There is someone else's application. I patch it, take a native library out of it, and through NativeActivity I load it in my application, so that someone else’s application starts up "in the context of mine" and I can change something. There is no source code, except that decompiled non-working. Of course, it crashes, because in my NativeActivity and in general in my assembly there are no classes and methods that exist in the original and which is accessed by the library via JNI. And with each version of the library, they are more and more.
My task is to smoothly, from the old versions to the new ones, to make it so that in the end everything that was necessary and the application at least does not fly off at launch.

First, noNSuchMethod from JNI was detected in LogCat. There was a full StackTrace, with a full path to the method, so that every exception was not difficult to fix, simply sticking "stub".
But once again, instead of StackTrace, I see this:

Exception thrown (Ljava/lang/NoSuchMethodError;) while throwing internal exception (Ljava/lang/NoSuchMethodError;) Exception thrown (Ljava/lang/NoSuchMethodError;) while throwing internal exception (Ljava/lang/NoSuchMethodError;) Exception thrown (Ljava/lang/NoSuchMethodError;) while throwing internal exception (Ljava/lang/NoSuchMethodError;) JNI ERROR (app bug): attempt to use stale local reference 0x1 VM aborting

What would it mean (why there is no StackTrace, why now stale writes because it worked in the old versions)? And how to still capture detailed information?

Is there any debugger in the manner of a "global sniffer" of all the exceptions that occur in the system or a specific application?

  • one
    I hope this is impossible. Your activity generally borders on copyright infringement. - Vladyslav Matviienko
  • @metalurgus theoretically everything is possible, why not patch the OS itself under the root? Moreover, it is open source. But in practice, apparently, no one has yet done so. - Simus
  • @metalurgus figured out. Everything is possible there. See the answer. And you, IMHO, to learn and gain experience, before you have the right to defend) - Simus

1 answer 1

Understood.
Everything is simple - by default, Android applications in Eclipse are launched without debugging, therefore, apart from LogCat, we actually have nothing.
But if you press Debug instead of Run, there will be debugging, where we will be able to trace the entire Stack trace, including getting to the detailMessage.
What I did was by adding the missing methods and correcting all 3 options.
But the "jni error" from this did not disappear, apparently, this is a separate problem. And with the JNI libraries, the situation is much worse - they are also in machine code, so debugging is generally difficult. So far I just found out which JNI method leads to an error (I removed the call - there is no error). But this is not talking about anything yet.