Google I/O 2012 - Android Fireside Chat

Uploaded by GoogleDevelopers on 28.06.2012


CHRIS DIBONA: Hi, my name is Chris DiBona.
I look after a lot of open source stuff at Google.
But you're not here for me.
You're here for the incredibly large number of people we have
on this stage.
And we're gonna start from the far left--
my left your right--
with Dan.
Dan, introduce yourself and pass it down.
I would like to, first, thank you on behalf of the entire
Android team for being here to hear us speak today instead of
being downstairs collecting your free hardware.
So thank you for that.
I'm Dan Morrill.
I do things.

RETO MEIER: I'm Reto Meier.
I'm the tech lead for the developer relations team.
REBECCA ZAVIN: Hi I'm Rebecca Zavin.
I'm the tech lead for the Android systems team.
FICUS KIRKPATRICK: My name is Ficus Kirkpatrick and I'm a
software engineer on Google Play.
DIANNE HACKBORN: My name is Dianne Hackborn and I work on
the application framework.
XAVIER DUCROHET: I'm Xavier Duchrohet.
I'm the tech lead for the SDK and developer tools.
FRED CONTADA: I'm Fred Contada.
I'm the tech lead manager for sync
accounts and data messaging.
MICHAEL SALISKY: I'm Michael Salisky.
I'm a product manager on Google Play.
DAVE BURKE: I'm Dave Burke, engineering director for
platform software and most accurately
described as overhead.

JAMES: Hi my name is James.
I'm the tech lead for media team.
CHRIS DIBONA: You can just keep hold of that and pass it
amongst yourselves.
So the way this is going to work, we have a number of
questions from the moderator instance, which I'm going to
draw from in between your going to the microphones and
asking questions.
It is a fireside chat, hence the fire.
This is a YouTube video called "98 Minutes of Fire." I
scrubbed through it to see if there was anything gross, but
you're all adults, you know.

Because YouTube would never let you down.
That's what I've learned.
So if you guys want to come to the mics and
line up, that's great.
I have no idea how many of you we will get to today.
We have 57 minutes and 41 seconds.
So I'm going to start with some of
the moderator questions.
Are you guys actually lined up for questions or are you just
standing around?
I can't tell.
There's no mic back there.
OK, so you're a questioner guy.
Why don't you kick us off.
Someone here in the room.
AUDIENCE: I have a question.
There seems to be a gap between the build environment
for Eclipse and Ant.
I have, let's say, a plain Java project that I want to
use in other Java projects, not just Android projects.
But I also want to use them in Android.
And it's always kind of a battle keeping the references
in Eclipse up to date and in sync with the references in
the Ant file.
So I'm wondering if there's any way to streamline that or
plans to kind of make them one in the same.
Xavier Duchrohet: Yes.
In your particular case, since you have a regular Java
project, you should be able to just add some custom root to
you Ant file to just reference that and generate the Java
file and drop it somewhere.
And the project then needs it.
It's kind of crappy.
We are well aware of that.
And we actually looking currently at revamping the
whole thing to have one single root system that's shared
across command line, or boot server, and Eclipse.
AUDIENCE: Cool, that's what I wanted to know.
CHRIS DIBONA: Let's go for this fellow over here.
This one's empty, this mic over here, by the way.
Just so you know.
That one's got 20 people on it.
Go ahead.
AUDIENCE: With the Chrome browser now coming on Android,
on Jelly Bean, what happens to the original Android browser?
Does that get taken out of the Android open source?
And also, what happens with WebView?
DAVE BURKE: So the Nexus 7 is the first device that we
actually pre-installed Chrome.

With the Galaxy Nexus, when you get an upgrade from Ice
Cream Sandwich to Jelly Bean, we're not actually going to
pre-install Chrome.
Because some users prefer using the Android browser,
which has flash support, for example.
What we are doing is actually converting the web view that's
in Android to the Chromium-based code.
So we're actually working on upstreaming the code right now
And so then that WebView will become one single browser.
And then organizationally, internally we
sort of combined teams.
So we have Android engineers and Chrome engineers working
on it together.
So it's a grand unification in theory.
AUDIENCE: What happens when, like in the old Android
platform, you couldn't actually update your browser?
And you couldn't update WebView.
So does that mean WebView now will get updated regularly?
Actually, it's a really good question.
So when a new version of Android comes out, the WebView
and the Chrome browser will be one and the same.
They'll use the same WebView.
Then every six weeks, or whatever it is, that we update
Chrome, we'll update the Chrome browser APK.
But we won't change the WebView.
So it will actually be a larger
install because of that.
And the reason we want to do that is we don't want to risk
any compatibility issues with people's applications who are
using WebView.
Chrome works really hard to make sure that every update
that you get is not only on your desktop, it's backwardly
But we're just going to play very careful.
So they're kind of separated.
CHRIS DIBONA: So I'll take one from the moderator.
Google Maps SDK for Android is getting long in the tooth.
Memory leaks, no fragment support, only a
single map per app.
Any word on improvements?

You got it, Dave.
DAVE BURKE: What can I say about this?
Yes, we're working on it.
No ETA on launching it.
But totally understood that the version that's out
there's quite old.
We're just trying to figure out exactly what it is we're
launching and when we're launching it.
So I think I just dodged that question.
AUDIENCE: Say that my app uses the support library.
Is there any work to automatically have that use
the native version of the APIs?

DIANNE HACKBORN: Some parts of the support library switch to
the native versions, some don't.
And that's done based on what makes most sense.
For example, fragments always use one of the support
libraries because you really don't want to get the
different behavior that's in the platform.
It doesn't really have an impact on how it runs on the
newer versions, so we decided that it was best to always use
the one in the support library.
There's a bunch of other stuff, though, that lets you
selectively use newer things in the platform.
AUDIENCE: Thank you.

AUDIENCE: How can we install multiple
versions of the same APK?
Like a product build, a QA build, and a dev build.

DIANNE HACKBORN: Give them different package names, I
guess, is the only answer for that.
AUDIENCE: But that generally screws up our
version control because--
CHRIS DIBONA: Get better version control.
AUDIENCE: Thank you.

CHRIS DIBONA: Will the ability to back up our entire phone to
a computer or some other local storage be
possible in Jelly Bean?
As I understand, this is possible
in Ice Cream Sandwich.
Will I be able to use Android ABB?
So if we're going to answer that, I'm going to say I'm
going to pick things are more developer focused going
forward, just so you know.
As opposed to this very-- what I consider a very
user-focused thing.
Users are great, but go ahead.
DIANNE HACKBORN: So the ADD backup stuff that was put into
Ice Cream Sandwich is still in Jelly Bean.
There were no changes really done to it in Jelly Bean.
I think I go this direction here.
AUDIENCE: So my question's about app discovery on the
Google Play store.
So about one month ago, I released my app
for the first time.
I only got like 30 downloads.
It's a free app.
If you compare that to releasing iOS on the first
time, I got like 4,000 downloads.
It's because, I didn't actually realize, but you guys
removed the 'What's New' section from
the Google Play store.
So there's no way that users can find fresh new apps.
So any plans to bring back 'What's New'?
I know you were getting spammed a little bit, but
maybe you could fix the spam somehow.
Get rid of the spam.
MICHAEL SALISKY: The 'What's New' on a per category basis
is something that we're actively looking at bringing
back in the future.
For app discovery in general, that's something that we care
very deeply about.
We know that you all care very deeply about as well.
So improving, I think, the storefront and making the apps
that get featured there, making a much broader and
deeper list, is something we're looking at.
We also, just today, launched Recommendations.
And so doing personalized and social recommedations is
something that we hope will get a lot more apps in front
of people in a lot more places as well.

AUDIENCE: So with recent phones that are running high
resolutions like 1280 by 800, is there a way to easily
identify if the user device is a phone or tablet?
Because right now, I couldn't find a way to do that.

DIANNE HACKBORN: Resolution doesn't matter, it's DP units.
Actually it's kind of funny.
We have Zoom, Galaxy Nexus, and now the Nexus 7.
There are all basically 1280 by 800 resolution screens.
But they're very different devices, and it's because they
had different densities.
So if you convert those to DP units, then you see that
they're actually very different screen sizes.
And that's why a lot of the newer stuff the platform for
selecting different layouts and stuff
is based on DP units.
AUDIENCE: Can I ask one more question?

So we really like the new smart app update when we
update the delta of the app.
Is there a way going forward for the user to only download
the scheduled image drivers for his own phone resolutions
instead of downloading the whole applications?
Because there's only one resolution that will work for
that device, which is kind of a waste to the user and also
the bandwidth.

FICUS KIRKPATRICK: Yeah, I think that's something that we
want to look at doing.
Right now, we found we got the most bang for the buck by
doing the deltas like you said.
The good news there is that the delta kind of eats up most
of the download that used to have to take place.
I think you could see a lot less disk footprint, you're
right, if we scale things down.
The problem is that we're seeing a lot of these devices
that can operate in multiple densities.
Like you plug it in a TV or something.
So it's a little trickier than you might think at first
glance, but it's definitely something we're looking at.
CHRIS DIBONA: Gifting and promo codes for paid apps and
in-apps purchases please.
One use case is paid gift apps to people who get to read the
development without a hassle.
[? This is reading ?] updates outside of Google Play.
So that's sort of update to Google Play.
MICHAEL SALISKY: Feature request?
CHRIS DIBONA: Yeah it's a feature request.
MICHAEL SALISKY: I think that would be great.
CHRIS DIBONA: There you go.
OK, so find that and start at it.
So we go to you.
AUDIENCE: This kind of ventures away from being an
app developer, but what would be the best thing to focus on
learning to eventually become part of your team?

DAVE BURKE: Skydiving.
AUDIENCE: Thank you.
CHRIS DIBONA: Or rappelling.
So as a developer, WebGL is really, really exciting.
Firefox and Opera on Android offer WebGL support today.
In iOS, you can flip a bit and get WebGL in any WebView.
But for Chrome for Android and the Android browser,
we don't have it.
So when can we expect it?
DAVE BURKE: Good question.
Internally, I've seen it working.
I think the basic issue with WebGL is denial of service and
GPU stability.
So the concern is, you're on the drive-by web, you hit a
web page, and then it pegs your GPU.
Either because it's a bug or because it's malicious.
Or worse it, exposes a GPU bug and your phone reboots.
And so there's some work in Chronos to try to
sanatize it, I guess.
Make it safer.
And so we're just kind of looking at that right now and
trying to figure out if we can release it in a safe way.
And again, Android's platform software has to run across
lots and lots of devices.
And some devices have better, more stable GPUs than others.
So we're just being a little bit cautious about it.
So I think I just dodged that puddle again.
We're working on it, I don't have an ETA, though.
AUDIENCE: Thank you.

So, very exciting stuff announced this morning.
However, that's Jelly Bean, and last time I checked, 7% of
people have still not--
that's the only amount of people we have
on Ice Cream Sandwich.
So my question is, how are we going to get more people on
Jelly Bean so that we can use those features?

DAVE BURKE: Well, we're going to first give you free devices
for Jelly Bean.
That's one quick way to start.
CHRIS DIBONA: How many people are at I/O?
DAVE BURKE: So it's a really good question.
I actually think the acceleration of ICS, Ice Cream
Sandwich, has been pretty good.
Because we only released it, like, literally months ago.
One of the things we're doing--
I'm going to answer at the keynote--
is the PDK, so the platform development kit.
And so what we're trying to do is get device manufacturers
access to the source that we're working on earlier.
So that they can actually work in parallel to us to speed up
the time it takes to get out a new device.
So that's one of the initiatives
we're trying to do.
The other thing we're noticing is there's is a really great
ecosystem built up around Android.
We're seeing device manufacturers getting more
Android savvy.
They're really sharp.
They really know what they're doing.
And so they're actually getting
faster at building devices.
So I think it's going to get better because of that.
I don't have a silver bullet to offer other than that.
The other thing is, I've seen some
distribution curves of versions.
And you've got to remember that we sort of had that weird
stage where we had Gingerbread and Honeycomb.
We were kind of like two versions as we did the tablet
and then we kind of came back together in ICS.
And so I think that sometimes skews data
when you look at that.
I think what you're going to see is ICS
ramp up quite quickly.
And then the delta from ICS to Jelly Bean, from a device
manufacturer is actually quite small.
So I think you'll see, then, the ICS flip to Jelly Bean
more quickly.
That's a prediction.
AUDIENCE: Thank you.

AUDIENCE: How much time do we have to
transition from CT to C--
Help me out here.
AUDIENCE: Right, to the Google cloud messaging.
At what point is the new device registration just going
to stop working on C2DM?
FRED CONTADA: It'll be a long time.
We'll give you plenty of heads' up
before that will happen.
AUDIENCE: Like a year?
FRED CONTADA: Like a year.

AUDIENCE: Is there anyone here who can answer a
render script question?

DAVE BURKE: I can answer easy ones.
AUDIENCE: Regarding shaders and variable packing.
DAVE BURKE: Getting nervous.
AUDIENCE: So in writing my program, I've discovered that
in the data structures that I create, the render script
seems to be converting Boolean and int values into floats.
So if I try and execute an if statement on the structure
member, I end up with an error message saying that it has to
be a Boolean value.
Obviously I can type cast it in the shader to fix that, but
the real issue becomes, it makes it difficult to
properly pack data.
DAVE BURKE: Yeah, I don't know the answer, but I
know a man who does.
So it just come up to me afterwards, I'll get your
details and I'll connect you up.
AUDIENCE: OK, thank you.
We've seen a lot of the exciting stuff from the Google
Maps team today.
And a lot of the stuff is focused on desktop usage
through a browser.
Now when running that on an Android smartphone or tablet
you see that from a user experience point of view, it's
kind of lacking as opposed to the native MapView component
in Android, up to the point where it
becomes barely usable.
What is the way forward in that respect and what should
we do as developers that want to leverage Google Maps
technologies on Android devices?

DAN MORRILL: So yeah, let me just rephrase the question and
make sure I understand what you're saying.
You're basically pointing out that there's a lot of features
in maps that are not necessarily available to
developers via WebView?
AUDIENCE: They are available via WebView,
but it's really slow.
DAN MORRILL: I'm sorry, not a WebView, a MapView.
AUDIENCE: Correct.
DAN MORRILL: Yeah, it's absolutely the case that the
MapView is getting kind of long in the tooth.
It came from Android 1.0.
The API has not changed significantly
really since then.
That is, in fact, something that we're looking at.
We're aware that there's this increasing functionality gap.
It's just one of those things as a being kind of a tricky
problem to solve because it's possible to build a cool, new
version, but then how do you maintain backwards
Do you maintain backwards compatibility?
So we don't have a ready answer, but it actually came
up relatively recently with us and we're working with GEO
team to figure out what the right way forward there is.
So we're definitely aware of that problem and we're looking
into it, but we recognize it's an issue.
AUDIENCE: And what would be the guidelines for
developers right now?
DAN MORRILL: For now, if you can make it work with the
current MapView, go ahead and do that.
But do whatever works for your app.
We don't really have a best practice at this time for what
you should do instead.
AUDIENCE: OK, thanks.
CHRIS DIBONA: So on the [? dory ?]
it says, on the Nexus 7, the notification bar and the
system bar are split similar to phones, rather than
combined such as on current HCIS devices.

Is a similar setup going to be used for 10
inch tablets as well?
So this is sort of like, what happens when the DP
units are to small?
AUDIENCE: What was the question?
Yeah, could you read them slower?
On the Nexus 7, the notification bar and the
system bar are split similar to phones, rather than
combined, as on the Zoom.
Is a similar setup going to be used on future
10-inch devices as well?
DIANNE HACKBORN: Jelly Bean on a 10-inch tablet uses the
system bar like before.
CHRIS DIBONA: Ok, so there you go.

I talk slowly, they get really pissed off.
Go ahead.
AUDIENCE: I had a question about--
more of a hardware question slash viewpoint from you guys.
Most of my organization uses iPhones, and I've basically
been persuading them to start letting people use Android
based phones.
And one of the problems that we've run into is with all the
different manufacturers and phone types out there, some
have external media, or external storage capabilities
and some don't.
And the Nexus doesn't.
And of the other things that's really been a barrier to entry
for my management team people is that you can't just plug it
in and mount it like you can most other--
like the Droid you can, or the Razr Max.
If you plug it in, it just shows up like a USB drive.
And with the Nexus, you have to go into a PTP or MTP mode.
And if you're a Linux user, that's even more of a headache
than it is on Windows and Mac.
So is there a reason why you guys chose to do non-block USB
Or can you to speak to why that is, and if that's
something that you're going to continue to move
forward with that?
Or will be a day where it just mounts like a USB drive?

REBECCA ZAVIN: I think some of that has to do with, a little
bit, about user experience around having that mount as a
USB key, essentially.
I don't know that we have a concrete
plan for moving forward.
I'm looking at Dave.
But I think--
AUDIENCE: Has it been something that anybody else
has mentioned to you?
Or has that even come up?
REBECCA ZAVIN: We definitely know that there are some
devices that do USB mass storage, which is what you're
talking about, and some that don't.
And that we haven't done it on our Nexus products recently.
I think there are some really great user experiences around
PTP, your PPTP and MTP.
But you're right.
You need, like, MTP on Linux and stuff to get it going.
There are some good tools, but like doing anything from
desktop Linux, it's a little bit more complex.
DIANNE HACKBORN: USB mass storage is kind of crummy.
I don't think we really want to do it.
It requires, for example, if you have a 32-gig phone, you
have to partition it into a hard partition between the
part that would be USB mass storage and
the part that's not.
And so being able to not have a FAT file system that has all
the negatives to it that forces you to do a partition
makes a lot things better.
So we've kind of tended to not do those in the newer devices.
AUDIENCE: It seems like that's how the external storage is
like what the Droid does.
That's your USB mass key is that thing.
Whether you pull it out and plug it directly into your
machine or you leave it mounted into your phone, it
just makes it very difficult for me to convince somebody
that they can't drag and drop stuff onto it.
So I was curious.

DIANNE HACKBORN: Dragging and dropping, I think, is probably
the host side's software problem.
There's no reason why you wouldn't be able to have it
all working.
The iPhone does not use USB mass storage, I don't think.

CHRIS DIBONA: There's no way to create an x86 emulator
using, quote, "API level 15 or any other API level." This
prevents us from using an Intel emulator to develop apps
that use maps, for example.
Is support for the Google APIs coming to that architecture?
AUDIENCE: What was the question?
Basically, support of x86 for the APIs and the emulator.
XAVIER DUCROHET: So we are aware that.
Intel is actually the one who worked a lot on making the
kernel for the emulator work on x86 well.
And so they've been contributing some
patches back to us.
So at some point, we do intend to see if we can actually
release that.
Something we haven't released, a Jelly Bean system image
running x86, we're working with Intel to be able to
release that.
But right now, it's kind of like we're not in total
control, because we depend on them on
helping us fix some issues.
But as soon as we can do it, we'll release that.

AUDIENCE: I do Android
development on atypical devices.
Not tablets, not phones.
CHRIS DIBONA: Pacemakers?
AUDIENCE: Say what?
CHRIS DIBONA: Pacemakers?

AUDIENCE: Media set-top boxes.
Specifically for entertainment-based apps and
digital signage, that sort of thing.
And one of my biggest headaches is the media player.
I'm aware, for technical and legal reasons, that you can't
just have one beautiful media player that
works across all devices.
Anyway, so I get all these different devices, and they
always have some different media player under the hood
that works different.
The performance is weird, scales
weird, it buffers weird.
There's something I have to--
whatever shipment of boxes has to work very differently.
I've tried several open-source media players that use NDK and
they've been buggy and also had performance problems.
And so I was wondering, with your greater awareness of the
Android world, if you are aware of any open-source media
player projects that could possibly reduce my headache.
DAVE BURKE: So what version of Android is this?
Or yeah, 4.0.2.
DAVE BURKE: So it really comes down to the hardware decoders
and encoders that you're struggling with.
The Android framework, the media framework's built on
something called Stagefright and then the media player sits
on top of that.
We just introduced some new Jelly Bean APIs called
Actually, James just came from a talk on that.
AUDIENCE: I was in that talk.
DAVE BURKE: Cool, ok so you got it.
The issue, though, is that we just mandate different codecs,
different profiles, but after that it's really up to the
And so it is true that there's some variability on the
hardware codecs.
If we could standardize on them and just go, here's the
codec, we would.
But that would mean it would be software and you wouldn't
have the performance.
But I think, maybe the right answer is getting more tests
on our side to make sure that issues you
run into we can control.
AUDIENCE: I was just curious, are you aware of any
open-source projects out there for it?
CHRIS DIBONA: Not any of the ones that you haven't already
checked out, like MPlayer and VLC.
We know you're looking at that, right.
And they're having their issues.
DAVE BURKE: And open source will be
software-based codecs, probably.
And so you won't get the performance.
CHRIS DIBONA: They tie in to the GPUs a little bit, but
it's a pretty challenging area.

Yeah, I haven't heard of any special program just for
Android in the open source world that's addressed this
any better than, say feel VLC or MPlayer.
REBECCA ZAVIN: If it makes you feel any better, James and I
both spend a significant amount of our time making this
work well on the devices that we ship.
So you're not alone.
AUDIENCE: That's good to know.
Thank you.
AUDIENCE: I work on a Scala plug-in to make it easy to run
Scala code on Android devices.
And one of the things that has to happen is the shrink step
in ProGuard so you get something that can be dexed.
But I end up with the full Scala library that I'd like to
use at code completion time, and then a minified version of
that but I want you to dex.
Is there a way to hook into the Eclipse build tool to do
that so I could make this a really nice experience for
someone just starting out of the box not using Ant or Maven
or something like that?
XAVIER DUCROHET: Not at the moment, but we can talk after
and we can open up some extension point for you to do
that if you want.
AUDIENCE: Great, thanks.
So in the radio interface layer with the Android source
code, there's references made to RIL
version 4 of the interface.
And then it says at the current version is version 6
and I assume it goes all the way back to 1.
But I haven't been able to find any references to the
documentation specifically for this interface.
And by proxy, the AT command set that the radio interface
supports, can we just assume that that's a subset of the
standard AT commands, or are any of the newer commands
supported for SMS or MMS?

DAVE BURKE: You're looking for documentation?
AUDIENCE: Yeah, basically.
DAVE BURKE: Yeah, we don't have as much documentation.
Actually, for the PDK, we're trying to build more
Because what you're talking about the real level is really
PDK-level stuff.
To your question about the Hayes commands, I don't know
the answer.
I'm not sure if anyone else--
Rebecca, if you know?
REBECCA ZAVIN: I think it is a subset, but I don't know.
DAVE BURKE: I think it's also very radio-dependent, as well.
REBECCA ZAVIN: We do support a subset of
AT commands, I think.
AUDIENCE: I guess the question, basically, for the
AT stuff was, can we assume that the AT commands that work
across all devices are on Android and that there aren't
any special ones for Android?
REBECCA ZAVIN: I think that's probably a safe assumption
based on the way that we interact with our partners who
build radios.
But I don't know for sure.
That's a good question to ask on the mailing lists.
AUDIENCE: OK, thank you.
I downloaded the last Google+ version and it's actually
really cool with that menu that opens up.
And I was wondering, it's a UI pattern that was first seen in
the Facebook application.
I was wondering, if at some point, we might get something
like that in the support library.
Because it's really cool and it has been implemented across
different apps in different ways.
And I'm just waiting for one standard.
DIANNE HACKBORN: No plans at this point.
DAVE BURKE: It's a good idea, though.
DAVE BURKE: Spotify does it really well.
Have you seen the spotify app?
Yeah, it's good.
So does YouTube, actually.
The latest version.
No, not YouTube, Google+.
Oh, and YouTube.
So we do, yeah good idea.

AUDIENCE: Regarding the PDK that's being released, is that
going to be targeting the Android
open-source platform as well?
Or is that primarily for OEM?
DAVE BURKE: Right now it's targeted
towards OPMs, basically.

One of the problems is we're kind of a finite-sized team,
and so we have to be careful.
If we were interacting with everybody while developing, we
would just slow down.
And so we decided we would try this approach where we make it
available to device manufacturers.
The explicit goal is to speed up getting devices to market.
That's our first goal.
AUDIENCE: Is there going to be any increased support, I
guess, on the Android open-source side of things?
DAVE BURKE: That's kind of [? orthogonal ?]
to the PDK.

AUDIENCE: All right, I know you addressed the Android
software updates earlier.
But I was wondering, whatever happened to the Android update
alliance which guaranteed, with OEMs, upgrades in two
months after release of device?
DAVE BURKE: Did we say two months?
CHRIS DIBONA: I think that might have been in base-10.
Thought it was base-16.
DAVE BURKE: It was 18 months.
So I think what we said last year--
and I wasn't here last year--
what we said last year was, we would make sure that devices
got supported for 18 months, and so we're
certainly doing that.
It hasn't been 18 months since last year, so you can't prove
or disprove if it's working yet.

It's an important thing.
CHRIS DIBONA: They're going to call you in December.
You know that, right?

It's a good question.
It's something we're working with partners hard on.
AUDIENCE: In Jelly Bean you have the ability to disable
notifications per application base.
Do you have any plans to extend it to more permissions?
Like, say I don't want a certain application to have
internet access anymore.
No, we don't.

CHRIS DIBONA: So the answer's no.
AUDIENCE: One thing I find difficult to do is create
package UI components to share among different applications.
Are there any plans to make that easier?

XAVIER DUCROHET: Do you want to show them just at the
compilation level, or do you want it to be
installed on the device?
Because we're doing that.
You have Android library projects.
So that second one, I don't think Dianne
will say yes to that.
But the first one, we support that at the compilation level.
If you look up Android library project, you can share code
and resources.
AUDIENCE: Right, but you have to actually, at least as far
as I know, you have to include that in your
workspace in Eclipse.
Or, it's very difficult to package that off and give it
to someone as just a jar, for example.
XAVIER DUCROHET: Right, so we do want to go with binary
distribution of that.
XAVIER DUCROHET: So, apparently, IntelliJ allows
you to do that, so you should look it up.
Or Maven.

We do want to support that directly, natively in the SDK
build system.
But, yes there are third parties, support that do that
and you should try them.
AUDIENCE: So is there any plans to support natively?
CHRIS DIBONA: There are two questions in the moderator
that are very, very similar.
And they come down to support for the Now cards, which is
what they call them.
Basically, support for user applications you get into the
Now stream, and tying into Android side navigation.
Asking if there's going to be support in the future SDKs for
some of the new elements.
Make sense?
DAVE BURKE: We have no plans at the moment.
CHRIS DIBONA: No plans at the moment.
So the biggest thing that I find that people coming into
the platform as developers from other systems, and as
well as demands coming from clients, is to show a lot of
downloaded URLs as images.
So dealing with bitmaps, and image views, and list views,
and all that kind of stuff.
And staying within the memory allowment that we have, as
well as dealing with the fact that images are built in on
the native side and then brought over to the Java side
and all that kind of stuff.
Anyways, the point is, it's a really hard problem to solve.
And I look at your apps and they're fantastic.
And you've solved them in some really clever ways.
So are you guys going to open-source that?
Well, not open-source that, because it's
already open source.
But more bring it to a level where beginner developers can
have access to that kind of reliability of a, caching, b,
having nice crisp images and not having to downsample.
And also speed when it comes to downloading and all that
kind of stuff.

RETO MEIER: So one thing which we are trying to do is pick up
a lot of these best practices and make them available as
development training on the newly redesigned site.
So if you have a look at the training section there, I
think we have a class now which talks about how to
download bitmaps efficiently.
If not, then I guess that's something
which is coming soon.
We're definitely trying to collect up that knowledge,
that best practice, and make it more readily available to
developers which don't want to have to troll through all of
the open-source code themselves.

FICUS KIRKPATRICK: We actually also have a ready-made jar for
exactly this thing that's coming soon.
It's just not ready yet.
But the idea is that a really typical pattern is you have a
list view and an adapter and it has thumbnails and you're
getting them from the network and you need to deal with
recycling the views and everything.
We're hoping to have something kind of plug and play you can
link in your app soon, it just wasn't ready today.
AUDIENCE: Is it anywhere in your site to just increase the
amount of memory we have access to as an app?

DIANNE HACKBORN: The memory has been increasing pretty
regularly, especially as the screen sizes increase.
There also was added in--
Honeycomb was the option to set a large memory size.
So if you have applications that do need a lot of RAM,
they can say that they want to have a higher memory limit.
It's always a trade-off between the RAM for that
application and, it could be used elsewhere to keep other
applications around so you don't have slow switches to
other applications.
So we do want developers to pay a lot of attention to the
RAM use and not just gratiously go, I'm going to
use a bunch of RAM because it's easier.
AUDIENCE: Thank you.
AUDIENCE: I might have missed this during the keynote, but
are there going to be any APIs for the new Voice Search and
Google Now that we can access?
DAVE BURKE: That was a question that you read out,
but no one understood you.
AUDIENCE: And also, just kind of off-topic, that I was
reminded of on my way here from Sacramento.
I used to have separate volumes for navigation and
that disappeared after Gingerbread .
Is there any way to have something like that back?
CHRIS DIBONA: We found people just weren't listening.

DAVE BURKE: James is saying no.
I'm going to hand you over to James.
DAVE BURKE: Thank you.
AUDIENCE: One of the things that I've liked that was
introduced in one of the more recent Android developer tools
was the Lint error checking.
And is there any thoughts on allowing the developers to
have their own test cases, basically?
For instance, to make sure that a texture always has a
color set, or something like that.
We actually have an API for it.
We just haven't actually finished integrating that into
the Lint tool so that it picks up jar coming from you.
But it's ready.
We just need to finish that.
But it's ready.

AUDIENCE: What is the best way of merging the data from your
own content provider with data from other
content providers available?
Performing some computation on that data beyond simple joins,
and then feeding that data into an adapter, cursor
adapter, for instance, and displaying a place view or
something What do you recommend?
Because I've been struggling with this.

DIANNE HACKBORN: It depends a lot on
exactly what you're doing.
AUDIENCE: For instance, I know there is CursorJoiner,
MagicCursor, MergeCursor, or something like that.
But I don't know which is the best way of integrating data
from multiple providers on the fly.

DIANNE HACKBORN: I don't know the details of all those
different helper classes.
Basically you're going to want to do something so that, as
you iterate through the different cursors, that you
don't have to look ahead.
ideally, you'd want to be able to basically keep a position
for each of the cursors and just returned the next result.
Because if you start to look ahead, then you're going to
have to do big queries across all of them.
And if you have a lot of data, then you have to re-query as
you go down the cursor.
AUDIENCE: Yeah, but how do I--
For instance, I want to merge something from my own provider
with something from the contact's contract and display
that in a list view.
So far, what I did is manually doing that and putting all the
data in MagicCursor, and then feeding that to CursorAdapter.
But what I found strange is that you can put anything in
MagicCursor, you can put any kind of object, but you can
only take out primitives and strings, basically.
Why is that?
Why is it this limitation?
DIANNE HACKBORN: I don't know that.
DAVE BURKE: We have office hours, actually.
I think they're on tomorrow as well.
So this is kind of like an in-depth question, but if you
go there I'm sure there's somebody who
can probably help.
So I think it's on the third floor, Android office hours.

Can an Android APK package be signed with multiple

DIANNE HACKBORN: You can do it, but you really should not.
DAVE BURKE: That's Dianne saying no.
DIANNE HACKBORN: The model is, you have your own self-signed
certificate, and that is your identity, and that is the one
you should use to sign your APK.
AUDIENCE: Let's say I have a dependency on some third-party
vendor, and so I'll have to get it signed by them.
So say my version one doesn't have that, and say my version
one has a certificate that is what I own.
And my version two, I depend on some third-party vendor
because I'll have to give it to them for signing.
How do you manage that, or is that manageable at all?
DIANNE HACKBORN: If you're signing it with a different
certificate, then it is a different identity.
It's a completely different application, and so you can't
treat it as the same thing.
You should give it a different package name.
One more question.
Is there an in-build WebView kind of a thing that can
render or open documents securely within your

DAVE BURKE: I think it's intent-based right?
AUDIENCE: Yeah, it's intent-based.
So I don't want to give the documents that are there
within my application to some other application for opening,
because they can do anything with their document.
I want the security of opening or viewing the document.
Other than [INAUDIBLE]
a document viewer, is there any other way that I can
somehow render a document in my--
DIANNE HACKBORN: There's just WebView.
And of course, TextView.
AUDIENCE: Well, for TextView even, you have to write your
parses for whatever format is directed.
Say you have a PDF document, then you'll have to write your
parses for extracting the text and then
rendering it in TextView.
So apart from [? breaking ?] that, is there something?
DAVE BURKE: Not today.
I'm a big fan of library projects,
which are quite awesome.
But my workspace got really messy lately with have
ActionBarSherlock having version four, version 3.5.
And I tried to solve if with Android maven again, but IDT
doesn't take the dot ApkLib file as a library project, so
I have to switch again the library from
one version to another.
So do you plan to manage that kind of file?
XAVIER DUCROHET: Yes we do want to support the binary
distribution similar to ApkLib.
I don't know if it will be exactly the same, but it's
pretty simple.
So we will would probably support that at some point in
the future but not right now.
Thank you.
In terms of portability and performance, it's hard to beat
native code.
But here at Google I/O, it doesn't seem to be
getting much love.
Why is that?
DAVE BURKE: In terms of portability, it's hard
to beat Java code.
DAVE BURKE: That's because you don't have all
the different hardware.
It's a good question.
The problem is that Android is a program that runs across
lots of different types of hardware.
And so we favor Java because it gives you that portability.
The problem is if you write everything in native, then you
have different types of ARM CPUs.
You now have x86 CPUs.
You're going to have new architectures in the future,
and so it's not as portable.
DIANNE HACKBORN: And there's a render script, too, as an

AUDIENCE: I was wondering have you guys
considered buying Swipe?
DAVE BURKE: Let me open up the financial statements at Google
and explain where we are.
AUDIENCE: I just think it's the greatest keyboard.
My dad, who's technically not into it, if you
will, to put it nicely.
He loves and he uses it every day.
So if he can use it, I think it just kind of speaks to how
great a keyboard it is.
DAVE BURKE: It's funny.
I see some people really love it, and other people like the
more traditional ones.
But, yeah, I definitely shouldn't talk about
DIANNE HACKBORN: We put a lot of work into the implemented
framework to allow you to replace the keyboard.
And so I think it's actually great that they have a great
keyboard that you go and buy, and support them, and use it
if you want to.
AUDIENCE: Yeah, but they're not in
the market and they're--
DIANNE HACKBORN: So you should talk with them about going
into the market.
AUDIENCE: That's why I'm telling you guys to buy them.

I have a question related to enterprise apps.
I was wondering if the panel can share if there is any plan
to open up API to manage 802.1x key management?
And I'm especially interested in on-campus networks.

DAVE BURKE: I think you
successfully stumped the panel.
Sorry, we don't have anyone from our
enterprise group here.
DAN MORRILL: That's actually a different group within Google.
So we don't really have an answer to that.
CHRIS DIBONA: Is this the Cisco thing again?
The Cisco 802.1x stuff?
AUDIENCE: 802.11 on-campus networks.
So, whereby--
CHRIS DIBONA: I think Cisco actually did some drivers.
I'm not vouching for them.
But you might want to talk to them.
They might have something for you.
Like I said, I haven't used it myself, but I remember them
having a similar problem.
AUDIENCE: Understood, thank you.
CHRIS DIBONA: Yeah, so I would look for them online.
AUDIENCE: I'm really excited about the announcement about
the PDK this morning as a device manufacturer.
And I have a question about it.
They say it took two to three months to apply to release it
And the other question is, in case we look at the two to
three months that's before release, it
must be immature Android.
And how can you describe the difference between current
Jelly Bean and two, three months before?
How can you describe it?
DAVE BURKE: So it's still really early.
What we're going to try to do is, let me see
if I have this right.
We want to get into a rhythm where let's say you have a
device brought up on Jelly Bean.
So you've got the Jelly Bean open-source.
And we're working on K, whatever that is.
Any suggestions for names, by the way?
AUDIENCE: Key lime, key lime pie.
So, we're working on Keylah--
Key lime pie.
DAVE BURKE: Oh, key lime pie.
So we're working on Key Lime-- it's not official, everybody.
So imagine we're working on 'K'.
What we want to do is make sure that your device that's
already running on Jelly Bean can actually start running on
an early version of K. So we want to make sure that the
HAL, the hardware abstraction layer, is forward compatible.
Did I get that right, Rebecca?
I think I did.
And so the result is that it should be much quicker to
bring up your device on the next version.
And then we finally drop the full source and open-source,
your device should basically be up and running.
That's the idea.
The specifics of how this all works and the exact timing,
like is it two months, is it three months et cetera, we're
still working that out.
This is our first cycle through it.
I think we mentioned this morning we've already given
some of our partners the PDK.
So it's very much a work in progress, but it's looking
kind of promising, so far.
REBECCA ZAVIN: And to be clear, that doesn't work
today, the forward
compatibility of the HAL layers.
That's something that we're working on.
But the goal is for you to someday be able to run your
JBSB, if you're a [? southern ?] vendor, against
K and vice versa.
But, like I said, that's a goal.
AUDIENCE: And in case of, talking about the hardware
abstraction layer, the participation of the chipset
vendor is very important.
And in case the device is, for example, our chipset is not
the one for use for the Nexus devices.
Do you see the major chipset vendors
participating in the program?
REBECCA ZAVIN: We've already taken some feedback on things
in the PDK, or things that were missing from the PDK,
from some of the partners we've shared with.
And the Nexus devices are not all on one chip set.
So I think we have some experience, now, with making
these kinds of effort to work across
different kinds of hardware.
That's something that, in the beginning, we were kind of a
Qualcomm house, and we didn't know how to do that.
But I think we've gotten a lot better at it.
So we're definitely going to be taking feedback on it.
The systems team is interested on making your life easier and
making it easier to bring up Android.
It makes our lives easier, because we bring up Android on
new hardware, too.
So we're actively interested in what are the holes, what
needs to be that isn't there, what's there that you wish
weren't there, things like that.
And how your time to bringing up a new Android release on
your hardware can be shortened.
Thank you.
CHRIS DIBONA: Just so you know, Key Lime's not official.
I think we should let Krispy Kreme and Kit Kat bid against
each other.
It would be auction-based.
It would be very Google-y.
DAVE BURKE: I like Key Lime.

AUDIENCE: When will the 'requires smallest width DP'
attribute in the manifest actually be used for filtering
in Google Play?


I don't have a good answer for you on that right now.
It's been kind of a trial migrating from the old screen
size buckets to the newer and better smallest-width stuff.
But, soon.
It's on our radar.
AUDIENCE: I just thought it was odd that it was--
I saw it there, and I thought, oh great I can not have it be
downloadable on certain devices.
And then I put it in and it didn't seem to work.
And then I realized that it's not actually
being used for filtering.
FICUS KIRKPATRICK: I agree with you.
DAVE BURKE: I was thinking more about the desserts.
What if we started going backwards?
Like, we go like J and then go I and then start going to H.
That would kind of be fun.
Do you think I threw them off?
CHRIS DIBONA: No, I'm actually all for it.
I think we're going to be really stuck at Z, and then
we'll just have to go backwards anyway.
Switch over to umlauts, you know.
DAN MORRILL: Sooner or later, we have a modular problem.
So we might as well just the bullet now and start--
CHRIS DIBONA: There's probably some German desserts that have
umlauts that we could use.
DAVE BURKE: That could work.
CHRIS DIBONA: But that's not they're here for.

AUDIENCE: Asking about the audio manager APIs within ICS.
It seems the notification stream and the ringer stream
have kind of combined into one, even though they're not
combined in the API.
You get a lot of users who complain about that.
Maybe you could explain the thought behind that.

DAVE BURKE: It was a user experience decision.
Do we have anyone from UX here?

AUDIENCE: I've got a lot of users who don't like the
I prefer the experience, but when it was a configuration
option before, you left it up to the user.
And now they don't have a choice.
DAVE BURKE: We have an internal meme, which, whenever
this topic comes up--
and somebody will always post a picture, which is, 'add
another setting.' And then they show this picture of this
huge mixing desk.
So I think the UX guys were basically trying to simplify
the experience.
I think there are some group of people who want that extra
level of control.
I don't know what the right answer is, but, yeah, we're
aware of the feedback.
DAN MORRILL: Another thing to point out there is, yeah, you
get you get complaints from users who want the
We got, probably, even more complaints from users who
didn't understand what was going on.
And so we totally hear where you're coming from on UX
decisions like that.
But our decision making process includes the broadest
number of users possible.
And so I'm just putting that out, just to kind of consider
both sides of the coin as well.

AUDIENCE: Hi, just a statement and a question.
First the statement.
I think Key Lime Pie is a great name.
They're very delicious.
DAN MORRILL: We decided we're going backwards.
It's I next now.
AUDIENCE: So my question is, I'm working on a suite of apps
that are not for consumer use.
We want to control what applications you're running on
the device.
In particular, we want to prevent users from getting to
the browser in the settings, and possibly Angry Birds.
Because people shouldn't be doing that at this time.
Anyways, digressing.
We have a service that is running a thread that is
scanning the log rapidly to see when an application has
been started.
And if one of the blacklisted applications is started, we
switch out of it and kill it.
I feel it's a really clunky way.
It's probably going to drain the battery really quickly.
Is there a more elegant way to do this?
DIANNE HACKBORN: Yeah, so from the platforms perspective,
that's a malicious application.

AUDIENCE: That's why I said not for consumer use.
DIANNE HACKBORN: Yeah, so you'll find, over time that
the platform has gotten much more aggressive about finding
things doing that kind of stuff and stopping them from
disrupting the user experience like that.
The answer, at this point, is that you need to do your own
build of Android that has these restrictions.
We don't have an application API to do that kind of thing.
AUDIENCE: So are you saying that our solution will
probably stop working in future?
DIANNE HACKBORN: I would not count on
it to continue working.
AUDIENCE: Awesome, thanks.

DAN MORRILL: Actually, I think it probably
broke in Jelly Bean.
DAVE BURKE: Now that you tell Dianne about it, it's
definitely not going to keep working.
CHRIS DIBONA: It sounds like he wants to start his own
build team, so.
Just wondering if anybody on the panel can speak to any
upcoming changes in Dalvik.
Maybe some optimizations in the Git, JC optimizations
coming up in Jelly Bean.

DAVE BURKE: Not right now.
AUDIENCE: No answer?
CHRIS DIBONA: I don't think we have the right people up here.
DAVE BURKE: We don't have anyone from the Dalvik team
today, sorry.
CHRIS DIBONA: I would find them during the office hours
and hammer them on that.
Very nice to meet you.
I do, in fact, have one kind of performance issue.
Sometimes, we've found that one's system
memory is very low.
I think it is less than two megs.
It's very easy to find that the tablet could reset.
We checked the logs.
It's always matching the widget or codec in the
[? detector. ?]
The response from, for example, the activity manager
service, some core service.

I want to know, is it normal behavior?
Or do you encounter this kind of issue on your side?

DIANNE HACKBORN: You mean two megs of RAM across the entire
system is free?


The result is, the system server was killed.

DIANNE HACKBORN: That sounds like a device that doesn't
have enough RAM.

There's the out of memory killer that has these
parameters for when it kills processes and stuff.
And it will not kill the system process unless it's
very, very, very--
It should never kill the system process.
So there's something going wrong there, that, either the
out of memory killer is not working or
something like that.

This is kind of a debugging thing that we probably can't
really address here.

AUDIENCE: I feel a little strange.
Normally, this program is awkward when we play the
[? peak ?] game.
And so normally, no memory kill should work.

It's very strange.
DIANNE HACKBORN: Could you find me after this and I can
talk with you about it.
No problem, thank you.
AUDIENCE: So on the Honeycomb tablet, we found a lot of
issues with video playback and segmentation for issues.
So we found the same issue addressed in the Ice Cream
Sandwich and also the [? Eclair ?]
[? beta ?].
Is there a way for you guys to push the Ice Cream Sandwich
for an old device to make sure the future one is updated to
the same level.
Because it was very difficult to develop when Honeycomb
stopped doing so well.
JAMES: Well the different devices have different
hardware accelerated codecs on it.
So that's difficulty for us to enforce, say, the same level
of performance across different devices.
But one thing we probably can improve is, in the future, we
will probably provide somthing like a profile based CTS test,
so that we can say this device passes this profile.
Meaning like a medium performance, or another one
passes another profile.
So that we probably can provide guidance to the user
of the device.
AUDIENCE: But I think it's a bug in the system for my case.
Because it is running into a segmentation fault when I have
a continuous playback.
So I assume there's a bug fix to the older
device or the tablet.
Or making sure they updated Ice Cream Sandwich, because it
seems to fix it.
Then that probably seems like a bug in a driver, maybe.
AUDIENCE: So, you guys don't have a plan for, for example,
the Zoom or like an older Galaxy to fix that?
JAMES: Well for the Jelly Bean release, we actually have a
refresh to Zoom device.
Also, even for a Nexus S device.

I like doing library apps a lot.
But sometimes, you can have a suite of apps and they all
have the same core.
And it seems like including the library in every single
one of them is excessive, it's just bloating each one.
Is there any plans of allowing something like a dependency on
application someplace?
So that if you want to install one APK it depends on another
one or it can just download both.
And then if I install a second one, which is also depending
on that APK, it's already there, it doesn't have to
download it.

FICUS KIRKPATRICK: I'll take this.
Short answer, no.
I think that if you look back at something like Windows,
with all the VB runtime deals or whatever, you can see where
this ends up, right.
And we're trying to learn from the previous mistakes of
others, right.
You end up with app A and app B, and one of them depends on
some particular bug compatibility
mode and that thing.
So it is a trade-off, right?
You trade a little bloat for statically linking, versus
knowing that the thing that you shipped with stays that
way forever.
Now again, I think there are things where we make that
trade off in the platform.
We add new APIs and things like that, and it's expected
be backward compatible.
But the short version is, we think it would
just become a mess.
CHRIS DIBONA: So this is probably our last question.
AUDIENCE: Excellent.
So, low latency audio.
We've heard quite a bit about it today.
What kind of improvements are we seeing in Jelly Bean?
What percentage?
How fast?
And also, beyond that, the low latency manifest flag and when
it's actually going to be, maybe, useful or anyone's
going to use it or care.
DAVE BURKE: So what did you hear about
audio latency today?
AUDIENCE: They'd been mentioning it in the Android
chat this morning.
DAVE BURKE: Yeah, it's a work in progress.
So to give you a bit of color on it--

We introduced [? Micala ?] fast mixer.
So for soundpool, tone generator, and open SL, will
actually run through a fast mixer, which
will reduce the latency.
Now it turns out the latency targets we're going for,
they're sub 10 milliseconds on warm audio playback.
Once you start getting into that level, anything at all
that's in the system that's preempting you becomes
And so we're now at the level of devic-dependent issues.
So on the Galaxy Nexus, I think or latency's gone from
about 100 milliseconds in Ice Cream Sandwich down to about
12 milliseconds.
But that's not good enough.
We want it to be below 10, and we want all our
devices below 10.
And all our other devices they we're updating to Jelly Bean
are not as good as that, for various reasons that we're
working on.
And so I think you'll see, in the next update
we'll do even better.
We want to get to a point where we mandate a minimum,
excuse me, a maximum latency.
And we're just not quite there yet, but we're making good
progress toward it.
AUDIENCE: And are you going to be working with any
manufacturers in particular to encourage the drivers to be
fast and this type of--
DAVE BURKE: Yeah, definitely.
One of the tools I mentioned at the keynote this morning
was Systrace, where you can actually look into the system
and see what's happening.
We originally built that for--
We call it jack busting, not butter, by the way.
That was a marketing term.
So we built that for jack busting, and it turns out
that's actually really good or audio as well.
If you had a glitch in audio, you can see what happened in
the system.
Like, maybe Wi-Fi driver thread was running at a higher
priority than the auido thread and starved it, et cetera.
Or there was a hot-swap of a CPU in or out.
And so we're working through all the
different issues, basically.
So watch the space, it will get better.
AUDIENCE: Awesome.
Thank you.
CHRIS DIBONA: And that's all of our time for today.
Thanks to the panel.
CHRIS DIBONA: If you have any further questions, there will
be office hours tomorrow, it sounds like, as well as people
milling about to help you.