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.
* Remove usage of deprecated WiFi ConnectivityManager
* Only listen for non-cellular network changes (where we can find devices)
* Do not listen for network changes also from PairingFragment
Motivation: We can't publish to the Play Store with a targetSdkVersion < 31
The new targetSdk required two changes:
* Specifying when activities, services and receivers should be exported or
not to other apps. For the ones I wasn't sure of what we want, I made
them exported to not break something.
* Specifying when a PendingIntent should be mutable or immutable. I made
them all mutable for now.
Summary: A simple widget to execute commands from android desktop
Test Plan:
Add the widget and execute commands from it.
By default, the selected device is the first device in the device list.
The selected device can be changed via the widget title.
If there is no commands, the widget show an empty list
If there is no connected device, show the message located in @string/unreachable_description
Reviewers: albertvaka, nicolasfella, #kde_connect
Reviewed By: albertvaka
Subscribers: kdeconnect, nicolasfella
Tags: #kde_connect
Differential Revision: https://phabricator.kde.org/D12507
