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

Agenda 2025-02-20 (tbc)

• presentation Bosch on fleet management use case for accessing Vehicle Properties.

Agenda 2025-02-13 (tbc)

• Participants:
• 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 → how to proceed.
    
    
• AMM revisited
  
  
• Planning: 
  • Use Cases 
  • Timelines
  • Teaming up with VSS / VISS / Capability teams revisited.

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://wiki.covesa.global/download/attachments/12124756/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