Android File Management

Like any other Linux-based distribution, Android uses a root filesystem to store
applications, libraries, and data. Unlike the vast majority of Linux-based
distributions, however, the layout of Android’s root filesystem does not adhere
to the Filesystem Hierarchy Standard (FHS).

The two main directories in which Android operates are /system and /data.
These directories do not emanate from the FHS. In fact, none of the mainstream
Linux distribution that uses either of these directories. Rather, they reflect the
Android development team’s own design. This is one of the first signs hinting
that it might be possible to host Android side by side with a common Linux
distribution on the same root filesystem.

/system is the main Android directory for storing immutable components

generated by the build of the AOSP(Android Open Source Project). This
includes native binaries, native libraries, framework packages, and stock apps.
It’s usually mounted read-only from a separate image from the root filesystem,
which is itself mounted from a RAM disk image. /data, on the other hand, is
Android’s main directory for storing data and apps that change over time. This
includes the data generated and stored by apps installed by the user alongside
data generated by Android system components at runtime. It, too, is usually
mounted from its own separate image, though in read-write mode.

Android also includes many directories commonly found in any Linux system,
such as /dev, /proc, /sys, /sbin, /root, /mnt, and /etc. These directories often
serve similar if not identical purposes to the ones they serve on any Linux
system, although they are very often trimmed down, as is the case of /sbin and
/etc, and in some cases are empty, such as /root.

Interestingly, Android doesn’t include any /bin or /lib directories. These

directories are typically crucial in a Linux system, containing, respectively,
essential binaries and essential libraries. This is yet another artifact that opens
the door for making Android coexist with standard Linux components.
The figure below illustrates how the images typically created by the build
system relate to one another at run time.

Android root filesystem

In essence, the kernel mounts the RAM disk image generated by the build
system as its root filesystem and launches the init process found in that image.
That init process’s configuration files will, cause a number of additional images
and virtual filesystems to be mounted onto existing directory entries in the root
filesystem.
The Root Directory
The classic structure of Linux root filesystems is specified in the Filesystem
Hierarchy Standard (FHS). Android, however, doesn’t abide by the FHS, but
relies heavily instead on the /system and /data directories for hosting most of its
key functionality.

Android’s root directory is mounted from the ramdisk.img generated by the

AOSP’s build system. Typically, ramdisk.img will be stored along with the
kernel in the device’s main storage device and loaded by the bootloader at
system startup. Below are the contents of the root directory once mounted.

Table 6-1. Android’s root directory

Entry Type Description

Entry Type Descriptiom
Entry Type Description
/acct dir cgroup mount-point.

/cache dir Temporary location for downloads in progress and other nonessential
data .

/d symlink Points to /sys/kernel/debug, the typical mount location for debugfs.a

/data dir The mount-point for the data partition.

Usually, the contents of userda ta.img are mounted here.

/dev dir Mounted on tmpfs and contains the device nodes used by Android.

/etc symlink Points to /system/etc.

/mnt dir Temporary mount-point.

/proc dir The mount-point for procfs.

/root dir In traditional Linux systems, the root user’s home directory. It’s generally
empty in Android.

/sbin dir In Linux, this would hold binaries essential to the system administrator. In
Android, it contains only ueventd and adbd.

/sdcard dir The mount-point for the SD card.

/sys dir The mount-point for sysfs.

/system dir The mount-point for the system partition. system.img is mounted to this

/vendor symlink Generally a symbolic link to /system/vendor. Not all devices actually
a /system/vendor directory.
/init file The actual init binary executed by the kernel at the end of its initialization.

/init.rc file init’s main configuration file.

/init.<device_name>.rc file The board-specific configuration file for init.

/ueventd.rc file ueventd’s main configuration file.

/ueventd.<device_name>.rc file The board-specific configuration file for ueventd.

/default.prop file The default global properties to be set for this system. These are
automatically loaded by init at startup

/system

As mentioned earlier, /system contains the immutable components generated by

the AOSP build system

To illustrate this further, the Figure below takes the Android architecture
diagram presented and shows where each part of the stack is found in the
filesystem.

Filesystem location of key Android components

As you can see, most of the components are found somewhere within /system
once system.img is mounted. Below the contents are described in detail.

Table /system directory contents

Entry Type Description

Entry Type Descriptiom

/app dir The stock apps built as part of the AOSP, such as the browser,
email app, calendar, etc. All modules built with
BUILD_PACKAGE are here.

/bin dir All native binaries and daemons built as part of the AOSP. All
modules built with BUILD_EXECUTABLE are here. The only
exception is adbd, which has the LOCAL_MODULE_PATH set
to /sbin and is therefore installed there instead.

/etc dir Contains configuration files used by various daemons and

utilities, including possibly an init.<device_name>.sh script
that would be launched by one of init’s configuration files at
startup

.
/fonts dir The fonts used by Android.

/framework dir Framework .jar files.

/lib dir The system’s native libraries. Essentially this means any
module built using BUILD_SHARED_LIBRARY. It’s important to
note again that Android doesn’t use /lib at all, only this lib
directory within /system.

/modules dir An optional directory for storing the dynamically loadable kernel
modules required to run the system.

/usr dir A miniature /usr akin to the classic /usr directory found in
traditional Linux systems.

/xbin dir “Extra” binaries generated by some of the packages that are
built within the AOSP but aren’t essential to the system’s
operation. This includes things like strace, ssh, and sqlite3
.
/build.prop file A set of properties generated during the build process of the
AOSP. They are loaded by init at startup

/data

As discussed earlier, /data contains all data and apps that can change over time.
For example, all the data stored by apps you download from Google Play is
found here. The userdata.img image generated by the AOSP’s build system is
mostly empty, so this directory starts off containing little to nothing. As the
system starts getting used, however, the content of this directory is naturally
populated, and it becomes important to preserve it across reboots. This is why
/data is typically mounted in read-write mode from persistent storage. The table
below shows the contents.

Table /data directory contents

Entry Type Descriptiom

/anr dir ANR traces.

/app dir Default install location for apps.

/app-private dir Install location for apps with forward locking.a This
Mechanism has been replaced with an API . allowing app
developers to check if the running app is a legitimate copy
obtained from Google Play
.
/backup dir For use by the BackupManager system service.

/dalvik-cache dir Holds the cached JIT’edb versions of all dex files.

/data dir Contains one subdirectory for each app installed on the
system. In effect, this is where each app’s “home” directory
is located
/dontpanic dir Last panic output (console and threads)—for use by
dumpstate
.
/local dir Shell-writable directory. In other words, any user who can
 shell into the device, using adb shell, for example, can
copy anything, including binaries, into this directory and it
will be preserved across reboots.

/misc dir Miscellaneous data such as for WiFi, Bluetooth, or VPN.

/property dir Persistent system properties.

/secure dir Used to store user account information if the device uses
an encrypted filesystem.

/system dir Systemwide data, such as the accounts database and the
list of installed packages.

/tombstones dir Whenever a native binary crashes, a file whose name is

tombstone_ followed by a sequence number is created
here with information about the crash.

SD Card

As discussed earlier, consumer devices typically have a microSD card that the
user can remove and plug into her computer. The content of this SD card is not
critical to the system’s operation. In fact, you can relatively safely wipe it out
without adverse effects. If a real user is using the device, however, you’ll at
least want to understand what’s on it, because some apps store their information
on the SD card, and it might matter to the user.