简介

AutoMotive是啥？ 就是google看大家现在都用Android操作系统做中控车机，但是你们每家跟车子沟通的方式都不一样呀，所以它就提供了一个平台给你，把车子的属性定义，值更新，值设置等都分离出来了，上层应用开发的不管下面如何与汽车进行通讯，按照Car API开发就行；各个Tier1/车厂你也不要管我上层如何实现，按照底层标准接口，对接实现通讯就完事。

架构

Android 9.0中的Vehicle模块实现相对8.0有了一定的变化，其实现的架构图如下所示，像HVAC这一类的，就是上层应用的具体实现，car-lib是一个java的分享库，是提供API提供给app调用设置以及查询汽车属性的，CarService是一个服务层，编译出来就是类似于SystemUI这种系统级服务应用，该服务内部了定义了诸多的子服务来与系统通信，与hal层的vehicle通信。hidl interface层主要是提供连两个接口定义文件，一个是IVehicle.hal，另外一个是IVehicleCallBack.hal; 前面一个是定义了Service层访问hal层的接口，后面一个顾名思义就是Hal层回调数据到Service层的回调接口。.hal文件是Android 8.0开始加入的hidl接口定义文件。关于hidl，后续在framework专栏里面再梳理一下。hal层的实现定义在hardware/interface/automotive里面，这里按照以前的话讲，叫做硬件抽象层。升级到8.0以后，原来以共享库存在，并提供jni的方式给到应用访问的方式叫做直通式访问，vhal给到应用的访问方式是通过hwservicemanager来进行的，这种方式叫做绑定式访问。各层编译出来的产物，以及路径定义如下：

功能： 上层API库
代码位置：/platform/packages/services/Car/car-lib
编译产物： android.car.jar

功能： 服务层
代码位置： /platform/packages/services/Car/service
编译产物： CarService.apk

功能： hidl通信接口
代码位置： /platform/hardware/interface/automotive/vehicle/2.0
Android.bp
IVehicleCallback.hal
IVehicle.hal
types.hal
编译产物： android.hardware.automotive.vehicle-V2.0-java.jar
android.hardware.automotive.vehicle@2.0.so

功能： hal层具体实现
代码位置： /platform/hardware/interface/automotive/vehicle/2.0/default
编译产物： 可执行文件 android.hardware.automotive.vehicle@2.0-service
动态库 android.hardware.automotive.vehicle@2.0-manager-lib.so
静态库 android.hardware.automotive.vehicle@2.0-default-impl-lib.a

功能流程

Hal层功能：首先看一下整个hal层中的vehicle模块代码目录。

这是vhal层的实现，首先一步步来看, 分析Android.bp文件，我们就知道该模块下哪些文件对应的被编译成了哪些产物。Android.bp里面一共配置编译了三个产物，其中包括一个动态库，对应如下：

// Vehicle reference implementation lib
cc_library {srcs: ["common/src/Obd2SensorStore.cpp","common/src/SubscriptionManager.cpp","common/src/VehicleHalManager.cpp","common/src/VehicleObjectPool.cpp","common/src/VehiclePropertyStore.cpp","common/src/VehicleUtils.cpp","common/src/VmsUtils.cpp",],
}

以上包含的cpp文件将会被编译后将会生成名为android.hardware.automotive.vehicle@2.0-manager-lib的库文件，名称太长了，姑且称之为manager-lib左先锋；

接下来另外一个

// Vehicle default VehicleHAL implementationsrcs: ["impl/vhal_v2_0/EmulatedVehicleHal.cpp","impl/vhal_v2_0/VehicleEmulator.cpp","impl/vhal_v2_0/PipeComm.cpp","impl/vhal_v2_0/SocketComm.cpp","impl/vhal_v2_0/LinearFakeValueGenerator.cpp","impl/vhal_v2_0/JsonFakeValueGenerator.cpp",],

以上几个文件将会被编译成一个名为
android.hardware.automotive.vehicle@2.0-default-impl-lib的库文件，名称也太长了，姑且称之为impl-lib右先锋。

大家都知道左右先锋都是归中军帐下，为元帅所有，所以这两个库跟VehicleService.cpp文件最终被一起编译成android.hardware.automotive.vehicle@2.0-service这个可执行文件，这里称它为service大帅。

众所周知，大帅一般要有虎符以及皇帝的命令才会调兵遣将，开始工作，android.hardware.automotive.vehicle@2.0-service.rc 这个玩意就类似皇帝密令，开机的时候，init进程扫到这个文件之后，会调用其中的命令拉起service大帅运行。

这里还要介绍一下左右先锋的作用，manager-lib左先锋主要负责与空中系统的通讯，就是我们所说的上层，VehicleHalManager类正是集成了IVehicle接口，所以只有它有天线，基本能够实现上下通达；另外还有一个数据缓存的功能；另外一个类基本就是一些数据订阅管理，还有工具类，实现一些模块的基础。

impl-lib右先锋是一个虚拟车身属性模块的实现，从它的组成就知道，骨血里流的都是Emulator， EmulatedVehicleHal是VehicleHal类的子类，而VehicleHal这个类，正是Android定义给我们自行客制化实现hal层功能的interface. 所以这里，右先锋是一个模拟车身通讯实现。所以这里右先锋是不能上战场的，它是个泥菩萨，只能跟模拟器玩玩，我们后期要么改造它，要么仿制它。

介绍完了之后，按照启动过程，来看下它的运行流程。

首先，我们知道可执行模块的入口，那必定是main函数，我们大帅的main函数就在VehicleService.cpp这个文件中，这个文件的内容比较简单，可以看下

int main(int /* argc */, char* /* argv */ []) {auto store = std::make_unique<VehiclePropertyStore>();auto hal = std::make_unique<impl::EmulatedVehicleHal>(store.get());auto emulator = std::make_unique<impl::VehicleEmulator>(hal.get());auto service = std::make_unique<VehicleHalManager>(hal.get());configureRpcThreadpool(4, true /* callerWillJoin */);ALOGI("Registering as service...");status_t status = service->registerAsService();if (status != OK) {ALOGE("Unable to register vehicle service (%d)", status);return 1;}ALOGI("Ready");joinRpcThreadpool();return 1;
}

把代码翻译成汉语,流程如下：
1.初始化VehiclePropertyStore，得到store指针
2.初始化EmulatedVehicleHal，得到hal指针，初始化时，将VehiclePropertyStore指针作为参数传输了EmulatedVehicleHal构造方法中
3.初始化VehicleEmulator，得到emulator指针，初始化时，将EmulatedVehicleHal指针作为参数传入VehicleEmulator的构造方法中。
4.初始化VehicleHalManager，获得service智能指针。
5.之前介绍了VehicleHalManager继承自IVehicle hidl接口，该接口在编译的时候自动生成了registerAsService方法，该方法就是将服务本身通过binder注册到hwservicemanager里面供其他进程连接。这里不再深入介绍。

这里初始化模块总共只有那么几个东东，我们来一个个分析。首先是VehiclePropertyStore, 在看它之前，首先了解几个数据结构，

/*** Encapsulates the property name and the associated value. It* is used across various API calls to set values, get values or to register for* events.*/
struct VehiclePropValue {/** Time is elapsed nanoseconds since boot */int64_t timestamp;/*** Area type(s) for non-global property it must be one of the value from* VehicleArea* enums or 0 for global properties.*/int32_t areaId;/** Property identifier */int32_t prop;/** Status of the property */VehiclePropertyStatus status;/*** Contains value for a single property. Depending on property data type of* this property (VehiclePropetyType) one field of this structure must be filled in.*/struct RawValue {/*** This is used for properties of types VehiclePropertyType#INT* and VehiclePropertyType#INT_VEC*/vec<int32_t> int32Values;/*** This is used for properties of types VehiclePropertyType#FLOAT* and VehiclePropertyType#FLOAT_VEC*/vec<float> floatValues;/** This is used for properties of type VehiclePropertyType#INT64 */vec<int64_t> int64Values;/** This is used for properties of type VehiclePropertyType#BYTES */vec<uint8_t> bytes;/** This is used for properties of type VehiclePropertyType#STRING */string stringValue;};RawValue value;
};

VehiclePropValue 作为一个数据结构包含属性名称和关联的值。它
用于各种API调用，以设置值、获取值或注册事件。

struct VehiclePropConfig {/** Property identifier */int32_t prop;/*** Defines if the property is read or write or both.*/VehiclePropertyAccess access;/*** Defines the change mode of the property.*/VehiclePropertyChangeMode changeMode;/*** Contains per-area configuration.*/vec<VehicleAreaConfig> areaConfigs;/** Contains additional configuration parameters */vec<int32_t> configArray;/*** Some properties may require additional information passed over this* string. Most properties do not need to set this.*/string configString;/*** Min sample rate in Hz.* Must be defined for VehiclePropertyChangeMode::CONTINUOUS*/float minSampleRate;/*** Must be defined for VehiclePropertyChangeMode::CONTINUOUS* Max sample rate in Hz.*/float maxSampleRate;
};

VehiclePropConfig 是车身属性值配置。以上两个数据结构均定义在type.hal文件中，type.hal文件是hidl定义数据结构的文件，在编译时会自动生成对应的数据结构，了解了这两个数据结构的内容之后，再看看下VehiclePropertyStore中怎么用的，首先也从数据接口开始切入，再VehiclePropertyStore.h文件中，定义了如下结构体

     struct RecordConfig {VehiclePropConfig propConfig;TokenFunction tokenFunction;};struct RecordId {int32_t prop;int32_t area;int64_t token;bool operator==(const RecordId& other) const;bool operator<(const RecordId& other) const;}

RecordConfig可以理解为属性记录配置，RecordId可以理解为属性记录id.

定义了一个PropertyMap的map表来保存属性值。

  using PropertyMap = std::map<RecordId, VehiclePropValue>;PropertyMap mPropertyValues;  // Sorted map of RecordId : VehiclePropValue.

定义了一个无序map来保存属性配置

 std::unordered_map<int32_t /* VehicleProperty */, RecordConfig> mConfigs;

既然知道了保存的值是什么，保存在哪里了，接下来看看store的增删查改。

注册属性：

void VehiclePropertyStore::registerProperty(const VehiclePropConfig& config,VehiclePropertyStore::TokenFunction tokenFunc) {MuxGuard g(mLock);//很简单，mConfigs键值对插入key为config.prop， 值为RecordConfig， RecordConfig是个结构体，成员就是VehiclePropConfig跟一个函数指针。mConfigs.insert({ config.prop, RecordConfig { config, tokenFunc } });
}

写入属性值:

bool VehiclePropertyStore::writeValue(const VehiclePropValue& propValue,bool updateStatus) {MuxGuard g(mLock);//首先从键值对的key集合里面查看是否当前需要写入属性值的属性id是否已经注册，如果当前属性id没有注册，则返回false，写入失败。if (!mConfigs.count(propValue.prop)) return false;
//查找RecordIdRecordId recId = getRecordIdLocked(propValue);//根据RecordId从map中获取Value值VehiclePropValue* valueToUpdate = const_cast<VehiclePropValue*>(getValueOrNullLocked(recId));//如果当前没有保存该属性，则加入一条新的记录，否则的话，更新对应的值if (valueToUpdate == nullptr) {mPropertyValues.insert({ recId, propValue });} else {valueToUpdate->timestamp = propValue.timestamp;valueToUpdate->value = propValue.value;if (updateStatus) {valueToUpdate->status = propValue.status;}}return true;
}

属性临时存储的增删改查基本都差不多，都是操作map, 这个不多说了，感兴趣的朋友可以自行查阅VehiclePropertyStore.cpp这个文件。

上面介绍了属性值临时保存方式，接下来看下EmulatedVehicleHal这个类，该类继承自EmulatedVehicleHal接口，而该接口又继承自VehicleHal，上文说过，VehicleHal接口是android定义在hal层用于实现VHal相关功能的接口。 因此EmulatedVehicleHal就里就实现了类似车身数据管理的功能。

首先看下其初始化的构造函数：

EmulatedVehicleHal::EmulatedVehicleHal(VehiclePropertyStore* propStore): mPropStore(propStore),mHvacPowerProps(std::begin(kHvacPowerProperties), std::end(kHvacPowerProperties)),//mRecurrentTimer是一个工具类，内部维护一个线程，用来处理指定时间触发的事件，这个跟上层的Handler比较类似。mRecurrentTimer(std::bind(&EmulatedVehicleHal::onContinuousPropertyTimer, this, std::placeholders::_1)),
//LinearFakeValueGenerator是一个模拟事件生成器，内部跟RecurrentTimer相互配合      mLinearFakeValueGenerator(std::make_unique<LinearFakeValueGenerator>(std::bind(&EmulatedVehicleHal::onFakeValueGenerated, this, std::placeholders::_1))),//JsonFakeValueGenerator跟LinearFakeValueGenerator类似，不过它是根据json配置产生假事件mJsonFakeValueGenerator(std::make_unique<JsonFakeValueGenerator>(std::bind(&EmulatedVehicleHal::onFakeValueGenerated, this, std::placeholders::_1))) {//注册DefaultConfig.h中定义的属性值initStaticConfig();for (size_t i = 0; i < arraysize(kVehicleProperties); i++) {mPropStore->registerProperty(kVehicleProperties[i].config);}
}

构造函数完事之后，简单看下VHal接口中的set/get/subscribe是怎么实现的

VehicleHal::VehiclePropValuePtr EmulatedVehicleHal::get(const VehiclePropValue& requestedPropValue, StatusCode* outStatus) {//当前我们要拿的属性值的属性ID是多少auto propId = requestedPropValue.prop;//这个pool是一个用于存储VehiclePropValue的对象池，这个跟Message的实现好像。auto& pool = *getValuePool();VehiclePropValuePtr v = nullptr;//这个就是根据propId来获取值了，OBD2_FREEZE_FRAME是OBD检测到故障信//息，OBD2_FREEZE_FRAME_INFO是故障检测到得时间戳。一般要获取OBD2_FREEZE_FRAME的数据之前，都要通过OBD2_FREEZE_FRAME_INFO获取时间戳。//除了这两个属性值，其他的都直接从临时的Store里面获取当前属性的状态值。switch (propId) {case OBD2_FREEZE_FRAME:v = pool.obtainComplex();*outStatus = fillObd2FreezeFrame(requestedPropValue, v.get());break;case OBD2_FREEZE_FRAME_INFO:v = pool.obtainComplex();*outStatus = fillObd2DtcInfo(v.get());break;default:auto internalPropValue = mPropStore->readValueOrNull(requestedPropValue);if (internalPropValue != nullptr) {v = getValuePool()->obtain(*internalPropValue);}*outStatus = v != nullptr ? StatusCode::OK : StatusCode::INVALID_ARG;break;}return v;
}

分析完了get函数，接下来就是set函数了，按照国际惯例，先贴代码，再分析，这个函数代码有点长，主要是各种判断，下面依次看下每个步骤都干啥了。

StatusCode EmulatedVehicleHal::set(const VehiclePropValue& propValue) {//这个常量定义为false,是因为这个set函数是给上层调用的，Android层//不能够改变属性值的状态，只有车身发送了该属性值过来了，才可改变//属性状态，这个在下面会有体现。static constexpr bool shouldUpdateStatus = false;//这段代码用于测试的，生产一个假的数据请求事件。if (propValue.prop == kGenerateFakeDataControllingProperty) {StatusCode status = handleGenerateFakeDataRequest(propValue);if (status != StatusCode::OK) {return status;}} else if (mHvacPowerProps.count(propValue.prop)) {//这里是判断当前属性值是否属于空调电源开关，如果是的情况下，去拿它值，如果当前开关没开，则返回当前状态不可用，设置失败的CODEauto hvacPowerOn = mPropStore->readValueOrNull(toInt(VehicleProperty::HVAC_POWER_ON),(VehicleAreaSeat::ROW_1_LEFT | VehicleAreaSeat::ROW_1_RIGHT |VehicleAreaSeat::ROW_2_LEFT | VehicleAreaSeat::ROW_2_CENTER |VehicleAreaSeat::ROW_2_RIGHT));if (hvacPowerOn && hvacPowerOn->value.int32Values.size() == 1&& hvacPowerOn->value.int32Values[0] == 0) {return StatusCode::NOT_AVAILABLE;}} else {// Handle property specific codeswitch (propValue.prop) {case OBD2_FREEZE_FRAME_CLEAR:return clearObd2FreezeFrames(propValue);case VEHICLE_MAP_SERVICE:// Placeholder for future implementation of VMS property in the default hal. For// now, just returns OK; otherwise, hal clients crash with property not supported.return StatusCode::OK;case AP_POWER_STATE_REPORT:// This property has different behavior between get/set.  When it is set, the value//  goes to the vehicle but is NOT updated in the property store back to Android.// Commented out for now, because it may mess up automated testing that use the//  emulator interface.// getEmulatorOrDie()->doSetValueFromClient(propValue);return StatusCode::OK;}}//status默认值为AVAILABLEif (propValue.status != VehiclePropertyStatus::AVAILABLE) {// Android side cannot set property status - this value is the// purview of the HAL implementation to reflect the state of// its underlying hardwarereturn StatusCode::INVALID_ARG;}//读取该属性值id的当前存储的Propauto currentPropValue = mPropStore->readValueOrNull(propValue);if (currentPropValue == nullptr) {return StatusCode::INVALID_ARG;}//如果目前属性值状态不可用，则上层不能设置，返回失败if (currentPropValue->status != VehiclePropertyStatus::AVAILABLE) {// do not allow Android side to set() a disabled/error propertyreturn StatusCode::NOT_AVAILABLE;}//更新属性值，开头说过，shouldUpdateStatus为false, 也就是android层更新属性值，不改变属性状态if (!mPropStore->writeValue(propValue, shouldUpdateStatus)) {return StatusCode::INVALID_ARG;}//通知汽车，设置属性值，这里是告诉模拟器，该值需要重新设置，调用的这个函数等下再说。getEmulatorOrDie()->doSetValueFromClient(propValue);return StatusCode::OK;
}

通过set函数我们知道，属性值的设置，先将属性值写入到内存中保存，然后再通知车身更新该属性值，doSetValueFromClient这个函数就实现了相关的功能，这里暂且按下不表。这个set事件是来自上层service的调用，那车身信息如果发生变化时，如何set呢，答案是该模块还有一个名称setPropertyFromVehicle的函数，正是这个函数实现了车身数据变化之后，更新缓存的属性，并通知上层。

bool EmulatedVehicleHal::setPropertyFromVehicle(const VehiclePropValue& propValue) {static constexpr bool shouldUpdateStatus = true;if (propValue.prop == kGenerateFakeDataControllingProperty) {StatusCode status = handleGenerateFakeDataRequest(propValue);if (status != StatusCode::OK) {return false;}}//更新属性值，注意这个shouldUpdateStaus为true,也就是要更新属性的status, //刚刚上面那个set函数该值为false,这是为啥？ 因为属性值只有由车身改变的时候才能改变其状态值，android层不行。if (mPropStore->writeValue(propValue, shouldUpdateStatus)) {//触发回调，通知上层doHalEvent(getValuePool()->obtain(propValue));return true;} else {return false;}
}

既然车身属性设置，跟上层设置都讲完了，下面看下该模块的属性值订阅实现，老规矩，贴代码：

StatusCode EmulatedVehicleHal::subscribe(int32_t property, float sampleRate) {ALOGI("%s propId: 0x%x, sampleRate: %f", __func__, property, sampleRate);if (isContinuousProperty(property)) {mRecurrentTimer.registerRecurrentEvent(hertzToNanoseconds(sampleRate), property);}return StatusCode::OK;
}

这个个代码比较简单，传输的参数有两个 property是属性ID，sampleRate是属性值更新的频率。 isContinuousProperty主要是判断该属性值的change类型是不是连续类型的，如果是连续类型的，就向RecurrentTimer中注册事件。RecurrentTimer是一个工具类，具体代码这里就不分析了，可以自行查阅，可以把它理解为一个另类的Handler, 其内部运行着一个线程维护着一个循环，当向其注册一个事件时，内部根据事件频率算出触发事件的事件，然后定期触发回调方法，跟Handler唯一不同的是，Handler的sendMesssageAtTime发完就没了，这个RecurrentTimer是如果你注册了事件，如果不取消注册，则事件会一直定期触发。

这里说了RecurrentTimer有个触发回调，那我们订阅了一个属性id，当达到时间后，触发的是哪个回调呢？ 当然是EmulatedVehicleHal中的onContinuousPropertyTimer函数啦，这个函数指针在EmulatedVehicleHal初始化的时候，就作为参数传给RecurrentTimer，然后在这个函数中调用 doHalEvent(std::move(v)); 触发回调事件，将属性值上报。doHalEvent中其实没做啥，可以看下它的代码

    void doHalEvent(VehiclePropValuePtr v) {mOnHalEvent(std::move(v));}

这里mOnHalEvent是一个函数指针，其对应函数定义在VehicleHalManager中，如下

void VehicleHalManager::onHalEvent(VehiclePropValuePtr v) {mEventQueue.push(std::move(v));
}

最终由BatchingConsumer取出该事件，回调给上层；mOnHalEvent函数指针再VehicleHalManager初始化的时候，会将其作为参数传给EmulatedVehicleHal

写到这里， 基本上把hal层数据管理讲的差不多了；算一下，还剩下两个点，一个点是上层service如何跟hal层通信，一个是hal层如何跟车身通信。

Vhal如何跟VService进行数据交互？
上文介绍过，实现IVehicle接口的天线宝宝是谁？ 就是VehicleHalManager这个宝宝，先看下IVehicle.hal通过hidl-gen生成的接口文件中定义了哪些方法, 大概摘录了其中主要的一些方法定义，如下：

getAllPropConfigs作用是获取所有的属性配置，对应实现在VehicleHalManager中的getlAllPropConfigs方法，代码如下：

Return<void> VehicleHalManager::getAllPropConfigs(getAllPropConfigs_cb _hidl_cb) {ALOGI("getAllPropConfigs called");//_hidl_cb是一个函数指针，定义在IVehicle.h里面hidl_vec<VehiclePropConfig> hidlConfigs;//从vector集合中读取所有当前的属性配置数据auto& halConfig = mConfigIndex->getAllConfigs();//写入到集合中hidlConfigs.setToExternal(const_cast<VehiclePropConfig *>(halConfig.data()),halConfig.size());//回调将数据发送到上层_hidl_cb(hidlConfigs);return Void();
}

上面这个函数是上层获取当前hal层支持的所有属性配置，接下来看根据属性id获取属性配置，对应的函数为getPropConfigs，代码如下：

Return<void> VehicleHalManager::getPropConfigs(const hidl_vec<int32_t> &properties,getPropConfigs_cb _hidl_cb) {//这个函数也比较简单，基本上就是判断当前属性id是否已经默认配置了，如果存在，则保存配置到集合中，否则的话，就针对未配置的属性id上报状态错误的消息。std::vector<VehiclePropConfig> configs;for (size_t i = 0; i < properties.size(); i++) {auto prop = properties[i];if (mConfigIndex->hasConfig(prop)) {configs.push_back(mConfigIndex->getConfig(prop));} else {ALOGW("Requested config for undefined property: 0x%x", prop);_hidl_cb(StatusCode::INVALID_ARG, hidl_vec<VehiclePropConfig>());}}_hidl_cb(StatusCode::OK, configs);return Void();
}

上面两个是关于属性配置获取的，属性配置跟属性值的区别是啥，一个是描述你这个配置的一些行为，如访问权限，更新最大的频率等；一个是用于具聚合一些具体值信息的载体，下面看一下属性值的设置跟获取，set/get函数，首先是set函数

//这个函数是上层调用set设置属性值的时候，参数value来自上层
Return<StatusCode> VehicleHalManager::set(const VehiclePropValue &value) {auto prop = value.prop;//获取属性配置const auto* config = getPropConfigOrNull(prop);//如果获取不到这个属性ID的配置，就证明当前hal层没配这个属性值，也就是不支持它if (config == nullptr) {ALOGE("Failed to set value: config not found, property: 0x%x", prop);return StatusCode::INVALID_ARG;}
//检查权限，上面说了，属性配置里面有关于访问权限的值定义，如果该属性值定义的配置不支持写权限，那就返回失败if (!checkWritePermission(*config)) {return StatusCode::ACCESS_DENIED;}//告诉上层订阅了该属性id的监听器，该值有更新。handlePropertySetEvent(value);//这里就到了上面介绍EmulatorVehicleHal中的set函数auto status = mHal->set(value);return Return<StatusCode>(status);
}

接下来是get函数，获取属性值

Return<void> VehicleHalManager::get(const VehiclePropValue& requestedPropValue, get_cb _hidl_cb) {
//逻辑跟set差不读，先获取属性配置，然后再检查权限，最后从缓存中取值。const auto* config = getPropConfigOrNull(requestedPropValue.prop);if (config == nullptr) {ALOGE("Failed to get value: config not found, property: 0x%x",requestedPropValue.prop);_hidl_cb(StatusCode::INVALID_ARG, kEmptyValue);return Void();}if (!checkReadPermission(*config)) {_hidl_cb(StatusCode::ACCESS_DENIED, kEmptyValue);return Void();}StatusCode status;auto value = mHal->get(requestedPropValue, &status);_hidl_cb(status, value.get() ? *value : kEmptyValue);return Void();
}

get函数跟set函数最终都是EmulatorVehicleHal.cpp中去执行具体的数据更新。基本上讲到这里，咱们VHal层的功能，除了具体跟车身通讯相关的部分没讲，其他的都说完了，对照下图，简单的总结一下。

VHal中的VehicleHalManager跟上层进行数据通讯，包括数据回调，跟上层调用，都均由此实现。
EmulatorVehicleHal模块承接了VehicleHalManager中的一部分属性值设置获取的功能，当上层设置值的时候，EmulatorVehicleHal会去更新内存中缓存的值，然后通知车身；当车身有数据更新时，也会该模块更新缓存值，并触发回调，通知上层。

VehicleEmulator这里不准备总结了，这个通讯实现比较简单，主要是运用Pipe管道或者socket通讯的方式，跟模拟器之间收发通过protobuf封装的数据，模块内部实现了protobuf数据的解析与封装，用来触发设置，获取属性值的事件等。

至此，VHal模块所实现的功能，均总结完毕，下一篇总结一个上层Car Service的实现。

写的不是很好，各位同行如果有了解，可以加微信一起交流。