Google I/O 2014 - Android fireside chat - VoiceTube: Learn English through videos!

Subtitles section Play video

RETO MEIER: All right.
Good afternoon, everyone.
Welcome to this year's Android Fireside Chat.
My name is Reto Meier.
I'm part of the developer relations team at Google
and I'm joined by some of the most important people
on the Android Engineering, Design and Product teams.
The purpose of the fireside chat is basically
to let you guys ask questions from these people, all
of the stuff that you want to know about Android,
where it is, what we've announced today,
how things have been done, how some of those decisions
have been made, all of those sorts of things.
So it is a Q&A session.
We have mics at the front and middle of the room.
If you have a question, please line up, ask.
If there are no questions, it'll be a really short session.
We do have a few from online which
we've collected in the weeks leading up.
So I'm going to ask some of those as well.
While you guys are getting ready to ask questions yourself,
I'll ask the panel to introduce themselves,
just who you are and a little bit
about what you do at Google.
Maybe start with you, Gabe.
GABE COHEN: I'm Gabe Cohen.
I'm a product manager on the Android OS.
I also work on Google Play services
and a few other things.
XAVIER DUCROHET: Hello, I'm Xavier Ducrohet.
I'm the lead for the Developer Tool and the SDK.
ADAM POWELL: I am Adam Powell I'm
a framework engineer on the UI Toolkit.
RACHEL GARB: Hi.
I'm Rachel Garb and I'm an interaction designer
on the Android OS.
JHILMIL JAIN: Hi.
My name is Jhilmil Jain and I lead user research for Android.
CHET HAUSE: I'm Chet Hause.
I'm an engineer on the UI Toolkit team.
DIANNE HACKBORN: I am Dianne Hackborn.
I'm an engineer on the Android Core Framework team.
DAVE BURKE: Dave Burke.
Engineering Director.
I work on the Platform and Nexus devices.
FICUS KIRKPATRICK: I'm Kirkpatrick.
I work on the Play Store apps and games and hardware.
MILES BAR: I'm Miles Bar, I'm the engineering manager
for the apps part of Google Play.
RETO MEIER: Thanks everyone.
All right.
Let's get started.
We've got a line at the back.
So, why don't we start with you, sir.
AUDIENCE: My question is about Java 8.
Will it be coming to Android?
And if so, when?
And will it be supported on all the versions as well?
RETO MEIER: It's like a hot potato question.
Oh, the mic's going to Xav.
CHET HAUSE: Usually any question that has the word will in it,
you might want to think about it.
Because I'm not sure the answer is going to be what you want.
In general, can we say the general policy, which is,
we don't really talk about stuff that we will do in the future.
Just so you know.
Let's just lay the groundwork out there.
Xav, go.
RETO MEIER: Now, answer the question,
Xav, What will happen and when?
[LAUGHTER]
XAVIER DUCROHET: I have no comment.
[LAUGHTER]
RETO MEIER: Perfect.
All right.
Now you can all see me as well.
All right.
Let's try another question.
Hopefully one which we can actually answer.
AUDIENCE: Hi.
This is for Dianne.
First off, I really appreciate all
of the work you've done on Binder.
And I know that it sits at the heart of everything that
is Android at all.
And I just wanted to ask you, you've
been involved in Binder development
even before Android was Android.
Can you talk a little bit about the history of Binder
and your work with it?
DIANNE HACKBORN: OK.
Well, thank you.
Oh, well I, So Binder started out in BOS
and has been something that I was--
I was not main person who did Binder.
I worked on it as an engineer at BE, then at Palm Source.
And then we kind of adopted it just for IPC in Android.
But actually, I don't even think it's the core of Android.
It's a convenient way to do IPC on the Android.
Previous versions of the Binder were actually much more core
to the platform design.
So today it's a really nice way to do capability based IPC.
RETO MEIER: Fair enough.
Thank you.
All right, I'm going to ask one of the questions we received
online earlier.
I think material design is one of the most interesting things
that I saw come out of the keynote today.
So I was wondering, what sort of research
did we do to be able to come up with some of those ideas?
JHILMIL JAIN: Thanks.
I think for the first time at Google,
the researchers came together across the company
to work on medieval design.
So we had researchers from 15 different groups
and four different Google offices come together
to do research.
And we conducted research on four main areas.
The first was components, which is containers and elements,
patterns and layouts, which is like the floating action
button, motion and accessibility.
So some examples of the types of research
that we did, was first, we explored and validated
key design principles, such as really figuring out
the motion curve and speed.
Second was that we highlighted key usability issues
that designers should be mindful of.
For example, when picking the color of the floating action
button, making sure that it doesn't
blend into the background like it was in some mocks
that we exploded earlier.
Or making sure that the fabs, the size of the fab
wasn't, or floating action button
wasn't like varying within the app
because that would confuse users.
And third is that we conducted a whole bunch
of accessibility studies that led
to a number of design changes.
And one such design change is that we
have now a much improved color palette, which
takes into account the color contrast that
is required between type and the background.
So now our low, vision impaired users
can actually read the text a lot better.
DAVE BURKE: If you're wondering what a floating action
button is, because I didn't know what it was until a week ago,
it's actually an image view.
It's where someone's called set elevation on the view.
Just thought you should know.
But it looks cool.
And it's round.
Does it have to be round?
So the dialer one's the floating action button.
We need a translation between you and engineering.
RETO MEIER: Question for Xav, I think.
I will quote it out to you.
Considering its performance, why not offer Genymotion
as the official emulator for Android?
[LAUGHTER AND CHEERS]
XAVIER DUCROHET: It's a good question.
First of all, I think it's a great product.
I think they are not quite free, though.
So there is a demo version.
I don't know exactly what the demo is.
But I think that's what I sense, that you
have to pay for to get some things.
So we can't quite distribute that.
The other thing is that, obviously, we
need to improve a lot, the story there.
We have, one other thing that we really want to do
is a low eliminating already, all the ecosystem.
And that means also AUM and MEEPS.
And they go mostly with x86 for performance reasons
which totally makes sense.
But we have to sleep on that.
And we do want to support a lot more hardware in the long term,
like Bluetooth, multi-touch, and things like that.
And it's a lot better, if we control
the own stack, the whole stack for that.
And so we want to keep all technology to do that.
But it's a great product.
You should definitely try it out and use it
if it fits your needs.
RETO MEIER: Thanks.
Let's take another question from the crowd, at the back.
AUDIENCE: Sure.
Just curious in Android L, what's
new with adaptive bit rate video and HLS support?
DAVE BURKE: OK.
So, let's see.
The most interesting thing we're doing.
And I'm not sure if it's launched yet
but it's imminent is, we're going
to open source something we call XO Player.
This is the player that's in YouTube and in Play Movies
and TV.
And it's built on MediaCodec, MediaDRM, and MediaExtractor,
MediaCrypto.
It's a really good adaptive bit rate player.
It uses Dash.
So that's one thing to know.
And then I'm pretty sure we've updated to the latest internet
draft of HLS in L. And that's all
I can remember that we've done so far.
AUDIENCE: Thank you.
RETO MEIER: From the front.
AUDIENCE: Hello.
I've seen the new UI and UX you have
prepared for the L release.
I was wondering, I've seen that in the action bar, where
we used to have the up navigation affordments, now
we have what looks like a back button.
What's going on there?
Is it changing?
Are we giving up on the app navigation?
So what's going to happen?
ADAM POWELL: So the short answer is that structurally nothing
is changing in that navigation.
Some of the stuff that was shown,
I think during the keynote, there
was a demo of multiple Chrome tabs opening
in different documents within recents as well.
So some of that is going to subtly change just
as a result of that new feature.
In terms of the iconography, unfortunately I
don't think we have a representative
from our visual design team here,
but Rachel do you want to talk to that?
RACHEL GARB: Yeah, I believe it's just that an arrow really
clearly says for most people, this is what I wanted to do.
want do what I was doing before.
Whether it's hierarchical or historical.
AUDIENCE: Don't we have the back button for that?
ADAM POWELL: There is.
And what, Go ahead Feel free.
So what we found is that, and again, even just
in terms of some of the research that we've done with this,
users tend to really think either in terms
of the system or the app at a given point in time.
And having that extra affordance be sitting there
in the app, very clearly in the app in the bar,
is something that they much more closely tie to,
I'm going to continue acting within the context of this app.
Whereas the Back button in the system
is really seen as more of kind of meta action
that can act between apps.
Even though a lot of users aren't
able to clearly articulate the difference between these two,
and even though the iconography is very similar, what we found
is a lot of users tend to develop this really intuitive
understanding of what to expect when they press either one.
Now, of course for developers, this is really interesting
because it means that there's a lot of subtlety to really get
this right.
And we're really hoping that some of the new functionality
that we've exposed to open documents in more recents tabs
will really help iron out some of the rougher cases that
have come up along with this.
So definitely stay tuned for more of the published
guidelines around how to use that effectively.
AUDIENCE: OK.
Thank you.
RETO MEIER: Thanks.
So I think seeing the keynote this morning
and all of the awesome changes from material design
and how good that makes apps look,
I think one of the questions that I have,
and I think, some other developers,
how much work is it going to take
to get an existing app which already looks good,
follows the Android design guidelines,
and turn it into something that's
a great example of a material design implementation?
CHET HAUSE: A bit.
RETO MEIER: Thank you, Chet.
GABE COHEN: I think you were supposed
to plug the talk for tomorrow.
CHET HAUSE: Right, so, Go see the talk tomorrow.
Answer over.
So, in fact, there's two talks on material design,
sort of the engineering side of that one with Adam at 11.
So you can go there if you want a little bit more information
about there, where we talk about things like this.
So there's sort of a gradient of how much work
you want to take on to get toward the vision of what
your material design app will be.
The first step is not that bad.
Which is basically enable the material theme.
then, if you're using custom apps, custom views,
in your system, then you may need to fix up some of those.
If you have assets that were created
with other themes in mind, maybe they
look a little bit out of place.
So we basically see it as enable the theme, spot
fix as necessary.
And that's kind of the minimum bar to be a material app.
And then after that, you can say, well,
what is the material design actually going
to be for this app, with different padding,
different lay out, and then what does that necessitate in terms
of the functionality that I need to change in my app.
And then, you can figure out how far down that road
you want to go.
And I should also point out that a lot of that work
is actually just using APIs that already exist.
They're not new APIs in L. So it's not
like we expose this huge new surface area of APIs in L
that you have to use to be a quantum app.
It's more that we have new capabilities
to do things like Real-Time Shadows
that we use internally to get elevation for views
when appropriate.
You can access those if you want,
if it's appropriate for your application.
But most of what we're talking about
is simply new design along the paradigm
that we talked about with material design.
And then the work that you need to do, just traditional Android
development work for layouts and padding and assets
to realize that design.
ADAM POWELL: The nice thing a lot of this,
as well, is that if you followed some of the design
evolution of a lot of big Android apps
in the last few years, you'll notice that a lot of them
have been moving in this sort of direction to begin with.
You'll see that a lot of things are contained on surfaces.
You have drawers that slide out over scrolling areas of cards.
You have a lot of these very similar patterns that
have really been kind of kicked up for material design
and refined.
So if you've been sort of following along
in a lot of the footsteps that have been blazed before this,
then I think you'll find that the workload to really go
that extra step isn't quite as much as it
looks like in the first glance.
GABE COHEN: I should also say material design's one
of the big drivers behind us doing the L Developer
Preview this year.
I definitely recognize that it's going to take, quote,
a bit of effort for people to adapt their apps.
We wanted to give people time to do that in advance of consumers
getting the full sweep of apps from Google in that theme.
But we also want to give people a chance
to give us feedback on where it works for them.
Where it doesn't.
What sort of patterns they want to express
in this design language.
And hopefully hear back from people about
how it fits with their design ethos in their brain.
Looking forward to that.
RETO MEIER: And that's a really important thing
as well, like one of the big key things about doing a Developer
Preview like this is that we want to hear from you guys
as to what works, what doesn't work, what you love,
start to see some of that stuff.
So tell us.
Let's see, from the front.
AUDIENCE: First off, I want to thank all of you
seriously for your work on the platform
and on developer relations.
You make my life a lot better.
So, thanks.
[APPLAUSE]
So my question.
I've noticed a lot of differing perspectives
from different developers.
And some developers who just throw up their hands
and say, I'm confused about when it's
appropriate to use an activity with one
fragment or an activity with a bunch of fragments,
like a dozen or an activity with two different fragments
or maybe, is it ever appropriate these days
to use an activity with no fragments?
And I know that's nuanced, but I'd really
appreciate if we could talk through it a little bit.
DIANNE HACKBORN: I'll start.
One of the basic things is that you're
going to have at least one activity.
And you'll probably have multiple activities.
So you should think of activities
as being the entry points into your application.
Android doesn't have like one main entry point.
It has more than one.
And so activities are the top things,
that if someone is going to go into your application,
that's how they get into it.
And then once you're inside the activity, the right way
to do things is, from my perspective,
now, Adam add to this, but from my perspective,
as far as the system management, that's really
up the application.
Now, the application has the freedom to say,
if it makes sense now to have multiple fragments,
to have one fragment, to have no fragments, however
it wants organize it, there's not concrete rules on that.
ADAM POWELL: So I would say that one of the rules
to follow with that is,
[LAUGHTER]
DIANNE HACKBORN: Nonconcrete.
ADAM POWELL: Not a concrete rule.
Rule of thumb, maybe, is just kind of look
to the name of the API.
It's a fragment, it's a piece.
It is a piece of an activity if you're
finding that your activity is just
getting too big and unwieldy and too much
code to think about in one go, then
maybe it's worth breaking some of that
up into some more logical fragments.
I mean, keep in mind that both activities and fragments
fulfill the role of being a controller in sort
of your whole model view controller
setup of your application.
So as long as it makes sense to break that
down into smaller more understandable pieces, then
maybe it makes sense to break that down
into some more fragments.
DIANNE HACKBORN: I would also add,
I think a very reasonable approach
is to say, just implement everything as fragments.
So all your UI elements are fragments
and then you put those into activities
where it makes sense.
Right?
Because fragments are the more flexible way
to organize your application.
And so if you find, like, I have this UI element here and now
in the future I need it somewhere else,
it's really nice that, instead of having implemented it
as an activity, you have it there as a fragment
and it can be fairly reasonable to other parts of the UI.
ADAM POWELL: Just think of it as another unit of abstraction
that's available to you.
AUDIENCE: Thank you.
RETO MEIER: From the back.
AUDIENCE: Yes.
I would like to understand what your experience is
with your own usage of permissions in Android,
as a user of Android.
And what user research you might have
and I wanted to give you some feedback from the Wild
West of developing, which is our users may not have a Google
approved version of Android.
So anywhere in my code that I'm calling
for system resources or assistant managers of any kind,
I need to protect that.
I need to be prepared for, although I got the permission,
because they installed it, it might not be there.
And where I'm going with this is,
I like the way you've simplified, recently,
the presentation when you install.
But where can we go with dynamic permissions
because I think that helps users to understand
the context with which a permission is used.
So what can you tell me about the research that's going on
and what you use.
Do you just hold your nose and install?
I mean that seems like a normal thing to do to me.
JHILMIL JAIN: All right.
So I'll talk from a research perspective
and then Dave or somebody else will
talk from a framework perspective.
So from a research perspective I do
realize that we can do a lot more to provide transparency
with the permissions.
I know one thing is that, OK, I have accepted these permissions
to install an app.
How was this data being showed?
Shared with other third party maybe.
Or is there was one place where I
can go to sort of manage all my permissions.
So these are things that we are aware of.
And we are deeply thinking about this.
So stay tuned.
FICUS KIRKPATRICK: Yeah.
I just wanted to comment on a couple things you mentioned.
I think there was a lot to unpack in that question.
But around, I guess, having to code defensively
around incompatible versions of Android and so on.
I'd be curious if you tell me afterward
what particularly that is because we work on the Play
Store and you may have heard of it.
It runs on a lot of devices and it's just not something
that we've run into of seeing this inconsistent
availability of permissions, whether they're granted or not.
RETO MEIER: I suspect you may be referring
to some of the problems which have come out which allow users
to optionally disable some of the permissions which you may
have been granted through installation.
AUDIENCE: Yes.
Thank you.
FICUS KIRKPATRICK: I think that, thank you
for the feedback on the way we display permissions now.
I think the big insight there was
we had tied the developers idea for the permission and the user
idea for the permission together for a long time.
I think what the users care about is the data.
So I think that we're just getting started on figuring out
how people think about what data they're getting access to.
You saw some of the stuff in the keynote today about data
control is something users want.
I think you're seeing the first step.
And the research is going to, the research we've done
is going to inform where the platform goes going forward.
Gabe do you want to, do you want to talk about app ops.
GABE COHEN: Also, thank you for the feedback
on the simplification.
Actually you ask for personal anecdotes or experience.
I think I'm similar to many users in that there's
a service I want.
And there's a certain number of things
I'm willing to bear to get it.
And sometimes I just want that service and that's
kind of the end of the conversation.
And for users who may be looking for more commodity experience,
I think the difference in permissions between apps
will actually make a difference in what they choose.
We hope the new UI makes it clear
what those differences are between apps.
And then anecdotally, what I've heard from friends and family
after we did the roll out, they're like, what is this?
Is that generally they're noticing them more.
I think our goal is to give a more gestalt impression, using
iconography and things like that.
And that's having an effect.
People are like, wow, this application can do this stuff.
Actually it could always do that stuff,
you couldn't tell because it was buried
in a mess of information.
We really uplifted the signal there.
And I guess for your question about context and run time.
I think we would all agree that context
helps users make decisions.
We just haven't come up with the right way
to incorporate that into the experience yet.
But like Jhilmil said, we're still thinking about this.
I think we have a long way to go still.
ADAM POWELL: And just to your point about your experience
as a developer, I think that's a great example of the experience
that we don't want.
And users are our developers as engineers on the platform.
So I think that as we continue thinking about this problem,
we're really going to try and find
where that balance is between user's needs and developer's
needs and make sure that everybody can kind of come
to some agreements.
AUDIENCE: Thanks guys.
RETO MEIER: So another question from online.
Asks, are there any plans to improve the Android activity
life cycle stack.
In particular making it less complex for developers
to deal with.
DIANNE HACKBORN: Well, less complex.
Well since this question did not say anything
about exactly what was wrong, I'm going to make that up.
[LAUGHTER]
So one perspective on this is that Android
took a quite different approach from a traditional operating
system to what an application is,
in that normally an operating system in an application
is basically a main.
And the platform just says, OK, the user
wants to run this application main go.
And at that point, the application
is all in control of what's going on inside of it.
And the platform doesn't really have any control over it.
So when we did Android, one of the basic things
we wanted to do is, we say we don't
want to have just a main entry point.
Because we want to have a lot more interesting
interactions across applications.
And so we have this activity component model.
This activity is services, receivers,
and stuff that make up all the entry
points into the application.
So once you do that, you kind of can't
have just this main black box application that is just
this box, you make it run and it does its thing.
Because the operating system actually
needs to have a lot more interaction
with the application about, oh, it's made this activity.
But now someone wants to share.
And so now we need to make another activity.
And we have to tell the application to do that.
And the application has to always be in a state
that it can do that.
Because it can't know when this is going to happen.
So that's where a lot of that complexity comes in.
And it's really, I think, about-- it's
this change from the app developer being
in control of its box to needing to do
some coordination with the platform.
And it may be some complexity.
I think there's it's maybe more learning curve.
I really think that once you get through
that, there's a lot of advantages to us,
certainly for developing the platform,
it's given us a lot of opportunities
to do new features in the platform
with existing applications and ways we never
could have without this.
And one example in L that I love is
that we introduced this whole recents
with this document oriented recents
that applications have multiple recent entries.
And if you run the developer preview, you're going to see,
we're actually doing this to existing applications.
So if you do a share, and you go through the standard share
dialogue, when you end up in the share target,
this becomes another entry on recents.
And now you can switch back and forth
between the original application and the thing
you're sharing to.
And we can do this because we made this break
between the application being this black box
and the something that the platform coordinates with more.
So, if that's the kind of complexity
you're talking about, I think that, yes,
there is a learning curve on it.
It's a little more complex, but I think it actually gives us
a lot of benefit going forward.
DAVE BURKE: I don't know if you guys just noticed that.
I see this about every month where Dianne goes, yeah,
we designed this thing four years ago
because we knew that tomorrow we're
going to want to work this way.
So she's this always happens.
Great.
RETO MEIER: Thanks, Dianne.
From the front of the room.
AUDIENCE: So I was wondering if you guys, at any point,
consider the support, the official support,
of the Scala programming language.
I'm asking this question, especially,
I know that we also that Apple already
has Swift after four years of work.
And I think that Swift does all those things for us
as developers that we can't do in Java.
And with the Android SDK.
So my question was, have you ever thought about it,
before the release of Swift?
Have you thought about it after that?
And is there any plan?
DAVE BURKE: Well, so I like Cocoa,
but Objective-C is based on C which is 40 years old.
So I think Apple sort of had to update it a bit.
I don't know.
Scala, I don't know.
Anyone want to take that?
DIANNE HACKBORN: No.
[LAUGHTER[
Seriously, Java is the programming language
for Android, you know, I don't really
think there's a lot benefit to-- The entire framework is built
around the Java programming language.
And I don't think there's much benefit for us
to try to support another whole other different language.
AUDIENCE: What about Swift?
DIANNE HACKBORN: I'll think about it.
DAVE BURKE: It's not optional semicolons.
DIANNE HACKBORN: You have the NDK.
So if you want to throw something in there.
But the NDK, it doesn't have access to the framework.
Right?
And that's kind of the challenge is
if you want to do a different language,
if you want to have it as a first class language,
equivalent to the current framework,
you've got to have either a whole new framework
or some bindings to it, which is going
to make it a really bad experience
because it's going to be Java in this other language.
AUDIENCE: I'm in a country that always
to work with Scala because Scala is compared to the JVM, right?
So it cannot run on Android.
So there can't be ways to do that, to work with Scala,
but it's using third-parties libraries.
So you have classes that were made by people to word the Java
classes but then it becomes tricky to integrate that
cleanly with that Android Studio that the [INAUDIBLE] quickly.
So I'm not sure it's as complicated as creating
a whole new language like Apple did, but I think, I don't know,
my question was just if you guys were considering and uh--
XAVIER DUCROHET: I think from the tool perspective, probably
later this year, or early next year,
there are some changes going on inside Grata
right now that will make things easier to you
to just have a module that's originally written in Scala
and then complied down to byte code
and then we can just text that and package
that with your application.
But it's not going to help you access like the activity API
through Scala code.
Right?
It would be if you have some code that your Business Logic
or whatever that you want to write in Scala because it's
easier for you, you should be able to do that.
Because, as you said, it's compatible in just
regular byte code and then just texting it.
But that's very different from saying
you can could code Android in Java
where you have access to all the framework API.
AUDIENCE: Thank you.
RETO MEIER: Thanks From the back of the room.
AUDIENCE: Hi.
Yeah.
I was wondering some of the newer features
in Android L, for example, like the notifications on the home
screen.
How much control will the user have over that?
And I mean, I went to the What's New In Android session earlier
and they talked about how, as the app developer
I will have the option of setting privacy levels.
But let's imagine for a second, that I
don't think that a third party developer knows
what I think is appropriate for displaying on my home screen.
Will I be able to, say, turn those off entirely?
GABE COHEN: Yes.
AUDIENCE: Oh, and just my two cents,
I think the new app ops of the Play Store permissions
are kind of confusing, actually, and they kind of
obfuscate a lot of things that I don't think
should be obfuscated.
[APPLAUSE]
RETO MEIER: Thank you for that feedback and to Chet
for not explaining the notification things well enough
in the earlier session.
Front of the room.
AUDIENCE: Hey.
So Kit Kat did an exceptional job of making Android svelte,
I guess.
And with L's new focus on lush animation and 3-D rendered
shadows and everything that's beautiful,
I was wondering how like emerging market
devices and older devices will fare with it?
Yeah.
ADAM POWELL: So when some of the engineers who
are working on some of the flashier features
that you've been seeing in here first started,
this was something that we thought was really important.
We didn't want to make a move like this in KitKat,
only to just kind of toss it out as soon as we found
some new, flashy effects we wanted to implement.
So they'd actually found the absolute oldest devices
they could, sitting around in a desk
that we still had drivers for.
And they actually started on those devices
to implement these effects.
So this is the sort of thing where performance on low end
devices is something that was really
intrinsic to the initial design of the implementation.
So there's definitely a few cases, a bunch of you're
going to get the L preview and go run some of it.
You'll probably run into some cases where you say, oh, wait,
this is a little bit slower than I thought.
We know about them already.
We're working on them.
Many of them actually have already
been addressed internally as we've continued along this.
So performance is something that we think is really important.
We can't really accomplish the goal of material design
if everything is just janking across the screen
the whole time.
DAVE BURKE: Yeah.
I'd just add that we still literally
have a weekly meeting on Svelte, so kind
of monitoring the memory.
We don't want to go backward.
And then Art, the runtime is actually
more memory efficient than Dalvik.
Well we have different types of garbage collectors
but there's a moving collector that's
used when your app goes in the background.
It's slower.
So you don't want to do it in the foreground.
But it will save like hundreds of kilobytes easily.
So it's helping us too.
AUDIENCE: Thank you.
Related question.
We had a project about a Svelte folder.
What comes first, the name or the idea?
DAVE BURKE: Genuis.
The idea.
ADAM POWELL: There was that one where you just
had to come up with a project for the name though.
DAVE BURKE: Project Project.
[LAUGHTER]
RETO MEIER: From the back of the room.
AUDIENCE: I have a question about Google Play services.
We want to use services like Google Analytics, Drive, AdMob,
across all Android devices including
those without Google Play.
These services used to be individual jars.
But now are part of Google Play services.
How do you propose we use these services across all Android
devices?
[APPLAUSE]
GABE COHEN: Did you ask this question in the Google Play
Services rocks?
AUDIENCE: I didn't but someone else did.
GABE COHEN: Someone else did.
OK.
I heard the same question.
I'm afraid I don't have much to add to the answer.
So all of us here work in the compatible device ecosystem
devices with Google Play.
So our primary concern is how this platform
is expressed on those devices.
We actually don't really have any opinion
on what other organizations in Google
do with devices outside of our ecosystem.
So it's kind of a question, I think, for somebody
from the analytics and the AdMob team.
I don't think I can answer that.
Sorry.
RETO MEIER: From the front of the room.
AUDIENCE: Hi.
Ever since Cupcake, or versions before that.
I'm not that old anyway.
I've been using BroadcastReceiver
to do fun things with getting SMS messages.
But these days everyone uses Hangouts, which is awesome.
But should I just give up on trying
to have an application interact with Hangout's messages
or-- Could someone comment on what
I should do in that regard?
DIANNE HACKBORN: I think if you're
talking about what happened in KitKat with the change in how
the messaging is, so you have a preferred messaging
application?
AUDIENCE: Not so much.
More on just a sense of like the fact
that Hangout's messages don't trigger an SMS broadcast out
to other applications.
DIANNE HACKBORN: People are not using SMS.
Yeah if they're not using SMS then
the platform won't know about it and--
AUDIENCE: OK With Hangout, people,
apps can't respond to messages as they come in
through the API?
RETO MEIER: I think that's unfortunately
more of a question for someone on the Hangout team
rather than Android framework team.
So,
ADAM POWELL: From the perspective
of the framework though, this is the sort of thing
where, if an application was implementing
messaging that moves over its own protocols
over the internet, then that application
would be totally free to publish their own broadcast if they so
chose.
AUDIENCE: OK.
Thanks.
RETO MEIER: From the back of the room.
AUDIENCE: Hi.
So I wanted to ask you guys, what's the status,
and if you do, for the Wi-Fi peer to peer tools for Android?
Because as a developer that has worked with them,
I know that the technology has a great potential but right now
these tools seem very incomplete and very buggy.
So I wanted to know if there are plans to replicate or continue
developing whatever.
DAVE BURKE: Oh, Yeah they are a little bit but buggy.
I agree.
We're actually scaling that team so we've
been hiring lots of people.
Wireless in general.
Actually so like trying to really invest a lot
more in Bluetooth and Wi-Fi and cellular and Volke
and all of stuff.
So no plan to duplicate peer to peer Wi-Fi.
There's some new Wi-Fi features coming.
I mean you can see some of the standards in Wi-Fi Alliance,
like Network Neighborhood, things like that.
I'm trying to think what else we're doing in that space.
We're actually doing a lot of refactoring internally
on Wi-Fi.
So previously in releases to Supplicant,
the WPA Supplicant had a lot of the logic.
We've actually sort of taken the logic
and moved it up and rewritten the parts of the Wi-Fi state
machine and then we've introduced a new Wi-Fi
How to abstract out Wi-Fi features.
Like, for example, Devices Scan for Locations.
Today they scan all the channels now with the new Wi-Fi
How, we can selectively scan.
Anyway, the point I'm making is that we're
investing in that area and so we're trying to improve it.
AUDIENCE: OK.
RETO MEIER: Thanks, Dave.
A question here from online.
Which is the most important thing
to focus on when you're first creating an app.
Should it be the engineering or the design?
JHILMIL JAIN: You're thinking about this the wrong way.
You should really be focusing on the user.
RETO MEIER: Nice.
I see what you did there.
DAVE BURKE: User design.
JHILMIL JAIN: Sure.
RETO MEIER: Moving on.
Someone from the back of the room.
JHILMIL JAIN: I think like even for a number of products
that we talked about today, where automotive, TV,
it didn't really start just with the design or whatever.
Coding really started with really looking
at some fundamental issues that are currently the wrong,
our products are not meeting when users are concerned
and really trying to be really clever about how can we
build a product that really solves those issues for users.
AUDIENCE: Thank you so much for thinking so much about design
with the new release.
It's very exciting.
I think that I probably speak for a number of people
though when we go and talk to our design teams
about the new looks and the new ways of doing things.
They will pull out a Galaxy S4 and they'll
show us the text messaging app and they'll say,
you think Android has a consistent design language.
And yet this is my text messaging app.
We're going to design it the way we want to design it.
What steps are you taking or thinking
of taking to address the kind of crazy design ecosystem that
exists in the Android world?
[APPLAUSE]
RACHEL GARB: One step that we can take that will help this,
I think, is to do a better job with our own applications.
Following our own design guidelines.
[APPLAUSE]
That's something that we've been working on for a while.
You know we're a big company.
We've got close to 100 teams that we're
working with that are developing Android
apps all across the company.
And they're all on different release schedules.
So it's a bit of a challenge.
Plus as you can see, we're also evolving our design guidelines
too.
And that happens usually internally first
and then externally.
But one of things about that strategy of starting internally
is it means that by the time the guidelines are rolled out
you have some concrete examples to work with,
which we know is really important.
RETO MEIER: Thank you.
In the front.
AUDIENCE: First thank you all for all your hard work
building a platform that so many of us
can create a career around.
My question is as a developer, I personally experience
a lot of pain points and hear about a lot
of pain around testing, particularly unit testing
in Android.
I feel like solutions like Robilectric
feel more like a bandaid than a proper solution
for the problem.
Can you speak to maybe anything in the L preview
or just a general idea around testing, particularly unit
testing in Android.
[APPLAUSE]
XAVIER DUCROHET: So first, we do want
to help Robilectric to integrate better
with our current set of tools.
We know it's definitely a bandaid,
that it's not a perfect solution.
But like a lot of teams currently rely on it,
so we want to improve the solutions there so for people
who want to use it, they can actually use it.
For the rest, anything that doesn't run on an Android
device is going to be a bandaid.
I mean, if you have some code that's purely non-Android
and can run on the VM, then you should
be able to create a Java module and test your logic there.
For the thing that access the Android API,
you should run it on a device.
Now the problem is that it is slow to deploy
It is slow to build.
And to run the test.
On the build and deploy, on the build, at least part,
we are trying to improve the situation
to build faster with greater [INAUDIBLE].
There's some work going on in there.
That will get better some time.
The deploy part is more complicated.
And it's something that we want to tackle,
but it's like we need to work with the runtime
to be able to do that.
So it does nothing in L that would help with that.
But in your existing Android API, there is no other way.
You need to run on a device to make sure that it is actually
reliable, as far as the test results.
RETO MEIER: Thank you.
From the back of the room.
AUDIENCE: Like many apps displays,
text and images for which we employ text views, and image
views, and layouts, we were not aware of a general purpose way
to wrap text around images.
And we're not satisfied with third party libraries
that we researched at the time.
So about a year ago, we developed our own overriding
canvas.
It was complicated.
It was difficult to test.
And lately we're revisiting the code
and wishing that our app didn't have to do all this work.
Is the Android team looking at this problem?
ADAM POWELL: So the short answer is yes.
I think that it's something that we've definitely
seen as a pain point in a number of apps that
have come to us asking questions about how to do exactly
the sorts of things that you've described.
And for all the reasons that I'm sure that you've already
run into you've realized that it's
a fairly complicated problem space.
Now a lot of that just comes from the way
that text views interaction with canvas and the way
that it deals with text and fonts and so on and so forth
is complicated, to say the least.
But it's also very tightly coupled right now.
And in the future we'd really like to work on that
and see if there's anything that we can do to sort of tease
that apart into some modules that can be used a little bit
more naturally to accomplish the types of things
you're talking about.
AUDIENCE: Thanks.
RETO MEIER: One of questions online.
It's colorfully asked, so I'll try to rephrase it slightly.
Dan is wondering, do you see a possibility
of having the ability to do a full build and test environment
within the Chrome OS 400?
[APPLAUSE]
DAVE BURKE: So I don't know.
I think that means an ID within Chromo S.
FICUS KIRKPATRICK: The ethos of Chrome OS
is that the ID would be like in the cloud
somewhere, right I don't know if there's anything that
makes sense to say we've made an ID for Chrome OS
that they couldn't use from any browser.
RETO MEIER: Question to the cloud team.
We saw a little stuff from them on like IDEs for cloud apps.
I don't see building Android apps
in the cloud happening soon.
XAVIER DUCROHET: I mean, you also
have to look at deployment.
I would guess that a lot of developers
right now mostly use devices to test.
If you're bringing in the cloud, and your application is not
a small, Hello World, application
you're going to have to be download
that APK on your local device every time you build.
And if your app is 10 megs and you
don't have a crazy connection, that's
just not going to work at all.
So I don't see that happening.
The current state of web ID is just the beginning of it.
If you compare that to a really good Java ID like IntelliJ
it just doesn't compare.
So I think that test of IDs are still the way to go for now.
RETO MEIER: Thank you.
Let's see.
From the front.
AUDIENCE: Like most of the people in this room,
I'm really excited to see that there's an L preview
release this time around.
And by the fact that it's coming out as factory images only,
it's pretty clear that it's only meant
for developers and extreme enthusiasts, who
want to get a real jump on it.
Is this a pattern that we can expect
to see in the future, more preview releases?
Because I've seen a lot of complaints from more normal,
average users who are running into problems
with the early versions of each major release.
DAVE BURKE: Yeah I think it's funny
that this idea everybody claims to be their idea
and pushed for it.
So I'm going to claim was my idea and pushed for it.
But it wasn't as everyone's idea.
I think one of the observations I had was just
that the platforms, it's getting so big.
Right?
That the surface area is so large.
We do, we've got a great QA team.
And we do, we test the top 1,000 apps and all this good stuff.
Got a CTS tasks but this is the long tale of apps.
You just can't test everything.
And so what ends up happening is you would make a release
and you break something.
And it's just, I remember triaging the bugs post
JBMR2 for KitKat.
And it was just embarrassing.
It was like, you should've caught this.
It was clear to me that we had to move to this model, where
we put out the developer preview, where people can test
their apps, submit bugs, and when we fix things.
So, I think, obviously I can't make promises
but I think the reason we've done
it is a very rational reason, and entropy, increases
not decreases.
So I think we shall continue doing it most likely, possibly
not promising, but yes.
[LAUGHTER]
AUDIENCE: And to that I say, thank you so much.
Thank you.
RETO MEIER: What do you guys think?
Do you like having the preview releases?
DAVE BURKE: And the other thing I hope to see
is actually to get OEM as a jump in building devices.
Because once we make the preview available
we don't have to be so secretive.
We can share our builds.
We can share more source.
We can look at vendors and stuff.
So my hope is that when L comes out officially in the fall,
that a bunch of devices pass follow.
So we'll see how that pounds out this year.
XAVIER DUCROHET: I just to point out quickly
that there will be a [INAUDIBLE] system
images of available as well.
So if you can use that if needed.
RETO MEIER: From the back of the room.
AUDIENCE: Hi.
I really like the new Grata Build System.
It's really awesome.
You can do really awesome things with it.
But I'm not really an intelligent user nor will
I see myself being one in the future.
Is Eclipse going to become the redheaded stepchild of Android
or is there going to be support for it continuing forward?
XAVIER DUCROHET: Did you see the time, Reto?
[LAUGHTER]
RETO MEIER: Thanks everyone.
We don't even have time to open a Java form on Eclipse.
[LAUGHTER AND GROANS]
AUDIENCE: Yeah, but you don't have time
to build an Android app in IntelliJ in this time.
AUDIENCE: No, I get it.
DAVE BURKE: Think it's tricky.
An ideal world will support all IDs.
But we sort of have to pick one to double down on.
And I think we're starting to pull down on IntelliJ.
So.
Yeah.
XAVIER DUCROHET: There's actually
some work going on with Grata on Eclipse
to try to improve to the integration there.
I mean separate from Android.
Also there's some work happening in Grata
itself to improve their internal model
so that's our model can be closer
or more compatible with theirs.
And so if both of those things happen,
then you could potentially at least,
open and Android Grata base project inside Eclipse
and do at least basic job editing
with all of the dependencies working
and possibly just build out.
You wouldn't have any Android specific feature tied to Grata
but it might actually work.
But as they've said, it would be nice to support every ID,
but right now we're focusing on Studio.
AUDIENCE: Thank you for everything you do.
RETO MEIER: Thanks.
We are completely out of time.
So thank you, everyone for your great questions.
[APPLAUSE]
And thank everyone on stage for joining us and answering
everything so open.
So thank you.