3

I'm maintaining a (relatively) old Android application that uses NDK built library for some functions. It was originally built for NDK platform level 9.

I've been trying to modernize the build infrastructure and as part of that I'm using updated SDK and NDK releases, which dropped support for NDK platform 9 (the minimal version is now 16).

Is there any advantage to not updating the target NDK we build against, and/or not updating to the latest NDK platform level (currently 28), or is it always a good idea to update the NDK target platform level when a new NDK is released?

Guss
  • 30,470
  • 17
  • 104
  • 128

2 Answers2

3

Probably, using a "proper" NDK version is a better choice rather than stick to a too old NDK version. One of the advantages of using a "catching the time" NDK version is to adapt to the Android ABI changes as well as the improvements for compiler changes along with the Android API version evolvement. E.g.

  • GCC is no longer supported. It is removed in NDK r18.
  • Support for ARMv5 (armeabi), MIPS, and MIPS64 has been removed. Attempting to build any of these ABIs will result in an error since r17.

Also, there almost always be some bug fixes and security enhancement for each new revision. Personally I don't think there is much added value for sticking to an old version of NDK.

Is there any advantage to not updating the target NDK we build against

Maybe the advantage for not updating NDK version is to make your project be compatible with those historical devices which are going to disappear soon.

You can check the release notes for NDK to understand its evolvement. https://developer.android.com/ndk/downloads/revision_history

For your concern about armeabi-v7a, here is how it officially said https://developer.android.com/ndk/guides/abis#v7a.

-- Edit --

To clarify a few things:

  • NDK revision: each revision usually add/remove features and supported platforms. Currently the latest revision is r18b. Compared to r16b, it removes platforms of android-14 and android-15.

  • minSdkVersion: Set the minSdkVersion property in the defaultConfig or productFlavors blocks of your module-level build.gradle file. This makes sure your library is used only by apps installed on devices running an adequate version of Android.

  • ANDROID_PLATFORM CMake variable: This variable is used to specify the name of the target Android platform. For example, android-18 specifies Android 4.3 (API level 18). You have TWO options to configure the android platform your are building for, one is this CMake variable, the other one is miniSdkVersion. And also note that CMake has its own logic to choose the best platform version, NOT necessarily equal to the said minSdkVersion.

    1. If there exists a platform version for the ABI equal to minSdkVersion, CMake uses that version.
    2. Otherwise, if there exists platform versions lower than minSdkVersion for the ABI, CMake uses the highest of those platform versions. This is a reasonable choice because a missing platform version typically means that there were no changes to the native platform APIs since the previous available version.
    3. Otherwise, CMake uses the next available platform version higher than minSdkVersion.

So, when you upgrade your NDK revision, and double check your required android platform exists in the NDK platforms directory, e.g. android-ndk-r16b/platforms.

References: https://developer.android.com/ndk/guides/cmake

shizhen
  • 12,251
  • 9
  • 52
  • 88
  • Regarding: "compatible with those historical devices which are going to disappear soon" - do you mean the obsolete build architectures, not operating system versions, right? I'm still supposed to support older OS versions (at least Lollipop is still a requirement), so I want to be absolutely sure that using a newer NDK will not prevent the application from being successfully installed and run on an older operating system (install on a device running on a supported architecture, such as ARMv7). – Guss Nov 26 '18 at 09:15
  • Yes, for example using newer NDK won't build armeabi libs and will cause UnsatisfiedLinkError if you miss this abi. But, you really don't need to maintain such an older NDK version, i.e. r9. For the armeabi-v7a, it will still be there for some time, even you use the latest NDK, you are still able to get it compiled and run well on your older devices. – shizhen Nov 26 '18 at 09:25
  • While this is good advice, it doesn't answer the question. The question is not whether or not it's advisable to update the NDK, but whether it's advisable to update your NDK *API level*. These two things are not the same. – Dan Albert Nov 27 '18 at 22:44
2

The only disadvantage to increasing your NDK API level is that this is equivalent to your minSdkVersion. If you increase your minSdkVersion, you're dropping support for older devices.

The NDK itself only drops support for API levels only when they have a trivial number of users. API levels 16 and up account for over 99% of all users. If for some reason your application's usage numbers show a significant number of users on Gingerbread or ICS, you'll need to stick to an older NDK to keep supporting those devices.

The advantage to upgrading your minSdkVersion is that you have access to more APIs and have fewer configurations to test against (given that the older devices will likely have more problems, that could be a significant reduction in required engineering effort).

The right API level will vary by app (although amusingly there's a twitter account that gives a reasonable suggestion). Check your usage numbers and see where your users are and balance that against the difficulty imposed by supporting older releases. If your application is something like a high fidelity game, odds are Jelly Bean devices won't be able to run your app with any reasonable performance anyway, so there's no sense in supporting those devices.

Dan Albert
  • 10,079
  • 2
  • 36
  • 79