時區規則

Android 10 淘汰了 APK 式時區資料 更新機制 (適用於 Android 8.1 和 Android 9) 並替換為 APEX 式模組更新機制。 Android 開放原始碼計畫 8.1 至 13 仍包含原始設備製造商 (OEM) 進行啟用所需的平台程式碼 以 APK 為基礎的更新，因此可升級至 Android 10 的裝置 仍可透過 APK 接收合作夥伴提供的時區資料更新。 不過，請勿在正式版裝置上使用 APK 更新機制 也會以 APK 型更新的形式接收模組更新，而不是 以 APEX 為基礎的更新 (也就是收到 APK 更新的裝置會遭到忽略) 以 APEX 為基礎的更新)。

時區更新 (Android 10 以上版本)

Android 10 和 Android 裝置的日光節約時間 (DST) 和時區更新率較高， 對宗教、政治及 都屬於地緣政治因素

更新程序會使用以下程序：

1. 愛荷華州 會釋出時區資料庫的更新版本，以因應 一或多家政府變更其所在國家/地區的時區規則。
2. Google 或 Android 合作夥伴準備更新「時區資料」模組 (APEX 檔案)。
3. 使用者裝置下載更新、重新啟動，然後套用 變更，如果過後裝置的時區資料包含新的時區， 更新資料。

如要進一步瞭解模組，請參閱 模組化系統元件。

時區更新 (Android 8.1–9)

注意：APK 式時區資料更新機制功能 已從 Android 14 以上版本中徹底移除，但無法在 原始碼合作夥伴應完整遷移至 時區 主系列模組。

在 Android 8.1 和 Android 9 中，原始設備製造商 (OEM) 可使用以 APK 為基礎的機制 更新時區規則資料，而且不需更新。 此機制可讓使用者及時收到更新，進而擴充 Android 裝置的有效生命週期)，並讓 Android 合作夥伴能夠進行測試 時區更新，不受系統映像檔更新影響。

Android 核心程式庫團隊提供必要的資料檔案 在庫存的 Android 裝置上更新時區規則。原始設備製造商 (OEM) 可以選擇 資料檔案，以便為裝置建立時區更新， 自己的資料檔案無論是哪種情況，原始設備製造商 (OEM) 仍保有品質控制權 確保其時區規則的更新保證/測試、時機和啟動 支援的裝置。

Android 時區原始碼和資料

所有庫存的 Android 裝置 (包括未使用這項功能的裝置) 都需要時區 規則資料，且必須符合 /system 個分區。接著，由 Android 原始碼樹狀結構中的下列程式庫：

• 來自 libcore/ 的代管程式碼 (例如 java.util.TimeZone) 使用 tzdata 和 tzlookup.xml 檔案。
• bionic/ 中的原生資料庫程式碼 (例如 mktime 時，本機系統呼叫) 會使用 tzdata 檔案。
• external/icu/ 中的 ICU4J/ICU4C 程式庫程式碼使用 icu .dat 檔案。

這些程式庫會追蹤 /data/misc/zoneinfo/current 目錄內。應有重疊檔案 納入改良的時區規則資料，因此裝置可以進行更新 而無須變更 /system。

需要時區規則資料的 Android 系統元件檢查下列項目 將位置放在最前面：

• libcore/ 和 bionic/ 程式碼會使用 /data 的「tzdata」和「tzlookup.xml」副本 檔案。
• ICU4J/ICU4C 程式碼使用 /data 中的檔案，並改回使用 /system 檔案適用於不存在的資料 (適用於格式，並進行本地化處理) 字串等)。

Distro 檔案

Distro .zip 檔案，內含填入 /data/misc/zoneinfo/current 目錄內。發行版檔案 包含可讓裝置偵測版本管理問題的中繼資料。

發行的檔案格式取決於 Android 發布的內容，因為 ICU 版本、Android 平台要求和其他版本異動 並輸入變更內容Android 會為每個系統支援的 Android 版本提供 Distro 檔案。 IANA 更新 (連同更新平台系統檔案除外)。為了保留 裝置就會保持最新狀態，原始設備製造商 (OEM) 可以使用這些 Distro 檔案，也可以利用 Android 原始碼樹狀結構 (內含 會產生 Distro 檔案)。

時區更新元件

時區規則更新牽涉到將永久性檔案傳輸至 並將內的檔案以安全方式安裝。轉移並 安裝需要下列項目：

• 平台服務功能 (timezone.RulesManagerService)、 這個選項預設為停用原始設備製造商 (OEM) 必須透過設定啟用此功能。 RulesManagerService 會在系統伺服器程序和階段中執行 透過寫入 /data/misc/zoneinfo/staged。「RulesManagerService」可以 取代或刪除已經準備的作業
• TimeZoneUpdater、 無法更新的系統應用程式 (又稱為 Updater 應用程式)。原始設備製造商 (OEM) 必須在系統映像檔中加入這個應用程式 這項功能
• OEM TimeZoneData、 可更新的系統應用程式 (即 資料應用程式)，可傳送發行檔案到裝置上 。原始設備製造商 (OEM) 必須將這個應用程式加入 使用這項功能的裝置
• tzdatacheck、 啟動時間二進位檔，才能正確且安全地更新時區。

Android 原始碼樹狀結構包含上述項目的一般原始碼 元件，原始設備製造商 (OEM) 可以選擇直接使用，不做任何修改。 測試代碼 可讓原始設備製造商 (OEM) 自動檢查 他們是否正確啟用這項功能

復古安裝

發行版本安裝程序包含下列步驟：

1. 透過應用程式商店下載或更新資料應用程式 側載。系統伺服器程序 (透過 timezone.RulesManagerServer/timezone.PackageTracker 個類別) 監控所設定 OEM 專屬資料應用程式套件的變更 名稱。
   
   

   圖 1. 資料應用程式更新。

2. 系統伺服器程序會觸發更新檢查，方法是 透過不重複的單次使用權杖向 Updater 播送指定意圖 申請系統伺服器會追蹤它的最新憑證， 可判斷最近一次觸發檢查的完成時間；任何其他 就會被忽略。
   
   

   圖 2. 觸發更新檢查。

3. 在更新檢查期間，Updater 應用程式會執行 幾項工作：
   • 呼叫 RulesManagerService 來查詢目前的裝置狀態。
     
     

     圖 3. 資料應用程式更新，呼叫 RulesManagerService。

   • 查詢定義完善的 ContentProvider 網址，進而查詢資料應用程式 資料欄規格，取得發行版相關資訊。
     
     

     圖 4. 更新資料應用程式，取得發行相關資訊。

4. Updater 應用程式會根據 所需資訊可執行的動作包括：
   • 要求安裝。透過「資料」應用程式讀取 Distro 資料 並傳送到系統伺服器中的 RulesManagerService。 RulesManagerService 再次確認發行格式版本和內容 每個外掛程式的版本
   • 要求解除安裝 (這種情況相當少見)。舉例來說， 正在停用或解除安裝「/data」中的 APK，且裝置符合下列條件 返回 /system 中的版本。
   • 不採取任何行動。當資料應用程式發行版本無效時，就會發生這個問題。
   ，瞭解如何調查及移除這項存取權。 在所有情況下，Updater 應用程式都會使用檢查權杖呼叫 RulesManagerService 讓系統伺服器知道檢查是否已完成且成功。
   
   

   圖 5. 檢查完成，

5. 重新啟動並 tzdatacheck。裝置下次啟動時， tzdatacheck 二進位檔會執行任何階段作業。tzdatacheck 二進位檔可以 執行下列工作：
   • 處理建立、取代、 和/或刪除 /data/misc/zoneinfo/current 個檔案 其他系統元件也已開啟並開始使用這些檔案。
   • 確認「/data」中的檔案是否正確 平台版本；如果裝置剛收到 系統更新和 Distro 格式版本變更。
   • 確認 IANA 規則版本與 /system。防止系統更新離開裝置 時區規則資料比 /system中顯示的舊 圖片。

可靠性

端對端安裝程序非同步，在三個 OS 之間分割 作業。在安裝過程中，裝置隨時都可能會沒電， 或發生其他問題，導致安裝作業檢查 不完整。在最好的情況下失敗的情況下，Updater 應用程式會通知系統 伺服器更新失敗是最糟糕的情況 RulesManagerService 完全沒有收到任何呼叫。

為處理這種情況，系統伺服器程式碼會持續追蹤 更新檢查已完成，以及上次檢查的資料版本代碼 應用程式當裝置處於閒置和充電狀態時，系統伺服器程式碼可以檢查 目前狀態如果發現更新檢查不完整或非預期的資料 應用程式版本，系統會主動觸發更新檢查。

安全性

啟用後，系統伺服器中的 RulesManagerService 程式碼會執行 進行多項檢查，確保系統安全無虞。

• 問題表示設定錯誤的系統映像檔導致裝置無法使用 啟動中；這些情況包括：錯誤的 Updater、Data 應用程式設定，或 更新程式或資料應用程式目前不在 /system/priv-app 中。
• 即使問題指出已安裝錯誤資料應用程式， 裝置正在啟動，但不會觸發更新檢查。例子 缺少必要的系統權限，或者「資料」應用程式不會公開 所預期 URI 上的 ContentProvider。

/data/misc/zoneinfo 目錄的檔案權限如下： 執行 SELinux 規則與任何 APK 一樣，「資料」應用程式必須由 用於簽署 /system/priv-app 版本的金鑰「資料」應用程式 應該會有專屬的原始設備製造商 (OEM) 專屬套件名稱和金鑰。

整合時區更新

如要啟用時區更新功能，原始設備製造商 (OEM) 通常會：

• 建立自己的資料應用程式。
• 在系統映像檔版本中加入 Updater 和資料應用程式。
• 設定系統伺服器以啟用 RulesManagerService。

準備

開始之前，原始設備製造商 (OEM) 應詳閱以下政策、品質保證政策、 和安全性考量等

• 為資料應用程式建立專屬的應用程式專屬簽署金鑰。
• 針對時區更新建立版本和版本管理策略 以便瞭解哪些裝置即將更新，以及如何確保 而且只會安裝在需要更新的裝置上。舉例來說，原始設備製造商 為所有裝置使用同一個資料應用程式，或在不同裝置上建立 適用於不同裝置的資料應用程式。這項決策會影響套件的選擇 名稱，可能是使用的版本代碼，以及 QA 策略。
• 瞭解他們是否想要使用 Android 現有時區資料 或自行建立

建立資料應用程式

Android 開放原始碼計畫包含建立資料應用程式所需的所有原始碼和建構規則 packages/apps/TimeZoneData，包含操作說明和範例範本 適用於「AndroidManifest.xml」和其他 packages/apps/TimeZoneData/oem_template。範例範本包括 一個是實際資料應用程式 APK 的建構目標，以及 建立測試版資料應用程式的測試版。

原始設備製造商 (OEM) 可使用自家應用程式的圖示、名稱、翻譯和 。不過，由於資料應用程式無法啟動， (位於「設定」>「應用程式畫面。

資料應用程式旨在以 tapas 版本建構 產生的 APK 適合新增至系統映像檔 (適用於 並透過應用程式商店簽署及發行 (以便後續使用) 更新)。如需使用西班牙語的詳細資訊，請參閱建立 使用 Tapas 的資料應用程式。

原始設備製造商 (OEM) 必須在裝置的系統映像檔中，安裝預先建構的資料應用程式： /system/priv-app。如要加入預先建立的 APK (由輕觸連結產生的 APK) 建立程序)，因此原始設備製造商 (OEM) 可將範例檔案複製到 packages/apps/TimeZoneData/oem_template/data_app_prebuilt。 範例範本也會包含建構目標， 測試套件中的資料應用程式。

在系統映像檔中加入 Updater 和資料應用程式

原始設備製造商 (OEM) 必須將更新程式和資料應用程式 APK 系統映像檔的 /system/priv-app 目錄。如要這麼做， 系統映像檔版本必須明確包含 Updater 應用程式和預先建構的「資料」應用程式 目標。

請使用平台金鑰簽署 Updater 應用程式，連同任何 和其他系統應用程式定義位於 以 TimeZoneUpdater 格式顯示 packages/apps/TimeZoneUpdater。 資料應用程式納入作業須視原始設備製造商 (OEM) 指定，取決於為 預先建構。

設定系統伺服器

如要啟用時區更新功能，原始設備製造商 (OEM) 可透過以下方式設定系統伺服器： 覆寫 Deployment 中定義的設定屬性 frameworks/base/core/res/res/values/config.xml。

config_enableUpdateableTimeZoneRules

config_timeZoneRulesUpdateTrackingEnabled

config_timeZoneRulesDataPackage

config_timeZoneRulesUpdaterPackage

config_timeZoneRulesCheckTimeMillisAllowed

config_timeZoneRulesCheckRetryCount

設定覆寫應位於系統映像檔 (而非供應商或其他) 中 因為設定錯誤的裝置可能會拒絕啟動。如果設定覆寫 位在供應商映像檔中，更新為沒有資料應用程式的系統映像檔 (或 不同資料應用程式/更新程式應用程式套件名稱) 以及設定錯誤

XTS 測試

xTS 是指任何與標準 Android 類似的原始設備製造商 (OEM) 專用測試套件 測試套件，例如 CTS 和 VTS。進行這類測試的原始設備製造商 (OEM) 套件可提供 Android 時區更新測試，如下所示： 地區：

• packages/apps/TimeZoneData/testing/xts 包含程式碼 進行基本自動化功能測試
• packages/apps/TimeZoneData/oem_template/xts 包含範例 目錄結構，在類似 Tradefed xTS 套件中加入測試。如同 其他範本目錄，原始設備製造商 (OEM) 應複製並自訂 系統會按照資料類型和業務需求 將資料儲存到不同類型的儲存空間
• packages/apps/TimeZoneData/oem_template/data_app_prebuilt 包含建構期間設定，可以納入必要的預先建構測試 APK 。

建立時區更新

當 IANA 釋出一組新的時區規則時，Android 核心程式庫就是其中之一 團隊會產生 Android 開放原始碼計畫更新版本的修補程式。使用存貨 Android 的原始設備製造商 (OEM) 系統和發行版本檔案可以接收這些修訂版本 的「資料」應用程式版本，接著發布新版本來更新裝置 。

由於資料應用程式包含與 Android 版本密切相關的 Distro 檔案， 原始設備製造商 (OEM) 必須針對「所有」支援的「所有」裝置，建立新版資料應用程式 原始設備製造商 (OEM) 要更新的 Android 版本。舉例來說，如果原始設備製造商 提供適用於 Android 8.1、9 和 10 的更新 裝置必須完成三次這個程序。

步驟 1：更新系統/時區和外部/icu 資料檔案

在這個步驟中，原始設備製造商 (OEM) 會接受 Android 承諾， system/timezone和external/icu (來自 release-dev 分支版本，並將修訂版本套用至 Android 原始碼

系統/時區 Android 開放原始碼計畫修補程式，包含在 「system/timezone/input_data」和 system/timezone/output_data。需要在當地製作其他區域的原始設備製造商 (OEM) 修正程式會修改輸入檔案 system/timezone/input_data，external/icu到 產生檔案output_data。

最重要的檔案是 system/timezone/output_data/distro/distro.zip，也就是 建立資料應用程式 APK 時即會自動加入。

步驟 2：更新資料應用程式的版本代碼

在這個步驟中，原始設備製造商 (OEM) 會更新資料應用程式的版本代碼。建構作業 會自動選擇 distro.zip，不過新版的 資料應用程式必須採用新的版本代碼，以便系統認定應用程式為新版本，並用於 將預先載入的「資料」應用程式或裝置上安裝的「資料」應用程式 更新。

使用從以下位置複製的檔案建構資料應用程式時 package/apps/TimeZoneData/oem_template/data_app，您可以在 Android.mk 中套用至 APK 的版本代碼/版本名稱：

TIME_ZONE_DATA_APP_VERSION_CODE :=
TIME_ZONE_DATA_APP_VERSION_NAME :=

您可以在 testing/Android.mk 中找到類似項目 (不過， 測試版本代碼必須高於系統映像檔版本)。詳情 請參閱範例版本代碼策略 配置；如果使用範例配置或類似配置，則測試 版本代碼保證會高於 真正的版本代碼。

步驟 3：重建、簽署、測試並發布

在這個步驟中，原始設備製造商 (OEM) 會使用 Tapas 重建 APK，並簽署產生的 ，然後測試並發布 APK：

• 適用於尚未發布的裝置 (或準備為 已發布裝置)，請在 Data app 預先建構目錄中提交新的 APK 確保系統映像檔和 xTS 測試都有最新的 APK。原始設備製造商 測試新檔案是否正常運作 (即通過 CTS 及任何 原始設備製造商 (OEM) 專用的自動化和手動測試)。
• 如果是不再收到系統更新的已發布裝置，則已簽署的 APK 只會透過應用程式商店發布

原始設備製造商 (OEM) 會負責確保品質及測試 在發布前在裝置上使用資料應用程式。

資料應用程式版本代碼策略

「資料」應用程式必須具備 適合 版本管理策略，確保裝置接收正確的 APK。適用對象 舉例來說，如果收到的系統更新含有比舊版 APK 更舊的 應用程式從應用程式商店下載後，應保留應用程式商店的版本。

APK 版本代碼應包含下列資訊：

• Distro 格式版本 (主要 + 次要)
• 遞增 (不透明) 版本號碼

目前平台 API 級別與反轉格式版本密切相關 因為每個 API 級別通常都與新版 ICU 相關聯 會導致 Distro 檔案不相容)。日後 Android 可能會變更這項設定 發行版檔案可在多種 Android 平台版本 (和 API) 中運作 未用於資料應用程式版本的代碼配置中)。

版本代碼策略範例

這個範例版本編號架構可確保 「版本」會取代較低發行的發行版本 AndroidManifest.xml使用 android:minSdkVersion： 確保舊裝置不會接收到較舊懷舊格式的版本 超乎預期的版本

圖 6. 範例版本代碼策略。

如果使用二進位而非小數，配置會更好，但 這種配置的優點在於人類可讀如果完整數字範圍 用盡，資料應用程式套件名稱可能會變更。

版本名稱是人類可讀的詳細資料表示法， 範例：major=001,minor=001,iana=2017a, revision=1,respin=2。 範例如下表所示。

• 範例 1 和 2 顯示同一個 2017a IANA 版本的兩個 APK 版本 不同的主要格式版本2 以數字表示 1 高於 1 以便確保新裝置收到的格式版本較高。 minSdkVersion 確保不會將 P 版本提供給 O 裝置。
• 範例 3 是 1 的修訂版本/修正，數字大於 1。
• 範例 4 和 5 顯示 O-MR1 和 P 的 2017b 版本。以數字表示 就會取代 IANA 先前的版本/各自版本的 Android 修訂版本 前身。
• 範例 6 和 7 顯示 O-MR1 和 P 的 2018a 版本。
• 範例 8 示範如何使用 Y 完全取代 Y=0 配置。
• 範例 9 示範如何使用 3 到 4 之間的空隙來重新固定 這兩個 APK

由於每部裝置都會在 系統映像檔，因此不會在 P 裝置上安裝 O-MR1 版本 因為版本號碼低於 P 系統映像檔版本A 罩杯 裝置 (在 /data 中安裝 O-MR1 版本)，之後會接收 P 的系統更新會優先使用 /system 版本 /data 中的 O-MR1 版本，因為 P 版本一律較高 而不是任何 O-MR1 的應用程式

使用 Tapas 建構資料應用程式

原始設備製造商 (OEM) 負責管理大多數時區「資料」應用程式 才能正確設定系統映像檔資料應用程式的用途是 提供的 tapas 版本會產生適合加入應用程式的 APK 安裝系統映像檔 (適用於初始版本) 並透過 應用程式商店 (供後續更新使用)。

Tapas 是 Android 版本的精簡版本 我們使用縮減原始碼樹狀圖產生可發布的可散發版本 應用程式。熟悉一般 Android 建構系統的原始設備製造商 (OEM) 應可辨識 從一般 Android 平台版本建構檔案

建立資訊清單

通常使用自訂資訊清單檔案來縮減來源樹狀結構， 只指建構系統和建構 應用程式。按照 建立資料應用程式，原始設備製造商 (OEM) 應 至少有兩個原始設備製造商 (OEM) 專用的 Git 專案 packages/apps/TimeZoneData/oem_template:

• 一個 Git 專案含有應用程式檔案，例如資訊清單和 建立應用程式 APK 檔案所需的版本檔案 (例如 vendor/oem/apps/TimeZoneData)。這項專案也 包含測試 APK 的建構規則，可供 xTS 測試使用。
• 一個 Git 專案包含由應用程式版本產生的已簽署 APK 納入系統映像檔建構和 xTS 測試中

應用程式版本會使用其他幾項與 或包含獨立原始設備製造商 (OEM) 的程式碼程式庫。

以下資訊清單程式碼片段包含最精簡的 Git 專案組合 ，以便支援時區資料應用程式的 O-MR1 版本。原始設備製造商 必須新增原始設備製造商 (OEM) 專用的 Git 專案 (通常包括 含有簽署憑證)，可能會 分支

   <!-- Tapas Build -->
    <project
        path="build"
        name="platform/build">
        <copyfile src="core/root.mk" dest="Makefile" />
    </project>
    <project
        path="prebuilts/build-tools"
        name="platform/prebuilts/build-tools"
        clone-depth="1" />
    <project
        path="prebuilts/go/linux-x86"
        name="platform/prebuilts/go/linux-x86"
        clone-depth="1" />
    <project
        path="build/blueprint"
        name="platform/build/blueprint" />
    <project
        path="build/kati"
        name="platform/build/kati" />
    <project
        path="build/soong"
        name="platform/build/soong">
        <linkfile src="root.bp" dest="Android.bp" />
        <linkfile src="bootstrap.bash" dest="bootstrap.bash" />
    </project>

    <!-- SDK for system / public API stubs -->
    <project
        path="prebuilts/sdk"
        name="platform/prebuilts/sdk"
        clone-depth="1" />
    <!-- App source -->
    <project
        path="system/timezone"
        name="platform/system/timezone" />
    <project
        path="packages/apps/TimeZoneData"
        name="platform/packages/apps/TimeZoneData" />
    <!-- Enable repohooks -->
    <project
        path="tools/repohooks"
        name="platform/tools/repohooks"
        revision="main"
        clone_depth="1" />
    <repo-hooks
        in-project="platform/tools/repohooks"
        enabled-list="pre-upload" />

執行點按版本

建立來源樹狀結構後，請叫用 tapas 版本 使用下列指令：

source build/envsetup.sh
tapas
make -j30 showcommands dist TARGET_BUILD_APPS='TimeZoneData TimeZoneData_test1 TimeZoneData_test2'  TARGET_BUILD_VARIANT=userdebug

成功的建構作業會在 out/dist 目錄中產生 進行測試。這些檔案可放入預先建構的目錄，以便納入 系統映像檔和/或透過應用程式商店發布， 裝置。