We have had a massive problem to solve for months.
It happens only on Android devices and only for users who use email login, which sends an OTP to their email address.
The problem is:
Once they switch to the email app to receive the OTP code, then switch back to our wallet app to enter the OTP. The web3auth otp ENTERING screen has already disappeared, and the whole login process has to start from ZER0 again!
Please help us solve this. As perhaps you must have came many times accross this issue.
Please watch the video actually to see the problem.
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.
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.)
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.
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.
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.
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
The problem is: