From 263835ad74ea2fd806fc915394494fc7a598d4ab Mon Sep 17 00:00:00 2001
From: duffyduck <info@hacker-net.de>
Date: Sat, 30 May 2026 23:01:12 +0200
Subject: [PATCH] =?UTF-8?q?fix(wake):=20Conversation-Window=20nur=20im=20F?=
 =?UTF-8?q?oreground,=20Background=20=E2=86=92=20direkt=20re-armen?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Symptom: Wake-Word laeuscht nach erfolgreicher Konversation im
Hintergrund nicht wieder — erst beim App-Vorholen wird's wieder
armed. Grund: nach TTS-Ende laeuft wakeWordService.resume() in
einen setTimeout(800ms) der im Doze stark verzoegert wird. Der
verspaetete Timer findet dann delay > 2800 und ruft endConversation
(re-arm) — aber eben erst beim App-Resume.

Fix: in onPlaybackFinished AppState pruefen:
  active     → resume() wie bisher (Multi-Turn-Conversation-Window)
  background → endConversation() direkt — kein setTimeout, native
               OpenWakeWord.start() greift sofort.

Begruendung fuer das Verhalten:
- Foreground: User ist aktiv, Multi-Turn-Dialog ohne erneutes
  "Computer"-Sagen ist nuetzlich.
- Background: User nutzt das Handy anderweitig, automatisches Mikro-
  Oeffnen ist nicht erwartet und droht durch Doze-Verzoegerung in
  ein Phantom-Trigger-Mismatch zu kippen. Direkt re-armen ist
  robust + erwartungskonform.

Eng verwandt mit dem 0.1.7.0-Fix (kein setTimeout zwischen
wake.detect und Callback) — selbes Doze-Throttling-Pattern, andere
Stelle in der Pipeline.
---
 android/src/screens/ChatScreen.tsx | 23 +++++++++++++++++++++--
 1 file changed, 21 insertions(+), 2 deletions(-)

diff --git a/android/src/screens/ChatScreen.tsx b/android/src/screens/ChatScreen.tsx
index 7781445..b079bf0 100644
--- a/android/src/screens/ChatScreen.tsx
+++ b/android/src/screens/ChatScreen.tsx
@@ -1263,11 +1263,30 @@ const ChatScreen: React.FC = () => {
     return () => { unsubUpdate(); clearTimeout(timer); };
   }, []);
 
-  // Gespraechsmodus: Nach TTS-Wiedergabe automatisch Aufnahme starten
+  // Gespraechsmodus: Nach TTS-Wiedergabe weiter im Multi-Turn (Conversation-
+  // Window) oder zurueck zu armed (Wake-Word lauscht wieder)?
+  //
+  //   Foreground   → resume() oeffnet das Mikro fuer N Sekunden Follow-Up
+  //                  (natuerlicher Dialog moeglich ohne erneutes "Computer")
+  //   Background   → endConversation() — Wake-Word direkt wieder armed.
+  //
+  // Grund: der setTimeout(800ms) in resume() wird im Doze stark verzoegert
+  // (siehe Wake-Detect-Bug von 0.1.7.0). Das hat zwei nervige Folgen:
+  //   1) Wake-Word ist solange "tot" — User kann ARIA nicht mehr triggern
+  //      bis er die App vorholt
+  //   2) Wenn er die App dann vorholt, oeffnet der verspaetete Timer das
+  //      Mikro — sieht aus wie ein Phantom-Wake-Word-Trigger
+  // Background = User nutzt das Handy anderweitig, das Multi-Turn-Konzept
+  // ist da eh nicht nuetzlich. Direkt re-armen ist robust und erwartungs-
+  // konform.
   useEffect(() => {
     const unsubPlayback = audioService.onPlaybackFinished(() => {
-      if (wakeWordService.isActive()) {
+      if (!wakeWordService.isActive()) return;
+      if (AppState.currentState === 'active') {
         wakeWordService.resume();
+      } else {
+        console.log('[Chat] TTS fertig im Background → endConversation (kein Multi-Turn)');
+        wakeWordService.endConversation().catch(() => {});
       }
     });
     return () => unsubPlayback();