全部博文(2005)
分类:
2008-12-05 11:31:56
Here is the overall picture.
There are two processes in the scenario. Mountd is a native application which does the real mount work. While MountService in system_server application is a JAVA layer service, it communicates with mountd through “/dev/socket/mountd” local UNIX domain socket.
Mountd first creates mount point list parsed from “/system/etc/mountd.conf” configuration file. Then it tries to mount devices defined in the configuration file. It opens another thread for automatically monitor inotify event for “/dev/block/” directory and uevent for USB mass storage. This thread is for monitor SD card and USB is plugged in or not. Finally in the main thread, mountd will listen on the ANDROID_SOCKET_mountd local UNIX domain socket to receive commands from MountService and send events to MountService.
The uevent for USB is observed if it contains these two strings: “POWER_SUPPLY_TYPE=USB”, “POWER_SUPPLY_ONLINE=”+[“1” | “0”].
The commands and events between MountService and mountd are all plain texts. It’s easy to understand.
MountService will broadcast the following intents for any interested clients if it receives any event from mountd:
ACTION_UMS_CONNECTED,
ACTION_UMS_DISCONNECTED,
ACTION_MEDIA_REMOVED,
ACTION_MEDIA_UNMOUNTED,
ACTION_MEDIA_MOUNTED,
ACTION_MEDIA_SHARED,
ACTION_MEDIA_BAD_REMOVAL,
ACTION_MEDIA_UNMOUNTABLE,
ACTION_MEDIA_EJECT.