Nomi in codice, tag e numeri di build

Le release per lo sviluppo di Android sono organizzate in famiglie, con nomi in ordine alfabetico.

Tag e build del codice sorgente

A partire da Donut, l'elenco esatto dei tag e delle build è riportato nella tabella seguente. L'ID build fornisce informazioni come la release della piattaforma, il ramo di codice e la data in cui la release è stata creata o sincronizzata con il ramo di sviluppo.

Creare definizioni di ID

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

• P rappresenta la prima lettera del nome in codice della release della piattaforma, ad esempio O è Oreo. Per i nomi in codice di Android 10 e versioni successive, viene utilizzata la lettera corrispondente, ad esempio Q per Android 10 e R per Android 11.
• V rappresenta un verticale supportato. Per convenzione, P rappresenta il ramo della piattaforma principale.
• BB è un codice alfanumerico che consente a Google di identificare il ramo di codice esatto da cui è stata eseguita la compilazione.
• GGMMAAAA identifica la data in cui la release viene creata da un ramo o sincronizzata con il ramo di sviluppo. Non è sempre la data esatta in cui è stata eseguita una compilazione, poiché è comune che le piccole variazioni aggiunte a una compilazione esistente riutilizzino lo stesso codice data della compilazione esistente.
• bbb identifica le singole versioni correlate allo stesso codice data, in sequenza a partire da 001.
• Cn è un valore alfanumerico facoltativo che identifica un hotfix su una compilazione PVBB.YYMMDD.bbb esistente, a partire da A1.

Android 7.00 e le versioni precedenti utilizzano un ID build diverso e più breve (ad esempio, FRF85B) in cui:

• La prima lettera è il nome in codice della famiglia di release, ad esempio F è Froyo.
• La seconda lettera è un codice ramo che consente a Google di identificare il ramo di codice esatto da cui è stata eseguita la compilazione. Per convenzione, R è il ramo di release principale.
• La terza lettera e i due numeri successivi sono un codice data. La lettera conta i trimestri (A è il primo trimestre del 2009, F è il secondo trimestre del 2010 e così via). I due numeri conteggiano i giorni del trimestre (F85 è il 24 giugno 2010). Il codice data non è sempre la data esatta in cui è stata creata una build, poiché è comune che le piccole variazioni aggiunte a una build esistente riutilizzino lo stesso codice data della build esistente.
• L'ultima lettera identifica le singole versioni relative allo stesso codice data, iniziando in sequenza con A (che è implicito e di solito viene omesso per brevità).

Gli aggiornamenti della sicurezza utilizzano un ID build puramente numerico (ad esempio 7786871) e fanno parte delle release del codice sorgente basate sui branch di backport. Puoi applicare questi aggiornamenti della sicurezza alle versioni Android precedenti.

Infine, i branch froyo, gingerbread, ics-mr0, ics-mr1, jb-dev, jb-mr1-dev, jb-mr1.1-dev, jb-mr2-dev e kitkat-dev rappresentano branch di sviluppo che non corrispondono esattamente alle configurazioni testate da Google. Di conseguenza, questi branch potrebbero contenere una serie di modifiche oltre alle release ufficiali con tag e potrebbero non essere testati in modo così accurato.

Distinguere le release

Per distinguere le release, puoi ottenere un elenco delle modifiche associate a ciascun progetto emettendo il seguente comando e passando i due tag branch:

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

Ad esempio:

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

Per inviare l'output a un file di testo:

  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

Moduli GPL di Honeycomb

Per Honeycomb, non è disponibile l'intero codice sorgente della piattaforma. Tuttavia, le parti di Honeycomb concesse in licenza ai sensi di GPL e LGPL sono disponibili con i seguenti tag.

Nessun manifest contiene esattamente questi moduli, ma alcuni manifest consentono di creare questi componenti. I seguenti comandi funzionano per 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

Per utilizzare un'altra versione, modifica il parametro git checkout e, se necessario, il parametro -m in repo init. Il comando git checkout genera un errore per tutti i progetti non GPL in cui non riesce a trovare il tag.

Nomi in codice dei dispositivi

La tabella seguente elenca i nomi in codice dei dispositivi Google. Puoi utilizzare questi nomi in codice per formare stringhe di destinazione di compilazione utilizzate con il comando lunch: