​Building Video and Non-Templated Apps for Android Automotive OS™

​​

Android Open Source Project has introduced guidelines for developers to distribute Non-Templated apps for Android Automotive OS based systems.  For developers looking to bring their application from mobile or tablet to automotive,  this articles aim is to summarize the key points from the Android AOSP documentation, as well as provide additional context when specifically deploying your app to Ignite Store compatible infotainment systems.

Technical Requirements

Configure your app's manifest files

To target Android Automotive OS, there are a number of manifest entries your app must have. With them, apps targeting Android Automotive OS can be submitted to the Play Store using a separate Automotive release type, and will be put through a manual review process to ensure they're safe for use in a car. See Distribute Android apps for cars for more details.

Require Android Automotive OS™ features

To show up in the Ignite Store in a car, video apps built for Android Automotive OS must include the following <uses-library> element in the <application> element of the AndroidManifest.xml file.

<uses-library
  android:name="android-automotive-video"
  android:required="true"/>

Note: The android-automotive-video library will only be included on cars that are ready to support video apps. If a car maker is not ready to support video apps on a given vehicle, the library will not be available and the app will not show up in the Ignite Store on that vehicle.

Apps submitted to non-automotive stores cannot declare the above tag as they cannot depend on car-specific hardware. As such, to ship the same app on both Ignite automotive device and non-automotive devices (e.g. in Google Play Store), it is recommended that apps should generate at least two flavors of the app, one for automotive devices and another for mobile devices (phones and tablets). For more information on how to create these separate flavors, refer to the following documentation:


The two flavors of the app can share the same package name, see https://developer.android.com/training/cars/video#require_android_automotive_os_features for additional details if you plan to publish the application also for mobile in the Google Play store.

In addition to the <uses-library> element, apps built for Android Automotive OS must include the following <uses-feature> elements in the root <manifest> element.

<uses-feature
  android:name="android.hardware.wifi"
  android:required="false"/>
<uses-feature
  android:name="android.hardware.screen.portrait"
  android:required="false"/>
<uses-feature
  android:name="android.hardware.screen.landscape"
  android:required="false"/>

Explicitly setting these features to not required ensures that your app doesn't conflict with available hardware features in Android Automotive OS devices.

Mark your app as a video app

To indicate that you have an automotive app that supports video, add an XML file named automotive_app_desc.xml to the res/xml/ directory in your project. This file should include the following content:

<automotiveApp>
  <uses name="video"/>
</automotiveApp>

Note: You may see a lint error in Android Studio that says "Expecting one of media, notification, sms, or template for the name attribute in uses tag." This can be safely ignored by adding tools:ignore="InvalidUsesTagAttribute" to the <uses> element.

Note: the Android.com article above suggests that all apps that are not templated, must declare themselves as a video app.  If you do not think you're app fits in the video category, please contact our team to discuss.​

Then, within the <application> element of your manifest, add the following <meta-data> element referencing the XML file:

<meta-data
  android:name="com.android.automotive"
  android:resource="@xml/automotive_app_desc"/>

Ensure there are no distraction optimized activities

Video apps are currently meant for use only while parked. As such, no <activity> element should include the following <meta-data> element:

<!-- NOT ALLOWED -->
<meta-data
  android:name="distractionOptimized"
  android:value="true"/>

Without this metadata, your app's activities will be blocked automatically by the OS when the car enters driving mode to reduce distractions for the driver. To your app, this will happen as an onPause lifecycle callback, during which you should ensure both video and audio playback from your app is paused.

Important: Pausing audio and video playback is necessary to meet the car app quality guidelines against which your app will be reviewed when submitted to the Ignite Store.

Optimize your app for Android Automotive OS

To give your users the best experience possible, you may need to enable or disable certain functionality depending on if your app is running on a car or not.

Disable features

If an existing mobile app is being made available on Android Automotive OS, certain features and functionality may not be relevant or available. For example, cars generally do not provide access to cameras. Additionally, only a subset of Google Play services are available on Android Automotive OS - see Google Play services for cars for more details.

You can use the PackageManager.hasSystemFeature API to detect if the app is running on Android Automotive OS by checking for the FEATURE_AUTOMOTIVE feature.

KotlinJava

PackageManager packageManager = ... // Get a PackageManager from a Context
boolean isCar = packageManager.hasSystemFeature(PackageManager.FEATURE_AUTOMOTIVE)
if (isCar) {
  // Enable or disable a given feature
}

Alternatively, if your app also has an Android Auto component, it may make sense to use the CarConnection API from the Car App Library to detect if the app is running on Android Automotive OS, Android Auto, or if it is not connected to a car at all.

Handle offline scenarios

While cars are becoming increasingly internet connected, apps should be able to handle running without an internet connection, such as in the following cases:

  • Auto makers may offer cellular data as part of a subscription package (which users may or may not purchase).Users may have cellular data enabled, but access may be limited in certain areas (just like with a phone).
  • Cars may or may not have WiFi radios. In those that do, a car may never come into WiFi range or an OEM may have disabled WiFi in favor of a cellular network.
  • Apps should be prepared to handle these scenarios and gracefully degrade (for example, by offering offline content). For more information, see the best practices for optimizing networking.​


​​​​Google Service Dependencies / APK Level

Addition, to the article above, developers hoping to reach the largest number of OEMs should also consider that while Android Automotive OS adoption amongst car makers is quite high, many of those car makers are not shipping AAOS with Google Automotive and Google Play Services.  

Please read the link below for general requirements for apps when migrating .

Addressing Google Service Dependencies ​
​

For the latest guidance from Android Open Source Project on Non-Templated Apps. please visit the link below.

Link to Article​​

​​Android Advertising ID

See Get a user-resettable ad ID which uses the ads-identifier library. If the library does not return a valid ID, you can alternative use the ANDROID_ID.

See also Best practices for unique identifiers



​​

UI Guidelines

Although not strictly enforced during our certification process, it's recommended that font and touch target sizing should be optimized for a "lean back" in-vehicle experience.  While screen-sizes are often comparable to tablets in the consumer electronics world, the distance at which the user's head is in proximity to the screen is often quite different, as well as the position of the hands (since the display is mounted).   In order to accomodate these differences,  please review the two links below. 

​​​​Touch Target Sizing Guidelines  

Touch Targets Article

Font Sizing Guidelines​

Text Legibility

Testing Your App

​[INTERNAL NOTE] This section should be it's own article.​

To begin building your app for Android Automotive OS, the first thing you should do is test your existing mobile app (for phones and tablets) on an  Ignite Android Automotive OS emulator or reference board. To set up an emulator, follow the steps in Test Android apps for Ignite Automotive. You can then run the app by following these instructions.

When running your app, you should watch out for compatibility issues such as the following:

  • Infotainment screens come in fixed orientations. Per the car app quality guidelines, apps should support both portrait and landscape orientations.
  • Ignite requires the support for the following display sizes
  • Automotive Automotive do not provide a physical or virtual BACK button, the application has to provide a way to go back from each sub screen.
  • APIs available on other Android devices may not be available on Android Automotive OS. Google Play Services APIs are not available on the Ignite Android Automotive OS. See Disable features and Alternative features for more details on how to handle these issues.

​​Self Certification

After reading the Android.com article and making the necessary changes to your application.  It is highly recommended that you check your app for compliance with the following test cases.  The list of cases are a sample of the types of issues we will review during the certification process after. you submit your app for review.
Please see Android.com car app quality guidelines developer article.

If you'd like to understand what Harman's certification process involves, please download the sample set of test cases.  Please note that this list is not meant to be exhaustive, or guaranteed to be up to date with the latest version our certification team will actually use.  It is simply an illustrative example to give you a sense of the types of functions we will test for.  

Test Case_Generic_Video Apps.xlsx


​​