forked from fritob/Camper-Monitor
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>
101 lines
3.8 KiB
Markdown
101 lines
3.8 KiB
Markdown
# 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.
|
|
|
|
```bash
|
|
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):
|
|
|
|
```properties
|
|
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
|
|
|
|
```bash
|
|
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.
|
|
|
|
```bash
|
|
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
|
|
|
|
1. **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.
|
|
2. **Actions eingeschaltet**, im Repository unter *Settings → Advanced*.
|
|
3. **Der Schlüssel als Geheimnis**, falls mit eigenem Schlüssel signiert werden
|
|
soll. Unter *Settings → Actions → Secrets* anlegen:
|
|
|
|
| Name | Inhalt |
|
|
| ------------------ | ------------------------------------------ |
|
|
| `KEYSTORE_BASE64` | `base64 -i ~/camper-monitor.jks \| pbcopy` |
|
|
| `KEYSTORE_PASSWORD`| das Passwort des Schlüsselspeichers |
|
|
| `KEY_ALIAS` | `camper` |
|
|
| `KEY_PASSWORD` | das Passwort des Schlüssels |
|
|
|
|
Fehlen sie, baut der Ablauf trotzdem — dann eben mit dem Debug-Schlüssel,
|
|
und die APK heisst entsprechend.
|