...
- Bosch: we have issues with the BT audio stream / BT handsfree but I am just starting digging into it
- Gunnar: I am surprised that the BT handsfree is not part of the Google AA code
- Bosch: there is some support in the framework to support handsfree
- Gunnar: is the basic hansfree profile implementation part of the BT support in AA ?
- Bosch: pairing the phone with the device works but there is a need to connect the audio
- Andrey: shows a list of questions / problems, look at the list below
- Android does not implement all features required by customer.
- Audio focus can be lost at any time
- Limited number of sources
- Limited number of priorities -2
- No easy way to support external amplifiers
- No priorities of phone call types.
- Android Audio subsystem is developed only for infotainment purposes. Safety-related features need to be implemented in another RTOS
- Need to share the same hardware between 2 OSes
- Running Android as a virtual machine inside RTOS leads to problems with scheduling of audio processes
- Android way of extending its functionality is developing vendor extensions without modification of the framework.
- But in some cases you need to modify framework. There is a process for this, but slow. And changes needed to one customer / developer is not needed for another. Even if you do this, you have to wait until Tier 1 merges this change to its drop
- You have to retain compatibility for third-party apps
- Android does not implement all features required by customer.
- Gunnar: what are the most important topics to tackle on ? maybe there is a particular problem to look at first
- Wassim: there is some topics that are low-hanging fruit
- Stefan: IMHO some of the topics are not related to Audio HAL but rather system-level architectural issues
- Gunnar: Audio HAL is much more complex than the Vehicle HAL
- Gunnar: in the Vehicle HAL we are finding solutions that can sit aside from AA, we do not intend to make a fork which would provoke a lot of
integration problems - Stefan: priority of sources varies among OEMs, we would need a better configuration capability from Google to handle this better
- Bartorz: extending the framework is fine provided you do not change the APIs, the HAL is actually something where we can put additional stuff
"for free" - Bartoz: this is a much bigger challenge to work out a common Audio Hal and port it to different SoCs but it is interesting to do
- Gunnar: agreed
- /TODO/ all participants identify additional extensions to Audio HAL that would not change too many things
- /TODO/ all participants identify a part of the Audio HAL that could common for all SoC vendors
- /TODO/ Gunnar and Philippe create the wiki page to gather the priorities of topics of interest listed so far (from minutes of first meeting and presentations delivered by Tieto and Windriver at the tech summit)
...