基于Android系統(tǒng)的車載系統(tǒng)

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

1、Android Auto

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

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

?

img

1.1 ?核心功能

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

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

回主界面

地圖功能

通話功能

音樂功能

1.1.1 Google Assistant

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

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

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

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

優(yōu)秀的語音系統(tǒng)可以利用對話的上下文完成任務(wù)，避免用戶重復(fù)輸入。

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

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

img

1.2 兼容的車型和應(yīng)用

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

1.3 App

1.3.1 開發(fā)

Android Auto目前僅支持兩類第三方的應(yīng)用：

音頻應(yīng)用：允許用戶瀏覽和播放汽車中的音樂和語音內(nèi)容。

消息應(yīng)用：通過text-to-speech朗讀消息并通過語音輸入回復(fù)消息。

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

???

這里通過標(biāo)簽描述了應(yīng)用所使用的特性：media。name屬性目前僅支持兩個值：

media：該應(yīng)用使用Android框架API在車輛中播放音樂。

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

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

????...
????

之后就是通過相應(yīng)的API完成功能開發(fā)了，這部分內(nèi)容具體見Android Developer中的文檔，這里不再贅述：

Provide audio playback for Auto

Provide messaging for Auto

1.3.2 設(shè)計

Google專門為Android Auto上的UI設(shè)計做了一個指導(dǎo)網(wǎng)站，具體見這里：Auto UI guidelines。

img

基本的指導(dǎo)原則包括：

Android Auto上的互動步調(diào)必須由駕駛員控制。

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

適當(dāng)?shù)纳蕦Ρ瓤蓭椭{駛員快速解讀信息并做出決定。

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

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

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

謹(jǐn)慎和有選擇地使用圖像。

有節(jié)制的使用動畫來描述兩個狀態(tài)之間的變化。

這些指導(dǎo)原則也值得其他車載的交互系統(tǒng)借鑒。

1.4 無線

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

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

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

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

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

2 Android Automotive

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

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

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

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

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

不過，據(jù)報道中的信息，這類產(chǎn)品兩年之內(nèi)恐怕都不會上市。

從這一點來講，AliOS是完全領(lǐng)先Android Automotive的。因為內(nèi)置AliOS的榮威RX5早就已經(jīng)量產(chǎn)了。

一旦將系統(tǒng)內(nèi)置于汽車，可以完成的功能將大大增加。例如：直接在中控觸摸屏上調(diào)整空調(diào)和座椅。

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

img

內(nèi)置于汽車內(nèi)部的系統(tǒng)甚至?xí)绊懫嚤旧淼脑O(shè)計，兩者將非常好的融合在一起。

img

2.1 版本演進

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

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

img

2.2 源碼與架構(gòu)

Android Automative的源碼包含在AOSP中。

關(guān)于AOSP以及如何獲取源碼可以參見其官方網(wǎng)站：

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

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

這里是Android Automative的一些文檔。

Android Automative的整體架構(gòu)如下圖所示：

img

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

包括：

Car App：包括OEM和第三方開發(fā)的App

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

Car Service：系統(tǒng)中與車相關(guān)的服務(wù)

Vehicle Network Service：汽車的網(wǎng)絡(luò)服務(wù)

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

下面我們采取從上到下的順序?qū)χ饕K做一些介紹。

2.3 ?Car App

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

# 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 

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

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

當(dāng)然，OEM廠商可以添加更多的App。

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

2.4 Car API

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

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

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

img

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

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

cabin：座艙相關(guān)API。

hvac：通風(fēng)空調(diào)相關(guān)API。（hvac是Heating, ventilation and air conditioning的縮寫）

property：屬性相關(guān)API。

radio：收音機相關(guān)API。

pm：應(yīng)用包相關(guān)API。

render：渲染相關(guān)API。

menu：車輛應(yīng)用菜單相關(guān)API。

annotation：包含了兩個注解。

app

cluster：儀表盤相關(guān)API。

content

diagnostic：包含與汽車診斷相關(guān)的API。

hardware：車輛硬件相關(guān)API。

input：輸入相關(guān)API。

media：多媒體相關(guān)API。

navigation：導(dǎo)航相關(guān)API。

settings：設(shè)置相關(guān)API。

vms：汽車監(jiān)測相關(guān)API，見下文。

2.5 Car Service

源碼：

Car service

Android Automative中的Car Service集中在一個App中。可以想象，這個App需要非常高的權(quán)限，所以這是一個系統(tǒng)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屬性使得這個應(yīng)用具有系統(tǒng)權(quán)限。

Car Service并非一個服務(wù)，而是一系列的服務(wù)。這些服務(wù)都在ICarImpl.java構(gòu)造函數(shù)中列了出來。

讀者可以瀏覽這些服務(wù)的源碼了解其實現(xiàn)。

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

還有幾個模塊沒有出現(xiàn)在上面的架構(gòu)圖中。但它們也包含在了Android Automative系統(tǒng)中，這里一并介紹一下。

2.6.1 VMS

源碼：

vehicle_monitor_service

libvehiclemonitor/

VMS全稱是Vehicle Monitor Service。正如其名稱所示，這個服務(wù)用來監(jiān)測其他進程。

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

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

service?vms?/system/bin/vehicle_monitor_service

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

on?boot
????start?vms

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

2.6.2 EVS

源碼：

evs

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

EVS 包括以下系統(tǒng)組件：

img

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

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

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

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

關(guān)于EVS的更多內(nèi)容請參見這里：AOSP camera-hal。

關(guān)于HIDL請參見這里：HIDL。

2.6.3 ODB2

源碼：

obd2-lib

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

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

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

AOSP中的ODB2庫是以一個Java靜態(tài)庫的形式存在的。

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

img

2.7 Vehicle Network Service

源碼：

vehicle_network_service

libvehiclenetwork

Vehicle Network Service的結(jié)構(gòu)和VMS的結(jié)構(gòu)是類似的，也是一個可執(zhí)行文件（vehicle_network_service）加一個庫（libvehiclenetwork）的形式。

libvehiclenetwork中既包含了C++的庫，也包含了Java語言的庫。對于需要跨語言訪問的數(shù)據(jù)結(jié)構(gòu)，使用Protocol Buffers 格式描述：libvehiclenetwork/proto/。

Protocol Buffers是Google開發(fā)的另外一個工具。它語言中立，平臺中立，具有可擴展的機制，用于序列化結(jié)構(gòu)化數(shù)據(jù)。類似XML，但更小，更快，更簡單。

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

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;

當(dāng)然，并非所有模塊都有權(quán)限設(shè)置這些HAL屬性。所以這里需要權(quán)限的控制。

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

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

2.8 HAL

源碼：

hardware/libhardware/include/hardware/vehicle.h

hardware/libhardware/modules/vehicle/

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

2.8.1 HAL接口

車載HAL使用以下接口：

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

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

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

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

(*release_memory_from_get)(struct vehicle_hw_device* device, vehicle_prop_value_t *data)?釋放從 get 調(diào)用分配的內(nèi)存。

車載HAL使用以下回調(diào)接口：

(*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級錯誤或每個屬性的錯誤。全局錯誤會導(dǎo)致HAL重新啟動，這可能導(dǎo)致包括應(yīng)用在內(nèi)的其他組件重新啟動。

2.8.2 屬性與區(qū)域

每個屬性都由 int32 鍵唯一標(biāo)識，且具有預(yù)定義的類型（value_type）：INT32（和數(shù)組）、INT64、BOOLEAN、FLOAT（和數(shù)組）、字符串、字節(jié)。

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

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 處理區(qū)域?qū)傩耘e例

下面是獲取HVAC溫度的調(diào)用過程。

img

下面是設(shè)置HAVC溫度的調(diào)用過程。

img

圖中縮寫說明如下：

CS：CarService

VNS：VehicleNetworkService

VHAL：Vehicle HAL

3 結(jié)束語

最后，我們以Android系統(tǒng)在汽車行業(yè)上的發(fā)展小結(jié)一下車載系統(tǒng)的特點：

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

車載系統(tǒng)不是手機系統(tǒng)的簡單移植，手機上的應(yīng)用大部分也不適合車載系統(tǒng)。

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

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

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

語音將是車載系統(tǒng)上很重要的交互方式。

導(dǎo)航，多媒體，消息將是車載系統(tǒng)上最主要的應(yīng)用類型。

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

車載系統(tǒng)將脫離手機，內(nèi)置的原生系統(tǒng)能獲得更好的體驗。

編輯：黃飛

?