How to Combat Android .so Library Bloat and Compatibility Issues

Basic Knowledge

In Android development, dynamic library .so files are typically built with C/C++ (or increasingly Rust) and packaged as ELF binaries. This section focuses on ABI incompatibility, duplication, conflicts, and unused exported symbols, discussing tooling and mitigation practices.

1.1 C++ Standard Template Library (STL)

When using C++ to develop .so libraries, you must choose a specific STL implementation. Options include:

libc++ – LLVM’s implementation, the default for Android 5.0+ and the only STL available from NDK r18 onward.

gnustl & gnustl_port – GNU implementations, deprecated after NDK r18.

system – Android’s built‑in minimal STL (new/delete only), also deprecated.

After selecting an STL, you can link it statically (copying code into the .so) or dynamically (referencing the STL symbols at runtime). For a single .so, static linking reduces package size; for multiple .so files, static linking inflates size, so dynamic linking is preferred. Consistency—using the same STL and the same linking mode across all .so files—is essential to avoid crashes.

1.2 so Dynamic Linking (Dependencies)

Modules built as .so can depend on other .so libraries, similar to STL linking. When a dependent .so is present in the APK, dynamic linking should be used; otherwise static linking is required. Dependency information resides in the .dynamic section and can be inspected with readelf:

Dynamic section at offset 0x2d18 contains 27 entries:</code><code>  Tag        Type                         Name/Value</code><code>0x00000001 (NEEDED)             Shared library: [liblog.so]</code><code>0x00000001 (NEEDED)             Shared library: [libm.so]</code><code>0x00000001 (NEEDED)             Shared library: [libc++_shared.so]</code><code>0x00000001 (NEEDED)             Shared library: [libdl.so]</code><code>0x00000001 (NEEDED)             Shared library: [libc.so]</code><code>0x00000001 (NEEDED)             Shared library: [libslimlady_core.so]</code><code>0x0000000e (SONAME)             Library soname: [libslimlady.so]

The NEEDED entries list the libraries this .so depends on, such as libdl.so (dynamic loader), libc.so / libm.so (C runtime), liblog.so (logcat), libc++_shared.so (LLVM STL), and other project‑specific .so files.

1.3 so Loading Process Analysis

When System.loadLibrary is called, the Java runtime searches for the absolute path of the .so. For Android < 6.0 the search path is stored in BaseDexClassLoader.nativeLibraryDirectories; for Android ≥ 6.0 it is in DexPathList.nativeLibraryPathElements. After locating the file, the VM checks if it is already loaded; if not, the native loader parses the ELF header, resolves its dependencies, and loads them breadth‑first. Search paths differ by OS version: Android < 7.0 uses the Java‑level paths, while Android ≥ 7.0 introduces a Namespace concept that mirrors the Java paths in native code.

Governance Practice

As the codebase grows, .so “corrosion” accumulates: excessive static STL linking inflates size, missing ABIs cause crashes, duplicate .so increase package weight, and unused exported symbols waste space. Dedicated tools detect these issues and enforce gate‑keeping checks to prevent new problems.

2.1 ABI Incompatibility

ABI (Application Binary Interface) differences arise from CPU architecture (32‑bit vs 64‑bit ARM) and calling conventions. Supporting 64‑bit brings performance and memory‑address‑space benefits, but also larger binaries. Google Play has required 64‑bit support for apps with native code since August 2019. Strategies include App Bundle (feature modules per ABI), split‑APK (separate 32‑bit and 64‑bit APKs), or universal “fat” APKs, each with trade‑offs in size and distribution.

2.2 Duplicate so

Duplicate .so files share the same ABI and identical MD5 hashes but have different filenames, leading to redundant packaging and potential runtime conflicts. Detection output example:

[armeabi-v7a] md5: c0598ed0b87843147152e14bba2b036f</code><code>|-- libmitaec.so (com.youku.android:DQI4Android:1.2.0.10)</code><code>|-- libNlsAEC.so (com.youku.android:DQI4Android:1.2.0.10)

2.3 Conflict so

Conflict .so refers to the same ABI and filename but different MD5 hashes, causing build failures or nondeterministic “pickFirst” behavior. Detection example:

[armeabi-v7a] libaceManager.so</code><code>|-- com.youku.arch:Hnd:2.8.16-SNAPSHOT (4339…)</code><code>|-- com.youku.android:ALib:1.0.2 (b7f8…)

2.4 Useless Exported Symbols

Exported symbols that are never imported by any other .so inflate package size. The analysis lists modules, .so names, and ABI, e.g.:

* project:library-aar-2:1.0</code><code>|-- libuvc.so</code><code>   |-- _uvc_status_callback</code><code>   |-- uvc_print_format_desc_one

JNI_OnLoad/OnUnload symbols and symbols accessed via dlsym are excluded or manually verified to avoid false positives.

2.5 Governance Overview

The combined tooling provides a comprehensive view of .so health, enabling developers to shrink package size, ensure ABI compatibility, and avoid runtime crashes. A final overview diagram illustrates the end‑to‑end detection and remediation pipeline.