Managed Google Play

How it works

You bind your Android Enterprise organisation to the management platform, and the console embeds the Managed Google Play iframe. From there an admin approves public apps, accepts their permissions once on behalf of all users, and publishes private apps by uploading a signed APK. Google hosts and scans the binary even when the listing is private.

On the device, the store appears inside the work profile or on the fully managed device, and it shows only approved entries. Identity comes from a managed Google Play account created automatically at enrollment, which is why nobody has to type personal credentials. This model replaced the old device-administrator approach and has been the standard route for Android app deployment since Android Enterprise became the default in 2017.

Three app types live there: public apps from the catalogue, private apps limited to your organisation, and web apps, which wrap a URL into an icon. Web apps are underrated for internal tools that have no mobile build.

Why it matters for a fleet

It gives Android fleets a clean distribution channel with no unknown-sources toggle anywhere in the process. Apps arrive signed, scanned by Play Protect, and updatable in place.

Practical points that trip teams up: an app has to be approved before it can be assigned, permission changes can block an update until the admin accepts them again, and private apps take a few minutes to appear after upload. Also worth planning for, devices need Google Mobile Services. Rugged hardware sold without GMS can't use Managed Google Play at all, so those devices need internal APK distribution instead.

How Appaloosa handles it

Appaloosa connects to Managed Google Play during setup, so approving a public app, publishing a private APK or adding a web app happens in the same console as device policies. Apps install silently on enrolled devices, and the same catalogue also carries internal builds for GMS-free hardware. See the Mobile Application Management page.