Android O 前期预研之二：HIDL相关介绍

在上一篇博客里，大致介绍了下Android O 中treble计划的一些背景与相关基本架构，这一篇中跟大家一起来探讨下HIDL相关的内容。

Android HAL类型
在此之前的ANDROID版本当中Android HAL没有什么特殊的特殊的，也么有什么分类，但是从android 8.0开始，Android重构了HAL与Android FW之间的联系结构，所以Android HAL会被区分成以下2种类型：
1，Binderized HALs，从名字上应该是指Binder化的HAL，对Android 比较熟悉的同学应该对binder这个东西很熟悉，我们是不是可以大胆猜猜下Android 8.0里的HAL是不是都是binder化了？也就是说HAL都被写成了binder service了？Android FW都是binder client?后续我们研究研究再来看看我们的猜测是不是正确的。
2，Passthrough HALs，从google的官方介绍来说，这个是对原先HAL的包装，但是最终的binder service 跟binder client都是活在同一个进程当中。这个应该是对老版本HAL的兼容。
3，Same-Process HALs,由于某些性能的因素，这些HALs必须运行在Android Framework 所在的进程当中。

按照google的要求，新设计生产的Android O设备，必须而且只能支持 Binderized HALs，而老版本的设备升级到Android O可以支持 Passthrough HALs，但是有些HAL也必须修改成 Binderized HALs。

以下HAL可以根据是升级设备或者新设备自由选择：

以下跟graphic相关的HAL因为涉及到性能问题，只能在同一个进程当中运行：

HIDL的相关介绍
HIDL的全称是HAL interface definition language（硬件抽象层接口定义语言），在此之前Android 有AIDL，架构在Android binder 之上，用来定义Android 基于Binder通信的Client 与Service之间的接口。HIDL也是类似的作用，只不过定义的是Android Framework与Android HAL实现之间的接口。

在AIDL机制中Android 会提供一系列工具会将用户定义的*.aidl文件编译生成Client端代码与Service端代码，用户仅仅 需要1）在Service端实现所需要实现的接口。2）在Client端调用相关接口。基于Binder机制，在Clinet端的调用会自动通过binder驱动跨进程到service进程当中。

而在HIDL里，与AIDL比较类似，底层也是基于binder机制。但是也有稍微不一样的地方。为了支持HIDL，Android 对BInder做了一定程度的修改。

接下来，我们来研究下HIDL的语法，以及通过一个实际的例子来真实感受下HIDL。

HIDL的基本语法：

1）定义接口:

package android.hardware.tests.foo@1.0;
  interface ISimpleTest {
   
   enum SomeBaseEnum : uint8_t {
        bar = 66
    };

    struct Goober {
        int32_t q;
        string name;
        string address;
    };
      getCookie() generates (int32_t cookie);
      customVecInt() generates (vec<int32_t> chain);
      customVecStr() generates (vec<string> chain);
      mystr() generates (string str);
      myhandle