Android emulators not starting for the last few days? (late March 2019)

Languages Android
,
1

Not sure what is going on recently but builds that used to work are now failing.

Just to be sure I wasn’t losing my mind I went back to a build that did work, and restarted it. Now it fails.

https://travis-ci.com/mikehardy/Anki-Android/builds/106048154

The AnkiDroid project is fully open source and our builds are easy to reproduce - https://github.com/ankidroid/Anki-Android/blob/master/.travis.yml

1 Like
2

Can you try by removing tools from components.

3

Sure, I’ll give that a try. It does seem odd that a .travis.yml that hadn’t changed resulted in builds breaking but I guess that’s the downfall of dynamically resolved dependencies. I’ll report back when I get a chance to test it.

4

Actually a few days earlier same happened to me. Suddenly emulator stop working. Finally, after searching for 20 hrs I got this. This worked for me and started the emulator at least. Now from nowhere license are making an issue for SDK 28 and none of the solutions are working to accept the license. Even though you can give a try by removing tools. Hope that works for you.

5

@akshay-testpress - thanks so much for the replies - I did try this in every combination I could think of but I couldn’t get it to work that way. Not sure what is going on. The android emulator setup docs have examples that have no triggered builds in the last week so I can’t check them, and in general it’s listed as “unsupported”, which isn’t great. Maybe I need to investigate CircleCI though I was pretty happy with my .travis.yml…

6

Getting this as well, https://github.com/natario1/CameraView/blob/master/.travis.yml .
Just like original post, this used to work and no changes were made. The only error line is

emulator: ERROR: detected a hanging thread ‘QEMU1 main loop’. No response for 105001 ms

@mikehardy if you find a solution, I would appreciate any help.

7

I’ve had no luck, I hate just randomly tagging people but maybe @BanzaiMan with his vast experience knows something? (and maybe my flattery here will make up for randomly tagging him :wink: )

8

Nothing that I think can explain this sort change in behavior has been deployed recently, so I am really not sure what is causing it, unfortunately.

1 Like
9

Hey everyone, so I looked into this deeper and I think the new behavior stems from the new Android emulator package that was released on March 29th. See https://developer.android.com/studio/releases/emulator.html#28-0-25.

I did some tests on Travis CI and it seems that the only armeabi-v7a based emulator that’s working now is the android-24 one i.e. "system-images;android-24;default;armeabi-v7a".

I have a sample config that you can look into here: https://travis-ci.org/cotsog/travis_ci_prod_regular/jobs/516178009/config.

Could you try this out and let us know if it helps?

Thanks!

2 Likes
10

@dominic thank you for investigating this! I haven’t kept up with the release notes (I should have) so I didn’t see that. It seems to me that the headless backport from canary is probably the culprit https://androidstudio.googleblog.com/2019/02/emulator-2818-canary.html - I’m going to investigate using that.

I believe they added the ability for x86 to run without emulation also which would solve a long-standing problem of no arm emulators for the modern APIs unless/until Travis supports nested virtualization (separate issue of course, but I imagine that if you toggled that in the infrastructure you might burn quite a few less CPU cycles, but I digress)

I will test API24. I will try the headless stuff. I will try x86 without virtualization. And I will also see if I can directly fetch the prior package as a quick-fix recommendation for people that just need green CI to unblock. Will let you know

1 Like
11

Some preliminary results.

TL;DR: add ‘–channel=4’ to your emulator install line to use the canary emulator 29.0.1 (as of this writing) and you’re good.

But there’s great news

  • I didn’t test just the API24 (I wanted more API skew than just that, so I was going to do it last)
  • I did try headless. The binaries are in $ANDROID_HOME/emulator/qemu/linux-x86_64 and have a ‘-headless’ version but ‘emulator-headless’ as a front end for them doesn’t exist and I haven’t done the fiddly bits yet of figuring out exactly how to get that one to fire up
  • if you enable ‘–channel=4’ on your sdkmanager line you get access to canary (emulator 29.0.1) and it works! Not only that, it works with x86_64 images you guys. MODERN ANDROID EMULATORS. Also the canary emulator fixes the old APIs (down to 16) without using -engine classic (aka QEMU1)

As far as I am concerned this is resolved, just you have to move to the canary.

Using the headless emulator binaries is something that bears investigation for the future but we can get our CI dashboards green again now

12

Still a few peculiarities to work out (API28 and Q emulators look like they work but are resource-hungry enough to have trouble with the 10minute startup timeout (Q) and ADB command response timeouts (28)) but this is a thing of beauty: https://travis-ci.org/ankidroid/Anki-Android/builds/516486599

13

Any updates on the API 28 adb connection/timeout issue?

14

Hi there - I haven’t pursued this further with success since the last update, once I got the main fleet of emulators on the API skew working it was a lower priority. I did make one attempt using the timeout values I’m aware of, but I think this will either take a few more emulator speedups from Project Marble (Google’s optimization project, which helps emulators in CI), nested virtualization in Travis, or a custom build of ddmlib (the source of which is available in AOSP, you can download it and tweak timeouts directly - stackoverflow has some success reports for similar problems some time ago). Hope this info helps, and if you try it (esp. with ddmlib) I’d love to hear results.