Android Hal

ANDROID HAL
Hardware Abstraction Layer
YEHYAOUI IMED
Table des matires
Introduction : ANDROID Hardware Abstraction Layer ............................................................................ 2 Pourquoi ANDROID a choisi cette approche ? ........................................................................................ 2 Position de la couche HAL dans larchitecture ANDROID: ...................................................................... 3 Emplacement dans la structure des dossiers: ......................................................................................... 4 Conventions:........................................................................................................................................ 4 Examples.............................................................................................................................................. 5 Pendant lexcution (RUNTIME):............................................................................................................. 5 Caractristiques et critique de cette approche : .................................................................................... 6
Introduction : ANDROID Hardware Abstraction Layer

Contrairement aux autres systmes bass sur Linux, les applications tournant sous Android communiquent avec le matriel par le biais des API Java non par les appels systme. Bien quAndroid s'appuie sur les abstractions matrielles et les capacits du noyau, son approche est trs diffrente. Sur un plan purement technique, la diffrence la plus flagrante est que ses sous-systmes et les bibliothques ne comptez pas sur les entres standard /dev pour fonctionner correctement. Au lieu de cela, la pile Android repose gnralement sur les bibliothques partages fournies par les fabricants pour interagir avec le matriel. En effet, Android s'appuie sur ce qui peut tre considr comme un Hardware Abstraction Layer (HAL) . La couche d'abstraction matrielle (Hardware Abstraction Layer ou HAL) est une spcification et un utilitaire logiciel qui traque les priphriques du systme informatique. Cest une couche connectable qui fournit des informations propos du matriel. Bien que, comme nous allons le voir, l'interface, le comportement et les fonctions fournies par le composant dabstraction matriel diffrent grandement d'un type l'autre. De plus, la plupart des piles logicielles qui se trouve gnralement dans les distributions Linux pour interagir avec le matriel ne figurent pas dans Android. Il n'existe pas de systme X Window, par exemple, et tandis que les pilotes ALSA sont parfois utiliss (une dcision laisse au fabricant du matriel qui fournit la bibliothque partage pour implmenter le support audio pour le HAL), leur fonctionnalit est diffrente de celle sur les distributions Linux standard.
Pourquoi ANDROID a choisi cette approche ?

pas tous les drivers kernel ont des interfaces standardises. les drivers kernel sont sous licence GPL ce qui exposerait les interfaces propritaires des fabricants. Les fabricants veulent pouvoir garder ces interfaces en "closed source" Android a des besoins spcifiques pour les drivers kernel.
Position de la couche HAL dans larchitecture ANDROID:
Figure 1 : L'architecture d'androde
La couche HAL se situe entre les librairies et le kernel linux, elle fournit les interfaces que doivent implmenter les drivers kernel. Elle spare la plateforme logique des interfaces matrielles. Le but de cette couche est de faciliter le portage des librairies sur diffrents matriels. La structure de base de l'architecture Android HAL a t tendu pour supporter diffrents matriels tout en assurant la compatibilit SoC tous les services Android systme et les applications. Pour faire face diffrents combinaison de fonctions matrielles et logicielles, l'actuel Android HAL a t construite au-dessus de l'interface unifie HAL .
Figure 2: les interactions entres les couches ANDROID
La plupart des libs partages dans le diagramme ci-dessus reprsentent les modules HAL. La couche HAL est le lien entre n'importe quel appareil (partie du noyau) et le correspondant interface JNI. Les dtails sur la couche HAL nest gnralement pas d'intrt pour les dveloppeurs d'applications. Cependant, il est un module important pour les fournisseurs de matriel et les quipementiers impliqus dans le portage androde dans leur propre matriel et ajout de nouveau matriel.
Emplacement dans la structure des dossiers:

Le code source HAL rside principalement dans le dossier matriel hardware . OEM maintien une racine rpertoire racine de haut niveau et l'intrieur il ya plusieurs modules HAL pour le matriel correspondant. Dans le dispositif, la HAL rside soit dans / system / lib / hw ou / vendor / lib / hw et autres. Les modules de HAL suivre une certaine nomenclature. Android s'appuie sur une convention de nommage pour charger le bon module HAL pour une configuration donne du matriel.
Conventions:
/system/libs/hw/<*_HARDWARE_MODULE_ID>.<ro.product.board>.so /system/libs/hw/<*_HARDWARE_MODULE_ID>.<ro.board.platform>.so /system/libs/hw/<*_HARDWARE_MODULE_ID>.<ro.arch>.so /system/libs/hw/<*_HARDWARE_MODULE_ID>.default.so
Ils ont aussi une interface bien dfinie qui rside dans:
4
include/hardware/
Un module peut avoir plusieurs variantes: "default", "arch", "board" Et ils sont chargs dans l'ordre : "board", "arch", "default" Le code source pour "board" est habituellement dans : Partners/... Le code source pour "default" and "arch" est habituellement dans : hardware/modules/
Examples
Radio Interface Layer (RIL) hardware/ril/ BT external/bluetooth Legacy WiFi hardware/libhardware_legacy/wifi
Pendant lexcution (RUNTIME):

La HAL est charg par ses clients l'aide de la hw_get_module. Cette mthode s'appuie sur les valeurs dfinies ro.hardware , ro.product.board et d'autres proprits ro pour charger le fichier .so approprie. Par exemple, le SurfaceFlinger est le compositeur du systme et le
compositeur du matriel est un HAL qui fait labstraction logique de la composition spcifique du matriel. Le SurfaceFlinger charge le compositeur matriel en utilisant la mthode hw_get_module pour obtenir le contrle sur la HAL.
Le contrat entre le service et le systme HAL est bien dfinie. Les fabricants d'appareils doivent s'assurer que ces interfaces sont mises en uvre comme prvu par les services de Android. La figure ci-dessous montrer une partie de la HAL sur la version Android ICS et les mthodes cls qui HAL devraient mettre en uvre.
Figure 3: Les modules HAL dans ANDROID ICS
Avec les nouvelles versions d'Android, la porte de HAL ont largi et il est probable qu'ils seront utilis non seulement pour labstraction matriel, mais de faire labstraction de tout comportement matriel spcifique.
Caractristiques et critique de cette approche :
Figure 4: Structure des interactions app-sys-materiel
L'une des principales caractristiques de cette approche est que la licence sous laquelle le partage de bibliothque est distribu est la responsabilit du fabricant du matriel. Ainsi, un fabricant de l'appareil pouvez crer un pilote de priphrique simpliste qui implmente les primitives les plus lmentaires pour accder un morceau donn de matriel et de faire ce pilote disponible sous licence GPL. Peu serait rvl sur le matriel, puisque le pilote ne ferais pas quelque chose de compliqu. Ce conducteur serait alors exposer le matriel l'espace utilisateur par mmap() ou ioctl() et la majeure partie de l'intelligence serait mis en uvre au sein d'une bibliothque en espace utilisateur qui utilise ces fonctions pour conduire le matriel. Androde n'a pas en fait spcifi la manire dont la bibliothque partage et le conducteur ou le sous-systme du noyau doivent interagir. Seule l'API fournie par la bibliothque partage pour les couches suprieures est spcifi par Androde. Quel que soit le mcanisme utilis pour charger une bibliothque , un service de systme correspondant au type de matriel est habituellement responsable du chargement et l'interfaage avec la bibliothque partag. Ce service systme sera responsable de l'interaction et la coordination avec les autres services du systme pour que le matriel se comporter cohrente avec le reste du systme et l'API exposes dveloppeurs d'applications. Habituellement, le service systme sera divis en deux parties, une partie en Java qui implmente la plupart de l'intelligence Android-spcifique et une autre partie dans C dont lemploi principal est d'interagir avec le matriel de bibliothque partage de support et d'autres fonctions de bas niveau.

Android Hal

Transféré par

Droits d'auteur :

Formats disponibles

Android Hal

Transféré par

Informations du document

Description originale:

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Android Hal

Transféré par

Droits d'auteur :

Formats disponibles

ANDROID HAL

Hardware Abstraction Layer

Table des matires

Introduction : ANDROID Hardware Abstraction Layer

Pourquoi ANDROID a choisi cette approche ?

Position de la couche HAL dans larchitecture ANDROID:

Figure 1 : L'architecture d'androde

Figure 2: les interactions entres les couches ANDROID

Emplacement dans la structure des dossiers:

Pendant lexcution (RUNTIME):

Figure 3: Les modules HAL dans ANDROID ICS

Caractristiques et critique de cette approche :

Figure 4: Structure des interactions app-sys-materiel

Vous aimerez peut-être aussi