Обзор администрирования устройства

Устаревание административной политики устройства . Начиная с Android 9 (уровень API 28), некоторые административные политики будут помечаться как устаревшие при вызове администратором устройства. Мы рекомендуем начать подготовку к этому изменению уже сейчас. Чтобы узнать больше и ознакомиться с вариантами миграции, прочитайте статью «Устаревание административной политики устройства» .

Android включает поддержку корпоративных приложений, предлагая API администрирования устройств Android. API администрирования устройств предоставляет функции управления устройствами на системном уровне. Эти API позволяют создавать приложения с учетом требований безопасности, полезные в корпоративной среде, где ИТ-специалистам требуется расширенный контроль над устройствами сотрудников. Например, встроенное приложение электронной почты Android использует эти API для улучшения поддержки Exchange. Через приложение электронной почты администраторы Exchange могут применять политики паролей — включая буквенно-цифровые пароли или цифровые PIN-коды — ко всем устройствам. Администраторы также могут удаленно стирать (то есть восстанавливать заводские настройки) потерянные или украденные телефоны. Пользователи Exchange могут синхронизировать свои данные электронной почты и календаря.

Этот документ предназначен для разработчиков, желающих создавать корпоративные решения для устройств на базе Android. В нем рассматриваются различные функции, предоставляемые API администрирования устройств, для обеспечения более надежной безопасности устройств сотрудников, работающих под управлением Android.

Примечание. Информацию о создании контроллера политик для развертывания Android for Work см. в разделе «Создание контроллера политик устройств» .

Режим владельца устройства без монитора

В Android 14 (уровень API 34) представлен режим Headless System User (устройства, для которых UserManager.isHeadlessSystemUserMode возвращает true ). В режиме Headless System User системный пользователь является фоновым пользователем и полагается на дополнительных пользователей переднего плана для взаимодействия с конечным пользователем. Android 14 также представляет режим Headless Device Owner Affiliated Mode , который добавляет владельца профиля ко всем связанным пользователям, кроме системного пользователя, для которого установлен владелец устройства.

На устройствах, настроенных с использованием системного пользователя без графического интерфейса (когда системный пользователь работает в фоновом режиме), к пользователю или пользователям, работающим в фоновом режиме, применяются только политики устройства, имеющие глобальный охват (политики, применимые ко всем пользователям). Подробности см. в addUserRestriction .

Примечание: В Android 14 (уровень API 34) приложение DPC может быть установлено в качестве владельца устройства на устройстве, настроенном как устройство в режиме Headless System User Mode, только если оно поддерживает режим аффилированного доступа. Подробнее см. HEADLESS_DEVICE_OWNER_MODE_AFFILIATED .

Производители устройств на базе Android могут обратиться к рекомендациям , опубликованным на сайте source.android.com.

Обзор API администрирования устройств

Вот примеры типов приложений, которые могут использовать API администрирования устройств:

• Почтовые клиенты.
• Приложения для обеспечения безопасности, позволяющие удаленно стирать данные.
• Сервисы и приложения для управления устройствами.

Как это работает?

Вы используете API администрирования устройств для написания приложений администрирования устройств, которые пользователи устанавливают на свои устройства. Приложение администрирования устройств обеспечивает соблюдение необходимых политик. Вот как это работает:

• Системный администратор разрабатывает приложение для администрирования устройств, которое обеспечивает соблюдение политик безопасности удаленных/локальных устройств. Эти политики могут быть жестко закодированы в приложении, или же приложение может динамически получать политики с сервера стороннего разработчика.
• Приложение устанавливается на устройства пользователей. В настоящее время в Android нет автоматического решения для развертывания. Системный администратор может распространить приложение среди пользователей следующими способами:
  • Google Play.
  • Включение возможности установки из другого магазина.
  • Распространение приложения другими способами, такими как электронная почта или веб-сайты.
• Система предлагает пользователю включить приложение администратора устройства. Способ и время включения зависят от реализации приложения.
• После активации приложения для администрирования устройства пользователи подчиняются его правилам. Соблюдение этих правил обычно предоставляет преимущества, такие как доступ к конфиденциальным системам и данным.

Если пользователи не активируют приложение для администрирования устройства, оно останется на устройстве, но в неактивном состоянии. На пользователей не будут распространяться его правила, и, соответственно, они не получат никаких преимуществ приложения — например, они могут не иметь возможности синхронизировать данные.

Если пользователь не соблюдает правила (например, устанавливает пароль, нарушающий рекомендации), решение о дальнейших действиях принимает приложение. Однако, как правило, это приводит к невозможности синхронизации данных.

Если устройство попытается подключиться к серверу, требующему политик, не поддерживаемых в API администрирования устройств, подключение будет запрещено. В настоящее время API администрирования устройств не позволяет осуществлять частичную настройку. Другими словами, если устройство (например, устаревшее устройство) не поддерживает все указанные политики, нет способа разрешить ему подключение.

Если на устройстве включено несколько административных приложений, применяется самая строгая политика. Выбрать конкретное административное приложение невозможно.

Для удаления существующего приложения администратора устройства пользователям необходимо сначала отменить регистрацию приложения в качестве администратора.

Политики

В корпоративной среде часто бывает так, что устройства сотрудников должны соответствовать строгому набору правил, регулирующих их использование. API администрирования устройств поддерживает правила, перечисленные в таблице 1. Обратите внимание, что в настоящее время 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 паролей, которые они использовали ранее.
• Укажите, что область хранения должна быть зашифрована, если устройство это поддерживает.
• Установите максимальное время бездействия, которое может пройти до блокировки устройства.
• Необходимо немедленно заблокировать устройство.
• Удалите все данные с устройства (то есть восстановите заводские настройки).
• Отключите камеру.

Рисунок 1. Скриншот демонстрационного приложения.

Разработка приложения для администрирования устройств.

Системные администраторы могут использовать 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

Базовый класс для реализации компонента администрирования устройства. Этот класс обеспечивает удобство интерпретации исходных действий Intent, отправляемых системой. Ваше приложение для администрирования устройств должно включать подкласс 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))
...
}

Java

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.

Рисунок 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
}

Java

@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, который помогает пользователям добавить администратора устройства в систему (или позволяет им отклонить его).

Когда приложению необходимо выполнить операцию, зависящую от того, включено ли приложение администратора устройства, оно подтверждает, что приложение активно. Для этого оно использует метод isAdminActive() DevicePolicyManager . Обратите внимание, что метод isAdminActive() DevicePolicyManager принимает в качестве аргумента компонент DeviceAdminReceiver :

Котлин

private lateinit var dpm: DevicePolicyManager
...
private fun isActiveAdmin(): Boolean = dpm.isAdminActive(deviceAdminSample)

Java

DevicePolicyManager dpm;
...
private boolean isActiveAdmin() {
    return dpm.isAdminActive(deviceAdminSample);
}

Управление политиками

DevicePolicyManager — это публичный класс для управления политиками, применяемыми к устройству. DevicePolicyManager управляет политиками для одного или нескольких экземпляров DeviceAdminReceiver .

Вы получаете доступ к DevicePolicyManager следующим образом:

Котлин

dpm = getSystemService(Context.DEVICE_POLICY_SERVICE) as DevicePolicyManager

Java

DevicePolicyManager dpm =
    (DevicePolicyManager)getSystemService(Context.DEVICE_POLICY_SERVICE);

В этом разделе описывается, как использовать DevicePolicyManager для выполнения административных задач:

• Настройка политик паролей
• Установить блокировку устройства
• Выполнить очистку данных

Настройка политик паролей

DevicePolicyManager включает API для установки и обеспечения соблюдения политики паролей устройства. В API администрирования устройства пароль применяется только к блокировке экрана. В этом разделе описаны распространенные задачи, связанные с паролями.

Установите пароль для устройства.

Этот код отображает пользовательский интерфейс, предлагая пользователю установить пароль:

Котлин

Intent(DevicePolicyManager.ACTION_SET_NEW_PASSWORD).also { intent ->
    startActivity(intent)
}

Java

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)

Java

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)

Java

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)

Java

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)

Java

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)

Java

DevicePolicyManager dpm;
ComponentName deviceAdminSample;
long pwExpiration;
...
dpm.setPasswordExpirationTimeout(deviceAdminSample, pwExpiration);

Ограничение доступа к паролям на основе истории.

Начиная с Android 3.0, вы можете использовать метод setPasswordHistoryLength() для ограничения возможности пользователей повторно использовать старые пароли. Этот метод принимает параметр length , который указывает, сколько старых паролей хранится. Когда эта политика активна, пользователи не могут ввести новый пароль, совпадающий с последними n паролями. Это предотвращает многократное использование одного и того же пароля. Эта политика обычно используется в сочетании с setPasswordExpirationTimeout() , который заставляет пользователей обновлять свои пароли по истечении определенного времени.

Например, этот фрагмент кода запрещает пользователям повторно использовать любой из своих последних 5 паролей:

Котлин

private lateinit var dpm: DevicePolicyManager
private lateinit var deviceAdminSample: ComponentName
private val pwHistoryLength = 5
...
dpm.setPasswordHistoryLength(deviceAdminSample, pwHistoryLength)

Java

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)

Java

DevicePolicyManager dpm;
ComponentName deviceAdminSample;
...
long timeMs = 1000L*Long.parseLong(timeout.getText().toString());
dpm.setMaximumTimeToLock(deviceAdminSample, timeMs);

Также можно программно дать указание устройству немедленно заблокироваться:

Котлин

private lateinit var dpm: DevicePolicyManager
dpm.lockNow()

Java

DevicePolicyManager dpm;
dpm.lockNow();

Выполнить очистку данных

Для сброса устройства до заводских настроек можно использовать метод wipeData() DevicePolicyManager . Это полезно, если устройство потеряно или украдено. Часто решение о сбросе данных с устройства принимается на основании выполнения определенных условий. Например, можно использовать setMaximumFailedPasswordsForWipe() чтобы указать, что данные с устройства должны быть сброшены после определенного количества неудачных попыток ввода пароля.

Удаление данных осуществляется следующим образом:

Котлин

private lateinit var dpm: DevicePolicyManager
dpm.wipeData(0)

Java

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)

Java

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)

Java

DevicePolicyManager dpm;
ComponentName deviceAdminSample;
...
dpm.setStorageEncryption(deviceAdminSample, true);

Полный пример включения шифрования хранилища см. в примере API администрирования устройств.

Дополнительные примеры кода

Примеры Android AppRestrictionEnforcer и DeviceOwner дополнительно демонстрируют использование API, описанных на этой странице.