Android ignoreer jou tik op VPN-goedkeuring? Kyk eerste na die oorlegsel

Jy tik op die VPN-goedkeuringsknoppie en die venster reageer nie. Die natuurlike gevolgtrekking is dat die toep of die bediener foutief is, en dus stel mense wagwoorde terug, verander DNS of herinstalleer die kliënt. Gewoonlik raak niks daarvan die fout nie, want Android laat aanrakiings val wat deur ’n hindernis aankom, en die goedkeuringskerm van die VPN is juis so ’n sensitiewe toestemmingsvenster. Die tik bereik nooit die knoppie nie.

Wat die beskerming eintlik verwerp

Android beskerm sensitiewe interaksies teen tapjacking, waar ’n ander venster bo-op ’n dialoog sit en die tik steel of dubbelsinnig maak. ’n Aansig sluit in met View.setFilterTouchesWhenObscured, en die gebeurtenis kom met MotionEvent.FLAG_WINDOW_IS_OBSCURED wanneer ’n ander venster as gedeeltelik of volledig bedekkend gemerk is. Dan word die gebeurtenis weggegooi eerder as na die verkeerde plek gestuur. Android 12 (API 31) het dieselfde beskerming uitgebrei met die blokkering van onbetroubare aanrakiings in stelsel-toestemmingsvlakke, en daarom kan die goedkeuringsdialoog ’n tik weier van ’n oorlegsel wat ander toeps steeds sou aanvaar.

Drie dinge veroorsaak gereeld ’n hindernis: ’n toep met die toestemming om oor ander toeps te vertoon, ’n toeganklikheidsdiens wat inhoud teken, en ’n swewende widget van ’n skermopnemer of ’n filterinstrument. Sommige vervaardiger-vertoningsfunksies voeg ook hul eie laag by, en daarom kan dieselfde dialoog anders optree op twee telefone met dieselfde Android-weergawe. ’n Gedeeltelik bedekkende venster stel FLAG_WINDOW_IS_PARTIALLY_OBSCURED, en die tik word weggegooi voordat die knoppie dit ooit sien. Dit is ’n eienskap van die skerm, nie van die netwerk nie. Niks is na die VPN-bediener gestuur toe die tik verwerp is nie, so geen verandering aan die bedienerkant kan die uitkoms beïnvloed nie.

Skei ’n dooie tik van ’n mislukte verbinding

Die onderskeid is die hele diagnose en dit neem tien sekondes. As die tik geïgnoreer word en die dialoog presies bly soos dit was, is die hindernis plaaslik. As die dialoog sluit en daarna ’n fout verskyn, is die toestemming aanvaar en is jy in ’n ander stadium wat die toep se eie gebeurtenisinligting nodig het.

Jy kan die plaaslike lees bevestig deur na te gaan of die versoekende toep selfs ’n verbinding probeer het. ’n Kliënt wat nooit ’n handshake-poging aanteken terwyl ’n toestemmingsdialoog op die skerm is nie, het nie die netwerk bereik nie.

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

Lys wat die oorlegseltoestemming het en watter toeganklikheidsdienste geaktiveer is, en pas dit teen die lopende programme. Moenie die platform se beskerming self afskakel nie; dit is juis wat verhoed dat ’n versteekte venster namens jou ’n toestemmingsvenster beantwoord.

Verwyder die hindernis en probeer dan die normale vloei

Identifiseer eers die toep wat VPN-goedkeuring versoek het, sodat jy weet watter toestemming jy gee. Stop dan die spesifieke oorlegsel deur sy eie instelling eerder as deur ’n breë toestemming te herroep wat jy later nodig mag hê. ’n Skermfilter het gewoonlik ’n skakelaar in sy eie toep; ’n swewende widget het ’n sluitbeheer; ’n vervaardiger-vertoningsmodus het ’n skakelaar in Vertoning-instellings.

Gaan daarna terug na die VPN-toep en vra weer goedkeuring, sodat die dialoog nuut geskep word. As die tik nou werk, pas die oorlegsel se versoenbaarheidsgedrag aan of laat dit af terwyl jy koppel, en hou die aanraakbeskerming aan.

As jy nie kan sê watter venster verantwoordelik is nie, verwyder hulle een op ’n slag en probeer die toestemmingsdialoog ’ná elke verandering. ’n Opnemer se beheerbalk of ’n swewende kortpad is die gewone oortreder, en die een wat jy net voor die sukses verwyder het, is die antwoord.

Herstel enigiets onverwants wat jy onderweg afgeskakel het. ’n Skermfilter of ’n nagmodus is nie die vyand nie; die spesifieke venster wat die dialoog oorvleuel, is.

Wat nie te doen om verby die dialoog te kom

Moenie toeganklikheidstoegang aan ’n onbekende toep gee sodat dit die knoppie kan druk nie, en moenie ’n hulptoep daarvoor installeer nie. Dit gee juis die vermoë wat die beskerming wil weier, op ’n skerm wat ’n VPN magtig.

Moenie die dialoog met ’n invoerinstrument outomatiseer nie. Dit lewer dieselfde resultaat as ’n kwaadwillige oorlegsel en leer jou niks oor die oorsaak nie.

Op ’n bestuurde toestel is ’n beleid wat VPN-veranderinge beperk, die administrateur se besluit. ’n Oorlegsel-eksperiment is nie magtiging om dit te omseil nie. Net so is ’n onreageerende toestemmingsknoppie geen rede om sertifikaatverifikasie te verswak of rekeningbewyse te verander nie: nie een van die twee instellings verwyder ’n plaaslike aanraakhindernis nie.

As dit steeds misluk, rapporteer die presiese gedrag

Beskryf die dialoog eerder as die gevolgtrekking: watter toep goedkeuring versoek het, of die dialoog oopgebly of gesluit het, of ander sensitiewe vrae soos die onbekende-bronne- of toeganklikheidswaarskuwings ook tikke ignoreer, die toestelmodel en Android-weergawe, en die oorlegsel- en toeganklikheidslyste wat jy vasgevang het.

Vra die ondersteuningspan nog een vraag terwyl jy daar is: of die toestelbeleid VPN-opstellingsveranderings hoegenaamd beperk. ’n Bestuurde blokkade lyk anders as ’n geïgnoreerde tik, en om te weet watter een jy sien, spaar ’n tweede rondte.

Daardie stel onderskei ’n bedekte-aanraakprobleem van ’n stukkende invoertoestel, ’n gevriesde dialoog of ’n beleidsblokkade. Dit sê ook vir die volgende persoon of hy na die skerm of na die netwerk moet kyk.

Die Android-riglyne oor tapjacking dek die bedekte-venster-toestande en die API agter hierdie gedrag. Vir die bewysketting, soek FLAG_WINDOW_IS_OBSCURED en FLAG_WINDOW_IS_PARTIALLY_OBSCURED op die gebeurtenis wat nooit die knoppie bereik het nie. Die dialoog wat oop bly, is die ding om vas te vang, want dit wys die tik is weerhou eerder as aan ’n ander venster gelewer.