AOSP 11开发：创建应用层到内核层数据交互自定义API咨询

以下实操步骤完全匹配你列出的Android层级交互链路，所有修改均在本地AOSP 11源码树内完成，无外部依赖：

内核层 + 设备驱动层实现 #

• 优先选择/proc或/sys节点作为内核与用户空间的交互入口，相比从零实现自定义字符设备，开发成本更低、兼容性更好
• 节点实现逻辑：
  • 实现write回调：接收上层下发的参数，执行内核侧对应逻辑后返回执行结果码
  • 实现read回调：向上层返回内核侧待上报的数据
  • 节点权限配置为system组可读写，避免后续HAL层访问触发权限拒绝
• 若对接自定义硬件，直接在对应驱动的probe函数中完成上述节点注册即可，无需额外修改通用驱动通信逻辑

HAL层实现 #

AOSP 11默认采用HIDL作为HAL层通信标准，实现步骤如下：

• 在源码树hardware/interfaces/路径下新建自定义HIDL接口目录，例如hardware/interfaces/customtrans/1.0/
• 编写.hal接口定义文件，声明基础通信方法，参考定义：

  interface ICustomTrans {
      sendToKernel(string data) generates (int32_t ret);
      readFromKernel() generates (string data);
  };
  

• 用AOSP内置的hidl-gen工具自动生成HIDL通信桩代码，无需手动编写Binder通信逻辑
• 实现HIDL服务端逻辑：在服务实现类中打开内核层创建的/proc//sys节点，完成上层数据到节点的写入、节点数据到上层的读取逻辑
• 配置SELinux规则：在对应sepolicy目录下新增规则，允许自定义HIDL服务访问对应内核节点、注册为hwservice，避免跨层调用被拦截

JNI层实现 #

• JNI代码统一存放于frameworks/base/core/jni/路径下，对应Framework层的Java类编写native方法
• 核心逻辑：获取自定义HIDL服务的代理实例，将Framework层传入的Java类型参数转换为HIDL支持的类型，调用HIDL接口方法后，再将返回结果转换为Java类型回传给Framework层
• 修改frameworks/base/core/jni/Android.bp编译配置，将新增的JNI源文件加入编译依赖；同时修改同目录下的onLoad.cpp，完成native方法的注册

Framework层自定义API实现 #

• 在frameworks/base/core/java/android/os/路径下新建系统服务管理类，例如CustomTransManager.java，在类中声明对应native方法、加载JNI库，封装给应用层调用的公开接口
• 修改frameworks/base/services/java/com/android/server/SystemServer.java，在系统服务启动流程中加入自定义服务的初始化逻辑，将服务实例注册到ServiceManager
• 配置Hidden API白名单：修改frameworks/base/config/路径下的hiddenapi白名单文件，将新增的公开API加入白名单，避免非系统应用调用时被系统拦截
• 全量编译framework后更新本地SDK，应用层编译时即可识别到新增的自定义API

应用层调用 #

• 系统应用/授权应用可直接通过Context.getSystemService("custom_trans")获取CustomTransManager实例，直接调用封装好的接口完成数据收发
• 若需开放给第三方应用调用，需将编译生成的更新版android.jar提供给应用方作为编译依赖

常见踩坑提示：AOSP 11全链路开发中90%的异常都来自SELinux权限配置，不要为了调试方便直接关闭SELinux，需逐层级添加对应allow规则，避免后续版本合规、安全风险。HIDL接口正式发布后不要直接修改已有版本的接口定义，需新建更高版本的接口目录做增量迭代，否则会无法通过VTS兼容性测试。

内容的提问来源于stack exchange，提问作者GNK