The version of the library we used stopped working in 2020 when the names
database it tries to download got deleted from the master branch of their
Github repo. There's a newer version, but it seems to have lost the
fetch-from-the-internet functionality (it only bundles a list of names) and
for some reason it crashes when I tested it (I've opened an issue on their
repo). Since Google now provides a CSV with all the Android device names
that exist, I've replaced the library by my own function that downloads the
CSV file (~3MB) in the first run of the app and looks for the name there.
Rewrites the RunCommand widget. Now we can have different widgets for
different devices at the same time. Also removes the startService call
that could cause ForegroundServiceStartNotAllowedException on API 12+.
We don't want to crash if we get onNetworkChange before tcpServer has been
initialized, however the way to do it was wrong because the exception was
being thrown from a new thread.
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.
