Skip to main content

Android Design Lessons: HAL plugin architecture

The Problem

Android OS has a clean separation between framework code and the Hardware Abstract Layer (HAL) code. The former is written by Google and is open source; the later is written by chip vendors and is usually proprietary. The design challenge is how to link them together, without both build time and link time dependency.  

Additional Constraint:
1. The interface is C
2. It is user mode interface not for user/kernel

To make the introduction more specific,  I will use Audio hardware as an example.

The Solution

Use dlopen to load libraries from designated location and use dlsyml to return a module instance, which inherit a common hw module.
Android HAL plugin architecture 

Solution Detail

1. Where to load the library? 

The easies way to fix the path and name of the library to be loaded for each type of module. But that will be too rigid an approach. Instead,Android use a more flexible solution. The library to load follows below conversion:

  {lib_dir}/{module}.{build_variant|default}.so
 where 
   lib_dir = {/vendor/lib/hw , /system/lib/hw}
 module:
   the hw module name, audio in this case
 build_variant:
   it is a property fixed for each build configuration but can be retrieved dynamically


2. How to load the library and create the specific module instance?

Once we know which library to use, we can call dlopen to load the library. But in order to create create an module instance , we need to know which symbol to open. As a contract, every module must have an entry symbol called HAL_MODULE_INFO_SYM, with the type of a concrete hw module type, that is audio_module_t  in our example.

struct audio_module_t HAL_MODULE_INFO_SYM {
     common: {
            tag: HARDWARE_MODULE_TAG,
            id:HW_MODULE_AUDIO,
            methods: &gralloc_module_methods
        },
        start: audio_start,
  }

where audio_module_t  is a subclass of hw_module_t .

typedef struct hw_module_t {
    const char *id;
    const char *name;
    struct hw_module_methods_t* methods;
}hw_module_t; 


typedef struct audio_module_t {
    struct hw_module_t common;  // must be the first member, so we can uppercast from derived to based 
    // module specific methods and attributions
   void (*start)(struct audio_module_t const *module); 
}
Using dlsym to load the address of the HAL_MODULE_INFO_SYM, we get an instance of audio_module_t . We can up-cast the returned instance to of hw_module_t, as the first member of  gralloc_module_t is of type hw_module_t, that make a audio_module_t is a subclass of hw_module_t.

Turning what we describe above as the code: 

static int load(const char *id,
        const char *path,
        const struct hw_module_t **pHmi)
{
    int status = -EINVAL;
    void *handle = NULL;
    struct hw_module_t *hmi = NULL;

    handle = dlopen(path, RTLD_NOW);

   /* Get the address of the struct hal_module_info. */
    const char *sym = HAL_MODULE_INFO_SYM_AS_STR;
    hmi = (struct hw_module_t *)dlsym(handle, sym);

    /* Check that the id matches */
    if (strcmp(id, hmi->id) != 0) {
        ALOGE("load: id=%s != hmi->id=%s", id, hmi->id);
        status = -EINVAL;
        goto done;
    }

   *pHmi = hmi;

    return status;
}

This is a simple but powerful plug-in architecture. In practice, it can be expand it a little bit by introduce another object called device. A device can be created from a module , by calling open method of the module. This is actually a perfect analogy of Linux device driver programming model, where we have a driver installed as a module, and we can open it, through device node, to get a device to work with. 




Popular posts from this blog

Android Camera2 API Explained

Compared with the old camera API, the Camera2 API introduced in the L is a lot more complex: more than ten classes are involved, calls (almost always) are asynchronized, plus lots of capture controls and meta data that you feel confused about.

No worries. Let me help you out. Whenever facing a complex system need a little bit effort to understand, I usually turns to the UML class diagram to capture the big picture.

So, here is the class diagram for Camera2 API.




You are encouraged to read this Android document first and then come back to this article, with your questions. I'll expand what is said there, and list the typical steps of using camera2 API. 

1. Start from CameraManager. We use it to iterate all the cameras that are available in the system, each with a designated cameraId. Using the cameraId, we can get the properties of the specified camera device. Those properties are represented by class CameraCharacteristics. Things like "is it front or back camera", "outpu…

Java Collections Framework Cheat Sheet

Java Collections Framework (JCF) implements the Abstract Data Type  for Java platform. Every serious Java programmer should familiar himself on this topic and be able to choose the right class for specific need.  A thorough introduction to JCF is not the target of this small article and to achieve that goal you can start with this excellent tutorial . 

Instead, I'd like to
1) Provide an overview of JCF's classes ,   2) Provide a cheat sheet you can post in your cubicel for daily reference, 3) Underline the relationship between JCF's implementation and the data structure and algorithm you learned in your undergraduate course

With these goals in mind, I came up following diagram - Java Collection Cheat Sheet. You can click it to zoom in. There is no necessity for more explanation once your familiar with UML class diagram and have a basic understanding of common data structures.


Android Security: An Overview Of Application Sandbox

The Problem: Define a policy to control how various clients can access different resources. A solution: Each resource has an owner and belongs to a group.Each client has an owner but can belongs to multiple groups.Each resource has a mode stating the access permissions allowed for its owner, group members and others, respectively. In the context of operating system, or Linux specifically, the resources can be files, sockets, etc; the clients are actually processes; and we have three access permissions:read, write and execute.