Как разработка пользовательского приложения Android DPC связана с API управления Android?

Я новичок в мире корпоративной разработки Android, и у меня есть некоторое представление о том, как разные части в корпоративной экосистеме Android связаны друг с другом. Позволь мне объяснить.

Решение, которое я пытаюсь найти, - это возможность заблокировать устройство в режиме киоска как удаленно, так и на основе бизнес-логики, даже если пользователь находится в автономном режиме. Я начал исследовать EMM и особенно API управления Android, чтобы решить эту проблему. Я смог удаленно заблокировать устройство в режиме киоска с помощью API. Шаги, которые я предпринимаю, следующие

  1. Сброс настроек устройства Android
  2. Добраться до экрана, где пользователю необходимо ввести свои учетные данные
  3. Вместо реальных учетных данных я ввожу afw#setup
  4. Устройство переходит в режим рабочего профиля и устанавливается политика устройства Android
  5. Я создаю токен регистрации в API управления (шаги для этого описаны в кратком руководстве
  6. Я генерирую QR-код и сканирую его, используя устройство сброса к заводским настройкам, как только мне предлагают
  7. Устройство будет связано с предприятием, и я успешно смогу управлять им и перевести устройство в режим киоска, создав специальную политику режима киоска и исправив устройство, чтобы оно соответствовало этой политике, используя комбинацию политики исправлений (для создания политика) и API-интерфейсы исправления устройства.

Следующим шагом было выяснение способа блокировки устройства в режиме киоска, даже когда пользователь находится в автономном режиме. Я предполагаю, что это произойдет, создав приложение корпоративного пользовательского DPC (контроллер политики устройства) для Android. Я предположил, что, прочитав следующую документацию, где одним из 3 способов предоставления "одноцелевых" устройств является создание собственного приложения DPC. Вот еще одна цитата из другого URL

Как EMM, вы разрабатываете приложение DPC, которое может использоваться вашими клиентами в сочетании с консолью и сервером EMM. Ваш клиент развертывает DPC на пользовательских устройствах, которыми он управляет. DPC действует как мост между вашей консолью EMM (и сервером) и устройством. Администратор использует консоль EMM для выполнения ряда задач, включая настройку параметров устройства и приложений.

И вот здесь возникают все мои заблуждения. Естественно, возникает первый вопрос - был ли автор предыдущей цитаты, ссылающийся на API управления EMM, когда говорил о консоли и сервере EMM?

Кроме того, есть еще вопросы, на которые я не смог найти ответ

В руководстве по созданию настраиваемого DPC нет упоминания о том, какую роль будет играть EMM API в настраиваемом DPC, и, следовательно, нет места, где я мог бы найти описание того, как именно настраиваемый DPC является мостом между консолью EMM (предположительно, EMM API). а устройство?

Тогда давайте предположим, что я разработал собственное приложение DPC и загрузил его в альфа-канал Google Play. В документации говорится, что во время процесса установки вместо ввода afw#setup мне нужно ввести afw#DPC_NAME, и я не знаю, как сгенерировать это имя? Это идентификатор пакета приложения DPC? Или, может быть, он установлен где-то в настройках Google? Например, Google разработал приложение TestDPC для тестирования корпоративных решений, и я смог пройти описанные выше шаги и ввести afw#testdpc, успешно отсканировать QR-код в файле git readme, и я увидел, что TestDPC установлен и устройство было запущено в режиме рабочего профиля. Итак, я предполагаю, что каким-то образом мне нужно зарегистрировать свой собственный "testdpc" и ввести вместо него afw#my_dpc.

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

Спасибо за ваши ответы

ОБНОВЛЕНИЕ 1:

Сегодня я нашел способ превратить пользовательский DPC в владельца устройства без прохождения NFC или другого процесса подготовки. Это особенно полезно для целей разработки. Перейдите по этой ссылке для получения инструкций. Это экономит много времени, и, в моем случае, мы все еще ждем одобрения Google, но, наконец, мы можем начать тестировать некоторые вещи без необходимости процесса пользовательской инициализации.

Источник

1 ответ

Решение

Существует два различных способа управления устройствами Android:

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

Старый способ: использование пользовательских DPC. Для этого вам необходимо:

В документации вы - разработчик, использующий эти API - называетесь "EMM". "Сервер EMM" означает сервер, которым вы владеете и который вызывает эти API, а "консоль EMM" относится к консоли пользовательского интерфейса, которую вы предоставляете своим ИТ-администраторам, если таковые имеются.

Источник

https://developer.android.com/work/dpc/build-dpc

Внимание! Android Enterprise больше не принимает новые регистрации для настраиваемых контроллеров политик устройств (DPC). Учить больше.

Привет @Fred!

Я нашел эту информацию выше по указанному пути. У меня есть несколько вопросов по поводу вышеупомянутого разговора.

  1. Если мы используем API управления Android для разработки EMM, нам не нужно внедрять приложение Custom DPC?

  2. Можем ли мы зарегистрировать учетную запись в сообществе EMM с помощью приложения Custom DPC?

  3. Можно ли использовать пользовательское приложение DPC с API управления Android?

Источник
Другие вопросы по тегам