All functionality of KDE Connect works only while the KDE Connect app is in the foreground on the phone. Switching to any other app causes KDE Connect to stop working. It does not receive pings from the desktop, and clipboard sharing is broken. In fact, about 25 seconds after switching away from KDE Connect on the phone, the phone becomes shown as disconnected in the desktop module. Reproducible: Always Steps to Reproduce: 1. Install KDE Connect 1.0 on a phone running Android 6.0.1 (e.g., CyanogenMod 13.0-20160901-NIGHTLY-d2spr). 2. Install KDE Connect 1.0 on desktop running Gentoo Linux, KDE Frameworks 5.25.0, Qt 5.6.1. 3. Pair phone with desktop. 4. Switch away from KDE Connect app on phone (e.g., by pressing Home button). 5. Try to send a ping from the desktop module. (No notification appears on phone.) 6. Switch back to KDE Connect app on phone. 7. Try again to send a ping from the desktop. (Notification appears.) Actual Results: KDE Connect communicates with desktop only while the app is the foreground activity. Expected Results: KDE Connect should continue functioning even while running in the background on the phone.
Android might decide to kill an app if the app is not in foreground and the device is low on memory. There is nothing we can do about it :/
Created attachment 101003 [details] Running app details Thanks for the reply. You've been too quick to dismiss this, though. In fact, the KDE Connect app is always running. You can see in the attached screen shot that its background services have been running continuously for the past 37+ hours. Android is not killing them. They simply don't work unless one of the app's activities is in the foreground.
Created attachment 101004 [details] KDE Connect memory usage statistics Here's another screen shot. Android reports that the KDE Connect app is "Always running (100%)."
After a reboot of my phone, KDE Connect is remaining connected to my desktop even while running in the background. I will attempt to determine the exact conditions under which KDE Connect enters the failure mode described in this report.
This failure mode has recurred several times since I last commented. • I can always bring functionality back by rebooting my phone, but obviously I should not need to do this. • Merely stopping the app's "BackgroundService" and then relaunching the app's main activity does not fix the problem. • Force-stopping the app entirely and then relaunching its main activity also does not fix the problem. (Although the app's uptime does reset upon the Force Stop request, the app immediately restarts to start its "NotificationReceiver" service. The "BackgroundService" is not started until the app's main activity is launched.) • Disabling the notifications permission allows the app to be fully stopped. (It disappears from the list of running services upon a Force Stop.) Relaunching the main activity still does not fix the problem. To reiterate, the problem is that the KDE Connect app does not communicate with the computer unless its main activity is in the foreground. The background services continue running, but they do not maintain connectivity with the computer. Rebooting the phone restores background connectivity. The failure mode always seems to begin when the phone is removed from the WLAN for a while. Upon reconnecting to the WLAN, the app's background service does not maintain connectivity with the computer.
There is a data-race bug in LanLink.java: https://github.com/albertvaka/kdeconnect-android/blob/master/src/org/kde/kdeconnect/Backends/LanBackend/LanLink.java#L116 Because LanLink.socket is not declared volatile, the load from this field on line 116 can see a stale value that was stored before the call to Thread.sleep(…) on line 115. Declare LanLink.socket volatile to ensure that loads from it are always fresh from RAM and are never speculated out of program order.
Is there a way I can reproduce it? This way I will be able to experiment and see what effect adding volatile has. Does simply adding volatile fixes it for you? If this was the case, there are probably many more volatile missing, so I would like to have a way to check the effect of adding/removing them.
(In reply to Albert Vaca from comment #7) > Is there a way I can reproduce it? I'm not sure. KDE Connect is broken for me more often than it works, and I still don't know the exact conditions that cause it to enter the failure mode. I know that rebooting my phone makes it work again for a while. In fact, I did that just now, and now KDE Connect is connected and I can ring my phone from my computer's KDE Connect tray panel. > Does simply adding volatile fixes it for you? I don't have an Android development environment, and I don't know the first thing about developing apps for Android. I'm a Java developer, not an Android developer. > If this was the case, there are probably many more volatile > missing, so I would like to have a way to check the effect of > adding/removing them. Data races are probabilistic and as such are notoriously difficult to reproduce reliably, as they depend on factors outside of the program being tested, such as the global state of the operating system and the specifics of the OS kernel's thread scheduler. Rather than measuring the effects of declaring variables volatile, which sounds a lot like "programming by accident" (https://en.wikipedia.org/wiki/Programming_by_permutation), you should reason about which variables need to be declared volatile. Generally, if you access a variable from more than one thread without any kind of synchronization between the threads, then you must declare the variable volatile. And for what it's worth, Thread.sleep(…) is not a synchronization primitive. In general, there is no upper bound on the amount of time that a thread may be paused between instructions, so you cannot pick any delay time for Thread.sleep(…) that is guaranteed to be long enough. Use proper thread synchronization techniques instead.
Git commit b7418c1db65fa4229ab929efa17642ae01468a8d by Albert Vaca. Committed on 08/12/2016 at 19:50. Pushed by albertvaka into branch 'master'. Socket should be volatile to prevent data-race M +1 -1 src/org/kde/kdeconnect/Backends/LanBackend/LanLink.java https://commits.kde.org/kdeconnect-android/b7418c1db65fa4229ab929efa17642ae01468a8d
KDE Connect has been working flawlessly for me for a while now. I am not sure whether something changed in KDE Connect or if it's due to my upgrading to LineageOS 14.1 (Android 7.1.1). My current versions: KDE Connect (KDE Frameworks 5.32.0) 1.0.3 KDE Connect (LineageOS 14.1, Android 7.1.1) 1.6.1 I can go away from home for days, and KDE Connect works fine upon my return. I can enable Airplane Mode overnight, and KDE Connect works fine when I disable Airplane Mode in the morning. Both of these used to break it. So I am not sure whether this bug still exists, but I am no longer seeing it.
Hi, I can confirm this.... I *think* I have the same problem. I'm pairing my phone with my computer, for the time I'm actively using my phone (e.g remote control with the touchpad on my android phone), it works. After a couple of minutes (sometimes even seconds) it loses the connection and then says "Device not paired. Request pairing." The list of connected devices is empty, unless I click the refresh button (on my laptop). This is odd, because kdeconnect used to work perfectly fine on my setup. I'm using Ubuntu 16.04.2 LTS (KDEConnect: and Android 6.0.1 Are there any logs that I could provide that would help identify the issue? Please, find attached my screenshots that prove it's actually working. It seeems the pairing between the devices is not persistent.
Created attachment 105049 [details] Empty devices list
Created attachment 105050 [details] Discovery of one device after hitting refresh
Created attachment 105051 [details] Device paired momentarily
Also, I forgot to mention which versions I'm running. On Ubuntu: 1.0.3 On Android: 1.6.2 Beta 2 (but it appeared in previous versions as well, just thought the beta might fix the problem)
@Albert/Matt: any idea what's causing my connection drops?!
(In reply to Theresa from comment #16) > @Albert/Matt: any idea what's causing my connection drops?! I never did figure it out. Upgrading to Android 7.1 made the problem disappear for me.
I can confirm that the problem is fixed with Android 7.x Alas my phone (Oneplus One) only has Android 6. Is there any chance of fixing this also for Android 6 devices?
(In reply to Theresa from comment #18) > Alas my phone (Oneplus One) only has Android 6. FYI, LineageOS 14.1 (Android 7.1) is available for the OnePlus One. LineageOS is the successor to CyanogenOS (which, if I'm not mistaken, is what the OnePlus One runs out of the box).
*** Bug 360278 has been marked as a duplicate of this bug. ***
On Gentoo running kdeconnectd 1.2.1-r2 and Android Oreo with KDE Connect version 1.8.1 I can confirm the same behaviour. Run the app in the foreground and the desktop utility shows it is connected. Lock the screen of the phone. Refresh the list of connected devices and the phone is shown as no longer connected. Rebooting the phone does not help.
*** Bug 399236 has been marked as a duplicate of this bug. ***
This used to work just fine, but lately my phones are constantly getting unpaired. To not be connected is one thing, and I've resolved that by disabling all battery saving for kdeconnect, but this auto-unpairing is driving me nuts. This happens with different versions of android on different phones. Steps to reproduce: 1. Open KDE connect on both the phone and computer. 2. Pair them. 3. Hit "Refresh" on the computer. Result: The phone and computer get unpaired, and need to be paired again.
Open a new bug about the unpairing, please.
Android 9 Pie (MIUI 10.3.5.0), KDEconnect 1.12.7 and the problem is still here. By default the Background permission was granted. Since I checked the autostart permission it sometimes works even if it is closed, but not always and if I reboot the phone it never works until I open the app at least one time. The same happens with other phones:https://www.reddit.com/r/kde/comments/c07ta1/kdeconnect_works_only_with_the_app_opened/
Just to add my 2 pennyworth, I have also been seeing this problem since getting a new 'phone running Android Pie. It never occurred on my older 'phone running Lollipop, even though that device had less RAM. I have other apps (on both 'phones) which can happily sit in background without being killed, whereas Kdeconnect can, at worst, get killed several times per hour. So it would appear that it needs *some* extra permissions to stop the OS killing it when it's in the background. Some comparisons of permissions in case it helps work out what's needed: Bikeometer (GPS ride tracker) Notifications allowed: display in status bar, lock screen notifications Permissions: location (precise and approx), storage, modify/delete memory card contents, read memory card contents, full network access, view network connections, prevent 'phone from sleeping, play install referrer API, receive data from Internet. SimpleSSHD (SSH daemon) Notifications: display in status bar, banners, lock screen notifications, sound, vibration. Permissions: modify/delete card contents, read card contents, full network access, run at startup. Bedr radio (alarm clock app) Notifications: alarm (status bar, lock screen), information (status bar, lock screen) Permissions: phone (requested but denied), storage (requested but denied), full network access, view network connections, view WiFi connections, connect and disconnect from WiFi, prevent 'phone from sleeping, run at startup, control vibration, change your audio settings, Google Play billing service, run foreground service, receive data from Internet, Play install referrer API. K-9 Mail (email client) Notifications: display in status bar, banners, lock screen notifications, priority display, sound, vibration. Permissions: contacts, storage, delete emails, k-9 mail remote control. read emails, run at startup, read sync settings, view network connections, full network access, control vibration, prevent 'phone from sleeping. KDE Connect Notifications: persistent indicator (lock screen), other notifications (status bar, lock screen), media control (status bar, lock screen), notifications from other devices (status bar, lock screen) badges. Permissions: call logs, contacts, 'phone, SMS, storage, run at startup, full network access, view network connections, allow WiFi multicast reception, control vibration, download files without notification, run foreground service. If there are any other comparisons that might be helpful, please ask.
The bug is still present in Android 10, I am running a stock Pixel 2 XL and I can send links from Firefox on Desktop to the phone only when KDE Connect is in foreground. However, clipboard syncing does work in background (only to PC to Android, but this is an Android 10 limitation).
Same behavior : pixel 2 xl with android 10, kde connect 1.13.2 "ring the phone" action only works when kde connect app is in the foreground.
Also having this problem on one plus 7 pro using android 10. It would seem the update to android 10 has caused this. Here is a relevant comment from one of the guys or gals over at gsconnect from when I was having a conversation with them on their github. Ferdnyc says, "Mm, it's quite conceivable that Android locked the permissions down so they apply only to foreground processes. Any "find my phone" type app I've ever had always had to be configured as a Device Administrator (in the Security settings) in order to perform its function, which is something I notice KDE Connect doesn't ask for (at least on Android 7). The only permission it requests in the 'security' category is the ability to read text messages. ...Actually, looking at the full KDE Connect permissions list on my phone, I can't figure out how it's actually able to activate the ringer at all. It only requests two Phone permissions: "read phone status and identity" "read call log" While it does also ask for "control vibration", that's the ONLY permission it requests that would seem to involve any sort of noise-making ability at all. So, maybe Android 10 just finally started requiring some sort of permission for apps (or at least background apps) that want to be able to activate the ringer. And AFAICT... KDE Connect may not have it?"
Is this still an issue? KDE Connect nowadays has a persistent notification to make sure it keeps running even if in the background, and up to at least Android 11 (I haven't had the opportunity to test any newer Android version) it has always managed to stay connected even while in the background.
(In reply to Bart Ribbers from comment #30) > Is this still an issue? KDE Connect nowadays has a persistent notification > to make sure it keeps running even if in the background, and up to at least > Android 11 (I haven't had the opportunity to test any newer Android version) > it has always managed to stay connected even while in the background. On a pixel 6 pro with android 13. This issue no longer effects me. The persistent notification solves the problem amd ensures it is always connected like you said.
For unknown reasons, my phone sometimes kills every app that isn't either an accessibility service or the currently active app on the turned on screen. And also for unknown reasons, it often disables accessibility services without asking, but some seem to be immune, like MacroDroid. So I've set up MacroDroid to check every minute if a Termux notification exists (because that should also always run on my phone and is more important) and if not, start it and, in my home WiFi or with hotspot on, also KDE Connect. That seems to be the only reliable way to keep KDE Connect always running on my phone, but it's pretty surely not the app's fault. I don't know what's different about MacroDroid that makes it immune, but it has basically all the permissions, including some advanced ones, root, helper app and some that needed to be granted via ADB, so I'm also not surprised that it's basically omnipotent on my phone.
I'm the original reporter on this bug. This is no longer affecting me. I haven't had to manually open/start KDE Connect on my phone within my recollection. It Just Works™. And I'm no longer using the workaround of locking the app in my app switcher. I don't see a persistent notification for it, but maybe I hid that at some point. Irregardless¹, I currently have no complaints. __________ ¹ “‘Irregardless’ isn't even a word.” “Yes, it is; it means ‘without lack of regard.’”
If KDE Connect is not currently open, the "Trusted Networks" option will not work because the app does not offer the "Location: Allow all the time" setting. Would be nice if this option could be added. Thanks.