APEX Format

The Android Pony EXpress (APEX) is a container format introduced in Android 10 to enable the update of lower-level system components. Unlike traditional APKs that run in the Dalvik/ART virtual machine, APEX files are designed to package native libraries, daemons, and core system utilities, effectively serving as an updateable filesystem within a file.

The APEX File Format: Zip with an Image

At its core, an .apex file is an uncompressed ZIP archive. This structure allows the system to extract metadata without needing to unpack the entire file.

Inside an APEX file, you will typically find:

• apex_manifest.pb: A protocol buffer file defining the APEX name and version.
• AndroidManifest.xml: For integration with the Android package manager (PackageManager).
• apex_payload.img: The heart of the APEX. This is an ext4 or EROFS filesystem image that contains the actual payload (native binaries, .so libraries, configuration files).
• apex_pubkey: The public key used to verify the payload's signature.

You can inspect an APEX file on a host machine using standard tools:

unzip -l some_module.apex

Security via dm-verity Protected Filesystem

A key requirement for APEX is that system processes must be able to trust the code inside them just as much as code residing on the read-only /system partition.

To achieve this, the apex_payload.img is mounted using dm-verity (Device Mapper Verity). dm-verity provides transparent integrity checking of block devices. When Google or an OEM signs an APEX, a hash tree of the payload image is generated, and the root hash is signed. When the APEX is mounted, the kernel verifies each block against this hash tree as it is read into memory. If an attacker tampers with the .apex file on the /data partition, the block read will fail the cryptographic hash check, and the kernel will refuse to serve the data, preventing the execution of malicious code.

APEX Activation at Boot (apexd)

APEX files cannot be updated while the components inside them are running. Therefore, updates are staged and activated during the boot process.

The APEX daemon (apexd) is one of the first processes started by init. Its lifecycle is critical:

1. Scanning: apexd scans /system/apex/ (pre-installed, read-only APEXes) and /data/apex/active/ (updated APEXes).
2. Verification: For updated APEXes in /data, apexd verifies the signature and the dm-verity root hash.
3. Mounting: apexd uses loopback devices to mount the apex_payload.img to a mount point in /apex/. For instance, the com.android.tzdata APEX is mounted at /apex/com.android.tzdata/.
4. Binding: Once mounted, apexd creates a bind mount so the highest-versioned APEX is always available at the expected path.

Only after apexd signals that all APEXes are successfully mounted does init proceed to start the rest of the Android framework, ensuring that all native dependencies (like the C library or ART) are ready.

Linker Namespace Isolation for APEX Libraries

Because APEXes contain native libraries (.so files), they introduce a risk of "DLL hell" or symbol clashes if multiple APEXes provide different versions of the same library, or if an APEX library conflicts with a system library.

Android solves this using Linker Namespaces. The dynamic linker (/system/bin/linker64) enforces strict isolation:

• Code inside an APEX can only link against libraries within its own APEX, or explicitly whitelisted libraries in the system (like libc.so or liblog.so).
• System code cannot accidentally link against internal libraries of an APEX unless those libraries are explicitly exposed as a public API surface.

This isolation is configured via ld.config.txt and ensures that modular updates to an APEX do not inadvertently break other system components due to hidden ABI (Application Binary Interface) changes.