En plus de prendre en charge les applications conçues pour la conduite, Android Automotive OS accepte des applications de navigateur, de jeux et de vidéo à utiliser à l'arrêt. Il suffit de quelques modifications mineures pour pouvoir proposer dans les voitures les mêmes applications que sur les appareils à grand écran.
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 les fichiers manifestes de votre application
Pour cibler Android Automotive OS, votre application doit comporter certaines entrées dans le fichier manifeste. Avec elles, les applications ciblant Android Automotive OS sont envoyées au Play Store avec un type de version Automotive OS distinct. Elles 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 la section Distribuer des applications Android pour voitures.
Fonctionnalités requises pour Android Automotive OS
Pour pouvoir figurer dans le Play Store destiné aux voitures, les applications conçues pour Android Automotive OS doivent inclure l'élément <uses-feature> suivant dans le fichier AndroidManifest.xml :
<manifest ...>
...
<uses-feature
android:name="android.hardware.type.automotive"
android:required="true" />
...
</manifest>
Les applis envoyées à des canaux non destinés aux voitures ne peuvent pas déclarer l'élément <uses-feature> affiché dans l'exemple de code précédent, car elles ne peuvent pas dépendre de matériel spécifique aux voitures. Par conséquent, pour proposer la même application pour des appareils automobiles et non automobiles, vous devez générer au moins deux types différents pour votre application : l'un pour les appareils automobiles et l'autre pour les appareils mobiles. Pour en savoir plus sur la création de ces types de produit, consultez les documents suivants :
Les deux types d'application peuvent partager le même nom de package, mais ils doivent utiliser des codes de version différents, car ils seront importés séparément dans le Play Store.
Au lieu d'utiliser des types distincts, vous pouvez utiliser des noms de package distincts pour les APK ou les app bundles pour mobiles et pour voitures. Pour comprendre les avantages et inconvénients propres à chaque approche, consultez la section Noms des packages dans le guide du développeur d'applications multimédias.
En plus de l'élément présenté dans l'exemple de code précédent, les applis conçues pour Android Automotive OS doivent inclure les éléments <uses-feature> suivants dans l'élément racine <manifest> :
<uses-feature
android:name="android.hardware.wifi"
android:required="false"/>
<uses-feature
android:name="android.hardware.screen.portrait"
android:required="false"/>
<uses-feature
android:name="android.hardware.screen.landscape"
android:required="false"/>
Définir explicitement ces fonctionnalités comme non requises garantit que votre appli n'entre pas en conflit avec les fonctionnalités matérielles disponibles sur les appareils Android Automotive OS.
S'assurer qu'il n'existe aucune activité optimisée contre la distraction
Pour vous assurer que votre application ne peut être utilisée qu'à l'arrêt, n'incluez pas 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"/>
Sans ces métadonnées, le système d'exploitation bloque automatiquement les activités de votre application dès que le véhicule passe en mode Voiture afin d'éviter toute distraction pour le conducteur. 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.
Entrées du 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 jeu.
Optimiser votre application pour Android Automotive OS
Pour offrir à vos utilisateurs la meilleure expérience possible, tenez compte des points suivants lorsque vous créez votre application pour Android Automotive OS.
Optimiser pour les écrans de grande taille
Les écrans des véhicules Android Automotive OS sont plus semblables en termes de taille, de résolution et de format à ceux des tablettes et des appareils pliables qu'aux téléphones. Ainsi, l'optimisation de votre application pour les grands écrans profite également aux utilisateurs dans leurs voitures.
Consultez en particulier les guides Assurer la compatibilité avec différentes tailles d'écran et Migrer votre UI vers des mises en page responsives pour savoir comment exploiter pleinement les grandes tailles d'écran, ainsi que des galeries de contenus multimédias et de jeux pour trouver l'inspiration et des conseils en matière de conception.
D'autres optimisations pour grand écran telles que la compatibilité des entrées ne sont pas aussi utiles pour Android Automotive OS, mais elles peuvent tout de même améliorer l'expérience utilisateur. Par exemple, la navigation au clavier utilise les mêmes API que la navigation par dispositif rotatif. Par conséquent, toute optimisation effectuée peut profiter aux deux facteurs de forme.
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.
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 qui, bien qu'elles ne soient jamais recommandées, permettent d'afficher le contenu dans la zone de sécurité sur d'autres appareils, ne seront pas en mesure de le faire dans les voitures.
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:
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.
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 appli 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'appli 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 zones cibles tactiles.
Distribuer votre application
Après avoir testé votre appli pour vérifier qu'elle respecte les Consignes relatives à la qualité des applis pour voitures pour sa catégorie et avoir créé une version adaptée à Android Automotive OS avec toutes les modifications nécessaires pour sa catégorie, vous pouvez la publier sur les canaux de facteur de forme correspondant à Automotive OS sur le Play Store. Pour en savoir plus sur le processus de publication, consultez Distribuer des applications Android pour voitures.
Envoyer des commentaires sur les applis à utiliser à l'arrêt
Si vous rencontrez un problème ou si vous souhaitez soumettre une demande de fonctionnalité durant le développement de votre appli à utiliser à l'arrêt pour Android Automotive OS, vous pouvez le signaler à l'aide de Google Issue Tracker. Veillez à fournir toutes les informations requises dans le modèle dédié. Avant de signaler un nouveau problème, vérifiez s'il figure déjà dans la liste des problèmes. Pour voter pour un problème et vous y abonner, cliquez sur l'étoile correspondant à ce problème dans l'outil Issue Tracker. Pour en savoir plus, consultez S'abonner à un problème.