Что нового для предприятий в Android 10

На этой странице представлен обзор новых корпоративных API, функций и изменений поведения, представленных в Android 10.

Рабочие профили для корпоративных устройств

В Android 10 представлены новые функции подготовки и аттестации для корпоративных устройств, для которых требуется только рабочий профиль.

Улучшенные инструменты подготовки для рабочих профилей.

Вы можете предоставить рабочие профили на устройствах Android 10 и более поздних версий, зарегистрированных с помощью QR-кода или Zero Touch . Во время подготовки устройства, принадлежащего компании, новая дополнительная функция позволяет приложениям контроллера политики устройства (DPC) инициировать рабочий профиль или полностью управляемую настройку. После создания рабочего профиля или установления полного управления центры обработки данных должны запустить экраны соответствия политике, чтобы обеспечить соблюдение любых первоначальных политик.

В файле манифеста вашего DPC объявите новый фильтр намерений для GET_PROVISIONING_MODE в действии и добавьте разрешение BIND_DEVICE_ADMIN , чтобы предотвратить запуск действия произвольными приложениями. Например:

<activity
    android:name=".GetProvisioningModeActivity"
    android:label="@string/app_name"
    android:permission="android.permission.BIND_DEVICE_ADMIN">
    <intent-filter>
        <action
            android:name="android.app.action.GET_PROVISIONING_MODE" />
        <category android:name="android.intent.category.DEFAULT"/>
    </intent-filter>
</activity>

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

Может оказаться полезным получить дополнительные сведения об обеспечении перед определением соответствующего режима управления для устройства. Действие может вызвать getIntent() для получения следующего:

ЦОД также могут создать новое намерение результата и добавить к нему следующие дополнения:

  • EXTRA_PROVISIONING_ADMIN_EXTRAS_BUNDLE : добавить к существующему пакету или создать новый пакет. Этот пакет отправляется как дополнительное намерение, когда ваш ЦОД запускает экраны соответствия политике.
  • EXTRA_PROVISIONING_ACCOUNT_TO_MIGRATE : указывайте учетную запись для переноса только в случае добавления рабочей учетной записи в рамках подготовки рабочего профиля.
  • EXTRA_PROVISIONING_SKIP_EDUCATION_SCREENS

Чтобы установить режим управления на устройстве, вызовите putExtra(DevicePolicyManager.EXTRA_PROVISIONING_MODE,desiredProvisioningMode) , где desiredProvisioningMode :

  • Рабочий профиль: PROVISIONING_MODE_MANAGED_PROFILE
  • Полностью управляемый: PROVISIONING_MODE_FULLY_MANAGED_DEVICE

Завершите рабочий профиль или полностью управляемую подготовку, отправив сведения о подготовке обратно в настройку через setResult(RESULT_OK, Intent) и закройте все активные экраны с помощью finish() .

После завершения подготовки ЦОД становится доступен новый Intent для запуска экранов соответствия и применения начальных настроек политики. На устройствах с рабочим профилем в рабочем профиле отображаются экраны соответствия. Ваш ЦОД должен гарантировать, что его экраны соответствия отображаются пользователям, даже если пользователь выходит из процесса настройки.

В файле манифеста вашего DPC объявите новый фильтр намерений для ADMIN_POLICY_COMPLIANCE в действии и добавьте разрешение BIND_DEVICE_ADMIN , чтобы предотвратить запуск действия произвольными приложениями. Например:

<activity
    android:name=".PolicyComplianceActivity"
    android:label="@string/app_name"
    android:permission="android.permission.BIND_DEVICE_ADMIN">
    <intent-filter>
        <action android:name="android.app.action.ADMIN_POLICY_COMPLIANCE" />
        <category android:name="android.intent.category.DEFAULT"/>
    </intent-filter>
</activity>

Ваш ЦОД должен использовать это новое намерение вместо прослушивания трансляции ACTION_PROFILE_PROVISIONING_COMPLETE .

Действие, связанное с фильтром намерений, может вызвать getIntent() для получения EXTRA_PROVISIONING_ADMIN_EXTRAS_BUNDLE . После выполнения политики соответствия ADMIN_POLICY_COMPLIANCE должен вернуть setResult(RESULT_OK, Intent) и закрыть все активные экраны с помощью finish() .

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

Аттестация идентификатора устройства рабочего профиля

Центры обработки данных, настроенные в качестве администраторов рабочего профиля, подготовленного с использованием автоматической регистрации, могут получать идентификаторы устройств, проверенные безопасным оборудованием, такие как IMEI или серийный номер производителя. Устройство должно включать защищенное оборудование (например, доверенную среду выполнения (TEE) или элемент безопасности (SE)) и поддерживать аттестацию идентификатора устройства и автоматическую регистрацию.

Административный компонент рабочего профиля может вызвать DevicePolicyManager.generateKeyPair() , передав один или несколько ID_TYPE_SERIAL , ID_TYPE_IMEI или ID_TYPE_MEID в качестве аргумента idAttestationFlags .

Дополнительные сведения об извлечении и проверке идентификаторов устройств см. в разделе Проверка пар аппаратных ключей с помощью Key Attestation .

Улучшения рабочего профиля

Доступны новые API для поддержки видимости календаря между профилями и блокировки установки приложений из неизвестных источников на всем устройстве.

Рабочий профиль, неизвестные источники на уровне устройства

Приложения, загруженные из источников, отличных от Google Play (или других надежных магазинов приложений), называются приложениями из неизвестных источников. В Android 10 администраторы рабочих профилей могут запретить любому пользователю или профилю устанавливать приложения из неизвестных источников в любом месте устройства, добавив новое пользовательское ограничение DISALLOW_INSTALL_UNKNOWN_SOURCES_GLOBALLY . Однако после добавления этого ограничения человек, использующий устройство, по-прежнему сможет устанавливать приложения с помощью adb .

Чтобы пользователи не могли по ошибке устанавливать приложения из неизвестных источников, мы рекомендуем добавить это пользовательское ограничение, поскольку оно не требует установки сервисов Google Play. Если вы хотите поддерживать более старые версии Android, вы можете установить значение управляемой конфигурации для Google Play .

Ограничить разрешенные устройства ввода рабочими профилями

Когда администраторы рабочих профилей вызывают DevicePolicyManager.setPermittedInputMethods() , пользователи ограничиваются только разрешенными методами ввода внутри своего рабочего профиля, а не всего устройства, что дает пользователям полный контроль над методами ввода на личной стороне своего устройства.

Тихое удаление рабочих профилей

Добавлен флаг WIPE_SILENTLY в DevicePolicyManager.wipeData() . Если флаг установлен, пользователи не будут уведомлены после очистки их рабочего профиля с помощью wipeData() .

Новые функции для полностью управляемых устройств

Android 10 представляет новые функции и API для полностью управляемых устройств, включая ручное обновление системы, расширение QR-кода и подготовку NFC для включения учетных данных для сети EAP Wi-Fi, а также поддержку DNS через TLS.

Ручная установка обновления системы

В Android 10 администраторы полностью управляемых устройств могут устанавливать обновления системы через файл обновления системы. Обновления системы вручную позволяют ИТ-администраторам делать следующее:

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

Сначала ИТ-администратор устанавливает политику отложенного обновления системы, чтобы отложить автоматическую установку (при необходимости). Затем ЦОД устройства вызывает installSystemUpdate() сообщая путь к файлу обновления системы производителя устройства. Передайте объект InstallSystemUpdateCallback , который система может использовать для сообщения об ошибках, возникающих до перезагрузки устройства. Если что-то пойдет не так, система вызывает onInstallUpdateError() с кодом ошибки.

После перезагрузки устройства вашему ЦОД необходимо подтвердить успешную установку с помощью API версии, например Build.FINGERPRINT . Если обновление не удалось, сообщите об этом ИТ-администратору.

Предоставление EAP Wi-Fi

В Android 10 QR-коды и данные NFC, используемые для подготовки устройства, могут содержать конфигурацию и учетные данные EAP, включая сертификаты. Когда человек сканирует QR-код или прикасается к метке NFC, устройство автоматически проходит аутентификацию в локальной сети Wi-Fi с использованием EAP и запускает процесс подготовки без какого-либо дополнительного ручного ввода.

Чтобы аутентифицировать Wi-Fi с помощью EAP, добавьте дополнительный EXTRA_PROVISIONING_WIFI_SECURITY_TYPE со значением "EAP" . Чтобы указать аутентификацию EAP, вы можете добавить к своему намерению следующие дополнительные возможности подготовки:

Поддержка частного DNS

Организации могут использовать DNS через TLS (так называемый частный DNS на устройствах Android), чтобы избежать утечки DNS-запросов, в том числе внутренних имен хостов. Компоненты администрирования полностью управляемых устройств могут управлять настройками частного DNS устройства. Чтобы установить режим Private DNS, позвоните:

  • setGlobalPrivateDnsModeOpportunistic() , чтобы устройство использовало частный DNS, когда система может обнаружить поддерживающий сервер имен, или
  • setGlobalPrivateDnsModeSpecifiedHost() , чтобы указать имя хоста сервера имен, который поддерживает RFC7858, в аргументе privateDnsHost .

Когда ваш ЦОД вызывает любой из этих методов, система возвращает PRIVATE_DNS_SET_NO_ERROR если вызов был успешным. В противном случае он возвращает ошибку.

Чтобы получить режим частного DNS и набор хостов на устройстве, вызовите getGlobalPrivateDnsMode() и getGlobalPrivateDnsHost() . Вы можете запретить пользователям изменять настройки частного DNS, добавив пользовательское ограничение DISALLOW_CONFIG_PRIVATE_DNS .

Исключение режима блокировки VPN

Режим блокировки VPN позволяет ЦОД блокировать любой сетевой трафик , который не использует VPN. Администраторы полностью управляемых устройств и рабочих профилей могут выводить приложения из режима блокировки. Исключенные приложения по умолчанию используют VPN, но автоматически подключаются к другим сетям, если VPN недоступна. Исключенные приложения, которым также явно запрещен доступ к VPN, будут использовать только другие сети.

Чтобы вывести приложение из режима блокировки, вызовите новый метод DevicePolicyManager setAlwaysOnVpnPackage() , который принимает список исключенных пакетов приложений. Любые пакеты приложений, добавляемые DPC, должны быть установлены на устройстве при вызове метода. Если приложение было удалено и переустановлено, оно должно быть освобождено снова. Чтобы получить приложения, ранее освобожденные от режима блокировки, вызовите getAlwaysOnVpnLockdownWhitelist() .

Чтобы администраторы полностью управляемых устройств и рабочих профилей могли получить статус режима блокировки, в Android 10 добавлен метод isAlwaysOnVpnLockdownEnabled() .

Новые области делегирования

Android 10 расширяет список функций, которые ЦОД может делегировать другим, более специализированным приложениям. Android группирует методы API, необходимые для задачи, в области . Чтобы делегировать область, вызовите setDelegatedScopes() и передайте одну или несколько из следующих областей:

В Android 10 представлен новый класс DelegatedAdminReceiver для приложений делегатов. Система использует этот широковещательный приемник для отправки обратных вызовов, подобных DPC, для делегирования приложений. Приложения, которым делегировано ведение журнала сетевой активности и выбор сертификата, должны реализовать этот класс. Чтобы добавить этот компонент в приложение делегата, выполните следующие действия:

  1. Добавьте подкласс DelegatedAdminReceiver в приложение делегата.
  2. Объявите <receiver> в манифесте приложения, добавив действие фильтра намерений для каждого обратного вызова. Например, ACTION_NETWORK_LOGS_AVAILABLE или ACTION_CHOOSE_PRIVATE_KEY_ALIAS .
  3. Защитите приемник вещания с помощью разрешения BIND_DEVICE_ADMIN .

В следующем фрагменте показан манифест одного приложения-делегата, которое обрабатывает как ведение журнала сети, так и выбор сертификата:

<receiver android:name=".app.DelegatedAdminReceiver"
        android:permission="android.permission.BIND_DELEGATED_ADMIN">
    <intent-filter>
        <action android:name="android.app.admin.action.NETWORK_LOGS_AVAILABLE">
        <action android:name="android.app.action.CHOOSE_PRIVATE_KEY_ALIAS">
    </intent-filter>
    </receiver>

Ведение журнала сетевой активности

Чтобы помочь организациям обнаруживать и отслеживать вредоносное ПО, центры обработки данных могут регистрировать TCP-соединения и запросы DNS в системе. В Android 10 администраторы полностью управляемых устройств могут делегировать ведение журнала сети специализированному приложению.

Чтобы получить сетевые журналы после того, как система сделает пакет доступным, приложения-делегаты должны сначала создать подкласс DelegatedAdminReceiver (описанный ранее). В своем подклассе реализуйте обратный вызов onNetworkLogsAvailable() , следуя инструкциям в разделе Получение журналов .

Приложения-делегаты могут вызывать следующие методы DevicePolicyManager (передавая в качестве аргумента admin null ):

Чтобы избежать потери журналов, ЦОДам не следует включать ведение журнала сети , если вы планируете делегировать их другому приложению. Приложение-делегат должно включить и собирать сетевые журналы. После того как центр обработки данных делегирует ведение журнала сети, он больше не будет получать обратные вызовы onNetworkLogsAvailable() .

Чтобы узнать, как сообщить о регистрации сетевой активности из приложения-делегата, прочтите руководство разработчика «Журнал сетевой активности» .

Выбор сертификата

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

Чтобы выбрать псевдоним сертификата, приложения-делегаты должны сначала создать подкласс DelegatedAdminReceiver (описанный ранее). В своем подклассе реализуйте обратный вызов onChoosePrivateKeyAlias() и верните псевдоним для предпочтительного сертификата или, чтобы предложить пользователю выбрать сертификат, верните null .

Устаревшие политики администратора устройства

Android 10 не позволяет приложениям и ЦОД применять устаревшие политики администрирования устройств . Мы рекомендуем клиентам и партнерам перейти на полностью управляемые устройства или рабочие профили. Следующие политики создают исключение SecurityException при вызове администратором устройства, ориентированного на Android 10:

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

Дополнительные сведения об этих изменениях см. в статье Прекращение поддержки администратора устройства .

Новые возможности для приложений

Приложения, ориентированные на Android 10, могут запрашивать сложность блокировки экрана, установленную на устройстве, прежде чем отображать конфиденциальные данные или запускать важные функции. Приложения, вызывающие API KeyChain получают преимущества от улучшения поведения, а для VPN-приложений также доступны новые функции.

Проверка качества блокировки экрана

Начиная с Android 10, приложения с важными функциями, требующими блокировки экрана, могут запрашивать сложность блокировки экрана устройства или рабочего профиля. Приложения, которым требуется более надежная блокировка экрана, могут направить пользователя к настройкам блокировки экрана системы, что позволит ему обновить настройки безопасности.

Чтобы проверить качество блокировки экрана:

Чтобы запустить настройки блокировки экрана системы, используйте ACTION_SET_NEW_PASSWORD с дополнительным EXTRA_PASSWORD_COMPLEXITY — параметры, которые не соответствуют сложности, указанной в дополнительном намерении, выделены серым цветом. Пользователи могут выбрать один из доступных вариантов блокировки экрана или выйти из экрана.

Рекомендация: отображайте сообщение в приложении перед запуском страницы блокировки экрана системы. Когда работа приложения возобновится, снова вызовите DevicePolicyManager.getPasswordComplexity() . Если по-прежнему требуется более надежная блокировка экрана, ограничьте доступ, а не постоянно предложите пользователям обновить свои настройки безопасности.

Поддержка HTTP-прокси в приложениях VPN

В Android 10 приложения VPN могут устанавливать HTTP-прокси для своего VPN-соединения. Чтобы добавить HTTP-прокси, VPN-приложение должно настроить экземпляр ProxyInfo с хостом и портом перед вызовом VpnService.Builder.setHttpProxy() . Система и многие сетевые библиотеки используют этот параметр прокси, но система не заставляет приложения проксировать HTTP-запросы.

Пример кода, показывающий, как настроить HTTP-прокси, см. в примере приложения ToyVPN .

Режимы обслуживания VPN

Приложения VPN могут определить, работает ли служба из -за постоянного подключения VPN и активен ли режим блокировки . Новые методы, добавленные в Android 10, помогут вам настроить пользовательский интерфейс. Например, вы можете отключить кнопку отключения, когда постоянный VPN контролирует жизненный цикл вашей службы.

Приложения VPN могут вызывать следующие методы VpnService после подключения к службе и установления локального интерфейса:

  • isAlwaysOn() чтобы узнать, запустила ли система службу из-за постоянно включенного VPN.
  • isLockdownEnabled() , чтобы узнать, блокирует ли система соединения, не использующие VPN.

Статус «всегда включен» остается неизменным во время работы службы, но статус режима блокировки может измениться.

Улучшения связки ключей

В Android 10 представлено несколько улучшений, связанных с API KeyChain .

Когда приложение вызывает KeyChain.choosePrivateKeyAlias() , устройства Android 10 и более поздних версий фильтруют список сертификатов, которые пользователь может выбрать, на основе эмитентов и ключевых алгоритмов, указанных в вызове.

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

Кроме того, KeyChain больше не требует, чтобы на устройстве была блокировка экрана, прежде чем можно будет импортировать ключи или сертификаты CA.