時區選項

顯示時間準確是汽車資訊娛樂系統的核心功能。 這個說法看起來可能很簡單，尤其是在設定時間和時間時更是如此 區域管理作業的複雜度低且必須滿足 日期和時間必須由無人為介入處理。

所有通常用於晶片系統 (SoC) 的即時時鐘都含有一些偏移， 隨著時間累積，若不修正，就可能引發重大錯誤。此外， 因為消費者期望當地時間越準確， 必須考慮世界標準時間 (UTC)。

時區資訊和應用程式日光節約時間的應用 (DST) 可能會在車輛的預期生命週期內發生變化。舉例來說 導入數位媒體服務 (DST) 的多年，巴西選擇不要在 2019 年開通數位服務稅時程。

Android 提供所需的基礎架構，用於協商時區規則的複雜性 以自動化做法管理成本詳情請參閱 時區規則， 讓原始設備製造商 (OEM) 不必透過系統，就能將更新後的時區規則資料推送到裝置 更新。此機制有助於：

  • 使用者能夠及時收到更新 (延長 Android 裝置的實用生命週期)。
  • 原始設備製造商 (OEM) 可單獨測試時區更新，不受系統映像檔更新影響。

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

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

車輛的時間 (可用區) 資訊來源

Android 裝置會在系統層級管理 Unix 時間、套用你所需的時區偏移 然後將值轉換成當地時間，向使用者顯示廣告。目前使用者的可用區 ID (通常是 稱為 Olson ID) 會以設定的形式儲存。例如「歐洲/倫敦」。

以下介紹的許多機制都描述了時間資訊。這些標準的用意在於 向使用者提供目前時間，而非說明適用的時區規則。為了判斷 裝置的實際時區 偏移值。

整個過程並不容易。根據可用資訊解決問題，可能包括 不明確。例如，時區規則 America/Denver 的時區規則是 DST，但採用高山 夏天的日光時間 (MDT) 與美國/鳳凰城相去，但仍然識別出 MDT。

行動無線電

系統資訊 (SI) 是「長期演化」(LTE) 空氣介面的重要面向 。3GPP TS 36.331 會指定 SystemInformationBlockType16 (SIB16)，其中包含 GPS 相關資訊 和世界標準時間 (UTC)、當地時間偏移，以及 DST 資訊。

另外，2G 和 3G 也具備類似功能，包括網路身分和時區 (NITZ) 的資訊可播送 (詳情請參閱 3GPP TS 22.042)。其他手機無線電標準 功能

遺憾的是，大多數標準常見的規定是在傳送這些資訊時， 因此不一定適用於所有聯播網。

優點 缺點
  • 盡可能提供最符合需求的資訊。
  • 為簡單易用，Android 已內建於手機中的行動網路收音機，而非這項功能 但事實上只會做為資料數據機使用
  • 「不」需要網際網路連線。

  • 無法保證資訊能夠播送，亦不保證基地站正常 專案。

  • 在邊界地區內，需負責從鄰近國家/地區領取 (漫遊) 行動通信基地台 且可能傳送的時區有誤

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

網路時間通訊協定

網路時間通訊協定 (NTP) 通常用於取得相對精確的 Unix 紀元時間 可能不準確或不適當Android 支援將系統時間與 NTP 伺服器同步 是否能向 RadioManager 適用於一般 RadioTuner.getParameters() 中繼資料。NTP 會在停止運作時更新系統時間 同步，以及電信業者最近沒有提供 NITZ 更新。如果使用者啟用 如果 NITZ 無法使用，系統會立即檢查網路：AUTO_TIME 讓應用程式從可以最快做出回應的位置 回應使用者要求

優點 缺點

簡單易用，由 Android 提供支援。

  • 未完成。NTP 僅提供一個必要值 (時間)。即使在最美好的情況下 NTP 無法提供時區，

  • 必須連上網際網路才能使用。

無線廣播電台

使用內建調音器擷取時間和時區資訊，這雖然很吸引人。 會造成的難題許多無線電廣播標準定義選項，以提供適當的廣播訊息。 可能不準確或不適當一般來說，廣播電台調整器所提供的資訊與行動網路相同 電台。

ETSI EN 300 401 V1.4.1 (2006-06) 第 8.1 節：指定服務資訊 補充資訊，說明音訊節目服務與數位音訊資料的補充性 廣播 (DAB) 系統。第 8.1.3 節定義了時間和日期的格式，以及 國家/地區和當地時間偏移資訊

同樣地，針對 FM 調音器中常實作的「無線電資料系統」(RDS)，第 3.1.5.6 節 EN 50067 標準 定義時鐘時間與資料 (每分鐘傳輸一次) 的格式。此外， 國家/地區代碼 (ECC) 也可當做傳輸的程式辨識資訊的一部分擷取。

HD Radio 包含對應的選項， HD RadioTM 空氣介面設計 站點資訊服務運輸規格 服務 (SIS) 參數訊息 (MSG ID 0111)。第 5 節清楚列出前瞻性的字詞 。同樣的道理 等於其他系統：

... 這些資料說明瞭電視台位置的當地自訂值， 與接收端位置的本機自訂值不同。在時區邊界附近 消費者可以收到提供不同資料的車站數量。因此 資料僅提供提示，而應做出的解釋和使用方式 皆由客戶控管。...」

此外，至少為 HD Radio 內容，您可以選擇是否播送這類資訊 完全仰賴它

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

  • 穩定性取決於電視台。

導入訣竅

Android 支援將系統時間與 NTP 伺服器同步 (如果可以) 暴露在 RadioManager。建議的解決方案是善用供應商擴充功能功能。 您必須在硬體抽象層 (HAL) 中實作此功能，之後 表示可以透過一般程式庫提供給 RadioManager 的用戶端 RadioTuner.getParameters() 方法。

為了保持解決方案的穩固性，這個供應商擴充資料的消費者必須確定 HAL 支援此功能 (請勿假設其確實存在)。參數字串 getParameters 呼叫必須井然有序，以明確用於各廠商。適用對象 例如使用貴機構的命名空間，並在前面加上適當的網域， 例如：com.me.timezoneTuner.currenttimezone。

資訊以事件為導向，因此使用 用於接收這項資訊的 RadioTuner.Callback.onParametersUpdated() 回呼。如果 這個功能應該可以設定，並且設計一組自訂處理常式， setParameters。例如：

com.me.timezoneTuner.currenttimezoneEvent.enable

但單憑全球衛星導航系統 (GNSS) 可以只提供準確的時間 這些資訊和位置

地理位置

這個問題的解決方法是執行反向地理編碼，然後找出國家/地區 根據位置執行查詢GNSS 是最顯而易見且品質最好的 車上的位置資訊。Google Time Zone API 提供了執行必要轉換所需的所有資訊當然，網際網路連線 這通常代表交易 不會十分要求關聯語意採行線上解決方案時，務必以保障使用者隱私為首要考量！ 必須要求使用者授予同意資料使用費用 (或不申請) 的權限。

您可針對離線使用建立合適的解決方案。本機地圖資料庫 提供精確的解析度資訊，您就能精準判斷可配合車輛通行的國家/地區和時區 如果 30 天內讀取資料不到一次 建議使用 Coldline Storage更新時區和國家/地區設定後，上述做法及充分實行的策略 以便根據 GNSS 對國家/地區進行反向地理編碼 擷取自地點子系統的位置。

優點 缺點
  • 能明確判斷正確的時區。
  • 如為本機資料庫，則「不」需要網際網路連線。
  • 適用於大多數的行車情境。
  • Android 不支援立即可用的這項功能。
  • 車輛位於室內/遮蔽區域，且 GNSS 衛星收訊不佳 但是在初始設定期間，您無法取得精確的時間、位置、 和時區資訊
  • 本機資料庫需要採用更新機制。
  • 實作的複雜度。

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

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

部分支援藍牙低功耗 (BLE) 的手機，都提供透過 GATT 目前時間特性 和目前時間服務概況規格 1.1。不過，這個選項 無法觸及足夠的市場 專屬分類

優點 缺點
  • 「不」需要網際網路連線。
  • 手機偵測到的時區變更可以轉發到車用運算主機。
  • Android 不支援立即可用的這項功能。
  • 必須在手機連接至車用運算主機時運作。
  • 時間是否等於手機所提供的時間差。
  • 實作程序相當複雜。
  • 並非所有手機都支援 BLE GATT 目前時間服務設定檔。

使用來源

每個裝置供應商都必須決定設定標準門檻，以及該決定最重視的使用者歷程 至關重要唯有充分瞭解他們需要的關鍵使用者體驗，才能獲得最佳體驗 做出決定在大部分的情況下，廠商必須考量便利性與 變得複雜

上述選項各有優缺點。舉例來說 與偶爾顯示畫面差不多相比 以及如何管理缺點這項完全自動化的解決方案預計會達到 但必須提供多個資訊來源組合，才能在所有情境下順利運作。 沒有任何一個選項能提供 100% 的可用性。

以手動設定選項做為暫時備用方案很容易執行，在實務上可做到 足以讓許多使用者使用應用程式