Android file system

Understanding the Android File Hierarchy

by  Bill Anderson

rootfs / rootfs ro 0 0
tmpfs /dev tmpfs rw,mode=755 0 0
devpts /dev/pts devpts rw,mode=600 0 0
proc /proc proc rw 0 0
sysfs /sys sysfs rw 0 0
tmpfs /sqlite_stmt_journals tmpfs rw,size=4096k 0 0
none /dev/cpuctl cgroup rw,cpu 0 0
/dev/block/mtdblock0 /system yaffs2 ro 0 0
/dev/block/mtdblock1 /data yaffs2 rw,nosuid,nodev 0 0
/dev/block/mtdblock2 /cache yaffs2 rw,nosuid,nodev 0 0
/dev/block//vold/179:0 /sdcard vfat rw,dirsync,nosuid,nodev,

noexec,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,

codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0

 

A search of the Internet reveals very little about the Android file hierarchy. For Windows users, it is another world. For Linux users, it is a variation of the Linux file hierarchy. In Linux / Android / Unix (for simplicity, referred to a just Linux), the file hierarchy is a single tree, with the top of the tree being "/" - the root of the tree. Under "/" are files and directories. The Linux file hierarchy lacks the concept of drives, as in Windows. Instead, file systems are mounted on a directory to create a single integrated tree. For media based file systems. the file system represents a partition of some media. It makes no difference whether the file system exists on the local device, or on a remote device. Everything is integrated into a single file hierarchy that begins with root.

The term path refers to the path to a file or directory. The absolute path to any file or directory begins with "/" - root. For example, your file application may show the the path to the internal flash drive as /mnt/sdcard, or simply "sdcard." If your Android device includes an external SD Card, you will also see /mnt/extSdCard. The actual names may vary, but the concept remains the same. For example, CyanogenMod mounts the external flash drive appears on /mnt/sdcard, and the internal flash as /mnt/emmc. The important point to remember is that each of these directories represents a mount point for a file system. As a normal user, an Android file only displays the file systems to which you have access. These file systems are just a part of the entire file hierarchy.

To see the complete Android file hierarchy, you need "root" access. In this case, "root" refers to a special user account that has system administration privileges. When you "root" a Android device, you are gaining access to the root account. There is a reason for not automatically granting root access - one tiny mistake can go a long way. However, for those experienced in Linux commands and Linux system administration, it opens the hood to the underlying structure of Android.

Android File Systems

As mentioned in Android Kernel versus the Linux Kernel, Android uses the Linux kernel. All file, and directory, operations from an application flow through a kernel abstract layer called the Virtual File System (VFS). Each file system, and there are a lot of them, are implementations of VFS. Each file system has a separate kernel module that registers the operations that it supports with VFS. By separating the implementation from the abstraction, adding a new file system becomes a matter of writing another kernel module. These modules are either part of the kernel, or are dynamically loaded on demand. The Android kernel comes with a subset of the vast collection of file systems that range from the Journal File System (JFS) for AIX (IBM's flavor of Unix) to the Amiga file system. All the fancy footwork is hidden from the user, as the kernel handles all the work when it mounts a file system.

The kernel configuration file determines what file system modules are compiled, and whether they are built into the kernel, or dynamically loaded. Consequently, the Android kernel only contains those file system modules that are relevant to its operation. In fact, I don't know of a single Linux distribution that compiles every file system module, as some of the file systems are hardware architecture dependent. While the supported file systems vary on different Android devices, the common flash memory file systems are as follows:

• exFAT - The extended File Allocation Table is a Microsoft proprietary file system for flash memory. Due to the licensing requirements, it is not part of the standard Linux kernel. However, some manufactures provide Android support for the file system.

• F2FS - Samsung introduced The Flash-Friendly File System as an open source Linux file system in 2012.

• JFFS2 - The Journal Flash File System version 2 is the default flash file system for the AOSP (Android Open Source Project) kernels, since Ice Cream Sandwich. JFFS2 is a replacement to the original JFFS.

• YAFFS2 - Yet Another Flash File System version 2 was the default AOSP flash file system for kernel version 2.6.32. YAFFS2 is not supported in the newer kernel versions, and does not appear in the source tree for the latest kernel versions from kernel.org. However, individual mobile device vendors may continue to support YAFFS2.

Besides flash memory file systems, Android devices typically support the following media-based file systems:

• EXT2 / EXT3 / EXT4 - The EXTended file system is the standard Linux file system, with EXT4 being the current version. Since 2010, EXT4 is often used in place of YAFFS2 or JFFS2 as the file system for internal flash memory on Android devices.

• MSDOS - The MSDOS driver supports the FAT12, FAT16 and FAT32 file systems.

• VFAT - The VFAT is not actually a file system, but an extension to the FAT12, FAT16, and FAT32 file systems. Thus, you will always see the VFAT kernel module in conjunction with the MSDOS module. External SD Cards are commonly formatted using VFAT.

The above file systems are media-based file systems. VFS also supports pseudo file systems, which are not media based. The Linux kernel supports a number of pseudo file systems, the ones that are important to Android devices are:

• cgroup - The cgroup (control group) pseudo file system provides a means to access, and define, various kernel parameters. While cgroup is the pseudo file system, there are a number of different process control groups. If your Adroid device supports process control groups, you will find a list of the groups in the file /proc/cgroups. Android uses cgroups for acct (user accounting), and cpuctl (CPU control).

• rootfs - This file system serves as the mount point for the root file system ("/").

• procfs - The procfs file system is normally mounted on the /proc directory, and reflects a number of kernel data structures. The  operations on these files actually read live kernel data. The number directories reflect the process IDs (actually, the thread group leader process ID) for each running task. The /proc/filesystems file generates a list of the currently registered file systems. File systems followed by NODEV are  pseudo file systems, as there is no related device. The /proc/sys directory contains kernel parameters, some of which are tunable.

• sysfs - The device model for the kernel is an object-oriented structure that reflects the devices known by the kernel through the sysfs file system, which is normally mounted on the /sys directory. When a kernel discovers a new device, it builds an object in the /sys/devices directory. The kernel uses a network socket to communicate the new device information to the udevd daemon, which builds an entry in the /dev directory. The /sys/fs directory contains the kernel object structures for media based file systems. The /sys/module directory contains objects for each loaded kernel module.

• tmpfs - The tmpfs file system is often mounted on the /dev directory. Since it is a pseudo file system, any data in the /dev directory is lost when the device is rebooted.

While there seems like a lot of file systems, they are just the tip of the iceberg. For those without root access, these file systems and directories are hidden from your view, as you do not have the permission to access them. My Samsung Galaxy SIII provides a USB debugging option under Developer options in the Settings menu. When enabled this option allows one to connect to the Samsung Galaxy SIII using adb (Android Debug Bridge). While it only provides user level privileges, it does provide access to most directories and most of the Linux commands. This option may be available on other Samsung Android devices. You can also try the Terminal Emulator app. It works on my Samsung Galaxy SIII, as well as my B&N Nook Color running CyanogenMod 10 (Jelly Bean).

Android File Hierarchy

As mentioned above, the Android file hierarchy is a modified version of the traditional Linux file hierarchy. There are slight variations in the structure across the different version of Linux, and from different manufacturers. However, the variations are slight. The following gives a brief summary of the top levels of the directory structure for the AOSP release of Jelly Bean:

• acct - This directory is the mount point for the acct cgroup (control group), which provides for user accounting.

• cache - The mount point for the /dev/block/mtdblock2 partition (the partition name may vary). The size of the cache is limited to the size of this partition.

• d - A symbolic link to /sys/kernel/debug.

• data - The mount point for the /dev/block/mtdblock1 partition.

• default.prop - This file defines various default properties.

• dev - The mount point for a tmpfs file system, which defines the devices available to applications. The /dev/cpuctl directory is the mount point for cpuctl control group, using the cgroup pseudo file system.

• etc - A symbolic link to /system/etc.

• init - A binary program that processes the init.rc file. The init.rc file imports the other init.*.rc files. When booting Android, the kernel executes the init program at the end of its boot process. It is worth reading the init.rc file, as it tells the story of the configuration for the Android device. Since Android does not support /etc/sysctl.conf, the updates to the /proc/sys/kernel parameters are part of the init.rc file. Unless you have a good understanding of the internal workings of the Linux kernel, you should not modify these parameters. The same is true of the /dev/cpuctl parameters.

• mnt - Besides the mounts for the internal and external SD cards, these directory serves as a mount point for other file systems. The /mnt/asec directory is a mount point for a tmpfs file system, and is part of Android security. The /mnt/obb directory is a mount point for the tmpfs file system, and stores expansion files for applications whose files exceed 50MB. The /mnt/secure directory is another component of Android security. You may also see mount points for one, or more, USB devices.

• proc - Mount point for the procfs file system, which provides access to kernel data structures. Programs, such as ps, lsof, and vmstat, use the /proc as the source for their information.

• root - The home directory for the root account.

• sbin - While much smaller than the /sbin directory in a standard Linux distributions, it does contain the binaries for several important daemons.

• sdcard - A symbolic link to /mt/sdcard.

• sys - The mount point for the sysfs pseudo file system, which is a reflection of the kernel's device object structure. There is a lot of information in this directory, but it does require understanding of the kernel device model. In a nutshell, the directories represent kernel objects, and files are attributes of those objects.

• system - This directory is the mount point for the /dev/block/mtdblock0. Under this directory are the directories that you normally see under the root directory of a standard Linux distribution. These directories include bin, etc, lib, usr, and xbin.

• ueventd.goldfish.rc ueventd.rc - These files define the configuration rules for the /dev directory.

• vendor - A symbolic link to /system/vendor.

The above is just a thumbnail sketch of the Android file structure. To understand the workings of Android beneath the desktop, you need a fundamental knowledge of Linux, and the Linux command-line. For kernel parameters, you need a working knowledge of the Linux kernel. In future articles, I shall explore the Android file hierarchy in more detail.