Regras de fuso horário

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:

1. 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.
2. 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.
3. 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) usa tzdata e arquivos tzlookup.xml.
• Código de biblioteca nativa em bionic/ (por exemplo, para mktime, chamadas do sistema de horário local) usa o arquivo tzdata.
• 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/ e bionic/ usam as Cópia de /data de tzdata e tzlookup.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:

1. 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.

2. 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.

3. 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.

4. 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.
   . 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.
   
   

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

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:

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

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.

• 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.