The latest Android and Google Play news for app and game developers.
Posted by Chris Sells, Benjamin Poiesz, Karen Ng, Product Management, Android Developer Tools
Today we're excited to introduce Android Jetpack, the next generation of components, tools and architectural guidance to accelerate your Android app development.
Android Jetpack was inspired by the Support Library, a set of components to make it easy to take advantage of new Android features while maintaining backwards compatibility; it's currently used by 99% of every app in the Play Store. Following on that success, we introduced the Architecture Components, designed to make it easier to deal with data in the face of changes and the complications of the app lifecycle. Since we introduced those components at I/O just one year ago, an overwhelming number of you have adopted them. Companies such as LinkedIn, Zillow and iHeartRadio are seeing fewer bugs, higher testability and more time to focus on what makes their app unique.
The Android developer community has been clear -- not only do you like what we've done with these existing components, but we know that you want more! And so more is what you get.
Android Jetpack is a set of components, tools and guidance to make great Android apps. The Android Jetpack components bring together the existing Support Library and Architecture Components and arranges them into four categories:
Android Jetpack components are provided as "unbundled" libraries that are not part of the underlying Android platform. This means that you can adopt each component at your own speed, at your own time. When new Android Jetpack functionality is available, you can add it to your app, deploy your app to the Play Store and give users the new features all in a single day (if you're quick)! The unbundled Android Jetpack libraries have all been moved into the new androidx.* namespace (as described in detail in this post).
androidx.*
In addition, your app can run on various versions of the platform because Android Jetpack components are built to provide their functionality independent of any specific version, providing backwards compatibility.
Further, Android Jetpack is built around modern design practices like separation of concerns and testability as well as productivity features like Kotlin integration. This makes it far easier for you to build robust, high quality apps with less code. While the components of Android Jetpack are built to work together, e.g. lifecycle awareness and live data, you don't have to use all of them -- you can integrate the parts of Android Jetpack that solve your problems while keeping the parts of your app that are already working great.
We know that these benefits are important to you because of feedback like this:
"We had been thinking of trying out MVVM in our code base. Android Architecture Components gave us an easy template to implement it. And it's helped make our code more testable as well; the ability to unit test ViewModels has definitely increased code robustness."
-- Sumiran Pradhan, Sr. Engineer, Zillow
If you want to learn more about how companies are using Android Jetpack components, you can read the developer stories on the Android Developer site.
And finally, as you can see from the Android Jetpack diagram above, today we're announcing new components as well.
Android Jetpack comes with five new components:
The WorkMananager component is a powerful new library that provides a one-stop solution for constraint-based background jobs that need guaranteed execution, replacing the need to use things like jobs or SyncAdapters. WorkManager provides a simplified, modern API, the ability to work on devices with or without Google Play Services, the ability to create graphs of work, and the ability to query the state of your work. Early feedback is very encouraging but we love to make sure that your use cases are covered, too. You can see what we have so far and provide feedback on our alpha on the WorkManager component.
While activities are the system provided entry points into your app's UI, their inflexibility when it comes to sharing data between each other and transitions has made them a less than ideal architecture for constructing your in-app navigation. Today we are introducing the Navigation component as a framework for structuring your in-app UI, with a focus on making a single-Activity app the preferred architecture. With out of the box support for Fragments, you get all of the Architecture Components benefits such as Lifecycle and ViewModel while allowing Navigation to handle the complexity of FragmentTransactions for you. Further, the Navigation component allows you to declare transitions that we handle for you, automatically builds the correct Up and Back behavior, includes full support for deep links, and provides helpers for connecting Navigation into the appropriate UI widgets, like the navigation drawer and bottom navigation. But that's not all! The Navigation Editor in Android Studio 3.2 allows you to see and manage your navigation properties visually:
The Navigation component is also in alpha and we'd love your feedback.
Data presented in an app can be large and costly to load, so it's important to avoid downloading, creating, or presenting too much at once. The Paging component version 1.0.0 makes it easy to load and present large data sets with fast, infinite scrolling in your RecyclerView. It can load paged data from local storage, the network, or both, and lets you define how your content gets loaded. It works out of the box with Room, LiveData, and RxJava.
And finally, to round out the set of new features making their debut in Android Jetpack is the Slices component. A "slice" is a way to surface your app's UI inside of the Google Assistant as a result of a search:
You can learn all about the Slices component and how to integrate it into your app on the Android Developer website.
And last but not least, one goal of Android Jetpack takes advantage of Kotlin language features that make you more productive. Android KTX lets you transform Kotlin code like this:
view.viewTreeObserver.addOnPreDrawListener( object : ViewTreeObserver.OnPreDrawListener { override fun onPreDraw(): Boolean { viewTreeObserver.removeOnPreDrawListener(this) actionToBeTriggered() return true } });
into more concise Kotlin code like the following:
view.doOnPreDraw { actionToBeTriggered() }
This is just the first step in bringing Kotlin support to Android Jetpack components; our goal is to make Android Jetpack great for Kotlin developers (and of course Java developers!).You can read more about Android KTX on the Android Developer web site.
You can get started with Android Jetpack at developer.android.com/jetpack. You'll find docs and videos for Android Jetpack, see what's new in Android Jetpack components, participate in the community and give us feedback. We've also created a YouTube playlist devoted to Android Jetpack, so you can tune in for information about Android Jetpack, components, tools and best practices.
Getting Started with Android Jetpack will tell you how to bring the Android Jetpack components into your existing apps and help you get started with new Android Jetpack apps. Android Studio 3.2 has great tooling support for Android Jetpack. For building new apps, use the Activity & Fragment+ViewData activity, which you can get to from File | New | New Project in Android Studio:
With Android Jetpack, we're taking the benefits of the Support Library and the Architecture Components and turning it up a notch with new components, Android Studio integration and Kotlin support. And while Android Jetpack provides the next generation components, tools and guidance to accelerate your Android development, we've got a lot more that we want to do and we want your help. Please go to developer.android.com/jetpack and let us know what we can do to make your experience building Android apps even better.
Today, we launch an early preview of the new Android extension libraries (AndroidX) which represents a new era for the Support Library. Please preview the change and give us your feedback. Since this is an early preview, we do not recommend trying this on any production projects as there are some known issues.
The Support Library started over 7+ years ago to provide backwards compatibility to framework APIs. Over the years, the library has grown to include device-specific UX, debugging, testing and other utilities. The adoption of the Support Library has been phenomenal; most Android apps use the Support Library today. We want to increase our investment in this area, and it is critical that we lay a solid foundation.
In that vein, we took a step back and chatted with many of you. The feedback has been consistent and unanimous; the organic growth of the library has become confusing. There are components and packages named "v7" when the minimal SDK level we support is 14! We want to make it clear for you to understand the division between APIs that are bundled with the platform and which are static libraries for app developers that work across different versions of Android.
With that in mind, say "Hello World" to "AndroidX". As previously noted in the Android KTX announcement, we are adding new features under this package, and updating some existing ones.
android.* vs androidx.* namespaces
android.*
Writing Android apps means depending on two kinds of classes:
PackageManager
AppCompatActivity
ViewModel
Many times, unbundled libraries can be a better choice, since they provide a single API surface across different Android versions. This refactor moves the unbundled libraries - including all of the Support Library and Architecture Components - into the AndroidX package, to make it clear to know which dependencies to include.
Revised naming for packages and Maven artifacts
We redesigned the package structure to encourage smaller, more focused libraries that relieve pressure on apps and tests that aren't using Proguard or Multidex. Maven groupIds and artifactIds have been updated to better reflect library contents, and we have moved to prefixing library packages with their groupId to create an obvious link between the class that you are using and the Maven artifact from which it came.
Generally, you can expect the following mapping from old to new packages:
android.support.**
androidx.@
android.databinding.**
androidx.databinding.@
android.design.**
com.google.android.material.@
android.support.test.**
androidx.test.@
The Architecture Components libraries have also been moved under androidx and their package names simplified to reflect their integration with core libraries. A sample of changes to these libraries:
androidx
android.arch.**
android.arch.persistence.room.**
androidx.room.@
android.arch.persistence.**
androidx.sqlite.@
Additionally, following the introduction in 28.0.0-alpha1 of Material Components for Android as a drop-in replacement for Design Library, we have refactored the design package to reflect its new direction.
For a complete listing of mappings from 28.0.0-alpha1 (android.support) to 1.0.0-alpha1 (androidx), please see the full AndroidX refactoring map. Please note that there may be minor changes to this map during the alpha phase.
android.support
Per-artifact strict semantic versioning
Starting with the AndroidX refactor, library versions have been reset from 28.0.0 to 1.0.0. Future updates will be versioned on a per-library basis, following strict semantic versioning rules where the major version indicates binary compatibility. This means, for example, that a feature may be added to RecyclerView and used in your app without requiring an update to every other library used by your app. This also means that libraries depending on androidx may provide reasonable guarantees about binary compatibility with future releases of AndroidX -- that a dependency on a 1.5.0 revision will still work when run against 1.7.0 but will likely not work against 2.0.0.
Migration from 28.0.0-alpha1
Moving your app from android.support to androidx-packaged dependencies has two major parts: source refactoring and dependency translation.
Source refactoring updates your Java code, XML resources, and Gradle configuration to reference the refactored classes and Maven artifacts. This feature is available in Android Studio Canary 14 for applications targeting Android P.
If you depend on a library that references the older Support Library, Android Studio will update that library to reference androidx instead via dependency translation. Dependency translation is automatically applied by the Android Gradle Plugin 3.2.0-alpha14, which rewrites bytecode and resources of JAR and AAR dependencies (and transitive dependencies) to reference the new androidx-packaged classes and artifacts. We will also provide a standalone translation tool as a JAR.
What's next?
We understand this is a big change for existing projects and codebases. Our intention is to provide a strong foundation that sets Android library projects up for more sustainable growth, better modularity, and smaller code size.
We hope that these changes also make it easier for developers to discover features and implement high-quality apps in less time; however, we understand that migration takes time and may not fit into everyone's production schedule. For this reason, we will continue to provide parallel updates to an android.support-packaged set of libraries for the duration of the P preview SDK timeframe. These updates will continue the 28.0.0 versioning scheme that began with 28.0.0-alpha1 in March 2018, and they will continue to be source-compatible with existing projects that depend on the android.support package.
The stable release of 28.0.0 will be the final feature release packaged as android.support. All subsequent feature releases will only be made available as androidx-packaged artifacts.
We'd love to hear from you as we iterate on this exciting future. Send us feedback by posting comments below, and please file any bugs you run into on AOSP.
We look forward to a new era of Android libraries!
Play Console
