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

Introduction

Introduction  moved to parent page for this subproject.

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


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.

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.  Ozgur/Eugen interested in option 1.

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.

Update:  See planning page for Android Dev Platform in Android SIG


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.

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



  • No labels