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.
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。