FoodBridge App

Native Android-Einkaufslisten-App (Kotlin/Compose) im Bring!-Stil, direkt auf der Grocy-Einkaufsliste: Kacheln nach Kategorie, Ein-Tipp-Abhaken, Autocomplete aus den vorhandenen Produkten, Barcode-Scan, offline-fähig. Das Backend (Sync-Container + Shopping-API) liefert das separate Repo food-bridge.

Installation über Obtainium

Die App wird als signiertes APK über die Forgejo-Releases dieses Repos verteilt — am bequemsten mit Obtainium, das die App installiert und Updates automatisch anbietet:

1. Obtainium installieren (F-Droid oder GitHub)

2. In Obtainium: App hinzufügen → Quelle „Direkter APK-Link" (custom URL)

3. Diese URL eintragen:

   https://git.weick.io/dennis/foodbridge-app/releases/download/stable/FoodBridge.apk
   

4. Hinzufügen → Installieren — fertig.

Obtainium liest die Versionsnummer aus dem APK selbst und meldet sich automatisch, sobald unter derselben URL eine neuere Version liegt. Das funktioniert, weil die CI das rollierende stable-Release bei jedem Release mit einem festen Asset-Namen neu befüllt (siehe unten).

Voraussetzung: Das Repo ist öffentlich lesbar, damit Obtainium ohne Anmeldung herunterladen kann.

Release-Kanäle in Obtainium

Die Pipeline veröffentlicht drei Kanäle — pro Kanal ein eigener Obtainium-Eintrag:

Kanal	Obtainium-Quelle	Konfiguration
Stable	„Direkter APK-Link“	URL wie oben
Versionen	„Forgejo (Codeberg)“	Instanz git.weick.io, Repo dennis/foodbridge-app; Filter-Regex ^FoodBridge \d
Dev	„Forgejo (Codeberg)“	wie Versionen, zusätzlich „Vorabversionen einschließen“ an; Filter-Regex ^Dev

Der Filter greift auf den Release-Titel: Versions-Releases heißen „FoodBridge x.y.z“, Dev-Releases „Dev FoodBridge x.y.z-dev.n“. Das rollierende „Stable (…)“-Release wird bei jedem Build neu erstellt und trägt damit immer das neueste Datum — ungefiltert würde es jeden Forgejo-Eintrag überdecken. Dev-Releases sind Prereleases; der Versions-Kanal („Vorabversionen einschließen“ aus, Obtainium-Standard) filtert sie damit doppelt sicher aus.

Migration vom Debug-Build

Wer bisher die handgebaute Debug-APK installiert hat: einmal deinstallieren, dann über Obtainium neu installieren. Die Release-Signatur unterscheidet sich zwingend vom Debug-Build — ein direktes Update ist nicht möglich. Einkaufslisten und Produkte liegen serverseitig; nur die Onboarding-Eingabe (Server-URL + Zugangscode) ist einmalig neu.

Manuelle Installation (ohne Obtainium)

APK aus den Releases herunterladen und öffnen — Android fragt einmal nach „Aus unbekannten Quellen installieren".

Erste Einrichtung

Beim ersten Start fragt die App:

• Server-Adresse: die foodbridge-URL, z. B. http(s)://<foodbridge-host>:8080
• Zugangscode: der APP_TOKEN aus der Server-Konfiguration (Details im food-bridge-README)

Bauen

• Voraussetzungen: JDK 21 und Android-SDK — oder Android Studio
• ./gradlew assembleDebug → Debug-APK unter app/build/outputs/apk/debug/
• ./gradlew assembleRelease → signiertes Release-APK unter app/build/outputs/apk/release/ (signiert mit dem lokalen Keystore, siehe unten)

Releases

Ein Release ist ein Tag-Push, mehr nicht:

git tag v0.2.0
git push origin v0.2.0

Die Forgejo-Actions-Pipeline (.forgejo/workflows/release.yml) baut dann das signierte APK und veröffentlicht beides:

• Release v0.2.0 mit Asset FoodBridge-0.2.0.apk
• das rollierende stable-Release mit festem Asset-Namen FoodBridge.apk — die permanente Download-URL, die Obtainium verfolgt

versionName kommt aus dem Tag (v0.2.0 → 0.2.0), versionCode wird daraus als major*1.000.000 + minor*10.000 + patch*100 berechnet. Deshalb: Versionen immer als v<maj>.<min>.<patch> taggen.

Dev-Builds bekommen eigene Tags mit Dev-Zähler: v0.2.0-dev.1, v0.2.0-dev.2, … (Zähler maximal 49). Die Pipeline veröffentlicht daraus ein Prerelease „Dev FoodBridge 0.2.0-dev.1“ (Obtainium-Dev-Kanal); das stable-Release und die Versions-Releases bleiben unberührt. Der Dev-Zähler (+50+N) hebt den Dev-Build im versionCode über seinem zukünftigen Stable (0.2.0 → +0) und unter der nächsten Patch-Version (0.2.1 → +100) — Updates funktionieren in beide Richtungen.

Signierung (wichtig!)

Der Release-Keystore liegt unter keystore/ und ist nicht im Repo (gitignored):

• keystore/foodbridge-release.jks — der Schlüssel
• keystore/keystore.properties — Passwörter und Alias
• keystore/FORGEJO-SECRETS.md — dieselben Werte als CI-Secrets (KEYSTORE_BASE64, KEYSTORE_PASSWORD, KEY_ALIAS, KEY_PASSWORD)

Ohne Backup des Keystores können später keine Updates über eine bestehende Installation verteilt werden — Android lehnt APKs mit anderer Signatur ab. Der komplette Ordner gehört daher an einen sicheren Ort kopiert.

CI liest die Signaturdaten aus den Repo-Secrets. Fehlen sie, fällt der Release- Build auf Debug-Signierung zurück (Build läuft trotzdem durch) — solche APKs sind nur fürs lokale Ausprobieren.

CI auf arm64-Hosts

Google baut den aapt2 (genau wie aidl/zipalign) nur für x86_64-Linux. Auf arm64-Runnern — hier: Forgejo-Runner auf der arm64-Maschine — stellt der Workflow deshalb einen arm64-aapt2 von Commit451/android-arm-build-tools bereit (aus offiziellen AOSP-Tags gebaut, Checksumme im Workflow fixiert) und leitet AGP per android.aapt2FromMavenOverride darauf um. Auf x86_64-Runnern entfällt dieser Schritt automatisch.

Pipelines (Forgejo Actions)

• CI (.forgejo/workflows/ci.yml): bei jedem Push / jeder PR — Unit-Tests (./gradlew test) und Android-Lint (./gradlew lint) im Container eclipse-temurin:21-jdk, Speicher-Limits wie beim Release-Build.
• Release (.forgejo/workflows/release.yml): bei Push eines Tags v* — baut das signierte APK und veröffentlicht je nach Tag das Versions-Release plus rollierendes stable-Release (Obtainium-URL) oder, bei -dev.N-Tags, ein Dev-Prerelease (stable bleibt unberührt). Dafür müssen in den Repo-Settings vier Secrets liegen: KEYSTORE_BASE64, KEYSTORE_PASSWORD, KEY_ALIAS, KEY_PASSWORD (Werte: keystore/FORGEJO-SECRETS.md).

Beide Workflows holen den Source per Tarball über die Forgejo-API — der Runner klont den Workspace nicht automatisch, und das JDK-Image bringt weder git noch node mit (ein actions/checkout würde dort scheitern).