Preface
Several of the problems encountered in Android Automotive recently are related to the driving mode applied on Android's car operating system. There is very little information about this in China. I will summarize the relevant knowledge here, mainly including the following aspects:
- The difference between Android Automotive and Android Auto
- Introduction to Android Automotive's driving mode
- Android Automotive implements several implementation methods and code examples of driving mode, as well as implementation effects
I mainly want to summarize the ways Android car applications can adapt to Automotive driving mode (Drive Mode).
Development Environment
Android Studio version 4.1.2
1. The difference between Android Automotive and Android Auto
Android Auto：
Android Auto is an Android-side app designed specifically for driving environments
- It can be used to map some functions on Android devices to the screen of the car through data cables. At that time, Android Auto was focused on security. In order to prevent users from picking up their phones during driving, Google added Google Assistant to Android Auto, that is, using voice interaction in the driving environment, so that users can implement some mobile app operations without changing their physical postures.
- The disadvantage is that the mobile phone application is mapped to the car computer through the data cable. The application is still running on the mobile phone, centered on the mobile phone, so that the data related to the car itself, such as vehicle speed, GPS, sensors, and driving status cannot be synchronized to the mobile phone.
Android Automotive is an operating system and open source platform that can run on the on-board hardware.
Our most common Android platform is tested on mobile phones or tablets. Compared with our common Android operating systems, Android Automotive has the same code base, and has specially added specific functions and technical support for cars, mainly including the following aspects:
- Car App: includes apps that are pre-installed by OEM and developed by third parties and downloaded to the car machine through the on-board app store
- Car API: OEM car manufacturers provide unique interfaces to automotive apps, including APIs related to dashboards, APIs related to vehicle hardware (cockpit, ventilation, etc.), multimedia, navigation, on-board system setting interface and vehicle sensor-related APIs.
- Car Service: Car Service is a system service that provides a series of services related to cars.
- Vehicle Network Service: Network Services for OEM vendors
- Vehicle HAL: Description of the hardware abstraction layer of the car
Android Auto actually displays data on the mobile phone, while Android Automotive needs to consider the synchronization of data and account with mobile app*
2. Introduction to Android Automotive's driving mode
As mentioned earlier, Google's original intention of launching Android Auto at the 2014 I/O Conference was to better ensure driving safety. Android Automotive has also added Drive Mode, aiming to help automotive OEM manufacturers manage applications that may cause driver distraction from the system level.
In driving mode, Android Automotive will make a series of suggestions for Driving Distraction. OEM manufacturers can also require an Activity or Fragment interface that may cause distraction to the driver, and register themselves as Distraction Optimized in the Manifest File, such as a login interface that requires driver operation, a QR code interface, a song switching interface, or a video playback interface, or a game interface.Android Automotive will actively restrict the interface marked Distraction Optimized in driving mode.
3. Several implementation methods and code examples of Android Automotive to implement driving mode
Method 1. In the Manifest file, use metadata to mark interfaces that may cause distracted driving
Android Automotive will identify activities or Fragments marked with distractionOptimized using metadata as interfaces that need to be optimized, and disable these interfaces in driving mode, or add a prompt box with a higher UI level above the current activity, thereby avoiding distractions from these interfaces during driving.
<activity android:name=".QRCodeScanPage"> <meta-data android:name="distractionOptimized" android:value="true"/> </activity>
The above code is used to scan the QRCodeScanPage interface for users to log in. It will be processed differently by Android Automotive when driving. OEM car manufacturers can also customize Android Automotive and add cover to the restricted interface.
As you can see, this way of handling distraction interfaces is simple and crude. Just add a Meta-data tag to the component elements in the Manifest file. The disadvantage is that it is not flexible enough. All distraction interfaces will have the same effect after being covered. The unified covering method provided by the system often directly blocks the entire UI interface in order to be suitable for the distraction interface of each application. Even if the UI of the QR code is very small, it still needs to cover the entire screen, which is very bad.
Method 2. Use the CarDrivingStateManager class to obtain the current driving state of the car. After obtaining the driving state, the occlusion scheme of the distraction interface is defined by yourself.
The CarDrivingStateManager class of Android Automotive can obtain the current driving state (stop, idling, driving) of the car based on the sensor data provided by the vehicle hardware abstraction layer (VHAL). In this way, the application can set the CarDrivingStateEventListener monitor through the following settings:
Guide package:
import ; /* For CarDrivingState */ import ; import ;
private final
mDrivingStateEventListener =
new () {
@Override
public void onDrivingStateChanged(CarDrivingStateEvent event) {
mDrivingStateEvent = event;
handleDrivingStateChange();
}
};
Android Automotive defines the following four states for DrivingState:
/** * This is when we don't have enough information to infer the car's driving state. */ public static final int DRIVING_STATE_UNKNOWN = -1; /** * Car is parked - Gear is in Parked mode. */ public static final int DRIVING_STATE_PARKED = 0; /** * Car is idling. Gear is not in Parked mode and Speed of the vehicle is zero. */ public static final int DRIVING_STATE_IDLING = 1; /** * Car is moving. Gear is not in parked mode and speed of the vehicle is non zero. */ public static final int DRIVING_STATE_MOVING = 2;
DrivingStateManager code:
mDrivingStateManager = (CarDrivingStateManager) (
Car.CAR_DRIVING_STATE_SERVICE);
/* Register the listener (implemented below) */
(mDrivingStateEventListener);
/* While we wait for a change to be notified, query the current state */
mDrivingStateEvent = ();
This allows you to obtain the current vehicle's three driving states: stop, idling, driving, and may also return to UNKNOWN, which requires the developer to handle.
In addition, here is a tip, through the CarUxRestrictions objectisRequiresDistractionOptimization()Method: You can directly obtain whether the current vehicle is in a driving state, 1 means that the vehicle is in a driving state, and 0 means that the non-driving state.
We see that the second method above can actively query the driving status of the vehicle, and then decide whether to display the distraction interface based on the results returned by the DrivingStateEventListener, or write the cover code yourself. Compared with Method One, it adds a lot of flexibility.
Method 3. Use CarUxRestrictionsManager and listen for OnUxRestrictionsChangedListener
Guide package:
import ; /* For CarUxRestrictions */ import ; import ;
As you can see from the CarUxRestrictionManager below, OnUxRestrictionsChangedListener provides monitoring of driving mode restriction state changes:
@Nullable private CarUxRestrictionsManager mCarUxRestrictionsManager;
private CarUxRestrictions mCurrentUxRestrictions;
/* Implement the onUxRestrictionsChangedListener interface */
private mUxrChangeListener =
new ()
{
@Override
public void onUxRestrictionsChanged(CarUxRestrictions carUxRestrictions) {
mCurrentUxRestrictions = carUxRestrictions;
/* Handle the new restrictions */
handleUxRestrictionsChanged(carUxRestrictions);
}
};
The three main application scenarios of this method are: distraction events that are not suitable for monitoring at startup or distraction interfaces that last longer. For example, long-term video playback applications, etc.
Conclusion
The above introduces the driving mode of Android Automotive, as well as several methods of implementation, the advantages and disadvantages and application scenarios of each method. Tomorrow, knee arthroscopy surgery, the network here is not good. When you go back, you can implement the code on the virtual machine of the Android vehicle system. Using the following ADB instructions, you can simulate the current vehicle speed and verify the change in driving status. The last parameter is the speed, which is meters/second.
adb shell dumpsys activity service inject-vhal-event 0x11600207 40
The above is a detailed explanation of the adaptation of Android Automotive on-board applications to driving mode (Safe Drive Mode). For more information about Android Automotive adaptation to driving mode (Safe Drive Mode), please follow my other related articles!