時區規則

Android 10 淘汰了以 APK 為基礎的時區資料更新機制 (可在 Android 8.1 和 Android 9 中使用)，並以 以 APEX 為基礎的模組更新機制取代。AOSP 8.1 到 13 仍包含原始設備製造商 (OEM) 啟用以 APK 為基礎的更新所需的平台程式碼，因此升級至 Android 10 的裝置仍可透過 APK 接收合作夥伴提供的時區資料更新。不過，如果正式版裝置同時接收模組更新，則不應使用 APK 更新機制，因為以 APK 為基礎的更新會取代以 APEX 為基礎的更新 (也就是說，收到 APK 更新的裝置會忽略以 APEX 為基礎的更新)。

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

Android 10 以上版本支援的時區資料模組會更新 Android 裝置上的日光節約時間 (DST) 和時區，將可能因宗教、政治和地緣政治因素而經常變動的資料標準化。

更新程序如下：

1. IANA 會針對一或多個政府變更所在國家/地區的時區規則，發布時區資料庫更新。
2. Google 或 Android 合作夥伴會準備包含更新時區的 Time Zone Data 模組更新 (APEX 檔案)。
3. 最終使用者的裝置會下載更新、重新啟動，然後套用變更，之後裝置的時區資料就會包含更新中的新時區資料。

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

時區更新 (Android 8.1 至 9)

注意：從 Android 14 起，以 APK 為基礎的時區資料更新機制功能已完全移除，無法在原始碼中找到。合作夥伴應完全遷移至 時區主線模組。

在 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、localtime 系統呼叫) 會使用 tzdata 檔案。
• external/icu/ 中的 ICU4J/ICU4C 程式庫程式碼會使用 icu .dat 檔案。

這些程式庫會追蹤可能位於 /data/misc/zoneinfo/current 目錄中的疊加檔案。疊加檔案應包含改善的時區規則資料，讓裝置能夠更新，而無須變更 /system。

需要時區規則資料的 Android 系統元件會先檢查下列位置：

• libcore/ 和 bionic/ 程式碼會使用 tzdata 和 tzlookup.xml 檔案的 /data 副本。
• ICU4J/ICU4C 程式碼會使用 /data 中的檔案，並在沒有資料 (格式、本地化字串等) 時改用 /system 檔案。

Distro 檔案

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

由於內容會隨著 ICU 版本、Android 平台需求和其他版本變更而變更，因此發布檔案格式會依 Android 版本而異。除了更新平台系統檔案外，Android 也會為每項 IANA 更新提供支援的 Android 版本發布檔案。為了讓裝置保持最新狀態，原始設備製造商 (OEM) 可以使用這些發布檔案，或是使用 Android 原始碼樹狀結構 (包含產生發布檔案所需的指令碼和其他檔案) 自行建立檔案。

時區更新元件

時區規則更新作業包括將發布檔案傳送至裝置，以及安全安裝其中的檔案。轉移和安裝作業需要以下項目：

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

Android 來源樹狀結構包含上述元件的一般來源程式碼，原始設備製造商可以選擇使用這些程式碼，無須修改。我們提供測試程式碼，讓原始設備製造商 (OEM) 自動檢查是否已正確啟用這項功能。

Distro 安裝

發布套件安裝程序包括下列步驟：

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

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

2. 系統伺服器程序會觸發更新檢查，方法是向 Updater 應用程式廣播含有專屬單次使用權杖的指定意圖。系統伺服器會追蹤所產生最新的權杖，以便判斷觸發的最新檢查何時完成；任何其他權杖都會遭到忽略。
   
   

   圖 2. 觸發更新檢查。

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

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

   • 透過查詢明確定義的 ContentProvider 網址和資料欄規格，查詢 Data 應用程式，以取得發布資訊。
     
     

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

4. Updater 應用程式會根據所擁有的資訊採取適當行動。可用的動作包括：
   • 申請安裝。系統會從 Data 應用程式讀取 Distro 資料，並將資料傳遞至系統伺服器中的 RulesManagerService。RulesManagerService 會再次確認發布格式版本和內容是否適合裝置，並分階段進行安裝。
   • 要求解除安裝 (這種情況很少發生)。舉例來說，如果 /data 中的更新版 APK 遭到停用或解除安裝，裝置就會回復 /system 中的版本。
   • 不採取任何行動。當系統發現資料應用程式發布無效時，就會發生這個錯誤。
   在所有情況下，Updater 應用程式都會使用檢查權杖呼叫 RulesManagerService，讓系統伺服器知道檢查已完成且成功。
   
   

   圖 5. 檢查完成。

5. 重新啟動並執行 tzdatacheck。裝置下次啟動時，tzdatacheck 二進位檔會執行任何分階段作業。tzdatacheck 二進位檔可執行下列工作：
   • 在其他系統元件開啟並開始使用檔案前，處理 /data/misc/zoneinfo/current 檔案的建立、取代和/或刪除作業，以便執行階段作業。
   • 請確認 /data 中的檔案是否適用於目前的平台版本，如果裝置剛收到系統更新，且發布格式版本已變更，則可能並非如此。
   • 請確認 IANA 規則版本與 /system 中的版本相同或較新。這可防止系統更新導致裝置使用比 /system 映像檔中更舊的時區規則資料。

可靠性

端對端安裝程序為非同步，並分散在三個 OS 程序中。在安裝過程中的任何時間點，裝置都可能沒電、磁碟空間不足或發生其他問題，導致安裝檢查作業無法完成。在最理想的失敗情況下，Updater 應用程式會通知系統伺服器失敗；在最糟糕的失敗情況下，RulesManagerService 完全不會收到呼叫。

為處理這個問題，系統伺服器程式碼會追蹤觸發的更新檢查是否已完成，以及 Data 應用程式上次檢查的版本程式碼為何。當裝置處於閒置狀態並充電時，系統伺服器程式碼可以檢查目前的狀態。如果發現未完成的更新檢查或未預期的 Data 應用程式版本，就會自動觸發更新檢查。

安全性

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

• 系統映像檔設定不良的問題，導致裝置無法開機，例如 Updater 或 Data 應用程式設定不良，或是 Updater 或 Data 應用程式不在 /system/priv-app 中。
• 指出已安裝不良資料應用程式的問題不會阻止裝置啟動，但會阻止觸發更新檢查作業，例如缺少必要的系統權限，或是資料應用程式未在預期的 URI 上公開 ContentProvider。

系統會使用 SELinux 規則強制執行 /data/misc/zoneinfo 目錄的檔案權限。如同任何 APK，資料應用程式必須使用用於簽署 /system/priv-app 版本的相同金鑰進行簽署。資料應用程式應具備專屬的 OEM 專屬套件名稱和金鑰。

整合時區更新

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

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

準備

開始前，原始設備製造商應詳閱下列政策、品質保證和安全性考量事項：

• 為 Data 應用程式建立專屬的應用程式專屬簽署金鑰。
• 建立時區更新的發布和版本策略，瞭解哪些裝置會更新，以及如何確保只在需要的裝置上安裝更新。舉例來說，原始設備製造商 (OEM) 可能會為所有裝置使用單一 Data 應用程式，也可能會為不同裝置使用不同的 Data 應用程式。這項決定會影響套件名稱的選擇 (可能會影響使用的版本代碼) 和品質管理策略。
• 瞭解他們是否想使用 AOSP 的 Android 時區資料，還是想自行建立時區資料。

建立 Data 應用程式

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

原始設備製造商 (OEM) 可以自訂 Data 應用程式，包括圖示、名稱、翻譯和其他詳細資料。不過，由於無法啟動 Data 應用程式，因此圖示只會顯示在「設定」>「應用程式」畫面中。

資料應用程式應使用 tapas 版本進行建構，以產生適合新增至系統映像檔 (初始版本) 的 APK，並透過應用程式商店簽署及發布 (後續更新)。如要進一步瞭解如何使用 tapas，請參閱「使用 tapas 建構 Data 應用程式」。

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

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

原始設備製造商 (OEM) 必須將更新程式和資料應用程式 APK 放在系統映像檔的 /system/priv-app 目錄中。為此，系統映像檔建構作業必須明確納入更新程式應用程式和資料應用程式的預先建構目標。

Updater 應用程式應使用平台金鑰簽署，並納入其他系統應用程式。目標在 packages/apps/TimeZoneUpdater 中定義為 TimeZoneUpdater。資料應用程式納入方式會因原始設備製造商 (OEM) 而異，並取決於預先建構作業所選的目標名稱。

設定系統伺服器

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

config_enableUpdateableTimeZoneRules

config_timeZoneRulesUpdateTrackingEnabled

config_timeZoneRulesDataPackage

config_timeZoneRulesUpdaterPackage

config_timeZoneRulesCheckTimeMillisAllowed

config_timeZoneRulesCheckRetryCount

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

xTS 測試

xTS 是指使用 Tradefed 的任何原始設備製造商 (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 核心程式庫團隊會產生修補程式，以便更新 AOSP 中的版本。使用原生 Android 系統和發布檔案的 OEM 廠商可以挑選這些提交內容，並用來建立 Data 應用程式的新版本，然後發布新版本，以便更新實際工作環境中的裝置。

由於資料應用程式包含與 Android 版本緊密相關的發布檔案，因此原始設備製造商必須為每個原始設備製造商想要更新的支援 Android 版本，建立新版資料應用程式。舉例來說，如果原始設備製造商 (OEM) 想為 Android 8.1、9 和 10 版裝置提供更新，就必須完成這個程序三次。

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

在這個步驟中，原始設備製造商會從 AOSP 的發布-dev 分支中取得 system/timezone 和 external/icu 的 Android 原始版本提交內容，並將這些提交內容套用至 Android 原始碼的副本。

系統/時區 AOSP 修補程式包含 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：更新 Data 應用程式的版本代碼

在這一步中，原始設備製造商會更新 Data 應用程式的版本代碼。建構作業會自動挑選 distro.zip，但新版 Data 應用程式必須具備新版本代碼，才能讓系統將其視為新版，並用於取代預先載入的 Data 應用程式，或在裝置上透過先前更新安裝的 Data 應用程式。

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

TIME_ZONE_DATA_APP_VERSION_CODE :=
TIME_ZONE_DATA_APP_VERSION_NAME :=

您可以在 testing/Android.mk 中找到類似的項目 (但測試版本代碼必須高於系統映像檔版本)。如需詳細資訊，請參閱版本代碼策略範例配置。如果使用範例配置或類似配置，測試版本代碼就不需要更新，因為這些代碼一定會高於實際版本代碼。

步驟 3：重新建構、簽署、測試及發布

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

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

OEM 廠商負責在發布前，為更新版 Data 應用程式進行品質保證和測試。

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

Data 應用程式必須採用適當的版本策略，確保裝置能收到正確的 APK。舉例來說，如果收到的系統更新包含的 APK 版本比從應用程式商店下載的版本還舊，則應保留應用程式商店版本。

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

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

目前，平台 API 級別與發布格式版本有密切關聯，因為每個 API 級別通常都與新版 ICU 相關聯 (這會導致發布檔案不相容)。日後，Android 可能會變更這項設定，讓發布檔案可在多個 Android 平台版本上運作 (且 Data 應用程式版本程式碼配置中不會使用 API 級別)。

版本代碼策略範例

這個版本編號系統示例可確保較高版本的發布格式取代較低版本的發布格式。AndroidManifest.xml 會使用 android:minSdkVersion，確保舊裝置不會收到無法處理的較高發布格式版本。

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

如果使用二進位而非十進位，這個配置方案的壓縮效果會更好，但這個配置方案的優點是可供人類閱讀。如果整個數字範圍都已用盡，Data 應用程式套件名稱可能會變更。

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

• 範例 1 和 2 顯示同一個 IANA 2017a 版本的兩個 APK 版本，但格式主要版本不同。2 的數值大於 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。

由於每部裝置都會在系統映像檔中提供預設的適當版本 APK，因此不會有在 P 裝置上安裝 O-MR1 版本的風險，因為該版本的版本號碼比 P 系統映像檔版本低。如果裝置在 /data 中安裝 O-MR1 版本，然後收到 P 版系統更新，則會優先使用 /system 版本，而非 /data 中的 O-MR1 版本，因為 P 版本一律高於任何針對 O-MR1 設計的應用程式。

使用 tapas 建構 Data 應用程式

原始設備製造商 (OEM) 負責管理時區資料應用程式的大部分內容，並正確設定系統映像檔。資料應用程式應使用 tapas 版本建構，以產生適合新增至系統映像檔 (初始版本) 的 APK，並透過應用程式商店簽署及發布 (後續更新)。

Tapas 是 Android 建構系統的簡化版本，使用精簡的來源樹狀結構來產生可發布的應用程式版本。熟悉一般 Android 建構系統的 OEM 應能辨識一般 Android 平台版本的建構檔案。

建立資訊清單

要縮減來源樹狀結構，通常會使用自訂資訊清單檔案，該檔案只會參照建構系統和建構應用程式所需的 Git 專案。按照「建立 Data 應用程式」中的操作說明操作後，原始設備製造商 (OEM) 應至少有兩個原始設備製造商專屬的 Git 專案，這些專案是使用 packages/apps/TimeZoneData/oem_template 底下的範本檔案建立：

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

應用程式建構作業會利用與平台建構作業共用的其他幾個 Git 專案，或包含不受 OEM 限制的程式碼程式庫。

下列資訊清單程式碼片段包含支援時區資料應用程式 O-MR1 版本所需的 Git 專案最少數量。原始設備製造商必須將其專屬的 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 版本

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

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

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