QR Code Scanner (Kamera) funktioniert nicht #13

New issue

Open

opened 2026-09-01 22:11:35 +02:00 by erdbruegger · 1 comment

erdbruegger commented

2026-09-01 22:11:35 +02:00

Owner

Im Menü unter "Mehr", Fahrzeug hinzufügen, Scannen sehe ich nur den angehängten Screenshot (Kamera lädt nicht). Berechtigungen habe ich erteilt (bei Benutzung der App).

Außerdem: Der Menü-Punkt sollte meiner Meinung nach unter "Mehr>Profil>Fahrzeuge" erscheinen.

Und: Wenn man die App frisch installiert und noch keinen Benutzerkonto erstellt hat, wäre man in einer Sackgasse. Auf dem Login-Screen sollte es also auch möglich sein, mit einem Fahrzeug zu starten.

Im Menü unter "Mehr", Fahrzeug hinzufügen, Scannen sehe ich nur den angehängten Screenshot (Kamera lädt nicht). Berechtigungen habe ich erteilt (bei Benutzung der App). Außerdem: Der Menü-Punkt sollte meiner Meinung nach unter "Mehr>Profil>Fahrzeuge" erscheinen. Und: Wenn man die App frisch installiert und noch keinen Benutzerkonto erstellt hat, wäre man in einer Sackgasse. Auf dem Login-Screen sollte es also auch möglich sein, mit einem Fahrzeug zu starten.

Screenshot_20260901-220628.png

57 KiB

erdbruegger added the

claude

label

2026-09-01 22:11:35 +02:00

claudecode added the

in-progress

label

2026-09-01 22:20:48 +02:00

claudecode referenced this issue from a commit

2026-09-01 23:14:23 +02:00

release: QR-Scanner startet wieder, Fahrzeuge unter Profil, Einstieg ohne Konto (Issue #13)

claudecode commented

2026-09-01 23:25:03 +02:00

Collaborator

Alle drei Punkte sind drin — Release v1.0.55, CI + Deploy grün (analyze/gate/release/deploy-web), Web live unter http://192.168.1.85/, APKs hängen am Release.

1. Der schwarze Scanner

Das weiße Ausrufezeichen auf dem Screenshot ist das Default-Fehlerbild von mobile_scanner — die Kamera hat also gar nicht erst gestartet, und die Lib hat den Grund für sich behalten. Zwei Sachen dagegen:

Die wahrscheinliche Ursache: wir hingen auf mobile_scanner 5.2.3. Das Paket baut auf CameraX 1.3.3 / compileSdk 34 — mit unserem targetSdk 36 startet die Vorschau auf aktuellen Androids nicht mehr zuverlässig. Jetzt ^7.4.0 (CameraX 1.6.1, compileSdk 36). Genau dein Symptom, Freigabe erteilt und trotzdem schwarz, passt zu diesem Bruch.

Und, falls es trotzdem klemmt: der Scanner hat jetzt ein eigenes Fehlerbild statt des Ausrufezeichens. Es sagt im Klartext, was schiefging (Freigabe fehlt / keine nutzbare Kamera / sonst der echte Fehlercode), und bietet „Erneut versuchen" — das setzt Controller und Kamera-Session komplett neu auf, was nötig ist, wenn die Freigabe erst im Dialog erteilt wurde und die Plattform-Session noch am abgelehnten Zustand hängt. Dazu „Stattdessen Text einfügen" als Ausweg, ein Platzhalter während des Starts und ein türkiser Sucher-Rahmen.

Am Gerät testen kann ich das nicht — wenn es weiter nicht geht, schick mir bitte den Text, der jetzt auf dem Fehlerbild steht. Damit ist es eindeutig statt geraten.

2. Menü-Punkt an die richtige Stelle

„Fahrzeug hinzufügen" ist aus Mehr raus und sitzt unter Mehr › Profil › Fahrzeuge. „Fahrzeuge" war bisher nur eine Zeile mit einer Zahl — jetzt ist es eine echte Unterseite: die Fahrzeuge des Kontos, das aktive per Tipp auswählbar, Pull-to-refresh, und unten der Einstieg ins Provisionieren. Ein Regressionstest hält fest, dass der Punkt in „Mehr" nicht wieder auftaucht.

3. Keine Sackgasse ohne Konto

Auf dem Login-Screen steht jetzt „Mit Fahrzeug starten". Der Weg dahinter: Head-Unit-QR scannen → Backend-Adresse kommt aus dem QR (das war ja der eigentliche Knoten: ohne Konto kennt die App das Backend nicht) → App fragt /auth/config und zeigt je nach allowRegistration entweder Anmelden oder die Umschaltung „Konto anlegen" → danach direkt weiter ins „Fahrzeug hinzufügen", mit dem schon gescannten QR, also ohne zweites Scannen.

Zwei Annahmen, die ich dabei getroffen habe (sag Bescheid, wenn anders gewollt):

Auf unserem Live-Backend meldet /auth/config aktuell allowRegistration: false (2 Konten). Der Setup-Weg funktioniert trotzdem — er sagt dann ehrlich „Konten legt hier ein Admin an" und bietet nur Anmelden. Der Konto-anlegen-Zweig ist für ein frisch aufgesetztes Backend gedacht und schaltet sich bei leerem Backend von selbst vor.
Im Browser endet die Einrichtung nach dem Anmelden: Schlüssel aufspielen braucht den WLAN-Wechsel ins TBox-AP, das geht nur in der Handy-App. Steht als Hinweis da.

Verifikation

flutter analyze sauber, 118 Tests grün (4 neue: Smoke für die drei neuen Screens, plus die beiden Regressionstests zu Punkt 2 und 3), flutter build web ok, Android-Debug-APK baut lokal mit mobile_scanner 7.4.0. Nicht verifiziert ist die Kamera auf echter Hardware — das ist der Punkt, an dem ich Deine Rückmeldung brauche.

Kleinigkeit am Rande: android/.kotlin/ (Session-Cache von AGP 9) ist in die .gitignore gewandert, das war reiner Build-Müll im Status.

Alle drei Punkte sind drin — **Release `v1.0.55`**, CI + Deploy grün (analyze/gate/release/deploy-web), Web live unter http://192.168.1.85/, APKs hängen am Release. ## 1. Der schwarze Scanner Das weiße Ausrufezeichen auf dem Screenshot ist das Default-Fehlerbild von `mobile_scanner` — die Kamera hat also gar nicht erst gestartet, und die Lib hat den Grund für sich behalten. Zwei Sachen dagegen: **Die wahrscheinliche Ursache:** wir hingen auf `mobile_scanner 5.2.3`. Das Paket baut auf CameraX 1.3.3 / compileSdk 34 — mit unserem `targetSdk 36` startet die Vorschau auf aktuellen Androids nicht mehr zuverlässig. Jetzt `^7.4.0` (CameraX 1.6.1, compileSdk 36). Genau dein Symptom, Freigabe erteilt und trotzdem schwarz, passt zu diesem Bruch. **Und, falls es trotzdem klemmt:** der Scanner hat jetzt ein eigenes Fehlerbild statt des Ausrufezeichens. Es sagt im Klartext, *was* schiefging (Freigabe fehlt / keine nutzbare Kamera / sonst der echte Fehlercode), und bietet **„Erneut versuchen"** — das setzt Controller und Kamera-Session komplett neu auf, was nötig ist, wenn die Freigabe erst im Dialog erteilt wurde und die Plattform-Session noch am abgelehnten Zustand hängt. Dazu **„Stattdessen Text einfügen"** als Ausweg, ein Platzhalter während des Starts und ein türkiser Sucher-Rahmen. Am Gerät testen kann ich das nicht — wenn es weiter nicht geht, schick mir bitte den Text, der jetzt auf dem Fehlerbild steht. Damit ist es eindeutig statt geraten. ## 2. Menü-Punkt an die richtige Stelle „Fahrzeug hinzufügen" ist aus **Mehr** raus und sitzt unter **Mehr › Profil › Fahrzeuge**. „Fahrzeuge" war bisher nur eine Zeile mit einer Zahl — jetzt ist es eine echte Unterseite: die Fahrzeuge des Kontos, das aktive per Tipp auswählbar, Pull-to-refresh, und unten der Einstieg ins Provisionieren. Ein Regressionstest hält fest, dass der Punkt in „Mehr" nicht wieder auftaucht. ## 3. Keine Sackgasse ohne Konto Auf dem Login-Screen steht jetzt **„Mit Fahrzeug starten"**. Der Weg dahinter: Head-Unit-QR scannen → **Backend-Adresse kommt aus dem QR** (das war ja der eigentliche Knoten: ohne Konto kennt die App das Backend nicht) → App fragt `/auth/config` und zeigt je nach `allowRegistration` entweder Anmelden oder die Umschaltung „Konto anlegen" → danach direkt weiter ins „Fahrzeug hinzufügen", mit dem schon gescannten QR, also ohne zweites Scannen. Zwei Annahmen, die ich dabei getroffen habe (sag Bescheid, wenn anders gewollt): - Auf unserem Live-Backend meldet `/auth/config` aktuell `allowRegistration: false` (2 Konten). Der Setup-Weg funktioniert trotzdem — er sagt dann ehrlich „Konten legt hier ein Admin an" und bietet nur Anmelden. Der Konto-anlegen-Zweig ist für ein frisch aufgesetztes Backend gedacht und schaltet sich bei leerem Backend von selbst vor. - Im Browser endet die Einrichtung nach dem Anmelden: Schlüssel aufspielen braucht den WLAN-Wechsel ins TBox-AP, das geht nur in der Handy-App. Steht als Hinweis da. ## Verifikation `flutter analyze` sauber, **118 Tests grün** (4 neue: Smoke für die drei neuen Screens, plus die beiden Regressionstests zu Punkt 2 und 3), `flutter build web` ok, Android-Debug-APK baut lokal mit mobile_scanner 7.4.0. Nicht verifiziert ist die Kamera auf echter Hardware — das ist der Punkt, an dem ich Deine Rückmeldung brauche. Kleinigkeit am Rande: `android/.kotlin/` (Session-Cache von AGP 9) ist in die `.gitignore` gewandert, das war reiner Build-Müll im Status.

claudecode added

needs-review

and removed

in-progress

labels

2026-09-01 23:25:04 +02:00