Désactivation de l’application « Zen Mode » de OnePlus

Un nouvel article pense-bête concernant la désactivation d’une application android sur la base des informations apportées par lord dans « Épurer un téléphone android« . Utilisant un smartphone de la marque OnePlus depuis un peu moins d’un an, j’avais noté l’intérêt des manipulations, mais sans franchir le pas, la couche oxygenOS présente sur les OnePlus m’ayant toujours semblé minimale et non intrusive… jusqu’à cette semaine.

Il y a de cela quelques jours, une nouvelle version de l’application OnePlus « Zen Mode » s’est mis à m’envoyer des notifications pour participer à des défis dont l’objectif est de ne pas utiliser le téléphone pendant une certaine durée. A cela s’est ajouté une autre notification m’informant que j’utilise beaucoup mon téléphone dernièrement, alors que je ne m’en étais pas servi depuis plusieurs heures. Pour la pertinence, on repassera. Bref, notifications non désirées égale désactivation. Impossible néanmoins de désactiver l’application dans les menus android, ni de forcer son arrêt. J’ai donc sorti l’artillerie lourde.

Première étape, installer android-tools pour avoir accès à la commande adb et pouvoir se connecter au téléphone. Ensuite, activer le mode de débogage USB, pour cela, se rendre dans « A propos du téléphone », puis cliquer plusieurs fois sur « Numéro de build » jusqu’à l’apparition du message « Vous êtes désormais un développeur ! », qui nécessite de saisir le code de verrouillage du téléphone avant affichage du message. Les « options pour les développeurs » sont désormais accessibles dans le menu « Système » et il devient possible d’activer l’option « Débogage USB » présente dans la sous-catégorie « Débogage ».

Une fois cela fait, un appel à la commande adb shell nous permet de disposer d’une ligne de commande exécutant les instructions sur le système du téléphone. A noter qu’en cas de première connexion, il faut autoriser la connexion entrante sur votre téléphone, pour valider la demande de connexion de l’ordinateur. La liste des applications installées s’obtient via pm list packages. Une fois les applications que l’on souhaite désactiver repérées, dans mon cas, l’application zen mode, nom de code com.oneplus.brickmode, on peut passer à la désactivation:

pm disable-user --user 0 com.oneplus.brickmode

Il est également possible d’aller plus loin qu’une simple désactivation en procédant à la désinstallation pure et simple (ce que j’ai finalement fait):

pm uninstall --user 0 com.oneplus.brickmode

J’en ai profité pour désactiver aussi :

com.android.chrome
com.google.android.googlequicksearchbox
net.oneplus.weather

Bref, continuer à garder un téléphone qui fait ce que je lui demande quand je lui demande, et qui ne cherche pas à induire des comportements ou à s’imposer à mon attention lorsque je ne l’ai pas choisi.

Logs Android via adb

Avec le téléphone connecté en USB et le débogage activé, il est possible d’avoir accès aux logs du système en temps réel avec la commande adb logcat, à laquelle on pourra passer le paramètre -v color afin de disposer d’une coloration des logs par sévérité.

adb logcat -v color

Pour filtrer les résultats et n’afficher que les logs de certains services, on ajoutera la liste des services désirés en suivante la forme <nom-du-service>:<niveau-de-verbosité>. Ce qui nous donne par exemple, pour n’afficher que les logs des services NFC :

adb logcat -v color "NfcService:V NativeNfcTag:V *:S"

Ou encore, pour afficher toutes les erreurs :

adb logcat *:E

Qui nous donne :

10-21 22:26:53.699 25006 25006 E android.hardware.nfc@1.0-impl: hw_get_module nfc_nci failed: -2
10-21 22:26:53.699 25006 25006 E android.hardware.nfc@1.0-impl: Passthrough failed to load legacy HAL.
10-21 22:26:53.700 25006 25006 E android.hardware.nfc@1.0-service: Could not get passthrough implementation for android.hardware.nfc@1.0::INfc/default.

Ce qui laisse à penser que le NFC n’est pas prêt de fonctionner correctement avec ma YubiKey sur ma custom rom.

Pour toutes les autres options de la commande logcat, direction la documentation !

TWRP récent pour Xperia Z1

J’ai voulu tester dernièrement une rom custom Android 9 pour mon Z1 vieillissant. Problème, la version de TWRP, programme installé sur mon téléphone de test était trop vieille pour pouvoir prendre en charge l’installation d’une rom aussi récente. Autre obstacle, TWRP n’a pas été mis à jour depuis fin 2016 pour mon appareil.

Je me suis donc tourné vers une version non officielle, résultat d’un portage de la version 3.2.3-0 pour le Z1. Version trouvée sur xdadevelopers. Une fois installée, j’ai donc pu procéder au déploiement d’une version beta de Android 9 sur mon appareil, portée par CarbonROM.

Je n’ai pas testé très longtemps. La ROM semblait stable, mais avec quelques problèmes bloquants, notamment du côté de l’appareil photo et de la connexion WiFi. Et toujours pas moyen d’utiliser des clés PGP sur une YubiKey via le NFC.

[Android] Flasher le recovery avec fastboot

Un grand nombre de site préconise d’utiliser une application disponible sur le PlayStore pour flasher le recovery d’un téléphone Android.

Ce que peu d’entre eux précisent, c’est qu’il est possible de réaliser cette opération directement en ligne de commande avec fastboot. Une fois l’appareil en mode « bootloader », il est donc possible d’utiliser la commande suivante (Exemple générique pour TWRP) :

fastboot flash recovery twrp-2.8.x.x-xxx.img

La dernière version de TWRP pour le Sony Xperia Z1, nom de code honami est ici : twrp-3.0.2-0-honami.img.

Téléphone, sécurité et mise à jour. C’est le bordel…

Mon téléphone actuel est un Xperia Z1 de marque Sony. Première apparition sur le marché en 2013, j’utilise le mien depuis presque trois années, autant dire une éternité pour un téléphone « moderne ». J’ai arrêté les téléphones vendus par les opérateurs depuis un bout de temps : rien à cirer de la surcouche opérateur ajoutant son lot d’applications inutiles et difficiles, voir impossible à désinstaller. Dans le cas de mon Z1, nous étions donc sur un téléphone constructeur, que je n’ai pas tardé à rooter, pour y faire tourner une ROM alternative, en l’occurrence CyanogenMod en version Nightly et en partie libérée de Google avec freecygn.
Que dire de plus si ce n’est que, pour le moment, il fonctionne parfaitement. Mais, …

Car il y a bien un mais. Le constructeur a arrêté les mises à jour d’Android à la version 5.0.2 en juin 2015 soit à peine plus de 2 ans après la sortie du téléphone. Au revoir mise à jour de sécurité via le canal officiel.  A cette époque, je faisais encore le malin puisque je venais de mettre à jour Cyanogen vers sa version 12-1 soit un Android 5.1.1. C’est ici que s’arrête l’histoire pour les mises à jour. Quelques commits ont eu lieu sur une branche cm-13.0 du dépôt Git, mais pas de builds officiels. Et cela ne risque pas de s’améliorer puisque CyanogenMod a cessé d’exister en décembre 2016. La communauté a repris le projet sous le nom LineageOS, mais l’âge du téléphone n’y changera rien, il y a peu de chance que j’obtienne un binaire pour mettre à jour ou remplacer mon système vers une version récente d’Android.

En parallèle, de nombreuses failles qui se sont succédées, surtout pour 2016, parmi lesquelles de nombreuses failles critiques. Youpi, mon téléphone est donc tout troué du point de vue de la sécurité. Du côté d’Android, il faut noter que nous sommes face à un système qui se ferme de plus en plus. L’article The proprietarization of android google play services and apps nous apprend par exemple que de nombreuses fonctionnalités de base, sont progressivement déplacées du système en lui-même vers le Google Play Services. Il devient alors toujours plus difficile de faire fonctionner des applications sans ce composant, si on a fait le choix de s’en passer, ou si le système ne l’intègre pas (Jolla Sailfish, …). Une alternative semble toutefois se dessiner avec le projet microG.

Bref, je n’ai pas envie d’acheter un nouveau téléphone au prix d’un ordinateur, alors que mon téléphone actuel continue de fonctionner. Du côté sécurité, Apple ne semble pas s’en tirer trop mal, mais les prix sont prohibitifs et je reste réfractaire à l’environnement IOS qui vient avec.

Quelles alternatives alors ?

  • Qu’on ne me parle pas de Windows Phone. Ça ne me tente pas du tout. Les ajouts de type surveillance de l’utilisateur me disent de rester loin de la plateforme mobile de Microsoft en tant qu’utilisateur.
  • Un téléphone chinois pour moins de 100E ? Pourquoi pas, mais à condition d’être certain qu’il n’y ai pas de backdoor. Par ailleurs, le problème des mises à jour n’arrivant plus risque de rester le même et on se retrouve donc à jeter un appareil fonctionnel pour faire tourner la machine économique. On garde donc dans un coin l’idée du téléphone chinois de transition à prix réduit; avec le moins possible de Google dedans ou en remettant une custom rom directement.
  • Le Neo900 encore en cours d’élaboration. Principe très attractif car séparation matérielle du modem et du CPU, l’alimentation du modem pouvant être désactivée (si j’ai bien suivi). Relativement inaccessible de par son prix (Environ 990E , même si réparti sur plusieurs années, cela pourrait se justifier). OS disponible relativement flou pour l’instant. Quelles possibilités ?
  • Dans la même idée, le GTA04.
  • Jolla. Les infographies semblaient proposer quelque chose d’un peu nouveau. Ils se sont plantés avec les tablettes, donc ils se concentrent sur le soft. Une base Linux. Plus de stock de téléphone au moment où j’écris ces lignes. Une entreprise indienne a produit quelques téléphone embarquant le système d’exploitation Jolla pour le marché indien. La poste Russe a annoncé vouloir acquérir des téléphones tournant sous Sailfish OS.
  • Ubuntu Phone. Pas vraiment de stock.
  • Une Fairphone ? Un téléphone plus « éthique » dans ses choix, pourquoi pas, mais le problème de version reste le même. Ici, du Android 5.1. Pour le prix, compter au moins 500E.
  • Construire sa propre ROM en se basant sur AOSP et sur la documentation Sony. Cela semble plutôt bien expliqué et cela me permettrait de mettre en application ce que j’avais eu l’occasion d’apprendre en cours.

Bref, beaucoup de solutions envisageables. Et pourtant, il n’y en a pas une qui me satisfait plus que les autres. D’ailleurs, plus j’y pense et et plus l’idée de mettre les mains dans le cambouis m’attire. Je vois d’ici les heures de travail pour préparer l’environnement de développement, adapter et compiler les sources, puis tester. Le résultat est incertain, l’échec possible, mais voyons le bon côté des choses, la documentation du constructeur semble plutôt complète, il existe quelques dépôts libres sur Github et je ne pars pas de zéro puisque j’ai eu la chance de suivre un cours sur le sujet durant mes études d’ingénieur (LO52 – Merci Fabien !). J’ai donc commencé à lire la documentation et à parcourir les forums, notamment XDA pour mon modèle de téléphone, et ce qu’on peut y lire a de quoi refroidir. A priori, en passant à Android 7, il y a un risque non nul de se retrouver avec un port micro-usb ne rechargeant plus la batterie du téléphone, ce qui est quand même un inconvénient majeur. Par ailleurs, ce qui m’ennuie le plus, c’est d’être obligé de tester directement sur le téléphone que j’utilise quotidiennement. L’idéal serait de mettre la main sur un deuxième exemplaire du téléphone à peu près en état de marche afin de disposer d’une plateforme de test.

Finalement, le problème est intrinsèquement lié au fonctionnement actuel de notre société, basée sur une consommation de masse permanente. Dans ce contexte, un constructeur renouvelle complètement sa gamme en 2 à 3 ans. Au revoir support sur les anciens modèles, les équipes sont assignées à la maintenance de la gamme en cours. Obsolescence par le logiciel donc, le matériel évoluant assez peu, mise à part les ajouts de RAM, puissance de calcul ou nombre de pixel de l’appareil photo. Tout cela pour vider la batterie plus rapidement, bien évidemment.

Pour ma part, je vais donc garder mon téléphone en Android 5.1 pour l’instant et voir comment les choses évoluent.