Reglas de zona horaria

Android 10 da de baja el mecanismo de actualización de datos de zona horaria basado en APK (disponible en Android 8.1 y Android 9) y lo reemplaza por un mecanismo de actualización de módulos basado en APEX. AOSP 8.1 a 13 aún incluye el código de plataforma necesario para que los OEM habiliten actualizaciones basadas en APK, por lo que los dispositivos que se actualizan a Android 10 aún pueden recibir actualizaciones de datos de zona horaria proporcionados por socios a través de APK. Sin embargo, el mecanismo de actualización de APK no debe usarse en un dispositivo de producción que también reciba actualizaciones de módulos, ya que una actualización basada en APK reemplaza una actualización basada en APEX (es decir, un dispositivo que recibió una actualización de APK ignoraría las actualizaciones basadas en APEX).

Actualizaciones de zona horaria (Android 10 y versiones posteriores)

El módulo de datos de zona horaria compatible con Android 10 y versiones posteriores actualiza el horario de verano (DST) y las zonas horarias en dispositivos Android, lo que estandariza los datos que pueden cambiar con frecuencia por motivos religiosos, políticos y geopolíticos.

Las actualizaciones usan el siguiente proceso:

1. IANA publica una actualización de la base de datos de zonas horarias en respuesta a uno o más gobiernos que cambian una regla de zona horaria en sus países.
2. Google o el socio de Android preparan una actualización del módulo de datos de zona horaria (archivo APEX) que contiene las zonas horarias actualizadas.
3. El dispositivo del usuario final descarga la actualización, se reinicia y, luego, aplica los cambios. Después, los datos de zona horaria del dispositivo contienen los nuevos datos de zona horaria de la actualización.

Para obtener detalles sobre los módulos, consulta Componentes modulares del sistema.

Actualizaciones de zona horaria (Android 8.1 a 9)

Nota: La función del mecanismo de actualización de datos de zona horaria basada en APK se quitó por completo a partir de Android 14 y no se puede encontrar en el código fuente. Los socios deben migrar por completo al módulo de línea principal de la zona horaria.

En Android 8.1 y Android 9, los OEMs pueden usar un mecanismo basado en APK para enviar datos actualizados de reglas de zona horaria a los dispositivos sin requerir una actualización del sistema. Este mecanismo permite a los usuarios recibir actualizaciones oportunas (lo que extiende la vida útil de un dispositivo Android) y permite a los socios de Android probar las actualizaciones de zona horaria independientemente de las actualizaciones de imagen del sistema.

El equipo de bibliotecas principales de Android proporciona los archivos de datos necesarios para actualizar las reglas de zona horaria en un dispositivo Android sin modificaciones. Los OEMs pueden optar por usar estos archivos de datos cuando crean actualizaciones de zona horaria para sus dispositivos o pueden crear sus propios archivos de datos si lo prefieren. En todos los casos, los OEMs retienen el control sobre la garantía de calidad o las pruebas, los tiempos y el lanzamiento de las actualizaciones de las reglas de zona horaria para sus dispositivos compatibles.

Código fuente y datos de la zona horaria de Android

Todos los dispositivos Android de stock, incluso aquellos que no usan esta función, necesitan datos de reglas de zona horaria y deben enviarse con un conjunto predeterminado de datos de reglas de zona horaria en la partición /system. Luego, el código de las siguientes bibliotecas del árbol de origen de Android usa estos datos:

• El código administrado de libcore/ (por ejemplo, java.util.TimeZone) usa archivos tzdata y tzlookup.xml.
• El código de la biblioteca nativa en bionic/ (por ejemplo, para mktime, llamadas al sistema de hora local) usa el archivo tzdata.
• El código de la biblioteca ICU4J/ICU4C en external/icu/ usa el archivo icu.dat.

Estas bibliotecas realizan un seguimiento de los archivos de superposición que pueden estar presentes en el directorio /data/misc/zoneinfo/current. Se espera que los archivos de superposición contengan datos mejorados de las reglas de zona horaria, lo que permite que los dispositivos se actualicen sin cambiar /system.

Los componentes del sistema Android que necesitan datos de reglas de zona horaria primero verifican las siguientes ubicaciones:

• El código libcore/ y bionic/ usa la copia /data de los archivos tzdata y tzlookup.xml.
• El código ICU4J/ICU4C usa los archivos en /data y recurre a los archivos /system para los datos que no están presentes (para formatos, cadenas localizadas, etcétera).

Archivos de distribución

Los archivos .zip de la distribución contienen los archivos de datos necesarios para propagar el directorio /data/misc/zoneinfo/current. Los archivos de distribución también contienen metadatos que permiten que los dispositivos detecten problemas de control de versiones.

El formato de archivo de distribución depende de la versión de Android, ya que el contenido cambia con la versión de ICU, los requisitos de la plataforma de Android y otros cambios de versión. Android proporciona archivos de distribución para las versiones compatibles de Android para cada actualización de la IANA (además de actualizar los archivos del sistema de la plataforma). Para mantener sus dispositivos actualizados, los OEMs pueden usar estos archivos de distribución o crear los suyos propios con el árbol de fuentes de Android (que contiene las secuencias de comandos y otros archivos necesarios para generar archivos de distribución).

Componentes de actualización de zona horaria

Una actualización de las reglas de zona horaria implica la transmisión de archivos de distribución a un dispositivo y la instalación segura de los archivos que contiene. La transferencia y la instalación requieren lo siguiente:

• Funcionalidad del servicio de la plataforma (timezone.RulesManagerService), que está inhabilitada de forma predeterminada Los OEMs deben habilitar la funcionalidad a través de la configuración. RulesManagerService se ejecuta en el proceso del servidor del sistema y escribe en /data/misc/zoneinfo/staged para organizar las operaciones de actualización de zona horaria. RulesManagerService también puede reemplazar o borrar operaciones ya en la etapa de preparación.
• TimeZoneUpdater, una app del sistema que no se puede actualizar (también conocida como app del actualizador). Los OEMs deben incluir esta app en la imagen del sistema de los dispositivos que usan la función.
• OEM TimeZoneData, una app del sistema actualizable (también conocida como app de datos) que lleva archivos de distribución al dispositivo y los pone a disposición de la app de actualización. Los OEMs deben incluir esta app en la imagen del sistema de los dispositivos que usan la función.
• tzdatacheck, un binario de inicio necesario para el funcionamiento correcto y seguro de las actualizaciones de zona horaria.

El árbol de origen de Android contiene código fuente genérico para los componentes anteriores, que el OEM puede usar sin modificaciones. Se proporciona un código de prueba para permitir que los OEM verifiquen automáticamente que habilitaron la función correctamente.

Instalación de la distribución

El proceso de instalación de la distribución incluye los siguientes pasos:

1. La app de datos se actualiza a través de una descarga de la tienda de aplicaciones o de la carga lateral. El proceso del servidor del sistema (a través de las clases timezone.RulesManagerServer/timezone.PackageTracker) busca cambios en el nombre del paquete de la app de datos configurado y específico del OEM.
   
   

   Figura 1: Actualizaciones de apps de datos

2. El proceso del servidor del sistema activa una verificación de actualización mediante la transmisión de un intent segmentado con un token único de un solo uso a la app del actualizador. El servidor del sistema realiza un seguimiento del token más reciente que generó para poder determinar cuándo se completó la verificación más reciente que activó. Se ignoran los demás tokens.
   
   

   Figura 2: Activa la verificación de actualización.

3. Durante la verificación de actualizaciones, la app de Updater realiza las siguientes tareas:
   • Llama a RulesManagerService para consultar el estado actual del dispositivo.
     
     

     Figura 3: Actualizaciones de la app de datos, llamadas a RulesManagerService

   • Consulta la app de datos mediante una URL de ContentProvider bien definida y especificaciones de columna para obtener información sobre la distribución.
     
     

     Figura 4: Actualizaciones de la app de datos, obtén información sobre la distribución.

4. La app de Updater realiza la acción adecuada según la información que tiene. Entre las acciones disponibles, se incluyen las siguientes:
   • Solicita una instalación. Los datos de la distribución se leen de la app de datos y se pasan a RulesManagerService en el servidor del sistema. RulesManagerService vuelve a confirmar que la versión y el contenido del formato de distribución son adecuados para el dispositivo y estaciona la instalación.
   • Solicitar una desinstalación (esto es poco frecuente). Por ejemplo, si se inhabilita o desinstala el APK actualizado en /data y el dispositivo vuelve a la versión presente en /system.
   • No hacer nada. Ocurre cuando se detecta que la distribución de la app de datos no es válida.
   En todos los casos, la app de Updater llama a RulesManagerService con el token de verificación para que el servidor del sistema sepa que la verificación se completó correctamente.
   
   

   Figura 5: Se completó la verificación.

5. Reinicia y ejecuta tzdatacheck. La próxima vez que se inicie el dispositivo, el objeto binario tzdatacheck ejecutará cualquier operación en etapa. El objeto binario tzdatacheck puede realizar las siguientes tareas:
   • Para ejecutar la operación en etapas, controla la creación, el reemplazo o la eliminación de los archivos /data/misc/zoneinfo/current antes de que otros componentes del sistema se abran y comiencen a usar los archivos.
   • Verifica que los archivos de /data sean correctos para la versión actual de la plataforma, lo que podría no ser el caso si el dispositivo acaba de recibir una actualización del sistema y cambió la versión del formato de distribución.
   • Asegúrate de que la versión de las reglas de la IANA sea la misma o más reciente que la versión de /system. Esto protege contra una actualización del sistema que deje un dispositivo con datos de reglas de zona horaria más antiguos que los que están presentes en la imagen /system.

Fiabilidad

El proceso de instalación de extremo a extremo es asíncrono y se divide en tres procesos del SO. En cualquier momento durante la instalación, es posible que el dispositivo pierda energía, se le acabe el espacio en el disco o tenga otros problemas, lo que provocará que la verificación de la instalación no se complete. En el mejor de los casos, la app de Updater informa al servidor del sistema que no se pudo realizar la actualización. En el peor de los casos, RulesManagerService no recibe ninguna llamada.

Para controlar esto, el código del servidor del sistema realiza un seguimiento de si se completó una verificación de actualización activada y cuál es el último código de versión verificado de la app de datos. Cuando el dispositivo está inactivo y se está cargando, el código del servidor del sistema puede verificar el estado actual. Si detecta una verificación de actualización incompleta o una versión inesperada de la app de datos, activa una verificación de actualización de forma espontánea.

Seguridad

Cuando está habilitado, el código de RulesManagerService en el servidor del sistema realiza varios controles para garantizar que el sistema sea seguro de usar.

• Los problemas que indican una imagen del sistema mal configurada impiden que se inicie un dispositivo. Algunos ejemplos son una configuración incorrecta de la app de actualización o de datos, o que la app de actualización o de datos no esté en /system/priv-app.
• Los problemas que indican que se instaló una app de datos incorrecta no impiden que se inicie el dispositivo, pero sí que se active una verificación de actualización. Entre los ejemplos, se incluyen la falta de permisos del sistema necesarios o que la app de datos no exponga un ContentProvider en el URI esperado.

Los permisos de archivos de los directorios /data/misc/zoneinfo se aplican con reglas de SELinux. Al igual que con cualquier APK, la app de datos debe estar firmada con la misma clave que se usó para firmar la versión de /system/priv-app. Se espera que la app de datos tenga un nombre y una clave de paquete específicos del OEM.

Integra las actualizaciones de zona horaria

Para habilitar la función de actualización de zona horaria, los OEM suelen hacer lo siguiente:

• Crear su propia app de datos
• Incluye las apps de Updater y Data en la compilación de la imagen del sistema.
• Configura el servidor del sistema para habilitar RulesManagerService.

Preparación

Antes de comenzar, los OEMs deben revisar la siguiente política, las consideraciones de seguridad y de control de calidad:

• Crea una clave de firma específica para la app de datos.
• Crea una estrategia de lanzamiento y control de versiones para las actualizaciones de zona horaria para comprender qué dispositivos se actualizarán y cómo se puede garantizar que las actualizaciones solo se instalen en los dispositivos que las necesitan. Por ejemplo, los OEMs pueden querer tener una sola app de datos para todos sus dispositivos o pueden optar por tener diferentes apps de datos para diferentes dispositivos. La decisión afecta la elección del nombre del paquete, posiblemente los códigos de versión utilizados y la estrategia de QA.
• Comprende si quieren usar los datos de zona horaria de Android estándar de AOSP o crear los suyos propios.

Crea una app de datos

AOSP incluye todo el código fuente y las reglas de compilación necesarias para crear una app de datos en packages/apps/TimeZoneData, con instrucciones y plantillas de ejemplo para AndroidManifest.xml y otros archivos ubicados en packages/apps/TimeZoneData/oem_template. Las plantillas de ejemplo incluyen un objetivo de compilación para el APK real de la app de Datos y objetivos adicionales para crear versiones de prueba de la app de Datos.

Los OEMs pueden personalizar la app de Datos con su propio ícono, nombre, traducciones y otros detalles. Sin embargo, como no se puede iniciar la app de Datos, el ícono solo aparece en la pantalla Configuración > Apps.

La app de datos se compila con una compilación de tapas que produce APKs adecuados para agregarlos a la imagen del sistema (para la versión inicial) y firmarlos y distribuirlos a través de una tienda de aplicaciones (para actualizaciones posteriores). Para obtener más información sobre el uso de tapas, consulta Cómo compilar la app de datos con tapas.

Nota: La firma segura de APKs y la administración de claves están fuera del alcance de este artículo.

Los OEMs deben instalar la app de datos precompilada en la imagen del sistema de un dispositivo en /system/priv-app. Para incluir APKs precompilados (generados por el proceso de compilación de tapas) en la imagen del sistema, los OEMs pueden copiar los archivos de ejemplo en packages/apps/TimeZoneData/oem_template/data_app_prebuilt. Las plantillas de ejemplo también incluyen destinos de compilación para incluir versiones de prueba de la app de datos en paquetes de pruebas.

Cómo incluir las apps de Updater y Data en la imagen del sistema

Los OEMs deben colocar los APKs de la app del actualizador y de los datos en el directorio /system/priv-app de la imagen del sistema. Para ello, la compilación de la imagen del sistema debe incluir de forma explícita los destinos precompilados de la app de Updater y de la app de datos.

La app del actualizador debe estar firmada con la clave de plataforma y debe incluirse como cualquier otra app del sistema. El destino se define en packages/apps/TimeZoneUpdater como TimeZoneUpdater. La inclusión de la app de datos es específica del OEM y depende del nombre de destino elegido para la compilación previa.

Configura el servidor del sistema

Para habilitar las actualizaciones de zona horaria, los OEMs pueden configurar el servidor del sistema anulando las propiedades de configuración definidas en frameworks/base/core/res/res/values/config.xml.

Propiedad	Descripción	¿Se requiere la anulación?
config_enableUpdateableTimeZoneRules	Se debe establecer en true para habilitar RulesManagerService.	Sí
config_timeZoneRulesUpdateTrackingEnabled	Se debe establecer en true para que el sistema detecte cambios en la app de datos.	Sí
config_timeZoneRulesDataPackage	Es el nombre del paquete de la app de datos específica del OEM.	Sí
config_timeZoneRulesUpdaterPackage	Se configuró para la app de Updater predeterminada. Cambia solo cuando proporciones una implementación diferente de la app de Updater.	No
config_timeZoneRulesCheckTimeMillisAllowed	Es el tiempo permitido entre que RulesManagerService activa una verificación de actualización y una respuesta de instalación, desinstalación o no hacer nada. Después de este punto, es posible que se genere un activador de confiabilidad espontáneo.	No
config_timeZoneRulesCheckRetryCount	Es la cantidad de verificaciones de actualización consecutivas que no se pudieron realizar y que se permiten antes de que el servicio de RulesManager deje de generar más.	No

Las anulaciones de configuración deben estar en la imagen del sistema (no del proveedor ni de otro), ya que un dispositivo con una configuración incorrecta puede negarse a iniciarse. Si las anulaciones de configuración estuvieran en la imagen del proveedor, la actualización a una imagen del sistema sin una app de datos (o con diferentes nombres de paquetes de apps de datos o de actualización) se consideraría una configuración incorrecta.

Pruebas de xTS

xTS hace referencia a cualquier conjunto de pruebas específico del OEM que sea similar a los conjuntos de pruebas estándar de Android con Tradefed (como CTS y VTS). Los OEMs que tengan esos conjuntos de pruebas pueden agregar las pruebas de actualización de zona horaria de Android que se proporcionan en las siguientes ubicaciones:

• packages/apps/TimeZoneData/testing/xts incluye el código necesario para las pruebas funcionales automatizadas básicas.
• packages/apps/TimeZoneData/oem_template/xts contiene una estructura de directorio de muestra para incluir pruebas en un paquete de xTS similar a Tradefed. Al igual que con otros directorios de plantillas, se espera que los OEM los copien y personalicen según sus necesidades.
• packages/apps/TimeZoneData/oem_template/data_app_prebuilt contiene la configuración del tiempo de compilación para incluir los APKs de prueba compilados previamente que requiere la prueba.

Nota: La configuración de un paquete de pruebas específico del OEM está fuera del alcance de este artículo.

Crea actualizaciones de zona horaria

Cuando la IANA lanza un nuevo conjunto de reglas de zona horaria, el equipo de bibliotecas principales de Android genera parches para actualizar las versiones en AOSP. Los OEMs que usan el sistema y los archivos de distribución de Android originales pueden detectar estas confirmaciones, usarlas para crear una versión nueva de su app de datos y, luego, lanzar la versión nueva para actualizar sus dispositivos en producción.

Nota: En los siguientes pasos, no se describe cómo actualizar los archivos de datos de base en la imagen /system, lo que es obligatorio cuando se prepara la imagen de fábrica o las actualizaciones del sistema. Ese proceso también genera el archivo de distribución para incluirlo en la app de datos. Para obtener instrucciones sobre cómo actualizar los archivos de la plataforma, consulta /system/timezone/README.android.

Debido a que las apps de datos contienen archivos de distribución estrechamente vinculados a las versiones de Android, los OEMs deben crear una versión nueva de la app de datos para cada versión compatible de Android que un OEM quiera actualizar. Por ejemplo, si un OEM quiere proporcionar actualizaciones para dispositivos Android 8.1, 9 y 10, debe completar el proceso tres veces.

Paso 1: Actualiza los archivos de datos del sistema/la zona horaria y los archivos de datos externos/ICU

En este paso, los OEMs toman las confirmaciones de Android existentes para system/timezone y external/icu de las ramas de versión-dev en AOSP y aplican esas confirmaciones a su copia del código fuente de Android.

El parche de AOSP del sistema/huso horario contiene archivos actualizados en system/timezone/input_data y system/timezone/output_data. Los OEMs que necesiten realizar correcciones locales adicionales pueden modificar los archivos de entrada y, luego, usar los archivos de system/timezone/input_data y external/icu para generar archivos en output_data.

El archivo más importante es system/timezone/output_data/distro/distro.zip, que se incluye automáticamente cuando se compila el APK de la app de datos.

Paso 2: Actualiza el código de versión de la app de datos

En este paso, los OEMs actualizan el código de versión de la app de datos. La compilación recupera automáticamente distro.zip, pero la versión nueva de la app de datos debe tener un código de versión nuevo para que se reconozca como nuevo y se use para reemplazar una app de datos precargada o una app de datos instalada en un dispositivo por una actualización anterior.

Cuando compilas la app de datos con archivos copiados de package/apps/TimeZoneData/oem_template/data_app, puedes encontrar el código o el nombre de la versión aplicados al APK en Android.mk:

TIME_ZONE_DATA_APP_VERSION_CODE :=
TIME_ZONE_DATA_APP_VERSION_NAME :=

Se pueden encontrar entradas similares en testing/Android.mk (sin embargo, los códigos de versión de prueba deben ser superiores a la versión de la imagen del sistema). Para obtener más información, consulta el esquema de estrategia de código de versión de ejemplo. Si se usa el esquema de ejemplo o uno similar, no es necesario actualizar los códigos de versión de prueba, ya que se garantiza que sean más altos que los códigos de versión reales.

Paso 3: Vuelve a compilar, firma, prueba y publica

En este paso, los OEM vuelven a compilar el APK con tapas, firman el APK generado y, luego, lo prueban y lanzan:

• En el caso de los dispositivos sin lanzar (o cuando prepares una actualización del sistema para un dispositivo lanzado), envía los APK nuevos al directorio precompilado de la app de datos para asegurarte de que la imagen del sistema y las pruebas de xTS tengan los APKs más recientes. Los OEMs deben probar que el archivo nuevo funcione correctamente (es decir, que pase la CTS y cualquier prueba automatizada y manual específica del OEM).
• En el caso de los dispositivos lanzados que ya no reciben actualizaciones del sistema, es posible que el APK firmado solo se lance a través de una tienda de aplicaciones.

Los OEM son responsables de la garantía de calidad y de probar la app de datos actualizada en sus dispositivos antes del lanzamiento.

Estrategia de código de versión de la app de datos

La app de datos debe tener una estrategia de control de versiones adecuada para garantizar que los dispositivos reciban los APK correctos. Por ejemplo, si se recibe una actualización del sistema que contiene un APK más antiguo que el que se descargó de la tienda de aplicaciones, se debe conservar la versión de la tienda de aplicaciones.

El código de versión del APK debe incluir la siguiente información:

• Versión del formato de distribución (principal + secundaria)
• Un número de versión incremental (opaco)

Actualmente, el nivel de API de la plataforma está fuertemente correlacionado con la versión del formato de distribución, ya que cada nivel de API suele asociarse con una versión nueva de ICU (lo que hace que los archivos de distribución sean incompatibles). En el futuro, es posible que Android cambie esto para que un archivo de distribución pueda funcionar en varias versiones de la plataforma de Android (y el nivel de API no se use en el esquema de código de versión de la app de datos).

Ejemplo de estrategia de código de versión

Este esquema de números de versión de ejemplo garantiza que las versiones de formato de distribución más altas reemplacen a las versiones de formato de distribución más bajas. AndroidManifest.xml usa android:minSdkVersion para garantizar que los dispositivos antiguos no reciban versiones con un formato de distribución más alto del que pueden admitir.

Figura 6: Ejemplo de estrategia de código de versión.

Ejemplo	Valor	Propósito
Y	Reservado	Permite esquemas alternativos o APKs de prueba futuros. Inicialmente (de forma implícita), es 0. Debido a que el tipo subyacente es un tipo int de 32 bits firmado, este esquema admite hasta dos revisiones futuras del esquema de numeración.
01	Versión principal del formato	Realiza un seguimiento de la versión de formato principal de 3 dígitos decimales. El formato de distribución admite 3 dígitos decimales, pero aquí solo se usan 2. Es poco probable que alcance los 100, debido al aumento importante esperado por nivel de API. La versión principal 1 equivale al nivel de API 27.
1	Versión del formato secundario	Realiza un seguimiento de la versión en formato de 3 dígitos decimales. El formato de distribución admite 3 dígitos decimales, pero aquí solo se usa 1. Es poco probable que alcance los 10.
X	Reservado	Es 0 para las versiones de producción (y puede ser diferente para los APKs de prueba).
ZZZZZ	Número de versión opaco	Es un número decimal asignado a pedido. Incluye espacios para permitir que se realicen actualizaciones de anuncios intersticiales si es necesario.

El esquema se podría empaquetar mejor si se usara el formato binario en lugar del decimal, pero este esquema tiene la ventaja de ser legible por humanos. Si se agota el rango completo de números, el nombre del paquete de la app de datos podría cambiar.

El nombre de la versión es una representación legible por humanos de los detalles, por ejemplo, major=001,minor=001,iana=2017a, revision=1,respin=2. En la siguiente tabla, se muestran ejemplos.

#	Código de versión	minSdkVersion	{Major format version},{Minor format version},{IANA rules version},{Revision}
1	11000010	O-MR1	major=001,minor=001,iana=2017a,revision=1
2	21000010	P	major=002,minor=001,iana=2017a,revision=1
3	11000020	O-MR1	major=001,minor=001,iana=2017a,revision=2
4	11000030	O-MR1	major=001,minor=001,iana=2017b,revision=1
5	21000020	P	major=002,minor=001,iana=2017b,revision=1
6	11000040	O-MR1	major=001,minor=001,iana=2018a,revision=1
7	21000030	P	major=002,minor=001,iana=2018a,revision=1
8	1123456789	-	-
9	11000021	O-MR1	major=001,minor=001,iana=2017a,revision=2,respin=2

• En los ejemplos 1 y 2, se muestran dos versiones de APK para la misma versión de IANA de 2017a con diferentes versiones de formato principales. 2 es numéricamente superior a 1, lo que es necesario para garantizar que los dispositivos más nuevos reciban las versiones de formato más altas. minSdkVersion garantiza que no se proporcione la versión P a los dispositivos O.
• El ejemplo 3 es una revisión o corrección de 1 y es numéricamente superior a 1.
• En los ejemplos 4 y 5, se muestran las versiones 2017b de O-MR1 y P. Como son numéricamente más altas, reemplazan las versiones anteriores de la IANA o las revisiones de Android de sus respectivos predecesores.
• En los ejemplos 6 y 7, se muestran las versiones de 2018a para O-MR1 y P.
• En el ejemplo 8, se muestra el uso de Y para reemplazar por completo el esquema Y=0.
• En el ejemplo 9, se muestra el uso del espacio dejado entre 3 y 4 para volver a crear el apk.

Como cada dispositivo se envía con un APK predeterminado con la versión adecuada en la imagen del sistema, no hay riesgo de que se instale una versión O-MR1 en un dispositivo P, ya que tiene un número de versión inferior al de una versión de imagen del sistema P. Un dispositivo con una versión de O-MR1 instalada en /data que luego recibe una actualización del sistema a P usa la versión /system en lugar de la versión de O-MR1 en /data porque la versión P siempre es superior a cualquier app diseñada para O-MR1.

Compila la app de datos con tapas

Los OEM son responsables de administrar la mayoría de los aspectos de la app de datos de zona horaria y configurar la imagen del sistema correctamente. La app de datos se compila con una compilación de tapas que produce APKs adecuados para agregarse a la imagen del sistema (para el lanzamiento inicial) y firmar y distribuir a través de una tienda de aplicaciones (para actualizaciones posteriores).

Tapas es una versión reducida del sistema de compilación de Android que usa un árbol de origen reducido para producir versiones distribuibles de apps. Los OEMs que estén familiarizados con el sistema de compilación normal de Android deberían reconocer los archivos de compilación de la compilación normal de la plataforma de Android.

Crea el manifiesto

Por lo general, se logra un árbol de fuentes reducido con un archivo de manifiesto personalizado que solo hace referencia a los proyectos de Git que necesita el sistema de compilación y para compilar la app. Después de seguir las instrucciones de Cómo crear una app de datos, los OEMs deberían tener al menos dos proyectos de Git específicos del OEM creados con los archivos de plantillas de packages/apps/TimeZoneData/oem_template:

• Un proyecto de Git contiene archivos de app, como el manifiesto y los archivos de compilación necesarios para crear el archivo APK de la app (por ejemplo, vendor/oem/apps/TimeZoneData). Este proyecto también contiene reglas de compilación para APKs de prueba que pueden usar las pruebas de xTS.
• Un proyecto de Git contiene los APKs firmados que produce la compilación de la app para su inclusión en la compilación de la imagen del sistema y las pruebas de xTS.

La compilación de la app aprovecha varios otros proyectos de Git que se comparten con la compilación de la plataforma o contienen bibliotecas de código independientes del OEM.

El siguiente fragmento de manifiesto contiene el conjunto mínimo de proyectos de Git necesarios para admitir una compilación O-MR1 de la app de datos de zona horaria. Los OEMs deben agregar sus proyectos de Git específicos del OEM (que suelen incluir un proyecto que contiene el certificado de firma) a este manifiesto y pueden configurar diferentes ramas según corresponda.

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

Ejecuta la compilación de tapas

Después de establecer el árbol de origen, invoca la compilación de tapas con los siguientes comandos:

source build/envsetup.sh
tapas
make -j30 showcommands dist TARGET_BUILD_APPS='TimeZoneData TimeZoneData_test1 TimeZoneData_test2'  TARGET_BUILD_VARIANT=userdebug

Una compilación correcta genera archivos en el directorio out/dist para pruebas. Estos archivos se pueden colocar en el directorio de compilaciones previas para incluirlos en la imagen del sistema o distribuirlos a través de una tienda de aplicaciones para dispositivos compatibles.