Android P pourrait bloquer l’accès à certaines fonctions de développement

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.