Hi, On Mon, 27 Apr 2020 at 10:02, Pekka Paalanen <ppaala...@gmail.com> wrote: > On Mon, 27 Apr 2020 15:07:20 +0800 zou lan <nancy.lan....@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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
