大家最熟悉的Android系統應該是手機和平板設備上的，大部分人可能沒想過Android系統和汽車有什么關系。但實際上，Android系統在四年前就在布局汽車這個平臺。我最近對相關內容做了一些了解。下面將我所了解到的信息分享給大家。 ?

1、Android Auto

Android Auto是一個Android端的App，是專門為駕駛環境而設計的。 ? 運行Android Auto需要Android 5.0或更高版本的系統，并且還需要Google地圖和Google Play 音樂應用。 ? Android Auto可以用來將Android設備上的部分功能映射到汽車屏幕上。 ? Android Auto在2014的Google I/O上首次亮相。相應的App：Android Auto在2015年3月19日發布。 ? 當Android Auto接到汽車屏幕上其界面看起來是下面這個樣子： ?

img ? 當然，也可以不連接汽車，直接在手機上使用，其界面是下面這個樣子： ?

?

img

1.1 ?核心功能

在2014的Google I/O大會上，Google在介紹Android Auto時，首先就是以安全性為引入點的：很多人在開車會使用手機，這就造成大量的交通事故。所以我們應當理解，汽車上的軟件功能并非越多越好。某些手機上很受歡迎的功能和軟件，它們未必適合車載系統，例如：瀏覽器網頁，閱讀，玩游戲，看視頻等等。

從上面的兩幅圖中可以看到，無論是汽車屏幕還是手機屏幕，界面底部包含了四個相同的按鈕（雖然位置不同）。 ? 以手機界面的按鈕順序，這四個按鈕的功能依次是：

回主界面

地圖功能

通話功能

音樂功能

1.1.1 Google Assistant

2007年，iPhone的發布宣示了觸摸交互方式的興起。在這之后，觸摸手勢徹底代替了物理鍵盤。 ? 當時的運營商無法想象一個沒有物理鍵盤的手機會被大家喜歡。而在十年之后，曾經能夠生產最好的物理鍵盤手機的制造商，例如黑莓和諾基亞都早已被市場淘汰。 因此我們可以想象，新一代的平臺和電子產品有可能會引入新的交互方式，或者是讓某個原先不太流行的交互方式成為主流。而對于汽車來說，語音無疑是比觸摸更好的交互方式。 ? 在駕駛環境中，語音交互存在如下優勢：

用戶不用改變自身的物理姿勢，所以這種交互方式不影響對于駕駛的操控。

有些需要多次觸摸手勢的交互，可能一條語音就可以完成。

語音交互不存在入口的層次嵌套，數據更加扁平。

優秀的語音系統可以利用對話的上下文完成任務，避免用戶重復輸入。

除此之外，在駕駛環境中，對于語音功能的實現也更有利。因為，駕駛艙的空間較小，便于語音數據的捕獲；駕駛艙座位的相對位置固定，系統更方便判斷發出語音的角色，例如區分發出語音指令的是駕駛員還是乘客而采取不同的處理。 ? 這就不奇怪Google將Google Assistant集成到Android Auto中了。 ? 當語音系統能夠獲取到用戶的基本信息的情況下，很多操作會變得非常便利。例如，直接告訴系統：”我要回家“。而不用先打開地圖，然后搜索自己家的地址，然后再點擊導航按鈕：

img ? 當系統有了更多的用戶的數據以及外部服務之后，可以做的事情將超遠我們現在看到的。例如：在導航至某個餐館的途中直接幫忙預訂座位（今年的Google I/O上，Google已經展示了通過AI完成的電話預訂：Google’s AI Assistant Can Now Make Real Phone Calls）。 ? 當然，Google Assistant 不僅僅是為Android Auto設計的，它支持非常多的設備。不過這部分內容已經超過本文所要說明的。 ?

img

1.2 兼容的車型和應用

現代汽車是首個支持Android Auto的汽車制造商。2015的Hyundai Sonata是第一個支持Android Auto的汽車型號。 ? 到目前為止（2018年7月），支持Android Auto的汽車品牌已經很多，包括：奧迪，別克，凱迪拉克，雪佛蘭，福特，本田，吉普，林肯，奔馳，馬自達，大眾，Volvo等超過50家汽車制造商，超過500種汽車型號。 ? 詳細的品牌和型號請參見下面這個鏈接：Android Auto - The right information for the road ahead 。 ? 目前，支持Android Auto的應用比較少。雖然2018年的Google I/O上宣稱這類應用數量正在高速增長，但目前Google Play上支持Android Auto的應用也只有數千款，這與Google Play上的三百多萬應用相比，就顯得很可憐了。 ? 可以通過這個鏈接瀏覽支持Android Auto的應用：Apps for Android Auto。 ?

1.3 App

1.3.1 開發

Android Auto目前僅支持兩類第三方的應用：

音頻應用：允許用戶瀏覽和播放汽車中的音樂和語音內容。

消息應用：通過text-to-speech朗讀消息并通過語音輸入回復消息。

為了聲明應用支持Android Auto，需要在/res/xml/新建一個XML文件來進行描述。 ? 例如，假設我們創建的文件是automotive_app_desc.xml，其內容是

???

這里通過標簽描述了應用所使用的特性：media。name屬性目前僅支持兩個值：

media：該應用使用Android框架API在車輛中播放音樂。

notification：該應用在汽車的主屏幕中顯示消息通知，允許用戶選擇要朗讀的消息，并讓他們通過語音輸入進行響應。

定義完成該文件之后，需要在AndroidManifest.xml中指定：

????...
????

之后就是通過相應的API完成功能開發了，這部分內容具體見Android Developer中的文檔，這里不再贅述：

Provide audio playback for Auto

Provide messaging for Auto

1.3.2 設計

Google專門為Android Auto上的UI設計做了一個指導網站，具體見這里：Auto UI guidelines。

img

基本的指導原則包括：

Android Auto上的互動步調必須由駕駛員控制。

汽車界面上的觸摸目標必須足夠大，以便可以輕松地瀏覽和點按。

適當的色彩對比可幫助駕駛員快速解讀信息并做出決定。

應用必須支持夜間模式，因為過高的亮度可能會干擾注意力。

Roboto字體在整個系統中用于保持一致性并幫助提高可讀性。

通過觸摸來進行分頁應該用來作為滑動翻頁的補充。

謹慎和有選擇地使用圖像。

有節制的使用動畫來描述兩個狀態之間的變化。

這些指導原則也值得其他車載的交互系統借鑒。

1.4 無線

目前的Android Auto需要通過USB線纜將手機連接到汽車上才能使用。

通過線纜連接這個動作對用戶來說無疑是一件很麻煩的事情。一來需要將手機從包中取出，二來再次拿手機時還受限于線的長度。所以很顯然，無線的使用方式將是未來的設計趨勢。這一點，從Apple的AirPods以及近期新上市的手機幾乎都會支持無線充電就可以看出。

在功耗和傳輸性能的限制下，有線設計只是暫時的妥協。不過一旦這些限制逐漸縮小，無線功能自然就會出現了。所以Google在今年提出了無線Android Auto。

可以看一下這個鏈接：Wireless Android Auto is available for Google phones。

Apple在iOS 9上就支持無線CarPlay了。不過目前只有BMW部分車型支持。

2 Android Automotive

Android Auto是以手機為中心的。這種模型既有好處，也有壞處。

好處是：數據和應用始終是一致的，不存在需要數據同步的問題，手機上裝的軟件和已有的數據，接到汽車直接就有了。而壞處是，每次得拿出手機，汽車只是手機一個外設。并且，這種模式不便于對于汽車本身的控制和相關數據的獲取。

如果是系統直接內置于汽車，那就是完全不一樣的體驗了。而Android Automotive則是面向這個方向設計的。

可以看一下下面的兩個鏈接：

Volvo’s native Google integration is the next level for Android Auto

For Google, it’s full speed ahead with Android Automotive, but not so much with Android Auto

不過，據報道中的信息，這類產品兩年之內恐怕都不會上市。

從這一點來講，AliOS是完全領先Android Automotive的。因為內置AliOS的榮威RX5早就已經量產了。

一旦將系統內置于汽車，可以完成的功能將大大增加。例如：直接在中控觸摸屏上調整空調和座椅。

同時，系統也能獲取到更多關于汽車的信息，例如：油耗水平，剎車使用等等。這對于改進駕駛體驗是非常有意義的。

img

內置于汽車內部的系統甚至會影響汽車本身的設計，兩者將非常好的融合在一起。

img

2.1 版本演進

最近幾年的Android版本中，每個版本都為Android Auto增加了一些新特性。具體可以觀看今年的Google I/O中的相關演講：What’s new in automotive - Google I/O 2018。

下面是這個演講中對于版本演進的特性小結：

img

2.2 源碼與架構

Android Automative的源碼包含在AOSP中。

關于AOSP以及如何獲取源碼可以參見其官方網站：

https://source.android.com，這里不再贅述。

如果你不想下載整個源碼，只想瀏覽Android Automative的相關源碼，可以直接點擊這個鏈接：/platform/packages/services/Car/。

這里是Android Automative的一些文檔。

Android Automative的整體架構如下圖所示：

img

從這幅圖中我們可以看出，Android Automative是在原先Android的系統架構上增加了一些與車相關的（圖中虛線框中綠色背景的）模塊。

包括：

Car App：包括OEM和第三方開發的App

Car API：提供給汽車App特有的接口

Car Service：系統中與車相關的服務

Vehicle Network Service：汽車的網絡服務

Vehicle HAL：汽車的硬件抽象層描述

下面我們采取從上到下的順序對主要模塊做一些介紹。

2.3 ?Car App

/car_product/build/car.mk 這個文件中列出了汽車系統中專有的模塊：

# Automotive specific packages
PRODUCT_PACKAGES += 
    vehicle_monitor_service 
    CarService 
    CarTrustAgentService 
    CarDialerApp 
    CarRadioApp 
    OverviewApp 
    CarLensPickerApp 
    LocalMediaPlayer 
    CarMediaApp 
    CarMessengerApp 
    CarHvacApp 
    CarMapsPlaceholder 
    CarLatinIME 
    CarUsbHandler 
    android.car 
    libvehiclemonitor-native 

這個列表中，首字母大寫的模塊基本上都是汽車系統中專有的App。

這些App的源碼都位于/platform/packages/services/Car/目錄下。

當然，OEM廠商可以添加更多的App。

你也可以在/platform/packages/services/Car/目錄下通過find . -name AndroidManifest.xml確認哪些文件中包含了Car App。

2.4 Car API

源碼：/platform/packages/services/Car/car-lib

開發汽車專有的App自然需要專有的API。這些API對于其他平臺（例如手機和平板）通常是沒有意義的。所以這些API沒有包含在Android Framework SDK中。

下面這張大圖列出了所有的Car API：

img

從這個圖中我們可以看到Car API主要包括：

android.car：包含了與車相關的基本API。例如：車輛后視鏡，門，座位，窗口等。

cabin：座艙相關API。

hvac：通風空調相關API。（hvac是Heating, ventilation and air conditioning的縮寫）

property：屬性相關API。

radio：收音機相關API。

pm：應用包相關API。

render：渲染相關API。

menu：車輛應用菜單相關API。

annotation：包含了兩個注解。

app

cluster：儀表盤相關API。

content

diagnostic：包含與汽車診斷相關的API。

hardware：車輛硬件相關API。

input：輸入相關API。

media：多媒體相關API。

navigation：導航相關API。

settings：設置相關API。

vms：汽車監測相關API，見下文。

2.5 Car Service

源碼：

Car service

Android Automative中的Car Service集中在一個App中。可以想象，這個App需要非常高的權限，所以這是一個系統App。其Manifest開頭如下：

????????xmlns:androidprv="http://schemas.android.com/apk/prv/res/android"
????????package="com.android.car"
????????coreApp="true"
????????android:sharedUserId="android.uid.system">

android:sharedUserId屬性使得這個應用具有系統權限。

Car Service并非一個服務，而是一系列的服務。這些服務都在ICarImpl.java構造函數中列了出來。

讀者可以瀏覽這些服務的源碼了解其實現。

public?ICarImpl(Context?serviceContext,?IVehicle?vehicle,?SystemInterface?systemInterface,

????????CanBusErrorNotifier?errorNotifier)?{
????mContext?=?serviceContext;
????mHal?=?new?VehicleHal(vehicle);
????mSystemActivityMonitoringService?=?new?SystemActivityMonitoringService(serviceContext);
????mCarPowerManagementService?=?new?CarPowerManagementService(
????????????mHal.getPowerHal(),?systemInterface);
????mCarSensorService?=?new?CarSensorService(serviceContext,?mHal.getSensorHal());
????mCarPackageManagerService?=?new?CarPackageManagerService(serviceContext,?mCarSensorService,
????????????mSystemActivityMonitoringService);
????mCarInputService?=?new?CarInputService(serviceContext,?mHal.getInputHal());
????mCarProjectionService?=?new?CarProjectionService(serviceContext,?mCarInputService);
????mGarageModeService?=?new?GarageModeService(mContext,?mCarPowerManagementService);
????mCarInfoService?=?new?CarInfoService(serviceContext,?mHal.getInfoHal());
????mAppFocusService?=?new?AppFocusService(serviceContext,?mSystemActivityMonitoringService);
????mCarAudioService?=?new?CarAudioService(serviceContext,?mHal.getAudioHal(),
????????????mCarInputService,?errorNotifier);
????mCarCabinService?=?new?CarCabinService(serviceContext,?mHal.getCabinHal());
????mCarHvacService?=?new?CarHvacService(serviceContext,?mHal.getHvacHal());
????mCarRadioService?=?new?CarRadioService(serviceContext,?mHal.getRadioHal());
????mCarNightService?=?new?CarNightService(serviceContext,?mCarSensorService);
????mInstrumentClusterService?=?new?InstrumentClusterService(serviceContext,
????????????mAppFocusService,?mCarInputService);
????mSystemStateControllerService?=?new?SystemStateControllerService(serviceContext,
????????????mCarPowerManagementService,?mCarAudioService,?this);
????mCarVendorExtensionService?=?new?CarVendorExtensionService(serviceContext,
????????????mHal.getVendorExtensionHal());
????mPerUserCarServiceHelper?=?new?PerUserCarServiceHelper(serviceContext);
????mCarBluetoothService?=?new?CarBluetoothService(serviceContext,?mCarCabinService,
????????????mCarSensorService,?mPerUserCarServiceHelper);
????if?(FeatureConfiguration.ENABLE_VEHICLE_MAP_SERVICE)?{
????????mVmsSubscriberService?=?new?VmsSubscriberService(serviceContext,?mHal.getVmsHal());
????????mVmsPublisherService?=?new?VmsPublisherService(serviceContext,?mHal.getVmsHal());
????}
????mCarDiagnosticService?=?new?CarDiagnosticService(serviceContext,?mHal.getDiagnosticHal());

????...

2.6 Car Tool

還有幾個模塊沒有出現在上面的架構圖中。但它們也包含在了Android Automative系統中，這里一并介紹一下。

2.6.1 VMS

源碼：

vehicle_monitor_service

libvehiclemonitor/

VMS全稱是Vehicle Monitor Service。正如其名稱所示，這個服務用來監測其他進程。

在運行時，這個服務是一個獨立的進程，在init.car.rc中有關于它的配置：

如果你不熟悉rc文件請閱讀我之前寫過的文章：Android系統啟動：init進程與init語言

service?vms?/system/bin/vehicle_monitor_service

???class?core
???user?root
???group?root
???critical

on?boot
????start?vms

這是一個Binder服務，并提供了C++和Java的Binder接口用來供其他模塊使用。

2.6.2 EVS

源碼：

evs

Android 8.0包含一個汽車 HIDL 硬件抽象層（HAL），可用于在 Android 啟動過程的初期提供圖像捕獲和顯示，并在系統啟動后繼續運行直到系統終止。HAL包含外部視景系統 (Exterior View System，簡稱EVS) 堆棧，通常用于在具有車載信息娛樂（IVI）系統（基于 Android）的車輛中支持后視攝像頭和環繞視圖顯示。EVS 還支持在用戶應用中實現高級功能。

EVS 包括以下系統組件：

img

EVS應用：該應用負責從EVS管理器請求視頻幀，并將用于顯示的已完成的幀發送回EVS管理器。EVS和汽車服務可供使用后，它便立即由init啟動。OEM可視需要修改或替換EVS應用。 ?

EVS 管理器：EVS管理器可提供 EVS 應用所需的編譯塊，以實現從簡單的后視攝像頭顯示到6DOF多相機渲染的任何功能。它的接口通過 HIDL呈現，并被編譯為接受多個并發客戶端。其他應用和服務（特別是汽車服務）可以查詢 EVS 管理器狀態，以了解EVS系統何時處于活動狀態。 ?

EVS HIDL接口：在 EVS 系統中，相機和顯示元素均在 android.hardware.automotive.evs 程序包中進行定義。用于實踐接口的示例實現（生成合成測試圖像并驗證圖像進行往返的過程）在?/hardware/interfaces/automotive/evs/1.0/default 中進行提供。 ?

內核驅動程序：支持EVS堆棧的設備需要使用內核驅動程序。OEM無需創建新驅動程序，他們可以選擇通過現有相機和/或顯示硬件驅動程序來支持EVS所需的功能。重復使用驅動程序可能會有好處，對于圖像呈現可能需要與其他活動線程協調的顯示驅動程序來說尤其如此。

關于EVS的更多內容請參見這里：AOSP camera-hal。

關于HIDL請參見這里：HIDL。

2.6.3 ODB2

源碼：

obd2-lib

ODB全稱是On-Board Diagnostics。這是一種裝置于車中用以監控車輛運行狀態和回報異常的系統，可于車輛的子系統出現問題時，產生故障代碼和提醒訊號通知車主和車廠診斷維修。1980年車上診斷系統發明后，早期僅能以指示燈形式回報故障發生與否。隨著計算機技術的進步，目前已經能回報各式各樣的實時數據和標準化故障代碼（diagnostic trouble codes，DTC），使得汽車故障診斷維修方法發生翻天覆地的變化。

美國是最早規定車輛必須裝配車上診斷系統的國家，之后歐盟與日本也陸續采行。臺灣自2008年起實施。中國大陸部分地區則自2006年起陸續對新車推出了裝置車上診斷系統的要求。

OBD-II是基于OBD-I的基礎上，增加了資料容量并將其標準化。OBD-II明確定義了連接器型式、腳位、可用通訊協定以及訊息格式。OBD-II同時也提供額外可監控汽車參數清單以及編碼方式說明。

AOSP中的ODB2庫是以一個Java靜態庫的形式存在的。

它支持多種命令。這些命令按照類型實現在不同的文件中：

img

2.7 Vehicle Network Service

源碼：

vehicle_network_service

libvehiclenetwork

Vehicle Network Service的結構和VMS的結構是類似的，也是一個可執行文件（vehicle_network_service）加一個庫（libvehiclenetwork）的形式。

libvehiclenetwork中既包含了C++的庫，也包含了Java語言的庫。對于需要跨語言訪問的數據結構，使用Protocol Buffers 格式描述：libvehiclenetwork/proto/。

Protocol Buffers是Google開發的另外一個工具。它語言中立，平臺中立，具有可擴展的機制，用于序列化結構化數據。類似XML，但更小，更快，更簡單。

vehicle Network Service的主要作用是通過它來設置HAL屬性（見下文HAL）。這些屬性在VehicleNetworkConsts.java中已經全部列出：

public?static?final?int?VEHICLE_PROPERTY_INFO_VIN?=?0x00000100;
public?static?final?int?VEHICLE_PROPERTY_INFO_MAKE?=?0x00000101;
public?static?final?int?VEHICLE_PROPERTY_INFO_MODEL?=?0x00000102;
public?static?final?int?VEHICLE_PROPERTY_INFO_MODEL_YEAR?=?0x00000103;
public?static?final?int?VEHICLE_PROPERTY_INFO_FUEL_CAPACITY?=?0x00000104;
public?static?final?int?VEHICLE_PROPERTY_PERF_ODOMETER?=?0x00000204;
public?static?final?int?VEHICLE_PROPERTY_PERF_VEHICLE_SPEED?=?0x00000207;
public?static?final?int?VEHICLE_PROPERTY_ENGINE_COOLANT_TEMP?=?0x00000301;
public?static?final?int?VEHICLE_PROPERTY_ENGINE_OIL_TEMP?=?0x00000304;
public?static?final?int?VEHICLE_PROPERTY_ENGINE_RPM?=?0x00000305;
public?static?final?int?VEHICLE_PROPERTY_GEAR_SELECTION?=?0x00000400;
public?static?final?int?VEHICLE_PROPERTY_CURRENT_GEAR?=?0x00000401;
public?static?final?int?VEHICLE_PROPERTY_PARKING_BRAKE_ON?=?0x00000402;
public?static?final?int?VEHICLE_PROPERTY_DRIVING_STATUS?=?0x00000404;
public?static?final?int?VEHICLE_PROPERTY_FUEL_LEVEL_LOW?=?0x00000405;
public?static?final?int?VEHICLE_PROPERTY_NIGHT_MODE?=?0x00000407;
public?static?final?int?VEHICLE_PROPERTY_HVAC_FAN_SPEED?=?0x00000500;
public?static?final?int?VEHICLE_PROPERTY_HVAC_FAN_DIRECTION?=?0x00000501;
public?static?final?int?VEHICLE_PROPERTY_HVAC_TEMPERATURE_CURRENT?=?0x00000502;
public?static?final?int?VEHICLE_PROPERTY_HVAC_TEMPERATURE_SET?=?0x00000503;
public?static?final?int?VEHICLE_PROPERTY_HVAC_DEFROSTER?=?0x00000504;
public?static?final?int?VEHICLE_PROPERTY_HVAC_AC_ON?=?0x00000505;
public?static?final?int?VEHICLE_PROPERTY_HVAC_MAX_AC_ON?=?0x00000506;
public?static?final?int?VEHICLE_PROPERTY_HVAC_MAX_DEFROST_ON?=?0x00000507;
public?static?final?int?VEHICLE_PROPERTY_HVAC_RECIRC_ON?=?0x00000508;
public?static?final?int?VEHICLE_PROPERTY_HVAC_DUAL_ON?=?0x00000509;
public?static?final?int?VEHICLE_PROPERTY_ENV_OUTSIDE_TEMPERATURE?=?0x00000703;
public?static?final?int?VEHICLE_PROPERTY_ENV_CABIN_TEMPERATURE?=?0x00000704;
public?static?final?int?VEHICLE_PROPERTY_RADIO_PRESET?=?0x0000801;
public?static?final?int?VEHICLE_PROPERTY_AUDIO_FOCUS?=?0x00000900;
public?static?final?int?VEHICLE_PROPERTY_AUDIO_VOLUME?=?0x00000901;
public?static?final?int?VEHICLE_PROPERTY_AUDIO_VOLUME_LIMIT?=?0x00000902;
public?static?final?int?VEHICLE_PROPERTY_AUDIO_ROUTING_POLICY?=?0x00000903;
public?static?final?int?VEHICLE_PROPERTY_AUDIO_HW_VARIANT?=?0x00000904;
public?static?final?int?VEHICLE_PROPERTY_AP_POWER_STATE?=?0x00000A00;
public?static?final?int?VEHICLE_PROPERTY_DISPLAY_BRIGHTNESS?=?0x00000A01;
public?static?final?int?VEHICLE_PROPERTY_AP_POWER_BOOTUP_REASON?=?0x00000A02;
public?static?final?int?VEHICLE_PROPERTY_HW_KEY_INPUT?=?0x00000A10;
public?static?final?int?VEHICLE_PROPERTY_INSTRUMENT_CLUSTER_INFO?=?0x00000A20;
public?static?final?int?VEHICLE_PROPERTY_CUSTOM_START?=?0x70000000;
public?static?final?int?VEHICLE_PROPERTY_CUSTOM_END?=?0x73ffffff;
public?static?final?int?VEHICLE_PROPERTY_INTERNAL_START?=?0x74000000;
public?static?final?int?VEHICLE_PROPERTY_INTERNAL_END?=?0x74ffffff;
public?static?final?int?VEHICLE_PROPERTY_INTERNAL_AUDIO_STREAM_STATE?=?0x74000000;

當然，并非所有模塊都有權限設置這些HAL屬性。所以這里需要權限的控制。

對于這一點，通過vns_policy.xml來控制。

這個文件中定義了每個屬性允許哪個角色訪問，以及訪問權限是只讀（r）還是可讀可寫（rw）。下面是vns_policy.xml中的一個代碼片段：

2.8 HAL

源碼：

hardware/libhardware/include/hardware/vehicle.h

hardware/libhardware/modules/vehicle/

車載HAL（Hareware Abstract Layer，硬件抽象層）接口會定義OEM可以實現的屬性，并會包含屬性元數據（例如，屬性是否為 int 以及允許使用哪些更改模式）。車載 HAL 接口是以對屬性（特定功能的抽象表示）的訪問（讀取、寫入、訂閱）為基礎。

2.8.1 HAL接口

車載HAL使用以下接口：

vehicle_prop_config_t const *(*list_properties)(..., int* num_properties)?列出車載 HAL 所支持的所有屬性的配置。車輛網絡服務只會使用受支持的屬性。

(*get)(..., vehicle_prop_value_t *data)?讀取屬性的當前值。對于區域屬性，每個區域都可能具有不同的值。

(*set)(..., const vehicle_prop_value_t *data)?為屬性寫入相應值。寫入的結果是按屬性進行定義。

(*subscribe)(..., int32_t prop, float sample_rate, int32_t zones)?監視屬性值的變化，回調見下文。

(*release_memory_from_get)(struct vehicle_hw_device* device, vehicle_prop_value_t *data)?釋放從 get 調用分配的內存。

車載HAL使用以下回調接口：

(*vehicle_event_callback_fn)(const vehicle_prop_value_t *event_data)?通知車輛屬性值的變化。

(*vehicle_error_callback_fn)(int32_t error_code, int32_t property, int32_t operation)?返回全局車載 HAL級錯誤或每個屬性的錯誤。全局錯誤會導致HAL重新啟動，這可能導致包括應用在內的其他組件重新啟動。

2.8.2 屬性與區域

每個屬性都由 int32 鍵唯一標識，且具有預定義的類型（value_type）：INT32（和數組）、INT64、BOOLEAN、FLOAT（和數組）、字符串、字節。

區域類型除了值之外還有區域。車載HAL定義了下面幾種區域類型：

enum?vehicle_zone_type?{

????VEHICLE_ZONE_TYPE_NONE??????=?0x00,
????VEHICLE_ZONE_TYPE_ZONE??????=?0x01,
????VEHICLE_ZONE_TYPE_SEAT??????=?0x02,
????VEHICLE_ZONE_TYPE_DOOR??????=?0x04,
????VEHICLE_ZONE_TYPE_WINDOW????=?0x10,
????VEHICLE_ZONE_TYPE_MIRROR????=?0x20,
};

2.8.3 處理區域屬性舉例

下面是獲取HVAC溫度的調用過程。

img

下面是設置HAVC溫度的調用過程。

img

圖中縮寫說明如下：

CS：CarService

VNS：VehicleNetworkService

VHAL：Vehicle HAL

3 結束語

最后，我們以Android系統在汽車行業上的發展小結一下車載系統的特點：

保持駕駛安全永遠是第一重要，任何新功能的增加都必須先考慮這個原則。

車載系統不是手機系統的簡單移植，手機上的應用大部分也不適合車載系統。

車機硬件差異太大，平臺需要處理好差異性。

交互方式需要用心對待，以便讓用戶更容易操作。

界面設計上也需要通過色彩或控件大小以突出重點，讓用戶更容易辨識。

語音將是車載系統上很重要的交互方式。

導航，多媒體，消息將是車載系統上最主要的應用類型。

無線通信是未來，隨著硬件傳輸速度的提升，各種線纜將盡可能的減少。

車載系統將脫離手機，內置的原生系統能獲得更好的體驗。

編輯：黃飛

?