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。