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

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

Предварительные требования

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

Интегрируйте AMAPI SDK в свой собственный DPC.

Для миграции пользовательскому DPC-приложению необходимо интегрировать AMAPI SDK. Более подробную информацию об этой библиотеке и о том, как добавить ее в ваше приложение, вы найдете в руководстве по интеграции AMAPI SDK .

Этапы миграции устройства

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

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

Диаграмма последовательности миграции DPC

Примечание: Для начала миграции устройство должно быть подключено к интернету. Процесс разработан таким образом, чтобы быть устойчивым к разрывам сетевого соединения во время миграции, поэтому ключевые операции, требующие сетевого подключения, выполняются до фактической передачи прав владельца устройства или профиля из вашего 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.

Процесс миграции отслеживается на устройстве с помощью параметра 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, необходимо удалить, чтобы 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, автоматически удаляются. Кроме того, для работы профилей на личных устройствах в Android 12 требуется наличие у пользовательского DPC разрешения ACCESS_WIFI_STATE , иначе миграция завершится неудачей.

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

Вот некоторые нюансы, связанные с этой функцией.

Идентификатор, специфичный для предприятия

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

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

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

команда RESET_PASSWORD

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