Gitea: warum die APK abgelehnt wird, und zwei Auswege

Die Instanz gefragt statt geraten. Ihre Liste erlaubter Dateitypen für
Anhänge enthält .apk nicht - daran scheitert das Hochladen. An der Grösse
liegt es nicht, die Grenze steht bei 100 MiB und die APK bei 11.

Der Quelltext als zip und tar.gz ist etwas anderes: den hängt Gitea an jedes
Release automatisch, erzeugt aus dem Etikett. Das ist nichts Hochgeladenes
und lässt sich auch nicht abschalten.

RELEASE.md nennt jetzt beides und zwei Wege. Der richtige ist eine Zeile in
der app.ini, die .apk erlaubt - für Release-Anhänge sind je nach Fassung
[attachment] oder [repository.release] zuständig, deshalb beide.

Ohne Serverzugriff hilft die Paket-Registry: die nimmt beliebige Dateien
ohne Typenliste und ist auf dieser Instanz eingeschaltet. Dafür ein Skript,
das den Zugangsschlüssel aus einer Datei liest und nirgends ausgibt, und
das die üblichen Fehlschläge benennt statt nur einen Statuscode zu zeigen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Android/RELEASE.md

@@ -52,6 +52,61 @@ keyPassword=DEIN_PASSWORT
 > die App installiert haben, nie wieder ein Update ausliefern. Eine Kopie an
 > einen zweiten Ort, getrennt vom Rechner.
 
+## Wenn Gitea die APK nicht annimmt
+
+Zwei Dinge, die leicht zusammenfallen:
+
+**Der Quelltext als `.zip` und `.tar.gz`** hängt an *jedem* Gitea-Release
+automatisch dran. Gitea erzeugt beides aus dem Etikett; es ist nichts, was
+versehentlich hochgeladen wurde, und es lässt sich auch nicht abschalten. Es
+stört nur optisch und kostet keinen Speicher — die Archive werden erst beim
+Anklicken erzeugt.
+
+**Die APK abgelehnt** wird dagegen aus einem handfesten Grund: Gitea nimmt nur
+Dateitypen an, die in seiner Liste stehen, und `.apk` steht dort nicht. Die
+Liste dieser Instanz lässt sich abfragen:
+
+```bash
+curl -s https://git.home.fritob.de/api/v1/settings/attachment
+```
+
+Kommt dort eine `allowed_types`-Liste ohne `.apk` zurück, ist das die Ursache.
+Die Grösse ist es nicht — die Grenze liegt bei 100 MiB, die APK bei 11.
+
+### Der richtige Weg: `.apk` erlauben
+
+In der `app.ini` des Servers (bei Docker meist
+`/data/gitea/conf/app.ini`, sonst `/etc/gitea/app.ini`):
+
+```ini
+[attachment]
+ALLOWED_TYPES = .avif,.cpuprofile,.csv,.dmp,.docx,.fodg,.fodp,.fods,.fodt,.gif,.gz,.jpeg,.jpg,.json,.jsonc,.log,.md,.mov,.mp4,.odf,.odg,.odp,.ods,.odt,.patch,.pdf,.png,.pptx,.svg,.tgz,.txt,.webm,.webp,.xls,.xlsx,.zip,.apk
+
+[repository.release]
+ALLOWED_TYPES = .apk,.zip
+```
+
+Beide Abschnitte, weil je nach Gitea-Fassung mal der eine, mal der andere für
+Release-Anhänge zuständig ist. Danach Gitea neu starten.
+
+Wer es sich einfach machen will, schreibt in beide Schlüssel `*/*` — dann ist
+alles erlaubt. Auf einer Instanz im eigenen Netz ist das vertretbar; öffentlich
+wäre es das nicht, weil dann auch beliebige ausführbare Dateien hochladbar sind.
+
+### Ohne Serverzugriff: die Paket-Registry
+
+Die nimmt beliebige Dateien an, ganz ohne Typenliste, und ist auf dieser
+Instanz eingeschaltet. Der Preis: Die Datei landet unter *Packages* statt am
+Release.
+
+```bash
+Android/upload-package.sh 1.0.0
+```
+
+Das Skript liest den Zugangsschlüssel aus `~/.gitea-token` und gibt ihn
+nirgends aus. Ein Token mit dem Recht `write:package` genügt; anzulegen unter
+*Einstellungen → Anwendungen → Zugriffstoken*.
+
 ## Von Hand veröffentlichen
 
 ```bash