Unified Update Controls

Unified Update Controls (UUC) give IT admins a single, consistent way to control when software updates are downloaded and applied on company-owned Android devices, so that updates don't disrupt business operations.

With one UUC policy, you can control updates for the following software components:

• OS updates issued by the device manufacturer (OEM), including major OS updates and minor OS and security updates.
• Google Play system updates (Mainline).
• Google system services, such as Google Play services and Android System WebView, either as a group or one app at a time.

You define UUC rules in the unifiedUpdatePolicy field of a Policy resource. The Android Device Policy (ADP) app is the central on-device decision point for UUC.

Prerequisites

Before configuring UUC, verify the following requirements:

• Your EMM solution can create and update policies for an enterprise.
• The devices are company-owned, configured either as a fully managed device or with a work profile on a company-owned device. UUC isn't supported on personally owned devices.
• The devices meet the minimum supported Android version for each update target you want to control, as shown in the following table:

Considerations and limitations

Review the following considerations and limitations before planning your UUC integration:

• Initial setup wizard: UUC policies aren't enforced while the device is in the initial setup wizard. Critical updates from Google Play or the OEM OTA agent can occur during device setup.
• Early updates after setup: UUC policies might not apply to automatic updates that start immediately after device setup, such as early updates to Google Play services, before the policy reaches ADP.
• Bundled OTA modules: OEM OTA updates can contain updated versions of Mainline modules and Google system services. Installing an OEM OTA update automatically updates those bundled components.
• Google Play system updates (Mainline): UUC controls the Mainline update as a single unit, so individual Mainline packages can't be controlled independently. UUC only governs the start of the download phase: once a Mainline download begins, it can't be stopped. If a BLOCK rule is applied after the download starts, the update still completes on the next device reboot.
• Manual updates during block periods: For Google Play system updates (Mainline) and Google system services, a BLOCK rule only prevents automatic updates. Users can still manually update these components even when a BLOCK rule is active. This will be addressed in a future release.
• Exempt applications: UUC doesn't manage updates for the Google Play Store app or the ADP app.

Understand UUC policies

A UnifiedUpdatePolicy consists of an ordered list of Rule objects. Each rule specifies:

• an identifier (id) defined by your EMM solution
• one or more software update targets
• optional evaluation stages.
• one or more optional predicates containing time-based conditions
• an outcome that determines how the update is handled

Rule evaluation

When evaluating a pending update, ADP considers all rules that apply to that update's target and stage, in the order they appear in rules. ADP selects the first rule whose predicate evaluates to true and applies its outcome, like a chained if-else statement. If no rule's predicate evaluates to true, the update client responsible for the component manages the update normally.

Rule identifiers

Each rule requires an id of up to 64 characters that your EMM solution defines. The id must not be empty and must be unique among the rules of a policy.

Update targets

Each rule must specify a non-empty list of targets without duplicates. Specifying multiple targets in a single rule is equivalent to defining multiple rules in sequence, each with a single target, in the same order.

The following table describes the supported targetType values:

Evaluation stages

For OS_UPDATE_WITH_API_LEVEL_CHANGE and OS_UPDATE_WITHOUT_API_LEVEL_CHANGE targets, you can optionally specify the stages at which a rule is evaluated:

• STAGE_DOWNLOAD: The rule is evaluated before downloading the update.
• STAGE_APPLY: The rule is evaluated before taking an action that applies the update, such as triggering an automatic reboot.

If stages is empty, the rule is evaluated at all stages. Note: For GOOGLE_SYSTEM_SERVICES, SINGLE_APP, and GOOGLE_PLAY_SYSTEM_UPDATE targets, stages are ignored.

Predicates

A predicate defines time-based conditions under which a rule matches—such as the days of the week, a time-of-day window (at hour granularity), a calendar date range in the device's local time zone, or how long the update has been available to the device (in multiples of 24 hours).

All conditions set within a single predicate are combined using a logical AND. An empty or omitted predicate always evaluates to true. For the full list of predicate fields and their constraints, see the Predicate reference documentation.

Outcomes

An outcome specifies how ADP instructs the update agent to proceed when a rule's predicate evaluates to true. The following table describes the supported outcomeType values:

Maximum deferral limits

UUC allows deferring updates with a BLOCK or USER_PROMPT outcome up to a maximum deferral period for each update target. Once an update has been available for longer than its maximum deferral period, any BLOCK or USER_PROMPT outcome is overridden to default, and the update client manages the update normally.

The following table lists the maximum deferral limits by target and management mode:

Precedence of systemUpdate

Before you add unifiedUpdatePolicy to an existing policy, review its systemUpdate settings and recreate the behavior you need with UUC rules. For example, to keep OS updates out of business hours, use a BLOCK rule like the one in Block major OS updates during business hours.

This precedence behavior differs from custom DPCs that use the AMAPI SDK, where an AOSP SystemUpdatePolicy takes precedence over UUC for OEM OTA updates. For details, see AOSP SystemUpdatePolicy precedence.

Configure the UUC policy

You can set, retrieve, and clear the unifiedUpdatePolicy field on a policy resource, and check device compliance for devices that use the policy.

Set the UUC policy

To configure UUC, add a unifiedUpdatePolicy object to the policy. To apply the UUC policy without changing the other settings of an existing policy, call enterprises.policies.patch with updateMask=unifiedUpdatePolicy:

PATCH https://androidmanagement.googleapis.com/v1/enterprises/{enterpriseId}/policies/{policyId}?updateMask=unifiedUpdatePolicy

{
  "unifiedUpdatePolicy": {
    "rules": [
      {
        "id": "Block Policy",
        "targets": [
          {
            "targetType": "OS_UPDATE_WITH_API_LEVEL_CHANGE"
          }
        ],
        "predicate": {
          "daysOfWeek": [
            "MONDAY",
            "TUESDAY",
            "WEDNESDAY",
            "THURSDAY",
            "FRIDAY"
          ],
          "timeOfDayLowerBound": { "hours": 9 },
          "timeOfDayUpperBound": { "hours": 17 }
        },
        "outcome": {
          "outcomeType": "BLOCK"
        }
      }
    ]
  }
}

The updated policy is applied to all devices that use it. ADP evaluates the rules on each device whenever an update is available for a controlled component.

Retrieve the UUC policy

To read the configured UUC rules, call enterprises.policies.get and inspect the unifiedUpdatePolicy field of the returned policy:

GET https://androidmanagement.googleapis.com/v1/enterprises/{enterpriseId}/policies/{policyId}

Clear the UUC policy

To remove all UUC rules from a policy, call enterprises.policies.patch with updateMask=unifiedUpdatePolicy and a request body that doesn't contain unifiedUpdatePolicy:

PATCH https://androidmanagement.googleapis.com/v1/enterprises/{enterpriseId}/policies/{policyId}?updateMask=unifiedUpdatePolicy

{}

Policy configuration examples

The following examples show the unifiedUpdatePolicy object for common scenarios. Apply them with enterprises.policies.patch as described in Set the UUC policy. The same scenarios are available as Kotlin and Java code in Configure Unified Update Controls with the AMAPI SDK.

Block major OS updates during business hours

The following rule blocks major OS updates (OS_UPDATE_WITH_API_LEVEL_CHANGE) from 09:00 to 17:00, Monday through Friday:

{
  "unifiedUpdatePolicy": {
    "rules": [
      {
        "id": "Block Policy",
        "targets": [
          {
            "targetType": "OS_UPDATE_WITH_API_LEVEL_CHANGE"
          }
        ],
        "predicate": {
          "daysOfWeek": [
            "MONDAY",
            "TUESDAY",
            "WEDNESDAY",
            "THURSDAY",
            "FRIDAY"
          ],
          "timeOfDayLowerBound": { "hours": 9 },
          "timeOfDayUpperBound": { "hours": 17 }
        },
        "outcome": {
          "outcomeType": "BLOCK"
        }
      }
    ]
  }
}

Force OS updates by update age

The following rule forces major OS updates that have been available to the device for up to 7 days (604800s):

{
  "unifiedUpdatePolicy": {
    "rules": [
      {
        "id": "Force Policy",
        "targets": [
          {
            "targetType": "OS_UPDATE_WITH_API_LEVEL_CHANGE"
          }
        ],
        "predicate": {
          "updateAgeUpperBound": "604800s"
        },
        "outcome": {
          "outcomeType": "FORCE"
        }
      }
    ]
  }
}

Block updates for a single Google system service app

To control a specific app that is part of Google system services, such as Android System WebView (com.google.android.webview), set targetType to SINGLE_APP and provide the app's packageName in singleApp. The following rule blocks WebView updates from 09:00 to 17:00, Monday through Friday:

{
  "unifiedUpdatePolicy": {
    "rules": [
      {
        "id": "Block Webview Policy",
        "targets": [
          {
            "targetType": "SINGLE_APP",
            "singleApp": {
              "packageName": "com.google.android.webview"
            }
          }
        ],
        "predicate": {
          "daysOfWeek": [
            "MONDAY",
            "TUESDAY",
            "WEDNESDAY",
            "THURSDAY",
            "FRIDAY"
          ],
          "timeOfDayLowerBound": { "hours": 9 },
          "timeOfDayUpperBound": { "hours": 17 }
        },
        "outcome": {
          "outcomeType": "BLOCK"
        }
      }
    ]
  }
}

Combine multiple rules across all update targets

Because rules are evaluated in order, you can combine multiple rules to block updates during specific windows and force updates outside those windows.

The following example applies two sequential rules across the four category targets (OS_UPDATE_WITH_API_LEVEL_CHANGE, OS_UPDATE_WITHOUT_API_LEVEL_CHANGE, GOOGLE_SYSTEM_SERVICES, and GOOGLE_PLAY_SYSTEM_UPDATE):

1. Block all updates during business hours (Monday–Friday, 09:00 to 17:00).
2. Outside business hours, force updates that have been available for up to 7 days.

{
  "unifiedUpdatePolicy": {
    "rules": [
      {
        "id": "Block Policy - rule1",
        "targets": [
          { "targetType": "OS_UPDATE_WITH_API_LEVEL_CHANGE" },
          { "targetType": "OS_UPDATE_WITHOUT_API_LEVEL_CHANGE" },
          { "targetType": "GOOGLE_SYSTEM_SERVICES" },
          { "targetType": "GOOGLE_PLAY_SYSTEM_UPDATE" }
        ],
        "predicate": {
          "daysOfWeek": [
            "MONDAY",
            "TUESDAY",
            "WEDNESDAY",
            "THURSDAY",
            "FRIDAY"
          ],
          "timeOfDayLowerBound": { "hours": 9 },
          "timeOfDayUpperBound": { "hours": 17 }
        },
        "outcome": {
          "outcomeType": "BLOCK"
        }
      },
      {
        "id": "Force Policy - rule2",
        "targets": [
          { "targetType": "OS_UPDATE_WITH_API_LEVEL_CHANGE" },
          { "targetType": "OS_UPDATE_WITHOUT_API_LEVEL_CHANGE" },
          { "targetType": "GOOGLE_SYSTEM_SERVICES" },
          { "targetType": "GOOGLE_PLAY_SYSTEM_UPDATE" }
        ],
        "predicate": {
          "updateAgeUpperBound": "604800s"
        },
        "outcome": {
          "outcomeType": "FORCE"
        }
      }
    ]
  }
}

Restrict updates until a calendar date

You can use dateLowerBound and dateUpperBound to restrict or allow updates within a specific calendar date range in the device's local time zone. The following rule blocks updates for the four category targets until March 14, 2026:

{
  "unifiedUpdatePolicy": {
    "rules": [
      {
        "id": "block_until_date",
        "targets": [
          { "targetType": "OS_UPDATE_WITH_API_LEVEL_CHANGE" },
          { "targetType": "OS_UPDATE_WITHOUT_API_LEVEL_CHANGE" },
          { "targetType": "GOOGLE_SYSTEM_SERVICES" },
          { "targetType": "GOOGLE_PLAY_SYSTEM_UPDATE" }
        ],
        "predicate": {
          "dateUpperBound": { "year": 2026, "month": 3, "day": 14 }
        },
        "outcome": {
          "outcomeType": "BLOCK"
        }
      }
    ]
  }
}