Selon un ensemble de commits dans AOSP, Google pourrait commencer à restreindre l'accès aux API non documentées ou cachées dans Android P. De nombreuses applications de marque utilisent des API cachées pour augmenter les fonctionnalités, l’effet peut donc être généralisé.
Mise à jour 28/02/18: Google a publié aujourd'hui un article de blog confirmant les changements. Plus de détails en fin d'article.
Alors que certains passionnés d'Android sont spéculer De quel dessert la prochaine version d'Android portera le nom, des développements intéressants se déroulent en coulisses. Nous avons repéré un peu dignes de mention fonctionnalités à venir dans Android P, mais une découverte plus récente dans le projet Android Open Source (AOSP) s'est avérée bien plus intéressante. Selon ces commits récents, les applications peuvent être empêchées d'accéder aux API qui ne sont pas documentées dans le SDK Android (telles que les API marquées par l'attribut @hide de javadoc).
Pourquoi c'est important
Le kit de développement logiciel (SDK) Android fournit aux développeurs les bibliothèques d'API et les outils dont ils ont besoin pour tester et créer de nouvelles applications Android. Chaque nouvelle version d'Android s'accompagne d'une multitude de nouvelles API disponibles pour les développeurs via le SDK Android. Les API disponibles pour une application dépendent de la version compileSDKVersion définie par le développeur. C'est pourquoi Google
nouvelles exigences du Play Store sont si importants qu'ils obligeront les applications à se mettre à jour et à migrer vers des API plus récentes.Hébergeurs Google pages de documentation pour chaque classe et toutes ses méthodes disponibles dans chaque niveau d'API. Il s'agit de l'ensemble des API documentées disponibles dans le SDK Android officiel. Vous pouvez facilement parcourir la liste des classes à l'aide d'une application Android telle que l'application Android SDK Search récemment publiée par Android Engineer. Jake Wharton.
Prix : Gratuit.
4.1.
Cependant, toutes les API disponibles dans chaque version d'Android ne sont pas documentées par Google ou disponibles dans le SDK Android officiel. Il existe souvent des API utiles sans papiers, mais sont néanmoins très utiles. Il n'est pas recommandé aux développeurs de créer leurs applications à l'aide d'API non documentées ou cachées, mais beaucoup le font parce qu'il n'y a tout simplement pas d'alternative s'ils souhaitent offrir une certaine fonctionnalité. Les développeurs qui utilisent des API cachées ou non documentées peuvent également bénéficier d'un avantage concurrentiel. puisqu'ils peuvent proposer des fonctionnalités que leurs concurrents, qui s'en tiennent aux API proposées par Android SDK: impossible.
Bien que je ne puisse pas fournir une liste d'applications qui utilisent des API non documentées (les développeurs ne partagent probablement pas lesquels ils utilisent parce que cela donnerait un avantage à leurs concurrents), la liste est probablement plutôt grand. Ainsi, je conclurais qu’interdire l’accès aux API cachées serait important. Mark Murphy, fondateur de Logiciel commun, est d'accord :
Je suis d'accord avec l'évaluation selon laquelle l'interdiction massive de l'accès aux éléments annotés @hide sera un gros problème, si cela se réalise. Espérons que peu d’applications accèdent à ces éléments dans le cadre de fonctionnalités clés. Cependant, je soupçonne que de nombreuses applications de marque les utilisent occasionnellement, directement ou via une bibliothèque.
Que se passe-t-il dans Android P?
Ces changements à venir ont été notés pour la première fois par le développeur XDA Senior Recognized rovo89, le développeur du Cadre Xposed. Il m'a signalé deux engagements, l'un des lequel a été fusionné, qui introduit un nouvel outil de construction appelé « hiddenapi ». Cet outil modifie les indicateurs d'accès de tous les membres de la classe dans un fichier DEX si leurs signatures apparaissent sur une liste grise ou une liste noire d'entrée, et si tel est le cas, les méthodes marquées seront traitées comme des API internes avec un accès restreint. accéder. L'autre commit décrit le fonctionnement de la liste noire des API; il empêche l'accès à classe de démarrage méthodes et champs marqués par le « hiddenapi » susmentionné auquel les développeurs peuvent accéder par liaison statique, réflexion et JNI.
Selon rovo89, le résultat final de ces deux changements dans Android P est le suivant :
Si ces commits sont fusionnés, cela signifierait que les applications ne peuvent plus utiliser/accéder aux API cachées, c'est-à-dire classes, méthodes et champs qui sont annotés avec @hide dans AOSP et ne font donc pas partie du SDK officiel. Cela ne poserait pas de problème pour les modules Xposed, car je pourrais facilement annuler ces validations ou autoriser les modules à le faire également. accéder à ces API. Mais il existe de nombreuses applications qui tirent parti des API cachées, et celles-ci échoueraient dans le futur. avenir.
En effet, d’autres engagements montrent que c’est peut-être ce que Google prévoit. Ce commettre déclare ce qui suit :
Bien que ce commit particulier n'ait pas été fusionné car il a été abandonné au profit de 3 commits plus petits, le message de commit décrit le but de ces modifications. Un autre ensemble de commet montrent que Google proposera des alternatives aux développeurs qui cherchent à utiliser des API non publiques :
Cependant, il n’existe souvent aucune alternative à certaines API cachées. Chez XDA, nous pouvons parler d'expérience ici comme Malheureusement, ce changement pourrait signifier la fin de certaines applications innovantes, ou nécessiter que certaines applications de renom réduisent leur Fonctionnalité. Ce changement à venir semble similaire dans son esprit au récent répression des services d'accessibilité (c'était heureusement en pause puisque Google évaluait les usages innovants). Bien que la plupart des applications qui utilisent des API non documentées le fassent pour des raisons bénignes, certaines applications peuvent les utiliser à mauvais escient à des fins néfastes.
Pour cette raison, Google pourrait verrouiller l'accès à toutes les API cachées dans Android P afin de protéger les utilisateurs des rares personnes qui en abusent. Il est difficile de dire quel impact cela peut avoir sur les utilisateurs, mais si vous êtes un développeur envisagez de consulter AOSP pour trouver une utilisation innovante d'une API cachée, vous souhaiterez peut-être reconsidérer.
Mise à jour: Google confirme
Dans un article de blog publié aujourd'hui 28 février, Google a confirmé ces changements. Citant des risques de crash pour les utilisateurs et obligeant par la suite les développeurs à déployer des correctifs d'urgence, Google déclare que la société a progressivement commencé à décourager les développeurs d'accéder à des logiciels non SDK. interfaces. À partir d'Android P, les restrictions s'étendront pour couvrir les interfaces de langage Java du SDK.
La société déclare que « certaines méthodes et certains champs non SDK seront restreints », sans toutefois préciser lesquels seraient restreints. Dans un premier temps, la restriction se concentrera sur les interfaces rarement utilisées, et pendant un certain temps, l'entreprise autorisera les développeurs doivent continuer à utiliser des méthodes et des champs non SDK pour lesquels la transition vers une méthode SDK est techniquement difficile. Cependant, les restrictions finiront par s'élargir, de sorte que les développeurs d'applications utilisant des méthodes non SDK devraient effectuer la transition dès que possible en préparation pour Android P. Quant aux méthodes sans alternative au SDK, Google demande aux développeurs de publier sur leur traqueur de bogues avec plus d'informations.
Le prochain aperçu des développeurs, qui devrait arriver prochainement, permettra aux développeurs de tester les applications existantes par rapport à la liste noire ou à la liste grise avant la version finale.