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 — много разработчици използват безплатния модел с реклама или покупки в приложението. Google Play също така включва раздели за таблети (Large Screen Apps), Wear OS, Android TV, Android Auto и Chromebook.

Google Play предлага уникални инструменти за Android: Google Play Protect — вграден антивирус, който проверява всяко приложение преди и след инсталиране; Android Vitals — анализи на производителността на приложението (ANR, честота на сривове, време за стартиране); 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, честота на сривове, време за стартиране, време за рендиране); 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.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, сканиране за зловреден софтуер чрез 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, за да гарантира, че приложенията използват актуални промени в поведението за сигурност. От август 2024 г. минималният targetSdk е API 33; от август 2025 г. — API 34; от август 2026 г. — API 35 (Android 15).

Приложенията, които не отговарят на изискването, се блокират — не могат да бъдат публикувани или актуализирани. Вече публикуваните приложения с нисък targetSdk продължават да работят в магазина, но за актуализация се изисква повишаване на targetSdk. Google Play Console предупреждава 90 дни преди повишаване на прага. Много разработчици отлагат актуализацията до последния момент, което създава риск от блокиране на приложението при спешна корекция на грешка.

Повишаването на targetSdkVersion изисква проверка на всички промени в поведението, въведени между стария и новия targetSdk. Например, при миграция от API 33 (Android 13) към API 35 (Android 15) трябва да се провери: Foreground Service Types (API 34) — задължителна декларация на типа услуга в манифеста; Privacy Sandbox (API 35) — ограничения на рекламните идентификатори; PhotoPicker (API 34+) — замяна на директния достъп до галерията със системен избирател; нови ограничения на фоновите услуги. Всяка промяна в поведението може да изисква промяна на кода.

Play Console API за автоматизиране на проверката

Google Play Developer API (REST) позволява автоматизиране на проверката на targetSdk за всички приложения в акаунта. Методът applications.get връща информация за targetSdkVersion. Препоръчва се да настроите мониторинг чрез API 120 дни преди крайния срок, за да получите списък с приложения, изискващи актуализация. За приложения с голям обем код, оценката на усилията е от 2 дни до 2 седмици за промени в поведението.

// Проверка на съответствие на 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
    }

    // Проверка на съответствие преди изграждане
    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 проверява съответствието на targetSdk преди изграждане. Методът validateCompliance връща списък с предупреждения за необходими промени в поведението за дадения targetSdk. Използвайте такъв код в CI/CD за автоматична проверка на съответствието преди изпращане на билд до 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, към модели, базирани на продукт (ProductDetails вместо SkuDetails), и поддържа Kotlin Coroutines и Flow за асинхронни операции.

Комисионна на Google Play: 30% стандартна, 15% за първите $1 милион приходи годишно (подобно на Apple Small Business Program). След достигане на прага от $1 милион, комисионната се връща на 30% за остатъка от годината. Абонаменти: 30% първата година, 15% от втората година (аналог на App Store). За програмите Google Play Pass — приходите се разпределят на база ангажираност (време на използване на приложението от абонатите на Pass), а не фиксирана комисионна.

AdMob от Google — основният инструмент за рекламна монетизация. Поддържа банерна, междустранична (interstitial), нативна, наградена (rewarded) реклама. Google Analytics за 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) и несъответствие с изискванията за 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, събиращи данни без знанието на потребителя (проследяване на местоположение без съгласие, четене на контакти и 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 издание.