Vous'avez raison lorsque vous'supposez que les applications Android sont écrites en langage Java, mais même cela'n'est pas une déclaration complète, car elle se compose de quelques autres parties.
Donc, sur le bureau, cela se passe comme suit:
- Vous écrivez du code Java. Des trucs standard, écrivez une méthode principale (ou plus), sélectionnez la classe Main, choisissez la version, vous avez toutes les bibliothèques standard à votre disposition, etc.
- Construisez-le en utilisant Ant, Maven ou Gradle (pour ne citer que les plus populaires) et emballez-le dans un .jar qui contient un manifeste (métadonnées) et des fichiers .class, avec éventuellement quelques autres ressources
- Distribuez le fichier .jar que vous venez de construire à d'autres
- Les autres téléchargent ce fichier, et le lancent en utilisant la machine virtuelle Java. Si la version de la JVM est inférieure au code pour lequel vous l'avez écrite (vous vous souvenez de la première étape ?), elle't juste afficher une erreur
Android, de son côté, est un peu plus complexe :
- Écrire du code Java.
- Cette fois, vous n'avez pas de méthode main, mais des activités. Chaque activité a un cycle de vie défini et des méthodes de rappel que vous pouvez utiliser (par exemple, onCreate, onStart, onResume, onPause, onStop, onDestroy, et ainsi de suite). Vous ne'définissez pas les failles du programme, plutôt le système décide quand chacun est appelé et vous obtenez une chance de faire ce que vous voulez à un certain point.
- Donc, en suivant la même logique que ci-dessus, vous'devriez déclarer une activité principale, et vous le faites dans un fichier appelé AndroidManifest.xml (c'est celui qui est lancé en premier). Vous devez également déclarer toutes les autres activités, services, récepteurs de diffusion, permissions, caractéristiques matérielles, etc. que vous prévoyez d'utiliser dans le même fichier, afin que le système sache qu'ils existent et/ou sont nécessaires, afin que Play Store puisse le filtrer pour les appareils qui ne sont't supportés.
- Vous ne'choisissez pas une version, au lieu de cela vous choisissez le niveau SDK minimum, qui est la version minimale d'Android pour laquelle vous prévoyez de construire et le placer dans le manifeste. Jusqu'à KitKat, la machine virtuelle (Dalvik) savait exécuter le bytecode Java 6, et dans KitKat et les versions ultérieures, elle peut également exécuter Java 7 (Dalvik/ART). Je ne sais pas avec certitude si c'est le même bytecode que sur les ordinateurs, mais c'est assez similaire. Remarquez également que j'ai utilisé le mot bytecode - même en développant pour des appareils pré-KitKat, vous pouviez utiliser des fonctions comme l'opérateur diamant, qui est essentiellement du sucre syntaxique. Si vous tentez d'exécuter du code Java 7 sur des appareils pré-KitKat, votre application se planterait (Android Studio se plaindra également s'il détecte que vous'tentez de faire une telle chose).
- Vous ne pouvez'pas utiliser toutes les bibliothèques, par exemple Swing. NIO est également absent. JavaFX est possible, mais il'n'est pas dans la bibliothèque standard, mais plutôt un port. On s'attend à ce que vous utilisiez le XML pour définir les mises en page, puis que vous obteniez par programme les objets Java appropriés pour lesquels vous avez l'intention de définir des écouteurs ou de les modifier ultérieurement. L'activité peut accéder à la vue racine, et puisque le XML est hiérarchique, c'est tout ce qui'est nécessaire.
- La construction est la même, à l'exception que Gradle est largement favorisé par rapport aux autres alternatives, principalement parce qu'il'est le défaut dans Android Studio. Il'est responsable non seulement du code Java, mais aussi des ressources XML, qui incluent les mises en page, les chaînes, les couleurs, les entiers, etc. qui sont définis dans des fichiers XML séparés et utilisés dans toute l'application. Il ne construit pas un fichier .jar, mais un .apk, qui est en fait un .zip comme .jar, mais contient un fichier nommé classes.dex qui contient les fichiers .class, plus le manifeste et les ressources dans des dossiers séparés (par défaut compressés dans un format appelé "XML binaire"), plus (en option) les actifs. Manifest doit rester lisible pour les tiers.
- La distribution diffère car il'y a un marché central - Play Store.
- Il vérifie le manifeste de votre app'e, extrait les données requises (nom, auteur, choses que vous exigez de l'appareil sur lequel elle va être installée) et le montre à l'utilisateur final en conséquence. Ainsi, si l'utilisateur utilise par exemple Android 4.0 et que le manifeste exige Android 4.1, votre application n'apparaîtra pas dans les résultats de recherche pour cet utilisateur, de même pour les fonctionnalités matérielles comme le GPS. Si un utilisateur suit un lien direct, il obtiendra simplement un message "appareil non compatible".
- Vous pouvez également distribuer à d'autres marchés, qui peuvent avoir leurs propres politiques, ou mettre en place un fichier .apk pour le téléchargement. L'inconvénient de est que dans Android, l'installation d'applications de sources tierces est désactivée par défaut, donc avant d'installer un .apk l'utilisateur devrait activer cette option dans les paramètres. C'est fait parce que Google ne peut'contrôler, ni se porter garant, pour des applications éventuellement malveillantes en dehors du Play Store, ou assurer une qualité et une compatibilité appropriées.
- So, lorsque l'application est installée (c'est-à-dire copiée dans le dossier /data/app/, a eu les dossiers appropriés /data/data/ et similaires créés et enregistrés dans le gestionnaire de paquets du système's), il'est enfin temps de la lancer. Il n'y a pas d'application "Java Virtual Machine" séparée comme sur les ordinateurs, mais tout le travail lourd est effectué par la machine par défaut du système (Dalvik ou ART). Il n'y a pas d'interface native au sens habituel du terme, mais plutôt le NDK qui expose quelques API supplémentaires, généralement dangereuses, et les trucs liés au système sont effectués par le Libcore qui est également intégré au système.
Parce qu'il'est un peu éparpillé, vous ne pouvez't simplement "mettre à jour Java" pour un certain appareil, mais vous devez effectuer une mise à jour de tout le système d'exploitation. Chaque fabricant de téléphones ajoute une marque, une interface utilisateur et des logiciels superflus spécifiques à l'entreprise et, lorsque cela n'a plus de sens financièrement de continuer à développer pour l'appareil, ils arrêtent simplement de proposer des mises à jour pour certains modèles d'appareils. Nous sommes maintenant dans une situation où, même si Android N est censé apporter le dernier et le meilleur OpenJDK, nous serons coincés sur Java 6 pendant un petit moment, et ensuite nous pourrons peut-être passer à la version 7. Peu de gens sentiront le changement de version pour au moins quelques années à partir de maintenant (pour référence, il y a 25% de dispositifs pré-KitKat sur le marché au 2 mai, et seulement 7,5% utilisent la dernière version, Marshmallow)
Donc il'n'est pas vraiment possible d'utiliser JAR sur Android, parce que la seule chose commune que Java sur Windows/Linux/OSX a avec Java sur Android est la spécification du langage, et cela'est juste une partie de l'équation. .apk contient un peu plus de données, est exécuté un peu différemment, et les responsabilités que la JVM a sur les ordinateurs sont éparpillées sur Android.