Skip to main content

Android Software and Policies

Use one enrolled Android Enterprise test device to deploy an approved Google Play app, then verify both the management policy and the app on the device. Start with an app that does not change networking, lock the screen or collect test-user data as part of the exercise. Network restrictions, password rules, compliance and dedicated-device policies can wait.

Before you start

  • Complete Android Enrollment. Confirm whether the device is fully managed or has a personal work profile, and check that it has communicated recently.
  • This walkthrough uses FileWave Central 16.4's Deployment editor. Fileset Creation and Deployment explains the shared workflow; the core concepts explain Filesets, Deployments and Model Update. For an older Associations interface, use the labeled legacy section of that lesson, not its 16.4 button sequence.
  • Check existing app assignments and policies. Do not edit an app Fileset already used in production for a one-device experiment. A new Deployment does not limit the impact of changing a shared Fileset.
  • Agree on the test and cleanup with the device owner. Keep personal or business data out of the test app.

First exercise: deliver Calculator to one device

Use Calculator by Google LLC, package com.google.android.calculator, if your organization approves it and it is available for the target in managed Google Play. Confirm the publisher and package against Google's Play listing, not just the app name.

Check the device first. For BYOD, inspect the work profile, not the owner's personal Calculator. If the app is already installed in the target management scope, its presence later will not prove a new installation. Use another approved free utility that is not already present, or record that you are testing management of an existing app rather than claiming a fresh install. Do not remove a system app just to test a fresh installation.

1. Create one app Fileset

  1. Open Filesets → New Mobile Fileset → Play Store in Central.
  2. Search for the approved app, open its listing and select Select. FileWave creates the Fileset in the background and leaves the store open for additional selections. For this test, close the store after selecting one app.
  3. Locate the new Fileset. If a Fileset Group was selected before opening the store, the Fileset is created there. Give the test item a recognizable name, such as Evaluation – Android Calculator, without changing its app identity.
  4. Open its properties and review Configuration, Permissions and any Managed Properties. Managed Properties appear only when the developer exposes them. Do not grant extra permissions or credential-provider capability for a calculator test. On Central 16.4, leave Auto Update Mode at Unspecified for this first delivery; Android then uses its Default update behavior.
  5. Save the Fileset. Creating it does not target a device.

See Deploying Google Play Apps for store-selection images and more detail. Its older “associate” wording refers to assigning the app; use the Deployment steps below for Central 16.4. Paid Play Store app distribution is not supported by this documented Android Management workflow.

2. Target the device, save and publish

  1. Open Deployments and create Evaluation – Android Calculator – one device.
  2. Use + beside Clients to add the individual test device. Confirm its identity and that the resulting client count is one. Do not select an entire Android group.
  3. Use + beside Filesets to add only the test app Fileset. Check exclusions and any existing assignments for the same app.
  4. Expand Options, choose Direct Installation, and leave optional timing unset for this test. VPP/Apps and Books license distribution is not the licensing path for this Android app.
  5. Select OK to save.
  6. Review the content, target and other administrators' pending work before opening Update Model. In Update Server Model, choose Update Model to confirm. The dialog is confirmation only; it does not preview pending changes.

Record the server model number. It proves a model was committed, not that Android installed the app. Model Update is shared, even when your Deployment targets only one device.

3. Verify the policy and the app separately

  • In Central: open the test device's details and inspect Installed Policy for the app's package. This shows the effective policy FileWave sent after merging assignments, not independent proof that the app installed. Inspect Filesets Status for the assigned Fileset when available, reading the specific state and current timestamps rather than assuming every completed-looking result is success.
  • On Android: open Android Device Policy → Policies and check the app's reported status. Resolve any installation or policy error.
  • On the device: confirm that the intended app is installed, record its version and open it. For BYOD, open the work-badged app, not a personal copy. In Calculator, enter 7 × 8 and confirm 56. If you used a different utility, perform its equivalent harmless check.

The first exercise is complete only when the intended device has the expected managed app and the app opens successfully. Keep the evidence specific: policy assignment, installation and a successful launch are different observations.

If the app has not arrived

First check the exact target, saved Deployment, committed model and any exclusions. Then check Android Device Policy, the effective Installed Policy, network access and managed Play availability for that device/profile. Connect the device to an approved Wi-Fi network, plug it into power and leave it idle. Android controls installation timing; do not repeatedly recreate the Fileset or update the model as a substitute for diagnosis.

Android apps are not installing immediately explains policy status and timing. If you choose Install from managed Play to accelerate the test, record that user action rather than calling it a fully automatic installation. For a managed Play 403/500 error, check privileges and follow Google Play Store Errors; avoid repeated attempts and ask your SE if the error persists.

Optional follow-up: set one app's update policy

After the app exercise succeeds, use the same test-only Fileset to inspect an app policy without changing network access or password requirements. In Central 16.4, open the app Fileset's Properties → Configuration, record its existing Auto Update Mode, then set it explicitly to Default. Save, review shared pending work and Update Model again.

In the device's Installed Policy, locate com.google.android.calculator (or your chosen package) and check its effective auto-update setting. Default uses Android's normal update behavior. If the previous value was Unspecified, this makes the setting explicit but does not intentionally change that behavior. This is a policy inspection exercise, not proof that an app update occurred. Reopen the Fileset to verify the saved setting; do not claim a device-side update without observing a version change.

Restore the original value if this was only a temporary test, save and publish after the same review, then recheck the effective policy. If Central omits or normalizes the default value, do not infer failure or success from that alone; compare with Android Apps and ask your SE to interpret the result. Do not switch to High Priority, Postponed or a global default just to force visible activity.

Before trying other policies

Use a purpose-specific Policy Fileset for the intended enrollment mode, not a fleet-wide Default Policy edit. Review the current values and plan how to remove the policy before assigning it. Avoid password wipe thresholds, Wi-Fi restrictions, compliance locks, location reporting and dedicated-device controls as beginner tests. In Central 16.4, BYOD password compliance can be used without Keyguard; Keyguard is not appropriate for BYOD.

Permissions have their own precedence, from highest to lowest: an app-specific permission grant; a specific permission for all applications in a Policy Fileset; the app Fileset's permission default; the global default. Other overlapping policy settings do not all follow that same rule. Inspect Installed Policy rather than guessing which assignment wins, and avoid assigning conflicting values.

- Android EMM Policies and Permissions: payloads, app permissions and version-specific controls. - Android EMM Default Policy and Compliance Scope: global versus enrollment-specific settings. - Android Policy Planning and Android devices with multiple policies: keep policies separate by purpose and inspect their effective result.

Finish without wiping the device

Record the test device and mode, Fileset, Deployment, model number, app version, policy observations and launch result. If the approved app can remain for the evaluation, leave it in place and note that cleanup has not been tested.

Before withdrawing the test assignment, confirm whether the app is preinstalled and whether another assignment requires it. Removing an app's management assignment may remove the managed app and its data; it is not a general undo for everything the app did. Use an owner-approved removal procedure, then check both the effective policy and the actual app state. Do not delete a shared Fileset, unlink the enterprise, remove a personal work profile or wipe the device merely to finish an app test.

More app types, when you need them

Next, use Inventory Reports to review the test-device information, or agree on the next platform-specific outcome with your SE.

No comments to display

Back to top