Introduction
Contrairement aux systèmes de programmation natifs conventionnels (par exemple, Java sur ordinateur conventionnel) qui sont destinés à être exécutés sur le même type de machine que le compilateur, AndroidStudio a comme mandat de générer des applications destinées à être exécutées sur une autre architecture (un autre type d’appareils). C’est ce que nous appelons de la compilation croisée.
Puisqu’Android utilise une architecture intermédiaire appelée JRE (pour Java RunTime Environment), la compilation croisée en Android est beaucoup simplifiée par rapport à d’autres types de compilation croisée. Nous avons tout de même la contrainte que l’application doit être exécutée sur une autre machine que la machine permettant le développement.
Afin de tester et d’exécuter nos applications Android, nous devons donc avoir une machine permettant l’exécution de ce type d’application (un appareil Android). Nous avons donc deux possibilités. Nous pouvons exécuter les applications sur des appareils Android physiques (téléphone, tablette, etc.) ou sur des machines virtuelles s’exécutant sur l’ordinateur de développement.
Les machines virtuelles Android
Comme nous l’avons indiqué plus haut, Il est possible d’utiliser des machines virtuelles afin d’exécuter des applications Android sur un ordinateur de bureau (tel que notre environnement de développement). Afin de nous aider à créer ces machines virtuelles, le SDK d’Android fournit un outil appelé « AVD Manager » (AVD pour « Android Virtual Devices »). À partir d’AndroidStudio, il est possible d’exécuter l’outil « AVD Manager » à partir du menu « Tools ».
Une fois dans l’outil « AVD Manager », afin de créer une nouvelle machine virtuelle, appuyez sur le bouton « Create Virtual Device… »
Ensuite, vous devez sélectionner les caractéristiques physiques de l’appareil à simuler. Notez que tester avec une grande variété de types d’appareil (grand écran, petit écran, multiple résolution, ratio largeur/hauteur, etc.) permet de s’assurer que l’apparence de l’application sera acceptable, peu importe sur quel appareil cette application sera utilisée. Notez également qu’une machine virtuelle avec une grande résolution est plus difficile simuler pour l’ordinateur qu’un appareil avec une petite résolution.
Vous devez maintenant choisir une image pour votre machine virtuelle. Il y a des images pour une grande quantité d’architecture physique (ABI) et pour une grande quantité d’API Android. Pour l’architecture de la machine (ABI), à moins que vous aviez une réellement bonne raison de devoir tester sur une architecture particulière (par exemple lors d’une compilation de module native), vous devriez vous limiter à « x86 » ou « x86_64 ». En ce qui concerne l’API, encore une fois, si vous voulez vous assurer que le programme s’exécutera de manière similaire, peu importe le type d’appareil utilisé par l’utilisateur, vous devriez tester l’application sur une grande quantité d’API. Vous devez également décider si vous désirez que le service Google Play soit utilisé dans la machine virtuelle.
Il est à noter ici qu’il est généralement une bonne idée de tester avec des API plus anciens ainsi que pour des appareils sans Google Play. Il est important de comprendre que certains utilisateurs ne sont pas en mesure de mettre à jour leurs appareils Android (généralement parce que le constructeur ne fournit pas ces mises à jour). De plus, certains utilisateurs ont des appareils ne possédant pas le service Google Play (parce que le constructeur ne le fournit pas ou bien pour des raisons de sécurité) et une application n’ayant pas besoin de l’API Google Play, mais qui spécifie l’API Google Play dans son Manifest donnera des messages d’erreur à l’utilisateur au démarrage de l’application. Le fait de tester sur ce type d’appareil permet donc d’éviter des problématiques d’utilisation et de viser une utilisation plus vaste de l’application.
Il vous reste maintenant à donner un nom à votre appareil. D’autres configurations peuvent être intéressantes également sur cette page (orientation de l’écran au démarrage, type de caméra, etc.), mais nous ne les couvrirons pas.
Pour démarrer une machine virtuelle, vous pouvez cliquer sur le bouton de démarrage (la flèche) dans l’outil « AVD Manager ».
Si aucune machine virtuelle n’est démarrée lorsque vous allez exécuter l’application à partir d’AndroidStudio, la machine virtuelle spécifiée dans les options de démarrage d’AndroidStudio (s’il s’agit d’une machine virtuelle) sera démarrée automatiquement.
Puisque le démarrage d’une machine virtuelle peut être très lent, il est recommandé de laisser la machine virtuelle en marche une fois l’exécution terminée si vous croyez qu’une nouvelle exécution sera à nouveau nécessaire rapidement.
Les appareils physiques
Il est également possible de tester les applications Android sur des appareils physiques. Cette méthode a certains avantages et certains inconvénients par rapport à tester avec des machines virtuelles.
L’avantage majeur de tester avec des machines physiques est la performance de l’exécution. Puisqu’une machine virtuelle est interprétée, une latence non négligeable est inévitable. Cette latence est inexistante sur une machine physique.
L’inconvénient de tester avec un appareil physique est qu’il est impossible de tester sur plusieurs types d’appareils (à moins d’avoir physiquement ces appareils). Par exemple, si vous voulez tester avec plusieurs tailles d’écran différents, plusieurs API différents, avec et sans le service Google Play, vous aurez plus de facilité avec des machines virtuelles.
En général, je recommande aux développeurs de tester avec un appareil physique lors du développement standard. Ensuite, de temps à autre (par exemple, lorsqu’un module de l’application est terminé), on peut effectuer des tests sur plusieurs machines virtuelles afin de s’assurer que le module développé se comporte de manière similaire sur chaque type de système.
Activer les options pour les concepteurs sur un appareil physique
En général, lorsqu’un appareil Android est démarré pour la première fois, les options pour les concepteurs (qui permettront à votre système Android de communiquer avec le SDK Android sur votre ordinateur) sont désactivées. Malheureusement, la méthode permettant d’activer les options pour les concepteurs peut varier entre les différents appareils. Je vais vous montrer ici la méthode pour mes appareils basés sur Android Lineage OS, mais garder en tête que la mécanique peut être différentes sur votre propre appareil. En général, une recherche sur votre moteur de recherche Web préféré devrait vous permettre de trouver la méthode qui fonctionne sur votre appareil.
Sur mes appareils, pour activer les options pour les concepteurs, vous devez vous rendre dans le menu de paramètre « À propos du Téléphone » (« About Phone ») et appuyer plusieurs fois sur le bouton « Numéro de version » (« Build number »).
—— > 
Ensuite, vous devriez avoir accès aux paramètres système « Options pour les concepteurs ».
Les options accessibles dans le menu d’options pour les concepteurs sont souvent très pointues et ne seront pas toutes présentées dans ce cours. L’option important ici est l’option permettant d’activer le débogage d’application.
Une fois cette option activée, votre appareil est prêt pour le développement. Lorsque vous connecterez un ordinateur avec AndroidStudio d’ouvert (ou avec la commande adb exécutée), vous devrez confirmer que vous souhaitez permettre à cet ordinateur de tester des applications.
Également, vous devriez maintenant voir votre appareil dans la liste des machines de tests dans AndroidStudio.
Le Logcat
Lors du débogage d’application, il peut être intéressant d’afficher certaines valeurs de l’application pour pouvoir déceler ce qui ne fonctionne pas bien. Android permet d’afficher des informations dans le Logcat et de lire ce dernier à partir de certains outils du SDK Android (dont AndroidStudio).
Il est important de savoir que le Logcat affiche les informations de toutes les applications du système Android. Il peut donc y avoir beaucoup d’information à traiter. Il est par contre possible de filtrer l’information afin d’avoir seulement les informations s’appliquant à l’application en cours de développement. Il est également possible de filtrer uniquement les informations de « Log » (informatif, erreur, attention, etc.)
Afin d’afficher une information dans le Logcat, vous pouvez utiliser l’utilitaire « Log » dans le code Java. Il y a plusieurs types d’informations qu’il est possible d’afficher dans le Logcat à partir de Log. Les voici:
- Log.d : Permets d’afficher un message de débogage dans le Logcat;
- Log.i : Permets d’afficher un message d’information dans le Logcat;
- Log.w : Permets d’afficher un message d’attention dans le Logcat;
- Log.e : Permets d’afficher un message d’erreur dans le Logcat.
Par exemple, le code suivant:
Log.d("Mon_Application", "Message de débogage");
Log.i("Mon_Application", "Message informatif");
Log.e("Mon_Application", "Message d'erreur");
Log.w("Mon_Application", "Message d'avertissement");
Donnera le résultat suivant:
Compiler en ligne de commande
Compiler et exécuter dans l’interface d’AndroidStudio est normalement assez simple. Mais il est généralement une bonne idée d’avoir une procédure ne nécessitant pas un IDE pour compiler et exécuter le programme.
Ainsi, pour compiler le projet en utilisant l’interface texte (console), il suffit de lancer la commande suivante à la racine du projet:
Sur Windows:
gradlew.bat build
Sur Unix (MacOS, Linux, etc.):
./gradlew build
Note: Si la dernière commande donne une erreur similaire à celle-ci:
bash: ./gradlew: Permission non accordée
Il est probablement nécessaire de rendre le programme exécutable avec « chmod »:
chmod +x gradlew
Une fois cette commande lancée, le APK se trouve dans le répertoire:
app/build/outputs/apk/release
Malheureusement, ce APK n’est pas signé et ne peut donc pas être installé sur un appareil par un utilisateur (autre qu’avec le programme ADB).
Signer un APK
Pour signer un APK, il est nécessaire de créer une clé. Pour créer cette clé, utiliser l’outil « Generate signed bundle/APK » dans le menu Build:
Ensuite, sélectionnez « APK » et appuyez sur « Next »:
Dans la fenêtre de fichier de clé, appuyer sur « Create new… ».
La fenêtre qui s’ouvre servira à générer la clé. Entrez des informations pour créer cette clé. Placer le fichier de clé dans le répertoire « app » du projet. Dans mon exemple, mon fichier s’appellera « keystore.jks ».
Ensuite, inscrivez les mots de passe ainsi que les informations sur la clé. Ne pas mettre d’information confidentielle si vous décidez de publier cette clé avec votre application. Dans mon exemple, les mots de passe sont « motdepasse », le nom de la clé est « apk_key » et le « issuer » est « APK Key ».
Enfin, ajouter le code suivant dans la clause « android » à l’intérieur du build.gradle du répertoire app:
signingConfigs {
release {
storeFile file("keystore.jks")
storePassword "motdepasse"
keyAlias "apk_key"
keyPassword "motdepasse"
}
}
buildTypes {
release {
signingConfig signingConfigs.release
}
}
Ensuite, si vous compilez avec « gradlew », une version signée du APK sera créée. Cette version peut être installée sur un appareil.
Auteur: Louis Marchand
Sauf pour les sections spécifiées autrement, ce travail est sous licence Creative Commons Attribution 4.0 International.