FileNavigator: an Android watcher that files new files away for you

A watcher, not a file browser

File Navigator describes itself as the missing link between Android and a sorted file system, and the sentence is the specification of the app. It watches Android's shared storage for new files and helps move them to the folders where they belong, and the rules can distinguish not only between file types but also between sources such as the camera, screenshots, downloads, recordings and other apps.

That framing matters because the app is not competing with a conventional file manager. A file manager is a browser: you open it, look through it, and move things by hand. This app is an event-driven sorter. It sits in the background, notices that a file appeared, and either asks you where it should go or decides for you.

The interaction model follows from that. The four steps in the documentation are: select the file types and sources to observe, start the navigator, and when a matching file appears either choose a new destination or a configured Quick Move destination from the notification, or let an Auto Move rule handle it, and finally review completed operations in the move history.

The app supports Android 11 and newer, and it is distributed in four places, on Google Play, on F-Droid, on IzzyOnDroid and as a GitHub release, with the package identifier `com.w2sv.filenavigator`.

It is written in Kotlin, with Jetpack Compose and Material 3 for the interface, and the repository is a Gradle project with convention plugins, a version catalog, a `build-logic/` directory and a `Makefile` of developer targets.

Source rules are the part that matters

The feature list is long, but one entry carries the design. Source-specific rules let you configure different behavior for camera photos, screenshots, recordings, downloads, and files created by other apps.

That is the feature that a plain file-type filter cannot express. A screenshot and a photo from the camera are both JPEG files in the same shared storage, and a rule that says images go to a Pictures folder will treat them identically. The source dimension lets them be separated, and it is the difference between a sorter that is useful and one that produces a second pile of unsorted images.

The built-in file types cover pictures, videos, audio, PDFs, text files, archives, APKs and eBooks, and custom file types can be created with a name, a color and a set of file extensions. There is also a configurable extensions option to include or exclude extensions from supported non-media file types, which is how you keep a project directory of `.txt` files out of the text bucket while still filing `.md` and `.pdf`.

The remaining features fit around that core. File discovery notifications tell you when a new matching file appears and let you move, open or delete it directly from the notification. Quick Move assigns frequently used destination folders to a file source so a move takes a single action. Auto Move routes new files to configured folders without further interaction. Batch moving collects multiple active navigation notifications and moves their files to one destination, which is the feature that saves time when a dozen screenshots arrive at once.

There is a move history for reviewing previously moved files and their destinations, a Quick Settings tile to start or stop the navigator, and optional background controls to start on boot and stop navigation when the battery is low.

The notification is the interface, and Auto Move removes it

The design decision worth thinking about is that the primary user interface is a notification rather than a screen. The app's screenshots show the home screen, a notification, a file type settings screen and an app settings screen, and the notification is where the decision to move a file is made.

That works because the moment a file appears is exactly the moment the user has context about it. You take a screenshot, the notification arrives, and you swipe it into a folder. No app needs to be opened, and the flow is one gesture long.

Auto Move takes the decision away. It routes new files to configured folders without further interaction, and the move history is the audit trail for what the rule did. The trade is obvious and worth stating plainly: an automatic rule that matches too broadly will move files unattended, and the only record is a list you have to remember to check.

That is why the source-specific rules matter more than they first appear. A rule set of file types alone is easy to write and easy to get wrong, because almost every app that writes media writes the same formats. A rule set that pairs types with sources is more work to configure and much less likely to sweep a file into the wrong folder.

The Material 3 presentation is the other half of the product. The app follows the system theme, supports light and dark mode, offers dynamic colors, and includes an AMOLED black theme, which is a small detail that matters for an app that sits on the lock screen and in the shade all day.

Android 11 changes what any file app can reach

The documentation states the constraint plainly. Android restricts access to app-private storage, and File Navigator therefore works with files exposed through shared storage and Android's media and document APIs.

This is the boundary of the whole product, and it is a platform boundary rather than an implementation detail. A file that lives in another app's private directory is not visible to this app, to any file manager, or to any other app, unless the owning app shares it. What a file sorter can therefore do is work on the media library, on the download directories and on the shared document surfaces, which in practice covers the files that actually accumulate: camera output, screenshots, screen recordings, downloads and the files that other apps write to shared storage.

The technology list confirms the approach. The stack names Android MediaStore, the Storage Access Framework, foreground services, notifications and the Quick Settings APIs, and those are the platform surfaces that a background watcher on modern Android is expected to use. A foreground service is what lets the watcher keep running, and a notification is both the foreground service requirement and the user interface, which is why the notification is the interface.

For an adopter, the practical check is simple. Look at where the files you want sorted actually are. If they are in shared storage or visible through the media and document APIs, the app can reach them. If they are inside an app's private directory, no version of this app or any other will see them.

The module graph behind a Compose application

The repository is a multi-module Gradle project, and the architecture table in the README lists the modules with their responsibilities. The `:app` module holds the Compose UI, the app navigation and the top-level dependency wiring. The `:benchmarking` module is for Baseline Profile generation and macrobenchmarks. The `:modules:database` module is the Room database and move-history persistence, and `:modules:datastore` covers persisted navigator and app configuration, with the table continuing beyond what the README shows.

That split is a modern Android application shape rather than a legacy one, and the rest of the stack matches it. Kotlin Coroutines for asynchronous work, Jetpack Compose with Material 3 for the interface, Navigation 3 for navigation, and Hilt for dependency injection. Configuration is stored with Protocol Buffers and DataStore-backed preferences, and the persistence of move history is Room.

The testing story is also visible: JUnit, Robolectric, MockK, Turbine and Compose UI tests, plus Baseline Profiles for startup and runtime performance.

The repository itself is arranged around those conventions. There is a `build-logic/` directory for the Gradle convention plugins, a `config/` directory, a `gradle.properties`, a `settings.gradle.kts`, the `gradlew` wrapper, a `docs/` directory holding the module dependency graph as an SVG, and a `Makefile` of developer targets. There is also a `renovate.json`, which is how the dependency updates are automated, and a `PRIVACY-POLICY.md` and an `Agents.md`.

The releases are versioned 0.3.x, with 0.3.6 on 2026-10-13, 0.3.5 on 2026-06-09 and 0.3.4 on 2026-05-29. The repository is not archived and the last push was on 2026-10-15, so the app is being worked on regularly. The licence is GPL-3.0, which for a distributed application means a derivative that is distributed has to carry the same licence.

The Makefile is the developer interface

The build is driven by Gradle, but the tasks a contributor actually runs are wrapped in the Makefile at the repository root, which makes them short enough to remember.

Formatting is one target:

format:
	@./gradlew ktlintFormat

Building a release APK is another:

build-apk:
	@echo "Build APK"
	@./gradlew assembleRelease --console verbose

and the target that starts the app with the navigator already running, which is the loop that matters when you are changing the watcher behaviour:

run-with-navigator-start:
	@./gradlew installDebug
	@adb shell am force-stop com.w2sv.filenavigator
	@adb shell am start -n com.w2sv.filenavigator/.ui.MainActivity -a com.w2sv.filenavigator.START_NAVIGATOR

That last target is worth understanding. It installs the debug build, force stops the app so the old process is gone, and starts it with the `START_NAVIGATOR` action, which tells the app to begin watching immediately rather than waiting for you to tap the start button. It is the difference between testing the watcher and testing the notification.

The Makefile also carries targets for taking screenshots with `adb shell screencap`, expanding the status bar, generating the store screenshots with `:app:storeScreenshots`, updating the dependency version catalog with `versionCatalogUpdate`, and updating the Gradle wrapper to the latest version.

One target is worth mentioning because it shows how the project keeps its own documentation honest. `generate-module-graph` runs a Gradle task that writes the module graph in Graphviz text form, pipes it through `dot -Tsvg` into an SVG, and moves the result into `docs/`, which is where the module dependency graph image in the README comes from. The diagram is generated from the build rather than drawn by hand.

Editorial conclusion

File Navigator suits an Android user whose storage fills up with camera photos, screenshots and downloads that never get filed, and who wants that sorting to happen in the background without opening a file manager. It does not suit a user who needs to browse app-private storage, because Android does not expose it, and it does not suit someone uneasy about an automatic rule moving files without confirmation. Before turning Auto Move on, check the source rules against the apps installed on your phone, because a camera rule and a download rule that both match the same file will produce a different outcome than you expect.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. w2sv/FileNavigator on GitHub