Android ICS: intento de error JNI para usar referencia local obsoleta 0x1

Aunque la respuesta de Ernest es técnicamente correcta, una referencia local obsoleta a algo como 0x1 debería sugerir que la máquina virtual Java intenta utilizar algo que no es un objeto Java como objeto Java.

Por ejemplo, supongamos que su función JNI es:

 JNI_EXPORT jboolean foobar(JNIEnv *env, jobject self) { ... return JNI_TRUE; } 

Pero declaras erróneamente la contraparte de Java como public native Boolean foobar() public native boolean foobar() lugar de public native boolean foobar() .

Es un error fácil de hacer, ya que la única diferencia entre boolean y Boolean es la capitalización.

• boolean , un tipo primitivo, se representa en JNI como boolean
• java.lang.Boolean , conocido también como Boolean , es un tipo de clase que se representa en JNI como jobject

Al regresar de foobar , la VM Java tratará el valor JNI_TRUE (0x1) como si se refiriera a un objeto java.lang.Boolean , que resultará en este error fatal.

El error de "referencia local obsoleta" significa que está guardando una referencia local a algún objeto Java entre llamadas JNI; NewGlobalRef convertir esa referencia a una referencia global utilizando el método NewGlobalRef antes de hacer cualquier cosa que haga que la referencia persista fuera del ámbito de una llamada JNI.

Aunque estrictamente esto siempre fue necesario – es en la especificación JNI – es sólo desde Ice Cream Sandwich que esto realmente causa problemas en la plataforma Android.

@Ennest y @Ilya son correctas. Tenga en cuenta que el problema se manifiesta de otras formas también, no sólo las discrepancias de firma. Hay otro caso muy específico en el que me encontré, que fue explicado aquí en el blog del equipo de Android bajo la sección:

Bug: Asumiendo equivocadamente que FindClass () devuelve referencias globales

FindClass () devuelve referencias locales. Muchas personas asumen lo contrario. En un sistema sin descarga de clase (como Android), puede tratar jfieldID y jmethodID como si fueran globales. (En realidad no son referencias, pero en un sistema con descarga de clase hay problemas de vida similares.) Pero jclass es una referencia y FindClass () devuelve referencias locales. Un patrón de error común es "jclass estático". A menos que esté transformando manualmente sus referencias locales en referencias globales, su código está roto.

Básicamente, estaba caché de la jclass devuelto por FindClass en una variable global como es, pero resulta que este valor (a partir de Android 4?) Es ahora un localref. Como resultado, tuve que convertirlo en un globalref así:

 jclass jc = env->FindClass(callbacks.name); // Since Android ICS, class references are not global so we need to peg a // global reference to the jclass returned by FindClass(), otherwise we get // following error in the log: // "JNI ERROR (app bug): attempt to use stale local reference 0xHHHHHHHH". callbacks._class = static_cast<jclass>(env->NewGlobalRef(jc)); 

Después de un montón de rascarse la cabeza, esto arregló el problema para mí.

Esta es una variación de la respuesta de Ernest, en lugar de pasar un booleano o incluso un booleano como un argumento para el método de llamada, pasé el verdadero literal (sí me pateó repetidamente cuando lo encontré), que por supuesto tiene el valor de 0x1 .

Aunque no desafío la validez de las otras respuestas, he perdido horas persiguiendo estos errores. En mi caso, eran verdaderamente crípticos, pero sólo tengo que culpar a mí mismo:

10-16 12: 24: 18.722: E / dalvikvm (1204): ERROR JNI (bug de la aplicación): intento de usar la referencia global obsoleta 0x26
10-16 12: 24: 18.722: E / dalvikvm (1204): VM aborting

Para mí, esto significaba que no había solicitado el permiso correcto en el manifiesto.