O Android 10 descontinua o mecanismo de atualização de dados de fuso horário baseado em APK (disponível no Android 8.1 e Android 9) e o substitui por um mecanismo de atualização de módulo baseado em APEX . O AOSP 8.1 a 13 ainda inclui o código da plataforma necessário para que os OEMs habilitem atualizações baseadas em APK, de modo que os dispositivos atualizados 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ó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 Dados de fuso horário compatível com Android 10 e versões posteriores atualiza o horário de verão (DST) e os fusos horários em dispositivos Android, padronizando dados que podem mudar frequentemente por motivos religiosos, políticos e geopolíticos.
As atualizações usam o seguinte processo:
- IANA lança uma atualização no banco de dados de fuso horário em resposta a um ou mais governos que alteram uma regra de fuso horário em seus países.
- 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.
- 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 módulos, consulte Componentes modulares do sistema .
Atualizações de fuso horário (Android 8.1–9)
Observação: o recurso do mecanismo de atualização de dados de fuso horário baseado em APK foi completamente removido do Android 14 em diante e não pode ser encontrado no código-fonte. Os parceiros devem migrar totalmente para o módulo Time Zone Mainline.
No Android 8.1 e no Android 9, os OEMs podem usar um mecanismo baseado em APK para enviar dados atualizados de regras de fuso horário aos 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 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 preferirem. Em todos os casos, os OEMs mantêm o controle sobre a garantia/teste de qualidade, o tempo e o lançamento de atualizações de regras de fuso horário para 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 fornecidos 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 de
libcore/
(por exemplo,java.util.TimeZone
) usa arquivostzdata
etzlookup.xml
. - O código da biblioteca nativa em
bionic/
(por exemplo, paramktime
, chamadas de sistema de horário local) usa o arquivotzdata
. - O código da biblioteca ICU4J/ICU4C em
external/icu/
usa o arquivo icu.dat
.
Essas bibliotecas controlam 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 /system
.
Os componentes do sistema Android que precisam de dados de regras de fuso horário verificam primeiro os seguintes locais:
- Os códigos
libcore/
ebionic/
usam a cópia/data
dos arquivostzdata
etzlookup.xml
. - O código ICU4J/ICU4C usa os arquivos em
/data
e recorre aos 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 aos dispositivos detectar problemas de controle de versão.
O formato do arquivo de distribuição depende da versão do Android porque o conteúdo muda com a versão do ICU, os requisitos da plataforma Android e outras alterações de versão. O Android fornece arquivos de distribuição para versões compatíveis do Android para cada atualização 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 os 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 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 instalação requerem o seguinte:
- Funcionalidade de serviço da plataforma (
timezone.RulesManagerService
), que está desabilitada por padrão. Os OEMs devem habilitar a funcionalidade por meio da configuração.RulesManagerService
é executado no processo do servidor do sistema e prepara 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 Data ) 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 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 habilitaram o recurso corretamente.
Instalação da distribuição
O processo de instalação da distribuição inclui as seguintes etapas:
- O aplicativo de dados é atualizado por meio de download ou sideload na app store. O processo do servidor do sistema (por meio das classes
timezone.RulesManagerServer/timezone.PackageTracker
) observa alterações no nome do pacote do aplicativo de dados configurado e específico do OEM.Figura 1. Atualizações de aplicativos de dados - O processo do servidor do sistema aciona uma verificação de atualização transmitindo uma intenção direcionada com um token exclusivo e de uso único para o aplicativo atualizador. O servidor do sistema monitora o token mais recente gerado para poder determinar quando a verificação mais recente acionada foi concluída; quaisquer outros tokens são ignorados.
Figura 2. Acionar verificação de atualização - Durante a verificação de atualização , o aplicativo Updater executa as seguintes tarefas:
- Consulta o estado atual do dispositivo chamando o RulesManagerService.
Figura 3. Atualizações de aplicativos de dados, chamando RulesManagerService - Consulta o aplicativo Data consultando um URL ContentProvider bem definido e especificações de coluna para obter informações sobre a distribuição.
Figura 4. Atualizações de aplicativos de dados, obter informações sobre distribuição
- Consulta o estado atual do dispositivo chamando o RulesManagerService.
- O aplicativo Updater toma as medidas apropriadas com base nas informações que possui. As ações disponíveis incluem:
- Solicite uma instalação. Os dados da distribuição são lidos no aplicativo Data 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 apropriados para o dispositivo e prepara 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 para a versão presente em/system
. - Fazer nada. Ocorre quando a distribuição do aplicativo Data é considerada inválida.
Figura 5. Verificação concluída - Reinicie 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 executar as seguintes tarefas:
- Execute a operação preparada manipulando 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, 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 da distribuição tiver mudado. - Certifique-se de que a versão das regras da IANA seja 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
.
- Execute a operação preparada manipulando a criação, substituição e/ou exclusão dos arquivos
Confiabilidade
O processo de instalação ponta a ponta é assíncrono e dividido em três processos de sistema operacional. 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 fique incompleta. Na melhor das hipóteses, o aplicativo Updater informa ao servidor do sistema que não teve êxito; na pior das hipóteses, o RulesManagerService não recebe nenhuma chamada.
Para lidar com isso, o código do servidor do sistema monitora se uma verificação de atualização acionada foi concluída e qual é o último código de versão verificado do aplicativo de dados. 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 Data App, ele acionará espontaneamente uma verificação de atualização.
Segurança
Quando ativado, o código RulesManagerService no servidor do sistema executa diversas verificações para garantir que o sistema seja seguro para uso.
- Problemas que indicam uma imagem do sistema mal configurada impedem a inicialização do dispositivo; os exemplos incluem uma configuração incorreta do aplicativo Updater ou Data ou o aplicativo Updater ou Data não está em
/system/priv-app
. - Problemas que indicam que um aplicativo de dados incorreto foi instalado não impedem a inicialização do dispositivo, mas impedem o acionamento de uma verificação de atualização; os exemplos incluem a falta de permissões de sistema necessárias 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 impostas usando regras do SELinux. Como acontece com 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 de pacote dedicados e específicos do OEM.
Integrando 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 compilação da imagem do sistema.
- Configure o servidor do sistema para ativar o RulesManagerService.
Preparando
Antes de começar, os OEMs devem revisar as seguintes considerações sobre política, garantia de qualidade e segurança:
- Crie uma chave de assinatura específica do aplicativo dedicada para o aplicativo Data.
- 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 impacta a escolha do nome do pacote, possivelmente os códigos de versão utilizados e a estratégia de controle de qualidade.
- Entenda se eles desejam usar dados de fuso horário padrão do Android do AOSP ou criar os seus próprios.
Criando um aplicativo de dados
O AOSP inclui todo o código-fonte e regras de compilaçã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 compilação para o APK do aplicativo Data real e destinos extras para a criação de versões de teste do aplicativo Data.
Os OEMs podem personalizar o aplicativo Data 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 construído com uma compilaçã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 Data usando tapas .
Os OEMs devem instalar o aplicativo Data 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 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 alvos de build para incluir versões de teste do aplicativo Data em conjuntos de testes.
Incluindo os aplicativos Updater e Data na imagem do sistema
Os OEMs devem colocar os APKs do aplicativo Updater e Data no diretório /system/priv-app
da imagem do sistema. Para fazer isso, a compilação da imagem do sistema deve incluir explicitamente os destinos pré-construídos do aplicativo Updater e 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 Data é específica do OEM e depende do nome de destino escolhido para a pré-construção.
Configurando o servidor do sistema
Para ativar 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 detecte alterações no aplicativo 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 acionada pelo RulesManagerService e uma resposta de instalação, desinstalação ou não fazer nada. Após este ponto, um gatilho espontâneo de confiabilidade pode ser gerado. | Não |
config_timeZoneRulesCheckRetryCount | O número de verificações de atualização sequenciais malsucedidas 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 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 diferentes de pacote de aplicativo de dados/aplicativo atualizador) seria considerada uma configuração incorreta.
Teste xTS
xTS refere-se a qualquer conjunto de testes específico de OEM que seja semelhante aos conjuntos de testes padrão do Android usando 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 testes funcionais automatizados básicos. -
packages/apps/TimeZoneData/oem_template/xts
contém uma estrutura de diretórios de amostra para incluir testes em um conjunto xTS semelhante ao Tradefed. Tal 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 configuração em tempo de compilação para incluir os APKs de teste pré-criados 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 as versões no AOSP. 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 Data 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 distribuição 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 quiser fornecer atualizações para 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 os commits do Android para system/timezone
e external/icu
das ramificações release -dev no AOSP e aplicam esses commits à sua cópia do código-fonte do Android.
O patch system/timezone AOSP contém arquivos atualizados em system/timezone/input_data
e system/timezone/output_data
. OEMs que precisam fazer correções locais adicionais 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 aplicativo Data é criado.
Etapa 2: atualizar o código da versão do aplicativo Data
Nesta etapa, os OEMs atualizam o código da versão do aplicativo Data. A compilação seleciona automaticamente distro.zip
, mas a nova versão do aplicativo Data deve ter um novo código de versão para que seja reconhecida como nova e usada para substituir um aplicativo Data pré-carregado ou um aplicativo Data instalado em um dispositivo por uma atualização anterior.
Ao criar o aplicativo Data usando arquivos copiados de package/apps/TimeZoneData/oem_template/data_app
, você pode encontrar o código/nome da versão aplicado ao APK no Android.mk
:
TIME_ZONE_DATA_APP_VERSION_CODE := TIME_ZONE_DATA_APP_VERSION_NAME :=
Entradas semelhantes podem ser encontradas em testing/Android.mk
(no entanto, os códigos da versão de teste 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 da versão de teste não precisam ser atualizados porque é garantido que sejam superiores aos códigos da versão real.
Etapa 3: reconstruir, assinar, testar e liberar
Nesta etapa, os OEMs reconstroem o APK usando tapas, assinam o APK gerado e, em seguida, 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, se ele passa no CTS e em quaisquer 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ó poderá ser lançado por meio de uma loja de aplicativos.
Os OEMs são responsáveis pela garantia de 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 Data deve ter uma estratégia de controle 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 aquele baixado da app store, a versão da app store deverá ser mantida.
O código da versão do APK deve incluir as seguintes informações:
- Versão em formato distro (maior + menor)
- Um número de versão incremental (opaco)
Atualmente, o nível da API da plataforma está fortemente correlacionado com a versão do formato da distribuição porque cada nível da API geralmente está associado a uma nova versão do ICU (o que torna os arquivos da 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 seja usado no esquema de código da 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 distribuição superior substituam as versões de formato de distribuição inferior. AndroidManifest.xml
usa android:minSdkVersion
para garantir que dispositivos antigos não recebam versões com um formato de distribuição superior ao que podem suportar.
![Verificação de versão](https://source.android.google.cn/static/docs/core/permissions/images/tz_version_check.png?authuser=4&hl=pt-br)
Exemplo | Valor | Propósito |
---|---|---|
S | Reservado | Permite futuros esquemas alternativos/APKs de teste. É inicialmente (implicitamente) 0. Como o tipo subjacente é um tipo int assinado de 32 bits, esse esquema oferece suporte a até duas revisões futuras do esquema de numeração. |
01 | Versão de formato principal | Rastreia a versão do formato principal de 3 dígitos decimais. O formato de distribuição suporta 3 dígitos decimais, mas apenas 2 dígitos são usados aqui. É improvável que chegue a 100, dado o 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 de formato menor de 3 dígitos decimais. O formato de distribuição 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 de versão opaco | Número decimal alocado sob demanda. Inclui lacunas para permitir que atualizações intersticiais sejam feitas, 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 de numeração completo se esgotar, o nome do pacote do aplicativo Data 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
. Exemplos são mostrados na tabela a seguir.
# | Código da versão | minSdkVersão | {Versão de formato principal},{Versão de formato secundário},{Versão de 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 | maior=001,menor=001,iana=2017a,revisão=2 |
4 | 11000030 | O-MR1 | maior=001,menor=001,iana=2017b,revisão=1 |
5 | 21000020 | P | maior=002,menor=001,iana=2017b,revisão=1 |
6 | 11000040 | O-MR1 | maior=001,menor=001,iana=2018a,revisão=1 |
7 | 21000030 | P | maior=002,menor=001,iana=2018a,revisão=1 |
8 | 1123456789 | - | - |
9 | 11000021 | O-MR1 | maior=001,menor=001,iana=2017a,revisão=2,respin=2 |
- Os exemplos 1 e 2 mostram duas versões de APK para a mesma versão 2017a da IANA com diferentes versões de formato principal. 2 é numericamente superior a 1, o que é necessário para garantir que os dispositivos mais recentes recebam 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 superior a 1.
- Os exemplos 4 e 5 mostram as versões 2017b para O-MR1 e P. Sendo numericamente superiores, eles substituem as versões anteriores da IANA/revisões do Android de seus respectivos antecessores.
- 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 do espaço deixado entre 3 e 4 para girar novamente o apk.
Como cada dispositivo é fornecido com um APK padrão com versão apropriada na imagem do sistema, não há risco de uma versão O-MR1 ser instalada em um dispositivo P porque ele tem um número de versão inferior ao de 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 preferência à versão O-MR1 em /data
porque a versão P é sempre superior a qualquer aplicativo destinado a O- MR1.
Construindo o aplicativo Data 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 Data deve ser construído com uma compilaçã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 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 normal do Android devem reconhecer os arquivos de compilação da compilação normal da plataforma Android.
Criando o 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 ao sistema de construção e à construção do 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.
A construção do aplicativo aproveita vários outros projetos Git que são compartilhados com a construção da plataforma ou contêm bibliotecas de código independentes de OEM.
O snippet de manifesto a seguir contém o conjunto mínimo de projetos 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 ramificações adequadamente.
<!-- 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" />
Executando a compilação de tapas
Depois que a árvore de origem for estabelecida, invoque a compilação 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 por meio de uma loja de aplicativos para dispositivos compatíveis.