crash applicazione nativa su Android L

Question

Ho un'applicazione nativa che ha sempre lavorato su Android KitKat sia con Dalivik e ARTE tempi di esecuzione, ma ora si blocca sul Android L con la seguente traccia:

E/art(12810): dlopen("/data/app-lib/com.mylib.example", RTLD_LAZY) failed: dlopen failed: cannot locate symbol "issetugid" referenced by "mylib.so"... 
D/AndroidRuntime(12810): Shutting down VM 
E/AndroidRuntime(12810): FATAL EXCEPTION: main 
E/AndroidRuntime(12810): Process: com.mylib.example, PID: 12810 
E/AndroidRuntime(12810): java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "issetugid" referenced by "mylib.so"... 
E/AndroidRuntime(12810): at java.lang.Runtime.loadLibrary(Runtime.java:364) 
E/AndroidRuntime(12810): at java.lang.System.loadLibrary(System.java:610) 

Il runtime ART in Android L è diverso da KitKat? Non è ancora disponibile un nuovo NDK, quindi, come evitare questo crash, poiché sembra che la funzione non sia più supportata.

Answer 1

Il problema è stato risolto in finale release 5.0 di Android. Non è necessario ricompilare i binari esistenti.

Tuttavia, se il lib nativo viene compilato con l'obiettivo Android-21, non riesce a precedenti versioni di Android (5.0 <)

Answer 2

Credo di avere la risposta, per favore correggetemi se wrong.I iam aveva affrontato problema simile e ora il suo fisso (o ho trovato una soluzione piuttosto)

durante la registrazione metodo nativo per JNI, ci sono due modi per farlo

1) implementare il metodo JNI_OnLoad() nel file cpp e registrare i vostri metodi nativi con le classi appropriate. Check- http://developer.android.com/training/articles/perf-jni.html#native_libraries esempio - https://android.googlesource.com/platform/development/+/master/samples/SimpleJNI/jni/native.cpp

2) c'è un particolare denominazione convenzione per seguire i metodi nativi, in cui la traiettoria classe (pacchetto compreso) devono essere aggiunti. Check - http://docs.oracle.com/javase/6/docs/technotes/guides/jni/spec/design.html#wp615 Qui non è necessario implementare alcun metodo. La JVM scopre il metodo nativo dal nome del simbolo stesso dal binario.

Il primo metodo non sembra funzionare nel runtime Android ART (ART è facoltativo in kitkat e sarà l'unico runtime in Lolipop). Non sono sicuro del motivo per cui non funziona. ma penso che la ragione sia dovuta al modo in cui ART esegue (i bytecode vengono convertiti e memorizzati nella cache durante il tempo di installazione stesso anziché in runtime, in modo che l'applicazione venga eseguita più rapidamente). Quindi, dal momento che le librerie native non vengono caricati (on_load non si chiama) la conversione in codice macchina non riesce a un certo punto

utilizzare il secondo metodo per registrare i nativi. dovrebbe funzionare. Solo lo svantaggio ora è che i nomi delle funzioni saranno e lunghi e sembreranno orribili (scommetto che nessuna funzione si adatta al limite di 100 khar). Addebito sulla leggibilità del nome della funzione.

Spero che questo aiuti

Cheers, Shrish