DbInspector: browsing an Android app's database from inside the app

What the library does

DbInspector provides a simple way to view the contents of the in-app database for debugging purposes, and the sentence that sells it comes next: there is no need to pull the database from a connected device.

That removes a familiar routine. The traditional way to look at an Android app's SQLite database on a device is to run the app, use adb to copy the file out of the app's sandbox, and open it in a desktop tool, and to repeat that every time the data changes. An in-app browser shows the current state immediately, on the device, with the same data the app itself is reading.

The library also supports inspecting the SQLite databases created by CouchBase Lite out of the box, which is a specific compatibility promise for a specific mobile database, and the topic list names couchbase and couchdb alongside sqlite and sqlite3.

The capability list in the README is the full scope, and it is worth reading because it defines the tool's edges as clearly as its centre. You can preview all the application sandbox databases. You can import single or multiple databases at once. You can search, delete, rename, copy and share a database. You can preview tables, views and triggers. You can preview a table or view pragma. You can delete table contents. You can drop a view or a trigger. You can search a table, a view or a trigger. You can sort a table, a view or a trigger per column. And you can execute any valid SQL command in the editor, per database connection.

That last item is the important one, and it is also the one that defines the risk. The editor is not a read-only viewer with a limited query language, it is a SQL console against the app's own data, in a debug build, on a device a developer is holding. Anything the app can do to its database, a person with the device can do to it as well.

The library is written entirely in Kotlin, and the README notes that it also works with Java only projects and all combinations of both, which is the kind of statement that matters in an Android codebase that is halfway through a migration.

The editor, and the statement history that survives a restart

The editor section describes a component scoped per database connection, and then lists what it actually does.

There is autocomplete of SQLite3 keywords and functions, and of the current table and column names, which is the second half that matters: knowing the function names is a convenience, and knowing the column names of the table you are looking at is what stops you writing a query that fails because of a typo in a column.

There is a history of executed statements, and the README is careful to say it does not matter whether they were successful or not, which is the right call. A history that only recorded successes would hide the queries that failed, which are the ones you want to look at again. The history of statements is persisted between sessions and can be cleared on demand at any point, so a developer can carry a set of exploratory queries from one run of the app to the next.

The panes between the editor input and the result are scalable and can be adjusted by dragging the splitter between them, and landscape mode is supported for a better preview of large datasets, which is a small detail that indicates the tool is used on a phone where a result set with a hundred columns is a real scenario.

The separate logging mechanism is a nice touch, and it is described as independent and built in. By default the logger is initiated as an EmptyLogger, omitting any output whatsoever, and where logs are required the AndroidLogger should be used:

DbInspector.show(logger = AndroidLogger())

The AndroidLogger uses a Level to filter between info, debug, error or no messages at all. The default of silence is the right default for a debug tool that otherwise sits in the log of an application, and having the level as a parameter rather than a global setting means it can be turned on for the case where the inspector itself is misbehaving.

The two artifacts, and why the release build gets a different one

The installation section is short and the arrangement is the thing to understand.

First the buildscript repositories, which in Gradle means adding mavenCentral in the Groovy or Kotlin DSL form, and then the dependencies themselves:

debugImplementation("com.infinum.dbinspector:dbinspector:6.0.0")
releaseImplementation("com.infinum.dbinspector:dbinspector-no-op:6.0.0")

Two artifacts at the same version, one on the debug configuration and one on the release configuration. The real one carries the inspector; the no-op one carries nothing that does anything. The release build therefore contains a stub in place of the library, so a database browser cannot end up in a shipped application because someone changed a build variant by accident.

That is a better pattern than the alternative of relying on a debug-only source set, and it is enforced by the type system of the build rather than by convention. The cost is that the API surface has to exist in both artifacts, so DbInspector.show() has to compile in a release build even when it does nothing, and the no-op artifact is a second thing to keep in step when the API changes.

The requirements section sets the floor. The minimum required API level to use DbInspector is 21, known as Android 5.0, Lollipop. As of the 4.0.0 version, AndroidX is required, and the README advises keeping the previous version if you cannot migrate your project to AndroidX, which is a sensible and now dated piece of advice for anyone on an old codebase.

Manifest merging, the launcher icon and how to keep it out of the way

DbInspector can be invoked explicitly or implicitly, and the implicit route is the one with the interesting mechanics.

Explicitly, you call DbInspector.show() anywhere you like, in an onClick handler or a lambda:

DbInspector.show()

Implicitly, when you add the dbinspector package, an Activity alias is automatically merged into your application manifest, and that alias creates a launcher icon for DbInspector. Add the dbinspector-no-op artifact instead and the same alias node is removed from the manifest. In other words, the launcher icon is a side effect of the artifact you depend on, which is the same guarantee as the code itself, expressed in the manifest rather than in the build logic.

If you use the real package but do not want the extra launcher icon, you remove the alias yourself with a manifest merge directive:

<!--suppress AndroidDomInspection -->
<activity-alias
    android:name="com.infinum.dbinspector.DbInspectorActivity"
    tools:node="remove" />

The suppression comment is required, because the Android lint inspection flags a manifest node you have deliberately removed, and the README asks you to copy it over. Further modification follows the rules of manifest merging and of the activity-alias XML node, both of which are linked.

There is one more case, which is a per-flavour launcher label. If you use DbInspector for a specific flavor and need to override the merged-in launcher label, you provide a string resource in your project:

<string name="dbinspector_launcher_name">Sample Debug</string>

This is the kind of detail that only exists because a real team needed it, a debug flavour whose inspector icon should not be called the same thing as the production one.

The engineering around the library

The repository layout shows a project built like a real Android library rather than a sample project, and it is worth reading for the parts that tell you how the code is maintained.

There are two Gradle modules, dbinspector and dbinspector-no-op, and the build configuration is split across several files, with build.gradle for the module, config.gradle, detekt.gradle for the static analysis, dokka.gradle for the API documentation, maven.gradle for the publishing setup and deploy.gradle, plus a buildSrc directory for shared build logic and a settings.gradle and gradle.properties. There is a sample directory with its own build.gradle, a dummy.jks keystore and proguard rules, so the project can be built and installed as a demonstration.

The static analysis choice is detekt, which is the Kotlin linter, and the documentation generator is dokka, the Kotlin documentation tool, which is the right pairing for a library whose public API is Kotlin. renovate.json keeps the dependency versions current automatically, and the CI workflows are visible in the badge row: a workflow that validates the Gradle wrapper, which checks that the wrapper JAR in the repository matches the expected checksum, a code analysis workflow, and a CodeFactor badge plus a codecov coverage report.

The Gradle wrapper validation is the one worth pausing on, because it is the check that stops someone from pushing a modified wrapper, and the wrapper is the thing that decides what code runs during the build. A library whose whole purpose is to look at data in an app is a reasonable target for a supply chain attack, and the project ships a SECURITY.md and the wrapper check, which is a proportionate response.

The coverage badge is on the master branch and the project publishes to Maven Central under the com.infinum.dbinspector group, with the download badge in the README header showing the current version.

Licence, releases and the judgement to make

The licence is the Apache License 2.0, with the full text in the README and in the LICENSE file at the repository root, and the copyright held by Infinum, the company that also sponsors and maintains the project. This describes the published terms rather than legal advice.

The release record shows a long gap followed by a jump. Version 5.4.9 was published on 2022-10-21, 5.4.8 on 2022-08-05, and 6.0.0 on 2026-02-09. The repository is not archived and the last push was on 2026-10-15, so the 6.x line is the active one and the earlier 5.x line sat untouched for more than three years.

That history is a fair proxy for the audience. A debugging tool for in-app databases is a library that teams adopt, use heavily for a while and then rarely touch, and the version numbers say the 6.0.0 release was a modernisation rather than a feature push, since the 4.0.0 note in the README is the same kind of event, the move to AndroidX.

The judgement is mostly about the security posture, because that is the part a careful team should reason about rather than assume. This tool executes arbitrary SQL against the application database, on a device, in a build that is, by definition, a debug build. The no-op artifact and the manifest merge are the project's answer to keeping it out of production, and they are good answers, but they depend on the build configuration being right. The failure mode is quiet: if a variant misconfiguration ships the real artifact, the application gains a launcher icon and a database browser, and nothing crashes.

For everything else, the case for it is straightforward. It removes the pull-the-database-off-the-device loop from a developer's day, it supports the Couchbase Lite flavour of SQLite that some apps use, and it gives a developer a real SQL editor on the device rather than a table dump they have to export and open elsewhere.

Editorial conclusion

Adopt DbInspector when you work on an Android app with a local database and want to inspect it on the device without a cable, a run-as dance and a desktop SQLite tool, since the in-app browser removes the whole export step. It is the wrong tool for a remote or server-side database, and it is the wrong tool if you are unwilling to keep the no-op artifact wired into your release build, because shipping the inspector in production is a mistake you should design against rather than remember to avoid. Before adopting, check your build variants, since the debug and release configurations have to reference different artifacts, and read the security policy in the repository, since a tool that exposes raw SQL against app data deserves one.

Frequently asked questions

Official sources

1. infinum/android_dbinspector on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases