[Android] Add ftr_ B/L telemetry markers for browser-login reason and login server type (W-23240736) - #2976
Open
wmathurin wants to merge 18 commits into
Open
Conversation
Add step-by-step Setup section, POST_NOTIFICATIONS permission (Android 13+), SalesforceActionableNotificationContent full field list, NotificationsApiClient, PushService subclassing guide, React Native context, actionable notifications section, and PushNotificationsRegistrationChangeWorkerTest in testing table.
This reverts commit fb487d7.
… selection - L3 is now FEATURE_LOGIN_SERVER_WELCOME_DISCOVERY (welcome.salesforce.com via WD flag) - L4 is now FEATURE_LOGIN_SERVER_MY_DOMAIN (host ending in .my.salesforce.com) - L5 remains the custom/fallthrough bucket - My Domain detection now uses `.my.salesforce.com` host suffix instead of isPoolServer guard - B2 (FEATURE_BROWSER_LOGIN_MDM) stays defined in Features.java for future use but is never selected on Android — MDM on Android forces cert auth (different code path that never sets completedViaBrowserTab); isMdmForcedBrowserLogin() is kept with an explanatory comment pending a real signal - Android B-marker priority is now: B3 (admin) > B4 (force flag) > B1 (server auth config) - Tests updated accordingly (B2 test expects B1 fallthrough; L3/L4 tests use new mapping) Part of W-23240736
- Add 9 new feature constants in Features.java: B1-B4 and L1-L5 - Add isProductionLoginServer() and isMyDomainServer() to LoginServerManager covering internal-env URLs (login.*.salesforce.com, *.my.*.salesforce.com) - Update isPoolServer() to delegate to isProductionLoginServer() - Register B-marker (alongside FEATURE_BROWSER_LOGIN) and L-marker in onAuthFlowSuccess() - Add BrowserLoginTelemetryTest and extend LoginServerManagerTest with helper tests - B2 (MDM) defined but not registered on Android: MDM forces cert auth, not browser login
…-23240736) Add expectedBMarker/expectedLMarker params to validateUserAgent in AuthFlowTesterPageObject. Thread through validateUser(), loginAndValidate(), adminLoginAndValidate(), and assertRevokeAndRefreshWorks(). All current browser-login tests expect B4+L4; admin custom tab tests expect B3+L4; WD tests expect L3.
Generated by 🚫 Danger |
…0736) restartAndValidateUser was not computing expectedBMarker/expectedLMarker, causing the "no B-markers present" assertion to fire for browser-login tests that restart the app (e.g. DPoP restart test). B4 persists across restart in per-user feature flags, so the assertion must expect it.
…(W-23240736) MockK's JVMTI inline agent crashes on API 36 when retransforming LoginActivity during BrowserLoginTelemetryTest class init. The two helpers are pure functions with no Activity state, so moving them to the companion object lets tests call them directly without requiring a mock of LoginActivity at all.
…ateAndValidate (W-23240736) Both helpers were called without setting expectedBMarker, causing the validator to assert no B-markers at all. But when forceAdvancedAuthentication=true (the default), B4 is registered at login time and persists through user-switch and migration. Apply the same expectedBMarker derivation already used in assertRevokeAndRefreshWorks and restartAndValidateUser.
…inTests + AuthFlowTest (W-23240736) The local switchToUserAndValidate helper, migrateAndValidate, and two direct validateUser calls in MultiUserLoginTests all omitted expectedBMarker, causing the validator to assert no B-markers are present even though B4 is registered when forceAdvancedAuthentication=true. Also add the missing isMultiUser parameter to migrateAndValidate so callers where two users are logged in can pass isMultiUser=true. Add a waitForAppLoad() before the post-SDK-logout validateUserAgent call in testAdvancedAuthUser_HasBWFlag_RegularAuthUser_DoesNot to handle the async UI re-render after the backgrounded logout completes.
…n details Document the B-marker and L-marker ftr_ code families validated by validateUserAgent, including priority rules, per-marker semantics, and note that B2 is iOS-only. Also note B4 assertion in AdvancedAuthBeaconLoginTests section. (W-23240736)
…ll (W-23240736) validateUser call at line 125 omitted expectAdvancedAuth and expectedBMarker. User logged in with forceAdvancedAuthentication=true so B4+BW are present.
Contributor
Author
Local test run resultsAll tests run on API 36 emulator against the Unit tests
AuthFlowTester UI tests
CI failures on this PRThe 3 CI failures ( |
brandonpage
approved these changes
Aug 5, 2026
…nLoginTests; update README
…without login When the test (or a user) backs out of the auto-launched Custom Tab and then proceeds with the in-app WebView, completedViaBrowserTab was left as true from the tab launch. onAuthFlowSuccess() would then register BW per-user for what was actually a WebView login, causing the InAppWebView UI tests to fail with 'Expected no BW flag'. Reset the flag to false in CustomTabActivityResult.RESULT_CANCELED so the subsequent WebView completion sees the correct state.
wmathurin
force-pushed
the
browser-login-telemetry-markers
branch
from
August 6, 2026 03:31
f48f8b2 to
2c3daa5
Compare
…ions changes auth surface Resetting on RESULT_CANCELED was too broad: that callback fires during server-change back-outs (ADVANCED_AUTH tests) where the next Custom Tab should still register BW. Resetting in clearWebView() was also too broad: clearWebView fires mid- flow before Login Options opens (UAF path), wiping the flag before the Custom Tab re-launches and sets it back. The only moment when the auth surface genuinely changes is when Login Options closes: loginDevMenuReload=true, which triggers onResume → reloadWebView(). Reset completedViaBrowserTab=false there, before reloadWebView() decides which surface to use: - InAppWebView path: isBrowserLoginEnabled=false → reloadWebView() skips onBrowserCustomTabReady → flag stays false → BW not registered ✓ - UAF/forced-advanced-auth: isBrowserLoginEnabled=true → reloadWebView() calls loadLoginPageInCustomTab → flag set back to true → BW registered ✓ - ADVANCED_AUTH server-change: no Login Options → loginDevMenuReload never set → onResume reset never fires → unaffected ✓
wmathurin
force-pushed
the
browser-login-telemetry-markers
branch
from
August 6, 2026 03:48
2c3daa5 to
b4c41a0
Compare
…WebView path When useWebServerFlow=false, adminLoginAndValidate intends to start with the in-app WebView so it can reach the Login Options and Login for Admins menu items. But ensureRegularAuthServer was called without forceAdvancedAuthentication=false, so the SDK re-launched a Custom Tab over the WebView after the server re-selection. The Compose hierarchy was then behind the tab, causing openLoginOptions() to crash with "No compose hierarchies found in the app". Pass forceAdvancedAuthentication=useWebServerFlow so that the WebView path also clears the forced-advanced-auth flag, matching the in-app WebView surface that topBarPage (a plain LoginPageObject) expects to drive.
…ionPageObject tapAllowInCustomTab and tapAllowInWebView used repeat(MAX_RETRIES=5) × 500ms = 2.5s total to poll for the server-rendered Allow button. On FTL (and locally) for second-user logins, Chrome is in a different pre-warmed state and the button arrives after that window closes, so login never completes and waitForAppLoad() times out. Replace all three polling loops with a deadline-based while loop that polls for the full TIMEOUT_MS budget (15s on FTL, 10s locally), matching the budget every other waitForNode/waitForCustomTab call already uses. Remove the now-unused MAX_RETRIES constant. Fixes testAdvancedAuthUser_HasBWFlag_RegularAuthUser_DoesNot (pre-existing failure on dev and on this branch).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds 8 new per-user `ftr_` telemetry markers to the SDK user-agent string (B2 deferred on Android):
Follow-up to W-23126676 (Force Advanced Authentication flag). Spec and plan live in the Workspace repo under `specs/W-23701450-W-23240736-browser-login-telemetry-markers/`. Companion iOS PR: forcedotcom/SalesforceMobileSDK-iOS.
B-markers — "why browser login was used"
Registered per-user alongside `BW`. Exactly one B-marker per user. Priority: B3 > B4 > B1 (B2 deferred — no reliable MDM browser-login signal on Android).
L-markers — "which login server type"
Registered per-user on every non-refresh login (browser or WebView). Exactly one L-marker per user.
Implementation
Tests
Notes