Make sure hw_get_module_by_class() first scans /vendor/lib/hw
and then /system/lib/hw so that vendor specific modules override
default ones.
Change-Id: Iaec61c3b4bb6fde202acb4412aaec3b318cc1cbd
Needed for things like audio and audio effects. Provides a
new interface to loading modules named 'hw_get_module_by_class'.
This takes two parameters: 'class_id' and 'instance' which are
used to construct the filename for the module to be loaded. If
instance is NULL, then this function acts identically to
hw_get_module where 'class_id' == 'id' (and in fact the latter
implemented exactly this way).
For audio, this new mechanism allows us to load multiple audio
interfaces by doing:
hw_get_module_by_class("audio", "primary", &module);
hw_get_module_by_class("audio", "a2dp", &module);
hw_get_module_by_class("audio", "usb", &module);
...
In the future we will likely want to add the ability to load a set of
module instances based on a config file, which will have a standard
syntax and the mechanism will be provided by libhardware.
Change-Id: I9976cc6d59a85a414b18e7b398a36edfbce4abd8
Signed-off-by: Dima Zavin <dima@android.com>
The problem was a simple typo, which prevented modules like
/system/lib/hw/lib<module>.default.so from being loaded even if they
were found on the system.
This is required to fix the generic build when run in the emulator.
Once we have determined which HAL to load and checked that the library exists,
we should not try to load another (more generic) HAL if a failure occurs, because
this could result in different process using different HALs for the same component.
Instead we just return an error.