Le Google Assistant pour les développeurs Android – PART 1

Tout le monde connaît l’Assistant Google, présent sur la plupart des appareils Android mais aussi iPhone. Au même titre que “Dis Siri”, le fameux “Ok Google” est entré dans le langage courant. Nous l’avons probablement tous déjà utilisé au moins une fois ne serait-ce que pour le tester.

Cependant, l’étendue de son champ d’action ainsi que de son implémentation dans une application semblent rester assez mystérieux pour nous autres développeurs. Du moins, c’était mon cas jusqu’à récemment.

Est-ce une fonctionnalité mobile uniquement ? Peut-on l’utiliser nous-mêmes dans notre application ? Quelles-sont les possibilités d’interactions ?

Nous répondrons à ces questions et à d’autres dans cet article, puis nous nous pencherons uniquement sur la partie qui nous intéresse ici : la mise en place via l’assistant d’une interaction avec notre application sur Android.

L’Assistant Google est une interface conversationnelle avec laquelle on interagit principalement par la voix. Bien que populaire sur smartphone, il est présent sur plus d’un milliard d’appareils différents tels que les enceintes, les écrans intelligents, les voitures, les TV ainsi que les montres connectées. Son but premier est d’améliorer la découverte ainsi que l’interaction avec les applications mais aussi avec les sites internet.

Il s’utilise par exemple par un appuie long sur le bouton “Home” de son smartphone ou tout simplement en disant “Ok Google” ou “Hey Google”.

Il se base sur le Natural Language Processing (NLP) et l’intelligence artificielle afin de transformer un input vocal en requête interprétable par un programme informatique. Pour faire simple, lorsque la requête d’un utilisateur correspond à une grammaire prédéfinie, l’Assistant extrait les paramètres de la requête dans des entités schema.org et génère des URL Android Deep Link en utilisant le mapping donné dans le fichier actions.xml.

Il existe déjà beaucoup d’interactions que nous connaissons déjà tous telles que le lancement d’une vidéo sur Youtube ou d’une musique sur Spotify, l’affichage d’un itinéraire sur Google Maps, le déclenchement d’un timer dans notre application Horloge ou encore le simple lancement d’une recherche internet.

Mais les possibilités sont beaucoup plus vastes.

Mais alors, puis-je, moi, développeur Android, développer mes propres interactions sur l’Assistant ? La réponse est oui, mais dans une certaine mesure.

Google propose aux développeurs la possibilité de créer leurs propres interactions. Cela se présente sous la forme d’actions appelées App Actions et qui sont des intents portant une requête et permettant de faire le lien avec notre application.

Plusieurs possibilités sont offertes quant à la mise en place de ces actions. Nous nous intéresserons aux deux possibilités pour le développement sur Android en lien avec notre application :

• La partie “Solutions” avec les actions prévues par Google pour nous simplifier la tâche. Ces actions sont représentées sous la forme de built-in intents et nous permettront d’avoir des interactions prêtes en un rien de temps. Cependant, ces actions ne permettent pas les échanges avec l’Assistant à la manière d’une conversation. Voyez-les plutôt comme des déclencheurs, de simples ordres. Aussi, elles ne permettent que le lancement de fonctionnalités dans nos applications avec un minimum de retour graphique dans l’Assistant.

• La partie “Custom Conversations”, beaucoup plus intéressante du point de vue de développeur. Ces actions sont construites à la main, notamment à travers DialogFlow et permettent ici de créer de « réelles » conversations avec l’Assistant. Nous pourrons notamment créer des interactions visuelles qui ne nécessiteront jamais le lancement de notre application.

Nous nous pencherons dans un premier temps sur la partie “Solutions” afin de comprendre le principe d’une App Action simple à travers sa mise en place dans une application. Nous attaquerons la partie “Custom Conversations” dans un prochain article.

Avant de nous lancer dans cette partie, il est important de préciser qu’à l’heure de la rédaction de cet article, la feature App Actions est encore en developer preview. Nous pourrons donc bel et bien développer et tester notre action mais nous ne pourrons pas la déclencher nous-mêmes directement depuis l’Assistant. Mais pas d’inquiétude, nous pourrons quand même visualiser le résultat de notre travail dans ce dernier.

Nous allons ici créer ensemble une application simple à laquelle nous accéderons par l’intermédiaire de l’un des built-in intents proposés par Google. Le but sera de lancer une feature dans notre application en spécifiant son nom.

Elle se présentera sous la forme suivante :

• une activity principale servant de hub et permettant l’accès à 3 features différentes à travers 3 boutons
• une activity par feature affichant un titre, un sous titre et une image

Enfin, nous améliorerons un peu l’interaction dans l’Assistant en affichant une Slice portant les informations de la feature demandée.

C’est parti.

Pour pouvoir intégrer une App Action dans notre application, il va falloir préparer le terrain. Pour cela, il est important de savoir que les App Actions ne sont disponibles qu’à partir d’Android 5 (API niveau 21).
Aussi, il sera dans un premier temps nécessaire de mettre en place des deep links au sein de notre application pour permettre à Google de faire le lien de nos actions vers nos activities. Nous ne couvrirons pas cette partie ici, mais il est très simple et rapide de générer ces deep links à travers l’App Links Assistant, accessible depuis l’onglet « Tools » d’Android Studio.
Enfin, il est indispensable d’avoir notre application uploadée sur la Google Play Console (juste un brouillon suffit) pour pouvoir tester nos actions, ainsi qu’être connecté au même compte Google sur la Console, dans Android Studio ainsi que dans le device / l’émulateur.

Pour commencer, créons notre application basique. Pour ne pas noyer cet article sous un code simple et sans intérêt particulier, le code est à disposition sur GitHub. Vous pourrez y trouver une AppActionsActivity qui set 3 listeners sur nos 3 boutons et permettant de lancer chaque feature. On remarquera également la présence d’un intent-filter dans le manifest pour gérer les deep links.

Ajout d’une App Action

Au sein des built-in intents proposés par Google, nous pouvons trouver beaucoup d’actions génériques telles que START_EXERCISE, CREATE_TAXI_RESERVATION ou encore GET_ACCOUNT, chacune permettant l’ouverture d’une feature spécifique dans son application avec les paramètres adaptés.

Nous utiliserons ici l’action la plus générique à savoir : OPEN_APP_FEATURE.

Pour ce faire, il faut créer un nouveau package “xml” dans le répertoire “res” de notre application et y créer un nouveau fichier actions.xml. C’est ce fichier qui structurera les actions utilisées dans notre application, les différents moyens d’y accéder (deep link ou Slice) ainsi que les paramètres acceptés et / ou nécessaires.

Ajoutons donc notre action à notre fichier actions.xml :

On constate différents éléments :

Il faut maintenant référencer ce fichier dans notre AndroidManifest.xml :

Attention : il est actuellement impossible d’uploader un APK ou un AAB sur la Google Play Console avec un AndroidManifest.xml référençant un fichier actions.xml. Il suffit alors d’uploader son APK ou son AAB sans cette balise puis de l’ajouter en local pour pouvoir tester ses App Actions.

Il nous reste à gérer l’intent reçu au sein de l’application. Pour cela, nous allons créer une méthode privée dans notre AppActionsActivity, appelée dans onCreate, et dont le rôle sera de d’extraire la data de l’intent et de vérifier qu’il s’agit bien d’une intent de type Intent.ACTION_VIEW, qu’il contient bien les éventuels paramètres nécessaires et de rediriger, dans notre cas, vers la feature passée en paramètre.

Pour le besoin de cet article, nous avons fait le choix de gérer cette redirection dans la AppActionsActivity, mais nous aurions par exemple très bien pu décider de créer un deep link par feature pour ne pas avoir à gérer de redirection. Les built-in intents ne sont que des points d’entrée pré-formatés mais la gestion du comportement en résultant au sein de l’application est à la responsabilité du développeur, ce qui laisse une grande liberté.

C’est le moment de tester notre App Action. Pour cela, il suffit d’installer le plugin “App Actions Test Tool” et de le lancer depuis l’onglet “Tools” d’Android Studio. Lorsque l’on clique sur le bouton “Create Preview”, Google vérifie la présence d’une application avec le même application ID sur la Google Play Console puis génère les deep links nécessaires automatiquement.

On constate que notre App Action OPEN_APP_FEATURE a bien été configurée et qu’il ne reste plus qu’à entrer le nom de la feature que l’on veut lancer puis de cliquer sur “Run”. On voit alors l’Assistant se lancer sur notre device / émulateur et nous rediriger vers notre application puis vers la feature demandée.

A noter que si la feature demandée n’existe pas, l’application sera quand même lancée par défaut.

Afin de rendre l’interaction avec l’Assistant un peu plus visuelle, nous allons ajouter une étape supplémentaire entre la requête à l’Assistant et le lancement de notre application à travers l’implémentation des Android Slices.

Sans entrer dans les détails de la mise en place des Slices, nous allons voir les quelques configurations à mettre en place pour que celles-ci soient envoyées vers l’Assistant.

Il va nous falloir ajouter un point d’entrée dans notre fichier actions.xml :

Comme précédemment avec le point d’entrée DEEPLINK, on constate :

fullfilmentMode	la manière de réaliser cette action, ici une Slice
urlTemplate	le modèle d’URL à respecter pour réaliser notre action avec ses éventuels paramètres (celui ci doit respecter le format “content://{slice_authority}/…”, la slice authority étant déclarée dans le Manifest)
intentParameter	le nom du paramètre issu de l’URL et qui sera passé à l’intent envoyé à notre application
urlParameter	le nom du paramètre à mapper dans l’URL

 

Ainsi, lors de l’invocation par l’App Actions test tool, l’application enverra à l’Assistant une Slice contenant les informations de la feature demandée (soit un titre, un sous-titre et une image) et redirigera vers la feature demandée au clic.

Il sera également nécessaire de gérer les permission d’accès aux Slices à l’Assistant au lancement. Pour cela, il suffit de créer une classe Application afin de demander ces permission :

Dans cet article, nous avons vu en quoi consiste le Google Assistant, principalement du point de vue Android. Nous avons mis en place une petite application permettant, dans un premier temps, d’accéder à une feature spécifique de l’application puis, dans un second temps, d’afficher une Slice dans l’Assistant et d’être redirigé vers la feature affichée à l’utilisateur, lors d’un clic. Le tout très simplement, en utilisant la partie “Solutions” proposée par Google et offrant ainsi des built-in intents permettant notamment la gestion automatique des deep-links sans effort de la part du développeur.

Nous verrons la partie “Custom Conversations” dans un second article à venir dans lequel on ira voir du côté de DialogFlow.

Lors de mes recherches, j’ai rencontré quelques difficultés auxquelles je n’ai pas encore de réponses. Par exemple, j’ai dans un premier temps voulu ne faire qu’une seule FeatureActivity configurable au travers d’un extra contenant la feature demandée, mais mon activity restait toujours configurée sur la première invocation (système de cache ?). Aussi, j’ai constaté beaucoup d’instabilités de l’Assistant sur émulateur. A l’heure actuelle, je conseille de tester les App Actions directement sur son device après l’avoir configuré en locale en-US.

Il est également bon de préciser qu’il est possible, après avoir créé une App Action, de la soumettre à Google à travers un formulaire afin de pouvoir éventuellement la déployer en production.

Pour conclure, je rappellerais le message d’Elaine Batista Dias, que je remercie pour son aide, lors de sa conférence à l’édition 2019 d’Android Makers :

“Google Assistant is still new, think outside the box.”

Rendez-vous dans le prochain article.