The app store is branded by the Original Equipment Manufacturers (OEMs) (e.g. “VW Play Apps” for our app store solution for Volkswagen) and pre-embedded into the car at the factory.

The app store can be deployed both in In-Vehicle Infotainment (IVI) systems and Rear Seat Entertainment (RSE) systems.

Prior to being deployed into the car, Faurecia Aptoide tests all applications, including updates, making sure they are compatible, functional, and safe in the automotive device. All tests performed on an app can be shared with the developers, to fast-track the adaptation to the automotive environment, and can also be shared with OEMs, to help the selection process. More about Faurecia Aptoide processes in chapter 4.

Due to the large application ecosystem already available, Android OS is gaining momentum with OEMs, being adopted by many car manufacturers. Android OS adoption in cars is expected to grow 10x over the next years, reaching 40% of the cars worldwide by 2025.

Majority of the OEMs have adopted Android Open Source Project (AOSP), as such this is the environment in which our app store will be deployed and in which applications will run.

For IVI specifically, OEMs are adopting Android Automotive OS (AAOS) which extends Android with some specific features for the automotive industry. AAOS is within the same codebase and repository as the Android shipped on phones, tablets, etc. – and not a fork or parallel development of Android. You can read more information about it here.

From our experience, most of the applications – designed for mobile, tablet and automotive – also run on our environment without modification. The next chapter highlights the conditions in which applications may find potential issues.

Our App Store distributes apps for automotive environments based on the Android Open-Source Project (AOSP). AOSP solutions don’t come with the licensed Google Mobile Services (GMS), so it is required that your app does not have any hard dependency from GMS.

A hard dependency is one that compromises the application functionality and usability, for example, an application that requires Google Billing for the user to be able to pay in the app.

You might have soft dependencies that won’t affect the app performance for the users (e.g., internal analytics). For Faurecia Aptoide, those apps are functional and as such will be allowed to be distributed in the car.

Some of the most common dependencies are associated with login/signing, billing, and location, resulting in app crashes, sign in button not working, warning messages informing lack of GMS, app crashes when playing.

Automotive displays vary in aspect ratio and orientation not only among OEMs, but also across different car models within the same OEM. Therefore, it is essential to consider the following if your app does not rely on existing automotive templates, or if it uses a template but includes custom screens such as Settings or Sign-in:

• Ensure that your app supports both Portrait and Landscape mode to provide a consistent user experience across devices and orientations.

• Make sure that your app scales correctly to different screen sizes and densities, to prevent visual distortions and ensure readability.

• Thoroughly test your app against different hardware profiles provided in “Testing the apps in an automotive environment” or a representative subset of the provided profiles.

By adhering to these guidelines, you can ensure that your app is fully functional, compatible, and optimized for different automotive displays, providing drivers and passengers with a seamless and satisfying experience.

There are apps, such as Music Streaming and Video on Demand apps, that require an additional encryption layer to play on a device. Digital rights management allows apps to secure their digital content preventing unauthorized use and piracy.

In all devices in which it will be pre-loaded our app store solution, hardware will be compliant with music rights. For video, it will be a case by case.

App publishers might want to distribute their apps in specific countries, be it because they have legal constraints, or the app is not designed for those regions. On the developer portal, developers can define countries availability. By default, all countries are selected.

For IVI app distribution, driver distraction is the main concern of both app publishers and OEMs. Some of the apps might have content that can distract the driver. We consider distracting apps those that by its nature (e.g., video apps), or because they have a distracting feature (e.g., popups/video ads), might affect driver behavior and passenger safety. More guidelines on distracting content here.

On IVI systems, any application that is not correctly optimized will be blocked while the car is in movement. On the other hand, RSE systems can run any type of content whether the car is moving or not. If one or more of an application use cases are a good fit for the IVI system, it is recommended to adapt it to respect both the Driver Distraction Checklist and UI/UX Guidelines

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:

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).

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.

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.

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.

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.

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 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.

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.

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.

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.

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

The validation process has several steps.

First, a compatibility test is performed on Faurecia Aptoide standard automotive platform aiming to identify potential compatibility and functional issues on the app associated with our automotive environment. These tests focus on main functionalities, which may vary depending on the type of app under test, such as opening the app, login and account creation, purchases, video and/or audio streaming, controller compatibility, etc. All the info gathered during the initial compatibility tests, including screenshots and logs, will be shared with the app developers.

Once the app is deemed ready to be distributed with the partners it is uploaded to our platform. Each version uploaded will be the subject of a series of manual and automated tests to ensure that our initial assessment is still valid and that it doesn’t contain any type of malware by running it on our antivirus platform.

At this point, the app is ready to be shared with the OEMs but before it is made available on the platforms it will be put through a final batch of tests on the OEM device. Besides running the same tests that were run on the standard platform, specific tests might apply depending on the app. Gaming apps might need low latency and external hardware compatibility tests to be executed to guarantee a good user experience, VoD apps can be subjected to a series of network performance tests while driving the car to ensure that a smooth streaming capability is achieved. Also, for IVI implementations, applications are tested to ensure that they follow the Driver Distraction Guidelines.

After the app passes all the testing stages and is made available on one of the OEMs platforms it will continue to be monitored at each new version uploaded, any issue that might arise will be shared with the app developers to help guarantee a fast and smooth solution. Our commitment is to ensure both OEMs and Developers satisfaction.

Besides Faurecia Aptoide validation procedures, app developers might want to replicate Faurecia Aptoide compatibility tests. Unfortunately given the lack of devices available, it might be difficult to replicate.

Even though this is not a perfect testing scenario, an emulator can help replicate most of the issues identified on Faurecia Aptoide reports.

Android Studio installed (https://developer.android.com/studio/install)

• SDK 29
• SDK 30
• Snapp Automotive

ADB installed on your macOS/Windows/Linux

1. Open your SDK Manager

2. Navigate to “SDK Update Sites“ separator located on the top right.

To integrate Snapp Automotive into Android Studio:

1. Click add button located on bottom left (+)
2. Fill information in the form:
   1. Name: Snapp Automotive
   2. URL: https://downloads.snappautomotive.com/emulator/snapp-automotive-sys-img2-1.xml
3. Click “Ok”
4. Restart Android Studio

Android Studio SDK Platform configuration:

1. Open SDK Manager
2. To install original Android AOSP emulator images and Snapp Automotive images perform follow steps:
   1. Activate “Show package Details“
   2. Activate “Snapp Automotive Intel x86 Atom System“ for Android 11.0 (R)
   3. Activate “Intel x86 Atom_64 System Image“ for Android 11.0 (R)
   4. Click “Ok”
   5. Restart Android Studio (after download and installation finish)

Note: (For Android 10.0 (Q) version, activate “Intel x86 Atom_64 System Image“ on Android 10 item)

Android Virtual Device creation

1. Open SDK Manager
2. Click on “+ Create Virtual Device…”

3. Click on “Import Hardware Profiles“ and import all the necessary profiles.

After importing all necessary hardware profiles, you can create emulator from list of available profiles.
It is possible to search for the names that were set for each hardware profile.

Then,

1. Select hardware profile needed
2. Select Operating System associated to that specific hardware profile consulting table above
3. Finish hardware profile setup

1. Start the emulator.
2. Once the emulator is running and the system has booted, the app can be installed with drag-n-drop.

If the app is installed successfully, you can scroll up to open the app drawer and you’ll find the app there available for testing.

If the app hasn’t been installed, an error message will be displayed. The most probable cause for unsuccessful installation is the lack of support for x86 or incompatible screen density. It’s possible to get a more detailed failure message by using adbs’ install command (https://developer.android.com/studio/command-line/adb).