Skip to main content
Every SDK screen - the linking webview, the reward hub, and offers - covers the game while it is open. The unified lifecycle pair tells you exactly when to pause and resume, regardless of what opened the screen (an API method or the LinkButton prefab):
The contract that makes this safe to wire one-to-one to pause/resume:
  • Matched pairs. A screen that appears fires exactly one OnScreenPresented and, later, exactly one OnScreenDismissed. Never two presents in a row, never a dismiss without a present.
  • No-ops fire nothing. A call that opens nothing (wrong state, missing URL, another screen already open) fires neither event, so the game never pauses for a screen that never appeared.
  • Presented fires early. It fires when the native container commits to presenting, before the page loads - the pause lands before the player sees the screen.
  • Dismissed fires after the sync. Native completes its sync-on-close first, so Almedia.Status and related state are already up to date in the handler. For webview linking, the dismissal also fires before the outcome link callbacks (OnLinkCompleted etc.).
  • System-browser linking is excluded. When linking runs in the system browser, the app is backgrounded by the OS rather than covered - use the regular application lifecycle for that case; only the link callbacks fire.
The screen argument (AlmediaScreen) identifies which screen it was, for analytics or per-screen UX. Both events fire on the Unity main thread, like every other SDK event - see Threading.