簡(jiǎn)介面向Android系統(tǒng)開(kāi)發(fā)者的傳感器HAL層源碼包聚焦傳感器硬件抽象層的內(nèi)部實(shí)現(xiàn)適合需要深入理解傳感器框架、進(jìn)行自定義ROM或硬件適配的工程師尤其對(duì)系統(tǒng)級(jí)開(kāi)發(fā)者價(jià)值明顯。包內(nèi)含27個(gè)文件包括13個(gè)C源文件、12個(gè)頭文件、1個(gè)靜態(tài)庫(kù)和1個(gè)構(gòu)建腳本源文件與頭文件實(shí)現(xiàn)傳感器驅(qū)動(dòng)及HAL接口覆蓋加速度計(jì)、陀螺儀、磁力計(jì)、光感與接近傳感器等靜態(tài)庫(kù)提供MEMS融合算法構(gòu)建腳本負(fù)責(zé)編譯集成整體僅71KB。目前已有913人學(xué)習(xí)/下載。通過(guò)閱讀各傳感器驅(qū)動(dòng)、輸入事件讀取與傳感器檢測(cè)模塊可梳理從底層文件節(jié)點(diǎn)讀取事件、數(shù)據(jù)校準(zhǔn)到HAL接口上報(bào)的完整鏈路掌握獲取傳感器列表、批處理、使能等核心接口的底層行為同時(shí)還能了解多傳感器協(xié)同、MEMS融合算法封裝、功耗優(yōu)化以及新增傳感器硬件的移植思路為系統(tǒng)級(jí)調(diào)試、性能調(diào)優(yōu)和故障排查提供直接參考。 接手過(guò)一個(gè)傳感器調(diào)試任務(wù)現(xiàn)象很典型上層應(yīng)用能讀到加速度計(jì)和陀螺儀的傳感器列表但數(shù)值永遠(yuǎn)停在同一個(gè)位置。第一反應(yīng)是查應(yīng)用代碼查了三天一無(wú)所獲。后來(lái)偶然打開(kāi)HAL層的調(diào)試日志才發(fā)現(xiàn)數(shù)據(jù)鏈路早就斷了——問(wèn)題根本不在應(yīng)用而在android的sensor hal層。那次經(jīng)歷之后我花了不少時(shí)間把HAL層的接口、結(jié)構(gòu)體、平臺(tái)適配邏輯完整梳理了一遍才真正看懂這個(gè)最深處的守門(mén)人在整條鏈路里扮演的角色。這篇文章的目標(biāo)很明確把sensor hal層里的關(guān)鍵結(jié)構(gòu)體、調(diào)用流程、平臺(tái)差異和排查方法講清楚。適合正在做驅(qū)動(dòng)適配、系統(tǒng)中間件開(kāi)發(fā)、傳感器bring up的工程師也想讓對(duì)傳感器內(nèi)部機(jī)制好奇的應(yīng)用層開(kāi)發(fā)者知道一個(gè)傳感器沒(méi)數(shù)據(jù)的問(wèn)題到底要過(guò)幾道門(mén)才能定位到根因。1. Sensor HAL層到底藏了什么密碼先看清整條數(shù)據(jù)鏈路1.1 從觸摸屏幕到傳感器數(shù)據(jù)一次上報(bào)要過(guò)幾道門(mén)很多Android開(kāi)發(fā)者對(duì)傳感器框架的印象是注冊(cè)一個(gè)Listener然后等回調(diào)。但在回調(diào)的背后數(shù)據(jù)要穿過(guò)一條相當(dāng)長(zhǎng)的鏈路。應(yīng)用層通過(guò)SensorManager.getDefaultSensor()拿到傳感器實(shí)例再通過(guò)registerListener()訂閱數(shù)據(jù)。這一步會(huì)向下走進(jìn)SensorManager的JNI層再通過(guò)Binder進(jìn)入SystemServer里的SensorService。SensorService是系統(tǒng)里的傳感器管理中樞它統(tǒng)一管理所有傳感器客戶(hù)端、事件分發(fā)和權(quán)限控制。SensorService真正取數(shù)據(jù)時(shí)會(huì)調(diào)用SensorDevice而SensorDevice做的事情是通過(guò)hw_get_module()加載一個(gè)以libsensors.xxx.so命名的HAL庫(kù)。這個(gè)so文件就是HAL層。它通常由芯片廠商或整機(jī)廠商提供向上實(shí)現(xiàn)Android定義的標(biāo)準(zhǔn)接口向下通過(guò)設(shè)備節(jié)點(diǎn)、I2C/SPI總線(xiàn)甚至協(xié)處理器和內(nèi)核驅(qū)動(dòng)及物理傳感器交互。數(shù)據(jù)上報(bào)的方向則完全反過(guò)來(lái)傳感器硬件產(chǎn)生中斷或數(shù)據(jù) - 內(nèi)核驅(qū)動(dòng)讀取寄存器 - HAL層通過(guò)poll輪詢(xún)或中斷事件拿到原始數(shù)據(jù) - 做濾波、校準(zhǔn)、坐標(biāo)轉(zhuǎn)換 - 交給SensorService - 再分發(fā)給上層應(yīng)用的回調(diào)函數(shù)。所以一次看似簡(jiǎn)單的加速度計(jì)數(shù)值變化至少經(jīng)過(guò)應(yīng)用、框架、Native服務(wù)、HAL、內(nèi)核驅(qū)動(dòng)、硬件六個(gè)環(huán)節(jié)。每一層都可能截?cái)鄶?shù)據(jù)而HAL層是唯一一個(gè)接口是公開(kāi)的、實(shí)現(xiàn)是閉源的環(huán)節(jié)也是最難排查的環(huán)節(jié)。1.2 為什么說(shuō)HAL層是獨(dú)家的HAL層的獨(dú)家體現(xiàn)在兩個(gè)層面。第一接口標(biāo)準(zhǔn)是公開(kāi)的但具體實(shí)現(xiàn)每家都不同。AOSP定義了一套統(tǒng)一接口Android上層只認(rèn)這套接口但同一顆加速度計(jì)芯片在高通平臺(tái)上和MTK平臺(tái)上的HAL實(shí)現(xiàn)可能完全不同。高通的HAL往往會(huì)把傳感器邏輯下沉到DSP協(xié)處理器MTK則依賴(lài)自己的Sensor Hub硬件海思平臺(tái)又有自己的配置通道。上層看到的都是同一個(gè)SensorDemo底下的實(shí)現(xiàn)卻是八仙過(guò)海。第二真正的算法和校準(zhǔn)參數(shù)全都鎖在HAL層里。姿態(tài)融合、計(jì)步識(shí)別、握持檢測(cè)、溫漂補(bǔ)償這些獨(dú)家配方不會(huì)放進(jìn)內(nèi)核也不會(huì)放進(jìn)框架而是以靜態(tài)庫(kù)或私有配置的方式跟HAL綁定在一起。這也是廠商之間拉開(kāi)體驗(yàn)差距的護(hù)城河。所以如果你想搞清楚某個(gè)平臺(tái)上傳感器的性格最直接的路徑就是打開(kāi)它的HAL層代碼。2. HAL頭文件里的簽名檔sensors.h關(guān)鍵結(jié)構(gòu)體逐個(gè)啃2.1 sensor_t一張傳感器的身份證不管哪家平臺(tái)的Sensor HAL頭文件里第一個(gè)繞不開(kāi)的結(jié)構(gòu)體就是sensor_t。它描述了一個(gè)傳感器的所有靜態(tài)能力上層拿到這張身份證后才知道怎么使用這個(gè)傳感器。下面是實(shí)際產(chǎn)品里必須填對(duì)的核心字段字段作用注意點(diǎn)name / vendor傳感器名字和廠商會(huì)影響用戶(hù)看到的顯示名handle傳感器的唯一句柄上層用這個(gè)ID來(lái)指定操作哪個(gè)傳感器一般從0開(kāi)始編號(hào)type傳感器類(lèi)型對(duì)應(yīng)SENSOR_TYPE_ACCELEROMETER、SENSOR_TYPE_GYROSCOPE等上層一大套分發(fā)邏輯依賴(lài)這個(gè)值maxRange量程加速度計(jì)常見(jiàn)的 ±16g 就要寫(xiě)成 16.0 嗎不對(duì)很多驅(qū)動(dòng)上報(bào)的是累加值要按實(shí)際轉(zhuǎn)換后的物理單位填寫(xiě)resolution分辨率1 LSB對(duì)應(yīng)的物理量直接影響上層看到的數(shù)值精度power工作電流單位mASensorService做功耗統(tǒng)計(jì)時(shí)會(huì)用到minDelay最小上報(bào)周期單位微秒對(duì)應(yīng)最大采樣率maxDelay最大上報(bào)周期加了report_mode之后這個(gè)字段決定batch模式下最低頻率fifoReservedEventCount / fifoMaxEventCountFIFO事件數(shù)用來(lái)告訴系統(tǒng)這個(gè)傳感器支持多少事件緩存stringType字符串類(lèi)型標(biāo)識(shí)從Android 4.0開(kāi)始推薦使用比如android.sensor.accelerometerrequiredPermission訪問(wèn)權(quán)限需要權(quán)限才能訪問(wèn)的傳感器必須填比如心率傳感器這里要特別強(qiáng)調(diào)maxRange和resolution一定不能隨手抄參考代碼必須跟驅(qū)動(dòng)里的實(shí)際轉(zhuǎn)換公式對(duì)齊。我就見(jiàn)過(guò)一個(gè)平臺(tái)加速計(jì)量程填成2g驅(qū)動(dòng)實(shí)際輸出是4g的量程結(jié)果上層所有算力都基于錯(cuò)誤量程做成的計(jì)步器偏差離譜。2.2 sensors_module_t 與 sensors_poll_device_t入口和操作句柄Android的HAL模塊有統(tǒng)一規(guī)范每個(gè)HAL都必須導(dǎo)出一個(gè)hw_module_t傳感器HAL則通過(guò)sensors_module_t擴(kuò)展。這個(gè)結(jié)構(gòu)體除了公共接口外最關(guān)鍵的是get_sensors_list()函數(shù)——它返回該設(shè)備上所有傳感器的sensor_t數(shù)組。static const struct sensor_t base_sensors[] { { .name BMI160 Accelerometer, .vendor Bosch, ... }, }; static int sensors_get_sensors_list(struct sensors_module_t* module, struct sensor_t const** list) { *list base_sensors; return ARRAY_SIZE(base_sensors); }上層拿到傳感器列表后再通過(guò)open()拿到sensors_poll_device_t這個(gè)操作句柄。sensors_poll_device_t繼承了hw_device_t并且擴(kuò)展出了activate、setDelay、poll、batch、flush這些關(guān)鍵函數(shù)。真實(shí)產(chǎn)品里HAL庫(kù)必須實(shí)現(xiàn)完整的方法表才能通過(guò)框架的加載校驗(yàn)。這里有個(gè)容易踩坑的點(diǎn)get_sensors_list返回的傳感器數(shù)組內(nèi)容必須在HAL加載期間保持有效不能是臨時(shí)變量否則上層訪問(wèn)時(shí)會(huì)拿到野指針。有些平臺(tái)為了動(dòng)態(tài)配置傳感器列表會(huì)分配一塊靜態(tài)存儲(chǔ)區(qū)再把可變指針填進(jìn)去。2.3 sensors_event_t上報(bào)數(shù)據(jù)的統(tǒng)一快遞盒上層從poll()里讀到的所有數(shù)據(jù)都用sensors_event_t來(lái)承載。這個(gè)結(jié)構(gòu)體把多種傳感器類(lèi)型的事件做成了union針對(duì)不同類(lèi)型切片解釋。typedef struct sensors_event_t { int32_t version; int32_t sensor; int32_t type; int32_t reserved0; int64_t timestamp; union { struct { float x, y, z; } acceleration; struct { float x, y, z; } gyro; struct { float x, y, z; } magnetic; struct { float light; } light; struct { float distance; } proximity; ... }; uint32_t flags; uint32_t reserved1[3]; } sensors_event_t;關(guān)鍵點(diǎn)在于timestamp。這個(gè)時(shí)間戳必須是CLOCK_MONOTONIC域的系統(tǒng)單調(diào)時(shí)鐘不能是CLOCK_REALTIME因?yàn)橄到y(tǒng)休眠時(shí)實(shí)時(shí)時(shí)鐘可能調(diào)整會(huì)導(dǎo)致傳感器事件的時(shí)間線(xiàn)錯(cuò)亂。好多傳感器調(diào)試問(wèn)題都出在這個(gè)細(xì)節(jié)上數(shù)據(jù)有、曲線(xiàn)有但時(shí)間線(xiàn)不定期倒跳最后定位到就是HAL里直接把內(nèi)核驅(qū)動(dòng)的jiffies轉(zhuǎn)成了實(shí)時(shí)時(shí)鐘的毫秒數(shù)。另外一個(gè)字段是flags。在batch和direct channel模式下flags會(huì)標(biāo)記事件是否來(lái)自FIFO、是否為喚醒事件這個(gè)不多看一眼后面做功耗優(yōu)化時(shí)很容易踩坑。3. 真正干活的三板斧activate、setDelay、poll的實(shí)現(xiàn)邏輯3.1 activate的使能與禁用傳感器不是一開(kāi)就完事上層調(diào)startListening()之后最終會(huì)轉(zhuǎn)化為HAL層的activate(handle, 1)調(diào)用。這個(gè)函數(shù)用真實(shí)的物理動(dòng)作開(kāi)啟傳感器把GPIO拉起來(lái)、通過(guò)I2C寫(xiě)入電源模式寄存器、申請(qǐng)中斷、啟動(dòng)輪詢(xún)線(xiàn)程等。activate(handle, 0)則做相反的事情。實(shí)現(xiàn)activate時(shí)的常見(jiàn)坑有同一個(gè)傳感器被多個(gè)客戶(hù)端同時(shí)使用但HAL層并不維護(hù)引用計(jì)數(shù)。SensorService已經(jīng)做了上層的客戶(hù)端管理它保證只有第一個(gè)和最后一個(gè)Listener來(lái)去時(shí)才會(huì)調(diào)用activate。HAL層如果自己也做引用計(jì)數(shù)反而容易出現(xiàn)狀態(tài)錯(cuò)亂。不同上報(bào)模式的傳感器activate之后的預(yù)期行為也不同。連續(xù)上報(bào)型如加速度計(jì)需要馬上開(kāi)始持續(xù)輸出數(shù)據(jù)on-change型如光感、接近傳感器只在數(shù)值變化時(shí)上報(bào)一次one-shot型如顯著運(yùn)動(dòng)檢測(cè)只上報(bào)一次事件后自動(dòng)進(jìn)入禁用狀態(tài)特殊上報(bào)型如姿態(tài)傳感器通常需要結(jié)合硬件中斷觸發(fā)。這些差異直接影響HAL層的具體實(shí)現(xiàn)方式。3.2 setDelay與batch參數(shù)換算頻率是門(mén)算術(shù)課setDelay(handle, period_ns)的參數(shù)是納秒周期的期望值但真實(shí)驅(qū)動(dòng)往往只支持固定的幾檔頻率HAL層需要把期望值轉(zhuǎn)換成最近的硬件頻率。比如驅(qū)動(dòng)支持 10ms、20ms、50ms 三檔上層要15msHAL可以取最近的20ms也可以直接向下取整到10ms行業(yè)內(nèi)通常傾向于取不小于請(qǐng)求值的檔位避免頻率不足導(dǎo)致上層計(jì)算的積分漂移。batch()則更復(fù)雜它同時(shí)設(shè)置了period_ns、max_report_latency_ns和flags。max_report_latency_ns表示硬件FIFO可以緩存事件多久不上報(bào)這個(gè)參數(shù)是傳感器省電的核心。如果傳感器硬件FIFO足夠HAL可以讓傳感器在低功耗模式下持續(xù)采集事件先存進(jìn)FIFO等到超過(guò)max_report_latency_ns或者FIFO快滿(mǎn)時(shí)再一次性上報(bào)AP側(cè)的cpu可以一直休眠。這也是為什么sensor_t里的fifoMaxEventCount要填準(zhǔn)因?yàn)樗鼪Q定了batch模式下FIFO能裝多少事件比如采樣率100HzFIFO容量為1000個(gè)事件那硬件大約可以緩存10秒的數(shù)據(jù)。3.3 poll與線(xiàn)程模型把數(shù)據(jù)穩(wěn)定送到上層poll()是個(gè)阻塞函數(shù)SensorService會(huì)開(kāi)啟專(zhuān)門(mén)線(xiàn)程調(diào)用它HAL實(shí)現(xiàn)里最常見(jiàn)的做法是內(nèi)部維護(hù)一個(gè)環(huán)形緩沖區(qū)當(dāng)傳感器數(shù)據(jù)到來(lái)時(shí)寫(xiě)入poll()被調(diào)用時(shí)把緩沖區(qū)里的數(shù)據(jù)拷貝到上層數(shù)組并返回事件個(gè)數(shù)。如果沒(méi)有數(shù)據(jù)則阻塞等待一個(gè)條件變量。實(shí)現(xiàn)poll時(shí)的幾個(gè)關(guān)鍵細(xì)節(jié)多傳感器共用一個(gè)poll線(xiàn)程靠傳入的傳感器句柄區(qū)分?jǐn)?shù)據(jù)來(lái)源。當(dāng)多個(gè)事件同時(shí)到達(dá)時(shí)poll()返回的是一個(gè)數(shù)組框架層會(huì)按數(shù)組順序分發(fā)。如果某個(gè)傳感器數(shù)據(jù)量大可以在一次poll里返回多個(gè)事件。環(huán)形緩沖區(qū)要加鎖且鎖內(nèi)不能做耗時(shí)的I2C讀取否則中斷上報(bào)會(huì)被鎖拖住。flush操作也要在poll線(xiàn)程里配合完成。上層調(diào)用flush()后HAL層的flush()函數(shù)不能直接返回一個(gè)事件因?yàn)槭录仨氉呓y(tǒng)一的事件通道。正確做法是在flush里置一個(gè)標(biāo)志讓poll線(xiàn)程在下一個(gè)循環(huán)中生成一個(gè)META_DATA_FLUSH_COMPLETE類(lèi)型的事件返回。4. 平臺(tái)適配的暗礁高通、MTK、海思的HAL差異4.1 高通平臺(tái)從直接操作寄存器到DSP大管家高通老平臺(tái)比如MSM8916那一代的Sensor HAL相對(duì)簡(jiǎn)單很多是直接在HAL里通過(guò)/dev節(jié)點(diǎn)操作I2C、SPI設(shè)備。到了后續(xù)平臺(tái)高通的傳感器框架逐步演變成以SLPI/ADSP為核心的模式傳感器被掛到DSP側(cè)DSP負(fù)責(zé)采樣和基礎(chǔ)算法AP側(cè)的Sensor HAL通過(guò)QMI/fastrpc消息與DSP通信。這個(gè)架構(gòu)的直觀影響是HAL層看到的不是一只裸傳感器而是一套運(yùn)行在DSP上的服務(wù)。上層調(diào)activateHAL會(huì)把請(qǐng)求包裝成消息發(fā)給傳感器核心再等待DSP的回執(zhí)。所以高通平臺(tái)上調(diào)HAL debug的時(shí)候不僅要在AP側(cè)打日志還得在DSP側(cè)看診斷輸出。高通平臺(tái)還附帶一個(gè)比較麻煩的配置點(diǎn)傳感器列表和軸向來(lái)。不同機(jī)型裝配的傳感器模組不同同型號(hào)主板也可能存在方向角差異這些是通過(guò)產(chǎn)品樹(shù)的配置文件來(lái)描述并由HAL加載的。手勢(shì)、休眠時(shí)是否保持傳感器上報(bào)等都在這套配置里做改錯(cuò)一個(gè)坐標(biāo)軸所有數(shù)據(jù)都會(huì)顛倒。4.2 MTK平臺(tái)Sensor Hub與硬件級(jí)融合MTK平臺(tái)通常有獨(dú)立的Sensor Hub協(xié)處理器甚至是多核MCU架構(gòu)。重力加速度、陀螺儀、磁力計(jì)數(shù)據(jù)先由協(xié)處理器統(tǒng)一采集再由HAL層通過(guò)專(zhuān)用通道獲取。觸覺(jué)上MTK的功耗表現(xiàn)不錯(cuò)也是因?yàn)镾ensor Hub把數(shù)據(jù)采集和部分算法從AP里解放了。MTK平臺(tái)調(diào)試時(shí)有個(gè)明顯特點(diǎn)很多傳感器的使能邏輯分散在HAL層和內(nèi)核驅(qū)動(dòng)的meta通道里。如果單純改HAL而忽略?xún)?nèi)核側(cè)的cust_alsps、cust_acc這類(lèi)配置宏常常會(huì)出現(xiàn)HAL明明已經(jīng)打開(kāi)了傳感器底層卻沒(méi)有數(shù)據(jù)的現(xiàn)象。MTK還通常要求在HAL里對(duì)傳感器進(jìn)行坐標(biāo)系轉(zhuǎn)換因?yàn)镾ensor Hub輸出的默認(rèn)坐標(biāo)系跟Android的約定坐標(biāo)系不一致。4.3 海思平臺(tái)的configs與pqtool.sh海思平臺(tái)在機(jī)頂盒、車(chē)載和部分手機(jī)方案中都有應(yīng)用。它的傳感器HAL層比較依賴(lài)專(zhuān)用配置文件工程師通常通過(guò)一個(gè)類(lèi)似pqtool.sh的腳本在調(diào)試階段把寄存器序列、校準(zhǔn)參數(shù)寫(xiě)入對(duì)應(yīng)配置文件再加載到HAL的初始化流程里。這種腳本生成配置、配置驅(qū)動(dòng)HAL的模式跟高通和MTK直接用代碼寫(xiě)死參數(shù)的做法很不一樣。pqtool.sh這類(lèi)工具的價(jià)值在于它可以快速驗(yàn)證寄存器配置是否生效而不用反復(fù)改代碼重編。用這類(lèi)工具導(dǎo)出的configs文件本質(zhì)上就是廠家傳感器工廠校準(zhǔn)參數(shù)的最終存檔調(diào)試完成后一定要備份好否則量產(chǎn)換料后數(shù)據(jù)漂移會(huì)非常嚴(yán)重。4.4 i2c-tools查看傳感器真面目的利器無(wú)論哪個(gè)平臺(tái)拿到一塊新板子第一件事是用i2c-tools確認(rèn)傳感器還在線(xiàn)。Android工程機(jī)上最常用的三個(gè)命令是i2cdetect掃描總線(xiàn)上掛著的設(shè)備、i2cget讀寄存器、i2cset寫(xiě)寄存器。以一顆常見(jiàn)的加速度計(jì)為例寄存器0x0F是芯片ID寄存器。如果I2C地址是0x68掛在I2C總線(xiàn)2上可以用這條命令確認(rèn)它還活著i2cget -y 2 0x68 0x0f正常返回的ID應(yīng)該跟數(shù)據(jù)手冊(cè)一致比如0xD1就表示BMI160在線(xiàn)。如果返回異常大概率不是HAL問(wèn)題而是驅(qū)動(dòng)、上拉電阻或芯片焊接問(wèn)題。i2c-tools的價(jià)值就是把硬件通沒(méi)通和軟件有沒(méi)有讀對(duì)這兩個(gè)問(wèn)題快速切開(kāi)省去在HAL層瞎找原因的半天時(shí)間。5. 踩坑實(shí)錄從看不到數(shù)據(jù)到HAL層日志的完整排查鏈路5.1 場(chǎng)景一傳感器列表能讀到但是數(shù)據(jù)不動(dòng)這是最經(jīng)典的問(wèn)題?？吹竭@個(gè)現(xiàn)象別急著改代碼按下面的鏈路走一遍。第一步用dumpsys sensorservice確認(rèn)SensorService視角下的傳感器狀態(tài)。命令會(huì)列出所有已注冊(cè)的傳感器以及當(dāng)前活躍的客戶(hù)端。重點(diǎn)看兩點(diǎn)傳感器列表里有沒(méi)有目標(biāo)傳感器只有應(yīng)用能拿到列表才說(shuō)明HAL層的get_sensors_list正常當(dāng)前客戶(hù)端有沒(méi)有注冊(cè)成功如果注冊(cè)失敗問(wèn)題是權(quán)限或handle沖突。第二步用getevent看內(nèi)核事件。傳感器通常通過(guò)input子系統(tǒng)上報(bào)運(yùn)行g(shù)etevent -S后晃動(dòng)手機(jī)看有沒(méi)有事件流。如果有事件說(shuō)明驅(qū)動(dòng)正常問(wèn)題卡在HAL到框架之間如果沒(méi)有事件說(shuō)明驅(qū)動(dòng)或硬件根本沒(méi)工作。第三步打開(kāi)HAL層的調(diào)試日志。多數(shù)HAL實(shí)現(xiàn)都支持設(shè)置屬性或編譯開(kāi)關(guān)打開(kāi)ALOGD。把日志打開(kāi)后看activate有沒(méi)有被調(diào)用poll線(xiàn)程有沒(méi)有在等數(shù)據(jù)以及事件里帶的傳感器handle是不是應(yīng)用期待的handle。實(shí)際操作中我印象最深的一次是列表正常驅(qū)動(dòng)事件也正常但HAL里poll的數(shù)據(jù)集死活不動(dòng)。最后定位到問(wèn)題出在HAL加載了舊版本的傳感器配置庫(kù)庫(kù)里的FIFO緩沖沒(méi)有真正初始化poll線(xiàn)程一直在空轉(zhuǎn)。這種問(wèn)題沒(méi)有日志定位幾乎不可能憑肉眼發(fā)現(xiàn)。5.2 場(chǎng)景二數(shù)值漂移得像過(guò)山車(chē)數(shù)據(jù)動(dòng)是動(dòng)了但完全對(duì)不上物理量靜置時(shí)加速度計(jì)讀數(shù)還在往下掉。這類(lèi)問(wèn)題大概率出在兩個(gè)環(huán)節(jié)校準(zhǔn)參數(shù)沒(méi)加載或者坐標(biāo)映射錯(cuò)誤。用i2c-tools讀原始寄存器看原始值是否穩(wěn)定。如果原始值穩(wěn)定說(shuō)明硬件沒(méi)問(wèn)題那就是HAL沒(méi)把offset和sensitivity應(yīng)用到上報(bào)值上。很多傳感器的校準(zhǔn)參數(shù)存放在/mnt/vendor/sensors/calibration這類(lèi)路徑如果這些文件缺失或權(quán)限不足HAL會(huì)退回默認(rèn)值漂移自然就會(huì)出現(xiàn)。坐標(biāo)映射錯(cuò)誤則表現(xiàn)為翻轉(zhuǎn)會(huì)跳變。比如把手機(jī)平放桌面Z軸應(yīng)該接近9.8如果讀數(shù)變成0或者負(fù)值要去檢查HAL里的坐標(biāo)系轉(zhuǎn)換矩陣。這類(lèi)錯(cuò)誤最常見(jiàn)的原因是從參考設(shè)計(jì)拷貝代碼時(shí)沒(méi)有根據(jù)當(dāng)前主板上的實(shí)際裝配方向修改。5.3 場(chǎng)景三功耗下不來(lái)省電是傳感器HAL設(shè)計(jì)里繞不開(kāi)的話(huà)題。明明開(kāi)啟了batch模式功耗還是居高不下通常要檢查三件事FIFO配置有沒(méi)有用上喚醒傳感器有沒(méi)有被頻繁使用poll線(xiàn)程有沒(méi)有在無(wú)事件時(shí)真正休眠。FIFO配置這塊我實(shí)測(cè)過(guò)把fifoMaxEventCount從100改成0之后同樣場(chǎng)景下整機(jī)功耗直接多了幾十毫安因?yàn)槊總€(gè)事件都會(huì)立即喚醒AP。對(duì)喚醒傳感器Android框架有獨(dú)立的紅外喚醒通道但HAL層必須正確標(biāo)記SENSOR_FLAG_WAKE_UP標(biāo)志否則傳感器事件無(wú)法在系統(tǒng)休眠時(shí)喚醒AP。5.4 排錯(cuò)工具速查工具用途使用時(shí)機(jī)dumpsys sensorservice查看傳感器列表和客戶(hù)端狀態(tài)優(yōu)先使用getevent -S看內(nèi)核input事件流判斷驅(qū)動(dòng)好壞i2cdetect/i2cget/i2cset直接訪問(wèn)傳感器寄存器確認(rèn)硬件在不在線(xiàn)HAL層ALOGD日志確認(rèn)activate/poll內(nèi)部行為定位軟件邏輯sensors-stress測(cè)試程序壓力測(cè)試多客戶(hù)端并發(fā)驗(yàn)證穩(wěn)定性6. 不上手的知識(shí)點(diǎn)不算真會(huì)一個(gè)最小Sensor HAL骨架參考很多文章講HAL層只停留在概念這里我直接給一個(gè)教學(xué)級(jí)別的骨架說(shuō)明一個(gè)最基本的加速度計(jì)HAL要怎么寫(xiě)。真實(shí)產(chǎn)品必須在對(duì)應(yīng)平臺(tái)SDK基礎(chǔ)上適配不能直接照抄但對(duì)于理解接口關(guān)系這個(gè)骨架足夠了。#include hardware/sensors.h static int accel_activate(struct sensors_poll_device_t* dev, int handle, int enabled) { // 打開(kāi)/關(guān)閉設(shè)備節(jié)點(diǎn)或通過(guò)ioctl控制傳感器電源 // 真實(shí)場(chǎng)景這里會(huì)寫(xiě)I2C寄存器 return 0; } static int accel_set_delay(struct sensors_poll_device_t* dev, int handle, int64_t period_ns) { // 將period_ns轉(zhuǎn)換為采樣頻率檔位 return 0; } static int accel_poll(struct sensors_poll_device_t* dev, sensors_event_t* data, int count) { // 讀取驅(qū)動(dòng)緩存或設(shè)備節(jié)點(diǎn)填充sensors_event_t data[0].type SENSOR_TYPE_ACCELEROMETER; data[0].sensor 0; data[0].timestamp systemTime(SYSTEM_TIME_MONOTONIC); // data[0].acceleration.x ...; // data[0].acceleration.y ...; // data[0].acceleration.z ...; return 1; } static struct sensors_poll_device_1_t sensor_device { .common { .tag HARDWARE_DEVICE_TAG, .module sensor_module, .close sensor_close, }, .activate accel_activate, .setDelay accel_set_delay, .poll accel_poll, .batch accel_batch, .flush accel_flush, };編譯時(shí)把這個(gè)文件所在的模塊加進(jìn)平臺(tái)的PRODUCT_PACKAGES或者直接放在vendor包中編譯產(chǎn)物就是libsensors_xxx.so。然后用dumpsys sensorservice驗(yàn)證能否看到傳感器列表再用一個(gè)測(cè)試APK或sensorstest讀取數(shù)據(jù)。這塊骨架里最容易被忽略的是.common.module必須指向一個(gè)合法的sensors_module_t而sensors_module_t里必須實(shí)現(xiàn)get_sensors_list。如果這兩個(gè)指針沒(méi)對(duì)齊HAL加載會(huì)直接失敗但錯(cuò)誤提示往往藏在logcat較深的地方不容易被發(fā)現(xiàn)。時(shí)間戳這一欄也要認(rèn)真處理不要用time()這類(lèi)秒級(jí)時(shí)鐘而要用systemTime(SYSTEM_TIME_MONOTONIC)或clock_gettime(CLOCK_MONOTONIC)否則框架層融合算法的數(shù)據(jù)順序會(huì)亂。寫(xiě)這個(gè)骨架的過(guò)程中我反復(fù)提醒自己HAL層不是寫(xiě)一個(gè)接口就完事每個(gè)字段、每個(gè)返回值都是跟上下層之間的一紙契約。你對(duì)契約的理解越精確調(diào)起問(wèn)題來(lái)就越有底氣。這種先看鏈路再看協(xié)議、先確認(rèn)硬件再定位軟件的排查方式我自己用了很多年實(shí)測(cè)是處理傳感器問(wèn)題效率最高的路徑。本文還有配套的精品資源點(diǎn)擊獲取