Android的硬件接口HAL

我一直觉得，现代计算机不是一门科学，起码快算不上一门理科科学。上上下下全是人造，左左右右全是生意，用管理学，经济学去学计算机，也许更看得懂很多问题。HAL就是一个典型例子。

传统Linux绕开了微软的霸权，但是又面临GPL要开源的尴尬。谷歌为了迎合资本家封闭发财的愿望，所以搞了HAL这个概念。将原来在内核态的驱动，移了大部分核心内容到用户态，这样就可以封闭，可以垄断赚钱。然后因为HAL这玩意只在安卓上有，配合了安卓的硬件公司反过来又被谷歌绑架，这样一环套一环吃钱。搞这一出，是真的只是科学吗？当然不是，归根结底全是生意。

对安卓接触不久，有些理解不一定对，大家看看就好。

传统Linux怎么调用硬件？就是ko。。。几个函数搞定。Android复杂了很多，所以整理一下。

在安卓中，除了上面讲的HAL，还有一个就是Framework，这个就是app的framework，要理解安卓驱动层，这两点绕不开。为了适配framework，安卓把硬件是作为服务service来使用。在Android中，这种结构也进化了很多代。

首先是传统HAL（Legacy HAL），在内核8.0以前使用。用户态的so貌似保存在/system/lib64，这个版本是直接读取硬件so，比较原始暴力。

App->Service->AIDL->Server->JNI->HAL so->kernel driver

现代HAL（Conventional HAL），使用Iibhardware来管理so，同时下层的驱动使用一个单独的分区，so全部集成到vender.img，和system解绑。要找寻so通过libhardware这个中间层。编译时要提供一个Android.bp文件。

App->Service->AIDL->Server->JNI->Iibhardware->so(vender.img)

在安卓8之后，开始使用HIDL，总的来说就是将HAL封装成服务，完全就是rpc的玩法。

HIDL编译后，会生成Android.bp（这个有时间再看看）。最后会有两个so，一个so，放在system分区；一个impl.so，放在vendor分区，以此实现framework和驱动服务的分离。客户端使用前者，服务端使用后者。服务端包含impl.so之后，会生成一个可执行程序，就可以作为一个service单独运行。客户端包含了so可以直接调用服务。

分为直通式和绑定式。有大神说直通式就是虽然使用HAL，但还是在一个进程，绑定式是使用HAL，但是数据通过Binder转发，上面说的应该就是绑定式。直通式和绑定式也都是HAL生成的代码中控制的。比如：

extern "C" IXXX* HIDL_FETCH_IXXX(const char* name);

AIDL和HIDL的中间就是安卓的framework。

App->AIDL->Service->HIDL->HAL Service->so(vender.img)

全AIDL（10内核开始）。

App->AIDL->HAL Service->so(vender.img)

其中主要涉及到的主要是两个接口，AIDL和HIDL。

首先是AIDL，Android Interface definition language。看资料说是android中两个app交互的IPC方式。首先IPC有很多种，管道，域套接字，message，共享内存，问题是谷歌为什么要搞出来一套新的呢？

从一个AIDL的例子可以看到：

// IMyRemoteService.aidl
interface IMyRemoteService {
    int getValue();
    void setValue(int value);
}

一边使用：

private final IMyRemoteService.Stub mBinder = new IMyRemoteService.Stub()

另一边使用：

mRemoteService = IMyRemoteService.Stub.asInterface(iBinder);

在接口中主要定义的还是函数，也就是说比管道这些更上层，更适合Java的调用。就算上层函数调用，其实也很多方式，比如COM，soap，rpc都是干这事的。安卓应该还是用binder进行统一管理了吧，毕竟是一个单独的服务。

HIDL

主要还是提供底层cpp驱动和上层java的通信。hal文件定义如下：

// ILedService.hal
package android.hardware.led;

interface ILedService {
    int getLedState();
    void setLedState(int state);
};

它的C++语法稍怪：

#include <android/hardware/led/1.0/ILedService.h>
#include <hidl/LegacySupport.h>

using android::hardware::led::V1_0::ILedService;
using android::hardware::Return;
using android::hardware::Void;

class LedService : public ILedService {
public:
    LedService() {}

    Return<int32_t> getLedState() override {
        return mLedState;
    }

    //略
};

int main() {
    return android::hardware::configureRpcThreadpool(1, true) == android::OK &&
           android::hardware::registerAsService(new LedService()) == android::OK
        ? 0
        : 1;
}

Java侧的倒是差不多。

在Binder的使用中，Server端继承BnInterface, Client端继承BpInterface。我接触的工程中，一边叫做BP侧，那么应该就是app侧，BN侧那么就是服务端了。

最后，写完的service可以通过rc文件，作为一个系统服务。

参考：

针对 Android 进行开发 | Android 开发者 | Android Developers

https://source.android.com/docs/core/architecture?hl=zh-cn

https://source.android.com/docs/core/architecture/aidl/aidl-hals?hl=zh-cn

AIDL for HALs实战_hidl会被aidl代替-CSDN博客

Android HIDL 介绍学习和实战应用-CSDN博客

AIDL for HALs实战_hidl会被aidl代替-CSDN博客

HIDL 原理及使用详解-CSDN博客

Android上层与驱动交互完整篇（三）HIDL服务_android.bp hidl_interface-CSDN博客