編輯:關於Android編程
在前文Android——編譯系統初始化設置中有解析編譯的TARGET_BUILD_VARIANT的配置與基本區別,
其中的一些編譯控制是對的但是Module的Android.mk中的LOCAL_MODULE_TAGS 控制並不全適用目前的android4.2,這裡記錄一下我對Module的控制過程。
首先還是這個放在Android.mk中的變量,默認在/build/core/base_rules.mk 中:
LOCAL_MODULE_TAGS := $(sort $(LOCAL_MODULE_TAGS)) ifeq (,$(LOCAL_MODULE_TAGS)) LOCAL_MODULE_TAGS := optional endif
而且並不是 LOCAL_MODULE_TAGS :=optional 就會都安裝進system.img !
LOCAL_MODULE_TAGS 在 android 4.2 能取的值有:
# Only the tags mentioned in this test are expected to be set by module # makefiles. Anything else is either a typo or a source of unexpected # behaviors. ifneq ($(filter-out debug eng tests optional samples shell_ash shell_mksh,$(LOCAL_MODULE_TAGS)),) $(warning unusual tags $(LOCAL_MODULE_TAGS) on $(LOCAL_MODULE) at $(LOCAL_PATH)) endif
其中TARGET_BUILD_VARIANT 還是對應:
默認類型,安裝 LOCAL_MODULE_TAGS 的類型為/build/core/main.mk:
ifeq ($(TARGET_BUILD_VARIANT),eng) tags_to_install := debug eng
安裝 PRODUCT_PACKAGES 中定義的Module
用於發行版,像之前描述的關閉log,shel,rootl,編譯出odex Android——編譯odex保護
LOCAL_MODULE_TAGS 的值不能為 user
安裝哪些Module 只依賴與 PRODUCT_PACKAGES
用於調試,安裝 LOCAL_MODULE_TAGS 的類型為/build/core/main.mk:
ifeq ($(user_variant),userdebug) # Pick up some extra useful tools tags_to_install += debug
安裝 PRODUCT_PACKAGES 中定義的Module
這裡記錄一種現象,不管 Module 是apk 還是 lib ,有的時候在單獨 mmm 編譯 的時候,
是可以安裝到 /out 中的system對應位置的,最後能夠打包進系統的system.img
但是 如果整體的 make -j* 編譯系統,那麼 對應的 apk .lib 就會生成在 /out 下的 symbols/system 對應的位置,
最後是不會打包進系統system.img 的!
這就是因為 Module 的LOCAL_MODULE_TAGS 和當前的編譯的TARGET_BUILD_VARIANT 沒有滿足上面說到的規則,
Module 並不認定為需要 install 的!
可以按照上面的規則,修改Module的 LOCAL_MODULE_TAGS 或者 看下面的 在 PRODUCT_PACKAGES 中添加 Module !
這裡只區分對Module的安裝控制,可以看到在4.2 中 對Module的控制級別最高的是 PRODUCT_PACKAGES 這個變量!
這個變量在很多.mk中都有賦值,比如在device中的 device.mk 中,而且都是 類似這樣的:
# jscese add libusb and compat lib ,usb-modeswitch execute binary for 3G PRODUCT_PACKAGES += rild libusb libusb-compat usb_modeswitch #end
這就代表這些Module 無論如何都會被編譯安裝進系統。
簡單記錄下PRODUCT_PACKAGES 的作用過程:
首先在main.mk中的
# The base list of modules to build for this product is specified # by the appropriate product definition file, which was included # by product_config.make. product_MODULES := $(PRODUCTS.$(INTERNAL_PRODUCT).PRODUCT_PACKAGES) # Filter out the overridden packages before doing expansion product_MODULES := $(filter-out $(foreach p, $(product_MODULES), $(PACKAGES.$(p).OVERRIDES)), $(product_MODULES)) $(call expand-required-modules,product_MODULES,$(product_MODULES)) product_FILES := $(call module-installed-files, $(product_MODULES))
modules_to_install := $(sort $(ALL_DEFAULT_INSTALLED_MODULES) $(product_FILES) $(foreach tag,$(tags_to_install),$($(tag)_MODULES)) $(call get-tagged-modules, shell_$(TARGET_SHELL)) $(CUSTOM_MODULES) )
modules_to_install 還會經過一些過濾處理,具體可看main.mk中
# build/core/Makefile contains extra stuff that we don't want to pollute this # top-level makefile with. It expects that ALL_DEFAULT_INSTALLED_MODULES # contains everything that's built during the current make, but it also further # extends ALL_DEFAULT_INSTALLED_MODULES. ALL_DEFAULT_INSTALLED_MODULES := $(modules_to_install) include $(BUILD_SYSTEM)/Makefile modules_to_install := $(sort $(ALL_DEFAULT_INSTALLED_MODULES)) ALL_DEFAULT_INSTALLED_MODULES :=
make 編譯的時候的依賴如下:
# Building a full system-- the default is to build droidcore droid: droidcore dist_files ... .PHONY: droid
# Build files and then package it into the rom formats .PHONY: droidcore droidcore: files systemimage $(INSTALLED_BOOTIMAGE_TARGET) $(INSTALLED_RECOVERYIMAGE_TARGET) $(INSTALLED_USERDATAIMAGE_TARGET) $(INSTALLED_CACHEIMAGE_TARGET) $(INSTALLED_FILES_FILE)
# All the droid stuff, in directories .PHONY: files files: prebuilt $(modules_to_install) $(modules_to_check) $(INSTALLED_ANDROID_INFO_TXT_TARGET)
可以看到 依賴到了 上面分析到的 modules_to_install !
這一篇主要根據上一篇的大致說明,我相信如果看完這一篇,對開發自定義View將會有很大的幫助,先介紹ColorStateList和StateListDrawable兩個類:
學習技術最好的方式就是實戰,看書看不到的東西太多了,實際操作時會碰到各種書本裡提不到的問題,解決這些問題會迅速提升你的能力,你是一個solider,最好成長的方式就是實戰
我們來講一下自定義組合控件,相信大家也接觸過自定義組合控件吧,話不多說,直接干(哈~哈~):大家看到這個覺得這不是很簡單的嗎,這不就是寫個布局文件就搞定嘛,沒錯,確實直接
在一些復雜布局中,經常會遇到事件沖突,事件失效等問題,這就需要我們深入理解Android事件的分發傳遞機制。最好的方法是自己寫一個demo,打印事件相關的日志查看其運行流