ppareit
Server not visible on network after phone screen switched off for a while
Hi there,
I'm really hoping this app will be able to do what I need. I'm currently automating transcoding of recorded TV on my TVHeadend server and then transferring to my phone.
To do this, I need the server to be on constantly when I'm on my home wifi to allow my script to discover my phone and transfer the file.
I scan the network for the ftp port and retrieve the IP address of the device that has this port open. This script works fine when the screen is active but once the screen is off for a certain amount of time it appears that the port is no longer open.
I'm currently using the Demo version (but will happily pay if this works) and have ticked the "Keep device awake (full CPU speed)" option.
I've also disabled power saving options for this app on my phone (Galaxy S8 Android 7.0).
Any ideas?
After ticking "Keep device awake (full CPU speed)" option, the screen of your device shouldn't turn off automatically. You'd have to manually turn it off.
And once you turn it off manually, it puts the device into the sleep mode after a 'certain amount of time'. Once the device is in sleep mode, all the open ports will be closed by the OS until the device is forced to wake up.
Ok. That makes sense.
So there's no way to have the ports open in "sleep mode"?
You'll have to modify the code that acquire wake lock, according to your needs. In this case, i think Partial Wake Lock will do the job.
Official Developer Docs on wake lock are available here.
Yes, that does sound like that could work. Unfortunately I wouldn't have the first clue where to add this code!
I'm pretty decent with coding in python. Never done Android/java before.
You don't need to modify anything. I just checked out the FsService#takeWakeLock() function (called just before the FTP server thread is started) and it looks like that the app will acquire partial wake lock after unchecking "Keep device awake (full CPU speed)" option.
I was just reading through the source and was going to ask you that very question as my reading was that there should be a partial wakelock by default unless overridden.
I'll try this later tonight.
Thanks.
Looks like there's a bug in Android (or Samsung's modifications). The WiFi is disconnecting when the phone sleeps despite checking the option to keep it on.
Thanks for your help on this.
I'm not sure if this is related (please let me know if I should open a different ticket), but I'm experiencing a similar problem.
Sometimes while I'm transferring lots of files between my cell phone and my linux box (using midnight commander's integrated FTP client), the transfer operation gets stuck (i.e. the progress bar on my computer stops) while the cell phone screen turns off automatically to save power.
As soon as I push the "home" button on the phone to turn the screen back on, the transfer resumes automagically until it finishes OK. Please note that I don't get any error message, or broken/partial files; it's just as if the "screen off" triggers some kind of "pause" command, and the "screen on" triggers a "resume",
I have the "Keep device awake" option turned on.
Android version? Could also be doze mode.
Op 11 jun. 2017 1:05 p.m. schreef "Vrihub" [email protected]:
I'm not sure if this is related (please let me know if I should open a different ticket), but I'm experiencing a similar problem.
Sometimes while I'm transferring lots of files between my cell phone and my linux box (using midnight commander's integrated FTP client), the transfer operation gets stuck (i.e. the progress bar on my computer stops) while the cell phone screen turns off automatically to save power.
As soon as I push the "home" button on the phone to turn the screen back on, the transfer resumes automagically until it finishes OK. Please note that I don't get any error message, or broken/partial files; it's just as if the "screen off" triggers some kind of "pause" command, and the "screen on" triggers a "resume",
I have the "Keep device awake" option turned on.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ppareit/swiftp/issues/95#issuecomment-307622313, or mute the thread https://github.com/notifications/unsubscribe-auth/AAqZNZ3-OyNaK-lg_SvuB3dmXny437U4ks5sC8nygaJpZM4NxAal .
Some device manufacturers add their proprietary battery saver software to the device so it might be possible that this software is blocking other apps from acquiring full wake lock. If you find settings for battery saver, try to add an exception for swiftp.
Android version? Could also be doze mode.
Android 4.2.2
Some device manufacturers add their proprietary...
Samsung phone. So, yes it might be some proprietary stuff causing the problem
I'm not 100% convinced this is a Samsung/Android problem.
I've tried FTPServer and this seems to allow me to connect when my phone screen has been off for an hour or so while SwiFTP doesn't.
There's a menu option saying "Choose the WAKE_LOCK mode" which is set to "always keep awake" but I don't know what lock is being set.
I'll reopen the issue and see if I can do some further digging to pinpoint the problem.
The FTPServer has a text interface showing activity. When stopping the app it references releasing both WakeLock and WifiLock. I was therefore hoping that the WifiLock may have been the answer.
Unfortunately/unsurprisingly, I see that the WifiLock is already implemented in your code!
I do have a couple of questions:
- Is there a particular reason why both the WakeLock and WifiLocks have setReferenceCounted(false) when the default behaviour is true? I assume it's because there's only one activity that acquires the lock so it's not anticipated that there could ever be more than one.
- What is the default WifiLock level? I note that the lock can be created with various levels so I wonder if escalating the level may be an option.
If I can work out how to build android apps I may give this a go but I'd guess the odds of this fixing the issue would be pretty low!
There are no levels in Wifilock as mentioned in official docs.
I don't know if there is any particular reason behind setting Wifilock and Wakelock non-reference counted but it doesn't really make any difference. By default, the device shouldn't fall asleep until the Wakelock is released and same applies to Wifilock.
Thanks. Didn't think it would make a difference but no harm in asking.
I'll fork the code and have a play. Good learning experience for me if nothing else!
Ok. So, I tried pinging my phone from my laptop with SwiFTP running. With screen on, ping times were about 50-200ms. As soon as screen goes off, ping times start to vary wildly between 50-1200ms. After 4-5 mins, ping responses stop and I can no longer connect to SwiFTP.
I thought I'd recreate the exercise with FTPServer given that this does seem to let me connect when the screen's off. My expectation was that the ping reponses wouldn't stop. I was wrong. Ping responses stopped 4-5 minutes after screen went but I could still connect via FTP.
I tried changing the SwiFTP code where the wifilock is created:
wifiLock = manager.createWifiLock(WifiManager.WIFI_MODE_FULL_HIGH_PERF, TAG);
but that didn't have any effect either.
I will add support to ignore the battery optimization in doze mode for SwiFTP. This will involve a runtime permission request, but should handle your use case @elParaguayo
I'll leave the issue open till it is implemented.
Thanks. I've got Android Studio set up at home now so I can build and test.
However, I've already disabled the battery optimisation setting in the phone so SwiFTP is listed as an "unmonitored app" so I don't know if your suggestion will make a difference but I'd be very happy to try it!
Having looked at this page I'd say it does sound promising. The maintenance windows would explain why I did get occasional ping bursts after they had stopped. I'm not sure why that happens though if the app is already whitelisted...
So I tried some USB debugging tonight. Here are the lines from about 5 mins after the screen goes off:
06-15 23:16:16.662 8359-8359/be.ppareit.swiftp D/WifiStateChangeReceiver: We are disconnected from wifi network
06-15 23:16:16.675 8359-18404/be.ppareit.swiftp D/FsService: Server is alive
06-15 23:16:31.678 8359-18404/be.ppareit.swiftp D/FsService: Server is alive
06-15 23:16:31.681 8359-18404/be.ppareit.swiftp D/WifiStateChangeReceiver$StopServerService: Wifi connection disconnected and no longer connecting, stopping the ftp server
06-15 23:16:31.695 8359-8359/be.ppareit.swiftp V/RequestStartStopReceiver: Received: be.ppareit.swiftp.ACTION_STOP_FTPSERVER
06-15 23:16:31.702 8359-8359/be.ppareit.swiftp I/FsService: onDestroy() Stopping server
06-15 23:16:31.703 8359-15161/be.ppareit.swiftp D/FsService: Thread interrupted
06-15 23:16:31.703 8359-15161/be.ppareit.swiftp I/FsService: Terminating 1 session thread(s)
06-15 23:16:31.703 8359-15161/be.ppareit.swiftp D/SessionThread: Closing data socket
06-15 23:16:31.704 8359-15161/be.ppareit.swiftp D/FsService: Exiting cleanly, returning from run()
06-15 23:16:31.704 8359-15164/be.ppareit.swiftp D/TcpListener: Exception in TcpListener
06-15 23:16:31.708 8359-8359/be.ppareit.swiftp D/FsService: serverThread join()ed ok
06-15 23:16:31.708 8359-8359/be.ppareit.swiftp I/FsService: Closing listenSocket
06-15 23:16:31.709 8359-8359/be.ppareit.swiftp D/FsService: onDestroy: Releasing wifi lock
06-15 23:16:31.710 8359-8359/be.ppareit.swiftp D/FsService: onDestroy: Releasing wake lock
06-15 23:16:31.712 8359-8359/be.ppareit.swiftp D/FsService: FTPServerService.onDestroy() finished
06-15 23:16:31.714 8359-8359/be.ppareit.swiftp D/FsNotification: onReceive broadcast: be.ppareit.swiftp.FTPSERVER_STOPPED
06-15 23:16:31.715 8359-8359/be.ppareit.swiftp D/FsNotification: Clearing the notifications
06-15 23:16:31.726 8359-8359/be.ppareit.swiftp D/FsNotification: Cleared notification
06-15 23:16:31.733 8359-8359/be.ppareit.swiftp D/NsdService: onReceive broadcast: be.ppareit.swiftp.FTPSERVER_STOPPED
06-15 23:16:31.739 8359-8359/be.ppareit.swiftp D/NsdService: onDestroy: Entered
06-15 23:16:31.745 8359-15168/be.ppareit.swiftp D/NsdService: onServiceUnregistered: SM-G950F FTP Server
06-15 23:16:31.748 8359-8359/be.ppareit.swiftp V/FsWidgetProvider: Received broadcast: be.ppareit.swiftp.FTPSERVER_STOPPED
06-15 23:16:31.752 8359-8359/be.ppareit.swiftp D/FsWidgetProvider: UpdateService start command
06-15 23:16:31.752 8359-8359/be.ppareit.swiftp D/FsService: Server is not running (null serverThread)
It looks like the phone shuts off wifi (even though the app should have it locked) so it stops the server. Weird.
According to google doc: https://developer.android.com/training/monitoring-device-state/doze-standby.html
Doze restrictions. The following restrictions apply to your apps while in Doze: Network access is suspended. The system ignores wake locks.
Yes, but if I had already manually added the app to the whitelist then those restrictions shouldn't apply. Or, at least, that's what I'd expect to happen.
Yes the app need to be whitelisted and can use network if it holds a partial wakelock
But that's what should be happening now. I've whitelisted the app and the partial wake lock should be acquired.
However, from the log it seems that WiFi goes off so the app releases the locks which stops the app from working.
This should work based on google doc but I know that many apps are having the same problem with doze.
The strange thing is that the FTPServer app seems to work: even though I can't ping the phone, I still seem to be able to connect to FTP.
Unfortunately that app seems to crash and just doesn't feel as smart as SwiFTP so I was hoping there may be a quick fix here.
Sounds like there may be a more fundamental problem at the operating system level.
Unfortunately, I think this is a flaw in SwiFTP.
I have set up both SwiFTP and FTPServer running simultaneously on different ports.
My phone has been off for about an hour. I can connect to FTPServer but SwiFTP won't connect (times out). This would suggest that FTPServer is holding on to the correct locks but SwiFTP seems to be releasing them.
I'll do some more testing and update this comment if I find out anything more.
We should probably implement REQUEST_IGNORE_BATTERY_OPTIMIZATIONS, though this comes with and extra permission. To check if an app has this permission, you can see the settings at Settings > Battery > Battery Optimization. I would prefer not to blindly add this permission to SwiFTP, this should come with a clear warning and explication for the user, see the following note from google:
Note: Google Play policies prohibit apps from requesting direct exemption from Power Management features in Android 6.0+ (Doze and App Standby) unless the core function of the app is adversely affected.
Of course, if something else can be done to keep the connection open, I'm all for it!
@elParaguayo Could you experiment with disabling WifiStateChangeReceiver?
in the AndroidManifest.xml, remove lines 85 til 92, the receiver for be.ppareit.swiftp.WifiStateChangeReceiver
or add a return in onReceive of WifiStateChangeReceiver