vold and filesystems

Under every app's files is a small native daemon that decides which volumes exist, which filesystem each one uses, how it is encrypted, and who can mount it. vold is one of the least visible and most consequential parts of the storage stack.

TL;DR#

• vold is the volume daemon: it detects, formats, mounts and unmounts storage volumes.
• userdata is typically ext4 or f2fs; read-only system partitions increasingly use EROFS.
• File-based encryption (FBE) encrypts each file with a key derived from the user's credential, enabling direct boot.
• Adoptable storage (API 23·Android 6.0) formats an SD card as an extension of internal storage.
• 16 KB page sizes (API 35·Android 15) change the granularity of every filesystem and require native libraries to be aligned.

Mental model#

Think of a building's facilities manager.

They decide which storerooms exist, what kind of shelving each has, which key opens which door, and what happens when a storeroom is added or removed. Tenants never meet them; they just find that the shelves are the right height and the door opens.

vold is that manager. The kernel provides the filesystem implementations; vold decides how they are used.

Where the analogy breaks#

A facilities manager works with physical rooms. vold works with block devices that may be encrypted, may be on a removable card, and may be mounted differently for each user on the device. Multi-user makes "the" storage a set of per-user views over shared blocks.

The big picture#

The treemap is an app's view. Underneath it, each group maps to a different mount with a different filesystem and a different encryption key.

Deep dive#

What vold does#

vold is a native daemon started by init. Its responsibilities:

• Watch for block devices appearing and disappearing (uevent).
• Format a volume when asked.
• Mount and unmount volumes, with the right flags and the right UID/GID mapping.
• Manage the encryption keys for adopted and internal storage.
• Notify the framework of state changes.

The framework's StorageManagerService talks to vold over Binder. Apps never talk to vold directly; they see volumes through StorageManager and paths through Environment.¹

Filesystems#

The choice between ext4 and f2fs is a device decision, often made by the SoC vendor. Both are journaled and both support the platform's encryption.

EROFS is the interesting one. It is a read-only filesystem designed for compressed system images: smaller images, faster mounts, and no write path to maintain. Its adoption for system partitions is one reason OTA images have shrunk even as the platform has grown.²

Adoptable storage#

API 23·Android 6.0 added adoptable storage: an SD card can be formatted as an extension of internal storage, encrypted with the device key, and treated as part of userdata.

The trade is real:

• Pro: more internal storage, apps can be moved to it, and it behaves like internal storage.
• Con: the card is no longer readable by other devices, and removing it can break the device until it is reinserted or the adopted storage is forgotten.

Most devices present adoptable storage as an option rather than the default, and many OEMs hide it.

File-based encryption#

Older Android used full-disk encryption (FDE): the whole userdata partition was decrypted with one key at boot. The problem was that the device could not boot far enough to do anything useful until the user entered the credential.

File-based encryption (FBE) encrypts each file with a key derived from a master key, and the master key is available in two states: device encrypted (available before the user unlocks) and credential encrypted (available after).³

This is what makes direct boot possible: an alarm can fire, a phone call can arrive, and a boot-complete receiver can run before the user has entered their PIN, because those components only need device-encrypted storage.³

Metadata encryption#

FBE encrypts file contents but leaves directory structure and file names visible in the clear unless metadata encryption is enabled. Metadata encryption wraps the whole filesystem in an additional layer so that names and inodes are protected too.⁴

The combination — metadata encryption for the structure, FBE for the contents — is the modern default on devices that support it.

The 16 KB page change#

API 35·Android 15 introduced support for devices with 16 KB memory pages, up from the 4 KB that ARM devices have used for years.⁵

Page size is not a filesystem feature, but it affects filesystems directly:

• The minimum allocation unit becomes 16 KB, so small files waste more space.
• Native libraries must be aligned to 16 KB or they cannot be mapped.
• Apps with native code must be rebuilt with the right alignment and tested on a 16 KB device.⁵

The change is transparent to Kotlin and Java code and disruptive to anything with a .so. It is a good example of a kernel-level decision that surfaces as an app compatibility requirement.

Multi-user and the per-user view#

Android supports multiple users (a work profile is a user). Each user gets their own userdata subtree, their own credential-encrypted keys, and their own view of /storage/emulated/<userId>.

vold mounts the per-user storage when the user starts and unmounts it when the user stops. A file written by one user is not visible to another, even though both live on the same physical partition.

Why storage bugs are hard#

The storage stack has more moving parts than almost any other: a kernel filesystem, a userspace daemon, a FUSE layer, an encryption layer, a per-user mount namespace, and the framework's abstractions on top. A bug can be in any of them, and the symptom — "the file is not there" — is the same for all.

Why vold is a separate daemon#

Mounting a filesystem is a privileged operation. Putting it in system_server would mean every mount ran with the framework's privileges and blocking the framework's main thread.

vold is a small, single-purpose daemon with a narrow Binder interface. It runs as root, mounts what it is asked to mount, and reports state. The framework decides what to mount; vold decides how.

That split is also why storage bugs can be hard to attribute: a failure to mount surfaces in the framework as a missing volume, with the cause in a different process.

f2fs versus ext4 in practice#

Both are journaled and both work. The choice is usually made by the SoC vendor based on the storage hardware:

• f2fs is designed for flash: it reduces write amplification and improves random write behaviour on the kind of NAND a phone uses.
• ext4 is more mature and better understood, with more tooling.

An app cannot tell which is in use, and should not care: the contract is POSIX file semantics either way.

EROFS and the system image#

EROFS is read-only and compressed. For a system partition that never changes at runtime, that is exactly the right trade: a smaller image, a faster mount, and no need for a journal.

The consequence for the platform is that OTA images are smaller and boot is faster, which is why its adoption spread across system partitions.

Direct boot and the app's obligations#

An app that wants to run before unlock must:

• Mark the component directBootAware in the manifest.
• Store the data it needs before unlock in device-encrypted storage.
• Handle the transition to credential-encrypted storage after unlock.

The transition is the hard part: the app may be running in one storage state and then gain access to another. The LOCKED_BOOT_COMPLETED and BOOT_COMPLETED broadcasts mark the two moments.

Why storage is a security boundary#

The storage stack is where several security properties meet: the per-user encryption keys, the SELinux labels on the mount points, the FUSE daemon's per-app view, and the framework's permission checks.

A bug in any layer can expose another app's data, which is why the layers are deliberately redundant — the kernel's UID check, the FUSE policy and the framework's permission check all have to pass.

How it evolved#

Under the hood#

• ‹›main.cpp↗the daemon's entry point and command dispatch
• ‹›VolumeManager.cpp↗volume discovery, mounting and state
• ‹›FsCrypt.cpp↗FBE key management and the credential-encrypted state
• ‹›↗the ext4 formatting tooling vold uses
• ‹›↗the EROFS image tools

Curiosity corner#

• Adopted storage can brick a device's data if the card fails. The card holds part of userdata, and there is no redundancy.
• EROFS is read-only by design. That is not a limitation for a system partition; it is the point.
• A 16 KB page device can run a 4 KB-built app, but not if the app ships native libraries that are misaligned.

Try it#

$ adb shell mount | grep -E "data|system"

/dev/block/dm-4 on /data type f2fs (rw,lazytime,seclabel,nosuid,nodev,noatime)
/dev/block/dm-2 on /system type erofs (ro,seclabel,relatime)

$ adb shell sm list-volumes all

emulated;0 mounted
public:179,1 mounted

$ adb shell dumpsys mount | grep -i "encrypt" | head

state: encrypted
type: file

Check yourself#

Sources#