Android集成一個新產品時，lunch的product name和device name注意事項

Android集成一個新產品時，lunch的product name和device name注意事項

Android系統lunch一個當前的Product大概流程包含以下幾個部分：

1. lunch確定TARGET_PRODUCT，一般位於vendor/device/build/target/product中的vendorsetup.sh腳本來定義分別有user/eng/userdebug。

2. 開發check product的合理性。

通過加載vendor/device/build/target/product中的AndroidProduct.mk文件，記錄其包含的各個.mk文件以及其所在的路徑，作為當前的all_product_makefile.

通過選擇的TARGET_PRODUCT filter到current_prodcut_makefile.

3 通過import-product當前的makefile文件，有可能是all,一般是current。這個import過程，基本是解析這個mk文件，並根據_product_var_list來生成一個全新的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 \

這些變量需要在我們Product目錄下進行定義並賦值，其中相關賦值決定了這個Product能否通過lunch的Product check。

 

4. 當對相關的mk文件進行var list的生成後組成全新的變量名：

PRODUCT.device/"vendor"/"device_name"/xxx.mk.PRODUCT_NAME = 我們自己定義的產品名字

5. resolve-short-product-name

resolve-short-product-name函數定義在build/core/product.mk文件中。

該函數的本質是根據TARGET_PRODUCT來與我們之前已經根據xxx.mk生成這個var list中的帶PRODUCT_NAME字段的變量值做match匹配。最終如果匹配的話，就把這個變量中屬於這個xxx.mk文件的路徑作為返回值返回。

這個過程如果出現no matches ,則說明雖然我們創建的文件結構雖然正常，但當Product相關的xxx.mk文件中指定的PRODUCT_NAME與我們lunch申明的值時是不相互匹配的，則說明這個lunch選擇的product的不合理的，需要重新選擇，或者說這個product name需要修改。。

lunch選擇的TARGET_PRODUCT作用首先是定位xxx,mk文件結構是正常的，如lunch fish，則一般需要定義fish,mk文件。

但最終TARGET_PRODUCT進一步的作用在於需要和具體fish,mk中的PRODUCT_NAME的值相互match，才會通過match過程。

6. 上述過程最終目的是通過PRODUCT來確定TARGET_DEVICE，從而找到這個device

device最直接的體現是這個xxx,mk中定義的PRODUCT_DEVICE值是需要作為一個目錄名的，因為後續查找device相關的boardconfig.mk時，需要在/device/xxx/device_name（TARGET_DEVICE，數值有xxx,mk中的PRODUCT_DEVICE來決定）。

總結：

上述描述大致可以說明在定義一個vendor下需要發布的Product時，我們應該先定義一個device_name作為當前Product的一個大目錄，在這個目錄下定義一個xxx,mk文件，這個xxx.mk中需要指定PRODUCT_DEVICE和目錄名一致，然後定義PRODUCT_NAME，再去lunch 中定義相同的一個name，可以有user/eng等類型可選，在處理好這些後需要將xxx命名為這個PRODUCT_NAME即TARGET_PRODUCT對應的數值。

之所以需要這樣做的目的是為了順利在all Product makefile文件中提取和TARGET_Product相一致的mk文件作為當前文件。

/device/gzz/fish/下基本文件：

1.先定義一個xxx.mk，xxx需要由PRODUCT_NAME決定，即兩者一致:

PRODUCT_NAME := my_fish
PRODUCT_DEVICE := fish

device name兩者一致

2.切換文件名為my_fish.mk，確保Product name一致

3. AndroidProduct.mk:

PRODUCT_MAKEFILES := $(LOCAL_DIR)/my_fish.mk

4. vendorsetup,sh

add_lunch_combo my_fish-eng，確保Product name一致

5. 其他相關如boardconfig.mk等.

需要說明的是定義的Product和device name兩者是可以不一致的，後者作為在out/target/product/fish/編譯的輸出。

lunch在處理時從下到上開始處理，TARGET_PRODCUTmy_fish如果無法從所有的Product makefile匹配my_fish.mk文件的話，lunch失敗。

如果my_fish.mk文件被解析並生成var list後，再與my_fish匹配，如果PRODUCT_NAME與my_fish不一致，則match失敗。

match成功並找到device name後，如果所在的目錄名不是fish，則報device config失敗。

故各方面都需要保持一致，才可以通過一次lunch的查找，Android很好的確保了系統進行編譯時，整個編譯環境是ok的，且是你所需要的Product。