Page tree
Skip to end of metadata
Go to start of metadata

Introduction

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. 


Background

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.

Use cases:
    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.

Solutions
Android renders to its own memory - hand over ... to Weston

Architecture choices

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...

Container usage
- 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.

prerequisite requirements:
    - HAL interface only modification (do not modify Android middleware)
    - Solve (still support) "early video"
    
Work plan:
    
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


Requirements

- Aim for zero-copy implementation (in final version, first try things out)


Define a shared Android basic working platform (hardware and setup),
open and reproducible starting point (similar to: other development platforms like GDP, AGL, ...)
Hardware choice?

- Renesas starter kit preferred by many
- Intel & Qualcomm available but longer starting path (ADIT)
- i.mx8 was used by Collabora

HiKey Kirin is well supported also.


Other references

Anbox: (another benchmarking)
https://anbox.io/
In contrast to Google's implementation, Anbox doesn't allow any direct access to hardware devices. For example it bridges Open GL ES to the host. In Chrome OS the container gets access to the host kernel side of the graphic subsystem to allow fast rendering. In our case, we decided against this to keep an easy way to port Anbox to different platforms. All a host operating system needs to provide is a Open GL / Open GL ES compatible driver to provide proper integration with the graphics subsystem. Other hardware devices like WiFi or Bluetooth will be abstracted in the future via a dedicated APIs between the container and the host.


  • No labels