With over 2 billion devices running Android, it is one of the most used operating systems on the planet. Android development follows software product lines approach and so is used in multiple business contexts. As Android supports devices of different form factors and hardware capabilities, OEMs resorted to extending the operating system and its APIs to provide capabilities or feature differentiation beyond stock Android. A continuously changing Android architecture meant the OEM changes were getting obsolete causing fragmentation in the Android mobile ecosystem. While the Android app developer ecosystem was insulated from such fragmentation, the Android systems developer was not.
This blog looks at android architecture’s maturation and recovery from an android systems development point of view. It aims to highlight potential issues for a wider adoption to newer ecosystems. Android architecture evolution has lessons for systems developers in other ecosystems who may not be used to the ways of working with Android Open Source Project.
Role of architecture in solving fragmentation
Architecture is often not perceivable to end customers. However if software is continuously refactored within a short period of time the system developer’s knowledge of the system and its architecture is challenged.
Conway’s law states that design reflects the structure of the organization that produced it. A holistic android device design has 3 stakeholders namely Google, SoC vendor, OEMs.
Design Reflections
- Can android fragmentation be controlled as newer ecosystems adopt android?
- How should OEMs differentiate and innovate while also keeping pace with android architecture?
- Are project treble and mainline the answers? There are several new projects planned with a wider outreach from Google. Project Marble, Adiantum, Apex, Android Jetpack, etc.
Architectural Underpinnings
Android is tiered into different layers from top to bottom like Lego blocks.
The Android Software stack (AOSP) is composed of the linux kernel and hardware abstraction, native libraries, the android runtime, the framework layer and applications on top.
Sources of Fragmentation
Around 2016, the device distribution dashboard gave a sense of how fragmentation had impacted Android. OEMs had slowed down in releasing updates. Android releases every six months complicated matters as OEMs were unsure which version to target.
The sources of fragmentation were many and spanned across hardware and software namely,
- Forked SoC specific vendor kernels
- Infrequent platform and security updates
- Applications for particular android versions
- Be-spoke OEM AOSP changes, user-space customization (services and daemons)
- Native code added from OEMs
The Upgrade Dilemma
Statistics showed most users were stuck on older versions of android and fewer users on newer versions of android releases. The sources of fragmentation had led OEMs to a software upgrade conundrum. Upgrades meant re-design and testing of the software took upto six months, rendering the update redundant as the next android version would be available and competing.
Google tried to understand and solve the fragmentation by talking to its silicon partners and OEMs. Project Treble was introduced in Android 8.0.
Defragmenting Android via Treble
Android architectural shortcomings were addressed with below goals
- Ensure app developer is agnostic to the changes and benefits implicitly.
- Decouple dependent changes allowing independent updates.
- Address OEM customization hazards.
- Ensure newer silicon revisions are able to upgrade to Android quickly and get the same level of support as available to the Linux kernel community.
Project Treble tried to address fragmentation by looking at the software stack with an intention to resolve the dependencies. Treble tried to partition the entire system into independent entities.
Treble achieved this by formalizing the dependencies between the different components provided by android (system) and the ones provided by the OEMs (vendor).
1. Inter process communication (IPC): Binder is the inter process communication mechanism in android. Treble introduced three types of Binder domains for separating communication and hardening security: apps and framework use the traditional Binder, new vendor Binder domain for vendor components, new hardware Binder for platform and vendor components. All other forms of IPC were disallowed ensuring better security sandboxing.
2. Hardware Abstraction Layer (HAL) interface & versioning: As the hardware capabilities improved in newer SoCs, the android framework needed a way to understand the changed capabilities down below the HAL. A Hardware Interface Description Language (HIDL) was introduced. (a more stable version of the Android Interface Definition Language replaces HIDL in Android 11)
3. Vendor Interface (VINTF): OEMs have used the native development kit for achieving higher performance for certain use-cases. Thus, android was modified by OEMs in a way which induced cyclic dependencies. A clear vendor Interface introduced separation and reduced dependence of the system image on the vendor image. This fixed the application binary interface incompatibility issues.
4. Linux kernel: The kernel is traditionally provided by the SoC vendor. Treble mandated the latest Long Term Stable (LTS) kernel for device release. The LTS kernels are also supported for six years enhancing the device lifetime support. Common Kernel: Traditionally, the Android Kernel was made up of some components added to the Linux Kernel (wakelocks, Binder, etc.). Now there is an effort to use the mainstream LTS kernel and slowly either drop or upstream the Android parts so that the fragmentation of the kernel used is reduced.
5. One Update per year cadence: The discontinuing Maintenance releases ensured the OEMs did not end up in a continuous cycle of adapting to new code.
6. System & Vendor code separation: Google owned code will be checked by the compliance test suite (CTS). A generic system image is introduced allowing OEMs to check for compatibility issues prior to release. Non-Google code is checked by the vendor test suite (VTS).
7. Upstreaming efforts: Google will push more code in the publicly available AOSP.
8. API deprecation & refactoring: Redundant APIs are deprecated and support is dropped after a pre announced schedule.
Mobile Ecosystem: Android can be configured by carriers and OEMs to provide differentiation which avoids fragmentation. However, Android also supports other device ecosystems and hence needs to support other ecosystem demands and requirements with a defragmentation lens.
Diverse Ecosystem Challenges
Android is entering ecosystems which have challenges hitherto unseen by a mobile centric android architecture. Android continues to be adopted for wearables, television, IoT, enterprise computing. They each have their own diverse domain requirements. For instance, flash memory life in an automobile is typically ten years unlike mobiles. Automobiles get fewer in-field updates and so software updates have to work 100% to ensure driver safety.
Driver safety, storage management, energy management and faster boot times for meeting rear view camera regulatory requirements are some of the must-have designs for Android infotainment.
In automotive and industrial control domains, the functional requirements demand high performance embedded systems (RTOS) coupled with general-purpose operating systems (android). Such mixed-criticality systems bring forth requirements of security, safety and resource sharing which have not been seen in the mobile industry.
Virtualization and Containerization have emerged as solutions to the challenge of consolidating and integrating such hybrid systems architectures. Logical isolation and separation for security and safety of mixed-criticality systems is being investigated by the android team. A clear partitioning is necessary to avoid performance issues and guarantee deterministic software behaviour.
Timely policy or guidelines for using virtualization with Android will ensure OEMs will avoid bespoke architectures which might give rise to fragmentation. It could well be Google policy to give freedom to OEMs, however the aspects of performance and security needs to be addressed via the compatibility definition document where possible.
Wrapping up
Effective policy and software customization guidelines from Google are crucial to avoid bespoke architectures and fragmentation, ensuring Android device makers thrive while trying to catch up with an evolving architecture. Android team’s capabilities to adopt software product lines and partnering with a broader ecosystem beyond mobile will help device makers to manage complexity and easily adopt Android.
Call to Action
Android fragmentation is now mostly a solved problem by the android team, however the good work done in re-architecting the android platform will be lost unless OEMs and android systems developers adopt a non-intrusive approach to AOSP development as much as possible.
About the Author: Prasanna Harpanhalli has been with android since 2010 as a systems architect (Ericsson, Sony Mobile) and currently works in automotive infotainment as an android IVI systems architect.
Disclaimer: These posts are written by individual contributors to share their thoughts on the Computer Architecture Today blog for the benefit of the community. Any views or opinions represented in this blog are personal, belong solely to the blog author and do not represent those of ACM SIGARCH or its parent organization, ACM.
