análisis trama de capa Android HAL (II)

análisis previo de los miembros clave de nuestra hw_module_t (módulo de hardware) y hw_device_t (hardware) de la estructura de la capa HAL androide dos, vamos a ver la parte superior de la aplicación específica en la final es cómo lograr el hardware operativa?

Sabemos que algunos fabricantes de hardware no quieren abrir algunos de su propio núcleo de código a cabo, por lo que estos códigos en la capa HAL, pero la forma de asegurarse de que no lo abre? código de la capa HAL no es también que todos sepan para descargarlo? De hecho, el HAL código principal fabricante de hardware es en forma de una biblioteca compartida, cada vez que sea necesario, Hal se cargará automáticamente la llamada correspondiente bibliotecas compartidas. Así es cómo encontrar una carga de hardware bibliotecas compartidas de TI correspondiente? Esto es por lo que tenemos que decir esto.

Aplicación superior hardware de adquisición de llamada de función del módulo hw_get_module JNI capa por Hal, Hal esta función se ocupa de la entrada superior. Así que si se ejecuta el proceso de mirar el código fuente de las llamadas de programa, esta función es la primera función se denomina capa de Hal, aquí venimos

Desde el comienzo de esta función, la ejecución del proceso del programa para ir junto.

hw_get_module función se define en /hardware/libhardware/hardware.c, abra el archivo se puede ver se define como sigue:

 1 int hw_get_module(const char *id, const struct hw_module_t **module) 
 2 {
 3     int status;
 4     int i;
 5     const struct hw_module_t *hmi = NULL;
 6     char prop[PATH_MAX];
 7     char path[PATH_MAX];
 8 
 9     /*
10      * Here we rely on the fact that calling dlopen multiple times on
11      * the same .so will simply increment a refcount (and not load
12      * a new copy of the library).
13      * We also assume that dlopen() is thread-safe.
14      */
15 
16     /* Loop through the configuration variants looking for a module */
17     for (i=0 ; i<HAL_VARIANT_KEYS_COUNT+1 ; i++) {
18         if (i < HAL_VARIANT_KEYS_COUNT) {
19             if (property_get(variant_keys[i], prop, NULL) == 0) {//获取属性
20                 continue;
21             }
22             snprintf(path, sizeof(path), "%s/%s.%s.so",
23                     HAL_LIBRARY_PATH1, id, prop);
24             if (access(path, R_OK) == 0) break;//检查system路径是否有库文件
25 
26             snprintf(path, sizeof(path), "%s/%s.%s.so",
27                      HAL_LIBRARY_PATH2, id, prop);
28             if (access(path, R_OK) == 0) break;//检查vender路径是否有库文件
29         } else {
30             snprintf(path, sizeof(path), "%s/%s.default.so",//如果都没有,则使用缺省的
31                      HAL_LIBRARY_PATH1, id);
32             if (access(path, R_OK) == 0) break;
33         }
34     }
35 
36     status = -ENOENT;
37     if (i < HAL_VARIANT_KEYS_COUNT+1) {
38         /* load the module, if this fails, we're doomed, and we should not try
39          * to load a different variant. */
40         status = load(id, path, module);//装载库,得到module
41     }
42 
43     return status;
44 }

 

 Mira la primera línea sabemos que hay dos parámetros, el primer parámetro es el identificador id para obtener un módulo de hardware, el segundo parámetro es un puntero módulo queremos que la estructura del módulo de hardware.

Se puede observar, ID hal necesidades de capa superior a ser adquiridos al primer módulo de hardware, la función hw_get_module para encontrar que coincide con el ID y la estructura del módulo de hardware correspondiente de acuerdo con este ID.

Echemos un vistazo a cómo encontrar.

Hay 17 líneas de bucle, el límite superior es HAL_VARIANT_KEYS_COUNT + 1, entonces este HAL_VARIANT_KEYS_COUNT ¿Qué es? Encontrado bajo vista el mismo archivo son:

static const int HAL_VARIANT_KEYS_COUNT =  (sizeof(variant_keys)/sizeof(variant_keys[0]));

Es el número original de elementos de la matriz de ariant_keys. Así que esta matriz, ¿qué es? En este documento buscando, somos:

/**
 * There are a set of variant filename for modules. The form of the filename
 * is "<MODULE_ID>.variant.so" so for the led module the Dream variants 
 * of base "ro.product.board", "ro.board.platform" and "ro.arch" would be:
 *
 * led.trout.so
 * led.msm7k.so
 * led.ARMV6.so
 * led.default.so
 */

static const char *variant_keys[] = {
    "ro.hardware",  /* This goes first so that it can pick up a different
                       file on the emulator. */
    "ro.product.board",
    "ro.board.platform",
    "ro.arch"
};

Podemos ver que en realidad es una matriz de cadenas. La estación no sabe qué hacer. Hw_get_module funciones siguen buscando en el bucle, véase la línea 22, de hecho, es HAL_LIBRARY_PATH1, identificación, prop tres cuerdas juntas de un camino,

HAL_LIBRARY_PATH1 se define como sigue:

/** Base path of the hal modules */
#define HAL_LIBRARY_PATH1 "/system/lib/hw"
#define HAL_LIBRARY_PATH2 "/vendor/lib/hw"

id es un, valor prop proporcionado superior de esta variable es la primera línea 19 property_get función (variant_keys [i], prop, NULL) para llegar, de hecho, esta función es una propiedad por ariant_keys matriz de búsqueda a los corresponde sistema de nombres de variante. Las diferentes plataformas para obtener el valor del apoyo no es lo mismo.

Si el valor adquirido es tout apoyo, Identificación del módulo de hardware que necesita ser adquiridos leds, a continuación, la última ruta es la cadena que consiste /system/lib/hw/leds.tout.so.

24 detrás de la línea de acceso es comprobar si la presencia de este camino, si es que se rompa, fuera del circuito. Si no es así, continúan yendo a continuación,

Aquí se puede ver sólo unas pocas líneas y formas similares,

snprintf(path, sizeof(path), "%s/%s.%s.so",  HAL_LIBRARY_PATH2, id, prop);

if (access(path, R_OK) == 0) break;//检查vender路径是否有库文件

HAL_LIBRARY_PATH2 de la unión "/ vendedor / lib / hw", asumiendo el mismo valor se adquiere prop tout, Identificación necesita ser adquirida es un LED del módulo de hardware, en este caso el valor está fuera del hechizo ruta / vendedor / lib / hw / leds .tout.so y, a continuación, determinar si existe el archivo. Si hay fuera del circuito.

Del análisis anterior, de hecho, se trata de las bibliotecas de búsqueda manera hal capa dinámica compartida, de la que podemos conseguir dos cosas:

1. Las bibliotecas dinámicas compartida normalmente se colocan en el "/ system / lib / HW" y "/ Vendedor / lib / hw" dos caminos.

2. El nombre de la biblioteca dinámica en forma de "id.variant.so" nombrado, donde id proporcionado para la variante de nombre superior, medio de variante, se incluye con el cambio de plataforma.

Luego, a partir de las líneas 29-32 podemos ver que cuando todas las variantes del nombre no existe en la forma de paquetes, con respecto a la forma "id.default.so" del nombre del paquete existe de búsqueda.

Línea 37, si (i <HAL_VARIANT_KEYS_COUNT + 1), si i es menor que el nombre var de la matriz, entonces, que encontraron una biblioteca correspondiente, luego la línea 38 de carga (id, trayectoria, módulo); // biblioteca de carga, módulo obtenido.


Hal capa por encima de ella para gobernar la base de búsqueda de averiguar.
 

A continuación vamos a entrar en la función de carga para ver cómo se carga la biblioteca compartida.

Publicados 407 artículos originales · ganado elogios 150 · vistas 380 000 +

Supongo que te gusta

Origin blog.csdn.net/ds1130071727/article/details/104908801
Recomendado
Clasificación