The trick is interpreting what is shown in Eclipse window or crash report.
The Eclipse view gives you a running 'dialog' about what is actually happening. You can see when errors are reported as they happen and that can be helpful.
The bug report (which I was finally able to generate and send) is different. It first reports information about the current state (one of the reports is the output of the 'top' *nix command). Then it starts reporting all kinds of things like what threads are running and memory and stuff.
Eventually you get to a section labeled 'KERNEL LOG'. This shows (not quite understandable) events as they happened for some period of time ('star date' type time stamps). But you can sort of see when some processes start and stop (or fail).
Then you get 'SMAPS OF ALL PROCESSES' and 'BLOCKED PROCESS WAIT-CHANNELS', no clue.
After that you get 'SYSTEM LOG (logcat -v threadtime -d *:v'. This is the first really useful section. It gives you events with human readable time tags and messages. You search through this to the first occurrence of your package id (com.yourcompany.yourapp) and you can start tracing it via name and process id (pid). The process id will be associated with the start of your package and then appear as the third or fourth value in each line when the reported event is for it.
More than one log is output and the time stamp starts over.
After the log outputs (it looks like three of them), you get to 'VM TRACES JUST NOW'. This looks like information about processes (identified by pid) that are running and the threads (?) they have.
Then some NETWORK stuff and QTAGUID CTRL INFO (?) and QTAGUID STATS INFO, followed by some more NETWORK stuff and then LAST KMSG (kill message, I think). Then (after a long bunch of kmsg stuff) PING and DUMP WIFI, INTERRUPTS, SYSTEM PROPERTIES, VOLD DUMP, SECURE CONTAINTERS, FILESYSTEMS, PACKAGE SETTINGS and a bunch of others (all pretty useless for our purposes).
Eventually you get to the 'DUMP OF SERVICE <servicename>' section. This might have useful information if the AppGameKit app is shown.
Then some WINDOW MANAGER SESSIONS.
Then, major section, 'Running Application Activities'. It shows activities for all activities currently running and may have information useful if your app is still running.
After that is 'Running Application Services'. Maybe useful, if the AppGameKit app shows up. And last is 'Running Application Providers' where some dump information may exist for each app, but it doesn't look very useful.
The screen shot provided by the Nexus 7 bug report is useless since it always sends the screen of the Developer options settings page.
I just created a debug log with my current WIP actively running. I was then able to follow its progress in the SYSTEM LOG section. It included messages like 'native-activity: Failed to create audio player' and 'threaded_app: New Input event: type=2...'. This second one was where I had tapped a button in the app. You can also see where the app loses focus, saving an instance state before it does.
The logcat is probably the most useful for seeing what your app does.
Best bet is to search for your app package and then follow the pid in the logcat to see if you can figure out what happens to it.
Cheers,
Ancient Lady
AGK Community Tester and AppGameKit Master