I know this could be a very ambiguous question But I need some help. I'm working for a project which consists of users doing some tests in Tablets. the tests they do are always the same but sometimes the app crashes for certain Tablets/users. As I mentioned, the tests are the same for every person and the tablets too. However, in some cases the app stops working. I have looked for some Warning errors ( intent receiver leaked , etc) but I think I have resolved them. I think this could be a matter of memory problems (mp3, images are in the tests).
Is there a way of testing this app's stability? I must mention that these crashes only happen when there are some users doing this in the same Wi-Fi and the same SERVER. Could be a server problem?
Thank you for the help.
Check out Crittercism or something similar - I have found it to be VERY useful in the past.
It will send a crash report for you, providing the stack trace.
(yes, there are plenty of others that may be better / worse / different / the same etc... I'm just mentioning this one because it is the one I had experience with)
Related
So I have an android application that has a myriad of activities (intents?) which all do their own thing. We were wanting to create a sort of debug log though, one where you can see what the user has been through and error that occurs. You may have had to send one before if you've run into a bug with a program you've used.
My initial thoughts are to just create a class where I can send information/data to and it just writes it onto a text file. It would need to be accessible across all the activities so that I can easily write to it and re-use it.
I do wonder whether that's a good way to go through, noted that it doesn't really save any actual errors but only data I tell it to. And I'm not sure if its a great idea to be constantly opening->writing->closing a file for a debug log.
Is there a smarter way? Or a common pattern that would be good to use?
Thanks so much!
Sentry's Android SDK, will automatically report errors and exceptions in your application.
The Sentry SDK catches the exception right before the crash and builds a crash report that will persist to the disk. The SDK will try to send the report right after the crash, but since the environment may be unstable at the crash time, the report is guaranteed to send once the application is started again.
You can see full documentation here
I'm having a problem where an app I'm developing is working on mobile devices (tested on 4 different devices), but crashing when I try to test it on my tablet. The tablet I'm using is a Tesco Hudl 2, which, although being a good quality low cost device, lacks adb drivers and so you can't debug apps through USB and get the Logcat data. The app was developed using Android Studio.
With other apps I have developed, I have just set up ACRA in the project so I can still get debug information from a crash. This time however, the app is crashing without any information from ACRA and so I'm not quite sure what is going wrong. I'm pretty sure I've set up ACRA correctly given that I've used it in several projects before and see nothing wrong this time. Can it be that whatever is going wrong is happening too early for ACRA to catch?
I have pulled out all the code from the activity so the only thing that happens in code is that ACRA gets initialized in the derived Application class (note that the crash exists without ACRA). The app also uses Google maps and a provider for search suggestions. If there is any code anyone wants to see just ask, but I'm unsure what exactly to post up since everything else was stripped out. So, does anyone have any idea on what I can do to solve this, or what tools I can use to catch whatever sort of errors happen so early in the apps lifecycle?
Thanks
Update with strange behaviour... Downloaded Crashlytics and it also did not catch the crash. I copied the project and removed every .java file except the Application, Activity and provider. The provider functions were empty (save for the return value of 0/false/null/whatever), the application class just initialized Crashlyitcs and the Activity class was empty. This then worked, I was even able to add in a lot of the code and get the google map to load.
Now if I do the same in my main project, except don't delete the .java files, the crash still happens. The classes in these files are not used so I have no idea how they can be causing the crash. Otherwise all the xml, gradle, resources are identical (except the package and app name). Very confusing...
Consider using one of the apps to view logcat on the device:
https://play.google.com/store/apps/details?id=com.nolanlawson.logcat
https://play.google.com/store/apps/details?id=org.jtb.alogcat
Also try using Crashlytics. Maybe it will catch your crash?
But yeah, it's possible to have a crash before any crash reporter (ACRA or Crashlytics) will have a chance to catch it.
And one more note, maybe there is a way to enabled ADB over WiFi.
Normally you would need to enable it via adb but maybe in case of this cheap and strange tablet, there is an option for that enabled in the ROM?
Ok! So it's 1am and I decided to have one final attempt to fix, which I think I did. In my manifest, I had things like
<activity
android:name=".MyActivity"
...
for example, and while this worked fine on the mobiles, for some reason the Hudl required the complete package name, i.e. com.mypackage.MyActivity. Not sure why this is the case but it appears to have fixed the problem.
Background
I wanted to simplify the usage of DB in an Android app.
For this, I've compared some third party libraries that create a DAO layer.
I've come up with a nice library called "GreenDao" (presentation about it here) . The website shows that it's faster than other competitors (like ORMLite) and is optimized for Android.
The problem
For some reason, on some device (usually old devices, with GB) , I get the next console error when trying to install the app:
Installation error: INSTALL_FAILED_DEXOPT
Please check logcat output for more details.
Launch canceled!
I've searched for the reason of this error, but couldn't find out how to solve it. Many complain about this error, but I can't find out why it occurs, and what can be done.
The error is quite common and known, but it's never mentioned as the result of using this library, yet when I remove the usage of this library, everything works fine...
Also note that on newer devices (like nexus 4) it installs and works just fine, and that the sample itself also works fine no matter which device I test it on.
The question
Why does it occur?
Is it possible that the structure of the classes is just too much for old devices to load, since we use other libraries ?
Could it be that I've reached the limit of code that is supported by android apps?
The jar file itself takes just 87KB ...
How can I solve this?
Ok, I've found the problem and the solution:
It has nothing to do with GreenDao.
It's because the app uses too many jars, so maybe Android has a limitation of code.
The solution is to either delete un-needed jar files or delete a lot of code.
Why and when should I use the android Logging? Should it be used only for debugging purposes? It seems to me that if kept in a production application, it would slow it down considerably.
One key part of my question, is WHEN it should be used...in what cases should I need it? Are there any 'best practices' for using this?
This may be a very stupid or amateur question, but I've never understood the need or felt compelled to use it. I may be missing something.
http://developer.android.com/reference/android/util/Log.html
Also - I already know that logging for errors/verbose/info/etc are different, and some are discarded when not debugging. Please don't reiterate the information that's in the class overview without giving me an explanation why. Thanks!
I agree with you, I never really used it either. I much prefer debugging over log reading (and unit-testing over debugging), when trying to figure out what's happening and getting an error.
Some people argue it can be useful to log "additional details" when your application crashes and get an exception, but I usually reply to them that the exception itself should hold that additional details when necessary, and expose them in its getMessage. Thus, the default stack trace that's included in the LogCat is more than enough to see what's going on.
But anyway, it's always nice to have the possibility to log something, even though I haven't found it really useful so far, you never know when it might help :)
Regarding my comment, see Preparing for Release. (Showing logging should be removed before release, hence not being used in production).
Turn off logging and debugging
Make sure you deactivate logging and disable the debugging option before you build your
application for release. You can deactivate logging by removing calls to Log methods
in your source files.
I used logging the other day, I fired off another thread to do some work but I needed to check some data being produced in the thread, without logging or displaying Toast's, how could I get the values? I'm tried debugging/stepping through code in Eclipse before and just run into several problems.
With logging, I can log each value, view the logcat and know exactly what my code is doing.
You usually debug only when you know there is something wrong. (And when you know, you might write additional test cases.)
With logging (at the INFO level, for example), you can add some additional information to trace the data in the app. This allows you to find out that there is something wrong.
Thus, it adds a higher-level overview.
Additionally, it can be easily disabled, does not slow the app down significantly (if done right), and might thus offer another avenue of approach to see if everything works correctly, with few disadvantages and some advantages. (See also Logging vs. Debugging, especially the links in #smonff's answer.)
My app had been chugging along fine on the Android market until last night when it was reported a customer found an error. The customer must have downloaded the latest version of the app because he tried to use it again with the latest version and the error came back.
I looked at the stack trace of the error and found it was caused by a NullPointerException when passing information between two activities, namely with the onActivityResult() method.
I checked the code and can't find what could have caused the error. I tried to figure out what steps the user took to get the error, but found nothing wrong, on the emulator Android 1.6 /Android 2.2 and my own phone (Android 2.2). I couldn't find any problems no matte rhow much I tried to crash the system.
Another thing that is strange is that the particular onActivityResult method is called a lot in my app. So it is odd that only one user has reported problems.
Also, it says the user's platform is "OTHER". I don't know what device that could be.
So my questions are:
1) Could this problem be an issue with the user's device and not my application?
2)What to do when you cannot find the cause of a crash?
1) Yes, they may have a custom ROM; they're known for doing things like this.
2) Unless you can reproduce it, you [probably] can't fix it.
Can you contact this customer? If not, there may be nothing you can do.