Contents:

AOSP home page:

Automotive AOSP App Framework Standardization Expert Group

please see also (sub-pages):

General Information

Welcome to the COVESA Automotive AOSP Data Workstream Meeting!

Weekly Meeting: Thursday, 3:00-4:00 pm CEST, zoom link: https://us06web.zoom.us/j/86051210072?pwd=fe2BinfbRCCx9zac7nbbDuXZCqzvbp.1

Slack: https://covesacommunity.slack.com/archives/C05EB6A6J5R

GitHub: https://github.com/COVESA/aosp-app-framework-standardizatiion

Leads:

Compliance statement:

Antitrust
Before we begin, we would like to make clear that COVESA is committed to compliance with the antitrust laws in all of its activities, and that it expects all participants to similarly comply with the antitrust laws.  We will not engage in--and members must refrain from--any discussion of, or understandings regarding competitively sensitive topics. If you have any doubts regarding whether a matter is appropriate for discussion, please consult with your antitrust counsel.

Open and Royalty-Free
Further, COVESA aspires to be an open and royalty-free organization. The discussions and contributions made during this session are governed by the COVESA Intellectual Property policy. If you are unfamiliar with that policy, please review it in detail prior to making any contribution that reads upon a patent.

Meeting Notes 2025

2025-07-24 AOSP Vehicle Data next steps meeting

Participants: COVESA, BMW, GM, Forvia, ParadoxCat, Allianz

• Aim: looking for an open - source solution, for VSS/VHAL mapping as well as permission model.

• recap of
  https://covesa.atlassian.net/wiki/download/attachments/39067416/Spring-AMM-2025_Day1_12-05_Kubovy-CarAPI-HAL-AndroidVHAL-COVESA.pdf?version=1&modificationDate=1753371575640&api=v2

• requirements Android automotive, example:

  • https://source.android.com/docs/compatibility/13/android-13-cdd#25_automotive_requirements

  • https://source.android.com/docs/compatibility/16/android-16-cdd#25_automotive_requirements

    
   

• next steps:

  • proposal to be presented to COVESA Technical Steering Team on Monday, 28

  • potentially presentation to the COVESA Board, depending on outcome TST.

  • summary in monday meeting July, 28.

2025-07-17 AOSP Vehicle Data next steps meeting

Participants: COVESA, BMW, GM, Forvia, ParadoxCat, Chris Simmonds, Antonio

from Monday vehicle data next steps discussion:

• Aim: looking for an open - source solution, e.g. VSS/VHAL mapping
  
  

• motivation:

  • as of today, only speed and a few others are available → devs cannot ideate on anything.

  • find the use cases on which to open up for devs, see first lists in First AOSP Data PoC

  • idea: This would be a great opportunity to make vss available to apps directly, then we can define our own permissions.

  • idea: this group to do a joint specification on the data side which goes through list of properties, their specifics. then develop alongside this. 
    
    

• Requirements: Android Vehicle Data Requirements
  
  

• Summary so far: COVESA AOSP VHAL: Use Cases
  
  

• Work in progress:

  • VSS / VHAL mapper (Jan): https://github.com/COVESA/vss-tools/pull/441

  • Kotlin wrapper (Viktor, ParadoxCat): https://github.com/Paradox-Cat-GmbH/KarPropertyManager

  • Permission model implementation.
    
    

• Next steps:

  • tbd

2025-06 ff for the moment no next meeting planned. Slots in AOSP Monday meetings. 

2025-06-12 AOSP Vehicle Data  

• Participants: appning, COVESA, BMW → just the chairs, next meetings cancelled, topic back to Monday meeting.

• Planning the next steps.

2025-06-05 AOSP Vehicle Data

• Participants: 

• Potentially Meeting of a Core Team to start working on the solution proposals for the permissions.
  low participation. next steps see AOSP Monday Minutes 2025-06-16

2025-05-29 Cancelled (Public Holiday)

2025-05-22 AOSP Vehicle Data Meeting Notes

• Participants: BMW, GM, Appning by FORVIA, Volvo Group (trucks, fleet), Elektrobit

• Synch on AMM Berlin meeting.

• Next steps: define a core team which starts working on the solution proposals for the permissions.

2025-05-15 Cancelled (AMM week).

COVESA All Member Meeting ~ May 14-15, 2025

2025-05-08 AOSP Vehicle Data Meeting notes

• Participants: BMW, GM, Spotify

• Work in Progress: Draft presentation AOSP Data for AMM Berlin

• offline: Jan Kubovy, BMW and Moritz Neukirchner, Elektrobit prepare presentation for AMM.

2025-05-01 Cancelled (Public holiday in Germany)

2025-04-24 AOSP Vehicle Data Meeting notes

• Participants: BMW, GM, Appning by FORVIA, Elektrobit, CARIAD SE, Allianz
  
  

• Who will be there and present at AOSP Data presentation slot at AMM Wednesday? https://www.eventleaf.com/e/ammberlin
  → Summary of our thoughts, of what we are addressing, requirements, of first solution ideas.
  → Sabine sends mail to all people involved to get (summary) slides on storyline and compiles the slides:

  • open issues, requirements on getting vehicle data - problem statement (1 slide).

  • concept1 (1-2 slides)

  • concept2 (1-2 slides)

  • concept3 (1-2 slides)

• Next Steps:

  • different concepts presented so far: AOSP Data: Use Cases and potential Concepts - compare PoCs & ideas - pros/cons

  • Android Vehicle Data Requirements → mapping them to the Concepts.

  • Overview vehicle properties that are already available today, plan for future. → ask ParadoxCat next week and move forward from there.

• for information: Dev Workshop AMM is a pure Dev Workshop + breakout meetings on AOSP in the afternoon:
  AMM 20250525 Automotive AOSP App Framework Expert Group Workshop Agenda
  
  

• set next meeting date → May, 08 to finalize the presentation.

• next AOSP Monday meeting, please feel invited to attend: Agenda proposal 2025-04-28

2025-04-17 Cancelled

2025-04-03 Meeting notes

• Participants: BMW, GM, Volvo, Forvia, Bosch, Allianz, Geotab

• short AMM workshop agenda review: AMM 20250525 Automotive AOSP App Framework Expert Group Workshop Agenda.
  https://forms.gle/EMLX4AtnEB27ffZ2A. 

• short Follow-up Android Vehicle Data Requirements

2025-03-27 Meeting notes

• Participants: COVESA, Cariad, Geotab, Tietoevry, Volvo, Appning by Forvia, Bosch, Paradox Cat, BMW

• AMM news from Paul:
  The registration form is up for the AOSP workshop in Berlin (on Thursday).  Please register.  Please let me know if you see problems, have questions, suggestions, etc…  https://forms.gle/EMLX4AtnEB27ffZ2A. FYI - Registration for the Workshop is separate from registration for the AMM.

• Follow-up Android Vehicle Data Requirements – to be continued next week.

2025-03-20 Meeting notes

• Participants: COVESA, Volvo, BMW, Appning by Forvia, Tietoevry, Geotab, Elektrobit.

• Jan Kubovy, see also presentation from 2025-02-20 Meeting notes: BMW: Mapper contribution to Github.
  Discussion on access control requirements in this approach vs. approach Volvo last week (OEM controlled, user controlled).
  Android 15 will see changes.

• Follow-up Android Vehicle Data Requirements - went through the table, please feel invited to contribute to this table
  which will be the basis to compare different solution ideas/proposals.

• Quicksort AMM status → please register for participation for Thursday concept workshops and developer session, agenda will be sent out shortly.

2025-03-13 Meeting notes

• Participants: COVESA, VOLVO, GM, FORVIA, FORD, Renesas, Tietoevry, Elektrobit, Geotab, Allianz, BMW

• Concept Presentation from Volvo:
  and Discussion:

  • Protection level topics still have to be solved.

  • Idea for permission groups

  • Configuration management in the backend would be needed, also to be able
    to cope with changes (car ownership, change of insurance contract etc.).

  • Availability of a PoC also depends on effects Android 15 might have.

• Follow-up AMM sessions → as for Thursday, we are planning for Workshops, everybody is invited
  to get back to us with inputs and who will be participating, Paul will be setting up a page for pre-registration.

  • deprecated - draft COVESA AOSP AMM Berlin 2025 - Prep Co-Chairs

  • https://www.eventleaf.com/e/ammberlin

• Please have a look at and add your thoughts to Android Vehicle Data Requirements

• fyi: announced in AOSP Monday meeting: hands-on session in Munich on Friday, March 14, details see Meeting notes 2025-03-10

• fyi: pdf from presentation Elektrobit, see 2025-02-27 Meeting notes

2025-03-06 Meeting notes

• Participants: COVESA, GM, VOLVO, CARIAD SE, Appning by FORVIA, Tietoevry, Paradox Cat, Elektrobit, Geotab, BMW

• Volvo - intro to presentation next week, first discussion:

  • it is a POC, based on system app.

  • SDK is custom, Java-SDK, Android security model will be obeyed.

  • emulator availability? → summary on emulator activities. discussion on emulator flavours.

• AOSP Data Ideas for talks & workshop on AMM, for discussion:
  deprecated - draft COVESA AOSP AMM Berlin 2025 - Prep Co-Chairs

• Table to compare concepts: Android Vehicle Data Requirements

2025-02-27 Meeting notes

• Participants: COVESA, FORVIA, Appning by FORVIA, GM, Elektrobit, CARIAD SE, BMW, Tietoevry, Geotab, Paradox Cat, Allianz, Valtech Mobility

• Presentation Elektrobit: 

• Discussion on how to proceed together - Paul setting up github repo for vhal.

2025-02-20 Meeting notes

• Participants: COVESA, Bosch, FORVIA, Appning by FORVIA, GM, Volvo, CARIAD SE, BMW, Allianz, Valtech Mobility, Tietoevry, Geotab, Elektrobit, Paradox Cat
  
  

• Presentation BMW, Jan Kubovy on Car API, HAL, Android VHAL.
  

  • Discussion/Q&A:

  • Permissions as in the manifest can be granted at install time (so e.g. a user could agree before driving),
    and at run time (by OEM).

  • Each OEM can have his own config. config list can be fetched at runtime.

  • For test purposes in a PoC, assumption could be that the app store is trusted. Later we will need infrastructure for that.

  • question: is config file same as privapp allowlist that whitelist packages that can access privileged properties ?

  • the mapper is planned as contribution to COVESA.

• Presentation Bosch, Andreas Klein, on fleet management use case for accessing Vehicle Properties.
  

• Space for planning first step → can be prepared in First AOSP Data PoC

2025-02-13 Meeting notes

• Participants: COVESA, FORVIA, Appning by FORVIA, GM, Volvo, BMW, Bosch, Elektrobit, Valtech Mobility, Tietoevry, Geotab, Paradox Cat

• one step back before discussing the details: our approach (Sabine, BMW):

  • What is the approach of the COVESA AOSP Data Workstream:

    • to technically enable 3rd party app developers within the COVESA Automotive Android app ecosystem, see https://covesa.global/aosp-framework/,
      to access vehicle properties, i.e. "data".

    • see also Automotive AOSP App Framework Standardization Expert Group#Charter:

      Vehicle Data collection

      Vehicle data collection using vehicle properties and making them available to the Android OS. Proposal: Create COVESA Vehicle Signals to AOSP translator.

  • AOSP offers standard vehicle properties as well as vendor vehicle properties, accessible for system apps with permissions.

  • What we need:

    • future 3rd party in-vehicle apps, i.e. use cases that need properties

    • solution to the permission challenge.

    • bridge the gap between VSS to Android properties as needed.
      
      

• update on presentations / potential PoCs:

  • BMW presentation availability as talked about on 2025-01-30

  • Volvo presentation availability as talked about on 2025-02-06

  • tbd: Valtech Mobility information.

  • definition of first PoC based on excel from Allianz → BMW to start with first set of properties.

• Discussion:

  • Permission topic approach:

    • learn how different PoCs / OEMs deal with it today → find a standardized way, do a workshop for a deep dive to work on it.

    • COVESA SDK for ambient lights .... one example also depending on permissions.

    • AOSP links:

      • https://developer.android.com/guide/topics/permissions/defining#grant-signature-permissions

      • https://developer.android.com/guide/topics/manifest/permission-element#plevel

    • Granularity as of today not good enough, maybe special categories of permissions needed for different use cases.

    • Each app obviously can only be signed with one certificate.

    • First: read access only.

    • https://developer.android.com/guide/topics/permissions/defining#grant-signature-permissions  granularity.

      https://developer.android.com/guide/topics/manifest/permission-element#plevel

    • System service has to keep the list of certificates. Client app will have a SDK level jar file to use the APIs.

    • OEMs could look in the store and app could access the permission level then.

    • idea: 

      https://source.android.com/docs/core/ota/modular-system 

  • Simulation on the emulator: pre-recorded dataa for simulation, see Volvo presentation at AMM one yer back.

2025-02-06 Meeting Notes

• Participants: Paradox Cat, Bosch, BMW, FORVIA, Appning by FORVIA, Tietoevry, Volvo, General Motors, Elektrobit, Allianz

• Recap on meeting last week.
  
  

• Which Properties will be needed:

  • list of use cases with properties needed from Allianz and MOTER. see link from COVESA Commercial Vehicle Group

    • links shared for VSS data:

      https://docs.google.com/spreadsheets/d/1FMtSLhJy1REgadlnSwAqPX7r57rqdLYyw4W7ZsWyg8E/edit?gid=2020824572#gid=2020824572

      Fleet Management Data [PUBLIC]

      https://docs.google.com/spreadsheets/d/1Np9uLvwEESZ09dMcXoSvoyoyj5L_Le0k/edit?gid=1250108163#gid=1250108163
      MOTER VSS Data additions v2 - Shared publically
      
      

    • https://covesa.atlassian.net/wiki/download/attachments/39299399/AOSP-VSS-Mapping-v1.7.xlsx?version=1&modificationDate=1676939208750&api=v2
      
      

    • → lists from Allianz to be checked, updated. Ted would know. →  to be followed up in Slack channel and sub-page to this page.
      
      

  • further use cases → FORVIA App Challenge shows

    • there are properties but permission not there.

    • needs the platform signature.

    • not possible for 3rd parties at the moment.

    • First step see demos below.

    • e.g. odometer: https://source.android.com/docs/automotive/vhal/system-properties#perf_odometer

• VolvoCars are investigating usage of Protectionlevel respecting Android security

  • https://developer.android.com/guide/topics/manifest/permission-element#plevel

  • "knownSigner" A permission that the system grants only if the requesting application is signed with an allowed certificate.
    If the requester's certificate is listed, the system automatically grants the permission without notifying the user or asking for the user's explicit approval.

  • → short presentation to follow in one of next meetings.

• Discussion on how to proceed and what has to be addressed:

  • Granularity of permissions,

    • e.g. there are different permission kinds → assessment  for different  properties to be done, e.g.:

      • https://developer.android.com/reference/android/car/VehiclePropertyIds#ENGINE_RPM

        https://developer.android.com/reference/android/car/VehiclePropertyIds#DOOR_POS

    • frequency/sampling.... also a matter of system load.

    • accuracy might be interesting for app level as well. 

  • idea: first PoC with subset of viable properties, like from Allianz, to be defined and shown to the group, e.g. at AMM.

  • does PoC really help? Key is to solve the permission issue. Concept proposal for permission is missing.

    https://source.android.com/docs/core/permissions/android-roles

  • Privacy is also an issue

  • 2nd problem is that there are properties missing.
    
    

• Who could contribute: 

  • Stefan from Allianz offers to reach out to Valtech Mobility.

  • At AMM, if we show a PoC, further companies might get on board.

2025-01-30 Meeting Notes

• Participants: COVESA, Paradox Cat, BMW, FORVIA, Appning by FORVIA, Tietoevry, Volvo, General Motors, Elektrobit, Allianz, Renesas, Geotab

• Summary on AOSP VHAL Properties (Vehicle Hardware Abstraction Layer giving access to car data),
  mapped from VSS data (https://covesa.global/project/vehicle-signal-specification/):

  • the aim is to get car data, implemented as vehicle properties in Android, to the headunit.

  • Standard Vehicle/System Properties for Android Open Source Project (AOSP) are defined in https://developer.android.com/reference/android/car/VehiclePropertyIds (65K Ids possible).

  • Android Automotive also offers the definition of custom "vendor" properties (65K Ids possible) which are restricted to system apps: https://source.android.com/docs/automotive/vhal/previous/properties#handling-custom-properties

  • Third party Android apps installed from a 3rd party app store have access only to system properties. 

  • Third party apps must be aware of the capabilities of the respective VHAL they are accessing.

  • Data specified in VSS can be mapped to VHAL system properties, as long as the respective property already exists.
    
    

• The question is, how to bridge the gap between additional VSS-data and already existing VHAL properties for third party apps - there are 3 ways which can be evaluated and applied for to avoid further fragmentation:

  1. extension of the system properties.

  2. extension of AOSP to handle vendor properties in the same way as standard properties.

  3. new VHAL property group, e.g. "VSS", with same use of standard system properties.
     
     

• Handling of permissions: app defines in manifest what it needs.
  Depending on permission the permission is given at install time or during run-time of the app, also in various degrees up to handling explicit user permissions where needed. It has to be evaluated, if the granularity, security and the flexibility of permissions as of today will be enough to handle future 3rd party use cases.
  
  

• A possible solution has to be evaluated regarding backwards compatibility to older Android versions.
  
  

• Authentication has to be evaluated thoroughly, e.g. can tokens as used in VISS (https://covesa.global/project/vehicle-information-service-specification/) be applied.
  
  

• For further information and evaluation, take a look at the demos given already in past COVESA All Member meetings, e.g.
  VISS POC in https://wiki.covesa.global/display/WIK4/COVESA+All+Member+Meeting+~+April+16-18%2C+2024.
  Implementation example as well in https://mobex.io/webinars/reaching-software-defined-vehicle-level-5-with-eb-corbos-link.
  
  

• First step to set up a first project / Proof of concept, check on data needed for some first use cases with the aim to offer a reference implementation in the COVESA AOSP SDK (BMW Co-Chair to start this).
    

2025-01-23 Kickoff Minutes

• Participants: COVESA, Tietoevry, Allianz, Ford, FORVIA, Appning by FORVIA, WirelessCar, General Motors, Elektrobit, Renesas, Geotab, Paradox Cat, BMW

• Presentation Stefan, Tietoevry 
  on previous challenges and achievements, including youtube - Links:

  •  

  • External Data Server Framework

  • Mapping VSS to Android Properties

  • Possible Work Packages

• Questions / Tasks:

  • which data points are available in which granularity & frequency?

  • which data points on ADAS side are already available in VSS?

  • identify the gap between VHAL and VSS → which data from this gap would be needed (first, and then later)
    → add them to Google Properties or define as COVESA-OEM-vendor properties?

  • authentication details

  • permissions challenge:

    • fleet management signature from OEMs would have to be solved.

    • how to give permissions to an app in runtime?

  • link to capabilities group → how to deal with e.g. different set of seat properties from basic set to advanced sets depending on car capabilities.

• Next steps:

  • set up a weekly + establish a lead

  • define a problem statement

  • set up a project proposal/one pager (what we plan on doing and how we plan on doing it.  Does not need to be heavyweight)

  • find the right focus to start with

  • deal with the questions/tasks above

  • next meeting: presentation from BMW, VSS group, depending on availability.

2025-01-23 Kickoff Agenda

Kickoff the AOSP Data Workstream with a overview/review of what has been done in the past in COVESA.  

Goals:

• Recruit and engage those that want to participate, collaborate, and contribute

• Review meaningful past efforts around AOSP and data especially as related to VSS.  

• Identify focus and propose work product/scope moving forward.

• Identify leads

• Start charter

Agenda:

• Overview

• Presentation of what meaningfully was done in the Android SIG in the past.

• Identify/Confirm Leads

• Next Steps