initial MPRIS support

[Gottox]

This PR adds support for the MPRIS Dbus protocol as described in #4080. My first approach was to directly use the low level API, but unfortunately the usage of the library is discouraged:

This manual documents the low-level D-Bus C API. If you use this low-level API directly, you're signing up for some pain.

So I felt back on the glib API and tried to get an glib event loop running in a worker thread.

For now the only event that has been wired up is the Raise method.

The goal for the first iteration is to only get the media keys working. Later iterations could also update the current track metadata if they can be extracted from the device. I haven't looked at the server implementation yet.

This implementation is unfinished and meant as an opportunity to see if @rom1v considers the approach acceptable.

addresses #1824, #4080

[rom1v]

Thank you for your PR, and for posting an early draft 👍

AFAIU, dbus/mpris is useful to control a player with a feedback, i.e. the client knows the state of the media player and get asynchronous updates.

Here, IIUC this is not the case (we are not able to receive the Android player state to synchronize with the client). In that case, maybe shortcuts are sufficient (#1824)?

Also, how does it interact with a local media player? For example, in my case, I don't want the media keys to control the Android device but my audio player on the computer.

So I felt back on the glib API and tried to get an glib event loop running in a worker thread.

I would like to avoid adding a dependency to glib. The low-level API can still be used, like in VLC:

https://code.videolan.org/videolan/vlc/-/blob/master/modules/control/dbus/dbus.c

But without state feedback from the device, I'm not sure the feature is useful. What do you think?

[Gottox]

My usecase: Since scrcpy supports audio forwarding (❤️❤️❤️), I really enjoy putting my phone into the dock and my desktop and seamlessly continue listening to music/podcasts on my desktop. While scrcpy is pretty good at forwarding, the integration of my android players into my desktop environment would be a real cherry on top.

Also, how does it interact with a local media player? For example, in my case, I don't want the media keys to control the Android device but my audio player on the computer.

That depends on the desktop environment. Gnome for example can handle multiple sources:

Also, in the final version, I would hide it behind a cmdline option: --mpris

I would like to avoid adding a dependency to glib. The low-level API can still be used, like in VLC:

Thanks! It looks quite massive, but I'll have a look.

But without state feedback from the device, I'm not sure the feature is useful. What do you think?

I believe that it would already have a benefit if a user can control the music on the android device without having scrcpy in focus. At least that would be a nice start for me.

I'm currently looking into the MediaSessionManager (src) API of android.

Up to now I'm unable to instantiate it, but if I understand correctly, it would allow control over all MediaSessions of a device and also can request metainformation about these sessions. My knowledge of the Android API is pretty basic and I have no real idea how to instantiate system services without the default getSystemService() interface.

Do you think that's feasible?