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