六、UsbDeviceManager及功能设置流程

转载 2013年12月04日 11:07:53

转自:http://blog.sina.com.cn/s/blog_6100a4f10101efob.html

一 光盘bicr的流程(UsbDeviceManager.java

1.1 光盘backfile的控制

sys.usb.mtk_bicr_support:这个值系统变量用来标识是否显示光盘内容,两个值yesyes_hide.

这个值的初始化发生在UsbDeviceManager.java文件里

if(nativeInitUMSproperty())

      SystemProperties.set("sys.usb.mtk_bicr_support","yes");

static jboolean android_server_UsbService_initUMSproperty(JNIEnv *env, jobject thiz)

{

#ifdef MTK_BICR_SUPPORT

    return true;

#else

    return false;

#endif

}

是否支持光盘内容弹出通过MTK_BICR_SUPPORT宏来决定。光盘作为mass_storage的一个子类,只要在使能了mass_storage 功能后,并且在mass_storage驱动中定义了cdromlun个数非0后,就会在pc上出现光驱。但是是否有文件系统还需要一个步骤。上面的sys.usb.mtk_bicr_support就是用来控制这个功能的开关。

该值为yes的话就会触发文件系统的挂载。

总体流程:

UsbDeviceManager.javashowBuiltinInstallerUI,启用了BuiltinInstallerActivity。这个activity会弹出对话框询问用户是否需要光盘,其实是是否挂在光盘内容。

Mountservice.java中,shareCDRom---doshareunshareCDRom--mconnector.doCommand

进入nativedaemonconnector.java  docommand--

经过jni进入到comandlistener.cpp该文件位于vold文件夹内,

执行CDROMCmdrunCommand函数,执行bicr.cppshareCdRom函数,

const char *Bicr::CD_ROM_PATH            = "/dev/block/loop0";

const char *Bicr::CD_ROM_LUN_PATH        = "/sys/class/android_usb/android0/f_mass_storage/lun-cdrom/file";

最后通过else if (write(fd, CD_ROM_PATH, strlen(CD_ROM_PATH)) < 0) {

完成了文件对应介质的操作。

1.2 光盘backfile的触发启动

PR:那么showBuiltinInstallerUI是什么时候启动的呢?挂载的介质在拔除usb cabel时有没有被清掉呢?防止下次在界面中虽然设置了hide,依然会显示光盘内容?所以应该是在拔除这个动作发生时清除才对。代验证。

第一种情况:系统启动完成时,但是要判断usb是否连接着,连接着才会考虑

        if(action.equals(Intent.ACTION_BOOT_COMPLETED)) {

               Slog.i(TAG, "BOOT_COMPLETED");

               Handler showBuiltinInstallerHandler = new Handler();

               showBuiltinInstallerHandler.postDelayed(mShowBuiltinInstallerRunnable, 14000);

            }

        private Runnable mShowBuiltinInstallerRunnable = new Runnable()

        {

            @Override

            public void run()

            {

                Slog.i(TAG, "Delay show");

                showBuiltinInstallerUI(mConnected);

            }

        };

系统上电的时候

 else if(action.equals(IPO_POWER_ON)) {

                    SXlog.d(TAG, "onReceive - [IPO_POWER_ON] mDefaultFunctions: " + mDefaultFunctions + ", mSettingUsbCharging: " + mSettingUsbCharging);

                    if (mSettingUsbCharging) {

                        mSettingUsbCharging = false;

                        setCurrentFunction(mDefaultFunctions, false);

                    }

                    showBuiltinInstallerUI(mConnected);

收到更新消息,并且是发生了硬件重新插拔动作才进行处理,所以如果仅仅是软的连接不会发生这个动作

        public void handleMessage(Message msg) {

            switch (msg.what) {

                case MSG_UPDATE_STATE:

                    mConnected = (msg.arg1 == 1);

                    mConfigured = (msg.arg2 == 1);

                    updateUsbNotification();

                    updateAdbNotification();

                    if (containsFunction(mCurrentFunctions,

                            UsbManager.USB_FUNCTION_ACCESSORY)) {

                        updateCurrentAccessory();

                    }

                                     //注意下面这个处理,当usb状态位connect(false)function会切换到默认的功能上,变成false有两种情况:1 软断,这种断开后会紧跟着一个设置会进来,这种情况是为了设置新的,才会先断一下,所以要设置的会生效2、真断,这种就是硬件上断开、拔除了,下面这部分代码会将其设置到默认的function。(目前打算是在setting中设置功能,但是每次设置完后,等再次插入时,又会恢复到默认的状态,mHwDisconnected标识硬件上是否连接的状态)

                    if (!mConnected && !mSettingUsbCharging) {

                        // restore defaults when USB is disconnected

                        SXlog.d(TAG, "handleMessage - MSG_UPDATE_STATE - mConnected: " + mConnected + ", mSettingUsbCharging: " + mSettingUsbCharging);

                        setEnabledFunctions(mDefaultFunctions, false);

                    }

                    if (mBootCompleted) {

                        updateUsbState();//将传过来的最新usb信息更新到UsbManager及其他全局变量中

 

                        Log.w(TAG, "handleMessage mConnected:" + mConnected + ",mConfigured:" + mConfigured +

                                                                                                  ", mHwDisconnected:" + mHwDisconnected + ", mHwReconnected:" + mHwReconnected);

                        if(mHwReconnected == true && mConnected == true) {

                            showBuiltinInstallerUI(true);//只有当硬件重新连接过,才会重新挂载介质

                            mHwReconnected = false;

                        }

                    }

                    break;

                   下面这个函数用来更新状态,发送消息,随后上面的 handleMessage进行处理

                 public void updateState(String state)

这个updateState的触发是有kernel层上来的,kernel层会发出uevent消息,所以上面需要接收、处理uevent消息。

如下:

    private final UEventObserver mUEventObserver = new UEventObserver() {

        @Override

        public void onUEvent(UEventObserver.UEvent event) {

            if (DEBUG) Slog.v(TAG, "USB UEVENT: " + event.toString());

 

            String state = event.get("USB_STATE");

            String accessory = event.get("ACCESSORY");

 

//Added for USB Develpment debug, more log for more debuging help

            if(DEBUG) Log.w(TAG, "mUEventObserver: onUEvent: state = " + state);

//Added for USB Develpment debug, more log for more debuging help

 

            if (state != null) {

                mHandler.updateState(state);

            } else if ("START".equals(accessory)) {

                if (DEBUG) Slog.d(TAG, "got accessory start");

                setCurrentFunction(UsbManager.USB_FUNCTION_ACCESSORY, false);

            }

        }

    };

下面看一下        mHandler = new UsbHandler(thread.getLooper());

    private final class UsbHandler extends Handler {

这个UsbHandler是一个主要的usb处理类。

 

    public void updateState(String state) {

………………

            Message msg = Message.obtain(this, MSG_UPDATE_STATE);

            msg.arg1 = connected;

            msg.arg2 = configured;

            // debounce disconnects to avoid problems bringing up USB tethering

            if (mHwDisconnected || mSettingUsbCharging) {

                SXlog.d(TAG, "updateState - UPDATE_DELAY  " + state + " mSettingFunction: " + mSettingFunction);

                sendMessageDelayed(msg, (connected == 0) ? UPDATE_DELAY : 0);

            }

………………

updateState函数中,通过传进来的state,重新调整了connected  configured两个参数,并传递了消息。

然后回到了上面的第三种情况中的消息处理函数handleMessage

root@android:/sys/class/android_usb/android0 # cat state

CONFIGURED

updateState函数中有4state状态:

HWDISCONNECTED 硬件上拔除了usb cabel

DISCONNECTED 这个应该是软拔除,现在理解是软件上的一种设置

CONNECTED 已经连接上了

CONFIGURED 已经配置完成

其中有一个重要变量mHwReconnected用来记录这次连接是否是硬件的再次连接,而不是软件设置上的重新连接。

1.3 光盘backfileunshare

上面有一个疑问是,什么时候将光盘的文件系统介质拿掉的。如下,通过下面的receiver接收到usbactionACTION_USB_STATE,如果发生了拔除动作,则shareCDRom(false)卸载掉文件系统介质。

// This class is used to close BuiltInstallerActivity and ims service unMount if it is mounted

public class BuiltinInstallerReceiver extends BroadcastReceiver {

    private static final String TAG = "BuiltinInstallerReceiver";

    @Override

    public void onReceive(Context context, Intent intent) {

        String action = intent.getAction();

        if (UsbManager.ACTION_USB_STATE.equals(action)) {

            boolean connected = intent.getExtras().getBoolean(UsbManager.USB_CONNECTED);

            if (!connected && BuiltinInstallerActivity.getSharedStatus()) {

                try {

                        IMountService ims = BuiltinInstallerActivity.getMountService();

                        if (ims == null) {

                           Log.e(TAG, "Cant get mount service");

                        }

                        ims.shareCDRom(false);

                        BuiltinInstallerActivity.setSharedStatus(false);

                        Log.i(TAG, "STOP sharing builtin installer");

                    } catch (RemoteException e) {

                        Log.e(TAG, "Cant call mount service");

                    }

            }

        }

    }

这个receivermanifest.xml中定义,这种方式类似于下面这种注册的方式     

registerReceiver(mUsbStateReceiver, new IntentFilter(UsbManager.ACTION_USB_STATE)); 

这个receiver收到广播消息后,调用了BuiltinInstallerActivity这个类的static成员函数。而当时修改去掉对话框的方式时没有启动这个activity,导致其中的static成员状态没有被更新。导致再拔除usb时,这个reciever获取不到正确的信息,不能卸载介质。(当发生了拔除动作,并且当前处于share状态,才进行unshare的动作)。这也是我当时去掉对话框后,留下的隐患,查看/sys/class/android_usb/android0/f_mass_storage/lun-cdrom/file始终是/dev/block/loop0

 这块对类的理解:BuiltinInstallerActivity类是一个特殊的对象,外界可以直接调用他的static成员,又可以实例化对象,被实例化的对象之间可以通过static通信,static有点像全局变量,类这个大家庭的全局变量。

 

PR:所以下面的问题就是消息的问题,当usb没有发生硬插拔时是广播的什么消息?可以确认的是即使广播的消息没有触发showBuiltinInstallerUI动作,也没有关系。因为由于上面BuiltinInstallerReceiver 的错误处理,一直都没有unshare光盘的介质,导致后期一直都处于share状态。也就是说直接有是否使能mass_storage 这个功能来决定是否弹出光盘(本来应该是两个决定因素:1 使能mass_storage 功能,2 share 介质)。

1.4 设置usbfunction的动作

PR:2012-07-04添加了复选框用来使能光盘or not。主要是通过addFunctionremoveFunction两个动作来处理usbfunction的。但是当使能光盘时,sys.usb.config变为mtp,adb,mass_storage不在init.usb.rc中,所以这个时候就会setUsbConfig失败,转而重新设置为刚才的(mtp,adb).

所以复选框的功能是否应该更改为:1 setCurrentFunction(“mass_storage”). 2 setCurrentFunction(“mtp,adb”).其中2还要看是否使能了debug,如果没有的话还得去掉。

所以这个部分现在只是行为方式上的定义,以及编译时对persist.sys.usb.config的控制(去掉mass_storage).

 

对于在调用setCurrentFunction后的动作中,有很多猫腻。setCurrentFunction发送消息,随后在处理函数中调用setEnabledFunctions完成整个设置过程,但这个setEnabledFunctions有对usb function的各种各样的变化。下面看看setEnabledFunctions的处理思路:

setEnabledFunctions(String functions, boolean makeDefault) {

mDefaultFunctions:代表系统默认的functionpersist.sys.usb.config

mCurrentFunctions:代表系统当前的usb function

mSettingFunction 代表当前要设置的function

functions:参数传入时代表当前要设置的function,但是这个值会在这个函数内部根据系统的功能发生变化,如当定义了cdrom,它会默认加入mass_storage功能等,所以最后设置的functions将有可能不是最初传入的function,最初传入的function一直保存在mSettingFunction中。

根据是否override persist.sys.usb.config进行了分支,persist.sys.usb.config考虑是否被修改为 makeDefault

 else {

                if (functions == null) {

                    functions = mDefaultFunctions;//如果传入参数为空,使用persist.sys.usb.config

                }

 

                // Override with bootmode specific usb mode if needed

                functions = processOemUsbOverride(functions);//留给oem一个插一杠子的机会

                    mSettingFunction = functions;

                            //如果要启用MTP function,并且系统还定义了光驱功能,那么就需要在加入一个mass_storage function,有点强奸民意的意思。在驱动中使能了光盘,上层应用就一定要用么?会什么和MTP还有关系呢?难道是,系统默认的存储一个是UMS一个是MTP,两个功能必用一个。如果定义了MTP,又定一个了光盘,那就说明要加入mass_storage,如果没定义MTP,那系统一定定义了mass_storage功能,所以不用再加入,什么狗屁逻辑!都是自我揣测。

                if (mUmsAlwaysEnabled && containsFunction(mSettingFunction, UsbManager.USB_FUNCTION_MTP)) {

                    functions = addFunction(functions, UsbManager.USB_FUNCTION_MASS_STORAGE);

                }

//mSettingUsbCharging UsbManager.USB_FUNCTION_CHARGING_ONLY代表usb只用来充电,这块的意思是如果在非只充电的情况下,用户的function设置,必须遵循系统的一些特性,尊重系统的adb功能,用户的设置会被改动

                if (mAdbEnabled && !mSettingUsbCharging) {

                    functions = addFunction(functions, UsbManager.USB_FUNCTION_ADB);

                } else {

                    functions = removeFunction(functions, UsbManager.USB_FUNCTION_ADB);

                }

//acmadb类似,注意这几个系统级别的function的顺序

                if (mAcmEnabled && !mSettingUsbCharging) {

                    functions = addFunction(functions, UsbManager.USB_FUNCTION_ACM);

                } else {

                    functions = removeFunction(functions, UsbManager.USB_FUNCTION_ACM);

                }

                if (!mCurrentFunctions.equals(functions)) {//看看是否需要设置,和当前功能没变化就不用设置了

                    if (!setUsbConfig("none")) {

                                   //先把功能设置成none,相当于软断开,如果失败,则切换到当前的function

                        Slog.e(TAG, "Failed to disable USB");

                        // revert to previous configuration if we fail

                        setUsbConfig(mCurrentFunctions);

                        return;

                    }

                                   //切换到当前需要的功能上,如果切换失败,在切换回刚才的功能上

                    if (setUsbConfig(functions)) {

                        mCurrentFunctions = functions;

                    } else {

                        Slog.e(TAG, "Failed to switch USB config to " + functions);

                        // revert to previous configuration if we fail

                        setUsbConfig(mCurrentFunctions);

                    }

                }

            }

        }

二 UsbDeviceManager.java的理解

这个函数是usb device主要的处理类:

一、是作为直接调用使用,被usb service调用,

二、是就收消息,对消息进行处理。

功能列表:

2.1 kernel层的event监控

       Listens for uevent messages from the kernel to monitor the USB state,如果状态有更新,降调用更新处理函数,随之触发一些列动作

    private final UEventObserver mUEventObserver = new UEventObserver()

2.2 构造函数

    进行对象实例化时的一些初始化

    public UsbDeviceManager(Context context, UsbSettingsManager settingsManager) {

2.3 storage功能的信息初始化

    public void systemReady()

{

       1、获取persist.sys.usb.config的值,并去掉可能的adb/acm功能,只保留下可能的存储功能,看来android默认认为除了adb/acm,产品就只剩下mtp/mass_storage了。

       2、获取ro.sys.usb.storage.typeusb存储设备的类型mUsbStorageTypemtp/mass_storage

       3、比较12的两个获取值,如果不相同,将默认的storage type更新给ro.sys.usb.storage.type

         4、如果mUsbStorageType 仅为UMS,就会通过StorageManagerSTORAGE_SERVICE获取分区情况,进而设置好        mUseUsbNotification用来决定是否更新usb通知。

}

2.4初始化rndis 地址

       private static void initRndisAddress() {

       设置rndis eth地址

2.5 usb功能的处理

       addFunction/removeFunction/containsFunction

       这三个都是static函数,类可直接调用

2.6 主要的usb处理类

    private final class UsbHandler extends Handler {

       下面每一个是这个类中的成员

       1、定义一个runnable 线程,待命执行mShowBuiltinInstallerRunnable

       2、定义一个receiver,接收各种信息进行处理,

                     private final BroadcastReceiver mIntentReceiver = new BroadcastReceiver() {

       3、定义UsbHandlerlooper

              各种function功能的初始配置

        public UsbHandler(Looper looper) {

       4、发送消息

              sendMessage,消息会有handleMessage来处理

       5updateState

              根据event传上来的信息,更新usb状态,并调用 sendMessage发送消息

       6setUsbConfig 设置usb的功能,SystemProperties.set

       7setAdbEnabled/setAcmEnabled

              adb/acm是两个特殊且独立的功能,一般不会出现在defaultFuncation里边,而是有单独的开关来        控制,所以在最终调用的setEnabledFunctions,里边的处理是很特殊的(一定要注意添加function             后造成的功能顺序是否与init.usb.rc中的配置是否吻合)

       8、这个函数比较特殊,逻辑上需要关注,尤其是对adb/acm的处理

        private void setEnabledFunctions(String functions, boolean makeDefault) {

       9updateCurrentAccessory

       10updateUsbState

              更新usb的状态,将usb的状态广播出去。广播的intentUsbManager.ACTION_USB_STATE,将                    usb的状态、功能携带到intent

       11、消息处理函数

              public void handleMessage(Message msg) {

       12updateUsbNotification/updateAdbNotification

              处理状态通知

       13、处理光驱介质share的动作

               showBuiltinInstallerUI

2.7openAccessory

2.8setCurrentFunction

这个会发送MSG_SET_CURRENT_FUNCTION消息,进而在消息处理函数中调用到      setEnabledFunctions

2.9setMassStorageBackingFile

下面的是oem是否覆盖persist.sys.usb.config的操作

2.10readOemUsbOverrideConfig

2.11needsOemUsbOverride

2.12processOemUsbOverride

UsbDeviceManager工作流程

       构造函数主要有两个动作:

              1创建线程

                       HandlerThread thread = new HandlerThread("UsbDeviceManager",

                                     Process.THREAD_PRIORITY_BACKGROUND);

              2 实例化mHandler,并给该hander提供looper

                      mHandler = new UsbHandler(thread.getLooper());

              3 其他为变量的初始化

       主要的工作就进入到UsbHandler这个处理类里了

              1 UsbHandler的构造函数:a)usbfunction及相关的功能设置,系统属性值进行获取及初始          . b)启用两个监听的动作,监听setting的设置改变以及usb uevent事件的变化。

              2 handleMessage的重载,在UsbHandler的成员函数中,会发送消息,那么处理消息的流程是如何             被启动的呢?这个流程就是looper来完成的,每个handler内都有message的发送、接收。但是这          handler必须指定looper,有looper来完成消息的分发、管理。Handler中只是完成具体的发送          和处理。

       handleMessage中的几个消息

              1 MSG_UPDATE_STATE://usb的连接状态有变化时,收到kerneluevent信息时

              2 MSG_ENABLE_ADB

              3 MSG_SET_CURRENT_FUNCTION://功能设置,上面应用传下来的动作

              4 MSG_SYSTEM_READY

              5 MSG_BOOT_COMPLETED

相关文章推荐

Quartus II 功能仿真设置流程

Quartus II功能仿真设置流程 1.新建一个.vwf文件 2.右键点击Name下白框,添加Node/Bus 3.如果已经知道名称和类型,直接键入 如果不确定或向多个输入,点击...

UsbDeviceManager.java

android  UsbDeviceManager (2012-08-07 11:08:34) 转载▼ 标签: android usb 杂谈 分类: 技术 ...

android usb解析(一)UsbDeviceManager(and5.1)

先来理下整个usb的架构,用户从UsbManager调用接口,会binder通信到UsbService。而UsbService又有两个实例,一个  UsbHostManager,一个UsbDevi...

oracle ebs 11i功能流程详解

  • 2012-11-16 21:54
  • 755KB
  • 下载

[ Activiti ] 关于activiti流程通过、驳回、会签、转办、中止、挂起等核心操作功能的封装

转载: http://blog.csdn.net/aochuanguying/article/details/7594197 写得很详细,很有参考价值 另外附上官方Activit...

流程超时功能的使用

  • 2013-10-16 11:15
  • 1.33MB
  • 下载

关于activiti的流程回退功能讨论

最近在整理一版基于struts、hibernate、spring和activiti的开发平台,在流程设计使选用了activiti的流程引擎,主要原因是习惯了JBPM的流程思路,而Tom Baeyens...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:深度学习:神经网络中的前向传播和反向传播算法推导
举报原因:
原因补充:

(最多只允许输入30个字)