Software Device Enablement for Android Upstream

Recent Updates:

Introduction

Hardware with good software support, such as 96Boards, is a critical tool both for testing and validation of the latest AOSP and latest stable and upstream kernels, but also key for prototyping both new hardware and software. 

While, with the Google Pixel Phones, there are a number of form-factor devices which are supported in AOSP, those devices are (for the most part) locked to a specific vendor BSP kernel. Given the time required to go from early bringup to shipping a product, the kernel supported by the form factor devices are always one and a half to two years old by the time they ship. This means these devices have little value for testing the current upstream kernel, and each device is really only useful for testing updates to the -stable kernel release it shipped with. This makes them less than ideal for developing any functionality that can be pushed upstream into the mainline kernel. 

Additionally, because the form-factor devices are enclosed, there is little ability to prototype hardware that didn’t ship on the device. 

Hardware with a well implemented software stack integrated into AOSP is able to solve both of these issues, as we prioritize devices that are close to upstream and continually push to upstream any board specific patches needed, so we are able to always move forward to newer kernels and continue to support a wide array of stable kernels. 

This allows us to quickly find and report regressions that come up in the mainline or -stable branches that might affect Android / AOSP.

Also hardware in the form of developer boards (devboards) are useful platforms for developing new functionality. The DMABUF Heaps interface, which replaces ION in future kernels, was prototyped and validated on the AOSP devboards, allowing us to confidently know that the patches we were submitting upstream would work well with Android. Additionally, initial prototyping of Google’s GKI effort was done on AOSP devboards, in order to work out issues and to minimize issues that vendors might run into and slow product shipping. Google developers have also used these boards to validate changes such as filesystem and UFS crypto changes that they were pushing upstream.  This is much better than having to develop in Android against an older device kernel and then forward porting the patch to the latest upstream kernel and, having no other way to validate it, hoping it works properly when it makes it upstream.

Since the devboards have a wider array of expansion ports that often can be used to prototype and validate new hardware designs that are targeting Android, making it easier for vendors to validate their kernel drivers and Android HALs against the latest mainline kernels and AOSP userland.

We have also leveraged the work done for the devboards to enable some of the derived form-factor devices to also work with mainline and AOSP. This enables us to use them for regression testing of features such as display panels, touch that are testable only on form-factor devices. Our efforts on running mainline on form-factor devices also helps community developers to utilize the knowledge to enable other devices.

Roadmap

Current Plan

Edit the macro below and add the appropriate project in the JQL query

Backlog

Edit the macro below and add the appropriate project in the JQL query

Accomplished

Edit the macro below and add the appropriate project in the JQL query

Active Members

 

Project Meetings

Project meetings happen every Thursday of the month. We alternate between two meetings, one for Asian timezone, and another for Europe / US timezone as detailed below.

Project Contacts

  • @Sumit Semwal - Project Lead

  • @Amit Pundir

  • @Sam Protsenko

  • @Caleb Connolly - Intern Engineer

Instructions and Source Code