Noms de code, balises et numéros de build

Les versions de développement Android sont organisées en familles, avec des noms de code alphabétiques inspirés de délicieuses friandises. Cette page fournit des informations sur les noms de code, les versions, les niveaux d'API et les versions du NDK de la plateforme , avec une explication des définitions d'ID de build qui leur sont associées.

Notez que vous pourriez avoir besoin de détails supplémentaires sur la version du nom de code, en fonction de votre cas d'utilisation. Par exemple, vous pourriez avoir besoin d'un nom de code de périphérique Android et de combinaisons de touches pour démarrer en mode flashboot, ou de sources et binaires du noyau pour créer un noyau manuellement. Celles-ci sont résumées dans la section Références de nom de code et ressources pour les cas d'utilisation , avec des liens vous permettant de localiser les informations dont vous avez besoin pour ces sujets :

• Le démarrage en mode flashboot nécessite des combinaisons de touches pour les appareils avec leurs noms de code d'appareil Android correspondants.
• Les noyaux qui doivent être construits manuellement nécessitent des noms de code et des emplacements correspondants pour obtenir les sources et les binaires du noyau.
• Les builds qui sourcent plusieurs référentiels Git nécessitent des paires de noms de code de périphérique pour obtenir une configuration correcte du répertoire source afin de télécharger les sources et de créer des outils.

Noms de code de plate-forme, versions, niveaux d'API et versions NDK

Ce tableau répertorie les noms de code, leurs numéros de version correspondants et les niveaux d'API associés.

Définitions d'ID de build

Dans Android 8.0.0 (Oreo) et versions ultérieures, les builds individuels sont identifiés avec 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 plateforme, par exemple, O est Oreo.
• V représente une verticale prise en charge. Par convention, P représente la branche principale de la plateforme.
• BB est un code alphanumérique qui permet à Google d'identifier la branche de code exacte à partir de laquelle la construction a été réalisée.
• AAMMJJ identifie la date à 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 build a été réalisée, car il est courant que des variations mineures ajoutées à une build existante réutilisent le même code de date que la build existante.
• bbb identifie les versions individuelles liées au même code de date, en commençant séquentiellement par 001 .
• Cn est un caractère alphanumérique facultatif qui identifie un correctif au-dessus d'une build PVBB.YYMMDD.bbb existante, à partir de A1 .

Les anciennes versions d'Android utilisent un code d'identification de build différent et plus court (par exemple, FRF85B ) où :

• La première lettre est le nom de code de la famille de versions, par exemple, F est Froyo.
• La deuxième lettre est un code de branche qui permet à Google d'identifier la branche de code exacte à partir de laquelle la construction a été réalisée. Par convention, R est la branche principale de la version.
• La troisième lettre et les deux chiffres suivants sont un code de date. La lettre compte les trimestres ( A correspond au premier trimestre 2009, F correspond au deuxième trimestre 2010, et ainsi de suite). Les deux nombres comptent les jours du trimestre ( F85 correspond au 24 juin 2010). Le code de date n'est pas toujours la date exacte à laquelle une build a été créée, car il est courant que des variations mineures ajoutées à une build existante réutilisent le même code de date que la build existante.
• La dernière lettre identifie les versions individuelles liées au même code de date, commençant séquentiellement par A (qui est implicite et généralement omis par souci de concision).

Balises 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 plateforme, la branche de code et la date à laquelle la version a été dérivée ou synchronisée avec la branche de développement.

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 font pas exactement correspondre aux configurations testées par Google. En tant que telles, ces branches peuvent contenir une variété de modifications en plus des versions officielles étiquetées et peuvent ne pas être testées de manière aussi approfondie.

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

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

Par exemple:

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

Pour envoyer la sortie vers 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 en nid d'abeille

Pour Honeycomb, l'intégralité du code source de la plateforme n'est pas disponible. Cependant, les parties de Honeycomb sous licence GPL et LGPL sont disponibles sous les balises suivantes.

Aucun manifeste ne contient exactement ces modules, mais certains manifestes permettent de créer ces composants. Les commandes suivantes fonctionnent pour 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 génère une erreur pour tous les projets non GPL pour lesquels elle ne trouve pas la balise.

Références de noms de code et ressources pour les cas d'utilisation

Les ressources sur le type d’informations sur les noms de code nécessaires à la prise en charge de cas d’utilisation de configuration spécifiques sont répertoriées ci-dessous :

• Si vous démarrez en mode Fastboot (à partir d'un appareil en cours de démarrage à froid), vous avez besoin des combinaisons de touches correspondant à l'appareil Android que vous utilisez. Pour obtenir la liste des appareils avec leurs noms de code d'appareil Android correspondants (par exemple, le Nexus 5x porte le nom de code Bullhead et utilise une combinaison de touches spécifique), consultez Démarrage en mode de démarrage rapide pour obtenir les combinaisons de touches dont vous avez besoin.
• Si votre build nécessite des sources provenant de plusieurs référentiels Git, utilisez l'approche repo pour télécharger les sources et créer des outils ; cela garantit une configuration correcte du répertoire source. Pour obtenir les noms BRANCH pour les noyaux dont vous avez besoin, consultez Téléchargement de sources et d'outils de construction pour une liste des paires de noms de code de périphérique (telles que Pixel 5 - redfin), avec des références croisées à leurs chemins binaires dans l'arborescence AOSP et les branches repo correspondantes.