8 out of the top 10 manufacturers are Chinese. Google has to be careful here, otherwise Android will end up as a Chinese consortium and their own version will just be available on Pixels.
But Western consumers at large won't buy Chinese devices if they don't carry the Play Store. And many Western app developers won't want to deal with Google Play Services and it's APIs missing, which is what made porting to Amazon's Android fork annoying as fuck.
That's the huge, huge carrot that Google carries in front of everyone thinking to fork Android.
Forking Android is not an option. Android is way too complex for any company or band of open-source developers to take up. The fork would quickly fall behind Google's implementation and would become effectively useless.
What maintained forks of Linux are there that actually do their own general improvements and maintenance besides just following along upstream with a custom driver or two? I'm even going easy and only referring to the kernel, even though "Android" is a lot more than that.
You might as well say that the average smartphone is not unlockable because iPhones aren't. People who want the advantages of user control don't buy the average device. They buy the devices they can control.
You're reading their comment in a way that most people wouldn't and that the author clearly didn't intend. Android can be and is installed on lots of appliances that aren't meant to give users control, like refrigerators and many Samsung phones. It is also installed on devices that give users control (and can be installed on lther devices that give users control and don't install Android by default). That is the difference between it and iOS.
I would argue though that even Samsung phones give more user control than iOS phones (not that I would buy either one). Even though you can't install your own remix of Android, you can disable or remove most of what you don't like and install anything that targets the Android APIs.
Yes, but my point is even stock Android is superior than iOS for usability, obviously custom ROMs such as Graphene or even proper GNU/Linux phones would be superior to Stock Android for customizability.
You can install third party stores and apps on iOS without a waiting period (in places with decent consumer rights); confirming three popups is all you need to install third party iOS apps.
Unlike on Android, there aren't that many third party iOS apps, though.
Plus, even with Google delaying shipping source code, at least they ship the source code. The traces of source you get with the open Darwin code are nowhere near comparable.
It doesn't do app store reviews as far as I am aware. They do charge an installation fee (I'm baffled they haven't been sued over that yet), but there are free apps out there thanks to Epic covering that fee to spite Apple.
Seems that this €0,50 flat fee per installation has been replaced by a 5% commission on digital transaction made through sideloaded apps as of last August.
It's fully your right to want non-webkit for your browser, but just curious. Why? Why does it matter? I've never once wished for firefox to use firefox's engine instead. The UI/sync/extension stuff is all built on top anyway.
They exist. But they don't support Android apps that are unfortunately necessary. For example, any phone without WhatsApp or banking apps support is dead on arrival in Europe.
Which is why /e/ OS and Graphene OS adoption is higher than projects such as PostmarketOS (now Nura) or Ubuntu Touch, even if they are already quite mature. I daily drove Ubuntu Touch for two years in 2019 and 2020, and it's the need of Signal which made me switch to /e/.
Yes, let's throw away a fully mature smartphone OS (AOSP) and replace it by something that does not even have proper app sandboxing. /s
The alternative are other AOSP-based OSes like GrapheneOS and Lineage. Once they are used widely enough and funded enough, they could fork AOSP when needed. In some sense they have already soft-forked in that they use major and QPR2 releases, but put a lot of patches on top to fix issues, improve security, etc.
GrapheneOS has an estimated 500,000 active installs now, apparently LineageOS has 1.4M active installs. Probably around two orders of magnitude more than traditional Linux desktop-based phones, which have been trying since, checking notes, Maemo in 2005?
Google is doing better here than Apple. Most google devices have an unlockable bootloader.
I have old Chromebooks and Nexus Tablets that are EoL, but I can install linux on them and give them a second life.
The source code for my old EoL pixel phones is out there, it's just a matter of effort to port Ubuntu or PureOS or one of the other Linux phone distros to them.
It's Apple that is being as evil as possible when it comes to stomping down alternatives, they don't release iOS source code, they bricked most of my old devices when they EoL'd them by not letting me unlock the bootloader and install my own OS, they don't release drivers.
I'm deeply unhappy with Google's current direction, but they're still lightyears from the level of evil Apple inflicts upon us.
Yeah, while I am loathe to trust Google again, will never be buying another Apple hardware again too - I used an alternative map app on an old iDevice and wrote them a 5-star review for their good features, for being better than Apple and Google maps (in some aspects) and especially for still supporting older devices. A new update for the app was released and suddenly I couldn't install it because App Store reported that my ios was outdated and not compatible with the new release. So I revised the review for the app to 2-stars pointing out they had suddenly dropped support for older iDevices which was one of their main attractive features. The developers of the app contacted me asking me to reconsider the review. According to them, they had released the latest update for the app for the "outdated" ios version / older iDEvices too, but Apple deliberately sat on it without approving it for the App store. According to them, Apple hasn't clarified the issue. If the developers are being truthful (and I do believe them), this is a deliberate and malicious act by Apple to push planned obsolescence of older iDevices.
Why does that matter? Even if it was released 20 years ago, why the fuck should Apple (or any company for that matter) dictate if a developer can make an app that runs on an old device or that a user runs the app that they want to? With Android, the developer doesn't need to depend on the "App Store", or even care about it, to distribute their app as an Android user can directly download and install the app through other means.
Tbf, Apple does in fact keep their ‘Apple OSS Distributions’ GitHub current.
This is the TiVo situation. Does open-source require allowing third parties to install their own software / OS and have unlimited control over the device? (GPL v3)
Or does it regard to access to the source code but not access to the device? (GPL v2)
TV’s, routers, IoT, etc vendors aren’t even allowed to ship devices with user-alterable software!
> We need an Android alternative, something that respects users' freedom.
The more successful Android alternative - iOS - that people love so much doesn't do any of that and it's apparently even more secure and earns even more money.
Is your theory really that closed source software will just stop being developed? I can't find another way to read that, but you can't think Google is just going to give up and shut down, right?
Look at spaces where ripoffs/copying are already rampant like mobile games. The result is a slop avalanche, rending the whole space commercially unviable for anything other than the most bottom-of-the-barrel dark-pattern shitware laden with scam ads and spyware because users don't care and won't pay.
That may well be the future for most commercial software (and software engineers) as margins collapse and AI tokenomics moves more power from labor to capital.
> But why invest time and money when your features get copied as soon as you publish it?
Because you still get money?
Nothing about getting copied means you don't still get money. It probably just means your legal team has some people to annoy into going away if you're a big company.
You think open source never develops new features?
The only thing that made commercial software more innovative is most developers never had time to build and maintain a big open source project without support from their job. Now we have agents and it takes a lot less time to implement your ideas. That means slop filling up GitHub, but also that people who came up with good new features can make them real in their free time.
ReSkate is a good example, it's a project 90% coded by AI but the people working on it are passionate and most of them are experienced game modders. They know what made the old Skate games special and wanted to bring it back to the new one. Now it's better than vanilla Skate 4 and has tons of new features never seen in the OG trilogy. That project would never be possible without Claude taking care of the hard and boring RE work.
Only the "copyleft/copyright extremists" who want to exert their own form of control over others are going to worry, while everyone else just gets to work asking AI to do what they want, and possibly even getting paid to do so.
AI's pretty good at copying features even when it's closed, or online.
Not perfect, of course. All that hype about the vibe-cloned Adobe suite is, today, hype. Next year it might not be, though that depends on questions like "will investment bubble pop?" etc.
But we are at a level where, if you can describe a feature or process well enough to test it, an LLM can develop and optimise for that feature/process. That creates opportunities for businesses to have custom just-for-them business software, which nobody copies because nobody outside the business even bothers to learn exist.
We are already there and it is called Play Integrity (meets STRONG integrity) and Google is trying to get apps to use it to shut out competitors. They are succeeding to some extend (see the Volkswagen and IKEA Smart Home apps as recent successes for Google).
Google should not be allowed to abuse its duopoly position in this way. I recommend EU citizens to report every case they are (potentially) affected by to the EU DMA team.
> see the Volkswagen and IKEA Smart Home apps as recent successes for Google
Someone should make a complaint about ePD violation in relation to those. I doubt it's "strictly necessary" for those applications to read that information (if they even fulfill the "at distance" requirement).
Oh, it’s 100% absolutely Claude. There are more tells than this.
At any rate, “developers are disassembling it to find bugs” sounds extreme, but this is something Claude will do almost spontaneously, in my experience. I ran into an issue last week where a library wasn’t doing what I expected, and asked Claude to sort out why; I came back a few minutes later to find Claude tearing apart the library’s disassembly to reveal a mismatch in struct sizes between the library’s expectations and my headers. And it did solve the bug!
Not just Claude. In my experience, almost any LLM running in Pi would rather go down rabbit holes than ask for clarification. I think the solution is to restrict what the LLM can do: If it keeps running into "permission denied" when trying to run disassemblers or read files in /lib64, then it's probably not doing what the user intended it to do.
But you're right, that report is definitely written by an LLM. Humans don't typically put parenthetical postmodifiers in headings ("Mechanism (from the shipped libc.so)"), but LLMs just love them too much.
LLMs can't help but leak details about your project into the bug too. When it started rambling about effects on Virtual Pinball or whatever it was, that was the ultimate giveaway. Completely unrelated to the bug, the fixer never needed to know, but to the LLM it's crucial data somehow.
I can't prove it, but I still think this is (partly) due to a recent EU regulation majorly backfiring.
I can't remember which one it was, but one of the recent regulations mandates that devices get updates for a certain period. Within that period a manufacturer must provide each update for all their devices in a short timeframe. The intention was to prevent flagships getting updates immediately and lower end devices having to wait months.
However, due to some (also well intentioned) wording about open source, the release of the source code is counted as the first release of an update and starts the timer.
I'm pretty sure Google is delaying public AOSP updates to give their partners (mainly Samsung I suppose) more time to finish building their updates on top of AOSP.
As far as I understand, most OEMs are not allowed to release QPR1 or QPR3 either (not that OEMs outside maybe Samsung would be able to). So part of it also reeks of giving Pixel benefits over phones of other manufacturers.
Since they are working with two OEMs (one for GrapheneOS support and one for getting embargoed security patches), I think they know what they are taking about.
Nothing of that has to do with OEMs being forbidden from shipping QPRs though.
Graphene isn't OEM so they don't get access to Android repository before AOSP drops. OEMs - like Motorola for example - do have access to partner repository and can ship QPRs if they wish to do so. Most often OEMs do not want to push updates (and it took years to make them push regular major Android updates).
> I think they know what they are taking about.
Err, if you look at that account you'll find that the person running it has a penchant for overexaggeration and selective truth telling when they feel aggrieved.
Nothing of that has to do with OEMs being forbidden from shipping QPRs though.
Are reading the same post?
“ The new APIs are currently exclusive to the Pixel OS and aren't available to other Android OEMs. […] Non-Google Android OEMs and AOSP-based projects can ship yearly and QPR2 releases.”
the person running it has a penchant for overexaggeration and selective truth telling when they feel aggrieved.
I wouldn't be surprised if large corporations like Apple and Google intentionally use these tactics to pressure regulators through their European users. Siri AI is a prime example. While it's a complicated issue, I certainly wouldn't put such maneuvers past them.
Giving their partners the time they need to finalise their releases legally seems like a... completely normal and correct thing to do? Why does everything have to be a big conspiracy?
Correct? I suppose that depends on your definition. From a corporate perspective, perhaps. But from a consumer's perspective it's most certainly not the desired outcome.
They don’t have agreements with graphene so what do they care? They care about their partners and following the law. If the law is bad that’s not their fault.
I’m not sure why you’d lump that together here? Motivations and context and the actual facts of a particular situation matter. Nobody has said “no group can ever use their power” which is what you’re hearing. People have said “certain uses of power are morally wrong” which is why the specifics matter.
Whether it's "right" depends on the goal of course, but in this case I'm not understanding your point because nobody is prosecuting those companies for doing this.
In any case, these kinds of blanket statements are not very useful, because each case tends to be judged on its own merits. For example, yes, enough people believe that monopolistic tactics are not "right" and laws reflect that.
But the goals are clear in this case, no? The regulator said "do X the way we tell you to" and the regulated decided to do Y instead in order not to break the regulation requiring them to do X in a certain way.
There should be a rule that any assertion of conspiracy must at least have some evidence.
I worked at MS and was involved in several decisions to not ship in the EU because it just wasn’t worth the internal and external regulatory headache. There was no secret agenda, Satya never told me to stick it to the EU by withholding a feature in the hopes the masses would clamor for it and demand regulatory changes, which would eventually allow us to… ship the feature in a decade or so.
I’m super sympathetic to the EU’s intent, but their execution is so obviously self-defeating that it doesn’t take elaborate conspiracies to explain corporate response.
> There should be a rule that any assertion of conspiracy must at least have some evidence.
Broadly, I agree, and good grief do I wish people would follow this more often. But Google specifically has acted incredibly anti-competitively for several years now [0], especially regarding Android. This has gone on for such a long time that they have, in my mind, lost the benefit of any doubt.
As they continue to lock down Android [1], things that would have once been met with a "Wait and see" approach are instead met with suspicion and a default assumption that it's primarily (though not typically exclusively) done to serve their own interests.
So generally, yes! That which is asserted without evidence can be dismissed without evidence. However, Google's history is all the evidence I need to assume their actions are not done in good faith.
> but their execution is so obviously self-defeating
Well no. It’s not self defeating. It’s being defeated because these are US tech companies, protected by US monopoly power, and the fact that US lawmakers are captured by lobbyists and are incapable of passing similar laws to protect their constituents. Big difference.
I posted about this 11 months ago [1]. The law you are referring to [2] absolutely makes distinctions between open/closed source. This is 100% why Google closed their source and now does security releases privately.
> from the date of end of placement on the market to at least 5 years after that date, manufacturers, importers or authorised representatives shall, if they provide security updates, corrective updates or functionality updates to an operating system, make such updates available at no cost for all units of a product model with the same operating system;
> (b)
> the requirement referred to in point (a) shall apply both to operating system updates offered voluntarily by manufacturers, importers or authorised representatives and to operating system updates provided to comply with Union law;
> (c)
> security updates or corrective updates mentioned under point (a) need to be available to the user at the latest 4 months after the public release of the source code of an update of the underlying operating system or, if the source code is not publicly released, after an update of the same operating system is released by the operating system provider or on any other product of the same brand;
> (d)
> functionality updates mentioned under point (a) need to be available to the user at the latest 6 months after the public release of the source code of an update of the underlying operating system or, if the source code is not publicly released, after an update of the same operating system is released by the operating system provider or on any other product of the same brand;
> (e) an operating system update may combine security, corrective and functionality updates.
(c) and (d) treat binary releases as equivalent to source code releases, so that's rather the opposite of making a distinction between open and closed source. It would serve as an explanation if Google had started to release source code and binaries simultaneously, but it doesn't explain why the source code release is delayed even beyond that.
EDIT: I see that was already brought up multiple times when you posted about it 11 months ago.
if that is the case then it should be brought to the respective overseen regulatory body, weather it is for them to clarify that this is not a valid interpretation of the law (it's at least clearly in conflict with the spirit of the law) and intentionally delaying public releases this way is a no-go or weather it is to amend the law to make it more explicitly illegal
either way if that is true it looks like a very intentional abuse/misinterpretation of existing regulations
How does that prevent them from releasing 17 QPR1 now given that 17 QPR1 is already released "by the operating system provider or on any other product of the same brand"?
The second part explicitly addresses this, Pixels getting QPR1 starts the timer.
My understanding is as follows: They're delaying source code releases for security updates, but they're privately sharing source and binary security updates with partners. Source releases are embargoed, binary releases aren't (I assume it's to avoid triggering the ecodesign clock)
When patches go out to partners in October, they are immediately released by GrapheneOS for users who opt-in for "security preview" releases. Stock Pixel users might get them in December (triggering the ecodesign clock), and other brands could get them as late as April (per ecodesign requirements).
So the timeline could look like:
June: Vulnerability discovered
September: Vulnerability patched
October: Source and binary patch sent to OEMs. Patch can now be reverse engineered and actively exploited.
October, shortly after: GrapheneOS releases an update with the binary patch
December: Vulnerability is officially part of the December bulletin, Pixel officially gets the update
I didn't dispute that they're delaying source code releases for security patches, I only pointed out that these regulations can't explain why they choose not to publish QPR1/QPR3 while publishing QPR0/QPR2.
Not completely. Android Security Bulletins only have fixes for vulnerabilities marked high/critical in resent years. To get all other security fixes, you need QPRs and major releases.
Ecodesign is so nice! The vacuum energy reduction requirements that also introduced mandatory of suction power, aside from starting a market trend towards better suction, saved:
- 45 kWh per household per year
- 11.7 TWh of electricity in 2020 EU-wide
Literally just from better designed consumer vacuum cleaners.
It's an interesting theory. However, Samsung has already started to roll out One UI 9, which is built on top of Android 17 a month ago, so their clock has already started ticking.
I'm not familiar with the concrete wording of the regulation, but I would wager that the all the customization layers (like "One UI") that OEMs put on top of AOSP is the component for which the update clock should tick, and they should be unaffected of an underlying open source component (AOSP) being released.
Android 17 is old news, and OneUI 9 was what delayed the OS version bump for months, because Samsung planned to launch it with on new flagships first, during summer Unboxed event.
A problem with legislation in general is that it is often very open to interpretation. Especially legislation around fast-moving technology fields. It’s very difficult to write both broadly applicable legislation that requires minimal interpretation. And in fact leaving the regulation open to interpretation can be a feature from the point of view of authority.
The only interpretation that matters is that of the Authority of enforcement and judgement. The implementer’s interpretation doesn’t hold much weight.
We can say what we earnestly believe the regulations mean, and how they can be met, but if the authorities say “not good enough” that’s all that matters.
> due to a recent EU regulation majorly backfiring
And why should a regulation in EU affect rest of the world. Or for that matter, any US regulation. The arrogance of these nations and the ignorance of tech companies is ruining the entire Internet.
Because making things everywhere compliant is cheaper than having both a non-EU and EU versions of software. See also: Brussels effect[0].
It's simple economics. The companies are also allowed to either do special versions to comply with local laws or even to pull out of the market. They just choose not to for reasons.
Sure, American courts ask for age verification, the entire world needs to comply now. Then people wonder why so much surveillance. You can’t see past Brussels effects, because ignorance.
This vicious European Union, which stifles innovation and works against the public interest – for example (checks his notes) by mandating USB-C charging and replaceable batteries!
If this is the case, I wonder why isn't Google publicly saying this. Because right now, it looks like they've stopped publishing the sources just because they felt like it, which has understandably generated a lot of backlash, but I feel like all the backlash would go away if they pointed at the EU regulations.
I'm not disagreeing with you, and I don't understand the market.
But surely, unless the regulation is written in an especially thoughtless way, the clock would start at either the time the device manufacturer has access to the upstream fix, or the time that the manufacturer provides an update to any of their devices (which implies access to an upstream fix).
So public source release would only impose additional burden on device manufacturers if it is the first time that they are seeing the upstream fix.
No, it's not. (source: used to work on Android at Google, and its as simple as it seems, more and more MBA-style management meant more and more didn't care, which meant it was more and more poorly resourced, until it was discovered by revealed preferences that no one cared, at least, no one cared enough to speak up)
Google hasn't delayed pushing releases to AOSP but rather stopped pushing Pixel exclusive releases to AOSP. Android 17 QPR1 and Android 17 QPR3 are Pixel exclusive releases which won't be pushed to AOSP under the current policy. For 2/4 quarters per year, Pixels are on a major release of Android exclusive to Pixels and not released to AOSP. Non-Pixel devices don't get QPR1 or QPR3 releases. This is part of Google dropping support for Pixel devices from AOSP and giving them an artificial advantage over other Android devices.
Good look with NDK issues, having the source code available would not help much anyway.
NDK seems to be handled like a 20% project in terms of allocated resources, I bet it has not more that like 2 FTEs, given its progress since Android 2.1.
Given the current trajectory of all things, I think that the drawbacks will outweigh the benefits for a project like AOSP due to the changing economics. The reduction of SBOM (and therefore the attack surface) will be far more beneficial than the saving of work from hundreds of imported dependencies. The trend of vertical integration will likely happen in software sooner or later.
Bit of a hyperbolistic title. The core of the bug report doesn't require disassembly of the library. The bug author just went the extra step to do a root cause investigation, which of course requires light reversing work.
We need a third option. Be it SalfishOS, Ubuntu Touch, Nura, or whatever picks up with a sizable community. We just need to start developing and investing in that one. It won't be perfect, but it will offer an alternative and control to the users.
There are plenty of alternative OS options. None are accepted by phone companies and shipped in orders of 100m devices worldwide.
Android has ~4b cumulative users, iOS 2.5b. Combined 1-2b phones are shipped annually, so phones are replaced over 3-6 years or so. Total production numbers of Sony PS2/Nintendo Switch are ~160m each, and there haven't been enough of those to be a viable alternative consumer platforms. China moves couple hundred million units per year of de-Googled phones internally(Google services are default banned in China except through Hong Kong VPN and such), and that doesn't seem to be changing situations much. Windows Phone was like few hundreds total.
The third option has to ship like 1000m - 1b units total and/or annually to be viable. Code quality... isn't going to matter, but it'll have to be literally 10-100x more popular than Nintendo. That is going to be the bar.
Wouldn't it be better to start focusing energy onto projects like PostmarketOS (now Nura)? Sure the Linux phone space on the hardware side is a bit barren, but there are options and you don't really need top of the line specs to get something working; you could even use an SBC with a cellular modem peripheral to have a cellphone replacement.
165 comments
[ 0.26 ms ] story [ 17.4 ms ] threadThat's the huge, huge carrot that Google carries in front of everyone thinking to fork Android.
Though given how little those companies have respected their users so far, I feel like this is a bit of a monkey's paw.
just hang up the hat and never look back
Both aren't.
I would argue though that even Samsung phones give more user control than iOS phones (not that I would buy either one). Even though you can't install your own remix of Android, you can disable or remove most of what you don't like and install anything that targets the Android APIs.
Unlike on Android, there aren't that many third party iOS apps, though.
Plus, even with Google delaying shipping source code, at least they ship the source code. The traces of source you get with the open Darwin code are nowhere near comparable.
Doesn't apple still "verify" (and can decide not to allow) those supposedly 3rd party applications?
https://developer.apple.com/support/apps-in-the-eu/
EU users can also add alternative app stores to their iOS device, e.g. Epic Games Store, AltStore, or some corn app.
Being able to have a fully functional version of KDE Connect was also be a requirement.
Check out Blink Chrome on iOS on Agelia developer Gyuyoung’s Weblog: https://blogs.igalia.com/gyuyoung/2024/08/08/chrome-ios-brow...
The Google has documented how to compile your own build. Note the ‘building blink for iOS’ section.
It’s as easy as adding ‘use_blink = true’ to ‘ [gn_args]’ in your ‘.setup-gn’: https://chromium.googlesource.com/chromium/src/+/main/docs/i...
We need an Android alternative, something that respects users' freedom.
Alternatives exist. They just need signifiant adoption.
Google can kill them in an instant, they need the AOSP source to survive.
The alternative are other AOSP-based OSes like GrapheneOS and Lineage. Once they are used widely enough and funded enough, they could fork AOSP when needed. In some sense they have already soft-forked in that they use major and QPR2 releases, but put a lot of patches on top to fix issues, improve security, etc.
GrapheneOS has an estimated 500,000 active installs now, apparently LineageOS has 1.4M active installs. Probably around two orders of magnitude more than traditional Linux desktop-based phones, which have been trying since, checking notes, Maemo in 2005?
I have old Chromebooks and Nexus Tablets that are EoL, but I can install linux on them and give them a second life.
The source code for my old EoL pixel phones is out there, it's just a matter of effort to port Ubuntu or PureOS or one of the other Linux phone distros to them.
It's Apple that is being as evil as possible when it comes to stomping down alternatives, they don't release iOS source code, they bricked most of my old devices when they EoL'd them by not letting me unlock the bootloader and install my own OS, they don't release drivers.
I'm deeply unhappy with Google's current direction, but they're still lightyears from the level of evil Apple inflicts upon us.
But that's not the case for other manufacturers, including ones way more popular than Google. Especially Samsung.
On average, a new Android device is almost as locked as iPhone is.
As per september 2026: https://developer.apple.com/news/upcoming-requirements/
Why does that matter? Even if it was released 20 years ago, why the fuck should Apple (or any company for that matter) dictate if a developer can make an app that runs on an old device or that a user runs the app that they want to? With Android, the developer doesn't need to depend on the "App Store", or even care about it, to distribute their app as an Android user can directly download and install the app through other means.
This is the TiVo situation. Does open-source require allowing third parties to install their own software / OS and have unlimited control over the device? (GPL v3)
Or does it regard to access to the source code but not access to the device? (GPL v2)
TV’s, routers, IoT, etc vendors aren’t even allowed to ship devices with user-alterable software!
The more successful Android alternative - iOS - that people love so much doesn't do any of that and it's apparently even more secure and earns even more money.
See post downbelow: https://news.ycombinator.com/item?id=50083579
So why? :)
You can support independent Android development (for example, GrapheneOS)
Not surprisingly, I get slight hints of Claudism in the text.
AI "opening" the source of software is one of the best things I've seen going for it so far.
Who beside the open source community develops new features if they can be easily copied?
That may well be the future for most commercial software (and software engineers) as margins collapse and AI tokenomics moves more power from labor to capital.
But why invest time and money when your features get copied as soon as you publish it?
Because you still get money?
Nothing about getting copied means you don't still get money. It probably just means your legal team has some people to annoy into going away if you're a big company.
The only thing that made commercial software more innovative is most developers never had time to build and maintain a big open source project without support from their job. Now we have agents and it takes a lot less time to implement your ideas. That means slop filling up GitHub, but also that people who came up with good new features can make them real in their free time.
ReSkate is a good example, it's a project 90% coded by AI but the people working on it are passionate and most of them are experienced game modders. They know what made the old Skate games special and wanted to bring it back to the new one. Now it's better than vanilla Skate 4 and has tons of new features never seen in the OG trilogy. That project would never be possible without Claude taking care of the hard and boring RE work.
IMHO it's the best outcome.
Not perfect, of course. All that hype about the vibe-cloned Adobe suite is, today, hype. Next year it might not be, though that depends on questions like "will investment bubble pop?" etc.
But we are at a level where, if you can describe a feature or process well enough to test it, an LLM can develop and optimise for that feature/process. That creates opportunities for businesses to have custom just-for-them business software, which nobody copies because nobody outside the business even bothers to learn exist.
Google should not be allowed to abuse its duopoly position in this way. I recommend EU citizens to report every case they are (potentially) affected by to the EU DMA team.
Someone should make a complaint about ePD violation in relation to those. I doubt it's "strictly necessary" for those applications to read that information (if they even fulfill the "at distance" requirement).
At any rate, “developers are disassembling it to find bugs” sounds extreme, but this is something Claude will do almost spontaneously, in my experience. I ran into an issue last week where a library wasn’t doing what I expected, and asked Claude to sort out why; I came back a few minutes later to find Claude tearing apart the library’s disassembly to reveal a mismatch in struct sizes between the library’s expectations and my headers. And it did solve the bug!
But you're right, that report is definitely written by an LLM. Humans don't typically put parenthetical postmodifiers in headings ("Mechanism (from the shipped libc.so)"), but LLMs just love them too much.
This is not true at all though. OEMs can release anything whenever they want.
https://grapheneos.social/@GrapheneOS/117282080803799576
Since they are working with two OEMs (one for GrapheneOS support and one for getting embargoed security patches), I think they know what they are taking about.
Graphene isn't OEM so they don't get access to Android repository before AOSP drops. OEMs - like Motorola for example - do have access to partner repository and can ship QPRs if they wish to do so. Most often OEMs do not want to push updates (and it took years to make them push regular major Android updates).
> I think they know what they are taking about.
Err, if you look at that account you'll find that the person running it has a penchant for overexaggeration and selective truth telling when they feel aggrieved.
Are reading the same post?
“ The new APIs are currently exclusive to the Pixel OS and aren't available to other Android OEMs. […] Non-Google Android OEMs and AOSP-based projects can ship yearly and QPR2 releases.”
the person running it has a penchant for overexaggeration and selective truth telling when they feel aggrieved.
Here we go again…
Maybe their own source at OEMs lied to them? The QPRs are in the same repo they're getting their security patches from.
That doesn't mean that they are actually allowed to release them. Big difference.
I wouldn't be surprised if large corporations like Apple and Google intentionally use these tactics to pressure regulators through their European users. Siri AI is a prime example. While it's a complicated issue, I certainly wouldn't put such maneuvers past them.
https://grapheneos.social/@GrapheneOS/115164133992525834
https://news.ycombinator.com/item?id=49946698
Correct? I suppose that depends on your definition. From a corporate perspective, perhaps. But from a consumer's perspective it's most certainly not the desired outcome.
This is also an instance of a group using its power.
In any case, these kinds of blanket statements are not very useful, because each case tends to be judged on its own merits. For example, yes, enough people believe that monopolistic tactics are not "right" and laws reflect that.
I worked at MS and was involved in several decisions to not ship in the EU because it just wasn’t worth the internal and external regulatory headache. There was no secret agenda, Satya never told me to stick it to the EU by withholding a feature in the hopes the masses would clamor for it and demand regulatory changes, which would eventually allow us to… ship the feature in a decade or so.
I’m super sympathetic to the EU’s intent, but their execution is so obviously self-defeating that it doesn’t take elaborate conspiracies to explain corporate response.
Broadly, I agree, and good grief do I wish people would follow this more often. But Google specifically has acted incredibly anti-competitively for several years now [0], especially regarding Android. This has gone on for such a long time that they have, in my mind, lost the benefit of any doubt.
As they continue to lock down Android [1], things that would have once been met with a "Wait and see" approach are instead met with suspicion and a default assumption that it's primarily (though not typically exclusively) done to serve their own interests.
So generally, yes! That which is asserted without evidence can be dismissed without evidence. However, Google's history is all the evidence I need to assume their actions are not done in good faith.
[0] https://arstechnica.com/gadgets/2018/07/googles-iron-grip-on...
[1] https://manualdousuario.net/en/blocking-unverified-apps-andr...
Well no. It’s not self defeating. It’s being defeated because these are US tech companies, protected by US monopoly power, and the fact that US lawmakers are captured by lobbyists and are incapable of passing similar laws to protect their constituents. Big difference.
[1]: https://news.ycombinator.com/item?id=45911673
[2]: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ%3AJOL...
> Clause 1.2:
> (6) Operating system updates:
> (a)
> from the date of end of placement on the market to at least 5 years after that date, manufacturers, importers or authorised representatives shall, if they provide security updates, corrective updates or functionality updates to an operating system, make such updates available at no cost for all units of a product model with the same operating system;
> (b)
> the requirement referred to in point (a) shall apply both to operating system updates offered voluntarily by manufacturers, importers or authorised representatives and to operating system updates provided to comply with Union law;
> (c)
> security updates or corrective updates mentioned under point (a) need to be available to the user at the latest 4 months after the public release of the source code of an update of the underlying operating system or, if the source code is not publicly released, after an update of the same operating system is released by the operating system provider or on any other product of the same brand;
> (d)
> functionality updates mentioned under point (a) need to be available to the user at the latest 6 months after the public release of the source code of an update of the underlying operating system or, if the source code is not publicly released, after an update of the same operating system is released by the operating system provider or on any other product of the same brand;
> (e) an operating system update may combine security, corrective and functionality updates.
EDIT: I see that was already brought up multiple times when you posted about it 11 months ago.
either way if that is true it looks like a very intentional abuse/misinterpretation of existing regulations
https://digital-strategy.ec.europa.eu/en/policies/cra-manufa...
The second part explicitly addresses this, Pixels getting QPR1 starts the timer.
My understanding is as follows: They're delaying source code releases for security updates, but they're privately sharing source and binary security updates with partners. Source releases are embargoed, binary releases aren't (I assume it's to avoid triggering the ecodesign clock)
When patches go out to partners in October, they are immediately released by GrapheneOS for users who opt-in for "security preview" releases. Stock Pixel users might get them in December (triggering the ecodesign clock), and other brands could get them as late as April (per ecodesign requirements).
So the timeline could look like:
June: Vulnerability discovered
September: Vulnerability patched
October: Source and binary patch sent to OEMs. Patch can now be reverse engineered and actively exploited.
October, shortly after: GrapheneOS releases an update with the binary patch
December: Vulnerability is officially part of the December bulletin, Pixel officially gets the update
January: Samsung releases the update
April: Everyone else (worst, legal case)
Not completely. Android Security Bulletins only have fixes for vulnerabilities marked high/critical in resent years. To get all other security fixes, you need QPRs and major releases.
- 45 kWh per household per year
- 11.7 TWh of electricity in 2020 EU-wide
Literally just from better designed consumer vacuum cleaners.
https://energy-efficient-products.ec.europa.eu/product-list/...
I'm not familiar with the concrete wording of the regulation, but I would wager that the all the customization layers (like "One UI") that OEMs put on top of AOSP is the component for which the update clock should tick, and they should be unaffected of an underlying open source component (AOSP) being released.
The only interpretation that matters is that of the Authority of enforcement and judgement. The implementer’s interpretation doesn’t hold much weight.
We can say what we earnestly believe the regulations mean, and how they can be met, but if the authorities say “not good enough” that’s all that matters.
And why should a regulation in EU affect rest of the world. Or for that matter, any US regulation. The arrogance of these nations and the ignorance of tech companies is ruining the entire Internet.
It's simple economics. The companies are also allowed to either do special versions to comply with local laws or even to pull out of the market. They just choose not to for reasons.
[0]: <https://en.wikipedia.org/wiki/Brussels_effect>
But surely, unless the regulation is written in an especially thoughtless way, the clock would start at either the time the device manufacturer has access to the upstream fix, or the time that the manufacturer provides an update to any of their devices (which implies access to an upstream fix).
So public source release would only impose additional burden on device manufacturers if it is the first time that they are seeing the upstream fix.
Right?
See https://news.ycombinator.com/item?id=50112059 for a more detailed explanation.
NDK seems to be handled like a 20% project in terms of allocated resources, I bet it has not more that like 2 FTEs, given its progress since Android 2.1.
Android has ~4b cumulative users, iOS 2.5b. Combined 1-2b phones are shipped annually, so phones are replaced over 3-6 years or so. Total production numbers of Sony PS2/Nintendo Switch are ~160m each, and there haven't been enough of those to be a viable alternative consumer platforms. China moves couple hundred million units per year of de-Googled phones internally(Google services are default banned in China except through Hong Kong VPN and such), and that doesn't seem to be changing situations much. Windows Phone was like few hundreds total.
The third option has to ship like 1000m - 1b units total and/or annually to be viable. Code quality... isn't going to matter, but it'll have to be literally 10-100x more popular than Nintendo. That is going to be the bar.
The bar for what? The parent talks about the start. I already daily drive Librem 5 without waiting for "the bar".
Man, the early '10s were wild, man.