在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，就可以看到如下打印。