Re: JNI call GetMethodId (C++) fails in system app

[gadget]

If what i'm about to tell you is super obvious and you've already checked it all, please disregard, just wanted to throw out some ideas.

1. Check GetMethodId vs GetStaticMethodId and such (but this is probably ok, since it runs in other cases)
2. Could it be that your classes are not being loaded somehow (probably also unlikely, since you're already running them in java)
3. Could it be that you're calling GetMethodId on the wrong object? Like a superclass, or something? (just a thought...)
4. Could the method be getting stripped due to ProGuard?

Other than that, make sure you've got CheckJNI enabled, and manually take a look at the classes once they're in the apk, make sure your method is there.
Overall, I agree, sounds really unusual.

On Monday, May 6, 2013 12:20:55 AM UTC-7, TPS wrote:

Hi all,

I have run into this strange problem that I would like to understand. I have implemented an Android service that includes native library that it accesses using JNI. The library also calls back to Java code in order to send some intents and get some information.

* the service runs successfully as a user app (on this part) when installed from apk file
* the service runs successfully as a user app (on this part) when build to the image in android build tree
* the service runs successfully as system app, when I just use  android:sharedUserId="android.uid.system", sign it with correct key and then install the apk.
* when I use android:sharedUserId="android.uid.system" and build the component as part of the android tree to /system/app folder and the native library installed to /system/lib, calling GetMethodId throws NoSuchMethodError. However to make this more complex, it does not happen with all builds. I have not been able to find out what are the differences and for that I would need some help and ideas.

The C++ code looks like this:

jmethodID callback_=NULL;
jobject obj_=NULL;

void storeCallbackMethodIds(JNIEnv* envP)
{  
    jclass cls = envP->GetObjectClass(obj_);
    if(NULL==cls)
    {
        LOGE("storeCallbackMethodIds cls(obj_)==NULL");
        return;
    }
   
    callback_ = envP->GetMethodID(cls, "javaCallback","()Ljava/lang/String;");
    if(NULL==callback_)
    {
        LOGE("storeCallbackMethodIds javaCallback_==NULL");
    }   
}

JNIEXPORT jint JNICALL Java_com_packet_jni_myMethod
  (JNIEnv* envP, jobject obj)
{
    obj_= envP->NewGlobalRef(obj);
    storeCallbackMethodIds(envP);
    ...
}

and the exception thrown like this:

E/JavaBinder(19218): *** Uncaught remote exception!  (Exceptions are not yet supported across processes.)
E/JavaBinder(19218): java.lang.NoSuchMethodError: no method with name='javaCallback' signature='()Ljava/lang/String;' in class Lcom/packet/jni/MyClass;
E/JavaBinder(19218):    at com.packet.jni.MyClass.myMethod(Native Method)
E/JavaBinder(19218):    at com.packet.service.MyService$MyServiceIfc.myMethod(MyService.java:282)
E/JavaBinder(19218):    at com.packet.ifc.MyServiceIfc$Stub.onTransact(MyServiceIfc.java:216)
E/JavaBinder(19218):    at android.os.Binder.execTransact(Binder.java:351)
E/JavaBinder(19218):    at dalvik.system.NativeStart.run(Native Method)
W/dalvikvm(19218): threadid=8: thread exiting with uncaught exception (group=0x40e8f930)
E/AndroidRuntime(19218): FATAL EXCEPTION: Binder_1
E/JavaBinder(19218): java.lang.NoSuchMethodError: no method with name='javaCallback' signature='()Ljava/lang/String;' in class Lcom/packet/jni/MyClass;
E/JavaBinder(19218):    at com.packet.jni.MyClass.myMethod(Native Method)
E/JavaBinder(19218):    at com.packet.service.MyService$MyServiceIfc.myMethod(MyService.java:282)
E/JavaBinder(19218):    at com.packet.ifc.MyServiceIfc$Stub.onTransact(MyServiceIfc.java:216)
E/JavaBinder(19218):    at android.os.Binder.execTransact(Binder.java:351)
E/JavaBinder(19218):    at dalvik.system.NativeStart.run(Native Method)

So we can see that the previous calls succeed, correct class (com/packet/jni/MyClass) is found and the method signature is correct, but for some reason the method is not found. The same thing happens to all four C++->Java callbacks I am using, all with different signature. Any ideas what could cause that?

[TPS]

Thanks,

Your option #4 is correct in this case. It is obvious now that it came up, blind me (actually I started suspecting that last week after discussion with a colleague, but due to holidays the verification took some time). I myself built the component without ProGuard and had no problems.

[Jesse Stone]

this problem I try three days

build In system app and jni call java function

need add in Android.mk

LOCAL_PROGUARD_ENABLED := disabled

///////example
LOCAL_PATH:= $(call my-dir)

include $(CLEAR_VARS)
LOCAL_PACKAGE_NAME := LinbusConfig
LOCAL_MODULE_TAGS := optional
LOCAL_PRELINK_MODULE := false
LOCAL_PROGUARD_ENABLED := disabled  #--->here
LOCAL_SRC_FILES := $(call all-subdir-java-files)
LOCAL_SDK_VERSION := current
LOCAL_CERTIFICATE := platform
LOCAL_JNI_SHARED_LIBRARIES := liblinattach
include $(BUILD_PACKAGE)

include $(call all-makefiles-under,$(LOCAL_PATH))



TPS於 2013年5月13日星期一 UTC+8下午8時52分35秒寫道：

[Jesse Stone]

System App Jni call to Java Fail

I paste my full code here
https://community.nxp.com/thread/459914


Jesse Stone於 2017年9月11日星期一 UTC+8下午10時17分34秒寫道：

[mic _]

LOCAL_PROGUARD_ENABLED appears to be an option for the PDK (Platform Development Kit). I don't see any indication that it's supported by the NDK.

/Michael

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-ndk+unsubscribe@googlegroups.com.
To post to this group, send email to andro...@googlegroups.com.
Visit this group at https://groups.google.com/group/android-ndk.

To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/0173e14d-39b6-4c05-b101-c94d1f185d90%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Jesse Stone]

System App not for ndk build

my problem is use External NDK build app and use GetStaticMethodID is good
and the same code for system app is fail

the problem is all system app will use LOCAL_PROGUARD_ENABLED enable

if u use External NDK build and GetStaticMethodID fail . it must be jni c code problem



mic於 2017年9月13日星期三 UTC+8上午12時51分46秒寫道：

To unsubscribe from this group and stop receiving emails from it, send an email to android-ndk...@googlegroups.com.

To post to this group, send email to andro...@googlegroups.com.
Visit this group at https://groups.google.com/group/android-ndk.

[TPS]

If you can not disable running proguard, why don't you just set the proguard rules so that it doesn't remove any functions?

It's been a while since I worked on those and don't have any examples available just now, unfortunately.