libnativeloader_lazy and libnativebridge_lazy are shim libraries for
libnativeloader and libnativebridge, respectively.
The shim libraries provides the same APIs as their counterparts, but
when the APIs are called, the APIs from the real libraries are
loaded/linked/and executed using dlopen/dlsym.
Bug: 123403798
Bug: 124250621
Test: m
Test: device boots to the UI
Test: mma under system/core/libnativebridge with aosp_cf_x86
adb sync; execute all tests under
/data/nativetest/libnativebridge-lazy-tests
All passes except NativeBridgeTest.V2_Signal which is also failing
in /data/nativetest/libnativebridge-tests.
Change-Id: Ic6484784eaa7872dcdd2decbb30943fb34c1abd7
Product-specific libraries in /product/lib can be exposed to Android
apps by adding the list of the libs into
/product/etc/public.libraries-<companyname>.txt. The libs MUST be named
as lib<name>.<companyname>.so.
Bug: 73095206
Test: with taimen
mma -j and runtest.sh. The libs are all loaded in system, but not in
vendor. After reinstalling app using adb -r and reopening app, only
libraries listed in .txt are loaded
Change-Id: I7c386813c72a7b225a7f244b6c5fec4ac0660fd3
OEM-defined libs in /system/etc/public.libraries-<companyname>.txt files
are not available to apks in the vendor partition, otherwise we are
allowing vendor -> system dependency, which is a Treble violation.
Bug: 71561542
Test: mm -j under system/core/libnativeloader/test and runtest.sh
the four libs (lib[foo|bar].[oem1|oem2].so are all loaded in
android.app.test.system app but not in android.app.test.vendor app
Change-Id: Ie5d9160ae4dc2a64beb6507602ee5a1db6518875
Partners (entities other than AOSP) can expose their own system
libraries which are in /system/lib[64] to Android apps. This can be done
by adding the name of the libs into the files
/system/etc/public.libraries-<companyname>.txt.
There can be multiple of the txt files on a device, which is for the
case that multiple partners contributing to the same system image
have their own set of public libraries.
The public libraries MUST be named as lib<name>.<companyname>.so. This
is to prevent accidental exposure of AOSP-defined system private libs.
Note 1:
<companyname> doesn't need to be the same as the value of the sysprop
ro.product.manufacturer or anything that can be part of a file path.
Note 2:
This feature is not for exposing SoC-specific libs to Android apps. That
is already done by /vendor/etc/public.libraries.txt and is only for
libs in /vendor/lib[64].
Bug: 68280171
Test: mm -j under /system/core/libnativeloader/test
cts-tradefed run commandAndExit cts-dev -m CtsJniTestCases -t
android.jni.cts.JniStaticTest#test_linker_namespaces
Change-Id: I7d32ec27c7858e35b96c7c98223cc110acb35b81
