3.1.0: Failed to unwrap key #13
Comments
|
Seeing the same when switching between profile and release builds. |
|
Same issue here... works fine when installing locally via ADB, but fails when installing from Play store Alpha. |
|
I found a workaround: The issue was throw because Android application has backups on Google Drive enabled. After disable it in the application with: android:allowBackup="true" It works again.. (More info on https://developer.android.com/guide/topics/data/autobackup#EnablingAutoBackup ) ORIGINAL POST Right now I can't run the project. This is my output What I'v tried:
My Flutter Doctor |
|
I found two similar issues: I applied this hack and pushed branch with it. Please try version from branch |
|
Fighting with the same problem right now. Your branch unfortunately did not change things for me. Without having investigated the call chains in detail, I did notice that the repeat loop was around a different place than the one the exception appears to be thrown from (unwrap). Is that intentional, like an early test? The most notable oddity, however, is that all builds work flawlessly up to a versionCode of 17. Any build with a higher number fails, any build with a lower number works. Does that help in any way? |
|
I've made a separate implementation on flutter_keychain which seems to be working fine for me now. |
@tom95 , I am testing on 8.1.0 and still not able to reproduce. So couldn't get the reason why the secret key is encrypted by another key pair. For now I can add fallback logic: if unwrapping failed, delete all data and start from scratch. |
|
@mogol Ah I did actually mean the app's versionCode, not the OS's. I have no clue why, but any versionCode in the app/build.gradle of 17 or lower threw no error. Starting from 18 any versionCode I tried (18, 19, 20, 100, 1000) exhibited the error. I have not tried reproducing that in an isolated environment, but this is the exact behavior as observed in our app. I believe just deleting the data on error should be an opt-in fallback, since that may discard valuable info. I can see how that info is not accessible anyways currently, but if a proper fix comes up at some point I would prefer for the data to still be there. |
|
Please try v3.1.2. |
|
This still happens on v3.1.2 and only in release mode @ernestomar workaround worked for me. Setting |
|
Disabling the backup for android will prevent the crash, but I was wondering if there is a more suitable approach we can take for when we want to keep the 'allow backup' option for Android enabled while also using this plugin? |
|
As I Understand the issue: |
|
Ok thanks for the clarification. |
Lol, how dare I call myself a developer. |
|
I know this issue is closed but after reading both the read.me and this issue it's not clear to me if my intended use case will work with this package; Goal
Disabling automatic backup would clearly not be a good idea in this case. |
|
Thanks, @Sdlion . This solution worked for me. I was encountering this error in both development and release modes. In the case of the release mode, I cleared my cache and restarted my phone to resolve it, but I was able to solve it through the method you suggested. Thanks |
|
@geeky-dawood How did you able to solve it, only by disabling backup? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I did the upgrade to 3.1.0 from 3.0.0. Execution worked just fine, however after cleaning the app data and reinstalling the app this error showed up - which strikes me as odd.
The text was updated successfully, but these errors were encountered: