[BUG] androidx.security version is overriding our app version

[jt-gilkeson]

Summary

Our app uses "androidx.security:security-crypto:1.0.0-rc02". When updating from Stripe 18.2.0 to 20. 5.0 we see in the dependency tree that Stripe is overriding the version used in the app to "1.1.0-alpha03" which causes problems.

Other libs don't seem to do this - even though they use a different version of the security-crypto it doesn't override it for the app.

Is there something we can specify on our side or preferably that you can change on your side to not override the version outside of your library?

Like would the following be safe to do?

    implementation('com.stripe:stripe-android:20.5.0') {
        exclude group:'androidx.security'
    }

[brnunes-stripe]

Hey @jt-gilkeson, thanks for reaching out!
We use 1.1.0-alpha03 because it supports Android API 21 (since alpha01). If you exclude it, and at runtime 1.0.0-rc02 is available, I think that would cause an error or crash on devices with Android 21.
If your app only supports API 23+, then it might be safe to do what you're suggesting, but you should make sure to test on different versions.
A better solution would be to upgrade your dependency, if that's possible.

Other libs don't seem to do this - even though they use a different version of the security-crypto it doesn't override it for the app.

We're not doing anything special regarding the dependency. My understanding is that by default Gradle will resolve to the most recent version of the library, I think it just usually does that silently because it doesn't detect any issues.

[jt-gilkeson]

Thank you for the quick reply.

If your app only supports API 23+, then it might be safe to do what you're suggesting, but you should make sure to test on different versions. A better solution would be to upgrade your dependency, if that's possible.

Yes we are 23+ Is there any particular functionality of the SDK that we should concentrate testing on?

Unfortunately there are problems with updating the version, something to do with newer versions having an issue with keystores when people get a new phone and their data was automatically transferred (there are a lot of reports of others having this same issue - with updating the lib), while we can change the app to stop transferring the data between phones going forward, we already have a large existing customer base so we are somewhat locked-in to 1.0.0-rc02 for the foreseeable future.

This article talks about how libraries can make their dependencies more flexible to avoid this type of conflict:
https://jeroenmols.com/blog/2020/11/11/library-dependencies/

[brnunes-stripe]

We use EncryptedSharedPreferences from that library, and our implementation, uses the MasterKey class which is new to 1.1.0. So I think if you exclude 1.1.0 and include 1.0.0, it will crash at runtime.
Once #5340 is merged and a new version is released you'll be able to test by calling PaymentSheet.reset, which will try to clear the EncryptedSharedPreferences.

The article is interesting, but this is an edge case not really covered by it, due to your restrictions and the non-backwards compatible changes made to 1.1.0. Even if we loosen the dependency requirements, we'd still need 1.1.0+.

One possible solution for this is to somehow rename the package so that you could ship with both 1.0.0 and 1.1.0, but they'll have different class names so they won't conflict. I haven't looked in depth, but this project might be able to help https://imperceptiblethoughts.com/shadow/introduction/

[jameswoo-stripe]

Hi @jt-gilkeson have you found a potential workaround that suits your use case?

[jt-gilkeson]

Hi @jt-gilkeson have you found a potential workaround that suits your use case?

Unfortunately there doesn't appear to be quick and easy solution to this situation. We'll ether have to try to wipe our users shared preferences if they can't be opened (not a great experience) or we'll have to try that rename package workaround.

@brnunes-stripe I didn't follow what you meant by:
Once #5340 is merged and a new version is released you'll be able to test by calling PaymentSheet.reset, which will try to clear the EncryptedSharedPreferences.

Are you saying test excluding 1.1.0 and calling that method?