Google I/O 2012 - What's New in Android Developers' Tools


Uploaded by GoogleDevelopers on 28.06.2012

Transcript:
>>> Ladies and gentlemen, good morning. Would you please welcome Xavier Ducrohet and Tor
Norbye. >>Xavier Ducrohet: Good morning. I'm Xavier
Ducrohet. >>Tor Norbye: And I'm Tor Norbye. In this
talk, we will show you what we have been working on in the tools team over the last year and
give you sneak peaks coming up. >>Xavier Ducrohet: Let's start with everyone's
favorite tool, the emulator. We are well aware that there's been a lot of problems, especially
on the emulator running larger configuration like tablet sizes, and we have been working
on fixing that. Last year at I/O, I talked about a prototype of hardware GL, and I'm
very happy that finally we released that a few months ago. If you are running ICS and
above and if you are unable to (indiscernible) support the AVD location dialogue, you will
be able to use your computer GPU to do the rendering. The problem is that software rendering
using code that is being interpreted into X86 was not fast enough for higher resolution.
So that helps for general interactivity in the emulator, but that doesn't help if you
have an application that does a lot of computation. To help with that, Intel contributed into
the OSP project support for virtualization mode. And so we already had that for Linux,
but they added support for Windows and for Mac. They have released Jelly Bean system
images and ICS system images -- not Jelly Bean, Gingerbread and ICS. We are working
for them for the Jelly Bean. If you are using that, you will see the emulator is much faster,
and I'm going to give you a quick demonstration in a little bit.
First, let's talk about hardware emulation. We have had different strategies about supporting
hardware. So since, basically, 1.0, we added telephony support. So to support telephony
in the emulator, we use another tool, DDMS, on the emulator and allow you to allow to
initiate code to send code into the emulator. About a year ago, we started really using,
actually, hardware to emulate hardware into the emulator. We started with webcam support.
If you have USB webcam or webcam directly into your lap, you can input a video stream
into the emulator. If you used the camera application, you would see the output of your
webcam. Starting more recently, we decided that those devices have a lot the hardware
that you don't find anywhere else. Sensors, accelerometer, compass, gyroscopes, multi-touch
screens, you don't have that on your random computer. So we decided to start using that.
And so using a device tethered through USB cable, we are starting to send some of that
information back into the emulator. Let's see what that looks like.
So I have an emulator here. This is running a regular 10-inch tablet screen, 1280 by 800.
It doesn't look great because it's a little bit scaled so it fits on screen. This is running
ICS with GPU on and with X86. The -- as you can see, it's very smooth. If we go into all
apps, there we go, it's -- really follows very well your interactivity. So I encourage
you to try it. It works very well. So let's look at touch input. As you can see,
when I click somewhere, there's a small white dot that you touch feedback. And you can enable
that in the settings if you go into developer options. So I have a phone here running a
small application that's packaged with the SDK so you can compile it on application and
then it can start swiping. I'm not touching my laptop; I'm just touching my phone.
[ Applause ] >>Xavier Ducrohet: So doing that, with just
one touch, it's pretty easy, but -- yes, that's okay. I will do it that way. It may rotate
while I'm doing it. We work to go disable that. So that's the point your location in
dev tools. I can do two touches, three touches, four touches, five touches, as many, really,
as your device will support. A device like that will do ten touches. I will try to put
all of my fingers. >>Tor Norbye: Good if you are developing a
ninja game. >>Xavier Ducrohet: That would be perfect.
That's the emulator. Our goal here is to let you try on any type of form factor that you
don't necessarily own, and we don't expect you to buy every device out there. We really
want you to be able to try your application on the emulator no matter what type of hardware
your application is using. We will work to improve even more the hardware support.
So that means we want you to be able to create emulators to really emulate any kind of devices.
To help you with that, we will show you something I just started working on.
I have -- I forgot to clear that. So this is the AVD creation manager. AVD stands Android
Virtual Device, really a configuration of emulator to simulate a particular device.
So, normally, you would enter an APL. And we are going to -- we just added that particular
menu here, where you have a bunch of devices. And we're going to work with OEMs to make
sure that this is populated with as many devices as we can. So here, let's say you want to
create an emulator that emulates exactly Nexus 7 -- not that any of you need that anymore.
So you click here and here, all the properties, all the hardware is set up for you. This is
going to be exactly a Nexus 7, the proper density, the proper resolution. Like the resolution
is entered here, and it will be done for you. [ Applause ]
>>Xavier Ducrohet: So I'm going to give you the name. Here I just created -- I started,
but I'm not going to do it. So I have a second one since I already had a first one. One thing
that we added was, you may have noticed those generics devices, and those were presented
before in the emulator, so since we are doing that, we figured that we may as well also
show you in the new editor. When you choose a device here, we just show you your AVD here
directly. When I chose the AVD I just created, since we know it was created to match a Nexus
7, then we just render it as if it was on a Nexus 7.
All right. So that's the new editor, or part of it. Why don't you tell us a bit more about
that editor. >>Tor Norbye: Okay. I'm going to defer the
editor and start with the basic editing we have improved over the last year. Hopefully,
you all know, in Java files, in Eclipse, you can press control O to open up this quick
outline and do quick filtering to navigate to a method. We made that work better in XML
files now. So if I'm, for example, in this layout file and I'm looking for button 5,
I can type B log chart 5. [ Applause ]
>>Tor Norbye: You can also use control shift P to jump between matching tags. We enhanced
the code completion to work with custom views. This is particularly useful. Let me show it.
Control space, you can see here we pick up on the app name space. We even find the documentation
for your custom style and show it to you. Hopefully make that easier. My favorite part,
though, in the XML is the new formatter. If you look at this file here, this is what you
used to get when you reformatted the files out of the box. If I do this now, you can
see I get a much clearer layout. [ Applause ]
>>Tor Norbye: And this is not just adjusting indentation. It's also, for example, reordering
attributes. So I put the height before the width and maybe the ID down here, maybe mess
up the indentation a bit, too, you can see it puts things back in the right order.
[ Applause ] >>Tor Norbye: Not that Android cared what
the order is. This is the style we recommend and we follow in all of our tutorials.
And the other thing you see here, for layouts, we prefer to have a blank line for the elements
and one attribute per line. You can use your editors and set it up to format the same way.
What's unique about this, if I switch to, for example, a strings file, like this one,
and I press control shift F here, it does something totally different. Here we format
the way string files should be formatted, one string per line, unless you are working
with a Perl. Of course, if I go to manifest file, there are other heuristics which apply.
Hey, let's put the permissions in one block, and let's treat the application element as
more like a layout tag. So I don't type indentation anymore. Instead of pressing the tab key,
no matter where I am, whatever I've copied or anything like that, I press control shift
F and it puts things back in order. The next thing I want to show you is the rebound
wizards. So if I open up the new wizard, you can see that we have a bunch of new items
in this list. And the list is going to get longer, by the way. We mostly worked at infrastructure
at this point. This is what the new project wizard looks like now. It's completely different,
because it's been rewritten. And let's type in an application name. Google I/O demo. So
notice that as I'm moving the focus between these text fields. On the bottom here, we
have explanation. For example, when we get to the package name, please choose carefully.
You will have to stick with this package name forever. Likewise, we explain the difference
between the build target and the MSDK version. We used to ask what number you want. Now we
are showing you code names and version numbers and everything. You also have the option of
creating a custom icon. And that happens on the second page.
So this is the assets studio. [ Applause ]
>>Tor Norbye: So here we can choose between some clip art. You can also start with random
text. So I can choose I/O. Maybe pick a different shape. Add some padding. More likely, though,
you will have some project or company logo you want to use. So you can go in and fetch
that image. So I'm going to put an I/O logo here and put it in. And as you can see, it's
now going to create different density versions of this icon, also gives sort of a standard
shading treatment. [ Applause ]
>>Tor Norbye: So this is even more useful when you're dealing with things like notification
icons and action bar icons. And we're going to show that in a bit more detail in the layout
talk tomorrow. So on a third page, I get to choose what to
put into the project. We no longer create this empty project. I can choose between a
master detail flow skeleton, which will create a tablet version with details on the left
-- right and a chooser thing on the left, or I can create among a set of blank activities.
So, by default, I can get tabs, I can get swiping, I can get swiping plus title script.
[ Applause ] >>Tor Norbye: Drop-down. Sadly, right now,
this requires Ice Cream Sandwich. But we are really hard at work at back porting all this,
and so ASAP, hopefully, this will also generate compatibility codes. Default layout, you see
there it is. Let me show you what happens when I add into an existing project. So I
invoke the new wizard again. Choose add activity, and I'm going to have to choose a unique name.
When I hit "next" now, I get this preview. Let me maximize it. So you can see that what
we are doing here is, we are not just creating a new activity class, we are adding registration
into the manifest. We are adding resources into the string file.
[ Applause ] >>Tor Norbye: And so forth.
So let's talk about the layout editor a bit. So when you're editing layouts, you don't
really need to be spending your precious screen real estate on the package explorer, output
window, and so forth. Luckily, Eclipse supports the concept of maximizing the editor, Control
M, which is really useful when you are editing Java code, but it's now useful in the editor
as when. Press Control M. Not only do we get rid of this other stuff, we also include a
structure view and property sheet inside the layout editor now. These are configurable.
I can, for example, drag the structure to the bottom here. This is useful if I'm trying
to do a landscape orientation like this. I can also give myself more space by minimizing,
for example, the pallette. Now that it sits over there, I can hover over it, I can drag
out the widget I need. When I do that, it goes away and it gives me the space I need
to see my layout in. The most important change is the property
sheet which has been completely revamped. So you can see if I select something here,
first of all, if I hover, it will show me the documentation for the property that I'm
about to edit. If it's a Boolean property, I can click it to cycle through the values
true/false and not set. When you look at the properties here, you can see where you might
not be able to see because this font is small. Trust me, there's blue colors for things that
you have set. And we're also showing inherited attributes when possible. So, for example
-- it's okay. You can clap. You can see here the inherited color for text link is blue.
And the way most property sheet implementations work is they call the getter and ask what
is your color and they can display it. In Android, we can't do that, because many XML
attributes don't have a corresponding get every. What we have done, what Java has done,
we intercept the value lookup. That gives us something cool. Which is, look, we can
show you that this is not just blue but this is actually the resource Android color Holo
blue lite. Likewise, we are showing these attributes in groups, so you can see nesting here, text view attributes
are all together, and we are showing the important properties in bold. That's useful if you switch
to an alphabetical order. If you are looking for a particular property by name, you can
switch that order. And we're also hiding a lot of more attributes. We ran statistics
on code bases and found there are attributes that are never set. You can expose them if
you want. There are great italics properties here. If I choose this edit text, you can
see something interesting. We also preview drawables, so in edit text has an actual attribute
to set the icon that's shown when you are selecting and it's right there, you can see
we are previewing it for you. Let's set some actual properties with this property sheet.
So let me switch back from alphabetical order. All right. So hello Google I/O. And I'm going
to set the color. Notice that we do complete completion on resources which is kind of handy.
I'm going to set the size to 36, not bips, but SPs. And you can invoke customizers as
well. One other cool thing we have added is we showed the resolve values. If you look
where I'm pointing at here, as I'm selecting different resources, you can see what the
current resolve value of this attribute is. This works not just for dimensions but strings
as well. That's a property sheet.
You can see that the -- we have these weird guidelines in the layout editor here that's
because this is a relative layout. Last year at I/O we previewed this layout support. Now
it's basically done, and so if I'm dragging in here, you can see we have been enhanced
it a bit more. In addition to showing guidelines, we have this tool tip which is trying to stay
out of the way for the constraints being shown. But it shows me what it is it is displaying.
So this year we have a preview of another layout that came out in Ice Cream Sandwich,
the grid layout. We are trying to go for the same tools experience that you have with relative
layout. As you are dragging, you get these guidelines. We are trying to go one step further.
You can see these red lines. This is something that appears in a lot of the internal UI specs
at Google. This is a feature that is not done, and you but we are working on it and bring
it back to the other layouts so you get the recommend UI look for these things.
Let me show you fragment support. I brought up the wrong layout.
So this is the Google I/O app, it is using fragments. The key thing about this layout
is that this is only organizing how these fragments will appear. It's relative to each
other. It's not controlling what's inside the fragment at all. That obviously is controlled
by Java code at run time. So it could be different layouts showing up depending on the context.
We give you a way at design time pick which one it is to work with. We basically look
at the class, figure out what layouts are you referring to and we offer them here. So
you can see that in this layout, maybe I want to show waiting for sync, here we have some
various banners shown at the bottom. In the middle there's a ListView and on the ride
there's several options I'm going to choose this one. So you can see this is basically
what this app looks like when you run, but we can work on editing the overall structure.
We can also go and edit the internals. If I do the swipe select, you can see this is
the outer layout. If you double click, I can go to the inner fragment layout and edit just
that. I can go into the property sheets and change the text to, for example, be patient,
or something like that. Let's save and exit that. Now, you can also
work with new fragments on your own. It's pretty easy. If I delete the fragment, now
we have a normal layout that you are familiar with. The way you insert a fragment is to
just go the pallette, find the fragment tag and drag it on to your layout. We pop up this
dialogue, which fragment class do you want. You can create a new one with the create new
on the bottom. I will pick an existing one for now. Choose something to show it design
time and there it is. All right. So the last thing I want to show
in the layout editor is the new configuration chooser. So I've already shown you that you
can flip orientations very easily through the orientation toggle. You can obviously
choose between other things such as the UL mode and the night mode. Xav showed you how
to switch different screen sizes to see how this looks in tablet size. We also let you
choose between themes here. So we've ordered them so you can easily pick the themes that
you have defined in your project with the themes you have in your manifest or Holo themes
or Holo lite themes. This used to be a giant list. Hopefully it's easier to work with now.
And we also have a new thing here. This is the activities users. So why would a layout
have an associated activity? We haven't needed it until now, but we're starting to. So right
now we are using this to figure out which theme to default your render with, because
in your manifest is where you're declaring theme associations and that's based on the
manifest. But in the next release, hopefully, we're going to use this to also be able to
render your action bar items in line. We will look at this associative activity and render
it there. There might be other features as well. Now, we also have a locale chooser.
So this shows you basically the locale to have.
And we have flags as well. This is based on a very simple heuristic mapping from language
to country flags so I hope there are no obvious mistakes, I don't want to start some kind
of an international incident. File a bug if you see something obviously wrong. And so
obviously I can choose the language here and we'll rerender with the other language.
And finally you can choose a different rendering target to see what this looks like on a different
platform. So everything I've shown you so far is in
AD20 which we shipped yesterday. But now I'm about to show you something I'm really excited
about which is a new feature that we're working on and this is something we're calling multiconfiguration
editing. So I don't even know how to start so I'm just
going to show you. I'm going to say generate the full thumbnails. So what I did here was
this is showing what this layout is going to look like with a different theme, in a
different language, different screen size, different orientation. And the key part about
this is if I edit this, these guys are staying in sync.
[ Applause ] >>Tor Norbye: And I can obviously switch between
them to see, you know, what does this look like, I can go back. I can zoom in on something,
if I want to see them, you know, in a larger dimension to see what's going on. And the
key part about this also is that I get to choose what these things are. So if I'm, for
example, really interested in supporting French, because French is? The best language, right,
Xav? >>Xavier Ducrohet: Yes. I mean oui.
[ Applause ] >>Tor Norbye: I should have gone for the Brazil
cheap shot but I didn't do that. So I can now pick French and I can go add a thumbnail
and see, now, it's showing up over here, showing me this in French, and as I go back to the
default, you can see this one states showing me what this looks like in French, I don't
know if you can see that, it might be tricky. Give it some more room here. So this is basically
now showing me persistent French preview. All right. So that's just -- we generated
some default thumbnails for you, you can also add your own. And we have some other ones.
Look at this, preview all screen sizes. Let me get some more screen space. This is showing
the layout across all the screen sizes that I care about.
[ Applause ] >>Tor Norbye: And preview all locales. So
here we have a rendering of what this looks like across a bunch of different languages.
And you can see that as I'm editing this, these things immediately start rendering to
whatever the current layout looks like. I can obviously -- I don't know if you can tell,
but something looks wrong, let me zoom in a bit more so it's easier to see from your
perspective. You can see that something looks wrong here. Let me zoom in so you can see.
This button is too high compared to this one. So I could obviously zoom in like this, or
we can switch to it, right, and we can see what's going on. So this feature I think is
going to be immensely useful. You can basically make your edits and simultaneously keep an
eye on what this is going to look like across screen sizes, languages, any configuration
language you care about. >>Xavier Ducrohet: So one thing that's really
interesting here is that we show you a language, but it's really the main configuration so
that if you switch to something else -- >>Tor Norbye: Yes, if I switch to a dark action
bar theme, it's now showing the dark action bar theme in these other languages, and I
can switch orientation, it's now showing me the other orientation, so, yeah, I think this
is going to be useful, so I'm really excited about finishing it.
[ Applause ] >>Tor Norbye: All right. So the last thing
I want to show you is Lint. So you might have noticed as I've -- if you've looked very carefully,
you might have noticed -- and if you're sitting near the front, you might have noticed these
little warning icons showing up on top of the layout. This thing. What's that? We have
a new tool in the Android tools called Lint which is basically a bug-checker. It looks
through your code, your Java files, your XML files, your ping files, your -- even your
Proguard files and looks for errors and it cross-correlates things to make sure there
aren't problems. We look for correctness issues, usability issues, performance issues. Here's
an example of a usability issue. If I hover over this, you can see we get a tool tip on
the bottom, so we're always putting the tool tips on the bottom, so they're not on top
of the layout, this could get really old really quickly if we kept putting up tool tips on
top of your design. This is showing that the bucking order is
wrong. Since we're targeting AP14 or higher, the okay button should be on the right. So
when I do that, the error goes away. So we're actually running Lint incrementally for every
UI action on this layout. If I add some more errors here, let's throw in some buttons,
for example, you can see there's a counter up in the right here. Does it look familiar?
So this one is basically incrementing and showing you the -- when you have no errors,
it disappears, but it's saying I have two issues now, and these are basically both -- there's
a hard-coded string here. So we run Lint incrementally on every UI action,
we also run it on every save. So if I'm in an XML file and I find a -- if I were to,
like, hard code this string here and say cancel, the minute I hit save, you see I get a warning
where saying there's an issue, you should use a string and resource here. This is not
just for XML files. If I switch to a Java file and let's go and create a toast. Toast
dot -- c'mon, make text. Context, hello, and one. The minute I save, you can see it tells
us, did you forget to call show on this? I don't know if anyone who's done this but --
[ Applause ] >>Tor Norbye: So we run Lint incrementally
when we can, but there are certain kinds of checks that require global analysis, we can't
do it incrementally. For example, finding unused resources. That requires all declarations
and all references. So the way you run Lint on the whole project is to go to the Toolbar
where we have this Lint action and I can run Lint on all projects or just a particular
project. And when I do that, you can see -- we open this window in the bottom here, Lint
warnings, and here we've collapsed it as much as possible. I can expand it if I want, but
we're showing one item per type of issue. And as I select these, you get a fuller description
because it's really hard to explain a problem to a user in less than 80 characters. So you
can get the fuller explanation and sometimes there's more information as well.
So let's take a look at some of these errors. If I double click you can see we jump right
to it. Here it's saying there's a problem where in the XML we can jump to it, in XML
this is a button and that is not compatible with the cast two toggle button, so it's cross-referencing
XML and Java. Likewise, we have a string formatter called here where we're passing a string as
a second formatting argument, and if we look at that actual string, you can see that it's
actually supposed to be an integer. Here's a good one --
[ Applause ] >>Tor Norbye: Here's a call to set the text
color. We're passing in the color black, this compiles just fine. So what's the problem?
Well, we're passing a resource ID, not the actual RGB triplet. These are just in, so
it compiles just fine, but it's a subtle problem so -- we found this in our own code, too,
as well, unfortunately. In the keynote yesterday, you found out how
to increase the amount of butter in your diet. We have some Lint checks her to help you sort
of avoid jitter. So what you don't want to do unconditionally allocate objects in any
draw call or on measure call, so we look for that, calling create bitmap. If you do put
conditional logic around it Lint should be quiet about it.
Now, in the summary here, you see light bulbs. I don't know if you can see it, so I'm going
to zoom in again. There's light bulbs next to some of these warnings. And this is basically
telling you we have an automatic quick fix for it.
For example, it says here that this text field does not specify input type or hint. I can
either press the fix icon here or I can use a quick fix while I'm editing. And we have
explanation of the issue. I've run the quick fix and it inserts, you know, the correct
fix. I hit control shift F to just clean things up again.
The other thing I can do is suppress issues. So let's say that I don't care about hard-coded
text because I only want to support French. Yes! Do you see a theme here? If I invoke
control one to invoke the quick fix, there's actually and add ignore hard-coded to element
here. This let's me suppress this issue. So if I select this you can se it actually adds
an ignore element on the specific type of issue, this can also say all or be a common
separate list of things I don't care about. And I can move this attribute up to the root
if I wanted to suppress it for the whole file. So the tools name space is special. This was
something that was added I think in tools 18. And this is basically going to be ignored
by AAPT. So anything in this name space, there's no penalty whatsoever. It does not make it
into the APK. But it's great for us. We can store metadata this way now, not using comments
like we used to. So the ability to suppress errors is not just
for XML files. If I go over to a Java file, I can do the same thing there. So if invoke
control one, I have a bunch of suppressed Lints and this is using annotations. All right.
So I want to show one more thing here. I assume many of you are trying to target not just
the very latest version of Android and so you always have a choice. Do you want to build
your app against the oldest platform you're supporting? That's good because it means you're
not going to accidentally use any APIs that aren't supported everywhere, but it's bad
because you have to access reflection to access anything newer and that's really cumbersome.
The other choice is to compile against the very latest version of the Android SDK, the
problem then is that what if you accidently use an API that isn't supported, you're going
to have a runtime error. So we now have a solution for that with Lint
which basically lets you have the best of both worlds. Now you should compile against
the latest target and then Lint will tell you when you have some kind of a illegal API
reference. So I'm going to show that here by calling get action bar and we'll assign
it to this. All right, let me save -- okay. So now, after I saved, it's coming up with
an error and it's saying that this class requires API 11 and that this method call here requires
API 11. And we're trying to target five. So the error message says exactly what the problem
is. And so you can basically make sure that this code is then only called on a path that
is guarded with some kind of a version check. And once you've done that, you can say I know
this class will only be called when we know the API is 11 so I can use the new target
API annotation to basically mark this as being clean for Lint.
The last thing I want to show you is a preview of a new Lint check that we're working on.
So I'm going to open up the Lint preferences dialogue. This is showing all the Lint errors.
So we have about 100 of them right now that we're checking, and this is increasing in
every release, so make sure you keep updating. In this build I have a special -- special
Lint check which is disabled by default but I'm going to enable it now. This is called
missing permission. So I'm now going to go into this class again and I'm going to innocently
create a new socket. All right. So I've got to fix the import. And now I get a new warning
here saying this requires Internet permission, which I don't have. So if I, then, go to the
Lint window and say, you know, fix this, it will open up the manifest file and add the
Internet permission for me and this checks all the libraries I'm using as well.
[ Applause ] >>Tor Norbye: So that check does, however,
require a really good permission database which we're working on. So this is not going
to be out in the next couple months, it's a little bit longer term goal, but I hope
this will be useful. >>Xavier Ducrohet: Excellent. Thank you, Tor.
All right, let's talk a little bit about developing tools. So in 20 that we just released yesterday,
we added a few new tools. The first one that we added is a tool called tracer for OpenGL
ES, and as its name indicates, it's going to help you trace your OpenGL codes, so it's
useful if you're using an engine that's doing GL code for you and you don't know exactly
what's going on. It's working on Jelly Bean and only on devices, I don't think it works
on emulator. And it's available as an Eclipse plug-in and it's available as a standalone
application. Now the standalone application, when we developed it, we realized that we
were starting to have quite a few standard applications. DDMS, Traceview, (indiscernible)
some are the UI are kind of crappy. None of them were configurable, let's say. So we decided
to just revamp that and integrate all of them into a single application. We are basing that
on the plug-ins that we have for Eclipse, so we use and LCP-based application that's
the Eclipse rich client platform, so that you can figure out the windows to look like
you want them to look, so it will be much better.
The second tool that we're adding which we actually showed very quickly at the keynote
yesterday, Systrace. This is a very low-level tracing tool, and I will show you output and
show you a few things in there. And then the third thing that we are adding
is the first bit (indiscernible) of the NDK support in Eclipse. So we have support for
building. So as you edit your JNI code it automatically get compiled and put in the
right place. And we have debugging support so you have a launch configuration, and we
start you to be on the device, we do all the things, and then if you have a break point,
we just stop on there. Let's do a quick demo of -- so my SDK here.
So the monitor, the Android device monitor which is the tool that regroups everything
is under tools, it's called monitor. We still have the other ways, so as we transition,
we will remove the other ones. But DDMS is still there, Trace is still there. We have
a nice splash screen. >>Tor Norbye: Thanks, Romain.
>>Xavier Ducrohet: Yes. There we go. That's not what I wanted but, well, let's show it
again. Okay, so this is -- so you have the DDMS here. There we go. So it looks like the
DDMS that you may already be using except that if you really don't care about the monitor
control you can just go in, close it, you can move things around. So if you have ever
used Eclipse it's basically the same view system.
And then, you know, we have some utilities in there that you should look at, we have
like the network statistics. I think Jeff Sharkey is doing a demo where he will show
that so you should definitely try to see that. And then here, on the top right, you have
the different tools so the (indiscernible) is here and then the tracer for OpenGL ES
is here. So I have -- see my device here? And I'm going to start tracing a tool. So
the way the tool works is that it's meant to work on any chips that are out there. There
are some GL debugger currently available but they are generally tied to a particular chip
set. So we wanted to do something that would work on any devices so that whatever devices
you have, that will work. This works whether you're using Java bindings or whether you're
using [NATPIs, it's just above the driver in the GL library. And what we do is intercept
every code that is done to the driver and then we start building, you know, a separate
state. Because of that and because we can't query the driver to actually get information
about the context, we have to basically start the application in a certain way. So if you
have an application that's already started, you have to quit it and then start it again.
so you click here. And then -- so here I'm going to start the settings application. You
can select your device here. Which application. If you want to start a particular activity,
you can do that, too. And then here you have a couple options. So
by default, we're going to get every GL code that you're doing but sometime you actually
want to see what you're drawing. So that -- those check boxes are for you to choose what you
want us to gather for you. By default, really, you want to get the result of each frame so
what happened after a swap buffer. In some cases you want to see the results of every
GL draw that's going to be significantly slower because we have to send them back from the
device on to the application. So I recommend not doing them all the time, there's another
way after, and then you decide where you're going to send the trace file.
So let's trace a very simple session into the sending app. So I'm going to click trace.
There I go. So I'm going to start tracing. You can see that's it's starting to collect
frame. And as I said earlier, if you want to get the result of every GL draw, just before
you do an action, enable it here, then do your action and then stop it.
So I probably have enough data to show you that. So let's stop tracing. And let's open
it. Stop. Here. Okay. Let's see. So what you have here, at the top you have the actual
frames. So if we look here, you have the actual drawing of the frame, normally. There we go.
So this is what was drawn by the application. And as I scroll, we should start seeing the
-- basically scrolling through the sending application. Here, before that you actually
have the construction of each frames. So every -- you start with the GL view port, and then
you -- and all the way at the end with a swap buffer. And through all those codes you can
look at your GL context here, everything that's in blue means it's what changed from one code
to another. So if I start here and I change, you'll see what change on every code, which,
you know -- and then you can also go look at something, for example, I just organized
that over here, since we can. You can see your shader, you can see your vertex, you
can see your textures, you know, everything. You can also do this. There we go. You can
do search. So one thing that you've seen -- oh, it's collapsed. There we go. So one thing
that you may have noticed is there's some kind of ER key going on. So we added some
extension to GL, the first one is you can put a marker with a particular string and
then will show up here. So if you want to say, hey, I'm starting to do that and I'm
done doing that, you put two markers and then you can search on that and see it. And the
other option is to actually push and pump to and from a stack. So this is what happens
here. This is the regular view framework. It's rendering with GL. So every time it unshows
a new view group it says, hey, I'm (indiscernible) out, so it does a push and then every children
say, I'm a text view, I'm a button, whatever, and then when they stop drawing, then pops
from the stack and then they would will show up here. So if you have your own game engine
or anything like that and you want to start doing some ER key display here, you can definitely
do those extensions. So that is GL tracer. The next tool that I want to show you is the
output of trace. So we showed it briefly during the keynote. I'm just going to show you a
very quick demo. Romain and Chet Haase will actually do a more in-depth look at the session
at 2:45, I believe, today. So I encourage you to go see that. So it's
a system-level trace. You can see everything that happens on your CPU. You can see, you
know, the binder thread for interprocess communication. You can see the Vsync. You can see everything.
It's very loadable, and it can really get stuff into a lot of details. So if you look
here, I'm showing about five seconds, and then you can start zooming into things and
see really what happens all the way down to very, like, short events. Like this event
here, whatever that was, 4.0.6 millisecond. So you can take on any blocks of color just
exactly -- what am I doing here? So exactly what was going on, what it was, how long it
took. You can do selection to see exactly what happened somewhere to see the emulator
and the speed. >>Tor Norbye: If you have some sort of jitter,
you want to use this to figure out why. >>Xavier Ducrohet: Traceview is there. If
you want to see what happens at the system level, Systrace is the way to do it. Okay.
Let's talk a little bit about Android projects. So you're creating a complex application.
Every time I talk to a developer, I'm always amazed by what you are doing. You are using
20 library projects. I have a hundred jars or something like that. You are pushing the
system to the limit. We really want to help you. We know that you want to share code and
resources across different applications or different -- across the same version of the
same application. It's just, you know, very complicated. One thing we do want to do is
make sure that Eclipse and Ant work seamlessly. Our approach is you live in the ID. We do
Eclipse but IntelliJ, why not, any other tool. You can use the great feature that Tor showed
you today. If you do configuration, add dependency and put it on your brief server, you shouldn't
have to maintain two different projects. That's one of the things we are trying to do. So
how do you share code and resources? So we kind of have three ways of doing that right
now. The first way is by using Java Project in Eclipse. It's really a shortcut to cross
-- shortcut for generating a Java file and putting that in another project. It doesn't
work in Ant. You could do custom work in Ant. I would recommend against using that. But
if you want to, it's up to you. Library project; so this is something that we introduced a
while ago and we are definitely committed to doing this. This is the right way of sharing
code and resources across Android applications. It's still available in source compile time
version. We are working on a binary distribution for that. We are starting to see exactly what
we need to do there. Other systems like support some binary application. You can use (indiscernible),
and then the third one is Java. Java is easy. You go online, run a source library that does
what you want. You download, put Java in your project, you're done. That works great when
you have a small project. When you have a bigger project with lots of libraries and
Java, you can get into some serious problems. Let's look at an example here. Let's say you
have an application. You have three library projects and each of them actually use a jar
file. As a human, I need the V2 version of the library because the other one is redundant.
The system doesn't work that way. The previous version was very stupid. It would take all
three versions of the jar file. Each of those library have a copy of that file. So each
would actually send all three versions of the jar to the DX tool which convert into
the byte code. It would process the first jar file, the second one. On the first class
of that jar, it would complain saying, hey, I already know about this class and then it
will break. I'm sure you've seen "this class already added" error. So this is a very simple
example. Very quickly, if you add more library, if you have a jar file that will bring other
dependencies, it gets complex very quickly. The right way of doing that is to -- fixing
that is to have a real dependency management system, like Maven or OIV. We definitely want
to get there. We are not there at the moment. We are working on it. We do want great ID
support. We are still looking at what we are going to do. In the meantime, we do want to
help you with the most common use case. So a couple of months ago we released an update
that would support the case where, let's say, you have two library projects and in each
of them you have a jar file support library, and you want that to work. We introduced a
very simple conflict resolution system. Something like Maven will identify the jar file by artifact
ID version and a clear understanding of what a library is, what a jar file is. Here we
don't really have that information. We have the file. So we just purely base that on file
name. If you have plenty of library projects, all of them have the support library, we are
going to identify all the duplicates of Android. We are going to make sure they are all the
same exact file. By that I don't mean like the version because we don't know about that.
We just compare the file itself. If they are all the same, that's great. We just pick one
of them randomly and then we just discard all the rest and basically get rid of duplicates.
If you -- if we find a file that's different, then we are going to actually generate an
error. Typically in this case, you have two library projects. You get the newer version
of the library support we used yesterday but only completing one of those projects. You
are completing both but you submitted only one of the get project and not the other one
and then your co-worker complains, that kind of thing. We detect that. We did add a very
simple custom support for the library support actually because the V13 version actually
embeds the V4 inside. If we were using something like Maven, we would not have the V4 inside.
We say that depends on V4. Right now, this contains it. So if we took V4 and V13, we
drop V4 and just use V13. So as I said, this is very basic. We really
want to get you a really good build system that will do a better dependency management
for you. And this is a very high priority. We are just not there yet.
So on the implementation side, in Eclipse you have to reference every jar file into
your project, and so it would be even worse than that. If a library project -- say I use
that jar file and you had 20 applications using that library project, you would have
to go in all of those 20 applications and manually also add that jar file. In Ant, you
just drop it into the (indiscernible) folder and it works. We wanted to simplify that and
make that the same way for Eclipse also. This is what you are doing now. If you are manually
referencing jar project into Eclipse, don't. Stop doing it. Just drop them into the libs
folder. Many say lib without an s, so just libs, and then we will automatically pick
the right one. We have a dynamic container on the Eclipse side, an Eclipse way of having
a class pass container that is dynamically filed by (indiscernible). We do the resolution.
We drop duplicate, and we just put what the application needs and we pick up whatever
is coming through the library project as well. So we just grab everything that your application
needs. So that was released a couple of months ago in 17. When we did that, we completely
followed that dynamic container preventing from you actually doing source attachment.
This is really silly, but you can't. And we could fix the UI to do it, but really the
registration is to make sure that wherever you have a jar, you have a source attachment
specific to that jar. So that if you have five applications using the same library project
that depends on a jar file, you don't have to do the source attachment on all five applications.
Again, if you had a dependency management system, you wouldn't have that problem, because
part of your dependency would know where the source is.
In the meantime, we have a very simple solution. It looks like a bit of a hack, I'll admit,
but it works. So if you have foo.jar properties. Create those properties in there linking to
the source command and it will be picked up automatically for you.
So library project, more improvements. We have merging of manifest now. So before if
you had an activity that was declared in a library, it wouldn't be picked up by the application,
even if you put it in the manifest. So we do have that now. We will merge things like
permissions, activities, services, things like that. It's basic. If you have a conflict,
it will fail. We are working on adding that, being able to say ignore, you know. I know
that library declared that permission. I don't want it, I don't want that activity. We are
working on that kind of thing. Because of that, it is not enabled by default. If you
want to try it in your project properties, declare manifest merger.enabled and true and
it will be enabled for you. [ Applause ]
>>Xavier Ducrohet: In 17 we also introduced buildconfig.java. It's very basic. It declares
a Boolean that is true. So in Eclipse if you do an export, otherwise it's debug and then
in Ant it's depending on if you do Ant release. The one basic one we decided to introduce,
that for is this one. Please stop logging too much information. The log buffer is shared
across all applications. Especially don't log information that is just sensitive, put
that -- when we compile a release, we ifelse, and the Java Compiler will discount that code.
You can use that also for whatever else you want. This is one important use case.
Finally, we have made a lot of improvement to Proguard. We have linked the current rules.
What we did is we used to only be able to reference one single Proguard file into your
project.properties. We changed that to be able to reference more than one file. And
we provide a default for into the SDK folder and you can reference to it using the sdk.gear
property. So now you can have your own word file that Google will never touch. Whenever
we do an Android update project we have never (indiscernible) your changes, and then we
can safely improve the Proguard rule. I think people have obsolete files because of that.
We have to optimize and non-optimize. We provide those to you depending on which version, to
choose which one you want. Another thing that we did is we used to be
able to be very conservative about removing classes, another rule five that we use, and
so we know exactly when I XML files are being used. We are much more interested in removing
classes. If you use something like the support library for just one particular small item
that you want, everything else will get removed for you and you will get a much smaller application.
[ Applause ] >>Xavier Ducrohet: All right, Lint.
>>Tor Norbye: We already talked about this. We had a different order earlier. I will show
a couple other things regarding Lint. This is my window. So Lint is -- I showed it running
in Eclipse, but it does not require Eclipse. IntelliJ has integrated Lint as well, and
you can run on the command line. If I go in here, type Lint, I talk point to a particular
project -- one directly. It basically just runs through the code and spits out the errors.
This is not a very useful format, so it actually has several other formats. I can pick a particular
file name like that, and when it runs it now, it creates a report that I can then open.
So when I do that, I get something likes this, which is basically -- it's showing the same
errors I explained to you but a bit more readable. We include the descriptions. We inlined -- for
example in the case of mismatched string format, you can see both cases of the source inline
right here. This is useful. [ Applause ]
>>Tor Norbye: Thank you. The main use case for this is that even though you can run Lint
during your development, you really want to run it continuously on a server along with
your unit tests, right? So I hope that you are familiar with Jenkins which is a continuous
integration server. Someone has contributed a Lint integration for Jenkins. This is the
AOSP project. If you look here, you can see this trend graph showing the number of Lint
warnings currently around 1200. Luckily there aren't very many red ones. We can drill into
this and take a look at them. So this is basically showing all the different folders. We can
swatch back category as well. So here we have a folder that has a red error, and I can drill
in to look at it. We can see -- actually, what is this one? Missing translation. I saw
a worse one earlier. I guess I picked a different one. This is the one I think I was going to
look at. Correct. Yes. So here we have -- someone has used an underscore instead of a colon
in their attribute. This is Lint running on the current sample that we are shipping with
AOSP. So we have a bit of a cleanup job to do. Let me quickly show you how this is set
up. If you go to configure, all I have done is add these two commands here. It basically,
like I showed you, you can do dash dash html report. You can also emit XML reports. That's
what the plug-in is using. That's basically how you set up Lint running so you can basically
blame people when they increase the error count.
At the fireside yesterday someone asked, well, can I add my own Lint rules? The answer is,
yes, you can. It's actually pretty easy. I will very briefly show you how to do that.
So the use case for this will be, let's say, in your company you have a custom view. There
is some attribute that is always set. So to do this, you need two classes. Where did you
put them? Okay. Two classes. Issue registry, which is as simple as this: Register this
issue, and the detector class which basically has a description, ID, summary, and we tell
Lint, hey, these are the elements I relate to. This is my custom view, and when you hit
this element, check that it has the attribute. The way you do this is, you build this file.
You get this custom Lint jar file. You copy that to your .Android Lint folder, now when
I run Lint, it is showing the error, showing the detector that it is added. So I can now
run Lint. I can check the specific issue on this project. It should now emit the warning
that we had in this detector. This is pretty simple. The API is evolving, but it can be
done for today. That's it for Lint for me. [ Applause ]
>>Xavier Ducrohet: All right, so that was it for demonstration. A quick information
about our team. We work directly in OSP. If you want to see what we are doing, Tor should
do some things that are coming, you can go and get it and try it. We have a tools site
where we are regularly posting information and sometimes we post previews, also. So we
encourage you to try it and give us feedback and then if you have questions, if you want
to help us, to contribute, the list is there. You can find us on Google+ also.
And we have two minutes and a half for questions. There's two mics. If you want, we'll be at
the office hours right after. If you have any question, we'd be happy to answer.
[ Applause ] >>> So I had a question about relative layout,
and I use it a lot. It's very useful. However, when I start to refactor elements, it messes
up orientation because it doesn't refactor IDs and other elements.
>>Tor Norbye: I guess I should go and look at that. Would you mind filing a debug, put
the details for how to reproduce it. Any other questions?
>>> Yes, I'm working on a project right now where I have five APKs at once and probably
more in the future and some libraries. Is there anything you can say for multi-APK support.
I have all these bass scripts and Ant in four loops, it's getting really clunky.
>>Xavier Ducrohet: Like building all of them at the same time?
>>> Any suggestions for making my life easier. I have a four-loop with all these Ant scripts
in it. >>Xavier Ducrohet: Seems like a good fix.
>>> I'm working on a project right now, I have five APKs at once, and probably more
in the future, and some libraries. Is there anything you can say for multi-APK
support, because I just got all these, like, bash scripts with, like, Ant in four loops
right now, and it's getting really funky. >>Xavier Ducrohet: You mean like building
all of them at the same time? >>> Any suggestions for making my life easier?
Because I've got a four loop with, like, all these Ant scripts in it.
>>Xavier Ducrohet: Seems like a good fix. I mean, we don't really have a project set
up for that. So any kind of automation, you know, a batch file, another Ant script. If
you have five of them, I think another Ant script that calls your other Ant script might
be better than doing some batch magic. But that's up to you really. We don't really have
anything. >>> Okay. Thank you.
You could put it in line for the future. >>Xavier Ducrohet: Yes.
>>> I've noticed that you've kind of been slowly ramping up support for go to definition
to layout files and, like, string definitions from within the code, as opposed to actually
just going to the R object, the generated object --
>>> Yes. >>> -- definition.
And I was just wondering, it seems like I kind of don't know where -- like, when that's
implemented and when it's not implemented. It would be nice if I could always hit F3
and go to the in-code definition. Are you planning to, like, continue to support more
types of go to definition? Or what's the plan with that?
>>Tor Norbye: Right now, in Java files, it will always go to the R file. And the reason
for that is that we don't have a way to actually give our resolver higher priority than the
built-in Java one. So that's kind of how it works.
>>> That's an Eclipse thing? >>Tor Norbye: It's Eclipse, yeah. We don't
have the option to sort of say, hey, ours is more important than the Java one. Because
when you jump from, you know, our definition to an actual field, that's the Java one. Going
to the XML files, that's ours. And we don't have a way to say ours is more important.
Let us come in first. >>> But it is in some places implemented from
the XML files; right? >>Tor Norbye: Yes, from XML, yeah. Those should
always do the right thing. If they don't, please file a bug.
>>> I don't think they work for strings. But I might have just not checked --
>>Tor Norbye: They're supposed to. So if they don't -- what they didn't work for and which
recently was fixed and I didn't have time to show it, but is, they should now work for
theme references. So the question mark thing that didn't used to work, it should now.
>>> Okay. Cool. Thanks. >>Xavier Ducrohet: We're running out of time.
As we said, we'll be at the office hours on the third floor over there. Feel free to come
and ask us questions. We will be happy to talk to you.
Thank you.