Android build system, NEON and non-NEON builds

Question

I want to build my library for armv6, and there is some neon code that I enable at runtime if the device supports it. The neon code uses neon intrinsics, and to be able to c

Answer 1

Using this link http://www.kandroid.org/ndk/docs/CPU-ARM-NEON.html

You can selectively build certain source files with NEON support using the .neon file suffix. Hopefully you can work out whether or not this applies to the ABI selection...

You may be able to put your NEON code path in one file, and using the make file conditional as shown above select to build the correct file based on which ABI you are targeting

Answer 2

If you put the NEON code in a separate module (static library or shared library), you can manually tune CFLAGS for that module in your Android.mk to your wanting.

If you have C files that use #ifdef __ARM_NEON__ around intrinsics, your best choice would be to put these files in shared libraries - one compiled for v6, another for neon.

I usually load such "supplimentary" libraries directly from Java, so that the main native code does not care about these changes at all.

---

Update: here is a simple example that uses static library:

Android.mk

LOCAL_PATH:= $(call my-dir)

include $(CLEAR_VARS)
LOCAL_MODULE    := neon_utils
LOCAL_SRC_FILES := neon_add.c
LOCAL_CFLAGS += -mfloat-abi=softfp -mfpu=neon -march=armv7
include $(BUILD_STATIC_LIBRARY)

NDK_PATH:=$(call my-dir)/../..

include $(CLEAR_VARS)
LOCAL_MODULE    := test_conditional_load
LOCAL_C_INCLUDES := $(NDK_PATH)/sources/cpufeatures
LOCAL_SRC_FILES := main.c
LOCAL_STATIC_LIBRARIES  :=  neon_utils cpufeatures

include $(BUILD_EXECUTABLE)

include $(NDK_PATH)/sources/cpufeatures/Android.mk

main.c

#include <stdio.h>
#include <cpu-features.h>

void neon_add(int32_t * ptr);

int main()
{
    int32_t int32_4[] = {2,3,4,5};

    if (android_getCpuFeatures() & ANDROID_CPU_ARM_FEATURE_NEON)
    {
        neon_add(int32_4);
        printf("neon\n");
    }
    else
    {
        printf("not neon\n");
    }
    printf("values = %d, %d, %d, %d\n", int32_4[0], int32_4[1], int32_4[2], int32_4[3]);
    return 0;
}

neon_add.c

#include <arm_neon.h>

void neon_add(int32_t * ptr)
{
    int32x4_t vin = vld1q_s32(ptr);
    int32x4_t vout = vaddq_s32(vin, vin);
    vst1q_s32(ptr, vout);
}

Answer 3

This snippet from the documentation will probably help:

   # define a static library containing our NEON code
   ifeq ($(TARGET_ARCH_ABI),armeabi-v7a)
      include $(CLEAR_VARS)
      LOCAL_MODULE    := mylib-neon
      LOCAL_SRC_FILES := mylib-neon.c
      LOCAL_ARM_NEON  := true
      include $(BUILD_STATIC_LIBRARY)
   endif # TARGET_ARCH_ABI == armeabi-v7a

That only compiles mylib-neon when using armeabi-v7a even if you use the same Android.mk file for various ABIs. For armeabi v6 it will skip over it completely.

Answer 4

I have recently found another way to work around the limitations of NDK. My case was not related to NEON, but for you the same hack could do the job.

The trick is to use the existing "tag" mechanism of NDK to specify special CFLAGS for a bunch of files. This is how you do it:

First, list the neon-specific sources. You cannot use the .neon suffix as described in docs/CPU-ARM-NEON.html because build-binary.mk will find that you are not targeting armeabi-v7a. I use the following technique:

LOCAL_NEON_SRC_FILES := imgproc/neon_utils.c \
                        videoproc/usingneon.cpp
LOCAL_SRC_FILES := main.c \
                   imgproc/img.c \
                   videoproc/video.cpp

LOCAL_SRC_FILES += $(LOCAL_NEON_SRC_FILES)

Now, define the CFLAGS for NEON:

LOCAL_NEON_CFLAGS := -mfloat-abi=softfp -mfpu=neon -march=armv7

Finally, add the following magical line to your Android.mk:

TARGET-process-src-files-tags += $(call add-src-files-target-cflags, $(LOCAL_NEON_SRC_FILES), $(LOCAL_NEON_CFLAGS))

If you have more than one binary to build, you will probably want $(LOCAL_NEON_SRC_FILES) to be reset by

include $(CLEAR_VARS)

For this, add the following to your Android.mk or to Application.mk:

modules-LOCALS += NEON_SRC_FILES

Note: I have not tried this magic for NEON, I needed it for entirely different purposes. You may need some adaptations to achieve the desired compilation options for your files, and for your project. I am using NDK r.8b, and I did not check if this would work on earlier (or later) versions.

Answer 5

If you're looking for a simpler implementation:

First, ensure all NEON-capable code is conditionally compiled only for ABI armeabi-v7a, and additionally will only be executed if at runtime it's running on an ARMv7 implementation which includes NEON:

/* 
   bar_better_on_neon.c
 */

#ifdef HAVE_ARMV7
#  include <arm_neon.h>
#  ifdef ANDROID
#    include "cpu-features.h"
#  endif
#endif

#ifdef HAVE_ARMV7 
static int check_for_neon(void)
{
#  ifdef ANDROID
    // Not all Android devices with ARMv7 are guaranteed to have NEON, so check.
    uint64_t features = android_getCpuFeatures();
    return (features & ANDROID_CPU_ARM_FEATURE_ARMv7) && (features & ANDROID_CPU_ARM_FEATURE_NEON);
#  elif defined(__APPLE__)
    return 1;
#  else
    return 0;
#  endif
}
#endif

void bar(void)
{
#ifdef HAVE_ARMV7
    if (check_for_neon()) {

        /* here put neon code */

    } else {
#endif

        /* here put non-neon code */

#ifdef HAVE_ARMV7
    }
#endif
}

Here, the check_for_neon() uses the NDK's cpufeatures library. Then, in your Android.mk file:

LOCAL_SRC_FILES := foo.c bar_better_on_neon.c
ifeq ($(TARGET_ARCH_ABI),armeabi-v7a)
  # Compile the one file in NEON mode.
  LOCAL_SRC_FILES := $(subst bar_better_on_neon.c, bar_better_on_neon.c.neon,$(LOCAL_SRC_FILES))
  LOCAL_CFLAGS += -DHAVE_ARMV7=1
endif

Answer 6

Yeah, in your Application.mk file add:

APP_ABI := armeabi armeabi-v7a
LOCAL_ARM_NEON := true

The NDK will not add NEON support to armeabi libs as they are mutually exclusive, simply adding those lines and compiling as you normally do will produce two seperate so files. You include them both in your apk in the directory structure they were exported to and the device will load the neon one automatically if it is supported.