SO hardening and native compatibility checklist
Yudun technical guide · Engineering principles and practice · English
SO hardening begins by understanding how native libraries are built, loaded, and called, not by hiding a few symbols. A clear load chain and ABI range give the strategy a testable boundary.
Build the native dependency map
List directly loaded libraries, transitive dependencies, JNI registration, and initialization order, including native components in third-party SDKs.
The map shows which libraries can change independently and which exports or load constraints must remain.
- Primary and dependent libraries
- JNI registration
- Load timing
- Third-party native SDKs
Choose controls by information type
Exports, strings, constants, protocol handling, and high-value functions expose different risks.
Frequently executed functions, application launch initialization, and error paths need specific performance and stability attention.
Collect evidence for every ABI
State which ABIs the output contains, then verify installation, application launch, library loading, and critical JNI calls on each target architecture.
Emulator evidence does not automatically replace the real target architecture.
- ABI matches output
- Dependencies resolve
- JNI calls regress
- Failures can be located
Release with APK and server controls
Native protection raises analysis cost, while signing, approved versions, server authorization, and final APK regression remain independent release responsibilities.
Verify the boundary with a real release candidate
Provide the application stack, critical paths, and target system range. Accounts, applications, and project details are handled by the central Yudun platform.