[wmathurin]

Summary

Native Login becomes an SDK debug feature: any debug-build app (RestExplorer, AuthFlowTester, templates) can log in natively from the developer support Login Options screen, without app code. AuthFlowTester only consumes it and adds the Native Login UI tests (W-24600769).

SDK changes (debug only, needs human review)

• Authentication Mode in Login Options. LoginOptionsActivity shows Authentication Mode: Browser / Native at the top (when developer support is enabled, which is the default in debug builds, and only when the app has no nativeLoginActivity). Native mode shows Client ID, Native Callback URL, Community Login URL, JSON import, Use DPoP and Use Hybrid Authentication. Browser-only rows are hidden in Native mode.
• Separate persistence. NativeLoginDebugSettings (own SharedPreferences) stores the mode and the native config apart from the browser config, so Browser mode and browser fallback keep the boot/override config and callback URL. Native DPoP/hybrid choices apply to Native Login only.
• Debug settings API. SalesforceSDKManager.debugLoginSettings with mode, config, apply(json) and reset(). JSON keys match iOS: consumerKey, redirectUri, communityUrl, useDPoP, useHybridFlow, authenticationMode (browser|native). Invalid JSON or an incomplete native config is rejected and nothing is saved.
• Built-in Compose native login. DebugNativeLoginActivity (not exported) is wired to the existing Native Login API: loading state, cancel (no account is created, and a cancelled or replaced attempt that completes late cannot update the form), result and OAuth error detail, a redacted diagnostics trace, Login Options link and browser fallback.
• SDK-owned routing. loginActivityClass is resolved per login attempt: the app's nativeLoginActivity (from initNative) always wins; otherwise DebugNativeLoginActivity in Native mode; otherwise the web login activity. Closing Login Options after a mode/config change restarts authentication (loginDevMenuReload).
• Diagnostics. NativeLoginDiagnostics (internal, recorded when developer support is enabled) records each authorize/token exchange: stage, HTTP status, OAuth error/error_description, and whether DPoP/nonce headers were present. No tokens, codes, proofs, nonces or passwords are recorded.
• NativeLoginManager takes optional useDPoP / useHybridAuthentication overrides (internal), used by the debug config.
• L marker (all builds). A successful Native Login now registers exactly one per-user login-server marker, as iOS does, from the Native Login URL (AuthenticationUtilities.onAuthFlowComplete, using LoginActivity.selectLMarker): a community URL gives L5, a My Domain URL L4. Before, Native Login sessions had no L marker.
• Apps that don't enable developer support (off by default in release builds): no behavior change. The new public surface (debugLoginSettings, AuthenticationMode, NativeLoginDebugConfig, DebugNativeLoginActivity) is debug tooling.

AuthFlowTester

• initNative without a native login activity. Launch extras EXTRA_AUTHENTICATION_MODE / EXTRA_NATIVE_LOGIN_CONFIG map onto debugLoginSettings; a value the settings reject is logged and ignored, as on iOS.
• NativeLoginTests drive the SDK Login Options and debug form: the eca_jwt_headless / eca_jwt_dpop_headless x DPoP on/off matrix, cancel during login (idle, and with a successful (HTTP 200) token response held until after Cancel; a failed token request fails the test: tokens, token type and user agent markers stay unchanged), browser fallback, same-user DPoP->Bearer re-auth, Activity recreation, multi-user isolation and config validation. Successful sessions are checked for NL, A5, L5 (and DP for DPoP).
• Relaunch tests: testECAJwtHeadless_DPoPOff_Relaunch_Bearer and testECAJwtDPoPHeadless_DPoPOn_Relaunch_DPoP relaunch the app and check that the session is restored without the form, with unchanged tokens and markers, a working REST call, and revoke+refresh (DPoP binding kept). This is an Activity relaunch in the same process, not a cold restart: the instrumentation runs in the app's process, so restartApp() cannot kill it. The same applies to every Android restart test; the README and the restartApp() KDoc say so. eca_jwt_dpop_headless with client DPoP off must report InvalidCredentials with authorize HTTP 400 invalid_request (missing dpop_jkt) and no account created.
• Native Login fixtures come from the existing apps (eca_jwt_headless, eca_jwt_dpop_headless) and loginHosts (community_auth) of ui_test_config.json. The tests skip only when neither app is configured. They fail with a clear message when only one is, when community_auth or its user is missing, or when an app has an empty consumerKey or a non-https:// redirectUri.

Screenshots

Login Options, Native mode	Built-in native login	eca_jwt_dpop_headless without DPoP	Login Options, Browser mode

Tests

Run on an API 36.1 emulator.

• Full AuthFlowTester UI suite: passes locally on an Android emulator against the test1 org (new NativeLoginTests plus the existing browser, Community, DPoP, RTR and restart suites).

• SDK androidTests: AuthenticationUtilitiesTest and BrowserLoginTelemetryTest pass (81/81), including three new L-marker tests (Native Login on a community registers only L5, on My Domain L4, and a web login leaves the L markers to LoginActivity). DebugNativeLoginViewModelTest passes (3/3: config change with delayed cancellation cleanup, late completion after cancel, retry after cancel); all three fail without the ViewModel fix. NativeLoginDebugSettingsTest, LoginOptionsAuthenticationModeTest and LoginOptionsActivityTest pass (39/39). These classes also pass: SalesforceSDKManagerTest (8), LoginViewModelTest (93), BiometricAuthenticationManagerTest (21) and LoginActivityScenarioTest (22). Some mockk-based classes (SalesforceSDKManagerTests, LoginViewModelMockTest, NativeLoginManagerTest, LoginActivityCancellationTest, LoginActivityTest) crash with SIGABRT when the mockk JVMTI agent loads on this emulator image. That is an environment problem, so they need a run on CI or another image.

• AuthFlowTester NativeLoginTests: 11/11 pass, plus UITestConfigNativeLoginTest (1/1) and NativeLoginConfigRulesTest (7/7). In testECAJwtDPoPHeadless_DPoPOff_RejectedNoAccount, the SDK returns InvalidCredentials and the diagnostic reads stage=authorize status=400 error=invalid_request dpop=false ... description="missing required dpop_jkt for code binding". No account is created.

• Regression: DPoPLoginTests 18/18 and NegativeLoginTests 3/3. testLogin_DPoP_ECA_Without_DPoP_Fails checks the missing required dpop_jkt for code binding error in the toast the SDK shows before it reloads the login page. CommunityLoginTests 16/16 in the run before the L5 change. In the combined run (NativeLoginTests, DPoPLoginTests, NegativeLoginTests), 30 of 32 tests ran and passed. The instrumentation process for the other two was killed (remove task) before any test code ran. Both passed when rerun.

• Manual check in RestExplorer (debug): Developer Support > Login Options shows Authentication Mode. Native mode shows the client ID, callback, community, DPoP and hybrid fields and JSON import. Pressing Back restarts authentication in DebugNativeLoginActivity.

• Screenshots: the AuthFlowTester README screenshots contain no credentials. The Login Options screenshot uses placeholder values, and identifying values are redacted.

For reviewers

• The L marker now registered by Native Login in all builds (telemetry only).
• The new public debug API: debugLoginSettings, AuthenticationMode, NativeLoginDebugConfig and DebugNativeLoginActivity.
• The debug Login Options and Native Login strings are hardcoded, like the existing LoginOptionsActivity strings. They are not in sf__strings.xml.

[github-actions]

	1 Warning
⚠️	Big PR, try to keep changes smaller if you can.

Generated by 🚫 Danger

[github-actions]

	9 Warnings
⚠️	libs/SalesforceSDK/src/com/salesforce/androidsdk/auth/NativeLoginManager.kt#L333 - This method should only be accessed from tests or within private scope
⚠️	libs/SalesforceSDK/src/com/salesforce/androidsdk/ui/LoginActivity.kt#L1374 - Consider adding a <queries> declaration to your manifest when calling this method; see https://g.co/dev/packagevisibility for details
⚠️	libs/SalesforceSDK/src/com/salesforce/androidsdk/ui/LoginOptionsActivity.kt#L623 - Consider adding a <queries> declaration to your manifest when calling this method; see https://g.co/dev/packagevisibility for details
⚠️	libs/SalesforceSDK/src/com/salesforce/androidsdk/ui/LoginOptionsActivity.kt#L626 - Consider adding a <queries> declaration to your manifest when calling this method; see https://g.co/dev/packagevisibility for details
⚠️	libs/SalesforceSDK/src/com/salesforce/androidsdk/ui/LoginOptionsActivity.kt#L630 - Consider adding a <queries> declaration to your manifest when calling this method; see https://g.co/dev/packagevisibility for details
⚠️	libs/SalesforceSDK/src/com/salesforce/androidsdk/ui/LoginOptionsActivity.kt#L633 - Consider adding a <queries> declaration to your manifest when calling this method; see https://g.co/dev/packagevisibility for details
⚠️	libs/SalesforceSDK/src/com/salesforce/androidsdk/ui/LoginViewModel.kt#L360 - This method should only be accessed from tests or within private scope
⚠️	libs/SalesforceSDK/src/com/salesforce/androidsdk/ui/LoginViewModel.kt#L364 - This method should only be accessed from tests or within private scope
⚠️	libs/SalesforceSDK/src/com/salesforce/androidsdk/ui/LoginViewModel.kt#L368 - This method should only be accessed from tests or within private scope

Generated by 🚫 Danger

[github-actions]

⚠️	This method should only be accessed from tests or within private scope

[JohnsonEricAtSalesforce]

Verdict: Request changes.

Reviewed head: 083fe6f508bd5ec71a3c57cd3ad82f6ea33ebb1e.

Requested Changes

1. [P2] Do not publish an authentication error from a cancelled job (DebugNativeLoginActivity.kt:141). Reproduce:

   1. Start Native Login for client A and hold its response. Make cancellation cleanup wait on a gate, matching the SDK noncancellable cleanup path.
   2. Change the native configuration to client B and close Login Options. The old job is cancelled and the form initially becomes Idle.
   3. Release client A's cancellation-cleanup gate.

   Expected: The cancelled attempt publishes no result; client B's form stays Idle and usable.

   Actual: runCatching catches CancellationException, substitutes UnknownError, and writes Failed(UnknownError) from the cancelled job after cleanup. The local probe reproduced Idle changing to Failed without a new login attempt.

   Rethrow cancellation and prevent obsolete attempts from publishing UI state. Add a ViewModel regression test with delayed cancellation cleanup. The previous stale-account-completion defect is addressed; this is a narrower error-state defect in the replacement implementation.

2. [P2] Skip only an absent native fixture (NativeLoginTests.kt:97). hasNativeLoginConfig catches nativeLoginSetup failures and converts them to false. A present nativeLogin block with an unknown app/host or no users therefore skips every test in the documented NativeLoginTests-only invocation. The separate validation class is not selected by that command. Check absence for the assumption, then let malformed or dangling configuration fail with its diagnostic.

3. [P2] Assert that in-flight cancellation preserves the session (NativeLoginTests.kt:199). This branch submits the same user as the existing account, then checks only that one account remains. If cancellation fails and reauthentication replaces that account, the count is still one and the test passes. The access-token comparison above covers only idle cancellation. Hold the response until cancellation, then verify the original credentials and feature markers remain unchanged and no late completion occurs.

4. [P3] Correct the password recreation expectation (README.md:125). The README says the password does not survive Activity recreation, but DebugNativeLoginViewModel retains it in memory across recreation; the shipped test never enters or checks a password. The local SDK-form smoke test also confirmed that it remains after recreation. Document clearing across process death, or implement and test clearing across Activity recreation if that is the intended behavior.

Open Questions

1. Will the headless native fixtures be provisioned for CI so the four-case matrix actually runs? The previous run skipped all nine native tests and the validator; the latest SDK/UI jobs are still running, so updated matrix results are not yet available.

2. Is the iOS twin implementation available on another branch or PR? Its tracking record is identified, but implementation searches still did not locate code to compare, so behavioral parity remains unverified.

Validation: SDK and AuthFlowTester test APKs build at the updated head. Focused SDK suites pass 39/39 (settings 12, Authentication Mode UI 4, existing Login Options 23); the SDK code in those runs is identical to this final head. A credential-free SDK-form/recreation smoke test also passes at this head. A separate production-ViewModel probe reproduces the cancellation-state defect above. All 19 current Kotlin files received IDE analysis, with the final changed test file reinspected after the last commit; no IDE errors were reported. The live native-login matrix was not independently rerun because available local fixtures lack the headless ECAs. Latest CI is still in progress; prior-head results are not validation of this redesign.

This response was generated by an AI agent on behalf of @JohnsonEricAtSalesforce.

[JohnsonEricAtSalesforce]

Follow-up at 994038229 to clarify what remains from my review:

Resolved: original item 2 (fixture skipping) is fixed; the five configuration-rule tests pass locally. The iOS implementation is identified in iOS PR 4192, and both platforms now use the same named-fixture convention.

Still requested:

• Original item 1 — [P2] Cancellation state (DebugNativeLoginActivity.kt:141): prevent cancelled/obsolete attempts from publishing a failure. The current-head delayed-cleanup probe still changes Idle to Failed(UnknownError) after configuration changes.
• Original item 3 — [P2] Session preservation (NativeLoginTests.kt:209): hold completion until cancellation, then verify unchanged credentials/feature markers and no late completion. Checking account count alone still allows session replacement to pass.
• Original item 4 — [P3] Password recreation documentation (README.md:140): the password remains in the ViewModel across Activity recreation. Correct the documented expectation, or implement and test clearing.
• New — [P2] Native cold-restart coverage (NativeLoginTests.kt:130): the acceptance criteria require restored native sessions after a cold restart, but the native success cases only test login and in-process refresh. Add Bearer and DPoP cases that end the app process, relaunch without clearing data or logging in again, and verify restored identity, token type, native/DP markers, REST access and refresh/binding. Verify a fresh process was used; the existing restartApp() helper excludes the instrumentation PID. This is a missing acceptance check; no persistence failure has been demonstrated.

Validation remains open for current-head CI: confirm all four native matrix cases execute rather than skip, and resolve or explain the earlier Browser-mode UI-test failure. That four-test UI class passes locally. The review remains Changes requested.

This response was generated by an AI agent on behalf of @JohnsonEricAtSalesforce.

[wmathurin]

Thanks @JohnsonEricAtSalesforce — all four items are addressed in d70aa3708 (and a16a80ab2).

1. Cancelled job publishing an error: DebugNativeLoginViewModel now rethrows CancellationException, and a per-attempt counter means only the latest attempt can publish state. New DebugNativeLoginViewModelTest (3 cases: config change to client B during delayed NonCancellable cleanup stays Idle; late success after cancel is not published; retry after cancel publishes only the retry). All 3 fail against the old runCatching code.
2. Fixture skip: only the absence of both headless apps skips. One app missing, community_auth or its user missing, an empty consumerKey or a non-https redirectUri all fail with a diagnostic (NativeLoginConfigRulesTest, 7 cases).
3. In-flight cancellation: testNativeLogin_CancelDuringLogin_NoNewAccount holds the token response until after Cancel, delivers it, and asserts one token request, one account, and unchanged access/refresh tokens, token type and user-agent markers.
4. README: the username survives recreation; the password is kept in memory only (retained across recreation, cleared on process death).

Open questions: (1) CI provisioning of the headless fixtures is still to be arranged with the UI_TEST_CONFIG owner; until then those tests skip in CI. (2) The iOS twin is forcedotcom/SalesforceMobileSDK-iOS#4192.

Local results (API 36.1 emulator): NativeLoginTests 9/9, DebugNativeLoginViewModelTest 3/3, NativeLoginConfigRulesTest 7/7, Community+DPoP regression 33/34 (the one failure, testLogin_DPoP_ECA_Without_DPoP_Fails, was already failing). The mockk-based SDK test classes can't run on this emulator image and need CI.

[JohnsonEricAtSalesforce]

Thanks, Wolf. I independently verified the new ViewModel tests (3/3) and fixture-rule tests (7/7) at 5060c85. The ViewModel and Authentication Mode UI classes also pass together (7/7). The cancellation-state fix, fixture validation and README correction are addressed.

Two requests remain:

1. [P2] Require a successful held token response (NativeLoginTests.kt:382). I exercised the actual holding helper with controlled responses. An IOException before any response still signals both held and delivered; HTTP 400 also satisfies the held-response wait. The HTTP 200 control correctly waits for release. Please make transport/HTTP failures fail the cancellation test and assert that a successful response was held before Cancel. Otherwise the existing session can remain unchanged simply because reauthentication failed, without proving cancellation prevented replacement.

2. [P2] Add native cold-restart coverage (NativeLoginTests.kt:137). This request from the follow-up remains outstanding. Verify successful Bearer and DPoP sessions after a genuine process restart, without resetting data or logging in again, including restored identity, token type, native/DP markers, REST access and refresh/binding. Confirm a fresh process was used; the existing restart helper excludes the instrumentation PID.

This response was generated by an AI agent on behalf of @JohnsonEricAtSalesforce.

[wmathurin]

Thanks @JohnsonEricAtSalesforce. Both remaining items are addressed, along with the doc fixes:

1. Held token response must be successful (c1ab32a33). TokenResponseHoldingHttpAccess now records the held response's status and any transport failure. Before it taps Cancel, the test fails on an IOException and asserts that the held response was HTTP 200, so the session can't stay unchanged just because re-authentication failed. 2/2 runs pass.

2. Native restart coverage (36446b9b1). Added testECAJwtHeadless_DPoPOff_Relaunch_Bearer and testECAJwtDPoPHeadless_DPoPOn_Relaunch_DPoP. After the relaunch, each test checks that:

   • the session comes back without the native form;
   • the access and refresh tokens are unchanged;
   • identity, token type, NL/A5/L5 (and DP) and REST access are correct;
   • revoke+refresh works, and keeps the DPoP binding in the DPoP test.

   These tests do not prove a fresh process, and we now say so. The instrumentation runs in the app's process (the probe showed myPid = pidof app), so restartApp() excludes its own PID, kills nothing, and only relaunches the Activity with a cleared task. These tests, like every existing Android restart test, are an Activity relaunch in the same process, not a cold restart. The restartApp() KDoc, the test KDoc and the AuthFlowTester README now say this. Real cold-restart coverage would need the app and the test runner in separate processes.

3. Also done:

   • Native Login now registers exactly one L marker, as iOS does (3c480a90f). A community URL gives L5. There are new unit tests, and NativeLoginTests asserts L5.
   • Doc and launch-extras fixes (c2aa84b3d): an invalid launch extra is logged and ignored.

Results on API 36.1:

• NativeLoginTests 11/11, plus config rules 8/8
• DPoPLoginTests 18/18
• NegativeLoginTests 3/3
• SDK AuthenticationUtilitiesTest and BrowserLoginTelemetryTest 81/81

In the combined run, the instrumentation process was killed (remove task) before two of the tests started. Both passed when rerun.

[JohnsonEricAtSalesforce]

Thanks, Wolf. Rechecked at 36446b9b1: the successful-held-response request is addressed. All three controlled probes against the actual helper pass, and the test checks transport failure and HTTP 200 before Cancel. The focused authentication/browser telemetry suites also pass locally (81/81), as do four launch-extra checks.

One request remains — [P2] Native cold-restart coverage (NativeLoginTests.kt:174,183; AuthFlowTest.kt:559,748).

• Reproduce: Run either new native relaunch case and compare the app/runner process identity before and after restartApp().
• Expected: Bearer and DPoP sessions restore in a fresh process without clearing data or logging in again, preserving identity, token type, native/DP markers, REST access and refresh/binding.
• Actual: The runner and app share a process. The helper excludes that PID, so the Activity relaunch retains SDK singletons and caches. The revised documentation correctly describes this; the cold-restart acceptance check remains untested.

A bounded option is a host-driven test with two instrumentation invocations: seed the session and finish the first invocation without logout/reset; force-stop the app and verify the old process is gone; then start a fresh verification invocation against the installed app, without reinstalling or resetting data. Assert the restored session and refresh/binding, then clean up. This can be limited to the native Bearer/DPoP cases without rewriting the browser harness.

This is a coverage request, not a demonstrated persistence bug. The review remains Changes requested pending that check.

This response was generated by an AI agent on behalf of @JohnsonEricAtSalesforce.

[wmathurin]

Android emulator: Full AuthFlowTester UI suite run locally: all tests pass against the test1 org (new NativeLoginTests plus the existing browser, Community, DPoP, RTR and restart suites).

[wmathurin]

Thanks @JohnsonEricAtSalesforce, agreed on the analysis. We'd like to leave the true cold-restart check for follow-up work rather than add it in this PR.

• The gap is not specific to Native Login: AuthFlowTester instruments its own app, so restartApp() has never killed the process. LoginWithRestartTests, RTRLoginTests#testECAOpaqueRtr_Hybrid_WithRestart and ConcurrentRestRequestTests#..._RemainsLoggedOutAfterRestart are Activity relaunches too.
• A host-driven two-phase test (seed, am force-stop, fresh verification run without clearing data) needs runner and CI changes: clearPackageData off for that pair, ordering between the two invocations, and a job type that can run adb between phases, which Firebase Test Lab cannot do. That is a test-infrastructure change that should cover all restart suites, not only the two native cases.
• This PR adds the relaunch tests (Bearer and DPoP) and documents them as Activity relaunches in the same process. They check that the form is not shown, identity, token type, markers, REST access, and refresh/binding. The README, KDoc and PR description do not claim cold-restart coverage.

We will track the cold-restart harness as a separate follow-up. Please let us know if you'd rather keep this P2 open as a blocker.

[JohnsonEricAtSalesforce]

Approved at 36446b9b1. The cancellation-state, fixture-validation, session-preservation and documentation fixes are addressed.

We accept Wolf’s proposal to defer genuine cold-restart coverage to shared test-harness follow-up work. The current tests and documentation correctly describe Activity relaunch within the same process.

This response was generated by an AI agent on behalf of @JohnsonEricAtSalesforce.

[wmathurin]

CI: the Community + Native Login Firebase shard (PR and nightly) now has a 45m timeout (was 15m), since it now carries both suites.