Device management enables you to remotely manage a vehicle running Android Automotive OS (AAOS). For example, a vehicle owner may want to remotely factory reset the infotainment unit.
In Automotive, we provide two categories of device management:
- Personal device. A vehicle is owned by a consumer. The owner of the vehicle remotely manages the car. For example, the owner uses the vehicle's mobile app to remotely perform a factory reset of the infotainment unit.
- Enterprise device. A vehicle is owned by an enterprise or an organization. An administrator remotely manages the car.
Personal devices
In a personal device scenario, remotely managing the vehicle requires considering the car's drive-state. For example, if the owner of the vehicle remotely triggers a factory reset, the vehicle should not factory reset if the car is actively driven by another person.
Thus, we have a set of device management APIs integrated with drive-state restrictions. These APIs can be called by any system app (preinstalled apps in the system partition) with the correct permissions.
Personal device management APIs
| API | Purpose |
|---|---|
CarDevicePolicyManager.createUser() |
Creates a new user on the device in the background. How does it interact with drive-state? A new user is created in the background, regardless of drive-state. |
CarDevicePolicyManager.RemoveUser() |
Removes an existing user on the device. How does it interact with drive-state? If the target user is in the: |
DevicePolicyManager.lockNow() |
Locks an existing user on the device. If the user has existing lockscreen credentials (for example, a PIN or pattern), the display stays on. How does this interact with drive-state? If the target user is in the: |
DevicePolicyManager.resetPassword() |
Locks an existing user on the device by setting a lockscreen credential, if the user doesn't have existing credentials. The display stays on. How does it interact with drive-state? If the target user is in the: |
DevicePolicyManager.wipeData() |
Triggers a factory reset on the device. How does it interact with drive-state? Regardless of drive-state (PARKED, IDLING, or MOVING), the operation proceeds. The system posts a notification to inform the driver that a factory reset is required. When the vehicle is PARKED, the driver can interact with the notification to choose to reset the device now or later (when the car is next started). |
For example:
Figure 1. System posts notification when factory reset is triggered.
Figure 2. When the vehicle is PARKED, the driver can interact with the notification to choose to reset the device now or later (when the car is next started).
Figure 3. If the driver chooses to Reset later, a toast message indicates the device will be factory reset the next time the car is started.
Enterprise devices
Android Automotive OS devices running Android 13 and higher can
declare support for the android.software.device_admin feature to enable enterprise
Device Management APIs (to learn more, see
DevicePolicyManager).
An organization can then use a
Device Policy
Controller (DPC) app to control local device policies and system apps on the device.
Automotive does not support Work Profiles, which means the only management solution supported is a Fully managed device, which is intended for company-owned devices over which the organization has complete management control.
Enterprises remotely managing the vehicle must also consider the car's drive-state. Hence,
specific remote actions are also integrated with the drive-state of a vehicle. For example, the
factory reset flow in
DevicePolicyManager.setFactoryResetProtectionPolicy() also applies
to enterprise-enabled vehicles.
Any API from DevicePolicyManagercode> can throw an exception (for example,
if the vehicle is moving). A partial list of DevicePolicyManagercode> APIs is provided
below. To learn more, see
Device administration overview.
DevicePolicyManager.removeActiveAdmin()DevicePolicyManager.setFactoryResetProtectionPolicy()DevicePolicyManager.installCaCert()DevicePolicyManager.uninstallCaCert()DevicePolicyManager.installKeyPair()DevicePolicyManager.removeKeyPair()
Enterprise device management for multiple users
Device management for Automotive works with Multi-user support. This means multiple drivers can use the same company-owned vehicle, but preserve and prevent their data privacy from being exposed to other drivers by using their own users.
The administrator can use a Device Policy Controller (DPC) app as described in Build a device policy controller to control device-wide or user-specific policies.
Automotive builds typically use the headless system user mode, in which case the Device Policy
Controller (DPC) would be set as the Device Owner (DO) of the system user and the Profile Owner (PO)
of every other user. The remote admin should affiliate the PO users, as some APIs (like
requestBugreport()) are only available if all users are affiliated. Then the
remote admin should select the proper DPC to execute actions. If the action is associated to the
device (like factory resetting through wipeData()), it should use the DO DPC. If it's
associated with a user (like addUserRestriction()), it should use the PO DPC.
For more information on how a DPC app manages multiple users, see Affiliated users.