The Jetpack map

Jetpack (glossary definition) is not a product with a feature list. It is a catalogue of libraries that share a namespace and a philosophy: solve one problem, ship it independently, and let the platform stay unchanged.

TL;DR#

• Jetpack is the set of AndroidX (glossary definition) libraries that provide recommended architecture, UI and behaviour.
• This site's dataset records 72 artifacts across 16 families and 55 Maven groups.
• The families map onto the architecture: Foundation, Architecture, UI, Compose, Navigation, Background, Media, Security, Testing, Performance, and the form-factor families (Wear, TV, Cars, Health).
• UI is the largest family by artifact count (14), but Compose is the fastest-growing one — and several other artifacts exist only to integrate with it.¹
• Version numbers are independent per artifact; a BOM pins a compatible set.²

Mental model#

Think of a hardware store, not a factory.

A factory makes one thing. A hardware store has aisles: plumbing, electrical, fasteners. You go to the aisle for the job you are doing. The store does not tell you how to build a house; it makes sure the parts fit together and that you can buy one screw without buying the whole aisle.

Where the analogy breaks#

A hardware store's parts are interchangeable. Jetpack artifacts are not: androidx.compose.material3 requires a compatible Compose runtime, and androidx.navigation:navigation-compose requires a compatible navigation core. The BOM exists precisely because the parts are not freely interchangeable, and the store's job is to tell you which combination is known to work.

The big picture#

Two things are visible in that shape. UI is the largest family ring at fourteen artifacts, with Compose close behind at eleven — and Compose is the newer of the two. And the outer ring is fragmented: even inside one family, artifacts come from several Maven groups, which is a direct consequence of independent versioning.

Deep dive#

The families, and what each is for#

The full catalogue#

Every artifact in the dataset, with its family, purpose and first stable release. Filter by family to see how the catalogue is distributed.

What the catalogue reveals#

Three patterns are visible in the table.

Compose is the growth area. Eleven of the seventy-two artifacts are Compose-specific, and several others (activity-compose, navigation-compose, lifecycle-runtime-compose) exist solely to integrate a non-Compose library with Compose. That integration layer is the clearest signal of where new development goes.

Deprecations are rare and explicit. Only two entries in the dataset are marked deprecated: legacy-support-v4 (the pre-AndroidX shim) and slice-core (a surface that never found adoption). AndroidX is careful about deprecation because the libraries are used by apps that cannot migrate quickly.

Some "Jetpack" artifacts are not Google's. com.squareup.okhttp3:okhttp and com.google.dagger:hilt-android are in the dataset because they are part of the recommended stack, even though they are not androidx.*. The boundary of "Jetpack" is fuzzy in practice; what matters is which libraries the platform's guidance assumes.

The BOM#

Because versions are independent, a compatible set needs to be declared somewhere:

dependencies {
    val composeBom = platform("androidx.compose:compose-bom:$composeBom")
    implementation(composeBom)
    androidTestImplementation(composeBom)
 
    implementation("androidx.compose.ui:ui")
    implementation("androidx.compose.foundation:foundation")
    implementation("androidx.compose.material3:material3")
    implementation("androidx.compose.ui:ui-tooling-preview")
    debugImplementation("androidx.compose.ui:ui-tooling")
}

The BOM is a pom with dependency management. It contributes no code and no classes; it only pins versions. That is why implementation(platform(...)) looks odd and is correct.

Choosing what to add#

A pragmatic rule set:

1. Start with what the architecture needs: lifecycle, viewmodel, core-ktx, appcompat (or Compose), activity.
2. Add data libraries when the data layer exists: room, datastore, paging.
3. Add Compose when you are ready to commit to its toolchain and compiler plugin version.
4. Add work when you have work that must survive the process.
5. Add hilt when manual wiring becomes painful — usually around ten ViewModels.
6. Do not add a library for one screen. A single-screen need is usually a function.

How it evolved#

The catalogue's growth tracks the eras: a handful of foundation libraries in 2018, architecture and navigation in 2018–2019, Compose from 2021, and form-factor and AI-adjacent libraries from 2023.

Under the hood#

• ‹›Application.java↗where a library initialiser usually hooks in
• ‹›Intent.java↗the platform surface most libraries wrap
• ‹›View.java↗the base class appcompat and material extend

Curiosity corner#

• The biggest family is not the newest. UI has fourteen artifacts to Compose's eleven, because fifteen years of View-era widgets accumulate.
• core-ktx is mostly extension functions. It adds almost no new classes — it makes existing platform APIs pleasant to call from Kotlin.
• A BOM pins versions but does not enforce compatibility. Two artifacts from the same BOM can still conflict if a transitive dependency demands a newer version.

Try it#

$ 
./gradlew :app:dependencies --configuration debugRuntimeClasspath | grep androidx | sort -u | head -40

$ 
./gradlew :app:dependencyInsight --dependency androidx.compose.ui:ui --configuration debugRuntimeClasspath

Check yourself#

Sources#