Android 升级NDK版本时是否应重建所有LIB?

Android 升级NDK版本时是否应重建所有LIB?,android,c++,android-ndk,Android,C++,Android Ndk,在我的android项目中有许多共享库(*.so)。其中一些是由其他人构建的,我没有源代码 我正在使用NDK r10e,我想将NDK版本升级到r13b 如果我不更改makefile,只需使用NDK-r13b构建部分共享lib,其他使用NDK-r10e构建的lib不会更改。android程序的功能有问题吗 NDK-r10e use clang-3.5 NDK-r13b use clang-3.8 以下配置相同: APP_ABI := armeabi-v7a APP_PLATFORM := and

在我的android项目中有许多共享库(*.so)。其中一些是由其他人构建的,我没有源代码

我正在使用NDK r10e,我想将NDK版本升级到r13b

如果我不更改makefile,只需使用NDK-r13b构建部分共享lib,其他使用NDK-r10e构建的lib不会更改。android程序的功能有问题吗

NDK-r10e use clang-3.5
NDK-r13b use clang-3.8
以下配置相同:

APP_ABI := armeabi-v7a
APP_PLATFORM := android-19
APP_STL := gnustl_shared

这通常是一个好主意,但并不总是必需的。我们试图保持NDK版本之间的兼容性,因为,是的,当您没有依赖项的源代码时,跨越兼容性边界是很困难的,但有时在不破坏兼容性的情况下无法修复bug

这通常是一个好主意,因为这样做的惊喜最少。我们只测试过NDK的一个版本。它还将为您节省大量时间,以便在出现兼容性中断时找出问题所在

以下是几个可能出错的例子(绝非完整列表):

NDK的公共API表面已随时间发生变化。API仍然存在于设备上,以便遗留应用程序继续工作,但有时会从NDK中删除API,以便新应用程序不使用它们(可能会发生这种情况的原因有很多)。在这些情况下,使用删除符号的旧库将无法使用没有这些API的NDK链接到新库/可执行文件(这实际上取决于链接器的行为;对于静态库总是如此,我认为对于共享库只有arm64)


特别是从r10升级时,libc++中出现了ABI中断(需要避免与系统的恶劣交互),这意味着使用r10构建的库和使用r11+构建的库不兼容。您使用的是gnustl,所以这个问题不会影响您,但对于其他人来说,值得一提。

根据一般经验,应用程序的所有部分(包括库)都应该使用完全相同的编译器版本构建。