Android users care a lot about the battery life on their phones. In particular, how your app schedules deferrable background tasks play an important role in battery life. To help you build more battery-friendly apps, we introduced WorkManager as the unified solution for all deferrable background processing needs.
Starting November 1, 2020, we are unifying deferrable background tasks on Android around WorkManager, and GCMNetworkManager will be deprecated and no longer supported.
The WorkManager API incorporates the features of Firebase Job Dispatcher (FJD) and GcmNetworkManager solutions, providing a consistent job scheduling service back to API level 14 while being conscious of battery life. For example, if your app needs to send log files up to the server, it would be more efficient to wait until the device is both charging and connected to WiFi. In this case, WorkManager will ensure that the sync will execute when the given constraints (charging and connected to WiFi) are met. Additionally, it does not require Google Play Services, unlike FJD and GcmNetworkManager.
Some of the other key features of WorkManager include:
Now that the WorkManager library has reached maturity, we have decided to deprecate alternative solutions to simplify the developer story and focus on WorkManager stability and features.
targetSdkVersion
Now is the time to migrate your apps to WorkManager if you haven't already done so! You can start by reading the official documentation for WorkManager.
If your app is still using FirebaseJobDispatcher, you can migrate your app to WorkManager by following the migration guide. A similar migration guide from GCMNetworkManager to WorkManager is also available.
YouTube recently moved over to WorkManager for their background scheduling needs and has reported improvements in app startup time as well as an 8% drop in crash rates.
The team is dedicated to improving and continuing feature development on WorkManager. If you encounter issues using the library, have proposals for features you would like to see, or have any feedback about the library, please file an issue.
Kevin Chyn, Android Framework
Curtis Belmonte, Android Framework
With the launch of Android 10 (API level 29), developers can now use the Biometric API, part of the AndroidX Biometric Library, for all their on-device user authentication needs. The Android Framework and Security team has added a number of significant features to the AndroidX Biometric Library, which makes all of the biometric behavior from Android 10 available to all devices that run Android 6.0 (API level 23) or higher. In addition to supporting multiple biometric authentication form factors, the API has made it much easier for developers to check whether a given device has biometric sensors. And if there are no biometric sensors present, the API allows developers to specify whether they want to use device credentials in their apps.
The features do not just benefit developers. Device manufacturers and OEMs have a lot to celebrate as well. The framework is now providing a friendly, standardized API for OEMs to integrate support for all types of biometric sensors on their devices. In addition, the framework has built-in support for facial authentication in Android 10 so that vendors don’t need to create a custom implementation.
The FingerprintManager class was introduced in Android 6.0 (API level 23). At the time -- and up until Android 9 (API level 28) -- the API provided support only for fingerprint sensors, and with no UI. Developers needed to build their own fingerprint UI.
FingerprintManager
Based on developer feedback, Android 9 introduced a standardized fingerprint UI policy. In addition, BiometricPrompt was introduced to encompass more sensors than just fingerprint. In addition to providing a safe, familiar UI for user authentication, it enabled a small, maintainable API surface for developers to access the variety of biometric hardware available on OEM devices. OEMs can now customize the UI with necessary affordances and iconography to expose new biometrics, such as outlines for in-display sensors. With this, app developers don’t need to worry about implementing customized, device-specific implementations for biometric authentication.
BiometricPrompt
Then, in Android 10, the team introduced some pivotal features to turn the biometric API into a one-stop-shop for in-app user authentication. BiometricManager enables developers to check whether a device supports biometric authentication. Furthermore, the setDeviceCredentialAllowed() method was added to allow developers the option to use a device’s PIN/pattern/password instead of biometric credentials, if it makes sense for their app.
BiometricManager
setDeviceCredentialAllowed()
The team has now packaged every biometric feature you get in Android 10 into the androidx.biometric Gradle dependency so that a single, consistent, interface is available all the way back to Android 6.0 (API level 23).
androidx.biometric
The androidx.biometric Gradle dependency is a support library for the Android framework Biometric classes. On API 29 and above, the library uses the classes under android.hardware.biometrics, FingerprintManager back to API 23, and Confirm Credential all the way back to API 21. Because of the variety of APIs, we strongly recommend using the androidx support library regardless of which API level your app targets.
Biometric
android.hardware.biometrics
androidx
To use the Biometric API in your app, do the following.
$biometric_version is the latest release of the library
$biometric_version
def biometric_version= '1.0.0-rc02' implementation "androidx.biometric:biometric:$biometric_version"
The BiometricPrompt needs to be recreated every time the Activity/Fragment is created; this should be done inside onCreate() or onCreateView() so that BiometricPrompt.AuthenticationCallback can start receiving callbacks properly.
Activity
Fragment
onCreate()
onCreateView()
BiometricPrompt.AuthenticationCallback
To check whether the device supports biometric authentication, add the following logic:
val biometricManager = BiometricManager.from(context) if (biometricManager.canAuthenticate() == BiometricManager.BIOMETRIC_SUCCESS){ // TODO: show in-app settings, make authentication calls. }
The BiometricPrompt constructor requires both an Executor and an AuthenticationCallback object. The Executor allows you to specify a thread on which your callbacks should be run.
Executor
AuthenticationCallback
The AuthenticationCallback has three methods:
onAuthenticationSucceeded()
onAuthenticationError()
onAuthenticationFailed()
The following snippet shows one way of implementing the Executor and how to instantiate the BiometricPrompt:
private fun instanceOfBiometricPrompt(): BiometricPrompt { val executor = ContextCompat.getmainExecutor(context) val callback = object: BiometricPrompt.AuthenticationCallback() { override fun onAuthenticationError(errorCode: Int, errString: CharSequence) { super.onAuthenticationError(errorCode, errString) showMessage("$errorCode :: $errString") } override fun onAuthenticationFailed() { super.onAuthenticationFailed() showMessage("Authentication failed for an unknown reason") } override fun onAuthenticationSucceeded(result: BiometricPrompt.AuthenticationResult) { super.onAuthenticationSucceeded(result) showMessage("Authentication was successful") } } val biometricPrompt = BiometricPrompt(context, executor, callback) return biometricPrompt }
Instantiating the BiometricPrompt should be done early in the lifecycle of your fragment or activity (e.g., in onCreate or onCreateView). This ensures that the current instance will always properly receive authentication callbacks.
onCreate
onCreateView
Once you have a BiometricPrompt object, you ask the user to authenticate by calling biometricPrompt.authenticate(promptInfo). If your app requires the user to authenticate using a Strong biometric or needs to perform cryptographic operations in KeyStore, you should use authenticate(PromptInfo, CryptoObject) instead.
biometricPrompt.authenticate(promptInfo)
authenticate(PromptInfo, CryptoObject)
This call will show the user the appropriate UI, based on the type of biometric credential being used for authentication – such as fingerprint, face, or iris. As a developer you don’t need to know which type of credential is being used for authentication; the API handles all of that for you.
This call requires a BiometricPrompt.PromptInfo object. A PromptInfo is where you define the text that appears in the prompt: such as title, subtitle, description. Without a PromptInfo, it is not clear to the end user which app is asking for their biometric credentials. PromptInfo also allows you to specify whether it’s OK for devices that do not support biometric authentication to grant access through the device credentials, such as password, PIN, or pattern that are used to unlock the device.
BiometricPrompt.PromptInfo
PromptInfo
Here is an example of a PromptInfo declaration:
private fun getPromptInfo(): BiometricPrompt.PromptInfo { val promptInfo = BiometricPrompt.PromptInfo.Builder() .setTitle("My App's Authentication") .setSubtitle("Please login to get access") .setDescription("My App is using Android biometric authentication") .setDeviceCredentialAllowed(true) .build() return promptInfo }
For actions that require a confirmation step, such as transactions and payments, we recommend using the default option -- setConfirmationRequired(true) -- which will add a confirmation button to the UI, as shown in Figure 2.
setConfirmationRequired(true)
setConfirmationRequired(false)
Now that you have all the required pieces, you can ask the user to authenticate.
val canAuthenticate = biometricManager.canAuthenticate() if (canAuthenticate == BiometricManager.BIOMETRIC_SUCCESS) { biometricPrompt.authenticate(promptInfo) } else { Log.d(TAG, "could not authenticate because: $canAuthenticate") }
And that’s it! You should now be able to perform authentication, using biometric credentials, on any device that runs Android 6.0 (API level 23) or higher.
Because the ecosystem continues to evolve rapidly, the Android Framework team is constantly thinking about how to provide long-term support for both OEMs and developers. Given the biometric library’s consistent, system-themed UI, developers don’t need to worry about device-specific requirements, and users get a more trustworthy experience.
We welcome any feedback from developers and OEMs on how to make it more robust, easier to use, and supportive of a wider range of use cases.
For in-depth examples that showcase additional use cases and demonstrate how you might integrate this library into your app, check out our repo, which contains functional sample apps that make use of the library. You can also read the associated developer guide and API reference for more information.
Posted by Doug Stevenson, Developer Advocate
Later this year, the Google Play services and Firebase SDKs will migrate from the Android Support libraries to androidx-packaged library artifacts. We are targeting this change for June/July of 2019. This will not only make our SDKs better, but make it easier for you to use the latest Jetpack features in your app.
androidx-packaged
If your app depends on any com.google.android.gms or com.google.firebase libraries, you should prepare for this migration. To quickly test your build with androidx-packaged library artifacts, add the following two lines to your gradle.properties file:
com.google.android.gms
com.google.firebase
gradle.properties
android.useAndroidX=true android.enableJetifier=true
If your build still works, then you're done! You will be ready to use the new Google Play services and Firebase SDKs when they arrive. If you experience any new build issues or want more information on this migration, visit the official Jetpack migration guide. We will communicate when the androidx migration is complete in the near future, stay tuned!
Posted by Karen Ng, Group Product Manager and Jisha Abubaker, Product Manager, Android
Last year, we launched Android Jetpack, a collection of software components designed to accelerate Android development and make writing high-quality apps easier. Jetpack was built with you in mind -- to take the hardest, most common developer problems on Android and make your lives easier.
Jetpack has seen incredible adoption and momentum. Today, 80% of the top 1,000 apps in the Play store are using Jetpack. We’ve also heard feedback from so many of you across our early access developer programs and user studies, as well as Reddit, Stack Overflow, and Slack, that has helped shape these APIs. Very humbly, thank you.
Today, we are excited to share with you 11 Jetpack libraries that can be used in development now and an early-development, open-source project called Jetpack Compose to simplify UI development.
CameraX
We've heard from many of you that developing camera apps or integrating camera functionality within your existing apps is hard. With the new CameraX library, we want to enable you to create great camera-driven experiences in your application without worrying about the underlying device behavior. This API is backwards compatible to Android 5.0 (API 21) or higher, ensuring that the same code works on most devices in the market. While it leverages the capabilities of camera2, it uses a simpler, use case-based approach that is lifecycle-aware eliminating significant amount of boilerplate code vs camera2. Finally, it enables you to access the same functionality as the native camera app on supported devices. These optional Extensions enable features like Portrait, Night, HDR, and Beauty.
LiveData and Lifecycles w/ coroutines
We heard you loud and clear and agree that LiveData must support your common one-shot asynchronous operations. With Lifecycle & LiveData KTX, you can do so with Kotlin coroutines that are lifecycle-aware. Kotlin coroutines have been well received by the developer community for how they simplify the way concurrency is handled within Android apps. We want to simplify it even further and enable you to use them safely by offering coroutine scopes tied to lifecycles, coroutine dispatchers that are lifecycle-aware, and support for simple asynchronous chains with the new liveData builder.
Benchmark
The Benchmark library provides you a quick way to benchmark your app code, whether it is written in Kotlin, the Java programming language or native code. We use this library to continuously benchmark Jetpack libraries we release to ensure we do not introduce any latency into your code. You can now do the same right within your development environment in Android Studio, easily measuring database queries, view inflation, or a RecyclerView scroll. The library takes care of what is needed to provide reliable and consistent results like handling warm-up periods, removing outliers, and locking CPU clocks.
Security
To maximize security of an application’s data at-rest, the new Security library implements security best practices for you. It provides strong security that balances encryption with performance for consumer apps like banking and chat. It also provides a maximum level of security for apps that require a hardware-backed keystore with user presence and simplifies many operations including key generation and validation.
ViewModel with SavedState
ViewModel provided you an easy way to save your UI data in the event of a configuration change. It did not save your app state in the event of process death, and many of you have been relying on SavedInstanceState alongside ViewModel. With the ViewModel with SavedState module, you can eliminate boilerplate code and gain the benefits of using both ViewModel and SavedState with simple APIs to save and retrieve data right from your ViewModel.
ViewPager2
ViewPager2, the next generation of ViewPager, is now based on RecyclerView and supports vertical scrolling and RTL (Right-to-Left) layouts. It also provides a much easier way to listen for page data changes with registerOnPageChangeCallback.
registerOnPageChangeCallback.
ConstraintLayout 2.0
ConstraintLayout 2.0 brings up new optimizations, and new way of customizing layouts, with the addition of helper classes. As part of ConstraintLayout 2.0, MotionLayout provides an easy way to manage motion and widget animation in your applications. You can easily describe transitions between layouts and animation of properties. MotionLayout is fully declarative in XML, allowing you to describe even complex transitions without requiring any code.
Biometrics Prompt
Users are accustomed to biometric credentials on their phones, but if your app requires a biometric login, it is important to make sure that users are provided a consistent and safe way to enter their credentials. The Biometrics library provides a simple system prompt giving the user a trustworthy experience.
Enterprise
With the Jetpack Enterprise library, your managed enterprise apps can send feedback back to Enterprise Mobility Management providers in the form of keyed app states, while taking advantage of backwards compatibility with managed configurations.
Android for Cars
With the Android for Cars libraries, you can provide your users a driver-optimized version of your app that will be automatically installed onto the vehicle’s infotainment system in vehicles equipped with the Android Automotive OS. It also allows your apps to work with the Android Auto app, providing the driver-optimized version anytime on their device.
And in case you missed it, we announced stable releases of Jetpack WorkManager (background processing) and Jetpack Navigation (in-app navigation) just a few months ago.
Today, we open-sourced an early preview of Jetpack Compose, a new unbundled toolkit designed to simplify UI development by combining a reactive programming model with the conciseness and ease-of-use of Kotlin. We have always done our best work when we did it with you - our developer community. That’s why we decided to develop Jetpack Compose in the open, starting today.
In that vein, we took a step back and chatted with many of you. We heard strong feedback from developers that they like the modern, reactive APIs that Flutter, React Native, Litho, and Vue.js represent. We also heard that developers love Kotlin, with over 53% of professional Android developers using it and with 20% higher language satisfaction ratings than the Java programming language. Kotlin has become the fastest-growing language in terms of number of contributors on GitHub.
So, we decided to invest in the reactive approach to declarative programming and create an easier way to build UIs with Kotlin.
We are building Compose with a few core principles:
A Compose application is made up of composable functions that transform application data into a UI hierarchy. A function is all you need to create a new UI component. To create a composable function just add the @Composable annotation to the function name. Under the hood, Compose uses a custom Kotlin compiler plug-in so when the underlying data changes, the composable functions can be re-invoked to generate an updated UI hierarchy. The simple example below prints a string to the screen.
We know that adopting any new framework is a big change for existing projects and codebases, which is why we’ve designed Compose like all of Jetpack -- with individual components that you can adopt at your own pace and are compatible with existing views.
If you want to learn more about Jetpack Compose or download its source to try it for yourself, check out http://d.android.com/jetpackcompose
We'd love to hear from you as we iterate on this exciting future together. Send us feedback by posting comments below, and please file any bugs you run into on AOSP or directly through the feedback buttons in the Android Studio Jetpack Compose build in AOSP. Since this is an early preview, we do not recommend trying this on any production projects.
Happy Jetpacking!
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:
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!