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 这个变量！
