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

標籤：add   處理   oid   無法   返回   dir   set   通過   cal   

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。

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