העברת מכשירים קיימים ל-AMAPI

אפשר להעביר מכשירים שכבר מנוהלים על ידי DPC מותאם אישית אל Android Device Policy‏ (ADP) וליהנות מהיתרונות של Android Management API.

דרישות מוקדמות

  • המכשיר כבר מנוהל על ידי פתרון ה-EMM שלכם באמצעות DPC בהתאמה אישית.
  • ה-DPC המותאם אישית משולב עם AMAPI SDK.
  • המכשיר רשום ב-Google Play EMM API.
  • המכשיר שייך לקבוצת חשבונות Google Play לארגונים.
  • במכשיר פועלת מערכת Android מגרסה 9 ואילך.
  • במקרה של פרופילי עבודה במכשירים בבעלות החברה, במכשיר צריכה להיות מותקנת מערכת Android 11 ואילך.

שילוב עם AMAPI SDK ב-DPC מותאם אישית

תהליך ההעברה מחייב את אפליקציית ה-DPC בהתאמה אישית לשלב את AMAPI SDK. במדריך לשילוב AMAPI SDK אפשר למצוא מידע נוסף על הספרייה הזו ועל אופן ההוספה שלה לאפליקציה.

שלבים להעברת מכשיר

  1. מגדירים מדיניות שמיועדת לשימוש במכשיר אחרי ההעברה ל-AMAPI. כדי לספק את חוויית המשתמש הטובה ביותר, צריך לוודא שהמדיניות הזו זהה למדיניות שכבר נאכפת במכשיר על ידי ה-DPC. המדיניות ב-AMAPI צריכה להיות שייכת לאותו ארגון שהמכשיר כבר שייך לו ב-Play EMM API. שימו לב: שם הארגון זהה ב-AMAPI וב-Play EMM API.
  2. כדי ליצור טוקן העברה למכשיר, קוראים לפונקציה enterprises.migrationTokens.create.
  3. שולחים את value של טוקן ההעברה הזה אל ה-DPC המותאם אישית שלכם.
  4. מוודאים שאפליקציית Device Policy למכשירי Android מותקנת במכשיר באמצעות Play EMM API.
  5. משתמשים ב-DpcMigrationClientFactory כדי ליצור DpcMigrationClient
  6. ב-DpcMigrationClient, מבצעים קריאה ל-method‏ migrateDeviceManagementToAndroidManagementApi. כך מסיימים את ההעברה.
  7. הסמל deviceState משתנה ל-ACTIVE, ותקבלו הודעה STATUS_REPORT בערוץ Pub/Sub.

אחרי שההעברה מסתיימת, לאפליקציית השיחות אין יותר הרשאות של בעלי המכשיר או בעלי הפרופיל, כי הן מועברות אל ‏Device Policy למכשירי Android. אפשר לראות את התהליך בתרשים הרצף הבא:

תרשים רצף של העברת DPC

הערה: כדי להתחיל בהעברה, המכשיר צריך להיות מחובר לאינטרנט. התהליך מתוכנן כך שיהיה עמיד לניתוקים מהרשת במהלך ההעברה, כדי שהפעולות העיקריות שדורשות קישוריות לרשת יתבצעו לפני ההעברה בפועל של זכויות הבעלות על המכשיר או על הפרופיל מ-DPC אל ‏Device Policy למכשירי Android.

טוקן העברה

שרת ה-EMM מבקש אסימון העברה כדי לציין את הכוונה להעביר מכשיר מסוים שמנוהל על ידי DPC מותאם אישית. אפשר להשתמש באסימון העברה עד שההעברה תושלם בהצלחה או עד שתוקף האסימון יפוג.

שילוב מותאם אישית של בקר DPC

קודם צריך ליצור DpcMigrationRequest, להעביר את הטוקן, ואם צריך, את רשימת רשתות ה-Wi-Fi שהוגדרו ל-builder שלו:

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

אחרי כן, תוכלו לקבל DpcMigrationClient ולהתחיל בתהליך ההעברה באמצעות 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
}

הגדרת NotificationReceiverService ומעקב אחרי ההעברה

מטמיעים NotificationReceiverService בבקר DPC מותאם אישית.

תהליך ההעברה מתועד במכשיר באמצעות DpcMigrationAttempt.

אפשר להשתמש ישירות בערך שמוחזר על ידי migrateDeviceManagementToAndroidManagementApi או להשתמש ב-methods‏ getMigrationAttempt ו-listMigrationAttempts כדי לקבל רשימה של ניסיונות ההעברה.

// Passing an empty name, we retrieve the last attempt
var request = GetDpcMigrationAttemptRequest.builder().build();

var attempt = client.getMigrationAttempt(request);

אפשר להגדיר DpcMigrationListener באמצעות NotificationReceiverService כדי לקבל עדכוני סטטוס לגבי 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
  }
}

טיפול ברשתות Wi-Fi

אם יש רשתות Wi-Fi שמנוהלות על ידי DPC מותאם אישית, מדיניות AMAPI ONC צריכה להתאים להגדרות של הרשתות האלה כדי ש-AMAPI יתחיל לנהל אותן בצורה חלקה. האינטראקציה של העברת DPC עם ניהול Wi-Fi משתנה בהתאם למצב הניהול.

מכשירים מנוהלים באופן מלא ופרופילי עבודה במכשירים שבבעלות החברה

במהלך ההעברה, ‏Device Policy למכשירי Android מניחה שכל רשת Wi-Fi שמוגדרת במדיניות עם אותו SSID וסוג אבטחה של רשת Wi-Fi שהוגדרה במכשיר זהה לרשת Wi-Fi התואמת שהוגדרה. לכן, רשתות Wi-Fi שהוגדרו על ידי DPC מותאם אישית לא מושפעות אחרי ההעברה, עד שמתבצע שינוי במדיניות ONC שמתאימה לרשת. עם זאת, אם מסירים את ה-DPC המותאם אישית אחרי ההעברה, רשתות ה-Wi-Fi שהוגדרו על ידי ה-DPC המותאם אישית יוסרו אוטומטית. האפליקציה Device Policy ל-Android ממשיכה לאכוף את המדיניות, ואם אחת מהרשתות האלה מוגדרת במדיניות, הרשתות מתווספות כרגיל כמו שהן מוגדרות במדיניות.

פרופיל עבודה במכשיר אישי

מסיבות טכניות, צריך להסיר את רשתות ה-Wi-Fi שהוגדרו על ידי ה-DPC המותאם אישית, כדי ש-‏Device Policy למכשירי Android תוכל להתחיל לנהל את רשתות ה-Wi-Fi האלה. ה-SDK של AMAPI מטפל בזה ומסיר רשתות Wi-Fi כאלה לפני העברת הבעלות מ-DPC מותאם אישית אל ‏Device Policy למכשירי Android, אבל הוא דורש ש-DPC מותאם אישית יעביר מידע על הרשתות האלה ב-DpcMigrationRequest. אחרי ההעברה, רשתות שהוגדרו במדיניות יתווספו כרגיל, ולכן מומלץ להגדיר במדיניות גם את הרשתות שנוספו על ידי ה-DPC בהתאמה אישית.

חשוב לשים לב לנקודות הבאות:

  • אם הרשת הפעילה היא רשת Wi-Fi שהוגדרה על ידי DPC מותאם אישית, יכול להיות שהמכשיר יהיה אופליין לזמן קצר במהלך ההעברה.
  • רק רשתות ה-Wi-Fi שהוגדרו על ידי DPC מותאם אישית צריכות לעבור ב-DpcMigrationRequest, אחרת ההעברה תיכשל אם לא ניתן להסיר רשת באמצעות AMAPI SDK (לדוגמה, רשת Wi-Fi שהמשתמש הוסיף).
  • צריך להעביר רשתות Wi-Fi ב-DpcMigrationRequest רק אם בקר ה-DPC המותאם אישית הוא בעלים של פרופיל במכשיר בבעלות אישית, אחרת ההעברה תיכשל.
  • מסיבות טכניות, Android 12 הוא מקרה חריג שבו המערכת מתעלמת מהרשתות שמועברות ב-DpcMigrationRequest ומסירה אוטומטית את כל רשתות ה-Wi-Fi שהוגדרו על ידי ה-DPC המותאם אישית. בנוסף, נדרשת הרשאת ACCESS_WIFI_STATE ב-Android 12 לפרופילי עבודה במכשירים בבעלות אישית, אחרת המיגרציה תיכשל.

נקודות שצריך לשים לב אליהן:

הנה כמה הערות שחשוב לדעת לגבי התכונה הזו.

מזהה ספציפי לארגון

בפרופילי עבודה ב-Android 12 ואילך, המזהה הספציפי לארגון שאפשר לגשת אליו מ-DevicePolicyManager.getEnrollmentSpecificId לא משתנה בזמן ההעברה. עם זאת, אם פרופיל עבודה שמנוהל על ידי ‏Device Policy למכשירי Android נוצר מחדש במכשיר (לדוגמה, אחרי מחיקה של הפרופיל הקודם או אחרי איפוס המכשיר להגדרות המקוריות), המזהה הספציפי לארגון ישתנה בשלב הזה.

פרופילים של עבודה במכשירים מנוהלים

התכונה הזו לא נתמכת במכשירים מנוהלים שפועלת בהם גרסה Android 9 או 10 ויש בהם פרופיל עבודה. אסור לנסות להעביר את המכשירים האלה, ולא משנה אם מוצגת שגיאה או לא, אין תמיכה במכשירים כאלה להעברה של DPC.

הפקודה RESET_PASSWORD

אם למכשיר יש סיסמה למסך הנעילה, הפקודה RESET_PASSWORD תצליח רק אחרי שהמשתמש יאשר את פרטי הכניסה שלו (למשל, יזין מחדש את הקוד הסודי) אחרי ההעברה. אם למכשיר אין סיסמה לביטול הנעילה, אפשר להשתמש בפקודה RESET_PASSWORD מיד אחרי ההעברה.