Android 17 Beta 2 : Google bloque les apps qui abusent des services d’accessibilité — votre appli préférée pourrait cesser de fonctionner

Android 17 Beta 2 : Google serre la vis et limite l’usage abusif des services d’accessibilité

Avec la seconde bêta d’Android 17, Google avance encore sur la sécurité et la protection des utilisateurs en renforçant le contrôle autour des Accessibility Services. Pensées à l’origine pour aider les personnes en situation de handicap à utiliser leur smartphone, ces API ont fini par être détournées pour permettre des fonctions avancées — et parfois problématiques — par des applications non prévues pour cela. La Beta 2 introduit donc une restriction importante : dans le mode « Advanced Protection » (protection avancée), seules les applications explicitement reconnues comme outils d’accessibilité peuvent obtenir ces permissions. Explications et conséquences pour les utilisateurs et développeurs.

À quoi servent réellement les Accessibility Services ?

Les Accessibility Services fournissent des capacités puissantes : lecture de l’écran, observation des événements système, simulation de gestes, interaction automatique avec l’interface. Tout cela permet de créer des aides comme les lecteurs d’écran, les claviers alternatifs ou les interfaces de commande vocale. Conçues pour compenser des limitations fonctionnelles, ces API sont cruciales pour l’inclusion numérique.

Mais ces mêmes pouvoirs attirent aussi des usages détournés : afficher des pop‑ups persistants, automatiser des actions, ou contourner des restrictions d’API. Certaines applications d’automatisation, certains launchers ou utilitaires de personnalisation s’appuient sur ces services pour aller au‑delà des possibilités permises par des API publiques, créant un terrain propice aux abus.

Ce que change Android 17 Beta 2

La nouveauté principale de la Beta 2 se manifeste lorsque l’utilisateur active la « Advanced Protection Mode ». Dans ce profil renforcé :

le système empêche les applications non classées comme outils d’accessibilité d’obtenir l’accès aux Accessibility Services ;

si une application avait déjà ces permissions, Android les révoque automatiquement dès l’activation du mode ;

tant que la protection avancée est active, il est impossible de réattribuer ces permissions aux applications bloquées.

Concrètement, cela signifie qu’une app utilitaire qui s’appuie sur ces services pour afficher des éléments flottants à l’écran ou automatiser des tâches ne fonctionnera plus si l’utilisateur choisit ce profil de sécurité. Les tests réalisés montrent que des apps populaires de personnalisation, comme dynamicSpot, perdent la possibilité d’obtenir ces droits sur un Pixel 9a sous Android 17 Beta 2 — elles cessent donc de fonctionner correctement tant que la protection avancée reste activée.

Pour qui est destinée la Advanced Protection Mode ?

Google a conservé une logique de choix volontaire : la protection renforcée n’est pas imposée par défaut. Elle s’adresse principalement :

aux utilisateurs très soucieux de la sécurité et de la confidentialité, souhaitant réduire au minimum les vecteurs d’accès au contenu affiché à l’écran ;

aux comptes sensibles (journalistes, militants, administrateurs) qui peuvent vouloir un profil plus verrouillé ;

aux utilisateurs moins techniques qui préfèrent activer un profil « sûr » et se passer de certaines apps d’appoint.

En bref : activer la mode avancée, c’est accepter une expérience plus restrictive en contrepartie d’une surface d’attaque réduite.

Quel impact pour les développeurs d’applications ?

Les développeurs qui reposent sur Accessibility Services pour proposer des fonctionnalités avancées doivent se préparer à deux réalités :

la nécessité d’identifier clairement si leur application est un outil d’accessibilité légitime et d’en justifier l’usage à Google ;

la perte potentielle d’une partie de leur user base si certains utilisateurs activent des profils de sécurité stricts.

Pour les éditeurs, il devient donc crucial de documenter l’usage des permissions, de s’appuyer sur les API publiques quand c’est possible, et d’évaluer des alternatives moins intrusionnistes. Google, de son côté, pousse clairement vers une limitation des accès privilégiés et vers une meilleure qualification des applications qui demandent ces droits.

Les avantages et les limites de cette approche

L’approche de Google présente des avantages clairs :

réduction immédiate des risques liés aux apps qui lisent l’écran et volent des données sensibles ;

protection des utilisateurs contre des comportements automatisés non désirés ;

encouragement pour les développeurs à utiliser des API publiques et des méthodes moins intrusives.

Cependant, des limites demeurent :

des applications légitimes pourraient souffrir d’une perte de fonctionnalités, affectant l’expérience d’utilisateurs qui en ont réellement besoin ;

les développeurs malveillants ou les techniques d’obfuscation pourront chercher d’autres vecteurs pour contourner les protections ;

la dépendance à un profil activable manuellement signifie que tous les utilisateurs ne bénéficieront pas automatiquement des protections.

Comment s’adapter en tant qu’utilisateur ?

Si vous tenez à la sécurité : activez la Advanced Protection Mode pour limiter les permissions sensibles et réduire l’exposition aux apps intrusives.

Si vous utilisez des applis de personnalisation : sachez que certaines fonctions peuvent être bloquées en mode avancé ; vous devrez décider entre sécurité et customisation.

Gardez un œil sur les mises à jour des apps : les développeurs pourraient proposer des versions compatibles sans recours aux Accessibility Services.

Perspectives : vers une plateforme plus sûre mais plus contrôlée

La décision de Google montre une orientation claire : sécuriser Android en limitant les pouvoirs des APIs les plus sensibles. C’est une bonne nouvelle pour la confidentialité et la protection des utilisateurs, mais cela implique une révision des pratiques pour certains développeurs et une prise de décision consciente de la part des utilisateurs. Android gagne en robustesse, mais les dialogues entre développeurs, utilisateurs et Google vont être déterminants pour que l’écosystème évolue de manière équilibrée.