Android. mk for your own module

Source: Internet
Author: User

Http://blog.csdn.net/yili_xie/archive/2009/12/09/4971736.aspx

 

This analysis is good. The original address is shown in the figure.

 

Here we add our own modules to Android, which only involves compiling. So/*. A/Elf source and how to add prebuilt file to the project. The source of APK and jar is not carefully studied for the moment. To add them, refer to Android. mk ~~ in/pacakge and/framework ~~
The first is the basic knowledge that may be used. You must understand the syntax of the basic makefile. The following is the core makefile used by andriod to compile the corresponding modules, of course, if you want to speed up the process, you can simply add these items as follows:
1. prebuilt
/Build/CORE/base_rules.mk
/Build/CORE/prebuilt. mk
/Build/CORE/multi_prebuilt.mk
2. So/
/Build/CORE/base_rules.mk
/Build/CORE/shared_library.mk
/Build/CORE/dynamic_library.mk
/Build/CORE/binary. mk
3..
/Build/CORE/base_rules.mk
/Build/CORE/static_library.mk
/Build/CORE/binary. mk
The preparation of executable files is basically the same as that of. So. It is divided into two types: prebuilt files compilation and. So/. A/Elf compilation.
Base_rules.mk is the most important of all makefiles. It is the core process for processing the module. Let's take a look at the content of this file:

Each module generates a compilation directory and an installation directory during compilation. The compilation directory is the target file generated after the module is compiled, the installation directory indicates whether the module is compiled into the file system, that is, whether it is compiled into the IMG ~~ Two variables are provided in base_rules.mk to define the directory you want to output. It is helpful to understand the generated directory after compilation ~~
Built_module_path: = $ (intermediates)
Local_built_module: = $ (built_module_path)/$ (local_built_module_stem)
Local_installed_module: = $ (local_module_path)/$ (local_module_subdir) $ (local_installed_module_stem)
Built_module_path is the directory where the intermediate file generated by compilation is located. local_built_module_stem is the compilation target you want to generate. If the local module specifies local_module_stem, its value is $ (local_module_stem) $ (local_module_suffix). If it is not specified, $ (local_module) $ (local_module_suffix ). From this we can see that the definition of local_module is very exquisite. For example, *. So is generally used as the module name. Local_module_suffix: When Compiling different modules, Google will add the corresponding value to you. If you do not know it, try to specify it by yourself, otherwise, the compiled object may have been tampered with the file name ~~
Copy the files in the compilation directory to the installation directory, which is our local_installed_module. Whether it will be installed depends on your local_module_tags. Of course, you can also modify local_module_path to customize the installation. Local_module_path is a useful variable. First, let's take a look at the value of local_module_path :=$ ($ (my_prefix) when we do not specify this value in the local module) out $ (use_data) _ $ (local_module_class). If your module defines tags: = tests, the value of user_data is data, this module will be installed in the data/directory. By replacing it, we will know that local_module_path: = target_out _ $ (local_module_class ). This local_module_class will be assigned a fixed value by Google in a specific type of compilation, but it is assigned by you in prebuilt compilation, its value is used to define the generated directory. For example, when local_module_class: = etc, it will be installed in the/system/etc directory. Then we know how to define the class in the prebuilt module. Google also provides a local_module_subdir that allows you to define sub-directories, but remember to clear this value at the end of each module, because clear_vars does not empty this value by default.
Of course, we mentioned the default value of local_module_path. We can assign a value to it to forcibly specify the installation directory, for example, to install it in the system/etc/permissions directory, you can forcibly specify its value as $ (target_out_etc)/permissions, so that the module will be forcibly installed in this directory, when assigning values to local_module_path, it is mainly applied to the compilation of the prebuilt module. Others should adopt their default values as much as possible.
Next, let's take a look at an example of how to compile your own. So *. A elf. I have written out the variables that can be used and what I should pay attention:

 

This is the prelink. prelinke is only compiled. so will only have options, mainly through the pre-Link Method to speed up program startup and execution, if your local module prelink is true, then you need to define the space required for your library in build/CORE/prelink-linux-arm.map, if the space is not enough, an error will be reported (the specific use has not been carefully studied)
Next, let's take a look at how to compile our own prebuilt files into the project. Let's take a look at the two most important makefiles:

 

Multi_prebuilt.mk is only used to add various libraries to be added. Pay attention to the function in it to process the added files, especially the local_module, local_module_suffix, and local_src_files variables, files compiled into the project using multi_prebuilt are automatically tagged with the user. In addition, it will eventually use prebuilt. mk to execute the real compilation operation.
Prebuilt. mk can actually compile any file into our project. The following is an example I wrote. The file in the corresponding format under the directory can be automatically compiled into the project:

 

In addition, you can add prebuilt. mk in a rough way. You can simply add all prebuilt files to your project using the following rules. You must add them one by one:
Local_path: = $ (call my-DIR)
Include $ (clear_vars)
# Your prebuilt file name
Local_module: = example. So
Local_module_tags: = user Eng
# Your prebuilt file (must be relative directory)
Local_src_files: = lib/example. So
# The path your prebuilt file will be installed $ (target_out) is the system directory
Local_module_path: = $ (target_out)/lib
Include (build_prebuilt)

Finally, let's talk about the android rule for module uniqueness detection. In base_rules.mk, use module_id to check whether the module already exists. Let's see how this value is defined:

Module_id: = module. $ (if/
$ (Local_is_host_module), host, target). $ (local_module_class). $ (local_module)

Therefore, it uses the local_module_class and local_module variables to check the uniqueness of the module. Therefore, when you define the same class and module, Android reports an error, the prompt module must be unique. Therefore, if you modify local_module_calss and use local_module_path to specify the installation directory, Android will not detect module uniqueness, but the problem is that the same target has multiple rules to implement it, and each rule is the same command. The result is that make puts all dependencies together and uses commands to generate the target. This is very dangerous and will overwrite the database, in addition, you often don't know which dependency it uses to generate the final target. Instead, you can use md5sum to check the dependency.

Therefore, you should be especially careful when using prebuilt to overwrite the original system files. If you confirm that your files will run normally after overwriting the original system files, the good way is to enable android to check the module_id and modify the makefile of the original file so that it does not compile the file ~

Finally, we will add how Android stores the module's compilation intermediate files:
1. If your local_module_class contains common_module_class: = java_libraries notice_files, the intermediate file you compiled will be placed in:
$ (Targetmediaout_common_intermediates)/$ (local_module_class)/$ (local_module) _ intermediates/
Target_out_common_intermediates: = out/target/common/obj
2. If your local_module_class does not contain common_module_class, the intermediate file you compiled will be placed in:
$ (Target1_out_intermediates)/$ (local_module_class)/$ (local_module) _ intermediates/
Target_out_intermediates: = out/target/product/msm7627_ffa/obj

This article from the csdn blog, reproduced please indicate the source: http://blog.csdn.net/yili_xie/archive/2009/12/09/4971736.aspx

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.