Android Ignores the VPN Approval Tap? Check the Overlay First

You tap the VPN approval button and the dialog does not react. The natural conclusion is that the VPN app or the server is broken, so people reset passwords, change DNS or reinstall the client. In the usual case none of that touches the fault, because Android discards touches that arrive through an obstruction, and the VPN approval screen is exactly the kind of sensitive consent prompt that gets that protection. The tap never reaches the button.

What the protection is actually rejecting

Android guards sensitive interactions against tapjacking, where another window sits on top of a dialog and either steals the tap or makes it ambiguous. A view opts in with View.setFilterTouchesWhenObscured, and the event arrives carrying MotionEvent.FLAG_WINDOW_IS_OBSCURED when another window is marked as partially or fully obscuring it. When that happens the event is dropped rather than delivered to the wrong place. Android 12 (API 31) extended the same protection with untrusted-touch blocking in system consent surfaces, which is why the approval dialog can refuse a tap from an overlay that other apps would still accept.

Three things routinely produce an obstruction: an app holding the display-over-other-apps permission, an accessibility service drawing content, and a floating widget from a screen recorder or a filter tool. Some vendor display features add their own layer as well, which is why the same dialog can behave differently on two phones running the same Android release. A partially obscuring window sets FLAG_WINDOW_IS_PARTIALLY_OBSCURED, and the touch is dropped before the button ever sees it. This is a property of the screen, not of the network. Nothing has been sent to the VPN server at the moment the tap is discarded, so no server-side change can influence the outcome.

Separate a dead tap from a failed connection

The distinction is the whole diagnosis and it takes ten seconds. If the tap is ignored and the dialog stays exactly as it was, the obstruction is local. If the dialog closes and an error appears afterwards, the consent was accepted and you have moved into a different stage that needs the VPN app's own event information.

You can confirm the local reading by checking whether the requesting app even attempted a connection. A client that never logs a handshake attempt while a consent dialog is on screen has not reached the network.

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

List what holds the overlay permission and which accessibility services are enabled, then match those against what is running. Do not disable the platform protection itself; it is the thing preventing a hidden window from answering a consent prompt on your behalf.

Clear the obstruction, then retry the normal flow

Identify the app that requested VPN approval first, so you know which consent you are granting. Then stop the specific overlay through its own setting rather than by revoking a broad permission you may need later. A screen filter usually has a toggle in its own app; a floating widget has a close control; a vendor display mode has a switch in Display settings.

Return to the VPN app after that and request approval again, so the dialog is created fresh. If the tap now works, adjust the overlay's compatibility behaviour or leave it off while you connect, and keep the touch protection enabled.

If you cannot tell which window is responsible, remove them one at a time and retry the consent dialog after each change. A recorder control bar or a floating shortcut is the usual offender, and the one you removed immediately before it worked is the answer.

Restore anything unrelated that you turned off along the way. A screen filter or a night mode is not the enemy; the specific window that overlaps the dialog is.

What not to do to get past the dialog

Do not grant accessibility access to an unfamiliar app so that it can press the button, and do not install a helper app for that purpose. Those grant exactly the capability the protection exists to deny, on a screen that authorizes a VPN.

Do not automate the dialog with an input tool either. It produces the same result as a malicious overlay and teaches you nothing about the cause.

On a managed device, a policy that restricts VPN changes is the administrator's decision. An overlay experiment is not authorization to work around it. Equally, an unresponsive consent button is no reason to weaken certificate verification or change account credentials: neither setting removes a local touch obstruction.

If it still fails, report the exact behaviour

Describe the dialog rather than the conclusion: which app requested approval, whether the dialog stayed open or closed, whether other sensitive prompts such as the unknown-sources or accessibility warnings also ignore taps, the device model and Android release, and the overlay and accessibility lists you captured.

Ask the support owner one more question while you are there: whether the device policy restricts VPN configuration changes at all. A managed block looks different from an ignored tap, and knowing which one you are looking at saves a second round trip.

That set distinguishes an obscured-touch problem from a broken input device, a frozen dialog, or a policy block. It also tells the next person whether to look at the screen or at the network.

The Android tapjacking guidance covers the obscured-window conditions and the APIs behind this behaviour. If you want the evidence trail, look for FLAG_WINDOW_IS_OBSCURED and FLAG_WINDOW_IS_PARTIALLY_OBSCURED on the event that never reached the button. The dialog that stays open is the thing to capture, because it shows the tap was withheld rather than delivered to a different window.