Sounds like good news for mobile linux!
Right after Linux on desktop takes off, which is sure to happen any day now.
I don’t need desktop linux to “take off”, I’ve happily used it for a decade. I don’t need mobile linux to become mainstream. I just need it to be a bit better than it currently is.
User base size dictates development resources. If you want Linux mobile to be daily driveable, you do need widespread adoption.
I thought Ubuntu Touch was dang near useable years ago, what someone considers “daily drivable” is probably subjective. If dumb phones had a web browser I’d probably settle for that as I self host and every service has a WebUI.
It’s honestly not the feature set of Linux on Mobile that holds me back from the permanent switch, it’s consistent availability of compatible hardware.
And there’s great strides happening towards fully open mobile hardware platforms.
The year of Linux on Mobile is steadily approaching. I predict it’ll be similarly disruptive as Android’s meteoric rise.
You’re quite right, I’ve forgotten how frustrating it was not knowing if I could get a hold of a replacement if my daily driver custom ROM Android gave up the ghost back when custom ROMs weren’t as widely supported as now.
Exactly. I’m not using mainstream Linux on my phone (I use Android) despite using Linux on my other devices (phone, laptop, desktop, servers), because it’s not daily driveable for me. I really want to switch, but I need some base level of compatibility, and it’s not there yet.
I personally finished deleting windows off of all of my machines recently. One by one we will add up over time
For every person switching from Windows to Linux, how many people got a new Chromebook or a Mac, or just do everything on their phones or a tablet?
I have a Linux machine myself, and I love having it, but I don’t think the user base is growing particularly quickly as a percentage of PC OS installations.
It’s but growing quickly (well, SteamDeck is), but it’s growing consistently. We’l recently passed an important milestone where people are being charged for no additional features in their commercial operating systems.
That’s why the commercial OS vendors are so keen to add AI. They know they need a new differentiator, because the free options just work.
It’s the year of the Linux desktop, today. Next year it’s the year of Linux on Mobile.
(I’m not going to clarify how much of this post is fanaticism and how much is humor. Even I’m not sure.)
Haven’t you heard? It’s the year of the Linux desktop.
This is terrible news. I don’t think anyone can replace Google’s contributions.
We’ve had this fear about Unix and various database engines, in the past. But we managed.
time to switch to graphene or e/os?
graphene is a fork of stock android, so wouldn’t this affect them?
Yes. This hurts the GrapheneOS project. It won’t stop the project, but it makes their work harder.
It’s not like Android is especially open to drive-by contributions anyway. I don’t think really changes much for the downstream consumers of the releases.
It means my GrapheneOS updates will probably be a little slower.
And yet Graphene will still probably need more private and secure
How so? If Graphene is based off a release branch, there shouldn’t be change in timing. Sure, maybe a little for inspection, but as far as I know Graphene isn’t based off
mainanyway.How so?
- Developers routinely read along with upstream updates that are relevant to them.
- Google is removing this access.
- Google is specifically removing access to read along with upstream updates that are relevant to the developers of GrapheneOS.
At minimum, this will slow down GrapheneOS releases and increase bugs in GrapheneOS.
At worst this could cause a new malicious anti-privacy “feature” to ship with GrapheneOS because there’s no time to analyze to discover and remove it.
It’s almost like Google hates Privacy or something…
They currently get early access in some capacity, and I wonder if this would impact that.
How does this affect custom ROMs like lineageOS?
Wondering the same about GrapheneOS
Depends on how much they contribute back. Graphene has a history of contributing to AOSP, so it will make things more difficult for that, but not really for the ROM development itself. I’m not sure how Lineage is structured these days.
Platform developers, including those who build custom ROMs, will largely also see little change, since they typically base their work on specific tags or release branches, not the main AOSP branch. Similarly, companies that release forked AOSP products rarely use the main AOSP branch due to its inherent instability.
Wack. Was planning on using post market OS again soon anyways
now I’m less worried about goggle being required to sell android. this way it does not matter anymore
Why would you think it doesn’t matter?
we were worried about android being sold off because of what bad things the new owner would do with it
No way! Now I’m afraid for the future of #Android. Never trust these companies.
To summarize the article: they will deliberately open-source any updates several years later, or whenever they feel like, to ensure Stock Android is the only OS you use and new features available for people who pay Google money, which also includes security updates.
That’s not what’s implied at all. Please don’t spread misinformation
Look at the FUD getting voted to the top. This place is just as bad as Reddit.
I like turtles.
I also choose this guy’s wife.
Fuck you for assuming I’m straight
You could be a woman
Negative. I am a meat popsicle.
Well now I hate turtles and I hope the Americans bomb them. Thank you for that.
🦅🇺🇸 🚀 💥🐢😢
This is not at all a summary of the article. They’re moving to trunk-based dev to reduce merge conflicts coming in from the public on AOSP.
I don’t like it, because those few devs who contribute to AOSP without an agreement currently will have lagging code, but what you describe is just plain wrong. Is it possible? Sure. But it always has been, that doesn’t mean that’s what is happening.
Is it possible? Yes
Is it likely given Corpo take over of civilization? Also yes…
Is it possible? Sure.
Even then, not really. Not legally, anyway. Open source licences require that the user be provided with the source code (if requested) alongside the binaries. If they roll out an update to Android (to code which is under an open source licence), they have to release the code at essentially the same time. Rolling out an update and then withholding the source code for an unnecessarily long time would be against the terms of the licence.
It’s an Apache license with a contributor agreement. At any point they could close source. People could fork from it at that point, but any new features/updates/breaking changed from then out would be behind the scenes. There’s no GPL poison pill in this one, I’m afraid.
Note: I don’t at all expect this extreme of a direction.
For as long as it’s still under the Apache licence, they’re still obligated to release the source under the terms of that licence. They’d need to change the licence to stop providing code; which as you say, they could do, but that would also kill AOSP entirely overnight so is a bit of a bigger problem than the one described in the OP.
Exactly. I don’t think they’d ever go down this road, but the big players like Samsung have agreements in place where they will continue to get access to
mainor some trunk. No reason they couldn’t change license and require all players to do the same thing, though O doubt that would happen given the massive security PR implications. So many Android devices would end up with vulnerabilities, tarnishing the image.There’s also just no real incentive for them to do it. The number of devices running fully de-googled Android forks are miniscule in the grand scheme of things. Everyone running devices with non-standard Android but which still uses Google Play Services and the rest are just as valuable to Google as the ones running stock. And it suits Google to have the small ultra-privacy hobbyist market still running Android forks, even de-googled ones, rather than moving on to something else entirely.
Good clarification. It’s also worth clarifying that choosing hidden trunk based development instead of public trunk based development makes it clear that community contributions aren’t one of their priorities.
ITT: People making assumptions based off the tagline without reading the article
Basically not much changes, they’re just gonna wait to post their code until it’s done instead of letting it be viewed in progress
Meh, reasonable. Thanks for posting the clarification.
That’s a huge change. Reviewing one years’ worth of code at once is practically impossible, this significantly reduces the chances of a third party spotting malicious changes in the code.
That’s already how it functionally worked for each major release
Here’s their previous strategy: https://web.archive.org/web/20220917195332/source.android.com/docs/setup/about/codelines
Google works internally on the next version of the Android platform and framework according to the product’s needs and goals
When the n+1th version is ready, it’s published to the public source tree
The source management strategy above includes a codeline that Google keeps private to focus attention on the current public version of Android.
We recognize that many contributors disagree with this approach and we respect their points of view. However, this is the approach we feel is best and the one we’ve chosen to implement for Android.
As far as I can tell, this would really only affect QPRs, since the public experimental branches that get made after they throw the next release over the wall is going away
