GitLab

ODM HALs should be compiled into /odm/lib/hw on the ODM partition.

BUG: 25653199
Change-Id: I23324d8e4dc82301cebd71bc40cdd2b73a678360

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>

Change-Id: Ib905e079b1e88977fb3408671301904c58f35d3c

Replace == with >, property_get returns the length of the
property if found.

Change-Id: I4b8fe8f8dba578112d21eee5dc64be4aa27f3bfb

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

See https://android-git.corp.google.com/g/#/c/157220

Bug: 5449033
Change-Id: I0cbe865d464a37365fa3be84948b07e5a0d181d0

See https://android-git.corp.google.com/g/#/c/143865

Bug: 5449033
Change-Id: I8772e564a55981aad2a9cf7cb9245367fcf57fe8

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>

Search /vendor/lib/hw/... as well as /system/lib/hw/... for hal modules.

Change-Id: I1aecafcc884e11b2f17edf28e8c8ca2926184807

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.

pmem allocator in gralloc. enabled for all surfaces. currently it uses a lot more address space than needed.

SurfaceFlinger rework for new EGL driver model support.