Migrer des appareils existants vers AMAPI

Les appareils déjà gérés par votre DPC personnalisé peuvent être migrés vers Android Device Policy (ADP) et profiter de l'API Android Management.

Prérequis

  • L'appareil est déjà géré par votre EMM avec un DPC personnalisé.
  • Votre DPC personnalisé est intégré au SDK AMAPI.
  • L'appareil est enregistré avec l'API Google Play EMM.
  • L'appareil appartient à un compte d'entreprise Google Play Accounts.
  • L'appareil est équipé d'Android 9 ou version ultérieure.
  • Dans le cas des profils professionnels sur les appareils détenus par l'entreprise, l'appareil doit être équipé d'Android 11 ou version ultérieure.

Intégrer le SDK AMAPI à votre DPC personnalisé

Le processus de migration nécessite que l'application DPC personnalisée intègre le SDK AMAPI. Pour en savoir plus sur cette bibliothèque et sur la façon de l'ajouter à votre application, consultez le guide d'intégration du SDK AMAPI.

Procédure de migration d'un appareil

  1. Configurez une règle destinée à être utilisée par l'appareil après sa migration vers AMAPI. Pour une expérience utilisateur optimale, cette valeur doit être équivalente à la règle déjà appliquée sur l'appareil par votre DPC. La règle dans AMAPI doit appartenir à la même entreprise que celle à laquelle l'appareil appartient déjà dans l'API Play EMM. Notez qu'une entreprise donnée porte le même nom dans l'AMAPI et dans l'API Play EMM.
  2. Créez un jeton de migration pour l'appareil en appelant enterprises.migrationTokens.create.
  3. Envoyez le value de ce jeton de migration à votre DPC personnalisé.
  4. Assurez-vous qu'Android Device Policy est installé sur l'appareil à l'aide de l'API Play EMM.
  5. Utilisez DpcMigrationClientFactory pour créer un DpcMigrationClient.
  6. Sur le DpcMigrationClient, appelez la méthode migrateDeviceManagementToAndroidManagementApi. La migration est alors terminée.
  7. L'état deviceState passe à ACTIVE, et vous recevez un message STATUS_REPORT via le canal Pub/Sub.

Une fois la migration terminée, l'application d'appel perd ses droits de propriétaire de l'appareil ou du profil, car ils sont transférés à Android Device Policy. Ce processus peut être représenté par le diagramme de séquence suivant :

Diagramme de séquence de la migration du DPC

Remarque : L'appareil doit être connecté à Internet pour que la migration puisse commencer. Le processus est conçu pour résister aux déconnexions réseau pendant la migration. Ainsi, les opérations clés nécessitant une connectivité réseau sont effectuées avant le transfert effectif des droits de propriétaire de l'appareil ou de propriétaire du profil de votre DPC vers Android Device Policy.

Jeton de migration

Le serveur EMM demande un jeton de migration pour signaler l'intention de migrer un appareil spécifique géré par un DPC personnalisé. Un jeton de migration peut être utilisé jusqu'à ce que la migration soit effectuée ou qu'il expire.

Intégration d'un DPC personnalisé

Vous devez d'abord créer un DpcMigrationRequest en transmettant le jeton et, si nécessaire, la liste des réseaux Wi-Fi configurés à son compilateur :

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

Vous pouvez ensuite obtenir un DpcMigrationClient et lancer le processus de migration avec 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
}

Configurer un NotificationReceiverService et suivre la migration

Implémentez un NotificationReceiverService dans votre DPC personnalisé.

Le processus de migration est suivi sur l'appareil via un DpcMigrationAttempt.

Vous pouvez utiliser directement celui renvoyé par migrateDeviceManagementToAndroidManagementApi ou utiliser les méthodes getMigrationAttempt et listMigrationAttempts pour obtenir et lister les tentatives de migration.

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

var attempt = client.getMigrationAttempt(request);

Vous pouvez éventuellement configurer un DpcMigrationListener à l'aide de votre NotificationReceiverService pour écouter les mises à jour de l'état de 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
  }
}

Gérer les réseaux Wi-Fi

S'il existe des réseaux Wi-Fi gérés par le DPC personnalisé, la règle ONC AMAPI doit correspondre aux configurations de ces réseaux pour qu'AMAPI puisse commencer à les gérer correctement. L'interaction de la migration DPC avec la gestion du Wi-Fi varie selon le mode de gestion.

Appareils entièrement gérés et profils professionnels sur les appareils appartenant à l'entreprise

Lors de la migration, Android Device Policy suppose que tout réseau Wi-Fi configuré dans la règle ayant le même SSID et le même type de sécurité qu'un réseau Wi-Fi configuré sur l'appareil est identique au réseau Wi-Fi configuré correspondant. Par conséquent, les réseaux Wi-Fi configurés par le DPC personnalisé ne sont pas modifiés après la migration tant qu'il n'y a pas de changement dans la stratégie ONC correspondant au réseau. Toutefois, si le DPC personnalisé est désinstallé après la migration, les réseaux Wi-Fi configurés par le DPC personnalisé sont automatiquement supprimés. La règle relative aux appareils Android continue d'être appliquée. Si l'un de ces réseaux est configuré dans la règle, il est ajouté comme d'habitude.

Profil professionnel sur un appareil personnel

Pour des raisons techniques, les réseaux Wi-Fi configurés par le DPC personnalisé doivent être supprimés par le DPC personnalisé pour qu'Android Device Policy puisse commencer à gérer ces réseaux Wi-Fi. Le SDK AMAPI s'en charge et supprime ces réseaux Wi-Fi avant de transférer la propriété du DPC personnalisé à Android Device Policy, mais il exige que le DPC personnalisé transmette des informations sur ces réseaux dans DpcMigrationRequest. Après la migration, les réseaux configurés dans la règle seront ajoutés normalement. Il est donc recommandé de configurer également dans la règle les réseaux ajoutés par le DPC personnalisé.

Voici quelques points à prendre en compte :

  • Si le réseau actif est un réseau Wi-Fi configuré par un DPC personnalisé, l'appareil peut être brièvement hors connexion pendant la migration.
  • Seuls les réseaux Wi-Fi configurés par le DPC personnalisé doivent être transmis dans DpcMigrationRequest. Sinon, la migration échoue si un réseau ne peut pas être supprimé par le SDK AMAPI (par exemple, un réseau Wi-Fi ajouté par l'utilisateur).
  • Les réseaux Wi-Fi ne doivent être transmis dans DpcMigrationRequest que lorsque le DPC personnalisé est propriétaire du profil sur un appareil personnel. Dans le cas contraire, la migration échoue.
  • Pour des raisons techniques, Android 12 est un cas exceptionnel où les réseaux transmis dans DpcMigrationRequest sont ignorés et où tous les réseaux Wi-Fi configurés par le DPC personnalisé sont supprimés automatiquement. De plus, le DPC personnalisé doit disposer de l'autorisation ACCESS_WIFI_STATE sur Android 12 pour les profils professionnels sur les appareils personnels, sinon la migration échoue.

Mises en garde

Voici quelques mises en garde concernant cette fonctionnalité.

ID spécifique à l'entreprise

Pour les profils professionnels sur Android 12 et versions ultérieures, l'ID spécifique à l'entreprise, accessible depuis DevicePolicyManager.getEnrollmentSpecificId, ne change pas au moment de la migration. Toutefois, si un profil professionnel géré par Android Device Policy est recréé sur l'appareil (par exemple, après la suppression du précédent ou après la réinitialisation de l'appareil), l'ID spécifique à l'entreprise changera à ce moment-là.

Profils professionnels sur des appareils entièrement gérés

Cette fonctionnalité n'est pas disponible sur les appareils entièrement gérés disposant d'un profil professionnel et exécutant Android 9 ou 10. Il ne faut pas essayer de migrer ces appareils. Qu'une erreur soit générée ou non, ces appareils ne sont pas compatibles avec la migration DPC.

Commande RESET_PASSWORD

Si l'appareil dispose d'un mot de passe pour l'écran de verrouillage, la commande RESET_PASSWORD ne fonctionnera qu'une fois que l'utilisateur aura confirmé ses identifiants (par exemple, en saisissant à nouveau son code PIN) après la migration. Si l'appareil n'a pas de mot de passe pour l'écran de verrouillage, la commande RESET_PASSWORD peut être utilisée juste après la migration.