fix: only fire APP_OPENED on background → active transition

[vinnyhoward]

Description

When the QR scanner on iPhone prompts the user to grant camera access, iOS transitions the app to inactive (not background). If the user taps "Cancel" on the permission dialog, the app returns to active, which was incorrectly triggering the App Opened analytics event.

The fix tightens the condition in AppStateEventListener to only fire APP_OPENED when transitioning from background → active, which represents the user genuinely re-opening the app. Transitions from inactive → active (system dialogs, incoming calls, etc.) are now correctly ignored.

Changelog

CHANGELOG entry:null

Related issues

Fixes: https://consensyssoftware.atlassian.net/browse/TMCU-256

Manual testing steps

Feature: App Opened analytics event

  Scenario: user dismisses camera permission dialog from QR scanner
    Given the user has not granted camera access to MetaMask
    And the user is on any screen in the app

    When user taps the QR scanner icon
    And the iOS camera permission dialog appears
    And user taps "Cancel" on the dialog

    Then the App Opened analytics event is NOT fired

  Scenario: user opens the app from the background
    Given the user has backgrounded the app

    When user returns to the app from the app switcher or home screen

    Then the App Opened analytics event IS fired

Screenshots/Recordings

~

Before

~

After

~

Pre-merge author checklist

• I've followed MetaMask Contributor Docs and MetaMask Mobile Coding Standards.
• I've completed the PR template to the best of my ability
• I've included tests if applicable
• I've documented my code using JSDoc format if applicable
• I've applied the right labels on the PR (see labeling guidelines). Not required for external contributors.

Pre-merge reviewer checklist

• I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
• I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.

---

Note

Medium Risk
Changes the gating logic for when APP_OPENED is emitted, which can impact analytics counts and attribution if the app state transitions are misclassified on some platforms.

Overview
Tightens APP_OPENED tracking to reduce false positives. AppStateEventListener now triggers the event only on background → active transitions, and explicitly ignores inactive → active returns (e.g., iOS permission dialogs/calls).

Tests are updated to reflect the required background → active sequence for firing, and add coverage to ensure APP_OPENED does not re-fire on repeated active states or on inactive → active transitions.

^{Written by Cursor Bugbot for commit dd64cc6. This will update automatically on new commits. Configure here.}

[github-actions]

CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes.

[github-actions]

🔍 Smart E2E Test Selection

• Selected E2E tags: None (no tests recommended)
• Selected Performance tags: None (no tests recommended)
• Risk Level: low
• AI Confidence: 95%

click to see 🤖 AI reasoning details

E2E Test Selection:
The change refines analytics behavior in AppStateEventListener to only fire APP_OPENED on background→active transitions. It does not affect controllers, navigation, confirmations, accounts, networks, swaps, snaps, identity, or any UI flows covered by Detox E2E tests. No shared components (Browser, TabBar, Confirmations, Engine, controllers) were modified. E2E tests do not assert analytics behavior or depend on inactive/background transitions. Therefore no E2E coverage is required.

Performance Test Selection:
The change only tightens a conditional check for analytics firing. No UI rendering, controller state management, asset loading, navigation, or startup logic was modified. No performance impact expected.

View GitHub Actions results

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud