Reglas de zona horaria

Android 10 desaproba el mecanismo de actualización de datos de zona horaria basado en APK (disponible en Android 8.1 y Android 9) y lo reemplaza con un mecanismo de actualización de módulo 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 proporcionadas por los 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 esté recibiendo 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+)

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, estandarizando datos que pueden cambiar con frecuencia por razones religiosas, políticas y geopolíticas.

Las actualizaciones utilizan el siguiente proceso:

1. La IANA publica una actualización de la base de datos de zonas horarias en respuesta a que uno o más gobiernos cambien una regla de zona horaria en sus países.
2. Google o el socio de Android prepara 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 de lo cual 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, consulte Componentes del sistema modular .

Actualizaciones de zona horaria (Android 8.1–9)

Nota: La función del mecanismo de actualización de datos de zona horaria basado en APK se eliminó por completo a partir de Android 14 y no se puede encontrar en el código fuente. Los socios deben migrar completamente al módulo Time Zone Mainline.

En Android 8.1 y Android 9, los OEM pueden utilizar un mecanismo basado en APK para enviar datos actualizados de reglas de zona horaria a los dispositivos sin necesidad de una actualización del sistema. Este mecanismo permite a los usuarios recibir actualizaciones oportunas (extendiendo así la vida útil de un dispositivo Android) y permite a los socios de Android probar actualizaciones de zona horaria independientemente de las actualizaciones de imágenes 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 estándar. Los OEM pueden optar por utilizar estos archivos de datos al crear actualizaciones de zona horaria para sus dispositivos o pueden crear sus propios archivos de datos si lo prefieren. En todos los casos, los OEM conservan el control sobre las pruebas/garantía de calidad, la sincronización y el lanzamiento de actualizaciones de reglas de zona horaria para sus dispositivos compatibles.

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

Todos los dispositivos Android estándar, incluso aquellos que no utilizan 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, estos datos son utilizados por el código de las siguientes bibliotecas en el árbol de fuentes de Android:

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

Estas bibliotecas realizan un seguimiento de los archivos superpuestos que pueden estar presentes en el directorio /data/misc/zoneinfo/current . Se espera que los archivos superpuestos contengan datos mejorados de reglas de zona horaria, lo que permitirá actualizar los dispositivos sin cambiar /system .

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

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

Archivos de distribución

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

El formato del archivo de distribución depende de la versión de Android porque el contenido cambia con la versión de ICU, los requisitos de la plataforma Android y otros cambios de versión. Android proporciona archivos de distribución para las versiones de Android compatibles para cada actualización de la IANA (además de actualizar los archivos del sistema de la plataforma). Para mantener sus dispositivos actualizados, los OEM pueden usar estos archivos de distribución o crear los suyos propios utilizando el árbol de fuentes de Android (que contiene los scripts 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 contenidos en él. La transferencia y la instalación requieren lo siguiente:

• Funcionalidad del servicio de plataforma ( timezone.RulesManagerService ), que está deshabilitada de forma predeterminada. Los OEM deben habilitar la funcionalidad mediante la configuración. RulesManagerService se ejecuta en el proceso del servidor del sistema y organiza las operaciones de actualización de la zona horaria escribiendo en /data/misc/zoneinfo/staged . RulesManagerService también puede reemplazar o eliminar operaciones ya preparadas.
• TimeZoneUpdater , una aplicación del sistema no actualizable (también conocida como aplicación Updater ). Los OEM deben incluir esta aplicación en la imagen del sistema de los dispositivos que utilizan esta función.
• OEM TimeZoneData , una aplicación de sistema actualizable (también conocida como aplicación de datos ) que transporta archivos de distribución al dispositivo y los pone a disposición de la aplicación Updater. Los OEM deben incluir esta aplicación en la imagen del sistema de los dispositivos que utilizan esta función.
• tzdatacheck , un binario de arranque necesario para el funcionamiento correcto y seguro de las actualizaciones de zona horaria.

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

instalación de distribución

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

1. La aplicación de datos se actualiza mediante una descarga o carga local de la tienda de aplicaciones. 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 aplicación de datos configurado y específico del OEM.
   
   

   

2. El proceso del servidor del sistema activa una verificación de actualización al transmitir una intención específica con un token único y de un solo uso a la aplicación Updater. 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ó; cualquier otro token se ignora.
   
   

   

3. Durante la verificación de actualización , la aplicación Updater realiza las siguientes tareas:
   • Consulta el estado actual del dispositivo llamando a RulesManagerService.
     
     

     

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

     

4. La aplicación Updater toma la acción adecuada según la información que tiene. Las acciones disponibles incluyen:
   • Solicite una instalación. Los datos de distribución se leen desde la aplicación de datos y se pasan a RulesManagerService en el servidor del sistema. RulesManagerService reconfirma que la versión y el contenido del formato de distribución son apropiados para el dispositivo y realiza la instalación.
   • Solicite una desinstalación (esto es poco común). Por ejemplo, si el APK actualizado en /data se deshabilita o desinstala y el dispositivo vuelve a la versión presente en /system .
   • Hacer nada. Ocurre cuando se determina que la distribución de la aplicación de datos no es válida.
   En todos los casos, la aplicación Updater llama a RulesManagerService con el token de verificación para que el servidor del sistema sepa que la verificación se completó y fue exitosa.
   
   

   

5. Reinicie y tzdatacheck. La próxima vez que se inicie el dispositivo, el binario tzdatacheck ejecuta cualquier operación por etapas. El binario tzdatacheck puede realizar las siguientes tareas:
   • Ejecute la operación por etapas manejando la creación, reemplazo y/o eliminación de los archivos /data/misc/zoneinfo/current antes de que otros componentes del sistema hayan abierto y comenzado a usar los archivos.
   • Verifique que los archivos en /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 la versión del formato de distribución ha cambiado.
   • Asegúrese de que la versión de las reglas de la IANA sea la misma o más reciente que la versión en /system . Esto protege contra una actualización del sistema que deja un dispositivo con datos de reglas de zona horaria más antiguos que los presentes en la imagen /system .

Fiabilidad

El proceso de instalación de un extremo a otro es asincrónico y se divide en tres procesos del sistema operativo. En cualquier momento durante la instalación, el dispositivo puede perder energía, quedarse sin espacio en el disco o encontrar otros problemas, lo que hace que la verificación de la instalación esté incompleta. En el mejor de los casos, la aplicación Updater informa al servidor del sistema que no tuvo éxito; en el peor de los casos fallidos, RulesManagerService no recibe ninguna llamada.

Para manejar esto, el código del servidor del sistema realiza un seguimiento de si se ha completado una verificación de actualización activada y cuál es el último código de versión verificada de la aplicación de datos. Cuando el dispositivo está inactivo y cargándose, el código del servidor del sistema puede verificar el estado actual. Si descubre una verificación de actualización incompleta o una versión inesperada de la aplicación de datos, activa espontáneamente una verificación de actualización.

Seguridad

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

• Los problemas que indican una imagen del sistema mal configurada impiden el arranque del dispositivo; los ejemplos incluyen una mala configuración de la aplicación Actualizador o Datos o que la aplicación Actualizador o Datos no esté en /system/priv-app .
• Los problemas que indican que se ha instalado una aplicación de datos incorrecta no impiden que el dispositivo se inicie, pero sí impiden que se active una verificación de actualización; Los ejemplos incluyen la falta de permisos del sistema requeridos o la aplicación de datos no expone un ContentProvider en el URI esperado.

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

Integración de actualizaciones de zona horaria

Para habilitar la función de actualización de zona horaria, los OEM normalmente:

• Crea su propia aplicación de datos.
• Incluya las aplicaciones Actualizador y Datos en la compilación de la imagen del sistema.
• Configure el servidor del sistema para habilitar RulesManagerService.

Preparando

Antes de comenzar, los OEM deben revisar las siguientes políticas, garantía de calidad y consideraciones de seguridad:

• Cree una clave de firma específica de la aplicación para su aplicación de datos.
• Cree una estrategia de lanzamiento y control de versiones para las actualizaciones de zona horaria para comprender qué dispositivos se actualizarán y cómo pueden garantizar que las actualizaciones solo se instalen en los dispositivos que las necesitan. Por ejemplo, los OEM pueden querer tener una única aplicación de datos para todos sus dispositivos o pueden optar por tener diferentes aplicaciones 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 control de calidad.
• Comprenda si quieren utilizar datos de zona horaria de Android de AOSP o crear los suyos propios.

Creando una aplicación de datos

AOSP incluye todo el código fuente y las reglas de compilación necesarias para crear una aplicación 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 de la aplicación de datos real y objetivos adicionales para crear versiones de prueba de la aplicación de datos.

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

La aplicación de datos está diseñada para construirse con una compilación de tapas que produzca APK adecuados para agregarse a la imagen del sistema (para la versión inicial) y firmarse y distribuirse a través de una tienda de aplicaciones (para actualizaciones posteriores). Para obtener detalles sobre el uso de tapas, consulte Creación de la aplicación de datos usando tapas .

Los OEM deben instalar la aplicación de datos prediseñada en la imagen del sistema de un dispositivo en /system/priv-app . Para incluir APK prediseñados (generados por el proceso de compilación de tapas) en la imagen del sistema, los OEM pueden copiar los archivos de ejemplo en packages/apps/TimeZoneData/oem_template/data_app_prebuilt . Las plantillas de ejemplo también incluyen objetivos de compilación para incluir versiones de prueba de la aplicación de datos en conjuntos de pruebas.

Incluir las aplicaciones Actualizador y Datos en la imagen del sistema

Los OEM deben colocar los APK de la aplicación Updater y Data en el directorio /system/priv-app de la imagen del sistema. Para hacer esto, la compilación de la imagen del sistema debe incluir explícitamente los destinos prediseñados de la aplicación Updater y la aplicación Data.

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

Configurar el servidor del sistema

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

config_enableUpdateableTimeZoneRules

config_timeZoneRulesUpdateTrackingEnabled

config_timeZoneRulesDataPackage

config_timeZoneRulesUpdaterPackage

config_timeZoneRulesCheckTimeMillisAllowed

config_timeZoneRulesCheckRetryCount

Las anulaciones de configuración deben estar en la imagen del sistema (no en el proveedor ni en otro), ya que un dispositivo mal configurado puede negarse a arrancar. Si las anulaciones de configuración estuvieran en la imagen del proveedor, la actualización a una imagen del sistema sin una aplicación de datos (o con diferentes nombres de paquete de aplicación de datos/aplicación de actualización) se consideraría una configuración incorrecta.

pruebas xTS

xTS se refiere a cualquier conjunto de pruebas específico de OEM que sea similar a los conjuntos de pruebas estándar de Android que utilizan Tradefed (como CTS y VTS). Los OEM que tienen dichos conjuntos de pruebas pueden agregar las pruebas de actualización de la zona horaria de Android proporcionadas 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 una suite 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 de tiempo de compilación para incluir los APK de prueba prediseñados requeridos por la prueba.

Crear actualizaciones de zona horaria

Cuando la IANA publica un nuevo conjunto de reglas de zona horaria, el equipo de bibliotecas principales de Android genera parches para actualizar las versiones en AOSP. Los OEM que utilizan el sistema Android estándar y los archivos de distribución pueden recoger estas confirmaciones, usarlas para crear una nueva versión de su aplicación de datos y luego lanzar la nueva versión para actualizar sus dispositivos en producción.

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

Paso 1: Actualización del sistema/zona horaria y archivos de datos externos/UCI

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

El parche AOSP system/timezone contiene archivos actualizados en system/timezone/input_data y system/timezone/output_data . Los OEM que necesiten realizar correcciones locales adicionales pueden modificar los archivos de entrada y luego usar los archivos en 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 crea el APK de la aplicación de datos.

Paso 2: actualizar el código de versión de la aplicación de datos

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

Al crear la aplicación de datos utilizando archivos copiados de package/apps/TimeZoneData/oem_template/data_app , puede encontrar el código de versión/nombre de la versión aplicado 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 la versión de prueba deben ser superiores a la versión de la imagen del sistema). Para obtener más información, consulte el ejemplo de esquema de estrategia de código de versión ; Si se utiliza el esquema de ejemplo o un esquema similar, no es necesario actualizar los códigos de la versión de prueba porque se garantiza que serán superiores a los códigos de la versión real.

Paso 3: reconstruir, firmar, probar y publicar

En este paso, los OEM reconstruyen el APK usando tapas, firman el APK generado y luego prueban y lanzan el APK:

• Para dispositivos no lanzados (o al preparar una actualización del sistema para un dispositivo lanzado), envíe los nuevos APK en el directorio prediseñado de la aplicación de datos para garantizar que la imagen del sistema y las pruebas xTS tengan los APK más recientes. Los OEM deben probar que el nuevo archivo funcione correctamente (es decir, que pase CTS y cualquier prueba manual y automatizada específica del OEM).
• Para los dispositivos lanzados que ya no reciben actualizaciones del sistema, es posible que el APK firmado solo se publique a través de una tienda de aplicaciones.

Los OEM son responsables del control de calidad y de probar la aplicación de datos actualizada en sus dispositivos antes del lanzamiento.

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

La aplicación 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 anterior al descargado de la tienda de aplicaciones, se debe conservar la versión de la tienda de aplicaciones.

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

• Versión de formato de distribución (mayor + menor)
• 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 porque cada nivel de API generalmente está asociado con una nueva versión de ICU (lo que hace que los archivos de distribución sean incompatibles). En el futuro, Android puede cambiar esto para que un archivo de distribución pueda funcionar en varias versiones de la plataforma Android (y el nivel de API no se utiliza en el esquema de código de versión de la aplicación de datos).

Estrategia de código de versión de ejemplo

Este ejemplo de esquema de número de versiones garantiza que las versiones con formato de distribución superior reemplacen a las versiones con formato de distribución inferior. AndroidManifest.xml usa android:minSdkVersion para garantizar que los dispositivos antiguos no reciban versiones con un formato de distribución superior al que pueden manejar.

El esquema podría empaquetarse mejor si se usara binario en lugar de 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 aplicación 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.

• Los ejemplos 1 y 2 muestran dos versiones de APK para la misma versión de IANA 2017a con diferentes versiones de formatos principales. 2 es numéricamente mayor que 1, lo cual es necesario para garantizar que los dispositivos más nuevos reciban las versiones de formato superior. minSdkVersion garantiza que la versión P no se suministrará a los dispositivos O.
• El ejemplo 3 es una revisión/corrección para 1 y es numéricamente mayor que 1.
• Los ejemplos 4 y 5 muestran las versiones de 2017b para O-MR1 y P. Al ser numéricamente superiores, reemplazan las versiones anteriores de IANA/revisiones de Android de sus respectivos predecesores.
• Los ejemplos 6 y 7 muestran las versiones de 2018a para O-MR1 y P.
• El ejemplo 8 demuestra el uso de Y para reemplazar completamente el esquema Y=0.
• El ejemplo 9 demuestra el uso del espacio que queda entre 3 y 4 para volver a girar la 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 de O-MR1 en un dispositivo P porque tiene un número de versión inferior al de una versión de imagen del sistema P. Un dispositivo con una versión O-MR1 instalada en /data que luego recibe una actualización del sistema a P usa la versión /system con preferencia a la versión O-MR1 en /data porque la versión P siempre es superior a cualquier aplicación destinada a O-MR1. MR1.

Construyendo la aplicación de datos usando tapas

Los OEM son responsables de administrar la mayoría de los aspectos de la aplicación de datos de zona horaria y de configurar la imagen del sistema correctamente. La aplicación de datos está diseñada para construirse con una compilación de tapas que produzca APK adecuados para agregarse a la imagen del sistema (para la versión inicial) y firmarse y distribuirse a través de una tienda de aplicaciones (para actualizaciones posteriores).

Tapas es una versión simplificada del sistema de compilación de Android que utiliza un árbol de fuentes reducido para producir versiones distribuibles de aplicaciones. Los OEM familiarizados con el sistema de compilación normal de Android deben reconocer los archivos de compilación de la plataforma Android normal.

Creando el manifiesto

Por lo general, se logra un árbol de fuentes reducido con un archivo de manifiesto personalizado que hace referencia solo a los proyectos de Git que necesita el sistema de compilación y para compilar la aplicación. Después de seguir las instrucciones en Creación de una aplicación de datos , los OEM deben tener al menos dos proyectos Git específicos de OEM creados utilizando los archivos de plantilla en packages/apps/TimeZoneData/oem_template :

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

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

El siguiente fragmento de manifiesto contiene el conjunto mínimo de proyectos Git necesarios para admitir una compilación O-MR1 de la aplicación de datos de zona horaria. Los OEM deben agregar sus proyectos Git específicos de OEM (que generalmente incluyen un proyecto que contiene el certificado de firma) a este manifiesto y pueden configurar diferentes ramas en consecuencia.

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

Ejecutando la construcción de tapas

Una vez establecido el árbol de origen, invoque la compilación de tapas usando 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 exitosa genera archivos en el directorio out/dist para realizar pruebas. Estos archivos se pueden colocar en el directorio precompilado para incluirlos en la imagen del sistema y/o distribuirse a través de una tienda de aplicaciones para dispositivos compatibles.