Lines Matching refs:to

3 This document details important changes related to native code
22 will be tied to an app's target API level:
27 * At the affected API level and above, we’ll refuse to load the library.
36 toasts help bring some visibility to the issues before it's too late.
39 ## Changes to library dependency resolution
44 had to call `dlopen` or `System.loadLibrary` on all transitive
48 to topologically sort your libraries and load them in reverse order.
50 If you need to support Android devices running OS versions older than
51 API level 23, you might want to consider
52 [ReLinker](https://github.com/KeepSafe/ReLinker) which claims to solve
55 Alternatively, if you don't have too many dependencies, it can be easiest to
60 ## Changes to library search order
62 We have made various fixes to library search order when resolving symbols.
64 With API level 22, load order switched from depth-first to breadth-first to
67 Before API level 23, the default search order was to try the main executable,
73 flag set (by passing “-z global” to ld(1)). The local group is
76 the local group. This allows ASAN, for example, to ensure that it can
82 LD_PRELOAD applies to both 32- and 64-bit processes. This means that you
90 The dlopen(3) RTLD_LOCAL flag used to be ignored but is implemented
92 so even calls to dlopen(3) that didn’t explicitly use RTLD_LOCAL will
94 symbols will not be made available to libraries loaded by later calls
95 to dlopen(3) (as opposed to being referenced by DT_NEEDED entries).
102 above. Use `--hash-style=both` if you want to build code that uses this
115 and used that to search for already-loaded libraries. For example,
118 that it was impossible to have two libraries `"dir1/libx.so"` and
121 tried to load both. This also applied to DT_NEEDED entries.
124 machine’s file system) that used to work because we ignored everything
125 but the basename. These apps will fail to load on API level 23 and above.
130 Symbol versioning allows libraries to provide better backwards
139 In API level 23 and above, it’s possible to open a .so file directly from
145 and reported to the user as space taken up by your app). Any .so file
146 that you want to load directly from your APK must be page aligned
153 page-aligned and stored uncompressed for this to work.
160 this rule is enforced and applications are no longer able to load all
161 non-NDK platform libraries. This was to prevent future issues similar
162 to the disruption caused when Android switched from OpenSSL to BoringSSL
166 are not accessible regardless of the way code tries to load them:
167 System.loadLibrary(), DT_NEEDED entries, and direct calls to dlopen(3)
170 In order to reduce the user impact of this transition, we identified
172 most-installed apps and were feasible for us to support in the
174 and libssl.so). In order to give app developers more time to transition,
175 we allowed access to these libraries for apps with a target API level < 24.
176 On devices running API level 26 to API level 30, this compatibility mode could be
197 *Resolution*: rewrite your native code to rely only on public API. As a
199 (libcutils.so) can be copied to the project. As a long term solution
200 the relevant code must be copied to the project tree. SSL/Media/JNI
209 applications should use GMS Security Provider to ensure they are protected
218 attempt to obfuscate the binary and prevent reverse engineering. (This
219 doesn't really help because it is possible to reconstruct the stripped
250 If you have no scanelf tool available, it is possible to do a basic
252 TEXTREL flag. Either alone is sufficient. (The value corresponding to the
263 Note: it is technically possible to have a shared object with the TEXTREL
266 you're not generating ELF files that claim to have text relocations,
272 level 23 and above refuses to load code with text relocations.
274 *Resolution*: rewrite assembler to be position independent to ensure
287 leaving the business of finding the library at runtime to the dynamic
293 the DT_NEEDED exactly and so it won't be able to load the library if
296 Even worse, some build systems have bugs that cause them to insert
297 DT_NEEDED entries that point to a file on the build host, something that
310 used, but starting from API level 23 the Android runtime will try to load the
316 only. It is better to let the runtime linker to find and load those
317 libraries as the location may change from device to device.
325 a misconfiguration in your build system. A missing SONAME may lead to
334 *Potential problems*: namespace conflicts may lead to the wrong library
335 being loaded at runtime, which leads to crashes when required symbols
336 are not found, or you try to use an ABI-incompatible library that isn't
341 configured your build system to generate incorrect SONAME entries (using
347 To allow `atfork` and `pthread_atfork` handlers to be unregistered on
360 will be searched to resolve DT_NEEDED entries. The string `${ORIGIN}` will
361 be rewritten at runtime to the directory containing the ELF file. This
370 dynamic linker what permissions to give the corresponding page in
405 to the fully-qualified name of the specific app:
413 of libraries. Note also that `dlerror` doesn't correspond to actual
414 calls of dlerror(3) but to any time the dynamic linker writes to its
419 On userdebug and eng builds it is possible to enable tracing for the
421 app-specific one. For example, to enable logging of all dlopen(3)
430 Android allows `dlclose` to unload a library even if there are still
431 thread-local variables with non-trivial destructors. This leads to
432 crashes when a thread exits and attempts to call the destructor, the
438 set (so that calls to `dlclose` don't actually unload the library)
452 functionality in the dynamic linker to choose optimized assembler routines at
454 devices, and is similar to what other OSes already did. Because the zygote
457 Most apps should be unaffected by this change, but apps that hook or try to
458 detect hooking of C library functions might need to fix their code to cope
460 may expand to include more functions (and more libraries) in future.
472 The RELR encoding is unrelated to the earlier "packed relocations"
475 There are no plans to remove support for ELF files using the older
479 Prior to API level 35, there was a bug that caused RELR relocations to
482 section would have been able to read globals with RELR relocations
485 should make sure not to store `R_*_IRELATIVE` relocations in packed
486 relocation sections in order to maintain compatibility with API levels
497 `.preinit_array`/`.init_array`/`.fini_array` sections of executables to locate
504 and switched to using symbols inserted by LLD (like `__init_array_start`,
505 `__init_array_end`) to locate the arrays. This also avoids the need for an