SoftwareApp
05a71f12bf
The root screen opened on a list of volumes, so "where are my photos?" began with knowing which folder they were in. It now opens on Libraries - Images, Videos, Audio, Documents, Archives and Recent - each row saying how many files the index knows of that kind, and each opening an ordinary listing with thumbnails, sorting, multi-select, details and the existing viewers, so a tap on a photo opens the image viewer and a tap on a PDF the PDF viewer. Downloads and New files are deliberately absent: one is a folder shortcut and the other a time window, and presenting three different things as one feature is how a listing starts lying about itself. Documents includes .txt, because a user looking for their documents means those too, and DIRECTORY, APK and OTHER belong to no library at all - a test asserts the three omissions so they stay decisions rather than oversights. A library has to ask for "every image" without reading a name, so IndexedFile gained a derived kind beside FileEntry's and the index stores a copy of it to filter on: schema v3, with a migration that rebuilds the files table and deletes the volume stamps with it, because a stamp means "the rows behind this are this current" and a rebuilt table has no rows behind it. Rebuilding rather than backfilling is legitimate only because this index is a cache of a walk that can be repeated; SqliteTrashIndex's rule is the opposite and its own documentation says why. A library then obeys the indexed search's two rules exactly: the answer comes first with the walk behind it, and every row is confirmed against the filesystem before it is shown, with the rows whose file has gone forgotten rather than displayed. On a device that has never been indexed the first tap on Images therefore starts a walk - which the screen admits to, using the progress row the search already had, instead of showing an empty library that reads as an empty device. "Find duplicates" in the overflow compares contents in three passes, cheapest first: size, which the index already knows, so the candidate list is one query and reads nothing at all; the first 64 KB of every candidate, a filter whose only power is to rule files out; and the whole file for whatever survives, which is the pass that decides. The separation is enforced by a test that builds two files sharing their first 64 KB and differing afterwards and asserts both were read in full - it would fail if the cheap pass were ever treated as an answer. The screen shows only what was measured: groups ordered by the space deleting the spare copies would give back, each header stating the copies and what they cost, every row carrying its folder as well as its size, and nothing preselected, because which copy to keep is the one decision the screen exists to hand over. A file whose bytes cannot be read is counted and reported rather than skipped, "nothing found" is never claimed without saying how many files were compared, and deleting closes the scan instead of patching it - its rows came from comparing bytes, and quietly dropping some of them would leave a list that still looks like a scan while its headers claim numbers nobody measured. The thumbnails went from 28 to 48 dp in a list row and 40 to 96 dp in a grid cell, with the grid's minimum column width raised to 144 dp to suit them; ListItem measures its leading slot rather than capping it, so a row grows to fit instead of clipping. That turned out to matter: the commonest complaint in the competitive survey is thumbnails that load only once scrolling stops, which is the failure mode a larger thumbnail invites. Two smaller corrections came out of the same work - a mutation now re-reads whatever is on screen, so a delete from inside a library removes the row instead of doing nothing at all because there was no path to reload, and returning to the app re-reads a library rather than dropping the user back to the roots. docs/COMPETITIVE_ANALYSIS.md records the market leader's features and what its users praise and complain about, with the sources that were blocked and the size of the review sample stated rather than glossed over; it is where both features came from, and the gaps that cost no permission are listed as candidates in the roadmap. 323 JVM tests (34 added across the two features), lint clean. Tested on the real phone - the same M2101K7AG, with the debug build installed past MIUI's two gates. The libraries on a cold index (no counts rather than a row of zeroes, "Indexing 300 files..." on the first tap, then "Index updated" and real thumbnails), the counts afterwards (Images 6238, Recent uncounted), a tap opening the viewer and BACK returning with the scroll position, and a duplicate scan that found four genuine groups in the device's own storage with nothing crashing. The duplicate delete was deliberately not pressed on a device that is not ours to empty, the store screenshots predate the new home screen, and the library views turn the M10 screenshot rule into a privacy question as well as a cosmetic one - all of that is recorded in docs/EDGE_CASE_TESTING.md rather than left implicit.
11 KiB
11 KiB
Roadmap
File Manager is built against a fixed milestone plan (M0–M10). This file is the single source of truth for what is done and what remains.
Legend: ✅ done · 🚧 in progress · ⏳ not started · 💡 candidate (proposed, not scheduled)
Milestones
| # | Milestone | Status | Evidence / notes |
|---|---|---|---|
| M0 | Toolchain & scaffold | ✅ | Gradle 9.3.1 + AGP 9.1.0 wrapper, version catalog, app module, Compose theme, debug APK builds, installs and runs on the phone AVD: package de.softwareapp_hb.filemanager.debug, versionCode 1, minSdk 26/targetSdk 36, no INTERNET permission, lintDebug clean (one expected UnusedResources for the not-yet-used notification icon) |
| M1 | Pure-Kotlin core + JVM tests | ✅ | core/ is Android-free: StoragePath (normalised absolute paths that cannot escape the root), FileEntry + FileKind classification, MimeTypes, NaturalOrder + SortSpec (directories first; file2 before file10), FileSize, NameMatcher (substring + */? glob), NameAllocator ("name (1)") and TransferPlanner (conflict policies, move-into-self). 44 JVM tests across 10 classes, all green |
| M2 | Storage layer | ✅ | StorageSource with two backends — AllFilesSource (java.io.File under all-files access) and SafSource (DocumentsContract over a persisted tree URI), the latter split so the tree↔path mapping (SafDocumentIds) is exhaustively testable; SafGrant for the picker and its persistence; VolumeRepository (StorageManager/StorageVolume + StatFs); StorageAccess + StorageAccessPolicy for the all-files/SAF decision. 76 JVM tests total (32 added here) |
| M3 | Operations engine + service | ✅ | domain/FileOperations composes the backend primitives into copy/move/delete/rename with recursive walking, an honest progress total, cooperative cancellation between entries and per-item failure reporting; conflicts are decided through the M1 TransferPlanner (ASK is surfaced for the UI to resolve). service/FileOpService is a dataSync foreground service mirroring progress into a notification (FileOpNotifications + text/TextRes). 99 JVM tests total (23 added here) |
| M4 | Compose UI | ✅ | BrowserViewModel + BrowserUiState over StorageLocation; browser screen with list/grid, breadcrumbs, in-folder search, a sort/hidden-files/view sheet, multi-select action bar, details sheet, and new-folder/rename/delete/conflict dialogs; a roots view and the "All files access" + SAF-folder prompts; data/MediaStoreDeleter routes a delete through the platform's own dialog where it can and falls back to a direct delete; a FileProvider backs "open with" and share. 115 JVM tests total (16 added here) |
| M5 | Analysis, archives, viewers | ✅ | domain/UsageAnalysis measures recursive folder sizes and finds the largest files, shown by a bar-per-row storage-usage screen; domain/ArchiveEngine creates ZIP and extracts ZIP/TAR/TAR.GZ/GZ/BZ2/XZ/7z using java.util.zip + Commons Compress + XZ for Java (no native code), with every entry name filtered through core/ArchivePath against zip-slip; a Coil-backed image viewer, thumbnails in the list and grid, a text editor, and compress/extract in the selection bar. 141 JVM tests total (26 added here) |
| M6 | Release config & Play readiness | ✅ | Upload keystore generated (4096-bit RSA, CN=Hadrian Burkhardt) and wired through the git-ignored keystore.properties; bundleRelease + assembleRelease verified — 4 682 814-byte .aab (sha256 9014627a…), 2 081 955-byte APK signed by the upload key, R8 mapping kept. PLAY_RELEASE_CHECKLIST (incl. the Permissions Declaration Form for "All files access", the Data safety answers and the shipped-permission audit) and PRIVACY.md written for a restricted-permission app. Shipped permission set audited: no INTERNET |
| M7 | On-device validation & hardening | ✅ | Run on a real Xiaomi M2101K7AG (Android 12 / MIUI V140) — see EDGE_CASE_TESTING. Verified on hardware: the first-run permission prompt, granting "All files access" while the app is alive (picked up on resume), browsing real storage, the text editor's read and write path (independently checked with adb shell cat), the storage-usage screen, landscape layout, and graceful degradation when access is revoked mid-use. Found and fixed two real defects: misleading first-run copy ("Full access was declined" on a device where nothing had been declined), and a usage screen that stayed blank for ~45–60 s on a 55 GB volume — now one listing per directory instead of a stat per node, with rows streamed out as they are measured. 142 JVM tests |
| M8 | Localisation groundwork | ✅ | Every user-visible string is in res/values/strings.xml with real <plurals>, and text/TextRes.kt maps both OperationKind and FileKind onto resources so the screen, the notification and the details sheet cannot drift. The audit found a genuine miss: the details sheet rendered FileKind.name, i.e. untranslatable English — now a resource. isPseudoLocalesEnabled = true on the debug build makes "did every string come from resources?" mechanically checkable; verified en-rXA is present in the debug APK and the flag is debug-only. Byte units and the timestamp pattern are deliberately unlocalised, and the README says why. 142 JVM tests |
| M9 | Monetisation | ✅ | Decided: one-time paid — €4.49 base with a 14-day launch price of €2.29, both set in the Play Console (Products › App pricing), so there is no Billing client, no com.android.vending.BILLING permission and no purchase code. Rationale, market anchors and Console steps: MONETISATION. Verified against the release APK: zero billing and zero INTERNET references. The price must be set before the first upload — Play allows paid → free but never free → paid |
| M10 | Store assets | ✅ | Name decided: Plain Files (one string; applicationId already locked). tools/make-store-assets.sh renders the 512×512 RGBA icon and the 1024×500 RGB feature graphic from the app's own vectors, so the store icon is the launcher icon; tools/make-store-screenshots.sh normalises adb captures to Play's 2:1 cap per form factor (phone crop default 93/130 px, tablets 0). STORE_LISTING carries length-checked copy (name 11/30, short 67/80, full 2730/4000), the permissions paragraph the MANAGE_EXTERNAL_STORAGE declaration requires, and the graphics table. The feature graphic's copy was verified to survive Play's centre-square crop by cropping the rendered PNG. Screenshots captured: 5 phone (1080×2160), 4 on a 7-inch tablet (1200×1920) and 4 on a 10-inch tablet (2560×1600), all 24-bit RGB, inside the 2:1 cap. The tablet sets came from AOSP AVDs. The normaliser refuses a capture whose app area is blank, which is how a pure-background capture was caught before it reached the listing |
| M11 | Library views | ✅ | A Libraries section on the root screen — Images, Videos, Audio, Documents, Archives, Recent — each row carrying how many files the index knows of that kind, each opening an ordinary listing (thumbnails, sort, multi-select, details, the existing viewers) answered from the index instead of from a directory. core/FileCategory groups FileKinds and is asserted to leave DIRECTORY, APK and OTHER out deliberately; SearchIndex gained byKind/recent/kindCounts, and SQLite schema v3 adds the derived kind column — the migration rebuilds the table and drops the volume stamps, because a stamp whose rows have gone would make the next search trust an empty index. A library obeys the indexed search's own two rules: the answer comes first with the walk behind it, and every row is confirmed against the filesystem before it is shown. Not included, and recorded in the CHANGELOG as decisions rather than omissions: Downloads and New files, and restoring a library across process death. 308 JVM tests (19 added here) |
| M12 | Duplicate finder | ✅ | Find duplicates in the overflow. Three passes, cheapest first: size (the index's duplicateCandidates query — one query and no reading at all), the first 64 KB of every candidate (a filter that may only rule files out), and the whole file to confirm (domain/DuplicateFinder, SHA-256, cancellable between files and between read buffers). Groups are ordered by reclaimable space; each header states the copies and what they cost; every row carries its folder, because identical names with no paths are unactionable; and nothing is preselected — the delete is the app's ordinary one, through the trash and the undo snackbar. A file that cannot be read is counted and reported rather than skipped, and the empty state says how many files were compared — or that the index has never run and there was nothing to compare. 323 JVM tests (15 added). Verified on the Xiaomi phone against four genuine groups in its own storage; the delete was deliberately not pressed on a device that is not ours — see EDGE_CASE_TESTING |
Key decisions
| Decision | Choice | Rationale |
|---|---|---|
| Language / UI | Kotlin + Jetpack Compose | Mirrors the sibling app's proven, installed toolchain; no NDK |
| Storage access | MANAGE_EXTERNAL_STORAGE first, SAF fallback |
Google Play explicitly permits "All files access" for file managers; SAF keeps the app usable if the user declines |
| Connectivity | Local-first (no INTERNET in v1) |
Preserves the "nothing leaves the device" claim and keeps the Data Safety form trivial |
| File sharing | Receives SEND/SEND_MULTIPLE, serves GET_CONTENT/OPEN_DOCUMENT, and deliberately does not register ACTION_VIEW |
A file manager should be able to receive a file and to supply one, and neither costs a permission. Registering as a viewer as well would put Plain Files in the "open with" chooser the app itself uses, offering it back to itself |
| Monetisation | One-time paid (€4.49; €2.29 launch price), set in the Console | No Billing client, no BILLING permission, no purchase code — which is what keeps "nothing leaves the device" true in the shipped APK. Free → paid is impossible after the first upload, so the price must be set beforehand. See MONETISATION |
Deliberately deferred (post-1.0)
- Cloud storage (Drive/OneDrive/Dropbox/…); network clients (SMB/FTP/SFTP/WebDAV); FTP/Web
server. All of these need
INTERNET, which is the one permission the app deliberately does not declare — see the connectivity decision above. - App manager (
QUERY_ALL_PACKAGES), APK installation (REQUEST_INSTALL_PACKAGES). - RAR archives (the format needs native code) and 7z creation; root explorer; encryption vault; themes/icon packs.
Candidates from the competitive analysis
A survey of the market leader (its features, and what its users praise and complain about) is in COMPETITIVE_ANALYSIS. Its gaps that cost no new permission are listed there as 💡 candidates. Category libraries were the first of them and are now M11, and the duplicate finder the second (M12); the rest — batch rename with sequence continuation, bookmarks, and the post-paste "copy again" / "return to source folder" — are proposals, not scheduled work, and adding one is a roadmap decision rather than a side effect of reading that document.