Cambios de comportamiento: todas las apps

La plataforma de Android 16 incluye cambios de comportamiento que podrían afectar tu app. Los siguientes cambios de comportamiento 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 consultar 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.

Baja completa de 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 de ART

Android 16 includes the latest updates to the Android Runtime (ART) that improve the Android Runtime's (ART's) performance and provide support for additional Java features. Through Google Play System updates, these improvements are also available to over a billion devices running Android 12 (API level 31) and higher.

As these changes are released, libraries and app code that rely on internal structures of ART might not work correctly on devices running Android 16, along with earlier Android versions that update the ART module through Google Play system updates.

Relying on internal structures (such as non-SDK interfaces) can always lead to compatibility problems, but it's particularly important to avoid relying on code (or libraries containing code) that leverages internal ART structures, since ART changes aren't tied to the platform version the device is running on and they go out to over a billion devices through Google Play system updates.

All developers should check whether their app is impacted by testing their apps thoroughly on Android 16. In addition, check the known issues to see if your app depends on any libraries that we've identified that rely on internal ART structures. If you do have app code or library dependencies that are affected, seek public API alternatives whenever possible and request public APIs for new use cases by creating a feature request in our issue tracker.

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, lo 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.

Cuando tu app se ejecuta en un dispositivo con Android 16 o versiones posteriores, 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 compatibilidad con versiones anteriores, se evitará que se muestre el diálogo cuando se inicie tu app. Para usar la propiedad android:pageSizeCompat, compila tu app con el SDK de Android 16.

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

Baja de anuncios de accesibilidad disruptivos

Android 16 deprecates accessibility announcements, characterized by the use of announceForAccessibility or the dispatch of TYPE_ANNOUNCEMENT accessibility events. These can create inconsistent user experiences for users of TalkBack and Android's screen reader, and alternatives better serve a broader range of user needs across a variety of Android's assistive technologies.

Examples of alternatives:

• For significant UI changes like window changes, use Activity.setTitle(CharSequence) and setAccessibilityPaneTitle(java.lang.CharSequence). In Compose, use Modifier.semantics { paneTitle = "paneTitle" }
• To inform the user of changes to critical UI, use setAccessibilityLiveRegion(int). In Compose, use Modifier.semantics { liveRegion = LiveRegionMode.[Polite|Assertive]} . These should be used sparingly as they may generate announcements every time a View is updated.
• To notify users about errors, send an AccessibilityEvent of type AccessibilityEvent#CONTENT_CHANGE_TYPE_ERROR and set AccessibilityNodeInfo#setError(CharSequence), or use TextView#setError(CharSequence).

The reference documentation for the deprecated announceForAccessibility API includes more details about suggested alternatives.

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).

Í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 los proyectan en pantallas.

Anulaciones del propietario del dispositivo virtual

A virtual device owner is a trusted or privileged app that creates and manages a virtual device. Virtual device owners run apps on a virtual device and then project the apps to the display of a remote device, such as a personal computer, virtual reality device, or car infotainment system. The virtual device owner is on a local device, such as a mobile phone.

Per-app overrides

On devices running Android 16 (API level 36), virtual device owners can override app settings on select virtual devices that the virtual device owners manage. For example, to improve app layout, a virtual device owner can ignore orientation, aspect ratio, and resizability restrictions when projecting apps onto an external display.

Common breaking changes

The Android 16 behavior might impact your app's UI on large screen form factors such as car displays or Chromebooks, especially layouts that were designed for small displays in portrait orientation. To learn how to make your app adaptive for all device form factors, see About adaptive layouts.

References

Companion app streaming

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 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 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 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 casos de uso legítimos de la app.

Para aplicaciones compiladas 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().

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 descubrimiento

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.

Manejo mejorado 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.