Cambios de comportamiento: todas las apps

La plataforma de Android 16 incluye cambios de comportamiento que podrían afectar tu app. Los siguientes cambios se aplican a todas las apps cuando se ejecutan en Android 16, independientemente de targetSdkVersion. Debes probar tu app y, luego, modificarla según corresponda para admitir estos cambios.

Asegúrate también de revisar la lista de cambios de comportamiento que solo afectan a las apps orientadas a Android 16.

Funcionalidad principal

Android 16 (nivel de API 36) incluye los siguientes cambios que modifican o expanden varias capacidades principales del sistema Android.

Optimizaciones de cuotas de JobScheduler

从 Android 16 开始，我们将根据以下因素调整常规作业和加急作业的执行运行时配额：

• 应用所处的应用待机存储分区：在 Android 16 中，活跃待机存储分区将开始通过宽松的运行时配额强制执行。
• 如果作业在应用处于前台状态时开始执行：在 Android 16 中，如果作业在应用对用户可见时开始执行，并在应用变为不可见后继续执行，则会遵守作业运行时配额。
• 如果作业在运行前台服务时执行：在 Android 16 中，与前台服务同时执行的作业将遵守作业运行时配额。如果您利用作业进行用户发起的数据传输，请考虑改用用户发起的数据传输作业。

此变更会影响使用 WorkManager、JobScheduler 和 DownloadManager 调度的任务。如需调试作业停止的原因，我们建议您通过调用 WorkInfo.getStopReason()（对于 JobScheduler 作业，请调用 JobParameters.getStopReason()）来记录作业停止的原因。

如需了解应用的状态如何影响其可使用的资源，请参阅电源管理资源限制。 如需详细了解电池优化方面的最佳实践，请参阅有关针对任务调度 API 优化电池使用的指南。

我们还建议利用 Android 16 中引入的新 JobScheduler#getPendingJobReasonsHistory API 来了解作业未执行的原因。

测试

如需测试应用的行为，只要应用在 Android 16 设备上运行，您就可以启用对某些作业配额优化功能的替换。

如需停用“顶级状态将遵守作业运行时配额”的强制执行，请运行以下 adb 命令：

adb shell am compat enable OVERRIDE_QUOTA_ENFORCEMENT_TO_TOP_STARTED_JOBS APP_PACKAGE_NAME

如需停用“在与前台服务同时执行时，作业将遵守作业运行时配额”的强制执行，请运行以下 adb 命令：

adb shell am compat enable OVERRIDE_QUOTA_ENFORCEMENT_TO_FGS_JOBS APP_PACKAGE_NAME

如需测试特定应用待机分桶行为，您可以使用以下 adb 命令设置应用的应用待机分桶：

adb shell am set-standby-bucket APP_PACKAGE_NAME active|working_set|frequent|rare|restricted

如需了解应用所在的待机分桶，您可以使用以下 adb 命令获取应用的待机分桶：

adb shell am get-standby-bucket APP_PACKAGE_NAME

Motivo de detención de trabajos vacíos abandonados

Una tarea abandonada ocurre cuando se recopiló como elemento no utilizado el objeto JobParameters asociado con la tarea, pero no se llamó a JobService#jobFinished(JobParameters, boolean) para indicar que se completó. Esto indica que el trabajo puede estar en ejecución y reprogramarse sin que la app lo sepa.

Las apps que dependen de JobScheduler no mantienen una referencia sólida al objeto JobParameters, y el tiempo de espera ahora se otorgará al nuevo motivo de detención de la tarea STOP_REASON_TIMEOUT_ABANDONED, en lugar de STOP_REASON_TIMEOUT.

Si se producen casos frecuentes del nuevo motivo de detención abandonada, el sistema tomará medidas de mitigación para reducir la frecuencia de las tareas.

Las apps deben usar el nuevo motivo de detención para detectar y reducir las tareas abandonadas.

Si usas WorkManager, AsyncTask o DownloadManager, no se te verá afectado porque estas APIs administran el ciclo de vida de la tarea en nombre de tu app.

Se dejó de usar por completo JobInfo#setImportantWhileForeground

El método JobInfo.Builder#setImportantWhileForeground(boolean) indica la importancia de una tarea mientras la app de programación está en primer plano o cuando está exenta temporalmente de las restricciones en segundo plano.

Este método dejó de estar disponible a partir de Android 12 (nivel de API 31). A partir de Android 16, ya no funciona de manera eficaz y se ignorará llamar a este método.

Esta eliminación de funcionalidad también se aplica a JobInfo#isImportantWhileForeground(). A partir de Android 16, si se llama al método, este muestra false.

El alcance de prioridad de transmisión ordenada ya no es global

Las apps para Android pueden definir prioridades en los receptores de emisión para controlar el orden en que los receptores reciben y procesan la emisión. En el caso de los receptores declarados en el manifiesto, las apps pueden usar el atributo android:priority para definir la prioridad y, en el caso de los receptores registrados en el contexto, las apps pueden usar la API de IntentFilter#setPriority() para definir la prioridad. Cuando se envía una transmisión, el sistema la entrega a los receptores en orden de prioridad, de la más alta a la más baja.

En Android 16, no se garantizará el orden de entrega de transmisiones con el atributo android:priority o IntentFilter#setPriority() en diferentes procesos. Las prioridades de transmisión solo se respetarán dentro del mismo proceso de la aplicación y no en todos los procesos.

Además, las prioridades de transmisión se limitarán automáticamente al rango (SYSTEM_LOW_PRIORITY + 1, SYSTEM_HIGH_PRIORITY - 1). Solo los componentes del sistema podrán establecer SYSTEM_LOW_PRIORITY, SYSTEM_HIGH_PRIORITY como prioridad de transmisión.

Es posible que tu app se vea afectada si realiza alguna de las siguientes acciones:

1. Tu aplicación declaró varios procesos con el mismo intent de transmisión y tiene expectativas sobre la recepción de esos intents en un orden determinado según la prioridad.
2. El proceso de tu app interactúa con otros procesos y tiene expectativas con respecto a la recepción de un intent de transmisión en un orden determinado.

Si los procesos deben coordinarse entre sí, deben comunicarse a través de otros canales de coordinación.

Cambios internos en ART

Android 16 incluye las actualizaciones más recientes del entorno de ejecución de Android (ART) que mejoran el rendimiento de este y proporcionan compatibilidad con funciones adicionales de Java. A través de las actualizaciones del sistema de Google Play, estas mejoras también están disponibles para más de mil millones de dispositivos que ejecutan Android 12 (nivel de API 31) y versiones posteriores.

A medida que se lanzan estos cambios, es posible que las bibliotecas y el código de la app que dependen de las estructuras internas de ART no funcionen correctamente en dispositivos con Android 16, junto con versiones anteriores de Android que actualizan el módulo de ART a través de actualizaciones del sistema de Google Play.

Depender de estructuras internas (como interfaces que no son de SDK) siempre puede generar problemas de compatibilidad, pero es particularmente importante evitar depender de código (o bibliotecas que contienen código) que aproveche estructuras internas de ART, ya que los cambios de ART no están vinculados a la versión de la plataforma en la que se ejecuta el dispositivo y se envían a más de mil millones de dispositivos a través de actualizaciones del sistema de Google Play.

Todos los desarrolladores deben verificar si sus apps se ven afectadas probando sus apps de forma exhaustiva en Android 16. Además, consulta los problemas conocidos para ver si tu app depende de alguna biblioteca que identificamos que se basa en estructuras internas de ART. Si tienes dependencias de código de app o biblioteca que se verán afectadas, busca alternativas de API públicas siempre que sea posible y solicita APIs públicas para casos de uso nuevos. Para ello, crea una solicitud de función en nuestro seguimiento de problemas.

Modo de compatibilidad de tamaño de página de 16 KB

Android 15 引入了对 16 KB 内存页面的支持，以优化平台性能。Android 16 添加了兼容模式，让一些针对 4 KB 内存页面构建的应用可以在配置为 16 KB 内存页面的设备上运行。

当您的应用在搭载 Android 16 或更高版本的设备上运行时，如果 Android 检测到您的应用具有 4 KB 对齐的内存页面，则会自动使用兼容模式并向用户显示通知对话框。在 AndroidManifest.xml 中设置 android:pageSizeCompat 属性以启用向后兼容模式，将会阻止应用启动时显示对话框。如需使用 android:pageSizeCompat 属性，请使用 Android 16 SDK 编译您的应用。

为了实现最佳性能、可靠性和稳定性，应用仍应以 16 KB 对齐。如需了解详情，请参阅我们近期发布的博文，了解如何更新应用以支持 16 KB 的内存页面。

兼容模式对话框：当系统检测到 4 KB 对齐的应用在 16 KB 对齐的情况下可以更高效地运行时，系统会显示此对话框。

Experiencia del usuario y la IU del sistema

Android 16 (nivel de API 36) incluye los siguientes cambios que tienen como objetivo crear una experiencia del usuario más coherente e intuitiva.

Se desaprobarán los anuncios de accesibilidad que interrumpen

Android 16 废弃了无障碍功能通告，其特征是使用 announceForAccessibility 或调度 TYPE_ANNOUNCEMENT 无障碍功能事件。这可能会给 TalkBack 和 Android 屏幕阅读器用户带来不一致的用户体验，而替代方案可以更好地满足各种 Android 辅助技术的用户需求。

替代方案示例：

• 对于窗口更改等重大界面更改，请使用 Activity.setTitle(CharSequence) 和 setAccessibilityPaneTitle(java.lang.CharSequence)。在 Compose 中，使用 Modifier.semantics { paneTitle = "paneTitle" }
• 如需向用户告知关键界面的更改，请使用 setAccessibilityLiveRegion(int)。在 Compose 中，请使用 Modifier.semantics { liveRegion = LiveRegionMode.[Polite|Assertive]}。应谨慎使用这些事件，因为它们可能会在每次更新视图时生成通知。
• 如需向用户发送错误通知，请发送类型为 AccessibilityEvent#CONTENT_CHANGE_TYPE_ERROR 的 AccessibilityEvent 并设置 AccessibilityNodeInfo#setError(CharSequence)，或使用 TextView#setError(CharSequence)。

已废弃的 announceForAccessibility API 的参考文档中包含有关建议替代方案的更多详细信息。

Compatibilidad con la navegación con 3 botones

Android 16 admite el gesto atrás predictivo en la navegación de 3 botones para las apps que migraron correctamente al gesto atrás predictivo. Si mantienes presionado el botón Atrás, se inicia una animación de atrás predictivo, que te brinda una vista previa de adónde te dirige el gesto de deslizar para volver.

Este comportamiento se aplica a todas las áreas del sistema que admiten animaciones de atrás predictivas, incluidas las animaciones del sistema (volver a la pantalla principal, cambiar de tarea y cambiar de actividad).

Las animaciones de atrás predictivo en el modo de navegación con 3 botones.

Íconos de apps temáticos automáticos

从 Android 16 QPR 2 开始，Android 会自动将主题应用于应用图标，以打造一致的主屏幕体验。如果应用未提供自己的带主题的应用图标，就会发生这种情况。应用可以通过在自适应图标中添加单色图层来控制主题化应用图标的设计，并在 Android Studio 中预览应用图标的外观。

Factores de forma del dispositivo

Android 16 (nivel de API 36) incluye los siguientes cambios para las apps cuando los propietarios de dispositivos virtuales las proyectan en pantallas.

Anulaciones del propietario del dispositivo virtual

虚拟设备所有者是创建和管理虚拟设备的受信任应用或特权应用。虚拟设备所有者在虚拟设备上运行应用，然后将应用投影到远程设备的显示屏上，例如个人电脑、虚拟现实设备或车载信息娱乐系统。虚拟设备所有者位于本地设备上，例如手机。

手机上的虚拟设备所有者创建将应用投影到远程显示屏的虚拟设备。

按应用替换项

在搭载 Android 16（API 级别 36）的设备上，虚拟设备所有者可以替换其管理的特定虚拟设备上的应用设置。例如，为了改进应用布局，虚拟设备所有者在将应用投影到外部显示屏上时，可以忽略屏幕方向、宽高比和可调整大小性限制。

常见的重大更改

Android 16 的行为可能会影响应用在汽车显示屏或 Chromebook 等大屏幕设备上的界面，尤其是那些专为竖屏小显示屏设计的布局。如需了解如何让应用适应所有设备类型，请参阅自适应布局简介。

参考文档

配套应用串流

Seguridad

Android 16 (nivel de API 36) incluye cambios que promueven la seguridad del sistema para ayudar a proteger las apps y los usuarios de las apps maliciosas.

Mayor seguridad contra ataques de redireccionamiento de intents

Android 16 proporciona seguridad predeterminada contra ataques generales de redireccionamiento de Intent, con cambios mínimos de compatibilidad y para desarrolladores.

Incorporaremos soluciones de refuerzo de seguridad predeterminadas para los ataques de redireccionamiento de Intent. En la mayoría de los casos, las apps que usan intents no tendrán problemas de compatibilidad. Recopilamos métricas durante todo nuestro proceso de desarrollo para supervisar qué apps podrían tener interrupciones.

El redireccionamiento de intents en Android se produce cuando un atacante puede controlar de forma parcial o total el contenido de un intent que se usa para iniciar un componente nuevo en el contexto de una app vulnerable, mientras que la app víctima inicia un intent de nivel secundario no confiable en un campo de extras de un intent ("de nivel superior"). Esto puede provocar que la app del atacante inicie componentes privados en el contexto de la app de la víctima, que se activen acciones con privilegios o que se obtenga acceso a URI de datos sensibles, lo que podría provocar el robo de datos y la ejecución de código arbitrario.

Cómo inhabilitar el control del redireccionamiento de intents

Android 16 presenta una nueva API que permite que las apps inhabiliten las protecciones de seguridad de inicio. Esto puede ser necesario en casos específicos en los que el comportamiento de seguridad predeterminado interfiere con los casos de uso legítimos de la app.

Importante: Debes inhabilitar las protecciones de seguridad con precaución y solo cuando sea absolutamente necesario, ya que esto puede aumentar el riesgo de vulnerabilidades de seguridad. Evalúa con cuidado el posible impacto en la seguridad de tu app antes de usar esta API.

Para las aplicaciones que se compilan con el SDK de Android 16 (nivel de API 36) o versiones posteriores

Puedes usar directamente el método removeLaunchSecurityProtection() en el objeto Intent.

val i = intent
val iSublevel: Intent? = i.getParcelableExtra("sub_intent")
iSublevel?.removeLaunchSecurityProtection() // Opt out from hardening
iSublevel?.let { startActivity(it) }

Para aplicaciones que se compilan en Android 15 (nivel de API 35) o versiones anteriores

Si bien no se recomienda, puedes usar la reflexión para acceder al método removeLaunchSecurityProtection().

Precaución: El uso de la reflexión puede hacer que tu código sea más frágil y propenso a errores, en especial si la API subyacente cambia en versiones futuras de Android. Siempre que sea posible, actualiza tu SDK de compilación para que se oriente a Android 16 (nivel de API 36) o versiones posteriores para usar la API directamente.

val i = intent
val iSublevel: Intent? = i.getParcelableExtra("sub_intent", Intent::class.java)
try {
    val removeLaunchSecurityProtection = Intent::class.java.getDeclaredMethod("removeLaunchSecurityProtection")
    removeLaunchSecurityProtection.invoke(iSublevel)
} catch (e: Exception) {
    // Handle the exception, e.g., log it
} // Opt-out from the security hardening using reflection
iSublevel?.let { startActivity(it) }

Ya no se notifica a las apps complementarias sobre los tiempos de espera de detección

Android 16 presenta un nuevo comportamiento durante el flujo de vinculación de dispositivos complementarios para proteger la privacidad de la ubicación del usuario de las apps maliciosas. A todas las apps complementarias que se ejecutan en Android 16 ya no se les notifica directamente el tiempo de espera de descubrimiento con RESULT_DISCOVERY_TIMEOUT. En su lugar, se le notifica al usuario sobre los eventos de tiempo de espera con un diálogo visual. Cuando el usuario descarta el diálogo, se alerta a la app sobre la falla de asociación con RESULT_USER_REJECTED.

La duración de la búsqueda también se extendió de los 20 segundos originales, y el usuario puede detener el descubrimiento de dispositivos en cualquier momento durante la búsqueda. Si se descubrió al menos un dispositivo en los primeros 20 segundos después de iniciar la búsqueda, el CDM deja de buscar dispositivos adicionales.

Conectividad

Android 16 (nivel de API 36) incluye los siguientes cambios en la pila de Bluetooth para mejorar la conectividad con dispositivos periféricos.

Se mejoró el manejo de la pérdida de vinculación

A partir de Android 16, se actualizó la pila de Bluetooth para mejorar la seguridad y la experiencia del usuario cuando se detecta una pérdida de vinculación remota. Anteriormente, el sistema quitaba automáticamente la vinculación e iniciaba un nuevo proceso de vinculación, lo que podía provocar una vinculación accidental. En muchos casos, observamos que las apps no se ocupan del evento de pérdida de vínculo de manera coherente.

Para unificar la experiencia, Android 16 mejoró el manejo de la pérdida de vinculación en el sistema. Si no se pudo autenticar un dispositivo Bluetooth vinculado anteriormente cuando se volvió a conectar, el sistema desconectará el vínculo, retendrá la información de vinculación local y mostrará un diálogo del sistema en el que se informará a los usuarios sobre la pérdida de vinculación y se les indicará que vuelvan a vincular el dispositivo.