Configure: android-arm facelift.

    },

#### Android: linux-* but without pointers to headers and libs.

    #

    # It takes pair of prior-set environment variables to make it work:

    #

    # CROSS_SYSROOT=/some/where/android-ndk-<ver>/platforms/android-<apiver>/arch-<

    # CROSS_COMPILE=<prefix>

    #

    # As well as PATH adjusted to cover ${CROSS_COMPILE}gcc and company.

    # For example to compile for ICS and ARM with NDK 10d, you'd:

    #

    # ANDROID_NDK=/some/where/android-ndk-10d

    # CROSS_SYSROOT=$ANDROID_NDK/platforms/android-14/arch-arm

    # CROSS_COMPILE=arm-linux-adroideabi-

    # PATH=$ANDROID_NDK/toolchains/arm-linux-androideabi-4.8/prebuild/linux-x86_64/

    #

    "android" => {

        inherit_from     => [ "linux-generic32" ],

        cflags           => "-mandroid -I\$(ANDROID_DEV)/include -B\$(ANDROID_DEV)/lib -Wall",

        # Special note about unconditional -fPIC and -pie. The underlying

        # reason is that Lollipop refuses to run non-PIE. But what about

        # older systems and NDKs? -fPIC was never problem, so the only

        # concern if -pie. Older toolchains, e.g. r4, appear to handle it

        # and binaries turn mostly functional. "Mostly" means that oldest

        # Androids, such as Froyo, fail to handle executable, but newer

        # systems are perfectly capable of executing binaries targeting

        # Froyo. Keep in mind that in the nutshell Android builds are

        # about JNI, i.e. shared libraries, not applications.

        cflags           => "-mandroid -fPIC --sysroot=\$(CROSS_SYSROOT) -Wa,--noexecstack -Wall",

        debug_cflags     => "-O0 -g",

        lflags           => "-pie%-ldl",

        shared_cflag     => "",

    },

    "android-x86" => {

        inherit_from     => [ "android", asm("x86_asm") ],

        bn_ops           => "BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}",

        perlasm_scheme   => "android",

    },

    "android-armv7" => {

    ################################################################

    # Contemporary Android applications can provide multiple JNI

    # providers in .apk, targeting multiple architectures. Among

    # them there is "place" for two ARM flavours: generic eabi and

    # armv7-a/hard-float. However, it should be noted that OpenSSL's

    # ability to engage NEON is not constrained by ABI choice, nor

    # is your ability to call OpenSSL from your application code

    # compiled with floating-point ABI other than default 'soft'.

    # [Latter thanks to __attribute__((pcs("aapcs"))) declaration.]

    # This means that choice of ARM libraries you provide in .apk

    # is driven by application needs. For example if application

    # itself benefits from NEON or is floating-point intensive, then

    # it might be appropriate to provide both libraries. Otherwise

    # just generic eabi would do. But in latter case it would be

    # appropriate to

    #

    #   ./Configure android-armeabi -D__ARM_MAX_ARCH__=8

    #

    # in order to build "universal" binary and allow OpenSSL take

    # advantage of NEON when it's available.

    #

    "android-armeabi" => {

        inherit_from     => [ "android", asm("armv4_asm") ],

    },

    "android-armv7" => {

        inherit_from     => [ "android-armeabi" ],

        cflags           => sub { join (" ","-march=armv7-a",@_); },

    },

    "android-mips" => {

DECLARE_DEPRECATED(int RAND_pseudo_bytes(unsigned char *buf, int num));

#endif

void RAND_seed(const void *buf, int num);

#if defined(__ANDROID__) && defined(__NDK_FPABI__)

__NDK_FPABI__	/* __attribute__((pcs("aapcs"))) on ARM */

#endif

void RAND_add(const void *buf, int num, double entropy);

int RAND_load_file(const char *file, long max_bytes);

int RAND_write_file(const char *file);