Naviguer dans la qualité multi-appareil et publier au-delà du mobile sur Google Play

Bienvenue à tous.

Merci d'avoir participé à cette session sur la qualité des applications multi-appareils et la publication sur Google Play pour les facteurs de forme autres que les mobiles.

Je m'appelle Jan Kleinert et je suis ingénieur DevRel dans l'équipe Android for Cars.

Et je m'appelle Faustine Liao, responsable des opérations au sein de l'équipe Trust and Safety de Play.

Nous sommes ravis de vous accueillir aujourd'hui.

Pendant des années, quand on parlait de développement Android, la plupart d'entre nous pensaient uniquement aux appareils mobiles. Mais l'écosystème Android s'est étendu bien au-delà des smartphones.

Aujourd'hui, vos utilisateurs interagissent avec des applications dans leur salon sur Android TV, peut-être en covoiturage ou pendant qu'ils rechargent leur voiture sur Android Auto ou Automotive OS, à leur poignet avec Wear OS, et de plus en plus dans des espaces 3D immersifs avec Android XR.

Il s'agit d'une opportunité de croissance considérable, mais l'expansion vers ces facteurs de forme implique de prendre en compte quelques considérations marginales pour votre stratégie de publication.

Le processus global, de la création de votre application à sa publication et à sa mise en ligne sur Google Play, reste généralement le même que celui auquel vous êtes habitué pour les versions mobiles.

Créez et préparez votre application, puis créez votre fiche dans la Play Console, testez votre application, importez et envoyez votre version en production, puis attendez qu'elle soit examinée et approuvée.

Toutefois, il existe des considérations spécifiques pour la publication d'applications sur des facteurs de forme autres que les mobiles.

Aujourd'hui, nous allons vous donner un cadre clair pour vous aider à préparer un processus de publication multi-appareil plus fluide et plus prévisible.

Commençons par les bases : comment concevoir l'architecture de votre application et la packager.

Avant même d'ouvrir la Google Play Console, vous devez donc prendre une décision importante concernant l'architecture.

Créez-vous un seul app bundle unifié contenant tout ce dont vous avez besoin pour tous les facteurs de forme que vous prenez en charge, ou divisez-vous votre application en modules spécifiques à chaque facteur de forme et générez-vous des Android App Bundles (AAB) pour chacun d'eux ?

Quand je parle de modules ou de modularisation, je fais référence à un moyen de structurer votre codebase de manière à améliorer sa maintenance.

Il existe de nombreuses approches de la modularisation, mais en général, vous organisez votre codebase en parties faiblement couplées et autonomes, où chaque partie est un module.

Ainsi, même si une approche unifiée d'Android App Bundle peut sembler plus simple à gérer, nous vous recommandons l'approche modulaire.

Voici un exemple qui montre pourquoi nous recommandons cette approche modulaire.

Imaginons que vous ayez une application compatible avec les appareils mobiles et Android TV.

Si vous envoyez un seul Android App Bundle sur le canal de publication mobile standard et que votre application Android TV échoue à un contrôle, l'intégralité de la publication est interrompue.

Cela aura donc un impact sur la publication de votre application Android TV et de votre application mobile.

Même si votre application mobile ne présente pas de problème, vous devez résoudre les problèmes qui ont entraîné l'échec de l'examen d'Android TV et renvoyer votre application pour examen avant que la version ne soit disponible pour vos utilisateurs.

En revanche, les Android App Bundles modulaires pour chaque facteur de forme vous permettent de mieux contrôler vos versions et de les isoler de vos versions mobiles.

Si vous disposez de modules d'application distincts pour votre application mobile et votre application TV, vous pouvez générer des Android App Bundles distincts pour chacune d'elles.

Si un problème survient lors de l'examen de votre appli TV, seule la version de cette appli sera bloquée jusqu'à ce que vous résolviez le problème.

La version de l'application mobile sera publiée comme prévu.

Comme je l'ai déjà mentionné, il existe de nombreuses approches de la modularisation.

Voici un exemple d'approche pour modulariser une application de livres audio qui propose une expérience mobile et une expérience Android Automotive OS.

En haut, en vert, nous avons un module d'application pour chaque facteur de forme, ce qui permet de séparer les dépendances spécifiques à la plate-forme.

Ensuite, en jaune, nous avons les modules de fonctionnalité, qui correspondent à des parties isolées des fonctionnalités de l'application.

Les modules de données sont en bleu, et en bas, nous avons les modules principaux ou communs, qui sont généralement utilisés pour contenir du code que d'autres modules utilisent fréquemment.

Ensuite, dans les fichiers de paramètres Gradle de votre projet, vous pouvez inclure et configurer cette configuration Gradle multimodule pour prendre en charge ce type de modularisation.

...

rootProject.name = "MultiFormFactorApp"

// Define modules for each form factor
include(":app:automotive")
include(":app:mobile")
include(":core:network")
include(":data:books")
include(":data:reviews")
include(":feature:home")
include(":feature:player")
include(":feature:reviews")

Vous continuerez donc à utiliser le même nom de package ou ID d'application pour chaque module et bundle d'application.

Cette approche modulaire est directement liée à votre stratégie de canaux dans la Play Console.

Lorsque vous publiez, vous disposez du canal mobile standard, mais nous proposons également des canaux dédiés à des facteurs de forme spécifiques.

Pour Android TV, Android XR et Android Automotive OS, vous avez le choix.

Vous pouvez publier vos applications en même temps que les applications mobiles ou utiliser leurs canaux de facteur de forme dédiés.

Il existe toutefois deux exceptions.

Pour Wear OS, vous devez utiliser le canal Wear OS dédié.

Pour Android Auto, comme il s'agit fondamentalement d'une extension de votre application mobile projetée sur l'écran de la voiture, le seul choix possible est la version mobile standard.

Si vous gérez plusieurs pistes, la gestion des versions est essentielle.

Une approche consiste à attribuer les deux premiers chiffres de votre code de version au facteur de forme.

Par exemple, 01 pour mobile, 02 pour Wear OS, 03 pour Android Automotive OS, etc.

Nous vous recommandons généralement d'utiliser des codes de version d'au moins sept chiffres, afin que les chiffres restants puissent être utilisés pour la version de l'application.

Cela permet d'éviter les conflits de codes de version dans la Play Console.

Une fois votre application empaquetée, il est temps de la tester.

Le développement de facteurs de forme nécessite des tests approfondis. Google Play vous propose trois canaux distincts pour les effectuer avant la mise en production : les tests internes, les tests fermés et les tests ouverts.

Si vous utilisez des canaux dédiés aux facteurs de forme, vous pouvez également combiner ces canaux de test avec vos facteurs de forme, ce qui vous permet de contrôler encore plus précisément le processus.

Par exemple, vous pouvez avoir une version de test fermé pour votre application mobile sur le canal standard et une version de test fermé distincte pour votre application Android TV sur le canal dédié au facteur de forme Android TV, avec différents groupes de testeurs si vous le souhaitez.

Les tests internes sont donc un excellent point de départ.

Il vous permet de distribuer rapidement votre application à un maximum de 100 testeurs et, surtout, il ne déclenche pas d'examen Play.

Cela signifie que vous et vos testeurs pouvez installer rapidement votre application sur des appareils et valider l'expérience sur des émulateurs ou sur un téléviseur, une montre ou un autre appareil réel.

Pour les tests internes, vous recevrez une URL unique que vous pourrez partager avec les testeurs.

Une fois que vous êtes satisfait des résultats de vos tests internes, vous pouvez passer aux tests fermés et ouverts.

Vous pouvez aller au-delà des tests internes avec une version de test fermé, qui vous permet de tester les versions préliminaires de votre application auprès d'un plus grand nombre de testeurs afin d'obtenir des commentaires ciblés.

Vous pouvez gérer vos groupes de test fermé sous forme de listes d'adresses e-mail ou via Google Groupes.

Les tests ouverts, quant à eux, vous permettent d'exécuter un test auprès d'un groupe plus important sur Google Play.

Vous serez visible sur Google Play, et n'importe qui pourra rejoindre le programme de test ouvert.

Aucune invitation n'est nécessaire, et ils pourront vous envoyer des commentaires publics et privés sur l'application.

Ces canaux de tests ouverts et fermés déclenchent des examens.

C'est un avantage considérable.

Cela vous permet de tester le processus d'examen lui-même et de résoudre les éventuels problèmes bien avant le jour du lancement.

En parlant de processus d'examen, voyons un peu en quoi il consiste et pourquoi il est important.

Ces règles et consignes visent avant tout à garantir la qualité des applications.

Des applications et des jeux de qualité offrent de la valeur aux utilisateurs, sont agréables à utiliser, exploitent pleinement les appareils haut de gamme et sont conçus pour assurer la sécurité des utilisateurs.

Voyons comment vous pouvez préparer votre application pour qu'elle passe les examens le plus facilement possible.

Je pense que le meilleur point de départ est de consulter les consignes relatives à la qualité des applications, qui se concentrent sur ce qu'est une expérience utilisateur de qualité.

Nous publions des consignes de base sur la qualité des applications qui s'appliquent à toutes les applications et définissent le niveau de qualité minimal que toutes les applications doivent respecter, ainsi que des consignes adaptatives sur la qualité des applications. Elles vous aideront à vous assurer que votre application offre une expérience optimale, quels que soient le facteur de forme, la taille d'écran ou le mode d'affichage de l'appareil.

Ces deux ensembles de consignes constituent un très bon point de départ.

Nous avons également des consignes relatives à la qualité des applications spécifiques à chaque facteur de forme.

Nos examinateurs testeront vos applications sur des appareils réels et des émulateurs en fonction de ces consignes.

Il est donc très important de vous assurer que votre application les respecte.

Voici un aperçu des raisons les plus courantes pour lesquelles les applications sont refusées pour chaque facteur de forme.

Toutefois, gardez à l'esprit que cette liste n'est pas exhaustive et ne couvre pas l'ensemble des consignes relatives à la qualité des applications.

Veillez donc à consulter en détail les consignes de qualité pour chaque facteur de forme avec lequel vous travaillez afin de connaître l'ensemble des critères.

Commençons par Android TV.

En bas de ces diapositives de section, vous trouverez un lien court qui vous redirigera vers la liste complète des consignes relatives à la qualité des applications pour ce facteur de forme.

L'une des raisons les plus courantes pour lesquelles les applications Android TV sont refusées est l'absence d'une image de bannière sur l'écran d'accueil pour chaque langue prise en charge par l'application.

Vous devez donc fournir une image de 320 x 180 pixels incluant du texte localisé qui identifie votre application.

L'image de cette diapositive montre un exemple de bannière d'écran d'accueil qui respecte ces critères.

Deuxièmement, sur la plupart des téléviseurs, les utilisateurs interagissent avec l'appareil à l'aide d'une télécommande à pavé directionnel.

Il est donc essentiel de prendre en charge correctement la navigation et la sélection à l'aide du pavé directionnel.

Assurez-vous de prendre en charge au moins les commandes minimales du pavé directionnel pour éviter tout refus basé sur ces critères.

La troisième raison la plus courante de refus d'une application Android TV est l'absence du filtre d'intent CATEGORY_LEANBACK_LAUNCHER dans votre fichier manifeste Android.

<application ...>
...
<activity
    android:name="com.example.TvActivity"
    android:label="@string/app_name"
    android:theme="@style/Theme.Leanback">
    <intent-filter>
      <action android:name=
           "android.intent.action.MAIN" />
      <category android:name=
           "Android.intent.category.
            LEANBACK_LAUNCHER" />
    </intent-filter>
  </activity>
</application>

Ce filtre identifiera votre application comme étant compatible avec la télévision et permettra à Google Play de l'identifier également comme une application TV auprès des utilisateurs.

Ainsi, lorsqu'un utilisateur sélectionne votre application sur l'écran d'accueil de son téléviseur, cet intent identifie l'activité à lancer.

Assurez-vous donc de l'avoir inclus dans votre fichier manifeste.

Android XR est la prochaine étape.

Lorsque vous développez des applications pour des casques ou des lunettes XR fonctionnant sous Android XR, portez une attention particulière aux performances, au rendu et à la stabilité de vos applications.

Vous pouvez utiliser Perfetto pour profiler les performances des applications créées avec le SDK Jetpack XR afin de vous assurer que vous respectez les exigences minimales de fréquence d'images.

Si vous utilisez un moteur en temps réel comme Unity, vous pouvez utiliser les outils de profilage intégrés à ce moteur pour vous assurer que vous respectez les exigences de rendu.

Ensuite, nous avons les voitures, qui incluent Android Auto et Android Automotive OS.

Pour Android Auto et Android Automotive OS, il existe une notion de catégories, qui est un peu propre à ce facteur de forme particulier.

Seules certaines catégories d'applications peuvent être publiées pour les voitures.

Par conséquent, si vous envoyez une application dans une catégorie qui ne correspond pas à l'une de celles que nous acceptons, ou si vous envoyez une application en test ouvert ou en production pour une catégorie qui n'est qu'en version bêta, elle sera refusée.

Laissez-moi vous montrer ce que je veux dire plus en détail.

Ici, vous pouvez voir un aperçu des catégories d'applications compatibles avec les voitures pour chaque plate-forme, ainsi que leur disponibilité.

C'est-à-dire s'il est en version bêta, ouvert (ce qui signifie qu'il est en disponibilité générale) ou pas encore compatible (ce qui est indiqué ici par "Bientôt disponible").

Certaines catégories, comme les applications de navigation ou de points d'intérêt, sont en disponibilité générale. Cela signifie que n'importe qui peut publier une application de l'une de ces catégories en production pour les voitures.

Toutefois, d'autres catégories, comme les applications d'appel pour Android Auto, sont en version bêta.

Pour ces catégories, vous pouvez publier votre application sur un canal de test interne ou fermé, mais vous ne pouvez pas la publier en production, sauf si vous avez été accepté dans l'un de nos programmes d'accès anticipé pour cette catégorie.

Pour en savoir plus, consultez nos guides du développeur Android pour voitures.

Vous y trouverez des liens pour vous inscrire à ces programmes d'accès anticipé.

L'absence ou l'inexactitude des spécifications des captures d'écran Android Automotive OS est une autre raison courante de refus des applications.

Lorsque vous fournissez des captures d'écran d'Android Automotive OS, vous devez donc inclure au moins deux captures d'écran en mode portrait et au moins deux en mode paysage, aux dimensions indiquées ici.

Vous pouvez utiliser l'émulateur Android Automotive OS pour les capturer.

Il est configuré de manière à pouvoir capturer exactement la taille de capture d'écran dont vous avez besoin.

Enfin, la sécurité est primordiale pour les applications pour voitures.

Si votre application ne respecte pas nos consignes concernant la distraction du conducteur, elle sera refusée.

Par exemple, une application vidéo doit mettre en pause la lecture et ne doit pas être visible lorsque le véhicule est en mouvement.

Enfin, et surtout, nous avons Wear OS.

Les applications Wear OS peuvent donc être refusées si elles ne sont pas optimisées et formatées pour les petits écrans ronds.

Nous vous recommandons donc d'utiliser la dernière version stable de Compose pour Wear OS afin de vous assurer que le contenu ne sera pas tronqué sur les bords sur des appareils de différentes tailles, ou, par exemple, pour vous assurer que la barre de défilement s'affiche lorsqu'il y a du contenu à faire défiler.

@Composable
fun MyText() {
  Text(
    text = stringResource(R.string.compose_for_wear_os),
    modifier = Modifier.fillMaxWidth(),
    textAlign = TextAlign.Center,
    style = MaterialTheme.typography.titleLarge
  )
}

Comme pour Android Automotive OS, les applications Wear OS peuvent également être refusées si des captures d'écran Wear OS sont manquantes ou inexactes.

Voici un bon exemple de capture d'écran de la fiche Google Play Store de l'application exemple Androidify, qui répond aux exigences.

Veillez donc à envoyer au moins une capture d'écran montrant votre application en cours d'exécution sur un appareil Wear OS.

Conclusion ?

Lisez les consignes relatives à la qualité des applications pour votre facteur de forme spécifique et testez votre application avant de l'envoyer.

Nous vous donnerons également quelques conseils essentiels.

Si votre application nécessite une connexion, vous devez fournir un compte de démonstration actif et des identifiants valides dans la section "Accès aux applications" de la Play Console.

Si nos examinateurs ne peuvent pas se connecter, nous ne pourrons pas tester votre application, qui sera automatiquement refusée.

Veillez également à tenir vos promesses.

Ne vous contentez pas de captures d'écran d'appareils mobiles.

Si votre application est disponible pour Wear OS et Android TV, veillez à importer des captures d'écran de haute qualité pour ces facteurs de forme spécifiques dans la Play Console.

Enfin, soyez descriptif.

Expliquez précisément aux utilisateurs ce que fait l'application, pourquoi elle est utile et ce à quoi ils peuvent s'attendre lorsqu'ils l'installent sur chaque type d'appareil.

Pour résumer, toucher les utilisateurs presque partout où ils vont est une opportunité incroyable. En adoptant une architecture modulaire, en exploitant les tests internes pour une itération rapide, en concevant votre application conformément aux consignes relatives à la qualité des facteurs de forme et en optimisant vos fiches Play Store, vous pourrez préparer votre application à un lancement et à un processus d'examen plus fluides.

Merci beaucoup pour votre temps aujourd'hui.

Nous avons hâte de découvrir les incroyables expériences multi-appareils que vous allez proposer sur Google Play.