Protection is not restarted after pause about adguardforandroid HOT 47 CLOSED

Re: AdguardTeam/AdguardForWindows#45 (comment)

Maybe this is the cause? I meant to investigate this more fully, but, if this solves it, I'm all for it. ☺

from adguardforandroid.

Nope, Windows and Android versions are totally different.
Windows service and Android service are only sounds similar.

from adguardforandroid.

I meant, this issue is very specific to this fix, but, like the Windows issue, a general issue investigating this may be appropriate. Or it may be moot if this fix solves it completely.… ☺

from adguardforandroid.

Also, I'm having this issue in proxy mode, as I can't functionally use VPN mode. (Separate bug has been e-mailed a few days ago.)

from adguardforandroid.

Hm, that's something new, protection is not restarted in proxy mode. It is specific to VPN mode - we need to restart it on every network reconnect.

Could you please tell me ID of the ticket with the description of that proxy mode bug?

from adguardforandroid.

I've no ticket for that bug, as I've only starting noticing it. The other, non-related VPN bug, I've @ least 2 ticket #s for, but I don't think you want them here.…

from adguardforandroid.

Anyway, if these bugs are still present, it's better to have them here on github.
Maybe support has missed it and didn't pass to us devs?

from adguardforandroid.

Ok, #23 filed. I think that 1 is a hard problem. ;)

from adguardforandroid.

I have just filed RMZ-109-29725 with details of what happens when AdGuard doesn't stay restarted in proxy mode. What's peculiar to me is that (as I mentioned in the report), when AdGuard quits after restarting, the app acts as if I quit the app myself, because it doesn't automatically reactivate as I'm used to, otherwise.

from adguardforandroid.

Thank you, got the log file.

So, what do I see there:
13:16:??: Adguard process was killed by Android
13:16:09.785: Adguard process was restarted (we've detected Android's sticky restart)
13:16:09.967: Starting protection, preparing filters
13:16:12.879: It looks like you've tried to start protection from UI. App has ignored this command (because it is already in process)
13:16:15.843: Protection has started

from adguardforandroid.

Something's missed in between. The sequence as I saw it happen:

1. Android kills it. (13:16:??)
2. It restarts. (13:16:09.785 & 13:16:09.967)
   3. It dies completely. (This is why long delay before next step: I'm waiting to see if it'll restart on its own.)
3. I open the app, but it doesn't startup on open. (13:16:12.879)
4. I activate via the Big Button, & now everything's fine. (13:16:15.843)

Almost every other time (maybe 5× more often than above), I see just steps 1 & 2 cycle through every 3 or 4 hours, but, about once a day, I have the above sequence (which, mind you, is still better than AB+, which forces a device reboot every 3 to 4 hours!)

from adguardforandroid.

3 seconds is not a long delay.
Maybe you mean that it dies completely before step 2?

Anyway, that seems to be android problem. Do you have some kind of power management app or settings? Sometimes it's possible to whitelist the app there so Android wouldn't kill it so frequently.

from adguardforandroid.

No, the order as I mentioned is correct, but maybe the timestamps you mentioned don't reflect precisely. (I've misread the 1s you quoted — I certainly waited perhaps a minute or more before trying an app restart, & confirmed app wasn't running before via app info).

I don't have any automatic power management via app, only Android system's own (which I think I've set as max power/least power-saving as possible ). I've also whitelisted app everywhere I can find.

from adguardforandroid.

Then I am pretty sure the order from the log is correct, but with one addition - the app was not restarted by Android.

1. Android kills the app and (as it's sticky) schedules restart.
2. You wait for a minute, the app is not restarted.
3. You open the app.
4. Android finds that the app was scheduled for restart and instead of simply starting it - sends restart "Intent" to our service.

That's why in the log file it looks like the app was restarted by Android (as it should).

The problem here is that this behavior is normal, Android sometimes kills apps and restarts them in a some period of time, we can't control or influence this behavior.

The only thing you can do is change Android settings to make it less aggressive to background processes.

from adguardforandroid.

Hmm. Where does 1 change these settings?

from adguardforandroid.

For instance try disabling Battery saver (if you have 5.X)

from adguardforandroid.

Same 4.4 x86 tablet, so no 5.x Battery Saver.… The only option is for WiFi power, which is set only for Max Power/No Saving.

from adguardforandroid.

Have you disabled AG notification icon? Having this icon enabled improves app priority.

from adguardforandroid.

Nope, learned that the hard via previous apps, so I intentionally left the notification icon enabled.

from adguardforandroid.

Found one unquestionable bug, fixed it. Added some new workarounds for network changes and slow protection starts & stops. Needs thorough testing.
These new changes can fix all such issues, including #36.

from adguardforandroid.

@Revertron Ready & willing tester here.… How do I get hold of this version?

from adguardforandroid.

@TPS You can get it here: https://cloud.jamm.me/index.php/s/50hYBtuQRHU72uD

from adguardforandroid.

Installed & using; of course, will need time to see how it behaves. (Did file 1 minor note in separate issue.) Thanks, @Revertron!

from adguardforandroid.

@Revertron This build is far less stable than the 1 from from #23 that I've been using 'til this point, which is about the same as the current 2.x release for me. It crashes every 15 to 30 minutes when actively web browsing (not with any other activity, curiously — just app updating, e-mail syncing, &c, stay working just fine) but generally restarts more quickly. Still, every 10 or 15 crashes, it doesn't restart timely at all, so I'm forced to manually start via the widget or app itself.

I'll send a bug report next time this happens, & note it here.

from adguardforandroid.

How does crash looks like? Is "Critical Error" notification there?

from adguardforandroid.

Ticket# QWK-273-24456

No crash in that sense, just complete loss of functionality & status icon. I realize pages with lots of external (not from base page server) assets, e.g., Slashdot, GMail, &c, cause this problem nearly every fresh page load, especially, but not limited to, via CM Private Browsing. Curiously, when/if AG reloads on a, e.g., Slashdot page in CM Private Browsing, reloading the same page doesn't trigger the issue, but loading the next Slashdot link will!

Maybe a new test build with the #36 fix will help?

from adguardforandroid.

Hope so, at least I don't see anything specific in that log.

@Revertron amazon code error in that build:

00:06:32.349 [pool-1-thread-1] INFO  c.a.android.service.JobServiceImpl - Start executing job Status Job
00:06:32.494 [pool-1-thread-1] WARN  c.a.a.s.license.LicenseServiceImpl - Could not check subscription status
java.lang.NullPointerException: null
at com.adguard.android.service.license.LicenseServiceImpl.checkStoreSubscription(Unknown Source) ~[na:0.0]
at com.adguard.android.service.license.LicenseServiceImpl.checkLicenseStatus(Unknown Source) ~[na:0.0]
at com.adguard.android.service.license.LicenseServiceImpl$1.run(Unknown Source) ~[na:0.0]
at com.adguard.android.service.b.run(Unknown Source) ~[na:0.0]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:422) ~[na:0.0]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:279) ~[na:0.0]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:152) ~[na:0.0]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266) ~[na:0.0]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112) ~[na:0.0]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587) ~[na:0.0]
at java.lang.Thread.run(Thread.java:841) ~[na:0.0]

from adguardforandroid.

I've fixed it, thanks for report.

from adguardforandroid.

@TPS A new build is available here: https://cloud.jamm.me/index.php/s/QvtjnEONfTHhHUD
Many fixes for this issue, crash from above and #33

from adguardforandroid.

@Revertron @ameshkov Thanks! Will report after a few days' use.… ☺

The build just notified to update to beta 2.0.106.… I'm assuming it's ok to test with?

I think report# IPI-833-82573 will work for both #2 & #23, but feed me further instructions as how you want me to test. I saw no difference in # or frequency of restarts, nor did VPN function under any debug option even for the simplest of tests — simply requesting AG filter updates.

from adguardforandroid.

There are no issues with restarting protection from testers. This issue can be closed for now I think.

from adguardforandroid.

This bug is back in 159.

from adguardforandroid.

Fixed it yet again.

from adguardforandroid.

@ameshkov @Revertron I think this VPN-mode bug is back in Amazon .231, but only when device is in standby/screen-off. (I can't find the separate bug I thought was filed specifically about this?) I think this is also @ the root of AdguardTeam/AdguardFilters#869 & AdguardTeam/AdguardFilters#870, because they manifest in this state.

Ticket# OXG-496-68436

from adguardforandroid.

@TPS
How long has it been since you've installed CM?
Have you added Adguard to CM's exceptions? Such cleaners are often kill AG process (as it seems to be rather heavy in battery usage stats)

from adguardforandroid.

I've had CM since long before AG, & have added AdGuard to CM's exceptions everyplace, even the AV (both internal & the separate CM AV app), as well as Greenify's. I reasonably sure neither of those is culprit here.

from adguardforandroid.

I've had an idea.… I'm going to try pref.vpn.disable.pause ✅ tonight & see if that makes a difference.… I've observed something that looks like a timing issue, & I hope this resolves it. Does this same pref work with the equivalent function for proxy?

Nope, no go.… Is there any way AdGuard can appear in [Android System Menu] » [Wireless & Networks] » [More] » [VPN] » [Vertical … Menu] » {Always On} (obscure, right? 😉) to force all connections to work only when VPN is active? Like, when proxy is down, most connections fail.…

from adguardforandroid.

I don't think it could help. Do you know how extract LogCat logs? If you can do it for us I'll see there why Adguard process is killed.

from adguardforandroid.

Here is an instruction: http://forum.xda-developers.com/showthread.php?t=1726238
Just get the log right after you face this problem again.

Also please leave default logging level in Adguard.

from adguardforandroid.

I'll use 1 of the logcat apps & report back. Thanks for the link!

Update: On Android 4.1+, these methods all require rooting or an external PC to get the whole system logcat. I'm not setup for either 1, so logcat will have to wait 'til I get my new laptop. (Hopefully, 1st week of December.) 🙏

from adguardforandroid.

I think 1 thing I'm seeing that, if AdGuard VPN doesn't come up (delays for some reason) by the time the connection is otherwise ready, foreground app & syncing will use connection anyway, including any of the above that download ads opportunisticly when a live internet connection is detected, like CM family of apps. 😞

Is there a way to minimize this delay? (Not quite same as disable.pause …) I agree there's the related problem of Android killing it, but that I can't help with (I think) until new laptop.…

from adguardforandroid.

@TPS it depends on the time when Android notifies Adguard that network is available. Unfortunately there can be a significant delay (up to 5-10 seconds). Second issue: all these apps are also listening to that event and could be notified before AG.

from adguardforandroid.

@ameshkov Is there an earlier event that AG could be listening for to give it a bit of an edge? Or a way to lock/block/disable the connection until it's ready to filter?

from adguardforandroid.

@ameshkov Is there an earlier event that AG could be listening for to give it a bit of an edge? Or a way to lock/block/disable the connection until it's ready to filter?

Using other events won't solve the problem we are solving with VPN restart. We should start VPN when connection is fully established so that the network routes are stable.

from adguardforandroid.

id 1373719, the same issue with both Adguard 2.6 and 2.7 on Huawei device
process is not killed, but Adguard doesn't restart protection after connecting to network
please advise

from adguardforandroid.

@vozersky it'd be better if you file a separate bug report on that issue.

from adguardforandroid.

@ameshkov
done: #758

from adguardforandroid.