Debugging?
Monkey Targets Forums/Android/Debugging?
| ||
| Our latest creation is progressing nicely, but we are suffering from the dreaded "occasional" crash. Things are fine normally, but sometimes we get a "Unfortunately [app] has stopped responding". The app is compiled with the debug option in Monkey (85e), but unfortunately we don't get any debug info when the crash occurs. like we do in HTML5 builds. Due to the virtual joystick control mechanisms, it's not easy to reproduce the crash in another environment. Any tips on the best way to figure what is happening? We have quite a lot of <Stack> objects, my bet is there's a gremlin in our code around removing things from the stack. Any thoughts or pointers appreciated! |
| ||
| When a debug Monkey build for Android crashes, it should have debug info output to ADB, which should then be routed to your console in Ted, Jungle, or any other IDE using standard I/O. You can't debug using 'DebugStop', but you can tell where it's called, from the ADB output, and you can tell where an exception (Any kind) is thrown (And not caught). Android debugging's pretty lack-luster, though. Basically the last line executed will be output at the top regardless, which is enough to understand where the crash happened. Unless of course, it's a native-code issue, at which point, you'd be debugging a translation, or a separate module/file. Either way, if something happens, you'll get the last known line of your Monkey source at the top of the console-output. Just make sure to make a "Debug" build. Printing (Standard output) will always be routed to ADB, and ideally, your console-window. As far as stacks go, as long as you aren't doing anything too crazy, like adding several thousand references to one 'Stack', I doubt that's what's making it crash. That being said, I should also bring up that 'RemoveEach' on a 'Stack' is a bit slow (Though overall, it's not bad), but that's because it shifts the contents. So, if you constantly remove elements like that, it shouldn't cause any major memory gimps. If Dalvik runs out of memory, it'll at least garbage collect before crashing. In other words, running out of memory's only an issue if you keep the objects referenced somewhere. Or, you know, you're taking excessive amounts of it. But, most Monkey objects are around one to two cache-lines long, depending on the chip, so other than grouping, they're pretty small to begin with. |
| ||
| Thanks for this info - I must be missing a trick in terms of getting my APK file onto my Android tablet and having that connected up to a console. Right now, I just grab the .apk created by Monkey, and install on my tablet (via Dropbox). I guess what you are portraying would require me to connect my tablet to my PC via USB and for Monkey to push the compiled app onto my tablet? I've never tried that, and will give it a whirl. Re: stack. I have some code which is processing two stacks (looking for collisions via a for..next loop nested in another for.. next loop). When a collision happens, I remove elements on the stacks, and I may have got some logic wrong here.. will check. |
| ||
| @silentshark: For most devices you just need to install the Google USB Driver(s): http://developer.android.com/tools/extras/oem-usb.html - This page may also help: http://developer.android.com/tools/device.html As long as you have the device plugged in, and you install the correct driver (Found in the Android SDK Manager), you should get a notification on the device. It should prompt you about something like USB debugging, charging, or file transfer/sync, just hit it, and you'll be able to enable to set USB debugging. If that doesn't work, there may be other settings you need to change. There's also a chance the generic Google drivers won't work. At that point, you need to look up drivers for your device, or check Google's documentation; as linked above. Once that's settled, just build and run from Monkey, and it'll connect to ADB automatically. ADB will upload and connect to your device over USB. The alternative is to use the Android Emulator that comes with the SDK. This is a pretty good option, but only if you're running basic stuff, or you have a CPU with Intel's virtualization technology, or AMD's technology (Linux only from what I understand). ADB will also work with the emulator, but it may take a while to upload or detect the device. |
| ||
| Great, I will try and install a better USB driver. The current one works, in terms of allowing data transfer, but doesn't seem to allow debugging. Thanks for all you advice. |
| ||
| The other thing I found useful was running the Bluestacks emulator on my PC, and connecting adb up to it, to see the debug logs. Following compilation for Android with the debug option, and install onto Bluestacks, the magic commands were: adb connect 127.0.0.1:5555 adb logcat Hope this helps someone, sometime! |
   |