Regras de fuso horário

O Android 10 descontinua o mecanismo de atualização de dados de fuso horário baseado 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. O AOSP 8.1 a 13 ainda inclui o código de plataforma necessário para que os OEMs ativem atualizações baseadas em APK. Assim, os dispositivos que fazem upgrade para o Android 10 ainda podem receber atualizações de dados de fuso horário fornecidas pelo parceiro pelo APK. No entanto, o mecanismo de atualização do APK não pode ser usado em um dispositivo de produção que também recebe atualizações de módulo, já que uma atualização baseada em APK substitui uma com base em APEX. Ou seja, um dispositivo que recebeu uma atualização de APK ignoraria essas atualizações.

Atualizações de fuso horário (Android 10 e versões mais recentes)

O módulo de dados de fuso horário, compatível com o Android 10 e versões mais recentes, atualiza 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 por motivos religiosos, políticos e geopolíticos.

As atualizações seguem o seguinte processo:

1. A IANA lança uma atualização do banco de dados de fuso horário em resposta a uma ou mais mudanças de regras de fuso horário feitas por governos.
2. O Google ou o parceiro do Android prepara uma atualização do módulo de dados de fuso horário (arquivo APEX) contendo os fusos horários atualizados.
3. O dispositivo do usuário final faz o download da atualização, reinicializa e aplica as mudanças. Depois disso, os dados de fuso horário do dispositivo contêm os novos dados de fuso horário da atualização.

Para detalhes sobre os módulos, consulte Componentes modulares do sistema.

Atualizações de fuso horário (Android 8.1 a 9)

Observação:o recurso do mecanismo de atualização de dados de fuso horário com base em APK foi removido completamente do Android 14 em diante e não pode ser encontrado no código-fonte. Os parceiros precisam migrar totalmente para o módulo Mainline do fuso horário.

No Android 8.1 e no Android 9, os OEMs podem usar um mecanismo baseado em APK para enviar 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 em tempo hábil (aumentando, assim, o ciclo de vida útil de um dispositivo Android) e permite que os parceiros do Android testem as atualizações de fuso horário independentemente das atualizações da imagem do sistema.

A equipe das principais bibliotecas do Android fornece os arquivos de dados necessários para atualizar as regras de fuso horário em um dispositivo Android padrão. Os OEMs podem usar esses arquivos de dados ao criar atualizações de fuso horário para os dispositivos ou criar os próprios arquivos de dados, se preferirem. Em todos os casos, os OEMs mantêm o controle sobre a garantia/teste de qualidade, o tempo e o lançamento de atualizações de regras de fuso horário para os dispositivos com suporte.

Código-fonte e dados do fuso horário do Android

Todos os dispositivos Android padrão, mesmo aqueles que não usam esse recurso, precisam de dados de regras de fuso horário e precisam ser enviados com um conjunto padrão de dados de regras de fuso horário na partição /system. Esses dados são usados pelo código das seguintes bibliotecas na árvore de origem do Android:

• O código gerenciado de libcore/ (por exemplo, java.util.TimeZone) usa arquivos tzdata e tzlookup.xml.
• O código da biblioteca nativa em bionic/ (por exemplo, para mktime, chamadas de sistema de horário local) usa o arquivo tzdata.
• O código da biblioteca ICU4J/ICU4C em external/icu/ usa o arquivo .dat da ICU.

Essas bibliotecas rastreiam arquivos de sobreposição que podem estar presentes no diretório /data/misc/zoneinfo/current. Os arquivos de sobreposição devem conter dados de regras de fuso horário aprimorados, permitindo que os dispositivos sejam atualizados sem alterar /system.

Os componentes do sistema Android que precisam de dados de regras de fuso horário verificam primeiro os seguintes locais:

• Os códigos libcore/ e bionic/ usam a cópia /data dos arquivos tzdata e tzlookup.xml.
• O código ICU4J/ICU4C usa os arquivos em /data e usa arquivos /system para dados que não estão presentes (para formatos, strings localizadas etc.).

Arquivos da distro

Os arquivos .zip da distro contêm os arquivos de dados necessários para preencher o diretório /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ões.

O formato de arquivo de distribuição depende da versão do Android porque o conteúdo muda com a versão da ICU, os requisitos da plataforma Android e outras mudanças de versão. O Android fornece arquivos de distribuição para versões do Android com suporte para cada atualização da IANA (além de atualizar os arquivos do sistema da plataforma). Para manter os dispositivos atualizados, os OEMs podem usar esses arquivos de distribuição ou criar os 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 de fuso horário

Uma 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 neles. A transferência e a instalação exigem o seguinte:

• Funcionalidade do serviço de plataforma (timezone.RulesManagerService), que é desativada por padrão. Os OEMs precisam ativar a funcionalidade pela configuração. RulesManagerService é executado no processo do servidor do sistema e organiza operações de atualização de fuso horário gravando em /data/misc/zoneinfo/staged. O RulesManagerService também pode substituir ou excluir operações já provisionadas.
• TimeZoneUpdater, um app do sistema não atualizável (também conhecido como app do atualizador). Os OEMs precisam incluir esse app na imagem do sistema dos 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 disponibiliza para o app de atualização. Os OEMs precisam incluir esse app na imagem do sistema de dispositivos que usam o recurso.
• tzdatacheck, um binário 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 o código-fonte genérico dos componentes acima, que o OEM pode usar sem modificações. O código de teste é fornecido para permitir que os OEMs verifiquem automaticamente se ativaram o recurso corretamente.

Instalação da distro

O processo de instalação de distro inclui as seguintes etapas:

1. O app de dados é atualizado com um download ou sideload da app store. O processo do servidor do sistema (usando classes timezone.RulesManagerServer/timezone.PackageTracker) monitora as mudanças no nome do pacote do app de dados configurado e específico do OEM.
   
   

   Figura 1. Atualizações do app de dados.

2. O processo do servidor do sistema aciona uma verificação de atualização transmitindo uma intent segmentada com um token exclusivo de uso único para o app Updater. O servidor do sistema rastreia o token mais recente gerado para determinar quando a verificação mais recente acionada foi concluída. Todos os outros tokens são ignorados.
   
   

   Figura 2. Acionar a verificação de atualização.

3. Durante a verificação de atualização, o app Updater executa 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 ao consultar um URL de ContentProvider e especificações de coluna bem definidos para receber informações sobre a distribuição.
     
     

     Figura 4. Atualizações do app de dados, informações sobre a distribuição.

4. O app Updater toma a ação apropriada com base nas informações que ele tem. As ações disponíveis incluem:
   • Solicitar uma instalação. Os dados da Distro são lidos do app de dados e transmitidos para o RulesManagerService no servidor do sistema. O RulesManagerService confirma que a versão e o conteúdo do formato de distribuição são adequados para o dispositivo e organiza a instalação.
   • Solicitar uma desinstalação (isso é raro). Por exemplo, se o APK atualizado em /data estiver sendo desativado ou desinstalado e o dispositivo estiver retornando à versão presente em /system.
   • Não fazer nada: Ocorre quando a distribuição do app de dados é considerada inválida.
   Em todos os casos, o app de atualização chama o RulesManagerService com o token de verificação para que o servidor do sistema saiba que a verificação foi concluída e foi bem-sucedida.
   
   

   Figura 5. Verificação concluída.

5. Reiniciar e tzdatacheck. Na próxima inicialização do dispositivo, o binário tzdatacheck executa qualquer operação em estágio. O binário tzdatacheck pode realizar as seguintes tarefas:
   • Execute a operação em estágios processando a criação, substituição e/ou exclusão dos arquivos /data/misc/zoneinfo/current antes de outros componentes do sistema abrirem e começarem a usar os arquivos.
   • Verifique se os arquivos em /data estão corretos para a versão atual da plataforma, o que pode não ser o caso se o dispositivo acabou de receber uma atualização do sistema e a versão do formato da distribuição mudou.
   • Verifique se a versão das regras da IANA é igual ou mais recente do que a versão em /system. Isso protege contra uma atualização do sistema que deixa um dispositivo com dados de regras de fuso horário mais antigos do que os presentes na imagem /system.

Confiabilidade

O processo de instalação de ponta a ponta é assíncrono e dividido em três processos do SO. A qualquer momento durante a instalação, o dispositivo pode perder energia, ficar sem espaço em disco ou encontrar outros problemas, fazendo com que a verificação de instalação seja incompleta. No melhor caso de falha, o app Updater informa ao servidor do sistema que ele não foi bem-sucedido. Na pior das hipóteses, o RulesManagerService não recebe nenhuma chamada.

Para lidar com isso, o código do servidor do sistema monitora se uma verificação de atualização acionada foi concluída e qual é o último código de versão verificado do app de dados. 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 uma versão inesperada do app de dados, ele vai acionar uma verificação de atualização de forma espontânea.

Segurança

Quando ativado, o código de RulesManagerService no servidor do sistema realiza várias verificações para garantir que o sistema é seguro.

• Problemas que indicam uma imagem do sistema mal configurada impedem a inicialização de um dispositivo. Os exemplos incluem uma configuração incorreta do app de dados ou do Updater ou o app de dados ou atualizador não estar no /system/priv-app.
• Problemas que indicam que um app de dados incorreto foi instalado não impedem a inicialização do dispositivo, mas impedem que uma verificação de atualização seja acionada. Exemplos incluem a falta de permissões do sistema necessárias ou o app de dados não expõe um ContentProvider no URI esperado.

As permissões de arquivo para os diretórios /data/misc/zoneinfo são aplicadas usando regras do SELinux. Como acontece com qualquer APK, o app de dados precisa ser assinado pela mesma chave usada para assinar a versão do /system/priv-app. O app de dados precisa ter um nome e uma chave de pacote dedicados e específicos para OEMs.

Integrar atualizações de fuso horário

Para ativar o recurso de atualização do fuso horário, os OEMs normalmente:

• Criar o próprio app de dados.
• Inclua 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 analisar as seguintes políticas, garantias de qualidade e considerações de segurança:

• Criar uma chave de assinatura específica para o app de dados.
• Crie uma estratégia de lançamento e versionamento para atualizações de fuso horário para entender quais dispositivos serão atualizados e como garantir que as atualizações sejam instaladas apenas em dispositivos que precisam delas. Por exemplo, os OEMs podem querer ter um único app de dados para todos os dispositivos ou podem optar por ter apps de dados diferentes para dispositivos diferentes. A decisão afeta a escolha do nome do pacote, possivelmente os códigos de versão usados e a estratégia de controle de qualidade.
• entender se eles querem usar dados de fuso horário do Android do banco de dados do AOSP ou criar os próprios dados.

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 em packages/apps/TimeZoneData, com instruções e modelos de exemplo para AndroidManifest.xml e outros arquivos localizados em packages/apps/TimeZoneData/oem_template. Os modelos de exemplo incluem um destino de build para o APK do app de dados real e destinos extras para criar versões de teste do app de dados.

Os OEMs podem personalizar o app de dados com o próprio ícone, nome, traduções e outros detalhes. No entanto, como o app de dados não pode ser iniciado, o ícone aparece apenas na tela Configurações > Apps.

O app de dados precisa ser criado com um build de tapas que produz APKs adequados para serem adicionados à imagem do sistema (para a versão inicial) e assinados e distribuídos por uma app store (para atualizações posteriores). Para saber mais sobre o uso de tapas, consulte Como criar o app de dados usando tapas.

Observação:a assinatura segura de APKs e o gerenciamento de chaves estão fora do escopo deste artigo.

Os OEMs precisam instalar o app Data pré-criado na imagem do sistema de um dispositivo em /system/priv-app. Para incluir APKs pré-criados (gerados pelo processo de build de tapas) na imagem do sistema, os OEMs podem copiar os arquivos de exemplo em packages/apps/TimeZoneData/oem_template/data_app_prebuilt. 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 build da imagem do sistema precisa incluir explicitamente os destinos pré-criados do app de atualização e do app de dados.

O app Updater precisa ser assinado com a chave da plataforma e incluído como qualquer outro app do sistema. O destino é definido em packages/apps/TimeZoneUpdater como TimeZoneUpdater. A inclusão do app de dados é específica do OEM e depende do nome de destino escolhido para o pré-build.

Configurar o servidor do sistema

Para ativar as atualizações de fuso horário, os OEMs podem configurar o servidor do sistema substituindo as propriedades de configuração definidas em 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 no 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. Mude apenas quando fornecer uma implementação diferente do app Updater.	Não
config_timeZoneRulesCheckTimeMillisAllowed	Tempo permitido entre uma verificação de atualização acionada pelo RulesManagerService e uma resposta de instalação, desinstalação ou não fazer nada. Depois disso, um gatilho de confiabilidade espontâneo pode ser gerado.	Não
config_timeZoneRulesCheckRetryCount	O número de verificações sequenciais de atualização com falha permitidas antes que o RulesManagerService pare de gerar mais.	Não

As substituições de configuração precisam estar na imagem do sistema (não no fornecedor ou em outros), porque um dispositivo configurado incorretamente pode se recusar a inicializar. Se as substituições de configuração estiverem na imagem do fornecedor, a atualização para uma imagem do sistema sem um app de dados (ou com nomes de pacote de apps de atualização/app de dados diferentes) será considerada uma falha de configuração.

Testes de xTS

xTS se refere a qualquer pacote de testes específico do OEM semelhante aos conjuntos de testes padrão do Android que usam o Tradefed (como CTS e VTS). Os OEMs que têm esses pacotes de teste podem adicionar os testes de atualização de fuso horário do Android fornecidos nos seguintes locais:

• packages/apps/TimeZoneData/testing/xts inclui o código necessário para testes funcionais básicos automatizados.
• packages/apps/TimeZoneData/oem_template/xts contém uma estrutura de diretório de exemplo para incluir testes em um pacote xTS semelhante ao Tradefed. Assim como em outros diretórios de modelos, espera-se que os OEMs copiem e personalizem de acordo com as necessidades deles.
• packages/apps/TimeZoneData/oem_template/data_app_prebuilt contém a configuração de tempo de build para incluir os APKs de teste pré-criados exigidos pelo teste.

Observação:a configuração de um conjunto de testes específico do OEM está fora do escopo deste artigo.

Criar atualizações de fuso horário

Quando a IANA lança um novo conjunto de regras de fuso horário, a equipe de bibliotecas principais do Android gera patches para atualizar as versões no AOSP. Os OEMs que usam o sistema Android padrão e os arquivos de distribuição podem usar esses commits para criar uma nova versão do app de dados e, em seguida, lançar a nova versão para atualizar os dispositivos em produção.

Observação:as etapas a seguir não descrevem como atualizar os arquivos de dados de base na imagem /system, o que é necessário ao preparar a imagem de fábrica ou as atualizações do sistema. Esse processo também gera o arquivo de distribuição para inclusão no app Data. Para instruções sobre como atualizar os arquivos de plataforma, consulte /system/timezone/README.android.

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 de dados para cada lançamento do Android com suporte que um OEM quer atualizar. Por exemplo, se um OEM quiser fornecer atualizações para dispositivos Android 8.1, 9 e 10, ele precisará concluir o processo três vezes.

Etapa 1: atualizar os arquivos de sistema/fuso horário e dados externos/icu

Nesta etapa, os OEMs verificam as confirmações do Android para system/timezone e external/icu nas ramificações de release-dev no AOSP e as aplicam à cópia do 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 outras correções locais podem modificar os arquivos de entrada e usar os arquivos em system/timezone/input_data e external/icu para gerar arquivos em output_data.

O arquivo mais importante é system/timezone/output_data/distro/distro.zip, que é incluído automaticamente quando o APK do app de dados é criado.

Etapa 2: atualizar o código da versão do app de dados

Nesta etapa, os OEMs atualizam o código de versão do app de dados. O build captura automaticamente distro.zip, mas a nova versão do app de dados precisa ter um novo código de versão para ser reconhecida como nova e usada para substituir um app de dados pré-carregado ou instalado em um dispositivo por uma atualização anterior.

Ao criar o app de dados usando arquivos copiados de package/apps/TimeZoneData/oem_template/data_app, você pode encontrar o código/nome da versão aplicado ao APK no 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, os códigos da versão de teste precisam ser maiores do que a versão da imagem do sistema. Para mais detalhes, consulte o esquema de estratégia de código de versão de exemplo. Se o esquema de exemplo ou um esquema semelhante for usado, os códigos de versão de teste não precisarão ser atualizados, porque eles serão mais altos 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 o APK gerado, testam e lançam o APK:

• Para dispositivos não lançados (ou ao preparar uma atualização do sistema para um 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 é aprovado no CTS e em todos os 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ó pode ser lançado em uma app store.

Os OEMs são responsáveis pelo controle de qualidade e pelo teste do app de dados atualizado nos dispositivos antes do lançamento.

Estratégia de código da versão do app de dados

O app de dados precisa ter uma estratégia de versionamento adequada para garantir que os dispositivos recebam os APKs corretos. Por exemplo, se for recebida uma atualização do sistema com um APK mais antigo do que foi transferido por download na app store, a versão da app store precisará ser retida.

O código da versão do APK precisa incluir as seguintes informações:

• Versão do formato da distro (principal + secundária)
• Um número de versão incremental (opaco)

Atualmente, o nível da API da plataforma está fortemente relacionado à versão do formato da distro, porque cada nível da API geralmente é associado a uma nova versão do ICU, o que torna os arquivos da distro incompatíveis. No futuro, o Android poderá mudar isso para que um arquivo de distribuição possa funcionar em várias versões da plataforma Android (e o nível da API não seja usado no esquema de código da versão do app de dados).

Exemplo de estratégia de código de versão

Este exemplo de esquema de numeração de versões garante que as versões de formato de distribuição mais recentes substituam as versões de formato de distribuição mais antigas. O AndroidManifest.xml usa android:minSdkVersion para garantir que dispositivos antigos não recebam versões com um formato de distribuição mais recente do que o que eles podem processar.

Figura 6. Exemplo de estratégia de código de versão.

Exemplo	Valor	Objetivo
Y	Reservados	Permite esquemas alternativos/APKs de teste futuros. Inicialmente, é (implicitamente) 0. Como o tipo subjacente é um tipo int de 32 bits assinado, esse esquema oferece suporte a até duas revisões futuras do esquema de numeração.
01	Versão principal do formato	Rastreia a versão do formato principal de três dígitos decimais. O formato de distribuição suporta três dígitos decimais, mas apenas dois dígitos são usados aqui. É improvável que atinja 100, devido ao grande incremento esperado por nível de API. A versão principal 1 é equivalente ao nível 27 da API.
1	Versão secundária do formato	Rastreia a versão do formato de três dígitos decimais. O formato de distribuição oferece suporte a 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 de versão opaco	Número decimal alocado sob demanda. Inclui intervalos para permitir que as atualizações intersticiais sejam feitas, se necessário.

O esquema poderia ser melhor compactado se fosse usado um binário em vez de decimal, mas ele tem a vantagem de ser legível por humanos. Se o intervalo de números for esgotado, 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 exemplos na tabela a seguir.

#	Código da versão	minSdkVersion	{Major format version},{Minor format version},{IANA rules version},{Revision}
1	11000010	O-MR1	major=001,minor=001,iana=2017a,revision=1
2	21000010	P	major=002,minor=001,iana=2017a,revision=1
3	11000020	O-MR1	principal=001,secundária=001,iana=2017a,revision=2
4	11000030	O-MR1	major=001,minor=001,iana=2017b,revision=1
5	21000020	P	major=002,minor=001,iana=2017b,revision=1
6	11000040	O-MR1	major=001,minor=001,iana=2018a,revision=1
7	21000030	P	major=002,minor=001,iana=2018a,revision=1
8	1123456789	-	-
9	11000021	O-MR1	major=001,minor=001,iana=2017a,revision=2,respin=2

• Os exemplos 1 e 2 mostram duas versões de APK para a mesma versão da IANA de 2017a com diferentes versões principais de formato. 2 é numericamente maior que 1, o que é necessário para garantir que os dispositivos mais recentes recebam as versões de formato mais recente. A minSdkVersion garante que a versão P não será fornecida a dispositivos O.
• O exemplo 3 é uma revisão/correção do 1 e é numericamente maior que 1.
• Os exemplos 4 e 5 mostram as versões 2017b para O-MR1 e P. Como são numericamente mais recentes, elas substituem as versões anteriores da IANA/revisões do Android dos respectivos 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 do intervalo à esquerda entre 3 e 4 para girar o apk novamente.

Como cada dispositivo é enviado com um APK padrão e com a versão adequada na imagem do sistema, não há risco de uma versão O-MR1 ser instalada em um dispositivo P porque ela tem um número de versão menor do que uma versão da imagem do sistema P. Um dispositivo com uma versão O-MR1 instalada em /data que recebe uma atualização do sistema para P usa a versão /system em vez da versão O-MR1 em /data, porque a versão P é sempre mais recente do que qualquer app destinado ao O-MR1.

Criar o app de dados usando o tapas

Os OEMs são responsáveis por gerenciar a maioria dos aspectos do app de dados de fuso horário e configurar a imagem do sistema corretamente. O app Data foi criado com um build de tapas que produz APKs adequados para serem adicionados à imagem do sistema (para a versão inicial) e assinados e distribuídos por uma app store (para atualizações subsequentes).

O Tapas é uma versão simplificada do sistema de build do Android que usa uma árvore de origem reduzida para produzir versões distribuíveis de apps. Os OEMs que conhecem o sistema de build normal do Android vão reconhecer os arquivos de build do build normal da plataforma Android.

Criar o manifesto

Uma árvore de origem reduzida geralmente é alcançada com um arquivo de manifesto personalizado que se refere apenas aos projetos do Git necessários para o sistema de build e para criar o app. Depois de seguir as instruções em Como criar um app de dados, os OEMs precisam ter pelo menos dois projetos do Git específicos do OEM criados usando os arquivos de modelo em packages/apps/TimeZoneData/oem_template:

• Um projeto do Git contém arquivos do app, como o manifesto e os arquivos de build necessários para criar o arquivo APK do app (por exemplo, vendor/oem/apps/TimeZoneData). Esse projeto também contém regras de build para APKs de teste que podem ser usados por testes xTS.
• Um projeto do 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 do Git que são compartilhados com o build da plataforma ou contêm bibliotecas de código independentes de OEM.

O snippet de manifesto a seguir contém o conjunto mínimo de projetos do Git necessário para oferecer suporte a um build O-MR1 do app de dados de fuso horário. Os OEMs precisam adicionar os projetos do Git específicos do OEM (que normalmente incluem um projeto que contém o certificado de assinatura) a esse manifesto e podem configurar diferentes filiais de acordo.

   <!-- 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 do 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 de pré-criados para inclusão na imagem do sistema e/ou distribuídos por uma app store para dispositivos compatíveis.