0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復
登錄后你可以
  • 下載海量資料
  • 學習在線課程
  • 觀看技術視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認識你,還能領取20積分哦,立即完善>

3天內不再提示

Android在車載上的應用

倩倩 ? 來源:智駕最前沿 ? 作者:智駕最前沿 ? 2022-09-05 16:29 ? 次閱讀

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

1 Android Auto

Android Auto是一個Android端的App,是專門為駕駛環(huán)境而設計的。

運行Android Auto需要Android 5.0或更高版本的系統(tǒng),并且還需要Google地圖和Google Play 音樂應用。

Android Auto可以用來將Android設備上的部分功能映射到汽車屏幕上。

Android Auto在2014的Google I/O上首次亮相。相應的App:Android Auto在2015年3月19日發(fā)布。

當Android Auto接到汽車屏幕上其界面看起來是下面這個樣子:

c9020842-2c1a-11ed-ba43-dac502259ad0.jpg

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

c917466c-2c1a-11ed-ba43-dac502259ad0.png

1.1 核心功能

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

從上面的兩幅圖中可以看到,無論是汽車屏幕還是手機屏幕,界面底部包含了四個相同的按鈕(雖然位置不同)。

以手機界面的按鈕順序,這四個按鈕的功能依次是:

  • 回主界面

  • 地圖功能

  • 通話功能

  • 音樂功能

1.1.1 Google Assistant

2007年,iPhone的發(fā)布宣示了觸摸交互方式的興起。在這之后,觸摸手勢徹底代替了物理鍵盤。

當時的運營商無法想象一個沒有物理鍵盤的手機會被大家喜歡。而在十年之后,曾經能夠生產最好的物理鍵盤手機的制造商,例如黑莓和諾基亞都早已被市場淘汰。

因此我們可以想象,新一代的平臺和電子產品有可能會引入新的交互方式,或者是讓某個原先不太流行的交互方式成為主流。而對于汽車來說,語音無疑是比觸摸更好的交互方式。

在駕駛環(huán)境中,語音交互存在如下優(yōu)勢:

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

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

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

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

除此之外,在駕駛環(huán)境中,對于語音功能的實現(xiàn)也更有利。因為,駕駛艙的空間較小,便于語音數據的捕獲;駕駛艙座位的相對位置固定,系統(tǒng)更方便判斷發(fā)出語音的角色,例如區(qū)分發(fā)出語音指令的是駕駛員還是乘客而采取不同的處理。

這就不奇怪Google將Google Assistant集成到Android Auto中了。

當語音系統(tǒng)能夠獲取到用戶的基本信息的情況下,很多操作會變得非常便利。例如,直接告訴系統(tǒng):”我要回家“。而不用先打開地圖,然后搜索自己家的地址,然后再點擊導航按鈕:

c96a08ca-2c1a-11ed-ba43-dac502259ad0.png

當系統(tǒng)有了更多的用戶的數據以及外部服務之后,可以做的事情將超遠我們現(xiàn)在看到的。例如:在導航至某個餐館的途中直接幫忙預訂座位(今年的Google I/O上,Google已經展示了通過AI完成的電話預訂:Google’s AI Assistant Can Now Make Real Phone Calls)。

當然,Google Assistant 不僅僅是為Android Auto設計的,它支持非常多的設備。不過這部分內容已經超過本文所要說明的。

c97602b0-2c1a-11ed-ba43-dac502259ad0.png

1.2 兼容的車型和應用

現(xiàn)代汽車是首個支持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 開發(fā)

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

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

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

為了聲明應用支持Android Auto,需要在/res/xml/新建一個XML文件來進行描述。

例如,假設我們創(chuàng)建的文件是automotive_app_desc.xml,其內容是:


"media"/>

這里通過標簽描述了應用所使用的特性:media。name屬性目前僅支持兩個值:
  • media:該應用使用Android框架API在車輛中播放音樂。
  • notification:該應用在汽車的主屏幕中顯示消息通知,允許用戶選擇要朗讀的消息,并讓他們通過語音輸入進行響應。
定義完成該文件之后,需要在AndroidManifest.xml中指定:


...
"com.google.android.gms.car.application"
android:resource="@xml/automotive_app_desc"/>


之后就是通過相應的API完成功能開發(fā)了,這部分內容具體見Android Developer中的文檔,這里不再贅述:
  • Provide audio playback for Auto
  • Provide messaging for Auto

1.3.2 設計

Google專門為Android Auto上的UI設計做了一個指導網站,具體見這里:Auto UI guidelines。c9912a86-2c1a-11ed-ba43-dac502259ad0.png基本的指導原則包括:
  • Android Auto上的互動步調必須由駕駛員控制。
  • 汽車界面上的觸摸目標必須足夠大,以便可以輕松地瀏覽和點按。
  • 適當的色彩對比可幫助駕駛員快速解讀信息并做出決定。
  • 應用必須支持夜間模式,因為過高的亮度可能會干擾注意力。
  • Roboto字體在整個系統(tǒng)中用于保持一致性并幫助提高可讀性。
  • 通過觸摸來進行分頁應該用來作為滑動翻頁的補充。
  • 謹慎和有選擇地使用圖像。
  • 有節(jié)制的使用動畫來描述兩個狀態(tài)之間的變化。

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

1.4 無線

目前的Android Auto需要通過USB線纜將手機連接到汽車上才能使用。通過線纜連接這個動作對用戶來說無疑是一件很麻煩的事情。一來需要將手機從包中取出,二來再次拿手機時還受限于線的長度。所以很顯然,無線的使用方式將是未來的設計趨勢。這一點,從Apple的AirPods以及近期新上市的手機幾乎都會支持無線充電就可以看出。在功耗和傳輸性能的限制下,有線設計只是暫時的妥協(xié)。不過一旦這些限制逐漸縮小,無線功能自然就會出現(xiàn)了。所以Google在今年提出了無線Android Auto。可以看一下這個鏈接:Wireless Android Auto is available for Google phones。Apple在iOS 9上就支持無線CarPlay了。不過目前只有BMW部分車型支持。

2 Android Automotive

Android Auto是以手機為中心的。這種模型既有好處,也有壞處。好處是:數據和應用始終是一致的,不存在需要數據同步的問題,手機上裝的軟件和已有的數據,接到汽車直接就有了。而壞處是,每次得拿出手機,汽車只是手機一個外設。并且,這種模式不便于對于汽車本身的控制和相關數據的獲取。如果是系統(tǒng)直接內置于汽車,那就是完全不一樣的體驗了。而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早就已經量產了。

一旦將系統(tǒng)內置于汽車,可以完成的功能將大大增加。例如:直接在中控觸摸屏上調整空調和座椅。同時,系統(tǒng)也能獲取到更多關于汽車的信息,例如:油耗水平,剎車使用等等。這對于改進駕駛體驗是非常有意義的。 內置于汽車內部的系統(tǒng)甚至會影響汽車本身的設計,兩者將非常好的融合在一起。

2.1 版本演進

最近幾年的Android版本中,每個版本都為Android Auto增加了一些新特性。具體可以觀看今年的Google I/O中的相關演講:What’s new in automotive - Google I/O 2018。下面是這個演講中對于版本演進的特性小結:ca12ac00-2c1a-11ed-ba43-dac502259ad0.png

2.2 源碼與架構

Android Automative的源碼包含在AOSP中。關于AOSP以及如何獲取源碼可以參見其官方網站:https://source.android.com,這里不再贅述。如果你不想下載整個源碼,只想瀏覽Android Automative的相關源碼,可以直接點擊這個鏈接:/platform/packages/services/Car/。這里是Android Automative的一些文檔。Android Automative的整體架構如下圖所示:ca40e2d2-2c1a-11ed-ba43-dac502259ad0.png從這幅圖中我們可以看出,Android Automative是在原先Android的系統(tǒng)架構上增加了一些與車相關的(圖中虛線框中綠色背景的)模塊。包括:
  • Car App:包括OEM和第三方開發(fā)的App
  • Car API:提供給汽車App特有的接口
  • Car Service:系統(tǒng)中與車相關的服務
  • Vehicle Network Service:汽車的網絡服務
  • Vehicle HAL:汽車的硬件抽象層描述
下面我們采取從上到下的順序對主要模塊做一些介紹。

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/目錄下。

當然,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:

ca6f20e8-2c1a-11ed-ba43-dac502259ad0.png

從這個圖中我們可以看到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:汽車監(jiān)測相關API,見下文。

2.5 Car Service

源碼:

  • Car service

Android Automative中的Car Service集中在一個App中??梢韵胂?,這個App需要非常高的權限,所以這是一個系統(tǒng)App。其Manifest開頭如下:

"http://schemas.android.com/apk/res/android"
xmlns:androidprv="http://schemas.android.com/apk/prv/res/android"
package="com.android.car"
coreApp="true"
android:sharedUserId="android.uid.system">
android:sharedUserId屬性使得這個應用具有系統(tǒng)權限。Car Service并非一個服務,而是一系列的服務。這些服務都在ICarImpl.java構造函數中列了出來。讀者可以瀏覽這些服務的源碼了解其實現(xiàn)。
publicICarImpl(ContextserviceContext,IVehiclevehicle,SystemInterfacesystemInterface,
CanBusErrorNotifiererrorNotifier){
mContext=serviceContext;
mHal=newVehicleHal(vehicle);
mSystemActivityMonitoringService=newSystemActivityMonitoringService(serviceContext);
mCarPowerManagementService=newCarPowerManagementService(
mHal.getPowerHal(),systemInterface);
mCarSensorService=newCarSensorService(serviceContext,mHal.getSensorHal());
mCarPackageManagerService=newCarPackageManagerService(serviceContext,mCarSensorService,
mSystemActivityMonitoringService);
mCarInputService=newCarInputService(serviceContext,mHal.getInputHal());
mCarProjectionService=newCarProjectionService(serviceContext,mCarInputService);
mGarageModeService=newGarageModeService(mContext,mCarPowerManagementService);
mCarInfoService=newCarInfoService(serviceContext,mHal.getInfoHal());
mAppFocusService=newAppFocusService(serviceContext,mSystemActivityMonitoringService);
mCarAudioService=newCarAudioService(serviceContext,mHal.getAudioHal(),
mCarInputService,errorNotifier);
mCarCabinService=newCarCabinService(serviceContext,mHal.getCabinHal());
mCarHvacService=newCarHvacService(serviceContext,mHal.getHvacHal());
mCarRadioService=newCarRadioService(serviceContext,mHal.getRadioHal());
mCarNightService=newCarNightService(serviceContext,mCarSensorService);
mInstrumentClusterService=newInstrumentClusterService(serviceContext,
mAppFocusService,mCarInputService);
mSystemStateControllerService=newSystemStateControllerService(serviceContext,
mCarPowerManagementService,mCarAudioService,this);
mCarVendorExtensionService=newCarVendorExtensionService(serviceContext,
mHal.getVendorExtensionHal());
mPerUserCarServiceHelper=newPerUserCarServiceHelper(serviceContext);
mCarBluetoothService=newCarBluetoothService(serviceContext,mCarCabinService,
mCarSensorService,mPerUserCarServiceHelper);
if(FeatureConfiguration.ENABLE_VEHICLE_MAP_SERVICE){
mVmsSubscriberService=newVmsSubscriberService(serviceContext,mHal.getVmsHal());
mVmsPublisherService=newVmsPublisherService(serviceContext,mHal.getVmsHal());
}
mCarDiagnosticService=newCarDiagnosticService(serviceContext,mHal.getDiagnosticHal());

...

2.6 Car Tool

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

2.6.1 VMS

源碼:

  • vehicle_monitor_service

  • libvehiclemonitor/

VMS全稱是Vehicle Monitor Service。正如其名稱所示,這個服務用來監(jiān)測其他進程。在運行時,這個服務是一個獨立的進程,在init.car.rc中有關于它的配置:如果你不熟悉rc文件請閱讀我之前寫過的文章:Android系統(tǒng)啟動:init進程與init語言
servicevms/system/bin/vehicle_monitor_service
classcore
userroot
grouproot
critical

onboot
startvms

這是一個Binder服務,并提供了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 還支持在用戶應用中實現(xiàn)高級功能。

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

caa9057e-2c1a-11ed-ba43-dac502259ad0.png
  • EVS應用:該應用負責從EVS管理器請求視頻幀,并將用于顯示的已完成的幀發(fā)送回EVS管理器。EVS和汽車服務可供使用后,它便立即由init啟動。OEM可視需要修改或替換EVS應用。

  • EVS 管理器:EVS管理器可提供 EVS 應用所需的編譯塊,以實現(xiàn)從簡單的后視攝像頭顯示到6DOF多相機渲染的任何功能。它的接口通過 HIDL呈現(xiàn),并被編譯為接受多個并發(fā)客戶端。其他應用和服務(特別是汽車服務)可以查詢 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 中進行提供。

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

2.6.3 ODB2

源碼:

  • obd2-lib

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

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

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

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

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

cac9cec6-2c1a-11ed-ba43-dac502259ad0.png

2.7 Vehicle Network Service

源碼:

  • vehicle_network_service

  • libvehiclenetwork

Vehicle Network Service的結構和VMS的結構是類似的,也是一個可執(zhí)行文件(vehicle_network_service)加一個庫(libvehiclenetwork)的形式。

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

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

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

publicstaticfinalintVEHICLE_PROPERTY_INFO_VIN=0x00000100;
publicstaticfinalintVEHICLE_PROPERTY_INFO_MAKE=0x00000101;
publicstaticfinalintVEHICLE_PROPERTY_INFO_MODEL=0x00000102;
publicstaticfinalintVEHICLE_PROPERTY_INFO_MODEL_YEAR=0x00000103;
publicstaticfinalintVEHICLE_PROPERTY_INFO_FUEL_CAPACITY=0x00000104;
publicstaticfinalintVEHICLE_PROPERTY_PERF_ODOMETER=0x00000204;
publicstaticfinalintVEHICLE_PROPERTY_PERF_VEHICLE_SPEED=0x00000207;
publicstaticfinalintVEHICLE_PROPERTY_ENGINE_COOLANT_TEMP=0x00000301;
publicstaticfinalintVEHICLE_PROPERTY_ENGINE_OIL_TEMP=0x00000304;
publicstaticfinalintVEHICLE_PROPERTY_ENGINE_RPM=0x00000305;
publicstaticfinalintVEHICLE_PROPERTY_GEAR_SELECTION=0x00000400;
publicstaticfinalintVEHICLE_PROPERTY_CURRENT_GEAR=0x00000401;
publicstaticfinalintVEHICLE_PROPERTY_PARKING_BRAKE_ON=0x00000402;
publicstaticfinalintVEHICLE_PROPERTY_DRIVING_STATUS=0x00000404;
publicstaticfinalintVEHICLE_PROPERTY_FUEL_LEVEL_LOW=0x00000405;
publicstaticfinalintVEHICLE_PROPERTY_NIGHT_MODE=0x00000407;
publicstaticfinalintVEHICLE_PROPERTY_HVAC_FAN_SPEED=0x00000500;
publicstaticfinalintVEHICLE_PROPERTY_HVAC_FAN_DIRECTION=0x00000501;
publicstaticfinalintVEHICLE_PROPERTY_HVAC_TEMPERATURE_CURRENT=0x00000502;
publicstaticfinalintVEHICLE_PROPERTY_HVAC_TEMPERATURE_SET=0x00000503;
publicstaticfinalintVEHICLE_PROPERTY_HVAC_DEFROSTER=0x00000504;
publicstaticfinalintVEHICLE_PROPERTY_HVAC_AC_ON=0x00000505;
publicstaticfinalintVEHICLE_PROPERTY_HVAC_MAX_AC_ON=0x00000506;
publicstaticfinalintVEHICLE_PROPERTY_HVAC_MAX_DEFROST_ON=0x00000507;
publicstaticfinalintVEHICLE_PROPERTY_HVAC_RECIRC_ON=0x00000508;
publicstaticfinalintVEHICLE_PROPERTY_HVAC_DUAL_ON=0x00000509;
publicstaticfinalintVEHICLE_PROPERTY_ENV_OUTSIDE_TEMPERATURE=0x00000703;
publicstaticfinalintVEHICLE_PROPERTY_ENV_CABIN_TEMPERATURE=0x00000704;
publicstaticfinalintVEHICLE_PROPERTY_RADIO_PRESET=0x0000801;
publicstaticfinalintVEHICLE_PROPERTY_AUDIO_FOCUS=0x00000900;
publicstaticfinalintVEHICLE_PROPERTY_AUDIO_VOLUME=0x00000901;
publicstaticfinalintVEHICLE_PROPERTY_AUDIO_VOLUME_LIMIT=0x00000902;
publicstaticfinalintVEHICLE_PROPERTY_AUDIO_ROUTING_POLICY=0x00000903;
publicstaticfinalintVEHICLE_PROPERTY_AUDIO_HW_VARIANT=0x00000904;
publicstaticfinalintVEHICLE_PROPERTY_AP_POWER_STATE=0x00000A00;
publicstaticfinalintVEHICLE_PROPERTY_DISPLAY_BRIGHTNESS=0x00000A01;
publicstaticfinalintVEHICLE_PROPERTY_AP_POWER_BOOTUP_REASON=0x00000A02;
publicstaticfinalintVEHICLE_PROPERTY_HW_KEY_INPUT=0x00000A10;
publicstaticfinalintVEHICLE_PROPERTY_INSTRUMENT_CLUSTER_INFO=0x00000A20;
publicstaticfinalintVEHICLE_PROPERTY_CUSTOM_START=0x70000000;
publicstaticfinalintVEHICLE_PROPERTY_CUSTOM_END=0x73ffffff;
publicstaticfinalintVEHICLE_PROPERTY_INTERNAL_START=0x74000000;
publicstaticfinalintVEHICLE_PROPERTY_INTERNAL_END=0x74ffffff;
publicstaticfinalintVEHICLE_PROPERTY_INTERNAL_AUDIO_STREAM_STATE=0x74000000;
當然,并非所有模塊都有權限設置這些HAL屬性。所以這里需要權限的控制。對于這一點,通過vns_policy.xml來控制。這個文件中定義了每個屬性允許哪個角色訪問,以及訪問權限是只讀(r)還是可讀可寫(rw)。下面是vns_policy.xml中的一個代碼片段:
"VEHICLE_PROPERTY_ENV_OUTSIDE_TEMPERATURE"value="0x00000703">
"AID_SYSTEM"access="r"value="1000"/>


"VEHICLE_PROPERTY_ENV_CABIN_TEMPERATURE"value="0x00000704">
"AID_SYSTEM"access="r"value="1000"/>


"VEHICLE_PROPERTY_RADIO_PRESET"value="0x0000801">
"AID_SYSTEM"access="rw"value="1000"/>


"VEHICLE_PROPERTY_AUDIO_FOCUS"value="0x00000900">
"AID_SYSTEM"access="rw"value="1000"/>
"AID_AUDIOSERVER"access="r"value="1041"/>

2.8 HAL

源碼:

  • hardware/libhardware/include/hardware/vehicle.h

  • hardware/libhardware/modules/vehicle/

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

2.8.1 HAL接口

車載HAL使用以下接口:
  • vehicle_prop_config_t const *(*list_properties)(..., int* num_properties)列出車載 HAL 所支持的所有屬性的配置。車輛網絡服務只會使用受支持的屬性。
  • (*get)(..., vehicle_prop_value_t *data)讀取屬性的當前值。對于區(qū)域屬性,每個區(qū)域都可能具有不同的值。
  • (*set)(..., const vehicle_prop_value_t *data)為屬性寫入相應值。寫入的結果是按屬性進行定義。
  • (*subscribe)(..., int32_t prop, float sample_rate, int32_t zones)監(jiān)視屬性值的變化,回調見下文。
  • (*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 屬性與區(qū)域

每個屬性都由 int32 鍵唯一標識,且具有預定義的類型(value_type):INT32(和數組)、INT64、BOOLEAN、FLOAT(和數組)、字符串、字節(jié)。區(qū)域類型除了值之外還有區(qū)域。車載HAL定義了下面幾種區(qū)域類型:
enumvehicle_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ū)域屬性舉例

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

caef4106-2c1a-11ed-ba43-dac502259ad0.png

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

cb104ed2-2c1a-11ed-ba43-dac502259ad0.png

圖中縮寫說明如下:

  • CS:CarService

  • VNS:VehicleNetworkService

  • VHAL:Vehicle HAL

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

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

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

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

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

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

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

  • 導航,多媒體,消息將是車載系統(tǒng)上最主要的應用類型。

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

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

下一個版本的Android,即Android P很快就會發(fā)布。新的版本將迎來哪些變化,我們一起拭目以待。

審核編輯 :李倩


聲明:本文內容及配圖由入駐作者撰寫或者入駐合作網站授權轉載。文章觀點僅代表作者本人,不代表電子發(fā)燒友網立場。文章及其配圖僅供工程師學習之用,如有內容侵權或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報投訴
  • Android
    +關注

    關注

    12

    文章

    3918

    瀏覽量

    127069
  • 車載系統(tǒng)

    關注

    1

    文章

    131

    瀏覽量

    27088

原文標題:一文聊聊Android在車載上的應用

文章出處:【微信號:智能汽車電子與軟件,微信公眾號:智能汽車電子與軟件】歡迎添加關注!文章轉載請注明出處。

收藏 人收藏

    評論

    相關推薦

    使用TPA3118應用于車載項目遇到的疑問求解

    Offset) 發(fā)生后,要如何恢復?由于TPA3118 PVCC直接連接在車身B+,不可能通過PVCC通斷來恢復。
    發(fā)表于 11-06 06:01

    愛普生可編程晶振SG-8018CB在車載通信設備中的優(yōu)勢

    在當今高速發(fā)展的通信時代,無論是在日常生活還是在出行途中,穩(wěn)定、高效的通信設備都至關重要。而愛普生SG-8018CB晶振以其卓越的性能,在通信設備中發(fā)揮著關鍵作用,尤其在車載環(huán)境下更是表現(xiàn)出色。高
    的頭像 發(fā)表于 10-23 11:07 ?119次閱讀
    愛普生可編程晶振SG-8018CB<b class='flag-5'>在車載</b>通信設備中的優(yōu)勢

    一文揭秘,如何選擇合適的車載用途功率電感?

    在車載應用中,合適的功率電感對于保證車載電子設備的穩(wěn)定性和可靠性至關重要。在上期推文中,我們了解了松下車載用途功率電感 ( PCC )的特點和優(yōu)勢。
    的頭像 發(fā)表于 09-07 09:47 ?200次閱讀
    一文揭秘,如何選擇合適的<b class='flag-5'>車載</b>用途功率電感?

    時鐘晶振在車載系統(tǒng)的應用

    車載汽車電子裝置是汽車環(huán)境下能夠獨立使用的電子裝置。其實車載汽車電子裝置與汽車本身的性能并沒直接關系。它包括GPS導航系統(tǒng)、汽車音響、汽車信息系統(tǒng)、電視娛樂系統(tǒng)、上網設備和車載通信系統(tǒng)等。這些汽車
    的頭像 發(fā)表于 09-06 11:14 ?271次閱讀

    Linux在車載HPC安全方面的工作原理

    隨著汽車智能化和自動駕駛技術的飛速發(fā)展,車載高性能計算(High-Performance Computing, HPC)系統(tǒng)已成為推動汽車產業(yè)革新的核心力量。在此背景下,Linux作為開源操作系統(tǒng)領域的佼佼者,正以其高度靈活性、強大生態(tài)系統(tǒng)以及不斷發(fā)展的安全特性,在車載H
    的頭像 發(fā)表于 08-27 14:58 ?399次閱讀
    Linux<b class='flag-5'>在車載</b>HPC安全方面的工作原理

    MOS管在車載逆變器中的應用

    MOS管(金屬氧化物半導體場效應晶體管)在車載逆變器中的應用方案,是汽車電子領域中的一個重要研究課題。車載逆變器作為將汽車電池的直流電轉換為交流電以供車載電器使用的設備,其性能直接影響到汽車
    的頭像 發(fā)表于 07-24 17:00 ?426次閱讀

    藍牙模塊在車載導航方面的應用知識分析

    藍牙模塊在車載導航方面的應用知識分析 藍牙作為一種近距離通信技術,目前已標配車載行業(yè),如下從以下幾個藍牙協(xié)議方面講述下藍牙車載導航藍牙基礎知識學習介紹 1:HFP 全稱為Hands Free
    的頭像 發(fā)表于 06-21 17:11 ?813次閱讀

    藍牙模塊在車載系統(tǒng)中的應用與集成:現(xiàn)狀、挑戰(zhàn)與未來展望

    模塊在車載系統(tǒng)中的應用,如車載電話、導航等,并探討其與車載系統(tǒng)的集成方式以及面臨的挑戰(zhàn)和未來的發(fā)展方向。 藍牙模塊在車載系統(tǒng)中的應用 車載
    的頭像 發(fā)表于 06-20 17:29 ?465次閱讀

    單管20元,碳化硅在車載OBC普及還有多遠?

    2023年下半年以來,碳化硅單管器件價格已急劇下降至20元左右,碳化硅在車載OBC的普及應用還有多遠?企業(yè)又該如何優(yōu)化現(xiàn)有產品方案以應對即將到來的碳化硅應用潮? 碳化硅方案在車載OBC的應用目前仍以
    的頭像 發(fā)表于 05-29 14:56 ?495次閱讀

    WTK6900G語音識別芯片在車載語音交互氛圍燈的應用案例解析

    隨著智能汽車的快速發(fā)展,車載語音交互技術逐漸成為提升駕駛體驗的關鍵技術之一。傳統(tǒng)的車載燈光控制系統(tǒng)往往依賴于手動操作,不僅操作繁瑣,而且在駕駛過程中容易分散駕駛員的注意力。因此,開發(fā)一種高效、便捷
    的頭像 發(fā)表于 05-17 13:57 ?352次閱讀

    車載數據終端丨車載平板丨車載平板電腦如何保證在港口使用

    車載數據終端是一種能夠在車安裝并連接到車輛系統(tǒng)的智能設備,它可以實現(xiàn)車輛的監(jiān)控、調度、管理等功能。在港口這樣的特殊環(huán)境中,車載數據終端具有以下幾個方面的優(yōu)勢,可以保證其在港口使用:
    的頭像 發(fā)表于 04-12 10:01 ?321次閱讀

    SD NAND:為車載顯示器注入智能與安全的心臟

    SDNAND在車載顯示器的應用在車載顯示器,SDNAND(SecureDigitalNAND)可以有多種應用,其中一些可能包括:導航數據存儲:SDNAND可以用于存儲地圖數據、導航軟件以及
    的頭像 發(fā)表于 03-01 11:32 ?569次閱讀
    SD NAND:為<b class='flag-5'>車載</b>顯示器注入智能與安全的心臟

    車載UPS電源的應用,車載式UPS與普通UPS相比有哪些優(yōu)點?

    車載UPS電源的應用,車載式UPS與普通UPS相比有哪些優(yōu)點? 車載UPS電源的應用: 車載UPS電源是一種可以裝載在車
    的頭像 發(fā)表于 01-10 10:30 ?1034次閱讀

    一種車載DVR整改案例分享

    車載DVR就是車載視頻終端,俗稱車載錄像機它是隨著數字視音頻編碼技術在車應用而發(fā)展起來的一個新興專用產品。
    的頭像 發(fā)表于 12-05 15:02 ?1097次閱讀
    一種<b class='flag-5'>車載</b>DVR整改案例分享

    車載LED獨得“青睞” LED企業(yè)相繼布局車載應用領域

    在過去的一周里,LED企業(yè)相繼在車載應用領域開展新布局。
    的頭像 發(fā)表于 11-25 14:33 ?1627次閱讀