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 work profile on a personally owned device, and check that it has communicated recently.
  • This walkthrough uses the Deployment editor in FileWave Central 16.4.x. Fileset Creation and Deployment explains the shared workflow; use it as a reference, not a second deployment exercise. The core concepts explain Filesets, Deployments and Model Update. If you see an older Associations interface, ask your SE how to proceed with Deployments for this evaluation rather than applying the 16.4.x steps unchanged.
  • Check existing app assignments and policies. For a one-device experiment, do not edit an app Fileset that is already used in production. Changes to a shared Fileset can affect devices outside this test, even if the new Deployment targets only one device.
  • 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 the test as management of an existing app rather than a fresh installation. Do not remove a system app just to test a fresh installation.

1. Create one app Fileset

  1. In Central, select an unassigned evaluation Fileset group, then open Filesets → New Mobile Fileset → Play Store. Do not select a group already included in a Deployment: adding content there can assign it beyond this test.
  2. Search for the approved app, open its listing and choose 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.x, leave Auto Update Mode at Unspecified for this first delivery; Android then uses its Default update behavior.
  5. Save the Fileset and confirm it remains in the unassigned evaluation group. It is not yet targeted to a device; create the one-device Deployment below.

For app-specific settings, see Android Apps. For current targeting, exclusions and installation options, see Deployments in FileWave Central; use the one-device Deployment steps below for this exercise. 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 a Deployment named 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 only asks you to confirm; it does not show a preview of 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. When available, inspect Filesets Status for the assigned Fileset. Check the specific state and current timestamps; a result that looks complete is not enough to prove that the app installed.
  • 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 that app's update policy without changing network access or password requirements. In Central 16.4.x, 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 select 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; only record a device-side app update if you observe 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.x, 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.

Finish without wiping the device

Record the test device and its enrollment 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 removing the test assignment, check 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, but it does not necessarily undo 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 the work profile from a personally owned device or wipe the device merely to finish an app test.

More app types, when you need them

  • Public and private apps: Android Apps describes the supported app Filesets and their configuration. Use Deployments to assign them to devices.
  • Managed website shortcuts: for a later test, open Filesets → New Mobile Fileset → Play Store, choose Web apps (the globe icon), then +. Enter an approved name and URL, choose the display mode and an optional icon, and select Create. Wait for Google Play to process the web app, reopen it and choose Select to create its Fileset. Add that Fileset to a separate one-device Deployment using the current Deployment controls, not the legacy Associations workflow. Google Chrome must be installed and allowed on the target for the shortcut to open. Keep dedicated-device/kiosk restrictions as a separate test.

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