I dispositivi già gestiti dal tuo DPC personalizzato possono essere migrati ad Android Device Policy (ADP) e sfruttare l'API Android Management.
Prerequisiti
- Il dispositivo è già gestito dal tuo EMM con un DPC personalizzato.
- Il tuo DPC personalizzato è integrato con l'SDK AMAPI.
- Il dispositivo è registrato con l'API EMM di Google Play.
- Il dispositivo appartiene a un'azienda con account Google Play gestiti.
- Sul dispositivo è in esecuzione Android 9 o versioni successive.
- Nel caso di profili di lavoro sui dispositivi di proprietà aziendale, sul dispositivo deve essere in esecuzione Android 11 o versioni successive.
Integrare l'SDK AMAPI nel DPC personalizzato
La procedura di migrazione richiede che l'applicazione DPC personalizzata integri l'SDK AMAPI. Puoi trovare ulteriori informazioni su questa libreria e su come aggiungerla alla tua applicazione nella guida all'integrazione dell'SDK AMAPI.
Passaggi per migrare un dispositivo
- Configura un criterio da utilizzare per il dispositivo dopo la migrazione ad AMAPI. Per un'esperienza utente ottimale, questo criterio deve essere equivalente a quello già applicato al dispositivo dal tuo DPC. Il criterio in AMAPI deve appartenere alla stessa azienda a cui il dispositivo appartiene già nell'API EMM di Play. Tieni presente che una determinata azienda ha lo stesso nome sia in AMAPI sia nell'API EMM di Play.
- Crea un token di migrazione per il dispositivo chiamando
enterprises.migrationTokens.create. - Invia il
valuedi questo token di migrazione al tuo DPC personalizzato. - Assicurati che Android Device Policy sia installato sul dispositivo utilizzando l'API EMM di Play.
- Utilizza
DpcMigrationClientFactoryper creare unDpcMigrationClient. - In
DpcMigrationClient, chiama ilmigrateDeviceManagementToAndroidManagementApimetodo. La migrazione è completata. - Il
deviceStatecambia inACTIVEe riceverai unSTATUS_REPORTmessaggio tramite il Pub/Sub canale.
Una volta completata la migrazione, l'app chiamante perde i privilegi di proprietario del dispositivo o del profilo, in quanto questi vengono trasferiti ad Android Device Policy. Questa procedura può essere rappresentata dal seguente diagramma di sequenza:

Nota: il dispositivo deve essere connesso a internet per avviare la migrazione. La procedura è progettata per essere resiliente alle disconnessioni di rete durante il processo di migrazione, in modo che le operazioni chiave che richiedono la connettività di rete vengano eseguite prima del trasferimento effettivo dei diritti di proprietario del dispositivo o del profilo dal DPC ad Android Device Policy.
Token di migrazione
Il server EMM richiede un token di migrazione per segnalare l'intenzione di migrare un determinato dispositivo gestito da un DPC personalizzato. Un token di migrazione può essere utilizzato fino al completamento della migrazione o fino alla sua scadenza.
Integrazione del DPC personalizzato
Per prima cosa, devi creare un DpcMigrationRequest, passando
il token e, se necessario, l'elenco delle reti Wi-Fi configurate al relativo
builder:
// Create a DpcMigrationRequest
DpcMigrationRequest request =
DpcMigrationRequest.builder()
.setMigrationToken(token)
.build();
Puoi quindi utilizzare un DpcMigrationClient e avviare la
procedura di migrazione con
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
}
Configurare un NotificationReceiverService e monitorare la migrazione
Implementa un NotificationReceiverService
nel tuo DPC personalizzato.
La procedura di migrazione viene monitorata sul dispositivo tramite un
DpcMigrationAttempt.
Puoi utilizzare direttamente quello restituito da
migrateDeviceManagementToAndroidManagementApi oppure utilizzare i metodi
getMigrationAttempt e
listMigrationAttempts per recuperare ed elencare i tentativi di migrazione.
// Passing an empty name, we retrieve the last attempt
var request = GetDpcMigrationAttemptRequest.builder().build();
var attempt = client.getMigrationAttempt(request);
Facoltativamente, puoi configurare un DpcMigrationListener utilizzando
il tuo NotificationReceiverService per ascoltare
gli aggiornamenti di stato di 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
}
}
Gestire le reti Wi-Fi
Se sono presenti reti Wi-Fi gestite dal DPC personalizzato, il criterio ONC AMAPI deve corrispondere alle configurazioni di queste reti affinché AMAPI possa iniziare a gestirle senza problemi. L'interazione della migrazione DPC con la gestione del Wi-Fi varia a seconda della modalità di gestione.
Dispositivi completamente gestiti e profili di lavoro sui dispositivi di proprietà aziendale
Durante la migrazione, Android Device Policy presuppone che qualsiasi rete Wi-Fi configurata nel criterio con lo stesso SSID e tipo di sicurezza di una rete Wi-Fi configurata sul dispositivo sia identica alla rete Wi-Fi configurata corrispondente. Di conseguenza, le reti Wi-Fi configurate dal DPC personalizzato rimangono invariate dopo la migrazione finché non viene apportata una modifica al criterio ONC corrispondente alla rete. Tuttavia, se il DPC personalizzato viene disinstallato dopo la migrazione, le reti Wi-Fi configurate dal DPC personalizzato vengono rimosse automaticamente. Android Device Policy continua ad applicare il criterio e, se una di queste reti è configurata nel criterio, le reti configurate nel criterio vengono aggiunte come di consueto.
Profilo di lavoro su un dispositivo personale
Per motivi tecnici, le reti Wi-Fi configurate dal DPC personalizzato devono essere rimosse dal DPC personalizzato affinché Android Device Policy possa iniziare a gestirle. L'SDK AMAPI si occupa di questa operazione e rimuove queste reti Wi-Fi
prima di trasferire la proprietà dal DPC personalizzato ad Android Device Policy
ma richiede che il DPC personalizzato passi le informazioni su queste reti in
DpcMigrationRequest. Dopo la migrazione, le reti
configurate nel criterio verranno aggiunte normalmente, pertanto è consigliabile che anche le
reti aggiunte dal DPC personalizzato siano configurate nel criterio.
Ecco alcuni punti da tenere presenti:
- Se la rete attiva è una rete Wi-Fi configurata dal DPC personalizzato, il dispositivo potrebbe essere brevemente offline durante la migrazione.
- In
DpcMigrationRequestdevono essere passate solo le reti Wi-Fi configurate dal DPC personalizzato.In caso contrario, la migrazione non riesce se una rete non può essere rimossa dall'SDK AMAPI (ad es. rete Wi-Fi aggiunta dall'utente). - Le reti Wi-Fi devono essere passate in
DpcMigrationRequestsolo quando il DPC personalizzato è un proprietario del profilo su un dispositivo di proprietà personale. In caso contrario, la migrazione non riesce. - Per motivi tecnici, Android 12 è un caso eccezionale in cui le reti passate in
DpcMigrationRequestvengono ignorate e tutte le reti Wi-Fi configurate dal DPC personalizzato vengono rimosse automaticamente. Inoltre, è necessario che il DPC personalizzato disponga dell' autorizzazioneACCESS_WIFI_STATEsu Android 12 per i profili di lavoro sui dispositivi di proprietà personale. In caso contrario, la migrazione non riesce.
Avvertenze
Ecco alcune avvertenze relative a questa funzionalità.
ID specifico dell'azienda
Per i profili di lavoro su Android 12 e versioni successive, l'ID specifico dell'azienda,
a cui è possibile accedere da DevicePolicyManager.getEnrollmentSpecificId
non cambia al momento della migrazione. Tuttavia, se sul dispositivo viene creato di nuovo un profilo di lavoro gestito da Android Device Policy (ad esempio dopo aver eliminato quello precedente o dopo aver ripristinato i dati di fabbrica del dispositivo), l'ID specifico dell'azienda cambierà a quel punto.
Profili di lavoro sui dispositivi completamente gestiti
Questa funzionalità non è supportata sui dispositivi completamente gestiti con un profilo di lavoro con Android 9 o 10. Non tentare di migrare questi dispositivi e, indipendentemente dal fatto che venga generato un errore, questi dispositivi non sono supportati per la migrazione DPC.
Comando RESET_PASSWORD
Se il dispositivo ha una password per la schermata di blocco, il RESET_PASSWORD comando
avrà esito positivo solo dopo che l'utente avrà confermato le proprie credenziali
(ad es. reinserendo il PIN) dopo la migrazione. Se il dispositivo non ha una password per la schermata di blocco, il comando RESET_PASSWORD può essere utilizzato subito dopo la migrazione.