Android fireside chat (Google I/O'19)

Video Statistics and Information

Video
Captions Word Cloud
Reddit Comments

TLDR; There was a Play Store manager but no one asked about what they are going to do about "bot developer support".

πŸ‘οΈŽ︎ 21 πŸ‘€οΈŽ︎ u/ramzes190 πŸ“…οΈŽ︎ May 10 2019 πŸ—«︎ replies

..So stupid questions

This is why all developers are f*cked by google

πŸ‘οΈŽ︎ 28 πŸ‘€οΈŽ︎ u/JohnDadiBo πŸ“…οΈŽ︎ May 10 2019 πŸ—«︎ replies

Anyone brave enough to watch with no hope for good questions and answers and give us highlights? :)

πŸ‘οΈŽ︎ 11 πŸ‘€οΈŽ︎ u/NLL-APPS πŸ“…οΈŽ︎ May 10 2019 πŸ—«︎ replies

What dumb motherfucker stands in front of the android team and asks them how they are making their teams more inclusive.

πŸ‘οΈŽ︎ 8 πŸ‘€οΈŽ︎ u/ToTooThenThan πŸ“…οΈŽ︎ May 10 2019 πŸ—«︎ replies

So much for Pray for Play :/

πŸ‘οΈŽ︎ 2 πŸ‘€οΈŽ︎ u/DrSheldonLCooperPhD πŸ“…οΈŽ︎ May 10 2019 πŸ—«︎ replies

Jetpack compose seems interesting

πŸ‘οΈŽ︎ 1 πŸ‘€οΈŽ︎ u/DovakhiinHackintosh πŸ“…οΈŽ︎ May 10 2019 πŸ—«︎ replies
Captions
[THEME MUSIC] CHET HAASE: So Android Fireside Chat. The first thing we should do is actually tell you who we are, so you have a little context on the kinds of things that maybe we can fake an answer to. I'm Chet Haase. I'm on the Developer Relations team. I will not be answering any questions today. DAVE BURKE: Dave Burke, Lead Android Engineering, and I was told I'm going to answer all the hard questions. CHET HAASE: True. ROMAIN GUY: I'm Romain Guy. I manage the Android Toolkit team. TOR NORBYE: I'm Tor Norbye, and work on Android Studio. YIGIT BOYAR: Yigit Boyar. I work on Android X, Architecture components, Harry Potter. AUDIENCE: [LAUGHING] AURASH MAHBOD: Aurash Mahbod. I run engineering for Play Store. PAUL BANKHEAD: Paul Bankhead, product for Play Store and Play policy. AUDIENCE: [LAUGHING] STEPHANIE CUTHBERTSON: I'm Steph. I work on our developer experience. DAN SANDLER: Dan Sandler. I work on Android system UI. DIANNE HACKBORN: Dianne Hackborn. I manage the Android framework team that does not include any Jetpack stuff. ANWAR GHULOUM: Anwar Ghuloum. I work on Android Core OS. CHET HAASE: Excellent. So that's all the people up here. We also have other people in the audience because this group of people doesn't know everything. That group of people does. So we have many experts here from the engineering team on Android. We can hopefully answer most of the topics that are going to come up. One important ground rule. We sort of have a general policy on the Android of not answering questions about the future. So if your question begins with when will or are you planning to, you're guaranteed to not get a very interesting answer. I will give you a sample. What is your favorite feature in the next release, Roma? ROMAIN GUY: Dark mode. CHET HAASE: Ugh. AUDIENCE: [LAUGHING] CHET HAASE: Why do I even? All right. So I had some content to cover first, and then we'll get into a little bit of Q&A, so let me work through some slides. All right. Let's get onto the Q&A. AUDIENCE: [LAUGHING] CHET HAASE: Here's how it's going to work. There are two mics in the stands, and there are a bunch of questions I reached out to Twitter for. And we're going to do a combination of those things. So I'm going to start with some of the questions that we got from the online community. If you have a question in your mind, please come stand by the mic, and we'll take most of the questions from the audience. And on we go with the Fireside Chat. So let me start with this one. What are Android's team's feelings on Kotlin/Native? Any plans to actively support it where it is possible or sensible? Steph? You want to-- Oh, deer in the headlights. STEPHANIE CUTHBERTSON: I was just looking at Tor to see-- I think we're very excited about Kotlin/Native. Tor and I and the team in general. It's a technology we've been exploring. We're interested in where it's going, and have been collaborating with Jet Brain's team. We'll see kind of how it evolves in the future. CHET HAASE: There we go. All right. I see a lot of people lined up at the mics-- not. OK, let me tell you how short this session is going to be if we don't get live questions. Yes. AUDIENCE: Hi. So unfortunately for the Pixel team, the top two OEM manufacturers for Android are Samsung and I think, like, LG or Huawei or something. The unfortunate thing about that is that both of these OEMs have known quirks around things like Bluetooth and camera. The unfortunate part about that, besides that being a pain for all of us here, is that these are the ambassadors for Android. These are the touch points for the Android operating system most people are familiar with. A lot of people, if you ask them what kind of phone do you have, they say, I have a Samsung. They don't say, I have an Android phone. So given that this is the touchpoint for Android, this is how most people interact with Android, not through Google specifically but through these OEMs, and given that there's all of these painpoints around camera that have been addressed now with camera X and Bluetooth and all of these hardware sensors, what's the long-term vision for ensuring that OEMs are adhering to some sort of standard around how they're integrating hardware with the operating system? And what's the plan to make sure that developers don't have to bash their heads in with things like Bluetooth in years to come? CHET HAASE: Just to be clear, we don't encourage bashing heads in as a developer community. It's not a policy. AUDIENCE: Sometimes it's necessary, though. [LAUGHING] DAVE BURKE: So, our role is to make sure that when you write an application that it runs everywhere on all devices with as much consistency as possible. Obviously the goal would be perfect consistency, and the way we ensure consistency, as you probably know, is we have these CTS tests, compatibility test suites that all device makers have to run. We also have something called VTS now, which is a set of tasks at the treble, at the hardware level, which also have to pass. And even more so, those tests have to pass with what we call a generic system image from Android on top of their implementation. And so what we've been doing is investing more and more into the infrastructure, the number of tests, how they run, test tools. And as we invest more, we start improving the consistency. And I think what you're saying, which I think is fair, is that we still got work to do to make it more consistent. And so we're definitely investing there. The other thing that's new in Q, which you may have heard about, is Android Mainline. And so now we have the ability to push select OS modules. And the way that works is it's still open source, but we work with all of our partners to upstream their changes. So we have a common mainline. And then we push these modules out in the terrain. And so in Q, for example, we have media codecs and media extractors that are standard. And they're often painpoints for media developers, app developers using media. And so that brings consistency as well as security benefits. So anyway, it's an ongoing thing that we're constantly working towards. I don't know if anyone else wants to add. CHET HAASE: Good. Thanks. Hi. AUDIENCE: Hi. As a user, I actually have a multi-voice assistant household. I have Alexa and Google Home, and I don't have a third. But I could theoretically, potentially, have one. And one of the things I love about my phone is that I can access both Google and Alexa on it. But with the changes, it seems like a lot of permissions and abilities are being restricted to the default voice assistant. And I wondered if there was any ability or ways that you could see having multiple voices assistants on your phone and being able to just invoke Alexa or Google or Bixby just by using that particular wake word on your phone. CHET HAASE: I have a question for you first. Do you find that they talk about you when you're not around? AUDIENCE: Yes. A lot. CHET HAASE: So onto your question. Assistant? DIANNE HACKBORN: Do you know what things you think are being restricted? Because I don't know that we-- AUDIENCE: Well, I do know that there's a permission bundled with default voices, the ability to access your call logs. And I'm guessing just based on that type of thing that more types of behavior like that will fall under the default voice assistant category, and thus will be unable to be accessed by the regular assistant. DIANNE HACKBORN: I don't think we just removed call log access. As far as I know, we haven't pushed any functionality to only the Assistant, or whoever the default voice interaction service is. Paul? AUDIENCE: Well, in addition to permissions, there's also the voice interaction service, which gets callbacks. And you only get that if you're the default voice assistant. DIANNE HACKBORN: Yeah, so that's been design since the beginning of that, is that you pick one assistant on your device, and there's only one. And there's a lot of reasons for that, like the always on hotword detection like is, barely works for one-- I mean, barely as far as like-- AUDIENCE: [LAUGHING] DIANNE HACKBORN: --being able to customize it and stuff. I don't mean it doesn't work. CHET HAASE: What Dianne really means-- DIANNE HACKBORN: Sorry. AUDIENCE: [LAUGHING] DIANNE HACKBORN: And there is, like, the gesture to bring up the Assistant is tied to that. And so if you have multiple ones it's not clear what should happen in that case. And there's a lot of resources associated with it, because those things need to always be running. Like part of the expectation is you're always running this, you're always listening to the microphone. And so it was a very conscious decision that you can have one assistant on your device. And we-- I mean, that hasn't changed in Q. That's been always the case. AUDIENCE: Of course. DIANNE HACKBORN: And, we don't have any plans to change that. DAVE BURKE: Let's be clear. You can have one assistant, and you can change it, for people who don't know. CHET HAASE: Yeah. All right. Thanks. Hi. AUDIENCE: I've got a question about expanded screenshots or scrolling screenshots. So recently I read about, there was a request about getting this into Android. There's several OEMs who've done, this but Google recently said that they're not going to do it? I think initially they said that they might look into it, but that ticket was changed to say it's not going to happen. Could you talk some about that? DAVE BURKE: So I don't know who said it's not going to happen. But Dan Sandler, what are you doing tomorrow? I think it's a good idea. I haven't talked to the team. I think it's a good idea. But maybe Dan's going to tell me why it's not a good idea. DAN SANDLER: No, I wouldn't dream of it. DAVE BURKE: Done. Yeah, I mean, there's no reason not to do it. It seems like a good idea. We just have to-- DAN SANDLER: We just have to prioritize it and fit it in with everything else. DAVE BURKE: Exactly. CHET HAASE: Thank you. AUDIENCE: Thanks. DAN SANDLER: Patches welcome. DAVE BURKE: Yeah. CHET HAASE: Any other feature requests? Anybody? Yes. Hi. AUDIENCE: So one thing that I'm noticing is I have a lot of friends who have iPhones. And I keep telling them, like, you should come to the Android device, and the number one thing that I keep getting as the I don't want to do it yet is because it doesn't have iMessage. And we have our messaging platforms that we've tried in the past, and historically they have not been great or they have been killed. And I want to be able to see, like, a version of iMessage that could come to Android that is either supported and continued to be built upon or is agreed upon by all the OEMs that necessarily do it. And I probably assume you're going to say the new rich text format, but I'm curious about all of that to fix that, so we can kind of say, like, no, no, we have something even better than iMessage. DAVE BURKE: Yeah, so super conscious of the iMessage situation. It depends on different regions. Like, you know, I'm from Ireland, and WhatsApp is the thing. And so it doesn't come up very often. That's what people use there. It's interesting if you look at what happened. We had text messaging, right? And then you had over the top messaging services like iMessage, WhatsApp, Signal, et cetera. And they pushed far ahead of text messaging. They didn't have restrictions, they had more multimedia, you could see when the person is typing, you get read receipts, all that kind of stuff. And so what's happened is regular SMS has got left behind. And the work that we've been doing-- and you're right, I was going to say RCS-- this is the new IMS standard. We've been working on that and working with carriers and working with device makers to basically bring SMS up to that level so that that capability is available in your phone and it becomes more standard, effectively. And so that's the approach that we've been taking. But it takes time to work through all the carrier standards and to get adoption. But we're making progress on it. AUDIENCE: But you're not going to kill it, right? We're going to keep-- [LAUGHING] DAVE BURKE: Kill-- AUDIENCE: Supporting it? DAVE BURKE: --kill which? AUDIENCE: OK. All right. Thank you. CHET HAASE: Thanks. I'm going to reach out to online again to ask Yigit. The AndroidX artifacts often seem like everything's an alpha beta RC, which is a hard sell in some companies where they demand that you use stable releases. Are there good ways to help smooth this out? YIGIT BOYAR: So I actually tried to touch this in our What is New talk. So there's two problems here. One is libraries, which already reached stable, and they go back to alpha quickly. Because while trying to stabilize the library, there's a lot of things we want to implement we cannot. So as soon as it's stable, we want to put them in. You are free to use the stable version. Another part is this, like something we announced-- WorkManager navigation-- last I/O, it took them like six to eight months to become stable. We want to shorten that time, but we also-- once we go stable, somebody is going to use it. You need to support that API forever. So we want to make sure there's a very good API. So we all try to do better on that end, and when we call something beta, that's pretty good to use in production. AUDIENCE: [LAUGHING] CHET HAASE: Beta stands for-- ROMAINE GUY: Don't be-- [INTERPOSING VOICES] CHET HAASE: --pretty good. ROMAINE GUY: There's also the fact that we have something like 70 libraries in Jetpack now. So of course, there's always one that will be in alpha or beta, which feels like a lot of libraries. So what I'm hearing is that we should do less and stop working? You're on vacation now. Right. CHET HAASE: Hi. AUDIENCE: Hi. Was there anything that you'd be willing to share about Fuchsia OS. I mean, I know there's a lot of curiosity surrounding it, and to the best of my knowledge, it hasn't really been discussed at I/O so far. DAVE BURKE: Do you have a slide that says Fuchsia Fireside Chat that you could put up there? Just joking. I mean, it's really a question for the Fuchsia team. So I don't really have much to add. There's some good collaboration happening between the teams, like this year to give you two examples, is one is we have this angle driver on Q. And the idea is that we have a module-- it's a mainline module-- and it implements OpenGL ES 2.0. We're just finishing that off, and soon 3.0. And it runs on top of Vulcan. And we actually developed that with Fuchsia because Fuchsia uses Vulcan at the base level for graphics like Android has now migrated to-- is migrating to. And so we work closely there. Also on Jetpack Compose, which is our new UI toolkit. We work very closely with the Flutter team. One of the things that we care about is having-- I care about is in particular-- is having transferable skills. Like, so if you know Flutter, the toolkit at Android should look familiar to you too, so you can move between them. And that's something we've done in collaboration. But, so our viewpoint of Fuchsia is more about the things we're doing with them, but I can't really speak to exactly their project, because I'll get it all wrong, so. AUDIENCE: OK. Thank you. DAVE BURKE: Thanks. CHET HAASE: Hi. AUDIENCE: Um-- CHET HAASE: No? AUDIENCE: Yeah, basically I just want to ask the same. CHET HAASE: OK. All right. Good. AUDIENCE: Thank you. CHET HAASE: Dave, do you want to say that again? DAVE BURKE: Yeah, I'll say it again. So-- AUDIENCE: [LAUGHING] CHET HAASE: Hi. AUDIENCE: Hi. So in past two years, we had PWA and we had AMP, and we had instant app. But I feel like they are competing each other. So I had the opportunity to do AMP and instant app at the same time. And when we released to production, the analytics got skewed because when we have instant app, the traffic's going to read out to the apps. And our sales are going to shift from the web sales to the app sales. So my question is, so when you guys release the product, what's the thinking behind it, like releasing two products that compete directly with each other. And the second question is, what do you expect from us as the implementer of your products. AURASH MAHBOD: I can take this one. So a couple of questions there. First is analytics. Obviously you know, the web analytics space is pretty complex, especially when you're doing SEO and things like that. So we've been working with a lot of early access partners to try to close those gaps because the way people think about mobile app analytics is actually quite different than the way they think about mobile web analytics. So we're continuing to improve there. You should see some continued improvements in the Pub site particularly. The other is around how you think about-- maybe I missed the third question-- but how you think about selecting between these various technologies. At the end of the day, the way we think about it is that we want developers to have the flexibility to choose the right technology for them. And for developers-- a perfect example of this is for games, where there is no real mobile web equivalent. So we want to make sure you have the flexibility to do what's right for you and for companies who are mobile first, then are really thinking about building native apps. We want to make sure that they have the same capability to bring that instant-like experience to mobile web traffic or to even the Play Store, like we talked about at the keynotes. And then if you're on the web and you want to focus on PWA or AMP, you know, there are pros and cons of all of these various approaches. So it's kind of about what's right for you as a developer. AUDIENCE: Yeah, but my concern is most of the time when we are working like Android team is working and web team is working, they might be working on a new feature, and they might be working on a new feature. It wasn't until the release we knew, like, are sales going to hinder each other? So we are in competition with each other because of the two new products released. PAUL BANKHEAD: It's a fair question. I think one of the things to think about is there's a technology choice in terms of what things you want, but there's also a distribution choice. And the different technologies lend themselves to the distribution method that your business is using. So that's why for game developers who are used to a distribution model that comes from an app store, instant games is going to be a much more natural choice from the distribution angle as well as a technology angle. If you're a legacy is, say, a shopping business and your legacy is SEO and web, then you come from a legacy of technologies where PWA AMP might be more natural for you. And if you're businesses, you know, 80% new visitors who are coming from SEO, you're probably not going to get those guys to download an app for a certain query. So I would think about it from a technology perspective and then a distribution perspective and try to make the right choice. We understand that it's difficult. And from a Google perspective, we want to give you a full suite of tools. And sometimes that means we can't give you a canonical answer that's the same for everybody, because everybody's situation is different. AUDIENCE: Thank you. CHET HAASE: Thanks. Hi. AUDIENCE: Hi. I'm quite invested in the Flutter framework. So I had two questions. The first one is, is it planned, or is it possible to have one module using Flutter so we can migrate some views in it and maybe share it with our iOS colleagues? And the second question is that I like Flutter, but is it possible to make Flutter with Kotlin? [LAUGHING] [APPLAUSE] DAVE BURKE: So I think, I didn't fully hear the first question. The first question was can you use Flutter in just part of your app, basically-- AUDIENCE: Yes. DAVE BURKE: --in a module and make it work in iOS. And then the second question is, you like Flutter but can you use it with Kotlin? Somebody said that should be called Clutter. AUDIENCE: [LAUGHING] DAVE BURKE: So let's see. So Flutter is its own thing, and I was actually really impressed with the keynote, like how many people cheered, and so it's gotten popular, which I think is great. And from my perspective on Android, it's awesome, because the more options there are for developers to write apps is really good. And where we as a team are investing in terms of toolkits is Jetpack Compose, which I mentioned earlier. And that's very much Kotlin-based, obviously, and also it's designed to allow you to use it in parts of your apps or all of your app. And so you can phase it in. And so we really thought about that sort of backward compatibility, and also being language consistent with Kotlin. But that said, as I mentioned earlier, Flutter has some really nice aspects to it. Like its Widget API is really nice, how it's done material. And so we've worked very closely. And so Jetpack Composed should look somewhat familiar to you. And so we're kind of trying to share some of the best practices and idioms in some ways. Yeah, so that's-- kind of my indirect way of answering your question. I don't know if anyone else wants to add. AUDIENCE: [LAUGHING] It's OK. Thank you. CHET HAASE: All right. DAVE BURKE: Thanks. I've been watching politicians. This is how they do it. You sort of-- CHET HAASE: Hi. AUDIENCE: Hi. So seasoned and active Android devs typically have a good idea of the road Android is heading towards and excited about all the new tools. But for new Android engineers, it can be nauseating trying to wrap their head around all the new approaches and filtering out the old methodologies. What can the team and community do to make coming into Android development easier-- examples, Kotlin first, Jetpack Compose, Navigation, [INAUDIBLE] components, Flutter which is also developed by Google, and just quickly outdated tutorials. CHET HAASE: I'm not sure what the actual question there was. AUDIENCE: What can you or the community do to help-- CHET HAASE: To simplify? STEPHANIE CUTHBERTSON: It's a great question, actually. I don't know how many of you-- there was in Android Studio AMA a month or two ago, and this question came up. I thought it was a great one. Essentially people saying, look, it's great that you're making development better. But you've made it better, and now there's all this new stuff, and I have to learn all the new stuff. And so holy cow, I got to onboard everybody to this. And so yes, we've been talking about this a lot in our team is how do we not just add documentation and samples, but holistically revamp everything we have. So let me try this out on you. Wouldn't it be cool if you could come into Android, and instead of having to go through what I sometimes call the layer cake of like API 9 and 10 and 11 and 12, by the time you have read all the documents about how it works on different versions, you kind of forgot where you started. You could say like look, I just want to manage a background task. Send me to the documentation that tells me how to do that. Look, I just want to build some UI. Just want to build navigation. And I think we're thinking a lot about how to improve all of our documentation and samples and other supporting information around that, as well as I think the work Yigit and the team have done around simplifying the libraries has just been-- I mean, I'm probably biased, but I think it's amazing. So I think we're thinking a lot about how to lower that barrier to entry so that when people are newer to Android development, it's straightforward. I would love feedback about what's working and also what we can do better. AUDIENCE: Awesome. Thank you. CHET HAASE: Thanks. Actually, I would add too, part of this stuff that Yigit and team were working on was the opinionated guide, right? And it's trying to address that. It's not just the libraries, but it's also how do you put these things together and architect or application appropriately. So hopefully we're getting better at that. I would argue that we're not done. YIGIT BOYAR: It's also like we're trying our best. It's also a little bit challenging, because like you know your use case the best. So it's very hard to give super generic advice. So we're trying to learn this over the last two, three years. I think we got better. to work with the community. Now we moved Composed to the open source, we got a lot more code reviews and help from the community. And I think if we can work together with you all engineers and people in our team, that will get a lot better over time. STEPHANIE CUTHBERTSON: Yeah, Jetpack is intended to be our opinionated answer. It's kind of the one, two-- remember Dianne wrote that really famous post that we're not opinionated, to which you all replied please be opinionated? And that's basically what Jetpack is, and we want to keep building on that so that you do have a sense of like, look, this is the way we recommend doing it. You can always drop down to the raw-- we sometimes call the laws of gravity-- to the raw framework. We always want to leave you that power. But also provide a more elegant, fast way of getting things done. CHET HAASE: All right, I'm going to dip into online questions here. I thought this one was kind of an interesting discussion point. With regards to a device like the Samsung Galaxy Fold, who starts that conversation? Is it Samsung or Google? Like hey, we'd like to build a folded device. Any chance you can support bendy phones in the OS? AUDIENCE: [LAUGHING] DAVE BURKE: Bendy phones? CHET HAASE: Bendy phones. DAVE BURKE: Bendy phones. You know, what I've noticed in the last decade, the way this goes is really it's actually the supply chain that comes up with some technology, whether it's like a fingerprint sensor or folded, bendable displays, flexible displays. And the supply chain puts it out there. And then the device makers look at it like what can we do there? And then we get involved, and we're like, oh, let's think how the software works. And so that's kind of a pretty consistent pattern of what we've seen. So we would have seen flexible displays a couple of years ago from the display manufacturers. And then a year or two later, we would see device makers trying things out. And then we would get involved. But you know, I actually am pretty excited about the foldables. I think we've been talking a lot about phones folding into tablets, and I think there's roughly form factors. But actually I think there's a lot more ideas still to come that will be quite surprising that I'm pretty excited about. And so yeah, I'm just thinking like this time next year there will be actually quite a few cool things to talk about in that space. Yeah. Anyone else want to add? CHET HAASE: And then eventually marketing people get involved, and they say, you know what, how about not bendy phones? How about foldables? Better. All right. Yes. Hi. AUDIENCE: Oh, hi. Yeah. I'm currently working on a Native calling app, and I was wondering if there's an API available to access to the voicemail system, kind of like for the visual voicemail, so that I can pull voicemail audio data? DAVE BURKE: No. So what I'm trying to remember-- AUDIENCE: Thanks a lot. DAVE BURKE: --how this works. They use IMAP. Most of the visual voicemail services use IMAP. So if you get a regular IMAP client, in theory, you can talk to them. But I'm not fully sure what the credentials are. I'm sure carriers have-- yeah. But it's an IMAP client-- AUDIENCE: So it's-- OK. So there's no telephone API for that? DAVE BURKE: No. Not that I'm aware of. Because it's also like because it's a pretty rich client, you wouldn't want to bake it into the framework because it changes a lot. And I know that different visual voicemail services have different quirks and stuff, so. AUDIENCE: OK, thank you. DAVE BURKE: Sure. Thanks. CHET HAASE: Hi. AUDIENCE: Hello. There was a distinct lack of mention about Wear OS in either keynote or anywhere in the conference. Is this a dead platform? Should we be worried? [LAUGHING AND APPLAUSE] DAVE BURKE: No, but where's the Wear team? Do we have anyone here? AUDIENCE: [LAUGHING] DAVE BURKE: Did I just make your point? I don't know. STEPHANIE CUTHBERTSON: There is a sandbox. DAVE BURKE: Oh, we have a sandbox? Yes. So, no, they're alive and kicking in a sandbox at I/O. No, it's something we're continuing to invest in. We're really excited by wearables, actually, and, what can I say? We've actually hired more people, and we're investing. AUDIENCE: Thank you. CHET HAASE: Thanks. Hi. AUDIENCE: So, hello. I've noticed that I/O an increased effort on diversity and inclusion, and many talked about it. And I want to know if there's anything you're doing just, to increase diversity inclusion in the Android platform or even just amongst your own teams. DAVE BURKE: That's a great question. So I've been spending a lot of time in the medical industry lately in hospitals, and the striking thing that I notice is that when doctors do rounds and whatnot, the striking thing I notice is how balanced and, in fact, female-heavy, just to give one angle of diversity, it is. And then I come back-- these really strong, smart doctors. And then I come back to work and it really, the diversity in the software industry is really quite skewed. And it's something we have to fix. And it's not because you live in a bubble and you can be like, well, the world needs to be more diverse or something. But this industry specifically, like, we really do need to improve it. And so we have a bunch of initiatives that we're working on. But fundamentally, we need to get more diverse people into the hiring chain so we can hire more people. One of the arguments-- we spent a lot of time in Google in trying to increase diversity both in the company and within our team. But it feels like a bit of a zero sum game. So we're going to try to do better. But then other companies are going to suffer. Like we need to work at this at a sort of an industry level. So that's just one or two of the things. I think other people on this panel should talk to this point, too, because it's so important. I know a lot of people have opinions. STEPHANIE CUTHBERTSON: I can just say briefly, one of things I was really proud of is Google was actually the first company, first tech company, to publish our numbers on diversity. And I think that was really amazing. Because then that kicked off all other companies to do the same thing. And I think having that transparency-- There's a saying, sunshine is the best disinfectant. Just looking at the numbers, I think, causes people to be aware and start to change. I think there's a lot of opportunity for change, still, but it's been really amazing to see especially on the Android team, is a lot of very strong leaders, like Dianne, many people on the team. And yet I think it's a place we can continue to invest. DAVE BURKE: The other thing I would add is, you know, it actually makes business sense. Like if you're building a product, you want a diverse set of opinions. You're going to build better products. And just so from a very fundamental level, it makes a lot of sense. You also have better teams. If you have a more diverse set of teams and different opinions, you're going have a better, healthier team. And so it's actually good for business to do this as well. But you know, like I said, I think this industry needs to work harder on it. And there's a couple of beacons which I get excited about. I went to Grace Hopper last year, and it's just amazing to see there are diverse aspects, people in this industry. But we need more. But events like that are really good to encouraging people to join. But great question. AUDIENCE: Thank you. CHET HAASE: Thanks. Speaking of Dianne, I'm going to toss one your way. Locking down inefficient Android APIs, such as background services, implicit broadcast receivers, and firewalls that reduce the amount of developer innovation. Is the Android team worried about that tradeoff? Have smartphones matured to the point that not much innovation remains? DIANNE HACKBORN: Very good question. So first of all, I understand it is really painful when we change things like this and remove some of the freedom you have to do things and put more [INAUDIBLE] things on. It's also very important, and it's actually been kind of a fundamental part of Android from the beginning. When we first did Android, we had application sandboxing from the very beginning, which was a huge change from how operating systems traditionally have worked. It greatly restricts applications. And it's very important for us so that we have this balance between freedom of developers, how open of an ecosystem we can have, and what the user experience is. And so things like application sandboxing allowed us to do things like by having restrictions in the platform, we can have a more open ecosystem instead of having something like where someone is sitting there approving every single application, like with arbitrary rules about whether it could be installed. We can have a more open store, we can have side loading of applications and that kind of stuff. And we are always having to kind of find a balance between these things. So as our ecosystem grows and changes, problems come up where we have issues, especially around user experience. So for a good example of this is background restrictions. We're finding that increasingly, battery life on the devices was getting bad because applications had total freedom to do stuff in the background. And you give them freedom to do stuff, and they're going to do it. And every app developer is thinking like, well, this is important for my application, so I should do it. And you put everything together, and things get bad for the user. So as we see these problems-- and this becomes a problem for everyone, because if users aren't happy with Android, then they're going to leave Android. They're going to not use their devices as much. So we kind of need to address this in the platform. So that's why we do these kind of things where we say, OK, we can't let applications run this freely anymore. We need to have some controls in the platform to lock that down. Ultimately, it's better for everyone. But it does cause a lot of pain. And it does cause some restrictions on what developers can do, but we try hard to still have as much freedom as we can. STEPHANIE CUTHBERTSON: We care deeply about compatibility. And I think the soul of the platform is we love developers. If you forget everything else from this I/O, just remember that. We love developers, and we really want to make it as friendly a platform as possible. Dave actually talked about compatibility in the Dev Summit keynote back in 2015. I remember that far back. It's a fundamental philosophy for us that we really want to, as much as possible, minimize change. And yes, this year there is some change. We actually had a great conversation with our developer advisory board and they said, look, you guys are so careful. If occasionally you need to make changes, just do a couple things. One, tell me about it as early as possible. Give me notice. two, tell me all the technical information upfront so I can prepare. And three, tell me why you're doing it, and be really careful. Do it as little as possible. And that's what we've tried to do. But I think the big fear I've heard from people with this I/O is a few people come up and said are you guys changing? Are you going to start breaking us all the time? And the answer is no. We have not changed. Our philosophy is the same. We are going to always seek to minimize changes as much as possible. Because we want you to be able to focus on your own business. Is that how you feel? OK. Other thoughts? CHET HAASE: Cool. Hi. AUDIENCE: Hi. I'm really excited about MotionLayout and some of the stuff that that can do, so thank you. My question's about Jetpack Compose, and how are they going to work together? Is one going to be deprecate at some point? ROMAIN GUY: So we really want ConstraintLayout in something like MotionLayout and Jetpack Compose. But the ConstraintLayout and MotionLayout team was apparently busy building ConstraintLayout and MotionLayout. So it's one of those many meetings that we decided to have after I/O to talk about it and start thinking about it seriously. But yeah, we want it to happen somehow at some point, hopefully. AUDIENCE: Thank you. CHET HAASE: Thanks. Hi. AUDIENCE: So I've noticed it seems like Google as a whole has become split brained on what they feel is right for Android development with this hard push towards Kotlin as like a godsend language as well as Flutter. And both are really hard to ignore with all the advancements that you guys are making on both sides. Kotlin with all of its functional features and things like that, while Flutter is really good with its cross platform. I was wondering if you could provide some guidance on how to decide, as a developer, which framework to go with. ROMAIN GUY: It depends. AUDIENCE: [LAUGHING] ROMAIN GUY: Yeah. It's what we said earlier, it truly depends on what you're focusing on as a developer. Like, Flutter's a fantastic cross platform solution if that's what you're looking for. If you're building a Native Android experience, we provide Kotlin, and we're building new libraries for that. We're improving our APIs. So again, it's about the choice, right? We feel like one single solution will not make all developers happy. So we have multiple solutions. AUDIENCE: So I was talking to the Flutter developers earlier at the sandbox, and it was difficult to get anything out of them as far as why not Flutter. Like, why use native over Flutter if you would have to write it twice? So is there anything that, like, you get out of writing natively that is significantly beneficial over using Flutter? ROMAIN GUY: So I mean, it's designed by-- our API is all designed by the Android team, so you're going to have all the newest features first. You can talk to all of the Android APIs directly. You don't change runtime, you don't change language. TOR NORBYE: [INAUDIBLE] ROMAIN GUY: So you have benefits there. And you get Kotlin, Tor says. AUDIENCE: Yeah. ROMAIN GUY: And you know, that's where we focus all of our efforts, so all of our teams are focused on this being what we think is the best experience on Android. But again, you know-- Flutter. If you're looking for something else that's cross platform, that's a great solution. AUDIENCE: All right. Thank you. CHET HAASE: Thanks. We've got time for one or two more. We'll go as fast we can. Hi. AUDIENCE: Hi. So what are your thoughts regarding the amount of fragmentation found across all 20,000 or so Android phones, across all markets, OEMs and stuff, and the choice the developers may find when they-- like sometimes I run into the choice where I need to choose between supporting an older API version and trying to make what I do compatible with those older versions versus just stopping and just drawing the line and supporting only the newer versions. But due to that amount of fragmentation, I only get a chunk of the users where I would get to the other choice. DAVE BURKE: Yeah, I think there's a couple of things we're doing. First of all, I would say this is a pretty unsolved problem at this scale to have an operating system that's open source and customizable running on so much different hardware and silicon. But we're doing a lot of work to improve the situation. So one is something we call Project Travel. By having a very distinct hardware abstraction layer. And so that when a device maker wants to move to a new version of Android, the new version of Android just runs on top with minimal work. And you can see some progress on that. So with the beta this year, we have-- what was the numbers? Like 23 devices, I think, including all the Pixels, that are running on the beta Q. And that's like four times more-- sorry. So that's double what it was last year, which had doubled the year before. And then on top of that, if you look at Pie, there's four times as many devices on Pie now than there was Oreo at the same time last year. And then the other interesting stat is there's 40% more devices on Pie than there where devices on O at the same time. And that's a direct example of why Travel is helping. It's much easier to do this. And so we're just putting a lot of effort into that area. And we do a lot of programs. We work with the silicon vendors, and so that we give them a standard build of Android. And so that helps reduce version fragmentation. But it's an ongoing thing. It'll keep getting better, but it takes a lot of work. I mentioned earlier about main lines for consistency so we can have more consistent modules. And then on top of that, Jetpack, if you think of that as a veneer on top, we do a lot of the work like CameraX to try to abstract you. I think that CameraX works from Lollipop forward. So we tried to abstract you from a lot of the complexity and the quirks that went across those different API versions. So we're doing multiple things, and I think, as I said probably in the first question, is it is clearly more work for us to do. But it's something we care about and are investing in. YIGIT BOYAR: This is a major focus area for us. So if you tried to use more Jetpack libraries, like all these background restrictions, WorkManager tries to hide the problems from you that so you don't need to deal with the APIs. And when you create a compatibility library, we try to implement it even in the older versions, even if we don't have the APIs So the more you could use Jetpack in your libraries, the less you will care about fragmentation. AUDIENCE: Great. Thank you. CHET HAASE: Thank you. Unfortunately, we ran out of time. I had one really quick question that I wanted to ask Aurash, and then we're going to wrap it up. When will Google Play in app update APIs be available for developers to use? AURASH MAHBOD: Now. CHET HAASE: So thanks, Twitter, and thanks to all of you. [APPLAUSE] See you next year. [THEME MUSIC]
Info
Channel: Android Developers
Views: 24,551
Rating: 4.8468471 out of 5
Keywords: type: Conference Talk (Full production);, pr_pr: Google I/O, purpose: Educate
Id: Xp4RSkHqaxc
Channel Id: undefined
Length: 40min 46sec (2446 seconds)
Published: Thu May 09 2019
Related Videos
Note
Please note that this website is currently a work in progress! Lots of interesting data and statistics to come.