根据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.
欢迎关注 『十六宿舍』 ，大家喜欢的话，给个 👍 ，更多关于嵌入式相关技术的内容持续更新中。