Android App im Google Play Store veröffentlichen: Der komplette Guide für 2026

TL;DR – Die Kurzfassung

Sie wollen Ihre Android-App in den Google Play Store bringen? Hier die wichtigsten Fakten auf einen Blick:

Die gute Nachricht: Im Vergleich zum Apple App Store ist der Google Play Store schneller, günstiger und weniger restriktiv. Die schlechte: Android-Fragmentierung und Policy-Änderungen sorgen für eigene Herausforderungen.

Als App-Entwickler in Österreich haben wir bei exponent dutzende Apps im Play Store veröffentlicht. In diesem Guide teilen wir alles, was Sie für einen reibungslosen Launch wissen müssen.

---

1. Google Play Developer Account einrichten

Bevor Sie irgendetwas hochladen können, brauchen Sie einen Google Play Developer Account.

Kosten und Voraussetzungen

• Einmalige Gebühr: 25 $ (zum Vergleich: Apple verlangt 99 $/Jahr)
• Google-Konto: Sie benötigen ein Google-Konto — idealerweise ein dediziertes Unternehmenskonto, nicht Ihre private Gmail-Adresse
• Kontotyp: Wählen Sie „Organisation" statt „Privat", wenn Sie als Unternehmen auftreten

Identitätsverifizierung seit 2023

Google hat die Anforderungen an die Verifizierung schrittweise verschärft. Stand 2026 müssen alle neuen Developer Accounts folgendes nachweisen:

• Persönliche Identität: Ausweisdokument (Reisepass, Personalausweis) des Account-Inhabers
• Organisationsverifizierung: Für Unternehmenskonten zusätzlich D-U-N-S-Nummer oder gleichwertiger Nachweis der Geschäftstätigkeit
• Kontaktdaten: Verifizierte Telefonnummer und E-Mail-Adresse
• Physische Adresse: Unternehmenssitz muss angegeben werden

Praxis-Tipp: Rechnen Sie mit 1–3 Werktagen für die Verifizierung. Laden Sie scharfe, gut lesbare Scans Ihrer Dokumente hoch. Abgelehnte Verifizierungen verzögern Ihren Launch unnötig.

Account-Struktur für Unternehmen

Für österreichische KMUs empfehlen wir folgende Struktur:

• Ein Organisations-Account für alle Apps des Unternehmens
• Separate Google-Gruppen für verschiedene Rollen (Admin, Release Manager, Analyst)
• Kontaktdaten auf das Unternehmen, nicht auf eine Einzelperson registriert — so bleibt der Account auch bei Personalwechsel erhalten

---

2. App Signing by Google Play

App Signing ist einer der Bereiche, der bei Erstveröffentlichungen am häufigsten für Verwirrung sorgt. Seit 2021 ist App Signing by Google Play für neue Apps verpflichtend.

Warum Google den Signing Key verwaltet

Früher lag der Signing Key vollständig beim Entwickler. Das Problem: Ging der Key verloren, konnte die App nie wieder aktualisiert werden — ein neuer Eintrag im Play Store war nötig. Google löst das durch zentrale Verwaltung:

• Kein Key-Verlust-Risiko: Google speichert den App Signing Key sicher in seiner Infrastruktur
• Key-Rotation: Bei Sicherheitsvorfällen kann Google den Key rotieren, ohne dass Sie eine neue App erstellen müssen
• Automatisches Re-Signing: Ihre hochgeladenen Builds werden mit dem offiziellen Key signiert

Upload Key vs. App Signing Key

Es gibt zwei verschiedene Keys, die Sie unterscheiden müssen:

Keystore in der Praxis

Ein Keystore ist eine Datei (.jks oder .keystore), die Ihre kryptografischen Schlüssel enthält. So erstellen Sie einen Upload Keystore:

keytool -genkeypair -v -storetype JKS \
  -keyalg RSA -keysize 2048 -validity 10000 \
  -keystore upload-keystore.jks \
  -alias upload

Wichtige Regeln für den Keystore:

• Speichern Sie die Keystore-Datei niemals im Git-Repository
• Notieren Sie das Passwort an einem sicheren Ort (Passwort-Manager)
• Erstellen Sie ein Backup der Datei — auch wenn ein Verlust des Upload Keys nicht katastrophal ist, spart ein Backup Zeit

---

3. Release Tracks: Der Weg zur Veröffentlichung

Google Play bietet vier Release Tracks, die aufeinander aufbauen. Sie müssen nicht alle nutzen, aber das Verständnis ist wichtig.

Die vier Tracks im Überblick

Internal Testing — Ihr bester Freund

Internal Testing ist der schnellste Weg, Ihre App auf echte Geräte zu bringen:

• Kein Review: Die App ist innerhalb von Minuten verfügbar
• Bis zu 100 Tester: Per Google-E-Mail-Adresse einladen
• Eigener App-Link: Tester installieren über einen speziellen Play Store Link
• Schnelle Iteration: Neue Builds sind sofort nach Upload verfügbar

Unser Workflow bei exponent: Jeder Build geht zuerst in den Internal Testing Track. Erst wenn QA und Kunde dort abgenommen haben, promoten wir in Closed oder direkt in Production.

Closed Testing — Kontrollierte Beta

Closed Testing eignet sich, wenn Sie Feedback von einer größeren, aber kontrollierten Gruppe brauchen:

• Tester-Listen: Erstellen Sie verschiedene Gruppen (z. B. „Beta-Kunden", „Mitarbeiter")
• Link-basierter Beitritt: Alternativ können Tester über einen Link beitreten
• Review erforderlich: Google prüft den Build, aber meist schneller als bei Production
• Ideal für: Pilotkunden, die die App vor dem offiziellen Launch testen sollen

Open Testing — Öffentliche Beta

Open Testing macht Ihre App für jeden sichtbar, der im Play Store danach sucht:

• Kein Einladungs-Prozess: Jeder Nutzer kann die Beta installieren
• Play Store Listing: Die App erscheint regulär im Store mit einem „Beta"-Hinweis
• Feedback-Kanal: Bewertungen und Feedback von echten Nutzern vor dem finalen Launch
• Empfehlung: Nur nutzen, wenn Sie aktiv öffentliches Feedback wollen — ansonsten direkt von Closed Testing zu Production wechseln

Von Track zu Track: Promotion

Sie müssen eine App nicht in jedem Track neu hochladen. Stattdessen promoten Sie einen bestehenden Build:

1. Build in Internal Testing hochladen und testen
2. Denselben Build in Closed Testing promoten
3. Nach erfolgreicher Beta in Production promoten

Das spart Zeit und stellt sicher, dass exakt der getestete Build live geht.

---

4. Store-Listing optimieren

Das Store-Listing ist Ihr Schaufenster im Play Store. Es entscheidet darüber, ob Nutzer Ihre App installieren oder weiterscrollen.

Screenshots und Grafiken

• Screenshots: Mindestens 2, empfohlen 4–8 pro Gerätetyp (Smartphone, Tablet)
• Format: JPEG oder 24-Bit-PNG, mindestens 320px, maximal 3840px pro Seite
• Feature-Grafik: 1024 × 500 px — wird prominent im Play Store angezeigt (z. B. bei Suchergebnissen und auf der App-Detailseite)
• App-Icon: 512 × 512 px, 32-Bit-PNG mit Alpha-Kanal

Praxis-Tipp: Verwenden Sie keine reinen Device-Screenshots. Erstellen Sie gestaltete Frames mit kurzen Textbeschreibungen, die den Mehrwert der App kommunizieren. Tools wie Figma oder Sketch eignen sich dafür gut.

Kurz- und Langbeschreibung

• Kurzbeschreibung (max. 80 Zeichen): Der wichtigste Satz Ihrer App. Wird in Suchergebnissen angezeigt. Nutzen Sie Keywords, aber bleiben Sie natürlich.
• Langbeschreibung (max. 4.000 Zeichen): Ausführliche Beschreibung der Funktionen und Vorteile. Strukturieren Sie mit Aufzählungen. Die ersten 2–3 Zeilen sind am wichtigsten, da der Rest hinter „Mehr anzeigen" verschwindet.

Kategorie und Content Rating

• Kategorie: Wählen Sie die passendste Hauptkategorie (z. B. „Business", „Productivity", „Shopping")
• Content Rating Fragebogen: Google verwendet den IARC-Fragebogen (International Age Rating Coalition). Sie beantworten Fragen zu Gewalt, Glücksspiel, Sprache, etc. Anhand Ihrer Antworten wird automatisch ein Altersrating vergeben (PEGI, USK, etc.)

Achtung: Falsche Angaben im Content Rating Fragebogen können zur Entfernung der App führen. Beantworten Sie die Fragen ehrlich.

Datenschutzerklärung und Datenerfassung

Seit 2022 sind diese Angaben verpflichtend für alle Apps:

• Datenschutzerklärung: URL zu Ihrer Datenschutzseite. Diese muss öffentlich erreichbar sein und die tatsächliche Datenverarbeitung der App beschreiben.
• Datenerfassungs-Formular (Data Safety Section): Sie müssen detailliert angeben, welche Nutzerdaten Ihre App erfasst, wie diese verwendet werden und ob sie mit Dritten geteilt werden.

Das Datenerfassungs-Formular umfasst Kategorien wie:

• Standort, Kontakte, Fotos/Videos
• App-Aktivität, Web-Browsing, Suchverlauf
• Geräte-IDs, Absturzberichte
• Finanzinformationen, Gesundheitsdaten

Wichtig für österreichische Unternehmen: Die Datenschutzerklärung muss DSGVO-konform sein. Wenn Ihre App Analytics-Tools wie Firebase oder Tracking-SDKs nutzt, müssen diese im Datenerfassungs-Formular deklariert werden.

---

5. Build-System: AAB, Gradle und SDK-Anforderungen

Das Build-System ist oft die größte technische Hürde auf dem Weg in den Play Store.

AAB vs. APK

Seit 2021 akzeptiert der Google Play Store nur noch Android App Bundles (AAB) für neue Apps. Das klassische APK-Format ist für Play Store Uploads nicht mehr erlaubt.

targetSdkVersion — Googles jährlicher Zwang

Google erhöht regelmäßig die Mindest-targetSdkVersion für neue Apps und Updates. Stand 2026:

• Neue Apps: Müssen mindestens API Level 35 (Android 15) als Target haben
• Updates bestehender Apps: Müssen innerhalb eines Jahres nachziehen
• Wear OS: Eigene Anforderungen, aktuell API Level 34+

Verpassen Sie das Deadline, kann Ihre App nicht mehr aktualisiert werden — und neue Nutzer auf aktuellen Android-Versionen sehen sie möglicherweise nicht mehr im Store.

64-Bit Anforderung

Seit 2019 müssen alle Apps nativen 64-Bit-Code enthalten. Das betrifft primär Apps mit Native Libraries (NDK). Reine Java/Kotlin-Apps und React Native Apps sind standardmäßig kompatibel.

Prüfen Sie Ihre APK/AAB mit:

# AAB analysieren
bundletool build-apks --bundle=app.aab --output=app.apks
bundletool get-device-spec --output=device-spec.json
# Oder direkt im Build-Output prüfen:
# Schauen Sie nach lib/arm64-v8a/ und lib/x86_64/ Ordnern

Häufige Gradle-Probleme

Gradle ist das Build-System für Android — und oft die Quelle von Frust:

• Version Conflicts: Verschiedene Libraries fordern unterschiedliche Versionen derselben Dependency. Lösung: implementation statt compile, resolutionStrategy in build.gradle.
• OutOfMemoryError: Große Projekte brauchen mehr Heap-Speicher. In gradle.properties: org.gradle.jvmargs=-Xmx4096m.
• Build Cache Probleme: ./gradlew clean und ~/.gradle/caches löschen löst viele mysteriöse Fehler.
• SDK-Lizenzen nicht akzeptiert: sdkmanager --licenses ausführen, bevor Sie bauen.

---

6. Der Google Play Review Prozess

Jeder Build, der in Closed Testing, Open Testing oder Production gepusht wird, durchläuft einen Review-Prozess.

Was Google prüft

• Policy-Konformität: Einhaltung der Google Play Developer Programme Policies
• Malware-Scan: Automatischer Scan auf schädlichen Code
• Content Rating: Stimmt der Inhalt mit dem Fragebogen überein?
• Berechtigungen: Werden nur notwendige Permissions angefordert?
• Funktionalität: Grundlegende Funktionsprüfung (kein sofortiger Absturz, Login funktioniert)
• Metadaten: Screenshots, Beschreibung und Icon sind angemessen und nicht irreführend

Wie lange dauert das Review?

In der Regel wenige Stunden bis 3 Tage. Erfahrungsgemäß:

• Erste App eines neuen Accounts: 3–7 Tage (Google prüft strenger)
• Updates bestehender Apps: Meist innerhalb von 2–24 Stunden
• Nach Policy-Verstößen: Deutlich längere Review-Zeiten für alle folgenden Builds

Unterschied zum Apple App Store Review

Unsere Erfahrung: Google lehnt seltener ab als Apple, aber die Begründungen sind oft weniger klar. Bei Apple wissen Sie genau, was zu ändern ist — bei Google kommt manchmal ein generischer Policy-Hinweis, der Interpretation erfordert.

---

7. Häufige Fehler und Probleme

Aus unserer Praxis als Android-App-Entwickler kennen wir die häufigsten Stolpersteine.

Policy Violations

Die häufigsten Policy-Verstöße, die wir sehen:

• Deceptive Behavior: Die App tut nicht, was die Beschreibung verspricht. Auch versteckte Funktionen oder irreführende Berechtigungsanfragen fallen darunter.
• Ads Policy: Werbung, die den Inhalt verdeckt, unerwartete Interstitials, oder fehlende Kennzeichnung von Werbung.
• Impersonation: Ihr App-Name oder Icon ähnelt zu sehr einer bekannten App.
• Permissions Policy: Sie fordern READ_CONTACTS oder ACCESS_FINE_LOCATION an, ohne einen klaren In-App-Zweck.

Tipp: Lesen Sie die Google Play Developer Programme Policies vor der Einreichung. Besonders die Abschnitte zu Deceptive Behavior und User Data werden regelmäßig aktualisiert.

Fragmentierung: Die Android-Herausforderung

Anders als bei iOS, wo wenige Gerätetypen existieren, läuft Android auf tausenden verschiedenen Geräten:

• Bildschirmgrößen: Von 4 Zoll bis Faltgeräte mit Dual-Screens
• Android-Versionen: In der Praxis müssen Sie Android 8+ (API 26+) unterstützen, um 95 %+ der Nutzer zu erreichen
• Hersteller-Modifikationen: Samsung, Xiaomi, Huawei — jeder kocht sein eigenes Süppchen mit Custom ROMs
• Hardware-Unterschiede: Manche Geräte haben keinen Gyroskop, andere keine NFC

Lösung: Nutzen Sie Firebase Test Lab oder den Pre-launch Report in der Play Console (siehe Abschnitt „Nach dem Launch"), um Ihre App automatisch auf verschiedenen Geräten zu testen.

ProGuard/R8 Code-Shrinking Probleme

R8 (der Nachfolger von ProGuard) entfernt ungenutzten Code und verschleiert Namen, um die App-Größe zu reduzieren. Das kann zu Laufzeitfehlern führen:

• ClassNotFoundException: R8 hat eine Klasse entfernt, die per Reflection verwendet wird
• JSON-Parsing Fehler: Feldnamen wurden verschleiert, Serialisierung schlägt fehl
• WebView-Probleme: JavaScript-Interfaces werden nicht mehr gefunden

Lösung: Pflegen Sie proguard-rules.pro sorgfältig. Fügen Sie -keep-Regeln für alle per Reflection genutzten Klassen hinzu. Testen Sie den Release-Build (nicht nur Debug), bevor Sie hochladen.

Permission-Handling seit Android 13+

Seit Android 13 (API 33) hat sich das Berechtigungssystem weiter verschärft:

• Benachrichtigungen: POST_NOTIFICATIONS muss explizit angefordert werden — Nutzer werden nicht mehr automatisch gefragt
• Medien-Zugriff: Statt READ_EXTERNAL_STORAGE gibt es granulare Permissions (READ_MEDIA_IMAGES, READ_MEDIA_VIDEO, READ_MEDIA_AUDIO)
• Nearby Devices: Bluetooth-Scanning erfordert NEARBY_WIFI_DEVICES statt Location
• Exact Alarms: SCHEDULE_EXACT_ALARM erfordert seit Android 14 eine spezielle Permission

Best Practice: Fragen Sie Berechtigungen kontextuell an — also genau dann, wenn der Nutzer die betreffende Funktion verwenden will, nicht beim App-Start. Erklären Sie vorher, warum die Berechtigung nötig ist.

Background Service Einschränkungen

Android schränkt Hintergrund-Aktivitäten immer weiter ein, um die Akkulaufzeit zu verbessern:

• Background Execution Limits (seit Android 8): Services, die im Hintergrund laufen, werden nach kurzer Zeit beendet
• Foreground Service Typen (seit Android 14): Jeder Foreground Service braucht einen deklarierten Typ (camera, location, dataSync, etc.)
• Hersteller-Optimierungen: Samsung, Xiaomi und andere beenden aggressiv Hintergrund-Apps. Die Website Don't Kill My App dokumentiert die Unterschiede.

Lösung: Nutzen Sie WorkManager für Hintergrund-Aufgaben statt klassischer Services. Für Echtzeit-Funktionen verwenden Sie Foreground Services mit korrekter Typ-Deklaration und Benachrichtigung.

---

8. Nach dem Launch: Monitoring und Optimierung

Die Veröffentlichung ist erst der Anfang. Google stellt leistungsstarke Tools bereit, um die Qualität Ihrer App zu überwachen.

Android Vitals

Android Vitals in der Play Console zeigt die technische Gesundheit Ihrer App:

• ANR Rate (App Not Responding): Der Anteil der Sitzungen, in denen die App einfriert. Googles Schwelle: unter 0,47 % der täglichen Sitzungen. Darüber kann Ihre Sichtbarkeit im Store sinken.
• Crash Rate: Der Anteil der Sitzungen mit Abstürzen. Googles Schwelle: unter 1,09 %. Überschreitung führt zu Warnhinweisen und schlechterer Platzierung.
• Excessive Wake-Ups: Zu häufiges Aufwecken des Geräts aus dem Schlafmodus — schadet Akkulaufzeit und Store-Ranking.
• Stuck Background Wake Locks: Lang gehaltene Wake Locks, die den Akku leeren.

Pre-launch Reports

Für jeden Build, den Sie in einen Release Track hochladen, erstellt Google automatisch einen Pre-launch Report:

• Automatische Tests auf echten Geräten: Google startet Ihre App auf verschiedenen Geräten und Android-Versionen
• Absturz-Erkennung: Crashes während der automatischen Tests werden dokumentiert
• Screenshot-Vergleich: Sie sehen, wie Ihre App auf verschiedenen Bildschirmgrößen aussieht
• Accessibility-Prüfung: Fehlende Content Descriptions, zu kleine Touch-Targets
• Sicherheitslücken: Bekannte Schwachstellen in verwendeten Libraries

Tipp: Schauen Sie sich den Pre-launch Report an, bevor Sie einen Build von Internal Testing in Production promoten. Er findet oft Probleme auf Geräten, die Sie selbst nicht besitzen.

Bewertungen und Feedback

• Antworten Sie auf Bewertungen — besonders auf negative. Nutzer können ihre Bewertung ändern, wenn ihr Problem gelöst wird.
• Nutzen Sie die Bewertungsanalyse: Die Play Console gruppiert Feedback nach Themen und Stimmung.
• In-App-Review-API: Bitten Sie zufriedene Nutzer im richtigen Moment um eine Bewertung (z. B. nach erfolgreichem Abschluss einer Aktion, nicht beim ersten App-Start).

---

9. Apple App Store vs. Google Play Store im Vergleich

Viele unserer Kunden veröffentlichen ihre App auf beiden Plattformen gleichzeitig. Hier die wichtigsten Unterschiede:

Fazit: Google Play ist günstiger, schneller und weniger restriktiv. Apple bietet dafür eine zahlungskräftigere Nutzerschaft und klarere Guidelines. Für österreichische Apps empfehlen wir immer beide Plattformen, da Android hier über 65 % Marktanteil hat.

---

10. Häufig gestellte Fragen (FAQ)

Was kostet es, eine App im Google Play Store zu veröffentlichen?

Die Registrierungsgebühr beträgt einmalig 25 $. Es gibt keine jährlichen Kosten für den Developer Account selbst. Wenn Sie In-App-Käufe oder Abos anbieten, behält Google 15 % (bis 1 Mio. $ Jahresumsatz) bzw. 30 % Provision.

Wie lange dauert es, bis meine App im Play Store sichtbar ist?

Nach Genehmigung durch das Review-Team ist die App meist innerhalb weniger Stunden weltweit verfügbar. Der Review-Prozess selbst dauert bei Updates 2–24 Stunden, bei der Erstveröffentlichung eines neuen Accounts 3–7 Tage.

Kann ich meine App nur in Österreich veröffentlichen?

Ja. In der Play Console können Sie unter „Preise und Vertrieb" exakt festlegen, in welchen Ländern Ihre App verfügbar sein soll. Sie können auch länderspezifische Store-Listings mit angepassten Texten und Screenshots erstellen.

Was passiert, wenn meine App abgelehnt wird?

Sie erhalten eine E-Mail mit dem Grund der Ablehnung. In den meisten Fällen können Sie das Problem beheben und den Build erneut einreichen. Bei wiederholten oder schwerwiegenden Verstößen kann Google den gesamten Developer Account sperren — das ist aber selten und betrifft hauptsächlich Spam-Apps oder Malware.

Muss ich eine Datenschutzerklärung haben?

Ja, eine Datenschutzerklärung ist für alle Apps im Google Play Store verpflichtend. Zusätzlich müssen Sie das Data Safety Formular ausfüllen, in dem Sie angeben, welche Daten Ihre App erhebt und wie diese verarbeitet werden. Für österreichische Unternehmen muss die Datenschutzerklärung DSGVO-konform sein.

Brauche ich für Updates ein neues Review?

Ja, jedes Update durchläuft erneut das Review. Bei bestehenden Apps mit guter Historie dauert das in der Regel nur wenige Stunden. Ausnahme: Internal Testing erfordert kein Review.

Kann ich die App selbst veröffentlichen oder brauche ich einen Entwickler?

Das Veröffentlichen an sich kann technisch jeder machen. Die Herausforderung liegt im Build-Prozess: Die App muss korrekt signiert, als AAB gebaut und die targetSdkVersion-Anforderungen müssen erfüllt sein. Ohne Entwicklungserfahrung empfehlen wir, eine App-Agentur mit dem Release-Prozess zu betrauen.

---

Checkliste: Android App veröffentlichen

Bevor Sie auf „Review starten" klicken, prüfen Sie diese Punkte:

• Google Play Developer Account eingerichtet und verifiziert
• Upload Keystore erstellt und sicher gespeichert
• App als AAB (nicht APK) gebaut
• targetSdkVersion erfüllt aktuelle Google-Anforderungen (API 35+)
• App in Internal Testing hochgeladen und auf echten Geräten getestet
• Store-Listing vollständig (Screenshots, Beschreibung, Feature-Grafik, Icon)
• Content Rating Fragebogen ausgefüllt
• Datenschutzerklärung verlinkt
• Data Safety Formular vollständig ausgefüllt
• Pre-launch Report überprüft
• ProGuard/R8-Release-Build auf Fehler getestet
• Berechtigungen auf das Minimum reduziert

---

Nächste Schritte

Die Veröffentlichung einer Android-App im Play Store ist ein strukturierter Prozess, der mit etwas Vorbereitung reibungslos verläuft. Die größten Zeitfresser sind erfahrungsgemäß nicht das Review selbst, sondern Build-Probleme, vergessene Formulare und unklare Policy-Anforderungen.

Wenn Sie eine App entwickeln lassen oder Unterstützung beim Play Store Launch brauchen, helfen wir Ihnen gerne:

• Android-App entwickeln lassen — Von der Idee bis zum Play Store Launch
• App-Entwicklung bei exponent — Alle App-Leistungen im Überblick
• Was kostet eine App in Österreich? — Detaillierte Kostenaufstellung
• Unverbindliches Angebot anfordern — Wir beraten Sie kostenlos
• Kontakt aufnehmen — Schreiben Sie uns direkt