2015-06-05 15 views
10

ho integrato Crashlytics, Fabric nella mia app, i crash legati SDK sono segnalati con successo.Android Crashlytics ndk; valori di NdkOut e NdkLibsOut in build.gradle

Per la parte NDK, ho seguito le istruzioni dal blog; The Wait is Over: Launching Crashlytics for Android NDK, ma i crash ndk non vengono segnalati. Il mio dubbio è, perché le altre parti sono sufficientemente chiari, non sto fornendo il percorso corretto per androidNdkOut e androidNdkLibsOut, come mostrato in:

enter image description here

Il dubbio e la domanda è nella mia build.gradle, eccolo qui. ..

crashlytics { 

    enableNdk true 
    androidNdkOut //what would be the obj here? 
    androidNdkLibsOut 'src/main/jniLibs' //path for my jni libraries 

} 

favore, fatemi sapere se devo inviare qualsiasi altra parte del codice

+0

Non sono sicuro al 100%, ma penso che questa funzione Crashlytics stia compilando il codice C nei file .so come parte del processo di compilazione. Questo genererà i "binari di debug e release" che penso siano posizionati in quelle cartelle. Se si utilizzano librerie .so precompilate, penso che non funzionerà. Guarda: https://dev.twitter.com/crashlytics/android/ndk "Controllo dei percorsi per eseguire il debug e rilasciare i binari" – GaRRaPeTa

+0

Realmente li realizzo tramite './Gradle' per i simboli debugRelease, spero che non sia un problema – user2450263

+0

Lo stesso problema qui, funzionerà con le librerie precompilate? – Anton

risposta

9

EDIT/UPDATE 7 luglio, 2017

Matt dal team Fabric qui con un aggiornamento a questa risposta - abbiamo lanciato il tessuto Gradle plug-in versione 1.23.0 che include il supporto per rilevare automaticamente il nativo appropriata i percorsi di libreria quando si sta utilizzando il externalNativeBuild DSL con il plugin di Android per Gradle versione 2.2.0+, quindi non è più necessario per impostare le proprietà androidNdkOut e androidNdkLibsOut. Ciò funzionerà sia con CMake che con ndk-build. Scopri maggiori informazioni qui: https://docs.fabric.io/android/crashlytics/ndk.html#specifying-the-path-to-debug-and-release-binaries


ho potuto risolvere il problema dopo aver ricevuto aiuto da Crashlytics/Fabric Support, ringraziando them..this risposta.

In primo luogo, per

crashlytics { 

    enableNdk true 
    androidNdkOut //what would be the obj here? 
    androidNdkLibsOut 'src/main/jniLibs' //path for my jni libraries 

} 

per di mia app build.gradle, avrebbe dovuto essere:

crashlytics { 
    enableNdk true 
    androidNdkOut 'src/main/jniLibs' 
    androidNdkLibsOut 'src/main/jniLibs' 
} 

androidNdkOut è dove si trovano i binari debug. Questo valore predefinito è in "src/main/obj" ma è possibile impostare in crashlytics {} se è diverso nel proprio progetto.

un link che contiene informazioni utili sulla stessa: crashlytics knowledgebase; Missing line numbers in native crashes

Una parte minore, ma molto utile è stata l'esecuzione di comandi come uploadReleaseSymbols con l'opzione --stacktrace. Ho pensato che valesse la pena menzionare che (il caricamento dei simboli di rilascio) era anche un problema da parte mia per non aver ricevuto i rapporti sugli arresti anomali.

5

Segui questa guida - https://fabric.io/downloads/gradle/ndk. Abbiamo tenuto vuoti entrambi i campi (androidNdkOut e NdkLibsOut)

+1

Di sicuro non vogliono che nessuno lo trovi. –

+0

Una guida ufficiale ma segreta, cool .. –

3

Aveva un problema simile: ho dovuto aggiungere il kit CrashlyticsNdk a Fabric.with().

Fabric fabric = new Fabric.Builder(context) 
    .kits(new Twitter(authConfig), new Crashlytics(), new CrashlyticsNdk()) 
    .debuggable(true) 
    .build(); 
Fabric.with(fabric); 

è possibile controllare androidNdkOut, androidNdkLibsOut in questo modo.

$ ./gradlew -d clean assemble{Flavor} | grep ndk-build 

e troverete NDK_OUT e NDK_LIBS_OUT.

+3

hey, solo un aggiornamento su questo, che il comando non funziona su un mac, con Crashlytics e ho usato 'Fabric.with (questo, nuovo Crashlytics(), nuovo CrashlyticsNdk()); ', funziona – user2450263