bollwerkadmin/bollwerk
1
0
Fork 0
Code Issues 12 Pull requests Projects Releases Packages Wiki Activity Actions

Self-Update: App prüft neue Version und installiert APK selbst #69

New issue
Closed
opened 2026-05-16 23:10:42 +00:00 by jreinemann-euris · 1 comment
jreinemann-euris commented 2026-05-16 23:10:42 +00:00 (Migrated from github.com)
Copy link

Ziel

Die App soll beim Start selbstst?ndig pr?fen, ob eine neue Version auf dem eigenen Server verf?gbar ist ? und die Installation ohne externen App-Store ansto?en.

Arbeitspakete

Server

  • GET /api/version ? { versionCode: Int, versionName: String, apkUrl: String }
  • APK als statische Ressource unter /static/app-latest.apk ausliefern (Ktor staticFiles)
  • Homepage (GET /) liefert eine HTML-Seite mit QR-Code, der auf /static/app-latest.apk zeigt (direkte APK-Installation per Scan)
  • /admin bleibt weiterhin erreichbar (keine ?nderung an der Admin-Route)

App

  • Permission REQUEST_INSTALL_PACKAGES im Manifest
  • FileProvider konfigurieren (damit die heruntergeladene APK als URI geteilt werden darf)
  • UpdateCheckUseCase: GET /api/version, BuildConfig.VERSION_CODE vergleichen
  • UpdateRepository: APK via OkHttp in context.cacheDir/update.apk laden (mit Progress)
  • UpdateDialog (Composable): Banner wenn Update verf?gbar, Button ?Jetzt aktualisieren"
  • Intent(Intent.ACTION_INSTALL_PACKAGE) mit FileProvider-URI feuern
  • Pr?fung beim App-Start (in MainActivity oder Top-Level-ViewModel)

Akzeptanzkriterien

  • App zeigt nach Start einen nicht-blockierenden Banner, wenn versionCode auf dem Server > lokaler VERSION_CODE
  • Tap auf ?Jetzt aktualisieren? l?dt die APK herunter und ?ffnet den Android-Installer
  • Nutzer muss einmalig ?Installieren aus dieser Quelle erlauben? best?tigen (Android 8+)
  • Kein Update-Check wenn keine Server-URL konfiguriert ist (opt-in)
  • Server-Homepage (/) zeigt einen QR-Code, der auf die APK-Download-URL zeigt
  • /admin bleibt unter derselben URL erreichbar

Technische Hinweise

  • FileProvider-Authority: de.krisenvorrat.app.fileprovider
  • Download-Pfad: context.cacheDir/update/app-latest.apk
  • APK muss mit demselben Signing-Key signiert sein wie die installierte Version (sonst bricht Android die Installation ab)
  • QR-Code auf der Homepage kann serverseitig generiert werden (z. B. Ktor + io.nayuki:qrcodegen) oder als clientseitiges JS (z. B. qrcode.js via CDN)
  • APK-Download-URL f?r den QR-Code: https://<server-host>/static/app-latest.apk
## Ziel Die App soll beim Start selbstst?ndig pr?fen, ob eine neue Version auf dem eigenen Server verf?gbar ist ? und die Installation ohne externen App-Store ansto?en. ## Arbeitspakete ### Server - [ ] `GET /api/version` ? `{ versionCode: Int, versionName: String, apkUrl: String }` - [ ] APK als statische Ressource unter `/static/app-latest.apk` ausliefern (Ktor `staticFiles`) - [ ] Homepage (`GET /`) liefert eine HTML-Seite mit QR-Code, der auf `/static/app-latest.apk` zeigt (direkte APK-Installation per Scan) - [ ] `/admin` bleibt weiterhin erreichbar (keine ?nderung an der Admin-Route) ### App - [ ] `Permission REQUEST_INSTALL_PACKAGES` im Manifest - [ ] `FileProvider` konfigurieren (damit die heruntergeladene APK als URI geteilt werden darf) - [ ] `UpdateCheckUseCase`: `GET /api/version`, `BuildConfig.VERSION_CODE` vergleichen - [ ] `UpdateRepository`: APK via `OkHttp` in `context.cacheDir/update.apk` laden (mit Progress) - [ ] `UpdateDialog` (Composable): Banner wenn Update verf?gbar, Button ?Jetzt aktualisieren" - [ ] `Intent(Intent.ACTION_INSTALL_PACKAGE)` mit FileProvider-URI feuern - [ ] Pr?fung beim App-Start (in `MainActivity` oder Top-Level-ViewModel) ## Akzeptanzkriterien - App zeigt nach Start einen nicht-blockierenden Banner, wenn `versionCode` auf dem Server > lokaler `VERSION_CODE` - Tap auf ?Jetzt aktualisieren? l?dt die APK herunter und ?ffnet den Android-Installer - Nutzer muss einmalig ?Installieren aus dieser Quelle erlauben? best?tigen (Android 8+) - Kein Update-Check wenn keine Server-URL konfiguriert ist (opt-in) - Server-Homepage (`/`) zeigt einen QR-Code, der auf die APK-Download-URL zeigt - `/admin` bleibt unter derselben URL erreichbar ## Technische Hinweise - `FileProvider`-Authority: `de.krisenvorrat.app.fileprovider` - Download-Pfad: `context.cacheDir/update/app-latest.apk` - APK muss mit demselben Signing-Key signiert sein wie die installierte Version (sonst bricht Android die Installation ab) - QR-Code auf der Homepage kann serverseitig generiert werden (z. B. Ktor + `io.nayuki:qrcodegen`) oder als clientseitiges JS (z. B. `qrcode.js` via CDN) - APK-Download-URL f?r den QR-Code: `https://<server-host>/static/app-latest.apk`
jreinemann-euris commented 2026-05-17 00:23:31 +00:00 (Migrated from github.com)
Copy link

Planung abgeschlossen

Dieses Planungsticket wurde in 3 Arbeitspakete zerlegt:

Sub-Tickets

  1. #83 [F] Self-Update Server: Version-Endpoint, APK-Hosting & Homepage mit QR-Code (Order: 1160)
  2. #84 [F] Self-Update App: Update-Check & APK-Download (Data/Domain-Layer) (Order: 1170)
  3. #85 [F] Self-Update App: Update-Dialog, Installation & App-Start-Integration (Order: 1180)

Implementierungsreihenfolge

  1. Server zuerst (#83): Version-Endpoint und APK-Hosting bereitstellen
  2. App Data-Layer (#84): Update-Check und Download-Logik implementieren
  3. App UI-Layer (#85): Banner, Download-Progress und Installations-Intent

Architektur-Überblick

  • Server: Öffentlicher GET /api/version Endpoint, statische APK aus server/data/, Homepage mit QR-Code (clientseitiges JS)
  • App: UpdateRepository + CheckForUpdateUseCase im Domain-Layer, UpdateViewModel + UpdateBanner im UI-Layer
  • FileProvider für APK-URI, REQUEST_INSTALL_PACKAGES Permission
  • Kein Update-Check ohne konfigurierte Server-URL (opt-in)
## Planung abgeschlossen Dieses Planungsticket wurde in 3 Arbeitspakete zerlegt: ### Sub-Tickets 1. **#83** [F] Self-Update Server: Version-Endpoint, APK-Hosting & Homepage mit QR-Code (Order: 1160) 2. **#84** [F] Self-Update App: Update-Check & APK-Download (Data/Domain-Layer) (Order: 1170) 3. **#85** [F] Self-Update App: Update-Dialog, Installation & App-Start-Integration (Order: 1180) ### Implementierungsreihenfolge 1. Server zuerst (#83): Version-Endpoint und APK-Hosting bereitstellen 2. App Data-Layer (#84): Update-Check und Download-Logik implementieren 3. App UI-Layer (#85): Banner, Download-Progress und Installations-Intent ### Architektur-Überblick - Server: Öffentlicher `GET /api/version` Endpoint, statische APK aus `server/data/`, Homepage mit QR-Code (clientseitiges JS) - App: `UpdateRepository` + `CheckForUpdateUseCase` im Domain-Layer, `UpdateViewModel` + `UpdateBanner` im UI-Layer - FileProvider für APK-URI, `REQUEST_INSTALL_PACKAGES` Permission - Kein Update-Check ohne konfigurierte Server-URL (opt-in)
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
No results found.
Labels
Clear labels   
block-planning

   
bug

Something isn't working

  
documentation

Improvements or additions to documentation

  
duplicate

This issue or pull request already exists

  
enhancement

New feature or request

  
feature

   
good first issue

Good for newcomers

  
help wanted

Extra attention is needed

  
infrastructure

   
invalid

This doesn't seem right

  
planning

   
priority:high

   
priority:low

   
question

Further information is requested

  
refactoring

   
status:backlog

Im Backlog

  
status:done

Abgeschlossen

  
status:in-progress

Aktuell in Bearbeitung

  
status:todo

Naechstes Todo-Ticket

  
tech-decision

   
test

   
wontfix

This will not be worked on

No labels
block-planning
bug
documentation
duplicate
enhancement
feature
good first issue
help wanted
infrastructure
invalid
planning
priority:high
priority:low
question
refactoring
status:backlog
status:done
status:in-progress
status:todo
tech-decision
test
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: bollwerkadmin/bollwerk#69
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?