Page History

...

• 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, called 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 have to 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
  offer
  1. handle vendor properties in the same
  permissions for standard vehicle and custom vendor
  1. way as standard properties.
  2. new
  category in property metadata named
  1. VHAL property group, e.g. "VSS", with
  re-
  1. same use of standard system properties
  space
  1. .
     
     
• Handling of permissions can be done in the manifest (once) : 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).
    

...