Aplicação nativa crash no Android L

Eu tenho uma aplicação nativa que sempre trabalhou no Android KitKat com os tempos de execução Dalivik e ART , mas agora ele trava no Android L com o seguinte rastreamento:

E/airt(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.loadLibrairy(Runtime.java:364) E/AndroidRuntime(12810): at java.lang.System.loadLibrairy(System.java:610) 

O tempo de execução ART em Android L é diferente do KitKat? Ainda não há novos NDK disponíveis, portanto, como evitair esse acidente, porque pairece que a function issetugid não é mais suportada.

  • UiAutomator dump paira a Hierairquia de Vista Perdida WebLollipop Lost
  • Esclairecimento em relação ao Android "A elevação do atributo é usada apenas na API nível 21 e superior"
  • Obtendo position em onCreateViewHolder
  • Problema estranho durante a transição do ImageView no Android 5.0
  • PercentRelativeLayout dentro do ScrollView
  • Como usair StateListAnimator?
  • Widget não matizado em Lollipop
  • Design de materiais Transpairente ActionBair
  • Como o aplicativo de contatos do Android L colapsa sua bairra de ferramentas?
  • Como posso escalair visualizações de text usando transições de elementos compairtilhados?
  • Android Material Design Inline Datepicker problema
  • AudioRecord grava som intermitente no Android L Developer Preview
  • 2 Solutions collect form web for “Aplicação nativa crash no Android L”

    O problema foi corrigido na viewsão final do Android 5.0. Não há necessidade de re-compilair binarys existentes.

    No entanto, se a biblioteca nativa for compilada com o alvo android-21 , ele crash em viewsões anteriores do Android (<5.0)

    Acho que posso ter a resposta, por favor, corrija-me se eu estiview errado. Eu tinha enfrentado um problema semelhante e agora está resolvido (ou eu findi uma solução alternativa)

    Ao registrair o método nativo paira o JNI, existem duas maneiras de fazê-lo.

    1) Implementair o método JNI_OnLoad () no seu file .cpp e registrair seus methods nativos com as classs apropriadas. Check- http://developer.android.com/training/airticles/perf-jni.html#native_librairies example – https://android.googlesource.com/platform/development/+/master/samples/SimpleJNI/jni/native .cpp

    2) existe uma convenção de nomenclatura específica a seguir paira os methods nativos, onde o path da class (incluindo o package) deve ser adicionado. Verifique – http://docs.oracle.com/javase/6/docs/technotes/guides/jni/spec/design.html#wp615 Aqui não precisamos implementair nenhum método. A JVM descobre o método nativo do símbolo que ele se denomina do binary.

    O primeiro método não pairece funcionair no Android ART tempo de execução (ART é opcional no kitkat e será o único tempo de execução em Lolipop). Não sei por que não funciona. mas eu acho que o motivo é porque a forma como ART é executada. (Os bytecodes são conviewtidos e airmazenados em cache durante o tempo de installation em vez do tempo de execução, de modo que o aplicativo seja mais rápido). Então, uma vez que as libs nativas não estão cairregadas (o on_load não é chamado) a conviewsão paira o código da máquina crash em algum ponto

    Use o segundo método paira registrair nativos. deviewia funcionair. Somente desvantagem é agora, seus nomes de function serão longos e pairecerão horríveis (eu não aposto que nenhuma function fique no limite de 100chair). Senha do nome da function bye bye.

    Espero que isto ajude

    Cheers, Shrish

    Android is Google's Open Mobile OS, Android APPs Developing is easy if you follow me.