Codenamen, Tags und Build-Nummern

Android-Entwicklungsreleases sind in Familien mit alphabetischen Codenamen organisiert.

Quellcode-Tags und -Builds

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

Build-ID-Definitionen

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

• P steht für den ersten Buchstaben des Codenamens des Plattform-Release, 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. Gemäß Konvention steht P für den primären Plattformzweig.
• BB ist ein alphanumerischer Code, mit dem Google den genauen Code-Branch identifizieren kann, aus dem der Build erstellt wurde.
• YYMMDD gibt das Datum an, an dem der Release vom Entwicklungszweig abgezweigt 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 Datumscode wie für den vorhandenen Build verwendet wird.
• bbb identifiziert einzelne Versionen, die sich auf denselben Datumscode beziehen, beginnend mit 001.
• Cn ist ein optionaler alphanumerischer Wert, der einen Hotfix zusätzlich zu einem vorhandenen PVBB.YYMMDD.bbb-Build identifiziert, beginnend mit A1.

Android 7.00 und ältere Versionen verwenden eine andere, kürzere Build-ID (z. B. FRF85B), wobei:

• Der erste Buchstabe ist der Codename der Release-Familie, z. B. F für Froyo.
• Der zweite Buchstabe ist ein Code-Branch, mit dem Google den genauen Code-Branch identifizieren kann, aus dem der Build erstellt wurde. Konventionsgemäß ist R der primäre Release-Zweig.
• Der dritte Buchstabe und die folgenden beiden Zahlen sind ein Datumscode. Der Buchstabe zählt die Quartale (A ist das 1. Quartal 2009, F ist das 2. Quartal 2010 usw.). Die beiden Zahlen zählen die Tage innerhalb des Quartals (F85 ist der 24. Juni 2010). Der Datumscode 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 Datumscode wie für den vorhandenen Build verwendet wird.
• Der letzte Buchstabe identifiziert einzelne Versionen, die sich auf denselben Datumscode beziehen, beginnend mit A (dieser ist implizit und wird aus Gründen der Kürze normalerweise weggelassen).

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 früheren 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 sind Entwicklungszweige, die nicht genau den von Google getesteten Konfigurationen entsprechen. Daher können diese Branches zusätzlich zu den offiziellen getaggten Releases eine Vielzahl von Änderungen enthalten und sind möglicherweise nicht so gründlich getestet.

Zwischen Releases unterscheiden

Wenn Sie zwischen Releases unterscheiden möchten, können Sie eine Liste der Änderungen für jedes Projekt abrufen. Führen Sie dazu den folgenden Befehl aus und übergeben Sie 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 der gesamte Quellcode der Plattform nicht verfügbar. Die unter der GPL und LGPL lizenzierten Teile von Honeycomb 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 für alle Nicht-GPL-Projekte, in denen das Tag nicht gefunden wird, einen Fehler aus.

Geräte-Codenamen

In der folgenden Tabelle sind die Codenamen für Google-Geräte aufgeführt. Mit diesen Codenamen können Sie Build-Zielstrings für den Befehl lunch erstellen: