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
