Android 8.0 版本將 USB 命令的處理從init
腳本轉移到原生 USB 守護程序中,以實現更好的配置和代碼可靠性。對於小工具功能配置, init
腳本(屬性觸發器)用於執行特定於設備的小工具操作。
在以前的版本中,這些特定於設備的配置是通過特定於設備的init
腳本(使用屬性觸發器)實現的。遷移到硬件抽象層 (HAL) 設計會產生更簡潔的實現來解決這些問題:
- 諸如寫入內核 sysfs 節點的操作可能會失敗,但不會傳播回設置屬性觸發器的框架代碼。結果,框架錯誤地假設操作已經成功,即使它們已經默默地失敗了。
-
init
腳本可以執行的操作數量有限。
Android 12 版本為網絡控制模型 (NCM) 和返回 HAL 版本號和 USB 速度的 API 調用添加了 USB Gadget HAL 支持。有關可通過 USB HAL 調用的 API 的更多信息,請參閱android.hardware.usb
包摘要。
HAL 和高音
特定於設備的init
腳本被用作 HAL 層的替代物,以執行特定於設備的 USB 操作。 USB(通過 ADB)是調試系統問題的主要接口。擁有一個執行 USB 配置的本機守護進程消除了對框架代碼的依賴,因此即使框架崩潰,USB 也應該運行。
在 Android 8.0 中引入的Treble模型下,所有 HAL 都與系統服務隔離,並且需要在自己的本機守護程序中運行。這消除了擁有獨占 USB 守護程序的要求,因為 HAL 層可以很好地兼作 USB 守護程序。
默認 HAL 實現負責所有 Android 8.0 之前的設備。因此,對於 Android 8.0 之前的設備,不會有任何特定於設備的工作。 Android 8.0 使用 HAL 接口來查詢 USB 端口的狀態並執行數據角色和電源角色交換。
執行
需要在每台搭載 Android 8.0 的設備上實現新的 USB HAL 接口。默認實現應適用於 Android 8.0 之前的設備。如果設備使用dual_role_usb
類報告 type-c 端口狀態,默認實現就足夠了。可能需要在特定於設備的 USB 腳本中進行一些細微的更改,以將 typc-c 節點的所有權轉移到系統。