[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]