- Google a publié le code source d’Android 16 dans l’AOSP, mais n’a pas rendu public le dépôt matériel Pixel
- L’absence de publication des arbres d’appareils Pixel et du code associé a fait naître, dans une partie de la communauté, des soupçons de « fin de l’AOSP »
- Google a officiellement démenti en affirmant que « l’AOSP ne sera pas abandonné », et a réaffirmé qu’il continuerait à publier et mettre à jour le code source de l’AOSP
- À l’avenir, l’AOSP visera une cible de référence (reference target) non liée à un matériel existant, avec une transition vers des appareils virtuels / appareils généralisés (GSI) comme Cuttlefish, plus flexibles et moins coûteux
- Cela pourrait compliquer les mises à jour d’OS et les travaux de recherche pour les développeurs de ROM custom et les chercheurs en sécurité
Lancement d’Android 16 et controverse autour de la publication du code source
- Avec la sortie d’Android 16, Google n’a pas publié le dépôt matériel Pixel ni le code des Device tree
- Jusqu’à présent, le code destiné au matériel Pixel était fourni avec l’AOSP et jouait un rôle essentiel dans le développement de ROM Android custom
- En conséquence, il est prévu que les développeurs de ROM custom et les chercheurs en sécurité rencontrent davantage de difficultés pour le développement d’OS custom, les mises à jour vers les dernières versions d’Android et la recherche sur les vulnérabilités de sécurité
Position officielle de Google sur l’AOSP
- Une rumeur selon laquelle « l’AOSP allait disparaître » a circulé dans une partie de la communauté, mais Seang Chau, VP de la division Android, l’a officiellement démentie en déclarant :
- « L’AOSP ne disparaît pas »
- « Nous restons engagés à continuer les mises à jour de l’AOSP »
- Cependant, la réponse officielle de l’équipe Android laisse entendre qu’elle ne fournira plus à l’avenir les arbres d’appareils Pixel et éléments similaires
- La cible de référence (reference target) fournie par l’AOSP visera désormais une forme indépendante d’un matériel spécifique
- L’objectif est un appareil de référence flexible, configurable et peu coûteux, sans lien avec un matériel particulier, y compris ceux de Google
- Depuis des années, la communauté utilise des cibles Cuttlefish (appareil de référence) et GSI compilées depuis les sources pour les tests et le développement
- Ces appareils de référence continueront d’être mis à disposition des développeurs
Impact sur les ROM custom et la communauté de la sécurité
- Google souligne officiellement sa volonté de continuer à soutenir l’AOSP
- Mais avec la disparition de la prise en charge matérielle directe, il est probable que le développement, la maintenance des ROM custom et la recherche en sécurité deviennent nettement plus difficiles, avec une barrière à l’entrée en forte hausse
1 commentaires
Réactions sur Hacker News
Vous me trouverez peut-être bizarre, mais la seule raison pour laquelle j’ai acheté un Pixel récemment, c’était avec l’intention d’y installer GrapheneOS immédiatement après l’achat. Jusqu’ici, l’expérience me satisfait vraiment. J’essaie d’éviter autant que possible tout ce qui est lié à Google, sauf si c’est pour le travail. Il y a trop de choses que je n’aime pas chez Google. Bien sûr, Google n’a pas l’obligation de continuer à fournir ces blobs binaires, mais je suis encore une fois déçu de les voir arrêter brutalement, sans préavis, quelque chose qu’ils faisaient depuis longtemps. À mon avis, ils auraient dû prévenir suffisamment à l’avance, comme pour l’arrêt de nombreux autres services. Je comprends aussi que continuer à distribuer ces binaires et en garantir le fonctionnement représente une charge supplémentaire, mais eux doivent de toute façon faire ce travail en interne. J’imagine que Google a fait un choix stratégique : accepter de perdre de l’argent sur certains appareils achetés pour GrapheneOS, afin de se concentrer sur ce qui rapporte ensuite via un écosystème fermé, le data mining, la publicité, etc.
J’ai acheté un Pixel exactement pour la même raison. Maintenant que tout le monde sait qu’on est pisté à presque tous les niveaux, flasher un Pixel avec GrapheneOS dès l’achat me semble être le choix le plus sensé. Tous les téléphones de notre foyer (celui de ma femme et le mien) sont utilisés comme ça. Pas besoin de se soucier de Play Services, des apps Google, de Facebook ou autre. Je n’ai pas envie que ma vie fasse partie du ciblage publicitaire ni de données dont on ne sait pas à quoi elles serviront plus tard. Ce qui m’étonne surtout, c’est qu’autant de gens soient à ce point insensibles à la question de la vie privée
Évaluation indulgente. Je fais pareil
J’ai un point de vue un peu différent sur l’affirmation selon laquelle « Google a arrêté de fournir les binaires sans prévenir suffisamment à l’avance ». Se reposer sur un comportement non documenté puis protester quand il change, c’est étrange. En tant qu’ingénieur logiciel, éviter de dépendre de ce genre de chose devrait relever du bon sens. Si quelqu’un utilisait un Pixel comme presse-papiers puis ne pouvait plus le faire à cause du bloc caméra qui dépasse, ce serait pareil : ce ne serait pas vraiment la faute de l’entreprise
Je garde un vrai sentiment de gratitude envers le fait qu’on pouvait acheter du matériel grand public réel comme les Pixel (ou les Nexus autrefois), récupérer AOSP et les blobs propriétaires, et produire sans effort particulier une build où tout le matériel fonctionnait. Cuttlefish est peut-être un appareil de référence plus efficace, mais ce n’est pas la même chose que la polyvalence d’un Pixel qu’on peut aussi utiliser pour GrapheneOS et d’autres usages. Faire tourner sur un vrai appareil un Android compilé de ses propres mains a un attrait qu’une VM ne peut pas offrir
Je pense que GrapheneOS a exagéré le problème et s’est tiré une balle dans le pied — effet « garçon qui criait au loup ». Pour l’entreprise, il est facile de répondre à des critiques dont la fausseté est évidente. Les affirmations du type « Google is killing AOSP » attirent l’attention, mais elles sont aussi trop faciles à démonter pour l’entreprise. Ce qui se passe ici, c’est que GrapheneOS obtenait des blobs binaires grâce à la bonne volonté de Google, et comme Google n’avait aucune obligation, ils ont simplement arrêté pour leurs propres raisons. En plus, comme GrapheneOS a évoqué des questions juridiques et de monopole, les développeurs s’en sont sans doute complètement écartés, laissant l’affaire au service juridique
Je serais curieux de savoir ce qui a été exagéré précisément. Qu’est-ce qui est faux ? En quoi GrapheneOS aurait déjà fait ça par le passé ? Quelle partie, exactement, a posé problème ?
Je pense que cet épisode va amener GrapheneOS à prendre en charge une gamme d’appareils plus large que les seuls Pixel. À vrai dire, ils auraient déjà dû le faire, et même sans cette excellente prise en charge matérielle, cela resterait de toute façon massivement plus sûr qu’Android stock
Je ne pense pas qu’il soit nécessaire de défendre activement Google alors qu’il s’agit de facto de l’un des deux acteurs en situation de quasi-monopole
J’ai toujours craint que, sans les dépôts matériels Pixel (device trees, binaires de pilotes, etc.), il devienne très difficile pour les ROM Android custom de développer les mises à jour du système. Cela pourrait aussi avoir un impact sur la recherche en sécurité
Sans GrapheneOS, je passerais probablement à l’iPhone. J’utilise GrapheneOS depuis longtemps et j’adore cette sensation légère et simple, sans les éléments Google superflus. Désormais, le Pixel officiel de Google ne me convient plus
Encore une entrée de plus dans le Google Graveyard. Si je ne peux plus le contrôler moi-même, je n’ai plus de raison d’utiliser un Pixel. Je vais réessayer l’iPhone, en acceptant ses inconvénients pour profiter de ses nombreux avantages
Je pense immédiatement à la réponse du type : « AOSP est toujours vivant, on peut toujours l’utiliser via l’émulateur ». L’article dit : « Pendant des années, les développeurs ont utilisé Cuttlefish (voir la référence GitHub) et la cible GSI, compilés depuis les sources, comme références. Cela continuera à être fourni à des fins de test et de développement. » Je débute sur AOSP, donc j’aimerais connaître le point de vue de la communauté : est-ce que ce genre d’appareils de référence est réellement exploitable pour développer des ROM custom, ou est-ce surtout un argument de façade ?
Je me demande si ce n’est pas précisément pour cela que GrapheneOS fonctionnait si bien sur les Pixel. J’espère qu’une fois les obstacles initiaux franchis et les changements clés compris, cela pourrait au contraire ouvrir la voie à la prise en charge de davantage d’appareils
Ce n’est vrai qu’en partie. D’après la FAQ officielle, les principales raisons sont : (1) des fonctions de sécurité matérielle de tout premier plan, comme le memory tagging, (2) la rapidité de diffusion des correctifs, et (3) un support officiel de longue durée
Ou alors, ce changement pourrait au contraire conduire GrapheneOS à ne plus prendre en charge de nouveaux appareils
GrapheneOS était la seule raison pour laquelle j’achetais des Pixel
C’est un peu redondant lien connexe