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.
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.
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
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
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
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
Prevent apps from updating while the device is in use
Temporarily turn off app updates
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