Prevent automatic app updates via Google Play that may disrupt business workflows;

Schedule updates during off-hours (e.g., at night or on weekends) to avoid peak impact;

Enforce mandatory upgrades for critical apps to ensure version consistency and functionality;

Combine with “App Publishing Policy” to manage test vs. production versions;

Fine-tune update network strategies (e.g., avoid mobile data usage) per device group.

GP App Update Policies only support Google Play Public and Private apps, and can only be applied to GMA-type devices;

Each app can only have one update policy. If multiple policies are configured, only the latest version will apply according to the stacking and overwrite mechanism;

Policies are not delivered immediately upon creation—they follow the defined "App Distribution Schedule";

GP update policies do not include compliance detection or enforcement mechanisms;

Once delivered, the policy cannot be revoked from the device.

Click [Create App Update Policy] in the upper right to begin;

Enter a policy name;

Select Google Play apps to manage (only Public/Private apps are supported);

Click [Next] to configure update behavior.

Choose an update mode (Default / Postpone / Immediate):

Click [Next] to configure device scope.

Choose how the policy will be delivered:

Set the distribution time:

Click [Submit] to complete the policy creation.

Only applicable to KMA / IMA devices. Not supported on GMA devices;

Supported app types: Enterprise Private Apps, Enterprise Public Apps, Enterprise Web Apps;

Apps must be in Published status to be used in an update policy;

Two version update modes are supported:

Strategy modules must be explicitly enabled. Disabled modules won’t be included in policy stacking;

If multiple KC policies exist, they are evaluated by “module merge, latest wins” logic;

App auto-start after update only applies to selected apps where this setting is enabled;

Distribution plan and device scope can be: Immediate / Scheduled; All Devices / Partial (grey release) / Percent-based;

After submission, the policy enters a “Pending Review” state and must be approved (if approval is enabled).

Click [Create Policy] and choose "KC App Update Policy";

Enter a policy name;

In the "Select Apps" step, choose the target enterprise apps;

Select the app version (“Latest” or a specific version);

Click [Next] to proceed.

Enable the “App Update Mode” module to include it in policy stacking;

Enable the “Start After Update” module to auto-launch the app after updating.

Update Mode (select one):

Network Control (select one):

Immediate: Updates are triggered as soon as the device receives the policy;

Start Time: Updates will be executed at the defined time only if the device receives the command before that time;

Time Window: Updates are allowed only within a specific window (daily/weekly).

Enable “Start After Update” and select which apps should auto-launch post-update;

Recommended for critical foreground apps like POS or ordering systems.

Choose the Device Scope:

Choose Effective Time:

Click [Submit] to complete creation. The policy enters "Pending Review".

Go to the policy list and filter by Pending Review;

Click [Approve];

In the popup, click Approve, and the system will deliver the policy immediately or at the scheduled time;

After approval, policy status becomes Published.

Only policies in “Draft” status can be submitted;

If the platform has not enabled the approval process, submission will immediately change the policy status to “Published,” bypassing review;

Submission is irreversible. Ensure the policy content is correct before proceeding;

Submitted policies cannot be edited directly. Use the “Edit” function to create a new version if changes are needed;

Once submitted, the policy will be distributed according to the configured update schedule and device scope.

After successful submission, the policy status updates to “Pending Review”;

If approval is not enabled, the system will automatically mark the policy as “Published” and begin distributing it per the delivery schedule;

Submission events are automatically recorded in the operation log.

Only policies with “Pending Review” status can be approved;

If the approval process is not enabled, the policy will automatically become “Published” upon submission, bypassing this step;

Approval actions are irreversible — verify policy content before proceeding;

Once approved, the policy takes effect immediately and cannot be delayed;

If rejected, the policy reverts to “Draft” status and must be modified and resubmitted;

All approval actions are logged and traceable through the operation log.

Click Approve: The policy status updates to “Published,” and the system will distribute it according to the delivery plan.

Click Reject: The policy reverts to “Draft” and must be edited before resubmission.

The result will be reflected in the policy list immediately;

Approval records can be viewed in the Operation Log.

Open the App Update Policy module;

Locate the target policy and click the [Details] button in its row.

Policy name and ID;

Current version (with dropdown to switch versions);

Creator, last modified time, and update time;

Number of associated apps, devices, and device groups.

App name and icon;

Package name;

Category (business tag);

Source (Enterprise Private / Public / Web App / Google Play Public / Private App);

Version (e.g., “Latest” or specific version);

Update Mode: Default / Prompt / Force;

Update Control Method: e.g., Disable auto update, WiFi only, etc.;

Distribution Schedule: Immediate, Scheduled Time, or Time Window;

Auto Launch After Update: Whether enabled and list of apps.

Update Schedule (Immediate / Scheduled);

Device Scope: by group or individual devices;

Device list: includes name, model, SN, group info.

Status of Required and Whitelisted Apps;

For Required Apps: shows the number of required devices and actual installations, supports exporting the delta list;

For Whitelisted Apps: shows how many devices currently have the app installed;

Supports filtering by app name, package name, device name, or serial number.

Actions: Submit, Approve, Edit, Disable, Enable, etc.;

Operator and timestamp;

Execution result (Success / Failure);

Policy push operations;

App update triggers;

Retry logic;

Error details;

Only policies in Published status can be edited; Draft, Disabled, and Archived statuses are not editable.

Each edit creates a new policy version; previous versions become read-only.

Review the current policy impact and related devices before editing to avoid unintentional changes.

Edited policies must be resubmitted and approved (if approval is enabled) to take effect.

You can save your edits as a draft at any time before submission.

All modifications are logged in the Operation Log and Version History.

Only policies in Published status can be pushed. Policies in Draft, Pending Review, Disabled, or Archived status cannot be pushed.

For KC App Update Policies, if no configuration changes are detected or the device is in normal status, the system may skip redundant push actions.

For offline devices, the policy will be automatically pushed once the device comes online — no repeated action is needed.

When policy stacking is applied, the final configuration is calculated using module-level merge and latest override for the same module.

IMA devices cache push instructions for a limited time; if exceeded, re-push is required.

All push actions are recorded in the Operation Log and System Log for traceability.

Only policies in Published status can be disabled.

Once disabled, all update rules defined in the policy will stop taking effect on the device side.

Associated devices will trigger a recalculation of the policy stack and may automatically apply a default policy (if configured).

Disabling a policy does not delete its contents or version history.

The policy can be re-enabled later via the Enable Policy action.

All disable actions are logged in the Operation Log for auditing and tracking.

Only policies in Disabled status can be enabled.

Once enabled, the policy status changes to Published without requiring resubmission or approval.

Enabling does not modify the policy content or version number.

The configuration will be re-issued to bound devices, which may trigger update actions.

For offline devices, the strategy will be cached and applied automatically when the device comes online.

All enable actions are recorded in the Operation Log for auditing purposes.

Only policies in the Disabled state can be archived.

Archiving will permanently remove all bindings with devices, groups, and apps and cannot be undone.

Archived policies can still be restored to Draft status using the Restore action for reuse.

Please proceed with caution—archiving is irreversible.

All archive actions are logged in the Operation Log for audit tracking.

Only policies in Archived status can be restored.

Restoration does not automatically reinstate the original bindings with devices, groups, or apps—these must be reconfigured manually.

The restored policy returns to Draft status and can be edited and submitted as a new version.

All restore actions are recorded in the Operation Log for auditing and tracking.

It is recommended to verify and update the configuration immediately after restoring to avoid applying outdated settings.

Only policies in Archived status can be deleted.

This is a logical deletion: the platform will remove the policy's visibility from both the UI and API.

Deleted policies are permanently removed—they cannot be restored, viewed, or reverted to draft.

Deletion does not impact devices that have already received the policy; it does not retroactively remove past deployments.

All delete actions are fully recorded in the Operation Log for audit purposes.

Across different modules: configurations are merged and applied together;

Within the same module: the latest bound policy module takes precedence.