Created attachment 117960 [details] The transmission packet from Android to PC captured by wireshark. SUMMARY After screen blanking, the Android closed connection to PC. STEPS TO REPRODUCE 1. Find an Android phone (N/O may be both okay.) and install kdeconnect. **Then give all the permissions the application wanted, if you are using MIUI or that kind of third party UI of Android, please ensure that all the permission managers in the system have granted all the permissions to the application.** 2. Using kdeconnect from plasma or gsconnect from gnome on PC are okay. 3. pair and send a ping, after that, lock the phone screen. OBSERVED RESULT: https://github.com/andyholmes/gnome-shell-extension-gsconnect/issues/272#issuecomment-462095788 https://github.com/andyholmes/gnome-shell-extension-gsconnect/issues/272#issuecomment-462096535 EXPECTED RESULT Worked as intended. Connection still be kept after screen blanking. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux, kdeconnect 1.3.3-1 (available in About System) KDE Plasma Version: Plasma 5.14.5-2 and Gnome 3.30.2-1 KDE Frameworks Version: \ Qt Version: 5.12.1-2 ADDITIONAL INFORMATION See: https://github.com/andyholmes/gnome-shell-extension-gsconnect/issues/272
Maybe I think you need to send keepalive both from PC and Android.
This is an ongoing issue with Android's "doze mode". We don't have a definitive solution to it yet. I've checked the github thread you link and I see you nailed it down to the keeplaives not being ackd, thanks for that! Let me brainstorm some ideas, and let's see we can do: - Ask the user to disable "battery optimizations" for KDE Connect on first run of the app (I'm not sure this actually helps, though... can you try it?) - Allow disconnection to happen, but set up a periodic task so the app reconnects every X minutes. - Remove/reduce keepalives, and hope the connection will still be open when the phone is back from doze. Unfortunately, in Java it's not possible to tweak keepalive's parameters like we don on the desktop. Can you try disabling battery optimizations for kdeconnect and see if it makes any difference? That would be the easiest of the three things.
Part 1: Preface As we all know that Android is really heavy-fragmented. Almost each manufacturer has their own modified ROM (or UI) instead of using standard AOSP one. China is really the most hard-hit areas about the fragmentation of Android ROM. Unfortunately, I live there. So, 1. I recommend you to learn some background keep-alive mechanism from one APP: WeChat(as the name suggests, I called it W[ater]C[loset] cuz I hate it for costing too much battery), especially due to the super-poor connectivity to Google server in China, each app almost have their method to keep alive. The Chinese-Specific version can be found at http://dldir1.qq.com/weixin/android/weixin703android1400.apk (Use with caution, it may eat your whole battery so quickly and may stole your privacy to China government). The international version can be found at Google Play Store.
Part 2: Answer of your reply - Ask the user to disable "battery optimizations" for KDE Connect on first run of the app (I'm not sure this actually helps, though... can you try it?) > I have to say that, the situation that I met was under a non-AOSP standard ROM. On my Google Pixel, it never need to disable the battery optimization for KDE connect. But you could still do some check to notice user to disable it or check the FAQ if they met the problem. On the latest release of Google Pixel ROM, nothing need to be done, which means on standard AOSP ROM, this app works totally fine. > This phone is running Huawei EMUI, even I enabled all the permission this app wanted, enabled persistant notification and give the self-startup permission and locked the background to be not killed. The EMUI is still going to kill the app like the packet capture file suggests. From an experienced user, I know that their background whitelist was hardcoded into the android framework, so, maybe it's time to check another method. - Allow disconnection to happen, but set up a periodic task so the app reconnects every X minutes. > Maybe works. **BUT** the problem is still existing if the background was killed. - Remove/reduce keepalives, and hope the connection will still be open when the phone is back from doze. Unfortunately, in Java it's not possible to tweak keepalive's parameters like we do on the desktop. > Maybe you could do some tweaks or some magic, check the Part 3 message. > If you remove keepalives, then the incoming call notification plugin may need to be removed cuz the reason I listed above. - Can you try disabling battery optimizations for kdeconnect and see if it makes any difference? That would be the easiest of the three things. > Already answered on the first quote block. Thanks for your understanding and patience. Your guys did a really perfect job.
Part 3: Maybe a solution? (Cuz I'm NOT a native speaker of English, the word may not be so suitable. So sorry for that. Also, I'm just a geek for Android, not a developer, hope the following things may be useful to you. These methods may be black magic, use with caution and maybe just Using them on some ROMs(eg. Huawei EMUI) is okay.) 0. Ask user to whitelist this app and enable persistent notification by default if some custom ROM detected. 1. Double processes to keep service alive via AIDL (based on `onStartCommand() return START_STICKY`) 2. Trying to decrease the value of `oom_adj`: - Listen to lock screen broadcast and then open a single pixel activity. - Loop play some "empty" audio - Use JobScheduler to wake service up if killed
We already use START_STICKY and a persistent notification, but it doesn't seem to be enough on some phones. Could you test disabling battery optimizations for KDE Connect, and let us know if it solves or not the problem?
Not working on some ROM, such as HUAWEI EMUI.