Cross-Cutting Architecture

Beyond the vertical layers (Apps, Framework, Native, HAL), Android relies on "Cross-Cutting" blocks that span the entire stack. These subsystems ensure security, build integrity, testing quality, and seamless updates.

1. Security (SELinux & AVB)

Android uses SELinux (Security-Enhanced Linux) to enforce Mandatory Access Control (MAC) over all processes, even root.

SELinux

• Enforcing Mode: Default in production. Violations are blocked and logged.
• Permissive Mode: Violations are logged but allowed (debugging only).
• Domains: Every process has a domain (e.g., u:r:system_server:s0).
• Contexts: Every file has a context (e.g., u:object_r:system_file:s0).

Debugging Denials (dmesg / logcat): When SELinux blocks an action, it logs an "AVC Denial":

• Action: { read } (MyApp tried to read)
• Actor: scontext (Source Context: myapp)
• Target: tcontext (Target Context: system_data_file)
• Fix: Use audit2allow to generate the .te policy rule to allow this (if safe).

Android Verified Boot (AVB)

AVB ensures that all code running on the device comes from a trusted source (usually the device manufacturer). It verifies the cryptographic signature of every partition (boot, system, vendor) before loading it.

dm-verity: Block-Level Verification

dm-verity is a kernel feature that verifies every block read from read-only partitions (/system, /vendor):

How it works:

1. Build Time: Generate a hash tree of all blocks in the partition

   • Each 4KB block is hashed
   • Hashes are organized in a Merkle tree
   • Root hash is signed with OEM key

2. Boot Time: Kernel loads the signed root hash from the boot image

3. Runtime: Every block read is verified against the hash tree

   • If verification fails → kernel panic (prevents tampering)
   • Verified blocks are cached (performance optimization)

Check dm-verity Status:

Verification States:

Note: The following states apply to physical devices with locked bootloaders. Emulators typically show veritymode: enforcing but don't expose verifiedbootstate.

• Green: Device is locked, all partitions verified
• Yellow: Device is locked, but verification failed (warning shown at boot)
• Orange: Bootloader is unlocked (verification disabled for development)
• Red: Verification failed on locked device (boot blocked)

Why This Matters:

• Prevents malware from modifying system files
• Ensures OTA updates haven't been tampered with
• Critical for enterprise/government deployments

📁 Official Documentation: Verified Boot | dm-verity

2. Build System (Soong / Make)

The Android Build System compiles the millions of lines of source code into the final disk images.

• Soong (.bp files): The modern build system (JSON-like syntax) that replaced Make. It compiles C++, Java, and Kotlin modules.
• Bazel (Future): AOSP is gradually migrating to Bazel for hermetic builds.
• Make (.mk files): Legacy build files still used for some device configuration.

Example Android.bp (Soong):

Key Artifacts:

• system.img: The Android OS.
• userdata.img: User data partition.
• vendor.img: Device-specific binaries.

📁 Official Documentation: Build System

3. Test Infrastructure (CTS / VTS)

To ensure specific Android devices are compatible with the ecosystem, Google provides rigorous test suites.

• CTS (Compatibility Test Suite): Automated tests that verify user-app compatibility. If a device fails CTS, it cannot include the Google Play Store.
• VTS (Vendor Test Suite): Validates that the HAL and Kernel implementations correctly support the Android Framework (Project Treble compliance).
• GTS (Google Mobile Services Test Suite): Tests for GMS (Google apps) compliance.

📁 Official Documentation: Compatibility

4. Observability (Perfetto / Logs)

Understanding what's happening inside the black box is critical for system engineers.

• Logcat: Real-time logging system (adb logcat).
• Perfetto: System-wide tracing tool. It records kernel scheduling, userspace function calls, and memory usage into a trace file for visualization.
• Dumpsys: Provides a snapshot of the status of system services (adb shell dumpsys).
• Tombstones: Crash dumps for native process failures.

📁 Official Documentation: Perfetto

5. Updates (A/B & APEX)

<div id="apex" className="scroll-mt-24"></div>

Modern Android devices update seamlessly in the background.

A/B (Seamless) Updates

Devices have two sets of partitions: Slot A and Slot B.

• The system runs from Slot A.
• Updates are installed to Slot B in the background.
• On reboot, the bootloader switches to Slot B.
• If boot fails, it falls back to Slot A.

APEX (Android Pony EXpress)

APEX allows updating core system components (like ART, Media Codecs, or Native Libraries) via the Play Store, without a full system OTA. An APEX file is essentially a mini filesystem mounted at runtime.

📁 Official Documentation: OTA Updates