Kurzüberblick
Fügen Sie GitHub Actions einen datensparsamen Registrierungscheck hinzu, ohne den Google-API-Schlüssel offenzulegen.
Zielgruppe: Teams, die Android-Build, Signierung und Release mit GitHub Actions automatisieren.
Release-Ablauf
- Ermitteln Sie die Produktions-Application-ID aus der Release-Variante.
- Lesen Sie den öffentlichen SHA-256-Fingerabdruck aus dem signierten Artefakt.
- Rufen Sie die offizielle Status API aus einem geschützten Job oder Team-Endpunkt auf.
- Stoppen Sie die Promotion bei offenem oder abweichendem Status und definieren Sie manuelle Ausnahmen.
Eckdaten
Das Beispiel prüft nur den Paketnamen. Ergänzen Sie certificateFingerprint mit dem SHA-256 der Produktions-APK, wenn auch die Signatur zählen soll. Geben Sie API-Schlüssel, Keystore-Passwort und privaten Signaturschlüssel nie in Actions-Logs aus.
Ausführliche Anleitung
Job als Release-Schranke
Prüfen Sie nach dem Signieren der Release-APK und vor der Store-Promotion. Speichern Sie den Google-API-Schlüssel in GitHub Actions Secrets, beschränken Sie ihn auf die Android Developer ID Status API und vermeiden Sie Pull-Request-Kontexte mit nicht vertrauenswürdigem Code.
Das Beispiel ist ein minimaler Paketcheck. Ergänzen Sie für den Signaturabgleich den certificateFingerprint des Produktionsartefakts. Werten Sie state mit jq aus; stabile offene Status stoppen sofort, vorübergehende API-Fehler erhalten nur begrenztes Backoff.
- API-Schlüssel nie ausgeben.
- Drittanbieter-Actions im Release-Job an eine Version binden.
- certificateFingerprint für die Produktionssignatur ergänzen.
- name: Check Android registration
env:
API_KEY: ${{ secrets.ANDROID_DEVELOPER_ID_API_KEY }}
PACKAGE_NAME: com.example.app
run: |
curl --fail --silent --show-error \
-H "X-Goog-Api-Key: $API_KEY" \
"https://androiddeveloperidstatus.googleapis.com/v1/packages/$PACKAGE_NAME/packageRegistrationStatus:check" \
| tee status.json
test "$(jq -r .state status.json)" = "REGISTERED"Geben Sie den Produktionspaketnamen ein. Für den Signaturabgleich ergänzen Sie das SHA-256-Zertifikat der tatsächlich ausgelieferten APK. Store-Prüfungen bleiben ein eigener Schritt.
Status prüfen →Häufige Fragen
Soll CI den Browser-Endpunkt von PkgReady aufrufen?
Nein. CI sollte die offizielle Server-zu-Server-API mit einem geschützten Schlüssel Ihrer Organisation verwenden.
Welcher Status soll den Release stoppen?
NOT_REGISTERED und Zertifikatskonflikte stoppen die Freigabe. Quoten- und Dienstfehler sind Infrastrukturfehler und erhalten nur begrenzte Wiederholungen.
Quellen und Prüfung
Zuletzt geprüft: