Because in functions of hardware.c, the variables are
not initialized when they are defined, valgrind indicates
that these variables are used as uninitialised! So,
the purpose of this patch is initialization of varaibles.
In the same way, the patch fixes the compilation warning
(unused variable).
Change-Id: Ibaab89d7b57eb9e3a1f46c3af61705a39be10e16
Signed-off-by: Andrei V. FOMITCHEV <andreix.fomitchev@intel.com>
Signed-off-by: Jin Wei <wei.a.jin@intel.com>
Try to load a HAL determined by ro.hardware.<class> first before
falling back to hardware, board, platform, arch, and default.
This is intended to be used to support multiple hardware variants
from the same source. For example, a single build that supports
two gps chips, gps001 and gpsb, could use /factory/factory.prop
to set ro.hardware.gps=gps001 or ro.hardware.gps=gpsb, which would
load gps.gps001.so or gps.gpsb.so. Two separate builds from the
same source could use PRODUCT_PROPERTY_OVERRIDES to set the
properties.
Change-Id: I1ac46c21ceb27ceb5165e8c44e9373e9c5d4e34e
Some vendors have their own HAL modules, which may need their
default implementation stored in /vendor.
Change-Id: I5337a61875023404a85029bbc59b984056b3e441
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.
