Android Fireside Chat (Android Dev Summit ’19)


[TITLE MUSIC] CHET HAASE: Welcome to
the Android Fireside Chat, something we try to do
now, what, twice a year, where everybody gets to
ask random questions and then we try to figure out
what the answer to them is. Ground rules– the
only ground rule is, if you ask a question
along the lines of “when is,” you will be disappointed
with the answer. We don’t talk about future
developments for the most part. And otherwise, anything is game. Let’s have an interesting
technical discussion. Let’s see, also,
all of this today is driven by audience questions. Sometimes at the
Fireside Chat, especially at I/O, we sort of pre-roll some
questions from social media. And we did not do that. So we are depending upon
you to ask the questions. That’s your job. And I will try to see
up in the heights. So if you don’t
know any offhand, try to think of some quick
while the panel introduces themselves. Why don’t we start with Tor. TOR NORBYE: All right,
so I’m Tor Norbye. I’m director of Android Studio. DIANNE HACKBORN: Hi,
I’m Dianne Hackborn. I manage the framework team. WALE OGUNWALE: I’m Wale. I lead the window manager team. MADY MELLOR: I’m Mady. I’m an engineer on system UI. AURASH MAHBOD: Hi, I’m Aurash. I’m on Play. STEPH CUTHBERTSON: I’m Steph. I’m the director
for the developer PM DevRel and UX team. BRIAN CARLSTROM: Hi, I’m Brian
Carlstrom from the Android engineering team. KRISH VITALDEVARA: I’m Krish. I’m on Play trust and safety. YIGIT BOYAR: I’m Yigit. I work on architecture
components. ROMAIN GUY: And I’m Romain. I work on the Toolkit team. And I would like to
point out that only Tor and Steph used their title. [LAUGHTER] We get it, you have a
higher title than we do. [LAUGHTER] CHET HAASE: Title-driven
development. So in addition– so it
turns out that Android is a really huge platform with
many, many things going on. And there’s a really good chance
that a question that you ask is going to surpass anybody
on the panel’s ability to actually answer it deeply. So we have additional
people in the audience, upfront or maybe spread
around in the audience. So we may also
include some of them. And we’ll see how this goes. So I see that– I’m going to count
now– how many people are standing at the mic? Exactly zero, but
now there’s one. Excellent, so we have
our first audience– ROMAIN GUY: Chet– CHET HAASE: –question. ROMAIN GUY: –there’s
also a mic at the top. CHET HAASE: Yeah, I see. But there’s also zero up there. [CHUCKLING] All right. AUDIENCE: So I wanted to ask not
as much a technical question, but we just had
version 10 of Android, and I know a lot of you
have been with Android for almost ever at least. So just kind of what
is sort of the biggest surprise, or the thing
that has been added, or that it’s been used
for that you didn’t expect in the beginning that you’re
most proud of or excited about? CHET HAASE: So who was here
prior to 1.0 on the panel? All right, a couple of them. You want to start with
that, surprising things. ROMAIN GUY: I mean, nothing’s
really surprising anymore because Android is
kind of everywhere. But I remember in the
early days where, you know, we’re still celebrating a few
thousand phones being sold, and people were
putting it in fridges, and washing machines, and
sending them to space. We were like, why
are you doing this? Like, I wrote some of that code. You really shouldn’t do that. [LAUGHTER] DIANNE HACKBORN: Yeah, and
seeing it in ATMs, too, was– ROMAIN GUY: Oh, God. [LAUGHTER] CHET HAASE: And how many
people have been on a flight where you try to swipe
up from the bottom to see the navigation buttons? [LAUGHTER] You can usually trick it. And then occasionally you
can even kill the tech. And then you’re like, what do I
do for the rest of the flight? ROMAIN GUY: I told you
to stop doing that. CHET HAASE: Anything
else surprising? DIANNE HACKBORN:
I’ll say– there’s a couple points I remember. There’s two specific points. Because we first
shipped the G1, and then I can’t remember the
name of the other device without a keyboard. But originally Android was
only running on our devices, and then some OEMs
started shipping it. And there was a point where
the number of other devices besides ours running Android
surpassed our own devices, which for a lot of
people on the team was kind of this really scary,
oh my gosh, what are we doing, it’s not our device
anymore, and kind of learning to accept
that we don’t have control over what we built so much. And it’s actually–
to learn to– it’s really exciting,
actually, seeing all the things these companies do, and
seeing them making bigger screens, and all this stuff. It’s just amazing. And there was another point,
seeing some other companies make Android devices without the
Google services on them, which is also something
we very much wanted Android to be able to do. But seeing that happen
is just like, oh my gosh, we made this thing,
and this is happening. And it’s like further,
oh, and we don’t have– even less control over
what’s going on there. But it’s really awesome
to see it happening. But yeah, it’s pretty amazing. CHET HAASE: Great. Let’s go upstairs. AUDIENCE: Hi. So, disclaimer, I
missed the Lint chat, so if this was answered
there, I apologize in advance. CHET HAASE: (JOKING) We could
do that presentation for you first. AUDIENCE: (JOKING) Oh,
could you, real quick? Thank you. So when we’re doing our
CI checks and everything, tests take a long time,
and Lint takes a long time. And these are not
done in parallel. From what I understand,
the root cause of this is that Lint is not using
Gradle’s Worker API. So I’m going to
avoid the “when is,” but is it possible to
make it use that, like from our own builds? And if not, is there
anything blocking that? There’s no word,
“when,” in there. TOR NORBYE: So I actually
missed that talk as well. [LAUGHTER] I’m having a flashback
to last year’s Dev Summit with questions around
Lint and CI performance. Yeah, it’s something
we should look into. In fact, when we demonstrated
the new Build Attribution UI today, I pointed
out that, hey, we’re listing tasks that
are always run. I didn’t highlight that I’ve
written one of those tasks that is always run. So it’s a bit of shame for me. I know Zab is smiling
from the front row. It’s something he
wants us to work on. So it’s something
we should get to. But obviously, as
Chet mentioned, we’re not going to
make promises today. CHET HAASE: But thank you
for the feature request. AUDIENCE: Appreciate it. CHET HAASE: Hi. Wow, looks like you have a
whole sheet full of questions. All right. AUDIENCE: Yay. I’m sorry, I will ask questions
about instrumented test. Because we have really
tried to make it reliable, and to get an environment
that will be reliable enough to do instrument test. So we tried to do a script
to kill the monitor, to restart it at each test,
to wait for it to be online, and all that kind of stuff. And we are still failing to
get a reliable environment. So do you have any advice
so we can get there? CHET HAASE: Reliable
test environment– are you talking about like– AUDIENCE: Instrumented test. CHET HAASE: –launch time
for activities– what’s that? AUDIENCE: For instrumented
test for a UI test mostly. CHET HAASE: Right. YIGIT BOYAR: I don’t know
when we have the testing talk– it’s today or tomorrow. Like, we know it is hard. It’s kind of doable. I mean, we do it too. But there is some
longer-term planning, but it’s distant future. So you kind of need to deal with
Espresso and other libraries people built on
top of it for now. So right now, it’s
really hard, but there is nothing we can provide. But you can always try to– other people just try to
minimize their reliance on instrumentation tests. I recommend that. And then you can also
try using Robolectric for some parts of it
where you’re really not trying to test the UI. But for testing the UI, you have
to run an instrumentation test. There’s no way around it. CHET HAASE: I know
Espresso has tried to deal with a lot
of these things and make things more
reliable in general. ROMAIN GUY: Yeah,
and we have a lot of instrumented tests for the
platform in the framework. And the good news is that
they’re also very flaky for us. [LAUGHTER] CHET HAASE: And was anybody
from the testing team here that wants to take that
and do anything more with it? I’m not seeing any hands. There is dedicated
testing office hours. Yeah, go ahead, go ahead. That’s great. AUDIENCE: There is a dedicated
testing officer hours at the summit, though, and
we’ll have the whole test team here as well. So you can ask them there. CHET HAASE: So seek them out. Thanks. Upstairs. AUDIENCE: Yeah, thanks. So there’s a lot of
community momentum building around Kotlin/Native
multi-platform. I’m wondering if the Jetpack
team or the, specifically, architecture components
team is exploring any support in that area. YIGIT BOYAR: We’re
watching it very closely. [LAUGHTER] No, this is like– we want to provide libraries
that people want to use. And this becomes important. This is something we are
really watching closely, but no plans right now. We are actually rewriting
paging in Kotlin. And that might actually be the
first library we ever try this. So it is important that people
wants, but we kind of need to see the demand to
provide the supply. CHET HAASE: Steph. STEPH CUTHBERTSON: Yeah. I think you might have broken
Chet’s rule, but that’s OK– about asking for futures. I do think it’s worth
mentioning that one thing that’s really cool about Kotlin/Native
is, one thing that we’re often asked about is code-sharing
across multiple platforms for back-end code
for business logic. And it’s something developers
talk to us about often– hey, I have this common set
of things that I want to do, I want to do it across– I want a common back end
that can provide functions that work across the
web, Android, iOS, lots of other clients. I think one of the things that’s
really cool about Kotlin/Native is that you would be able
to write those, and then execute them in a single way,
and then also potentially have a coherent way
of approaching it between your client
and your server. So I think it’s a
really interesting area. You know, we’re not
answering future questions. But it’s cool to hear about
it, and I think if there is– we’re very interested in
what the community thinks about it, like we always are. AUDIENCE: Thank you. CHET HAASE: Thanks. Hi. AUDIENCE: Hey. So just a quick question,
and I think last yea’s I/O, Project Nitrogen was
announced for making Android testing easy. What happened to
that, and are we going to see any
improvements in testing dynamic modules, especially
around instrumentation testing and Robolectric. CHET HAASE: (JOKING) Have we
mentioned the testing office hours? [LAUGHTER] Anyone know anything
more about Nitrogen? TOR NORBYE: I mean, I think
they’re still working on it. We don’t have studio
support ready yet. STEPH CUTHBERTSON:
Yeah, generally I think everything
Tor said is true. I think it’d be great to go
to the testing office hours. In general, I think testing
is an area we are getting asked a lot about recently. It’s definitely
something that we’d love to invest in for the long term. It’s something that
is super important. We would love to see
people testing more code. It definitely helps you to
write higher-quality code. And so obviously
feedback is great. There’s a lot of future
questions in here, Chet. CHET HAASE: Yeah. Should we repeat
the ground rules? There was only one. All right. Yes, hi. AUDIENCE: Me? CHET HAASE: Yep. AUDIENCE: Little short. Hello. So as individuals, what is your
top pet peeve, anti-pattern, or favorite paradigm that
third-party developers have adopted? [CHUCKLING] DIANNE HACKBORN: Let me think. [CHUCKLING] ROMAIN GUY: That was
many questions at once. BRIAN CARLSTROM: [INAUDIBLE] [CHUCKLING] ROMAIN GUY: Dianne,
you want to go first? CHET HAASE: We’re supposed
to be opinionated, right? DIANNE HACKBORN: I have
lots of little things. I mean, abusing
foreground service is a big one that we
kind of instigated because we cut all the
background restrictions, and stuff, and everything. But it’s becoming an
issue, and so we’re going to have to do
stuff to address that. AURASH MAHBOD: My
personal one is app size. So, you know, focusing on APK
size, I regularly, for fun, go and just tear down a bunch
of third-party apps just to see what’s in them and
what was left inside of them. It’s a very fun exercise. And sometimes you find 2-plus
megabyte, multiple testing images of, like, pigs
on carts or whatever, random stuff that
has no business being in Yelp or some other app. [LAUGHTER] I encourage you all to do that
and post those on Twitter. It’s a lot of fun. [LAUGHTER] DIANNE HACKBORN: You
know, going along with, a new one we
were just looking at is compressing your
resources table. Because some apps do that
to reduce their size. But it ends up meaning that
we have to, on the device, decompress every time we need
to access it, which is terrible. So we also need to do
something about that. CHET HAASE: All
right, and that’s it. And otherwise, all
apps are perfect. [LAUGHTER] Hi. AUDIENCE: Hi. So my question is around trust
and safety, and developer accounts, and how Play
Console postures in relation to the community. I understand that there’s this
balance between bad actors and trying to make
sure that people don’t get onto the platform,
and don’t put apps in the ecosystem that are
detrimental to the end users, and I think that’s something
that everyone here would agree is something that needs to
have good, strong institutional support for. But at the same time, people
getting their accounts banned when they
did nothing wrong is incredibly
detrimental to them, and could also mean
their company goes under. For example, our app got
pulled off of the Play Store– and I don’t care, we got
it reinstated, it’s fine– but our app got pulled
out of the Play Store for having the word Gmail in it
because we sit on top of Gmail. And the notification went
to some email address that we haven’t used in
four years or something. There was no information
on the Play Console. No one reached out to us. This is not a sustainable
way to do this. And there’s been a lot
of pain in the community. This was kind of
addressed at the keynote, and the thing was
like, yes, we’re sorry you’re going
through a hard time. But that doesn’t actually
give us any remediation. There’s nothing we
can do with that. I can’t go to my boss
and be like, yeah, Google said that they know
we’re having a hard time. So what’s the plan
for this moving forward so that developers
don’t have to worry about whether their account is going
to exist tomorrow, let alone the app, let alone building apps
that people can actually use? KRISH VITALDEVARA: Yeah. I was going to say, you took
two of my talking points. So that’s actually good. So you agree philosophically
that it’s very important for us, both as a developers
and the user ecosystem, to be able to protect our users. And I’m glad that the developer
community feels that way, and we have seen some
of that expressed on Reddit and other places. So that’s actually
good and positive. You took away the second
talking point, which was Tian, in the keynote, actually
talking about trust and safety. And I think one of the
things I want to reiterate is that 99% of the time, when
we do enforce on developers, it’s actually accurate. But at the same time, we
want to be very sensitive. Because the 1% of the time
when your app is taken down incorrectly, we are aware
it’s actually serious, and it has a potential impact
to your business, and so on. So I think from
that perspective– the gravity of what the
costs could relate to, I think we can
relate to that one. There are three
things that we are doing to be able to
minimize some of it. I don’t think any system
is going to be perfect. But we are at least
working on a few things. The first one is the
Play Developer console. And actually we’re
trying to figure out what’s the best
way to surface some of these messages
in the console, and surface them both in context
as to when the app is blocked, but also to try to be more
prescriptive about, hey, these are the reasons, or
maybe these are the things that you’ve got to do. So we’re working on it. I know we don’t talk
about the future stuff. But this feedback is
heard loud and clear, and it’s one of the things
that’s top of mind for us as well. And when we do
communicate in email, we are actually trying to be
more prescriptive as well. And I know that’s not
the perfect answer, but at any given time when
the app is caught incorrectly, there is an appeals process. We have a person on the team,
or persons on the team– real humans who actually
look at the appeals and take action if they
find out, like in your case, that the app was taken
down incorrectly. So– agree on the gravity of it,
agree on the importance of it, but also completely
acknowledge the feedback that we have to do better. CHET HAASE: I just wanted
to add– that was great– I wanted to add that, was
it this summer that we had a blog that Samir posted
on the Android Developers blog, where there was a bit
more detailed about some of the steps that we’re taking. If you haven’t seen that
yet, it’s worth reading. AUDIENCE: I think the fact
that the number of times that y’all have had to say, real
humans are looking at this, belies the impersonality of a
lot of the responses that we get. So I think just
consider that as well. So thank you for your time. KRISH VITALDEVARA: No,
I mean, the reason why the first response is always– it looks robotic, or the reason
why we enforce that, hey, there are humans actually
looking at this thing, is because for its type,
non-compliance, by definition, because we cannot be very
specific when we are taking down, let’s say, 1,000 apps for
a specific policy violation, we cannot be prescriptive or
we cannot get very specific. But when you do appeal, I
think that’s the reason why we have a human. And that’s why there
is a difference between the first and the second
communication that you see. CHET HAASE: Thanks. Upstairs. AUDIENCE: (JOKING)
Fun topic to follow. So one of the great
things about Android is how OEMs can modify
the behavior of the OS and things like that. Then, one of the
terrifying things is that they can
do that as well. So one of the things
I’ve noticed with Android is it’s going towards sort of
a more controlled model, more privacy controls and
things like that. I was just wondering if
that was also the case with working with OEMs and
having a more consistent experience across devices. CHET HAASE: I was going to
ask for a qualification of– do you have enough to
go for an answer on? OK, great. DIANNE HACKBORN: Yeah,
there’s a balance between letting the OEMs have
the flexibility that they should have to do all the cool
things they do, and also less flexibility and to
make sure that you’re shipping high-quality products
that don’t violate some of our privacy rules
or security rules, and don’t make
developers’ lives hard. We’re always kind of trying
to find a balance on that. And we are kind of
leaning more into having some more control over it. The mainline stuff is
a good example of that, where part of the reason for– certainly updating
pieces of the platform is very beneficial for
everyone, but it also is nice because it means that
those parts of the platform are shipping code that came
from us, so the OEMs aren’t modifying it. So we do see that as
something that is going to help that to some degree. But it is difficult.
Because taking away control from the OEMs
also is very difficult. They are doing lots
of valuable stuff. And so we either need
to do the same stuff, or give them ways to still
do what they want to do. STEPH CUTHBERTSON: Yeah,
I actually completely agree with Dianne. But just to start with the
problem and what you’re saying, I do think it’s a
very significant issue for developers. Because if you have to build
something, and then test it, and it behaves one way,
and then another way, and another way, and another
way, and another way, that’s just a huge tax. And so I think it’s
really crucial for us to address the problem. At the same time, Dianne’s
also totally right, one of the things that’s
coolest about Android is you have all these OEMs. There’s over– there’s like
hundreds of OEMs innovating independently. And that’s just driving
the platform forward at this incredible rate. And it’s really cool. We talk about openness
on the platform. It sounds corny,
but it’s really true that openness means you have
this amazing flow of ideas happening. But I’ll give you an
example of something that a developer
talked to me about, was did you know the color
white is implemented differently among two different OEMs? I’m not going to call
out who did this. [LAUGHTER] I don’t want to
make him feel bad. [CHUCKLING] But you know, things like
that, for a developer to have to test that,
that’s just cost for you. And so I think Dianne– obviously we’ve been talking
about this in the team, and something like Jetpack, what
Jetpack is doing with CameraX, I think, is a fantastic example. I’m really excited
that’s going to beta. Because there, with CameraX,
you have an example of something that was very problematic,
and now that team has been working
a lot with OEMs. So now you can write
against the camera in a single, unified
way, and trust that it’s going to work
consistently– so doing that at the API layer. And then Dianne is
exactly right– something like mainline, again, where
we’re working with OEMs, is a fantastic way of
creating consistency. It’s really something
that we care a lot about, and very empathetic with
the developer problem. AUDIENCE: No worries. Thank you. CHET HAASE: Thanks. Hi. AUDIENCE: Hi. My question was mainly
technical about UI. So I will start with, too
much good is sometimes bad. We’ve been dealing with
the keyboard height issue for a long time now, that
it’s been really pain for us. [LAUGHTER] Is there a way that we can get
an easy way of keyboard height? If not, because there is so
much keyboards floating around, and every OEM has, every
carrier has their own keyboards. Is there a way to at least
enforce a system default keyboard for our apps? Because our app heavily
relies on the keyboard height to allow shifting
the UI or graphics around the keyboards. CHET HAASE: Sorry, we just
smiled, not because it’s a funny issue, but because
it came up a year ago, and we thought, you
know what, someone’s going to ask about keyboards. AUDIENCE: Yeah. CHET HAASE: So– WALE OGUNWALE: It’s a
problem we agree with. And we definitely
recognize the issue, and it’s something we’re
working towards fixing. CHET HAASE: Turns out
it’s a hard problem. That’s not just like, yeah,
we’re looking into it. No no, no, it’s a hard problem– WALE OGUNWALE: It’s
a hard problem. The ecosystem has evolved. And for each of
those evolutions– intentional and unintentional– us breaking things is
not good for people that already depend on it. So we need to kind of make
pretty interesting choices to make things work
better long term. AUDIENCE: Right. But at least there can be a way
to say that my app will always use system default
keyboard no matter what. Is– maybe something like that? Or I don’t know. WALE OGUNWALE:
That’s an idea right? [LAUGHTER] With every idea, there’s
trade-offs and implications. And we could probably have a
long talk over coffee or beer about the implications
of that idea. AUDIENCE: OK, sounds good. But we are looking for it. WALE OGUNWALE: Definitely. AUDIENCE: Thank you. CHET HAASE: Thanks. Hi. AUDIENCE: Hi. So this is a Tools question. I’m a big fan of the
Intelligence Suite. I’ve been using it basically
since it first came out, like, decades ago. And I love that Android
Studio is based on this. It’s the best thing
you’ve done almost. CHET HAASE: Thanks
for your question. [LAUGHTER] AUDIENCE: Now– TOR NORBYE: So far, we agree. AUDIENCE: Yes. So the problem is that I
work in other platforms as well, especially web. And I people there
adopting editors that are lightweight,
very lightweight. They can actually run them on
various less powerful machines. And as much as I love the
Intelligence Suite, and Android Studio, and all of
those things, this is a problem that
I see, especially for new developers who have less
powerful laptops working with. And I think that it’s going
to become a bigger problem. And what do you have to say
about Android Studio becoming too heavy? TOR NORBYE: I mean,
are you thinking that laptops are going
to become less powerful, or that Studio’s going
to become more heavy? AUDIENCE: Kind of both. Like people will be using
Chromebooks and stuff like that, very lightweight
laptops, to do coding. And they work for web
development today, but it don’t work for Android. And I think that might actually
be an issue in the future. TOR NORBYE: Yeah,
I mean, Compose is kind of weblike, isn’t it? In that– [LAUGHTER] –in the sense that
it’s like, hey, just edit your source file, you
don’t need no debugger. ROMAIN GUY: What? TOR NORBYE: Right? [LAUGHTER] ROMAIN GUY: All right,
Tor is a director now. He doesn’t understand
tech anymore. [LAUGHTER] TOR NORBYE: No, so we
actually put a lot of work into making Studio smaller. That was Project Marble. And we haven’t stopped that. And simultaneously,
JetBrains seems to also be doing their own
Project-Marble-like thing. So in the latest,
2019.3, they’ve deliberately actually
worked on startup time. So they seem to really
care about this. I know that’s not exactly
what you asked for. If you’re asking for,
like, a web-based IDE, I have nothing to
announce at this time. [LAUGHTER] AUDIENCE: OK, thanks. CHET HAASE: Thanks. Hi. AUDIENCE: Before
I say my question, I would like to thank
Google for inviting me. I’m a 15-year-old
Android developer. So to get opportunities
like this is very, very– I don’t know, very rare for me. [APPLAUSE] TOR NORBYE: Welcome
to the community. AUDIENCE: And I also
like how Google’s promoting young students
and other university students to become
Android developers, because I really think it’s
a good opportunity for them. CHET HAASE: Cool. Welcome. AUDIENCE: So here’s my question. Last year at I/O– I won’t mention who, but– I was considering it, but– this was when
Viewmodel, and LiveData, and other architecture
components were under rapid development. OK, you found out. [LAUGHTER] CHET HAASE: So
what did Yigit say? AUDIENCE: Well,
basically he said that it was OK to use these
beta libraries in production. My obvious question is, is
this still true, and for newer libraries like Compose, CameraX,
and other Jetpack libraries, should we consider
using them, or are they just mere ideas that we should
consider for the future? YIGIT BOYAR: So it depends. The official answer is never use
beta libraries on production. ROMAIN GUY: But you
just said last year– YIGIT BOYAR: Yeah, but
like so the thing is, if you catch me in a bar or
talking here, I will say yes. [LAUGHTER] But the thing is that we
are tracking these numbers, and we know every library,
like thousands of apps start using it on production. And we know these numbers, how
many we are supposed to have, before we make something stable. And that’s the
confidence we have. If no one ever tries to use
these libraries before they are shipped, we will
never get the feedback. And you will go back
to the old days, like two, three years ago,
where you would always wait the 0.1 version of support
library before start using it. We don’t want to
be there anymore. We want people to be able
to use the stable version. For that, we need some people
to try the alpha beta libraries. [LAUGHTER] But so we need that help. If someone does it for
us, it’s very lovely. But if you don’t want
that– and we know many companies
don’t, and we’re also trying to accommodate for that. Like especially if
something is new, it will have a long
alpha beta period. But after something
stabilizes, we are trying to shorten the
timelines further and further so that we can get fewer
features, but quicker and more stable versions. TOR NORBYE: And
you probably want to make a distinction
between alpha and beta, and especially pre-alpha,
which I believe Compose is at this point. YIGIT BOYAR: Actually,
yeah, that’s true. Compose is pre-alpha. It’s like dev, we called it. And for AndroidX libraries,
when we call something alpha, it is not that it is unstable. It’s that API is unstable. We don’t even know
what we are doing. [LAUGHTER] So things might change a lot. But like we have seen,
there is thousands of apps shipped with Room
before it even become beta. And people used on productions. So that might be OK. When we say beta, it
means the API is stable, so you won’t need
to change your code. And when we go RC, that means
we don’t have any more bugs. We’re just waiting
for two weeks– [LAUGHTER] ROMAIN GUY: Bugs
that we know about. YIGIT BOYAR: Yeah. [LAUGHTER] Oh yeah, OK. And if nothing comes, it’s
going to become stable. If another bug comes, it’s
going to be RC2, and another two weeks. [CHUCKLING] CHET HAASE: There’s
also something new that we’re seeing with
Jetpack, which is, well, we’re shipping a static library,
you have the ability to test that in your app. You are shipping that
code with your app. If you test it
completely, you’re happy with the stability of
things, and the functionality that you get from it,
then it is your decision whether to ship with that. The API may not be stable,
but if it solves the problems that you needed to
solve, and you have not detected bugs in your
thorough testing suite that you run all
the time, then you can make the proper
decision, right? It’s a little different than
writing to something that’s alpha in the platform, and
we may change the bits out from under you between previews. ROMAIN GUY: Yeah, my first
example of what our developers actually do was, at the
[? constraint ?] [? level, ?] [? Nikolai ?] was telling me
that when he reached the first beta, it was installed
on a billion devices. So thank you for– [LAUGHTER] You’re crazy. [CHUCKLING] AUDIENCE: Thank you very much
for answering my question. And sorry, Yigit. [CHUCKLING] CHET HAASE: Thanks. Hi. AUDIENCE: Regarding the
whole layout measure system of view, like Romain
said earlier in a talk today, the view.Java is very scary. If you were to start over– ROMAIN GUY: I didn’t say
scary, I said it’s long. AUDIENCE: Long. So you have no problem
just kind of Control-Oing through the whole file? All good? OK, well, for the rest of us,
if you were to start over, what would you do
differently, if anything, about the layout
and measure system, whether conceptually
or in implementation? ROMAIN GUY: Oh boy. We are doing it
differently with Compose. Honestly, that’s not my biggest
problem with our View system or in the framework. There’s one change I would
make– and I’m sorry, Dianne. It’s the activity
extends context. [CHUCKLING] Yeah. AUDIENCE: I would
change that, too. [LAUGHTER] ROMAIN GUY: Yeah, who
would change that? OK, but all your memory
leaks all because of that. So you should all be
raising your hands. DIANNE HACKBORN:
Yeah, I always find those questions hard to
answer because I feel like, at the time it was done– if we were to do it different,
it’s a totally different world now. You know, I remember back when
we did the view hierarchy, we actually had a more
sophisticated layout system where we passed in
more constraints about, like, minimum preferred maximum size. So you could do a
lot smarter stuff. And we dropped it because it was
too expensive for the devices that at that time. So you’re always doing the
stuff under the constraints you have at the time that
drive a lot of decisions. And at that time,
we had one engineer working on it, and
very low-end devices. And so a lot of design decisions
that were driven by that. And these days, Jetpack Compose
is how we would do it now, but it’s a very
different world now. ROMAIN GUY: Yeah, and there’s
only one thing that bothers me with the measured layout system
that given in existing Toolkit is the wrap_content
and match_parents. You can be in situations
where there’s a conflict. So if the parent says that
it wants to write the content but all the children say they
want to match the parent, what do we do? And you’ve seen that happen. It does something. It’s really what you want,
but it does something. AUDIENCE: Thanks. CHET HAASE: Thanks. Hi. AUDIENCE: Hi. So first of all, thank you
for the whole modern Android development initiative. I think it’s a great idea. And I wanted to learn
a little bit more about how it’s going
to be implemented. Is it just going to
be tutorials, is it going to be something
integrated into Studio, like Lint or
suggested refactoring? Should we use
single-activity applications? Are fragments going away? Compose, animations, what? So how is that going to be
better educated, especially to new developers? ROMAIN GUY: You answered
your own question. AUDIENCE: Uh huh. CHET HAASE: I heard about
17 questions in there. Modern Android developments? ROMAIN GUY: All the above? I mean, it’s a bunch of
libraries that, you know, it’s tied to our
arch components. There’s obviously
things like Compose. We have Kotlin on the
programming language side. We’re doing more tutorials. We’re trying more
interactive tutorials. We’re doing more samples. It can’t be one thing, right? It has to be more than that. So Steph, anything I missed? STEPH CUTHBERTSON: Sure. Dave actually said
it pretty well. I think the reason
the team came up with the term,
modern Android, was we were getting asked
the question so often, what does the Android
team recommend, what does the Android team recommend? And how many people remember
Dianne’s post where she said, we don’t recommend anything? OK, yeah, it’s really cool. And after that, you all like– 87 comments, and
you were like, you need to recommend something. We went back and Dianne and I
were talking, like, maybe we should recommend something. [CHUCKLING] And over the years,
we’ve been investing in all of these different
pieces, which are, in essence, our recommendation. And what we realized was
that the community wanted us to be more explicit
and say, look, we really recommend
you use Jetpack, if you’re using a
set of APIs, this is a really great, effective,
easy, quick way to do it. And so I think– we’re not answering
futures question, so I can’t say, in the
future, in 12 months, you’ll see modern Android
will have x, y, and z. But I think what
you’re seeing today is a good indication of how
we’re thinking about it. The goal is to say, look,
Android is an open platform, and that’s super cool. There are so many new
ideas, and modern Android is going to evolve. Whatever it is
today, I’m sure it will be different in 12 months. Because someone’s going
to have a new idea, and we’re going to get together
and be like, did you see that? That was really cool. And a lot of people
are adopting it, and we should talk about that. There’s been even some
great ideas today. But I think what you’ve seen
today is a good starting point, I hope. ROMAIN GUY: So the great
thing about modern Android development is
that we won’t hear you ask, what do you recommend? Instead we will hear you
say that you disagree with what we recommend. AUDIENCE: Thanks. CHET HAASE: Thanks. Hi. AUDIENCE: Hi. So I have a question. I heard a lot of
presentations talking about how Google was going
kind of– or at least Android is recommending
Kotlin first. I got, like, 20 different
text messages right after that telling me to ask, what’s going
to happen with Java support? Are there going to
be Java 9/Java 11 syntactical expansions, and
support, and all of that. So that’s the main question
that I’ve been asked to ask you. BRIAN CARLSTROM: Well,
thank you for that. So obviously Kotlin is what
we’re recommending now, but we obviously– that’s
building on top of our Java language infrastructure. And so we continue to invest
in that particularly in the ART runtime, improving performance
for both Kotlin and Java language programs. One of the biggest
investments we’re trying to make there is part of
this Project Mainline effort, as we talked about
last year at I/O is trying to make
the runtime itself be updatable so we can continue
to bring new things forward, both to support Java language
developers and the Kotlin side. Similarly, we also invest a lot
on the C++ side, with the NDK. We recently announced we’re
now doing long-term support releases, because
we got feedback from developers that they really
like to adopt new versions. But sometimes when they
just want a bug fix, they don’t want to have
to upgrade everything to the latest version of C++. So we do continue
to invest sort of across the board in our
programming language support. AUDIENCE: Awesome. Thank you. STEPH CUTHBERTSON: Just to
add, when we adopted Kotlin, it was always super clear to
us that what we were doing was adding a language, not
shifting resources away from other ones. And I think our
biggest thing we want to be clear about
with Kotlin is, even as we lean
into it in our APIs, we are continuing to invest just
as much if not more in the Java programming language. Java was the first
language I used. It has a huge community. It’s a really wonderfully
productive language. And I think one of the
advantages of Kotlin is it’s interoperable. We expect to see Java
programming language continue to flourish, and we’re
investing in that. AUDIENCE: Thank you. CHET HAASE: Hi. AUDIENCE: Hi. Last year, I had
asked about Bazel. You made Bazel, so it’s there. But the Rules
Android are delayed, Rules Kotlin are delayed,
DA does not support it, which is like four years old. What part of the
developer tools team works on Bazel for Android? CHET HAASE: Not me. [CHUCKLING] TOR NORBYE: We
don’t work on that. So we have a team that works
for internal Blaze support, but we don’t work
on Bazel at all. AUDIENCE: Hm. What I’ve heard
was that the part of the team that works on
IntelliJ/Android Studio support joined that team, you team. TOR NORBYE: So that’s the Blaze
support, not the Bazel support. CHET HAASE: It’s
spelled differently. TOR NORBYE: So we have an– AUDIENCE: No, that’s
just a symlink. Wait, wait, wait. TOR NORBYE: Sure,
they’re similar. But the point is that
we have a team that works on supporting the
internal Google 3 build system, called Blaze. That’s slightly
different from Bazel, and so it’s not something
we ship externally. Yeah. AUDIENCE: Cool, all right. TOR NORBYE: And you
know, if you saw some of the stuff
we’ve shown today, we’re working on all these tools
related to the build system, such as the build attribution. This is all investing in Gradle. It’s really hard to support
multiple build systems. So we don’t really want to
divert our resources there. We already have lots
and lots of requests for our Gradle support. So we want to make sure that
we at least fund that properly before we start trying
to do multiple things. AUDIENCE: Interesting. Thanks. CHET HAASE: This is the awkward
part where I say, actually, we only have a minute left. So we’re going to take
one last question. I’m going to go upstairs. I’m sorry for the
people that didn’t get to ask their questions. AUDIENCE: You wouldn’t
have liked mine anyway. [CHUCKLING] AUDIENCE: Hi, you
just mentioned you were working with different OEMs
to improve the usage of cameras with the CameraX, which
is really promising. But I think– and I
really want to know if there’s something that you’re
doing related with Bluetooth. Because my team,
we are having a lot of problems with the
establish connection and something like that. CHET HAASE: I missed
part of that question. I don’t know if anybody caught
it– like the last third. AUDIENCE: Yeah,
well, I just wanted to know if you’re working on
something similar to CameraX, but with Bluetooth. BRIAN CARLSTROM: Bluetooth. AUDIENCE: Yeah. So something like BluetoothX. [CHUCKLING] CHET HAASE: That would
be a when question. AUDIENCE: I didn’t say when. [LAUGHTER] CHET HAASE: But now you did. [CHUCKLING] I think that’s not something
that we could comment on. So I’m going to end with
that very disappointing note. Thanks for coming. [TITLE MUSIC, APPLAUSE]

Add a Comment

Your email address will not be published. Required fields are marked *