Skip to main content

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.

Example Android EMM Policy with developer settings

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.

ControlPlanning decision
System UpdateChoose 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: PasswordMay be used independently, including for supported BYOD/work-profile deployments.
Compliance: KeyguardUse only where a Dedicated Device or single-app design requires it; do not include it in BYOD policy scope.
DefaultApp AppAuto Update ModeSet normalthe fleetintended behavior globally,on theneach useAndroid app FilesetFileset: overridesUnspecified, onlyDefault, forPostponed, documentedor exceptions.High Priority.
Credential ProviderKeep the default deny posture and explicitly allow only trusted credential-management apps on Android 14 and later.
  • 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 fleetPermission baselines;and useCredential individualProvider baselines. Configure Auto Update Mode on each Android app Fileset Properties for exceptions.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?

Related Content

Back to top