Login issue with Email + OTP via Android phones

Embedded Wallets (Web3Auth)
2

Hi bonuz Dev — thanks for the clear report and for the video link. I watched the short and can see the OTP entry UI (Web3Auth) closes after switching to the email app and back — really frustrating, I know. I’ve pulled the details you already provided and a few targeted next steps so the support team can act quickly.

Summary of what I have

  • SDK: MetaMask Embedded Wallets (Web3Auth)
  • Platform: Android (mobile)
  • Issue: Email OTP flow — when the user switches to their email app to copy the OTP and then returns, the Web3Auth OTP screen has already disappeared and the login must be restarted.
  • Video: https://youtube.com/shorts/4HitZ1r6oZA

Missing / helpful details (please provide if available)

  • SDK version number (Web3Auth / Embedded SDK). If you don’t know, any package.json or build.gradle reference is fine.
  • Exact Android environment: Is this a native Android app (Android WebView), a React Native app (react-native-webview), a Capacitor/Electron wrapper, or a browser on Android? Are you using an in-app browser or the system browser for the Web3Auth flow?
  • Initialization + login snippets (the code you use to initialize Web3Auth / MetaMask Embedded and the call that starts email OTP login).
  • Any console logs or Android logs (adb logcat) captured when this happens, or screenshots of the browser console. If using a WebView you can inspect via chrome://inspect and capture logs.

Likely causes & quick troubleshooting steps you can try now
(These are the common causes for the exact behavior you described.)

  1. WebView / activity lifecycle reloads or kills the page when switching apps
    • Android may destroy/recreate the activity or WebView (or the OS may kill the WebView process) and that clears transient state (popup window reference, sessionStorage). Reproduce with chrome://inspect to see whether the page reloads on resume.
  2. Popup/window reference lost (popup flow vs redirect flow)
    • If Web3Auth uses a popup window or an in-app modal that relies on a JS window reference, switching apps can cause that reference to be lost. Consider using a redirect-based flow or a deep-link redirect that resumes the flow reliably.
  3. Storage/cookie not persisted in WebView
    • If using an embedded WebView, confirm DOM storage and cookies are enabled (webSettings.setDomStorageEnabled(true), webSettings.setJavaScriptEnabled(true), enable third-party cookies). For React Native WebView use sharedCookiesEnabled={true} and thirdPartyCookiesEnabled (if available). Incognito modes or ‘clear on background’ settings will break persistence.

Concrete things to check/send to the support team

  • SDK version and platform details (native vs RN vs other). If React Native, tell us the RN WebView version.
  • Your Web3Auth / MetaMask Embedded init snippet and the call that starts email OTP
  • A short repro checklist (exact steps to reproduce on your test device) and whether it’s consistent across Android versions and devices
  • Chrome remote-inspect console logs or adb logcat around the time you switch apps/return
  • Any Android manifest or WebView flags you set related to storage, activity launchMode, or intent filters

Temporary mitigations you can try

  • Switch to a redirect/deeplink flow (so the email-forward-back is handled via a deep link that reopens your app and completes login) instead of a popup-based flow.
  • Ensure WebView settings persist storage/cookies (Dom storage enabled, cookies allowed). For React Native set sharedCookiesEnabled to true.
  • Test on system browser (open external browser for the flow) to confirm whether the issue is WebView-specific.

Relevant docs (quick references)

  • MetaMask docs / Builder Hub: https://docs.metamask.io and https://builder.metamask.io (check Embedded Wallets guides)
  • If you suspect Web3Auth-specific settings, Web3Auth docs cover redirect vs popup flows and deep linking; if you want, share your SDK version and I’ll point to the exact page.

If you can send: (1) SDK version, (2) platform type (native/RN/Capacitor), and (3) the initialization + login snippet — I’ll triage further and propose the most likely fix and exact code changes. If you can also attach a chrome://inspect console capture or adb logcat around the failing run that’ll be a huge help.

I know this is blocking for users — I’ll escalate this to the support team once you provide the SDK version and the init/login snippet so they can dig in. Thanks for reporting and for the video — that made reproduction much clearer.

Note: This response was generated by an AI bot and may require further verification. The MetaMask Community Team has tracked this issue and will be responding as soon as possible.

Additionally, we would recommend you to join our biweekly Office Hours to get this resolved even faster. MetaMask Developer Office Hours