Ho cercato di hackerare un progetto Android gestito da Gradle che utilizza JNI e sto avendo un po 'di problemi. Comprendo che il supporto di NDK è ancora relativamente nuovo e per lo più non documentato, ma sono riuscito a trovare gli elementi di base per la realizzazione di scarpe in una build Gradle. A quanto pare il trucco è quello di includere tutto il codice nativo sotto src/main/jni e rilasciare il seguente in uno dei vostri file di configurazione (ad esempio, nel blocco defaultConfig):NDK Dev in un progetto di libreria Android con Gradle e Android Studio
ndk {
moduleName "mylib"
}
Il problema è che quando cerco di costruire il mio progetto, il Il plugin ndk genera un file Android.mk che include percorsi assoluti alla fonte nativa. Questo fa sì che make si blocchi perché STILL considera i percorsi come relativi. Nel mio caso ho un semplice progetto di libreria con 1 cpp combinata fonte/intestazione sotto src/main/jni e io uso questo gradle.build:
apply plugin: 'android-library'
android {
compileSdkVersion 19
buildToolsVersion "19.0.3"
defaultConfig {
minSdkVersion 9
targetSdkVersion 19
versionCode 1
versionName "1.0"
ndk {
moduleName "mylib"
}
}
buildTypes {
release {
runProguard false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.txt'
}
}
}
dependencies {
compile fileTree(dir: 'libs', include: ['*.jar'])
compile 'com.android.support:appcompat-v7:19.+'
}
esecuzione la build genera questo Android.mk sotto build/NDK/debug:
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := mylib
LOCAL_SRC_FILES := \
/Users/clifton/dev/Multi/MultiAndroid/lib/src/main/jni/Android.mk \
/Users/clifton/dev/Multi/MultiAndroid/lib/src/main/jni/myNativeSectionTextProvider.cpp \
LOCAL_C_INCLUDES += /Users/clifton/dev/Multi/MultiAndroid/lib/src/main/jni
LOCAL_C_INCLUDES += /Users/clifton/dev/Multi/MultiAndroid/lib/src/debug/jni
include $(BUILD_SHARED_LIBRARY)
... che, quando viene eseguito genera questo errore:
make: *** No rule to make target `/Users/clifton/dev/Multi/MultiAndroid/lib/build/ndk/debug//Users/clifton/dev/Multi/MultiAndroid/lib/src/main/jni/myNativeSectionTextProvider.cpp', needed by `/Users/clifton/dev/Multi/MultiAndroid/lib/build/ndk/debug/obj/local/armeabi-v7a/objs/mylib//Users/clifton/dev/Multi/MultiAndroid/lib/src/main/jni/myNativeSectionTextProvider.o'. Stop.
... poiché i percorsi assoluti vengono convertiti erroneamente relativa. Se io modificare manualmente il file e modificare i percorsi di relativa in questo modo:
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := mylib
LOCAL_SRC_FILES := \
../../../src/main/jni/Android.mk \
../../../src/main/jni/myNativeSectionTextProvider.cpp \
LOCAL_C_INCLUDES += ../../../src/main/jni
LOCAL_C_INCLUDES += ../../../src/debug/jni
include $(BUILD_SHARED_LIBRARY)
... Allora ottengo questo errore:
/Users/clifton/dev/Multi/MultiAndroid/lib/build/ndk/debug/../../../src/main/jni/com_craig_multiandroid_app_NativeSectionTextProvider.h:2:17: fatal error: jni.h: No such file or directory
La mia domanda è che cosa posso fare per risolvere questo problema? Ho iniziato a modificare il mio supporto gradle personalizzato per build .aar ma mi sono perso cercando di capire quale task Gradle è responsabile della generazione del file .aar. (I documenti Gradle, anche se abbondanti, rendono difficile trovare i dettagli su un'API Android Gradle specifica.) Ho un gradle.build parzialmente funzionante che eseguirà ndk-build tramite la linea cmd, genererà il .so ma posso ' t capire come (o anche se dovrei) in linea il .so all'interno del .aar. Sto usando Android Studio 0.5.7 e Gradle 1.11. Ho tirato la fonte di Gradle alcuni mesi fa, il che spiega come integrare i file .so e gdbserver in un normale progetto .apk, ma quelle regole non sembrano essere applicabili ai progetti .aar. Qualcun altro ha tentato questo? Dove posso andare per le risposte?