Android Automotive介绍
Android Automotive是⼀个基本的Android平台，它运⾏预安装的（车载信息娱乐）IVI系统，Android应⽤程序以及可选的第⼆⽅和第三⽅Android应⽤程序。
Android Automotive的硬件抽象层(HAL)为Android框架提供了一致的接口（无需考虑物理传输层）。此车载HAL是开发Android Automotive实现的接口。
系统集成商可以将特定于功能的平台HAL接口（如HVAC）与特定于技术的网络接口（如 CAN 总线）连接，以实现车载 HAL 模块。典型的实现可能包括运行专有实时操作系统(RTOS)的专用微控制器单元 (MCU)，该微控制器单元用于CAN总线访问或类似操作，可通过串行链路连接到运行Android Automotive的CPU。
AutoMotive整体架构
系统应用层
Android Automotive 为系统定制了一些专门适用车载系统的应用，以代替传统的手机应用模块。
系统应用层的Application都位于源码目录下：packages/apps/Car/
包含的应用如下
系统框架层
系统框架层提供了多个模块，来对Android Automotive 进行支持，最重要的有一个服务CarService (com.android.car) 。
系统框架层的模块都位于源码目录下：packages/services/Car/
CarService是一个类似Android系统中SystemSever的服务。它由一个服务启动，而里面又控制着数十个子模块服务。
CarService
CarService中CarService只作为服务的入口，具体的业务逻辑都在内部的子服务中处理，CarService的子服务如下。
CarService启动
CarService本质上是一个特殊的APP，它编译后生成CarService.apk；在系统中，它是在/system/priv-app/CarService/CarService.apk
CarService在启动启动时，由SystemServer拉起
代码：frameworks/base/services/java/com/android/server/SystemServer.java
private static final String CAR_SERVICE_HELPER_SERVICE_CLASS =
"com.android.internal.car.CarServiceHelperService";
private void startOtherServices() {
mActivityManagerService.systemReady(() -> {
if (mPackageManager.hasSystemFeature(PackageManager.FEATURE_AUTOMOTIVE)) {
traceBeginAndSlog("StartCarServiceHelperService");
mSystemServiceManager.startService(CAR_SERVICE_HELPER_SERVICE_CLASS);
traceEnd();
}
});
}
代码：frameworks/opt/car/services/src/com/android/internal/car/CarServiceHelperService.java
private static final String CAR_SERVICE_INTERFACE = "android.car.ICar";
public class CarServiceHelperService extends SystemService {
@Override
public void onStart() {
Intent intent = new Intent();
intent.setPackage("com.android.car");
intent.setAction(CAR_SERVICE_INTERFACE);
if (!getContext().bindServiceAsUser(intent, mCarServiceConnection, Context.BIND_AUTO_CREATE, UserHandle.SYSTEM)) {
Slog.wtf(TAG, "cannot start car service");
}
System.loadLibrary("car-framework-service-jni");
}
}
- SystemServer中ActivityManagerService.systemReady后会通过SystemServiceManager启动CarServiceHelperService
- CarServiceHelperService中绑定CarService 代码：packages/services/Car/service/AndroidManifest.xml
<service android:name=".CarService"
android:singleUser="true">
<intent-filter>
<action android:name="android.car.ICar" />
</intent-filter>
</service>
通过在CarService的AndroidManifest的配置，CarServiceHelperService可以通过包名和action的名称实现和CarService绑定。
Car API
Car API 是Android系统为汽车应用提供的一套SDK接口（Android Automotive Library）。
源代码位于packages/services/Car/car-lib目录下
Google官方的API文档在Android Q之后，也开始支持Android Automotive库。
链接地址： https://developer.android.google.cn/reference/android/car/package-summary
同CarService一样Car API 也提供的多个模块对应不同的功能调用。
硬件抽象层
硬件抽象层主要是提供了一个native服务android.hardware.automotive.vehicle@2.0-service，负责处理车辆相关的业务。
硬件抽象层的模块位于源码目录下hardware/interfaces/automotive/
VehicleService
VehicleService是一个native服务，代码实现在目录hardware/interfaces/automotive/vehicle/2.0/default/impl/vhal_v2_0/
VehicleServices是Android Automotive在硬件抽象层的入口。它通过initrc启动。
代码：hardware/interfaces/automotive/vehicle/2.0/default/android.hardware.automotive.vehicle@2.0-service.rc
service vendor.vehicle-hal-2.0 /vendor/bin/hw/android.hardware.automotive.vehicle@2.0-service
class hal
user vehicle_network
group system inet
VehicleHalManager
VehicleHalManager是Android Automotive在硬件抽象层的API接口。代码在目录
hardware/interfaces/automotive/vehicle/2.0/default/common/。
HAL接口语言
从硬件抽象层到系统框架层，也就是从VehicleService到CarService，从Android O版本开始使用了一种新的HIDL接口。
HIDL 是用于指定 HAL 和其用户之间的接口的一种接口描述语言 (IDL)。虽然从 Android 10 开始，HIDL 已废弃，Android 将在所有位置改用 AIDL。 但是Android Automotive的HIDL架构还保留着，直到Android 13才发生变化。
HIDL使用一种以.hal为后缀文件作为接口定义，在Android Automotive中硬件抽象层到系统框架层使用IVehicle.hal（代码路径：hardware/interfaces/automotive/vehicle/2.0/IVehicle.halhardware/interfaces/automotive/vehicle/2.0/IVehicle.hal）来定义。
代码：hardware/interfaces/automotive/vehicle/2.0/IVehicle.hal
package android.hardware.automotive.vehicle@2.0;
import IVehicleCallback;
interface IVehicle {
/**
* Returns a list of all property configurations supported by this vehicle
* HAL.
*/
//返回这个vehicle hal支持的全部property属性
getAllPropConfigs() generates (vec<VehiclePropConfig> propConfigs);
/**
* Returns a list of property configurations for given properties.
*
* If requested VehicleProperty wasn't found it must return
* StatusCode::INVALID_ARG, otherwise a list of vehicle property
* configurations with StatusCode::OK
*/
getPropConfigs(vec<int32_t> props)
generates (StatusCode status, vec<VehiclePropConfig> propConfigs);
/**
* Get a vehicle property value.
*
* For VehiclePropertyChangeMode::STATIC properties, this method must always
* return the same value always.
* For VehiclePropertyChangeMode::ON_CHANGE properties, it must return the
* latest available value.
*
* Some properties like RADIO_PRESET requires to pass additional data in
* GET request in VehiclePropValue object.
*
* If there is no data available yet, which can happen during initial stage,
* this call must return immediately with an error code of
* StatusCode::TRY_AGAIN.
*/
get(VehiclePropValue requestedPropValue)
generates (StatusCode status, VehiclePropValue propValue);
/**
* Set a vehicle property value.
*
* Timestamp of data must be ignored for set operation.
*
* Setting some properties require having initial state available. If initial
* data is not available yet this call must return StatusCode::TRY_AGAIN.
* For a property with separate power control this call must return
* StatusCode::NOT_AVAILABLE error if property is not powered on.
*/
set(VehiclePropValue propValue) generates (StatusCode status);
/**
* Subscribes to property events.
*
* Clients must be able to subscribe to multiple properties at a time
* depending on data provided in options argument.
*
* @param listener This client must be called on appropriate event.
* @param options List of options to subscribe. SubscribeOption contains
* information such as property Id, area Id, sample rate, etc.
*/
subscribe(IVehicleCallback callback, vec<SubscribeOptions> options)
generates (StatusCode status);
/**
* Unsubscribes from property events.
*
* If this client wasn't subscribed to the given property, this method
* must return StatusCode::INVALID_ARG.
*/
unsubscribe(IVehicleCallback callback, int32_t propId)
generates (StatusCode status);
/**
* Print out debugging state for the vehicle hal.
*
* The text must be in ASCII encoding only.
*
* Performance requirements:
*
* The HAL must return from this call in less than 10ms. This call must avoid
* deadlocks, as it may be called at any point of operation. Any synchronization
* primitives used (such as mutex locks or semaphores) must be acquired
* with a timeout.
*
*/
debugDump() generates (string s);
};
IVehicle接口支持功能如下
update-makefiles.sh
通过update-makefiles.sh 可以创建编译HIDL文件的Android.bp。
代码路径：hardware/interfaces/update-makefiles.sh
假设创建一个helloworld模块，在hardware/interfaces 下创建helloworld/1.0/IHelloWorld.hal：
package android.hardware.helloworld@1.0;
interface IHelloWorld {
justTest(string name);
};
通过update-makefiles.sh就可以在对应package的目录下创建Android.bp：
// This file is autogenerated by hidl-gen -Landroidbp.
hidl_interface {
name: "android.hardware.helloworld@1.0",
root: "android.hardware",
vndk: {
enabled: true,
},
srcs: [
"IHelloWorld.hal",
],
interfaces: [
"android.hidl.base@1.0",
],
gen_java: true,
}
name：模块的全名
root：包根目录
interfaces：编译过程中依赖的模块
gen_java：是否编译为Java 使用的接口
当然，还有其他的参数，例如gen_java_constants设为true 的时候会生成为Java 使用的Constants类。
全文概括了车机系统开发中的；Android Automotive原理架构解析；技术参考《车机开发手册》需要可以点击查看更多车载技术知识。
文末
车载HAL是汽车与车辆网络服务之间的接口定义（同时保护传入的数据）：
车载HAL与Android Automotive架构：
- Car API：内有包含CarSensorManager在内的API。位于/platform/packages/services/Car/car-lib
- CarService：位于 /platform/packages/services/Car/
- 车载 HAL：用于定义OEM可以实现的车辆属性的接口。包含属性元数据（例如，车辆属性是否为int以及允许使用哪些更改模式）。位于hardware/libhardware/include/hardware/vehicle.h。如需了解基本参考实现，请参阅 hardware/libhardware/modules/vehicle/（vehicle意思即车辆）