Battery saver

[Xavron]

Closes

• Battery usage can indeed be lowered a lot #223

Battery saver

Some quick notes:

• Idle battery drops off of Android battery chart to <0.1% and won't show up in a day of pure idle (pre pull request my device was ~0.3-0.6% per every 2 hours)
• Default set to HIGH (high battery use) to maintain backwards compat during app updates
• Android battery chart can be wrong as it is currently on my Android 14 device. So be aware. Battery usage difference above was seen before the chart broke.
• Just seen past 24 hours, Android 14's app clear data can result in older app code showing up so that can potentially mess up your ideas of how the app battery use is working. Older code (not related but I'm adding this note here) showed up that was removed for 11 hours and was definitely not in the app before clearing. I checked and there was no way for me to cause it not even accidentally. Be aware.
• Added advanced preference to choose from full wake locks, connection only wake locks, and no wake locks
• Deep (no wake locks) also disables cpu wake lock preference setting
• Tested on Android 6, Android 7.1.1, Android 14
• Previous cpu full wake lock (now set using battery saver HIGH + full cpu wakelock setting enabled) use didn't actually work on Android 14 (new way does and recommended by Android) - tested many combinations and narrowed to this.
• New full wake locks will be very smooth all the time (tested 10 days straight with fully smooth connections)
• Removed a loop running for no reason (much testing has been done without it and showing zero problems)
• Changed name of wifiListener to socketWatcher as it literally had zero to do with wifi and is involved in the code changes here
• Various exit, crash testing done
• Long time running purely in background done
• Connection wake locks may delay before wake lock is turned on but will be smooth during connection provided too that full cpu wake lock is also enabled.
• Disabled wake locks will have delays and clients would need to have increased timeouts set or will timeout roughly 1-2x per several days. Idle battery usage will be super low and many may find it good enough for their needs.
• Naturally cannot workaround devices that break apps running in the background (devices with bad OS behavior)
• Many devices have their own setting to allow apps to keep running in the background and that needs to be set outside of the app and by the user
• Connection wake locks are delayed 10 minutes to off after client quit to allow time for clients to quit and connect again as at times they do this and it will keep the connection fully smooth. Delay reset if a client reconnects.
• Connection wake locks also have the super low idle battery use but may use more battery during connections.
• Super low idle battery use is fantastic. I can't emphasize enough how much better it is :)

Other notes:

Issues seen with causes noted (more causes can exist):

Connection timed out

• In advanced settings, set battery saver to HIGH and also enable full cpu wakelock setting OR don't do either of those but increase client timeout if the client offers a setting to do so (not all do).
• Write external storage permission in the app needs to be re-obtained for the user the client is trying to connect to
• Client machine suspended/hibernated during connection

No route to host

• Client tries before the client OS brings up the network connection

Examples to adjust Android OS battery settings for apps:

• Android 6: Battery > Battery Optimization > set app to not optimized
• Newer Samsung devices eg Android 12-14: Android's settings for the app > battery > set to unrestricted

Original info I wrote to figure out what was going on with the loop I removed in FsService run() that I didn't want to leave commented in the code for this pull request.

So what does actually happen after this point here...

1. new TcpListener() aka server + thread
2. Gets puts back in here at registerSessionThread() into sessionThreads holder
3. Because of Service sticking around in the bg, it is therefore kept around and not lost or GC'd
4. Therefore socket, etc stays open due to Service, server on, etc.
5. new TcpListener() is then removed each time registerSessionThread() is called in TcpListener
   which it removes but also adds so its always there and not lost. registerSessionThread() is
   mostly remove/cleanup so its a bit oddly named. Don't get thrown off looking at it.
6. new TcpListener() sticks around (and also doesn't loop thousand times per sec) as
   listenSocket.accept() blocks until new connection is made. Has no timeout, etc. Thus,
   everything stays working, socket stays open, clients can connect, etc.
7. The loop in TcpListener with the .accept() basically keeps everything going. Everything, pauses
   while its blocking. Once it receives the next connection is made, everything loops again. Repeat.
8. Repeats until server is turned off (on/off toggle switch) and then onDestroy is called and
   cleans everything up. When server is toggled on again, we arrive back here.

However, removal tested without a single issue. Tested for months, tested against original during any seen problems to the same result. Zero difference found except for lower battery use :)

Again, no loop + full wakelocks + battery saver at HIGH with app running in bg (no foreground use at all) had super smooth connections with 0 connection failures or delays for 10 days straight. Logs for all connections watched with times visible. Connections in UIs always heavily watched. Android 14.

[Xavron]

One known issue. The connection wake lock release code needs a boolean check in an Exception code block. I can't remember but think it resulted in an app crash.

Added 1e1a31a commit to deal with this. Its been too long and I don't know what happened now lol. But, that line was added in this pull request for the connection wakelocks so it should work as expected if it was a problem. Might only have been a problem seen during code changes as that's when I noticed it and not during normal use. Half the reason why I'm lost on it now :)

[Xavron]

Sorry, just noticed an issue :'(

android.view.WindowManager.LayoutParams.FLAG_KEEP_SCREEN_ON

For some reason isn't actually keeping the screen on lol. Not with Android 14 and not with Android 8 either. The wake lock definitely appears to be running and isn't being ended in the code.

So, I need to look into this. I don't know what happened there.

Edit: I see. Made an oops. I know what happened now. When I looked at the hover popup documentation, it says use the flag under deprecated, so I used it there at that time and left it like that lol. Probably when I was confirming it and making final changes and reverting and changing things and testing things. They wrote that there not clear enough. I wonder how many people that got? :)P Can't be just me.

Only problem now is that it requires the Activity... I may just revert it to the old FULL_WAKE_LOCK. Now I wonder if it had stabilized before because of no wake lock at all since that flag wasn't working or I had a static Activity for testing there. Quite sure it was static for testing. Kind of remember that now....

Added pull request #241 to fix this. Tried getting it added here with a request for you to add it but that looks to be "not going to happen". I will add it to a new pull request as a duplicate one is not looking like a good idea.

[Xavron]

Adding here various new tests for Android 14 to find ways of dealing with its forced over aggressive power saving...

This will be updated over time for as long as I have Android 14 to test with and have reason to,

Indirect connection influences

o AOD: Sleeping connection moves again each time the AOD time changes but it may also sleep a lot.

• Confirmed: Doesn't move on time change when disabled. Does move when AOD is enabled.
• Shows that A14 power saving is very complicated as settings, apps, and choices indirectly affect this app.

Time differences (all A14 and scoped storage)

Set 1 (has 1k files, and 400 dirs more than the other sets)

• 2 hours 23 min DEEP + background + experimental list improvement
• 2 hours 12 min LOW + CPU FULL + background + experimental list improvement
• 2 hours 9 min HIGH + CPU FULL + background + experimental list improvement
• 2 hours 2 min LOW + background + experimental list improvement
• 1 hour 35 min HIGH + background + experimental list improvement

Set 2 + reboot WIFI AP

• 2 hours 40 min DEEP + background + experimental list improvement
• 2 hours 6 min LOW + CPU FULL + background + experimental list improvement
• 2 hours 5 min HIGH + CPU FULL + background + experimental list improvement
• 2 hours 2 min HIGH + background + experimental list improvement
• 1 hour 56 min LOW + background + experimental list improvement

Set 3

• QUIT at 3 hours HIGH + CPU FULL + background. Was less than 50% finished. Total time would be somewhere above 7 hours. The experimental list improvement fixes this issue.
• No other tests run for this set because it showed the issue immediately.

Set 4

• 2 hours 10 min LOW + background + experimental list improvement
• 2 hours 9 min DEEP + background + experimental list improvement
• 2 hours 4 min HIGH + background + experimental list improvement
• 1 hours 39 min LOW + wifi debugging in use + background + experimental list improvement
• 1 hours 34 min LOW + AOD enabled + background + experimental list improvement

  2 hours 6 min
  2 hours 7 min AOD BRIGHT

• 1 hour 30 min HIGH w/CPU full wake locks + app visible and screen on + experimental list improvement

o Battery % has nothing to do with times. Testing has gone down into the 20% range.

o Had to move to fully using experimental list improvement to deal with the bad sleeping issue.

o Experimental list improvement is more important than I thought. Will look further into that and testing sooner than later.

o Might be possible that there's another battery saver switching bug as the one LOW + AOD had low times but am not sure at this time.

o Debugging affecting times is a bit of an annoyance for certain things.

o Target time to get as close as possible: 45 min Android 8 java.io.File (match of sets 2-4) HIGH + CPU FULL + background. Saving about 50% ms on each file/dir would get it there.

[Xavron]

Adding here Android 14 sleep problem (where it awakes eg automatically, above on AOD time change, when screen is manually put on, etc)...

This appears to be only or normally happening only during listing (MLST, LIST, etc) and appears to be happening on DocumentFile and DocumentsContract code such as documentFile.getName() or buildChildDocumentsUriUsingTree().

Also do not understand why its continually on listing and not on similar use during transfers. Thread priority doesn't appear to make a difference. Both use data connection and other same things. Understanding this could maybe provide a solution. However, experimental list improvement does work in current testing.

Scoped storage experimental list code is showing to be a fix for this. As its importance has increased, will work on further testing of it.