Managed Configurations on Android: Setting Up Apps for Workers Before They Open Them

A common first-day support ticket goes like this. A worker opens the company app, the app asks for a server address, and nobody on the shop floor knows it. Someone from IT then types the same URL, account name or Wi-Fi-only setting on every device, and sooner or later one of them gets a typo.

Android Enterprise has a standard way to avoid this, called managed configurations. You set an app's values once in your MDM policy. They reach every device that policy covers, and the app reads them on launch. When a worker opens Chrome, the mail client, a scanner app or your own line-of-business app, it already knows where to connect and what is allowed.

This tutorial covers both sides of the setup. You will learn how to find and apply managed configurations for common apps in your MDM's policy editor. You will also learn what to ask your internal developers so your own APKs support the same mechanism.

What a managed configuration is, and who defines the fields

A managed configuration is a set of key-value settings that an organization pushes to an app on a managed Android device. Google's Android Enterprise documentation describes the chain like this:

1. The app developer defines the schema. In the app's res/xml/app_restrictions.xml file, the developer declares every setting the app will accept: its key, its type (string, boolean, integer, choice, multi-select, bundle and so on), a title and a default value.
2. Google Play publishes the schema. When the app is uploaded to Google Play, Play reads that file. Managed Google Play can then show the fields to EMM consoles as a form.
3. Your MDM sends the values. Through the Android Management API, the app's entry in a device policy carries the values you chose.
4. The app reads them. On the device, the app calls RestrictionsManager.getApplicationRestrictions() and applies what it finds.

So the app developer decides which fields exist, not your MDM. If the developer did not publish a "server URL" key, no console can preconfigure the server URL. The console can only fill in fields the developer exposed.

Note: Managed configurations are separate from device policies. A device policy controls Android itself, for example the camera, USB or Wi-Fi. A managed configuration controls settings inside one specific app. You usually need both.

Before you start

• Devices are enrolled in your MDM with Android Enterprise (fully managed, or work profile).
• The apps you want to configure are approved in managed Google Play, or are private apps your developers published there.
• You have a test device that is enrolled under a test policy, not your production policy.
• You know the values you want to push, such as server hostnames, allowed URLs and account formats.

Step 1: Check whether the app supports managed configuration

Before you plan anything, confirm that the app publishes a schema. You can check in three places:

1. Your MDM's policy editor. Add the app to a test policy and see whether a configuration form appears. If it does, the developer published a schema.
2. The vendor's enterprise documentation. Many vendors publish their keys. For example, Google lists Chrome's enterprise policies, with platform support for each one, at chromeenterprise.google/policies.
3. The vendor's support team. Ask: "Does your Android app support Android Enterprise managed configurations, and which keys does it expose?"

Write down each key you need and its type. Schema types include string, bool, integer, choice, multi-select, hidden, bundle and bundle_array. A bool field expects true or false rather than the text "true", and a multi-select field expects values from a fixed list.

Expected result: For each app, you know whether it supports managed configuration and which fields you will set.

Warning: If an app has no schema, there is no workaround inside the managed configuration system. Your options are to ask the vendor to add one, to switch apps, or to keep a documented manual setup step for that app.

Step 2: Add the app to the policy and open its configuration

1. Open the policy that covers the target devices. Use your test policy first.
2. Add the app from managed Google Play if it is not already in the policy.
3. Open the app's configuration form.

In Nomid MDM, the app card in the policy editor opens the app's managed configuration. This is the set of settings the developer publishes through Google Play, shown as fields you fill in. Nomid's own Android apps read their settings the same way.

Expected result: You see a form whose fields match the keys you listed in Step 1.

Note: Google Play reads the schema from the uploaded app, so the form appears for apps distributed through managed Google Play, both public and private. In Nomid, private apps hosted in the Nomid Store also show a configuration form when the uploaded app declares a schema. For any other delivery route, check how configuration works before you rely on it.

Step 3: Fill in the configuration for common apps

Before you fill in values, read Steps 4 and 5. Decide which values are the same for every device on the policy and which differ by site or device, so you don't rebuild the forms later.

Below are the three patterns most fleets need. Field names vary between vendors, so treat the keys as examples and confirm them against each app's own form.

3a. Browser: start page and URL lists (Chrome)

Chrome on Android accepts many of the same enterprise policies as desktop Chrome, delivered as managed configuration. Policies often used on worker devices include:

Before you depend on a policy, check the Chrome Enterprise policy list to confirm it is supported on Android. Some desktop policies, especially around startup and home page behavior, behave differently or are not available on Android. If you need a fixed start screen, managed bookmarks or a kiosk launcher web link are often more predictable. If you block everything with URLBlocklist ["*"], add your identity provider's sign-in pages to URLAllowlist as well, or work sites that need a sign-in won't load.

3b. Mail client: server and account

Enterprise mail apps commonly expose fields such as:

• Email address or user name
• Server host name (for example, an Exchange ActiveSync host)
• SSL/TLS requirement
• Whether personal accounts can be added

Per-user values like the email address are covered in Step 5. For now, fill in the fields that are the same for everyone, such as the server host and the security options.

3c. Scanner and line-of-business apps: server URL and behavior

Rugged-device utilities, scanning apps and business apps usually expose:

• Backend or API base URL, for example https://wms.example.com/api
• Tenant, site or warehouse code
• Feature toggles, such as offline mode, camera scanning versus hardware scanner, or debug logging off

Save the policy. Then make sure your test device is assigned to it. Expected result: Each app's form holds the shared values for this policy, the policy is saved, and the test device uses it.

Warning: Avoid putting passwords or long-lived secrets into managed configuration. The values are stored on the device and readable by the app. Prefer flows where the configuration points the app to the right server and the worker or the app then authenticates.

Step 4: Set it once per policy

Managed configuration belongs to the policy, not to an individual device. Every device on the policy gets the same values. Use this to your advantage:

1. Group devices by what differs. If store A and store B use different backend URLs, they need different configuration. Organize your policies or policy groups around that difference.
2. Reuse a known-good baseline. Build one fully configured policy and use it as the starting point for new sites, so you do not rebuild the configuration by hand. In Nomid, policy templates and policy groups serve this purpose.
3. Change once, roll out everywhere. When the server URL changes, edit it in the policy. Devices pick up the new value at their next policy sync.

Expected result: Each distinct set of values maps to exactly one policy or policy group, and nothing is configured per device by hand.

Step 5: Handle per-device values

Some values are different on every device: a user's email address, a device name, an asset tag, or a serial number your app needs for licensing. Since Android 10, ordinary apps cannot read the hardware serial number themselves, so passing it through managed configuration is a common pattern.

There are two general approaches:

• Variables. The Android Management API lets a console attach configuration variables to a managed configuration template. One template can then resolve to different values on each device. How a console exposes this, and which variables it offers, differs between products. Confirm with your vendor which device or user attributes can be inserted before you design around them.
• Smaller policy scopes. If the per-device value really maps to a site or team, give that group its own policy. For a handful of devices this is simple. For hundreds, it does not scale, and that is a sign you need variables or a change in the app.

A third option sits on the app side. The app can take a shared value such as a tenant ID from configuration and then fetch device-specific settings from its own backend after login. This often holds up better than pushing every per-device detail through the MDM.

Expected result: You have chosen, per field, whether the value is shared (policy-level), variable (resolved per device) or fetched by the app after login.

Step 6: Verify the app picked up the change

1. Confirm the device received the policy. Check its last-seen or sync status in your console. In Nomid, the asset list shows last-seen and contact status.
2. Confirm the app is installed. A configuration sent before installation finishes is applied once the app is present, but the app must actually be installed. Check the device's app list in your console or on the device itself.
3. Force-stop and reopen the app. Many apps read their configuration only at launch. Force-stop it from the app's page in Settings. If the policy blocks Settings, as on a kiosk, reboot the device instead, which can be done remotely.
4. Check inside the app. The server field should be pre-filled and locked, the blocked site should be blocked, and so on. A remote screenshot lets you check without handling the device.

Expected result: On the test device, each configured app shows the pushed values with no manual input. Then roll out in stages: note the current values so you can roll back, copy the tested values into the production policy, apply it to a small pilot group first, and widen it once the pilot devices show the right values.

Note: If the app still shows old values after a force-stop, see the troubleshooting FAQ below. The cause is usually how the app handles configuration, not the delivery.

For in-house apps: ask your developers to publish a schema

If your own app still asks workers to type a server URL, the fix is in the app's code. You can send the following brief to your development team.

1. Declare the schema

Create res/xml/app_restrictions.xml:

<?xml version="1.0" encoding="utf-8"?>
<restrictions xmlns:android="http://schemas.android.com/apk/res/android">
    <restriction
        android:key="server_url"
        android:title="@string/cfg_server_url_title"
        android:description="@string/cfg_server_url_desc"
        android:restrictionType="string"
        android:defaultValue="" />
    <restriction
        android:key="site_code"
        android:title="@string/cfg_site_code_title"
        android:restrictionType="string"
        android:defaultValue="" />
    <restriction
        android:key="allow_offline"
        android:title="@string/cfg_offline_title"
        android:restrictionType="bool"
        android:defaultValue="false" />
</restrictions>

2. Reference it in the manifest

<application ...>
    <meta-data
        android:name="android.content.APP_RESTRICTIONS"
        android:resource="@xml/app_restrictions" />
</application>

3. Read the values, and react to changes

class MainActivity : AppCompatActivity() {
    private val configReceiver = object : BroadcastReceiver() {
        override fun onReceive(context: Context, intent: Intent) = applyConfig()
    }

    override fun onResume() {
        super.onResume()
        applyConfig() // picks up changes made while the app was in the background
        registerReceiver(
            configReceiver,
            IntentFilter(Intent.ACTION_APPLICATION_RESTRICTIONS_CHANGED)
        )
    }

    override fun onPause() {
        unregisterReceiver(configReceiver)
        super.onPause()
    }

    private fun applyConfig() {
        val rm = getSystemService(Context.RESTRICTIONS_SERVICE) as RestrictionsManager
        val config = rm.applicationRestrictions
        val serverUrl = config.getString("server_url", "")
        val allowOffline = config.getBoolean("allow_offline", false)
        // Apply serverUrl and allowOffline to the app's settings here
    }
}

The ACTION_APPLICATION_RESTRICTIONS_CHANGED broadcast is only delivered to receivers registered at runtime. The app should also re-read the configuration in onResume() so changes made while it was in the background apply.

4. Publish through managed Google Play

Upload the app to Google Play, as a private app for your organization if it is not public, so Play can read the schema and show the form to your MDM. Every new release that adds or renames a key needs a new upload.

Checklist for developers

• Keep keys stable. Renaming server_url breaks every policy that sets it.
• Hide a field in the UI when it is set by configuration, so workers cannot override it.
• Fall back gracefully when a key is empty, for example by showing a clear "contact IT" message.
• Never require a secret in configuration. Use it to find the server, then authenticate properly.
• Test with Google's TestDPC app on a device that isn't enrolled in your MDM. TestDPC has to be the device's management app, so it can't run on a device your MDM already manages.

Troubleshooting FAQ

The app has no configuration form in my policy editor.

The developer has not published a schema through Google Play, or the version on Play predates it. Check the vendor's documentation, or ask them directly. For in-house apps, confirm the manifest meta-data entry exists and that the build with the schema was uploaded. A key added in a new release only shows up in the form after that version has been uploaded to Google Play and processed.

I changed a value, but the app still shows the old one.

Work through these in order:

1. Has the device synced the updated policy? Check last-seen.
2. Force-stop and reopen the app. If the new value now appears, the app only reads configuration at launch and does not listen for the change broadcast.
3. If it still does not appear, the app may have cached the old value in its own storage. Clearing the app's data fixes that, but it deletes anything stored only on the device, such as offline scans not yet synced, so sync first. Otherwise the developer needs to fix the app.

The value arrives, but the app ignores it.

Check that the key name and type match the schema exactly. Keys are case-sensitive, and a boolean sent as a string will not be read as a boolean. Also check whether the app version on the device is older than the one that introduced the key. On a device with a work profile, check that the worker opened the work copy of the app, shown with a briefcase badge. The personal copy never receives the configuration.

Some Chrome policies work and others do not.

Not every Chrome Enterprise policy is supported on Android. Check each one's platform support in the Chrome Enterprise policy list, and check the Chrome version on the device.

Can I push a different value to each device?

Yes, but not by default. Use configuration variables if your console supports them for the attribute you need, split devices into smaller policies, or have the app fetch per-device settings from its backend. See Step 5.

The configuration applied, but the worker can still edit the field.

Locking a field is the app's job, not Android's. Ask the developer to disable or hide settings that come from managed configuration.

How do I test without touching production?

Use a dedicated test policy and one enrolled device. For in-house apps, developers can use TestDPC before the app ever reaches your MDM.

Next steps

Key takeaways:

• The app developer defines what can be configured. Your MDM fills in those fields and nothing more.
• Confirm support first, record the keys and types, and test on one device before rolling out.
• Shared values belong in the policy. Per-device values need variables, smaller scopes, or app-side lookups.
• For in-house apps, adding a schema takes a small, well-documented change, and it removes the manual setup step for workers.

Start this week with the app that generates the most setup tickets. List its keys, build a test policy, and verify it on one device. Then send the developer checklist above to the team that owns your internal app.

If you want to try this flow with Nomid MDM, the app card in the policy editor opens each app's managed configuration, and the free plan covers up to 10 devices with no time limit. That is enough for a test policy and a pilot group. Remote access and the API are not included on the free plan.

FAQ

What is an Android managed configuration?

It is a set of key-value settings that an organization pushes to an app on a managed Android device. Examples include a server URL, allowed websites or feature toggles. The app's developer defines the available fields in a schema published through Google Play, and the MDM sends the values through the device policy.

How do I know if an app supports app config on Android Enterprise?

Add the app to a test policy in your MDM and see whether a configuration form appears. You can also check the vendor's enterprise documentation or ask their support team which managed configuration keys the app exposes.

What is app_restrictions.xml?

It is the XML file in an Android app's resources where the developer declares the managed configuration schema: each setting's key, type, title and default value. The file is referenced in the app manifest, and Google Play reads it when the app is uploaded.

Does a managed configuration change apply immediately?

The device receives it at its next policy sync. Whether the app applies it right away depends on the app. Apps that listen for the restrictions-changed broadcast update while running, while others only read their configuration at the next launch.