-
Notifications
You must be signed in to change notification settings - Fork 874
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Android 14 Beta - AuthorizationManagementActivity fails to handle AuthIntent due to being recreated #977
Comments
Seems to be similar to #973 but unfortunately can't seem to reproduce the conditions you're describing. |
@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 |
@Diogo00dev I had a similar issue, but only when I would add |
@Diogo00dev thank you for the reference. |
The issue is reproduced on Android 14 beta 4.1 with AppAuth-Android 0.11.1. Thank you. |
Dear maintainers, could you please fix this issue. |
It appears that this issue is no longer reproducible on Android 14 Beta 5.3 (Build: UPB5.230623.009) |
i am still having the same issue now with the QPR1 version, anyone else still having the same problem ? |
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) |
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.
|
Thanks for this interim solution! You saved my bacon :) |
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:
Otherwise you lose the intent filter of RedirectUriReceiverActivity 😄 |
Still having this issue with Android 14 Stable |
@troymolnar thanks for tip! i think this one should be enough, at least it was in my case
|
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 in AndroidManifest just add this:
and values/integers.xml
and actual fix: values-v34/integers.xml
|
@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. |
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 ? |
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. |
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:
***@***.***>
|
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. |
Hi guys After some days of debugging I found the root cause of the problem we still have on Samsung Devices Running Android 14. Having the But this will cause the Custom tab activity to remain opens because we broke the flow on how we dismiss the Custom tab activity that will require the The root problem lies in the start Activity for result. Not working example
Instead if we do a simple activity start here. we will NOT have the problem, but of course we wont have the response code. So one of the solutions here is to send an Event from the Another solution we just tried is using the So instead of using the activity for result use this code below and will work perfectly as well.
Pending Intent snipped for Kotlin
|
Checklist:
https
with App Links for client redirect.Configuration
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()
fromAuthorizationManagementActivity
is called and we finish the login flow instead of the same instance ofAuthorizationManagementActivity
being updated to handlehandleAuthorizationComplete
on theonResume
, 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
fromsingleTask
tosingleInstance
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
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
The text was updated successfully, but these errors were encountered: