About Step 1 — Minimal Bring-Up Step 2 — QTI Components Step 3 — Regenerate Blobs Summary GitHub ↗
Theme
CLO/CAF Based Android Custom ROM

Device Bring-Up
Guide

Bring up your device for Project Flare using your existing LineageOS device tree — in simple steps anyone can follow.

đŸŒŗ Do I Need a Special Tree?

✅
No — Use Your Existing Tree

You do not need an AOSPA tree or any special CLO tree to build Flare. You can build Flare directly using your existing LineageOS device tree. Some small adaptations are needed, but everything is explained below with references.

🔄 LineageOS Tree vs CLO Tree — What's Different?

The main difference is that LineageOS trees use some AOSP components where CLO uses Qualcomm's QTI CLO ones.

But here's the thing — if you have a Qualcomm device, you're most likely already using QTI components for display, audio, etc. from stock. The one area where LineageOS trees commonly differ is the power HAL:

ROMPower HAL
LineageOSlibperfmgr (Lineage Power HAL)
CLO / StockQTI Perf HAL
💡
Good to Know

Flare ships both power HALs for your convenience, so you can boot the ROM right away even with the Lineage power HAL. However, it's not ideal to run a CLO ROM long-term with the Lineage power HAL — you'll miss out on a lot of the performance benefits.

Minimal Bring-Up (Get It to Boot)

Start here. The goal is just to get your device to boot Flare.

âš ī¸
Important — QPR Trees Are NOT Supported

CLO/CAF does not merge Google's QPR (Quarterly Platform Release) updates. Instead, all QPR features arrive in the next major Android version.

This means:

  • For Android 16 → use a LineageOS 23.0 tree, not 23.1 or 23.2
  • For Android 15 → use a LineageOS 22.0 tree, not 22.1 or 22.2
  • And so on for older versions

If you only have a QPR tree (23.1 / 23.2 etc.), you'll need to revert the QPR-related commits from it before using it with Flare.

Use our minimal bring-up template as a reference for your device tree:

đŸ“Ļ Minimal Bring-Up Reference →

Clean Up Telephony Lines

Delete any telephony lines from your device tree that are already defined in the Flare source. If they're defined in two places, you'll hit a build error. The reference above shows exactly which lines to remove.

Once you've done this, you should be able to build and boot Flare on your device.

Adapting QTI Components (After First Boot)

Once your device boots, you can start switching over to proper QTI/CLO components for a better experience. This section assumes your device is already booting.

Should You Even Do This?

Only switch to a QTI component if something is broken. Examples:

  • Telephony (calls/SMS) broken → switch to QTI telephony
  • Audio broken → switch to QTI audio
  • Bluetooth broken → switch to QTI BT
🛑
Don't Fix What Isn't Broken

Stock display HAL for example is usually better than the common one — no need to change it unless there's a problem. If you're already using the stock QTI perf HAL in your tree, you likely don't need to adapt anything at all.

Switching the Power HAL (Lineage → QTI Perf HAL)

If you were using the Lineage power HAL (libperfmgr) for your first boot, here's how to switch to QTI Perf HAL properly.

You need to switch three things together:

  1. Perf HAL blobs
  2. Common QTI init files
  3. Common QTI overlay

How to do it:

  1. Open our device_qcom_common repo
  2. You'll see two folders — system/ and vendor/
  3. Check the init/, overlay/, and perf/ directories in both
  4. Remove from your device tree any files that are already defined in device_qcom_common

For perf HAL specifically, the blobs are proprietary, so you also need to clean up your proprietary-files.txt:

  1. Check the proprietary file list inside the perf/ directory of device_qcom_common
  2. Remove any matching blobs from your device tree's proprietary list

💡 You can use AI to speed up the comparison — just paste both lists and ask it to find duplicates.

Reference commits:

🔗 Overlay switch 🔗 Init switch 🔗 Perf HAL switch

Using Exclude Flags to Skip Blob Adaptation

Switching blobs can be tedious, and for some components you can actually skip it entirely using exclude flags.

🔖 Exclude flags commit →

Add any of these flags to your device.mk:

device.mk
TARGET_EXCLUDE_QTI_PREBUILT_AUDIO := true
TARGET_EXCLUDE_QTI_PREBUILT_BT := true
TARGET_EXCLUDE_QTI_PREBUILT_DISPLAY := true
TARGET_EXCLUDE_QTI_PREBUILT_GPS := true
TARGET_EXCLUDE_QTI_PREBUILT_TELEPHONY := true

Or to exclude all common prebuilt blobs at once:

TARGET_EXCLUDE_QTI_PREBUILTS := true
💡
Pro Tip

This is especially useful for telephony — just switch to the QTI telephony component and set the flag, no blob migration needed.

Regenerating Vendor Blobs

After cleaning up your proprietary files list, you need to regenerate the vendor tree so everything stays in sync.

If you've done this before, you already know how. If not, don't worry — you don't need to fully regenerate blobs from a device dump.

  1. Make sure you've fully synced the Flare source and cloned all your trees
  2. cd into your device tree directory
  3. Run the setup script:
./setup-makefiles.sh
# or
./setup-makefiles.py
â„šī¸
Common Tree Note

If you use a common device tree, you only need to run the script from your device tree — it will automatically regenerate makefiles for the common tree too.

  1. Commit and push your vendor tree
Note: Unused blobs may still remain. That's fine for now. Later, learn full blob regeneration from a stock device dump.

Summary

SituationWhat to do
First bring-upUse minimal bring-up reference, remove duplicate telephony lines, build and boot
Using Lineage perf HALBoot first, then switch to QTI perf HAL + init + overlay
Already using stock QTI perf HALYou're good, just check what's broken and fix selectively
Something brokenSwitch that specific QTI component
Don't want to migrate blobsUse TARGET_EXCLUDE_QTI_PREBUILT_* flags
After cleaning proprietary listRun setup-makefiles.sh

Resources

đŸ“Ļ
Reference Tree
Minimal Bring-Up Tree
🔧
Common Config
device_qcom_common
🔖
Exclude Flags
Reference Commit
đŸ’Ŧ
Community
Telegram Chat
đŸ“ĸ