hardware_hardwareprotect如何删除 - CSDN
精华内容
参与话题
  • hardware.exe

    2020-07-30 23:33:20
    网上流传的机器码修改器可以去网上参考教程使用 不保证百分百可以
  • HAL 详解之 hardware 详解

    千次阅读 2019-01-10 21:28:40
    ... 请转载的朋友标明出处~~   前言: 《Android 系统HAL 简介》一文和《Android,在争议中逃离 Linux 内核的 GPL 约束》中对HAL 做了简单的简介,这一文中对HAL 进行详细的分析。...android HAL 主要框架来源于:.....

     

    文章出处:http://blog.csdn.net/shift_wwx/article/details/54969612

    请转载的朋友标明出处~~

     

    前言:

    《Android 系统HAL 简介》一文和《Android,在争议中逃离 Linux 内核的 GPL 约束》中对HAL 做了简单的简介,这一文中对HAL 进行详细的分析。

     

     

    android HAL 主要框架来源于:

    /hardware/libhardware/hardware.c

    /hardware/libhardware/include/hardware/hardware.h

     

    本文主要对这两部分分析:

    • hardware.h
    • hardware.c

     

    hardware.h

    1、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;
    
        /**
         * The API version of the implemented module. The module owner is
         * responsible for updating the version when a module interface has
         * changed.
         *
         * The derived modules such as gralloc and audio own and manage this field.
         * The module user must interpret the version field to decide whether or
         * not to inter-operate with the supplied module implementation.
         * For example, SurfaceFlinger is responsible for making sure that
         * it knows how to manage different versions of the gralloc-module API,
         * and AudioFlinger must know how to do the same for audio-module API.
         *
         * The module API version should include a major and a minor component.
         * For example, version 1.0 could be represented as 0x0100. This format
         * implies that versions 0x0100-0x01ff are all API-compatible.
         *
         * In the future, libhardware will expose a hw_get_module_version()
         * (or equivalent) function that will take minimum/maximum supported
         * versions as arguments and would be able to reject modules with
         * versions outside of the supplied range.
         */
        uint16_t module_api_version;
    #define version_major module_api_version
        /**
         * version_major/version_minor defines are supplied here for temporary
         * source code compatibility. They will be removed in the next version.
         * ALL clients must convert to the new version format.
         */
    
        /**
         * The API version of the HAL module interface. This is meant to
         * version the hw_module_t, hw_module_methods_t, and hw_device_t
         * structures and definitions.
         *
         * The HAL interface owns this field. Module users/implementations
         * must NOT rely on this value for version information.
         *
         * Presently, 0 is the only valid value.
         */
        uint16_t hal_api_version;
    #define version_minor hal_api_version
    
        /** Identifier of module */
        const char *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;
    
    #ifdef __LP64__
        uint64_t reserved[32-7];
    #else
        /** padding to 128 bytes, reserved for future use */
        uint32_t reserved[32-7];
    #endif
    
    } hw_module_t;

    首先来看结构体的解释:

    每一个硬件模块必须有一个命名为HAL_MODULE_INFO_SYM的数据结构体。这个结构体成员必须以hw_module_t 开头。

    这个命名在头文件中有定义:

    #define HAL_MODULE_INFO_SYM         HMI

    例如hdmi cec:

    typedef struct hdmi_cec_module {
        /**
         * Common methods of the HDMI CEC module.  This *must* be the first member of
         * hdmi_cec_module as users of this structure will cast a hw_module_t to hdmi_cec_module
         * pointer in contexts where it's known the hw_module_t references a hdmi_cec_module.
         */
        struct hw_module_t common;
    } hdmi_module_t;

    hdmi cec 就定义了一个自己的结构体hdmi_module_t,而开头也必须是hw_module_t

    下面来详细解释hw_module_t 的数据成员:

    1)tag

    这个tag 必须初始化为 HARDWARE_MODULE_TAG

    2)module_api_version

    标记硬件模块的接口api 版本,当模块的接口变化的时候由module 自身更新这个值。

    例如hdmi cec 就自己定义了一个版本:

    #define HDMI_CEC_MODULE_API_VERSION_1_0 HARDWARE_MODULE_API_VERSION(1, 0)

    3)hal_api_version
    标记HAL api 的版本,主要标记hw_module_t,hw_module_methods_t,hw_device_t 等结构体的版本

    目前都用宏HARDWARE_HAL_API_VERSION表示:

    #define HARDWARE_HAL_API_VERSION HARDWARE_MAKE_API_VERSION(1, 0)

    4)id

    硬件模块的标记,查找module 的时候就是通过这个查找,很关键
    例如hdmi cec:

    #define HDMI_CEC_HARDWARE_MODULE_ID "hdmi_cec"

    5)name

    硬件模块的名字,与id 不同,id 原意是Identifier,也就是辨认都是通过id

    6)author

    author/owner/implementor 的标记

    7)methods

    变量是结构体指针 hw_module_methods_t*,里面是一个open 函数,device 的open 就靠这个methods

    8)dso

    在hardware.c中会解释,dlopen so 时候的handle

     

    2、hw_module_methods_t

    typedef struct hw_module_methods_t {
        /** Open a specific device */
        int (*open)(const struct hw_module_t* module, const char* id,
                struct hw_device_t** device);
    
    } hw_module_methods_t;

    hw_module_t 的成员,放的是函数指针,成员是open,也就是硬件模块自身要有这样的open 函数,用于实现硬件模块对相应的设备进行初始化

    3、hw_device_t

    /**
     * Every device data structure must begin with hw_device_t
     * followed by module specific public methods and attributes.
     */
    typedef struct hw_device_t {
        /** tag must be initialized to HARDWARE_DEVICE_TAG */
        uint32_t tag;
    
        /**
         * Version of the module-specific device API. This value is used by
         * the derived-module user to manage different device implementations.
         *
         * The module user is responsible for checking the module_api_version
         * and device version fields to ensure that the user is capable of
         * communicating with the specific module implementation.
         *
         * One module can support multiple devices with different versions. This
         * can be useful when a device interface changes in an incompatible way
         * but it is still necessary to support older implementations at the same
         * time. One such example is the Camera 2.0 API.
         *
         * This field is interpreted by the module user and is ignored by the
         * HAL interface itself.
         */
        uint32_t version;
    
        /** reference to the module this device belongs to */
        struct hw_module_t* module;
    
        /** padding reserved for future use */
    #ifdef __LP64__
        uint64_t reserved[12];
    #else
        uint32_t reserved[12];
    #endif
    
        /** Close this device */
        int (*close)(struct hw_device_t* device);
    
    } hw_device_t;

    上面hw_module_t 的时候说到,每个硬件模块有个名字为HAL_MODULE_INFO_SYM 的数据结构,而且成员必须是hw_module_t 开头。

    这里一样,在硬件模块定义自身设备结构的时候,数据成员必须以hw_device_t 开头。
    例如hdmi cec,在定义自身设备成员的时候就是以这个开头:

    typedef struct hdmi_cec_device {
        /**
         * Common methods of the HDMI CEC device.  This *must* be the first member of
         * hdmi_cec_device as users of this structure will cast a hw_device_t to hdmi_cec_device
         * pointer in contexts where it's known the hw_device_t references a hdmi_cec_device.
         */
        struct hw_device_t common;
    
        /*
         * (*add_logical_address)() passes the logical address that will be used
         * in this system.
         *
         * HAL may use it to configure the hardware so that the CEC commands addressed
         * the given logical address can be filtered in. This method can be called
         * as many times as necessary in order to support multiple logical devices.
         * addr should be in the range of valid logical addresses for the call
         * to succeed.
         *
         * Returns 0 on success or -errno on error.
         */
        int (*add_logical_address)(const struct hdmi_cec_device* dev, cec_logical_address_t addr);
    
        /*
         * (*clear_logical_address)() tells HAL to reset all the logical addresses.
         *
         * It is used when the system doesn't need to process CEC command any more,
         * hence to tell HAL to stop receiving commands from the CEC bus, and change
         * the state back to the beginning.
         */
        void (*clear_logical_address)(const struct hdmi_cec_device* dev);
    
        /*
         * (*get_physical_address)() returns the CEC physical address. The
         * address is written to addr.
         *
         * The physical address depends on the topology of the network formed
         * by connected HDMI devices. It is therefore likely to change if the cable
         * is plugged off and on again. It is advised to call get_physical_address
         * to get the updated address when hot plug event takes place.
         *
         * Returns 0 on success or -errno on error.
         */
        int (*get_physical_address)(const struct hdmi_cec_device* dev, uint16_t* addr);
    
        /*
         * (*send_message)() transmits HDMI-CEC message to other HDMI device.
         *
         * The method should be designed to return in a certain amount of time not
         * hanging forever, which can happen if CEC signal line is pulled low for
         * some reason. HAL implementation should take the situation into account
         * so as not to wait forever for the message to get sent out.
         *
         * It should try retransmission at least once as specified in the standard.
         *
         * Returns error code. See HDMI_RESULT_SUCCESS, HDMI_RESULT_NACK, and
         * HDMI_RESULT_BUSY.
         */
        int (*send_message)(const struct hdmi_cec_device* dev, const cec_message_t*);
    
        /*
         * (*register_event_callback)() registers a callback that HDMI-CEC HAL
         * can later use for incoming CEC messages or internal HDMI events.
         * When calling from C++, use the argument arg to pass the calling object.
         * It will be passed back when the callback is invoked so that the context
         * can be retrieved.
         */
        void (*register_event_callback)(const struct hdmi_cec_device* dev,
                event_callback_t callback, void* arg);
    
        /*
         * (*get_version)() returns the CEC version supported by underlying hardware.
         */
        void (*get_version)(const struct hdmi_cec_device* dev, int* version);
    
        /*
         * (*get_vendor_id)() returns the identifier of the vendor. It is
         * the 24-bit unique company ID obtained from the IEEE Registration
         * Authority Committee (RAC).
         */
        void (*get_vendor_id)(const struct hdmi_cec_device* dev, uint32_t* vendor_id);
    
        /*
         * (*get_port_info)() returns the hdmi port information of underlying hardware.
         * info is the list of HDMI port information, and 'total' is the number of
         * HDMI ports in the system.
         */
        void (*get_port_info)(const struct hdmi_cec_device* dev,
                struct hdmi_port_info* list[], int* total);
    
        /*
         * (*set_option)() passes flags controlling the way HDMI-CEC service works down
         * to HAL implementation. Those flags will be used in case the feature needs
         * update in HAL itself, firmware or microcontroller.
         */
        void (*set_option)(const struct hdmi_cec_device* dev, int flag, int value);
    
        /*
         * (*set_audio_return_channel)() configures ARC circuit in the hardware logic
         * to start or stop the feature. Flag can be either 1 to start the feature
         * or 0 to stop it.
         *
         * Returns 0 on success or -errno on error.
         */
        void (*set_audio_return_channel)(const struct hdmi_cec_device* dev, int port_id, int flag);
    
        /*
         * (*is_connected)() returns the connection status of the specified port.
         * Returns HDMI_CONNECTED if a device is connected, otherwise HDMI_NOT_CONNECTED.
         * The HAL should watch for +5V power signal to determine the status.
         */
        int (*is_connected)(const struct hdmi_cec_device* dev, int port_id);
    
        /* Reserved for future use to maximum 16 functions. Must be NULL. */
        void* reserved[16 - 11];
    } hdmi_cec_device_t;

    下面来详细解释hw_device_t 的数据成员:

    1)tag

    必须初始化为HARDWARE_DEVICE_TAG
    2)version

    硬件设备接口的版本

    3)module

    标记该设备属于哪个硬件模块,例如audio 可能会有多种device

    4)reserved

    暂时没用到

    5)close

    函数指针,也就是说需要实现close 用于后面device 设备close 回收

     

    4、两个对外接口

    hw_get_module、hw_get_module_by_class

    下面hardware.c 中详细说明

     

    小结:android HAL 在创建的时候,需要实现四个部分:

    1、定义一个名字叫HMI 或HAL_MODULE_INFO_SYM 的模块数据结构,开头必须是hw_module_t

    2、定义hw_module_methods_t 的结构体,实现open

    3、定义一个设备的数据结构,里面可以设备自身相关的数据成员,但开头必须是hw_device_t

    4、设备自身的成员的处理

     

    hardware.c

    主要目的就是通过函数hw_get_module、hw_get_module_by_class 找到对应的模组

    1、hw_get_module

    int hw_get_module(const char *id, const struct hw_module_t **module)
    {
        return hw_get_module_by_class(id, NULL, module);
    }
    

    可以看到hw_get_module 和hw_get_module_by_class 的根本区别第二个参数是否为NULL

     

    在说明hardware.h 的时候说明过,HAL 首先要定义一个数据结构,这个数据结构开头必须是hw_module_t,也就是说hw_module_t 可能是共同的,但是模块自身的数据结构实现的接口可能不同。例如audio 就分primary、a2dp,这两个模组的数据结构开头hw_module_t 可以是相同的。

    因此,hw_get_module_by_class 的第一个参数是hw_module_t 的id,第二个参数是区分模组。

    2、hw_get_module_by_class

    int hw_get_module_by_class(const char *class_id, const char *inst,
                               const struct hw_module_t **module)
    {
        int i = 0;
        char prop[PATH_MAX] = {0};
        char path[PATH_MAX] = {0};
        char name[PATH_MAX] = {0};
        char prop_name[PATH_MAX] = {0};
    
    
        if (inst)
            snprintf(name, PATH_MAX, "%s.%s", class_id, inst);
        else
            strlcpy(name, class_id, PATH_MAX);
    
        /*
         * Here we rely on the fact that calling dlopen multiple times on
         * the same .so will simply increment a refcount (and not load
         * a new copy of the library).
         * We also assume that dlopen() is thread-safe.
         */
    
        /* First try a property specific to the class and possibly instance */
        snprintf(prop_name, sizeof(prop_name), "ro.hardware.%s", name);
        if (property_get(prop_name, prop, NULL) > 0) {
            if (hw_module_exists(path, sizeof(path), name, prop) == 0) {
                goto found;
            }
        }
    
        /* Loop through the configuration variants looking for a module */
        for (i=0 ; i<HAL_VARIANT_KEYS_COUNT; i++) {
            if (property_get(variant_keys[i], prop, NULL) == 0) {
                continue;
            }
            if (hw_module_exists(path, sizeof(path), name, prop) == 0) {
                goto found;
            }
        }
    
        /* Nothing found, try the default */
        if (hw_module_exists(path, sizeof(path), name, "default") == 0) {
            goto found;
        }
    
        return -ENOENT;
    
    found:
        /* load the module, if this fails, we're doomed, and we should not try
         * to load a different variant. */
        return load(class_id, path, module);
    }

    1)首先确定模组的全名name

    class_id.inst 组成的,如果inst 是NULL 模组的全名就是id

    2) 根据name 找到这个so 是否存在,如果存在调用load

    从这里看出来,HAL 的so 命名是有规定的

    a、ro.hardware.name 已经定义好的,这里的name 就是1)中说的全名

    如果定义了,so 的名字应该是name.prop.so

    b、ro.hardware 或 ro.produce.board 或 ro.board.platform 或 ro.arch 中定义了prop

    组合后so 的名字是name.prop.so

    c、如果没有这样的prop定义,那so 的名字是name.default.so

    例如目前我们平台的hdmi cec 的so 就是来源ro.hardware 中的prop

     

    3、load

    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;
    
        /*
         * load the symbols resolving undefined symbols before
         * dlopen returns. Since RTLD_GLOBAL is not or'd in with
         * RTLD_NOW the external symbols will not be global
         */
        handle = dlopen(path, RTLD_NOW);
        if (handle == NULL) {
            char const *err_str = dlerror();
            ALOGE("load: module=%s\n%s", path, err_str?err_str:"unknown");
            status = -EINVAL;
            goto done;
        }
    
        /* 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);
        if (hmi == NULL) {
            ALOGE("load: couldn't find symbol %s", sym);
            status = -EINVAL;
            goto done;
        }
    
        /* 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;
        }
    
        hmi->dso = handle;
    
        /* success */
        status = 0;
    
        done:
        if (status != 0) {
            hmi = NULL;
            if (handle != NULL) {
                dlclose(handle);
                handle = NULL;
            }
        } else {
            ALOGV("loaded HAL id=%s path=%s hmi=%p handle=%p",
                    id, path, *pHmi, handle);
        }
    
        *pHmi = hmi;
    
        return status;
    }

    1)dlopen 对应path 的so

    2)dlsym 获取HMI 的地址

    至此,hardware 相关的部分就讲解完。

     

    总结:

    1、获取module 方式有两种

    hw_get_module_by_class、hw_get_module

    前者是针对公用module 的模块,后者是单个的,当然用前者找单个的module 也是可以的,第二个参数传NULL 即可

    注意最后一个参数是hw_module_t **module

    2、通过1 中获取到module 数据结构指针变量在内存中地址

    3、根据2 中的module 就可以调用module 中open 初始化硬件设备,最终获得hw_device_t

    4、根据3 中的device 实现真正的调用,实现与内核的通信

     

     

     

     

     

     

     

     

     

     

     

    展开全文
  • Hardware

    2017-07-23 14:28:40
    Ola Clason’s Hardware store is an old company where most work is done “the old way”. Among other things, the company is the one and only provider of marble house numbers. These house numbers have ...
  • hardware

    2015-05-19 20:50:55
    资源页
    资源页
    
    展开全文
  • Hardware Acceleration

    千次阅读 2013-04-26 15:26:25
    Hardware Acceleration IN THIS DOCUMENT Controlling Hardware AccelerationDetermining if a View is Hardware AcceleratedAndroid Drawing Models Software-based drawing modelHardware accele

    Hardware Acceleration

    Beginning in Android 3.0 (API level 11), the Android 2D rendering pipeline is designed to better support hardware acceleration. Hardware acceleration carries out all drawing operations that are performed on a View's canvas using the GPU. Because of the increased resources required to enable hardware acceleration, your app will consume more RAM.

    The easiest way to enable hardware acceleration is to turn it on globally for your entire application. If your application uses only standard views and Drawables, turning it on globally should not cause any adverse drawing effects. However, because hardware acceleration is not supported for all of the 2D drawing operations, turning it on might affect some of your applications that use custom views or drawing calls. Problems usually manifest themselves as invisible elements, exceptions, or wrongly rendered pixels. To remedy this, Android gives you the option to enable or disable hardware acceleration at the following levels:

    • Application
    • Activity
    • Window
    • View

    If your application performs custom drawing, test your application on actual hardware devices with hardware acceleration turned on to find any problems. The Unsupported drawing operations section describes known issues with drawing operations that cannot be hardware accelerated and how to work around them.

    Controlling Hardware Acceleration


    You can control hardware acceleration at the following levels:

    • Application
    • Activity
    • Window
    • View

    Application level

    In your Android manifest file, add the following attribute to the <application> tag to enable hardware acceleration for your entire application:

    <application android:hardwareAccelerated="true" ...>

    Activity level

    If your application does not behave properly with hardware acceleration turned on globally, you can control it for individual activities as well. To enable or disable hardware acceleration at the activity level, you can use theandroid:hardwareAccelerated attribute for the <activity> element. The following example enables hardware acceleration for the entire application but disables it for one activity:

    <application android:hardwareAccelerated="true">
        <activity ... />
        <activity android:hardwareAccelerated="false" />
    </application>

    Window level

    If you need even more fine-grained control, you can enable hardware acceleration for a given window with the following code:

    getWindow().setFlags(
        WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED,
        WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED);
    

    Note: You currently cannot disable hardware acceleration at the window level.

    View level

    You can disable hardware acceleration for an individual view at runtime with the following code:

    myView.setLayerType(View.LAYER_TYPE_SOFTWARE, null);

    Note: You currently cannot enable hardware acceleration at the view level. View layers have other functions besides disabling hardware acceleration. See View layers for more information about their uses.

    Determining if a View is Hardware Accelerated


    It is sometimes useful for an application to know whether it is currently hardware accelerated, especially for things such as custom views. This is particularly useful if your application does a lot of custom drawing and not all operations are properly supported by the new rendering pipeline.

    There are two different ways to check whether the application is hardware accelerated:

    If you must do this check in your drawing code, use Canvas.isHardwareAccelerated() instead ofView.isHardwareAccelerated() when possible. When a view is attached to a hardware accelerated window, it can still be drawn using a non-hardware accelerated Canvas. This happens, for instance, when drawing a view into a bitmap for caching purposes.

    Android Drawing Models


    When hardware acceleration is enabled, the Android framework utilizes a new drawing model that utilizesdisplay lists to render your application to the screen. To fully understand display lists and how they might affect your application, it is useful to understand how Android draws views without hardware acceleration as well. The following sections describe the software-based and hardware-accelerated drawing models.

    Software-based drawing model

    In the software drawing model, views are drawn with the following two steps:

    1. Invalidate the hierarchy
    2. Draw the hierarchy

    Whenever an application needs to update a part of its UI, it invokes invalidate() (or one of its variants) on any view that has changed content. The invalidation messages are propagated all the way up the view hierarchy to compute the regions of the screen that need to be redrawn (the dirty region). The Android system then draws any view in the hierarchy that intersects with the dirty region. Unfortunately, there are two drawbacks to this drawing model:

    • First, this model requires execution of a lot of code on every draw pass. For example, if your application callsinvalidate() on a button and that button sits on top of another view, the Android system redraws the view even though it hasn't changed.
    • The second issue is that the drawing model can hide bugs in your application. Since the Android system redraws views when they intersect the dirty region, a view whose content you changed might be redrawn even though invalidate() was not called on it. When this happens, you are relying on another view being invalidated to obtain the proper behavior. This behavior can change every time you modify your application. Because of this, you should always call invalidate() on your custom views whenever you modify data or state that affects the view’s drawing code.

    Note: Android views automatically call invalidate() when their properties change, such as the background color or the text in a TextView.

    Hardware accelerated drawing model

    The Android system still uses invalidate() and draw() to request screen updates and to render views, but handles the actual drawing differently. Instead of executing the drawing commands immediately, the Android system records them inside display lists, which contain the output of the view hierarchy’s drawing code. Another optimization is that the Android system only needs to record and update display lists for views marked dirty by an invalidate() call. Views that have not been invalidated can be redrawn simply by re-issuing the previously recorded display list. The new drawing model contains three stages:

    1. Invalidate the hierarchy
    2. Record and update display lists
    3. Draw the display lists

    With this model, you cannot rely on a view intersecting the dirty region to have its draw() method executed. To ensure that the Android system records a view’s display list, you must call invalidate(). Forgetting to do so causes a view to look the same even after changing it, which is an easier bug to find if it happens.

    Using display lists also benefits animation performance because setting specific properties, such as alpha or rotation, does not require invalidating the targeted view (it is done automatically). This optimization also applies to views with display lists (any view when your application is hardware accelerated.) For example, assume there is a LinearLayout that contains a ListView above a Button. The display list for the LinearLayoutlooks like this:

    • DrawDisplayList(ListView)
    • DrawDisplayList(Button)

    Assume now that you want to change the ListView's opacity. After invoking setAlpha(0.5f) on the ListView, the display list now contains this:

    • SaveLayerAlpha(0.5)
    • DrawDisplayList(ListView)
    • Restore
    • DrawDisplayList(Button)

    The complex drawing code of ListView was not executed. Instead, the system only updated the display list of the much simpler LinearLayout. In an application without hardware acceleration enabled, the drawing code of both the list and its parent are executed again.

    Unsupported Drawing Operations


    When hardware accelerated, the 2D rendering pipeline supports the most commonly used Canvas drawing operations as well as many less-used operations. All of the drawing operations that are used to render applications that ship with Android, default widgets and layouts, and common advanced visual effects such as reflections and tiled textures are supported. The following list describes known operations that are not supported with hardware acceleration:

    In addition, some operations behave differently with hardware acceleration enabled:

    If your application is affected by any of these missing features or limitations, you can turn off hardware acceleration for just the affected portion of your application by callingsetLayerType(View.LAYER_TYPE_SOFTWARE, null). This way, you can still take advantage of hardware acceleratin everywhere else. See Controlling Hardware Acceleration for more information on how to enable and disable hardware acceleration at different levels in your application.

    View Layers


    In all versions of Android, views have had the ability to render into off-screen buffers, either by using a view's drawing cache, or by using Canvas.saveLayer(). Off-screen buffers, or layers, have several uses. You can use them to get better performance when animating complex views or to apply composition effects. For instance, you can implement fade effects using Canvas.saveLayer() to temporarily render a view into a layer and then composite it back on screen with an opacity factor.

    Beginning in Android 3.0 (API level 11), you have more control on how and when to use layers with theView.setLayerType() method. This API takes two parameters: the type of layer you want to use and an optionalPaint object that describes how the layer should be composited. You can use the Paint parameter to apply color filters, special blending modes, or opacity to a layer. A view can use one of three layer types:

    • LAYER_TYPE_NONE: The view is rendered normally and is not backed by an off-screen buffer. This is the default behavior.
    • LAYER_TYPE_HARDWARE: The view is rendered in hardware into a hardware texture if the application is hardware accelerated. If the application is not hardware accelerated, this layer type behaves the same asLAYER_TYPE_SOFTWARE.
    • LAYER_TYPE_SOFTWARE: The view is rendered in software into a bitmap.

    The type of layer you use depends on your goal:

    • Performance: Use a hardware layer type to render a view into a hardware texture. Once a view is rendered into a layer, its drawing code does not have to be executed until the view calls invalidate(). Some animations, such as alpha animations, can then be applied directly onto the layer, which is very efficient for the GPU to do.
    • Visual effects: Use a hardware or software layer type and a Paint to apply special visual treatments to a view. For instance, you can draw a view in black and white using a ColorMatrixColorFilter.
    • Compatibility: Use a software layer type to force a view to be rendered in software. If a view that is hardware accelerated (for instance, if your whole application is hardware acclerated), is having rendering problems, this is an easy way to work around limitations of the hardware rendering pipeline.

    View layers and animations

    Hardware layers can deliver faster and smoother animations when your application is hardware accelerated. Running an animation at 60 frames per second is not always possible when animating complex views that issue a lot of drawing operations. This can be alleviated by using hardware layers to render the view to a hardware texture. The hardware texture can then be used to animate the view, eliminating the need for the view to constantly redraw itself when it is being animated. The view is not redrawn unless you change the view's properties, which calls invalidate(), or if you call invalidate() manually. If you are running an animation in your application and do not obtain the smooth results you want, consider enabling hardware layers on your animated views.

    When a view is backed by a hardware layer, some of its properties are handled by the way the layer is composited on screen. Setting these properties will be efficient because they do not require the view to be invalidated and redrawn. The following list of properties affect the way the layer is composited. Calling the setter for any of these properties results in optimal invalidation and no redrawing of the targeted view:

    • alpha: Changes the layer's opacity
    • xytranslationXtranslationY: Changes the layer's position
    • scaleXscaleY: Changes the layer's size
    • rotationrotationXrotationY: Changes the layer's orientation in 3D space
    • pivotXpivotY: Changes the layer's transformations origin

    These properties are the names used when animating a view with an ObjectAnimator. If you want to access these properties, call the appropriate setter or getter. For instance, to modify the alpha property, call setAlpha(). The following code snippet shows the most efficient way to rotate a viewiew in 3D around the Y-axis:

    view.setLayerType(View.LAYER_TYPE_HARDWARE, null);
    ObjectAnimator.ofFloat(view, "rotationY", 180).start();

    Because hardware layers consume video memory, it is highly recommended that you enable them only for the duration of the animation and then disable them after the animation is done. You can accomplish this using animation listeners:

    View.setLayerType(View.LAYER_TYPE_HARDWARE, null);
    ObjectAnimator animator = ObjectAnimator.ofFloat(view, "rotationY", 180);
    animator.addListener(new AnimatorListenerAdapter() {
        @Override
        public void onAnimationEnd(Animator animation) {
            view.setLayerType(View.LAYER_TYPE_NONE, null);
        }
    });
    animator.start();

    For more information on property animation, see Property Animation.

    Tips and Tricks


    Switching to hardware accelerated 2D graphics can instantly increase performance, but you should still design your application to use the GPU effectively by following these recommendations:

    Reduce the number of views in your application
    The more views the system has to draw, the slower it will be. This applies to the software rendering pipeline as well. Reducing views is one of the easiest ways to optimize your UI.
    Avoid overdraw
    Do not draw too many layers on top of each other. Remove any views that are completely obscured by other opaque views on top of it. If you need to draw several layers blended on top of each other, consider merging them into a single layer. A good rule of thumb with current hardware is to not draw more than 2.5 times the number of pixels on screen per frame (transparent pixels in a bitmap count!).
    Don't create render objects in draw methods
    A common mistake is to create a new Paint or a new Path every time a rendering method is invoked. This forces the garbage collector to run more often and also bypasses caches and optimizations in the hardware pipeline.
    Don't modify shapes too often
    Complex shapes, paths, and circles for instance, are rendered using texture masks. Every time you create or modify a path, the hardware pipeline creates a new mask, which can be expensive.
    Don't modify bitmaps too often
    Every time you change the content of a bitmap, it is uploaded again as a GPU texture the next time you draw it.
    Use alpha with care
    When you make a view translucent using setAlpha()AlphaAnimation, or ObjectAnimator, it is rendered in an off-screen buffer which doubles the required fill-rate. When applying alpha on very large views, consider setting the view's layer type to LAYER_TYPE_HARDWARE.
    展开全文
  • // android 源代码里 cat hardware/libhardware/include/hardware/hardware.h /* * Copyright (C) 2008 The Android Open Source Project * * Licensed under the Apache License, Version 2.0 (the
    // android 源代码里 cat hardware/libhardware/include/hardware/hardware.h
        /*
         * Copyright (C) 2008 The Android Open Source Project
         *
         * Licensed under the Apache License, Version 2.0 (the "License");
         * you may not use this file except in compliance with the License.
         * You may obtain a copy of the License at
         *
         *      http://www.apache.org/licenses/LICENSE-2.0
         *
         * Unless required by applicable law or agreed to in writing, software
         * distributed under the License is distributed on an "AS IS" BASIS,
         * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
         * See the License for the specific language governing permissions and
         * limitations under the License.
         */
        
        #ifndef ANDROID_INCLUDE_HARDWARE_HARDWARE_H
        #define ANDROID_INCLUDE_HARDWARE_HARDWARE_H
        
        #include <stdint.h>
        #include <sys/cdefs.h>
        
        #include <cutils/native_handle.h>
        #include <system/graphics.h>
        
        __BEGIN_DECLS
        
        /*
         * Value for the hw_module_t.tag field
         * 这里提供字符合成方式
         */
        #define MAKE_TAG_CONSTANT(A,B,C,D) (((A) << 24) | ((B) << 16) | ((C) << 8) | (D))
        
        /**
         * 需要合成的module、device的tag
         */
        #define HARDWARE_MODULE_TAG MAKE_TAG_CONSTANT(‘H‘, ‘W‘, ‘M‘, ‘T‘)
        #define HARDWARE_DEVICE_TAG MAKE_TAG_CONSTANT(‘H‘, ‘W‘, ‘D‘, ‘T‘)
        
        /**
         * 提供硬件api版本合成方法
         */
        #define HARDWARE_MAKE_API_VERSION(maj,min) \
                    ((((maj) & 0xff) << 8) | ((min) & 0xff))
        
        #define HARDWARE_MAKE_API_VERSION_2(maj,min,hdr) \
                    ((((maj) & 0xff) << 24) | (((min) & 0xff) << 16) | ((hdr) & 0xffff))
        #define HARDWARE_API_VERSION_2_MAJ_MIN_MASK 0xffff0000
        #define HARDWARE_API_VERSION_2_HEADER_MASK  0x0000ffff
        
        /*
         * The current HAL API version.   -->  当前的硬件api版本 1.0
         *
         * All module implementations must set the hw_module_t.hal_api_version field
         * to this value when declaring the module with HAL_MODULE_INFO_SYM.
         *
         * Note that previous implementations have always set this field to 0.
         * Therefore, libhardware HAL API will always consider versions 0.0 and 1.0
         * to be 100% binary compatible.
         *
         * 设置当前版本为1.0
         */
        #define HARDWARE_HAL_API_VERSION HARDWARE_MAKE_API_VERSION(1, 0)
        
        /*
         * Helper macros for module implementors.  -->  提供的版本生成宏
         *
         * The derived modules should provide convenience macros for supported
         * versions so that implementations can explicitly specify module/device
         * versions at definition time.
         *
         * Use this macro to set the hw_module_t.module_api_version field.
         */
        #define HARDWARE_MODULE_API_VERSION(maj,min) HARDWARE_MAKE_API_VERSION(maj,min)
        #define HARDWARE_MODULE_API_VERSION_2(maj,min,hdr) HARDWARE_MAKE_API_VERSION_2(maj,min,hdr)
        
        /*
         * Use this macro to set the hw_device_t.version field
         */
        #define HARDWARE_DEVICE_API_VERSION(maj,min) HARDWARE_MAKE_API_VERSION(maj,min)
        #define HARDWARE_DEVICE_API_VERSION_2(maj,min,hdr) HARDWARE_MAKE_API_VERSION_2(maj,min,hdr)
        
        struct hw_module_t;
        struct hw_module_methods_t;
        struct hw_device_t;
        
        /**
         * 每一个硬件模块都一个HAL_MODULE_INFO_SYM结构体
         * 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 */
            /** 这个tag的值必须初始化为 HARDWARE_MODULE_TAG */
            uint32_t tag;
        
            /**
             * 对于模块实现的版本,模块开发者有责任更新版本
             * The API version of the implemented module. The module owner is
             * responsible for updating the version when a module interface has
             * changed.
             *
             * The derived modules such as gralloc and audio own and manage this field.
             * The module user must interpret the version field to decide whether or
             * not to inter-operate with the supplied module implementation.
             * For example, SurfaceFlinger is responsible for making sure that
             * it knows how to manage different versions of the gralloc-module API,
             * and AudioFlinger must know how to do the same for audio-module API.
             *
             * The module API version should include a major and a minor component.
             * For example, version 1.0 could be represented as 0x0100. This format
             * implies that versions 0x0100-0x01ff are all API-compatible.
             *
             * In the future, libhardware will expose a hw_get_module_version()
             * (or equivalent) function that will take minimum/maximum supported
             * versions as arguments and would be able to reject modules with
             * versions outside of the supplied range.
             */
            uint16_t module_api_version;
        #define version_major module_api_version
            /**
             * version_major/version_minor defines are supplied here for temporary
             * source code compatibility. They will be removed in the next version.
             * ALL clients must convert to the new version format.
             */
        
            /**
             * The API version of the HAL module interface. This is meant to
             * version the hw_module_t, hw_module_methods_t, and hw_device_t
             * structures and definitions.
             *
             * The HAL interface owns this field. Module users/implementations
             * must NOT rely on this value for version information.
             *
             * Presently, 0 is the only valid value.
             */
            uint16_t hal_api_version;
        #define version_minor hal_api_version
        
            /** Identifier of module */
            /** 模块的标识符,独一无二的,用于区分各个模块,也用于获取模块 */
            const char *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;
        
        typedef struct hw_module_methods_t {
            /** Open a specific device */
            /** 目前唯一的方法,打开一个设备的方法 */
            int (*open)(const struct hw_module_t* module, const char* id,
                    struct hw_device_t** device);
        
        } hw_module_methods_t;
        
        /**
         * Every device data structure must begin with hw_device_t
         * followed by module specific public methods and attributes.
         */
        typedef struct hw_device_t {
            /** tag must be initialized to HARDWARE_DEVICE_TAG */
            uint32_t tag;
        
            /**
             * Version of the module-specific device API. This value is used by
             * the derived-module user to manage different device implementations.
             *
             * The module user is responsible for checking the module_api_version
             * and device version fields to ensure that the user is capable of
             * communicating with the specific module implementation.
             *
             * One module can support multiple devices with different versions. This
             * can be useful when a device interface changes in an incompatible way
             * but it is still necessary to support older implementations at the same
             * time. One such example is the Camera 2.0 API.
             *
             * This field is interpreted by the module user and is ignored by the
             * HAL interface itself.
             */
            uint32_t version;
        
            /** reference to the module this device belongs to */
            /** 指向设备所属的硬件模块 */
            struct hw_module_t* module;
        
            /** padding reserved for future use */
            uint32_t reserved[12];
        
            /** Close this device */
            /** 关闭设备的方法 */
            int (*close)(struct hw_device_t* device);
        
        } hw_device_t;
        
        /**
         * Name of the hal_module_info
         */
        #define HAL_MODULE_INFO_SYM         HMI
        
        /**
         * Name of the hal_module_info as a string
         */
        #define HAL_MODULE_INFO_SYM_AS_STR  "HMI"
        
        /**
         * 通过id获取模块
         * Get the module info associated with a module by id.
         *
         * @return: 0 == success, <0 == error and *module == NULL
         */
        // jni中通过这个来获取底层的模块
        int hw_get_module(const char *id, const struct hw_module_t **module);  
        
        /**
         * Get the module info associated with a module instance by class ‘class_id‘
         * and instance ‘inst‘.
         *
         * Some modules types necessitate multiple instances. For example audio supports
         * multiple concurrent interfaces and thus ‘audio‘ is the module class
         * and ‘primary‘ or ‘a2dp‘ are module interfaces. This implies that the files
         * providing these modules would be named audio.primary.<variant>.so and
         * audio.a2dp.<variant>.so
         *
         * @return: 0 == success, <0 == error and *module == NULL
         */
        int hw_get_module_by_class(const char *class_id, const char *inst,
                                   const struct hw_module_t **module);
        
        __END_DECLS
        
        #endif  /* ANDROID_INCLUDE_HARDWARE_HARDWARE_H */
    展开全文
  • 不管是出于什么样地考虑,android系统终究是提供了hardware层来封装了对Linux的驱动的访问,同时为上层提供了一个统一的硬件接口和硬件形态。一.Hardware概述在Hardware层中的一个模块中,主要设计一下三个结构: ...
  • Vivado Hardware Manager的使用

    千次阅读 2016-10-22 22:32:23
    Hardware Manager是集成在VIVADO中的片上调试工具,功能类似于ISE套件中的Chipscope,但功能更加强大,且使用更加方便。Hardware Manager不仅能够管理本机或者远程连接的FPGA资源,将生成的bit文件下载,而且也可以...
  • 从Android3.0(API Level 11)开始,Android 2D渲染管道能够更好的支持硬件加速。硬件加速执行的所有的绘图操作都是使用GPU在View对象的画布上来进行的。因为启用硬件加速会增加资源的需求,因此这样的应用会占用更...
  • android hardware解析

    千次阅读 2014-09-23 09:54:30
    HAL层的hardware module主要实现文件为: hardware/libhardware/hareware.c hardware/libhardware/include/hardware/hardware.h Hareware.c中的内容在此就不做解释,可自行学习。 hardware.c中三个重要的...
  • android.hardware.camera2详解

    万次阅读 热门讨论 2020-06-11 21:35:35
    看到有些读者对博客提出的疑问,在此真诚说一句实在抱歉,本人是一名在校非科班出身大学生... 前言:原有的android.hardware.camera已经被google废除,改用功能更强大的camera2,camera2的复杂度远远超过camera,所以写
  • Android中hardware源码(android-5.0.2) 路径:android-5.0.2/hardware/libhardware/include/hardware/hardware.h hardware.h /* * Copyright (C) 2008 The Android Open Source Project * * Licensed
  • https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux_Hardware_Certification/1/html-single/Program_Policy_Guide/index.html Red Hat Enterprise Linux Hardware Certification ...
  • hardwareAccelerated 硬件加速详解

    千次阅读 2016-02-17 09:57:56
    从Android3.0(API Level 11)开始,Android 2D渲染管道能够更好的支持硬件加速。硬件加速执行的所有的绘图操作都是使用GPU在View对象的画布上来进行的。因为启用硬件加速会增加资源的需求,因此这样的应用会占用更...
  • ro.hardware 由来

    千次阅读 2016-04-06 11:52:18
    关于这个ro.hardware 这个东西是怎么来的?
  • 从Android3.0(API Level 11)开始支持硬件加速,在Target API >= 14时是默认开启的。可充分利用GPU的特性,使得界面渲染更加平滑,但是会消耗更多内存RAM。硬件加速自身并非完美,在某些Android 5的rom上,由于内存...
  • Android优化之Hardware Layer

    千次阅读 2017-08-21 14:05:13
    项目中越来越多的动画,越来越多的效果导致了应用性能越来越低。该如何提升。 简介在View播放动画的过程中每一帧都需要被重绘。...通过hardware layers可以快速的渲染一些简单的转变(位移、选中、缩放
  • android-android.hardware.Camera

    万次阅读 2016-06-28 14:24:32
    Camera public class Camera  extends Object  java.lang.Object ...android.hardware.Camera This class was deprecated in API level 21. We recommend using the new
  • http://developer.android.com/guide/topics/graphics/hardware-accel.html 工作太忙没时间翻译,贴出来方便不能翻墙的同学查阅 See also OpenGL with the Framework APIsRenderscript Beginning ...
  • kernel: [946277.337433] {5}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 4
1 2 3 4 5 ... 20
收藏数 184,313
精华内容 73,725
关键字:

hardware