[MUSIC PLAYING]
CHET HASSE: Hello, and welcome
to another fireside chat.
You can tell it's a
fireside chat because
of that professional video
shot in my dirty closet.
So we have a panel of
experts here on stage.
We also have more engineers
in the audience to handle,
hopefully, anything you
can throw out at us.
So let me set some ground rules.
We're looking for interesting
technical questions.
We are not looking for
questions that go something
like, when will Android,
will the platform--
anything with the word
"will," or any future thing,
you can guarantee
we're not going to give
an interesting answer to it.
We don't really
talk about futures.
But we'd like to talk
about everything else.
So let me start this out by
actually introducing the panel.
I'm Chet Hasse.
I'm from the Android
Toolkit team.
DIANNE HACKBORN:
I'm Dianne Hackborn.
I manage the Android
Framework team.
ANWAR GHULOUM:
I'm Anwar Ghuloum.
I'm responsible
for CoreOS Android.
STEPHANIE CUTHBERTSON:
I'm Steph.
I'm the Director of
Product Management
and Developer Relations
for Developer platform.
AURASH MAHBOD: I'm Aurash.
I work on Play Store.
ROMAIN GUY: I'm Romain.
I'm not sure what I do anymore.
CHET HASSE: Neither
does anybody else.
PAUL BANKHEAD:
I'm Paul Bankhead.
I'm the PM for the Play Store.
TOR NORBYE: I'm Tor
from Android Studio.
YIGIT BOYAR: I'm Yigit.
I don't have a microphone.
I work in the Toolkit team.
CHET HASSE: And so in
past fireside chats,
we've pre-rolled questions from
Twitter, from the interwebs.
And we didn't do that this year.
We thought it'd be interesting
to just take the live questions
from the crowd.
The fact that nobody is
standing up at the microphones
means this may be an
extremely short session.
I would invite any
and all questions,
with the caveat that I did
before from the audience,
please come up to the microphone
so that the Livestream-- so
that the recording can actually
catch what you're saying
and so that we can as well.
It looks like we have our first
coming up to the microphone.
So just form queues,
really, really long
and painful and tedious queues
at the microphones, and we'll
take them one by one
until we're done.
Thanks.
Yes, please?
AUDIENCE: Hi.
I have a couple questions
about some of the libraries.
I'd like to start off with the
Android job priority queue.
And so-- yes--
I'm wondering if
with all the new ways
to manage jobs in the
background if you would still
suggest using that
particular library,
or would you suggest
something else?
YIGIT BOYAR: For
people who don't know,
this is like a job
schedule library.
Before that was a
job scheduler that I
wrote in my previous
job, I thought
I'm just lazy to deprecate it.
I worked closely with
the Work Manager team.
I think that's
definitely the way to go.
Hopefully, I will have some
time to deprecate the library.
You should have used it more.
AUDIENCE: What would
you suggest using
if you want a job to be
done in the background,
but relatively quickly?
Not like in the
middle of the night,
but within a few minutes, an
hour, something like that.
YIGIT BOYAR: So Work
Manager actually
does try to run it faster,
compared to Job Scheduler.
It doesn't delegate to the
Job Scheduler immediately.
It also tries to run it itself.
So Work Manager will work
most of the use cases.
When we were designing
Work Manager, we looked at,
should we create
something that both
can run different jobs
and the instant jobs?
The problem is you cannot really
define a good API that works
for both of them.
And if you're trying to run
them in memory instantly,
there's much better APIs
with callbacks and stuff.
So we decided to
keep them separate.
AUDIENCE: OK.
One last question.
If anyone knows
anything about Glide--
on Glide 4, we've got
Glide and Glide app.
And I'm just curious, if I could
maybe have someone from Glide
maybe explain some of
the differences with it?
CHET HASSE: I don't think we
have people from the Glide
library here.
But has anybody on the
panel used Glide before,
or have opinions, besides we do
recommend that people use that
and not write your own bitmap
caching library, because why?
AUDIENCE: Yes.
CHET HASSE: There are
other ones as well.
Picasso is a
reasonable approach.
But I'm not sure what
your question was.
It's not answered by
that vague assumption.
AUDIENCE: That's fine.
If there's no one around
then I'll ask later.
Thanks.
CHET HASSE: Yup.
Also, there are two mics, too,
if one line gets really long.
Be sure to seek
out the other one.
Hi.
AUDIENCE: Hi.
Since I cannot ask questions,
I'm going to just make
a comment.
So I noticed that
you're not opinionated,
and that's excellent.
You have limited your opinion.
So for example, it's still there
is no dependency injection.
There are suggestions,
maybe use dagger, too.
There are suggestions about
using Rx Java at certain times.
Sometimes there are conflicts
between the suggestions.
I'm not going to ask
when you're going
to have those incorporated
into what you're doing today.
I'm just suggesting
that maybe you
should consider
that have those also
so that we don't
have to make choices.
CHET HASSE: So if I could
rephrase that, I'd just say,
would you consider?
And then I'll put a
question mark at the end,
and then it would be about--
AUDIENCE: Not really.
I was going to ask when
you are going to do that.
[LAUGHS]
CHET HASSE: OK.
I doubt we're going to
answer to that question.
Was there anyone that wanted to
address the underlying thing?
YIGIT BOYAR:
Dependency injections
is one of the areas we
are looking at expanding,
but we want to be
careful and slow.
So we want to make sure the
things we have already shipped
are iterated very well.
And as we get more head
count, I don't know,
we'll be able to run it.
CHET HASSE: Subtle.
Very subtle.
YIGIT BOYAR: We'll
challenge more problems.
CHET HASSE: I should
point out, too.
This came up in
conversations yesterday
that we were having
with some developers.
We have opinions now, but
those opinions, we hope,
don't approach the area of
arrogance, where we say,
this is absolutely the way
you should do it always.
It's more that we are providing
opinions on reasonable ways
to write applications.
If you have other opinions,
if you have existing
architectures, or ways that
you need to do it instead,
we absolutely think that you
should use those approaches.
And this includes the
use of other libraries
and other approaches out there.
We don't want to take
the place of things
that are there that are working
reasonably well for people
already.
Why would we bother doing that?
So yes, we do have opinions,
but one of those opinions
is use what is right for
you and your application.
DIANNE HACKBORN: I still
don't have opinions.
[LAUGHS]
DIANNE HACKBORN: So
the underlying platform
is still neutral,
and what we're doing
is building, on top of it,
some opinions that make
it easier for people to use.
ROMAIN GUY: I'm pretty
sure you have opinions,
you just don't want to say them.
CHET HASSE: Yes?
AUDIENCE: Hey.
My name's Shane.
I'm with Jaguar Land Rover.
So ever since I first heard
about Kotlin last year,
it sounds like something
really interesting.
I've practiced it a
little bit on my own.
But the reality is
I'm not going to be
able to start getting
deeper into it
until I can get organizational
buy-in to switch
from Java to Kotlin at a
company like mine, which
is a big automotive company.
It's not a software company.
Getting that sort of
buy-in is really difficult.
So do you guys have any
strategies or tips to sell that
up to management, and slash,
are there any resources that you
guys have that we can
use to kind of help
present a technical and
business case to use
Kotlin more at work?
ROMAIN GUY: So first of all,
[? Kristin ?] [? Ali ?] had
a couple talks last year, I
think, on this exact topic,
how to convince your
organization to adopt Kotlin.
So you should check those out.
ANWAR GHULOUM: Maybe
we have some data
on developer productivity.
Developer productivity
data might help.
TOR NORBYE: We do know that
people who are using it
are very, very happy.
[LAUGHS]
TOR NORBYE: And also, it
could be an easier way
to attract talent, if
that's difficult for you
to find really good
Android developers.
It seems that a lot
of pro developers
really prefer to use Kotlin.
So they might be more
excited to come work for you
if you can offer them Kotlin.
ROMAIN GUY: It's
actually pretty cool
to see that in LinkedIn
emails from recruiters,
where they say, and we use
Kotlin and it's a perk.
That's weird to have
a language as a perk.
STEPHANIE CUTHBERTSON:
So just some more data.
Our surveys, which have
an end of like 17,000,
the delta between Kotlin
and any other language,
it's about 20 to 25
points higher, absolute,
in terms of satisfaction.
And what's interesting is the
more developers use Kotlin--
we measure that--
the higher that
satisfaction gets,
which the first time I saw that,
I was like, is that an error?
ROMAIN GUY: Yeah.
Engineers never gets
happier over time.
STEPHANIE CUTHBERTSON: Yeah, so
that was very interesting data.
The other thing that
we're finding is,
generally, the companies
that are using Kotlin
are finding they have whole
classes of errors that go away.
So the quality of the code
is significantly higher.
And also, their
productivity is higher.
One of the things that
is useful is you end up
writing a lot less code,
and code you don't write
doesn't have bugs in it.
If I was going to phrase
the question back to you,
if we produced a series
of concrete case studies
that documented that, would
that be useful to you?
AUDIENCE: Yeah.
That's exactly what
I'm getting at.
STEPHANIE CUTHBERTSON: OK.
Mr. Katsaros is right
in front of you.
I think we should
probably do some of those.
We did one, he says.
OK.
What's that?
Oh, he says, did you
watch the keynote?
It was in it.
AUDIENCE: Well, sure.
But it's not readily available
for me to share the keynote,
right?
So yeah, anything.
And I've talked to several
other developers here
who work for maybe
financial institutions,
or other kind of non-software
companies that don't get it.
So any case studies
or any statistics
that you guys can put up,
like in a one-stop shop
that could be sent to a manager,
that would be really useful.
STEPHANIE CUTHBERTSON: How many
other people in the audience,
if we produced a
series of case studies,
like valid case
studies on Kotlin,
that would be useful to you?
Raise your hand.
Wow.
OK, let's do it.
Thank you very much for this.
AUDIENCE: Thank you.
CHET HASSE: You have
alerted the right people.
Also, as a general
rule, if you're
trying to convince
business executives,
I find that charts
and graphs help.
[LAUGHS]
CHET HASSE: Thanks.
Yes?
ROMAIN GUY: And if you
could ask questions
that don't lead to more work
for us, that would be great.
[LAUGHS]
AUDIENCE: Hey, guys.
A bunch of tooling questions.
I'll start with the easy one.
Can we make Lint incremental?
In our projects, for context, it
takes about an hour on 32 cores
118 28 gigs of RAM machines.
And we shard it now.
CHET HASSE: Tor, you
wrote too much LintCode.
TOR NORBYE: Yeah.
It's a very difficult
problem, and I
had this conversation with a
couple of people yesterday.
And unfortunately for them,
what they're doing right now
is they want to have every CL
they upload actually also run
through all the Lint
to make sure that you
don't accidentally regress.
AUDIENCE: Exactly, yeah.
TOR NORBYE: My plan is to
make Lint five to 10 times
slower over the next year.
AUDIENCE: Oh, thanks.
TOR NORBYE: Right.
And I'm doing that because
I want to add more checks.
I want to look for
things more deeply,
add more whole program analysis.
And I think, for most people,
it's more important for Lint
to find more bugs than
for it to run quickly.
And so I would
recommend, instead,
running Lint as a
post-submit thing,
so that it runs,
maybe, every night.
And then you find
out afterwards, hey,
this CL broke something.
I understand that it would
be nicer if it was fast,
but I'm saying that the
primary goal of Lint
is to be really
comprehensive and for us
to keep adding more checks.
And that is the opposite of
trying to make it run faster.
If there was some low-hanging
fruit of making it faster,
I would love to do it--
AUDIENCE: No, there is.
TOR NORBYE: Go ahead.
AUDIENCE: Well, I mean,
you can mark all the inputs
as inputs cachable.
TOR NORBYE: I think we
just did that in 3.4.
But there's a lot more work
to make it run in parallel.
AUDIENCE: Yeah, yeah.
All right.
But that will be like eventual
integration if we run it post?
TOR NORBYE: Yeah.
I know that there are
people in the Gradle team
who actually are looking
into making Lint run faster.
It's just that we don't see
a lot of low hanging fruit.
And again, it's, at least,
not my top priority.
AUDIENCE: All right.
So the second one from it,
so there is Bazel, right?
Let me start that way.
There was Bazel [INAUDIBLE]--
Bazel is open source.
So it's not something
that is in future.
Bazel is here, but what
Android teams think about it?
TOR NORBYE: Every time
we another language
or build system or IDE,
it's a lot more work, right?
So when we started
working on Android Studio,
we stopped working on Eclipse,
because trying to maintain, oh,
you want Eclipse?
We'll have this plugin for you.
Oh, you want IntelliJ?
Here's this other plugin.
There's a lot to be gained when
you focus on making one thing
work really well.
And so right now, we are
focusing on making Gradle work
as well as we can make it.
AUDIENCE: Fair enough.
CHET HASSE: Thanks.
Yes?
AUDIENCE: Hi.
So back in the
day, back in 2011,
we had Android App Inventor.
Actually, I used to
use it to teach it
to kids in the summer games,
and it was a good, noble tool.
But then it got deprecated.
I was just curious, do you
guys have any like this?
Any local framework which
we can use right now?
TOR NORBYE: I think
that what happened
was that it's been taken
over by, I want to say MIT.
I'm not sure exactly
which university.
CHET HASSE: It get absorbed
in some of the project, yeah.
TOR NORBYE: Yeah, I think
they're still developing it.
One of my daughters is
using it in college.
AUDIENCE: Oh, OK.
But there were not a lot of
updates coming in, so yeah.
TOR NORBYE: We're
not working on it.
AUDIENCE: OK.
TOR NORBYE: I think that it
was originally maybe developed
together, you know,
academia and Google.
We're not working
off that right now.
STEPHANIE CUTHBERTSON: Would
you like us to work on it?
AUDIENCE: Yeah.
I mean, something.
TOR NORBYE: What, in particular,
is that you like about it?
Is it the no source file, just
the actual visual programming?
Or is it the
component-based development
of taking readymade, not
just widgets, but things
like accelerometers
and hooking those up?
What specifically
is it that you want?
AUDIENCE: When I was
using it for teaching it
to kids in the third
or the fourth grade,
it's really exciting for
them to just develop an app.
And at that time, it was
intuitive for me as well.
So I was just thinking,
if something is there,
since we're already
working on so many tools,
if there was just one more
local tool, it will help us out.
And the kids can
start developing apps.
TOR NORBYE: All right, well,
thank you for the request.
We'll add it to our to do list.
It's pretty long at this point.
AUDIENCE: And just
one more question.
So any recommended tool
for using CI/CD in Android?
There is no means.
We can use Jenkins,
and that's fine,
but do you guys recommend any
tool to be used for CI/CD?
TOR NORBYE: Any of
the experts want
to say anything about this?
I don't think we picked
one that we recommend.
Oh, Stephan.
STEPHAN SOMOGYI: So we
have a talk later today
on Project Nitrogen, which is
a pretty interesting project,
where we want to
give you something
that you can scale your testing.
And so you might want to
check that session out.
AUDIENCE: OK, OK.
OK.
Thanks.
CHET HASSE: Thanks.
Yes?
AUDIENCE: All right.
Does the Android team view
Flutter as a growing core
that developers in this room
should focus on learning,
or should we expend
those learning resources
on deeper Android SDK knowledge?
ROMAIN GUY: So we do a
lot of things at Google.
Flutter is one of them.
AUDIENCE: Sure.
ROMAIN GUY: And Android, as
always, is all about choice.
I personally really
like Flutter.
There's a lot of
interesting things.
But we just made Kotlin an
offshore language on Android.
We're not going to make Dart an
offshore language on Android.
And it photographs
qualities that
are very interesting to
some types of applications
out there.
If you are already
cross-platform,
you should definitely
look into it.
It's worth a look,
but it's not something
we are adopting,
ourselves, on the Android.
AUDIENCE: All right.
Thank you.
CHET HASSE: Yes?
Yes?
AUDIENCE: Hello.
My name is Bombi from Brazil.
Thanks for any
work that you have
done for Android community.
I think everyone
is grateful here.
I have two questions.
One is regarding Instant Run.
I was talking to some friends a
few weeks ago, and all of them
disable Instant Run to
work on a daily basis.
And if you look for
Instant Run on Google,
every time there's three
or four suggestions,
it's like, how can I disable
Instant Run to program?
What's the current
scenario of Instant Run?
Are you guys putting some
effort to [INAUDIBLE]
some [INAUDIBLE]?
It's kind of not
working as could be?
How is the current scenario?
TOR NORBYE: Yeah, so we
described in the keynote
yesterday, I think,
that we're working
on Project Marble, which is
really about reworking things
that are kind of broken
and focusing on product
excellence-- fixing
bugs, UI freezes,
leaks, those kinds of things.
And Instant Run is one
of those things where
we're working pretty deeply on.
Did we talk about the EA?
Yes, we did.
So we're already working
with a few early access users
to test our new
implementation, which
is quite different
from the old one,
and we are pretty
optimistic about it.
But we want to make sure
that we really test it well
before we say, hey, try it now.
AUDIENCE: OK.
TOR NORBYE: It's
going to be great.
AUDIENCE: We are actively
recruiting for an EAP right
now for what we're
doing with Instant Run,
so if you are
interested, you can
look for me or John [INAUDIBLE]
out in the Android studio
booth.
AUDIENCE: Awesome.
Thank you.
And second question,
just quickly.
How do you folks think
about remote development?
For example, if you don't
have this kind of huge machine
with 16 gigabytes of RAM,
how it's possible for me
to have this kind of fast
deployment on Android?
I saw some libraries, like
[? Ming ?] Framer, that
can also deploy an
application, come back.
If you have good
connection, it doesn't
matter the hardware you have.
What do you guys think about
this kind of remote deployment
and testing with remote ADB?
There's a lot of stuff going
on about this on community.
What do you guys think about it?
As Google is this
kind of cloud-first,
data-first company, it's
good to have something--
TOR NORBYE: Are you
talking about running tests
in the cloud, or are you talking
about actually live debugging?
AUDIENCE: Yeah, I run an app.
It reads on a very powerful
machine on the cloud
and come back with [INAUDIBLE]
that I run on my phone.
TOR NORBYE: But I mean machine.
Are you talking
about the device?
AUDIENCE: Yeah, your computer.
TOR NORBYE: OK, so
you want Studio?
AUDIENCE: Yeah, remote.
TOR NORBYE: So
you want like an X
terminal that's talking to it?
AUDIENCE: Yeah, yeah.
Maybe you can code
on your machine,
and then, if you need
to, a fast deployment.
You can have heat on
the cloud or deployment.
TOR NORBYE: Basically, X hosting
should already work, right?
If you have Linux, this should
be possible to you already.
But building this in
general is a little harder.
STEPHANIE CUTHBERTSON:
Yeah, it's a great question.
It's one we talk about.
We've talked about it every
year for the last three years.
I think one of the
advantages is it would really
help when you don't have
a really beefy machine.
AUDIENCE: Yeah, yeah.
STEPHANIE CUTHBERTSON: And
that is a lot of users.
For those of you
who opt in, we do
watch the stats of how
much RAM people have
and how much disk size.
And as you can expect,
it varies a lot by geo.
Only if people have opted in
do we look at those stats.
So we worry a lot about places
where people don't, on average,
have larger machines.
It's a great question.
The challenge is the cost of
doing that and doing that well
is exceptionally high.
And probably a lot of
you in the audience
are familiar with many
different efforts.
So it's a long-running
debate we have.
Should we do this?
Because doing that
would postpone
a lot of other efforts.
So we're still
having that debate,
and that would be great
to have you weigh in.
It's just really a
trade-off decision.
AUDIENCE: Yeah, I was thinking
because most of the people
that I talk about, why they
don't code for Android,
it's just because they don't
have a proper powerful machine.
So for example, if you have
just kind of remote deployment
that you can run
the application,
it would be good for, for
example, Google for Education
would have a lot of
Chromebooks that would
have this local Android Studio.
It's a very short
hardware machine,
but with powerful
cloud machine that
can build tablets, or something.
CHET HASSE: OK,
thank you so much.
AUDIENCE: Thanks.
CHET HASSE: Hi.
AUDIENCE: Hi.
A quick question
about after you pur--
not repurchase-- you
got acquired Crashlytics
into Firebase, some
functionalities
are in the Firebase side
is trying to catch up
on the Crashlytics side.
And they're trying to
bring themselves up
to a feature parity.
But I can no longer
search the crashes
on Crashlytics or Firebase.
Is that deliberate?
CHET HASSE: Is there anybody
from Firebase or Crashlytics
around?
AUDIENCE: Or is that not part
of the tools offering anymore?
CHET HASSE: Let me point out
that Google's a big company.
We're not representative
of all the stuff
that we're working on right now.
I know some of the
people on the team
and I also know that
they're not in the room.
So I don't think we can actually
answer that question right now.
If you follow up afterwards,
we can get back to you
with an answer.
AUDIENCE: Cool.
CHET HASSE: Thanks.
Hi.
AUDIENCE: Hi, I'm Jason.
I work at Hinge and
we've been 100% Kotlin
for about two years now and
it's been dope and amazing.
CHET HASSE: How did you convince
your executive management
to do that?
[LAUGHS]
AUDIENCE: Actually,
Christina Lee and Ty Smith,
their talks from Droidcon
2 and 1/2 years ago
were the convincing factors.
So that was great and
wonderful and amazing.
I have been working
really, really
hard at making the app
as good as I can, with
respect to CI and test
coverage and unit tests.
And something that's
been plaguing me
for a very long time
is having code coverage
and getting the reporters
to work correctly,
with respect to Kotlin and
the 40 Gradle modules that I
have to maintain.
When I run code coverage
in Android Studio,
by the default, Android
Studio Code coverage tool,
it works great and amazing.
And then when I
switch it to JaCoCo,
it says there's
no coverage found.
And essentially, I have this
very strange copy pasted from
Stack Overflow scripts for
JaCoCo version 07927 blah that
happens to work and does
happen to do correct reporting.
But I feel like it's
not documented anywhere.
And essentially, I'm
not sure where to go,
or if I upgrade to JaCoCo
or Kotlin, at some point,
I'm going to break this.
And I do love Kotlin and
I do love Android Studio,
in general.
I just want to make this better.
TOR NORBYE: Well, it
sounds like we just
need to fix the JaCoCo
integration with our Kotlin
Gradle plugin.
CHET HASSE: Or integrate
that Stack Overflow
post into the IDE.
AUDIENCE: Yeah.
[LAUGHS]
TOR NORBYE: I'll make sure
to talk to the Gradle team
and see what we can do.
AUDIENCE: Thank you.
AUDIENCE: Can we
follow up afterwards
to get the bug report from you?
I'm aware that early on,
there was some code coverage
issues with Kotlin.
But we fixed a bunch of those
recently, but apparently,
not all of them.
AUDIENCE: Yeah.
Some of them we
definitely did fix.
There was one really
weird bug where
I could only run unit tests
on a single file at the time.
I couldn't run it
on an entire module.
CHET HASSE: If we could
follow up with you afterwards,
then we can get the details.
Thanks.
Hi.
AUDIENCE: Hi.
What is the reason behind
the JVM-based instrumentation
tests in Roboelectric 4.0?
AUDIENCE: JVM
instrumentation tests.
AUDIENCE: Yeah.
So now, you can
run Android tests.
Instead of on device,
you can write it on JVM
instead with the
Roboelectric 4.0.
AUDIENCE: Yeah, that's right.
So in Android, there's
two kinds of tests.
There's local JVM
tests, and they're
in your Test folder, and
then instrumentation test,
which are in your
Android Test folder.
You can use [INAUDIBLE] or
you can use Roboelectric
in those local tests.
What we're doing
with Android X test
is bringing a unified testing
API into Android X test,
because each mode of testing
has different APIs and styles.
It's very confusing
for developers.
So in terms of
Roboelectric, it just
basically implements
the same APIs
that instrumentation implements.
So you can write the same
tests in both local unit
tests and instrumentation.
AUDIENCE: So are you
merging the Android test
folder and the normal unit
test folder in Android Studio?
AUDIENCE: Well, I don't
think there's actually
been any decision yet on that.
But in terms of right now, you
can use the same APIs in both.
We've got another talk
today on Project Nitrogen,
so if you think about the
tests or what you run,
Project Nitrogen sort of
is the how and the where.
So I'd encourage you to
check that talk out today.
It's at 4:45, I believe.
AUDIENCE: OK And will
you provide code coverage
for both unit tests
and functional tests?
AUDIENCE: We would
hope so, yeah.
AUDIENCE: OK.
Thank you.
CHET HASSE: Thanks.
Hi.
AUDIENCE: Hi.
I'm Colin William from
Minneapolis, Mozilla.
I have a question.
Over the past eight years
or so of writing apps,
the one API that's been the
most bizarre hacks for something
that's really basic is
working with a soft keyboard.
And things like just
opening the keyboard,
listening to the
state, saying you
want to focus particular
element reliably,
and shifting the
window on View so
that it focuses the elements
you want to write into or alter.
All those things, they
break up certain layouts.
Are we considering a rewrite
of how keyboards functions?
AUDIENCE: Yeah.
Yes we are.
DIANNE HACKBORN: Do
you want to answer it?
CHET HASSE: Many people want
to answer this question.
AUDIENCE: Dianne,
you want to go first?
DIANNE HACKBORN: I'll let others
go, if you have something.
CHET HASSE: Many people don't
want to answer this question.
AUDIENCE: It's
something we're looking
into in official release.
AUDIENCE: Yeah, exactly.
So I mean, we're well
aware of the shortcomings
that we've got there.
We definitely want to enable
some richer integration
with letting apps feel like the
keyboard is a part of your app
experience, more so
than the bolt-on.
So we're actively looking at it.
CHET HASSE: It's pretty
constant feedback
over the last few years.
ROMAIN GUY: Everybody's being
very polite about these APIs.
AUDIENCE: Thank you.
CHET HASSE: All right, thanks.
Hi.
AUDIENCE: Hi.
I'm Mike.
So I love Android Studio
and I love IntelliJ.
I was lucky enough
to actually start
working on IntelliJ
as my first IT,
rather than having
to use Eclipse.
But unfortunately, sometimes
it's a little too heavy.
If we have emulators
up, we have Studio,
we have the browser for
doing something like Stetho.
16 gigs is now
something that is not
even optimal to do
Android development with.
And my manager
looks at me like I'm
crazy when I tell him
that a 16-gig laptop that
is, basically, top of
the line isn't something
that I want to be coding
on on a daily basis.
So I know we can use Vim.
I can't use Vim.
Maybe other people can use Vim.
We have Sublime.
Sublime, also,
doesn't really have
some of the nice
autocomplete, or doesn't
have some of the code
navigation that I really
got used to using
IntelliJ all these years.
So I kind of want to
ask, has there ever
been something like an
Android Studio Light,
or some kind of plugins that
anyone has thought about doing?
Because I used to use Visual
Studio for everything.
And then VS Code came
out and you can now
do a lot of that same
development, just
on smaller machines.
And I would love to just bring
my Pixelbook here and still
be able to do
development for work
and be able to do
it in not in Studio.
I kind of want to throw
it out, has there ever
been any thought
about doing tooling
that would work on
things other than just
the IntelliJ platform?
TOR NORBYE: Um.
[LAUGHS]
AUDIENCE: Does that help?
TOR NORBYE: I mean,
we're not starting there.
It's very tempting to
start with an editor
and try to build
it up, but there's
so much magic in IntelliJ that
they're very hard to replicate.
What we're doing with
Project Marble is
to try to look at optimizing a
lot of inefficiencies, right?
A lot of people tell me that
they have a 16-gig machine
and Studio runs slowly on
it, but they weren't aware--
and this is not their
fault, by the way--
but they weren't aware that
Studio is capped to use,
at most, 1.2 gigs
out of those 16 gigs,
because there's a hard setting
of max heat that Studio gets.
And the only way to
make it use more of that
is to actually go and
edit the VM config file.
AUDIENCE: I think if we
don't-- sorry to interrupt--
but I think if we don't edit
it, we're unable to use Android
Studio.
At least that's
my issue with it.
I don't want to edit it
and give it 4 or 8 gigs,
but it's not a
usable experience.
We get pop-ups saying that
we have to give it more RAM.
TOR NORBYE: Yeah.
So one of the
things we want to do
is to try to autoconfigure that
so you don't have to do it.
We also want to try to reduce
the obvious inefficiencies
in some of the
things we're doing.
We're also looking at
disabling some plugins,
sort of on demand,
because some of them
are pretty resource-intensive
that maybe you aren't using.
So I think our first plan is
to spend the next few releases
just really trying to optimize
things to work better,
as opposed to starting
a brand new tool.
CHET HASSE: Anything else?
Good?
AUDIENCE: All right, thank you.
CHET HASSE: Thank you.
Hi.
AUDIENCE: Hi.
I'm [? Swabnim ?]
from CBS Interactive.
So I have a question regarding
the data mining library.
So I kind of have
mixed opinion regarding
using the data mining library.
So I just want to
ask you, technically,
is it efficient, or
anything, then, let's say,
using Kotlin X [INAUDIBLE]?
Or does data mining
have efficient benefits
or something?
Personally, I don't like
putting the code inside XML.
I just prefer--
YIGIT BOYAR: But don't put
the code inside the XML.
AUDIENCE: But with
data mining, you--
YIGIT BOYAR: Data mining doesn't
require you to put code in XML.
Actually, Jose and I give a
talk in Droidcon two weeks ago.
You can check that one out.
There's a misconception that
just because you could do it,
you should do it.
You don't put all of your code
into your activity either,
right?
It will divide your app.
So same things are
valid in data mining.
Just because you can
write complex expression
doesn't mean you should write.
In terms of efficiency,
yes, actually, data mining
tries to generate
more efficient code
that you would normally write.
But is it a decision point?
Definitely not.
It's not going to
make a big change.
You probably have a
bigger fish to fry.
But I personally like it.
I wrote on it and I used to use
it in other platforms before.
I do like the declarative
nature of data mining
that makes it like you just
said, put this thing here
and it eventually
shows up there.
But it's kind of
a personal choice.
We have these things.
They are not rules,
they are opinions,
and we don't always share
the same opinion, either.
If you like it, use it.
That's great.
And if you don't like
it, it's like you
don't have to use anything.
AUDIENCE: [INAUDIBLE] support
[INAUDIBLE] just [INAUDIBLE]
not that really helps with
the efficiency or anything.
YIGIT BOYAR: Yeah.
I mean, it is
efficient, but it's not
going to make a big change
for your application.
That's the problem.
Yes, we generate,
try to generate,
better code than you would
normally bother with writing.
But is it that important?
I don't think so.
AUDIENCE: OK.
Thank you.
CHET HASSE: Thanks.
Hi.
AUDIENCE: Bunch of
more tooling questions.
Let's start with an easy one.
Can we push for J Unit 5
support in integrated plugin?
Because right now, you have to
use third-party plugin written
by some guy, which every
integrated plugin obviously
breaks, and all that.
And Gradle 4.6 made
the J Unit 5 work out
of the box, and all that.
Can we do it?
TOR NORBYE: That sounds like
a very reasonable request.
Yeah.
AUDIENCE: All right.
Now to the harder ones.
[LAUGHS]
TOR NORBYE: You're
warming me up.
AUDIENCE: Yeah.
There was a question
about Instant Run, right?
Can we please make it a
command line tool, rather than
an integration into
Android studio?
Because right now, three
major build systems--
Bazel, Bulk, Gradle--
Bazel and Bulk
has their own ways
of incrementally [INAUDIBLE].
Gradle hasn't one,
Android Studio has one.
And that's like mismatch.
TOR NORBYE: Yeah so in
the new implementation,
we're not hooking into the
Gradle bite code transformation
pipeline.
It's done at runtime,
a bit like the profiler
does instrumentation.
So it should be easier.
But again, it's not
something we're deliberately
designing for, but we're
trying not to do that.
AUDIENCE: All right.
Harder one now.
So let me put it that way.
Who knows how to
contribute to AOSP?
Well, who is not
Googler, those people.
ROMAIN GUY: Can I quit just
to answer the question?
AUDIENCE: Yeah.
So as you can figure,
particularly with Android KTX
Project, there was
an announcement
that it was moved
from GitHub to AOSP.
For some reason people were
happy, but that's not true.
It's very hard to
contribute to AOSP.
It's really hard to pull it.
ROMAIN GUY: I'm not happy.
I like GitHub.
AUDIENCE: Yeah, yeah.
And a lot of projects from
Google are already on GitHub.
Can we, as a community,
ask for this push for some
of the libraries, maybe?
ROMAIN GUY: Please do.
AUDIENCE: I'm asking.
YIGIT BOYAR: Actually, like
other Android X migration,
when we're internal
discussing moving to a speed,
sort of like internally
developing and syncing.
I was a big proponent.
And I said, look, if you put
this on AOSP, plenty of people
will contribute.
No one [? sends the ?] CL.
So we understand
there's still a barrier,
but we simplified
it significantly.
And we understand there's
[INAUDIBLE],, Repo, tools people
are not very familiar with.
But we also have an
internal integration,
like with the next
version of Android.
We need to stay in the
same BL3 to make this easy.
Oh, there you are.
That guy can answer.
AUDIENCE: Hi. [? Allen ?]
[? Everett, ?] TLM for Android
X. We checked out the Android
X Repo from AOSP onto the two
machines that we have, over
at the Android X booth,
in about five minutes.
And we're up and running
to upload commence.
CHET HASSE: So if you
want to contribute,
just go into the next
room and write some code.
AUDIENCE: Yeah.
AUDIENCE: Cool.
Sounds scalable.
[LAUGHS]
CHET HASSE: There's
a difference, too.
When you say AOSP, when we
think of AOSP contributions
in platform, yes,
that is a big deal.
And we don't expect
a lot of people
are going to absorb the
entire platform to be
able to contribute,
especially since we
don't release the source code
until the release is out.
But the smaller
libraries, like Android X,
we're actually
developing an AOSP.
We would like
contributions, and we
hope that that's low
weight enough for people.
AUDIENCE: We would
love to contribute.
CHET HASSE: Please do.
So get together with
[? Allen ?] and figure out
what the disconnects are
on being able to do that,
because the intention was to
make it much more possible.
AUDIENCE: Some of the projects,
we're able to succeed at that.
Like Dagger, for example.
And you have tooling to sync
it back to your MonoRepos.
I think AOSP is not the
part of MonoRepo Google,
but still is a MonoRepo, so you
should be able to sync it back.
STEPHANIE CUTHBERTSON:
Can I ask a question?
CHET HASSE: Yes.
STEPHANIE CUTHBERTSON: So we
could make contributing to AOSP
easier.
We could also consider GitHub.
I'm curious what you all
would like to see us do.
How many people would
be interested in seeing
us put Android X on GitHub?
Wow.
OK.
How many would like to see
us just make AOSP easier?
AUDIENCE: You can't
make [INAUDIBLE] easier.
STEPHANIE CUTHBERTSON:
OK, thank you.
That was very helpful.
AUDIENCE: Thanks.
CHET HASSE: Thanks.
Hi.
AUDIENCE: Hi.
So I work at a company that does
smart connected devices, which
means that I have had the joy of
interacting with the Bluetooth
API.
I also implemented
barcode scanning recently
in the app, which means I
had the joy of interacting
with the camera API.
ROMAIN GUY: Have you
considered a different job?
AUDIENCE: Only every day.
ANWAR GHULOUM: He's
regretting his life choices.
AUDIENCE: So many of them.
So my question is
with the GSIs, there
was this notion of pulling
things away from the OEMs
and putting them in
Google-controllable land.
And there's lore from
many, many years ago of,
oh, you only run
Bluetooth operations
on Samsung phones
on the main thread.
If you don't, Samsung
phones just goop on you.
Or like, modern phones
don't support Camera2 APIs,
even though they were made
this side of the century.
Is there an effort, or
can there be an effort,
to move all of this
junk that happens
on the cameras and Bluetooth
into Google-controllable land
so that it's not OEM-dependent?
ANWAR GHULOUM: So this might
be a little forward-looking,
but there is an effort
around cameras, specifically,
to try to have a higher-level
API that the chips is part
of the X libraries that smooths
those differences between OEMs.
AUDIENCE: What about Bluetooth?
Because that's
almost even worse.
ANWAR GHULOUM: Yeah, there's
probably a need there.
In fact, we suggest a lot of--
if you can use it, because
it has a limited API,
that you use the Nearby
APIs because they
hide a lot of the messiness
of the underlying application
that we actually check
the quality of those APIs
on different devices.
If not, we can certainly take
it back to the Bluetooth team
and share your pain.
So let us know.
AUDIENCE: But the nearby APIs
don't give you the ability
to assemble the two
packets and actually
communicate with a Smart
Lock that I'm trying
to unlock on someone's door.
That's not what those
APIs are meant for.
But I don't want to have
to remember that, oh,
if I'm on a Samsung
phone, I have
to switch to the main thread.
All other devices, I don't
have to switch to main thread,
except for LG, which
just doesn't work,
all this nonsense.
This should be something
that Google controls.
Why is it something that the
OEMs get to decide on my life?
ANWAR GHULOUM: I'm
going to take this one.
I'm not responsible
for Bluetooth.
But it is pretty
complicated, right?
Bluetooth's standard
isn't totally complete,
or unambiguous about how
certain devices should behave.
So you'll see a
lot of variability
between OEM devices.
Now, some of the stuff
you're describing
seems kind of pointless to have.
So I can take it back
to the Bluetooth team
and talk to them about it.
One of things we've been doing
over the last couple of years
is really trying to improve
Bluetooth implementation
across the ecosystem, including
a rewrite of the Bluetooth
stack, working with our C
vendors, and stuff like that.
All those platitudes
aside, it sounds
like there is this gap
on the developer side
that we need to address, and
I'm happy to take it back
to the team.
I don't know of anything that
they're doing specifically
to address this, like I
do on the camera side.
AUDIENCE: Speaking of
platitude, Bluetooth
has gotten way better
since Android 7.0,
so thank you guys for that.
ANWAR GHULOUM: Cool.
CHET HASSE: It's getting
better, at least.
Yeah, if you can follow up
afterwards with more details,
that'd be awesome.
We are running out of time.
I'm sorry for all the people
who've been standing there
for a while.
If you can ask really
quick questions,
we'll try to get through
as many as we can
before they shut down.
STEPHANIE CUTHBERTSON: And Chet,
can I ask one question, too?
CHET HASSE: Yes, please.
STEPHANIE CUTHBERTSON:
You can take them first.
CHET HASSE: I can what?
STEPHANIE CUTHBERTSON:
They can go first.
That's OK.
ROMAIN GUY: Your turn.
AUDIENCE: Thank you for this
great event and all the support
on the various forums.
I'm showing my gratitude
first because I
have a complaint slash
request for the data mining.
So most of time on Android
Studio, it works fine.
But sometime, even though
I refer to, let's say,
variable name, it doesn't
pick up in XML file.
TOR NORBYE: Yeah.
So we are specifically
trying to address
this with Project Marble.
AUDIENCE: Second thing.
The classes we generate
are in one package.
So what happens is all
the internet classes,
let's say view model or
inside support classes,
I have to make them public
because they are not
accessible in the XML files or
in the data mining generated
classes.
YIGIT BOYAR: No, actually,
when you have a layout file,
you can use the class name.
So if you specify
the class name,
it will change the layout file.
The binding will
have that class name
with the package you provided.
AUDIENCE: But the data
mining generated class,
they are not package-specific.
They are not in one place.
YIGIT BOYAR: No, they are.
If you specify the package
name, then they will be there.
AUDIENCE: Interesting.
I will try that.
YIGIT BOYAR: Find me
afterwards, if maybe I
didn't get the question.
AUDIENCE: And third thing,
if some error happens,
it shows 200-plus error,
which is hard to--
sometimes it takes
some time to--
CHET HASSE: Can we make
that less than 200 errors?
YIGIT BOYAR: That's
a Java C problem.
We haven't foreseen-- we cannot
workaround without breaking
our API.
I wish knew this four years ago.
We would design
something differently.
I'm getting this so many times
that we might actually just
break some of the API to
work around that problem,
like some easy [INAUDIBLE]
AUDIENCE: And last thing.
CHET HASSE: We're
overtime already.
Is it really quick?
AUDIENCE: In XML, can we
import some convenience methods
so that we don't have to put the
business logic inside the XML?
Let's see if null, then
visible, not visible.
If we can reimport
some static function
and we can really use them, like
really small set of functions.
YIGIT BOYAR: Yeah.
Let's talk offline.
AUDIENCE: OK.
CHET HASSE: OK, Steph,
did you something quick?
STEPHANIE CUTHBERTSON:
I have one question
that came out of the community
in advance of this summit,
was people had questions about
how we think about the store
and apps on the store.
We talked about
it in the keynote.
People were just
wondering what's
the reasoning for when
we take apps down.
How can I reach out if
there's been a mistake?
So I actually invited some
friends of mine to come,
like Paul Bankhead.
I was wondering
if any people did
have that question,
if you'd like
to hear Paul talk about it,
because they have certainly
thought about it.
Yes.
Would people like to hear
Paul answer that question?
He's great, by the way.
OK.
CHET HASSE: No pressure.
PAUL BANKHEAD: No pressure.
So sometimes we take
apps down from the store
because your safety is
really, really important.
And we're a marketplace.
We need all of you to create
awesome apps and games
and we need users to come.
And if we don't have either
side of the ecosystem,
we don't have a store.
We don't have Android.
So we really appreciate
everything that all of you
do to create great
apps and games.
There are a handful of
bad actors in the world.
Some of them are really
bad and some of them
are accidentally
doing bad things.
And we have a set of policies
in place to protect our users,
and some of these policies
also protect good developers
from having their stuff
inappropriately used.
So we try really hard to
not have any false positives
and to not make any
mistakes in our enforcement.
If we do make mistakes,
you can appeal.
We look at every appeal and try
to do so within a day or two.
And I think you can expect--
over the next quarters,
we've announced
that we are looking at
further improving the safety
and privacy on the
Android Interplay,
and we are going to do our best
to keep all of you in business
and keep our users safe.
CHET HASSE: Thanks.
Let me check real
quick with the crew.
We're running into
lunchtime right now.
Is it possible to run over and
take a couple more questions,
or do we need to shut down?
AUDIENCE: How about if
we say five more minutes.
CHET HASSE: Five more minutes.
AUDIENCE: OK?
CHET HASSE: Thank you.
Really quick.
Yes, please?
AUDIENCE: OK.
I've been doing Android
TV for three months.
Due to design constraints,
I could not use Leanback,
so I had to do the
fields manually.
I was hoping for better ways
to override Focus Finder.
Sometimes I when
I refresh things,
there is nothing to focus on
anymore or it had gone away.
And sorry for
suggesting more work.
CHET HASSE: Adam?
Have any take on this?
AUDIENCE: Oh, for me?
Oh geez.
Go ahead and find us in
the general questionnaire
afterwards.
I want to know some
more about this.
AUDIENCE: OK.
CHET HASSE: Thanks.
Yes?
AUDIENCE: Hi.
Thanks for the event.
I have two questions.
First of them is
more generic one.
So I hear beacon library's
being deprecated.
So what is the future obligation
detection based on beacons?
ANWAR GHULOUM: That's
a good question.
I mean, you can
still do BLE scans
and use those scans for
location, beacon-based location
using nearby.
What we deprecated was the
nearby notifications stuff,
which, basically, the issue was
the potential for spam or user
abuse through people just
posting inappropriate URLs,
or whatever on these
beacons, and then
people getting notifications
about them constantly.
So you should still
be able to use
BLE scanning to do beacon-based
location applications.
And we do that.
I mean, I don't think we,
as a team, do it directly,
but my team supports that
kind of work in other apps
that are doing
this kind of thing.
AUDIENCE: OK, thank you.
So the second question is
more specific to data mining.
So yeah.
YIGIT BOYAR: Should be a
fireside chat on data mining.
CHET HASSE: I think
we're doing it now.
AUDIENCE: So newer APIs,
so writing binding adapters
in Java class static meta fire,
and writing them and Kotlin
isn't.
It's not supposed to.
But it didn't work for me unless
I edit JVM static annotation.
But in the
documentation, it doesn't
say that I'm required to do so.
It doesn't work.
YIGIT BOYAR: Yeah.
Maybe we should fix
the documentation.
It's like if you write
it as an extension
function on the [INAUDIBLE].
Kotlin ends up generating
a static function.
Then data mining picks
it up automatically.
It works by mistake.
It wasn't intended to.
But it's really nice because
you're binding it up.
There's an actual
extension functions
on the actual [INAUDIBLE],,
like a much more convenient way
to declare them.
But I guess we need to
fix the documentation.
You still need
them to be static,
or you could do
it dynamic, but it
goes through data
mining [INAUDIBLE],,
which I think I'm
going to deprecate
to fix that Java C problem.
AUDIENCE: So if you copy
from the documentation,
it just doesn't work, so I
was just letting you know.
YIGIT BOYAR: I will
get that fixed.
Thanks.
CHET HASSE: Thank you.
Two minutes left.
AUDIENCE: Hi.
I have a quick correction.
Is there any plan that camera
API will be in the Jetpack
with a better interface?
And when will the camera
API1 actually be gone?
Because it's been
deprecated for a while.
ANWAR GHULOUM: I can't speak to
when it will actually be gone.
Hopefully soon.
I think the reason
we kept it around
was to better support low-end
devices that were on chipsets
that can support Camera2 API.
But the plan is to
eventually have it be gone.
I can't really speak to
details on the plans,
including the new camera
APIs in the Jetpack,
because, again, it's sort of
work in progress and stuff
that we're looking at.
But we are keenly
interested in it
because we know
that a lot of apps,
they want to get the best
picture out of the camera,
and they're having to resort
to things like screen scraping
and stuff like that.
AUDIENCE: It's writing
too much code on our side.
ANWAR GHULOUM: Yeah.
It's a high priority for us.
We're aware of it.
Just stay tuned.
Hopefully, next
developer summit,
we'll have something
better to say about it.
AUDIENCE: Great.
Thank you.
CHET HASSE: Does that
mean in three years?
[LAUGHS]
CHET HASSE: Thanks.
Yes?
ANWAR GHULOUM: Three years?
I thought it was four.
AUDIENCE: I was late,
so hopefully this
wasn't already asked.
CHET HASSE: Oh, let
me just summarize
what we've been talking about
for the last [INAUDIBLE]
[LAUGHS]
AUDIENCE: Data binding, right?
So Play Services, and Firebase,
as well, to an extent,
is this huge monolithic
black box that crashes a lot
and has no bug reporter.
Is there anything on your radar
to improve that feedback loop?
Yeah.
It's really frustrating
whenever you have an issue.
We know people in the community
who work directly on Android X
or Frameworks, but as far as
Play Services or Firebase,
it's just, well, you can
dump it into the ether--
CHET HASSE: I'm going to
stop you there because we're
about to run out of time.
Is there anybody that can handle
that question of Play Services
crashing?
ANWAR GHULOUM: I mean,
I work with them a lot,
and some of my colleagues
here do, too, as well.
They've been working really hard
to reduce the number of crashes
in Google Play Services.
They've actually made
a lot of progress.
But it is kind of a volume
game, in a sense, right?
They look at the crashes
that are most frequent
and focus on those.
If you're looking
at crashes that
are induced by certain uses
of the Google Play SDK,
I think that'd be--
we can talk offline
afterwards, if you want,
and I can get you connected
with the right people.
AUDIENCE: Yeah The main
concern is it's not clear
where to file bug reports.
STEPHANIE CUTHBERTSON: So
Zach, you're basically asking,
I'd like a good way
to file bug reports
for Play Services in Firebase?
AUDIENCE: Yeah.
STEPHANIE CUTHBERTSON: OK.
Yeah, we can mention it.
Thank you.
CHET HASSE: Thank you.
Last question.
AUDIENCE: I have two questions,
but I'll ask just one.
CHET HASSE: OK.
AUDIENCE: Firstly, I'd like
to say that I'm new to Android
and it's really good that
we have the Google samples
in every possible
combination, with Rx Java,
with the live data.
So that's really good,
but I was recently
working on a code lab
for dynamic feature,
and I did everything right,
and still, nothing was working.
Because there was some issue
with the flavors in our app.
So can we have more
real-world app samples as well
to reflect such things?
CHET HASSE: Real-world samples.
It's a good request.
There are many, many dev rel
people here who work on stuff.
So that's certainly good
feedback for that team.
It'd be good to get the
details on the specific problem
that you had, and that would
be a good use case for us
to look at if you could
follow up with us.
Thank you.
Thanks, everybody, for coming.
Thanks to the panel.
Thanks for the people
in the audience as well.
[APPLAUSE]
[MUSIC PLAYING]
