The information below is taken from MDK v.0.2
Figure below shows an abstracted view of the Ara software stack. The Ara software stack currently requires that exactly one Application Processor (AP) Module running Android is present in the system. (Support for multiple AP modules may be included in a future release of the MDK.) From the perspective of the software, there are two types of modules: those which conform to a particular device class and Android HAL/subsystem (such as cameras, displays, human interface devices, etc.), and those which don’t conform to any device class (modules with functions which are novel, unique, or otherwise special-purpose). The latter case often have associated custom libraries and/or applications.
The figure shows the software interfaces and interactions for conforming and non-class conforming modules. Conforming modules use generic device class drivers that interface with updated Android HALs and services to enable the unique modular features on the Ara platform. These features include support for hotplugging modules and recon;guring the device without having to recompile and update the kernel and Android configuration. A set of device class definitions, UniPro-based communication protocols, and associated kernel drivers will enable a set of devices commonly found on smartphones today including displays, cameras, batteries, sensors, audio devices, etc.
Developers of non-class conforming modules can create a custom Android Application, which can then access Android bus interface APIs to communicate with the Bridge PHY Protocol Drivers in the Greybus subsystem to connect to and manage the module.
Communication between modules in the Ara phone is abstracted in the form of Greybus Operations. Both device class protocols and Bridge PHY protocols are encapsulated as Greybus Operations.
MDK 2.0: The present prototype platform software is a modified version of the Linaro Android L release, targeting Marvell AP and NVidia APs. The source tree for each AP will be available made available along with developer hardware, to be announced on the Project Ara website. Some AP-specific binaries have proprietary licenses and may require additional end-user license agreements.
Figure below shows an overview of the software interfaces for the prototype platform. All prototype modules contain either a HS or GP Bridge ASIC. The Prototype Camera, Display, and AP Modules use an HS Bridge ASIC, which tunnels CSI-2 and DSI traTc over the UniPro network transparently. While generic class drivers for displays, cameras, and other common devices are still in development, the Prototype Camera and Display Modules use device specific drivers and HALs targeted for each AP.
Other prototype modules (e.g. Battery, Receiver, Speaker, WiFi/BT, 3G Cellular Modules) use a GP Bridge ASIC and utilize one or more bridged PHY protocols. The HS Bridge ASIC also implements some bridged PHY protocols, which are accessed the same way via Greybus Operations. The Bridged PHY Protocol Drivers in the Greybus subsystem implement their respective protocols’ Operations and interface with existing kernel APIs to enable end-to-end communication between Android applications and module devices.
Linux device drivers provide low-level hardware support on Android devices. On a standard smartphone, the available hardware is fixed, allowing device manufacturers to pre-select a set of device drivers. On an Ara phone, however, almost all of the hardware which is normally an immutable part of a smartphone’s design is designed to be user replaceable and hotpluggable.
The primary requirement to enable Ara features in the kernel is the implementation of the Greybus specification, which defines how modules communicate over the UniPro network on an Ara device. The Greybus specification also defines messaging needed to complete system level functions (defined in a later section) such as module manifest declaration, EPM control, and RF bus configuration.
MDK 0.2: Figure below depicts an abstracted view of a reference implementation of the Greybus specification as a kernel subsystem and its interfaces to other kernel components. The Greybus kernel reference implementation is available as a kernel module, which can compiled against a source tree targeted for various APs. The Greybus kernel module is hosted on Github and will be continuously updated as part of the Ara platform development activities. This kernel code will be merged into the main Linux kernel releases on kernel.org when the implementation is completed.
As shown in figure below, the Greybus kernel module is designed around a central Greybus Core. The key functions of the Greybus Core include interfacing with the virtual file system, parsing module manifest information to identify modules and their capabilities, handling power management features, controlling EPMs to lock and release modules, and configuring the RF bus in the Endo to route RF signals between modules. The Greybus core coordinates these functions with the supervisory controller (SVC) in the Endo. These system-level functions, which require interfaces between the SVC, AP, modules, and users are defined in a later section.
The main function of the Greybus subsystem is to perform the duties of a kernel driver for each module. On a traditional smartphone, the kernel can be compiled with a set of custom drivers since all the devices are known. To enable a seamless experience where users may swap modules from different vendors, with different device classes and different features, and do it with nominal technical skills required of any smartphone user, the traditional kernel driver model must be adapted with a more flexible approach.
To enable the goals of the Ara modular platform, a set of generic class drivers will be specified in the Greybus specification and implemented in the Greybus subsystem. The set of generic class drivers will span a broad range of module devices typically found on smartphones. The current plan includes the the following device classes: audio, batteries and chargers, Bluetooth devices, cameras, consumer IR devices, displays, GPS, input devices, lights, NFC, sensors, vibrators, WiFi, baseband, and other network devices, and storage devices. Future versions of the MDK and Greybus specification will include details for each device class.
As of the current MDK release, the Greybus specification document includes definitions of two generic device classes: batteries and vibrators. These relatively simple devices were chosen to serve as a pathfinder for more challenging devices. Even among devices that perform the same function (i.e. cameras, WiFi), their drivers can be extremely varied among manufacturers and product lines. To ensure that the Ara platform can accommodate the broadest set of devices, generic class drivers must be developed carefully to ensure broad application without sacrificing significant performance. Similarly, we are seeking feedback from the developer community including device manufacturers and device driver vendors to help us compose the appropriate device class definitions in the Greybus specifications. Please contact us at email@example.com if you are interested in engaging in these activities.
One of the advantages of the Ara platform is the ability to accommodate non-traditional devices in a smartphone. Modules that do not fall within a generic class and thus unable to use the generic class drivers are supported through a Bridge ASIC and the Bridge ASIC Driver in the Greybus subsystem. Bridge ASICs are used to translate between UniPro and various common interfaces including I2C, I2S, and USB. The Network section details the complete list of Bridged interfaces supported by the current Bridge ASICs. The Greybus specification defines the operations used on a connection implementing these Bridge PHY protocols, and the Bridge ASIC Driver allows developers to access and manage these connections with an Android Application through Android APIs and standard kernel subsystem interfaces.
The Android software stack is shown in figure below highlighted with modifications and additional components that will be developed to support the unique features of the Ara platform. Android Applications are shown at the very top of stack. The Android Settings App will be modified to allow hardware configurations to change dynamically (e.g. enable/disable location services when GPS module is removed). An Ara Manager App will also be introduced to facilitate user interactions with modules on the device. The Ara Manager App will allow users to get detailed information on all the modules currently attached to their device and swap them by commanding the EPM(s) in the Endo to release. The Ara Manager App and required module interfaces will be provided in a future MDK release.
Android System Services are application components that perform long-running operations in the background and does not provide a user interface. As shown in figure below, many of these services will be modified to enable Android to support hotplug and hardware reconfiguration features. In addition, a new Endo service will be developed to support Android Applications that make use of Ara features. Among its responsibilities, the Endo Service will register/unregister the Ara Manager App, provide hotplug notification and Endo information (i.e. geometry, orientation) to various module developer-supplied Applications, support EPM control, and control module power modes.
Android Hardware Abstraction Libraries (HAL) are implemented as shared libraries; their code runs within Android’s system services. Unlike device drivers, HAL APIs are specified by Google and are updated with each release. Device manufacturers provide library binaries which implement these interfaces in their devices’ system images. These libraries are then subsequently loaded by the relevant system services as part of their initialization. Among other things, HALs provide an abstraction barrier between Android system services and the various device driver interfaces exposed by the kernel for different hardware peripherals those services must control.
MDK 0.2: Current HAL APIs assume a fixed hardware configuration and will require modifications to support hot-plugging features inherent to the Ara architecture. Firstly, a set of HALs will be modified, as shown in figure above to match the set of kernel device class drivers. These HALs will be adapted to support hotplugging events. Each HAL will monitor device availability and return generic values to dependent services without causing the system to crash in the event that a device is not present (e.g., provide null or zero values if GPS sensor is not present or issue off commands for user-controllable devices like WiFi). HALs will also detect any change in module availability and notify dependent services upon module insertion and device availability.
We are currently developing a modified version of Android L to enable dynamic hardware configurations on the Ara platform. These modifications will include support for modules to be swapped and hotplugged, support for Greybus, and integration with Google Play services for dynamic driver and application distribution. The plan is to merge these modifications back into mainline Android in the future. Specifications for Android HAL will be defined in full in a future MDK release.
MDK 0.2: The prototype Android release includes existing HALs, yet to be modified to support hotplugging and dynamic hardware reconfiguration. Additionally, the prototype Display and Camera Modules also require device-specific HALs targeted for each AP.
As shown in Figure 6.5, a representative set of HALs will be modified to support required Ara features. Modifications for each existing HAL will vary in complexity and scope. The Bluetooth HAL for example can be extended by ensuring a maximum set of Bluetooth profiles and configurations can be accommodated. On the other hand, the Battery HAL must be modified to support a wide range of battery technologies, multiple battery modules, and enable hotplugging and related functions such as aggregation and calculation of overall system battery usage and statistics. All modified HALs and a description of the required modifications will be provided in a future MDK releases.
In general, Android applications for the Ara platform are not in any significant respect different than traditional Android apps. Consequently, Ara devices are anticipated to be compatible with most standard apps. Where unique Ara features are required, the Endo Service will provide notification and callback interfaces to Android applications. These interfaces will be specified in a future MDK release.
The Android developers portal describes Android application development. Additional guidance and reference materials are also readily available from many third party sources. App developers are encouraged to pay attention to application stability and graceful behavior in light of dynamically varying availability of hardware resources (as with hot-plug, for instance).