I'm building a demo with bullet physics engine library for android phone(NDK).
From 2.81 version, Bullet physics engine supports arm neon optimization, but only for apple devices.
My question is how to enable arm neon for android?
The flag for arm neon is defined in btScalar.h file, code is as below:
#if (defined (__APPLE__) && (!defined (BT_USE_DOUBLE_PRECISION)))
#if defined (__i386__) || defined (__x86_64__)
#define BT_USE_SSE
#define BT_USE_SSE_IN_AP
#elif defined( __armv7__ )
#ifdef __clang__
#define BT_USE_NEON 1
#if defined BT_USE_NEON && defined (__clang__)
#include <arm_neon.h>
……
As we can see in the code, flag BT_USE_NEON is defined in the condition of it is compiled for apple device, if I drop this code and define this flag by myself, some error occurs when compiling, something like bad alignment--vld1.f32 {d26},[r4:128].
What should I do for my demo to enable arm neon?
I had the same issues few days ago:)
The problem was assembly code defined in btVector3 (vld1q_f32_aligned_postincrement). As far as I know, syntax such as [r3, :128] is used in GAS - I guess it is used in iOS environment, but not sure. Modifying it to [%1, #128] may remove those errors.
By the way, from my experience, it is usually slow than plain implementation. I think the bullet neon intrinsics are not optimized for android, as you can see an assembly code(probably optimized) on the other side(defined as APPLE).
Related
First off, my app has a file named Android.hpp. This is part of the tmxlite library. Compiling tmxlite on windows works fine. However, when I move the code to android studio and compile it (with the NDK), I get an error.
Android.hpp:
/*********************************************************************
Matt Marchant 2016
http://trederia.blogspot.com
tmxlite - Zlib license.
This software is provided 'as-is', without any express or
implied warranty. In no event will the authors be held
liable for any damages arising from the use of this software.
Permission is granted to anyone to use this software for any purpose,
including commercial applications, and to alter it and redistribute
it freely, subject to the following restrictions:
1. The origin of this software must not be misrepresented;
you must not claim that you wrote the original software.
If you use this software in a product, an acknowledgment
in the product documentation would be appreciated but
is not required.
2. Altered source versions must be plainly marked as such,
and must not be misrepresented as being the original software.
3. This notice may not be removed or altered from any
source distribution.
*********************************************************************/
#ifndef ANDROID_INC_HPP_
#define ANDROID_INC_HPP_
#ifdef __ANDROID__
#include <string>
#include <sstream>
#include <cstdlib>
namespace std
{
template <typename T>
std::string to_string(T value)
{
std::ostringstream os;
os << value;
return os.str();
}
}
#define STOI(str) std::strtol(str.c_str(), 0, 10)
#else
#define STOI(str) std::stoi(str)
#endif // __ANDROID__
#endif // ANDROID_INC_HPP_
The error:
In file included from E:\max\android_libs\tmxliteOG\tmxlite\src\FreeFuncs.cpp:28:
In file included from E:\max\android_libs\tmxliteOG\tmxlite\include\tmxlite\FreeFuncs.hpp:54:
E:\max\android_libs\tmxliteOG\tmxlite\include\tmxlite\detail\Android.hpp:37:11: error: expected '{'
Why is this happening? I was under the impression that this was how namespaces were supposed to be declared and I don't see what is wrong with it. I mean, I didn't even write the code :-).
help is greatly appreciated.
I setup conan for cross building android app on my linux, i have my_profile below for conan for this cross building, which that I run conan create . user/testing -pr=my_profile
include(default)
target_host=aarch64-linux-android
android_ndk=$HOME/android-ndk-r21
api_level=21
[settings]
arch=armv8
build_type=Release
compiler=clang
compiler.libcxx=libc++
compiler.version=9
os=Android
os.api_level=$api_level
[build_requires]
[options]
[env]
PATH=[$android_ndk/toolchains/llvm/prebuilt/linux-x86_64/bin]
CHOST=$target_host
AR=$target_host-ar
AS=$target_host-as
LD=$target_host-ld
STRIP=$target_host-strip
RANLIB=$target_host-ranlib
CC=$target_host$api_level-clang
CXX=$target_host$api_level-clang++
CONAN_MAKE_PROGRAM=$android_ndk/prebuilt/linux-x86_64/bin/make
CONAN_CMAKE_TOOLCHAIN_FILE=$android_ndk/build/cmake/android.toolchain.cmake
and I made a very simple file:
#include <fcntl.h>
int raw_fallocate(int fd, off_t length) {
if (fallocate(fd, 0, 0, length) == 0) return 0;
return -1;
}
I found that in the fcntl.h, it only defines fallocate when __ANDROID_API >=21 with #ifdef
so in my CMakeLists.txt, I need to put
target_compile_definitions(hello PRIVATE __ANDROID_API__=21) to make it compile, otherwise, the compiler will complain it cannot find definition of fallocate.
That all make sense. However, when I put this preprocessor definition, I still got a warning message saying:
In file included from <built-in>:413:
<command line>:1:9: warning: '__ANDROID_API__' macro redefined [-Wmacro-redefined]
#define __ANDROID_API__ 21
^
<built-in>:405:9: note: previous definition is here
#define __ANDROID_API__ 16
^
1 warning generated.
What I don't understand is I could not find this built-in thing..., i searched my whole android_ndk folder, and could not find where is this #define __ANDROID_API__ 16
Also I only have android_ndk v21 installed, I have no idea where this version of 16 came from.
Any idea?
This #define __ANDROID_API__ 16 comes from the NDK itself (this is the lowest supported API for android-ndk-r21. To set it to 21, you must pass ANDROID_PLATFORM parameter to CMake. Update: this is actually wrong. For ABI arm64-v8a the minimal API is 21. So, the problem is that arch=armv8 didn't work.
According to the conan instructions, set os.api_level=21 should have worked. But with this approach, you should not supply the CONAN_CMAKE_TOOLCHAIN_FILE. Update: this does not work because conan is not compatible with NDK r21.
I assume that when you do supply CONAN_CMAKE_TOOLCHAIN_FILE, all the settings, like CC= and AR= become irrelevant. Same for os.api_level and arch. But if you replace cmake with a script that calls the original cmake binary and sets the necessarycommand-line parameters, including -DANDROID_PLATFORM=android-21, you should be set. Simply add to my_profile:
CONAN_CMAKE_PROGRAM=cmake-wrapper
This approach is used in https://github.com/bincrafters/conan-android_ndk_installer package.
So I've been digging into this a little bit, and I think I found where the problem is. As #Alex Cohn said, the android ndk sets the min api level to 16 in the file
$android_ndk/build/cmake/platforms.cmake, it says on the first line set(NDK_MIN_PLATFORM_LEVEL "16"). After I change it to 21, everything works.
Now the question becomes: How can I override this value externally without touching this platforms.cmake file (I just don't want to touch files come with ndk package)? I tried to put set(NDK_MIN_PLATFORM_LEVEL "16") in my CMakelists.txt file for my project, but that does not work as I believe it is overridden later on by platforms.cmake.
Of course the second method of using conan's ndk-installer also works, and I checked the same platforms.cmake file in the installed ndk folder, it has the same value of 16. So there must be somewhere in conan settings that updated the value to 21, and I would like to learn where / how this is changed when using ndk-installer, so I can do the same for my manually installled android ndk.
I'm trying to compile libfuse with NDK, my environment:
Win10(64bit) + NDK(r14b,64bit) + libfuse(3.1.0)
Error occurs in fuse_common.h, it checks size of off_t:
$ ndk-build
[armeabi-v7a] Compile thumb : fuse <= buffer.c
In file included from jni/../../libfuse/lib/buffer.c:15:
In file included from jni/../../libfuse/lib/fuse_i.h:9:
In file included from jni/../../libfuse/include\fuse.h:19:
jni/../../libfuse/include/fuse_common.h:745:13: error: bit-field
'_fuse_off_t_must_be_64bit' has negative width (-1)
{ unsigned _fuse_off_t_must_be_64bit:((sizeof(off_t) == 8) ? 1 : -1); };
^
1 error generated.
make: *** [obj/local/armeabi-v7a/objs/fuse/__/__/libfuse/lib/buffer.o] Error 1
here's the check in fuse_common.h:
struct _fuse_off_t_must_be_64bit_dummy_struct \
{ unsigned _fuse_off_t_must_be_64bit:((sizeof(off_t) == 8) ? 1 : -1); };
I searched on google, there's _FILE_OFFSET_BITS=64 definition, which can be used to change the size of off_t, I have this defined my 'Android.mk' file:
LOCAL_CFLAGS := \
....
-D_FILE_OFFSET_BITS=64 \
....
And even add this line at the beginning of fuse_common.h
#define _FILE_OFFSET_BITS 64
Still not working, how to fix it?
Update to NDK r15c. _FILE_OFFSET_BITS=64 works from there on out.
Note that most off64_t system calls weren't available until android-21. If your minSdkVersion is set below that and you use _FILE_OFFSET_BITS=64, many functions will not be available.
NOTE Provided solution is much like workaround, see #Dan's answer for reliable and official way to get 64-bit off_t.
On Android off_t is always 32-bit length, and there is no preprocessor macro that controls its size. (Though it is true only for NDK development since modern bionic allow to configure off_t size at compile time). And because of this you cannot compile your library directly.
But I guess there is some way to workaround it. Android NDK offers non-POSIX extended type - off64_t, and also it provides a complementary set of library functions that accept it instead of off_t. They are distinguished by 64 suffix, i.e. lseek64(), mmap64(). So to make things work you may try to add global configuration header to your project:
/* let off_t to be a 64-bit length */
typedef off64_t off_t;
/* use appropriate versions of system functions */
/* list here only functions that have off_t parameters and are used by your library */
#define mmap mmap64
#define lseek lseek64
And of course keep in mind that compiled code now is linked against *64() functions instead of regular ones and any public interfaces expect off64_t instead of off_t.
I'm compiling C++ code written primarily for Mac OS, using the Android NDK and I get the following error:
- Type 'errno_t' could not be resolved
In Xcode this type is defined on OSX 10.0/usr/include/sys/_types/_errno_t.h as this:
#ifndef _ERRNO_T
#define _ERRNO_T
typedef int errno_t;
#endif /* _ERRNO_T */
Any suggestions on how to convert this to the NDK, or add compiler flags to make this compile, or where to even get the source code to define this type in my source code itself?
Thanks.
See this answer for information on errno_t.
errno_t is not a part of the C standard, and bionic doesn't support it.
The fix is simply to change all the errno_ts to be ints.
I'm using FFMPEG in an app, and I'm using the following configuration:
--extra-cflags=' -march=armv7-a -mfloat-abi=softfp -mfpu=neon'
I'm targeting 4.0+ so I believe armv7-a should be supported by most non Intel devices, and I'm sure the neon extension is supported in most devices as well, but I'm not sure how I can find that out for all 2000+ devices.
Is there a way to check in Android the processor type and extensions and/or in the Google Play Store to limit the apk to devices with certain processors?
I'll answer you last question first: you can limit the apk to devices with certain processors on the Play Store, but not with the granularity you're looking for.
In short: if you upload an apk containing native libs only for armv7-a, it won't be downloadable from an x86, mips or armv6 device. But the choice stops there: both NEON and non-NEON devices are considered armv7-a devices, so that does not solve your problem. The check has to be done at runtime.
Checking the processor architecture and capabilities in Java on Android is not easy to do: there's no API for that.
On the other side, this can easily be done using the NDK, which contains a cpufeatures module (you can find documentation on it in your NDK install folder). This module lets you:
find the architecture of the device using android_getCpuFamily()
get additional details using android_getCpuFeatures(): this is what you're looking for, as these details contain the ANDROID_CPU_ARM_FEATURE_NEON flag indicating NEON compatibility!
In practice, implementing a JNI function such as the following one and calling it from Java should do the trick:
#include <jni.h>
#include <cpu-features.h>
jboolean
Java_com_my_namespace_MyClass_isNeon
(JNIEnv *env, jclass class) {
uint64_t features = android_getCpuFeatures();
if ((android_getCpuFamily() != ANDROID_CPU_FAMILY_ARM) ||
((features & ANDROID_CPU_ARM_FEATURE_NEON) == 0 )) {
return JNI_FALSE;
}
else {
return JNI_TRUE;
}
}
it will return true if the device is ARMv7 and features NEON, false otherwise!