It should not directly call functions from hybris's libEGL,
because it is not linking to libEGL. Load libEGL dynamically
and resolve function at run time instead.
Related: https://github.com/libhybris/libhybris/pull/424
[ci:skip-build]: already built successfully in CI
As observed on UBPorts, hwcomposer implementation on Android 7 CAF (non-Nexus
Qualcomm) devices has slight differences in employed structs, which makes
them binary incompatible with AOSP headers.
Halium 7.1 android-headers extracted from LineageOS include those
modifications (e. g. https://github.com/Halium/android-headers/blob/halium-7.1/hardware/hwcomposer.h#L290),
so it is enough to add QTI_BSP/QCOM_BSP to defines of programs utilizing
those headers. In case of libhybris, only test_hwcomposer is affected so
far on 7.1 (might be not true for Android 5.1/6!).
This change avoids providing libhybris-7.1-caf package by building a
separate binary of test_hwcomposer for affected devices.
As discussed in #1039, I want to split feature/hybris branch into
smaller sensible pull requests.
This is the first one that simply adds android-headers and libhybris
packaging. libhybris allows apps compiled with glibc (musl in our case)
to load Android libraries that utilize bionic libc, which is used to
load proprietary userspace drivers.
The package isn't very useful on its own and requires core (non-UI/Java)
Android services to be running in some way - either in Halium-style LXC
container or in same root as main OS with modified init (Mer/Sailfish do
it this way). Both ways are tested to work in postmarketOS.
libhybris also includes some tests, not all of them are known to be
representative, but test_vibrator and test_egl_configs are usually good
indicators if system is set up correctly.
