Please answer the following questions for yourself before submitting an issue
AdGuard version
4.14 nightly 42
Environment
- OS version: android 16
- Device: pixel 10 pro xl
HTTPS filtering
Root access
Integration with AdGuard VPN
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
Enable AdGuard Protection using the local VPN filtering mode.
Make sure both Ad blocking filters and DNS filters are enabled.
Open AdGuard.
Go to the filter update screen and manually select Update filters.
Wait for all Standard/Ad-blocking and DNS filter updates to finish.
Observe the protection/VPN lifecycle while the update completes.
The Standard filters updater completes and requests a protection restart.
Before protection has fully returned to the Started state, the DNS filters updater completes and requests another protection restart.
In the instrumented test, a single manual filter-update operation resulted in:
2 protection restart requests
2 internal VPN stop cycles
1 final VPN start
Reproducibility: Reproduced in multiple instrumented runs. The two restart call paths were traced independently to FiltersUpdater.kt:277 for Standard filters and FiltersUpdater.kt:266 for DNS filters.
Expected Behavior
When a single manual Update filters operation updates both Standard filters and DNS filters, protection should restart only as many times as necessary to apply the completed updates. If both filter types can be applied with a single protection restart, their restart requests should ideally be coalesced so the VPN is stopped and restarted only once.
Actual Behavior
During a single manual Update filters operation, the Standard filters updater and DNS filters updater independently request protection restarts.
In repeated instrumented tests, this resulted in:
2 protection restart requests
2 internal VPN stop cycles
1 final VPN start
The first restart request originates from the Standard filters path (FiltersUpdater.kt:277). Approximately 10–11 seconds later, while the first restart has not yet fully completed, the DNS filters path (FiltersUpdater.kt:266) requests another protection restart.
It is currently unclear whether this double restart/stop behavior is intentional, which is why I am reporting it for confirmation.
Screenshots
Screenshot 1
Additional Information
No response
Please answer the following questions for yourself before submitting an issue
AdGuard version
4.14 nightly 42
Environment
HTTPS filtering
Root access
Integration with AdGuard VPN
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
Enable AdGuard Protection using the local VPN filtering mode.
Make sure both Ad blocking filters and DNS filters are enabled.
Open AdGuard.
Go to the filter update screen and manually select Update filters.
Wait for all Standard/Ad-blocking and DNS filter updates to finish.
Observe the protection/VPN lifecycle while the update completes.
The Standard filters updater completes and requests a protection restart.
Before protection has fully returned to the Started state, the DNS filters updater completes and requests another protection restart.
In the instrumented test, a single manual filter-update operation resulted in:
2 protection restart requests
2 internal VPN stop cycles
1 final VPN start
Reproducibility: Reproduced in multiple instrumented runs. The two restart call paths were traced independently to FiltersUpdater.kt:277 for Standard filters and FiltersUpdater.kt:266 for DNS filters.
Expected Behavior
When a single manual Update filters operation updates both Standard filters and DNS filters, protection should restart only as many times as necessary to apply the completed updates. If both filter types can be applied with a single protection restart, their restart requests should ideally be coalesced so the VPN is stopped and restarted only once.
Actual Behavior
During a single manual Update filters operation, the Standard filters updater and DNS filters updater independently request protection restarts.
In repeated instrumented tests, this resulted in:
2 protection restart requests
2 internal VPN stop cycles
1 final VPN start
The first restart request originates from the Standard filters path (FiltersUpdater.kt:277). Approximately 10–11 seconds later, while the first restart has not yet fully completed, the DNS filters path (FiltersUpdater.kt:266) requests another protection restart.
It is currently unclear whether this double restart/stop behavior is intentional, which is why I am reporting it for confirmation.
Screenshots
Screenshot 1
Additional Information
No response