Android negeert je tik op VPN-goedkeuring? Kijk eerst naar de overlay

Je tikt op de knop voor VPN-goedkeuring en de dialoog reageert niet. De logische conclusie is dat de app of de server stuk is, dus mensen resetten wachtwoorden, wijzigen DNS of herinstalleren de client. Meestal raakt niets daarvan de oorzaak, omdat Android tikken weggooit die via een hindernis binnenkomen, en het goedkeuringsscherm van de VPN precies zo’n gevoelige toestemmingsdialoog is. De tik bereikt de knop nooit.

Wat de bescherming werkelijk weigert

Android beschermt gevoelige interacties tegen tapjacking, waarbij een ander venster boven de dialoog zit en de tik steelt of dubbelzinnig maakt. Een view doet mee met View.setFilterTouchesWhenObscured, en de gebeurtenis komt met MotionEvent.FLAG_WINDOW_IS_OBSCURED wanneer een ander venster als gedeeltelijk of volledig bedekkend is gemarkeerd. Dan wordt de gebeurtenis weggegooid in plaats van op de verkeerde plek afgeleverd. Android 12 (API 31) breidde dezelfde bescherming uit met het blokkeren van onbetrouwbare aanrakingen op systeemtoestemmingsoppervlakken, waardoor de goedkeuringsdialoog een tik uit een overlay kan weigeren die andere apps nog zouden accepteren.

Drie dingen veroorzaken geregeld een hindernis: een app met toestemming om over andere apps te tonen, een toegankelijkheidsdienst die inhoud tekent, en een zwevend widget van een schermrecorder of filterhulpmiddel. Sommige beeldschermfuncties van de fabrikant voegen hun eigen laag toe, waardoor dezelfde dialoog zich anders gedraagt op twee telefoons met dezelfde Android-versie. Een gedeeltelijk bedekkend venster zet FLAG_WINDOW_IS_PARTIALLY_OBSCURED, en de tik wordt weggegooid voordat de knop hem ziet. Dat is een eigenschap van het scherm, niet van het netwerk. Er is niets naar de VPN-server gestuurd op het moment dat de tik wordt weggegooid, dus geen enkele wijziging aan de serverkant kan de uitkomst beïnvloeden.

Scheid een dode tik van een mislukte verbinding

Het verschil is de hele diagnose en het kost tien seconden. Wordt de tik genegeerd en blijft de dialoog precies zoals hij was, dan is de hindernis plaatselijk. Sluit de dialoog en verschijnt daarna een fout, dan is de toestemming geaccepteerd en zit je in een andere fase die de eigen gebeurtenisinformatie van de app nodig heeft.

Je kunt de plaatselijke lezing bevestigen door te controleren of de aanvragende app überhaupt een verbinding probeerde. Een client die nooit een handshake-poging registreert terwijl de toestemmingsdialoog op het scherm staat, heeft het netwerk niet bereikt.

adb shell cmd appops get com.example.vpn SYSTEM_ALERT_WINDOW
adb shell settings get secure enabled_accessibility_services

Maak een lijst van wie de overlay-toestemming heeft en welke toegankelijkheidsdiensten aan staan, en vergelijk dat met wat er draait. Zet de bescherming van het platform zelf niet uit; die voorkomt dat een verborgen venster namens jou een toestemmingsdialoog beantwoordt.

Verwijder de hindernis en probeer daarna de normale stroom

Bepaal eerst welke app om VPN-goedkeuring vroeg, zodat je weet welke toestemming je geeft. Stop daarna de specifieke overlay via zijn eigen instelling, niet door een brede toestemming in te trekken die je later nodig kunt hebben. Een schermfilter heeft meestal een schakelaar in zijn eigen app; een zwevend widget heeft een sluitknop; een weergavemodus van de fabrikant heeft een schakelaar in de weergave-instellingen.

Ga daarna terug naar de VPN-app en vraag opnieuw om goedkeuring, zodat de dialoog nieuw wordt gemaakt. Werkt de tik nu, pas dan het compatibiliteitsgedrag van de overlay aan of laat hem uit terwijl je verbindt, en houd de aanraakbescherming aan.

Kun je niet achterhalen welk venster verantwoordelijk is, verwijder ze dan een voor een en probeer de dialoog na elke wijziging. Een bedieningsbalk van een recorder of een zwevende snelkoppeling is de gebruikelijke boosdoener, en degene die je vlak voor het succes verwijderde is het antwoord.

Herstel alles wat er niet bij hoort en wat je onderweg hebt uitgezet. Een schermfilter of nachtmodus is niet de vijand; het specifieke venster dat de dialoog overlapt is dat wel.

Wat je niet moet doen om de dialoog te omzeilen

Geef een onbekende app geen toegankelijkheid zodat hij op de knop kan drukken, en installeer daarvoor geen hulpapp. Dat geeft precies de mogelijkheid die de bescherming bestaat om te weigeren, op een scherm dat een VPN machtigt.

Automatiseer de dialoog ook niet met een invoerhulpmiddel. Het levert hetzelfde resultaat als een kwaadaardige overlay en leert je niets over de oorzaak.

Op een beheerd apparaat is een beleid dat VPN-wijzigingen beperkt de beslissing van de beheerder. Een overlay-experiment is geen toestemming om dat te omzeilen. Evenzo is een niet-reagerende toestemmingsknop geen reden om certificaatverificatie te verzwakken of accountgegevens te wijzigen: geen van beide instellingen haalt een plaatselijke aanraakhindernis weg.

Als het nog steeds mislukt, meld dan het exacte gedrag

Beschrijf de dialoog, niet de conclusie: welke app om goedkeuring vroeg, of de dialoog open bleef of sloot, of andere gevoelige vragen zoals waarschuwingen over onbekende bronnen of toegankelijkheid ook tikken negeren, het apparaatmodel en de Android-versie, en de overlay- en toegankelijkheidslijsten die je hebt vastgelegd.

Vraag de supportverantwoordelijke nog één ding: of het apparaatbeleid wijzigingen in de VPN-configuratie überhaupt beperkt. Een beheerde blokkade ziet er anders uit dan een genegeerde tik, en weten welke je ziet scheelt een tweede ronde.

Die set onderscheidt een bedekt aanraakprobleem van een defect invoerapparaat, een bevroren dialoog of een beleidsblokkade. Het vertelt de volgende persoon ook of hij naar het scherm of naar het netwerk moet kijken.

De Android-richtlijnen over tapjacking behandelen de voorwaarden voor bedekte vensters en de API’s achter dit gedrag. Wil je het bewijsspoor, zoek dan FLAG_WINDOW_IS_OBSCURED en FLAG_WINDOW_IS_PARTIALLY_OBSCURED op de gebeurtenis die de knop nooit bereikte. De dialoog die open blijft is wat je moet vastleggen, omdat hij laat zien dat de tik werd tegengehouden en niet aan een ander venster gegeven.