The default boot ctrl implementation depends
on libhardware.
Bug: 78793464
Test: Compiles, can load bootctrl in recovery
Change-Id: I9c8aa8b00b9b81f11736de13c85973e113056e69
HAL implementations should be directly inside hw
folders.
Fixes: 80431864
Test: Boot Pixel 2 devices (which has hal implementations
that use this as an implementation detail)
Change-Id: I430c2531ed40ce85c86e8efac4fbd2bc244aa5fd
For vendor modules, do not search system directory.
Also, vendor modules do not need to dlopen system hals.
Those are allowed only for system modules.
Bug: 62209000
Test: On the device, use camera, audio and bluetooth a2dp.
Change-Id: If7af82a694ef8de901adae7e9aeb187a30e50b02
Originally, it is not allowed to open non-sphal libraries if the device
has sphal namespace. However, some system processes are still using
libhardware to load non-sphal libraries. Since it has no harm to allow
system libraries to be loaded by libhardware, this patch loads the
library from the default namespace if the library is located in system
partition.
Bug: 38435840
Test: sailfish builds and boots
Change-Id: I206da11a2656559fcd0995d32dbd73621a79a683
'vndk' namespace should not have /vendor/lib/* in its search paths.
However, /vendor/lib/* has been included due to libhardware; it should
be able to load HAL libs in /vendor/lib and /vendor/lib/hw.
Since the HAL libs are not vndk but part of SP-HAL, they are loaded
explicitly from the 'sphal' namespace.
Bug: 37731053
Bug: 37323945
Test: sailfish builds and boots successfuly
Test: BOARD_VNDK_VERSION=current m libhardware.vendor successful
Change-Id: I1e1619de7deaa0e6610180e585bd7775887bc562
This doesn't need utils/Log.h, just log/log.h and some stdlib headers.
Bug: 33241851
Test: m -j libhardware
Change-Id: Id73059f5636af42b0d1680b89f6ca27f466d9ea8
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.
