Planungen android

android/ANDROID_APP_PLAN.md

@@ -0,0 +1,605 @@
+# Android-App-Plan fuer YourPart3
+
+Stand: 2026-07-08
+
+## Ziel
+
+Dieses Dokument plant eine Android-App fuer das bestehende YourPart3-Projekt unter `/android`.
+
+Das Projekt besteht aktuell aus:
+
+- `frontend`: Vue 3, Vite, Vuetify, Vue Router, Vuex, Axios, Socket.IO Client, Three.js
+- `backend`: Node.js/Express 5, Sequelize, Redis-Sessiondaten, OAuth/OIDC, Socket.IO, REST-APIs
+- Authentifizierung: Login liefert einen User mit `id`/`authCode`; API-Requests senden Header `userid` und `authcode`
+- Realtime: Socket.IO fuer Backend-Events und separater Daemon-WebSocket fuer Falukant-Updates
+- Deployment: Backend serviert die gebaute SPA aus `frontend/dist`
+
+Backend-Implementierung ist nicht Teil dieses Android-Starts. Das vorhandene Backend wird als gegeben betrachtet; Android-seitig werden nur Kompatibilitaet, URLs, Auth-Header, OAuth-Weiterleitung und Realtime-Verbindungen getestet.
+
+## Empfehlung
+
+Die Android-App sollte in Phase 1 als Capacitor-App umgesetzt werden, nicht als nativer Rewrite.
+
+Begruendung:
+
+- Die bestehende App ist bereits eine grosse SPA mit vielen Views: Social Network, Falukant, Vokabeltrainer, Minigames, Kalender, Admin, Settings.
+- Der Auth-Mechanismus und die vorhandenen API-Clients sind Web-orientiert und koennen in einer WebView nahezu unveraendert weiterlaufen.
+- OAuth-Callback-Routen existieren bereits im Frontend (`/auth/oauth/callback`, `/auth/oauth/user/callback`).
+- Socket.IO und WebSocket-Verbindungen funktionieren in Capacitor deutlich schneller als in einem nativen Rewrite.
+- Ein nativer Rewrite wuerde zuerst API-Vertraege, Sessionmodell, Navigation, Offline-Strategie und UI-Komponenten neu definieren muessen.
+
+Zielarchitektur Phase 1:
+
+```text
+/android
+  capacitor.config.ts
+  package.json
+  android/
+    Android-native Projektdateien, durch Capacitor generiert
+
+/frontend
+  bestehende Vue/Vite-App
+
+/backend
+  bestehende Express/API/Socket.IO-App
+```
+
+Capacitor verwendet den bestehenden `frontend`-Build als Web-Bundle und erzeugt daraus eine installierbare Android-App.
+
+## Nicht-Ziele fuer Phase 1
+
+- Kein kompletter nativer Kotlin/Jetpack-Compose-Rewrite.
+- Keine Offline-First-Synchronisation fuer Falukant/Social/Vocab.
+- Keine komplette Neugestaltung aller mobilen Screens.
+- Keine API-Versionierung fuer mobile Clients, solange die App nur das bestehende Web-Frontend verpackt.
+- Keine Play-Store-Verteilung vor Datenschutz-, Content- und OAuth-Pruefung.
+- Keine Backend-Neuentwicklung und keine Backend-API-Neuplanung.
+
+## Getroffene Entscheidungen
+
+### App-Technologie
+
+- Entscheidung: Capacitor mit lokal gebuendelter Vue/Vite-App.
+- Kein nativer Kotlin-Rewrite in Phase 1.
+- Kein reiner Remote-WebView-Wrapper auf `https://www.your-part.de`.
+- Begruendung: Der vorhandene Funktionsumfang ist breit, Web-Auth und Socket.IO existieren bereits, und Capacitor ermoeglicht spaetere native Erweiterungen ohne sofortigen Rewrite.
+
+### App-ID und Name
+
+- App-ID: `de.yourpart.app`
+- Launcher-Name: `YourPart`
+- Android-Projektpfad: `/android`
+- Capacitor `webDir`: `../frontend/dist`
+
+### Ziel-Distribution
+
+- Phase 1: interne Debug-/Test-APK.
+- Phase 2: signiertes internes AAB/APK fuer Testgeraete.
+- Play Store erst nach separatem Compliance-Check fuer Datenschutz, UGC, Moderation und Adult Content.
+
+### Backend-Abgrenzung
+
+- Backend bleibt unveraendert.
+- Android nutzt die bestehenden REST-Endpunkte, Auth-Header, OAuth-Routen, Socket.IO-Events und Daemon-WebSocket-Events.
+- Backendbezogene TODOs sind nur Test- und Konfigurationschecks. Falls ein Test scheitert, wird der konkrete Anpassungsbedarf danach separat entschieden.
+
+### Admin-Bereich
+
+- Admin-Routen bleiben in Phase 1 nicht priorisiert.
+- Wenn Admin-Menues durch bestehende Berechtigungen sichtbar sind, werden sie nicht aktiv entfernt.
+- Abnahmekriterien fuer Phase 1 gelten nur fuer normale Nutzerfunktionen.
+
+### Adult-/Erotikbereiche
+
+- Phase 1: vorhandenes Web-Gating bleibt bestehen, keine neue native Adult-Content-Funktion.
+- Play-Store-Ziel ist blockiert, bis Altersfreigabe, UGC-Moderation, Melden/Blockieren, Datenschutz und Store-Policy separat geprueft sind.
+- Fuer interne APK-Tests darf der Bereich technisch erreichbar bleiben, wenn der bestehende Account-/Altersstatus ihn erlaubt.
+
+### OAuth
+
+- Phase 1 startet mit Username/Passwort-Login als Pflichtfunktion.
+- OAuth ist Phase-1-Testumfang, aber kein Blocker fuer das erste Debug-APK.
+- Zielrichtung fuer OAuth: externer Browser bzw. System-Browser plus App Links, nicht OAuth in einer versteckten WebView erzwingen.
+
+### Push Notifications
+
+- Push ist nicht Teil des ersten Android-Scaffolds.
+- Push wird nach stabiler App-Shell geplant, weil dafuer Device Tokens, Opt-in, Settings und Backend-Zustellung noetig sind.
+
+### 3D / WebGL
+
+- 3D-Charaktere werden im Android-Debug-Build initial per `VITE_DISABLE_3D=true` deaktiviert.
+- Begruendung: Die Login-Seite rendert mehrere `Character3D`-Instanzen sofort. In Kombination mit CORS-Fehlern und vielen GLB-Kandidaten kann der Emulator-WebView-Renderer per OOM abstuerzen.
+- Reaktivierung erfolgt erst nach erfolgreichem CORS-Test und separatem 3D-Performance-Test.
+
+### Navigation
+
+- Vue `createWebHistory` bleibt initial unveraendert.
+- Hash-Routing wird nur eingefuehrt, wenn Capacitor-Tests echte Routing-Probleme zeigen.
+- Android Back Button wird als native App-Anforderung in Phase 1 umgesetzt.
+- Mobile Navigation bleibt Teil der Web-App, wird aber fuer Android als kompakte Hybrid-Navigation gehaertet: Header-Leiste, aufklappbares scrollbares Menue, keine dauerhaft sichtbare Desktop-Menueflaeche auf kleinen Displays.
+
+### Sichere Speicherung
+
+- Phase 1 darf bestehendes `localStorage`/`sessionStorage` weiterverwenden.
+- Vor Play-Store-Release wird Auth-Persistenz auf Secure Storage/Android Keystore umgestellt.
+
+## Technische Ausgangslage
+
+### Frontend
+
+- Zentrale API-Konfiguration: `frontend/src/utils/axios.js`
+- API-Basis-URL: `frontend/src/utils/appConfig.js` ueber `VITE_API_BASE_URL`
+- Auth-Header: `userid` und `authcode`
+- Persistenz: `localStorage` oder `sessionStorage` fuer `isLoggedIn`, `user`, `userid`
+- Router: `createWebHistory`, viele Clean-URL-Routen
+- Realtime: `socket.io-client` ueber `VITE_SOCKET_IO_URL`
+- Daemon-WebSocket: ueber `VITE_DAEMON_SOCKET`
+- 3D/Assets: Three.js und Modelle ueber `/api/models` bzw. statische Assets
+
+### Backend
+
+- CORS erlaubt aktuell konfigurierte Origins und lokale Web-Origins.
+- Auth-Middleware prueft `userid` und `authcode`.
+- OAuth startet serverseitig per Redirect.
+- Socket.IO erlaubt aktuell `origin: '*'`.
+- Backend serviert SPA-Fallback fuer Nicht-API-Routen.
+
+## Android-Strategie
+
+### Phase 1: Capacitor Shell
+
+Die Android-App laedt nicht die Produktionswebsite remote, sondern nutzt das lokal gebundelte Vite-Build-Artefakt.
+
+Vorteile:
+
+- App startet auch dann, wenn die Website selbst nicht als Web-Seite geladen werden muss.
+- Google Play bewertet sie eher als App statt als reinen Browser-Shortcut.
+- Versionierbare Builds mit reproduzierbarer Web-Bundle-Version.
+- Zugriff auf native Funktionen bleibt moeglich: Splash Screen, Deep Links, Push Notifications, sichere Speicherung.
+
+Wichtige Anpassung:
+
+- `VITE_API_BASE_URL`, `VITE_SOCKET_IO_URL`, `VITE_DAEMON_SOCKET` muessen fuer Android-Builds explizit auf die produktiven HTTPS/WSS-Endpunkte gesetzt werden.
+- Relative API-URLs sind in einer gebuendelten Android-WebView riskant, weil `window.location.origin` nicht der Server-Origin ist.
+
+### Phase 2: Mobile Web-Haertung
+
+Die bestehende UI muss fuer kleine Viewports und Touch-Nutzung stabilisiert werden.
+
+Prioritaeten:
+
+- Login/Register/OAuth
+- Hauptnavigation
+- Falukant-Overview, Branch, Family, Bank
+- Vokabeltrainer und Lessons
+- Chat/Friends/Forum-Basics
+- Minigames nur nach separater Touch-Performance-Pruefung
+
+### Phase 3: Native Integrationen
+
+Nach stabiler Shell koennen echte App-Features ergaenzt werden:
+
+- Push Notifications fuer Chat, Freund-Login, Falukant-Events
+- Deep Links fuer OAuth-Callbacks und geteilte Inhalte
+- Android Back Button Integration
+- Splash Screen und App Icons
+- Secure Storage fuer Authdaten
+- App Update / Version Check
+
+### Phase 4: Selektiv native Screens
+
+Wenn einzelne Bereiche Performance- oder UX-Probleme haben, koennen sie spaeter nativ ersetzt werden. Kandidaten:
+
+- Login/Onboarding
+- Push Notification Center
+- Vokabeltrainer Session
+- Falukant Status/Quick Actions
+
+## Repository-Layout
+
+Vorgeschlagenes Layout:
+
+```text
+android/
+  ANDROID_APP_PLAN.md
+  README.md
+  package.json
+  capacitor.config.ts
+  android/                # Capacitor Android-Projekt
+  scripts/
+    build-android-web.sh
+    sync-android.sh
+```
+
+Hinweis: In Phase 1 wird `/android/android` generiert, weil `/android` die Capacitor-Projektwurzel ist. Die generierten Android-Dateien werden versioniert, weil reproduzierbare Builds und native Anpassungen wichtig sind.
+
+## Build-Konzept
+
+### Android Web-Build
+
+Ein eigener Build-Modus verhindert Vermischung mit Web-Production:
+
+```bash
+cd frontend
+npm run build -- --mode android
+```
+
+Dafuer wird eine Datei `frontend/.env.android` benoetigt:
+
+```env
+VITE_API_BASE_URL=https://www.your-part.de
+VITE_SOCKET_IO_URL=https://www.your-part.de
+VITE_DAEMON_SOCKET=wss://www.your-part.de
+VITE_PUBLIC_BASE_URL=https://www.your-part.de
+```
+
+Wichtig: `VITE_API_BASE_URL` ist bewusst nur die Origin ohne `/api`, weil die bestehenden Frontend-Aufrufe bereits Pfade wie `/api/auth/login` enthalten. Mit `/api` in der Base-URL entstehen Android-seitig falsche Requests wie `/api/api/...`.
+
+Die exakten WebSocket-Pfade muessen gegen die produktive Apache-/Backend-Konfiguration verifiziert werden.
+
+### Lokaler Emulator-Stand
+
+Android Studio und mehrere AVDs sind lokal vorhanden. Fuer die ersten Stabilitaetstests ist `trainingstagebuchApi35` die bevorzugte VM, weil sie im bisherigen Test stabiler lief als das Play-Store-Image `Medium_Phone`.
+
+```bash
+ANDROID_AVD_HOME=/home/torsten/.config/.android/avd /home/torsten/Android/Sdk/emulator/emulator -avd trainingstagebuchApi35 -no-snapshot-save
+adb install -r android/android/app/build/outputs/apk/debug/app-debug.apk
+adb shell am start -W -a android.intent.action.MAIN -c android.intent.category.LAUNCHER -n de.yourpart.app/.MainActivity
+```
+
+Ergebnis bisher:
+
+- Debug-APK wurde erfolgreich gebaut.
+- APK wurde auf einem Emulator installiert.
+- App startet als `de.yourpart.app/.MainActivity`.
+- Login-Screen rendert mobil.
+- API-Base-URL wurde von `/api` auf die Origin `https://www.your-part.de` korrigiert, damit keine `/api/api`-Requests entstehen.
+- Capacitor `server.hostname` darf nicht auf `www.your-part.de` gesetzt werden, weil sonst echte Backend- und Model-URLs als lokale App-Assets behandelt werden.
+- Nach Entfernung der Hostname-Kollision ist die Android-App-Origin `https://localhost`. Das Backend muss diese Origin in `CORS_ORIGINS` erlauben, sonst blockiert die WebView REST- und GLB-Requests.
+
+### Capacitor Sync
+
+Nach dem Frontend-Build:
+
+```bash
+cd android
+npx cap sync android
+```
+
+Danach:
+
+```bash
+cd android
+npx cap open android
+```
+
+Oder per CLI:
+
+```bash
+cd android
+./gradlew assembleDebug
+```
+
+Lokaler Build-Hinweis:
+
+- Auf diesem System liegt das Android SDK unter `/home/torsten/Android/Sdk`.
+- Die lokale Datei `/android/android/local.properties` setzt `sdk.dir` darauf und ist absichtlich nicht versioniert.
+- Erstes Debug-APK wurde erfolgreich gebaut: `/android/android/app/build/outputs/apk/debug/app-debug.apk`.
+
+## Authentifizierung
+
+### Bestehender Login
+
+Der bestehende Login kann initial unveraendert bleiben:
+
+- `POST /api/auth/login`
+- Antwort enthaelt User inkl. `authCode`
+- Axios haengt `userid` und `authcode` an Folgerequests
+- Storage bleibt vorerst `localStorage`/`sessionStorage`
+
+### Sicherheitsverbesserung
+
+Phase 1 kann noch mit Web Storage starten. Vor Play-Store-Release sollte Auth aber in native sichere Speicherung verschoben werden:
+
+- Capacitor Preferences nur fuer unkritische Werte
+- Fuer sensible Werte besser Android Keystore ueber ein Secure-Storage-Plugin
+- Migration: Store liest zuerst Secure Storage, fallback auf lokalen Web Storage, migriert dann
+
+### OAuth
+
+OAuth ist der groesste Integrationspunkt.
+
+Kurzfristige Option:
+
+- OAuth im In-App Browser oder externen Browser starten
+- Callback bleibt auf `https://www.your-part.de/auth/oauth/callback`
+- Die Callback-Seite tauscht `code/state` wie bisher gegen einen App-User
+
+Bessere App-Option:
+
+- Android App Links fuer `https://www.your-part.de/auth/oauth/callback`
+- `assetlinks.json` auf der Domain bereitstellen
+- Capacitor App Plugin verarbeitet den Deep Link und routet intern weiter
+
+Risiko:
+
+- OAuth Provider koennen eingebettete WebViews einschraenken. Deshalb sollte OAuth nicht in einer versteckten WebView erzwungen werden, sondern ueber Browser/App Links laufen.
+
+## API und CORS
+
+Fuer Capacitor-Bundles ist die Origin nicht immer identisch mit der Website-Origin.
+
+Zu pruefen:
+
+- Welche Origin sendet Android WebView bei Requests an `https://www.your-part.de/api`?
+- Muss `CORS_ORIGINS` um `https://localhost` erweitert werden?
+- Funktionieren Custom Header `userid` und `authcode` in der WebView?
+- Funktionieren Preflight-Requests mit den bestehenden erlaubten Headers?
+
+Noetige Backend-Konfiguration fuer Debug-Builds:
+
+```env
+CORS_ORIGINS=https://www.your-part.de,https://localhost,http://localhost:5173,http://127.0.0.1:5173
+```
+
+Nur nach Test setzen; nicht blind `CORS_ALLOW_ALL=1` fuer Produktion verwenden.
+
+## Navigation und Deep Links
+
+Die Vue-App nutzt `createWebHistory`. In Capacitor kann das funktionieren, aber folgende Punkte muessen getestet werden:
+
+- Direktstart auf `/`
+- Interne Navigation zu `/falukant/home`, `/friends`, `/socialnetwork/vocab/...`
+- Android Back Button
+- OAuth Callback URL
+- App-Resume nach Browser-OAuth
+
+Falls History-Mode Probleme in der WebView macht:
+
+- Option A: Capacitor-spezifisch auf Hash-History wechseln
+- Option B: History beibehalten und Deep-Link-Routing sauber behandeln
+
+Hash-History waere technisch einfacher, aber wegen bestehender SEO-/Web-Routen nicht global fuer das Web-Frontend umstellen.
+
+## Realtime
+
+### Socket.IO
+
+Bestehender Ablauf:
+
+- Nach Login `initializeSocket`
+- Socket verbindet zu `VITE_SOCKET_IO_URL`
+- Client sendet `setUserId` mit `hashedId` oder `id`
+
+Android-Testfaelle:
+
+- Login erzeugt Socket-Verbindung
+- App im Hintergrund trennt/reconnectet sauber
+- Friend-Login-Events kommen an
+- Schlechte Verbindung erzeugt keine Endlos-Fehlerdialoge
+
+### Daemon-WebSocket
+
+Falukant nutzt zusaetzliche Daemon-Events. Android muss mindestens diese Events empfangen koennen:
+
+- `falukantUpdateFamily`
+- `falukantUpdateStatus`
+- `falukantUpdateProductionCertificate`
+- `children_update`
+- `falukantUpdateChurch`
+- `falukantUpdateDebt`
+
+Test:
+
+- WSS ueber produktiven Proxy
+- Reconnect nach App-Resume
+- Filterung nach `user_id`
+
+## Mobile UX Prioritaeten
+
+Die App sollte nicht nur ein Desktop-Layout in einer WebView zeigen. Phase 1 braucht mindestens diese UX-Haertung:
+
+- Header/Navigation auf kleinen Viewports pruefen
+- Dialoge auf 360px Breite testen
+- Tabellen und breite Falukant-Views horizontal oder responsiv absichern
+- Touch-Ziele mindestens ca. 44px
+- Keyboard-Verhalten im Login/Register testen
+- Safe Area Insets fuer Statusbar/Navigationbar beachten
+- Android Back Button: Dialog schliessen, sonst Router zurueck, sonst App minimieren
+
+Aktueller Stand 2026-07-08:
+
+- Hauptnavigation ist auf kleinen Viewports zu einer kompakten Menueleiste mit aufklappbarem, scrollbarem Menue umgebaut.
+- Header ist auf Smartphone-Breite kompakter, Statusanzeigen laufen zweispaltig statt als lange Desktop-Leiste.
+- Footer blendet leere System-/Fensterbereiche auf Smartphone-Breite aus und reserviert Safe-Area-Abstand nach unten.
+- App-Shell nutzt `100dvh` als Android-WebView-freundlichere Viewport-Hoehe.
+
+## Datenschutz, Content und Store-Risiken
+
+Das Projekt enthaelt Social-, Chat-, Galerie-, Erotik-/Adult- und Moderationsbereiche. Fuer Play Store sind diese Punkte kritisch:
+
+- Altersfreigabe und Adult-Content-Gating
+- UGC-Moderation, Meldefunktion, Blockieren
+- Datenschutzrichtlinie in der App und im Store Listing
+- Account-Loeschung oder klare Anleitung
+- Sichere Uebertragung nur per HTTPS/WSS
+- Keine unsicheren Debug-Endpunkte im Release-Build
+- Keine Secrets im Android-Bundle
+
+Vor Play-Store-Release muss ein eigener Compliance-Check erfolgen.
+
+## Teststrategie
+
+### Lokale Tests
+
+- Android Emulator mit Debug-Build
+- Echtes Android-Geraet im gleichen Netz
+- Produktions-API mit Testnutzer
+- Offline/Online-Wechsel
+- App Kill/Restart/Resume
+
+### Kern-Testmatrix
+
+- Login mit Username/Passwort
+- Logout
+- Registrierung
+- Passwort vergessen
+- OAuth Login je Provider, soweit konfiguriert
+- Menu-Load nach Login
+- Falukant Overview laden
+- Falukant Realtime-Update empfangen
+- Vokabeltrainer Lesson starten und abschliessen
+- Chat verbinden und Nachricht empfangen
+- Galerie/Bild-Upload, falls mobil zunaechst erlaubt
+- Minigames Touch-Steuerung
+- Admin-Bereiche entweder nutzbar oder bewusst ausgeblendet
+
+### Build-Checks
+
+- `npm run build` im Frontend
+- Android Web-Build mit `.env.android`
+- `npx cap sync android`
+- `./gradlew assembleDebug`
+- `./gradlew lint`
+- Release-Build mit Signing-Konfiguration
+
+## Verbleibende offene Punkte
+
+- Produktivdomain final technisch testen: voraussichtlich `https://www.your-part.de`.
+- Daemon-WebSocket-URL und Pfad final gegen Deploy-/Proxy-Konfiguration testen.
+- Mindest-Android-Version aus Capacitor-Default uebernehmen und nach erstem Scaffold im Gradle-Projekt dokumentieren.
+- Play-Store-Entscheidung bleibt nachgelagert bis Compliance-Pruefung abgeschlossen ist.
+
+## TODO
+
+### 1. Grundsatzentscheidungen
+
+- [x] App-ID festlegen: `de.yourpart.app`.
+- [x] App-Name und Launcher-Label festlegen: `YourPart`.
+- [x] Ziel-Distribution festlegen: zuerst interne Debug-/Test-APK.
+- [x] Entscheiden, ob Admin-Routen in der App sichtbar bleiben: nicht priorisiert, nicht aktiv entfernt.
+- [x] Entscheiden, wie Adult-/Erotikbereiche in Android behandelt werden: bestehendes Web-Gating, kein Play Store ohne Compliance-Check.
+- [x] Entscheiden, ob Backend Teil des Android-Starts ist: nein, nur Kompatibilitaetstests.
+- [x] Entscheiden, ob Push Teil des ersten Scaffolds ist: nein.
+- [x] Entscheiden, ob OAuth erster Blocker ist: nein, Username/Passwort-Login zuerst.
+
+### 2. Android-Projekt scaffolden
+
+- [x] In `/android` eigenes `package.json` anlegen.
+- [x] Capacitor installieren: `@capacitor/core`, `@capacitor/cli`, `@capacitor/android`.
+- [x] `capacitor.config.ts` mit App-ID `de.yourpart.app`, App-Name `YourPart` und `webDir` auf `../frontend/dist` konfigurieren.
+- [x] Android-Plattform generieren: `npx cap add android`.
+- [x] `/android/README.md` mit Build-Kommandos anlegen.
+- [x] Entscheiden, ob generiertes `/android/android` versioniert wird: ja.
+
+### 3. Frontend Android-Build
+
+- [x] `frontend/.env.android.example` anlegen.
+- [x] `VITE_API_BASE_URL` fuer Android explizit setzen.
+- [x] `VITE_SOCKET_IO_URL` fuer Android explizit setzen.
+- [x] `VITE_DAEMON_SOCKET` fuer Android explizit setzen.
+- [x] Root- oder Android-Script fuer `build:android:web` ergaenzen.
+- [x] Android-Web-Build mit produktiver Origin statt lokaler Dev-URL bauen.
+- [ ] Release-Build-Gate ergaenzen, das lokale Dev-URLs automatisiert verhindert.
+
+### 4. Backend-Kompatibilitaet
+
+- [ ] Android-Origin im CORS-Verhalten messen.
+- [x] Fehlerhafte Android-Request-Basis `/api/api` identifizieren und durch Origin-only-Config beheben.
+- [x] Capacitor-Hostname-Kollision mit Backend-Host vermeiden; `server.hostname` bleibt Default.
+- [x] `CORS_ORIGINS` fuer Capacitor als bestehenden Backend-Konfigurationspunkt notieren: `https://localhost`.
+- [ ] Produktiv-/Testbackend mit `CORS_ORIGINS` inklusive `https://localhost` neu starten und Android-Requests erneut pruefen.
+- [ ] Custom Header `userid`/`authcode` auf Android testen.
+- [ ] Socket.IO-Verbindung von Android testen.
+- [ ] Daemon-WebSocket ueber Android testen.
+- [ ] Produktionsproxy fuer HTTPS/WSS pruefen.
+- [ ] Keine Backend-Aenderung ohne konkreten fehlgeschlagenen Android-Test einplanen.
+
+### 5. Auth und OAuth
+
+- [ ] Username/Passwort-Login in Android testen.
+- [ ] Persistenz nach App-Neustart testen.
+- [ ] Logout inklusive Socket-Cleanup testen.
+- [ ] OAuth-Login-Flow je Provider testen.
+- [ ] Entscheiden: OAuth per externem Browser plus App Links oder innerhalb bestehender WebView.
+- [ ] Android App Links einrichten, falls OAuth nativ zurueck in die App fuehren soll.
+- [ ] Authdaten spaeter in Secure Storage migrieren.
+
+### 6. Native App-Verhalten
+
+- [ ] Android Back Button behandeln.
+- [ ] Splash Screen konfigurieren.
+- [ ] App Icons erzeugen.
+- [ ] Statusbar/Safe-Area pruefen; aktueller Test zeigt nicht-blockierende Safe-Area-CSS-Console-Fehler.
+- [x] WebView-Textfeld-Eingabe fuer Emulator reparieren: `android.captureInput` nicht aktivieren.
+- [x] Android-Studio-Projektpfad dokumentieren: `/android/android`.
+- [x] Android-Studio-Run-Configuration `YourPart Debug` anlegen.
+- [ ] Deep-Link-Handling vorbereiten.
+- [ ] App Resume/Pause Events fuer Socket-Reconnect nutzen.
+
+### 7. Mobile UI-Haertung
+
+- [ ] Login/Register auf 360px Breite testen.
+- [x] Login-Screen im Emulator visuell pruefen.
+- [x] Parameterlisten-Handling gegen Nicht-Array-Antworten haerten, damit Backend-Fehler keine UI-Exception ausloesen.
+- [x] 3D-Modelle fuer Android-Debug per `VITE_DISABLE_3D=true` deaktivieren, damit Login/Onboarding stabil bleibt.
+- [x] Hauptnavigation fuer kleine Viewports umbauen: kompakte Menueleiste plus scrollbares Menue statt voller Desktop-Navigation.
+- [ ] Hauptnavigation mobil mit mehreren Rollen/Berechtigungssets testen.
+- [ ] Dialoge auf kleinen Screens pruefen.
+- [ ] Falukant-Views mit breiten Tabellen pruefen.
+- [ ] Vokabeltrainer Touch- und Keyboard-Verhalten testen.
+- [ ] Minigames separat auf Touch-Performance testen.
+- [ ] Bild-/Dateiupload auf Android pruefen.
+
+### 8. Push Notifications
+
+- [ ] Entscheiden, ob Push in Phase 1 oder spaeter kommt.
+- [ ] Event-Kandidaten definieren: Chat, Friend Login, Falukant, Vocab Reminder.
+- [ ] Backend-Device-Token-Modell planen.
+- [ ] FCM-Projekt konfigurieren.
+- [ ] Opt-in und Settings-UI planen.
+
+### 9. Store/Compliance
+
+- [ ] Datenschutzseite in App erreichbar machen.
+- [ ] Impressum in App erreichbar machen.
+- [ ] Account-Loeschung/Anfrageprozess klaeren.
+- [ ] Adult Content Policy pruefen.
+- [ ] UGC-Moderation fuer Store Review dokumentieren.
+- [ ] Release-Build ohne Debug-Konfiguration pruefen.
+
+### 10. CI/CD
+
+- [x] Android-Build-Script anlegen.
+- [x] Debug-Build lokal reproduzierbar machen.
+- [ ] Release-Signing-Konzept festlegen.
+- [ ] Keystore sicher ausserhalb des Repos verwalten.
+- [ ] Optional CI-Job fuer `frontend build` + `cap sync` + Gradle Build einrichten.
+
+## Empfohlene erste Umsetzungsschritte
+
+1. `/android` als Capacitor-Projekt initialisieren.
+2. `frontend/.env.android.example` und Android-Build-Script anlegen.
+3. Debug-APK mit produktiver Test-API bauen.
+4. Login, Menu, Falukant Overview und Socket.IO testen.
+5. Erst danach OAuth, Deep Links und Push angehen.
+
+## Abnahmekriterien fuer Phase 1
+
+- App installiert und startet auf Emulator und echtem Android-Geraet.
+- Login/Logout funktionieren.
+- Persistierter Login funktioniert nach App-Neustart.
+- API-Requests senden `userid` und `authcode` korrekt.
+- Socket.IO verbindet nach Login und reconnectet nach Resume.
+- Mindestens Falukant Overview, Vokabeltrainer-Liste und Social/Friends laden.
+- Android Back Button fuehrt nicht zu kaputten Zustanden.
+- Build ist reproduzierbar dokumentiert.
+
+Aktueller Stand:
+
+- Android/Capacitor-Projekt ist erzeugt.
+- Android-Web-Build ist erfolgreich.
+- Capacitor Sync ist erfolgreich.
+- Debug-APK-Build ist erfolgreich.
+- Installation und Laufzeittests auf Emulator/Geraet stehen noch aus.