On Android 10 and above, Clipboard needs to be manually sent. Recently the app was shipped with the patches so that users can use adb to grant the required permissions for automatic clipboard propagation.
In case the permissions were granted for automatic clipboard propagation, 'Send Clipboard' option was hidden from persistent notification but was not removed from the DeviceFragment. This MR addresses this.
Certain implementations of the protocol (namely GSConnect) use UUIDS
for the device IDS/command keys, which contain hyphens in them. The
current implementation of RunCommandControlsProviderService (used for
the android 11 power menu command control things) gives the controls
unique IDS with "{deviceid}-{commandkey}" and then tries to split on the
hyphen, which obviously breaks if the device id or command key contain
hyphens. This patch changes it to uses colons to separate them instead.
Note that I've only tested this with GSconnect, but I see no reason why
it wouldn't work with the normal KDE connect implementation too, unless
it uses colons in IDs.
## Summary
Android apps which target SDK 31+ require specifying the mutability of any PENDING_INTENT. This is not supported in the upstream android-smsmms library: https://github.com/klinker41/android-smsmms/pull/193
Until the above PR is merged, we need a solution. I have pulled the code into https://invent.kde.org/sredman/android-smsmms and published the package in the Maven repository in gitlab.
BUG: 464392
## Test Plan
### Before:
Attempting to send an SMS or MMS message using kdeconnect-sms results in no message being sent, and an error being logged:
> V/Sending message: Sending new SMS
> E/Sending message: Exception
> java.lang.IllegalArgumentException: org.kde.kdeconnect_tp: Targeting S+ (version 31 and above) requires that one of FLAG_IMMUTABLE or FLAG_MUTABLE be specified when creating a PendingIntent.
> Strongly consider using FLAG_IMMUTABLE, only use FLAG_MUTABLE if some functionality depends on the PendingIntent being mutable, e.g. if it needs to be used with inline replies or bubbles.
> at android.app.PendingIntent.checkFlags(PendingIntent.java:382)
> at android.app.PendingIntent.getBroadcastAsUser(PendingIntent.java:673)
> at android.app.PendingIntent.getBroadcast(PendingIntent.java:660)
> at com.klinker.android.send_message.Transaction.sendSmsMessage(Transaction.java:267)
> at com.klinker.android.send_message.Transaction.sendNewMessage(Transaction.java:158)
> at com.klinker.android.send_message.Transaction.sendNewMessage(Transaction.java:172)
> at org.kde.kdeconnect.Plugins.SMSPlugin.SmsMmsUtils.sendMessage(SmsMmsUtils.java:188)
> at org.kde.kdeconnect.Plugins.SMSPlugin.SMSPlugin.onPacketReceived(SMSPlugin.java:414)
> at org.kde.kdeconnect.Device.onPacketReceived(Device.java:570)
> <snipped for brevity>
### After:
SMS and MMS sends normally.
## Summary
Fix a logic error in the SMS plugin which caused it to skip the addresses of other targets when reporting group messages.
Notionally, this bug originated with the logic change in !197, where everything switched to using the android-smsmms library.
BUG: 464555
## Test Plan
### Before:
Group messages would be returned as single-target messages between you and the sender, meaning the desktop app would have a bad time showing them.
### After:
Group messages are returned with the appropriate list of addresses, the desktop app groups them appropriately.
With the old logic, the mostRecentTimestamp would effectively only be updated once, the first time the app noticed an SMS/MMS. This means that, until the app was next closed, it would return every message sent or received after that timestamp. Since the app doesn't crash as often as it used to, this can grow to a quite significant number of messages.
