broadcastUdpPacket will throw if setupTcpListener isn't successful, and
at that point we no longer know the real issue. Re-throw exceptions in
setupTcpListener so we can see what goes wrong.
This is read by F-Droid, so it should fix our app not having an icon or
having outdated screenshots there.
Also, this can be used to update the Play Store by doing:
fastlane supply --version-code <version code> --json-key <path to key>
In a future, it would be nice to update the StaticMessages.sh script so
it converts the app description here to .pot and back so we can have KDE
localization teams translate it and updates are automatically picked up.
When playing music on Windows, we receive MPRIS player updates ~once per
second. This calls the MprisMediaSession updateMediaNotification function
which then calls updateCurrentPlayer which used to call
SystemVolumeProvider's startTrackingVolumeKeys (now renamed to
startListeningForSinks) which is quite bad because on each call:
* It would add yet another copy of this to the listeners list
* It would send a network packet to get the sinks from the other device
Now we only call startListeningForSinks when the tracked player changes.
Fixes the bug described in !359. Since we made sending packets sequential
in !90 (including the payload part of the packet) we could be blocking the
queue for up to 10 seconds if the other end didn't fetch our payload.
This makes the payload part async by default but keeps the option to make
it sync, since we want that behavior in CompositeUploadFileJob.
Added a new KdeConnect Application class that holds the Devices now, while
BackgroundService "only" takes care of the LinkProviders.
Since KdeConnect subclasses Application we have the guarantee that it will
exist as long as our process does, so we can use it as a singleton. This
removes the "BackgroundService.RunCommand" hack (which sent an Intent that
would awake BackgroundService in case it wasn't running already and then
call our code in a callback). This saves lots of round trips between the
system and us and makes things simpler (and stack traces useful) by making
the code sequential.
We already had an Application subclass that I moved to a new helper, which
now the KdeConnect class initializes together with all the other helpers.
