QA checklist

Everything on this page is about one risk: a network export is one of the most useful things you can attach to a bug report, and it contains live credentials. This is a short, practical routine for handling that — written for whoever is actually filing the ticket.

Why an export is sensitive

A TXT, HAR or cURL export reproduces the request faithfully, which is exactly why it is worth attaching — and it means the Authorization header, the API key and the session cookie come with it. A cURL command always carries the token the original request used; paste it into a terminal and it authenticates.

There is a subtler version of the same problem. Captured request headers are read off the wire, so an export can contain credentials your calling code never set — added by an auth interceptor, a token refresh, or the cookie jar. "My code doesn't attach a token to that call" is not a reason to skip the check.

Before you attach an export

1. Search the file for Authorization, Cookie, Set-Cookie, X-API-Key, and whatever credential headers your own API uses.
2. Replace the values with [REDACTED] — the header name is useful to whoever debugs it, the value never is.
3. Strip -H "Authorization: …" from any cURL command you paste into a ticket or a chat message.
4. Check where it is going. An internal ticket is not the same as a shared drive, a vendor's support portal, or a screenshot in a group chat.

Habits for a build that has the inspector

• Export files linger. They stay in the app's cache directory until Android clears it or the app is uninstalled. They are not world-readable, but they are still there.
• Crash and ANR reports are source-adjacent. They name your packages, classes, methods and line numbers. Treat a shared report like a code excerpt.
• Mock rule sets are shareable artifacts too. Review a rule set before committing it, and keep real credentials out of mock response bodies — rules are stored verbatim and are never redacted.
• Exclude AppInspect's database from auto-backup if your debug build enables it. appinspect_storage.db can contain captured auth headers. Production builds have nothing to back up.
• If a response looks impossible, check for a mock. A MOCK badge on the row, an amber notification, or a Mock: line in a TXT export all name the rule that fired. This has cost people a whole afternoon more than once.

Handing the build to people outside the team

The checklist above is a process control. When a build is going to a wider audience, reduce what is exposed in the first place instead of relying on everyone remembering it: mask sensitive values before they are stored, make storage read-only, hide the panels that audience does not need, and turn off response mocking.

There is a ready-made profile for exactly this on the configuration reference.

Two questions worth asking once

Who can install this build? If the answer is "anyone with the link", the inspector should be configured down before that link exists.

Where do our tickets live? If your issue tracker is readable by contractors, vendors or the whole company, redaction is not optional — it is the only control between an export and a much longer conversation.