APP_PLATFORM，android：minSdkVersion和android：targetSdkVersion之间是什么关系？

Question

我正在开发使用NDK功能的Android应用程序。 我的应用在AndroidManifest.xml定义了android:minSdkVersion和android:targetSdkVersion ，在jni / Application.mk中定义了APP_PLATFORM 。

我目前的理解是android:minSdkVersion降低了支持的最低操作系统版本， android:targetSdkVersion声明了要链接的Java库版本，而APP_PLATFORM声明了要链接的C ++库。

两个问题：

1. 我的理解正确吗？

2. APP_PLATFORM可以大于android:minSdkVersion吗？ 还是必须彼此平等？

我提出这个问题的原因：我希望我的应用程序可用于API> = 10的设备 ，但是我需要使用NDK中的platforms\\android-13文件夹中定义的NDK函数（例如AMotionEvent_getAxisValue ）。 所以我用android:minSdkVersion=10和APP_PLATFORM=13 。 项目可以成功编译，但是可以在API 10-12设备上运行吗？

Answer 1

这个答案汇集了来自许多优秀网站的难以找到但重要的信息，以及关于这个文档不足的NDK主题的stackoverflow答案/评论：

避免崩溃：NDK版本， minSdKVersion ， targetSdkVersion和APP_PLATFORM （在project.properties中）

短版

为了防止您的本机Android应用神秘地崩溃在旧的客户设备上，简单的答案是使NDK APP_PLATFORM （位于project.properties或Application.mk ）与minSdkVersion （位于AndroidManifest.xml ）相同。

但是根据您使用的NDK功能，这样做可能会严重限制可以下载您的应用程序的客户群。

要找出原因，以及是否还有其他选择，请继续阅读...

四个不同的概念

• NDK版本 （例如r10e，r13b）：这是您从Google下载的Android NDK版本（tar / zip文件）的版本。 这是所有NDK版本

• minSdkVersion （例如15,19,21）是您在AndroidManifest.xml中的<manifest>元素下的<manifest> <uses-sdk>元素中进行的设置。 此设置会影响NDK（本机）和Java开发。

• targetSdkVersion （例如15,19,21）是您在AndroidManifest.xml中的<manifest>元素下的<manifest> <uses-sdk>元素中进行的另一种设置。 此设置仅影响Java开发。

• APP_PLATFORM （例如15,19,21）是您在本机NDK项目中进行的设置。 通常，此设置位于project.properties根目录下的project.properties文件中，作为target=行末尾的最后一个数字，例如，对于21级， target=Google Inc.:Google APIs:21 21（通常采用以下方式“ 21”可以通过-t/--target选项到达android create project或android update project命令的命令行来实现。 您还可以通过将APP_PLATFORM := android-21放入Application.mk文件来进行此设置。

其中三个概念使用API​​级别编号

minSdkVersion ， targetSdkVersion和APP_PLATFORM对API级别使用Android的一致编号方案：

点击此处查看Google的API级别图表

如您所见，级别大致与Android版本相对应，但与Android版本的数量甚至没有远程匹配（这太容易了）。 例如，API级别10对应于Android OS 2.3.3和2.3.4。

可爱的代号，例如“ Lollipop”和“ Nougat”，比API版本的粒度更粗。 例如，几个API版本（21和22）是“棒棒糖”

这些相同的API版本号由Java Build.VERSION_CODES类型编码：

点击此处查看Build.VERSION_CODES

例如，级别22为LOLLIPOP_MR1

并非每个概念都有每个数字。 例如，您可能希望支持API级别10，但是没有APP_PLATFORM 10，因此您将返回到最后一个可用的APP_PLATFORM和APP_PLATFORM 9。

单击此处以在野外安装的基础中查看API版本的分发

什么是minSdkVersion ？

到目前为止，此设置最容易理解。 当您将minSdkVersion设置为21（对应于Android OS 5.0）时，这意味着Google Play商店只会宣传您的应用程序支持Android OS 5.0及更高版本，并且Android将阻止用户安装其应用程序（如果他们的Android设备）低于安装的Android OS 5.0。

因此， minSdkVersion是您支持的最低操作系统。 漂亮又简单。

显然，此设置对Java和C代码都有影响：您希望将其设置为代码的两个部分都可以支持的最低OS版本。

targetSdkVersion和APP_PLATFORM必须大于或等于minSdkVersion 。

什么是targetSdkVersion ？

此设置仅在Android Java世界中有效（对您的C NDK代码无效）。 它在Android Java世界中APP_PLATFORM了与Android C NDK世界中的APP_PLATFORM相似的目的。

有时，您希望您的应用程序支持较旧的设备，但也使用仅在较新的Java API版本上可用的新功能。

例如，Android添加了一个漂亮的Java VoiceInteractor API，该API仅在API 23（Android 6.0）或更高版本中受支持。 如果您的客户有新设备，但您的​​应用仍在旧设备上运行，则可能需要支持VoiceInteractor 。

通过将targetSdkVersion设置为23，您可以与Android签订一个简单的合同：

• Android同意让您的应用程序代码访问仅API-23的Java功能（例如VoiceInteractor
• 作为回报，您同意在运行时在Java代码中检查该功能是否在客户的设备上可用，然后再调用它（否则您的应用程序将崩溃）。

该合同之所以有效，是因为在Java中，只要您的代码中引用了客户设备上可能不存在的类/方法（只要您不调用它们），就可以。

该合同适用于minSdkVersion直至targetSdkVersion包括您）添加的所有Android Java功能。

除了允许您访问某些新的Java API外， targetSdkVersion设置还启用或禁用某些有据可查的兼容性行为：

单击此处以查看每个目标targetSdkVersion哪些行为更改

这些有据可查的变更也构成了一种合同。 例如，围绕Android 4，Google将其Android设备设计从原来的专用菜单按钮转移到了屏幕上的操作栏。 如果您的应用程序的targetSdkVersion低于14（Android 4.0.1），则Google会在屏幕上放置一个软件菜单按钮，以确保即使设备没有专用的菜单按钮，您的应用程序仍可以正常工作。 但是，通过在构建时选择大于或等于14的targetSdkVersion ，可以向Google保证您没有菜单或使用操作栏，因此Google不再设置软件菜单按钮。

什么是APP_PLATFORM ？

APP_PLATFORM在C NDK世界中执行与targetSdkVersion在Java世界中执行的功能相似的功能。

但是，可悲的是，由于C语言的局限性和Google的不良行为的共同作用， APP_PLATFORM显然更加危险，并且坦率地说几乎无法使用。

让我们从头开始...

APP_PLATFORM是仅NDK的设置，它告诉build-ndk工具在NDK的哪个子目录中查找某些键，包括文件和库，这些文件和库统称为NDK“平台”。 每个NDK发行版（我们开发人员从Google下载的每个NDK tar / zip）都包含多个平台。

例如，如果将APP_PLATFORM设置为android-21 ， build-ndk将显示在：

$(ndk_directory)/platforms/android-21/arch-$(architecture)/usr/include
$(ndk_directory)/platforms/android-21/arch-$(architecture)/usr/lib

用于包含文件和库。

如果您仅通过从Google的NDK下载网站下载zip / tar安装了NDK，则$(ndk_directory)就是您提取文件的目录。

如果先通过下载Android（Java）SDK然后运行Android SDK Manager来安装NDK，然后运行Android SDK Manager来安装“ NDK”项，则$（ndk_directory）为$(sdk_directory)/ndk-bundle ，其中$(sdk_directory)为无论您的SDK安装在哪里。

$(architecture)是arm ， arm64 ， x86等。

什么是“平台”？

$(ndk_directory)/platforms/android-XX目录包含两个非常重要的内容：

• 您所有的C库都调用，例如fopen() ， atof() ， sprintf()等。Android上的C库称为“仿生”。
• 特定于Android的NDK调用/类型/定义，例如AInputQueue和EGLContext

在不同的APP_PLATFORM级别有哪些变化？

在每个android-XX版本中，Google都会向NDK添加更多调用。 例如，

• APP_PLATFORM API级别9添加了非常有用的NativeActivity
• APP_PLATFORM API级别18添加了OpenGL ES 3.0

一些APP_PLATFORM版本还会将调用添加到C库，和/或“修复”缺少的内容（例如，在APP_PLATFORM 21中添加了令牌PTHREAD_KEYS_MAX ）。

单击此处以阅读Google关于每个APP_PLATFORM级别更改内容的不完整文档

到目前为止，这类似于Java世界。 没有人期望Google或任何其他操作系统供应商在旧设备上提供所有新功能，特别是当这些功能依赖于仅在较新设备上找到的硬件（例如，更快的处理器，新的摄像头功能，新的音频功能）时。

但是Google的NDK团队做了一件淘气的事情，而Java团队却没有。

在某些APP_PLATFORM版本中，Google做出了无偿的， APP_PLATFORM API更改，这些更改不能被上述任何合法参数所原谅 。

这些是Android Java开发人员永远不会接受的API重大更改类型。 例如，谷歌有

• 重命名的C库函数和
• 将C库函数从内联更改为未内联

最严重的情况是APP_PLATFORM 21，其中Google进行了许多重大更改，这些更改产生了非常多的APP_PLATFORM问题（ 此处和以下更多示例）。

但是以前的APP_PLATFORM也有所变化（例如API 19中的 signal() ）。

在21之后， APP_PLATFORM甚至还有一些重大更改，例如APP_PLATFORM 24（例如，正如Karu在此问题的评论中提到的那样， std::vector::resize ）。

因此，这显然是一个不良的Google习惯，这种习惯将持续下去。

为什么这些更改会使我的应用在旧设备上崩溃？

要了解为什么这些顽皮的更改会带来问题，请记住Android上的C库是共享库 ，这意味着非内联，非宏调用（如sprintf()的实现未编译到您的程序中，而是存在于程序中。测试设备和每个客户设备上的C库。

因此，开发环境中的API版本并不重要。 同样重要的是，您的应用可能会在运行的每台设备上使用C库的API版本。

假设您的应用程序调用atof()并使用APP_PLATFORM 21构建应用程序，然后在运行Android 5或更高版本（API版本21或更高版本）的现代测试设备上对其进行测试。 一切看起来还好。

然后，您发布应用程序，突然发现大量使用Android OS 4.4及更早版本（API版本低于21）的客户报告您的应用程序在其设备上崩溃。

这是怎么回事？

在APP_PLATFORM 21（Android 5）中， atof()是常规函数（不是inline函数，不是宏）。 因此，应用程序的本机部分（ ndk-build将创建的myapp.so文件，以及使用System.loadLibrary("myapp")从Java代码加载的myapp.so文件）将被标记为依赖于称为C库中的atof（）。

在给定设备上运行应用程序时，Android将打开myapp.so ，查看对atof()的依赖关系，并在该设备上的C库中找到atof() 。

但是令人惊讶的是，在早于21的APP_PLATFORM ， atof()是平台头文件中的inline函数，这意味着：

• 其实现（其定义，其代码，其主体）位于头文件中，并在构建应用程序时被编译到应用程序中
• 在API <21的任何客户设备（运行Android <5的任何客户设备atof()上，C库中没有atof()实现。 因为atof()在当时是内联的，所以永远都不需要。

因此，当您在运行API版本<21（Android OS <5）的设备上运行应用程序时，Java调用System.loadLibrary("myapp")失败，因为运行时加载程序无法找到myapp.so所需的所有符号。 Android知道您的myapp.so需要atof()但无法在设备的C库中找到atof() 。 崩溃

这个atof()示例只是Google无耻地称为WorkingAsIntended的许多未记录或几乎未记录的重大更改之一 。 除了atof() ，您还可以找到大量其他起因相同的其他stackoverflow项目（例如，使用mkfifo()甚至令人难以置信的是rand() ）

我该如何解决？

在上面的atof()示例中，您可能对自己说：“好的，如果旧设备上没有atof() ，我将在我的应用程序中提供一个并发布新的应用程序版本。”

实际上，这是可行的。

但是，当您意识到对一个更重要的问题没有答案时，您会感到肚子下沉：

我怎么知道发生了什么变化，哪些旧设备会受到影响？

这才是真正的踢脚。 你不能

与Android Java API不同，Google会仔细维护与旧API的向后兼容性，从而清楚地记录键入到targetSdkVersion参数的任何行为更改，而对于Android NDK APP_PLATFORM级别则没有此类文档 。

与Java API一样，您可以查找NDK调用并找出支持该调用的最早的API版本（最早的客户Android OS）。

但是，与带有targetSdkVersion的Java API targetSdkVersion ，当您更改NDK APP_PLATFORM级别时，将找不到任何Google文档，该文档告诉您：

• 存在哪些可能会在旧设备上破坏您的应用程序的API更改（甚至可能是C库API更改）。 例如，一系列功能，如atof() ， mkfifo()和rand() ，您需要为较旧的设备提供自己的实现
• 如果不提供这些重新实现的例程，将会对您现在可以在您的应用中支持的最低Android OS产生什么影响

简而言之，Google不会告诉您每个APP_PLATFORM支持的最早的Android版本。

如果您碰巧有很多旧设备在闲逛，并且有很多时间，则可以在每个可能的旧Android版本上尝试使用您的应用，并查看由于缺少C库符号而崩溃的情况，并为未找到的功能提供自定义实现。 当然，这只是测试的第一步：实际上，Google可以在符号仍然存在的地方进行重大更改（因此不会崩溃），但是调用的行为有所不同。 在Java级别上，这永远不会被接受，但是由于某种原因，谷歌觉得有权使用NDK。

当然，没有人有时间这样做，开发人员也不必这样做。

如此有效的意思是，这就是Google NDK的官方政策：

每次增加项目的APP_PLATFORM时，您都可以访问新的API，但是您也将获得一些重大更改，这些更改将导致您的应用在某些旧设备上崩溃。 哦，我们不会为您提供这些更改的特定列表。 我们也不会告诉您仍然可以保证您的应用可以运行的最早的Android OS版本。

实际上， 这意味着：

每次增加项目的APP_PLATFORM时，都必须将minSdkVersion设置为等于APP_PLATFORM ，以防止您的应用在旧设备上运行 。 否则，您的应用可能会在某些较旧的设备上崩溃。

很难高估这是多么悲惨。

Google有效地告诉您“要使用NDK的新功能，您必须放弃所有使用旧设备的客户，并放弃对使用旧设备的客户的未来销售。”

为了通过实际示例具体说明这一悲剧，请注意Google在API Level 21（Android OS 5.0）中添加了对OpenGL ES 3.1的支持。 假设您想在新设备上支持新的OpenGL ES 3.1功能，但在旧设备上仍支持OpenGL ES 3.0（ API级别18（Android OS 4.3） ）和OpenGL ES 2.0（ API级别5（Android OS 2.0） ）。 这是一种非常可能的情况，因为（与从OpenGL ES 1到2的过渡不同），在OpenGL ES 2到3中的更改非常小且是累积的。

为了使用Google荒唐的NDK策略从您的应用程序中支持ES 3.1，您必须放弃对所有Android 5以下设备的支持。

有解决方法吗？

有点，但不太可能有任何开发人员有时间陪伴他们。

上面提到了第一个解决方法：在每个可能的旧Android版本上仔细测试您的应用程序，不仅针对未找到符号的崩溃，而且还更改行为。

第二种解决方法是，从理论上讲，您可以将不同版本的NDK代码“运送”给具有不同API版本的客户。

最简单的方法可能是在NDK级别执行此操作。 例如，您可以在NDK构建中构建多个myapp.so ，每个都在Application.mk中具有不同的APP_PLATFORM值，然后将它们全部捆绑到您的应用.apk 。 然后从Java代码中，可以根据客户设备的API版本，将System.LoadLibrary()不同的.so 。

这在结构上与NDK开发人员当前为每种体系结构捆绑多个NDK版本（例如armeabi ， armeabi-v7a ， mips ， x86 ） armeabi-v7a 。

但是，存在巨大的实际差异：与ndk-build或多或少免费提供多个ABI而又不浪费开发人员时间的开发人员不同，开发人员将不得不花费大量时间破解NDK和Java构建脚本来创建和分发多个APP_PLATFORM .so版本。 然后，每次开发人员更改C代码时，他们都必须仔细考虑在每个API版本中调用的每个函数的行为（如果存在）。 这种工作是完全可以预期的，并且对于与新硬件功能直接相关的调用是可以接受的，但是Android的NDK团队让我们对诸如atof()和rand()类的调用执行此操作是完全荒谬的。

第三种解决方法是我怀疑大多数开发人员都会采用的解决方法：修复生气的客户报告问题后，再祈祷不会再发生此类崩溃（或导致客户对其应用程序进行不良评价，并且永远不会将问题报告给开发人员） 。

dlsym（）是一种非解决方法

您可以将C NDK APP_PLATFORM兼容性问题与更加干净的Java targetSdkVersion然后说

“嘿，如果我可以设置targetSdkVersion然后检查在Java运行时的新功能，我不能设置APP_PLATFORM并检查位于C运行时的新功能？”

好吧，不。

第一个问题是，与Java不同，为了在C中执行此操作，您必须避免甚至在代码中引用例程。 然后，您必须使用dlopen()打开C库，并尝试使用dlsym()提取所需的例程。 即使找到C库，我们也不要讨论供应商设备依赖性的可能性。 加上由于Android重大更改而带来的复杂性，某些例程已更改了名称，因此即使您查找的名称也必须取决于设备的API版本。

但是，第二个更严重的问题是，有时您不是打电话的那个人。 正如我们将在下面解释的那样，编译器可能会插入对Google中断的例程的调用，例如stpcpy()和std::vector::resize ，并且您无法用对dlopen()调用来替换这些调用。和dlsym() 。 阻止编译器调用它们的唯一方法是减少APP_PLATFORM ，这APP_PLATFORM在兼容设备上访问新功能的目的。

更改呼叫清单会有所帮助吗？

令人惊讶的是，没有。 问题比听起来更糟。

假设我们假设Google 确实发布了所有程序的完整列表，例如atof()并进行了重大更改。 您可以只扫描代码中的这些例程，如果不调用它们，就很安全，对吗？

错误。

事实证明，有时出血的编译器会调用这些突破更改例程，而实际上它们不会出现在您的代码中：

• 如果您构建到APP_PLATFORM 21（Android 5）并在较旧的设备（Android <5）上运行，您可能会惊讶地发现崩溃，因为较旧的设备无法找到您永远不会调用的stpcpy() 。 事实证明，编译器会在您的代码中注意到某些stpcpy()的模式，并将其替换为对stpcpy()的调用！ 这可以在许多stackoverflow示例中看到： 示例1 示例2 示例3 示例4 。 如果您尝试自己实现stpcpy()以实现向后兼容性，则将获得无限循环，除非您足够聪明地以非stpcpy()方式实现它！ 疯狂。
• 如果您构建到APP_PLATFORM 24，您将遇到与std::vector::resize类似的问题，就像Karu在对此问题的评论中提到的那样。

在这两种情况下，编译器都决定可以插入这些调用，因为它检查了您正在使用的包含文件集-您的APP_PLATFORM并确定了这些调用可用。 在不失去对要在新设备上使用的新例程的访问权限的情况下，您不能减少APP_PLATFORM 。 赶上22。

Google如何摆脱这种情况？

综上所述，Google有效的NDK政策为：

每次增加项目的APP_PLATFORM时，都必须将minSdkVersion设置为等于APP_PLATFORM ，以防止您的应用程序在旧设备上运行 ，除非您愿意在旧设备上进行大量详尽的测试或祈祷。

实际上，我从来没有找到过官方的Google政策声明。 Google的官方文档说的恰恰相反。 特别是， 谷歌官方NDK级别文档中的这段话完全是胡说八道：

给定Android API级别的NDK头文件和库的每个新版本都是累积的； 如果您在构建应用时使用最新发布的标头，则几乎总是安全的。 例如，您可以将Android API级别21的NDK标头用于定位API级别16的应用程序。但是，这样做会增加APK的占用空间。

实际上，事实恰恰相反：您必须使用API​​级别16标头来定位API级别16设备，否则，如果您使用诸如atof()类的大量API之一atof()记录重大更改，则应用程序将崩溃。

我们从Google获得的最大帮助是一个神秘的NDK构建WARNING: APP_PLATFORM android-XX is larger than android:minSdkVersion没有任何我可以找到的相关文档。

我希望这个答案对开发人员大开眼界，并且对开发人员有所帮助，也许随着我们在开发人员中的知名度提高，它可能会激发Google NDK开发人员像向后兼容Java Java开发人员一样。

参考：上面的文本中插入了许多指向其他stackoverflow答案和其他网页的链接。

Answer 2

1. android:minSdkVersion是您的应用程序期望的最低操作系统版本。

2. android:targetSdkVersion本质上是您设计应用程序可以使用的最高操作系统版本。 这是一个如何工作的示例。 假设您使用API​​ 19对应用程序进行了良好的测试，然后使用android:targetSdkVersion = 19发布了应用程序。 然后Google决定发布API 20并更改某些API的行为，但他们不想更改旧应用程序的行为（以防止破坏它们）。 因此，当您的应用程序启动时，Android会发现您的应用程序具有targetSdkVersion = 19，因此它具有旧的API行为，但是如果其他一些应用程序将targetSdkVersion = 20，则Android将为其赋予新的API行为。

3. APP_PLATFORM是NDK用来编译本机代码的本APP_PLATFORM和库的版本。 如果将APP_PLATFORM设置为特定值，并且使用仅在该平台版本中可用的API，则您的应用将无法在旧平台上正常运行。 因此APP_PLATFORM是最小值。 解决方案是使用较低的值而不使用那些较新的API，或者编写在运行时决定是否调用新API的代码（可能使用dlopen / dlsym ）。

通常来说，使用比android:minSdkVersion更新的APP_PLATFORM值似乎没有任何意义，除非您做了一些特殊的操作（例如注意不要通过在运行时检查版本来调用新的API，并确保不要链接到新的API，而是使用dlopen / dlsym ）。

因此，如果您使用APP_PLATFORM=13并调用AMotionEvent_getAxisValue （在较早的平台头文件中不存在，这意味着它在较早的平台上无法在运行时使用），则您的应用程序将无法在API <13的设备上运行。如果AMotionEvent_getAxisValue实际上在较早版本上可用，但是它不在头文件/库文件中，或者未在文档中记录。 但是我不知道特定的API是否会出现这种情况（基本上，这将需要更多的研究和风险分析，以确定是否要依赖不受支持的内容）。

Answer 3

您对最低要求是正确的。 我不确定目标应该代表什么，我认为它提供了目标SDK的某些功能，但也确保该应用程序将以最低的SDK运行。