Codinomes, tags e números da versão

As versões de desenvolvimento do Android são organizadas em famílias, com codinomes em ordem alfabética.

Builds e tags de código-fonte

A tabela abaixo apresenta a lista exata de tags e builds, a partir do Android Donut. O ID do build oferece informações como a versão da plataforma, a ramificação do código e a data em que a versão foi ramificada ou sincronizada com a ramificação de desenvolvimento.

Definições do ID do build

No Android 8.0.0 (Oreo) e em versões mais recentes, os builds são identificados pelo formato PVBB.AAMMDD.bbb[.Cn] do ID do build, em que:

• P representa a primeira letra do codinome da versão da plataforma (por exemplo, O é Oreo). No Android 10 e em codinomes mais recentes, a letra equivalente é usada, como Q para o Android 10 e R para o Android 11.
• V representa uma ramificação vertical compatível. Por convenção, P representa a ramificação principal da plataforma.
• BB representa um código alfanumérico que permite ao Google identificar a ramificação de código exata em que o build foi criado.
• AAMMDD identifica a data da ramificação ou sincronização da versão com a ramificação de desenvolvimento. Essa nem sempre é a data exata em que um build foi criado, já que é comum que pequenas variações adicionadas a um build existente reutilizem o mesmo código de data desse build.
• bbb identifica versões individuais relacionadas ao mesmo código de data, iniciando sequencialmente com 001.
• Cn é um alfanumérico opcional, que identifica um hotfix feito em um build PVBB.AAMMDD.bbb, começando com A1.

Android 7.00 e versões mais antigas usam um ID de build diferente e mais curto (por exemplo, FRF85B), em que:

• A primeira letra é o codinome da família da versão, por exemplo, F refere-se a Froyo.
• A segunda letra é um código de ramificação que mostra ao Google a ramificação de código exata em que o build foi criado. Por convenção, R é a ramificação principal de versão.
• A terceira letra e os dois dígitos seguintes são um código de data. A letra indica a contagem de trimestres (A é o 1º trimestre de 2009, F é o 2º trimestre de 2010 etc.). Os dois números indicam a contagem dos dias dentro do trimestre (F85 se refere a 24 de junho de 2010). O código de data nem sempre é a data exata em que um build foi criado, já que é comum que pequenas variações adicionadas a um build reutilizem o mesmo código de data dele.
• A última letra identifica versões individuais relacionadas ao mesmo código de data, iniciando sequencialmente com A, o que é implícito e geralmente omitido para simplificar.

Atualizações de segurança usam um ID de build meramente numérico (por exemplo, 7786871) e fazem parte das versões do código-fonte baseadas nas ramificações da backport. É possível aplicar essas atualizações de segurança em versões anteriores do Android.

Por fim, as ramificações froyo, gingerbread, ics-mr0, ics-mr1, jb-dev, jb-mr1-dev, jb-mr1.1-dev, jb-mr2-dev e kitkat-dev representam ramificações de desenvolvimento que não correspondem exatamente às configurações testadas pelo Google. Assim, essas ramificações podem conter uma variedade de mudanças, além das versões oficiais marcadas, e podem não ter sido completamente testadas.

Diferenciar entre versões

Para diferenciar as versões, você pode acessar uma lista das mudanças associadas ao projeto executando o comando abaixo e transmitindo as duas tags de ramificação:

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

Exemplo:

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

Para enviar o resultado para um arquivo de texto:

  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

Módulos GPL do Honeycomb

Para o Honeycomb, todo o código-fonte da plataforma está indisponível. No entanto, as partes do Honeycomb licenciadas pela GPL e LGPL estão disponíveis nas seguintes tags:

Nenhum manifesto contém exatamente esses módulos, mas alguns permitem a criação desses componentes. Os comandos abaixo funcionam para 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

Para usar outra versão, mude o parâmetro git checkout e, se necessário, o parâmetro -m em repo init. O comando git checkout resulta em um erro para os projetos não GPL em que não é possível encontrar a tag.

Codinomes de dispositivos

A tabela a seguir lista os codinomes de dispositivos do Google. Você pode usar esses codinomes para formar strings alvo de build usadas com o comando lunch: