AuthTab Support Feature #124

noguier · 2025-10-20T21:47:19Z

Thank you for your contribution to Braintree.

Summary of changes

added support for AuthTab
introduced a parametrized constructor, to initialize AuthTabLauncher
added restorePendingRequest() method to handle process kill recovery
updated Unit Tests to support new flow

Checklist

Added a changelog entry

Authors

@noguier, @saperi22

* remove duplicate intent-filter * - Update androidx.browser to 1.9.0 - Update AGP version to 8.9.1 -- requires update to gradle wrapper 8.11.1 - Update compile and target sdk to 36

* remove duplicate intent-filter * - Update androidx.browser to 1.9.0 - Update AGP version to 8.9.1 -- requires update to gradle wrapper 8.11.1 - Update compile and target sdk to 36 * first iteration on AuthTab Setup: added AuthTabInternalClient, removed ChromeCustomTabsInternalClient, modified ComposeActivity & DemoActivitySingleTop to accept the above changes, added toast visuals to see whether or not the AuthTab is supported * Rename .java to .kt * second iteration on AuthTab Setup: rewrote AuthTabInternalClient to Kotlin and added a ClearTop Flag, wrote new AuthTabInternalClientUnitTest, removed ChromeCustomTabsInternalClientUnitTest, modified BrowserSwitchClientUnitTest to accept the AuthTab changes * third iteration on AuthTab Setup: removed CustomTabIntentBuilder, removed tests associated with CustomTabs from AuthTabInternalClientUnitTest,, modified BrowserSwitchClientUnitTest to accept the AuthTab launchURL signature * EOD commit: -Testing the authtab flow on older devices without intents * Revert "EOD commit:" This reverts commit e27cfa1. * Revert "third iteration on AuthTab Setup:" This reverts commit 9803e43. Branching still needed to provide support for older devices. * Completed implementation of AuthTab Support: - added AuthTabInternalClient, - removed ChromeCustomTabsInternalClient, - modified ComposeActivity & DemoActivitySingleTop to accept the above changes, - added toast visuals to see whether or not the AuthTab is supported * Address PR suggestions * Address PR suggestions --------- Co-authored-by: saperi <[email protected]>

* remove duplicate intent-filter * - Update androidx.browser to 1.9.0 - Update AGP version to 8.9.1 -- requires update to gradle wrapper 8.11.1 - Update compile and target sdk to 36 * first iteration on AuthTab Setup: added AuthTabInternalClient, removed ChromeCustomTabsInternalClient, modified ComposeActivity & DemoActivitySingleTop to accept the above changes, added toast visuals to see whether or not the AuthTab is supported * Rename .java to .kt * second iteration on AuthTab Setup: rewrote AuthTabInternalClient to Kotlin and added a ClearTop Flag, wrote new AuthTabInternalClientUnitTest, removed ChromeCustomTabsInternalClientUnitTest, modified BrowserSwitchClientUnitTest to accept the AuthTab changes * third iteration on AuthTab Setup: removed CustomTabIntentBuilder, removed tests associated with CustomTabs from AuthTabInternalClientUnitTest,, modified BrowserSwitchClientUnitTest to accept the AuthTab launchURL signature * EOD commit: -Testing the authtab flow on older devices without intents * Revert "EOD commit:" This reverts commit e27cfa1. * Revert "third iteration on AuthTab Setup:" This reverts commit 9803e43. Branching still needed to provide support for older devices. * Completed implementation of AuthTab Support: - added AuthTabInternalClient, - removed ChromeCustomTabsInternalClient, - modified ComposeActivity & DemoActivitySingleTop to accept the above changes, - added toast visuals to see whether or not the AuthTab is supported * Address PR suggestions * Address PR suggestions * Add support for parametrized constructor to give a merchant a choice to use AuthTab or not * -added the ability to store a callback internally without exposing it -modified BrowserSwitchClient's constructor to only accept Activity as a parameter -rerouted the flow to always call completeRequest and check for the callback result withing the function -added a call to completeRequest in DemoActivitySingleTop.java onResume -added the tests to support the new flow * -addressed PR suggestions -removed toast pop-ups * updated javadoc for parametrized BrowserSwitchClient constructor and completeRequest() function --------- Co-authored-by: saperi <[email protected]>

) * updated default constructor to accept `ActivityResultCaller` as a parameter updated `CHANGELOG.md` * addressed PR suggestions * addressed PR suggestions: switch the version to `unreleased`

# Conflicts: # CHANGELOG.md # browser-switch/src/main/java/com/braintreepayments/api/BrowserSwitchClient.java # build.gradle

sshropshire · 2025-10-21T16:33:22Z

browser-switch/src/main/java/com/braintreepayments/api/BrowserSwitchClient.java

    private final BrowserSwitchInspector browserSwitchInspector;
+    private final AuthTabInternalClient authTabInternalClient;
+    private ActivityResultLauncher<Intent> authTabLauncher;
+    private BrowserSwitchRequest pendingAuthTabRequest;


This is the only part I can see that may not survive a process kill. I wish there was an easy way to access the pending request state that we ask the merchant to hold on to.

Yep. During development, there didn't seem to be a possible way to handle process kill. Since an ActivityResultLauncher<Intent> is used by the Auth Tab API, in the event of a process kill, the merchant app would pass in a new instance of ActivityResultLauncher<Intent> which would not get invoked properly when the merchant app Fragment/Activity is recreated.

But we're open to ideas if there's a good way to handle process kill!

Looks like we encode the request and send it to the merchant: return new BrowserSwitchStartResult.Started(request.toBase64EncodedJSON());.
In case of a process kill, maybe we can have a constructor that takes the pending request?! In that case, we'd expect them to call completeRequest() next? Would that work in your opinion?

I think it could work. On PPCP we have balancing call pattern for start<FEATURE>() and finish<FEATURE>() to allow merchants to pass pending state back into the SDK. The idea for having pending state be a Base64 encoded string is to:

discourage merchants from tampering with the string

strings are supported by virtually all Android persistence mechanisms (Parcelable, etc.) which allows merchants to use their preferred persistence mechanism out-of-the-box for browser switch pending state

It's worth getting creative to come up with a complete solution. Ideally it's good for us to provide a way for merchants to recover from the rare event of a process kill.

Hi all, Sai's suggestion seems to work, I pushed the change and it is visible now at 742b29c

abstracted process kill recovery into a method restorePendingRequest at 387e96c

sshropshire · 2025-10-21T16:35:12Z

browser-switch/src/main/java/com/braintreepayments/api/BrowserSwitchClient.java

+                    BrowserSwitchFinalResult finalResult;
+                    switch (result.resultCode) {
+                        case AuthTabIntent.RESULT_OK:
+                            if (result.resultUri != null && pendingAuthTabRequest != null) {


On a cold start, this value will be null. A false .NoResult may occur here when the host application is recovering from a process kill.

I don't believe the ActivityResultCallback<AuthResult> will get invoked when the host app is recovering from a process kill since the authTabLauncher is not used until the host app/sdk calls start().

I think it might. It's definitely worth trying with developer settings to see if the callback is invoked. I'm looking at the ActivityResult API docs that has this somewhat cryptic message:

It's a tough use case to handle, because the ActivityResult API also places the responsibility on the host application for state restoration, and since we wrap their API that responsibility gets forwarded to the merchant.

I tried testing with Don't keep activities and the callback itself is called, but as you mentioned, pendingAuthTabRequest is null.

I tested the newest change with Don't keep activities, and it seems to work as expected 742b29c

abstracted process kill recovery into a method restorePendingRequest at 387e96c

demo/src/main/java/com/braintreepayments/api/browserswitch/demo/MainActivity.java

browser-switch/src/main/java/com/braintreepayments/api/BrowserSwitchClient.java

saperi22 · 2025-10-29T21:48:21Z

browser-switch/src/main/java/com/braintreepayments/api/BrowserSwitchClient.java

+     * @throws BrowserSwitchException if the pending request cannot be parsed
+     */
+    public void restorePendingRequest(@NonNull String pendingRequest) throws BrowserSwitchException {
+        this.pendingAuthTabRequest = BrowserSwitchRequest.fromBase64EncodedJSON(pendingRequest);


did we want to validate that the pendingRequest sent is non-null?
@nonnull annotation on java is just for compiler, it doesn't give any guarantees, AFAIK.

hey, that's a great suggestion, I added it to befcdd1

saralvasquez

This looks great! 🎉 I had a few non-blocking comments and a question but this looks ready to go to me!

saralvasquez · 2025-10-30T19:07:42Z

CHANGELOG.md

+    * Upgrade `compileSdkVersion` and `targetSdkVersion` to API 36
+    * Replace `ChromeCustomTabsInternalClient.java` with `AuthTabInternalClient.kt`
+    * Add parameterized constructor `BrowserSwitchClient(ActivityResultCaller)` to initialize AuthTab support
+    * Maintain default constructor `BrowserSwitchClient()` (without AuthTab support) for backward compatibility


Tiny tiny nit: not sure if the (without AuthTab support) is necessary and it make the entry a bit long

saralvasquez · 2025-10-30T19:10:34Z

browser-switch/src/main/java/com/braintreepayments/api/AuthTabInternalClient.kt

+            LaunchType.ACTIVITY_CLEAR_TOP -> {
+                customTabsIntent.intent.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP)
+            }
+            null -> { }


I think I'm missing some kotlin knowledge. Why is the null case necessary?

See this. It is likely that the compiler complained about a non-exhaustive when statement.

yes, this was exactly the case, i had to add it for a compiler. I suppose there must be a more elegant way to deal with it though...

Ah makes so much sense! Thanks for the resource Sai!

saralvasquez · 2025-10-30T19:24:53Z

browser-switch/src/main/java/com/braintreepayments/api/BrowserSwitchClient.java

+
+        } catch (ActivityNotFoundException e) {
+            this.pendingAuthTabRequest = null;
+            return new BrowserSwitchStartResult.Failure(


Nit: Nested function calls and object instantiation is a bit hard to read. Especially when it's also a return. It might be easier to read if the exception creation was broken out onto a separate line. The same goes for line 214

this was another pattern that I took from legacy code, but i agree that readability can be improved!

saralvasquez · 2025-10-30T19:27:50Z

demo/src/main/java/com/braintreepayments/api/browserswitch/demo/MainActivity.java

 import android.os.Bundle;
 import android.view.View;
 import android.widget.Button;
-


Nit: Cleanup is nice, but no-ops can make commit history for a file a bit cluttered. I would recommend leaving this file alone

saralvasquez · 2025-10-30T19:31:42Z

browser-switch/src/test/java/com/braintreepayments/api/AuthTabInternalClientUnitTest.kt

+
+    @Before
+    fun setUp() {
+        clearAllMocks()


This definitely feels like best practice! Love it. Out of curiosity, did you notice that this call was necessary to the tests passing?

This was a part of the ChromeCustomTabClientUnitTest that was removed because the new AuthTabClient was introduced. Since it was used in the old test, I decided to add it to this one as well. However, the tests DO pass without that line, because we are not reusing the mocked objects, I opted in to keeping it because it is was in the old test.

Ah makes sense! Thanks for the info!

saralvasquez · 2025-10-30T19:33:55Z

browser-switch/src/test/java/com/braintreepayments/api/AuthTabInternalClientUnitTest.kt

+        every { CustomTabsClient.getPackageName(context, null) } returns packageName
+        every { CustomTabsClient.isAuthTabSupported(context, packageName) } returns false
+
+        val client = AuthTabInternalClient(authTabBuilder, customTabsBuilder)


Nit: I think in most of the unit test classes we use sut for the variable name if it's the object we testing

saralvasquez · 2025-10-30T19:39:50Z

demo/src/main/java/com/braintreepayments/api/browserswitch/demo/DemoActivitySingleTop.java

-        browserSwitchClient = new BrowserSwitchClient();
+
+        browserSwitchClient = new BrowserSwitchClient(this);
+        // Check if there is a preserved pending request after the process kill


Nit: The code here seems pretty self explanatory so I'm not sure if the comments here add much

saperi22 and others added 4 commits October 7, 2025 10:31

Auth tab initial setup (#119)

ee1cce3

* remove duplicate intent-filter * - Update androidx.browser to 1.9.0 - Update AGP version to 8.9.1 -- requires update to gradle wrapper 8.11.1 - Update compile and target sdk to 36

Update CHANGELOG.md and an argument for a parametrized constructor (#123

4673301

) * updated default constructor to accept `ActivityResultCaller` as a parameter updated `CHANGELOG.md` * addressed PR suggestions * addressed PR suggestions: switch the version to `unreleased`

noguier requested a review from a team as a code owner October 20, 2025 21:47

noguier added 2 commits October 21, 2025 10:07

Merge branch 'main' into auth-tab-feature

2a792f7

# Conflicts: # CHANGELOG.md # browser-switch/src/main/java/com/braintreepayments/api/BrowserSwitchClient.java # build.gradle

address merge conflicts

5a137c7

sshropshire reviewed Oct 21, 2025

View reviewed changes

saperi22 reviewed Oct 21, 2025

View reviewed changes

demo/src/main/java/com/braintreepayments/api/browserswitch/demo/MainActivity.java Outdated Show resolved Hide resolved

saperi22 reviewed Oct 21, 2025

View reviewed changes

browser-switch/src/main/java/com/braintreepayments/api/BrowserSwitchClient.java Show resolved Hide resolved

saperi22 reviewed Oct 21, 2025

View reviewed changes

browser-switch/src/main/java/com/braintreepayments/api/BrowserSwitchClient.java Outdated Show resolved Hide resolved

noguier added 3 commits October 21, 2025 15:27

address PR suggestions

7ddb477

address process kill as per Sai's suggestion

742b29c

Add restorePendingRequest() method to handle process kill recovery

387e96c

saperi22 reviewed Oct 29, 2025

View reviewed changes

add a null check to restorePendingRequest

befcdd1

saralvasquez approved these changes Oct 30, 2025

View reviewed changes

saperi22 approved these changes Oct 30, 2025

View reviewed changes

add PR suggestions

11248d1

noguier merged commit 6beaa58 into main Oct 30, 2025
4 checks passed

noguier deleted the auth-tab-feature branch October 30, 2025 21:07

AuthTab Support Feature #124

AuthTab Support Feature #124

Uh oh!

Conversation

noguier commented Oct 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary of changes

Checklist

Authors

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

saralvasquez left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

noguier commented Oct 20, 2025 •

edited

Loading