[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]