https://bugs.kde.org/show_bug.cgi?id=527012
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Android mDNS discovery |Android: long-lived Wi-Fi |holds an app-level |multicast lock during |multicast lock for its |background discovery |entire lifetime | --- Comment #1 from [email protected] --- Description KDE Connect Android holds kdeConnectMdnsMulticastLock for long periods while its background discovery service runs. This enables blanket Wi-Fi multicast reception, including traffic unrelated to KDE Connect. On my OnePlus 13, the original build accumulated 16 hours 38 minutes of multicast-lock time during a statistics period with about 18 hours of foreground-service time. Steps to reproduce 1. Run KDE Connect Android 1.35.17 on a Wi-Fi network permitted by its trusted-network settings. 2. Pair it with a desktop and leave the background service running. 3. Turn the phone's screen off and leave it connected to Wi-Fi. 4. Inspect the active multicast locks and accumulated battery statistics: adb shell dumpsys wifi adb shell dumpsys batterystats --charged Look for kdeConnectMdnsMulticastLock in the Wi-Fi dump and the WiFi Multicast Wakelock entry under KDE Connect's UID in the battery statistics. Observed result KDE Connect keeps its multicast lock while mDNS discovery runs. The lock lifetime follows discovery, rather than a short discovery transaction. This report concerns that long-running behavior, not a lock that fails to release after discovery stops. Expected result KDE Connect should remain available for background connections and discovery while allowing normal Wi-Fi multicast filtering wherever the platform can provide those functions without blanket multicast reception. Software versions - OnePlus 13, CPH2653 - Android 16 - KDE Connect Android 1.35.17 - Initial observations on OxygenOS 16.0.10.501; later patched-build observations on 16.0.10.600 Additional observations and limits I tested a local build that removes only KDE Connect's explicit multicast-lock creation, acquisition and release in MdnsDiscovery.kt. NsdManager discovery and registration, UDP discovery and TCP connections remain unchanged. Normal paired-device use has continued to work. The patched app has no multicast-lock attribution in the collected statistics. Separate packet-filter logs show mcast: DROP during screen-off operation when no other app requires multicast reception. These observations do not establish a battery saving. The captures come from different periods, and firmware, access-point conditions and other background activity changed. I have not separately verified discovery of a new peer while filtering is active, or behavior on other Android versions and OEMs. The evidence therefore does not justify removing the lock unconditionally on every supported device. Requested severity: wishlist. -- You are receiving this mail because: You are watching all bug changes.
