Google 致力于为黑人社区推动种族平等。查看具体举措
Esta página foi traduzida pela API Cloud Translation.
Switch to English

Regras de fuso horário

O Android 10 desativa o mecanismo de atualização de dados de 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 de plataforma necessário para que os OEMs habilitem atualizações baseadas em APK, para que os dispositivos que estejam fazendo upgrade 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 está recebendo atualizações do módulo, pois 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 as atualizações baseadas em APEX )

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

O módulo Time Zone Data com suporte no Android 10 e superior atualiza o horário de verão (DST) e os fusos horários em dispositivos Android, padronizando os dados que podem mudar com frequência por motivos religiosos, políticos e geopolíticos.

As atualizações usam o seguinte processo:

  1. IANA lança uma atualização para o banco de dados de fuso horário lança uma atualização em resposta a um ou mais governos alterando uma regra de fuso horário em seus países.
  2. O Google ou o parceiro Android prepara uma atualização do módulo Time Zone Data (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 o que os dados de fuso horário do dispositivo contêm os novos dados de fuso horário da atualização.

Para obter 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 Android 9, os OEMs podem usar um mecanismo baseado em APK para enviar dados atualizados de regras de fuso horário para dispositivos sem exigir uma atualização do sistema. Esse mecanismo permite que os usuários recebam atualizações oportunas (estendendo 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 escolher 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 de estoque, 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 entã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 chamadas de sistema mktime , localtime) usa o arquivo tzdata .
  • O código da biblioteca ICU4J / ICU4C em external/icu/ usa o arquivo icu .dat .

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 de regras de fuso horário, permitindo assim que os dispositivos sejam atualizados sem alterar o /system .

Os componentes do sistema Android que precisam de dados de 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, strings localizadas, etc.).

Arquivos de distro

Os arquivos .zip distro contêm os arquivos de dados necessários para preencher o diretório /data/misc/zoneinfo/current . Os arquivos da distro também contêm metadados que permitem que os dispositivos detectem problemas de versão.

O formato do arquivo de distro depende do lançamento do Android porque o conteúdo muda com a versão ICU, requisitos da plataforma Android e outras mudanças de lançamento. 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 de sistema da plataforma). Para manter seus dispositivos atualizados, os OEMs podem usar esses arquivos de distro ou criar seus próprios usando a árvore de origem do Android (que contém os scripts e outros arquivos necessários para gerar os arquivos de distro).

Componentes de atualização de 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 a instalação requerem o seguinte:

  • Funcionalidade de serviço da plataforma ( timezone.RulesManagerService ), que é desabilitada por padrão. Os OEMs devem habilitar a funcionalidade por meio da configuração. RulesManagerService é executado no processo do servidor do sistema e organiza as operações de atualização de 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 distro 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 inicialização necessário para a operação correta e segura de 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 escolher para usar sem modificação. O código de teste é fornecido para permitir que os OEMs verifiquem automaticamente se ativaram o recurso corretamente.

Instalação de distro

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

  1. O aplicativo de dados é atualizado por meio de um download da app store ou sideload. O processo do servidor do sistema (por meio das classes timezone.RulesManagerServer/timezone.PackageTracker ) observa as alterações no nome do pacote de aplicativo de dados específico do OEM configurado.

    Atualizações do aplicativo de dados
    Figura 1. Atualizações do aplicativo de dados
  2. O processo do servidor do sistema aciona uma verificação de atualização ao transmitir uma intenção direcionada com um token único de uso único para o aplicativo Updater. O servidor do sistema mantém registro do token mais recente que gerou para que possa determinar quando a verificação mais recente que ele disparou foi concluída; quaisquer outros tokens são ignorados.

    Atualização do gatilho
    Figura 2. Verificação de atualização do gatilho
  3. Durante a verificação de atualização , o aplicativo Updater executa as seguintes tarefas:
    • Consulta o estado atual do dispositivo chamando RulesManagerService.

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

      Obtenha informações sobre a distro
      Figura 4. Atualizações do aplicativo de dados, obter informações sobre a distro
  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 da distro são lidos no aplicativo de dados e passados ​​para o RulesManagerService no servidor do sistema. O RulesManagerService reconfirma que a versão e o conteúdo do formato da distro são apropriados para o dispositivo e organiza a instalação.
    • Solicite uma desinstalação (isso é raro). Por exemplo, se o APK atualizado em /data estiver sendo desabilitado 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. Na próxima inicialização do dispositivo, o binário tzdatacheck executa qualquer operação em estágios. O binário tzdatacheck pode realizar as seguintes tarefas:
    • Execute a operação em estágios tratando da criação, substituição e / ou exclusão dos /data/misc/zoneinfo/current antes que outros componentes do sistema tenham aberto e comecem a usar os arquivos.
    • Verifique se os arquivos em /data estão corretos para a versão da plataforma atual, 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 distro mudou.
    • Certifique-se de que a versão das regras da IANA seja a mesma 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 sistema operacional. A qualquer momento durante a instalação, o dispositivo pode ficar sem energia, ficar sem espaço em disco ou encontrar outros problemas, fazendo com que a verificação da instalação seja incompleta. Na melhor das hipóteses de falha, o aplicativo Updater informa ao servidor do sistema que não foi bem-sucedido; no pior caso de 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 de versão verificado do aplicativo de dados. Quando o dispositivo está ocioso 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 aplicativo de dados, ele acionará 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 é seguro para uso.

  • Problemas que indicam uma imagem do sistema mal configurada impedem a inicialização do dispositivo; exemplos incluem uma configuração de aplicativo de dados ou atualizador incorreta ou o atualizador ou aplicativo de dados não está em /system/priv-app .
  • Problemas que indicam que um aplicativo de dados inválido foi instalado não impedem a inicialização do dispositivo, mas evitam que uma verificação de atualização seja acionada; os exemplos incluem a falta de permissões de sistema necessárias ou o aplicativo 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 as regras SELinux. Como acontece com qualquer APK, o aplicativo de dados deve ser assinado com a mesma chave usada para assinar a versão /system/priv-app . Espera-se que o aplicativo de dados tenha um nome de pacote e uma chave dedicados e específicos do OEM.

Integração de atualizações de fuso horário

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

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

Preparando

Antes de começar, os OEMs devem revisar a seguinte política, garantia de qualidade e considerações de segurança:

  • Crie uma chave de assinatura específica de aplicativo dedicada para seu aplicativo de dados.
  • Crie uma estratégia de lançamento e controle de 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 delas. 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 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 QA.
  • Entenda se eles desejam usar dados de fuso horário do Android do AOSP ou criar seus próprios.

Criação de um aplicativo de dados

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

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

O aplicativo de dados deve ser construído com uma versão 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 como usar tapas, consulte Construindo o aplicativo de Dados usando tapas .

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

Incluindo os aplicativos Updater e Data na imagem do sistema

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

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 o pré-desenvolvimento.

Configurando 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
Deve ser definido como true para ativar o RulesManagerService. sim
config_timeZoneRulesUpdateTrackingEnabled
Deve ser definido como true para que o sistema escute as alterações no aplicativo de dados. 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 diferente do aplicativo Updater. Não
config_timeZoneRulesCheckTimeMillisAllowed
Tempo permitido entre uma verificação de atualização disparada pelo RulesManagerService e uma resposta de instalação, desinstalação ou não fazer nada. Após este ponto, um gatilho de confiabilidade espontâneo pode ser gerado. Não
config_timeZoneRulesCheckRetryCount
O número de verificações de atualização malsucedidas sequenciais permitidas antes que RulesManagerService pare de gerar mais. Não

As substituições de configuração devem estar na imagem do sistema (não do fornecedor ou outro), pois um dispositivo mal configurado pode se recusar a inicializar. Se as substituições de configuração estivessem na imagem do fornecedor, a atualização para uma imagem do sistema sem um aplicativo de dados (ou com nomes de pacote de aplicativo de dados / Updater diferentes) seria considerada uma configuração incorreta.

teste xTS

xTS refere-se a qualquer suíte de teste específica do OEM que seja semelhante a suítes de teste padrão do Android usando Tradefed (como CTS e VTS). Os OEMs que possuem tais suítes 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 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 pacote xTS do tipo Tradefed. Como acontece com outros diretórios de modelos, espera-se que os OEMs copiem e personalizem de acordo com suas necessidades.
  • packages/apps/TimeZoneData/oem_template/data_app_prebuilt contém a configuração de tempo de construção para incluir os APKs de teste pré-construídos exigidos pelo teste.

Criação de 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 arquivos de distribuição podem pegar esses commits, usá-los para criar uma nova versão de seu aplicativo de dados e, em seguida, lançar a nova versão para atualizar seus dispositivos em produção.

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

Etapa 1: atualização do sistema / fuso horário e arquivos de dados externos / icu

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

O patch AOSP system / timezone 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 de dados é criado.

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

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

Ao construir o aplicativo 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 de versão de teste devem ser superiores à versão da imagem do sistema). Para obter 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 são garantidamente superiores aos códigos de versão real.

Etapa 3: reconstruir, assinar, testar e liberar

Nesta etapa, os OEMs reconstroem o APK usando tapas, assinam o APK gerado e 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é-compilado do aplicativo de dados 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, se ele 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 só pode ser lançado por meio de uma loja de aplicativos.

Os OEMs são responsáveis ​​por garantir a qualidade e testar o aplicativo de dados atualizado em seus dispositivos antes do lançamento.

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

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

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

  • Versão do formato Distro (maior + menor)
  • Um número de versão crescente (opaco)

Atualmente, o nível de API da plataforma está fortemente correlacionado à 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 pode mudar isso para que um arquivo de distro possa funcionar em vários lançamentos da plataforma Android (e o nível de API não é usado no esquema de código de versão do aplicativo de dados).

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

Este exemplo de esquema de número de versão garante que as versões de formato de distro superiores substituam as versões de formato de distro inferiores. AndroidManifest.xml usa android:minSdkVersion para garantir que dispositivos antigos não recebam versões com uma versão de formato de distro superior ao que eles 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 esquemas alternativos futuros / APKs de teste. É inicialmente (implicitamente) 0. Como o tipo subjacente é um tipo interno de 32 bits com sinal, este esquema suporta até duas revisões futuras do esquema de numeração.
01 Versão do formato principal Rastreia a versão do formato principal de 3 dígitos decimais. O formato da distro suporta 3 dígitos decimais, mas apenas 2 dígitos são usados ​​aqui. É improvável que chegue a 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 de formato menor Rastreia a versão do formato menor de 3 dígitos decimais. O formato da distro suporta 3 dígitos decimais, mas apenas 1 dígito é usado aqui. É improvável que chegue a 10.
X Reservado É 0 para versõ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 que atualizações intersticiais sejam feitas, se necessário.

O esquema poderia ser melhor empacotado se binário fosse usado em vez de decimal, mas este esquema tem a vantagem de ser legível por humanos. Se todo o intervalo de números se esgotar, o nome do pacote do aplicativo de dados pode 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 . Os exemplos são mostrados na tabela a seguir.

# Código de versão minSdkVersion {Versão do formato principal}, {Versão do formato secundário}, {versão das regras da IANA}, {revisão}
1 11000010 O-MR1 maior = 001, menor = 001, iana = 2017a, revisão = 1
2 21000010 P maior = 002, menor = 001, iana = 2017a, revisão = 1
3 11000020 O-MR1 principal = 001, menor = 001, iana = 2017a, revisão = 2
4 11000030 O-MR1 principal = 001, menor = 001, iana = 2017b, revisão = 1
5 21000020 P principal = 002, menor = 001, iana = 2017b, revisão = 1
6 11000040 O-MR1 principal = 001, menor = 001, iana = 2018a, revisão = 1
7 21000030 P principal = 002, menor = 001, iana = 2018a, revisão = 1
8 1123456789 - -
9 11000021 O-MR1 principal = 001, menor = 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 IANA com diferentes versões de formato principal. 2 é numericamente maior que 1, que é necessário para garantir que os dispositivos mais novos recebam as versões de formato superior. O minSdkVersion garante que a versão P não será fornecida para 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 2017b para O-MR1 e P. Sendo numericamente mais altos, eles substituem versões anteriores da IANA / revisões do Android de seus respectivos predecessores.
  • Os Exemplos 6 e 7 mostram as versões 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 é fornecido com um APK com versão apropriada e padrão na imagem do sistema, não há risco de uma versão O-MR1 ser instalada em um dispositivo P porque tem 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 então recebe uma atualização de sistema para P usa a versão /system em preferência à versão O-MR1 em /data porque a versão P é sempre superior a qualquer aplicativo destinado a O- MR1.

Criar o aplicativo de dados usando tapas

Os OEMs são responsáveis ​​por gerenciar a maioria dos aspectos do aplicativo de dados de fuso horário e configurar a imagem do sistema corretamente. O aplicativo de dados deve ser construído com uma versão 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 simplificada do sistema de compilação do Android que usa uma árvore de código-fonte reduzida para produzir versões distribuíveis de aplicativos. Os OEMs familiarizados com o sistema de compilação Android normal devem reconhecer os arquivos de compilação da compilação normal da plataforma Android.

Criação do manifesto

Uma árvore de código-fonte reduzida geralmente é obtida com um arquivo de manifesto personalizado que se refere apenas aos projetos Git necessários para o sistema de compilação e para compilar o aplicativo. Depois de 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 aplicativo, 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 construção para APKs de teste que podem ser usados ​​por 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.

O app build aproveita vários outros projetos Git que são compartilhados com o build da plataforma ou contêm bibliotecas de código independentes de OEM.

O seguinte fragmento de manifesto contém o conjunto mínimo de projetos Git necessários para dar suporte a uma compilação O-MR1 do aplicativo de dados de 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 este manifesto e podem configurar diferentes branches 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 compilação de tapas

Depois que a árvore de origem for estabelecida, invoque a compilaçã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 construção bem-sucedida gera arquivos no diretório out/dist para teste. Esses arquivos podem ser colocados no diretório pré-compilados para inclusão na imagem do sistema e / ou distribuídos por meio de uma loja de aplicativos para dispositivos compatíveis.