summaryrefslogtreecommitdiff
path: root/libnativeloader/native_loader.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Drop ro.debuggable restriction for NATIVELOADER_DEFAULT_NAMESPACE_LIBS.Martin Stjernholm2021-05-131-22/+10
| | | | | | | | | | | | | To allow running tests on user builds. The (non)existence of the environment variable itself serves fine as a toggle, and it is hard to inject into the zygote environment on a user build anyway. Also a few other cleanups from comments on https://r.android.com/1689792. Test: art/test/testrunner/testrunner.py --target --64 --optimizing Bug: 130340935 Change-Id: I1843a8bbfb5dadc560919022d1f2123eb652be5a
* Drop ANDROID_ADDITIONAL_PUBLIC_LIBRARIES.Martin Stjernholm2021-05-131-2/+2
| | | | | | | | | | It's not needed any more since libarttest(d).so is loaded from the ART linker namespace. Test: art/test/testrunner/testrunner.py --target --64 --optimizing Bug: 130340935 Bug: 167578583 Change-Id: I785133e921277cb25360856e9af20fa681b54a3b
* Avoid loading external libraries from ARTs internal linker namespaceMartin Stjernholm2021-05-101-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (reland). dlopen() calls in ART will use its own linker namespace (com_android_art). That's appropriate for internal libraries in the APEX, but not when ART loads libraries on behalf of external requests. In those cases we should instead use android_dlopen_ext to load them from the system namespace, i.e. the one that searches /system/lib(64). The linker config has been using allow_all_shared_libs, so any loads from com_android_art fall back to the system namespace, and hence dlopen() usually works regardless which namespace it ought to use. However we want to drop allow_all_shared_libs, so we need to figure out which dlopen's should use which namespace: 1. Several ART libraries are loaded on-demand, e.g. libart-compiler and libart-disassembler. There are also those going through the runtime plugin system, like libperfetto_hprofd and heapprofd_client_api. All these are internal or at least statically known (so we can provide links for them in the linker config), and should continue to use dlopen from the ART namespace. 2. libnativeloader loads the preloadable public libraries from system/etc/public.libraries.txt, and should use the system namespace for that. 3. libnativebridge loads the native bridge implementation specified through the command line (or ultimately the system property ro.dalvik.vm.native.bridge). It's not part of the ART APEX and not known statically, so the system namespace should be used. 4. libnativeloader also loads JNI libraries from classloader namespaces, but has a fallback if no such namespace can be found based on caller location. Fall back to the system namespace to handle libraries loaded during the preload phase in the zygote. 5. JVMTI agents are loaded by dalvik.system.VMDebug.attachAgent(). Treat these too as external libraries - they are loaded in a way similar to JNI libraries through OpenNativeLibrary in libnativeloader, so are covered by #4. They are normally loaded by apps with a classloader, but a special case is adbconnection which loads libjdwp.so in the ART APEX without one and hence falls back to the system namespace. We therefore need to create a link for it (https://r.android.com/1690889, https://r.android.com/1690795). All cases #2-#5 are covered by libnativeloader and libnativebridge. Introduce OpenSystemLibrary, and since libnativeloader depends on libnativebridge, put it in the latter to be usable from both. It's only an internal dependency not exposed in the APEX stubs. (Another possibility could be to put it in the generic toolbox lib libartbase, but it's split into -d and non-d variants, and we don't want to split libnative{loader,bridge} that way.) Since libnativeloader_test no longer needs to mock dlopen we can simplify it to a more regular test that loads the tested libs dynamically. This relands https://r.android.com/1673312 without setting ANDROID_ADDITIONAL_PUBLIC_LIBRARIES in run-test-jar, because that made libnativeloader try to preload internal libraries from the system namespace. Test: mmm art Test: atest art/libnativeloader Test: atest CtsJniTestCases Test: Cuttlefish app compat test that uses NDK translation Test: Manual tests with Android Studio TI agents (http://g/art-module-team/7Jy3Tg7LCh0) Test: art/test/testrunner/testrunner.py --target --64 --optimizing in chroot on cuttlefish Bug: 130340935 Change-Id: I7fb32faacc1c214402b58125d8190e97bbbcfad2
* Revert "Avoid loading external libraries from ARTs internal linker namespace."Calin Juravle2021-05-091-5/+1
| | | | | | | | This reverts commit 582448f29f2f2529202bf868d00ba5d3d3776bb6. Reason for revert: breaks tests Change-Id: I2e0b2a28d4644b314887673d4aef4f1094aea289
* Avoid loading external libraries from ARTs internal linker namespace.Martin Stjernholm2021-05-071-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | dlopen() calls in ART will use its own linker namespace (com_android_art). That's appropriate for internal libraries in the APEX, but not when ART loads libraries on behalf of external requests. In those cases we should instead use android_dlopen_ext to load them from the system namespace, i.e. the one that searches /system/lib(64). The linker config has been using allow_all_shared_libs, so any loads from com_android_art fall back to the system namespace, and hence dlopen() usually works regardless which namespace it ought to use. However we want to drop allow_all_shared_libs, so we need to figure out which dlopen's should use which namespace: 1. Several ART libraries are loaded on-demand, e.g. libart-compiler and libart-disassembler. There are also those going through the runtime plugin system, like libperfetto_hprofd and heapprofd_client_api. All these are internal or at least statically known (so we can provide links for them in the linker config), and should continue to use dlopen from the ART namespace. 2. libnativeloader loads the preloadable public libraries from system/etc/public.libraries.txt, and should use the system namespace for that. 3. libnativebridge loads the native bridge implementation specified through the command line (or ultimately the system property ro.dalvik.vm.native.bridge). It's not part of the ART APEX and not known statically, so the system namespace should be used. 4. libnativeloader also loads JNI libraries from classloader namespaces, but has a fallback if no such namespace can be found based on caller location. Fall back to the system namespace to handle libraries loaded during the preload phase in the zygote. 5. JVMTI agents are loaded by dalvik.system.VMDebug.attachAgent(). Treat these too as external libraries - they are loaded in a way similar to JNI libraries through OpenNativeLibrary in libnativeloader, so are covered by #4. They are normally loaded by apps with a classloader, but a special case is adbconnection which loads libjdwp.so in the ART APEX without one and hence falls back to the system namespace. We therefore need to create a link for it (https://r.android.com/1690889, https://r.android.com/1690795). All cases #2-#5 are covered by libnativeloader and libnativebridge. Introduce OpenSystemLibrary, and since libnativeloader depends on libnativebridge, put it in the latter to be usable from both. It's only an internal dependency not exposed in the APEX stubs. (Another possibility could be to put it in the generic toolbox lib libartbase, but it's split into -d and non-d variants, and we don't want to split libnative{loader,bridge} that way.) Since libnativeloader_test no longer needs to mock dlopen we can simplify it to a more regular test that loads the tested libs dynamically. Test: mmm art Test: atest art/libnativeloader Test: atest CtsJniTestCases Test: Cuttlefish app compat test that uses NDK translation Test: Manual tests with Android Studio TI agents (http://g/art-module-team/7Jy3Tg7LCh0) Bug: 130340935 Change-Id: I2513472c4e1c44f0fcb01a6b4f6eccbb03718f1d
* In run tests, do not rely on loading native libs in the ART namespaceMartin Stjernholm2021-05-051-5/+170
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | with an allow_all_shared_libs fallback to system. The system and com_android_art namespaces need to be properly separated, but run tests have relied on loading test libraries through either LD_LIBRARY_PATH or java.library.path without a clear separation. That has worked through a combination of ANDROID_ADDITIONAL_PUBLIC_LIBRARIES and fallback dlopen() calls that used the ART namespace. This change introduces a new directory /data/nativetest(64)/com.android.art for test libraries that depend on internal ART libraries. It's added with LD_LIBRARY_PATH to the default namespace, which in the APEX linker config has full access to com_android_art. Normal JNI libraries that don't depend on ART internals stay in /data/nativetest(64)/art/<arch>. There should be no overlap between the two locations. A new environment variable NATIVELOADER_DEFAULT_NAMESPACE_LIBS is introduced to list the libraries added through LD_LIBRARY_PATH, so libnativeloader can link to them from classloader namespaces and in the fallback namespace when no classloader is specified. Like ANDROID_ADDITIONAL_PUBLIC_LIBRARIES, NATIVELOADER_DEFAULT_NAMESPACE_LIBS is only effective when ro.debuggable is true. A new cc_defaults "art_test_internal_library_defaults" is added to Android.bp, to be used in libraries that should be installed in the new com.android.art directory. Some run tests that are special and need more treatment are disabled for now, to be addressed in b/186654484. Test: art/test/testrunner/testrunner.py --target --64 --optimizing Test: art/test/testrunner/testrunner.py --target --32 --jit Test: art/test/testrunner/testrunner.py --host --64 --optimizing Bug: 130340935 Change-Id: Iec640d5e22b46af2c1a4d375ce3f06c57b1d224e
* libnativeloader understands uses-native-library tagJiyong Park2020-07-241-4/+5
| | | | | | | | | | | | | | | | | | | | | | | Previously, libnativeloader provided all the partner-provided public shared libraries to apps unconditionally. Starting from Android S, apps targeting S (or higher) get only the libs that are explicited listed as dependencies using the <uses-native-library> tag in the app manifest. The libs not listed there are not available to the app even if they are registered as public libraries. The changed behavior affects new (S+) apps. Existing apps are not affected; they still get all the libraries. The implementation is rather straightforward. The library accepts a new parameter soname_list from the framework, which is actually from the <uses-native-library> tags of the app manifest. The list is used to filter the partner-provided libraries when the target sdk is > 30. Bug: 142191088 Test: atest CtsUsesNativeLibraryTest Merged-In: I52e23dda58fc69f51451c5dbeffd0a77125c9bff (cherry picked from commit e741dfd18dcd15f002bc1db9bd6634322e4eeef8) Change-Id: I52e23dda58fc69f51451c5dbeffd0a77125c9bff
* Use ART_TARGET_ANDROID instead of __ANDROID__Nicolas Geoffray2020-04-271-8/+8
| | | | | | | | | | | On golem, we build for ART_TARGET_LINUX, which doesn't have support for linkerconfig. Therefore, guard all linker namespace code on ART_TARGET_ANDROID instead of __ANDROID__ (which is unfortunately not under ART's control). Test: build for golem and run Bug: 154074847 Change-Id: I7a2b81918177704b42d8aafbd6d7e9d06d34e5f4
* Loading JNI libraries in an APEXJooyung Han2020-03-041-16/+4
| | | | | | | | | | | | | | | | To load JNI libraries in an APEX, libnativeloader relies on jni.config.txt file which contains available JNI libraries for APEX namespaces: com_android_foo libfoo_jni.so:... com_android_bar libbar_jni.so:... This file is generated by linkerconfig. Bug: 143733063 Test: cuttlestone boots (For now, no behavioral changes because jni.config.txt is empty) Change-Id: I066de90a73875118be53972e50d076061922d762
* Rename APEX NamespaceKiyoung Kim2020-02-211-0/+2
| | | | | | | | | | | | | | | Current APEX Namespace is named with APEX name itself, which also uses .(dot) so linker configuration can keep the syntax safe. For example, if there are APEX modules named 'A' and 'A.link.A', then 'namespace.A.link.A.link.A = a.so' phrase can be ambiguous from the linker. To allow any additional linker syntax in the future, we should avoid dot separator from the namespace name. Bug: 148826508 Test: m -j passed Test: boot succeeded from cuttlefish and walleye Change-Id: I11b6da1b59b4ebf3016f1d783636c7e5d0f8309a
* Use apex name for apex linker namespaceJooyung Han2020-02-111-6/+4
| | | | | | | | | Linkerconfig now uses apex_names to automatically generate linker namespaces from apexes. Bug: 148826508 Test: build / boot Change-Id: Id7fa68531033124727e618284af4fd2a61bdd85f
* Convert art/ to Result::ok()Bernie Innocenti2020-02-071-4/+4
| | | | | | | No functionality changes, this is a mechanical cleanup. Test: m Change-Id: I10030314ad8a06d49a63f1e2f3c5aa5b484e34b6
* Update libnativeloader dependency on libnativehelperOrion Hodson2020-02-061-1/+1
| | | | | | | Only requires header library dependency. Test: m Change-Id: I84de37651f4cb01bdaaa2b354f0a71058a5772f8
* Move libnative{bridge,loader} to art/Orion Hodson2019-10-111-0/+254
This change moves system/core/libnative{bridge,loader} under art/. Bug: 137364733 Test: m Change-Id: I9be7333d00fcd3f36cd80520e50a30ea840187ad
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-20 02:03:52 +0000