Section 3
Having a compatible app for automotive
Our app store solution, designed for both front and back seats of the car, supports all main app categories.
If the technical requirements outlined in Section 2 are met, the app should run without major constraints regardless of if it’s a navigation, media, video conference or gaming app. In other words, it’s not mandatory that the app is built specifically for Android Automotive, as mobile/tablet versions can also work if the car is Parked (not moving).
Driver distraction guidelines and restrictions
Recent Android Automotive platforms restrict application functionality according to the driving state to minimize driver distraction. However, when Android Automotive applications are compliant with the Driver Distraction Guidelines (DDG), the applications can run on the HU when a vehicle is moving.
DDG consists of baseline recommendations provided by Google which can be consulted in more detail here. Applications that meet the Driver Distraction Guidelines can be tagged as Distraction Optimized and are able to run in the User Experience Restricted state. For an entire app to be designated as Distraction Optimized, all its activities must adhere to the driver distraction guidelines. When the driving state of a vehicle changes to a state in which the UX restrictions are active:
- Current foreground activity can continue to run only when it is tagged as Distraction Optimized in the manifest.
- When launching a new activity, the new activity is permitted only when it is tagged as Distraction Optimized in the manifest.
The platform is responsible for checking the manifest and allowing only Distraction Optimized activities to run in a restricted state.
Not all application activities need be Distraction Optimized. An application can provide different user experiences for an unrestricted state (for example, when the vehicle is parked) versus a more restricted state. As a result, an application can tag a specific activity to be Distraction Optimized by adding the following metadata to the <activity> element in the AndroidManifest xml file for the application:
<activity android:name=”.DistractionOptimizedMainActivity”….>
….
<meta-data android:name=”distractionOptimized” android:value=”true”/>
</activity>
Apps that offer activities designed to run in a restricted state must declare that information in the manifest. The platform looks only at the declared information before determining if the activity can be permitted to run (or not) in the restricted state.
Driver distraction is one of the most concerning topics for Faurecia Aptoide, when deploying apps in the IVI of cars.
For an app to run while the car is moving a set of restrictions need to be respected. Media, Messaging and Navigation apps can be easily adapted to abide to the restrictions by using the templates provided by Android. All apps that don’t fit in those categories, or that prefer to have their own UI experience, must respect the following checklist (under review).
Restrictions
The app does not display animated elements on the screen such as animated graphics, video, or progress bars.
The app does not display text-based advertising other than the advertiser’s name or the product name.
The app does not display visual advertising (image or video).
App elements do not display any images on the screen.
Users must be able to complete tasks in the app using five screens or fewer.
The app does not include games or other features outside the app types (media and messaging) intended for cars.
Do not display static information not related to driving. Examples not related to driving:
- Function Description
- Detailed information of restaurants and hotels
Limit character input operation
The app does not display automatically scrolling text.
The app provides white icon sets that the system colorizes to provide automatic contrast compensation.
The app provides icons and colors that meet Android Automotive contrast requirements.
The app provides colors that the system can optimize for easy in-vehicle readability.
The app must support voice commands in audio apps.
App-specific buttons respond to user actions with no more than a 2 second delay.
The app launches in no more than 10 seconds.
The app loads content in no more than 10 seconds.
App functionality works as expected or described in the app’s info page.
When the app is relaunched from the home screen, the app restores the app state as closely as possible to the previous state.
Interactive elements that are intentionally grayed-out must be non-functional.
The navigation audio channel may only be used by navigation apps and for navigation instructions
The app must not allow users to make a purchase on the car screen
Media apps do not autoplay on startup or without user initiated action to select the app or app media.
The app does not present advertisements through notifications
The app displays notifications only when relevant to the driver’s needs.
The app receives incoming messages
Messages are properly grouped and displayed in the correct order.
The user can reply to a message.
The app uses short-form messaging app design patterns. Traditional long-form messaging apps, such as apps for email, are not permitted
The app implements a peer-to-peer messaging service and not notification services such as those for weather, stocks, and sport scores.
The app must provide turn-by-turn navigation directions.
The app does not display detailed roads (roads under 5.5m in width)
The app does not display addresses, phone numbers or email addresses as guiding information
The app draws only map content on the surface of the navigation templates.
Text-based turn-by-turn directions, lane guidance, and estimated arrival time must be displayed on the relevant components of the Navigation template.
Additional information relevant to the drive (e.g., speed limit, road obstructions) can be drawn on the right side of the map.
When the app provides text-based turn-by-turn directions, then it must also trigger navigation notifications.
When the navigation app provides text-based turn-by-turn directions, it must send next-turn information to the vehicle’s cluster display.
The app must not conflict with other navigation apps when providing turn-by-turn notifications or turn-by-turn voice guidance
The app must handle navigation requests from other Android Automotive apps.
The app must draw a light-themed or dark-themed map when instructed to do so
The app must provide a “test drive” mode that simulates driving.
Driver distraction definition and assessment
Depending on the car driving state (Parked, Idling, Driving) any activity that is not clearly declared as optimized for driving can be blocked.
To adapt the app to the different driving states, app developers have access to the CarUxRestrictions module which informs if any Driver Distraction optimization is needed and what restrictions are to be applied. Any combination of the following restrictions can be demanded by OEMs:
- NONE,
- UX_RESTRICTIONS_BASELINE,
- UX_RESTRICTIONS_NO_DIALPAD,
- UX_RESTRICTIONS_NO_FILTERING,
- UX_RESTRICTIONS_LIMIT_STRING_LENGTH,
- UX_RESTRICTIONS_NO_KEYBOARD,
- UX_RESTRICTIONS_NO_VIDEO,
- UX_RESTRICTIONS_LIMIT_CONTENT,
- UX_RESTRICTIONS_NO_SETUP,
- UX_RESTRICTIONS_NO_TEXT_MESSAGE, and
- UX_RESTRICTIONS_NO_VOICE_TRANSCRIPTION
More information can be found here.
Best practices in designing/adjusting your app for automotive environment
Despite most of the apps being functional in the car without any effort, there are potential improvements that could be made to ensure a good experience for car usage. App developers can find below some of the adjustments that top automotive publishers have made to improve their apps and that Faurecia Aptoide also recommends.
- Majority of head-unit and rear-seat displays favour landscape orientation over portrait. It’s important that all app sections are fully functional in landscape and correctly displaying all UI elements.
- For IVI, UX in-car should also be streamlined as to minimize the attention necessary to interact with the app. The number of touches and information displayed should be optimized for simplicity using familiar design patterns.
- Connectivity in-car may not be as stable and fast as at home for instance. If your app has video on demand, it’s recommended that it uses updated codecs and streaming protocols such as EVC and AV1.
- Some app features may also be limited or disabled entirely if the car is in movement. This can be done by making use of some Google APIs often supported by AOSP platforms.
- On monetization Native and Audio ads should be prioritized over more intrusive ad formats. For in-app payments, it is recommended to use Faurecia Aptoide or app developer’s payment solution.
If the app has media playback, it can further be optimized and delegate the UI rendering to the platform, which will be covered in the next section.
In addition to our guidelines and best practices, Google has also launched a set of design guidelines for automotive OS apps that can be adhered to improve the application.
Building automotive apps
Android apps for cars should avoid driver distraction above all else. You can minimize distractions by following best practices, such as using voice commands and a very simple visual design.
Great car experiences are predictive and predictable. Your app should show timely information to the driver only when it’s relevant, and use simple, predictable patterns for common tasks.
Visual design
Content designed for a car screen must be legible and glanceable, with a consistent UI and large touch targets that drivers can identify under all viewing conditions.
Here are the interaction principles:
- Make content easy to read
- Make targets easy to touch
- Keep UI elements consistent
You can get more information about these principles and how they can impact on app building here.
Interactions
Interactions between a driver and a screen must be simple, non-distracting, and interruptible, so the driver’s attention can quickly return to the road.
As the visual foundations follows a set of principles all the interactions between user and the app should follow a list of principles:
- Keep information current and glanceable
- Encourage hands-on driving
- Prioritize driving tasks
- Discourage distraction
You can get more information about these principles and how they can impact on app building here.
Style foundations
The principles described above do not work in isolation, but when we combine them, we form an automotive style.
The foundations for designing an automotive application have been laid out on the webpage, where we can find some examples of how to improve the UX of an application for a certain category.
App templates
Media Apps (Audio)
For media apps, Android Automotive or platforms with similar functionality can provide an API to connect with the vehicle-optimized media browser. Developers can integrate their content with this API through a media browser service that allows the system to discover and display the media content.
The main advantage is to allow the developers to focus on the core parts of the app while leaving the car-friendly UI rendering to the system, with the added benefit of streamlining the experience for the user.
All the information for this topic can be found here.
Video apps
One of the most recent use-cases documented and thought of by Google is video applications, or applications with a video gallery included in their functionality.
According to the following page it is possible to create automotive applications for video content, to provide a good user experience, with the automotive environment as a base.
Navigation and POI Apps
One of the most popular use-cases when thinking about using apps in a car is navigating to a specific geographic location and adding Points of Interest to a map when driving.
As these are use-cases that require various specifics when it comes to implementation it is important to read the documentation pages of POI and navigation apps.
Common issues found in apps
Some OEMs may be using an AOSP based system (standard Android) and not AAOS (Android Automotive), which means that Car APIs from Android Automotive library might not be available. Please make sure that your app doesn’t crash in case Car API is not available, e.g.:
try {
car = Car.createCar(context)
if (car == null) {
Log.e(TAG, "Failed to instantiate Car.")
// Car could not be initiated, proceed with the needed changes
} else {
// Car API is available
}
} catch (ncdfe: NoClassDefFoundError) {
// Car API not available, proceed with the needed changes
}
For Audio apps that follow the Media Apps (Audio) Template, in addition to the known documentation, the following recommendations should be considered:
-
When a request made to your app cannot be handled but the app can continue to play, please avoid fatal errors and use non-fatal errors instead; this will improve the user experience since payback is not interrupted, even if an error message can still be shown to the user;
-
Be cautious with the handing of transient PlaybackStates when new content is requested to play, since Media Center Apps from different OEMs may react to the PlaybackStates differently from the default AAOS Media Center app; in particular avoid transient states such as STOPPED or ERROR when connecting to new content; use appropriately states such as BUFFERING instead;
-
Make sure your app always updates the available actions; E.g. if at the end of a playlist the SKIP_TO_NEXT action cannot be handled by your app or is not supported, please make sure to update the Playback Actions accordingly.
Localization is a crucial aspect of app development that must be considered, especially since our partner OEMs have a broad geographical coverage. To ensure a wider reach, your app should provide translations for the official languages of the regions where you are distributing.
If your app requires the display of long texts, such as terms of service or other legal information, using WebViews or alternative solutions, such as opening in an external browser, may not be optimized for driving. Some OEMs may also choose not to support browsers for safety reasons.
To ensure that your app is safe and fully optimized for driving, we recommend that you either display the text directly in your app or provide a QR code that can be scanned with a mobile phone to access the information. However, it is essential to follow the driver distraction guidelines while displaying any content, ensuring that the driver’s attention is not diverted from the road.