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

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

מבוא

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

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

טבלה 1: המשימות שזמינות לבקרי DPC תלויות במצב הבעלים

חיפוש עדכונים בהמתנה

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

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

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

אחרי שמתקשרים אל 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));
}

קריאות חזרה למערכת

כשעדכון זמין, מערכת 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 (שנקראים גם עדכוני ראשי) יורדות באופן אוטומטי, אבל צריך להתקין מחדש את המכשיר. האלה העדכונים לא יפעילו הפעלה מחדש באופן אוטומטי, ובמקום זאת הם מותקנים ההפעלה מחדש של המשתמש, האדמין או המדיניות הבאים הופעלה. הפעלות מחדש שמתרחשות כתוצאה ממדיניות עדכון המערכת יגרמו להתקנה של עדכון המערכת המשויך של Google או של יצרן הציוד המקורי (OEM), ושל כל עדכוני המערכת של Google Play שהורדתם בעבר.

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

ביטול עדכון

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

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

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

למידע נוסף על עדכוני מערכת, אפשר לקרוא את OTA בפרויקט קוד פתוח של Android תיעוד של עדכונים.