AppInspect
On this page
Configuration

Configuration reference

The defaults assume a developer holding the phone: everything visible, everything editable. That is the right default for a debug build and the wrong one for a build you hand to twenty external testers. This page is the single list of what you can change and what each switch actually does.

Changing something: use updateConfiguration

There is one thing to understand before any of the fields below matter. AppInspect has already configured itself by the time your Application.onCreate() runs — it installs from AndroidX Startup, which runs earlier, and part of what it worked out there is which build tier this variant is. So any call you make is a re-configuration, and there are two ways to make one.

DebugApplication.kt (debug source set)
// Changes only what you name, and keeps everything AppInspect inferred.
AppInspect.updateConfiguration { configuration ->
    configuration.copy(
        panels = AppInspectPanels(mocksEnabled = false),
        powerTools = AppInspectPowerTools(showRawSensitiveValues = false),
    )
}
install() replaces the whole configuration

Passing a fresh AppInspectConfiguration() to install() discards the enablement and environment AppInspect inferred — including a non-debuggable staging variant's resource opt-in, which switches the inspector back off in exactly the variant that needed it. Use install() when you deliberately want to own build-tier policy too, and then set enablement explicitly. Otherwise use updateConfiguration.

Either call belongs in a debug-only source set, because neither exists in appinspect-no-op — see install. Registered metadata, metadata providers and redaction rules survive an install(), so handles you are holding stay valid. AppInspect.initialize(configuration) still works and is kept for compatibility.

AppInspectConfiguration is a group of small objects rather than one flat list of flags: enablement, entryPoints, panels, powerTools, logs, retention, environment, initialMetadata, redaction and branding. Each group below covers one of them.

One useful consequence of the ordering: if a configuration change is what enables AppInspect for the first time, persistence and the default metadata providers are brought up at that point — so it gets a real database rather than the in-memory fallback the disabled install created.

Enablement — whether it runs at all

This is the outermost gate, and it is checked independently of which artifact you depended on. It is why the runtime self-disable described in the security model works.

You probably do not need these fields

The normal way to enable a non-debuggable staging or QA build is the opt-in resource — one line in the build type, no host code, and it cannot leak into your release variant. These fields exist for the unusual case where you want to own the policy in Kotlin.

allowedBuildTiersdefault: DEBUG only
Which build tiers may run the inspector. A LinkedHashSet of AppInspectBuildTier values, so linkedSetOf(AppInspectBuildTier.DEBUG) is the default shape.
allowInNonDebugBuildsdefault: false
Required before the library will run in a build where FLAG_DEBUGGABLE is not set — a release-signed staging build, for example.
allowInProductionBuildsdefault: false
A second, separate opt-in for production. Both this and allowInNonDebugBuilds have to be shipped as true in the APK before the inspector can run for real users. There is no way to flip either at runtime, and the resource opt-in cannot reach this one.

AppInspect.setEnabled(...) is ANDed with the tier check rather than substituted for it, so it can turn an enabled build off — useful for a kill switch in your own debug menu — but can never turn a disallowed tier on.

If you enable a non-debuggable build

Turn response mocking off in the same commit (allowResponseMocking = false). A shared staging build that can rewrite live traffic is a support incident waiting to happen.

Entry points — how it opens

Each of these can be switched off independently, which is how you hand over a build without advertising that the inspector exists. Opening the inspector covers the behaviour of each one.

shakeToOpenEnableddefault: true
Open on a deliberate shake.
shakeThresholdGravitydefault: 2.7f
Total accelerometer magnitude, gravity included, that counts as a shake. Lower for a lighter shake; values below about 1.5 g are floored.
shakeCooldownMillisdefault: 1500
How long shakes are ignored after one is accepted.
launcherShortcutEnableddefault: true
Register a dynamic launcher shortcut that opens the inspector from the home screen.
autoOpenOnLongPressTriggerdefault: true
Whether an accepted long-press trigger opens the inspector immediately, or only reports the gesture so you can confirm it yourself.
networkNotificationsEnableddefault: true
Post a notification per captured call. Worth turning off when lock-screen visibility is a concern, or when the build goes to testers who would find it noisy. See Network notifications.
openInSeparateTaskdefault: true
Open the inspector in its own task, so it gets a separate Recents card and can be used in split-screen next to your app. Set to false to open it stacked in the current task.

Panels — what appears

All default to true. Hiding a panel removes it from the UI; it does not by itself remove the underlying capability, which is what the power tools below are for.

networkEnabled
The Network tab.
mocksEnabled
The Mocks tab. Visibility only — whether a rule can actually replace a response is allowResponseMocking. A build can therefore show the panel but be unable to mock, or hide the panel while a committed mocks.json keeps working.
storageEnabled
The Storage tab.
workManagerEnabled
The Work tab.
crashesEnabled
The Crashes tab. Turn it off for an audience that should not be reading stack traces.
runtimeEnabled
The Runtime button in the top bar — Runtime is not a bottom-bar tab.
logsEnabled
The Logcat button in the top bar. Off means the terminal icon disappears and no capture is ever started — there is no separate capability flag, because reading the log is all the panel does.

Power tools — what can be seen and changed

These are the switches that matter when the build leaves your desk. All default to true, because the default audience is a developer debugging their own app.

showRawSensitiveValuesdefault: true
When false, configured headers, query parameters, body fields, cookies and metadata keys are masked or removed before they are stored — not merely hidden in the UI. Which keys count as sensitive comes from the redaction group.
allowSharedPreferencesEditingdefault: true
Write access to SharedPreferences. Off means the panel is a reader.
allowDatabaseEditingdefault: true
Structured row editing in host databases.
allowSqlConsoledefault: true
The free-form SQL console.
allowResponseMockingdefault: true
The master capability for response mocking. When false, no rule can replace a response no matter what mocks.json or the in-app switch says, and the adb-pullable mirror file is never written.

Logs — how much of the tail is held

AppInspectLogsConfig bounds memory and nothing else, because Logcat capture never touches disk and only runs while the page is open.

bufferSizedefault: 2000
Entries held in memory before the oldest are evicted; clamped to 100–20,000. The default costs well under a megabyte. Raise it when you are chasing something that happens minutes before you notice it.
initialBacklogLinesdefault: 1000
Lines replayed from Android's own log buffer when the panel opens, so it never starts blank. The device buffer is itself finite, so asking for more than it holds simply returns what is there.
maxMessageLengthdefault: 8000
Per-message character cap, so one enormous stack trace or pretty-printed body cannot consume the whole budget. A truncated message says so.
redactSensitiveValuesdefault: null
null follows showRawSensitiveValues, so a build that already masks sensitive values does not start leaking them through logs. Set it explicitly to pin the behaviour. It is the initial state of the panel's Redact toggle, which stays live and also governs exports.

Retention — how much is kept

Captured events live in AppInspect's own app-private database with a cap; the oldest are dropped once it is reached. The defaults are 300 network events and 50 crashes. Raise them if you are chasing something intermittent over a long session, lower them if you would rather keep less of it around.

Environment and metadata

environment and initialMetadata are how your own details get into the Runtime panel — which backend this build points at, which release train it belongs to, which flag cohort the session is in. They are displayed as-is and never leave the device.

Redaction

The redaction group defines which keys are treated as sensitive when showRawSensitiveValues is false — header names, query parameters, body fields and metadata keys. Extend it with anything your own API uses that is not a standard credential header.

The same rules mask log lines, where they have to work on unstructured text: a single line can carry a header, a JSON body and a query string at once, so scopes are ignored there and matching is best-effort on key=value-shaped text. A value printed with no key beside it cannot be caught.

Redaction does not apply to mock rules

Rules are configuration a developer wrote, so they are stored exactly as written, in the internal database, in your mocks.json and in the mirror file. Keep real credentials out of mock response bodies.

Two profiles worth copying

A developer's own build

This is the default, and there is nothing to write. Everything visible, everything editable, mocking available, notifications on, logs unredacted.

A build that leaves your desk

Anything going to a wider QA, business or external-tester audience wants the opposite defaults: read-only, quieter, unable to rewrite traffic, and masking credentials before they are stored — while still capturing everything a good bug report needs.

A controlled QA profile
AppInspect.updateConfiguration { configuration ->
    configuration.copy(
        entryPoints = AppInspectEntryPoints(
            shakeToOpenEnabled = true,
            launcherShortcutEnabled = false,
            networkNotificationsEnabled = false,
        ),
        panels = AppInspectPanels(mocksEnabled = false),
        powerTools = AppInspectPowerTools(
            showRawSensitiveValues = false,
            allowSharedPreferencesEditing = false,
            allowDatabaseEditing = false,
            allowSqlConsole = false,
            allowResponseMocking = false,
        ),
        logs = AppInspectLogsConfig(redactSensitiveValues = true),
    )
}

Note what is not in there: nothing about build tiers. Because this uses updateConfiguration, the same code is correct in a debug build and in a staging variant that opted in through the resource — the tier AppInspect worked out for the build is left alone.

Defaults at a glance

  • Everything is on with no configuration at all — panels, entry points, crash capture, notifications, logs.
  • Raw sensitive values are visible in an enabled build.
  • Build-tier gating decides whether the library runs at all, regardless of configuration.
  • Production is opt-in and off, and needs two separate flags shipped in the APK.
  • WorkManager inspection is read only and cannot be made writable.
  • SharedPreferences and host database editing are on, and configurable.
  • Log capture is in-memory only, on demand, and limited to your own process.