Noms de code, balises et numéros de build

Les versions de développement d'Android sont organisées en familles, avec des noms de code alphabétiques inspirés de friandises savoureuses. Cette page fournit des informations sur les noms de code, les versions, les niveaux d'API et les versions NDK de la plate -forme, 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, selon votre cas d'utilisation. Par exemple, vous pourriez avoir besoin du nom de code et des combinaisons de touches de l'appareil Android pour démarrer en mode flashboot, ou des sources du noyau et des binaires 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 les emplacements correspondants pour obtenir les sources et les binaires du noyau.
• Les builds qui sourcent plusieurs référentiels Git nécessitent des appariements de nom de code de périphérique pour obtenir une configuration de répertoire source correcte pour télécharger les sources et les outils de build.

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

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

Créer des définitions d'ID

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 plate-forme, par exemple, O est Oreo.
• V représente une verticale supportée. 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 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.
• bbb identifie les versions individuelles associées au même code de date, en commençant séquentiellement par 001 .
• Cn est un alphanumérique facultatif qui identifie un correctif au-dessus d'une version 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 de version principale.
• La troisième lettre et les deux chiffres suivants sont un code de date. La lettre compte les trimestres ( A est Q1 2009, F est Q2 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 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 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 brièveté).

Balises de code source et constructions

À partir de Donut, la liste exacte des balises et des versions 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 à laquelle la version a été dérivée ou synchronisée avec la branche de développement.

The branches froyo, gingerbread, ics-mr0, ics-mr1, jb-dev, jb-mr1-dev, jb-mr1.1-dev, jb-mr2-dev, and kitkat-dev represent development branches that don't exactly match configurations tested by Google. As such, these branches might contain a variety of changes in addition to the official tagged releases and might not be as thoroughly tested.

To differentiate between releases, you can get a list of changes associated with each project by issuing the following command and passing it the two branch tags:

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

For example:

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

To send the output to a text file:

  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 modules

For Honeycomb, the entire platform source code isn't available. However, the parts of Honeycomb licensed under the GPL and LGPL are available under the following tags.

No manifest contains exactly these modules, but some manifests allow building those components. The following commands work for 3.0_r1.1:

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

To use another version, change the git checkout parameter and (if necessary) the -m parameter in repo init . The git checkout command outputs an error for any non-GPL projects where it can't find the tag.

Codename references and resources for use cases

Resources for the type of codenames information that's needed to support specific setup use cases are listed below:

• If you're booting into Fastboot mode (from a device that's undergoing a cold boot), you need the key combinations that correspond to the Android device you're using. For a listing of devices with their corresponding Android Device codenames (for example, Nexus 5x is codenamed Bullhead and uses a specific key combination), see Booting into fast boot mode to obtain the key combinations you need.
• If your build requires sources from multiple Git repositories, use the repo approach to download sources and build tools; this ensures a correct source directory setup. To get BRANCH names for the kernels you require, see Downloading sources and build tools for a list of device-code name pairings (such as Pixel 5 - redfin), cross-referenced to their binary paths in the AOSP tree and corresponding repo branches.