Contents:

AOSP home page:

Automotive AOSP App Framework Standardization Expert Group

please see also (sub-pages):

General Information

...

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-

...

24 (

...

tbc)

• Participants:
• Topics learnings from last week on infrastructure (Paul, Viktor) 
• gather feedback from participants on white paper, see Meeting notes 2025-02-17
  and decide on where to give feedback (google docs, co-working document?).
• tbc: first feedback from José, appning on documenting the gap between Automotive App Host GAS vs. AOSP
• tbd: emulator requirements revisited - structure the topics (tasks / timing / roadmap).

Meeting notes 2025-02-17

• Participants: GM, FORVIA, Appning by FORVIA, BMW, Bosch, FORD, CARIAD, Elektrobit, Endava, Paradox Cat.
• White paper as project charter; Initial draft - please give your feedback!

• first steps possible after infrastructure has been clarified (repo in github, github actions, build host, artifacts and binary storage) → news expected next week.
• Automotive App Host gaps → analysis probably next week, see change log https://developer.android.com/jetpack/androidx/releases/car-app
• App Host Experience (Paradox Cat, Appning):
  • App Host is open source lib with regular updates.
  • updates include
    • e.g. more number of buttons now (4 instead of 2)
    • some new types of templates, e.g. tab view with each tab having a grid.
  • one update which would be needed also for AOSP is the map rendering possibility:.
    • status was formerly: navi maps render on their own, POI apps use maps rendered by the App Host.
    • if we update to V1.7, apps would be able to render on their own.
    • Appning is using open street maps OSM.
    • ability to run different maps depends on availability of keys, questionable if this would really plug & play.
    • question is if OSM or even different maps could be added to AOSP.
    • maybe a further layer of abstraction would be possible: OSM plus lib which renders OSM.
    • seems as if App Host can be updated and built separate from the platform (as a system app).
      From OEM perspective this feature then would need to be supported.

Meeting notes 2025-02-10

• Participants: COVESA, csimmonds, GM, RemotiveLabs, BMW, FORVIA, Ford, Appning by FORVIA, Endava, Valtech Mobility, Allianz, Tietoevry, Paradox Cat, Renesas, mavi.io
• Review COVESA AOSP Emulator Requirements - thanks to Viktor and José!
• Discussions:
  • add white paper from José as project charter.
  • smaller group to take this forward as proposed in Requirements
  • Viktor could start to build repos, then switch to COVESA
  • first priority: repos, infrastructure. Paul will be talking to Steve and connecting to Viktor regarding machines that are needed.
  • automate the first build, then build on top of it, e.g. adding push notifications
  • Side track not immediately to be solved: automotive host.
    • Option 1: bridge the gap GAS and AOSP automotive host on COVESA
    • Option 2: limit API level which can be used. Up to level 4
    • Option 3: wait for Google.
    • First step: document the gap. José offers first feedback on that within 2 weeks.
  • different emulator images that will be needed:

    • Android version 10-14, two architectures ARM/X86.
      proposal: Start with Android 12 && ARM/X86 ?

    • might also need Android 9.

    • might also need emulators with/without additional services
    • be careful, too many flavours will end us up in too much space/compute power that is needed.

Meeting notes 2025-02-03

• Participants: BMW, COVESA, Bosch, RemotiveLabs, FORVIA, FORD, Appning by FORVIA, Tietoevry, General Motors, Elektrobit, Endava, Allianz, Paradox Cat
• Topics:

  
  

• tools are limiting factor at the moment.
• Sabine: Just a proposal for discussion how we could structure it:

  Category	Task	Description	contributors	until when
  Specification	Requirements	gather and document requirements on this WIKI → José and analyse tasks regarding automotive host offers to start. see: COVESA AOSP COVESA AAOS Emulator Requirements
  Ressources	build & host critical path.	where?  idea: Crave for building → Viktor ? → Viktor to will provide requirements, questions: done monthly? on every pull request? CI needed. idea: COVESA for hosting e.g. → hosting? → gerrit instance on virtual machine. Viktor to will specify. How do we collaborate → go to every repo we are hosting - bundling automatically not easy on Github. → for bundling gerrit better. second option: manually. make the emulator available in the SDK. details see: COVESA AOSP Emulator Requirements
  Component	Push Notifications	be able to use Push Notifications in the emulator → part of the requirements. pre-installed apk.
  Component	Vehicle Data access	Vision: Be able to use vehicle data in the emulator & description on how to do it (e.g. via adb shell commands). Authentication system service. needed: → simulating the data and data streams. → get back to the data stream working group. google has some (python) scripts to feed the emulator. see VISS tooling →  Swen would address it in the data group VSS/VISS. → managing access & permissions.
  Component	Open Source map	emulator extension to render maps in open source map
  Component	SDK	emulator extensions for all (future) SDK parts
  ...	Automotive host decision	as input to emulator.  analyse tasks regarding automotive host.

Meeting notes 2025-01-27

• Participants: BMW, FORVIA/Appning by FORVIA, General Motors, FORD, COVESA, UnifiedPush, RemotiveLabs, Elektrobit, Tietoevry, Paradox Cat
• Emulator Kickoff - requirements (José Freitas, appning by FORVIA):
  
  • Push notifications
  • SDK
  • Automotive host:
    • explanation: for templated apps that can be used while driving, there is a Car app library for e.g. Point of Interest apps. the automotive host on IVI renders the apps.
    • challenge at the moment: mismatch AOSP vs. GAS release.
      for the gap, see release notes: https://developer.android.com/jetpack/androidx/releases/car-app
    • solutions to solve the challenge could be
      • update from Google
      • restrain API level for developers
      • build add-ons on top of AOSP host.
  • Add open source map like open street map, as Automotive host doesn't render maps
  • Data workstream requirements like authentication, system service.
  • From COVESA: building and hosting the images of the emulator,
    ideas:
    • https://crave.io/ allows for open source instances
    • Gerrit instance?
  • next Steps:
    • check with Crave
    • document what is needed (→ new space with this confluence)
    • meet again next week.