Google Play System Updates

Google Play System Updates (GPSU) is the delivery mechanism for Project Mainline (Modular System Components). It leverages the robust distribution infrastructure of the Google Play Store to push updates to core OS modules, fundamentally changing how Android devices stay secure and up-to-date.

Mainline Module Delivery via Play Store

To the user, a Google Play System Update looks similar to a regular app update, but its underlying mechanics are entirely different.

The Google Play Store app has special system privileges. When Google releases a new version of an APEX module (e.g., the ART module), Play Services queries Google's servers. If an update is available, the Play Store downloads the .apex file to a staging directory on the /data partition.

This process bypasses the OEM and mobile carrier completely. Google builds the modules directly from the AOSP source and signs them with Google's own cryptographic keys, ensuring uniformity across the entire Android ecosystem.

Update Flow: Download, Stage, Reboot, Activate

Because APEX modules contain critical native libraries and daemons that are constantly in use, they cannot be replaced while the system is running. The update process is strictly staged.

1. Download: The Google Play Store downloads the .apex file.
2. Staging (PackageInstaller): The Play Store passes the APEX to the PackageInstaller service. The system verifies the Google signature on the APEX to ensure it is authentic and hasn't been tampered with.
3. Pre-reboot Verification: The APEX daemon (apexd) performs a dry-run mount of the new payload. It verifies the dm-verity hash tree to ensure the filesystem image is structurally sound.
4. Reboot Required: The user is prompted to restart their device. The update remains pending in /data/apex/sessions/.
5. Activation: During the next boot sequence, apexd detects the staged session. It mounts the new APEX from /data/apex/active/ over the old factory-installed APEX residing in /system/apex/. The system then boots using the updated libraries.

You can inspect active APEX sessions via shell:

adb shell dumpsys apex

Rollback of Mainline Updates

A catastrophic failure in a core module like ART or Bionic would render a device completely unusable (a "bootloop"). To mitigate this, GPSU includes a sophisticated, mandatory rollback mechanism.

Android monitors system health using the RescueParty and Watchdog components.

• If init detects that a critical service (like zygote or system_server) crashes repeatedly during boot.
• If the device fails to reach a stable state within a specific timeframe.

The system will trigger a rollback. apexd will mark the newly updated APEX as problematic, delete it from /data/apex/active/, and fallback to the original, factory-provided APEX residing on the read-only /system partition. The device then reboots safely into its previous working state.

OEM Responsibilities for Mainline Compliance

While Google builds and distributes the Mainline modules, OEMs still have critical responsibilities to ensure their devices are compliant.

• No Modifications: OEMs are strictly forbidden from modifying the source code of Mainline modules. They must include the prebuilt APEX files provided by Google in their factory ROMs.
• Factory Keys: The APEX files shipped in the factory system.img must be signed by Google's keys, not the OEM's keys. This ensures that the Google Play Store can seamlessly update them later.
• Testing: OEMs must run the Mainline Test Suite (MTS) alongside the standard CTS to prove that their hardware and custom framework modifications do not interfere with the operation of Google's Mainline modules.
• Bootloader Support: The device bootloader must support A/B updates and robust rollback mechanisms to satisfy the safety requirements of staged APEX installations.