Skip to content
October 11, 2026•9 min read•By Dzaki Amri Zaidaan

LineageOS 24.0: Engineering a Post-Android 16 AOSP Fork with Treble VNDK and Kernel 6.1

A deep dive into LineageOS 24.0's architecture: how the fork rebases on Android 16 QPR, enforces Treble VNDK 35, migrates to kernel 6.1 LTS, and ships a hardened, reproducible build pipeline for 200+ devices.

#Architecture#DevOps
black and silver computer ram stick

The Problem & Industry Shift

For a decade, custom Android distributions lived in a comfortable gray zone: fork AOSP, patch frameworks/base, ship a zip. That model broke with Project Treble (Android 8) and shattered with the Vendor Interface / VNDK split and the GKI (Generic Kernel Image) mandate. By Android 14, a ROM that touched vendor blobs or shipped a non-GKI kernel could not boot on a device with a locked-down bootloader chain and a signed vbmeta.

LineageOS 24.0 is the first major release that fully internalizes this reality. It rebases on Android 16 (API 36) AOSP, targets VNDK 35, and requires kernel 6.1 LTS or newer for GKI-compliant targets [1]. The engineering consequence is that LineageOS is no longer "AOSP plus patches" — it is a downstream distribution that must respect the same vendor/kernel contracts Google enforces on OEMs, while still supporting 200+ devices whose vendors abandoned them years ago.

The shift matters because the previous approach (Android 13/LineageOS 20) relied on:

  • Monolithic system.img patching — fragile, broke on every security patch.
  • Per-device kernel forks — thousands of divergent trees, unmaintainable CVE surface.
  • Non-reproducible builds — signed with maintainer keys, no verifiable provenance.

LineageOS 24.0 replaces all three with a Treble-native, GKI-anchored, reproducible pipeline.

Architecture & Core Mechanics

LineageOS 24.0 sits as a thin, opinionated layer on top of AOSP. The critical insight is the separation of concerns enforced by Treble:

+-------------------------------------------------------------+
|  LineageOS 24.0 (system + product + system_ext partitions)  |
|  - frameworks/base patches (privacy, UI, permissions)       |
|  - Lineage SDK (lineage-sdk)                                |
|  - Updater, Trust, Profiles, LiveDisplay                    |
+-------------------------------------------------------------+
              |  HIDL/AIDL over /dev/binder
              v
+-------------------------------------------------------------+
|  VNDK 35 (vendor-native dev kit) — stable ABI surface       |
|  Provided by AOSP, consumed by vendor HALs                  |
+-------------------------------------------------------------+
              |  GKI kABI
              v
+-------------------------------------------------------------+
|  GKI kernel 6.1 LTS + vendor modules (.ko)                  |
|  Boot image: boot.img + vendor_boot.img + dtbo.img          |
+-------------------------------------------------------------+
              |  AVB 2.0
              v
+-------------------------------------------------------------+
|  Verified Boot chain (vbmeta, dm-verity, dm-verity-avb)     |
+-------------------------------------------------------------+

Data flow at boot

  1. Bootloader verifies vbmeta against the device's root of trust.
  2. GKI kernel loads, mounts vendor_boot ramdisk, then system via dm-verity.
  3. init reads /system/etc/init/hw/init.rc and the VNDK snapshot to resolve vendor HALs.
  4. lineage-sdk initializes after system_server, injecting privacy toggles via PermissionManagerService hooks.

Key architectural decisions in 24.0

  • VNDK 35 enforcement: LineageOS now ships a frozen VNDK snapshot. Vendor HALs compiled against VNDK 33/34 are rejected at linker time unless explicitly allowlisted via vndk_lite.
  • GKI-only kernels: Non-GKI devices are supported through a legacy compatibility shim (lineage-legacy-kernel) that emulates the GKI kABI surface, but this is deprecated and will be removed in 25.0.
  • Reproducible builds: Every official build is produced inside a pinned docker image (lineageos/build:24.0) with SOURCE_DATE_EPOCH set, enabling bit-for-bit verification against the published sha256sum manifest [2].
  • repo manifest restructure: The lineage-24.0 branch now uses a two-tier manifest — default.xml (AOSP) + lineage.xml (fork) — so upstream rebases are mechanical rather than manual merges.

Production Code Example

Below is a realistic device tree snippet (device/xiaomi/example/BoardConfig.mk and lineage_example.mk) showing how a maintainer wires a GKI-compliant device into LineageOS 24.0. Inline comments highlight the non-obvious engineering decisions.

# device/xiaomi/example/BoardConfig.mk

# --- Treble / VNDK ---
# 24.0 REQUIRES VNDK 35. If the vendor ships VNDK 33, you must
# either rebuild vendor HALs or declare the device as 'vndk_lite'.
BOARD_VNDK_VERSION := 35
BOARD_VNDK_RUNTIME_DISABLE := false

# --- GKI kernel ---
# 24.0 mandates kernel 6.1 LTS for GKI targets. Prebuilt kernel
# must be a GKI boot image; vendor modules go into vendor_boot.
TARGET_KERNEL_VERSION := 6.1
BOARD_USES_GENERIC_KERNEL_IMAGE := true
BOARD_KERNEL_MODULES_INCLUDE := \
    $(wildcard $(DEVICE_PATH)/modules/*.ko)

# --- Verified Boot ---
# AVB 2.0 with a 4096-bit RSA key. The vbmeta must chain to the
# device's root of trust or the bootloader will refuse to boot.
BOARD_AVB_ENABLE := true
BOARD_AVB_ALGORITHM := SHA256_RSA4096
BOARD_AVB_KEY_PATH := vendor/lineage/security/avb/example.pem
BOARD_AVB_ROLLBACK_INDEX := 1

# --- Partitions ---
# 24.0 uses dynamic partitions (super.img) with a 2MB alignment
# for the vendor_boot header. Misalignment breaks OTA.
BOARD_SUPER_PARTITION_SIZE := 9126805504
BOARD_SUPER_PARTITION_GROUPS := xiaomi_dynamic_partitions
BOARD_XIAOMI_DYNAMIC_PARTITIONS_SIZE := 9122611200

# --- LineageOS-specific ---
# The lineage-sdk requires this flag to enable privacy toggles.
TARGET_USES_LINEAGE_SDK := true
# Enable the reproducible-build timestamp override.
LINEAGE_REPRODUCIBLE_BUILD := true
# device/xiaomi/example/lineage_example.mk

# Inherit the common GKI device tree first — order matters.
$(call inherit-product, device/xiaomi/gki-common/lineage_gki.mk)

# Product identity. The 'lineage_' prefix is mandatory in 24.0
# so that the OTA server can route updates correctly.
PRODUCT_NAME := lineage_example
PRODUCT_DEVICE := example
PRODUCT_BRAND := Xiaomi
PRODUCT_MODEL := Example GKI Device

# VNDK 35 enforcement: fail the build if the vendor ships < 35.
PRODUCT_EXTRA_VNDK_VERSIONS := 35

# Include the LineageOS apps and SDK.
PRODUCT_PACKAGES += \
    LineageSettingsProvider \
    LineageParts \
    LineageUpdater \
    Trust

# Reproducible build: pin the timestamp to the source commit date.
PRODUCT_BUILD_PROP_OVERRIDES += \
    BUILD_DATETIME=$(shell date -u -d @$(SOURCE_DATE_EPOCH) +%s)

Critical engineering notes:

  1. BOARD_VNDK_VERSION := 35 is not a suggestion — the linker will hard-fail on VNDK 33/34 symbols unless vndk_lite is set, which disables the stable ABI guarantee.
  2. BOARD_USES_GENERIC_KERNEL_IMAGE := true forces the build to use the GKI boot image. Vendor modules must be signed and placed in vendor_boot, not boot.
  3. LINEAGE_REPRODUCIBLE_BUILD := true sets SOURCE_DATE_EPOCH and strips build paths. Without it, sha256sum verification fails.

Performance, Cost & Trade-offs

Build-time and OTA cost

MetricLineageOS 20 (Android 13)LineageOS 24.0 (Android 16)
Full build (16-core, 64GB)~4h 10m~5h 45m
Incremental (1 file)~12 min~18 min
OTA payload size~1.1 GB~1.4 GB
super.img size~7.2 GB~8.5 GB

Why the regression? VNDK 35 ships a larger stable ABI surface, and GKI 6.1 adds ~180 MB of kernel modules. The OTA payload grows because delta_generator must diff the larger vendor_boot.

Runtime trade-offs

  • Latency: VNDK 35's stricter linker namespace isolation adds ~40–60 ms to cold boot on mid-range SoCs (Snapdragon 778G). This is the cost of ABI stability.
  • Memory: GKI 6.1's vendor_boot ramdisk is ~30 MB larger than a monolithic boot image, but it enables module unloading at runtime, saving ~50 MB after boot.
  • Security: AVB 2.0 with dm-verity adds ~2% I/O overhead on system reads, but eliminates the entire class of "persistent rootkit" attacks that plagued pre-Treble ROMs.

The hard trade-off

LineageOS 24.0 drops support for ~40 legacy devices that cannot meet the GKI 6.1 requirement. This is deliberate: maintaining non-GKI kernels means backporting CVEs indefinitely, which is unsustainable for a volunteer project. The lineage-legacy-kernel shim exists as a one-release grace period, not a long-term solution [3].

Actionable Checklist / Summary

If you are a device maintainer or an engineer adopting LineageOS 24.0:

  • Verify VNDK version. Run adb shell getprop ro.vndk.version. If it is < 35, either rebuild vendor HALs or declare vndk_lite (and accept the ABI risk).
  • Confirm GKI kernel. Check uname -r — it must be 6.1.x. If not, you need a GKI port or the legacy shim.
  • Enable reproducible builds. Set LINEAGE_REPRODUCIBLE_BUILD := true and verify with sha256sum against the published manifest.
  • Re-sign AVB. Generate a new vbmeta with avbtool and a 4096-bit RSA key. Never reuse a leaked key.
  • Test OTA delta. Use ota_from_target_files with --delta and validate on a locked bootloader.
  • Audit lineage-sdk hooks. Privacy toggles inject into PermissionManagerService; ensure your device's sepolicy allows the new lineage_* contexts.
  • Pin your build environment. Use the official lineageos/build:24.0 Docker image to avoid toolchain drift.

Bottom line: LineageOS 24.0 is the most disciplined release in the project's history. It trades device breadth for ABI stability, reproducibility, and a sustainable security posture. For engineers, it is a masterclass in downstream distribution engineering — respecting upstream contracts while still shipping a differentiated product.

References