Introduction
AppInspect is an Android library that adds a full-screen inspector to your own app. You add it as a Gradle dependency to your debug and internal builds; anyone holding the phone can then open it and see the network calls the app just made, what is stored on the device, which background jobs ran, the log it is writing right now, and the last crash or ANR — without a laptop, a proxy, or a cable.
AppInspect-Sample-App is a small runnable app whose only job is to show what this library does. Clone it, run the debug variant, tap a few buttons to make some traffic and a crash, and open the inspector. It is also the shortest reference for wiring the library into your own project — three files, all commented. The install page has the clone command.
The idea
Nearly every Android team eventually builds an internal debug screen: a list of recent API calls, a way to look at SharedPreferences, a button that dumps the last crash. It is useful, it is never anyone's priority, and it gets rewritten in the next app.
AppInspect is that screen, packaged as a dependency and kept out of your codebase. Because it lives inside the app rather than outside it, the person who found the bug is the person who can capture the evidence — on the build that actually failed, at the moment it failed.
What is inside the inspector
The inspector opens as its own full screen. Five panels sit along the bottom bar and you move between them by tapping or swiping; Runtime and Logcat are one tap away in the top bar, and any panel can hand an oversized value to a shared viewer. Each has its own page here, because knowing that a panel exists is not the same as knowing how it behaves when the value is 200 KB, encrypted, or missing entirely.
How this differs from a proxy
A desktop proxy such as Charles or Proxyman sees traffic from the outside. That is powerful, and it costs you a certificate on every test device, a Wi-Fi configuration, a machine on the same network, and a developer to run it. Android Studio's own inspectors need the device attached over adb.
AppInspect trades breadth for reach. It only sees what your app hands to the
OkHttpClient you instrumented — not WebView traffic, not another
HTTP stack, not other apps. In exchange, it works on any tester's phone with no
setup at all, and it can see things a proxy cannot: which coroutine wrote that
preference, what WorkManager did overnight, the stack trace of the crash that
happened before anyone could attach a debugger.
They are not exclusive. Plenty of teams keep the proxy for deep protocol work and use AppInspect for everything a tester needs during a normal test pass.
How it is put together
The library is published as several artifacts, but you normally depend on just one umbrella module for your debug builds and one stub for release. The rest are transitive.
| Artifact | What it is for |
|---|---|
appinspect | The umbrella dependency. Pulls in the UI, storage, network capture, WorkManager and crash modules, and auto-initialises. This is the one you add to debug, staging and internal-test builds. |
appinspect-no-op | The release stub. Mirrors only the OkHttp API surface so shared client code compiles, and does nothing at runtime. |
appinspect-api | Public contracts — AppInspectConfiguration, mock rule models, entry points. Comes in transitively. |
appinspect-ui | The inspector activity and its Compose screens. |
appinspect-network-okhttp, appinspect-storage, appinspect-insights-storage, appinspect-workmanager, appinspect-logs, appinspect-core | The capture and inspection implementations behind each panel. |
Snippets in these docs use <latest-version> rather than a
pinned number, so nothing here goes stale. Check
the versions page on Maven Central
for the current release. These pages track the latest published version, so if
something here does not match the artifact you resolved, check that you
are on the newest one.
It does not ship to your users
This is the first question most teams ask, so it is worth answering here rather than at the end. Two independent things keep the inspector out of production.
The recommended setup puts appinspect-no-op in your release variant,
so the inspector's code is never compiled into the production APK. And if the full
module ever ends up in a release build by mistake, it checks
FLAG_DEBUGGABLE at runtime and switches itself off completely —
no database on disk, no crash handler, no capture, every open()
refused.
The security model page covers both layers, what debug builds deliberately do expose, and the extra gates around response mocking. Builds and environments is the practical companion to it: which of your variants actually run the inspector, and what a staging build has to do to be one of them.