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. Retr0id · 1789761534 · focus · HN ↗
  Google is also seriously dropping the ball in terms of security. The CVE-2026-43499 root LPE (aka ghostlock) is still unpatched across all Pixel devices, on the latest """security""" update, despite weaponized exploits being public for months.
  1. grapheneos · 1789763587 · focus · HN ↗
    Pixels used to have far better updates than any other Android devices but they stopped improving it years ago. It should have kept improving because it's not at all adequate. They need to be able to release OS updates more than once per month and it shouldn't take months for patches to make it into the OS. It currently takes them at least around 2 months to get even the most urgent patches into the OS. They could fix emergency calls being broken if the patch was made around 3 weeks before an OS release, but that's about as quick as they can go. It's not at all adequate for security and is a complete joke compared to Chromium's release cycle. They can get an emergency Chrome update released within a couple days. They should at least be able to do it for the Pixel OS in a week.
    GrapheneOS is often around 4 to 6 months ahead on merging Linux kernel LTS releases. We used to handle this ourselves but switched to the Android GKI LTS branch maintained by Greg KH. Unfortunately, it was often struggling to keep up even before the absolutely massive increase in Linux kernel security patches this year. AI models have rapidly accelerated vulnerability discovery and it's an ongoing crisis for the Linux kernel. We want to be on the latest LTS revision within days and want to be using the latest LTS branch within months of it being released. We're not at all happy with how Android is handling things and plan to fix that ourselves. We'll get things back to how they should be.
    We also ship all the AOSP userspace patches months before Pixels due to shipping all of the security preview patches as soon as possible. There are sometimes minor regressions but we find and fix them ourselves downstream. The security preview system has a terrible design especially considering that frontier AI models can reverse engineer the patches. There should at least only be a source embargo for around 24 to 72 hours rather than pretending as if it can work with the patches available 2 to 6 months in advance.
    cyberax · 1789766073 · focus · HN ↗
    I'd love to use GrapheneOS on less secure devices, just for the sake of Google autonomy rather than privacy.
    Cider9986 · 1789767061 · focus · HN ↗
    GrapheneOS's goal is privacy for the world and that's achieved through secure devices. You can get a phone specifically for GrapheneOS just as you choose a new device when you're buying a new one. Soon there will be two different phone brands which you can install it on. There's already an estimated 500,000 users with Pixel exclusivity.
    <a href="https://grapheneos.social/@GrapheneOS/117249893761790371" rel="nofollow">https://grapheneos.social/@GrapheneOS/117249893761790371
    cesarb · 1789772193 · focus · HN ↗
    > GrapheneOS's goal is privacy for the world and that's achieved through secure devices.
    Perfect is the enemy of good. What's better for privacy, an old but inexpensive smartphone running Android 11, or the same smartphone running an up-to-date third-party rebuild of Android 16 or newer with as many privacy-improving bells and whistles as the hardware can support?
    > Soon there will be two different phone brands which you can install it on.
    ...will they be available in my country (Brazil)? I don't think I've ever seen a Google Pixel phone in person.
    microtonal · 1789796749 · focus · HN ↗
    What's better for privacy, an old but inexpensive smartphone running Android 11, or the same smartphone running an up-to-date third-party rebuild of Android 16 or newer
    I see your point, but it would be very misleading, since the phone would still have a lot of known holes. Only the OS would get updated, typically not the drivers, driver firmware, possibly not the kernel. The phone would still be easily compromised through all the known RCEs. So you tie up non-profit projects in a lot of extra work to get an improvement that does not really matter.
    This is a mess created by the OEMs and they will continue to create this mess until people will stop buying from OEMs that only give lip service to security updates (roll out Android Security Bulletins to show a high patch level, while in reality the phone the phone has many known CVEs).
    grapheneos · 1789839977 · focus · HN ↗
    Android Security Bulletins do list a tiny subset of firmware, Linux kernel, driver and HAL patches so they do require at least very minimal updates to those. Most non-Google-certified operating systems are setting an inaccurate Android security patch level by ignoring the non-AOSP portion of the patches. GrapheneOS doesn't do that but most of the other AOSP-based projects not being certified by Google are doing it. OEMs were caught doing it too but it's not clear if it was intentional in most cases as it is with the alternate operating systems.
    Android Security Bulletins set a very low bar since the AOSP patches are available to ship by OEMs 2-6 months prior to the bulletin being published. It's also only High/Critical severity patches being listed. Due to a recent policy change, it's also officially only a subset of the patches for AOSP. That's visible through the Android platform components having patches in the Pixel Update Bulletin for September 2026 despite those being applicable to other operating systems. It's because they no longer want to backport all High and Critical severity patches due to the high volume of issues discovered by AI models. It's similar to how they stopped backporting any Low and Moderate severity patches years ago due to high volume.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.