For an emulator that mimics a Pixel 5 Device with Google APIs and ARM architecture (for an M1/M2 Macbook):
-
List All System Images Available for Download:
sdkmanager --list | grep system-images -
Download Image:
sdkmanager --install "system-images;android-30;google_atd;arm64-v8a" -
Create Emulator:
echo "no" | avdmanager --verbose create avd --force --name "pixel_5_api30_google_atd_emulator" --package "system-images;android-30;google_atd;arm64-v8a" --tag "google_atd" --abi "arm64-v8a" --device "pixel_5"
For M1/M2 Macbooks, use arm64-v8a as your "tag" or "target".
For Intel Macbooks use x86.
I recommend always using the new google_atd or aosp_atd images when possible. In my benchmarks, they are about 40% more efficient than the google_apis image.
Note: To check which devices you can create from the command line, run avdmanager list deviceand pass in the device name as the value of --device, e.g. --device "pixel_5" at the end of the command on step 3. (This includes tablets, etc)
Passing in a device will make the Emulator settings (usually found in the ~/.android/avd/emulator.avd/config.ini file) try to mimic that device. It is not actually the device. But, certain settings like pixel density, resolution, memory, partition size, etc will be changed. Generally the lower resolution devices will be less taxing on your CPU resources on CI, and are preferred especially without GPU/Hardware acceleration.
For generic skin emulator with default apis (without google apis) for use with Intel Macbook on CI (Can use google_atd too):
-
List All System Images Available for Download:
sdkmanager --list | grep system-images -
Download Image:
sdkmanager --install "system-images;android-30;aosp_atd;x86" -
Create Emulator:
echo "no" | avdmanager --verbose create avd --force --name "generic_api30_aosp_atd_emulator" --package "system-images;android-30;aosp_atd;x86" --tag "aosp_atd" --abi "x86"If you do not use the --device flag, I recommend adding these lines to: ~/.android/avd/generic_10.avd/config.ini or else your emulator will have a very low resolution. Note: Increasing resolution will decrease performance on CI. skin.name=1080x1920 # proper screen size for emulator hw.lcd.density=480 hw.keyboard=yes # enables keys from your laptop to be sent to the emulator If you cannot do this, you can still pass -skin 1080x1920 as an argument when starting the emulator. Keep in mind, you can also pass the --device flag and use a device name from the avdmanager list device command which should also set a default resolution because it will inherit the set of properties of that "device" in the config.ini. -
Run Emulator:
emulator @generic_api30_aosp_atd_emulator &oremulator @pixel_5_google_atd_emulator &
See: Google's Emulator CLI Documentation for more info.
See: Google's AVDManager Documentation for more info.
See: Google's SDKManager Documentation for more info.
Add aliases to your ~/.zshrc or ~/.bashrc to run the emulators with parameters more easily.
alias generic_api31_emulator='emulator @generic_api31_emulator -no-boot-anim -netdelay none -no-snapshot -wipe-data -skin 768x1280 &'
alias pixel_5 ='emulator @pixel_5 -no-boot-anim -netdelay none -no-snapshot -wipe-data &'
You can pass the -read-only parameter when starting up an emulator emulator @pixel_5 -read-only to run multiple devices at the same time.
- aosp_atd and google_atd system images are only available on x86 and ARM architecture at API level 30.
See also: https://android-developers.googleblog.com/2021/10/whats-new-in-scalable-automated-testing.html
Output of sdkmanager --list | grep atd:
system-images;android-30;aosp_atd;arm64-v8a | 1 | AOSP ATD ARM 64 v8a System Image
system-images;android-30;aosp_atd;x86 | 1 | AOSP ATD Intel x86 Atom System Image
system-images;android-30;google_atd;arm64-v8a | 1 | Google APIs ATD ARM 64 v8a System Image
system-images;android-30;google_atd;x86 | 1 | Google APIs ATD Intel x86 Atom System Image
avdmanager list deviceis great to figure out which emulators you can create- The newest cmdline-tools located at
$HOME/Library/Android/sdk/cmdline-tools/latest/binwere created for Java 9/10/11. If you are running into issues running sdkmanager, make sure to update your path in your~/.zshrcto the tools to the new tools if you are on Java 11, e.g.export PATH=$PATH:$ANDROID_HOME/cmdline-tools/latest/bin. If you are still on Java 8, you can use the old tools.
@josevelasdev I too am stuck in the same error, got any solution?