1

I'm testing a script to build a shared object from the command line. According to NDK Downloads, the latest download is android-ndk-r10e (I thought this was an old download).

However, when I check for android-23 I see there's nothing available:

$ echo "$ANDROID_NDK_ROOT"
/opt/android-ndk-r10e

$ ls "$ANDROID_NDK_ROOT/platforms"
android-12  android-15  android-18  android-3   android-8
android-13  android-16  android-19  android-4   android-9
android-14  android-17  android-21  android-5

Is the NDK for Android 6.0, which I believe is android-23, not available? Or maybe something else I don't quite understand.

(I'm concerned about the major version bump, and the breaking changes it encompasses, like when the rand function was changed and broke things).

Community
  • 1
  • 1
jww
  • 97,681
  • 90
  • 411
  • 885

2 Answers2

1

There are no new native APIs in 6.0, so there is no need to have that target available in the NDK - it would be identical to the ones for 5.1 and 5.0.

When building with the NDK, the target platform is picked as the latest one that actually exists prior to the one you've chosen to target (and the earliest one, for ABIs that were introduced later).

Keep in mind that "target API" behaves quite differently between Java and native code. If you build your native code with one target API level, chances are that the code won't run on older versions at all - see e.g. https://stackoverflow.com/a/27338365/3115956 and https://stackoverflow.com/a/27093163/3115956.

So unless you want to try to manually load and use new functionality on some platforms if available, you should just set the target version (APP_PLATFORM in jni/Application.mk) to the lowest version that you want your code to run on, i.e. corresponding to minSdkVersion.

Community
  • 1
  • 1
mstorsjo
  • 12,983
  • 2
  • 39
  • 62
  • 6.0 indicates a major version bump. Major version bumps means something changed in a breaking way. I expect something like a function was changed to inline. This has happened in the past; for example, AOSP changed the `rand` function ([Cannot load library: reloc_library (1285): cannot locate 'rand'](http://stackoverflow.com/q/27338318)). – jww Dec 07 '15 at 14:37
  • Yes, APP_PLATFORM [should match **minSdkVersion**](http://stackoverflow.com/questions/15872254/android-ndk-warning-app-platform-android-9-is-larger-than-androidminsdkversio). – Alex Cohn Dec 07 '15 at 19:43
  • 1
    @jww: Even if it is a major version, it still can run binaries built for older versions. In general (with very few exceptions), all android versions are backwards compatible, i.e. can run binaries built for older versions. The same goes for the `rand` function in 5.0 also; binaries built for older version keep on working just fine - the lower level function that `rand` used to call before still exists for compatbility, even if new code ends up calling something else. – mstorsjo Dec 07 '15 at 20:25
0

From my understanding, the NDK is in a separate "stream" of development with releases less or more frequent than the Android platform itself. You should be able to develop a NDK app for android-23 devices without any problem, Google probably just did not have time yet to update the NDK release for android-23.

Looking at the revisions, r10e was released a while ago, but the truth is that it is also the latest version as of today.

Sebastian Roth
  • 11,344
  • 14
  • 61
  • 110
  • Actually, we need it for a SYSROOT. For example, ***`--sysroot=/opt/android-ndk-r10e/platforms/android-23/arch-arm`***. (I think, or at least that's the way we have done it in the past). – jww Dec 07 '15 at 03:07
  • 1
    Why do you need SYSROOT to point to the highest possible platform? Generally speaking, libraries built for **android-3** run on all modern ARM devices. You must choose platform **android-21** if you want 64-bit binaries. Even now, there are some platform "numbers" (e.g. **android-10**) that were skipped because from the point of view of native library, they did not introduce new API. – Alex Cohn Dec 07 '15 at 08:35
  • @Alex - 6.0 indicates a major version bump. Major version bumps means something changed in a breaking way. I expect something like a function was changed to inline. This has happened in the past; for example, AOSP changed the `rand` function ([Cannot load library: reloc_library (1285): cannot locate 'rand'](http://stackoverflow.com/q/27338318)). – jww Dec 07 '15 at 14:35
  • 1
    Yes, this has often happened before that a binary built for platform **N** could not run on platform **N-1** and back, but never vice versa. Actually, this is ***the*** rationale for keeping older platforms in latest NDK. – Alex Cohn Dec 07 '15 at 15:18