← Back to Blogs

System vs Vendor Services

Understanding the partition split in Android

1 min read

Android divides its software into partitions. The two most important are /system and /vendor. Understanding this split is crucial for AOSP work, HAL development, and understanding how OTA updates work without requiring vendor involvement.

The Partition Layout

Android Partition Structure

  ┌──────────────────────────────────────┐
  │  /system                             │
  │  Android Framework + Core Apps       │
  │  Updated by Google (OTA)             │
  │  system_server, framework.jar,       │
  │  Settings.apk, Telephony.apk...      │
  ├──────────────────────────────────────┤
  │  /vendor                             │
  │  OEM / Chip vendor code              │
  │  Updated by manufacturer             │
  │  HAL binaries, kernel modules,       │
  │  vendor daemons, firmware...         │
  ├──────────────────────────────────────┤
  │  /system_ext                         │
  │  Extended system components          │
  │  (OEM additions to framework)        │
  ├──────────────────────────────────────┤
  │  /product                            │
  │  Carrier / OEM apps                  │
  ├──────────────────────────────────────┤
  │  /data                               │
  │  User data, app data (encrypted)     │
  └──────────────────────────────────────┘

System Services

System services live in /system and run in the context of System Server. They are part of the Android framework and are started by SystemServer.java. These services are Google-owned and updated with every Android release.

Vendor Services

Vendor services live in /vendor and are specific to the chip or device manufacturer. They are typically HAL servers started by vendor init.rc files. They run isolated from the framework and communicate with it via AIDL/HIDL interfaces.

The Treble Interface Boundary

Project Treble (Android 8+) mandates a strict interface between /system and /vendor. System code cannot directly call into vendor code - they must communicate only through stable AIDL/HIDL interfaces. This means Google can ship a new /system image on top of an unchanged /vendor image.

Key rule: If your module is in /vendor, it must not link against libraries from /system (and vice versa). The build system enforces this. Violations are caught at build time with 'VNDK' (Vendor NDK) violations.