在bp文件中添加编译控制
适用平台:Q平台、R平台
遇到的问题:在产品的BoardConfig.mk中定义的编译控制,只能在Android.mk文件中使用,无法在Android.bp文件使用。
解决思路:经常在Android.bp中看到对于user版本和debug版本的编译控制,那能否参考系统实现添加自定义的编译控制呢,答案是肯定的。
上图中的 debuggable 关键字就是编译控制,意思是编译debug版本时设置两个宏定义为1(默认为0)。
搜索源码,在 build/make/core/soong_config.mk 文件中找到了 debuggable 的定义,实现了TARGET_BUILD_VARIANT (mk中定义)和 Debuggable(bp中使用) 的关联,截图如下:
在 build/soong/android/variable.go 文件中找到了 debuggable 结构的定义,结构体中指明了可以控制的范围,截图如下:
下面我们来定义自己的控制feature,作用是控制user版本上remount功能的开启。默认情况下,user版本时不支持remount功能的,为了调试的方便,添加了编译控制。在需求存在的情况下,可以编译出支持remount功能的user版本,提高开发效率。下面给出详细的添加步骤。
1、在 build/make/core/soong_config.mk 文件中定义 Remount_on_user 编译控制,和BoardConfig.mk中的 PRODUCT_ALLOW_REMOUNT_ON_USER 关联。
2、在 build/soong/android/variable.go 文件中添加如下两部分。
定义 Remount_on_user 为 productVariables struct 中的一个变量
定义 Remount_on_user 结构中包含的控制变量(cflags, cppflags, rc文件, 模块依赖)
3、在 system/core/fs_mgr/Android.bp 中进行了应用,相当于在user版本上增加了debug版本的编译宏控制,截图如下。
4、在 BoardConfig.mk 中定义编译feature,需要的时候开启如下feature就可以,可有效减小项目的维护成本。
5、到此,工作就结束了。但是我们在编译时怎么知道这个feature是否配置了呢,怎么在不看代码的情况下知道呢。
在 build/soong/ui/build/dumpvars.go 中添加feature的打印。
这样在lunch编译目标后,如果在 BoardConfig.mk 中定义了feature,就可以看到如下打印。
本文地址:https://blog.csdn.net/wangxuguang_/article/details/109609410
推荐阅读