Support SurfaceFlinger and Qt Wayland Compositor side by side

There are two separate proposals in Genivi for running Android apps and Wayland apps side by side on the same system:

https://at.projects.genivi.org/wiki/display/DIRO/Wayland+Application+on+Android
https://at.projects.genivi.org/wiki/display/DIRO/Android+display+subsystem+as+a+wayland+client

This would be a useful enhancement of Qt Wayland Compositor, either for the Qt Wayland Compositor to support the SurfaceFlinger protocol and function as the compositor for Java apps, or to implement Qt Wayland Compositor features in an existing SurfaceFlinger.

The ideal solution would be a compositor which can provide Android apps with buffers through the SurfaceFlinger protocol, and Wayland-based apps with buffers through the Wayland protocol.

Assuming that Qt Wayland Compositor, or AppMan, would be used to write the main compositor, the former of the two approaches is probably the most convenient, as you would be able to use all the Qt Quick APIs etc. to customize the window placement etc. and you would easily be able to support additional/custom extensions.

However, it may turn out that the latter of the two approaches is relevant: If an Android app launcher is going to be used as the main entry point and this requires special features or functionality from the SurfaceFlinger, that might be one case. Also, if the Android-based multimedia framework is going to be used, this probably requires access to hardware layers through the SurfaceFlinger. If we don't want to map those APIs, it might be simpler if a working SurfaceFlinger is at the core.

This is similar to the case of GStreamer + Wayland. If existing GStreamer plugins are in use that talk directly to the compositor to get access to the layers, it would be easier to extend the Qt Wayland Compositor to also support SurfaceFlinger than the other way around.

The use case and architecture of the system should be known before a decision is made on which of these approaches to choose, but both are relevant.