1. Features and Purpose
The "Application Publishing Policy" module is used to centrally control app installation and behavior permissions on enterprise endpoint devices. Administrators can create different policy types (GP App Policy / KC App Policy) based on device type (GMA / KMA / IMA), and designate specific apps as "Mandatory Install", "Allowlisted", or "Prohibited" to ensure consistent security control and operational efficiency.
The platform supports full policy lifecycle management, including creation, configuration, submission, approval, publishing, editing, disabling, reverting, and deletion. Policies can be associated with specific devices or device groups to implement differentiated, multi-tiered deployments.
Notes:
GP App Policies apply only to GMA devices and support Google Play public/private apps only.
KC App Policies apply to KMA and IMA devices and support enterprise private apps, enterprise public apps, and enterprise web apps.
The platform uses a "merge between modules, most recent configuration within the same module prevails" stacking mechanism to support coexisting and updated policies.
Only apps in "Published" status can be included in policy configuration.
When the "Non-compliance Handling" feature is enabled, the system will automatically enforce actions (e.g., device lock, factory reset) if a device fails to meet policy requirements.
Primary Actions:
Action | Description |
Create GP App Policy | Create a policy for GMA devices, configuring Google Play public/private apps. Supports mandatory apps, whitelist/blacklist, and app removal. Also supports dynamic and runtime permissions. |
Create KC App Policy | Create a policy for KMA/IMA devices, configuring enterprise private/public/web apps. Supports default launch app, uninstall protection, and dynamic permission control. |
Secondary Actions:
Action | Description |
Submit | Submit a draft policy for approval, moving it to "Pending Review" (if policy approval is enabled). |
Approve | Admin approves or rejects pending policies to determine whether the policy takes effect. |
View Details | View policy version info, configuration details, associated devices/groups, and activity logs. |
Edit | Create a new version of a published policy to adjust configurations and scope. |
Deploy Policy | Manually push the policy to associated devices to enforce or re-apply policies. |
Enable/Disable | Control whether the policy takes effect on devices. Disabled policies are removed from the stack; enabled policies re-enter the stack. |
Revert Policy | Revert an archived policy to draft for reuse or modification. |
Delete | Permanently remove an archived policy. This action is irreversible. |
Typical Use Cases
Define a default app policy for new devices to ensure compliance at first deployment.
Restrict store terminals to run only approved apps, preventing unauthorized installations.
Combine with “Device Grouping” to apply differentiated policies based on region or business type.
Distribute new app versions via policy to streamline app updates.
Use "Mandatory Install + Whitelist" to ensure system stability and security.
2. Primary Operations
2.1 Create GP App Policy
Description
The GP App Policy is used to deliver Google Play apps (public/private/web) to GMA-type devices. This policy supports configuration of app installation behavior (mandatory, whitelist/blacklist, removal), permission management (authorization control), app configurations (predefined parameters), and accessibility service authorization. Administrators can standardize app environments across devices by defining which Google Play apps are available and how they behave.
The platform follows a "merge between modules, and the most recent config within the same module prevails" stacking logic. Policy configurations will participate in the final device configuration based on the enabled modules. Once created, the policy can be released to devices/groups immediately, gradually, or by percentage, and supports scheduled deployment.
Notes
GP App Policy only applies to GMA-type devices, not applicable to KMA or IMA devices.
This policy only supports Google Play Public Apps, Private Apps, and Web Apps.
Only apps in "Published" status can be added to a policy.
The policy stacking follows the principle of "merge between modules, latest config within the same module prevails":
Different modules across policies are merged;
The same module uses the configuration from the latest active policy.
Modules not enabled will not participate in merging or configuration delivery.
Once published, the policy takes effect immediately on bound devices; gradual rollout is recommended for testing.
Policy content cannot be edited directly after publication; to modify, create a new version via "Edit Policy".
If Non-compliance Handling is enabled, the system will enforce actions if a device violates the policy (e.g., uninstalling a mandatory app), as per System Settings → Compliance Settings:
Choose from "Disable Device" or "Factory Reset".
The enforcement logic is handled by the system; the policy only triggers the rule.
Use whitelist and blacklist settings carefully to avoid conflicts between policies.
Distribution mode (Immediate, Scheduled, Gradual, By Percentage) affects deployment scope and timing; align with rollout plans.
Steps
1. Configure Basic Policy Info
Click [Create Policy] and select "GP App Policy";
Enter the policy name (required);
Set the Non-compliance Handling switch (default: off) to define enforcement behavior.
2. Configure App Deployment Behavior
2.1 Choose App Types
Supported: All Google Play Apps, Google Play Public Apps, Google Play Private Apps
2.2 Choose Deployment Modes
Three types of deployment options are available (can be used independently or together):
Required App: The app must be installed and remain installed. If uninstalled, the system auto reinstalls it.
Blocklist / Allowlist:
Blocklist : Prevents installation of listed apps.
Allowlist: Restricts installation to only the listed apps.
Cannot use allowlist and blocklist simultaneously.
Delete Apps: Removes the app from associated devices/groups regardless of its status. If the app is listed under "Required App" or "Allowlist" in the same policy, it cannot be marked for removal.
3. Configure App Behavior
3.1 App Configuration
For Android Enterprise apps that support managed configurations, you can set custom parameters.
Example: For Slack, preconfigure team name, domain, login settings, etc.
All configurations will be pushed to the device after policy release.
3.2 App Permissions
Set permissions on a per-item basis:
Deny / Prompt / Grant
Examples include access to contacts, storage, and network status.
3.3 Accessibility Settings
For apps that require Accessibility Services, you can pre-authorize here.
The system will prompt and enable it if supported.
If not enabled here, users can manually grant it later.
4. Configure Policy Deployment Scope
4.1 Deployment Schedule
Set when the policy takes effect:
Immediate: Policy activates upon creation;
Scheduled: Set a start time for deployment.
4.2 Target Devices
All Devices: All GMA devices under your organization;
Targeted Deployment: Select specific devices or groups;
Proportional: Deploy by random percentage for phased rollout.
You can define multiple phases like 10% → 30% → 60%;
The system randomly selects the device samples.
5. Approve GP App Policy
In the policy list, filter by "Pending Review";
Click the [Approve] button in the action column;
In the confirmation popup, choose Approve or Reject;
If approved, the policy status changes to "Published" and is pushed immediately or as scheduled;
If rejected, the policy remains in "Draft" and needs editing and resubmission.
2.2 Create KC App Policy
Description
The KC App Policy is used to distribute enterprise public, private, or web apps to KMA/IMA-type devices. This policy supports configuring installation behaviors (mandatory, blacklist/whitelist, removal), app settings (default launch, uninstall protection, dynamic permissions), and more. It ensures consistency, control, and security for enterprise apps on managed devices. After creation, the policy can be released to devices or groups immediately, gradually, or by percentage, with support for scheduled publishing.
Notes
KC App Policy is only applicable to KMA and IMA devices and not supported on GMA devices.
Only Enterprise Public Apps, Enterprise Private Apps, and Enterprise Web Apps can be configured.
Only apps in Published status can be added to the policy.
Policies follow the "merge between modules, and the most recent config within the same module prevails" stacking logic:
Different modules in multiple policies will be merged;
The same module follows the configuration from the latest effective policy.
Modules must be enabled manually. Disabled modules will not participate in stacking or enforcement.
Policies take effect on bound devices upon creation. Use gradual or percentage-based rollout for pilot testing.
Policies cannot be modified directly after publishing; create a new version via "Edit Policy" if changes are needed.
If Non-compliance Handling is enabled and the device fails to meet policy requirements (e.g., a mandatory app is uninstalled), actions will be executed based on System Settings → Compliance Settings:
Actions include "Disable Device" or "Factory Reset";
Violation detection and enforcement are managed by the system; the policy only acts as a trigger.
When a mandatory or Allowlisted app is set to use the "latest version," the system will automatically upgrade it using Immediate Update + Forced Install + WiFi First.
If the app has an associated update policy, the update policy will take precedence.
The "Remove App" module is mutually exclusive with other modules (mandatory, whitelist, blacklist); combine carefully based on business needs.
Only one app can be set as the default launch app per policy. If multiple apps are selected, only the first one will take effect.
Steps
1. Configure Basic Policy Info
Click [Create Policy] and select "KC App Policy";
Enter the policy name (required);
Toggle Non-compliance Handling to define violation enforcement (default: off);
Proceed to the "Select Apps" screen to configure the policy modules.
2. Configure App Deployment Behavior
2.1 Select App Types
Supported types: Enterprise Private App, Enterprise Public App, Enterprise Web App;
Apps must be in Published status to be configured and deployed.
2.2 Configure Distribution Modes
The following modules can be enabled independently:
Required App
Enforces app installation on devices;
If removed or damaged, the system will reinstall it automatically;
Users cannot uninstall it manually.
Blocklist / Allowlist
Blocklist : Prohibits installation of the app. If detected, it will be uninstalled;
Allowlist: Only Allowlisted apps can be installed. All others are blocked;
Allowlist and Blocklist cannot be enabled simultaneously.
Delete App
Uninstalls the app from the associated devices/groups;
Does not consider whether the app is in other modules (Required App/Allowlist/Blocklist);
If the app is not present on the device, no action is taken.
3. Configure App Behavior
3.1 App Configuration Modules (independently enabled)
Once enabled, modules participate in policy enforcement. Disabled modules have no effect.
Default Launch (single selection): Set the app to auto-start on device boot;
Uninstall Protection (multi-selection supported): Prevent users from uninstalling the app;
Dynamic Permissions: Grant system-level special permissions (see parameter description).
4. Define Policy Deployment Scope
4.1 Deployment Plan
Options:
Immediately: Deploy immediately after policy creation;
Start Time: Deploy at a specified time;
Time Slot: Define daily/weekly time slots for execution (ideal for non-peak hours).
4.2 Target Devices
All Devices: All KMA/IMA devices under the organization;
Targeted Deployment: Select specific devices or device groups;
Proportional: Define a percentage rollout. Devices are randomly selected and deployed in phases.
5. Approve KC App Policy
Go to the policy list and filter for policies in "Pending Review";
Click the [Approve] button;
Select Approve or Reject;
Once approved, the policy status updates to Published.
3. Secondary Actions
3.1 Submit
Description
This action is used to submit application publishing policies in draft status to the platform's approval workflow. After submission, the policy status changes to "Pending Review" and must be approved by an administrator (if the "App Publishing Policy Approval Workflow" is enabled). Only after approval can the policy be released and applied to devices.
Policies typically enter draft status either by being restored from "Archived" or after being newly created or edited.
Notes
Policies in draft status can be edited, saved, or submitted directly;
If the approval workflow is disabled, the submission will bypass "Pending Review" and the policy will immediately switch to "Published";
There is no confirmation dialog for submission—please ensure the policy is correct before proceeding;
Submitted policies cannot be edited. To make changes, a new version must be created.
Steps
Access Draft Policies
In the "App Publishing Policy" module, filter policies with the status "Draft";
Initiate Submission
Click the [Actions] button next to the target policy and select [Submit];
The system will submit the policy immediately with no confirmation prompt;
Submission Complete
The policy status changes to "Pending Review" and appears in the approval list;
Admins can configure approval rules under System Settings → Others → Approval Workflow Toggle.
3.2 Approve
Description
This action is used to review and approve submitted application publishing policies, determining whether the policy is allowed to be published to associated devices.
Notes
If the "App Publishing Policy Approval Workflow" is disabled, the policy will skip the "Pending Review" status and go directly to "Published" after submission;
Once approved, the policy status will change to "Published", and the system will deliver the policy to target devices according to the configured release time;
If not approved, the policy will revert to "Draft" and require editing and resubmission;
Approval actions cannot be undone, so proceed with caution.
Steps
Go to the App Publishing Policy page and locate the policy with status "Pending Review";
Click the [Approve] button next to the policy to open the approval confirmation dialog;
In the popup dialog, choose Approve or Reject:
Click Approve: Policy status changes to Published;
Click Reject: Policy status reverts to Draft;
After the action, the page will update, and the policy will proceed according to the specified workflow.
3.3 Details
Description
This feature is used to view the full details of an app publishing policy, including basic information, selected apps, configuration items, publishing scope, delivery status, and execution logs. It supports all policy statuses for both KC and GP policy types, helping administrators with policy review, effectiveness monitoring, and troubleshooting.
This page is an important entry point for policy lifecycle management. It provides visibility into bound groups/devices, version changes, non-compliant devices, and detailed module configurations.
Steps
Access the Policy Management Interface
Open the App Publishing Policy module;
Locate the target policy in the list and click the Details button on the corresponding row to enter the policy details page.
View Policy Overview
The top section of the page displays core policy information:
Policy Name and ID;
Last Modified Time, Most Recent Deployment Time;
Version Number (with support for viewing historical versions);
Bound groups/devices and number of non-compliant devices.
Browse Policy Content
The policy detail page includes several tabs for modular viewing:
Selected Apps
Whether "Non-compliance Handling" is enabled;
Details of apps configured as Mandatory Install, Blacklist, Whitelist, or Delete;
Whether each app is set to "Latest Version" and its update behavior;
Configure App
Display status of modules such as Default Launch, Uninstallation Protection, and Dynamic Permissions;
Shows parameters and values for each configured module;
Deployment Configuration
Shows strategy timing settings (Immediate / Scheduled / Time Window);
Shows delivery method (All Devices / Gradual Rollout / Percentage-based Deployment);
Installation Progress
View the progress of Mandatory and Whitelist apps;
For Mandatory Apps: displays required device count and actual installed count, supports export of missing data;
For Whitelist Apps: displays the number of devices that currently have the app installed;
Supports filtering app installation data by app name, package name, device name, or serial number;
Deleted Devices
Planned Device Deletion Count: total number of devices targeted for app deletion;
Actual Device Deletion Count: number of devices where the app was successfully removed;
Operation Logs
Records of user actions on the policy such as submit, approve, modify, deactivate, etc.;
Displays operator name, time, and action details;
System Logs
Records of automated platform actions such as policy deployment, version activation, retry attempts, and non-compliance handling;
Useful for diagnosing issues when policies are not applied or function abnormally;
3.4 Edit
Description
This feature allows editing of an existing app publishing policy, including changes to the policy name, selected apps, configuration settings, and distribution scope. All fields are editable. Upon editing, the system automatically creates a new version, while the previous version is retained as a read-only historical record.
After editing, the policy can be saved as a draft or submitted for approval (if the approval workflow is enabled). Once the new version is published, it will replace the previous one and be applied to all associated devices, ensuring consistent configuration updates.
Notes
All fields are editable. Editing creates a new policy version; the original version becomes read-only.
It is recommended to review the current policy status and impact before making changes to avoid misconfigurations affecting production.
Policies in the "Archived" status cannot be edited directly; they must be restored to draft first.
If the new version is submitted but not approved, it will not take effect on devices.
App selections and configurations can be freely modified, including adding, removing, or changing parameters.
When configuring apps with the "Latest Version" option, the default update behavior is: immediate update + forced execution + Wi-Fi preferred.
Once the new version is published, it automatically replaces the old one and delivers updates to all target devices.
All actions are logged in the "Operation Log," which supports version difference audits.
Steps
Access Policy List
Open the App Publishing Policy module;
Locate the target policy and click the Actions > Edit button.
Edit Policy Content
On the policy edit page, you can modify the following:
Basic Information: Policy name and description;
Non-compliance Handling: Enable/disable and configure enforcement rules (if enabled, actions follow System Settings → Compliance Rules);
Selected Apps: Adjust mandatory apps, whitelist, blacklist, or apps to be removed;
App Configuration: Reconfigure each module status and corresponding parameters (e.g., default launch, dynamic permissions);
Distribution Settings: Modify policy delivery time and device scope.
Save and Submit
After completing the changes, click Submit;
If approval workflow is enabled, the policy will enter "Pending Review" status and require admin approval to publish;
If approval workflow is disabled, the policy will become "Published" immediately and be pushed to devices.
3.5 Deploy Policy
Description
This operation is used to immediately push a published GP/KC application policy to target devices or device groups, ensuring the configuration is received and takes effect in time. It is suitable for scenarios such as active policy push after publishing, fixing abnormal device policies, or temporary forced synchronization.
The platform applies different distribution mechanisms based on policy type:
GMA Policies: Delivered via Google AMAPI interface. After dispatch, Google services handle the actual policy delivery.
KMA Policies: Directly pushed by KiwiCloud services. Push will only be triggered if there are configuration changes, avoiding redundant dispatches.
Notes
GP application policy distribution depends on Google Admin services. Please ensure AMAPI permissions and binding settings are correctly configured for the organization.
KC policies will not be re-pushed if there is no configuration change.
All push operations will re-calculate the complete strategy stack for target devices.
Distributing a policy does not modify its content—it only affects its enforcement on the device.
All push operations are logged in both operation and system logs.
Offline devices (GMA, KMA) will receive the policy once they come online. For IMA devices, the policy command will be cached for a limited time—if exceeded, the command becomes invalid.
Steps
Go to the App Release Policy module.
Locate the target policy and click Deploy Policy in the action column.
A confirmation popup will appear. Click Confirm to execute the push immediately.
3.6 Disable Policy
Description
This operation is used to change a published application policy to Disabled status. Once disabled, the system will remove the corresponding configuration modules from the strategy stack on associated devices, making the policy ineffective. However, the binding relationship between the policy and its associated devices or groups will be retained, allowing future reactivation, modification, or archiving.
This function is suitable for temporary policy suspension, version replacement, or troubleshooting scenarios.
Notes
After disabling, the policy itself will not be deleted. You can still modify, enable, or archive it.
Disabling a policy does not remove its device or group bindings—it only affects the enforcement on devices.
The system will recalculate the strategy stack for all affected devices and log the disable operation in both operation and system logs.
If no other valid policies exist in the stack for a device, the platform will attempt to push a default policy to ensure configuration integrity.
Steps
Go to the Application Policy module
Navigate to the Application Policy page.
Locate the target policy in the list and click More Actions > Disable Policy.
Confirm the action
A confirmation popup will appear: “Are you sure you want to disable the policy 【Policy Name】? Once disabled, a default policy will be applied to devices. Please confirm whether to proceed.”
Click Confirm to execute the disable action.
System Execution
The policy status will change to Disabled.
The system will remove the related configuration modules from the strategy stack of all associated devices.
If no other effective strategies are available for a device, a default policy will be pushed automatically (if configured).
3.7 Enable Policy
Description
This operation is used to enable an application publishing policy that is currently in Disabled status. Once enabled, the system will reintegrate the policy into the application policy stack of its bound devices or groups and immediately re-push the configuration, restoring the policy's effect on device management.
After being enabled, the policy will return to Published status. Devices will reapply the policy’s configurations, including app installation, permission settings, and publishing plans, ensuring full reactivation of the policy.
Notes
Only policies in the Disabled status can be enabled.
Once enabled, the policy status updates to Published without requiring re-submission or approval.
Enabling a policy does not change its content or version number.
After enabling, the policy will be reissued to bound devices, which may trigger app reinstallation or permission updates.
If devices are offline, the policy will be queued and automatically executed once the devices reconnect.
All enable actions will be recorded in the Operation Log.
Steps
Go to the Policy List Page
Open the Application Publishing Policy module.
Filter for policies with the status Disabled.
Find the target policy and click More Actions > Enable Policy.
Confirm Enable Action
A confirmation popup will appear: “Are you sure you want to enable this policy 【Policy Name】?”
Click Confirm to proceed.
System Execution
The policy status will change from Disabled to Published.
The system will re-integrate the policy into the stack for all bound devices or groups.
Based on the stacking rules, devices will retrieve and apply the policy configurations again, potentially triggering actions like app installation, configuration updates, or re-distribution.
The enable operation will be logged in the policy’s Operation Log.
3.8 Archive Policy
Description
The archive operation is used to convert a Disabled application policy into the Archived status and to remove all bindings between the policy and any devices or device groups. Once archived, the policy will no longer take effect on any device and is mainly intended for retention after the policy's lifecycle ends.
Archived policies remain visible under the “Archived” tab and can still be restored or deleted, allowing for easier policy management and historical tracking.
Notes
Only policies in the Disabled status can be archived.
Archived policies will no longer participate in the policy stacking calculation and will not be issued or enforced.
When archived, all bindings to devices, device groups, and apps will be removed.
Archived policies retain their configuration and version history and can be re-enabled using the Restore operation.
All archive actions are recorded in the Operation Log and System Log for audit purposes.
Steps
Go to the Policy List Page
Open the Application Publishing Policy module.
Locate the target policy with status Disabled.
Click the Actions button on the right, then select Archive.
Confirm Archive Action
A system prompt will appear: “Are you sure you want to archive this policy?”
Click Confirm to proceed with the archive process.
System Processing
The system will unbind the policy from devices, groups, and applications.
The policy status will update to Archived.
The policy will move from the main list to the Archived tab.
Post-Archive Actions
In the Archived policy list, you can perform Restore or Delete operations on the policy as needed.
3.9 Revert Policy
Description
This operation is used to restore an Archived application publishing policy back to Draft status, allowing it to be edited and published again. The restored policy retains all configuration and historical data from the original version, but device or group bindings are not automatically restored and must be manually reconfigured.
Once restored, the policy re-enters the normal policy lifecycle and can undergo editing, submission, approval, and publishing as needed.
Notes
Only policies with status Archived can be restored.
Device and group bindings will not be automatically restored and must be manually reconfigured.
The policy status will be reset to Draft and follow the standard approval and publishing process.
The restore operation is recorded in the platform’s operation log for audit tracking.
After restoration, new versions can be created to support iteration and optimization.
Steps
Access Archived Policies
Go to the Application Publishing Policy module.
Switch to the Archived tab at the top of the page.
Browse the list and locate the target policy.
Perform Restore Operation
Click the Actions button on the target policy, then select Revert.
System Response
The policy status updates to Draft and moves into the main “All” policy list.
All previous configurations and version info are preserved.
You may continue editing or submitting the policy.
Suggested Next Steps
To reactivate the policy, go to the draft list to modify and submit it.
If the application publishing policy approval process is enabled, the restored policy will enter Pending Approval status after submission.
Once approved, the policy can be reissued to devices.
3.10 Delete
Description
This operation is used to permanently delete a policy in "Archived" status. The platform performs a logical deletion, and once deleted, the policy will no longer appear in any interface and cannot be recovered.
Only policies with Archived status can be deleted. Deletion must be performed only when there are no active device bindings. This is typically used to clean up obsolete or historical policy data.
Notes
This operation is irreversible. Ensure the policy is no longer needed before deleting.
Only policies in Archived status are eligible for deletion.
Once deleted, the policy is permanently removed from all views and cannot be restored or viewed again.
Deletion does not affect historical records or logs related to devices previously bound to the policy.
The deletion action is recorded in the operation log for audit tracking.
Steps
Go to the "Archived" List
Open the Application Publishing Policy module page;
Click the Archived tab at the top to switch the view.
Initiate the Delete Operation
Locate the policy you wish to delete, click Actions > Delete.
A confirmation dialog will appear asking if you're sure about deleting the policy.
Confirm and Execute
Click Confirm to proceed.
The platform will immediately perform a logical deletion.
The policy will no longer appear in either the All or Archived lists.
4. Configuration Item Descriptions
Policy configuration items differ based on the policy type (GP App Policy / KC App Policy). All configurations are delivered to devices using a module-level merge strategy:
Between different modules: configurations are merged and applied together;
For the same module: the configuration from the most recently bound policy takes precedence.
Note: KMA app distribution policies are backward compatible with IMA-type devices.
4.1 GP App Policy Configuration Items
Item | Description |
Non-compliance Handling | When enabled, if a device is found to be non-compliant (e.g., required apps are uninstalled), the system will execute predefined actions such as device lockout or factory reset. These actions are defined under System Settings → Compliance Settings. The policy serves only as a trigger. |
Required Apps | Apps set as "Required" must remain installed on the device. The system monitors them continuously and will automatically reinstall them if uninstalled or removed abnormally. Users cannot manually uninstall these apps. Supports Google Play public apps, private apps, and web apps in "Published" state. |
Allowlisted Apps | Only apps in the whitelist can be installed on the device. Any other apps, including those manually installed via Play Store, will be blocked. Suitable for high-control scenarios to prevent employees from installing non-business apps. Whitelist and blacklist cannot be enabled at the same time. |
Blocklisted Apps | Blocklisted apps will be uninstalled from the device once the policy is effective and cannot be reinstalled. Suitable for blocking sensitive or non-business-related apps. Whitelist and blacklist are mutually exclusive. |
Delete Apps | Apps already configured as "Required" or "Allowlisted" in the same policy cannot be marked for deletion. When this configuration is applied, the specified app will be forcibly uninstalled regardless of its previous state. Suitable for scenarios requiring removal of outdated or non-compliant apps. |
App Configuration | For Android Enterprise apps that support managed configuration, parameters such as workspace URL or pre-filled usernames can be specified here (e.g., for Slack). The configuration is pushed alongside the policy and automatically takes effect upon installation. |
App Permissions | Controls how app permission requests (camera, location, file access, etc.) are handled. Options include "Prompt User", "Auto Grant", and "Auto Deny". Enforces uniform permission behavior across devices, preventing user misconfigurations or abuse. |
Accessibility Settings | Grants specific Android accessibility services required by certain apps (e.g., input assistance, auto-clicking). When enabled, these services are automatically activated, reducing the need for user intervention. |
App Distribution Schedule | Controls when the policy is pushed to devices. Can be set to "Immediately" or scheduled for a specific time. Useful for off-peak deployments or batch rollouts. |
Device Distribution Scope | Defines which devices the policy will be applied to. Supports three methods: ① All devices (all GMA devices in the organization); ② Staged rollout (select groups or devices manually); ③ Proportional rollout (e.g., 10%, 50%, randomly assigned by system). |
4.2 KC App Policy Configuration Items
Item | Description |
Non-compliance Handling | Defines the action taken when policy requirements are not met (e.g., required app is uninstalled). Behavior is managed under System Settings → Compliance Settings, supporting device lockout or factory reset. |
Required Apps | Devices must install the specified app. If the app is missing or uninstalled, the system will automatically reinstall it. The app is force-installed and cannot be manually removed. Suitable for core business applications. Supports enterprise private, public, and web apps. |
Allowlist Apps | Only apps on the whitelist can be installed. All non-allowlist apps are blocked. Prevents non-business apps from being installed. Cannot be enabled together with blocklist. |
Blocklist Apps | Blocklist apps will be automatically uninstalled and blocked from reinstalling. Useful for preventing use of entertainment or prohibited apps. Mutually exclusive with allowlist. |
Delete Apps | Apps marked as required or allowlisted in the same policy cannot be set for removal. This item removes the app’s policy configuration and triggers an uninstall, regardless of other configurations. Suitable for forced removal scenarios such as outdated or non-compliant apps. |
Default Launch App | Automatically launches the specified app upon device startup. If the app is not installed, the system will install and launch it. If the app becomes inactive for a certain duration, it will be relaunched. Only one app can be set as the default launch app. |
Uninstall Protection | Prevents users from uninstalling the app through the system UI. Ideal for mission-critical apps to avoid accidental or intentional removal. |
Dynamic Permission Configuration | Allows pre-setting specific system permissions to enhance app persistence and system-level behavior. Includes (but is not limited to): USB exemption, reboot block, silent install, auto-enabling accessibility, LMK app protection, and floating window display. |
App Distribution Schedule | Controls when the policy takes effect. Options: Immediately, Start Time, or Time Slot (e.g., 1–2 AM daily or weekends). Useful for deploying policies during off-peak hours. |
Device Distribution Scope | Defines which devices will receive the policy. Supports: ① All devices; ② Targeted Deployment (by group or manual selection); ③ Proportional (e.g., 10%, 30%, etc.). Ideal for pre-release testing or phased deployment. |