On Android 10 the share files feature fails when the default
directory is selected. When selecting a custom directory, the
permission is explicitly asked to the user, which makes the
feature work. When the location is switched back to the default
location, the feature is again broken.
The requestLegacyExternalStorage flag brings back the old
behavior and allows to write in the directory. It should be however
ignored for Android >= 11 according to the docs:
https://developer.android.com/training/data-storage/use-cases#opt-out-in-production-app
From Android 11, the Downlods directory should not need specific permissions.
## Summary
This contains some minor code quality improvements in
`RunCommandControlsProviderService`, as well as the following feature changes:
* If the device for a Device Control is reachable, clicking on the secondary
space of the control will launch RunCommandActivity. If the device isn't
reachable, we launch the MainActivity like usual.
* Pixel 7 and other modern Google devices can now show KDE Connect commands
in the 'Home' quick access tile (you still have to 'add app')
## Test Plan
0. Make sure your Android OS supports Device Controls (Android 11+)
1. Choose a paired device to work with
2. Place at least one command in the Run Command list
3. Enable the command in the Device Controls screen
4. Test what happens when you click on the secondary space of the control
As discussed in Matrix and BUG: 474121 this plugin is confusing (because
it doesn't actually take a photo, it just launches the camera on your
phone) and its use case can be covered by taking a photo and sharing it,
which only requires a couple extra clicks.
Starting next month (September 2023) it will be required to target
Android 13 to publish to the Play Store.
On Android 13, we need to request the POST_NOTIFICATIONS permission.
This change adds the permission as required/optional to the plugins
that do create notifications. It also adds a popup to request it the
first time you open the app.
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+.
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.
