הדף הזה הוא חלק מהתיעוד של פלטפורמת אפליקציות Chrome, שהוצאה משימוש בשנת 2020. היא תמשיך לתמוך בלקוחות Enterprise ו-Education ב-ChromeOS עד ינואר 2025 לפחות. מידע נוסף על העברת האפליקציה

דף זה תורגם על ידי Cloud Translation API.

עדכון אוטומטי

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

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

אם אתם מארחים קובץ CRX בשרת אינטרנט ומשתמשים בכללי מדיניות ארגוניים כדי לדחוף אותו למכשירים מנוהלים, כדאי להמשיך לקרוא. מומלץ גם לקרוא את המאמרים אירוח ואריזה.

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

סקירה כללית

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

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

עדכון כתובת URL

אם אתם מארחים תוסף או אפליקציה משלכם, עליכם להוסיף את השדה update_url לקובץ manifest.json, כך:

{
  "name": "My extension",
  ...
  "update_url": "http://myhost.com/mytestextension/updates.xml",
  ...
}

עדכון המניפסט

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

<?xml version='1.0' encoding='UTF-8'?>
<gupdate xmlns='http://www.google.com/update2/response' protocol='2.0'>
  <app appid='aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa'>
    <updatecheck codebase='http://myhost.com/mytestextension/mte_v2.crx' version='2.0' />
  </app>
</gupdate>

פורמט ה-XML הזה הוא פורמט שמשמש את Omaha, תשתית העדכונים של Google. פרטים נוספים זמינים בכתובת http://code.google.com/p/omaha/. מערכת התוספים משתמשת במאפיינים הבאים לרכיבים <app> ו-<updatecheck> במניפסט העדכון:

appid

מזהה התוסף או האפליקציה, שנוצר על סמך גיבוב של המפתח הציבורי, כפי שמתואר בקטע אריזה. כדי למצוא את המזהה של תוסף או אפליקציה ל-Chrome, עוברים לדף התוספים (chrome://extensions).

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

פותחים את האפליקציה. כדי לעשות זאת, לוחצים על הסמל שלה בדף 'כרטיסייה חדשה'.
פותחים את מסוף JavaScript. כדי לעשות זאת, לוחצים על סמל הבורג ובוחרים באפשרות כלים > מסוף JavaScript.
מזינים את הביטוי הבא במסוף JavaScript: chrome.app.getDetails().id. במסוף יוצג המזהה של האפליקציה כמחרוזת בתוך מירכאות.

codebase

כתובת URL לקובץ .crx.

גרסה

הלקוח משתמש בו כדי לקבוע אם להוריד את קובץ ה-.crx שצוין על ידי codebase. הערך צריך להיות זהה לערך של 'version' בקובץ manifest.json של הקובץ .crx.

קובץ ה-XML של מניפסט העדכון יכול להכיל מידע על כמה תוספים על ידי הכללת כמה רכיבי <app>.

בדיקה

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

שימוש מתקדם: פרמטרים של בקשות

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

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

הפורמט של פרמטרים הבקשה הוא:

?x=_<extension_data>_

כאשר _<extension_data>_ היא מחרוזת בקידוד URL בפורמט:

_id=<id>_&v=_<version>_

לדוגמה, נניח שיש לכם שני תוספי Sitelink, ושניהם מפנים לאותה כתובת URL לעדכון (http://test.com/extension_updates.php):

תוסף 1
- מזהה: "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
- גרסה: '1.1'
תוסף 2
- מזהה: "bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb"
- גרסה: '0.4'

הבקשה לעדכון של כל תוסף בנפרד תהיה:

http://test.com/extension_updates.php?x=id%3Daaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa%26v%3D1.1
http://test.com/extension_updates.php?x=id%3Dbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb%26v%3D0.4

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

http://test.com/extension_updates.php?x=id%3Daaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa%26v%3D1.1&x=id%3Dbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb%26v%3D0.4

אם מספר התוספים המותקנים שמשתמשים באותה כתובת URL לעדכון גדול מספיק וכתובת ה-URL של בקשת ה-GET ארוכה מדי (יותר מ-2,000 תווים בערך), בדיקת העדכון תיצור בקשות GET נוספות לפי הצורך.

שימוש מתקדם: הגרסה המינימלית של הדפדפן

ככל שנוסיף ממשקי API נוספים למערכת התוספים, יכול להיות שתרצו לפרסם גרסה מעודכנת של תוסף או אפליקציה שתפעול רק בגרסאות חדשות יותר של הדפדפן. Google Chrome מתעדכן באופן אוטומטי, אבל יכול להיות שיחלפו כמה ימים עד שרוב בסיס המשתמשים יתעדכן לגרסה החדשה. כדי לוודא שעדכון מסוים יחול רק על גרסאות של Google Chrome בגרסה מסוימת או בגרסה גבוהה יותר, מוסיפים את המאפיין prodversionmin לאלמנט <app> במניפסט העדכון. לדוגמה:

<?xml version='1.0' encoding='UTF-8'?>
<gupdate xmlns='http://www.google.com/update2/response' protocol='2.0'>
  <app appid='aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa'>
    <updatecheck codebase='http://myhost.com/mytestextension/mte_v2.crx' version='2.0' prodversionmin='3.0.193.0'/>
  </app>
</gupdate>

כך תוכלו לוודא שהמשתמשים יקבלו עדכון אוטומטי לגרסה 2 רק אם הם משתמשים ב-Google Chrome בגרסה 3.0.193.0 ואילך.