Revert recreating the encrypted token storage on initialisation error. #61
Conversation
If the EncryptedSharedPreferences can't be created, try to delete the existing file and delete the master key. See tink-crypto/tink#535 for more info.
The alternative is to cause crashes every time the app starts, at least that's what's happening to Podme. So the app becomes unusable until users manually clear app data. Reinstalling the app will still cause the app to crash on start |
|
If my understanding is correct, disabling backup of Shared Preferences in Android Manifest should mitigate this issue. Proposed solution solving edge case will cause severe business impact on other users of the SDK. GeneralSecurityException is to wide exception to always log user out. If we'll go with this solution is should be exception specyfic to this case. |
We tried to set allowBackup=false and it made no difference. We could still recreate the issue by reinstalling the app multiple times. Besides, what's the benefit of ignoring this, the encrypted storage can't be recovered anyways? |
|
Another alternative is to stick with a nonproblematic version of the Tink library |
The problem with propsed soultion is it will log out not only in case You've described but others as well. And based on experience from summer - this is not always non recoverable cases - as GeneralSecurityException covers multiple scenarios. It should be narrowed down. In general - we should aim to solve this specyfic case instead of logging people out as default solution... |
|
Closing this as work is ongoing to replace the storage backed by |
If the EncryptedSharedPreferences can't be created, try to delete the existing file and delete the master key.
See tink-crypto/tink#535 for more info.
This might happen when a user uninstalls an app using this SDK, and then re-installs the app again.
Follow up of #50 and related to #48.