אמצעי בקרה מאוחדים לעדכונים

אמצעי בקרה מאוחדים לעדכונים (UUC) נותנים לאדמינים ממחלקת ה-IT דרך אחת ועקבית לקבוע מתי עדכוני תוכנה יורדו ויופעלו במכשירי Android שבבעלות החברה, כדי שהעדכונים לא ישבשו את הפעילות העסקית.

באמצעות מדיניות UUC אחת, אתם יכולים לשלוט בעדכונים של רכיבי התוכנה הבאים:

• עדכונים של מערכת ההפעלה שהופצו על ידי יצרן המכשיר (OEM), כולל עדכונים משמעותיים של מערכת ההפעלה ועדכונים קלים של מערכת ההפעלה ועדכוני אבטחה.
• עדכוני מערכת של Google Play (Mainline).
• שירותי המערכת של Google, כמו Google Play Services ו-Android System WebView, כקבוצה או כל אפליקציה בנפרד.

מגדירים את כללי ה-UUC בשדה unifiedUpdatePolicy של משאב Policy. אפליקציית Android Device Policy‏ (ADP) היא נקודת ההחלטה המרכזית במכשיר לגבי UUC.

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

לפני שמגדירים את UUC, צריך לוודא שהדרישות הבאות מתקיימות:

• פתרון ה-EMM שלכם יכול ליצור ולעדכן כללי מדיניות לארגון.
• המכשירים נמצאים בבעלות החברה, ומוגדרים כמכשירים מנוהלים או עם פרופיל עבודה במכשיר בבעלות החברה. אין תמיכה ב-UUC במכשירים בבעלות אישית.
• המכשירים עומדים בדרישות המינימליות של גרסת Android שנתמכת בכל יעד עדכון שרוצים לשלוט בו, כמו שמוצג בטבלה הבאה:

שיקולים ומגבלות

לפני שמתכננים את השילוב של UUC, חשוב לעיין בשיקולים ובמגבלות הבאים:

• אשף ההגדרה הראשונית: כללי המדיניות של UUC לא נאכפים כשהמכשיר נמצא באשף ההגדרה הראשונית. עדכונים קריטיים מ-Google Play או מסוכן ה-OTA של ה-OEM יכולים להתרחש במהלך הגדרת המכשיר.
• עדכונים מוקדמים אחרי ההגדרה: יכול להיות שכללי המדיניות של UUC לא יחולו על עדכונים אוטומטיים שמתחילים מיד אחרי הגדרת המכשיר, כמו עדכונים מוקדמים של Google Play Services, לפני שהמדיניות מגיעה ל-ADP.
• מודולים של עדכוני OTA בחבילה: עדכוני OTA של OEM יכולים להכיל גרסאות מעודכנות של מודולים של Mainline ושירותי המערכת של Google. כשמתקינים עדכון OTA של OEM, הרכיבים האלה מתעדכנים אוטומטית.
• עדכוני מערכת של Google Play‏ (Mainline): שירות UUC שולט בעדכון Mainline כיחידה אחת, כך שאי אפשר לשלוט בחבילות Mainline נפרדות באופן עצמאי. ה-UUC שולט רק בתחילת שלב ההורדה: אחרי שההורדה של Mainline מתחילה, אי אפשר לעצור אותה. אם כלל BLOCK מוחל אחרי שההורדה מתחילה, העדכון עדיין יושלם בהפעלה מחדש הבאה של המכשיר.
• עדכונים ידניים במהלך תקופות חסימה: לגבי עדכוני המערכת של Google Play (Mainline) ושירותי המערכת של Google, כלל BLOCK מונע רק עדכונים אוטומטיים. המשתמשים עדיין יכולים לעדכן את הרכיבים האלה באופן ידני גם כשכלל BLOCK פעיל. הבעיה הזו תטופל באחת מהגרסאות הבאות.
• אפליקציות פטורות: שירות UUC לא מנהל עדכונים לאפליקציית חנות Google Play או לאפליקציית ADP.

הסבר על המדיניות בנושא תוכן שנוצר על ידי משתמשים לא מאומתים (UUC)

UnifiedUpdatePolicy מורכב מרשימה מסודרת של אובייקטים מסוג Rule. כל כלל מציין:

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

הערכת הכלל

כשהמערכת בודקת עדכון בהמתנה, היא מתייחסת לכל הכללים שחלים על היעד והשלב של העדכון, לפי הסדר שבו הם מופיעים ב-rules. ‫ADP בוחר את הכלל הראשון שהפרדיקט שלו מקבל את הערך true ומחיל את התוצאה שלו, כמו הצהרת if-else משורשרת. אם הפרדיקט של אף כלל לא מקבל את הערך true, לקוח העדכון שאחראי לרכיב מנהל את העדכון כרגיל.

מזהי כללים

כל כלל דורש id של עד 64 תווים שמוגדר על ידי פתרון ה-EMM. השדה id לא יכול להיות ריק, והערך שלו חייב להיות ייחודי בין הכללים של המדיניות.

עדכון היעדים

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

בטבלה הבאה מתוארים הערכים הנתמכים של targetType:

שלבי ההערכה

ביעד OS_UPDATE_WITH_API_LEVEL_CHANGE וביעד OS_UPDATE_WITHOUT_API_LEVEL_CHANGE, אפשר לציין את stages שבו הכלל נבדק:

• ‫STAGE_DOWNLOAD: הכלל נבדק לפני הורדת העדכון.
• ‫STAGE_APPLY: הכלל נבדק לפני ביצוע פעולה שמחילה את העדכון, כמו הפעלה של אתחול אוטומטי.

אם stages ריק, הכלל נבדק בכל השלבים. הערה: ביעדים מסוג GOOGLE_SYSTEM_SERVICES,‏ SINGLE_APP ו-GOOGLE_PLAY_SYSTEM_UPDATE, המערכת מתעלמת מהשלבים.

פרדיקטים

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

כל התנאים שמוגדרים בפרדיקט אחד משולבים באמצעות AND לוגי. פרדיקט ריק או מושמט תמיד מקבל את הערך true. הרשימה המלאה של שדות הפרדיקט והמגבלות שלהם מופיעה בPredicate.

תוצאות

הערך של outcome קובע איך ADP מורה לסוכן העדכון להמשיך כשתוצאת הבדיקה של הפרדיקט של הכלל היא true. בטבלה הבאה מפורטים הערכים הנתמכים של outcomeType:

מגבלות דחייה מקסימליות

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

בטבלה הבאה מפורטות מגבלות הדחייה המקסימליות לפי יעד ומצב ניהול:

סדר הקדימות של systemUpdate

לפני שמוסיפים את unifiedUpdatePolicy למדיניות קיימת, צריך לבדוק את ההגדרות של systemUpdate וליצור מחדש את ההתנהגות הרצויה באמצעות כללי UUC. לדוגמה, כדי למנוע עדכונים של מערכת ההפעלה בשעות הפעילות, אפשר להשתמש בכלל BLOCK כמו הכלל שמופיע בקטע חסימת עדכונים משמעותיים של מערכת ההפעלה בשעות הפעילות.

ההתנהגות הזו שונה מבקרי DPC בהתאמה אישית שמשתמשים ב-AMAPI SDK, שבהם SystemUpdatePolicy של AOSP מקבל עדיפות על פני UUC לעדכוני OTA של OEM. פרטים נוספים זמינים במאמר קדימות של SystemUpdatePolicy ב-AOSP.

הגדרת המדיניות של UUC

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

הגדרת מדיניות ה-UUC

כדי להגדיר את UUC, מוסיפים אובייקט unifiedUpdatePolicy למדיניות. כדי להחיל את מדיניות ה-UUC בלי לשנות את ההגדרות האחרות של מדיניות קיימת, צריך להפעיל את enterprises.policies.patch עם updateMask=unifiedUpdatePolicy:

PATCH https://androidmanagement.googleapis.com/v1/enterprises/{enterpriseId}/policies/{policyId}?updateMask=unifiedUpdatePolicy

{
  "unifiedUpdatePolicy": {
    "rules": [
      {
        "id": "Block Policy",
        "targets": [
          {
            "targetType": "OS_UPDATE_WITH_API_LEVEL_CHANGE"
          }
        ],
        "predicate": {
          "daysOfWeek": [
            "MONDAY",
            "TUESDAY",
            "WEDNESDAY",
            "THURSDAY",
            "FRIDAY"
          ],
          "timeOfDayLowerBound": { "hours": 9 },
          "timeOfDayUpperBound": { "hours": 17 }
        },
        "outcome": {
          "outcomeType": "BLOCK"
        }
      }
    ]
  }
}

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

אחזור המדיניות של UUC

כדי לקרוא את כללי ה-UUC שהוגדרו, מפעילים את enterprises.policies.get ובודקים את השדה unifiedUpdatePolicy של המדיניות שהוחזרה:

GET https://androidmanagement.googleapis.com/v1/enterprises/{enterpriseId}/policies/{policyId}

ניקוי המדיניות של UUC

כדי להסיר את כל כללי ה-UUC ממדיניות, מפעילים את enterprises.policies.patch עם updateMask=unifiedUpdatePolicy וגוף בקשה שלא מכיל את unifiedUpdatePolicy:

PATCH https://androidmanagement.googleapis.com/v1/enterprises/{enterpriseId}/policies/{policyId}?updateMask=unifiedUpdatePolicy

{}

דוגמאות להגדרת מדיניות

הדוגמאות הבאות מציגות את האובייקט unifiedUpdatePolicy בתרחישים נפוצים. מחילים אותם באמצעות enterprises.policies.patch, כמו שמתואר במאמר הגדרת מדיניות ה-UUC. אותם תרחישים זמינים כקוד Kotlin ו-Java במאמר הגדרת פקדי עדכון מאוחדים באמצעות AMAPI SDK.

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

הכלל הבא חוסם עדכונים משמעותיים של מערכת ההפעלה (OS_UPDATE_WITH_API_LEVEL_CHANGE) מ-09:00 עד 17:00, בימים שני עד שישי:

{
  "unifiedUpdatePolicy": {
    "rules": [
      {
        "id": "Block Policy",
        "targets": [
          {
            "targetType": "OS_UPDATE_WITH_API_LEVEL_CHANGE"
          }
        ],
        "predicate": {
          "daysOfWeek": [
            "MONDAY",
            "TUESDAY",
            "WEDNESDAY",
            "THURSDAY",
            "FRIDAY"
          ],
          "timeOfDayLowerBound": { "hours": 9 },
          "timeOfDayUpperBound": { "hours": 17 }
        },
        "outcome": {
          "outcomeType": "BLOCK"
        }
      }
    ]
  }
}

אילוץ עדכונים של מערכת ההפעלה לפי משך הזמן שחלף מאז העדכון האחרון

הכלל הבא מאלץ עדכונים משמעותיים של מערכת ההפעלה שזמינים למכשיר עד 7 ימים (604800s):

{
  "unifiedUpdatePolicy": {
    "rules": [
      {
        "id": "Force Policy",
        "targets": [
          {
            "targetType": "OS_UPDATE_WITH_API_LEVEL_CHANGE"
          }
        ],
        "predicate": {
          "updateAgeUpperBound": "604800s"
        },
        "outcome": {
          "outcomeType": "FORCE"
        }
      }
    ]
  }
}

חסימת עדכונים לאפליקציה אחת של שירותי המערכת של Google

כדי לשלוט באפליקציה ספציפית שהיא חלק משירותי המערכת של Google, כמו Android System WebView (com.google.android.webview), מגדירים את targetType בתור SINGLE_APP ומציינים את ה-packageName של האפליקציה ב-singleApp. הכלל הבא חוסם עדכונים של WebView מ-09:00 עד 17:00, בימים שני עד שישי:

{
  "unifiedUpdatePolicy": {
    "rules": [
      {
        "id": "Block Webview Policy",
        "targets": [
          {
            "targetType": "SINGLE_APP",
            "singleApp": {
              "packageName": "com.google.android.webview"
            }
          }
        ],
        "predicate": {
          "daysOfWeek": [
            "MONDAY",
            "TUESDAY",
            "WEDNESDAY",
            "THURSDAY",
            "FRIDAY"
          ],
          "timeOfDayLowerBound": { "hours": 9 },
          "timeOfDayUpperBound": { "hours": 17 }
        },
        "outcome": {
          "outcomeType": "BLOCK"
        }
      }
    ]
  }
}

שילוב של כמה כללים בכל יעדי העדכון

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

בדוגמה הבאה, שני כללים רציפים חלים על ארבעת יעדי הקטגוריות (OS_UPDATE_WITH_API_LEVEL_CHANGE,‏ OS_UPDATE_WITHOUT_API_LEVEL_CHANGE,‏ GOOGLE_SYSTEM_SERVICES ו-GOOGLE_PLAY_SYSTEM_UPDATE):

1. חסימת כל העדכונים במהלך שעות הפעילות (שני עד שישי, 09:00 עד 17:00).
2. מחוץ לשעות הפעילות, לאלץ עדכונים שזמינים עד 7 ימים.

{
  "unifiedUpdatePolicy": {
    "rules": [
      {
        "id": "Block Policy - rule1",
        "targets": [
          { "targetType": "OS_UPDATE_WITH_API_LEVEL_CHANGE" },
          { "targetType": "OS_UPDATE_WITHOUT_API_LEVEL_CHANGE" },
          { "targetType": "GOOGLE_SYSTEM_SERVICES" },
          { "targetType": "GOOGLE_PLAY_SYSTEM_UPDATE" }
        ],
        "predicate": {
          "daysOfWeek": [
            "MONDAY",
            "TUESDAY",
            "WEDNESDAY",
            "THURSDAY",
            "FRIDAY"
          ],
          "timeOfDayLowerBound": { "hours": 9 },
          "timeOfDayUpperBound": { "hours": 17 }
        },
        "outcome": {
          "outcomeType": "BLOCK"
        }
      },
      {
        "id": "Force Policy - rule2",
        "targets": [
          { "targetType": "OS_UPDATE_WITH_API_LEVEL_CHANGE" },
          { "targetType": "OS_UPDATE_WITHOUT_API_LEVEL_CHANGE" },
          { "targetType": "GOOGLE_SYSTEM_SERVICES" },
          { "targetType": "GOOGLE_PLAY_SYSTEM_UPDATE" }
        ],
        "predicate": {
          "updateAgeUpperBound": "604800s"
        },
        "outcome": {
          "outcomeType": "FORCE"
        }
      }
    ]
  }
}

הגבלת העדכונים עד לתאריך מסוים

אפשר להשתמש ב-dateLowerBound וב-dateUpperBound כדי להגביל או לאפשר עדכונים בטווח תאריכים ספציפי ביומן, באזור הזמן המקומי של המכשיר. הכלל הבא חוסם עדכונים של ארבעת יעדי הקטגוריות עד 14 במרץ 2026:

{
  "unifiedUpdatePolicy": {
    "rules": [
      {
        "id": "block_until_date",
        "targets": [
          { "targetType": "OS_UPDATE_WITH_API_LEVEL_CHANGE" },
          { "targetType": "OS_UPDATE_WITHOUT_API_LEVEL_CHANGE" },
          { "targetType": "GOOGLE_SYSTEM_SERVICES" },
          { "targetType": "GOOGLE_PLAY_SYSTEM_UPDATE" }
        ],
        "predicate": {
          "dateUpperBound": { "year": 2026, "month": 3, "day": 14 }
        },
        "outcome": {
          "outcomeType": "BLOCK"
        }
      }
    ]
  }
}