A device can boot Android 17 and still be excluded from official LineageOS 24 builds. In its October 11 release announcement, the project says devices using Linux 4.4 and 4.9 will be accepted only on LineageOS 22.2, based on Android 15. For developers extending a phone's life, getting the new OS running is only part of the work.
OnePlus 6 and POCO F1 stay on Android 15
LineageOS says carrying these older kernels forward requires platform changes that have become difficult to maintain. It will keep building and merging monthly security patches for 22.2 until Google stops issuing Android 15 security bulletins. New device submissions to that branch remain welcome, according to the release notes.
The split is visible in the device catalogue. The OnePlus 6 page lists LineageOS 22.2, Android 15 and Linux 4.9, with LuK1337 as maintainer. Its supported-version history runs from Android 9 through Android 15. That's continued maintenance for a phone released in April 2018, even though it isn't moving to the newest Android branch.
The POCO F1, released in August 2018, has the same current Android and kernel versions. Both phones use Qualcomm's Snapdragon 845. Their listings give owners a concrete answer to the release question: both retain an official Android 15 branch, with named maintainers and installation guides. Neither device page lists support for 24.0.
Age alone doesn't describe the boundary. Google's Pixel 6 listing now shows LineageOS 24.0, Android 17 and Linux 6.1. It also names its maintainer and links separate instructions for installation, ordinary updates and major upgrades. The kernel and maintained device port provide more useful information than a general claim that an Android release supports old phones.
Official status carries obligations beyond reaching a home screen. Under the device support charter, maintainers must own the device or a suitable variant, keep valid installation instructions and routinely handle bug reports. Shipping devices must use SELinux in enforcing mode. The charter also requires working installation through the project's documented recovery path.
Those rules make an official build a recurring commitment. The charter's security requirements require patches for high-profile vulnerabilities and recommend regular fixes for kernels and their dependencies. A port that starts successfully provides no evidence by itself that someone can meet those obligations every month. That distinction explains why a newer unofficial build and an older official branch can coexist.
A current Android build has several security dates
LineageOS's security FAQ separates Android security fixes from vendor patches. The Android changes come from Google's AOSP bulletins. Vendor fixes apply to proprietary components, including hardware abstraction layers and closed binaries, and their patch date reflects the stock firmware used as the source. Updating Android doesn't automatically update that second layer.
The bootloader and modem introduce another dependency. The same FAQ says LineageOS cannot independently update these often closed components. Some devices include the expected firmware in their installation package, while others require a particular firmware version beforehand. If you're assessing a spare phone for development work, check those requirements alongside its Android version.
This is also why a device-specific guide matters when an installation fails. The FAQ's explanation of recovery errors includes firmware that is too old or too new, an outdated recovery, and an image intended for a different device or variant. Each points to a different fix. Repeating a flashing command won't correct an incompatible firmware base.
Patch dates need care on older branches, too. The release notes say LineageOS will keep backporting fixes to 18.1, 19.1 and 20.0 without changing their security patch level strings, because Google no longer supplies an attestable set of patches for those Android versions. An unchanged date can therefore accompany new backports. It also leaves users without the same claim of complete bulletin coverage that the project makes for branches still receiving Google's bulletins.
Browser flashing still starts with the right device
The release introduces WebUSB flash tools for ADB, Fastboot, Amlogic Burn and Samsung Odin protocols. They let a compatible browser communicate with the device without separate flashing utilities. LineageOS keeps its existing installation guides as the default supported route, with compatibility dependent on the device, browser, operating system and USB connection.
A related desktop tool shows what that connection still has to accomplish. samloader-rs combines Samsung firmware downloading and flashing, supports Linux, macOS and Windows, and can process official firmware packages in memory. Its commands distinguish checking an available firmware version, detecting a device and writing files to it. Presenting those operations through a browser can reduce setup work, but the files and target hardware still have to match.
The samloader documentation also traces its flashing implementation to Heimdall and credits earlier firmware download tools. This is useful context for the new installation options: the work includes implementing existing device protocols, with different requirements for different manufacturers. One interface doesn't make the devices interchangeable.
LineageOS's download FAQ says some exposed images are required for an installation or upgrade, while others exist to help debugging. Its instruction is to ignore files that your device guide doesn't mention. That's a practical starting point before choosing a browser or desktop utility: establish which images this particular installation needs.
Faster updates don't make major upgrades automatic
LineageOS 24's redesigned Updater streams updates by default, according to the announcement. Android's A/B update documentation explains the benefit: the system can write incoming update blocks directly to the target partition without first storing the whole package on the data partition. That reduces the temporary space needed for an update.
Google's description of legacy A/B updates explains separate partition slots: the system runs from one while preparing the other, with a fallback if the new system fails to boot. The page notes that Virtual A/B replaced the legacy design in Android 10. Treat this as background on Android's update mechanisms, and use the device guide for the actual procedure.
The Pixel 6 upgrade guide makes the distinction explicit: its Updater blocks packages for a different LineageOS version. Moving between major versions requires a manual process using recovery and ADB. The guide says that process doesn't wipe user data, but still recommends saving important files first. Those upgrade instructions remain separate from routine updates through the app.
Add-ons can change that procedure. The Pixel 6 guide tells users retaining Google Apps to install an updated package before Android's first boot. Adding or removing that package requires a factory reset. For this device, keeping your data depends on which add-on changes you make as well as following the upgrade procedure.
The experimental port makes the distinction visible
The release announcement also reports experimental bare-metal boots on PCs, Apple Silicon Macs, NVIDIA DGX Spark and Snapdragon X laptops. The generic device tree's status document supplies the qualification: cameras, GNSS, radio and power management are not yet implemented. Hardware video codecs are unavailable, and accelerated graphics aren't guaranteed on every card.
One detail makes the limits unusually clear. If the kernel exposes no battery device, the generic port presents Android with a fake battery reading of 85 percent. That's a development accommodation, not a measurement of the hardware. A functioning Android interface can therefore sit above missing support that only becomes apparent when you inspect individual subsystems.
For devices eligible for LineageOS 24, watch the device page and its download instructions. The project's FAQ says builds can be delayed or removed because of infrastructure, build failures or device problems, without support necessarily ending. The useful next signal is a maintained build for your exact model, accompanied by instructions you can follow.