forking from https://bugs.kde.org/show_bug.cgi?id=368529 rather than derail that bug. basically, everywhere there's currently #if...defined..._linux_android is wrong. they're either missing a case (typically amd64), or they're covering too much (it looks like whoever added arm64 just copy & pasted arm without thinking about whether the same condition is true for arm64), or they're actually Android-version-specific (i.e. the test shouldn't really "android on arm" but "android before api level 9"). there distinguish between places that should say __BIONIC__, places that should say __ANDROID__, places that should say __ANDROID_API__ <= 9, and places that genuinely have a use for breaking out the individual architectures. there's no way to express __ANDROID_API__ <= 9 within the existing system, unless you want to go further and have VGPV_arm_linux_android_9 and VGPV_arm_linux_android_10 and VGPV_arm_linux_android_11 and so on (for each of the architectures), which doesn't seem like a good choice. examples: * the ashmem ioctl support should be __ANDROID__. it's Android-specific and available on all architectures. (currently it's missing on amd64.) likewise things like the "/system/bin/sh" versus "/bin/sh" should be __ANDROID__. * the glibc __freeres support should be !defined(__BIONIC__) (or just __GLIBC__ since i'm not aware of any other libc that has a __freeres?) * the AT_FPUCW checks should just be removed when NDK r15 ships. * the "ignore zero-sized" check should explicitly check for gingerbread (which is what the comment says) with __ANDROID_API__ <= 9. likewise the Elf32_Nhdr redefinition should only happen if __ANDROID_API__ < 8 (froyo). note that these are only examples: there are about 30 such places in the code. what i'd like is just an agreement that this (using the appropriate check) is how these should be fixed, and then i can prepare a patch. (which can obsolete several of the outstanding android valgrind bugs, which are just fixing the cases that cause build breaks.)