Perché ricevo segnalazioni di java.lang.UnsatisfiedLinkError dal Market

Question

Ho un'app nel mercato Android e nei rapporti sugli arresti anomali ottengo java.lang.UnsatisfiedLinkError arresti anomali e ogni volta che si tratta di file .so diversi.

errori sembra

java.lang.ExceptionInInitializerError 
at dalvik.system.NativeStart.main(Native Method) 
Caused by: java.lang.UnsatisfiedLinkError: Couldn't load *****: findLibrary returned null 

o

java.lang.ExceptionInInitializerError 
at java.lang.Thread.run(Thread.java:1019) 
Caused by: java.lang.UnsatisfiedLinkError: Cannot load library: alloc_mem_region[871]: OOPS: 116 cannot map library ********. no vspace available. 

o

java.lang.UnsatisfiedLinkError: Couldn't load ******: findLibrary returned null 
at java.lang.Runtime.loadLibrary(Runtime.java:429) 
at java.lang.System.loadLibrary(System.java:554) 

Sembra che alcuni dispositivi non riesce a trovare alcuni file .so .. L'incidente non è per qualsiasi particolare file .so. Ho circa 4 file .so nella mia app e talvolta si blocca per 1 e talvolta si blocca per un altro.

non avrei mai potuto riprodurre il problema durante il test, anche se ho provato su quasi tutte le versioni di Android ...

Qualsiasi puntatori sarebbe molto apprezzato

Grazie

Answer 1

Sapete i telefoni e/o le versioni di Android che producono questo problema?

Qual è la dimensione delle librerie? Forse stai colpendo alcuni limiti di memoria dei telefoni più vecchi durante il caricamento delle librerie?

Answer 2

Ho visto simili problemi io stesso - questo sembra interessare un numero molto piccolo di utenti, e non posso direttamente correlarlo a tipi di dispositivi o sistemi operativi. Dalla ricerca che ho fatto, tuttavia, ho trovato una discussione sullo Cyanogenmod Google Code page; per riassumere rapidamente: sembra che alcune build di quel mod non abbiano esattamente copiato alcune modifiche apportate da Google alle librerie a livello di sistema, il che significa che alcuni simboli (__android_log_print, ad esempio) potrebbero causare errori, incluso il mancato caricamento della libreria.

Sono in procinto di provare a bloccare ulteriormente, ma ho pensato di condividere quello che ho fino ad oggi.

Answer 3

Forse si alloc troppa memoria in libxxxx.so

"causato da: java.lang.UnsatisfiedLinkError: Impossibile caricare la libreria: alloc_mem_region [871]: OOPS: 116 non può mappare biblioteca * *. nessun vspace disponibile. "

Answer 4

Stavo ricevendo rapporti dal Market circa UnsatisfiedLinkError, anche se la mia app funzionava correttamente nell'emulatore e su alcuni dispositivi Android che ho per testare. Ad un certo punto ho aperto l'archivio .apk generato e ho notato che alcune delle cartelle libs/<ABI> mancano di una delle librerie collegate che utilizzo (file .so). È emerso che i dispositivi Android con CPU compatibili con ARM64 caricheranno alcune delle librerie collegate e si arresteranno in modo anomalo quando non riescono a trovare la versione arm64 di una delle librerie utilizzate dalla mia app (invece di ricadere su arm7v).

problema simile con maggiori dettagli è spiegato qui: https://realm.io/docs/java/latest/#couldnt-load-librealm-jniso

farla breve, ho aggiunto una configurazione aggiuntiva nel mio build.Gradle, che esclude arm64:

android { 
    ndk { 
    abiFilters "armeabi", "armeabi-v7a", "x86" 
    } 
} 

Come nota a lato - CPU arm64-V8A sono compatibili con l'istruzione braccio V7A impostare e possono eseguire istruzioni Thumb 32 bit, ma mischiare librerie 64 e 32 bit non è permesso.