Introduction moved to parent page for this subproject.
Different needs (for different OSes, and combination of OSes)
Can we create a flexible system (group of building blocks)
Each part may need Android Certification or not (Google approved, GAS requirements etc.)
Flexible building blocks: Audio system...
Isolated system (VM, container) or not.
Look at previous mapping Wayland to Surfaceflinger
- what is next step when completed?
--> Not yet completed however...
Running system with Wayland (possibly container) -- communicate with Android especially the hardware overlay part. Sharing resources, common needs like DRM (Direct Rendering Manager)
Enables shared Layer Management
Android could output to Weston being the system compositor. Even multiple Android instances - it's just a window.
Video streaming services like Netflix well implemented on Android
Other needs might drive towards a different Android variations. As systems get more powerful you might consider designing using multiple (Android) instances, even if today it's not typically considered.
Biggest constraint at moment is memory footprint of Android?
Lifetime: Desktop Wayland also has some proprietary protocols that change over time.
...Android renders to its own memory - hand over ... to Weston
Two different architecture choices, and initial thoughts (brainstorm):
Alt. 1. A wayland compositor is the master compositor, a.k.a. "Android on Wayland"
- Android applications act as wayland clients
---> This means Android needs to provide a handle to a file descriptor (pointing to the surface?)
How to access the memory buffers that are being filled by SurfaceFlinger.
Alt. 2. Android Surfaceflinger is master. Wayland part act as client. a.k.a. "Wayland on Android"
We must not modify things in the Android middleware in this case.
How --> A Wayland compositor backend (possibly implemented as Weston backend) acts as an "Android app".
OpenGL version does not matter. For the wayland clients you need to have Wayland GPU libraries.
Eugen: Not too complicated. But not getting generic window management...
Namespace/Container usage (not deeply analyzed yet)
- Using Linux Namespaces for what?
-- For Wayland Compositor
-- For Android system
-- or one of those two, running on the other as the main/host namespace?
Check some important use cases and design from there:
Early video cases -- best supported by Linux/Wayland part. We should not wait for Android bring up.... But
Early cases often done in different way, e.g. adaptive autosar on realtime core, then hand over to Android once it is up.
- HAL interface only modification (do not modify Android middleware)
- Solve (still support) "early video"
Investigate two approaches separately. Harsha look into option 2. Ozgur/Eugen interested in option 1.
- Aim for zero-copy implementation (in final version, first try things out)
ment platforms like GDP, AGL, ...)
HiKey / Kirin is well supported also.
Ref: Collabora's PoC: https://www.collabora.com/news-and-blog/blog/2019/04/01/running-android-next-to-wayland
Some relevant code -- consider the memory handling: https://gitlab.collabora.com/spurv/device_freedesktop/tree/master/spurv/hwcomposer