Intermittent Database Inspector connection failures — Android Studio

Direct answer

Attribute the failure by where it stops in the Inspector sequence. If the app or device does not appear and no databases are listed, it is a target-discovery failure. If the database appears but the schema will not load, it is a connection-establishment failure. If the schema is browsable but a submitted query times out or returns a lock error, it is a query-execution failure. Database Inspector does not own a server connection pool. For a local on-device SQLite database there is no server-side pool to exhaust; pool metrics are relevant only if the app proxies Inspector traffic to a remote database.

Failure-mode distinctions

Failure mode	Visible symptom in Inspector	Likely layer
Target discovery	Device, process, or database list is empty; Inspector pane stays blank	ADB transport, debuggable flag, process lifecycle
Connection establishment	Database is listed, but schema fails to load; open, read, or decrypt error	File lock, permissions, encryption, app holding the database
Query execution	Schema loads, but SQL times out or returns a lock error	Contention inside the app or device, long transactions, WAL stalls

Pool metrics and logs to compare

For local SQLite, compare Inspector failure timestamps against app-side database logs for lock waits, busy timeouts, WAL checkpoint stalls, and long-running transactions. Skip server-side pool metrics; they do not apply to a local file. If the app proxies to a remote server, compare against active connections, waiting requests, acquisition timeouts, and rejected connections at the same timestamps. A generic Inspector failure alone is not evidence of pool exhaustion.

Second-client test

Open the same database file with a second independent SQLite client using identical read-only settings. If the second client succeeds while Inspector fails, the Inspector or ADB path is implicated. If both fail, the app or device database layer is implicated. Do not open the live file for write from both clients at the same time; that creates its own lock contention.

Recommended steps

1. Pin Android Studio, platform-tools, device API level, and the app database library; reproduce while capturing idea.log and logcat with synchronized timestamps.
2. Confirm whether the app exposes a local SQLite file or proxies queries to a remote database.
3. Correlate failure timestamps with app-side lock-wait, busy-timeout, or pool-acquisition logs.
4. Test with a second SQLite client under the same read-only conditions.

Missing diagnostic detail: Is the inspected database a local on-device SQLite file, or does the app forward queries to a remote database and connection pool? This determines whether server-side pool metrics are relevant at all.