Docs

Android 17 Certificate Transparency Tracking Impact

Android 17 enforces certificate transparency by default, breaking the debug proxies teams use to verify analytics SDK calls actually fire.

Analytics

Android 17 turns on certificate transparency (CT) enforcement by default for every network connection, once an app targets API level 37 or higher. It’s a genuine security win — the OS now checks that the certificate behind a secure connection has been publicly logged, closing off forged or tampered certificates of the kind used in some corporate monitoring setups and man-in-the-middle attacks. For most production API traffic this changes nothing visible. For the analytics and QA workflow sitting behind it, it changes a lot.

Teams commonly verify that an analytics SDK is actually firing the events it claims to by routing device traffic through a debug proxy — Charles, mitmproxy, Proxyman — so a human can see the raw request hit the wire. That workflow relies on installing a proxy’s root certificate on the test device and trusting it for TLS interception. CT enforcement doesn’t recognise that certificate as publicly logged, so on a CT-enforcing Android 17 device those intercepted connections start failing outright, not silently degrading. QA teams who haven’t touched their instrumentation see analytics calls appear to break overnight, chase a phantom SDK regression, and lose time before anyone traces it back to the OS update rather than the code.

Data Points to Track

  • CT enforcement status per test device and per build, since the failure only appears on devices running Android 17 with a target SDK of 37 or higher — older devices and lower target SDKs won’t reproduce it
  • Analytics call success/failure rate split by debug-proxy presence, so a real regression doesn’t get masked by proxy-induced failures or vice versa
  • Which domains have an explicit CT opt-out in the network security config, mapped against every analytics, crash-reporting, and third-party SDK endpoint the app talks to
  • Certificate chain and CT-log verification errors surfaced by the OS, logged distinctly from generic network failures so they’re diagnosable without re-running a repro
  • QA environment parity — whether staging/debug builds share the same network security configuration as production, since a config that only exists in one build hides the problem until release

Setup Steps

  1. Audit every analytics and third-party SDK domain your app calls and confirm whether it needs a CT opt-out entry in a custom network security configuration for debug builds specifically — production traffic to public, properly-logged certificates needs no change.
  2. Add a debug-build-only network security config that opts test-proxy domains out of CT enforcement, rather than disabling CT app-wide, so the QA workflow is restored without weakening the security posture that ships to users.
  3. Re-validate your debug-proxy verification workflow on an Android 17 device before assuming it still works — don’t wait for a QA engineer to report “analytics stopped working” and diagnose from there.
  4. Log CT and certificate-chain failures with a distinct error code in your crash/network monitoring, separate from generic connectivity failures, so a real production TLS issue isn’t buried under expected debug-proxy noise.
  5. Document the opt-out scope for every domain added to the network security config, since an overly broad global opt-out silently reintroduces the MITM risk CT enforcement exists to close.

Actionable Insights

If analytics failure rates spike only on Android 17 devices and only in QA or internal-testing builds, that’s almost certainly the debug-proxy interaction, not a genuine SDK regression — check the network security config before touching instrumentation code. If the same failure pattern shows up in production crash data on Android 17 devices, that’s a real problem: either a legitimate SDK endpoint isn’t serving a CT-logged certificate, or a corporate/carrier network is intercepting traffic in a way the OS now correctly refuses. And if staging and production builds show different CT-related error rates for the same domains, that’s a build-configuration gap worth closing before it hides a genuine issue behind “it works in staging.”

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