08 What this cannot do
Read this before you believe any recovery claim, including ours.
It cannot undelete files without root
This is the single most important limit in the product.
On a modern Android phone, an app installed from the Play Store cannot read the raw storage blocks. It cannot see a deleted file's data, because the filesystem does not hand out raw blocks to ordinary apps. Without root, the app can reach the media database, the file listings and the thumbnail cache. It cannot reach the disk.
That gap produces the classic disappointment in this category. A tool reports a large amount of recoverable video because it can read database entries, the user pays, and the exported file turns out to be a small fragment, because only the database entries and cached thumbnails were ever readable. Nothing changes between the report and the export; the reported size was never readable. This project cannot verify any particular tool's internal behaviour, so treat this as the mechanism to watch for rather than as an accusation against a named app.
The app states its own scope in Settings > About: storage access is the Storage Access Framework only, there is no all-files permission and no root, it recovers what the filesystem still exposes as a file, and it does not claim to undelete.
What that means in practice:
- Undelete and raw carving are not features of this app. They are not promised on an unrooted device and they are not hidden behind a switch.
- The app never shows a recoverable size or count that it has not actually read. If you see one, treat it as a defect.
- Deleted files that were never indexed in the media database are invisible to this app, whatever other products claim.
It cannot recover data that has been overwritten
Once new data is written over the blocks a file used, the original bytes are gone. Deleting other files, taking new photos, installing apps, or letting the phone do background updates all reduce what is left. No tool recovers overwritten data, with or without root.
If the file matters: use the phone as little as possible, do not factory reset it, and do not install more apps than you must.
What the app can reach, and what it does not attempt
The Android app reads only through the folder you grant in the system picker:
| Access path | In this app? | What it reaches | What it cannot reach |
|---|---|---|---|
| Storage Access Framework folder grant (persisted) | Yes - the only access path | Any file inside the granted folder, including broken leftover .pending files beside finished recordings |
The internal storage root, Android/data/, Android/obb/, and anything outside the grant |
All-files access (MANAGE_EXTERNAL_STORAGE) |
No. Not declared in the manifest and not offered | Would add read/write across shared storage | Would still not reach other apps' app-specific directories under Android/data/ (Google states this explicitly); raw storage blocks; the Gallery recycle bin is not guaranteed |
| Shizuku (shell-level privileges via wireless debugging) | No. Not part of this app | Would depend on the device, Android version and vendor | Raw storage blocks; not guaranteed on any given phone; the recycle bin is not guaranteed |
| Root | No. Not part of this app | Raw block access for carving, where the hardware and encryption state allow it | Overwritten data; on encrypted, TRIM-enabled storage, deleted blocks are often discarded by the flash controller or unreadable because their key is gone |
The three lower rows are included because users ask about them, not because the app implements them. Chapter 04 covers wireless ADB, which the desktop companion uses to talk to the phone; it is not a storage tier.
The tier-1 exclusions are a platform rule: the Storage Access Framework picker
refuses the internal storage root, Android/data/ and Android/obb/ and their
subdirectories (developer.android.com/training/data-storage/shared/documents-files,
developer.android.com/about/versions/11/privacy/storage). All-files access is
restricted by Play policy (support.google.com/googleplay/android-developer/answer/10467955)
and Google documents that it still cannot reach other apps' app-specific
directories (developer.android.com/training/data-storage/manage-all-files).
Encryption and key deletion are described on
source.android.com/docs/security/features/encryption/file-based; idle
maintenance discarding blocks (FI_TRIM) is described on
source.android.com/docs/core/storage/adoptable.
Other honest limits
- Encrypted or DRM-protected files. If the recorder encrypted the file with a key that no longer exists, the bytes are noise. Same for DRM content.
- A factory reset or a wipe. Those destroy the media database as well as the files.
- A phone that is not booting or not connecting. Recovery needs a working phone and a working connection.
- Some formats. Container repair is strongest for the common camera MP4/MOV/3GP layouts. Other formats can still be exported as a verified byte copy, but not every format can be rebuilt.
- Damaged media, not just a missing index. If the flash itself returned errors and parts of the picture data were never written, the recovered video will have gaps. The result reports what it found rather than hiding it.
- Audio that will not decode. The phone decodes raw AAC well, and the measured case recovered every frame. When a recording's audio still cannot be decoded, the result says so; you can import a separate recording and align it, but nothing can conjure the missing bytes.
- Your phone's manufacturer policy. Some work profiles and Knox or MDM managed devices block USB debugging entirely. That is a policy decision you cannot toggle away.
What we will never claim
That undelete works without root. That a large "found" total means a large readable total. That a repaired file is guaranteed to be pixel-perfect. That the app can recover content it never had permission to read. If any screen or document says otherwise, it is a bug and should be reported.