Storage Studio: an Android inspector that exposes its engine over REST and MCP

The library you knew, rebuilt as an application

The repository is the continuation of a 2017 project, and the README tells the story plainly. android-storage began as a small Java wrapper over java.io.File, its maintenance ended, jcenter died, and it was archived while Android moved on a decade of API levels. It returns now as an application called Storage Studio, with the library still shipping underneath, rewritten in Kotlin. The library is published as com.snatik:storage and is now a thin, typed Kotlin module rather than the product. The point of the project is now the app, and the app is built around a particular idea: everything it can do is exposed over an HTTP and MCP API so agents can drive the device directly. The primary language is Kotlin, the interface is Jetpack Compose, and the licence is Apache 2.0. There are no GitHub releases, and the last push was on 2026-09-24.

Fifty-four operations, a bearer token and two safety gates

The mechanism behind the screens is a local server, and the same operations are what an agent calls. There are 54 of them, reachable over REST at the path /api/v1/{op} and over MCP at /mcp, and the access is behind a bearer token. Two safety gates sit in front, one for shell tools and one for device changes, and both are off by default, with an audit log recording what happened. The point of the audit log and the disabled-by-default gates is that an agent running on your machine can do things a person would hesitate to do, so the tool makes the dangerous parts opt-in and visible. The transport is the familiar one:

adb forward tcp:8484 tcp:8484
curl -s localhost:8484/api/v1/apps -H "Authorization: Bearer $TOKEN"

Forwarding a port with adb is what makes the server reachable from the machine running the agent rather than only from the device, and the curl line is the shape of every call: an operation path, a bearer token in the Authorization header, and a JSON response. The example asks for the app list, which is one of the operations that needs no special access at all.

What it can read depends entirely on what you grant it

There is a capability table, and it is the most useful thing in the README. Browsing your own app directories, inspecting any APK, and listing apps and components need nothing at all. All of shared storage and the per-app storage sizes need a permission, namely MANAGE_EXTERNAL_STORAGE or usage access. Another apps' Android/data directories, the private files of debuggable apps, logcat, the pm, am and appops commands and dumpsys need Shizuku, which runs as a shell UID over ADB. Anything deeper, meaning any app's private /data/data, non-exported providers, partitions and swap, needs root. The design principle is stated as nothing being faked, with each capability honest about what it needs, and the app working at every tier rather than only with everything granted. That matters for anyone deploying it, because the tiers determine the security posture of the deployment, and the deepest tier is the one that gives an agent full read and write access to the device.

Shizuku is the tier that needs a ritual after every reboot

The Shizuku instructions are the part you will follow most often, so it is worth being precise about them. Enable wireless debugging in the developer options, then in the Shizuku app tap Start via Wireless debugging, and no computer is needed. The catch is that non-root Shizuku stops on every reboot, so you have to restart it after each restart, although the application already holds the grant and so reconnects on its own once Shizuku is back. There is one more wrinkle: the permission is tied to the app's signature, so you have to re-grant it once after switching between the debug and Play builds. That is a real operational tax on a permission model where most of the value sits, and it is the sort of detail that explains why the deeper features are opt-in rather than the default. The tier table also makes clear that what you gain by running Shizuku is not everything, since the private /data/data of arbitrary apps still requires root.

A file manager, a hex viewer and a camera RAW darkroom in one app

The feature list is long enough that it is worth sorting by what kind of work it is. Browsing and viewing give you a file manager with search, sort and thumbnails, plus viewers for code, JSON and XML trees, images with EXIF, video and audio, PDF and fonts, a binary inspector that reads hex, strings, magic byte types and protobuf, and a canvas renderer for Android vector drawables. Measure and reclaim gives per-app app, data and cache sizes, a drillable treemap and sunburst, and storage insights covering duplicates, empty directories, zero byte and ghost files, with a Time Machine that forecasts when storage will fill. Apps and APKs lets you open any APK without installing it, read the manifest, resources and signing information, decompile dex to Java, inspect ELF binaries, and force-stop, clear, uninstall or re-grant. And the photo features are the outlier, with a native LibRaw develop pipeline that edits Sony ARW files from the sensor with exposure, tone curve, HSL, presence and effects, exporting JPEG, 16-bit TIFF or an archival DNG, plus focus peaking, clipping warnings, histogram, deep EXIF and camera sync over Wi-Fi FTP, PTP or USB.

Reading the device's own data, and watching it move

Two feature groups are aimed squarely at people building or debugging apps. The first is reading the device's data: every content provider presented as a table with CSV and JSON export, a SQLite browser with a SQL console, editable shared preferences, a permission matrix and an app-ops timeline. The second is watching and recording: live monitors for intents, broadcasts, notifications, clipboard changes and provider changes, snapshot folders with diffing between them, and recording of logcat, broadcasts, file changes and the screen. For an agent, that is an unusually complete picture of what an application is doing, and for a human debugging a bug it is the kind of tooling that normally means a desktop application. The last group is aimed at developers and agents directly: build and send any intent, receive files over the network, and the agent API itself.

The old library survives as a typed Kotlin module

For anyone who depended on the 2017 library, the migration story is in a small block of code. The com.snatik:storage module exposes a Storage class, and every operation returns a Result with a StorageException on failure. The calls block, so the documentation is explicit that you should wrap them in withContext(Dispatchers.IO), which is the one piece of advice that matters most if you move it onto the main thread by accident:

val storage = Storage(context)
val file = "${storage.externalStorageDirectory}/notes.txt"
storage.createFile(file, "first line")
storage.appendLine(file, "second line")
storage.readTextFile(file).onSuccess { println(it) }

// AES-256-GCM, hardware-backed key that never leaves the device
val secure = Storage(context, Encryption.fromKeystore("my-files"))

The encryption constructor takes a keystore-backed key, and the scheme is AES-256-GCM with a fresh random nonce per file, so identical content never produces identical bytes on disk. That requires minSdk 28. The change from the old wrapper is mostly in the type signature: errors are returned rather than thrown, so a caller has to handle them explicitly, and the operations are grouped into a coherent module rather than a scattering of static helpers.

A core module that both the UI and the agent API call

The architecture is the reason the API exists rather than being bolted on. Everything the user interface can do is reachable from the core module, and the HTTP and MCP endpoints call into that same core, so an agent and a human are working with the same implementation. The core is split by concern: core/fs for the file system abstraction, volumes, operations and the disk scanner, core/apps for package inspection and the binary XML decoder, core/data for provider queries, the SQLite inspector and the preferences codec, core/intents for the intent model, the sender, the broadcast monitor and the deep link parsers, core/capture for the Room database, snapshots, diffs and the recording engine, core/net for the Ktor server, peer discovery and the transfer client, and core/shell for the privilege layer, which is a ShellExecutor with plain, Shizuku and root backends. That last one is the abstraction that makes the tier table work, because the same operation runs at three privilege levels. The app layer is Compose only, with Navigation 3, Koin and Coil, and the Shizuku binder is hand-written Kotlin with no AIDL and no generated Java, which is an unusual choice worth knowing about if you were expecting a generated binding.

Building from source is one Gradle command, but the requirements are specific. You need JDK 17 or newer and the Android SDK platform 37:

./gradlew :app:installDebug

Installing the debug build straight onto a connected device is the intended path, and it fits the rest of the design, since a debug and a Play build differ by signature and the Shizuku grant has to be re-given after you switch between them. The repository root holds the usual Android project files, build.gradle.kts and settings.gradle.kts alongside the gradle wrapper, a gradle.properties, a keystore.properties.template for signing, a CHANGELOG, and the app, core, storage, docs and tools directories, and the roadmap is kept in docs/PLAN.md. With no GitHub releases, the version you build is the version in the repository rather than a tagged artefact.

Editorial conclusion

Storage Studio suits a developer who wants to poke at a device, an agent that needs an HTTP and MCP surface onto Android rather than adb scripting, or a team that wants a maintained replacement for the archived com.snatik:storage library. It does not suit a user who just wants a file manager, since the extra reach depends on grants most ordinary users will not give. Before you install it, work out which tier you actually need, because the capability table ties the deepest features to root, and if you use Shizuku remember that it stops on every reboot and has to be restarted by hand.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. sromku/android-storage on GitHub