Прекращение поддержки Device Admin. Некоторые правила администратора помечены как устаревшие при вызове администратором устройства. Подробнее о прекращении поддержки администратора устройства и вариантах переноса…
Начиная с Android 2.2 (уровень API 8), платформа Android предлагает возможности управления устройствами на системном уровне через API администрирования устройств.
На этом уроке вы узнаете, как создать приложение, которое управляет доступом к своему контенту, применяя политики управления устройствами. В частности, приложение можно настроить так, чтобы оно проверяло, установлен ли достаточно надежный пароль для разблокировки экрана, прежде чем показывать пользователю контент с ограничениями.
Определите и объявите свои правила
Сначала нужно определить, какие правила будут поддерживаться на функциональном уровне. Правила могут касаться надежности пароля для блокировки экрана, срока его действия, шифрования и т. д.
Вы должны объявить выбранный набор правил, который будет применяться приложением, в файле res/xml/device_admin.xml. В манифесте Android также должна быть ссылка на набор правил.
Каждое объявленное правило соответствует определенному количеству связанных методов правил для устройств в DevicePolicyManager (например, определение минимальной длины пароля и минимального количества заглавных букв). Если приложение попытается вызвать методы, правила которых не объявлены в XML-файле, во время выполнения возникнет ошибка SecurityException. Другие разрешения, например force-lock, доступны, если приложение предназначено для управления другими типами правил. Как вы увидите позже, в процессе активации администратора устройства список объявленных политик будет представлен пользователю на системном экране.
В следующем фрагменте кода показано, как объявить правила ограничения паролей в res/xml/device_admin.xml:
<device-admin xmlns:android="http://schemas.android.com/apk/res/android"> <uses-policies> <limit-password /> </uses-policies> </device-admin>
XML-файл декларации о соответствии правилам, на который ссылается манифест Android:
<receiver android:name=".Policy$PolicyAdmin" android:permission="android.permission.BIND_DEVICE_ADMIN"> <meta-data android:name="android.app.device_admin" android:resource="@xml/device_admin" /> <intent-filter> <action android:name="android.app.action.DEVICE_ADMIN_ENABLED" /> </intent-filter> </receiver>
Создание получателя администрирования устройства
Создайте широковещательный приемник для администратора устройства, который будет получать уведомления о событиях, связанных с правилами, которые вы объявили для поддержки. Приложение может выборочно переопределять методы обратного вызова.
В примере приложения Device Admin, когда администратор устройства деактивируется пользователем, настроенное правило удаляется из общих настроек. Рекомендуем реализовать бизнес-логику, которая подходит для вашего случая. Например, приложение может удалить конфиденциальные данные с устройства, отключить удаленную синхронизацию, оповестить администратора и т. д.
Чтобы широковещательный приемник работал, зарегистрируйте его в манифесте Android, как показано в приведенном выше фрагменте кода.
Kotlin
class PolicyAdmin : DeviceAdminReceiver() { override fun onDisabled(context: Context, intent: Intent) { // Called when the app is about to be deactivated as a device administrator. // Deletes previously stored password policy. super.onDisabled(context, intent) context.getSharedPreferences(APP_PREF, Activity.MODE_PRIVATE).edit().apply { clear() apply() } } }
Java
public static class PolicyAdmin extends DeviceAdminReceiver { @Override public void onDisabled(Context context, Intent intent) { // Called when the app is about to be deactivated as a device administrator. // Deletes previously stored password policy. super.onDisabled(context, intent); SharedPreferences prefs = context.getSharedPreferences(APP_PREF, Activity.MODE_PRIVATE); prefs.edit().clear().commit(); } }
Активируйте администратора устройства.
Прежде чем применять правила, пользователь должен вручную активировать приложение в качестве администратора устройства. В приведенном ниже фрагменте кода показано, как запустить действие настроек, в котором пользователь может активировать ваше приложение. Рекомендуется добавить пояснительный текст, чтобы пользователи понимали, почему приложение запрашивает права администратора устройства. Для этого укажите дополнительный параметр EXTRA_ADD_EXPLANATION в намерении.
Рисунок 1. Экран активации пользователя, на котором можно добавить описание правил для устройств.
Kotlin
if (!policy.isAdminActive()) { val activateDeviceAdminIntent = Intent(DevicePolicyManager.ACTION_ADD_DEVICE_ADMIN) activateDeviceAdminIntent.putExtra( DevicePolicyManager.EXTRA_DEVICE_ADMIN, policy.getPolicyAdmin() ) // It is good practice to include the optional explanation text to // explain to user why the application is requesting to be a device // administrator. The system will display this message on the activation // screen. activateDeviceAdminIntent.putExtra( DevicePolicyManager.EXTRA_ADD_EXPLANATION, resources.getString(R.string.device_admin_activation_message) ) startActivityForResult(activateDeviceAdminIntent, REQ_ACTIVATE_DEVICE_ADMIN) }
Java
if (!policy.isAdminActive()) { Intent activateDeviceAdminIntent = new Intent(DevicePolicyManager.ACTION_ADD_DEVICE_ADMIN); activateDeviceAdminIntent.putExtra( DevicePolicyManager.EXTRA_DEVICE_ADMIN, policy.getPolicyAdmin()); // It is good practice to include the optional explanation text to // explain to user why the application is requesting to be a device // administrator. The system will display this message on the activation // screen. activateDeviceAdminIntent.putExtra( DevicePolicyManager.EXTRA_ADD_EXPLANATION, getResources().getString(R.string.device_admin_activation_message)); startActivityForResult(activateDeviceAdminIntent, REQ_ACTIVATE_DEVICE_ADMIN); }
Если пользователь выбирает "Активировать", приложение становится администратором устройства и может начать настройку и применение правил.
Приложение также должно быть готово к ситуациям, когда пользователь прерывает процесс активации, нажимая кнопку "Отмена", "Назад" или "Домой". Поэтому в onResume() в Policy Set Up Activity должна быть логика, которая повторно оценивает условие и при необходимости предлагает пользователю активировать администратора устройства.
Как реализовать контроллер политик на устройствах
После успешной активации администратора устройства приложение настраивает Менеджер правил для устройств в соответствии с запрошенным правилом. Помните, что с каждым выпуском в Android добавляются новые правила. Если вы используете новые правила и при этом поддерживаете более ранние версии платформы, то в приложении целесообразно выполнять проверку версии. Например, правило "Минимальное количество заглавных букв в пароле" доступно только для уровня API 11 (Honeycomb) и выше. В примере кода ниже показано, как проверить версию во время выполнения.
Kotlin
private lateinit var dpm: DevicePolicyManager private lateinit var policyAdmin: ComponentName dpm = context.getSystemService(Context.DEVICE_POLICY_SERVICE) as DevicePolicyManager policyAdmin = ComponentName(context, PolicyAdmin::class.java) dpm.apply { setPasswordQuality(policyAdmin, PASSWORD_QUALITY_VALUES[passwordQuality]) setPasswordMinimumLength(policyAdmin, passwordLength) if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) { setPasswordMinimumUpperCase(policyAdmin, passwordMinUpperCase) } }
Java
DevicePolicyManager dpm = (DevicePolicyManager) context.getSystemService(Context.DEVICE_POLICY_SERVICE); ComponentName policyAdmin = new ComponentName(context, PolicyAdmin.class); dpm.setPasswordQuality(policyAdmin, PASSWORD_QUALITY_VALUES[passwordQuality]); dpm.setPasswordMinimumLength(policyAdmin, passwordLength); if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) { dpm.setPasswordMinimumUpperCase(policyAdmin, passwordMinUpperCase); }
После этого приложение сможет применять правила. Хотя у приложения нет доступа к паролю блокировки экрана, с помощью API Device Policy Manager оно может определить, соответствует ли существующий пароль требованиям. Если окажется, что существующий пароль для разблокировки экрана не соответствует требованиям, API администрирования устройств не будет автоматически предпринимать корректирующие действия. Приложение должно явным образом запускать системный экран смены пароля в приложении "Настройки". Пример:
Kotlin
if (!dpm.isActivePasswordSufficient) { // Triggers password change screen in Settings. Intent(DevicePolicyManager.ACTION_SET_NEW_PASSWORD).also { intent -> startActivity(intent) } }
Java
if (!dpm.isActivePasswordSufficient()) { ... // Triggers password change screen in Settings. Intent intent = new Intent(DevicePolicyManager.ACTION_SET_NEW_PASSWORD); startActivity(intent); }
Обычно пользователь может выбрать один из доступных механизмов блокировки, например "Нет", "Графический ключ", "PIN-код" (цифровой) или "Пароль" (буквенно-цифровой). Если правило настроено, типы паролей, которые не соответствуют требованиям, будут отключены. Например, если задано требование "Цифровой", пользователь может выбрать только PIN-код (цифровой) или пароль (буквенно-цифровой).
После того как пользователь установит надежный пароль для разблокировки экрана, приложение разрешит доступ к защищенному контенту.
Kotlin
when { !dpm.isAdminActive(policyAdmin) -> { // Activates device administrator. ... } !dpm.isActivePasswordSufficient -> { // Launches password set-up screen in Settings. ... } else -> { // Grants access to secure content. ... startActivity(Intent(context, SecureActivity::class.java)) } }
Java
if (!dpm.isAdminActive(..)) { // Activates device administrator. ... } else if (!dpm.isActivePasswordSufficient()) { // Launches password set-up screen in Settings. ... } else { // Grants access to secure content. ... startActivity(new Intent(context, SecureActivity.class)); }