Android與汽車

paulquei發表於2018-07-12

Android

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

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接到汽車螢幕上其介面看起來是下面這個樣子：

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

核心功能

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

從上面的兩幅圖中可以看到，無論是汽車螢幕還是手機螢幕，介面底部包含了四個相同的按鈕（雖然位置不同）。

以手機介面的按鈕順序，這四個按鈕的功能依次是：

回主介面
地圖功能
通話功能
音樂功能

Google Assistant

2007年，iPhone的釋出宣示了觸控互動方式的興起。在這之後，觸控手勢徹底代替了物理鍵盤。

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

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

在駕駛環境中，語音互動存在如下優勢：

使用者不用改變自身的物理姿勢，所以這種互動方式不影響對於駕駛的操控。
有些需要多次觸控手勢的互動，可能一條語音就可以完成。
語音互動不存在入口的層次巢狀，資料更加扁平。
優秀的語音系統可以利用對話的上下文完成任務，避免使用者重複輸入。

除此之外，在駕駛環境中，對於語音功能的實現也更有利。因為，駕駛艙的空間較小，便於語音資料的捕獲；駕駛艙座位的相對位置固定，系統更方便判斷髮出語音的角色，例如區分發出語音指令的是駕駛員還是乘客而採取不同的處理。

這就不奇怪Google將Google Assistant整合到Android Auto中了。

當語音系統能夠獲取到使用者的基本資訊的情況下，很多操作會變得非常便利。例如，直接告訴系統：”我要回家“。而不用先開啟地圖，然後搜尋自己家的地址，然後再點選導航按鈕：

當系統有了更多的使用者的資料以及外部服務之後，可以做的事情將超遠我們現在看到的。例如：在導航至某個餐館的途中直接幫忙預訂座位（今年的Google I/O上，Google已經展示了通過AI完成的電話預訂：Google`s AI Assistant Can Now Make Real Phone Calls）。

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

相容的車型和應用

現代汽車是首個支援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。

App

開發

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

音訊應用：允許使用者瀏覽和播放汽車中的音樂和語音內容。
訊息應用：通過text-to-speech朗讀訊息並通過語音輸入回覆訊息。

為了宣告應用支援Android Auto，需要在/res/xml/新建一個XML檔案來進行描述。

例如，假設我們建立的檔案是automotive_app_desc.xml，其內容是：

<automotiveApp>
   <uses name="media" />
</automotiveApp>

這裡通過<uses>標籤描述了應用所使用的特性：media。name屬性目前僅支援兩個值：

media：該應用使用Android框架API在車輛中播放音樂。
notification：該應用在汽車的主螢幕中顯示訊息通知，允許使用者選擇要朗讀的訊息，並讓他們通過語音輸入進行響應。

定義完成該檔案之後，需要在AndroidManifest.xml中指定：

<application>

    ...
    <meta-data android:name="com.google.android.gms.car.application"
     android:resource="@xml/automotive_app_desc"/>

</application>

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

設計

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

基本的指導原則包括：

Android Auto上的互動步調必須由駕駛員控制。
汽車介面上的觸控目標必須足夠大，以便可以輕鬆地瀏覽和點按。
適當的色彩對比可幫助駕駛員快速解讀資訊並做出決定。
應用必須支援夜間模式，因為過高的亮度可能會干擾注意力。
Roboto字型在整個系統中用於保持一致性並幫助提高可讀性。
通過觸控來進行分頁應該用來作為滑動翻頁的補充。
謹慎和有選擇地使用影像。
有節制的使用動畫來描述兩個狀態之間的變化。

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

版本演進

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

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

無線

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

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

在功耗和傳輸效能的限制下，有線設計只是暫時的妥協。不過一旦這些限制逐漸縮小，無線功能自然就會出現了。所以Google在今年提出了無線Android Auto。可以看一下這個連結：Wireless Android Auto is available for Google phones。

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

Android Automotive

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

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

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

可以看一下下面的兩個連結：

不過，據報導中的資訊，這類產品兩年之內恐怕都不會上市。

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

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

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

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

原始碼與架構

Android Automative的原始碼包含在AOSP中。

關於AOSP以及如何獲取原始碼可以參見其官方網站：https://source.android.com，這裡不再贅述。

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

這裡是Android Automative的一些文件。

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

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

包括：

Car App：包括OEM和第三方開發的App
Car API：提供給汽車App特有的介面
Car Service：系統中與車相關的服務
Vehicle Network Service：汽車的網路服務
Vehicle HAL：汽車的硬體抽象層描述

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

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。

Car API

原始碼：/platform/packages/services/Car/car-lib

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

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

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

android.car：包含了與車相關的基本API。例如：車輛後視鏡，門，座位，視窗等。
- annotation：包含了兩個註解。
- app
  - menu：車輛應用選單相關API。
- cluster：儀表盤相關API。
  - render：渲染相關API。
- content
  - pm：應用包相關API。
- diagnostic：包含與汽車診斷相關的API。
- hardware：車輛硬體相關API。
  - cabin：座艙相關API。
  - hvac：通風空調相關API。（hvac是Heating, ventilation and air conditioning的縮寫）
  - property：屬性相關API。
  - radio：收音機相關API。
- input：輸入相關API。
- media：多媒體相關API。
- navigation：導航相關API。
- settings：設定相關API。
- vms：汽車監測相關API，見下文。

Car Service

原始碼：

Car service

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

<manifest xmlns:android="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屬性使得這個應用具有系統許可權。

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());
    
    ...

Car Tool

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

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介面用來供其他模組使用。

EVS

原始碼：

evs

Android 8.0包含一個汽車 HIDL 硬體抽象層（HAL），可用於在 Android 啟動過程的初期提供影像捕獲和顯示，並在系統啟動後繼續執行直到系統終止。HAL包含外部視景系統 (Exterior View System，簡稱EVS) 堆疊，通常用於在具有車載資訊娛樂（IVI）系統（基於 Android）的車輛中支援後視攝像頭和環繞檢視顯示。EVS 還支援在使用者應用中實現高階功能。

EVS 包括以下系統元件：

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。

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靜態庫的形式存在的。

它支援多種命令。這些命令按照型別實現在不同的檔案中：

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中的一個程式碼片段：

<PROPERTY name="VEHICLE_PROPERTY_ENV_OUTSIDE_TEMPERATURE" value = "0x00000703">
<UID name="AID_SYSTEM" access="r" value="1000"/>
</PROPERTY>

<PROPERTY name="VEHICLE_PROPERTY_ENV_CABIN_TEMPERATURE" value = "0x00000704">
<UID name="AID_SYSTEM" access="r" value="1000"/>
</PROPERTY>

<PROPERTY name="VEHICLE_PROPERTY_RADIO_PRESET" value = "0x0000801">
<UID name="AID_SYSTEM" access="rw" value="1000"/>
</PROPERTY>

<PROPERTY name="VEHICLE_PROPERTY_AUDIO_FOCUS" value = "0x00000900">
<UID name="AID_SYSTEM" access="rw" value="1000"/>
<UID name="AID_AUDIOSERVER" access="r" value="1041"/>
</PROPERTY>

HAL

原始碼：

hardware/libhardware/include/hardware/vehicle.h

hardware/libhardware/modules/vehicle/

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

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重新啟動，這可能導致包括應用在內的其他元件重新啟動。

屬性與區域

每個屬性都由 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,
};

處理區域屬性舉例

下面是獲取HVAC溫度的呼叫過程。

下面是設定HAVC溫度的呼叫過程。

圖中縮寫說明如下：

CS：CarService
VNS：VehicleNetworkService
VHAL：Vehicle HAL

結束語

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

保持駕駛安全永遠是第一重要，任何新功能的增加都必須先考慮這個原則。
車載系統不是手機系統的簡單移植，手機上的應用大部分也不適合車載系統。
車機硬體差異太大，平臺需要處理好差異性。
互動方式需要用心對待，以便讓使用者更容易操作。
介面設計上也需要通過色彩或控制元件大小以突出重點，讓使用者更容易辨識。
語音將是車載系統上很重要的互動方式。
導航，多媒體，訊息將是車載系統上最主要的應用型別。
無線通訊是未來，隨著硬體傳輸速度的提升，各種線纜將盡可能的減少。
車載系統將脫離手機，內建的原生系統能獲得更好的體驗。

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

參考資料與推薦讀物

探索未來智慧交通：網聯汽車與汽車互聯
2023-05-19
福特打算用手錶操作汽車：可穿戴與智慧汽車相結合
2016-01-14
豐田與電信廠商合作5G加速自動駕駛，讓汽車與汽車進行交流
2018-03-08
自動駕駛
[Flutter翻譯]eBay汽車與狀態管理
2021-04-01
Flutter
變更管理與汽車研發應用
2019-01-04
中國汽車流通協會： 2022汽車流通行業回述與展望
2023-04-13
行業
Android 與 Lua
2018-11-16
Android
GIFView與Android
2018-02-25
ViewAndroid
谷歌禁止廠商定製Android汽車和手錶平臺
2014-06-30
谷歌Android
共享汽車APP開發的功能與優勢
2021-03-02
APP
亞太與奇瑞簽署智慧汽車合作協議
2016-07-13
協議
築道與尋術：華為雲與汽車產業的時代問答
2022-11-22
產業
把握汽車行業的變與不變，汽車之家如何打造新的增長樣板？
2022-11-08
行業
賦能汽車安全｜綠盟科技出席第四屆中國汽車安全與召回技術論壇
2021-10-25
中國汽車與共享出行：智慧駕駛艙（附下載）
2021-02-22
蘋果與大眾汽車洽談聯手打造iCar
2007-09-24
蘋果
當汽車成為智慧終端：三個視角看“汽車運營”的機會與屏障
2018-11-13
汽車與汽車零部件行業：汽車零部件成長性的三大驅動力（附下載）
2018-03-08
行業
Apache Flink 在汽車之家的應用與實踐
2021-11-05
Apache
亞馬遜與菲亞特合作開始網站上銷售汽車
2016-11-19
亞馬遜網站
Android之Window與WindowManager
2019-03-01
Android
Android 與前端互動
2018-02-27
Android前端
Android與JS互調
2017-09-04
AndroidJS
android 拖拽與縮放
2015-08-14
Android
谷歌與蘋果的競爭擴充套件到汽車領域
2014-02-08
谷歌蘋果套件
汽車破解
2023-04-02
Flutter 與 Android 的互動
2019-05-13
FlutterAndroid
Android 動畫介紹與使用
2019-05-10
Android動畫
capt 與 Android Gradle Plugin
2019-01-07
APTAndroidGradlePlugin
Android與ARM處理器
2020-12-01
Android
RN 與android原生互動
2018-01-17
Android
Android程式與執行緒
2017-04-01
Android執行緒
Android中的IntentFilter與安全
2017-11-09
AndroidIntentFilter
Android 之 zygote 與程式建立
2013-11-15
AndroidGo
Android 元件化探索與思考
2017-08-02
Android元件化
Android layer type與WebView白屏
2015-02-01
AndroidWebView
Android: HttpClient與Webview共享cookies
2015-03-11
AndroidHTTPclientWebViewCookie
android httpclient與webview cookie同步
2015-03-11
AndroidHTTPclientWebViewCookie