[MUSIC PLAYING]
DAVE BURKE: Hey, everyone, and
welcome to the 2018 Android
Developers Summit here at
the historic Computer History
Museum in California.
This is an event for
developers by developers
with tons of in-depth content
and, most importantly,
direct access to the engineers
that actually build Android.
In fact, we have so many
of them here this week
that I'm pretty sure Android
development is going to stop.
In the audience,
we have attendees
from over 70 countries,
both in-person
and on the livestream.
We're glad to have you
all with us here today.
Now, speaking of history,
we're about to celebrate
our 10th anniversary of Android.
And, in fact, it was
about 10 years ago
that the very first customers
were unboxing their G1 devices.
And CNET's review
at the time said,
"Thanks to the openness
of the operating system,
there's huge potential for
the G1 and any Android devices
after it to become powerful
minicomputers as developers
create more applications
for Google Android."
The G1 did OK, but
it's what came next
and what you built on
Android that fundamentally
changed the mobile industry.
10 years ago, the
mobile landscape
looked very different.
Mobile platforms at
the time were not
friendly to developers,
with severely limited APIs
and tools.
But even more problematic
was that each OS
required completely different
and non-transferable skills.
So it was simply impossible to
build a mobile app at scale.
Now, at the same time,
off in a corner of Google,
in building 44, a small
team of dedicated engineers
were quietly working
on what, at the time,
seemed like a crazy project.
The idea was bold--
to build a new open
source operating system
that any device maker could
use with a powerful SDK that
put developers first.
And to many at the time, this
seemed like a harebrained idea.
What did Google know
about telecommunications,
and how could it
possibly influence
this established industry?
It was an intense time
for the Android team.
And to add to the
drama, while getting
close to launching version 1.0,
Apple announced the iPhone.
And it looked awesome.
They brought their A game.
So what were we going to do?
Well, we had two
hardware programs
at the time, the Sooner device,
with a physical keyboard
and the Dream device, which
included a touch screen.
So we had no choice
but to accelerate
the schedule of the Dream.
We felt like we had
a window to deliver
on our vision of the smartphone
before it was too late.
We were racing to
launch, and the team
was incredibly motivated.
So we started a
tradition of putting
on a huge breakfast on Sundays
in building 44 for anyone
who wanted to come in--
bacon, eggs, pastries.
You name it.
And it was super productive.
No meetings, just
coding, and in parallel,
bug triaging and
release planning.
Clearly, these cats do not
know that Android Studio
has code completion.
In the morning, you'd have
a previous week's version
of Android.
But by the evening, some amazing
new piece of functionality
would appear, like
the notification
shade or a new home screen.
It was like watching the OS
come alive before your eyes.
Now, one of the big challenges
in creating a new platform
is the bootstrapping problem.
So how do you motivate anyone
to write an application
for a platform with zero users?
And why would a user buy a
phone with no applications?
So we did two things.
First, the core Android team
wrote mobile app versions
of Google's desktop services,
everything from Gmail
to Maps to YouTube.
And it worked out
well because it
let us experience our APIs
in framework at the same time
as developing the applications.
And it's something that I like
to encourage we do to this day.
But, to make the
platform shine, we
needed apps from
across the industry.
So we launched an early
look SDK in November 2007
and announced the Android
Developer Challenge
with $20 million to be
awarded to the top 100 apps.
And developers around the world
responded, and by April 2008,
just six months later, we
had over 2,000 submissions.
And it was amazing, given that
there were no physical devices
to use for development--
just the emulator.
The apps were
surprisingly diverse,
from games to social
networking and from utilities
to productivity tools.
And location and GPS were
the top used features,
along with camera and
media and messaging.
So it really showed this
pent-up demand for developers
to be creative on mobile and
to use features that we're,
up to now, locked down to them.
Some of the winning apps
are still around today,
like Life360, and several paved
the way for apps and businesses
that would come years later.
The T-Mobile G1
launched in October 2008
with Android Market.
This was the predecessor
to Google Play,
and it had just over
50 apps on day one.
One week later, we opened the
store for developer uploads,
and advanced capabilities
like in-app purchases
and direct carrier billing and
just broader country support
were yet to be built.
The following 10 years was
one of rapid evolution.
In the early days, we were
doing two big releases a year,
and our lead program
manager at the time
made this offhand
suggestion that we
codename the releases after
desserts in alphabetical order.
And that idea stuck, and
here's what came next.
So Android 1.5, Cupcake--
we were eating a lot of
cupcakes at the time--
added virtual keyboard
support so we'd
no longer require that physical
keyboard like on the first G1
device.
We also added the copy
and paste clipboard.
Android 1.6, Donut,
followed, introducing support
for different screen
densities and sizes,
thereby laying the foundation
for a variety of phone sizes
and form factors that were
going to come a couple of years
later.
And that was Dianne
Hackborn's idea.
She's generally about five
years ahead of the rest of us.
Android 2, Eclair, introduced
powerful speech recognition
and changed driving forever
with Google Maps navigation.
Android 2.2, Froyo, took
the speech capabilities
to the next level
with voice actions,
which lets you perform key
functions on your phone
like getting directions and
taking notes and setting
alarms.
And that, of course,
was the precursor
to today's Google Assistant.
Android 2.3, Gingerbread,
was, in many ways,
the first mainstream
version of Android,
and it was the one that
started to get serious scale
with hardware manufacturers.
With Android 3, Honeycomb,
we added support for tablets
with the Holo theme.
But now we had a
problem because phones
were shipping on
Gingerbread and tablets
were shipping on Honeycomb.
So we merged both form factors
with Android 4, Ice Cream
Sandwich.
And in that release, we also
introduced more intuitive
navigation with
the use of gestures
to dismiss notifications
and recent apps.
And that release was also the
arrival of Quick Settings.
Android Jelly Bean was
an incremental release
that included Project
Butter to optimize
graphics to get a buttery
smooth vsync locked animations.
And smooth animations are
something that I personally
obsess about to this day.
Android KitKat came with Project
Svelte that reduced the memory
footprint to 512 megabytes.
And it also included
DSP-offloaded OK Google
hotword.
I heard a beep.
It works.
Android 5, Lollipop,
followed and was
the mother of all releases.
It brought material
design to Android
in giving it entirely
new look and feel.
And so between Project
Butter and material design,
we changed the
narrative on Android,
giving it a beautiful,
refined user experience.
Lollipop also introduced
support for new categories
of computing, including
wearables and auto and TV.
And Lollipop was
the first release
with enterprise features,
such as the work profile,
which we've been
building on ever since.
Lollipop was such
an epic release
that we, frankly, needed to
spend our energy on Android 6,
Marshmallow, on
improving quality.
We also made a major overhaul
of privacy in that release
with the introduction
of runtime permissions.
Android 7, Nougat, brought
significant new capabilities,
including multi-window support,
virtual reality, and new emoji.
Android 8, Oreo, introduced
the Android Go profile
for entry-level smartphones.
And it also came with Project
Treble, a massive overhaul
of the hardware interface layer
to help speed up and reduce
the cost of doing upgrades.
Finally, this year, we
launched Android Pie,
which starts our journey
on an AI-first experience.
It also contains tons
of UI improvements
and simplifications and
introduces the concept
of digital well-being.
So that was a very quick
trip down memory lane.
I think it's pretty incredible
to see just how far we have all
come in a decade of
smartphone development.
And while we're solving
different problems today,
it's clear the
principles upon which
we built Android are just
as true today as they
were 10 years ago.
So principles like
giving developers
a powerful SDK so their apps can
run everywhere or open source
code to enable device
makers from entry level
to high end and an ever
improving UX that delights
users around the world.
So what does the next 10 years
have in store for Android?
Well, I obviously don't
have a crystal ball.
But there are three trends
that I want to call out
that I think are important.
One, smartphones
are getting smarter.
Two, multi-screen
computing is becoming
pervasive with exciting new
form factors on the horizon.
And three, our phones
are going to be
able to help us with safety
and digital well-being.
So first, our smartphones
are about to get a whole lot
smarter.
AI will enable your
phone to get to know
you better, to adapt to you,
and to become more personal.
And you can already see glimpses
of this in Android Pie running
on Google Pixel.
For example, the screen
brightness automatically
learns your preferences,
and the next apps to launch
are predicted with high
accuracy to save you time.
And the camera is able to
recognize objects in real time
with Google Lens.
And the phone can screen
calls with an intelligent AI.
For developers wanting
to tap into AI,
we announced ML Kit
earlier this year.
So whether you're
new or experienced
in machine learning, ML
Kit enables everything
from image labeling to
face detection and more.
ML Kit builds on Android's
neural networks API,
which provides hardware
acceleration by DSPs
and net neural processing
units, or NPUs.
And it's supported on
the latest flagship
devices from Huawei,
[INAUDIBLE],, OnePlus, Google,
and more.
And then API boosts
performance considerably.
So, for example,
MobileNet, which
is a family of vision
models for TensorFlow,
runs eight times faster using an
API on the Qualcomm Snapdragon
845 compared to the CPU.
And you can expect
NPUs to become standard
on all smartphones' silicon
in the next few years.
The second trend
goes beyond phones.
We're investing heavily in
a multi-screen experience.
This means a great Android
experience across TVs,
wearables, cars, and Chromebox.
And we're seeing user growth
in all of these form factors.
For example, user
engagement on Android TV
has grown to three hours
per device per day.
And this year, Android Auto
has seen 250% user growth.
And our partners launched 19
new watches running Wear OS.
And just when you thought you'd
seen everything in phones,
we're about to see a whole new
form factor idea from Android
device makers.
Foldables.
They take advantage of new
flexible display technology
so the screen can
literally bend and fold.
And you can think
of the device really
as both a phone and a tablet.
And broadly, we're
seeing two variants.
There's the two-screen devices
and the one-screen devices.
When folded, it
looks like a phone,
so it fits in your
pocket or purse.
And the defining feature
for this form factor
is something we call
screen continuity.
For example, you
might start a video
on the folded smaller
screen while on the go
but later sit down and want
a more immersive experience.
So you can simply
unfold the device
to get a larger
tablet-sized screen.
And as you unfold,
the app seamlessly
transfers to the bigger
screen without missing a beat.
It's an exciting
concept, and we expect
to see foldable devices from
several Android manufacturers.
In fact, we're already
working closely
with Samsung on
a new device they
plan to launch early
next year, which
you'll hear about later today.
For our part, we're
enhancing Android
to take advantage of
this new form factor
with as little work
as possible from you.
For example, we're
adding resizable flags
so your app can respond
to folding and unfolding.
And we expect to see
a lot of innovation
in foldable hardware
over the next few years.
And we're excited to see
what you come up with.
The third trend is
safety and well-being.
Smartphones have gone
from non-existent
to indispensable
in just 10 years.
In fact, the very idea
of leaving your home
without your smartphone
literally sends shivers
down people's spines.
And at Google, we like to build
products that give you utility,
whether that's
putting the world's
information at your
fingertips or navigating you
to where you need to be or
translating a foreign language.
But beyond utility, we
feel a responsibility
to your safety and well-being.
As one example, more
than 80% of emergency
calls originate
from mobile phones.
However, locating these
phones in an emergency
can be challenging since
traditional emergency location
technologies often
fail indoors or have
a radius that's too large.
In a serious emergency,
minutes can mean the difference
between life and death.
We launched Android's emergency
location service, ELS, in 2016
and just recently announced
bringing it to the US.
With ELS, when you dial 911,
or your country's equivalent,
your location is
accurately calculated
through a combination
of Wi-Fi cell towers
and GPS signals
and sent directly
to the emergency provider.
ELS is built into
99% of Android phones
all the way back to
version 4, and we're
continuing to look
at new ways to help
improve your safety with
lots of ideas in the works.
Now, having a smartphone
with you all day is awesome,
but we also want to make
sure you're in control
of your digital well-being.
And we know from our
research that 72% of people
are concerned with the amount
of time they spend on tech.
So with Android Pie this
year, we introduced new tools
to let you control your usage
with things like app limits,
grayscale Wind Down,
and do not disturb
that blocks all distractions.
Of course, like most features,
we've added developer hooks.
So you can now tell if
do not disturb is enabled
or if your app is
temporarily limited.
And you can implement
an intent filter
so your app has its
own usage dashboard.
We're continuing to
invest in this space
with lots of
enhancements planned.
OK, so let's wrap up.
Android, from the beginning,
was conceived as a platform
built around developers.
We've poured a ton of energy
into growing this ecosystem
and community from
the ground up.
I see our developer
tools and frameworks
as living, breathing things.
So we're constantly
striving to be better.
And in return, you've
been an amazing community,
building incredible
apps and services
that enable and delight
users the world over.
We simply could not do this
without you, so thank you.
So with that, let's
get down to business.
I'm excited to
hand over to Steph
and team to talk about
some of the recent work
we've been doing to
increase developer
productivity on Android.
Thank you.
[APPLAUSE]
[MUSIC PLAYING]
RAHUL GANJOO: Zomato
started as an app which
lets you browse digital menus.
Now we are this big
full-tech company
that in operation
in 24 countries.
More than 150 million users
visit the platform every month.
We are available
in 10 languages.
And on the delivery
side, we have
a fleet of around
60,000 delivery riders.
PRATEEK SHARMA: After all
the buzz in the development
community about
Kotlin, I was intrigued
by how Kotlin was able to uphold
the object-oriented paradigm
and solve many of the
architectural flaws
in the combined [INAUDIBLE].
I almost instantly
recognized that Kotlin
will enable me to develop
more architecturally-sound
applications.
Almost all the new SDKs and
APIs that Google is releasing
right now has Kotlin support.
If you converted
Java class to Kotlin,
there will be about 15% to 20%
decrease in the line of code.
But if you did
data classes, there
is a drastic
improvement of about 55%
decrease in the lines of code.
Switching to Kotlin is
efficient and really exciting.
On Zomato now, almost
every new feature
is being developed in Kotlin.
I would recommend
switching to Kotlin
because of its
interoperability with Java.
With recent updates,
Android Studio
has drastically
improve Kotlin support.
It is almost frictionless.
[MUSIC PLAYING]
[APPLAUSE]
STEPHANIE CUTHBERTSON:
Hey, everyone.
I'm Steph.
I'm on the Android team.
And Dave is right.
Developers influence
the platform.
You're not on top of it.
You're a part of what we do.
Kotlin's a great example.
It's not a
Google-designed language.
It was not, maybe,
the obvious choice.
But it was the best
choice, as you made clear.
We could see developers
voting with their feet
in the adoption in the months
before we announced support.
Like Kotlin, our
developer investments
come down to two
things at heart.
Number one, your
feedback, and number two,
Google engineers using
Android and thinking,
how do I make something
people will love?
So the past several years,
we've been investing deeply
in Android's
developer experience.
It's been guided
by your feedback.
We'll talk about that.
We're also going to talk
about some new things
that we have to share.
So each year we've
been investing.
Let's start with IDEs.
In 2013, we first
demoed Android Studio
at I/O. It was a new
IDE built on InteliJ
designed to accelerate
Android development.
Over five years, we've
progressively built it out,
based on the features
you asked for most--
completely new emulators, a new
compile tool chain, profilers,
mobile layout tools, like
constraint layout, better C++,
inspectors for things
like layouts and app size,
and tools for every
dessert release.
We also wanted to
add the little things
that make a big difference,
whether that's Maven
integration to lint checks.
Second, APIs.
In 2016, Dianne Hackborn
wrote a famous post
on app architecture saying,
we're not opinionated,
to which you replied,
please be opinionated.
So we created
architecture components,
and we've refined them with
feedback over many EAPs
and expanded them now
into Android Jetpack.
We see Jetpack as the
future of our mobile APIs.
They are opinionated
and easy to use,
intuitive APIs that
work on 95% of devices.
We want them to integrate
seamlessly with Android's core
primitives so you get the
best possible combination
of efficiency everyday
and also deep control.
Expect to see us continue
expanding Jetpack every year.
Third was languages.
In 2017, we announced
support for Kotlin.
We've added since then
IDE support, API support,
docs, samples, and moved it
into the Kotlin Foundation,
working with the wonderful
language authors.
Fourth, app delivery.
So developers have always
loved the Play Store
for the fast delivery times.
That's great when you want
to launch and innovate fast.
But you told us app
size is way too big,
and that really hurts install.
So this year, we
announced the App Bundle
and dynamic delivery.
Developers using this
are slimming down apps
worldwide with most apps
saving up to and over 30%.
Finally, security.
Android was built with
security in mind from day one
with application sandboxing.
As Android's matured, we've
expanded our mobile security
services.
Today 99% of abusive
apps are taken down
before anyone can install.
And after you install, we
use Google Play Protect
to scan over 50
billion apps per day.
That's every kind of app
on every connected device.
When we find a
potentially harmful app,
we disable it or we remove it.
But let's say you're
doing everything right,
and you accidentally
get caught in this net
without someone to talk to.
This is a place I think
we need to do better.
We need to make it
much easier for you
to reach us in these cases.
So our engineering director
will be here tomorrow
at the fireside chat to
talk with you about it
and get your feedback.
Now, another way we
protect the ecosystem
is moving apps to target current
APIs, like API 26 by November.
And you told us,
OK, makes sense,
but please give us a
long notice period.
So that's why we gave
almost a year's notice.
We think of you as
a part of how we
work, whether it's early
ideas, to advisory boards,
reading Reddit threads, beta,
and iterating after launch.
We really want to
be trustworthy.
And we've definitely
heard about things
that you loved like architecture
components and Kotlin.
Sometimes we have
underestimated the time
it takes to get things
right, like Instant Run.
What we've heard is you
want from us open sharing,
so you're can see
things that are early--
as long as we're
clear this is early--
as well as things that
are ready for production.
So that's what we'll do today.
Let's shift gears.
Today, I'm going to share
a range of early ideas all
the way to stable releases.
I want to walk you through
two big themes for Android
development.
First, foundations, using
languages and libraries
to work smarter.
Second, productivity,
using mobile IDEs,
console in distribution,
to develop easier,
have higher quality apps,
and to grow adoption.
We're going to start with
foundations and Kotlin.
Throughout, I wanted
you to hear from some
of the people who have been
instrumental in these projects.
So we're going to
start with someone who
was key in the Kotlin decision.
He's a huge
contributor to Android,
both while he was
in the community,
now on the Google team.
It's a privilege to turn
things over to Jake Wharton.
[MUSIC PLAYING]
[APPLAUSE]
JAKE WHARTON: Hey, everyone.
So I'm Jake.
I'm part of the team working
on Kotlin for Android.
And it's been 18 months
since Steph was onstage
at Google I/O just
down the road from here
announcing that Kotlin
would be supported
as a new first-class language.
So something that had never been
done in the history of Android.
But based on positive feedback
from developers like you
and the growing adoption
that we've seen in apps,
it's clear that this
was the right choice.
According to GitHub's
yearly stats,
Kotlin is the number one
fastest-growing language
in terms of contributors.
Stack Overflow's
yearly survey places
Kotlin as number two
most-loved programming language
by those who participated.
For Android, 46% of
pro Android developers
are now using Kotlin
to build their apps.
This was according to a
survey of those visiting
developer.android.com.
In October, we had 118,000
seven-day active projects using
Kotlin and Android Studio.
This is based on those who
opt in to reporting analytics.
That's a 10x increase from
the numbers last year.
Now when Kotlin
support was announced,
there already were a bunch
of apps that were using it
in the Play Store.
And that group continues to
grow and includes new apps
like WeChat, Amazon
Kindle, and Twitter.
Just prior to Google
I/O this year,
the Kotlin language moved
into the Kotlin Foundation.
And we're fortunate to
partner with JetBrains,
who spent a tremendous
amount of resources
on improving the
language itself.
Just last week, they
released the newest version
of Kotlin, 1.3, with new
language features, APIs,
bug fixes, and
performance improvements.
For example, inline classes,
which, in most cases,
don't actually allocate
like a normal class
would unless they're boxed.
For constrained
devices that we target,
avoiding allocation while
still retaining type safety
is a big one.
The Kotlin Standard
Library now includes
a set of unsigned numbers,
such as uint, ubyte, and ulong.
And these are built using
that inline class feature.
And in addition to Kotlin code
targeting Android or the JVM,
you can now target JavaScript
or now Native code as well.
This unlocks the possibility of
reusing parts of your code base
on more platforms.
And finally, the long-awaited
coroutine support
is now stable in 1.3, which
is a lighter-weight version
of threading.
The language and library
support for coroutines
combine and simplify how you
do asynchronous operations
or perform concurrent
work, things that are
essential to every Android app.
And, as I'm sure you are,
we're looking forward
to using these new Kotlin
features in the Kotlin-specific
APIs that we provide.
So far, the majority
of those have
been through the
Kotlin extensions,
which are part of Jetpack.
This year at I/O, we announced
that the Kotlin extensions were
expanding from just
core KTX to seven KTX
libraries for common artifacts
that you use from Jetpack,
like Fragments,
SQLite, Lifecycle.
And all of these are now
available as stable releases.
Since then, though, as new APIs
are added to existing libraries
or new libraries are
added to Jetpack,
the KTX extensions are
being built alongside.
So things like navigation,
paging, and Slices
are all new libraries
that each have extensions
being built with them.
And we're starting to go beyond
just providing extensions.
So Lifecycle is going to
support a coroutine scope
so you can easily launch
coroutines and have
automatic cancellation.
And WorkManager will be
offering a work object
based on coroutines.
And we're always on the
lookout for integrations
like these that provide
more close interoperability.
If you want to get started with,
say, coroutines on Android,
there's a new code lab
that you can work through.
It covers performing
asynchronous work, testing
of coroutines, and the
WorkManager integration.
Since Kotlin isn't just a
language for building Android
apps, Google Cloud Platform
now offers samples, tutorials,
and their own code lab so you
can build your application back
end using Kotlin.
And finally, new
Udacity courses are
available in preview today,
which cover app development
entirely in Kotlin.
And they use both Jetpack and
popular third-party libraries.
To speak more about
Jetpack as a whole,
I'd like to turn it
over to Romain Guy.
[MUSIC PLAYING]
[APPLAUSE]
ROMAIN GUY: Hi.
I'm Romain.
I work on the Androids
framework team.
So a few months
ago, we announced
Jetpack, the next generation
of Android tools and APIs
to accelerate Android
application development.
Jetpack builds on the
foundation that we laid out
with support library and net
architectural components.
But we also add new tools
and libraries to the mix.
Jetpack is about
writing less code
and targeting more devices.
All Jetpack libraries
are backwards compatible
and target up to 95% of
existing Android devices.
We first started running
early-access programs
on architectural components
about two years ago,
and our first public beta was 18
months ago at Google I/O 2017.
Today, out of the top
1,000 applications
in active development
on Play Store,
798 are already using Jetpack.
This is up from about 560
at Google I/O this year.
Jetpack is used in
many applications,
like New York Times, KakaoTalk,
Duolingo, Evernote, Uber,
SoundCloud, Pandora, Twitter,
Dropbox, Viber, and many more.
Apps built all over the world in
India, Germany, France, Korea,
Israel, China, the US, and more.
Also, at I/O, we
announced new libraries
for paging, navigation,
WorkManager, Slices, and Kotlin
extensions we just talked about.
Although these are still in the
early phases of development,
they are already being used
in over 38,000 applications
worldwide.
And the evolution of
those AndroidX libraries
is driven in large part
by the feedback we receive
from you, the community.
But we know that
many of you have long
expressed a desire to do
more than simply be feedback.
So that's why, this summer, we
moved all AndroidX development
to public airway speed.
You can now see features and bug
fixes implemented in real-time,
and you can contribute to any
of the AndroidX libraries.
All you need is Android
Studio and the public SDK.
And we also want to
use AOSP as a place
where we can experiment
and prototype new ideas.
And our hope is that early
access to Android features
will help us refine and help
shape even better libraries.
So please join us.
With Jetpack, we introduced
two architectural component
libraries-- navigation
and WorkManager.
The navigation architectural
component library
offers a simplified way to
implement Android's navigation
principles in your application
using a single activity.
This solution gives you
consistent animations
across devices, atomic
navigation operations,
and easier animated transitions.
WorkManager makes it easy
to perform background tasks
in the most efficient
manner possible.
You do not need to
wonder whether you
should be using JobDispatcher,
JobScheduler, or AlarmManager.
WorkManager will
figure out which
is the best solution
given the application
state and the device API level.
These two libraries will
become beta later this month.
So if you have any
feedback about those APIs,
the Android teams are
here today and tomorrow.
So now is the time to
give us that feedback.
We also introduced
Android Slices, a new way
to bring users to
your applications.
Slices are like a [INAUDIBLE]
to surface content outside
of your application.
It's going to help users
book a flight, play video,
call a ride, and so on.
Slices are another example where
we want to be open very early,
but we want to take the
time to get things right.
After working with several
of you on the APIs,
we're moving into public
EAP at the end of the month
with [? Doist, ?] KAYAK,
and many other applications.
We will run experiments
surfacing Slices
in Google search results.
And there's a session
today with more info
on best practices about building
Slices, so please check it out.
Our team has also
been hard at work
bringing numerous improvements
to existing AndroidX libraries.
For instance, in Paging
2.0, you have more control
over memory usage, and it offers
better Kotlin integration.
Room 2.1 is our biggest
feature launch since 1.0.
We added full-text search
tables, database views, better
[INAUDIBLE] in the
two-value integration.
Data binding 3.2
brings much faster,
multimodule compilation, and
we expect further improvements
in 3.4.
And, finally, ViewModel
let's you save state in AOSP.
One thing you told
us worked pretty well
was deeply integrating
libraries and tools in Android.
[INAUDIBLE] was one example.
But a new great example
of this is navigation.
So in Android Studio 3.3, we
have a new navigation editor
to help you easily understand,
visualize, and build navigation
flow in your application.
So let's go straight to a
demo of the navigation editor.
So here, I have an
application that
was already partially written.
And you can already see
the flow of navigation
through the different
screens of the application.
So if I run the demo
on the emulator--
and we wait for
Gradle to do its job--
I can click on leaderboards.
I can see different profiles.
But if I click on the
profile, nothing happens.
I can go back to the
editor, add a new screen--
so I just select the Fragments
to view user profiles.
And then I link the leaderboard
screen to the user profile.
I also need to add [INAUDIBLE]
for the selected user.
It's a string and
just rerun the app.
Wait for Gradle.
The tools team
will probably want
to chat with me after this.
[LAUGHTER]
We go back to leaderboards, and
if I click on the profile now,
I can see the profile.
But as I go back and forth
between those two screens,
you can see that there are no
animations, no transitions.
So if I go back to the editor
and I select this navigation
flow, I can choose
which animations I want.
So I'm going to choose the
enter animations and the exit
animations.
And now, if I reruns
the app one last time--
go back to leaderboards,
and now you
can see the sliding transition.
So if you want to play
with the navigation--
[APPLAUSE]
So if you want to play with
the navigation [INAUDIBLE],,
all you have to do is download
Android Studio from the better
channel today and get started.
And as we expand the Android
Jetpack libraries and tools
together, we're focused on your
feedback about the [INAUDIBLE]
that you encounter.
So please let us know.
We want to know
about animations, UI,
themes and styles,
camera, anything else.
We are here today.
We are here tomorrow.
You can tell us what
you need from us.
And with that, I
would to turn it over
to Karen, who will let you know
about our plans for Android
Studio.
Thanks.
[MUSIC PLAYING]
[APPLAUSE]
KAREN NG: Hi.
I'm Karen.
I'm on the team that builds
Android Studio and Android
Jetpack.
So Romain and Jake
just talked to you
through the language
and library experiences.
To build on top
of that, I'm going
to talk to you
about productivity
and what we're doing
with Android Studio.
For three two, we
asked ourselves,
what can we do to have
a meaningful impact
on productivity,
and where do you
spend the most of your time?
We heard loud and clear--
thanks, Romain-- that
it's build speed.
It's something that
you do every day.
He set me up.
It's something you do every
day, multiple times a day.
And every minute
that you're waiting
for that build to finish, we
know it's a minute wasted.
So we took a deep look at our
data to see what was going on.
And we actually found
two things to be true.
The first thing we found
was that build speeds
in our opt-in data is actually
getting slower over time.
The second thing we found is
that new releases of Studio
are actually
improving build times.
In the last year and a half,
we saw build speeds get faster
by 42% on fresh projects.
So something's going on, and
we had to take a deeper look.
Code bases are just
getting larger.
Custom plugins are
adding to build times.
Annotation processors
that people use
are negating the benefit
of incremental build.
New languages could add
to compilation times.
And if you have many
modules, resource management
can add time as well.
The ecosystem and
project growth are
kind of outgrowing our
build improvements.
We are committed to
making build faster.
You'll find a large part of the
team on build here this week
to listen and learn
and to tell you
more about what we're doing.
We want to get this right, and
we need your help to do it.
We're giving ourselves
stretch goals.
We're working on
attribution tools
to help you better
understand what's impacting
your build in your projects.
And we're making Gradle and
our first-party plugins faster.
We also know that
iteration speed
is super important
to app development
because it's all about
trying things out, iterating,
and then failing fast
and then doing it again.
With Instant Run, we want
to fix what we started
and quickly apply
changes without losing
the state of your app.
Part of that apply changes
is around deployment times.
So we know they
play a huge part,
and we've just shipped an update
in Android Pie where we're
seeing a big difference in
real-world and sample projects
between Pie and [INAUDIBLE].
If you're using USB
3.0 versus USB 2.0,
we've seen some times that seem
close to that emulator speed.
Please let us know if you're
interested in giving us
early feedback to get
apply changes right.
We're starting an EAP very soon.
That takes us to emulators.
Because we want to make
iteration speed faster,
we're investing in
emulators for every OS.
At I/O, we showed
the ability to save
a snapshot of your current
state of your emulator and boot
up and switch to any snapshot
in under two seconds.
Productivity is
also about making
the hard problems easier.
We heard that it's
really hard to see
how your app is impacting
battery life on the phone.
So we built the new
energy profiler in 3.2
You can now see WakeLocks,
visualize the estimated battery
usage of system components, and
inspect background events that
contribute to battery drain.
The new beta for
Android Studio 3.3
is available today and was
just released moments ago.
We know that in order for
an IDE to be delightful
and to keep you productive,
it has to be not just stable,
but it has to be rock-solid
stable because of the number
of hours that you spend there.
The main focus for
our next few releases
will be quality, which we're
calling Project Marble,
reducing the number of crashes,
hangs, and memory leaks,
fixing user-impacting bugs, and
investing in our infrastructure
and tools.
We know that sometimes
we've missed memory leaks
before we shipped.
So we're building tools to help
detect those leaks before they
even happen.
Dave mentioned how
millions of Android apps
already run on Chromebooks.
We're bringing the full
power of Android Studio
as an officially supported IDE
to Chrome OS early next year.
You'd like to try it
today, you can learn more
at developer.android.com.
Now, I'd like to invite
Matt Henderson up
to share more about app
size and what we're doing
with the Android App Bundle.
[MUSIC PLAYING]
[APPLAUSE]
MATT HENDERSON: Thanks,
Karen, and hi, everybody.
So I work on developer
tools like the Play console,
and I wanted to start by
talking about app size.
Apps have grown
dramatically in size.
The average is up
five times since 2012.
But larger size carries a cost.
It reduces the install
conversion rate,
and it increases uninstall rate.
Now, you told us that using
multi APK to configure
different app versions was a
painful way to reduce app size.
So the Android App Bundle
makes it much simpler.
Using the App Bundle,
we reduce size
by generating an APK for
the languages, the screen
density, the CPU architecture
that each user needs.
And it's working.
While size reductions
vary, on average,
apps are seeing a
35% reduction in size
compared to a universal APK.
Now, with the recent stable
release of Android Studio 3.2,
app bundles in production
have taken off.
They're up 10 times.
Thousands of developers
have embraced App Bundles,
and the number of
bundles in production
now total billions of installs.
And Google's apps,
they're switching too.
YouTube, Google Maps,
Photos, Google News
are all in production
with App Bundles today.
Photos, for example,
is now 40% smaller.
So we're really excited about
the App Bundles' potential.
We sign APKs for
delivery to the end user.
This is highly secure.
We protect your key
in the same memory,
in the same storage we
protect Google's own keys.
This signing step is critical.
It allows us to process
the App Bundle in order
to generate the optimized APKs.
And this, in turn,
allows you to benefit
from additional optimizations in
the future, starting right now.
So I'm happy to announce that
the App Bundle now supports
uncompressed Native libraries.
This utilizes an existing
Android platform feature
that was little used
because, in the past,
you would have had
to use multi APK
for pre-M and post-M devices.
Now, we just do it for you.
With no additional
developer work needed,
the App Bundle now makes
apps using Native libraries
an average of 8%
smaller to download
and 16% smaller on
disc for MPlus devices.
By adding dynamic feature
modules to your app bundle,
you can load any app
functionality on demand
instead of at install time.
For example, you don't need
to send that same big feature
to 100% of your users
if it's only going
to be used by 10% of them.
And you don't need to
keep big features that
are only used once.
Dynamic features can be
installed and uninstalled
dynamically when your
app requests them,
or you can choose to defer
installing to a later time
when the app goes
to the background.
Facebook was one of
our launch partners,
and they are using
dynamic features
in production in the
main Facebook app
and in Facebook Lite.
For example, card
scanning is a feature
that only a small percentage of
Facebook's user base is using,
so moving it to
a dynamic feature
avoids it taking up
almost two megabytes
on each user's device.
Within an App Bundle,
installed and instant apps
can share the same base module
and the same dynamic feature
modules.
So separating out functionality
as a dynamic feature
is a great way to get
your base small enough
to offer an instant
app experience.
Now you can stop
building and testing
dynamic features using
Android Studio 3.2 today,
and you can join our beta and
become white-listed to publish
them to production.
Now, I'd like to
invite Aurash Mahbod up
to tell us more
about app updates.
[MUSIC PLAYING]
[APPLAUSE]
AURASH MAHBOD: Good job.
Awesome.
Thanks, Matt.
So, yeah, we've
heard your feedback,
that you'd like more
control to ensure
that users are running the
latest and greatest version
of your app.
To address this, I'm excited
to announce the Google Play
in-app update API.
The update API has two variants.
The first is an
immediate update flow
where the user is presented
with a full-screen experience.
They can accept the update,
have it downloaded and installed
immediately before proceeding.
Many of you have already
implemented similar variants
of this in your app.
But this new streamlined
implementation
is less error prone and
super easy to integrate.
Next is flexible updates.
Flexible updates are really
cool because they actually
allow the update experience to
be integrated into your app,
and it feels far
more customized.
As an example, Google
Chrome has opted
to nudge users to update
with a small affordance.
If the user accepts that
update, the download
happens in the
background, and the user
can continue to use your app.
When the download
is complete, it's
up to use the developer to
decide if you'd like the update
to be applied immediately
by presenting an affordance,
or if you'd simply
like the update
to be applied the next time
the app is in the background.
Google Chrome is
testing this now,
and we're excited to be
expanding the early access
program coming soon.
Next, instant apps.
Instant apps are now available
on over 1.3 billion devices,
helping more users
discover your apps.
We've been hard at work on
simplifying the development
experience for instant apps.
Earlier this year, we increased
the size limit for instant apps
from four megabytes
to 10 megabytes.
And what we found is that
just by using the Android App
Bundle, many
developers are already
able to get under that size
limit without additional work.
Additionally, the
dynamic features
that Matt mentioned earlier
are also instant compatible,
so you get two-for-one savings.
We've also made it possible
to now upload and test
instant apps of any size.
This allows you to both
iterate on the user
experience at the same time
that you're optimizing for size.
And we've also made
web URLs optional.
What this means is
that you can now
just take your existing
Play Store deep link traffic
and reroute those users
into your instant experience
automatically.
And lastly, I'm excited
to announce that today,
in the Android
Studio 3.3 beta, you
can now have a
single Android Studio
project that houses both your
instant and installed apps.
This dramatically simplifies
the development experience
for instant apps.
And additionally, the app bundle
that's emitted by this project
can be uploaded once
to the Play Developer
console, dramatically
simplifying release management
as well.
We're super excited about it.
And with that, back to Steph.
[MUSIC PLAYING]
[APPLAUSE]
STEPHANIE CUTHBERTSON:
Android's open source and scale
means it's incredible to
watch what you're building
on top of the platform.
With over two billion devices,
3/4 of a trillion apps
downloaded every
year, and developers
in 194 countries, Android's
developer community
is growing hugely.
In countries like
India and Brazil,
we saw it more than double
just in the past few years.
So we're seeing innovation
on Android worldwide.
Android's not a conventional
operating system
in how we work with developers.
We want to get your input
in our GDE community,
in open source collaborations,
like the Kotlin Foundation.
And we want to be
open in new places
like our medium
developer channel.
It's by developers
for developers
to share more technical
behind the scenes.
Today and tomorrow, about 500
members of the team are here.
We'll have over 30 sessions
of technical content.
It's livestreamed
and on YouTube,
so the whole community
can participate.
We feel lucky to
be a part of it.
So that's it for the keynote.
Thank you.
I hope you enjoy
Android Dev Summit.
[MUSIC PLAYING]
