Up until now, Google developed several components of Android out in the open, as part of AOSP, while developing everything else behind closed doors, only releasing the source code once the final new Android version was released. This meant that Google had to merge the two branches, which lead to problems and issues, so Google decided it’s now moving all development of Android behind closed doors.
What will change is the frequency of public source code releases for specific Android components. Some components like the build system, update engine, Bluetooth stack, Virtualization framework, and SELinux configuration are currently AOSP-first, meaning they’re developed fully in public. Most Android components like the core OS framework are primarily developed internally, although some features, such as the unlocked-only storage area API, are still developed within AOSP.
Beginning next week, all Android development will occur within Google’s internal branches, and the source code for changes will only be released when Google publishes a new branch containing those changes. As this is already the practice for most Android component changes, Google is simply consolidating its development efforts into a single branch.
↫ Mishaal Rahman at Android Authority
This brings up a very old debate: if development happens entirely behind closed doors, with only the occasional code drop, is the software in question really open source? Technically, the answer is obviously ‘yes’ – there’s no requirement that development take place in public. However, I’m fairly sure that when most people think of open source, they think not only of occasionally throwing chunks of code over the proverbial corporate walls, but also of open development, where everybody is free to contribute, pipe in, and follow along.
Clearly, this move makes Android more closed, not less so, and it follows in a long string of changes Google has made to Android that make it ever harder to consider AOSP, the Android Open Source Project, a capable, modern mobile operating system. The Android fork of the Linux kernel will always be properly open, of course, but I have my doubts Android in and of itself will remain open source in the narrow definition for much longer, and even if it does, you have to wonder how much value it will have.
I mean, Darwin, the open source base underneath macOS and iOS, is technically open source, but nobody cares because Apple made it pretty much worthless in and of itself. Anything of value is stripped out and not only developed behind closed doors, but also not released as open source, ensuring Darwin is nothing but a curiosity we sometimes remember exists. Android could be heading in the same direction.
My biggest worry are Android ROMs, most notably for me personally GrapheneOS. I honestly have no idea how this will impact such projects.
I wonder if they did a contribution analysis before making this decision, and I wonder what they found. It’s generally well known that even when something is developed “in the open” – it’s still mostly developed by a few core maintainers. It sucks that we are getting less transparency – and that kind of thing can lead to code quality drops. But given the constraints described in the summary here, it kind of makes sense. If you have a complicated, PIA process to deal with, sometimes that’s costs more than it’s worth, in terms of time, and headache.
Real world story:
“Our call-center receives very few calls, waiting times are low. The product must be working! Let’s cut the number of call-center agents – we save money, and users loose little value”
It turned out the support phone lines were simply not reachable most of the time :-O
Many users were in fact already quite dissatisfied, but had a hard time reaching support. For some, further reduction in support was the straw breaking the camel’s back.
I’m sure there’s plenty more other anecdotes about misunderstanding one’s context. A fun one is about survivorship bias and WWII british spitfire planes armouring
The key detail that is left out is whether there would still be individual commits and merged pull requests or it would be unannotated code dump once every couple of months. If the latter it will for sure raise costs and frustration maintaining community forks of AOSP leading to diminution of the overall ecosystem and major development slowdown. Only the biggest projects will survive, most one-man shows will die out soon.
I’m curious about how many of those types of commits have been submitted, and merged in the past. Like, do those individual contributors rely on those PRs getting merged upstream? Or do they just maintain their own changes on their own branches/forks?
I would say that a lot of both is happening. Almost all MIPS (yes, at some point Android supported MIPS architecture!) and large chunk of RISC-V support was contributed by people (often individual contributors, not companies) via AOSP.
And I suspect this may be the real reason something like this is happening: of course when patches are developed and submitted by Huawei and other Chinese companies you can be 100% sure these Chinese companies would have the best technology (in this particular field).
And Google (or, more likely, Trump’s government) doesn’t want that.
While this is a shame, the option of installing variant roms is incredibly limited. Most OEMs simply don’t allow it. So for the overwhelming majority, you are forced to use the locked down Android anyway.
I remember switching ROM every 6 months or so when Android first hit the scene. I don’t think I’ve even attempted it for about 6 years now..
Does it even make sense to use a custom ROM on a non-Nexus/non-Pixel device? There is always some bit of hardware that doesn’t work right with third-party ROMs.
If you want to experiment with custom ROMs, but a Pixel
*buy a Pixel (sorry)
Varies by device – some devices are 100% hardware supported by custom firmware, and the custom firmware often continues providing updates long after the vendor does. Why replace my 2018-era phone when it still works well. still gets reasonably timely security updates through LineageOS, and and a current model with very similar specs costs about the same if not more?
It’s worth noting that Google-less AOSP exists in the embedded industry (barcode scanners, delivery tracking devices etc), since those devices don’t need integration with Google services and use their own location providers, so, unlike Darwin, AOSP is an OS offered for use by itself (which is something Darwin hasn’t been since MacOS 10.4 Tiger). Not by Google directly of course, but by third parties. Still, Google has an interest in keeping Windows IoT out of that market, so it’s in their best interest to maintain AOSP open-source.
On the one hand I hope that continues to be the case (I benefit from embedded AOSP as at my workplace we use Android based barcode scanners and PDAs and I am able to customize them to our needs when necessary using the manufacturers’ SDKs). On the other hand, as a hardware enthusiast I am excited to see what the embedded Linux on RISC-V world can bring to such devices in the future. Right now RISC-V dev boards in general are slow, buggy, and lack good software support, but give the industry as a whole a reason to move away from Android/ARM and we may see rapid development in that space.
I suppose some might find this step shocking, but for me it was inevitable, as the LLMs progress more and more of a code base can be maintained by less and less people. Bringing this stuff in will be the first step to cutting development costs, I think it’s bad news for everybody.
If you think of Open Source Developers as the engine of progress you’ll be shocked, if you think the same Devs are free labour you’re not shocked at all. This move tells Devs without doubt exactly where Google think they stand!
LLMs? Maintaining with less people? Dream on! LLMs allow one to create more mess quicker, sure. But they would make the effort of maintaining said mess even harder… of course Google wouldn’t see it that way, being in the epicenter of AI hype, thus, perhaps, Google is betting on something that wouldn’t happen… wouldn’t be the first time. Remember Google+ ?
Darwin isn’t worthless. It’s just the usual bullshit where anything open source coming from Apple is usually ignored or spit on by the FOSS community. And therewere a lot of them. Apple stopped giving a fuck and now just release a big code dump for each Darwin version, which wasn’t always the case.
As for the technical merits, XNU is an interesting kernel. And I still read people complaining about systemd whereas Apple’s launchd is quite efficient. Overall, Darwin is certainly an interesting UNIX. But the community around it gave up.
To add insult to injury, Apple worked hard on Webkit but all you could read on forums was “it’s just KHTML” or, by Thom here, “Webkit will be the new IE6”. Happy now with the Chrome monopoly? So many open source projects use Webkit one way or the other.