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))
取xxx.mk所在的路径notdir后的basename。
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 = 我们自定义的产品名字.
当中*号可代表存在多级文件夹下的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。