GMA Kiosk Policy: For GMA devices only. Supports configuration of Google Play public and private apps.

KMA Kiosk Policy: For KMA / IMA devices. Supports configuration of enterprise public, private, or web apps.

Lock store-front devices to a single POS or ordering app to prevent misuse or entertainment app installations.

Enable navigation and permission restrictions for logistics and courier terminals, allowing only camera and scanner access.

Control system settings and notification access on government or medical institution devices for regulatory compliance.

Roll out kiosk strategies to new devices using phased or percentage-based deployments for testing and validation.

Partners can centrally push kiosk policies to demo units to ensure consistent demo content and device security.

Applicable to GMA devices only, not for KMA/IMA devices.

Supports only Google Play public and private apps, not enterprise private apps.

Each app can only be effective in one GMA Kiosk policy. The system follows a "module merge, latest override" logic.

All apps must be in Published status before they can be added.

Modules not configured in a policy will be excluded from deployment and stacking.

Policies are effective immediately upon release. It’s recommended to pilot-test in small batches.

If approval is enabled, policies enter "Pending Review" status and must be approved before activation.

Policies cannot be directly edited. Use the “Edit” function to create a new version.

The selected device scope and release time affect delivery timing. Plan according to device onboarding batches.

Go to the App Policy module and click Create Policy.

Select GMA Kiosk Policy as the policy type.

In the App Selection screen, choose published apps from Google Play (public/private).

Only apps in Published status can be selected.

App Configuration For apps supporting Android Enterprise Managed Configurations, you can set parameters (e.g., Slack workspace, email domain). These settings are delivered with the policy and applied automatically.

App Permissions Define how the system handles permission prompts:

Permissions include access to contacts, location, network status, camera, etc.

Accessibility Service Settings Optionally pre-authorize accessibility services for selected apps. Useful for automation and UI control apps. If not configured, users will be prompted to enable it manually.

Power Button: Allow or block use of the power button (shutdown, restart).

System Error Dialogs: Control whether system error prompts appear.

System Navigation: Define the appearance of the bottom navigation bar.

System Info & Notifications: Configure access to status bar and notifications.

Device Settings: Restrict or allow access to system settings.

Immediately: Push the policy right after creation.

Scheduled: Choose a future time to release the policy.

All Devices: Apply to all GMA devices under the enterprise.

Phased Release: Manually select device groups or devices.

Percentage-Based Rollout: Randomly push to a defined percentage of devices.

After configuration, click Submit.

If approval is not enabled, the policy will enter “Published” state and be delivered.

If approval is enabled, it enters “Pending Review” and requires admin approval to take effect.

KMA Kiosk policies are only applicable to KMA / IMA devices, not GMA devices.

Supported app types include Enterprise Private Apps, Enterprise Public Apps, and Enterprise Web Apps only.

App version options:

All related apps must be in Published status.

Disabled modules will not participate in device-side policy stacking or configuration.

Kiosk exit password can be set to allow operators to exit Kiosk mode when needed.

Upon submission, the policy enters Pending Review status and requires admin approval to take effect.

If the Policy Approval Workflow is disabled, the policy takes effect immediately upon submission.

Click Create Policy, and select KMA Kiosk Policy.

Enter the policy name (required).

Enable Compliance Check (recommended).

Select the deployment mode: Single App or Multi-App.

Select the apps and choose either Latest Version or Specified Version.

Set the Kiosk Exit Password (for cases like network disconnection or maintenance).

Configure the Auto Launch App (the app starts automatically on boot).

Configure Dynamic Permissions:

Power Button Control: Whether to allow power button usage (e.g., shutdown, reboot).

System Error Dialogs: Display or suppress system error dialogs.

System Navigation: Control the bottom navigation bar display.

System Info & Notifications: Manage status bar and notification visibility.

Device Settings: Restrict access to system settings.

Choose when to distribute the policy:

Select the devices the policy will apply to:

Click Submit to save the policy. The policy status will become Pending Review.

If approval is enabled, the policy must be approved by an admin before deployment.

If approval is disabled, the policy will take effect immediately after submission.

Policies in draft status can be freely edited and saved. Once submitted, they can no longer be edited.

If the approval workflow is enabled (System Settings > Others > Approval Workflow Toggle), the policy must be approved before it becomes active.

If the approval workflow is disabled, the policy will immediately change to “Published” status upon submission.

The submission action does not include a second confirmation step — please ensure all policy details are correct before proceeding.

The submitted policy version will become the active version. The previous version will be archived as history.

Approval is only applicable to policies in “Pending Review” status;

Once approved, the policy will immediately change to “Published” and be deployed according to the release schedule;

If rejected, the policy will revert to “Draft”, allowing further edits and resubmission;

If the approval workflow is disabled (System Settings > Others > Approval Workflow), policies will automatically skip this step and go directly to “Published” status upon submission;

Approval actions are irreversible — ensure the policy content, scope, and device impact are correct before proceeding;

All approval actions are logged in the policy’s operation history for audit purposes.

The edit action generates a new version; the previous version will be archived and cannot be edited;

All fields are editable, including selected apps, Kiosk configurations, and release settings;

Before editing, confirm the current policy status and affected device scope to avoid misconfiguration;

If the policy is in the Archived status, it must be Reverted to draft before editing;

After editing, you must Submit the policy for changes to take effect, following the approval flow;

All changes will be logged in the operation history;

Once edited, the system will re-calculate and apply the updated policy stack to all associated devices;

The updated policy will not be pushed to devices until it enters the “Published” state.

GMA Policies: Delivered via Google AMAPI. Once pushed, Google services manage the actual policy distribution.

KMA Policies: Pushed directly by KiwiCloud services. Delivery only occurs if the configuration has changed, avoiding redundant updates.

GP (Google Play) policy delivery depends on Google Management Services. Ensure AMAPI permissions and bindings are properly configured;

KC (KiwiCloud) policy will not be pushed again if there are no changes;

All push actions will trigger full policy stack recalculation on the target devices;

This operation only affects the device-side application of the policy, not its content;

All push events will be logged in the Operation Log and System Log;

Offline devices (GMA, KMA) will receive the policy once online; for IMA devices, policy instructions are cached temporarily and may expire if the device does not come online in time.

Only policies in "Published" status can be disabled;

Disabling a policy does not delete it — you may still edit, enable, or archive it later;

Once disabled, the system will immediately re-calculate the policy stack on all associated devices;

If no other valid policy modules exist for a device, the platform will attempt to push a default policy;

The policy will no longer be effective on any device but will retain version history and bindings;

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

Only policies in "Disabled" status can be enabled;

No resubmission or approval is required; the policy will directly return to the Published state;

Enabling does not alter the policy content or version number;

Once enabled, the system will re-calculate the policy stack and re-distribute the configuration to all bound devices;

If a device is offline, the instructions will be cached and applied once it comes online;

All enable actions are recorded in both the Operation Log and System Log for auditing and traceability;

It is recommended to confirm the current device environment and policy configuration before enabling to avoid conflicts.

Only policies in Disabled status can be archived;

Archived policies are excluded from policy stack calculations — they will not be pushed or applied to devices;

Upon archiving, all associations between the policy and its devices, groups, and apps will be removed;

Archived policies retain their original configuration and version history and can be restored for reuse if needed;

All archive actions are logged in both Operation Log and System Log for audit tracking.

Only policies in Archived status support the restore operation;

After restoration, the policy enters Draft status and must be submitted again before publishing;

Restoration does not alter the policy content or version information;

All restore actions are recorded in the Operation Log for audit purposes;

Restoring a policy does not re-establish push relationships to devices — manual resubmission is required.

Only policies in "Archived" status support deletion;

Deletion is irreversible — proceed with caution;

Once deleted, the policy will no longer appear in any policy list, and all log records related to it will also be removed;

If the policy might be reused, consider using Restore before deletion;

Deleting a policy does not affect existing configurations on devices, but it removes the ability to track the policy in the platform;

All delete actions will be recorded in the Operation Log, including the operator and timestamp.