Android ignore le toucher sur l’approbation VPN ? Vérifiez d’abord la superposition
Un bouton d’approbation qui ne prend pas le toucher est le plus souvent un obstacle local à l’écran, pas une panne du serveur ni du compte. Retirez la superposition et gardez la protection.
Vous touchez le bouton d’approbation VPN et la boîte de dialogue ne réagit pas. La conclusion naturelle est que l’application ou le serveur est cassé, alors les gens réinitialisent les mots de passe, changent le DNS ou réinstallent le client. Dans le cas courant, rien de tout cela ne touche la cause, car Android écarte les touchers qui arrivent à travers un obstacle, et l’écran d’approbation VPN est exactement ce genre de boîte de dialogue de consentement sensible. Le toucher n’atteint jamais le bouton.
Ce que la protection refuse réellement
Android protège les interactions sensibles contre le tapjacking, où une autre fenêtre se place au-dessus de la boîte de dialogue et vole le toucher ou le rend ambigu. Une vue s’y inscrit avec View.setFilterTouchesWhenObscured, et l’événement arrive avec MotionEvent.FLAG_WINDOW_IS_OBSCURED lorsqu’une autre fenêtre est marquée comme partiellement ou totalement masquante. L’événement est alors écarté au lieu d’être livré au mauvais endroit. Android 12 (API 31) a étendu la même protection avec le blocage des touchers non fiables dans les surfaces de consentement du système, et c’est pourquoi la boîte d’approbation peut refuser un toucher venant d’une superposition que d’autres applications accepteraient encore.
Trois choses produisent régulièrement un obstacle : une application détenant l’autorisation de s’afficher au-dessus des autres, un service d’accessibilité qui dessine du contenu, et un widget flottant d’un enregistreur d’écran ou d’un outil de filtre. Certaines fonctions d’affichage du fabricant ajoutent leur propre couche, et c’est pourquoi la même boîte peut se comporter différemment sur deux téléphones de même version d’Android. Une fenêtre masquante partielle définit FLAG_WINDOW_IS_PARTIALLY_OBSCURED, et le toucher est écarté avant même que le bouton le voie. C’est une propriété de l’écran, pas du réseau. Rien n’a été envoyé au serveur VPN au moment où le toucher est écarté, donc aucun changement côté serveur ne peut influencer le résultat.
Séparez un toucher mort d’une connexion échouée
La distinction est tout le diagnostic et elle prend dix secondes. Si le toucher est ignoré et que la boîte reste exactement comme avant, l’obstacle est local. Si la boîte se ferme et qu’une erreur apparaît ensuite, le consentement a été accepté et vous êtes passé à une autre étape qui a besoin des informations d’événement de l’application.
Vous pouvez confirmer la lecture locale en vérifiant si l’application demandeuse a même tenté une connexion. Un client qui n’enregistre jamais de tentative de handshake alors que la boîte de consentement est à l’écran n’a pas atteint le réseau.
adb shell cmd appops get com.example.vpn SYSTEM_ALERT_WINDOW
adb shell settings get secure enabled_accessibility_servicesListez qui détient l’autorisation de superposition et quels services d’accessibilité sont activés, puis comparez avec ce qui tourne. Ne désactivez pas la protection de la plateforme elle-même ; c’est elle qui empêche une fenêtre cachée de répondre à une boîte de consentement à votre place.
Retirez l’obstacle, puis refaites le parcours normal
Identifiez d’abord quelle application a demandé l’approbation VPN, pour savoir quel consentement vous accordez. Arrêtez ensuite la superposition précise depuis son propre réglage, plutôt qu’en révoquant une autorisation large dont vous pourriez avoir besoin plus tard. Un filtre d’écran a généralement un interrupteur dans son application ; un widget flottant a une commande de fermeture ; un mode d’affichage du fabricant a un interrupteur dans les réglages d’affichage.
Revenez ensuite à l’application VPN et demandez de nouveau l’approbation, pour que la boîte soit créée à neuf. Si le toucher fonctionne maintenant, ajustez le comportement de compatibilité de la superposition ou laissez-la désactivée pendant la connexion, et gardez la protection tactile active.
Si vous ne savez pas quelle fenêtre est responsable, retirez-les une par une et refaites le test de la boîte après chaque changement. Une barre de contrôle d’enregistreur ou un raccourci flottant est le coupable habituel, et celle que vous venez de retirer avant que ça marche est la réponse.
Rétablissez tout ce qui n’a rien à voir et que vous avez désactivé en chemin. Un filtre d’écran ou un mode nuit n’est pas l’ennemi ; la fenêtre précise qui chevauche la boîte l’est.
Ce qu’il ne faut pas faire pour contourner la boîte
N’accordez pas l’accessibilité à une application inconnue pour qu’elle appuie sur le bouton, et n’installez pas d’application d’aide pour cela. Cela accorde exactement la capacité que la protection existe pour refuser, sur un écran qui autorise un VPN.
N’automatisez pas non plus la boîte avec un outil de saisie. Cela produit le même résultat qu’une superposition malveillante et ne vous apprend rien sur la cause.
Sur un appareil géré, une stratégie qui limite les changements de VPN relève de l’administrateur. Une expérience de superposition n’est pas une autorisation de la contourner. De même, un bouton de consentement qui ne répond pas n’est pas une raison d’affaiblir la vérification des certificats ni de changer les identifiants du compte : aucun des deux réglages ne supprime un obstacle tactile local.
Si cela échoue encore, décrivez le comportement exact
Décrivez la boîte plutôt que la conclusion : quelle application a demandé l’approbation, si la boîte est restée ouverte ou s’est fermée, si d’autres invites sensibles comme les avertissements de sources inconnues ou d’accessibilité ignorent aussi les touchers, le modèle de l’appareil et la version d’Android, ainsi que les listes de superpositions et d’accessibilité que vous avez relevées.
Posez une question de plus au responsable du support : la stratégie de l’appareil limite-t-elle les changements de configuration VPN. Un blocage géré ne ressemble pas à un toucher ignoré, et savoir lequel vous avez devant vous épargne un second aller-retour.
Cet ensemble distingue un problème de toucher masqué d’un périphérique d’entrée défaillant, d’une boîte figée ou d’un blocage de stratégie. Il indique aussi à la personne suivante s’il faut regarder l’écran ou le réseau.
Le guide Android sur le tapjacking couvre les conditions de fenêtres masquées et les API derrière ce comportement. Si vous voulez la trace des preuves, cherchez FLAG_WINDOW_IS_OBSCURED et FLAG_WINDOW_IS_PARTIALLY_OBSCURED sur l’événement qui n’a jamais atteint le bouton. La boîte qui reste ouverte est ce qu’il faut capturer, car elle montre que le toucher a été retenu et non livré à une autre fenêtre.