En esta página, se resumen las funciones principales de la versión de Android 9 y se incluyen vínculos a información adicional. Los resúmenes de las funciones se ordenan según la ubicación de la documentación de las funciones en este sitio. Consulta las Actualizaciones del sitio de agosto de 2018 para obtener información sobre las secciones que se trasladaron y el cambio de nombres.
Compilación
Imagen genérica del sistema (GSI)
Una imagen genérica del sistema (GSI) es una imagen del sistema con configuraciones adaptadas para dispositivos Android. Una imagen genérica del sistema (GSI) incluye información sobre las diferencias entre las GSI de los dispositivos que se lanzan con Android 9 y de los que se actualizan a Android 9.
Arquitectura
Capa de abstracción de hardware (HAL)
Retrocompatibilidad con el framework de HIDL
La verificación de retrocompatibilidad con el framework de HIDL es una manera de verificar la retrocompatibilidad del framework.
HAL disponibles dinámicamente
Las HAL disponibles dinámicamente admiten el cierre dinámico de los subsistemas de hardware de Android cuando no están en uso o no se necesitan.
HIDL
MemoryBlock de HIDL
MemoryBlock de HIDL es una capa abstracta compilada en hidl_memory, HIDL @1.0::IAllocator y HIDL @1.0::IMapper. Está diseñada para servicios HIDL con varios bloques de memoria que comparten una sola pila de memoria.
Superposiciones del árbol de dispositivos
Superposiciones comprimidas
Android 9 y las versiones posteriores admiten superposiciones comprimidas en la imagen de superposición de BLOB del árbol de dispositivos (DTBO) cuando se usa la versión 1 del encabezado de tabla del árbol de dispositivos.
Actualizaciones de DTO
Android 9 y las versiones posteriores requieren que el bootloader pase el BLOB del árbol de dispositivos unificado al kernel antes de que se modifiquen las propiedades definidas en las superposiciones del árbol de dispositivos (DTO).
Versiones del encabezado de imagen de DTBO
Android 9 y las versiones posteriores incluyen un campo de versión en el encabezado de imagen de DTBO.
Verificación de DTBO
Android 9 y las versiones posteriores requieren una partición de DTBO. Si deseas agregar nodos o realizar cambios a las propiedades en el DT de SoC, el bootloader debe superponer dinámicamente un DT específico para dispositivos por sobre el DT de SoC. Para obtener más información, consulta Cómo compilar y verificar.
Cumplimiento del kernel
Android 9 y las versiones posteriores incluyen requisitos que afectan el kernel, sus interfaces y el uso de DTBO. Para obtener más información, consulta las siguientes páginas:
- Lanzamientos y actualizaciones estables de kernel
- Núcleos comunes de Android
- Requisitos modulares de kernel
- Requisitos de interfaz
- Superposiciones del árbol de dispositivos
NDK de proveedor
Cambios de diseño
Si deseas obtener información sobre los cambios de diseño del VNDK en Android 9 y las versiones posteriores, consulta las siguientes páginas:
- Kit de desarrollo nativo del proveedor (VNDK)
- Asistencia para el sistema de compilación del VNDK
- Herramienta de definición del VNDK
- Directorios, reglas y políticas
- Extensiones del VNDK
- Espacio de nombres del vinculador
Verificador de ABI
En la página Estabilidad de ABI, se describe el verificador de la interfaz binaria de la aplicación (ABI), que garantiza que los cambios en las bibliotecas del VNDK mantengan el cumplimiento de la ABI.
Resúmenes del VNDK
Una imagen del sistema puede usar resúmenes del VNDK para proporcionar las bibliotecas del VNDK correctas a las imágenes del proveedor, incluso cuando las imágenes del sistema y el proveedor se compilan a partir de versiones diferentes de Android.
Objeto de interfaz de proveedor (objeto VINTF)
En las siguientes páginas de la sección Objeto de interfaz de proveedor, se describen las actualizaciones en Android 9 y las versiones posteriores:
Calendario de baja de HIDL
En las siguientes páginas, se describe cómo Android da de baja y quita las HAL de HIDL:
Bootloader
Particiones de producto
Android 9 y las versiones posteriores admiten la compilación de particiones de /product con el sistema de compilación de Android. Anteriormente, Android 8.x aplicaba la separación de componentes específicos de sistema en chip (SoC) de la partición /system a la partición /vendor sin dedicar espacio para los componentes específicos de OEM compilados a partir del sistema de compilación de Android.
Cumplimiento del motivo de inicio canónico
En la página del Motivo de inicio canónico, se describen los cambios realizados en la especificación del motivo de inicio del bootloader en Android 9 y versiones posteriores.
Sistema como raíz
Todos los dispositivos que se lanzan con Android 9 y versiones posteriores deben usar system-as-root, que fusiona ramdisk.img en system.img (también conocido como no-ramdisk), que, a su vez, se monta como rootfs.
Versión del encabezado de imagen de arranque
En Android 9 y versiones posteriores, el encabezado de la imagen de arranque tiene un campo para indicar la versión del encabezado. El bootloader debe verificar el campo de versión y analizar el encabezado según corresponda.
DTBO en recuperación
A fin de evitar las fallas de actualización inalámbrica debido a discrepancias entre la imagen de recuperación y la partición de DTBO en los dispositivos que no sean A/B, la imagen de recuperación debe incluir información de la imagen de DTBO.
Pantalla
Cortes de pantalla
Los cortes de pantalla permiten a los desarrolladores de apps crear experiencias envolventes de borde a borde al mismo tiempo que dejan espacio para sensores importantes en el frente de los dispositivos.
Cómo rotar sugerencias
Las actualizaciones del comportamiento de rotación de la pantalla en Android 9 y las versiones posteriores permiten que el usuario fije la rotación de la pantalla en modo horizontal o vertical, incluso si cambia la posición del dispositivo.
Transiciones de app sincronizadas
Las transiciones de app sincronizadas permiten animaciones de transiciones de app nuevas.
Clasificación de texto (anteriormente TEXTCLASSIFIER)
Android 9 y las versiones posteriores incluyen un servicio de clasificación de texto, que es la manera recomendada de implementar la clasificación de texto, y una implementación de servicio predeterminada.
Amplia gama de colores
Android 9 y las versiones posteriores permiten colores de amplia gama, como los siguientes:
- Alto rango dinámico (HDR)
- Procesamiento de contenido en el espacio de color BT2020, pero no como un espacio de datos de objetivo final
Para usar la amplia gama de colores, la pila de pantalla completa de un dispositivo (como una pantalla, un compositor de hardware y la GPU) deben admitir la amplia gama de colores o formatos de búfer. No es necesario que los dispositivos admitan contenido de amplia gama, incluso si el hardware sí lo hace. Sin embargo, la amplia gama de colores debe estar habilitada para aprovechar el hardware al máximo. Para evitar una experiencia visual inconsistente, se debe desactivar la amplia gama de colores durante el tiempo de ejecución.
Compatibilidad
Documento de definición de compatibilidad de Android (CDD)
El Documento de definición de compatibilidad de Android 9 se basa en versiones anteriores e incluye actualizaciones sobre funciones nuevas y cambios en los requisitos de funcionalidades lanzadas previamente.
Configuración
Mejores widgets de apps
El framework de widget de apps para Android ofrece mayor visibilidad de las interacciones del usuario, sobre todo cuando un usuario borra o agrega widgets manualmente. Esta funcionalidad viene incluida de forma predeterminada con Launcher3.
Los fabricantes deben actualizar las apps de selector (incluidas con los dispositivos) para admitir esta función si no está basada en Launcher3. Los OEM deben ofrecer compatibilidad con el campo widgetFeatures nuevo en su selector predeterminado.
Ten en cuenta que la función solo se ejecuta correctamente cuando los selectores la implementan como se espera. El AOSP incluye una implementación de muestra. Consulta el ID de cambio Iccd6f965fa3d61992244a365efc242122292c0ca del AOSP para ver el código de muestra proporcionado.
Notificaciones de cambio de estado del dispositivo a los instaladores de paquetes
Se puede enviar un anuncio de sistema protegido a las apps que retienen el permiso INSTALL_PACKAGES cada vez que haya un cambio en propiedades como la configuración regional o la densidad de la pantalla. Se pueden registrar los receptores en el manifiesto y se activa un proceso para recibir el anuncio. Esto es útil para los instaladores de paquetes que desean instalar componentes de apps adicionales en caso de cambios, lo que no es común, ya que los cambios de configuración que activan este anuncio son inusuales.
El código fuente de notificaciones de cambio de estado del dispositivo está en platform/frameworks/base:
api/system-current.txtcore/java/android/content/Intent.javacore/res/AndroidManifest.xmlservices/core/java/com/android/server/am/ActivityManagerService.java
Arquitectura de la información
Los cambios en la arquitectura de la información de la app de Configuración ofrecen más funcionalidades, y la implementación es más sencilla.
Pruebas
Atest
La herramienta de línea de comandos Atest permite compilar, instalar y ejecutar pruebas de Android a nivel local, lo que agiliza significativamente las ejecuciones repetidas de pruebas sin requerir conocimiento sobre las opciones de la línea de comandos del agente de prueba de la Federación de Comercio.
Conjunto de pruebas de compatibilidad (CTS)
Descargas de CTS
Los paquetes de CTS compatibles con Android 9 están disponibles en la página Descargas de CTS. Se puede sincronizar el código fuente de las pruebas incluidas con la etiqueta android-cts-9.0_r1 en el árbol de código abierto.
Opciones de CTS
En el caso de Android 9, CTS v2 obtiene el comando y el argumento que se muestran a continuación:
run retryreintenta hacer todas las pruebas que fallaron o que no se ejecutaron en las sesiones anteriores.‘--shard-countfragmenta una ejecución de CTS en una cantidad determinada de partes independientes para ejecutarlas en varios dispositivos en paralelo.
Además, se agregó el comando --retry-type, antes indocumentado, a la misma referencia de comando de consola de CTS v2.
Servicio de Elemento seguro (SE)
El servicio de Elemento seguro busca elementos seguros globales compatibles con la plataforma. Para ello, identifica si los dispositivos tienen alguna implementación SE HAL y, de ser así, cuántas. Esto se usa como base para probar la API y la implementación del elemento seguro subyacente.
Caja de fusión de sensores
La caja de fusión de sensores se usa en la prueba de fusión de sensores y en la prueba de sincronización de varias cámaras del Conjunto de prueba de imagen de la cámara (ITS de la cámara), y proporciona un entorno de prueba coherente para medir la precisión de la marca de tiempo de la cámara y otros sensores de los teléfonos Android. Consulta las siguientes páginas para obtener más información:
- En la Guía de inicio rápido de la caja de fusión de sensores, se incluyen pasos para configurar por primera vez la prueba de fusión de sensores y la caja de fusión de sensores.
- El Conjunto de cajas de fusión de sensores incluye pasos para ensamblar una caja de fusión de sensores.
ITS integrado de campo visual amplio
El ITS integrado de campo visual amplio es un sistema automático diseñado para probar los sistemas de cámara de campo visual amplio (WFoV) y campo visual regular (RFoV) en el ITS de la cámara.
Conjunto de pruebas de proveedores (VTS)
Arquitectura del controlador de host
La arquitectura del controlador de host de VTS es la arquitectura del framework de prueba de VTS integrado con su servicio de pruebas basado en la nube.
Prueba HAL del servicio con reconocimiento de nombre
La prueba de HAL del servicio con reconocimiento de nombre de VTS permite obtener el nombre del servicio de una instancia de HAL determinada en función del dispositivo en el que se ejecutan las pruebas de VTS.
Verificación de capacidad de prueba de HAL
La verificación de capacidad de prueba de HAL de VTS incluye un método de tiempo de ejecución para usar la configuración del dispositivo a fin de identificar las pruebas de VTS que deberían omitirse en esa orientación por dispositivo.
Infraestructura de pruebas automatizada
La infraestructura de pruebas automatizada es una infraestructura de VTS para las pruebas automatizadas de VTS, CTS u otras pruebas en dispositivos de socios que ejecutan la imagen genérica del sistema (GSI) del AOSP.
Depuración
Telemetría avanzada
En Android, la telemetría es el proceso de recopilar automáticamente información de uso y diagnóstico sobre el dispositivo, el sistema Android y las apps. En las versiones anteriores de Android, la pila de telemetría era limitada y no recopilaba la información necesaria para identificar y solucionar problemas con el dispositivo, las apps o la confiabilidad del sistema. Eso hacía que identificar las causas raíz de los problemas fuera difícil, por no decir imposible.
Android 9 incluye la función de telemetría de statsd, que recopila mejores datos más rápido para solucionar esta deficiencia. statsd recopila estadísticas sobre el proceso, la batería y el uso de la app, además de las fallas. Los datos se analizan y se utilizan para mejorar productos, hardware y servicios.
Consulta frameworks/base/cmds/statsd/ para obtener más información.
Funciones de seguridad
Firma de aplicaciones
El esquema de firma de APK v3 admite la rotación de clave de APK.
Soporte biométrico
Android 9 incluye la clase pública BiometricPrompt, que las apps pueden usar para integrar la compatibilidad con la autenticación biométrica de manera agnóstica en cuanto al dispositivo y la modalidad. Si deseas obtener más información sobre cómo integrar tu pila de datos biométricos para incluir BiometricPrompt, consulta Datos biométricos.
Análisis dinámico
Android 9 admite más herramientas de análisis y mitigación de la explotación.
Integridad del flujo de control (CFI)
La integridad del flujo de control (CFI) es un mecanismo de seguridad que prohíbe los cambios en el gráfico del flujo de control de un objeto binario compilado, lo que dificulta considerablemente que se produzcan ataques de ese tipo.
CFI de kernel
Además del CFI del sistema, que está habilitado de forma predeterminada, Android 9 y las versiones posteriores admiten la integridad del flujo de control (CFI) de kernel.
Encriptación
Encriptación basada en archivos (FBE)
Se actualizó la encriptación basada en archivos (FBE) para que funcione con el almacenamiento adoptable. Los dispositivos nuevos deben usar la encriptación basada en archivos en lugar de la encriptación de disco completo.
Encriptación de metadatos
Android 9 y las versiones posteriores admiten la encriptación de metadatos cuando hay compatibilidad con el hardware. Con la encriptación de metadatos, una sola clave presente al momento del inicio usa la encriptación basada en archivos para encriptar el contenido no encriptado.
Almacén de claves
Android 9 y las versiones posteriores incluyen Keymaster 4, que tiene estas funciones.
StrongBox
Android 9 y las versiones posteriores admiten las claves del almacén de claves de Android, que se almacenan y se usan en una CPU separada y diseñada específicamente para aplicaciones de alta seguridad, como un elemento seguro (SE) incorporado. StrongBox Keymaster es una implementación de la HAL de Keymaster en un hardware discreto seguro. Un StrongBox tiene lo siguiente:
- CPU discreta
- Almacenamiento seguro integral
- Generador de número al azar verdadero de alta calidad
- Empaquetado a prueba de manipulaciones
- Resistencia al canal lateral
Importación de clave segura
Para importar una clave a Keymaster 4 de manera segura, se encripta una clave creada fuera del dispositivo con una especificación de las autorizaciones que definen cómo se puede usar la clave.
Compatibilidad con 3DES
Keymaster 4 incluye 3DES para ofrecer compatibilidad con los sistemas heredados que usan 3DES.
Vinculación de versión
A fin de admitir la estructura modular de Treble y romper la vinculación entre system.img y boot.img, Keymaster 4 cambió el modelo de vinculación de versión de la clave con el objetivo de tener niveles de parche separados para cada partición. Gracias a ello, cada partición se actualiza independientemente y, al mismo tiempo, se ofrece protección contra reversiones.
API de Confirmación de protección de Android
Los dispositivos admitidos que se lanzan con Android 9 instalado ofrecen a los desarrolladores la capacidad de usar la API de Configuración de protección de Android.
Con esta API, las apps pueden usar una instancia de ConfirmationPrompt para mostrarle al usuario un mensaje en el que se le pida que apruebe una afirmación breve. Esta afirmación permite que una app reconfirme que el usuario quiere completar una transacción sensible, como realizar un pago.
SELinux
Zona de pruebas de SELinux por app
La zona de pruebas de la aplicación tiene casos de prueba y protecciones nuevas para garantizar que todas las apps sin privilegios orientadas a Android 9 y versiones posteriores usen zonas de prueba de SELinux individuales.
Cambios de Treble SELinux
Las actualizaciones de SELinux de Treble en Android 9 y versiones posteriores se documentan en varias páginas en la sección de SELinux.
Init de proveedor
El init de proveedor usa un dominio de SELinux separado a fin de ejecutar comandos /vendor con permisos específicos según proveedores para cerrar la brecha en la división entre el sistema y el proveedor de Treble.
Propiedades del sistema
Android 9 restringe las propiedades del sistema y evita que se compartan innecesariamente entre las particiones de system y vendor. Además, establece un método para garantizar la coherencia entre las propiedades del sistema compartido.
Pruebas de atributos de SELinux
Android 9 incluye pruebas de tiempo de compilación nuevas que garantizan que todos los archivos en ubicaciones específicas tengan los atributos apropiados.
Por ejemplo, todos los archivos en sysfs tienen el atributo sysfs_type requerido.
Audio
Efectos de audio de alta resolución
Las actualizaciones de los efectos de audio de alta resolución incluyen la conversión del procesamiento de efectos de int16 a formato flotante y aumentos en las pistas de salida simultáneas del cliente, la memoria máxima del cliente y el servidor, y el total de pistas combinadas.
Cámara
Cámaras USB externas
Android 9 y las versiones posteriores admiten el uso de cámaras USB plug-and-play (es decir, cámaras web) que usan la API de Android Camera2 estándar y la interfaz de HIDL de la cámara.
Registro de movimiento
Los dispositivos de cámara pueden anunciar la capacidad de seguimiento del movimiento.
Compatibilidad con varias cámaras
La compatibilidad con varias cámaras incluye la compatibilidad de la API para dispositivos con varias cámaras a través de un dispositivo de cámara lógico nuevo formado por dos o más dispositivos de cámara físicos que apuntan en la misma dirección.
Parámetros de sesión
La implementación de los parámetros de sesión puede reducir los retrasos, ya que permite que los clientes de la cámara configuren de manera activa un subconjunto de parámetros de solicitud costosos como parte de la fase de inicialización de la sesión de captura.
Búfer de un solo productor y varios consumidores
El transporte de búfer de cámara de un solo productor y varios consumidores es un conjunto de métodos que permite que los clientes de la cámara agreguen y quiten superficies de salida de manera dinámica al mismo tiempo que la sesión de captura está activa y la transmisión de la cámara está en curso.
Conectividad
Llamadas y mensajes
Implementación de planes de datos
Android 9 y las versiones posteriores ofrecen asistencia mejorada para los proveedores que implementen planes de datos con las API de SubcriptionPlan.
Apps de llamadas de terceros
Android 9 y las versiones posteriores ofrecen API que permiten que las apps de llamadas de terceros (3P) procesen llamadas entrantes simultáneas mediante proveedores y registren las llamadas en el sistema.
Proveedor
Identificación del proveedor
En Android 9, el AOSP agrega una base de datos de ID de proveedor para ayudar en la identificación del proveedor. La base de datos ofrece una manera común de identificar a los proveedores para minimizar las experiencias de apps fragmentadas y de lógica duplicada.
eSIM
La tarjeta SIM integrada (eSIM o eUICC) es la tecnología más reciente que permite a los usuarios descargar el perfil de un proveedor y activar el servicio de un proveedor sin tener una tarjeta SIM física. En Android 9 y las versiones posteriores, el framework de Android ofrece API estándar para acceder a la eSIM y administrar los perfiles de suscripción. Para obtener más información, consulta:
Compatibilidad con varias SIM para la configuración de IMS
Android 9 y las versiones posteriores ofrecen mejoras en la configuración del usuario para el subsistema multimedia de IP (IMS). Se puede configurar el LTE de voz superpuesta (VoLTE), la videollamada y la llamada por Wi-Fi por cada suscripción, en lugar de compartir la configuración en todas las suscripciones.
Transmisiones del estado de la SIM
En Android 9 y las versiones posteriores, Intent.ACTION_SIM_STATE_CHANGED deja de estar disponible y se agregan dos transmisiones distintas para el estado de la tarjeta y el estado de aplicación de la tarjeta: TelephonyManager.ACTION_SIM_CARD_STATE_CHANGED y TelephonyManager.ACTION_SIM_APPLICATION_STATE_CHANGED.
Con estos cambios, los receptores que solo necesitan saber si hay tarjeta presente no tienen que escuchar los cambios de estado de una aplicación, mientras que los receptores que solo necesitan saber si las aplicaciones de una tarjeta están listas no tienen que escuchar los cambios en el estado de la tarjeta.
Las dos transmisiones nuevas son @SystemApis y no son fijas. Solo los receptores con el permiso READ_PRIVILEGED_PHONE_STATE pueden recibir las transmisiones.
No se vuelven a transmitir los intents cuando desbloqueas el dispositivo. Los receptores que dependen de las transmisiones enviadas antes del desbloqueo deben usar directBootAware o deben consultar el estado después del desbloqueo del usuario. Se pueden consultar los estados mediante las API correspondientes en TelephonyManager: getSimCardState() y getSimApplicationState().
Wi-Fi
Wi-Fi del proveedor
La función Wi-Fi del proveedor permite que los dispositivos se conecten automáticamente a las redes de Wi-Fi implementadas por el proveedor. En áreas de alta congestión o cobertura móvil mínima, como un estadio o una estación de tren subterránea, el Wi-Fi del proveedor permite mejorar la conectividad y aligera el tráfico.
Aleatorización de MAC
La aleatorización de MAC permite que los dispositivos usen direcciones de MAC aleatorias cuando sondean redes nuevas sin estar asociados actualmente a una red. En Android 9 y las versiones posteriores, se puede habilitar una opción para desarrolladores a fin de provocar que un dispositivo use una dirección de MAC aleatoria cuando se conecte a una red de Wi-Fi.
Activar Wi-Fi automáticamente
Cuando se habilita la función Activar Wi-Fi automáticamente, se restablece la conexión cada vez que el dispositivo está cerca de una red Wi-Fi guardada con un indicador de intensidad de señal recibida (RSSI) relativa suficientemente alto.
Tiempo de ida y vuelta (RTT) de Wi-Fi
La función Tiempo de ida y vuelta (RTT) de Wi-Fi permite que los dispositivos midan la distancia a otros dispositivos compatibles, ya sean puntos de acceso (PA) o pares con Wi-Fi Aware (si el dispositivo admite dicha tecnología). La función está integrada en el protocolo IEEE 802.11mc y permite que las apps usen el reconocimiento y la precisión de ubicación mejoradas.
Mejoras en la puntuación de Wi-Fi
Los modelos mejorados de puntuación de Wi-Fi determinan rápidamente y con precisión cuándo un dispositivo debe salir de una red Wi-Fi a la que está conectado o entrar a una nueva. Esos modelos ofrecen una experiencia confiable y fluida para los usuarios, ya que evitan las brechas de conectividad.
Revisa y ajusta los valores de RSSI en los recursos config.xml, sobre todo, en los siguientes:
config_wifi_framework_wifi_score_bad_rssi_threshold_5GHzconfig_wifi_framework_wifi_score_entry_rssi_threshold_5GHzconfig_wifi_framework_wifi_score_bad_rssi_threshold_24GHzconfig_wifi_framework_wifi_score_entry_rssi_threshold_24GHz
Simultaneidad de STA/AP de Wi-Fi
La simultaneidad de STA/AP de Wi-Fi permite que los dispositivos funcionen simultáneamente en los modos estación (STA) y punto de acceso (AP). En el caso de los dispositivos compatibles con Wi-Fi simultáneo de doble banda (DBS), se incorporan capacidades como no interrumpir el Wi-Fi de STA cuando un usuario quiere habilitar un hotspot (SoftAP).
Mejoras de WiFiStateMachine
WifiStateMachine es la clase principal que se usa para controlar la actividad de Wi-Fi, coordinar la entrada del usuario (modos operativos: hotspot, escanear, conectar o apagado) y controlar las acciones de la red de Wi-Fi (como buscar o conectar).
En Android 9 y versiones posteriores, se rediseñaron el código del framework de Wi-Fi y la implementación de WifiStateMachine, lo que redujo el tamaño del código, permitió una lógica de control de Wi-Fi más fácil de seguir, mejoró el nivel de detalle del control y aumentó la cobertura y la calidad de las pruebas de unidades.
En un nivel más alto, WifiStateMachine permite que el Wi-Fi esté en uno de los siguientes cuatro estados:
- Modo de cliente (se puede conectar y escanear)
- Modo de solo escaneo
- Modo de SoftAP (hotspot de Wi-Fi)
- Inhabilitado (Wi-Fi desactivado por completo)
Cada modo de Wi-Fi tiene diferentes requisitos a fin de ejecutar servicios y se debe configurar de manera coherente, limitado al control de los eventos relevantes para su funcionamiento. La implementación nueva restringe el código a los eventos relacionados con ese modo, lo que reduce el tiempo de depuración y el riesgo de introducir errores nuevos debido a la complejidad. Además del manejo explícito en la funcionalidad del modo, la administración de subprocesos se procesa de forma coherente y se elimina el uso de los canales asíncronos como mecanismo para la sincronización.
Actualizaciones de permisos de Wi-Fi
En Android 9 y versiones posteriores, se habilitan de forma predeterminada los permisos de la app CHANGE_WIFI_STATE. Puedes inhabilitar el permiso de cualquier app en la página de configuración en Configuración > Apps y notificaciones > Acceso especial de apps > Control de Wi-Fi.
Las apps deben poder manejar casos en los que no se otorgue el permiso de CHANGE_WIFI_STATE.
Para validar este comportamiento, ejecuta las pruebas manuales y de roboelectric.
Para las pruebas manuales:
- Ve a Configuración > Apps y notificaciones > Acceso especial de apps > Control de Wi-Fi.
- Selecciona y desactiva el permiso de tu app.
- Verifica que tu app pueda manejar una situación en la que no se otorgue el permiso
CHANGE_WIFI_STATE.
Baja de WPS
Por problemas de seguridad, se dio de baja Wi-Fi Protected Setup (WPS) en WiFiManager y no está habilitado en Android 9 y versiones posteriores. Sin embargo, WiFiDirect todavía usa WPS en el solicitante de WPA.
Gráficos
Implementación
API de Vulkan 1.1
Android 9 y las versiones posteriores admiten la implementación de la API de gráficos de Vulkan 1.1.
Herramienta WinScope para el seguimiento de la transición de ventanas
Android 9 y las versiones posteriores incluyen la herramienta WinScope para el seguimiento de la transición de ventanas. WinScope proporciona infraestructura y herramientas para registrar y analizar el estado del administrador de ventanas durante las transiciones y después de ellas. Permite registrar y llevar a cabo transiciones de ventanas al mismo tiempo que se registran todos los estados del administrador de ventanas pertinente en un archivo de registro. Puedes usar esos datos para volver a reproducir la transición y avanzar en ella.
El código fuente de la herramienta WinScope está en platform/development/tools/winscope.
Interacción
Audio en automóviles
En Audio en automóviles, se describe la arquitectura de audio de las implementaciones de Android relacionadas con automóviles.
La HAL de Redes neuronales (NN) define una abstracción de los distintos aceleradores. Los controladores de los aceleradores deben cumplir con esta HAL.
HAL de vehículo
En Propiedades de vehículo, se describen los cambios en la interfaz de la HAL de vehículo.
Selección de satélite de GNSS
Cuando se trabaja con las HAL (v1.1+) nuevas del sistema satelital de navegación global (GNSS), el framework de Android supervisa la configuración de Android. Los socios pueden cambiar la configuración de los servicios de Google Play u otras actualizaciones del sistema. Esta configuración le indica a la HAL del GNSS si no deberían usarse determinados satélites del GNSS. Puede ser útil en caso de errores persistentes de constelación o satélite del GNSS, o bien para reaccionar más rápido ante problemas de implementación de la HAL del GNSS que puedan ocurrir cuando se combinan constelaciones con diferentes sistemas de tiempo y eventos externos, como desplazamientos de números de semanas, días o segundos intercalares.
Modelo de hardware GNSS
En Android 9, la versión 1.1 de HAL del GNSS o las versiones posteriores pueden pasar información sobre la API de hardware a la plataforma. La plataforma necesita implementar la interfaz de IGnssCallback y pasar el procesamiento a la HAL. La HAL del GNSS pasa la información sobre el modelo de hardware con el método de LocationManager#getGnssHardwareModelName(). Los fabricantes de dispositivos deben trabajar con los proveedores de la HAL del GNSS para brindar esta información siempre que sea posible.
Permisos
Cómo configurar actualizaciones de control de acceso a discreción (DAC)
En Cómo configurar el control de acceso a discreción (DAC), puedes encontrar actualizaciones del mecanismo de ID de Android (AID) para extender las capacidades del sistema de archivos.
Cómo incluir en una lista blanca permisos de apps con privilegios
En Android 9 y versiones posteriores, si hay permisos que deben rechazarse, edita el XML para usar la etiqueta deny-permission en lugar de permission, que se usaba en las actualizaciones anteriores.
Datos
Mejoras en la estimación del ancho de banda
Android 9 ofrece asistencia mejorada para la estimación del ancho de banda. Las apps de Android pueden configurar de manera más apropiada la resolución de las videollamadas y la transmisión de video por Internet si pueden acceder al ancho de banda de datos disponible.
En los dispositivos que ejecutan Android 6.0 o versiones posteriores, un emisor que desee obtener una estimación del ancho de banda de una red móvil llama a ConnectivityManager.requestBandwidthUpdate() y el marco de trabajo podría proporcionar un ancho de llamada estimado por enlace descendente.
Sin embargo, en los dispositivos con Android 9 o versiones posteriores, se activa automáticamente la devolución de llamada de onCapabilitiesChanged() cuando hay un cambio significativo en el ancho de banda estimado y llamar a requestBandwidthUpdate() es una no-op; los getLinkDownstreamBandwidthKbps() y getLinkUpstreamBandwidthKbps() asociados se completan con información actualizada que proporciona la capa física.
Además, los dispositivos pueden verificar los anchos de banda móviles de LTE mediante ServiceState.getCellBandwidths().
Esto permite que las aplicaciones determinen cuánto ancho de banda (frecuencia) está disponible en una celda determinada. La información sobre el ancho de banda de la celda está disponible en un menú oculto de manera que los verificadores de campos puedan comprobar la información más actual.
Control de tráfico de eBPF
La herramienta de tráfico de red de eBPF usa una combinación de implementación de espacio del usuario y kernel para supervisar el uso de red en un dispositivo desde el último inicio del dispositivo. Esta herramienta proporciona funcionalidades adicionales, como etiquetado de socket, separación de tráfico en primer plano y en segundo plano, y firewall por UID para bloquear el acceso a la red de las apps según el estado del dispositivo.
Cómo restablecer en API inferiores
Ahora los dispositivos pueden restaurarse a partir de versiones futuras del sistema operativo. Esto es particularmente útil cuando un usuario actualiza su teléfono, pero luego se le pierde o rompe.
Si un OEM modifica los agentes de copia de seguridad de uno de los paquetes del sistema (Android, sistema, configuración), esos agentes deben restaurar los conjuntos de copias de seguridad que se crearon en versiones posteriores de la plataforma sin fallar y con una restauración al menos parcial de los datos.
Procura usar un validador para verificar los valores no válidos de un conjunto determinado de datos de copia de seguridad y restaurar datos válidos únicamente, como en core/java/android/provider/SettingsValidators.java.
La función está activada de forma predeterminada. La función SettingsBackupAgent para restaurar a partir de versiones futuras se puede desactivar mediante Settings.Global.OVERRIDE_SETTINGS_PROVIDER_RESTORE_ANY_VERSION. No se requiere ninguna implementación adicional, a menos que el fabricante del dispositivo extienda uno de los agentes de copia de seguridad incluidos en la ROM (o que agregue un agente personalizado).
Esta función permite restaurar el sistema a partir de versiones futuras de la plataforma. Sin embargo, es posible que los datos restaurados no estén completos. Las instrucciones que figuran a continuación se aplican a los siguientes agentes de copia de seguridad.
PackageManagerBackupAgent admite versiones futuras de los datos de copia de seguridad mediante el control de versiones de formato; las extensiones deben ser compatibles con el código de restauración actual o seguir las instrucciones en la clase, lo que incluye transmitir las constantes apropiadas.
SystemBackupAgent especifica
restoreAnyVersion = falseen Android 9 y versiones posteriores. No admite una restauración a partir de versiones posteriores de la API.SettingsBackupAgent especifica
restoreAnyVersion = trueen Android 9 y versiones posteriores. El soporte parcial existe a través de validadores. Se puede restablecer una configuración a partir de una versión de API superior si existe un validador aplicable en el SO de destino. Todas las configuraciones que se agreguen deben estar acompañadas por su validador. Verifica la clase para obtener más detalles.Todos los agentes de copia de seguridad personalizados incluidos en la ROM deben aumentar el código de la versión cada vez que se realice un cambio incompatible en el formato de datos de la copia de respaldo y garantizar
restoreAnyVersion = false(la opción predeterminada) si el agente no está preparado para procesar los datos de copia de seguridad de una versión futura de su código.
Empresa
Mejoras en el perfil administrado
Los cambios de UX en los perfiles administrados facilitan la identificación, el acceso y el control del perfil administrado para los usuarios.
Cómo pausar actualizaciones inalámbricas
Un @SystemApi nuevo permite que el propietario de un dispositivo pause de manera indefinida las actualizaciones inalámbricas, incluidas las actualizaciones de seguridad.
Rendimiento
Health 2.0
Android 9 y las versiones posteriores incluyen HAL 2.0 android.hardware.health, una actualización de versión importante de HAL health@1.0. Para obtener más información, consulta las siguientes páginas:
Almacenamiento en caché de APK
Android 9 y las versiones posteriores incluyen una solución de almacenamiento en caché de APK para la instalación rápida de apps precargadas en un dispositivo que admite particiones A/B. Los OEM pueden colocar las precargas y las apps populares en la memoria caché de APK almacenadas principalmente en la partición B vacía en dispositivos nuevos con particiones A/B sin afectar de manera negativa el espacio de datos del usuario.
Optimización guiada por perfil (PGO)
Android 9 y las versiones posteriores usan la optimización guiada por perfil de Clang (PGO) en los módulos de Android nativos que tienen reglas de compilación de diseño.
Registro de escritura anticipada (WAL)
Un modo especial de SQLiteDatabase llamado registro de escritura anticipada (WAL) de compatibilidad permite que una base de datos use journal_mode=WAL al mismo tiempo que mantiene un máximo de una conexión por base de datos.
Tiempos de inicio
Android 9 cambia la optimización del tiempo de inicio según lo descrito en Cómo optimizar los tiempos de inicio.
Energía
Restricciones en segundo plano
Android 9 y las versiones posteriores incluyen restricciones en segundo plano que permiten que los usuarios restrinjan apps que podrían agotar la batería. El sistema también puede sugerir la inhabilitación de apps que afecten de manera negativa el estado de un dispositivo.
Dispositivos sin batería
Android 9 maneja los dispositivos sin batería de manera más efectiva que las actualizaciones anteriores. Android 9 quita de los dispositivos sin batería el código que infiere de forma predeterminada que hay una batería cargada al 100% y en buen estado con una lectura de temperatura normal en el termistor.