Security and data handling

Release builds are safe — two independent layers of protection.

AppInspect is a local library, not an external data service. It never uploads captured app data, sends zero telemetry, and writes nothing to Logcat. For production, two separate layers each guarantee on their own that no inspection happens in users' hands.

Integration guide Maven Central

Release safety

Two layers, either one sufficient on its own.

Layer 1 — Compile-time no-op

releaseImplementation("...appinspect-no-op") ships only a pass-through OkHttp interceptor.
No inspector UI, no storage, no network capture, no crash handler, no manifest entries — inspection code is absent from the release APK.
Shared OkHttp builder code compiles unchanged across debug and release variants.

Layer 2 — Runtime self-disable

Even if the full module accidentally ships in a release build, it detects the non-debuggable build and disables itself completely.
Never creates appinspect_storage.db on disk, never installs the crash handler or ANR collector, never registers sensors, notifications, or shortcuts.
The interceptor becomes a pure pass-through and all open() calls are refused.
Cannot be re-enabled at runtime — production requires the host to explicitly ship both allowInNonDebugBuilds = true and allowInProductionBuilds = true in the APK.

Hardening in every build type

No exported components — the inspector activity, startup initializer, and file provider are all exported="false"; nothing is reachable from other apps.
No network calls of its own — the library only observes the host's OkHttp traffic and never sends data anywhere.
No logging — captured payloads, headers, and crash traces are never written to Logcat.
Notifications show only method, status code, host, and path — never headers, bodies, or tokens.
Export sharing goes through a non-exported FileProvider scoped exclusively to cacheDir/appinspect_exports/ with per-URI grants.

Debug and staging builds are intentionally open

Auth headers, tokens, cookies, database contents, DataStore values, decrypted EncryptedSharedPreferences, and crash stack traces are visible inside the inspector — by design, for developer tooling.
Captured data stays on device in app-private SQLite with retention caps (300 network events, 50 crashes by default).
Distribute enabled builds only to trusted development, QA, and internal-test audiences.
Tune visibility for wider audiences with the levers in Configuration.

QA checklist

Share evidence carefully. Exports can carry real credentials.

Network exports are valuable for bug reports, but they include the same headers and tokens the original requests used. Treat them as internal security artifacts.

Before sharing TXT, HAR, or cURL output

Search for Authorization, Cookie, Set-Cookie, X-API-Key, and app-specific credential headers.
Replace token values with [REDACTED] before uploading to Jira, Slack, email, shared drives, or bug trackers.
Remove -H "Authorization: ..." flags from cURL commands copied into tickets or messages.
If an unredacted export was already shared, rotate the exposed token and ask the backend team to invalidate the session.

Good habits for enabled builds

Exports persist in app cache until Android clears the cache or the app is uninstalled.
Crash and ANR reports reveal package names, class names, methods, and line numbers — treat shared reports like source-adjacent artifacts.
If your debug build enables Android auto-backup, exclude appinspect_storage.db in your backup rules — it can contain captured auth headers. Production builds have nothing to back up.
For wider QA audiences, reduce what testers can see and change with the levers in Configuration.

Ready to integrate

Add AppInspect to your Android app in three steps.

Follow the integration guide to add the Gradle dependency, wire the OkHttp interceptor, and configure panels for your team.

Integration guide Maven Central