Android Storage System-vold and Mountservice analysis (i)

Android Storage System (i)

Looking for a long time vold storage module knowledge, also merely for a period of time the Android source code, found that the Android storage system involved in the function call, and kernel between the top of the socket transmission is really a headache, in addition to the principle of organizing the entire architecture, Also have to repeatedly look at the source code, really depressed. depressed, or intends to see the experience of the paste and reference materials to organize, in the form of a post, for the Code of God reference, there is wrong place please correct, we communicate with each other, the following to enter the theme.

Android's storage system consists mainly of Volumemanager in the systemserver process, mountservice and vold processes.

They manage the system's storage devices and perform various operations such as Mount, unmount, format, and so on.

Figure 1 Android Storage System architecture diagram

Figure 2 schematic diagram of the Android storage system

"Important Composition Analysis"

1, Netlinkmanager

The full name is NetlinkManager.cpp located in the Android 4.x source location/system/vold/netlinkmanager.cpp.

The class primarily receives event messages from the kernel by referencing the OnEvent () method in the Netlinkhandler class, Netlinkhandler is located in/system/vold/netlinkhandler.cpp.

2, Volumemanager

The full name is VolumeManager.cpp located in the Android 4.x source location/system/vold/volumemanager.cpp. The primary function of this class is to receive event messages after Netlinkmanager processing.

Because we are here is the SD mount, so after Netlinkmanager processing message will be divided into five kinds, respectively: block, switch, usb_composite, battery, power_supply.

Here the SD card Mount event is block.

3, Directvolume

Located in/system/vold/directvolume.cpp. This class is a tool class that is primarily responsible for further processing of incoming events.

Block event can also be divided into: Add, removed, change, noaction these four kinds.

4, Volume

Located in/system/vold/volume.cpp, this class is the main class that is responsible for mounting the SD card. Volume.cpp is mainly responsible for checking the SD card format, as well as the composite requirements of the SD card mount, and through the socket to the message SD card mounted message to Nativedaemonconnector.

5, Commandlistener

The class is located in/system/vold/commandlistener.cpp, communicating with Nativedaemonconnector through the vold socket.

6, Nativedaemonconnector

This class is located in Frameworks/base/services/java/com.android.server/nativedaemonconnector.java. This class is used to receive an SD card mount message from Volume.cpp and pass it up.

7, Mountservice

Located in Frameworks/base/services/java/com.android.server/mountservice.java.

Mountservice is a service class that serves as a system service that provides management, querying, and so on for external storage devices. When the state of an external storage device changes, the class sends a notification to the upper-level application. This is a very important class in the Android system.

8, Storagemanaer

Located in Frameworks/base/core/java/andriod/os/storage/storagemanager.java.

As mentioned in the description of this class, this class is the interface of the system storage service. In the system setup, there are storage related items, and setting also registers the listener for that class.

StorageManager also registered his listener in the Mountservice, so this class is mainly used for upper-level applications to obtain the status of SD card.

"SD card Mount Process"

1, Kernel issued SD card insert uevent message.

2,netlinkhandler::onevent () receive the kernel issued by the uevent and parse.

3.volumemanager::handleblockevent () handles the event after the second step of processing.

4, Next Call directvolume::handleblockevent ().

There are a few highlights to be aware of in this approach: (1) The program will first traverse the MPath container to find if the sysfs_path corresponding to the event exists in the MPath container; (2) There are 4 ways to handle the action in the event: ADD, removed, change, noaction.

5. After the previous step, the directvolume::handlediskadded () method is called, and the disk insert message is broadcast in this method.

6,Socketlistener::runlistener () will receive directvolume::handlediskadded () broadcast messages. This method mainly completes the data acquisition in the event, through the socket.

7. Call the frameworklistener::ondataavailable () method to process the received message content.

8,Frameworklistener::d ispatchcommand () This method is used to distribute instructions.

9, in the Frameworklistener::d Ispatchcommand () method, through the RunCommand () method to invoke the corresponding instruction.

10, in the/system/vold/commandlistener.cpp has RunCommand () the concrete realization. This method can be found in this class: Commandlistener::volumecmd::runcommand (), the literal meaning of this method is to volume distribution instructions. The "Mount" function is executed in this method:Vm>mountvolume (arg[2]).

11, MountVolume (Arg[2]) is implemented in Volumemanager::mountvolume () , and V>mountvol () is called in the method.

12. The MountVol () method is implemented in Volume::mountvol (), which is a true mount function. (In this method, subsequent processing is in the method, and the corresponding message is broadcast to the upper layer during the mount process, via the SetState () function).

13, SetState (volume::checking) broadcast to the upper layer, is checking the SD card, ready to mount.

14,Fat::check ()? SD card Check method to check if the SD card is in fat format.

15,Fat::d omount () mount the SD card.

At this point, the SD mount has been initially completed, the next should be the SD card after the message sent to the upper layer, in 13 also mentioned, in the mount and check the process in fact also sent to the upper layer.

16. In the Mountservice constructor, the listener thread is turned on to listen for the socket information from Vold.

Thread thread = new Thread (mconnector,vold_tag)? Thread.Start ()?

17, Mconnector is the object of Nativedaemonconnector, Nativedaemonconnector inherited runnable and override the Run method. The listentosocket() method is invoked through a while (true) in the Run method to enable real-time monitoring.

18. In Listentosocket (), first establish the socket server with Vold communication and then call the ondaemonconnected () method in Mountservice.

19, the Ondaemonconnected () method is defined in the interface Inativedaemonconnectorcallbacks, Mountservice implements the interface and override the Ondaemonconnected ( Method This method opens a thread for updating the state of an external storage device, and the method for updating the state is also implemented in it.

20, and then back to Listentosocket, through the InputStream to get Vold to pass the event, and stored in the queue.

21. These event will then be removed in ondaemonconnected () through the queue. Take () method of the queues. and call the updatepublicvolumestate () method according to the different event, calling the updateexteralstate () in the Packagemanagerservice in the method method to update the state of the storage device.

22. The update is implemented through the Packagehelper.getmountservice (). Finishmediaupdate ( ) method.

23. In the Updatepublicvolumestate () method, the following code will be executed after the update:

bl.mListener.onStorageStateChanged ()?

In the Android source code/packages/apps/settings/src/com.android.settings.deviceinfo/memory.java, implemented the Storageeventlistener Anonymous inner class, and override the Onstoragestatechanged () method. Therefore, when the onstoragestatechanged () method is called in Updatepublicvolumestate (), it is also received in Memory.java. The status of the SD card is updated in the Memory.java after it is received in the setting interface and the system settings-storage. Thus the SD card mounts from the bottom to the upper layer.

In the next post I will analyze the source code of the Vold module and the Mountservice service, including the main function, Netlinkmanager, Netlinkhandler, the uevent that handles the block type, Processing Mountservice command, Volumemanager, Nativedaemonconnector and other source code, will soon meet with you, thank you for your support, welcome communication and Correction!

Android Storage System-vold and Mountservice analysis (i)