One of the biggest changes in Android in recent years that flew under the radar, relatively speaking against its importance, was the introduction of Project Mainline in Android 10. Google mandates the inclusion of specific Mainline modules across Android releases, with Android 11 coming in with a combined compulsory total of 25 Mainline modules. Here is an explanation on what Project Mainline is and what it aims to solve, alongside a list of all of Android’s Project Mainline modules.
What is Project Mainline?
To properly understand Project Mainline, we will have to rewind a bit. If you go back a few years, a lot of the conversation around Android updates centered around the fragmentation problem. Fragmentation was one of the biggest challenges for Google to solve on Android around the Ice Cream Sandwich – Lollipop era. Even though Android as a platform received regular updates across a largely-predictable pattern, these updates used to take a very long time to reach the hands of final consumers, if at all. So while Google was fixing critical bugs and security issues at the platform level, the actual rollout of these changes left a lot to be desired. There were/are a lot of middlemen (SoC vendor, OEMs, carriers, etc.) and a lot of moving parts involved in delivering updates to your phone, and the fragmentation problem did not appear like it would solve itself without requiring some hard-hitting interventions.
One of the major efforts to address this problem came in the form of Project Treble alongside Android 8.0 Oreo, which involved a major rearchitecting of Android, separating the Android OS framework components from the vendor HALs and Linux kernel. Project Treble, in essence, modularized Android by separating the OS framework from the device-specific, lower-level software. This way, device makers (OEMs) need not wait for silicon manufacturers (SoC vendor) to update their vendor implementation code, and OEMs could update the Android OS framework independently. The end result is faster adoption of newer Android releases from the OEM, as they no longer need to wait around for the middleman (SoC vendor) to finish its job first before they can begin doing theirs.
While the Android update situation did not dramatically improve right off the bat with Project Treble, it did largely enable broader OEM participation in Android 10 and Android 11 betas as well as making it easier for OEMs to update more of their devices on a quicker timeline. Plus, the entire concept of the GSI (Generic System Image) has had a major impact on aftermarket development on our forums.
Developer boots Android 11 on 22 older devices with a Project Treble GSI
Project Mainline extends the efforts of Project Treble. While Treble reduced how dependent OEMs were on SoC vendors for every single OS update, Mainline reduces how dependent Google is on OEMs for delivering security updates to key OS components. Project Mainline extends the Treble philosophy to more critical parts of the Android framework, removing OEMs as the dependent middlemen from this equation. The purpose of Project Mainline is for Google to wrest control of framework components and system applications that are critical to security and maintaining development consistency away from OEMs. Project Mainline is rightfully referred to as the biggest change to Android since Project Treble.
For Project Mainline, Google makes use of Mainline modules which are delivered through the Google Play Services framework and the Google Play Store. Each Mainline module is delivered as either an APK file, an APEX file, or as an APK-in-APEX. When a Mainline module is being updated, the user sees a “Google Play System Update” (GPSU) notification on their device. Effectively, to deliver updates to critical components, Google has bypassed the need to wait for an OEM to roll out an update, choosing to do the task itself.
As Google states on the Android website:
Modular system components enable Google and Android partners to distribute updates broadly, quickly, and seamlessly to end-user devices in a non-intrusive manner. For example, the combination of media codec fragmentation and critical bugs can dramatically slow app adoption and user engagement. Frequent updates to media-related modules can reduce codec fragmentation to make media app behavior more consistent across different Android devices and fix critical bugs to build user trust.
Android 10 or higher converts selected system components into modules, some of which use the APEX container format (introduced in Android 10) and some of which use the APK format. The modular architecture enables system components to be updated with critical bug fixes and other improvements as needed, without affecting lower-level vendor implementations or higher-level apps and services.
Project Mainline, AKA “Google Play System Updates,” was introduced in Android 10 as a major effort to make core system components of Android more modular and updatable. Mainline introduced a new “APEX” filetype specifically for system components, with the goal of shipping core Android code through the Play Store as easily as you ship an app update. Previously, Android’s only shippable code block was the APK, a filetype originally designed for third-party apps. This came with all sorts of security restrictions and could only start up late in the boot-up process, so APEX was created with more powerful system components in mind. APEXes can only be created by Google or your device manufacturer, so they can be noticeably more powerful and house critical boot-up components like the app runtime.
Mainline isn’t just a technical solution, it’s also about making more parts of Android centrally distributed by Google, which involves negotiating with device manufacturers and getting them to all agree to ship the same block of code. Mainline modules eventually become mandatory to ship, so Mainline is actually a big collaboration with device manufacturers to make sure a single ecosystem-wide module meets everyone’s needs. Not every Mainline module is an ultra-powerful APEX module—some are just APKs that are now Google-distributed Android code.
Project Mainline — Modules
With Android 10, Google mandated the inclusion of 13 specific Mainline modules. With Android 11, the total number of mandatory modules is 25. Here is the full list, alongside some key details:
| Module Name | Package Name | Type | Device Upgraded to or Launched with Android 11 |
Device Launched with Android 10 |
Device Upgraded to Android 10 |
|---|---|---|---|---|---|
| adbd | com.google.android.adbd | APEX | Must | Unsupported | Unsupported |
| Android Neural Network API Runtime | com.google.android.neuralnetworks | APEX | Must | Unsupported | Unsupported |
| Captive Portal Login | com.google.android.captiveportallogin | APK | Must | Strongly Recommended | Optional |
| Cell Broadcast | com.google.android.cellbroadcast | APEX | Must | Unsupported | Unsupported |
| Conscrypt | com.google.android.conscrypt | APEX | Must | Strongly Recommended | Optional |
| DNS Resolver | com.google.android.resolv | APEX | Must | Strongly Recommended | Optional |
| Documents UI | com.google.android.documentsui | APK | Must | Must | Optional |
| ExtServices – APK | com.google.android.ext.services | APK | Must | Must | Must |
| ExtServices – APEX | com.google.android.extservices | APEX | Must | Unsupported | Unsupported |
| IPsec/IKEv2 Library | com.google.android.ipsec | APEX | Must | Unsupported | Unsupported |
| Media Codecs | com.google.android.media.swcodec | APEX | Must | Must | Optional |
| Media Framework Components | com.google.android.media | APEX | Must | Must | Optional |
| Media Provider | com.google.android.mediaprovider | APEX | Must | Unsupported | Unsupported |
| Module Metadata | com.google.android.modulemetadata | APK | Must | Must | Must |
| Network Stack Components | com.google.android.networkstack | APK | Must | Strongly Recommended | Optional |
| Network Stack Permission Configuration | com.google.android.networkstack.permissionconfig | APK | Must | Strongly Recommended | Optional |
| Permission Controller – APK | com.google.android.permissioncontroller | APK | Must | Must | Must |
| Permission Controller – APEX | com.google.android.permission | APEX | Must | Unsupported | Unsupported |
| SDK Extensions | com.google.android.sdkext | APEX | Must | Unsupported | Unsupported |
| Statsd | com.google.android.os.statsd | APEX | Must | Unsupported | Unsupported |
| Telemetry Train Version Package | com.google.mainline.telemetry | APK | Must | Unsupported | Unsupported |
| Tethering | com.google.android.tethering | APEX | Must | Unsupported | Unsupported |
| Time Zone Data | com.google.android.tzdata | APEX | Must NOT | Must | Optional |
| Time Zone Data 2 | com.google.android.tzdata2 | APEX | Must | Unsupported | Unsupported |
| Wi-Fi³ | com.google.android.wifi | APEX | Must | Unsupported | Unsupported |
To provide some context to the columns above, the column titled “Device Upgraded to or Launched with Android 11” includes details on whether the module must be present (or must not be present, in case of Time Zone data because of the inclusion of its alternative) on all devices that have either been upgraded to Android 11, or are launching with Android 11 out of the box. Similarly, devices launching with Android 10 are required to include a few modules, are strongly recommended to include a few others, and are unsupported by the rest. For devices that are upgraded to Android 10 (as opposed to launched with Android), the list of required modules is shorter.
What does each Mainline module do?
Here’s a brief explanation for each of the Mainline modules:
Adbd
The adbd module manages command-line adb and IDE debugging sessions. Modularizing adbd allows Google to deliver performance improvements and bug fixes quicker. This is crucial as some bugs in the past were related to battery drain, and could cause devices to continue using 100% CPU until the phone dies. So getting these fixes out is crucial for Google as adb is widely used by app developers and OEMs for testing.
Android Neural Networks API Runtime
This is a library that sits between an app and backend drivers. The API in turn is an Android C API for running computationally intensive machine learning operations on mobile devices, and to enable hardware-accelerated inference operations.
CellBroadcast
Cell Broadcast refers to emergency and non-emergency alerts (such as AMBER alerts). This module is concerned with tasks around these alerts, and with other ancillary functions such as SMS decoding and geofencing for wireless emergency alerts.
Conscrypt
The Conscrypt module handles Android’s TLS implementation and other cryptographic functions such as key generators, cipers, and message digests. Shipping this is as a module allows Google to accelerate security improvements, without needing to rely on OTA updates.
DNS Resolver
As the name implies, the DNS resolver resolves DNS, i.e. it converts human-readable URLs into IP addresses. The module contains the code that implements the DNS stub resolver, and shipping this as a module lets Google provide better user protection against DNS interception and configuration update attacks.
Documents UI
Documents UI is the module responsible for controlling access to specific files for components that handle document permissions. As Google states, making storage access and permissions into a module increases privacy and security for end users, while the runtime resource overlay (RRO) feature allows OEMs to theme the experience (referring to the Files app) if they need to. As a module, all Google-Android devices will ship with the same Documents UI experience.
ExtServices
This module includes framework components for core OS functionality such as notification ranking, autofill text-matching strategies, storage cache, package watchdog, and other services.
IPsec/IKEv2 Library
This library module concerns itself with new and existing features around Interworking Wireless LAN (IWLAN) and VPNs, such as negotiating security parameters like keys, algorithms, and tunnel configurations. The idea with modularizing these functions is to promote ecosystem consistency and provide a way to deliver quick fixes for security and interoperability issues.
Media, Media Codecs, Media Provider
These are three bifurcated modules, but they have functions that are reliant on each other. These media modules handle media types and codes, interact with the ExoPlayer, expose transport controls and playback information to the framework, optimize indexed metadata, etc. Remember Stagefright, the exploit that changed Android and brought about the very concept of monthly security updates to the platform? That exploit relied on vulnerabilities within the media playback library. So a modularization of the media components allows Google to react quickly and widely in case security bugs are found in this often targetted component.
Module Metadata
The function of this module is immediately clear from its name, although its purpose isn’t. Module Metadata module contains….metadata about the list of modules on the device. And that’s about it.
Network Stack Components, Network Stack Permission Configuration, Captive Portal Login
The Network Stack Components module provides common IP services, network connectivity monitoring, captive login portal detection. The Permission Configuration module defines the permission that enables other modules to perform network-related tasks. The Captive Portal Login module deals with Captive Portals — web pages that are displayed when connected to certain public Wi-Fi networks, where the user is asked to enter details to gain Internet access.
Permission Controller
This module delivers updatable privacy policies and UI elements around granting and managing permissions. If this sounds familiar to what Package Installer does, that is because it is. Functions like runtime permissions granting, management, and usage tracking were part of the Package Installer app up till Android 9. In Android 10, the Package Installer app is split into sections to enable the permissions logic to be updated. The Permission Controller module is delivered as an APK file, and in Android 11, the module can automatically revoke runtime permissions for apps that haven’t been used for an extended period of time.
SDK Extensions
This module is a little difficult to understand and consequently explain. Every Android release is assigned an SDK level (usually +1 from its predecessor). When an app targets a particular SDK, it is assumed that the developer has taken into account the platform behavioral and API changes that the Android release has brought along.
SDK Extensions module decides the “extension SDK” level of the device and exposes APIs for apps to query the extension SDK level. That’s about all that the official documentation mentions. ArsTechnica, though, mentions that this is likely a secondary API layer that will be shipped through the Play Store.
Statsd, Telemetry Train Version Package
Statsd is responsible for collecting device metrics. The Telemetry Train Version Package, on the other hand, does not contain active code or any functionality of its own. It simply contains a version number for the “Telemetry Train” which Google says is a set of metrics-related modules. Based on the version number, Google Play displays the security patch version to end users and figures out if updates are available for metric-related modules.
Tethering
The Tethering module shares the device’s Internet connection with other connected client devices through Wi-Fi, USB, Bluetooth, or Ethernet. The module includes the tethering components and their dependencies. By using this Tethering module, OEMs can rely on a single, standard reference implementation and bring a consistent experience across devices.
Time Zone Data
The Time Zone Data module updates daylight saving time (DST) and time zones on Android devices, standardizing both the data (which can and does change rather frequently in response to religious, political, and geopolitical reasons) and the update mechanism across the ecosystem. Android 8.1 and Android 9 used an APK-based time zone data update mechanism, and Android 10 replaces it with an APEX-based module update mechanism. Google states that AOSP continues to include the platform code necessary for APK-based updates, so devices upgrading to Android 10 can still receive partner-provided time zone data updates through the APK. However, Google does warn that APK-based updates supersedes an APEX-based update.
Wi-Fi
This is the module for Wi-Fi functionality. End users can now get a consistent Wi-Fi experience across Android devices, as well as fixes to interoperability issues through module updates, app developers can get reduced platform fragmentation, and OEMs can fulfill carrier requirements while also reducing costs for individual customizations.
Hopefully, this article highlights just how important Project Mainline is to Google’s Android ecosystem.
The post Everything you need to know about Android’s Project Mainline appeared first on xda-developers.
from xda-developers https://ift.tt/3nDxbta
via IFTTT
Aucun commentaire:
Enregistrer un commentaire