托管更新作業 (Hosting Updates)

本文節錄自 B2G/Updating

托管更新作業 (Hosting Updates)

其實亦可解釋為:用戶端針對更新檔案所進行的輪詢作業。

B2G 用戶端針對更新所執行的輪詢 (Poll),即針對 update manifest 檔案進行提取 (Fetching) 與剖析 (Parsing)。此檔案即稱為「update.xml」。

B2G 用戶端均已完成「輪詢特定伺服器上的更新」的設定,亦將查詢伺服器上特別架構而成的路徑。而我們建議透過 HTTPS 協定 (當然 HTTP 亦支援),讓用戶端查詢伺服器。若現有用戶端更改了輪詢程式碼,則只要將一筆更新傳送至此用戶端,即可針對「用戶端所輪詢過的路徑與伺服器」進行變更。

在下列範例中,我們假設將更新作業托管 (Hosting) 給 updates.b2g.com 伺服器。

則由用戶端所輪詢的 URL,主要可用下列參數呈現:

PRODUCT_MODEL

裝置型號的名稱。此為 B2G 屬性資料庫中的 ro.product.model 數值。

CHANNEL

更新「頻道」,有助於測試作業。舉例來說,我們可設定伺服器托管「nightly」、「beta」、「release」等頻道。

VERSION

此為用戶端的軟體版本,此以「18.0.2」為例。

BUILD_ID

專屬 ID,如針對特定軟體版本 (Build) 所設的時間戳記。

當然另有許多數值,可為查詢作業建構出更新用的 URL。

B2G 用戶端隨後將整合「本身已設定的更新主機」的數值,搭配上述的相關數值,進而建構出 URL,以於執行期間執行輪詢作業。

此 URL 範例可為:

https://updates.b2g.com/release/unagi1/18.0/20121203123456/update.xml

 

針對用戶端的請求,若伺服器回傳「404 Not Found」,即代表目前並無可用的更新;若回傳「200」與 manifest 檔案,則代表可能有更新。該 manifest 檔案將描述可用的新版本,亦即用戶端目前應該更新的版本。此 manifest 檔案範例為:

<?xml version="1.0"?>
<updates>
  <update type="major" appVersion="19.0" version="19.0" extensionVersion="19.0" buildID="20121210123456"
          licenseURL="http://www.mozilla.com/test/sample-eula.html"
          detailsURL="http://www.mozilla.com/test/sample-details.html">
    <patch type="partial" URL="https://updates.b2g.com/release/unagi1/18.0/20121203123456/update.mar"
           hashFunction="SHA512" hashValue="5111e033875752b7d9b32b4795152dea5ef954cb8a9d4a602dd19a923b464c43521287dcb5781faf3af76e6dc5e8a3dd9c13edea18c1f2c8f3bd89e17d103d6f"
           size="41901319"/>
  </update>
</updates>

而 manifest 檔案中的欄位則描述了:

  • 可於用戶端顯示使用者介面的後設資料 (Metadata)
  • 關於可用新版本的後設資料
  • 更新封裝的位置
  • 用以驗證更新裝包下載作業的後設資料

當然,使用者或用戶端裝置可能會拒絕更新作業。

透過這些機制,伺服器將可托管更新封裝,以利舊版用戶端的更新作業。或可僅托管「線性更新歷史紀錄 (Linear update history)」,讓用戶端必須透過單一路徑完成升級。

針對「版本 (Build) 伺服器」和「更新主機」之間的互動細節,仍與作業環境息息相關。本文尚不足以詳細解說完畢。

 

文件標籤與貢獻者

 此頁面的貢獻者: chrisdavidmills, MashKao
 最近更新: chrisdavidmills,