Regras de fuso horário

O Android 10 descontinua o mecanismo de atualização de dados de fuso horário com base em APK (disponível no Android 8.1 e no Android 9) e o substitui por um mecanismo de atualização de módulo com base em APEX. O AOSP 8.1 a 13 ainda inclui o código da plataforma necessário para que os OEMs ativem atualizações baseadas em APK. Assim, os dispositivos que fizerem upgrade para o Android 10 ainda poderão receber atualizações de dados de fuso horário fornecidas por parceiros via APK. No entanto, o mecanismo de atualização de APK não deve ser usado em um dispositivo de produção que também está recebendo atualizações de módulo, já que uma atualização baseada em APK substitui uma atualização baseada em APEX. Ou seja, um dispositivo que recebeu 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 compatível com o Android 10 e versões mais recentes atualiza o horário de verão 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 usam o seguinte processo:

1. A IANA lança uma atualização do banco de dados de fusos horários em resposta a um ou mais governos que mudam uma regra de fuso horário nos respectivos países.
2. O Google ou o parceiro Android prepara uma atualização do módulo de dados de fuso horário (arquivo APEX) com os fusos horários atualizados.
3. O dispositivo do usuário final baixa a atualização, reinicia e aplica as mudanças. Depois disso, os dados de fuso horário do dispositivo contêm as novas informações da atualização.

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

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

Observação:o recurso de mecanismo de atualização de dados de fuso horário com base em APK foi totalmente removido do Android 14 em diante e não pode ser encontrado no código-fonte. Os parceiros precisam migrar totalmente para o módulo principal de 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 (estendendo a vida útil de um dispositivo Android) e que os parceiros do Android testem atualizações de fuso horário independentemente das atualizações da imagem do sistema.

A equipe das bibliotecas principais 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 das atualizações de regras de fuso horário para os dispositivos compatíveis.

Código-fonte e dados de 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 devem 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 localtime) usa o arquivo tzdata.
• O código da biblioteca ICU4J/ICU4C em external/icu/ usa o arquivo icu .dat.

Essas bibliotecas rastreiam arquivos de sobreposição que podem estar presentes no diretório /data/misc/zoneinfo/current. Espera-se que os arquivos de sobreposição contenham dados aprimorados de regras de fuso horário, 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:

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

Arquivos de distribuição

Os arquivos .zip da distribuição 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 do 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 compatíveis do Android em todas as atualizações 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 nele. A transferência e a instalação exigem o seguinte:

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

Instalação da distribuição

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

1. O app de dados é atualizado por um download da app store ou por sideload. O processo do servidor do sistema (por meio de classes timezone.RulesManagerServer/timezone.PackageTracker) monitora 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 ao transmitir uma intent direcionada com um token exclusivo de uso único para o app Updater. O servidor do sistema acompanha o token mais recente gerado para determinar quando a verificação mais recente acionada foi concluída. Outros tokens são ignorados.
   
   

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

3. Durante a verificação de atualização, o app Updater realiza as seguintes tarefas:
   • Consulta o estado atual do dispositivo chamando o RulesManagerService.
     
     

     Figura 3. Atualizações do app de dados, chamando RulesManagerService.

   • Consulta o app Data consultando um URL ContentProvider bem definido e especificações de coluna para receber informações sobre a distribuição.
     
     

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

4. O app Updater toma a ação adequada com base nas informações que tem. As ações disponíveis incluem:
   • Solicite uma instalação. Os dados de distribuição são lidos do app Dados e transmitidos para o RulesManagerService no servidor do sistema. O RulesManagerService reconfirma que a versão e o conteúdo do formato de distribuição são adequados para o dispositivo e prepara 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 voltando para a versão presente em /system.
   • Não fazer nada: Ocorre quando a distribuição do app Data é considerada inválida.
   Em todos os casos, o app Updater chama o RulesManagerService com o token de verificação para que o servidor do sistema saiba que a verificação foi concluída e bem-sucedida.
   
   

   Figura 5. Verificação concluída.

5. Reinicialize e execute tzdatacheck. Na próxima vez que o dispositivo for inicializado, o binário tzdatacheck vai executar qualquer operação em estágio. O binário tzdatacheck pode realizar as seguintes tarefas:
   • Execute a operação em etapas processando a criação, substituição e/ou exclusão dos arquivos /data/misc/zoneinfo/current antes que outros componentes do sistema tenham aberto e começado a usar os arquivos.
   • Verifique se os arquivos em /data estão corretos para a versão atual da plataforma. Isso pode não acontecer se o dispositivo tiver recebido uma atualização do sistema e a versão do formato de distribuição tiver mudado.
   • Verifique se a versão das regras da IANA é igual ou mais recente 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. Em 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 da instalação fique incompleta. No melhor caso sem sucesso, o app Updater informa ao servidor do sistema que não foi possível concluir a ação. No pior caso, o RulesManagerService não recebe nenhuma chamada.

Para lidar com isso, o código do servidor do sistema acompanha se uma verificação de atualização acionada foi concluída e qual foi 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 espontaneamente.

Segurança

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

• Problemas que indicam uma imagem do sistema mal configurada impedem a inicialização de um dispositivo. Por exemplo, uma configuração ruim do app Updater ou Data ou a ausência do app Updater ou Data em /system/priv-app.
• Problemas que indicam a instalação de um app de dados ruim não impedem a inicialização de um dispositivo, mas impedem que uma verificação de atualização seja acionada. Exemplos incluem a falta de permissões de sistema necessárias ou o app de dados não expor 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 em qualquer APK, o app de dados precisa ser assinado com a mesma chave usada para assinar a versão /system/priv-app. O app Data precisa ter um nome de pacote e uma chave dedicados e específicos do OEM.

Integrar atualizações de fuso horário

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

• Criar um app de dados próprio.
• Inclua os apps Updater e Data no build da imagem do sistema.
• Configure o servidor do sistema para ativar o RulesManagerService.

Preparação

Antes de começar, os OEMs precisam analisar as seguintes considerações sobre política, controle de qualidade e segurança:

• Crie uma chave de assinatura dedicada específica do app para o app de dados.
• Crie uma estratégia de lançamento e controle de versões para atualizações de fuso horário e entenda 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 Dados para todos os dispositivos ou escolher ter apps 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.
• Entenda se eles querem usar dados de fuso horário do Android padrão do AOSP ou criar os próprios.

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. Exemplos de modelos incluem um destino de build para o APK do app Data real e destinos extras para criar versões de teste do app Data.

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

O app Data foi criado com um build tapas que produz APKs adequados para serem adicionados à imagem do sistema (para o lançamento inicial) e assinados e distribuídos por uma app store (para atualizações posteriores). Para detalhes sobre como usar tapas, consulte Como criar o app de dados usando tapas.

Os OEMs precisam instalar o app Dados pré-criado na imagem do sistema de um dispositivo em /system/priv-app. Para incluir APKs pré-criados (gerados pelo processo de build do 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 app Updater e Data no diretório /system/priv-app da imagem do sistema. Para isso, o build da imagem do sistema precisa incluir explicitamente o app Updater e os destinos pré-criados do app Data.

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.

config_enableUpdateableTimeZoneRules

config_timeZoneRulesUpdateTrackingEnabled

config_timeZoneRulesDataPackage

config_timeZoneRulesUpdaterPackage

config_timeZoneRulesCheckTimeMillisAllowed

config_timeZoneRulesCheckRetryCount

As substituições de configuração precisam estar na imagem do sistema (não do fornecedor ou de outro tipo), já que um dispositivo mal configurado 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 app de dados/atualizador diferentes) será considerada uma configuração incorreta.

Teste do xTS

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

• O packages/apps/TimeZoneData/testing/xts inclui o código necessário para testes funcionais automatizados básicos.
• packages/apps/TimeZoneData/oem_template/xts contém uma estrutura de diretório de amostra para incluir testes em um pacote xTS semelhante ao Tradefed. Assim como acontece com outros diretórios de modelos, espera-se que os OEMs copiem e personalizem de acordo com as necessidades.
• 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 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, a equipe das bibliotecas principais do Android gera patches para atualizar as versões no AOSP. Os OEMs que usam o sistema Android padrão e arquivos de distribuição podem coletar esses commits, usá-los para criar uma nova versão do app Dados e lançar essa versão para atualizar os dispositivos em produção.

Como os apps de dados contêm arquivos de distribuição intimamente ligados às versões do Android, os OEMs precisam criar uma nova versão do app de dados para cada lançamento do Android compatível 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 arquivos de dados do sistema/fuso horário e externos/icu

Nesta etapa, os OEMs usam commits do Android system/timezone e external/icu das ramificações release-dev no AOSP e aplicam esses commits à cópia do código-fonte do Android.

O patch do AOSP system/timezone contém arquivos atualizados em system/timezone/input_data e system/timezone/output_data. Os OEMs que precisam fazer mais 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 Dados é criado.

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

Nesta etapa, os OEMs atualizam o código da versão do app Dados. O build seleciona automaticamente distro.zip, mas a nova versão do app Dados precisa ter um novo código de versão para ser reconhecida como nova e usada para substituir um app 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ê encontra o código da 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, os códigos de versão de teste precisam ser maiores 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 semelhante for usado, não será necessário atualizar os códigos de versão de teste porque eles serão maiores 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 e depois 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 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 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 pode ser lançado apenas por uma app store.

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

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

O app Data precisa ter uma estratégia de controle de versões adequada para garantir que os dispositivos recebam os APKs corretos. Por exemplo, se uma atualização do sistema for recebida com um APK mais antigo do que um baixado da app store, a versão da app store será mantida.

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

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

No momento, o nível de 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 do ICU (que torna os arquivos de distribuição incompatíveis). No futuro, o Android poderá mudar isso para que um arquivo de distribuição funcione 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

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

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

O esquema poderia ser compactado melhor se o binário fosse usado em vez do decimal, mas ele tem a vantagem de ser legível para humanos. Se o intervalo de números completo for esgotado, o nome do pacote do app Dados poderá mudar.

O nome da versão é uma representação legível por humanos dos detalhes, por exemplo, major=001,minor=001,iana=2017a, revision=1,respin=2. Confira exemplos na tabela a seguir.

• Os exemplos 1 e 2 mostram duas versões de APK para o mesmo lançamento da IANA 2017a com diferentes versões principais de formato. 2 é numericamente maior que 1, o que é necessário para garantir que os dispositivos mais novos recebam as versões de formato mais recentes. O minSdkVersion garante que a versão P não seja fornecida a dispositivos O.
• O exemplo 3 é uma revisão/correção do exemplo 1 e é numericamente maior que 1.
• Os exemplos 4 e 5 mostram as versões de 2017b para O-MR1 e P. Por serem numericamente mais altas, elas substituem versões anteriores da IANA/revisões do Android dos respectivos predecessores.
• 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 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 de 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 tapas

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

O Tapas é uma versão reduzida do sistema de build do Android que usa uma árvore de origem reduzida para produzir versões distribuíveis de apps. Os OEMs familiarizados com 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 Git necessários pelo sistema de build e para a criação do app. Depois de seguir as instruções em Criar um app de dados, os OEMs precisam ter pelo menos dois projetos Git específicos do OEM criados usando os arquivos de modelo em packages/apps/TimeZoneData/oem_template:

• Um projeto do Git contém arquivos de 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 usa vários outros projetos do Git compartilhados com o build da plataforma ou que contêm bibliotecas de código independentes do OEM.

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

   <!-- 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

Uma build bem-sucedida gera arquivos no diretório out/dist para teste. Esses arquivos podem ser colocados no diretório prebuilts para inclusão na imagem do sistema e/ou distribuídos por uma app store para dispositivos compatíveis.