Google Play: co to jest, publikacja aplikacji i konsola dewelopera

Czym jest Google Play?

Google Play — cyfrowa platforma dystrybucji od Google, łącząca sklep z aplikacjami, grami, filmami, książkami i muzyką. Uruchomiona 22 października 2008 roku pod nazwą Android Market, platforma została przemianowana na Google Play w marcu 2012 roku. W przeciwieństwie do App Store od Apple, Google Play nie jest jedynym kanałem instalacji aplikacji Android — użytkownicy mogą instalować APK z zewnętrznych źródeł (sideloading), korzystać z alternatywnych sklepów (Samsung Galaxy Store, Amazon Appstore, F-Droid), ale większość użytkowników korzysta z Google Play.

Według danych Google I/O 2026, miesięczna publiczność Google Play przekracza 2,8 miliarda aktywnych użytkowników z 190+ krajów. Liczba dostępnych aplikacji — ponad 3,2 miliona. Średnia cena aplikacji jest niższa niż w App Store — wielu deweloperów korzysta z bezpłatnego modelu z reklamą lub zakupami w aplikacji. Google Play obejmuje również sekcje dla tabletów (Large Screen Apps), Wear OS, Android TV, Android Auto i Chromebook.

Google Play oferuje unikalne dla Androida narzędzia: Google Play Protect — wbudowany antywirus, sprawdzający każdą aplikację przed i po instalacji; Android Vitals — analityka wydajności aplikacji (ANR, wskaźnik awarii, czas uruchamiania); Google Play Integrity — API do weryfikacji autentyczności urządzenia i aplikacji (zamiennik SafetyNet Attestation). Play Integrity jest obowiązkowy dla aplikacji pracujących z poufnymi danymi i płatnościami.

Google Play Console: możliwości i konfiguracja

Google Play Console — centralne narzędzie dewelopera do zarządzania aplikacjami w Google Play. Dostępne pod adresem play.google.com/console. Do rozpoczęcia pracy wymagane jest konto deweloperskie (jednorazowa opłata $25) i potwierdzenie tożsamości. Play Console zapewnia pełny cykl zarządzania aplikacją: od przesłania pierwszego AAB po analitykę sprzedaży i raporty awarii.

Główne sekcje Play Console: Dashboard — ogólne statystyki dla wszystkich aplikacji (instalacje, usunięcia, awarie, ocena, dochód); Release — zarządzanie wersjami i ścieżkami (Production, Open Beta, Closed Beta, Internal Testing); Growth — narzędzia promocji (Google Ads, Promo Codes, Store Listing Experiments); Quality — Android Vitals (wskaźnik ANR, wskaźnik awarii, czas uruchamiania, czas renderowania); Monetization — konfiguracja produktów, subskrypcji, Google Play Pass; Users & Permissions — zarządzanie dostępem zespołu.

Ścieżki testowania Google Play — kluczowa różnica w stosunku do App Store. Internal Testing — do 100 testerów, nie wymaga recenzji, aktualizacje publikowane natychmiastowo. Closed Testing (Alpha) — do 100 testerów, wymaga recenzji. Open Testing (Beta) — nieograniczona liczba testerów, aplikacja dostępna w Google Play dla wszystkich zarejestrowanych w teście. Zaleca się publikowanie aplikacji najpierw w Internal Testing, następnie w Closed/Open Beta, a dopiero potem w Production.

// Google Play Billing Library 6.x — sprawdzanie subskrypcji
import com.android.billingclient.api.BillingClient
import com.android.billingclient.api.BillingClientStateListener
import com.android.billingclient.api.BillingFlowParams
import com.android.billingclient.api.PurchasesUpdatedListener
import com.android.billingclient.api.QueryProductDetailsParams
import kotlinx.coroutines.tasks.await

class PlayBillingManager(
    private val context: Context
) {
    private val billingClient = BillingClient.newBuilder(context)
        .setListener(purchasesUpdatedListener)
        .enablePendingPurchases()
        .build()

    private val purchasesUpdatedListener = PurchasesUpdatedListener { billingResult, purchases ->
        if (billingResult.responseCode == BillingClient.BillingResponseCode.OK && purchases != null) {
            // Zakup udany — przetworzyć zakupy
            purchases.forEach { purchase ->
                handlePurchase(purchase)
            }
        }
    }

    suspend fun startConnection() {
        billingClient.startConnection(object : BillingClientStateListener {
            override fun onBillingSetupFinished(result: BillingResult) {
                if (result.responseCode == BillingClient.BillingResponseCode.OK) {
                    // Klient gotowy do pracy
                }
            }
            override fun onBillingServiceDisconnected() {
                // Ponowne połączenie
            }
        })
    }

    suspend fun querySubscription(productId: String): ProductDetails? {
        val params = QueryProductDetailsParams.newBuilder()
            .setProductList(
                listOf(
                    QueryProductDetailsParams.Product.newBuilder()
                        .setProductId(productId)
                        .setProductType(BillingClient.ProductType.SUBS)
                        .build()
                )
            )
            .build()

        val result = billingClient.queryProductDetails(params)
        return result.productDetailsList?.firstOrNull()
    }

    private fun handlePurchase(purchase: Purchase) {
        // Weryfikacja zakupu na serwerze
        // 1. Wyślij purchaseToken na swój serwer
        // 2. Serwer weryfikuje przez Google Play Developer API
        // 3. Po sukcesie — odblokuj funkcjonalność
        val purchaseToken = purchase.purchaseToken
        val productId = purchase.products.firstOrNull()
        println("Purchase: $productId, Token: $purchaseToken")
    }
}

Klasa PlayBillingManager demonstruje pracę z Google Play Billing Library 6.x: nawiązywanie połączenia z BillingClient, zapytanie o szczegóły produktu (subskrypcji lub jednorazowego zakupu), obsługa wyniku zakupu przez PurchasesUpdatedListener. Weryfikacja powinna być wykonana na serwerze przez Google Play Developer API z tokenem purchaseToken — nigdy nie ufaj tylko lokalnej weryfikacji, ponieważ zakup może być sfałszowany.

Proces publikacji aplikacji w Google Play

Publikacja w Google Play — wieloetapowy proces obejmujący rejestrację konta, przygotowanie aplikacji, konfigurację w Play Console, przesłanie AAB, przejście weryfikacji i publikację. W porównaniu z App Store, proces jest mniej sformalizowany: Google polega na zautomatyzowanej weryfikacji (Play Integrity, skanowanie w poszukiwaniu malware przez Google Play Protect), a nie na ręcznej moderacji każdej aplikacji.

Etap 1: Rejestracja konta deweloperskiego

Do publikacji wymagane jest konto Google i rejestracja w Google Play Console za $25 (jednorazowa opłata). Po opłaceniu wymagana jest weryfikacja tożsamości: przesłanie dokumentu tożsamości (paszport lub prawo jazdy) i potwierdzenie adresu. Proces weryfikacji trwa od 24 godzin do 2 tygodni. Bez weryfikacji aplikacja nie zostanie opublikowana w ścieżce Production.

Etap 2: Budowa AAB i wypełnienie Store Listing

Google zaleca format AAB (Android App Bundle) od sierpnia 2021 roku — APK nie jest już akceptowany dla nowych aplikacji. AAB pozwala Google Play generować zoptymalizowane APK dla każdego typu urządzenia (różne ABI, ekrany, języki), zmniejszając rozmiar pobierania o 15-35%. Budowa jest wykonywana przez Android Studio: Build → Build Bundle(s) / APK(s) → Build Bundle(s). AAB jest podpisywany przez Play App Signing — Google przechowuje klucz podpisu po swojej stronie.

Store Listing — strona aplikacji w Google Play: nazwa (50 znaków), krótki opis (80 znaków), pełny opis (4000 znaków), zrzuty ekranu (minimum 2, do 8; dla telefonu 5", 6.5", dla tabletu 7"+), ikona (512x512), grafika promocyjna (1024x500), wideo promocyjne (YouTube). Krótki opis jest najważniejszy dla wyszukiwania w Google Play — jest indeksowany i wyświetlany w wynikach. Pełny opis jest indeksowany, ale ma mniejsze znaczenie dla wyszukiwania.

Etap 3: Wybór ścieżki i publikacja

Po przesłaniu AAB deweloper wybiera ścieżkę: Internal Testing (do 100 testerów, bez recenzji), Closed Testing (Alpha, do 100 osób, z recenzją), Open Testing (Beta, nieograniczona, z recenzją) lub Production. Zaleca się rozpoczęcie od Internal Testing — przetestowanie na rzeczywistych urządzeniach, następnie Closed Testing dla szerszej weryfikacji, a dopiero potem — Production. Dla Open Testing i Production wymagane jest co najmniej 12 godzin i 20 testerów w Closed Testing w ciągu ostatnich 14 dni dla nowych kont (polityka Google Play 2024).

Po publikacji aplikacja pojawia się w Google Play w ciągu 1-24 godzin. Pierwsza aktualizacja może być kompleksowo sprawdzona. Google Play automatycznie skanuje każdą aplikację w poszukiwaniu złośliwego kodu przez Google Play Protect. W przypadku wykrycia zagrożenia aplikacja może zostać usunięta, a konto deweloperskie zablokowane.

Wymagania Google Play dotyczące targetSdkVersion

Google Play ustanawia obowiązkowe wymagania dotyczące targetSdkVersion do publikacji i aktualizacji aplikacji. Każdego roku Google podnosi minimalny targetSdk, aby zapewnić, że aplikacje korzystają z aktualnych zmian behawioralnych dotyczących bezpieczeństwa. Od sierpnia 2024 minimalny targetSdk — API 33; od sierpnia 2025 — API 34; od sierpnia 2026 — API 35 (Android 15).

Aplikacje niespełniające wymogu są blokowane — nie można ich opublikować ani zaktualizować. Już opublikowane aplikacje z niskim targetSdk nadal działają w sklepie, ale do aktualizacji wymagane jest podniesienie targetSdk. Google Play Console ostrzega na 90 dni przed podniesieniem progu. Wielu deweloperów odkłada aktualizację do ostatniego momentu, co stwarza ryzyko zablokowania aplikacji w przypadku pilnej naprawy błędu.

Podniesienie targetSdkVersion wymaga sprawdzenia wszystkich zmian behawioralnych wprowadzonych między starym a nowym targetSdk. Na przykład przy migracji z API 33 (Android 13) na API 35 (Android 15) należy sprawdzić: Foreground Service Types (API 34) — obowiązkowa deklaracja typu usługi w manifeście; Privacy Sandbox (API 35) — ograniczenia dotyczące identyfikatorów reklamowych; PhotoPicker (API 34+) — zamiana bezpośredniego dostępu do galerii na systemowy picker; nowe ograniczenia usług tła. Każda zmiana behawioralna może wymagać modyfikacji kodu.

Play Console API do automatyzacji weryfikacji

Google Play Developer API (REST) umożliwia automatyzację weryfikacji targetSdk dla wszystkich aplikacji na koncie. Metoda applications.get zwraca informacje o targetSdkVersion. Zaleca się skonfigurowanie monitorowania przez API na 120 dni przed terminem, aby uzyskać listę aplikacji wymagających aktualizacji. Dla aplikacji z dużą ilością kodu szacowany nakład pracy — od 2 dni do 2 tygodni na zmiany behawioralne.

// Sprawdzanie zgodności targetSdk w kodzie aplikacji
import android.os.Build

class TargetSdkCompliance {

    // Minimalny targetSdk wymagany przez Google Play w 2026 roku
    companion object {
        const val REQUIRED_TARGET_SDK = 35
    }

    // Sprawdzenie: czy trzeba obsłużyć behavioural change API 34?
    fun checkForegroundServiceTypes(targetSdk: Int): Boolean {
        // Foreground Service Types jest obowiązkowy dla targetSdk >= 34
        return targetSdk >= 34
    }

    // Sprawdzenie: czy trzeba obsłużyć Privacy Sandbox (API 35)?
    fun checkPrivacySandbox(targetSdk: Int): Boolean {
        return targetSdk >= 35
    }

    // Sprawdzanie zgodności przed budową
    fun validateCompliance(targetSdk: Int): List<String> {
        val warnings = mutableListOf<String>()

        if (targetSdk < REQUIRED_TARGET_SDK) {
            warnings.add("targetSdk $targetSdk jest niższy niż wymagany $REQUIRED_TARGET_SDK")
        }

        if (targetSdk >= 34) {
            // Upewnij się, że wszystkie foreground-serwisy mają type w manifeście
            warnings.add("Sprawdź: wszystkie foreground-serwisy deklarują type w AndroidManifest.xml")
        }

        if (targetSdk >= 35) {
            warnings.add("Sprawdź: Privacy Sandbox, ograniczenia Advertising ID")
        }

        return warnings
    }
}

Klasa TargetSdkCompliance sprawdza zgodność targetSdk przed budową. Metoda validateCompliance zwraca listę ostrzeżeń o wymaganych zmianach behawioralnych dla danego targetSdk. Używaj takiego kodu w CI/CD do automatycznego sprawdzania zgodności przed wysłaniem builda do Google Play Console. W IT Sectr wdrożyliśmy takie sprawdzenie w CI po zablokowaniu jednego z projektów z powodu pominiętego targetSdk.

Monetyzacja w Google Play: In-App Billing, subskrypcje i AdMob

Monetyzacja w Google Play obejmuje kilka modeli: płatne pobieranie, In-App Products (zakupy jednorazowe: consumable — waluta w grze; non-consumable — usunięcie reklam), subskrypcje (auto-renewable subscriptions przez Google Play Billing), reklama (AdMob, Google Ad Manager, sieci zewnętrzne) i Google Play Pass (subskrypcja pakietu aplikacji, dochód dzielony między deweloperów według czasu użytkowania).

Google Play Billing Library (aktualna wersja — 7.x na 2026 rok) — obowiązkowe narzędzie do sprzedaży cyfrowych towarów w aplikacji. Alternatywne systemy płatności są zabronione dla towarów cyfrowych (wyjątek — Korea Południowa, Indie, EU Digital Markets Act). Billing Library 7.x wymaga migracji z zakupów opartych na SKU na modele oparte na produktach (ProductDetails zamiast SkuDetails) i obsługuje Kotlin Coroutines i Flow do operacji asynchronicznych.

Prowizja Google Play: 30% standardowa, 15% dla pierwszych $1 mln dochodu rocznie (analogicznie do Apple Small Business Program). Po osiągnięciu progu $1 mln prowizja wraca do 30% na pozostałą część roku. Subskrypcje: 30% pierwszy rok, 15% od drugiego roku (analogicznie do App Store). Dla programów Google Play Pass — dochód jest rozdzielany na podstawie zaangażowania (czasu korzystania z aplikacji przez subskrybentów Pass), a nie stałej prowizji.

AdMob od Google — główne narzędzie monetyzacji reklamowej. Obsługuje reklamy banerowe, śródmiąższowe (interstitial), natywne, z nagrodą (rewarded). Google Analytics dla Firebase integruje się z AdMob do śledzenia konwersji reklam na docelowe działania. Od Android 14+ (API 34) wymagane jest Google Play Services for Ads 22.0+ i Handling Ad Responses API do zgodności z Privacy Sandbox. Monetyzacja reklamowa — 0% prowizji — popularny wybór dla bezpłatnych aplikacji z dużą publicznością.

Moderacja Google Play: kontrole i polityki

Moderacja Google Play (Google Play Policy Review) różni się od App Store — Google polega na zautomatyzowanych kontrolach i wybiórczej ręcznej moderacji, a nie na 100% ręcznym sprawdzaniu każdej aplikacji. System automatyczny skanuje AAB/APK w poszukiwaniu złośliwego kodu, naruszeń polityk (Spyware, Deceptive Behavior, naruszenia SDK) i niezgodności z wymaganiami targetSdk. W przypadku wykrycia naruszenia aplikacja może zostać odrzucona lub usunięta.

Google Play publikuje Developer Program Policies — zestaw zasad obejmujących treść, zachowanie aplikacji, monetyzację i prywatność. Główne sekcje: Restricted Content (przemoc, nienawiść, nielegalna działalność), Deceptive Behavior (fałszywe oświadczenia, imitacja innych aplikacji), Monetization and Ads (uczciwa reklama, zgodność z polityką IAP), Privacy and Security (zbieranie danych, szyfrowanie), Store Listing and Promotion (dokładny opis, prawidłowa kategoryzacja).

Google aktywnie walczy z spyware i deceptive SDK. W latach 2024-2025 Google usunął ponad 1,5 miliona aplikacji naruszających polityki prywatności. Szczególna uwaga — SDK zbierające dane bez wiedzy użytkownika (śledzenie lokalizacji bez zgody, odczytywanie kontaktów i SMS). Przed publikacją sprawdź używane SDK pod kątem zgodności z Google Play Policy — wiele popularnych SDK (na przykład niektóre sieci reklamowe) zostało zablokowanych za naruszenie polityk.

Proces apelacji: jeśli aplikacja zostanie odrzucona, deweloper otrzymuje powiadomienie w Play Console z przyczyną i zaleceniami. Można złożyć apelację przez Play Console → Policy → Appeals. Czas rozpatrzenia — do 7 dni. Powtarzające się naruszenia tej samej polityki prowadzą do ostrzeżenia (strike), trzykrotne naruszenie — do blokady konta deweloperskiego. Przywrócenie zablokowanego konta jest niezwykle trudnym procesem, wymagającym pisemnego odwołania i dowodów naprawy naruszeń.

Aby zminimalizować ryzyko: używaj Google Play Integrity API do weryfikacji autentyczności żądań, wdróż Data Safety Section (obowiązkowa od 2023 roku — wskaż wszystkie zbierane dane i cele zbierania), sprawdź wszystkie SDK pod kątem zgodności z Developer Program Policies, używaj Play Console Policy Insights do śledzenia potencjalnych naruszeń przed publikacją. Podczas tworzenia aplikacji w IT Sectr sprawdzamy każdą aplikację przez internal testing na rzeczywistych urządzeniach przed wydaniem produkcyjnym.