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

אפשר להעביר מכשירים שכבר מנוהלים על ידי ה-DPC המותאם אישית שלך ל-Android Device Policy, וליהנות מהיתרונות של Android Management API.

הערה: התהליך הזה שקוף מבחינת משתמשי הקצה. זהו תהליך חד-כיווני (אי אפשר לבטל את הפעולה אחרי השלמתו) ואי אפשר להשתמש בו כדי להעביר מכשירים מ-EMM אחד לאחר.

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

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

שילוב עם AMAPI SDK בקר DPC בהתאמה אישית

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

חשוב: לתהליך הזה נדרשת גרסה 1.1.4 ואילך של ספריית AMAPI SDK. תוכלו למצוא את הגרסה העדכנית ביותר של נתוני הגרסה של ספריית AMAPI SDK.
מומלץ מאוד להשתמש תמיד בגרסה העדכנית ביותר של הספרייה כדי ליהנות מהיתרונות של תיקוני הבאגים והשיפורים הזמינים.

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

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

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

הערה: כדי להתחיל בהעברה, המכשיר צריך להיות מחובר לאינטרנט. התהליך נועד להיות עמיד לניתוקים מהרשת במהלך ההעברה, כך שהפעולות העיקריות שדורשות קישוריות רשת יבוצעו לפני ההעברה בפועל של הזכויות של בעלי המכשיר או של בעלי הפרופיל מבקר ה-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
}

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

מתבצע מעקב אחרי תהליך ההעברה במכשיר באמצעות 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() {
    // getDpcMigrationListener"
    return this;
  }

  @Override
  public void onMigrationStateChanged(DpcMigrationAttempt migrationAttempt) {
    // send success feedback
  }
}

מה עושים ברשתות ה-Wi-Fi

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

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

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

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

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

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

הנה כמה אזהרות שקשורות לתכונה הזו.

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

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

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

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