WiFi based tracking keeps disconnecting about trackworktime HOT 17 CLOSED

Could you please try to disable the battery optimization for TWT in the settings? Maybe Android causes the IN/OUT events by manipulating the app for power saving.

These screenshots may help you get to the right place (sadly the option is not very obvious):
screenshot 1
screenshot 2
screenshot 3
screenshot 4
screenshot 5
screenshot 6
screenshot 7

from trackworktime.

Thank you, I followed the instructions in the screenshots but unfortunately the problem persists. Here is a screenshot showing the events for today.

from trackworktime.

It seems that Android Oreo creates some extra work for developers of location-aware apps which are not in the foreground all the time - see https://developer.android.com/about/versions/oreo/background-location-limits.html

I honestly don't know when I will have the time to look into this new behaviour of Android.

from trackworktime.

@PRosenb, do you know how to get around this obstacle?

from trackworktime.

@mathisdt, I see this issue on my device too and will do some tests to find out if it can be resolved without too much effort.

from trackworktime.

@berceanu: I should have resolved this issue with the fix for #37. Could you please re-test using the newly released version 1.0.3?

from trackworktime.

This issue still persists in 1.0.3

from trackworktime.

Something that may help you to figure out what's going on. I'll try to fiddle around a bit, but can't make any promises.

Reproduce

• emulator API 26 (or later, dunno I've used this one)

1. Start the app and set it up
2. Press power button (Ctrl+P) to put it to ?sleep? mode
3. Should start disconnecting every few minutes

Logcat

• https://pastebin.com/v3gNyfPG

from trackworktime.

Using your description I finally could observe the problem myself (log). This is good - but I'm still not sure when I will have the time to fix it.

It looks like Doze or App Standy (which seems to have changed in 8.0) is the cause of this issue, especially because it only kicks in after some time of inactivity. Also see #11.

from trackworktime.

Just fyi, I'm cooking up a fix for this issue. Basically using this implementation seems to solve this problem. Checking WifiManager.startScan() return value and more importantly WifiManager.EXTRA_RESULTS_UPDATED and only then checking WifiManager.getScanResults() does the job.

from trackworktime.

@mathisdt Let me know what you think about my fix 21615f3 . I've been testing it on my phone for about a week without any issues.

If you want, I can also include basic functional tests for new functionality. I've played around a bit and almost have them made in Mockito + Junit4.

from trackworktime.

@WildOrangutan Great to hear of your progress! I have two questions about your change:

1. Major: Could it be done without requiring CHANGE_WIFI_STATE permission? Requesting this might be seen as intrusive, so if possible, I'd very much like to go without it.
2. Minor: Can we please (a) use blocks in if-else statements to ensure consistency and (b) remove prefixes like "m" from instance variable names? (I know, then we have to use a "this." qualifier to address the right variable, but for my understanding prefixes make the code more difficult to read.)

from trackworktime.

1. Hm, looking at documentation I've linked above, it could be done w/o including CHANGE_WIFI_STATE permission, but only on Oreo devices. Starting with Android Pie, it's required, along with some additional stuff. Dunno why I included this now; I'm intending of doing some minor fix on for Pie. I can exclude this for now.

2. Sure, no problem.

from trackworktime.

Even tough documentation says otherwise, CHANGE_WIFI_STATE is a must have. I'd say due to build tools version already on 28. App crashes otherwise.

from trackworktime.

One more idea on permission thingy (sorry for spamming). If you really want to avoid it, I guess you could omit wifiManager.startScan() and only listen when scan results update. Similarly like it's working on master atm. Tough relying only on other services to initiate scans is a bit optimistic imho.

from trackworktime.

@mathisdt I suggest closing this (and possibly similar) issues. Last fix seems to be working reliably for me.

from trackworktime.

Thanks @WildOrangutan. Seems to work. 😃

from trackworktime.