Data handling
What the library touches, what it writes to the device, how long it keeps it, and what leaves. The short version: AppInspect has no backend, so nothing is ever sent to us — data leaves the device only when a person taps share.
This page is about the library. What the documentation site itself collects is in the privacy policy.
What it never does
AppInspect is a local tool, not a service. There is no account, no registration, and no infrastructure behind it.
- No network calls of its own. It observes the traffic your app makes and never originates a request.
- No telemetry of any kind — not usage, not crashes, not "anonymous" statistics about the inspector.
- No advertising or tracking SDKs bundled or transitively pulled in.
- No Logcat output of captured payloads, headers or crash traces.
- No modification of the requests your app sends. Response mocking changes only what your app receives back, on the device; a rule's matching conditions are filters, never transmitted data.
What it writes to the device
Everything below lives in your app's own private storage, inaccessible to other apps without root, and only in a build where the inspector is enabled.
| Data | Where | Kept |
|---|---|---|
| Captured requests and responses headers and bodies, up to the capture limit |
appinspect_storage.db — AppInspect's own app-private SQLite database |
300 most recent by default; oldest dropped |
| Crashes, ANRs and native crashes type, message, thread, full stack trace |
The same private database | 50 most recent by default |
| ANR bookkeeping which exit records have already been read |
appinspect_internal_state preferences file |
Until uninstall |
| Mock rules created in the panel | The same private database, plus a mirror file | Until deleted or cleared |
| Storage and WorkManager contents | Read from your app on demand — never copied or persisted by AppInspect | Not stored |
Both retention caps are configurable; see retention. The Storage panel excludes AppInspect's own database and preference files, so the inspector never shows you itself.
Encrypted preferences
EncryptedSharedPreferences files are decrypted for viewing using your
app's own on-device Keystore key. The decryption happens in the process and the
plaintext is never written anywhere — and those files are read-only in the
inspector, so an encrypted store cannot be edited or corrupted.
The mock rule mirror file
So that adb pull works without run-as, the current rule set
is mirrored to <external-files>/appinspect/mocks.json —
app-scoped external storage. It is removed when the app is uninstalled, and it is
never written on a build where mocking is not allowed; a build that cannot mock also
deletes any mirror an earlier install left behind.
It is app-scoped but not app-private the way internal storage is, so treat it like an export. And note that mock rules are developer-authored configuration: they are stored verbatim and are never redacted, so real credentials must not go into a mock response body.
What leaves the device
Only files a person deliberately shares. There is no automatic upload, no background sync, and nowhere for data to go.
- Network logs as
.txt(with cURL commands) or.har. - Mock rules as
.json. - Individual crash reports, and runtime summaries, through the Android share sheet.
Export files are written to cacheDir/appinspect_exports/ and handed out
through a non-exported FileProvider scoped to that directory
alone, with per-URI grants — it cannot be induced to serve any other
path. Files stay in the app cache until Android clears it or the app is uninstalled.
A network export contains the same Authorization headers, API keys
and cookies the original requests used — including ones your own code never
set, because request headers are recorded
as they went out on the wire. Redact
before attaching one anywhere. The
QA checklist is the procedure.
Device backups
In a debug build, if your app enables Android auto-backup, appinspect_storage.db
can be included like any other app file — and it may contain captured auth
headers. Exclude it in your backup rules if that matters to you. Production builds
have nothing to back up, because the file is never created.
Deleting it
- Clear inside the inspector removes captured data immediately.
- Clear runtime rules in the Mocks panel removes device-made rules.
- Uninstalling the app removes everything, including the mirror file.
In a production build, none of this exists
With the recommended setup there is no inspector, no database and no capture code in
the release APK at all. Even if the full library ships by mistake, it detects the
non-debuggable build and writes nothing: no appinspect_storage.db, no
internal state file, no mirror, no captured events. See the
security model for how both layers work.
For a vendor review or a Play Data Safety form
Google Play asks you to declare what every SDK in your app collects and shares. The answer here is unusually simple, and the reason is the build variant.
| Question | Answer |
|---|---|
| Is the SDK in the production app? | Not in the recommended setup — release builds get appinspect-no-op, which contains no inspection code. If it is not in the shipped APK, there is nothing to declare. |
| Does it collect data? | No. Collection means transmission off the device, and the library never transmits. |
| Does it share data with third parties? | No. There are no third parties and no network calls. |
| Is data encrypted in transit? | Not applicable — there is no transit. |
| Can a user request deletion? | Data is local to their device and is removed on clear or uninstall. |
| Who is the data controller? | You are. AppInspect never receives the data, so it is neither a controller nor a processor for it. |
If you do enable the library in a build you distribute more widely, treat it as you would any internal tooling: the data is on the tester's device, exports are the only way out, and the power tools decide what a tester can see in the first place.