With the recent change that removed get_exported_namespace out of libdl,
the RenderScript SP-HAL stopped using android_dlopen_ext which it used
to load libRS_internal.so in the "rs" namespace. Instead, it now falls
back to the ordinary dlopen() call. The dlopen() call tries to load the
lib in the current namespace (which is sphal) and then falls back to the
linked namespaces: default, vndk, rs.
The problem is that rs is listed as the last namespace and therefore the
linker tries the namespace only when it failed to load the library in
other namespaces: default and vndk. libRS_internal.so is accessible to
both vndk and rs namespaces. So, the dlopen() call always goes into the
vndk namespace and there is no chance for the lib to be loaded in the rs
namespace.
To fix the problem, the rs namespace is placed before vndk so that the
namespace is tried first.
Bug: 129550847
Test: runtest -x cts/tests/camera/src/android/hardware/
Change-Id: Idafc32f8a309dd12495768931d7ea17a2f791c50
This is necessary to get the correct APEX namespace setup for apps that
executes binaries from there.
In older releases no linker config applied to binaries in /data, so the
fallback config in /system/bin/linker was used, which basically just looked
up libraries in /system/{lib,lib64}. With the introduction of APEXes that
location no longer contains the complete set of libraries, so this is
necessary to retain functional parity.
Strictly speaking this fallback rule should apply as last resort for a
binary in any location, but the linker does not accept "dir.system = /".
Test: Flash and boot
Test: The app regression in b/128569634
Bug: 128569634
Change-Id: Icfcd66f0a7d8d898618be1b6186bb1111d20d688
They are not needed since the binaries and relevant exported libraries have
moved to the Runtime APEX.
Test: Flash and boot
Test: atest CtsJniTestCases CtsJdwpTestCases
Bug: 119867084
Change-Id: If416fbae7057aec02059bb31a4dcd8b63dcc0cad
AsynchronousCloseMonitor is moved into libandroidio by
r.android.com/910073 and so libjavacore no longer needs to
be linked to the conscrypt namespace.
Bug: 123744297
Test: m && flashall
Test: atest CtsLibcoreOkHttpTestCases
Test: atest CtsLibcoreTestCases
Change-Id: Id720b59e4ef42a2c0226b497a1cc3c54f7a837d0
Make ld.config.legacy.txt similar to other linker configurations with
respect to tests in /data/{nativetest,benchmarktest}{,64}.
Note: The linker legacy configuration is used by the ART generic build
targets, defined in project device/generic/art.
Test: ART chroot-based on-device testing using the master-art
Bug: 121117762
Change-Id: I6c8fafa2568862e450aa7b9fea1177a184cb9705
With allow_all_shared_libs, the libs under /system/lib may be used
instead of libs included in the apex. This change adds stable libraries
the media apex relies on to prevent this case.
Test: dumpsys media.extractor, atest MediaPlayer2Test
Bug: 127791685
Change-Id: I6a0419e6da9e9f48a394257b1e8f977ec2dfa9a1
Bind-mounting of the bionic files on /bionic/* paths no longer required
as there are direct symlinks from bionic files in /system partition to
the corresponding bionic files in the runtime APEX. e.g.,
/system/lib/libc.so -> /apex/com.android.runtime/lib/bionic/libc.so
Bug: 125549215
Test: m; devices boots
Change-Id: I4a43101c3e3e2e14a81001d6d65a8a4b727df385
When no-vendor-variant VNDK is enabled, the vendor variant of VNDK
libraries are not installed. In this case, the vendor binaries need to
be able to link in the core variant.
Update the linker config so that we export such VNDK libraries to the
proper linker namespaces.
Bug: 119423884
Test: Enable no-vendor-variant VNDK for a dummy VNDK library. Boot and
check the vendor variant does not exist and only the core variant
is used.
Change-Id: I71274fdf61373663603a5fbc3497400420094fcf
This is a temporal fix. With this change, the extractor plug-ins uses
unstable libs under /system/lib[64]. The right resolution is being
discussed.
Test: applied the same change to ld.config.txt and checked
the memory map of media.extractor on cuttlefish.
Bug: 127791685
Change-Id: Ifd5b79831f27ef4017bb8aa774671aa9b2c5264e
Because /vendor is a symlink to /system/vendor on devices without a
dedicated /vendor partition, /system/vendor/lib/* needs to be added to
the permitted paths whereever /vendor/lib/* is permitted.
Reasoning:
Legacy devices are forced to use ld.config.legacy.txt, which is very
permissive. We can prolong support for them and enable them to use the
VNDK if we extend the search paths to include the resolved symlink dirs.
Change-Id: I6b3bb7b86ed82395345a16bdc857353b1b15c704
Ensure that only the symbols in liblog.map.txt can be used by the
platform.
Bug: 123349183
Test: build
Change-Id: I99ae5d0e8ba8f5061ec20701c941d861c9eb615d
This is essentially the same change as
bcb5ba75a5
for ld.config.vndk_lite.txt.
Bug: 124789446
Test: atest CtsBionicTestCases on marlin
Change-Id: I6b65ec4df1626d625975c9834bf96ac9ff6cc3f3
libandroidicu is used by various libraries, e.g. libxml2, minikin.
Thus, expose libandroidicu to default namespace.
libpac is only used by libjni_pacprocessor (part of framework).
libicuuc, libicui18n are not exposed to default namespace,
because everyone else, except app, should use libandroidicu.
They are exposed to classloader namespace from runtime namespace
via the work done in libnativeloader in http://r.android.com/887453
b/120786417 has more details about these 2 libraries.
Bug: 120659668
Test: m droid
Change-Id: I2cd3378f1eb94b7bb1c942738b59d7e577a5f8f0
Originally, vndk_lite does not include system/lib/vndk-* directory but
searching the required files in system/lib instead. However, in GSI,
they are using the vndk libs which has symbols than core variants.
To avoid this problem, allow the vendor processes in vndk_lite devices
to search system/lib prior to vndk libs.
Bug: 124063441
Test: Check boot for vndk_lite devices.
Change-Id: I89a72e9d43d6fb05f4b6d87bbd4500f8febfe970
