Android ignorerar trycket på VPN-godkännandet? Kontrollera överlägget först

Du trycker på knappen för VPN-godkännande och dialogrutan reagerar inte. Den naturliga slutsatsen är att VPN-appen eller servern är trasig, så folk återställer lösenord, byter DNS eller installerar om klienten. Vanligtvis rör inget av det felet, eftersom Android kastar bort tryck som kommer genom ett hinder, och VPN-godkännandets skärm är precis den sorts känsliga samtyckesfråga som får det skyddet. Trycket når aldrig knappen.

Vad skyddet faktiskt avvisar

Android skyddar känsliga interaktioner mot tapjacking, där ett annat fönster ligger ovanpå en dialogruta och antingen stjäl trycket eller gör det tvetydigt. En vy anmäler sig med View.setFilterTouchesWhenObscured, och händelsen kommer med MotionEvent.FLAG_WINDOW_IS_OBSCURED när ett annat fönster är markerat som delvis eller helt övertäckande. När det händer kastas händelsen bort i stället för att levereras till fel plats. Android 12 (API 31) utökade samma skydd med blockering av obetrodd beröring i systemets samtyckesytor, och därför kan godkännandedialogen avvisa ett tryck från ett överlägg som andra appar fortfarande skulle acceptera.

Tre saker skapar rutinmässigt ett hinder: en app med behörigheten att visa ovanpå andra appar, en tillgänglighetstjänst som ritar innehåll och en flytande widget från en skärminspelare eller ett filterverktyg. Vissa tillverkares skärmfunktioner lägger också till sitt eget lager, och därför kan samma dialogruta bete sig olika på två telefoner med samma Android-version. Ett fönster som delvis skymmer ställer in FLAG_WINDOW_IS_PARTIALLY_OBSCURED, och trycket kastas bort innan knappen ens ser det. Det här är en egenskap hos skärmen, inte hos nätverket. Ingenting har skickats till VPN-servern i det ögonblick trycket kastas bort, så ingen ändring på serversidan kan påverka resultatet.

Skilj ett dött tryck från en misslyckad anslutning

Den skillnaden är hela diagnosen och den tar tio sekunder. Om trycket ignoreras och dialogrutan står exakt som förut är hindret lokalt. Om dialogrutan stängs och ett fel visas efteråt godtogs samtycket och du har flyttat dig till ett annat steg som behöver VPN-appens egna händelseuppgifter.

Du kan bekräfta den lokala läsningen genom att kontrollera om appen som begär det ens försökte ansluta. En klient som aldrig loggar ett handskakningsförsök medan en samtyckesdialog står på skärmen har inte nått nätverket.

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

Lista vad som har överläggsbehörigheten och vilka tillgänglighetstjänster som är aktiva, och jämför det med det som körs. Stäng inte av själva plattformsskyddet; det är det som hindrar ett dolt fönster från att svara på en samtyckesfråga i ditt ställe.

Ta bort hindret och försök sedan igen med det vanliga flödet

Identifiera först appen som begärde VPN-godkännande, så att du vet vilket samtycke du ger. Stoppa sedan det specifika överlägget via dess egen inställning i stället för att återkalla en bred behörighet som du kan behöva senare. Ett skärmfilter har vanligtvis en växel i sin egen app; en flytande widget har en stängningskontroll; ett tillverkarläget för skärmen har en växel i skärminställningarna.

Gå tillbaka till VPN-appen efter det och begär godkännande igen, så att dialogrutan skapas på nytt. Om trycket nu fungerar justerar du överläggets kompatibilitetsbeteende eller låter det vara avstängt medan du ansluter, och behåller beröringsskyddet påslaget.

Om du inte kan avgöra vilket fönster som är ansvarigt tar du bort dem ett i taget och försöker igen med samtyckesdialogrutan efter varje ändring. En inspelares kontrollrad eller en flytande genväg är den vanliga boven, och det du tog bort precis innan det fungerade är svaret.

Återställ allt orelaterat som du stängde av på vägen. Ett skärmfilter eller ett nattläge är inte fienden; det specifika fönstret som överlappar dialogrutan är det.

Vad du inte bör göra för att komma förbi dialogrutan

Ge inte tillgänglighetsåtkomst till en okänd app så att den kan trycka på knappen, och installera inte en hjälparapp för det syftet. De ger precis den förmåga som skyddet finns för att neka, på en skärm som auktoriserar en VPN.

Automatisera inte heller dialogrutan med ett inmatningsverktyg. Det ger samma resultat som ett skadligt överlägg och lär dig ingenting om orsaken.

På en hanterad enhet är en policy som begränsar VPN-ändringar administratörens beslut. Ett överläggsexperiment är inte tillstånd att kringgå den. På samma sätt är en samtyckesknapp som inte reagerar inget skäl att försvaga certifikatverifieringen eller ändra kontouppgifterna: ingen av inställningarna tar bort ett lokalt hinder för beröring.

Om det fortfarande misslyckas, rapportera det exakta beteendet

Beskriv dialogrutan i stället för slutsatsen: vilken app som begärde godkännande, om dialogrutan stannade öppen eller stängdes, om andra känsliga frågor som varningarna om okända källor eller tillgänglighet också ignorerar tryck, enhetsmodell och Android-version, samt listorna över överlägg och tillgänglighetstjänster som du fångade.

Fråga supportansvarig en sak till medan du är där: om enhetspolicyn över huvud taget begränsar ändringar i VPN-konfigurationen. En hanterad blockering ser annorlunda ut än ett ignorerat tryck, och att veta vilken du tittar på sparar en andra runda.

Den här uppsättningen skiljer ett skymt beröringsproblem från en trasig inmatningsenhet, en frusen dialogruta eller en policyblockering. Den talar också om för nästa person om de ska titta på skärmen eller på nätverket.

Androids vägledning om tapjacking täcker villkoren för skymda fönster och API:erna bakom det här beteendet. Om du vill ha beviskedjan letar du efter FLAG_WINDOW_IS_OBSCURED och FLAG_WINDOW_IS_PARTIALLY_OBSCURED på händelsen som aldrig nådde knappen. Dialogrutan som blir kvar öppen är det du bör fånga, eftersom den visar att trycket hölls tillbaka i stället för att levereras till ett annat fönster.