It appears to be, as you suspected, the Android emulator that is causing the issue. Some users have filed an issue on Google Code. If you scroll down past all of the "Me Too's," you'll actually find useful information; there appears to be a workaround involving /Applications/Eclipse.app/Contents/MacOS/eclipse.ini for some.
I increased the heap space used by Eclipse, and haven't experienced this problem since.
In eclipse.ini I used the following values:
--launcher.XXMaxPermSize256m
-Xms256m
-Xmx1024m
The same issue has a duplicate. In this thread, they mentioned a slightly different method where they added -vmargs between --launcher.XXMaxPermSize256m and -Xms256m
And I assume you've installed Intel Hardware Accelerated Execution Manager, as this is a requirement for the Android Emulator. However, in the comments, people note that it doesn't work with Mountain Lion and they had to disable it for Android Emulator to work.
For your question about the number of installs Lion from the App Store will give you, this is directly from Apple's EULA (emphasis added):
(i) to download, install, use and run for personal, non-commercial
use, one (1) copy of the Apple Software directly on each
Apple-branded computer running Mac OS X Snow Leopard or Mac OS X Snow
Leopard Server (“Mac Computer”) that you own or control;
So, assuming that this is for personal, non-commercial use, Apple lets you install Lion as many times as you like on the Macs that you own or control.
Understanding a panic is quite easy: The core scheduler for the OS got lost in the weeds. This is a fail-safe in that the computer decides to stop running itself.
The inner most portion of the OS's control logic got derailed and the system was designed to drop all processing and leave a log file for engineering to troubleshoot further.
You can see these files after a restart by looking in /Library/Logs/DiagnosticReports and especially if you have several that recur (in the same day or hour) it is sometimes useful to compare the reasons and patterns in the file.
Back to the high level - how to understand this design is that some fundamental things went so wrong in the core of the operating system, the designers have all concluded that it's almost certainly worse to keep running with this error than to halt the computer immediately.
Think of this as a fail-safe at the level where the computer decides what program or instruction gets to run next. The computer is literally out of ideas how to continue, so it dumps what it was working on (as best as it can recollect now that things are off the rails) and stops immediately.
Kernel Panics are some of the hardest to debug unless you have one that you know exactly how to trigger it. In that case, it's pretty easy to keep eliminating possibilities until the source is obvious. Here is the best writeup of Mac specific information on Understanding and Debugging Kernel Panics. It is very technical, so take what you wish and move on to the steps below.
Like anything, it's best to isolate the problem to avoid chasing down thousands of potential causes. If you want to be systematic about how you isolate the cause (or worse causes) of a panic, here are the two articles with general steps for isolating software causes before investigating hardware.
In your specific case - Core Storage is either the root cause or just an innocent next bystander that "falls into the hole" that another process left behind. Good Luck if you decide to isolate this, hopefully it was a one-off error and you can just use your Mac in peace.
Best Answer
Did this happen after a system update perhaps? It seems that a lot of people have similar problems after the "Thunderbolt update" from Apple.
check this thread