This has nothing to do with eclipse. Every other question about logcat not displaying anything on this site is about eclipse, so far as I have found. This is not one of them.
I have an LG G3. It's rooted and bumped. It's pestering me ALL THE DAMN TIME to update (there's apparently no way to shut this off with the Verizon model). I really, really, REALLY want to use a custom ROM to end this pain. Thing turns on the screen and leaves it that way until I notice and tell it to bug me sometime within the next 24 hours.
I set it up with Skydragon, which from what I can tell is the stock ROM de-bloated and slightly modified to run faster and more efficiently.
Apparently though it has no log. I can connect to it with adb just fine. I can upload apps and run them. What I can't do is see anything at all in logcat. I even tried opening the main log device on the phone, it was empty.
My best guess is that either the kernel doesn't have logging facilities in it, which would seem stupid so I doubt it, or the logging service isn't turned on (assuming there is one). I don't see any log service file in the init.d directory (skydragon I believe uses init.d).
Anyone know what I need to do here to get logging working? I'd sort of like to stick as close to stock as possible at least for the time being. It's getting frustrating though. Either I'm constantly arguing with the system upgrader, or can't debug my apps with logs. Neither is what I'd call acceptable.
I did try asking this same question in the skydragon thread at xda but got no reply. It's been a week so I don't expect one.
Was able to get this going by selecting the stock kernel in the aurora install. With this done the expected logcat content is there. There may be a better answer, but it's yet to be provided. I'll leave this open just in case, but this be here for those searching for WTF might be going wrong needing to fix it.
Related
I got this report (second hand) from a user of my Android app:
Unfortunately after downloading the app and opening it my phone
stopped working immediately, was locked up and unusable. I took it to
a repair shop and they said the only fix was to wipe the phone clean
and start from scratch.
So far I don't have any other information such as type of device. Besides getting more info from the user, does anyone have ideas on how to research something like this if it's even possible? No developer or tester has ever had this happen, and it's the only report from a user that we've gotten. It's always possible it's a coincidence but I doubt we could get the user to try it again to find out and it's disturbing to think our app could be doing this.
Without having hands on the device, there's nothing you can do.
I doubt that an App actually can put an (unrooted) device into a state where only factory reset helps, but factory reset is the all-time "have-you-tried-turning-it-off-and-on-again" solution for Android, so that's probably why the repair shop sugested that.
If it's possible for an app to so though, this is not your problem, but Androids one. It might be very well something the branding company messed up in their version of Android.
My company got me the same kind of device and I figured out (I think) that it was a huge icon file causing the problem. For me, the symptom was the application list in settings crashing; I never got the "system UI has stopped" error.
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.
The title speaks for itself, but I would add some pointers I've noticed along the way.
I would like anyone who also experiences the end result while developing for Android to try to reproduce this and see if this scenario is really the case.
The crash happens when Logcat is overpopulated. By overpopulated I mean that from a point in time, if you would leave a device connected in debug mode for a while, and you would look at the Logcat view, it would display only the new 'delta' lines added to the log in the past short interval of about two seconds.
If you would pay attention, while the Logcat is overpopulated, the device which is been debugged, responds slowly to user interaction (this can be your indication, that the Logcat is overpopulated while testing your application), and perform other actions ridiculously slow.
If you would leave the device connected and more logs would be added, there is a short interval 5-10 seconds, where Eclipse starts to behave weird, and after that, there is nothing you can do, Windows 7 freezes and only hard reboot allows you to get back to work.
I can reproduce this every time, if I would just leave a device connected in debug mode with an application running.
I've Googled this and came up with nothing. I assume that if me and my colleagues encounter this (we have the same Eclipse setup), then other should also experience this, so before posting a bug, I would like to confirm this...
Details:
Windows 7
Eclipse 3.6
ADT 10.0.0.v201102162101-104271 (latest for today)
I have the same problem here. I've been troubleshooting this for months! Mostly because it's been extremely difficult to find anyone with the same issue. (I was actually linked to this post from the bug report that Android Developer provided.)
I've been working with someone on a similar Stack Overflow issue. He thought the problem was his IDE until I reported that I was experiencing the same issue, but with a different IDE. Together, we've been able to whittle the problem down to either the device itself or the drivers. We recently just excluded the USB cables as the culprit.
However, the problems reported in the Google bug report are exactly what we've been experiencing. It makes sense that ADB might be where the problem ultimately lies.
Hopefully, this post will help create some search-friendly connections between the other posts.
Other Stack Overflow post mentioned above -- Android development in IntelliJ IDEA causes computer to freeze
Google bug report, Issue #24171 (originally posted by Android Developer) -- http://code.google.com/p/android/issues/detail?id=24171
I also have a similar problem. Sometimes, the Windows OS completely freeze when an Android device is connected.
I'm not sure why it happens, but I think that it only occurs when the ADB is active.
Here's a bug report I've found recently about this:
adb causes whole Windows operating system to freeze randomly
After using a USB from the back, and installing Windows 8, the problem doesn't occur any more.
However, it's Windows 8, and I wish I used Windows 7. For some reason, Microsoft didn't provide a way to go back...
Try setting your Eclipse Android Settings for the maximum amount of logcat messages in the buffer to a lower value.
This should help
I don't want to jump to conclusions, but I think I've found the real issue which causes this halt...
I'm going to make some assumptions, and if one of these does not fit your scenario, let me know:
Assumptions:
This only happens on a chargeable computer... Be very very sure before dismissing this assumption.
This happens when a laptop is connected to the adapter, and is being charged.
Cause:
This happens when you use a custom adapter, and not one that 100% fit your computer.
According to my experience, once I've used my home adapter on my work computer, the crash reoccurred over, and over, and over... drove me nuts... and when I got back to work, and used the proper adapter, the issue vanished!
Same with my home computer, and work adapter.
Lend me your thoughts...
I use IntelliJ IDEA to write Android apps, and use the DDMS Windows application to view the Android logs (separate from the IDE). It works fine, but after a seemingly random period of time, the logs vanish, except for one line of log, which gets overwritten with incoming logs. I have to shut it down and restart it, which combined with the delays of deploying an app to a device over ADB to debug and test is pretty tiresome.
Is this a known issue with DDMS? Is there anything I can do to make it work consistently without breaking itself?
Are there any other Android log viewing applications for Windows that work better? I'm not very fond of the IntelliJ IDEA one. My favourite is actually CatLog on Android itself, but on a small-screen device it's not a great experience.
It's not about the time, but number of lines being recorded. As Dave C said in the comment, just clear the log and it will be fine
Have you tried looking at "Why doesn't LogCat show anything in my Android?"? The top voted answer may solve your problem