Ĉu Android ignoras la frapeton de VPN-aprobo? Kontrolu unue la supermeton

Vi frapetas la butonon de VPN-aprobo kaj la dialogo ne reagas. La natura konkludo estas, ke la aplikaĵo aŭ la servilo paneis, do homoj restarigas pasvortojn, ŝanĝas DNS aŭ reinstalas la klienton. Kutime nenio el tio tuŝas la kaŭzon, ĉar Android forĵetas tuŝojn, kiuj alvenas tra baro, kaj la ekrano de VPN-aprobo estas ĝuste tia sentema konsenta dialogo. La frapeto neniam atingas la butonon.

Kion la protekto efektive rifuzas

Android protektas sentemajn interagojn kontraŭ tapjacking, kie alia fenestro sidas super la dialogo kaj ŝtelas la frapeton aŭ igas ĝin dusenca. Vido aliĝas per View.setFilterTouchesWhenObscured, kaj la evento alvenas kun MotionEvent.FLAG_WINDOW_IS_OBSCURED kiam alia fenestro estas markita kiel parte aŭ plene kaŝanta. Tiam la evento estas forĵetita anstataŭ liverita al la malĝusta loko. Android 12 (API 31) etendis la saman protekton per blokado de nefidindaj tuŝoj en sistemaj konsentaj surfacoj, kaj tial la aproba dialogo povas rifuzi frapeton el supermeto, kiun aliaj aplikaĵoj ankoraŭ akceptus.

Tri aferoj rutine kreas baron: aplikaĵo kun permeso montriĝi super aliaj aplikaĵoj, alirebla servo, kiu desegnas enhavon, kaj flosanta fenestraĵo de ekranregistrilo aŭ filtrilo. Iuj ekranfunkcioj de la fabrikanto aldonas sian propran tavolon, kaj tial la sama dialogo povas konduti malsame sur du telefonoj kun la sama Android-versio. Parte kaŝanta fenestro agordas FLAG_WINDOW_IS_PARTIALLY_OBSCURED, kaj la tuŝo estas forĵetita antaŭ ol la butono eĉ vidas ĝin. Tio estas eco de la ekrano, ne de la reto. Nenio estis sendita al la VPN-servilo en la momento de la forĵeto, do neniu ŝanĝo ĉe la servilo povas influi la rezulton.

Apartigu mortan frapeton de malsukcesa konekto

La distingo estas la tuta diagnozo kaj daŭras dek sekundojn. Se la frapeto estas ignorata kaj la dialogo restas precize kiel ĝi estis, la baro estas loka. Se la dialogo fermiĝas kaj poste aperas eraro, la konsento estis akceptita kaj vi transiris al alia stadio, kiu bezonas la proprajn eventajn informojn de la aplikaĵo.

Vi povas konfirmi la lokan legadon per kontrolo, ĉu la petanta aplikaĵo entute provis konekton. Kliento, kiu neniam registras manpreman provon dum la konsenta dialogo estas sur la ekrano, ne atingis la reton.

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

Listigu, kiu tenas la supermetan permeson kaj kiuj alireblaj servoj estas ŝaltitaj, poste komparu kun tio, kio funkcias. Ne malŝaltu la protekton de la platformo mem; ĝi estas tio, kio malhelpas kaŝitan fenestron respondi konsentan dialogon anstataŭ vi.

Forigu la baron, poste reprovu la normalan fluon

Unue identigu, kiu aplikaĵo petis VPN-aprobon, por ke vi sciu, kian konsenton vi donas. Poste haltigu la konkretan supermetaĵon per ĝia propra agordo, ne per retiro de larĝa permeso, kiun vi eble bezonos poste. Ekranfiltrilo kutime havas ŝaltilon en sia propra aplikaĵo; flosanta fenestraĵo havas fermilon; ekranreĝimo de la fabrikanto havas ŝaltilon en la ekranagordoj.

Poste revenu al la VPN-aplikaĵo kaj denove petu aprobon, por ke la dialogo estu kreita denove. Se la frapeto nun funkcias, ĝustigu la kongruan konduton de la supermetaĵo aŭ lasu ĝin malŝaltita dum vi konektiĝas, kaj tenu la tuŝprotekton ŝaltita.

Se vi ne povas determini, kiu fenestro respondecas, forigu ilin unu post la alia kaj reprovu la konsentan dialogon post ĉiu ŝanĝo. Stirbreto de registrilo aŭ flosanta fulmoklavo estas la kutima kaŭzanto, kaj tio, kion vi forigis tuj antaŭ la sukceso, estas la respondo.

Restarigu ĉion nerilatan, kion vi malŝaltis survoje. Ekranfiltrilo aŭ nokta reĝimo ne estas la malamiko; la konkreta fenestro, kiu surmetiĝas al la dialogo, estas.

Kion ne fari por preterpasi la dialogon

Ne donu alireblecon al nekonata aplikaĵo por ke ĝi premu la butonon, kaj ne instalus helpan aplikaĵon por tio. Tio donas ĝuste la kapablon, kiun la protekto ekzistas por rifuzi, sur ekrano, kiu rajtigas VPN.

Ne aŭtomatigu la dialogon per eniga ilo. Ĝi donas la saman rezulton kiel malica supermetaĵo kaj instruas al vi nenion pri la kaŭzo.

Sur administrata aparato, politiko, kiu limigas VPN-ŝanĝojn, estas decido de la administranto. Eksperimento kun supermetaĵo ne estas rajtigo eviti ĝin. Same, butono de konsento, kiu ne reagas, ne estas kialo malfortigi atestilan kontrolon aŭ ŝanĝi kontajn akreditaĵojn: nek unu nek la alia agordo forigas lokan tuŝbaron.

Se ĝi ankoraŭ malsukcesas, raportu la precizan konduton

Priskribu la dialogon, ne la konkludon: kiu aplikaĵo petis aprobon, ĉu la dialogo restis malfermita aŭ fermiĝis, ĉu aliaj sentemaj petoj kiel avertoj pri nekonataj fontoj aŭ alirebleco ankaŭ ignoras frapetojn, la aparatmodelo kaj la Android-versio, kaj la listoj de supermetaĵoj kaj alirebleco, kiujn vi kolektis.

Demandu la subtenposedanton ankoraŭ unu aferon: ĉu la aparatpolitiko limigas ŝanĝojn de VPN-agordo entute. Administrata blokado aspektas alie ol ignorata frapeto, kaj scii, kion vi vidas, ŝparas duan raŭndon.

Tiu aro distingas kaŝitan tuŝproblemon de difektita eniga aparato, frostigita dialogo aŭ politika blokado. Ĝi ankaŭ diras al la sekva persono, ĉu rigardi la ekranon aŭ la reton.

La gvidilo de Android pri tapjacking kovras la kondiĉojn de kaŝitaj fenestroj kaj la API-ojn malantaŭ ĉi tiu konduto. Se vi volas la spuron de pruvoj, serĉu FLAG_WINDOW_IS_OBSCURED kaj FLAG_WINDOW_IS_PARTIALLY_OBSCURED ĉe la evento, kiu neniam atingis la butonon. La dialogo, kiu restas malfermita, estas tio, kion oni devas kapti, ĉar ĝi montras, ke la frapeto estis retenita kaj ne transdonita al alia fenestro.