Additional information:

https://groups.google.com/group/android-developers/browse_thread/thread/658133be
c901d7e
http://stackoverflow.com/questions/5915597/android-error-java-lang-illegalstatee
xception-trying-to-requery-an-already-clos

This looks to be a known issue where Honeycomb has deprecated 
Activity.startManagingCursor() in favor of a new android.content.CursorLoader 
class. This new class is introduced in API Level 11 (Honeycomb or 3.0), which 
isn't very useful for apps like Cryptnos that want to provide backward support 
(in our case, all the way back to Android 1.1 or API Level 2).

Fortunately, I think I found where the problem lies. Because Cryptnos encrypts 
the database and the process of decrypting the site list is lengthy and 
expensive, the main application code (CryptnosApplication) does this work in a 
worker thread and stores the decrypted site names/tokens in a simple String 
array, which it holds on to for as long as the app is running and the site list 
is not deemed "dirty". The first time the site list is requested (by Generate 
Existing, Exit Existing, Delete, or Export), this code decrypts the list and 
stores it in the central app class, then passes the String array to the calling 
activity. Later on, if another activity requests the same list, the decrypted 
and cached list passed to the new activity without the overhead of decrypting 
it again. If the site list is changed (i.e. a new set of site parameters are 
added to the database), the activity that makes the change informs the main app 
class that the site list is "dirty" and that it needs to be rebuilt. The next 
time the site list is requested after this, it is queried, decrypted, and 
cached again and marked "clean" until another "dirty" change occurs or the app 
closes down completely.

The main app's worker thread for decrypting the list forces the calling 
activity to manage the database cursor by calling its startManagingCursor(). 
Unfortunately, I later called close() on the actual cursor object without 
subsequently calling stopManagingCursor() on the activity. In the reported 
situation above, tapping Generate Existing at the main menu launches the 
SiteListActivity, which forces the main app to build the site list. 
SiteListActivity is told to manage the cursor, but then CryptnosApplication 
closes it, leaving SiteListActivity with a null cursor to manage. The user goes 
on to the GenerateExistingActivity, generates their password, and taps Back to 
return to the site list. SiteListActivity resumes and attempts to manage the 
cursor it was told to manage, but the cursor has been closed, resulting in the 
error.

I've got a change in place that seems to be testing OK so far. Rather than just 
closing the cursor, the decrypter thread in CryptnosApplication now tells the 
caller activity to stop managing it first, then closes the cursor. This seems 
to eliminate the FC reported above in Honeycomb and seems to produce no ill 
effects in 1.6. More testing is required before this gets pushed out, however, 
and I want to make sure I don't find any other instances where this might be 
occurring.

Should be fixed with the new 1.2.5 release.