1. 编译安装32位库
到android 5.0、6.0之后,由于系统分成32位和64位,对应的so也分32位和64位,分开存放。那么预置的方法就有差别,不然会导致放不到固定的目录中。
采用prebuilt 的方式,在当前so 所在目录下写 Android.mk ,内容类似如下:
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := 此so 库名(不加so后缀)
LOCAL_SRC_FILES_32 := xxx.so (表示是32 bit 的so)
LOCAL_SRC_FILES_64 := xxx.so (表示是64 bit的so)
LOCAL_MULTILIB := 32/64/BOTH (只编译32bit/64bit/both)
ALL_DEFAULT_INSTALLED_MODULES += xxx_32 (重点:添加进要安装的modules)
LOCAL_MODULE_CLASS := SHARED_LIBRARIES
LOCAL_MODULE_SUFFIX := .so
include $(BUILD_PREBUILT)
比如某个apk的so只放在system/lib中,写法:
include $(CLEAR_VARS)
LOCAL_MODULE := libtest_zzq
LOCAL_MULTILIB := 32
ALL_DEFAULT_INSTALLED_MODULES += $(LOCAL_MODULE)_32
LOCAL_MODULE_CLASS := SHARED_LIBRARIES
LOCAL_MODULE_SUFFIX := $(TARGET_SHLIB_SUFFIX)
LOCAL_SRC_FILES := $(LOCAL_MODULE)$(TARGET_SHLIB_SUFFIX)
include $(BUILD_PREBUILT)
不然就会一编译就放在lib64中,修改module path无用。
2. mk变量解析
ALL_DEFAULT_INSTALLED_MODULES : 所有默认将安装的模块
ALL_DEFAULT_INSTALLED_MODULES += $(INSTALLED_DEFAULT_PROP_TARGET)
ALL_DEFAULT_INSTALLED_MODULES += $(INSTALLED_BUILD_PROP_TARGET)
这里记录一种现象,不管 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 !
本人亲测在本mk文件中添加: ALL_DEFAULT_INSTALLED_MODULES += $(LOCAL_MODULE)_32 和在 PRODUCT_PACKAGES 中添加 Module效果相同!
PRODUCT_PACKAGES : 是BSP中的makefile指定,device定制目录下的mk文件可以修改
PRODUCT_PACKAGES 优先级大于 LOCAL_MODULE_TAGS。也就是哪怕模块Android.mk指定的TAGS与lunch type不一致,但是 PRODUCT_PACKAGES 指定要编译该模块,最终也会生成。
这里只区分对 Module 的安装控制,在4.2 中 对Module的控制级别最高的是 PRODUCT_PACKAGES 这个变量!
网友评论