Why hasn't my managed Google Play app updated yet — and how do I force it?

You published an urgent fix to a managed Google Play app, synced everything in sight, and a day later your Android fleet is still running the old version — with kiosk devices apparently never updating at all. Nothing is broken. This is Play's default update machinery working exactly as designed, and there is a per-app setting that changes it.

The problem

The symptom pattern is consistent enough to recognise on sight:

• A new version of an app is published (a private LOB app or an updated public app) and assigned via managed Google Play — typically through Intune or another EMM.
• Hours pass. Device check-ins complete. The app version reported by the fleet does not move.
• Somewhere between several hours and a day-plus later, most devices quietly pick up the update.
• A stubborn subset — almost always dedicated/kiosk devices running the app full-screen 24/7 — never seem to update at all.

Admins then go hunting for a “push this update now” button, and discover it does not exist by default. Forcing an Intune device sync doesn't help either, because Intune isn't the thing delivering the update — Google Play is.

This bites hardest when the update is urgent: a crash fix for a warehouse scanning app, a payment-flow patch for a customer-facing kiosk, a security fix you're on a deadline to deploy.

Why it happens

Two separate mechanisms stack on top of each other, and both are documented Google Play behaviour rather than a fault in your EMM.

1. The roughly-daily update check

Managed devices don't watch for app updates continuously. The Play Store checks for updates approximately once a day, and Google's managed Google Play documentation states plainly that “it can take up to 24 hours before an app update is added to the update queue” on a given device. Until that daily check fires, your published update isn't even queued — no amount of EMM syncing changes that.

2. The auto-update constraints

Once queued, the update still only installs when the device meets Play's default auto-update conditions. Per Google's documentation, automatic updates in the default mode wait for the device to be idle, typically charging and on Wi-Fi, and — critically — for the app being updated to be out of the foreground.

Now consider a kiosk: it runs one app, pinned full-screen, in the foreground, 24 hours a day. The “app not in the foreground” condition is never met. The update sits in the queue indefinitely. This is why dedicated devices are always the last to update — the busier and more important the device, the less likely it is to update.

Common misdiagnoses

• “Intune hasn't synced.” Intune (or any EMM) tells managed Play which apps and versions are approved; the Play services on the device do the actual downloading and installing on their own schedule. Microsoft's own Intune troubleshooting guidance for Google apps points in the same direction: much of the delivery timing is Play-side.
• “The publish didn't work.” If the developer used a staged rollout, or the new version is still processing in the Play Console, some devices won't be offered it yet regardless of policy.
• Postponed mode. If someone previously set the app's update mode to Postponed, Play may defer its updates for up to 90 days. Worth checking before blaming the queue.

The fix

The fix most admins don't know exists is per-app high-priority update mode. Managed Google Play supports three update modes per app: Default, Postponed (defer up to 90 days), and High priority — which Google describes as the app being updated “as soon as possible” after the developer publishes a new version, rather than waiting for the daily queue and the idle/charging constraints.

Step 1 — set High priority on the apps that matter

• In Intune: Apps → Android → [your managed Google Play app] → Properties → Assignments → edit the assignment, and under the assignment's app settings set Update priority to High priority. The setting applies on Android Enterprise corporate-owned enrolments (fully managed, dedicated, and corporate-owned work profile); availability varies by enrolment type, so check what your assignment screen offers.
• Via API (other EMMs, or direct Android Management API use): set the app's autoUpdateMode to AUTO_UPDATE_HIGH_PRIORITY in the policy's applications block.

Reserve high priority for the apps where update latency genuinely hurts — the kiosk app, the line-of-business app, the scanning client. Leaving every app on high priority just burns bandwidth and battery for no operational gain; Default is the right mode for the long tail.

Step 2 — give kiosks a window to actually install

Even in high-priority mode, Play will not swap out an app while it is running in the foreground. A 24/7 kiosk app therefore still needs a deliberate gap. Options, in rough order of preference:

1. Scheduled nightly reboot — where your management tooling or launcher supports it, a reboot puts the app out of the foreground long enough for the pending update to apply before the kiosk relaunches.
2. App-side maintenance window — have the kiosk app background itself (or show a system screen) for a few minutes at a quiet hour.
3. Manual window — for a genuinely urgent fix on a small estate, exiting kiosk mode briefly per device is crude but works today.

Whichever you choose, the device must be online during the window.

Step 3 — check the network policy

Default auto-update behaviour is Wi-Fi-only. Cellular-only devices (vehicle-mounted units, field tablets) won't auto-update unless your Play/device policy permits updates over any network. If a subset of devices never updates and they all happen to be on SIMs, this is why.

Step 4 — verify properly

• Confirm the new version is live in the Play Console (fully rolled out, not staged) before judging device behaviour.
• Check reported app versions in your EMM inventory after the next device check-in — reporting lags the actual install, so don't re-diagnose a problem that has already resolved.
• Expectation-set with stakeholders: with high priority set, updates land far faster than the 24-hour default cycle, but “as soon as possible” is still not a synchronous push button.

How Decolla handles it

Straight answer: it doesn't — and we'd rather say so than pretend. Decolla provisions Windows devices over your own Intune and Autopilot tenant; it does not manage Android devices or managed Google Play, so the per-app high-priority fix above is the complete answer to this problem.

The reason this article exists on our site is that the underlying failure mode — a delivery setting you didn't know existed until it cost you a day — is exactly the class of problem Decolla is built to eliminate on the Windows side. Before anything runs, Decolla produces a written, itemised plan from a curated catalogue of 260+ items across 21 sections, stating the delivery method and reversibility class of every item (automatic, reversible, or flagged irreversible) for your approval. Its library ships pre-built, industry-tested policies and fixes — including recurring helpdesk fixes and built-in hardening — with the delivery settings already thought through, and Decolla can roll back its own changes per item afterwards.

Decolla is pre-launch; if opaque delivery behaviour on Windows is your version of this pain, the waitlist is at decolla.app.

Sources

• Google — Manage app updates in managed Google Play (update queue timing, auto-update constraints, and per-app update modes)
• Microsoft Learn — Troubleshoot Google apps and managed Google Play app issues in Intune