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

A partir de Android 16, ajustaremos la cuota de tiempo de ejecución de trabajos regulares y acelerados en función de los siguientes factores:

• En qué intervalo de espera de la app se encuentra la aplicación: En Android 16, los intervalos de espera activos comenzarán a aplicarse con una cuota de tiempo de ejecución generosa.
• Si el trabajo comienza a ejecutarse mientras la app está en un estado superior: En Android 16, los trabajos que se inician mientras la app es visible para el usuario y continúan después de que la app se vuelve invisible cumplirán con la cuota de tiempo de ejecución del trabajo.
• Si el trabajo se ejecuta mientras se ejecuta un servicio en primer plano: En Android 16, los trabajos que se ejecutan de forma simultánea con un servicio en primer plano cumplirán con la cuota de tiempo de ejecución del trabajo. Si aprovechas los trabajos para la transferencia de datos iniciada por el usuario, considera usar trabajos de transferencia de datos iniciados por el usuario.

Este cambio afecta las tareas programadas con WorkManager, JobScheduler y DownloadManager. Para depurar por qué se detuvo un trabajo, te recomendamos que registres el motivo por el que se detuvo llamando a WorkInfo.getStopReason() (para los trabajos de JobScheduler, llama a JobParameters.getStopReason()).

Para obtener información sobre cómo el estado de tu app afecta los recursos que puede usar, consulta Límites de recursos de administración de energía. Para obtener más información sobre las prácticas recomendadas para optimizar la batería, consulta la guía sobre cómo optimizar el uso de la batería para las APIs de programación de tareas.

También recomendamos aprovechar la nueva API de JobScheduler#getPendingJobReasonsHistory que se introdujo en Android 16 para comprender por qué no se ejecutó un trabajo.

Prueba

Para probar el comportamiento de tu app, puedes habilitar la anulación de ciertas optimizaciones de la cuota de trabajos siempre que la app se ejecute en un dispositivo Android 16.

Para inhabilitar la aplicación de la regla "El estado superior se ajustará a la cuota de tiempo de ejecución del trabajo", ejecuta el siguiente comando de adb:

adb shell am compat enable OVERRIDE_QUOTA_ENFORCEMENT_TO_TOP_STARTED_JOBS APP_PACKAGE_NAME

Para inhabilitar la aplicación de "los trabajos que se ejecutan de forma simultánea con un servicio en primer plano se ajustarán a la cuota de tiempo de ejecución del trabajo", ejecuta el siguiente comando de adb:

adb shell am compat enable OVERRIDE_QUOTA_ENFORCEMENT_TO_FGS_JOBS APP_PACKAGE_NAME

Para probar el comportamiento de un intervalo de Standby específico, puedes establecer el intervalo de Standby de tu app con el siguiente comando adb:

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

Para comprender el intervalo de Standby de la app en el que se encuentra tu app, puedes obtenerlo con el siguiente comando adb:

adb shell am get-standby-bucket APP_PACKAGE_NAME

Motivo de detención de trabajos vacíos abandonados

An abandoned job occurs when the JobParameters object associated with the job has been garbage collected, but JobService#jobFinished(JobParameters, boolean) has not been called to signal job completion. This indicates that the job may be running and being rescheduled without the app's awareness.

Apps that rely on JobScheduler, don't maintain a strong reference to the JobParameters object, and timeout will now be granted the new job stop reason STOP_REASON_TIMEOUT_ABANDONED, instead of STOP_REASON_TIMEOUT.

If there are frequent occurrences of the new abandoned stop reason, the system will take mitigation steps to reduce job frequency.

Apps should use the new stop reason to detect and reduce abandoned jobs.

If you're using WorkManager, AsyncTask, or DownloadManager, you aren't impacted because these APIs manage the job lifecycle on your app's behalf.

Se dejó de usar por completo JobInfo#setImportantWhileForeground

The JobInfo.Builder#setImportantWhileForeground(boolean) method indicates the importance of a job while the scheduling app is in the foreground or when temporarily exempted from background restrictions.

This method has been deprecated since Android 12 (API level 31). Starting in Android 16, it no longer functions effectively and calling this method will be ignored.

This removal of functionality also applies to JobInfo#isImportantWhileForeground(). Starting in Android 16, if the method is called, the method returns 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 包含 Android 运行时 (ART) 的最新更新，这些更新可提升 Android 运行时 (ART) 的性能，并支持更多 Java 功能。通过 Google Play 系统更新，搭载 Android 12（API 级别 31）及更高版本的 10 亿多部设备也将受益于这些改进。

发布这些变更后，依赖于 ART 内部结构的库和应用代码在搭载 Android 16 的设备以及通过 Google Play 系统更新来更新 ART 模块的较低 Android 版本上可能无法正常运行。

依赖于内部结构（例如非 SDK 接口）始终会导致兼容性问题，但避免依赖于利用内部 ART 结构的代码（或包含代码的库）尤为重要，因为 ART 更改与设备所运行的平台版本无关，并且会通过 Google Play 系统更新推送到超过 10 亿部设备。

所有开发者都应在 Android 16 上对其应用进行全面测试，以检查其应用是否受到影响。此外，请查看已知问题，了解您的应用是否依赖于我们发现的任何依赖于内部 ART 结构的库。如果您的应用代码或库依赖项受到影响，请尽可能寻找公共 API 替代方案，并在问题跟踪器中创建功能请求，为新用例请求公共 API。

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 dieron de baja los anuncios de accesibilidad que interrumpen

Android 16 da de baja los anuncios de accesibilidad, que se caracterizan por el uso de announceForAccessibility o el envío de eventos de accesibilidad TYPE_ANNOUNCEMENT. Esto puede crear experiencias del usuario incoherentes para los usuarios de TalkBack y el lector de pantalla de Android, y las alternativas satisfacen mejor una gama más amplia de necesidades de los usuarios en una variedad de tecnologías de accesibilidad de Android.

Ejemplos de alternativas:

• Para cambios significativos en la IU, como cambios de ventana, usa Activity.setTitle(CharSequence) y setAccessibilityPaneTitle(java.lang.CharSequence). En Compose, usa Modifier.semantics { paneTitle = "paneTitle" }.
• Para informar al usuario sobre los cambios en la IU crítica, usa setAccessibilityLiveRegion(int). En Compose, usa Modifier.semantics { liveRegion = LiveRegionMode.[Polite|Assertive]} . Se deben usar con moderación, ya que pueden generar anuncios cada vez que se actualiza una vista.
• Para notificar a los usuarios sobre errores, envía un AccessibilityEvent de tipo AccessibilityEvent#CONTENT_CHANGE_TYPE_ERROR y establece AccessibilityNodeInfo#setError(CharSequence), o usa TextView#setError(CharSequence).

La documentación de referencia de la API de announceForAccessibility, que dejó de estar disponible, incluye más detalles sobre las alternativas sugeridas.

Compatibilidad con la navegación con 3 botones

Android 16 brings predictive back support to the 3-button navigation for apps that have properly migrated to predictive back. Long-pressing the back button initiates a predictive back animation, giving you a preview of where the back swipe takes you.

This behavior applies across all areas of the system that support predictive back animations, including the system animations (back-to-home, cross-task, and cross-activity).

The predictive back animations in 3-button navigation mode.

Íconos de apps temáticos automáticos

A partir de Android 16 QPR 2, Android aplica automáticamente temas a los íconos de las apps para crear una experiencia cohesiva en la pantalla principal. Esto sucede si una app no proporciona su propio ícono de app temático. Las apps pueden controlar el diseño de su ícono de app temático si incluyen una capa monocromática dentro de su ícono adaptable y obtienen una vista previa de la apariencia de su ícono de app en 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

El propietario de un dispositivo virtual es una app de confianza o privilegiada que crea y administra un dispositivo virtual. Los propietarios de dispositivos virtuales ejecutan apps en un dispositivo virtual y, luego, las proyectan en la pantalla de un dispositivo remoto, como una computadora personal, un dispositivo de realidad virtual o un sistema de infoentretenimiento para automóviles. El propietario del dispositivo virtual se encuentra en un dispositivo local, como un teléfono celular.

El propietario del dispositivo virtual en el teléfono crea un dispositivo virtual que proyecta la app en la pantalla remota.

Anulaciones por app

En los dispositivos que ejecutan Android 16 (nivel de API 36), los propietarios de dispositivos virtuales pueden anular la configuración de apps en dispositivos virtuales seleccionados que administran. Por ejemplo, para mejorar el diseño de la app, el propietario de un dispositivo virtual puede ignorar las restricciones de orientación, relación de aspecto y cambio de tamaño cuando proyecta apps en una pantalla externa.

Cambios rotundos comunes

El comportamiento de Android 16 podría afectar la IU de tu app en factores de forma de pantalla grande, como las pantallas de automóviles o las Chromebooks, en especial los diseños que se crearon para pantallas pequeñas en orientación vertical. Para obtener más información sobre cómo hacer que tu app sea adaptable a todos los factores de forma de los dispositivos, consulta Acerca de los diseños adaptables.

Referencias

Transmisión de apps complementarias

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.

Presentamos soluciones de refuerzo de seguridad predeterminadas para los exploits 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 experimentar 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 generar robo de datos y 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 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 con 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, especialmente 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 在配套设备配对流程期间引入了一种新行为，以防恶意应用侵犯用户的位置信息隐私。在 Android 16 上运行的所有配套应用都不再直接通过 RESULT_DISCOVERY_TIMEOUT 收到发现超时通知。而是通过可视对话框通知用户超时事件。当用户关闭对话框时，系统会通过 RESULT_USER_REJECTED 提醒应用关联失败。

搜索时长也从原来的 20 秒延长到了 30 秒，并且用户可以在搜索期间的任何时间停止设备发现。如果在开始搜索的前 20 秒内发现了至少 1 部设备，CDM 会停止搜索其他设备。

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.