LE JOURNAL
Choisissez une date pour retrouver les articles complets publiés ce jour-là.
Chargement des archives…
Basée sur Android 17, la version 24.0 de LineageOS est arrivée en environ quatre mois, contre six auparavant. À l’approche des dix ans du projet, nous avons interrogé l’un des contributeurs historiques sur la dépendance à Google, le verrouillage des bootloaders et le sort des appareils les plus anciens. Longtemps vu comme le successeur de CyanogenMod réservé aux passionnés, LineageOS s’affirme aujourd’hui comme une façon concrète de prolonger la vie d’un smartphone délaissé par son constructeur. Mais les choses sont devenues moins faciles qu’avant Google ne publie plus les device trees et les binaires des Pixel dans AOSP, déploie la vérification des développeurs, et plusieurs marques verrouillent leurs bootloaders. Nolen Johnson, développeur et mainteneur de plusieurs appareils au sein du projet, a répondu à quelques-unes de nos questions. Il explique comment LineageOS s’adapte, ce qu’il garantit en matière de vie privée et comment le soutenir.Pour les lecteurs qui ne connaissent LineageOS que de nom, comment décririez-vous le projet aujourd’hui, à l’approche de ses 10 ans ? Que représente-til pour ceux qui veulent simplement garder leur téléphone en vie et fonctionnel ? Je dirais que LineageOS est un système d’exploitation Android open source, porté par une communauté, qui donne aux gens plus de contrôle sur leurs appareils et qui prolonge leur durée de vie. À l’approche de nos 10 ans, je pense que LineageOS est devenu bien plus qu’une ROM alternative pour passionnés ou qu’un simple successeur de CyanogenMod. C’est un effort au long cours pour montrer que la vie d’un appareil ne doit pas forcément s’arrêter quand son constructeur décide de ne plus fournir de mises à jour. On le retrouve aussi dans des projets IoT et embarqués vraiment sympas. Il paraît même que beaucoup d’écrans connectés des transports publics polonais tournent sous LineageOS ! LineageOS 24.0 est sorti plus tôt que d’habitude. Qu’est-ce qui a permis au rebase vers Android 17 d’aller plus vite que prévu, et qu’est-ce que les utilisateurs vont remarquer en premier ? On s’améliore, tout simplement. Avant, on voyait arriver les nouvelles versions d’Android en septembre et on publiait en mars ou en avril, soit environ six mois plus tard. En simplifiant nos processus et grâce à nos ajouts, on a vu arriver Android 17 en juin et on a publié en octobre, soit environ quatre mois. Ça n’a rien à voir avec la vitesse du rebase, mais ce que les utilisateurs verront d’abord, c’est notre nouvel assistant de configuration, entièrement redessiné. Il reprend le design MD3E (Material Expressive) avec plein de jolies animations. On a aussi remis à jour une bonne partie de notre suite d’applications et ajouté une nouvelle application de retouche d’images. Le projet dépend de l’AOSP, que Google contrôle. Google ne publie plus les device trees et les binaires de pilotes des Pixel dans AOSP, et pourtant votre rebase vers Android 17 s’est bien passé. Comment voyez-vous cette dépendance aujourd’hui, et menace-t-elle votre indépendance à plus long terme ? Ça veut simplement dire que les Pixel sont désormais des appareils comme les autres. Ils restent assez proches de l’AOSP pour qu’on ait des scripts qui calculent et appliquent une bonne partie des différences entre deux builds, donc c’est parfois un peu plus simple que sur d’autres appareils, parfois un peu plus compliqué. Perdre la référence, c’est dommage. Et devoir demander chaque mois le code source du noyau de chaque appareil via un formulaire, auquel Google met un temps fou à répondre, c’est vraiment pénible. Mais c’est tout à fait faisable, et je ne vois pas ça changer de sitôt. Devices trees : ensemble de fichiers qui décrivent le matériel d’un appareil (processeur, écran, capteurs, partitions, etc.). Ils permettent de compiler Android pour ce modèle précis. Plusieurs personnes installent LineageOS pour des raisons de confidentialité. Que garantit réellement le projet sur ce point, et où les attentes des utilisateurs dépassent-elles, selon vous, ce qu’une ROM dégooglisée peut offrir ? Pour être clair, on ne se présente pas comme une ROM dégooglisée ». Certains projets le font, mais nous, on ne retire pas Google là où AOSP l’intègre, par exemple pour le DNS ou le portail captif. On ne livre simplement pas les applications GMS (Google Mobile Services). Les utilisateurs peuvent les installer euxmêmes, ou passer par MicroG, l’alternative libre, tout aussi bien prise en charge, qui permet à beaucoup de ces applications de fonctionner. On ne collecte pas de données sur les utilisateurs. La seule chose qu’on récupère, c’est votre build string et votre région générale (continent ou pays), sauf si vous refusez dans l’assistant de configuration. C’est tout, rien de plus. Ce qui est génial avec ce projet, c’est que chacun peut l’alléger ou le modifier comme il veut, et donc régler sa confidentialité au niveau qui lui convient. Google déploie la vérification des développeurs et de nouvelles règles sur le sideloading, et de moins en moins de constructeurs autorisent le déverrouillage du bootloader. Comment voyez-vous l’impact de ces changements sur LineageOS et ses utilisateurs ? La vérification des développeurs ne nous touche pas directement. On n’intègre pas l’application qui s’en charge et on ne le fera jamais. Les gens qui packagent les applications Google (MTG, NikGapps) ne l’intégreront pas non plus. Ce n’est donc pas un problème pour nous. Si quelque chose doit changer, je pense que ça va plutôt nous amener des utilisateurs. Quand les gens ne pourront plus faire ce qu’ils veulent avec la ROM d’origine, ils finiront par installer LineageOS. Le déverrouillage du bootloader, en revanche, c’est celui qui fait mal. Si on ne peut pas déverrouiller, on ne peut pas installer, et ça arrive parfois sur des appareils qu’on supporte déjà. Regardez ce que Samsung a fait avec la mise à jour OneUI 8, qui a verrouillé les bootloaders de force. Des exploits pour contourner ça sortent de temps en temps, mais ils ne sont pas toujours fiables. On ne peut prendre en charge que les appareils capables de faire tourner notre système. La bonne nouvelle, c’est qu’il reste beaucoup de constructeurs qui jouent le jeu : Google, Motorola, AYN, OnePlus, SHIFT, Fairphone, Lenovo, Nubia, Nothing, NVIDIA, Razer, etc. Ça fait beaucoup d’options. Comment conciliez-vous le support à long terme des appareils anciens avec les blobs propriétaires et les correctifs que les constructeurs ne fournissent plus, maintenant que les nouvelles soumissions 24.0 pour les appareils sous noyau 4.4 et 4.9 sont fermées ? Linux 4.4 est sorti en janvier 2016. Dix ans, c’est plus du double de ce qu’on attend aujourd’hui en matière de support, à savoir cinq ans. Et on ne les a pas lâchés de gaieté de cœur. Le nombre de bidouilles de plateforme et de rustines propres à chaque appareil qu’il fallait traîner était devenu trop important. Elles entraient en conflit avec les correctifs de sécurité et les QPR tous les mois ou tous les deux ou trois mois. En plus, le nombre d’utilisateurs de ces appareils diminue avec le temps. Ça ne veut pas dire que ces appareils ne sont plus supportés ! Les noyaux 4.4 et 4.9 continuent de vivre sur LineageOS 22.2, où l’on intègre toujours les correctifs de sécurité mensuels de Google, où l’on publie des builds et où l’on accepte de nouveaux appareils. À partir d’un certain point, ces appareils deviennent aussi poussifs et manquent de ressources pour faire tourner la dernière version d’Android. QPR (Quarterly Platform Release) : mise à jour trimestrielle d’Android publiée par Google entre deux versions majeures. Elle apporte des correctifs et parfois des nouveautés, et oblige les projets comme LineageOS à adapter leur code régulièrement. Pourvoir flasher directement depuis un navigateur web, cela facilite quand même bien les choses, même si le déverrouillage du bootloader reste nécessaire. Pensez-vous pouvoir toucher un public plus large, et êtes-vous prêts à gérer la charge de support qui va avec ? Si vous avez un appareil Fastboot, ODIN ou AMLogic, on permet aussi de déverrouiller le bootloader depuis le navigateur, à condition que votre constructeur prenne en charge les procédures de déverrouillage habituelles. Ça va clairement rendre la démarche plus accessible, puisqu’il y a moins de pilotes à installer et moins de configuration à faire sur l’ordinateur. On est tout à fait prêts à accueillir plus d’utilisateurs. Regardez notre page stats.lineageos.org : on en a déjà énormément !
Source : Transaction d’Algérie