State of Kotlin on Android New Update | Google IO 2021

State of Kotlin on Android New Update | Google IO 2021

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.

Leave a Reply

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

Sundar Pichai's Notifications    Yes No thanks