Best Practices in Using the Android Emulator (Google I/O’19)
Articles Blog

Best Practices in Using the Android Emulator (Google I/O’19)

August 9, 2019

afternoon, everyone. Welcome to Android
Emulator Section. My name is Sam Lin. I’m a product manager in
Android Emulator Team. Join me onstage
are Frank and Hoyt. How many people here have
been using Android Emulator? Show me your hands. Wow, that’s great. Good to see you guys here. Today we’re going to tell
you about a new feature and to show you a few use case. Hopefully that will
inspire you a new way to using Android Emulator to
improve your productivity. If you haven’t using Android
Emulator, the first tip for you, you can download
Android Studio today and try it out. Android Emulator has always been
part of SDK from version one. Can you believe it is
already 11 years ago? I still remember my
first Android app. I powered it with SDK 1.5. Back then, Android
Emulator was slow. I end up need to using a
lot of physical device. But, in the past few years,
we have been systematically improved Android Emulator. Three years ago, we’d
review the foundation to make it much, much faster
and add a bunch of feature, so it’s easier for you to
test application with it. Two years ago, we add the
Google Play Store support, so you can actually test your
application distribution flow end to end. Last year, we add the snapshot. You can literally easily switch
between different systems’ tech to help you do
different tasks quickly. And this year, we add
the foldable support. You can start to help
user to unfold the future with your application. With all those changes,
we are actually focused on three key principle. The first one is fast. A good emulator should be
fast so we can actually get things done quickly. The second one, a good emulator
shall be high fidelity, which it mean you can
test application just like using physical device. Finally, a good emulator
can be versatile, so we can actually help you
finish different kinds of task quickly. At Google, we believe
faster is better than slow. That’s why we start
making Android Emulator fast to save you time. So how do we know
something is fast? Obvious, UI is a big part
of it, because nobody likes using jenky
UI, we’re using this to make sure our department. This is I’ll show you how
many frame per second a device can draw when they run
the benchmark application. As you can see, Android Emulator
is slightly faster than Pixel 2 XL, which mean running
application on Android Emulator is pretty fast now. In case you’re curious, I using
the notebook have a core quad CPU, 16 gig of RAM, fresh
storage, and a good GPU. Frank, can you tell us how we
made Android Emulator fast? LINFENG “FRANK”
YANG: Sure can, Sam. So, to start out with,
the biggest thing that’s changed about the Android
Emulator versus the emulator from many years
back is we stopped translating every
single instruction of the guest operating
system to x86 one at a time. So what used to be
the case that you ran an arm Android guest
operating system on an x86 host machine, and that
required the emulator to look at every
single instruction and decode them while
translating them to x86 equivalence. And this is actually
how most emulators work these days because of
this architectural mismatch between the guest operating
system’s CPU architecture and the host CPU architecture. But with the Android
emulator, we’ve decided to run x86 on x86. And that gives you a
really powerful technology, CPU virtualization, which is
a set of hardware extensions for your CPU that let you
simply direct your computer and run the Android
guest operating system’s code directly with
almost no translation. So these technologies
are called hypervisors, and we use HAXM on Windows,
or Windows Hypervisor Platform if you want to run with
Hyper-V. And on Mac we use Mac OS Hypervisor Framework,
and on Linux we use KVM. So this lets you run the
Android guest operating system with nearly the same
CPU performance as your host machine. Next, Android, to give a
brief bit of background, does almost all of its hardware
rendering operations using the OpenGL ES or Vulcan APIs. Previously we used to
run these graphics APIs in the Android guest operating
system using the CPU to render, while these APIs are meant to
be used with hardware GPUs. However, hardware GPUs
is now the default setting for the Android
Emulator and has been for quite some
time, and we’ve recently started supporting the
Vulcan and OpenGL ES 3.1 APIs in Android Q. We do this
by leveraging GPU virtualization techniques that let you use
the full power of your host GPU in order to run
Android Emulator. SAM LIN: That’s great LINFENG “FRANK” YANG: Thanks. SAM LIN: So during the
development process, you actually interact with
Android device quite often. For example, you’re
testing the app, and you’re installing
application. All those interaction is
basically done by Android Debug Bridge to help
you transform data from the computer
to Android device. The way to measure
this performance, you can easily done by
pushing the application or file to Android device. On this chart, we show you
Android Emulator can actually doing this much, much faster. Frank, can you show
us why it is that? LINFENG “FRANK” YANG: Sure. So if you’re using– oh,
go back to the slides? Sure. If you’re using a
real device, you often need to connect it with USB. And USB contains a few
complications here and there. So you’ll need a USB cable
upon USB cables, USB 2 or 3, USB drivers that work well with
your Mac OS or Windows system, especially, and
depending on your device, it may or may not support
the latest and greatest USB protocols that are fast. Now if you’re
using the emulator, everything takes place
on your host machine. All of your adb pushes and
all that, they basically talk through a virtual TCP
connection over shared memory. So you’re essentially limited
by your host machine’s disk IO when you’re transferring
files over adb. So that’s why we can get
adb push to be so fast. SAM LIN: That’s great. With that performance
advantage, you can actually get things done faster. For example, when you
installed application, this I’ll show you,
emulator is actually faster for a simple application. Of course, if your
application is much bigger, Android Emulator will
save you more time. We also know you normally
do quite a lot of things on your computer, and
sometimes you just need to close Android Emulator
to do some other things. But for Android to
pull up, you actually take [INAUDIBLE]
for our sequence, which you can take for a while. That’s why we add
Quick Boot, which will resume Android
Emulator in a few seconds. Switch it to demo, please. LINGFENG “FRANK”
YANG: Thanks, so I’ll show you the difference
between a normal boot up of the device and the Emulator. So with this AVD
called Cold Boot, you can select Cold
Boot right now. And you see this black
screen here called, Boot Selected by User. And I guess, we gotta
wait for a while before a Google logo comes up. But we have this other
AVD called Quick Boot, where you just press Play. I have a previous
snapshot saved here. And it’s able to just
come up right away, while the other
Emulator is still in the middle of
its boot-up cycle. And the Quick Boot Emulator is
already interactive right away. So this makes it really easy to
set your device in some state. Now, you need some more
resources or whatever– you close the Emulator. And you launch it
again really quickly. Also, this is our most
heavyweight hardware profile– the 8-inch Foldable. And it was able to
launch in much less time than a cold boot, using
our snapshots technology. Thanks– back to the slides. SAM LIN: Wow, that’s great. We also tried to look
at what kind of things Android Emulator can do
faster than a physical device. For example, our friends
on AR core team– they love using Android Emulator
to test their application. But just like me, they are lazy. They don’t want to do
manual tests every time they change an application. That’s why they add a new
feature called AR Micro. This allows you to
playback a preset breaker. So you can do sanity tests
quickly and precisely. Switch to demo, please. LINGFENG “FRANK”
YANG: Thanks, Sam. So for those of you who
went to the keynote today, there were some really
cool AR demos, right? And it kind of looked
like you really needed a real physical device in order
to develop and test AR apps. However, on the Emulator, we’ve
been working with the AR core team to enable you
to test and develop AR core apps without
needing a physical device. We call this the
Virtual Scene camera. It is a virtual
camera device that exposes a virtual environment. This virtual
environment has textures that can be picked up by
AR core tracking algorithms and, thus, can function largely
to the needs of your AR core application. But recently, we’ve added a
feature called AR Core Macros. This is because, when you’re
running this virtual scene camera, you might end up doing a
lot of repetitive motions like, maybe, resetting to
their initial position– which we can do now
with a button press– or tracking a horizontal
plane, in order to get the tracking
plane to show up, so we can place
your AR core models. Notice that, while the
playback is going on, the camera is changing
its viewpoint according to the macro’s instructions. And while that is going on,
all the right sensor signals are sent to the guest so that
your app will think that it’s in a real environment. Thanks– now back to the slides. [APPLAUSE] SAM LIN: Thank you. I think I want to
add on that one. If you look at
the mobile device, the powerful mobile
devices actually interact with the world. That means you need to do
a lot of tasks manually. And we try to explore if Android
Emulator can help you on that. This is just a starting point. In the past few
months, we have been working on [INAUDIBLE] mobile,
which polish Android Emulator. In the new release, we actually
improved the efficiency for Android Emulator. For example, when device
is on the Charger mode, Play Store can
automatically update application, whenever there’s
a new version available. This is actually one
of the key reasons Android Emulator
attacking a lot of CPU and consume a lot of power, as you
can see on the chart right now. To avoid this, the team actually
properly enabled the Battery mode by default, which
will eliminate Application Auto-Update and the
background tasks, as you can see– that blue line. But don’t worry,
you can still turn on Application Auto-Update,
whenever you like it. Just switch to AC mode. Now, let me hand this over
to Hoi to tell you more. HOI LAM: Thank you, Sam. so we have just talked
about– how do we make the Emulator nice and fast? The next thing that we
need in an Emulator is– well, actually, we
need to trust it. Otherwise, there is
very little point in you testing anything
on the Emulator. So the team have
done a lot of work to make sure that the behavior
of the Emulator is the same or very similar to
the physical device. So what are the three
things that we have done? Let’s go through them. The first thing is– we
start off with the same code base as a physical device. And when we say,
the same code base, we don’t mean half a stack. We mean the whole stack. And that includes the hardware
abstraction layer, as well as the Linux kernel. In addition, as Sam and
Frank mentioned earlier, we have made it super fast
for Windows, Mac, and Linux, by paying a lot of
attention to performance, so that you can get the
same feel using the Emulator as the physical device. So OK– fine. You’ve done the code. But as all good
developers do, we test it. So we are now running over
900,000 compatibility tests. And these are the
same tests that pass with your physical phone. So your physical phone
passed these tests. And the Emulator
passed the same tests. And you might go– yeah, Hoi–
900,000– big number. What does it actually mean? Can you give me a
concrete example where this makes a difference? So this is one of the tests
that the previous generation of the Android
Emulator had failed. When you’re displaying a YUV
image, instead of displaying the Blue-128,
actually, we sneakily fit in Blue-132 and hope
that you didn’t notice. Well, you may not notice
it from this screen. But your integration test would. And a lot of integration tests
actually fail because of this. And why is that? When we go through the code
base, these kinds of things were in it. We basically run one set of
code if it is a physical device. And we run a completely
different set of code if it is running
in the Emulator. So the team worked diligently
and went through all the code color within Android, to
take these kind of codes out. So the result is– when you specify
Blue-128, you can be sure that it is giving you Blue-128. And if this doesn’t convince
you, maybe this date will. From the 1st of
August 2019, as we all know, when you’re submitting a
new or update app to the Google Play Store, you will need
to submit a 64-bit version. And if you haven’t got a
64-bit device to hand– well, the Android
Emulator is your friend. Woo-hoo! So we have done testing. We’ve done our code base. How about things
that you’d normally find on a physical phone? The team have done
such a good job that Google Play Store
actually now trusts us to, basically, put the
store on our phone. And what this means
is you can actually truly test the app end-to-end–
not just installing it and run through the
flow within your app but through all the things that
are around the app as well. So a typical end-to-end
testing scenario might start with an ad on
a website on another app. When you click through,
it will actually take you to the Google Play Store. And you can install
the app right there. After that, you can
sign in with your Google account or any of
the social networks that your app may support. Because you can now install
those social network apps on the Emulator. If your app supports
in-app purchase, you can also test in-app
purchase in the Emulator itself. And last but not least, all of
us want our apps to go viral. You can now share your
app within the Emulator and test their flow as well. So this is truly
end-to-end testing. Woo-hoo! We heard a couple of claps. [APPLAUSE] Excellent. So we have built the
Emulator super fast. And hopefully, we’ll have
convinced you as, you know, we’ve done a lot work in getting
back your trust on the fidelity of the Emulator. How about– how does it
actually fit into your workflow? So let’s talk about the
versatility of the Emulator itself. My own personal favorite
feature is Snapshots. How many of you have
basically installed an app, run through the
flow, and then you realize– oh, actually, I need
to test it again! Which means
uninstalling your app and then, basically, reset
up the entire thing again. Show me your hands. Yay! OK– so this feature is for you. After you get done
all your setup steps, you can just tell the
Emulator to save a snapshot. And when you’re
ready to test again from exactly that
particular point, you can just click
on the one button and basically get right
back to that point. Can we switch to
the laptop, please? And Frank will
demonstrate this for us. Over to you. LINGFENG “FRANK”
YANG: Thanks, Hoi. So I’m going to demonstrate this
little thing where oftentimes Snapshots can be useful
for when you want to put your device in
a particular state that is easy to get back to. This is especially
going to be an issue in new foldable devices,
where a split-screen may be more prominent. So to demonstrate a
split-screen first, I’ll show you how to set it up. I’m going to start this
Multi-window Playground app that does different
things, depending on your split-screen settings. I’m going to activate
split-screen, by pressing the App icon
and selecting Split Screen. So, now, we have
another window pane in which we can potentially
launch a different application. Now, when you’re testing
this multi-window app, one of the things
that might happen is you might launch an
un-resizeable activity. And now, when you
launch that, the system has no choice but to
cancel Split-Screen mode and put you in this Fixed-Aspect
Ratio mode right here. And now, if you want to
retest that original scenario, you need to click through
what I just did again. But with the Snapshots, once
you have saved your device in a state that you like,
you can click Play down here. And it will load the snapshot. And I guess it’s still loading. But– yeah. HOI LAM: That is live demo! LINGFENG “FRANK” YANG: Yeah. HOI LAM: Yay! [APPLAUSE] LINGFENG “FRANK”
YANG: So anyways– HOI LAM: OK– it’s there. LINGFENG “FRANK”
YANG: –you load it. And then it’s in the state
that you were using before. And you can then pretty easily
set up many other states here and also change the name of
your snapshot and everything. So that’s cool. All right– back to slides. HOI LAM: Cool! Thank you, Frank. So in that scenario,
you might argue– hey, it was just two steps. It split the screen. But as many of you who have
raised your hand before– you might spend five
minutes setting up your app to a particular
state before you go on a test. And what I usually do as
well is I will actually run through the flow of my
app and pick several snapshots along the way, which saves
me a ton of time when I want to retest a
particular bug fix or when I want to just add a new
feature at a particular place. And I can go right back in. So a performance snapshot– and we have done
a lot of testing. So now is your turn. And what’s better than
running one test?– running multiple tests
at the same time. So another feature that the
Android Emulator supports is having multiple instances
running different tests at the same time. Another way that I use this
is to test the same app on different screen
configurations. And this doesn’t just work
for the phone form factor. It also works for large
screen and foldables as well. And another thing
about the Emulator is– quite often, you have
different devices available in
different geographies. And, in this particular
case, foldable is actually pretty
hard to get, even when you’re working in Google. So what happened with the
foldable at a moment is– I have to say, my first
taste of foldable and testing my own app on
foldable is actually on the Android Emulator. So I strongly encourage
you to take a look. And I’m sure that you
have got many more questions about
this new form factor and also the larger screen apps. So we have got a
special session today at 5:00 PM, where you can
check out the latest best practice about building for
foldable and large screen. I strongly recommend that
you attend that session. So we test– different tests,
running at the same time. We have different screen
configuration tests. What about other things you
can do with multiple instances of the Emulator? Another one my
favorites is basically running different instances, but
running different API levels. I’m sure that a lot of you will
go through the Behavior Change page of every single Android
release and find out– oh! You have changed this. Let me test that. This makes it super easy to
test at different API levels, such as, in this example, the
straight screens have been changed in Android Q.
So you can now test it right next to an Emulator. So Frank, can you
show us how this could be done with
different types of testing? LINGFENG “FRANK” YANG: Indeed. Well, let’s switch to– HOI LAM: Let’s switch
to the computer. LINGFENG “FRANK”
YANG: –the laptop. Thanks, Hoi. So there are many
different things that you can do with multiple
instances of Emulators. And there are
different Degrees So, the first one, which
we introduced recently, is a way to run more than
one instance of the same AVD. Note that previously, you needed
to create more than one AVD if you wanted to run more
than one Emulator in parallel. Well, now you don’t have to. I have a terminal
open with a script to launch multiple
instances of the same AVD– called, Now, you’ll notice that this
command line is pretty typical, except for the fact that we
have this new command line flag here– read-only. And the AVD name is
the same in both cases. Now, why is this significant? Well, read-only
will essentially let you launch more than
one instance of an AVD at the same time. So when we launched a script,
it will launch both of them in the background. In addition, if you add
the read-only option and you’re booting off
of a Quick Boot Snapshot, you’re only going to restore
it to that previous snapshot and discard all of the changes
to the snapshot, once you exit. So once you launch
it again, you’re going to be in the
same exact state that you started with when
you last saved the Quick Boot Snapshot. I will demonstrate now. So this is actually
two Emulators. And they’re all
running independently. And if we look in, say– let’s clear the
terminal adb devices– we have two devices. And we can run integration
tests, as if we actually had two devices. So for example, if I try to run
this instrumentation test here, the adb shell am instrument– it can run on parallel on
both devices at the same time. So one test is
running on one device, and a different test is
running on the other device. So you can get tests
starting pretty easily. One last thing to mention
about resuming these AVD clones from the same
snapshot is that their RAM is shared until it’s written. It’s called Copy on Write. So this is also using
less RAM than if you started two independent AVDs. So that’s the same AVD instance. But what if you’re testing
multiple screen configurations? Well, let’s launch a normal
screen configuration and one of the new foldable ones. OK– let’s see– and if we run the Santa
Tracker in the Emulator with normal screen
configuration, it comes up with a
particular layout. However, if you launch the
foldable Emulator and then, inside that Emulator,
you launch the same app, you can often get
a different layout. So running multiple Emulator
screen configurations this way lets you really quickly test
multiple screen configurations. And since this is
a foldable device, I have to also demonstrate
the folding feature. So, with a foldable
device, the app layout will change a lot if
you fold and unfold. And so the foldable
virtual devices give you a quick
way to test this. All right– so that’s
for our different screen configurations. What about different API levels? In launch-sdk-compat, I will
be launching two Emulators. One of them is an API 27 Oreo. Another one is a Q image. So once we launch them– both of them are
in Read-Only mode. So once you can integrate
this into your CI pipeline, all the changes are
discarded on exit, so you can launch it the
same way the next time without wiping any data
or installing any apps or restoring any state. Anyways, let’s see,
sharing shortcuts test. Test stat sharing
app that Hoi was showing earlier on both of
these API levels in parallel. And we can, indeed, get one
of the tests to fail and one of the tests to succeed,
depending on the API level. So there you have it– multiple instances. They will let you chart
your test with the same AVD, let you run multiple screen
configurations in parallel, and run tests on different
API levels in the same manner. All right– back to slides. AUDIENCE: Whoo! HOI LAM: Yay! Isn’t that fantastic? [APPLAUSE] So hopefully, we
have convinced you that you should
run all your tests collate multiple instances. Another way that
can really help is to run, actually, those
tests in a Headless mode, so you can save
even more memory. And by all accounts, you
save about 100 megabytes if you’re running
it in Headless mode. Frank, can you show us? LINGFENG “FRANK” YANG: Indeed–
let’s switch to the laptop. So one of the complaints
about the Emulator that we heard a
lot is how hard it was to deploy in many common
continuous integration containers’ delivery pipelines. In the recent versions
of the Emulator, we tried to let take a hard look
at the Emulator’s dependencies on the Linux system and
tried to strip down as many of them as possible,
starting with removing the usage of UI libraries. So we used to depend on things
like X-11, Pulsario, QT. But now, we give you
the option to run the Emulator in a
minimal-dependency headless field. So, in order to use
the Headless field– let’s see– In recent Emulator versions, we
provided a new Emulator binary called Emulator-headless. What this is is the Emulator
that doesn’t use any UI but still does all of the
rendering and everything else, just as the normal
Emulator would, so that you can get
high-fidelity results and easier to deploy. We explicitly list the libraries
on Linux that this depends on. There’s only, like,
7 of them– like, ld-so and various
essential things. So hopefully, we
this makes it easier for you to run CI
pipelines with Emulators. Launching this, you’ll
notice that it’s launched, but there is no UI. But, if we go back to
Studio, Lawcat is running. Everything in your tests
will behave as if there was a real device there still. You just have a
minimal footprint that is easier to deploy. All right– thanks. Back to slides. [APPLAUSE] HOI LAM: Whoo! Let’s go back to slides, please. And I’m sure that
a lot of you really want to find out– what’s
the latest best practice on building [INAUDIBLE] apps? So, on Thursday,
at 11:30, we have got another session for you. Please go there for
the latest information. So we’ve went through the
day-to-day development using Snapshot to having
multiple tests running– integration tests or maybe your
continuous integration system running them. OK– so after your app launch– I am sorry. But in real life, the Android
Not Responsive and crashes, unfortunately, do happen. And one of the ways
that I use the Emulator is basically in conjunction
with the Google Play Console. So the Google Play Console– you will see the
different crashes or Android Not
Responsive being divided into different sections. One is, potentially,
your own app version. Another one is the
different devices that are experiencing
these kind of problems. And then third is the
different API levels. And you might also want to have
a look at the user feedback– whether positive or
negative– depending on the device as well. And this is the kind of workflow
that I would go through. So the first thing
that we’d do is– I want to have a look at– are there any
particular device that is causing a lot of crashes or
Android not being responsive? And if it is, I would look up,
what is the screen density? Is it actually API? Or is other different
screen size or density? Once I get that, I
will launch an Emulator that matches that and
just do a sanity test. That’s usually very quick– much, much faster than me
going down to the device lab and checking a device out. If it’s not that, the
next thing that I would do is to look at the API level
and see whether the crashes is actually caused by
differences in behavior of the different API levels. While the Emulator, we think,
is of very high quality, there are always
instances where you do need to go back
to physical device. But, hopefully, what
we have done here in this session is
to convince you– the Emulator is
actually your first port of call in this diagnostic. And to hear more from
the Google Play team about how to use
the latest Android vitals to improve the quality
of your apps and games, on Thursday at 2:30,
we have a full session to go through all the new
features and existing features. So with that, let me
hand it back to Sam. SAM LIN: Thanks, Hoi and Frank. So that’s a lot of
information to remember. And I bet you guys
remember it all, right? Just kidding– so let’s recap. First– Android Emulator
is pretty fast now, so you can actually get
your tests done quickly. Secondly, Android
Emulator is pretty close to a physical device. So you can do most of the
tests with it with confidence. Finally, Android Emulator
is pretty flexible. It will help you to
validate different APIs, different screen
compilations quickly. So, with that, we
believe Android Emulator can be your go-to device
for application deployment. One thing we like about
Android is the open platform. Just like internet– permission
list- innovation is possible. That’s why we want to build
Android Emulator to help. The new opportunity– only
possible because a user like you actually creates
a new way to help the user. So hopefully, this will
help you to find a new way to use Android Emulator to
improve your productivity. Thank you for coming. And enjoy the rest of I/O. [MUSIC PLAYING]

Only registered users can comment.

  1. Much needed change. The emulators are really slow. I always use a physical device to debug my android app. Wonder how much of memory is consumed by the emulator!! Good job guys. Can't wait to test my apps on an emulator. Just downloaded the android studio.

  2. Really like the headless emulator. Also makes it easier to run some emulator somewhere to make automated screenshot on any CI!

  3. Hi, would like to try this out. Which version of the emulator is it? I can't see the options you mentioned in my emulator (Android Studio 3.4) etc.

  4. Very good features, but i am waiting for something like, you can switch to any android version device within an emulator, like you don't have to download the versions specifically, because it will take a lot of space and time.

  5. to me is incredible how fast the native Android emulator is nowa days. keep the good work guys. much appreciated 😀

  6. Snapshot, running integration tests on multiple devices and headless emulator are interesting to know. Thanks!

  7. Most of the performance / stability issues I'm still experiencing with the emulator are probably caused by my CPU not supporting some profile expected by the specific image used.

    That said: can you give a clear recommendation on the kind of PC / laptop to be used for Android development and which server requirements are suggested to run the emulator on a CI environment? (For example we use Docker images in our CI and I just couldn't make the emulator work in an acceptable way there)

  8. I really appreciate the effort by the Team but there are so many unnecessary features in the Emulator which causes a painful experience to use on low Ram PCs. I wish the emulator was more like iOS Simulator or Emulator should provide an option to developers which features they want in the emulator and developers can keep adding features according to their needs. No need to make Emulator same as the Pixel device.

  9. Now if only the camera emulation wasnt terrible and unusably laggy. Besides that though emulator runs great now and even plays nicely with me shutting my mac books lid.

Leave a Reply

Your email address will not be published. Required fields are marked *