Delayed Security Patches for AOSP (Android Open Source Project)

Scope and Misinterpretation of the Issue

  • Multiple comments note the HN title is wrong: patches are not “delayed for AOSP” specifically.
  • Security backports for Android 13/14/15 were pushed to AOSP on Sept 2 as usual.
  • What is delayed are:
    • Monthly/QPR Android releases (e.g. Android 16 QPR1 not tagged in AOSP on time).
    • The overall public disclosure timeline for Android security fixes, affecting Pixels and OEM builds as well as AOSP.

New Security Update / Embargo Model

  • Google is shifting from mostly monthly to mostly quarterly security updates.
  • OEMs now reportedly get 3–4 months of early access to patches instead of ~1 month.
  • Commenters claim these partner bulletins are widely leaked, including to attackers, making the long embargo harmful rather than protective.
  • Google added an exception allowing binary‑only security fixes before source is released, but:
    • Critics argue this is pointless because patches are easily reverse‑engineered.
    • It creates an incentive to ship opaque fixes and further erodes transparency.
  • GrapheneOS (via an OEM partner) already has early access, but is constrained by embargo rules and rejects the idea of a special binary‑only “preview” branch.

Security Posture: Android vs iOS and Linux

  • Some argue Pixel/Android used to be roughly competitive with iOS on security, but Google’s new policies and partner‑driven compromises are eroding that.
  • Criticism extends to the Linux kernel and Android security process as “understaffed” and mismanaged despite Google doing a lot of upstream security work.
  • Apple is seen as having different problems but not this level of self‑inflicted delay.

Google’s Control, Antitrust, and Open Source Strategy

  • Strong sentiment that Google is degrading “open Android”:
    • Migrating key components into proprietary Google Mobile Services and apps.
    • Using security and Play Integrity as levers to enforce licensing and ecosystem control.
  • Several call for antitrust remedies: splitting Android and/or Chrome from Google, or moving them to independent nonprofits.
  • Others worry that:
    • New owners might be even more exploitative.
    • Fragmentation could weaken security and leave Apple with de facto monopoly power.

Browsers as a Parallel Case

  • Discussion connects Android’s trajectory to Chromium:
    • Fear that privacy/ad‑blocking forks are ultimately at Google’s mercy.
    • Suggestion that Firefox/Gecko should be the basis for forks, with more community‑aligned governance.
  • Concern that Firefox’s dependence on Google search revenue is unstable; some think better governance or a new steward may be needed.

Alternatives and Fragmentation

  • Linux phones (postmarketOS, PinePhone, etc.) are viewed as promising but far from Android’s app ecosystem and security model.
  • Some suggest a consortium of Android OEMs collaboratively steering AOSP, but:
    • Today most vendors focus on their own skins, stores, and partial forks (Huawei, Samsung, etc.).
    • There is skepticism that multiple slightly incompatible ecosystems are viable for app developers.

Desire for Simpler, More Secure Devices

  • A thread explores “simple, secure phones” with minimal features:
    • One side argues lower complexity would ease community maintenance and reduce attack surface.
    • The other points to economics: serious security (patch cadence, secure hardware) is expensive and hard to sustain for niche devices.
    • Examples like Raspberry Pi, Flipper Zero, and OpenWrt are cited as counterpoints showing niche hardware can work with strong community backing.

Apps, Phishing, and Platform Responsibility

  • Tangential debate about Google’s narrative of “verifying developers wherever you get the app”:
    • Some see it as similar to EV certificates—nominal identity checks that don’t stop real‑world fraud.
    • Others note real problems with fake “banking” apps, but argue deeper issues stem from app‑centric design and data‑hungry business models, not lack of developer identity checks.