En Android 10, los datos de zona horaria basados en APK ya no están disponibles mecanismo de actualización (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 incluyen el código de plataforma necesario para que los OEM habiliten. Actualizaciones basadas en APK para que los dispositivos se actualicen a Android 10 pueden seguir recibiendo actualizaciones de datos de zona horaria proporcionadas por socios a través del APK. Sin embargo, el mecanismo de actualización del APK no debe usarse en un dispositivo de producción. que también recibe actualizaciones de módulos como una actualización basada en un APK reemplaza a Actualización basada en APEX (es decir, un dispositivo que recibió una actualización de APK ignoraría actualizaciones basadas en APEX).
Actualizaciones de zonas horarias (Android 10 y versiones posteriores)
El módulo de datos de zona horaria compatible con Android 10 y más actualizaciones del horario de verano (DST) y las zonas horarias en dispositivos Android, la estandarización de datos que pueden cambiar con frecuencia para los datos religiosos, políticos y por razones geopolíticas.
Las actualizaciones usan el siguiente proceso:
- IANA publica una actualización de Time Zone Database publica una actualización en respuesta al que uno o más gobiernos cambien una regla de zona horaria en sus países.
- 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.
- El dispositivo del usuario final descarga la actualización, se reinicia y, luego, aplica la cambia, después de lo cual los datos de zona horaria del dispositivo contienen la nueva zona horaria datos 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: El mecanismo de actualización de datos de zona horaria basado en APK tiene se quitó por completo a partir de Android 14 y no se encuentra en el código fuente. Los socios deberán migrar completamente Zona horaria Módulo de línea principal
En Android 8.1 y Android 9, los OEM pueden usar un mecanismo basado en APK para enviar datos actualizados de las reglas de zona horaria en los dispositivos sin necesidad de una actualización del sistema. Este mecanismo permite a los usuarios recibir actualizaciones oportunas (por lo tanto, se extiende el la vida útil de un dispositivo Android) y permite a los socios de Android probar se actualiza la zona horaria independientemente de las actualizaciones de imagen del sistema.
El equipo de bibliotecas principales de Android proporciona los archivos de datos necesarios para actualización de las reglas de zona horaria en un dispositivo Android de stock Los OEM pueden optar por usar estas archivos de datos cuando crean actualizaciones de zona horaria para sus dispositivos o pueden crear sus archivos de datos propios si lo prefieres. En todos los casos, los OEM tienen el control de la calidad. control, pruebas, programación y lanzamiento de actualizaciones de las reglas de zona horaria para sus compatibles.
Datos y código fuente de la zona horaria de Android
Todos los dispositivos Android en stock, incluso aquellos que no usan esta función, necesitan la zona horaria
y debe enviarse con un conjunto predeterminado de datos de reglas de zona horaria en el
/system
. Luego, el código de la fuente
las siguientes bibliotecas en el árbol de fuentes de Android:
- Código administrado de
libcore/
(por ejemplo,java.util.TimeZone
) usatzdata
ytzlookup.xml
. - Código de biblioteca nativo en
bionic/
(por ejemplo, paramktime
, llamadas al sistema de hora local) usa el archivotzdata
. - El código de la biblioteca ICU4J/ICU4C en
external/icu/
usa icu archivo.dat
.
Estas bibliotecas realizan un seguimiento de los archivos superpuestos que pueden estar presentes en la
/data/misc/zoneinfo/current
. Se esperan archivos de superposición
para incluir datos mejorados de las 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 lo siguiente: ubicaciones primero:
- Los códigos
libcore/
ybionic/
usan la Copia/data
detzdata
ytzlookup.xml
archivos. - El código ICU4J/ICU4C usa los archivos en
/data
y recurre a archivos/system
para datos que no están presentes (para formatos, localizado cadenas, etc.).
Archivos de distribución
Los archivos de distribución .zip
contienen los archivos de datos necesarios para propagar la
/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 actualización de Android porque el contenido cambian con la versión de ICU, los requisitos de la plataforma de Android y otras versiones cambios. Android proporciona archivos de distribución para las versiones de Android compatibles de cada actualización de IANA (además de actualizar los archivos de sistema de la plataforma). Para mantener sus actualizados, los OEM pueden usar estos archivos de distribución o crear los suyos el árbol de fuentes de Android (que contiene las secuencias de comandos y otros archivos necesarios para generar archivos de distribución).
Componentes de la 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 y la instalación segura de los archivos que contiene. Transferir y la instalación requiere lo siguiente:
- Funcionalidad del servicio de la plataforma
(
timezone.RulesManagerService
), que está inhabilitado de forma predeterminada. Los OEMs deben habilitar la funcionalidad mediante la configuración.RulesManagerService
se ejecuta en el proceso y las etapas del servidor del sistema las operaciones de actualización de zona horaria escribiendo/data/misc/zoneinfo/staged
RulesManagerService
puede reemplazar o borrar las operaciones ya preparadas. -
TimeZoneUpdater
: una app del sistema que no se puede actualizar (es decir, la app de Actualizador). Los OEM deben incluir esta app en la imagen del sistema de dispositivos que usan la función. - OEM
TimeZoneData
: una aplicación de sistema actualizable (también conocida como la app de datos) que lleva los archivos de distribución al dispositivo y los convierte disponibles para la aplicación Updater. Los OEMs deben incluir esta app en la imagen del sistema de dispositivos que usan la función. -
tzdatacheck
: un objeto binario de inicio que se requiere para el funcionamiento correcto y seguro de las actualizaciones de zona horaria.
El árbol de fuentes de Android contiene código fuente genérico para lo anterior que el OEM puede usar sin modificaciones. Código de prueba para permitir que los OEM comprueben automáticamente que habilitaron la función correctamente.
Instalación de distribución
El proceso de instalación de distribución incluye los siguientes pasos:
- La app de datos se actualiza mediante una descarga en la tienda de aplicaciones o
transferencia. El proceso del servidor del sistema (mediante
timezone.RulesManagerServer/timezone.PackageTracker
clases) observa los cambios en el paquete de app de datos configurado y específico del OEM. de la fuente de datos.
Figura 1: Actualizaciones de la app de datos.
- El proceso del servidor del sistema activa una verificación de actualización cuando
transmitir un intent específico con un token único de un solo uso al Actualizador
Aplicación El servidor del sistema lleva un registro del token más reciente que generó para
puede determinar cuándo se completó la verificación más reciente que activó; Cualquier otro
y los tokens de acceso se ignoran.
Figura 2: Activar búsqueda de actualizaciones
- Durante la verificación de actualizaciones, la app de Updater realiza la
las siguientes tareas:
- Consulta el estado actual del dispositivo mediante una llamada a RulesManagerService.
Figura 3: Actualizaciones de la app de datos y llamada a RulesManagerService
- Consulta la app de datos a través de una URL de ContentProvider bien definida y
y las especificaciones de cada columna
para obtener información sobre la distribución.
Figura 4: Actualizaciones de apps de datos, información sobre distribución
- Consulta el estado actual del dispositivo mediante una llamada a RulesManagerService.
- La app Actualizador toma la acción adecuada según las
la información que tiene. Entre las acciones disponibles, se incluyen las siguientes:
- Solicita una instalación. Los datos de distribución se leen desde la app de datos y se pasa al RulesManagerService en el servidor del sistema. El RulesManagerService vuelve a confirmar que la versión y el contenido del formato de distribución adecuados para el dispositivo y organiza la instalación en etapa intermedia.
- Solicita una desinstalación (esto es poco común). Por ejemplo, si la actualización
Se está inhabilitando o desinstalando el APK en
/data
, y el dispositivo se volviendo a la versión presente en/system
. - No hacer nada. Ocurre cuando se descubre que la distribución de la app de datos no es válida.
Figura 5: Se completó la verificación.
- Reinicio y tzdatacheck La próxima vez que se inicie el dispositivo,
el objeto binario tzdatacheck ejecuta cualquier operación preparada. El objeto binario tzdatacheck puede
realizar las siguientes tareas:
- Para ejecutar la operación por etapas, controla la creación, el reemplazo
o borrar los archivos
/data/misc/zoneinfo/current
antes otros componentes del sistema se abrieron y comenzaron a usar los archivos. - Comprueba que los archivos de
/data
sean correctos para el archivo actual de la plataforma, que podría no ser el caso si el dispositivo acaba de recibir un 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 IANA sea igual o más reciente que la versión de
/system
Esto brinda protección contra una actualización del sistema que sale de un dispositivo. con datos de reglas de zona horaria más antiguos que los presentes en/system
imagen.
- Para ejecutar la operación por etapas, controla la creación, el reemplazo
o borrar los archivos
Fiabilidad
El proceso de instalación de extremo a extremo es asíncrono y se divide en tres SO procesos. En cualquier momento de la instalación, el dispositivo podría perder alimentación, funcionar sin espacio en el disco o con otros problemas, lo que hará que la verificación de instalación estar incompletos. En el mejor de los casos que no tienen éxito, la app Actualizador informa al sistema servidor que falló; y, en el peor de los casos, RulesManagerService no recibe ninguna llamada.
Para controlar esto, el código del servidor del sistema realiza un seguimiento se completó la verificación de actualizaciones y cuál es el último código de versión verificado de los datos la app lo es. 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 actualizaciones incompleta o datos inesperados En cuanto a la versión de la app, se activa espontáneamente una verificación de actualizaciones.
Seguridad
Cuando se habilita, el código RulesManagerService del servidor del sistema realiza varias verificaciones para garantizar que el sistema sea seguro de usar.
- Los problemas que indican que una imagen del sistema está mal configurada impiden que un dispositivo
el inicio; por ejemplo, una configuración incorrecta de Updater o Data, o
El actualizador o la app de datos no están en
/system/priv-app
. - Los problemas que indican que se instaló una app de datos incorrecta no evitan el dispositivo se inicia, pero evitan que se active una verificación de actualizaciones. ejemplos incluyen la falta de permisos de sistema necesarios o la aplicación de datos no expone una ContentProvider en el URI esperado.
Los permisos de archivo para los directorios /data/misc/zoneinfo
son los siguientes:
con reglas de SELinux. Al igual que con cualquier APK, la aplicación de datos debe estar firmada por el
misma clave que se usó para firmar la versión de /system/priv-app
. La app de datos es
se espera que tenga una clave y un nombre de paquete dedicados y específicos de OEM.
Cómo integrar 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 OEM deben revisar la siguiente política, control de calidad, y consideraciones de seguridad:
- Crear una clave de firma dedicada y específica de la app para su app de datos
- Crea una estrategia de lanzamiento y control de versiones para las actualizaciones de zona horaria entender qué dispositivos se actualizarán y cómo pueden garantizar que solo se instalan en los dispositivos que las necesitan. Por ejemplo, es posible que los OEMs quieran 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 influye en la elección del paquete el nombre, posiblemente los códigos de versión utilizados, y la estrategia de QA.
- Comprender si desea usar datos de disponibilidad de la zona horaria de Android del AOSP o crear una propia.
Crea una app de datos
AOSP incluye todas las reglas de compilación y el código fuente 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 de la app de datos real 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, aparecerá el ícono solo en Configuración > Apps.
La app de datos está diseñada para compilarse con una compilación de tapas. que produce APK adecuados para agregar a la imagen del sistema (para la versión) y se firman y se distribuyen a través de una tienda de aplicaciones (para las actualizaciones). Para obtener más información sobre el uso de tapas, consulta Cómo crear App de datos que usa tapas
Los OEMs deben instalar la app de datos compilada previamente en la imagen del sistema de un dispositivo en
/system/priv-app
Para incluir APK precompilados (generados por las tapas
proceso de compilación) en la imagen del sistema, los OEM pueden copiar los archivos de ejemplo en
packages/apps/TimeZoneData/oem_template/data_app_prebuilt
El
las plantillas de ejemplo también incluyen objetivos de compilación para incluir versiones de prueba del
App de datos en paquetes de pruebas.
Cómo incluir las apps de datos y el Actualizador en la imagen del sistema
Los OEM deben colocar el APK de la app de datos y del Actualizador en la
Directorio /system/priv-app
de la imagen del sistema. Para ello, el
la compilación de la imagen del sistema debe incluir explícitamente la app de Updater y la app de datos compiladas previamente
objetivos.
La app Updater debe firmarse con la clave de la plataforma y debe incluirse como cualquier
otra app del sistema. El objetivo se define en
packages/apps/TimeZoneUpdater
como TimeZoneUpdater
El
La inclusión de apps de datos es específica del OEM y depende del nombre de destino elegido para el
la compilación previa.
Configura el servidor del sistema
Para habilitar las actualizaciones de zona horaria, los OEM pueden configurar el servidor del sistema
anular las propiedades de configuración definidas en
frameworks/base/core/res/res/values/config.xml
Propiedad | Descripción | ¿Es necesaria la anulación? |
---|---|---|
config_enableUpdateableTimeZoneRules |
Se debe configurar en true para habilitar RulesManagerService. |
Sí |
config_timeZoneRulesUpdateTrackingEnabled |
Se debe establecer en true para que el sistema detecte los cambios en
la aplicación de datos. |
Sí |
config_timeZoneRulesDataPackage |
Es el nombre del paquete de la app de datos específica del OEM. | Sí |
config_timeZoneRulesUpdaterPackage |
Configurado para la app de Updater predeterminada. Cambiar solo cuando se proporcione un implementación diferente de la app de Updater. | No |
config_timeZoneRulesCheckTimeMillisAllowed |
Tiempo transcurrido entre la activación de una búsqueda de actualizaciones por el RulesManagerService y una respuesta de instalación, desinstalación o no hacer nada. Después del en este punto, se puede generar un activador espontáneo de confiabilidad. | No |
config_timeZoneRulesCheckRetryCount |
La cantidad de verificaciones secuenciales de actualizaciones incorrectas que se permiten antes de RulesManagerService deja de generar más. | No |
Las anulaciones de configuración deben estar en la imagen del sistema (no del proveedor ni de otro tipo). ya que un dispositivo mal configurado puede rechazar su inicio. Si la configuración anula estaban en la imagen del proveedor, actualizando a una imagen del sistema sin una app de datos (o con diferentes nombres de paquetes de aplicaciones de Data o de actualizaciones) se considerará como una mala configuración.
Pruebas de xTS
xTS se refiere a cualquier paquete de pruebas específico de OEM que sea similar al de Android estándar. conjuntos de pruebas que usan Tradefed (como CTS y VTS) OEM que tienen esas pruebas pueden agregar las pruebas de actualización de zona horaria de Android que se proporcionan en la siguiente ubicaciones:
packages/apps/TimeZoneData/testing/xts
incluye el código necesarias para las pruebas funcionales automatizadas básicas.packages/apps/TimeZoneData/oem_template/xts
contiene una muestra Estructura de directorios 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 en su necesidades empresariales.packages/apps/TimeZoneData/oem_template/data_app_prebuilt
contiene la configuración de tiempo de compilación para incluir los APK de prueba compilados previamente necesarios antes de la prueba.
Crea actualizaciones de zona horaria
Cuando IANA lanza un nuevo conjunto de reglas de zona horaria, las bibliotecas principales de Android genera parches para actualizar versiones en AOSP. OEM que usan el paquete de Android los archivos de sistema y distribución pueden recoger estas confirmaciones, usarlas para crear una nueva de la app de datos y, luego, lanzar la nueva versión para actualizar los dispositivos en producción.
Como las apps de datos contienen archivos de distribución estrechamente unidos a las versiones de Android, Los OEMs deben crear una versión nueva de la app de datos para todas las compatibles. Versión de Android que un OEM quiere actualizar. Por ejemplo, si un OEM quiere proporcionar actualizaciones para Android 8.1, 9 y 10 deben completar el proceso tres veces.
Paso 1: Actualiza los archivos de datos del sistema/zona horaria y externos/icu
En este paso, los OEMs analizan las confirmaciones de Android para
system/timezone
y external/icu
de
ramas release-dev en AOSP y aplicará esas confirmaciones a su copia de
el código fuente de Android.
El parche del AOSP para el sistema y la zona horaria contiene archivos actualizados en
system/timezone/input_data
y
system/timezone/output_data
los OEM que necesiten realizar más acciones
puede modificar los archivos de entrada y, luego, usarlos 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 es
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 la versión de la app de datos. La compilación
selecciona automáticamente distro.zip
, pero la versión nueva del
La app de datos debe tener un código de versión nuevo para que se reconozca como nuevo y se use para lo siguiente:
reemplazar una app de datos precargada o una app de datos instalada en un dispositivo por una anterior
actualización.
Cuando compilas la app de datos con archivos copiados desde
package/apps/TimeZoneData/oem_template/data_app
, puedes encontrar la
Código de versión/nombre de versión aplicado al APK en Android.mk
:
TIME_ZONE_DATA_APP_VERSION_CODE := TIME_ZONE_DATA_APP_VERSION_NAME :=
Puedes encontrar entradas similares en testing/Android.mk
(sin embargo, el
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 la estrategia de código de versión de ejemplo
esquema; Si se usa el esquema de ejemplo o uno similar, la prueba
los códigos de versión no necesitan actualizarse porque se garantiza que serán superiores
que los códigos de versión reales.
Paso 3: Vuelve a compilar, firma, prueba y lanza
En este paso, los OEMs vuelven a compilar el APK con tapas, firman el archivo APK y, luego, pruébalo y publícalo:
- Para dispositivos que aún no se han lanzado (o cuando se prepara una actualización del sistema para una dispositivo lanzado), envía los APK nuevos en el directorio compilado previamente de la app de datos para asegurarte de que las pruebas de imagen del sistema y xTS tengan los APK más recientes. Los OEMs deben prueba que el archivo nuevo funcione correctamente (es decir, que pase el CTS y cualquier pruebas automatizadas y manuales específicas del OEM).
- Para los dispositivos lanzados que ya no reciben actualizaciones del sistema, el APK firmado solo se publican en una tienda de aplicaciones.
Los OEM son responsables del control de calidad y de probar la versión actualizada App de datos en sus dispositivos antes del lanzamiento
Estrategia de código de la versión de la app de datos
La app de datos debe tener un adecuado estrategia de control de versiones para garantizar que los dispositivos reciban los APK correctos. Para Por ejemplo, si se recibe una actualización del sistema que contiene un APK anterior a uno descargada 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 en formato de distribución (principal y secundaria)
- Un número de versión incremental (opaco)
En la actualidad, el nivel de API de la plataforma está muy relacionado con la versión del formato de distribución. ya que cada nivel de API generalmente se asocia con una nueva versión de ICU (que hace que los archivos de distribución sean incompatibles). En el futuro, Android podría cambiar esto que un archivo de distribución pueda funcionar en varias versiones de la plataforma de Android (y la API no se usa en el esquema de código de la versión de la app de datos).
Ejemplo de estrategia de código de versión
Este ejemplo de esquema de números de control de versiones garantiza que el formato de distribución
anteriores sustituyen a las versiones de formato de distribución inferiores.
AndroidManifest.xml
usa android:minSdkVersion
para
asegúrate de que los dispositivos antiguos no reciban versiones con un formato de distribución más alto
de la que pueden manejar.
Figura 6: Ejemplo de estrategia de código de versión.
Ejemplo | Valor | Propósito |
---|---|---|
Sí | Reservado | Permite futuros esquemas o APK de prueba alternativos. Inicial (de manera implícita) 0. Como el tipo subyacente es un tipo int firmado de 32 bits, este esquema admite hasta dos revisiones futuras del esquema de numeración. |
01 | Versión del formato principal | Hace un seguimiento de la versión del formato principal de 3 dígitos decimales. El formato de distribución admite Aquí se usan 3 dígitos decimales, pero solo 2. Es poco probable que llegue a 100 dado el incremento importante esperado por nivel de API. La versión principal 1 es equivalente. hasta el nivel de API 27. |
1 | Versión de formato secundario | Hace un seguimiento de la versión de formato secundario de 3 dígitos decimales. El formato de distribución admite En este caso, se utiliza solo 3 dígitos decimales, pero solo 1. Es poco probable que llegue a 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 | Número decimal asignado a pedido. Incluye brechas para permitir anuncios intersticiales y las actualizaciones que se realizarán si es necesario. |
El esquema podría empaquetarse mejor si se usaran objetos binarios en lugar de decimales, pero este esquema tiene la ventaja de ser legible por humanos. Si el rango de números completo se agote, 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,
ejemplo: major=001,minor=001,iana=2017a, revision=1,respin=2
.
Los ejemplos se muestran en la siguiente tabla.
# | Código de versión | minSdkVersion | {Major format version},{Minor format version},{reglas de IANA versión},{Revisión} |
---|---|---|---|
1 | 11000010 | O‐MR1 | mayor=001,menor=001,iana=2017a,revisión=1 |
2 | 21000010 | P | 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 | P | mayor=002,menor=001,iana=2017b,revisión=1 |
6 | 11000040 | O‐MR1 | mayor=001,menor=001,iana=2018a,revisión=1 |
7 | 21000030 | P | 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 formatos principales. 2 es numéricamente mayor que 1, lo que significa necesarias para garantizar que los dispositivos más nuevos reciban las versiones de formato más altos. El minSdkVersion se asegura de que la versión P no se suministre a dispositivos O.
- El ejemplo 3 es una revisión/corrección de 1 y su valor numérico es mayor que 1.
- Los ejemplos 4 y 5 muestran las versiones de 2017b para O-MR1 y P. Siendo numérica superior, reemplazan las versiones anteriores de IANA o Android de sus respectivas de sus predecesores.
- En los ejemplos 6 y 7, se muestran las versiones de 2018a para O-MR1 y P.
- En el ejemplo 8, se demuestra el uso de Y para reemplazar por completo el esquema Y=0.
- En el ejemplo 9, se muestra el uso del espacio izquierdo entre 3 y 4 para volver a girar. el APK.
Como cada dispositivo se envía con un APK predeterminado y con la versión adecuada en la
de 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 inferior al de una versión de imagen de sistema P. R
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
en lugar de
la versión O-MR1 en /data
porque la versión P siempre es posterior.
que cualquier otra app diseñada para el 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 de forma correcta. La app de datos está diseñada para compilarse con una compilación de tapas que produce APK adecuados para agregar la imagen del sistema (para la versión inicial) y que se firma y distribuye a través de un tienda de aplicaciones (para actualizaciones posteriores).
Tapas es una versión reducida de la compilación de Android. que usa un árbol de fuentes reducido para producir versiones distribuibles de de Google Chat. Los OEM familiarizados con el sistema de compilación normal de Android deben reconocer el de compilación de la compilación normal de la plataforma de Android.
Crea el manifiesto
Un árbol de fuentes reducido generalmente se logra 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
. Después de seguir las instrucciones de
Crear una app de datos, los OEMs deben tener
al menos dos proyectos de Git específicos de OEM creados con los archivos de plantilla de
packages/apps/TimeZoneData/oem_template
:
- Un proyecto de Git contiene archivos de aplicaciones, como el manifiesto y el
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 APK de prueba que pueden usar las pruebas de xTS. - Un proyecto de Git contiene los APK firmados que produjo la compilación de la app para Inclusión en la compilación de imágenes del sistema y en las pruebas de xTS.
La compilación de apps aprovecha varios proyectos de Git que se comparten con el de compilación de la plataforma ni contener bibliotecas de código independientes de OEM.
El siguiente fragmento de manifiesto contiene el conjunto mínimo de proyectos de Git necesaria para admitir una compilación O-MR1 de la app de datos de zona horaria. OEM deben agregar sus proyectos de Git específicos de OEM (que suelen incluir un proyecto que contiene el certificado de firma) a este manifiesto y puede 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
Una vez establecido el árbol de fuentes, invoca la compilación 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
y pruebas. Estos archivos se pueden colocar en el directorio de compilaciones previas para incluirlos en
de la imagen del sistema o se distribuyen a través de una tienda de aplicaciones
dispositivos.