Próbowałem hackować na zarządzanym przez firmę Gradle projekcie Android, który używa JNI i mam trochę problemów. Rozumiem, że wsparcie NDK jest wciąż stosunkowo nowe i w większości nieudokumentowane, ale udało mi się znaleźć podstawowe elementy do tworzenia klocków na buty w kompilacji Gradle. Widocznie Sztuką jest to cały swój natywnego kodu pod src/main/jni i upuść następuje w jednym ze swoich configs (np w bloku defaultConfig):NDK Dev w projekcie biblioteki Android z Gradle i Android Studio
ndk {
moduleName "mylib"
}
Problemem jest to, że gdy próbuję zbudować mojego projektu The Wtyczka ndk generuje plik Android.mk, który zawiera bezwzględne ścieżki do natywnego źródła. To powoduje, że make dusi się, ponieważ STILL traktuje ścieżki jako względne. W moim przypadku mam prosty projekt biblioteki z 1 źródło cpp/nagłówka kombi pod src/main/jni i używam tego 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.+'
}
Running kompilacji generuje ten Android.mk pod 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)
... który po uruchomieniu powoduje błąd:
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.
... ponieważ absolutne ścieżki są przekształcane w stosunku do błędnie. Gdybym ręcznie edytować plik i zmienić ścieżki do względnych tak:
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)
... I wtedy ten błąd:
/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
Moje pytanie brzmi, co mogę zrobić, aby rozwiązać ten problem? Zacząłem hackować własną niestandardową obsługę gradacji dla buildów .aar, ale zgubiłem się, próbując dowiedzieć się, które zadanie Gradle jest odpowiedzialne za generowanie pliku .aar. (Dokumentacja Gradle'a, mimo że jest obfita, utrudnia znalezienie szczegółów na temat konkretnego API zadania Android Gradle.) Mam częściowo działający plik gradle.build, który uruchomi ndk-build poprzez linię cmd, wygeneruje plik .so, ale mogę. t wymyślić, jak (lub nawet jeśli powinienem) wstawić .so wewnątrz .aar. Korzystam z Android Studio 0.5.7 i Gradle 1.11. Kilka miesięcy temu ściągnąłem źródło Gradle, w ten sposób zorientowałem się, jak wstawiać pliki .so i gdbserver do zwykłego projektu .apk, ale te zasady nie wydają się dotyczyć projektów .aar. Czy ktoś jeszcze próbował tego? Gdzie mogę znaleźć odpowiedzi?