Hi, my name is Jeffrey van Gogh. I’m a tech lead on Android Studio.
I’m responsible for Android programming language support.
I’m excited to tell you about what’s new on Kotlin on Android.
For those of you new to Kotlin,
it’s an expressive, statically typed language perfect for writing apps on Android.
It’s mature, open source, and it’s used by millions of developers around the world.
A lot is happening around Kotlin for Android. Let’s start by looking at Kotlin’s momentum.
It’s been four years since we announced support for Kotlin on Android,
and its use continues to grow.
Looking at the top 1,000 apps by number of installs on Google Play,
we see that 80% of them contain Kotlin code,
and 60% of Android developers are now using Kotlin.
It’s not just the top of the market adopting Kotlin.
Several thousands of developers completed our Android Kotlin training courses
and codelabs in the last year.
We also launched Android Basics in Kotlin,
a full course in learning writing Android apps for beginners.
Of course, Google has started using Kotlin in our own apps too.
It is currently used in over 70 of our published applications.
We’ve adopted coroutines as the future for concurrency
across both Android and server applications written in Kotlin.
As a result, the amount of Kotlin code in Google’s MonoRepo is rapidly growing.
We now have over 100 teams and several thousand engineers using Kotlin
across Android and server applications.
Kotlin powers the servers for some of our biggest products,
including Google Voice, Nest and Google Shopping.
These are impressive numbers, and we always knew there’re many reasons
why so many people love Kotlin.
You’ve heard us talk a lot about Kotlin’s expressiveness,
and features like properties & extension methods,
the safety brought through things like nulliblity and string templates,
easier interoperability with existing code & structured concurrency through coroutines.
These are benefits that we have experienced ourselves and hear users talk about.
The cool thing is we can measure some of these benefits.
A recent Google internal analysis of apps available on Google Play
showed that apps who adopt Kotlin saw over 10% reduction
in the number of users who experienced crashes.
Even with all these benefits,
we understand that learning any new language can be a challenge.
To help, we launched a Kotlin Google Developers Experts program.
We have 50 GDEs around the world who share knowledge about Kotlin
in talks articles and through open-source contributions.
So follow them to learn more.
These GDEs provide Kotlin-related content for Android, server, and multi-platform.
Alongside all these great educational resources,
we’re also making Kotlin easier to use through ever-improving tooling.
First of all, you can now write your Gradle build files in Kotlin script.
This eliminates needing to learn Groovy
and also gives you all the benefits of Kotlin in your build files,
like autocomplete, refactoring, and more.
This was enabled by a brand-new Kotlin DSL for the Android Gradle plugin.
We recently posted documentation for this new DSL on developers.android.com
Speaking of Kotlin Gradle, we made lots of improvements
in Gradle’s interaction with Kotlin.
We made KAPT more reliable and incremental.
We also fixed several issues in incremental Kotlin compilation
and we landed Gradle configuration caching in Kotlin.
Together, they should give a lot of build speed improvements.
Another thing to help build times and improve expressiveness
is Kotlin Symbol Processors, or KSP.
We launched the first developer preview of KSP a year ago,
and recently the first alpha.
The goal of KSP is to make symbol processing
a first-class feature in the Kotlin ecosystem.
No more Java stub generation for your KAPT and associated long build times.
KSP integrates with the Kotlin compiler and provides access to all Kotlin symbols,
It has support for incremental and multi-run processing
and it’s multi-platform ready.
The Jetpack Room library has KSP support in beta,
and we’re seeing 2x faster processing with KSP than we saw through KAPT.
We need your help in converting existing annotation processors to KSP.
You can find the status of KSP and the list of popular processors
via the link on the slide.
All these improvements’ll hopefully make your builds faster,
but you care about IDE performance too.
Our team works closely with JetBrains to address performance issues in the IDE.
In Kotlin 1.5, we fixed many performance issues that affect large real-world projects.
As a result of these improvements, we see up to 20x faster auto-import suggestions
and up to 2x faster code completions for projects with complex dependency graphs.
Make sure to upgrade to the latest versions of Android Studio & the Kotlin IDE plugin
to benefit from these improvements.
Even with these efforts, we know both build speed
and IDE responsiveness remain the top concerns with adopting Kotlin.
To address this, Google and JetBrains have been working on a rewrite of the compiler.
Here, you can see a typical Kotlin compilation pipeline.
The compiler is divided into two parts: the frontend and backend.
The frontend takes care of code correctness; the backend takes care of code generation.
We started a rewrite with the new JVM IR Backend compiler,
which was launched in Kotlin 1.5.
The new IR Backend compiler comes with a rich set of compiler plugin APIs.
These APIs are what powers the Jetpack Compose language extensions.
The new backend allows us to unify the frontend of the compiler
between JVM, JS and Native.
Both JetBrains and Google are working hard bringing you this new unified frontend
and hope to have it available later this year.
The new frontend will bring 2x faster compilations
and drastically improve IDE performance.
Please try the new Backend as well as the experimental Frontend and send us feedback.
Even with amazing tooling a language wouldn’t be complete without a great set of libraries.
I’ll hand over to Wojtek to talk about some improvements made in that area this year.
Thanks, Jeffrey.
When we first announced Kotlin support on Android,
we started something called Android KTX.
Back then, it was a single library
with some useful Kotlin extensions for framework APIs.
Today, KTX has grown into dozens of artifacts for various Jetpack APIs.
Moreover true to our Kotlin-first commitment, we started writing new libraries in Kotlin.
That way, we can benefit from features
like coroutines and flow in popular libraries,
such as Paging and DataStore while keeping their APIs usable
from code written in the Java programming language.
And then we went even further when we decided to fully invest in Kotlin
when building our next generation UI toolkit, Compose,
which is based around the Kotlin compiler plugin
and as such needs the code to be written in Kotlin as well.
Other product teams of Google are finding success with Kotlin too.
With releases of extensions for SDK, such as Maps, Places, Firebase, and Play Core
writing apps for Android becomes safer and more seamless for Kotlin developers.
Looking beyond Android, there are already libraries built
by server-side engineering teams on Google, such as the Kotlin gRPC library,
which we open-sourced last year.
And just recently, the new Kotlin bindings
for protocol buffers were released, offering a Kotlin DSL for working with protobufs.
Last year, we announced that Kotlin coroutines
are the officially recommended way to do asynchronous operations
in Android when using Kotlin.
Many of the libraries that I just mentioned
incorporate coroutines in their API surface, including flows,
for observable streams of values.
With new additions of StateFlow and SharedFlow to the coroutines library,
we’ll be looking at how to best incorporate them
into our training materials and future APIs.
For example, developers ask us
if LiveData would be deprecated in favor of StateFlow.
So far, LiveData was a convenient way to observe state updates from the UI,
and it remains exactly that for Java programming language users.
In Kotlin, StateFlow can serve an equivalent function,
while also supporting the power of suspending functions in operators.
And if you had to keep using LiveData just because of data binding
you will be happy to hear the newest versions
of Android Studio support observing StateFlows directly in your bindings.
For observing flows in the UI without data binding,
you could use the AndroidX Lifecycle KTX library.
However, the existing functions like launchWhenStarted,
have a particular pausing behavior that could potentially lead
to wasting resources when the UI is not active.
We are currently adding a new set of functions
that will make it safe to observe any flow in the UI
thanks to auto cancellation and restarting of any jobs scheduled with this API.
So watch out for alpha releases of Lifecycle KTX
and give us your feedback on these new APIs.
Because coroutines are becoming more common in apps
the ability to properly debug and understand what's going on
under the hood is very important for developers.
That’s why we’re finally bringing the Coroutines Debugger
from IntelliJ IDEA to Android.
It will be available using a future version of Android Studio,
but let me quickly show you what it can do.
When using the debugger, you’ll can switch to the Coroutines tab
where you can see details about active dispatchers and any coroutines.
You can check the coroutines status, such as running or paused in the UI,
or dump everything into a file.
And lastly, one reminder, together with JetBrains,
we are phasing out the support for the Kotlin Android Extensions plugin.
Specifically, when using Kotlin synthetics for Android Views.
The recommended migration path is to use Android ViewBinding.
The parcelize feature is still supported,
but it has now moved to a separate plugin: kotlin-parcelize.
So all you need is to update your build files and imports.
Now we've talked about Kotlin today,
but we didn’t forget about developers who are not using Kotlin in their apps.
In fact, all of the Android platform APIs are written
in the Java programming language
and are used by Kotlin and Java developers alike.
There are also many popular libraries that are written in Java,
which are contributing to a healthy developer ecosystem.
Kotlin’s popularity and success comes in a big part
from being able to evolve quickly
and add modern features that developers want.
However, the Java language spec does not stand still.
And today we can see many similar improvements
being incorporated into it.
For example, records, which resemble Kotlin data classes.
We will be assessing these new features
and working hard to bring them to Android development.
We have two important projects that are helping us achieve this goal.
First, we're bringing support for additional language features
in Android Gradle Plugin 7.
We're also adding new Java language APIs to Android 12
and we’re making them available for use on older devices through library desugaring.
And finally, I’m excited to share that the Android Runtime, known as ART,
is becoming an updateable mainline module starting in Android 12,
which means we’ll be able to update supported language features
and even add new APIs on future Android devices directly
without waiting for full operating system updates.
For now, there is no action required from developers.
We will share more details about how this affects
SDK targeting in your apps in a future announcement.
We hope you like what’s in store for Kotlin and Java language development on Android.
Whether you’re looking to onboard developers to Kotlin
or if you’re a library author looking to use new language features, we got you covered.
Check out the links in the description below for more information
and look out for more content on coroutines, flow, KSP,
and more coming to our social channels soon.
Thanks for watching, and go build better apps with Kotlin.