J'ai effectué quelques développements d'application android sous eclipse. Néamoins, eclipse n'est plus à jour et le plugin dédié aux développements d'applications android n'est plus supporté/maintenu depuis 2013.

J'ai réussi, avec beaucoup de difficulté (2020/03), à développer ma dernière appli, aerobic, via eclipse et maven. Néamoins, quand j'ai voulu déployer sur le playstore, j'ai été confronté à plusieurs obstacles :

• difficulté d'importation de projet effecuté avec l'éditeur Android Studio :

AS est l'éditeur qui est dorénavant l'incontournable pour tous les dev android. Eclipse est 'has been'. En effet, en essayant d'importer quelques projets gradle effectué sous AS, j'ai énormément galéré pour réussir à les structurer correctement pour qu'ils soient correctement compris par eclipse, à les rendre compilables. Plus d'information dans le fichier word, à la racine de mon projet aerobic (sous gitlab).

• se mettre en mode release : il faut imposer l'attribut android:debuggable=“false” dans la balise <application> du fichier AndroidManifest.xml, pour pouvoir lancer un build maven qui produira un apk en mode release.
• signer l'application : eclipse propose un utilitaire ; Click droit sur projet > Android Tools > Export Signed Application Package ; cet utilitaire permet de créer un keystore et un alias dans ce keystore qui contiendra la clé privée pour signer cette application.
• optimiser l'apk : j'ai du ajouter et utiliser un .bat qui effectue ça :

<AndroidSdk>\build-tools\22.0.1\zipalign.exe -f -v 4 ./external/signed/aerobic.trainer.signed.apk ./external/signed/aerobic.trainer.signed.zipaligned.apk

Je n'ai jamais réussi, à partir d'eclipse à produire un apk que je puisse pousser sur le playstore.

• livrer l'application sous le format Android App Bundle : Google préconise fortement de livrer des fichier au format Android App Bundle ( définiton plus bas )

C'est le kit de développement d'Android ; c'est un ensemble d'outils et de librairies de dev. Il inclut :

• un deboggueur (dossier <Android-SDK-Install>/emulator)
• des outils de build (dossiers <Android-SDK-Install>/build-tools/<Android_Version>) : AAPT (Android Asset Packaging Tool), zipalign, <archi>-linux-android-ld, lld, apksigner, …
• les images systemes (dossiers <Android-SDK-Install>/system-images/<Android_Version>) : les fichiers img qui correspondent aux partitions d'origine à copier pour créer un AVD.
• les librairies (dossiers <Android-SDK-Install>/platforms/<Android_Version>) : contient notamment le fichier android.jar, qui contient :
  1. toutes les classes java fournies par une version d'android (View, Activity, BaseAdapter, ListView, …)
  2. des fichiers assets
  3. des fichiers de resources (res)
  4. Bref, ca devrait plutôt être un fichier AAR, vu que c'est en gros la dépendance de base de tout projet android.

• un émulateur, basé sur QEMU (machine virtuelle, comme Virtual Box, KVM, …)
• un ensemble d'outils annexe permettant la communication avec des devices android (dossier <Android-SDK-Install>/platforms-tools/<Android_Version>) ; on y retrouve :
  1. ADB (Android Debug Bridge)
  2. Fastboot
  3. mke2fs

1. sqlite3

C'est sur ce kit que sont pluggé les IDE de dev android, comme eclipse en premier lieu, puis Android Studio maintenant.

Remarque : sur mon pc, Eclipse et Android Studio utilisent le même Android SDK !! Et les mêmes AVD, heureusement

Voir plus bas ce qu'est un AVD

Référence : https://fr.wikipedia.org/wiki/Android_SDK

Il permet de récupérer en local ou supprimer les librairies android, et qui seront utilisées builder les projets android ou pour lancer des AVD. Plus précisément, il s'agit des :

• les images systèmes (dans différentes architectures)
• les SDK platforms
• les outils de builds

….

Les AVD pour Android Vitual Device, simulent un téléphone, une tablette, ou autre dispositif réel.

L'AVD manager permet de créer des AVD sur notre PC. Chaque AVD dispose est en gros un n-uplet définissant :

• Version Android
• RAM
• CPU
• Taille Internal Storage
• Taille Ecran
• Densité
• Capteurs présents
• Touches tactiles présentes
• Et des images systèmes chargées par QEMU et permettant de booter le device !!!

Chaque exécution d'une application android (APK) se fait en choisissant l'AVD. QEMU lance alors l'AVD choisi, puis l'APK du projet (buildé auparavant), est déployé sur l'AVD, puis exécuté. Toute ces étapes se font de manière automatique, il suffit de choisir un AVD existant, puis de lancer l'exécution.

On peut éxécuter l'APK en mode deboggage, ce qui permet de mettre des points d'arrêt dans notre code source.

….….

Par défaut, chaque création d'AVD est couplé à la création d'un dossier <UserHomeFolder>\.android\avd\<AndroidVirtualDevice's name>.avd

• userdata-qemu.img : (Internal Storage) image sera montée en /data ; elle contiendra les données des applications et de l'utilisateur. Elle est construite à la base à partir de l'image userdata.img. Elle sera recopiée depuis userdata.img si on coche –wipe-data dans les options de lancement de l'AVD
• userdata.img : image d'origine. Elle est créé lors dela première instanciation de l'AVD. Elle est sans doute copiée de puis <AndroidSdk Install Dir>\system-images\android-22\google_apis\x86_64
• cache.img :
• sdcard.img : carte sd ; elle est optionnelle (removable media) ; d'ailleurs, on peut la retirer dans les parametres de l'AVD en démontant la sdcard
• config.ini : existence/émulation de (type d'architecture, encodage, microphone, camera avant/arriere, gps, accelerometre, résolution écran, densité dpi, quantité de RAM, disk.dataPartition.size=100M, sdcard et taille)
• hardware-qemu.ini : ressemble à config.ini. Il me semble que ce fichier est écrit suite à la première instanciation de l'AVD ; on retrouve les référence aux fichiers .img précédents.

Remarques :

• ramdisk.img : une image qui contient des fichiers pour booter le système.
• system.img : image qui sera monté en / , et qui contient tout les binaires de base.
• cache : The cache partition stores temporary data and is optional if a device uses A/B updates. The cache partition doesn't need to be writable from the bootloader, only erasable. The size depends on the d

An Android library is structurally the same as an Android app module. It can include everything needed to build an app, including source code, resource files, and an Android manifest.

However, instead of compiling into an APK that runs on a device, an Android library compiles into an Android Archive (AAR) file that you can use as a dependency for an Android app module.

Unlike JAR files, AAR files can contain Android resources and a manifest file, which allows you to bundle in shared resources like layouts and drawables in addition to Java classes and methods.

Plugin de base qu'utilise eclipse pour la génération de projet Android sous Eclipse

La plupart des projet android que j'ai faite sous eclipse n'utilisaient que ADT.

J'ai, sur mon dernier projet (aerobic, sous gitlab ), voulu utiliser maven pour tirer des dépendances disponibles sur les repository maven(/gradle). Mais comme expliqué dans la section Introduction, j'ai galéré, et en voici sans doute les raisons :

Android Development Toolkit (ADT) : is a plugin for the Eclipse IDE that is designed to give you a powerful, integrated environment in which to build Android applications. Its package is com.android.ide.eclipse

Last plugin version seems to be ADT 9.0.0, release in 2011. So it seems that ADT is no more supported : see https://developer.android.com/studio/tools/sdk/eclipse-adt

This last web page tells to developers :

1. the Eclipse ADT plugin has many known bugs and potential security bugs that will not be fixed.
2. to migrate ASAP to Android Studio (another IDE).

Android for Maven Eclipse connector is an Maven Eclipse (m2e) plug-in that adds maven support for Android Developer Tools (ADT) and the Maven Android Plugin

Ce connector permettait de tirer les dépendances.

Par contre, il fallait que ces dépendances soient des jar : Eclipse n'arrivait pas à utiliser/exploiter les dépendances de type aar, qu'il téléchargeait : il les voyait comme des jars ; l'artifact pullé par maven fournissait un jar. Et quant on essayait de forcer le type de dépendance en aar, il téléchargeait bien l'aar, mais ne savait comment l'expoiter …

Ceci fut un gros obstacles qui m'a fait perdre beaucoup de temps.

• first, we have to create a default.properties or project.properties file at each android project root to be able to add “android project nature”.

• second, and I'm stuck on this : “cannot be resolved to a type” eclipse errors for all projects which have AAR type dependencies.

• thirst, we have to make symbolic link for AndroidManifest.xml and res folder to get them accessible from each android project root folder.

• fourth, Android Studio projects uses gradle. When importing these gradle projects in eclipse, it fails to correctly detect subproject. We have to know a little how project and its subproject are structured with gradle, in order to rearange the imported projects to make them work. ⇒ We have to know a little gradle.

Reference : https://stackoverflow.com/questions/60960336/does-eclipse-photon-has-problems-dealing-with-aar-eclipse-generally-how-to-d?noredirect=1#comment107859476_60960336

Il permet, indépendamment d'eclipse et d'ADT, de pouvoir builder les projets Android grace au fichier de build maven pom.xml, comme pour un projet java classique. Ce plugin est (était) beaucoup utilisé par les développeur :

Il est toujours disponible sur mavencentral : com.simpligility.maven.plugins:android-maven-plugin:4.1.1

Voir mon projet eclipse aerobic pour plus de précision.

Ce qu'il y a de dingue, c'est que le build maven se passait très bien, même avec des dépendances AAR utilisées par le code source, mais Eclipse était complètement incapable de bien exploiter les dépendances AAR, donc ne compilait pas. =⇒ Il a fallu que :

1. je récupère le code source du fichier aar (apng)
2. je tente et que je réussisse à le réorganiser sous eclipse, pour pouvoir le lire
3. que je récupère les dépendances les plus importantes, qui heureusement étaient des jars)
4. que je récupère les sources du projet qui m'intéresse, et que je les copie dans mon projet, en des adaptant (noms de package).

Bref

⇒ Il est quasiment certain que tout ceci aie été beaucoup plus rapide en utilisant Android Studio, qui lui comprend et exploite parfaitement les AAR (librairies android).

Tout se passe bien à partir du moment où on maitrise l'utilisation du gestionnaire de build gradle.

• Basé sur Intellij, donc plus rapide qu'eclipse …

• Android Studio dispose d'un 'Device File Explorer' qui permet de gérer les fichiers des AVD en cours d'exécution.

• Dans AS, la sortie standard et erreur de QEMU se trouve dans l'onglet Debug ou Run (dans Eclipse, c'était dans l'onglet Console)

• Dans AS, les logs applicatifs se trouvent dans l'onglet Logcat

http://www.nicolasaguenot.com/nicoandco/index.php?post/2011/11/30/Les-diff%C3%A9rentes-unit%C3%A9s-de-mesures-Android https://blog.mindorks.com/understanding-density-independent-pixel-sp-dp-dip-in-android

Resolution : dpi = Dots (count) Per Inchs

^ Density Bucket ^ Screen Density ^

⇒ For each screen, defined by its WidthPixel and its WidthInch : its dpi is WidthPixel / WidthInch, hence :

nbDp = WidthPixel / fd = Pixels / (dpi / 160) = Pixels * 160 / dpi = Pixels * 160 / ( WidthPixel / WidthInch ) = 160 * WidthInch

nbDp ←→ WidthPixel =⇒ 1 dp ←→ WidthPixel / nbDp =⇒ 1 dp ←→ WidthPixel / (WidthPixel / fd) = fd real pixels

• Les commandes pour échanger des fichiers avec l'AVD ou piloter l'AVD sont :

adb devices

adb push "<host path to file to upload to avd>" /storage/sdcard/aerobic

adb shell

adb shell permet d'ouvrir une session shell (en root) sur le device émulé.

 adb install <Path/to/uneAppli.apk>

• Il n'y pas d'explorateur de fichier sur l'AVD quand on lance l'AVD. Android Studio résoud ce problème en en fournissant un (voir au dessus) ; pas eclipse.

Dans tous les cas, pour en installer un sur le device, (comme TotalCommander), démarrer votre AVD, puis exécuter la commande suivante:

adb install <Path/to/TotalCommander.apk>

Ce qu'affiche Android Studio (ou eclipse) quand on debogue, c'est fait avec la commande logcat :

cd <android-sdk-install-folder>/platform-tools/
./adb.exe logcat

Il suffit donc de connecter son appareil android sur le pc, de s'assurer que le device est bien connu d'adb, puis d'exécuter la commande ci-dessus, puis de réexécuter l'application.

Dans android studio, si un appareil réel est connecté au PC en adb (adb devices le référence bien), alors il est visible dans la liste des Devices disponibles pour l'exécution. Testé avec succès avec mon Xiami Redmi 8. Lors de l'exécution sur AS, l'appli est buildé, puis installée sur le device (si elle c'est une nouvelle version), puis elle est lancée en mode debug.

<UserHomeDir>\.gradle\caches\modules-2\files-2.1\com.android.support\appcompat-v7\25.3.1\fb12db83b0687efd651695c5f6d03f0d293238f5

./gradlew <yourmodule>:dependencies

Additionally, if you want to check if something is compile, testCompile, androidTestCompile, implementation, testImplementation, or androidTestImplementation dependency as well, you can do so with the configuration parameter like this:

./gradlew app:dependencies --configuration implementation
./gradlew app:dependencies --configuration testImplementation 
./gradlew app:dependencies --configuration androidTestImplementation

Voir : http://supertos.free.fr/supertos.php?page=1263, http://supertos.free.fr/supertos.php?page=1263

• Classes du framework android : SoundPool et MediaPlayer
• On peut charger des fichiers depuis un assets, une resource, ou directement depuis la carte sd (voir mon projet aerobic pour android studio)

Il faut se créer un compte développeur et s'inscrire (cout = 25euros, mais pour la vie)

Après toute les étapes se passe sur une IHM web, nommée la Google Play Console, qui permet d'accéder à toutes ses applications android developpées et poussées sur le playstore. On sélectionne alors l'application que l'on veut faire évoluer (nouvelle release), puis un menu à gauche permet de suivre les étapes jusqu'au déploiement de la nouvelle release.

• Fiche Play Store
• Tarification (ou gratuité) et disponibilité
• Gestion des releases
• Classification de contenu

A savoir, qu'il faut remplir un ensemble de ces étapes avant de pouvoir demander le déploiment d'une release sur le playstore.

Enfin, cette 'console' web a aussi mis en place des processus de tests de chaque nouvelle release, (qu'on peut ignorer, plutôt prévue pour des équipes de travail), et une gestion de chaque release avec un ensemble d'artifacts livrés (pas forcément qu'un seul APK ou AAB …

Remarque : Mon compte google pour le développement d'applications android est : and.xavier.marquis@gmail.com

Il est nécessaire, pour garantir l'authenticité de votre identité de signer votre APK ou AAB. Un How-To est disponible ici : https://developer.android.com/studio/publish/app-signing#sign_release

J'ai stocké dans mon M (administration_xxx.tc) :

• keystore.android is a java keystore that will contains my private keys to sign my next developed apk. It actually only contains 'aerobic.trainer' alias (which contains private key).

• private_key.pepk is a binary file that we can give to google play console to defer apk signature process to google.

This file has been generated by Android Studio ; it is generated when checking an option when building and generating a signed AAB (Android App Bundle) or APK.

Android App Bundle is a publishing format that :

1. includes all your app’s compiled code and resources
2. defers APK generation and signing to Google Play.

Google Play uses your app bundle to generate and serve optimized APKs for each device configuration, so only the code and resources that are needed for a specific device are downloaded to run your app. You no longer have to build, sign, and manage multiple APKs to optimize support for different devices, and users get smaller, more-optimized downloads.