8b265c90b2
This is part of supporting multiple devices playback. Currently, the usb audio module only supports single device. The limitation is that there is only one alsa_device_profile/proxy cached. With supporting multiple devices playback in audio framework, it makes sense to use list to cache alsa_device_profile/proxy so that it is possible to route audio to multiple USB devices simultaneously. To keep the code symemetric, the device for capture is also cached as a list. But there will only be one device for capture. Test: play audio via USB Bug: 160352965 Change-Id: Ibe7bbb7000d657381b317c19fda57e6c0edaa1df |
||
---|---|---|
.. | ||
audio | ||
audio_remote_submix | ||
camera | ||
consumerir | ||
fingerprint | ||
gralloc | ||
hwcomposer | ||
input/evdev | ||
local_time | ||
nfc | ||
nfc-nci | ||
power | ||
radio | ||
sensors | ||
soundtrigger | ||
thermal | ||
tv_input | ||
usbaudio | ||
usbcamera | ||
vibrator | ||
vr | ||
Android.mk | ||
README.android |
Default (and possibly architecture dependents) HAL modules go here. libhardware.so eventually should contain *just* the HAL hub (hardware.c), everything in it should be rewritten as modules. Modules are .so in /vendor/lib/hw/ and have a well defined naming convention: /vendor/lib/hw/<*_HARDWARE_MODULE_ID>.<ro.product.board>.so /vendor/lib/hw/<*_HARDWARE_MODULE_ID>.<ro.board.platform>.so /vendor/lib/hw/<*_HARDWARE_MODULE_ID>.<ro.arch>.so /vendor/lib/hw/<*_HARDWARE_MODULE_ID>.default.so They also have a well defined interface which lives in include/hardware/. A module can have several variants: "default", "arch" and "board", and they're loaded in the "board", "arch" and "default" order. The source code for the "board" variant, usually lives under partners/... The source code for "default" and "arch" would usually live under hardware/modules/.