Android Auto - Safely Connecting Cars

Inspecting the Android Auto solution - with guidance around the security considerations of implementing it in apps and head units

Google are working for vehicles to become more connected, as seen in their self driving car project. But they are also working in other ways to make vehicles smarter. One of these is “Android Auto”, a solution to build a bridge between vehicle head units and user’s Android devices, launched in June 2014.

Android Auto logo normal.1

Android Auto Screenshot normal.1

This article inspects the Android Auto solution, and gives guidance to security considerations of implementing it in apps and head units.

Android Auto Components

Android Auto is a way for Android smart phones, and the apps that they run, to connect into a vehicle’s console and sound systems. It’s made up of three components:

  • An Android Auto enabled head unit
  • An Android smart phone running Android 5.0 or greater with the Android Auto app installed
  • Third party apps that are designed to support Android Auto

There are several key concerns when connecting devices to vehicles in this manner. We don’t want to lower the security of the phone or its apps, nor do we want to communicate insecurely with the vehicle from the phone. Finally for head unit and vehicle manufacturers, we don’t want to risk allowing mobile users to access more functionality than just the console screen and vehicle sound systems.

Android Auto for app developers

For app designers, Android Auto is a useful feature that makes apps more usable by having them show notifications on a car’s console, or by allowing them to play media through the car sound system. Android provide clear instructions to developers to show how to use this API in their apps.

If a developer wants their notifications to show up on the console, then they can build notifications in the regular Android manner, but extended with CarExtender. The Android’s Auto App will pick up these notifications and handle getting them to the head unit.

It is also possible for the app to be informed when a user has acknowledged the notification, or maybe has produced a reply. In this case, the app needs to add a pending intent to the notification.

Pending intents have been known to have some security issues in the past. By using them, the app is allowing another app to call activities that are then executed with its privileges. The Google developer pages show how both to do this securely and insecurely.

The type of pending intent is up to the developer, but must be included in the app’s AndroidManifest.xml. The example shown by Google has two major security flaws:

android code normal.1

Firstly the broadcast receiver has an intent-filter, but is not marked as export=false. This means that any other app on the same device could call these end-points and interact with this app in an unintended way.

The second issue is that the app is using broadcasts for pending intents. This means that the messages will be broadcast to any app that is interested to register a broadcast receiver. SMSmessages are usually strictly controlled on modern Android devices so that only apps that the user has selected can read their text messages. It is recommended that instead, an Activity is used as a pending intent.

Using pending intents can be used securely. Google’s guide to the subject can be found here

Android Auto for car manufacturers & head unit manufacturers

Car manufacturers also need to consider security protections when designing and implementing Android enabled head units. Many in vehicle entertainment systems aren’t simple music players, but instead connect to many components of the car so as to display information such as fuel consumption and engine temperature. As has been shown in several recent reports car hacking is more than just a theoretical attack, so an attack from an Android device should be considered when designing and Android Auto head unit.

In some instances Android is used on the Android enabled head units, making it an area with known vulnerabilities and known exploits. Manufacturers should therefore be careful to enforce two key areas of security: segregation and patching.

Patching is a well-known method in the IT world to keep systems safe from known issues. But in embedded devices there is the issue of how to get the latest versions of libraries and applications to a system that may not have a network connection, or at least not one capable of transferring large files.

For some manufacturers, the choice has been made to rely on the customers to patch – a method becoming avoided in the IT world – but where possible a process of patch management could form part of a vehicle’s servicing.

The other area of segmentation is a more technically complex one. Android has always used app sandboxing to keep apps’ data separate, and to prevent an app reaching resources that it should not be able to access through the permissions model. Similar considerations will needed to be given to apps on the head unit. We do not trust the media coming from our customers’ devices, so what would happen if the media app is compromised through malicious input? Hopefully the media app has only the few permissions it needs, so a compromise would have little impact on the vehicle’s safety. Otherwise mobile malware may take on a far more dangerous form.


As we have seen, Android Auto provides a simple and effective way for apps to interact with head units through well documented API. However as with building any type of Android application, it is important to understand and design products with security in mind. In the case of using Android in vehicles, this presents a unique landscape, with unique challenges. It will be important to be proactive to make sure that customers remain confident in products.



Accreditations & Certificates

MWR is an accredited member of The Cyber Security Incident Response Scheme (CSIR) approved by CREST (Council of Registered Ethical Security Testers).
MWR is certified under the Cyber Incident Response (CIR) scheme to deal with sophisticated targeted attacks against networks of national significance.
We are certified to comply with ISO 9001 and 14001 in the UK, internationally accepted standards that outline how to put an effective quality and environmental management systems in place.
MWR is certified to comply with ISO 27001 to help ensure our client information is managed securely.
As an Approved Scanning Vendor MWR is approved by PCI SSC to conduct external vulnerability scanning services to PCI DSS Requirement 11.2.2.
We are members of the Council of Registered Ethical Security Testers (CREST), an organisation serving the needs of the information security sector.
MWR is a supplier to the Crown Commercial Service (CCS), which provides commercial and procurement services to the UK public sector.
MWR is a Qualified Security Assessor, meaning we have been qualified by PCI to validate other organisation's adherence to PCI DSS.
As members of CHECK we are measured against high standards set by NCSC for the services we provide to Her Majesty's Government.
MWR’s consultants hold Certified Simulated Attack Manager (CCSAM) and Certified Simulated Attack Specialist (CCSAS) qualifications and are authorized by CREST to perform STAR penetration testing services.