時區選項

準確顯示時間是車輛資訊娛樂系統的核心功能。雖然這聽起來似乎很簡單，尤其是在時間和時區管理的預期值偏低且必須符合這些預期值的情況下，但如果必須在沒有人工介入的情況下，顯示可靠且準確的日期和時間，時間就會變得複雜。

所有通常用於晶片系統 (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) 是 Long-Term Evolution (LTE) 無線介面的必要元素，由基地台 (BS) 透過廣播控制通道 (BCCH) 傳送。3GPP TS 36.331 會指定 SystemInformationBlockType16 (SIB16)，其中包含與 GPS 和世界標準時間 (UTC)、當地時間偏移以及夏令時間資訊相關的資訊。

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

不幸的是，大多數標準的共通點是傳送這類資訊屬於選用，因此並非所有網路都支援。

優點 缺點
  • 提供大部分所需資訊 (如有)。
  • 簡單來說，當行動無線電以手機形式公開時，Android 已支援這項功能，而非僅限於資料數據機。
  • 不需要連上網際網路。

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

  • 在邊境地區，可能會接收鄰近國家/地區的 (漫遊) 基地台，並傳送錯誤的時區。

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

網路時間通訊協定

網路時間通訊協定 (NTP) 通常用於取得相對精確的 Unix 紀元時間資訊。如果 Android 可透過一般 RadioTuner.getParameters() 中繼資料，將系統時間與 NTP 伺服器的時間同步，則可向 RadioManager 的用戶端公開。當系統時間不同步，且最近未收到電信業者提供的 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 節定義了時鐘時間和資料的格式 (每分鐘傳送一次)。此外，系統也可以在傳送的節目 ID 中擷取擴充國家/地區代碼 (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() 方法，將 if 公開給 RadioManager 的用戶端。

為了讓解決方案保持健全，此廠商擴充功能的使用者必須判斷 HAL 是否支援該功能 (不要假設其存在)。getParameters 呼叫的參數字串必須經過妥善安排，才能在各供應商之間確保使用無誤。例如，使用貴機構的命名空間，並在前面加上適當的網域，例如 com.me.timezoneTuner.currenttimezone。

由於資訊具有事件驅動性質，因此使用 RadioTuner.Callback.onParametersUpdated() 回呼來接收這項資訊可能會有所助益。如果這個設施應可設定，請在 setParameters 之上設計一組自訂例行程序。例如：

com.me.timezoneTuner.currenttimezoneEvent.enable

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

地理位置

解決這個問題的方法是執行反向地理編碼，並根據位置執行查詢，判斷國家/地區和時區。在車輛中，GNSS 是位置資訊的明顯 (也是最佳品質) 選擇。Google 的 時區 API 提供執行必要轉換所需的所有內容。當然，你必須連上網際網路。導入線上解決方案時，務必優先保障使用者隱私！您必須要求使用者授權，才能讓他們接受 (或拒絕) 資料使用費用。

您可以建立適合離線使用的解決方案。本機地圖資料庫具有足夠的解析度，可準確判斷國家/地區和時區，並可儲存在車輛的儲存空間中。有了這項功能，加上完整實作的策略，可視需要更新時區 (和國家/地區) 資訊，進而根據從位置子系統取得的 GNSS 位置，為國家/地區/時區反向地理編碼。

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

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

您可以使用多種技術，利用使用者的手機取得時間和時區資料。對於所有手機，您必須在手機和車內資訊娛樂系統 (IVI) 系統上安裝一組自訂應用程式和隨附應用程式。接著，您就可以在所需間隔時間內同步處理時間。例如在建立連線時，以及手機偵測到新的時區時。

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

優點 缺點
  • 不需要連上網際網路。
  • 手機偵測到時區變更時，可以將資訊轉送至車用主機。
  • Android 並未預先支援這項功能。
  • 只有在手機連上車用主機時才有效。
  • 時間是好是壞，取決於手機提供的服務。
  • 實作方式相當複雜。
  • 並非所有手機都支援 BLE GATT 目前時間服務設定檔。

使用來源

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

上述每個選項各有優缺點。舉例來說，您必須做出關鍵的設計選擇，決定在經常出現不良時間顯示的情況下，您能接受的彈性程度為何，以及如何因應缺點。全自動解決方案可在所有情境下正常運作，但必須結合多個資訊來源。沒有任何選項可提供 100% 的可用性。

手動設定選項可做為暫時備用方案，執行起來很簡單，而且在實際情況下，對許多使用者來說都足夠了。