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:

/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:

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:

cd frontend
npm run build -- --mode android

Dafuer wird eine Datei frontend/.env.android benoetigt:

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.

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:

cd android
npx cap sync android

Danach:

cd android
npx cap open android

Oder per CLI:

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:

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

• App-ID festlegen: de.yourpart.app.
• App-Name und Launcher-Label festlegen: YourPart.
• Ziel-Distribution festlegen: zuerst interne Debug-/Test-APK.
• Entscheiden, ob Admin-Routen in der App sichtbar bleiben: nicht priorisiert, nicht aktiv entfernt.
• Entscheiden, wie Adult-/Erotikbereiche in Android behandelt werden: bestehendes Web-Gating, kein Play Store ohne Compliance-Check.
• Entscheiden, ob Backend Teil des Android-Starts ist: nein, nur Kompatibilitaetstests.
• Entscheiden, ob Push Teil des ersten Scaffolds ist: nein.
• Entscheiden, ob OAuth erster Blocker ist: nein, Username/Passwort-Login zuerst.

2. Android-Projekt scaffolden

• In /android eigenes package.json anlegen.
• Capacitor installieren: @capacitor/core, @capacitor/cli, @capacitor/android.
• capacitor.config.ts mit App-ID de.yourpart.app, App-Name YourPart und webDir auf ../frontend/dist konfigurieren.
• Android-Plattform generieren: npx cap add android.
• /android/README.md mit Build-Kommandos anlegen.
• Entscheiden, ob generiertes /android/android versioniert wird: ja.

3. Frontend Android-Build

• frontend/.env.android.example anlegen.
• VITE_API_BASE_URL fuer Android explizit setzen.
• VITE_SOCKET_IO_URL fuer Android explizit setzen.
• VITE_DAEMON_SOCKET fuer Android explizit setzen.
• Root- oder Android-Script fuer build:android:web ergaenzen.
• 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.
• Fehlerhafte Android-Request-Basis /api/api identifizieren und durch Origin-only-Config beheben.
• Capacitor-Hostname-Kollision mit Backend-Host vermeiden; server.hostname bleibt Default.
• 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.
• WebView-Textfeld-Eingabe fuer Emulator reparieren: android.captureInput nicht aktivieren.
• Android-Studio-Projektpfad dokumentieren: /android/android.
• 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.
• Login-Screen im Emulator visuell pruefen.
• Parameterlisten-Handling gegen Nicht-Array-Antworten haerten, damit Backend-Fehler keine UI-Exception ausloesen.
• 3D-Modelle fuer Android-Debug per VITE_DISABLE_3D=true deaktivieren, damit Login/Onboarding stabil bleibt.
• 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

• Android-Build-Script anlegen.
• 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.