I. Analysis of process initiation and configuration files vold stands for volume daemon. In fact, it is responsible for completing the system's CDROM, USB large capacity storage, mmccard and other extended storage mounting tasks to automatically complete the daemon process. It supports hot swapping of these storage peripherals. There is a big difference between the vold System on Android and the GNU/Linux system. Here we mainly analyze the processing process of the vold System on Android.
Since Android 2.2, vold has been greatly changed and upgraded to vold 2.0. The previous configuration file is
System/etc/vold. conf, vold 2.0 is changed to system/etc/vold. fstab. 1. Start vold
Run the following command to start the vold daemon thread and create a socket in init. RC:
Service vold/system/bin/vold
Socket vold stream 0660 root Mount
Ioprio be 2
2. Configure vold. fstab
The format of the vold. fstab file is:
Format: dev_mount <label> <mount_point> <part> <sysfs_path1...>
Label:-label for the volume
Mount_point-where the volume will be mounted
Part-partition #(1 based), or 'auto' for first usable partition.
<Sysfs_path>-List of sysfs paths to source Devices
For example:
Dev_mount sdcard/mnt/sdcard 1/devices/platform/mxsdhci.0/mmc_host/mmc0
After Android 2.2, the SD Mount position is/mnt/sdcard.
Ii. Control Flow Analysis vold the code for SD card settings is located:
Packages/apps/settings/src/COM/Android/settings/deviceinfo/memory. Java
The Code of mountservice on the upper level of vold is located:
Frameworks/base/services/Java/COM/Android/Server/mountservice. Java
The Code processed by the vold underlying layer is located:
System/vold/
1. vold design architecture
Setting
|
Mountservice
|
Commandlistener
|
Volumemanager-netlinkmanager
|
Volume-directvolume
|
SD/USB device
Mountservice receives the setting changes and information from the underlying volumemanager, analyzes and judges the changes, and then uses the domountvolume command to the underlying layer.
During vold initialization, class netlinkmanager and volumemanager will be created, and class netlinkmanager will receive
The information from the underlying layer is sent to volumemanager for processing;
The important class volumemanager has only one instance. It is mainly responsible for vold management operations, managing multiple SD cards and various USB operations. The important class volume can have multiple instances, how many SD cards and USB cards are mounted, and how many SD cards and USB cards are mounted. Important class directvolume encapsulates many methods and attributes. Important class commandlistener receives commands sent by the upper mountservice through domountvolume, analyzes the commands, and transfers them to volumemanager for processing;
After the volumemanager processes the information, it may report the information to the upper-layer mountservice, or hand it to volume for specific operations (mounting SD, USB ).
2. the vold code implementation process is roughly divided into three steps:
1). Create link:
As a daemon, vold receives the driver information and sends the information to the application layer. It also accepts the commands at the upper layer and performs corresponding operations.
Therefore, there are two links:
(1) vold socket: responsible for transferring information between vold and the application layer;
(2) socket accessing udev: responsible for transmitting vold and underlying information;
Both links are created at the beginning of the process. 2). Guidance:
Here, the processing of existing peripheral storage devices is mainly performed when the vold is started. First, load and parse vold. fstab,
And check whether the mount point has been mounted (note: the purpose of checking the mount point here is not very clear !); Second, execute the mmccard mounting; finally, process the USB large-capacity storage. 3) event handling:
Here, two links are monitored to process dynamic events and respond to upper-layer application operations. Extended article http://blog.csdn.net/zoe6553/article/details/6115068
