Docs

Android 17 Native Library Loading: What to Track

Android 17 requires native libraries loaded via System.load() to be read-only, breaking crash and analytics SDKs — what to monitor before you target it.

Performance

Android 17 extends Safer Dynamic Code Loading — previously a DEX/JAR-only protection — to native libraries. Any file loaded via System.load() now has to be read-only, or the app throws UnsatisfiedLinkError at the exact moment it tries to load it. That sounds like a narrow security hardening detail, but it lands squarely on the SDKs least likely to be caught by normal QA: native crash reporters, anti-tamper libraries, and analytics SDKs that extract or patch a .so file at runtime, often only in production builds under real device conditions.

The timing makes this worse than a routine platform change. Google Play’s target-API deadline requires new and updated apps to target API 36 by the end of August 2026, which has a lot of teams bumping targetSdkVersion right now. Jump straight to API 37 while you’re at it — a reasonable instinct, since you’re already touching the manifest — and you can silently break the exact instrumentation you’d rely on to notice something else broke. A crash SDK that fails to load doesn’t just miss its own crashes; it takes your visibility into everything else with it. Common workarounds like the ReLinker library, which re-extracts native libraries to a writable location before loading, stop working under the same restriction.

Data Points to Track

  • SDK initialization success rate, split by targetSdkVersion and Android OS version, so a native-library load failure introduced by an API bump shows up as a distinct cohort rather than blending into an aggregate crash-free-users number
  • UnsatisfiedLinkError occurrences, tagged separately from other crash types, since this specific failure mode indicates a dynamic-loading violation rather than a genuine app crash
  • Native library load path and permissions, logged at SDK init time in a debug build, to catch System.load() calls against extractable or writable paths before they reach production
  • Third-party SDK version and native-loading strategy, inventoried across every dependency that ships or extracts .so files, including ad SDKs, crash reporters, and anti-tamper libraries
  • Silent instrumentation gaps, measured as a drop in expected event or crash volume from a specific app version or OS cohort rather than an explicit error, since a broken crash SDK reports nothing at all

Setup Steps

  1. Grep your codebase and dependency tree for System.load() and System.loadLibrary() calls, and for any use of ReLinker or equivalent runtime-extraction libraries, before bumping targetSdkVersion past 36.
  2. Audit every third-party SDK’s native-loading behaviour, not just your own code — most teams don’t control how a bundled crash reporter or ad SDK loads its native components.
  3. Test on an actual Android 17 device or emulator with the new restriction enabled, since this failure mode won’t show up in unit tests or on older OS versions running the same targetSdkVersion.
  4. Instrument SDK initialization explicitly — log success/failure for every native-dependent SDK at startup, rather than assuming silence means it worked.
  5. Stage the targetSdkVersion bump separately from other changes, so if instrumentation volume drops after release, the API-level change is the first and most obvious suspect rather than one of several simultaneous changes.

Actionable Insights

A drop in crash or event volume that coincides with a targetSdkVersion release, with no corresponding drop in DAU or session count, is a strong signal that a native-dependent SDK failed to initialise rather than that users stopped triggering crashes. Comparing UnsatisfiedLinkError rates across old vs. new targetSdkVersion cohorts isolates whether the restriction is actually being hit in the wild, versus only in specific device or OS combinations. And because Play’s August 2026 deadline is pushing many teams toward this bump simultaneously, expect third-party SDK vendors to ship fixes reactively — tracking SDK version alongside initialization success lets you correlate a fix landing with instrumentation recovering, instead of guessing.

Expert help

Need help tracking this in your app?

Our team sets up analytics pipelines for mobile and web teams every day. Talk to us and get your first events flowing in under an hour.

Talk to an expert