App state kept without client requesting it?

[Alexs784]

Describe the problem

When closing the app while the authentication browser is open, relaunching the app starts from the screen previous to the authentication opening.

What was the expected behavior?

I was expecting to land on the usual initial screen of the app.

Reproduction

Let's say my app by default is launched on Activity A with fragment B. To launch the SDK authentication, the user needs to first go to fragment C and then click on a button that will launch the SDK login through:

WebAuthProvider.login(auth0)
            .withAudience(AUTH0_AUDIENCE)
            .withScope(SCOPE)
            .withScheme(SCHEME)
            .withParameters(requestParameters)
            .start(activity, callback)

If I close the app while the login (custom tabs browser) is open and then I relaunch the app, I land on the fragment C.
I was expecting to land on fragment B which is the standard behaviour of the app.

Reproduction 2

I have the same output with a similar scenario.
Let's say I have activity A and B. Activity B has an extra used to trigger the SDK authentication.
Activity A has a button that, when clicked, sets that extra on Activity B to true, triggering the SDK authentication once launched.
If I launch Activity A, then click on that button -> Activity B is launched and the SDK authentication (custom tabs browser) is immediately launched as expected.
If I close the app at this point (so while the custom tabs are visible) and reopen it again, I would expect to land on Activity B without the SDK authentication being triggered.
Well, the SDK authentication gets triggered (which is not what I expect)

Environment

• Version of this library used: 1.29.2, 1.30.0
• Any other relevant information you think would be useful: tested on physical device with. Android 11 and on emulator wit Android 10

[lbalmaceda]

What you are describing is normal behavior.

In the 1st scenario, your activity A changes to fragment C. There the user clicks a button and the authentication is started. Internally, the library will start another activity and when the authentication is received, that internally launched activity will be finished, so it goes back to whatever context started the web auth. In this case, Activity A with fragment C. This could vary if the OS decided it needed more RAM and killed your app, forcing Activity A to be recreated.

In the 2nd scenario, your activity A has a button that opens B and from there you start the authentication. The same workflow is applied. An activity is started internally by this library to launch the browser. And when the result comes back, it will be finished, taking the user back to whatever context started the web auth. In this case, Activity B.

All these activities that you have in your app are not part of this library, and so, are not in control of this library. The library doesn't launch any of your app's activities, it just finishes the ones the library had internally started. I hope that makes sense.

[Alexs784]

@lbalmaceda thanks for your response 🙏

Uhmm, I am not sure I am following you 🤔

For example:

Internally, the library will start another activity and when the authentication is received, that internally launched activity will be finished, so it goes back to whatever context started the web auth.

That's totally fine and makes sense, but what I am saying here is different, let's try to use a different example to see if I can explain myself better:

Let's say I have an app that launches a DefaultActivity, which by default shows the fragment HomeFragment.
Now, from the HomeFragment I can go to the AccountFragment, and there I have a button that will trigger the auth0 authentication (thus the SDK activity with the webview).

All good till here.

Now let's consider 2 scenarioa:

1. I launch the app, go to the AccountFragment, don't click on anything and close the app (=kill it). If I launch it again, I will land on the HomeFragment (as expected). ✅
2. I launch the app, go to the AccountFragment and click on the button that launches the auth0 SDK authentication. While in th ewebview activity I close the app (again, =kill). If I launch the app again I land on the AccountFragment ❌ (instead of the HomeFragment as I was expecting).

As you can see. the issue happens only if I close the app while on the webview activity from the SDK, which made me think something is done there, maybe some flags for the intent that keep the state of the app in some way? 🤔

Update: this seems to happen on Android 10 and 9, does not happen on Android 11 (from my tests)

[Alexs784]

There is something definitely off here, further investigating I noticed another scenario with a weird behaviour. Suppose we have a simple app with one default activity and one fragment in it.

1. Open your app
2. Click on the button on the fragment that triggers the auth0 SDK (authentication flow)
3. Open the multi-tasking system view as if we wanted to switch app
4. You can switch to another app or not, doesn't seem to matter
5. Resume your app
6. You are (correctly) back into the auth0 webview activity
7. Close the activity through the 'X' button
8. The whole app is closed

The app doesn't seem to crash, is just closed together with the auth0 activity. (writing this under this issue since they might be related(?))

This one happens for sure in Android 10 and 11 as well.

[Alexs784]

Ok, found something interesting: I had the launch mode on my activity as SingleInstance. Changing it to the default one (standard) fixes the issue.

[lbalmaceda]

That makes sense. Changing the launchMode of an activity leads to totally different behavior. We use that in one activity to ensure only one instance is kept at the same time, but you generally don't want to touch that unless you are developing an Android Launcher/Home application, for example. Here is a nice (but old) post about it if you are curious https://inthecheesefactory.com/blog/understand-android-activity-launchmode/en.

As mentioned earlier, what we do in this library doesn't have any impact on any activity/fragment that you have in your application, as we don't have access to them.

[lbalmaceda]

I'm going to close this. If you run into a different issue, please open a new one. Thanks