Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Reglas de zona horaria

Android 10 desaprueba el tiempo mecanismo de actualización de datos de la zona a base de APK (disponible en Android 8.1 y Android 9) y lo reemplaza con un mecanismo de actualización del módulo basado en APEX . AOSP continúa incluyendo el código de plataforma necesario para que los fabricantes de equipos originales habiliten las 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 recibe actualizaciones de módulo, ya que una actualización basada en APK reemplaza a 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 Time Zone Data compatible con Android 10 y versiones posteriores actualiza el horario de verano (DST) y las zonas horarias en los dispositivos Android, estandarizando los datos que pueden cambiar con frecuencia por razones religiosas, políticas y geopolíticas.

Las actualizaciones utilizan el siguiente proceso:

  1. IANA publica una actualización de la base de datos de zona horaria lanza una actualización en respuesta a uno o más gobiernos cambiantes 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 de lo cual los datos de la zona horaria del dispositivo contienen los datos de la nueva zona horaria de la actualización.

Para más detalles sobre los módulos, consulte modular los componentes del sistema .

Actualizaciones de zona horaria (Android 8.1–9)

En Android 8.1 y Android 9, los OEM pueden utilizar un mecanismo basado en APK para enviar datos de reglas de zona horaria actualizadas 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 las actualizaciones de la zona horaria independientemente de las actualizaciones de imágenes del sistema.

El equipo de bibliotecas centrales 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 mantienen el control sobre la garantía de calidad / pruebas, el tiempo 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 de valores, incluso aquellos que no utilizan esta característica, el tiempo de necesidad reglas de zona de datos y deben enviar con un conjunto predeterminado de datos de reglas de zona horaria en el /system partición. Luego, estos datos son utilizados por el código de las siguientes bibliotecas en el árbol de origen de Android:

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

Estas bibliotecas realizar un seguimiento de los archivos de plantillas que pueden estar presentes en el /data/misc/zoneinfo/current directorio. Se espera que los archivos de superposición para contener la mejora de datos de reglas de zona horaria, lo que permite a los dispositivos ser actualizados sin cambiar /system .

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

  • libcore/ y bionic/ código de utilizar el /data copia de la tzdata y tzlookup.xml archivos.
  • ICU4J / ICU4C utilice el código de los archivos en /data y posterior caída a /system archivos de datos que no está presente (para los formatos, las cadenas localizadas, etc.).

Archivos de distribución

Distro .zip archivos contienen los archivos de datos necesarios para rellenar el /data/misc/zoneinfo/current directorio. 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 de Android y otros cambios de la versión. Android proporciona archivos de distribución para versiones compatibles de Android para cada actualización de 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 que contiene. La transferencia y la instalación requieren lo siguiente:

  • Funcionalidad de servicio de la plataforma ( timezone.RulesManagerService ), que está desactivado por defecto. Los OEM deben habilitar la funcionalidad a través de la configuración. RulesManagerService carreras en las operaciones de actualización de zona de proceso de servidor del sistema y el tiempo de las etapas por escrito a /data/misc/zoneinfo/staged . RulesManagerService también puede reemplazar o ya eliminar las operaciones por etapas.
  • TimeZoneUpdater , una aplicación del sistema nonupdateable (también conocido como la aplicación de actualización). Los OEM deben incluir esta aplicación en la imagen del sistema de los dispositivos que utilizan la función.
  • OEM TimeZoneData , una aplicación del sistema actualizable (también conocido como la aplicación de datos) que lleva distribuciones archivos en el dispositivo y hace que estén disponibles para la aplicación de actualización. Los OEM deben incluir esta aplicación en la imagen del sistema de los dispositivos que utilizan la función.
  • tzdatacheck , un binario en tiempo de arranque necesario para el funcionamiento correcto y seguro de cambios de zona horaria.

El árbol de fuentes de Android contiene código fuente genérico para los componentes anteriores, que el OEM puede optar por utilizar sin modificaciones. Código de ensayo se proporciona para permitir a los fabricantes de equipos para comprobar automáticamente que han activado la función correctamente.

Instalación de distribución

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

  1. Aplicación de datos se actualiza a través de una tienda de descargas de aplicaciones o de carga lateral. El proceso de servidor del sistema (a través de timezone.RulesManagerServer/timezone.PackageTracker clases) relojes para los cambios en el, específica de OEM configurado, el nombre del paquete de datos de aplicación.

    Actualizaciones de la aplicación de datos
    Actualizaciones de la aplicación Figura 1. Datos
  2. Los desencadenantes de procesos de servidor del sistema una comprobación de actualización mediante la difusión de un dirigidos intención con una, de un solo uso único de contadores a la App 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.

    Activación de actualización
    Comprobación de actualización Figura 2. Disparador
  3. Durante la verificación de actualización, la aplicación de actualización realiza las siguientes tareas:
    • Consulta el estado actual del dispositivo llamando al RulesManagerService.

      Llamar a RulesManagerService
      Figura 3. Datos actualizaciones de aplicaciones, llamando 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.

      Obtener información de distribución
      Actualizaciones de la aplicación Figura 4. Datos, obtener información sobre distro
  4. El actualizador de aplicación toma la acción apropiada basándose en 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 vuelve a confirmar que la versión y el contenido del formato de distribución son apropiados para el dispositivo y prepara la instalación.
    • Solicitar una desinstalación (esto es raro). Por ejemplo, si el APK actualizado en /data está siendo desactivado o desinstalado y el dispositivo está volviendo 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.

    Verificar completa
    Figura 5. Comprobar completa
  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:
    • Ejecutar la operación de puesta en escena por el manejo de la creación, sustitución y / o eliminación de la /data/misc/zoneinfo/current archivos antes de otros componentes del sistema han abierto y comenzaron a utilizar los archivos.
    • Compruebe que los archivos en /data son correctos para la versión de la plataforma actual, que podría no ser el caso si el dispositivo acaba de recibir una actualización del sistema y la versión de formato de distribución ha cambiado.
    • Asegúrese de que la IANA gobierna versión es la misma o más reciente que la versión de /system . Esto protege contra una actualización del sistema dejando a un dispositivo con datos de reglas de zona horaria más viejo que está presente en el /system imagen.

Fiabilidad

El proceso de instalación de un extremo a otro es asíncrono 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 sea incompleta. En el mejor de los casos sin éxito, 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 verificado de la aplicación de datos. Cuando el dispositivo está inactivo y se está cargando, 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 de RulesManagerService en el servidor del sistema realiza varias verificaciones para garantizar que el sistema sea seguro de usar.

  • Los problemas que indican una imagen del sistema mal configurada impiden el arranque de un dispositivo; ejemplos incluyen una mala configuración aplicación de actualización o de datos o el actualizador o datos de aplicaciones no estar en /system/priv-app .
  • Los problemas que indican que se ha instalado una aplicación de datos incorrecta no impiden que se inicie un dispositivo, pero sí evitan 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.

Permisos de archivo para los /data/misc/zoneinfo directorios se imponen mediante reglas de SELinux. Al igual que con cualquier APK, la aplicación de datos debe ser firmado por la misma clave utilizada para firmar el /system/priv-app versión. Se espera que la aplicación de datos tenga un nombre de paquete y una clave dedicados y específicos del OEM.

Integración de actualizaciones de zona horaria

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

  • Cree su propia aplicación de datos.
  • Incluya las aplicaciones Updater y Data 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 la siguiente política, garantía de calidad y consideraciones de seguridad:

  • Cree una clave de firma específica de la aplicación dedicada para su aplicación de datos.
  • Cree una estrategia de versión y control de versiones para las actualizaciones de zona horaria a fin de 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 sola 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 los datos de la zona horaria de Android de AOSP o crear los suyos propios.

Crear una aplicación de datos

AOSP incluye todas las reglas del código de fuentes y de construcción necesarios para crear una aplicación de datos en packages/apps/TimeZoneData , con instrucciones y plantillas de ejemplo para AndroidManifest.xml y otros archivos que se encuentran en packages/apps/TimeZoneData/oem_template . Las plantillas de ejemplo incluyen tanto un objetivo de compilación para el APK de la aplicación de datos real como 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 icono, nombre, traducciones y otros detalles. Sin embargo, como la aplicación de datos no puede ser lanzado, el icono sólo aparece en la pantalla Configuración> Aplicaciones.

La aplicación de datos está destinado a ser construido con una acumulación de tapas que produce APK adecuados para ser añadido a la imagen del sistema (para la versión inicial) y firmado y distribuido a través de una tienda de aplicaciones (para actualizaciones posteriores). Para más detalles sobre el uso de tapas, ver Construcción de la aplicación de datos usando tapas .

OEM deben instalar la aplicación de pre-compilados de datos de la imagen del sistema de un dispositivo en /system/priv-app . Para incluir APK creados previamente (generados por el proceso de acumulació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.

Incluyendo las aplicaciones Updater y Data en la imagen del sistema

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

La aplicación Updater debe estar firmada con la clave de la 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 puede configurar el servidor de sistema de sobreescribiendo propiedades de configuración definidos en frameworks/base/core/res/res/values/config.xml .

Propiedad Descripción ¿Se requiere anulación?
config_enableUpdateableTimeZoneRules
Debe establecerse en true para que el RulesManagerService.
config_timeZoneRulesUpdateTrackingEnabled
Debe establecerse en true tener el sistema de escuchar los cambios a la aplicación de datos.
config_timeZoneRulesDataPackage
Nombre del paquete de la aplicación de datos específica de OEM.
config_timeZoneRulesUpdaterPackage
Configurado para la aplicación de actualización predeterminada. Cambie solo cuando proporcione una implementación de aplicación de actualización diferente. No
config_timeZoneRulesCheckTimeMillisAllowed
Tiempo permitido entre la activación de una verificación de actualización por parte de RulesManagerService y una respuesta de instalación, desinstalación o no hacer nada. Después de este punto, se puede generar un disparador de confiabilidad espontáneo. No
config_timeZoneRulesCheckRetryCount
El número de comprobaciones de actualización secuenciales fallidas permitidas antes de que RulesManagerService deje de generar más. No

Las modificaciones de configuración deben estar en la imagen del sistema (no en el proveedor u otro) ya que un dispositivo mal configurado puede negarse a arrancar. Si las modificaciones de la 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 paquetes de aplicaciones / actualizaciones de datos) se consideraría una configuración incorrecta.

prueba 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 estos conjuntos de pruebas pueden agregar las pruebas de actualización de la zona horaria de Android que se proporcionan en las siguientes ubicaciones:

  • packages/apps/TimeZoneData/testing/xts incluye el código necesario para realizar pruebas funcionales automatizadas básica.
  • packages/apps/TimeZoneData/oem_template/xts contiene una estructura de directorio de ejemplo para la inclusión de pruebas en un Tradefed-como XTS suite. Al igual que con otros directorios de plantillas, se espera que los OEM copien y personalicen según sus necesidades.
  • packages/apps/TimeZoneData/oem_template/data_app_prebuilt contiene configuración de tiempo de construcción para la inclusión de los archivos APK de prueba pre-construidos requeridos por la prueba.

Crear actualizaciones de zona horaria

Cuando IANA lanza un nuevo conjunto de reglas de zona horaria, el equipo de bibliotecas centrales de Android genera parches para actualizar las versiones en AOSP. Los OEM que utilizan el sistema Android de serie y los archivos de distribución pueden recoger estas confirmaciones, utilizarlas 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.

Dado que las aplicaciones de datos contienen distribuciones archivos estrechamente ligadas a las versiones de Android, los fabricantes deben crear una nueva versión de la aplicación de datos para cada versión de Android compatible que un OEM quiere actualización. Por ejemplo, si un OEM desea proporcionar actualizaciones para dispositivos con 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 / icu

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

El parche AOSP sistema / zona horaria contiene archivos en actualiza system/timezone/input_data y system/timezone/output_data . OEMs que necesitan para hacer correcciones locales adicionales pueden modificar los archivos de entrada a continuación, utilizar 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 de forma automática cuando se construyó la aplicación de datos APK.

Paso 2: actualización del 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 acumulación, selecciona automáticamente distro.zip , pero la nueva versión de la aplicación de datos debe tener un nuevo código de la versión por lo que se reconoce como nuevo y se utiliza para reemplazar una aplicación de datos precargados o una aplicación de datos instalado en un dispositivo mediante una actualización anterior.

Cuando la construcción de la aplicación de datos usando archivos copiados de package/apps/TimeZoneData/oem_template/data_app , se puede encontrar el nombre código de la versión / versión aplicada a la APK en el Android.mk :

TIME_ZONE_DATA_APP_VERSION_CODE :=
TIME_ZONE_DATA_APP_VERSION_NAME :=

Entradas similares se pueden encontrar en testing/Android.mk (sin embargo, los códigos de versión de prueba debe ser mayor que la versión de la imagen del sistema). Para más detalles, ver el esquema de la estrategia ejemplo código de la 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 más altos que los códigos de la versión real.

Paso 3: reconstrucción, firma, prueba y publicación

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

  • Para dispositivos inéditos (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 asegurarse de que la imagen del sistema y las pruebas de xTS tengan los APK más recientes. Los OEM deben probar que el nuevo archivo funciona correctamente (es decir, pasa CTS y cualquier prueba automatizada y manual específica de 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 de garantizar la calidad y 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 adecuadas para garantizar que los dispositivos reciben los APK correctas. Por ejemplo, si se recibe una actualización del sistema que contiene un APK más antiguo que uno descargado de la tienda de aplicaciones, se debe conservar la versión de la tienda de aplicaciones.

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

  • Versión de formato de distribución (mayor + menor)
  • Un número de versión creciente (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 múltiples versiones de la plataforma Android (y el nivel de API no se usa 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 esquema de número de versiones de ejemplo garantiza que las versiones de formato de distribución superior reemplacen a las versiones de formato de distribución inferior. AndroidManifest.xml usos android:minSdkVersion para asegurar que los dispositivos antiguos no reciben versiones con una versión de mayor formato de distribución de lo que pueden manejar.

Verificación de versión
Figura 6. Ejemplo estrategia código de versión
Ejemplo Valor Objetivo
Y Reservado Permite futuros esquemas alternativos / APK de prueba. Inicialmente es (implícitamente) 0. Debido a que el tipo subyacente es un tipo int de 32 bits con signo, este esquema admite hasta dos revisiones futuras del esquema de numeración.
01 Versión de formato principal Realiza un seguimiento de la versión del formato principal de 3 dígitos decimales. El formato de distribución admite 3 dígitos decimales, pero aquí solo se usan 2 dígitos. Es poco probable que llegue a 100 dado el incremento importante esperado por nivel de API. La versión principal 1 es equivalente al nivel de API 27.
1 Versión de formato menor Realiza un seguimiento de la versión de formato menor de 3 dígitos decimales. El formato de distribución admite 3 dígitos decimales, pero aquí solo se usa 1 dígito. Es poco probable que llegue a 10.
X Reservado Es 0 para las versiones de producción (y puede ser diferente para los APK de prueba).
ZZZZZ Número de versión opaco Número decimal asignado a pedido. Incluye espacios para permitir que se realicen actualizaciones intersticiales si es necesario.

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 de números completo, el nombre del paquete de la aplicación de datos podría cambiar.

El nombre de la versión es una representación legible 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 {Versión de formato principal}, {Versión de formato secundario}, {Versión de reglas de IANA}, {Revisión}
1 11000010 O-MR1 mayor = 001, menor = 001, iana = 2017a, revisión = 1
2 21000010 PAG mayor = 002, menor = 001, iana = 2017a, revisión = 1
3 11000020 O-MR1 mayor = 001, menor = 001, iana = 2017a, revisión = 2
4 11000030 O-MR1 mayor = 001, menor = 001, iana = 2017b, revisión = 1
5 21000020 PAG mayor = 002, menor = 001, iana = 2017b, revisión = 1
6 11000040 O-MR1 mayor = 001, menor = 001, iana = 2018a, revisión = 1
7 21000030 PAG mayor = 002, menor = 001, iana = 2018a, revisión = 1
8 1123456789 - -
9 11000021 O-MR1 mayor = 001, menor = 001, iana = 2017a, revisión = 2, respin = 2
  • Los ejemplos 1 y 2 muestran dos versiones de APK para la misma versión de IANA 2017a con diferentes versiones de formato principal. 2 es numéricamente mayor que 1, lo cual es necesario para garantizar que los dispositivos más nuevos reciban las versiones de formato más alto. MinSdkVersion asegura que la versión P no se suministrará a los dispositivos O.
  • El ejemplo 3 es una revisión / corrección de 1 y es numéricamente mayor que 1.
  • Los ejemplos 4 y 5 muestran las versiones 2017b para O-MR1 y P. Al ser numéricamente más altas, reemplazan las versiones anteriores de IANA / revisiones de Android de sus respectivos predecesores.
  • Los ejemplos 6 y 7 muestran las versiones 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 dejado entre 3 y 4 para volver a girar 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 porque tiene un número de versión más bajo que una versión de imagen del sistema P. Un dispositivo con una versión O-MR1 instalado en /data que recibe a continuación una actualización del sistema a P utiliza el /system versión con preferencia a la versión O-MR1 en /data porque la versión P es siempre mayor que cualquier aplicación destinada a O- 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á destinado a ser construido con una acumulación de tapas que produce APK adecuados para ser añadido a la imagen del sistema (para la versión inicial) y firmado y distribuido a través de una tienda de aplicaciones (para actualizaciones posteriores).

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

Creando el manifiesto

Por lo general, se logra un árbol de origen reducido con un archivo de manifiesto personalizado que se refiere 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 de Creación de una aplicación de datos , los OEM debe tener al menos dos proyectos Git OEM-específicos creados mediante el uso de los archivos de plantilla bajo packages/apps/TimeZoneData/oem_template :

  • Un proyecto Git contiene archivos de aplicaciones, tales como el manifiesto y todos los archivos requeridos para crear el archivo APK aplicación (por ejemplo, vendor/ oem /apps/TimeZoneData ). Este proyecto también contiene reglas de compilación para APK de prueba que las pruebas xTS pueden usar.
  • Un proyecto de 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 de 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 que contienen bibliotecas de código independientes de 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 aplicación de datos de zona horaria. Los OEM deben agregar sus proyectos de Git específicos de OEM (que normalmente 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="master"
        clone_depth="1" />
    <repo-hooks
        in-project="platform/tools/repohooks"
        enabled-list="pre-upload" />

Ejecutando la construcción de tapas

Una vez establecida la estructura de directorios, invocar las tapas construir 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 acumulación éxito genera archivos en el out/dist del directorio para la prueba. Estos archivos pueden colocarse en el directorio precompilado para su inclusión en la imagen del sistema y / o distribuirse a través de una tienda de aplicaciones para dispositivos compatibles.