1. 概述:
从Android P开始,Mediatek Release的 Project会出现一种叫做 RSC (Run-time Switchable Configuration )的 makefile 文件。 比如 RuntimeSwitchConfig.mk,RuntimeSwitch.mk 以及 OpxxBase.mk, DsdsBase.mk等等。
* 以下描述都以 Android Q 的Split Build Project为例
* 以下描述都以 Android Q 的Split Build Project为例
首先要说,这些 Makefile里的配置一旦被使用,通常其
优先级就是最高的,会覆盖掉device.mk以及其他makefile里的设置。
具体用法还是要以各个Feature给客户提供的Customization方式的文档为准,这里只是概要的介绍RSC makefile以及机制在整个系统中的位置&作用,并不涉及具体的Feature的配置方法。
Mediatek 的Feature也并非全都支持Run-time Switch,具体配置方法,以各个Feature提供的 Customization为准.
目前粗略分类,会遇到三种情况:
第一类客户,
没有共版本需求,此时您可以选择忽略这些Makefile,我们的软件包虽然Release了这些各个package的 makefile,但其实默认并不会启用,您可以完全按照原有的 feature opiton的方式配置Project,此时开机后的Property和 APK都会按照 device.mk里面的配置来被设置和安装。当然也可以选择Follow 某些Feature的 Customization的文档的写法,启用其中某一个makefile,这样您Build出来的软件包,就会优先使用这个Makefile里的配置,变为您所有需要某种配置。
第二类客户,
有共版本需求,且有自己的可以在不同HW间切换Property/APK的机制,此时这些makefile可以成为您的参考文件,把makefile里的Property/APK都按您的方法,配置到您的机制里,就可以配出某种软件包来,比如各个Operator的Package.
第三类客户,
有新的共版本需求,但还没有来得及建立自己的切换机制,此时可以研究MTK的切换机制,通过客制化LK部分的Code来直接使用,抑或建立自己的切换机制
如果您对自己公司的Single Image机制并不了解,请您务必先和自己公司的 编译流程/项目配置 等部门负责人了解一下,
如果您已经有自己公司的配置方式了,请勿再使用Mediatek的机制,两套机制间可能会出现优先级的问题,影响到后续的产线/场测/不同地区出货等情景。
2. 机制简介:
类似的
共版本的需求在贵司,通常被称作
单软多硬、共Binary、Single Image、Single Binary等称呼,我们下面都称呼其Single Image。
其主要作用是实现编译好的一套Binary烧录到不同硬件上的时候,呈现不同的配置的能力,各家实现方式大同小异,多为在init/PMS植入code,以Mediatek的流程为例:
- 编译阶段以某种方式将不同硬件的配置信息写入Image
- 配置信息一般包含Property列表/APK/...
- 具体流程请参考下一章节的介绍
- LK(little kernel)通过 eFuse/GPIO等硬件讯息获取当前应该是用哪套配置,并通过Command Line的方式传给init.
- 这个步骤需要客户参考 DCC3209223 并根据自己的硬件设计自行实现
- 单个Package的时候,无需此步骤,此步骤仅用于需要"切换"的场景。
- init process增加一段逻辑,加载当前配置对应的预先放在Image里的 Property 列表.
- 具体流程参考:/system/core/init/property_service.cpp 里的 LoadRscRoProps LoadRscRwProps
- 具体流程参考:/system/core/init/property_service.cpp 里的 LoadRscRoProps LoadRscRwProps
- PMS 增加一段逻辑,安装当前配置对应的预先放在Image里的 APK.
- 具体流程参考:/vendor/mediatek/proprietary/frameworks/base/services/core/java/com/mediatek/server/pm/PmsExtImpl.java 搜索 rsc 相关的code
3. 配置/编译流程:
RSC相关的配置文件,在Project中的位置如下图,主要是由Project的 RuntimeSwitchConfig.mk,以及各个RSC Package自己的RuntimeSwitch.mk组成。
大部分RSC的RuntimeSwitch.mk都使用了Include其他.mk的方式用来减少配置的工作量。
Project从MTK Release的时候,只有配置default一个RSC(其内容通常为空),此时您可以把它任意换成某个RSC,当不涉及到切换的时候,是可以直接使用的,它可以被视为一套优先级很高的配置,会覆盖掉device.mk的配置。而当您要配置2个及以上的RSC的时候,就需要如上节所述,自行客制化LK里面切换的Code了。
DeviceTree部分的配置会稍微复杂,大多数Feature并不需要配置它,如果有需求的时候,可以参考Single Image的文档. DCC3209223
当完成编译后,会在不同的Image的etc/rsc/目录下生成几套不同的配置包,如下图,
然后Init和PMS以及各个模块会根据您从LK传入的rsc name,来选择不同目录进行加载/安装。
4. 客制化示例:
如果需要切换Property/APK,一般情况只需要在LK实现这个Function即可,该函数是个 Weak function,被LK的platform.c调用。
#include <rsc.h> #include <mt_gpio.h> void rsc_init(void) { /* Please customize here base on your HW design, usually call driver function to get some HW info, like eFuse value or GPIO value, then decide to use which RSC names. Example: here we check a MTK HW GPIO as an example */ if (mt_get_gpio_in(GPIO155) == 0) { cmdline_append(RSC_CMDLINE"rsc01"); } else { cmdline_append(RSC_CMDLINE"default"); } }
如果需要切换Device Tree Overlay 还需要额外实现这个Weak Function。
/* Implement this function only if you need to switch between different device tree overlay */ int rsc_get_dtbo_index(void) { if (mt_get_gpio_in(GPIO155) == 0) { return 1; //Index 1 dtbo for Special HW, map to rsc01 } return 0; //Index 0 dtbo for default }
来源:oschina
链接:https://my.oschina.net/u/3750358/blog/4307165