La plataforma de Android 16 incluye cambios de comportamiento que podrían afectar a 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 incluye los siguientes cambios que modifican o expanden varias funciones principales del sistema Android.
Optimizaciones de cuotas de JobScheduler
A partir de Android 16, ajustamos la cuota del tiempo de ejecución de la ejecución de trabajos normales y acelerados en función de los siguientes factores:
- En qué bucket de modo de espera de la app se encuentra la aplicación: En Android 16, se comenzará a aplicar una cuota generosa del tiempo de ejecución a los buckets de modo de espera activos.
- Si la tarea comienza a ejecutarse mientras la app está en un estado superior: En Android 16, las tareas 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 del entorno de ejecución de la tarea.
- Si la tarea se ejecuta mientras se ejecuta un servicio en primer plano: En Android 16, las tareas que se ejecutan de forma simultánea con un servicio en primer plano cumplirán con la cuota del entorno de ejecución de la tarea. Si aprovechas tareas para la transferencia de datos que inicia el usuario, considera usar tareas de transferencia de datos que inicia 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 llamando a WorkInfo.getStopReason() (para trabajos de JobScheduler, llama a JobParameters.getStopReason()).
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ó una tarea.
Prueba
Para probar el comportamiento de tu app, puedes habilitar la anulación de ciertas optimizaciones de la cuota de trabajo, siempre que la app se ejecute en un dispositivo Android 16.
Para inhabilitar la aplicación forzosa de "el estado superior se ajustará a la cuota del tiempo de ejecución del trabajo", ejecuta el siguiente comando adb:
adb shell am compat enable OVERRIDE_QUOTA_ENFORCEMENT_TO_TOP_STARTED_JOBS APP_PACKAGE_NAME
Para inhabilitar la aplicación forzosa de "las tareas que se ejecutan de forma simultánea con un servicio en primer plano cumplirán con la cuota del entorno de ejecución de la tarea", ejecuta el siguiente comando adb:
adb shell am compat enable OVERRIDE_QUOTA_ENFORCEMENT_TO_FGS_JOBS APP_PACKAGE_NAME
Para probar cierto comportamiento del bucket de App Standby, puedes configurar el bucket de App 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 bucket de App Standby en el que se encuentra tu app, puedes obtener el bucket de App Standby de tu app con el siguiente comando 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:
- 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.
- 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 de 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 introdujo la compatibilidad con páginas de memoria de 16 KB para optimizar el rendimiento de la plataforma. Android 16 agrega un modo de compatibilidad, que permite que algunas apps compiladas para páginas de memoria de 4 KB se ejecuten en un dispositivo configurado para páginas de memoria de 16 KB.
Si Android detecta que tu app tiene páginas de memoria alineadas de 4 KB, usa automáticamente el modo de compatibilidad y muestra un diálogo de notificación al usuario. Si configuras la propiedad android:pageSizeCompat en AndroidManifest.xml para habilitar el modo de retrocompatibilidad, se evitará que se muestre el diálogo cuando se inicie la app. Para obtener el mejor rendimiento, confiabilidad y estabilidad, tu app aún debe estar alineada en 16 KB. Consulta
nuestra entrada de blog reciente
sobre cómo actualizar tus apps para que admitan páginas de memoria de 16 KB y obtener más detalles.
Experiencia del usuario y IU del sistema
Android 16 incluye los siguientes cambios, cuyo objetivo es crear una experiencia del usuario más intuitiva y coherente.
Se darán de baja los anuncios de accesibilidad disruptivos
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).
Seguridad
Android 16 incluye cambios que promueven la seguridad del sistema para ayudar a proteger a las apps y a los usuarios de las apps maliciosas.
Mayor seguridad contra los ataques de redireccionamiento de intents
Android 16 proporciona seguridad predeterminada contra ataques generales de redireccionamiento de Intent, con compatibilidad mínima y cambios necesarios para los desarrolladores.
Presentamos soluciones de endurecimiento de la seguridad de forma predeterminada para los exploits de redireccionamiento de Intent. En la mayoría de los casos, las apps que usan intents no suelen tener problemas de compatibilidad. Recopilamos métricas durante nuestro proceso de desarrollo para supervisar qué apps podrían tener fallas.
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 víctima, active acciones con privilegios o obtenga acceso de URI a datos sensibles, lo que podría generar robo de datos y ejecución de código arbitraria.
Cómo inhabilitar el manejo de redireccionamiento de intents
Android 16 presenta una nueva API que permite a las apps inhabilitar las protecciones de seguridad de inicio. Esto puede ser necesario en casos específicos en los que el comportamiento de seguridad predeterminado interfiera con casos de uso legítimos de la app.
Para aplicaciones que compilan con el SDK de Android 16 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().
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) }