David Madore's WebLog: Un téléphone brické, un nouveau fiasco de mise à jour Android, et quelques pensées

[Index of all entries / Index de toutes les entréesLatest entries / Dernières entréesXML (RSS 1.0) • Recent comments / Commentaires récents]

↓Entry #2690 [older| permalink|newer] / ↓Entrée #2690 [précédente| permalien|suivante] ↓

(vendredi)

Un téléphone brické, un nouveau fiasco de mise à jour Android, et quelques pensées

Pour faire bref, j'ai (complètement ? partiellement ? cela reste à voir) brické mon téléphone Android (le OnePlus 6 que j'avais acheté il y a un an et demi), j'ai dû en acheter un autre en catastrophe (un Google Pixel 4a), et j'ai eu une cascade suffisamment improbable de malchances que j'ai dû évacuer un tas de mauvais karma dans l'histoire. Mais la séquence d'événements en question est tellement pleine de rebondissements qu'elle mérite d'être consignée ici en un peu de détails. Si ça ne vous intéresse pas, j'ajoute quelques remarques générales (certaines techniques, d'autres pas) à la fin.

Dramatis personæ :

OnePlus 6
Un téléphone Android d'un constructeur chinois (basé à Shēnzhèn ; plutôt haut de gamme par rapport à ce dont on a l'habitude venant de ce pays). Le mien a été acheté en 2019, et choisi parce qu'il pouvait faire tourner LineageOS (cf. ci-dessous) et que mon poussinet avait un modèle proche dont il était assez content. Son nom de code Android est enchilada ce qui peut expliquer l'apparition de ce mot à différents endroits.
Pixel 4a
Un téléphone Android par Google. (J'en ai conseillé l'achat à ma mère tout récemment, et j'ai pu vérifier qu'il n'était pas mauvais. Par ailleurs, il permet également de faire tourner LineageOS.) Ses spécifications sont assez semblables au OnePlus 6 (en un peu plus petit, ce qui peut être vu comme un avantage ou un inconvénient). Son nom de code Android est sunfish.
LineageOS
Une version communautaire d'Android (i.e., des modifications par rapport à l'Android de base de Google apportées par une communauté d'amateurs ; elle est un peu plus libre et un peu plus hackable, et elle supporte des appareils un peu plus anciens). Elle succède à celle qui s'appelait CyanogenMod, et j'utilise l'une ou l'autre sur mes téléphones Android depuis dix ans environ. (Noter que toute version d'Android est toujours un peu modifiée par rapport à la version de référence AOSP distribuée par Google et qui n'est, en fait, utilisée par personne telle quelle : certaines le sont moins, comme celle de Google lui-même, d'autres le sont énormément comme celles des téléphones Samsung ; LineageOS est tout de même très proche de AOSP.)
TWRP
Un mode rescue pour Android, c'est-à-dire une sorte de petit OS spécialisé dans lequel on peut démarrer le téléphone pour faire des opérations de maintenance, comme un backup complet, des modifications de permissions, ou l'installation d'une nouvelle version du système principal. (LineageOS vient avec son propre mode rescue, mais il permet de faire beaucoup moins de choses que TWRP : essentiellement juste installer ou réinstaller LineageOS, ou effacer toutes les données.)
Fastboot
Un mode de démarrage de beaucoup de téléphones Android qui se situe à encore plus bas niveau qu'Android ou que le mode rescue (cf. ci-dessus) : le mode fastboot est géré par le bootloader (le petit programme qui démarre en premier et qui sert normalement juste à lancer Android ou le mode rescue) et qui permet, avec une interface extrêmement minimale, de réinstaller certaines parties (partitions) de la mémoire du téléphone (par exemple celui qui contient le mode rescue, ou celui qui contient les pilotes de périphérique fournis par le constructeur comme le firmware radio).
Google Apps
Une surcouche par rapport à Android fournie par Google (et qui, à la différence de AOSP, est propriétaire). Non nécessaire à faire tourner Android, mais nécessaire à un grand nombre d'applications dessus (tout ce qui utilise de près ou de loin les services Google, par exemple les cartes façon Google Maps). L'installation de LineageOS est donc généralement immédiatement suivie d'une installation de Google Apps qui peut elle-même se faire par différentes sources (j'utilise celles de MindTheGapps).

Le déroulement des faits, maintenant, par ordre chronologique :

  • Acte I. Où j'essaie d'installer de migrer mon OnePlus 6 de LineageOS 16.0 (Android 9) vers 18.1 (Android 11), et où je me retrouve un peu coincé.

    • Scène 1. Mon téléphone OnePlus 6 est actuellement sous LineageOS 16.0 (lineage-16.0-20200325-nightly-enchilada pour être précis) : je décide d'essayer de le mitrer vers la version 18.1. Je commence par faire un backup depuis TWRP de toutes les partitions, que je sauvegarde sur l'ordinateur, à restaurer en cas de problème dans les étapes suivantes. Avec ça, je me dis que je suis en sécurité. Dans la foulée, je mets à jour TWRP lui-même (vers la version twrp-3.5.2_9-0-enchilada.img), mais je ne crois pas que ceci ait joué de rôle pour la suite.
    • Scène 2. Conformément aux instructions trouvées sur le site de LineageOS, j'essaie, en utilisant le mode fastboot, de mettre à jour les partitions constructeur du téléphone (c'est-à-dire les partitions contenant des pilotes ou autres bouts de code ou de données propriétaires, fournies par le constructeur, et utilisées par Android pour que ce dernier soit relativement peu dépendant du téléphone même si ceci reste à ce stade un vœu pieux ; concrètement, j'ai utilisé cet outil pour extraire les fichiers .img du payload.bin contenu dans le fichier fourni par le constructeur, i.e., par OnePlus dans mon cas). Ceci était probablement une erreur (rien ne me dit que le nouveau LineageOS n'aurait pas tourné avec le firmware précédent), mais probablement pas fatale à ce stade. Le mode fastboot refuse de mettre à jour certaines de ces partitions (qualifiées de critiques) : je trouve des avis contradictoires sur quoi faire à ce sujet (certains disent d'ignorer le problème, d'autres de lancer fastboot unlock_critical — mais après coup je découvrirai que ça ne fait rien sur ce téléphone-ci —, d'autres encore de passer en mode rescue et de mettre à jour ces partitions à l'aide de l'outil Unix dd depuis le mode Rescue — cf. par exemple ici, et je finirai par faire ça en II.1). Dans l'immédiat, j'ignore le problème de ces partitions critiques et je passe à la suite.
    • Scène 3. J'installe le nouveau LineageOS (lineage-18.1-20210727-nightly-enchilada) puis des Google Apps (MindTheGapps-11.0.0-arm64-20210412_124247) depuis TWRP. J'essaie de démarrer le téléphone en mode normal : l'animation de démarrage de LineageOS s'affiche (tout n'est donc pas cassé), mais elle mouline indéfiniment sans jamais finir (je comprendrai plus tard la cause probable de ce problème, mais, à ce stade, je ne le sais pas ; l'outil de diagnostic adb logcat montre des tonnes d'erreurs, dont des problèmes de permission, que je pense — à ce stade — peut-être liées au fait que je n'ai mis à jour qu'une partie des partitions constructeur).
    • Scène 4. J'essaie de revenir en arrière en restaurant depuis TWRP le backup que j'ai fait (en I.1). Je redémarre mais, cette fois, le téléphone reste coincé dans le bootloader. J'ai cru qu'il était totalement brické, et j'ai commencé à réfléchir à en acheter un nouveau, mais j'ai fini par me rendre compte que c'était un peu moins grave : le mode fastboot marchait encore, et seulement lui.
  • Acte II. Où j'essaie de repartir de zéro, j'empire nettement la situation et je me retrouve avec un téléphone brické.

    • Scène 1. Ayant maintenant un téléphone qui ne peut plus tourner qu'en fastboot, j'essaie de revenir à un état plus sain. Comme je peux utiliser fastboot pour démarrer un TWRP, je fais une copie du reste des données du téléphone (celles de /sdcard qui ne sont pas concernées par le backup fait en I.1). Puis je reprends l'ensemble des partitions du firmware d'origine de OnePlus (déjà utilisées en I.2), je les recopie sur le téléphone à l'aide de fastboot pour celles (non critiques) que ce dernier accepte de mettre à jour, et de dd sous TWRP (conformément à ces instructions) pour celles qui sont qualifiées de critiques. Je redémarre le téléphone et, à mon heureuse surprise, celui-ci démarre correctement : j'ai maintenant un OnePlus 6 vierge, essentiellement tel que sorti d'usine (j'ai perdu toutes mes données mais j'en ai, en principe, un backup complet). Je le configure minimalement pour vérifier qu'il fonctionne.
    • Scène 2. Enhardi par ce succès, je décide de reprendre ma tentative d'installer LineageOS 18.1 : je restaure le backup initial (celui effectué en I.1), y compris les partitions boot et system, ce qui était probablement une erreur (mais je ne vois pas pourquoi elle aurait porté à conséquence vu que ça doit être annulé par l'installation qui suit). J'installe de nouveau LineageOS et les Google Apps, je redémarre… et je suis accueilli par un message, que je n'ai jamais vu, qui dit uniquement QUALCOMM CrashDump Mode (plus aucun bouton ne fait aucun effet, je n'ai plus accès ni au mode normal, ni au mode recovery, ni même au fastboot ; même éteindre le téléphone n'est pas évident : on peut l'éteindre de force en gardant le bouton power appuyé pendant dix secondes, mais il redémarre dans le mode en question quelques secondes plus tard — il faut faire une manip pas très reproductible à base de branchement et débranchement du câble USB pour arriver, apparemment, à l'éteindre). Bref, mon téléphone est bel et bien brické.
  • Entracte. Je me renseigne sur ce mystérieux mode Qualcomm CrashDump dans lequel mon OnePlus est maintenant : il semble que ce soit un bootloader d'encore plus bas niveau, écrit par Qualcomm (le fabricant de la puce principale du téléphone), qui doit lancer le bootloader normal (celui qui va, à son tour, lancer Android ou un mode rescue), et qui rentre dans ce mode (EDL pour Emergency DownLoad) quand il échoue (ou quand on fait quelque chose de spécial pour l'y faire entrer) ; depuis ce mode on doit en principe pouvoir faire faire des choses à la puce Qualcomm, y compris réécrire sa mémoire pour remettre une version qui marche d'Android, donc mon téléphone n'est pas irrémédiablement brické, mais en pratique c'est tout de même bien compliqué. Je ne suis pas le seul à rencontrer ce genre de problèmes et on peut s'en tirer : apparemment on peut réinitaliser le téléphone en utilisant un outil Windows (MsmDownloadTool V4.0.exe) pour écrire une version spéciale du firmware constructeur (je pense que OnePlus distribue cette version, et cet outil, à leurs revendeurs qui auraient à réinitialiser des téléphones brickés de la sorte, et que ça a fuité), le problème est que je n'ai pas accès à une machine Windows (je pourrais éventuellement essayer d'en lancer une dans une machine virtuelle, mais essayer de reflasher un téléphone par un outil Windows douteux tournant sur un Windows piraté, sur une machine virtuelle, communiquant avec le téléphone brické par un pont USB, ça a l'air quand même assez casse-gueule même si j'ai l'impression qu'il n'y a plus grand-chose à perdre à ce stade). Il y a bien un outil Linux pour communiquer avec le mode EDL des puces Qualcomm, et un script Python qui permet d'extraire le contenu détaillé du firmware enchilada_22_J.50_210121.ops fourni par OnePlus pour aller avec l'outil Windows, et des gens ont réussi à faire quelque chose sur un téléphone proche-mais-différent, mais comme je n'ai aucune idée du fonctionnement de ces outils, ça a l'air assez hasardeux. [Ajout () : cet autre outil est intéressant. et j'ai réussi à m'en servir pour débricker le téléphone, au moins au point de revenir à un Android tel qu'il avait initialement.]

    À ce stade, il est environ 5h du matin (dans la nuit du au ), je suis crevé, je jette l'éponge : je considère le téléphone comme brické jusqu'à nouvel ordre, et je décide que j'en achèterai un autre (soit comme remplaçant, soit comme téléphone temporaire le temps de débricker le OnePlus).

    (Je me suis couché mais, en fait, je n'ai pas réussi à dormir, à la fois parce que j'étais trop énervé et en colère contre moi-même et contre tout le monde d'Android et de l'embarqué, et parce que je continuais à tourner dans ma tête les choses que je pourrais faire et que je devrais faire pour récupérer un téléphone utilisable.)

  • Acte III. Où j'achète un nouveau téléphone (un Pixel 4a) et j'installe LineageOS dessus.

    • Scène 1. Je vais à la Fnac la plus proche de chez moi (celle du centre Italie 2) et je m'achète un Pixel 4a (pour 330€), choix dicté par le fait qu'il était disponible immédiatement, que je savais pour en avoir fait acheter un à ma mère qu'il n'était pas mauvais, et qu'il était au moins géré par LineageOS. Je me prépare à installer LineageOS dessus (instructions là) : la première étape est de déverrouiller le bootloader, ce qui est un peu agaçamment long (j'ai fait ça avec celui de ma mère), parce qu'il faut finir une installation, puis faire le déverrouillage, ce qui efface tout sur le téléphone (mesure de sécurité complètement crétine et absurde), puis refaire une installation. Avant d'aller plus loin, je fais une copie avec TWRP de toutes les partitions dans leur état constructeur : ceci n'est pas pertinent pour la suite, par contre je dois noter que TWRP ne supporte pas officiellement ce téléphone, c'est une version trouvée au hasard du web que je dois utiliser.
    • Scène 2. J'installe LineageOS (lineage-18.1-20210729-nightly-sunfish) puis les Google Apps (MindTheGapps-11.0.0-arm64-20210412_124247) sur le Pixel, cette fois depuis le mode rescue de LineageOS lui-même (conformément aux instructions d'installation), pas depuis le TWRP un peu incertain mentionné en III.1. Le même symptôme qu'en I.3 se produit : le système démarre, mais l'animation de démarrage mouline indéfiniment.
    • Scène 3. Sur l'insistance de mon poussinet, je fais des recherches Google du style LineageOS ("Pixel 4a" OR sunfish) boot stuck jusqu'à tomber sur ce fil Reddit où est décrit le problème que j'ai rencontré, avec une solution : le problème vient d'une incompatibilité(?) de permissions entre les Google Apps et la version de LineageOS, on s'en sort en installant une version modifiée des Google Apps (MindTheGapps-unofficial-11.0.0-arm64-20210624, le lien est dans la réponse Reddit liée ci-dessus). Cette solution fonctionne pour moi, et j'obtiens un Pixel 4a qui marche sous LineageOS 18.1.
  • Acte IV.TWRP n'arrive pas à accéder à ma partition de données.

    Mon intention était, à ce stade, d'essayer de restaurer sauvagement la partition /data de mon ancien téléphone (depuis la sauvegarde faite en I.1), dans l'espoir de remettre mon téléphone dans un état aussi proche que possible du OnePlus 6 que j'avais avant. (C'est certes très hasardeux de copier brutalement les données d'un Android vers un autre, surtout si on change à la fois la version d'Android — en principe il y a des scripts de mise à jour mais il ne faut pas trop compter dessus — et le téléphone. Mais je préfère essayer de voir ce que ça donne, quitte à réparer ce qui ne marchera pas, que d'essayer de reprendre mes données application par application, ce que je finirai quand même par faire à l'acte V.)

    • Scène unique. Je démarre le Pixel sous TWRP (celui mentionné en III.1) dans l'espoir d'y restaurer le backup fait en I.1. Et je découvre que la partition /data du système Android n'y est pas du tout accessible : apparemment TWRP n'arrive pas à la monter. Il semble que ce soit parce qu'il n'arrive pas à la déchiffrer. J'apprends à ce sujet des choses sur la manière dont le chiffrement des partitions se passe sous Android (la partition de données est toujours chiffrée : la clé de chiffrement elle-même est chiffrée avec une passphrase : si on ne met pas de passphrase ni de PIN ni autre chose pour déverrouiller le téléphone, cette passphrase est default_password, que normalement Android et TWRP doivent essayer en premier : ceci fait que si on veut changer de passphrase ultérieurement il n'y aura pas besoin de rechiffrer toute la partition, juste rechiffrer la clé), mais je ne trouve rien qui explique le fait que ça ne marche pas dans mon cas. J'ai essayé diverses idées comme reformater la partition /data depuis TWRP, rien n'a fonctionné. Mais comme dans le fil où j'ai trouvé ce TWRP d'autres ont le même problème (p.ex. ce commentaire et quelques unes de ses réponses), ce n'est probablement pas ma faute. Toujours est-il que je dois abandonner l'idée de faire quoi que ce soit d'utile avec TWRP sur ce téléphone.
  • Acte V. La peur d'avoir perdu les données sauvegardées, puis la longue et fastidieuse configuration du nouveau téléphone.

    • Scène 1. Ne pouvant pas passer par TWRP, je vais tenter de restaurer les données de l'ancien téléphone par petits bouts depuis Android lui-même : pour chaque application à laquelle je tiens, arrêter autant que possible l'application, recopier brutalement les fichiers ou bases de données depuis le backup effectué en I.1, relancer l'application (voire redémarrer le système), et espérer qu'elle utilise la version recopiée. Je veux commencer avec le plus important à mes yeux, l'historique de mes SMS+MMS (que je sais être dans /data/data/com.android.providers.telephony/databases/mmssms.db : cf. mon précédent billet à ce sujet, même si j'avoue être embrouillé entre /data/data/ et /data/user_de/0/ qui ont l'air de contenir le même genre de choses). Mais là, coup de théâtre : je ne trouve pas ce fichier mmssms.db dans l'archive : elle semble ne contenir qu'environ un quart des fichiers qu'elle devrait contenir. Donc non seulement j'ai brické mon vieux téléphone, mais je parais avoir perdu l'essentiel de ce qu'il contenait (et que je pensais avoir sauvegardé en I.1). C'est peu dire que je suis fort contrarié.
    • Scène 2. Mon poussinet me fait remarquer que cette histoire d'archive incomplète est bizarre : sa taille est cohérente avec le fait que tous les fichiers aient bien été sauvés. En fait, le programme tar (qui sert à lire une archive Unix) s'arrête avant la fin : peut-être est-il embrouillé par des extensions non-standard(?) que TWRP a utilisées pour sauvegarder les permissions complexes d'Android (SELinux), toujours est-il que, nouveau rebondissement, en cherchant plus loin dans l'archive on trouve bien les fichiers qui m'intéressent : en fait, tout est bien là, il n'est juste pas immédiatement lisible. Contourner le problème n'est pas difficile (quoique pénible en pratique), il suffit de fournir à tar un bout de l'archive autour du fichier qu'on veut extraire (et qu'on peut trouver en recherchant son nom), il arrive ensuite à le lire.
    • Scène 3. J'extrais (laborieusement, donc) de ma sauvegarde les fichiers d'historiques de SMS et MMS, les pièces jointes des MMS, l'historique des appels, ma liste de contacts, et je les recopie. Je réinstalle l'essentiel des applications que j'avais et, pour celles qui avaient une configuration non triviale, je refais cette configuration (soit à partir de ma sauvegarde, soit à partir de mes souvenirs).
  • Ajout () : J'oubliais d'ajouter que je ne comprends toujours pas, à ce jour, pourquoi la restauration de backup en I.4 m'a coincé dans le bootloader, ni pourquoi j'ai brické le téléphone en II.2 (je n'ai pas touché au bootloader, sauf en installant le firmware fabricant en II.1 mais en II.1 j'ai vérifié qu'il fonctionnait bien ; et tant que le bootloader fonctionne le téléphone ne devrait pas être brické), ni pourquoi TWRP ne parvient pas à accéder à mes données en IV, ni pourquoi le backup fait en I.1 était cassé (comme je l'ai découvert en V.1). Le poussinet a émis l'hypothèse d'un problème matériel sur le téléphone (mémoire défectueuse ?) pour expliquer tout ça à la fois, mais je n'en ai (avais) pas vu de signes avant ce jour.

  • Conclusion. J'ai donc un Pixel 4a à la place de mon OnePlus 6. J'y ai perdu 330€ plus un jour et demi de temps. (Et sans doute encore plus pour me familiariser avec ce qui a changé : par exemple, le bouton de volume du Pixel est à l'emplacement du bouton marche/arrêt du OnePlus, tandis que le bouton marche/arrêt du OnePlus est à l'emplacement du bouton permettant de choisir entre sonnerie, vibreur et silence sur le OnePlus — on dirait que c'est fait exprès pour embrouiller les gens. J'ai aussi plein d'applications qui ne sont pas configurées exactement comme avant et qui risquent de m'embrouiller sur des points mineurs ou moins mineurs.)

    Quant au OnePlus brické, je vais probablement essayer de le débricker, soit en trouvant moyen d'avoir accès à une machine Windows (ce qui ne doit pas être si difficile, mais il faudra quand même que je sois administrateur pour installer les pilotes Qualcomm, et que je puisse faire tourner le programme prétendant faire ce qu'il faut), soit en essayant d'utiliser l'outil Linux censément équivalent. Si j'y arrive, soit je le reprendrai (mais ça implique de faire encore une installation, et je commence à en avoir vraiment marre), soit je le garde comme téléphone de secours, soit je le donne à mon poussinet (qui a un OnePlus 5T).

Quelle morale je tire de tout ça, maintenant ?

Beaucoup de choses que j'ai déjà écrites la dernière fois quand je me suis déjà énervé quant à la difficulté de garder ses données quand on passe d'un téléphone à un autre (en passant de mon Nexus 5 au OnePlus 6 que je viens de bricker). Je ne vais donc pas les répéter ici, mais ajouter quelques compléments.

On m'a fait remarquer, dans les commentaires de l'entrée que je viens de lier, que dans l'optique de préservation de l'information il valait sans doute mieux penser que l'information sur le téléphone est éphémère et que celle qui importe est stockée, de façon pérenne, dans une archive qu'on contrôle mieux. Par exemple, faire une archive des SMS+MMS, sur l'ordinateur, sous un format qu'on saura bien gérer et manipuler et la mettre à jour régulièrement depuis le téléphone, de sorte que si on perd le téléphone ce n'est pas grave, et qu'on ne s'embête pas à tout restaurer si on a un nouveau téléphone. (D'autant plus que l'application Android de SMS est plutôt mauvaise et ne permet même pas de faire des recherches.) C'est très juste, et je devrais m'efforcer de réfléchir dans ce sens.

Néanmoins, même pour des données d'importance secondaire, les perdre à chaque changement de téléphone est pénible : repartir avec un historique de SMS vierge est chiant si on a l'habitude de se servir du téléphone pour se rappeler le contexte de conversations récentes, par exemple. Devoir reconfigurer des dizaines et des dizaines d'applications Android, même si aucune n'est vraiment précieuse, est une fastidieuse perte de temps. (Je ne parle même pas du fait que certaines préférences sont assez cachées et qu'on va remettre un temps fou à les retrouver même quand on sait exactement ce qu'on veut.)

Une chose à laquelle on ne pense jamais : la disposition des applications les plus fréquemment utilisées sur l'écran de démarrage d'Android est quelque chose que je n'ai pas jugé utile de sauvegarder (elle est, bien sûr, stockée quelque part dans les données de l'application de démarrage de mon Android, donc dans mon backup, mais ça doit être vraiment pénible à extraire et décoder). Or c'est quelque chose à quoi on s'habitue : ne pas avoir la disposition à laquelle on s'est fait est perturbant — on sent bien que quelque chose ne va pas, mais pas suffisamment nettement pour retrouver comment ça devrait être. (Je recommande donc de faire, de temps en temps, une copie d'écran de cet écran de démarrage, une fois qu'on en est content. Cf. aussi ces remarques passées sur l'intérêt de photographier les choses banales auxquelles on est habitué.)

Il n'y a toujours aucun moyen décent de copier les données d'un Android vers un autre. Pour certaines choses (comme les contacts) il y a l'option vendre son âme à Google et tout mettre chez eux ; quand on démarre le téléphone pour la première fois il y a moyen de connecter un câble USB avec l'ancien (si on n'a pas brické l'ancien…) pour synchroniser certaines choses ; il y a bien un système de backups dans adb, mais il est plus ou moins abandonné ; il y a vaguement des systèmes passant par le cloud (qu'on peut éventuellement faire siens avec des clouds privés, mais je n'y connais rien) ; en tout cas, restaurer sauvagement les fichiers du /data d'Android marche très mal (et si TWRP ne marche pas ce sera encore pire), surtout à cause du système byzantin de permissions d'Android.

Mais plus profondément, le problème est qu'Android n'a pas compris l'intérêt du modèle de données de l'ordinateur où l'unité essentielle est le fichier : mes données sont dans des fichiers, je sais quels noms ils ont, je passe d'un ordinateur à l'autre en recopiant mes fichiers. Non, Android cache ça sous un labyrinthe d'interfaces complexes qui cherchent à rendre le fonctionnement opaque à l'utilisateur (bien sûr, in fine, les données sont bien dans des fichiers, mais ces fichiers ne sont pas montrés comme tels et rien que trouver leur nom, du style /data/data/com.android.providers.telephony/databases/mmssms.db, est difficile). C'est un choix catastrophique pour la sauvegarde et la restauration des données, et c'est à cause de cette erreur profonde qu'on ne peut pas simplement extraire, modifier et remettre les données sur un téléphone Android. (Je dis Android, mais j'imagine que c'est pareil ou pire pour un iPhone : quelque chose me dit qu'on ne peut pas simplement en copier les données, dans un sens ou dans l'autre, comme des fichiers lisibles au format documenté.)

Une bonne partie de ce problème vient, bien sûr, de l'encore plus détestable idée d'empêcher l'utilisateur de faire ce qu'il veut de son téléphone : le fait que certaines données ne doivent pas être accessibles, ou au moins pas modifiables, par lui, et pas juste pour le protéger d'une fausse manip, mais parce qu'on veut lui interdire certaines choses (comme modifier une application propriétaire, la recopier si elle est payante, ce genre de choses). À cause de ça, Android, qui est un Unix (enfin, un Linux) en interne, vous empêche normalement d'être root (administrateur) : vous avez beau être propriétaire de la machine, vous ne la contrôlez pas autant que vous devriez pouvoir. De cette répugnante idée découlent beaucoup de fautes de conception technique qui ont notamment la conséquence que je viens de souligner que le bête fait de faire un backup est compliqué (forcément, si vous pouvez librement faire un backup et le restaurer, vous pourriez lire ou modifier le backup au passage, et donc accéder à toutes les données du téléphone, en lecture et en écriture), ou le fait que la séquence de boot implique un nombre faramineux d'étapes et de signatures cryptographiques[#] d'où il découle un risque très important de bricker le tout.

[#] Bien sûr, en principe, une séquence de boot où chaque étape valide la signature sur l'étape suivante peut permettre de protéger l'utilisateur contre certaines attaques (ou plus exactement, contre la persistance de certaines attaques). Mais en pratique, il est clair que sous Android cette moussaka est plus là pour protéger les intérêts de Disney contre Madame Michu que pour protéger Madame Michu contre le méchant hacker russe.

Le fait qu'il soit si pénible d'installer un Android un peu modifié sur un téléphone résulte lui aussi de l'incompréhension par le monde de l'informatique embarquée de choses qui sont normalement évidentes en informatique de bureau. La séparation du logiciel et du matériel, notamment : pour installer un système d'exploitation sur un ordinateur, je prends un support d'installation, je le branche dessus, et j'installe — et je n'ai pas une version différente du système pour chaque modèle d'ordinateur. Mais les gros débiles du monde de la téléphonie ont décidé qu'il en serait autrement, et au lieu qu'on ait un système Android, avec éventuellement différentes variantes, mais toutes capbables de tourner sur tous les téléphones du marché, il faut une version différente pour chaque téléphone. Et du coup on a persuadé Madame Michu que c'est normal de penser que tel ou tel téléphone est mieux que tel ou tel autre parce qu'il a telle ou telle fonction, alors que cette fonction est purement logicielle et qu'il n'y a aucune raison qu'elle ne soit pas disponible sur tous. Tout ça me met profondément en colère.

Pour les défendre, Google semble avoir compris certains de ces problèmes en lançant ce qui s'appelle le projet Treble (voir ici pour des explications peu techniques et pour de plus techniques), même si leur but, dans l'histoire, était plutôt de diminuer le délai entre une mise à jour d'Android et sa répercussion sur les téléphones des différents constructeurs. Mais je constate que le succès est mitigé : mon ancien téléphone contenait des partitions constructeur nommées LOGO, abl, aop, bluetooth, cmnlib, cmnlib64, devcfg, dsp, dtbo, fw_4j1ed, fw_4u1ea, hyp, keymaster, modem, oem_stanvbk, qupfw, reserve, storsec, tz, vbmeta, vendor, xbl et xbl_config, le nouveau contient abl, aop, apdp, cdt, cdt_backup, cmnlib64, cmnlib, ddr, devcfg, devinfo, dtbo, frp, fsc, fsg, hyp, imagefv, keymaster, keystore, klog, limits, logfs, modem, modemst1, modemst2, msadp, qupfw, secdata, splash, spunvm, ssd, storsec, toolsfv, tz, uefisecapp, uefivarstore, vbmeta, vbmeta_system, xbl et xbl_config, excusez du peu (notez que j'omets les partitions normales d'Android comme system et boot) : je n'ai aucune idée de ce à quoi servent toutes ces partitions (le mieux que je trouve est ), encore moins de pourquoi il en faut autant alors que mon PC n'en a qu'une poignée, mais je constate que même avec tout ça ils n'ont pas réussi à faire une couche d'abstraction suffisante pour qu'on puisse juste installer Android sans se soucier du matériel sous-jacent.

Bon, si je continue sur cette ligne d'idées je vais me retrouver à redire des choses que j'ai déjà écrites il y a des années, donc je n'insiste pas plus.

↑Entry #2690 [older| permalink|newer] / ↑Entrée #2690 [précédente| permalien|suivante] ↑

[Index of all entries / Index de toutes les entréesLatest entries / Dernières entréesXML (RSS 1.0) • Recent comments / Commentaires récents]