When Android integrates a new product, considerations for lunch's product name and device name

When Android integrates a new product, considerations for lunch's product name and device name

In the Android system lunch, the current Product process includes the following parts:

1. lunch: Determine TARGET_PRODUCT. Generally, the vendorsetup. sh script in the vendor/device/build/target/product contains user/eng/userdebug, respectively.

2. check the rationality of product development.

By loading the AndroidProduct. mk file in the vendor/device/build/target/product file, record each. mk file and its path as the current all_product_makefile.

Filter the selected TARGET_PRODUCT to current_prodcut_makefile.

3. The current makefile file of import-product may be all, generally current. This import process basically parses the mk file and generates a brand new list Variable Based on _ product_var_list.

 

 66  67 _product_var_list := \ 68     PRODUCT_NAME \ 69     PRODUCT_MODEL \ 70     PRODUCT_LOCALES \ 71     PRODUCT_AAPT_CONFIG \ 72     PRODUCT_AAPT_PREF_CONFIG \ 73     PRODUCT_PACKAGES \ 74     PRODUCT_PACKAGES_DEBUG \ 75     PRODUCT_PACKAGES_ENG \ 76     PRODUCT_PACKAGES_TESTS \

These variables need to be defined and assigned values under the Product directory. The related values determine whether the Product can pass the lunch Product check.

 

4. When var list is generated for the related mk file, a new variable name is formed:

PRODUCT. device/"vendor"/"device_name"/xxx. mk. PRODUCT_NAME = PRODUCT name defined by ourselves

5. resolve-short-product-name

The resolve-short-product-name function is defined in the build/core/product. mk file.

The essence of this function is to match the variable value with the PRODUCT_NAME field in the var list based on TARGET_PRODUCT that we have previously generated based on xxx. mk. In the end, the path of the xxx. mk file in the variable will be returned as the return value.

If no matches occurs in this process, it means that although the structure of the file we created is normal, when the Product-related xxx. when the PRODUCT_NAME specified in the mk file does not match the value stated by our lunch, it indicates that the product selected by this lunch is unreasonable and needs to be re-selected, or this product name needs to be modified ..

The TARGET_PRODUCT selected by lunch is used to locate xxx first, and the mk file structure is normal. For example, lunch fish usually needs to define the fish and mk files.

However, the final role of TARGET_PRODUCT is to match the value of PRODUCT_NAME in the specific fish and mk to pass the match process.

6. the final purpose of the above process is to determine TARGET_DEVICE through the PRODUCT, so as to find the device

The most direct embodiment of device is this xxx. The PRODUCT_DEVICE value defined in mk needs to be used as a directory name, because the relevant device boardconfig will be searched later. when mk is used, it must be determined by/device/xxx/device_name (TARGET_DEVICE, which has a value of xxx and PRODUCT_DEVICE in mk ).

Summary:

The above description Roughly indicates that when defining a Product to be released under the vendor, we should first define a device_name as a large directory of the current Product, and define a xxx and mk file under this directory, this xxx. in mk, you must specify the same PRODUCT_DEVICE and directory name, define PRODUCT_NAME, and define the same name in lunch. user/eng and other types are optional, after processing these items, You need to name xxx As the value corresponding to PRODUCT_NAME, that is, TARGET_PRODUCT.

The purpose of this operation is to extract the mk file consistent with TARGET_Product in the all Product makefile file as the current file.

/Device/gzz/fish:

1. First define a xxx. mk, xxx needs to be determined by PRODUCT_NAME, that is, the two are consistent:

PRODUCT_NAME: = my_fish
PRODUCT_DEVICE: = fish

The device names are the same.

2. Switch the file name to my_fish.mk to ensure that the Product name is consistent.

3. AndroidProduct. mk:

PRODUCT_MAKEFILES: = $ (LOCAL_DIR)/my_fish.mk

4. vendorsetup, sh

Add_lunch_combo my_fish-eng to ensure consistent Product name

5. Other issues such as boardconfig. mk.

It must be noted that the defined Product and device name can be inconsistent, and the latter can be used as the output in the out/target/product/fish/compilation.

Lunch starts processing from bottom to top during processing. If TARGET_PRODCUTmy_fish cannot match the my_fish.mk file from all Product makefiles, lunch fails.

If the my_fish.mk file is parsed and var list is generated, it matches with my_fish. If PRODUCT_NAME and my_fish are inconsistent, match fails.

After the match succeeds and the device name is found, if the directory name is not fish, device config fails.

Therefore, all aspects must be consistent before a lunch query can be performed. Android ensures that the entire compilation environment is OK during system compilation, and is the Product you need.