Préparer votre application aux changements de comportement dans Wear OS 4

Wear OS 4 est basé sur Android 13 (niveau d'API 33), qui correspond à plusieurs versions version ultérieure à celle sur laquelle Wear OS 3 est basé, Android 11 (niveau d'API 30). Ainsi, lorsque vous préparez votre application Wear OS pour l'utiliser sous Wear OS 4, vous devez gérer les modifications de comportement du système qui s'appliquent à toutes les applications sous Android 12 ; et Android 13

Vous pouvez améliorer la compatibilité de votre application avec cette version de Wear OS : ciblant Android 13 (niveau d'API 33).

Modifications apportées aux autorisations

Les modifications suivantes, qui concernent les autorisations, sont les plus susceptibles d'affecter votre Application Wear OS sur un appareil exécutant Wear OS 4 ou version ultérieure.

Autorisation de notification

L'option "Allow" (Autoriser) est le premier bouton de la boîte de dialogue
Figure 1. La boîte de dialogue des autorisations système qui demande aux utilisateurs d'autoriser votre application Wear OS à afficher des notifications. Les utilisateurs peuvent choisir entre Autoriser et Ne pas autoriser.

Dans la plupart des cas, les utilisateurs doivent accorder une autorisation d'exécution de notification pour votre application, y compris lorsqu'elle affiche des notifications d'activités en cours.

Remarque : L'autorisation de notification ne s'applique pas aux notifications pontées, ni aux plusieurs cas d'utilisation spécifiques qui en sont exemptés, comme les sessions multimédias.

Lorsque les utilisateurs installent votre application sur un appareil exécutant Wear OS 4 ou une version ultérieure, votre les notifications de l'application sont désactivées par défaut. Avant de publier une notification locale ou lancer une activité en cours, vérifiez si votre appli est autorisée à publier notifications en appelant areNotificationsEnabled(). Si cette méthode renvoie true, votre application peut afficher des notifications. Si votre application ne dispose pas du l'autorisation appropriée, ces notifications échouent silencieusement sans aucun environnement d'exécution d'exceptions générées.

Lorsque vous demandez l'autorisation POST_NOTIFICATIONS dans votre application, la boîte de dialogue des autorisations système s'affiche, comme illustré dans la figure 1.

Autorisation d'accès aux capteurs corporels en arrière-plan

Sur un appareil exécutant Wear OS 4 ou version ultérieure, les utilisateurs doivent accorder l'autorisation à votre application pour obtenir des informations à partir des capteurs corporels courants, comme la fréquence cardiaque, en arrière-plan.

Pour en savoir plus, consultez le guide sur la demande d'accès en arrière-plan aux données des capteurs corporels.

Autorisation d'accéder à la position approximative

Sur un appareil exécutant Wear OS 4 ou version ultérieure, les utilisateurs peuvent demander que votre application récupérer uniquement les informations de localisation approximatives, même lorsque votre application demande Autorisation d'exécution ACCESS_FINE_LOCATION.

Vérifiez que votre application peut toujours traiter ses principaux cas d'utilisation (par exemple, afficher un itinéraire de jogging) si l'utilisateur n'accorde qu'une position approximative. En particulier, lorsque vous utilisez Services Santé sur Wear OS, tenez compte des erreurs de position.

Pour en savoir plus sur la façon dont l'utilisateur ne peut accorder qu'une position approximative, consultez cette page.

Modifications apportées aux composants de l'application et à la navigation

Les modifications suivantes liées aux composants d'application et à la navigation sont très probablement affecte votre application Wear OS sur un appareil équipé de Wear OS 4 ou version ultérieure.

Les filtres d'intent bloquent des intents qui ne correspondent pas

Lorsque votre application envoie un intent à un composant exporté d'une autre application qui cible Android 13 ou une version ultérieure, cet intent n'est diffusé que s'il correspond un élément <intent-filter> dans l'application réceptrice.

Découvrez comment établir une correspondance entre des intents et les filtres d'intent d'autres applications.

Comportement de l'activité du lanceur d'applications racine

Une activité du lanceur d'applications se trouve dans la racine d'une tâche s'il déclare un filtre d'intent qui inclut à la fois ACTION_MAIN et CATEGORY_LAUNCHER.

Si l'utilisateur quitte ce type d'activité de lanceur d'applications pour revenir à l'écran précédent, le système ne termine pas l'activité. Au lieu de cela, il la place en arrière-plan.

Pour en savoir plus sur cette modification des activités du lanceur d'applications racine et du cycle de vie d'une activité, consultez cette page.

Le système apporte plusieurs modifications à la méthode de validation d'Android App Links. En particulier, le système applique une syntaxe de filtre d'intent plus stricte pour démontrer que les URL d'un domaine particulier doivent ouvrir le contenu directement dans votre application. Ces modifications améliorent la fiabilité de l'expérience d'association d'applications, qui offre plus de contrôle aux développeurs d'applications et aux utilisateurs finaux.

Pour tester la fiabilité de vos déclarations, appelez manuellement la validation de domaine.

L'UI de la fenêtre d'alerte système est supprimée

Wear OS 4 supprime l'UI du système pour accorder l'autorisation SYSTEM_ALERT_WINDOW. l'autorisation. Cette UI est disponible sur certains appareils équipés de Wear OS 3 ou version antérieure.

Si vous utilisez ACTION_MANAGE_OVERLAY_PERMISSION pour rediriger les utilisateurs vers une page de paramètres où ils peuvent afficher votre appli par-dessus d'autres applis, mettez à jour la logique de votre appli. Par exemple, si vous utilisez des fenêtres d'alerte système pour afficher les messages importants, utilisez plutôt des notifications.

Modifications apportées à la gestion de l'alimentation et des données

Les changements suivants liés à la gestion de l'alimentation et des données sont les plus probables affecte votre application Wear OS sur un appareil exécutant Wear OS 4.

Bucket de mise en veille des applications limité

Le système place votre application dans le bucket de mise en veille des applications "limité" si elle n'est pas utilisée pendant une période prolongée, ou si elle appelle un nombre excessif de diffusions et de liaisons.

Hibernation des applications

Si l'utilisateur n'interagit pas avec votre application pendant quelques mois, le système la fait passer en hibernation.

Sauvegarde et restauration

À partir de Wear OS 4, si un appareil Wear OS spécifique est compatible avec la sauvegarde dans le cloud, les utilisateurs peuvent sauvegarder leurs données dans le cloud afin de les transférer depuis cet appareil ; il peut restaurer des données depuis le cloud pour les transférer sur un nouvel appareil Wear OS.