背景
事情起因是我在学习WIFI Hal部分时，发现一个比较困惑的地方：
代码路径：hardware/interfaces/wifi/1.2/default/wifi_legacy_hal.cpp:
wifi_error WifiLegacyHal::QcAddInterface(const std::string& iface_name,
const std::string& new_ifname,
uint32_t type) {
wifi_error status = global_func_table_.wifi_add_or_remove_virtual_intf(
getIfaceHandle(iface_name),
new_ifname.c_str(), type, true);
...
}
可见global_func_table_是一个函数表，wifi_add_or_remove_virtual_intf是一个函数指针；
因此具体实现一定是通过初始化时给这个函数指针赋值来进行绑定的，于是我看到注册的逻辑是这里：
代码路径：hardware/interfaces/wifi/1.2/default/wifi_legacy_hal.cpp:
wifi_error WifiLegacyHal::initialize() {
...
wifi_error status = init_wifi_vendor_hal_func_table(&global_func_table_);
...
}
init_wifi_vendor_hal_func_table()函数实现在这里：(以QCOM平台为例，MTK平台在vendor下相应目录)
代码路径：android/hardware/qcom/wlan/qcwcn/wifi_hal/wifi_hal.cpp：
wifi_error init_wifi_vendor_hal_func_table(wifi_hal_fn *fn) {
...
fn->wifi_add_or_remove_virtual_intf = wifi_add_or_remove_virtual_intf;
...
return WIFI_SUCCESS;
}
乍一看貌似没有什么问题，但是当我看到这两个代码对应的编译产物时，我困惑了：
hardware/interfaces/wifi/1.2/default/wifi_legacy_hal.cpp会被编译成android.hardware.wifi@1.0-service-lib，随后被静态链接到android.hardware.wifi@1.0-service可执行文件中；android/hardware/qcom/wlan/qcwcn/wifi_hal/wifi_hal.cpp会被编译成libwifi-hal-qcom，这个模块可以作为静态库，也会作为共享库存在于system.img中；
在我查看android.hardware.wifi@1.0-service-lib与android.hardware.wifi@1.0-service的Android.mk时，并未发现其有依赖libwifi-hal-qcom；
并且我在全局搜索依赖了libwifi-hal-qcom的模块时，也并未发现直接依赖libwifi-hal-qcom的，且与android.hardware.wifi@1.0-service-lib或android.hardware.wifi@1.0-service有关联的模块；
分析
在全局搜索依赖了libwifi-hal-qcom的模块时，我无意间发现了一个路径下有见解使用过：
代码路径：frameworks/opt/net/wifi/libwifi_hal/Android.mk：
LIB_WIFI_HAL := libwifi-hal-qcom
而这个路径所可能代表的模块（由于使用opengrok查看，当时并不知晓真实模块名）与android.hardware.wifi@1.0-service-lib的Android.mk中依赖的一个共享库：libwifi-hal一模一样；
此时，我才打开了上面所述的frameworks/opt/net/wifi/libwifi_hal/Android.mk，看了下具体的逻辑：
# Pick a vendor provided HAL implementation library.
# ============================================================
LIB_WIFI_HAL := libwifi-hal-fallback
VENDOR_LOCAL_SHARED_LIBRARIES :=
ifeq ($(BOARD_WLAN_DEVICE), bcmdhd)
LIB_WIFI_HAL := libwifi-hal-bcm
else ifeq ($(BOARD_WLAN_DEVICE), qcwcn)
LIB_WIFI_HAL := libwifi-hal-qcom
VENDOR_LOCAL_SHARED_LIBRARIES := libcld80211
else ifeq ($(BOARD_WLAN_DEVICE), mrvl)
# this is commented because none of the nexus devices
# that sport Marvell's wifi have support for HAL
# LIB_WIFI_HAL := libwifi-hal-mrvl
else ifeq ($(BOARD_WLAN_DEVICE), MediaTek)
# support MTK WIFI HAL
LIB_WIFI_HAL := libwifi-hal-mt66xx
else ifeq ($(BOARD_WLAN_DEVICE), emulator)
LIB_WIFI_HAL := libwifi-hal-emu
endif
# The WiFi HAL that you should be linking.
# ============================================================
include $(CLEAR_VARS)
LOCAL_MODULE := libwifi-hal
...
LOCAL_EXPORT_HEADER_LIBRARY_HEADERS := libhardware_legacy_headers
LOCAL_HEADER_LIBRARIES := libhardware_legacy_headers
...
LOCAL_WHOLE_STATIC_LIBRARIES := $(LIB_WIFI_HAL) libwifi-hal-common
include $(BUILD_SHARED_LIBRARY)
可以看到这个模块正是libwifi-hal，并且根据其编译规则可以看出，其在编译之前通过BOARD_WLAN_DEVICE这个宏来判断了WIFI网卡的设备供应商，如果为qcwcn则将libwifi-hal-qcom添加到libwifi-hal模块的LOCAL_WHOLE_STATIC_LIBRARIES中；而如果是其他品牌的网卡，则添加对应的模块进来，从而做到了同一个模块对多个平台的接口抽象，保证了上下层的低耦合；
关于LOCAL_STATIC_LIBRARIES与LOCAL_WHOLE_STATIC_LIBRARIES的差异，可以参考这位朋友的介绍；
简而言之，就是通过LOCAL_WHOLE_STATIC_LIBRARIES引入的静态库，其死代码(dead code)不会在编译阶段被删除，相反，会将所有代码编译进目标中；
这是必然的，因为libwifi-hal是作为共享库被其他模块使用的，不能因为编译时没人使用就精简掉部分代码；
最后附上一张关系图：
后记
写这篇文章完全是由于在学习过程中遇到的一个小插曲，没有什么技术难度。但是为了避免后续重蹈覆辙，因此在此记下一笔。