La fonctionnalité d'accessibilité d'Android est connue pour provoquer un décalage dans l'interface utilisateur. Est-ce un bug ou est-ce une fonctionnalité? Pourquoi cela se produit-il? Chez XDA, nous enquêtons sur la cause profonde.
La beauté d’Android réside dans les nombreuses façons dont les applications tierces peuvent interagir avec le système. Applications de gestion de mots de passe telles que Dernier passage offrent la possibilité d’alimenter automatiquement les données pertinentes de nom d’utilisateur/mot de passe sur presque n’importe quel écran de connexion. Aide-texte vous permet de réduire considérablement le temps passé à envoyer des SMS à vos amis en vous permettant de créer des macros d'expansion de texte. Presse-papiers natif diminue les tracas liés au basculement fréquent entre les applications pour copier de grandes quantités de texte en vous permettant d'appuyer deux fois sur n'importe quel champ de saisie pour afficher un presse-papiers. Qui peut oublier Verdir, peut-être l'application la plus recommandée par les passionnés, qui contrôle les applications malveillantes en arrière-plan et peut ainsi améliorer la durée de vie de la batterie? Enfin, bien que moins familier à la plupart des utilisateurs, il existe
Pour l'utilisateur Android moyen, il peut sembler étrange que bon nombre de ces fonctionnalités étonnantes utilisées par votre application préférée soient contrôlées par un paramètre sous l'onglet accessibilité sous-menu. Créer une application accessible est généralement censé signifier qu'une application Android est utilisable par une personne avec handicapées. Alors pourquoi diable LastPass, Native Clipboard, Text Aide, Greenify ou AutoInput ont-ils un accessibilité service? De plus, pourquoi l’activation d’un service d’accessibilité semble-t-elle causer tellement de décalage dans l'interface utilisateur? La version d'Android que vous utilisez ne semble pas avoir d'importance - que ce soit Android 5.0 Sucette ou Android 7.0 Nougat - car le décalage provoqué par certains services d'accessibilité peut affecter votre expérience. Une solution simple à ce problème consiste simplement à désactiver les services d’accessibilité que vous avez peut-être activés – mais ce faisant, nous perdons de nombreuses fonctionnalités utiles. Une autre solution consiste à demander à Google de « corriger » le retard d'accessibilité d'Android, mais Google affirme que l'accessibilité d'Android est Travailler comme prévue. Nous avons parlé à quelques développeurs intimement familiers avec les services d'accessibilité et avons étudié le fonctionnement de la fonctionnalité, et nous sommes ici pour tester cette affirmation: Le retard d'accessibilité d'Android est-il un bug ou est-ce une fonctionnalité ?
Comprendre l'accessibilité d'Android
Comme son nom l'indique peut-être, l'accessibilité est principalement destinée aux développeurs afin de fournir des fonctionnalités supplémentaires à tout utilisateur handicapé. En effet, un rapide coup d'œil sur pages de documentation officielle pour l'accessibilité révèle que Google a une vision assez étroite des types de services qui devraient être fournis par les services d'accessibilité.
De nombreux utilisateurs d'Android ont des capacités différentes qui les obligent à interagir de différentes manières avec leurs appareils Android. Il s'agit notamment des utilisateurs qui ont des limitations visuelles, physiques ou liées à l'âge qui les empêchent de voir ou de voir pleinement. utilisant un écran tactile et les utilisateurs malentendants qui peuvent ne pas être en mesure de percevoir les informations et les alertes sonores.
Android fournit des fonctionnalités et des services d'accessibilité pour aider ces utilisateurs à mieux naviguer sur leurs appareils. facilement, y compris la synthèse vocale, le retour haptique, la navigation gestuelle, le trackball et le pavé directionnel la navigation.
Google Répondre, qui est préinstallé sur chaque téléphone Android, est un excellent exemple de ce à quoi est censé ressembler le service d'accessibilité « typique ». Accès vocal va encore plus loin en matière d'accessibilité et permet un contrôle presque complet de votre téléphone en utilisant uniquement votre voix. Mais le fait que Google ait eu l'intention d'utiliser les services d'accessibilité de cette manière n'empêche pas les développeurs de les implémenter comme ils le souhaitent - et c'est exactement ce que les développeurs ont fait. C'est exactement à cause de la façon dont fonctionne l'accessibilité qui rend cette fonctionnalité incroyablement utile aux utilisateurs avec ou sans handicap.
Pour simplifier un peu les choses, voici un aperçu de base du fonctionnement de l'accessibilité d'Android. Un développeur crée un Service d'accessibilité qui s'abonne à divers Événements d'accessibilité qui sont envoyés par le système au Service selon que certains critères sont remplis ou non. Lorsque tous les services sont désactivés sous Paramètres -> Accessibilité, Android ne collecte ni n'envoie d'événements d'accessibilité. Mais lorsque l'utilisateur commence à activer les services d'accessibilité, Android commence à surveiller et à collecter uniquement les événements d'accessibilité demandés par le service d'accessibilité. Par exemple, un service d'accessibilité qui s'abonne à l'événement d'accessibilité TYPE_WINDOW_CONTENT_CHANGED sera averti par le système A chaque fois qu'un changement dans la fenêtre actuelle se produit. Un autre événement sur l'accessibilité appelé TYPE_VIEW_CLICKED tire A chaque fois l'utilisateur clique sur un bouton quelconque.
Démonstration d'accessibilité Android. Dans cette vidéo, j'ai activé l'application Tâcheur surveiller pour changements dans le titre de la fenêtre. Cela nécessite l'activation du service d'accessibilité de Tasker. Vous pouvez reproduire cela en créant un nouveau profil dans Tasker avec le contexte « Événement » défini sur « Ensemble de variables » et en choisissant %WIN comme variable à surveiller. Au total, cette vidéo d'environ 1 minute capturée 107 changements dans la fenêtre actuelle.
Ces types d’événements d’accessibilité se produisent très fréquemment lors d’une interaction normale de l’utilisateur. Alors imaginez ce qui se passe lorsqu'un utilisateur permet plusieurs services d'accessibilité qui demandent le déclenchement d’événements d’accessibilité à haute fréquence. C'est exact - décalage. Pour atténuer ce problème, les développeurs peuvent définir plus précisément les types d'événements d'accessibilité qu'ils souhaitent utiliser. Le service doit réagir et dans quel contexte, comme la possibilité de limiter le service à réagir uniquement quand à certaines applications ou pour limiter le période de scrutin entre les événements. Mais à part cela, le montant des frais généraux générés par un service d'accessibilité dépend principalement de quels types d'événements d'accessibilité auquel il souscrit. Essentiellement, tous les services d’accessibilité n’entraîneront pas de décalage. Un seul service d'accessibilité qui nécessite un événement à haute fréquence peut entraîner un décalage, surtout si ledit Service est couplé à un autre Service qui nécessite qu'un autre Événement à haute fréquence soit surveillé.
Plongez dans l’accessibilité avec les démontages d’APK
Comme vous pouvez le constater dans la vidéo publiée ci-dessus, un service d'accessibilité qui surveille les modifications apportées au contenu de la fenêtre peut entraîner des changements assez notables dans les performances de l'interface utilisateur en raison de la grande quantité d'événements d'accessibilité capturés et déclenchés par le système. Cependant, il est assez difficile de déterminer exactement quelle surcharge est causée par un service d'accessibilité particulier. La surveillance de LogCat ne vous mènera généralement nulle part, car les événements d'accessibilité ne sont imprimés sur LogCat que si le développeur du service d'accessibilité choisit de le faire. Heureusement, le papa de tous les services d'accessibilité Android, Saisie automatique, fait exactement cela. Et la sortie LogCat est exactement aussi compliquée que vous pourriez l'imaginer.
AutoInput ne nous cache pas la vérité. La surcharge causée par l'application peut être assez énorme en fonction des événements que vous surveillez. Mais cette surcharge est nécessaire au fonctionnement de l’application. Pour qu'AutoInput intercepte chaque pression sur une touche, chaque geste à l'écran, chaque mise à jour de l'interface utilisateur et chaque pression sur un bouton, il besoins pour surveiller les événements d'accessibilité respectifs. Sans ces événements, AutoInput ne peut pas se connecter au système et fournir l'automatisation presque illimitée de l'interface utilisateur qu'il permet actuellement. Ainsi, toutes les fonctions d'AutoInput prennent tout leur sens dans le contexte de l'accessibilité. Mais pour d’autres applications, nous devons regarder un peu plus en profondeur pour comprendre comment leurs services d’accessibilité sont gérés.
Un service d'accessibilité les attributs sont définis dans un Fichier de ressources XML dans l'APK. Nous pouvons donc effectuer une Démontage de l'APK sur une application avec un service d'accessibilité pour déterminer les attributs du service. Chaque application fonctionne différemment, je vais donc essayer d'expliquer comment les attributs de leur service sont liés à la fonction spécifique qu'elle remplit.
Presse-papiers natif
Native Clipboard est mon choix en matière de gestionnaires de presse-papiers. Si vous recherchez un gestionnaire de presse-papiers hautement personnalisable, Native Clipboard est une très bonne application. Il dispose même d'un composant Xposed Module pour vous permettre d'appuyer longuement sur le bouton « Coller » pour afficher le gestionnaire du presse-papiers! Malheureusement, si vous n'avez pas accès au Xposed Framework (comme tous les utilisateurs de Nougat), vous devrez vous contenter pour activer le service d'accessibilité qui vous permettra d'appuyer deux fois sur n'importe quelle saisie de texte pour afficher le presse-papiers directeur. Voici ce que cela implique.
"@string/access_decs"
android: accessibilityEventTypes="typeViewClicked|typeViewFocused|typeViewLongClicked|typeWindowStateChanged"
android: accessibilityFeedbackType="feedbackGeneric"
android: notificationTimeout="100"
android: accessibilityFlags="flagReportViewIds|flagRetrieveInteractiveWindows"
android: canRetrieveWindowContent="true"
xmlns: andro /> Le service d'accessibilité de Native Clipboard demande le déclenchement d'un événement d'accessibilité à chaque fois qu'un clic sur une vue est effectué, un clic long, une mise au point ou s'il y a un changement dans l'état de la fenêtre. Sans avoir accès au code source, je ne peux pas dire exactement comment fonctionne Native Clipboard, mais il est probable que Native Clipboard attend que l'état de la fenêtre indique que le clavier logiciel est actuellement ouvert, puis il surveille les pressions sur l'entrée champ. L'application a une période d'interrogation de 100 ms, ce qui est certainement assez rapide pour réagir immédiatement aux changements de visibilité du clavier logiciel ainsi qu'aux doubles pressions. Cela pourrait entraîner une surcharge de l'interface utilisateur chaque fois que l'utilisateur utilise le clavier logiciel pour saisir du texte, ce qui pourrait entraîner un décalage.
Verdir
La prochaine étape est l'économiseur de batterie préféré de tous, Greenify. Greenify utilise les événements d'accessibilité pour alimenter ses fonctions non root.
"@string/accessibility_service_description"
android: settingsActivity="com.oasisfeng.greenify.accessibility.AccessibilitySettings"
android: accessibilityEventTypes="typeAnnouncement|typeNotificationStateChanged|typeWindowStateChanged"
android: accessibilityFeedbackType="feedbackGeneric" android: notificationTimeout="0"
android: accessibilityFlags="flagReportViewIds"
android: canRetrieveWindowContent="true"
xmlns: andro /> Il utilise les modifications apportées à l'état de la fenêtre pour déterminer quand l'écran du téléphone s'est éteint et nécessite que vous retardiez l'activation de l'écran de verrouillage en modifiant une option dans les paramètres de sécurité. Greenify recevra également des événements de type Annonce ou État de notification modifié, ce dernier qui n'est pas nécessaire sur les appareils Android 5.0+ grâce à la fonctionnalité Notification Access. Cependant, il recevra toujours ces événements indépendamment de ce fait. Greenify ne devrait pas entraîner beaucoup de frais généraux en soi, mais la possibilité demeure.
Lanceur Nova
Probablement l'application de lancement tierce la plus populaire du marché, Nova Launcher est un excellent exemple d'application utilisant un service d'accessibilité avec une surcharge minimale, voire nulle. La seule raison d'être du Service est d'aider certains appareils à effectuer des gestes.
"@string/accessibility_service_description"
android: accessibilityEventTypes=""
android: packageNames="com.teslacoilsw.launcher"
android: accessibilityFeedbackType=""
android: notificationTimeout="10000"
android: canRetrieveWindowContent="false"
xmlns: andro /> Comme vous pouvez le constater, aucun événement d'accessibilité n'est défini dans le fichier XML. Tout ce qui est mentionné est le nom d'un package - Nova Launcher. Ce qui se passe ici est une solution de contournement pour certains appareils pour lesquels les gestes de Nova Launcher ne fonctionnent pas. Ce service fournira à Nova Launcher tous les événements d'accessibilité déclenchés depuis uniquement dans Nova Launcher. Cela semble étrange, mais c'est apparemment un moyen de corriger les gestes de l'écran d'accueil de Nova si votre appareil ne fonctionne pas avec eux. Étant donné que cela ne demande que des événements à Nova lui-même, le service pose très peu de frais généraux.
Dernier passage
Enfin, peut-être le service d'accessibilité le plus tristement célèbre qui provoque un décalage (probablement en raison de son immense popularité): LastPass. Le problème du décalage dans LastPass est si visible que l'entreprise a un responsable Page FAQ décrivant le problème. Comme l'indique la FAQ, vous ne pouvez rien faire contre le décalage, sauf désactiver le service. Pourquoi le service LastPass semble-t-il si flagrant en termes de décalage? Jetons un coup d'œil aux attributs du service.
"@string/accessibility_service_description"
android: accessibilityEventTypes="typeViewFocused|typeWindowContentChanged"
android: accessibilityFeedbackType="feedbackGeneric"
android: notificationTimeout="200"
android: accessibilityFlags="flagReportViewIds"
android: canRetrieveWindowContent="true"
android: canRequestEnhancedWebAccessibility="true"
xmlns: andro /> La vérité est qu’il n’y a rien d’extraordinaire avec le service LastPass. Il ne demande que deux types d'événements à surveiller: TYPE_VIEW_FOCUSED et TYPE_WINDOW_CONTENT_CHANGED. Il le fait parce qu'il a besoin de savoir quand le contenu d'une application/d'une page Web a changé/est mis en évidence, puis il récupère le contenu actuel de la fenêtre pour rechercher les champs de saisie de mot de passe. Mais comme le service effectue constamment cette opération sur deux événements d'accessibilité qui se déclenchent extrêmement fréquemment, cela entraîne un décalage. C'est la triste vérité.
Vivre avec le décalage
Lorsque nous avons appris pour la première fois que Google fermait les rapports de bogues concernant le décalage d'accessibilité parce que la fonctionnalité « fonctionnait comme prévu », nous étions tout aussi perplexes et bouleversés que beaucoup d'entre vous. Mais plutôt que d’accepter l’explication au pied de la lettre, nous avons décidé d’examiner la question nous-mêmes pour déterminer la vérité. Ainsi, lorsque le Googleur sur la page de rapport de bug a dit ceci :
Bonjour, ce problème persiste sur les versions Android. De plus, il y aura toujours un décalage supplémentaire lorsqu'un service d'accessibilité est activé. En effet, l'appareil, en plus de l'interface utilisateur standard, fournit de nombreuses informations aux services d'accessibilité afin qu'ils puissent offrir une expérience utilisateur alternative à ces utilisateurs.
Nous sommes parvenus à comprendre pourquoi c'est comportement prévu. Les applications qui utilisent les services d'accessibilité d'une manière non intentionnelle par Google entraîneront toujours une certaine surcharge de performances; ce coût est simplement nécessaire pour fournir aux services la pléthore d'informations qu'Android Accessibility déclenche en arrière-plan. Le décalage d'Android avec les services d'accessibilité est pas un bug, mais une fonctionnalité. Une fonctionnalité avec laquelle nous devrons vivre à moins que l'ensemble du système ne soit retravaillé, et je ne peux pas imaginer comment cela serait fait pour accueillir autant d'ensembles de fonctionnalités différents provenant de tant d'applications différentes.
À tout le moins, les développeurs de LastPass n’accepteraient pas cela. Leurs développeurs ont travaillé avec les développeurs de Chromium pour optimiser la prise en charge de l'accessibilité, peut-être en activant la prise en charge de LastPass grâce à l'utilisation d'API plutôt que d’activer un service d’accessibilité. L'optimisation des frais généraux induits par les services d'accessibilité est une possibilité, mais comme de nombreux développeurs l'ont implicitement noté sur sur les forums Chromium, il s'agit simplement d'un pansement qui ne résoudra pas le fait que les utilisations involontaires des services d'accessibilité peuvent entraîner décalage.
Un merci spécial au développeur d'AutoInput, joaomgcd, pour avoir répondu à plusieurs de mes questions concernant l'accessibilité !