Professional Documents
Culture Documents
PARTITION TABLE
The Phone's Internal Memory (eMMC or UFS; not the SD card) is solid-state (flash)
memory, aka NAND. Raw NAND, as it's called, is basically a pure flash memory dependent
on CPU to control it. But in order to use flash memory just like a traditional hard drive
(block device), NAND is equipped with an (embedded multimedia) micro-controller. It's
called eMMC.
eMMC can be partitioned much like a hard drive on PC. PC's have traditionally been
partitioned with BIOS compatible Master Boot Record (MBR) scheme in which first sector
of disk contains the details of partitions called Partition Table. Limited size of boot sector
(512 bytes) puts a limitation of at maximum 4 (primary) partitions listed in MBR. Extended
partition has been used for 4+ partitions.
GUID Partition Table (GPT) was introduced with UEFI booting system which isn't
dependent on first boot sector and hence may contain up to 128 partitions. GPT also does
CRC check, has backup GPT, identifies partitions by GUID and partitions have a label.
Android devices use GPT. We can view and manipulate GPT using Linux tools such as
parted and gdisk while fdisk is the traditional tool for MBR partitions.
To view partition table on internal memory:
Code:
~# parted /dev/block/mmcblk0
(parted) p free
~# gdisk -l /dev/block/mmcblk0
(The external SD Card can also be partitioned to include a section dedicated to storing user
apps (like Link2SD does) or to create partitions for secondary or tertiary OS on Android
device using some multiboot kernel and recovery system). Even we can put whole OS/ROM
on an SD card.
2. BRIEF INTRO
Contents of Android partitions can be partially or completely modified by flashing an
image (filesystem .img or executable binary or a flashable zip) to them. But we never need
to modify most of them and whatever manufacturer wrote on them, resides there
unmodified (read-only) for the whole of device life. A user uses only one partition /data to
save personal data like photos, music etc. All the other are for device to run. There are
typically in the range of 50 partitions on an Android device but only a few partitions are
modified for the purpose of adding new features or upgrading the device. A custom ROM
or minor upgrade is also limited to modify /boot, /system and /data partitions usually.
Most of the partitions are almost intact, containing bootloaders, firmwares, settings etc.
Here is a "summarized" detail to these partitions which matter to a common but interested
user.
On most devices /system and /data are larger partitions (on some devices /custom or
a similar partition too) covering almost 90% of eMMC. All others are smaller ones of a few
KB's or MB's.
4. BOOTLOADERS
Bootloaders - in many steps - hand over charge to kernel after loading in RAM. These are
mostly standalone ELF executable files becuase at this stage no filesystem is loaded and
only executable code may work. These are all closed source components on Android
device, provided by SoC vendors - either built-in or as binary blobs.
SBL - Secondary bootloader loaded by SoC, loads ABOOT in memory, also provides
(Emergency) Download Mode (EDL) on many devices, a Firmware Update Protocol.
ABOOT (bootloader.img or aboot.mbn file in Factory Firmware) - Applications Bootloader is
the main bootloader responsible for loading kernel or recovey and fastboot - a Firmware
Update Protocol - as well.
Kernelflinger is a similar bootloader on Intel devices.
• vmlinux: Large sized non-bootable Linux kernel (executable) with debug symbols,
just an intermediate step to producing vmlinuz
• vmlinux.bin: Same as vmlinux binary but with removed symbols, produced by
'objcopy'
• vmlinuz: Compressed and bootable Linux kernel file; one of zImage or bzImage
formats; compressed using zlib, LZMA, gzip or bzip2 etc.
• zImage: Smaller format, for old kernels
• bzImage: Big zImage
• Image: vmlinux.bin of embedded devices
• Image.gz: zImage or bzImage of embedded devices
SYSTEM - ROM / OS
Contains system applications and libraries that have AOSP source code. During normal
operation, this partition is mounted read-only; its contents change only during an OTA
update or when flashing a new OS. Most ROM's don't allow root level (Admin rights in
Windows) access by default. So, "rooting" is required to modify the contents of this
partition. This is the actual User Interface we use on our phone i.e. system apps are
installed on this partition on /system/app directory. Another important directory is
/system/bin which contains executable binaries to perform each and every action by OS in
background (as daemons) or by user in shell (bash) scripts or CLI (command line interface).
These are native binaries (developed in C / C++ mostly) as opposed to Android apps which
are developed in Java. A minimal form of Linux commands is also included in AOSP as
toolbox or toybox (or user can add busybox or individual static binaries). /system/lib
directory contains native libraries (shared by applications commonly) with .so extensions
just like .dll on Windows.
VENDOR
This partition is replaced with a shortcut (symbolic link in fact) to /system/vendor directory.
It contains system applications and libraries that do not have source code available on
AOSP but added by vendors (OEM's). During normal operation, this partition is mounted
read-only; its contents change only during an OTA update. It also contains SoC firmware
images i.e. hardware specific libraries and binaries (OpenGL, ISP...).
Proprietary blobs (HALs) usually live in (/system)/vendor as shared libraries (.so files) which
are loaded by Android binders when processes call a hardware component. HAL (hardware
abstraction layer) is userspace alternative to traditional Linux's system calls for drivers and
is a kind of Google's standardization for OEMs/hardware vendors, though being
abandoned by mainstream Linux.
PROJECT TREBLE
In an ideal world, there should be a generic AOSP OS and a single kernel for all Android
devices, not tied to hardware and vendors. But unfortunately it isn't so because unlike PC
world, there is no standardization in mobile world. AOSP is heavily modified on silicon
vendor (SoC) as well as phone vendor level. One of the worst outcome of this situation is
almost no Long Term Support (LTS). There are delayed or none updates once the
consumers have phone, making it vulnerable to security issues and missing new features.
Project Treble (starting from Android-8) addresses this issue somewhat by creating a
separation between hardware specific code and generic AOSP code.
Previously, phone vendors used to get AOSP code from Google, mixing it with their own
cutomizations (UI, apps etc.) and the hardware specific code from SoC vendor. If a minor
fix needed to be applied to AOSP code, the whole process had to be repeated because
code was intermingled and fixing one thing broke the other. Google resolved this issue by
specifying /vendor partition for hardware specific code, /system containing only generic
code. Interaction with AOSP code will be through HIDL interfaces, thus making it possible
to upgrade the both codes independently. /oem and /odm partitions were added
previously for the same purpose.
USERDATA
User applications are installed in different folders under /data. Apps data (user and system)
is stored in /data/data. User personal data and some apps data is stored in /data/media.
/data/media is also emulated as internal SDCard at /storage/emulated and symlinked at
/sdcard. Personalized and apps settings are also stored in this partition. A folder
/data/dalvik contains, in simple words, extracted apps to boost loading process. Java
bytecode of Android apps is converted to executable code (.odex) by Dalvik Virtual
Machine, separate instance of which is launched by zygote (an Android init daemon) for
every app.
This partition is not normally touched by the OTA update process. A Factory Reset wipes
this partition, normally excluding /data/media i.e. personal data.
When you do a factory reset (AKA: wipe, hard reset, factory wipe, etc.), you are erasing
the /data and /cache partitions. Note that a factory reset does NOT put your phone back
to its factory state from an OS standpoint. OS upgrades will stay because the OS lives in
/system, and that is not touched during a factory reset. So it's not a factory reset. It's a
factory DATA reset actually.
RECOVERY
Holds alternate boot partition and the recovery program that lets the device boot into a
recovery console for performing advanced recovery and maintenance operations. It
contains a second complete Linux system i.e. independent OS, including a user-interface
application, kernel and the special recovery binary that reads a package and uses its
contents to update i.e. flash or wipe itself or any other partition particularly during OTA
updates.
Recovery is also the most commonly used method to flash custom ROM's.
ADB sideload mode through PC is a replacement of flashing files (usually .zip) through
Recovery. ADB works when phone is switched on in Recovery (or ROM). ADB/fastboot
setup is to be made on PC to use this mode.
CACHE - cached (frequently accessed) data from OS usage and contains the firmware
update package downloaded from server during OTA updates. Temporary holding area
used by a few applications with the expectation that files can disappear at any time. Major
use is by recovery and OTA updates. Recovery last_log is also written to this partition.
6. OTHER PARTITIONS
CUST - also CUSTOM or PRELOAD on some devices, it's used by stock ROM's, holding
some preloaded system apps and regional settings which are installed on first use.
PERSIST - contains data which shouldn't be changed after the device is shipped, e.g. DRM
related files, sensor reg file (sns.reg) and calibration data of chips; wifi, bluetooth, camera
etc.
Some package installers such as OpenGapps also make use of this partition to read
configuration file.
OEM - like VENDOR, it incorporates OEM (Original Equipment Manufacturer i.e. hardware
manufacturer or Mobile Phone brand) small customization (modifications) to original
Android (AOSP) during OTA updates such as customized system properties values etc.
PAD - related to OEM
OTA, FOTA - OTA updates
DDR - Double Data Rate RAM
FSC - Modem FileSystem Cookies
SSD - Secure Software Download, a memory based file system for secure storage, stores
some encrypted RSA keys
DEVINFO - device information including: is_unlocked (aboot), is_tampered, is_verified,
charger_screen_enabled, display_panel, bootloader_version, radio_version etc. Contents of
this partition are displayed by "fastboot oem device-info" command in human readable
format. Before loading boot.img or recovery.img, bootloader verifies the locked state from
this partition.
CONFIG/FRP/PDB - saves state of Factory Reset Protection (FRP), "Allow bootloader (OEM)
unlocking" . (Developer Options), asks already associated account info. This partition is
erased/reset if Factory Reset done from Settings.
DEVCFG - used by TZ for upgrades
LKSECAPP - "LK (Little Kernel) Security App", related to RPM, TZ online verification / update
LIMITS - Qualcomm Limits Management Hardware (LMh) driver in SBL writes the data in this
partition to use for later reboots
SYSCFG - Qualcomm CPR (Core Power Reduction) Regulator for better performance and
power saving of application processor by voltage control
DIP, MDTP - boot verification, use Qualcomm SafeSwitch technology to lock and track theft
phones
CMNLIB, KEYMASTER - verified boot
SEC - contains fuse settings, mainly for secure boot (signing bootloaders for chain of trust)
and oem setting
KEYSTORE - related to /data Full Disc Encryption (FDE)
MCFG - (Modem Configuration Framework) - on dual SIM devices, loads MBN (modem
binary) files depending on SIM/carrier
SPLASH - splash image or boot logo which appears when device boots (at ABOOT stage).
CHGLOGO - charging screen that appears when charger is connected to powered off device.
MSADP, APDP, DPO - related to debug policies
GROW - empty for future expansion
7. FILESYSTEMS
Supported filesystems by your kernel can be viwewd by:
Code:
~# cat /proc/filesystems
Other partitions don't contain a mountable filesystem. However, we may try to get an idea
of the contents by reading smaller partitions e.g.:
Code:
~# cat /dev/block/bootdevice/by-name/config | strings
~# cat /dev/block/bootdevice/by-name/misc | strings
ROM Development
A ROM developer downloads AOSP source code from Google while device tree, driver
binaries and kernel source code is provided by (ODM's through) OEM's, if they are
generous enough. OEM's manufacture and sell devices themselves while ODM's sell to
white-labelers who brand them under their own names. Original Android kernel tree is
provided by Google which in turn is taken from Linux and then modified by Google for
Android-specific needs.