Du trykker på knappen til VPN-godkendelse, og dialogen reagerer ikke. Den naturlige konklusion er, at appen eller serveren er i stykker, så folk nulstiller adgangskoder, skifter DNS eller geninstallerer klienten. Normalt rammer intet af det fejlen, fordi Android kasserer tryk, der ankommer gennem en forhindring, og VPN-godkendelsesskærmen er netop den slags følsomme samtykkedialog. Trykket når aldrig knappen.

Hvad beskyttelsen faktisk afviser

Android beskytter følsomme interaktioner mod tapjacking, hvor et andet vindue sidder oven på dialogen og stjæler trykket eller gør det tvetydigt. En visning tilmelder sig med View.setFilterTouchesWhenObscured, og hændelsen ankommer med MotionEvent.FLAG_WINDOW_IS_OBSCURED, når et andet vindue er markeret som delvist eller fuldt tildækkende. Så kasseres hændelsen i stedet for at blive leveret det forkerte sted. Android 12 (API 31) udvidede den samme beskyttelse med blokering af ubetroede tryk i systemets samtykkeflader, og derfor kan godkendelsesdialogen afvise et tryk fra en overlejring, som andre apps stadig ville acceptere.

Tre ting skaber rutinemæssigt en forhindring: en app med tilladelse til at vise over andre apps, en tilgængelighedstjeneste der tegner indhold, og en flydende widget fra en skærmoptager eller et filterværktøj. Nogle skærmfunktioner fra producenten lægger deres eget lag ovenpå, og derfor kan den samme dialog opføre sig forskelligt på to telefoner med samme Android-version. Et delvist tildækkende vindue sætter FLAG_WINDOW_IS_PARTIALLY_OBSCURED, og trykket kasseres, før knappen overhovedet ser det. Det er en egenskab ved skærmen, ikke ved netværket. Intet er sendt til VPN-serveren i det øjeblik trykket kasseres, så ingen ændring på serversiden kan påvirke resultatet.

Skeln et dødt tryk fra en mislykket forbindelse

Forskellen er hele diagnosen, og den tager ti sekunder. Hvis trykket ignoreres, og dialogen står præcis som før, er forhindringen lokal. Hvis dialogen lukker, og der bagefter vises en fejl, blev samtykket accepteret, og du er i en anden fase, som har brug for appens egne hændelsesoplysninger.

Du kan bekræfte den lokale læsning ved at kontrollere, om den anmodende app overhovedet forsøgte en forbindelse. En klient, der aldrig registrerer et håndtryksforsøg, mens samtykkedialogen er på skærmen, er ikke nået til netværket.

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

List, hvem der har overlejringstilladelsen, og hvilke tilgængelighedstjenester der er slået til, og sammenlign med det, der kører. Slå ikke platformens beskyttelse fra; den er det, der forhindrer et skjult vindue i at svare på en samtykkedialog på dine vegne.

Fjern forhindringen, og prøv det normale flow igen

Find først ud af, hvilken app der bad om VPN-godkendelse, så du ved, hvilket samtykke du giver. Stop derefter den konkrete overlejring via dens egen indstilling, ikke ved at trække en bred tilladelse tilbage, som du måske får brug for senere. Et skærmfilter har som regel en kontakt i sin egen app; en flydende widget har en lukkekontrol; en skærmtilstand fra producenten har en kontakt i skærmindstillingerne.

Gå derefter tilbage til VPN-appen, og bed om godkendelse igen, så dialogen oprettes på nytt. Virker trykket nu, kan du justere overlejringens kompatibilitetsadfærd eller lade den være slukket, mens du forbinder, og beholde berøringsbeskyttelsen slået til.

Kan du ikke afgøre, hvilket vindue der er ansvarligt, så fjern dem ét ad gangen, og prøv samtykkedialogen efter hver ændring. En optagers kontrolbjælke eller en flydende genvej er den sædvanlige synder, og det, du fjernede lige før det virkede, er svaret.

Gendan alt urelateret, som du slog fra undervejs. Et skærmfilter eller en natfunktion er ikke fjenden; det konkrete vindue, der overlapper dialogen, er.

Hvad du ikke skal gøre for at komme forbi dialogen

Giv ikke en ukendt app tilgængelighed, så den kan trykke på knappen, og installer ikke en hjælpeapp til det. Det giver netop den evne, som beskyttelsen findes for at nægte, på en skærm der godkender en VPN.

Automatiser heller ikke dialogen med et inputværktøj. Det giver samme resultat som en ondsindet overlejring og lærer dig intet om årsagen.

På en administreret enhed er en politik, der begrænser VPN-ændringer, administratorernes beslutning. Et overlejringseksperiment er ikke tilladelse til at omgå den. På samme måde er en knap, der ikke reagerer, ingen grund til at svække certifikatvalideringen eller ændre kontoopplysninger: ingen af de to indstillinger fjerner en lokal berøringsforhindring.

Hvis det stadig fejler, så beskriv den præcise adfærd

Beskriv dialogen, ikke konklusionen: hvilken app der bad om godkendelse, om dialogen blev stående åben eller lukkede, om andre følsomme anmodninger som advarsler om ukendte kilder eller tilgængelighed også ignorerer tryk, enhedsmodellen og Android-versionen samt de overlejrings- og tilgængelighedslister, du har samlet.

Spørg supportejeren om en ting mere, mens du er der: om enhedspolitikken overhovedet begrænser ændringer af VPN-konfigurationen. En administreret blokering ser anderledes ud end et ignoreret tryk, og det at vide, hvad du ser, sparer en anden runde.

Det sæt adskiller et tildækket berøringsproblem fra en defekt inputenhed, en frossen dialog eller en politikblokering. Det fortæller også den næste person, om de skal kigge på skærmen eller på netværket.

Androids vejledning om tapjacking dækker betingelserne for tildækkede vinduer og de APIer, der ligger bag denne adfærd. Vil du have spor af beviser, så se efter FLAG_WINDOW_IS_OBSCURED og FLAG_WINDOW_IS_PARTIALLY_OBSCURED på den hændelse, der aldrig nåede knappen. Dialogen, der bliver stående åben, er det, du skal fange, fordi den viser, at trykket blev tilbageholdt og ikke leveret til et andet vindue.

Relaterede artikler