Our Android app is frozen in carbonite

Android app economics & alternative stores

• Several commenters argue that being off Google Play effectively kills revenue; attempts with Amazon and other stores reportedly yielded “zero revenue” and lots of paperwork.
• Others note network effects: users stay on Play because all apps are there, and apps stay because that’s where users are. Alternative stores and sideloading see little mainstream adoption.
• Some suggest that if enough high‑quality apps moved to an alternative store with lower fees, users might follow, but this is seen as unlikely given current friction and security nags.

Google Drive access, scopes, and CASA audits

• Core conflict: full read/write Drive scopes now require recurring third‑party security audits (CASA), which are expensive relative to many apps’ Android revenue.
• Some devs say restricted scopes like drive.file (only app‑created or user‑picked files) are sufficient and avoid audits; others insist the app’s model—treating Drive like a full filesystem—needs broad access.
• Many defend Google’s tightening, citing highly sensitive contents in Drive and analogies to handling credit cards or “toxic waste.”
• Others see CASA as security theater: superficial checks outsourced to big consultancies, creating barriers that mainly hurt small/indie developers while not meaningfully blocking serious attackers.

Security vs usability and permissions

• Strong split:
  • One side: no unvetted app should ever get full Drive access; yearly scrutiny is appropriate and should even recur after updates to prevent “benign app later sold and abused” scenarios.
  • Other side: power users want to trust editors like this with all their files, just as on desktop; they view Google’s all‑or‑nothing, audit‑gated model as paternalistic.
• Real‑world abuses (e.g., loan apps misusing contact lists leading to blackmail and suicides) are cited as justification for strict permission regimes.

Storage Access Framework & file pickers

• Android’s Storage Access Framework and file picker are proposed as a Drive‑agnostic solution: users pick files/folders, apps get scoped URIs, often with persistent access.
• Counterpoints: picker UX is described as clunky, buggy, and file‑by‑file (folder selection support and persistence behavior are debated and device/version‑dependent), making it poor for workflows like “open and manage an entire project tree” or robust “recent files.”
• Some say these are OS‑level design problems that should be fixed there, not worked around via broad Drive scopes.

Broader Play Store & platform bureaucracy

• Multiple commenters recount growing Play Store bureaucracy: shifting policies, country‑specific tax and legal changes, repeated permissions rewrites, and confusing verification processes.
• Hobbyist and small devs report giving up on Android because maintenance overhead outweighs any revenue or satisfaction.
• There’s a wider sense that app stores have moved from democratizing distribution to tightly controlled, high‑friction channels favoring large companies.

Alternatives: sync models and platforms

• Suggestions include: dropping Drive support and relying on app‑managed storage, using other cloud providers, or “bring‑your‑own‑sync” (e.g., Syncthing) with local‑first files.
• Others argue such setups are too complex for typical users and lead to fragmented, half‑implemented sync solutions.
• Several point to web apps/PWAs and traditional desktop OSes (especially with package repositories) as more sustainable and less encumbered by app‑store gatekeeping, though desktop sandboxing and security tradeoffs are also debated.