Incorporating Driver Distraction Guidelines into AAOS Apps

Faurecia Aptoide

Introduction

There is an inherent contradiction at play when app developers switch their attention to the automotive environment. Whereas phone apps are often designed to distract from everyday tasks and take the user into a different world for a few minutes, there are obvious reasons why in-car apps cannot do the same. Anything that distracts a driver from his primary task of driving the vehicle safely, is a clear no-no.

It is estimated that somewhere between 10% and 30% of all car accidents are caused by driver distraction, so authorities and car manufacturers alike are understandably nervous about adding any extra distractions to the driving experience. For this reason, very strict guidelines are in place to make sure that whilst on the move, any active apps are not encouraging drivers to take their eyes off the road.

Of course, there are large chunks of time spent in cars that aren’t moving. Once parked and stationary (or waiting for your electric vehicle to charge) there is no longer a reason why the driver needs 100% attention on the road. When this is the case, the restrictions on what an app can and can’t do can be relaxed and people can enjoy the full functionality of their infotainment systems. With sales of electric vehicles seeing huge growth and autonomous vehicles already starting to appear on the roads, more and more use cases are likely to appear.

How Does AAOS handle these different states?

To help mitigate this situation, Google have developed a comprehensive set of Driver Distraction Guidelines which can help app developers through the process and ensure that apps produced for Android Automotive OS are safe and suitable for in-car use. Developers can use these guidelines to adapt existing apps for in-car use or to develop brand new apps designed specifically for that environment.

The fundamental principles of the guidelines are that the car can be in 3 states (Parked, Idling and Driving) and that any app running in each of those 3 states needs to be appropriately ‘distraction optimised’

Parked (Vehicle gear is ‘Parked’) – no restrictions on functionality required
Idling (Vehicle gear is not ‘Parked’ but speed is zero) – no video and no configuration allowed
Driving (Vehicle gear is not parked and speed is not zero) – in addition to the above, no keyboard display, no text messaging, no dialling pad etc.

All Apps that run on AAOS need to be tagged as ‘Distraction Optimised’, otherwise they will not run in any of the restricted states. This means that any android mobile apps running on the vehicle will be blocked as soon as it starts moving. It’s important to note however that the system itself cannot detect an app’s actual adherence to the guidelines, only that it is tagged correctly. Adherence to the guidelines, therefore, is verified by the app store that hosts the app and as a safeguard, Google have defined that only system apps and apps that are installed via a trusted source (i.e.,Faurecia Aptoide’s App Store) can run while the car is moving.

So what does this mean for an app developer?

By working to these guidelines, skilled developers can tailor existing apps to work within the in-car environment or even better, create brand new ones that are designed specifically with the driving experience in mind. Apps can be designed with distraction optimised functionality whilst driving and a richer, more visual experience when the situation allows. For example, a media app that can play music videos and display extra metadata whilst parked, but whilst in driving mode shows no videos, switches to audio-only, has fewer and bigger icons and has less distracting functionality.

Alternatively, apps can be developed for specific statuses in mind, for instance, navigation apps or radio/podcast apps whilst in driving mode, apps to locate and pay for parking spaces whilst idling and games and full-video apps whilst in parked.

The 3 design principles that developers should keep in mind whilst designing an app for a restricted status are:

  • Interaction – The app should require minimal input from the driver. One-touch, voice control or gesture control should be considered where possible.
  • Visuals – should be informative, clear, short and not distracting.
  • Style layout – large icons, basic and intuitive menus and clear fonts.

To help with the guidelines, there are AAOS templates available that developers can use to create driving apps. To date the only one released is for media players, but messaging, charging and navigation templates are expected to be available very soon.

How can Faurecia Aptoide help developers create apps in AAOS?

If all that sounds a lot to take in, fear not. As the leading App Store for the AAOS platform, we have the expertise on hand to help app developers successfully launch their products onto the store. We’ve already delivered app store solutions for many of the world’s biggest car manufacturers like Volkswagen, Porsche and Volvo and are ready to help you.

By partnering with us, this is what you can expect:

  • We will support you in adapting your apps to the AAOS environment.
  • We will provide all the necessary technical documentation.
  • We will support you through the entire development process.
  • We will take care of the quality assurance process to get approved on the store.
    • We will test your app thoroughly in our environment and provide technical test reports.
    • We will guide you through any revisions that need to be made.
  • Once approved, we will work on a joint communication plan including PR and Social Media.
  • We will promote your app to car manufacturers
  • We can facilitate meetings between you and the car manufacturer to discuss marketing opportunities.

For more info or to arrange a call, get in contact with us

Other news you might like…

Incorporating Driver Distraction Guidelines into AAOS Apps

Faurecia Aptoide

Introduction

There is an inherent contradiction at play when app developers switch their attention to the automotive environment. Whereas phone apps are often designed to distract from everyday tasks and take the user into a different world for a few minutes, there are obvious reasons why in-car apps cannot do the same. Anything that distracts a driver from his primary task of driving the vehicle safely, is a clear no-no.

It is estimated that somewhere between 10% and 30% of all car accidents are caused by driver distraction, so authorities and car manufacturers alike are understandably nervous about adding any extra distractions to the driving experience. For this reason, very strict guidelines are in place to make sure that whilst on the move, any active apps are not encouraging drivers to take their eyes off the road.

Of course, there are large chunks of time spent in cars that aren’t moving. Once parked and stationary (or waiting for your electric vehicle to charge) there is no longer a reason why the driver needs 100% attention on the road. When this is the case, the restrictions on what an app can and can’t do can be relaxed and people can enjoy the full functionality of their infotainment systems. With sales of electric vehicles seeing huge growth and autonomous vehicles already starting to appear on the roads, more and more use cases are likely to appear.

How Does AAOS handle these different states?

To help mitigate this situation, Google have developed a comprehensive set of Driver Distraction Guidelines which can help app developers through the process and ensure that apps produced for Android Automotive OS are safe and suitable for in-car use. Developers can use these guidelines to adapt existing apps for in-car use or to develop brand new apps designed specifically for that environment.

The fundamental principles of the guidelines are that the car can be in 3 states (Parked, Idling and Driving) and that any app running in each of those 3 states needs to be appropriately ‘distraction optimised’

Parked (Vehicle gear is ‘Parked’) – no restrictions on functionality required
Idling (Vehicle gear is not ‘Parked’ but speed is zero) – no video and no configuration allowed
Driving (Vehicle gear is not parked and speed is not zero) – in addition to the above, no keyboard display, no text messaging, no dialling pad etc.

All Apps that run on AAOS need to be tagged as ‘Distraction Optimised’, otherwise they will not run in any of the restricted states. This means that any android mobile apps running on the vehicle will be blocked as soon as it starts moving. It’s important to note however that the system itself cannot detect an app’s actual adherence to the guidelines, only that it is tagged correctly. Adherence to the guidelines, therefore, is verified by the app store that hosts the app and as a safeguard, Google have defined that only system apps and apps that are installed via a trusted source (i.e.,Faurecia Aptoide’s App Store) can run while the car is moving.

So what does this mean for an app developer?

By working to these guidelines, skilled developers can tailor existing apps to work within the in-car environment or even better, create brand new ones that are designed specifically with the driving experience in mind. Apps can be designed with distraction optimised functionality whilst driving and a richer, more visual experience when the situation allows. For example, a media app that can play music videos and display extra metadata whilst parked, but whilst in driving mode shows no videos, switches to audio-only, has fewer and bigger icons and has less distracting functionality.

Alternatively, apps can be developed for specific statuses in mind, for instance, navigation apps or radio/podcast apps whilst in driving mode, apps to locate and pay for parking spaces whilst idling and games and full-video apps whilst in parked.

The 3 design principles that developers should keep in mind whilst designing an app for a restricted status are:

  • Interaction – The app should require minimal input from the driver. One-touch, voice control or gesture control should be considered where possible.
  • Visuals – should be informative, clear, short and not distracting.
  • Style layout – large icons, basic and intuitive menus and clear fonts.

To help with the guidelines, there are AAOS templates available that developers can use to create driving apps. To date the only one released is for media players, but messaging, charging and navigation templates are expected to be available very soon.

How can Faurecia Aptoide help developers create apps in AAOS?

If all that sounds a lot to take in, fear not. As the leading App Store for the AAOS platform, we have the expertise on hand to help app developers successfully launch their products onto the store. We’ve already delivered app store solutions for many of the world’s biggest car manufacturers like Volkswagen, Porsche and Volvo and are ready to help you.

By partnering with us, this is what you can expect:

  • We will support you in adapting your apps to the AAOS environment.
  • We will provide all the necessary technical documentation.
  • We will support you through the entire development process.
  • We will take care of the quality assurance process to get approved on the store.
    • We will test your app thoroughly in our environment and provide technical test reports.
    • We will guide you through any revisions that need to be made.
  • Once approved, we will work on a joint communication plan including PR and Social Media.
  • We will promote your app to car manufacturers
  • We can facilitate meetings between you and the car manufacturer to discuss marketing opportunities.

For more info or to arrange a call, get in contact with us

Other news you might like…