O Android 10 descontinua os dados de fuso horário baseados em APK (disponível no Android 8.1 e no Android 9) e o substitui por um mecanismo de atualização de módulo baseado em APEX (em inglês). As versões 8.1 a 13 do AOSP ainda incluem o código da plataforma necessário para que os OEMs façam a ativação. atualizações baseadas em APK, para que os dispositivos façam upgrade para o Android 10. ainda podem receber atualizações de dados de fuso horário fornecidos pelo parceiro pelo APK. No entanto, o mecanismo de atualização do APK não deve ser usado em dispositivos de produção. que também recebe atualizações de módulo como uma atualização baseada em APK substitui um Atualização baseada em APEX, ou seja, um dispositivo que recebesse uma atualização de APK ignoraria atualizações baseadas em APEX).
Atualizações de fuso horário (Android 10 e versões mais recentes)
O módulo de dados de fuso horário com suporte no Android 10 e atualizações sobre o horário de verão (DST, na sigla em inglês) e os fusos horários em dispositivos Android; padronizando dados que podem mudar com frequência em termos de religião, política e por motivos geopolíticos.
As atualizações seguem este processo:
- IANA (em inglês) lança uma atualização do banco de dados de fusos horários libera uma atualização em resposta a um ou mais governos alterando a regra de fuso horário de seus países.
- O Google ou o parceiro Android prepara uma atualização do módulo de dados de fuso horário (arquivo APEX) contendo os fusos horários atualizados.
- O dispositivo do usuário final faz o download da atualização, reinicia e aplica a for alterado. Após essa data, os dados de fuso horário do dispositivo incluirão o novo fuso horário. os dados da atualização.
Para obter detalhes sobre os módulos, consulte Componentes modulares do sistema.
Atualizações de fuso horário (Android 8.1 a 9)
Observação:o mecanismo de atualização de dados de fuso horário com base em APK tem foram completamente removidos do Android 14 e versões mais recentes e não podem ser encontrados nos o código-fonte. Os parceiros devem migrar completamente para Fuso horário Módulo principal.
No Android 8.1 e no Android 9, os OEMs podem usar um mecanismo baseado em APK para enviar por push dados de regras de fuso horário atualizados para os dispositivos sem exigir uma atualização do sistema. Esse mecanismo permite que os usuários recebam atualizações oportunas (aumentando, assim, o vida útil útil de um dispositivo Android) e permite que os parceiros Android testem o fuso horário é atualizado independentemente das atualizações da imagem do sistema.
A equipe das principais bibliotecas do Android fornece os arquivos de dados necessários para atualizando regras de fuso horário em um dispositivo Android padrão. OEMs podem optar por usar esses arquivos de dados ao criar atualizações de fuso horário para dispositivos, ou ao criar próprios arquivos de dados, se preferir. Em todos os casos, os OEMs mantêm o controle sobre a qualidade garantia/teste, tempo e lançamento de atualizações de regras de fuso horário para seus compatíveis.
Código-fonte e dados do fuso horário do Android
Todos os dispositivos Android de estoque, mesmo aqueles que não usam esse recurso, precisam de fuso horário
dados de regras e deve ser enviado com um conjunto padrão de dados de regras de fuso horário no
/system
. Em seguida, esses dados são usados pelo código
seguintes bibliotecas na árvore de origem do Android:
- Código gerenciado de
libcore/
(por exemplo,java.util.TimeZone
) usatzdata
e arquivostzlookup.xml
. - Código de biblioteca nativa em
bionic/
(por exemplo, paramktime
, chamadas do sistema de horário local) usa o arquivotzdata
. - O código da biblioteca ICU4J/ICU4C em
external/icu/
usa a icu arquivo.dat
.
Essas bibliotecas rastreiam arquivos de sobreposição que podem estar presentes no
/data/misc/zoneinfo/current
. Arquivos de sobreposição são esperados
para conter dados de regras de fuso horário aprimorados, permitindo que os dispositivos sejam atualizados
sem mudar a /system
.
Os componentes do sistema Android que precisam de dados de regra de fuso horário verificam o seguinte locais primeiro:
- Os códigos
libcore/
ebionic/
usam as Cópia de/data
detzdata
etzlookup.xml
. - O código ICU4J/ICU4C usa os arquivos em
/data
e usa como Arquivos/system
para dados que não estão presentes (para formatos, localizados strings etc.).
Arquivos Distro
Os arquivos .zip
de distribuição contêm os arquivos de dados necessários para preencher a
/data/misc/zoneinfo/current
. Os arquivos de distribuição também
contêm metadados que permitem que os dispositivos detectem problemas de controle de versão.
O formato do arquivo de distribuição depende da versão do Android porque o conteúdo mudar com a versão ICU, os requisitos da plataforma Android e outras mudanças. O Android fornece arquivos de distribuição para as versões com suporte do Android para cada Atualização da IANA (além de atualizar os arquivos do sistema da plataforma). Para manter dispositivos atualizados, OEMs podem usar esses arquivos de distribuição ou criar seus próprios usando a árvore de origem do Android, que contém os scripts e outros arquivos necessários para gerar arquivos de distribuição).
Componentes de atualização do fuso horário
A atualização das regras de fuso horário envolve a transmissão de arquivos de distribuição para um dispositivo e a instalação segura dos arquivos contidos nele. Transferir e requer o seguinte:
- Funcionalidade do serviço da plataforma
(
timezone.RulesManagerService
) que fica desativado por padrão. Os OEMs precisam ativar a funcionalidade pela configuração.RulesManagerService
é executado no processo e nos estágios do servidor do sistema operações de atualização do fuso horário gravando/data/misc/zoneinfo/staged
.RulesManagerService
sabe substituir ou excluir operações já preparadas. -
TimeZoneUpdater
, um app do sistema não atualizável (também conhecido como app Updater). OEMs precisam incluir esse app na imagem do sistema de dispositivos que usam o recurso. - OEM
TimeZoneData
, um app do sistema atualizável (também conhecido como app de dados) que carrega arquivos de distribuição para o dispositivo e os torna disponível no app Updater. Os OEMs precisam incluir esse app na imagem do sistema do dispositivos que usam o recurso. -
tzdatacheck
, um binário de tempo de inicialização necessário para a operação correta e segura das atualizações de fuso horário.
A árvore de origem do Android contém um código-fonte genérico para o item acima que o OEM pode optar por usar sem modificações. Código de teste é fornecido para permitir que OEMs verifiquem automaticamente se o recurso foi ativado corretamente.
Instalação da Distro
O processo de instalação de distro inclui as seguintes etapas:
- O app de dados é atualizado por um download da app store ou
por sideload. O processo do servidor do sistema (por meio
timezone.RulesManagerServer/timezone.PackageTracker
de turmas) monitora mudanças no pacote de app de dados configurado e específico do OEM; nome.
Figura 1. Atualizações do app de dados.
- O processo do servidor do sistema aciona uma verificação de atualização:
transmitir uma intent direcionada com um token exclusivo de uso único para o Updater.
Aplic. O servidor do sistema acompanha o token mais recente gerado para que
pode determinar quando a verificação mais recente acionada foi concluída; qualquer outro
e tokens serão ignorados.
Figura 2. Acione a verificação de atualização.
- Durante a verificação de atualização, o app Updater executa o
as seguintes tarefas:
- Consulta o estado atual do dispositivo chamando o RulesManagerService.
Figura 3. Atualizações de apps de dados, chamando RulesManagerService.
- Consulta o app de dados consultando um URL do ContentProvider bem definido e
especificações de coluna para obter informações sobre a distribuição.
Figura 4. Atualizações de apps de dados e informações sobre distribuição.
- Consulta o estado atual do dispositivo chamando o RulesManagerService.
- O app Updater toma a ação adequada com base no
informações que possui. As ações disponíveis incluem:
- Solicite uma instalação. Os dados de distribuição são lidos no app Data e é passado para o RulesManagerService no servidor do sistema. A RulesManagerService confirma novamente que a versão no formato de distribuição e o conteúdo são adequado para o dispositivo e organiza a instalação.
- Solicite uma desinstalação (isso é raro). Por exemplo, se a versão
O APK em
/data
está sendo desativado ou desinstalado, e o dispositivo está sendo retornando à versão presente em/system
. - Não fazer nada: Ocorre quando a distribuição do app de dados é inválida.
Figura 5. Verificação concluída.
- Reiniciar e tzdatacheck. Na próxima inicialização do dispositivo,
o binário tzdatacheck executa qualquer operação preparada. O binário tzdatacheck pode
execute as seguintes tarefas:
- Execute a operação testada, lidando com a criação, substituição
e/ou a exclusão dos arquivos
/data/misc/zoneinfo/current
antes de outros componentes do sistema foram abertos e começaram a usar os arquivos. - Verifique se os arquivos em
/data
estão corretos para o arquivo versão da plataforma, o que pode não ser o caso se o dispositivo tiver acabado de receber uma atualização do sistema e a versão do formato de distribuição mudou. - Verifique se a versão das regras da IANA é igual ou mais recente que a versão no
/system
: Isso protege contra uma atualização do sistema que sai do dispositivo com dados de regras de fuso horário mais antigos do que os presentes em/system
imagem.
- Execute a operação testada, lidando com a criação, substituição
e/ou a exclusão dos arquivos
Confiabilidade
O processo de instalação completo é assíncrono e dividido em três SOs processos de negócios seguros. A qualquer momento durante a instalação, o dispositivo pode ficar sem energia, ser executado sem espaço em disco ou outros problemas, fazendo com que a verificação da instalação estar incompleta. Na melhor falha, o app Updater informa ao sistema de que ela não foi bem-sucedida. no pior caso, o RulesManagerService não recebe nenhuma chamada.
Para lidar com isso, o código do servidor do sistema monitora se um evento a verificação de atualização foi concluída e qual o último código de versão verificado O app é. Quando o dispositivo está inativo e carregando, o código do servidor do sistema pode verificar o estado atual. Se ele descobrir uma verificação de atualização incompleta ou Dados inesperados versão do app, ele aciona espontaneamente uma verificação de atualização.
Segurança
Quando ativado, o código de RulesManagerService no servidor do sistema realiza fazer várias verificações para garantir a segurança do uso do sistema.
- Problemas que indicam uma imagem do sistema mal configurada impedem um dispositivo
inicialização por exemplo, uma configuração incorreta do atualizador ou do app de dados
O atualizador ou o app de dados não está no
/system/priv-app
. - Problemas que indicam que um app de dados inválido foi instalado não impedem uma o dispositivo inicializa, mas impede o acionamento de uma verificação de atualização; exemplos incluem a falta das permissões necessárias do sistema ou o aplicativo de dados não expõe uma ContentProvider no URI esperado.
As permissões de arquivo para os diretórios /data/misc/zoneinfo
são
aplicada usando regras SELinux. Como acontece com qualquer APK, o app de dados precisa ser assinado pelo
mesma chave usada para assinar a versão do /system/priv-app
. O aplicativo de dados
precisa ter uma chave e um nome de pacote exclusivos e específicos para OEM.
Integrar atualizações de fuso horário
Para ativar o recurso de atualização de fuso horário, os OEMs geralmente:
- Criar o próprio app de dados.
- Incluir os apps Updater e Data no build da imagem do sistema.
- Configurar o servidor do sistema para ativar o RulesManagerService.
Preparação
Antes de começar, os OEMs precisam consultar a política a seguir, controle de qualidade, e considerações de segurança:
- Criar uma chave de assinatura específica para o app de dados.
- Criar uma estratégia de lançamento e controle de versões para atualizações de fuso horário para entender quais dispositivos serão atualizados e como garantir que as atualizações são instaladas apenas nos dispositivos que precisam delas. Por exemplo, OEMs podem querer de ter um único app de dados para todos os dispositivos ou escolher usar Apps de dados para dispositivos diferentes. A decisão afeta a escolha do pacote possivelmente os códigos de versão usados e a estratégia de QA.
- entender se o cliente quer usar dados de fuso horário do Android. do AOSP ou criar uma nova.
Criar um app de dados
O AOSP inclui todo o código-fonte e as regras de build necessárias para criar um app de dados no
packages/apps/TimeZoneData
, com instruções e modelos de exemplo
para AndroidManifest.xml
e outros arquivos localizados em
packages/apps/TimeZoneData/oem_template
Exemplos de modelos incluem
um destino de build para o APK real do app de dados e destinos extras para
criar versões de teste do aplicativo de dados.
Os OEMs podem personalizar o app de dados com os próprios ícones, nomes, traduções e outros detalhes. No entanto, como não é possível abrir o app de dados, o ícone aparece somente nas Configurações > Tela Apps.
O app de dados foi desenvolvido com uma versão de tapas que produz APKs adequados para adição à imagem do sistema (para o versão) e assinada e distribuída em uma app store (para armazenamentos atualizações. Para mais detalhes sobre o uso de tapas, consulte Criação do App de dados que usa tapas.
Os OEMs precisam instalar o app Data pré-criado na imagem do sistema de um dispositivo
/system/priv-app
: Para incluir APKs pré-criados (gerados pelas APIs de tapas
processo de build) na imagem do sistema, os OEMs podem copiar os arquivos de exemplo
packages/apps/TimeZoneData/oem_template/data_app_prebuilt
: A
Os modelos de exemplo também incluem destinos de build para incluir versões de teste do
App de dados em conjuntos de testes.
Incluir os apps Updater e Data na imagem do sistema
Os OEMs precisam colocar os APKs do atualizador e do app de dados no
Diretório /system/priv-app
da imagem do sistema. Para fazer isso, o
O build da imagem do sistema precisa incluir explicitamente os apps Updater e Data pré-criados.
de destino.
O app Updater precisa ser assinado com a chave de plataforma e incluído como qualquer
ou outro app do sistema. A meta é definida em
packages/apps/TimeZoneUpdater
como TimeZoneUpdater
. A
A inclusão de apps de dados é específica do OEM e depende do nome de destino escolhido para
pré-construção.
Configurar o servidor do sistema
Para ativar as atualizações de fuso horário, os OEMs podem configurar o servidor do sistema da seguinte forma:
as propriedades de configuração definidas
frameworks/base/core/res/res/values/config.xml
:
Propriedade | Descrição | Substituição necessária? |
---|---|---|
config_enableUpdateableTimeZoneRules |
Precisa ser definido como true para ativar o RulesManagerService. |
Sim |
config_timeZoneRulesUpdateTrackingEnabled |
Precisa ser definido como true para que o sistema detecte mudanças.
app de dados. |
Sim |
config_timeZoneRulesDataPackage |
Nome do pacote do app de dados específico do OEM. | Sim |
config_timeZoneRulesUpdaterPackage |
Configurado para o app Updater padrão. Alterar apenas ao fornecer um outra implementação do app Updater. | Não |
config_timeZoneRulesCheckTimeMillisAllowed |
O tempo permitido entre o acionamento de uma verificação de atualização pelo RulesManagerService e uma resposta de instalar, desinstalar ou não fazer nada. Depois um gatilho de confiabilidade espontâneo pode ser gerado. | Não |
config_timeZoneRulesCheckRetryCount |
O número de verificações de atualização sequenciais malsucedidas permitidas antes da O RulesManagerService para de gerar mais arquivos. | Não |
As substituições de configuração precisam estar na imagem do sistema (não do fornecedor nem de outro) como um dispositivo mal configurado pode se recusar a inicializar. Se a configuração modificar na imagem do fornecedor, atualizando para uma imagem do sistema sem um app de dados (ou com diferentes nomes de pacotes do app de dados/atualizador) seria considerada uma configuração incorreta.
Teste xTS
xTS se refere a qualquer pacote de testes específico do OEM semelhante ao Android padrão pacotes de testes usando o Tradefed (como CTS e VTS). OEMs que tenham esse tipo de podem adicionar testes de atualização de fuso horário do Android fornecidos nos locais:
packages/apps/TimeZoneData/testing/xts
inclui o código necessários para testes funcionais automatizados básicos.packages/apps/TimeZoneData/oem_template/xts
contém uma amostra. estrutura de diretórios para incluir testes em um pacote xTS semelhante ao Tradefed. Assim como acontece com outros diretórios de modelo, os OEMs devem copiar e personalizar para seus necessidades.packages/apps/TimeZoneData/oem_template/data_app_prebuilt
contém uma configuração de tempo de build para incluir os APKs de teste pré-criados necessários para o teste.
Criar atualizações de fuso horário
Quando a IANA lança um novo conjunto de regras de fuso horário, as principais bibliotecas do Android de software gera patches para atualizar versões no AOSP. OEMs que usam a versão padrão do Android os arquivos de sistema e de distribuição podem obter essas confirmações, usá-las para do app de dados e lançar a nova versão para atualizar os dispositivos em produção.
Como os apps de dados contêm arquivos de distribuição intimamente vinculados às versões do Android, Os OEMs precisam criar uma nova versão do app Data para todas as versões compatíveis uma versão do Android que um OEM quer atualizar. Por exemplo, se um OEM quiser fornecem atualizações para o Android 8.1, 9 e 10 eles precisarão concluir o processo três vezes.
Etapa 1: atualizar os arquivos de sistema/fuso horário e dados externos/icu
Nesta etapa, os OEMs fazem o inventário dos commits do Android para
system/timezone
e external/icu
do
release-dev no AOSP e aplicar esses commits à cópia deles
o código-fonte do Android.
O patch do AOSP do sistema/fuso horário contém arquivos atualizados em
system/timezone/input_data
e
system/timezone/output_data
. OEMs que precisam fazer melhorias
podem modificar os arquivos de entrada e usar os arquivos
system/timezone/input_data
e external/icu
a
gerar arquivos em output_data
.
O arquivo mais importante é
system/timezone/output_data/distro/distro.zip
, que é
incluídos automaticamente quando o APK do app de dados é criado.
Etapa 2: atualizar o código de versão do app de dados
Nesta etapa, os OEMs atualizam o código de versão do app Data. O build
escolhe distro.zip
automaticamente, mas a nova versão da
O app de dados precisa ter um novo código de versão para ser reconhecido como novo e usado para:
substituir um app de dados pré-carregado ou um app de dados instalado em um dispositivo por uma
atualizar.
Ao criar o app Data usando arquivos copiados de
package/apps/TimeZoneData/oem_template/data_app
, você encontra
código de versão/nome da versão aplicado ao APK em Android.mk
:
TIME_ZONE_DATA_APP_VERSION_CODE := TIME_ZONE_DATA_APP_VERSION_NAME :=
Entradas semelhantes podem ser encontradas em testing/Android.mk
(no entanto, o
códigos de versão de teste precisam ser superiores à versão da imagem do sistema). Para mais detalhes,
consulte o exemplo de estratégia de código de versão
esquema; Se o esquema de exemplo ou um esquema semelhante for usado, o
códigos de versão não precisam ser atualizados, porque eles certamente serão maiores
do que os códigos de versão reais.
Etapa 3: recriar, assinar, testar e lançar
Nesta etapa, os OEMs recriam o APK usando tapas, assinam a versão e, em seguida, teste e lance o APK:
- Para dispositivos que ainda não foram lançados (ou ao preparar uma atualização do sistema para uma dispositivo lançado), envie os novos APKs no diretório pré-criado do app de dados. para garantir que a imagem do sistema e os testes xTS tenham os APKs mais recentes. Os OEMs precisam testar se o novo arquivo funciona corretamente (ou seja, se ele passa no CTS e em qualquer testes automatizados e manuais específicos do OEM).
- Para dispositivos lançados que não recebem mais atualizações do sistema, o APK assinado só podem ser lançados em uma app store.
Os OEMs são responsáveis pelo controle de qualidade e pelo teste da versão App de dados nos dispositivos deles antes do lançamento.
Estratégia de código da versão do app de dados
O app de dados precisa ter adequado estratégia de controle de versões para garantir que os dispositivos recebam os APKs corretos. Para exemplo, se for recebida uma atualização do sistema com um APK mais antigo que um baixado da app store, a versão da app store deve ser mantida.
O código da versão do APK precisa incluir as seguintes informações:
- Versão no formato Distro (principal + secundária)
- Um número de versão incremental (opaca)
Atualmente, o nível da API da plataforma está fortemente correlacionado à versão do formato de distribuição porque cada nível de API geralmente está associado a uma nova versão da ICU (que torna os arquivos de distribuição incompatíveis). No futuro, o Android poderá mudar isso para que um arquivo de distribuição pode funcionar em várias versões da plataforma Android (e em várias não é usado no esquema de código de versão do app de dados).
Exemplo de estratégia de código de versão
Este exemplo de esquema de número de controle de versão garante que um formato de distribuição maior
substituem as versões mais antigas no formato de distribuição.
AndroidManifest.xml
usa android:minSdkVersion
para
garantir que dispositivos antigos não recebam versões com um formato de distribuição mais alto
mais recente do que consegue lidar.
Figura 6. Exemplo de estratégia de código de versão.
Exemplo | Valor | Objetivo |
---|---|---|
S | Reservados | permite futuros esquemas alternativos/APKs de teste. Inicialmente, é (implicitamente) 0. Como o tipo subjacente é int assinado de 32 bits, esse esquema aceita até duas futuras revisões do esquema de numeração. |
1 | Versão do formato principal | Acompanha a versão do formato principal com três dígitos decimais. O formato de distribuição aceita Três dígitos decimais, mas apenas dois dígitos são usados aqui. É improvável que chegue a 100 considerando o grande incremento esperado por nível de API. A versão principal 1 é equivalente para o nível 27 da API. |
1 | Versão secundária do formato | Acompanha a versão secundária de três dígitos decimais. O formato de distribuição aceita Três dígitos decimais, mas apenas um dígito é usado aqui. É improvável que chegue a 10. |
X | Reservados | É 0 para versões de produção e pode ser diferente para APKs de teste. |
ZZZZ | Número da versão opaca | Número decimal alocado sob demanda. Inclui lacunas para permitir anúncios intersticiais se necessário. |
O esquema poderia ser melhor compactado se fosse usado binário em vez de decimal, mas esse esquema tem a vantagem de ser legível por humanos. Se o intervalo numérico completo acabar, o nome do pacote do app de dados poderá mudar.
O nome da versão é uma representação legível dos detalhes, por
exemplo: major=001,minor=001,iana=2017a, revision=1,respin=2
.
Confira alguns exemplos na tabela abaixo.
# | Código da versão | minSdkVersion | {Versão principal do formato},{Versão secundária do formato},{regras da IANA versão},{Revisão} |
---|---|---|---|
1 | 11000010 | O-MR1 | principal=001,secundária=001,iana=2017a,revisão=1 |
2 | 21000010 | P | principal=002,secundária=001,iana=2017a,revisão=1 |
3 | 11000020 | O-MR1 | principal=001,secundária=001,iana=2017a,revision=2 |
4 | 11000030 | O-MR1 | principal=001,secundária=001,iana=2017b,revisão=1 |
5 | 21000020 | P | principal=002,secundária=001,iana=2017b,revisão=1 |
6 | 11000040 | O-MR1 | principal=001,secundária=001,iana=2018a,revisão=1 |
7 | 21000030 | P | principal=002,secundária=001,iana=2018a,revisão=1 |
8 | 1123456789 | - | - |
9 | 11000021 | O-MR1 | principal=001,secundária=001,iana=2017a,revision=2,respin=2 |
- Os exemplos 1 e 2 mostram duas versões do APK para a mesma versão da IANA de 2017a com diferentes versões de formatos principais. 2 é numericamente maior que 1, que é necessárias para garantir que dispositivos mais recentes recebam versões de formatos mais altos. A A minSdkVersion garante que a versão P não será fornecida a dispositivos O.
- O exemplo 3 é uma revisão/correção para 1 e é numericamente maior que 1.
- Os exemplos 4 e 5 mostram as versões de 2017b para O-MR1 e P. Como usar numericamente superiores, eles substituem versões anteriores da IANA/revisões Android de suas respectivas antecessores.
- Os exemplos 6 e 7 mostram as versões de 2018a para O-MR1 e P.
- O exemplo 8 demonstra o uso de Y para substituir completamente o esquema Y=0.
- O exemplo 9 demonstra o uso da lacuna deixada entre 3 e 4 para girar novamente o apk.
Como cada dispositivo é enviado com um APK padrão com as versões adequadas no
imagem do sistema, não há risco de uma versão O-MR1 ser instalada em um dispositivo P
por ter um número de versão inferior ao de uma versão de imagem do sistema P. Um
com uma versão O-MR1 instalada no /data
, que recebe
uma atualização do sistema para P usa a versão /system
em vez de
a versão O-MR1 em /data
porque a versão P é sempre maior
do que qualquer app destinado ao O-MR1.
Criar o app de dados usando tapas
Os OEMs são responsáveis por gerenciar a maioria dos aspectos do app de dados de fuso horário e corretamente a imagem do sistema. O app de dados foi criado para ser com um build tapas que produz APKs adequados para serem adicionados imagem do sistema (para a versão inicial) e assinada e distribuída por meio de um app store (para atualizações subsequentes).
O Tapas é uma versão reduzida do build do Android sistema que usa uma árvore de origem reduzida para produzir versões distribuíveis do apps. OEMs familiarizados com o sistema normal de compilação do Android devem reconhecer a usando o build normal da plataforma Android.
Criar o manifesto
Uma árvore de origem reduzida geralmente é alcançada com um arquivo de manifesto personalizado que
refere-se apenas aos projetos Git necessários para o sistema de compilação e para a criação do
app. Depois de seguir as instruções
Como criar um app de dados, os OEMs precisam ter pelo menos
pelo menos dois projetos Git específicos de OEM, criados usando os arquivos de modelo no
packages/apps/TimeZoneData/oem_template
:
- Um projeto Git contém arquivos de aplicativos como o manifesto e o
os arquivos de build necessários para criar o arquivo APK do app (por exemplo,
vendor/oem/apps/TimeZoneData
). Este projeto também contém regras de build para APKs de teste que podem ser usadas por testes xTS. - Um projeto Git contém os APKs assinados produzidos pelo build do app para inclusão no build da imagem do sistema e nos testes xTS.
O build do app aproveita vários outros projetos Git que são compartilhados com o plataforma ou conter bibliotecas de código independentes de OEM.
O snippet de manifesto a seguir contém o conjunto mínimo de projetos Git necessário para oferecer suporte a um build O-MR1 do app de dados de fuso horário. OEMs precisam adicionar projetos Git específicos de OEM (que normalmente incluem um projeto que contém o certificado de assinatura) a este manifesto e pode configurar diferentes ramificações de modo adequado.
<!-- Tapas Build --> <project path="build" name="platform/build"> <copyfile src="core/root.mk" dest="Makefile" /> </project> <project path="prebuilts/build-tools" name="platform/prebuilts/build-tools" clone-depth="1" /> <project path="prebuilts/go/linux-x86" name="platform/prebuilts/go/linux-x86" clone-depth="1" /> <project path="build/blueprint" name="platform/build/blueprint" /> <project path="build/kati" name="platform/build/kati" /> <project path="build/soong" name="platform/build/soong"> <linkfile src="root.bp" dest="Android.bp" /> <linkfile src="bootstrap.bash" dest="bootstrap.bash" /> </project> <!-- SDK for system / public API stubs --> <project path="prebuilts/sdk" name="platform/prebuilts/sdk" clone-depth="1" /> <!-- App source --> <project path="system/timezone" name="platform/system/timezone" /> <project path="packages/apps/TimeZoneData" name="platform/packages/apps/TimeZoneData" /> <!-- Enable repohooks --> <project path="tools/repohooks" name="platform/tools/repohooks" revision="main" clone_depth="1" /> <repo-hooks in-project="platform/tools/repohooks" enabled-list="pre-upload" />
Executar o build de tapas
Depois que a árvore de origem for estabelecida, invoque o build tapas usando os seguintes comandos:
source build/envsetup.sh
tapas
make -j30 showcommands dist TARGET_BUILD_APPS='TimeZoneData TimeZoneData_test1 TimeZoneData_test2' TARGET_BUILD_VARIANT=userdebug
Um build bem-sucedido gera arquivos no diretório out/dist
para
testes. Esses arquivos podem ser colocados no diretório pré-criados para inclusão em
da imagem do sistema e/ou distribuídos em uma loja de aplicativos para
dispositivos.