Android 14 Beta - AuthorizationManagementActivity fails to handle AuthIntent due to being recreated

[Diogo00dev]

Checklist:

• I am using the latest release
• I searched for existing GitHub issues
• I read the documentation
• I verified the client configuration matches the information in the identity provider (or I am using dynamic client registration)
• I am either using a custom URI scheme or https with App Links for client redirect.

Configuration

• Version: 0.11.1
• Integration: (native(Kotlin))
• Identity provider: (Google, Okta)

Issue Description

Hi There.

We have been using AppAuth for years now and only now we just had a problem on Android 14.

On API 34 the login flow is broken, after the startActivity() from AuthorizationManagementActivity is called and we finish the login flow instead of the same instance of AuthorizationManagementActivity being updated to handle handleAuthorizationComplete on the onResume, a completely new instance is being created, and therefore fails to function properly.

We where able to get passed this issue by changing the launchMode of AuthorizationManagementActivity from singleTask to singleInstance

Here is a screenshot with some logs confirming that indeed a new instance of AuthorizationManagementActivity is created.

And here is the same logs after changing the launchMode to singleInstance

<activity android:name=".AuthorizationManagementActivity"
      android:exported="false"
      android:configChanges="screenSize|smallestScreenSize|screenLayout|orientation|keyboard|keyboardHidden"
      android:theme="@style/Theme.AppCompat.Translucent.NoTitleBar"
      android:launchMode="singleInstance" />

If there is any configuration that we might have missed to fix this we would appreciate if you could point us in the right direction, in case this is not actually an issue on your end.

Thank you

[agologan]

Seems to be similar to #973 but unfortunately can't seem to reproduce the conditions you're describing.

[Diogo00dev]

@agologan after further investigation the root of the issue comes from a google issue, and to replicate it with AppAuth the activity that calls AppAuth needs to be a singleInstance

[marinantonio]

@Diogo00dev I had a similar issue, but only when I would add acr_values. First login would work, but every following one would fail caused by AppAuth's Cancelled exception. I just updated my phone to the latest Android 14 build and issue seems to be gone.

[agologan]

@Diogo00dev thank you for the reference.
Will keep this topic open for tracking purposes to see how the situation evolves until the final release.

[asbozh]

The issue is reproduced on Android 14 beta 4.1 with AppAuth-Android 0.11.1.
Could you please verify what is the plan to resolve the issue? Are we waiting to see if Google will include the fix from https://issuetracker.google.com/issues/288400064?pli=1 in probably the first stable version of Android 14 which is a little risky as they haven't confirm or commit to particular build... Or in the meantime there will be a new AppAuth-Android version with the described workaround mentioned in this thread? Any suggestion for apps that are using the library?

Thank you.

[anisimov74]

Dear maintainers, could you please fix this issue.

[yao-xie-kinto]

It appears that this issue is no longer reproducible on Android 14 Beta 5.3 (Build: UPB5.230623.009)

[Diogo00dev]

i am still having the same issue now with the QPR1 version, anyone else still having the same problem ?

[DevDema]

I am also having this issue. I think the openid flow needs to be changed because API 34 looks like it's forcing intents to open in a new task (FLAG_ACTIVITY_NEW_TASK)

[troymolnar]

Fyi who ever it helps, we've been in communication with Google about this issue for our own app, and they're now claiming that their fix for the launchType will be released during QPR1 (which is currently in beta). That means that there may be up to 2-3 months of time (guessing based on last years Android 13 release pattern) between the production release of Android 14 & the fix.

We have a simple workaround for it in the meantime, though it comes with it's own set of possibly unique drawbacks.

Overriding openId's launch mode this way in our own manifest at least let's us log in again.

        <activity
            android:name="net.openid.appauth.AuthorizationManagementActivity"
            android:launchMode="3"
            tools:replace="android:launchMode" />

        <activity
            android:name="net.openid.appauth.RedirectUriReceiverActivity"
            android:excludeFromRecents="true"
            android:exported="true"
            tools:node="replace">
            
            ............

[ninehundreds]

Fyi who ever it helps, we've been in communication with Google about this issue for our own app, and they're now claiming that their fix for the launchType will be released during QPR1 (which is currently in beta). That means that there may be up to 2-3 months of time (guessing based on last years Android 13 release pattern) between the production release of Android 14 & the fix.

We have a simple workaround for it in the meantime, though it comes with it's own set of possibly unique drawbacks.

Overriding openId's launch mode this way in our own manifest at least let's us log in again.

        <activity
            android:name="net.openid.appauth.AuthorizationManagementActivity"
            android:launchMode="3"
            tools:replace="android:launchMode" />

        <activity
            android:name="net.openid.appauth.RedirectUriReceiverActivity"
            android:excludeFromRecents="true"
            android:exported="true"
            tools:node="replace">
            
            ............

Thanks for this interim solution! You saved my bacon :)

[DevDema]

I want actually to elaborate a bit on @troymolnar 's answer (and thank you for the idea by the way).

The trick is indeed in the launchMode of the openId activity, but to correct it make sure you replace with their whole thing:

        <activity
            android:name="net.openid.appauth.AuthorizationManagementActivity"
            android:configChanges="screenSize|smallestScreenSize|screenLayout|orientation|keyboard|keyboardHidden"
            android:exported="false"
            android:launchMode="singleInstance"
            android:theme="@style/Theme.AppCompat.Translucent.NoTitleBar"
            tools:node="replace"/>
        <activity
            android:name="net.openid.appauth.RedirectUriReceiverActivity"
            android:exported="true"
            tools:node="replace">
            <intent-filter>
                <action android:name="android.intent.action.VIEW" />

                <category android:name="android.intent.category.DEFAULT" />
                <category android:name="android.intent.category.BROWSABLE" />

                <data android:scheme="${appAuthRedirectScheme}" />
            </intent-filter>
        </activity>

Otherwise you lose the intent filter of RedirectUriReceiverActivity 😄

[janveprek]

Still having this issue with Android 14 Stable

[filipkowicz]

@troymolnar thanks for tip!

i think this one should be enough, at least it was in my case

<activity
       android:name="net.openid.appauth.AuthorizationManagementActivity"
       android:launchMode="singleInstance"
       tools:replace="android:launchMode" />

[guy-utila]

These solutions solve the sign in issue for me, however they keep another browser activity with a login screen even after the login ended. Does anybody have an idea what can be done about it or even how can I limit this only to the Android 14 users?

[troymolnar]

These solutions solve the sign in issue for me, however they keep another browser activity with a login screen even after the login ended. Does anybody have an idea what can be done about it or even how can I limit this only to the Android 14 users?

We had that side effect as well, that there was a vestigial app instance remaining on that sign in screen. Though since we couldn't cause any further issues with that stake instance, we considered it acceptable losses for the interim while we wait for the true fix in Android OS.

[filipkowicz]

These solutions solve the sign in issue for me, however they keep another browser activity with a login screen even after the login ended. Does anybody have an idea what can be done about it or even how can I limit this only to the Android 14 users?

We had that side effect as well, that there was a vestigial app instance remaining on that sign in screen. Though since we couldn't cause any further issues with that stake instance, we considered it acceptable losses for the interim while we wait for the true fix in Android OS.

you can do it with setting int value in resources which you can latter use in AndroidManifest - just bare in mind that it's not string then - it's int - you can check values in Android source code

2 - LAUNCH_SINGLE_TASK - default
3 - LAUNCH_SINGLE_INSTANCE - fix for api 34

in AndroidManifest just add this:

        <activity
            android:name="net.openid.appauth.AuthorizationManagementActivity"
            android:launchMode="@integer/launch_mode_for_app_auth"
            tools:replace="android:launchMode" />

and

values/integers.xml

<?xml version="1.0" encoding="utf-8"?>
<resources>
    <!-- LAUNCH_SINGLE_TASK -> default value from library -->
    <integer name="launch_mode_for_app_auth">2</integer>
</resources>

and actual fix:

values-v34/integers.xml

<?xml version="1.0" encoding="utf-8"?>
<resources>
    <!-- LAUNCH_SINGLE_INSTANCE -> overrides library mode because of
     bug in Android 14 (34) which causes infinite loop
     should be fixed soon with version 14.1 -->
    <integer name="launch_mode_for_app_auth">3</integer>
</resources>

[guy-utila]

@filipkowicz Thank you so much! It worked! I actually tried the same idea but tried to use strings for launchMode which did not work, I had no idea you can use numbers.

[filipkowicz]

I think Android 14 QPR1 is released, this should fix issue so we can close it.

BTW does anyone has idea how to check if device is running particular QPR version of android os release ?

[stelma]

Just reporting in from a recent debugging session we had concerning this issue. Even if QPR1 is out on the wild, it is definitely not for all devices, so this issue will pop up again in the future.

[filipkowicz]

I think qpr updates are well spreaded as they are installed automatically and if any provider allows qpr1, will allow qpr2 too. Any only faulty one is qpr1

…

On Fri, 19 Apr 2024 at 14:40, stelma ***@***.***> wrote: Just reporting in from a recent debugging session we had concerning this issue. Even if QPR1 is out on the wild, it is definitely not for all devices, so this issue will pop up again in the future. — Reply to this email directly, view it on GitHub <#977 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABDZMXVSHHMUINWIV5OHAALY6EGFXAVCNFSM6AAAAAAZRWIKYCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRWGQ4DQNRSGE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[benebun]

Note that we ran into this on several up-to-date Samsung devices with Android 14 and also on Pixel 4a latest possible Android 14 patch update. Not sure when/if the Samsungs will receive another update.