Distributions

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.]

Comments (7 posted)

Distribution quotes of the week

— Stephen J Smoogen

— Wookey (Thanks to Paul Wise)

Comments (none posted)

Debian Project mourns the loss of Kristoffer H. Rose

Ana Guerrero Lopez sadly reports that Kristoffer H. Rose died on September 17. "Kristoffer was a Debian contributor from the very early days of the project, and the upstream author of several packages that are still in the Debian archive nowadays, such as the LaTeX package Xy-pic and FlexML. On his return to the project after several years' absence, many of us had the pleasure of meeting Kristoffer during DebConf15 in Heidelberg. The Debian Project honours his good work and strong dedication to Debian and Free Software. Kristoffer's broad technical knowledge and his ability to share that knowledge with others will be missed. The contributions of Kristoffer will not be forgotten, and the high standards of his work will continue to serve as an inspiration to others."

Full Story (comments: none)

Ubuntu 16.10 (Yakkety Yak) Final Beta released

The Ubuntu team has announced the final beta release of Ubuntu 16.10 Desktop, Server, and Cloud products. Beta images are also available for Kubuntu, Lubuntu, Ubuntu GNOME, Ubuntu Kylin, Ubuntu MATE, and Ubuntu Studio. The final release is expected on October 13.

Full Story (comments: none)

Ubuntu Online Summit

The next Ubuntu Online Summit will take place November 15-16. "At the event we are going to celebrate the 16.10 release and all the great things which are new and get to talk about what's coming up in Ubuntu 17.04."

Full Story (comments: none)

Distribution newsletters

• DistroWatch Weekly, Issue 680 (September 26)
• Lunar Linux weekly news (September 23)
• openSUSE news (September 22)
• openSUSE news (September 23)
• openSUSE Tumbleweed – Review of the Week (September 23)
• Ubuntu Weekly Newsletter, Issue 482 (September 25)

Comments (none posted)

Firefox OS, B2G OS, and Gecko

Ari Jaaksi and David Bryant posted a note to the B2G (Boot to Gecko) OS community looking at the end of Firefox OS development and at what happens to the code base going forward. "In the spring and summer of 2016 the Connected Devices team dug deeper into opportunities for Firefox OS. They concluded that Firefox OS TV was a project to be run by our commercial partner and not a project to be led by Mozilla. Further, Firefox OS was determined to not be sufficiently useful for ongoing Connected Devices work to justify the effort to maintain it. This meant that development of the Firefox OS stack was no longer a part of Connected Devices, or Mozilla at all. Firefox OS 2.6 would be the last release from Mozilla. Today we are announcing the next phase in that evolution. While work at Mozilla on Firefox OS has ceased, we very much need to continue to evolve the underlying code that comprises Gecko, our web platform engine, as part of the ongoing development of Firefox. In order to evolve quickly and enable substantial new architectural changes in Gecko, Mozilla’s Platform Engineering organization needs to remove all B2G-related code from mozilla-central. This certainly has consequences for B2G OS. For the community to continue working on B2G OS they will have to maintain a code base that includes a full version of Gecko, so will need to fork Gecko and proceed with development on their own, separate branch." (Thanks to Paul Wise)

Comments (3 posted)