Option to choose emulator build version

[natario1]

It seems that each emulator version breaks something new. 29.3.0 was out recently (today?) and I'm now fighting against system exceptions, segmentation faults or emulator not starting at all.

It would be very nice to be able to choose a specific emulator version that proved to be "stable". See here for linux: https://github.com/mmcc007/test_emulators/blob/master/.travis.yml#L242-L245

      curl -fo emulator.zip "https://dl.google.com/android/repository/emulator-linux-$emulator_version.zip"
      rm -rf "${ANDROID_HOME}/emulator"
      unzip -q emulator.zip -d "${ANDROID_HOME}"
      rm -f emulator.zip

On macOS we should replace emulator-linux- with emulator-darwin- in the URL but it should work. This feature would let for example go back to v29.2.11.0 by passing the build number 6031357.

[natario1]

Some mappings from emulator -version:

• v27.2.9.0 : build number 4773671
• v27.3.8.0 : build number 4848055
• v27.3.9.0 : build number 4899998
• v27.3.10.0 : build number 4969155
• v28.0.16.0 : build number 5112988
• v28.0.20.0 : build number 5171946
• v28.0.22.0 : build number 5194135
• v28.0.23.0 : build number 5264690
• v28.0.25.0 : build number 5395263
• v29.0.6.0 : build number 5513838
• v29.0.8.0 : build number 5533278
• v29.0.9.0 : build number 5537588
• v29.0.11.0 : build number 5598178
• v29.1.12.0 : build number 5839083
• v29.2.0.0 : build number 5871853
• v29.2.1.0 : build number 5889189
• v29.2.11.0 : build number 6031357
• v29.3.0.0 : build number 6061023

[ychescale9]

Yeah not being able to pin the emulator binary version is really annoying. We recently had an issue with 29.2.11 for docker/linux (https://issuetracker.google.com/issues/145622251) which was fixed in 29.3.0. But now it breaks darwin builds??? It's supposed to be a fix exclusively for the issue reported on 29.2.11. Can you show me those error logs? Have you reported those issues?

Also do you know where we can get a list of all emulator version : build number mappings? I filed this and they are also looking at a better versioning scheme and adding support to the downloading specific emulator version with sdkmanager.

Another question is how do we decide which version is "stable" now that users can specify any launch-options some of which might expose more issues than others? I'm thinking once we've got a "official" list of [emulator version : build number] mappings we'll just use the latest from stable channel as default, and allow user to specify the emulator-binary-version in which case we'll download it from the url instead of using the sdkmanager.

[natario1]

Man I was the first star on that issue and because of that I have later left Travis out of frustration and found this project.

I don't have a complete list of mappings unfortunately. A good source could be looking at CI logs from some open source project that happens to call emulator -version. Might have collected quite a few values over time.

That said I would be already happy if this action accepted the build id instead of version, until maybe Google answers your feature request (starred!). At least, if the provided value does not start with "v", we could assume it's a build code.

Not easy to link from mobile, but if you look at https://github.com/natario1/CameraView/pull/696/checks , most failures and cancellations from the latest commits are due to segfaults or emulator freezing (no output, test suite frozen, ...).

[ychescale9]

I can totally feel your pain as you're dealing with emulated camera which behave differently for each API level. Or could this be the latest system images? I don't recall seeing any updates recently though...

I'll consider adding a temporary emulator-build action input as a workaround for you and whoever needs to pin a specific emulator build, and eventually replace it with a proper emulator-version once the mappings are available.

[natario1]

About logs, this one froze in the middle of the test (scroll to bottom and see timestamps):
https://github.com/natario1/CameraView/pull/696/checks?check_run_id=348074726

This one could not even start the test command: https://github.com/natario1/CameraView/pull/696/checks?check_run_id=348074758

Segmentation fault:
https://github.com/natario1/CameraView/pull/696/checks?check_run_id=348763184

I have no evidence that this is 29.3.0's fault, but I only got these in the past couple of days, and new versions do tend to break something each time (before that linux issue you mentioned, they removed the emulator-headless binary out of nowhere...).

About build vs. version I think the build number includes both version and channel, so the mappings are a bit more complex than that if you want to support different channels. Anyway I'm happy with any solution. Won't ever go outside of "Stable" which is already self-destructive

[ychescale9]

They mentioned they were going to replace emulator-headless with -no-window in the 29.2.7 Canary release note, and they just did it... They are moving (and breaking) pretty fast these days.

Have you reported those issues? The emulator team is quite responsive and willing to help, although helping them debug can be very time-consuming 😞

[natario1]

Yeah I can't afford the debug effort for helping the team. I only encounter this issue in about 20% of test runs, and can't even bring evidence that it is related to 29.3.0, although I suspect that. So I haven't reported.

[natario1]

After 91 commits my PR is finally green. Thank you so much @ychescale9 !

[natario1]

@ychescale9 I've been updating the list above. I think these are all the stable versions from 2018 and 2019. Possibly some of them are not stable but I left them there anyway. Just in case you don't get any answer from Google

[natario1]

I figured out the best mapper is the issuetracker itself. If you search a version name there you'll always get the build number inside the bug reports. So it's not hard to build, maybe even for other channels.

[ychescale9]

Thanks! I'm still hopeful that Google will publish and maintain an official list eventually as that would also benefit other projects. I'll try to ping the Emulator Tech Lead everytime he posts a new release on Reddit:)

Re. channels, how useful do you think if we add support for using non-stable channels (#1 )?

[natario1]

Well, since we're at it... I think a recent canary emulator is much more useful than a 2018 stable. Pinging the tech lead could improve your chances indeed 😄

[ychescale9]

Looks like they'll look at adding the emulator download paths next month.