Important Android compilation parameter local_module_tags

Http://hi.baidu.com/kenny_wju/item/042603c7f4f66d78ced4f83b

Recently transplanted the tslib Library to the Android system, it is strange to find that the compiled library and test tool are not input to out/target/product/ok6410/system/lib and out/target/product/ok6410/system/bin, so I made up my mind to see where I entered it.

The process is as follows:

Tslib source code is stored in the vendor directory under android2.3 source code (add your own file in android2.3 and set your own file in my blog) under forlinx/ok6410. android. after MK is written, re-make clean the entire android source code and make the compilation again. The strange thing is that the output directory out/target/product/ok6410/SystemNo tslib-related tools are available in/bin, but in out/target/product/ok6410/Symbols/System/Bin, because the symbols folder is not put into the file system during packaging, the calibration function cannot be implemented. (In fact, the symbols folder should not be taken into account during file extraction ).

The final reason is that there is a problem with the local_module_tags variable setting in the Android. mk file in the tslib file.

Local_module_tags: = optional

Change this

Local_module_tags: = ENG

The reason is that the local_module_tags variable andThe target_build_variant variable is closely related.If this parameter is not specified during Android compilation

The value of the target_build_variant variable. The default value isTarget_build_variant = ENG, which specifies the version style formed when Android is compiled. This value is generally used for release, and also has style values such as user and debuguser,Take a look at this link.If it cannot be opened, you can open a wall.

After this setting, re-compile and output the directory out/target/product/ok6410/system/bin, out/target/product/ok6410/system/LIB contains tslib-related libraries and test programs.

Therefore, if you need to add additional modules or applications, pay attention to Android. the variable in MK, of course, can be compiled if you specify local_module_tags: = optional, but the input path is not general.

Out/target/product/ok6410/System/Directory, but out/target/product/ok6410/Symbols/System/Directory.

Later, I put a module under the external directory of the android source code, specifying the Compiling Style of the module as local_module_tags: = optional, and re-compiling the module, output directly to out/target/product/ok6410/System/Directory. I am surprised that it is also related to the directory stored by the module. Therefore, it is best to specify the valueTarget_build_variant related, if not specifiedTarget_build_variant, which is set by default.Target_build_variant = ENG, you also specifyLocal_module_tags: = ENG

 

Currently, the module output path under the hardware directory has a great relationship with local_module_tags.

Local_module_tags: = optional> out/target/product/ok6410/Symbols/System/

Local_module_tags: = ENG> out/target/product/ok6410/System/

 

Of course, the premise is thatTarget_build_variant = ENG.

 

The following are similar problems encountered by netizens:

"Set local_module_tags to any number of whitespace-separated tags.

This variable controls what build flavors the package gets encoded DED
In. For example:

* User: include this in user/userdebug builds
* Eng: include this in Eng builds
* Tests: the target is a testing target and makes it available for tests
* Optional: Don't include this"

Are these the same as "variants" and if so, which name wowould affect
The build and how? I 've noticed that everything mentioned in
Product's makefile will always get built. But what gets in the final
System. IMG not always the same as what gets built.
Http://groups.google.com.tw/group/android-platform/browse_thread/thread/a4f70254a2ceb622