アンドロイドドライブに係合または下に従事するとして、私は自分の分析の全体のアイデアを書き留めて何を総括して、私は、それがマスターにHALのために必要であると思いますが、一定の深さに到達しなければなりません。
Androidの主なソースコードを参照するために、ソースコードが考えに従って得られます。（本は役に立つ本あるかを確認するよりも、ソースコードを参照してください）
何というHALをアンドロイド？それはなぜか？
ハードウェア抽象化層は、上部層とAndroidカーネルカーネルとの間の抽象化層構造との間です。彼は、Linux駆動の、基礎となるハードウェアへの統一されたインタフェースを提供するために、上層のパッケージで、上位アプリケーションは、基礎となる実装の詳細を遮蔽し、特定の仕事を達成する方法を知っている必要はありません。
下に示すように、それはアンドロイドアーキテクチャ全体で配置します。
基本的にはLinuxカーネル空間でドライバを実現し、従来のLinuxオペレーティング・ハードウェア、そしてなぜ、二つの部分に分かれてハードウェアの動作を邪魔して、今そうHALとそれを駆動LINUX？
また、ユーザ空間のHAL、ドライブに属するのLinuxカーネル空間に属します。実際には、冗長ではありません。では、なぜこのようなことが高ければ高いほど、多数の引用：
フレームワークアップ1. GoogleのHAL設定、JNI呼び出しHALを介して上の演奏のための枠組みが統一APIを提供し、ハードウェア開発者や移植が唯一の上位層との相互作用のエネルギー法案の実現せずにフレームワークの開発を追跡する必要があります、自身が達成することができ、HAL層に焦点を当てます。
ビジネスの観点から、2は、多くのハードウェアメーカーは、カーネル空間ドライバの実装にすべてのハードウェアドライバを所有する場合は、ハードウェア関連のものは、外開き、コアの一部を所有したくない、あなたはGPLに準拠している必要があり、オープンソースが必要です。appache契約は次のようであるあなたがHAL層があれば、彼らはユーザ空間でコア層、およびHAL層にHALのようなもののアルゴリズムを実現することができ、Linuxカーネル、およびAndroidのソースコードに属し、これはオープンソースではありませんまたは開けません。
最後に、以下のソースのHAL HAL層を分析するために応じて存在意義うちハルの図は、フレームワークと原則、何の詳細な分析を実現する方法です。
コードは、主にトップダウンからレッツ・ゴーlibhardware / /ハードウェアにあるHAL層をアンドロイド。
層HALにおいて、ハードウェアの様々な種類のHAL層構造が記載されてhw_module_tハードウェア・モジュールの形式で記述されており、ハードウェア・モジュールの各タイプは、それぞれ独立したハードウェアを持っている、Halは構造hw_device_tであります彼は体を説明しました。
トップアプリのハードウェアによるJNI呼び出しは、最初に、この順序と動作するようにハードウェアと、ハードウェアモジュールであるhw_module_t構造に取得する必要があります。その後、我々はそれがどんなものかを定義これら二つの構造を見見てみましょう。
彼らは/hardware/libhardware/include/hardware/hardware.h内部で定義されています。
。hw_module_tは、主に情報の定義を含むハードウェアモジュール、モジュールのハードウェア構成の一部を表します。
/**
* Every hardware module must have a data structure named HAL_MODULE_INFO_SYM
* and the fields of this data structure must begin with hw_module_t
* followed by module specific information.
*/
typedef struct hw_module_t {
/** tag must be initialized to HARDWARE_MODULE_TAG */
uint32_t tag; //tag，根据引文注释可以看到必须被初始化为HARDWARE_MODULE_TAG
/** major version number for the module */
uint16_t version_major;//主版本号
/** minor version number of the module */
uint16_t version_minor;//次版本号
/** Identifier of module */
const char *id;//模块id字符串
/** Name of this module */
const char *name;//模块名
/** Author/owner/implementor of the module */
const char *author;//作者
/** Modules methods */
struct hw_module_methods_t* methods;//硬件模块方法结构体
/** module's dso */
void* dso;//打开硬件模块的库时得到的句柄
/** padding to 128 bytes, reserved for future use */
uint32_t reserved[32-7];
} hw_module_t;プロパティのいくつかのメンバーは、それが指すこのポインタ方法を見ることができないハードウェアモジュールのこの方法に関連した構造であり、以下のhw_module_methods_tを見てみましょう、私たちは皆知っていると信じていたコメントを読んで、言うことはありませんことを前面タグ、名前私はいくつかの関数ポインタが存在しなければならないと思いますが、唯一の関数ポインタがあります。私たちは、定義を見ることができます：
1 typedef struct hw_module_methods_t {
2 /** Open a specific device */
3 int (*open)(const struct hw_module_t* module, const char* id,//打开硬件设备函数指针
4 struct hw_device_t** device);
5
6 } hw_module_methods_t;私たちは、実際には関数ポインタを参照してくださいオープン機能のハードウェアモジュールのハードウェアデバイスを開くことができます。
そして、それに関連した返されるハンドルデバイスのハードウェアモジュールの量の後に開かれているvoid *型DSOのメンバーは、リアビューhw_get_moduleにおけるソース関数は、あなたが理解するとき。
B。ここではhw_device_t構造を見て、この構造は、主に属性情報モジュールのハードウェアまたは何かを記述するために使用されます。ハードウェアモジュールは、ハードウェアデバイスを複数有していてもよいです。
例えば、センサモジュール、sensor_moduleは、ハードウェアモジュールであるが、良い品種に対応するセンサで電話、等加速度acc_sensor、磁気センサM_sensor、として、それらはすべてsensor_moduleに属し、彼らは自分自身を持っていました
hw_device_t構造について説明します。hw_device_t定義：
1 /**
2 * Every device data structure must begin with hw_device_t
3 * followed by module specific public methods and attributes.
4 */
5 typedef struct hw_device_t {
6 /** tag must be initialized to HARDWARE_DEVICE_TAG */
7 uint32_t tag; //设备tag
8
9 /** version number for hw_device_t */
10 uint32_t version;//版本
11
12 /** reference to the module this device belongs to */
13 struct hw_module_t* module;//本设备归属的硬件模块
14
15 /** padding reserved for future use */
16 uint32_t reserved[12];//保留
17
18 /** Close this device */
19 int (*close)(struct hw_device_t* device);//关闭设备的函数指针
20
21 } hw_device_t;前記本装置の第三のメンバーのハードウェアモジュールが向けられているモジュール構造体が属します。
最後に、近い関数ポインタ点は間違いデバイス機能オフです。
まあ、これは、終了したHAL二つの主要な構造、我々は引き続き次は、この作品は、ハードウェア・モジュール、ハードウェアデバイスを取得する方法を最上部に見てどのように見て最後にソースコード、HAL層を組み合わせ、そして最後になりますこれは、動的にロードされる共有ライブラリを解決する方法です。
