AboutLibraries builds your dependency list before the app runs

Dependency data is collected during the build, never at runtime

Everything AboutLibraries reports about your app is decided before the app ever starts. Collection runs inside Gradle, the output is written into the build, and the UI layer only reads what was already produced, so the screen that lists your dependencies carries no scanning work of its own and the result stays cached between builds. One Kotlin Multiplatform project covers Android, JVM desktop, iOS, native, JS and Wasm, which is what lets the same plugin and the same generated data serve a phone app, a desktop binary and a browser bundle from a single Gradle graph. Nobody edits a hand-written list of libraries, and nothing has to be refreshed at app start, because the build already collected the metadata and cached it.

One core module, three Compose skins, one shared data shape

The repository top level lists `aboutlibraries-core` next to `aboutlibraries-compose-m2`, `aboutlibraries-compose-m3` and `aboutlibraries-compose-wear-m3`, and those four names are the architecture. Data access sits in the core, presentation sits in whichever skin fits the generation you already ship, whether Material 2, Material 3 or Wear. The project page frames that as two separate promises: a choice between Material 2, Material 3 and Wear for the ready-made screen, and a core described as the way to reach the generated data programmatically. Take one UI module and the row layout, the density options and the interaction modes arrive with it. Ignore all three and you can assemble your own rows on top of the core data. The cost sits on the build side rather than on the code side, since the module you pick fixes the Compose and Material versions your app compiles against.

Two plugin ids cover one job after the configuration cache split

Applying the plugin takes two lines, and the only value you must supply is the version placeholder:

// Root build.gradle.kts
id("com.mikepenz.aboutlibraries.plugin") version "${latestAboutLibsRelease}" apply false

// App build.gradle.kts
id("com.mikepenz.aboutlibraries.plugin")

The artifact comes from the Gradle Plugin Portal, and the `plugins` DSL is the recommended route. Two ids exist because the automatic Android wiring was moved out of the main plugin in v13.x.y, and the stated reason is configuration cache compatibility together with fewer unintended behaviors in the build. The main plugin gives you tasks you invoke yourself and does not generate metadata on its own. The Android plugin hooks generation into the Android build, and the guidance is explicit that most projects should stay on the main one and take the Android plugin only when the definitions have to be produced as part of that build.

Quickstart names one plugin id while its snippet applies the other

Step 1 is where the writing falls apart. Its prose tells you to use `com.mikepenz.aboutlibraries.plugin.android` to hook into the Android build automatically, and the snippet printed right under that sentence applies `com.mikepenz.aboutlibraries.plugin`, the manual variant. Step 2 picks a UI module with a placeholder version, and step 3 binds the generated data to a resource:

implementation("com.mikepenz:aboutlibraries-compose-m3:${latestAboutLibsRelease}")

val libraries by produceLibraries(R.raw.aboutlibraries)
LibrariesContainer(libraries, Modifier.fillMaxSize())

Read the code rather than the sentence and you have the plugin most projects want, but you keep an Android-shaped handle. The call loads through `R.raw.aboutlibraries`, a resource id from the Android resource class, and the quickstart then sends full setup and multiplatform loading off to the reference section. So a desktop, iOS or web build inherits the first two steps and has to find the loading path elsewhere, because nothing in that block covers a target without an Android resource table.

Three Compose lines, three library versions, two carrying the new UI

The compatibility table pairs three Compose lines with three library versions, and the rows differ in more than the numbers. Compose 1.12.x carries the new UI marker next to AGP 9, Kotlin 2.4 and compile 37 on 15.3.0. Compose 1.11.x repeats both the same new UI marker and the same toolchain row on 15.1.1. Compose 1.10.x is marked only with AGP 9 and sits on 14.1.0. Two details survive a skim only if you line the rows up against each other. The new UI marker belongs to the two newest Compose lines and not to 1.10.x, so that redesign is pinned to the Compose line instead of being floated across every supported version. And the project's own release dates for 15.1.1, 15.2.0 and 15.3.0 are 2026-08-21, 2026-08-28 and 2026-10-13, which tells you how fast the line moves without telling you what moved in it.

One container, four knobs, and pictures that change a single axis

A single Compose component covers the demo page because it takes four named arguments: `variant`, `density`, `detailMode` and `actionMode`. `LibrariesVariant.Refined` and `LibrariesVariant.Traditional` change the list structure, `LibrariesDensity.Compact` and `LibrariesDensity.Cozy` change how much room a row occupies, and `LibraryActionMode.Chips` and `LibraryActionMode.Icons` change how the row actions render. Tapping an entry opens its detail through `LibraryDetailMode`, either inline, in a dialog, or in a bottom sheet. Every picture comes from Paparazzi renders of `ReadmeShowcasePreviews.kt`, which passes the same arguments and theme as the sample app and varies only the one knob named above the image. That keeps the screenshots readable, and it also means each axis is only ever shown alone. Traditional layout plus Cozy density plus chip actions is unproven by any picture on the page, so check the sample app before assuming a combination looks finished.

Exports, strict mode and funding all read the same generated file

The compliance side of the feature is derived from that same build output. The project lists CSV and text exports, compliance reports, a license strict mode, and funding detection that surfaces the funding options of the projects you depend on. A Gradle tasks section in the reference covers exports, compliance reports and funding, so these run as tasks in Gradle rather than as checks on a device. What the setup text does not hand you is the task names themselves or the configuration key behind strict mode, so a build that has to fail on the wrong notice needs that key looked up in the reference or the plugin source before the first pipeline run. If your compliance process expects a particular schema, verify the column layout against your own tooling, because the output formats are named here without their fields.

The sample tree carries the cost of the platform list

Every target the feature claims has a checked-in example that has to keep compiling, and the sample tree makes the size of that promise visible. `sample/` carries five platform directories, android, desktop, ios, shared and web, alongside its own `README.md`, `gradle.properties` and `build.gradle.kts`. Alongside it sit `app/`, `app-test/`, `plugin-build/`, `config/` and `kotlin-js-store/`, plus top level files such as `stability_config.conf` and `renovate.json` that the project page names without explaining what they configure. Breaking changes get a document too: `MIGRATION.md` exists because the v13.x.y split changed plugin ids under existing users, and `SECURITY.md` and `DEV/` sit next to it. The gap for a newcomer is the setup text itself, which defers plugin configuration and multiplatform loading to a reference section further down the page.

Editorial conclusion

AboutLibraries fits apps that publish an open-source inventory to users and want that screen to look native. Teams on Compose 1.12.x with AGP 9 and Kotlin 2.4 have the least friction; anyone on 1.10.x inherits the older 14.1.0 line without the new UI marker. Before adopting it, confirm three things: whether your build can invoke the plugin tasks without the Android plugin, what your compliance tooling expects from the CSV exports, and how strict mode fails a build. None of that is settled by the sample images.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. mikepenz/AboutLibraries on GitHub
3. Project website
4. README
5. Releases