Android will ignore permission request and will not show the request dialog
if the user's action implies "don't ask again."
This leaves the app in a crippled state and the user confused.
Google says "don't try to convince the user", so it returns false for `shouldShowRequestPermissionRationale`.
To help the user proceed, we show the `Request permission` button only if `shouldShowRequestPermissionRationale == true`
because there's a good chance the premission request dialog will not be ignored.
If `shouldShowRequestPermissionRationale == false` we instead show the "rationale" message and a button to open
the app info dialog where the user can explicitly grand the permission.
This ensures that android is always built with the deps we build
with wrap.
Also put back the asm disable for openssl since the version we use needs
that flag
For some reason the type annotations here show @NonNull but that is
actually false according to the documentation under service.
This may be null if the service is being restarted after its process has gone away, and it had previously returned anything except START_STICKY_COMPATIBILITY.
This adds a button that can jump to the bottom of the log view.
If the user scrolls up we now disable the auto scroll down and show the
down button. When the down button is clicked the auto scroll resumes and
the button is removed.
org.musicpd.action.StartService
org.musicpd.action.StopService
You can test these actions like:
adb shell am broadcast -a org.musicpd.action.StartService org.musicpd
Calling these from an app like tasker should allow for automation
The `android` command was depricated and has been removed from new installs of the sdk
The license file existing is about all that is stable between different sdk versions and
cli vs Android studio installs
This starts a Media3 MediaSession when the service starts. A custom player class gets passed into that session to receive commands from other apps and the android os.
Currently we pad out some dummy items to make SimpleBasePlayer think we can do next and previous tracks.
MPD handles the threading for the native calls so we can just directly call the bridge from the player class.
This will allow the android client to directly make calls to the mpd process to change tracks
I went with camel case on the function names here, if you use an underscore
javac generates a function tht looks like this:
JNIEXPORT void JNICALL Java_org_musicpd_Bridge_play_1previous
I figured what we ended up with looks a little nicer:
JNIEXPORT void JNICALL Java_org_musicpd_Bridge_playPrevious
Logs will be maintained and appended even when the main UI is not bound to the service.
This also lets us log without filling a Handler with a bunch of messages we might just throw away anyway.
Dagger and hilt give us dependency injection which makes it easier to split up parts of the app. This lets us easily split out things like logging and paves the way to migrate off preferences to DataStore
This also remove the process name on the service to pull eveything into one process so we don't have to do IPC to pass logs around. This lets us use the same instances of injected classes between the UI and the service side.
This changes lets us use the latest UI design from Google, Material 3.
Google only provides the material UI 3 themes for compose, compose only works with kotlin.
We're not interested in the *.class files, we run javac only to
generate the JNI header. By using @PRIVATE_DIR@, it gets stored to a
directory we can ignore, and not into the source tree.
