使用高可用性轉譯器 (HAR) 顯示 Android 無法顯示的車輛資訊。這可能是因為啟動、可用性、安全性或法規等問題。HAR 是以 Rust 編寫的可攜式內建應用程式。
HAR (又稱 HAR 架構) 包含用於建構應用程式的程式碼。使用 HAR 建構的應用程式稱為以 HAR 為基礎的應用程式。HAR 架構包含適用於不同平台的程式碼區段。舉例來說,在 Linux 系統上,您可以使用 tinyalsa 等程式庫來播放音效。QNX 有專屬的音訊程式庫。
平台包括硬體、作業系統、系統程式庫和其他因素。平台專屬程式碼包含稱為子系統的部分。每個子系統會處理一項平台功能,例如音訊、EVS 攝影機或車輛資料。如要支援平台,HAR 架構需要實作所有子系統。
平台專屬子系統程式碼可能會在與 HAR 應用程式相同的程序中執行,也可能在獨立程序中執行。分開時,這段程式碼會處理處理序間通訊 (IPC),協助驗證平台是否支援應用程式。複雜的 IPC 機制必須是平台專屬程式碼的一部分。
HAR 測試套件會針對為平台實作的所有子系統執行測試。請使用這套工具,檢查平台是否符合 HAR 規定,並找出任何新問題。
術語
本頁面包含以下條款:
- HAR 應用程式
- 使用 HAR 架構建構的原始設備製造商 (OEM) 或特定功能應用程式。應用程式會因應用程式狀態和其他可自訂的層面而有所不同。
- HAR 架構
- 提供一組用於建構應用程式的核心工具。
- HAR 平台抽象化
- HAR 架構的一部分,提供所有目標平台都必須實作的已知 API。
- HAR 測試套件
- 針對平台實作項目進行一系列已知測試,協助驗證平台實作項目是否支援特定平台上的 HAR 架構。
不在範圍內
HAR 不會處理:
所有平台目標的個別實作:目標平台的實作。本頁面說明平台實作必須滿足的介面,以及測試套件必須滿足的條件。
測試案例:所有介面的特定測試案例。本頁面說明介面的個別函式,包括引數、傳回值、預期行為和預期副作用。本頁面說明測試套件,您可以在其中實作及執行測試案例。
平台抽象化高階 crate 結構
Rust 專案由 crate 組成。圖 1 顯示 HAR 平台抽象層的 crate 結構。平台抽象層會影響兩個以上的 Rust crate:
抽象化 (Rust
trait說明) 位於 HAR 架構 Crate 中。平台的實作項目是由獨立的
har-platform-xcrate 負責。例如har-platform-linux或har-platform-android。
如果沒有指定平台實作,就無法建構或測試 HAR crate。這是刻意設計,因為 HAR 框架是框架。
指定平台的應用程式必須使用這個架構建構,才能運作及測試。HAR 架構與平台之間的連結如下圖所示:
圖 1. HAR Crate。
display-safety 的一般結構
這項設計會將一系列新的 crate 新增至 display_safety 存放區,如圖 2 所示:
圖 2. 抽象模組。
測試套件的結構與應用程式類似,但僅依賴特定平台實作 crate。測試套件必須參照 HAR 架構中定義的特徵和結構,但不得參照更複雜的實作。
平台抽象層概要說明
下表說明 HAR 平台抽象層定義的平台專屬子系統。
| 抽象化名稱 | 相關函式 | 說明 | 附註 |
|---|---|---|---|
OpenGL |
2D 算繪 | 為 HAR 架構 Crate 提供 OpenGLES 2.0/3.0 轉譯功能。 | |
Audio |
音訊算繪 | 提供類似 Android SoundPool 的介面,用於管理及播放系統音訊。 | |
Camera |
車輛攝影機畫面 | 提供類似 EVS HAL 的介面,用於管理及顯示車輛攝影機資訊。 | |
Looper |
應用程式主迴圈和顯示設定 | 提供類似 Android Looper 的介面,用於管理平台專屬的應用程式主迴圈和顯示設定。 | |
UserInput |
觸控、鍵盤、方向盤或旋轉控制器,以及其他平台專屬輸入 | 提供介面,可為 HAR 應用程式提供觸控和鍵盤輸入。har-user-input-evdev 中以 Linux evdev 為基礎的參考實作。 |
|
VehicleData |
車輛狀態輸入 | 提供介面,為以 HAR 為基礎的應用程式提供任意車輛資料串流,例如 Android VHAL 或 CAN 匯流排提供的資料。 | |
ResourceManager |
應用程式專屬快取設計文件 | 提供 HAR 啟動所需資源的記憶體內快取,例如快取圖片和設計文件。尚未實作磁碟快取。 | |
Logging |
系統記錄和遙測 | 使用追蹤系統提供平台專屬的記錄支援。這樣一來,系統就能按照平台要求收集遙測資料。 | |
Tracing |
系統追蹤 | 提供抽象機制,可與追蹤和剖析系統整合。 | |
Monitoring |
系統監控 | 在 HAR 架構中監控效能和延遲時間的工具包。 | |
Commlib |
車輛資料 | 使用 protobuf 序列化的參考實作。
已淘汰:請使用 reference/harry-control-api 中定義的 API,以及 harry-grpcio-server 和 harry-tonic-server (參考實作) 的實作。 |
|
TestSupport |
測試支援掛鉤 | 支援測試案例的建構和拆解、測試事件的生成,以及測試構件的建立。例如,產生模擬觸控事件來測試 UserInput,以及產生螢幕截圖以供分析。 |
Rust 會鎖定這項功能,避免納入正式版本。 |
命名慣例和架構結構
下表列出這些名稱和結構:
HAR 架構應提供子系統
trait執行個體。每個trait都代表必須實作的平台專屬子系統。任何平台 Crate 中平台專屬子系統實作項目的預期名稱。HAR 應用程式會預期實作這些特定名稱。
相關的 HAR 架構
enum和struct執行個體,通常用於將資訊從平台相關實作傳遞至 HAR 架構。
| 特徵名稱 | 導入名稱 | HAR 架構列舉和結構 |
|---|---|---|
GlContextFactory |
OpenGL |
trait harry::Rendererharry::DisplayRotation |
AudioApiFactory |
Audio |
harry::AudioApiharry::AudioDeviceharry::VolumeMillibel |
ICameraManager |
Camera |
harry::ICameraDeviceharry::CameraDescriptor |
Looper |
Looper |
harry::LooperMessageharry::LooperOptionsharry::DisplayId |
PlatformVehicleData |
VehicleData |
harry::VehicleDataTypeharry::VehicleDataListener |
ResourceManager (Struct) |
ResourceManager |
harry::ResourceManagerMessageharry::ResourceTokenharry::RawImageData |
PlatformTracing |
Tracing |
不適用 |
HarPerformanceMonitor |
Monitoring |
harry::Rendererharry::ResolveLatencyToken |
PlatformTestSupport |
TestSupport |
harry::TestConfigharry::TestDisplayConfig |
錯誤與錯誤處理機制
建議的 API 使用 Rust Result<> 類型。Rust 會要求您檢查含有錯誤的 Result 類型。否則編譯器會產生警告或錯誤。建構時檢查會強制執行平台專屬程式碼的錯誤檢查。
平台實作傳回的錯誤類型為 harry::error::Error。如要確認平台錯誤類型不會洩漏至應用程式程式碼,請使用 HAR 架構提供的標準錯誤類型。
harry::error::Error 類型會展開,納入所有子系統的特定錯誤:
// This is Rust
pub enum Error {
Msg(String), // A generic message string
// Legacy error type, likely to be removed or merged into Msg
Audio(String),
}
無法復原的錯誤主要透過定義的介面和回呼傳回。
測試套件詳細設計
本節說明測試套件的設計,用於驗證抽象層的平台專屬實作。
建構測試套件測試
如果是 Soong 建構作業 (由 Android.bp 檔案定義),測試會做為 Android 平台建構系統的一部分進行編譯,並由 atest 管理執行作業。
執行測試套件
如要測試個別平台,請使用 atest 指令和相關測試目標 (例如 atest <module_name>)。這個指令會在 Android 裝置或模擬器上部署及執行測試。