Настройка Android Enterprise (Work Profile) для корпоративного додатка
Типова ситуація: сотрудник використовує особистий Android-смартфон для роботи, ІТ-відділ хоче управляти корпоративними додатками, не торкаючись особистих даних. Без Work Profile або весь девайс під MDM, або ніякої ізоляції. Обидва варіанти—погано.
Android Enterprise Work Profile створює окремий профіль на рівні ОС—зі своїм launcher, своїм keystore, ізольованим сховищем. Корпоративні додатки працюють у цьому профілі; особисті додатки навіть не бачать їх існування.
Де чаще всього ломається інтеграція
Найпоширеніша проблема—неправильна ініціалізація Device Policy Controller (DPC). Якщо додаток реєструється як Device Owner замість Profile Owner, отримує занадто широкі повноваження та ломає UX: блокує 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 тижня.