Google Will Develop the Android OS Fully In Private 20
An anonymous reader quotes a report from Android Authority: No matter the manufacturer, every Android phone has one thing in common: its software base. Manufacturers can heavily customize the look and feel of the Android OS they ship on their Android devices, but under the hood, the core system functionality is derived from the same open-source foundation: the Android Open Source Project. After over 16 years, Google is making big changes to how it develops the open source version of Android in an effort to streamline its development. [...] 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.
This change will have minimal impact on regular users. While it streamlines Android OS development for Google, potentially affecting the speed of new version development and bug reduction, the overall effect will likely be imperceptible. Therefore, don't expect this change to accelerate OS updates for your phone. This change will also have minimal impact on most developers. App developers are unaffected, as it pertains only to platform development. 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.
External developers who enjoy reading or contributing to AOSP will likely be dismayed by this news, as it reduces their insight into Google's development efforts. Without a GMS license, contributing to Android OS development becomes more challenging, as the available code will consistently lag behind by weeks or months. This news will also make it more challenging for some developers to keep up with new Android platform changes, as they'll no longer be able to track changes in AOSP. For reporters, this change means less access to potentially revealing information, as AOSP patches often provide insights into Google's development plans. [...] Google will share more details about this change when it announces it later this week. If you're interested in learning more, be sure to keep an eye out for the announcement and new documentation on source.android.com. Android Authority's Mishaal Rahman says Google is "committed to publishing Android's source code, so this change doesn't mean that Android is becoming closed-source."
"What will change is the frequency of public source code releases for specific Android components," says Rahman. "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."
This change will have minimal impact on regular users. While it streamlines Android OS development for Google, potentially affecting the speed of new version development and bug reduction, the overall effect will likely be imperceptible. Therefore, don't expect this change to accelerate OS updates for your phone. This change will also have minimal impact on most developers. App developers are unaffected, as it pertains only to platform development. 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.
External developers who enjoy reading or contributing to AOSP will likely be dismayed by this news, as it reduces their insight into Google's development efforts. Without a GMS license, contributing to Android OS development becomes more challenging, as the available code will consistently lag behind by weeks or months. This news will also make it more challenging for some developers to keep up with new Android platform changes, as they'll no longer be able to track changes in AOSP. For reporters, this change means less access to potentially revealing information, as AOSP patches often provide insights into Google's development plans. [...] Google will share more details about this change when it announces it later this week. If you're interested in learning more, be sure to keep an eye out for the announcement and new documentation on source.android.com. Android Authority's Mishaal Rahman says Google is "committed to publishing Android's source code, so this change doesn't mean that Android is becoming closed-source."
"What will change is the frequency of public source code releases for specific Android components," says Rahman. "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."
And then.... (Score:3)
Will be rewritten rust embedded in go.....
[Yawn] (Score:3)
This news will also make it more challenging for some developers to keep up with new Android platform change
We'll release our new version for iOS right away. The Android version, ... whenever we get around tuit.
Re: (Score:2)
This news will also make it more challenging for some developers to keep up with new Android platform change
We'll release our new version for iOS right away. The Android version, ... whenever we get around tuit.
Are you saying this announcement has an effect on that, or that it's what you do anyway?
Re: (Score:2)
Are you saying this announcement has an effect on that
Hypothetically*, yes. I'd sit on my hands if one platform holds back information that might help me support it.
*Actually, I don't write apps for fondle toys.
Re: (Score:1)
Are you saying this announcement has an effect on that
Hypothetically*, yes. I'd sit on my hands if one platform holds back information that might help me support it.
Well, this change puts Android and iOS on the same footing that way, then. Because iOS never provided the visibility that Android is no longer going to provide.
This makes me sad (Score:5, Informative)
I'm an Android OS engineer (at Google) and this makes me sad. As the summary says, it won't have any practical impact on, well, pretty much anyone outside of Google. But there are a number of Android subprojects, including all of mine, which have been developed directly in AOSP for years because the engineers involved believe that there are strong philosophical reasons for them to be developed in public, where anyone who wants can see the changes as they happen. Probably no one ever actually bothers to watch (other than guys like Mishaal), but it still seems right to build security and privacy-relevant components in public.
I understand the rationale for this change, and I can't disagree with it. The infrastructure team has been maintaining a ridiculously complex set of automergers to make development in both AOSP and internal work, plus a whole redundant set of continuous integration and test servers and device farms. I've been amazed for years that the automerger infrastructure even works. There's an internal tool that shows the whole web of repositories and how changes automatically flow through the graph, and if you zoom out enough to fit the whole thing on a 30" screen, the text is too small to read. Ending merging from AOSP will hugely simplify that.
But even though it makes good, pragmatic engineering sense not to carry this large and arguably artificial extra burden, I still really feel like the stuff I build should be built in public. I mean, it'll get there eventually anyway, and in the decade I've been doing this I've never seen any actual benefit from working in public (e.g. no one outside of Google has ever contacted me to point out some issue with my latest change). But, still.
I know a few Android teams feel strongly enough about it that they're discussing moving development to Github, just to keep it public. I'm not sure if they're planning on manually merging everything from there into Android, or if they're going to set up their own automergers. I'm not doing that, for my stuff, though. Too much overhead. My stuff is just going to start being released in quarterly chunks.
Oh, the summary should probably have mentioned that: Android has already switched from an annual release cycle (sometimes with mid-year updates) to a quarterly cycle. So the public repository will only lag by a little more than three months.
Re:This makes me sad (Score:5, Interesting)
in the decade I've been doing this I've never seen any actual benefit from working in public (e.g. no one outside of Google has ever contacted me to point out some issue with my latest change).
I can explain that. I fixed a number of bugs in ADB several years back, making the connection more stable, and tried to contribute them back. I couldn't figure out the process for doing so, and couldn't get into contact with anyone at Google.
Eventually I just gave up and maintained a local fork for my company, merging any changes Google made. That was less effort than trying to get the fixes added upstream.
Re:This makes me sad (Score:5, Informative)
in the decade I've been doing this I've never seen any actual benefit from working in public (e.g. no one outside of Google has ever contacted me to point out some issue with my latest change).
I can explain that. I fixed a number of bugs in ADB several years back, making the connection more stable, and tried to contribute them back. I couldn't figure out the process for doing so, and couldn't get into contact with anyone at Google.
I wasn't talking about contributions, though this new model may make those impossible. I did get a few external contributions over the years.
FWIW, the contribution process is pretty simple. Just go to https://android-review.googles... [googlesource.com] (easy to find with a web search), log in with any Google account (e.g. gmail), sign the CLA, then upload your commits for review. There is some documentation for this, though I'm feeling too lazy to find it. Of course, it's possible that your commits may sit there unreviewed for a very long time since you wouldn't know who to poke, but usually whoever is responsible for that part of the codebase will notice and look at them.
Of course, this does you no good now. Well, maybe. It's possible that AOSP Gerrit will stay alive just for external contributions. I have no idea.
Re: (Score:2)
Well, thanks for your dedication to the open source community development model (even when it feels more theoretical than actual because few or no external people help out).
To me it does seem like a significant step away from collaboration (or potential collaboration) more towards the Netgear model of "here's some tarballs we're GPL compliant now" (https://kb.netgear.com/2649/NETGEAR-Open-Source-Code-for-Programmers-GPL).
from TFA and reading their article about moving to what they label "trunk based develo
Re: (Score:3)
from TFA and reading their article about moving to what they label "trunk based development" (https://www.androidauthority.com/android-trunk-stable-explained-3495640/ ) it sounds like android dev has fewer long lived feature branches but instead everything's going to be checked in to trunk but hidden behind (build time?) feature flags with this "aconfig" thing.
Yeah, except that Android never really did feature branches in the main repos. There were feature branches on engineers' machines, obviously.
So then doing the development in public would mean that upcoming or experimental work would be revealed publicly
Nah, work that needed to be kept out of the public eye was just done on the internal repo. In fact, that's where nearly all Android development is done. The "AOSP first" projects have always been the exception, not the rule.
[BTW i'm a little skeptical about that one picture that says all branches are merged to trunk every day... is that for real ? ]
Not "every day"... continuously. As soon as your change is merged, the automerger starts trying to merge it into the downstream branches.
The au
Re: This makes me sad (Score:2)
Isnâ(TM)t this mostly just in response to Huawei dropping out of Android OS development with HarmonyOS?
I feel as though developers like yourself are in the minority, unfortunately.
Re: This makes me sad (Score:1)
They dropped out? Iinm, they were pushed out by sinophobic politicians in the US government.
Re: (Score:2)
Isnâ(TM)t this mostly just in response to Huawei dropping out of Android OS development with HarmonyOS?
I don't think there's any connection at all.
I feel as though developers like yourself are in the minority, unfortunately.
I think most feature work actually needs to be done internally, and that security and privacy-focused projects like the ones I mostly work on, and which I think should be done in public, are the exception.
Re: (Score:2)
Is there any reason why they don't just sync the public repository daily?
Re: (Score:2)
Is there any reason why they don't just sync the public repository daily?
A lot of feature work is secret until release, for competitive reasons.
Android is a mess anyway (Score:2)
It is absurd there are still cooks baking device specific OS images. The update cadence is already too fast and disruptive for what is now a mature technology. Sort of the end user equivalence of running production services on Fedora only the image is built specifically for every possible combination of motherboard and processors.
The notion of constantly buying new gear to get new versions and rapid abandonment of prior versions is a massive global waste of time and resources.
Just another China embargo (Score:2)
Considering that all this does is oust commits from Chinese companies, who were the majority contributors to Android, this seems like a national security move.
Iâ(TM)m rather surprised that they didnâ(TM)t do this five or ten years ago, but i suppose that since the majority of android phones are from Chinese owned companies, i suppose it makes sense.
Re: Just another China embargo (Score:1)
Yup, if this isn't being forced on them behind the scenes from politicians, then some have simply seen the writing on the wall and are making moves towards closing it all.
I guess most of the Chinese companies are doing likewise, but in the opposite direction - ie maintaining their own forks, or switching to FOSS OSes developed in the free world (from their perspective, ie not the USA).
Re: (Score:2)
They want the cudos and exposure to the public that comes from saying "download it, it's free, and it's safe because you can read the source". This brings in customers who otherwise wouldn't look twice at the product, and probably wouldn't pay to look once.
The game of open source branded software today is about economic dumping. Free s
Trying to kill Custom ROMs? (Score:3)
Now custom ROMs can only start the work on supporting a new version after it is out. They will always be a version late.