深度入门 Android 车机核心 CarService 的构成和链路

这篇具有很好参考价值的文章主要介绍了深度入门 Android 车机核心 CarService 的构成和链路。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

作者:TechMerger

本文将结合 Android 系统整体,对 CarService 的构成和链路对其做一个全面的分析和理解。

构成

1. CarServiceHelperService 系统服务

SystemServer 中专门为了 Automotive OS 设立的系统服务,用来管理车机的核心服务 CarService。该系统服务的具体实现实际上由 CarServiceHelperServiceUpdatableImpl 类完成,后面会提到。

System service side companion service for CarService. Starts car service and provide necessary API for CarService. Only for car product.

2. CarService 核心服务 App

Car Service App 实际上分为两个,一个是和系统服务直接交互的 builtin app,另一个是给该 built app 提供实际实现的 updatable app。

builtin app

系统中与车相关的核心 App,掌管最重要的 CarService 服务类。目录位于:

  • packages/services/Car/service-builtin/

其 AndroidManifest.xml 文件如下,可以看到它具有系统权限、与 system uid 共享数据。

<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">
    
     <application android:label="@string/app_title"
         android:directBootAware="true"
         android:allowBackup="false"
         android:persistent="true">

         <service android:name=".CarService"
             android:singleUser="true"
             android:exported="true">
            <intent-filter>
                <action android:name="android.car.ICar"/>
            </intent-filter>
        </service>
        ...
    </application>            
</manifest>
updatable app

builtin app 的所有具体实现以及后续支持的一堆服务都在 updatable app 中实现,目录见:

  • packages/services/Car/service/

其 AndroidManifest.xml 文件如下,可以看到它也具有系统权限。

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
     xmlns:androidprv="http://schemas.android.com/apk/prv/res/android"
     package="com.android.car.updatable"
     coreApp="true">

    <permission-group android:name="android.car.permission-group.CAR_MONITORING"
         android:icon="@drawable/perm_group_car"
         android:description="@string/car_permission_desc"
         android:label="@string/car_permission_label"/>
    ...

    <application android:label="@string/app_title"
         android:directBootAware="true"
         android:allowBackup="false">
    </application>
</manifest>

3. Car 专用 API

Android 车机里提供给系统使用汽车相关能力的专用接口,源码实现在:

  • packages/services/Car/car-lib/

看下它的 manifest 文件:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
        xmlns:androidprv="http://schemas.android.com/apk/prv/res/android"
        package="android.car" >
    <uses-sdk android:minSdkVersion="23" android:targetSdkVersion="23" />
</manifest>

再看下它的 bp 文件:

...
filegroup {
    name: "android.car-full-src",
    srcs: [
        "src/**/*.java",
        "src/**/*.aidl",
    ],
    visibility: [
        "//packages/services/Car/car-lib",
        "//packages/services/Car/car-lib-module",
    ],
}

java_library {
    name: "android.car",
    srcs: [
        ":android.car-full-src",
    ],
    aidl: {
        include_dirs: [
            "packages/modules/Bluetooth/framework/aidl-export",
        ],
    },
    libs: [
        "android.car.builtin",
        "framework-annotations-lib",
        "modules-utils-preconditions",
        "framework-wifi",
        "framework-bluetooth",
    ],
    installable: true,
    sdk_version: "module_current",
}

可以看到它会编译到 android.car.jar 中,而非面向 AOSP 手机/平板的 android.jar 中。这也意味着如果要基于 Car 相关 API 开发,需要通过添加 Automotive os addon 的方式才能导入该 SDK。

这个 jar 囊括了我们常用的 Car、CarPowerManager、CarSettings 等,下面罗列了部分常用的 Car API:

  • android.car:包含了与车相关的基本API。例如:车辆后视镜,门,座位,窗口等
  • menu:车辆应用菜单相关API
  • cluster:仪表盘相关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

最后的实现会经由 AIDL 抵达上个章节的 CarService App。

4. Car Apps

提供 Automotive OS 内置的、专门为 Car 场景设计的 App,目录位于:

  • packages/apps/Car/

比如面向 Car 的 SystemUI、Launcher、Settings、IME 等。

深度入门 Android 车机核心 CarService 的构成和链路,移动开发,Android,车载,android,移动开发,安卓,framework,车载系统

CarService 启动链路

Service 整体

SystemServer 会在启动系统服务的过程中依据 FEATURE_AUTOMOTIVE 的特性决定是否启动 AAOS 的系统服务 CarServiceHelperService

public final class SystemServer implements Dumpable {
    ...
    private static final String CAR_SERVICE_HELPER_SERVICE_CLASS =
            "com.android.internal.car.CarServiceHelperService";

    private void startOtherServices(@NonNull TimingsTraceAndSlog t) {
        t.traceBegin("startOtherServices");
        ...
        mActivityManagerService.systemReady(() -> {
            Slog.i(TAG, "Making services ready");
            ...
            boolean isAutomotive = mPackageManager
                    .hasSystemFeature(PackageManager.FEATURE_AUTOMOTIVE);
            if (isAutomotive) {
                t.traceBegin("StartCarServiceHelperService");
                final SystemService cshs = mSystemServiceManager
                        .startService(CAR_SERVICE_HELPER_SERVICE_CLASS);
                t.traceEnd();
            }
            ...
        }, t);
        ...
    }
    ...
}

CarServiceHelperService 执行 onStart() 的时候,会将后续的工作交给 CarServiceHelperServiceUpdatableImpl 来处理。

其 onStart() 里调用 bindService() 绑定 action 为 “android.car.ICar”、package 为 “com.android.car” 的 Service,即构成章节里提到的 CarService 组件。

public class CarServiceHelperService extends SystemService
        implements Dumpable, DevicePolicySafetyChecker, CarServiceHelperInterface {
    ...
    @Override
    public void onStart() {
        ...
        mCarServiceHelperServiceUpdatable.onStart();
    }
    ...
}

public final class CommonConstants {
    ...
    // CarService Constants
    public static final String CAR_SERVICE_INTERFACE = "android.car.ICar";
    ...
}

public final class CarServiceHelperServiceUpdatableImpl
        implements CarServiceHelperServiceUpdatable, Executor {
    ...
    private static final String CAR_SERVICE_PACKAGE = "com.android.car";

    @Override
    public void onStart() {
        Intent intent = new Intent(CAR_SERVICE_INTERFACE).setPackage(CAR_SERVICE_PACKAGE);
        Context userContext = mContext.createContextAsUser(UserHandle.SYSTEM, /* flags= */ 0);
        if (!userContext.bindService(intent, Context.BIND_AUTO_CREATE, this,
                mCarServiceConnection)) {
            Slogf.wtf(TAG, "cannot start car service");
        }
    }
    ...
}

CarService 的实现都在父类 ServiceProxy 中,比如首先被调用的 onCreate(),内部将先调用 init()。

init() 将构建 mRealServiceClassName 的实例,而 mRealServiceClassName 变量来自于 UpdatablePackageDependency.java 中定义的 CAR_SERVICE_IMPL_CLASS 常量即 “com.android.car.CarServiceImpl”

通过如下代码看到,这意味着将初始化 CarServiceImpl 实例。

public class CarService extends ServiceProxy {
    ...
    public CarService() {
        super(UpdatablePackageDependency.CAR_SERVICE_IMPL_CLASS);
        // Increase the number of binder threads in car service
        BinderInternal.setMaxThreads(MAX_BINDER_THREADS);
    }
    ...
}

public class ServiceProxy extends Service {
    ...
    @Override
    public void onCreate() {
        init();
        mRealService.onCreate();
    }
    
    private void init() {
        mUpdatablePackageContext = UpdatablePackageContext.create(this);
        try {
            mRealServiceClass = mUpdatablePackageContext.getClassLoader().loadClass(
                    mRealServiceClassName);
            // Use default constructor always
            Constructor constructor = mRealServiceClass.getConstructor();
            mRealService = (ProxiedService) constructor.newInstance();
            mRealService.doAttachBaseContext(mUpdatablePackageContext);
            mRealService.setBuiltinPackageContext(this);
        } catch (Exception e) {
            throw new RuntimeException("Cannot load class:" + mRealServiceClassName, e);
        }
    }
    ...
}

public class UpdatablePackageDependency {
    /** {@code com.android.car.CarServiceImpl} class */
    public static final String CAR_SERVICE_IMPL_CLASS = "com.android.car.CarServiceImpl";
    ...
}

init() 之后是执行创建出来的 CarServiceImpl 实例的 onCreate(),可以看到是继续创建关键类 ICarImpl 的实例并再次执行 init()。

public class CarServiceImpl extends ProxiedService {
    ...
    @Override
    public void onCreate() {
        ...
        mICarImpl = new ICarImpl(this,
                getBuiltinPackageContext(),
                mVehicle,
                SystemInterface.Builder.defaultSystemInterface(this).build(),
                mVehicleInterfaceName);
        mICarImpl.init();
        ...
    }
    ...
}

public class ICarImpl extends ICar.Stub {
    ...
    ICarImpl( ... ) {
		...
        mHal = constructWithTrace(t, VehicleHal.class,
                () -> new VehicleHal(serviceContext, vehicle));
        ...
        mCarPropertyService = constructWithTrace(
                t, CarPropertyService.class,
                () -> new CarPropertyService(serviceContext, mHal.getPropertyHal()));
        mCarDrivingStateService = constructWithTrace(
                t, CarDrivingStateService.class,
                () -> new CarDrivingStateService(serviceContext, mCarPropertyService));
        ...
        mCarPowerManagementService = constructWithTrace(
                t, CarPowerManagementService.class,
                () -> new CarPowerManagementService(mContext, mHal.getPowerHal(),
                        systemInterface, mCarUserService, powerPolicyDaemon));
        ...
        mCarInputService = constructWithTrace(t, CarInputService.class,
                () -> new CarInputService(serviceContext, mHal.getInputHal(), mCarUserService,
                        mCarOccupantZoneService, mCarBluetoothService));
        ...

        List<CarServiceBase> allServices = new ArrayList<>();
        allServices.add(mCarPropertyService); // mCarUXRestrictionsService depends on it
        allServices.add(mCarPowerManagementService);
        allServices.add(mCarDrivingStateService);
        allServices.add(mCarInputService);
        ...
        ...
        mAllServices = allServices.toArray(new CarServiceBase[allServices.size()]);
        mICarSystemServerClientImpl = new ICarSystemServerClientImpl();
        ...
    }
    ...
}

ICarImpl 的初始化将完成很多 vehicle 相关的重要工作:

  1. 将初始化和 vehicle HAL 层交互的 VehicleHal 实例
  2. 遍历 ICarImpl 实例构造时候创建的各个扩展自 CarServiceBase 的实例,逐个调用 init() 初始化,比如:
    • 掌管车辆硬件按键输入的 CarInputService
    • 掌管车辆属性的 CarPropertyService
    • 掌管车辆电源管理的 CarPowerManagementService
    • 掌管车辆驾驶状态的 CarDrivingStateService
    • 等等
public class ICarImpl extends ICar.Stub {
    ...
    void init() {
        ...
        mHal.init();

        for (CarServiceBase service : mAllServices) {
            service.init();
        }
        ...
    }
    ...
}

下面以 CarInputService 和 CarPropertyService 为例,继续看某个具体的 CarServiceBase 初始化了什么。

CarInputService 输入服务

CarInputService 初始化是向和 VehicleHal 交互的 InputHalService 传递输入相关的监听器 Listener。

public class CarInputService ... {
    ...
    @Override
    public void init() {
        if (!mInputHalService.isKeyInputSupported()) {
            return;
        }

        mInputHalService.setInputListener(this);
        ...
    }
    ...
}

InputHalService 将依据是否支持按键输入、旋钮输入、自定义输入的配置决定是否向 VehicleHal 订阅 Input Property 变化。

public class InputHalService extends HalServiceBase {
    ...
    private final VehicleHal mHal;

    public void setInputListener(InputListener listener) {
        boolean keyInputSupported;
        boolean rotaryInputSupported;
        boolean customInputSupported;
        synchronized (mLock) {
            if (!mKeyInputSupported && !mRotaryInputSupported && !mCustomInputSupported) {
                Slogf.w(TAG, "input listener set while rotary and key input not supported");
                return;
            }
            mListener = listener;
            keyInputSupported = mKeyInputSupported;
            rotaryInputSupported = mRotaryInputSupported;
            customInputSupported = mCustomInputSupported;
        }
        if (keyInputSupported) {
            mHal.subscribeProperty(this, HW_KEY_INPUT);
        }
        if (rotaryInputSupported) {
            mHal.subscribeProperty(this, HW_ROTARY_INPUT);
        }
        if (customInputSupported) {
            mHal.subscribeProperty(this, HW_CUSTOM_INPUT);
        }
    }
    ...
}

CarPropertyService 属性服务

CarPropertyService 也是一样,向和 VehicleHal 打交道的 PropertyHalService 传递输入相关的监听器 Listener。

public class CarPropertyService extends ICarProperty.Stub
        implements CarServiceBase, PropertyHalService.PropertyHalListener {
    @Override
    public void init() {
        synchronized (mLock) {
            // Cache the configs list and permissions to avoid subsequent binder calls
            mConfigs = mHal.getPropertyList();
            mPropToPermission = mHal.getPermissionsForAllProperties();
            if (DBG) {
                Slogf.d(TAG, "cache CarPropertyConfigs " + mConfigs.size());
            }
        }
        mHal.setListener(this);
    }
    ...
}

PropertyHalService 将 CarPropertyService 作为 Callback 暂存,等待来自 HAL 的 Vehicle Property 变化回调。

public class PropertyHalService extends HalServiceBase {
    /**
     * Set the listener for the HAL service
     * @param listener
     */
    public void setListener(PropertyHalListener listener) {
        synchronized (mLock) {
            mListener = listener;
        }
    }
    ...
}

Vehicle 属性调用链路

Car 获取链路

对于其他 App 来说,想要使用 Car API,得做些准备工作:

  1. 先获取 Car 实例
  2. 然后执行连接
  3. 成功之后获取具体功能的 Manager 实例

比如这段用 CarPropertyManager 的示例:

    private Car mCar;
    private CarPropertyManager mCarPropertyManager;

    mCar = Car.createCar(this, /* handler= */ null, Car.CAR_WAIT_TIMEOUT_WAIT_FOREVER,
                (car, ready) -> {
                    mCar = car;
                    if (ready) {
                        mCarPropertyManager =
                                (CarPropertyManager) mCar.getCarManager(Car.PROPERTY_SERVICE);
                        ...
                    }
                });

我们结合源码看下上面这个步骤的链路:

createCar() 首先检查当前 OS 是否属于 Automotive 版本,之后调用 Car 构造函数进行一些全局变量的准备。

public final class Car {
    ...
    public static Car createCar(Context context, ServiceConnection serviceConnectionListener,
            @Nullable Handler handler) {
        if (!context.getPackageManager().hasSystemFeature(PackageManager.FEATURE_AUTOMOTIVE)) {
            Log.e(TAG_CAR, "FEATURE_AUTOMOTIVE not declared while android.car is used");
            return null;
        }
        try {
            return new Car(context, /* service= */ null , serviceConnectionListener,
                    /* statusChangeListener= */ null, handler);
        } catch (IllegalArgumentException e) {
            // Expected when car service loader is not available.
        }
        return null;
    }
    
    private Car( ... ) {
        mContext = context;
        mEventHandler = determineEventHandler(handler);
        mMainThreadEventHandler = determineMainThreadEventHandler(mEventHandler);

        mService = service;
        if (service != null) {
            mConnectionState = STATE_CONNECTED;
        } else {
            mConnectionState = STATE_DISCONNECTED;
        }
        mServiceConnectionListenerClient = serviceConnectionListener;
        mStatusChangeCallback = statusChangeListener;
        // Store construction stack so that client can get help when it crashes when car service
        // crashes.
        if (serviceConnectionListener == null && statusChangeListener == null) {
            mConstructionStack = new RuntimeException();
        } else {
            mConstructionStack = null;
        }
    }
    ...
}

connect() 首先检查是否重复请求连接了,确实需要连接的话调用 startCarService() 核心处理。

startCarService() 将绑定 CarService 服务。

public final class Car {
   ...
   public void connect() throws IllegalStateException {
        synchronized (mLock) {
            if (mConnectionState != STATE_DISCONNECTED) {
                throw new IllegalStateException("already connected or connecting");
            }
            mConnectionState = STATE_CONNECTING;
            startCarService();
        }
    }
    
    private void startCarService() {
        Intent intent = new Intent();
        intent.setPackage(CAR_SERVICE_PACKAGE);
        intent.setAction(Car.CAR_SERVICE_INTERFACE_NAME);
        boolean bound = mContext.bindService(intent, mServiceConnectionListener,
                Context.BIND_AUTO_CREATE);
        synchronized (mLock) {
            if (!bound) {
                mConnectionRetryCount++;
                if (mConnectionRetryCount > CAR_SERVICE_BIND_MAX_RETRY) {
                    Log.w(TAG_CAR, "cannot bind to car service after max retry");
                    mMainThreadEventHandler.post(mConnectionRetryFailedRunnable);
                } else {
                    mEventHandler.postDelayed(mConnectionRetryRunnable,
                            CAR_SERVICE_BIND_RETRY_INTERVAL_MS);
                }
            } else {
                mEventHandler.removeCallbacks(mConnectionRetryRunnable);
                mMainThreadEventHandler.removeCallbacks(mConnectionRetryFailedRunnable);
                mConnectionRetryCount = 0;
                mServiceBound = true;
            }
        }
    }    
   ...
}

绑定成功之后,将 ICar AIDL 的本地接口代理赋值到 mService 变量(server 端在 CarService 的 ICarImpl 中),待使用。

public final class Car {
    ...
    private final ServiceConnection mServiceConnectionListener =
            new ServiceConnection() {
        @Override
        public void onServiceConnected(ComponentName name, IBinder service) {
            synchronized (mLock) {
                ICar newService = ICar.Stub.asInterface(service);

                if (mService != null && mService.asBinder().equals(newService.asBinder())) {
                    // already connected.
                    return;
                }
                mConnectionState = STATE_CONNECTED;
                mService = newService;
            }
            if (mStatusChangeCallback != null) {
                mStatusChangeCallback.onLifecycleChanged(Car.this, true);
            } else if (mServiceConnectionListenerClient != null) {
                mServiceConnectionListenerClient.onServiceConnected(name, service);
            }
        }

        @Override
        public void onServiceDisconnected(ComponentName name) {
            ...
    };
    ...
}

getCarManager() 首先得确保 CarService 准备就绪了,然后再去缓存 Manager 实例的 HashMap mServiceMap 中查找是否已有现成的,最后才发起 AIDL 获取该功能的接口。

public final class Car {
    ...
    private final HashMap<String, CarManagerBase> mServiceMap = new HashMap<>();
    
    public Object getCarManager(String serviceName) {
        CarManagerBase manager;
        synchronized (mLock) {
            if (mService == null) {
                Log.w(TAG_CAR, "getCarManager not working while car service not ready");
                return null;
            }
            manager = mServiceMap.get(serviceName);
            if (manager == null) {
                try {
                    IBinder binder = mService.getCarService(serviceName);
                    if (binder == null) {
                        Log.w(TAG_CAR, "getCarManager could not get binder for service:"
                                + serviceName);
                        return null;
                    }
                    manager = createCarManagerLocked(serviceName, binder);
                    if (manager == null) {
                        Log.w(TAG_CAR, "getCarManager could not create manager for service:"
                                        + serviceName);
                        return null;
                    }
                    mServiceMap.put(serviceName, manager);
                } catch (RemoteException e) {
                    handleRemoteExceptionFromCarService(e);
                }
            }
        }
        return manager;
    }
    ...
}

ICarImpl 则是依据约定好的 Manager 的 Service 端名称去 CarService 中返回启动时候创建的一堆具体服务。

比如:PROPERTY_SERVICE 的话返回 CarPropertyServiceCAR_INPUT_SERVICE 返回 CarInputService

public class ICarImpl extends ICar.Stub {
    ...
    public IBinder getCarService(String serviceName) {
        if (!mFeatureController.isFeatureEnabled(serviceName)) {
            Slogf.w(CarLog.TAG_SERVICE, "getCarService for disabled service:" + serviceName);
            return null;
        }
        switch (serviceName) {
            ...
            case Car.PROPERTY_SERVICE:
            case Car.SENSOR_SERVICE:
            case Car.VENDOR_EXTENSION_SERVICE:
                return mCarPropertyService;
            ...
            case Car.CAR_INPUT_SERVICE:
                return mCarInputService;
            ...
            default:
                IBinder service = null;
                if (mCarExperimentalFeatureServiceController != null) {
                    service = mCarExperimentalFeatureServiceController.getCarService(serviceName);
                }
                if (service == null) {
                    Slogf.w(CarLog.TAG_SERVICE, "getCarService for unknown service:"
                            + serviceName);
                }
                return service;
        }
    }
    ...
}

CarPropertyManager 调用链路

Automotive OS 提供了 CarPropertyManager API 给第三方 App 读写车辆属性。参数 propId 来自于 VehiclePropertyIds 类中定义的属性 ID,当然也需要获得相应的 permission。

比如读写车窗属性的 ID 为 WINDOW_POS,需要 android.car.permission.CONTROL_CAR_WINDOWS 的权限。

读取 getProperty() 首先调用 checkSupportedProperty() 检查是否支持该属性,如果是 USER 相关的属性会抛出如下的异常:

Unsupported property:xxx

通过检查的向实现的 Service 发出读取调用。

public class CarPropertyManager extends CarManagerBase {
    public <E> CarPropertyValue<E> getProperty(@NonNull Class<E> clazz, int propId, int areaId) {
        checkSupportedProperty(propId);

        try {
            CarPropertyValue<E> propVal = mService.getProperty(propId, areaId);
            if (propVal != null && propVal.getValue() != null) {
                Class<?> actualClass = propVal.getValue().getClass();
            }
            return propVal;
        }
        ...
    }

    private void checkSupportedProperty(int propId) {
        switch (propId) {
            case VehiclePropertyIds.INITIAL_USER_INFO:
            case VehiclePropertyIds.SWITCH_USER:
            case VehiclePropertyIds.CREATE_USER:
            case VehiclePropertyIds.REMOVE_USER:
            case VehiclePropertyIds.USER_IDENTIFICATION_ASSOCIATION:
                throw new IllegalArgumentException("Unsupported property: "
                        + VehiclePropertyIds.toString(propId) + " (" + propId + ")");
        }
    }
    ...
}

ICarProperty aidl 的实现即位于上个章节分析到的 CarPropertyService 中。

1.先到存放所有 Property ID 的 SparseArray 中检查是否确实存在该 Property,如果不存在的话打印 error 提醒并结束
2.获取该 Property 的 Permission 配置,如果不存在的话,抛出如下异常:

> SecurityException: Platform does not have permission to read value for property Id: 0x...

3.assertPermission() 检查当前 Car Service 是否确实被授予了如上 Permission
4.最后调用持有的 PropertyHalService 继续发出读取的调用

public class CarPropertyService extends ICarProperty.Stub
        implements CarServiceBase, PropertyHalService.PropertyHalListener {
    @Override
    public CarPropertyValue getProperty(int prop, int zone) ... {
        synchronized (mLock) {
            if (mConfigs.get(prop) == null) {
                // Do not attempt to register an invalid propId
                Slogf.e(TAG, "getProperty: propId is not in config list:0x" + toHexString(prop));
                return null;
            }
        }

        // Checks if android has permission to read property.
        String permission = mHal.getReadPermission(prop);
        if (permission == null) {
            throw new SecurityException("Platform does not have permission to read value for "
                    + "property Id: 0x" + Integer.toHexString(prop));
        }
        CarServiceUtils.assertPermission(mContext, permission);
        return runSyncOperationCheckLimit(() -> {
            return mHal.getProperty(prop, zone);
        });
    }
    ...
}

PropertyHalService 首先调用 managerToHalPropId() 将 Property ID 转为 HAL 中该 ID 的定义,并再度检查该 HAL ID 是否确实存在。如果不存在的话亦抛出异常:

IllegalArgumentException:Invalid property Id : 0x…

接着,通过 VehicleHal 传递 HAL 中 ID 继续读取得到 HalPropValue,当读取的 value 存在的话,首先得获取该 Property 在 HAL 层和上层定义的 HalPropConfig 规则。

最后依据 config 将 value 解析成 CarPropertyValue 类型返回。

public class PropertyHalService extends HalServiceBase {
'/ '    ...
    public CarPropertyValue getProperty(int mgrPropId, int areaId)
            throws IllegalArgumentException, ServiceSpecificException {
        int halPropId = managerToHalPropId(mgrPropId);
        if (!isPropertySupportedInVehicle(halPropId)) {
            throw new IllegalArgumentException("Invalid property Id : 0x" + toHexString(mgrPropId));
        }

        // CarPropertyManager catches and rethrows exception, no need to handle here.
        HalPropValue value = mVehicleHal.get(halPropId, areaId);
        if (value == null) {
            return null;
        }
        HalPropConfig propConfig;
        synchronized (mLock) {
            propConfig = mHalPropIdToPropConfig.get(halPropId);
        }
        return value.toCarPropertyValue(mgrPropId, propConfig);
    }
    ...
}

其实 VehicleHal 并未做太多处理就直接交给了 HalClient 来处理。

public class VehicleHal implements HalClientCallback {
    ...
    public HalPropValue get(int propertyId)
            throws IllegalArgumentException, ServiceSpecificException {
        return get(propertyId, NO_AREA);
    }
    ...
    public HalPropValue get(int propertyId, int areaId)
            throws IllegalArgumentException, ServiceSpecificException {
        return mHalClient.getValue(mPropValueBuilder.build(propertyId, areaId));
    }
    ...
}

HalClient 通过 invokeRetriable() 进行超时为 50ms 的 internalGet() 调用:如果结果是 TRY_AGAIN 并且尚未超时的话,再次调用;反之已经超时或者结果成功获取到的话,即结束。

后续会再次检查该 Result 中的 status,是否是不合法的、空的值等等,通过检查的话则返回 HalPropValue 出去。

final class HalClient {
    ...
    private static final int SLEEP_BETWEEN_RETRIABLE_INVOKES_MS = 50;

    HalPropValue getValue(HalPropValue requestedPropValue)
            throws IllegalArgumentException, ServiceSpecificException {
        ObjectWrapper<ValueResult> resultWrapper = new ObjectWrapper<>();
        resultWrapper.object = new ValueResult();
        int status = invokeRetriable(() -> {
            resultWrapper.object = internalGet(requestedPropValue);
            return resultWrapper.object.status;
        }, mWaitCapMs, mSleepMs);

        ValueResult result = resultWrapper.object;

        if (StatusCode.INVALID_ARG == status) {
            throw new IllegalArgumentException(
                    getValueErrorMessage("get", requestedPropValue, result.errorMsg));
        }

        if (StatusCode.OK != status || result.propValue == null) {
            if (StatusCode.OK == status) {
                status = StatusCode.NOT_AVAILABLE;
            }
            throw new ServiceSpecificException(
                    status, getValueErrorMessage("get", requestedPropValue, result.errorMsg));
        }

        return result.propValue;
    }

    private ValueResult internalGet(HalPropValue requestedPropValue) {
        final ValueResult result = new ValueResult();
        try {
            result.propValue = mVehicle.get(requestedPropValue);
            result.status = StatusCode.OK;
            result.errorMsg = new String();
        }
        ...
        return result;
    }
    ...
}

internalGet() 的实现由持有的 VehicleStub 实例的 get 方法完成,其实现对应于依据 HIDL 的配置调用 HAL 侧获取相应数据。

public abstract class VehicleStub {
    ...
    @Nullable
    public abstract HalPropValue get(HalPropValue requestedPropValue)
            throws RemoteException, ServiceSpecificException;
    ...
}

set 写入的链路和 get 大同小异,后面我会以车窗状态和开关操作为例,详细展开车辆属性 API 的使用和原理细节。

总结

我们通过一张表格来总结 CarService 相关组件的构成。

Car 相关组件 所属进程 作用
CarServiceHelperService SystemServer 管理 Car Serivce 的系统服务
CarService builtin app Car 核心服务
updatable app Car 核心服务的具体实现
Car API android.car.jar Car API SDK
Car Apps Launcher 等 Car 专门设计的一系列 App

而 CarService 在系统中的位置、与外部的交互链路,则是通过一张总图来直观把握:

深度入门 Android 车机核心 CarService 的构成和链路,移动开发,Android,车载,android,移动开发,安卓,framework,车载系统

  1. SystemServer 进程在系统启动的时候发现 OS 具备 Automotive 的 feature,则启动 CarServiceHelperService 系统服务,并交由 CarServiceHelperServiceUpdatableImpl 实际负责和 CarService 的绑定
  2. CarService 的 builtin app 由父类 ServiceProxy 完成中转,即反射出 updatable appCarServiceImpl 实例
  3. CarServiceImpl 的初始化将构建 ICarImpl 实例并构建内部的一堆具体服务 CarServiceBase,比如负责输入的 CarInputService、负责车辆属性的 CarPropertyService 等。
  4. 这些具体服务通过 HalServiceBase 和 VehicleHal 进行交互,比如调度输入事件的 InputHalService、读写/转换车辆属性的 PropertyHalService
  5. 后续的交给 VehicleHal 通过 HIDL 和 HAL 层交互
  6. 其他 Apps 可以通过 Car lib 提供的 Car API 获取 CarService 中的服务接口即 ICarImpl
  7. ICarImpl 通过启动时候注册的服务名称和 CarServiceBase 实例对照表向 Apps 返回对应的接口实例,比如控制、监听输入的 CarInputManager、读写车辆属性的 CarPropertyManager
  8. 其他 Apps 拿到这些 Manager 接口之后,像 AOSP 中使用 ActivityManager 等接口一样通过 AIDL 和 CarService 进行交互

为了帮助到大家更好入手车载,根据官方文档+行业大牛们一些指导,整理出了《Android 车载开发手册》+《Android车载开发学习手册》+《Framework 知识点汇总》,希望能帮助到大家,有需要的可以 点此处进行参考↓↓↓ 学习!!!

Android 车载学习手册

第一章——Android Auto概述

  1. 概述
  2. Android Auto
  3. Android Automotive OS
  4. 支持的应用类别

深度入门 Android 车机核心 CarService 的构成和链路,移动开发,Android,车载,android,移动开发,安卓,framework,车载系统

第二章——开发汽车媒体应用

  1. 构建车载媒体应用
  2. 添加对Android Auto 的支持
  3. 构建Android Automotive OS视频应用

深度入门 Android 车机核心 CarService 的构成和链路,移动开发,Android,车载,android,移动开发,安卓,framework,车载系统

第三章——构建 Android Auto即时通信应用

  1. 使用入门
  2. 声明 Android Auto 支持
  3. 导入 Android X 核心库
  4. 处理用户操作
  5. 向用户提供消息通知

深度入门 Android 车机核心 CarService 的构成和链路,移动开发,Android,车载,android,移动开发,安卓,framework,车载系统

第四章——构建车载导航和地图的注点应用

  1. 使用 Android for cars 应用库
  2. 构建车载导航应用
  3. 添加对 Android Auto 的支持
  4. 添加对 Android Automotive OS 的支持

深度入门 Android 车机核心 CarService 的构成和链路,移动开发,Android,车载,android,移动开发,安卓,framework,车载系统

第五章——构建 Android Automotive OS 视频应用

  1. 在 Android Automotive OS模拟器上适配测速应用
  2. 配置应用清单文件
  3. 针对 Android Automotive OS 优化应用

深度入门 Android 车机核心 CarService 的构成和链路,移动开发,Android,车载,android,移动开发,安卓,framework,车载系统

第六章——测试Android 车载应用

  1. 测试 Android Auto 应用
  2. 测试 Android Automotive 应用
  3. 针对手机屏幕测试应用
  4. 媒体应用的其他测试要求

深度入门 Android 车机核心 CarService 的构成和链路,移动开发,Android,车载,android,移动开发,安卓,framework,车载系统

第七章——分发 Android 车载应用

  1. 了解指南和要求
  2. 开发出优秀的车载应用
  3. Android 车载应用质量测试
  4. Android for Cars 条款
  5. 跟踪审核进度

深度入门 Android 车机核心 CarService 的构成和链路,移动开发,Android,车载,android,移动开发,安卓,framework,车载系统

第八章——适用于车载的Google Play服务

深度入门 Android 车机核心 CarService 的构成和链路,移动开发,Android,车载,android,移动开发,安卓,framework,车载系统

第九章——Android Automotive OS 通知

  1. 车内通知有何不同
  2. 通知中心
  3. 浮动通知
  4. 面向车载的 Notification API 变更和限制

深度入门 Android 车机核心 CarService 的构成和链路,移动开发,Android,车载,android,移动开发,安卓,framework,车载系统

有需要的可以通过↓↓↓ 方式进行参考学习!!!

有需要的可以复制下方链接,传送直达!!!
https://qr21.cn/CaZQLo?BIZ=ECOMMERCE

《Android车载开发学习手册》433页

深度入门 Android 车机核心 CarService 的构成和链路,移动开发,Android,车载,android,移动开发,安卓,framework,车载系统

Framework 知识点汇总

  1. Handler机制实现原理
  2. Binder原理
  3. Zygote部分
  4. AMS源码分析
  5. 深入PMS源码
  6. WMS

深度入门 Android 车机核心 CarService 的构成和链路,移动开发,Android,车载,android,移动开发,安卓,framework,车载系统文章来源地址https://www.toymoban.com/news/detail-707146.html

到了这里,关于深度入门 Android 车机核心 CarService 的构成和链路的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 【Docker晋升记】No.1--- Docker工具核心组件构成(镜像、容器、仓库)及性能属性

    👧个人主页:@小沈YO. 😚小编介绍:欢迎来到我的乱七八糟小星球🌝 🔑本章内容:Docker工具核心组件构成(镜像、容器、仓库)及性能属性 记得 评论📝 +点赞👍 +收藏😽 +关注💞哦~ 提示:以下是本篇文章正文内容,下面案例可供参考 Docker 是一个开放源代码的容器化平

    2024年02月14日
    浏览(54)
  • 一文了解 Android 车机如何处理中控的旋钮输入?

    上篇文章《从实体按键看 Android 车载的自定义事件机制》带大家了解了 Android 车机支持自定义输入的机制 CustomInputService 。事实上,除了支持自定义事件,对于中控上常见的音量控制、焦点控制的旋钮事件,Android 车机也是支持的。 那本篇文章带大家看下 Android 车机处理旋钮

    2024年02月15日
    浏览(44)
  • 车机 Android 调节音量的三种方式及底层代码逻辑

    注意:本文基于 Android 12/S 进行分析 Qidi 2023.07.20 (MarkDown EnterpriseArchitect Haroopad) 车机环境下的音频使用场景,相较于原始 Android 的音频使用场景,存在这些特殊性: 使用专门的 aDSP 芯片进行音效处理; 需要播放/控制原始 Android 预设之外的音源(AudioUsage); 音源间交互行为更

    2024年02月05日
    浏览(52)
  • 计算机网络—TCP协议详解:协议构成、深度解析(1)

                                               🎬慕斯主页 : 修仙—别有洞天                                        ♈️ 今日夜电波: マリンブルーの庭園—ずっと真夜中でいいのに。                                                            0:34━━━

    2024年04月16日
    浏览(37)
  • 计算机网络—TCP协议详解:协议构成、深度解析(3)

                                               🎬慕斯主页 : 修仙—别有洞天                                        ♈️ 今日夜电波: マリンブルーの庭園—ずっと真夜中でいいのに。                                                            0:34━━━

    2024年04月29日
    浏览(47)
  • 如何在 Windows上使用桌面车机(DHU)测试 Android Auto

    如果你想在购买支持 Android Auto 的汽车之前尝试 Android Auto,那么就可以使用 Android Studio 在模拟器中试用 Android Auto,使用 Android Studio 即可模拟一个车机的Android Auto,你只需要通过USB连接线把手机连接到电脑,即可在电脑上使用Android Auto。 Desktop Head Unit(DHU) 是一种Android模拟

    2024年02月21日
    浏览(38)
  • 车机 Android 环境下利用 CarAudioService 实现自定义 Java 服务自启动

    注意:本文基于 Android 11/R 进行分析 Qidi 2023.11.28 (MarkDown Haroopad) Overlay 实现的效果正如其字面意思,就是“在原有效果的基础上再叠加一些效果”。 Android 提供了两种实现方式: 编译时:https://source.android.com/docs/setup/create/new-device#use-resource-overlays 运行时:https://source.android.c

    2024年02月05日
    浏览(38)
  • 榨干Pixel5最后的价值:编译刷写Android12L车机系统

    去年2022年中的时候,突然迷上了小屏手机,当时小屏的选择很有限,所以左挑右选网购了一台Pixel 5的库存机。酷安各个机主都称呼其为小五,小巧机身,这台鼠尾草绿的颜色很好看。 原生安卓系统的人机交互里有很多让人惊喜的细节,比如我开睡眠模式的时候,整个屏幕的

    2024年01月22日
    浏览(51)
  • android车机手机黑屏闪黑终结者-Winscope工具使用介绍

    设想一下,假如我们又如下场景,一个闪黑一瞬间的问题,正常我们看到黑屏冻屏问题,是不是时刻想到是要来dumpsys SurfaceFlinger和dumpsys window windows相关的信息来辅助我们分析问题,但奈何这个是个瞬时问题。。。我们dumpsys很难抓住那一瞬间,而且即使抓到了黑一瞬间的,我

    2024年02月08日
    浏览(37)
  • Android Framework最难模块WMS实战作业-手机车机系统开发必备

    0-整体介绍 1-window-container.mp4 窗口层级树实战启动篇 2-displayarea-feature.mp4 窗口层级树源码分析相关 3-displayarea-draw-feature.mp4 窗口层级树绘制实战1 4-displayarea-draw-leaf.mp4 窗口层级树绘制实战2 5-displayarea-draw-leaf-2.mp4 窗口层级树绘制实战3 6-displayarea-surfacelayer.mp4 窗口层级树相关sur

    2024年02月12日
    浏览(46)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包