Notas de la versión para Android 9

En esta página, se resumen las funciones principales en la versión de Android 9. Además, se incluyen vínculos 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. Consulta las Actualizaciones del sitio de agosto de 2018 para obtener información sobre las secciones que se trasladaron y el cambio de nombres.

Compilar

Imagen genérica del sistema (GSI)

Una imagen genérica del sistema (GSI) es una imagen del sistema con configuraciones ajustadas para dispositivos Android. Una imagen genérica del sistema (GSI) incluye información sobre las diferencias entre las GSI para los dispositivos que se lanzan con Android 9 y para los dispositivos que se actualizan a Android 9.

Arquitectura

Capa de abstracción de hardware (HAL)

Retrocompatibilidad con el marco de trabajo de HIDL

La verificación de retrocompatibilidad con el marco de trabajo de HIDL es una manera de verificar la retrocompatibilidad del marco de trabajo.

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 son necesarios.

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ñado para servicios HIDL con varios bloques de memoria que comparten un solo montón de memoria.

Superposiciones del árbol de dispositivos

Superposiciones comprimidas

Android 9 y las versiones posteriores admiten las 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 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 ABI.

Resúmenes del VNDK

Una imagen del sistema puede usar resúmenes del VNDK a fin de 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 diferentes versiones 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 las /productparticiones de compilación que usan 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 a los componentes específicos de OEM compilados a partir del sistema de compilación de Android.

Cumplimiento del motivo de inicio de canonicalización

En la página del motivo de inicio de canonicalización, se describen los cambios realizados en la especificación del motivo de inicio del bootloader en Android 9 y las versiones posteriores.

Sistema como raíz

Todos los dispositivos que se lanzan con Android 9 y las versiones posteriores deben usar sistema como raíz, 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 inicio

En Android 9 y las versiones posteriores, el encabezado de la imagen de inicio contiene un campo para indicar la versión del encabezado. El bootloader debe verificar este campo de versión y analizar el encabezado según corresponda.

DTBO en recuperación

A fin de evitar las fallas de OTA debido a discrepancias entre la imagen de recuperación y la partición de DTBO en los dispositivos que no sean de 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.

Color de amplia gama

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 de BT2020, pero no como un espacio de datos de objetivo final.

Para usar colores de amplia gama, la pila de pantalla completa de un dispositivo (como una pantalla, un compositor de hardware y la GPU) deben admitir colores de amplia gama o formatos de búfer. No es necesario que los dispositivos admitan contenido de amplia gama, incluso si el hardware sí lo admite. Sin embargo, el color de amplia gama debe estar habilitado para aprovechar el hardware al máximo. A fin de evitar una experiencia visual inconsistente, el color de amplia gana se debe desactivar 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 anteriormente.

Configuración

Mejores widgets de apps

El marco de trabajo del 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 manera predeterminada con Launcher3.

Los fabricantes deben actualizar la app de selector (que se incluye con los dispositivos) a fin de 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 característica solo funciona por completo cuando los selectores la implementan como se espera. 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 resulta útil para los instaladores de paquetes que desean instalar componentes de apps adicionales frente a estos 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 se encuentra 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 para la app de configuración ofrecen más funcionalidades y su implementación es más sencilla.

Pruebas

Atest

La herramienta de línea de comandos Atest te 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 que admiten Android 9 están disponibles en la página 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 de CTS

En el caso de Android 9, CTS v2 obtiene el comando y el argumento que se muestran a continuación:

  • run retry vuelve a ejecutar todas las pruebas que fallaron o que no se ejecutaron en las sesiones anteriores.
  • ‘--shard-count fragmenta una ejecución de CTS en un número determinado de partes independientes a fin de ejecutarlas en varios dispositivos en paralelo.

Además, se agregó el comando anteriormente indocumentado --retry-type 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 Paquete de prueba de imagen de la cámara (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 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 Camera ITS.

Paquete de pruebas del proveedor (VTS)

Arquitectura del controlador de host

La arquitectura del controlador de host de VTS es la arquitectura del marco de trabajo de prueba de VTS integrado con su servicio de pruebas basado en la nube.

Prueba HAL del servicio con reconocimiento de nombre

La prueba 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 para 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 los socios 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 apps. En las versiones anteriores de Android, la pila de telemetría era limitada y no capturaba la información necesaria para identificar y solucionar problemas con el dispositivo o la app y de confiabilidad del sistema. Esto 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. Se analizan los datos y se utilizan para mejorar productos, hardware y servicios.

Si deseas obtener más información, consulta frameworks/base/cmds/statsd/.

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 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 estos ataques.

CFI de kernel

Además del CFI del sistema, que está habilitado de manera predeterminada, Android 9 y las versiones posteriores admiten la integridad del flujo de control de kernel (CFI).

Encriptación

Encriptación basada en archivos (FBE)

La encriptación basada en archivos (FBE) se actualizó para funcionar 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. Mediante la encriptación de metadatos, una sola clave presente en el 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 seguro discreto. 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 para contar con niveles de parche separados para cada partición. Gracias a ello, se actualiza independientemente cada partición 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 les 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 a fin de mostrarle al usuario un mensaje en el que se le pida que apruebe una afirmación breve. Esta afirmación permite que una app vuelva a confirmar 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 nuevos a fin de 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 Treble SELinux en Android 9 y versiones posteriores están documentadas en varias páginas en la sección de SELinux.

Init de proveedor

El init de proveedor cierra la brecha en la división entre el sistema y el proveedor de Treble. Para ello, usa un dominio de SELinux por separado a fin de ejecutar comandos /vendor con permisos específicos para proveedores.

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, proporciona un método para garantizar la coherencia entre las propiedades del sistema compartido.

Pruebas de atributos de SELinux

Android 9 incluye pruebas de compilación nuevas que garantizan que todos los archivos en ubicaciones específicas tengan los atributos apropiados. Por ejemplo, todos los archivos de sysfs tienen el atributo sysfs_type requerido.

Audio

Efectos de audio de alta resolución

Las actualizaciones a los efectos de audio de alta resolución incluyen la conversión del procesamiento de efectos de int16 a formato flotante y los aumentos en las pistas de salida del cliente simultáneas, 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 publicitar la capacidad de seguimiento del movimiento.

Compatibilidad con varias cámaras

La compatibilidad con varias cámaras incluye compatibilidad con la API para dispositivos con varias cámaras a través de un nuevo dispositivo de cámara lógico 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 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 implementan planes de datos que usan 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) manejen llamadas mediante proveedores entrantes simultáneas y registren las llamadas en el sistema.

Proveedor

Identificación del proveedor

En Android 9, AOSP agrega una base de datos de ID de proveedor para ayudar en la identificación del proveedor. La base de datos minimiza las experiencias de apps fragmentadas y lógica duplicada. Para ello, ofrece una manera común de identificar a los proveedores.

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 marco de trabajo de Android ofrece API estándar para acceder a la eSIM y administrar sus perfiles de suscripción. Para obtener más información, consulta lo siguiente:

Compatibilidad con varias SIM para la configuración de IMS

Android 9 y las versiones posteriores ofrecen mejoras de configuración del usuario para el subsistema multimedia de IP (IMS). Puedes configurar el LTE de voz superpuesta (VoLTE), la videollamada y la llamada por Wi-Fi por cada suscripción en lugar de compartir esta 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 por separado 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 una tarjeta está 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.

Los intents no se vuelven a transmitir 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 mediante las API correspondientes en TelephonyManager: getSimCardState() y getSimApplicationState().

Wi-Fi

Wi-Fi del proveedor

La función de 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 celular mínima, como en un estadio o en 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.

Función Activar Wi-Fi automáticamente

Cuando se habilita la función Activar Wi-Fi automáticamente, se vuelve a habilitar 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 respecto de otros dispositivos compatibles, ya sean puntos de acceso (PA) o pares de Reconocimiento de Wi-Fi (si está admitido en el dispositivo). Esta 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. Estos modelos ofrecen una experiencia confiable y fluida para los usuarios, ya que evitan las brechas en la 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 de estación (STA) y de 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 desactivar) y controlar las acciones de la red de Wi-Fi (como escanear o conectar).

En Android 9 y las versiones posteriores, se rediseñaron el código del marco de trabajo 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 para ejecutar servicios y se debe configurar de manera coherente, es decir, manejar solo 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 para la funcionalidad del modo, se maneja de manera coherente la administración de subprocesos y se elimina el uso de los canales asíncronos como un mecanismo para la sincronización.

Actualizaciones de permisos de Wi-Fi

En Android 9 y las versiones posteriores, los permisos de la app de CHANGE_WIFI_STATE se habilitan de manera predeterminada. Puedes inhabilitar el permiso para 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 otorga el permiso de CHANGE_WIFI_STATE.

A fin de 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 para tu app.
  3. Verifica que tu app pueda manejar una situación en la que no se otorga el permiso de CHANGE_WIFI_STATE.

WPS dejó de estar disponible

Debido a problemas de seguridad, Wi-Fi Protected Setup (WPS) en WiFiManager dejó de estar disponible y no está habilitado en Android 9 y las 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 grabar y avanzar en las transiciones de ventanas al mismo tiempo que se graban todos los estados del administrador de ventanas pertinente en un archivo de registro. Puedes usar estos datos para volver a reproducir la transición y avanzar en ella.

El código fuente de la herramienta WinScope se encuentra 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 estos aceleradores deben cumplir con esta HAL.

HAL de vehículo

En Propiedades de vehículo, se describen los cambios en la interfaz de HAL del vehículo.

Selección de satélite de GNSS

Cuando se trabaja con HAL (v1.1+) de sistema satelital de navegación global (GNSS) nuevas, el marco de trabajo 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 de GNSS si no se deberían usar determinados satélites de GNSS. Esto puede ser útil en caso de errores persistentes de constelación o satélite de GNSS, o bien para reaccionar más rápido a problemas de implementación de HAL de GNSS que puedan ocurrir cuando se combinan constelaciones usando 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 de 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 manejo a la HAL. La HAL de GNSS pasa la información sobre el modelo de hardware a través del método de LocationManager#getGnssHardwareModelName(). Los fabricantes de dispositivos deben trabajar con sus proveedores de HAL de 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 al mecanismo de ID de Android (AID) para extender las capacidades del sistema de archivos.

Cómo incluir en la lista blanca permisos de apps con privilegios

En Android 9 y las versiones posteriores, si hay permisos que se deben denegar, edita el XML para usar la etiqueta deny-permission en lugar de la etiqueta 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 para las videollamadas y la transmisión de video por Internet si pueden acceder al ancho de banda de datos disponible.

En los dispositivos con Android 6.0 o versiones posteriores, un emisor que desee obtener una estimación del ancho de banda de una red celular llama a ConnectivityManager.requestBandwidthUpdate() y el marco de trabajo podría proporcionar un ancho de llamada por enlace descendente estimado.

Sin embargo, en los dispositivos con Android 9 o versiones posteriores, la devolución de llamada de onCapabilitiesChanged() se activa automáticamente 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 celulares de LTE mediante ServiceState.getCellBandwidths(). Esto permite que las aplicaciones determinen cuánto ancho de banda (frecuencia) está disponible en un celular determinado. La información sobre el ancho de banda del celular está disponible a través de 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 a fin de 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 apps y que no accedan a la red según el estado del dispositivo.

Cómo restablecer a 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 se le pierde o se le rompe posteriormente.

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 restaurando al menos parte de los datos.

Considera 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 manera 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; estas 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 las versiones posteriores. No admite una restauración a partir de versiones posteriores de la API.

  • SettingsBackupAgent especifica restoreAnyVersion = true en Android 9 y las versiones posteriores. El soporte parcial existe a través de validadores. Una configuración se puede restaurar 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 de su validador. Verifica la clase para obtener más detalles.

  • Todos los agentes de copia de seguridad personalizados incluidos en ROM deben aumentar el código de su 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 su agente no está preparado para manejar 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 para los perfiles administrados hacen que identificar el perfil administrado, acceder a él y controlarlo sea más fácil para los usuarios.

Cómo pausar las OTA

Un @SystemApi nuevo permite que el propietario de un dispositivo pause de manera indefinida las actualizaciones de OTA, incluidas las actualizaciones de seguridad.

Rendimiento

Salud 2.0

Android 9 y las versiones posteriores incluyen HAL 2.0 android.hardware.health, una actualización de versión importante desde health@1.0 HAL. 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 con particiones A/B nuevos 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 como se describe en Cómo optimizar los tiempos de inicio.

Encendido

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 inhabilitar 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 en las actualizaciones anteriores. Android 9 quita de los dispositivos sin batería el código que asume de manera predeterminada que hay una batería cargada al 100% y en buen estado con una lectura de temperatura normal en su termistor.