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 exploiter 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'une solution EMM à une autre.

Conditions préalables

• 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 des appareils détenus par l'entreprise, l'appareil doit exécuter Android 11 ou une version ultérieure.

Intégrer le SDK AMAPI dans 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 découvrir comment 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 des améliorations disponibles.

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 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 DpcMigrationClient, appelez la méthode migrateDeviceManagementToAndroidManagementApi. La migration est alors terminée.
7. 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 ceux-ci sont transférés vers Android Device Policy.

Remarque:L'appareil doit être connecté à Internet pour que la migration commence. Ce processus est conçu pour être résilient aux déconnexions du réseau lors du processus de migration, de sorte que les opérations clés nécessitant une connectivité réseau soient effectuées avant le transfert réel des droits de propriétaire de l'appareil ou du propriétaire du profil de votre DPC vers Android Device Policy.

Jeton de migration

Un jeton de migration est demandé par le serveur EMM pour signaler l'intention de migrer un appareil particulier géré par un DPC personnalisé. Vous pouvez utiliser un jeton de migration jusqu'à ce que la migration soit terminée ou qu'il expire.

Intégration DPC personnalisée

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 démarrer 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 de 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 AMAPI ONC doit correspondre aux configurations de ces réseaux pour qu'AMAPI commence à les gérer facilement. 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 suppose que tout réseau Wi-Fi configuré dans une 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é ne sont pas modifiés après la migration, jusqu'à ce que la règle ONC correspondant au réseau soit modifiée. Toutefois, si le DPC personnalisé est désinstallé après la migration, les réseaux Wi-Fi configurés par ce DPC personnalisé sont automatiquement supprimés. Android Device Policy continue d'appliquer les règles, et si l'un de ces réseaux est configuré dans la 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 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é vers Android Device Policy, mais il nécessite que le DPC personnalisé transmette les 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é que les réseaux ajoutés par le DPC personnalisé soient également configurés dans la 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 un 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 échoue.
• Pour des raisons techniques, Android 12 est un cas exceptionnel dans lequel les réseaux transmis dans DpcMigrationRequest sont ignorés et 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 échouera.

Mises en garde

Voici quelques mises en garde concernant cette fonctionnalité.

ID spécifique à l'entreprise

Pour les profils professionnels sous 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 à nouveau créé sur l'appareil (par exemple, après avoir supprimé le précédent ou après avoir rétabli la configuration d'usine de l'appareil), l'ID propre à 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 qui disposent d'un profil professionnel exécutant Android 9 ou 10. Aucune tentative de migration de ces appareils ne doit être effectuée. Qu'une erreur soit générée ou non, ces appareils ne sont pas compatibles avec la migration DPC.