Прекращение поддержки администратора устройства . Начиная с Android 9 (уровень API 28), некоторые политики администратора будут помечены как устаревшие при вызове администратором устройства. Мы рекомендуем вам начать готовиться к этим изменениям уже сейчас. Чтобы узнать больше и просмотреть варианты миграции, прочтите статью Прекращение поддержки администратора устройства .
Android включает поддержку корпоративных приложений, предлагая API администрирования устройств Android. API администрирования устройств предоставляет функции администрирования устройств на уровне системы. Эти API позволяют создавать безопасные приложения, полезные в корпоративных условиях, где ИТ-специалистам требуется полный контроль над устройствами сотрудников. Например, встроенное приложение электронной почты Android использует эти API для улучшения поддержки Exchange. С помощью приложения «Электронная почта» администраторы Exchange могут применять политики паролей, включая буквенно-цифровые пароли или числовые ПИН-коды, на всех устройствах. Администраторы также могут удаленно стереть (то есть восстановить заводские настройки) потерянные или украденные телефоны. Пользователи Exchange могут синхронизировать свою электронную почту и данные календаря.
Этот документ предназначен для разработчиков, которые хотят разрабатывать корпоративные решения для устройств под управлением Android. В нем обсуждаются различные функции, предоставляемые API администрирования устройств для обеспечения более надежной безопасности устройств сотрудников на базе Android.
Примечание. Информацию о создании контроллера политики работы для развертываний Android for Work см. в разделе Создание контроллера политики устройства .
Режим владельца безголового устройства
В Android 14 (уровень API 34) представлен режим пользователя безголовой системы (устройства, в которых UserManager.isHeadlessSystemUserMode
возвращает true
). В режиме пользователя безголовой системы пользователь системы является фоновым пользователем и полагается на дополнительных пользователей на переднем плане для взаимодействия с конечным пользователем. В Android 14 также представлен аффилированный режим владельца безголового устройства , который добавляет владельца профиля ко всем аффилированным пользователям, кроме системного пользователя, для которого установлен владелец устройства.
В устройствах, настроенных с использованием автономного пользователя системы (где пользователь системы работает в фоновом режиме), к пользователю или пользователям приоритетного режима применяются только политики устройства, которые являются глобальными по области действия (политики, применимые ко всем пользователям). Подробности см. в разделе addUserRestriction
.
Производители устройств Android могут обратиться к руководству, опубликованному на сайте source.android.com.
Обзор API администрирования устройств
Вот примеры типов приложений, которые могут использовать API администрирования устройств:
- Почтовые клиенты.
- Приложения безопасности, которые выполняют удаленную очистку.
- Службы и приложения управления устройствами.
Как это работает?
Вы используете API администрирования устройств для написания приложений администрирования устройств, которые пользователи устанавливают на свои устройства. Приложение администратора устройства применяет нужные политики. Вот как это работает:
- Системный администратор пишет приложение администратора устройства, которое обеспечивает соблюдение политик безопасности удаленного/локального устройства. Эти политики могут быть жестко запрограммированы в приложении, либо приложение может динамически получать политики со стороннего сервера.
- Приложение устанавливается на устройства пользователей. В настоящее время в Android нет решения для автоматической подготовки. Вот некоторые способы, которыми системный администратор может распространять приложение среди пользователей:
- Гугл Плей.
- Включение установки из другого магазина.
- Распространение приложения другими способами, например по электронной почте или через веб-сайты.
- Система предложит пользователю включить приложение администратора устройства. Как и когда это произойдет, зависит от того, как реализовано приложение.
- Как только пользователи включают приложение администратора устройства, на них распространяются его политики. Соблюдение этих политик обычно дает преимущества, такие как доступ к конфиденциальным системам и данным.
Если пользователи не включают приложение администратора устройства, оно остается на устройстве, но в неактивном состоянии. На пользователей не будут распространяться его политики, и, наоборот, они не получат никаких преимуществ приложения — например, они не смогут синхронизировать данные.
Если пользователь не соблюдает политики (например, если пользователь устанавливает пароль, который нарушает правила), приложение должно решить, как с этим справиться. Однако обычно это приводит к тому, что пользователь не сможет синхронизировать данные.
Если устройство попытается подключиться к серверу, которому требуются политики, не поддерживаемые в API администрирования устройств, подключение не будет разрешено. API администрирования устройств в настоящее время не поддерживает частичную подготовку. Другими словами, если устройство (например, устаревшее устройство) не поддерживает все заявленные политики, разрешить подключение устройства невозможно.
Если на устройстве имеется несколько включенных приложений администратора, применяется самая строгая политика. Невозможно настроить таргетинг на конкретное приложение администратора.
Чтобы удалить существующее приложение администратора устройства, пользователям необходимо сначала отменить регистрацию приложения в качестве администратора.
Политика
В корпоративной среде часто бывает так, что устройства сотрудников должны соответствовать строгому набору политик, регулирующих использование устройств. API администрирования устройств поддерживает политики, перечисленные в таблице 1. Обратите внимание, что API администрирования устройств в настоящее время поддерживает только пароли для блокировки экрана:
Политика | Описание |
---|---|
Пароль включен | Требуется, чтобы устройства запрашивали PIN-код или пароли. |
Минимальная длина пароля | Установите необходимое количество символов для пароля. Например, вы можете потребовать, чтобы PIN-код или пароли содержали не менее шести символов. |
Требуется буквенно-цифровой пароль | Требуется, чтобы пароли содержали комбинацию букв и цифр. Они могут включать символические символы. |
Требуется сложный пароль | Требуется, чтобы пароли содержали как минимум букву, цифру и специальный символ. Представлено в Android 3.0. |
Минимальное количество букв в пароле | Минимальное количество букв, необходимое в пароле для всех администраторов или конкретного. Представлено в Android 3.0. |
Минимальное количество строчных букв в пароле | Минимальное количество строчных букв, необходимое в пароле для всех администраторов или конкретного. Представлено в Android 3.0. |
Минимальное количество небуквенных символов, необходимых в пароле | Минимальное количество небуквенных символов, необходимое в пароле для всех администраторов или конкретного. Представлено в Android 3.0. |
Минимальное число цифр, необходимое в пароле | Минимальное количество цифр, необходимое в пароле для всех администраторов или конкретного. Представлено в Android 3.0. |
Минимальное количество символов, необходимое в пароле | Минимальное количество символов, необходимое в пароле для всех администраторов или конкретного. Представлено в Android 3.0. |
Минимальное количество заглавных букв в пароле | Минимальное количество заглавных букв, необходимое в пароле для всех администраторов или конкретного. Представлено в Android 3.0. |
Таймаут истечения срока действия пароля | Когда истечет срок действия пароля, выражается в виде разницы в миллисекундах с момента, когда администратор устройства устанавливает время истечения срока действия. Представлено в Android 3.0. |
Ограничение истории паролей | Эта политика запрещает пользователям повторно использовать последние n уникальных паролей. Эта политика обычно используется вместе с setPasswordExpirationTimeout() , которая заставляет пользователей обновлять свои пароли по истечении определенного периода времени. Представлено в Android 3.0. |
Максимальное количество неудачных попыток ввода пароля | Указывает, сколько раз пользователь может ввести неправильный пароль, прежде чем устройство сотрет свои данные. API администрирования устройств также позволяет администраторам удаленно сбрасывать настройки устройства к заводским настройкам. Это защищает данные в случае потери или кражи устройства. |
Блокировка максимального времени бездействия | Устанавливает продолжительность времени с момента последнего касания пользователем экрана или нажатия кнопки, прежде чем устройство блокирует экран. В этом случае пользователям необходимо снова ввести свой PIN-код или пароли, прежде чем они смогут использовать свои устройства и получить доступ к данным. Значение может находиться в диапазоне от 1 до 60 минут. |
Требовать шифрование хранилища | Указывает, что область хранения должна быть зашифрована, если устройство поддерживает это. Представлено в Android 3.0. |
Отключить камеру | Указывает, что камеру следует отключить. Обратите внимание, что это не обязательно должно быть постоянное отключение. Камеру можно включать/отключать динамически в зависимости от контекста, времени и т. д. Представлено в Android 4.0. |
Другие особенности
Помимо поддержки политик, перечисленных в таблице выше, API администрирования устройств позволяет делать следующее:
- Предложить пользователю установить новый пароль.
- Немедленно заблокируйте устройство.
- Сотрите данные устройства (то есть восстановите заводские настройки устройства).
Пример приложения
Примеры, использованные на этой странице, основаны на образце API администрирования устройств, который включен в примеры SDK (доступен через Android SDK Manager) и расположен в вашей системе как <sdk_root>/ApiDemos/app/src/main/java/com/example/android/apis/app/DeviceAdminSample.java
.
Пример приложения предлагает демонстрацию функций администрирования устройства. Он предоставляет пользователям пользовательский интерфейс, который позволяет им включить приложение администратора устройства. После включения приложения они смогут использовать кнопки пользовательского интерфейса для выполнения следующих действий:
- Установите качество пароля.
- Укажите требования к паролю пользователя, такие как минимальная длина, минимальное количество цифровых символов, которые он должен содержать, и т. д.
- Установите пароль. Если пароль не соответствует указанным политикам, система возвращает ошибку.
- Установите, сколько неудачных попыток ввода пароля может произойти до того, как устройство будет очищено (т. е. восстановлено до заводских настроек).
- Установите срок действия пароля.
- Установите длину истории паролей ( длина относится к количеству старых паролей, хранящихся в истории). Это не позволяет пользователям повторно использовать один из последних n паролей, которые они использовали ранее.
- Укажите, что область хранения должна быть зашифрована, если устройство это поддерживает.
- Установите максимальное время неактивности, которое может пройти до блокировки устройства.
- Немедленно заблокируйте устройство.
- Стереть данные устройства (то есть восстановить заводские настройки).
- Отключите камеру.
Разработка приложения для администрирования устройств
Системные администраторы могут использовать API администрирования устройств для написания приложения, которое обеспечивает соблюдение политики безопасности удаленного/локального устройства. В этом разделе кратко описаны шаги, необходимые для создания приложения для администрирования устройств.
Создание манифеста
Чтобы использовать API администрирования устройств, манифест приложения должен включать следующее:
- Подкласс
DeviceAdminReceiver
, который включает в себя следующее:- Разрешение
BIND_DEVICE_ADMIN
. - Возможность реагировать на намерение
ACTION_DEVICE_ADMIN_ENABLED
, выраженное в манифесте как фильтр намерения.
- Разрешение
- Декларация политик безопасности, используемых в метаданных.
Вот выдержка из образца манифеста администрирования устройств:
<activity android:name=".app.DeviceAdminSample" android:label="@string/activity_sample_device_admin"> <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.SAMPLE_CODE" /> </intent-filter> </activity> <receiver android:name=".app.DeviceAdminSample$DeviceAdminSampleReceiver" android:label="@string/sample_device_admin" android:description="@string/sample_device_admin_description" android:permission="android.permission.BIND_DEVICE_ADMIN"> <meta-data android:name="android.app.device_admin" android:resource="@xml/device_admin_sample" /> <intent-filter> <action android:name="android.app.action.DEVICE_ADMIN_ENABLED" /> </intent-filter> </receiver>
Обратите внимание, что:
- Следующие атрибуты относятся к строковым ресурсам, которые для примера приложения находятся в
ApiDemos/res/values/strings.xml
. Дополнительные сведения о ресурсах см. в разделе Ресурсы приложения .-
android:label="@string/activity_sample_device_admin"
относится к читаемой пользователем метке действия. -
android:label="@string/sample_device_admin"
относится к читаемой пользователем метке разрешения. -
android:description="@string/sample_device_admin_description"
относится к читаемому пользователем описанию разрешения. Описание обычно длиннее и информативнее, чем этикетка.
-
-
android:permission="android.permission.BIND_DEVICE_ADMIN"
— это разрешение, которое должен иметь подклассDeviceAdminReceiver
, чтобы гарантировать, что только система может взаимодействовать с получателем (ни одному приложению не может быть предоставлено это разрешение). Это предотвращает злоупотребление другими приложениями приложения администратора вашего устройства. -
android.app.action.DEVICE_ADMIN_ENABLED
— это основное действие, которое должен обрабатывать подклассDeviceAdminReceiver
, чтобы ему было разрешено управлять устройством. Это значение устанавливается на приемнике, когда пользователь включает приложение администратора устройства. Ваш код обычно обрабатывает это вonEnabled()
. Для поддержки получателю также необходимо разрешениеBIND_DEVICE_ADMIN
, чтобы другие приложения не могли им злоупотреблять. - Когда пользователь включает приложение администратора устройства, это дает получателю разрешение выполнять действия в ответ на трансляцию определенных системных событий. При возникновении подходящего события приложение может применить политику. Например, если пользователь пытается установить новый пароль, который не соответствует требованиям политики, приложение может предложить пользователю выбрать другой пароль, который соответствует требованиям.
- Не меняйте имя получателя после публикации приложения. Если имя в манифесте изменится, администратор устройства отключится, когда пользователи обновят приложение. Чтобы узнать больше, см.
<receiver>
. -
android:resource="@xml/device_admin_sample"
объявляет политики безопасности, используемые в метаданных. Метаданные предоставляют дополнительную информацию, специфичную для администратора устройства, анализируемую классомDeviceAdminInfo
. Вот содержимоеdevice_admin_sample.xml
:
<device-admin xmlns:android="http://schemas.android.com/apk/res/android"> <uses-policies> <limit-password /> <watch-login /> <reset-password /> <force-lock /> <wipe-data /> <expire-password /> <encrypted-storage /> <disable-camera /> </uses-policies> </device-admin>
При разработке приложения для администрирования устройств вам не обязательно включать все политики, а только те, которые актуальны для вашего приложения.
Дополнительные сведения о файле манифеста см. в Руководстве для разработчиков Android .Реализация кода
API администрирования устройств включает следующие классы:
-
DeviceAdminReceiver
- Базовый класс для реализации компонента администрирования устройства. Этот класс обеспечивает удобство интерпретации необработанных действий намерения, отправляемых системой. Ваше приложение администрирования устройств должно включать подкласс
DeviceAdminReceiver
. -
DevicePolicyManager
- Класс для управления политиками, применяемыми на устройстве. Большинство клиентов этого класса должны опубликовать
DeviceAdminReceiver
, который в данный момент включен пользователем.DevicePolicyManager
управляет политиками для одного или нескольких экземпляровDeviceAdminReceiver
. -
DeviceAdminInfo
- Этот класс используется для указания метаданных для компонента администратора устройства.
Эти классы обеспечивают основу для полнофункционального приложения для администрирования устройств. В оставшейся части этого раздела описывается, как использовать API-интерфейсы DeviceAdminReceiver
и DevicePolicyManager
для написания приложения администратора устройства.
Создание подкласса DeviceAdminReceiver
Чтобы создать приложение администратора устройства, необходимо создать подкласс DeviceAdminReceiver
. Класс DeviceAdminReceiver
состоит из серии обратных вызовов, которые запускаются при возникновении определенных событий.
В подклассе DeviceAdminReceiver
пример приложения просто отображает Toast
уведомление в ответ на определенные события. Например:
Котлин
class DeviceAdminSample : DeviceAdminReceiver() { private fun showToast(context: Context, msg: String) { context.getString(R.string.admin_receiver_status, msg).let { status -> Toast.makeText(context, status, Toast.LENGTH_SHORT).show() } } override fun onEnabled(context: Context, intent: Intent) = showToast(context, context.getString(R.string.admin_receiver_status_enabled)) override fun onDisableRequested(context: Context, intent: Intent): CharSequence = context.getString(R.string.admin_receiver_status_disable_warning) override fun onDisabled(context: Context, intent: Intent) = showToast(context, context.getString(R.string.admin_receiver_status_disabled)) override fun onPasswordChanged(context: Context, intent: Intent, userHandle: UserHandle) = showToast(context, context.getString(R.string.admin_receiver_status_pw_changed)) ... }
Ява
public class DeviceAdminSample extends DeviceAdminReceiver { void showToast(Context context, String msg) { String status = context.getString(R.string.admin_receiver_status, msg); Toast.makeText(context, status, Toast.LENGTH_SHORT).show(); } @Override public void onEnabled(Context context, Intent intent) { showToast(context, context.getString(R.string.admin_receiver_status_enabled)); } @Override public CharSequence onDisableRequested(Context context, Intent intent) { return context.getString(R.string.admin_receiver_status_disable_warning); } @Override public void onDisabled(Context context, Intent intent) { showToast(context, context.getString(R.string.admin_receiver_status_disabled)); } @Override public void onPasswordChanged(Context context, Intent intent, UserHandle userHandle) { showToast(context, context.getString(R.string.admin_receiver_status_pw_changed)); } ... }
Включение приложения
Одним из основных событий, которые должно обрабатывать приложение администратора устройства, является включение приложения пользователем. Пользователь должен явно включить приложение, чтобы политики применялись. Если пользователь решит не включать приложение, оно все равно будет присутствовать на устройстве, но его политики не будут применяться, и пользователь не получит никаких преимуществ приложения.
Процесс включения приложения начинается, когда пользователь выполняет действие, которое запускает намерение ACTION_ADD_DEVICE_ADMIN
. В примере приложения это происходит, когда пользователь устанавливает флажок Включить администратора .
Когда пользователь устанавливает флажок «Включить администрирование» , дисплей меняется, предлагая пользователю активировать приложение администратора устройства, как показано на рисунке 2.
Ниже приведен код, который выполняется, когда пользователь устанавливает флажок « Включить администратора» . Это приводит к запуску обратного вызова onPreferenceChange()
. Этот обратный вызов вызывается, когда значение этого Preference
было изменено пользователем и скоро будет установлено и/или сохранено. Если пользователь включает приложение, дисплей меняется, предлагая пользователю активировать приложение администратора устройства, как показано на рисунке 2. В противном случае приложение администратора устройства отключается.
Котлин
override fun onPreferenceChange(preference: Preference, newValue: Any): Boolean { if (super.onPreferenceChange(preference, newValue)) return true val value = newValue as Boolean if (preference == enableCheckbox) { if (value != adminActive) { if (value) { // Launch the activity to have the user enable our admin. val intent = Intent(DevicePolicyManager.ACTION_ADD_DEVICE_ADMIN).apply { putExtra(DevicePolicyManager.EXTRA_DEVICE_ADMIN, deviceAdminSample) putExtra(DevicePolicyManager.EXTRA_ADD_EXPLANATION, activity.getString(R.string.add_admin_extra_app_text)) } startActivityForResult(intent, REQUEST_CODE_ENABLE_ADMIN) // return false - don't update checkbox until we're really active return false } else { dpm.removeActiveAdmin(deviceAdminSample) enableDeviceCapabilitiesArea(false) adminActive = false } } } else if (preference == disableCameraCheckbox) { dpm.setCameraDisabled(deviceAdminSample, value) } return true }
Ява
@Override public boolean onPreferenceChange(Preference preference, Object newValue) { if (super.onPreferenceChange(preference, newValue)) { return true; } boolean value = (Boolean) newValue; if (preference == enableCheckbox) { if (value != adminActive) { if (value) { // Launch the activity to have the user enable our admin. Intent intent = new Intent(DevicePolicyManager.ACTION_ADD_DEVICE_ADMIN); intent.putExtra(DevicePolicyManager.EXTRA_DEVICE_ADMIN, deviceAdminSample); intent.putExtra(DevicePolicyManager.EXTRA_ADD_EXPLANATION, activity.getString(R.string.add_admin_extra_app_text)); startActivityForResult(intent, REQUEST_CODE_ENABLE_ADMIN); // return false - don't update checkbox until we're really active return false; } else { dpm.removeActiveAdmin(deviceAdminSample); enableDeviceCapabilitiesArea(false); adminActive = false; } } } else if (preference == disableCameraCheckbox) { dpm.setCameraDisabled(deviceAdminSample, value); } return true; }
В строке intent.putExtra(DevicePolicyManager.EXTRA_DEVICE_ADMIN, mDeviceAdminSample)
указано, что mDeviceAdminSample
(который является компонентом DeviceAdminReceiver
) является целевой политикой. Эта строка вызывает пользовательский интерфейс, показанный на рисунке 2, который помогает пользователям добавить администратора устройства в систему (или позволяет им отклонить его).
Когда приложению необходимо выполнить операцию, которая зависит от включения приложения администратора устройства, оно подтверждает, что приложение активно. Для этого он использует метод DevicePolicyManager
isAdminActive()
. Обратите внимание, что метод DevicePolicyManager
isAdminActive()
принимает в качестве аргумента компонент DeviceAdminReceiver
:
Котлин
private lateinit var dpm: DevicePolicyManager ... private fun isActiveAdmin(): Boolean = dpm.isAdminActive(deviceAdminSample)
Ява
DevicePolicyManager dpm; ... private boolean isActiveAdmin() { return dpm.isAdminActive(deviceAdminSample); }
Управление политиками
DevicePolicyManager
— это общедоступный класс для управления политиками, применяемыми на устройстве. DevicePolicyManager
управляет политиками для одного или нескольких экземпляров DeviceAdminReceiver
.
Вы получаете дескриптор DevicePolicyManager
следующим образом:
Котлин
dpm = getSystemService(Context.DEVICE_POLICY_SERVICE) as DevicePolicyManager
Ява
DevicePolicyManager dpm = (DevicePolicyManager)getSystemService(Context.DEVICE_POLICY_SERVICE);
В этом разделе описывается, как использовать DevicePolicyManager
для выполнения административных задач:
Установите политику паролей
DevicePolicyManager
включает API для настройки и обеспечения соблюдения политики паролей устройств. В API администрирования устройств пароль применяется только к блокировке экрана. В этом разделе описаны общие задачи, связанные с паролями.
Установите пароль для устройства
Этот код отображает пользовательский интерфейс, предлагающий пользователю установить пароль:
Котлин
Intent(DevicePolicyManager.ACTION_SET_NEW_PASSWORD).also { intent -> startActivity(intent) }
Ява
Intent intent = new Intent(DevicePolicyManager.ACTION_SET_NEW_PASSWORD); startActivity(intent);
Установите качество пароля
Качество пароля может быть одной из следующих констант DevicePolicyManager
:
-
PASSWORD_QUALITY_ALPHABETIC
- Пользователь должен ввести пароль, содержащий как минимум буквы (или другие символы).
-
PASSWORD_QUALITY_ALPHANUMERIC
- Пользователь должен ввести пароль, содержащий как минимум цифровые и буквенные ( или другие символы) символы.
-
PASSWORD_QUALITY_NUMERIC
- Пользователь должен ввести пароль, содержащий как минимум числовые символы.
-
PASSWORD_QUALITY_COMPLEX
- Пользователь должен ввести пароль, содержащий как минимум букву, цифру и специальный символ.
-
PASSWORD_QUALITY_SOMETHING
- Политика требует какой-то пароль, но не важно, какой он.
-
PASSWORD_QUALITY_UNSPECIFIED
- Политика не имеет требований к паролю.
Например, вот как можно настроить политику паролей, требующую буквенно-цифровой пароль:
Котлин
private lateinit var dpm: DevicePolicyManager private lateinit var deviceAdminSample: ComponentName ... dpm.setPasswordQuality(deviceAdminSample, DevicePolicyManager.PASSWORD_QUALITY_ALPHANUMERIC)
Ява
DevicePolicyManager dpm; ComponentName deviceAdminSample; ... dpm.setPasswordQuality(deviceAdminSample, DevicePolicyManager.PASSWORD_QUALITY_ALPHANUMERIC);
Установите требования к содержанию пароля
Начиная с Android 3.0, класс DevicePolicyManager
включает методы, позволяющие точно настроить содержимое пароля. Например, вы можете установить политику, согласно которой пароли должны содержать как минимум n заглавных букв. Вот методы точной настройки содержимого пароля:
-
setPasswordMinimumLetters()
-
setPasswordMinimumLowerCase()
-
setPasswordMinimumUpperCase()
-
setPasswordMinimumNonLetter()
-
setPasswordMinimumNumeric()
-
setPasswordMinimumSymbols()
Например, в этом фрагменте указано, что пароль должен состоять как минимум из двух заглавных букв:
Котлин
private lateinit var dpm: DevicePolicyManager private lateinit var deviceAdminSample: ComponentName private val pwMinUppercase = 2 ... dpm.setPasswordMinimumUpperCase(deviceAdminSample, pwMinUppercase)
Ява
DevicePolicyManager dpm; ComponentName deviceAdminSample; int pwMinUppercase = 2; ... dpm.setPasswordMinimumUpperCase(deviceAdminSample, pwMinUppercase);
Установите минимальную длину пароля
Вы можете указать, что длина пароля должна быть не меньше указанной минимальной длины. Например:
Котлин
private lateinit var dpm: DevicePolicyManager private lateinit var deviceAdminSample: ComponentName private val pwLength: Int = ... ... dpm.setPasswordMinimumLength(deviceAdminSample, pwLength)
Ява
DevicePolicyManager dpm; ComponentName deviceAdminSample; int pwLength; ... dpm.setPasswordMinimumLength(deviceAdminSample, pwLength);
Установите максимальное количество неудачных попыток ввода пароля
Вы можете установить максимальное количество разрешенных неудачных попыток ввода пароля, прежде чем устройство будет очищено (то есть сбросится к заводским настройкам). Например:
Котлин
val dPM:DevicePolicyManager private lateinit var dpm: DevicePolicyManager private lateinit var deviceAdminSample: ComponentName private val maxFailedPw: Int = ... ... dpm.setMaximumFailedPasswordsForWipe(deviceAdminSample, maxFailedPw)
Ява
DevicePolicyManager dpm; ComponentName deviceAdminSample; int maxFailedPw; ... dpm.setMaximumFailedPasswordsForWipe(deviceAdminSample, maxFailedPw);
Установить таймаут истечения срока действия пароля
Начиная с Android 3.0, вы можете использовать метод setPasswordExpirationTimeout()
, чтобы установить срок действия пароля, выраженный в виде разницы в миллисекундах с момента, когда администратор устройства устанавливает время истечения срока действия. Например:
Котлин
private lateinit var dpm: DevicePolicyManager private lateinit var deviceAdminSample: ComponentName private val pwExpiration: Long = ... ... dpm.setPasswordExpirationTimeout(deviceAdminSample, pwExpiration)
Ява
DevicePolicyManager dpm; ComponentName deviceAdminSample; long pwExpiration; ... dpm.setPasswordExpirationTimeout(deviceAdminSample, pwExpiration);
Ограничить пароль на основе истории
Начиная с Android 3.0, вы можете использовать метод setPasswordHistoryLength()
чтобы ограничить возможность пользователей повторно использовать старые пароли. Этот метод принимает параметр длины , который указывает, сколько старых паролей хранится. Когда эта политика активна, пользователи не могут вводить новый пароль, соответствующий n последних паролям. Это не позволяет пользователям использовать один и тот же пароль снова и снова. Эта политика обычно используется вместе с setPasswordExpirationTimeout()
, которая заставляет пользователей обновлять свои пароли по истечении определенного периода времени.
Например, этот фрагмент запрещает пользователям повторно использовать любой из последних 5 паролей:
Котлин
private lateinit var dpm: DevicePolicyManager private lateinit var deviceAdminSample: ComponentName private val pwHistoryLength = 5 ... dpm.setPasswordHistoryLength(deviceAdminSample, pwHistoryLength)
Ява
DevicePolicyManager dpm; ComponentName deviceAdminSample; int pwHistoryLength = 5; ... dpm.setPasswordHistoryLength(deviceAdminSample, pwHistoryLength);
Установить блокировку устройства
Вы можете установить максимальный период бездействия пользователя, который может произойти до блокировки устройства. Например:
Котлин
private lateinit var dpm: DevicePolicyManager private lateinit var deviceAdminSample: ComponentName private val timeMs: Long = 1000L * timeout.text.toString().toLong() ... dpm.setMaximumTimeToLock(deviceAdminSample, timeMs)
Ява
DevicePolicyManager dpm; ComponentName deviceAdminSample; ... long timeMs = 1000L*Long.parseLong(timeout.getText().toString()); dpm.setMaximumTimeToLock(deviceAdminSample, timeMs);
Вы также можете программно указать устройству на немедленную блокировку:
Котлин
private lateinit var dpm: DevicePolicyManager dpm.lockNow()
Ява
DevicePolicyManager dpm; dpm.lockNow();
Выполнить очистку данных
Вы можете использовать метод wipeData()
DevicePolicyManager
для сброса устройства к заводским настройкам. Это полезно, если устройство потеряно или украдено. Часто решение об очистке устройства является результатом выполнения определенных условий. Например, вы можете использовать setMaximumFailedPasswordsForWipe()
чтобы указать, что данные с устройства должны быть очищены после определенного количества неудачных попыток ввода пароля.
Вы стираете данные следующим образом:
Котлин
private lateinit var dpm: DevicePolicyManager dpm.wipeData(0)
Ява
DevicePolicyManager dpm; dpm.wipeData(0);
Метод wipeData()
принимает в качестве параметра битовую маску дополнительных опций. В настоящее время значение должно быть 0.
Отключить камеру
Начиная с Android 4.0, вы можете отключить камеру. Обратите внимание, что это не обязательно должно быть постоянное отключение. Камеру можно включать/отключать динамически в зависимости от контекста, времени и т. д.
Вы контролируете, отключена ли камера, с помощью метода setCameraDisabled()
. Например, этот фрагмент позволяет включить или отключить камеру в зависимости от установки флажка:
Котлин
private lateinit var disableCameraCheckbox: CheckBoxPreference private lateinit var dpm: DevicePolicyManager private lateinit var deviceAdminSample: ComponentName ... dpm.setCameraDisabled(deviceAdminSample, mDisableCameraCheckbox.isChecked)
Ява
private CheckBoxPreference disableCameraCheckbox; DevicePolicyManager dpm; ComponentName deviceAdminSample; ... dpm.setCameraDisabled(deviceAdminSample, mDisableCameraCheckbox.isChecked());
Шифрование хранилища
Начиная с Android 3.0, вы можете использовать метод setStorageEncryption()
чтобы установить политику, требующую шифрования области хранения, если это поддерживается.
Например:
Котлин
private lateinit var dpm: DevicePolicyManager private lateinit var deviceAdminSample: ComponentName ... dpm.setStorageEncryption(deviceAdminSample, true)
Ява
DevicePolicyManager dpm; ComponentName deviceAdminSample; ... dpm.setStorageEncryption(deviceAdminSample, true);
Полный пример включения шифрования хранилища см. в примере API администрирования устройств.
Дополнительные примеры кода
Примеры Android AppRestrictionEnforcer и DeviceOwner дополнительно демонстрируют использование API, описанных на этой странице.