Placeholder Image

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.

RETO MEIER: All right.

Subtitles and vocabulary

Click the word to look it up Click the word to find further inforamtion about it