Настройка Android Enterprise (Work Profile) для корпоративного приложения
Типичная ситуация: сотрудник использует личный Android-смартфон для работы, и ИТ-отдел хочет управлять корпоративными приложениями, не трогая личные данные. Без Work Profile либо весь девайс под MDM, либо никакой изоляции. Оба варианта — плохо.
Android Enterprise Work Profile создаёт отдельный профиль на уровне ОС — со своим launcher, своим keystore, своим сетевым трафиком. Корпоративные приложения работают внутри этого профиля; личные приложения даже не видят их существования.
Где чаще всего ломается интеграция
Самая распространённая проблема — неправильная инициализация Device Policy Controller (DPC). Если приложение регистрируется как Device Owner вместо Profile Owner, оно получает слишком широкие полномочия и ломает пользовательский опыт: блокирует Bluetooth, запрещает смену обоев, вызывает жалобы в отзывах.
Для BYOD-сценария нужен именно ProfileOwner. Провизионирование через QR-код (Android 7+) или NFC bump (Android 6) настраивается через DevicePolicyManager с флагом EXTRA_PROVISIONING_SKIP_ENCRYPTION — без него на старых девайсах весь процесс зависает на шифровании диска.
Вторая точка отказа — cross-profile intent. Если бизнес-логика требует передавать данные из рабочего профиля в личный (например, открыть PDF в системном viewer), нужно явно разрешить это через DevicePolicyManager.addCrossProfileIntentFilter(). Без этого intent молча проглатывается, пользователь видит пустой экран, и никаких логов в Logcat.
Третья проблема — managed configurations. Многие команды просто не используют RestrictionsManager, а толкают настройки через push-уведомления или захардкоженные URL. Это антипаттерн: EMM-система (Intune, VMware Workspace ONE, SOTI) должна деплоить конфиг через APP_RESTRICTIONS_CHANGED, а приложение — читать его из Bundle в onReceive.
Как мы реализуем Work Profile
Процесс начинается с аудита: какой MDM у клиента, какие версии Android в парке устройств, BYOD или COBO (Corporate-Owned, Business-Only). От этого зависит схема провизионирования.
Для BYOD через QR:
// В DPC-приложении, которое становится Profile Owner
val dpm = getSystemService(DevicePolicyManager::class.java)
val adminComponent = ComponentName(this, DeviceAdminReceiver::class.java)
// Проверяем, что мы Profile Owner, не Device Owner
if (dpm.isProfileOwnerApp(packageName)) {
dpm.setProfileName(adminComponent, "Корпоративный профиль")
dpm.setCrossProfileCalendarPackages(adminComponent, setOf(calendarPackage))
}
Для managed configurations используем RestrictionsManager:
val restrictionsManager = getSystemService(RestrictionsManager::class.java)
val appRestrictions = restrictionsManager.applicationRestrictions
val serverUrl = appRestrictions.getString("server_url") ?: BuildConfig.DEFAULT_SERVER
val ssoEnabled = appRestrictions.getBoolean("sso_enabled", false)
Это позволяет ИТ-администратору менять конфигурацию через Intune Policy без нового релиза приложения.
Сертификаты и VPN в Work Profile
Установка клиентских сертификатов через KeyChain.createInstallIntent() работает только в личном профиле. В рабочем — только через DevicePolicyManager.installCaCert() и installKeyPair(). Путаница здесь стоит нескольких дней отладки.
Для VPN в рамках Work Profile — VpnService с флагом setAlwaysOnVpnPackage() через DPC. Трафик рабочего профиля уходит через корпоративный VPN, личный — через обычный интернет. Пользователь этого не чувствует.
Тестирование и инструменты
Отдельный эмулятор с Work Profile — через Android Studio AVD с опцией «Work profile». Для интеграционных тестов с реальным MDM используем TestDPC (open source от Google) — он имитирует поведение Enterprise MDM без Intune.
Android Debug Bridge позволяет переключаться между профилями:
adb shell am switch-user 10 # переключение в рабочий профиль (user id зависит от устройства)
adb shell pm list packages --user 10
Firebase Crashlytics в Work Profile требует отдельной инициализации — по умолчанию SDK не передаёт данные через профильную границу.
Этапы работы
- Аудит — EMM-платформа, парк устройств, требования ИТ-политики
- DPC-разработка — создание или доработка Device Policy Controller под Profile Owner
- Managed Config schema — XML-схема для AppConfig Community (стандарт для Intune/Workspace ONE)
- Интеграционное тестирование — TestDPC + реальные устройства из парка клиента
- Документация для ИТ — инструкция по деплою политик через EMM
Сроки: 2–3 рабочих дня на типовой проект (существующее приложение + Work Profile без кастомного DPC). Если нужен собственный DPC с нуля — от 1 недели.