28. Android Fragmentation & Support Libraries

Written by Darryl Bayliss

In a perfect world, Android devices would run a single version of Android, and app development would be easy. As it turns out, the world isn’t perfect.

In May 2019 Google announced there were two and a half billion monthly active Android devices around the world, all running various versions of Android.

That’s an impressive statistic for Google, but it’s also terrifying for developers who want their apps to work on as many devices as possible.

This chapter, however, is aimed at helping to put you at ease. Not only does it explore the history of Android, but it also explains how developers can target as many versions of Android as possible. Within its pages, you’ll learn:

• What problems Android faces from fragmentation and why they exist.
• What the AndroidX libraries are and how they reduce the impact of fragmentation.
• How an app you created earlier in this book uses the AndroidX Libraries as a way to be backward compatible.

Android: An open operating system

To understand where the fragmentation problem originates, it’s important to understand how Android came to be the most popular operating system on the planet.

Google acquired Android by buying a company named Android Inc in 2005. Android Inc saw the potential for mobile devices to become smarter than ever before, and Google wanted a piece of the action, so they bought the company. Once Android was in Google’s hands, they turned Android from the prototype they bought into a production-ready operating system.

Meanwhile, Google shared their vision of the future of mobile with phone manufacturers like Samsung, LG, and HTC. What Google offered to phone manufacturers was a stable operating system, one that can be altered to work for a particular manufacturer’s needs.

For Google, it was a way to reach users like never before. For phone manufacturers, it was a way of keeping up with the competition. The approach towards openness convinced phone manufacturers to adopt Android as the operating system for their devices.

When Google publicly announced Android in November 2007, it also announced the creation of the Open Handset Alliance (http://www.openhandsetalliance.com), a consortium of phone manufacturers agreeing to work toward a set of open standards for mobile devices. Those standards materialized in the form of Android.

To ensure these standards were openly available, the Android Open Source Project (https://source.android.com) was created, which allows anyone to download and contribute to the Android Operating System.

How Android Fragmented

As years went by, devices needed updates for their Android OS. However, many devices didn’t receive updates for months at a time. Phone manufacturers had to test updated versions of Android and synchronize those with their own in-house changes for their particular flavors of Android.

Differences between stock Android and the versions that the phone manufacturers included in their operating system varied. Some changes were minor UI tweaks, others were dramatic changes to underlying components of Android that only worked with particular devices.

If you look at the leading Android devices today, you’ll notice differences in the user interface. If you could dive deeper into the internals of the devices, you’ll find manufacturer-specific apps and features that you can’t remove on your own.

Dive deeper still, and it’s possible you’ll find deeply embedded processes that are unique to a particular phone manufacturer and not part of the core Android operating system.

The delay in Android updates, magnified across multiple manufacturers and devices, led to tech journalists declaring that Android has a fragmentation problem.

Google has made efforts to combat the delay in Android updates getting to devices. Their stock apps are downloadable only from the Google Play store, available only to devices whose manufacturers pay Google a licensing fee for their Google Mobile Services suite.

Google has gone so far as to rearchitect the Android OS via a project named Project Treble (https://source.android.com/devices/architecture/treble), aiming to abstract the core of Android and provide interfaces for manufacturers to use in their own Android implementations.

The idea is a stable Android core allows manufacturers to customize Android in a quicker, cheaper, and safer way. Allowing users to receive Android updates quicker.

The Pixel line of devices from Google run unmodified versions of Android, often called the “vanilla” version. This means these devices can be updated with the latest version of the operating system without the need to test device-specific modifications.

These are all changes aimed at reducing the time it takes for an Android update to be received by a device. That’s great for users, but fragmentation is still a reality and one you must deal with as a developer.

The AndroidX Libraries

To ensure developers are not held back by delayed Android updates, the engineering teams at Google introduced the Android Compatibility Library in 2011. This library aimed to ensure Android was easy to develop for across multiple versions of the operating system.

Since then, the library grew to encompass a range of libraries that provide backward compatibility for many Android features and UI components and was renamed the Android Support Library.

In 2018, the libraries were rebuilt from the ground up and renamed the AndroidX Libraries.

Backward compatibility across Android versions is so important that Android Studio, by default, uses the AndroidX Libraries in the code it generates. In fact, you’ve been using the AndroidX all this time as you’ve worked through this book.

Look through the ListMaker app you created in Section II, and you’ll see that the AndroidX Libraries are used throughout the app. You can see the first sign in build.gradle for the app module.

Open build.gradle (Module: app) and scroll down to the dependencies block:

dependencies {

    implementation "org.jetbrains.kotlin:kotlin-stdlib:$kotlin_version"
    implementation 'androidx.core:core-ktx:1.3.2'
    implementation 'androidx.appcompat:appcompat:1.2.0'
    implementation 'com.google.android.material:material:1.2.1'
    implementation 'androidx.constraintlayout:constraintlayout:2.0.4'
    implementation 'androidx.lifecycle:lifecycle-livedata-ktx:2.2.0'
    implementation 'androidx.lifecycle:lifecycle-viewmodel-ktx:2.2.0'
    testImplementation 'junit:junit:4.+'
    androidTestImplementation 'androidx.test.ext:junit:1.1.2'
    androidTestImplementation 'androidx.test.espresso:espresso-core:3.3.0'
    implementation 'androidx.preference:preference-ktx:1.1.1'
    implementation "androidx.cardview:cardview:1.0.0"
}

The dependencies prefixed with androidx. are all part of the AndroidX Libraries, created explicitly for backward compatibility of newer features to older versions of Android.

It’s thanks to the AndroidX Libraries that Constraint Layouts are compatible back to Android Gingerbread. Gingerbread was released in December 2010, yet Constraint Layouts were introduced in February 2017. That’s an incredible amount of support for old software.

It may be obvious that Constraint Layouts are used to build up the Layout for the UI in your app. However, other uses of the other AndroidX Libraries may not be so apparent.

Open the ListMaker project and then open MainActivity.kt. Holding the Command button, if you’re using macOS, hover the mouse cursor over the AppCompatActivity subclass at the top and left-click it:

Note: For Windows / Linux users, hold Ctrl and left-click.

Android Studio jumps to AppCompatActivity.java. AppCompatActivity is part of the ‘androidx.appcompat:appcompat:1.2.0’ library. You can tell by the package name at the top of the file:

package androidx.appcompat.app;

AppCompatActivity.java is a handy class. If a device runs an earlier version of Android that doesn’t know what a ToolBar is, the AndroidX Library provides the device with the class.

This ensures the app functions as intended, and developers can rely on using consistent APIs that support earlier versions of Android.

It’s time to take a look at a few other examples.

Open MainFragment.kt, hold the Command button, hover the mouse cursor over the Fragment() subclass at the top and left-click it.

Android Studio opens Fragment.java, the class definition for the Fragment. Scroll to the top of the class and take note of the package:

package androidx.fragment.app;

That’s right, even Fragments exist in the AndroidX Library! Although Fragments allow your UI to provide flexibility depending on the screen of a device, they were introduced in Android’s Honeycomb release. However, thanks to the AndroidX Library implementation, Fragments can be used back to Android Donut, which was released two years before Fragments were introduced.

Open the main_fragment.xml layout and Command-left-click over the RecyclerView defined within.

Android Studio shows you RecyclerView.java, the class definition for a RecyclerView. Scroll to the top of the class and inspect the package name:

package androidx.recyclerview.widget;

This is another AndroidX class you’ve been using.

RecyclerView was first introduced to Android in 2014 with Android Lollipop. However, instead of bundling RecyclerView into the Lollipop update, Google Engineers decided to put it into the Support Library as they recognized how integral the libraries had become.

This decision meant RecyclerViews were not released in a particular version of Android. As part of the Support Libraries, they became a crucial element of the UI that are backward-compatible to Android Eclair, which was released in 2009.

Reducing the impact of fragmentation in your app

Although fragmentation is a real problem for Android, the engineering teams at Google provide a way for developers to avoid its effects, ensuring apps can reach as many users and devices as possible.

While not every feature can be backported, the most important ones that provide consistency for the user experience are there for you to use.

That said, use the AndroidX Libraries whenever possible. Even if you don’t think you need them, assume that your first user will use your app on the oldest version of Android possible. Optimizing for the worst experience means you’re giving your users the best experience you can — on whatever device they’re using.

Key Points

Android Fragmentation was a concern for a long time. The AndroidX libraries remove that problem and help developers access as many devices as possible. In this chapter, you learned:

• How Android was acquired by Google and where the Fragmentation problem came from.

• How Google began to fix the problem via the support libraries, then the AndroidX libraries.

• How the apps you’ve built by following along with this book use the AndroidX libraries.

Where to go from here?

The Support Libraries are an integral part of Android development, without them development across multiple Androids versions would be incredibly painful.

• For more information on how to use the AndroidX Libraries, visit the AndroidX page on the developer website at https://developer.android.com/jetpack/androidx/.

• Finally, you can find a list of the AndroidX Libraries you can include in your apps at https://developer.android.com/jetpack/androidx/versions.