Importance of Natural Resources

Emulator in a Continuous Integration (CI) Environment (Android Dev Summit ’19)


[MUSIC PLAYING] HOI LAM: So I’m Hoi, and you can
follow me on Twitter @hoitab, h-o-i-t-a-b. And this is Frank, tech
lead, engineering lead for android emulator LINGFENG ‘FRANK’ YANG: Hello. HOI LAM: Cool. I thought, before we
start, I would just like to highlight some
of the improvements that we’ve made since Google
I/O on the Android emulator, in particular, three different
features that we have launched. So the first one
is multi-display, the second one is Google
Maps integration– it sounds a lot more
exciting when you see it– and then, last, but not least. ARM emulation, something brand
new that we want you to try. So the first one
is multi-display. At Google I/O, a
lot of you would have seen our new enhancement
to enable foldable testing. And this is really taking
it to the next level. You can attach up to
three external displays to the Android emulator, so that
you can now basically check out what the apps look like in
those particular devices. Second– and this is my
fave feature of Google Maps integration– previously, when you’re
trying to get somewhere with your Android
emulator, you need him know the latitude
and longitude. And then you look it up
and type in a really long no that, I have to say,
is not intuitive to me. But now, you could
just go in and just use search for any
location on Google Maps, and it will take
you right there. And it doesn’t just
stop there as well. The second thing that it does
if you tell it two locations, it can actually plot a route. And you can play it back at
up to five times the speed. So now, there is no excuse not
it has your location-based app in an android emulator. Yeah– [LAUGHTER] Last but not least,
the ARM emulation. So at first, I go, hey, is
this only for games developer? Actually, a lot of
you told us not. So a lot of you have
got ARM native libraries that you want to test before
you go onto a physical device. And this is now available
under the Canary channel, under Android P 32-bit. So we would really love for
you to check it out and give us feedback on this
brand new feature. And with that, I
would like to hand it to Frank for some live demos. Let’s switch over
to the demo sheet. LINGFENG ‘FRANK’
YANG: So I have opened over here a multi-display
version of the emulator. It’s running Android Q. There
is one extra display that has been created. I will demonstrate the
UI in a bit more detail. So we’re allowed to
press this button to add secondary displays. And basically, how this
UI currently works is, well, let’s just
first get some of the multi-display-related things
you can do on the emulator here out of the way. So you can open apps in
one window or another, and they can all run
at the same time. So one of the things
that I like to point out is that you can not only
pick from a preset set of resolutions, like
we have 480p up to 4k, but you can also change the DPI. So one of the side effects of
having this multi-display UI, aside from being able to
add and remove displays, is you can also changed the DPI. And so, for example,
I can change the DPI from 420, which is
what the current device is defaulting to, to 240,
and I can apply changes, and the system will
update dynamically. So, for example, if I launch a
different app, like, say, maybe Contacts. Maybe I pressed it again. But it’s basically that the side
effect of having mult-displays is that we dynamically adjust
all the aspects of a display without having to take another
snapshot or reboot the emulator or anything like that. So I just want to
put that out there. So that’s it for the
multi-display feature that I wanted to talk about. And the next thing is the
Google Maps integration. So in recent versions
of the Canary emulator, you’ll now have a Google Maps UI
that replaces the old location UI. So in the old location
UI, you had a field to enter the latitude and
longitude and points from a GPX or KML file. However, we now have
a Google Maps browser running in the emulator here. It operates in two modes–
single points and routes. So in single point mode,
you can press on a point, and you can set the location. So, for example, if I
want to go all the way into the middle of the Bay,
I can set that location. And if I ask Google
Maps what– oh, OK, it has to ask for permission. All right, fine. There you go. I’m in the middle
of the Bay, and I can go really fast over here. The other mode of operation– well, by the way, all
these single points can be saved and
played back later. The other mode of operation
that’s really cool is the routes. So I’ve set this
up in two places. So I have this navigation
from Shoreline Park to 1600 Amphitheater
Parkway, which is Googleplex. And I can play back this route,
and while it’s playing back, suddenly, my location is here. But this enables us to
do something else, which is I can follow the same route
inside the emulator itself. So in the emulator,
the Google Maps is now thinking I’m navigating,
when we haven’t even stepped outside. So it’s a great way to test
apps that rely on map data. And you get an easily set a
route and then play it back. In addition, you can increase
the playback speed to 5x. So we’ll just try that again. And usually, Google
Maps doesn’t expect you to go this
fast on this road, so it’ll look at you
look a little janky. But it’s definitely working. [LAUGHTER] Yeah. So that’s it for
the Google Maps API. So we want to stop
this now, I guess. And then there’s another thing
that I want to demonstrate, which is the arm translation. So previously, if you ran
into an app like this– this is the
endless-tunnel sample that contains a lot of native code. So there’s an entire
game written in C++. So all the game state and all
the game loop is running there. And what if I just compile it
only for ARM, what will happen? Well, in the recent
Canary channel, there’s images of an Android P–
system images– that give you both x86 and ARM
API compatibility in the same system image. This is done by leveraging
binary translation technology by Google. This translation
technology is much faster than the ARM system images
that do full system emulation. So to demonstrate, I
can pick between these. So you’ll notice that
the AVE parm, it’s the P image that has ARM and
x86 in one, and I can deploy it. But the other device
that I’ve been running Q, it will say that it supports
x86, but APK only supports ARM. And so the device
chooser already notices that we’re
potentially running something that is compatible with ARM. So we’ll just try to build this. Let’s see. OK. Get the build. All right. Yeah. And it’s working. And it’s running a lot
faster than typical for ARM system images. And it’s much closer to what
we expect from an x86 emulator. So that’s it for the
first round of demos. Back to the slides. HOI LAM: Yay. [APPLAUSE] LINGFENG ‘FRANK’ YANG: Thanks. HOI LAM: Excellent. And now, onto the main event
that you’re all here for, continuous integration testing. So when we look at
this problem, we thought of, basically,
two different aspects of the challenges that you face
in a continuous integration environment. The first one is what
we call deployability. You want the correct
version of the emulator, of the system image, deployed
and make the test reproducible, make the environment
completely contained. And the second one
is debuggability. So I don’t know about you, but
my code have a lot of bugs. When things
inevitably go wrong, I want to find out,
basically, what’s going on. And there are new tools
that is available to you. So earlier this month,
we published a couple of scripts on GitHub that
will help you basically build your own testing environment. And there are three
aspects to those tools in terms of deployability. The first one is a script to
help you download the latest version of the Android system
image, all the way from Android Lollipop and up. The second aspect is
to help you download the correct version of
the Android emulator in both Canary and stable. And last but not least,
we have a tool now to basically help you
publish a Docker image that contains both, so you
can always go back to it and reproduce your tests. As I said before, at the moment,
the system image and emulator are only available with
the latest version. You can, of course,
downloaded and basically put in a Docker image for
your own environment. But what we actually want
to do, going forward, is to actually enable
you to download legacy versions of both,
so that you can reproduce even historical tests. So yeah, you get
more reproducibility with your testing. The second aspect
is debuggability. So there are two tools
that are available to you when you deploy the remote
instances of the emulator. The first one that we all
know love is adb– yay! So you can kick off your
tests with adb, of course. and you can get
lockout messages. But what if those don’t
quite describe it? We have all done it
before, where we just do, hey, more LockDock D, and
just see what happened. But actually, there’s a
new tool that is available. And we’ve worked together
with our web team to enable WebRTC remote
streaming of your emulator. So now, you can
actually see what’s going on with your emulator
if things go wrong. With that, let’s
switch over to demo and see how it
works in practice. LINGFENG ‘FRANK’
YANG: So this demo will start by just introducing
where these container scripts live. So if you go to
gitrhub/google/android emulator container scripts with
dashes in between, then you’re going
to get to where we’ve maintained these scripts. So basically, these scripts
are structured as a way to generate Docker
images easily. This includes the
complete workflow from where do I even get an
emulator and a system image? Download them from the
SDK, packaged them together in a Docker image,
expose adb ports, and get WebRTC
streaming working. So there are some
requirements, like Python. And eventually, you
want adb at some point to communicate with the device. However, we do know that
there is a special requirement of requiring KVM acceleration. We’re aware that some users
aren’t able to do that, but we’re going to
work on that later. But mainly, this is for if
KVM acceleration is available. So the scripts work through
this emu Docker interface. So I type emu-docker -h. it’ll come with a
set of commands. They’re mainly around listing
where to find the downloads and creating the emulators. So if I type
emu-docker list, I get a dynamically-generated
list of all the currently released
systems images and emulators in the
stable and Canary channels. So this is not hardcoded. This is based off
of the same data source that describes the
current version of the emulator and system images
in the SDK manager. So this will always be
updated, every time you run it. We’re also aware,
though, that some users want to be able to freeze
a particular version of the emulator system image. And we haven’t really
put that in yet, but we do plan to do that. We know it’s valuable. So after you get a
list of downloads, there’s this convenience script
called emu-docker interactive, where it gives
you a menu listing all of the possible downloads,
and you enter a number. So, for example,
you can enter 43 if you want to download
the API 29 image, and 2 to pick the Canary emulator. I happened to download those
already, so it cached it, and the Docker image
is being created. This can take a while. But then, lots of things
happened to cache this time around, so it’s almost done. But when you do this, we
create a Docker image that will contain all of the
unnecessary dependencies on Linux for the
emulator, this can be often hard without Docker. Because sometimes you run
it on some Linux machines, versus others that have
different sets of system libraries. It can be really confusing
on which ones you need. And our Docker file that we
provide here is basically our current opinion of what the
system dependency should be. It’s captured there. So after the
container is created, there’s the possibility
to use Docker run to run these
containers directly. However, there are still a
little bit of extra setup that you need to do in
order to really do that. And that’s captured
in this run.sh script. So although we’re
using Docker run, we need some kind
of adb public key to communicate
with the emulator, and privileged for running
with KVM acceleration, along with publishing
to ports 5556 and 5555. So the first port
is to enable GRPC, which is needed for
the remote streaming. And the second port is
your standard adb port. And so I can then invoke
run.sh on the container I just created. So YAML is starting up
and0 everything from. However, in the background,
I have, in fact, started a different emulator. And I forward the adb port
over to my local MAC over here on port 5595. So adb devices, it shows
that there is a device here. And I’m looking
for the [INAUDIBLE] processes and activity
manager, and there’s nothing. That’s because it’s running
on the remote machine. And, in fact, it’s
also streaming via this WebRTC thing. So this is like a
standard web page. This is working using a TURN
server, connecting to HTTPS port on our server. At the same time, it’s
available as an active device. And so the log cap over
here that you’re seeing is actually from that device. Wait, hold on, that’s
actually not true. [LAUGHTER] I need to switch it over. Anyway, so I’ve
been trying some– so I’m taking some tests from
the Android testing samples. So part of these are
UI tests, and they do a lot of clicks and other
automated interactions. And it can be useful
to see what happens when you try to run these tests
on the emulator in real time. So I’ve started a test up,
and you see the test log on your local machine. But the test itself
is running remotely. And you’re able to see what’s
going on as it happens, which can be valuable in some cases. So yeah, the test isn’t running,
and we’re getting the log cap from the remote machine. And I think that
just about sums up what I want to demonstrate
for the container scripts. Back to the slides. HOI LAM: Thank you. Cool. Yay, that works! [APPLAUSE] The most important is to
select the correct emulator. [LAUGHTER] So what you have seen
today is two things. The first is we’re continuing
to basically improve the Android emulator infrastructure. And as I’ve said, the newest
features that we have launched is the ARM emulation. And we would love
to hear feedback from the community on
what works and actually, very importantly, what
doesn’t for you, so that we can continue to
improve that infrastructure. The second is around basically
setting up the engine emulator in your container’s
testing environment, in terms of creating
the [INAUDIBLE] image or remotely
debugging for WebRTC. My mind is still blown
by that functionality. I’m sure that I love you
would like to find out more about all of these, so we
have actually published– or actually Frank published
a blog on continuous testing with the Android emulator. So you can use your
favorite search engine to find this blog. [LAUGHTER] And with that,
thank you very much, and we’ll be available
for questions. LINGFENG ‘FRANK’ YANG:
Thank you very much. [APPLAUSE] [MUSIC PLAYING]


Reader Comments

  1. Just wanted to point out that the main problem is not debugging the emulator or how to deploy the correct version. We can't run android 26+ emulator on public CI like travis at the moment. FYI

Leave a Reply

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