Keeping apps updated on your users’ devices gives them access to the latest features, while also improving app security and stability. This article outlines steps you can take as an IT admin to ensure the latest versions of apps are installed on your organization’s managed devices.
Default update behavior
By default, apps are updated automatically when the following constraints are met:
- The device is connected to a Wi-Fi network.
- The device is charging.
- The device is idle (not actively used).
- The app to be updated is not running in the foreground.
Google Play typically checks for app updates once a day, so it can take up to 24 hours before an app update is added to the update queue. After an app is added to the queue, it will be automatically updated the next time the constraints above are met.
App update settings available to users
Your users can modify the Wi-Fi network constraint by changing the auto-update settings on their device. A user can select one of the following options:
- Update apps over any network.
- Update apps over Wi-Fi only (this is the default setting).
- Do not update apps.
App update settings available to IT admins
As the IT admin you can override the update settings that your users configure to further customize the app update behavior on the devices you manage. If your EMM supports these features, the controls will be available in your EMM console. If you don’t find these controls in your EMM console, contact your EMM provider.
Select High priority mode
If you want an app to update immediately after the developer publishes a new version, you can select the High priority update mode for that app.
When using High priority mode, the app is updated, as soon as possible, after the developer publishes the new version and it has been reviewed by Google Play. If the device is offline, the app will be immediately updated the next time the device is connected to the internet.
If the app is in use when the update is ready to install, the app will be closed during the update, which could affect your users.
Select Postpone mode
If you want to pause updates for an app, you can select the Postpone mode for that app.
When using the Postpone mode, the app will not be automatically updated during 90 days after it first became out of date. After this 90-day period, the latest available version of the app is automatically installed with the default update behavior (as outlined above).
After the app is updated to the latest available version, a new 90-day postponement period will begin the next time the developer publishes a new version of the app.
Postpone mode does not prevent your users from manually updating the app during the 90 day postponement period.
The Postpone mode does not prevent your users from manually updating the app. During the 90-day postponement period, your users can manually update the app by visiting the Google Play Store on their devices.
Here’s an illustrative example of expected update behavior when using the Postpone mode:
| May 1 |
The app is up to date on the device.
Installed version: 1.0
Latest available version: 1.0
|
| May 2 |
The developer publishes a new version (2.0). The 90-day period starts and will finish on July 31.
Installed version: 1.0
Latest available version: 2.0
|
| June 6 |
The developer publishes a new version (3.0).
Installed version: 1.0
Latest available version: 3.0
|
| July 11 |
The developer publishes a new version (4.0).
Installed version: 1.0
Latest available version: 4.0
|
| July 31 |
The 90-day period ends, the app is added to the update queue and will be automatically updated according to the default update behavior, once the constraints are met.
Installed version: 1.0
Latest available version: 4.0
|
| August 1 |
The constraints are met and therefore the app is updated to the latest available version (4.0).
Installed version: 4.0
Latest available version: 4.0
|
| August 15 |
The developer publishes a new version (5.0). A new 90-day period starts and will finish on November 13.
Installed version: 4.0
Latest available version: 5.0
|
Set network constraints
If you select High priority mode or Postpone mode for an app, then the network constraints are ignored for that app.
You can set the network constraint and override the app update setting, set by the end user. You can choose one of the following options:
- Update apps over any network.
- Update apps over Wi-Fi only (this is the default setting).
- Do not update apps.
- Leave the choice to the end user.
Note that enforcing the network constraint doesn’t affect the other constraints, which still apply, and apps are only be updated when:
- The device is charging.
- The device is idle (not actively used).
- The app to be updated is not running in the foreground.
To override these other constraints, you can set a maintenance window (go to the section below).
Set a maintenance window
If you select High priority mode or Postpone mode for an app, then the maintenance window is ignored for that app.
You can set a maintenance window during which the following constraints are ignored:
- The device is charging.
- The device is idle (not actively used).
- The app to be updated is not running in the foreground.
The maintenance window is defined by a start time (local time of the device) and a duration (between 30 minutes and 24 hours).
Note that setting a maintenance window doesn’t affect the network constraint, which is managed separately.
It can take up to 24 hours for an app update to be added to the update queue. After an app is added to the queue, it will be updated automatically the next time the device is in the maintenance window, if the network constraint is met. As a result, it can take up to 48 hours for an app to update after you set a maintenance window.
Set a minimum version code
If the minimum version code is set to a value greater than the current version installed on the device, the app will be updated, ignoring default auto-install constraints. However, auto-install constraints set by the IT admin still apply.
There is no admin constraint to require that the app is not running in the foreground. This means when using minimum version code, the default foreground constraint is always ignored and the app will be closed if it is running in the foreground when the update occurs.
Other factors affecting app updates
There are a few other factors that may influence the timing and speed of app updates on Android devices:
- App release settings: Android app developers can roll out app updates gradually. As a result, an app update may initially only be available to some devices in your fleet.
- Pending installs: App updates are queued and installed one at a time. If a device has several apps with pending updates, it may take longer than expected to install all the updates.
Common scenarios for updating apps
Ensure updates are delivered regularly
By default, updates are delivered regularly while minimizing their impact on user experience, battery life, and mobile data consumption. For most devices and apps, this default update behavior is sufficient.
Deliver updates as soon as possible
If you want an app to be updated as soon as possible after the developer publishes a new version, or if you need all your devices to have the latest version of an app, you can select the High priority update mode for that app. Note that this mode can interrupt the on-device experience for your users.
Prevent apps from updating while the device is in use
By default, apps aren’t updated when a device is in use. This constraint is ignored when you select the High priority mode or set a maintenance window in your EMM console. As a result, we recommend using the High priority mode only when you really need the app to be updated as soon as possible. We also recommend selecting a maintenance window during a time when a device isn’t typically in use (overnight, for example).
Temporarily turn off app updates
Turning off app updates isn’t recommended, as you may miss critical security fixes from developers, but you may need to do this on a temporary basis to prevent any unexpected change on devices during a critical time. In your EMM console, for specific apps that you want to prevent being updated during critical periods, you can select the Postpone mode. This will ensure that an app is not updated for 90 days after it first became out of date.
Validate the new version of an app before deploying it
To validate the new version of an app you developed before you deploy it to a fleet of devices, you can set up closed testing for that app. With closed testing you can manage testers through Google Groups or directly from your EMM console if your EMM supports this feature. If you don’t find this feature in your EMM console, contact your EMM.
For apps that your organization didn’t develop, you can contact the app developer to have them set up closed testing for you. It’s not possible to validate the new version of an app without closed testing.
Alternatively, you can also refer to the section above to temporarily turn off app updates for a given app.
Frequently asked questions
Can I prevent app updates on a work profile?
Android devices maintain a single version of an app, even if the app is installed in both a personal profile and work profile. This means apps installed in both profiles are updated at the same time. As a result, it’s not possible to prevent app updates on a work profile since apps can be updated from the personal profile.
Can I choose which version of an app to install?
No, you can’t choose which version of an app to install or to update to. Only the latest available version of an app can be installed.
Can I turn off updates for Google Play Store and Google Play Services?
No, you can’t turn off updates for Google Play Store and Google Play Services. Updates to these apps are critical to the security and reliability of devices.
Troubleshooting
If apps aren’t updating automatically on the devices you manage after following the best practices in this article, we recommend sending a bug report to your EMM:
- In your EMM console, select the High priority update mode for the affected apps.
- Be sure you have Developer Options turned on.
- Connect the device to your computer and agree to allow USB debugging if prompted.
- At the terminal, enter the command in the code snippet below, then collect a bug report and send it to your EMM for inspection.
adb logcat -G 32M; adb shell setprop persist.log.tag.dpcsupport VERBOSE; adb shell setprop persist.log.tag.Finsky VERBOSE; adb shell setprop persist.log.tag.Auth VERBOSE; adb shell setprop persist.log.tag.PackageManager VERBOSE; adb shell setprop persist.log.tag.JobScheduler VERBOSE