ByteScope

Android Storage Analyzer

Find what is eating your phone's storage — over a USB cable, with adb's access instead of a cleaner app's.

Every size on this page is measured by the phone and read over the USB cable. No file, filename or listing is uploaded.

Checking browser support…

About this tool, FAQ and related tools

About this tool

Plug an Android phone into a Chromium browser over USB and this page measures where its storage actually went. It reads dumpsys diskstats for the whole-volume breakdown (apps, app data, cache, photos, videos, audio, downloads, system), joins the per-app sizes with pm list packages so every row says whether it is a system app or one you installed, runs du over /sdcard and draws it as a squarified treemap you can drill into, and offers four separate scans: large files, leftover APKs in Downloads, empty folders, and how many gigabytes of screenshots you have been carrying around. Nothing is installed on the phone and nothing is uploaded — the sizes are measured on the device and read back over the cable.

Why adb sees more than any cleaner app can

This is not a matter of convenience, it is a matter of permissions, and it is why the storage cleaners on the Play Store have quietly stopped working. CLEAR_APP_CACHE — the permission needed to clear *another* app's cache — has been privileged since Android 6, so no installed app can free your cache for you any more. Scoped storage means an app cannot list /sdcard/Android/data, which is exactly where uninstalled apps leave their leftovers behind, so the orphaned-data scan that SD Maid was famous for is simply not available to an app in 2026. And no third-party app can remove a preloaded one. An adb shell runs as the shell user with none of those restrictions: it reads the framework's own accounting, walks shared storage, and can act on what it finds. The browser is only the UI — the access comes from ADB.

What the numbers mean, including where they disagree

dumpsys diskstats has two halves that come from different places, and this page never blends them. The capacity and free-space figures are live StatFs calls. The category sizes and the per-app sizes come from diskstats_cache.json, which Android rewrites roughly once a day — so on a phone that was just flashed or just rebooted, that half does not exist yet, and on any phone it is up to a day stale. The two therefore never add up exactly. The difference is shown as its own labelled band when used space exceeds the categories, and as a note when the categories claim more than the volume says is used. Nothing is rescaled, clamped or quietly rounded to make the bar look tidy. The same rule governs the rest: a du that hit a permission denial reports the denial, a per-app section whose arrays came back mismatched shows an explanation instead of a plausible-looking table, and the orphan scan refuses to produce a list at all when the package list it would compare against is incomplete.

Deleting is deliberately a separate step

Removing things is a different kind of operation from measuring them, and it is built accordingly. Deletion only ever works on paths a scanner found — there is no box to type a path into, and there cannot be one: the internal value that authorises an rm can only be produced while parsing a scan's output. Every removal prints the exact list first, twice, and then re-reads every path on the phone immediately before acting: if one file's size or timestamp moved since the scan, the whole run is cancelled rather than partly applied. Each path is then removed with its own command so the result is reported per file — deleted, refused with the phone's own words, or already gone — because a batch that reports one status for forty files cannot tell you which one survived. Android has no trash can and ADB has no undelete, so what goes is gone; the restore centre lists what this browser removed and says plainly that these operations have no cure.

Coming from the other direction: the Web ADB Toolkit hub is where the device dashboard and the rest of the tools live, and the APK Analyzer inspects an installer's permissions and size before you commit to installing it.

Frequently asked questions

Why can't a cleaner app from the Play Store do this?

Because Android took the permissions away. Clearing another app's cache needs `CLEAR_APP_CACHE`, which is privileged and not grantable to a normal app. Listing `/sdcard/Android/data` — where uninstalled apps leave data behind — is blocked by scoped storage. Removing a preloaded app is impossible for a third-party app entirely. An `adb shell` has none of those limits, which is why this works from a cable and not from an install.

Do the category sizes and the free space have to add up?

No, and on a real phone they never do. Free space is measured live; the category and per-app sizes come from a cache Android rewrites about once a day. This page shows the difference as its own band (or as a note when the cache claims more than the volume reports as used) rather than rescaling the segments to fit. A phone that was just flashed has no cached half at all, and the page says so instead of drawing an empty bar.

Can it scan /sdcard/Android/data for orphaned app data?

It tries, and it tells you what happened. Whether `adb shell` can list that directory varies by Android version and by manufacturer, so the page reports each of the three areas separately: listed, listed but empty, or could not be listed. An empty-but-readable listing is flagged rather than reported as "nothing to clean", because on Android 11+ that is what a restriction looks like from the outside.

Does anything get deleted automatically?

Nothing runs on its own — not a scan, and certainly not a deletion. The `du` pass and each of the four `find` scans run when you press their button, because they walk tens of thousands of files and that costs the phone battery and responsiveness. Ticking a finding builds a list and sends nothing. Deleting takes a separate press, an exact list of every path, an acknowledgement you have to tick, a two-second pause, and a fresh re-read of every path on the phone that cancels the run if anything moved since the scan. The one thing that runs on a single press is `pm trim-caches`, which asks Android to drop cached files it already considers disposable; no app data is touched and nothing is lost.

Which browsers and phones does this work with?

Chrome or Edge on a desktop, because WebUSB is Chromium-only; Firefox and Safari cannot open a USB device at all. The phone needs USB debugging turned on in Developer options, and on Windows its ADB interface usually needs the WinUSB driver installed with Zadig — the page walks you through that if connecting fails. macOS, Linux and ChromeOS need no driver.

Is the treemap usable with a keyboard or a screen reader?

Yes — the canvas is never the only representation. The same `du` data is also a real table with a button per folder, so every rectangle is reachable by tab and readable by a screen reader, and the breadcrumb is a row of buttons. The list view is the default on narrow screens, where treemap cells would be too small to tap, and the page counts and reports how many cells fall under that size.

  • Web ADB Toolkit

    The device dashboard and the rest of the ADB tools.

  • APK Analyzer

    Inspect an APK's permissions and size before you install it.