What’s new in Android development tools – Google I/O 2016

What’s new in Android development tools – Google I/O 2016

STEPH CUTHBERTSON: Good morning. Hello. [APPLAUSE] Welcome, everybody to
our talk today on what’s new in Android Developer Tools. It is awesome to see
so many developers here from around the world
and in a concert venue. I just want you guys to know
this is pretty cool for us. I’m Steph Cuthbertson,
I’m here today with the wonderful Tor Norbye
and the wonderful Jamal Eason. We’re going to give you an
insider’s tour of Android Studio. And for those of you who
are already real insiders, and noticed that Zav is
not on the stage this year, I’m just filling in for him. He’s actually on
a beach in Hawaii. So hello, Zav. When we first started
working on Android Studio, we wanted a purpose
built IDE which was tuned for our languages. That’s why we picked IntelliJ,
and native to the Android platform. Now Android Studio has
built tremendous momentum in a short period of time. One of the things we
announced yesterday is that now, 92% of the
top 125 apps and games use Android Studio. Since we announced it here
at I/O three years ago, and you may remember it
was Tor who did the demo, we’ve released 131
times across our preview beta, and stable releases. And what that reflects
is actually a big part of what’s driving our success. We have an incredibly
engaged developer community. They’re trying all
of our early builds and giving us
wonderful feedback. That is what’s
letting the team focus and helping us go very quickly. We’ve been thinking a lot
the past year about what else we could do to help accelerate
productivity and make your lives better. So for those of you
in the audience who don’t know Android
Studio quite as well, I’m going to give you a
whirlwind tour of 2016 and what we’ve done so far. Just in about 60 seconds. So I’ll bring everybody
up to the same level, and then we’ll go on and talk
about 2.2 and the road ahead. So already this year,
we launched 2.0. That focused on speed with the
introduction of Instant Run and the emulators. We also launched wonderful new
emulator UI, the GPU debugger preview. Search deep linking creation,
testing and much more. Then shortly followed 2.1, which
we built side by side with N. And that brings you support
for all N’s features and API. It brings you
emulators, so you can test N. The new Jack
compiler, so you can try out Java 8 support. And in particular, in 2.1 we
also accelerated Instant Run. And the way we did that
was by moving our Dec step to happen in process, which gave
us wonderful speed advances. Now all of this
brings us now to 2.2, which focuses on speed, smarts,
and Android platform support. Now, one of the things that’s
wonderful for us about I/O is this is a developer audience,
so what we’re going to do is spend the first 25
minutes of today’s talk giving you a live demo of nearly
every single feature in the 2.2 preview, which you can also use. [CHEERS AND APPLAUSE] Now, just a reminder,
this is a preview build, so expect preview quality. And then we’ll do the
normal thing we always do. Over the next
several weeks, we’ll be stabilizing this
as we do, as we move through beta and stable. After that, Jamal and I
will then take it back. And we’ll walk you
through design, develop, build, and test to give
you a nice structured overview with screen shots, and also
take you behind the scenes to talk more about how and
why features were built. So with that, to take you on
a lap around 2.2, would you guys please give a very
warm welcome to Tor Norbye. Thank you. [APPLAUSE] TOR NORBYE: All right. Can you see the screen? Demo. All right. Can we get the demo machine? Thank you. All right. So I’m going to
start with something very small and simple, but
I think you’ll like it. So we released a lot of
SDK components yesterday, and once you’ve installed
Android Studio 2.2, and you go to install them,
notice how we have a background button now. [APPLAUSE] So you can keep
coding while you’re installing the latest goodies. So we spent the
last year focusing on making builds faster. We know that’s a top
concern for all of you. And so I want to show you
where we are with Instant Run right now. So this is the I/O app
running on the right. I can go ahead and comment
out some code here and run it. And when I make
that change, you can see that, within about
a second, it reflects that change on the device. That would take 15 seconds
without Instant Run. I can also make some
incompatible changes, for example, extracting
this into a method, and making that change
is another second or two to deploy. So after the demo,
Steph’s going to talk more about what it is we’re
doing next with Instant Run in 2.2 and 2.3. So one of the
things we had to do when we worked on Instant
Run was figuring out what’s going on inside the APK files. So to do that, we’ve built this
new feature, the APK analyzer. So I can open up any APK
or the one in my project. And now I can drill into
what’s going on in the file. So I can see, for
example what’s inside the assets folder or the
res folder or, in this case, Instant Run. The way we’re repackaging
the application into slices. So let me drag in a
real production app. The Chrome APK. The purpose of this tool,
there’s a couple of things. First one is to be able to
look at the download size. So in some markets,
it’s very important that you make the download small
and the install size small. So this lets you look at
what is actually in your app and focus on whether
you can get rid of it. So I can drill into the Assets
folder and look at the files. I can look at the, let’s
say, the layout folder would decompile the binary
XML back into source. Although we need to do a
better job with the resource references. So soon we will map those
back into resource names. You can also look
at the value table, which has been an opaque
file to look at before. Now, we have a viewer, so
you can go in and see just what’s inside. And last but not least– [APPLAUSE] Yes. And last but not least, this
lets you look at the dex files. So you probably all aware
of the 64k method limit. It’s not actually
a method limit, it’s method plus
reference limit. So you can now drill
into this and see what is it that you’re
declaring and what is it that you’re
referencing, to see how you can get below that
64k or turn on multidex. [APPLAUSE] If you’ve ever
looked at a manifest file in the build
output, you might have noticed that a lot
of stuff in the manifest file that you did not write. Right? Where did it come from? Well, we have a new editor
in 2.2, the manifest editor. So this is the XML tab, but
you can see on the bottom, there’s now a
merged manifest tab. And when I click on that,
you can see that we now give you the full
merged, updated live whenever you make edits. There is a legend on the
right, which tells you where stuff is coming from. So for example, I can see
now the Internet permission– [APPLAUSE] –is coming from Play services. So I can also go in here and
navigate to the line that is the source for the merge. So hopefully that
will help demystify what’s going on with the Gradle
manifest merging process. So speaking of
Gradle, we don’t want you to have to learn how to
edit build files in order to configure your project. So we’re in the middle of a
complete rewrite of the project structure dialog. And I say middle, because
all we’ve done so far is dependencies,
though arguably, it’s probably the hardest part. So my favorite part in the
new PSD is the messages pane. So what this shows me is
suggestions the ID is making. So you can see here,
my project happens to be using jCenter
for dependencies, and it’s telling
me, hey, there’s a newer version of this
dependency available. And all I have to do is
click on this update link, now I’m using the
latest version. I can also click on Update
All to take all suggestions. So notice this is
not just looking at local repositories, which
Lint used to be for you, it goes out and searches
remote repositories as well. If I switch to the
dependencies view, I can drill into the
dependencies, either by module or I can look at the overall
dependencies for all modules across the project. And I can drill in
and see, for example, the transitive dependencies
to see, basically, how I’m reaching certain
dependencies in my project. I can also go and
add dependencies. So we have a nice UI now
where I can go and search. Again, just like with
the update suggestions, this looks at
remote repositories. It also looks at
local repositories. It shows all the
available versions, and it even helps
me tweak the scope string in the dependency list. So you can turn this on today
in the experimental settings, if you want to play with it. And we’re going to
try to finish that in next couple of releases. [APPLAUSE] Next let’s talk about C++. So last year, we showed you that
we have really great editing support. This is the Sea-lion C++
functionality from JetBrains that we’ve integrated. However, it required you to use
the experimental Gradle plugin. And the big news for
2.2 is that we’ve now added support for
external build systems. So you can actually use CMake
to build your native code. You just declare it like
so, with a stable plugin, and now you can build C++. And for C++, we will have
a wizard in the next couple of builds, so you can very
easily go and add C++ support to your project. And when you do that, you end
up with a sample project that looks exactly like this one. So you have a main activity
that loads the native library, and then you have a sample
“hello world” native library string. So let’s hook this up. I’m going to, first of all, set
a breakpoint here in the C++ code. This main activity is just
showing the default layout that has a string in the middle. So let me go back and change
that string to show the value from C++. So will do text view
equals fine view by ID. And then we’ll hook up that ID. We go to cast it, and then we
will call set text on that text with the call from C++. Now, let’s also set
a breakpoint here. So now I’m going to
launch the debugger. This runs Gradle
which runs CMake, builds everything, packages it. And in a second, this app should
be running on the emulator. There it is. So we hit our breakpoint,
now we’re in Java code. And so you can obviously
be looking around at your manifest state,
I’m sorry, activity state. And if I resume
the debugger now, you can see now we’re in C++. [APPLAUSE] And I can drill around. So that’s the hybrid debugger
and the CMake support class. The last thing I’ll show
you in the build system area is something on
the command line. So let’s say that you’ve gotten
a project from a coworker, or maybe you did a Git
poll and someone changed the build tools version, or
let’s say, the compiled SDK version of your project. And then you build, and then
you hit a message like this one. You don’t have built tools
2201, what you do now you? You open SDK Manager,
you installed it, right? Well, in 2.2 alpha 1, we
now have a experimental flag you can set. And when I run the
build, if I’ve already agreed to this license,
Gradle will just go and download it for me on the
fly, as you can see right here. [APPLAUSE] So that should also
make configuring continuous integration
serves a lot easier. All right. Let’s go from the extreme of
command line to visual editors. So let’s take a look at
our new Layout Editor. Actually, I shouldn’t call
it Layout Editor, because it does more than layouts. So first of all, I can
open up a menu file. Here’s a menu. I can drag and drop
design menus now. We can also open up
preference files, and I can drag and
drop preference files. And obviously, this
Component Inspector. STEPH CUTHBERTSON: You did
a really nice job on this. TOR NORBYE: But of course,
layouts are a big part of this. So you can see we
have a new Component Inspector on the
right, this one shows you the important attributes
for the selected component, text view, in this case. So for example,
for text view, we show you the text appearance. And notice how there is some
gray text here in the Component Inspector, even though I
haven’t set the text appearance, we’re showing you
what it actually is going to be at runtime. So I can see the font will
be 14 SPs for example. If I switch to
something else, it’ll compute what that should be. Now, we only have a
subset of the properties here to make it simple to find. But if you need anything else,
the full set of properties is just a click away, up here. So on the design surface,
we have blueprint mode. So blueprint mode is basically
showing the structure. It’s like an x-ray of
what your app is doing. And I can have blueprint
mode and design mode on side by side. And one thing we have
that you’ve asked for is, this is the scroll view
and I can now scroll the design surface directly. [CHEERING AND APPLAUSE] Now, blueprint mode
is particularly useful for the new
constraint layout. So let’s take a look
at constraint layout. So first of all, I’m to
turn off auto connect mode. So let’s drag in
some components. So I’ll put a text view here. We’ll put a edit text, another
text view, and another password field, maybe. And then we’ll add some
buttons on the bottom right. So you can notice I’m
being kind of sloppy, because after the fact, I can go
in and I can make a selection. I can right click
and say, hey, I want to align these
things on the bottom. I want to align all
these things on the left. Maybe I also want to
pack them vertically. So here I have my
design, now let’s see what happens if I go
to landscape mode. That’s not good, right? So I have buttons off screen. So let’s try to fix that. So there’s this
little light bulb icon for infer constraints. Notice what happens
when I click it. I now have these
constraints, where it’s tried to guess what
we probably mean here. And when I try to
resize this now, you can see the buttons
are moving correctly. [APPLAUSE] So normally, you’re actually
in Auto connect mode. So if I want to drag
in a button here, you can see that the
second I drop it, it actually goes and adds
these constraints for me. And if I don’t like
them, of course, I can delete the constraint
by just clicking on them. I can also drag new constraints. And we sort of
show you a preview what it’s going to do
when you commit to it. And the constraints
can also have strength. So as I’m dragging,
you can see it auto snaps to a quarter
or a specific percentage. Someone asked yesterday if this
also works from XML editing, if that’s what you prefer. And why, yes it does. You can see here, we are in XML. I can continue to play with
the constraints over here. And you can see that XML
editing works just fine as well. So this is a very powerful– [APPLAUSE] Thank you. So this is a very powerful
constraint solver. And what that lets you
do is flatten your layout hierarchies, and that’s very,
very, good for performance. So we’ve added a feature
to help jumpstart that. So let me open this
other layout, this one. Let me switch to blueprint mode,
so you can see what’s going on. So here’s a layout
that is actually a set of nested linear layouts. And if I now go and say,
convert this linear layout to a constraint
layout, it offers to flatten the whole thing. And as you can see, visually,
it looks the same now, except we have constraints. And on the left, you can
see a single flat list. [APPLAUSE] All right. Let’s go look at editing. So in the editing area, we’ve
added a couple of features. So first of all, there’s
the Firebase integration. So if you’re trying to
accomplish a task with Firebase for example, you want
to add crash reporting, you just open up the
assistant window, and you pick the
task you want to do. So for example, crash
reporting, you drill into this, you can see you get this step
by set of instructions that sits next to your source editor. And if you, for
example, see that you want to perform these
lines, you can just drag it into your source code
to make that edit, for example. If you are trying to figure
out how to use an API. So let’s say you’ve heard you
should use the Job Scheduler, and yes, you should
use the Job Scheduler. You could right
click on it, and you can say find me some
sample code for this. [APPLAUSE] So as you can see, it
basically goes to the server and finds recommended samples
that you can then drill into. And you can right click and
say, open this in a browser, and let me learn
more about this. 2.2 is based on IntelliJ 16.1. So we have a number of new
features for that, as well. So one thing we’ve got
is support for editing bidirectional strings. So this is something our
international audience has been asking for a while. So here we have
some Arabic text. And you can see the
source editor’s now more than happy to
handle this correctly. I know this has been a big pain
point, so finally we’ve got it. Thank you IntelliJ. So IntelliJ 16 also comes with
a bunch of new inspections in the editors. And on top of that,
we’ve added into it, too, a number of new inspections
that are Android specific. Let’s take a look at those. So first of all,
hopefully everyone knows that it’s really,
really bad practice to solve the problem of passing
data from activities by making your field static. That’s a no-no. And now Lint will
flag it for you, not just because it’s
a leak, but also it makes Instant Run very
happy when you do this. This is also not as simple as
just this case, for example, we have– if I make
other fields here static, app data 1 is no
problem, but after app data 2, it turns out that one
has Instant State that is a context, but now there’s
a static reference to it, which is bad. [APPLAUSE] So let’s look at some of
the new support annotations. We released the support
library yesterday, and there are some
new good ones. So first of all, you can now,
finally say, hey, this method, even though it’s inside
of a worker thread class, this one is thread-safe. You can call it from any thread. For awhile, we’ve had
API check, so Lint will look at the platform
APIs and compare them to your main SDK. And we have a quick fix where
we can say, well OK, insert that check for me. However, what you can now
do is, you can say– sorry. You can say I expect my
method to require this API. So you’re passing on
the responsibility to call it from your API. So you can now get API check
for your libraries to client. So you can see now
these other calls, even though they’re calling your
API, the API check is applied. The next thing I will do is show
you the dimension resource– the dimension annotation. So this one lets you say, this
integer represents a dimension. And there are various
units you can apply. Now, it turns out pixel
is a very, very important. Most APIs in SDK operate
in the pixel space. So we have a new annotation
to just say pixels. So that’s at px, and
when I do that, you can see we’re now flagging
incorrect usages, where you’re passing a dimension resource
that should be a dimension. So hopefully that
will be useful. And the last annotation
I want to highlight is the keep annotation. So you can put keep on
your methods and classes. And as of, yes– [APPLAUSE] So as of Gradle plugin
2.2, we now automatically make sure that, if you use
ProGuard or the new Incremental Shrinker, these methods will
not be removed at release time. So if you like the
support annotations, we have a feature that,
I think, will make them even more useful to you. And that’s the new inference. So IntelliJ has, for a while,
had this analysis action to infer nullity. Well, we have a new
feature, it’s behind a flag, but you can try it if you want,
to infer support annotations. So when I run this
on the current file, it basically does
a bunch of analysis to figure out a lot of
new annotations based on usage in your project. So if I go back
into my file here, all the div markers you see
here are for new adaptations that it figured out. For example, there’s a
permission requirement here. So that will hopefully
help jump start annotations and will help Lint find
more bugs in your code. We’ve also been
collaborating with a research team at Oregon State University
to work on permissions. So this is still a
work in progress, but when this is done, this
will let you migrate your app to Android end permissions. So here, I can
invoke this action, it will help me perform
the right requests and handle callbacks for
Android end permissions. [APPLAUSE] We also have a refactoring
to remove unused resources. So if I add some resources
that aren’t actually used, I can now discard
their refactoring menu, say remove unused
resources, and the IDE will find them and nuke
them for you, which helps make your app leaner. [APPLAUSE] All right. So now the last thing I want to
show you is the Espresso Test Recorder. I’m hearing “ooh”
in the audience. All right. So to do that, all I have
to do is go into my project, and go to the Run menu and
say, record Espresso test. And note that it’s
Espresso not “Ex-presso.” And so when I do that, you
can see that it actually says that actually
builds the app, and it starts this event
recorder on the left here. And on the right, we
have our app running. So now I can, for
example, go and click on this category over
here, and you can see it records an event for that. And I can click on
the Back button. And then I can go down,
and let’s say, click on the music tile. Notice as I’m clicking, it’s
recording the events over here. And it tries to make sense
of what it is I’m clicking. So for example, when I
click on the red button, it’s recording that I
click the FAB quiz button. And so another cool thing I
can do while I’m recording, I can add assertions. So I’m going to click on the
Add Assertion button here. And it’s now pulling down a
screenshot and view hierarchy of what’s going on in the app. And now you can see,
I can move around in the logical
structure of the app. And if I click,
for example, on the question, “Who was
the youngest Beatle?” It pulls that down
and it suggests an assertion, which
is, hey, at this point, when the test is
running, we expect this string to be “Who
was the youngest Beatle?” [APPLAUSE] So then I press Save
Assertion, and I keep going. So does anyone– I’m going
to click some wrong answers, until you stop me. So all right? Still wrong. Still wrong. George is right. OK? And I’m going to finally
click on the Submit button. And you can see that that
was the correct answer. And I think it’s
probably good enough for the test recording part. Now I’m going to say
Complete Recording. When I do that, it’s
asking me what class I want to save this test as. I’m going to accept
the default. And here we have our Espresso test. Notice that I clicked some
wrong stuff in the beginning. I can now edit this
test if I want. So for example, I can take
out, clicking the wrong tile and going back. And then I can run the test. So let’s do that. So all I have to do is click
on this Run button right here. And you can actually use
cloud testing as well. I don’t have time to show it,
but you can sign up for that. And then it’ll run your
UI test across a number of different harbored
form factors, which is pretty useful. All right. So let’s just run this
on the emulator again. So it’s going to build the test,
deploy, and let’s look over on the right here, when
the app starts running, because it actually can
click faster than I can. Installing APK, here we
go, click, click, click. And we have our green pass. All right. [APPLAUSE] Thank you. So with that, I’m
going to turn it back over to Jamal,
who’s going to be talking about the visual editors. [APPLAUSE] JAMAL EASON: Thanks
Tor, great demo. So what Tor showed you
is what we’re doing. I’m going to spend a
little time talking about why we’re doing it and why
you might want to integrate it into your development workflow. So for design, we’re thinking
about two main topics: XML and layouts. So for XML, I know a few of you
enjoy designing your entire UI in XML, that’s great. But I know for me,
and many others, it’s great to have some sort
of visualization tool to allow you to see how
your app is going to render. And our team set a goal for
ourselves, thinking about is it possible for us
to create a tool where no XML editing is required? Of course, that means you can
always look into your code afterwards, but it
shouldn’t be in the way to get your job done. So that was the reason
behind the new layout editor. And as Tor has showed, you have
a whole host of new features, including ways to drag widgets
onto the component tree onto the design surface, or
the new blueprint mode, which allows you to peer
behind your application to see how all your
widgets connect together. And lastly, the new
properties panel. In the past, it used to show
you all the different properties that are available for a view. Now, we curated
those and showed you the most impactful attributes
to use for your particular view layout. The second question
we were thinking about is around layouts. So for Android layouts, you
have a couple different options. You have linear layout, of
course, horizontal and linear. But then, you’re
thinking well perhaps, I need to use the frame
layout or the table layout, wait that’s not going
to work, actually. Let’s think about using the grid
layout or the relative layout, wait, so which
should we use here? That’s the problem we’re
trying to think about, because many times, you’re
thinking about which containers to use for my layouts? So the constraint
layout is the solution for this problem, where you can
think less about the container and more about the content
and how you lay out your widgets on your layouts. So let’s talk about
why you might want to use the constraint layout. So number one, it’s
fast UI development. So as you saw in the
demo, you can actually add widgets pretty
quickly and connect all the different constraints. What it’s also very
important to think about is that this helps you have
more responsive design. So instead of thinking
about, well how does my screen fit on a Nexus 4
or a tablet or a Nexus device, we can now create
constraints that allows you to respond your
content based on the screen size. The third most important
aspect is performance. So as you saw in
the demonstration, we can now find your
hierarchy for you. If you didn’t know, if
you put a relative layout underneath another linear layout
and another relative layout, that actually is slower
for the Android operating system to process. So all that nesting
can now flattened with a new constraint layout. And lastly, it’s
backwards compatible, which means you can use it,
obviously, for new projects, but it’s the
support library that allows you to use it to
existing projects as well. [APPLAUSE] And so the third tool that
we demonstrated around design is the Layout Inspector. So sometimes when you’re
loading your application, you’re wondering, well,
why is my view overlapping, or perhaps, why is one
of my attributes not what I expect it to be? So what you can do
now with our tools is you can right click
and take a snapshot of your current layout
and visually inspect all different attributes
and look at the entire view hierarchy of your layout. So that should be very
helpful in debugging. It’s now time to spend a
little bit of time talking about Develop, and
what tools we’ve enabled to help you with that. So as we showed in the demo,
we have a new Firebase plugin. And this supports a the
new Firebase services that we launched
yesterday at Google I/O. And you can now add things
like Google Analytics, ads, cloud messaging, all in a
click of a button, inside of Android Studio 2.0. The other cool thing we talked
about is the sample’s browser. And as demonstrated,
if you’re looking for an API example of
how do you use something, now we provide the power
of all the Google samples at the click of a button. This should make
it easier for you to now look and have
a good starting point for your application
development. And now with that,
I’d like to talk a little bit about
the build tools and I’ll invite Steph to talk
about those two changers. STEPH CUTHBERTSON: Cool. [APPLAUSE] Thanks very much, Jamal. For Build, I want to start
by talking about Instant Run. Now, as a developer, I
think one of the best feelings in the world
is being in the flow. And one of our
goals for Android is to make Android
development feel as lightweight as web development. So you can make
your code changes, and then see them,
essentially, refresh. So that you can really stay
in the flow as you’re coding. That’s why we built Instant Run. So I want to talk a little
bit first about how it works. The IDE swaps your changes
in one of three ways. For incremental changes,
we do the fastest swap, which is called a hot-swap. And here, what we
do is we instrument your byte code on
the first build. And then after that,
when you make changes, we just redirect the code path
to pick up the changed code. The second type of
swap is a warm swap. And that’s when we need
to do an activity restart. So that’s what you need
whenever you’re going to do, for instance, resource changes. Cold swaps are when we
need to restart the app. And that’s required when
you do structural changes. So examples of those would
be changes to inheritance or if you change your
method signature. So what I’d like to do is back
up and unpack a little bit some of the benchmarks that
we talked about yesterday in the keynote. We benchmark using a wide
range of different applications and different tools. I won’t take you through
all of it, just one example. We benchmark with
the Wikipedia app. It’s an open source app,
you can get it on GitHub. And I’ve posted here
all of our criteria, in case it’s interesting
to repeat them. What you’ll notice is that
we benchmark against 2.0 with Instant Run disabled. And you can see in,
2.1 with cold swap, it’s 4.7 times faster, and
hot-swap is 10.7 times faster. Now, what that means,
if you think about it, is our build speeds are actually
faster than 10x, because we’re benchmarking against 2.0,
and 2.0 is faster than 1.5, because of changes
we made in dex. And we also made ADB push
speeds 10 times faster. So we’re underselling
a little bit, but what we care
about most is, really, that you guys are getting
super fast builds. And so that’s what
we focused on, and this gives us a nice
apples to apples comparison in our own benchmarks. Let me talk about another
type of benchmarking we do. So we look at the user
stats for users who opt in. And we instrument in a bunch
of different, very cool ways. So for all of you guys
who opt in, thank you. This is an example
of a stat we look at. This is average build time
for Instant Run on hot-swap. And this is showing
across all users, so this is worldwide,
all operating systems, all countries, all
hardware, and that includes very old hardware
with slow processors and things of that nature. What you can see
is that most users are seeing hot-swap happen in
four to five seconds or less. And our goal is always
to push that graph over. We’re trying to make as many as
possible happen in one second. So what we look for is,
we’re trying to figure out, how do we drive full
build speeds down, how do we make hot-swaps
faster, and how do we make as many swaps as
possible be hot swaps. So we look at things like this. We look at the distribution
of hot swaps, warm swaps, and cold swaps, and full
build times, as well as what’s causing cold swaps to happen. And it was looking at that
instrumentation, really all of your wonderful
data, that gave us the clue for one of the big
changes you’ll see in 2.2. So 2.2 includes
a change to AAPT. A lot of you guys know, when you
change a resource, AAPT inserts and ID in the manifest. Now, what you may not know,
and what we didn’t know, is that if you change a
resource or add a new one, AAPT was renumbering those IDs. So the impact is, you
make a code change, but you would get a cold swap. We identified this was
driving about 16% to 19% of our cold swaps. So with 2.2, we’ve changed AAPT
so it holds all the resource IDs constant. So I’m kind of taking you guys
on an insider’s view of what will just occur to you in 2.2 as
an acceleration in Instant Run, because you’re going to
see a lot more hot swaps. Another change we made is we’re
taking advantage of Split APK. So now, when you build
will break your app into about 11 to 12 dex files. And when you do a
full build, we’ll actually only rebuild
the changed code. We plan to keep driving
build speeds down in multiple successive
releases, not 2.2. So if any of you guys are
seeing still slow build speeds, the engineering team
would really appreciate it if you come find us. Let me talk next about
project structure. Now, Tor already gave
a wonderful demo. So I’m just going to give
you guys the insider’s look. Underneath the project
structure dialog, is some very interesting changes
to the great old build model. Now Gradle has been
wonderful for us. It’s a very flexible language,
very powerful for Android. But let’s think about it. An IDE expects
structured inputs, and Gradle is a
programming language. So that’s pretty complex. One of the changes
we made in 2.2 is, we completely rewrote the
Gradle parser from the bottom up. So what that means is we’re
now much more accurate when we read in Gradle
files, and we’re also much more accurate in the IDE
when we write them back out. So an example of what
you’ll see is for instance, if you write variables
into your Gradle file, it will now read those
correctly in the IDE. And in the future, in the
project structure dialog, you’ll be able to modify
those in the UI as well. [APPLAUSE] The Gradle rewrite of the
model is done already in 2.2. As Tor mentioned, the
project structure dialog is partially complete
in 2.2, and you’ll be able to try it under
an experimental flag. We plan to complete it in
2.3, and at that point, it will become the default. This is just a nice screenshot
of the Merged Manifest viewer, which Tor also showed. For a time, I want to skip
ahead and talk a little bit about Jack. Now the Jack compiler was
integrated with Gradle in 2.1, and in 2.2, we now include
annotation processing. So you can now use annotation
processors on your class path. [APPLAUSE] So this would include, such
as a compile dependency, and they’ll be
automatically applied. Now, detailed information about
how to use this in our docs. One of the things I wanted
to call out here at I/O is, if you are someone who’s
writing tools and doing pre or post-processing
on class files, one of the really
nice things about Jack is that it has a structured
API for manipulations. Now, we are going to be looking
to move more and more to Jack in coming releases. So please do try
this out, and let us know if there’s anything
that’s missing for you. Our last topic will
be C++ support. And for this, I’m going to give
you guys the whole arc of what we’re doing. Because I think it’s a nice way
to just understand C++ from end to end. The reason we’re
investing so much is because we know there’s a
lot of you who are doing very graphics-rich apps and games. And you’ve talked to us and
told us that C++ is critical. We already support C++
editing and debugging. And all of that is
coming through IntelliJ. So one of the new things you’re
going to get with 2016.1 is also IntelliJ’s wonderful
improved support for C++. But I think the biggest
change you’ll see in 2.2 is CMake and Gradle. Let me walk through
a CMake example. You can now reference a CMake
project in your Gradle file. And this will build
your SO files, so they’re packaged in the APK. And how it works is, Gradle
now shells out to CMake. And we’re getting CMake
to emit more metadata about the project itself,
both how to build it and what files are
in the project. So that’s how, as
Tor was showing you, you’re able to see the .cpp
files show up in the project hierarchy, and you’ll also
get your .h files as well, if those are in the same folder. The files themselves will show
up in a node in the project hierarchy as well, under
external build files, so you can edit those
as well from the IDE. And just as Tor
showed, you can then run the app, set a breakpoint,
it will all work as expected. Setting up NDKBuild
works the same way. So you can reference an Android
.mk file from your build. I’d also like to give you guys
a brief tour of the C++ debugger enhancements. So first, in 2.2,
as we mentioned, you no longer have to
explicitly choose the C++, Java, or hybrid debugger,
you can just use auto, and the IDE will automatically
select the right debugger for you. If you’re debugging in N, you
can actually use one single debugger for Java and C++. And then, a final thing
we added is watchpoints. So you can add a
variable, and you can freeze the process if those
are red or if they’re modified. Watchpoints can be used
on x86 and Nexus 9, and we’re planning to
bring more devices online. For now, a great way,
if you want to try them, is to try them out
with our emulators. We also fixed several
compatibility issues with Samsung S5 and S6 devices. So that covers C++ in 2.2, and
you should expect to continue to see enhancements
in coming releases. The last area we’d like
to talk about is testing. And so with that, I would
love to bring Jamal back. Thank you guys very much. [APPLAUSE] JAMAL EASON: So
for testing, a core feature you need is a
local testing environment. So we’re really excited that we
launched the Android emulator earlier this year. If you haven’t tried,
it it’s a great tool. What’s great about it is
that we’ve improved the CPU, GPU, an I/O speeds, so it’s
even faster than a device. We’ve also improved
the ADB speeds. Believe or not, many times
the bottlenecks between you pushing your assets, and
your application is ADB. So that’s actually now 10 times
faster with the new Android emulator. And of course, as
Tor was showing you, we have the new UI. You can do things like
rotating, take screenshots. But also, there’s an
extended UI as well, which allows you
to control sensors, like taking a location,
doing SMS, or making phone calls, all tools allowing
you to test your application. [APPLAUSE] So in addition to
the local testing, we also launched the
Firebase Test Lab inside of Android Studio. So if you click
on that clouds tab that Tor showed in the
demo, it allows you to choose devices in the cloud. And now you can run a
device that you may not own, and try and send your
APK and test along with that, to help you test
your application. And I showed earlier, we have
the Espresso Test Recorder. And that’s a very cool demo. Why this is very
important is that, we found that making
tests can be tedious, and sometimes, not lot
of people like to do it. And so now, you can
click on your device, we can capture all those tests. And you can now upload
those to the test lab or run them locally
on your machine. And lastly, we talked
about the APK Analyzer. Again, why this is very
important is because sometimes, you think you’re done, you
built your application, and the APK is too big. Because at the end of
the day, your users who download your
application from Google Play want the smallest
APK as possible. So this tool allows you
to dig into your APK, look into your dex
files, your assets, and figure out what might be the
problem, and my APK is large. We don’t have time to talk
about every single feature, but we talked about new Lint
analysis, new IntelliJ 2016 features, and we made a big
investment to accessibility. So these are all new features
that we’ve added inside of Android Studio 2.2. So just to recap, we launched
a whole host of features around design, a new constraint
layout manager, and corresponding designer, new
Firebase integration to help you code better, enhanced C++
support and build support, and a test recorder
to help you test. And how do you get started? All you have to do, if you’re
using Android Studio 2.2 today, just go to check for
updates and we’ll prompt you to download
Android Studio 2.2 in the canary channel. And if you’re not using
Android Studio, anyone, jut go to this link here
and download a fresh copy. And again, change the
channel to the canary channel to download Android Studio 2.2. And that’s it. Thank you so much. [APPLAUSE] Thank you. [MUSIC PLAYING]

61 thoughts on “What’s new in Android development tools – Google I/O 2016

  1. I had to disable instant run. Often did not get the changes forcing me to force a clean rebuild (very long). Worst part, when something didn't work I started to think: did I made something wrong or is it instant run? basically unreliable. Are you aware of these issues? there are tons of bugs reports about this, are they fixed in 2.2?

    other thing: Data Binding is amazing but preview does not work with it. tools namespace data are ignored.

    finally: constraint layout is really cool but suffer of the same problem of the appbarlayout + collapsingtoolbar. If you want to use fragments sometimes you have an image there, with a transparent toolbar, sometimes the image is below the toolbar (smartphone vs tablet). Problem is you need to keep the toolbar outside the fragment but the image managed by your fragment is inside the appbarlayout. Are you aware of this issue? any plans on addressing this?

  2. Pretty cool congrats on the new release! I can see you're updating the docs too. Now I will try this new version. Thanks for your work!

  3. This Android Development Tools team goes to eleven!! Unbelievable work!
    This release should be 2.11 instead of 2.2 because it goes to 11.

  4. Quick question: if I use a linear layout inside a relative layout to group items, in case I want to hide them for example, won't the flatten to constraint layout screw it up?

  5. is it just me who dont know android dev but still think new version is the coolest one? i wanna be NerdMan.

  6. is it just me who dont know android dev but still think new version is the coolest one? i wanna be NerdMan.

  7. is it just me who dont know android dev but still think new version is the coolest one? i wanna be NerdMan.

  8. 92% is actually disappointing due to the fact that 8% still uses eclipse which is not officially supported.

  9. Why did they remove the "Monitor" button from the toolbar? Do they offer the same functionalities from there, within the IDE?
    I don't see the feature of getting the current view-hierarchy , for example…

    IS IT JAVA???????

  11. I don't understand how you can talk so happily about the new things when the "old" still have (major) bugs, are incomplete or don't even work at all.

  12. Finally I'm not insulted a woman. Shes informing not just a stupid affermative action placement

  13. I dont have the convert to Constraint Layout button when right clicking a layout. Anyone else having the same problem?

  14. Какая же ты страшная, ненакрашенная и накрашенная тоже страшная.

  15. waiting for the stable build but other than that ive had the normal amount of bugs especially gradle build errors even when there were no errors

  16. For me, the structure of the talk seems a little bit awkward. First, the demo shows a lot of new features in Android Studio. Next, most of the content of the demo is repeated over a number of slides and very little new information is given.

  17. gradle is really slow , I have to wait more than 3 minutes to build, this is really annoying.
    also the emulater is another slow feature, it runs fast and stable in eclipse. also everything is running fast in eclipse.

  18. I like the way how Android Studio has lowered my productivity down by 1000%, thanks to shitty gradle. Who needs instant runs, in Eclipse, when you can make and drink a cup of tea, and have a s***, and visit your neighbour, every time you run the damn s***. Google, are you Microsoft in disguise?

  19. Getting closer and closer to the beauty of designing in Xcode… you'll be 30% there in another 10 years or so…

  20. LOL at the off-camera presenters with their mics STILL ON, whispering to one another – we can still hear you – hello?

    The quality of this presentation is okay, but lacks the confident and polished, self assured style which Apple excels at. Do better, Google, because the way you come across in public is a metric by which people measure how much confidence they have in your ability to run your company… and if you haven't even got it together enough to mute your off camera mics, well……

  21. Edureka’s Android development online course

  22. Hi…. Good work..
    I am following the channel… keep it up
    now checkout my channel Android Learners:

Leave a Reply

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