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

טוקן העברה

שרת ה-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
}

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

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

אפשר להשתמש ישירות ב-method שמוחזר על ידי 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() {
    // 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, לא משתנה בזמן ההעברה. עם זאת, אם פרופיל עבודה שמנוהל על ידי Device Policy למכשירי Android נוצר שוב במכשיר (למשל אחרי מחיקת הפרופיל הקודם או אחרי איפוס המכשיר להגדרות המקוריות), המזהה הייחודי לארגון ישתנה בשלב הזה.

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

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