Directories, Rules, and sepolicy

This page describes the directory layout for devices running Android O, VNDK rules, and associated sepolicy.

Directory layout

The Degenerated Directory Layout consists of the following directories:

  • /system/lib[64] contains all framework shared libraries, including LL-NDK, SP-NDK, VNDK, and framework-only libraries (including LL-NDK-Indirect, SP-NDK-Indirect, and some libraries with the same names as the ones in VNDK-SP).
  • /system/lib[64]/vndk-sp contains VNDK-SP libraries for same-process HALs.
  • /vendor/lib[64] contains the extended VNDK libraries (either DXUA or DXUX VNDK libraries), same-process HAL implementations, and other vendor shared libraries.
  • /vendor/lib[64]/vndk-sp may contain extra libraries that are used by VNDK-SP libraries.

Vendor modules load the VNDK libraries from /system/lib[64].

VNDK rules

This section provides a comprehensive list of VNDK rules:

  • Framework processes must not load non-SP-HAL shared libraries from vendor partitions (not strictly enforced in Android O but will be in a future release).
  • Vendor processes must not load non-LL-NDK, non-SP-NDK, non-VNDK-SP, and non-VNDK libraries from the system partition. (not strictly enforced in Android O but will be in a future release).
  • NOTE: To benefit from the framework-only OTA beyond Android O, this rule must not be violated in devices launched with Android O.

  • Installed VNDK libraries must be a subset of Google-defined eligible VNDK libraries.
  • The outer dependencies of SP-HAL and SP-HAL-Dep must be restricted to LL-NDK, SP-NDK, or Google-defined VNDK-SP libraries.
    • The dependencies of an SP-HAL shared library must be restricted to LL-NDK libraries, SP-NDK libraries, SP-NDK libraries, Google-defined VNDK-SP libraries, other SP-HAL libraries, and/or other vendor shared libraries that can be labeled as SP-HAL-Dep libraries.
    • A vendor shared library can be labeled as a SP-HAL-Dep library only if it is not an AOSP library and its dependencies are restricted to LL-NDK libraries, SP-NDK libraries, Google-defined VNDK-SP libraries, SP-HAL libraries, and/or other SP-HAL-Dep libraries.
  • VNDK-SP must be self-contained. gets special treatment in Android O, but will be revisited in a future release.
  • No framework-vendor communication through non-HIDL interfaces, including (but not limited to) binder, sockets, shared memories, files, etc.
  • The size of the system partition must be large enough to contain two copies of all eligible VNDK libraries and a copy of ineligible framework shared libraries.


Framework processes described in this section correspond to coredomain in sepolicies while vendor processes correspond to non-coredomain. For example, /dev/binder can be accessed only in coredomain and /dev/vndbinder can be accessed only in non-coredomain.

Similar policies restrict the access to the shared libraries on system and vendor partitions. The following table shows the rights to access shared libraries of different categories:

Category Partition Accessible from
Accessible from
LL-NDK System Y Y
LL-NDK-Indirect System Y Y
SP-NDK System Y Y
SP-NDK-Indirect System Y Y
VNDK-SP/VNDK-SP-Indirect/VNDK-SP-Indirect-Private System Y Y
VNDK-SP-Ext/VNDK-SP-Indirect-Ext Vendor Y Y
VNDK System Y Y
VNDK-Ext Vendor N Y
SP-HAL Vendor Y Y
SP-HAL-Dep Vendor Y Y

LL-NDK-Indirect, SP-NDK-Indirect, VNDK-SP-Indirect, and VNDK-SP-Indirect-Private must be accessible from both domains because non-coredomain will indirectly access them. Similarly, SP-HAL-Dep must be accessible from coredomain because SP-HAL relies on it.