Android overser VPN-godkjenningen du trykker på? Sjekk overlegget først

Du trykker på knappen for VPN-godkjenning, og dialogen gjør ingenting. Det er lett å konkludere med at VPN-appen eller serveren har en feil, og derfor nullstiller folk passord, bytter DNS eller legger inn klienten på nytt. Som oftest er det ingen av disse tingene som berører problemet, fordi Android kaster bort berøringer som kommer gjennom en hindring, og VPN-godkjenningsskjermen er akkurat en slik sensitiv samtykkedialog som får denne beskyttelsen. Trykket når aldri knappen.

Hva beskyttelsen egentlig avviser

Android verner sensitive handlinger mot tapjacking, der et annet vindu ligger over en dialog og enten kaprer trykket eller gjør det uklart. En visning aktiverer dette med View.setFilterTouchesWhenObscured, og hendelsen kommer med MotionEvent.FLAG_WINDOW_IS_OBSCURED når et annet vindu er registrert som delvis eller helt tilslørende. Når det skjer, blir hendelsen forkastet i stedet for å bli sendt til feil mottaker. Android 12 (API 31) bygget ut den samme beskyttelsen med blokkering av ikke-klarerte trykk i systemets samtykkeflater, og det er grunnen til at godkjenningsdialogen kan avslå et trykk fra et overlegg som andre apper fortsatt ville godtatt.

Tre forhold skaper vanligvis en hindring: en app som har tillatelse til å vise over andre apper, en tilgjengelighetstjeneste som tegner innhold, og en flytende widget fra en skjermopptaker eller et filterverktøy. Noen produsenters skjermfunksjoner legger også på sitt eget lag, og derfor kan den samme dialogen oppføre seg ulikt på to telefoner med samme Android-versjon. Et delvis tilslørende vindu setter FLAG_WINDOW_IS_PARTIALLY_OBSCURED, og trykket forkastes før knappen i det hele tatt mottar det. Dette er en egenskap ved skjermen, ikke ved nettet. Ingenting er sendt til VPN-serveren i det øyeblikket trykket forkastes, så ingen endring på serveren kan påvirke resultatet.

Skille et dødt trykk fra en mislykket tilkobling

Denne forskjellen utgjør hele diagnosen, og den tar ti sekunder. Dersom trykket overses og dialogen står helt uendret, er hindringen lokal. Dersom dialogen lukker seg og det kommer en feilmelding etterpå, ble samtykket godtatt, og du har gått videre til en annen fase som trenger VPN-appens egne hendelsesdata.

Du kan bekrefte den lokale tolkningen ved å kontrollere om appen som spør i det hele tatt forsøkte å koble til. En klient som aldri registrerer et håndtrykksforsøk mens en samtykkedialog vises, har ikke nådd nettet.

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

Skriv opp hva som har overleggstillatelsen og hvilke tilgjengelighetstjenester som er aktive, og hold det opp mot det som faktisk kjører. Ikke skru av selve plattformbeskyttelsen; det er den som forhindrer at et skjult vindu svarer på en samtykkedialog på dine vegne.

Fjern hindringen, og gjenta deretter den normale flyten

Finn først ut hvilken app som ba om VPN-godkjenning, slik at du vet hva du samtykker til. Deretter stopper du det bestemte overlegget via innstillingen i den appen, i stedet for å trekke en bred tillatelse du kan få bruk for senere. Et skjermfilter har som regel en av/på-bryter i sin egen app; en flytende widget har en lukkeknapp; en produsentmodus for skjermen har en bryter i Skjerminnstillinger.

Gå så tilbake til VPN-appen og be om godkjenning på nytt, slik at dialogen blir opprettet fra bunnen av. Virker trykket nå, justerer du overleggets kompatibilitetsoppførsel eller lar det være slått av mens du kobler til, og du beholder berøringsbeskyttelsen på.

Klarer du ikke å avgjøre hvilket vindu som er årsaken, fjerner du dem ett av gangen og prøver samtykkedialogen på nytt etter hver endring. En kontrollinje fra en opptaker eller en flytende snarvei er som regel synderen, og det du fjernet rett før det fungerte, er svaret.

Slå på igjen alt urelatert som du skrudde av underveis. Et skjermfilter eller en nattmodus er ikke problemet; det er det bestemte vinduet som ligger over dialogen.

Hva du ikke bør gjøre for å komme rundt dialogen

Ikke gi tilgjengelighetstilgang til en app du ikke kjenner, for at den skal kunne trykke på knappen, og ikke installer en hjelpeapp for dette. Slike apper gir nettopp den muligheten beskyttelsen skal hindre, på en skjerm som gir VPN-tillatelse.

Ikke sett i gang automatisering av dialogen med et inndataverktøy heller. Det gir samme resultat som et ondsinnet overlegg og lærer deg ingenting om årsaken.

På en administrert enhet er en policy som begrenser VPN-endringer, en beslutning fra administratoren. Et overleggseksperiment er ikke tillatelse til å omgå den. På samme måte er en samtykkeknapp som ikke reagerer, ingen grunn til å svekke sertifikatkontrollen eller endre innloggingsdetaljene for kontoen: ingen av disse innstillingene fjerner en lokal hindring for berøring.

Hvis det fortsatt ikke virker, rapporter nøyaktig oppførsel

Beskriv dialogen og ikke konklusjonen: hvilken app som ba om godkjenning, om dialogen ble stående åpen eller lukket seg, om andre sensitive meldinger som advarslene om ukjente kilder eller tilgjengelighet også overser trykk, enhetsmodell og Android-versjon, og listene over overlegg og tilgjengelighetstjenester som du tok med.

Still støtteansvarlig ett spørsmål til mens du er der: om enhetspolicyen i det hele tatt begrenser endringer i VPN-oppsettet. En administrert blokkering ser annerledes ut enn et oversett trykk, og når du vet hvilken av dem du står overfor, sparer du en runde til.

Dette settet skiller et tilslørt berøringsproblem fra en defekt inndataenhet, en fastlåst dialog eller en policyblokkering. Det forteller også den neste personen om de skal se på skjermen eller på nettet.

Veiledningen om tapjacking fra Android dekker vilkårene for tilslørte vinduer og API-ene som ligger bak denne oppførselen. Ønsker du beviskjeden, ser du etter FLAG_WINDOW_IS_OBSCURED og FLAG_WINDOW_IS_PARTIALLY_OBSCURED på hendelsen som aldri nådde knappen. Dialogen som blir stående åpen, er det du bør fange opp, fordi den viser at trykket ble holdt tilbake og ikke levert til et annet vindu.