Android Developers Blog: Jetpack

One Biometric API Over all Android

30 October 2019

Posted by Isai Damier, Android Developer Platform Engineering (@isaidamier)

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. A bit of background 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. 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. 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. 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). How it works 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. To use the Biometric API in your app, do the following. 1. Add the Gradle dependency to your app module $biometric_version is the latest release of the library def biometric_version= '1.0.0-rc02' implementation "androidx.biometric:biometric:$biometric_version"2. Check whether the device supports biometric authentication 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. 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. }3. Create an instance of BiometricPrompt 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. The AuthenticationCallback has three methods:

onAuthenticationSucceeded() is called when the user has been authenticated using a credential that the device recognizes.

onAuthenticationError() is called when an unrecoverable error occurs.

onAuthenticationFailed() is called when the user is rejected, for example when a non-enrolled fingerprint is placed on the sensor, but unlike with onAuthenticationError(), the user can continue trying to authenticate.

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. 4. Build a PromptInfo object 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. 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. 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.

Figure 1. Example face authentication flow using BiometricPrompt with setConfirmationRequired(false).

Figure 2. Example face authentication flow using BiometricPrompt with setConfirmationRequired(true) (default behavior).5. Ask the user to authenticate 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. Going forward 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.

Google Play services and Firebase migrating to AndroidX

03 June 2019

Posted by Doug Stevenson, Developer AdvocateLater 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. 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: android.useAndroidX=true android.enableJetifier=trueIf 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!

What’s New with Android Jetpack and Jetpack Compose

08 May 2019

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. What’s New in Jetpack 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. Now in Alpha 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. Now in Beta 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. Now in Stable 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. Jetpack Compose 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:

Build with the benefits that Kotlin brings -- concise, safe, and fully interoperable with the Java programming language. Designed to drastically reduce the amount of boilerplate code you have to write, so you can focus on your app code, and help avoid entire classes of errors.

Fully declarative for defining UI components, including drawing and creating custom layouts. Simply describe your UI as a set of composable functions, and the framework handles UI optimizations and updates to the view hierarchy under the hood.

Provide reusable building blocks that let you build custom widgets easier, and without starting from scratch.

Compatible with existing views so you can mix and match and adopt at your own pace with direct access to all of the Android and Jetpack APIs.

Material Design out of the box and animations from the start, so it’s easy to create beautiful apps that are full of motion.

Accelerate development with tools like live preview and apply changes.

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!

Google I/O 2018: What’s new in Android

08 May 2018

Posted By Stephanie Cuthbertson, Product Management Director, Android Developer KeynoteDevelopment: making mobile development fast and easy

Android Jetpack — Today, we announced Android Jetpack, designed to accelerate your app development. Android Jetpack is the next generation of Android components, bringing together the benefits of the Support Library -- backwards compatibility and immediate updates -- to a larger set of components, making it quick and easy to build robust, high quality apps. Android Jetpack manages activities like background tasks, navigation, and lifecycle management, so you can eliminate boilerplate code and focus on what makes your app great. Android Jetpack is designed to work well with Kotlin, saving you even more code with Android KTX. The new Android Jetpack components released today include WorkManager, Paging, Navigation, and Slices.

Kotlin — Since announcing support for Kotlin last year, the developer community has embraced the language. Most importantly, 95% of developers tell us they are very happy with using Kotlin for their Android development. And, the more developers use it, the more that number rises. The number of Play Store apps using Kotlin grew 6x in the last year. 35% of pro developers use it, and that number is growing each month. We are continuing to improve the Kotlin developer experience across our libraries, tooling, runtime, documentation and training. Android KTX is launching today as part of Android Jetpack to optimize the Kotlin developer experience. Tooling continues to improve with Android Studio, Lint support, and R8 optimizations. We have even tuned the Android Runtime (ART) in Android P, so that apps built with Kotlin can run faster. We have rolled out Kotlin code snippets in our official documentation, and are publishing a Kotlin version of the API reference documentation today. Earlier this week, we launched a new Kotlin Bootcamp on Udacity, which is a great resource for developers who are new to Kotlin. Lastly, we now have a Kotlin specialization in the Google Developers Experts Program. If you still haven't used Kotlin, I hope you you give it a try.

Android Studio 3.2 Canary — Android Studio 3.2 features tools for Android Jetpack including a visual Navigation Editor and new code refactoring tools. The canary release also includes build tools to create the new Android App Bundle format, Snapshots in the Android Emulator for fast start time, new R8 optimizer for smaller download and install app code size, a new Energy Profiler to measure app impact on battery life, and more. You can download the latest version of Android Studio 3.2 from the canary channel download page.

Distribution: making apps radically smaller

Android App Bundle & Google Play Dynamic Delivery — Introducing the new app model for Android. Dramatically reduce app size with a new publishing format—the Android App Bundle. In Android Studio, you'll now build an app bundle that contains everything your app needs for any device—all the languages, every device screen size, every hardware architecture. Then, when a user downloads your app, Google Play's new Dynamic Delivery will only deliver the code and resources matching the user's device. People see a smaller install size on the Play Store, can download your app more quickly, and save space on their devices.

An example of all resources being delivered to a device via a legacy APK and an example of Dynamic Delivery serving just what’s needed to a device.

(Left) An example of all resources being delivered to a device via a legacy APK.
(Right) An example of Dynamic Delivery serving just what’s needed to a device.

Dynamic features via the Android App Bundle — The Android App Bundle also enables modularization so that you can deliver features on-demand, instead of during install. You can build dynamic feature modules in the latest Android Studio canary release. Join our beta program to publish them on Google Play.

Google Play Console — New features and reports in the Play Console will help you improve your app's performance and grow your business. Read about the improvements to the dashboard, statistics, Android vitals, pre-launch report, acquisition report, and subscriptions dashboard. You can also upload, test, and publish apps using our new publishing format, the Android App Bundle.

Google Play Instant — After launching in beta at GDC, today we announced that all game developers can build instant apps and we're thrilled to welcome Candy Crush Saga. Google Play Instant is now available on over 1 billion devices worldwide from the Play Store, search, social and most places you can tap a link. To make instant apps easier to build, we are launching a Unity plugin and beta integration with Cocos creator this week. Recently, we've started testing Google Play Instant compatibility with AdWords, allowing people to try out games directly from ads, across all the channels reached by Universal App campaigns.

Engagement: bringing users back more and more.

Slices — Slices are UI templates that display a rich array of dynamic, and interactive content from your app, across Android and within Google surfaces. Slices can include live-data, scrolling content, inline actions, and deep-linking into your app so users can do everything from playing music to checking reservation updates. Slices can also contain interactive controls like toggles and sliders. You can get started building Slices today, and they will begin appearing for users soon.

Actions — Actions are a new way to make your app's capabilities and content more accessible, so that people can easily get to it at the right moment. App Actions will appear to users based on usage and relevance, across multiple Google and Android surfaces, such as the Google Search App, the Play Store, the Google Assistant, and the Launcher. App Actions will be available for all developers to try soon, please sign up here if you'd like to be notified. You can also choose to build a Conversational Action as a companion experience to your app. This works on a variety of Assistant-enabled devices, such as speakers and smart displays. Both types of Actions use a new common catalog of intents.

Smarter devices: a powerful platform for IoT devices

Android Things 1.0 — Android Things is Google's managed OS that enables developers to build and maintain Internet of Things devices at scale. Earlier this year at CES, we announced Lenovo, Harman, LG, and iHome are all building Assistant-enabled products powered by Android Things.

After a developer preview with over 100,000 SDK downloads and feedback from more than 10,000 developers, we announced Android Things 1.0 this week. Four new System-on-Modules (SoMs) are now supported on the platform with guaranteed long-term support for three years and additional options for extended support, making it easier to go from prototypes to production. To make product development more seamless than ever, the accompanying Android Things Console is also ready for production. It helps developers easily manage and update their devices with the latest stability fixes and security updates provided by Google.

developer siteCommunity HubGoogle's IoT Developers CommunityOEM Partner ProgramWomen TechmakersGDGsGoogle Developers Certification50 agencies90 Android Developer Expertswinners and nomineesGoogle I/O

Use Android Jetpack to Accelerate Your App Development

08 May 2018

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. What is Android Jetpack?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). 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. What's NewAndroid Jetpack comes with five new components:

WorkManager alpha release

Navigation alpha release

Paging stable release

Slices alpha release

Android KTX (Kotlin Extensions) alpha release

WorkManagerThe 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. NavigationWhile 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. PagingData 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. SlicesAnd 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. Android KTXAnd 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. Getting StartedYou 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:

What's NextWith 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.

Hello World, AndroidX

08 May 2018

Posted by Alan Viverette (/u/alanviverette), Kathy Kam (@kathykam) , Lukas Bergstrom (@lukasb) 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 Writing Android apps means depending on two kinds of classes:

Classes like PackageManager, which are bundled with the operating system and can have different APIs and behavior for different Android versions

Classes like AppCompatActivity or ViewModel, which are unbundled from the operating system and ship in your apk. These libraries are written to provide a single API surface with behavior that's as consistent as possible across Android versions.

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:

Old

New

android.support.**

androidx.@

android.databinding.**

androidx.databinding.@

android.design.**

com.google.android.material.@

android.support.test.**

(in a future release) 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:

Old

New

android.arch.**

androidx.@

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. 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!

One Biometric API Over all Android

Google Play services and Firebase migrating to AndroidX

What’s New with Android Jetpack and Jetpack Compose

Google I/O 2018: What’s new in Android

Use Android Jetpack to Accelerate Your App Development

Hello World, AndroidX

Labels

Archive

Feed

Newsletter