# androidx/androidx: the AOSP development environment behind every androidx.* library > This repository is the source tree for Android Jetpack libraries, not a library you add to an app. It explains who should clone it, how the checkout works, and why most readers should pull AARs from Google Maven instead. **androidx/androidx** — Development environment for Android Jetpack extension libraries under the androidx namespace. Synchronized with Android Jetpack's primary development branch on AOSP. - Repository: https://github.com/androidx/androidx - Website: https://android.googlesource.com/platform/frameworks/support - Stars: 6,099 · Forks: 1,384 - Language: Kotlin - License: Apache-2.0 - Published: 2026-08-08 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/androidx-androidx ## What androidx/androidx actually is, and who it is for The README describes Jetpack as a suite of libraries, tools, and guidance for writing Android apps, with the components unbundled from the platform APIs so they ship backward compatibility and update more often than the Android platform itself. This repository is where those components are developed. The top-level tree is a list of library directories: activity, appcompat, biometric, collection, compose, core, datastore, fragment, lifecycle, navigation, paging, room, work, and many more, alongside build infrastructure such as buildSrc, development, and prebuilts. That distinction decides who should read further. If you are building an app, you consume androidx artifacts as binaries; the README states that official AARs and JARs are distributed through Google Maven, and the landing page at developer.android.com/jetpack covers usage. If you are fixing a bug inside a library, adding tests, or correcting documentation, this is the tree you clone. The contribution guide narrows that further: the GitHub workflow is described as experimental, and contributions are accepted only for Activity, AppCompat, Biometric, Collection, Compose Runtime, Core, DataStore, Fragment, Lifecycle, Navigation, Paging, Room, and WorkManager. The README also states plainly that new modules are not currently being accepted. ## How the checkout is structured: repo, prebuilts, and hermetic builds This is an AOSP-style tree, not a single Gradle project you open and build in one step. The README points to docs/onboarding.md for setup and the development workflow, and mentions repo upload as the command that pushes a change for review, which tells you the tooling is repo and Gerrit rather than a plain git push to GitHub. One design choice stands out. The README states that AndroidX uses git to store all binary Gradle dependencies, kept in prebuilts/androidx/internal and prebuilts/androidx/external in the checkout. Every dependency in those directories is also available from google() or mavenCentral(); the copies exist so builds are hermetic. That is a real trade-off: the repository carries binary weight most projects would keep in a remote cache, in exchange for builds that do not depend on an external artifact server being reachable. A tool called importMaven, documented under development/importMaven/README.md, is how a new dependency is pulled in. Continuous integration builds in-progress libraries on ci.android.com, and the README notes those AARs and JARs can be downloaded manually for experimentation, which is the closest thing to a nightly channel described here. ## Setting up a checkout and making a first change The README does not inline the setup commands; it directs readers to docs/onboarding.md for getting set up and for the development workflow. What it does specify are the two account steps required before a first upload. Generate an HTTPS password through the new-password page, and accept the Google Contributor License Agreement at the review settings page. Both are prerequisites, not optional. The upload path is repo, and the review UI is r.android.com. ```bash repo upload ``` The README states that after running repo upload you open r.android.com, sign in, and add a reviewer, choosing someone from git log for the file you are touching or from the OWNERS file in that project's directory. The repository root carries several ownership files, including OWNERS, TAG_OWNERS, TEXT_OWNERS, and MOLECULE_UI_OWNERS, so the reviewer you want depends on what you changed. Before any of that, a bug fix needs a corresponding report in the Android Issue Tracker, and each fix is expected to come with tests. The accepted contribution types are bug fixes, spelling fixes, documentation updates, new tests for uncovered areas, and new features only when an AndroidX team member has approved the feature request. If you want to see the libraries in use rather than change them, the samples directory holds demo projects such as samples/AndroidXDemos and samples/MediaRoutingDemo. ## Where this repository is the wrong place to start The most common mistake is treating androidx/androidx as the way to add Jetpack to an app. It is not. There is no Gradle coordinate published from this tree that you add to a module; the README states binaries are distributed through Google Maven. Cloning this repository to get Room or Compose gives you a very large AOSP-style checkout with prebuilt dependency caches, when a single line in a module build file would have done the job. The contribution surface is the second limit. The README lists thirteen projects accepting contributions through GitHub and calls that workflow experimental. If the library you care about is not on that list, the documented path here does not cover you. New modules are explicitly not being accepted, so a new library idea has no route through this repository as described. And feature work is gated: a new feature to an existing library needs an approved feature request from an AndroidX team member before it is accepted, which means an unsolicited feature patch is likely to be rejected on process grounds regardless of code quality. ## AndroidX versus the platform APIs, and where binaries come from The comparison that matters is not against another source repository. It is against the Android platform APIs themselves. The README frames the split directly: Jetpack comprises the androidx.* package libraries unbundled from the platform, which is what allows backward compatibility and a faster update cadence than the platform. A framework API ships with the OS version on the device; an androidx library ships with your app and can be updated on your schedule. That is why the practical alternative to cloning this tree is not a competing project but the binary channel. Google Maven serves the official AARs and JARs, and the developer.android.com/jetpack landing page documents how to use them. The difference in approach is the whole point: consuming binaries gives you versioned artifacts and normal dependency resolution, while working in this tree gives you source, tests, and the ability to change library behaviour, at the cost of the repo-based tooling, the contributor agreement, and Gerrit review. If your goal is to ship an app, the binary channel is the correct one, and this repository is documentation of how those binaries are made rather than a dependency you install. ## Maintenance, licensing, and what a contribution costs The repository is not archived. No last-push date was retrieved, so nothing here should be read as a statement about how recently the tree changed; the README describes an active contribution process with an experimental GitHub workflow, a Gerrit review flow, and continuous integration that builds libraries as changes merge. Treat that as process description, not as a currency guarantee for any individual module. The licence is Apache-2.0, per the LICENSE.txt file at the repository root. That is a permissive licence, and it is the same licence family the published androidx artifacts carry, but this article does not give legal advice; if you plan to redistribute modified library code, read LICENSE.txt and the contribution agreement yourself. The ongoing cost of contributing is process, not compute. You need a Google account with an HTTPS password and a signed contributor agreement, a reviewer identified from git log or an OWNERS file, a bug report for any fix, and tests alongside the change. Code review etiquette is documented in code-review.md, which the README links. Weigh that against the size of the fix: for a one-line spelling correction in a doc file, the paperwork is the dominant cost, and the README lists spelling fixes as an accepted contribution type anyway. ## Conclusion Adopt this repository if you are fixing a bug, adding tests, or working on one of the libraries listed in the contribution guide, and expect to use repo, the prebuilt dependency caches under prebuilts/androidx, and Gerrit review rather than a normal pull request. Do not clone it to use Room, Compose, or AppCompat in an app; those come from Google Maven. Verify two things first: that your target library is on the accepted contribution list, since the README states new modules are not being accepted, and that a matching bug report exists in the Android Issue Tracker, because bug fixes are expected to come with tests and a report. ## FAQ ### What is AndroidX used for? AndroidX is the namespace for Jetpack libraries, a suite of libraries, tools, and guidance that help developers write Android apps with less boilerplate. The components are unbundled from the platform APIs, so they offer backward compatibility and update more frequently than the Android platform. ### What is the difference between Android and AndroidX? The README states that Jetpack comprises the androidx.* package libraries unbundled from the platform APIs, which is what allows backward compatibility and a faster update cadence than the platform. Platform APIs ship with the OS on the device; androidx libraries ship with your app and are distributed as AARs and JARs through Google Maven. ### how to use androidx For app development, the README points to the Android Jetpack landing page at developer.android.com/jetpack and states that official AARs and JARs are distributed through Google Maven. Working inside the androidx/androidx source tree is a separate activity, covered by docs/onboarding.md. ### how to add androidx library in android studio The README does not document adding libraries inside Android Studio. It states that official AARs and JARs are distributed through Google Maven and directs readers to the Android Jetpack landing page for usage guidance. ### what is androidx room Room is one of the libraries developed in this repository, and room/ is a top-level directory in the tree. It is also on the README's list of projects currently accepting contributions through the experimental GitHub workflow. ## Sources - [Official documentation](https://android.googlesource.com/platform/frameworks/support) - [Official README](https://github.com/androidx/androidx#readme) - [Project repository](https://github.com/androidx/androidx) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/androidx-androidx