Senzme/NFile: a Flutter file manager for Android with a media hub built in

The gap NFile is trying to fill on Android

Android has no shortage of file managers, but most of them split browsing from playback. You open a folder, tap a video, and a separate app takes over. NFile's README describes a different arrangement: one app that browses, indexes and plays. The stated audience is Android users who care about how the app looks, since the feature list leads with a textured, alpha-blended interface, an icon pack the project calls "Broken", and an AMOLED-friendly dark mode. The repository topics confirm the framing: android, android-app, beautiful-ui, file, file-manager, filemanager. If you have ever wanted a file manager whose visual language you could actually modify, this is a Dart codebase rather than a closed APK, which is the real reason it is interesting to an engineer.

How NFile indexes media instead of walking the tree

The mechanism that matters is native media indexing. According to the README, gallery views for images, videos and audio come from native device indexing rather than a recursive scan of the filesystem. The Technologies Used section names the packages behind that: photo_manager for images and video, on_audio_query for audio. That is a meaningful design decision. A recursive scan costs time proportional to the number of files and gets slower as storage fills; a query against the platform's media database returns results without touching each directory. The trade-off is that indexed media and files on disk are not the same set. A file the platform indexer has not picked up will not appear in the Quick Categories views even though it is present in the file tree. The README does not describe a manual rescan control, so treat the index as the source of truth for the gallery screens and the directory browser as the source of truth for everything else. Playback and viewing are handled by media_kit for video and audio, photo_view for pinch-to-zoom images, and open_filex for handing a file to another app. State management uses provider, and permission_handler sits in front of the platform permission prompts.

Building NFile from source on an Android device

The README gives three steps and no more, and it does not publish a binary or point to a store listing, so building it yourself is the documented path. You need the Flutter toolchain and an Android device or emulator at API 21 or above. Clone the repository, then resolve dependencies:

flutter pub get

With dependencies resolved, run the app on a connected Android device:

flutter run

On first launch the app will request the permissions listed in the README. `MANAGE_EXTERNAL_STORAGE` covers file operations across the whole device, and `READ_MEDIA_IMAGES`, `READ_MEDIA_VIDEO` and `READ_MEDIA_AUDIO` back the native indexing. Expect the media categories to populate only after those media permissions are granted, since the gallery views depend on the platform index rather than on a directory walk. If you only want to check that the project compiles before wiring up a device, `flutter analyze` is the least invasive step, and the repository ships an `analysis_options.yaml` for it.

MANAGE_EXTERNAL_STORAGE is the real adoption cost

The permission list is where NFile asks the most of you. `MANAGE_EXTERNAL_STORAGE` is a broad grant: the README says it is needed for file operations across the entire device. That is exactly what a full file manager needs, and it is also the permission Google restricts on Play for apps whose core purpose is not file management. The README does not discuss Play distribution, and the presence of a `fastlane/` directory in the repository suggests store metadata was at least considered, but nothing available confirms the app is published. So the honest position is this: NFile is straightforward to build and install yourself, and its store situation is undocumented. If your requirement is an app you can ship to a wide audience through Play, verify the distribution path before you invest in the codebase. If you are building for yourself or a small group, the permission is a one-time grant and the rest of the README's claims are about the UI and the players rather than about anything the permission unlocks beyond file access.

Where NFile is the wrong tool

Three cases stand out. First, iOS and desktop: the README is explicit that the target is Android, the topics include android and android-app, and the permission model it relies on is Android's. There is no iOS or desktop build described. Second, scoped-storage-only environments. If your policy or your users' devices forbid `MANAGE_EXTERNAL_STORAGE`, NFile's core promise of file operations across the entire device does not hold, and you would be better served by a manager that works through the Storage Access Framework. Third, headless or scripted file work. NFile is a GUI application with no documented CLI, so anything you would automate belongs elsewhere. There is also a maintenance question worth stating plainly. The last push to the default branch was on 2026-08-11, and the most recent release listed is v1.0.44 from 2026-07-12. The repository is not archived, but the README does not describe a support policy or a release cadence, so do not assume fixes will arrive on a schedule.

How NFile differs from a terminal file manager

The obvious alternative for an engineer is a keyboard-driven terminal manager such as ranger or its Python successor, or a dual-pane tool like Midnight Commander. The difference is not cosmetic. Those tools operate on paths and shell commands, run over SSH, and work identically on a server and a laptop. NFile operates on Android's media database and its permission model, and its value is in the viewers: media_kit for high-resolution video, an audio player with album art and seeking, and photo_view for pinch-to-zoom. A terminal manager will never render a video or show you a thumbnail grid from the platform index. Conversely, NFile will never give you a scriptable pipeline over a remote host. Pick based on whether the job is looking at media on a phone or moving bytes around a system you can reach from a shell.

Licence, forks and what to verify before you commit

NFile is licensed under GNU GPL v3, and the LICENSE file sits at the top level of the repository alongside pubspec.yaml and the android, assets, lib, metadata and test directories. For a fork or an internal build that stays inside your organisation, GPL-3.0 is usually unremarkable. It becomes a real constraint if you intend to ship a modified NFile as a closed product, because the licence's copyleft terms attach to derivative works. That is a description of the licence, not legal advice; if distribution matters to you, have someone qualified read the terms. On upgrade cost, the repository commits a pubspec.lock, which pins the dependency graph, so a rebuild reproduces the dependency set the maintainer used. That is good for reproducibility and it also means moving forward requires deliberately refreshing the lockfile and re-testing media_kit, photo_manager and on_audio_query, since a media engine upgrade is the kind of change that shows up as playback regressions rather than compile errors. The README does not document a rollback procedure, so keep the working commit hash before you refresh anything.

Editorial conclusion

NFile is worth building from source if you want a Flutter codebase to study or extend and you are comfortable with an Android-only target. Skip it if you need iOS, desktop, or a file manager that works inside Android's scoped storage rules without MANAGE_EXTERNAL_STORAGE, since the README lists that permission as required for full file operations. Before adopting it, check the last push date (2026-08-11), read the permission list in the README, and confirm that the Flutter toolchain on your machine can resolve the pubspec.lock that ships in the repository.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. Senzme/NFile on GitHub