hardcore-sushi/DroidFS: encrypted volumes on Android that you browse, not mount

A file explorer instead of a mount point

DroidFS is an implementation of encrypted overlay filesystems for Android, and the design decision that defines it is that it does not mount anything. Instead it uses its own internal file explorer, so a volume appears inside the app rather than as a directory the system can see.

That is a different threat model from the desktop tools it is compatible with. On a desktop, a mounted encrypted volume is a normal directory, and every application with the right permissions can walk it. On Android, where the storage sandbox is the main security boundary, handing an app a file tree is a bigger concession than it looks, so keeping the decrypted content inside a single app's sandbox is the point of the project.

The supported formats are gocryptfs and CryFS, and the project describes itself as compatible with the original encrypted volume implementations. In other words, a volume created on a laptop with gocryptfs can be opened on the phone, which is the use case that makes the tool worth installing rather than a curiosity.

The README also notes that DroidFS is available on Tangled, an alternative hosting platform, alongside the GitHub repository, which is a small but telling detail about how the author wants the project distributed.

The disclaimer is the most informative paragraph

Before the features, the README has a disclaimer, and it is more specific than disclaimers usually are.

DroidFS is provided as is, without any warranty of any kind, and it should not be considered an absolute safe way to store files. It cannot protect you from screen recording apps, keyloggers, APK backdooring, compromised root access or memory dumps. And the instruction is direct: do not use this app with volumes containing sensitive data unless you know exactly what you are doing.

That list is a threat model, and it is worth reading as one. Each item is a way the plaintext leaves the app's control. A screen recorder captures the display while a decrypted file is open. A keylogger captures what you type, including the volume password. A backdoored APK does not need any permission because it is the app. Root access bypasses the sandbox entirely. And a memory dump catches the plaintext while it is in RAM, which is unavoidable for a viewer that has to decrypt something.

For a tool whose selling point is encryption, the honest admission that the encryption protects the volume at rest and not the session in which you read it is the most valuable thing in the documentation, and it is the reason to read the rest of the unsafe features list before you turn anything on.

Every dangerous behaviour is an opt-in flag

The features that could leak plaintext are collected under a heading of unsafe features, and the project says they are disabled by default and that you should read the documentation before activating one.

There are more of them than you would expect, and each one is a hole you can open. Allow screenshots disables the secure flag of the DroidFS activities, which lets you take screenshots of the app but also lets other apps record the screen while DroidFS is in use. The documentation adds that apps with root access do not care about this flag, since they can capture any app's screen without permissions.

Allow exporting files decrypts and writes a file to disk in external storage, where any app with storage permissions could reach it. Allow sharing files via the Android share menu decrypts and shares a file with other apps, which could then save and send it. Allow opening files with other applications does the same through the open-with flow, and a companion flag, Grant write access, lets those external apps modify the files they open.

Expose open volumes is the one that goes furthest, allowing the volumes to be browsed in the system file explorer through the DocumentProvider API, so encrypted files can be selected from other applications, potentially with permanent access. It requires the auto-locking override and works more reliably with the keep open option also enabled.

There is a footnote that explains the mechanism behind several of them. These features can work in two ways, temporarily writing the plain file to disk in DroidFS internal storage or sharing it via memory, and by default DroidFS keeps the file only in memory because that is more secure, falling back to disk export if the file is too large to hold in memory. The behaviour is changed with the Export method parameter in the settings, and the footnote warns that some applications require a file on disk and therefore do not work with memory exported files.

Fingerprint unlocking and the key in the Keystore

Fingerprint authentication appears twice in the feature list, once as a normal feature and once as an unsafe option, and the difference is instructive.

Unlocking volumes using fingerprint authentication is a standard feature. The unsafe variant is allowing the password hash to be saved using fingerprint. The mechanism is described precisely: generate an AES-256 GCM key in the Android Keystore, protected by fingerprint authentication, then use it to encrypt the volume password hash and store the result in DroidFS internal storage. It requires Android v6.0 or later, and the documentation notes that if your device is not encrypted, extracting the encryption key with physical access may be possible.

That last sentence is the important one, and it explains why a Keystore key is not automatically as safe as it sounds. The Keystore protects the key with the device's own lock screen and, in the best case, a biometric. If the device's storage is not itself encrypted, the key material can be pulled off the device by someone with physical access.

Two more options in the list are about how long plaintext lives in memory. Disable volume auto-locking, previously called keeping volumes open when the app goes in background, stops the app from closing open volumes when you leave it, and the documentation is explicit that anyone going back to the application could have access to the open volumes, and that cryptographic secrets are kept in memory for an undefined amount of time. Keep volumes open is a different thing despite the confusing name, and the author apologises for the confusion in the README, so it runs as a foreground service to keep the volumes open even when the app is removed from recent tasks, which prevents the system killing the app during file operations, at the same cost of secrets living in memory indefinitely.

Verifying the download, in three steps

The download section is the most careful in the project, and it is worth following exactly.

DroidFS is available from F-Droid, from the GitHub releases, and from IPFS with both a local gateway address and a public one. The APKs are signed with the author's PGP key, and the key is available on keyservers, so the verification starts with:

gpg --recv-keys AFE384344A45E13A

The fingerprint is given in full, `B64E FE86 CEE1 D054 F082 1711 AFE3 8434 4A45 E13A`, with the email `Cipherd <[email protected]>`, and the fingerprint is what you compare against what the key server returned, since a key ID alone can be forged.

To check the authenticity of the release, you save the PGP signed message in a file named `hashes.txt` and run:

gpg --verify hashes.txt

And the instruction is emphatic: do not install any APK if the verification fails. If the signature is valid you can compare the SHA256 checksums with:

sha256sum <APK file>

with the matching warning not to install the APK if the checksums do not match. The README also provides the hashes of the APK signing certificate itself, for anyone who would rather check the certificate than the files, while noting that you still need to verify the PGP signature of the message itself.

For a project distributed outside the Play Store, from three different channels, with an AGPL-3.0 licence and a single author, that verification chain is what makes the distribution trustworthy, and the fastlane metadata in the repository suggests the releases are built through a repeatable pipeline rather than by hand.

Where this is the wrong choice

The first wrong case is the one the disclaimer names. If the loss of the plaintext would be unrecoverable, this tool is not a defence. A keylogger or a backdoored APK defeats the encryption entirely, and no option in the settings changes that.

The second wrong case is a workflow that needs other apps to read the volume. The whole design keeps the content inside the app, and opening it with other applications is listed as an unsafe feature for a reason. If your work involves a document that a third party application must open, you are either accepting the export risk or you are not using DroidFS.

The third is a product decision. The project is AGPL-3.0 licensed, and a fork embedded in a distributed application inherits obligations that a permissively licensed library would not. For personal use that is irrelevant, and for a commercial product it is a conversation with a lawyer rather than a technical detail.

The fourth is a device you do not control. The fingerprint options assume a device with a secure screen lock and, for the strongest guarantees, encrypted storage. On a device without encryption, the documentation says outright that extracting the encryption key with physical access may be possible.

On maintenance, the releases are current, with v2.3.0 on 2026-08-12, v2.3.1 on 2026-08-16 and v2.3.2 on 2026-09-13, and the last push was on 2026-10-15. The repository is a Gradle project with an `app/` module, a bundled `libpdfviewer` for the PDF support, a `fastlane/` directory for the store metadata, and a `TODO.md` that lists the planned features.

Editorial conclusion

Adopt DroidFS if you already have encrypted volumes from gocryptfs or CryFS and want to read them on Android without granting an app a mounted filesystem, since that is the whole premise and the safe defaults are genuinely conservative. Do not adopt it for data whose compromise would be unrecoverable, because the project states plainly that it cannot protect you from screen recording apps, keyloggers, a backdoored APK, compromised root access or memory dumps, and do not fork it into a closed source product without reading the AGPL-3.0 terms. Verify first that your volume format is one of the two supported ones, that the fingerprint features work on your device and Android version, and that you check the PGP signature and the SHA256 checksum of the APK before installing it.

Frequently asked questions

Official sources

1. hardcore-sushi/DroidFS on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases