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.

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 il 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 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.
• Pour les profils professionnels sur les appareils détenus par l'entreprise, l'appareil doit exécuter Android 11 ou 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 profiter 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 valeur doit être équivalente à la stratégie 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ée.
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 DpcMigrationClient, appelez la méthode migrateDeviceManagementToAndroidManagementApi. La migration est terminée.
7. deviceState est remplacé par ACTIVE, et vous recevrez un message STATUS_REPORT via le canal Pub/Sub.

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

Remarque:L'appareil doit être connecté à Internet pour que la migration puisse commencer. Le processus est conçu pour être résilient aux déconnexions réseau pendant le processus de migration, de sorte que les opérations clés nécessitant une connectivité réseau soient effectuées avant le transfert effectif des droits de 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 particulier géré par un DPC personnalisé. Un jeton de migration peut être utilisé jusqu'à ce que la migration soit terminée ou jusqu'à son expiration.

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 générateur:

// 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 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 d'é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 ONC AMAPI doit correspondre aux configurations de ces réseaux pour qu'AMAPI commence à 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 détenus par l'entreprise

Lors de la migration, Android Device Policy suppose que tout réseau Wi-Fi configuré dans la stratégie 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 DPC personnalisé ne sont pas modifiés après la migration tant qu'il n'y a pas de modification de 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 supprimés automatiquement. Android Device Policy continue d'appliquer la stratégie. Si l'un de ces réseaux est configuré dans la stratégie, 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 commence à gérer ces réseaux Wi-Fi. Le SDK AMAPI s'en occupe et supprime ces réseaux Wi-Fi avant de transférer la propriété de la DPC personnalisée vers Android Device Policy. Toutefois, la DPC personnalisée doit transmettre des informations sur ces réseaux dans DpcMigrationRequest. Après la migration, les réseaux configurés dans la stratégie seront ajoutés normalement. Il est donc recommandé que les réseaux ajoutés par le DPC personnalisé soient également configurés dans la stratégie.

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, sinon la migration échoue.
• Pour des raisons techniques, Android 12 est un cas exceptionnel où les réseaux transmis dans DpcMigrationRequest sont ignorés et que 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 propre à l'entreprise

Pour les profils professionnels sur Android 12 et versions ultérieures, l'ID propre à 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 disposant d'un profil professionnel exécutant Android 9 ou 10. Vous ne devez pas tenter de migrer ces appareils. En outre, que des erreurs soient générées ou non, ces appareils ne sont pas compatibles avec la migration DPC.