XAVIER DUCROCHET: Good morning.
My name is Xavier Ducrochet.
TOR NORBYE: I'm Torn Norbye.
JAMAL EASON: Hi, and I'm
Jamal, and welcome to
"What's new in Android Studio."
So today we're going to talk
about three distinct features,
IDE enhancements, build system,
and the Android Emulator.
So first topic, the Android
Studio Enhancements.
So going back, at Google I/O
we launched Android Studio 1.3,
and there we launched a
whole host of features,
including the C++
editor, data binding,
and some new art new UI
around SDK management.
Over this past
summer and fall, we
worked on new vector
assets, new HPROF bug fixes,
and a whole host of other
features around Android Studio.
And today we are really excited
to talk about Android Studio
2.0 today at the
Android Dev Summit.
So features since
Google I/O 2015.
Before jumping into
some of the 2.0 stuff,
I want to recap some of the
great stuff we worked on
in the past few months.
So for instance, we
launched a GPU Monitor.
The GPU monitor allows
you to look at your app
as is performing on your device
and see the impact on the GPU
calls for your device.
We launched a network monitor.
You look at the input
and output calls
of your device on the network
while running your device
on either an emulator
or a real device.
App implants.
For the new App templates,
we took a real look at those
and added things like App
compact, design library
to help you get
started on a new app,
or add new enhancements to
a preexisting application.
Theme editor.
Theme editor was a way for
you to visualize your styles
and colors to XML, to get
a recap of how your look
and feel is going to
look for the application,
and visualize those tweaks as
you do your app development.
And Vector Asset Studio.
One pain point we talked
about at Google I/O
was about how to manage
your raster assets.
Previously you
would have to manage
10 to 20 different assets per
API level for your application.
Today you can import one of
the vector drawable assets
we provide for you from
the material library,
or you can import one
of your own SEG files
and place that in
your application.
And during build time,
we will automatically
generate all the
raster images for you
automatically, so you only
have to manage one asset.
And that's just an
example of a few things.
We have Lint checks,
better accessibility,
bi-directional support,
better test UI, a Logcat, a
and a whole host of things.
And we're still investing.
We're excited that
we're still working
on things to make your life
more better as an app developer.
With that, we'll jump
into the build system.
XAVIER DUCROCHET: All right,
thank you J. All right,
so let's talk about
the build system.
Before we talk
about Instant Run we
want to talk about just general
build system improvement.
Instant Run does
not always activate,
and so we still
wanted to make sure
that the build system would
be faster than it used to be.
So we know of a few
bottlenecks that I'm sure
very obvious to you, whether
it's dx or ProGuard or just
the installation process.
So let's go through
a few of those.
So the first fix that we did
was we improved the dx merger.
So when you build with
Android, with a Gradle
and you have a lot
of dependencies,
we're going to predict all of
those dependencies separately
running dx on each of
them, and then at the hand
we have a merge state.
Now, the algorithm them was
pretty bad, unfortunately.
It was a quadratic algorithm,
and so the more and more
dependencies that you have in
your project, the really slower
it would get.
The new one is linear.
If you have a large
number of dependencies,
just the dx merger step could be
at least an order of magnitude
faster.
It's available in 23.0.2, which
we shipped a few weeks ago,
so if your project is not
yet using that build tools,
you should definitely get it.
The second thing that we did
was we now run dx in process.
So I said we run a
lot of critics saying,
a lot of different version of
dx in parallel, and for each
of those we would
start a different VM.
And that means you have the
cost of starting the VM.
That means that
the JIT of the JVM
does not have time to
really optimize the code,
and then it's
really a lot slower.
So we changed that
in Plugin 2.0.
Also, it requires
Build Tools 23.0.2,
and it requires Gradle 2.4.
The previous version would
drop all the plug-in code
on every run, so that
would not actually work.
We recommend using
2.8 or 2.9 anyway,
but you need at least 2.4.
Simple set up, just dexOption,
dexInProcess equal true.
For now, it's forced by default.
We want to get feedback.
Make sure that there's no issue.
So let's look at some benchmark.
This is I/O schedule 2014.
There's about 15
or so dependencies,
maybe a bit more than that.
As you can see, both clean
builds and incremental
build are much, much faster.
So that's pretty good.
So on the left is the
old plug-in, the old dx,
and on the right is the
new plug-in, the new dx,
and dx in process.
Now, doing that
has some trade off
that you have to think about.
I'm sure some of you have
done something like that,
giving a few more memory to dx.
Now, what happens here
is that every call to dx
will actually get two gigs.
So if you're predicting
four different libraries
in parallel, you have four
dx running in parallel,
and each of them gets two gigs.
And all of them will
be in the same JVM,
so you will need
to give probably
a little bit more memory.
The other thing to think
about is that this,
when we toss that in
your build of Gradle,
the Gradle JVM has
already started,
and you cannot change that
after the fact, right.
So it's only to control
external process.
So if you have that
right now in your
build of Gradle, when you
switch to dx in process
that won't do anything.
You have instead to
change Gradle properties,
give it more memory.
You may already have done that
because ProGuard is already
in memory, and ProGuard some
times requires a lot of memory.
So you will have to
play with that value.
It may not be exactly,
like four times what
you gave to dx before because
there's different overhead,
but you should play
with the number.
Do realize, though, that this
is long lasting in the daemon.
The daemon has a
three hour time out,
so this memory will
be used all the time,
while before dx was really
to fire and then forget,
and the JVM would disappear.
Still, it's a very
big speed gain,
so you should definitely try it.
Right now we run up to
four dx in parallel.
You can control that through
an environmental variable,
android.dexerPoolSize.
Give us feedback
on the number that
works for you, the memory,
and things like that,
and we may tweak the
default values later.
The second bottleneck I want
to talk about is ProGuard.
Now, ProGuard works great.
There's no issue.
You know, if you're running
it for your release process,
not a problem.
The problem starts
happening when
you have a really
big application
and you have more
than 65K method,
and you need to shrink it
below the actually limit.
So when you do that, you need
to run ProGuard on every debug
build, and it's slow.
The main problem,
it's not incremental.
And a second problem is
it disables PreDexing.
And by that, I mean that
when you run ProGuard,
the output of ProGuard
is a single jar, which
means that you have to
re-dex the whole application
and its dependencies every time.
And so we really
wanted to fix that.
So we've been working
on a new shrinker.
It's experimental right now.
The big thing is that it
has some incrementality.
But the big thing, really,
is that it unables preDexing.
So if you have, let's
say, your main application
plus 10 dependencies, the
output of the shrinker
will be 10 dependencies, or 10
jars, plus a jar for your code.
And even if the shrinker has to
do a full non-incremental run,
it doesn't really matter.
If it only touches one
of those jar files,
the other nine jars
will be the same,
and Gradle allows
us to just say, hey,
those jars are the same.
I don't need to re-dex them.
I already have dexed
them somewhere.
And that's again
a big speed gain.
This is only a shrinker.
Our goal is not to
replace ProGuard.
So the configuration
is per-variant.
It doesn't do a obfuscation.
It doesn't do it optimization.
It's only a shrinker
for debug mode only.
And the other thing it
will allow us in the future
is to do legacy multi-dex
faster, as well.
Right now, if you first
shrink with ProGuard
to get below to 65K limit,
but you're still above it,
you have to enable
legacy multi-dex,
if your main SDK
is less than 21.
So in that case what
happens is the process says,
hey, we run ProGuard
a second time.
Because it was slow the first
time, so let's run it again.
And so here, because we control
the code of the shrinker,
it's easier to keep the graph
of dependencies and method codes
and things like
that, and actually
run shrinker and multi-dex
at the same time.
So that will come later,
probably after today
though, we want to stabilize
first the shrinker for 2.0.
It's not actually
available right now,
in alpha, one of the plug- in.
It will come in the next
plug-in in a few weeks.
This is how you
enable it, so you
do have to unable minify still.
Within debug, you would
say, useProguard false,
and in release you would
say useProguard true.
Actually, it's true by default,
so you don't need to say it,
but this is what
would happen here.
The results.
So if we look at
here, the first thing
I want to mention, just to
go back to the dx merger,
if you compare the clean
build on the first column
and the clean build with
shrinking on the first column,
you'll notice that, hey,
running ProGuard is faster.
That's because,
again, I said ProGuard
disables merging of dx, and
dx being so bad at merging,
it's actually
better not to do it.
But anyway, we fixed that.
So on the right
column, you can see
that we're quite
faster than before,
almost two x, and that
is running the shrinker
in a non incremental way.
So as soon as there's a change,
we re-run the full shrinking.
If we run it actually
in an incremental way,
it's something that is
not completely there,
so I do not want to
show the numbers,
we get a little
bit faster, again.
So if you compare
on the left side,
basically doing a clean
or an incremental build
was just basically
not different,
and here we can get, hopefully,
at least twice faster
than a clean build
for incremental.
So that's quite good.
So that's the changes
for actually building.
Now we want to talk
about deployment.
Deployment is slow.
We know ADB is slow.
So we talked about
it a little bit
yesterday during the keynote.
We'll have a new ADB
push/pull protocol.
Much faster throughput.
It's coming to the emulator
soon, and with some system
image, at least API 22 and 23.
And we'll backhaul that later
to two more system images.
So deploying faster is great.
What we want to do also
is maybe push less.
We have a new
mechanism in studio 1.5
that you may have noticed, where
when you click the run button,
we first ask you where
you want to deploy it to.
And then we build,
and then we deploy.
And before we would do first
build and then ask you.
So this is something
that is not related
to what we wanted
to do, but since we
are doing that now, we figured,
hey maybe we can do something.
So as a first proof
of concept, we
decided to do it to
target specifically
for your device in
term of density.
So if you plug a
device with MDPI,
you know, wide package,
XHDPI wide package, XXHDPI
and all of that.
So APT does that for
us in a very smart way.
So if there's some assets
that you do not have in MDPI,
it will package in
all the density,
basically like the
device would choose.
Right, if you have a device
that has a density, when
you don't have those assets, it
finds some other assets to use.
So here we don't gain
a whole lot, only 10%,
but this is still useful.
But we do want to extend
that to more things.
So the things that we want
to extend to, for example
are ABIs.
If you deploy to an X86 device,
why build and package on code?
Let's not do it.
Right, so we'll do
that next, and that
would be for people who have
native code, a big gain.
And then we want to do
that for multi-dex as well.
It's not really packaging.
It's more building this time.
Right now, we tell
you, hey, if you
have to use legacy
multi-dex and you
want it to be faster, create
a variant for minSDK 21
and above, so that when
you deploy to, let's
say, a marshmallow device
it uses the native multi-dex
rather than the legacy.
So here we're
basically going to be
able to do that automatically.
If you plug at 21, it will just
build it with the native one.
You unplug it, you
plug a different one,
and it will use the legacy one.
That way you don't have to think
about changing the variants
and deploying the wrong
variant to the wrong device,
and all of that will just
take care of that for you.
OK so, we saw a building,
we saw deploying,
now you have to install.
So I took this small
little app, right.
IO schedule five meg.
That's not really big.
And I try to install
it on my Nexus six,
and the install was 12 seconds,
which is just 12 seconds.
It's awful.
I mean, we have
before and after.
Right, it's like we made
some really good progress
on building.
2.4 x.
That's awesome.
And then we add installation,
and it's just bad.
So 18 x is better than 28.
Sorry, 18 seconds
is better than 28,
but it's still
just way too slow.
So we wanted to fix that.
And so that's why
we did Instant Run.
We really wanted to change the
whole deployment cycle from end
to end.
Not just focus on building,
but look at everything.
And we wanted to do that
in a way that worked
on all the devices as well.
So Instant Run.
What we want to do is we want
to deploy as little as possible,
so only what changed.
We want to avoid installing,
because as we just it's 20
seconds, or more if you have a
much bigger application, right.
It could be a lot more.
And while we're at
it, let's just not
kill the app whatsoever, right.
TOR NORBYE: So to
avoid killing the app,
it's not always
possible if you made
a completely structural change.
But when we can
leave it running,
that's what we call hot-swap.
So the app is just running.
If we have to mess with your
app in more significant ways,
but still leave it running,
that's what we call warm swap.
So a resource change
will trigger a warm swap.
Cold swap is not in
the preview build,
but that's where we
restart your app in order
to make bigger
structural changes so
that your objects have changed.
And of course, the last one
is full rebuild and reinstall.
If you change something,
for example, the app icon,
we're going to have to do this
because obviously your launcher
wants to see the icon.
We can't deal with that.
But rebuild and reinstall
is where we are today before
and Instant Run.
XAVIER DUCROCHET: So let's
see what happens, actually,
when you do a full regular
build with Instant Run
because we have to
prepare your application.
If you take a regular
application built with an older
version of Studio, we can't just
go and replace stuff on the fly
there.
It's just not going to work.
So the first thing
that we started doing
is, when you build it
with Gradle from Studio,
we kind of do something
a little bit different.
So we call Gradle with and
additional property saying,
hey, you're in
that special mode.
And in Gradle we
create additional tasks
in order to do more
work than if you
build from the command line.
So we'll do bytecode
instrumentation,
we'll add a server to you app
so that you can talk to it,
and things like that.
So let's look at
what it looks like.
This is a very simplified
version of the build steps.
Right, we have the
manifest merger
that generates
the final manifest
that we packaged
with APT, and then we
have the Java CDX flow where we
just compile and convert code.
So the first thing that we
do is we stop feeding dx
with regular classes.
So we have a new API
called Transform API,
and I'll talk about
that in my other talk
on the Gradle plugin.
And so we're going to do that
bytecode instrumentation,
and we're basically going to
add a level of indirection
to every method and
constructor in your code
so that we can go and replace
stuff on the fly later.
Then, I mentioned we need
an app server because Studio
will talk directly to the
app, so we add that code
to your app.
And then we just
send that to dx.
In order to actually
start the server
and add some custom classloader
and things like that,
we actually have to
change our manifest.
So we actually
instrument your manifest.
We add stuff to it, and we add
a new custom application class,
and then we actually need to
add that particular application
class to your code.
And that, if you have already
your own custom application
class, the one that
we use will proxy
and delegate to yours so
that it's transparent.
You don't have
anything to change.
That was one thing that
we really wanted to do
is, as a developer, you
shouldn't have to go and hack
the code around to make the
app work with Instant Run.
It should just work.
And then the final
thing that we are doing
is, in order to make sure that
the connection between the app
and Studio is valid,
we generate a build ID
on every build to
make sure that we
know what the current state is.
TOR NORBYE: So when you are
hitting the Run button in ID,
this is what happens.
We first make sure that you're
actually using Gradle 2.0.
And then we check the
build IDs I have just
mentioned to make sure that the
device and Gradle are in sync,
because if they're
not, if you run
your device on a different
development machine,
it could be really, really
bad if we put the wrong bytes
on there that are incompatible.
Then we make sure that we
can actually talk to it,
so we use a socket
connection to the app.
And then we check, is the
activity in the foreground?
And if all that's true,
then we run Gradle.
And Gradle is run with a
different task which basically
would build up the dex files.
It then runs a verifier
which makes sure
that everything that
you've done in your code
is compatible with a hot-swap.
And if it is, of course
we can do a hot-swap,
otherwise we will
do a cold swap.
And the other thing
we do for optimization
is to monitor the files
you're editing in the ID.
And the reason
we're doing that is
that that allows
the Gradle plug-in
to do certain optimizations.
They're not
technically necessary,
but we're really looking
for latency avoidance,
and so if I've noticed that
you've only touched Java files,
we don't have to touch
the resource task.
Or similarly, if you've
only touched the Java class.
Anything you want to add?
XAVIER DUCROCHET: So right
now we only support hot swap
in the main module.
We'll add that to
the sub-module.
But one of the
optimizations that we do
is, if you change the
code in the main module
and you just ask
Gradle to build,
it doesn't know anything
about the state.
It doesn't monitor the
file change at the moment.
And so it's going to try to
build all your submodules,
which will be up to
date, but because it
doesn't know anything it
has to go and make sure
that all the files
haven't changed.
And if you have
dozens of modules,
that can take a lot of time.
Now, if you actually
run it, you will
see up-to-date, up-to-date,
up-to-date, up-to-date
and nothing change,
and that's good.
But it can still
take some time if you
don't have an SSD, if you
have slow IO, whatever.
You know, that's going
to take a lot of time.
And so, Studio knows.
Studio tells you, hey, only
the main module changed,
and then we just, same thing,
add the Gradle plug-in.
We will just stop
asking to build those,
and then we won't even
do the up to date,
and then it's much, much faster.
So this is what happens once
you get the actual file.
So here you have Studio on
the left and then Gradle,
and then on the right, you
have your app, it's running,
and it has a server
and it has that class
that we just touched.
So we call Gradle, and then
here, it's a custom task.
It's not a regular
assemble debug
that you would normally use.
And we created a dex
file that contains
only the classes that change.
It could be one, it
could be two, depending
on how many you change.
Then Studio grabs that,
sends that to the app server,
which gets ready to use the
custom classloader to just load
it.
Now, the thing that's important
is that when we load it,
we don't actually load the same
class that you actually wrote.
The classes there, we
can't replace them.
So what we load instead
is a special version,
and that special version
is created by Gradle itself
during the bytecode
transformation,
and it's just an override of it.
And then the app server will
just basically modify the class
here on the left to
delegate every method
call to the override.
And that's because that
version of the class
is a special version, as I
showed in the first graph
where we had that
bytecode instrumentation.
We go and we add that
level of indirection,
so here the app
server just makes
the connection between the
original class saying, hey,
now when we call that
method just go and call
that version instead.
TOR NORBYE: So for
resource changes,
we're currently relying on
sending all the resources.
So we have to run APT.
So if you have an
app that's really
large with lots of resources,
it's not going to be instant.
So the instant run feature is
really after the hot-swap case.
But there is a
incremental APT under way
that's going to really
help with this a lot.
And we have some
short term tricks
we're going to do,
too, to send a smaller
portion of the resource file.
And once we send
it across the wire,
we then use reflection
hacks-- and I
think there's no prettier way
of referring to it-- to actually
make that running app
restart activity and apply
the changes you made.
There are some limitations
to resource changes.
If you change for example the
app name or any resource that
can be referenced
from the manifest,
we know we have to
trigger a full rebuild.
And the other thing is that
until the preview build,
we had some special
optimizations where the R
class was treated specially.
So we would exclude
field checks for them.
But we saw some crashes,
so to be on the safe side,
if you have any ID
changes as well.
So if you drop in a new
button in the layout editor,
that's going to put an
ID for you by default.
Or even if you have +
IDs, and you reorder them,
that will change the
values in R class.
So those things right now
would trigger a restart.
And so for cold swap,
this is something that
is not in the preview build.
We'll demo it shortly.
But that's when you have
an incompatible change.
So you've added a
field, which currently
is an incompatible change.
And we're working
on basically making
that be not a full rebuild,
which it is right now.
XAVIER DUCROCHET:
OK, so there's a lot
of things happening
under the hood.
Bytecode instrumentation,
replacing class on the fly.
But we wanted it to be as
easy for you as possible.
The user interface for Instant
Run is just like the Run button
that you've used before.
So the goal is that
Studio knows whether we
can do Instant Run, whether we
can do cold swap, warm swap,
hot-swap, anything.
You don't have to
think about it.
If there's a little
lightning bolt
right next to the
Run button, then you
know that you'll
have Instant Run.
But just keep pressing that
button or using the shortcut,
and it will just happen.
And hopefully, the
best scenario will
happen without you
having to do anything.
Now, because we talk
directly to the app,
and we send stuff
on the fly, you
could be in the weird situation
where we replace some code,
but because the state can be
weird, there is a stop button.
So if you do that,
it will kill the app,
and then on the
next run it will do
a regular, hopefully
cold swap at some point,
but for now a full reboot.
And then you have a shortcut
also to restart the activity.
There's some cases
where we replace stuff,
but we can't actually apply it,
so we have a shortcut for that.
TOR NORBYE: All right demo.
Can we get stage two.
All right, so here
is an old project.
You can see it's using the
ancient Gradle plugin 1.5.
And if you bring up
the preference panel,
and you go to the
Instant Run settings,
you can see it's
telling me right
now that I don't have
Instant Run because I
need to update my project.
What that will do is it
will update to Gradle 2.0,
but it will also give you
build tools 23.0.2 which
isn't necessary, but really
it's going to be much faster.
XAVIER DUCROCHET: Yeah,
you should use them anyway.
TOR NORBYE: And
Gradle plug-in 2.8.
All right, so here
I'm going to switch
to a different project, a Topeka
sample app, which I've already
run on the device.
So let me show you some
of the Instant Run stuff.
The first thing
we can do here is,
we can change some resources.
So see it says
sign in at the top?
Let me open up the
translations editor
and find the sign-in
string, and we'll just
change it to welcome, sign in.
And if I hit the
Instant Run button,
it now performs a
incremental build,
it grabs the whole resource
file, and it sends it over.
And it restarts the activity.
You can see it says,
welcome, sign in, over here.
If I switch to the theme editor,
I can make non string changes,
too.
So let's for example go and
change the primary color
to material red, material pink.
We'll do red.
And we can also change
the status color
for the device, which I thought
was-- now I can't see it.
There it is.
So we'll switch that
to let's say this one.
And again, if I press Instant
Run, it packages the resources,
the app is still running,
and it applies those changes.
So let's make some code changes.
So if you look at this
grid of icons over here,
the number of icons is dynamic.
It is based on the size
of the avatar icons
and the size of the screen, and
it's done by this method right
here, calculate span count.
I can just go and
change this code.
Let's say, just hard
code it to three for now.
And if I press Instant Run, you
can see that nothing happens.
And you can see that it
was saying in the toast,
we've made this change
for you, but you may
want to restart the activity.
And that's because this
code is only run on create.
So just because I've
hot-swaped, that
doesn't really make the
change visually appear.
But there's also a
bubble we're showing
in the bottom left
corner here, saying, hey,
you haven't restarted activity.
Would you like to do that?
It's telling you what the
shortcut is for doing it.
We can also configure
it by options.
First of all, I'll
turn the option on.
But I'll also just apply
it manually right now,
Control, Shift, R. You can
see we have three columns.
And now if I switch it to four,
for example and press Control,
Run, you can see
it's nearly instant.
Right, four columns.
So that's basically the
hot-swap case, and the warm case
with the resources.
Now I'm going to
show you cold swap.
So cold- swap is not
actually enabled,
and the reason for
that is primarily
that it's really, really buggy.
So you can see I have an
option here called demo only,
and that's because this is
not available in your build.
But I'm going to show you
what it does when we hopefully
get it working.
So let's put the real code back
in, and let me do some method
extraction here.
So I'm going to actually
extract this whole line.
We'll call it get avatar size.
Oh, and the IDE
noticed, hey, this
is a pretty generic method.
Let me try to
generalize that for you.
So now it's basically turned
it into something different,
which I'll call, get dimension.
And then we'll extract
this expression over here
to calculate columns.
So now we have some
structural changes.
And because I turned on
cold swap, if I hit run now,
it's going to kill the
app, and restart it.
But it's not doing a full build.
You can see it's the
little bubble saying, hey,
method added.
We couldn't really restart it.
But now the app is
back and running,
and it's running the new code,
although it's the correct code,
so let me change it to prove
that this new method can
do the right thing.
So Instant Run, two columns,
from the new method.
So that's cold- swap
which hopefully we'll
get working soon.
The last thing I want to
show you is data binding.
So data binding, also broke
for the preview build,
we have it working in
the [INAUDIBLE] again.
Actually, let me just
run it first of all.
So this is a sample app I
found in the data binding code
repository.
I don't know what the app
means, but it has some buying
expressions I can show you.
So while that's starting,
let me show the stuff
we have for data binding.
This is not integrated
in the preview build,
but we've finally,
you could say,
added code completion for
expression language stuff.
So here, not only can I
navigate between symbols
and into methods
and data objects.
We also have full
code completion here
on all the attributes
and all that stuff.
So that's nice.
So as you can see
in this app here,
we have uppercase characters
in some of these name cards.
If I were to change this to
lower case, and do Instant Run,
you can see that, hopefully,
soon it applied the change,
and you can see
it's now lowercase.
So data binding is working
too, and that will hopefully
make data binding and Instant
Run work really well together.
And that's it for the demo.
[APPLAUSE]
JAMAL EASON: All right,
so Android emulator.
So we talked about
the Android emulator
at the keynote
yesterday, and we really
wanted to invest time and
effort into the product
because we knew, we use it
all the time as a developer,
but it hasn't been as great as
we wanted it to be as a team.
So the two things we worked
on, first is performance,
and the second
thing is usability.
And we think of performance
in three different ways
for the emulator, it's
around CPU, GPU and I/O.
So for CPU, what we added to the
emulator is multi-core support.
What it allows you to do
is that you can actually
process your apps faster,
install them faster, and get
a more performing
experience in the emulator.
For GPU, we've had a
strong offering so far,
but we added additional
GL calls so you actually
can support more
GL applications,
and get a more performing
experience while using open
GL ES.
And the third column we
added is I/O. So Xav touched
on ADV push speeds, but we
also looked at the I/O speed
on the actual virtual device.
In itself it's like a
little mini hard drive.
We actually improved
that very dramatically
in order to improve things like
install time and processing
time.
So let's look at some
data to highlight
that particular data point.
And so we looked at
the Google Play Store
and tried to find
the biggest app
possible to kind of highlight
this particular scenario.
We found one.
It's about 45 megabytes.
It's quite extreme.
Most developers don't
have apps this big,
but lets us use
this as an example.
So in the past, the
emulator 1.0 would take just
under 300 seconds to install
and push that application.
Most of the time,
as indicated by Xav,
is actually on the install part.
In a few seconds, you can
push it across the wire,
but it takes a long
time to process.
That same application
on the Nexus 6
was just under 150 seconds.
That's OK.
But we thought we
could do better.
So they Android
studio emulator 2.0,
we're now just under 45
seconds for that same push.
[APPLAUSE]
So usability.
So again, the emulator has
been around for some time.
We've had a lot of great
features, but most of them
have been under command line.
Not very easy to use,
not very intuitive.
Again, if you're trying to
develop your application
and try out different
scenarios, it's
very difficult to remember
some keyboard shortcut-- we
have shortcuts now, but remember
some archaic ADB push command,
or some command just
to get your app running
or to try out some scenario.
So we decided to invest on
a new UI to address this.
So let's jump to
stage one demo please.
OK, perfect.
So this is the new UI
for the Android emulator.
We showed a little bit of
this at the keynote yesterday.
So of course, here,
let me just open up
Google Maps here in my recents.
All right, so as before, you
can use the emulator to type
in directly into the
UI for quickly typing.
So let's go to New York.
And again, with open
GL we can quickly
render this really quickly with
the UI to render all the maps.
But in addition to just allowing
you to enter in GPS points,
we've also allowed you
to import KML files.
So here in the right hand side,
I have a table of GPS points,
and this right now
is a path I want
to test out for my application.
So let me turn on the GPS
location here on the emulator,
pressing the blue button here.
Let me speed this up
to two x for the demo
here, and press play.
And what's happening now is
that I'm now pumping in points
to my emulator.
This is actually the Googleplex.
And you can kind of move
through the emulator experience
and kind of repeat that
process for applications if you
use location in your emulation.
Cool.
All right.
All right, so moving on to the
next tab is around cellular.
Now, some developers
have asked about, hey,
how do I have some
way to control
the speed of my network.
So let me just kind of
zoom into the top here, OK.
So you can control
here the network type.
I want to change it to 2G.
If you notice here
under no vacations,
it's currently
saying a 3G Android.
Changing this to Edge
will change this to 2G.
We can change that
to E for edge.
Let me pull that back to
full for this demonstration.
Or if I want to change
things like, hey,
what happens if I'm
roaming, I can quickly
change that on my
data connection.
That changes from an E
to an R for that icon.
Or if you want to
see what happens
with an application that has
no service or the SIM card's
out, how do I simulate
that situation.
And here I can simulate that
on the cellular tab as well.
Again, this is just
to help you out
to figure out your
different data connections
as you're testing
your application.
[APPLAUSE]
OK, so moving on to battery.
So battery, here-- let me
just open up battery here
in this UI.
Great.
So as you can see here, I can
move the charge level here
with the UI.
That's straightforward.
I can say, hey, I want
it to be charging,
can be in AC, or not charging,
so I can change the state.
That's moves it to not charging.
So straightforward
there, just a way
for you to toggle that if
your app uses any battery
kind of configurations,
we now have a UI for you
to manage that as well.
Great.
All right, so now
moving on to phone.
So at the keynote
we talked about,
you can actually receive
phone calls from the emulator.
That's what your app does.
But we also can
send SMS messages
if that's what you
need to test as well.
So in this case, I sent
myself a text saying, hey,
don't forget the marshmallows.
That's great.
We'll come back to that.
So let me go back to sensors.
So at Google ILS past year,
we talked about fingerprint.
And fingerprint is a way
for you to authenticate
your application either
for payment or for security
for your device.
And we've added that feature
into the emulator itself.
So if you go under settings,
we have fingerprint here,
under Security.
Great.
Fingerprint.
And here we can ask you
to add a fingerprint
to unlock your device.
You can click Continue here.
And use a pin to
super secure for once.
Great.
All right, and then we have
this fingerprint tab here.
And what this
allows you to do, it
has 10 input points for
10 fingers on your hands.
And let's say I wanted to use
my finger one, touch the sensor,
boom it's authenticated.
Now you've added fingerprints
into your device,
and now you can use this
for testing for fingerprint
for your applications.
OK.
Great.
So a last few things here.
So on settings, if
you don't like dark,
we have the ability for you
to switch to a light theme.
If that's your option
here, so we go to lights.
That the light theme
of the emulator.
So you can see how that works.
My personal favorite is dark, so
I'll put it back to dark here.
All right.
And then we're just going to
close this extended controls
here.
So we talked about the
drag and drop capability.
In addition to being able to
install APKs drag and drop,
we also allow you to
install media files.
So let me go to my SD card.
And let's go to download, here.
Let me rotate, because
rotate's also available here,
which is great.
So I can rotate
that very easily.
Let me resize this so you
can kind of see this together
on one screen.
OK.
So I have a picture here I
wanted to get on this device.
So I can simply drag this
on to my emulator window,
and there you go.
So this is my picture.
[APPLAUSE]
There.
OK.
All right.
So then let's go
back to the SMS here.
So I sent myself
that text message.
So let me just rotate
this back again.
So let's back to this.
All right.
And let's go to that message.
Here we go.
Right, so there is that
text I sent to myself.
All right, let's make this
a little bigger here so
everybody can see this.
Great.
You can resize up at the corner.
And again, with a keyboard,
I can just type messages here
on the keyboard.
And so, then, lastly,
I will say thanks
for coming to Android
Dev Conference.
Cool.
Spell check's also
included here.
Great.
Conference.
And send.
That's it.
Great.
[APPLAUSE]
Let's switch back
to slides, please.
So we talked about a lot
of different features
here at this session.
And so a few things are
going to be available now.
So things like the dx
merger, Instant Run
is available today in
the Canary channel,
and coming soon we're adding
the shrinker, the emulator,
and APT.
Actually, APT is coming
later on in a few weeks.
And so with that,
I think that's--
XAVIER DUCROCHET: We
have time for questions.
JAMAL EASON: We'll
have questions.
So questions.
TOR NORBYE: I think
we're supposed
to tell people to line up.
There's some mics over there,
so you need to go to the mics
so that everyone can hear.
AUDIENCE: Hi, my question is,
can Android emulate Android
wear connectivity to the
Android phone emulator.
JAMAL EASON: Yes.
So if you load up and Android
wear AV with a device,
we automatically simulate
that Bluetooth connection
so you can send messages
between your Android
wear and the device.
AUDIENCE: Thank you.
[APPLAUSE]
JAMAL EASON: Hi.
AUDIENCE: Do you know if you
can modify the Network setting
in the emulator so you can
point to a proxy, a local proxy,
if you wanted to use
like Charles or something
like that to sniff
network traffic?
JAMAL EASON: Do you want
to say that one more time?
AUDIENCE: Point a Wi-Fi
connection on the emulator
to a local proxy so you
could sniff network traffic,
like using Charles proxy
or something like that.
JAMAL EASON: I don't think so.
Look talk afterwards.
XAVIER DUCROCHET: We
don't have Wi-Fi emulation
because there's only
one network connection
on the emulator right now.
It's something we're
working on, so right now
you only have basically
the network connection.
But it's something
we want to fix.
AUDIENCE: Cool.
Thanks.
TOR NORBYE: Let's
go to this side.
AUDIENCE: You mentioned better
GPU support in the emulator.
Which versions of the
S can we play with now?
JAMAL EASON: So we're
shipping with OpenGL ES 2.0,
and we're working on 3.0.
AUDIENCE: Thank you.
AUDIENCE: Is it possible
to run the Instant
Run from the command line?
TOR NORBYE: No.
The reason for that is that
a lot of stuff we're doing
is there, in particular
the socket connection,
is from the IDE,
not from Gradle.
So the IDE is really
central Instant Run.
A lot of the tasks you see, like
actually preparing, performing
the incremental dex
file creation is done.
Just looking in the Gradle
console to see which task's
running, plus that
command line flag
that was in Xavier's slide.
But no, you need the IDE.
AUDIENCE: So I have
on more question.
It's about the emulation.
Is it possible to
simulate a SIM card?
JAMAL EASON: We are going
to add the SIM card soon.
AUDIENCE: Thank you
XAVIER DUCROCHET: OK
AUDIENCE: On the NDK
side, when will you
be adding support for
building static libraries
and native only libraries
from Android Studio?
XAVIER DUCROCHET:
I'll talk about it
a little bit in the
next talk about Gradle,
but we just added [INAUDIBLE]
support for modules that only
build native code,
and we also just added
intermodule dependencies
because the NDK is
built on the new version,
new APIs on the Gradle side
to do plugins.
In the previous
version we didn't
have intermodule dependencies
because they handle that
differently.
So we have intermodule
dependencies,
and there's an option
to do a static linkage
between different module.
So you should be
able to do that now.
AUDIENCE: OK.
Thanks.
AUDIENCE: So the Android
emulator currently
supports doing
fingerprint by touching,
but it really only
supports happy path, i.e.
You either touch
finger one or two,
and not any of the, like,
finger move too fast,
or some of the error scenarios.
Is there are any
plans to add that in?
JAMAL EASON: Yeah,
so it's not going
to be in the initial
release for that,
but we are planning to add more
fingerprint test conditions.
AUDIENCE: Thank you
AUDIENCE: Also only emulator,
is there any support
for other device sensors?
Accelerometer,
gyroscope, ambient light,
any of that kind of stuff?
JAMAL EASON: Yes, so
that in a future release.
We didn't show that today,
but definitely it's on the run
up to get that out.
Yep.
AUDIENCE: I was wondering,
for the connectivity settings
on the new emulator,
is it possible to
simulate partial or
total packet loss?
JAMAL EASON: So there is
a data drop connection
that's on the emulator.
It's OK.
We're working on creating a
more enhanced version of that.
But today you can say, I want
to like degregate to 2G network,
and you can simulate
that situation today.
AUDIENCE: So you showed a demo
that simulated the location
changes.
I'm assuming that's intended
for the geo-fencing API,
testing that out.
And you also mentioned
the support for KML files.
What about GPX files?
JAMAL EASON: Yes, so
we parse GPX and KML.
AUDIENCE: OK.
AUDIENCE: So when you
install with Instant Run,
is that a normal
stand alone APK,
so if I then disconnect the
device and take it away,
is that still going to
work in the same way,
or does it rely somehow in being
connected to Android Studio
still?
TOR NORBYE: No,
it runs just fine.
Yeah.
The only thing is that it does
some extra stuff, like listen
on a certain socket,
but the app is
a self-contained APK that
has everything and can
run anywhere.
AUDIENCE: Great, thanks.
AUDIENCE: Is there
any sort of SDK
so that for some of
these emulator features,
so if we're running
integration tests on emulators
and that kind of stuff, we can
control some of the settings?
JAMAL EASON: Yeah, that's
not in the first release.
Something we've
been thinking about,
but we're definitely
planning on working on it.
Yeah.
AUDIENCE: Will the new
emulators support headless mood
for continuous
integration servers?
JAMAL EASON: That same point.
So we are looking at the
remote testing application
for that, so we're definitely
planning to do that.
AUDIENCE: So the logcat view
in Android studio kind of--
is not great.
Like it still doesn't have the
column view that Eclipse had,
sorting your tags and your
time stamps, and filtering
doesn't seem to be as
robust, and half the time it
seems like it loses the
connection to the device.
TOR NORBYE: Well, the
connection wouldn't be logcat.
We know that ADB has been
pretty flaky particularly
on some platforms, and I
think the newer version of ADB
is actually better, so
you should definitely
install the preview version.
That's what we use for the
demo because Instant Run really
wants an ADB connection
to be reliable.
On the-- what was
the other point?
JAMAL EASON: So we
also replace logcat.
TOR NORBYE: Well,
what we've done
is we in 1.4 we made
logcat quite a bit better.
So before that it was terrible.
Now it's better,
although it still
doesn't have the table sorting.
Part of the reason for
that is that we're actually
using a console widget which
gives us some other stuff.
For example, we can collapse
dock traces and things
like that in a much smarter
way with the auto expand.
In the 2.0 preview, we've
done some more work.
Actually, it might
have been in 1.5.
We show dead
processes, for example.
Right, so once
your process dies,
you can still find it
in the process list.
And for 10 x, when we do cold
swap, the process changes.
It was very important for
us to actually associate
the two together, so
we've done that as well.
XAVIER DUCROCHET: But we know
that we need to improve it.
We have some work plans
for it to rewrite the UI.
AUDIENCE: I usually use
it from the terminal,
just so you can
have multiple tabs
or you can have
different sortings
where Android Studio is kind of
pretty inflexible about that.
XAVIER DUCROCHET: Yeah,
we want to fix that.
Yes.
AUDIENCE: I was wondering
if you considered
any impact of the
bytecode for Instant Run
for developers who might be
using MAT and trying to profile
their apps,
considering, you know,
looking at performance
tools and such?
TOR NORBYE: Right.
Are you asking about the
overhead of the indirection?
AUDIENCE: More or less, yeah.
Instrumenting the bytecode
has to have some impact, and--
TOR NORBYE: Yeah, I
definitely wouldn't do
profiling on Instant Run mode.
I'd probably turn off Instant
Run when I'm going to measure.
In our experience it hasn't been
a noticeable lag, I would say.
But you know, results
may vary, I guess.
XAVIER DUCROCHET: I mean,
for memory, it shouldn't
impact it too much anyway.
There is an instance
of each override class,
only for the classes that
you replace, of course.
But you know, because
you mentioned MAT, right?
So there should be
no memory changes.
We're not allocating
a lot more objects.
We're not doing any of that.
So for memory there
shouldn't be any issue.
For performance, yes, there
is definitely something.
If you do actually
method tracing,
you're going to see all
those overrides, delegation,
and all of that.
TOR NORBYE: But the main
cost is to stuff we add,
that counts towards
a 65K method limit.
XAVIER DUCROCHET: Right.
AUDIENCE: Right.
That's another problem.
I guess I was wondering if the
bytecode had been measured.
Like, you're testing with
a 5 meg app the IO app.
XAVIER DUCROCHET: Measured
in terms of performance?
AUDIENCE: No, just the
difference in size.
For example, when you
install using Instant Run.
TOR NORBYE: It's negligible.
I mean, it's very tiny.
It's basically the same access--
AUDIENCE: It might be nice to
see those numbers, that's all.
Because for five megabytes
maybe it's really tiny,
but if you're doing
the multi-dex--
TOR NORBYE: It shouldn't
be proportional.
AUDIENCE: Uh-huh.
TOR NORBYE: In
fact, we only touch
your code, not the library code,
which makes a big difference.
So when you're using large
libraries, like play services
and design library
and app compact,
we're not going to and
instrumenting those.
We only instrument
your actual app code
that we think you will change.
And so that's a pretty small
amount of code, actually.
AUDIENCE: Usually.
TOR NORBYE: Yeah
AUDIENCE: Not necessarily.
TOR NORBYE: Yeah Yeah,
we are aware of some code
bases that are pretty large.
AUDIENCE: Yeah, so did you want
to talk about multi-dex at all?
TOR NORBYE: Well, one of the
nice things that Xav mentioned
is that we now target it
to the device you picked,
and a lot of developers
target newer devices.
So if you're 21 and up, we can
use the-- what is it called?
Non legacy multi-dex?
What is called?
Native multi-dex.
XAVIER DUCROCHET: So
we don't do that yet,
but we'll do that soon.
One issue to think
about for multi-dex,
is if you're in legacy
multi-dex and your app is
very close to the 65 K limit,
and adding that extra upserver
and stuff like that may
bring you over the limit,
and in that case you
would have to figure out
what to do in your app to
reduce the amount of classes
that you need upstart.
JAMAL EASON: So we're
actually out of time,
so if you have more questions,
please see us in the sandbox
over there, and thanks
for coming today.
TOR NORBYE: Thank you.
[APPLAUSE]
