An abandoned consent screen causes the next authorization request to be rejected with `access_denied` (LINE SDK 5.10.1)

Nobody has claimed this yet.

## Summary

When integrating LINE Login with the LINE Android SDK, a login attempt that the user leaves without answering the consent screen puts the LINE application into a state where the **next** authorization request is rejected.

This does not require the user to close or kill anything. Simply pressing **Home**, switching to another application, or opening Recents and moving to a different task while the consent screen is displayed is enough. The LINE application keeps running, and the consent screen itself is never dismissed.

The next request never shows any UI. It returns `access_denied` almost immediately, and the SDK reports `LineApiResponseCode.CANCEL`. Only the request after that succeeds.

From the user's point of view the login button does nothing the first time it is pressed. From the integrating application's point of view the event is indistinguishable from the user declining consent.

---

## Environment

- LINE Android SDK: **5.10.1**
- LINE application: **26.13.0**
- Login method: App-to-App LINE Login (`botPrompt=aggressive`, scopes `profile email openid`)
- Result handling: `ActivityResultContracts.StartActivityForResult`
- Device:
- **Samsung SM-S931N**
- Android 16 (API 36)
- Reproducibility:
- Always reproducible once the consent screen has been abandoned

---

## Steps to Reproduce

1. Launch LINE Login from the host application. The LINE application opens the consent screen.
2. Without tapping **Allow** or **Cancel**, leave LINE with the **Home button** and return to the host application. The SDK cancels the attempt after about one second, as expected (`LineAuthenticationController.CANCEL_DELAY_MILLIS`).
LINE is only backgrounded here — it is not closed, not swiped away from Recents, and its process stays alive. Switching to another application instead of pressing Home produces the same result.
3. Start LINE Login again.
4. Start LINE Login once more.

---

## Expected Behavior

In step 3, the new authorization request should supersede the abandoned one and the consent screen should be displayed.

---

## Actual Behavior

In step 3:

- The LINE application does not become visible at all.
- `access_denied` is returned after roughly 370 ms.
- The SDK reports `LineApiResponseCode.CANCEL`.
- The callback carries the same parameters as a genuine consent denial.

In step 4 the login proceeds normally. Exactly one request is consumed each time the consent screen is abandoned.

---

## Investigation

All components named below belong to the LINE application package (`jp.naver.line.android`) and were read from its APK manifest and from `dumpsys` on a device. None of them are part of the SDK or of the integrating application.

### The abandoned consent screen is paused, not destroyed

`dumpsys activity activities`, immediately after step 2:

```
Task{#5892 A=jp.naver.line.android visible=false visibleRequested=false sz=2}
mLastPausedActivity: ChannelPermissionApprovalActivity t5892
* Hist #0: ChannelPermissionApprovalActivity
resultTo=OAuthWebLoginServiceActivity resultWho=null resultCode=100
windows=[Window{...ChannelPermissionApprovalActivity}]
```

The activity is still alive and still owes a result to its parent.

### The user cannot return to it

The OAuth task is excluded from Recents. From the LINE application manifest:

| Activity | `launchMode` | `excludeFromRecents` |
| --- | --- | --- |
| `jp.naver.line.android.urlscheme.service.oauth.OAuthWebLoginServiceActivity` | `2` (singleTask) | `true` |
| `jp.naver.line.android.activity.channel.permission.ChannelPermissionApprovalActivity` | (none → standard) | (none) |

Confirmed at runtime:

```
Recent tasks visible drop reason:
* Task{... A=jp.naver.line.android}
Drop Reason: ACTIVITY_EXCLUDE_FLAG

mCallingPackage=jp.naver.line.android
intent={flg=0x10800000 cmp=.../OAuthWebLoginServiceActivity}
0x10000000 FLAG_ACTIVITY_NEW_TASK
0x00800000 FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS
```

Because `excludeFromRecents` is set while `noHistory` is not, the consent screen remains alive but unreachable. It is not listed in Recents, and the launcher icon opens LINE's main task instead. The user has no way to complete or dismiss the pending consent.

### The next request is answered by the previous attempt's activity

`logcat ActivityTaskManager` during step 3:

```
17:29:58.851 START .../LineAuthenticationActivity
from uid 10566 (host application)

17:29:59.222 START .../LineAuthenticationCallbackActivity
dat=lineauth://result/...
from uid 10595 (jp.naver.line.android) sr=18359843
```

`sr=18359843` identifies the activity that sent the callback:

```
ActivityRecord{18359843 jp.naver.line.android/.urlscheme.service.oauth.OAuthWebLoginServiceActivity t5892}
```

This belongs to `t5892` — the task created in step 1. No new LINE task was created for the step 3 request, and `Task{#5892}` disappears entirely right afterwards.

State across the three points:

| | Consent screen visible | After Home button | After the step 3 request |
| --- | --- | --- | --- |
| `Task{#5892}` | `visible=true` | `visible=false` | gone |
| `ChannelPermissionApprovalActivity` | `topResumedActivity` | `mLastPausedActivity` | gone |
| `resultCode` | `100` | `100` | — |

### A possible explanation

`OAuthWebLoginServiceActivity` is declared `singleTask`. When a new authorization intent is routed to it, the platform destroys every activity stacked above the existing instance before delivering `onNewIntent()`.

The activity destroyed that way is `ChannelPermissionApprovalActivity`, which was started with `startActivityForResult` and had a result pending. Its destruction delivers `RESULT_CANCELED` to `OAuthWebLoginServiceActivity`.

The instance therefore receives the new authorization request and a cancellation of the previous consent at effectively the same moment, and the cancellation appears to take precedence.

Two observations are consistent with this:

- The error is specifically `access_denied`, the code for a declined consent, rather than a generic failure.
- The SDK validates `state` before parsing `error` in `BrowserAuthenticationApi#getAuthenticationResultFrom`, and the result is a clean `CANCEL` rather than `Illegal parameter value of 'state'`. The new request's `state` was therefore adopted, which suggests the new intent was read before the flow was discarded.

We can only observe this from outside the LINE application, so this part is an inference rather than a confirmed cause.

---

## Impact

Integrating applications cannot distinguish this from a real consent denial. The callback parameters are identical, and the SDK maps both to `LineApiResponseCode.CANCEL`. Any application that measures its login funnel will count these as user denials.

There is also no way for an integrator to detect or clear the pending state, since the task belongs to the LINE application and is excluded from Recents.

---

## Questions

1. Is this behaviour expected when a previous authorization has been left unanswered?
2. Should a new authorization request supersede a pending one, rather than being rejected by it?
3. Is there a supported way for an integrating application to detect or reset this state?
4. Is there a recommended implementation pattern for applications where users frequently switch away during consent?

---

## Additional Notes

The 4.0.2 release notes list a known issue with the same user-visible symptom — `onActivityResult` returning `CANCEL` on the first login attempt with app-to-app login, succeeding on the second — which was fixed in 4.0.4 and scoped to Android 4.x. The cause described here appears to be different, but the symptom users experience is the same.

Possibly related open issues: #138, #140, #171, #192.

Thank you.

Reproduce the abandoned-consent sequence on the stated Android environment, then read BrowserAuthenticationApi#getAuthenticationResultFrom and the LineAuthenticationController cancellation timing mentioned in the report. The issue names no repository file or test; done would require confirming the cause and documenting or implementing a supported way for a new request to supersede or reset the abandoned authorization.

Written by the indexing model from the issue text.