嵌入式Android系统增加新硬件支持

Posted 2023-04-08 十六宿舍

根据Statcounter显示，截至2021年4月全球移动操作系统中 ，谷歌 android占比高达72.2% ， 苹果ios占比26.99% ，其余移动操作系统占比之和低于1%。 包含桌面操作系统在内的全球操作系统占比中 ， Android以40.66% 位列第一位， Windows 位列第二， 占比31.97% 。如此庞大的用户量，使得芯片厂商以及软件开发人员都不能无视它。

虽然早期的大多数嵌入式系统设备很少甚至没有用户界面，但还是有很多传统“嵌入式”设备确实是有用户界面的。现如今更多的嵌入式设备除了有纯粹的功能需求外，开发者还要为用户操作提供人机交互界面。所以，设计人员要么为用户提供一种其熟悉的界面体验，要么冒险为用户提供一种不熟悉甚至是全新的界面风格，再加上原先很多属于Java等语言开发的大型软件业务逻辑下移至嵌入式设备的需求。这么看来，在我们的板卡上运行Android系统，往往是一个不错的选择。🎭

如果您是基于安卓系统的应用开发，您不仅可以通过官方的渠道找到非常详细的指导文档，还有非常多书籍和博文，但是任何希望多Android框架开展工作的开发人员，不管是嵌入式系统移植还是修改Android框架的工程师，都会发现根本没有任何文档来阐述应该如何开展工作，官方AOSP（Android Open Source Project）网站的东西大部分都是说明性质，而且在很多情况下，你的嵌入式系统会包含Android所不支持的设备，增加对新类型硬件的支持是一件很棘手的事情，下面的博客内容会通过对姜饼系统的修改，增加一个具有"存储"功能的硬件支持,帮助我们理解Android框架各层之间的复杂关系。🐣

基础知识

Android系统跟“纯洁的Linux”相比，它需要的不仅仅是恰当的驱动程序来使得硬件能够正常工作。通常来说，每个Android支持的硬件类型都有一个系统服务和HAL定义。比如说，GPIO驱动LED等的亮灭，就有一个灯光服务和灯光HAL的定义，这样基于安卓的应用就可以通过系统提供的灯光服务来控制LED灯。

本博文讲述的例子来源于《构建嵌入式Android系统》这本书籍，但显然这仅仅是一个简单的架构程序，注释为了帮你在增加新的硬件类型方面给予你些许灵感，你的硬件很可能具有完全不一样的接口，你的系统版本也提升了很多了。[1]

系统服务

我们首先在frameworks/base/services/java/com/android/server/目录下增加OpersysService.java，这个文件实现了OpersysServic类，提供了构造函数以及给上层的基本调用：

public OpersysService(Context context) 
    super();
    mContext = context;
    Log.i(TAG, "Opersys Service started");
    mNativePointer = init_native();  
    Log.i(TAG, "test() returns " + test_native(mNativePointer, 20));

public String read(int maxLength)

    int length;
    byte[] buffer = new byte[maxLength];
    length = read_native(mNativePointer, buffer);
    return new String(buffer, 0, length);

重要的工作是调用/write_native函数来完成的，它本身在OpersysServic类里的声明如下：

private static native int init_native();
private static native int read_native(int ptr, byte[] buffer);

该方法通过native关键字像编译器声明该函数不在任何Java代码中是实现，它需要Davik虚拟机运行时装载JNI的动态库文件。将这些本地方法的具体实现：com_android_server_OpersysService.cpp放到frameworks/base/services/jni目录下，并修改目录下的的Android.mk增加com_android_server_OpersysService.cpp为libandroid_servers.so动态库编译源文件，并在同目录下的onload.cpp中增加：

extern "C" jint JNI_OnLoad(JavaVM* vm, void* reserved)

    ...
    register_android_server_OpersysService(env);
    ...

方法在com_android_server_OpersysService.cpp的实现如下：

static JNINativeMethod method_table[] = 
     "init_native", "()I", (void*)init_native ,
     "finalize_native", "(I)V", (void*)finalize_native ,
     "read_native", "(I[B)I", (void*)read_native ,
     "write_native", "(I[B)I", (void*)write_native ,
     "test_native", "(II)I", (void*)test_native,
;

int register_android_server_OpersysService(JNIEnv *env)

    return jniRegisterNativeMethods(env, "com/android/server/OpersysService",
            method_table, NELEM(method_table));
;

上面的结构体包含了三个域，第一个域是Java类中定义的函数名称，最后一个域是它对应的C语言实现的函数名。中间的参数括号里的字母是Java传递下来的参数类型描述，右括号后边的字母是返回值类型描述。例如init_native()函数不懈怠参数并返回一个整型值，而read_native()函数有两个参数，一个整型和一个字节数组，并且返回一个整型值。当你深入Android内部，你会经常跟这样的JNI打交道，建议你抽空系统的了解更多关于JNI使用的信息。

read_native()函数的实现如下：

static int read_native(JNIEnv *env, jobject clazz, int ptr, jbyteArray buffer)

    opersyshw_device_t* dev = (opersyshw_device_t*)ptr;
    jbyte* real_byte_array;
    int length;
    real_byte_array = env->GetByteArrayElements(buffer, NULL);

    if (dev == NULL) 
        return 0;
    
    length = dev->read((char*) real_byte_array, env->GetArrayLength(buffer));
    env->ReleaseByteArrayElements(buffer, real_byte_array, 0);
    return length;

JNI调用函数的前两个隐藏入参一个叫做env的虚拟机句柄以及一个名为clazz的指向this对象的指针。在编写的时候千万不要忘记JNI函数是在C语言的世界里操作Java类型的对象，像是上面就需要使用env->GetByteArrayElements()来获得在C代码中可以使用的数组。

可以看出，其方法中实际的读取操作是通过dev->read来实现的，这个函数指针指向了哪里呢？我们需要看一下init_native()的实现：

static jint init_native(JNIEnv *env, jobject clazz)

    int err;
    hw_module_t* module;
    opersyshw_device_t* dev = NULL;  
    err = hw_get_module(OPERSYSHW_HARDWARE_MODULE_ID, (hw_module_t const**)&module);
    if (err == 0) 
        if (module->methods->open(module, "", ((hw_device_t**) &dev)) != 0)
       return 0;
    
    return (jint)dev;

这个函数做了两件重要的事情。首先，调用hw_get_module()函数请求HAL装载支持OPERSYSHW_HARDWARE_MODULE_ID类型的硬件模块。然后，调用模块的open()函数。我们会在后边的章节再看这两个函数。但是需要在这里注意的是，第一个动作导致了驱动.so文件被加载到系统服务的地址空间，第二个动作使得那个库文件中的硬件相关函数，例如read()和write()被com_android_server_OpersysService.cpp调用，本质上也就是C实现的系统服务被增加到了系统中。

HAL模块管理

Hardware/目录下的HAL提供了前面提到的hw_get_module()函数。如果你进一步阅读代码，你会看到hw_get_module()函数是以经典的dlopen()来实现的，dlopen()函数的功能就是装载一个动态库到进程空间。[2]

HAL当然不仅仅装载一个动态库而已。当你请求一个特定硬件类型的时候，它会检查/system/lib/hw目录查找匹配的文件名。文件名由硬件类型和运行的设备决定，如我们现在在模拟器上实现的这个新的硬件类型，HAL会找一个叫做opersyshw.goldfish.so的文件，goldfish是我们模拟器的代码。动态库必须包含一个提供HAL硬件信息的结构体，结构体要命名HAL_MODULE_INFO_SYM_AS_STR。在下一个章节我们会看到一个例子。

对于一个新硬件类型本身的定义是放在hardware/libhardware/include/hardware/目录下的头文件，针对本例中即为opersyshw.h。

#ifndef ANDROID_OPERSYSHW_INTERFACE_H
#define ANDROID_OPERSYSHW_INTERFACE_H
#include <stdint.h>
#include <sys/cdefs.h>
#include <sys/types.h>
#include <hardware/hardware.h>

__BEGIN_DECLS
#define OPERSYSHW_HARDWARE_MODULE_ID "opersyshw"
struct opersyshw_device_t 
    struct hw_device_t common;

    int (*read)(char* buffer, int length);
    int (*write)(char* buffer, int length);
    int (*test)(int value);
;
__END_DECLS

#endif // ANDROID_OPERSYSHW_INTERFACE_H

这个文件除了定义了read和write原型之外，还定义了OPERSYSHW_HARDWARE_MODULE_ID，这个ID成为了在文件系统中查找HAL模块文件名的基础。

HAL模块

Android的思想是每个设备都需要一个相应的HAL模块来抽象特性的硬件类型。例如不同的硬件厂商的手机会使用不同的图形芯片，因此也就有不同的gralloc模块。通常来说，添加到AOSP源的HAL模块在device/<vendor>/<product>的lib*目录里，我们模拟器则放在sdk/emulator/目录下。我们的硬件驱动：opersyshw_qemu.c（环形缓冲驱动程序）就放在这个目录下。

为了这个文件产生的库文件可以被HAL管理识别，它需要以下面这样的代码段结尾：

static struct hw_module_methods_t opersyshw_module_methods = 
    .open = open_opersyshw
;

const struct hw_module_t HAL_MODULE_INFO_SYM = 
    .tag = HARDWARE_MODULE_TAG,
    .version_major = 1,
    .version_minor = 0,
    .id = OPERSYSHW_HARDWARE_MODULE_ID,
    .name = "Opersys HW Module",
    .author = "Opersys inc.",
    .methods = &opersyshw_module_methods,
;

由上面代码可得HAL_MODULE_INFO_SYM结构体和opersyshw_module_methods及其包含的open()函数指针。还记得前文提到的“调用模块的open函数"吗？指针经过传递最终调用open_opersyshw()。

static int open_opersyshw(const struct hw_module_t* module, char const* name,
        struct hw_device_t** device)

    struct opersyshw_device_t *dev = malloc(sizeof(struct opersyshw_device_t));
    memset(dev, 0, sizeof(*dev));

    dev->common.tag = HARDWARE_DEVICE_TAG;
    dev->common.version = 0;
    dev->common.module = (struct hw_module_t*)module;
    dev->read = opersyshw__read;
    dev->write = opersyshw__write;
    dev->test = opersyshw__test;
    *device = (struct hw_device_t*) dev;
    fd = open("/dev/circchar", O_RDWR);
    D("OPERSYS HW has been initialized");
    return 0;

这个函数主要将对设备的操作函数挂接到了device结构体，该结构体的类型就是opersyshw.h文件中定义的opersyshw_device_t,然后打开了/dev目录下的设备节点，建立了驱动程序与系统服务之间的连接。

最后，我们看一下opersyshw__read函数：

int opersyshw__read(char* buffer, int length)

    int retval;
    D("OPERSYS HW - read()for %d bytes called", length);
    retval = read(fd, buffer, length);    
    return retval;

这里我们没有做错误检测和处理，但这是你的驱动应该需要做的。现在，从系统服务为起点的调用的路径已经很清晰了。系统服务的read导致对JNI函数read_native()的调用，通过HAL,调用到了HAL模块中的opersyshw_read()。

调用系统服务

系统服务通过binder被其他系统和应用所调用，至少需要一个接口定义，我们依然以opersys服务为例，增加IOpersysService.aidl到frameworks/base/core/java/android/os中：

package android.os;
interface IOpersysService 
/**
* @hide
*/
String read(int maxLength);
int write(String mString);

这个修改使得ASOP中编译的代码可以调用到我们的系统服务。例如，我们可以在packages/apps目录下增加一个app，并在其onCreat()回调函数中这么做：

public void onCreate(Bundle savedInstanceState) 
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);
        
        IOpersysService om = IOpersysService.Stub.asInterface(ServiceManager.getService("opersys"));
        try 
            Log.d(DTAG, "Going to write to the \\"opersys\\" service");
            om.write("Hello Opersys");
            Log.d(DTAG, "Service returned: " + om.read(20));
        
        catch (Exception e) 
            Log.d(DTAG, "FAILED to call service");
            e.printStackTrace();
        
    

我们这里使用了ServiceManager.getService()来得到Binder句柄，然后通过IOpersysService.Stub.asInterface()来把它转化成我们可以使用的IOpersysService对象，这对跟ASOP编译的app代码来说是可行的，但对于普通app来说就行不通了，因为ServiceManager.getService在SDK中是不存在的。

为了解决上边的问题，我们需要执行额外几个步骤来构建一个新的SDK。首先，我们需要创建一个manager类来进一步把binder可用服务包装起来，我们在frameworks/base/core/java/android/os目录中增加OpersysManager.java：

package android.os;
import android.os.IOpersysService;
public class OpersysManager

    public String read(int maxLength) 
    
        try 
                return mService.read(maxLength);
             catch (RemoteException e) 
                return null;
            
    
    public int write(String mString) 
    
    try 
            return mService.write(mString);
          catch (RemoteException e) 
                return 0;
         
    

    public OpersysManager(IOpersysService service) 
        mService = service;
    
    IOpersysService mService;

这里可以看到将IOpersysService用OpersysManager包了一层。接下来要使得这个manager能通过getSystemService()调用获得，还需要两个步骤要做。首先，需要修改frameworks/base/core/java/android/content/Context.java文件，将其增加到应用上下文环境中：

// ***** <ADDED-BY-OPERSYS> *****
    /**
     * Use with @link #getSystemService to retrieve a
     * @link android.os.OpersysManager for using Opersys Service.
     *
     * @see #getSystemService
     */
    public static final String OPERSYS_SERVICE = "opersys";
    // ***** </ADDED-BY-OPERSYS> *****

然后，我们需要修改frameworks/base/core/java/android/content/ContextImpl.java以使得getSystemService()函数能够识别这个新服务：

public Object getSystemService(String name)
    if(WINDOW_SERVICE.equals(name))
        return WindowManagerImpl.getDefault();
    else if(LAYOUT_INFLATER_SERVICE.equals(name))
        synchronized(mSync)
    ...
    else if(NFC_SERVICE.equals(name))
        return getNFCManager();

    else if(OPERSYS_SERVICE.equals(name))
        return getOpersysManager();
    ...

getSystemService类的实现在android不同版本之间差异较大，您可以参考一下ContextImpl类如何声明新的manager，理一下POWER_SERVICE是怎么利用getSystemService得到要用的PowerManager对象，就可以照葫芦画瓢了。

到此，我们就可以通过这个ASOP构建一个新的SDK，然后基于这个SDK编译的APP就可以像调用其他预定义服务一样调用这个新的系统服务：

public void onCreat(Bundle savedInstanceState)
    super.onCreate(savedInstanceState);
    setContentView(R.layout.main);
    
    OpersysManager om = (OpersysManager)getSystemService(OPERSYS_SERVICE);
    
    Log.d(DTAG, "Going to write to the \\"opersys\\" service");
    om.write("Hello Opersys");
    Log.d(DTAG, "Service returned: " + om.read(20));

结语

这个例子还有一点没有介绍，就是这个系统服务是怎么启动的。基于Java的系统服务是在frameworks/base/services/java/com/android/server/SystemServer.java中启动的。所以，我们修改这个文件来实例化我们的系统服务并向Service Manager注册：

...
 // ***** <ADDED-BY-OPERSYS> *****
        try 
                Slog.i(TAG, "Opersys Service");
                ServiceManager.addService(Context.OPERSYS_SERVICE, new OpersysService(context));
             catch (Throwable e) 
                Slog.e(TAG, "Failure starting OpersysService Service", e);
            
// ***** </ADDED-BY-OPERSYS> *****
...

上面为AOSP添加新类型硬件的方法和给出的代码仅仅就是能工作而已。因为你需要修改一些ASOP的文件，所以它是依赖版本的。定制化的扩展最好还是添加到device/<manufacturer/product_name>/目录，这样你就可以把它复制到任意的AOSP代码树里面去。但是尽管有些缺点，但是这种方法你可以以ASOP中大量的HAL模块作为例子，并且可以简单的复制这些代码来用，因为你增加的代码位置跟其他的内建组件是一样的。

要使得新类型的硬件对app和其他系统服务可用，还有很多种路线。我们可以把系统服务添加到产品相关的目录device/中，我们也可以采用Java创建一个独立的系统服务，甚至可以使用C这样的语言创建本地服务。虽然程序可以直接运行在CPU上，但是你就不能像Java一样使用aidl这样的工具来产生封装和解封装代码，与Binder通信的数据也都只能手工进行封装和解封装，这是相当繁琐的过程。

---

[1]亚荷毛尔.构建嵌入式Android系统[DB/CD].北京:中国电力出版社,2015.

[2]王振丽.底层开发技术实战详解-内核、移植和驱动[DB/CD].北京:电子工业出版社,2012.

十六宿舍 原创作品，转载必须标注原文链接。
©2023 Yang Li. All rights reserved.
欢迎关注 『十六宿舍』 ，大家喜欢的话，给个 👍 ，更多关于嵌入式相关技术的内容持续更新中。

哪个嵌入式 Linux 窗口系统支持硬件覆盖？

【中文标题】哪个嵌入式 Linux 窗口系统支持硬件覆盖？

【英文标题】：Which windowing system for embedded Linux supports Hardware Overlay?

【发布时间】：2009-11-05 16:38:10

【问题描述】：

哪个嵌入式linux窗口系统支持hardware overlay？

是否可以在 Qt 中为嵌入式 Linux 添加硬件覆盖支持？

【参考方案1】：

Qt for Embedded Linux 使用 Qt 自己的窗口系统。为了渲染图形，使用了后端。其中一些后端支持硬件图形加速——例如用于基于 OMAP 的高端系统的 PowerVR 后端。在这里，您可能可以创建叠加层，但您必须使用 Qt 来完成，因为 Qt 完全拥有屏幕。

我使用的另一种替代方法（实现机顶盒功能时，即 UI over video）是为 Qt 编写自定义后端，然后为其配备额外的钩子，您可以使用这些钩子来控制覆盖功能（即从您的 Qt 应用程序中规避 Qt）。但我想这种方法算作 hack！

【讨论】：

非常感谢。让我告诉你，我读了你书的前四章。这是我读过的关于 QT 的最好的书。你把书写成正确的教程，事情就像流一样。