Al igual que las versiones anteriores, Android 13 incluye cambios de comportamiento que podrían afectar tu app. Los siguientes cambios se aplican exclusivamente a las apps orientadas a Android 13 o versiones posteriores. Si tu app está orientada a Android 13 o versiones posteriores, debes modificarla para que admita estos comportamientos correctamente, cuando corresponda.
Asegúrate de revisar también la lista de cambios en el comportamiento que afectan a todas las apps que se ejecutan en Android 13.
Privacidad
El permiso de notificaciones afecta la apariencia de los servicios en primer plano
Si el usuario rechaza el permiso de notificaciones, no verá avisos relacionados con los servicios en primer plano en el panel lateral de notificaciones. Sin embargo, los usuarios aún ven esos avisos en el Administrador de tareas de servicios en primer plano (FGS), sin importar si se otorga el permiso de notificaciones.
Nuevo permiso de tiempo de ejecución para dispositivos de Wi-Fi cercanos
En versiones anteriores de Android, el usuario debe otorgarle a tu app el ACCESS_FINE_LOCATION permiso para completar varios casos de uso frecuentes de Wi-Fi.
Como es difícil para los usuarios asociar permisos de ubicación con la funcionalidad de Wi-Fi, Android 13 (nivel de API 33) incorpora un permiso de tiempo de ejecución en el grupo de permisos NEARBY_DEVICES para apps que administran las conexiones de un dispositivo a puntos de acceso cercanos a través de Wi-Fi. Este permiso, NEARBY_WIFI_DEVICES, completa casos de uso de Wi-Fi como los siguientes:
- Buscar dispositivos cercanos, como impresoras o dispositivos de transmisión de contenido multimedia, o conectarse a ellos.
Este flujo de trabajo permite que tu app realice este tipo de tareas:
- Recibir información del punto de acceso fuera de banda, por ejemplo, a través de BLE
- Descubrir dispositivos y conectarse a ellos a través de Wi-Fi Aware y conectarse mediante un hotspot solo local
- Descubrir dispositivos y conectarse a ellos a través de Wi-Fi directo
- Iniciar una conexión a un SSID conocido, como un automóvil o un dispositivo de casa inteligente.
- Iniciar un hotspot solo local.
- Alcanzar dispositivos cercanos de Wi-Fi Aware
Siempre que tu app no obtenga información de la ubicación física de las APIs de Wi-Fi, solicita NEARBY_WIFI_DEVICES en lugar de ACCESS_FINE_LOCATION cuando orientes tu app a Android 13 o versiones posteriores y uses APIs de Wi-Fi. Cuando declaras el permiso NEARBY_WIFI_DEVICES, afirma con firmeza que tu app nunca obtiene información de la ubicación física de las APIs de Wi-Fi. Para hacerlo, configura el atributo android:usesPermissionFlags en neverForLocation. Este proceso es similar al que realizas en Android 12 (nivel de API 31) y versiones posteriores, cuando declaras que la información del dispositivo Bluetooth nunca se usa para la ubicación.
Obtén más información sobre cómo solicitar permiso para acceder a dispositivos Wi-Fi cercanos.
Permisos de contenido multimedia detallados
READ_MEDIA_AUDIO.Si tu app se orienta a Android 13 o versiones posteriores y necesita acceder a archivos multimedia que crearon otras apps, debes solicitar uno o más de los siguientes permisos de contenido multimedia detallados en lugar de el permiso READ_EXTERNAL_STORAGE:
| Tipo de contenido multimedia | Permiso para solicitar |
|---|---|
| Imágenes y fotos | READ_MEDIA_IMAGES |
| Videos | READ_MEDIA_VIDEO |
| Archivos de audio | READ_MEDIA_AUDIO |
Si el usuario otorgó antes el permiso READ_EXTERNAL_STORAGE a tu app, el sistema le otorgará automáticamente los permisos de contenido multimedia detallados. De lo contrario, el sistema mostrará un diálogo para el usuario cuando tu app solicite cualquiera de los permisos que se muestran en la tabla anterior. En la Figura 1, la app solicita el permiso READ_MEDIA_AUDIO.
Si solicitas los permisos READ_MEDIA_IMAGES y READ_MEDIA_VIDEO al mismo tiempo, solo aparecerá un diálogo de permiso del sistema.
El uso de sensores corporales en segundo plano requiere un permiso nuevo
Android 13 introduce el concepto de acceso "durante el uso" para los sensores corporales, como el ritmo cardíaco, la temperatura y el porcentaje de oxígeno en sangre. Este modelo de acceso es muy similar al que introdujo el sistema para la ubicación en Android 10 (nivel de API 29).
Si tu app se orienta a Android 13 y requiere acceso a la información del sensor corporal mientras se ejecuta en segundo plano, debes declarar el nuevo permiso BODY_SENSORS_BACKGROUND además del permiso existente BODY_SENSORS.
Rendimiento y batería
Uso de recursos de batería
Si el usuario coloca tu app en estado "restringido" para el uso de batería en segundo plano mientras la app se orienta a Android 13, el sistema no entrega la transmisión BOOT_COMPLETED ni LOCKED_BOOT_COMPLETED hasta que se inicie la app por otros motivos.
Experiencia del usuario
Controles multimedia derivados de PlaybackState
En el caso de las apps que se orientan a Android 13 (nivel de API 33) y versiones posteriores, el sistema obtiene controles multimedia de las acciones de PlaybackState. De esta manera, el sistema puede mostrar un conjunto de controles más completo que sea técnicamente coherente entre teléfonos y tablets, y también que se alinee con la forma en que se renderizan los controles multimedia en otras plataformas de Android, como Android Auto y Android TV.
En la Figura 2, se muestra un ejemplo de cómo se ve en un teléfono y una tablet, respectivamente.
Antes de Android 13, el sistema mostraba hasta cinco acciones de la notificación de MediaStyle en el orden en que se agregaron.
En el modo compacto, por ejemplo, en la configuración rápida contraída, se mostraron hasta tres acciones especificadas con setShowActionsInCompactView().
A partir de Android 13, el sistema muestra hasta cinco botones de acción en función de PlaybackState, como se describe en la siguiente tabla. En el modo compacto, solo se mostrarán las primeras tres ranuras de acción. En el caso de las apps que no se orientan a Android 13 o que no incluyen PlaybackState, el sistema mostrará los controles en función de la lista de Action que se agregó a la notificación de MediaStyle, como se describió en el párrafo anterior.
| Ranura | Acción | Criterios |
|---|---|---|
| 1 | Reproducir |
El estado actual de PlaybackState es uno de los siguientes:
|
| Ícono giratorio de carga |
El estado actual de PlaybackState es uno de los siguientes:
|
|
| Pausar | El estado actual de PlaybackState no es ninguno de los anteriores. |
|
| 2 | Anterior | Las acciones de PlaybackState incluyen ACTION_SKIP_TO_PREVIOUS. |
| Personalizada | Las acciones de PlaybackState no incluyen ACTION_SKIP_TO_PREVIOUS, y las acciones personalizadas de PlaybackState incluyen una acción personalizada que todavía no se implementó. |
|
| Vacío | Los extras de PlaybackState incluyen un valor booleano true para la clave SESSION_EXTRAS_KEY_SLOT_RESERVATION_SKIP_TO_PREV. |
|
| 3 | Siguiente | Las acciones de PlaybackState incluyen ACTION_SKIP_TO_NEXT. |
| Personalizada | Las acciones de PlaybackState no incluyen ACTION_SKIP_TO_NEXT, y las acciones personalizadas de PlaybackState incluyen una acción personalizada que todavía no se implementó. |
|
| Vacío | Los extras de PlaybackState incluyen un valor booleano true para la clave SESSION_EXTRAS_KEY_SLOT_RESERVATION_SKIP_TO_NEXT. |
|
| 4 | Personalizada | Las acciones personalizadas de PlaybackState incluyen una acción personalizada que todavía no se realizó. |
| 5 | Personalizada | Las acciones personalizadas de PlaybackState incluyen una acción personalizada que todavía no se realizó. |
Las acciones personalizadas se muestran en el orden en que se agregaron a PlaybackState.
Tema de color de las apps aplicado automáticamente al contenido de WebView
En el caso de las apps orientadas a Android 13 (nivel de API 33) o versiones posteriores, el método setForceDark() es obsoleto, lo que genera una no-op si se llama al método.
En cambio, WebView ahora establece la consulta de medios prefers-color-scheme según el atributo del tema de la app, isLightTheme. En otras palabras, si isLightTheme es true o no se especifica, prefers-color-scheme es light; de lo contrario, es dark. Este comportamiento significa que el estilo oscuro o claro del contenido web se aplica automáticamente para que coincida con el tema de la app si el contenido lo admite.
Para la mayoría de las apps, el nuevo comportamiento debería aplicar automáticamente los estilos de app adecuados. Sin embargo, debes probar tu app para verificar si hay casos en los que hayas controlado en forma manual la configuración del modo oscuro.
Si aún necesitas personalizar el comportamiento del tema de color de tu app, usa el método setAlgorithmicDarkeningAllowed() como alternativa. A fin de brindar retrocompatibilidad con versiones de Android anteriores, te recomendamos usar el método setAlgorithmicDarkeningAllowed() equivalente en AndroidX.
Consulta la documentación sobre ese método para obtener más información sobre el comportamiento que se puede esperar en tu app según la targetSdkVersion y la configuración de tema.
Servicios de Google Play
Se requiere permiso para el ID de publicidad
Las apps que usan el ID de publicidad de Servicios de Google Play y se orientan a Android 13 (nivel de API 33) y versiones posteriores deben declarar el permiso normal AD_ID en el archivo de manifiesto de la app, de la siguiente manera:
<manifest ...>
<!-- Required only if your app targets Android 13 or higher. -->
<uses-permission android:name="com.google.android.gms.permission.AD_ID"/>
<application ...>
...
</application>
</manifest>
Si tu app no declara este permiso cuando se orienta a Android 13 o versiones posteriores, se quita automáticamente el ID de publicidad y se reemplaza por una string de ceros.
Si tu app usa SDKs que declaran el permiso AD_ID en el manifiesto de la biblioteca, este se combinará con el archivo de manifiesto de tu app de forma predeterminada. En este caso, no necesitas declarar el permiso en el archivo de manifiesto de tu app.
Para obtener más información, consulta ID de publicidad en la Ayuda de Play Console.
Actualización de restricciones que no pertenecen al SDK
Android 13 incluye listas actualizadas de este tipo de interfaces que están basadas en la colaboración con desarrolladores de Android y las pruebas internas más recientes. Siempre que sea posible, nos aseguramos de que las alternativas públicas estén disponibles antes de restringir las interfaces que no pertenecen al SDK.
Si tu app no está orientada a Android 13, es posible que algunos de estos cambios no te afecten de inmediato. Sin embargo, aunque actualmente puedes usar algunas interfaces que no pertenecen al SDK (según el nivel de API objetivo al que esté orientada la app), utilizar cualquier método o campo que no pertenezca al SDK siempre implica un gran riesgo de error para la app.
En caso de no saber con certeza si tu app usa este tipo de interfaces, puedes probarla para verificarlo. Si tu app depende de interfaces que no pertenezcan al SDK, deberías planificar una migración hacia otras alternativas que sí lo hagan. Sin embargo, sabemos que algunas apps tienen casos prácticos válidos para usarlas. Si no encuentras una alternativa al uso de una interfaz que no pertenece al SDK para una función de tu app, deberías solicitar una nueva API pública.
Para obtener más información sobre los cambios implementados en esta versión de Android, consulta Actualizaciones de las restricciones de interfaces que no pertenecen al SDK en Android 13. Para obtener más información sobre las interfaces que no pertenecen al SDK en general, consulta Restricciones en interfaces que no pertenecen al SDK.