yourpart3/android/ANDROID_APP_PLAN.md

# 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.