How to Use AirWatch to Control App Permissions on Android
Android apps often request access to contacts, location, cameras, microphones, storage and other device functions. For a business, approving every request by default can expose sensitive information, create compliance gaps and make a lost handset harder to contain. AirWatch, now part of VMware’s Workspace ONE platform, gives administrators a central way to govern these permissions across managed Android endpoints.
The platform supports several Android management models, including fully managed devices, corporate-owned work profiles and personally owned work profiles. The right approach depends on who owns the handset, what data it handles and how much control the organisation needs. A company-issued warehouse scanner may require a much tighter policy than an employee’s personal phone enrolled under BYOD.
Android version, device manufacturer and enrolment mode affect the controls available in the AirWatch console. Samsung Knox devices, for example, may expose additional enterprise controls, while standard Android Enterprise management follows Google’s framework. Menu names can also differ between Workspace ONE UEM releases, so administrators should confirm the current console documentation before publishing a profile.
For Australian organisations, app permission management also sits alongside the Privacy Act and the Australian Privacy Principles. A business operating in Sydney, Perth or Brisbane should be able to explain why an app needs personal information, who can access it and how long that information is retained. Clear permission policies support that accountability while reducing the risk of informal workarounds by staff.
Prepare Android Enrolment And Ownership Rules
Begin by identifying the ownership model for each group of Android devices. A fully managed device provides the strongest administrative control and is suitable for company-owned phones, tablets, point-of-sale equipment and rugged devices used in logistics or mining. A work profile separates business apps and data from personal content, making it a better fit for BYOD programs.
In the AirWatch console, create smart groups that reflect business needs rather than simply grouping every Android device together. Useful groups might include corporate-owned handsets, personally owned devices, frontline tablets and devices assigned to travelling staff. You can then apply different compliance rules, application assignments and permission policies without affecting the entire fleet.
Check that devices are enrolled through Android Enterprise and that the relevant Workspace ONE UEM integration is active. Google Play managed accounts and Android Enterprise allow the organisation to distribute approved applications while keeping business data inside a managed container. Older legacy Android enrolment methods may offer fewer controls and should be reviewed before being used for new deployments.
Create A Permission Policy
Android runtime permissions allow an application to request access when it needs a protected function. Common examples include camera access for identity verification, location for fleet tracking and microphone access for field-service calls. Workspace ONE UEM can help administrators configure how managed apps handle these requests, depending on the Android Enterprise mode and device capabilities.
Open the appropriate Android Enterprise device profile or application assignment in the AirWatch console. Look for the settings covering application control, runtime permissions, managed configurations or application restrictions. Available options commonly include allowing a permission automatically, denying it, or leaving the decision to the user. The exact labels vary by console version and OEM.
Use the least-privilege approach. A barcode-scanning app may need camera access but have no reasonable need for contacts. A navigation application may need location while in use, yet unrestricted background location could create unnecessary privacy exposure. Blocking an essential permission can break the app, so test each policy with the application’s actual workflow before enforcing it.
Where an application supports managed configuration, use that feature to control behaviour without relying solely on Android permission prompts. For instance, an administrator may be able to disable personal cloud storage, restrict account changes or require a business tenant. Permission settings and managed app configurations work best together because they address both operating-system access and application-level behaviour.
Match Controls To Device Ownership
The following model helps determine how much control to apply. It is a starting point rather than a substitute for testing the specific Android release, application and manufacturer combination used by the business.
| Device scenario | Recommended AirWatch approach | Permission stance | Main consideration |
|---|---|---|---|
| Corporate-owned, fully managed phone | Android Enterprise fully managed enrolment and device profile | Automatically allow only required permissions; deny high-risk access by default | Strong security and central control |
| Corporate-owned work-profile device | Work profile with managed applications and restrictions | Permit business permissions inside the work profile; limit personal-data access | Keeps work and personal use separate |
| Employee-owned BYOD phone | Android Enterprise work profile | Control work apps while avoiding personal-profile inspection | Employee privacy and clear consent |
| Rugged warehouse or mining tablet | Dedicated or fully managed mode with kiosk restrictions | Allow only permissions required for scanning, location or diagnostics | Operational continuity and offline use |
| Executive or travelling device | Managed work profile with conditional access and compliance rules | Use tighter controls for sensitive applications and data | Lost-device response and roaming connectivity |
BYOD requires particular care in Australia. Employees should receive plain-language information about what AirWatch can see and control before enrolment. A work profile lets the business manage corporate applications and data without treating a personal photo library, private messages or personal contacts as company assets.
For corporate devices, stronger enforcement is generally acceptable, especially where the handset accesses customer records, health information or financial systems. Even then, document the business reason for sensitive permissions. An employee in Melbourne using a field-service application should not need to approve broad contact access merely because the app requests it during setup.
Assign Approved Applications Safely
Permission controls are most effective when paired with an approved application catalogue. Use Workspace ONE UEM to distribute applications from managed Google Play, upload private enterprise applications where appropriate, and define which smart groups can install each app. Removing unapproved alternatives reduces the likelihood that workers will transfer business data through consumer tools.
Review application permissions before approval. Check the developer, package name, release history, data safety disclosures and requested access. An application that suddenly adds SMS, accessibility or background location permissions should trigger a review before the new version is made available to staff.
App assignment settings can also support staged deployment. Start with an IT pilot group, then move to a small operational team before wider release. This is useful for Australian businesses with different conditions across offices in Adelaide, farms in regional New South Wales and remote worksites in Western Australia. Connectivity, device models and working hours may differ considerably.
When an app is removed or a permission is withdrawn, consider the operational result. A delivery application that loses location access may stop recording proof of service. A two-factor authentication app that cannot use notifications may lock staff out. Build a rollback process and communicate changes before enforcement, particularly for shift-based teams and workers who are often away from the office.
Monitor Compliance And User Activity
After deploying a permission policy, use the AirWatch dashboard to identify non-compliant devices, failed installations and applications that require user action. Reports can show enrolment status, device ownership, operating-system version and compliance events. These records help administrators distinguish a deliberate policy block from a technical failure.
Set compliance actions that match the risk. A low-risk outdated application might generate a reminder, while a device with disabled security controls could be blocked from corporate email or conditional access. Avoid immediately wiping a personal device enrolled through BYOD unless the organisation has a clear, documented authority to remove corporate data only.
Application and device logs should be reviewed carefully. Frequent permission denials may indicate that the policy is too restrictive, that the application has changed, or that users do not understand the prompt. A short internal guide can explain why camera, location or microphone access is needed and how the organisation uses the resulting data.
Make permission reviews part of normal governance. Revisit profiles when Android releases change, when a vendor updates its app, or when the business introduces a new data-processing purpose. Australian organisations should retain enough evidence to demonstrate sensible privacy and security practices to internal auditors, customers and regulators.
Test Policies Before Broad Deployment
Use a controlled test group containing the Android versions and manufacturers found in the real fleet. Include at least one device with a clean enrolment, one with an existing work profile and one device using the same network conditions as field staff. Test installation, first launch, permission prompts, offline operation, updates and removal.
Confirm that the app performs its core task after each permission decision. Test both allowed and denied states, because some applications fail silently when access is refused. Check whether a user can re-enable a blocked permission through Android settings and whether the AirWatch profile restores the intended state during the next device check-in.
For organisations using Samsung Knox, validate the policy on the precise Knox version in circulation. OEM extensions can add useful controls, but they can also produce behaviour that differs from Google’s standard Android Enterprise implementation. Record the device model, operating-system build, console version and application version for repeatable troubleshooting.
A pilot should also measure user impact. If workers in Cairns or regional Queensland regularly operate with patchy coverage, policies must still behave predictably when the device is offline. Gather feedback from supervisors and frontline staff, then adjust the profile before broad deployment rather than relying on assumptions made at head office.
Recommended Permission Management Practices
A sustainable Android permission strategy combines technical enforcement with privacy communication and regular review. Apply controls according to risk, keep business and personal data separate, and make exceptions temporary and traceable.
- Use Android Enterprise work profiles for BYOD and avoid managing an employee’s personal profile.
- Allow only the permissions required for a documented business function.
- Test profiles across Android versions, manufacturers and low-connectivity locations.
- Review new app versions and permission changes before broad deployment.
- Record policy owners, exception expiry dates and the reason for each sensitive permission.
AirWatch can turn app permission management from a collection of device-by-device decisions into a consistent operational policy. Start with a small pilot, use smart groups to separate ownership and risk, and connect permission rules with managed applications and compliance actions. Organisations ready to formalise their Android controls can evaluate Workspace ONE UEM through the available 30-day trial or speak with the sales team about a configuration suited to their Australian environment.