MTK sensorServer層到HAL層、驅動層解析
參考文章:Android硬體抽象層(HAL)概要介紹和學習計劃 http://blog.csdn.net/luoshengyang/article/details/6567257
本人也是新手,不過看大牛寫的例子感覺有點力不從心,本人還是通過Android原始碼來分析,在這裡寫這些東西一是給自己總結一下;二是自己也好記錄一下自己的學習過程分享給大家。
我們這裡首先從SensorServer.cpp開始分析:
(本人專案檔案的路徑:.\frameworks\native\services\sensorservice\SensorServer.cpp)
1.enable()
在這裡我們可以先去找enable()函式,在這裡我們可以看出來其實就是呼叫了另外一個sensor全域性量型別在封裝層SensorDevice.cpp中
if (actuateHardware) { ALOGD_IF(DEBUG_CONNECTIONS, "\t>>> actuating h/w activate handle=%d enabled=%d", handle, enabled); err = mSensorDevice->activate( reinterpret_cast (mSensorDevice), handle, enabled); ALOGE_IF(err, "Error %s sensor %d (%s)", enabled ? "activating" : "disabling", handle, strerror(-err)); if (err != NO_ERROR && enabled) { // Failure when enabling the sensor. Clean up on failure. info.removeBatchParamsForIdent(ident); } } // On older devices which do not support batch, call setDelay(). if (getHalDeviceVersion() < SENSORS_DEVICE_API_VERSION_1_1 && info.numActiveClients() > 0) { ALOGD_IF(DEBUG_CONNECTIONS, "\t>>> actuating h/w setDelay %d %" PRId64, handle, info.bestBatchParams.batchDelay); mSensorDevice->setDelay( reinterpret_cast(mSensorDevice), handle, info.bestBatchParams.batchDelay); }
在進入sensorDevice.cpp中 我們可以看到這裡對enable變數進行了判斷並且如果是第一次的話,後面就可以省一些硬體操作,每個應用呼叫一次sensor都有有一個connetion(註解裡面有相關說明的!)後面會對actuateHardware進行判斷並進行對應操作。
現在到此,我們可以看出server層是用SensorDevice.cpp()進行的封裝,然後我們開始進入HAL,在HAL一樣和server層類似,先是在sensor.c中去呼叫封裝層nusensor.cpp,在這裡實現了HAL的具體呼叫device的API,在active()這裡去呼叫poll_active(),這裡程式碼就不去分析了,其實就是層層封裝,到後面的具體實現就是那幾個關鍵的函式!
在這server層到HAL層的封裝中,我們可以看見函式的引數明顯少了一個device型別引數,當然我們也是可以理解的,在server層是面向應用,一個device可能被好幾個應用呼叫,所以必須得有device引數,而到HAL層中(就已經是有對應好了device),已經知道對應的device,也就不需要這個引數,所以我們也能越來越理解Google程式碼的設計思想了。
到這裡我感覺其他的setDelay()其他什麼的都是類似的原理,後面可以自己去理解,只不過是花的時間可能多一點,不過花時間去自己嘗試就是最好的鍛鍊!相信你可以的!
今天收穫最大的就是知道了整個流程的date和control的傳遞流程,和Google一層層的程式碼封裝,