時區選項

準確的時間顯示是汽車資訊娛樂系統的核心功能。雖然這可能看起來很簡單，特別是當時間和時區管理的期望較低並且必須滿足時，但當必須在沒有手動幹預的情況下顯示可靠準確的日期和時間時，時間很快就會變得複雜。

系統單晶片 (SoC) 中通常使用的所有即時時鐘都包含一些漂移，這些漂移會隨著時間的推移而累積，如果不加以修正，可能會導致嚴重的錯誤。此外，由於人們對準確顯示當地時間的期望很高，因此必須考慮與協調世界時 (UTC) 的正確偏移。

時區資訊以及夏令時 (DST) 的應用預計會在車輛的預期使用壽命期間發生變化。例如，在實施夏令時多年後，巴西選擇在 2019 年不啟動夏令時時間表。

Android 提供了協商時區規則管理複雜性所需的基礎架構。有關詳細信息，請參閱時區規則，它使 OEM 能夠將更新的時區規則資料推送到設備，而無需系統更新。此機制可以：

  • 用戶能夠及時收到更新（這可以延長 Android 裝置的使用壽命）。
  • OEM 可以獨立於系統映像更新來測試時區更新。

注意： AAOS 10 不支援 Android 10（及更高版本）版本中提供的基於 APEX 的模組更新機制。

注意：要實現此機制，需要重新啟動系統。

汽車中的時間（區域）資訊來源

Android 裝置在系統層級管理 Unix 時間的時間，套用所需的時區偏移，然後將該值轉換為本機時間以顯示給使用者。目前使用者的區域 ID（通常稱為 Olson ID）會作為設定儲存。例如，歐洲/倫敦。

下面概述的大部分機制描述了時間資訊。這些標準的目的是向使用者提供當前時間，而不是描述適用的時區規則。要確定實際時區，設備必須在設定區域 ID 之前根據國家/地區、偏移量和 DST 偏移量等因素進行回溯。

這個過程可能是一個挑戰。根據可用資訊進行回溯可能會產生歧義。例如，時區規則 America/Denver 遵守 DST，但在夏季採用山區夏令時 (MDT)，而 America/Phoenix 則繼續承認 MDT。

蜂巢式無線電

系統資訊 (SI) 是長期演進 (LTE) 空中介面的重要方面，由基地台 (BS) 透過廣播控制通道 (BCCH) 傳輸。 3GPP TS 36.331 指定了 SystemInformationBlockType16 (SIB16)，其中包含與 GPS 和協調世界時 (UTC)、本地時間偏移以及 DST 資訊相關的資訊。

類似的功能可以在 2G 和 3G 中找到，其中可以廣播網路身份和時區 (NITZ) 資訊（有關詳細信息，請參閱 3GPP TS 22.042）。其他蜂窩無線電標準具有同等功能。

不幸的是，大多數標準的共同點是該資訊的發送是可選的，因此並非在所有網路上普遍可用。

優點缺點
  • 如果可用，可提供大部分所需資訊。
  • 當蜂窩無線電作為電話而不僅僅是數據調製解調器時，Android 就已經支援簡單性。
  • 不需要網路連線。

  • 不保證訊息被廣播，也不保證基地台配置正確。

  • 在邊境地區，可能會接收來自鄰國的（漫遊）手機訊號塔，並可能傳達錯誤的時區。

  • 在某些位置，更新可能需要數小時甚至數天的時間才能完成。

網路時間協定

網路時間協定 (NTP) 通常用於取得相對精確的 Unix 紀元時間資訊。如果可以透過通用RadioTuner.getParameters()元資料向RadioManager的用戶端公開，Android 支援將其係統時間與 NTP 伺服器的系統時間同步。當 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 包含對應選項，作為電台資訊服務 (SIS) 參數訊息 (MSG ID 0111) 中 HD Radio™ 空中介面設計描述電台資訊服務傳輸規格的一部分。第 5 節清楚地闡明了嘗試使用廣播時鐘支援時必須注意的警告詞。同樣的智慧同樣適用於其他系統：

……這些數據描述了廣播公司所在地的當地習俗，可能與接收者所在地的當地習俗相同，也可能不同。在時區邊界附近，消費者可以接收多個提供不同資料的站點。因此，這些數據僅作為提示提供，其解釋和使用應由客戶自行決定並受客戶控制。 ……”

此外，至少對於 HD Radio 來說，此資訊的廣播是可選的，不應完全依賴。

優點缺點
  • 通常可用於不同地區的廣播無線電標準。
  • 不需要網路連線。
  • Android 不支援此開箱即用。
  • 需要打開調諧器（至少偶爾在後台）才能可靠地檢測資訊。

  • 可靠性取決於廣播公司。

實施技巧

如果 Android 可以暴露給RadioManager的用戶端，則 Android 支援將其係統時間與 NTP 伺服器的系統時間同步。推薦的解決方案是利用供應商擴展功能。此功能的實作必須發生在硬體抽象層 (HAL) 中，之後可以透過通用RadioTuner.getParameters()方法將其公開給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 當前時間特徵和當前時間服務設定檔規格 1.1檢索時間的選項。然而，這種選擇並沒有解決足夠大的、可以完全依賴的細分市場。

優點缺點
  • 不需要網路連線。
  • 電話偵測到的時區變更可以轉送到主機。
  • Android 不支援此開箱即用。
  • 僅當手機連接至主機時才有效。
  • 時間的好壞取決於手機提供的時間。
  • 實施很複雜。
  • 並非所有手機都支援 BLE GATT 當前時間服務設定檔。

使用來源

每個設備供應商都必須確定要設定多高的標準以及哪些用戶旅程被認為是最關鍵的。只有清楚了解所需的關鍵使用者體驗，才能做出最佳決策。在大多數情況下，供應商必須考慮便利性和實施複雜性之間的權衡。

上述每個選項都有優點和缺點。例如，必須做出關鍵的設計選擇，考慮到與偶爾的不良時間顯示相比，多大的彈性是可以接受的，以及如何管理缺點。全自動解決方案可以在所有場景中正常運行，但必須基於多個資訊來源的組合。沒有任何一個選項可以提供 100% 的可用性。

作為臨時後備的手動配置選項很容易執行，並且在實踐中對於許多用戶來說已經足夠了。