Android’s open source nature as an OS leads to OEMs customizing the Android stack introducing various features and attractive themes, to differentiate themselves in the market. This holds true especially for their mid-segment and premium-segment devices. When Google releases their latest version of the Android OS, OEMs must transfer/port all these customizations onto this new version to release their products with the current Android Version. It takes time and is extremely costly to modify the Android stacks, stabilize them, and procure the necessary Google certifications. Therefore, OEMs tend to delay the upgrades. The end result is the presence of differing versions of the Android OS, ultimately leading to fragmentation. The OEMs will continue to customize and introduce new features and attractive themes in their flagship devices.

The main problem that developers face due to fragmentation is interoperability issues and the effort they have to take maintaining their applications on multiple versions of Android. When it comes to end users, their devices will not be secure if critical security and privacy updates in the latest versions are not provided. Google is trying to address these issues in various ways to ensure the security of their Android devices. One such initiative is Project Mainline. Through this project, the system core modules (mainline modules) are updated frequently, in place of the traditional full system updates provided OTA.

Project Mainline helps push the important code changes to internal system modules directly from the Google Play Store, as shown in the diagram below. In other words, each compatible component will get upgraded like any other application independently. These updates will be downloaded from Google Play Store, and installed after a rebooting of the device. This is also referred to as Google Play System Updates (GPSU). However, there may be other components in the Android framework and middleware that cannot be pushed from Google Play, due to OEM customizations.

Objectives of Project Mainline

Project Mainline addresses the following issues Android end users face by providing updates periodically on their devices:

• Security
  • Accelerates updates and removes OEM dependencies for critical security bugs
  • Modules involved are media codecs, media framework components, DNS Resolver, Conscrypt, StatsD (for safety)
• Privacy
  • This method ensures better protection of users’ data
  • The relevant modules here are Documents UI, Permission Controller, ExtServices, Media Provider
• Consistency
  • Frequent updates ensures device stability and compatibility
  • Necessary modules here are time zone data, ANGLE (developers opt-in), module metadata, networking components, captive portal login, tethering neural network, API ANGLE, cellular broadcasts, Android Debug Bridge Daemon (adbd), IKE

Google is increasing the presence of these mainline modules with each new release of Android. ART/Libcore, Bionic (Runtime), Job Scheduler, Bluetooth, and UI Rendering (SKIA/HWUI) are being planned for 12.

How it Works

The mainline components are bundled as either APEX (Android Pony Express) or APK files; APEX is new file format similar to APK. As the mainline modules are low level system components which do not follow the standard application lifecycle, they need to be available before system servers start. This is unlike APKs which are started by the PackageManagerService.

The Settings application will have an option to trigger the mainline module updates. This option will be available parallel to the OTA upgrade options for system updates.

The release workflow of mainline updates is as follows:

Module Qualification: Each module is well tested independently and is required to pass all the identified tests, before it can move on to the Training stage

Train Qualification: Multiple modules are integrated and tested with integration testing and exhaustive OEM testing carried out in this phase. Google carries out testing on Pixel devices in their GPSU Labs

Partner Testing: Google shares the release modules after the training stages to their respective partners for exhaustive OEM testing

If the update through mainline modules fails, there is a rollback mechanism present in Android. The rollback scenarios in case of failures are developed in two ways:

1. Locally on the device
2. Through the Cloud for Google Play

Rollbacks happen locally, when the update results in crash loops, system server reboots, or a failure to update i.e. Death on Arrival (DOA)

Google Play rollbacks are triggered when a user experiences severe degradation after the update. This degradation may be in the battery, memory capabilities or when an application tries to start up.

Sasken has over a decade of comprehensive expertise in the Android ecosystem towards solving these issues. We have successfully ensured seamless Android upgrades meeting Google’s certification qualifications, for various global OEMs and continue to do so.

Find out more about our expertise in Android across multiple industries here.