GSConnect is sending requests the paired device can't handle (ignoring incomingCapabilities)

[ferdnyc]

Describe the bug

From the logs on the Android side, it appears that several of our plugins send packets (primarily requests) to the paired device without first checking whether the device can accept those packets, despite that information being readily available in the device's incomingCapabilities list (which we receive on initial connection and store in the device's settings).

The battery plugin and the connectivity_report plugin, at least, both have a _requestState() method which will generate a packet (kdeconnect.battery.request or kdeconnect.connectivity_report.request, respectively) and send it to the device. But, recent KDE Connect Android releases do not accept either of these packets, being willing to send updates only at their discretion, not on demand. (kdeconnect.battery and kdeconnect.connectivity_report both still appear in the device's outgoingCapabilities.)

This one-way messaging is correctly reflected in the incomingCapabilities list sent by the device on initial handshake, which GSConnect stores in the list accessible via device.settings.get('incoming-capabilities') , AKA DCONF path /org/gnome/shell/extensions/gsconnect/device/${id}/incoming-capabilities.

For my Android 16 Samsung phone running KDE Connect 1.34.4, that list is:

$ GSETTINGS_SCHEMA_DIR=/home/ferd/.local/share/gnome-shell/extensions/gsconnect@andyholmes.github.io/schemas dconf read /org/gnome/shell/extensions/gsconnect/device/$ID/incoming-capabilities |sed -e 's/, /,\n/g'   
['kdeconnect.battery',
'kdeconnect.clipboard',
'kdeconnect.clipboard.connect',
'kdeconnect.contacts.request_all_uids_timestamps',
'kdeconnect.contacts.request_vcards_by_uid',
'kdeconnect.findmyphone.request',
'kdeconnect.mousepad.keyboardstate',
'kdeconnect.mousepad.request',
'kdeconnect.mpris',
'kdeconnect.mpris.request',
'kdeconnect.notification',
'kdeconnect.notification.action',
'kdeconnect.notification.reply',
'kdeconnect.notification.request',
'kdeconnect.ping',
'kdeconnect.runcommand',
'kdeconnect.sftp.request',
'kdeconnect.share.request',
'kdeconnect.share.request.update',
'kdeconnect.sms.request',
'kdeconnect.sms.request_attachment',
'kdeconnect.sms.request_conversation',
'kdeconnect.sms.request_conversations',
'kdeconnect.systemvolume',
'kdeconnect.telephony.request_mute']

Steps to reproduce

1. Run GSConnect
2. Run KDE Connect Android
3. Pair
4. Know the code (and read the Android logcat)

Expected behavior

GSConnect is a good citizen, and doesn't generate packets the other end is unwilling to accept.

GSConnect version

v71

Installed from

GNOME Extensions website

GNOME Shell version

49

Linux distribution/release

Fedora 43

Paired device(s)

Samsung Galaxy A53

KDE Connect app version

1.34.4

Plugin(s)

Battery, Connectivity Report, possibly others

Support log

Screenshots

No response

Notes

There isn't, technically, any major problem with sending unsupported packets to a device. It will examine them and reject them as unsupported. But it has to do so each time we generate one, and makes those packets effectively noise on the line. They're useless, and the device TOLD us right up front that they'd be useless. Yet the plugin stats on my device show that it's received 103 battery.request packets and 103 connectivity_report.request packets.

To be good citizens of the KDE Connect ecosystem, we should be checking the capabilities on our end, and suppressing (IOW, not generating) any packets that the device isn't prepared to handle.

[ferdnyc]

The way I see it, there are two ways we could approach this.

One would be to have sendPacket() in service/device.js check the packet.type of any packet it's passed against the device's settings.get_strv('incoming-capabilities') list, and if a packet comes through with a type that's not on that list, just drop it on the floor.

The second would be to have each plugin do a device.settings.get_strv('incoming-capabilities') check whenever it's asked to generate any sort of packet to the device, and refuse to even generate the types that don't appear on that list.

Although it's more code in more places, I'm personally leaning towards the second option. It cuts off the unsupported packets sooner, and avoids more unnecessary work (generating the packet contents for packets that won't be sent). It also means that there won't potentially be double checks, if any of the plugins do check whether their packets are permitted.

Amusingly, there is one incoming capabilities check in the plugin code already... but it's for the battery-status report (outgoing update), which isn't collected if the device won't accept it:

gnome-shell-extension-gsconnect/src/service/plugins/battery.js

Lines 391 to 404 in 9a0406e

	_monitorState() {
	try {
	// Currently only true if the remote device is a desktop (rare)
	const incoming = this.device.settings.get_strv('incoming-capabilities');
	if (!incoming.includes('kdeconnect.battery'))
	return;
	this._upower = Components.acquire('upower');
	this._upowerId = this._upower.connect(
	'changed',
	this._sendState.bind(this)
	);

The request, tho, is always blindly sent if the plugin is enabled:

gnome-shell-extension-gsconnect/src/service/plugins/battery.js

Lines 364 to 369 in 9a0406e

	_requestState() {
	this.device.sendPacket({
	type: 'kdeconnect.battery.request',
	body: {request: true},
	});
	}

[ferdnyc]

It's also worth noting that both of the packet types in question are officially deprecated in the KDE Connect protocol, so we definitely shouldn't expect that paired devices want to receive them.