After upgrading to Android 15 I noticed the automatic clipboard push from Android stopped working,
debugging it, figured out that it looks like the format of lines in the logcat has changed,
this patch got it working again.
So we can see crashes in previous sessions of the app. Also, Android only
lets apps see their own logs anyway (at least in recent versions), so there
should be no privacy concerns from someone sharing those logs.
## Summary
Previously, URLs shared to offline targets via the ShareActivity were
delivered to them once they became online. This change extends this
behavior to direct share targets.
## Test Plan
Test 1
* Make sure a PC device is already paired with the phone. Let's say the name of this device is "PC".
* Make PC unreachable, e.g., close the KDE app on it.
* On the phone, open Chrome and share a couple of webpages to KDE's PC's direct share target.
* Open the KDE app on the PC.
* Observe that the webpages are opened on PC.
Test 2
* Make sure a PC device is already paired with the phone. Let's say the name of this device is "PC".
* Make PC unreachable, e.g., close the KDE app on it.
* On the phone, share a file to KDE's PC's direct share target.
* Open the KDE app on the PC.
* Observe that the file is sent to PC.
Test 3
* Make sure two PC devices are already paired with the phone. Let's say the name of these devices are "PC1" and "PC2".
* Make PC1 and PC2 unreachable, e.g., close the KDE app on them.
* On the phone, open Chrome and share a couple of webpages to KDE's PC1's direct share target.
* Open the KDE app on the PC2.
* Observe that the webpages are NOT opened on PC2.
* Open the KDE app on the PC1.
* Observe that the webpages are opened on PC1.
Test 4
* Make sure a PC device is already paired with the phone. Let's say the name of this device is "PC".
* Make PC reachable, e.g., have the KDE app open on it.
* Try to share a URL from the phone to the KDE's PC's direct share target.
* Observe that the URL opens instantly on the PC.
Some Android versions seem to hang if calling sslSocket.getOutputStream()
from within the HandshakeCompleted callback (maybe because calling it in
on a socket that hasn't finished the SSL handshake is supposed to trigger
the SSL handshake).
BUG: 501241
Reading the docs, BufferedReader maybe could read and cache more than one
line from the socket, and since we discarded the BufferedReader and
created a new one (up to three times), data could be lost.
