I'm using ACRA, to sending crash reports to my server. But for two reason, I don't want to send duplicate exceptions to server:
It's boring and make it hard to read and handle exceptions in panel.
My server bandwidth is limited.
So is there any option to enable/disable sending duplicate exceptions?
Duplicate exceptions means duplicate exceptions in specific device. For example if there is a button in my application that cause of a error, I don't want to send occurred error each time user push that button.(If application version increased, it should be sent).
There is no way to do this OOTB.
To do so would mean that you would need to build a database of crashes on your device and check to see if that error had occurred previously.
ACRA is designed to be lightweight and robust. Added that kind of functionality into it would diminish both of those design criteria.
I suggess you consider using a commercial cloud instance for your crash reporting instead of relying on your own server. A good crash server will aggregate crash instances for you. Which let's you focus on the high volume ones.
Related
I'm debugging a voip call application for Android. It users Android Telecom framework & self-managed phone accounts. The incoming calls fail sometimes with a cryptic message:
TelecomFramework createConnectionFailed TC#47: (TSI.aNIC)->CS.crCoF->H.CS.crCoF#E-AZs
I deciphered some of it, but still having trouble with parts of the message.
TSI.aNIC is TelecomServiceImpl.addNewIncomingCall
CS.crCof is ConnectionService.createConnectionFailed
H. is Handler.
So it looks like a poor man's stacktrace. I still can't figure out TC#47 and E-AZs (E- is EXTERNAL_INDICATOR, but that does not tell much).
But what I really need is the actual reason why the connection is failing. Any suggestions?
P.S. I figured out TC#47: TeleCom, #47 is just a sequence number to identify an interaction. And instead of AZs it's sometimes ARs.
P.P.S: It seems like ARs etc, is also some sort of transient identifier, it changes all the time. Thus the cryptic message contains no explanation for the failure.
This problem sounds really weird and it looks is somehow my mistake but isn't
I use crashlytics to keep logs and track exception of the usage of my app
for that i created a lib in the log4j interface which simple calls the crashlytics methods for log events.
On the first version of my lib i add an extra Crashlytics.logException() to every logger.error() in my code. After using it for a while i noticed that this behavior wasn't what i want and I removed the Crashlytics.logException()
BUT CRASHLYTICS KEPT SHOWING EXCEPTIONS ON THAT
I'm really confuse with that and for a long time i thought i was doing something wrong, but after debuging the code thousands of times i came to think that there is something beyond what i see
there is no metion of Crashlytics.logException() in my code, and somehow i still manage to see many errors in my crashlytics dashboard
can someone help me with that?
what events might generate a non-fatal issue on crashlytics dashboard
attach:
- https://pastebin.com/Rbu1ySpd this is the core class of my log lib
- whenever i want to log an even i do `logger.log("something");' in a very log4j way
I have a BaseActivity that I use as a parent for all my Activities. I'd like to log Activity events (onCreate(), onStart(), onResume(), etc.) to Crashlytics, so when a crash happens, I know what the user was doing and what Activities were currently alive. I added the following code to all the methods that I want to log:
CrashlyticsCore.getInstance().log(getClass().getSimpleName() + ".onResume()");
I'm wondering if it's a good idea to do it. Are the logs only sent when a crash happens? Will I not spam the server and produce unnecessary network calls for the users? Perhaps there's a better method of implementing bread crumbs with Crashlytics?
As the name subtly suggests, Crashlytics will only trigger a report (and send a log) after a crash, and will only contain up to 64kb of log history as stated in the docs: "To make sure that sending crash reports has the smallest impact on your user’s devices, Crashlytics logs have a maximum size of 64 KB. When a log exceeds 64 KB, the earliest logged values will be dropped in order to maintain this threshold."
If you ask my personal opinion, it's not good practice or useful to log every onCreate, onResume. A Crashlytics report will already contain the stacktrace giving you insight on the error.
If you have caught exceptions and want to log those, you can do so as explain here, by calling Crashlytics.logException(e);. Again only 8 of these will be stored: "For any individual app session, only the most recent 8 logged exceptions are stored".
I've installed a native code crash reporting system in my Android app, based on signal processing. There's a bunch of sigaction() calls for all the popular crash causes, there's crash report dumping and sending home to the bug tracker.
I'm receiving pretty consistent reports about some signals that are definitely not in my code. There are multiple instances of SISSEGV that originates in android.view.GLES20Canvas.nDrawDisplayList. There's another that comes from within android.webkit.JWebCoreJavaBridge.sharedTimerFired.
Question: is there any chance those signals constitute normal program operation and won't cause a crash/termination if not caught by me? Naturally, I can't reproduce any of those at will. They happen on customer devices.
My Android app uses the AWS Java SDK for uploading user photos to S3.
Whenever a user's phone's clock is 'skewed', this causes all transfers to fail. This is a well documented aspect of S3:
http://aws.amazon.com/articles/1109?_encoding=UTF8&jiveRedirect=1#04
It appears that the upstream S3 service reports this error quite clearly:
HTTP Status Code: 403 Forbidden
Error Code: RequestTimeToo-Skewed
Description: The difference between the request time and the server's
time is too large.
However when using the Java SDK, it seems as if the informative 403 code is lost ... and I have only an opaque "TransferState.Failed" to go by (which incidentally is the same error if internet connectivity is lost, if it times out, etc...).
As far as I can tell from the docs:
http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/index.html
http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/s3/transfer/TransferProgress.html
http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/s3/transfer/Transfer.TransferState.html
http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/s3/transfer/Upload.html
There is no way to get the additional "RequestTimeToo-Skewed" metadata about a transfer failure.
Am I missing it? Is there any way to get additional error information when an S3 transfer fails using Amazon's Java SDK?
UPDATE #1:
A commenter kindly highlighted that I should clarity two points:
I am actually using the AWS SDK for Android (which seems very similar to the Java SDK, but is nonetheless distinct)
I am using the TransferManager class to perform my upload. Apparently, this is a high-level class that wraps the lower-level AmazonS3Client ... and this lower-level class should expose the error reporting I need, but I am still investigating the exact tradeoffs involved between TransferManager and AmazonS3Client. As far as I can tell, there is no way to get progress information via the (synchronous) AmazonS3Client.putObjectRequest which would be a blocker for me...
UPDATE #2:
My sincere thanks to Jason (of the AWS SDK team) for stopping by and helping me out here. The important information is, indeed, available as properties on an AmazonS3Exception if you use certain methods. The docs had originally confused me and I thought that a manual Thread.sleep() loop was required to poll status (and thus I could not leverage waitForCompletion or waitForException), but if you use ProgressListener on PutObjectRequest you can get full progress callbacks and the error-fidelity of AmazonS3Exception.
these two methods should help you out:
Transfer.waitForCompletion()
Transfer.waitForException()
If you detect that your transfer has failed based on a transfer progress event, you can simply call Transfer.waitForException() to be returned the exception that occurred. That exception will be an AmazonServiceException in this case, with all of the info that you need to see that the real problem was a clock skew issue.
Alternatively, the Transfer.waitForCompletion() method will unwrap the original exception from an ExecutionException and directly throw the original exception, just as if it'd all been happening on one thread. This might be a more convenient approach if you want to use a catch blocks to catch different types of errors cleanly and elegantly.
I disagree that the "catch Exception" block is "brutally broad". The point of that code is to catch any error that happens, mark the transfer as failed and rethrow the error so that the application code can know about it. If it were less broad, then that's exactly the case where exceptions could sneak through and transfer progress wouldn't be updated correctly and would be out of sync with reality.
Give those two methods and shot and let us know if that helps!
Well, I have debugged Amazon's SDK and I'm sorry to say that this information is being swallowed internally. Perhaps I will try to submit a patch.
Details: an AmazonS3Exception is being thrown internally which does in fact accurately report this exact error scenario, but a brutally broad try catch ( Exception e ) consumes it and washes away the specificity.
Here is the guilty try-catch:
https://github.com/aws/aws-sdk-java/blob/master/src/main/java/com/amazonaws/services/s3/transfer/internal/UploadMonitor.java#L145
Here is a screenshot showing that an AmazonS3Exception is correctly thrown with the right info...