During a discussion in the most recent AMM, several people expressed interest in understanding how the traditional Linux graphics approaches can be combined with the interest in Android for Automotive. Looking at the entire car electrical system we already see Android being introduced and combined with other systems, combined in the sense that it is communicating with separate units (ECUs) implementing Linux, or possibly consolidated using virtualization approaches. In addition to this, the opportunity to run traditional GNU/Linux software stacks in parallel with Android stacks on a single Linux Kernel instance, often comes up in conversation.
The GSHA project participants expressed interest in investigating the different software approaches to create flexible building blocks and combinations of GNU/Linux and Android style systems. Based on the project purpose, the initial focus is of course on the graphics stack and HMI composition areas.
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
Alt. 1. A wayland compositor is the master compositor
- Android applications act as wayland clients
---> This means Android needs to provide a handle to a file descriptor (pointing to the surface?)
Alt. 2. Android Surfaceflinger is master. Wayland part act as client.
We must not modify things in the Android middleware in this case.
How --> A Weston backend that 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...
- Using Linux Namespaces for what
-- For Wayland Compositor
-- For Android system
-- or one of those two
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.
Ref: Collabora's PoC: https://www.collabora.com/news-and-blog/blog/2019/04/01/running-android-next-to-wayland
- Aim for zero-copy implementation (in final version, first try things out)
ment platforms like GDP, AGL, ...)
HiKey Kirin is well supported also.