Description

Removed the global RiveRenderer.defaultRenderer(..., RiveRendererAndroid.Canvas) call in FoxLoader during app init. Although this lived in the splash-screen loader, defaultRenderer is a process-wide setting that forced every Rive view in the app onto Android's Canvas renderer Surface.lockCanvas path. This caused the Money/Earn onboarding stepper to hard-crash SIGABRT/SIGSEGV on Android when the Rive view tore down during tab navigation, the worker thread called lockCanvas on an already-released Surface, leaving a pending JNI exception that ART aborted on. Tombstone confirmed on Pixel 6a / Android 16. Reverting to the default Rive GPU renderer removes the lockCanvas code path entirely.

iOS is unaffected (already uses the GPU renderer).

Changelog

CHANGELOG entry: Fixed an Android crash when entering Earn onboarding caused by the Rive Canvas renderer being forced app-wide.

Related issues

Fixes: #31166
#31167

Manual testing steps

Feature: Earn onboarding no longer crashes on Android

  Scenario: User enters Earn onboarding on Android after fresh install
    Given the app is built in release mode on a Pixel 6a (or equivalent) running Android 16
    And the user has completed initial app load (FoxLoader splash animation plays)

    When the user taps the Money/Earn tab
    And the Rive onboarding stepper mounts
    Then the app does not crash
    And the onboarding animation renders and steps through normally

  Scenario: Splash animation still plays on Android
    Given a fresh launch on Android
    When the FoxLoader splash screen appears
    Then the fox Rive animation plays to completion without visual regressions

Screenshots/Recordings

Before

Crash on open

Crash on close

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.

Performance checks (if applicable)

• I've tested on Android
  • Ideally on a mid-range device; emulator is acceptable
• I've tested with a power user scenario
  • Use these power-user SRPs to import wallets with many accounts and tokens
• I've instrumented key operations with Sentry traces for production performance metrics
  • See trace() for usage and addToken for an example

For performance guidelines and tooling, see the Performance Guide.

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.