Dynamic Loading of Native .so Libraries in Android Apps: Testing Strategies and Recommendations

In Android development, using the NDK to create native .so libraries for tasks such as video decoding or complex animations can significantly increase the size of the APK, making the installation package bulky.

To achieve a slimmer package, developers often separate these .so files from the APK and load them dynamically at first launch or when the related feature is invoked.

Testing objectives include deciding whether the library should be auto‑downloaded on first launch, handling download over cellular networks, prompting the user during network download, and defining interactions when the library is missing or after successful installation.

Example scenario : A video‑playback app bundles several large .so files (≈12 MB each), causing the APK to exceed 20 MB. To slim the package, the team opts for dynamic downloading of the native libraries.

Test point design :

1. Ensure normal playback using the system player when the .so is not downloaded, covering various device models, video formats, and playback interactions (play, pause, replay, interruption, offline playback).

2. Verify the download process: trigger timing, normal download, interruption by network loss, process kill, network switch, weak network, and failure cases.

3. Validate library verification and installation: corrupted files, installation failures, and correct installation timing.

4. Conduct regression testing of all features after successful installation.

5. Test upgrade scenarios where a new version replaces the existing .so files.

6. Perform compatibility testing across different device models.

Potential issues and suggestions :

• If the .so fails to download, any feature that depends on it should show an error without silent failures; the app should prompt the user that the component is downloading and fall back to the system player once installed.

• Download should be triggered only at app start for essential libraries; for important libraries, also request download when the feature is used, and let users decide on cellular networks.

• After an over‑the‑air upgrade, ensure the new version remains compatible with the old .so unless a major change is made.

• When adding new features that depend on a native library, confirm with product owners whether a download prompt is required.

• If multiple .so files have dependency relationships, use a tool to guarantee correct installation order and avoid crashes.

The author invites readers to share their own testing problems and experiences in the comments.