Android usb流程分析.docx
《Android usb流程分析.docx》由会员分享，可在线阅读，更多相关《Android usb流程分析.docx（23页珍藏版）》请在冰豆网上搜索。
Androidusb流程分析
Androidusb流程分析
文档以UMS（usbmassstorage）为例来分析流程，主要按照图中红线来分析（即从插入USB开始到状态栏弹框，然后又从选择UMS功能开始往下的流程）。
以前没有看过USB相关代码,网上也很少有分析usbFRAMEWORK相关的东西，文档中可能存在错误，如果发现欢迎指正。
总体框图
1.KernelUSB流程
LINUXKERNELGADGET架构
LinuxUSBGadget分三层架构，层次关系从上到下
一层：
USBGadget功能层.BSP/Driver开发者通常是要实现这一层，从而实现一个具体的设备驱动，如Anddroid在此层实现了adb，mtp，mass_storage等。
浏览参考关注此层代码时，会发现“composite”是此层的关键字，此层中关键的数据结构是：
struct usb_composite_driver.这一层的驱动文件一般为：
driver/usb/gadget/android.c（android实现的）或driver/usb/gadget/serial.c（传统Linux实现的USB转串口）。
二层：
USB设备层（usbcore）.这一层是Linux内核开发维护者实现的，与我们没太大关系，不用我们操心，我们只关心其的一些接口就行.浏览参考关注此层时，会发现“gadget"是此层的关键字,此层的关键数据结构是：
usb_gadget_driver，usb_composite_dev。
这层主要的一个驱动文件为:
driver/usb/gadget/composite。
c
三层:
USB设备控制器驱动层。
这一层主要是与CPU、CPUUSB控制器有关，与硬件紧密相关，主要它和USB控制器牵扯在一起，涉及有寄存器、时钟、DMA等等。
但是这一层往往是由芯片厂商去实现。
我们一般仅需在板级文件中处理好所需要的USB接口即可。
这层的关键字就是“UDC”,主要驱动文件命名含“udc”关键字,一般与CPU或芯片厂商有关,如MTKUDC驱动在kernel/mediatek/platform/mt6592/kernel/drivers/usb20/目录下。
USBGadget的三层架构的关系
可以用一句简单的话去概括三层的关系：
USBGadget功能层调用USB设备层的接口，USB设备层调用USB设备控制器驱动层的接口，然后USB设备控制器驱动层回调USB设备层，USB设备层回调USBGadget功能层。
USB设备驱动层:
USBDEVICE注册
Mt_devs。
c
Driver:
Usb20.c（doov6592kk\kernel\mediatek\platform\mt6592\kernel\drivers\usb20）：
Probe:
重新注册了一个"musb—hdrc”设备,
然后在kernel/drivers/usb/musb/musb_core。
c加载musb—hdrc驱动，
执行PROBE,这里才是真正的加载驱动，内存,中断，DMA等资源申请，并初始化USB。
musb_probe→musb_init_controller→musb_gadget_setup→usb_add_gadget_udc加入了LINUXUSB框架了。
Android。
c
注册的android_usb_function：
在SYS下创建一系列文件,对应接口XX_show/store
充电器插入中断检测电路
USB插入中断流程：
USB插入中断
→WAKEUPPMICTHERAD
→if（（（（int_status_val_0）&（0x0400））〉〉10）==1）｛chrdet_int_handler（）；｝
→do_chrdet_int_task
→mt_battery_charger_detect_check
→mt_usb_connect
→musb_start（mtk_musb）;＊ProgramtheHDRCtostart（enableinterrupts，dma，etc.）。
→开始USB枚举
→android.candroid_setup
→android_work
→kobject_uevent_env
→USBserviceueventobserver收到UEVENT事件。
。
.。
PMIC中断,检测到充电器中断
Battery里判断chargertype,然后会使能USB，等待主机发枚举包。
收到主机发来的枚举包,会调用到android_setup完成枚举，android_setup会调用android_work发uevent事件。
2.UsbService相关
/＊*
＊UsbServicemanagesallUSBrelatedstate，includingbothhostanddevicesupport.
*HostrelatedeventsandcallsaredelegatedtoUsbHostManager，anddevicerelated
＊supportisdelegatedtoUsbDeviceManager.
*/
在systemserver中启动
并调用，
在USBDEVICEMANAGER里，得到NOTIFICATION_SERVICE，后面显示通知时用到。
上面newusbdevicemanager，在其构造函数中,newusbhandler
在usbhandler构造函数中，
上面那个文件是有kernelandroid.c里的设备,
当KERNELandroid_work发UEVENT时,UeventObserver会收到，执行onUEvent
Updatestate,给HANDLER发消息
Handler处理消息:
updateUsbNotification,STATUSBAR显示通知，com.android。
settings.UsbSettings，
updateAdbNotification提示ADB,com.android。
settings。
DevelopmentSettings。
LOG:
3.应用相关
3.1Statusbar：
Onresume中调用下面方法加载preferencescreen，
并获得USBMANAGER，在后面设置改变时会用到。
UsbManagerOverview
ThisclassallowsyoutoaccessthestateofUSBandcommunicatewithUSBdevices。
CurrentlyonlyhostmodeissupportedinthepublicAPI。
Youcanobtainaninstanceofthisclassbycalling Context。
getSystemService（）。
当设置改变时调用usbmanager的setCurrentFunction方法来设置USBFUNCTION。
往下的流程：
mUsbManager。
setCurrentFunction（function,makeDefault）;
→mService.setCurrentFunction（function,makeDefault）;
→mDeviceManager。
setCurrentFunctions（function，makeDefault）；
→mHandler.sendMessage（MSG_SET_CURRENT_FUNCTIONS，functions，makeDefault）；
→setEnabledFunctions
→setUsbConfig
→SystemProperties.set（"sys.usb。
config”,config）;
→initproperty_service
→init.rc
→内核SYS文件show/store完成KERNELUSBFUNCTIONbind。
kernelusbfunctionbind
3.2UsbStorageActivity
/＊*
*Thisactivityisshowntotheuserforhim/hertoenableUSBmassstorage
*on-demand（thatis,whentheUSBcableisconnected）.Itusesthealert
＊dialogstyle。
Itwillbelaunchedfromanotification。
*/
USBDEVICEMANAGER的handler处理中还会发送ACTION_USB_STATE的广播。
Sendboardcast，上面的LOG：
广播会被mountservice收到
因为如上图StorageNotification.start中通过storagemanager注册了listener，会huidaoStorageNotification（SYSTEMUI中）的onUsbMassStorageConnectionChangedAsync
onUsbMassStorageConnectionChangedAsync中会调到updateUsbMassStorageNotification
updateUsbMassStorageNotification，
提示UMS。
UsbStorageActivity中如果使能UMS，则会通过storagemanagerenableUsbMassStorage方法设置UMS。
往下流程分析：
mStorageManager.enableUsbMassStorage（）;
→mMountService.setUsbMassStorageEnabled（true）；
→往handler发H_UNMOUNT_PM_UPDATE消息，
→处理消息，mForceUnmounts。
add（ucb）；
→doUnmountVolume（path，true，removeEncryption）;
→回调UmsEnableCallBack。
handleFinished
→doShareUnshareVolume
→mConnector.execute（"volume"，enable?
”share”:
"unshare"，path，method）；
→VOLD下面就是VOLD的处理流程了.
4.Mountservice,storagemanager
/*＊
*MountServiceimplementsback—endservicesforplatformstorage
＊management。
*＠hide-Applicationsshoulduseandroid。
os。
storage。
StorageManager
＊toaccesstheMountService。
*/
和vold等合作起作用，主要负责监听并广播device的mount/unmount/badremoval等等事件。
mountservice启动也在systemserver中，如下图,构造函数中newNativeDaemonConnector，连接到VOLD.
5。
Vold（volumedaemon）
vold启动在init。
rc中：
入口：
/system/vold/main.cpp
流程图：
接上面的流程，mountservice发下来share的命令后（之前发了umount）,会到CommandListener。
cpp中VolumeCmd的runCommand.
VolumeManager:
:
shareVolume会将设备名
写入到sys下的一个文件，这个文件是由kernel的mass_storage_functioninit函数创建的，写入要分享的设备名就直接将这个设备share出去了。
问题：
1.只大概梳理了UMS，其他项MTP,PTP等都没分析。
2.内核USBCORE的功能比较复杂，没涉及，KERNELUSB功能绑定功能没有深入涉及。
3.本文档不涉及到USBHOST（特指KERNEL不原生支持的设备）。
升级会员 