David Madore's WebLog: J'essaie Cyanogen

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

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

(lundi)

J'essaie Cyanogen

J'ai un téléphone sous Android depuis un an et demi, et force est de constater qu'il subit le même phénomène horripilant que tous les ordinateurs : ce que j'appelle le « vieillissement logiciel », c'est-à-dire le fait que les mises à jour sont prévues pour des matériels plus récents et plus performants et qu'au bout d'un moment le vieux matériel est laissé sur le côté (alors qu'il n'est pas matériellement usé, il est seulement logiciellement usé). En l'occurrence, si mon téléphone était livré avec Android 1.0 et que j'ai rapidement pu mettre à jour vers Android 1.5 puis 1.6, le fabriquant (HTC) ne semble pas avoir (eu) pour projet de fournir des mises à jour vers les versions ultérieures du système : on peut le comprendre, parce que celles-ci sont prévues pour des appareils ayant plus de ressources (notamment mémoire), mais l'ennui est que, de nos jours, tout logiciel de plus de six mois est infesté de problèmes de sécurité, et le navigateur Web utilisé par Android n'est pas une exception. Normalement, HTC aurait le devoir moral de prévoir (pour plusieurs années au moins) des mises à jour mineures d'Android 1.6 pour corriger uniquement les trous de sécurité, mais évidemment, si Google ne les fait pas, ils n'ont pas les ressources pour. Bref. L'autre facette du problème est que, si je ne peux pas mettre à jour le système lui-même, les applications, elles, elles essaient quand même, notamment Google Maps qui déploie une ingéniosité sans pareil pour activer sournoisement la mise à jour automatique, or il se trouve que cette mise à jour échoue souvent parce que le téléphone manque de place (dans la partition /data) et on se retrouve avec une application cassée.

Ces problèmes étant ce qu'ils sont, cela faisait un moment que j'envisageais de passer à CyanogenMod, qui est la version communautaire d'Android (avec des petits robots cyan beaucoup plus joueurs que les petits robots verts de l'Android de base) et qui, contrairement à Google continue, pour encore un moment au moins, à gérer mon vieux téléphone HTC Dream (aka G1, aka, dans mon cas, Google Dev Phone) : spécifiquement, avec la version 6 de CyanogenMod, qui est basée sur Android 2.2.

J'envisage aussi d'acheter un nouveau téléphone (je logne sur le HTC Desire Z, parce que je veux avoir un vrai clavier physique ; l'inconvénient est que je tiens absolument au clavier QWERTY, ce qui veut dire qu'il faudra probablement faire acheter l'appareil hors de prix à Londres et que je n'aurai pas de garantie dessus, ce qui m'ennuie quand même), auquel cas mon poussinet (qui s'est fait voler son HTC Magic et depuis a un téléphone tout pourri qu'il avait acheté au Canada) récupérerait celui que j'ai actuellement. Mais en attendant, comme nous voulons faire des économies, je reste où j'en suis matériellement. Reste, donc, la possibilité de l'upgrade logicielle.

Les instructions pour mettre à jour, décrites officiellement ici et ici pour mon téléphone, font un peu peur, et j'avais beaucoup hésité avant de me lancer. Notamment pour deux raisons : (1) il faut accepter de perdre toutes les données installées sur le téléphone (toutes les données enregistrées par toutes les applications, les contacts, les logs d'appel, les SMS, etc. : certes, on peut faire des copies de sauvegarde de certaines choses pour les récupérer après, j'y reviendrai, mais le défaut est de tout perdre), et (2) pire, il y a une chance (faible, mais non négligeable, et surtout mal comprise) de « briquer » le téléphone (c'est-à-dire qu'il ne puisse plus redémarrer et qu'il devienne aussi inutile qu'une brique), situation dont il est très difficile de s'extraire (c'est possible, mais cela impose au moins d'ouvrir la bête pour souder des points de contact JTAG pas facilement accessibles, et de faire ensuite de la magie avec OpenOCD via un contrôleur JTAG : le genre de choses que je n'ai pas, mais alors vraiment pas du tout, envie de faire). Un jour j'écrirai dans ce blog un rant pour protester contre le fait que tous les dispositifs électroniques ou informatique, de nos jours, soient « briquables », que c'est un scandale, et que les fabriquants devraient avoir l'obligation réglementaire de fournir sur tout appareil de ce genre un bouton de reset complet qui remet le dispositif à zéro à partir d'une vraie ROM, bordel de merde, pas une connerie d'EPROM flashable… mais je digresse.

Concernant la première partie, j'ai fait des copies de sauvegarde ad hoc (soit avec des applications faites pour, soit simplement sur du papier) de toutes sortes de petites choses, de ma liste de SMS échangés à toutes sortes de réglages de configuration, et même la manière dont j'avais disposé les icônes sur les écrans. Mais j'ai aussi voulu faire une sauvegarde plus systématique de toutes les données du téléphone, en me disant que ça pourrait toujours servir. Eh bien figurez-vous que ce n'est pas facile !

Sur un système Linux normal, on peut copier intégralement l'image d'un disque ou d'une partition en faisant quelque chose comme dd if=/dev/sda of=/un/fichier/de/sauvegarde.img, où /dev/sda désigne le disque à sauvegarder ; mais pour la mémoire flash d'un téléphone sous Android, ce n'est pas si facile : on peut bien essayer de copier les partitions flash avec par exemple dd if=/dev/mtd/mtd5 of=/sdcard/data.img bs=2048, cela produit bien une image, mais si on veut ensuite en examiner le contenu (par exemple en extraire un fichier précis), il faut bien s'accrocher ! D'abord, Android utilise un système de fichiers complètement bizarre connu sous le nom de Yaffs2, tellement arcane qu'il ne fait pas partie des zillions de systèmes de fichiers (ou même des dizaines de systèmes de fichiers spécifiquement prévus pour les mémoires flash) connus par un Linux de base, et la documentation des structures de ce filesystem est quasi-inexistante (et fausse) ; ensuite, les mémoires flash ne stockent pas juste des blocs de 2048 octets, elles stockent pour chaque bloc un petit bout de données en plus, appelées données OOB (out-of-band), dans le cas de mon téléphone 56 octets par bloc de 2048 octets, utilisées pour faire de la détection et correction d'erreurs sur le bloc, mais dont certains bouts restent encore libres et Yaffs2 s'en sert : donc, pour pouvoir récupérer correctement les fichiers d'un tel dump, il faudra les données OOB. Pour les récupérer, il y a un programme qui existe, il s'appelle nanddump et il fait partie du jeu d'utilitaires mtd-utils, mais alors imaginez-vous que pour compiler ce programme de façon à pouvoir le faire tourner sous Android, ce n'est vraiment pas du gâteau (Google fournit bien des outils pour compiler des programmes pour Android, mais ils sont orientés vers la production d'applications normales, pas de petits utilitaires en ligne de commande ; pour compiler mon nanddump, j'ai dû passer par des choses aussi rébarbatives à taper que /opt/android-ndk-r5b/toolchains/arm-eabi-4.4.0/prebuilt/linux-x86/bin/arm-eabi-gcc -mandroid -O2 -g -Wall -Wextra -Wwrite-strings -Wno-sign-compare -ffunction-sections -fdata-sections -Wl,--gc-sections -g -o /tmp/mtd-utils-20110107/nanddump /tmp/mtd-utils-20110107/nanddump.o /tmp/mtd-utils-20110107/lib/libmtd.a -L/tmp/mtd-utils-20110107/lib -lmtd -Wl,-rpath-link,/opt/android-ndk-r5b/platforms/android-4/arch-arm/usr/lib -Wl,--dynamic-linker,/system/bin/linker -L /opt/android-ndk-r5b/platforms/android-4/arch-arm/usr/lib -I /opt/android-ndk-r5b/platforms/android-4/arch-arm/usr/include -nostdlib /opt/android-ndk-r5b/platforms/android-4/arch-arm/usr/lib/crtbegin_dynamic.o -lc). Et de toute façon, une fois produits ces dumps avec données OOB, je suis bien embarrassé pour les utiliser ; j'ai trouvé un programme unyaffs2 censé marcher, mais il a fallu le patcher parce qu'il attendait des blocs de 2048+64 octets et pas 2048+56, et encore, il n'a correctement fonctionné que sur la partition system, sur la partition data, il est mort dans de violentes souffrances. C'est à croire que je suis le premier à vouloir faire ça, récupérer intégralement la copie de la mémoire d'un téléphone Android pour pouvoir en extraire ensuite des fichiers si besoin est !

J'ai fini par me contenter d'une copie de sauvegarde « probablement complète, et exploitable en théorie » en plus de mes différentes sauvegardes manuelles de tout ce qui me venait à l'esprit.

Pour le risque de « briquer » le téléphone, les instructions officielles se voulaient rassurantes (j'avais déjà la bonne version du firmware radio, donc normalement tout est bien), même si j'ai assez peu apprécié la petite note en bas de la page qui explique qu'en fait personne n'a la moindre idée de pourquoi certains téléphones se font ainsi « briquer ». J'ai cependant affronté ma peur (en me disant que si ça m'arrivait, j'achèterais un kit JTAG pour faire joujou avec ce téléphone et/ou que j'en rachèterais un autre). Heureusement, tout s'est bien passé (j'ai suivi en gros le résumé fait par ce Monsieur) et je me suis retrouvé avec un téléphone sous CyanogenMod 6.1.0-DS.

Le passage d'Android 1.6 à 2.2 n'est pas bouleversant. C'est un peu plus lent mais pas catastrophiquement non plus (j'ai choisi d'activer la compilation just-in-time, je ne sais pas si c'était le mieux à faire), sauf pour certaines applications comme la nouvelle galerie (mais je m'en sers peu) qui a voulu faire des effets spéciaux malins en 3D qui ne servent à rien ; le navigateur, lui, semble plutôt plus rapide. Il y a quelques nouveautés en plus qui ont l'air intéressantes, comme le tethering (=utilisation du téléphone comme un modem) fourni par le système lui-même, et des petits raffinements pas mal dans l'interface (cinq écrans virtuels plutôt qu'un seul, les fonctions d'appel téléphonique et de lancement du navigateur toujours présentes à l'écran, la présentation des applications est mieux foutue, etc.) ; et pour les geeks qui s'en serviront, la ligne de commande a plus d'utilitaires de base (ils ont dû mettre un Busybox). L'application contacts est mieux faite, mais je vais y venir.

J'ai passé pas mal de temps à remettre les choses comme je les voulais, et à regretter de ne pas avoir noté scrupuleusement tous les réglages que j'avais. Il m'a fallu un peu de temps pour retrouver d'où venait le fond d'écran que j'utilise et auquel je m'étais attaché. Je n'ai pas remis en place ma liste d'appels ni mon archive de SMS, me disant que l'important pour un maniaque de la préservation de l'information comme moi est d'en avoir une copie sur mon ordinateur, pas forcément sur le téléphone lui-même.

Pour les contacts, j'ai eu plus de difficultés. La solution proposée par Google, c'est que tous les contacts sont synchronisés avec le compte Google de l'utilisateur, donc on ne les perd jamais. Personnellement, ceci me pose un problème : je n'ai rien contre le fait de donner mes informations personnelles à Google (elles sont de toute façon sur ma page Web, donc tout navigateur de recherche y a accès), mais je ne veux pas donner celles de mes amis sans leur autorisation. (Or il se trouve que j'ai pas mal d'amis qui se plaignent de la big-brother-itude de Google.) Donc je ne synchronise pas mes contacts avec mon compte Google (lequel, d'ailleurs, ne me sert quasiment qu'à faire du Google talk, et encore, plus trop depuis que mon poussinet n'a plus de smartphone). Mais alors, comment sauvegarder mes contacts ? Sur la nouvelle version d'Android, ils proposent la possibilité de les exporter au format vCard, ce qui n'est ma foi pas trop mal, mais l'ancienne n'avait pas cette possibilité, justement. J'avais plus ou moins prévu de taper directement dans les bases de données SQLite dans lesquelles ils sont stockés, mais la signature de la base de contacts a complètement changé entre les deux versions d'Android en question. Au final, je me suis dit que je perdrais plus de temps à faire les choses intelligemment qu'à rentrer à la main la quarantaine de contacts que j'ai dans mon téléphone, et à en profiter pour nettoyer et réorganiser les choses (qui a sa photo associée au contact, notamment, qui a quelle sonnerie, etc.). Une amélioration qui m'a plu, c'est que maintenant les contacts ont vraiment un prénom et un nom de famille, pas juste un nom indifférencié, et qu'on peut choisir de trier par prénom ou par nom de famille mais aussi d'afficher le prénom avant ou après le nom de famille. Le petit raffinement, c'est que si on trie par nom de famille mais qu'on affiche le prénom d'abord (ce que j'ai choisi), pour faciliter le repérage de la clé de tri quand on fait défiler la liste des contacts, le prénom s'affiche en plus sombre (il redevient clair quand la liste cesse de défiler) : comme ça on voit très clairement où on en est dans l'ordre alphabétique.

Mais bon, ce que je gagne surtout à cette mise à jour, c'est d'avoir maintenant plus de place disponible pour installer les applications (la mise à jour a repartitionné la mémoire flash, en attribuant moins de place à des choses qui ne servaient à rien du tout).

↑Entry #1853 [older| permalink|newer] / ↑Entrée #1853 [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]