Nomi in codice, tag e numeri di build

Le versioni di sviluppo di Android sono organizzate in famiglie con nomi in codice alfabetici ispirati a prelibatezze.

Nomi in codice della piattaforma, versioni, livelli API e rilasci NDK

I nomi in codice corrispondono ai seguenti numeri di versione, livelli API e release NDK.

In Android 8.0.0 (Oreo) e versioni successive, le singole build vengono identificate con il formato ID build PVBB.YYMMDD.bbb [.Cn] , dove:

• P rappresenta la prima lettera del nome in codice della versione della piattaforma, ad esempio, O è Oreo.
• V rappresenta una verticale supportata. Per convenzione, P rappresenta il ramo principale della piattaforma.
• BB è un codice alfanumerico che consente a Google di identificare il ramo di codice esatto da cui è stata creata la build.
• AAMMGG identifica la data in cui il rilascio è ramificato o sincronizzato con il ramo di sviluppo. Non è sempre la data esatta in cui è stata creata una build poiché è comune che le variazioni minori aggiunte a una build esistente riutilizzino lo stesso codice della data della build esistente.
• bbb identifica le singole versioni relative allo stesso codice data, in sequenza a partire da 001 .
• Cn è un facoltativo, alfanumerico che identifica un hotfix su una build PVBB.YYMMDD.bbb esistente, a partire da A1 .

Le versioni precedenti di Android utilizzano un codice ID build diverso e più breve (ad esempio, FRF85B ) dove:

• La prima lettera è il nome in codice della famiglia di rilascio, ad esempio, F è Froyo.
• La seconda lettera è un codice di filiale che consente a Google di identificare l'esatto ramo di codice da cui è stata creata la build. Per convenzione, R è il ramo di rilascio principale.
• La terza lettera e i due numeri seguenti sono un codice data. La lettera conta i trimestri ( A è il primo trimestre 2009, F è il secondo trimestre 2010 e così via). I due numeri contano i giorni all'interno del trimestre ( F85 è il 24 giugno 2010). Il codice della data non è sempre la data esatta in cui è stata creata una build poiché è comune che le variazioni minori aggiunte a una build esistente riutilizzino lo stesso codice della data della build esistente.
• L'ultima lettera identifica singole versioni relative allo stesso codice data, che iniziano in sequenza con A (che è implicita e solitamente omessa per brevità).

Tag e build del codice sorgente

A partire da Donut, l'elenco esatto di tag e build è nella tabella seguente.

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.