Codenamen, Tags und Build-Nummern

Android-Entwicklungsversionen sind in Familien mit alphabetischen Codenamen organisiert.

Quellcode-Tags und Builds

Ab Donut finden Sie die genaue Liste der Tags und Builds in der folgenden Tabelle. Die Build-ID enthält Informationen wie die Plattformversion, den Codezweig und das Datum, an dem die Version vom Entwicklungszweig abgezweigt oder mit diesem synchronisiert wurde.

Build-ID-Definitionen

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

• P steht für den ersten Buchstaben des Codenamens der Plattformversion, z. B. O für Oreo. Für Android 10 und höher wird der Buchstabencode verwendet, z. B. Q für Android 10 und R für Android 11.
• V steht für eine unterstützte Branche. Üblicherweise steht P 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.
• JJJJMMTT gibt das Datum an, an dem die Version vom Entwicklungszweig abgezweigt oder mit ihm synchronisiert wird. Es ist nicht immer das genaue Datum, an dem ein Build erstellt wurde, da bei geringfügigen Änderungen an einem vorhandenen Build häufig derselbe Datumscode wie beim vorhandenen Build wiederverwendet wird.
• bbb gibt einzelne Versionen mit demselben Datumscode an, beginnend mit 001.
• Cn ist ein optionaler alphanumerischer String, der einen Hotfix auf einem vorhandenen PVBB.YYMMDD.bbb-Build identifiziert, beginnend mit A1.

Bei Android 7.00 und älteren Releases wird eine andere, kürzere Build-ID verwendet (z. B. FRF85B), wobei:

• Der erste Buchstabe ist der Codename der Release-Familie. F steht beispielsweise 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. Üblicherweise ist R der primäre Release-Zweig.
• Der dritte Buchstabe und die beiden folgenden Ziffern sind ein Datumscode. Der Buchstabe steht für Quartale (A steht für das 1. Quartal 2009, F für das 2. Quartal 2010 usw.). Die beiden Zahlen geben die Tage innerhalb des Quartals an (F85 ist der 24. Juni 2010). Der Datumscode entspricht nicht immer dem genauen Datum, an dem ein Build erstellt wurde. Es ist üblich, 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 mit demselben Datumscode, beginnend mit A (dieser ist implizit und wird aus Gründen der Übersichtlichkeit in der Regel weggelassen).

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

Die Branches „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 mit den von Google getesteten Konfigurationen übereinstimmen. Daher können diese Branches neben den offiziellen Tagged-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 abrufen, die mit den einzelnen Projekten verknüpft sind. Geben Sie dazu den folgenden Befehl mit den beiden Branch-Tags ein:

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 Plattform-Quellcode verfügbar. Die unter der GPL und der 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 werden kann, einen Fehler aus.

Gerätecodenamen

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