Chinaunix首页 | 论坛 | 博客
  • 博客访问: 15531808
  • 博文数量: 2005
  • 博客积分: 11986
  • 博客等级: 上将
  • 技术积分: 22535
  • 用 户 组: 普通用户
  • 注册时间: 2007-05-17 13:56
文章分类

全部博文(2005)

文章存档

2014年(2)

2013年(2)

2012年(16)

2011年(66)

2010年(368)

2009年(743)

2008年(491)

2007年(317)

分类:

2008-12-05 11:31:56

[First written by Steve Guo, please keep the mark if forwarding.]

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.

阅读(2738) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~