Android ignora o toque de aprobación de VPN? Mira primeiro a superposición

Tocas o botón de aprobación de VPN e o diálogo non reacciona. A conclusión natural é que a aplicación ou o servidor están rotos, así que a xente restablece contrasinais, cambia o DNS ou reinstala o cliente. Normalmente nada diso toca a causa, porque Android descarta os toques que chegan a través dun obstáculo, e a pantalla de aprobación de VPN é exactamente ese tipo de diálogo de consentimento sensible. O toque nunca chega ao botón.

Que rexeita realmente a protección

Android protexe as interaccións sensibles contra o tapjacking, no que outra ventá se sitúa sobre o diálogo e rouba o toque ou o fai ambiguo. Unha vista adhírese con View.setFilterTouchesWhenObscured, e o evento chega con MotionEvent.FLAG_WINDOW_IS_OBSCURED cando outra ventá está marcada como parcial ou totalmente obstructiva. Entón o evento descártase en vez de entregarse ao lugar equivocado. Android 12 (API 31) ampliou a mesma protección co bloqueo de toques non fiables nas superficies de consentimento do sistema, e por iso o diálogo de aprobación pode rexeitar un toque dunha superposición que outras aplicacións aínda aceptarían.

Tres cousas producen un obstáculo con regularidade: unha aplicación con permiso para mostrarse sobre outras aplicacións, un servizo de accesibilidade que debuxa contido e un widget flotante dun gravador de pantalla ou dunha ferramenta de filtro. Algunhas funcións de pantalla do fabricante engaden a súa propia capa, e por iso o mesmo diálogo pode comportarse distinto en dous teléfonos coa mesma versión de Android. Unha ventá que obstruye parcialmente establece FLAG_WINDOW_IS_PARTIALLY_OBSCURED, e o toque descártase antes de que o botón chegue a vello. É unha propiedade da pantalla, non da rede. Non se enviou nada ao servidor de VPN no momento de descartar o toque, así que ningún cambio no servidor pode influír no resultado.

Separa un toque morto dunha conexión fallida

A distinción é todo o diagnóstico e custa dez segundos. Se se ignora o toque e o diálogo segue exactamente igual, o obstáculo é local. Se o diálogo se pecha e despois aparece un erro, o consentimento aceptouse e pasaches a outra etapa que necesita a información de eventos da propia aplicación.

Podes confirmar a lectura local comprobando se a aplicación solicitante chegou a intentar unha conexión. Un cliente que nunca rexistra un intento de handshake mentres o diálogo de consentimento está na pantalla non chegou á rede.

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

Enumera quen ten o permiso de superposición e que servizos de accesibilidade están activos, e compárao co que se está executando. Non desactives a protección da plataforma; é o que impide que unha ventá oculta responda por ti a un diálogo de consentimento.

Retira o obstáculo e tenta de novo o fluxo normal

Identifica primeiro que aplicación pediu a aprobación de VPN, para saber que consentimento concedes. Despois detén a superposición concreta desde o seu propio axuste, non revogando un permiso amplo que poidas necesitar máis adiante. Un filtro de pantalla adoita ter un interruptor na súa aplicación; un widget flotante ten un control de peche; un modo de pantalla do fabricante ten un interruptor nos axustes de pantalla.

Volve despois á aplicación de VPN e solicita a aprobación outra vez, para que o diálogo se cree de novo. Se agora o toque funciona, axusta o comportamento de compatibilidade da superposición ou déixaa apagada mentres te conectas, e mantén activa a protección de toque.

Se non sabes que ventá é a responsable, retíraas dunha en unha e repite o diálogo de consentimento tras cada cambio. A barra de control dun gravador ou un atallo flotante adoita ser o culpable, e a que retiraches xusto antes de que funcionase é a resposta.

Restaura calquera cousa non relacionada que desactivas polo camiño. Un filtro de pantalla ou un modo nocturno non son o inimigo; o é a ventá concreta que se superpón ao diálogo.

Que non facer para pasar o diálogo

Non concedas accesibilidade a unha aplicación descoñecida para que prema o botón, nin instales unha aplicación auxiliar para iso. Iso entrega exactamente a capacidade que a protección existe para denegar, nunha pantalla que autoriza unha VPN.

Tampouco automatices o diálogo cunha ferramenta de entrada. Produce o mesmo resultado que unha superposición maliciosa e non che ensina nada sobre a causa.

Nun dispositivo xestionado, unha política que restrinxe os cambios de VPN é decisión do administrador. Un experimento con superposicións non é autorización para saltala. Igualmente, un botón de consentimento que non responde non é motivo para debilitar a verificación de certificados nin para cambiar as credenciais da conta: ningún dos dous axustes elimina un obstáculo local de toque.

Se segue fallando, informa do comportamento exacto

Describe o diálogo, non a conclusión: que aplicación pediu a aprobación, se o diálogo quedou aberto ou se pechou, se outros avisos sensibles como as advertencias de orixes descoñecidas ou de accesibilidade tamén ignoran os toques, o modelo do dispositivo e a versión de Android, e as listas de superposicións e accesibilidade que capturases.

Pregunta unha cousa máis ao responsable de soporte: se a política do dispositivo restrinxe os cambios de configuración de VPN. Un bloqueo xestionado vese distinto dun toque ignorado, e saber cal tes diante aforra unha segunda rolda.

Ese conxunto distingue un problema de toque obstruído dun dispositivo de entrada roto, un diálogo conxelado ou un bloqueo de política. Tamén lle di á seguinte persoa se debe mirar a pantalla ou a rede.

A guía de Android sobre tapjacking cobre as condicións de ventás obstruídas e as API detrás deste comportamento. Se queres o rastro de probas, busca FLAG_WINDOW_IS_OBSCURED e FLAG_WINDOW_IS_PARTIALLY_OBSCURED no evento que nunca chegou ao botón. O diálogo que queda aberto é o que hai que capturar, porque mostra que o toque se retivo e non se entregou a outra ventá.