The user-side will work with all kernels that contain the matching driver, but the user-side will not necessarily work on future Android versions without modification.
611 karma · joined December 25, 2021
The sources for the matching userspace binaries (which are usually the issue for Android version bumps) are usually under NDA by the component manufacturer and can not be released by the OEM independently.
On the other hand, LineageOS runs a lot of devices at the very (lower) edge of compatibility, which means that (with Google pushing large changes quarterly instead of yearly) the build roster has to be reevaluated quarterly instead of yearly as well. This was not anticipated properly for the Android 14 (LineageOS 21) cycle, which resulted in 19 devices not being able to be built on a previously supported major version (and therefore dropping from the roster completely).
In addition, the components that have been causing rebase conflicts each year now have the opportunity to cause rebase conflicts multiple times a year.
However, if donating means that you have to consider your current paycheck size, then it might be more appropriate to put that idea on the back-burner for a while.
If you don't have to make that consideration and/or you feel strongly obligated to donate, then by all means, please do so.
Just to emphasize this for anyone else who is reading this: Please do not feel obligated to donate.
Yes, it is greatly appreciated, since it keeps the lights on a little while longer and allows us to provide builds and host continued development. However, we regard donations as having no strings attached, and the same applies for using the builds that we provide.
We will be fine, at the very least for a while. Please think of yourself first.
Why not be mad at IEEE for a change? They apparently only managed to ban use of the image in April of 2024.
I'm sure at least someone has thought about doing that. However, including any amount of GrapheneOS code is considered a no-go.
> Or, to throw another wild guess, are you perhaps concerned that the "blind eye" only extends to Graphene, since they target Google's own devices only [...]
The "blind eye" in this case is the assumption that the permission to use Google Apps is attached to the device, not the software that is running on it (I'm not sure if this was ever communicated by Google in private or publicly).
While GrapheneOS still has the lowest amount of friction (because they only ever ship the devices that Google ships, with the respectively matching Android version), we hope that this licensing assumption applies to everyone equally.
> (and are lower profile in general, and also apparently contribute a lot of upstream code), while Lineage is much more widespread and well-known so it wouldn't get treated as nicely?
LineageOS being somewhat well-known and wide-spread is indeed something to be considered. As an example, PixelExperience both ships Google Apps built-in and has obvious points of conflict in regards to trademark issues, yet continues existing. We are not keen on finding out whether Google has changed their stance or whether PixelExperience is simply small enough to be flying under Google's lawyers' radars.
For what it's worth, we regularly try to contribute upstream as well, but get ghosted most of the time on things that aren't trivial. :^)
The only thing that matters is "did you have Google Apps or not?". This fact can not be changed without doing a factory reset, or your OS will be terribly confused. It shouldn't matter _which_ flavor of a Google Apps package you installed (although the officially recommended one only has one flavor anyways), for this purpose they are freely interchangeable. I also haven't seen any other addon that has this particular destructive trait, so you should be fine as long as you pay attention to "Google Apps or no Google Apps?".
> I'd be happy if the process were always a full reset followed by choosing what to run until the next full reset.. And maybe it is (?) but I never understand what people are talking about in android land.
You are free to do that, and this is basically the fallback option in case anything related to Google Apps goes wrong while upgrading. It's just that most users don't want to reset their devices each time that a major update appears, so the instructions jump through hoops to accommodate them.
Backups are (of course) always recommended, no matter the circumstances.
The important difference (I imagine) is that they still don't deliver Google Apps built into the ROM (which was what Google was disagreeing with 15 years ago).
The current consensus is that it's OK for a separate Google Apps package to exist, and that Google will turn somewhat of a blind eye under the assumption that the package will only be used on devices that have been licensed for use of Google Apps by their respective OEM.
Sadly, they have to be.
We can't ship Google Apps due to licensing restrictions (and even if we could, a very vocal subset of users probably wouldn't like that), but not upgrading Google Apps (and/or select other addons/components, for that matter) during a major version bump breaks the installation beyond repair.
It's unfortunate that this is the case, but there is no way around telling users to do major version upgrades manually instead of doing it all in-system.
The 25Q32BVSIG operates on 3.3V, so this particular programmer was compatible by default, but for 1.8V one would have to watch out indeed.
Good news: FreeBSD is able to read the whole variable list.
Bad news: I just wiped my test drive with all the in-progress kernel patches by accident.
To the untrained layman like me, this sounds like Windows actually is querying via `GetNextVariableName`, because UEFI doesn't seem to offer any other interfaces that aren't "get/set variable by name".
The userspace interface is somewhat documented by third-parties (because it is technically internal). However, the important parts happen kernel side, and I'd rather avoid diving too deep into Windows because some very interesting job postings (understandably) have "No exposure to Microsoft code or reverse-engineering of Microsoft software" in them.
I already tried getting to the service handler implementation via Linux, but memory protections made it weird enough that I was even questioning whether it was returning correct raw data when trying to read it from memory (or I have been looking at the wrong set of headers).
Had there been any more than one possible type of chip and more than three of these similar looking chips on the [accessible part of the] motherboard, I'd probably still be sitting here trying to figure out what to do.
In any case, I'll try and add it to the blog post once I figure out how to do footnotes. :^)
The main issue with fixing it properly is that I'd most likely have to reverse engineer the Windows kernel or the UEFI firmware itself (note to self: I haven't yet checked whether any of the *BSDs can read EFI variables in general and on this hardware in particular) to figure out where the request is going wrong/what Windows is doing different.
It's not impossible, given that one can unpack the UEFI PI firmware image into all the separate modules, but going through them to figure out where variable management is implemented will still take me a few weeks at least (not due to any particular challenge, it's just consuming a lot of time that I don't have right now).
> Especially in laptops, a lot of hardware / firmware issues are simply "solved" by baking a fix into the pre-installed Windows version. It's a solution for 99% of users, so why bother spending time looking into the root cause?
The Windows versions I installed for testing were non-OEM versions. They still behaved as expected.
Notably, Windows didn't just know about all the standard UEFI variables, but also about a non-standard one that I added for testing. This means that there definitely is a way to ask for the list of variables so that the UEFI accepts it (sadly, reverse engineering that is a pain), and that the Linux kernel is most likely the place where an actual fix has to happen.
Of course, yes, at the end of the day, the root cause is a specification non-conformity in the UEFI itself.
I seems that nobody except for Linux (for some not yet determined reason) is having issues with retrieving EFI variables on this hardware, and one could potentially classify this as a bug in `efibootmgr` as well (due to how it handles creating the new entry in unknown conditions).
In either case, Linux is the only thing affected by this, so in real-world setups Linux is going to be the only boot option that is available while the boot menu is in a broken state.
Compatibility with C++ is required at this point in time to interface with the thousands of lines of C++ code that have already been written. Assuming that everything will be written in Jakt at some point, then one could look into making more grave changes without having to care about compatibility (including maybe skipping the C++ part alltogether).
> Why not to just use Rust as their system language.
Rust has been evaluated, but discarded (mainly, iirc) due to it's approach (or lack thereof) for OOP. Also, the whole "we want to make things ourselves" thing.
This means that ~95% of users would break their installation by pressing the "auto-update" button because they didn't update their GApps accordingly.
Also, nowadays there is the problem of requiring a certain version of the built-in firmware as well, and in case there are any incompatibilities, a major version upgrade is the perfect time to require updating that as well.
"When it's ready."
Stuff is merged in once it's well tested and ready. It also is only updated as long as someone still cares to update it.
`userdebug` is used to have a few specific debugging capabilities that aren't available on a `user` ROM. Note that this is not the same as the standard `userdebug`, as most security measures that would otherwise get removed are manually reinstated.
> pretend to support devices past their vendor EOL (which is impossible since Lineage can't provide security updates for firmware etc.)
So... no security fixes at all are better in your opinion?
> ship the F-Droid Privileged Extension (which uses an incorrect approach to implementing unattended updates),
Where are you getting this from? Neither F-Droid nor its privileged extension is included in the system.
> don't support locking the bootloader to enable verified boot on many supported devices
There is nothing that inherently prevents you from relocking your bootloader on LineageOS. But technically, something may go wrong at any time, so it neither is officially supported nor endorsed, and the keys necessary for relocking the bootloader are not provided.
If someone wants to, they can always just build LineageOS themselves (with all system modifications built-in, because anything else would break the signature), sign it with their own keys, and reconfigure their bootloader to use that key.
They seem to have that issue with a lot of things.
At one point they were stripping existing copyrights out of the apps that were taken from other projects.
Changing the display name of an app definitely is one of the more innocent things to do, and most developers likely wouldn't even object. As an example, LineageOS uses Etar as the calendar app (with their permission of course), which is named "Calendar" in the app drawer.