Android Jetpack: What do the recent announcements mean for Android’s Support Library?

The official Android docs describe Android Jetpack as “a set of libraries, tools and architectural guidance.” This vague description has left many developers wondering what Android Jetpack really is. Taking a look at the list of Android Jetpack components just raises even more questions — there’s clearly a ton of crossover with existing Android libraries and projects.

A good chunk of the components seem to be taken straight from the Support Library, such as AppCompat. So, is Android Jetpack just a rebranded Support Library? Is it a replacement? Can you use the two side by side, or should we all be migrating our apps to Jetpack?

The Support Library components aren’t the only familiar features in the list of Jetpack components. All of the Architecture Components (Lifecycles, LiveData, Room and ViewModel) are now part of Jetpack, too.

To add to the confusion, at Google I/O 2018 we learned future Support Library updates will be published to the android.support namespace and to a new androidx namespace, as part of AndroidX. This brings us to a grand total of three projects that seem to have some overlap with Jetpack — and we’re still no closer to figuring out what Jetpack actually is!

If Google I/O 2018 has left you with more questions than answers, then in this article we’ll be taking a closer look at the Support Library, Architecture Components and AndroidX projects, and demystifying how all of these puzzle pieces fit with Android Jetpack.

What is Android Jetpack?

Android Jetpack provides a series of unbundled libraries not tied to any particular version of Android, giving developers a way to support newer features on older versions of the Android operating system. In addition to backward compatibility, Jetpack promises to help you get more done, with less code, by providing the boilerplate to handle repetitive tasks like managing the application lifecycle.

Android Jetpack components are divided into these categories:

• Foundation- This covers core system capabilities, such as AppCompat.
• UI- This is the category for UI-focused components, including Fragment and Layout, but also for components that aren’t restricted to smartphones, such as Auto, TV, and Wear OS by Google (formerly Android Wear).
• Architecture- This is where you’ll find modules to help you handle the challenges surrounding data persistence and the application lifecycle.
• Behavior- This category contains modules such as Permissions, Notifications, and Sharing.

Android Jetpack also introduces five brand-new components:

WorkManager

WorkManager is a job dispatching service that lets you schedule tasks, specify some optional constraints, and then leave WorkManager to handle the rest. When you use WorkManager to schedule a task, it’s guaranteed to run as soon as the conditions are met. If you schedule a battery-intensive task to run when the device is charging, then this task will execute as soon as the device is connected to a power outlet, even if the user has exited your application or rebooted their device in the meantime.

By default, WorkManager executes the task immediately in a new background thread, but if your application isn’t running it’ll choose the most appropriate way to schedule the task, based on factors such as API level and whether the device has access to Google Play services. Depending on these factors, WorkManager may schedule the task using JobScheduler, Firebase JobDispatcher, or a custom AlarmManager and BroadcastReceiver implementation.

Navigation

If you’re going to provide a good user experience, then your app’s navigation needs to feel intuitive and effortless. By using the Navigation component in combination with Android Studio 3.2’s new navigation editor, you can design, edit, and generally fine-tune your application’s navigation.

The Navigation component also makes it easier to implement a navigational structure that’s based on fragments, by automatically handling much of the complexity surrounding FragmentTransactions.

Paging

Trying to download and present a large amount of data all at once never leads to a good user experience!

The Paging components helps you avoid the lag typically associated with loading large data sets, by breaking data down into chunks, known as “pages.” By focusing on displaying a subset of data as quickly as possible, Paging reduces the amount of time the user is left waiting for something to appear onscreen. Plus, since you’re only loading the portion of data that’s currently visible, Paging uses system resources such as battery and data allowance in a much more economical way.

Paging can load content from local storage or over the network, and works out-of-the-box with Room, LiveData, and RxJava.

Slices

Slices are designed to drive user engagement, displaying a snippet of your application’s content in places where many Android users spend a significant amount of time, like in Google search results and Google Assistant.

Slices can display a range of static and interactive content, including images, video, deep links, toggles, and sliders, and they can be dynamic, updating to reflect events that are happening inside the related application.

Android KTX

This is a collection of modules consisting of extensions that optimize the Android platform APIs for Kotlin. Using these extensions, you can make your Kotlin code more concise and readable, for example by using the androidx.core:core-ktx module, you can turn:

Into:

Note that Android KTX doesn’t actually add any new features to the existing Android APIs.

Is Android Jetpack replacing the Support Library?

The Support Library was designed to help developers support recent platform features on devices running earlier versions of Android, by providing backwards compatible implementations of important classes and methods.

The Support Library doesn’t guarantee backwards compatibility across all devices, but if it can’t provide a complete set of functionality for a particular device, it’s designed to gracefully fall back on equivalent functionality. Occasionally, you may encounter a framework call that you still need to wrap in an explicit SDK version check.

If this sounds a lot like Android Jetpack, there’s a reason for that. Android Jetpack takes the existing Support Libraries and wraps them in a new set of components. However, Android Jetpack isn’t designed to replace the existing Support Library, as Google currently plans to release updates to both the Support Library and Android Jetpack.

While Jetpack components are designed to play nicely together, they can operate independently. This means it’s not necessarily a question of “Jetpack or the Support Library?” There’s no reason not to use Jetpack components and the Support Library side-by-side, which is exactly what we’re doing in this snippet from our Scheduling background tasks with WorkManager article:

Here, we’re using Jetpack’s WorkManager component alongside several components from the Support Library.

Where do the Architecture Components fit in?

If you’ve read through the list of Jetpack components, then you’ll have noticed that it also includes all of the Architecture Components:

• Lifecycles. This is a library for managing application lifecycles and avoiding memory leaks, by creating lifecycle-aware components that respond to changes in the lifecycle status of other components.
• ViewModel. UI-related data is often lost in configuration changes like screen rotations. Since ViewModel objects are retained across configuration changes, you can use this class to ensure your data remains available, even after an Activity or Fragment has been destroyed and then recreated.
• LiveData. A lifecycle-aware data holder class that helps you avoid memory leaks, by only updating application components when they’re in an active STARTED or RESUMED state.
• Room. This SQLite object mapping library aims to take the pain out of database management by creating a local cache of your application’s data that remains accessible, even when there isn’t an active internet connection.

These components are now only available as part of Android Jetpack, but since the dependencies remain the same, this is more of a rebranding than something you need to act on.

At this point we know Jetpack combines Support Library components like AppCompat with the Architecture Components announced at Google I/O 2017. You can keep using the modules in the Support Library, switch to their Jetpack equivalent, or use a combination of the two, although the Architecture Components are now considered part of Jetpack.

This leaves us with Google I/O 2018’s final Support Library-related announcement: AndroidX.

Do I need to switch to the androidx.* namespace?

Today, many consider the Support Library an essential part of Android app development, to the point where it’s used by 99 percent of apps in the Google Play store. However ,as the Support Library has grown, inconsistencies have crept in surrounding the library’s naming convention.

Initially, the name of each package indicated the minimum API level supported by that package, for example support-v4. However, version 26.0.0 of the Support Library increased the minimum API to 14, so today many of the package names have nothing to do with the minimum supported API level. When support-v4 and the support-v7 packages both have a minimum API of 14, it’s easy to see why people get confused!

Even the official Android docs admit this is a problem:

“When working with any recent release of the support library, you should not assume that the the v# package notation indicates a minimum API support level.”

To clear up this confusion, Google is currently refactoring the Support Library into a new Android extension library (AndroidX) package structure. AndroidX will feature simplified package names, as well as Maven groupIds and artifactIds that better reflect each package’s content, and its supported API levels.

With the current naming convention, it also isn’t clear which packages are bundled with the Android operating system, and which are packaged with your application’s APK (Android Package Kit). To clear up this confusion, all the unbundled libraries will be moved to AndroidX’s androidx.* namespace, while the android.* package hierarchy will be reserved for packages that ship with the Android operating system.

The AndroidX refactoring map contains the specific mappings between the old and new classes, and the old and new build artifacts, but as a general rule you can expect to encounter these mapping patterns:

android.support.**  >  androidx.@

android.databinding.**  >  androidx.databinding.@

android.design.**  >  com.google.android.material.@

android.support.test.**  >  androidx.test.@

Another important change is that the AndroidX artifacts will update independently, so you’ll be able to update individual AndroidX libraries in your project, rather than having to change every dependency at once. Those frustrating “All com.android.support libraries must use the exact same version specification” messages should become a thing of the past!

According to the Google blog, we can expect to see parallel updates to the android.support-packaged libraries throughout the duration of the Android P Preview timeframe, but the stable release of 28.0.0 will be the final feature release packaged as android.support.

Regardless of whether you move to Android Jetpack, stick with the Support Library, or use a mixture of the two, eventually you’ll have to switch to the new androidx.* namespace.

There are two ways to make the shift to AndroidX:

Create a project that supports AndroidX out of the box

This requires adding the following to your project’s gradle.properties file:

Refactor an existing project

Android Studio 3.2 has a refactoring feature that can update your code, resources, and Gradle configuration to reference the AndroidX artifacts and classes. To refactor your project, select Refactor > Refactor to AndroidX… from the Android Studio toolbar.

Wrapping up

Now we’ve explored all the Google I/O announcements, and how existing components overlap with Android Jetpack, we’re finally ready to answer our original question(s)!

Android Jetpack takes the existing Support Library components, combines them with last year’s Architecture Components, and adds a few new components. There are no plans to abandon the Support Library just yet, so if a component is available via the Support Library and Android Jetpack, you can still choose which implementation to use. However, version 28.0.0 will be the last release of android.support. After that you’ll have to move to the androidx.* namespace.

Are there any other Google I/O announcements that left you with more questions than answers? Let us know in the comments below!