Noms de code, tags et numéros de build

Les versions de développement Android sont organisées en familles, avec des noms de code alphabétiques.

Tags et builds de code source

À partir de Donut, la liste exacte des balises et des builds se trouve dans le tableau suivant. L'ID de build fournit des informations telles que la version de la plate-forme, la branche de code et la date à partir de laquelle la version a été créée ou synchronisée avec la branche de développement.

Définitions des ID de build

Sous Android 8.0.0 (Oreo) et versions ultérieures, les builds sont identifiés par le format d'ID de build PVBB.YYMMDD.bbb[.Cn], où:

• P représente la première lettre du nom de code de la version de la plate-forme. Par exemple, O correspond à Oreo. Pour les noms de code d'Android 10 et versions ultérieures, l'équivalent de la lettre est utilisé, par exemple Q pour Android 10 et R pour Android 11.
• V représente une verticale acceptée. Par convention, P représente la branche principale de la plate-forme.
• BB est un code alphanumérique qui permet à Google d'identifier la branche de code exacte à partir de laquelle la compilation a été effectuée.
• AAAAMMJJ identifie la date à partir de laquelle la version est dérivée ou synchronisée avec la branche de développement. Il ne s'agit pas toujours de la date exacte à laquelle une compilation a été effectuée, car il est courant que des variations mineures ajoutées à une compilation existante réutilisent le même code de date que la compilation existante.
• bbb identifie les versions individuelles associées au même code de date, de manière séquentielle à partir de 001.
• Cn est un élément alphanumérique facultatif qui identifie un correctif au-dessus d'un build PVBB.YYMMDD.bbb existant, à partir de A1.

Android 7.00 et les versions antérieures utilisent un ID de build différent et plus court (par exemple, FRF85B), où :

• La première lettre correspond au nom de code de la famille de versions. Par exemple, F correspond à Froyo.
• La deuxième lettre est un code de branche qui permet à Google d'identifier la branche de code exacte à partir de laquelle la compilation a été effectuée. Par convention, R est la branche de publication principale.
• La troisième lettre et les deux chiffres suivants correspondent à un code de date. La lettre indique le trimestre (A correspond au T1 2009, F au T2 2010, etc.). Les deux chiffres indiquent le nombre de jours du trimestre (F85 correspond au 24 juin 2010). Le code de date n'indique pas toujours la date exacte à laquelle une version a été créée, car il est courant que des variations mineures ajoutées à une version existante réutilisent le même code de date que la version existante.
• La dernière lettre identifie les versions individuelles associées au même code de date, en commençant par A de manière séquentielle (ce qui est implicite et généralement omis par souci de concision).

Les mises à jour de sécurité utilisent un ID de compilation purement numérique (par exemple, 7786871) et font partie des versions de code source basées sur les branches de rétroportage. Vous pouvez appliquer ces mises à jour de sécurité à vos versions Android précédentes.

Enfin, les branches froyo, gingerbread, ics-mr0, ics-mr1, jb-dev, jb-mr1-dev, jb-mr1.1-dev, jb-mr2-dev et kitkat-dev représentent des branches de développement qui ne correspondent pas exactement aux configurations testées par Google. Par conséquent, ces branches peuvent contenir diverses modifications en plus des versions taguées officielles et ne sont peut-être pas testées aussi minutieusement.

Différencier les versions

Pour différencier les versions, vous pouvez obtenir la liste des modifications associées à chaque projet en exécutant la commande suivante et en lui transmettant les deux balises de branche:

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

Exemple :

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

Pour envoyer la sortie dans un fichier texte :

  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

Modules GPL Honeycomb

Pour Honeycomb, l'intégralité du code source de la plate-forme n'est pas disponible. Toutefois, les parties de Honeycomb sous licence GPL et LGPL sont disponibles sous les tags suivants.

Aucun fichier manifeste ne contient exactement ces modules, mais certains permettent de créer ces composants. Les commandes suivantes fonctionnent pour la version 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

Pour utiliser une autre version, modifiez le paramètre git checkout et (si nécessaire) le paramètre -m dans repo init. La commande git checkout affiche une erreur pour tous les projets non GPL pour lesquels elle ne trouve pas la balise.

Noms de code des appareils

Le tableau suivant répertorie les noms de code des appareils Google. Vous pouvez utiliser ces noms de code pour former des chaînes de cibles de compilation utilisées avec la commande lunch :