ppareit
Changes needed to target Android 14
All changes to get the app working with a target of Android 14.
I did not look into the following enough to know if they are indeed the best choice? Data seems like it should be. Exported didn't double check and just plugged that into there.
~Data or other? (edit: d'oh! Just seen the note that DATA_SYNC is to be deprecated in the future. It isn't yet lol.) FOREGROUND_SERVICE_TYPE_DATA_SYNC foregroundServiceType="dataSync"~ *dealt with in commit b2e6e0e477c267454b2881c951a1b15b63fa0ca8 due to DATA_SYNC nearing deprecated status.
Exported or not? RECEIVER_EXPORTED *see below https://github.com/ppareit/swiftp/pull/210#issuecomment-1878798610
Found more that show up later. Need to add more fixes.
Fixed with https://github.com/ppareit/swiftp/pull/210/commits/2dad55687effaf97da96f6143cc34ca2933c15a6
RECEIVER_NOT_EXPORTED does seem to be working just fine. Am currently not seeing any reason to need RECEIVER_EXPORTED.
Edit - leaving as RECEIVER_EXPORTED for now. Can adjust as needed.
I wonder if FireReceiver needs that? I don't use that so I'm not sure if it would be affected by this or not.
Non-app Issue seen. Notification can be dismissed ~causing a problem.~
Edits:
This is Android 14. Notifications that used to be unable to be dismissed are no more. Feature gone. But, this app works fine. Its not doing anything to it. So, can't find any actual notification related issue.
The notification can come back hours later but that is from Google Backup running as that causes it to show up again while its running.
After swiping, can see active background apps from previous notifications that could not be dismissed by tapping the nav bar recents button and looking at the top for active background apps. Not the best thing for all but works for some. May be different on some devices depending on manufacturers.
Issue seen. Major performance loss when app is in the background. Will look into it further.
The device has no battery/power saver enabled and the app is given full unrestricted use (adaptive battery is the only thing enabled but was enabled in A13 and does it when plugged in as well). Am thinking its probably related to A14's new changes so will need to look into if anything can affect it differently.
All other conditions same
2,706 files; 710 folder; size 54.9MB
screen on and app open...
total time: 7m 37s
anything else...
total time: 19m 51s
And indeed, tests I've run that should take approx 58 minutes can take up to 3 hours making it 3x slower.
This affects everything from transfer up and down to deletions.
To speed it up: The device display must be on and the app must be visible. Browsing away from the app or having the app open with the display off will drop the speed.
Edit: Not an app issue. It is Android 14.
1. Happens with target of A13 as well so not a target issue.
2. Happens with Samsung Files FTP client transfer from Windows Server: (vis) 8m 28s (not vis) 13m 30s
> In comparison exact same folder transfer using WinSCP and Swiftp:
connection count from to
1 (vis) 13m 22s (not vis) 14m 27s (vis) 7m 44s (not vis) 10m 57s
2 (vis) 9m 12s (not vis) 10m 42s (vis) 5m 44s (not vis) 7m 30s
3 (vis) 7m 42s (not vis) 9m 37s (vis) 5m 16s (not vis) 6m 40s
4 - (not vis) 8m 39s - (not vis) 6m 29s
Maybe workaround: The "keep device awake" setting in the app actually does keep the screen on so that might be as good as it gets. However, on longer transfers the time can range anyway and have tested as faster with this setting disabled and app in the bg so idk lol. Needs more looking into.
I don't know if anything else could be possible at this time. If WorkManager bg tasks have the issue, keep screen on verses the implemented cpu wake, etc.
So far I can't figure out what happened. But after the March Android security update (coincidence?) the wake locks just don't appear to work anymore even adjusted fully to Android 14, using old, etc. I checked and it even only shows 1% battery with lots of transfer time.
Update:
WindowManager.LayoutParams.FLAG_KEEP_SCREEN_ON use keeps things smooth and working great while PowerManager.FULL_WAKE_LOCK does not nor any other things. (This is also part of something I was tracking for another reason and not caused by the issue of this post but it does properly work to solve 1/2 of it.)
Still am not seeing the app get onto the Android battery chart though and the battery chart seems off so something at fault with Android / device updates there. Will keep an eye on it.
Update: What can be fixed has been added to pull request https://github.com/ppareit/swiftp/pull/229
July update on this.
No negative has been seen from target of Android 14 on any OS version.
Android 14 itself however (edit: I have a feeling this https://github.com/ppareit/swiftp/pull/241 is probably going to affect all of the following lol. It already now shows wakelock use in battery stats. Fun times.) - ~regardless of target - on longer transfers will occasionally sleep the background app. This can cause disconnects or failures from clients will too short of a timeout during times when Android 14 forces it into sleep.~
~Workarounds are to increase client timeout or it can also be done with setting full wake locks in the app along with keeping the screen on and in the foreground.~
~Is there a better way around this that can be done in code? I've not found anything. Android 14 is designed to be very aggressive at attempts to save battery by micro managing and forcing apps. A lot of users have bad battery usage because of bad apps and many users don't know how to deal with that so it comes down to this (every device has some user saying they have really bad battery lol).~
~I do think some Android 14 update made it worse. Battery stats still aren't working as they should. They will have also worked on various battery stuff in later updates since release as well.~ Yes, it was one line of code changed and I found it now. Should be ~better~ better to some degree anyway with that change fixed. This change doesn't keep the OS from sleeping the connection for a time though. But, it can be used to keep the screen on. The other flag should work according to prior tests but need to look into that again now.
(Confirmation once more that full cpu wake locks using FULL_WAKE_LOCK + app in background doesn't keep Android 14 from sleeping the connection. Next need to confirm again the other flag with actual working code lol.)
Ultimately, Android 14 works. I've used it fine enough for a few months now, don't see any need to not use it, and have run hours of auto tests on it with the longest transfer test being about 3 hours of files.