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?

[Gottox]

@rom1v

Here, IIUC this is not the case (we are not able to receive the Android player state to synchronize with the client).

I finally got access to a functional MediaSessionManager instance. That would indeed make it possible to synchronize the state between the scrcpy client and the Android Device. I still need to work out how to a) get events from this instance (and its MediaController children) and b) synchronize the state through scrcpy.

I haven't looked into the libdbus itself. So for now it'll remain in libgdbus.

Now to figure out how to wire everything up.

[Gottox]

I updated the PR. Currently I'm facing the issue, that the MediaSessionManager and the MediaController do not emit any events. Any pointers what the issue could be here?

Edit: fixed. I needed to start a new HandlerThread.

[MultisampledNight]

First of all: Thanks!! This is amazing!! 🎉
Then: noted a few small things I noticed while skimming through. I don't know C that well though, so take them with some caution!

[MultisampledNight]

Doesn't this leave target pointing at uninitialized memory if size == 0? Below, the null terminator write was done unconditionally. Putting this here would result in:

Suggested change

	data[size] = '\0';
	memcpy(data, src, size);
	}
	*target = data;
	memcpy(data, src, size);
	}
	data[size] = '\0';
	*target = data;

[MultisampledNight]

Is it intentional that these closing brackets don't match their indentation level? The first one closes the case of DEVICE_MSG_TYPE_MEDIA_REMOVE (henceforth m) while the second one closes the case of DEVICE_MSG_TYPE_UHID_OUTPUT (henceforth o).

(I'm not even sure if the case of m works since it's inside the block opened by o, but I don't know C well enough to say for sure. Maybe cases inside a switch can be in nested blocks and blocks aren't hard scopes.)

[MultisampledNight]

Is there a reason the Pause method is not logged like the others?

Suggested change

	if (g_strcmp0(method_name, "Pause") == 0) {
	g_dbus_method_invocation_return_value(invocation, NULL);
	if (g_strcmp0(method_name, "Pause") == 0) {
	LOGD("mpris: Pause");
	g_dbus_method_invocation_return_value(invocation, NULL);