Your phone is about to stop being yours

Overview of Google’s New Restrictions

  • New “developer verification” will require most Android app developers to register with Google, pay a fee, provide ID, and list app IDs.
  • Sideloading from settings will require a multi-step “advanced flow” with a mandatory ~24h delay and scary warnings; flow is controlled by Google Play Services, not the OS.
  • ADB installs and alternative ROMs without Google Play Services are expected to keep working, but ecosystem effects are a major concern.

Security Rationale vs Freedom / Ownership

  • Pro-change side:
    • Argues this targets real banking malware and social‑engineering scams (especially in parts of Asia) where victims are pressured to sideload “official” apps that drain bank accounts.
    • Sees 24h cooldown as a way to break urgency‑based scams, and ID verification as needed accountability.
  • Anti-change side:
    • Sees this as centralization and a power grab dressed as security, especially given ongoing malware in Play Store itself.
    • Emphasizes that phones already show strong warnings; prefers education over gatekeeping.
    • Slippery‑slope fear: once Google can silently tighten rules via Play Services, they can later ban disfavored apps or OSes.

Impact on Developers and FOSS Ecosystem

  • Concern that requiring ID and a Google relationship will chill hobby projects, anonymous devs, small FOSS apps, and third‑party stores like F‑Droid.
  • Others say serious developers will just pay and verify; only “political” or fringe devs are affected.
  • Worry that if users don’t bother with the advanced flow, F‑Droid and similar ecosystems will lose reach and contributions.

Workarounds and Practicality

  • “Advanced flow” is described as one‑time per device, not per app, but still seen as enough friction to deter non‑experts.
  • ADB is widely cited as a permanent bypass, but many argue “use ADB” is unrealistic for most users and not equivalent to a normal install.
  • Unclear whether existing unverified apps will be removed or just blocked from updating; docs suggest updates will be blocked.

Comparisons: iOS, PCs, Consoles

  • Many note Android is becoming more like iOS (notarization, developer IDs, cooling‑off flows), though still somewhat more open (unlimited ADB installs, bootloader unlock on some devices).
  • Historical parallels drawn to Windows driver signing, browser extension signing, game consoles, and earlier Microsoft lock‑in attempts.
  • Some argue PCs are the historical exception; most consumer devices have always been closed appliances.

Alternative OSes and Hardware Lockdown

  • GrapheneOS, LineageOS, /e/OS, postmarketOS, Librem 5, PinePhone, Jolla, etc. are discussed as escape hatches, but:
    • Hardware support is narrow (e.g., GrapheneOS mainly on Pixels now, maybe some Motorolas later).
    • Many phones have non‑unlockable bootloaders; even unlockable ones often depend on proprietary blobs.
  • Some say the “real fight” is:
    • Legally mandating unlockable/relockable bootloaders and custom keys.
    • Banning app‑level discrimination against non‑vendor OSes (Play Integrity, etc.).

Banking, Government Services, and Everyday Dependence

  • In many countries (especially parts of Europe and elsewhere), banking, government login, payments, transit, and online shopping increasingly require official apps and sometimes high Play Integrity scores.
  • Custom ROM and Linux‑phone users already face broken banking apps; people fear this change plus attestation will eventually lock out alternatives entirely.
  • Some accept carrying a second, stock device for banking; others see that as unsustainable or a de facto coercion.

Regulation & Antitrust Views

  • Several argue this conflicts with the EU Digital Markets Act or should trigger antitrust action (abuse of gatekeeper status, self‑preferencing Play Store).
  • Others think current DMA loopholes and regulators’ focus on business, not end‑user freedom, mean it will likely stand unless laws are revised.

Overall Sentiment

  • Thread is sharply split:
    • One camp sees a necessary, imperfect security measure that still leaves enough room for power users.
    • Another sees a key step in the long‑running erosion of general‑purpose computing and user control, with serious long‑term ecosystem risks.