[Android][Voice in Chat] Rotation reinitializes bubbles and cuts off active response

Summary

In the ChatGPT Android app, rotating the phone during an ordinary Voice in Chat conversation recreates/reinitializes the live voice UI. The response bubbles restart and the current spoken response can be cut off instead of continuing across the orientation change.

This is the normal ChatGPT assistant/Voice-in-Chat flow, not Codex Remote.

Environment

• Device: Samsung Galaxy A70 (SM-A705FN)
• Android: 11
• ChatGPT app: 1.2026.230
• Android build shown by the app/device context: 2623032
• Observed: 2026-09-02
• Display setting: auto-rotate enabled

Steps to reproduce

1. Open the ChatGPT Android app.
2. Start or continue a normal Voice-in-Chat conversation.
3. Ask a question and wait while ChatGPT is speaking/rendering the answer.
4. Rotate the phone between portrait and landscape.
5. Observe the voice bubbles and active response state.

Actual behavior

The voice/conversation bubbles visibly restart or reinitialize after rotation. An in-progress spoken response may be interrupted/cut off, forcing the user to ask for the missing part again.

Expected behavior

An Android configuration change should preserve:

• the active voice session and transport;
• playback position and streaming state;
• the in-progress assistant response;
• transcript/bubble state;
• conversation identity and pending UI state.

Rotation may recompose/re-layout the UI, but it should not restart the interaction or lose any portion of the answer.

User impact

This makes normal phone rotation destructive during a voice conversation. Disabling auto-rotate is a workaround, but users should not have to disable a standard Android feature to keep a live ChatGPT response intact.

Suggested implementation direction

The closed Android client source is not available in this repository, so this is implementation guidance rather than a patch against the production code:

• Keep voice/session ownership outside the Activity/Composable lifecycle (for example, an Activity-scoped or navigation-graph-scoped ViewModel backed by a longer-lived session repository/service).
• Store UI state in StateFlow and use SavedStateHandle only for lightweight restoration identifiers—not the live audio transport itself.
• Make connection/start events idempotent so recomposition or Activity recreation cannot initiate a second session.
• Key effects to a stable session ID rather than a Composable instance.
• Do not disconnect or clear the active response from Activity.onDestroy() when isChangingConfigurations == true.
• Restore playback/stream observation after recreation without replaying already-consumed events.

Illustrative lifecycle guard:

override fun onDestroy() {
    if (!isChangingConfigurations) {
        voiceSessionController.detachUi()
    }
    super.onDestroy()
}

The precise production fix may differ depending on whether the app uses Compose, Views, a foreground service, or another realtime-session abstraction.

Suggested regression test

Add an instrumentation test that:

1. starts a fake streaming voice response;
2. emits several transcript/audio chunks;
3. recreates the Activity or changes orientation;
4. continues emitting chunks;
5. verifies that the same session ID remains active;
6. verifies that no second connect/start call occurs;
7. verifies uninterrupted transcript ordering and playback position;
8. verifies the response completes exactly once.

A separate manual QA pass should cover portrait → landscape → portrait during both user recording and assistant playback.

The production Android client source is not available in this repository, so there is no implementation file or entry point to inspect here. Start by validating the issue against a client repository that contains the voice session lifecycle, then use the suggested Activity recreation instrumentation test to verify session identity, transcript ordering, playback continuity, and exactly-once completion.