Der Release-Build lieferte bisher app-release-unsigned.apk - und die
installiert Android nicht, auch nicht per Sideload. Ohne Signatur kann das
System nicht feststellen, ob ein Update vom selben Absender stammt wie die
Erstinstallation; das ist unabhängig davon, woher die Datei kommt.
Der Build signiert jetzt. Liegt Android/keystore.properties vor, mit dem
eigenen Schlüssel; sonst wird aus der Umgebung gelesen, damit ein Bauknecht
sie aus seinen Geheimnissen setzen kann, ohne dass ein Passwort im Verlauf
landet. Fehlt beides, wird mit dem Debug-Schlüssel signiert - der Build
sagt das dann deutlich, denn eine so signierte Release-APK sieht sonst aus
wie eine richtige, lässt sich aber vom nächsten Rechner aus nicht mehr
aktualisieren. Schlüssel und Passwörter sind ausgeschlossen.
Version und Versionszähler lassen sich beim Bauen setzen, damit sie aus
einem Etikett kommen können.
Dazu ein Ablauf für Gitea Actions: ein Etikett hochschieben baut die APK,
legt das Release an, falls es noch nicht besteht, und hängt sie an. Beides
muss gehen - sonst scheitert es je nachdem, ob man das Release vorher von
Hand angelegt hat.
Android/RELEASE.md erklärt beide Wege und sagt auch, warum die APK nicht
ins Repository gehört: Release-Anhänge liegen in Gitea neben dem
Repository. Eine 11-MB-Binärdatei je Version im Verlauf wäre unwiderruflich
- Git vergisst nichts, ein späteres Löschen bringt den Platz nicht zurück.
Geprüft: die signierte APK installiert sich im Emulator, meldet sich mit
der übergebenen Version und trägt keine Debug-Kennzeichnung mehr.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Emulator hat kein Bluetooth. Damit sich die Ansichten trotzdem
ansehen und durchklicken lassen, füttert ein Demo-Modus fertige Werte
ein - dasselbe Vorgehen wie in der iOS-Fassung.
Nur in Debug-Bauten und nur, wenn beim Start das Extra gesetzt ist:
adb shell am start -n de.fritob.campermonitor/.MainActivity --ez demo true
Im Demo-Modus funkt nichts und es wird nichts abgelegt; die echten Geräte
und Fahrzeuge bleiben unberührt. Der Kühlbox-Zustand kommt dabei aus
einem echten Einzonen-Datensatz, wie ihn die Box im Fahrzeug schickt -
inklusive des Fühlerplatzhalters, damit die Anzeige auch im Demo zeigt,
was sie im Fahrzeug zeigen würde.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Damit steht der erste Teil vollständig: Protokoll, Funk und Ablage
übersetzen sich, die 50 Prüfungen laufen.
Die Funkschicht folgt der iOS-Fassung samt allem, was wir uns dort erst
erarbeiten mussten. Ein eigener Thread für alles, was Bluetooth anfasst;
Android ruft Scan- und GATT-Rückmeldungen auf Binder-Threads auf. Die
Wartesperre nach Fehlschlägen, die zwischen einem Abbruch einer stehenden
Verbindung und einem echten Fehlschlag unterscheidet. Stellbefehle, die
aufgehoben statt verworfen werden, wenn die Kühlbox gerade weg ist. Die
Zwanzig-Byte-Grenze beim Schreiben an die Kühlbox. Die stabile Reihenfolge
der Kandidaten, damit nicht der Zufall die Schreibart bestimmt.
Vier Dinge sind auf Android anders und im Quelltext vermerkt:
Die Herstellerdaten kommen ohne die zwei Bytes der Company-ID - die steht
im Schlüssel der Tabelle. Sie werden wieder davorgesetzt, damit derselbe
Rahmen ankommt wie unter iOS und dieselben Prüfungen gelten.
Notify muss über einen Deskriptor eingeschaltet werden; das Einschalten auf
unserer Seite allein genügt nicht.
Geräte werden über ihre MAC-Adresse angesprochen statt über eine
systemvergebene Kennung - iOS gibt die Adresse gar nicht heraus.
Die Victron-Schlüssel liegen in app-privater Ablage statt im
Schlüsselbund. Das schützt gegen andere Apps, ist aber nicht
hardwaregestützt. Ohne zusätzliche Bibliothek gibt es unter Android kein
gleichwertiges Gegenstück.
Als Nächstes die Oberfläche.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
