When testing on real Android devices, I run my application from within Eclipse and have access to the logs and errors using DDMS and LogCat.
However, there is one device I own that I cannot connect to my PC, and therefore I cannot view on DDMS.
When this application loads, it throws an Exception. However, I have no idea what this Exception is.
How can I view such errors or logs on a real device?
Install a logcat viewer such as aLogCat. It provides various ways for you to view, save or share the log output.
To answer your question more generally, you can include BugSense, whenever your application crashes on your clients' devices, it will automatically send the crash report to you, including useful info like stacktrace, Android OS version, screen dimensions, device name, etc...
I didn't realize how buggy my applications really are in the field until I started using it.
There is a bunch of logcat reader apps - like CatLog or aLogcat, capable of viewing logs, filtering or saving them to the external storage. Just search the Market for "logcat".
Related
It is not really a programming question. I have this app that continues to crash on my phone, but works fine for everybody else. I used to program android apps, so I have knowledge in this field.
It something on my phone probably it always crashes at the same stage. I did not program this app. How can I still get the details of the error or the trace of the exception?
I would suggest plugging the phone into your computer or laptop, opening up the Logcat tab in Android Studio and viewing the exception details as the app crashes.
This can be done separately from Android Studio using ADB but it involves more steps.
Of course, make sure that you have enabled USB debugging on your device before this.
I have an app installed on my device.
An app that I developed, but I haven't got the source code anymore.
Is it possible to attach log cat to this app?
yes you can, just enable usb debugging on your android device, and plug the device where you have the application installed on it, by that, you will see all the logs on logcat.
Depends if you've left logs in the code. If you did, the easiest method would be probably going into your Android Studio and checking you Android Monitor tab. You can switch devices / applications there.
If you don't have any logs and your question actually means you want to add some logs in, then I'm afraid you can't reliably do that.
I have a bug that happens very randomly, so I rely on a LogCat monitoring app I bought off the Play Store, to see the exceptions thrown on my device when it happens. Since using Jelly Bean, I'm seeing no logging. I've read that, with Jelly Bean, an app can only see the LogCat output of itself.
So outside of rooting my device, is there any way to read the LogCat output of my app on my phone directly? I know I can use Eclipse, but, like I said, it happens so randomly and I can't manually recreate it.
So outside of rooting my device, is there any way to read the LogCat output of my app on my phone directly?
Not really. You can read discussions on aLogcat bugtracker about this issue:
After doing some reading and some testing, I've found three ways to make aLogcat work, all of which use root.
More detailed discussion about READ_LOGS permission is not granted to 3rd party applications in Jelly Bean (api 16)
What do you think about writing directly to the screen using a textView? Of course this would only be for a debug build.
This post contains code that prints logcat errors on the screen Write android logcat data to a file
Now all that's left to do is to put try/catch stmts in your code, where the try surrounds code you think is problematic. The catch delegates to writing the error message to your screen.
I was wondering if there is any way to get any feedback of what's going on behind the scenes when running an app on an Android device. If I use the emulator and eclipse I can see what's happening in the logcat. But I'm making a program with ROS android and it I cannot run it on the emulator. Now my program crashes and I don't know why. Is there any way I can get more information?
Thanks
You can use adb to debug the app on your device. See http://developer.android.com/guide/developing/device.html
I can think of a couple (less than elegant) ways to try and find out what's going on.
1) Display toasts from potential problem areas (Does it have a screen?)
2) Write logs to the SD card (does it have an SD card??)
EDIT
I wasn't thinking clearly... you have to be able to load the program to the device, so you must be able to connect it to your PC. So, as Agarwal pointed out, you can most likely hook it up, run it on the device/robot/whatever and see what happens with the logcat.
How can i debug when application works without error in emulator but force closes while doing SQLite operations on some screens?
Connect your phone to your dev machine
Make sure the emulator is not running
Open a command prompt and run adb logcat
Use application on your phone and trigger the error
Review the resulting stack trace in the logcat output
You can also view the logcat output in Eclipse via the debug or DDMS perspective.
You should connect the phone to your development machine and look at Logcat (or use the debugger) to see what is going on in the stack trace. You can also install an app (like CatLog) on the phone to view the log.
You just connect you phone and use debugger. When it is open just choose your phone...you can use and logcat too...
Everyone else commented about the technical tools available, so I'll try to explain the process we have with our app. Our app is pretty widely used, so we have a bunch of different devices to consider.
Create a beta group. There are a lot of devices, and it's impossible to test on all of them yourself unless your company has very deep pockets and you have a lot of time to test. Get a group of users together who are ok with things breaking, and ask them to beta test.
Look at what's different. This one seems obvious, but it's surprising how often this trips us up. If an app isn't working on certain devices, what's different about those devices? We once had a bug that only occurred when the app was in landscape mode, so we saw it mostly on devices that default to landscape mode. When you're trying to find the cause of a bug, ask yourself what the difference is between the scenario where the app doesn't work and the scenario where the app does work.
Use the tech available. Sometimes, the last two don't catch all the problems. Sometimes, you get a weird edge case. We had 2.3 devices that didn't implement a deprecated method-- even though the method was deprecated in 3.0. For whatever reason, they didn't implement the method and left us without its replacement, so we had to use a backwards compatibility package. But the only reason this came to light was because we got access to the logcat reports from users who experienced the bug. Moral of the story: manufacturers do weird stuff.
You're not going to be able to catch everything. There are just too many subtle and non-sensical differences. But (especially with beta testing) you should be able to catch 99.99% of the problems before they happen.