O Google está comprometido em promover a equidade racial para as comunidades negras. Veja como.
Esta página foi traduzida pela API Cloud Translation.
Switch to English

Regras de fuso horário

O Android 10 descontinua o mecanismo de atualização de dados do fuso horário baseado em APK (disponível no Android 8.1 e Android 9) e o substitui por um mecanismo de atualização de módulo baseado em APEX . O AOSP continua a incluir o código da plataforma necessário para os OEMs habilitarem atualizações baseadas em APK, para que os dispositivos que atualizam para o Android 10 ainda possam receber atualizações de dados de fuso horário fornecidas pelo parceiro por meio do APK. No entanto, o mecanismo de atualização do APK não deve ser usado em um dispositivo de produção que também esteja recebendo atualizações de módulos, pois uma atualização baseada em APK substitui uma atualização baseada em APEX (ou seja, um dispositivo que recebeu uma atualização APK ignoraria as atualizações baseadas em APEX )

Atualizações de fuso horário (Android 10+)

O módulo Dados do fuso horário, compatível com o Android 10 e superior, atualiza o horário de verão (DST) e os fusos horários nos dispositivos Android, padronizando dados que podem ser alterados com frequência por motivos religiosos, políticos e geopolíticos.

As atualizações usam o seguinte processo:

  1. A IANA libera uma atualização do banco de dados de fuso horário libera uma atualização em resposta a um ou mais governos que alteram uma regra de fuso horário em seus países.
  2. O Google ou o parceiro Android prepara uma atualização do módulo Dados do fuso horário (arquivo APEX) contendo os fusos horários atualizados.
  3. O dispositivo do usuário final baixa a atualização, reinicia e aplica as alterações, após as quais os dados do fuso horário do dispositivo contêm os novos dados do fuso horário da atualização.

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

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

No Android 8.1 e no Android 9, os OEMs podem usar um mecanismo baseado em APK para enviar dados atualizados das regras de fuso horário para os dispositivos sem exigir uma atualização do sistema. Esse mecanismo permite que os usuários recebam atualizações oportunas (prolongando assim a vida útil de um dispositivo Android) e permite que os parceiros Android testem atualizações de fuso horário independentemente das atualizações de imagem do sistema.

A equipe de 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 optar por usar esses arquivos de dados ao criar atualizações de fuso horário para seus dispositivos ou podem criar seus próprios arquivos de dados, se preferir. Em todos os casos, os OEMs mantêm o controle sobre a garantia / teste de qualidade, tempo e lançamento de atualizações de regras de fuso horário para seus dispositivos suportados.

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 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 a partir libcore/ (por exemplo, java.util.TimeZone ) usa tzdata e tzlookup.xml arquivos.
  • O código da biblioteca nativa em bionic/ (por exemplo, para mktime , chamadas de sistema em tzdata ) usa o arquivo tzdata .
  • O código da biblioteca ICU4J / ICU4C em external/icu/ usa o arquivo .dat icu.

Essas bibliotecas controlam os 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 das regras de fuso horário, permitindo que os dispositivos sejam atualizados sem alterações /system .

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

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

Arquivos de distribuição

Os arquivos .zip 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 versão.

O formato do arquivo de distribuição depende da versão do Android, pois o conteúdo muda com a versão da ICU, os requisitos da plataforma Android e outras alterações na versão. O Android fornece arquivos de distribuição para as versões suportadas do Android para todas as atualizações da IANA (além de atualizar os arquivos do sistema da plataforma). Para manter seus dispositivos atualizados, os 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

Uma atualização de 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 instalação requer o seguinte:

  • Funcionalidade do serviço de plataforma ( timezone.RulesManagerService ), que está desativado por padrão. Os OEMs devem habilitar a funcionalidade através da configuração. RulesManagerService é executado no processo do servidor do sistema e RulesManagerService as operações de atualização do fuso horário gravando em /data/misc/zoneinfo/staged . RulesManagerService também pode substituir ou excluir operações já preparadas.
  • TimeZoneUpdater , um aplicativo de sistema não atualizável (também conhecido como aplicativo Updater ). Os OEMs devem incluir este aplicativo na imagem do sistema dos dispositivos que usam o recurso.
  • OEM TimeZoneData , um aplicativo de sistema atualizável (também conhecido como aplicativo de dados ) que carrega arquivos de distribuição para o dispositivo e os disponibiliza para o aplicativo Updater. Os OEMs devem incluir este aplicativo na imagem do sistema dos 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 optar por usar sem modificação. O código de teste é fornecido para permitir que os OEMs verifiquem automaticamente se eles ativaram o recurso corretamente.

Instalação da distribuição

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

  1. O aplicativo de dados é atualizado por meio de um download ou carregamento lateral da loja de aplicativos. O processo do servidor do sistema (por meio das classes timezone.RulesManagerServer/timezone.PackageTracker ) procura alterações no nome do pacote de aplicativos de dados, específico do OEM, configurado.

    Atualizações de aplicativos de dados
    Figura 1. Atualizações do aplicativo de dados
  2. O processo do servidor do sistema aciona uma verificação de atualização transmitindo uma intenção direcionada com um token de uso único e exclusivo para o Aplicativo Atualizador. O servidor do sistema controla o token mais recente gerado, para que possa determinar quando a verificação mais recente acionada foi concluída; quaisquer outros tokens são ignorados.

    Acionar atualização
    Figura 2. Trigger update check
  3. Durante a verificação da atualização , o aplicativo Updater executa as seguintes tarefas:
    • Consulta o estado atual do dispositivo chamando o RulesManagerService.

      Call RulesManagerService
      Figura 3. Atualizações do aplicativo de dados, chamando RulesManagerService
    • Consulta o aplicativo Data consultando uma URL do ContentProvider bem definida e especificações de coluna para obter informações sobre a distribuição.

      Obter informações da distribuição
      Figura 4. Atualizações de aplicativos de dados, obtenha informações sobre distribuição
  4. O aplicativo Updater executa a ação apropriada com base nas informações que possui. As ações disponíveis incluem:
    • Solicite uma instalação. Os dados de distribuição são lidos no aplicativo Data e transmitidos para o RulesManagerService no servidor do sistema. O RulesManagerService confirma novamente que a versão e o conteúdo do formato de distribuição são apropriados para o dispositivo e preparam a instalação.
    • Solicite 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 .
    • Fazer nada. Ocorre quando a distribuição do aplicativo de dados é considerada inválida.
    Em todos os casos, o aplicativo 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.

    Verificação completa
    Figura 5. Verificação completa
  5. Reinicialize e tzdatacheck. Quando o dispositivo for inicializado, o binário tzdatacheck executa qualquer operação em estágios. O binário tzdatacheck pode executar as seguintes tarefas:
    • Execute a operação faseada manipulando a criação, substituição e / ou exclusão dos /data/misc/zoneinfo/current antes que outros componentes do sistema sejam abertos e iniciados o uso dos 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 se a versão do formato de distribuição foi alterada.
    • Verifique se a versão das regras da IANA é a mesma ou mais recente que a versão em /system . Isso protege contra uma atualização do sistema, deixando 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 da instalação esteja incompleta. Na melhor das hipóteses, o aplicativo Updater informa o servidor do sistema que não teve êxito; no pior caso malsucedido, o RulesManagerService não recebe nenhuma chamada.

Para lidar com isso, o código do servidor do sistema controla se uma verificação de atualização acionada foi concluída e qual é o último código da versão verificada do Data App. Quando o dispositivo está ocioso e carregando, o código do servidor do sistema pode verificar o estado atual. Se descobrir uma verificação de atualização incompleta ou uma versão inesperada do aplicativo de dados, ele disparará espontaneamente uma verificação de atualização.

Segurança

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

  • Problemas que indicam uma imagem do sistema mal configurada impedem a inicialização do dispositivo; exemplos incluem uma configuração incorreta do aplicativo Updater ou Data ou o aplicativo Updater ou Data não está em /system/priv-app .
  • Os problemas que indicam que um aplicativo 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 necessárias do sistema ou o aplicativo Data 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 as regras do SELinux. Como em qualquer APK, o aplicativo Data deve ser assinado pela mesma chave usada para assinar a versão /system/priv-app . Espera-se que o aplicativo Data tenha um nome e uma chave dedicados e específicos de OEM.

Integrando atualizações de fuso horário

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

  • Crie seu próprio aplicativo de dados.
  • Inclua os aplicativos Atualizador e Dados na criação da imagem do sistema.
  • Configure o servidor do sistema para ativar o RulesManagerService.

Preparando

Antes de iniciar, os OEMs devem revisar as seguintes considerações de política, garantia de qualidade e segurança:

  • Crie uma chave de assinatura específica de aplicativo dedicada para o aplicativo de dados.
  • Crie uma estratégia de versão e versão para atualizações de fuso horário para entender quais dispositivos serão atualizados e como eles podem garantir que as atualizações sejam instaladas apenas nos dispositivos que precisam deles. Por exemplo, os OEMs podem querer ter um único aplicativo de dados para todos os seus dispositivos ou podem optar por ter aplicativos de dados diferentes para diferentes dispositivos. 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 desejam usar dados de fuso horário do Android da AOSP ou criar seus próprios.

Criando um aplicativo de dados

O AOSP inclui todo o código-fonte e regras de criação necessárias para criar um aplicativo 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 criação para o APK real do aplicativo de dados e destinos extras para criar versões de teste do aplicativo de dados.

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

O aplicativo Data deve ser criado com uma compilação de tapas que produz APKs adequados para serem adicionados à imagem do sistema (para a versão inicial) e assinados e distribuídos por meio de uma loja de aplicativos (para atualizações subsequentes). Para obter detalhes sobre o uso de tapas, consulte Construindo o aplicativo Dados usando tapas .

Os OEMs devem instalar o aplicativo Dados pré-criado na imagem do sistema de um dispositivo em /system/priv-app . Para incluir APKs pré-criados (gerados pelo processo de criação 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 criação para incluir versões de teste do aplicativo Data em suítes de teste.

Incluindo os aplicativos Updater e Data na imagem do sistema

Os OEMs devem colocar os APKs do aplicativo Atualizador e Dados no diretório /system/priv-app da imagem do sistema. Para fazer isso, a criação da imagem do sistema deve incluir explicitamente os destinos pré-construídos do aplicativo Updater e do aplicativo Data.

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

Configurando o Servidor do Sistema

Para habilitar 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 Substituir Necessário?
config_enableUpdateableTimeZoneRules
Deve ser definido como true para ativar o RulesManagerService. sim
config_timeZoneRulesUpdateTrackingEnabled
Deve ser definido como true para que o sistema aguarde alterações no aplicativo Data. sim
config_timeZoneRulesDataPackage
Nome do pacote do aplicativo de dados específico do OEM. sim
config_timeZoneRulesUpdaterPackage
Configurado para o aplicativo Updater padrão. Altere apenas ao fornecer uma implementação de aplicativo Updater diferente. Não
config_timeZoneRulesCheckTimeMillisAllowed
Tempo permitido entre uma verificação de atualização ser acionada pelo RulesManagerService e uma instalação, desinstalação ou resposta sem resposta. Após esse ponto, um gatilho de confiabilidade espontâneo pode ser gerado. Não
config_timeZoneRulesCheckRetryCount
O número de verificações seqüenciais sem êxito de atualização permitidas antes que o RulesManagerService pare de gerar mais. Não

As substituições de configuração devem estar na imagem do sistema (não no fornecedor ou em outro), pois 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 aplicativo de Dados (ou com diferentes nomes de pacotes do aplicativo de aplicativos / Atualizador de dados) seria considerada uma configuração incorreta.

teste xTS

O xTS refere-se a qualquer conjunto de testes específico do OEM que seja semelhante aos conjuntos de testes padrão do Android usando o Tradefed (como CTS e VTS). Os OEMs que possuem esses conjuntos de testes 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 o teste funcional automatizado básico.
  • packages/apps/TimeZoneData/oem_template/xts contém uma estrutura de diretório de amostra para incluir testes em um conjunto xTS do tipo Tradefed. Como em outros diretórios de modelos, os OEMs devem copiar e personalizar de acordo com suas necessidades.
  • packages/apps/TimeZoneData/oem_template/data_app_prebuilt contém configuração em tempo de compilação para incluir os APKs de teste pré-compilados exigidos pelo teste.

Criando 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 os lançamentos no AOSP. Os OEMs que usam o sistema Android padrão e os arquivos de distribuição podem pegar esses commits, usá-los para criar uma nova versão do aplicativo de dados e liberar a nova versão para atualizar seus dispositivos em produção.

Como os aplicativos de dados contêm arquivos de distribuição intimamente vinculados às versões do Android, os OEMs devem criar uma nova versão do aplicativo de dados para cada versão do Android suportada que um OEM deseja atualizar. Por exemplo, se um OEM quiser fornecer atualizações para os dispositivos Android 8.1, 9 e 10, ele deverá concluir o processo três vezes.

Etapa 1: Atualizando arquivos de dados do sistema / fuso horário e externos / icu

Nesta etapa, os OEMs avaliam as confirmações do Android para system/timezone e external/icu das ramificações release -dev no AOSP e aplicam essas confirmações à sua cópia do código-fonte do Android.

O patch do sistema / fuso horário do AOSP contém arquivos atualizados em system/timezone/input_data e system/timezone/output_data . Os OEMs que precisam fazer correções locais adicionais podem modificar os arquivos de entrada e, em seguida, 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 aplicativo Data é criado.

Etapa 2: atualizando o código da versão do aplicativo Data

Nesta etapa, os OEMs atualizam o código da versão do aplicativo Dados. A compilação pega automaticamente o distro.zip , mas a nova versão do aplicativo Data deve ter um novo código de versão para que seja reconhecido como novo e seja usado para substituir um aplicativo Data pré-carregado ou um aplicativo Data instalado em um dispositivo por uma atualização anterior.

Ao criar o aplicativo Dados usando arquivos copiados do package/apps/TimeZoneData/oem_template/data_app , você pode encontrar o código da versão / 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 devem ser maiores que a versão da imagem do sistema). Para detalhes, consulte o exemplo de esquema de estratégia de código de versão ; se o esquema de exemplo ou um esquema semelhante for usado, os códigos de versão de teste não precisam ser atualizados porque eles garantem que são maiores que os códigos de versão reais.

Etapa 3: Reconstruindo, assinando, testando e liberando

Nesta etapa, os OEMs recriam o APK usando tapas, assinam o APK gerado e testam e liberam 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 aplicativo Data para garantir que a imagem do sistema e os testes xTS tenham os APKs mais recentes. Os OEMs devem testar se o novo arquivo funciona corretamente (ou seja, passa no CTS e em qualquer teste automatizado e manual específico do OEM).
  • Para dispositivos lançados que não recebem mais atualizações do sistema, o APK assinado pode ser liberado apenas por meio de uma loja de aplicativos.

Os OEMs são responsáveis ​​pela garantia da qualidade e pelo teste do aplicativo Data atualizado em seus dispositivos antes do lançamento.

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

O aplicativo Dados deve ter uma estratégia de versão adequada para garantir que os dispositivos recebam os APKs corretos. Por exemplo, se for recebida uma atualização do sistema que contenha um APK mais antigo do que o baixado da loja de aplicativos, a versão da loja de aplicativos deverá ser mantida.

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

  • Versão no formato distro (maior + menor)
  • Um número de versão incrementado (opaco)

Atualmente, o nível da API da plataforma está fortemente correlacionado à versão no formato de distribuição, pois cada nível de API geralmente está associado a uma nova versão do ICU (o que torna os arquivos de distribuição incompatíveis). No futuro, o Android poderá alterar 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 é usado no esquema de código de versão do aplicativo Data).

Estratégia de código de versão de exemplo

Este exemplo de esquema de número de versão garante que versões superiores de formato distro substituam versões inferiores de formato distro. AndroidManifest.xml usa android:minSdkVersion para garantir que os dispositivos antigos não recebam versões com uma versão em formato de distro mais alta do que podem suportar.

Verificação de versão
Figura 6. Exemplo de estratégia de código de versão
Exemplo Valor Objetivo
Y Reservado Permite futuros esquemas alternativos / teste de APKs. É inicialmente (implicitamente) 0. Como o tipo subjacente é um tipo int assinado de 32 bits, esse esquema suporta até duas revisões futuras do esquema de numeração.
01 Versão principal do formato Rastreia a versão do formato principal de 3 dígitos decimais. O formato da distribuição suporta 3 dígitos decimais, mas apenas 2 dígitos são usados ​​aqui. É improvável que atinja 100, devido ao grande incremento esperado por nível da API. A versão principal 1 é equivalente ao nível 27 da API.
1 Versão secundária Rastreia a versão de formato secundário de 3 dígitos decimais. O formato da distribuição suporta 3 dígitos decimais, mas apenas 1 dígito é usado aqui. É improvável que chegue a 10.
X Reservado É 0 para liberações de produção (e pode ser diferente para APKs de teste).
ZZZZZ Número da versão opaca Número decimal alocado sob demanda. Inclui lacunas para permitir atualizações intersticiais, se necessário.

O esquema poderia ser melhor compactado se o binário fosse usado em vez do decimal, mas esse esquema tem a vantagem de ser legível por humanos. Se o intervalo completo de números estiver esgotado, o nome do pacote do aplicativo Dados poderá ser alterado.

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 . Exemplos são mostrados na tabela a seguir.

# Código da versão minSdkVersion {Versão no formato principal}, {Versão no formato secundário}, {Versão das regras da IANA}, {Revisão}
1 11000010 O-MR1 major = 001, minor = 001, iana = 2017a, revisão = 1
2 21000010 P major = 002, minor = 001, iana = 2017a, revisão = 1
3 11000020 O-MR1 major = 001, minor = 001, iana = 2017a, revisão = 2
4 11000030 O-MR1 major = 001, minor = 001, iana = 2017b, revisão = 1
5 21000020 P major = 002, minor = 001, iana = 2017b, revisão = 1
6 11000040 O-MR1 major = 001, minor = 001, iana = 2018a, revisão = 1
7 21000030 P major = 002, minor = 001, iana = 2018a, revisão = 1
8 1123456789 - -
9 11000021 O-MR1 major = 001, minor = 001, iana = 2017a, revisão = 2, respin = 2
  • Os exemplos 1 e 2 mostram duas versões do APK para a mesma versão 2017a da IANA com diferentes versões dos principais formatos. 2 é numericamente maior que 1, o que é necessário para garantir que os dispositivos mais novos recebam as versões de formato mais altas. O minSdkVersion garante que a versão P não seja fornecida aos dispositivos O.
  • O exemplo 3 é uma revisão / correção para 1 e é numericamente maior que 1.
  • Os exemplos 4 e 5 mostram os lançamentos de 2017b para O-MR1 e P. Por serem numericamente mais altos, eles substituem os lançamentos anteriores da IANA / revisões do Android de seus respectivos antecessores.
  • Os exemplos 6 e 7 mostram os lançamentos 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 espaço deixado entre 3 e 4 para girar novamente o apk.

Como cada dispositivo é fornecido com um APK com versão adequada e padrão na imagem do sistema, não há risco de uma versão O-MR1 ser instalada em um dispositivo P, pois possui um número de versão inferior ao da 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 preferência à versão O-MR1 em /data porque a versão P é sempre maior do que qualquer aplicativo destinado a O- MR1.

Construindo o aplicativo Dados usando tapas

Os OEMs são responsáveis ​​pelo gerenciamento da maioria dos aspectos do aplicativo Dados do fuso horário e pela configuração correta da imagem do sistema. O aplicativo Data deve ser desenvolvido com uma compilação de tapas que produz APKs adequados para serem adicionados à imagem do sistema (para a versão inicial) e assinados e distribuídos por meio de uma loja de aplicativos (para atualizações subsequentes).

Tapas é uma versão reduzida do sistema de compilação Android que usa uma árvore de fontes reduzida para produzir versões distribuíveis de aplicativos. Os OEMs familiarizados com o sistema de compilação normal do Android devem reconhecer os arquivos de compilação da compilação normal da plataforma Android.

Criando 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 ao sistema de compilação e para compilar o aplicativo. Após seguir as instruções em Criando um aplicativo de dados , os OEMs devem ter pelo menos dois projetos Git específicos do OEM criados usando os arquivos de modelo em packages/apps/TimeZoneData/oem_template :

  • Um projeto Git contém arquivos de aplicativos, como o manifesto e os arquivos de compilação necessários para criar o arquivo APK do aplicativo (por exemplo, vendor/ oem /apps/TimeZoneData ). Este projeto também contém regras de compilação para APKs de teste que podem ser usadas pelos testes xTS.
  • Um projeto Git contém os APKs assinados produzidos pela compilação do aplicativo para inclusão na compilação da imagem do sistema e nos testes xTS.

A criação do aplicativo utiliza vários outros projetos Git que são compartilhados com a construção da plataforma ou contêm bibliotecas de códigos independentes do OEM.

O fragmento de manifesto a seguir contém o conjunto mínimo de projetos Git necessários para suportar uma compilação O-MR1 do aplicativo Dados do fuso horário. Os OEMs devem adicionar seus 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.

   <!-- 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="master"
        clone_depth="1" />
    <repo-hooks
        in-project="platform/tools/repohooks"
        enabled-list="pre-upload" />

Executando a Construção de Tapas

Depois que a árvore de origem for estabelecida, chame a construção de 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 compilação 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 através de uma loja de aplicativos para dispositivos compatíveis.