将小米平板2从低版本安卓适配到高版本的若干收获与思考

有个愿望：让小米平板2用上64位 Android9.0。因为64位 Android9.0 的 houdini 兼容性非常好，我曾经试过把 houdini9 植入 Android_x86-9.0 r2，然后安装到小米平板2中，发现APP运行很稳定，其它小米平板2安卓系统常见的APP闪退问题基本上都没有。只是因为显卡原因，Android_x86-9.0 r2 在小米平板2上只能运行在 nomodeset 模式下，视频靠CPU解码，导致系统卡顿很厉害。

目标很美好，但对于安卓适配新兵来说，实现这个目标还是要循序渐进。

我手头有能成功编译的 lineage13.0 for latte（小米平板2的代号是 latte）源码，lineage13.0 属于安卓6，为了缩小跨度，降低难度，我决定先从 lineage14.1 的小米平板2适配入手，因为 lineage14.1 属于安卓7，相比安卓6的变化比9要小一些。

虽然适配工作还没有完成，但过程中也有不少收获，总结一下。

一、下载源码

lineage14.1 的主源码可以按 LineageOS Wiki 上的说明下载，latte 的 vendor、device、kernel 则来自 Github（ LineageOS Resources for Xiaomi Mi Pad 2 ），但配置 local_mainifest.xml 时要注意：不要使用 cm-14.1 分支的 vendor、device、kernel，它的BUG太多，基于它进行适配工作量巨大，并且会出现很多看不懂的问题。建议用 cm-13.0 分支，因为它已经在 lineage13.0 for latte上适配成功，本身不存在问题，所需要做的是对 lineage14.1 调试。

二、获取日志

最初编译出来的 lineage14.1 Rom 安装到小米平板2上多半无法成功运行，需要查看日志来分析原因，但系统如果没有运行到合适的阶段是无法通过 ADB 获取日志的，怎么办？群友 ygjsz 提供了一个方法。

在 init.rc 中加入以下代码：

# Take logs even when adb is not working.
# Thanks: markakash
# Add these lines to your init.rc file:service boot_lc_main /system/bin/logcat -f /cache/boot_lc_main.txtclass mainuser rootgroup root systemoneshotservice boot_dmesg /system/bin/sh -c "dmesg > /cache/boot_dmesg.txt"class mainuser rootgroup root systemoneshoton property:sys.boot_completed=1start boot_lc_mainstart boot_dmesg

这段代码在开机后会自动把日志记录到 cache 文件夹中。当系统启动失败后，长按电源键+音量增键，让平板进入 Recovery 模式，就能把日志拷贝出来分析。

三、处理 dlopen failed 错误

日志中常出现 dlopen failed 报错，形式为 cannot locate symbol "_ZNxxxx" referenced by "xxxxx.so"，例如：

 dlopen failed: cannot locate symbol "_ZN7android13GraphicBufferC1Ejjij"  referenced by "/system/vendor/lib/hw/hwcomposer.gmin.so"

这里需要重点搞清 symbol "_ZN7androidxxxxxx" 是什么？简单说，它是系统在编译 so 时自动生成的某个函数的别名，这个函数在源码中本来有易理解的名称，但在编译时编译器给它生成了一个 symbol，这个 symbol 具有唯一性，生成规则与函数名称、参数个数和参数类型有关，系统运行时根据它就可以定位到具体的动态库中具体的函数。

解决这个报错的第一步是要定位这个函数，但由于不知道生成规则，所以无法直接解码 symbol 去定位函数源码，但我找到了一个方法。

报错中的 xxxxx.so 一般都位于 system/vendor/lib 中，因为用的是 lineage13.0 for latte 的 vendor， lineage14.1 中找不到的那个 symbol 在 lineage13.0 一定能找到，所以可以先到 lineage13.0 中找，确定函数位于哪个源码文件中，然后再看 lineage14.1 中这个文件为什么没有这个函数。

就以 dlopen failed: cannot locate symbol "_ZN7android13GraphicBufferC1Ejjij" referenced by "/system/vendor/lib/hw/hwcomposer.gmin.so" 举例。

先看 "_ZN7android13GraphicBufferC1Ejjij" 位于 lineage13.0的哪个动态链接库中：

butterfly@Amazon:~/lineage/13.0/out/target/product/latte/system/lib$ find -type f -name '*.so' | xargs grep "_ZN7android13GraphicBufferC1Ejjij"

出现以下结果：

匹配到二进制文件 ./libstagefright_wfd.so
匹配到二进制文件 ./libshim_camera.so
匹配到二进制文件 ./libgui.so
匹配到二进制文件 ./hw/camera.gmin.so
匹配到二进制文件 ./arm/libgui.so
匹配到二进制文件 ./arm/libui.so
匹配到二进制文件 ./arm/nb/libgui.so
匹配到二进制文件 ./arm/nb/libui.so
匹配到二进制文件 ./libui.so
匹配到二进制文件 ./libwebviewchromium_plat_support.so

说明这些so动态链接文件中都有 "_ZN7android13GraphicBufferC1Ejjij"，但有并不表示这个函数在这个文件中，有可能这个文件只是调用了这个函数而已，那么哪个才是被调用的文件呢？

对这些文件逐个执行下面命令：

butterfly@Amazon:~/lineage/13.0$ ~/Android/Sdk/ndk/16.1.4479499/toolchains/x86_64-4.9/prebuilt/linux-x86_64/bin/x86_64-linux-android-gcc-nm -D ~/lineage/13.0/out/target/product/latte/system/lib/libui.so | grep GraphicBuffer | sort

命令中，“GraphicBuffer”是 symbol 中一段有字面含义的文字，它一般是那个函数名称中的一部分。

出现下面结果：

00007930 T _ZN7android13GraphicBufferC1Ev
00007930 T _ZN7android13GraphicBufferC2Ev
00007a20 T _ZN7android13GraphicBufferC1Ejjij
00007a20 T _ZN7android13GraphicBufferC2Ejjij
00007b30 T _ZN7android13GraphicBuffer8initSizeEjjij
00007c00 T _ZN7android13GraphicBufferC1EjjijjP13native_handleb
......

可以看到第三行就是那个 symbol，它前面有一串十六进制数 00007a20，这表明这个 symbol 在这个so文件中对应着有实实在在的函数；如果这个 symbol 前面没有十六进制字符串，则表明这个 symbol 出现在这个文件中只是因为这个文件调用了别的库中的这个函数。通过这个方法可以找到有这个函数的so文件，在这个例子中就是 system/lib/libui.so（其实有一个方法可以减轻工作量，不用对每个so文件都检查：用 Cutter 工具打开 hwcomposer.gmin.so，查看它的依赖库，仅对是其依赖库的so文件进行分析）。

上面的命令中，x86_64-linux-android-gcc-nm 的路径是计算机中它的安装位置，我的安装在 ~/Android/Sdk/ndk/16.1.4479499/toolchains/x86_64-4.9/prebuilt/linux-x86_64/bin/ 中。

下面查这个so文件的确切函数名称和参数。对 system/lib/libui.so 执行下面这条命令（与上一条很像，但多一个 “-C”）：

butterfly@Amazon:~/lineage/13.0$ ~/Android/Sdk/ndk/16.1.4479499/toolchains/x86_64-4.9/prebuilt/linux-x86_64/bin/x86_64-linux-android-gcc-nm -C -D ~/lineage/13.0/out/target/product/latte/system/lib/libui.so | grep GraphicBuffer | sort

出现下面结果：

00007930 T android::GraphicBuffer::GraphicBuffer()
00007930 T android::GraphicBuffer::GraphicBuffer()
00007a20 T android::GraphicBuffer::GraphicBuffer(unsigned int, unsigned int, int, unsigned int)
00007a20 T android::GraphicBuffer::GraphicBuffer(unsigned int, unsigned int, int, unsigned int)
00007b30 T android::GraphicBuffer::initSize(unsigned int, unsigned int, int, unsigned int)
00007c00 T android::GraphicBuffer::GraphicBuffer(unsigned int, unsigned int, int, unsigned int, unsigned int, native_handle*, bool)
00007c00 T android::GraphicBuffer::GraphicBuffer(unsigned int, unsigned int, int, unsigned int, unsigned int, native_handle*, bool)
00007d00 T android::GraphicBuffer::GraphicBuffer(ANativeWindowBuffer*, bool)
00007d00 T android::GraphicBuffer::GraphicBuffer(ANativeWindowBuffer*, bool)
00007e10 T android::GraphicBuffer::~GraphicBuffer()
00007e10 T android::GraphicBuffer::~GraphicBuffer()
......

找到 00007a20 那行，其对应的是 GraphicBuffer::GraphicBuffer(unsigned int, unsigned int, int, unsigned int)，这就是那个函数的名称与参数。

然后查找函数源码。执行下面命令：

butterfly@Amazon:~/lineage/13.0$ find -type f -name '*.mk' | xargs grep "LOCAL_MODULE := libui"

出现：

./frameworks/native/libs/ui/Android.mk:LOCAL_MODULE := libui

由此可知 libui 的源码在 frameworks/native/libs/ui/ ，进到这个文件夹，运行：

butterfly@Amazon:~/lineage/13.0/frameworks/native/libs/ui$ find -type f -name '*.cpp' | xargs grep "GraphicBuffer::GraphicBuffer("

出现：

./GraphicBuffer.cpp:GraphicBuffer::GraphicBuffer()
./GraphicBuffer.cpp:GraphicBuffer::GraphicBuffer(uint32_t inWidth, uint32_t inHeight,
./GraphicBuffer.cpp:GraphicBuffer::GraphicBuffer(uint32_t inWidth, uint32_t inHeight,
./GraphicBuffer.cpp:GraphicBuffer::GraphicBuffer(ANativeWindowBuffer* buffer, bool keepOwnership)

至此，可以确定那个 symbol 对应的函数在 frameworks/native/libs/ui/GraphicBuffer.cpp 中。

打开 ~/lineage/13.0/frameworks/native/libs/ui/GraphicBuffer.cpp，可以找到 GraphicBuffer::GraphicBuffer(unsigned int, unsigned int, int, unsigned int)。打开 Lineage14.1 中同名文件，发现尽管其中也有 GraphicBuffer::GraphicBuffer 函数，但所有的 GraphicBuffer 函数中没有参数为 (unsigned int, unsigned int, int, unsigned int) 的。

现在可以动手解决 dlopen failed 错误了：参照 lineage13.0 中函数内容，在 lineage14.1 中添加相同参数的 GraphicBuffer 函数。这个函数怎么写要具体情况具体分析，即要实现其应有的功能，又不能破坏原有的函数。

添加完，编译后，让平板进入REC 模式，将 lineage14.1 中新生成的 out/target/product/latte/system/lib/libui.so 拷贝到平板中，再开机获取日志，可以看到那条 dlopen failed 报错不再出现了。

其它 dlopen failed 错误也可以参考这个方法解决。

但有一个类似报错折腾了我很长时间，需要用到不同的处理方法。这个报错形式是：Can't locate symbol "ufoInitPlatform" referenced by ......

这个问题折磨我很久才发现是因为系统中有两个 libskuwa.so，一个在 system/lib 中，一个在 vendor/lib 中，默认会调用 system/lib 下那个，而那个是没有 ufoInitPlatform 函数的。解决办法就是把 system/lib 下面那个 libskuwa.so 删除。

通过前面这些处理方法，我成功地实现了小米平板2的开机动画显示。

四、目前遇到的困难

适配工作还在艰难进行中，不断遇到新的问题。目前主要有三个问题不知道该怎么分析。

1.keymaster

日志中有下面报错重复出现：

3336  3336 I keystore: Found keymaster0 module Keymaster Intel MEI HAL, version 3
3336  3336 I SoftKeymaster: system/keymaster/soft_keymaster_device.cpp, Line 131: Creating device
3336  3336 D SoftKeymaster: system/keymaster/soft_keymaster_device.cpp, Line 132: Device address: 0xf6eb0000
3336  3336 I ITEEKeyMaster: intel_mei_km_open called
3336  3336 I ITEEKeyMaster: Connected to keymasterd successfully
3336  3336 I ITEEKeyMaster: get_supported_classes called
2904  3337 E ITEEKeyMasterD: Could not acquire wake lock ret = -2
3336  3336 E ITEEKeyMaster: Received error -2 on command 0 from FW
3336  3336 E ITEEKeyMaster: CMD_ID_GET_SUPPORTED_CLASSES failed
3336  3336 E keystore: Error opening keystore keymaster0 device.
3336  3336 E keystore: keystore keymaster could not be initialized; exiting

我能跟踪到报错来自 keystore.gmin.so，由于没有它的源码，无法进一步分析。

尝试用 keystore.default.so 替换 keystore.gmin.so，日志中报错消失，变成下面的内容，不确定是否解决。

3045  3045 I keystore: Found keymaster0 module Keymaster OpenSSL HAL, version 2
3045  3045 I SoftKeymaster: system/keymaster/soft_keymaster_device.cpp, Line 131: Creating device
3045  3045 D SoftKeymaster: system/keymaster/soft_keymaster_device.cpp, Line 132: Device address: 0xf6eb0000
3045  3045 I keystore: Keymaster0 module is software-only.  Using SoftKeymasterDevice instead.

2.sensorhubd

报错如下，不知道该如何分析。

3335  3335 F libc    : Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 3335 (sensorhubd)
3338  3338 E         : debuggerd: Unable to connect to activity manager (connect failed: Connection refused)
3338  3338 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
3338  3338 F DEBUG   : LineageOS Version: '14.1-20220120-UNOFFICIAL-latte'
3338  3338 F DEBUG   : Build fingerprint: 'Xiaomi/latte/latte:5.1/LMY47I/V8.2.2.0.LACCNDL:user/release-keys'
3338  3338 F DEBUG   : Revision: '0'
3338  3338 F DEBUG   : ABI: 'x86'
3338  3338 F DEBUG   : pid: 3335, tid: 3335, name: sensorhubd  >>> /system/bin/sensorhubd <<<
3338  3338 F DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
3338  3338 F DEBUG   :     eax 00000001  ebx f733fdcc  ecx 00000000  edx f7747371
3338  3338 F DEBUG   :     esi f6d1900c  edi f745f010
3338  3338 F DEBUG   :     xcs 00000023  xds 0000002b  xes 0000002b  xfs 00000003  xss 0000002b
3338  3338 F DEBUG   :     eip f6dd92ce  ebp ffb37a18  esp ffb37a18  flags 00010286
3338  3338 F DEBUG   :
3338  3338 F DEBUG   : backtrace:
3338  3338 F DEBUG   :     #00 pc 000062ce  /system/lib/libcutils.so (android_atomic_inc+14)
3338  3338 F DEBUG   :     #01 pc 00008f6d  /system/lib/libaware_client.so (_ZNK7android12SharedBuffer7acquireEv+29)
3338  3338 F DEBUG   :     #02 pc 00005470  /system/lib/libaware_client.so (_ZN7android7String8C1Ev+32)
3338  3338 F DEBUG   :     #03 pc 000074b1  /system/lib/libEGL.so
3338  3338 F DEBUG   :     #04 pc 0000b91b  /system/bin/linker (__dl__ZN6soinfo13call_functionEPKcPFvvE+139)
3338  3338 F DEBUG   :     #05 pc 0000b803  /system/bin/linker (__dl__ZN6soinfo10call_arrayEPKcPPFvvEjb+323)
3338  3338 F DEBUG   :     #06 pc 00009423  /system/bin/linker (__dl__ZN6soinfo17call_constructorsEv+371)
3338  3338 F DEBUG   :     #07 pc 0000937a  /system/bin/linker (__dl__ZN6soinfo17call_constructorsEv+202)
3338  3338 F DEBUG   :     #08 pc 0000937a  /system/bin/linker (__dl__ZN6soinfo17call_constructorsEv+202)
3338  3338 F DEBUG   :     #09 pc 0000937a  /system/bin/linker (__dl__ZN6soinfo17call_constructorsEv+202)
3338  3338 F DEBUG   :     #10 pc 0000937a  /system/bin/linker (__dl__ZN6soinfo17call_constructorsEv+202)
3338  3338 F DEBUG   :     #11 pc 0000937a  /system/bin/linker (__dl__ZN6soinfo17call_constructorsEv+202)
3338  3338 F DEBUG   :     #12 pc 00010ec2  /system/bin/linker (__dl__ZL29__linker_init_post_relocationR19KernelArgumentBlockj+7746)
3338  3338 F DEBUG   :     #13 pc 0000efb6  /system/bin/linker (__dl___linker_init+630)
579  3338  3338 F DEBUG   :     #14 pc 0001c4f3  /system/bin/linker (__dl__start+35)

将 system/bin/sensorhubd 删除后报错消失，但问题肯定是没有解决。

3.Preloading shared libraries

前面两个报错凑乎着应付过去后，日志停在下面这行，也不知道该如何分析，需要恶补一些安卓系统启动方面的知识。

3054  3054 I Zygote  : Preloading shared libraries...

五、几点体会

不知道最终能否成功，但时不时总结一下很有必要。

小米平板2适配高版本安卓这个目标，给我提供了强烈的学习动机。前面那些摸索出来的方法和工具，以及很多不方便记录下来的小而杂的收获，都是得益于这个动机的推动。可以肯定地说，没有这个目标我无法坚持自学这么多东西，这点倒是很符合费曼学习法。
没有足够的知识储备，包括C++、JAVA、Android系统原理等，进行适配工作是很困难的。这些决定了不能急于求成，有强烈动机当然好，但一味急功近利地解决眼前问题，恨不得马上就见成果，是不现实的，欲速则不达，欲速往往是在走弯路。应该停下来补习补习相关知识。
做一件辛苦的事，冲着最终目标去当然是应该的，但设计好过程中的子目标也很重要。尤其对于系统适配这个不知道是否能成功的目标，如果最终目标没有达成，过程中也没有收获，那真是白白浪费了时间。对于这个项目，设置一些学习目标作为子目标是不错的选择。
做 lineage14.1 for latte 对于新手来说不是好的选择。刚开始时选择这个目标没有错，因为它对我最有吸引力，但遇到这么多不能克服的困难后，应该暂停，换一个目标。因为 lineage14.1 for latte 的 vendor 没有源码，遇到问题往往只能来回试探，效率很低，运气成分很大；Android7 相比 Android6 的变化比预想的要大，导致 lineage13.0 的代码和日志对于 14.1 来说参考性不足；小米平板2是一款比较老的设备，给它做适配的人很少，导致网上可以找到的参考资料很少。

我打算换个系统做学习样例，等知识积累足够多了，再回来继续做 lineage for latte 的适配。

希望高手大神们看到这篇文章，能给予指点，你们的一两句话也许对我就是拨云见日。拜托！