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

30rd January 2025 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).
    

23rd January 2025 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.

23rd January 2025 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