In another thread on here this post suggests to dig into current patch level and build recency by looking at:
While I have some “concepts of plans” on how to do this, is there a handy explanation on how to assess the build and patch status of the device one holds in one’s hand? Or, as some users in the Graphene OS discussion would put it - assess “how much out of date” the current device build is?
The first level of information is Settings > About phone > tap on Android version
There will be different info there by device and Android version … will usually contain kernel version. Two things significant to current patch levels are
The name (of this date) can vary by context but these are what is meant by Android SPL and Vendor SPL.
Fairphone 5 had its own Vendor SPL thread Vendor Security Patch Level (SPL) in Fairphone 5.
my suggestion was: the code is there, just check. In any case do not harrass maintainers or developers.
It was “firmware version strings” in my statement - or use partition hashes compared to the ota payload published by the vendor that claims a newer vendor patch level. As previously mentioned, there’s also SnoopSnitch.
“framework base” meant to check if AOSP branches containing the ASB got merged, that is system patch level. This work is done by Lineage upstream and auto-merged in /e/OS repos since some time now. To check look for merged branch names.
My feeling when browsing some device repos (kernel or binaries) that are in the market for 2-3 years but not end of lifed by vendors yet: the kernel repos aren’t kept very much up to date.
Updated firmware but didn’t import the vendor kernel fixes? shouldn’t touch the vendor patch level then. Devices being able to use GKIs benefit from that infra work of Google getting kernel fixes this way. For Fairphones that started afaik with the FP5 (unsure about FP4). Compare to the official FP forge. Devices can use different kernels - vendor or if there is one, Lineages.
Pixels had an easy life up to now as lot of work was catered to the devices within the AOSP repo including proprietary parts.
For EoL devices all of this is best effort, no vendor backing.
Personally, this all sucks, but it is how mass produced smartphones swept the market cheaply for consumers.
Apologies for misquote, fixed.
As to the rest - phew, I have to learn a lot… no real clue on where to start (and then whether whatever I find there really means what I think it means). In any case, thanks for expanding on it!
At some point, if someone had time to write this up with links to repos and explanations as an example, I think it would be awesome.
where to start: it’s git repology you aquire when doing AOSP builds. Keywords are build and device manifest, device tree, kernel repo, proprietary files.
I have an example writeup but it isn’t really conclusionary, just hints. I can post but it got long.
To confirm source equals build artifact, you’d need to rebuild from the same commit hash. AOSP is to some degree reproducible (unsure, I never tried), in any case timestamp variables would need to be set to a fixed datetime, key material ignored.
I think you own a xz2c and FP5?
In retrospect after writing this down I don’t know how helpful this is to people totally unfamiliar with AOSP - but I wouldn’t know another way to “assess the patch level” bar running the exploits against the system it claims to have fixed (needs alot of other infrastructure).
if there’s no local build manifest that tells otherwise (see FP5 later), lineage build upstream picks device-tree folders by a specific scheme, so for xz2c it is “android_devices_sony_xz2c” and in there the “lineage.dependencies” determines more. I picked lineage links for the Sony as /e/ gitlab doesn’t mirror that devices repo and falls back to lineage. Release package version strings are inside proprietary-files.txt of both(!) this device tree and “commonized” repo(s). Look at the version strings in the first line and at times per subsection and search them at the GPL-sink vendor pages to what release date they correspond to
kernel version is in the Makefile header. If it isn’t an official kernel.org LTS release that Android Common Kernels track, it will be best effort backports after the version dropped out of the support window. A12+ release devices have it better with GKIs (your FP5). LTS get CVEs backported, but the closer you are to mainline the better
framework merges will have the aosp upstream branch name in their commit message across many aosp core repos (media, av etc). Click “branches containing merge”. I picked frameworks_base but you’d need to check more. If you visit that aosp tag at googles forge it will have the ASB month it conforms to.
so what’s the verdict? your xz2c hasn’t seen vendor firmware patches since 2020-ish (but some proprietary files are from other OEMs so not accurate on all counts), the 4.9 kernel dropped out of LTS / ACK status in January 2023 and is since a best effort backport op (but being sdm845 has it better than most other devices of similar age) and AOSP patchlevel in lineages merge and /e/ import is from june 2025 if you’re on A14 or A15.
Thus a system patch level of 2025-06-01 (slightly muddy) and vendor patchlevel of 2020-12-05 (but in theory a bit better, esp. on the kernel side - but the latter is ancient). If one says “there is only one patchlevel”, you’d need to pick the older one or just be informed what they mean.
I said previously start at the device tree, but one level above is the device manifest that can decide the repo picks. If a roomservice type xml overwrites the Makefile logic of lineage, the repos can be different. In FP5 case for bringup or to see if switching kernels fixes an issue, you can see branches of local_manifests do that switch. Atm FP5 devicetree repo on the A14 branch uses the upstream Lineage fairphone_qcm6490 kernel - for a time (or still?) it used android_device_fairphone_FP5-kernel that looks like a direct Fairphone vendor kernel. The Lineage kernel merges ASB branches. But compare the branches in any case, it gets merges for LOS 22.2 / A15 but not A14 (!). If you’re an FP5 user by the manifest you use the L21 / A14 kernel that last saw ASB merges in december. Unsure if the direct vendor kernel is used instead - not by the manifest. From outside, without the devices build strings or without a rebuild I can’t tell which manifest was used or if there’s another internal one. Your about screen kernel string will tell
look at release strings (“UT2P” atm) used at FP release notes used in proprietary-files.txt to see what they conform to in the published patch level dates. FP5.UT2P.B.122 was released with May patch level.
verdict? vendor probably 2025-05-01 patchlevel, but depends on kernel. Not if the kernel was based on the commonized lineage A14 branch. I’d think it’s the direct vendor kernel by FP, check your about screen. As for framework, the paragraph of the xz2c applies too. If the major branch (“a14”) has a recent ASB merge (ctrl+f “security” and look for the “android-security-…rVersion” merges), this side is self-explanatory - would come out at 2025-06-01 currently.
Awesome, thanks very much! Both for the legwork and for writing it up. This is really helpful.
Also, note to self - post more questions on other devices I might or might not own, because I seem to be too easily stalkable…
So without confirming or denying whether I really have a Fairphone 5, a little birdy might have told me the security patch level shows as 2025-06-01 as your detective work has said it would, vendor patch level shows as 2025-05-05.
what I forgot - beside the patch level(s), for /e/ the chromium fork repo matters too for webview and browser.
I’ve got a rant in me about all this and that rant ends with that I do not like Android. For one it’s one-corp directed and has too much money, so it’s hard for small teams to keep that pace and still innovate (I mean murena) - and the proprietary hardware it mostly runs on keeps you from fixing an issue in the closed parts, so a bureaucratic, contractual decision end-of-lifes a device.
Rant understood and sympathised with. Is there an alternative to it though at the moment?
today I learned - from the murena folk thread. Google puts out a tool for CVE signature checks:
As to alternatives, agreed - not for a general audience, but for enthusiasts, mobile linux is shaping up, blessed devices can do soviet-style photos already!