mason icon indicating copy to clipboard operation
mason copied to clipboard

Rename MASON_ANDROID_ABI values to match official ABI names

Open jfirebaugh opened this issue 8 years ago • 5 comments

MASON_ANDROID_ABI currently uses a different naming convention than the official naming convention for Android ABIs, which is needlessly confusing. The values should just be the same as the official names.

Concretely, this means the following MASON_ANDROID_ABI values should be renamed:

  • arm-v5armeabi
  • arm-v7armeabi-v7a
  • arm-v8arm64-v8a
  • x86-64x86_64
  • mips-64mips64

x86 and mips are already the same as the official names.

cc @kkaefer @bleege

jfirebaugh avatar Mar 10 '16 20:03 jfirebaugh

Agreed, let's do this. Should we retain the MASON_ANDROID_PLATFORM, which is currently 9 or 21 (for 64 bit), or just generally compile against the most recent SDK, and drop it? Retaining it would mean that the MASON_PLATFORM_VERSION would be armeabi-9 or something like that to indicate the Android API level.

kkaefer avatar Mar 11 '16 10:03 kkaefer

I'm fine either way. There was some discussion in chat about whether 9 and 21 were important to mapbox-gl-native in some way, without a clear answer. The Android documentation says:

Each new release of NDK headers and libraries for a given Android API level is cumulative; you are nearly always safe if you use the most recently released headers when building your app. For example, you can use the NDK headers for Android API level 21 for an app targeting API level 16. By doing so, however, you increase your APK's footprint.

jfirebaugh avatar Mar 11 '16 17:03 jfirebaugh

you increase your APK's footprint.

Wondering what that means; are they referring to binary size? If so, it's unclear to me why that would increase binary size in any significant way...

kkaefer avatar Mar 14 '16 10:03 kkaefer

Wondering what that means; are they referring to binary size?

Yes this is the binary size, I'm guessing that extra methods will be added to provide backwards compatibility but I'm also not sure if these changes will have significant impact, worth doing a test around.

tobrun avatar Mar 14 '16 12:03 tobrun

FWIW... we always use the latest Android SDK version on the Java side for compilation. This keeps things closer to what Google is pushing. The current version is 23. On a related note, the Android Minimum that in use is 15.

bleege avatar Mar 14 '16 20:03 bleege