1. Features and Application Objectives
The Device Policy module is designed to define and centrally manage the behavioral standards and system configurations for enterprise devices. Administrators can create different types of device policies (GMA / KMA) to configure various management dimensions such as system restrictions, security settings, and scheduled tasks. These policies can be bound to devices or device groups to achieve standardized and scalable remote control.
This module serves as the core component for the full lifecycle of policy management—covering policy deployment, centralized control, and real-time monitoring. It supports operations such as creation, publishing, modification, deactivation, and archiving.
Special Notes:
Policies must be explicitly bound via “Associate Device / Device Group” actions.
A device can be bound to multiple policies; the system will merge configurations using a stacking mechanism.
Once a policy is disabled, it will be removed from the “active policy stack” but its binding remains. It will no longer push new versions to devices.
GMA policies apply to GMS-type devices.
KMA policies are compatible with both KMA and IMA-type devices.
If the “Non-compliance Handling” feature is enabled, the platform will execute enforcement actions such as “Device Block” or “Factory Reset” for non-compliant devices.
A single policy can be reused across multiple devices or groups and supports version control.
Key Operations
The Device Policy module supports the following operations:
Operation | Description |
Create Policy | Create GMA or KMA policies. Configure settings by device type and associate them with devices or device groups. |
Submit | Submit a draft policy for review (if approval is enabled). Upon approval, the policy can be published. |
Policy Details | View policy versions, configuration content, associated devices/groups, and logs. Core entry for auditing and troubleshooting. |
Edit | Modify policy basic information, configurations, and bindings. A new version will be created while the previous version remains immutable. |
Deploy Policy | Manually push policy configurations to devices, used for updates, issue recovery, etc. |
Disable Policy | Deactivate the policy on all associated devices. The configuration is removed but bindings remain. |
Enable Policy | Reactivate a disabled policy. It is added back to the active policy stack and immediately pushed to devices. |
Archive Policy | Move a published policy into the archive. Device/group bindings are removed but the policy record is retained. |
Restore Policy | Restore an archived policy to draft status for editing or reuse. |
Delete Policy | Permanently delete an archived policy record. This action is irreversible. |
Typical Use Cases
Apply consistent security, system behavior, and permission settings to different device types.
Distribute policies by device or group to meet regional or departmental management needs.
Use policy stacking for layered control and configuration reuse.
Implement policy versioning and approval workflows to ensure traceability.
Enable or disable policies to control rollout or conduct A/B testing.
Archive and restore policies for historical reference and version management.
2. Primary Operations
2.1 Create Policy – GMA Policy
Description
The GMA Policy is designed to enforce system-level security controls and feature restrictions on GMA-type devices. By configuring parameters such as Bluetooth, Wi-Fi, system volume, and password policies, administrators can ensure remote consistency and compliance enforcement.
GMA policies can be bound to individual devices or device groups and can be combined with other policies (e.g., Application Policy, Kiosk Policy) to form a complete endpoint compliance system. Device policies follow a stacked merge mechanism, where policies from different sources are merged by module, and only one effective configuration per module is applied.
Note: If the “Device Policy Approval Workflow” is enabled, the policy must be approved before taking effect; otherwise, it will be immediately merged and pushed to devices.
Steps
1. Configure Basic Policy Information
Click [Create Policy] and select [GMA Policy];
Fill in the Policy Name (required) and Description (optional);
Optionally set Tags for classification and management.
2. Configure Device Policy Modules
Navigate to tabs like Password, Restrictions, Wi-Fi, etc.;
Enable and configure fields as needed (see “Policy Configuration Reference” below);
All configuration items are module-level stacked; for the same module, the most recent configuration takes effect.
3. Associate Devices or Device Groups
Choose to bind the policy to specific devices or device groups;
Once published and bound, the policy is immediately pushed to online devices;
You can enable, disable, or version the policy later via the Device Policy list.
Notes
GMA policies apply only to GMA devices and cannot be pushed to KMA or IMA types;
One device may be bound to multiple GMA device policies simultaneously. If multiple policies define the same module, the configuration from the latest bound policy will take precedence;
Once configuration items are enabled, they directly affect device behavior — it is recommended to validate before mass deployment;
Policy settings cannot be edited directly. You must create and publish a new version via the edit function for changes to take effect;
If the policy includes non-compliance actions (e.g., “disable device”, “factory reset”), ensure the device system time is accurate to avoid rule failure;
The number of days set for “factory reset” must be greater than those for “disable device”, and both must not exceed 30 days.
2.2 Create Policy – KMA Policy
Description
KMA Policy is used to configure system parameters, permission behaviors, custom wallpapers, and scheduled tasks on KiwiCloud Managed Access (KMA) devices. This policy is designed for device management scenarios where Google EMM is not integrated, offering enhanced customization and localized control options.
Administrators can build policy templates via multi-module configurations and deploy them to specific devices or device groups. This allows for unified device behavior control, UI presentation, and automated maintenance tasks.
Additional Notes:
KMA Policies apply to both KMA and IMA device types.
Policies can be bound to devices or device groups as a centralized configuration source.
The policy stacking mechanism follows a “merge across modules; latest takes precedence within module” rule:
If multiple policies contain different modules, the system merges them into one effective policy;
If multiple policies contain the same module, only the configuration from the most recently bound policy takes effect;
The final device configuration is the result of all merged policies, ensuring unified yet differentiated control;
All configurations are modified via "Create New Version"; existing versions cannot be edited directly;
When Non-Compliance Handling is enabled in a module, the platform will execute compliance actions (e.g., disable device, factory reset) on non-compliant devices.
Steps
Open the Policy Creation Page
Navigate to the “Device Policy” module, click [Create Policy], and select [KMA Policy];
Enter the Policy Name (required) and Description (optional).
Configure Policy Modules
Policy content is divided into modules. Click each tab to configure the following:
System Settings Module
Includes settings for Wi-Fi, Bluetooth, Sound, Display, Hotspot, etc.;
Some fields support custom values such as Bluetooth name, brightness, volume, etc.
Permission Settings Module
Controls use of Google services, USB debugging, Play Protect, and more;
Once enabled, the system will verify and enforce the specified permissions.
Custom Wallpaper Module
Upload one or more image files to be used as wallpapers and define resolution;
Optionally set as the “default wallpaper” to override the original device wallpaper;
Supports PNG/JPG formats, with a maximum file size of 5MB.
Scheduled Task Module
Configure scheduled system actions such as reboot or shutdown;
Define: country/region, time zone, execution time, and recurrence pattern;
Typically used for automatic nighttime reboot or scheduled shutdown.
Associate Devices or Device Groups
In Step 3, select the target devices or device groups;
Once published, the policy will be immediately pushed to applicable terminals;
Offline devices will automatically receive and apply the policy upon reconnection.
Notes
KMA policies are applicable only to KMA and IMA device types;
At least one configuration module must be enabled in a KMA device policy;
If using custom values (e.g., for Bluetooth or Wi-Fi names), ensure valid characters;
To update a policy, you must create a new version; older versions will be archived;
Scheduled task times should be based on device local time zone or global settings;
Recommended wallpaper resolution is 1920x1080 or 1360x720 for optimal display compatibility.
2.3 Submit Policy
Description
This operation is used to submit a device policy in draft status to the platform for approval. Once submitted, the policy status changes to "Pending Review" and awaits administrator approval (if the Device Policy Approval Process is enabled). Only after approval can the policy be published and deployed.
Policies typically enter draft status when restored from “Archived,” or when a new policy is created / an older version is edited.
Steps
Access the Draft Policy List
In the “Device Policy” module, filter policies by status = “Draft”;
Initiate Submission
Click the [Submit] button from the “Actions” dropdown next to the target policy;
The system will submit the policy immediately without a secondary confirmation;
Submission Complete
The policy status changes to Pending Review, and it appears in the approval list;
Administrators can configure approval rules via System Settings – Others – Approval Flow Settings.
Notes
Policies in draft status can be modified and saved or directly submitted;
If the approval process is not enabled, submission skips the “Pending Review” stage and the policy is marked Published immediately;
No confirmation popup is shown when submitting—ensure content accuracy before proceeding;
Submitted policies cannot be modified; to make changes, create a new version.
2.4 Device Policy Details
Description
This feature allows you to view the full details of a specific device policy, including its basic information, configuration modules, associated device groups and individual devices, as well as operation and system logs. It supports version history viewing and relationship tracing, helping administrators comprehensively monitor policy status and execution results.
This function is commonly used for policy verification, deployment confirmation, and troubleshooting.
Note: If the “Device Policy Approval Process” is enabled, the policy must pass approval before taking effect; otherwise, the system will immediately execute policy stacking and deployment.
Steps
Open Policy Management
Go to the Device Policy module;
Locate the target policy in the list and click [Details] to access the detail page.
View Policy Overview
The top section displays key metadata: policy name, policy ID, version number, last update time;
It also shows the number of associated devices, device groups, and non-compliant devices.
Browse Policy Configuration
In the Policy Configuration tab, view all configured modules;
Each field displays its value and toggle status, organized by module.
Check Device Association
In the Associated Devices tab, view all devices currently using the policy;
Includes both directly bound devices and indirectly bound via device groups;
Devices from group association will be listed but cannot be modified here;
For group-bound devices, go to the Associated Groups tab to manage them.
Check Group Association
In the Associated Groups tab, view all device groups currently bound to the policy;
You can unbind or modify policies for these groups;
Any changes will apply to all devices that inherit the policy from the group.
View Execution Logs
Use the Operation Log tab to track administrative actions on the policy;
Use the System Log tab to view actual execution results and deployment status.
Notes
Policies can be associated with both individual devices and device groups. The system will handle deployment accordingly;
A single device may be bound to multiple policies. The platform uses a "merge across modules, latest wins within module" stacking mechanism;
In case of module conflicts, the configuration from the most recently bound policy takes precedence;
Once published, a policy becomes a versioned item and cannot be edited directly. To change it, create and publish a new version;
Policy deployment depends on device online status. If a device is offline, the policy will be queued until the device comes online;
The system continuously monitors device compliance and highlights exceptions in the Policy Details view;
Associated Devices Tab:
Displays all devices currently bound to the policy, including direct and group-inherited bindings;
Devices bound via group cannot be managed from this tab;
Associated Groups Tab:
Displays all device groups bound to the policy;
Modifying or unbinding a group will affect all devices inheriting the policy from that group;
Any changes to device-policy associations (e.g., unbinding, switching policies, changing versions) will trigger automatic policy restacking and recomputation;
All policy delivery and exception records are logged under Operation Logs and System Logs for auditing and troubleshooting.
2.5 Edit Policy
Description
This operation allows you to edit an existing device policy, including the policy name, description, configuration content, and associated devices or groups. All fields and modules are editable. Once changes are made, the system will automatically generate a new version of the policy.
After saving the new version, if the Device Policy Approval Process is enabled, the policy must be approved before deployment. Otherwise, it will be applied to devices immediately. If the previous version has not yet been successfully deployed, the new version will automatically replace it.
Steps
Go to the Device Policy module, click [Actions] > [Edit] for the target policy;
The edit page contains three steps:
Policy Basic Information: Modify the policy name and description;
Configure Policy Content:
For KMA device policies: update System Settings, Permissions, Custom Wallpaper, Scheduled Tasks, etc.;
For GMA device policies: configure Password, Restrictions, Wi-Fi, etc.;
Associate Devices or Groups: add, remove, or keep existing bindings;
Click [Save and Publish] to submit the changes;
If the approval process is enabled, an administrator must review and approve the new version in the policy list;
Once approved, the system will deploy the updated policy version, and associated devices will apply the configuration changes.
Notes
All fields are editable. Editing a policy always creates a new version, leaving historical versions unaffected;
If approval is required, the policy will only take effect after it is approved;
If the previous version has not been deployed successfully, it will be replaced by the new version automatically upon publishing;
Device associations remain unchanged; only the policy content is updated;
All version history and operations are logged for audit purposes;
The system will re-stack policies for all affected devices to ensure the latest version takes effect correctly.
2.6 Deploy Policy
Description
This operation is used to immediately push a policy to target devices or device groups. After deployment, devices will execute the policy stacking and enforcement process based on their associations. The platform supports multiple entry points for deployment, suitable for scenarios such as post-publish push, re-sending after policy failure, or temporary forced application.
The deployment mechanism varies depending on the policy type:
GMA Policies: Delivered via Google AMAPI interface; Google services handle actual distribution after push.
KMA Policies: Pushed directly by KiwiCloud services; policies are only pushed when configurations are changed, preventing redundant delivery.
Steps
There are three entry points to deploy a policy:
Device Policy List View
Go to the Device Policy page;
Locate the target policy and click [Actions] > [Deploy Policy];
A confirmation dialog will appear; click [Confirm] to execute the deployment immediately.
Policy Details - Associated Groups
Open the Details page for the target policy;
Switch to the Associated Groups tab;
Select one or more target groups and click [Deploy Policy] in the upper right;
Confirm to push the policy to all devices within the selected groups.
Policy Details - Associated Devices
Switch to the Associated Devices tab;
Select one or more individual devices (not in any group);
Click [Deploy Policy], and confirm to push the policy to the selected devices.
Notes
GMA policy deployment depends on Google Admin services. Ensure that AMAPI permissions and bindings are correctly configured;
KMA policies will not be pushed again if there is no change in configuration;
All deployment actions will trigger complete policy stacking and calculation on the target devices;
Deployment does not modify policy content, only applies it on the device side;
Deployment records will be logged in both Operation Logs and System Logs;
Offline devices will receive the policy after coming online (GMA & KMA). For IMA devices, policy commands are cached for a limited time—expired commands will not be executed.
2.7 Disable Policy
Description
This operation disables the selected policy, making its configurations inactive on all associated devices. The system will remove the policy's configuration modules from the devices' stacked policies, but will retain the binding relationship between the policy and its associated devices or groups. This allows quick reuse when re-enabling or editing the policy in the future.
If no other valid policy remains on the device, the system will automatically apply the default policy (if configured). This operation is suitable for temporarily disabling a policy without deleting it.
Steps
Enter the Device Policy module
Go to the Device Policy list and locate the target policy;
Click [Actions] > [Disable Policy] on the corresponding policy row;
Confirm the operation
A confirmation dialog will appear: “The policy configuration will be removed from devices. Continue?”;
Click [Confirm] to execute the operation immediately;
System execution
The policy will be removed from the stacked policies of all associated devices;
The system will re-calculate and apply the updated policy stack based on remaining configurations;
If no other policy is available, the system will automatically apply a default policy (if set).
Notes
After disabling, the policy itself is preserved and can still be viewed, edited, archived, or re-enabled;
Disabling a policy does not remove the device or group bindings, it only deactivates its effect within the policy stack;
Re-enabling the policy will cause devices to reapply its configurations;
All disable actions will be logged in Operation Logs and System Logs;
If no effective policies remain after stacking, the system will attempt to apply the default policy.
2.8 Enable Policy
Description
This operation enables a disabled device policy, restoring its management effect on associated devices or groups. Once enabled, the system will automatically include this policy in the policy stacking structure of bound devices and push the corresponding configurations again.
Policy stacking rule: “Merge across modules; for identical modules, apply the latest.” That is, each module in the policy will be merged with existing active policies, and if a module overlaps, the configuration from this policy will take precedence.
Steps
Enter the Device Policy module
In the “Device Policy” list, filter policies with status Disabled;
Click [Actions] > [Enable Policy] on the target policy;
Confirm the operation
A confirmation dialog will appear: “Are you sure you want to enable this policy [Policy Name]?”;
Click [Confirm] to submit the action;
System execution
The policy status changes to Published;
The policy is added to the device's stack using module-level merge with latest override;
Configuration is pushed immediately to all bound devices;
View results
View execution records in Policy Details > Operation Logs;
Go to Device Details > Effective Policy Overview to verify applied configurations.
Notes
This action only applies to policies currently in Disabled state;
Once enabled, the policy becomes active on all previously bound devices;
The system automatically re-stacks device policies according to the merge rule;
Enabling a policy does not affect existing binding relationships;
All actions are logged for auditing and traceability.
2.9 Archive Policy
Description
This operation archives a deactivated policy, terminating all its bindings with devices and groups. It is primarily used for policy version management and historical retention.
Once archived, the system automatically unbinds the policy from all associated device groups and individual devices. The policy status is updated to Archived and will be moved to the “Archived” tab in the Device Policy module.
Archived policies are not deleted and can later be restored or deleted as needed.
Steps
Initiate Archiving
On the Device Policy list page, click the [Actions] button for the target policy and select [Archive];
Confirm Archive
A confirmation dialog appears: “Are you sure you want to archive this policy?” Click [Confirm] to proceed;
System Processing
The system automatically unbinds the policy from all associated groups and devices;
The policy status is updated to Archived and removed from the “All” list;
The archived policy becomes viewable in the Archived tab;
Post-archive Actions
In the “Archived” tab, you may choose to Restore or Delete the policy as needed.
Notes
Once archived, the policy configuration will no longer take effect on any device and will be excluded from stacking;
Device policy stacking follows the rule: “Merge across modules; for identical modules, apply the latest.” If an archived policy contains a unique module, fallback occurs to the next applicable policy;
Archived policies can be restored into Draft status and require re-approval before becoming effective again;
If the policy was the device’s only bound policy, archiving will revert the device to the default policy (if configured);
All archive operations are recorded in the platform’s operation logs.
2.10 Revert Policy
Description
This operation is used to revert an archived policy back to an editable state, allowing users to re-enable or modify historical policy configurations.
Revert is only available for policies listed under the Archived tab. Once reverted, the policy enters Draft status, with all original configurations and version information preserved. Users can continue editing the policy and submit it for approval (if the Device Policy Approval Process is enabled).
Note: Reverting does not automatically rebind the policy to any devices or groups. Rebinding must be done manually during re-editing and publication.
Steps
Go to Archived Policies
In the Device Policy module, switch to the Archived tab;
Initiate Revert
Click the [Actions] button in the target policy row and select [Revert];
System Processing
The policy status is updated to Draft and moved to the “All” policies view;
Configuration and version details remain unchanged;
Follow-up Actions
If needed, click [Submit] to enter the Pending Approval stage (if approval is enabled);
Or continue editing the policy while in Draft status.
Notes
Reverting does not re-establish previous bindings to devices or groups; you must reconfigure these during re-editing;
The reverted policy enters Draft status and must be submitted to resume approval and deployment;
If the Device Policy Approval Process is enabled, the policy will be routed to Pending Approval after submission;
All revert actions are recorded in the platform’s operation logs;
Reverting does not affect historical logs or audit trails of the policy.
2.11 Delete Policy
Description
This operation is used to permanently delete a policy that is in the Archived state. The system will perform a logical deletion — once deleted, the policy will no longer appear in any interface and cannot be reverted or recovered.
To ensure data safety, only policies in the “Archived” status are eligible for deletion. This guarantees that only policies no longer associated with any devices or groups can be removed.
Steps
Go to Archived Policies
In the Device Policy module, switch to the Archived tab;
Initiate Deletion
Locate the target policy, click [Actions] > [Delete];
Confirm the Operation
A confirmation dialog will appear: “Are you sure you want to delete this policy?”
Click [Confirm], and the system will immediately perform the deletion;
View the Result
Once deleted, the policy will be completely removed from the platform and will not appear in any views;
Related operation logs will remain in the system for future auditing or tracking.
Notes
Only policies in the Archived state can be deleted;
The system performs a logical deletion, which is irreversible;
Once deleted, the policy will be removed from all pages and cannot be recovered from the “Archived” tab;
All deletion actions are recorded in the platform’s operation logs for audit and traceability.
3. Configuration Item Descriptions
Policy configuration items are divided into two categories based on the policy type (GMA / KMA). All policy configurations are delivered to devices using module-level merging:
Between different modules: merged and applied together
Within the same module: the configuration from the most recently bound policy takes precedence
Note: KMA device policies are downward-compatible with IMA-type devices.
3.1 GMA Policy Configuration Items
The following configuration items apply to GMA-type device policies in KiwiCloud. These items are categorized by module, with parameters presented as dropdowns or input fields. The platform enforces them according to the device policy stacking rules.
Module | Configuration Item | Parameters | Description |
Password | Password complexity | None / Low / Medium / High | Defines password strength requirements, affecting the rules when users set device unlock passwords. |
Password | Max failed attempts | Unlimited / 1-8 attempts | Sets the maximum number of incorrect password entries before the device triggers non-compliance handling. |
Password | Password history count | Unlimited / 1-8 | Records the number of most recently used passwords to prevent reuse. |
Password | Password expiration policy | Unlimited / 30 / 60 / 90 / 180 days | Sets the expiration cycle requiring users to periodically change their passwords. |
Restrictions - Security | Camera access | Allow / Disable / User choice | Controls whether the device's camera functionality is available. |
Restrictions - Security | Screenshots | Allow / Disable / User choice | Controls whether screen capture is allowed on the device. |
Restrictions - Security | Microphone | Allow / Disable / User choice | Controls whether the microphone feature is enabled. |
Restrictions - Security | Developer mode | Allow / Disable | Controls whether developer mode can be enabled. |
Restrictions - Security | Factory reset | Allow / Disable | Controls whether the device can perform a factory reset. |
Restrictions - Security | System update policy | Automatic / Windowed (maintenance period) / Postpone install | Defines Android OTA update behavior: • Automatic: Download/install immediately when updates are detected; • Windowed: Only install during the defined daily maintenance window; • Postpone install: Delay installation, allowing user control. |
Restrictions - Security | OTA Freeze Periods | Up to 3 time ranges, format: Start Date - End Date | Configures annual OTA update freeze periods to prevent updates during business-critical times: • Max 3 periods/year; • Each freeze can last up to 90 days; • At least 60 days between freeze periods; • Devices will skip updates released during freeze. |
Restrictions - Network & Connectivity | Airplane mode | Disable / User choice | Controls whether airplane mode can be enabled. |
Restrictions - Network & Connectivity | Wi-Fi config | Allow user config / Disallow additions | Controls whether users can add new Wi-Fi configurations. |
Restrictions - Network & Connectivity | NFC data transfer | Allow / Disable | Controls whether NFC functionality is enabled. |
Restrictions - Network & Connectivity | USB file transfer | Allow file transfer / Disallow file transfer / Disallow all | Controls USB data transfer permissions. |
Restrictions - Network & Connectivity | Bluetooth | Allow / Disable | Controls whether Bluetooth functionality is available. |
Restrictions - Network & Connectivity | Hotspot sharing | • Allow all types of sharing • Disallow Wi-Fi sharing • Disallow all sharing | Controls whether devices can create hotspots or share networks. |
Restrictions - Others | Global permission policy | Auto / Deny / Prompt user | Defines how the system handles permission popups. |
Restrictions - Others | App installation | Allow / Disable | Controls whether users are allowed to install applications. |
Restrictions - Others | App uninstallation | Allow / Disable | Controls whether users are allowed to uninstall applications. |
Restrictions - Others | Unknown app install policy | Allow / Disallow | Controls whether installation from unknown sources is permitted. |
Restrictions - Others | Use network time | Auto / User choice | Whether the device uses time provided by the network. |
Restrictions - Others | Screen timeout | User choice / Never / Fixed | Defines the timeout period before the screen turns off. |
Restrictions - Others | Screen brightness | User choice / Auto / Fixed | Defines how screen brightness is managed. |
Restrictions - Others | Wallpaper change | Allow / Disable | Controls whether users can change the device wallpaper. |
Restrictions - Others | Sound settings | Allow / Disable | Controls whether users can adjust system volume settings. |
Wi-Fi | Wi-Fi network config | Enable / Disable | Enables/disables auto Wi-Fi network configuration. |
Wi-Fi | SSID name | String | Specifies the SSID name of the Wi-Fi network to connect to. |
Wi-Fi | Auto connect | Yes / No | Determines whether the device connects to the specified Wi-Fi when discovered. |
Wi-Fi | Hidden network | Yes / No | Specifies whether the configured network uses a hidden SSID. |
Wi-Fi | MAC address randomization | Persistent / Non-persistent | Defines the MAC address behavior when connecting to the network. |
Wi-Fi | Security type | None / WEP / WPA/WPA2-Personal | Defines the security type for connecting to the network. |
3.2 KMA Policy Configuration Items
The following configuration items apply to KMA/IMA-type device policies in KiwiCloud. These settings are categorized by module and support high flexibility for local control and custom behavior enforcement.
⚠ Note: All KMA policy configurations are modular. During policy stacking:
Modules from different policies will be merged.
If the same module exists in multiple policies, the configuration from the most recently bound policy will take effect.
Module | Configuration Item | Parameters / Format | Description |
System Settings | Wi-Fi | Enable / Disable | Controls Wi-Fi availability. |
System Settings | Bluetooth | Enable / Disable | Controls Bluetooth availability. |
System Settings | Hotspot | Enable / Disable | Controls hotspot usage. |
System Settings | Brightness (fixed value) | 0 - 255 | Sets a fixed screen brightness level. |
System Settings | Auto brightness | Enable / Disable | Enables or disables adaptive screen brightness. |
System Settings | Screen timeout | 15s / 30s / 1min / 2min / 5min / 10min / Never | Defines how long the screen stays on when idle. |
System Settings | Volume (fixed value) | 0 - 15 | Sets the system volume level. |
System Settings | Mute | Enable / Disable | Whether to mute all sounds. |
System Settings | Time format | 12-hour / 24-hour | Sets the system time display format. |
System Settings | Use network time | Enable / Disable | Whether to use automatic time from the network. |
System Settings | USB Debugging | Enable / Disable | Controls whether USB debugging is allowed. |
System Settings | Navigation bar | Show / Hide | Controls the visibility of the system navigation bar. |
System Settings | Status bar | Show / Hide | Controls the visibility of the system status bar. |
System Settings | Airplane mode | Enable / Disable | Controls airplane mode availability. |
System Settings | USB data transfer | Enable / Disable | Controls file/data transfer over USB. |
System Settings | Network sharing | Enable / Disable | Controls mobile data/Wi-Fi sharing and tethering. |
System Settings | Custom Bluetooth name | String | Set a custom Bluetooth device name (validated for format). |
System Settings | Auto power-on after reboot | Enable / Disable | Whether the device auto powers on after rebooting. |
System Settings | Allow adding accounts | Enable / Disable | Controls if new user accounts (Google, others) can be added. |
Permissions | Google service usage | Enable / Disable | Controls whether core Google services (e.g., GMS, Play Store) can be used. |
Permissions | Safe boot | Enable / Disable | Prevents booting into Safe Mode. |
Permissions | Play Protect | Enable / Disable | Controls Android Play Protect scanning feature. |
Permissions | Accessibility settings | Enable / Disable | Allows or restricts access to accessibility options. |
Permissions | System update UI access | Enable / Disable | Controls access to OTA update interfaces. |
Custom Wallpaper | Wallpaper files | PNG/JPG, ≤ 5MB each | Upload one or more wallpapers to push to devices. |
Custom Wallpaper | Set as default wallpaper | Enable / Disable | Whether to overwrite the current device wallpaper with the uploaded one. |
Scheduled Tasks | Task type | Reboot / Shutdown | Select scheduled task type. |
Scheduled Tasks | Country / Region | Dropdown | Define the region where the scheduled task applies. |
Scheduled Tasks | Time zone | Dropdown | Define the local time zone for task execution. |
Scheduled Tasks | Execution time | Time (HH:mm) | Define the exact time of execution. |
Scheduled Tasks | Repeat cycle | One-time / Daily / Weekly (select weekdays) | Set the repeat schedule for the task. |
Non-compliance Handling | Lock device after non-compliance | 1–30 days | If violated, device will be locked after X days. |
Non-compliance Handling | Factory reset after non-compliance | 1–30 days | If violated, device will be reset to factory defaults after X days. |