Alors que nous ne savons toujours pas comment sera nommée la mouture qui succédera à Oreo (Pancake ou Pi, sacré dilemme), Google pourrait bien s’attirer les foudres des développeurs. À quelques mois de la grande révélation, de mauvaises surprises commencent à faire leur apparition. De nombreuses personnes surveillent les modifications apportées au code de base d’Android (AOSP), ne serait-ce que pour se tenir informés des nouveautés touchant le développement de l’OS au robot vert, et ont repéré des modifications pas forcément bien vues dans le monde des développeurs.
Google documente une grosse partie de son code, mais certaines interfaces de programmation ne le sont pas : il s’agit d’API cachées, marquées par l’attribut @hide et ne faisant pas officiellement partie du SDK. Pourtant, des applications font appel à ces interfaces, de par leur utilité et surtout par l’avantage technique offert en termes de fonctionnalités possibles par rapport aux API plus traditionnelles et publiques.
Une source de problèmes
Le site XDA rapporte que plusieurs commits ont été réalisés, dont un qui a fusionné avec la branche principale d’Android et introduit un nouvel outil ‘hiddenapi’ qui bloquerait purement et simplement cet accès en modifiant les flags de signatures renseignées sur les nouvelles listes restreintes. Ainsi, les applications exploitant ces API ne pourraient plus être lancées et le blocage serait même répercuté dans le logiciel de test (CTS) d’Android.
Rovo89, développeur bien connu, indique pour sa part que si ces changements venaient à être répercutés, cela ne serait pas un problème pour les modules Xposed puisque son logiciel peut facilement s’affranchir des règles établies. Il craint cependant que beaucoup d’applications soient concernées, obligeant des développeurs à mettre leur code en conformité ou à trouver une autre parade.
Google fait la loi
Ce n’est pas la première fois que Google se met à dos les développeurs avec ce genre de pratique : on se souviendra de la polémique des options d’accessibilité lorsque le géant a instauré une nouvelle politique interdisant l’usage abusif de ces services réservés aux handicapés pourtant intégrés dans certaines applications en faisant un usage initialement pas prévu pour.
On peut se demander si la firme ne chercherait pas à se réserver un usage exclusif d’API privilégiées pour imposer un peu plus ses GApps, qui seraient alors plus fonctionnelles par rapport à la concurrence devant se rabattre sur des API classiques. D’autres pistes pointent davantage vers un souci de sécurité. Par cette action, Google obligerait les fabricants — car cette mesure ne s’appliquerait pas qu’aux petits développeurs — à n’utiliser que les API autorisées, assurant compatibilité et stabilité dans le cadre de mises à jour unifiées, où l’image système unique ne viendrait pas corrompre la partition du fournisseur.
Mais sait se montrer indulgent
Fort heureusement, une souplesse a été instaurée le mois dernier pour les applications reposant sur les services d’accessibilité, permettant aux développeurs de se justifier sur la nécessité de cette permission.
Dans le cas présent, un commit montre que Google réfléchit à des solutions pour ne pas laisser les développeurs dans l’impasse, avec notamment un système qui suggérerait des alternatives à ces API cachées. Reste à voir comment tout cela sera géré dans la version finale d’Android P.
Des invités passionnants et des sujets palpitants ! Notre émission UNLOCK est à retrouver un jeudi sur deux en direct, de 17 à 19h sur Twitch. Pensez aussi aux rediffusions sur YouTube !
Un article et avis intéressant (en anglais) avec des explications sur le sujet https://commonsware.com/blog/2018/01/18/think-hard-about-hide.html ?
Sans oublier le fait qu'en utilisant des APIs non documentées on a aucune garantie qu'elles fonctionnent à l'identique d'une version d'Android à l'autre (ou même simplement continuent d'exister, exemple setMobileDataEnabled(), supprimée à partir d'Android 5). il me semble légitime qu'il existe des APIs exclusivement destinées à être invoquées entre différentes composants interne de l'OS mais cachées de façon à permettre de les faire évoluer de façon potentiellement non compatible quand ça s'avère nécessaire. Je conçois que ça puisse être frustrant pour certains devs mais quand on utilise des fonctions non documentées on doit le faire en connaissance de cause en sachant qu'on n'est plus en position de reprocher l'absence de compatibilité ascendante.
Classique de Frandroid. Google joue avec leur patience chaque année, ils n'en peuvent plus
A croire que le root a encore de beau jours devant lui
Effectivement, il ne faut pas voir le mal partout. Ce choix semble justifié et judicieux. Merci pour ton commentaire détaillé :)
il en existait deux excellentes: BB10 et Windows mobile, pour les avoir testé. mais bon, snapchat, n'était pas compatible....
A voir ce que cela concerne exactement
Bof moi le projet Librum avec un vrai linux mobile, ça peut être une alternative crédible pour moi. Les parts de marchés je m'en fout perso. Ça fait moins de virus qui viennent se focaliser dessus en plus.
"Alors que nous ne savons toujours pas comment sera nommée la mouture suivante d'Android" Clair, jsuis au bout de ma vie et au bord du suicide a cause de ça ^^
et vu la position dominante de ces 2 OS une alternative crédible n'est pas prêt d'arriver...
Ce contenu est bloqué car vous n'avez pas accepté les cookies et autres traceurs. Ce contenu est fourni par Disqus.
Pour pouvoir le visualiser, vous devez accepter l'usage étant opéré par Disqus avec vos données qui pourront être utilisées pour les finalités suivantes : vous permettre de visualiser et de partager des contenus avec des médias sociaux, favoriser le développement et l'amélioration des produits d'Humanoid et de ses partenaires, vous afficher des publicités personnalisées par rapport à votre profil et activité, vous définir un profil publicitaire personnalisé, mesurer la performance des publicités et du contenu de ce site et mesurer l'audience de ce site (en savoir plus)
En cliquant sur « J’accepte tout », vous consentez aux finalités susmentionnées pour l’ensemble des cookies et autres traceurs déposés par Humanoid et ses partenaires.
Vous gardez la possibilité de retirer votre consentement à tout moment. Pour plus d’informations, nous vous invitons à prendre connaissance de notre Politique cookies.
Gérer mes choix