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

Прекращение поддержки администратора устройства . Начиная с 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 14 (уровень API 34) приложение DPC можно установить в качестве владельца устройства на устройстве, настроенном как устройство с режимом пользователя безголовой системы, только если оно поддерживает партнерский режим. Подробности см. в разделе HEADLESS_DEVICE_OWNER_MODE_AFFILIATED .

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

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

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

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

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

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

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

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

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

Если устройство попытается подключиться к серверу, которому требуются политики, не поддерживаемые в 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

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

Рисунок 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, описанных на этой странице.