Ajouter la prise en charge d'Android Automotive OS à votre application à utiliser à l'arrêt

Lorsque vous distribuez votre application sur des appareils Android Automotive OS, vous devez tenir compte de certains éléments propres au facteur de forme. Ce guide explique ces considérations.

Tester l'application sur un émulateur d'Android Automotive OS

Pour commencer à compiler votre application pour Android Automotive OS, testez d'abord votre application existante sur un émulateur d'Android Automotive OS. Pour configurer un émulateur, suivez la procédure décrite dans Effectuer des tests avec l'émulateur d'Android Automotive OS. Vous pouvez ensuite exécuter l'application en suivant les instructions de la section Exécuter votre application sur l'émulateur.

Lorsque vous exécutez votre application, soyez attentif aux problèmes de compatibilité suivants :

• Les écrans d'infoloisirs ont une orientation fixe. Pour respecter les consignes relatives à la qualité des applications pour voitures, les applications doivent être compatibles avec les orientations portrait et paysage.
• Les API disponibles sur d'autres appareils peuvent ne pas l'être sur Android Automotive OS. Par exemple, certaines API des services Google Play ne sont pas disponibles sur Android Automotive OS. Consultez la section Désactiver des fonctionnalités pour découvrir comment gérer ces problèmes.

Configurer le fichier manifeste de votre application

Pour cibler les appareils Android Automotive OS, votre application doit comporter certaines entrées de fichier manifeste. Une fois que vous avez activé la distribution sur les appareils Android Automotive OS, les applications compatibles sont soumises à un processus d'examen manuel afin de s'assurer qu'elles peuvent être utilisées de façon sécurisée dans une voiture. Pour en savoir plus, consultez Distribuer sur les voitures.

Fonctionnalités requises pour Android Automotive OS

Toutes les applications créées pour Android Automotive OS doivent répondre à certaines exigences pour être distribuées via Google Play. Pour en savoir plus, consultez Répondre aux exigences concernant les fonctionnalités Google Play.

Avertissement :Si votre application ne répond pas à ces exigences, elle sera refusée lors de son envoi sur Google Play.

Entrées de fichier manifeste spécifiques à une catégorie

En plus des exigences précédentes, qui s'appliquent à toutes les applications à l'arrêt, les catégories "Vidéo" et "Jeux" présentent des exigences supplémentaires:

• Pour les applications vidéo, consultez Identifier votre application comme une application vidéo.
• Pour les jeux, consultez Marquer votre application comme application de jeu.

Respecter les exigences concernant la distraction du conducteur

Il est essentiel d'éviter toute distraction du conducteur lorsque vous déployez votre application dans les voitures. Pour les applications à utiliser à l'arrêt, cela se fait principalement en empêchant votre application d'être utilisée ou de lire de l'audio lorsque les restrictions liées à l'expérience utilisateur (UX) sont actives, comme indiqué dans les consignes de qualité DD-2 et DD-3.

Remarque :Les applications vidéo constituent une exception à cette règle. Elles peuvent activer l'audio pendant la conduite sur les appareils compatibles pour permettre aux utilisateurs de continuer à lire du contenu lorsque les restrictions d'expérience utilisateur sont actives.

Empêcher l'utilisation lorsque les restrictions sur l'expérience utilisateur sont actives

Par défaut, les activités ne peuvent pas être utilisées ni lancées lorsque les restrictions d'expérience utilisateur sont actives. Pour vous assurer que ce comportement s'applique à votre application, celle-ci ne doit pas inclure l'élément <meta-data> suivant dans un élément <activity> dans votre fichier manifeste:

<!-- NOT ALLOWED -->
<meta-data
  android:name="distractionOptimized"
  android:value="true"/>

Si une activité de votre application est reprise lorsque les restrictions liées à l'expérience utilisateur deviennent actives, elle est masquée par une activité appartenant à l'OS.

Au minimum, l'activité de votre application passe à l'état de cycle de vie Suspendu. Il s'agit d'un rappel de cycle de vie onPause(), au cours duquel vous devez suspendre la lecture vidéo et audio à partir de votre application.

Sur les appareils qui incluent le mode de compatibilité Android Automotive OS, le blocage du système entraîne la transition des activités de votre application de l'état Paused (En veille) à l'état Stopped (Arrêté).

Arrêter la lecture et empêcher sa reprise

Pour certaines applications, la mise en pause de la lecture pendant onPause() et le suivi de l'état pour empêcher la reprise de la lecture jusqu'à onResume() est suffisant pour répondre aux exigences de distraction du conducteur.

Si la réaction aux rappels de cycle de vie n'est pas suffisante pour votre application, vous pouvez écouter directement l'état de la restriction d'expérience utilisateur, comme décrit dans la section suivante. Par exemple, les applications compatibles avec le mode Picture-in-picture peuvent préférer écouter directement plutôt que d'effectuer des vérifications conditionnelles dans les rappels de cycle de vie.

Écouter les restrictions liées à l'expérience utilisateur

Pour écouter les restrictions d'expérience utilisateur, commencez par ajouter une dépendance à la bibliothèque android.car dans le fichier build.gradle de votre module d'application. Il s'agit d'une extension du SDK Android qui fournit des API spécifiques à Android Automotive OS.

android {
    ...
    useLibrary("android.car")
}

Utilisez CarUxRestrictionsManager pour lire l'état de la restriction d'expérience utilisateur. N'essayez pas de déterminer l'état de la restriction d'expérience utilisateur à partir d'un autre état matériel, tel que la vitesse ou le rapport, car les restrictions d'expérience utilisateur peuvent varier d'un écran à l'autre dans un véhicule.

val car = Car.createCar(context)
val carUxRestrictionsManager =
    car.getCarManager(Car.CAR_UX_RESTRICTION_SERVICE) as CarUxRestrictionsManager

// You can either read the state directly ...
val currentUxRestrictions = carUxRestrictionsManager.currentUxRestrictions

// or listen to state changes
carUxRestrictionsManager.registerListener { carUxRestrictions: CarUxRestrictions -> ...}

// Don't forget to teardown and release resources when they're no longer needed
carUxRestrictionsManager.unregisterListener()
car.disconnect()

Conseil :Vous pouvez utiliser une vérification d'exécution pour prendre en charge à la fois Android Automotive OS et d'autres facteurs de forme avec le même code en n'appelant Car.createCar() que sur les appareils Android Automotive OS.

La seule valeur fournie par CarUxRestrictions que votre application doit référencer est la valeur renvoyée par isRequiresDistractionOptimization(). Les autres valeurs ne sont pertinentes que pour les activités marquées comme optimisées pour les distractions.

Tester l'implémentation

Vérifiez que votre application répond aux exigences de distraction du conducteur en procédant comme suit:

1. Installez votre application sur une image système sans le Google Play Store ni le mode de compatibilité.
2. Lorsque la grille d'applications du lanceur est ouverte, simulez la conduite et vérifiez que votre application ne peut pas être ouverte.
3. Arrêtez de simuler la conduite, ouvrez votre application sur un écran de lecture et lancez la lecture.
4. Simulez à nouveau la conduite et vérifiez que la lecture est mise en pause.
   1. Si votre application est compatible avec l'intégration à MediaSession, utilisez adb shell cmd media_session dispatch play et vérifiez que la lecture ne reprend pas.

Attention :Pour vérifier que votre application met en pause la lecture sur tous les appareils, et pas seulement sur ceux qui sont compatibles avec le mode de compatibilité, assurez-vous de réaliser des tests sur un appareil qui n'inclut pas le mode de compatibilité. Pour savoir quels émulateurs incluent ou non le mode de compatibilité, consultez la section Effectuer des tests avec l'émulateur d'Android Automotive OS.

Optimiser votre application pour Android Automotive OS

Pour offrir à vos utilisateurs la meilleure expérience possible dans les voitures, tenez compte des points suivants lorsque vous créez votre application pour Android Automotive OS:

Utiliser des encarts de fenêtre et des encoches

Comme c'est le cas pour d'autres facteurs de forme, Android Automotive OS inclut des éléments de l'interface utilisateur du système, tels que des barres d'état et de navigation, ainsi que la prise en charge des écrans non rectangulaires.

Par défaut, les applications s'affichent dans une zone qui ne chevauche pas les barres système ni les encoches. Toutefois, vous pourriez souhaiter que votre application masque les barres système, affiche du contenu derrière elles ou dans une encoche, comme décrit dans la section Afficher votre application dans les encarts. Si votre application se comporte de l'une de ces manières, reportez-vous aux sous-sections suivantes pour découvrir comment la faire fonctionner correctement sur l'ensemble des appareils Android Automotive OS.

Attention : Les barres de navigation peuvent inclure ou non une affordance de retour sur Android Automotive OS, et la navigation par gestes n'est pas prise en charge. Les consignes relatives à la qualité des applications pour voitures AN-1 exigent que les utilisateurs puissent naviguer dans votre application sans affordance de retour système ou matérielle.

Barres système, mode immersif et rendu de bord à bord

Dans les voitures, contrairement à d'autres facteurs de forme, les barres système peuvent être dimensionnées et positionnées de différentes manières. Par exemple, les barres de navigation peuvent être positionnées à gauche, à droite ou en bas de l'écran. Même si une barre d'état s'affiche en haut et une barre de navigation en bas (comme c'est le cas pour la plupart des téléphones et des tablettes), la taille de ces éléments sera probablement beaucoup plus grande dans les voitures.

De plus, Android Automotive OS permet aux OEM de choisir si les applications peuvent afficher ou masquer les barres système pour passer en mode immersif et quitter ce même mode. Par exemple, en empêchant les applications de masquer les barres système, les OEM peuvent s'assurer que les commandes du véhicule, telles que la climatisation, sont toujours accessibles sur l'écran. Si l'OEM n'a pas autorisé les applications à contrôler les barres système, rien ne se passe lorsqu'une application appelle les API WindowInsetsController (ou WindowInsetsControllerCompat ) permettant d'afficher ou de masquer les barres système. Reportez-vous à la documentation relative aux fonctions show et hide pour apprendre à détecter si votre application a pu modifier les encarts.

De même, les OEM décident si les applications peuvent ou non définir la couleur et la translucidité des barres système afin de s'assurer que celles-ci (et tous les éléments qu'elles contiennent) sont clairement visibles à tout moment. Si votre application s'affiche de bord à bord, vérifiez que seul le contenu non essentiel apparaît derrière les barres système. Si l'OEM de l'appareil n'autorise pas l'application à définir la couleur ou la translucidité des barres, ce contenu peut être invisible.

<!-- Depending on OEM configuration, these style declarations
     (and the corresponding runtime calls) may be ignored -->
<style name="...">
  <item name="android:statusBarColor">...</item>
  <item name="android:navigationBarColor">...</item>
  <item name="android:windowTranslucentStatus">...</item>
  <item name="android:windowTranslucentNavigation">...</status>
</style>

Si votre application s'affiche de bord à bord, ne laissez pas la taille, le nombre, le type ou l'emplacement des barres système au hasard. Utilisez plutôt les API d'encarts de fenêtre afin de mettre en page le contenu de votre application en fonction de l'emplacement des barres système. Pour en savoir plus sur l'utilisation de ces API, consultez la section Afficher le contenu de bord à bord dans votre application. Les valeurs de marge intérieure codées en dur ne sont jamais recommandées pour aucun facteur de forme, mais dans les voitures, elles ne fonctionneront probablement pas pour maintenir le contenu dans la zone de sécurité.

Conseil :Pour savoir comment tester la façon dont votre application gère ces différentes configurations, consultez Tester à l'aide de l'émulateur configurable.

S'adapter aux écrans de forme non conventionnelle

En plus des écrans rectangulaires, certains véhicules peuvent disposer d'écrans de forme non conventionnelle, comme illustré dans la Figure 1:

Figure 1 : un appareil Android Automotive OS doté d'un écran incurvé sur le côté droit. La zone verte représente le rectangle qui, à coup sûr, ne chevauchera pas le cadre de délimitation de l'encoche de la courbe.

Si votre application ne s'affiche pas de bord à bord, aucune action n'est requise de votre part pour que celle-ci s'affiche dans la zone de sécurité.

Si votre application s'affiche de bord à bord, vous pouvez choisir son comportement par rapport aux encoches. Pour ce faire, vous pouvez utiliser des ressources en définissant l'attribut android:windowLayoutInDisplayCutoutMode pour le thème de votre application ou au moment de l'exécution en modifiant le l'attribut layoutInDisplayCutoutMode de la fenêtre.

Étant donné que les types d'encoches présents sur les appareils Android Automotive OS sont différents de ceux présents sur les appareils mobiles, n'utilisez pas LAYOUT_IN_DISPLAY_CUTOUT_MODE_DEFAULT ni LAYOUT_IN_DISPLAY_CUTOUT_MODE_SHORT_EDGES, dont le comportement est optimisé pour les encoches sur les appareils mobiles. Utilisez plutôt LAYOUT_IN_DISPLAY_CUTOUT_MODE_NEVER ou LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS pour éviter systématiquement l'encoche ou y entrer. Au moment de faire votre choix, consultez la section Prise en charge des encoches pour en savoir plus sur les API relatives aux encoches.

Si votre application s'affiche dans la zone d'encoche et que vous souhaitez qu'Android Automotive OS se comporte différemment de la version mobile, consultez la section Désactiver des fonctionnalités pour savoir si votre application se comporte de cette manière au moment de son exécution. Si votre application se comporte de cette manière à l'aide de fichiers de ressources, consultez d'autres ressources.

Conseil :Pour savoir comment tester la façon dont votre application gère les encoches d'affichage, consultez la section Effectuer des tests avec l'émulateur configurable.

Désactiver des fonctionnalités

Si vous publiez une application mobile existante sur Android Automotive OS, certaines fonctionnalités peuvent ne pas être pertinentes ou disponibles. Par exemple, les voitures ne permettent généralement pas d'accéder aux appareils photo. De plus, seul un sous-ensemble de services Google Play est disponible sur Android Automotive OS. Pour en savoir plus, consultez Services Google Play pour voitures.

Vous pouvez utiliser l'API PackageManager.hasSystemFeature pour détecter si l'application s'exécute sur Android Automotive OS en recherchant la fonctionnalité FEATURE_AUTOMOTIVE, comme illustré dans l'exemple suivant :

Kotlin

val packageManager: PackageManager = ... // Get a PackageManager from a Context
val isCar = packageManager.hasSystemFeature(PackageManager.FEATURE_AUTOMOTIVE)
if (isCar) {
  // Enable or disable a given feature
}

Java

PackageManager packageManager = ... // Get a PackageManager from a Context
boolean isCar = packageManager.hasSystemFeature(PackageManager.FEATURE_AUTOMOTIVE)
if (isCar) {
  // Enable or disable a given feature
}

Si votre application comporte également un composant Android Auto, vous pouvez utiliser l'API CarConnection de la bibliothèque d'applications Android for Cars pour détecter si l'application s'exécute sur Android Automotive OS, sur Android Auto, ou si elle n'est pas connectée du tout à une voiture.

En ce qui concerne la fonctionnalité Picture-in-picture (PIP), suivez les bonnes pratiques pour vérifier si elle est disponible et agissez en conséquence.

Gérer les situations hors connexion

Bien que les voitures soient de plus en plus connectées à Internet, il est préférable que les applications puissent fonctionner sans connexion Internet, comme dans les cas suivants :

• Les utilisateurs peuvent désactiver les données mobiles proposées dans le cadre d'un abonnement du constructeur automobile.
• L'accès aux données mobiles peut être limité dans certaines régions.
• Les voitures dotées de signaux Wi-Fi peuvent ne pas être à portée du signal Wi-Fi, ou un OEM peut désactiver le Wi-Fi au profit d'un réseau mobile.

Préparez-vous à gérer ces scénarios dans votre application en dégradant de manière élégante les fonctionnalités qui dépendent de l'accès à Internet, par exemple en proposant du contenu hors connexion. Pour en savoir plus, consultez les bonnes pratiques pour optimiser la mise en réseau.

Utiliser d'autres ressources

Pour vous aider à adapter votre application pour les voitures, vous pouvez utiliser le qualificateur de ressource car afin de fournir d'autres ressources lorsque vous l'exécutez sur un véhicule Android Automotive OS. Par exemple, si vous utilisez des ressources de dimension pour stocker des valeurs de marge intérieure, vous pouvez recourir à une valeur plus élevée pour l'ensemble de ressources car afin d'augmenter la taille des cibles tactiles.

Important : Le qualificateur de ressource car est mis en correspondance lorsque le mode renvoyé par UiModeManager.getCurrentModeType() est UI_MODE_TYPE_CAR. Cela est toujours le cas sur Android Automotive OS, mais cela peut parfois avoir lieu sur d'autres appareils (par exemple, lorsqu'une application appelle UiModeManager.enableCarMode() elle-même).