ARC++

At the 2016 X.Org Developers Conference (XDC) in Helsinki, David Reveman gave a talk about the ARC++ project, which allows Android apps to run unchanged on Chrome OS. In order to make that work, there was some significant impedance matching that needed to be done. Reveman described how it all worked in a session on the first day of the conference.

The name "ARC++" comes from a previous project, called the "App Runtime for Chrome" or ARC, that was launched in 2014. It was a plugin for the Chrome browser, but required developers to change their apps to run in that environment. The plugin had to emulate multiple Android layers, which had performance implications. In the end, ARC "never really took off", he said.

So a new project was started, ARC++, with the goal of allowing access to all of the Play Store apps without requiring changes to those apps and with minimal changes to the underlying Android framework. The goals also included keeping Chrome OS secure, while maintaining the Chrome OS update model. In ARC++, Android apps are isolated from Chrome OS as much as possible, by using Linux containers. The apps run in the containers, while Chrome OS runs as it normally does.

Reveman then went into an overview of the graphics stack for ARC++. It is a complicated stack, as can be seen in the diagram from his slides [PDF] below on the left. A YouTube video of the talk is also available for those interested in further details.

Android apps typically use the hardware-accelerated Canvas API that has been available since Android 4.0. Some other apps, especially games, use OpenGL ES (GLES) directly, though they may use the new Vulkan 3D graphics API in the future.

Everything in Android is rendered to a Surface; those Surfaces are produced by apps and placed into a queue that is consumed by SurfaceFlinger. The gralloc hardware abstraction layer (HAL) is used to allocate the buffers that underlie Surfaces, both in Android and ARC++. For ARC++, gralloc and the GLES driver use the Direct Rendering Manager (DRM) subsystem in the kernel for rendering. That allows apps to use fully accelerated GLES or to use other rendering APIs (e.g. Canvas) as needed. Some day, the apps may use Vulkan, but ARC++ doesn't care so long as the target is a gralloc buffer, he said.

For compositing in Android, Surfaces are sent to SurfaceFlinger, which uses GLES to do the compositing. For ARC++, though, the Hardware Composer HAL (HWComposer) handles all of the Surfaces. They are forwarded to Chrome OS for compositing along with the rest of the Chrome OS user interface.

For window management, ARC++ takes advantage of some of the recent multi-window work that has been done for Android. Certain operations are handled by Android and the others are managed by Chrome OS. The absolute positioning and resizing of windows are done by Android, while maximize, minimize, and full-screen operations are managed by Chrome OS. In addition, app switching, multiple profiles, screen magnifiers, and the like are handled by Chrome OS.

DRM and kernel modesetting (KMS) are used on Chrome OS. DRM is also used by Android and that is what allows efficiently integrating Android and Chrome OS, Reveman said. For both, DRM is used for rendering and buffer allocation; that is what allows easily sharing graphics buffers between the two. Chrome OS is a DRM master, so it can program the display controller, while Android does not need the modesetting capabilities, as it can just needs access to the GPU via a render node.

Low-level input and graphics on Chrome OS are handled by the Ozone abstraction layer that targets everything from embedded system-on-chip (SoC) graphics to X11 and its alternatives (e.g. Wayland). It uses a GpuMemoryBuffer object to hold DRM buffers that have been allocated using gralloc on the Android side or DRM itself on the Chrome OS side. That abstraction allows platform-independent code, such as the Chrome browser compositor, to take advantage of low-level graphics buffers.

The pixel formats (i.e. the color schemes and sizes used for in-memory pixel representation) in Chrome OS are limited and more had to be added for Android apps. In order for a DRM buffer to be imported into Chrome OS from Android, the pixel format of the buffer has to be supported. Some formats were only supported by falling back to converting them in software, though that is rare now, he said.

Exosphere is a Chrome OS component that allows other clients to connect to the user interface. It protects Chrome OS from potentially malicious clients, such as Android apps, by doing validation of the operations requested. It is built on top of the GpuMemoryBuffer framework.

Applications on Chrome OS run within the Chrome browser. Its compositor has a multi-process architecture, with one browser process that starts a renderer process for each tab. Those renderer processes produce frames that get sent back to the browser process. One difference between Chrome and Android is in synchronization. It is relatively simple for Chrome, where there is just one process that talks to the DRM driver from a single thread. In ARC++, though, multiple threads in the Android container make things more complicated. Right now, there is something of a "fence dance" that is done to ensure Android does not reuse a buffer before the GPU has finished with it; in the future, it is expected that explicit synchronization will allow that dance to be removed.

For the graphics, window management, and input communication between Android and Chrome OS, the Wayland protocol was chosen. There are a number of benefits to that approach, including Wayland's limited API that allows easier validation from a security point of view, Reveman said. Most of the interfaces needed were already present, but ARC++ did add a few. Another advantage is that Wayland is well-tested and has a set of existing clients that could be used to test and validate the ARC++ implementation.

The project is currently going through the process of deciding which of the new interfaces should go upstream and which should be discarded in favor of upstream. Some existing Wayland interfaces did not do quite what was needed for ARC++ and the developers did not have time to work with upstream at the time. There is also interest in adding a few more interfaces, for things like explicit synchronization for releasing buffers and presentation timing, as well as protected buffers for digital rights management.

The code for ARC++ can be found in the Chromium source tree. For example, Exosphere can be found here and the Wayland extensions can be found in this repository.

Reveman gave a few demonstrations of ARC++, including the Play Store app running on Chrome OS and multiple YouTube apps running while switching between them. There is gamepad support as well. When running a system in developer mode, you can have normal Wayland applications communicate with the compositor and run in Chrome OS when it is running an environment that allows running regular Linux applications on a Chrome OS device, such as crouton.

In answer to some questions from the audience, Reveman said that there were really no problems for regular Wayland applications due to the extensions made to the protocol. Chrome OS supports regular Wayland just fine; applications could even take advantage of the ARC++ extensions, though he doesn't recommend doing that. So far, there is a single Wayland application on Chrome OS—Android—and there are no plans to change that right now, but that could perhaps change down the road.

[I would like to thank the X.Org Foundation for sponsoring my travel to Helsinki for XDC.]