Le processus de boot d'android : tout comprendre

Par franck_29 - Le 24/09/13 - Affichages : 11526

Une fois n'est pas coutume, ce sujet est essentiellement est une traduction d'un article de Ketan Parmar initialement publié sur le site KP Bird.
Il m'a semblé que l'on ne trouvait pas sur le forum de description assez précise et détaillée du processus de démarrage d'android dans sa globalité, cela manquait alors je me propose de vous en faire une traduction.
------

Android est un système d'exploitation basé sur Linux (Ndt: linux n'est que le noyau d'un système complet qu'il conviendrait de nommer GNU/Linux), le noyau Linux est est omniprésent sur les plate-formes x86, quoi qu'il en soit, tous les smartphones Android fonctionnent sur des processeurs ARM (ARM pour Advanced RISC Machine, qui était auparavant Acom RISC Machine), à l’exception du Xolo d'intel (http://xolo.in/xolo-x900-features). Xolo est équipé d'un processeur Atom 1.6Ghz ayant une architecture x86. La procédure de démarrage d'android sur smartphone est quelque peu différente de celle ayant cours sur les ordinateurs sous Gnu/Linux. Dans cet article, je tenterai d'expliquer cette séquence de boot en ne parlant que d'android. Inside the linux boot process est un excellent article traitant de la séquence de boot pour GNU/Linux.

Lors de la mise sous tension, les étapes suivantes se déroulent successivement :


Image



Etape 1 : Mise sous tension et Démarrage du système

A la mise sous tension, un code de démarrage s'éxécute, le "Boot ROM code". Son emplacement est prédéfini et "câblé" dans la ROM de l'appareil (NDT : ne pas confondre avec le FIRMWARE). Ce code a pour effet de charger en RAM le "bootloader" qui s'éxécute alors.

Etape 2 : Le bootloader

Le bootloader est un petit programme qui s'exécute avant même qu'android ne soit lancé, c'est le premier programme à s’exécuter, il est donc spécifique à la carte mère et au processeur qu'embarque l'appareil. Les constructeurs peuvent utiliser des bootloaders "standards" comme redboot, uboot, gi bootloader, mais ils peuvent aussi développer leur propres bootloaders. Le bootloader ne fait pas partie du système android. C'est par ailleurs en son sein que les constructeurs et les opérateurs insèrent leurs protections et restrictions.
Son exécution se déroule en deux temps, premièrement, il détecte la présence de RAM et y charge des modules qui seront utiles lors de la deuxième étape.
Deuxièmement, il charge des modules de configuration du réseau, de la mémoire, etc... modules qui requerront de lancer le Kernel. Le bootloader est capable de transmettre au kernel des éléments de configuration pour des besoins spécifiques.

(...)
Un bootloader contient essentiellement deux procédures :
1. init.s - Initialisation des piles, mise à zéro du segment BSS , appel de la fonction main() in main.c
2. main.c - Initialisation du matériel (horloge, carte mère, clavier, console), création de "Linux tags"

Pour en savoir plus sur les bootloader :
https://motorola-global-portal.custhelp ... -questions

Etape 3 : Le Kernel

Le noyau android démarre de la même façon que sur un PC sous GNU/Linux. A son chargement, il configure le cache, la mémoire protégée, charge des drivers. Quand le kernel en a terminé de son initialisation, il commence par vérifier la présence la présence d'init dans les fichiers systèmes puis lance le premier processus du système, le processus root ou init.


Etape 4: init process

init est le tout premier processus, on parle de processus racine (root) ou de "grand-mère" de tous les futurs processus. Le processus init a deux responsabilités :
1- il monte des répertoires comme /sys /dev, /proc
2- il exécute le script init.rc

Le code du processus init peut etre trouvé ici : <android source>/system/core/init
Le fichier init.rc peut être trouvé ici : <android source>/system/core/rootdir/init.rc
Le fichier readme.txt peut être trouvé dans le source android ici : <andorid source>/system/core/init/readme.txt

Android impose un format spécifique au fichier init.rc, on appelle ce format, l'"android init language" (Ndt : ça ne se traduit pas ça)
Ce langage est constitué de 4 grandes classes d'item :
- Les Actions
- Les Commandes
- Les Services
- Les options

Les Actions sont des séquences d'instruction nommées. Aux Actions sont associées des déclencheurs (triggers) qui sont utilisés pour déterminer quand ou dans quelle circonstance les Commandes doivent être exécutées.
Syntaxe
Code: Select All Code
on <trigger>
  <command>
  <command>
  <command>


Les services sont des programmes que le processus init va lancer et qu'optionnellement il pourra relancer quand ils se termineront.
Syntaxe
Code: Select All Code
service <name> <pathname> [ <argument> ]*
  <option>
  <option>
  ...


Les Options sont des "modificateurs" de services, ils servent à préciser quand et comment init doit lancer le service

Examinons le fichier init.rc par défaut. Je vous propose un extrait ne retraçant que les éléments principaux


Action / ServiceDescription
on early-initSet init and its forked children's oom_adj.
Set the security context for the init process.
on initsetup the global environment
Create cgroup mount point for cpu accounting
and many
on fsmount mtd partitions
on post-fschange permissions of system directories
on post-fs-datachange permission of /data folders and sub folders
on bootbasic network init ,Memory Management ,etc
service servicemanagerstart system manager to manage all native services like location, audio, shared preference etc..
service zygotestart zygote as app_process


A ce stade, vous devriez voir le logo android sur l’écran de votre appareil

Etape 5: Zygote et Dalvik

En environnement Java, nous savons que pour chaque application, une instance séparée d'une machine virtuelle JAVA doit être montée en mémoire. Dans le cas d'android, il était impératif que chaque application se lance le plus rapidement possible, et s'il avait fallu lancer autant de machine virtuelle Dalvik (Ndt : c'est le nom de la machine virtuelle JAVA) cela aurait eu des impacts négatifs forts en terme de rapidité et de consommation de mémoire. Alors, pour traiter le problème, Android a mis en œuvre un système appelé "Zygote". Zygote permet de partager des éléments de code entre machines virtuelles Dalvik, il limite ainsi grandement le taille mémoire requise et, ce faisant, minimise le temps de chargement. Zygote est un processus qui démarre lors du boot, ainsi que nous l'avons vu lors de l'étape 4 (Ndt : cf. tableau), il précharge et initialise les "core library classes" (bibliothèques de classes de base). Normalement, ces classes sont "read-only", elles font partie de l'android SDK ou du "framework", elles ne sont donc chargées qu'une fois, tandis qu'en environnement JAVA classique, chaque VM devrait avoir sa propre copie en mémoire de ces "core library classes"

Examinons dans le détail le chargement du process zygote

1. Load ZygoteInit class, Code source :<Android Source> /frameworks/base/core/java/com/android/internal/os/ZygoteInit.java
2. registerZygoteSocket() - Registers a server socket for zygote command connections.
3. preloadClasses() - “preloaded-classes” est un simple fichier texte enumérant la liste des classes devant être préchargées. Les classes préchargées sont listées dans le fichier <Android Source>/frameworks/base
4. preloadResources() - preloadResources va charger les thèmes natifs, et tout ce qui est inclus dans le fichier android.R sera chargé selon cette méthode.

A cet instant vous devriez voir l'animation du boot (BootAnimation)

Etape 6: System Service or Services

A la fin de l'étape 5, Zygote est en charge de lancer les "system servers". Ces "system servers" sont écrits soit en JAVA ou en code natif, on peut les considérer comme des processus, Dans la terminologie Android, on parle de services systèmes.

Zygote "forke" un nouveau process pour chaque service système à lancer, le code source assurant ce fork et le lancement des services systèmes se situe dans la classe ZygoteInit et plus précisément dans la méthode startSystemServer.

Liste des "Core Services":
1. Starting Power Manager
2. Creating Activity Manager
3. Starting Telephony Registry
4. Starting Package Manager
5. Set Activity Manager Service as System Process
6. Starting Context Manager
7. Starting System Context Providers
8. Starting Battery Service
9. Starting Alarm Manager
10. Starting Sensor Service
11. Starting Window Manager
12. Starting Bluetooth Service
13. Starting Mount Service

Liste des autres services
1. Starting Status Bar Service
2. Starting Hardware Service
3. Starting NetStat Service
4. Starting Connectivity Service
5. Starting Notification Manager
6. Starting DeviceStorageMonitor Service
7. Starting Location Manager
8. Starting Search Service
9. Starting Clipboard Service
10. Starting Checkin Service
11. Starting Wallpaper Service
12. Starting Audio Service
13. Starting HeadsetObserver
14. Starting AdbSettingsObserver

Etape 7: Boot Completed

Une fois les services systèmes lancés, le processus de boot android est terminé. A ce point, une dernière action est lancée : le signal “ACTION_BOOT_COMPLETED” est "fired" (lancé).


A ce stade, une autre phase particulièrement intéressante va se dérouler, toues les applications installées qui pourraient être à l'écoute de ce signal, vont être activées, elles pourront alors s'initialiser.
Mais cela est une autre histoire.

Ndt : J'ai pris un certain plaisir à traduire et à comprendre ce texte, je suis souvent allé dans les références citées par l'article original, pour notamment en comprendre un peu plus sur Zygote, et le signal "Action_boot_completed".
Je vous engage à faire de même... Vous regarderez votre smartphone avec peut être un peu plus d'humilité et témoignerez un véritable respect vis à vis de la longue chaîne de savoirs qui ont permis d'en arriver là, plus de 30 ans après les premiers PC.
Franchement, c'est de la haute technologie, soyez en assurés.


11 réponse(s) -