不想為想題目耗費寶貴的靈感，先起乙個名字。
想獲取usb裝置的idproduct，不知道如何是好，一直在猶豫。利用現有資源就是直接實驗，而不是一直坐那死想，插入乙個usb設定的時候，可以看到是vold盡心盡責的進行的檢測:
其實一開始準備用ueventd(相當於udev/mdev)監測，但是發現不是那麼回事，來看看udev的架構：
我現在的情況是有裝置而無驅動(其實獲取idproduct是為了動態載入驅動，差點搞錯誤先有雞還是先有蛋的問題)，就不能去用udev/ueventd的方法了，要用vold的方法，在vold檢測到一些idproduct的時候，來進行過慮。
話說vold管理了 各種格式的u盤 的掛載。要新增對usb其它裝置的管理也要有模有樣的做一套系統，不過目前先做實現，直接在列印了"== current usb device: %04x/%04x ==="這一句的後邊進行idproduct的過濾，過濾出8176進行報告,分析這段**：
slogd("== current usb device: %04x/%04x ===", vid, pid);
char configure_file[2048];
sprintf(configure_file, "/etc/usb_modeswitch.d/%04x_%04x", vid, pid);
if( access(
configure_file
, 0) == 0 )
再看/etc/usb_modeswitch.d目錄下：
都是以idproduct命名的檔案，這都是一些規則，寫好的規則。我對usb wifi的管理也可以參考這樣的規則。關於usb_modeswitch.d參見《usb_modeswitch 介紹》，看完就會覺悟，原來這都是udev的那套東西。
現在開始設計上層：
1.建立/etc/usb_wifi.d/目錄 和usb_modeswitch.d一樣以idproduct來命名的檔案，這裡以8192cu的usb wifi為例子：0bda_8176內容為rtl8188cu。
2.如果檔案存在則將0bda_8176的內容rtl8188cu寫入到/sys/class/rkwifi/chiporadic中，實驗中可以寫入/data/local/tmp/wifi_chip中。
下面開始著手寫**。
else
memset(buf, 0 , 64);
if( 0 == read(wifi_fd, buf, 10) )
close(wifi_fd);
wifi_fd = open(wifi_chip_aidc_path, o_wronly);
if (wifi_fd < 0)
if (write(wifi_fd, buf, strlen(buf)) < 0)
alogd("usb wifi_type:%s", buf);
close(wifi_fd);
}else
done:
alogd("end!");
}效果還不錯：
（天，邏輯怎麼有點亂"end!"在怎麼在「enter」前邊了，原來aloge和sloge還不一樣，優先順序一樣，順序也不一樣，統一為sloge好了，這裡要注意了。
）當我信心滿滿的時候，發現乙個問題vold是基於netlink的，但是
這個好像在開機之前就有的熱插拔
，並不能監聽。這個可苦了我了。先研究一下上述情況下udev是怎麼做到的，也就是開機前插入u盤,udev後來啟動後怎麼知道的。
先把開機這個事放這，繼續往下走，在拔出usb 裝置的時候也同樣判斷是不是usb wifi，如果是就將標誌清除，也就是寫空。
這個沒有什麼難度，很快就完成了。
解決關機過程中的插拔：
這個問題是在我寫wifi type到/data/local/tmp/wifi_chip中是出現的，具體情況是如果關機時還插著usb wifi的時候，在關機的情況下拔掉usb wifi然後再開機的時候會檔案中的型別還是usb wifi。但是沒有這個裝置也是事實，就會引起還會去堅持插入usb wifi的驅動模組，導致邏輯不對。對於這個問題最好的解決方法是 儲存usb wifi type到乙個關機就消失的檔案中，這樣再次開機的時候就不會還是上次關機時判斷的狀態了。
在android中預設是沒有和/tmp乙個功能的目錄的，所以可以考慮寫的/sys檔案系統中，自己實現乙個小驅動。
簡單說下這個小驅動的實現，基於freg，這是乙個可以在/sys檔案系統中乙個buf，可以供讀寫，本來是乙個整數型的，改進一下存成字元型的。每次開機時，buf是空的，就不會存在上述問題了。
解決開機前插入usb wifi的不能識別的問題：
直接說不能識別是不準確的，應該是我的測試結果是這樣的。現象再仔細描述一下，在開機後插拔usb wifi和上述的截圖（「效果不錯」）是一樣的，可以看到型別為usb。但是開機前插入的時候，就相當於先有的熱插拔，後有vold來監聽，所以就監聽不到了。這個是問題的總體概述。下面說下解決過程。
趕緊google它找巨人，沒有肩膀可站的時候才去自動分析，有巨人：
由於我的usb wifi還沒有配置上驅動，所以沒有類別，我要讓所有的usb裝置重新傳送一下事件，測試了/sys/class/usb_devices不成功，改為/sys/bus/usb/devices這樣ok了。
正是我想要的，問題就此解決。
說句後話，usb wifi驅動是歸類到net類別中的，但是這裡是用不到的，因為那個時候還沒有驅動，更沒有類別。
Android監聽USB插拔事件
android監聽usb插拔事件有兩種方式 一種是在mainifest.xml中註冊 android.hardware.usb.action.usb device attached即在usb插入是的action意圖。在android.hardware.usb.usbmanager類中有多種actio...
android 獲取usb 裝置資訊
1.使用者需要獲取usb 裝置名,來判斷是不是我方的印表機 2.public string getproductname catch exception e logger.i manufacturer manufacturer n logger.i product product n logger....
MFC中SDI程式建立流程的回顧
sdi程式建立流程的回顧 1.首先應用程式物件建立文件模板 csingledoctemplate pdoctemplate pdoctemplate new csingledoctemplate idr mainframe,runtime class csdicoindoc runtime clas...