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

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

מבוא

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

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

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

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

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

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

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

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

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

Kotlin

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

Java

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). הדוגמה הבאה מראה איך לעשות זאת:

Kotlin

/**
 * 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.
        // ...
    }
}

Java

/**
 * 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 יום. התקופה מתחילה אחרי קודם המערכת דוחה את העדכון והגדרה של כללי מדיניות דחייה חדשים לא להאריך את פרק הזמן.

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

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

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

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

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

Kotlin

// 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)

Java

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

תקופות הקפאה

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

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

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

איור 1. הוגדרו שתי תקופות הקפאה למכשיר

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

איך להגדיר תקופת הקפאה

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

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

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

Kotlin

// 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 ...
}

Java

// 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() הבאים לדוגמה, קוראים לשיטה הזו כדי לתעד תקופות הקפאה של מכשיר:

Kotlin

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

Java

// 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 (ראשי)

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

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

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

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