Flaz's Hotline

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
====== Démarrage et chargement d'un système sur un androphone ======
On sait toutes éteindre et démarrer notre androphone. Le bouton marche/arrêt fait ça très bien :-D Seulement voilà, dès qu'on veut fouiller dans ses entrailles ou y apporter des modifications importantes, cela impose souvent de devoir démarrer notre androphone "autrement".

L'objet de cette fiche est clarifier quelques notions et termes qui apparaissent dans presque tous les tutoriels concernant la manipulation avancée des fonctionnalités d'un androphone. On y rencontre des termes déroutants tels que bootloader, fastboot, recovery, partition système et bien d'autres… Certes, on peut se contenter se suivre pas à pas un tutoriel en ne considérant ces termes que comme des suites de caractères mais ce n'est pas très raisonnable et ça peut être frustrant. En général, ces termes sont utilisés pour expliquer des actions susceptibles de rendre votre androphone totalement inutilisable, de le "briquer". Voilà qui nous donne un premier terme étrange à expliciter avant d'entrer dans le vif du sujet.
===== Briquer =====
C'est un verbe du premier groupe qui exprime d'idée d'effectuer une intervention sur un appareil électronique avec pour résultat de le rendre totalement inutilisable. C'est une transposition littérale du  verbe anglais "brick" qui lui-même dérive du substantif "brick" qui désigne une brique. Briquer un androphone c'est le rendre aussi inerte qu'une brique. Il est "briqué" :-/ En français, on a bien l'expression "en faire un presse-papier" mais c'est un peu plus long et un chouille plus difficile à transformer en verbe. Va pour "briquer". En dehors d'un geste artistique ou politique, //briquer// son androphone est très exactement ce qu'on voudrait éviter.
===== Chargement du système d'un androphone =====
Sources :
[[https://tektab.com/2015/10/31/android-bootloaderfastboot-mode-and-recovery-mode-explained/|Android bootloader/fastboot mode and recovery mode explained/Android boot process]]

La difficulté à comprendre des termes tels que "bootloader" ou "recovery" vient notamment du fait qu'il est difficile de les appréhender isolément. Une manière de restituer une vision d'ensemble est d'examiner ce qui se passe lorsqu'on démarre son androphone. On parle ici de démarrer un téléphone complètement arrêté, éteint, pas en mode veille comme il l'est la plupart du temps bien que l'écran soit éteint.

La première chose qui saute aux yeux est, qu'à l'instar d'un ordinateur,  le démarrage d'un androphone n'est pas instantané. Il faut le temps que le système, l'interface graphique, le lanceur((L'équivalent du "bureau" sur un ordi.)) se chargent avant de pouvoir lancer les applications, d'un simple touché sur l'écran. Il se passe donc beaucoup de choses dont on ne voit rien. Ce qu'on voit, n'est généralement qu'une animation masquant la complexité de ce qui se déroule et visant à nous faire patienter. Mais que se passe-t-il ?

==== Bootloader ====
De manière simplifiée, le démarrage d'un androphone déclenche le lancement d'un premier programme dénommé "[[https://en.wikipedia.org/wiki/Bootloader|bootloader]]"((En français : "chargeur d'amorçage". J'utiliserai le terme "bootloader" car l'expression française n'apporte rien en clarté aux lectrices francophones, expertes ou néophytes.)). Au cours de son exécution, il va lancer Android et lui passer le contrôle de notre  notre androphone. Ce qui donne le schéma ci-après :
{{ :phone:bl-and.png?400 |}}
Sans entrer dans le détail des raisons ayant conduit à ce choix de lancement en deux étapes, notons que le //bootloader// pourrait lancer autre chose que notre système Android. Il se comporte comme un aiguillage qui, en l'absence de toute autre indication, oriente vers le chargement du système (Android).

==== Recovery ====
Une première idée est de lancer un "système" de dépannage, en lieu et place d'Android. Un tel système est un système au sens où il permet d'agir sur le contenu et la configuration de l'androphone tout en proposant une interface d'interaction à travers l'écran tactile. Mais les fonctionnalités qu'il propose sont limitées à des tâches de dépannage et de maintenance : effacer totalement (reformater) une partie de la mémoire, sauvegarder le système Android dans un fichier (ou, en sens inverse, le restaurer), installer une application à partir d'un fichier ou carrément, installer une mise à jour d'Android… Dans certains cas où le système Android est "planté"((Totalement ou partiellement inopérant même si on redémarre l'androphone.)), ce système de dépannage permet de reprendre la main sur l'androphone, de le récupérer, d'en recouvrer l'usage. Dans le jargon Android, ce système de dépannage est appelé un "recovery".
Le //bootloader// a donc le choix entre lancer Android ou lancer le //recovery//, ce qui nous donne le schéma enrichi ci-après :
{{ :phone:bl-and-recov.png?400 |}}
Soit… Mais comment indique-t-on au //bootloader// lequel lancer ? Si on ne fait rien, on constate que le //bootloader// lance Android. Pour qu'il lance le //recovery//, cela réclame une action de notre part. Sur de nombreux androphones, on peut le faire via l'interface matérielle, en appuyant sur le bouton physique "Volume+" au moment du démarrage((Téléphone arrêté, on maintient le bouton Vol+ enfoncé **puis** on appuie sur le bouton marche/arrêt.)). On dit alors que l'androphone a été démarré en "mode" //recovery//.

Le //recovery// est un système très simplifié, rudimentaire, mais il reste malgré tout un logiciel d'une certaine complexité. De nouvelles versions peuvent être nécessaires pour corriger des bugs ou apporter de nouvelles fonctionnalités. On peut même souhaiter utiliser un //recovery// totalement différent de celui qui a été préinstallé sur notre androphone (voir [[#stock_et_custom|stock]]). Pour tout cela, il faut disposer d'un moyen autonome permettant d'installer un nouveau //recovery//. C'est alors qu'intervient le //fastboot//.


==== Fastboot ====
Sources :
  * [[https://android.googlesource.com/platform/system/core/+/master/fastboot|Fastboot]] (en) (AOSP)

On pourrait être tentée de dire, "yaka prévoir un //recovery// du //recovery//!". Pour plein de bonnes raisons, les concepteurs de l'environnement Android ont fait un autre choix. La première chose qui change est que //fastboot// présente une interface graphique spartiate ! L'écran de l'androphone ressemble à un terminal informatique des années 80 : pas d'écran tactile et donc pas de clavier :-\ Le programme informatique qui constitue le //fastboot// est ainsi allégé de toutes les "lignes de code" nécessaires au fonctionnement d'une interface graphique, le protégeant ainsi des bugs et défaillances matérielles susceptibles d'affecter l'écran tactile. La deuxième différence découle de la première : fastboot propose une interface logicielle. Mais encore ? Cela signifie que fastboot peut communiquer avec un programme parlant la même langue que lui. En pratique, on installera un tel programme sur un ordi. L'ordi sera relié à l'androphone par un câble USB. Le programme sur l'ordi nous offre une interface graphique permettant d'interagir avec //fastboot// et se charge de la traduction dans la langue reconnue par //fastboot//.

Pour répondre à la question initiale, //fastboot// permet bel et bien d'installer un nouveau recovery. Mais il permet d'autres choses comme, par exemple, installer une nouvelle version d'Android dans votre androphone sans avoir à la copier au préalable…

===== Sideload =====
Sources :
  * [[https://twrp.me/faq/ADBSideload.html|What is ADB Sideload and how can I use it?]]
  * [[https://forums.oneplus.com/threads/question-whats-the-difference-between-adb-sideload-vs-setting-update.524992/#post-16063718|Whats the difference between adb sideload vs setting update ?]]

Bien qu'étant utilisé dans des opérations complexes, sideload((Que je me hasarderai à traduire par "chargement par la bande.")) n'intervient pas dans la logique de chargement du système. La présence de la racine "load" est trompeuse. Il s'agit d'une fonctionnalité qui permet, depuis un ordi relié en USB (ou par réseau((WiFi, Bluetooth.))), d'implanter une application android (une app) dans la mémoire non volatile d'un androphone. Cette mémoire est celle qui contient notamment le système Android et les applications pré-installées((Celles que l'on peut désactiver mais pas désinstaller.)).

Cette fonctionnalité est offerte via un mode spécifique de fonctionnement du //recovery//. Pour l'utiliser, il faut donc démarrer son androphone en faisant en sorte que le //bootloader// lance le recovery. Puis demander au //recovery// de basculer((Il s'agit bien d'une bascule. Le //recovery// est en mode ordinaire ou bien //sideload//.)) en mode //sideload//. L'ordi doit être équipé d'un programme capable de dialoguer avec le //recovery// à travers une connexion par câble USB.

===== Stock et custom =====
En première approximation, le terme //stock// est utilisé pour désigner ce qui est préinstallé sur un androphone : le bootloader, le système Android, le recovery, le fastboot, des apps… Par extension, cela désigne également ce qui est installé via les mise à jour Android officielle du fabricant de votre androphone (rien à voir avec les fréquentes mises à jours de vos apps via Google Play). On peut remplacer plusieurs de ces composants stock par des composants de notre choix. On peut, par exemple, remplacer la déclinaison propriétaire d'Android préinstallée par une [[https://fr.wikipedia.org/wiki/Liste_de_distributions_alternatives_Android|déclinaison (ou "distribution") open source]] ou changer de //recovery//. Ces versions alternatives aux composants préinstallés sont dites "custom" (personnalisées). On parle ainsi de "custom recovery"((Traduit en franglais par "recovey custom". Authentique :-D)) ou de "custom Android distribution". En français, on utilisera indifféremment "alternatif" ou "personnalisé". Dans l'usage courant, cela permet de distinguer que est //stock// de ce qui est //custom// mais cela n'explique pas pourquoi on utilise le terme "stock" pour désigner "ce qui est préinstallé"…

Pour éclaircir ce point, il faut revenir à la définition originelle. Android est un système open source dont chaque fabricant se saisit pour y introduire un nombre plus ou moins grand de modifications. Dans cette perspective, //stock// désigne la version open source développée dans le cadre du projet [[https://source.android.com/|AOSP]]. Dans les faits, la version open source d'Android contient non seulement le système qui donne vie à notre androphone mais également quelques apps ainsi qu'un //bootloader//, un //fastboot// et un //recovery//. Par voie de conséquence, les versions préinstallées sur un androphone résultent d'une personnalisation par le fabricant; elles sont donc //custom//. Pour s'y retrouver, rien de plus simple. On appelle "stock" la version open source, "officielle" la variante du fabricant et "alternatives" les [[https://fr.wikipedia.org/wiki/Liste_de_distributions_alternatives_Android|autres variantes]].

Certaine distribution alternatives permettent d'installer une version beaucoup plus proche de la version //stock// que la celle préinstallée par le fabricant. Elles sont donc moins customisées que les versions fabricant.
===== Flasher/installer =====
Dès l'instant où l'on veut installer quelque chose qui doit être enregistré dans la mémoire dite "non-volatile" d'un androphone, il va falloir la "flasher". Typiquement, on flashe le système ou le //recovery//. On peut aussi flasher le //bootloader// et le //fastboot// mais cela est une option de flashage du système. Finalement, flasher quelque chose signifie installer cette chose en mémoire non-volatile. certains composants figurant par essence dans la mémoire non-volatile, installer une //custom ROM// (ou un //recovery//) signifie forcément flasher cette //custom ROM// (ou ce //recovery//). On utilisera le verbe "flasher" ou "installer" selon ce sur quoi on veut mettre l'accent.

Flasher un composant est une opération délicate, plus invasive que l'installation d'une app, manuellement ou depuis un store. Elle demande d'être méticuleuse et consciente de ce l'on fait. Il ne faut cependant pas être timorée. Des tutoriels sont là pour nous informer et nous guider. Ayons en tête qu'installer une app sans précaution peut avoir des conséquences bien pires qu'un flashage désinvolte.
===== Confusions possibles =====
En informatique plus qu'ailleurs, un même terme peut être utilisé de manière pertinente à différents niveaux de description. Ainsi, l'//interface// clavier-écran d'un ordi permet de dialoguer avec l'//interface// logicielle d'une programme sur un androphone. Le même terme peut être utilisé pour désigner plusieurs facettes d'un même objet.

Ainsi //fastboot// est à la fois utilisé pour désigner un protocole de communication, le micro-système chargé sur un androphone et l'application installée sur un ordi pour dialoguer avec ce micro-système. Si on omet de préciser de quel //fastboot// on parle, seul le contexte permet de le savoir.

Concernant le //bootloader//, ce terme est également utilisé par certaines pour désigner le //mode// dans lequel se trouve l'androphone quand on décide d'arrêter le démarrage après le lancement du //bootloader//. Comme dans le cas précédent, le contexte précise généralement de quoi l'on parle.

Le terme //sideload// est également employé dans une sens plus général. Certaines l'utilisent pour parler de l'[[https://www.xda-developers.com/how-to-sideload-install-android-app-apk/|installation d'une app sans passer par un store]] (google play, F-Droid, etc.). Autrement dit, pour installer une app autrement que d'une manière "normale". Ce type d'installation n'utilise pas le mode //sideload// précédemment décrit et ne modifie ni le système ni les apps préinstallées.

Les schémas sont par définition des représentations schématiques. La distinction faite entre fastboot et le //bootloader// correspond aux visées explicatives de cette fiche. Si l'on s'interrogeait sur comment mettre à jour //fastboot// ou le //bootloader//, cette schématisation perdrait en pertinence((//Fastboot// et //bootloader// sont plus intimement liés que sur le schéma.)).

La représentation en 4 composants peut laisser penser qu'on pourrait faire ses courses sur internet, un composant par ci, un composant par là… Pour une utilisation avancée mais non experte, le choix est limité au système et au //recovery//.

Cette présentation générale ne préjuge pas des adaptations introduites par les fabricants d'androphones. Sur certains androphones, il est possible d'installer 2 //recovery// simultanément((Cela permet, par exemple, d'installer le //recovery// de son choix tout en conservant le //recovery// d'origine, pré-installé par fabricant, qui seul permet d'effectuer certaines opérations "propriétaire".)), comme cela est prévu dans Android.

De plus, les fabricants et opérateurs téléphoniques peuvent décider de rendre inaccessibles certaines fonctionnalités. Certains donnent accès à un "download mode" qui n'est souvent qu'une variante propriétaire du //fastboot// (standardisé) obligeant à passer par des outils propriétaires pour effectuer des opérations similaires, sans autre but que de verrouiller leurs appareils((D'autant moins justifiable que le protocole //fastboot// étant ouvert, chaque fabricant est libre d'enrichir les commandes standard de commandes propriétaire.)) :-\

===== Schéma détaillé =====
Source de l'image : [[https://tektab.com/author/saadfaruque/|Saad Faruque]], [[https://tektab.com/|Technology Tab]]

{{ https://saadfaruque.files.wordpress.com/2015/10/android-booting-process.png?400 }}
===== Interfaces graphiques =====
L'interface graphique du système Android installé dans notre androphone nous est familière. C'est celle qui nous est présentée lorsqu'on se sert quotidiennement de notre androphone.

J'ai également évoqué l'animation qui s'affiche durant le démarrage ordinaire d'un androphone. Sans que ce soit explicité, la progression de l'animation correspond aux états successifs traversés jusqu'à ce qu'Android soit opérationnel. Bien qu'elle ne soit pas interactive, c'est donc une interface qui nous informe, même sommairement, de ce qui est en train de se passer. Le contenu de l'affichage est plus ou moins explicite, plus ou moins détaillé, selon les distributions d'Android, les fabricants, les opérateurs téléphoniques.

N'oublions pas les interfaces logicielles ! Lorsqu'on connecte un androphone à un ordi ou à un autre androphone((Par un câble USB, en Bluetooth ou par Wifi.)) pour échanger des fichiers, par exemple, on utilise une interface logicielle : un programme présent sur l'androphone dialogue avec un programme présent sur l'ordi. L'important est d'avoir en tête que les possibilités d'interagir avec un androphone ne se limitent pas à l'écran et aux boutons. C'est vrai pour le système Android dans une utilisation banale. Ça l'est encore plus dans les modes de fonctionnement plus "techniques" tels que ceux évoqués (recovery, bootloader, fastboot, sideload).


==== recovery ====
==== bootloader ====
==== fastboot ====

===== Mise à jour du bootloader =====
Concrètement, aucune commande ne permet d'effectuer une mise à jour ciblé du //bootloader//. En fait, ce composant est intégré dans le fichier d'installation d'un système Ancdroid. On pourrait donc en déduire que toute mise à jour d'un système complet entraîne la mise à jour du //bootloader// : oui et non. "Oui" dans la mesure où une mise à jour du système est le seul moyen de changer de //bootloader//. "Non" dans la mesure où la mise à jour du //bootloader// est généralement bloquée par un verrou logiciel (un paramètre). Dans ces conditions, l'installation d'un système provoque le remplacement de tout ce qui est autorisé, mais pas du //bootloader//.

L'astuce consiste à déverrouiller la mise à jour du //bootloader//, préalablement à l'installation d'une mise à jour ou d'une alternative au système.
<note important>Le déverrouillage du //bootlaoder// entraîne l'effacement de l'intégralité du contenu de la mémoire volatile : données, comptes, paramètres, configurations, mise à jours cumulatives d'apps… Cela déclenche une réinitialisation de la mémoire de la même ampleur que le rétablissement des réglages d'usine : votre androphone se retrouve dans l'état de personnalisation((À ceci près que le système n'est pas altéré. En effet, ce dernier est stocké en mémoire non volatile.)) qui était le sien lorsque vous l'avez allumé pour la première, après l'avoir sorti de sa boîte.</note>
Pour ce faire, on doit redémarrer l'androphone en mode //bootloader// et passer les commandes suivantes depuis un ordi :
<code>
fastboot flashing unlock
fastboot flashing unlock_critical
</code>
La prochaine mise à jour intégrale du système s'accompagnera de la mise à jour du //bootloader//.