Al igual que las versiones anteriores, Android 16 incluye cambios de comportamiento que podrían afectar tu app. Los siguientes cambios se aplican exclusivamente a las apps orientadas a Android 16 o versiones posteriores. Si tu app está orientada a Android 16 o versiones posteriores, debes modificarla para que admita estos comportamientos, cuando corresponda.
Asegúrate de revisar también la lista de cambios de comportamiento que afectan a todas las apps que se ejecutan en Android 16, independientemente de targetSdkVersion
de la app.
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.
Migración o inhabilitación obligatoria para el gesto atrás predictivo
En el caso de las apps que se orientan a Android 16 o versiones posteriores y se ejecutan en un dispositivo con Android 16 o versiones posteriores, las animaciones del sistema de atrás predictivo (volver a la página principal, cambiar de tarea y cambiar de actividad) están habilitadas de forma predeterminada.
Además, no se llama a onBackPressed
y ya no se envía KeyEvent.KEYCODE_BACK
.
Si tu app intercepta el evento atrás y aún no migraste al gesto atrás predictivo, actualiza tu app para usar las APIs de navegación atrás compatibles o inhabilita temporalmente la función configurando el atributo android:enableOnBackInvokedCallback
como false
en la etiqueta <application>
o <activity>
del archivo AndroidManifest.xml
de tu app.
Funcionalidad principal
Android 16 incluye los siguientes cambios que modifican o expanden varias funciones principales del sistema Android.
Optimización de la programación de trabajo con tarifa fija
Antes de orientarse a Android 16, cuando scheduleAtFixedRate
omitía la ejecución de una tarea debido a que estaba fuera de un ciclo de vida del proceso válido, todas las ejecuciones omitidas se ejecutaban de inmediato cuando la app regresaba a un ciclo de vida válido.
Cuando se orienta a Android 16, se ejecuta de inmediato una ejecución perdida de scheduleAtFixedRate
cuando la app vuelve a un ciclo de vida válido. Se espera que este cambio de comportamiento mejore el rendimiento de la app. Prueba este comportamiento en tu app para verificar si se ve afectada.
También puedes realizar pruebas con el marco de compatibilidad de apps y habilitar la marca de compatibilidad STPE_SKIP_MULTIPLE_MISSED_PERIODIC_TASKS
.
Pantallas grandes y factores de forma
Android 16 incluye los siguientes cambios para las apps cuando se muestran en dispositivos de pantalla grande.
Diseños adaptables
Dado que las apps para Android ahora se ejecutan en una variedad de dispositivos (como teléfonos, tablets, plegables y computadoras de escritorio) y modos de ventana en pantallas grandes (como la pantalla dividida y la ventana de escritorio), los desarrolladores deben compilar apps para Android que se adapten a cualquier tamaño de pantalla y ventana, independientemente de la orientación del dispositivo. Los paradigmas como la restricción de la orientación y el cambio de tamaño son demasiado restrictivos en el mundo multidispositivo actual.
Ignora las restricciones de orientación, cambio de tamaño y relación de aspecto
En el caso de las apps que se orientan a Android 16, esta versión incluye cambios en la forma en que el sistema administra las restricciones de orientación, tamaño y relación de aspecto. En las pantallas con un ancho más pequeño >= 600 dp, ya no se aplican las restricciones. Las apps también ocupan toda la ventana de visualización, independientemente de la relación de aspecto o la orientación preferida del usuario, y no se usa el formato pillarbox.
Este cambio introduce un nuevo comportamiento estándar de la plataforma. Android se está moviendo hacia un modelo en el que se espera que las apps se adapten a varias orientaciones, tamaños de pantalla y relaciones de aspecto. Las restricciones, como la orientación fija o el cambio de tamaño limitado, dificultan la adaptabilidad de la app, por lo que te recomendamos que la hagas adaptable para ofrecer la mejor experiencia del usuario posible.
Cambios rotundos comunes
Si ignoras las restricciones de orientación, cambio de tamaño y relación de aspecto, es posible que se vea afectada la IU de tu app en algunos dispositivos, en especial los elementos diseñados para diseños pequeños bloqueados en orientación vertical, por ejemplo, problemas como diseños estirados y animaciones y componentes fuera de la pantalla. Cualquier suposición sobre la relación de aspecto o la orientación puede causar problemas visuales en tu app. Obtén más información para evitarlos y mejorar el comportamiento adaptable de tu app.
Permitir la rotación del dispositivo genera más recreaciones de actividades, lo que puede provocar la pérdida del estado del usuario si no se conserva correctamente. Obtén información para guardar correctamente el estado de la IU en Cómo guardar estados de la IU.
Detalles de implementación
Los siguientes atributos del manifiesto y las APIs del tiempo de ejecución se ignoran en los dispositivos de pantalla grande en los modos de pantalla completa y multiventana:
screenOrientation
resizableActivity
minAspectRatio
maxAspectRatio
setRequestedOrientation()
getRequestedOrientation()
Se ignoran los siguientes valores para screenOrientation
, setRequestedOrientation()
y getRequestedOrientation()
:
portrait
reversePortrait
sensorPortrait
userPortrait
landscape
reverseLandscape
sensorLandscape
userLandscape
En cuanto al cambio de tamaño de la pantalla, android:resizeableActivity="false"
, android:minAspectRatio
y android:maxAspectRatio
no tienen efecto.
En el caso de las apps orientadas a Android 16, la orientación, el cambio de tamaño y las restricciones de relación de aspecto de la app se ignoran en pantallas grandes de forma predeterminada, pero todas las apps que no están completamente listas pueden anular temporalmente este comportamiento inhabilitando la opción (lo que genera el comportamiento anterior de colocarse en el modo de compatibilidad).
Excepciones
Las restricciones de orientación, tamaño y relación de aspecto de Android 16 no se aplican en las siguientes situaciones:
- Juegos (según la marca
android:appCategory
) - Los usuarios que habilitan de forma explícita el comportamiento predeterminado de la app en la configuración de la relación de aspecto del dispositivo
- Pantallas más pequeñas que
sw600dp
Inhabilitar temporalmente
Para inhabilitar una actividad específica, declara la propiedad del manifiesto PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY
:
<activity ...>
<property android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY" android:value="true" />
...
</activity>
Si demasiadas partes de tu app no están preparadas para Android 16, puedes inhabilitar la función por completo aplicando la misma propiedad a nivel de la aplicación:
<application ...>
<property android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY" android:value="true" />
</application>
Salud y fitness
Android 16 incluye los siguientes cambios relacionados con los datos de salud y fitness.
Permisos de salud y fitness
En el caso de las apps orientadas a Android 16 o versiones posteriores, los permisos BODY_SENSORS
están en transición a los permisos detallados de android.permissions.health
que también usa Health Connect. Cualquier API que antes requiriera BODY_SENSORS
o BODY_SENSORS_BACKGROUND
ahora requiere el permiso android.permissions.health
correspondiente. Esto afecta los siguientes tipos de datos, APIs y tipos de servicios en primer plano:
HEART_RATE_BPM
de los Servicios de salud para WearSensor.TYPE_HEART_RATE
desde el Administrador de sensores de AndroidheartRateAccuracy
yheartRateBpm
de WearProtoLayout
FOREGROUND_SERVICE_TYPE_HEALTH
, en el que se necesita el permisoandroid.permission.health
correspondiente en lugar deBODY_SENSORS
Si tu app usa estas APIs, ahora debe solicitar los permisos detallados correspondientes:
- Para la supervisión durante el uso de la frecuencia cardíaca, la SpO2 o la temperatura de la piel, solicita el permiso detallado en
android.permissions.health
, comoREAD_HEART_RATE
en lugar deBODY_SENSORS
. - Para el acceso a los sensores en segundo plano, solicita
READ_HEALTH_DATA_IN_BACKGROUND
en lugar deBODY_SENSORS_BACKGROUND
.
Estos permisos son los mismos que protegen el acceso a la lectura de datos de Health Connect, el almacén de datos de Android para datos de salud, fitness y bienestar.