AndroidRuntimeException thrown when starting WebAuthProvider with Application context (FLAG_ACTIVITY_NEW_TASK flag required)

[alex-wiggle]

Describe the problem

When calling start on WebAuthProvider builders with an application context, the android system throws the exception

Android.Util.AndroidRuntimeException: Calling startActivity() from outside of an Activity context requires the FLAG_ACTIVITY_NEW_TASK flag 

This makes it hard to use the provider to another class where we're injecting the application scope via Koin. It means we end up having to pass contexts around and affects testing.

What was the expected behavior?

Expected to be able to start the universal login/logout flow (i.e. open the browser window) using the Application context

Reproduction

• Create an application
• Do the following:

WebAuthProvider
                .login(auth0)
                .withScheme(scheme)
                .withScope("openid profile email")
                .start(
                    context,
                    object : Callback<Credentials, AuthenticationException> {
                        override fun onFailure(error: AuthenticationException) {
                            continuation.resumeWithException(error)
                        }

                        override fun onSuccess(result: Credentials) {
                            continuation.resume(result)
                        }
                    }
                )

Where context is an instance of Application

Environment

Auth0 Android Lib: 2.2.0
Kotlin 1.5
Android (v21+)

[lbalmaceda]

@alex-wiggle I've tried and can confirm that passing an Application context breaks the flow.

Adding the Intent.FLAG_ACTIVITY_NEW_TASK flag would be incorrect as the authentication is meant to run on the same task as the activity that launches it (i.e. the main or login activity from your app). Moreover, this would defeat the purpose of using Chrome Custom Tabs which would now open as "a separate activity".

Application contexts are not supposed to start activities. I don't believe it's possible to use them for this use case, nor that we can fix this, unfortunately.

Where are you trying to launch the authentication from? Can you expand a bit on your use case? Thanks

[alex-wiggle]

Hi @lbalmaceda ! We're using a single activity/multi fragment layout but wanted to put auth behind a service that doesn't rely on the activity directly as it means passing references around through many layers.

With regards to : Moreover, this would defeat the purpose of using Chrome Custom Tabs which would now open as "a separate activity" - is this a feature that's coming soon? With the testing I've been running so far it always launches a fresh browser instance.

Cheers!

[lbalmaceda]

But as proved by this issue, to use our WebAuthProvider class you need to pass an Activity context. This provider delegates the authentication to the browser. We follow the Authorization + PKCE flow. I guess as an alternative you could manage this on your own, forking the repository and adding that flag to the intent here. Note however that you'd need to maintain that fork when we push changes.

With the testing I've been running so far it always launches a fresh browser instance.

The CCT dependency tries to find a compatible browser. This is, a browser that implements the Custom Tabs service. If one is found, that one is used and the URL will load in what looks like a new fragment styled with a Toolbar from within your app. Chrome & Firefox are examples of browsers that have this behavior. You might want to try installing them to see how this looks like.

If no compatible CCT browser is found, then the intent is handled by any other browser app available, which will open in their own task as a separate activity. Pressing the "recents" button would help you understand these differences.

[alex-wiggle]

In that case -good to close the issue then and I'll work with as is

Thanks for the help @lbalmaceda

[lbalmaceda]

We will probably change back the method signature to accept an Activity instead of a generic Context, as the latter is not supported.