Google details new 24-hour process to sideload unverified Android apps
Overview of the new process
- To install apps whose signatures aren’t registered with Google, users must:
- Enable Developer Options.
- Go through an “advanced flow” with warnings, a device restart, and biometric/PIN auth.
- Wait a one‑time 24‑hour “protective” delay before enabling installs.
- Then choose to allow such installs for 7 days or indefinitely.
- ADB installs are exempt from the 24‑hour delay.
- Clarifications in-thread:
- The advanced flow appears to be one‑time per device, not per app.
- Developer Options can be turned off after enabling the flow.
- A Google account is not required; device authentication is via PIN/biometrics.
Security rationale and scam debate
- Google frames this as protection against “coached” or coerced sideloading, especially for banking/identity theft scams.
- Some commenters see this as a reasonable compromise that may disrupt urgency‑based scams by forcing a cooling‑off period.
- Many are skeptical:
- Scammers already spend days or weeks grooming victims and can just “call back tomorrow”.
- Most reported scams in multiple countries rely on social engineering, official apps, web phishing, or remote control tools, not sideloaded malware.
- Google Play itself is described as full of scammy or intrusive apps, weakening the “safety” justification.
Impact on F-Droid, independent devs, and open source
- Strong concern that extra friction will:
- Reduce adoption of apps from F-Droid and similar stores.
- Shrink user bases for projects like NewPipe, Obtainium, and other non‑Play apps.
- Separate but related: mandatory developer verification and government‑ID requirements for broader distribution are seen as:
- Hostile to anonymous or pseudonymous FOSS developers.
- Giving Google leverage to de‑platform apps that hurt its business (e.g., ad‑blocking YouTube front‑ends).
- Hobbyist “limited distribution” accounts (up to 20 devices, no ID) are viewed as inadequate for large FOSS ecosystems.
User autonomy, ownership, and “walled gardens”
- Very strong theme: this is viewed as another step toward an iOS‑style locked platform and “tech feudalism”.
- Many argue that on a device they own, they should install whatever they want without delays or identity checks.
- Others counter that most users are non‑technical; prioritizing their safety over power‑user convenience is acceptable.
ADB, developer mode, and banking apps
- ADB is repeatedly mentioned as a workaround, but:
- Many see “connect to a PC and use a CLI” as unrealistic for normal users.
- Requiring Developer Mode to enable the flow is problematic because:
- Some banking, payment, and government apps in multiple countries refuse to run if Developer Mode is on.
- It’s clarified that Developer Mode need not remain enabled after enabling the advanced flow, but some worry apps may detect the advanced-flow state itself in the future (unclear).
Regulatory and competition concerns
- Many call the change anti‑competitive:
- It imposes extra friction specifically on competing app stores and independently distributed apps.
- F-Droid and similar projects must either submit to Google’s verification (including ID) or accept being second‑class.
- Several commenters hope EU and other regulators will intervene; others are pessimistic, arguing regulators also benefit from centralized control.
Alternatives and migration
- Repeated suggestions to:
- Move to GrapheneOS or other AOSP‑based ROMs, which are not bound by Google Play rules (though banking/Play Integrity issues remain).
- Consider SailfishOS, Linux‑based phones, or even “dumbphone + separate small computer” setups.
- Some say if Android becomes a de facto walled garden, they might as well switch to iOS; others insist that’s just trading one cage for another.
Language and framing
- Several object to the term “sideloading” itself:
- Argue it pathologizes “installing software” and normalizes corporate gatekeeping.
- See it as part of a broader “newspeak” that paints user control as inherently suspect.