Google teste une mesure de sécurité supplémentaire dans le mode Android Advanced Protection (AAPM) qui limite l'accès à l'API des services d'accessibilité pour les applications qui ne sont pas spécifiquement conçues pour aider les personnes handicapées. La nouveauté est apparue sur le Beta 2 d'Android 17 et a attiré l'attention parce qu'il réduit une surface d'attaque qui, ces dernières années, a été utilisé par les acteurs malveillants pour voler des données sensibles.
Le mode de protection avancée, introduit avec Android 16 comme option d'opt-in pour les utilisateurs à risque - journalistes, militants ou cadres, par exemple - met l'appareil dans un état de sécurité renforcé qui sacrifie certaines commodités pour minimiser les vecteurs d'attaque. Si vous voulez savoir comment il fonctionne et ce qui bloque ce mode s'applique, Google dispose de documentation officielle expliquant ses actions et limitations sur sa page de support et dans la documentation pour les développeurs: Assistance Android sur AAPM et le guide technique evooper.android.com.

La restriction testée sur Android 17 bloque l'utilisation de l'API AccessibilityService par des applications qui ne sont pas officiellement déclarées comme des outils d'accessibilité. Pour qu'une application maintienne ce permis pendant que le mode AAPM est actif, vous devez porter l'indicateur isAccessibilitéTool = "true" dans sa configuration et aussi répondre aux catégories que Google reconnaît comme légitimes: lecteurs d'écran, systèmes d'entrée de commutation, outils d'entrée vocale et solutions en braille. Les outils tels que les antivirus, les automates, les assistants, les nettoyeurs, les gestionnaires de mots de passe ou les lanceurs ne tombent pas dans cette classification et verraient donc leurs capacités limitées lorsque AAPM est activé. Plus de détails sur la façon dont les applications d'accessibilité sont identifiées sont disponibles dans le guide Google développeur et dans le centre de politique de lecture: Accessibilité Guide des services et documentation sur isAccessibility Outil.
La raison de cette décision est claire: bien que l'API Services d'accessibilité ait des utilisations légitimes et précieuses pour les utilisateurs ayant des besoins spéciaux, elle a également été abusée par des applications malveillantes pour capturer des informations à l'écran, intercepter des événements et des références d'exfiltre. En désactivant automatiquement les autorisations d'accessibilité pour les applications qui ne sont pas des outils d'accessibilité lorsque AAPM est actif, Google a l'intention de fermer un vecteur qui a été fréquemment exploité. En outre, pendant que le mode est activé, les utilisateurs peuvent ne pas accorder manuellement cette autorisation aux applications non autorisées, ajoutant une couche de protection supplémentaire.
Pour les développeurs, Google suggère d'intégrer la détection de statut AAPM en utilisant son API de gestion de la protection avancée, afin que les applications puissent adapter leur comportement lorsque l'utilisateur a opté pour ce profil de sécurité plus élevé. L'API et ses recommandations figurent dans la documentation technique officielle : Gestionnaire de protection avancé. Cela permet, par exemple, de désactiver les fonctionnalités à haut risque ou de rediriger vers des flux qui ne nécessitent pas d'accès à l'API d'accessibilité le cas échéant.
Une autre nouveauté incluse dans Android 17 est un sélecteur de contact plus granulaire qui permet aux applications de demander seulement l'accès aux champs dont elles ont vraiment besoin, comme les téléphones ou les courriels, ou laisser l'utilisateur sélectionner des contacts spécifiques sans exposer le carnet complet. Selon Google, cette nouvelle approche offre une expérience utilisateur uniforme - avec recherche intégrée, changement de profil et sélection multiple - et réduit l'exposition aux données en limitant la lecture à ce qui est strictement nécessaire. L'explication de cette fonctionnalité fait partie du résumé de nouvelles Android 17 sur le site officiel: Fonctions Android 17.

Dans la pratique, ces mesures représentent un équilibre : les utilisateurs qui privilégient la sécurité obtiennent une meilleure protection contre les techniques connues de vol d'informations, au prix de certaines applications perdant des fonctions qui dépendent de l'API d'accessibilité. Pour la plupart des utilisateurs qui ne seront probablement pas un problème, mais pour les organisations et les développeurs qui offrent des services légitimes basés sur l'accessibilité, il sera nécessaire de vérifier qu'ils répondent aux exigences de Google et, le cas échéant, d'adapter leurs applications.
Si vous êtes préoccupé par le risque d'exposition de vos données et si vous êtes un utilisateur plus susceptible d'être ciblé pour des attaques ciblées, activer le mode Protection avancée peut être une mesure raisonnable. Si vous êtes un développeur, vérifiez la documentation de Google pour vous assurer que votre application déclare correctement son but et utilise les API recommandées pour détecter et respecter l'état d'AAPM. Pour suivre la couverture médiatique et technique de cette mise à jour, vous pouvez lire le rapport initial Android Autorité sur l'Android Beta 2 17: Autorité Android en plus des sources officielles énumérées ci-dessus.
En bref, les changements sur Android 17 montrent un engagement clair pour durcir la plate-forme contre les abus connus, renforcer la protection pour les utilisateurs à haut risque et pousser l'industrie à séparer clairement les outils qui offrent l'accessibilité légitime des utilitaires qui, bien que pratique, ne devraient pas avoir accès sans contrôles supplémentaires.
Autres
Plus de nouvelles sur le même sujet.

La jeunesse ukrainienne de 18 ans dirige un réseau d'infostealers qui a violé 28 000 comptes et laissé 250 000 $ en pertes
Les autorités ukrainiennes, en coordination avec les agents américains. Ils se sont concentrés sur une opération de infostealer Selon la Cyber Police ukrainienne, Odessa aurait ...

La signature numérique est en contrôle : Microsoft désigne un service qui a transformé les logiciels malveillants en logiciels apparemment légitimes
Microsoft a annoncé la désarticulation d'une opération "malware-signing-as-a-service" qui a exploité son système de signature de périphérique pour convertir le code malveillant ...

Un seul jeton GitHub a ouvert la porte à la chaîne d'approvisionnement du logiciel
Un seul jeton GitHub a échoué dans la rotation et a ouvert la porte. C'est la conclusion centrale de l'incident dans Grafana Labs suite à la récente vague de paquets malveillant...

WebWorm 2025: le malware qui est caché dans Discord et Microsoft Graphh pour échapper à la détection
Les dernières observations des chercheurs en cybersécurité font état d'un changement de tactique inquiétante d'un acteur lié à la Chine, connu sous le nom de WebWorm: en 2025, e...

L'identité n'est plus suffisante : vérification continue de l'appareil pour la sécurité en temps réel
L'identité reste l'épine dorsale de nombreuses architectures de sécurité, mais aujourd'hui, cette colonne se fissure sous de nouvelles pressions : phishing avancé, kits d'authen...

La question sombre de l'identité change les règles de la sécurité des entreprises
The Identity Gap: Snapshot 2026 rapport publié par Orchid Security met les chiffres à une tendance dangereuse: la « matière sombre » de l'identité - comptes et références qui ne...

Clé jaune L'échec BitLocker qui pourrait permettre à un attaquant de déverrouiller votre unité avec seulement un accès physique
Microsoft a publié une atténuation pour une vulnérabilité d'omission de sécurité BitLocker Clé jaune (CVE-2026-45585) après que son test de concept ait été divulgué publiquement...