Locara

Google Play

What it is: Android’s primary app marketplace and the most-permissive of the major mobile stores. Hybrid automated + human review, peer-grouped permission analysis, allows sideloading. Status: Mature, dominant on Android, recently subject to court orders (Epic v. Google) requiring opening to alternative stores. Most relevant to Locara: A different model from Apple — more open to alternative distribution, more reliant on automation, more regular malware breaches. The cautionary tale on what happens when scale outruns review.

Background

Google Play launched in 2012, consolidating Android Market and Google’s media stores. Android’s open ethos meant Google could never lock down distribution the way Apple did — sideloading APKs has always been allowed, which both reduced antitrust pressure and increased malware vectors. Google has progressively tightened review (Bouncer in 2012, Play Protect in 2017, manual review for new devs since 2019) but malware still slips through more often than on iOS.

Key design decisions

  • Sideloading allowed. Users can install APKs outside Play. This made Android a more open ecosystem but constrained Google’s ability to enforce safety.
  • Hybrid review. Automated malware scanning + human review for new/less-established developers (intro’d 2019).
  • Permissions declared in manifest, granted at install (old) → granted at runtime (new). Modern Android prompts the user when an app first uses a permission, similar to iOS.
  • Peer grouping (since 2017) — apps in the same category get compared; those requesting unusually broad permissions are flagged.
  • Play Protect scans installed apps continuously for malicious behavior, even sideloaded ones.
  • Android App Bundle (AAB) — Google’s binary format that lets Play deliver device-specific subsets (e.g., your screen density’s resources only). Smaller downloads, but couples developers to Play.
  • Play Integrity API — apps can check whether they’re running on a trusted device + Play-distributed binary. Used by banks etc. to block tampered installs.
  • Play Billing — like IAP, mandatory for most digital goods. Standard 30% cut, dropped to 15% for first $1M and post-12-month subscriptions.
  • Court-ordered openness (2023+). Following Epic v. Google, Google must allow rival app stores on Android and end exclusive billing. Implementation evolving.

What worked

  • Massive scale — billions of devices, hundreds of millions of apps installed daily. Automation has to do most of the work; humans only on borderline cases.
  • Peer grouping for permissions is a clever idea that Locara should consider: comparing capability declarations across similar apps and flagging outliers automates a lot of judgment.
  • Runtime-granted permissions improved user agency over install-time-only.
  • Play Protect on sideloaded apps is a genuine value-add — even outside-store installs get continuous scanning.
  • App Bundles delivered real bandwidth wins for end users.

What failed / criticisms

  • Repeated malware breaches. DroidDream (2011, 260k devices), FalseGuide (2017, ~2M devices), and steady flow since. When automation is your main filter, sophisticated attackers eventually evade it.
  • Sideloading is both feature and exploit vector. Tradeoff Google had to make; lessons for Locara: automated scanning is necessary but not sufficient.
  • Permission fatigue. Users hit so many permission prompts they auto-approve. Same risk for Locara if every app prompts for everything.
  • Antitrust losses — court ordered Google to allow alternative stores. The “default store” position is regulatorily fragile.
  • Inconsistent enforcement. Like Apple, similar apps get different treatment.
  • Long-tail discovery is poor. Most installs concentrate at the top of the rankings; mid-tail apps starve.

Specific learnings for Locara

  1. Peer-grouped capability analysis is a great pattern. When app X declares “filesystem read on entire ~/” but other apps in its category only declare specific subdirectories, flag it for review. Locara can automate this once the catalog is large enough.
  2. Runtime + install-time consent. Apple’s model (declared at install, prompted at first use) catches more cases than either alone. Locara should adopt the same dual model.
  3. Continuous post-install scanning is worth doing. Malware can ship clean and weaponize later. Locara’s runtime can do behavioral monitoring (capability use vs. declaration) and flag anomalies.
  4. Don’t lock distribution. Android’s openness was forced on Google by their ecosystem stance; Locara should embrace it deliberately. Sideloading equivalent: users should be able to install Locara apps from a .locapp file, not just the registry. The registry is the “trusted” distribution but not the only one.
  5. Permission fatigue is real. Don’t make Locara apps prompt for every capability. Group them, batch them at install, only re-prompt when capabilities change.
  6. App Bundles concept maps onto model variants. Locara could support a manifest that declares “use 7B model on 16GB+ Macs, 3B model on 8GB Macs” — fetch only the right one at install. Different problem (hardware-tier, not screen density), same architecture.
  7. Antitrust lessons. Don’t aggressively close the ecosystem. If Locara becomes meaningful, regulators will look. Open distribution + open standards from day one mean the regulatory case never materializes.
  8. Scale of catalog implies automation. The right answer for Locara at 100 apps is fully manual; at 10,000 apps is fully automated; the transition needs to be designed for, not stumbled into.

References