Project Mainline in Android 10
Yesterday, the next OS update for mobile devices from Google was released. One of the main innovations of Android 10 was the "Project Mainline". I'll try to figure out what it is, why, and how it works.
For years, Google has been trying to solve the problem of security updates on Android. Android is currently installed on several billion devices, but most manufacturers are very reluctant to support devices after release. This leads to the fact that there are many devices in operation on which a version with known vulnerabilities is installed.
The first big step to simplify updating Android was “Project Treble”, which “divided” Android into two parts: hardware-dependent and independent. Which facilitated the release of updates to new versions of Android. The next big step was Project Mainline. It allows you to update individual components of the operating system without updating the entire system, similar to updating applications.
In Android architecture, the operating system (often referred to as firmware) is tightly separated from user data and applications. It is located on a separate section of flash memory, is read-only and in the latest versions of Android is digitally signed for integrity control. For Android applications that are part of the operating system, an update is possible with the placement of new versions of applications in the user’s memory section. Updating other parts of the operating system (services, libraries, etc.), for example using the package manager, as on Linux distributions, was impossible. For such corrections, the manufacturer was forced to release an update of the entire system. At the same time, when using Google Mobile Services (the vast majority of devices use them), each update requires certification by Google. And “Project Mainline” solves this problem, now the system components can be updated individually, similar to Android applications. In addition to security updates, it also simplifies updating system settings and data, such as time zones (tzdata).
The core of Project Mainline is the new container for APEX system applications (short for Android Pony EXpress).
In Android 10, Google identified 13 APEX packages in the system that can be updated independently:
APEX packages can be installed similarly to APKs using the "package installer", adb or Google Play.
The APEX file is similar to that used for Andoird APK applications.
APEX is a zip archive containing 4 main files:
The APEX manager system service (apexd) works with APEX packages.
Inside an image from an APEX package, there may be:
APEX packet is signed twice, with two different keys. The ext4 image is signed with one key (dm-verity is used, as in the Android Verified boot), the APEX package (zip file) is signed with the second key, similar to the APK package.
APEX uses a number of Linux kernel mechanisms, such as a loop device, DM-verity.
APEX is supported on the kernel version 4.4 and higher. For devices on older versions of the kernel, only work in "flat" mode that does not support updating is supported.
References:
android.googlesource.com/platform/system/apex/+/refs/heads/master/docs/README.md
android-developers.googleblog.com/2019/05/fresher-os-with-projects-treble-and-mainline.html
For years, Google has been trying to solve the problem of security updates on Android. Android is currently installed on several billion devices, but most manufacturers are very reluctant to support devices after release. This leads to the fact that there are many devices in operation on which a version with known vulnerabilities is installed.
The first big step to simplify updating Android was “Project Treble”, which “divided” Android into two parts: hardware-dependent and independent. Which facilitated the release of updates to new versions of Android. The next big step was Project Mainline. It allows you to update individual components of the operating system without updating the entire system, similar to updating applications.
Why is this needed?
In Android architecture, the operating system (often referred to as firmware) is tightly separated from user data and applications. It is located on a separate section of flash memory, is read-only and in the latest versions of Android is digitally signed for integrity control. For Android applications that are part of the operating system, an update is possible with the placement of new versions of applications in the user’s memory section. Updating other parts of the operating system (services, libraries, etc.), for example using the package manager, as on Linux distributions, was impossible. For such corrections, the manufacturer was forced to release an update of the entire system. At the same time, when using Google Mobile Services (the vast majority of devices use them), each update requires certification by Google. And “Project Mainline” solves this problem, now the system components can be updated individually, similar to Android applications. In addition to security updates, it also simplifies updating system settings and data, such as time zones (tzdata).
How it works
The core of Project Mainline is the new container for APEX system applications (short for Android Pony EXpress).
In Android 10, Google identified 13 APEX packages in the system that can be updated independently:
- Security: Media Codecs, Media Framework Components, DNS Resolver, Conscrypt
- Privacy: Documents UI, Permission Controller, ExtServices
- Consistency: Timezone data, ANGLE (developers opt-in), Module Metadata, Networking components, Captive Portal Login, Network Permission Configuration
APEX packages can be installed similarly to APKs using the "package installer", adb or Google Play.
Apex
The APEX file is similar to that used for Andoird APK applications.
APEX is a zip archive containing 4 main files:
- apex_manifest.json - contains the name of the package and its version;
- AndroidManifest.xml - package metadata (similar to APK);
- apex_payload.img - image of the ext4 file system;
- apex_pubkey - public key to verify the signature of the image.
The APEX manager system service (apexd) works with APEX packages.
Apex manager
- The package installer, having determined that it is an APEX package, passes it to the APEX manager.
- The APEX manager checks the package and its version.
- If the checks pass, it unpacks it into the user section of the memory, updates the record in its database and reboots the devices.
- When APEX boots, the manager checks all packages from the database, creates a loop device for the ext4 image and mounts it along the path / apex / name @ ver.
Inside an image from an APEX package, there may be:
- executable files
- shared (.so) libraries,
- JAR libraries,
- data files
- configuration files.
Signature APEX Package
APEX packet is signed twice, with two different keys. The ext4 image is signed with one key (dm-verity is used, as in the Android Verified boot), the APEX package (zip file) is signed with the second key, similar to the APK package.
Linux kernel
APEX uses a number of Linux kernel mechanisms, such as a loop device, DM-verity.
APEX is supported on the kernel version 4.4 and higher. For devices on older versions of the kernel, only work in "flat" mode that does not support updating is supported.
References:
android.googlesource.com/platform/system/apex/+/refs/heads/master/docs/README.md
android-developers.googleblog.com/2019/05/fresher-os-with-projects-treble-and-mainline.html
All Articles