時區規則

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. IANA 會針對一或多個政府變更其國家/地區的時區規則，發布時區資料庫更新。
2. Google 或 Android 合作夥伴準備包含更新時區的時區資料模組更新 (APEX 檔案)。
3. 使用者裝置會下載更新並重新啟動，然後套用變更，之後裝置的時區資料就會包含更新後的新時區資料。

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

時區更新 (Android 8.1 至 9)

注意：以 APK 為基礎的時區資料更新機制功能已從 Android 14 以上版本完全移除，在原始碼中找不到這項功能。合作夥伴應完全遷移至 時區 Mainline 模組。

在 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/ 程式碼會使用 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) 可以選擇在不修改的情況下直接使用。我們提供測試程式碼，讓原始設備製造商 (OEM) 自動檢查是否已正確啟用這項功能。

復古安裝

反轉安裝程序包含下列步驟：

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

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

2. 系統伺服器程序會觸發更新檢查，方法是將包含唯一、單次使用權杖的目標意圖廣播至 Updater 應用程式。系統伺服器會追蹤它的最新憑證，以判斷最近一次檢查觸發的時間；系統會忽略任何其他權杖。
   
   

   圖 2. 觸發更新檢查。

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

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

   • 查詢資料應用程式，方法是查詢明確定義的 ContentProvider 網址和資料欄規格，以取得發布相關資訊。
     
     

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

4. Updater 應用程式會根據所擁有的資訊採取適當行動。可執行的操作包括：
   • 申請安裝。系統會從 Data 應用程式讀取 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 完全不會收到任何呼叫。

為處理這個問題，系統伺服器程式碼會追蹤觸發的更新檢查是否已完成，以及資料應用程式上次檢查的版本程式碼為何。當裝置處於閒置狀態並充電時，系統伺服器程式碼可以檢查目前的狀態。如果發現未完成的更新檢查或未預期的 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 應用程式，使用自有的圖示、名稱、翻譯和其他詳細資料。不過，由於資料應用程式無法啟動，該圖示只會顯示在「設定」>「應用程式」畫面中。

資料應用程式應使用 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 應用程式和 Data 應用程式的預先建構目標。

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

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

xTS 測試

xTS 是指任何原始設備製造商 (OEM) 專用的測試套件，與使用 Tradefed 的標準 Android 測試套件類似 (例如 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 資料檔案

在這個步驟中，原始設備製造商 (OEM) 會從 Android 開放原始碼計畫的版本-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 應用程式的版本代碼。建構作業會自動挑選 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，則應保留應用程式商店的版本。

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

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

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

版本代碼策略範例

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

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

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

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

• 範例 1 和 2 顯示同一個 2017a IANA 版本中擁有兩個不同主要格式版本的兩個 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 建構資料應用程式

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

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

建立資訊清單

如要縮減來源樹狀結構，通常使用自訂資訊清單檔案，只參照建構系統和建構應用程式所需的 Git 專案。按照「建立資料應用程式」一文中的操作說明操作後，原始設備製造商 (OEM) 應擁有至少兩個 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 建構作業：

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

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