If the phone is in sleep mode, it is not visible nor accessible from other kde-connect devices. After playing around with the code, it looks like the problem is that in sleep mode Android ignores UDP broadcasts. If UDP anouncement is sent directly to a known IP address of the phone instead of broadcasting - then everything works ok. As a thread in google groups (https://groups.google.com/forum/?fromgroups=#!topic/android-platform/OpbSdp9FTmA) suggests, it is probably related with specific hardware. Maybe instead of broadcasting some other announcement method could be used or a workaround discussed in the google groups could be implemented? My phone model which has the issue is LG G2
Environment: Phone model: Xiaomi Redmi note 3 pro (MIUI 8.2 global ROM) KDE Connect 1.6 on phone, 1.0.3-1 PC Phone and PC have been paired. Steps to reproduce: -let phone enter standby -reboot PC Result: "No paired devices available" until phone is first activated from standby. As soon as the screen goes on, everything KDE connect related starts working, I don't even need to unlock it. Reproducible: always. Notes: KDE Connect on phone granted every priviledge (auto-start, read SMS, allow notifications on lock screen etc) I'm hereby confirming the bug.
This might be because of the Android Doze feature, which tries to save battery by limiting apps functionality when the phone is iddle. Can you try disabling "Battery optimization"for KDE Connect, and see if that fixes the problem? You can follow this blogpost on how to do it: http://www.greenbot.com/article/2993199/android/how-to-turn-off-doze-mode-for-specific-apps-in-android-marshmallow.html
Created attachment 105287 [details] Battery optimization disabled Doze feature is disabled. Still experiencing same issue.
Created attachment 105288 [details] MIUI battery saver settings Appart from Android battery optimizations MIUI comes with it's own power saving system. Providing picture of settings in effect for KDE connect. Still experiencing same issue.
It might be different issues, but please note the google groups thread I did mention in the first thread. It look like it is pretty deep in the network stack and related how it handles IP broadcast packets in particular. There is also a workaround mentioned, but it is a little bit ugly I think.
This is an Android limitation. If you add forks on top you're just making things harder. Not much we can do on our side.