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?
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:
| ROM | Power HAL |
|---|---|
| LineageOS | libperfmgr (Lineage Power HAL) |
| CLO / Stock | QTI Perf HAL |
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.
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
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:
- Perf HAL blobs
- Common QTI init files
- Common QTI overlay
How to do it:
- Open our device_qcom_common repo
- You'll see two folders â
system/andvendor/ - Check the
init/,overlay/, andperf/directories in both - 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:
- Check the proprietary file list inside the
perf/directory ofdevice_qcom_common - 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 switchUsing 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:
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
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.
- Make sure you've fully synced the Flare source and cloned all your trees
cdinto your device tree directory- Run the setup script:
./setup-makefiles.sh
# or
./setup-makefiles.py
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.
- 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
| Situation | What to do |
|---|---|
| First bring-up | Use minimal bring-up reference, remove duplicate telephony lines, build and boot |
| Using Lineage perf HAL | Boot first, then switch to QTI perf HAL + init + overlay |
| Already using stock QTI perf HAL | You're good, just check what's broken and fix selectively |
| Something broken | Switch that specific QTI component |
| Don't want to migrate blobs | Use TARGET_EXCLUDE_QTI_PREBUILT_* flags |
| After cleaning proprietary list | Run setup-makefiles.sh |