Emulator 28.0.16 is now available in the Stable channel.
Here is the full list of changes versus the previous stable version, 27.3.10, categorized by area:
Read more
Emulator 28.0.16 is now available in the Stable channel.
Here is the full list of changes versus the previous stable version, 27.3.10, categorized by area:
Resource UsageWe have made a number of improvements to the RAM usage of the emulator, especially when it comes to graphics memory usage. The emulator should now use less RAM overall, especially when coupled with latest API 28+ system images where we have also improved the memory usage of the guest-side graphics drivers.
- Reduced emulator memory usage on long-running tests: If you are experiencing issues with emulator resource usage, please file bugs describing what happens and your use case. We are making resource usage of the emulator a priority for v28.
- Reduced CPU usage when running apps with animations.
- We have noticed that some Windows emulator users have been unable to launch the emulator due to exceeding the RAM commit charge. We have detailed the issue in the Troubleshooting page.
- Fixed leak of QEMU AIO context on Windows.
Multiple AVD instancesThis is a major new feature for CI users and we would like your feedback on this.
- Previously, the user was only able to launch one instance of a particular AVD at a time. The emulator can now launch multiple instances of the same AVD running concurrently. Instances started after the first instance are read-only; their changes to the guest virtual disk are discarded on exit.
- To run multiple instances of the same AVD at the same time, launch the instances after the first instance with the following command line flag: -read-only
- This feature is made possible by copying the QCOW2 files associated with the writable parts of the Android image. We have also bundled the qemu-img command line tool to allow you to pre-commit QCOW2 files before launching subsequent instances, to help with disk space issues.
- In addition, when used in tandem with File-backed Guest RAM Snapshots, multiple emulator instances started with -read-only will share the existing Quickboot snapshot as a common source of copy-on-write guest RAM. This allows the user to start multiple AVD instances that share much of their RAM in common, making it easier to run tests involving multiple devices in parallel.
- We appreciate your feedback on any possible use case of multiple emulator instances that are part of your normal interactive or CI workflow. Please feel free to file or upvote issues in Issuetracker.
File-backed Guest RAM SnapshotsThis is to address concerns for users who experience long saving times when closing the emulator, and is also useful for CI users.
By pre-allocating and mapping guest RAM as a file, Quickboot snapshots can be saved automatically as the emulator runs, instead of doing all of the work on exit. By default, like before, the Quickboot snapshot is saved on exit and loaded again every time, like suspending and waking a real device.
Because guest RAM is now auto-saved by default, if you want to establish some state in the beginning and repeatedly load from that state, discarding changes in each session, you need to decide in the beginning whether or not to discard changes. This can be done in the following ways:
- Add -no-snapshot-save or -read-only to the command line.
- Go to Extended Controls > Snapshots > Settings and switch Auto-save current state to Quickboot? to No. (A restart is required).
- If the emulator is currently auto-saving, adb emu avd snapshot remap 0 will set a checkpoint and the emulator Quickboot snapshot will not get written after that. Subsequent invocations of adb emu avd snapshot remap 0 will rewind the emulator to that checkpoint.
Multiple emulator instances started with
-read-only disable auto-saving, but now use any existing Quickboot RAM file as a common source of copy-on-write memory. This allows the user to start multiple AVD instances that share much of their RAM in common, making it easier to run tests involving multiple devices in parallel.
Snapshots taken and loaded through the Snapshots UI function as they did before, with no file mapping.
Since this is a large change in how Quickboot works, we would greatly appreciate feedback on whether it improves Quickboot performance and what kind of issues you encounter when using it. If you experience problems, the feature can be disabled by adding the following line to ~/.android/advancedFeatures.ini (create this file if it does not exist already):
QuickbootFileBacked = off
Starting the emulator from a snapshot (using the
-snapshot command line option or launching with a snapshot from the AVD manager) will disable auto-saving Quickboot and saving Quickboot on exit. This is to reduce unintentional overwriting of the Quickboot snapshot and to avoid using a slow fallback path that does not use file-backed Quickboot.
QEMU 2.12We have rebased our variant of QEMU from QEMU 2.9 to QEMU 2.12. It includes the following changes in QEMU:
Some notable changes impacting Android Emulator:
- x86: gdbstub now provides access to SSE registers
- Disk images: Image locking is added and enabled by default. Multiple QEMU processes cannot write to the same image as long as the host supports OFD or posix locking, unless options are specified otherwise.
- qemu-img: qemu-img resize supports preallocation of the new parts of the image.
- QCOW2 shrinking supported in qemu and qemu-img.
Accessibility
- Fixed issues and added better support for screen readers in the Screen Record and Snapshot UI.
- The Quick Boot notification icons have been revised to be more understandable to colorblind users.
Graphics
- Fixed an out-of-bounds memory access that could occur for OpenGL ES vertex array pointers.
- Some older GPUs did not support OpenGL 2.1 or greater (which is required), or had reliability issues, resulting in crashes on start, freezes, or general inability to use the emulator on the default GPU setting. The emulator now auto-switches to the Swiftshader renderer if it detects that these GPUs are in use.
- Fixed an issue that caused the emulator to not post the correct framebuffer if FBO != 0 was bound at the time of eglSwapBuffers.
- Fixed issue where the virtual Android display would only show up in the top left corner. We believe this is due to misconfigured Qt environment variables.
- The emulator now overrides all Qt scaling-related environment variables.
- Fixed a crash in some situations when loading GLES1 apps from a snapshot.
- Fixed concurrency issues in OpenGL / launching render threads, which could result in double frees or corrupted data.
- Emulator now supports ASTC LDR compressed texture support (GL_KHR_texture_compression_astc_ldr) if using latest API 28 system images.
- Most modern GPUs should now be able to launch the emulator with OpenGL ES 3.x enabled by default, and not require the activation of a separate GLESDynamicVersion feature flag.
- -gpu guest (software rendering in the guest) has been deprecated. API 28+ system images will now auto switch to using Swiftshader (-gpu swiftshader_indirect).
- If the emulator is launched with -no-window, the default is now Swiftshader, not guest rendering.
Location
- The emulator can now update bearing along with latitude/longitude position. The magnetometer virtual sensor now adjusts itself dynamically to magnetic north based on inferring motion when playing back a GPX or KML file.
- Device speed can now be set on the Location page.
- When playing back a GPX or KML file, the speed is set automatically, and is set to zero when the playback ends.
- Previously we required that the altitude be between -1,000 and +10,000 meters. This restriction is now removed.
- Fixed an issue where the virtual GPS location would not be properly updated periodically unless the Extended Controls window was opened at least once.
Camera
- On Windows, more webcams are supported due to dynamic resizing of the camera frames delivered from the webcam, and errors in frame delivery will no longer hang the emulator.
Play Store
- To address issues with running out of disk space on Play Store images, the emulator will automatically resize the userdata partition to 6 GB when running with a fresh Play Store AVD.
General Quality Improvements / Fixes
- Users have reported that the emulator has been slow recently. We have found that a possible cause of slowdown is that the temp directory for the emulator ends up with too many stale files inside. As a workaround, we do not store ADB liveness check files in that directory anymore. However, it may also help to delete the contents of that folder:
- Windows: C:\Users\<username>\AppData\Local\Temp\AndroidEmulator\*
- macOS/Linux: /tmp/android-<username>/*
- Insufficient memory message: If the emulator is unable to start due to insufficient free RAM, an error message is displayed. If you are on Windows and notice that there is RAM free, but you are still unable to start the emulator, the commit charge may have been exceeded. See this troubleshooting page.
- Increase of minimum RAM level for API 26+ images: Recently, users have reported that the emulator is slower than before. We have tracked this down to the AVD RAM size in the AVD's config.ini being set incorrectly. To mitigate this, the emulator increases the minimum RAM level for API 26+ images. Please file a bug if your AVD's config.ini is not listing hw.ramSize in megabytes. The file can be found in the data directory of the AVD:
- ~/.android/avd/<avdname>.avd/config.ini
- The -sysdir command line option now properly overrides the inferred system image directory.
- Virtual modem now supports the model activity info +MAI query.
- Fixed various memory leak, memory corruption, and CPU usage issues. If you are experiencing crashes, memory leaks, or other high resource usage, we encourage you to report a bug. We are making these items a priority.
- Fixed an issue that reappeared in macOS 10.14 in which using Bluetooth headsets with the emulator would degrade audio globally. The Mac emulator will now completely avoid using Bluetooth audio. Issue link: https://issuetracker.google.com/issues/37070892
- Fixed issue where, on Windows, the emulator clock would not be in the correct timezone.
- Fixed emulator slowness and hangs on Linux systems with spinning hard disks (HDDs).
- Fixed some compile warnings that could lead to stack corruption on Mac.
- Fixed issues that could result in misleading reports of hanging.
- Fixed issue with destroying thread pools that could result in a crash if one of the threads was not successfully created.
- Fixed issue on Mac where timers would become unreliable, leading to hangs and other strange behavior. If you experience emulator hangs on Mac, please file an issue in Issuetracker.
- Fixed an issue where closing the emulator would disable the UI, but not actually close the emulator.
- Fixed sporadic crashes, including an abort due to opening too many instances of /dev/urandom.
- Fixed issue that caused the emulator to fail to start after the first time if ADB was terminated forcefully.
- The MIPS build has been removed. If you still require MIPS, please file an issue.
- Fixed an issue where ADB connections could become corrupt on snapshot load.
- Fixed issue where the emulator window would have an afterimage or teleport offscreen when resuming a snapshot where the device orientation was different from the AVD's default orientation.
- Fixed crashes on snapshot save.
- On Linux, btrfs filesystems may cause extreme slowdowns due to auto-snapshot-saving mechanisms and the emulator already employing copy-on-write for its virtual disk devices. We recommend cleaning out the ~/.android/avd directory and running chattr +C on an empty ~/.android/avd.
- New snapshots will be created in a folder where copy-on-write is disabled.
HAXM 7.3.2We would like to mention HAXM 7.3.2 again as it is critical for proper functioning of the emulator for recent system images. HAXM 7.3.2 should already be available in the Stable channel, and can also be installed manually from
https://github.com/intel/haxm/releases.
- Fixed random crashes of guest OSes that use a recent Linux kernel (>= 4.6), e.g. Ubuntu 18.04 (#39, #74).
- Fixed an x86 instruction emulator bug that could lead to a host crash (#93).
32-bit Windows deprecationDue to low usage and maintenance costs, we are planning to deprecate the 32-bit version of the Android Emulator that runs on Windows. We will roll out a transition plan before removal and end-of-life for the 32-bit version of the Android Emulator. However, we are actively seeking any feedback or concerns with this future change. Please let us know in the
Issuetracker if you currently rely on the 32-bit version of the Android Emulator that runs on Windows, and how we can work with you going forward.
Posts
