Delayed Security Patches for AOSP (Android Open Source Project)(twitter.com)
twitter.com
Delayed Security Patches for AOSP (Android Open Source Project)
https://twitter.com/grapheneos/status/1964561043906048183
115 comments
Security patches aren't being delayed for AOSP specifically but rather Android as a whole including the stock Pixel OS. The title is misinterpreting our reply. We didn't say they're delaying patches to AOSP specifically. Stock Pixel OS has delayed patches too.
A more detailed explanation is at https://x.com/GrapheneOS/status/1964754118653952027.
GrapheneOS has an OEM partner and early access to the security patches so our complaint isn't about us not having access. Google has added an exception to the embargo where binary-only patches can be released which we could use for a special security update branch but that's a ridiculous exception and it should be allowed to release the sources. It can be reversed from the security patches anyway and is trivial for Java and Kotlin. We can't break the embargo ourselves but we CAN publish the security patches early under the rules of the embargo via a special branch and people could reverse the patches from there which could then be applied to the regular GrapheneOS branch. The system is ridiculous and our hope is these changes are undone.
The title should really be changed from "for AOSP" to "for Android". There's a binary-only exception in the embargo now but that's not really about AOSP and isn't being used in practice even for Pixels. They've really just delayed all patches 4 months instead of 1 while also destroying any semblance of there being a real embargo (which was already very weak).
A more detailed explanation is at https://x.com/GrapheneOS/status/1964754118653952027.
GrapheneOS has an OEM partner and early access to the security patches so our complaint isn't about us not having access. Google has added an exception to the embargo where binary-only patches can be released which we could use for a special security update branch but that's a ridiculous exception and it should be allowed to release the sources. It can be reversed from the security patches anyway and is trivial for Java and Kotlin. We can't break the embargo ourselves but we CAN publish the security patches early under the rules of the embargo via a special branch and people could reverse the patches from there which could then be applied to the regular GrapheneOS branch. The system is ridiculous and our hope is these changes are undone.
The title should really be changed from "for AOSP" to "for Android". There's a binary-only exception in the embargo now but that's not really about AOSP and isn't being used in practice even for Pixels. They've really just delayed all patches 4 months instead of 1 while also destroying any semblance of there being a real embargo (which was already very weak).
Thanks for the clarification. Delaying patches for all Android is even worse than delaying for AOSP. Excerpts below.
.. Google recently made.. misguided changes to Android security updates.. almost entirely quarterly instead of monthly to make it easier for OEMs. They're giving OEMs 3-4 months of early access which we know for a fact is being widely leaked including to attackers.
.. Google's existing system for distributing security patches to OEMs was already.. problematic. Extending 1 month of early access to 4 months is atrocious. This applies to all of the patches in the bulletins. This is harming Android security to make OEMs look better by lowering the bar.. The existing system should have been moving towards shorter broad disclosure of patches instead of 30 days.
.. Android's management has clearly overruled the concerns of their security team and chosen to significantly harm Android security for marketing reasons.. Android is very understaffed due to layoffs/buyouts and insufficient hiring.. Google does a massive portion of the security work on the Linux kernel, LLVM and other projects.. providing the resources and infrastructure for Linux kernel LTS releases. Others aren't stepping up to the plate.
[deleted]
Just a year prior, I would have been against a decision to force Google to part with either Android or Chrome.
Now, I'm of the opinion that they should have been forced to sell off both, and maybe Chromebooks too, for the good measure.
No company with a direction as vile and openly user-hostile as what Google currently demonstrates should have anywhere near this level of control over the ecosystem.
Now, I'm of the opinion that they should have been forced to sell off both, and maybe Chromebooks too, for the good measure.
No company with a direction as vile and openly user-hostile as what Google currently demonstrates should have anywhere near this level of control over the ecosystem.
They should lose YouTube as well. Remember how they used their control over YouTube to kill Windows Phone back in the day also. They should have lost it right then.
Google is very clearly an abusive monopoly, and has been for a very long time. We all overlooked it because they were mostly benevolent. That is no longer the case.
Google is very clearly an abusive monopoly, and has been for a very long time. We all overlooked it because they were mostly benevolent. That is no longer the case.
> YouTube to kill Windows Phone back in the day also.
I hope you're not referring to YouTube blocking the 3rd party YT Windows Phone client that didn't play or display ads? At the time, Microsoft was threatening Android OEMs with patent infringement (without disclosing the specific patents!), and making it go away if they agreed to make Windows phone models[1]. Google refusing to make a first-party YouTube client for Windows Phone was to be expected, it was an ugly, hand-to-hand fight and all parties used the weapons they had at hand.
1. The agreements were never made public, but HTC and Samsung disclosed they'd be making Windows phones in their respective agreements with Microsoft. Microsoft also initially filed an Amicus brief in Google v Oracle - supporting Oracle's position.
I hope you're not referring to YouTube blocking the 3rd party YT Windows Phone client that didn't play or display ads? At the time, Microsoft was threatening Android OEMs with patent infringement (without disclosing the specific patents!), and making it go away if they agreed to make Windows phone models[1]. Google refusing to make a first-party YouTube client for Windows Phone was to be expected, it was an ugly, hand-to-hand fight and all parties used the weapons they had at hand.
1. The agreements were never made public, but HTC and Samsung disclosed they'd be making Windows phones in their respective agreements with Microsoft. Microsoft also initially filed an Amicus brief in Google v Oracle - supporting Oracle's position.
The sad thing is I think Google keeping Chrome is actually likely the better of two possible bad outcomes... Anyone else interested and willing to pay the true value of owning the entire Internet ecosystem is almost certainly going to look to extract value from that, and that's almost certainly worse than what Google does today. E.g. using everyone's browser to extract training data for AI without getting IP blocked.
A year or so ago, I would have agreed. Not anymore.
Sure, a company can buy Chrome and proceed to sell user browsing habits data to the highest bidder, or use it as a backbone for decentralized scraping - backed by real user data and real residential IPs to fool most anti-scraping checks. But if they fuck with users enough, Chrome would just die off over time, and Firefox or various Chromium forks like Brave would take its place. This already happened to the browsing titan that was IE, and without the entire power of Google to push Chrome? It can happen again.
The alternative is Google owning Chrome for eternity - and proceeding with the most damaging initiatives possible. Right now, Google is seeking to destroy adblocking, tighten the control over the ad data ecosystem to undermine their competitors, and who knows what else they'll come up with next week.
Sure, a company can buy Chrome and proceed to sell user browsing habits data to the highest bidder, or use it as a backbone for decentralized scraping - backed by real user data and real residential IPs to fool most anti-scraping checks. But if they fuck with users enough, Chrome would just die off over time, and Firefox or various Chromium forks like Brave would take its place. This already happened to the browsing titan that was IE, and without the entire power of Google to push Chrome? It can happen again.
The alternative is Google owning Chrome for eternity - and proceeding with the most damaging initiatives possible. Right now, Google is seeking to destroy adblocking, tighten the control over the ad data ecosystem to undermine their competitors, and who knows what else they'll come up with next week.
Why do suppose Chrome would die off for user-hostile actions under a non-Google entity (2nd paragraph), but not while being controlled by Google (3rd paragraph)?
Not the OP, but Google spent years advertising Chrome front and center on the Internet's most visited pages. Money doesn't buy that kind of real estate, ownership does.
OP, agreed.
Prior to Chrome, Google actually used to promote Firefox on its own pages instead - which was a major driver of Firefox adoption. Google did it because they had a partnership with Mozilla, and were very much in favor of users switching to a browser that's not Internet Explorer.
Then Google decided they wanted more control over Firefox. Mozilla decided that Google isn't going to get it. This resulted in Chrome.
Firefox was evicted from Google's promotion, and it never quite recovered.
Prior to Chrome, Google actually used to promote Firefox on its own pages instead - which was a major driver of Firefox adoption. Google did it because they had a partnership with Mozilla, and were very much in favor of users switching to a browser that's not Internet Explorer.
Then Google decided they wanted more control over Firefox. Mozilla decided that Google isn't going to get it. This resulted in Chrome.
Firefox was evicted from Google's promotion, and it never quite recovered.
> Money doesn't buy that kind of real estate, ownership does.
If this is the reason, the remedy doesn't attack the root of the matter. If Chrome were unbundled from Google, what's to stop Google from creating a new Chromium fork - and naming it Cobalt and marketing the hell out of it to achieve the same market share?
If this is the reason, the remedy doesn't attack the root of the matter. If Chrome were unbundled from Google, what's to stop Google from creating a new Chromium fork - and naming it Cobalt and marketing the hell out of it to achieve the same market share?
Antitrust orders are more complicated than just declaring a business unit spontaneously independent. They usually include provisions to ensure the the situation is actually fixed, like prohibitions on the parent competing in that entire market and financial/infrastructure support for the new companies on their transition to independence.
Are you able to share a case when an American court issued such a broad order on a F100 company? There was a stronger case for breaking up Microsoft, but the DoJ shied from that remedy, there was never a chance that Google could have been broken up in this case, IMO.
Split it to a point where no one company can own the entire Internet ecosystem. Apply antitrust laws to keep it like this.
Maybe the development will slow down, but let's be honest: we would still be fine if Android and iOS had stopped "improving" years ago. Now it's mostly about adding shiny AI features and squeeze the users.
Maybe the development will slow down, but let's be honest: we would still be fine if Android and iOS had stopped "improving" years ago. Now it's mostly about adding shiny AI features and squeeze the users.
>Split it to a point where no one company can own the entire Internet ecosystem. Apply antitrust laws to keep it like this.
Facebook was once small too. Yet people happily signed up, giving up their privacy in the process. What makes you think the remaining companies offering a free browser wouldn't try to monetize users in a similar way? How many people are willing to pay $5/month for a browser?
Facebook was once small too. Yet people happily signed up, giving up their privacy in the process. What makes you think the remaining companies offering a free browser wouldn't try to monetize users in a similar way? How many people are willing to pay $5/month for a browser?
> Yet people happily signed up, giving up their privacy in the process.
When Facebook started, it was a different era. And since then, Facebook has clearly abused their position with anti-competitive behaviours.
> How many people are willing to pay $5/month for a browser?
If they can keep using Google Chrome for free, we already know the answer. If the only way for them to have a reasonable browser would to pay... who knows? People pay more than that to access movies that they could download as torrents.
Also does it have to be 5$ per month? Do browsers need to keep adding so many features, and hence so many bugs and security issues, that only huge companies can keep up and nobody wants to pay for that work?
Maybe it's enough to pay 1$/year for a company to maintain a reasonably secure browser with the features that people actually need. Do people actually need QUIC? Not sure.
When Facebook started, it was a different era. And since then, Facebook has clearly abused their position with anti-competitive behaviours.
> How many people are willing to pay $5/month for a browser?
If they can keep using Google Chrome for free, we already know the answer. If the only way for them to have a reasonable browser would to pay... who knows? People pay more than that to access movies that they could download as torrents.
Also does it have to be 5$ per month? Do browsers need to keep adding so many features, and hence so many bugs and security issues, that only huge companies can keep up and nobody wants to pay for that work?
Maybe it's enough to pay 1$/year for a company to maintain a reasonably secure browser with the features that people actually need. Do people actually need QUIC? Not sure.
>When Facebook started, it was a different era. And since then, Facebook has clearly abused their position with anti-competitive behaviours.
Insurgents like tiktok show that even today, people will happily give up their privacy for some dopamine.
>If they can keep using Google Chrome for free, we already know the answer.
Why would google continue maintaining chrome if they can no longer derive any benefit from it?
>If the only way for them to have a reasonable browser would to pay... who knows? People pay more than that to access movies that they could download as torrents.
No, the contention is that people will go for free browsers that violate their privacy or monetize them somehow, not some future where all browsers cost money.
>Maybe it's enough to pay 1$/year for a company to maintain a reasonably secure browser with the features that people actually need. Do people actually need QUIC? Not sure.
Remember when whatsapp was also $1/year, ostensibly for similar reasons? How did that go?
Insurgents like tiktok show that even today, people will happily give up their privacy for some dopamine.
>If they can keep using Google Chrome for free, we already know the answer.
Why would google continue maintaining chrome if they can no longer derive any benefit from it?
>If the only way for them to have a reasonable browser would to pay... who knows? People pay more than that to access movies that they could download as torrents.
No, the contention is that people will go for free browsers that violate their privacy or monetize them somehow, not some future where all browsers cost money.
>Maybe it's enough to pay 1$/year for a company to maintain a reasonably secure browser with the features that people actually need. Do people actually need QUIC? Not sure.
Remember when whatsapp was also $1/year, ostensibly for similar reasons? How did that go?
> Why would google continue maintaining chrome if they can no longer derive any benefit from it?
That is unrelated to the sentence you quote: if people can use Google Chrome for free, they don't pay for a browser. But if Chrome disappeared, they would still need a browser. Maybe they would pay if they didn't have a free choice?
> No, the contention is that people will go for free browsers that violate their privacy or monetize them somehow, not some future where all browsers cost money.
If there are more browsers instead of a monopoly, then websites will work on the paid, secure browser that I will use, so I'm happy. I don't want to prevent people from using bad software: I want to make it possible for companies to build good software.
By not using Chromium today, many times the websites don't work correctly because devs don't care, because Chromium is a monopoly. I say split it! Then websites will have to work on more than 1 browser.
> Remember when whatsapp was also $1/year, ostensibly for similar reasons? How did that go?
It was a huge success? WhatsApp is still a huge success.
That is unrelated to the sentence you quote: if people can use Google Chrome for free, they don't pay for a browser. But if Chrome disappeared, they would still need a browser. Maybe they would pay if they didn't have a free choice?
> No, the contention is that people will go for free browsers that violate their privacy or monetize them somehow, not some future where all browsers cost money.
If there are more browsers instead of a monopoly, then websites will work on the paid, secure browser that I will use, so I'm happy. I don't want to prevent people from using bad software: I want to make it possible for companies to build good software.
By not using Chromium today, many times the websites don't work correctly because devs don't care, because Chromium is a monopoly. I say split it! Then websites will have to work on more than 1 browser.
> Remember when whatsapp was also $1/year, ostensibly for similar reasons? How did that go?
It was a huge success? WhatsApp is still a huge success.
Browsers should be classified as critical infrastructure and be run by NPOs or PBCs. There’d be no need for end users to pay anything if the tens of thousands of companies all relying on the web chipped in to sustain the infrastructure that allows them to exist and be profitable.
I wonder if Android and Chrome would support open source even less as independent companies though.
Why not spin them each off into an independent non-profit?
Because people don't just throw away money.
Non-profits can make a lot of money, they just have to reinvest said money back into capital, labor, or R&D. Non-profits can absolutely charge a license as well, if they want. You can do that with OSS, too. Just make it GPL and then charge for a more generous license like Qt does.
Of course they don't. But the courts/government should force them to do so in this case. If the company or its shareholders need to be compensated then so be it. Better to pay them off and get Android and Chrome out of their hands before they can cause further damage.
And by destroying the Android development team you'd achieve what exactly? Magical appearance of the security patches you're complaining about here?
Would you start to actually pay for all those hundreds of engineers maintaining the OS?
Would you start to actually pay for all those hundreds of engineers maintaining the OS?
Either the new company takes over maintaining Android, or it fumbles the bag and the development becomes less centralized for a while - until some leader emerges and takes over.
Either way, the new control center of Android wouldn't be Google. A decade ago, I would have seen that as a very bad thing. Now, I'm almost certain that this would be a change for the better. Google is not what it once was.
Either way, the new control center of Android wouldn't be Google. A decade ago, I would have seen that as a very bad thing. Now, I'm almost certain that this would be a change for the better. Google is not what it once was.
Or a more likely scenario is that Apple picks up even more market share, and we go from a duopoly to a monopoly.
Well, there is barely any new Android feature worth talking about for the past three years (no, new skins definitely don't count). I seriously doubt there is going to be any change in the market share if Android were controlled by a different company. We would have already seen that by now.
Drone manufacturers like Samsung, Xiaomi etc need an OS. Right now it's more profitable for them to just pay licences to Google. But if Google lost Android... they would need to find a solution.
I would like to see this, at least something would be happening.
I would like to see this, at least something would be happening.
I could see sort of an Android consortium taking over developing it and keeping it going outside of Google. Samsung, Oppo, Xiaomi, Huwawei, Motorola, etc.
Honestly it'd probably be better off that way. Google has far too much influence and control.
Honestly it'd probably be better off that way. Google has far too much influence and control.
None of those companies have a tiny little bit of interest of helping their competitors with joint development. I guess you're too young to remember the balkanization of Symbian among such companies?
Those are companies, their only interest is to maximise profit. Apparently right now the most profitable is to pay Google for the Android licence.
Huawei found themselves on their own because of the ban, and decided to go for HarmonyOS NEXT. Probably they wouldn't come back to a "joint development AOSP" now.
Now if Google lost Android, what would happen for the others? Would they each try their luck with their own OS or would they try to go for a joint development?
Huawei found themselves on their own because of the ban, and decided to go for HarmonyOS NEXT. Probably they wouldn't come back to a "joint development AOSP" now.
Now if Google lost Android, what would happen for the others? Would they each try their luck with their own OS or would they try to go for a joint development?
Yep. If we’re gonna be forking browsers, Firefox should be the base, not Chromium. Mozilla is in much less of a position to abuse their position, and more Firefox forks means more chances that one catches on with some slice of the larger public and helps chip away at Blink hegemony.
Fully agreed. I am however worried by the fact that Firefox is basically kept alive by Google. I assume it's just so that they can pretend Chrome isn't a monopoly, but the minute Firefox becomes an inconvenience they can stop financing it. I hope we can find a way for Firefox to sustain itself long term.
It’s a valid concern, and it may not be possible to properly address so long as Mozilla in its current form continues to be the controlling party of Firefox/Gecko. The best scenario might actually be for Mozilla to collapse and some other NPO or PBC with better financial sense to pick up the projects and their engineers.
Google pays Firefox for traffic acquisition, not out of pity. If Google stopped paying, another search engine like Bing or Perplexity would be happy to take over.
True, but what happens when Firefox's marketshare decreases to the point where the amount of traffic lost by not having the Google deal stops mattering to Google?
If Google does the math one day, and determines that they won't lose out anymore by not paying Firefox they'll stop paying.
If Google does the math one day, and determines that they won't lose out anymore by not paying Firefox they'll stop paying.
It's revenue share based, so the cost to google is the time it takes to renew the deal. This is a fixed cost that doesn't depend on the market share of Firefox.
Last time I suggested brave on hn to base off on Firefox and they said its pita but we have unpaid.volunteer run waterfox and others, then we have floorp, tor and others so I know for a fact brave not basing on Firefox is pure politics because of brendan
> This is all the more likely now that Google has been emboldened by not having to sell off Chrome for anticompetitive reasons.
Exactly. The only thing that can prevent this behaviour is regulations. But apparently nobody wants to regulate, so we're screwed.
Exactly. The only thing that can prevent this behaviour is regulations. But apparently nobody wants to regulate, so we're screwed.
FYI the poster this story links to says that this title is incorrect:
https://x.com/grapheneos/status/1964757878910136346?s=46
They say this:
Our reply here was linked on Hacker News with an inaccurate title ("Delayed Security Patches for AOSP"). Security patch backports were pushed to AOSP on September 2nd for Android 13, 14 and 15 as expected.
More information is available at x.com/GrapheneOS/sta… explaining the situation with security patches. It would be better to have a thread linking to that instead. We have early access to the security patches, but we can't break the embargo. We can only release the sources once source release is allowed. We could make a security preview branch but the system simply doesn't make sense.
Android 16 QPR1 is a new major release, not a security patch release. Our reply is talking about 2 different issues. Android 16 QPR1 is what was delayed for AOSP and we don't currently know why. It's possible it was a mistake and it will be pushed on Monday.
https://x.com/grapheneos/status/1964757878910136346?s=46
They say this:
Our reply here was linked on Hacker News with an inaccurate title ("Delayed Security Patches for AOSP"). Security patch backports were pushed to AOSP on September 2nd for Android 13, 14 and 15 as expected.
More information is available at x.com/GrapheneOS/sta… explaining the situation with security patches. It would be better to have a thread linking to that instead. We have early access to the security patches, but we can't break the embargo. We can only release the sources once source release is allowed. We could make a security preview branch but the system simply doesn't make sense.
Android 16 QPR1 is a new major release, not a security patch release. Our reply is talking about 2 different issues. Android 16 QPR1 is what was delayed for AOSP and we don't currently know why. It's possible it was a mistake and it will be pushed on Monday.
Thanks for the clarification. 90 day embargo of patches for all Android is worse than delaying for AOSP, https://news.ycombinator.com/item?id=45158523#45161240
They're giving OEMs 3-4 months of early access which we know for a fact is being widely leaked including to attackers.X cut off the link you copied within our reply. Here's that link along with 2 alternatives other than X:
https://x.com/GrapheneOS/status/1964754118653952027
https://bsky.app/profile/grapheneos.org/post/3lyb6rx46tc2r
https://grapheneos.social/@GrapheneOS/115164133992525834
https://x.com/GrapheneOS/status/1964754118653952027
https://bsky.app/profile/grapheneos.org/post/3lyb6rx46tc2r
https://grapheneos.social/@GrapheneOS/115164133992525834
"No tags were pushed to AOSP for the July 2025 monthly release of Android. We asked about this on the android-building group but each of our posts was rejected. We emailed people at Google we've previously contacted about mistakes pushing tags but received no response this time."
https://xcancel.com/GrapheneOS/status/1952413110947430786
"July monthly release was not pushed to AOSP and then neither was the August monthly release. September quarterly release hasn't been pushed yet."
https://xcancel.com/GrapheneOS/status/1963812920673861981
https://xcancel.com/GrapheneOS/status/1952413110947430786
"July monthly release was not pushed to AOSP and then neither was the August monthly release. September quarterly release hasn't been pushed yet."
https://xcancel.com/GrapheneOS/status/1963812920673861981
That's about the monthly and quarterly releases of Android, not the Android security patches. The post title is misinterpreting what's wrong. There is a lot wrong but that's not it. The baseline Android security patches are being delayed for Android as a whole, not AOSP specifically.
Not having the very tiny monthly updates pushed to AOSP is an annoyance which will delay a subset of non-security bug fixes until the quarterly releases. It's a bad change, although we know have a good idea why it happened and need the reason it happened to be reversed for them to push those again.
We've been told by multiple people at Google that the quarterly releases would still be pushed and that monthly releases are largely being phased out. However, the quarterly update was not pushed as expected on September 3rd. If it's pushed on Monday, it will be 6 days late. There hasn't been a similar delay for quarterly and yearly releases in the past.
GrapheneOS can still provide security updates but not having the quarterly release is a major problem and it's not clear why it wasn't pushed when they said it was going to be pushed.
There's a separate issue not specifically tied to AOSP impacting security patches which is what the initial part of our reply was about. See https://x.com/GrapheneOS/status/1964754118653952027 for an explanation.
Not having the very tiny monthly updates pushed to AOSP is an annoyance which will delay a subset of non-security bug fixes until the quarterly releases. It's a bad change, although we know have a good idea why it happened and need the reason it happened to be reversed for them to push those again.
We've been told by multiple people at Google that the quarterly releases would still be pushed and that monthly releases are largely being phased out. However, the quarterly update was not pushed as expected on September 3rd. If it's pushed on Monday, it will be 6 days late. There hasn't been a similar delay for quarterly and yearly releases in the past.
GrapheneOS can still provide security updates but not having the quarterly release is a major problem and it's not clear why it wasn't pushed when they said it was going to be pushed.
There's a separate issue not specifically tied to AOSP impacting security patches which is what the initial part of our reply was about. See https://x.com/GrapheneOS/status/1964754118653952027 for an explanation.
Serious question: do we know as a matter of fact that iOS and family are safer than Android, including Pixel, especially when it comes to 0-day exploits?
No, but Google has significantly downgraded security from it used to be and Apple isn't sharing security patches very broadly outside their company 4 months ahead of fixing them. They don't have partners to share it with. That's not to say there aren't people in the company leaking them but they likely don't take that long to fix most patches. We considered the Pixel stock OS largely competitive with iOS on security but recent changes including but not limited to this are changing our mind. Both the Linux kernel and Google with Android are doing a horrific job with security. Apple has their own issues but it's not this embarrassingly bad and getting consistently better. Google could easily provide strong security for Pixels and AOSP but is downgrading them to appease OEMs failing to keep up with the previous already bare minimum patch system they were expected to follow.
An issue reported to Google 3 months ago and fixed today would likely get disclosed to partners around November 2025 or December 2025 and then officially fixed in March 2025. It's not just 1 month of early access for OEM partners now but rather around 4 months. Patches are artificially delayed beyond the time to fix them by 4 months. This is completely ridiculous. Google also doesn't control the patch releases for many projects such as the Linux kernel and many other external projects they use. This means they're always going to be at least around 4 months behind on including a small number of patches for those projects as mandatory to fix for Android OEMs. The bar for Android OEMs was already ridiculously low and they've made it far lower. It's dragging down the Pixel stock OS with it to a significant extent.
Google realizes this system is horrible and has therefore added a binary-only exception to the embargo which is a complete joke since they know it's easy to reverse the patches. However, it's not really being used in practice. It's just an option to ship binary-only patches without the long delay now. We have this option for GrapheneOS since we do have access to the partner bulletins via an OEM partner. We could also ask our OEM partner not to share them with us and instead obtain them another way with no NDA to publish them right away. We haven't asked for the December patches yet since we haven't decided how to handle it. The current embargo would allow us to publish a special delayed source release variant of GrapheneOS this month with December 2025 patches, but we want to provide source code for all our releases and do not want to have a special variant of the OS needed for the latest Android patches. With how broadly they've distributed the December 2025 patches, they can't seriously be considered private and it should be permitted to simply ship them now.
Android's partner licensing people are destroying the security work. Play Integrity API is similar pretend security actually just enforcing Google's partner licensing model while actually disallowing using much more secure devices. That's highly anti-competitive and so is what they're doing with security patches. Both should result in substantial regulatory action against them, and perhaps it will, but it will probably come a very long time from now when the damage is done.
An issue reported to Google 3 months ago and fixed today would likely get disclosed to partners around November 2025 or December 2025 and then officially fixed in March 2025. It's not just 1 month of early access for OEM partners now but rather around 4 months. Patches are artificially delayed beyond the time to fix them by 4 months. This is completely ridiculous. Google also doesn't control the patch releases for many projects such as the Linux kernel and many other external projects they use. This means they're always going to be at least around 4 months behind on including a small number of patches for those projects as mandatory to fix for Android OEMs. The bar for Android OEMs was already ridiculously low and they've made it far lower. It's dragging down the Pixel stock OS with it to a significant extent.
Google realizes this system is horrible and has therefore added a binary-only exception to the embargo which is a complete joke since they know it's easy to reverse the patches. However, it's not really being used in practice. It's just an option to ship binary-only patches without the long delay now. We have this option for GrapheneOS since we do have access to the partner bulletins via an OEM partner. We could also ask our OEM partner not to share them with us and instead obtain them another way with no NDA to publish them right away. We haven't asked for the December patches yet since we haven't decided how to handle it. The current embargo would allow us to publish a special delayed source release variant of GrapheneOS this month with December 2025 patches, but we want to provide source code for all our releases and do not want to have a special variant of the OS needed for the latest Android patches. With how broadly they've distributed the December 2025 patches, they can't seriously be considered private and it should be permitted to simply ship them now.
Android's partner licensing people are destroying the security work. Play Integrity API is similar pretend security actually just enforcing Google's partner licensing model while actually disallowing using much more secure devices. That's highly anti-competitive and so is what they're doing with security patches. Both should result in substantial regulatory action against them, and perhaps it will, but it will probably come a very long time from now when the damage is done.
This is an official response from GrapheneOS:
The title of this post linking our reply is inaccurate and is not what we said ("Delayed Security Patches for AOSP"). It should really be changed from "for AOSP" to "for Android". Security patch backports were pushed to AOSP on September 2nd for Android 13, 14 and 15 as expected. The issue isn't the security patches being delayed for AOSP. We didn't say patches are being delayed for AOSP.
Security patches for Android are being delayed as a whole. The delays aren't specific to AOSP. They're moving to quarterly security updates with 4 months of early OEM access instead of monthly security updates with 1 month of early OEM access. They realize that the patches distributed to OEMs are hardly secret once they're so broadly distributed. Therefore, they've relaxed the rules of the embargo and permitted releases of patches under certain rules without being allowed to providing a description or the sources for the patch. This is ridiculous because it's easy to reverse the patches from binary-only releases.
Google trying to cover for OEMs not keeping up with patches by making it seem as if the patches are now quarterly and largely being delivered on time while actually broadly disclosing them 4 months early and permitting quietly fixing them early.
We posted a much more detailed explanation at https://x.com/GrapheneOS/status/1964754118653952027. It would be better to link to our more detailed post.
The title of this post linking our reply is inaccurate and is not what we said ("Delayed Security Patches for AOSP"). It should really be changed from "for AOSP" to "for Android". Security patch backports were pushed to AOSP on September 2nd for Android 13, 14 and 15 as expected. The issue isn't the security patches being delayed for AOSP. We didn't say patches are being delayed for AOSP.
Security patches for Android are being delayed as a whole. The delays aren't specific to AOSP. They're moving to quarterly security updates with 4 months of early OEM access instead of monthly security updates with 1 month of early OEM access. They realize that the patches distributed to OEMs are hardly secret once they're so broadly distributed. Therefore, they've relaxed the rules of the embargo and permitted releases of patches under certain rules without being allowed to providing a description or the sources for the patch. This is ridiculous because it's easy to reverse the patches from binary-only releases.
Google trying to cover for OEMs not keeping up with patches by making it seem as if the patches are now quarterly and largely being delivered on time while actually broadly disclosing them 4 months early and permitting quietly fixing them early.
We posted a much more detailed explanation at https://x.com/GrapheneOS/status/1964754118653952027. It would be better to link to our more detailed post.
Google sold Android to nerds as open source. We thought that mobile operating systems would be won by the "Linux of mobile OSs."
But Google has made sure that didn't happen and we're left with devices more locked down than the proprietary Windows ecosystem we were hoping to leave in the past - and with a company in charge looking to exert even more power over us than Microsoft did.
But Google has made sure that didn't happen and we're left with devices more locked down than the proprietary Windows ecosystem we were hoping to leave in the past - and with a company in charge looking to exert even more power over us than Microsoft did.
The trick is adding a ton of features which expose extra attack surface that needs them to maintain and fix, under the pretense that it will make everyone's life easier. Make it complicated enough so that the community cannot maintain it, enabling the corporation to throw its weight around.
It’s the perfected form of what MS was trying to achieve with IE back in the 90s. All the power of a closed source monopoly, further enhanced by friends and foes alike incorporating your tech as a load-bearing pillar of their strategies, with a cloak of plausible deniability in the form of an open source repo protecting you from antitrust enforcement. A true have your cake and eat it situation.
This is what happened with the Qt app dev framework. The Qt Company delayed releases of LTS updates to non-paying users by 1 year, while not properly dealing with the steady stream of regressions that were affecting normal releases. I quit Qt development partially because I felt that I was dealing with forever-beta software.
But actually, with Qt you do have KDE devs who push their own patches which does help deal with the flaws in the upstream project.
In the Android world, they need more devs doing the same and supporting projects like GrapheneOS with security testing/hardening.
But actually, with Qt you do have KDE devs who push their own patches which does help deal with the flaws in the upstream project.
In the Android world, they need more devs doing the same and supporting projects like GrapheneOS with security testing/hardening.
Note the post title is incorrect. See https://news.ycombinator.com/item?id=45160975. Android patches are being delayed in general, not only for AOSP.
XCancel link which will show the thread context if you aren't logged in to Twitter: https://xcancel.com/grapheneos/status/1964561043906048183
Note the post title is incorrect. See https://news.ycombinator.com/item?id=45160975. Android patches are being delayed in general, not only for AOSP.
Security of the Android ecosystem should not be compromised just to make the lives of Googlers easier in handling the public, internal, and pixel branches of AOSP.
Edit: The HN title is false and security patches were released. But this is more about Google trying to appease OEMs who aren't capable with keeping up with a monthly OS release schedule.
Edit: The HN title is false and security patches were released. But this is more about Google trying to appease OEMs who aren't capable with keeping up with a monthly OS release schedule.
> We want to make sure that if you download an app from a developer, regardless of where you get it, it's actually from them. That's it.
In what scenario is this a serious threat because I can't think of any.
In what scenario is this a serious threat because I can't think of any.
People are installing banking apps that are actually from criminals. Basically app phishing.
> People are installing banking apps that are actually from criminals.
and this identification does nothing about that, this is not to protect users. such phishing are always found on play-store alone.
and this identification does nothing about that, this is not to protect users. such phishing are always found on play-store alone.
The reason this happens is that greedy companies like Google have made apps the de facto way to get anything done.
There's 0 reason you should need an app to fucking pay for parking. Why do you then?
Because running mostly unsandboxed native code on customers devices is a fantastic way to steal data and build profiles. Browsers just don't cut it - they're too safe, too secure, too abstracted.
Let's be honest here - what is a banking app? Web forms, some more web forms, and then to top it off, some web forms. I mean, hell, half these apps are just web views with spywa - I mean analytics - slapped on top.
There's 0 reason you should need an app to fucking pay for parking. Why do you then?
Because running mostly unsandboxed native code on customers devices is a fantastic way to steal data and build profiles. Browsers just don't cut it - they're too safe, too secure, too abstracted.
Let's be honest here - what is a banking app? Web forms, some more web forms, and then to top it off, some web forms. I mean, hell, half these apps are just web views with spywa - I mean analytics - slapped on top.
Let's not call them banking apps. They're not. They're scam apps.
The problem represented in the tweet is deeper. It is about not receiving patches which means the device is basically unsafe to use altogether.
The problem represented in the tweet is deeper. It is about not receiving patches which means the device is basically unsafe to use altogether.
It sounds like EV certificates, and it turned out that in practice no one cared about id verification.
This feels like an airplane bullet hole example.
[deleted]
Seems like there needs to be a split of both hardware and software. Mobile phones morphed into something else lately. Not all of us need all the features of a smart phone, but still need a comms device.
We need a simpler OS with simpler hardware that focuses on comms and less features. Simpler OS, lower attack surface, simpler to maintain without the help of a gigantic corporation. I don't need a supercomputer in my pocket.
>Not all of us need all the features of a smart phone, but still need a comms device. [...] I don't need a supercomputer in my pocket.
What's stopping you from using a feature phone?
What's stopping you from using a feature phone?
I don’t even want a smart phone if the banks/trading firms don’t force me to use a phone for auth. I keep a used smart phone for company stuffs (again auth) and bank stuffs.
Security/privacy?
So you want a $100 feature phone that has serious security features like monthly security patches and dedicated security coprocessors? It's tough to make the economics of that work out. All the serious security features costs money to implement, either in the form of development costs or added costs to the BOM. Those costs can be absorbed if you're selling a $600 phone, but not a $100 phone. If you try to add those features to a $100 phone, it'll end up making the phone more expensive, which means nobody but security freaks would buy your phone, and you lose economies of scale that's needed to make a phone at all.
Back to your point, there's already a "split of hardware and software" in the PC market, and we know how it works out. Security there is a joke. Windows might be getting monthly security patches, but the same can't be said of the panoply of third party drivers/firmware. Whenever microsoft tries to push for better security they get shouted down by people claiming it's some sort of conspiracy to implement DRM.
Back to your point, there's already a "split of hardware and software" in the PC market, and we know how it works out. Security there is a joke. Windows might be getting monthly security patches, but the same can't be said of the panoply of third party drivers/firmware. Whenever microsoft tries to push for better security they get shouted down by people claiming it's some sort of conspiracy to implement DRM.
You missed my point, a simpler hardware/software phone needs less resources to maintain. No eyecandy/cushy features to maintain, security becomes easier to maintain by the community. No constantly added features and gimmicks which break and introduce weak points.
Let's not forget that all these "features" which enable corporations like Google take complete control over the project also end up driving price up, constantly. Cheap phones are a sh*t iteration of more expensive phones, instead of being simpler more basic implementations of must have features without the "quality of life" bloat on the top tier models. They should have a different tier OS rather than the same one.
I would also not make the parallel between comms devices and PCs, they're different beasts.
Let's not forget that all these "features" which enable corporations like Google take complete control over the project also end up driving price up, constantly. Cheap phones are a sh*t iteration of more expensive phones, instead of being simpler more basic implementations of must have features without the "quality of life" bloat on the top tier models. They should have a different tier OS rather than the same one.
I would also not make the parallel between comms devices and PCs, they're different beasts.
>a simpler hardware/software phone needs less resources to maintain
And a such a product is going to absolutely niche, which means no economies of scale producing or maintaining it. You try to justify that by saying it'll be maintained by "the community", but who's going to want to do unglamorous work fixing security issues, compared to developing features? Mainstream phones have dedicated security teams and freelance vulnerability researchers going after them for fame/clout. Who would want to do security research for what's essentially a glorified nokia 3310 that maybe 1000 people use?
And a such a product is going to absolutely niche, which means no economies of scale producing or maintaining it. You try to justify that by saying it'll be maintained by "the community", but who's going to want to do unglamorous work fixing security issues, compared to developing features? Mainstream phones have dedicated security teams and freelance vulnerability researchers going after them for fame/clout. Who would want to do security research for what's essentially a glorified nokia 3310 that maybe 1000 people use?
The Flipper Zero and its success through direct crowdfunding proves that if you build it, and this next step is equally important to the first, if you build a community around it to directly market it effectively with reversible crowdfunding, you don’t have to wait for them to then come, as they’re already here, right there with you.
Flipper zero doesn't really have a competitor, aside from maybe a bunch of bulky equipment that fits on a table. Such a feature phone would be competing against iPhones/Pixels, both of which are pretty secure and have dedicated security teams. Any new product would have to compete on price/feature/reputation, which would be tough.
The success of the Raspberry Pi proves that existence of competitors is no impediment to success with the proper connections with vendors and with the community.
The OpenWRT One is another example of collaborating with community trusted vendors to build a niche community based hardware product.
https://openwrt.org/toh/openwrt/one
The OpenWRT One is another example of collaborating with community trusted vendors to build a niche community based hardware product.
https://openwrt.org/toh/openwrt/one
Ignoring how strangely against this idea you are, for no justifiable reason, it wouldn't look like a 3310, it would still look like a smart phone, probably OLED so more battery life. It would just miss a lot of modern features which are absolutely irrelevant to anyone who wants a privacy/security focused mobile phone.
Probably not the latest CPU, not the latest mobile chip, but still decent for what it has to do.
I have crossed paths with them before. Yellow rock approach.
https://danieldashnawcouplestherapy.com/blog/yellow-rock-met...
https://danieldashnawcouplestherapy.com/blog/yellow-rock-met...
>Ignoring how strangely against this idea you are, for no justifiable reason
Ignoring how you assert this, when I outlined plenty of reasons which you've yet to rebut...
>it wouldn't look like a 3310, it would still look like a smart phone, probably OLED so more battery life. It would just miss a lot of modern features which are absolutely irrelevant to anyone who wants a privacy/security focused mobile phone. Probably not the latest CPU, not the latest mobile chip, but still decent for what it has to do.
Sounds like a $200 mid-range phone that's sold in much of Asia. Question is, who's going to make it? How are you going to amortize the development costs? You mentioned that it's going to use custom software/hardware to keep security maintenance burden low, but how would that be funded? Most of the SoC vendors are going to be providing kernels/drivers to you with the expectation that you're going to use it to build an Android phone. Good luck convincing them to provide engineering support for your custom software/hardware stack.
Not to mention the questions about maintenance you haven't addressed aside from some handwaving about it'll be simpler and therefore can be "community maintained".
Ignoring how you assert this, when I outlined plenty of reasons which you've yet to rebut...
>it wouldn't look like a 3310, it would still look like a smart phone, probably OLED so more battery life. It would just miss a lot of modern features which are absolutely irrelevant to anyone who wants a privacy/security focused mobile phone. Probably not the latest CPU, not the latest mobile chip, but still decent for what it has to do.
Sounds like a $200 mid-range phone that's sold in much of Asia. Question is, who's going to make it? How are you going to amortize the development costs? You mentioned that it's going to use custom software/hardware to keep security maintenance burden low, but how would that be funded? Most of the SoC vendors are going to be providing kernels/drivers to you with the expectation that you're going to use it to build an Android phone. Good luck convincing them to provide engineering support for your custom software/hardware stack.
Not to mention the questions about maintenance you haven't addressed aside from some handwaving about it'll be simpler and therefore can be "community maintained".
>Whenever microsoft tries to push for better security they get shouted down by people claiming it's some sort of conspiracy to implement DRM.
Mainly because it is, and you can go Q.E.D. all you like, but there doesn't need to be a bunch of mustachioed villains explicitly making evil plans when everyone's ultimate aims align. They're going to get theirs, and the rest will just be a long for the ride while those people in a position of power continue to weave a collective path through the space of "conspicuously unimplemented features".
The computer was meant to be as a calculator. An unassuming tool to automate the mundane, not as a link in the chain of techno-fascism/feudalism/tyranny. The only thing that will ward off that eventuality is how we as people embrace and guide it's further usage & implementation.
The tech is currently here for every bad ending. I want to make that clear. It has already arrived. The knowledge of it's configuration to bring those ends are the part that isn't quite realized yet. I pray that it won't be unearthed, but with the way things are currently going, I have serious doubts.
Mainly because it is, and you can go Q.E.D. all you like, but there doesn't need to be a bunch of mustachioed villains explicitly making evil plans when everyone's ultimate aims align. They're going to get theirs, and the rest will just be a long for the ride while those people in a position of power continue to weave a collective path through the space of "conspicuously unimplemented features".
The computer was meant to be as a calculator. An unassuming tool to automate the mundane, not as a link in the chain of techno-fascism/feudalism/tyranny. The only thing that will ward off that eventuality is how we as people embrace and guide it's further usage & implementation.
The tech is currently here for every bad ending. I want to make that clear. It has already arrived. The knowledge of it's configuration to bring those ends are the part that isn't quite realized yet. I pray that it won't be unearthed, but with the way things are currently going, I have serious doubts.
>Mainly because it is, and you can go Q.E.D. all you like, but there doesn't need to be a bunch of mustachioed villains explicitly making evil plans when everyone's ultimate aims align. They're going to get theirs, and the rest will just be a long for the ride while those people in a position of power continue to weave a collective path through the space of "conspicuously unimplemented features".
Like it or not, TPM was meant to increase security by deterring evil maid attacks. If you can't stop this sort of attack, your device doesn't offer serious security, and a feature phone with wifi/bluetooth/cellular data turned off probably has similar security. Moreover TPMs were introduced over a decade ago and there's still no DRM that's based on it. People did forget about SGX though, which came and went but had actual DRM built for it. I've also never heard a peep about HDCP which is specifically for DRM purposes and is built into every GPU/monitor.
Like it or not, TPM was meant to increase security by deterring evil maid attacks. If you can't stop this sort of attack, your device doesn't offer serious security, and a feature phone with wifi/bluetooth/cellular data turned off probably has similar security. Moreover TPMs were introduced over a decade ago and there's still no DRM that's based on it. People did forget about SGX though, which came and went but had actual DRM built for it. I've also never heard a peep about HDCP which is specifically for DRM purposes and is built into every GPU/monitor.
Okay, so there's so much wrong here i don't know where to start.
> Like it or not, TPM was meant to increase security by deterring evil maid attacks. If you can't stop this sort of attack, your device doesn't offer serious security, and a feature phone with wifi/bluetooth/cellular data turned off probably has similar security
TPMs in their commercial implementation do not deter any evil maid attack. Only some special cases like HEADS Firmware actually protects you from an evil maid attack. TPMs, Secureboot, etc. merely prevent non-signed code from booting when the hard has not been tampered with. Tamper with the hardware and make it show a green "everything is fine" screen while booting a tainted kernel and device drivers and a tpm won't save you.
> Moreover TPMs were introduced over a decade ago and there's still no DRM that's based on it.
Google Play Integrity API is essentially this. Can't run certain apps on devices that don't pass TPM based attestation. Not exactly DRM but something akin to it.
> People did forget about SGX though, which came and went but had actual DRM built for it.
People didn't forget, it got broken so badly intel gave up on it.
> I've also never heard a peep about HDCP which is specifically for DRM purposes and is built into every GPU/monitor.
You've just not been listening. It's just that HDCP also has been bypassed a lot.
> Like it or not, TPM was meant to increase security by deterring evil maid attacks. If you can't stop this sort of attack, your device doesn't offer serious security, and a feature phone with wifi/bluetooth/cellular data turned off probably has similar security
TPMs in their commercial implementation do not deter any evil maid attack. Only some special cases like HEADS Firmware actually protects you from an evil maid attack. TPMs, Secureboot, etc. merely prevent non-signed code from booting when the hard has not been tampered with. Tamper with the hardware and make it show a green "everything is fine" screen while booting a tainted kernel and device drivers and a tpm won't save you.
> Moreover TPMs were introduced over a decade ago and there's still no DRM that's based on it.
Google Play Integrity API is essentially this. Can't run certain apps on devices that don't pass TPM based attestation. Not exactly DRM but something akin to it.
> People did forget about SGX though, which came and went but had actual DRM built for it.
People didn't forget, it got broken so badly intel gave up on it.
> I've also never heard a peep about HDCP which is specifically for DRM purposes and is built into every GPU/monitor.
You've just not been listening. It's just that HDCP also has been bypassed a lot.
Looks like PostmarketOS (mainline Linux for phones, with choice of frontend, such as Plasma Mobile or Phosh) has demoted all their previous "Main"-tier devices to "Community" or lower tier:
https://wiki.postmarketos.org/wiki/Devices#Main
Anyone know whether this is a sign of a push for being daily driver quality? Or a sign that volunteers previously doing promising work have drifted away, and they're acknowledging that?
https://wiki.postmarketos.org/wiki/Devices#Main
Anyone know whether this is a sign of a push for being daily driver quality? Or a sign that volunteers previously doing promising work have drifted away, and they're acknowledging that?
I am the pmOS maintainer for the PinePhone. It was demoted from main to community because I was the only maintainer and one of the criteria for main is to have two or more maintainers. ( https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merg... ) Originally many pmOS core devs were maintainers, which is why it was in main, but they all lost interest and it was about to be demoted to testing / unmaintained, so I volunteered to become the maintainer to stop that from happening.
A blanket statement of a phone being "of daily driver quality or not" is impossible to make because everyone has different expectations of a "daily driver". I have been daily-driving the PinePhone since 2021 (it is my first and only smartphone) but that doesn't mean everyone else will be happy with it.
A blanket statement of a phone being "of daily driver quality or not" is impossible to make because everyone has different expectations of a "daily driver". I have been daily-driving the PinePhone since 2021 (it is my first and only smartphone) but that doesn't mean everyone else will be happy with it.
Thank you for your work on PostmarketOS.
Main is described as "The most supported devices, with all the features and stability you'd expect from a regular OS."
Unfortunately there was/is no device supported by postmarketOS that fits that description. You'll need at least good telephony support including 4G features like VoLTE, proper camera support (not potato polaroid from the 80s quality), Wifi, Bluetooth, geolocation, working GPU acceleration, media hardware decoders, decent battery life. And I'm probably forgetting a few things.
Let's hope that initiatives like https://liberux.net/ will help make a fully working, long lasting device available!
Unfortunately there was/is no device supported by postmarketOS that fits that description. You'll need at least good telephony support including 4G features like VoLTE, proper camera support (not potato polaroid from the 80s quality), Wifi, Bluetooth, geolocation, working GPU acceleration, media hardware decoders, decent battery life. And I'm probably forgetting a few things.
Let's hope that initiatives like https://liberux.net/ will help make a fully working, long lasting device available!
Unfortunately, and as much as I like Linux for phones, I think it's very, very far from AOSP. It completely misses the AOSP security model and the apps (no, I don't believe that running waydroid on Linux is entirely viable, otherwise instead of Linux for phone we would have Waydroid as an alternative to Android).
I think the only realistic alternative would be to build upon AOSP properly, with Google being just a contributor instead of the owner. But it cannot come from a community fork by someone in their garage, it has to come from Android manufacturers. I was hoping that Huawei would start something like that, instead they went with their own HarmonyOS.
I think the only realistic alternative would be to build upon AOSP properly, with Google being just a contributor instead of the owner. But it cannot come from a community fork by someone in their garage, it has to come from Android manufacturers. I was hoping that Huawei would start something like that, instead they went with their own HarmonyOS.
[deleted]
[deleted]
The only reason that would make me fear from an antitrust judgement splitting Android from Google is that it may lose the Google contributions to AOSP.
Google is more and more showing that they really don't want to contribute to AOSP.
So for me, Android should be split out of Google. Maybe the other Android manufacturers will start contributing to AOSP, and maybe Android will die. But let me be honest: if Google keeps going this way, I will move to an iPhone (and I've been using and developing for Android forever). We may as well try the split, and if it fails I'll end up with an iPhone anyway.
Google is more and more showing that they really don't want to contribute to AOSP.
So for me, Android should be split out of Google. Maybe the other Android manufacturers will start contributing to AOSP, and maybe Android will die. But let me be honest: if Google keeps going this way, I will move to an iPhone (and I've been using and developing for Android forever). We may as well try the split, and if it fails I'll end up with an iPhone anyway.
Note the post title is incorrect. See https://news.ycombinator.com/item?id=45160975. Android patches are being delayed in general, not only for AOSP.
And so, Google's war on open Android continues.
Fucking hell. Can Google stop being evil for like 5 minutes? It's like they can't go a week without coming up with some new fucked up thing to do to their already tormented mobile ecosystem.
Fucking hell. Can Google stop being evil for like 5 minutes? It's like they can't go a week without coming up with some new fucked up thing to do to their already tormented mobile ecosystem.
Note the post title is incorrect. See https://news.ycombinator.com/item?id=45160975. Android patches are being delayed in general, not only for AOSP.
"Why should people believe what you say about /^.*$/?"
That regex derived from the tweet seems apt.
That regex derived from the tweet seems apt.
̶D̶o̶n̶'̶t̶ ̶b̶e̶ ̶e̶v̶i̶l̶
I hope that this action, along with Google's refusal to correctly safeguard and segregate apps, costs Google all of Android in the long term. Neither deserves to exist.
Any thoughts on Linux phones?
Any thoughts on Linux phones?
Unchecked Apple without real competition would be worse than the status quo.
That is a misrepresentation because Samsung, Huawei, and various Linux vendors each will have their own answer, their own alterative. In no universe will Apple be without competition. Apple is not even a consideration since it doesn't allow unapproved app installation anyway.
Android only ever had a chance because it is one ecosystem. Developers aren't going to develop for five slightly-different ecosystems in a trench coat.
This ship has sailed, in the past Amazon's store did not succeed a lot, but there are already a few important enough offsprings:
* Huawei with separate store and no Gapps
* Samsung with importantly different browser and ton of extra features, also another store
* in China the app-in-wechat and similar are a major thing
If you develop for a diverse set of user you need a lot of effort.
If you develop for a diverse set of user you need a lot of effort.
Apps that run on the Kindle Fire can't use Google Mobile Services, and the Amazon appstore is missing many well-known titles.
The Play Store is mostly absent from China, and I really don't know how that ecosystem works.
Was there one ecosystem?
The Play Store is mostly absent from China, and I really don't know how that ecosystem works.
Was there one ecosystem?
You're too young to remember Symbian and Java phone ecosystem mess, are you? Or even Android of around 2.x era, where getting an app doesn't mean it works on your phone?
There already are multiple different android ecosystems today. For example Samsung has SDKs that have features when targeting their flavor of Android. There will still be a common base.
> Developers aren't going to develop for five slightly-different ecosystems
The point, perhaps, is for one to emerge as the prominent choice, the correct one. Diversity however has its own value.
The point, perhaps, is for one to emerge as the prominent choice, the correct one. Diversity however has its own value.
I wish Android manufacturers contributed to AOSP, so that it would still be one ecosystem, but with shared ownership. But I guess it's more profitable for all of them to let Google do it on their own. And it sucks for the user, because we have to live with Google's decisions.
But does Google accept third-party contributions for AOSP?
Yes, anyone is free to contribute to AOSP and many manufacturers already do.
https://source.android.com/docs/setup/contribute/submit-patc...
https://source.android.com/docs/setup/contribute/submit-patc...
It is a shame that those companies don't contribute to AOSP (or fork it). Apparently Huawei decided that they would do better alone with their own HarmonyOS, but I don't get it. It could be so powerful if AOSP was actually shared between the Android manufacturers...
I would happily leave Android and go with such a fork. Instead, each (Samsung, Huawei, ...) try to make their own thing. And good luck to them to beat Android on their own.
I would happily leave Android and go with such a fork. Instead, each (Samsung, Huawei, ...) try to make their own thing. And good luck to them to beat Android on their own.
The same is clearly coming for Chromium forks, which is why I've always thought the privacy and ad-blocking forks are a joke - if they ever gain enough marketshare, or if google just tires of the public open source charade, they have no chance of maintaining a modern browser on their own.
This is all the more likely now that Google has been emboldened by not having to sell off Chrome for anticompetitive reasons.