BiasFandClaude Opus 5
3f37e6f047
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>
3.8 KiB
Eine APK veröffentlichen
Vorweg: die APK gehört nicht ins Repository
Ein Release-Anhang in Gitea liegt neben dem Repository, nicht darin. Gitea legt ihn in seinem Anhang-Speicher ab; im Git-Verlauf taucht er nicht auf.
Das ist auch gut so. Eine APK ist eine 11-MB-Binärdatei, die sich bei jedem Build komplett ändert. Läge sie im Repository, wüchse der Verlauf mit jeder Version um 11 MB — und zwar unwiderruflich: Git vergisst nichts, ein späteres Löschen bringt den Platz nicht zurück. Nach zehn Versionen wäre das Auschecken des Projekts ein 110-MB-Download, obwohl der Quelltext selbst nur wenige hundert Kilobyte hat.
Deshalb: bauen, an ein Release hängen, fertig. .gitignore sorgt dafür, dass
die gebauten Dateien gar nicht erst versehentlich hineinrutschen.
Signieren
Android installiert keine unsignierte APK — auch nicht per Sideload. Das hat nichts mit Googles Sperren zu tun, sondern damit, dass das System ohne Signatur nicht feststellen kann, ob ein Update vom selben Absender stammt wie die Erstinstallation.
Ohne eigenen Schlüssel signiert der Build mit dem Android-Debug-Schlüssel und sagt das beim Bauen deutlich. Das funktioniert, hat aber einen Haken: Dieser Schlüssel wird pro Rechner erzeugt. Baust du die nächste Version auf einem anderen Rechner, hat sie eine andere Signatur, und Android verweigert das Update — es bliebe nur Deinstallieren und neu einrichten.
Einen eigenen Schlüssel anlegen
Einmalig. Das Passwort tippst du dabei selbst.
keytool -genkeypair -v \
-keystore ~/camper-monitor.jks \
-alias camper -keyalg RSA -keysize 4096 -validity 10000
Danach Android/keystore.properties anlegen (die Datei ist in .gitignore,
sie landet nicht im Repository):
storeFile=/Users/DEINNAME/camper-monitor.jks
storePassword=DEIN_PASSWORT
keyAlias=camper
keyPassword=DEIN_PASSWORT
Diesen Schlüssel aufbewahren. Geht er verloren, lässt sich für alle, die die App installiert haben, nie wieder ein Update ausliefern. Eine Kopie an einen zweiten Ort, getrennt vom Rechner.
Von Hand veröffentlichen
source Android/env.sh
cd Android
./gradlew :app:assembleRelease -PversionName=1.0.0 -PversionCode=1
Die APK liegt dann unter
Android/app/build/outputs/apk/release/app-release.apk.
In Gitea: Releases → New Release, ein Etikett wie v1.0.0 wählen, und die
APK unter Attachments hochladen. Fertig — genau das ist das „Wie sage ich
Gitea, dass die APK dort hinein soll".
Von selbst veröffentlichen
.gitea/workflows/release.yml nimmt das ab: Ein Etikett hochschieben genügt.
git tag v1.0.0
git push origin v1.0.0
Der Ablauf baut die APK, legt das Release an, falls es noch nicht besteht, und hängt die Datei an. Die Versionsnummer kommt aus dem Etikett, der Versionszähler aus der Anzahl der Commits — so steigt er verlässlich.
Voraussetzungen
-
Ein Runner. Actions brauchen in Gitea einen registrierten Runner mit dem Etikett
ubuntu-latest. Unter Site Administration → Actions → Runners nachsehen. Ist keiner da, bleibt der Weg von Hand — der tut es genauso. -
Actions eingeschaltet, im Repository unter Settings → Advanced.
-
Der Schlüssel als Geheimnis, falls mit eigenem Schlüssel signiert werden soll. Unter Settings → Actions → Secrets anlegen:
Name Inhalt KEYSTORE_BASE64base64 -i ~/camper-monitor.jks | pbcopyKEYSTORE_PASSWORDdas Passwort des Schlüsselspeichers KEY_ALIAScamperKEY_PASSWORDdas Passwort des Schlüssels Fehlen sie, baut der Ablauf trotzdem — dann eben mit dem Debug-Schlüssel, und die APK heisst entsprechend.