Wear OS 4 se basa en Android 13 (nivel de API 33), que es posterior a la versión en la que se basa Wear OS 3, Android 11 (nivel de API 30). Por lo tanto, cuando prepares tu app para Wear OS y la uses en Wear OS 4, debes controlar los cambios de comportamiento del sistema que se aplican a todas las apps en Android 12 y Android 13
Puedes mejorar aún más la compatibilidad de tu app con esta versión de Wear OS. Para ello, haz lo siguiente: orientadas a Android 13 (nivel de API 33).
Cambios en los permisos
Es probable que los siguientes cambios relacionados con los permisos afecten a tu App para Wear OS en un dispositivo que ejecute Wear OS 4 o una versión posterior
Permiso de notificaciones
En la mayoría de los casos, los usuarios deben otorgar un permiso de tiempo de ejecución de las notificaciones para tu app, incluso cuando esta publica notificaciones de actividades en curso.
Cuando los usuarios instalan tu app en un dispositivo que ejecuta Wear OS 4 o una versión posterior, tu
las notificaciones están desactivadas de forma predeterminada. Antes de publicar una notificación o
inicia una actividad en curso, comprueba si tu aplicación puede publicar
para recibir notificaciones llamando a areNotificationsEnabled(). Si este método
muestra true, tu app puede mostrar notificaciones. Si tu app no incluye
el permiso correcto, estas notificaciones fallarán silenciosamente sin ningún tiempo de ejecución
excepciones que se arrojen.
Cuando solicitas el permiso POST_NOTIFICATIONS en tu app, los usuarios ven el diálogo de permisos del sistema que aparece en la Figura 1.
Permiso de sensores corporales en segundo plano
En un dispositivo que ejecute Wear OS 4 o una versión posterior, los usuarios deben otorgar el permiso a tu app para obtener información de sensores corporales comunes, como la frecuencia cardíaca, en el en segundo plano.
Obtén más información en la guía para solicitar acceso en segundo plano a los datos de sensores corporales.
Permiso de ubicación aproximada
En un dispositivo que ejecute Wear OS 4 o versiones posteriores, los usuarios pueden solicitar que tu app
recuperar solo información de ubicación aproximada, incluso cuando tu app solicite la
Permiso de tiempo de ejecución ACCESS_FINE_LOCATION.
Verifica que tu app aún pueda cumplir con sus casos de uso clave, por ejemplo, mostrar una ruta de trote, si el usuario solo otorga la ubicación aproximada. En particular, cuando uses los Servicios de salud en Wear OS, ten en cuenta los errores de posición.
Descubre cómo el usuario puede otorgar solo la ubicación aproximada.
Cambios en los componentes y la navegación de la app
Los siguientes cambios relacionados con los componentes y la navegación de la app son más probables que tu app para Wear OS se vea afectada en un dispositivo que ejecute Wear OS 4 o una versión posterior.
Los filtros de intents bloquean los intents que no coinciden
Cuando tu app envía un intent a un componente exportado de otra app que
se orienta a Android 13 o versiones posteriores, ese intent se entrega solo si coincide
Un elemento <intent-filter> en la app receptora
Descubre cómo hacer coincidir los intents con los filtros de intents de otras apps.
Comportamiento de la actividad del selector raíz
Una actividad del selector se encuentra en la raíz de una tarea si declara un filtro de intents que incluye ACTION_MAIN y CATEGORY_LAUNCHER.
Si el usuario va a la pantalla anterior desde este tipo de actividad del selector, el sistema no finaliza esta actividad, sino que la coloca en segundo plano.
Obtén más información sobre este cambio en las actividades de selector raíz y el ciclo de vida de la actividad.
Verificación de vínculos de apps
El sistema realiza varios cambios en la manera en que se verifican los Android App Links. En particular, el sistema aplica, de manera forzosa, una sintaxis de filtro de intents más estricta para demostrar que las URLs de un dominio determinado deben abrir el contenido directamente en tu app. Estos cambios mejoran la confiabilidad de la experiencia de vinculación de apps, lo que proporciona más control a los desarrolladores de apps y los usuarios finales.
Para probar la confiabilidad de tus declaraciones, invoca la verificación del dominio de forma manual.
Se quitó la IU de la ventana de alerta del sistema
Wear OS 4 quita la IU del sistema para otorgar SYSTEM_ALERT_WINDOW.
permiso. Esta IU está disponible en algunos dispositivos que ejecutan Wear OS 3 y versiones anteriores.
Si usas ACTION_MANAGE_OVERLAY_PERMISSION para enviar a los usuarios a una página de configuración, en la que podrían mostrar tu app sobre otras, actualiza la lógica de tu app. Por ejemplo, si dependes de las ventanas de alerta del sistema para mostrar mensajes importantes, usa notificaciones en su lugar.
Cambios en la administración de datos y energía
Es más probable que los siguientes cambios relacionados con la administración de datos y la energía tu app para Wear OS en un dispositivo que ejecute Wear OS 4.
Intervalo restringido de App Standby
El sistema coloca la app en el intervalo de App Standby "restringido" si no se usa durante un período prolongado o si esta invoca una cantidad excesiva de transmisiones y vinculaciones.
Hibernación de apps
Si el usuario no interactúa con tu app durante unos meses, el sistema la ubica en un estado de hibernación.
Creación de copias de seguridad y restablecimiento
A partir de Wear OS 4, si un dispositivo Wear OS específico admite la copia de seguridad en la nube, los usuarios Puede crear una copia de seguridad de sus datos en la nube para transferirlos desde ese dispositivo. pueden restablecer datos de la nube para transferirlos a un nuevo dispositivo Wear OS.
Recomendaciones para ti
- Nota: El texto del vínculo se muestra cuando JavaScript está desactivado
- Cambios de comportamiento: Todas las apps
- Servicios en primer plano
- Permiso de tiempo de ejecución de notificaciones