Je viens de basculer mon fairphone 2 de Fairphone Open à /e/os plus ou moins suite au fait qu'il n'y aura plus de mises à jour (de sécurité) par Fairphone. Théoriquement /e/ prétend fournir encore au moins un an… à voir. Dépendra sûrement de ce qui est fait du côté de lineageOS. Et au passage on a android 11 (au lieu de 10).

Pour l'instant tout fonctionne bien. Les petits bugs que j'avais et qui étaient apparus au fur et à mesure des mises à jour ont l'air d'avoir disparu. Ils auraient sûrement disparu aussi en faisant une reset complet dans tous les cas mais tant qu'à faire et tout re-paramétrer, autant passer sur quelque chose qui aura des mises à jour.

Pour l'instant je suis plutôt content des choix faits par défaut. Le "launcher" (truc qu'on a en tant que "bureau") est un peu minimaliste mais bon. Et je trouve dommage que le navigateur par défaut soit un fork de bromite lui-même fork de chromium ; on reste donc sur du google quand-même (et du coup j'ai remis fennec).
Ils utilisent https://doc.e.foundation/app-lounge comme gestionnaire d'applications, qui permet de taper à la fois sur f-droid mais aussi sur le play store, soit avec son compte google soit en mode anonyme. Ça évite de se trainer un client f-droid et un aurora store pour les rares applis que j'utilise et qui sont que sur le play store.

Bref pour l'instant que du bon. Pas de révolution non-plus par rapport à l'OS d'avant qui était déjà dépourvu des gapps.

EDIT 26/06/23 : /e/os n'est pas vraiment dépourvu des gapps, un sous-ensemble y est via migroG. On a donc les messages push, la localisation dans les appli passant par les gapps etc. Signal par exemple n'a plus recours à sa tâche de fond et ne vide plus la batterie à cause de ça.

Je confirme que copier la DB SQLite mmssms.db et les data MMS à la main fonctionne encore, d'un android 4.4 vers un 7.1 en tous cas.
Par contre si l'appli était déjà lancée avant, les données n'étaient pas vues, j'ai dû reboot… je suppose qu'il y a un cache.

Une méthode de root des android sur processeur intel (x86) : injection d'un binaire via fastboot puis exéctution dudit binaire. Ici ce binaire enchaîne avec un autre, qui lui lance le cwm recovery (une "rom" recovery apparemment très utilisée et assez complète, que j'ai déjà utilisé sur mon téléphone).
Le post original sur xda-developers fournit un script windows, j'y connais rien mais ça se décortique pas trop difficilement (j'avais pas trouvé la page ci-liée avant, l'auteur a aussi traduit le script en quelques commandes shell…).
Pour moi donc :
adb reboot-bootloader
fastboot flash /tmp/recovery.zip /tmp/IntelAndroid-FBRL-07-24-2015/FB_RecoveryLauncher/cwm.zip
fastboot flash /tmp/recovery.launcher /tmp/IntelAndroid-FBRL-07-24-2015/FB_RecoveryLauncher/recovery.launcher
fastboot flash /sbin/partlink /tmp/IntelAndroid-FBRL-07-24-2015/FB_RecoveryLauncher/fbrl.trigger
fastboot oem stop_partitioning

À ce moment-là on est dans la recovery cwm, et on peut par exemple installer SuperSU ou tout autre zip d'installation. Et on peut aussi enfin faire des backup du système complet (boot, system, …) cas où… :)

Nouvelle adresse du debian kit (a changé à cause de dyndns, comme moi en fait) ? Drôle d'adresse. L'appli sur f-droid ne fonctionne plus vraiment non plus du coup.
Pour réinstaller après un wipe des data, il suffit de relancer la shar, qui se ré-extraiera et détectera qu'une image existe déjà donc ne la supprimera pas et ne lancera pas le debootstrap. Pour ensuite ré-intégrer les scripts au système, il suffit de faire :
/data/local/deb/mk-debian -u
Et voila, tout repart comme avant.

DriveDroid, c'est une petite appli android qui permet de faire apparaître l'ordinateur comme une clef USB contenant une ISO/image quelconque. Sauf que pas sur f-droid (mais apk dispo) et nécessitant forcément les droits root on hésite à l'utiliser sans plus de confiance que cela…
Sur ce lien, l'auteur a dit grosso-modo ce que l'appli fait (deux coups de echo dans des dev en gros) et ça marche ! Donc j'ai vite-fait écrit un petit script qu'on peut poser dans /system/bin par exemple :
vim /system/bin/usbloadfile
<CONTENU>
FILE=$1

if [ "$FILE" = "-u" ]; then
echo > /sys/devices/virtual/android_usb/android0/f_mass_storage/lun0/file
else
if [ -r "$FILE" ]; then
echo "mass_storage" > /sys/devices/virtual/android_usb/android0/functions
echo "$FILE" > /sys/devices/virtual/android_usb/android0/f_mass_storage/lun0
/file
else
echo "Non-readable '$FILE'"
fi
fi
</CONTENU>
chmod 750 /system/bin/usbloadfile

… et zou on a moyen de faire apparaître une ISO d'une distro par exemple, ou encore l'image d'un chroot Debian.

En pratique chez moi, je peux même "monter" deux fichiers, car j'ai lun0 et lun1 disponibles. Je sais pas trop comment ça marche par contre, d'avoir adb et deux fichiers sur le même port USB, mais c'est sûr que ça marche.

Un peu de doc sur l'API gadget : http://www.linux-usb.org/gadget/
Un how-to un peu plus prolixe que le lien shaarlié : http://www.linuxembedded.fr/2013/02/how-to-android-mass-storage-usb-gadget/
La page du projet DriveDroid : http://softwarebakery.com/projects/drivedroid

… et on peut même copier ce fichier depuis un backup, et zou ça repart avec l'historique. Pareil pour les contacts/appels avec /data/data/com.android.providers.contacts/databases/contacts2.db

Quand on a un debian en chroot, facile de voir ses SMS sur un téléphone android : il suffit de taper dans la base de données sqlite qui va bien :)
Et en plus on peut installer le binaire sqlite3 des paquets (et pas télécharger un truc foireux comme ici).
Exemple :
sqlite3 /data/data/com.android.providers.telephony/databases/mmssms.db
select * from sms where address = '+336xxxxxxxx';

C'est sûr que si on le sait pas… on va pas taper 7 fois sur un bouton au hasard.