-
Notifications
You must be signed in to change notification settings - Fork 62
Back-to-back calls to read() throws IllegalStateException #1
Comments
If anyone else is hitting this, our workaround is:
|
Adding subscribeOn(mainThread()) might also do the trick. This will defer On Wed, Mar 23, 2016, 7:56 PM Dan Hill [email protected] wrote:
|
Matt had me give this a shot. Didn't work for me, unfortunately. |
Can you use a retained fragment to retain the same Observable instance? On Wed, Mar 23, 2016, 8:14 PM Dan Hill [email protected] wrote:
|
I definitely can give it a shot. Is there any drawback to the |
The repro in the sample does throw the same exception, but that's intentional since it calls |
Shouldn't the |
Ah, yeah. You are correct. |
The time above is apparently less than the time it takes between |
The wait is unknown. We trip the cancelation signal which makes a binder call to the OS which has to make a binder call back into the app to signal successful cancelation. |
Right. It's an unfortunate case where you're trying to save us from the platform bug, which is definitely great! This is just a bit of a sharp corner in the api here that I didn't expect. I initially expected that if I had unsubscribed from the previous I'm not sure what a resolution here would look like. Perhaps just mention this case in the docs somewhere? Trying to delay the second call to |
I think I've found an interesting point here: due to the platform bug, it's also possible for the lockscreen to steal whorlwind's callback to Repro steps (can use latest version of Robinhood to repro):
edit: |
Ugh... that bug is the worst. Does the lockscreen register its listener before your
:flag-ca: |
Haha, sorry! Is there a log statement to look for in logcat that you're aware of for when the lockscreen registers? I'm sifting through a log now, but my device is very verbose :( |
Ah, I was actually just able to repro by turning the phone completely off and then running the app from Android Studio - so in that case the lockscreen would be registered before both |
So I think my statements above about the lockscreen hijacking whorlwind's onAuthenticationError call are untrue. After debugging through more, it seems like this is happening:
|
I can reproduce what @danh32 is seeing with the lock screen just by toggling the power button on the Nexus 6P. Once to turn off the device screen while my Activity is in the foreground, and then a quick two hit toggle about a second afterwards (I have quick launch of the Camera disabled). For whatever reason, this ends up resuming and then immediately pausing my Activity, even though it's still sitting behind the lock screen. The workaround I came up with was to check that |
@alan-rodriguez, are you getting another |
@mattprecious Yes, I do get another But before that, I am seeing an cycle of |
Alright, that's interesting. I was worried that It sounds like that's a good solution for that case. |
I have a pretty hacky idea for working around this if you're interested @mattprecious. If |
I've found a bit more, here. If you subscribe and unsubscribe from the I'm able to get my app to crash by backgrounding and foregrounding it enough, and can get the whorlwind sample to crash by backgrounding, foregrounding and tapping 'read' enough times (6-8, generally). |
@danh32 if you remove the logcat filter for your app, do you see the following logs from the system:
Android won't call the fingerprint authentication callbacks if your app is backgrounded, and it seems like there's a race condition with when As you say, whenever there is a missed error callback, Whorlwind becomes completely unusable without resetting that flag. |
@grandstaish Yep, I'm seeing those logs. It's interesting, since the code at https://android.googlesource.com/platform/frameworks/base/+/5e35422/services/core/java/com/android/server/fingerprint/FingerprintService.java seems to indicate that it only checks for the app being in the foreground when trying to authenticate, not when trying to cancel. I haven't dug into the history to see if that behavior has changed since the Marshmallow release. |
I'm bad at navigating AOSP, but found here: https://github.com/android/platform_frameworks_base/blob/master/services/core/java/com/android/server/fingerprint/FingerprintService.java#L764 Looks like you're right, race condition as to whether we're backgrounded or not. |
I'm seeing some
java.lang.IllegalStateException: Already attempting to read another value.
being thrown in the wild. I'm able to reproduce locally by rotating my device a couple of times with our FingerprintFragment up. As best as I can tell, there's a race condition between the CancellationSignal notifying the AuthenticationCallbacks which resets the AtomicBoolean and then the Activity/Fragment lifecycle's onPause and onResume.I can also repro in SampleActivity by hardcoding immediate calls at the end of onResume:
The text was updated successfully, but these errors were encountered: