Codenamen, Tags und Build-Nummern

Android-Entwicklerversionen sind in Familien mit alphabetischen Codenamen organisiert.

Quellcode-Tags und Builds

Die genaue Liste der Tags und Builds ab Donut finden Sie in der folgenden Tabelle. Die Build-ID enthält Informationen wie die Plattformversion, den Code-Branch und das Datum, an dem die Version vom Entwicklungs-Branch abgeleitet oder mit ihm synchronisiert wurde.

ID-Definitionen erstellen

In Android 8.0.0 (Oreo) und höher werden Builds mit dem Build-ID-Format PVBB.YYMMDD.bbb[.Cn] identifiziert. Dabei gilt Folgendes:

• P steht für den ersten Buchstaben des Codenamens der Plattformversion, z. B. O für Oreo. Für Codenamen ab Android 10 wird der entsprechende Buchstabe verwendet, z. B. Q für Android 10 und R für Android 11.
• V steht für eine unterstützte Branche. P steht für den primären Plattformzweig.
• BB ist ein alphanumerischer Code, mit dem Google den genauen Codezweig identifizieren kann, aus dem der Build erstellt wurde.
• YYMMDD gibt das Datum an, an dem die Version vom Entwicklungszweig abgeleitet oder mit ihm synchronisiert wurde. Es ist nicht immer das genaue Datum, an dem ein Build erstellt wurde, da es üblich ist, dass bei geringfügigen Änderungen an einem vorhandenen Build derselbe Datums-Code wie beim vorhandenen Build verwendet wird.
• bbb kennzeichnet einzelne Versionen, die sich auf denselben Datums-Code beziehen, beginnend mit 001.
• Cn ist ein optionaler alphanumerischer Wert, der einen Hotfix für einen vorhandenen Build vom Typ PVBB.YYMMDD.bbb identifiziert. Er beginnt mit A1.

In Android 7.00 und älteren Versionen wird eine andere, kürzere Build-ID verwendet, z. B. FRF85B. Dabei gilt:

• Der erste Buchstabe ist der Codename der Release-Familie, z. B. F für Froyo.
• Der zweite Buchstabe ist ein Branch-Code, mit dem Google den genauen Code-Branch identifizieren kann, aus dem der Build erstellt wurde. R ist der primäre Release-Zweig.
• Der dritte Buchstabe und die beiden folgenden Zahlen bilden einen Datums-Code. Der Buchstabe gibt das Quartal an (A ist das 1. Quartal 2009, F das 2. Quartal 2010 usw.). Die beiden Zahlen geben die Anzahl der Tage innerhalb des Quartals an (F85 ist der 24. Juni 2010). Der Datumscode ist nicht immer das genaue Datum, an dem ein Build erstellt wurde. Es ist üblich, dass bei geringfügigen Änderungen an einem vorhandenen Build derselbe Datumscode wie beim vorhandenen Build verwendet wird.
• Der letzte Buchstabe kennzeichnet einzelne Versionen, die sich auf denselben Datums-Code beziehen, und beginnt sequenziell mit A (was implizit ist und in der Regel aus Gründen der Übersichtlichkeit weggelassen wird).

Sicherheitsupdates verwenden eine rein numerische Build-ID (z. B. 7786871) und sind Teil der Quellcode-Releases, die auf den Backport-Zweigen basieren. Sie können diese Sicherheitsupdates auf Ihre vorherigen Android-Versionen anwenden.

Die Zweige „froyo“, „gingerbread“, „ics-mr0“, „ics-mr1“, „jb-dev“, „jb-mr1-dev“, „jb-mr1.1-dev“, „jb-mr2-dev“ und „kitkat-dev“ stellen Entwicklungszweige dar, die nicht genau den von Google getesteten Konfigurationen entsprechen. Daher können diese Branches neben den offiziellen getaggten Releases auch eine Vielzahl von Änderungen enthalten und sind möglicherweise nicht so gründlich getestet.

Unterscheidung zwischen Releases

Um zwischen Releases zu unterscheiden, können Sie eine Liste der Änderungen abrufen, die mit jedem Projekt verknüpft sind. Geben Sie dazu den folgenden Befehl ein und übergeben Sie ihm die beiden Branch-Tags:

repo forall -pc 'git log --no-merges --oneline branch-1..branch-2'

Beispiel:

repo forall -pc 'git log --no-merges --oneline android-4.4.2_r2..android-4.4.2_r1'

So senden Sie die Ausgabe an eine Textdatei:

  repo forall -pc 'git log --no-merges --oneline android-4.4.2_r2..android-4.4.2_r1' > /tmp/android-4.4.2_r2-android-4.4.2_r1-diff.txt

Honeycomb-GPL-Module

Für Honeycomb ist nicht der gesamte Quellcode der Plattform verfügbar. Die Teile von Honeycomb, die unter der GPL und LGPL lizenziert sind, sind jedoch unter den folgenden Tags verfügbar.

Kein Manifest enthält genau diese Module, aber einige Manifeste ermöglichen das Erstellen dieser Komponenten. Die folgenden Befehle funktionieren für 3.0_r1.1:

repo init -b main -m base-for-3.0-gpl.xml
repo sync
repo forall -c git checkout android-3.0_r1.1

Wenn Sie eine andere Version verwenden möchten, ändern Sie den Parameter git checkout und (falls erforderlich) den Parameter -m in repo init. Der Befehl git checkout gibt einen Fehler für alle Nicht-GPL-Projekte aus, bei denen das Tag nicht gefunden werden kann.

Geräte-Codenamen

In der folgenden Tabelle sind die Gerätecodenamen für Google-Geräte aufgeführt. Sie können diese Codenamen verwenden, um Build-Zielstrings zu erstellen, die mit dem Befehl lunch verwendet werden: