[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]
TLDR; There was a Play Store manager but no one asked about what they are going to do about "bot developer support".
..So stupid questions
This is why all developers are f*cked by google
Anyone brave enough to watch with no hope for good questions and answers and give us highlights? :)
What dumb motherfucker stands in front of the android team and asks them how they are making their teams more inclusive.
So much for Pray for Play :/
Jetpack compose seems interesting