Android Policy Planning
What
Android EMM Policies can contain several configuration types, and multiple Policies can be assigned to one device. Good policy design keeps each Policy’s intent, enrollment scope, and removal impact clear.
The core rule is simple: separate settings by purpose and avoid conflicting Policies that manage the same value differently.
Why separate Policies
- Troubleshooting: Smaller, purpose-specific Policies make an unexpected result easier to isolate.
- Safe removal: A Policy can be removed and reinstalled without also removing unrelated certificates, restrictions, or network settings.
- Clear scope: BYOD, fully managed, and Dedicated Device deployments can receive settings appropriate to their enrollment mode.
- Predictable ownership: Each managed setting has one authoritative source instead of competing Policies.
Overlapping Policies
An overlap occurs when two or more Policies manage the same setting with different values. The device may appear correct until one Policy is changed or removed, at which point the effective behavior can change unexpectedly.
Do not design around accidental precedence. Avoid assigning conflicting values and document which Policy owns each setting.
Multiple Policies are fine when they manage different things. For example, separate Policies can deliver different certificates without conflict.
FileWave 16.4 policy planning
FileWave 16.4 adds controls that should be separated by purpose so enrollment type, operational role, and app trust remain explicit.
| Control | Planning decision |
|---|---|
| System Update | Choose Automatic, Windowed, or Postpone based on device availability requirements. Use Freeze Periods only for defined business-critical dates and document when normal patching resumes. |
| Compliance: Password | May be used independently, including for supported BYOD/work-profile deployments. |
| Compliance: Keyguard | Use only where a Dedicated Device or single-app design requires it; do not include it in BYOD policy scope. |
| App Auto Update Mode | Set the intended behavior on each Android app Fileset: Unspecified, Default, Postponed, or High Priority. |
| Credential Provider | Keep the default deny posture and explicitly allow only trusted credential-management apps on Android 14 and later. |
Recommended separation
- Keep System Update behavior separate from Password and Keyguard compliance so maintenance windows can change without disturbing security policy.
- Separate BYOD compliance from Dedicated Device compliance because Keyguard is not applicable to BYOD.
- Use the Android Default Policy for Permission and Credential Provider baselines. Configure Auto Update Mode on each Android app Fileset.
- Name Policies for their purpose and scope, such as BYOD – Password Compliance or Dedicated Devices – Windowed System Updates.
Planning checklist
- Which enrollment modes receive this Policy?
- Does another Policy or app Fileset already manage the same setting?
- What unrelated controls would be removed if this Policy had to be withdrawn?
- Is the global default appropriate, or is a narrowly scoped override required?
- How will the Policy be tested before production assignment?
- Who owns the date for ending a Postpone or Freeze Period?