What I Have
I have CrashAnaytics setup for my app and it works flawlessly so far. I also have disabled it for my debug build and is only enabled for my release builds.
Crashlytics crashlyticsKit = new Crashlytics.Builder()
.core(new CrashlyticsCore.Builder().disabled(BuildConfig.DEBUG).build())
.build();
Fabric.with(this, crashlyticsKit);
What I Want
In my app, I sometimes deliberately need to throw an exception and crash the app. You can consider it as a feature where the user can force close or crash the app if they want to.
throw new FakeCrashException();
Now, the problem is that I am getting plenty of these crashes reported in CrashAnalytics as well. I know that these are not real crashes and there is no point in logging them in CrashAnalytics.
Is there a way I can exclude this specific exception from being reported by CrashAnalytics?
Mike from Fabric here.
Have you thought about logging these as Caught Exceptions instead of FakeCrashes?
Using: Crashlytics.logException(e); may accomplish what you're looking for as this would not be considered crashes and wouldn't affect your crash-free statistics. More information within the documentation.
Related
I launched my app in the alpha channel, and my Google Play Console pre-launch report details page shows an error occurred on Android 12 (SDK 31).
The stack trace that show me is:
ANR in com.google.android.apps.safetyhub;PID: 11778;Broadcast of Intent { act=com.google.android.gms.phenotype.UPDATE flg=0x30 pkg=com.google.android.apps.safetyhub cmp=com.google.android.apps.safetyhub/com.google.apps.tiktok.experiments.phenotype.ConfigurationUpdatedReceiver_Receiver (has extras) };
I don't see the name of my package anywhere.
Can you help me to understand what is causing the error?
If you are not using those packages of the ANR it is warning you about, it is likely a bug in the Google Play Console testing platform and/or simulated device. This is especially the case an error only appears on one device. It tests on numerous different emulated devices, so if it's just happening on one, it's probably just a one-off glitch that's unrelated. Good news is you don't need to pass the pre-launch report in order to release, so you can ignore it!
In any case, you should double check the full logcat. Click 'show more' then click the -> to the right of the device, then click download full log cat. If it doesn't seem like your app initiated any calls, it's probably just a background crash that is unrelated to your app and you can disregard it.
I am automating an android hybrid application using appium. This application is a news app and displays ads randomly. So when the ad pops up my script gets failed with element not found exception.
To overcome this issue I have added try catch block.when the NoSuchElement exception occurs a logic is written in the catch block to close the ad and then the test is continued.
But i found it is not feasible to add try catch block in all test methods. there are 100 plus test methods, which in turn increase my code size and not a professional approach.
I request experts help for a better solution.
I think you should integrate some crash reporting tools:
Crashlytics
Sentry
and there are many others in the market.
Having either of the tools integrated will help you in getting all the crashed logged over dashboard.
Try Catch block will effect your app performance. Try handling it by yourself with checking either is null or not. If you need reporting and stats for your crash then you should go for Splunk Mint which gives you detail of your crash.
I think you can use Thread.UncaughtExceptionHandler which can caught exception and we can give appropriate message
For further you can check android document
https://developer.android.com/reference/java/lang/Thread.UncaughtExceptionHandler
Usage of it you can get from below
Need to handle uncaught exception and send log file
I am running a new thread which keep monitor the app activity in the device and the activity is "ad activity" then i kill that activity immediately this resolves my long time test execution problem.
Thanks everyone for you time and help
I have been writing a simple Android application (one Activity).
I would really like to gather crash reports from actual user sessions. I know there are some nice 3rd-party libraries. I also read that Google Play Console (Android vitals) should be providing some basic telemetry including crash reports. I was thinking that, to keep things simple, I would stick with the Android vitals for now.
I was wondering whether there is anything I need to do on the Application side to get the crash reports. Or should I just simply let the App crash?
I handle exception that can be handled, but there is always a possibility that one makes it to, say, onCreate. 'onCreate' does not allow throwing checked exceptions though. If I cannot handle it, should I just wrap it in Runtime exception and throw that instead?
Thanks.
Here's an article for a similar approach, https://proandroiddev.com/hide-your-crashes-gracefully-and-still-report-them-9b1c85b25875 However it does not rely on the Android OS crash reporting process; i.e. I don't think you would see the crashes in Android Vitals if you follow the steps described in the article.
You might be able to adapt it though, mainly in terms of restarting the app after the crash occurs.
I am working on an application for pre-Marshmallow devices. The source code was not written by me and the project itself is quite big.
I am currently making the app to request permissions when needed.
The question is: How to find all places in code where permission should be requested?
I am using Android Studio.
EDIT
Some people suggest to change api to 23 and just run the app and see the places where it crashes.
The problem is that the app does not crash in every place.
For example, running this code without a permission will crash the app:
TelephonyManager manager = (TelephonyManager) context
.getSystemService(Context.TELEPHONY_SERVICE);
While this one just returns an empty array, instead of crashing.
final String[] SELF_PROJECTION = new String[]{
ContactsContract.CommonDataKinds.Phone.DISPLAY_NAME,};
Cursor cursor = context.getContentResolver()
.query(ContactsContract.Profile.CONTENT_URI, SELF_PROJECTION, null, null, null);
Also, Android Lint does not show these places. I'm not sure if it should be.
According to the developer page regarding security permissions :
In almost all cases, however, a permission failure will be printed to the system log.
So run the app and search the log for "permissions" or similar.
Use unit testing to ensure coverage of all the places in the code where permissions may be required.
Add
lintOptions {
enable 'MissingPermission'
}
in your build.gradle. This will show warnings after you build your application.
Sure, compile targeting api 23, do not add in permissions code, run the app and see where it crashes.
Once you start pinpointing the locations then flip permissions on (via app settings) so you can get past that screen and then turn them back off so you can see if it crashes.
Logcat is pretty descriptive in letting you know that permissions are denied...
You can do this trick: delete the dangerous permissions from the manifest. This way, you can test on pretty much any device, you'll be sure it will crash and you'll find the exact places where you need those permissions. This is how I did it anyway.
Request all permissions you want at the first startup of your app.
It's not a Best Practices, but it is an answer of this question.
This is not really a programming question but more of a debuging question.
I have an app that works fine, however, it is a bit unreliable when we try to resume the app.
What happens is, if we background/ minimize it, and than try to resume the app by clicking the app's icon. It sometimes crashes and it sometimes doesn't. It is unreliable that we can not trace what is the issue and why it occurs.
Any possible solution or places we can start tracing for the issue, please advise me :)
Cheers
Not a programming question but it is a development question. It is extremely inconsistent didn't know how to even find the stack-trace
How I solved it was wrapped everything with a bunch of try catch and print the error stacktrace to the screen(or email the developer), finally found out the error was with one of the 3rd party LocationService library I was using.
Note: Location Service is not very reliable, please be caution in how you want to use that feature Android Devs!