Page History

...

• presentation Bosch on fleet management use case for accessing Vehicle Properties.
• presentation BMW, Jan Kubovy on Car API, HAL, Android VHAL.
  
• planning first step for Data PoC (proposal: customer journey, first set of data) .→ can be prepared in First AOSP Data PoC

Meeting notes 2025-02-13

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

...