storePassword "..." steht in build.gradle, der Release-Build-Typ ist noch mit signingConfigs.debug signiert, und targetSdk = 35 wird seit dem 31. August 2026 von Google Play für Smartphone-Apps nicht mehr akzeptiert. Dieser Skill findet diese und elf weitere Fehler im Release-Build in Ihren Gradle-Dateien, bevor Sie hochladen, und erklärt Ihnen, wie Sie jeden davon beheben.

Ihr Agent führt einen Scanner auf build.gradle- und build.gradle.kts-Dateien aus (App- und Bibliotheksmodule, die Root-Build-Datei, Settings-Dateien und gemeinsam genutzte Dateien wie variables.gradle von Capacitor), auf gradle.properties, local.properties, keystore.properties, key.properties und signing.properties, gradle/libs.versions.toml, R8-Regeldateien (proguard-rules.pro, consumer-rules.pro, keepRules/*.keep) und auf den Namen von Keystore-Dateien. Er überspringt Kommentare, folgt Gradle-Blöcken so, wie Gradle sie liest (buildTypes { release { } }, getByName("release"), named("release"), android.buildTypes.release...), liest Kotlin-DSL-Aufrufe, deren Argumente auf separaten Zeilen stehen, folgt einfachen Werten, die in derselben Datei definiert sind (enableProguardInReleaseBuilds von React Native, ext { targetSdkVersion = 33 }), unterscheidet Wear-OS-, TV-, Automotive- und XR-Module anhand ihrer Abhängigkeiten von Smartphone-Apps und lässt Signierdateien und Keystores aus, die von einer .gitignore erfasst werden. Er funktioniert mit Projekten in Android Studio, Flutter, React Native, Expo, Capacitor und Kotlin Multiplatform. Er führt nie Gradle oder Ihren Code aus. Das Ergebnis lautet BLOCK, REVIEW oder NOT FLAGGED, jeweils mit Datei, Zeile, Begründung und einem sichereren Vorgehen. Geheimnisse werden nie ausgegeben.

Was geprüft wird

BLOCK (vor der Auslieferung beheben)

• A01: storePassword oder keyPassword in einer Build-Datei eingetragen (auch als Fallback nach System.getenv, getOrElse oder orElse), Signierpasswörter in der gradle.properties des Projekts sowie keystore.properties-, key.properties-, signing.properties- oder local.properties-Dateien mit Passwörtern, die von keiner .gitignore ausgeschlossen werden
• A02: debuggable true oder isDebuggable = true im Release-Build-Typ
• A03: der Release-Build-Typ ist mit der Debug-Signierkonfiguration signiert, oder eine Release-Signierkonfiguration zeigt auf debug.keystore (außer es handelt sich um einen Vorlagen-Platzhalter oder das Projekt injiziert seinen Release-Schlüssel: siehe A18)
• A04: ein targetSdk, das Google Play nicht mehr akzeptiert: unter 34 überall, unter 35 in Modulen für Wear OS und Android Automotive OS, unter 36 in App-Modulen, deren Abhängigkeiten auf eine Smartphone- oder Tablet-App hinweisen
• A05: im Klartext eingetragene Geheimnisse, Tokens, Passwörter und API-Schlüssel in buildConfigField, resValue oder manifestPlaceholders (Schlüssel, die für die Auslieferung in Apps gedacht sind, etwa für Google Maps, veröffentlichbare Schlüssel und Schlüssel von Analyse-SDKs, werden nicht gemeldet)
• A06: .jks- oder .keystore-Dateien (oder base64-Kopien davon) im Projekt, die von keiner .gitignore ausgeschlossen werden

REVIEW (vor dem Release prüfen)

• A11: R8 für den Release-Build eines App-Moduls deaktiviert: minifyEnabled false, optimization { enable = false } oder ein Release-Block, der es nie einschaltet
• A12: targetSdk 34 oder 35, wo der Formfaktor nicht erkennbar ist (gemeinsamer ext-Block, variables.gradle, gradle.properties, Versionskatalog)
• A13: jniDebuggable true im Release-Build-Typ
• A14: ein Android-Gradle-Plugin älter als 8.5.1 (sofern der dokumentierte Workaround mit Legacy-Packaging nicht gesetzt ist) oder ein NDK älter als r27, nicht bereit für die 16-KB-Seitengrößen-Anforderung von Google Play
• A15: -dontobfuscate, -dontoptimize, -dontshrink oder Regeln, die alles behalten, in R8-Regeldateien, getDefaultProguardFile("proguard-android.txt") oder android.enableR8.fullMode=false
• A16: lint checkReleaseBuilds false
• A17: APK Signature Scheme v2 in einer Release-Signierkonfiguration ohne v3 abgeschaltet
• A18: die Debug-Signierkonfiguration im Release-Build-Typ als Platzhalter: Der TODO- oder Caution-Kommentar der Vorlage steht direkt darüber (Flutter, React Native, Expo), oder das Projekt injiziert seinen Release-Schlüssel über EAS Build oder android.injected.signing

Was enthalten ist

• Der Scanner (Python 3.9+, nur Standardbibliothek)
• Ein Regelleitfaden mit Begründung, sichererem Vorgehen und Link zur offiziellen Android-Dokumentation für jede Regel
• Ein riskantes und ein sicheres Beispielprojekt sowie der echte Bericht, den der Scanner für das riskante Projekt erzeugt

Grenzen

Der Scanner liest jede Datei so, wie sie geschrieben ist: Zur Build-Zeit gesetzte Werte, Katalog-Accessoren wie libs.versions.targetSdk, Convention-Plugins in buildSrc oder build-logic und flutter.targetSdkVersion werden nicht verfolgt, und Product Flavors, benutzerdefinierte Build-Typen und die Variant API werden nicht als Release-Build behandelt. Der Formfaktor wird nur aus den eigenen Abhängigkeiten eines Moduls ermittelt. AndroidManifest.xml und der Quellcode der App werden nicht gelesen. Eine Datei, die git bereits verfolgt, bleibt im Repository, auch nachdem sie zur .gitignore hinzugefügt wurde. Die Regeln zu Target SDK und 16 KB folgen den Anforderungen von Google Play mit Stand November 2026. Die Vorlagen von Flutter und React Native signieren Release-Builds mit dem Debug-Schlüssel; dies wird als A18 (REVIEW) gemeldet, weil ein Build, der keinen Release-Schlüssel von EAS Build, dem Assistenten Generate Signed Bundle von Android Studio oder Ihrer CI erhält, von Google Play abgelehnt wird. NOT FLAGGED ist keine Garantie.

Inhalt

Eine ZIP-Datei mit 27 Dateien: SKILL.md, der Scanner in scripts/ (7 Python-Dateien), references/rules.md (jede Regel mit Begründung und sichererem Vorgehen) und examples/ (17 Beispieldateien plus report.md, die echte Scanner-Ausgabe für das riskante Beispiel).

So verwenden Sie ihn: Dies ist ein Agent-Skill: ein Ordner mit einer SKILL.md-Datei und Python-Skripten, die ein KI-Coding-Agent wie Claude Code, Cursor oder Codex CLI ausführen kann. Entpacken Sie ihn in den Skills-Ordner Ihres Agenten (für Claude Code: ~/.claude/skills/) und bitten Sie Ihren Agenten dann, Ihr Projekt zu prüfen. Die Skripte laufen auch eigenständig mit Python 3.9 oder neuer, ohne dass etwas installiert werden muss. Sie lesen ausschließlich Ihre Dateien: kein Netzwerkzugriff, und nichts wird irgendwohin gesendet.