Hi Daniel Thank you for reply my question about 'SPURV'.
If 'SPURV' only support one active application on one display, does it consider to support multiple displays? can I ask if there is any plan to update 'SPURV' to match hwc2 or the latest Android version? Thank you! Best Regards Nancy Daniel Stone <dan...@fooishbar.org> 于2020年4月29日周三 下午5:11写道： > 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
