Notas de la versión para Android 9

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:

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:

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.txt
  • core/java/android/content/Intent.java
  • core/res/AndroidManifest.xml
  • services/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 retry reintenta hacer todas las pruebas que fallaron o que no se ejecutaron en las sesiones anteriores.
  • ‘--shard-count fragmenta 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:

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_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 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:

  1. Ve a Configuración > Apps y notificaciones > Acceso especial de apps > Control de Wi-Fi.
  2. Selecciona y desactiva el permiso de tu app.
  3. 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 = false en Android 9 y versiones posteriores. No admite una restauración a partir de versiones posteriores de la API.

  • SettingsBackupAgent especifica restoreAnyVersion = true en 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.