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 et bénéficier de l'API Android Management.

Remarque :Ce processus est transparent pour les utilisateurs finaux. Il s'agit d'un processus à sens unique (il ne peut pas être annulé une fois terminé) et ne peut pas être utilisé pour migrer un appareil d'un EMM à un autre.

Prérequis

• L'appareil est déjà géré par votre EMM avec un DPC personnalisé.
• Votre outil DPC personnalisé est intégré au SDK AMAPI.
• L'appareil est enregistré auprès de l'API EMM Google Play.
• L'appareil appartient à un compte d'entreprise Google Play Accounts.
• L'appareil est équipé d'Android 9 ou version ultérieure.
• Dans le cas de profils professionnels sur des appareils détenus par l'entreprise, ceux-ci doivent exécuter Android 11 ou une version ultérieure.

Intégrer le SDK AMAPI dans votre outil de contrôle des règles relatives aux appareils 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.

Important :Ce processus nécessite la version 1.1.4 ou ultérieure de la bibliothèque du SDK AMAPI. Vous trouverez la dernière version disponible dans les notes de version de la bibliothèque du SDK AMAPI.
Nous vous recommandons vivement de toujours utiliser la dernière version de la bibliothèque pour bénéficier des corrections de bugs et améliorations disponibles.

Procédure de migration d'un appareil

1. Définissez une règle que l'appareil doit utiliser après sa migration vers AMAPI. Pour une expérience utilisateur optimale, cette règle doit être équivalente à la règle déjà appliquée sur l'appareil par votre DPC.
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. Utiliser DpcMigrationClientFactory pour créer un DpcMigrationClient
6. Sur le DpcMigrationClient, appelez la méthode migrateDeviceManagementToAndroidManagementApi. La migration est maintenant terminée.
7. Le deviceState devient ACTIVE, et vous recevez un message STATUS_REPORT via le canal Pub/Sub.

Une fois la migration terminée, l'application appelante perd ses droits de propriétaire d'appareil ou de propriétaire de profil, car ces droits sont transférés vers Android Device Policy.

Remarque:L'appareil doit être connecté à Internet pour que la migration commence. Le processus est conçu pour résister aux déconnexions du réseau lors du processus de migration, de sorte que les opérations de clé nécessitant une connectivité réseau soient effectuées avant le transfert réel des droits du propriétaire de l'appareil ou du 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'à la fin de la migration ou jusqu'à son expiration.

Intégration de l'outil 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
}

Suivre la progression de la migration

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

Vous pouvez utiliser directement celle renvoyée par migrateDeviceManagementToAndroidManagementApi ou utiliser les méthodes getMigrationAttempt et listMigrationAttempts pour obtenir et répertorier 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 du DpcMigrationAttempt.

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

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

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

Gérer les réseaux Wi-Fi

Si des réseaux Wi-Fi sont 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 en toute fluidité. L'interaction de la migration DPC avec la gestion Wi-Fi varie en fonction du mode de gestion.

Appareils entièrement gérés et profils professionnels sur les appareils détenus par l'entreprise

Lors de la migration, Android Device Policy part du principe 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 un DPC personnalisé restent intacts après la migration jusqu'à ce que la règle ONC correspondant au réseau soit modifiée. Toutefois, si l'outil DPC personnalisé est désinstallé après la migration, les réseaux Wi-Fi configurés par l'outil DPC personnalisé sont automatiquement supprimés. Android Device Policy continue d'appliquer les règles. Si l'un de ces réseaux est configuré dans une règle, les réseaux configurés dans la règle sont ajoutés 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 Android Device Policy afin de commencer à gérer ces réseaux Wi-Fi. Le SDK AMAPI s'occupe de cela et supprime ces réseaux Wi-Fi avant de transférer la propriété du DPC personnalisé vers Android Device Policy, mais il nécessite qu'il transmette des informations sur ces réseaux dans DpcMigrationRequest. Après la migration, les réseaux configurés dans une règle seront ajoutés normalement. Il est donc recommandé de configurer également les réseaux ajoutés par le DPC personnalisé dans une règle.

Voici quelques points à retenir:

• Si le réseau actif est un réseau Wi-Fi configuré par un DPC personnalisé, l'appareil peut être brièvement hors connexion lors de la migration.
• Seuls les réseaux Wi-Fi configurés par l'outil 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 de profil sur un appareil personnel, sinon la migration échouera.
• Pour des raisons techniques, Android 12 est un cas exceptionnel où les réseaux transmis dans DpcMigrationRequest sont ignorés et tous les réseaux Wi-Fi configurés par le DPC personnalisé sont automatiquement supprimés. En outre, le DPC personnalisé doit disposer de l'autorisation ACCESS_WIFI_STATE sur Android 12 pour les profils professionnels sur les appareils personnels, sans quoi la migration échouera.

Mises en garde

Voici quelques mises en garde concernant cette fonctionnalité.

ID spécifique à l'entreprise

Pour les profils professionnels sur Android 12 ou version ultérieure, 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 créé à nouveau sur l'appareil (par exemple, après la suppression du profil précédent ou après le rétablissement de la configuration d'usine de l'appareil), l'ID spécifique à l'entreprise change à ce stade.

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

Cette fonctionnalité n'est pas disponible sur les appareils entièrement gérés dotés d'un profil professionnel fonctionnant sous Android 9 ou 10. Aucune tentative de migration de ces appareils ne doit être effectuée, et qu'une erreur se produise ou non, ces appareils ne sont pas compatibles avec la migration DPC.