# 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.