[t14000]

> Android 15 introduced several complex changes under the hood...

> Android’s move to trunk-based development, and the subsequent growth in size of Android’s QPRs (Quarterly Platform Releases) have made our job magnitudes harder! As a byproduct we must rebase our entire code-base every 3 months.

> Sadly, Google also has a habit of introducing deprecations or outright removing code that older devices rely on with little advanced notice...

Google trying new tactics to move Android from open-source to "source available, lol"?

[zozbot234]

> Google trying new tactics to move Android from open-source to "source available, lol"?

It seems to be the opposite - more of AOSP internal development moving out into the open. QPR's are getting more frequent releases than the old AOSP code-drops.

(Tbh I do think that AOSP has always had way too much churn for a sensible system. A Linux phone should just work, and share as much of its codebase as possible with Linux systems running on other device classes; distributions like pmOS and Mobian - and quite possibly Debian Mobile in the future - are working towards this goal.)

[gf000]

Or maybe the Linux Desktop (used by a couple of people) should use more code from the android project (which is the biggest OS on the Earth)

The latter has sane sandboxing, proper IPC, an app lifecycle that makes sense for embedded devices (an app in the background should only ever take CPU time if it has an explicit service with permission for that) etc.

[zozbot234]

Plain old Linux has these features. For example:

> an app in the background should only ever take CPU time if it has an explicit service with permission for that

You can run your services in a cgroup and use "freeze" and "thaw" support for that purpose.

[gf000]

It doesn't have it, because this is like security. You either have it everywhere, or it doesn't matter.

Sure, the Linux kernel is very capable, but the "gnu" userspace doesn't make good use of its features. Android makes much better use and has a bunch of software that could be re-used on the former as well.

[ykonstant]

Is the reason GNU doesn't use these kernel features aggressively that they want to be portable? Or something else?

[zozbot234]

Freezing background apps just isn't needed all that much if you run a fully FLOSS system. It's much more of a concern for proprietary software where you don't have the source code available. There's a similar story for sandboxing actually, it's not a coincidence that it's been getting more popular as proprietary apps have been made widely available via Flathub and the like.

[nextaccountic]

You "can" in the sense that the kernel technically supports, but realistically, who does that for all programs they use?

Android userland is actually better designed in some ways

[throw5959]

Android is not "a Linux phone", it just happens to use Linux kernel under the hood. What you're saying was always an explicit anti-goal.

[surajrmal]

This is gatekeeping. Linux is a kernel. You're talking about userspace which is not part of the Linux kernel project.

[throw5959]

What gatekeeping? I'm talking about Android project goals. They never intended to provide any direct userspace access to the Linux kernel. The Linux kernel is supposed to be an implementation detail that can be replaced without breaking app compatibility.

[surajrmal]

That is more of a theory than reality. In practice you need to emulate the Linux kernel in order to run Android. Keep in mind that Android is more than just the apps you run.

[throw5959]

Yes, I agree. But it is the stated goal.

[sweden]

It should be the opposite, I am a bit confused about LineageOS' statement here. The Quarterly releases represent solid milestones towards the final Android number milestone.

GrapheneOS claims that this made their rebasing much more efficient: instead of receiving a massive dump of all Android 15 at the end, developers receive incremental changes (the QPRs) to help them anticipate major changes in the code.

[timschumi]

GrapheneOS only supports devices that are still supported by the OEM, and they generally seem to have very few modifications that touch on frequently-changed parts of AOSP. In short, they can be relatively certain that nothing will break when they rebase, Google does the work for them.

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.