can subsurface and shell surface be used together to manage surfaces

[Daniel Stone]

Hi,

On Mon, 27 Apr 2020 at 10:02, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> On Mon, 27 Apr 2020 15:07:20 +0800 zou lan <nancy.lan.zou at gmail.com> wrote:
> > I read some documents about chrome OS run Android Apks such as
> > https://qiangbo-workspace.oss-cn-shanghai.aliyuncs.com/2019-09-10-chromeos-with-android-app/Arcpp_Graphics.pdf
> >  As far as I known, chrominum could run upon wayland,  I just wondering how
> > it handle Android windows on wayland.
> > I think the surface of Android apks could be wayland surface in linux, the
> > window could be the shell surface.
> >  Since all the android apks are still running on android container, android
> > window manager will manage these windows, in wayland, the relationship of
> > these surfaces should be parent-       subsurface that map to android
> > windows. That's a little of problem, as you are confirmed, one wl surface
> > can't be both subsurface and shell surface.
> > If each android apks are not subsurfaces, I am confused how Android to
> > handle the input events from wayland.
>
> you'll have to ask or wait for someone who knows ARC++ to answer. I
> don't dare extrapolate details based on that one simple PDF alone.
>
> Android window management is very different from desktop window
> management, and I don't even know if CrOS window management is close
> to either. Using custom Wayland extensions is always a possibility, it
> happens even on the desktops, e.g. GNOME/GTK.
>
> Look at the slide titled "Chromium Wayland Interfaces", for instance.

ARC++ is proprietary, and I haven't seen its source code either.

But looking at https://github.com/chromium/chromium/blob/master/components/exo/wayland/protocol/aura-shell.xml
I would very much expect that the ARC++ client implementation uses
this as an extra to support Android applications running under
Chromium - for example, the titlebar-colour request is certainly
fulfilling an Android need.

Integrating Android into a desktop system is non-trivial. You will
have to make quite a lot of changes along the way: Android assumes
that you have one, or maybe two, applications open, and a status bar,
and maybe a button bar, and that's it. If you want to make Android
behave more like a desktop, then you're going to have to change
Android to fit your desktop, and you're going to have to change your
desktop to accommodate Android.

I believe the ARC++ solution of using multiple top-level windows, and
having the window management be primarily done by the host compositor,
is a better option than trying to use subsurfaces to invert
responsibility and effectively control the window management from
Android.

However, there is no out-of-the-box solution. Whatever you do is going
to require custom development and experimentation. 'SPURV' is a
periodically-refreshed effort from Collabora to see what this
integration would look like, however we never addressed the idea of
having multiple active applications, as it requires too many changes
in Android, such as deep changes to the Android activity manager to
deal with more than one application being current at one time.

Cheers,
Daniel