Перенесите существующие устройства на AMAPI

Устройства, которые уже управляются вашим пользовательским DPC, можно перенести в Android Device Policy (ADP) и воспользоваться преимуществами API управления Android.

Примечание: Этот процесс прозрачен для конечных пользователей. Это односторонний процесс (его нельзя отменить после завершения), и его нельзя использовать для миграции устройства из одного EMM в другой или из одного предприятия в другое.

Предпосылки

• Устройство уже управляется вашим EMM с помощью настраиваемого DPC.
• Ваш пользовательский DPC интегрирован с AMAPI SDK .
• Устройство зарегистрировано в Google Play EMM API .
• Устройство принадлежит предприятию с управляемыми аккаунтами Google Play .
• Устройство работает под управлением Android 9 или более поздней версии.
• В случае рабочих профилей на корпоративных устройствах устройство должно работать под управлением Android 11 или более поздней версии.

Важно: Для этого процесса требуется версия 1.1.4+ библиотеки AMAPI SDK. Вы можете найти последнюю доступную версию в примечаниях к выпуску библиотеки AMAPI SDK . Мы настоятельно рекомендуем всегда использовать последнюю версию библиотеки, чтобы воспользоваться доступными исправлениями ошибок и улучшениями.

Интеграция с AMAPI SDK в вашем пользовательском ЦОД

Процесс миграции требует, чтобы пользовательское приложение DPC интегрировало AMAPI SDK. Вы можете найти больше информации об этой библиотеке и о том, как добавить ее в свое приложение, в руководстве по интеграции AMAPI SDK .

Действия по миграции устройства

1. Настройте политику , которая будет использоваться устройством после его миграции в AMAPI. Для лучшего пользовательского опыта она должна быть эквивалентна политике, уже примененной на устройстве вашим DPC. Политика в AMAPI должна принадлежать тому же предприятию, к которому уже принадлежит устройство в API Play EMM. Обратите внимание, что данное предприятие имеет одинаковое имя как в AMAPI, так и в API Play EMM.
2. Создайте токен миграции для устройства, вызвав enterprises.migrationTokens.create .
3. Отправьте value этого токена миграции на ваш пользовательский DPC.
4. Убедитесь, что на устройстве установлена ​​политика Android Device Policy с помощью API Play EMM .
5. Используйте DpcMigrationClientFactory для создания DpcMigrationClient
6. На DpcMigrationClient вызовите метод migrateDeviceManagementToAndroidManagementApi . Это завершит миграцию.
7. Состояние deviceState изменится на ACTIVE , и вы получите сообщение STATUS_REPORT через канал Pub/Sub .

После завершения миграции вызывающее приложение теряет свои привилегии владельца устройства или владельца профиля, поскольку они переносятся в Android Device Policy. Этот процесс можно представить следующей схемой последовательности:

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

Миграционный токен

Токен миграции запрашивается сервером EMM для сигнализации о намерении перенести определенное устройство, управляемое пользовательским DPC. Токен миграции может использоваться до тех пор, пока миграция не будет успешно завершена или пока не истечет ее срок действия.

Индивидуальная интеграция DPC

Сначала необходимо создать DpcMigrationRequest , передав его создателю токен и, при необходимости, список настроенных сетей Wi-Fi:

// Create a DpcMigrationRequest
DpcMigrationRequest request =
        DpcMigrationRequest.builder()
            .setMigrationToken(token)
            .build();

Затем вы можете использовать DpcMigrationClient и начать процесс миграции с помощью migrateDeviceManagementToAndroidManagementApi :

// Create a DpcMigrationClient
DpcMigrationClient dpcMigrationClient = DpcMigrationClientFactory.create(context);
try {
  // Use helper function to retrieve Admin component name
  var adminComponentName = getAdminComponent(context);

  ListenableFuture<DpcMigrationAttempt> futureAttempt =
          dpcMigrationClient.migrateDeviceManagementToAndroidManagementApi(
              new ComponentName(context, DpcMigrationNotificationReceiver.class),
              adminComponentName,
              request);
  // handle futureAttempt
} catch (RuntimeException e) {
  // send failure feedback: "Error: " + e
}

Настройка NotificationReceiverService и отслеживание миграции

Реализуйте NotificationReceiverService в вашем пользовательском DPC.

Важно: эта функция требует реализации NotificationReceiverService , даже если вы не собираетесь отслеживать ход миграции.

Процесс миграции отслеживается на устройстве с помощью DpcMigrationAttempt .

Вы можете напрямую использовать метод, возвращаемый функцией migrateDeviceManagementToAndroidManagementApi , или использовать методы getMigrationAttempt и listMigrationAttempts для получения и перечисления попыток миграции.

// Passing an empty name, we retrieve the last attempt
var request = GetDpcMigrationAttemptRequest.builder().build();

var attempt = client.getMigrationAttempt(request);

При желании вы можете настроить DpcMigrationListener с помощью NotificationReceiverService для прослушивания обновлений статуса DpcMigrationAttempt .

// DpcMigrationNotificationReceiver for callback handling
public class DpcMigrationNotificationReceiver extends NotificationReceiverService
    implements DpcMigrationListener {

  @Override
  protected DpcMigrationListener getDpcMigrationListener() {
    return this;
  }

  @Override
  public void onMigrationStateChanged(DpcMigrationAttempt migrationAttempt) {
    // send success feedback
  }
}

Управление сетями Wi-Fi

Если есть сети Wi-Fi, управляемые пользовательским DPC, политика AMAPI ONC должна соответствовать конфигурациям этих сетей, чтобы AMAPI мог начать плавно управлять ими. Взаимодействие миграции DPC с управлением Wi-Fi различается в зависимости от режима управления.

Полностью управляемые устройства и рабочие профили на корпоративных устройствах

Во время миграции Android Device Policy предполагает, что любая сеть Wi-Fi , настроенная в политике, имеющая тот же SSID и тип безопасности настроенной сети Wi-Fi на устройстве, идентична соответствующей настроенной сети Wi-Fi. Таким образом, сети Wi-Fi, настроенные с помощью пользовательского DPC, остаются нетронутыми после миграции, пока не будет внесено изменение в политику ONC, соответствующую сети. Однако если пользовательский DPC удаляется после миграции, то сети Wi-Fi, настроенные с помощью пользовательского DPC, удаляются автоматически. Android Device Policy продолжает применять политику, и если какая-либо из этих сетей настроена в политике, сети, настроенные в политике, добавляются как обычно.

Рабочий профиль на персональном устройстве

По техническим причинам сети Wi-Fi, настроенные пользовательским DPC, должны быть удалены пользовательским DPC для Android Device Policy, чтобы начать управлять этими сетями Wi-Fi. AMAPI SDK заботится об этом и удаляет такие сети Wi-Fi перед передачей права собственности от пользовательского DPC к Android Device Policy, но для этого требуется, чтобы пользовательский DPC передал информацию об этих сетях в DpcMigrationRequest . После миграции сети , настроенные в политике, будут добавлены обычным образом, поэтому рекомендуется, чтобы сети, добавленные пользовательским DPC, также были настроены в политике.

Есть несколько моментов, на которые следует обратить внимание:

• Если активная сеть представляет собой сеть Wi-Fi, настроенную с помощью пользовательского DPC, устройство может на короткое время отключиться во время миграции.
• В DpcMigrationRequest следует передавать только сети Wi-Fi, настроенные с помощью пользовательского DPC, в противном случае миграция завершится неудачей, если сеть не может быть удалена с помощью AMAPI SDK (например, сеть Wi-Fi, добавленная пользователем).
• Сети Wi-Fi следует передавать в DpcMigrationRequest только в том случае, если пользовательский DPC является владельцем профиля на личном устройстве, в противном случае миграция не будет выполнена.
• По техническим причинам Android 12 является исключительным случаем, когда сети, переданные в DpcMigrationRequest игнорируются, а все сети Wi-Fi, настроенные пользовательским DPC, автоматически удаляются. Кроме того, для пользовательского DPC требуется разрешение ACCESS_WIFI_STATE на Android 12 для рабочих профилей на личных устройствах, в противном случае миграция не выполняется.

Предостережения

Вот несколько предостережений, связанных с этой функцией.

Идентификатор предприятия

Для рабочих профилей на Android 12 и более поздних версиях корпоративный идентификатор , доступ к которому можно получить из DevicePolicyManager.getEnrollmentSpecificId , не изменяется во время миграции. Однако если рабочий профиль, управляемый Android Device Policy, создается снова на устройстве (например, после удаления предыдущего или после сброса настроек устройства до заводских), корпоративный идентификатор изменится в этот момент.

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

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