OEM VHAL Permission Proxy Service

This permission proxy service grants and denies OEM runtime permissions to apps.

This is done in 2 steps:

1. At boot for all apps
2. On application installation

OEM runtime permissions are permissions starting with "android.car.permission.oem.".

Currently the allow-list mapping is present in vhal-mapper-permission-grant-proxy-service/permissions/vhal-privapp-permissions-permissionsgrantproxyservice-trusted-external.xml in the following format:

<permissions>
    <package pattern="{:REGEX_PATTERN:}">
        <permission name="android.car.permission.oem.{:PERMISSION_NAME:}"/>
    </package>
</permissions>

This is an allow-list: All apps (package IDs) matching the pattern attribute, will be granted all permissions listed in <permission> tags. All other available permissions will be revoked.

Permissions can be also granted and revoked during runtime. Currently, the VHAL Permission Proxy Service does not implement any such logic, but it can be tested using ADB. For example to grand or revoke permissions for the COVESA test app to get or set the sunroof shade use one of the following commands:

$ adb shell pm grant --user 10 global.covesa.aosp.vhal.test.app android.car.permission.oem.CABIN_SUNROOF_SHADE_IS_OPEN_READ
$ adb shell pm grant --user 10 global.covesa.aosp.vhal.test.app android.car.permission.oem.CABIN_SUNROOF_SHADE_IS_OPEN_WRITE
$ adb shell pm revoke --user 10 global.covesa.aosp.vhal.test.app android.car.permission.oem.CABIN_SUNROOF_SHADE_IS_OPEN_READ
$ adb shell pm revoke --user 10 global.covesa.aosp.vhal.test.app android.car.permission.oem.CABIN_SUNROOF_SHADE_IS_OPEN_WRITE

When the app is running a grant will not interrupt the app, while revoke will. This is expected since the system cannot know whether the app already checked if it has the runtime permission and thinks it can perform corresponding action. A revoke will therefore lead to restart of the app.

Note: In Android, User 10 usually refers to the first regular non-system user account on the device, not a special system component.

Build

Check COVESA AOSP Platform Manifest to build it.

Initial setup

In order the permission grant proxy to manage the android.car.permission.oem.* permissions we need to tell the Device Policy Manager (DPM) to make it profile owner of our user (in this case user 10):

adb shell dpm set-profile-owner --user 10 global.covesa.vhal.mapper.permission.proxy/.CarDeviceAdminReceiver

---

Android OEM Permissions XML

This part describes the structure of the XML file used to define OEM-specific permissions for Android Automotive.

Root Element: <permissions>

Container for one or more <package> entries that define OEM permissions. Only single <permissions> root element is allowed.

<permissions>
    ...
</permissions>

Element <package>

The <package> element defines app (package ID) pattern with one or more <permission> elements. Each <package> must have a pattern attribute to specify which packages it applies to.

Attribute	Type	Required	Description
pattern	string	Yes	A regex pattern or exact package name.

<package pattern="com\.test\.app_id">
    <permission name="android.car.permission.oem.EXAMPLE_DATA_POINT_READ"/>
    <permission name="android.car.permission.oem.EXAMPLE_DATA_POINT_WRITE"/>
    <!-- Additional permissions -->
</package>

Element <permission>

The <permission> element defines a single OEM-specific permission that a will be granted to matched apps (package IDs).

Attribute	Type	Required	Description
name	string	Yes	Full permission name, only permissions prefixed with android.car.permission.oem. are allowed.

<permission name="android.car.permission.oem.EXAMPLE_DATA_POINT_READ"/>
<permission name="android.car.permission.oem.EXAMPLE_DATA_POINT_WRITE"/>