>>Tor Norbyte: We have the slides. >>Xavier Ducrohet: All right. That looks great.
There we go. So that's what we've been working on on the
layout editor. Obviously, it's something that we are going to keep working on. So we'll
get even more improvements. So I wanted to do a quick talk about another
tool that we have that's not technically packaged with the SDK. It's created by Roman Nurik,
who's a different product advocate at Android. And it's a Web application. It's Android Assets
Studio. And it's a Web app that will allow you to create assets.
Now, creating a layout is one thing. But actually, you know, putting logos in that layout is
another thing. And maybe some of you are working alone and don't have a graphic artist to work
with you. So that tool allows you to create icons for your launcher icons, but also the
-- you know, the big 512 by 512 icon that you need to put on Market. And then, like,
notification icons, menu icons, and tab icons. And it's even going to create different style
based on which version of Android, since we changed, like, for the notification icon.
And then you get a big zip file that contains all the icons in every density and so on.
It's very easy to use. You know, if you're looking to get some quick assets, that's a
great way to create some assets and make sure that your application has some nice-looking
icons. So now I'm going to give you a quick demonstration
on some features that we have in the tools that you should be aware of, but maybe are
not aware of. So I'm sure a lot of you have been doing Android
for quite a while now. But I still want to mention that in DDMS, you have that log cat
view. Use it. If your application is crashing and you get a false close dialogue and you're
wondering what's going on. The whole exception has been dumped into logcat. Just go look
at it. If something is going wrong, first reflex should be go to logcat. And then if
it's not there, they try to connect to the debugger and see what's up.
I should have -- there I go. So I have a small application here that's -- okay -- that's
an application that should be showing around here.
So the thing that I want to show you is, you probably know Traceview. Traceview is a profiling
tool that we have. We've had it for a long time. It's -- want to improve it, but it's
there, and you should use it. It's a stand-alone tool, but thanks to actually an excellent
contribution, we have it integrated in Eclipse right now. So that's much better. And it's
very easy to use. So what I'm going to do here is, I'm going to click on that button,
which is going to start profiling my application. Then I'm going to do something with my application
which takes a while. That's fractiles. And I'm just going to click back here. It's telling
the VM to stop profiling, send me back the trace file so I can look at it.
And then you get Traceview directly inside Eclipse. So if you don't know about Traceview,
you can easily, like, zoom in, see here, and you see here the thread that's red that is
apparently taking a lot of time, you can look at the blue, zoom in even more to see what's
going on here with all of those methods here. So you have a lot of things that happens here.
And because it's integrated into Eclipse, you can easily click command and click here
and go -- hmm. You should be able to. Hold on.
Is it.... Maybe not.
>>Tor Norbyte: Maybe not. >>Xavier Ducrohet: So normally -- I think
you have a custom build. >>Tor Norbyte: Yeah.
>>Xavier Ducrohet: So normally, you should be able to just click there and go directly
to the source code. So Traceview is a great way to profile applications.
You can easily either click on that button so, you know, click on that button to start
profiling, do something that takes a lot of time on your application, click back, and
then you get all the threads and everything. And you can also, if you want to really profile
something very specific, there's a class called debug, Android.OS.debug that allows you to
actually start it from your code so that you can do that manually.
The last thing I want to show you, which is a little bit similar that we've had for a
while is this button here, which is basically going to dump an edge profile. So edge profile,
it's a type of profile that contains a profile of your HIP. So if you choose any application
or just use the same one, it is going to instruct the VM to send back the edge profile and it's
going to open it. So what happens is we are getting the edge
profile directly from the VM, and we have to open it somehow. And there's a great Eclipse
tool called MAT, Memory Analyzer Tool, which if you install it -- and it's free. You should
just go on the Eclipse.org Website and download it and put it inside your Eclipse, then it
will open it and you will have it directly. So basically it's opening your file, and then
there's a lot of tool in there. And I am not going into too much detail. There's another
talk after that in this room. No, in the other room, room 9, at 4:15 that actually talks
about memory management. And if we can go back to the -- There we go.
So memory management for Android app, room 9 at 4:15, and you learn all about using MAT
and helping you profile the memory of your application.
So those two small feature in DDMS that also exist in the stand-alone version have been
here for a while but a lot of developers don't know about T those two buttons are really
helpful when you want to quickly dump either the profiling or the memory information.
All right. So now we heard that some developer were having issues with that tool. And we
are very aware of it. Trust me. So, yeah, the emulator running in Honeycomb
is a big, big issue. So we are going to talk about that a little bit.
The first thing I want to explain is that the emulator is not just a small compatibility
layer that exposed tom API to an application to run directly on your host machine. It's
actually emulating a full ARM-based device. It's actually emulating hardware. And it's
running all of Android all the way from the top where you have your application, the framework,
the Dalvik VM, the kernel, and hardware driver. It's like emulating a full hardware.
So this is great for Android because, as you know, an Android application does not just
have a main entry point, you know, a main method that's being called. You can launch
it from the launcher, you can receive like a broadcast, and you have a broadcast receiver
to get T maybe another application is calling your content provider and that launch is your
application. So there are so many ways that we can't really use a simulator that would
just be running a fake version of Android on top of the host. So we have to use that.
So there's two issue with the current emulator. The first one is, as I said, it's an ARM device.
So it's actually executing ARM code, not X86 code which is what we support for the host,
for the SDK, whatever, Mac, Linux or Windows. So that's a bit slow.
It's not that bad. We found out it's not exactly the issue why it's slow.
The other issue is that all of the rendering pipeline is completely software. So there
is no hardware GL. But there's also no hardware composition. It's all software.
And not only it's software but it's software implemented ARM, and that ARM also has to
be translated back into X86 to actually run. In fact, if you run the Gingerbread emulator
in a very tiny resolution, like the smallest we support is probably QVGA, you will find
that, hey, it's actually not bad. It's actually pretty good. And then you create another AVD
and you give it the Honeycomb size tablet and then it's super slow.
So the rendering is really the issue. And we're working on it.
So the way we're doing is we decided the best way to do that is to have full time hardware
rendering in the emulator. And we're working with a company called Graph Tech. They have
a lot of GL expertise, and they are helping us with that. And so the first issue that
we had is that since it's an ARM device, it doesn't know about the host machine; right?
On Android, you can't go and access like the file system of your Windows PC, because it's
really, it's sandboxed. So we had to design a nice and fast pipeline to transmit some
other -- to transmit all the rendering information back to the host machine to have actually
a native application running, and then have hardware support for that.
The other issue is that most of your machines, like on Windows, at least, and Mac, you only
have GL support, but Android use the ES version of that. And although GLES 1.1 is translating
to GL, GLES 2.0 is much more complex with shadows that are not fully compatible with
GL. So we are working on that. It's a lot of work
but we are working on it. So I wanted to give you a quick demonstration
of what happens here. So, now, keep in mind that this is a very
fresh build, but also it's a very ugly prototype, because we wanted to show you something.
So in the -- oh, yeah, so you see the emulator here. If you haven't noticed, starting with
our 9, I think, version 9 of the tools, we have snapshot support. It basically allows
your emulator to boot in like 3 seconds. It doesn't actually boot. It just restart your
previous nonstate. So if you enable that when you create an AVD,
when you kill your emulator, basically it's going to save the state.
Now, if you have an emulator that has 256 megs of RAM, it's going to take a huge size
to save the snapshot in the 5- to 600 megabyte. But then that allows you to reboot super fast.
So when you develop, generally you can use that. It's currently available.
So what I'm going to show you here is that's the version that's not accelerated. And so
this is Google Sky map, that uses GLES 1.1 and you are going to see that it's -- a bit
slow, but that's expected nowadays. Okay.
So it's running 600 by -- 800 by 600, which is slightly bigger than a nexus 1. I am going
to switch to manual mode here and when I move you can see it's clearly not tracking my mouse
very well. It's very slow. So the current version of -- that we have,
as I said, it's a prototype, and all we are doing -- all we are about to do is render
one application and only that one application. Because one of the other challenge that we
have is that the native application that's going to run on your host has to be able to
endure a lot of GL context. It's not just writing one GL application. It's doing GL
context for all of your OS, and you could have several context.
But right now we only support one. So what I am doing here is I am just doing a force
stop on this app. And then I'm going to basically push a file to the emulator to tell it to
basically white list that application as running -- as being able to run in hardware.
And.... There we go.
So what is happening here is that we have another application that's not the GL, the
emulator that's going to do the rendering for the emulator. And of course in the future
you won't have that. It will be just integrated with the front end of the emulator. But right
now, we have that, and it's a little bit annoying because I actually have to do my process here.
And so you can see here that the GL part is there, but the non-GL part is still there.
So it's really the one application. It's just that the GL part is being rendered in another
application. So I am going to do the same thing here and
switch to manual mode. And you can see here when I switch, it's much faster.
[ Applause ] >>Xavier Ducrohet: So you can see that it's
much faster. There's still some issue with all of the input and all of that, but it's
going to allow us to scale to much larger resolution and still have good rendering support.
Log in to save your progress and obtain a certificate in Alison’s free Fundamentals of Google Android Development online course
Sign up to save your progress and obtain a certificate in Alison’s free Fundamentals of Google Android Development online course
Please enter you email address and we will mail you a link to reset your password.