Framework/Vendor Separation at the Partition Level
Project Treble fundamentally redesigned Android's architecture. Prior to Android 8.0, the Android framework and vendor-specific hardware drivers were tightly coupled within the /system partition. Updating the OS required vendors to rewrite significant portions of their HALs.
Treble introduced a strict boundary by mandating a physical partition separation:
- /system partition: Contains the generic Android Open Source Project (AOSP) framework, built by Google.
- /vendor partition: Contains the System-on-Chip (SoC) specific hardware drivers and HAL implementations, built by companies like Qualcomm, MediaTek, or Samsung.
These two partitions communicate exclusively through stable, versioned interfaces (HIDL or AIDL). This separation allows the /system partition to be updated via Over-The-Air (OTA) updates without requiring any changes to the /vendor partition.
Vendor Native Development Kit (VNDK)
Because the /system and /vendor partitions are updated independently, they cannot share arbitrary native libraries (e.g., libssl.so or libpng.so). If the framework updates a shared library and changes its ABI, vendor binaries relying on the older ABI would crash.
The Vendor Native Development Kit (VNDK) solves this. It is a curated set of libraries provided by the framework that vendor modules are permitted to link against. Crucially, the system partition maintains backwards compatibility for these VNDK libraries for multiple API levels.
VNDK Libraries: VNDK-core, VNDK-SP
The VNDK is subdivided based on usage and process constraints:
- VNDK-core: Standard shared libraries used by vendor processes. These are loaded into vendor HAL processes.
- VNDK-SP (Same-Process): Libraries that must be loaded directly into a framework process (e.g., libEGL, libGLESv2 for graphics drivers). Since they run in the framework's memory space, they face stricter linking restrictions to avoid symbol collisions.
- LLNDK (Low-Level NDK): A very small set of stable C libraries (like libc, libm, liblog) that are guaranteed to remain ABI stable forever. Both framework and vendor processes link against the exact same LLNDK libraries.
You can inspect the dependencies of a vendor binary using the readelf or ldd tools on the device to ensure it only links against allowed VNDK/LLNDK libraries.
# Check dependencies of a vendor HAL
adb shell readelf -d /vendor/bin/hw/android.hardware.camera.provider@2.4-service
Vendor Processes vs Framework Processes
Treble mandates that HALs run in their own sandboxed processes, known as "Binderized HALs".
Before Treble, the camera driver was loaded as a .so directly into the mediaserver process (a "Passthrough HAL"). A crash in the camera driver would crash the entire media subsystem.
With Treble, the camera HAL runs in its own /vendor/bin/hw/ process. The mediaserver (in the framework) communicates with the camera HAL (in the vendor partition) via hwbinder (Hardware Binder).
You can use dumpsys to inspect the services registered via hardware binder:
# List all hardware binder services running on the device
adb shell dumpsys -l | grep "android.hardware"
This strict process isolation greatly improves system stability and security, as vendor drivers no longer execute with framework-level privileges.