androidx/androidx: der Entwicklungsbaum hinter den Jetpack-Bibliotheken
Entwicklungsumgebung für Android Jetpack-Erweiterungsbibliotheken unter dem Androidx-Namespace. Synchronisiert mit dem primären Entwicklungszweig von Android Jetpack auf AOSP.
Auf einen Blick
- Was ist das?
- androidx/androidx ist die Entwicklungsumgebung für die Jetpack-Bibliotheken unter dem androidx-Namespace und spiegelt den AOSP-Zweig androidx-main. Wer hier mitarbeiten will, arbeitet über ein experimentelles GitHub-Fenster mit 13 freigegebenen Projekten.
- Für wen ist es gedacht?
- Das Repository taugt für Entwickler, die einen Fehler in Activity, Room, WorkManager oder einem der anderen zehn freigegebenen Projekte belegen und samt Test beheben wollen, sowie für alle, die den Quellstand von androidx-main lesen möchten. Wer neue Module vorschlagen oder ausserhalb dieser Liste beitragen will, wird hier nicht angenommen und muss den AOSP-Weg über android.googlesource.com gehen.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 1 Tag.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Kotlin, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 14. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
androidx-main als Arbeitszweig statt als Release-Quelle
androidx/androidx ist laut Repository-Beschreibung die Entwicklungsumgebung für die Jetpack-Erweiterungsbibliotheken unter dem androidx-Namespace, abgeglichen mit dem primären Entwicklungszweig von Android Jetpack in AOSP. Der Standardzweig heisst androidx-main; die Homepage verweist auf android.googlesource.com/platform/frameworks/support.
Das README stellt Jetpack als Sammlung von Bibliotheken, Werkzeugen und Empfehlungen vor, die dabei helfen sollen, empfohlene Vorgehensweisen einzuhalten und Standardcode zu vermeiden. Der Kern der Aussage ist technisch: Jetpack besteht aus den androidx.*-Paketen, die von den Plattform-APIs entkoppelt sind. Daraus folgt Abwärtskompatibilität und ein Takt, der häufiger ist als der der Android-Plattform.
Was das Repository nicht bietet, gehört genauso zur Einordnung: Es veröffentlicht keine Releases, das README nennt keine Versionsnummern, keine Abhängigkeitslisten und keine API-Level-Vorgaben. Wer eine Bibliothek einsetzen will, liest nicht dieses Repository, sondern die Artefaktliste.
Vertrieb der AAR- und JAR-Dateien über Google Maven
Die offiziellen Binärdateien liegen laut README auf Google Maven unter maven.google.com, verteilt als AAR und JAR. Für die Nutzung verweist das README auf die Jetpack-Seite bei developer.android.com. Dieser Umweg erklärt, warum im Repository selbst keine Versionsangaben stehen: Die Version entsteht beim Veröffentlichen des Artefakts, nicht im Quellbaum.
Wer dennoch ein Artefakt aus dem Quellstand braucht, findet einen zweiten Kanal. Das verlinkte CI-System baut unter ci.android.com alle laufenden Arbeiten, sobald Änderungen zusammengeführt werden; die README-Formulierung nennt die Bibliotheken dabei ausdrücklich potenziell instabil. Die AARs und JARs von dort lassen sich manuell herunterladen.
Der praktische Unterschied ist klar: Google Maven liefert geprüfte Veröffentlichungen, das CI-Grid liefert den aktuellen Stand von androidx-main. Für Produktionsbuilds ist nur ersteres vorgesehen, für das Prüfen eines frischen Fehlerfixes kann letzteres Wochen sparen.
Das GitHub-Fenster: 13 Projekte, feste Beitragsarten, keine neuen Module
Beiträge über GitHub sind laut README experimentell und auf eine Liste von Projekten beschränkt: Activity, AppCompat, Biometric, Collection, Compose Runtime, Core, DataStore, Fragment, Lifecycle, Navigation, Paging, Room und WorkManager. Was ausserhalb dieser Liste liegt, wird über GitHub nicht angenommen.
Angenommen werden Fehlerbehebungen, wenn dazu ein Bericht im Android Issue Tracker vorliegt, und jede Fehlerbehebung soll Tests mitbringen. Dazu kommen Korrekturen von Schreibfehlern, Aktualisierungen der Dokumentation, zusätzliche Tests für bislang ungedeckte Bereiche sowie neue Funktionen für bestehende Bibliotheken, sofern ein AndroidX-Teammitglied den zugehörigen Wunsch genehmigt hat.
Der Satz, der viele Erwartungen beendet, steht im selben Abschnitt: Neue Module werden derzeit nicht angenommen. Das README nennt weder ein Enddatum für den experimentellen Status noch die Gründe für die Auswahl der dreizehn Projekte.
Vom Checkout zum Review: docs/onboarding.md, HTTPS-Passwort, Google CLA
Der Einstieg für den Checkout führt über docs/onboarding.md; diesen Pfad nennt das README als einzigen Ort für Einrichtung und Arbeitsablauf. Build-Befehle, benötigte Werkzeugversionen oder IDE-Vorgaben stehen im README nicht.
Vor dem ersten Upload sind zwei Schritte Pflicht. Über https://android.googlesource.com/new-password wird ein HTTPS-Passwort erzeugt, und unter android-review.googlesource.com/settings/new-agreement wird der Google Contributor Licenses Agreement zugestimmt. Erst danach lässt sich ein Änderungssatz hochladen.
Das Review findet auf r.android.com statt. Das README empfiehlt, einen passenden Prüfer über git log auf der betroffenen Datei oder über die OWNERS-Datei im Projektverzeichnis zu finden. Für die Beitragsarten verweist das Repository auf CONTRIBUTING.md, für den Umgangston in Reviews auf code-review.md. Fristen für Reviews nennt das README nicht.
Hermetische Builds: prebuilts/androidx/internal und das importMaven-Werkzeug
AndroidX legt binäre Gradle-Abhängigkeiten im git selbst ab, unter prebuilts/androidx/internal und prebuilts/androidx/external. Das README begründet das mit hermetischen Builds: Der Baum soll ohne Netzabruf baubar bleiben. Dieselben Artefakte sind laut README auch über google() und mavenCentral() verfügbar.
Für eine neue Abhängigkeit gibt es ein eigenes Werkzeug. Der Weg führt über development/importMaven/README.md, dessen Aufgabe das Einspielen einer Maven-Abhängigkeit in die beiden prebuilts-Verzeichnisse ist. Wer stattdessen eine Koordinate direkt in eine Gradle-Datei schreibt, bricht die Hermetik und wird beim Review darauf angesprochen.
Diese Struktur hat eine Nebenwirkung, die man beim Klonen unterschätzt: Der Checkout ist gross, weil er Bibliotheken enthält, die anderswo nur heruntergeladen würden. Das README macht dazu keine Grössenangabe.
Apache-2.0: was die Lizenz für eigene Apps bedeutet
Die Metadaten des Repositorys führen die Lizenz als Apache-2.0. Für Anwendungen heisst das: Die veröffentlichten Artefakte dürfen in proprietäre Produkte eingebunden werden, solange Lizenz- und Urhebervermerke mitgeführt und Änderungen kenntlich gemacht werden; die Apache-Lizenz enthält zudem eine Patentregelung zugunsten der Nutzer. Das ist keine Rechtsberatung, sondern die übliche Lesart, die sich an den Lizenztext hält.
Zu beachten ist die Trennung zwischen Quellbaum und Artefakt. Wer androidx-Code in ein eigenes Produkt kopiert, statt das Artefakt einzubinden, muss die Vermerke des jeweiligen Moduls mitnehmen. Für reine Leser und für Beitragende gilt die Google Contributor Licenses Agreement aus dem vorigen Abschnitt.
Offen bleibt an dieser Stelle, wie das Projekt Sicherheitsmeldungen handhabt und welche Supportzusagen für einzelne Bibliotheken gelten: Beides behandelt das README nicht.
Der AOSP-Weg als Alternative zum GitHub-Spiegel
Die Alternative zum Weg über GitHub ist der direkte Weg über AOSP. Die Homepage des Repositorys zeigt auf android.googlesource.com/platform/frameworks/support, und der Review läuft ohnehin über r.android.com, also über Gerrit und nicht über Pull Requests. Der GitHub-Ablauf ist damit ein zusätzlicher Eingang, der denselben Prüfprozess speist.
Der Unterschied liegt im Umfang. Über GitHub sind dreizehn Projekte freigegeben und neue Module ausgeschlossen; über den AOSP-Zweig ist der Baum in Gänze erreichbar, auch die Bereiche, die hier nicht aufgeführt sind. Wer ausserhalb der Liste beitragen will, richtet seinen Arbeitsablauf deshalb von Anfang an auf Gerrit ein, inklusive repo upload und Reviewerfindung über OWNERS.
Für die tägliche Arbeit an einer App ist beides ohne Belang: Dort zählt nur das Artefakt von maven.google.com, und dieses Repository ist die Quelle, nicht der Lieferweg.
Redaktionelles Fazit
Das Repository taugt für Entwickler, die einen Fehler in Activity, Room, WorkManager oder einem der anderen zehn freigegebenen Projekte belegen und samt Test beheben wollen, sowie für alle, die den Quellstand von androidx-main lesen möchten. Wer neue Module vorschlagen oder ausserhalb dieser Liste beitragen will, wird hier nicht angenommen und muss den AOSP-Weg über android.googlesource.com gehen. Vor dem ersten Upload klärt man die beiden Voraussetzungen: HTTPS-Passwort unter android.googlesource.com/new-password und die Google Contributor Licenses Agreement unter android-review.googlesource.com/settings/new-agreement.
Community-Notizen