Migrer des appareils existants vers AMAPI

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

Remarque :Ce processus est transparent pour les utilisateurs finaux. Il s'agit d'un processus à sens unique (cette opération est irréversible) et ne peut pas être utilisée pour migrer un appareil. d'une solution EMM à l'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 des appareils détenus par l'entreprise, l'appareil doit être exécuté 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 la fonction SDK AMAPI. Vous trouverez plus d'informations sur cette bibliothèque et sur la façon de l'ajouter à votre application dans 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. Toi vous pouvez trouver la dernière version disponible dans le 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éficiera des corrections de bugs et 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. à AMAPI. Pour une expérience utilisateur optimale, l'utilisation doit correspondre au règlement déjà appliquée sur l'appareil par votre DPC.
2. Créez un jeton de migration pour l'appareil en appelant la méthode 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 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. deviceState devient ACTIVE, et vous recevrez une STATUS_REPORT via le canal Pub/Sub.

Une fois la migration terminée, l'application appelante perd son propriétaire ou son profil d'appareil. Droits de propriétaire, car ils 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 résister aux déconnexions du réseau lors du de migration, de sorte que les principales opérations nécessitant une connectivité réseau sont effectuées avant le transfert des droits du propriétaire de l'appareil ou du profil. de votre DPC à Android Device Policy se produit.

Jeton de migration

Un jeton de migration est demandé par le serveur EMM pour signaler l'intention de migrer un appareil spécifique géré par un DPC personnalisé. Vous pouvez utiliser un jeton de migration jusqu'à ce que la migration soit terminée. jusqu'à son expiration.

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 constructeur:

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

Vous pouvez ensuite utiliser DpcMigrationClient et démarrer la 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 DpcMigrationAttempt

Vous pouvez utiliser directement celle renvoyée par migrateDeviceManagementToAndroidManagementApi ou utilisez 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 des mises à jour de l'état pour 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

Règle AMAPI ONC, si des réseaux Wi-Fi sont gérés par le DPC personnalisé doivent correspondre aux configurations de ces réseaux pour qu'AMAPI puisse commencer à les gérer en douceur. 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 les réseaux Wi-Fi configurée dans une règle ayant le même SSID et le même type de sécurité le réseau Wi-Fi configuré sur l'appareil est identique au réseau Réseau Wi-Fi. 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 soit modifiée réseau. Toutefois, si le DPC personnalisé est désinstallé après la migration, le Les réseaux Wi-Fi configurés par un DPC personnalisé sont supprimés automatiquement. Android Device Policy continue d'appliquer les règles, et si l'un de ces réseaux sont configurés dans la règle, les réseaux tels qu'ils sont configurés dans la règle sont ajoutés 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é par le DPC personnalisé pour Android Device Policy afin de commencer à gérer ces Réseaux Wi-Fi. Le SDK AMAPI s'en charge et supprime les réseaux Wi-Fi avant de transférer la propriété du DPC personnalisé à Android Device Policy mais il nécessite que le DPC personnalisé transmette des informations sur ces réseaux dans DpcMigrationRequest Après la migration, les réseaux configurées dans la règle seront ajoutées normalement. Il est donc recommandé d'utiliser les réseaux ajoutés par le DPC personnalisé doivent également être 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 peuvent être brièvement hors connexion pendant la migration.
• Seuls les réseaux Wi-Fi configurés par un DPC personnalisé doivent être transmis DpcMigrationRequest. Sinon, la migration échoue si une 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 doivent être transmis DpcMigrationRequest uniquement lorsque l'outil DPC personnalisé est un 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 via DpcMigrationRequest sont ignorés et tous les réseaux Wi-Fi les réseaux configurés par le DPC personnalisé sont supprimés automatiquement. De plus, il est obligatoire pour que l'outil DPC personnalisé dispose de ACCESS_WIFI_STATE autorisation 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 sous Android 12 et versions ultérieures, ID propre à l'entreprise, accessible depuis DevicePolicyManager.getEnrollmentSpecificId ne change pas au moment de la migration. Toutefois, si un profil professionnel gérés par Android Device Policy sont de nouveau créés sur l'appareil (par exemple, après avoir supprimé l'ancien ou après avoir rétabli la configuration d'usine de l'appareil), l'icône l'ID propre à l'entreprise change alors.

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 compte profil sous Android 9 ou 10. N'essayez pas de migrer ces appareils. et qu'une erreur se produise ou non, ces appareils ne sont pas compatibles pour la migration DPC.