2.5. Automotive Requirements

Android Automotive implementation refers to a vehicle head unit running Android as an operating system for part or all of the system and/or infotainment functionality.

Android device implementations are classified as an Automotive if they declare the feature android.hardware.type.automotive or meet all the following criteria.

  • Are embedded as part of, or pluggable to, an automotive vehicle.
  • Are using a screen in the driver's seat row as the primary display.

The additional requirements in the rest of this section are specific to Android Automotive device implementations.

2.5.1. Hardware

Automotive device implementations:

  • [7.1.1.1/A-0-1] MUST have a screen at least 6 inches in physical diagonal size.

  • [7.1.1.1/A-0-2] MUST have a screen size layout of at least 750 dp x 480 dp.

  • [7.2.3/A-0-1] MUST provide the Home function and MAY provide Back and Recent functions.

  • [7.2.3/A-0-2] MUST send both the normal and long press event of the Back function (KEYCODE_BACK) to the foreground application.

  • [7.3.1/A-SR] Are STRONGLY RECOMMENDED to include a 3-axis accelerometer.

If Automotive device implementations include a 3-axis accelerometer, they:

If Automotive device implementations include a GPS/GNSS receiver and report the capability to applications through the android.hardware.location.gps feature flag:

  • [7.3.3/A-1-1] GNSS technology generation MUST be the year “2017” or newer.

If Automotive device implementations include a gyroscope, they:

  • [7.3.4/A-1-1] MUST be able to report events up to a frequency of at least 100 Hz.

Automotive device implementations:

  • [7.3.11/A-0-1] MUST provide current gear as SENSOR_TYPE_GEAR.

Automotive device implementations:

  • [7.3.11.2/A-0-1] MUST support day/night mode defined as SENSOR_TYPE_NIGHT.

  • [7.3.11.2/A-0-2] The value of the SENSOR_TYPE_NIGHT flag MUST be consistent with dashboard day/night mode and SHOULD be based on ambient light sensor input.

  • The underlying ambient light sensor MAY be the same as Photometer.

  • [7.3.11.4/A-0-1] MUST provide vehicle speed as defined by SENSOR_TYPE_CAR_SPEED.

  • [7.3.11.5/A-0-1] MUST provide parking brake status as defined by SENSOR_TYPE_PARKING_BRAKE.

  • [7.4.3/A-0-1] MUST support Bluetooth and SHOULD support Bluetooth LE.

  • [7.4.3/A-0-2] Android Automotive implementations MUST support the following Bluetooth profiles:

    • Phone calling over Hands-Free Profile (HFP).
    • Media playback over Audio Distribution Profile (A2DP).
    • Media playback control over Remote Control Profile (AVRCP).
    • Contact sharing using the Phone Book Access Profile (PBAP).

  • [7.4.3/A-SR] Are STRONGLY RECOMMENDED to support Message Access Profile (MAP).

  • [7.4.5/A] SHOULD include support for cellular network-based data connectivity.

  • [7.4.5/A] MAY use the System API NetworkCapabilities#NET_CAPABILITY_OEM_PAID constant for networks that should be available to system apps.

  • [7.6.1/A-0-1] MUST have at least 4GB of non-volatile storage available for application private data (a.k.a. “/data” partition).

Automotive device implementations:

  • [7.6.1/A] SHOULD format the data partition to offer improved performance and longevity on flash storage, for example using f2fs file-system.

If Automotive device implementations provide shared external storage via a portion of the internal non-removable storage, they:

  • [7.6.1/A-SR] Are STRONGLY RECOMMENDED to reduce I/O overhead on operations performed on the external storage, for example by using SDCardFS.

If Automotive device implementations are 32-bit:

  • [7.6.1/A-1-1] The memory available to the kernel and userspace MUST be at least 512MB if any of the following densities are used:

    • 280dpi or lower on small/normal screens
    • ldpi or lower on extra large screens
    • mdpi or lower on large screens

  • [7.6.1/A-1-2] The memory available to the kernel and userspace MUST be at least 608MB if any of the following densities are used:

    • xhdpi or higher on small/normal screens
    • hdpi or higher on large screens
    • mdpi or higher on extra large screens

  • [7.6.1/A-1-3] The memory available to the kernel and userspace MUST be at least 896MB if any of the following densities are used:

    • 400dpi or higher on small/normal screens
    • xhdpi or higher on large screens
    • tvdpi or higher on extra large screens

  • [7.6.1/A-1-4] The memory available to the kernel and userspace MUST be at least 1344MB if any of the following densities are used:

    • 560dpi or higher on small/normal screens
    • 400dpi or higher on large screens
    • xhdpi or higher on extra large screens

If Automotive device implementations are 64-bit:

  • [7.6.1/A-2-1] The memory available to the kernel and userspace MUST be at least 816MB if any of the following densities are used:

    • 280dpi or lower on small/normal screens
    • ldpi or lower on extra large screens
    • mdpi or lower on large screens

  • [7.6.1/A-2-2] The memory available to the kernel and userspace MUST be at least 944MB if any of the following densities are used:

    • xhdpi or higher on small/normal screens
    • hdpi or higher on large screens
    • mdpi or higher on extra large screens

  • [7.6.1/A-2-3] The memory available to the kernel and userspace MUST be at least 1280MB if any of the following densities are used:

    • 400dpi or higher on small/normal screens
    • xhdpi or higher on large screens
    • tvdpi or higher on extra large screens

  • [7.6.1/A-2-4] The memory available to the kernel and userspace MUST be at least 1824MB if any of the following densities are used:

    • 560dpi or higher on small/normal screens
    • 400dpi or higher on large screens
    • xhdpi or higher on extra large screens

Note that the “memory available to the kernel and userspace” above refers to the memory space provided in addition to any memory already dedicated to hardware components such as radio, video, and so on that are not under the kernel’s control on device implementations.

Automotive device implementations:

  • [7.7.1/A] SHOULD include a USB port supporting peripheral mode.

Automotive device implementations:

  • [7.8.1/A-0-1] MUST include a microphone.

Automotive device implementations:

  • [7.8.2/A-0-1] MUST have an audio output and declare android.hardware.audio.output.

2.5.2. Multimedia

Automotive device implementations MUST support the following audio encoding:

  • [5.1/A-0-1] MPEG-4 AAC Profile (AAC LC)
  • [5.1/A-0-2] MPEG-4 HE AAC Profile (AAC+)
  • [5.1/A-0-3] AAC ELD (enhanced low delay AAC)

Automotive device implementations MUST support the following video encoding:

  • [5.2/A-0-1] H.264 AVC
  • [5.2/A-0-2] VP8

Automotive device implementations MUST support the following video decoding:

  • [5.3/A-0-1] H.264 AVC
  • [5.3/A-0-2] MPEG-4 SP
  • [5.3/A-0-3] VP8
  • [5.3/A-0-4] VP9

Automotive device implementations are STRONGLY RECOMMENDED to support the following video decoding:

  • [5.3/A-SR] H.265 HEVC

2.5.3. Software

Automotive device implementations:

  • [3/A-0-1] MUST declare the feature android.hardware.type.automotive.

  • [3/A-0-2] MUST support uiMode = UI_MODE_TYPE_CAR.

  • [3/A-0-3] MUST support all public APIs in the android.car.* namespace.

  • [3.4.1/A-0-1] MUST provide a complete implementation of the android.webkit.Webview API.

  • [3.8.3/A-0-1] MUST display notifications that use the Notification.CarExtender API when requested by third-party applications.

  • [3.8.4/A-0-1] MUST implement an assistant on the device that provides a default implementation of the VoiceInteractionSession service.

  • [3.13/A-SR] Are STRONGLY RECOMMENDED to include a Quick Settings UI component.

If Automotive device implementations include a push-to-talk button, they:

  • [3.8.4/A-1-1] MUST use a short press of the push-to-talk button as the designated interaction to launch the user-selected assist app, in other words the app that implements VoiceInteractionService.

Automotive device implementations:

  • [3.14/A-0-1] MUST include a UI framework to support third-party apps using the media APIs as described in section 3.14.

2.5.4. Performance and Power

If Automotive device implementations include features to improve device power management that are included in AOSP or extend the features that are included in AOSP, they:

  • [8.3/A-1-1] MUST provide user affordance to enable and disable the battery saver feature.
  • [8.3/A-1-2] MUST provide user affordance to display all apps that are exempted from App Standby and Doze power-saving modes.

Automotive device implementations:

  • [[8.2](#8.2_File I/O Access Performance)/A-0-1] MUST report the number of bytes read and written to non-volatile storage per each process's UID so the stats are available to developers through System API android.car.storagemonitoring.CarStorageMonitoringManager. The Android Open Source Project meets the requirement through the uid_sys_stats kernel module.
  • [8.4/A-0-1] MUST provide a per-component power profile that defines the current consumption value for each hardware component and the approximate battery drain caused by the components over time as documented in the Android Open Source Project site.
  • [8.4/A-0-2] MUST report all power consumption values in milliampere hours (mAh).
  • [8.4/A-0-3] MUST report CPU power consumption per each process's UID. The Android Open Source Project meets the requirement through the uid_cputime kernel module implementation.
  • [8.4/A] SHOULD be attributed to the hardware component itself if unable to attribute hardware component power usage to an application.
  • [8.4/A-0-4] MUST make this power usage available via the adb shell dumpsys batterystats shell command to the app developer.

2.5.5. Security Model

If Automotive device implementations support multiple users, they:

  • [9.5/A-1-1] MUST include a guest account that allows all functions provided by the vehicle system without requiring a user to log in.

If Automotive device implementations support a secure lock screen, they:

Automotive device implementations:

  • [9.14/A-0-1] MUST gatekeep messages from Android framework vehicle subsystems, e.g., whitelisting permitted message types and message sources.
  • [9.14/A-0-2] MUST watchdog against denial of service attacks from the Android framework or third-party apps. This guards against malicious software flooding the vehicle network with traffic, which may lead to malfunctioning vehicle subsystems.