העברת מכשירים קיימים ל-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 בהתאמה אישית

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

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

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

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

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

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

טוקן העברה

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

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

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

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

מסיבות טכניות, רשתות Wi-Fi שהוגדרו על ידי ה-DPC המותאם אישית צריכות להימחק על ידי ה-DPC המותאם אישית כדי ש-Android Device Policy תתחיל לנהל את רשתות ה-Wi-Fi האלה. ערכת ה-SDK של AMAPI מטפלת בבעיה הזו ומסירה רשתות Wi-Fi כאלה לפני העברת הבעלות מה-DPC המותאם אישית למדיניות המכשיר של 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 המותאם אישית יוסרו באופן אוטומטי. בנוסף, ל-DPC המותאם אישית צריכה להיות ההרשאה ACCESS_WIFI_STATE ב-Android 12 לפרופילים של עבודה במכשירים בבעלות אישית, אחרת ההעברה תיכשל.

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

ריכזנו כאן כמה אזהרות לגבי התכונה הזו.

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

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

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

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