ניהול עדכוני המערכת

במדריך למפתחים הזה מוסבר איך הבקר לניהול מדיניות המכשירים (DPC) יכול לנהל את עדכוני מערכת Android בשם משתמש המכשיר.

מבוא

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

מנהל IT יכול לנהל את עדכוני המערכת עבור המשתמש במכשיר באמצעות בקר ה-DPC. ל-DPC יכולה להיות בעלות על מכשיר מנוהל במלואו (נקרא 'בעל מכשיר') או על פרופיל עבודה (נקרא 'בעל פרופיל'). בטבלה 1 מוסבר איך בעלי המכשירים יכולים לנהל את עדכוני המערכת, ואילו בעלי הפרופילים יכולים רק לדווח על מידע לגבי עדכוני המערכת.

טבלה 1: המשימות הזמינות ל-DPCs תלויות במצב הבעלות

איך בודקים אם יש עדכונים בהמתנה

עדכון בהמתנה הוא עדכון מערכת למכשיר שעדיין לא הותקן. ה-DPC יכול לעזור למנהלי IT לבדוק אילו מכשירים יש להם עדכוני מערכת בהמתנה, ואולי לבקש ממשתמשי המכשיר להתקין עדכונים קריטיים באופן מיידי.

בעלי המכשיר ובעלי הפרופיל עם Android 8.0 (רמת API 26) ואילך יכולים לבדוק אם יש עדכון מערכת בהמתנה במכשיר. שיחת טלפון DevicePolicyManager.getPendingSystemUpdate() הפונקציה מחזירה את הערך null אם המכשיר עדכני. אם יש עדכון מערכת בהמתנה, ה-method תחזיר מידע על העדכון.

מידע נוסף על עדכון בהמתנה

אחרי שמתקשרים אל getPendingSystemUpdate(), אפשר לבדוק את הפריט שהוחזר SystemUpdateInfo כדי לקבל מידע נוסף על העדכון בהמתנה. בדוגמה הבאה מוסבר איך אפשר לבדוק מתי עדכון בהמתנה היה זמין לראשונה במכשיר:

val firstAvailable =
        dpm.getPendingSystemUpdate(adminName)?.receivedTime
firstAvailable?.let {
    Log.i(TAG, "Update first available: ${Date(firstAvailable)}")
}

SystemUpdateInfo updateInfo = dpm.getPendingSystemUpdate(adminName);
if (updateInfo != null) {
  Long firstAvailable = updateInfo.getReceivedTime();
  Log.i(TAG, "Update first available: " + new Date(firstAvailable));
}

קריאה חוזרת (callback) של המערכת

כשעדכון זמין, מערכת Android מעדכנת את בעלי המכשירים על העדכון החדש. ב-Android מגרסה 8.0 ואילך, המערכת גם תודיע לבעלי הפרופיל.

בתת-הסוג DeviceAdminReceiver, משנים את פונקציית ה-callback‏ onSystemUpdatePending(). לא צריך כדי לרשום או לפרסם את ה-DPC כדי לקבל את הקריאה החוזרת (callback). המערכת עשויה קוראים לשיטה הזו יותר מפעם אחת לצורך עדכון אחד, לכן כדאי לבדוק את סטטוס העדכון לפני שאתם מגיבים. אפשר להתקשר אל getPendingSystemUpdate() כדי לקבל מידע נוסף על עדכון מערכת בקריאה חוזרת (callback). הדוגמה הבאה מראה איך לעשות זאת:

/**
 * Called when a new update is available.
 */
override fun onSystemUpdatePending(context: Context?, intent: Intent?,
                                   receivedTime: Long) {

    // System update information is supported in API level 26 or higher.
    if (Build.VERSION.SDK_INT < Build.VERSION_CODES.O) {
        return
    }

    val updateInfo = getManager(context)
            .getPendingSystemUpdate(getWho(context))
            ?: return
    if (updateInfo.securityPatchState ==
            SystemUpdateInfo.SECURITY_PATCH_STATE_TRUE) {
        // Perhaps install because this is a security patch.
        // ...
    }
}

/**
 * Called when a new update is available.
 */
public void onSystemUpdatePending (Context context, Intent intent,
                                   long receivedTime) {

  // System update information is supported in API level 26 or higher.
  if (Build.VERSION.SDK_INT < Build.VERSION_CODES.O) {
    return;
  }
  SystemUpdateInfo updateInfo = getManager(context)
      .getPendingSystemUpdate(getWho(context));
  if (updateInfo == null) {
    return;
  }
  if (updateInfo.getSecurityPatchState() ==
      SystemUpdateInfo.SECURITY_PATCH_STATE_TRUE) {
    // Perhaps install because this is a security patch.
    // ...
  }
}

אם למערכת יש יותר מבקר DPC אחד, לדוגמה, פרופילי עבודה בחשבונות מנוהלים בעלי המכשיר והבעלים של הפרופיל יקבלו את הקריאה החוזרת.

עדכון המדיניות

הבעלים של המכשיר יכול לקבוע מתי העדכונים יותקנו על ידי הגדרת מדיניות מקומית לעדכון המערכת במכשיר. יש שלושה סוגים של מדיניות עדכוני מערכת:

אוטומטי

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

בחלון נפרד

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

נדחה

דחיית ההתקנה של עדכוני המערכת ב-30 יום. אחרי 30 יום פרק הזמן הסתיים, המערכת תנחה את המשתמש במכשיר להתקין את העדכון.

תקופות דחייה

המערכת מגבילה כל עדכון להשהיה אחת של 30 יום. התקופה מתחילה אחרי קודם המערכת דוחה את העדכון והגדרה של כללי מדיניות דחייה חדשים לא להאריך את פרק הזמן.

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

המערכת תאפס את הטיימר לדחייה ל-30 יום אם יהיה עדכון אחר להיות זמינות במהלך התקופה - כך שאפשר לתת למנהלי IT הזדמנות לנסות את המערכת המשולבת אחרי 30 ימים ללא עדכון חדש, המערכת תשלח משתמש שיתקין את כל העדכונים הממתינים להתקנה. מאוחר יותר, כשעדכון מערכת חדש הופך זמינה, התקופה של 30 הימים תתחיל שוב.

איך מגדירים מדיניות

אפשר להגדיר מדיניות עדכונים ב-Android מגרסה 8.0 (רמת API 26) ואילך. כדי לציין מתי המכשיר צריך להתקין עדכוני מערכת, יוצרים מכונה של SystemUpdatePolicy באמצעות אחד משלושת הסוגים שמפורטים למעלה. כדי להגדיר מדיניות, הבעלים של המכשיר קורא לשיטה DevicePolicyManager‏setSystemUpdatePolicy(). את הקוד הבא דוגמה שמראה איך אפשר לעשות את זה. דוגמה למדיניות בחלון זמנים מפורטת במסמכי העזרה של SystemUpdatePolicy.

// Create the system update policy to postpone installation for 30 days.
val policy = SystemUpdatePolicy.createPostponeInstallPolicy()

// Get a DevicePolicyManager instance to set the policy on the device.
val dpm = context.getSystemService(Context.DEVICE_POLICY_SERVICE)
        as DevicePolicyManager
val adminName = getComponentName(context)

// Set the policy.
dpm.setSystemUpdatePolicy(adminName, policy)

// Create the system update policy to postpone installation for 30 days.
SystemUpdatePolicy policy = SystemUpdatePolicy.createPostponeInstallPolicy();

// Get a DevicePolicyManager instance to set the policy on the device.
DevicePolicyManager dpm = (DevicePolicyManager) context
    .getSystemService(Context.DEVICE_POLICY_SERVICE);
ComponentName adminName = getComponentName(context);

// Set the policy.
dpm.setSystemUpdatePolicy(adminName, policy);

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

אפליקציות יכולות להתקשר למספר getSystemUpdatePolicy() כדי לקבל המדיניות הנוכחית של המכשיר. אם ה-method הזה מחזיר את הערך null, סימן שאין מדיניות מוגדרת כרגע.

תקופות הקפאה

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

• המכשיר לא מקבל התראות לגבי עדכוני מערכת בהמתנה.
• עדכוני המערכת למערכת ההפעלה אינם מותקנים.
• משתמשי המכשיר לא יכולים לבדוק באופן ידני אם יש עדכוני מערכת בהגדרות.

המערכת אוכפת תקופת 'מאגר' של 60 יום לאחר תקופות הקפאה מוגדרות, כדי למנוע הקפאה של המכשיר ללא הגבלת זמן. חשוב לזכור, מערכת קופאת עדכונים מסוימים עלולים למנוע ממכשירים לקבל עדכונים קריטיים.

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

איך מגדירים תקופת הקפאה

אפשר להגדיר תקופות הקפאה ב-Android 9 (רמת API 28) ואילך. מכשיר הבעלים מגדיר תקופת הקפאה של מדיניות עדכון מערכת לפני הגדרת המדיניות עבור המכשיר. השלבים הם:

1. יוצרים מדיניות חדשה (או מקבלים את המדיניות הנוכחית) בנושא עדכוני מערכת.
2. כדי להגדיר את תקופות ההקפאה של המדיניות, מבצעים קריאה setFreezePeriods()
3. אפשר להגדיר את המדיניות ולהקפיא את תקופות ההקפאה של המכשיר באמצעות קריאה setSystemUpdatePolicy()

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

// Get the existing policy from the DevicePolicyController instance.
val policy = dpm.systemUpdatePolicy ?: return

try {
    // Set the two annual freeze periods on the policy for our retail
    // point-of-sale devices.
    val summerSale = FreezePeriod(
            MonthDay.of(6, 1),
            MonthDay.of(7, 31)) // Jun 1 - Jul 31 inclusive
    val winterSale = FreezePeriod(
            MonthDay.of(11, 20),
            MonthDay.of(1, 12)) // Nov 20 - Jan 12 inclusive
    policy.freezePeriods = Arrays.asList(summerSale, winterSale)

    // Set the policy again to activate the freeze periods.
    dpm.setSystemUpdatePolicy(adminName, policy)

} catch (e: SystemUpdatePolicy.ValidationFailedException) {
    // There must be previous periods recorded on the device because
    // summerSale and winterSale don’t overlap and are separated by more
    // than 60 days. Report the overlap ...
}

// Get the existing policy from the DevicePolicyController instance.
SystemUpdatePolicy policy = dpm.getSystemUpdatePolicy();

try {
  // Set the two annual freeze periods on the policy for our
  // retail point-of-sale devices.
  FreezePeriod summerSale = new FreezePeriod(
      MonthDay.of(6, 1),
      MonthDay.of(7, 31)); // Jun 1 - Jul 31 inclusive
  FreezePeriod winterSale = new FreezePeriod(
      MonthDay.of(11, 20),
      MonthDay.of(1, 12)); // Nov 20 - Jan 12 inclusive
  policy.setFreezePeriods(Arrays.asList(summerSale, winterSale));

  // Don’t forget to set the policy again to activate the freeze periods.
  dpm.setSystemUpdatePolicy(adminName, policy);

} catch (SystemUpdatePolicy.ValidationFailedException e) {
  // There must be previous periods recorded on the device because summerSale
  // and winterSale don’t overlap and are separated by more than 60 days.
  // Report the overlap ...
}

גם יום ההתחלה וגם יום הסיום כוללים את הערכים האלה. אם יום ההתחלה גדול מיום הסיום (למשל winterSale בדוגמה הקודמת), תקופת ההקפאה נמשכת גם לשנה הבאה.

כשמגדירים הקפאה פרקי זמן מסוימים של מדיניות עדכוני מערכת, מערכת Android בודקת את הדרישות הבאות:

• אין תקופת הקפאה שנמשכת יותר מ-90 יום.
• המרווח בין תקופות ההקפאה הוא 60 יום לפחות.
• תקופות ההקפאה לא חופפות.
• אין תקופות הקפאה כפולות.

כשמגדירים את מדיניות עדכון המערכת למכשיר, מערכת Android חוזרת על הבדיקות האלה והוא כולל תקופות הקפאה נוכחיות או קודמות במכשיר.

אם אחת מהבדיקות האלה נכשלת, מערכת Android תציג את השגיאה SystemUpdatePolicy.ValidationFailedException.

כדי לקבל רשימה של תקופות ההקפאה שהוגדרו בעבר באובייקט של מדיניות עדכוני המערכת, כל האפליקציות המותקנות יכולות להפעיל את SystemUpdatePolicy.getFreezePeriods(). הבאים לדוגמה, קוראים לשיטה הזו כדי לתעד תקופות הקפאה של מכשיר:

// Log any freeze periods that might be set on a system update policy.
dpm.systemUpdatePolicy?.freezePeriods?.forEach {
    Log.i(TAG, "Freeze period: $it")
}

// Log any freeze periods that might be set on a system update policy.
SystemUpdatePolicy currentPolicy = dpm.getSystemUpdatePolicy();
if (currentPolicy != null) { // A policy might not be set.
  for (FreezePeriod freezePeriod : currentPolicy.getFreezePeriods()) {
    Log.i(TAG, "Freeze period: " + freezePeriod.toString());
  }
}

שנים מעוברות

מערכת Android משתמשת בלוח השנה לפי תקן ISO 8601 (שנקרא גם לוח שנה גרגוריאני) כדי: מחשבים תקופות הקפאה ומתעלמים משנים מעוברות. כלומר, 29 בפברואר אינו מוכר כתאריך חוקי, והמערכת מתייחסת אליו כאילו היה 28 בפברואר. לכן, 29 בפברואר לא נספרים בחישוב משך ההקפאה של התקופה.

פיתוח ובדיקה

במהלך הפיתוח והבדיקה של תכונת עדכון המערכת של בקר ה-DPC, ייתכן צריכות ליצור הרבה תקופות קיפאון. כי ב-Android מתבצעת בדיקה של פרק זמן של 60 יום בין תקופות הקפאה קודמות, יכול להיות שלא תוכלו להגדיר תקופת הקפאה חדשה בלי לנקות קודם את התיעוד של תקופות קודמות. כדי למחוק את הרשומה של תקופת ההקפאה של המכשיר, מריצים את הפקודה הבאה במעטפת Android Debug Bridge‏ (adb):

adb shell dpm clear-freeze-period-record

אפשר לוודא שמכשיר נמצא בתקופת הקפאה על ידי בדיקה שהמשתמש הממשק לעדכוני מערכת מושבת.

עדכוני מערכת של Google Play (Mainline)

עדכוני מערכת של Google Play (שנקראים גם עדכוני Mainline) מורידים באופן אוטומטי, אבל כדי להתקין אותם צריך להפעיל מחדש את המכשיר. האלה העדכונים לא יפעילו הפעלה מחדש באופן אוטומטי, ובמקום זאת הם מותקנים ההפעלה מחדש של המשתמש, האדמין או המדיניות הבאים הופעלה. הפעלות מחדש שמתרחשות כתוצאה ממדיניות עדכון המערכת יגרמו להתקנה של עדכון המערכת המשויך של Google או של יצרן הציוד המקורי (OEM), ושל כל עדכוני המערכת של Google Play שהורדתם בעבר.

אפשר גם להתקין עדכוני מערכת של Google Play באופן ידני. לשם כך, עוברים אל הגדרות > מידע כללי > גרסת Android > עדכון מערכת של Google Play.

החזרת עדכון לגרסה קודמת

במקרים מסוימים, אפשר להשתמש בכלי לחזרה לגרסאות קודמות (GPSUR) של Google Play משמש לשחזור מצב המכשיר בעקבות עדכון מערכת בעייתי של Google Play בתהליך ההתקנה. משתמשים מתקדמים צריכים להשתמש בכלי הזה או כשהוא צריך לעשות זאת ולכן צוות התמיכה עלול לגרום לאובדן נתונים. כך משתמשים בכלי GPSUR:

1. אם הגשר לניפוי באגים ב-Android (adb) פועל במחשב, יש להפסיק את שירות ה-adb לפני שממשיכים כדי שלא יפריע תהליך החזרה למצב הקודם. כדי להפסיק את adb, מריצים את adb kill-server.
2. פותחים את הכלי GPSUR.
3. לוחצים על Allow ADB access כדי לאפשר לכלי לתקשר עם מכשיר הבדיקה דרך adb.
4. לוחצים על הוספת מכשיר חדש.
5. בוחרים את המכשיר מהרשימה ולוחצים על קישור. ייתכן שהרשימה הזו לא לכלול את השם המלא של המכשיר.
6. במסך המכשיר, בוחרים באפשרות תמיד לאפשר מהמחשב הזה ולוחצים על אישור כדי לקבל את החיבור לניפוי באגים ב-USB.
7. בוחרים בדפדפן את המכשיר המחובר.
8. טקסט הלחצן בדף צריך להשתנות מאין אפשרויות החזרה זמינות ל- להחזיר את העדכונים האחרונים אם יש חזרות זמינות במכשיר. לוחצים על ביטול העדכונים האחרונים.
9. קוראים את האזהרות בחלון אישור החזרה למצב קודם ולוחצים על אישור.
10. ממתינים לסיום החזרה לאחור. בסיום, תוצג תיבת דו-שיח עם הכיתוב Rollback Successful והמכשיר יופעל מחדש. עכשיו אפשר לנתק את במכשיר.

מקורות מידע נוספים

מידע נוסף על עדכוני מערכת זמין במסמכים של עדכוני OTA בפרויקט Android Open Source.