New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FC in Generate Existing on Honeycomb #5

Closed
GoogleCodeExporter opened this Issue Jun 26, 2015 · 2 comments

Comments

Projects
None yet
1 participant
@GoogleCodeExporter

GoogleCodeExporter commented Jun 26, 2015

What steps will reproduce the problem?
1. Launch Cryptnos on an Android 3.x (Honeycomb) device. There should already 
be parameters saved in the database.
2. Select Generate Existing Password, then select a saved site.
3. Enter the master password and tap Generate. Password should be generated 
successfully.
4. Tap Down (lower left corner) to close the virtual keyboard.
5. Tap Back to return to the previous activity.
6. Android reports that Cryptnos "has stopped unexpectedly" and requires a 
force close.

I think I know what's going on here, but I don't have time to research this 
now. I want to make sure to log the issue so (a) I won't forget it and (b) if 
someone else encounters it, they can already see it's a known issue. This may 
or may not appear in other activities (Generate New or Edit Existing), but I 
haven't had time to check. The issue seems to be Honeycomb specific as it does 
not occur on my 2.2 (Froyo) device nor does it show up in 1.6 (Donut) on the 
emulator. (Using Honeycomb in the emulator is a pain, but I now have a 
Honeycomb-enabled device to test with.)

I'm rating this a low priority mostly because there aren't many Honeycomb users 
out there using Cryptnos yet (or so says the Market) and because the FC does 
not really impair the user's ability to use the program. After the FC, the user 
is returned to the main menu, which is where they were going to go after 
tapping Back anyway. Passwords are still generated successfully.

Original issue reported on code.google.com by jeff.darlington@gmail.com on 3 Jun 2011 at 1:50

@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Jun 26, 2015

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.

Original comment by jeff.darlington@gmail.com on 17 Jun 2011 at 8:43

  • Changed state: Started
@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Jun 26, 2015

Should be fixed with the new 1.2.5 release.

Original comment by jeff.darlington@gmail.com on 20 Jun 2011 at 2:11

  • Changed state: Fixed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment