Android ignorerer VPN-godkjenninga når du trykkjer? Sjekk overlegget først

Du trykkjer på VPN-godkjenninga og dialogen reagerer ikkje. Den naturlege konklusjonen er at VPN-appen eller serveren er øydelagd, så folk nullstiller passord, byter DNS eller installerer klienten på nytt. Vanlegvis er det ingen av desse som rører feilen, fordi Android forkastar berøringar som kjem gjennom ei hindring, og VPN-godkjenningsskjermen er nettopp den typen sensitive samtykkjespm som får det vernet. Trykket når aldri fram til knappen.

Kva vernet faktisk avviser

Android verner sensitive samhandlingar mot tapjacking, der eit anna vindauge ligg oppå ein dialog og anten stel trykket eller gjer det tvitydig. Ein view melder seg på med View.setFilterTouchesWhenObscured, og hendinga kjem med MotionEvent.FLAG_WINDOW_IS_OBSCURED når eit anna vindauge er merkt som delvis eller heilt tilslørande. Når det skjer, blir hendinga droppa i staden for å bli levert til feil stad. Android 12 (API 31) utvida det same vernet med blokkering av ubetrudde trykk i systemets samtykkjeflater, og difor kan godkjenningsdialogen avvise eit trykk frå eit overlegg som andre apper framleis ville godta.

Tre ting lagar rutinemessig ei hindring: ein app med løyvet til å vise over andre apper, ei tilgjengelegheitsteneste som teiknar innhald, og ein flytande widget frå ein skjermopptakar eller eit filterverktøy. Nokre leverandørskjermfunksjonar legg også til sitt eige lag, og difor kan den same dialogen oppføre seg annleis på to telefonar med same Android-versjon. Eit delvis tilslørande vindauge set FLAG_WINDOW_IS_PARTIALLY_OBSCURED, og trykket blir droppa før knappen i det heile ser det. Dette er ein eigenskap ved skjermen, ikkje ved nettverket. Ingenting er sendt til VPN-serveren i det augneblinken trykket blir forkasta, så inga endring på serversida kan påverke utfallet.

Skil eit dødt trykk frå ei mislukka tilkopling

Denne skilnaden er heile diagnosen, og han tek ti sekund. Viss trykket blir ignorert og dialogen står nøyaktig som før, er hindringa lokal. Viss dialogen blir lukka og ein feil viser seg etterpå, vart samtykket godteke, og du har flytta deg til eit anna stadium som treng VPN-appen sine eigne hendingsopplysningar.

Du kan stadfeste den lokale lesinga ved å sjekke om appen som ber om det i det heile prøvde ei tilkopling. Ein klient som aldri loggar eit handtrykkforsøk medan ein samtykkjedialog står på skjermen, har ikkje nådd nettverket.

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

List opp kven som har overleggsløyvet og kva tilgjengelegheitstenester som er slått på, og samanlikn det med det som køyrer. Ikkje slå av sjølve plattformvernet; det er det som hindrar eit skjult vindauge i å svare på eit samtykkjespm på dine vegner.

Fjern hindringa, og prøv så den vanlege flyten på nytt

Identifiser først appen som bad om VPN-godkjenning, slik at du veit kva samtykke du gir. Stopp så det aktuelle overlegget gjennom si eiga innstilling i staden for å trekkje tilbake eit breitt løyve du kan trengje seinare. Eit skjermfilter har vanlegvis ein brytar i sin eigen app; ein flytande widget har ei lukkekontroll; ein leverandørskjermmodus har ein brytar i Skjerminnstillingar.

Gå tilbake til VPN-appen etter det og be om godkjenning igjen, slik at dialogen blir oppretta på nytt. Viss trykket no verkar, juster kompatibilitetsoppførselen til overlegget eller la det vere av medan du koplar til, og hald berøringsvernet på.

Viss du ikkje kan avgjere kva vindauge som er ansvarleg, fjern dei eitt om gongen og prøv samtykkjedialogen på nytt etter kvar endring. Ei opptakarkontrollinje eller ein flytande snarveg er den vanlege syndaren, og det du fjerna rett før det verka, er svaret.

Gjenopprett alt urelatert du slo av undervegs. Eit skjermfilter eller ein nattmodus er ikkje fienden; det aktuelle vindauget som overlappar dialogen er det.

Kva du ikkje bør gjere for å kome forbi dialogen

Ikkje gi tilgjengelegheitstilgang til ein ukjend app slik at han kan trykkje på knappen, og ikkje installer ein hjelpeapp for det føremålet. Dei gir nøyaktig den eigenskapen vernet finst for å nekte, på ein skjerm som autoriserer VPN.

Ikkje automatiser dialogen med eit inndataverktøy heller. Det gir same resultat som eit vondsinna overlegg og lærer deg ingenting om årsaka.

På ein administrert eining er ein policy som avgrensar VPN-endringar administratoranes avgjerd. Eit overleggeksperiment er ikkje løyve til å omgå han. På same måte er ein samtykkjeknapp som ikkje reagerer inga grunn til å svekkje sertifikatverifiseringa eller endre kontopåloggingsinformasjon: ingen av innstillingane fjernar ei lokal berøringshindring.

Om det framleis feilar, rapporter den nøyaktige åtferda

Skildre dialogen i staden for konklusjonen: kva app som bad om godkjenning, om dialogen vart ståande open eller vart lukka, om andre sensitive spm som åtvaringane om ukjende kjelder eller tilgjengelegheit også ignorerer trykk, einingsmodell og Android-versjon, og overleggs- og tilgjengelegheitslistene du fanga.

Spør støtteansvarleg om eitt spørsmål til medan du er der: om einingspolicyen i det heile avgrensar endringar i VPN-konfigurasjonen. Ei administrert blokkering ser annleis ut enn eit ignorert trykk, og å vite kva du ser på sparer ein andre runde.

Dette settet skil eit tilslørt berøringsproblem frå ei øydelagd inndataeining, ein frosen dialog eller ei policyblokkering. Det fortel også neste person om dei skal sjå på skjermen eller på nettverket.

Android si rettleiing om tapjacking dekkjer vilkåra for tilslørte vindauge og API-ane bak denne oppførselen. Viss du vil ha spor av prov, sjå etter FLAG_WINDOW_IS_OBSCURED og FLAG_WINDOW_IS_PARTIALLY_OBSCURED på hendinga som aldri nådde knappen. Dialogen som blir ståande open er det du bør fange, fordi han viser at trykket vart halde tilbake i staden for levert til eit anna vindauge.