時區選項

準確顯示時間是車輛資訊娛樂系統的核心功能。這看似簡單，尤其是在時間和時區管理方面的期望不高，且必須符合這些期望時，但如果必須顯示準確的日期和時間，且不得手動介入，時間就會變得複雜。

晶片系統 (SoC) 中通常使用的所有即時時鐘都含有一些漂移，這些漂移會隨著時間累積，如果未修正，可能會導致重大錯誤。此外，由於使用者期望系統能準確顯示當地時間，因此必須考量與世界標準時間 (UTC) 的正確時差。

在車輛的預期使用壽命期間，時區資訊和日光節約時間 (DST) 適用情形可能會變更。舉例來說，巴西實施日光節約時間多年後，於 2019 年決定不啟動日光節約時間排程。

Android 提供必要的基礎架構，可處理時區規則管理相關的複雜問題。詳情請參閱「時區規則」，瞭解如何讓原始設備製造商 (OEM) 將更新的時區規則資料推送至裝置，而不必更新系統。這項機制可提供以下優勢：

  • 使用者可及時取得更新 (延長 Android 裝置的使用壽命)。
  • 原始設備製造商 (OEM) 可獨立測試時區更新，不必與系統映像檔更新一併測試。

注意：AAOS 10 不支援 Android 10 (以上版本) 中提供的 APEX 型模組更新機制。

注意：如要實作這項機制，必須重新啟動系統。

車輛中的時區資訊來源

Android 裝置會在系統層級管理 Unix 時間，套用所需的時區偏移量，然後將值轉換為當地時間，供使用者查看。目前使用者的時區 ID (通常稱為 Olson ID) 會儲存為設定。例如「Europe/London」。

下文所述的機制大多與時間資訊有關。這些標準的目的是為使用者提供目前時間，而非說明適用的時區規則。如要判斷實際時區，裝置必須先根據國家/地區、時差和日光節約時間時差等因素，回溯時區 ID 設定前的時間。

這項程序可能很困難。根據現有資訊回溯可能會有模糊不清之處。舉例來說，America/Denver 時區規則會遵守日光節約時間，但在夏季會採用山區日光節約時間 (MDT)，而 America/Phoenix 則會繼續採用 MDT。

行動無線電

系統資訊 (SI) 是長期演進技術 (LTE) 空中介面的重要環節，由基地台 (BS) 透過廣播控制通道 (BCCH) 傳輸。3GPP TS 36.331 規格會指定 SystemInformationBlockType16 (SIB16)，其中包含與 GPS 和世界標準時間 (UTC) 相關的資訊、當地時間時差，以及日光節約時間資訊。

2G 和 3G 也提供類似功能，可播送網路 ID 和時區 (NITZ) 資訊 (詳情請參閱 3GPP TS 22.042)。其他行動無線電標準也有類似功能。

可惜的是，大多數標準的共同點是傳送這項資訊為選用功能，因此並非所有網路都提供這項功能。

優點 缺點
  • 盡可能提供所需資訊。
  • 簡化作業，Android 已經支援將行動無線電視為手機，而不只是資料數據機。
  • 不需要網路連線。

  • 無法保證資訊會廣播，也無法保證基地台已正確設定。

  • 在邊境地區，手機可能會連上鄰近國家/地區的 (漫遊) 行動基地台，因此可能傳送錯誤的時區。

  • 在某些地區，更新作業可能需要數小時，甚至數天才能完成。

網路時間通訊協定

網路時間通訊協定 (NTP) 通常用於取得相對精確的 Unix 紀元時間資訊。如果可以透過一般 RadioTuner.getParameters() 中繼資料向 RadioManager 用戶端公開，Android 支援將系統時間與 NTP 伺服器時間同步。如果系統時間不同步，且電信業者最近未提供 NITZ 更新，NTP 就會更新系統時間。如果使用者在 NITZ 無法使用時啟用 AUTO_TIME，系統會立即檢查網路時間。

優點 缺點

簡單易用，支援 Android。

  • 不完整，NTP 只提供一個必要值 (時間)。即使在最佳情況下，NTP 也無法提供時區。

  • 必須連上網路。

廣播電台調諧器

雖然使用內建調諧器擷取時間和時區資訊很吸引人，但這項做法會遇到一些挑戰。許多無線電廣播標準都定義了公開所需資訊的選項。一般來說，廣播電台調諧器提供的資訊與行動無線電相同。

ETSI EN 300 401 V1.4.1 (2006-06) 第 8.1 節規定了服務資訊功能，可為數位音訊廣播 (DAB) 系統的音訊節目和資料提供服務的補充資訊。第 8.1.3 節定義了時間和日期的格式，以及國家/地區和當地時差的資訊。

同樣地，對於 FM 收音機中常見的無線電資料系統 (RDS)，EN 50067 標準的第 3.1.5.6 節定義了時鐘時間和資料的格式 (每分鐘傳輸一次)。此外，擴充國家/地區代碼 (ECC) 也可做為傳輸的節目識別資訊。

HD Radio 包含相應選項，這些選項是「Station Information Service (SIS) Parameter Message (MSG ID 0111)」規格中「HD Radio™ Air Interface Design Description Station Information Service Transport」的一部分。第 5 節清楚列出警示字詞，嘗試使用廣播的時鐘支援時，務必留意這些字詞。這項智慧同樣適用於其他系統：

...這些資料說明廣播者所在位置的當地習俗，可能與接收者所在位置的當地習俗相同或不同。在時區邊界附近，消費者可能會收到多個電台提供的不同資料。因此，這些資料僅供參考，客戶應自行斟酌解讀及運用。..."

此外，至少就 HD Radio 而言，這項資訊的廣播是選用功能，不應完全依賴。

優點 缺點
  • 通常適用於不同區域的廣播電台標準。
  • 不需要網路連線。
  • Android 不支援這項功能。
  • 必須開啟調諧器 (至少偶爾在背景執行)，才能可靠地偵測資訊。

  • 可靠性取決於廣播員。

導入提示

如果 Android 可以向 RadioManager 用戶端公開，就能與 NTP 伺服器同步處理系統時間。建議您使用供應商擴充功能。 這項功能的實作作業必須在硬體抽象層 (HAL) 中進行，之後即可透過一般 RadioTuner.getParameters() 方法，向 RadioManager 的用戶端公開。

為確保解決方案的穩定性，這項廠商擴充功能的消費者必須判斷 HAL 是否支援這項功能 (請勿假設 HAL 支援)。getParameters 呼叫的參數字串必須井然有序，確保供應商能明確使用。舉例來說，您可以為機構的命名空間加上適當網域的前置字串，例如 com.me.timezoneTuner.currenttimezone。

由於這類資訊是以事件為導向，因此建議使用 RadioTuner.Callback.onParametersUpdated() 回呼來接收這類資訊。如果這項設施應可設定，請在 setParameters 的基礎上設計一組自訂常式。例如：

com.me.timezoneTuner.currenttimezoneEvent.enable

全球導航衛星系統 (GNSS) 本身只能提供準確的時間資訊和位置。

地理位置

為解決這項不便，您可以執行反向地理編碼，並根據位置查閱國家/地區和時區。GNSS 是車輛位置資訊的明顯 (也是最佳品質) 選擇。Google 的時區 API 提供執行必要轉換的所有功能。當然，你必須連上網路。導入線上解決方案時，請務必將保障使用者隱私權列為首要之務！您必須要求使用者授權接受 (或拒絕) 資料用量費用。

因此可以為離線使用情境打造合適的解決方案。解析度足夠精確判斷國家/地區和時區的本機地圖資料庫，可儲存在車輛的儲存空間中。有了這項功能，並全面實作視需要更新時區 (和國家/地區) 資訊的策略後，即可根據從 Location 子系統取得的 GNSS 位置，反向地理編碼國家/地區/時區。

優點 缺點
  • 可明確判斷正確時區。
  • 不需要網路連線 (如果是本機資料庫)。
  • 在大多數駕駛情境中都能穩定運作。
  • Android 不支援這項功能。
  • 如果車輛位於室內/有遮蔽的區域，無法在初始設定期間接收良好的 GNSS 衛星訊號，系統就無法取得準確的時間、位置和時區資訊。
  • 本機資料庫需要更新機制。
  • 導入複雜度。

透過藍牙、Wi-Fi 或 USB 連線的手機

您可以運用多種技術，透過使用者的手機取得時間和時區資料。 在所有手機上，手機和車載資訊娛樂 (IVI) 系統都必須安裝一組自訂應用程式和隨附應用程式。然後就能以所需間隔同步時間。舉例來說，建立連線後，手機偵測到新的時區時，

部分支援藍牙低功耗 (BLE) 的手機提供透過 GATT Current Time 特徵和 Current Time Service Profile Specification 1.1 擷取時間的選項。不過，這個選項無法涵蓋足夠大的市場區隔，因此不宜單獨使用。

優點 缺點
  • 不需要網路連線。
  • 手機偵測到的時區變更會轉送至車載主機。
  • Android 不支援這項功能。
  • 手機必須連線至車載主機，才能使用這項功能。
  • 時間的準確度與手機提供的時間相同。
  • 實作過程複雜。
  • 並非所有手機都支援 BLE GATT Current Time Service 設定檔。

使用來源

每個裝置供應商都必須決定要設定多高的標準，以及要將哪些使用者歷程視為最重要。只有清楚瞭解所需的重要使用者體驗，才能做出最佳決策。在大多數情況下，供應商必須考量便利性和實作複雜度之間的取捨。

上述每個選項都有優缺點。舉例來說，相較於偶爾顯示不準確的時間，可接受的復原力程度為何，以及如何管理缺點，都必須做出關鍵設計選擇。全自動解決方案，可望在所有情境中正常運作，但必須根據多個資訊來源的組合。沒有任何單一選項可提供 100% 可用性。

手動設定選項可做為暫時的回溯方式，執行起來很簡單，而且實際上對許多使用者來說已足夠。