Fossify File Manager is an Android file manager with app-level locks and no network code

Three distribution channels and what each one changes

The README links the same application id, org.fossify.filemanager, to three places: Google Play, F-Droid and IzzyOnDroid.

The presence of a `fastlane/` directory with metadata under `fastlane/metadata/android/en-US/images/phoneScreenshots/` explains where the store listing text and the three screenshots in the README come from. That directory is part of the repository, so the store copy is versioned alongside the code rather than written in a browser dashboard.

The homepage is https://www.fossify.org/apps/file-manager/, and the README ends with links to a broader Fossify app catalogue, the GitHub organisation, a Reddit community and a Telegram group. This is one app in a family, which is relevant to how maintenance is funded and how bugs get reported.

The lock feature covers hidden items or the whole app

The one feature that distinguishes this from a generic file browser is the locking, and it comes in two scopes.

You can protect sensitive files with a password, a pattern, or a fingerprint, and the target of that protection is either individual hidden items or the entire application. Scoping it to hidden items is the more interesting half: a folder can be marked hidden from casual browsing and separately require a credential to open, which is the arrangement most people are actually looking for when they install a file manager.

Fingerprint as an unlock method puts this app in a small category. Biometric unlock in a file manager is a convenience feature in most apps, since you have already unlocked the phone. Here it gates a second layer, which is the case where it earns its place.

The rest of the feature set is standard for the category: compression of files and folders, transfer between locations, a customizable home folder, favorite shortcuts, search, sorting, root file navigation, SD card and USB device access, storage analysis to find large files, desktop shortcuts, and a light file editor with zoom gestures for viewing, editing and printing documents.

Customization covers colors, themes and icons.

No internet access is a design constraint, not a promise

The README states that no internet access is required and that your files stay on your device. For an Android application, that is a stronger claim than it sounds, because declaring no internet permission is verifiable in the merged manifest of a built APK, and it removes a whole class of concern.

It also removes a category of feature. There is no built-in transfer to a remote machine, no cloud integration, no sharing to a network location. If any of those are what you want, this is not the app.

That said, the README says the app requires no internet access rather than declaring that the manifest holds no network permission, and the README is not the place that is verified. If the property matters to you, the check is to inspect the permission set of the specific build you intend to install.

Storage analysis is described as a built-in tool for identifying space-hogging files, and root navigation is offered alongside SD card and USB device access. Root access is a capability here rather than a documented requirement, and how it behaves on a device with an unlocked bootloader is not something the README addresses.

Gradle, detekt and lint.xml describe the build and the quality gate

The repository layout is what you would expect from a maintained Android project, and it tells you what building involves.

The build is Kotlin DSL: `build.gradle.kts` and `settings.gradle.kts` at the root, `gradle.properties`, the `gradle/` directory, and the `gradlew` and `gradlew.bat` wrappers. Application code lives in `app/`, and `graphics/` holds the icon assets referenced in the README.

Static analysis is configured rather than assumed. `detekt.yml` is Kotlin static analysis configuration, `lint.xml` is Android Lint configuration, `.editorconfig` fixes formatting across editors, and `CODEOWNERS` assigns review responsibility by path. For a project of this size, having all four is a signal about how changes are checked before they land.

There is also `keystore.properties_sample`, which is the template for release signing credentials. A file manager gets a signed release build rather than a debug build, and the sample tells you the file that must exist and be filled in. It does not contain a key, and it should not.

`.fossify/` at the root suggests project-specific tooling shared across the Fossify apps, and the presence of a `Gemfile` and `Gemfile.lock` points at Ruby tooling used for release automation, likely driving fastlane.

Release 1.6.2 in October after a nine-month gap

The release history is uneven in a way worth reading before you adopt.

1.6.2 shipped on 2026-10-10. The one before it, 1.6.1, is from 2026-02-17, and 1.6.0 from 2026-01-30. So there was a cluster of development in January and February, then roughly eight months of nothing visible in the tags, then a release six days before the current date.

The last push was on 2026-10-14, two days after the 1.6.2 tag, and the repository is not archived.

The gap has two possible readings and the repository does not settle which applies. Either work continued on a branch without a tag, or development genuinely paused and has just resumed. Either way, if you install 1.6.2 you are running a build that is at least six months newer than the previous one and about as old as the last commit, which is the version most worth testing carefully on a device holding real data.

Version numbers here are plain `1.6.x`, not semver, so there is no minor-versus-major signal in the numbering. The CHANGELOG.md at the root is the place to read what actually changed, and the README does not summarise it.

GPL-3.0 and what that means for a fork

The licence is GPL-3.0, which is the standard for this category of Android application and shared across the Fossify family.

For an end user installing a build, the practical implication is limited: you can use it, modify it for your own device, and redistribute it provided you also offer the source under the same terms.

For anyone planning to fork it into a product, GPL-3.0 is copyleft, which means a derivative distributed to users has to carry the licence and its source offer. That is the constraint to evaluate, and it is a licence question rather than a technical one, so this is not advice on it.

The companion files at the root are CHANGELOG.md, CONTRIBUTING.md and LICENSE, so the contribution process and the change history are both in the repository.

One thing the repository does not contain is a privacy policy or a data-collection statement. For an app that stores no data and requests no network access, that absence is arguably consistent with the design, but it also means there is no document in which the maintainer makes that promise formally. The README's statement is the only one available.

Editorial conclusion

Adopt Fossify File Manager if you want an Android file manager distributed from F-Droid or IzzyOnDroid and you want a fingerprint or pattern lock over private directories, which the Google Play versions of the category rarely offer as a first-class feature. It is the wrong tool if you need network transfer built in, because the app states it requires no internet access and has no sharing or remote-access features.

Frequently asked questions

Official sources

1. FossifyOrg/File-Manager on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases