Once you’re registered on Appning’s Developers Portal and are ready to submit your app, your app will go through the following process:

• App Submission: you can submit your app and corresponding metadata through the
  Developers Portal; this is also where you’ll configure the regional distribution and will be
  able to see the status of your app.
• App Certification: once the app is submitted and all the mandatory information is filled,
  Appning team will perform the Certification of your app, including the following
  verifications:
  • Verifying that metadata submitted is correct and according to the guidelines;
  • Run an automatic scan of your app that will check its security (malware,
    vulnerabilities, etc.), permissions, accessibility, etc. Depending on the results of
    the automatic scan, a manual review of your app may need to be performed;
  • Running functional validation of your app on a reference, OEM agnostic, AAOS Hardware (also known as “Light test”).

If all the checks and validations are passed, your app is “certified” and becomes part of the Appning Catalogue, visible to all the OEMs.

• OEM Specific Validation: each OEM decides which apps they want to distribute. If they
  request your app to Appning, the app will enter an OEM specific validation phase.
  Appning has a lab with devices from the different OEMs where the OEM specific
  validation, a.k.a. “Deep Tests”, are performed. During this phase, in addition to the same
  type of app functional tests performed during the OEM agnostic certification, Appning
  team will also performed additional validation on OEMs head unit, including: integration
  with hardware and physical buttons, check proper functioning of connectivity, audio,
  voice assistant integration (if applicable), assess performance of the app, etc. Again, if all
  the checks and validations are passed, your app is ready to be distributed by the OEM.
• OEM Distribution: finally, the OEMs can distribute your app through their OEM Admin
  Portal.

Issues found by Appning during the Certification and OEM specific validation phases will be reported to you through the Developers Portal. The corresponding test reports are also made available on the portal.

Some points to take into account when preparing your app file(s) for submission:

• App File(s): Your app should be submitted in one of the following formats:
  • APK
  • OBB / Splits
• Architecture (ABI) support:
  • arm64-v8a (mandatory)
  • x86_64 (strongly recommended)
• Maximum size: 1 Gb. If your app is larger than 1Gb, please reach out to our team.
• App Version: each new version of a submitted app needs to have the versionCode, defined in the manifest file, incremented. The versionName is a string used as the version number displayed to end-users in your app’s listing. We strongly recommend you to also increment the versionName accordingly for each app submission. You can find more details on app versioning on Android’s official documentation.
• Signature: The app signing is not managed by Appning, which means you will have to sign your app. The app will be rejected on uploading if:
  • APK does NOT have any signature
  • APK is debuggable
  • APK has FLAG_TEST_ONLY
  • APK is signed with Android’s standard signature:
    • CN=Android Debug
    • or O=Android
  • Signature certificate does not match the certificates of previous version(s) of the same app.
• Please make sure to keep secure the keys used to sign your app and use the same keys in subsequent releases.
• Target SDK: We strongly recommend using targetSdk 34+ (Android 14+) for new apps submitted to make sure your app is compatible with as many OEM devices as possible.
• Minimum SDK: to maximize compatibility with OEM’s systems, you should target the following minSdkVersion: API Level 28 (Android 9).

After registering on the Developers Portal and taking the previously mentioned considerations into
account, you can submit your app files along with the corresponding app metadata required to
list your app in OEM stores. This includes details that help users discover more about your app.
To offer a localized experience, some assets are localized, allowing you to add translations for
your app’s metadata. Some requirements and recommendations regarding the app’s metadata
include:

App information

(*) Some metadata fields are requested only by some OEMs, but are mandatory for those OEMs. In order to maximize your app’s potential reach, we recommend providing these metadata fields.

The tags available on the Developers Portal allow you to select whether your app supports input methods such as gamepads, rotary controls, or remote controllers. In addition to manually input tags, other types of tags can be assigned to your app:

• Public Value Media (PVM): for apps that have been declared by local authorities as Public Value Media in their respective regions, a “PVM” tag, along with the respective country, is assigned to the app by Appning team. This can be relevant in countries like Germany due to Medienstaatsvertrag (MStV) that have specific requirements on apps listing and placement based on PVM categorization.

iNote: If you believe your app should be tagged as PVM but it is currently not, please reach out to
our team.

• App type: After static analysis, tags representing different app types can be assigned based on the analysis results, such as android-automotive, android-for-cars, media-template or tablet; these are automatically assigned to each of your app’s versions.

Age rating is used to set minimum age recommendation based an app’s content. The Developer
is responsible for selecting the appropriate rating:

More information on PEGI ratings can be found on the following link.

Once everything is ready, you can submit your app for Appning team to start the review and the app certification process. Since the automotive ecosystem is more stringent in terms of content validation than the mobile ecosystem, you should expect some issues to be found during your app certification and OEM validation. These will be communicated to you by e-mail and through the Developers Portal. Make sure to check the status of the issues and to respond accordingly so that your app gets approved faster.

Your app can have different statuses depending on the results of the validation flow. On the
Developers Portal, you can see the following statuses:

• Drafts: App has not been submitted yet;
• Pending approval: The app is currently under review. Security, functional, and metadata validations are being performed by the Appning team;
• Approved: The app was certified, passing all validations, and is now part of the Appning catalog. OEMs can now add your app to the store and configure its distribution. More information about this process is available here;

iAfter the app is approved, it becomes part of the Appning Catalog, visible to OEMs. As mentioned previously, it is up to the OEMs to decide which apps will go through the OEM specific validation and distribution.

• Rejected: The app was rejected due to incorrect information or issues found during the validation; you can check the reported issues or test reports on the Developers Portal.

Before jumping into the different app categories, there are some important aspects to consider:

• Check compatibility with Android for Cars: although Appning ecosystem only supports Automotive AOSP (embedded), you may want to develop your app both for Android Auto^TM (projected mode) and Android Automotive (embedded) and use different distribution channels to increase your reach. If that’s the case, please check Android for Cars documentation to understand which categories of apps are compatible with both projected mode and Android Automotive (embedded);
• Remove Google Play Services for Cars dependencies: as explained previously, Google Play Services for Cars are not available on Appning ecosystem, these are only available on OEMs that have Google Automotive Services (GAS); as such you need to make sure your app does not have any hard dependency from these services. Most common dependencies found are login/signing, billing and location. Appning provides replacements for some of these services, namely for the Billing SDK in case you want to monetize your app (please check Monetising your app for details). More services will be added soon, such as Push Notifications. Feel free to reach out to our team in case you’re missing some important feature or dependency.

In this context, your audio app, will need to provide:

• Media Browser Service: to expose your app content to be browsed and searched for; this is the entry point for the Media Center to control your app’s content;
• Media Session: implement media session interface to represent the playback state and provide playback controls;
• Player: integrate the audio player, usually through ExoPlayer.

By adhering to this framework, the onboarding of your app in the OEM ecosystem is simple:

• You’re app can be used while driving through the OEM Distraction Optimised Media Player;
• The OEM can easily configure the car physical buttons, including steering wheel controls, to send commands – such as Play, Pause, Next, Previous – to your app through the Media Session interface;
• Voice assistants can also interact with your app to search for content or control playback.

iIf you have an audio app that is not following the media browser service framework, you should check the “Distraction Optimised Apps” section.
If your app’s content is primarily video, you should check the “Parked & Passenger Apps” section, particularly the Video Apps.

The following references will be useful building your app:

• Droidcon Berlin 2023, “Faurecia & TIDAL: Building Apps for Android Automotive”: particularly the second part of the talk, describing how to build a media app for Automotive;
• Build media apps for cars: provides an overview on how to build media apps for projected modes and native experience; Android Automotive embedded specificities are covered under Add Android Automotive OS support to your media app;
• Media app architecture overview;
• Jetpack Media3.

!Not all the OEMs that work with Appning support the CAL Templated Apps. If you plan to build a CAL templated app, please reach out to Appning team to know which OEMs currently support it.

CAL Library

The CAL library can be found on the official android documentation.

Automotive Host

The Automotive Host is a system app, provided by Appning or by the OEM, that runs on AAOS and that is responsible for rendering parts of your app and managing its lifecycle. E.g. the map rendering is provided by the Host. If the IVI system has no automotive host app, your templated app cannot be executed.

OEMs may customize the Host, particularly for plugin-in their own maps provider, to ensure consistent maps rendering look and feel cross different apps in the same IVI system.

API Level

When you’re building your app using CAL, there are some concepts that you should take into account regarding API and compatibility between App and Host:

• App Car Api level: your app will be able to support a range of API levels
  • minCarApiLevel: similar to the minSdkVersion for mobile apps, the minCarApiLevel defines minimum Car App API Level supported by your app. Check Car App API level for information on how to define it and use it;
  • max Car Api Level: CAL defines its own API levels, which means your app can support, at most, the API level provided by the version of CAL that you imported. E.g. if you import “androidx.car.app:app:1.4.0” you’ll get the API level supported by version 1.4.0 of android for cars library (API Level 7).
• Host API Level:
  • Maximum API level supported by the host, which is also derived from the CAL version the host includes. Appning Automotive Host is currently at API Level 4.
• API level negotiated between App and Host:
  • getCarAppApiLevel: “API levels are used during client and host connection handshake to negotiate a common set of elements that both processes can understand. Different devices might have different host versions. Each of these hosts will support a range of API levels, as a way to provide backwards compatibility. Clients must ensure no elements annotated with a RequiresCarApi value higher than returned by this method is used at runtime”.

iAppning provided Automotive Host is currently at API Level 4. CAL car-app#1.7.0-beta01 already introduces CarAppApiLevel 8. Therefore, we recommend you to use features from CAL that are up to API Level 4 and use the RequiresCarApi to check if specific features can be used or not.
It is also strongly recommended that you test your app using Appning’s emulator, to make sure you are testing using our Automotive Host. Please refer to the section Validating your app for details.

iAppning is actively involved, in the scope of COVESA Automotive AOSP App Framework Standardization, with automotive industry players to reduce fragmentation in the Automotive AOSP Ecosystem. One of the activities being worked is the development of a COVESA Automotive Host that will allow to bridge the current gap to CAL, supporting API Level 8.

In addition to the considerations on API level and App ↔︎ Host compatibility, the following references will be useful to help you build your app:

• Use the Android for Cars App Library
• Build a point of interest app
• Build a navigation app
• Build a weather app
• Build an internet of things app
• Design for Driving Templates

Distraction Optimised (DO) Apps built without using the existing templates can be an option for your app for different scenarios:

• the type of user interface you’re aiming is not supported by existing CAL templates and
  you prefer to have some extra work to build the UI yourself taking into consideration
  driver distraction;
• the OEMs that you want to target don’t support the CAL Template.

When designing a DO App, you need to take into considerations the Design for Driving
foundations particularly the Visual and Interaction principles, in order to minimize the driver
distraction.

Please refer to Distraction Optimized apps for more details.

iThe OEM system can’t tell if your app is actually DO or not. Driver distraction guidelines will
be checked by Appning team during your app certification process. Expect further interaction
with our team to certify your DO app.

The parked and passenger apps are not optimized for driving and can only be used:

• on driver display while the car is parked;
• on secondary displays (passenger, rear seat) at any moment.

The OEM is responsible for configuring the “driver distraction” settings of each display.

In this category of apps are included games, video apps or browsers.

Some important aspects to take into consideration when building your parked & passenger app are discussed below.

• You’ve followed the Building your app guidelines particularly for the category of app you’re submitting
• You’ve verified the Android Car app quality checklist
• You’ve tested your app using Appning’s emulator, particularly using the provided tools to test audio apps (if applicable to you) and testing with different displays configurations
• (If this is not the first version submitted) You’ve checked, fixed and updated the status of the previously reported issues.

After submitting your app, it will follow the Appning Certification and Distribution Flow.

Issues found by Appning and OEMs during your app certification and operations – bugs, security issues, improvement suggestions – will be reported to you through the Developers Portal and by email.

Before submitting a new version of your app, you should check the existing issues and confirm which ones have been fixed, so that Appning validation team can confirm the fixes on the next version validation cycle.

5. Click OK and then click Apply on the SDK Update Sites view.

Once this setup is concluded, Appning’s images will be listed under SDK Platforms as per
usual.

To download the images, follow these steps:

1. In Android Studio’s settings, go to Languages & Frameworks > Android SDK
2. Click the SDK Platforms tab.
3. Navigate to the Android 12L section.
4. Select the appropriate architecture for your machine and click Apply.
   • Appning’s image supports both x86 & arm based architectures.

Once the installation is concluded, you will be able to select Appning’s images when creating an Automotive emulator.

This enables testing your media session app, whether it’s built using the legacy MediaSessionCompat or the newer Media3 MediaSession — when it’s accessed by an external app through a legacy MediaControllerCompat.

For additional information: Using the media controller test app.

iAdditional devices will be added in the future.

Test system bar position

The Hardware Device Configuration application allows developers to modify the system bar position in order to emulate particularities of certain cars.

These changes can be applied within Hardware Device Configuration’s settings screen or through the following RROs:

• com.android.systemui.rro.bottom
• com.android.systemui.rro.left
• com.android.systemui.rro.right

iComing soon! If you’re interested in testing your app on an AAOS tablet, please get in touch with the Appning team.

https://firebase.google.com/docs/android/android-play-services

Handle scenarios where no Activity is able to run the given intent

As stated in the documentation (https://developer.android.com/reference/android/content/Context#startActivity(android.content.I ntent,%20android.os.Bundle))

“This method throws

if there was no Activity found to run the given Intent.”

This means that it is a good practice to handle this corner cases, as there may be some systems
where the requested intent is indeed not available.

In cases where the action is not executed due to the lack of support (i.e., no activity in the system
that is able to handle the given intent), there should be some visual feedback that gives some
information to the user reasoning to why the action couldn’t be executed.

Back affordance

Navigation bars may or may not include a back affordance on Android Automotive OS, and gesture navigation isn’t supported. Car app quality guideline AN-1 requires that your app be navigable by users without a system or hardware back affordance.

Users should be able to navigate through the app without encountering any dead ends.

More info at Back Navigation.

Insecure WebViews

Having access to external, non-controllable, entry-points can lead to several system-wide vulnerabilities.

Third-party applications should not allow the user to be redirected to external sources. If the application is overly permissive with redirects, it could create potential vulnerabilities and opportunities for exploits.

Some additional information on how to secure WebViews: Secure your WebView.

Media

Handling duration when playing infinite content

When developing media applications, if your app plays infinite content, please follow the Android official guidelines regarding METADATA_KEY_DURATION and use negative duration.

iNote: If your apps use 0 duration instead of negative, the integration with some OEM Media Center Apps may fail and bugs will be reported when performing the OEM specific validation.