自定义Android ROM开发疑问：HAL作用、内核交互及系统服务修改问题

• HAL定义与核心作用：HAL（硬件抽象层）是Android系统栈中位于应用框架层与Linux内核层之间的中间抽象层，核心作用是解耦上层框架逻辑和底层硬件驱动实现：一方面让Google的AOSP通用框架代码不需要适配不同厂商的硬件差异，另一方面也支持硬件厂商将驱动相关的实现逻辑闭源发布，不需要遵循内核的GPL开源协议。
• HAL与内核的交互逻辑：HAL一定会和内核产生交互。HAL层会按硬件类型拆分为不同的独立模块（如音频、相机、传感器、显示等），每个模块内部封装对应硬件的操作逻辑，通过open()、ioctl()、mmap等标准Linux系统调用直接和内核态的硬件驱动通信，拿到硬件返回结果后，再按照Android定义的HAL标准接口格式返回给上层框架，上层框架完全不需要感知底层驱动的具体实现。
• HAL实现时机：正常的设备适配流程中，HAL实现是在对应硬件的内核驱动调通之后、上层框架适配之前完成的。如果你是新增自定义外设、扩展系统硬件能力，只需要在内核驱动开发完成后，同步实现对应自定义硬件的HAL模块即可。

• 是否可以新增/修改系统服务：完全可以，这是定制ROM的常见操作。如果是修改原有系统服务，直接修改AOSP中对应服务的源码逻辑即可；如果是新增自定义系统服务，按标准流程注册到SystemServer中即可正常运行。
• 是否需要编写Binder IPC接口：是的，只要需要让应用框架层、第三方应用跨进程调用该系统服务，就必须定义对应的AIDL接口。常规的自定义系统服务开发流程如下：
  1. 定义服务对应的AIDL接口文件，放置到frameworks/base/core/java/下的对应包路径，编译时AOSP的构建系统会自动生成Binder通信需要的Stub、Proxy类代码
  2. 编写系统服务实现类，继承自动生成的AIDL Stub类，实现所有接口的业务逻辑
  3. 在SystemServer的启动流程中添加服务注册代码，将你的服务实例注册到ServiceManager中，服务会随SystemServer进程一同启动
  4. 若需要简化上层调用，可以新增对应的Manager类，封装getSystemService()获取服务代理的逻辑，对外暴露易用的调用接口

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