import new version Browser Switch and add its integration
IMPORTANT: this PR is waiting for the new Browser-Switch version to be released before it can be reviewed/merged. Thank you for your patience!
Summary of changes
- Added the new version of Browser-Switch that supports AuthTab to core SDK
- Added integration of the new AuthTab flow to demo app
- IMPORTANT data binding needed to be disabled to compile with Gradle 8.9.1
Checklist
- [ ] Added a changelog entry
- [ ] Relevant test coverage
- [x] Tested and confirmed payment flows affected by this change are functioning as expected
Authors
@noguier
Dependency Review
The following issues were found:- ✅ 0 vulnerable package(s)
Scanned Files
- settings.gradle
Looks like there's a unit test failure. Does that happen locally for you as well?
@saralvasquez yes, it was happening local as well, just fixed 406a975, thank you!
great questions @jaxdesmarais and @saralvasquez.
In browser-switch we updated androidx.browser:browser to 1.9.0 to take advantage of the AuthTab, this introduced the need to update com.android.tools.build:gradle to at least 8.9.1, as well as compile/targetSdk to at least 36.
When importing the library into this repository we also needed to make the same updates, however, we also needed to disable data binding in only the demo module. This is because 8.8.0 was the first version of the android gradle plugin that requires kotlin 2.x if a project is using the databinding ktx library.
So that we do not introduce even more version changes, me and @tdchow decided that it is fair to assume that if the merchant wants to use databinding ktx they will have to update their kotlin versions.
Please let me know if it makes sense, I am happy to add CHANGELOG entry as well. However, I do think that @saralvasquez raises a fair question of whether or not it should be a minor version change for our SDK.
Please let me know what would be the best way to proceed?
Ok yeah the data binding changes being isolated to the demo module sounds reasonable to me. I think the only thing that might be a little wonky then is the gradle version for a minor update
Hey all - to add additional context to @noguier's above comment. This ended up being a cascading dependency version changes.
Looking at our changelog on when we've updated our compile SDK to the next Android API version, these were the timings of the last 3 versions:
| Android API Version | Android SDK Release Date | BT Android SDK Release Date |
|---|---|---|
| 35 | 2024-06 | 2024-08 |
| 34 | 2023-06 | 2023-09 |
| 33 | 2022-06 | 2022-10 |
All of these updates were minor version bumps. The update in compile SDK is technically a breaking change, but not due to the BT SDK's interface.
So I'd say it's safe to up the compile SDK version to API 36 if we're following the same cadence as the previous versions. With compile SDK version set as 36, it requires AGP 8.6.0 and above which was released Aug 2024.
https://developer.android.com/studio/releases#api-level-support https://developer.android.com/build/releases/past-releases/agp-8-6-0-release-notes
Ok yeah looking back at the CHANGELOG, gradle version updates didn't require a major version bump. Cool! I think this is ready once a CHANGELOG entry gets added 🥳
It looks like the bump to 35 was in a major version since it was in one of the betas. We should absolutely call all of these out in a CHANGELOG since that is what we have done historically. I just want to ensure we don't expect these changes cause any major issues with our merchants especially going into the holidays. We just need to be extremely diligent on what potential impact or a rollback strategy would be for the change as well as documentation to avoid inbounds.
Yeah 35 was a major but it looks like 34 and 33 was a minor version bump. But I feel ya on not wanting to push anything with any questions marks
Hi all , I added the CHANGELOG entry in b71bca6, let me know if it looks ok!