Project Ara

CHAPTER 1
INTRODUCTION
A modular smartphone is a cellphone that is assembled from discrete parts, so-called
“modules”. The idea of the modular smartphones is to upgrade or replace the phone’s parts
individually according to user’s needs and preferences. Such parts might include a camera,
processor, internal storage, battery, screen and all kinds of sensors. This may save a lot of
money to consumers, because modular phone users won’t need to buy a new device to keep
up with the trend.
Modular phone concept started to earn popularity after the Dutch designer Dave
Hakkens has announced Phonebloks concept in September 2013. The name Phonebloks was
picked up because the concept assumed that the phone would be built from Lego-like blocks,
which users could easily change. Now a days mostly everything related to modular phones is
associated with the Google’s Project Ara
Project Ara is the code name for an initiative by google that aims to develop an open
hardware platform for creating highly modular smartphones. The platform will include a
structural frame that hold smartphone module of the owner’s choice such as display,
keyboard or an extra battery. It would allow users to swap out malfunctioning modules or
upgrade individual modules as innovation emerge, providing longer lifetime cycles for the
handset, and potentially reducing electronic wastage. The first module of the modular phone
is a scheduled to be released in September 2017. The project was originally headed by
advance technologies and project team within Motorola. Mobility while it was a subsidiary of
google. Although google had sold Motorola to Lenovo it is retaining the project team who
will work under the direction of android division
Since modules are interchangeable, a user has the freedom to design exactly the phone
they want and continue to customize the phone over time by replacing modules. Ara’s
success is predicated on a rich, vibrant and diverse ecosystem of modules from developers.
User would be able to select modules from an online market place using a configuration that
facilitates user choice and curates the configuration process to ensure that the selection of
modules provides the expected system level functionality.
Project Ara is a platform for creating modular smartphones. User will be able to
populate an endoskeleton, the structural frame and network backbone of the device, and
populate it with modules, the building blocks that make up the vast majority of the of the
phone’s functionality and features. Since modules are interchangeable, a user has the
freedom to do exactly the phone they want and continue to customize the phone over time by

Department of CSE 1 KMP College of Engineering

Project Ara

replacing modules. Ara’s success is predicate on rich, vibrant and divers eco system of
modules from a myriad of developers. Users would able to select modules from an online
marketplace using a configurator that facilitates user choice and curate the configuration
process to ensure that the selection of modules provides the expected system level
functionality.

Fig 1.1: Structure of Project Ara

Ara modules can change categories throughout their usage life. For instance, a battery
module may have a built-in charging port. Such a module would serve as a power consumer
when being charged from the bus (e.g., if another module’s charging port is active), a
charging module when powered through its charging port, and a power storage device when
functioning as a regular battery.

Department of CSE 2 KMP College of Engineering

Project Ara

CHAPTER 2
PROJECT ARA AN OVERVIEWS

Developer Google

Manufacture User

Type Smartphone

Release date 2017

Introductory price Minimal cost ~US $50

Operating system Android

Power Variable

System-on-chip used Variable, Toshiba supplied for first year

CPU Variable

Memory Variable

Storage Variable

Display Variable

Graphics Variable

Sound Variable

Input Variable

Camera Variable

Connectivity Variable

Dimensions Variable
Weight Variable

Table 2.1: Project Ara Overviews

Department of CSE 3 KMP College of Engineering

Project Ara

CHAPTER 3
GENERAL HARDWARE ARCHITECTURE
Modules are the building blocks of the Ara phone. They are the hardware analogue of
software apps. These are physical components that implement various phone functions. There
are currently two major classes of modules in MDK 0.2: front modules, which make up the
front of the phone and generally provide user interaction or interface (the display, receiver,
microphone, etc.), and rear modules, which provide the bulk of the phone’s back-end (non-
user facing) functionality.

Fig 3.1: Module structure

Front modules reach across the entire width of a particular Endoskeleton frame, while
rear modules come in three standard sizes (1×1, 1×2, and 2×2) and can fit into multiple frame
sizes. The rear of the Endo is parceled into 1×1 unit squares. Each 1×1 square is
approximately 22mm.1×2 and 2×2 modules are approximately 22x44mm and 44x44mm
respectively.

Department of CSE 4 KMP College of Engineering

Project Ara

Fig 3.2: Hardware architecture

Endoskeleton (or “Endo”): Endo is the frame and backplane of the device that determines
the size and layout of the phone. Ara modules slide in and attach to the Endo’s slots, and
it has a backplane to electrically and logically connect modules together. There are currently
three Endo size variants: Mini (45x118x9.7mm), Medium (68x141x9.7mm), Jumbo (98
x164x9.7mm) with varying rib configurations for each. The MDK only details the
specification of the Endo to the extent that it is necessary for module developers to develop
modules. In the interest of maintaining the integrity of the Ara platform specification, third-
party Endo development is not permitted.

Department of CSE 5 KMP College of Engineering

Project Ara

Fig 3.3: Ara phone endoskeleton

Endo Spine and Ribs: Endo Spine is a singular vertical feature that bisects the rear of the
Endo and forms part of the module slots. Endo Ribs are horizontal features located either in
the front or the rear of the Endo and forms part of the module slots.
Top: The orientation of the primary display module determines the “top” of the Plane.
Phone Coordinate Axes(X, Y and Z): the Ara platform uses the android defined coordinate
system. The Side-to-Side direction defines the X axis. The Top-Bottom direction defines the
Y axis. The thickness direction defines the Z axis.
Interface Block: The interface block is the area on the endo and the modules where the
electrical power pins and capacitive data pads are located.
Electro-permanent magnets (EPMs): The Endo contains electro-permanent
magnets (EPMs) to attach and secure each module. The EPMs are activated upon module
insertion and deactivated by the user with an Android application.
Module shell: The module shell is a user-replaceable cover for Ara modules that can be
aesthetically customized as part of the Ara fulfilment process. With a few exceptions as noted
in the MDK, Ara modules should nominally support user serviceable module shells.

Department of CSE 6 KMP College of Engineering

Project Ara

CHAPTER 4
MODULE GEOMETRY AND ASSEMBLIES
Rear module is composed of three sub-assemblies: the module base, printed circuit
board (PCB), and shield. The module shell is not considered part of the module assembly.
To the extent that it may deviate from a standard shell geometry, it will be created in
accordance with a module developer’s geometric specifications, but will include a
consumer’s aesthetic customizations and is presently envisaged to be manufactured as part of
the fulfillment process (i.e., not by the module developer).

Fig 4.1: Rear module sub-assemblies

MDK requires the module base must be composed of a piece of machined anodized
aluminum and one or two pieces of Hiperco-50 inserts (1×1 modules have a single Hiperco-
50 insert). Hiperco-50 is an alloy with enhanced magnetic properties and thus enhanced
holding force between modules and the Endo. The inserts must mount to the sections of the
module base that correspond to the locations of electro-permanent magnets (EPMs) on the
Endo. When activated, EPMs in tandem with the Hiperco-50 inserts should provide sufficient
magnetic force to secure modules into their slots on the Endo throughout all nominal usage
scenarios. When released, EPMs provide a residual magnetic force sufficient to prevent
modules from falling out unless the user deliberately removes a module from the Endo. Users
should be able to remove modules with minimal effort when the EPM is in the release state.
EPMs require no sustained electrical power in either attach or release states and only a short
electrical pulse to transition between states.

Department of CSE 7 KMP College of Engineering

Project Ara

Fig 4.2: Prototype module base

Except for cutouts needed for external interfaces (e.g., USB connector), the external
dimensions of the module base must conform to the shape defined by the CAD model and
drawings provided in the reference materials of MDK (Module Developers Kit). This
requirement ensures the module is compatible with third-party provided module shells and
fits snugly into the Endo frame. Custom milled cavities are allowed in the inside of the
module base as long as the structural integrity of the module base is maintained and can
survive module compliance specifications.
The back of every module must have a clearly marked module label. This label must
include the Ara emblem, the name of the module developer, the name of the module, and a
module icon signifying the module function. If applicable, module labels should include
regulatory markings such as the module FCC ID and CE markings.
Figure below defines the specifications for positioning text and icons in the module
label in relation to the interface block. If a module has multiple interface blocks, the module
label must be positioned in relation to the leftmost interface block as viewed from the
direction in figure below. Module labels should be applied with a laser-etched process.

Department of CSE 8 KMP College of Engineering

Project Ara

Fig 4.3: Module label specifications

The PCBs (interface block PCB and main PCB) contain the circuitry for the module,
including circuits to enable interfaces to the Endo, as well as custom circuitry of the module.
Any non-electronic components that are part of the module (e.g., batteries, sensors) must
either mount to or be in place of the PCB. Table below provides maximum dimensions
available for rear module PCBs. PCBs smaller than these dimensions are allowed. The main
PCB must be securely mounted to the module base sufficiently to survive vibration and shock
specifications. A smaller PCB for the interface block should be soldered to bottom of the
main PCB and must conform to the shape and dimensions in the reference implementation to
fit flush with the corresponding cutout in the module base.

Table 4.1: Rear module maximum PCB dimensions

Department of CSE 9 KMP College of Engineering

Project Ara

Fig 4.4: Prototype 1×2 PCB

A shield is necessary to prevent users from making unintentional contact with
sensitive components on the PCB while changing module shells. The shield also acts as a
Faraday cage to protect modules from potential interference and ensure a uniform RF
environment for modules which are intentional RF emitters. The shield must be made of
nickel-plated steel or a functionally and aesthetically similar metal. Cutouts for components
that exceed the standard envelope are allowed (e.g., camera lens). The shield must securely
mount to the module base.

Fig 4.5: Prototype shield and clips

The envelope for a module comprises the standard dimensions for the module to
conform to the Ara Endos. While a module will ideally fit within these very specific
dimensions, modules are allowed to exceed the standard envelope in the Y (top-bottom) and
Z (thickness) directions. Modules are NOT allowed to exceed the envelope in the X (side-
side) direction. Table below provides the absolute maximum execedance limits; however,

Department of CSE 10 KMP College of Engineering

Project Ara

module developers should also use good engineering judgment to determine the stress levels
from user levied forces and torques and ensure exceedances are structured to accommodate
common usage scenarios including scenarios where the module and phone are in the user’s
pocket. Modules with dimensional exceedances must have a custom shield and ensure all
electrically active components except antennas and batteries are encapsulated within.
Whenever modules exceed the standard envelope, the execedance should conform to the Ara
design language specification.
4.1 Connected to the interface block
All modules require at least one interface block to exchange power, data, and
detect/wake signal between modules and the Endo. Some modules may also send RF signals
through the interface block to another module on the device.
The interface block hosts electrical, data, and RF connections between modules and
the Endo. The Ara platform utilizes a contactless inductive interface for high-speed data
transfer between modules and the Endo. The Network Stack section details the contactless
data transfer mechanism.
Each interface block is composed of 4 electrical connections (2 for power, 1
detect/wake, and 1 RF) and 8 data interfaces transferred by means of 4 contactless inductive
pads as shown in figure below (1×2 modules have 2 sets of electrical connections to enable
module insertion in both orientations). Details of the contactless inductive interface is
provided in the Network section. Additional details of the objective interface block design
will also be provided in a future MDK release.

Fig 4.6: Interface block

Department of CSE 11 KMP College of Engineering

Project Ara

The interface block is itself mounted and printed on a separate PCB (printed circuit
board). The interface block PCB is then soldered to the main PCB. When installed into the
module, the interface block PCB should be completely flush with the corresponding opening
in the module base. The interface block PCB must follow the geometry specified in the
module template CAD and EDA files provided in the reference implementation with in MDK
(Module Developers Kit).The interface block in the current prototype platform differs from
the objective specification. Instead of contactless data transfer with inductive pads, the
prototype uses electrical signaling between the gold-plated copper pads on the module
interface block and spring pins on the Endo for data transfer (i.e., the same method used for
power transfer). The shape of the prototype interface block pad is round to match the spring
pins on the Endo.
The prototype interface block provides 8 data pads: two bidirectional M-PHY data
lanes with 8 differential pairs (2 TX pairs and 2 RX pairs), a power pad, a ground pad, a
detect/wake pad, and an RF pad. Figure and table below detail the pin outs of the prototype
interface block.

Fig 4.7: Interface block pin out

Table 4.2: Pin out descriptions

Department of CSE 12 KMP College of Engineering

Project Ara

4.2 Attached to endoskeleton spring loaded mechanism.

Project Ara smartphone modules require Hiperco-50 insert(s) on the module base to
provide enhanced magnetic coupling with the EPMs in the Endo. Front modules also require
an additional spring loaded mechanism attached to the Hiperco-50 insert that work in tandem
with EPMs in the Endo to secure the module in place when activated.
The front module attachment spring should have a spring force constant in the order of 1
N/mm to provide optimum release force when the EPM is deactivated, while not exceeding
the ability of the EPM to pull the insert into the Endo when activated.

Fig 4.8: front-module attachment assembly

4.3 How modules communicate with each other

Project Ara utilizes the UniPro protocol for inter-module communication. The UniPro
specification is defined by the MIPI Alliance. UniPro’s design follows a layered architecture,
and specifies how communication shall occur up to the Application layer in the OSI model.
Project Ara’s architecture requires an application layer specification which can handle
dynamic device insertion and removal from the system at any time and at variable locations.
It also requires that existing modules interoperate with modules introduced at later dates.In

Department of CSE 13 KMP College of Engineering

Project Ara

addition to UniPro, Project Ara also specifies a small number of other interfaces between
modules and the endoskeleton. These include a power bus, signals which enable hot plug and
power management functions, and interface pins for modules which emit radio signals. The
Grey bus Specification also defines the behavior of the system’s software with respect to
these interfaces.
A Project Ara module is a device that slides into a physical slot on a Project Ara
endoskeleton. Each module communicates with other modules on the network via one or
more UniPro CPorts. A CPorts is a bidirectional pipe through which UniPro traffic is
exchanged. Modules send messages via CPorts; messages are datagrams with ancillary
metadata. All CPorts traffic is peer-to-peer; multicast communication is not supported.
Project Ara presently requires that exactly one application processor (AP) is present
on the system for storing user data and executing applications. The module which contains
the AP is the AP module; the Grey bus specification defines a Control Protocol to allow the
AP module to accomplish its tasks.
In order to ensure interoperability between the wide array of application processors
and hardware peripherals commonly available on mobile handsets, the Grey bus Specification
defines a suite of Device Class Connection Protocols, which allow for communication
between the various modules on the system, regardless of the particulars of the chipsets
involved.
The main functional chipsets on modules may communicate via a native UniPro
interface or via bridges, special-purpose ASICs which intermediate between these chipsets
and the UniPro network. In order to provide a transition path for chipsets without native
UniPro interfaces, the Grey bus Specification defines a variety of “bridged-phi-protocols”,
which allow module developers to expose these existing protocols to the network. In addition
to providing an “on-ramp” to the platform, this also allows the implementation of modules
which require communication that does not comply with a device class protocol.

Department of CSE 14 KMP College of Engineering

Project Ara

CHAPTER 5
ELECTRO PERMENENT MAGNETS (EPM)
The EPMs provide a low-power and user-controllable method to securely attach
modules to slots in the endoskeleton. The EPM has to selectable states: the attach state and
release state, corresponding to high and low levels of magnetic force. Electrical power is
needed to switch between two states only; the EPMs require no sustained electrical power to
maintain either state. EPMs in the attach state provide sufficient magnetic force to secure
modules into their slots on the endo throughout all nominal usage scenarios. EPMs in the
release state provide a residual magnetic force to prevent modules from falling out unless the
user deliberately removes the module from the endo. Users should be able to remove modules
with minimal effort when the EPM is in the release state.
The 1x1 and 2x2 modules each use a single EPM. 1x2 modules use two EPMs, one
each valid module insertion direction .Each EPM must provide a minimum holding force of
30 N in the attach state, and 3 N in the release state. The EPM attachment surfaces on the
endo are made from Hiperco-50 alloy to provide enhanced holding force.

Fig 5.1: Structure of EPM

Above figure shows an EPM used in prototype. The front covered face mates with the
Hiperco-50 attachment surface on the endo spine. The EPM is made from three parallel
sections. The N42SH magnets at the front are magnetized parallel to the long axis of the
device, altering magnetizing the back can have their magnetization direction from section to
section. The Alnico magnetism the back can have their magnetization direction reversed by
passing a current through the coils. When the Alnico magnets are magnetized opposite to the
N42SH magnets, the holding forces is low this is the reverse state. When the Alnico and
N42SH magnets are magnetized together, the holding force is larger this is attach state.

Department of CSE 15 KMP College of Engineering

Project Ara

CHAPTER 6
PARCELING SCHEMES
Parceling schemes are rules that determine how and where modules can be placed in
the endo frame. The front parceling scheme only has a few possible layouts, while the rear
parceling scheme can have many different configurations depending on the location of the
ribs and spine.
6.1 Rear Parceling Scheme:
The rear of the endo is parceled into 1x1 unit square. Each 1x1 square is
approximately 20mm. Note, however, that 1x2 and 2x2 modules are note exactly 20x40 and
40x40mm due to fact that the thickness of the missing rib must be accommodate for to
conform to overall grid scheme. Refer to the Computer Aided Design (CAD) models and
drawing for exact dimensions. All three endo sizes use the same rear parceling scheme.
 Endo must have exactly one vertical spine
 The medium variant spine must be at 1:2 horizontal offset from the centerline
of the device as viewed from the rear.
 The Mini and large (TBD) variant spine must be in the middle.
 For the horizontal ribs, there must be at least one rib per two units (since
modules cannot be larger than 2x2).
 Only a single cross is allowed in an endo (that is only one rib can go straight
across the spine on both sides).
The application of these design rules results in discrete set of possible endo
configurations for each size variant.
6.2 Front Parceling Schemes:
The following design rules govern the front parceling scheme.
 Vertical spine are not allowed – All modules must fill the complete horizontal width.
 A maximum of 2 ribs are allowed.
 Only a single rib is allowed in each of the upper or lower halves.
The parceling scheme for the front endo results in modules that are proportionally
sized for each endo size variant. Figure shows the valid set front endo configurations for each
size variant, labeled A through L. front modules for the large endo variant will be formalized
in a future MDK release.

Department of CSE 16 KMP College of Engineering

Project Ara

CHAPTER 7
POWER ARCHITECTURE
The Ara power architecture is designed to accommodate the unique and flexible
nature of the platform. Users of an Ara phone will be able to power their device with one or
multiple batteries; they will be able to swap a depleted battery with a fresh one, without
powering off their phone; they will be able to charge one or more batteries in their phone
from one or multiple charging devices. The design of the power architecture enables all of
these use cases and provides a flexible power platform for new applications.
Figure (7.1) shows a high-level view of the Ara power architecture. A common power
bus is central to the architecture. The power bus voltage is specified to be between 3.3 and
4.8 V. The power bus is distributed through the Endo frame to each interface block. A power
manager in the Endo optimizes power consumption, reduces current leakages, and provides
protection against over currents and over voltages. The Endo also has a small battery or
capacitor bank, and associated charge controller. The power stored in the Endo provides
power to the phone during brief periods when the battery and/or charger modules are being
hot-swapped or reconfigured and no other power source is available to keep the device on.
Ara modules fall into three categories in relation to the power architecture: power
consumers, charging modules, and power storage modules (batteries, fuel cells, etc.).
Modules can change categories throughout their usage life. For instance, a battery module
may have a built-in charging port. Such a module would serve as a power consumer when
being charged from the bus (e.g., if another module’s charging port is active), a charging
module when powered through its charging port, and a power storage device when
functioning as a regular battery. Figure below also illustrates a simplified view of these three
module types. The following subsections describe each of the types.

Fig 7.1: Power Architecture

Department of CSE 17 KMP College of Engineering

Project Ara

Power Consumer Module

At the top of the figure is a power consumer, which is the simplest in its operation.
The power consumer module draws power directly from the power bus, or more
commonly, voltage regulators step down and regulates the voltage from the bus for
various circuits within the module.
Charger Module
Charging module can supply externally derived power bus. Charging modules
may dray a small amount of current from the power bus during EPM activation and
the module enumeration process, but current flows nominally in one direction, from
the module to the bus. A traditional DC charger module is shown in the above figure.
Power Storage Module
Power storage primarily include battery modules, but other power storage devices
are envisioned. Power storage module can supply power to the rest of the system or
draw power from the bus for recharging. Battery modules supply power to the power
bus by default. Ideal diode circuit prevent current flow into a battery, and there for the
power bus voltage is equal to the highest voltage presented by any of the batteries
connected to the power bus. When charger module is connected to the system and
ready to deliver charging current to the batteries, it signals the supervisory controller
in the endo (central power management system) via Uni pro messaging. The
supervisory controller then signals battery modules to cut of power delivery to the
power delivery to the power bus and activate their charging circuits to draw power
from the busBattery modules supply power to the power bus by default. Figure below
shows a configuration in which there are multiple battery modules connected to the
power bus. Ideal diode circuits are required to prevent current Qow into a battery in
default discharge mode. The power bus voltage is equal to the highest voltage
presented by any of the batteries connected to the power bus; the battery with the
highest voltage bears the full load. The load is shared when the voltage falls to level
of the next highest battery. This trend continues until the voltage across all batteries is
equal and the load is shared evenly among them.

Department of CSE 18 KMP College of Engineering

Project Ara

Fig 7.2: Power bus with multiple battery

Fig 7.3: Battery charging

Figure shows when a charger module is connected to the system and ready to deliver
charging current to the batteries, it signals the supervisory controller in the Endo (power
manager) via UniPro messaging. The supervisory controller then signals battery modules to
cut off power delivery to the power bus and activate their charging circuits to draw power
from the bus. The supervisory controller periodically polls battery modules to report self-
diagnostics such as state of charge and uses this information in its power management power
manager can accurately determine the overall power budget of the device.

Department of CSE 19 KMP College of Engineering

Project Ara

CHAPTER 8
EXTENDED ARCHITECTURE
The envelope for a module comprises the standard dimensions for the module to
conform to the Ara endos. While a module will ideally fit within these very specific
dimensions, modules are allowed to exceed the standard envelop in the Y (top-bottom) and Z
(thickness) directions. Modules are NOT allowed to exceed the envelop in the X (side-side)
direction. The table provides the absolute maximum execedance limits, driven by the capacity
of D printer (to print the associated module shells); however, module developers should also
use good engineering judgment to determine the stress level from user levied forces and
torques and ensure execedance are structured to accommodate common usage scenarios
including scenarios where the module and phone are in the user’s pocket. Modules with
dimensional execedance must have a custom safety shield and ensure all electrically activate
components are encapsulated within.

Directions Max Dimensions Notes

X 45mm (mini),67.02mm Modules are NOT allowed
(Medium), 21.82mm to exceed the standard
(1x1,1x2), envelope in the X direction.
44.82mm(1x2,2x2)
Y 20cm Overall module height must
not exceed this figure.
Z 2.5cm Overall module thickness
must not exceed this figure.

Table 8.1: Module Direction and its limits

Exceedances may be appropriate and necessary for some applications as demonstrate
in Pulse Oxiometer Module, which measures blood oxygen saturation. The execedance in the
Y dimension provides a convenient affordance and sensor location for a user’s finger. The
prototype of a Thermal Image Module. The execedance in the Z dimension enables modules
to accommodate components with high thickness requirements such as a camera lens unit.

Department of CSE 20 KMP College of Engineering

Project Ara

CHAPTER 9
SOFTWARE ARCHITECTURE
The present prototype platform software is a modified version of the Liner 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, Wi-Fi/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 Grey bus Operations. The Bridged PHY Protocol Drivers in the Grey bus subsystem
implement their respective protocols’ Operations and interface with existing kernel APIs to
enable end-to-end communication between Android applications and module devices.

Fig 9.1: Prototype software stack

Kernel
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
hot pluggable. The primary requirement to enable Ara features in the kernel is the

Department of CSE 21 KMP College of Engineering

Project Ara

implementation of the Grey bus specification, which defines how modules communicate over
the UniPro network on an Ara device. The Grey bus 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.
Figure 9.2 depicts an abstracted view of a reference implementation of the Grey bus
specification as a kernel subsystem and its interfaces to other kernel components. The Grey
bus kernel reference implementation is available as a kernel module, which can compiled
against a source tree targeted for various APs. The Grey bus 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 9.2, the Grey bus kernel module is designed around a central Grey
bus Core. The key functions of the Grey bus 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 Grey bus 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 Grey bus 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 Grey bus specification and implemented in the Grey bus subsystem. The set
of generic class drivers will span a broad range of module devices typically found on
smartphones. The current plan includes then following device classes: audio, batteries and
chargers, Bluetooth devices, cameras, consumer IR devices, displays, GPS, input devices,
lights, NFC, sensors, vibrators, Wi-Fi, baseband, and other network devices, and storage
devices. Future versions of the MDK and Grey bus specification will include details for each
device class.

Department of CSE 22 KMP College of Engineering

Project Ara

As of the current MDK release, the Grey bus 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, Wi-Fi), 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 Grey bus
specifications. 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 Grey bus 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 Grey bus
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.

Fig 9.2: Kernel Subsystem Interfaces

Android
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

Department of CSE 23 KMP College of Engineering

Project Ara

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 hot plug 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 hot plug notification and
Endo information (i.e.geometry, orientation) to various module developer-supplied
Applications, support EPM control, and control module power modes.

Fig 9.3: Ara Android Stack

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

Department of CSE 24 KMP College of Engineering

Project Ara

and the various device driver interfaces exposed by the kernel for different hardware
peripherals those services must control.
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 hot plugging 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 Wi-Fi).
HALs will also detect any change in module availability and notify dependent services upon
module insertion and device availability.
Project Ara 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 hot plugged, support for Grey bus, 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.
The prototype Android release includes existing HALs, yet to be modified to support
hot plugging and dynamic hardware reconfiguration. Additionally, the prototype Display and
Camera Modules also require device-specific HALs targeted for each AP.
As shown in Figure 9.2 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 hot plugging 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 call back interfaces to Android applications. These
interfaces will be specified in a future MDK release.

Department of CSE 25 KMP College of Engineering

Project Ara

CHAPTER 10
SYSTEM LEVEL FUNCTIONS
The following are the system level functions performed by Ara modules. Modules
will utilize the network and software stacks to exercise these functions.
Module Detect:
A feature of the Ara platform is that batteries and power buttons can be distributed
among the module. The detect signals are used to communicate to a signals are used to
communicate to a module and the endo when a module is inserted or removed. An Ara phone
can be power itself on and off by pressing buttons on a module. The wake signals are used to
bring the phone out of a low-power stand by state. The WAKE_TX signal is sent from a
module to the supervisory controller when the power button is pressed. This brings the
supervisory controller out of stand by state, and the supervisory controller, in turn sends
WAKE_RX signals to each of the installed modules to turn them on.
Enumeration:
Enumeration allows the phone to identify and determine the capability of a module
when it is plugged into the endo. For example Display Module will provide its
vendor/manufacture, device class indicating the type of device driver it needs, screen
resolution, and other performance identifier needed to operate the module. When a module
insertion event occurs, the UniPro switch on the endo signals an interrupt to the supervisory
controller
EPM Control:
EPM control addresses how EPM (s) in the module are switched between attach and
release states. These actions are triggered by the user with an application interface. The
application will graphically show the current state of the modules and module slots in the
phone including whether a module is present in the slot, the name identifier of a module, and
the state of the module’s EPM (s) (attach/release). The user may then toggle the state of the
EPM by touching on a specific module.
Active Thermal Management:
Active thermal management features protect the user and the phone from excessive
heat buildup. Temperature sensors in the endo and the module provide measurements to the
supervisory controller. If temperatures exceed the limits, modules my receive warnings, and
in the worst case, power will be removed. Active thermal management is not implemented in
the prototype platform.

Department of CSE 26 KMP College of Engineering

Project Ara

CHAPTER 11
ADVANTAGES
1. Price
The basic Project Ara phone is going to cost less than $50 to manufacture making it
accessible to almost every one.
2. Cheaper repairs
If a screen breaks, you just replace that. The same will be true with any module.
Hopefully there will be some sort of diagnostic built in so whatever breaks, you can swap the
part out.
3. Customization
You only need to add in what you need so you need to pay only for what you want.
4. Increased life
You just upgrade as you require or as parts break so you never need to buy a whole
new phone. This will also result in less waste.
5. Battery
By having two or more battery’s, phone last longer and being able to how swap
modules should mean that you can keep your phone going as long as you need.
6. Support specialization
You may have specialized modules that you only swap in when you need them.
DISADVANTAGES
1. Size of the phone
In the early days Project Ara phone is not going to be as slim as a traditional phone.
Height and width will not be an issue, because people want big phones but thickness could be
a problem.
2. Testing issues
Expect more bugs with an Ara phone. Even with only a handful of modules, there will
be a huge number of combinations and it will be almost impossible to test them all. With
open module development environment, there will be Ara module from a huge number of
suppliers which can’t all be tested together.
3. Design issues
Due to the modular architecture, Project Ara is can’t offer attractive designs which is
offered by todays smart phone.

Department of CSE 27 KMP College of Engineering

Project Ara

CHAPTER 12
CONCLUSIONS

 One field that is benefiting from this project is 3D printing

 Specialized technology (UniPro and M-PHY) has made the development of this
device efficient.
 Technology used in Project Ara can be re-used in other items
 Modular market might not settle so quickly
 With the prototypes receive in the market, new companies or individuals might get
interested in the development of modules.
 The success is tightly connected to the variety of modules and brands that the user
might be able to acquire
 The platform that allows the user to manage all its module should be intuitive enough
for new smartphone users.

Department of CSE 28 KMP College of Engineering

Project Ara

REFERENCES

 PHONEBLOKS. Phonebloks, a phone worth keeping.2014.http://Phonebloks.com/en

 http://www.cnet.com/news/report-google-acquires-modus-mobilepatents/
 THUNDERCLAP.INC.Thundeclap.2012 https://www.thunderclap.it/en
 MCCRACKEN,Harry.Project Ara :Inside Google’s Bold Gambit to Make
Smartphones Modular.http//time.com/10115/google-project-aramodular-smartphone/
 REISINGER, Don. Report: Google acquires Modu's mobile patents. 20/05/2011.
http://www.cnet. com/news/report-google-acquires-modus-mobile patents/
 THUNDERCLAP.INC. Thunderclap.https://www. thunderclap.it/en MCCRACKEN,
Harry. Project Ara: Inside Google’s Bold Gambit to Make Smartphones Modular.
 Google ATAP project Ara Developer/http://www.youtube.com/watch?v=cP8yzJhe-
BA
 MIPI ALLIANCE, UniPro (SM) Specifications .http://mipi.org/specifications/UniPro-
specifications.
 BLOCKS Choose blocks. http://www.chooseblocks.com/
 CHAN,Norman.Tested Explains: How Google’s Project Ara Smartphone works.
http://www.tested.com/tech/smartphones/460765-tested-explains-how googles-
project-ara-smartphone-works/
 htt4p://www.hizook.com/blog/2010/12/07/electropermenentmagnets-programmable-
magnets-zero -sts=atic-powerconsumption-enables-s.

Department of CSE 29 KMP College of Engineering