Strange enough problem...
Okay, here's my situation. In my Android application I'm using 3rd party component which generates a lot of Logcat logs. I don't have sources of those component :(
For some security reason I need to find way to somehow intercept those logs before they appearing in Logcat.
Is it possible? Any ideas?
You can use ProGuard on the 3rd party library to strip it of all calls to the Log class as per this answer to a similar question: https://stackoverflow.com/a/2019002/1122135
If the source code is available for the library, I would recommend building your own version of the library without the debug output.
Related
I'm using Unity 2018.4 to make a 2D game. I am facing a strange error with native code (possibly coming from some library) only in a release version and possibly in Android 10.
I don't know how to interpret the abort message.
Abort message
The only library I used that doesn't start with Unity is libsqlite3.so extracted from the SQLite website itself. (Link here)
I also have the errors coming from Google Play by Android Vitals, but it’s just as unreadable.
Does anyone know how I can solve? My game is already in the Play Store and I am receiving some complaints.
SIGSEGV, nice. Welcome to the club of games programmers who have managed to really crash Android hard. I've got a couple of guesses, but can't say for certain. More info would be useful - is this happening to all users of your release, or just some devices or device families?
I've managed to do the same, but my crash was consistent - happened every time, not just release. I had some libGDX native objects open, then tried to change the activity before closing them. My crash looked quite like yours. Check your screen changes to make sure that you cleanly close all your objects before trying to change activities/fragments.
The fact that you mention release makes me think of ProGuard. If you have it turned on it can aggressively optimise out classes that are 'unused'. This means that if you have classes you use via reflection then they won't be compiled into the release bundle. You could try turning it off completely and making a release, to see if that makes things work again. If this is the cause, look into
-keepclasseswithmembers class [your_class_path].** {*;}
in your proguard-rules.pro.
What I was suspecting was correct, the problem was the 64x library libsqlite3.so, I didn't quite understand what might have happened, I replaced the library with one from this source.
We are working on an Android app. We are using the Chilkat library to handle the email communication and it works well. Although, there may be a "issue" involving some JNI communication. From internet research and discussing with Chilkat, the problem may involve how EMOJI's are processed in messages.
Periodically, we get an error that hard crashes the app and it comes from the library call. It is a single line call that sometimes crashes depending on something within the message itself. Our call is...
tmpstr=email.getHtmlBody();
The hard crash error we get is:
JNI DETECTED ERROR IN APPLICATION: input is not valid Modified UTF-8: illegal start byte 0xf0
Again, doing some internet searches on this message... this apparently is a more common issue than anyone wants but still needs to be addressed. Chilkat is working on a fix but in the meantime, we need to continue with the app.
What I am trying to figure out if there is a way that we can catch the error and prevent the app from crashing... maybe just flagging this message and continuing with the next message?
Seeing how I have never tried to catch an error from a 3rd party library, I am not sure where to go with this.
Any suggestions or examples that might help would be greatly appreciated.
Well, depending on error, you can always try to "fix" it. Working with legacy code is always hard and all you can do here are some hacks.
You can do few things here:
try to catch signals
make sure your app doesn't exit your JVM
Take a look here: http://jnicookbook.owsiak.org/recipe-No-015/ and here: http://jnicookbook.owsiak.org/recipe-No-016/
Maybe you will find some solution based on these samples.
Obviously with code, errors can occur anywhere. So without having try/catch blocks all over the place (which as I understand it is major overhead) how do I allow errors to bubble up to the application level and then handle them there? Or at the very least, record the error somehow for troubleshooting? I found information on an product called ACRA, but the setup instructions are geared for Eclipse projects. I am using Mono for Android in Visual Studio 2010.
That's a bit of an "It depends" question.
The appropriate handling of an errors is going to depend on what the recovery strategy needs to be, how much information you want the user to see etc.
I wouldn't worry how many Try/Catch blocks you use - just use them wherever you need to handle an error that gets thrown - if they're everywhere, your strategy is probably wrong.
It terms of logging and later interrogation, you can log caught errors using the Android.Util.Log class.
These can be interrogated (provided you're debugging on your own device) using Logcat.
There's some more info on logging and Logcat here.
Found this project that writes crash info to google docs. Android Crasher
In the Android docs it talks about getting an application ready for the market.
It says that you should deactivite Log and debugging.
Is this totally neccessary? Or just an suggestion?
Also how do you go about doing this?
You can remove all logging by running progruard with the correct options.
Android Proguard, removing all Log statements and merging packages
Has some of the options needed. Takes some understanding of Proguard but allows the source to keep the log messages while not worrying about them in a released application. Additionally, you can add the other methods to the config as well to remove logging completely. Not all applications do this. Many of Google's own applications are fairly chatty on the log in release.
Is there a way to report Bugs, similar to the Android Feedback Client, but without registering my application at the market. I'm still working on the application and some users are alpha testing it so it would be useful to receive reports/ stacktraces etc. Is there a common way or an application for that?
You can look at ACRA Project - http://acra.googlecode.com/
You can use Instabug which lets you report bugs right from the app by shaking the phone. It sends you all the device details, network logs, view hierarchy inspection, as well as the steps to reproduce it. It takes a line of code to integrate.
For full disclosure. I work at Instabug.
I've used acra and it works well: http://acra.googlecode.com/
see: How do I obtain crash-data from my Android application?
I have used Android Remote Stacktrace before, it was very easy to setup, but when I set it up I don't think it had as many options as A.C.R.A does - I haven't used either in a while so I'm not sure which is better.