Improve Android emulator startup failure messages #1630

rmartin16 · 2024-02-03T20:31:11Z

Changes

Updates handling and management of information presented to the user when the Android emulator fails to start
Related issues:
- Android emulator acceleration messages may lead the user to install an incompatible version of HAXM #1036
- Android emulator does not open until CTRL+C is pressed during "Starting emulator..." #1573

UX

Conceptually, I broke the errors in to two categories:
- Briefcase detects the emulator closed
- The user aborts the start up process
In the first case, the emulator's output probably includes the recommended steps for the user.
In the second case, Briefcase probably won't be able to retrieve the emulator's output because the emulator will likely still be running....and retrieving stdout from a running process without blocking is non-trivial....but potentially really valuable here

Presentation when Briefcase detects startup failure:

Presentation when the User aborts the startup:

PR Checklist:

All new features have been tested
All new features have been documented
I have read the CONTRIBUTING.md file
I will abide by the code of conduct

rmartin16 · 2024-02-03T21:03:32Z

As it relates to #1573, these changes may make it less likely for users to report when the issue occurs. However, such reports aren't really producing any valuable information anyway right now.

Given this, it'd be nice if we could add some instrumentation to include potentially valuable information about the emulator when it occurs.

The only idea I have for that is trying to retrieve any output to stdout from the emulator since it started. This is tricky but is possible with the output thread streamer using something like stop_func=lambda: time.time() > [1 sec in future]. That said, I don't have any reason to believe the output will contain anything useful....especially if the process is simply blocked on something after starting.

From the provided logs from users, we can see the emulator is in an offline state....I don't know if that's useful but it's about all we have to go on.

Another thought to help users would be to print a message telling users to send CTRL+C if the Starting emulator... Wait Bar takes longer than a few minutes...

Open to ideas...

rmartin16 · 2024-02-03T21:12:58Z

wow....didn't expect the integration tests to try out the new errors right away lol

https://github.com/beeware/briefcase/actions/runs/7769288597/job/21188546568?pr=1630

[edit]
this looks like a non-transient problem...

freakboy3742

The broad direction of this looks like a good improvement - anything that makes it easier to surface what might be going on in this case will be a good improvement. A couple of cosmetic suggestions inline; but I don't have any additional ideas on other ways to improve the error reporting.

What's really frustrating is that the people who are experiencing this problem are the least likely to be able to help us diagnose it... but I'm willing to bet that as soon as we find someone who (a) experiences this problem and (b) has enough skills to know how to generate a useful log message, we'll be able to identify the problem and a fix really quickly.

The test failure is really weird... it reads like the specific machine that is being assigned for the job is lacking disk or memory space... but I would have though re-running the job would get you a new machine in the pool...

freakboy3742 · 2024-02-04T00:14:12Z

src/briefcase/integrations/android_sdk.py

                self.tools.logger.info(emulator_popen.communicate(timeout=1)[0])
+            except subprocess.TimeoutExpired:
+                self.tools.logger.info(
+                    "> Briefcase failed to retrieve emulator output "


Is this chevron intentional? If it's intentional, I'm not sure what it's communicating.

I went through a few iterations of what to print in this situation because initially, at least, I concluded that whatever is printed here could be construed as "the emulator failed to retrieve the logs". So, then I experimented with some bracket markup and then eventually just added "Briefcase" as the explicit actor that was trying to retrieve the logs.

At any rate, I can remove it.

freakboy3742 · 2024-02-04T00:16:46Z

src/briefcase/integrations/android_sdk.py

-            # if the emulator exited, this should return its output immediately;
-            # if it is still running, this will quickly time out and print nothing.
-            with suppress(subprocess.TimeoutExpired):
+            self.tools.logger.info("Emulator output log", prefix=self.name)


I'd be inclined to bump this to warning or error. As currently rendered, it looks a bit like "normal output"; but if we're at this point, we're already in "something is in the process of breaking" mode.

It might also be worth highlighting that it's not just the output log - it's "output because of error".

Yeah; I think I'm hesitant to make it red error output because that will automatically become the first thing the user looks at and perceived as the most important....and it might be. Mostly, I wanted to direct the user to where I wanted them to start reading...at least in the case of CTRL+C. For the other failure case, it's just a wall of red text.

Anyway, I think changing the emulator output heading to a yellow warning and saying Emulator Output Log for Startup Failure instead.

freakboy3742

I'm happy with this from a functionality point of view. The CI failure is the only thing standing in the way here.

I'm wondering if this might be a configuration change that has been introduced in a recent update to the Ubuntu system image... if the user's home directory has a restriction on the amount of free space, that might explain what we're seeing here.

If you want to try and debug this, Toga has a (commented out) mechanism for getting a shell session on the CI machine.

rmartin16 · 2024-02-04T03:50:21Z

It's something with the runner image released on the 1st.

I re-ran the most recent successful CI; it used the latest runner image and failed as well.

I may try to dig in later. I haven't found anything saying the available disk space was changed....intentionally anyway.

I suppose it's also possible the emulator is requiring more space for the qemu disks now...

freakboy3742 · 2024-02-04T04:05:25Z

Interestingly, the problem doesn't appear to be affecting Toga. Fresh PRs are passing Android CI without any problem

rmartin16 · 2024-02-04T04:11:32Z

Yeah...although, Toga isn't also building a bunch of Docker images beforehand (among a lot of other stuff)...so, I'm also wondering if something changed about the way Docker images are being managed...

I may just create a quick PR for app-build-verify to run df -h && du --max-depth 5 -h / | sort -h....that might help narrow down the issue to begin with...

rmartin16 · 2024-02-04T06:38:11Z

Unfortunately, re-running a previous run of CI uses the same workflows it ran the first time. If a workflow is updated (as we did in beeware/.github#88), you need a new commit; I'll push an update.

freakboy3742

All looks good in CI, so 🚢 !

Improve Android emulator startup failure messages

bef1578

rmartin16 force-pushed the android-emulator-debug branch from daf09fd to bef1578 Compare February 3, 2024 20:39

rmartin16 requested review from freakboy3742 and mhsmith February 3, 2024 20:42

freakboy3742 requested changes Feb 4, 2024

View reviewed changes

rmartin16 requested a review from freakboy3742 February 4, 2024 01:40

freakboy3742 reviewed Feb 4, 2024

View reviewed changes

rmartin16 mentioned this pull request Feb 4, 2024

Delete Docker images to free up disk space beeware/.github#88

Merged

4 tasks

Tweak errors for android emulator startup failure

a835cea

rmartin16 force-pushed the android-emulator-debug branch from 9c31475 to a835cea Compare February 4, 2024 06:38

rmartin16 requested a review from freakboy3742 February 4, 2024 07:08

freakboy3742 approved these changes Feb 4, 2024

View reviewed changes

freakboy3742 merged commit e650795 into beeware:main Feb 4, 2024
44 checks passed

rmartin16 deleted the android-emulator-debug branch February 4, 2024 07:12

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Improve Android emulator startup failure messages #1630

Improve Android emulator startup failure messages #1630

rmartin16 commented Feb 3, 2024 •

edited

Loading

rmartin16 commented Feb 3, 2024 •

edited

Loading

rmartin16 commented Feb 3, 2024 •

edited

Loading

freakboy3742 left a comment

freakboy3742 Feb 4, 2024

rmartin16 Feb 4, 2024

freakboy3742 Feb 4, 2024

rmartin16 Feb 4, 2024

freakboy3742 left a comment

rmartin16 commented Feb 4, 2024 •

edited

Loading

freakboy3742 commented Feb 4, 2024

rmartin16 commented Feb 4, 2024

rmartin16 commented Feb 4, 2024

freakboy3742 left a comment

Improve Android emulator startup failure messages #1630

Improve Android emulator startup failure messages #1630

Conversation

rmartin16 commented Feb 3, 2024 • edited Loading

Changes

UX

PR Checklist:

rmartin16 commented Feb 3, 2024 • edited Loading

rmartin16 commented Feb 3, 2024 • edited Loading

freakboy3742 left a comment

Choose a reason for hiding this comment

freakboy3742 Feb 4, 2024

Choose a reason for hiding this comment

rmartin16 Feb 4, 2024

Choose a reason for hiding this comment

freakboy3742 Feb 4, 2024

Choose a reason for hiding this comment

rmartin16 Feb 4, 2024

Choose a reason for hiding this comment

freakboy3742 left a comment

Choose a reason for hiding this comment

rmartin16 commented Feb 4, 2024 • edited Loading

freakboy3742 commented Feb 4, 2024

rmartin16 commented Feb 4, 2024

rmartin16 commented Feb 4, 2024

freakboy3742 left a comment

Choose a reason for hiding this comment

rmartin16 commented Feb 3, 2024 •

edited

Loading

rmartin16 commented Feb 3, 2024 •

edited

Loading

rmartin16 commented Feb 3, 2024 •

edited

Loading

rmartin16 commented Feb 4, 2024 •

edited

Loading