Android APK生成未获取.so文件-为什么？

Question

I have an Android build environment on my Mac. When I run ant debug , it cleanly packages up libandroidnative.so inside the APK file for deployment. This works as expected.

I am migrating my build setup over to a Windows PC. When I run ant debug , it successfully completes without packaging up `libandroidnative.so' into the APK file.

The codebases are exactly the same -- this is a pull from the same repo. The versions of the NDK (r8) and SDK (2013-05-22) are exactly the same.

Here is a (working) output on my Mac:

res/layout/main.xml
AndroidManifest.xml
resources.arsc
res/drawable-hdpi/ic_launcher.png
res/drawable-ldpi/ic_launcher.png
res/drawable-mdpi/ic_launcher.png
res/drawable-xhdpi/ic_launcher.png
classes.dex
lib/armeabi/gdbserver
lib/armeabi/libandroidnative.so  <--- success!
lib/x86/gdbserver
lib/x86/libandroidnative.so
META-INF/MANIFEST.MF
META-INF/CERT.SF
META-INF/CERT.RSA

Here is the non-working output on my PC:

res/layout/main.xml
AndroidManifest.xml
resources.arsc
res/drawable-hdpi/ic_launcher.png
res/drawable-ldpi/ic_launcher.png
res/drawable-mdpi/ic_launcher.png
res/drawable-xhdpi/ic_launcher.png
classes.dex
lib/armeabi/gdbserver
lib/armeabi-v7a/gdbserver
lib/x86/gdbserver
META-INF/MANIFEST.MF
META-INF/CERT.SF
META-INF/CERT.RSA

Note that the same thing happens from an Eclipse build.

Here is my Ant build file (sans comments):

<?xml version="1.0" encoding="UTF-8"?>
<project name="AndroidNativeLayer" default="help">

    <property file="local.properties" />

    <property file="ant.properties" />

    <property environment="env" />
    <condition property="sdk.dir" value="${env.ANDROID_HOME}">
        <isset property="env.ANDROID_HOME" />
    </condition>
    <loadproperties srcFile="project.properties" />

    <fail
            message="sdk.dir is missing. Make sure to generate local.properties using 'android update project' or to inject it through the ANDROID_HOME environment variable."
            unless="sdk.dir"
    />
    <import file="custom_rules.xml" optional="true" />

    <import file="${sdk.dir}/tools/ant/build.xml" />

</project>

Answer 1

I got it. TLDR; eclipse deletes the old .so file before generating the new one, regardless of whether running ndk-build generates a new one . Make sure that an ndk-build command creates a new one.

In my case, I was only building if an environment variable was set to a certain value. I had a logic branch in my Android.mk that silently exited if the environment variable was a mismatch.

On Linux/Mac, you can type set SOME_VAR="foo" . In a batch file on Windows, typing set SOME_VAR="foo" includes the quotes in the environment variable name.

Awful and totally my fault. I am keeping the question up because the general wisdom at the start of this question may be relevant.

Also worth understanding: you can type aapt list bin\\somepackage.apk to generate the listings I used in the original posting.

Answer 2

According to http://docs.xamarin.com/guides/android/advanced_topics/cpu_architecture , the native libraries behaved differently for different android versions.

Android prior to 4.0 Ice Cream Sandwich will only extract native libraries from a single ABI within the .apk

Consequently, when targeting Android versions prior to 4.0, it is necessary to provide all native libraries for each ABI that the application will support.

and further on, it mentions that

Android 4.0 Ice Cream Sandwich changes the extraction logic. It will enumerate all native libraries, see if the file's basename has already been extracted, and if both of the following conditions are met, then the library will be extracted

It hasn't already been extracted. The native library's ABI matches the target's primary or secondary ABI.

Unfortunately, this behavior is order dependent.

The native libraries are processed “in order” (as listed by, for example, unzip), and the first match is extracted. Since the .apk contains armeabi and armeabi-v7a versions of libtwo.so, and the armeabi is listed first, it's the armeabi version that is extracted, not the armeabi-v7a version:

> It is recommended, if the app will run on Android prior to 4.0.4, that the app contain onlyarmeabi-v7a, not armeabi. Including x86 or any other ABI won't cause problems; it's only the inclusion of both armeabi and armeabi-v7a is an issue.

and for post 4.0.4

Android 4.0.4 changes the extraction logic: it will enumerate all native libraries, read the file's basename, then extract the primary ABI version (if present), or the secondary ABI (if present). This allows “merging” behavior