Private Android Distribution Options
Evaluate how to distribute the Android companion privately while keeping updates easy for end users. This page compares Google Play testing tracks, Google Play internal app sharing, and a self-hosted F-Droid repository.
Recommendation
If the main requirement is easy updates for a small trusted group, prefer Google Play internal testing (up to 100 testers) or closed testing (for larger private groups). If the main requirement is no Google dependency and full self-hosting, a private F-Droid repository is viable, but it carries noticeably higher hosting, signing-key, and client-onboarding overhead.
Executive Summary
| Option | Best for | Update experience | Main trade-off |
|---|---|---|---|
| Google Play internal testing | Fast private rollout to a small trusted group | Best — normal Play Store install/update flow | Requires Play Console and Google accounts; internal track capped at 100 testers |
| Google Play closed testing | Private rollout beyond the internal-track limit | Best — same Play update path | More Play Console setup / tester management |
| Google Play internal app sharing | Ad-hoc QA builds | Weak — upload a new build and share a new link | Links expire; not a smooth ongoing update channel |
| Private F-Droid repo | Self-hosted / no-Google distribution | Good once installed — F-Droid client can update from the repo | Requires hosting, repo signing, and onboarding users into the F-Droid client |
Direct APK / caco update android | Operator-managed devices reachable over adb | Good — pushes + installs the latest APK to configured serials | Manual/operator-driven; only installs to explicitly configured adb serials |
Detailed Comparison
| Criterion | Play internal testing | Play closed testing | Play internal app sharing | Private F-Droid repo |
|---|---|---|---|---|
| Who can install | Up to 100 testers on the internal track | Private tester groups / email lists / Managed Google Play orgs | People with the sharing link (or an allowed email list) | Anyone with the repo URL / QR and the F-Droid client |
| How users join | Tester receives opt-in link, accepts in Play, installs from Play Store | Tester added to track, then opts in / installs via Play | Tester enables Internal App Sharing in Play Store, then opens the link | User installs F-Droid, adds the repo, then installs from that repo |
| Update mechanism | Play Store updates on the internal testing track | Play Store updates on the closed testing track | Upload a new APK/AAB and distribute a new sharing link | F-Droid client polls the repo and offers updates |
| Speed to first install | Fast once track is published; first release may still require review | Good, but more setup than internal | Very fast for one-off QA builds | Slower — user must install F-Droid and add repo first |
| Operational overhead | Low | Low to medium | Low per build, but poor for ongoing update management | Medium to high |
| Cost considerations | Requires Google Play developer account (US$25 one-time registration fee) | Same as internal testing | Same as internal testing | No Play fee, but hosting + repo-signing/admin overhead |
| Privacy / control | Google-hosted | Google-hosted | Google-hosted | Best — fully self-hosted |
Recommended Choices by Use Case
Best overall for easy private updates
Google Play internal testing if you have 100 or fewer trusted testers. It gives the cleanest install and update flow because updates are delivered through the normal Play Store mechanism.
Best for larger private cohorts
Google Play closed testing if you need a bigger private group, more structured tester management, or Managed Google Play organization support.
Best for self-hosting / no Google dependency
Private F-Droid repo if control and self-hosting matter more than friction. Viable, but the extra setup and maintenance are real.
Option Details
1. Google Play internal testing
- Good fit when: you want the easiest install/update flow for a small private group.
- Tester limit: internal testing is intended for up to 100 testers.
- Onboarding flow: add testers in Play Console, publish the internal test, share the opt-in link, tester accepts and installs from Play.
- Update flow: publish a new build to the internal track; Play handles update delivery.
- Current automation: an explicit
play_upload_mode=nonesource dispatch builds the signed phone/Wear AAB pair and publishes bounded source-run provenance. A later trusted-main validate/draft/rollout dispatch carries that immutable source run id and exact head, downloads the uniquely named unexpired artifacts, verifies provider/file digests plus package/versionCode/upload certificate before Play credentials are loaded, and promotes phone tointernaland Wear to the same package'swear:internalform-factor track without rebuilding later main or creating a historical ref. Tag-triggered Android release work remains opt-in behindCACO_ANDROID_RELEASE_ON_TAG=true, so ordinary core releases do not consume the Linux release runner unless Android artifacts are intentionally requested. - Gotchas: the first-ever release on the internal track can still require review, and opt-in links may take a few hours to become available after first publish. Use
rolloutonly after explicit operator approval.
2. Google Play closed testing
- Good fit when: you need a private rollout larger than the internal-track limit or want more explicit tester-group management.
- Onboarding flow: add testers or Managed Google Play organizations to the closed track, share the opt-in link, install from Play.
- Update flow: same high-quality Play Store update path as internal testing.
- Trade-off: slightly more setup overhead than the internal track, but still much easier for end users than self-hosted distribution.
3. Google Play internal app sharing
- Good fit when: you want to hand a QA build to someone immediately.
- Onboarding flow: tester enables Internal App Sharing in Play Store, then opens the sharing link.
- Update flow: weak for ongoing use — you upload a new build and share a new link. A single link can only be used by up to 100 users, and links expire 60 days after upload.
- Conclusion: useful for ad-hoc validation, not the best answer to the “easy to update” requirement.
4. Private F-Droid repository
- Good fit when: you want self-hosted distribution and no Google Play dependency.
- Infrastructure: run
fdroidserver, host the generated repo under the conventional/fdroid/repo/path, and manage the repo signing keys. - Onboarding flow: user installs the F-Droid client, adds your repo (link or QR), then installs the app from that repo.
- Update flow: publish a new APK into the repo and run the repo update step; F-Droid clients can then discover and install updates from that repository.
- Trade-off: much more operational ownership than Play, but also much more control.
5. Direct APK install via caco update android
- Good fit when: you manage the target devices directly and they are reachable over adb (operator-owned phones/emulators on a known serial).
- Automation: APK update orchestration is configured under
updates.android.caco update androidinspects and installs only explicitly configured adb serials, and for remote hosts copies the APK to the adb host before invokingadb install. - Update flow: build/fetch the APK, then
caco update androidpushes and installs it to each configured serial — no Play account or F-Droid client required. - Trade-off: manual/operator-driven rather than a self-service store channel, and limited to devices you can reach over adb; best for a small operator-controlled device set.
Decision Matrix
If the requirement is “private + easiest updates”
Prefer Google Play internal testing first, then closed testing if you outgrow the 100-tester internal track.
If the requirement is “private + no Google dependency”
Prefer a private F-Droid repository, but budget for hosting, signing-key management, user onboarding into the F-Droid client, and some repo maintenance.
Not recommended as the primary update channel
Internal App Sharing is excellent for one-off QA drops, but the expiring-link / new-link-per-build model makes it a poor primary “easy to update” path.
User Onboarding Cheat Sheet
| Option | What the user does |
|---|---|
| Play internal / closed testing | Open opt-in link, accept tester status, install from Play Store, receive updates via Play |
| Play internal app sharing | Enable Internal App Sharing in Play Store, open the link, install the one shared build |
| Private F-Droid | Install F-Droid, add repo URL / QR, trust repo signing key, install and update from that repo |
Direct APK / caco update android | Connect a configured device over adb; the operator runs caco update android to push + install the latest APK |
Sources
- Google Play: set up an open, closed, or internal test
- Google Play: share app bundles and APKs internally
- Google Play: control when app changes are reviewed and published
- Google Play: developer account registration fee
- F-Droid: installing the server and repo tools
- F-Droid: setup an app repo
- F-Droid: how to add a repo