[MUSIC] Welcome to Part 1 in the lesson on Android Infrastructure Middleware. Which focuses on the hardware abstraction layer, or HAL. After completing this part of the lesson. You'll understand the role that the HAL plays in Android's system architecture. In particular it resides atop the operating system kernel layer. But below the other layers in the Android stack. You'll also understand the technical and economic factors that motivated Google and its OEM partners to add a HAL in Android. We'll start with an overview of Android's abstraction layer. The HAL helps to separate concerns in the Android system architecture. In particular, it separates the Android platform logic from the hardware logic. Likewise it also separates the Android framework layer from the operating system layer. This allows apps to be programmed via method calls on Java objects, rather than C system function calls. Moreover developers were able to focus on business logic. Rather than wrestling with tedious and error-prone details. Of the underlying operating system kernel and hardware device drivers. Android's HAL finds interfaces that these so called drivers must implement. As it turns out of course, these drivers don't actually run in the operating system kernel. Which is a key component of the Android hardware abstraction layer. Some examples of the various drivers that have supported this layer. Include drivers for camera, Bluetooth, GPS, radio, and WiFi. The Android HAL is a user space C/C++ library layer. In contrast, the device drivers that reside in the Android Linux kernel are written in C. This user space code can't directly access the kernel device drivers residing in the Android Linux kernel. Therefore, the apps and system services use the HAL to interact with the kernel device drivers on their behalf. Original equipment manufacturers, or so called OEMs, implement HAL modules. That encapsulate their hardware via the HAL APIs and various system services. For the various system components we just talked about. Such as the camera, media, Bluetooth, TV, sensors, and so on. As an example, the camera hardware from a particular OEM has a camera system service and a camera HAL API. Binary code modules that implement HAL APIs are linked dynamically by Android when they're needed. In other words when they're first accessed. When an app first accesses the camera hardware that's encapsulated by the camera HAL API. Those binary code modules are linked in automatically by the Android Linux kernel. And made available to the HAL layer. We'll now describe several motivations for Android's Hardware Abstraction Layer. There are two types of motivations for Android's user space HAL design. One type of motivation is technical. For example, the HAL shields higher layers of Android software stack. From the underlying idiosyncrasies of a Linux kernel. In particular, cameras, cellular radios, and GPS devices aren't supported consistently by GNU Linux device drivers. The HAL, therefore, defines a consistent object-oriented API. That makes it more convenient to access these underlying hardware elements. Another type of motivation is economic. Kernel device drivers are GPL'd. This means that the source code for the drivers must be disseminated along with the binary code. However, OEMs of Android devices often want to use proprietary hardware and associated software drivers that are not to be released in open source form. Putting these device driver implementations into the user space. HAL therefore relieves them from releasing their source code. This is the end of Part 1 of our lesson on infrastructure middleware. It focused on the Android Hardware Abstraction Layer. [MUSIC]
