Thread

Android 17 is the first since 3.x to add new APIs without releasing to the AOSP

1180 points · 723 comments · theanonymousone

wps · 1789760710 · focus · HN ↗
The amount of roadblocks Google is putting up for GrapheneOS is just ridiculous. None of their decisions make any sense, from the delayed source patches upstream, to the embargos, attestation issues, etc. Google simply regrets android being open source.
1. godelski · 1789763541 · focus · HN ↗
  I hope people remember this when advocating for chromium. Just because it is open source doesn't mean they don't control it. We need to start the long process of hard forking now or turn to alternatives like Firefox as a new foundation.
  > Google simply regrets android being open source.
  Android wouldn't be what it is if it wasn't open source. With all the work from outside Google. The same is true chrome.
  But they won't learn that on their own. They are breaking the deals. So we move. We force their hand
  1. StilesCrisis · 1789766362 · focus · HN ↗
    Hard forking doesn't solve the problem of closed source.
    If the goal of a hard fork is "the community will invest equal resources that Google does today" then you wildly underestimate how many engineers work on Chrome.
    ocdtrekkie · 1789778454 · focus · HN ↗
    The bigger problem is wasting developer effort contributing to Google's platform. The real secret behind Android being "open" (sorta) is that while almost nobody runs AOSP, Google has tricked a bunch of fools into working on Android forks instead of building a real competitor.
    Playing at their table is a losing game, the house always wins.
    charcircuit · 1789780372 · focus · HN ↗
    The developer effort is not wasted because it's open source. Anyone can fork it at any time. None of it can be thrown away from humanity, wasting it.
    The reason why no one runs AOSP is because the phone market rewards differentiation. Each phone manufacture wants to build their own experience and building on top of AOSP is how they do so.
    Is it really a losing game? Building a new OS from scratch is not worth it. Why throw away an entire app catalog for your device? Consumers want access to existing app catalogs when buying a phone. If anything is a losing game it's building a new mobile operating system over forking Android as a base.
    ocdtrekkie · 1789781209 · focus · HN ↗
    If you are not working to destroy Android, you are supporting it. You might feel happy about your custom ROM nonsense and how it protects your privacy, but that just means you're selfish, because nearly everyone will still be trapped on Google's version.
    Technologists need to aggressively reject solutions which don't spread freedom to ordinary users as well.
    fragmede · 1789781558 · focus · HN ↗
    It wasn't worth it, but it's 2026, not 1991, when Linus first released Linux. AI can shit out a new OS, given enough tokens, and a VM/compatibility layer would let you run Android apps until native ports became available. The question is why would you want to do that? Computers are vastly more capable than they were when the Linux kernel was originally designed, and the needs of programs and their permissions have changed as well. <a href="https://xkcd.com/1200/" rel="nofollow">https://xkcd.com/1200/ While throwing away all the learnings and starting from scratch are usually not justified, sometimes it is the right choice, if enough things have changed. Should GPS location, fine grained or coarse, and related permissions, be a part of the OS kernel or a user space daemon that other processes can query or some other thing? That wasn't a question when Linux was created but should be a core consideration for a replacement system that was created today, along with a myriad of other modern day questions that didn't exist back then. I don't think it's a loosing game, and I don't have the resources to make one myself, but I do think that the world's materially changed enough to justify it.
    fragmede · 1789781694 · focus · HN ↗
    It wasn't worth it, but it's 2026, not 1991, when Linus first released Linux. AI can shit out a new OS, given enough tokens, and a VM/compatibility layer would let you run Android apps until native ports became available. The question is why would you want to do that? Computers are vastly more capable than they were when the Linux kernel was originally designed, and the needs of programs and their permissions have changed as well. <a href="https://xkcd.com/1200/" rel="nofollow">https://xkcd.com/1200/ While throwing away all the learnings and starting from scratch are usually not justified, sometimes it is the right choice, if enough things have changed. Should GPS location, fine grained or coarse, and related permissions, be a part of the OS kernel or a user space daemon that other processes can query or some other thing? That wasn't a question when Linux was created but should be a core consideration for a replacement system that was created today, along with a myriad of other modern day questions that didn't exist back then. I don't think it's a loosing game, and I don't have the resources to make one myself, but I do think that the world's materially changed enough to justify building a new one from scratch.
    AI generating code changes the game significantly, though there are issues with that. A new OS would have taken several millions and multiple teams, but can now be done for far less. The problem is hardware to run it on. Who'd pay $2,000 for a shittier phone with less features when a $500 used one with GrapheneOS is right there? So the market, (in)efficiently, hasn't come up with a new phone OS. Not because it isn't warranted, but because the free market isn't a perfect system.
    pjmlp · 1789789361 · focus · HN ↗
    You mean proprietary AI can do that, running on big corp servers.
    thepasch · 1789811323 · focus · HN ↗
    What proprietary AI running on big corp servers was 6 months ago is now runnable on owned bare metal compute, and there's no reason to believe this trajectory won't continue for the foreseeable future.
    pjmlp · 1789829168 · focus · HN ↗
    With a proprietary local stack, provided one can actually afford the hardware.
    bigstrat2003 · 1789793468 · focus · HN ↗
    LLMs can't even get much simpler programs right without humans holding their hand, let alone an OS. The odds of an LLM just banging out an OS are nil.
    fragmede · 1789957820 · focus · HN ↗
    <a href="https://github.com/Made-In-Basement/ember" rel="nofollow">https://github.com/Made-In-Basement/ember would seem to raise the odds, slightly.
    charcircuit · 1789795024 · focus · HN ↗
    Why bother building a compatibility layer when you can just start with Android and start promoting your LLM from there?
    realusername · 1789785877 · focus · HN ↗
    > The reason why no one runs AOSP is because the phone market rewards differentiation.
    No, the reason is that AOSP doesn't even include a functional keyboard nor a functional call manager nowadays.
    AOSP apps were abandonned around Android 11, you can't just keep them as is for real users, it looks amateur.
    Even the open-source ROMs came to the same conclusion eventually and developed their own.
    charcircuit · 1789794895 · focus · HN ↗
    >the reason is that AOSP doesn't even include a functional keyboard nor a functional call manager nowadays
    No one was using those apps so it didn't make sense to spend time on them.
    troupo · 1789797777 · focus · HN ↗
    So.. The market didn't actually support differentiation?
    izacus · 1789820264 · focus · HN ↗
    The marked used all the different apps available from both OEMs and on Play Store.
    Don't be a prick.
    realusername · 1789836682 · focus · HN ↗
    They were used quite a lot at the time, outside of the usual Samsung/HTC, a lot of OEM didn't bother to make their own full app suite, nowadays it's necessary though
    AnthonyMouse · 1789790586 · focus · HN ↗
    > The reason why no one runs AOSP is because the phone market rewards differentiation.
    This is what empire-building middle managers say to rationalize their boondoggles, but in actual fact most customers can't even tell the difference between two different vendors' Android skins, definitely can't tell the difference before they buy one, and the way they actually differentiate phones is on real hardware differences that show up in the specs like the camera or performance.
    The hardware company's idiosyncratic fork of the software is irrelevant at best and annoyingly irregular in the common case.
    miki123211 · 1789814960 · focus · HN ↗
    > the way they actually differentiate phones is on real hardware differences that show up in the specs
    You forgot about one thing they care about above all others — cost.
    And the easiest way to keep costs down is through "alternative revenue streams", which involve your own tracking, your own app bundling deals and your own App Store, which you're pushing on users constantly. And if you do that, you may as well get the branding win from doing the custom skin too.
    AnthonyMouse · 1789967427 · focus · HN ↗
    That's the middle manager's rationalization again, but meanwhile nobody actually uses their OEM-specific app store and the two dollars they made from the two percent of customers who accidentally bought an app using their store is less than the amount of money they lose to pissing people off.
    swiftcoder · 1789817127 · focus · HN ↗
    > The developer effort is not wasted because it's open source. Anyone can fork it at any time
    Assuming you can get a hardware vendor to support your fork.
    Android has always been a weird blend of proprietary BSPs wedged together with the core AOSP project - we used to have an entire team whose full-time job was merging the Qualcomm BSP into our AOSP fork. At the time you didn't even get access to that BSP without inking a deal with QCOM...

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.