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.

197 current_product_makefile :=
198 all_product_makefiles :=
199 $(foreach f, $(all_product_configs),200     $(eval _cpm_words := $(subst :,$(space),$(f)))201     $(eval _cpm_word1 := $(word 1,$(_cpm_words)))202     $(eval _cpm_word2 := $(word 2,$(_cpm_words)))203     $(if $(_cpm_word2),204         $(eval all_product_makefiles += $(_cpm_word2))205         $(if $(filter $(TARGET_PRODUCT),$(_cpm_word1)),206             $(eval current_product_makefile += $(_cpm_word2)),),207         $(eval all_product_makefiles += $(f))208         $(if $(filter $(TARGET_PRODUCT),$(basename $(notdir $(f)))),209             $(eval current_product_makefile += $(f)),)))
 

210 _cpm_words :=
211 _cpm_word1 :=
212 _cpm_word2 :=
213 current_product_makefile := $(strip $(current_product_makefile))
214 all_product_makefiles := $(strip $(all_product_makefiles))

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 \

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

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

當中*號可代表存在多級文件夾下的xxx.mk.即/*/會自己主動跨越多級文件夾找到須要的目標文件。

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值是須要作為一個文件夾名的，由於興許在envsetup.mk中查找device相關的boardconfig.mk時，須要在device和vendor的文件夾下查找-maxdepath 4 -path */$(TARGET_DEVICE)/BoradConfig,mk（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後確定TAEGET_DEVICE來自於PRODUCT_DEVICE如這裏的fish。假設所在的文件夾名不是fish。則報no device config失敗。

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

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