Google Play: що це, публікація додатків і консоль розробника

Що таке Google Play?

Google Play — цифрова платформа дистрибуції від Google, що об'єднує магазин додатків, ігор, фільмів, книг і музики. Запущена 22 жовтня 2008 року під назвою Android Market, платформа була перейменована в Google Play у березні 2012 року. На відміну від App Store від Apple, Google Play не є єдиним каналом встановлення Android-додатків — користувачі можуть встановлювати APK зі сторонніх джерел (sideloading), використовувати альтернативні магазини (Samsung Galaxy Store, Amazon Appstore, F-Droid), але більшість користувачів використовують Google Play.

За даними Google I/O 2026, щомісячна аудиторія Google Play перевищує 2,8 мільярда активних користувачів із 190+ країн. Кількість доступних додатків — понад 3,2 мільйона. Середня ціна додатка нижча, ніж в App Store — багато розробників використовують безкоштовну модель з рекламою або In-App Purchases. Google Play також включає розділи для планшетів (Large Screen Apps), Wear OS, Android TV, Android Auto та Chromebook.

Google Play пропонує унікальні для Android інструменти: Google Play Protect — вбудований антивірус, що перевіряє кожен додаток до та після встановлення; Android Vitals — аналітика продуктивності додатка (ANR, crash rate, startup time); Google Play Integrity — API для перевірки автентичності пристрою та додатка (заміна SafetyNet Attestation). Play Integrity обов'язковий для додатків, що працюють з конфіденційними даними та платежами.

Google Play Console: можливості та налаштування

Google Play Console — центральний інструмент розробника для керування додатками в Google Play. Доступний за адресою play.google.com/console. Для початку роботи потрібен обліковий запис розробника (одноразовий платіж $25) і підтвердження особи. Play Console надає повний цикл керування додатком: від завантаження першого AAB до аналітики продажів і звітів про помилки.

Основні розділи Play Console: Dashboard — загальна статистика по всіх додатках (встановлення, видалення, збої, рейтинг, дохід); Release — керування версіями та треками (Production, Open Beta, Closed Beta, Internal Testing); Growth — інструменти просування (Google Ads, Promo Codes, Store Listing Experiments); Quality — Android Vitals (ANR rate, crash rate, startup time, render time); Monetization — налаштування продуктів, підписок, Google Play Pass; Users & Permissions — керування доступом команди.

Треки тестування Google Play — ключова відмінність від App Store. Internal Testing — до 100 тестувальників, не потребує рев'ю, оновлення публікуються миттєво. Closed Testing (Alpha) — до 100 тестувальників, потребує рев'ю. Open Testing (Beta) — необмежена кількість тестувальників, додаток доступний у Google Play для всіх, хто зареєструвався в тесті. Рекомендується публікувати додаток спочатку в Internal Testing, потім у Closed/Open Beta і лише потім у Production.

// Google Play Billing Library 6.x — перевірка підписки
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) {
            // Покупка успішна — обробити purchases
            purchases.forEach { purchase ->
                handlePurchase(purchase)
            }
        }
    }

    suspend fun startConnection() {
        billingClient.startConnection(object : BillingClientStateListener {
            override fun onBillingSetupFinished(result: BillingResult) {
                if (result.responseCode == BillingClient.BillingResponseCode.OK) {
                    // Клієнт готовий до роботи
                }
            }
            override fun onBillingServiceDisconnected() {
                // Перепідключення
            }
        })
    }

    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) {
        // Верифікація покупки на сервері
        // 1. Відправити purchaseToken на ваш сервер
        // 2. Сервер верифікує через Google Play Developer API
        // 3. При успіху — розблокувати функціональність
        val purchaseToken = purchase.purchaseToken
        val productId = purchase.products.firstOrNull()
        println("Purchase: $productId, Token: $purchaseToken")
    }
}

Клас PlayBillingManager демонструє роботу з Google Play Billing Library 6.x: встановлення з'єднання з BillingClient, запит деталей продукту (підписки або разової покупки), обробка результату покупки через PurchasesUpdatedListener. Верифікація має виконуватися на сервері через Google Play Developer API з purchaseToken — ніколи не довіряйте лише локальній перевірці, оскільки покупка може бути підроблена.

Процес публікації додатка в Google Play

Публікація в Google Play — багатоетапний процес, що включає реєстрацію облікового запису, підготовку додатка, налаштування в Play Console, завантаження AAB, проходження перевірки та публікацію. Порівняно з App Store, процес менш формалізований: Google покладається на автоматизовану перевірку (Play Integrity, сканування на malware через Google Play Protect), а не на ручну модерацію кожного додатка.

Етап 1: Реєстрація облікового запису розробника

Для публікації потрібен обліковий запис Google і реєстрація в Google Play Console за $25 (одноразовий платіж). Після оплати потрібна верифікація особи: завантаження посвідчення особи (паспорт або водійські права) та підтвердження адреси. Процес верифікації триває від 24 годин до 2 тижнів. Без верифікації додаток не буде опубліковано в Production-треку.

Етап 2: Збірка AAB і заповнення Store Listing

Google рекомендує формат AAB (Android App Bundle) із серпня 2021 року — APK більше не приймається для нових додатків. AAB дозволяє Google Play генерувати оптимізовані APK для кожного типу пристрою (різні ABI, екрани, мови), скорочуючи розмір завантаження на 15-35%. Збірка виконується через Android Studio: Build → Build Bundle(s) / APK(s) → Build Bundle(s). AAB підписується через Play App Signing — Google зберігає ключ підпису на своїй стороні.

Store Listing — сторінка додатка в Google Play: назва (50 символів), короткий опис (80 символів), повний опис (4000 символів), скріншоти (мінімум 2, до 8; для телефону 5", 6.5", для планшета 7"+), іконка (512x512), фіче-графіка (1024x500), промо-відео (YouTube). Короткий опис — найважливіше для пошуку Google Play, він індексується та показується в результатах. Повний опис індексується, але для пошуку менш значущий.

Етап 3: Вибір треку та публікація

Після завантаження AAB розробник вибирає трек: Internal Testing (до 100 тестувальників, без рев'ю), Closed Testing (Alpha, до 100 осіб, з рев'ю), Open Testing (Beta, необмежено, з рев'ю) або Production. Рекомендується почати з Internal Testing — протестувати на реальних пристроях, потім Closed Testing для ширшої перевірки і лише потім — Production. Для Open Testing і Production потрібно як мінімум 12 годин і 20 тестувальників у Closed Testing за останні 14 днів для нових облікових записів (політика Google Play 2024).

Після публікації додаток з'являється в Google Play протягом 1-24 годин. Перше оновлення може бути комплексно перевірено. Google Play автоматично сканує кожен додаток на шкідливий код через Google Play Protect. Якщо виявлено загрозу — додаток може бути знято з публікації, а обліковий запис розробника заблоковано.

Вимоги Google Play до targetSdkVersion

Google Play встановлює обов'язкові вимоги до targetSdkVersion для публікації та оновлення додатків. Щороку Google підвищує мінімальний targetSdk, щоб гарантувати, що додатки використовують актуальні behavioural changes безпеки. Із серпня 2024 року мінімальний targetSdk — API 33; із серпня 2025 — API 34; із серпня 2026 — API 35 (Android 15).

Додатки, що не задовольняють вимогу, блокуються — їх не можна опублікувати або оновити. Вже опубліковані додатки з низьким targetSdk продовжують працювати в магазині, але для оновлення потрібно підвищити targetSdk. Google Play Console попереджає за 90 днів до підвищення порогу. Багато розробників відкладають оновлення до останнього моменту, що створює ризик блокування додатка при необхідності термінового фіксу бага.

Підвищення targetSdkVersion вимагає перевірки всіх behavioural changes, введених між старим і новим targetSdk. Для прикладу, при міграції з API 33 (Android 13) на API 35 (Android 15) потрібно перевірити: Foreground Service Types (API 34) — обов'язкова декларація типу сервісу в маніфесті; Privacy Sandbox (API 35) — обмеження на рекламні ідентифікатори; PhotoPicker (API 34+) — заміна прямого доступу до галереї на системний пікер; нові обмеження фонових служб. Кожне behavioural change може вимагати зміни коду.

Play Console API для автоматизації перевірки

Google Play Developer API (REST) дозволяє автоматизувати перевірку targetSdk для всіх додатків в обліковому записі. Метод applications.get повертає інформацію про targetSdkVersion. Рекомендується налаштувати моніторинг через API за 120 днів до дедлайну, щоб отримати список додатків, що потребують оновлення. Для додатків з великим обсягом коду оцінка трудозатрат — від 2 днів до 2 тижнів на behavioural changes.

// Перевірка compliance targetSdk в коді додатка
import android.os.Build

class TargetSdkCompliance {

    // Мінімальний targetSdk, необхідний Google Play у 2026 році
    companion object {
        const val REQUIRED_TARGET_SDK = 35
    }

    // Перевірка: чи потрібно обробляти behavioural change API 34?
    fun checkForegroundServiceTypes(targetSdk: Int): Boolean {
        // Foreground Service Types обов'язковий для targetSdk >= 34
        return targetSdk >= 34
    }

    // Перевірка: чи потрібно обробляти Privacy Sandbox (API 35)?
    fun checkPrivacySandbox(targetSdk: Int): Boolean {
        return targetSdk >= 35
    }

    // Перевірка compliance перед збіркою
    fun validateCompliance(targetSdk: Int): List<String> {
        val warnings = mutableListOf<String>()

        if (targetSdk < REQUIRED_TARGET_SDK) {
            warnings.add("targetSdk $targetSdk нижче необхідного $REQUIRED_TARGET_SDK")
        }

        if (targetSdk >= 34) {
            // Переконайтеся, що всі foreground-сервіси мають type в маніфесті
            warnings.add("Перевірте: всі foreground-сервіси декларують type в AndroidManifest.xml")
        }

        if (targetSdk >= 35) {
            warnings.add("Перевірте: Privacy Sandbox, обмеження Advertising ID")
        }

        return warnings
    }
}

Клас TargetSdkCompliance перевіряє compliance targetSdk перед збіркою. Метод validateCompliance повертає список попереджень про необхідні behavioural changes для заданого targetSdk. Використовуйте такий код у CI/CD для автоматичної перевірки compliance перед відправкою білда в Google Play Console. В IT Sectr ми впровадили таку перевірку в CI після блокування одного з проєктів через пропущений targetSdk.

Монетизація в Google Play: In-App Billing, підписки та AdMob

Монетизація в Google Play включає кілька моделей: платне завантаження, In-App Products (разові покупки: consumable — ігрова валюта; non-consumable — видалення реклами), підписки (auto-renewable subscriptions через Google Play Billing), рекламу (AdMob, Google Ad Manager, сторонні мережі) та Google Play Pass (підписка на пакет додатків, дохід ділиться між розробниками за часом використання).

Google Play Billing Library (актуальна версія — 7.x на 2026 рік) — обов'язковий інструмент для продажу цифрових товарів у додатку. Альтернативні платіжні системи заборонені для цифрових товарів (виняток — Південна Корея, Індія, EU Digital Markets Act). Billing Library 7.x вимагає міграції з покупок на базі SKU на product-based моделі (ProductDetails замість SkuDetails) і підтримує Kotlin Coroutines та Flow для асинхронних операцій.

Комісія Google Play: 30% стандартна, 15% для перших $1 млн доходу на рік (аналогічно Apple Small Business Program). Після досягнення порогу $1 млн комісія повертається до 30% на решту року. Підписки: 30% перший рік, 15% з другого року (аналог App Store). Для програм Google Play Pass — дохід розподіляється на основі engagement (час використання додатка підписниками Pass), а не фіксованої комісії.

AdMob від Google — основний інструмент рекламної монетизації. Підтримує банерну, міжсторінкову (interstitial), нативну, rewarded (за винагороду) рекламу. Google Analytics for Firebase інтегрується з AdMob для відстеження конверсії реклами в цільові дії. З Android 14+ (API 34) потрібен Google Play Services for Ads 22.0+ та Handling Ad Responses API для дотримання Privacy Sandbox. Рекламна монетизація — 0% комісії — популярний вибір для безкоштовних додатків з великою аудиторією.

Модерація Google Play: перевірки та політики

Модерація Google Play (Google Play Policy Review) відрізняється від App Store — Google покладається на автоматизовані перевірки та вибіркову ручну модерацію, а не на 100% ручну перевірку кожного додатка. Автоматична система сканує AAB/APK на наявність шкідливого коду, порушення політик (Spyware, Deceptive Behavior, SDK violations) та невідповідності вимогам до targetSdk. При виявленні порушення додаток може бути відхилено або знято з публікації.

Google Play публікує Developer Program Policies — набір правил, що охоплюють контент, поведінку додатка, монетизацію та конфіденційність. Основні розділи: Restricted Content (насильство, ненависть, незаконна діяльність), Deceptive Behavior (хибні заяви, імітація інших додатків), Monetization and Ads (чесна реклама, відповідність IAP-політиці), Privacy and Security (збір даних, шифрування), Store Listing and Promotion (точний опис, правильна категоризація).

Google активно бореться з spyware та deceptive SDK. У 2024-2025 роках Google видалив понад 1,5 мільйона додатків, що порушують політики конфіденційності. Особлива увага — SDK, що збирають дані без відома користувача (location tracking без згоди, читання контактів та SMS). Перед публікацією перевірте використовувані SDK на відповідність Google Play Policy — багато популярних SDK (наприклад, деякі рекламні мережі) були заблоковані за порушення політик.

Процес апеляції: якщо додаток відхилено, розробник отримує повідомлення в Play Console з причиною та рекомендаціями. Можна подати апеляцію через Play Console → Policy → Appeals. Термін розгляду — до 7 днів. Повторні порушення однієї політики ведуть до попередження (strike), триразове порушення — до блокування облікового запису розробника. Відновлення заблокованого облікового запису — вкрай складний процес, що вимагає письмового звернення та доказів виправлення порушень.

Для мінімізації ризиків: використовуйте Google Play Integrity API для перевірки автентичності запитів, впровадьте Data Safety Section (обов'язково з 2023 року — вкажіть всі зібрані дані та цілі збору), перевірте всі SDK на відповідність Developer Program Policies, використовуйте Play Console Policy Insights для відстеження потенційних порушень до публікації. При розробці в IT Sectr ми перевіряємо кожен додаток через internal testing на реальних пристроях перед Production-релізом.