Notas de la versión de Android 9

Esta página resume las funciones principales de la versión de Android 9 y proporciona enlaces a información adicional. Estos resúmenes de funciones están organizados según la ubicación de la documentación de la función en este sitio. Consulte las actualizaciones del sitio de agosto de 2018 para obtener una guía sobre cómo mover y cambiar el nombre de las secciones.

Construir

Imagen genérica del sistema (GSI)

Una imagen genérica del sistema (GSI) es una imagen del sistema con configuraciones ajustadas para dispositivos Android. La imagen genérica del sistema (GSI) incluye detalles sobre las diferencias entre las GSI para dispositivos que se inician con Android 9 y dispositivos que se actualizan a Android 9.

Arquitectura

Capa de abstracción de hardware (HAL)

Compatibilidad con versiones anteriores del marco HIDL

La verificación de compatibilidad con versiones anteriores del marco HIDL es un método para verificar la compatibilidad con versiones anteriores del marco.

HAL disponibles dinámicamente

Los HAL disponibles dinámicamente admiten el apagado dinámico de los subsistemas de hardware de Android cuando no están en uso o no son necesarios.

HIDL

Bloque de memoria HIDL

HIDL MemoryBlock es una capa abstracta construida sobre hidl_memory , HIDL @1.0::IAllocator y HIDL @1.0::IMapper . Está diseñado para servicios HIDL que tienen múltiples bloques de memoria que comparten un único montón de memoria.

Superposiciones del árbol de dispositivos

superposiciones comprimidas

Android 9 y versiones posteriores incluyen compatibilidad con superposiciones comprimidas en la imagen de superposición de blobs del árbol de dispositivos (DTBO) cuando se usa la versión 1 del encabezado de la tabla del árbol de dispositivos.

Actualizaciones de DTO

Android 9 y versiones posteriores requieren que el gestor de arranque pase el blob del árbol de dispositivos unificado al kernel antes de modificar las propiedades definidas en las superposiciones del árbol de dispositivos (DTO) .

Versionado del encabezado de imagen DTBO

Android 9 y versiones posteriores incluyen un campo de versión en el encabezado de la imagen DTBO.

Verificación DTBO

Android 9 y superiores requieren una partición DTBO. Para agregar nodos o realizar cambios en las propiedades en el DT del SoC, el gestor de arranque debe superponer dinámicamente un DT específico del dispositivo sobre el DT del SoC. Para obtener más información, consulte Compilación y verificación .

Cumplimiento del núcleo

Android 9 y superiores incluyen requisitos que afectan al kernel, sus interfaces y el uso de DTBO. Para obtener más información, consulte estas páginas:

Proveedor NDK

Cambios de diseño

Para obtener información sobre los cambios de diseño de VNDK en Android 9 y versiones posteriores, consulte estas páginas:

Comprobador ABI

La página Estabilidad de ABI describe el verificador de interfaz binaria de aplicaciones (ABI), que garantiza que los cambios realizados en las bibliotecas VNDK mantengan el cumplimiento de ABI.

Instantáneas VNDK

Una imagen del sistema puede usar instantáneas de VNDK para proporcionar las bibliotecas VNDK correctas a las imágenes del proveedor, incluso cuando las imágenes del sistema y del proveedor se crean a partir de diferentes versiones de Android.

Objeto de interfaz de proveedor (objeto VINTF)

Las siguientes páginas en la sección Objeto de interfaz del proveedor describen las actualizaciones en Android 9 y versiones posteriores:

Calendario de desuso de HIDL

Las siguientes páginas describen cómo Android desaprueba y elimina los HIDL HAL:

Cargador de arranque

Particiones de productos

Android 9 y versiones posteriores admiten la creación de particiones /product mediante el sistema de compilación de Android. Anteriormente, Android 8.x imponía la separación de componentes específicos del sistema en chip (SoC) de la partición /system a la partición /vendor sin dedicar espacio para componentes específicos de OEM creados a partir del sistema de compilación de Android.

Cumplimiento del motivo de arranque canónico

La página Canonical Boot Reason describe los cambios en la especificación del motivo de arranque del gestor de arranque en Android 9 y versiones posteriores.

Sistema como raíz

Todos los dispositivos que se inician con Android 9 y versiones posteriores deben usar system-as-root , que fusiona ramdisk.img con system.img (también conocido como no-ramdisk), que a su vez se monta como rootfs.

Versionado del encabezado de la imagen de arranque

En Android 9 y versiones posteriores, el encabezado de la imagen de inicio contiene un campo para indicar la versión del encabezado . El gestor de arranque debe verificar este campo de versión y analizar el encabezado en consecuencia.

DTBO en recuperación

Para evitar fallas de OTA debido a discrepancias entre la imagen de recuperación y la partición DTBO en dispositivos que no son A/B, la imagen de recuperación debe contener información de la imagen DTBO .

Mostrar

Recortes de pantalla

Los recortes de pantalla permiten a los desarrolladores de aplicaciones crear experiencias inmersivas de borde a borde y, al mismo tiempo, dejar espacio para sensores importantes en la parte frontal de los dispositivos.

Rotar sugerencias

Las actualizaciones del comportamiento de rotación de la pantalla en Android 9 y versiones posteriores incluyen soporte para un control orientado al usuario para fijar la rotación de la pantalla en horizontal o vertical incluso si cambia la posición del dispositivo.

Transiciones de aplicaciones sincronizadas

Las transiciones de aplicaciones sincronizadas permiten nuevas animaciones de transición de aplicaciones.

Clasificación de texto (anteriormente TEXTCLASSIFIER)

Android 9 y versiones posteriores incluyen un servicio Clasificador de texto , que es la forma recomendada de implementar la clasificación de texto, y una implementación de servicio predeterminada.

Color de amplia gama

Android 9 y versiones posteriores incluyen compatibilidad con una amplia gama de colores, que incluye:

  • Alto rango dinámico (HDR)
  • Procesar contenido en el espacio de color BT2020, pero no como un espacio de datos de destino final

Para utilizar una amplia gama de colores, la pila de visualización completa de un dispositivo (como la pantalla, el compositor de hardware, la GPU) debe admitir colores de amplia gama o formatos de búfer. Los dispositivos no están obligados a reclamar soporte para contenido de amplia gama, incluso si el hardware lo admite. Sin embargo, se debe habilitar una amplia gama de colores para aprovechar al máximo el hardware. Para evitar una experiencia visual inconsistente, la gama de colores amplia no debe desactivarse durante el tiempo de ejecución.

Compatibilidad

Documento de definición de compatibilidad de Android

El Documento de definición de compatibilidad (CDD) de Android 9 se basa en versiones anteriores con actualizaciones para nuevas funciones y cambios en los requisitos de las funciones publicadas anteriormente.

Ajustes

Mejores widgets de aplicaciones

El marco de widgets de la aplicación de Android ofrece una mayor visibilidad de las interacciones del usuario, específicamente cuando un usuario elimina o agrega widgets manualmente. Esta funcionalidad viene de forma predeterminada con Launcher3.

Los fabricantes deben actualizar sus aplicaciones de inicio (que se envían con los dispositivos) para admitir esta función si no se basan en Launcher3. Los OEM deben admitir el nuevo campo widgetFeatures en su iniciador predeterminado.

Tenga en cuenta que la función solo funciona de principio a fin cuando los lanzadores la implementan como se esperaba. AOSP incluye una implementación de muestra. Consulte el ID de cambio de AOSP Iccd6f965fa3d61992244a365efc242122292c0ca para obtener el código de muestra proporcionado.

Notificaciones de cambio de estado del dispositivo a los instaladores de paquetes

Se puede enviar una transmisión del sistema protegido a aplicaciones que tienen el permiso INSTALL_PACKAGES cada vez que hay un cambio en propiedades como la configuración regional o la densidad de visualización. Los receptores se pueden registrar en el manifiesto y se despierta un proceso para recibir la transmisión. Esto es útil para los instaladores de paquetes que desean instalar componentes adicionales de aplicaciones tras dichos cambios, lo cual es poco común, porque los cambios de configuración elegibles para desencadenar esta transmisión son raros.

El código fuente de notificación de cambio de estado del dispositivo se encuentra en las siguientes ubicaciones en platform/frameworks/base :

  • api/system-current.txt
  • core/java/android/content/Intent.java
  • core/res/AndroidManifest.xml
  • services/core/java/com/android/server/am/ActivityManagerService.java

Arquitectura informacional

Los cambios en la arquitectura de la información para la aplicación Configuración brindan más funcionalidad y una implementación más sencilla.

Pruebas

Una prueba

La herramienta de línea de comandos Atest le permite crear, instalar y ejecutar pruebas de Android localmente, lo que acelera enormemente las repeticiones de pruebas sin necesidad de conocer las opciones de línea de comandos del arnés de pruebas de Trade Federation.

Conjunto de pruebas de compatibilidad

Descargas CTS

Los paquetes de Compatibility Test Suite (CTS) compatibles con Android 9 están disponibles en la página de descargas de CTS . El código fuente de las pruebas incluidas se puede sincronizar con la etiqueta android-cts-9.0_r1 en el árbol de código abierto.

Opciones CTS

Para Android 9, CTS v2 obtiene el siguiente comando y argumento :

  • run retry vuelve a intentar todas las pruebas que fallaron o no se ejecutaron en las sesiones anteriores.
  • '--shard-count divide un CTS en un número determinado de fragmentos independientes, para ejecutarlos en múltiples dispositivos en paralelo.

Además, el comando --retry-type que no estaba documentado anteriormente se agregó a la misma referencia de comando de la consola CTS v2.

Servicio de elemento seguro (SE)

El servicio Secure Element comprueba los elementos seguros compatibles con la plataforma global identificando si los dispositivos tienen una implementación SE HAL y, de ser así, cuántos. Esto se utiliza 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 utiliza en la prueba de fusión de sensores y en la prueba de sincronización multicámara de Camera Image Test Suite (Camera ITS) y proporciona un entorno de prueba consistente para medir la precisión de la marca de tiempo de la cámara y otros sensores para teléfonos Android. Consulte estas páginas para obtener más información:

Amplio campo de visión ITS-in-a-box

El ITS-in-a-box de amplio campo de visión es un sistema automatizado diseñado para probar sistemas de cámara de campo de visión amplio (WFoV) y de campo de visión regular (RFoV) en Camera ITS.

Conjunto de pruebas de proveedores

Arquitectura del controlador de host

La arquitectura del controlador de host de Vendor Test Suite (VTS) es la arquitectura del marco de prueba de VTS integrada con su servicio de servicio de pruebas basado en la nube.

Pruebas HAL con reconocimiento de nombre del servicio

Las pruebas HAL con reconocimiento de nombre del servicio VTS permiten obtener el nombre del servicio de una instancia HAL determinada en función del dispositivo en el que se ejecutan las pruebas VTS.

Verificación de capacidad de prueba HAL

La verificación de capacidad de prueba de VTS HAL incluye un método de tiempo de ejecución para usar la configuración del dispositivo para identificar qué pruebas de VTS deben omitirse para ese dispositivo objetivo.

Infraestructura de prueba automatizada

La infraestructura de pruebas automatizadas es una infraestructura VTS para pruebas automatizadas de VTS, CTS u otras pruebas en dispositivos asociados que ejecutan la imagen genérica del sistema (GSI) de 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 aplicaciones. En versiones anteriores de Android, la pila de telemetría era limitada y no capturaba la información necesaria para identificar y resolver la confiabilidad del sistema y los problemas de dispositivos o aplicaciones. Esto hizo que identificar las causas fundamentales de los problemas fuera difícil, si no imposible.

Android 9 incluye la función de telemetría statsd , que resuelve esta deficiencia al recopilar mejores datos más rápido. statsd recopila estadísticas de uso, batería y procesos de la aplicación, y fallas. Los datos se analizan y utilizan para mejorar productos, hardware y servicios.

Para obtener más detalles, consulte frameworks/base/cmds/statsd/ .

Características de seguridad

firma de aplicaciones

El esquema de firma APK v3 admite la rotación de claves APK.

Soporte biométrico

Android 9 incluye la clase pública BiometricPrompt , que las aplicaciones pueden usar para integrar el soporte de autenticación biométrica de forma independiente del dispositivo y la modalidad. Para obtener más información sobre la integración de su pila de datos biométricos para incluir BiometricPrompt , consulte Biometrics .

Análisis dinámico

Android 9 incluye soporte para más herramientas de análisis y mitigación de exploits .

Integridad del flujo de control (CFI)

La integridad del flujo de control (CFI) es un mecanismo de seguridad que prohíbe cambios en el gráfico de flujo de control original de un binario compilado, lo que dificulta significativamente la realización de dichos ataques.

CFI del núcleo

Además del CFI del sistema, que está habilitado de forma predeterminada, Android 9 y versiones posteriores incluyen soporte para la integridad del flujo de control del kernel (CFI) .

Cifrado

Cifrado basado en archivos

El cifrado basado en archivos (FBE) se actualiza para funcionar con almacenamiento adoptable . Los nuevos dispositivos deberían utilizar cifrado basado en archivos en lugar de cifrado de disco completo.

Cifrado de metadatos

Android 9 y versiones posteriores incluyen soporte para cifrado de metadatos donde hay soporte de hardware. Con el cifrado de metadatos, una única clave presente en el momento del arranque utiliza cifrado basado en archivos para cifrar cualquier contenido no cifrado.

Almacén de claves

Android 9 y superiores incluyen Keymaster 4 , que tiene estas características.

Caja fuerte

Android 9 y versiones posteriores incluyen compatibilidad con claves de Android Keystore que se almacenan y utilizan en una CPU físicamente separada diseñada específicamente para aplicaciones de alta seguridad, como un elemento seguro (SE) integrado. StrongBox Keymaster es una implementación de Keymaster HAL en hardware discreto y seguro. Una Caja Fuerte tiene:

  • CPU discreta
  • Almacenamiento seguro integral
  • Generador de números aleatorios verdaderos de alta calidad
  • Embalaje resistente a manipulaciones
  • Resistencia del canal lateral

Importación segura de claves

Para importar de forma segura una clave a Keymaster 4, una clave creada fuera del dispositivo se cifra con una especificación de las autorizaciones que definen cómo se puede usar la clave.

Soporte 3DES

Keymaster 4 incluye 3DES para compatibilidad con sistemas heredados que utilizan 3DES.

Enlace de versión

Para admitir la estructura modular de Treble y romper la vinculación de system.img a boot.img , Keymaster 4 cambió el modelo de vinculación de la versión clave para tener niveles de parche separados para cada partición. Esto permite que cada partición se actualice de forma independiente y al mismo tiempo proporciona protección contra reversiones.

API de confirmación protegida de Android

Los dispositivos compatibles que se inician con Android 9 instalado brindan a los desarrolladores la posibilidad de utilizar la API de confirmación protegida de Android . Con esta API, las aplicaciones pueden usar una instancia de ConfirmationPrompt para mostrar un mensaje al usuario pidiéndole que apruebe una breve declaración. Esta declaración permite que una aplicación reafirme que el usuario desea completar una transacción confidencial, como realizar un pago.

SELinux

Sandbox SELinux por aplicación

El entorno limitado de aplicaciones tiene nuevas protecciones y casos de prueba para garantizar que todas las aplicaciones sin privilegios destinadas a Android 9 y versiones posteriores ejecuten entornos limitados de SELinux individuales.

Cambios agudos en SELinux

Las actualizaciones de Treble SELinux en Android 9 y versiones posteriores están documentadas en varias páginas de la sección SELinux .

Inicio del proveedor

Vendor init cierra el agujero en la división sistema/proveedor de Treble al usar un dominio SELinux separado para ejecutar comandos /vendor con permisos específicos del proveedor.

Propiedades del sistema

Android 9 restringe que las propiedades del sistema se compartan innecesariamente entre las particiones system y vendor y proporciona un método para garantizar la coherencia entre las propiedades compartidas del sistema.

Pruebas de atributos de SELinux

Android 9 incluye nuevas pruebas de tiempo de compilación que garantizan que todos los archivos en ubicaciones específicas tengan los atributos adecuados . 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 al formato flotante y aumentos en las pistas de salida simultáneas del cliente, la memoria máxima cliente/servidor y el total de pistas mezcladas.

Cámara

Cámaras USB externas

Android 9 y versiones posteriores admiten el uso de cámaras USB plug-and-play (es decir, cámaras web) utilizando la API Camera2 estándar de Android y la interfaz HIDL de la cámara.

Rastreo de movimiento

Los dispositivos con cámara pueden anunciar la capacidad de seguimiento de movimiento .

Soporte multicámara

El soporte multicámara incluye soporte API para dispositivos multicámara a través de un nuevo dispositivo de cámara lógico compuesto 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 parámetros de sesión puede reducir los retrasos al permitir que los clientes de la cámara configuren activamente un subconjunto de costosos parámetros de solicitud como parte de la fase de inicialización de la sesión de captura.

Búfer de productor único, consumidor múltiple

El transporte de búfer de cámara de un solo productor y múltiples consumidores es un conjunto de métodos que permite a los clientes de cámara agregar y eliminar superficies de salida dinámicamente mientras la sesión de captura está activa y la transmisión de la cámara está en curso.

Conectividad

Llamadas y mensajes

Implementar planes de datos

Android 9 y versiones posteriores brindan soporte mejorado para los operadores que implementan planes de datos utilizando las API de SubscriptionPlan.

Aplicaciones de llamadas de terceros

Android 9 y versiones posteriores proporcionan API que permiten que las aplicaciones de llamadas de terceros (3P) manejen llamadas entrantes simultáneas del operador y registren las llamadas en el registro de llamadas del sistema.

Transportador

Identificación del transportista

En Android 9, AOSP agrega una base de datos de identificación del operador para ayudar con la identificación del operador . La base de datos minimiza la lógica duplicada y las experiencias de aplicaciones fragmentadas al proporcionar una forma común de identificar a los operadores.

é SIM

La SIM integrada (eSIM o eUICC) es la última tecnología que permite a los usuarios de dispositivos móviles descargar un perfil de operador y activar el servicio de un operador sin tener una tarjeta SIM física. En Android 9 y versiones posteriores, el marco de Android proporciona API estándar para acceder a eSIM y administrar perfiles de suscripción en eSIM. Para más información, ver:

Compatibilidad con múltiples SIM para la configuración de IMS

Android 9 y versiones posteriores proporcionan mejoras en la configuración de usuario para el subsistema multimedia IP (IMS) . Puede configurar voz en off LTE (VoLTE), videollamadas y llamadas Wi-Fi por suscripción en lugar de compartir estas configuraciones entre todas las suscripciones.

Transmisiones del estado de la SIM

En Android 9 y versiones posteriores, Intent.ACTION_SIM_STATE_CHANGED está obsoleto y se agregan dos transmisiones separadas para el estado de la tarjeta y el estado de la aplicación de la tarjeta, TelephonyManager.ACTION_SIM_CARD_STATE_CHANGED y TelephonyManager.ACTION_SIM_APPLICATION_STATE_CHANGED .

Con estos cambios, los receptores que sólo necesitan saber si una tarjeta está presente no tienen que escuchar los cambios de estado de la aplicación, y los receptores que sólo necesitan saber si las aplicaciones de la tarjeta están listas no tienen que escuchar los cambios en el estado de la tarjeta.

Las dos nuevas transmisiones son @SystemApis y no son fijas. Solo los receptores con el permiso READ_PRIVILEGED_PHONE_STATE pueden recibir las transmisiones.

Los intents no se retransmiten 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. Los estados se pueden consultar utilizando las API correspondientes en TelephonyManager, getSimCardState() y getSimApplicationState() .

Wifi

Wi-Fi del operador

La función Wi-Fi del operador permite que los dispositivos se conecten automáticamente a redes Wi-Fi implementadas por el operador. En áreas de alta congestión o con cobertura celular mínima, como un estadio o una estación de tren subterráneo, el Wi-Fi del operador ayuda a mejorar la conectividad y alivia el tráfico.

Aleatorización de MAC

La aleatorización de MAC permite a los dispositivos utilizar direcciones MAC aleatorias cuando buscan nuevas redes mientras no están actualmente asociados a una red. En Android 9 y versiones posteriores, se puede habilitar una opción de desarrollador para hacer que un dispositivo utilice una dirección MAC aleatoria al conectarse a una red Wi-Fi.

Activar Wi-Fi automáticamente

Cuando la función Activar Wi-Fi automáticamente está habilitada, Wi-Fi se vuelve a habilitar automáticamente cada vez que el dispositivo está cerca de una red Wi-Fi guardada con un indicador de intensidad de señal recibida (RSSI) relativo suficientemente alto.

Tiempo de ida y vuelta Wi-Fi

El tiempo de ida y vuelta (RTT) de Wi-Fi permite a los dispositivos medir la distancia a otros dispositivos compatibles, ya sean puntos de acceso (AP) o pares compatibles con Wi-Fi (si el dispositivo admite Wi-Fi Aware). Esta función se basa en el protocolo IEEE 802.11mc y permite que las aplicaciones utilicen una mayor precisión y conocimiento de la ubicación.

Mejoras en la puntuación de Wi-Fi

Los modelos de puntuación de Wi-Fi mejorados determinan de forma rápida y precisa cuándo un dispositivo debe salir de una red Wi-Fi conectada o ingresar a una nueva red Wi-Fi. Estos modelos brindan una experiencia confiable y fluida para los usuarios al evitar brechas en la conectividad.

Revise y ajuste los valores RSSI en los recursos config.xml , especialmente los siguientes:

  • config_wifi_framework_wifi_score_bad_rssi_threshold_5GHz
  • config_wifi_framework_wifi_score_entry_rssi_threshold_5GHz
  • config_wifi_framework_wifi_score_bad_rssi_threshold_24GHz
  • config_wifi_framework_wifi_score_entry_rssi_threshold_24GHz

Simultaneidad de Wi-Fi STA/AP

La simultaneidad de Wi-Fi STA/AP es la capacidad de los dispositivos de operar en modos de estación (STA) y punto de acceso (AP) simultáneamente. Para los dispositivos que admiten Wi-Fi de banda dual simultánea (DBS), esto abre capacidades como no interrumpir el Wi-Fi de STA cuando un usuario desea habilitar un punto de acceso (SoftAP).

Mejoras en WiFiStateMachine

WifiStateMachine es la clase principal utilizada para controlar la actividad de Wi-Fi, coordinar la entrada del usuario (modos de funcionamiento: punto de acceso, escanear, conectar o desactivar) y controlar las acciones de la red Wi-Fi (como escanear o conectarse).

En Android 9 y versiones posteriores, se rediseñó el código del marco de Wi-Fi y la implementación de WifiStateMachine , lo que lleva a un tamaño de código reducido, una lógica de control de Wi-Fi más fácil de seguir, una granularidad de control mejorada y una mayor cobertura y calidad de las pruebas unitarias. .

En un nivel alto, WifiStateMachine permite que Wi-Fi esté en uno de cuatro estados:

  • Modo cliente (puede conectarse y escanear)
  • Modo de solo escaneo
  • Modo SoftAP (punto de acceso Wi-Fi)
  • Deshabilitado (Wi-Fi completamente apagado)

Cada modo Wi-Fi tiene requisitos diferentes para ejecutar servicios y debe configurarse de manera consistente, manejando solo los eventos relevantes para su funcionamiento. La nueva implementación restringe el código a eventos relacionados con ese modo, reduciendo el tiempo de depuración y el riesgo de introducir nuevos errores debido a la complejidad. Además del manejo explícito de la funcionalidad del modo, la gestión de subprocesos se maneja de manera consistente y se elimina el uso de canales asíncronos como mecanismo de sincronización.

Actualizaciones de permisos de Wi-Fi

En Android 9 y versiones posteriores, el permiso de la aplicación CHANGE_WIFI_STATE está habilitado de forma predeterminada. Puede desactivar el permiso para cualquier aplicación en la página de configuración en Configuración > Aplicaciones y notificaciones > Acceso a aplicaciones especiales > Control de Wi-Fi .

Las aplicaciones deben poder manejar casos en los que no se concede el permiso CHANGE_WIFI_STATE .

Para validar este comportamiento, ejecute las pruebas roboeléctricas y manuales.

Para pruebas manuales:

  1. Vaya a Configuración > Aplicaciones y notificaciones > Acceso a aplicaciones especiales > Control de Wi-Fi .
  2. Seleccione y desactive el permiso para su aplicación.
  3. Verifique que su aplicación pueda manejar el escenario en el que no se otorga el permiso CHANGE_WIFI_STATE .

WPS en desuso

Debido a problemas de seguridad, la configuración protegida de Wi-Fi (WPS) en WiFiManager está obsoleta y deshabilitada en Android 9 y versiones posteriores. Sin embargo, WiFiDirect todavía usa WPS en el solicitante WPA.

Gráficos

Implementación

API de Vulkan 1.1

Android 9 y versiones posteriores admiten la implementación de la API de gráficos Vulkan 1.1 .

Herramienta WinScope para el seguimiento de transiciones de ventanas

Android 9 y versiones posteriores incluyen la herramienta WinScope para rastrear transiciones de ventanas. WinScope proporciona infraestructura y herramientas para registrar y analizar el estado del administrador de ventanas durante y después de las transiciones. Permite grabar y recorrer las transiciones de las ventanas, mientras registra todos los estados pertinentes del administrador de ventanas en un archivo de seguimiento. Puede utilizar estos datos para reproducir y recorrer la transición.

El código fuente de la herramienta WinScope se encuentra en platform/development/tools/winscope .

Interacción

audio automotriz

Automotive Audio describe la arquitectura de audio para implementaciones de Android relacionadas con la automoción.

Neural Networks (NN) HAL define una abstracción de los distintos aceleradores. Los controladores de estos aceleradores deben ajustarse a este HAL.

Vehículo HAL

Propiedades del vehículo describe los cambios en la interfaz HAL del vehículo.

Selección de satélites GNSS

Cuando se trabaja con los nuevos HAL del sistema de navegación global por satélite (GNSS) (v1.1+), Android Framework monitorea la configuración de Android. Los socios pueden cambiar la configuración de los servicios de Google Play u otras actualizaciones del sistema. Estas configuraciones le indican al GNSS HAL si ciertos satélites GNSS no deben usarse. Esto puede ser útil en caso de errores persistentes de satélites o constelaciones GNSS, o para reaccionar más rápidamente a los problemas de implementación HAL GNSS que pueden ocurrir al mezclar constelaciones que utilizan diferentes sistemas horarios y eventos externos, como cambios de números de segundos intercalares, días o semanas. .

Modelo de hardware GNSS

En Android 9, GNSS HAL versión 1.1 o superior puede pasar información sobre la API de hardware a la plataforma. La plataforma necesita implementar la interfaz IGnssCallback y pasar un identificador a HAL. GNSS HAL pasa la información del modelo de hardware a través del método LocationManager#getGnssHardwareModelName() . Los fabricantes de dispositivos deben trabajar con sus proveedores GNSS HAL para proporcionar esta información siempre que sea posible.

Permisos

Configuración de actualizaciones de control de acceso discrecional

La configuración del control de acceso discrecional (DAC) contiene actualizaciones del mecanismo de ID de Android (AID) para ampliar las capacidades del sistema de archivos.

Incluir permisos de aplicaciones privilegiadas en la lista blanca

En Android 9 y versiones posteriores, si hay permisos que deben denegarse, edite el XML para usar la etiqueta deny-permission en lugar de la etiqueta permission utilizada en versiones anteriores.

Datos

Mejoras en la estimación del ancho de banda

Android 9 proporciona soporte mejorado para la estimación del ancho de banda. Las aplicaciones de Android pueden realizar configuraciones de resolución más apropiadas para videollamadas y transmisión de video si pueden acceder al ancho de banda de datos disponible.

En dispositivos con Android 6.0 o superior, una persona que llama y desea una estimación del ancho de banda para una red celular llama a ConnectivityManager.requestBandwidthUpdate() y el marco puede proporcionar un ancho de banda de enlace descendente estimado.

Pero en dispositivos que ejecutan 9 o superior, la devolución de llamada onCapabilitiesChanged() se activa automáticamente cuando hay un cambio significativo en el ancho de banda estimado, y llamar requestBandwidthUpdate() no es operativo; los getLinkDownstreamBandwidthKbps() y getLinkUpstreamBandwidthKbps() asociados se completan con información actualizada proporcionada por la capa física.

Además, los dispositivos pueden verificar los anchos de banda de las celdas LTE a través de ServiceState.getCellBandwidths() . Esto permite a las aplicaciones determinar cuánto ancho de banda (frecuencia) está disponible en una celda determinada. La información del ancho de banda celular está disponible a través de un menú oculto para que los evaluadores de campo puedan verificar la información más actualizada.

Monitoreo de tráfico eBPF

La herramienta de tráfico de red eBPF utiliza una combinación de implementación de kernel y espacio de usuario para monitorear el uso de la red en un dispositivo desde el último inicio del dispositivo. Esta herramienta proporciona funciones adicionales como etiquetado de sockets, separación del tráfico en primer plano y en segundo plano y firewall por UID para bloquear el acceso a la red de aplicaciones según el estado del dispositivo.

Restaurar a API inferiores

Los dispositivos ahora pueden restaurar desde versiones futuras del sistema operativo. Esto es especialmente útil cuando los usuarios actualizaron sus teléfonos pero luego los perdieron o se estropearon.

Si un OEM modifica los agentes de respaldo para cualquiera de los paquetes del sistema (Android, sistema, configuración), esos agentes deben encargarse de restaurar los conjuntos de respaldos que se realizaron en versiones superiores de la plataforma sin fallar y restaurando al menos algunos datos.

Considere usar un validador para verificar si hay valores no válidos de una determinada pieza de datos de respaldo y solo restaurar datos válidos, como en core/java/android/provider/SettingsValidators.java .

La función está activada de forma predeterminada. La compatibilidad de SettingsBackupAgent para restaurar desde versiones futuras se puede desactivar a través de Settings.Global.OVERRIDE_SETTINGS_PROVIDER_RESTORE_ANY_VERSION . No se requiere implementación adicional a menos que el fabricante del dispositivo extienda uno de los agentes de respaldo incluidos en la ROM (o agregue un agente personalizado).

Esta característica permite restaurar el sistema desde versiones futuras de la plataforma; sin embargo, es razonable esperar que los datos restaurados no estén completos. Las siguientes instrucciones se aplican a los siguientes agentes de respaldo:

  • PackageManagerBackupAgent admite versiones futuras de los datos de la copia de seguridad mediante control de versiones de formato; Las extensiones aquí deben ser compatibles con el código de restauración actual o seguir las instrucciones de la clase, que incluyen cambiar las constantes adecuadas.

  • SystemBackupAgent especifica restoreAnyVersion = false en Android 9 y versiones posteriores. No admite una restauración desde versiones superiores de la API.

  • SettingsBackupAgent especifica restoreAnyVersion = true en Android 9 y versiones posteriores. Existe soporte parcial a través de validadores. Se puede restaurar una configuración desde una versión de API superior si existe un validador en el sistema operativo de destino. La adición de cualquier configuración debe ir acompañada de su validador. Consulta la clase para más detalles.

  • Cualquier agente de respaldo personalizado incluido en la ROM debe aumentar su código de versión cada vez que se realiza un cambio incompatible en el formato de los datos de respaldo y garantizar restoreAnyVersion = false (el valor predeterminado) si su agente no está preparado para manejar los datos de respaldo de una versión futura de su código.

Empresa

Mejoras en el perfil administrado

Los cambios de UX para los perfiles administrados facilitan a los usuarios identificar, acceder y controlar el perfil administrado.

Pausar OTA

Una nueva @SystemApi permite a los propietarios de dispositivos pausar indefinidamente las actualizaciones OTA , incluidas las actualizaciones de seguridad.

Actuación

Salud 2.0

Android 9 y versiones posteriores incluyen android.hardware.health HAL 2.0, una actualización importante de Health@1.0 HAL. Para obtener más información, consulte estas páginas:

Solución de almacenamiento en caché de APK

Android 9 y versiones posteriores incluyen una solución de almacenamiento en caché de APK para una instalación rápida de aplicaciones precargadas en un dispositivo que admita particiones A/B. Los OEM pueden colocar precargas y aplicaciones populares en la caché de APK almacenada principalmente en la partición B vacía en nuevos dispositivos con particiones A/B sin afectar el espacio de datos de cara al usuario.

Optimización guiada por perfiles

Android 9 y versiones posteriores admiten el uso de la optimización guiada por perfiles (PGO) de Clang en módulos nativos de Android que tienen reglas de compilación de planos.

Registro de escritura anticipada

Un modo especial de SQLiteDatabase llamado registro de escritura anticipada de compatibilidad (WAL) permite que una base de datos use journal_mode=WAL manteniendo un máximo de una conexión por base de datos.

Tiempos de arranque

Android 9 cambia la optimización del tiempo de arranque como se describe en Optimización de tiempos de arranque .

Fuerza

Restricciones de fondo

Android 9 y versiones posteriores incluyen restricciones en segundo plano que permiten a los usuarios restringir aplicaciones que pueden estar agotando la batería. El sistema también puede sugerir deshabilitar aplicaciones que están afectando negativamente la salud de un dispositivo.

Dispositivos sin batería

Android 9 maneja dispositivos sin batería de manera más elegante que en versiones anteriores. Android 9 elimina el código para dispositivos sin batería que asumían de forma predeterminada que había una batería presente, cargada al 100 % y en buen estado con una lectura de temperatura normal en su termistor.