Après quelques réflexions et quelques recherches, je me suis dit que c'était peut-être une bonne idée de présenter aux plus curieux l'architecture d'Android. Vous pouvez considérer ce chapitre comme facultatif s'il vous ennuie ou vous semble trop compliqué, vous serez tout de même capable de développer correctement sous Android mais un peu de culture technique ne peut pas vous faire de mal .
Concrètement, l'architecture d'Android, c'est ça :
En soi, ce schéma est incompréhensible et franchement pas glamour, mais il résume de manière concrète ce que je vais vous raconter. Ce que vous observez est une pile des composants qui constituent le système d'exploitation. Le sens de lecture se fait de bas en haut, puisque le composant de plus bas niveau est le noyau Linux et celui de plus haut niveau sont les applications.
La version du noyau utilisée avec Android est une version conçue spécialement pour l'environnement mobile, avec une gestion avancée de la batterie et une gestion particulière de la mémoire. C'est cette couche qui fait en sorte qu'Android soit compatible avec tant de supports différents.
Si vous regardez attentivement le schéma, vous remarquerez que cette couche est la seule qui gère le matériel. Android en soi ne s'occupe pas de ce genre de détails. Je ne veux pas dire par là qu'il n'y a pas d'interactions entre Android et le matériel, juste que quand un constructeur veut ajouter un matériel qui n'est pas pris en compte par défaut par Android, il doit travailler sur le kernel et non sur les couches au-dessus, qui sont des couches spécifiques à Android.
Un moteur d'exécution (« runtime system » en anglais) est un programme qui permet l’exécution d'autres programmes. Vous savez peut-être que pour utiliser des applications développées en Java sur votre ordinateur vous avez besoin du JRE (« Java RUNTIME Environment »), et bien il s'agit du moteur d'exécution nécessaire pour lancer des applications écrites en Java.
Concrètement, l'architecture d'Android, c'est ça :
Schéma qui provient de la page suivante, provenant du site d'Android destiné aux développeurs.
En soi, ce schéma est incompréhensible et franchement pas glamour, mais il résume de manière concrète ce que je vais vous raconter. Ce que vous observez est une pile des composants qui constituent le système d'exploitation. Le sens de lecture se fait de bas en haut, puisque le composant de plus bas niveau est le noyau Linux et celui de plus haut niveau sont les applications.
Le noyau Linux
Je vous avais déjà dit que le système d'exploitation d'Android se basait sur Linux. Si on veut être plus précis, c'est le noyau (« kernel » en anglais) de Linux qui est utilisé. Le noyau est l'élément du système d'exploitation qui permet de faire le pont entre le matériel et le logiciel. Par exemple les pilotes Wifi permettent de contrôler la puce Wifi. Quand Android veut activer la puce Wifi, on peut imaginer qu'il utilise la fonction « allumerWifi() », et c'est au constructeur de spécifier le comportement de « allumerWifi() » pour sa puce. On aura donc une fonction unique pour toutes les puces, mais le contenu de la fonction sera unique pour chaque matériel.La version du noyau utilisée avec Android est une version conçue spécialement pour l'environnement mobile, avec une gestion avancée de la batterie et une gestion particulière de la mémoire. C'est cette couche qui fait en sorte qu'Android soit compatible avec tant de supports différents.
Ça ne signifie pas qu'Android est une distribution de Linux, il a le même coeur mais c'est tout. Vous ne pourrez pas lancer d'applications destinées à GNU/Linux sans passer par de petites manipulations, mais si vous êtes bricoleur...
Si vous regardez attentivement le schéma, vous remarquerez que cette couche est la seule qui gère le matériel. Android en soi ne s'occupe pas de ce genre de détails. Je ne veux pas dire par là qu'il n'y a pas d'interactions entre Android et le matériel, juste que quand un constructeur veut ajouter un matériel qui n'est pas pris en compte par défaut par Android, il doit travailler sur le kernel et non sur les couches au-dessus, qui sont des couches spécifiques à Android.
Les bibliothèques pour Android
Ces bibliothèques proviennent de beaucoup de projets open-sources, écris en C/C++ pour la plupart, comme SQLite pour les bases de données, WebKit pour la navigation web ou encore OpenGL afin de produire des graphismes en 2D ou en 3D. Vous allez me dire qu'Android ne peut pas utiliser ces bibliothèques puisqu'elles ne sont pas en Java, cependant vous auriez tort puisqu'Android comprend très bien le C et le C++ !
Le moteur d'exécution Android
C'est cette couche qui fait qu'Android n'est pas qu'une simple « implémentation de Linux pour portables ». Elle contient certaines bibliothèques de base du Java accompagnées de bibliothèques spécifiques à Android et la machine virtuelle « Dalvik ».
Voici un schéma qui indique les étapes nécessaires à la compilation et à l’exécution d'un programme Java standard :
Votre code est une suite d'instructions que l'on trouve dans un fichier « .java » et ce fichier sera traduit en une autre suite d'instructions dans un autre langage que l'on appelle le « bytecode». Ce code est contenu dans un fichier « .class ». Le bytecode est un langage spécial qu'une machine virtuelle Java peut comprendre et interpréter. Les différents fichiers « .class » sont ensuite regroupés dans un « .jar » et c'est ce fichier qui est exécutable. En ce qui concerne Android, la procédure est différente. En fait ce que vous appelez Java est certainement une variante particulière de Java qui s'appelle « Java SE ». Or, pour développer des applications pour Android, on n'utilise pas vraiment Java SE. Pour ceux qui savent ce qu'est « Jave ME », ce n'est pas non plus ce framework que l'on utilise (Java ME est une version spéciale de Java destinée au développement mobile, mais pas pour Android donc).
A noter que sur le schéma le JDK et le JRE sont réunis, mais il est possible de télécharger le JRE sans télécharger le JDK.
La version de Java qui permet le développement Android est une version réduite amputée de certaines fonctionnalités qui n'ont rien à faire dans un environnement mobile. Par exemple, la bibliothèque graphique Swing n'est pas supportée, on trouve à la place un système beaucoup plus adapté. Mais Android n'utilise pas une machine virtuelle Java ; une machine virtuelle toute étudiée pour les systèmes embarqués a été développée, et elle s'appelle « Dalvik ». Cette machine virtuelle est optimisée pour mieux gérer les ressources physiques du système. Je citerai par exemple qu'elle permet de laisser moins d'empreinte mémoire (la quantité de mémoire allouée à une application pendant son exécution) et qu'elle puise moins dans la batterie qu'une machine virtuelle Java.
La plus grosse caractéristique de Dalvik est qu'elle permet d'instancier (terme technique qui signifie « créer une occurrence de ». Par exemple quand vous créez un objet en java, on instancie une classe puisqu'on crée une occurrence de cette classe) un nombre très important d'occurrences de lui-même : chaque programme a sa propre occurrence de Dalvik et elles peuvent vivre sans se perturber les unes les autres. Voici un schéma qui indique les étapes nécessaires à la compilation et à l’exécution d'un programme Android standard :
On voit bien que le code Java est ensuite converti en bytecode Java comme auparavant. Mais souvenez-vous, je vous ai dit que le bytecode Java ne pouvait être lu que par une machine virtuelle Java, et je vous ai aussi dit que Dalvik n'était PAS une machine virtuelle Java. Il faut donc procéder à une autre conversion à l'aide d'un programme qui s'appelle « dx ». Ce programme s'occupera de traduire les applications de bytecode Java en bytecode Dalvik, qui lui est compréhensible par la machine virtuelle.
La puissante machine virtuelle Dalvik est destiné uniquement à Android, mais il est possible de développer une machine virtuelle similaire et qui ne fonctionne pas sous Android. Par exemple, le Nokia N9 pourra exécuter des applications Android sans utiliser ce système.
Les frameworks pour les applications
Il s'agit d'un framework qui...
Un framework peut se traduire littéralement par un cadre de travail. Il s'agit d'un ensemble de composants qui définissent les fondations ainsi que les grandes lignes directrices de l'organisation d'un code, en d'autres termes on peut parler de son architecture ou de son squelette. Un framework prodigue aussi quelques fonctionnalités de base (accès à la base de données par exemple). Cet outil fournit ainsi une démarcation radicale entre plusieurs aspects d'un programme et permet de mieux diviser les tâches (toi tu fais l'interface graphique, toi l'interaction avec le réseau, etc).
En fait ce sont ces frameworks là qui vous sont disponibles quand vous programmez en Java, et qui s'occupent d'interagir avec la bibliothèque Android. Vous pouvez vous contenter d'appeler des fonctions déjà faites à l'avance par d'autres et les regarder s'exécuter tranquillement.
Un quoi??
Un framework peut se traduire littéralement par un cadre de travail. Il s'agit d'un ensemble de composants qui définissent les fondations ainsi que les grandes lignes directrices de l'organisation d'un code, en d'autres termes on peut parler de son architecture ou de son squelette. Un framework prodigue aussi quelques fonctionnalités de base (accès à la base de données par exemple). Cet outil fournit ainsi une démarcation radicale entre plusieurs aspects d'un programme et permet de mieux diviser les tâches (toi tu fais l'interface graphique, toi l'interaction avec le réseau, etc).
En fait ce sont ces frameworks là qui vous sont disponibles quand vous programmez en Java, et qui s'occupent d'interagir avec la bibliothèque Android. Vous pouvez vous contenter d'appeler des fonctions déjà faites à l'avance par d'autres et les regarder s'exécuter tranquillement.
Les applications
Il s'agit tout simplement d'un ensemble d'applications que l'on peut trouver sur Android, par exemple les fonctionnalités de base inclues un client pour recevoir/envoyer des emails, un programme pour envoyer/recevoir des SMS, un calendrier, un répertoire, etc. C'est ici que vous intervenez, cette stèle est celle de vos futures applications développées en Java. Vous l'aurez compris, vous accédez aux mêmes ressources que les applications fournies par défaut, vous avez donc autant de possibilités qu'elles, vous avez même la possibilité de les remplacer. C'est aussi ça la force d'Android.
