Always-on VPN reliably starts AdGuard after reboot, but protection is not automatically enabled

[Samuel12321]

Please answer the following questions for yourself before submitting an issue

• Filters were updated before reproducing an issue
• I checked the knowledge base and found no answer
• I checked to make sure that this issue has not already been filed

AdGuard version

AdGuard v4.12.3

Environment

• OS version:Android 16, one ui 8
• Device: Samsung Galaxy S25

HTTPS filtering

• yes, I do

Root access

• yes, I have it

Integration with AdGuard VPN

• yes, I do

Routing mode

Local VPN

Ad Blocking

No response

Privacy

No response

Social

No response

Annoyances

No response

Security

No response

Language-specific

No response

Other

No response

Which DNS server do you use?

DNS protection disabled

DNS protocol

None

Custom DNS

No response

What Stealth Mode options do you have enabled?

No response

Issue Details

1. Enable AdGuard protection.
2. Enable Android Always-on VPN for AdGuard.
3. Do not enable “Block connections without VPN”.
4. Reboot the phone.
5. After reboot, check AdGuard protection status.

Result: AdGuard appears to be started/invoked through Android’s Always-on VPN handling, but protection is not automatically enabled.

Expected Behavior

If AdGuard protection was enabled before reboot, and Android starts or invokes AdGuard through Always-on VPN after reboot, AdGuard should automatically restore protection, just as it normally does of started through the normal process.

Always-on VPN should help keep the local VPN path alive, and improve app start reliability, but it should not leave AdGuard running with protection disabled.

Actual Behavior

After reboot, AdGuard appears to start or be invoked by Android’s Always-on VPN handling, but protection remains disabled.

I have to manually open AdGuard or use notification and tap to enable protection again.

This seems different from the normal “AdGuard did not start at all” case. In this case, Android/Always-on VPN appears to start the app or VPN path, but AdGuard does not restore its saved protection state from that path.

Screenshots

Screenshot 1

Additional Information

This may be related to #5822, but I think it is a separate failure mode.

My current understanding from testing is:

• Protection seems to auto-enable only when AdGuard is started through AdGuard’s own boot/startup receiver.
• That boot/startup path is already unreliable on affected devices, as discussed in AdGuard protection fails to start automatically after reboot #5822.
• Always-on VPN appears to make AdGuard significantly more reliable at being started/invoked after reboot, and helps with OEM/battery-optimisation behaviour.
• However, Always-on VPN does not appear to trigger the same internal protection-restore logic.

So the issue may be that AdGuard has separate startup paths:

1. AdGuard boot receiver / launch-at-startup path → can auto-enable protection, but is unreliable.
2. Android Always-on VPN / VpnService path → more reliably starts/invokes AdGuard, but does not auto-enable protection.

If so, part of the fix may need to be in the VpnService startup path as well, not only the boot receiver path. When VpnService.onStartCommand() is called, AdGuard could check whether protection was enabled before reboot, whether protection is currently off, and whether VpnService.isAlwaysOn() is true, then restore protection automatically.

Expected behaviour would be for the Always-on VPN / VpnService startup path to also reconcile the saved desired state. If protection was enabled before reboot, but the actual state after reboot is protection off, AdGuard should detect and repair that automatically without requiring the user to open the app.

Always-on VPN was enabled without “Block connections without VPN”.

[Samuel12321]

Needed for #5996

[oksenina]

@Samuel12321 Hello!
Thanks a lot for reaching out and providing such a precise description of the bug! Your enthusiasm for helping us track down the cause is awesome and highly appreciated
Our engineering team has taken this into work. We are tracking the fix and aim to roll it out in one of the future releases