When a company deploys your Android app to its employees through a mobile management system, it often needs to configure the app remotely: set the server URL, turn features on or off, enforce restrictions. Android Enterprise provides this through managed configurations, settings an administrator sets that your app reads at runtime, and it runs managed apps in a work profile that keeps company data separate from personal data. Supporting this well makes your app deployable in regulated and security-conscious organizations, but it also means reading admin-supplied configuration and respecting a data boundary you must not cross. Here is what managed configurations and the work profile are and how to support enterprise management securely.
Short answer
Android Enterprise lets an organization manage your app: managed configurations are settings an administrator defines and pushes through a management system, which your app reads at runtime via the restrictions framework, and the work profile keeps managed app data separate from the user's personal data. Per Android, supporting managed configurations means declaring the configuration keys your app exposes and reading the admin-set values, while respecting the work-profile boundary means not leaking work data into the personal profile. The security points are to validate managed configuration values rather than trusting them blindly, not hardcode settings that should be admin-controlled, and honor the separation between work and personal data. Done well, this makes your app deployable in security-conscious organizations.
What you should know
- Managed configurations are admin-set values: your app reads them at runtime.
- They are declared by your app: the configuration keys you expose.
- The work profile separates work and personal data: a data boundary to respect.
- Validate managed config values: do not trust them blindly.
- Support it for enterprise deployment: secure, configurable rollout.
What are managed configurations and the work profile?
They are the two pillars of Android Enterprise management for your app. Managed configurations are settings your app declares, a list of keys like a server URL, a feature flag, or a restriction, that an administrator can set remotely through the organization's management system, and your app reads them at runtime via the restrictions framework. This lets an enterprise deploy your app pre-configured for its environment, without each user setting it up, which is essential for managed rollouts. The work profile is the other pillar: on a managed device, work apps and their data live in a separate, managed profile, isolated from the user's personal profile and apps, so company data stays contained and the organization can manage it without touching personal data. Together they let an organization deploy, configure, and contain your app. For you as the developer, supporting managed configurations means exposing the right keys and reading them, and operating in a work profile means honoring the boundary that keeps work data separate from personal data.
How do they work?
Through declared keys, admin-set values, and a profile boundary. The table summarizes.
| Element | Detail |
|---|---|
| Configuration keys | Your app declares the settings it exposes to admins |
| Admin-set values | An administrator sets them via the management system |
| Runtime read | Your app reads the values through the restrictions framework |
| Work profile | Managed app data is isolated from the personal profile |
| Cross-profile limits | Sharing between work and personal is restricted |
The flow for managed configurations is that your app declares which settings it supports as a set of keys with types, an administrator configures values for those keys in their management console, and the management system applies them to the device, where your app reads them at runtime and can be notified when they change. The values are set by a trusted administrator, but they still arrive as input your app consumes, so they warrant validation. The work profile flow is about isolation: a managed device can have a work profile containing managed apps and their data, separated from the personal profile, with the platform restricting data sharing across the boundary, so a work app generally cannot freely move data into the personal space and vice versa. Both mechanisms exist to give organizations control and containment over the apps they deploy.
How do you support enterprise management securely?
Expose the right configuration, validate it, and respect the profile boundary. Declare managed configuration keys for the settings an enterprise legitimately needs to control, server endpoints, feature and security toggles, restrictions, so administrators can deploy your app correctly without users hand-configuring it, and avoid hardcoding values that should be admin-controlled. Read the admin-set values at runtime and respond to changes, but validate them as you would any input, since a misconfigured or unexpected value should be handled gracefully rather than trusted to be well-formed, even though it comes from an administrator. Respect the work-profile boundary: do not attempt to move work data into the personal profile or otherwise undermine the separation the platform enforces, since that isolation is the point of the managed deployment and a key expectation of the organizations relying on it. Where your app handles sensitive enterprise data, keep it within the managed profile and apply your normal secure storage and transport. Follow Android Enterprise guidance for the management features you support. The principle is that managed configurations let administrators securely tailor your app, so expose what they need, validate what you read, and honor the work-and-personal data boundary that makes managed deployment safe.
What to watch out for
The first trap is not supporting managed configurations when your app targets enterprises, forcing manual setup and hardcoded values where admins should have control. The second is trusting managed configuration values without validation, when they are still input that could be misconfigured. The third is undermining the work-profile boundary by moving work data into the personal profile, which breaks the isolation organizations depend on. Managed configuration and profile behavior are implemented in your app, so a pre-submission scan such as PTKD.com (https://ptkd.com), which reads the compiled APK or AAB against OWASP MASVS, assesses your app's data handling and configuration, while exposing and validating managed config and respecting the profile boundary are yours to implement.
What to take away
- Android Enterprise manages your app through managed configurations, admin-set values your app declares and reads at runtime, and the work profile, which isolates managed app data from personal data.
- Support it by declaring the configuration keys enterprises need, reading and validating the admin-set values, and not hardcoding settings that should be admin-controlled.
- Respect the work-profile boundary by keeping work data within the managed profile and not undermining the separation from personal data.
- Use a pre-submission scan such as PTKD.com to assess your app's data handling and configuration, and implement managed configuration and profile separation correctly.
