Google Play: ano ito, pag-publish ng app at console ng developer

Ano ang Google Play?

Google Play — ang digital distribution platform mula sa Google na pinagsasama ang tindahan ng app, laro, pelikula, libro, at musika. Inilunsad noong Oktubre 22, 2008 sa ilalim ng pangalang Android Market, pinalitan ng pangalan ang platform sa Google Play noong Marso 2012. Hindi tulad ng App Store mula sa Apple, ang Google Play ay hindi lamang ang channel para sa pag-install ng mga Android app — ang mga gumagamit ay maaaring mag-install ng APK mula sa mga third-party na mapagkukunan (sideloading), gumamit ng mga alternatibong tindahan (Samsung Galaxy Store, Amazon Appstore, F-Droid), ngunit karamihan sa mga gumagamit ay gumagamit ng Google Play.

Ayon sa datos ng Google I/O 2026, ang buwanang audience ng Google Play ay lumalampas sa 2.8 bilyong aktibong gumagamit mula sa 190+ bansa. Ang bilang ng mga available na app — higit sa 3.2 milyon. Ang average na presyo ng app ay mas mababa kaysa sa App Store — maraming developer ang gumagamit ng libreng modelo na may advertising o In-App Purchases. Kasama rin sa Google Play ang mga seksyon para sa mga tablet (Large Screen Apps), Wear OS, Android TV, Android Auto, at Chromebook.

Nag-aalok ang Google Play ng mga natatanging tool para sa Android: Google Play Protect — built-in antivirus na nagsusuri ng bawat app bago at pagkatapos ng pag-install; Android Vitals — analytics ng performance ng app (ANR, crash rate, startup time); Google Play Integrity — API para sa pag-verify ng authenticity ng device at app (kapalit ng SafetyNet Attestation). Ang Play Integrity ay sapilitan para sa mga app na gumagana sa kumpidensyal na data at mga pagbabayad.

Google Play Console: mga kakayahan at pagsasaayos

Google Play Console — ang sentral na tool ng developer para sa pamamahala ng mga app sa Google Play. Available sa play.google.com/console. Upang magsimula, kinakailangan ang isang developer account (isang beses na bayad na $25) at pagpapatunay ng pagkakakilanlan. Ang Play Console ay nagbibigay ng kumpletong ikot ng pamamahala ng app: mula sa pag-upload ng unang AAB hanggang sa analytics ng benta at mga ulat ng crash.

Mga pangunahing seksyon ng Play Console: Dashboard — pangkalahatang estadistika para sa lahat ng app (mga pag-install, pag-alis, crash, rating, kita); Release — pamamahala ng bersyon at mga track (Production, Open Beta, Closed Beta, Internal Testing); Growth — mga tool sa promosyon (Google Ads, Promo Codes, Store Listing Experiments); Quality — Android Vitals (ANR rate, crash rate, startup time, render time); Monetization — pagsasaayos ng mga produkto, subscription, Google Play Pass; Users & Permissions — pamamahala ng access ng team.

Mga track ng pagsubok ng Google Play — pangunahing pagkakaiba mula sa App Store. Internal Testing — hanggang 100 tester, hindi nangangailangan ng review, ang mga update ay nai-publish kaagad. Closed Testing (Alpha) — hanggang 100 tester, nangangailangan ng review. Open Testing (Beta) — walang limitasyong bilang ng mga tester, ang app ay available sa Google Play para sa lahat ng nag-sign up sa pagsubok. Inirerekomenda na i-publish muna ang app sa Internal Testing, pagkatapos sa Closed/Open Beta, at pagkatapos lamang sa Production.

// Google Play Billing Library 6.x — pagsusuri ng subscription
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) {
            // Matagumpay ang pagbili — iproseso ang mga pagbili
            purchases.forEach { purchase ->
                handlePurchase(purchase)
            }
        }
    }

    suspend fun startConnection() {
        billingClient.startConnection(object : BillingClientStateListener {
            override fun onBillingSetupFinished(result: BillingResult) {
                if (result.responseCode == BillingClient.BillingResponseCode.OK) {
                    // Handa nang gamitin ang client
                }
            }
            override fun onBillingServiceDisconnected() {
                // Muling pagkonekta
            }
        })
    }

    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) {
        // Pag-verify ng pagbili sa server
        // 1. Ipadala ang purchaseToken sa iyong server
        // 2. Sine-verify ng server sa pamamagitan ng Google Play Developer API
        // 3. Kung matagumpay — i-unlock ang functionality
        val purchaseToken = purchase.purchaseToken
        val productId = purchase.products.firstOrNull()
        println("Purchase: $productId, Token: $purchaseToken")
    }
}

Ang klase na PlayBillingManager ay nagpapakita ng pagtatrabaho sa Google Play Billing Library 6.x: pagtatatag ng koneksyon sa BillingClient, paghingi ng mga detalye ng produkto (subscription o isang beses na pagbili), pagproseso ng resulta ng pagbili sa pamamagitan ng PurchasesUpdatedListener. Ang pag-verify ay dapat gawin sa server sa pamamagitan ng Google Play Developer API gamit ang purchaseToken — huwag kailanman magtiwala lamang sa lokal na pag-verify, dahil ang pagbili ay maaaring peke.

Proseso ng pag-publish ng app sa Google Play

Pag-publish sa Google Play — multi-stage na proseso na kinabibilangan ng pagpaparehistro ng account, paghahanda ng app, pagsasaayos sa Play Console, pag-upload ng AAB, pagdaan sa pagsusuri, at pag-publish. Kumpara sa App Store, ang proseso ay hindi gaanong pormal: ang Google ay umaasa sa automated na pagsusuri (Play Integrity, pag-scan para sa malware sa pamamagitan ng Google Play Protect), hindi sa manu-manong moderasyon ng bawat app.

Stage 1: Pagpaparehistro ng developer account

Para sa pag-publish, kinakailangan ang isang Google account at pagpaparehistro sa Google Play Console para sa $25 (isang beses na bayad). Pagkatapos ng bayad, kinakailangan ang pagpapatunay ng pagkakakilanlan: pag-upload ng pagkakakilanlan (pasaporte o lisensya sa pagmamaneho) at kumpirmasyon ng address. Ang proseso ng pagpapatunay ay tumatagal mula 24 oras hanggang 2 linggo. Kung walang pagpapatunay, ang app ay hindi mai-publish sa Production track.

Stage 2: Pagbuo ng AAB at pagpuno ng Store Listing

Inirerekomenda ng Google ang format na AAB (Android App Bundle) mula noong Agosto 2021 — ang APK ay hindi na tinatanggap para sa mga bagong app. Pinapayagan ng AAB ang Google Play na makabuo ng mga na-optimize na APK para sa bawat uri ng device (iba't ibang ABI, screen, wika), na binabawasan ang laki ng pag-download ng 15-35%. Ang pagbuo ay ginagawa sa pamamagitan ng Android Studio: Build → Build Bundle(s) / APK(s) → Build Bundle(s). Ang AAB ay nilalagdaan sa pamamagitan ng Play App Signing — iniimbak ng Google ang signing key sa panig nito.

Store Listing — ang pahina ng app sa Google Play: pangalan (50 character), maikling paglalarawan (80 character), buong paglalarawan (4000 character), mga screenshot (minimum 2, hanggang 8; para sa telepono 5", 6.5", para sa tablet 7"+), icon (512x512), featured graphic (1024x500), promo video (YouTube). Ang maikling paglalarawan ay pinakamahalaga para sa paghahanap sa Google Play — ito ay ini-index at ipinapakita sa mga resulta. Ang buong paglalarawan ay ini-index, ngunit hindi gaanong mahalaga para sa paghahanap.

Stage 3: Pagpili ng track at pag-publish

Pagkatapos mag-upload ng AAB, pipili ang developer ng track: Internal Testing (hanggang 100 tester, walang review), Closed Testing (Alpha, hanggang 100 tao, may review), Open Testing (Beta, walang limitasyon, may review) o Production. Inirerekomenda na magsimula sa Internal Testing — subukan sa totoong mga device, pagkatapos ay Closed Testing para sa mas malawak na pag-verify, at pagkatapos lamang — Production. Para sa Open Testing at Production, kinakailangan ng hindi bababa sa 12 oras at 20 tester sa Closed Testing sa nakaraang 14 na araw para sa mga bagong account (patakaran ng Google Play 2024).

Pagkatapos ng pag-publish, lilitaw ang app sa Google Play sa loob ng 1-24 na oras. Ang unang update ay maaaring komprehensibong suriin. Awtomatikong ini-scan ng Google Play ang bawat app para sa malisyosong code sa pamamagitan ng Google Play Protect. Kung may nakitang banta, ang app ay maaaring alisin sa publikasyon at ang developer account ay maaaring i-block.

Mga kinakailangan ng Google Play para sa targetSdkVersion

Google Play ay nagtatakda ng mga sapilitang kinakailangan para sa targetSdkVersion para sa pag-publish at pag-update ng mga app. Bawat taon, tinataasan ng Google ang minimum na targetSdk upang matiyak na ginagamit ng mga app ang pinakabagong mga pagbabago sa pag-uugali ng seguridad. Mula Agosto 2024, ang minimum na targetSdk — API 33; mula Agosto 2025 — API 34; mula Agosto 2026 — API 35 (Android 15).

Ang mga app na hindi nakakatugon sa kinakailangan ay naka-block — hindi maaaring i-publish o i-update. Ang mga nai-publish nang app na may mababang targetSdk ay patuloy na gumagana sa tindahan, ngunit para sa update kailangan itaas ang targetSdk. Nagbabala ang Google Play Console 90 araw bago ang pagtaas ng threshold. Maraming developer ang ipinagpapaliban ang update hanggang sa huling sandali, na lumilikha ng panganib ng pag-block ng app sa kaso ng agarang pag-aayos ng bug.

Ang pagtaas ng targetSdkVersion ay nangangailangan ng pagsusuri ng lahat ng mga pagbabago sa pag-uugali na ipinakilala sa pagitan ng luma at bagong targetSdk. Halimbawa, sa paglipat mula sa API 33 (Android 13) patungo sa API 35 (Android 15) kailangang suriin: Foreground Service Types (API 34) — sapilitang deklarasyon ng uri ng serbisyo sa manifest; Privacy Sandbox (API 35) — mga paghihigpit sa mga advertising identifier; PhotoPicker (API 34+) — pagpapalit ng direktang pag-access sa gallery ng system picker; mga bagong paghihigpit sa background services. Ang bawat pagbabago sa pag-uugali ay maaaring mangailangan ng pagbabago ng code.

Play Console API para sa automation ng pagsusuri

Google Play Developer API (REST) ay nagbibigay-daan sa automation ng pagsusuri ng targetSdk para sa lahat ng app sa account. Ang pamamaraang applications.get ay nagbabalik ng impormasyon tungkol sa targetSdkVersion. Inirerekomenda na mag-set up ng monitoring sa pamamagitan ng API 120 araw bago ang deadline upang makakuha ng listahan ng mga app na nangangailangan ng update. Para sa mga app na may malaking dami ng code, ang pagtatantya ng pagsisikap — mula 2 araw hanggang 2 linggo para sa mga pagbabago sa pag-uugali.

// Pagsusuri ng pagsunod sa targetSdk sa code ng app
import android.os.Build

class TargetSdkCompliance {

    // Minimum na targetSdk na kinakailangan ng Google Play sa 2026
    companion object {
        const val REQUIRED_TARGET_SDK = 35
    }

    // Pagsusuri: kailangan bang iproseso ang behavioural change ng API 34?
    fun checkForegroundServiceTypes(targetSdk: Int): Boolean {
        // Ang Foreground Service Types ay sapilitan para sa targetSdk >= 34
        return targetSdk >= 34
    }

    // Pagsusuri: kailangan bang iproseso ang Privacy Sandbox (API 35)?
    fun checkPrivacySandbox(targetSdk: Int): Boolean {
        return targetSdk >= 35
    }

    // Pagsusuri ng pagsunod bago ang pagbuo
    fun validateCompliance(targetSdk: Int): List<String> {
        val warnings = mutableListOf<String>()

        if (targetSdk < REQUIRED_TARGET_SDK) {
            warnings.add("Ang targetSdk $targetSdk ay mas mababa sa kinakailangang $REQUIRED_TARGET_SDK")
        }

        if (targetSdk >= 34) {
            // Tiyakin na ang lahat ng foreground-service ay may type sa manifest
            warnings.add("Suriin: lahat ng foreground-service ay nagdedeklara ng type sa AndroidManifest.xml")
        }

        if (targetSdk >= 35) {
            warnings.add("Suriin: Privacy Sandbox, mga limitasyon sa Advertising ID")
        }

        return warnings
    }
}

Ang klase na TargetSdkCompliance ay nagsusuri ng pagsunod sa targetSdk bago ang pagbuo. Ang pamamaraang validateCompliance ay nagbabalik ng listahan ng mga babala tungkol sa mga kinakailangang pagbabago sa pag-uugali para sa ibinigay na targetSdk. Gamitin ang naturang code sa CI/CD para sa awtomatikong pagsusuri ng pagsunod bago magpadala ng build sa Google Play Console. Sa IT Sectr, ipinatupad namin ang pagsusuring ito sa CI pagkatapos ma-block ang isa sa mga proyekto dahil sa hindi nakuha na targetSdk.

Pagkakakitaan sa Google Play: In-App Billing, subscription, at AdMob

Pagkakakitaan sa Google Play ay may kasamang ilang modelo: bayad na pag-download, In-App Products (isang beses na pagbili: consumable — pera sa laro; non-consumable — pag-alis ng advertising), subscription (auto-renewable subscriptions sa pamamagitan ng Google Play Billing), advertising (AdMob, Google Ad Manager, third-party network), at Google Play Pass (subscription sa isang pakete ng mga app, ang kita ay hinati sa pagitan ng mga developer batay sa oras ng paggamit).

Google Play Billing Library (kasalukuyang bersyon — 7.x noong 2026) — ang sapilitang tool para sa pagbebenta ng mga digital na produkto sa loob ng app. Ang mga alternatibong sistema ng pagbabayad ay ipinagbabawal para sa mga digital na produkto (exception — South Korea, India, EU Digital Markets Act). Ang Billing Library 7.x ay nangangailangan ng paglipat mula sa mga pagbiling batay sa SKU patungo sa mga modelong batay sa produkto (ProductDetails sa halip na SkuDetails) at sumusuporta sa Kotlin Coroutines at Flow para sa asynchronous na mga operasyon.

Komisyon ng Google Play: 30% standard, 15% para sa unang $1 milyong kita bawat taon (katulad ng Apple Small Business Program). Pagkatapos maabot ang threshold na $1 milyon, ang komisyon ay babalik sa 30% para sa natitirang taon. Subscription: 30% unang taon, 15% mula sa ikalawang taon (katulad ng App Store). Para sa mga programa ng Google Play Pass — ang kita ay ipinamamahagi batay sa engagement (oras ng paggamit ng app ng mga subscriber ng Pass), hindi fixed na komisyon.

Ang AdMob mula sa Google — ang pangunahing tool para sa monetization ng advertising. Sumusuporta sa banner, interstitial, native, at rewarded (may gantimpala) na advertising. Ang Google Analytics para sa Firebase ay isinasama sa AdMob para sa pagsubaybay ng conversion ng advertising sa mga target na aksyon. Mula sa Android 14+ (API 34) kinakailangan ang Google Play Services for Ads 22.0+ at Handling Ad Responses API para sa pagsunod sa Privacy Sandbox. Monetization ng advertising — 0% komisyon — popular na pagpipilian para sa mga libreng app na may malaking audience.

Moderasyon ng Google Play: mga pagsusuri at patakaran

Moderasyon ng Google Play (Google Play Policy Review) ay iba mula sa App Store — ang Google ay umaasa sa automated na pagsusuri at piling manu-manong moderasyon, hindi sa 100% manu-manong pagsusuri ng bawat app. Ang automated na sistema ay nag-scan ng AAB/APK para sa malisyosong code, paglabag sa patakaran (Spyware, Deceptive Behavior, paglabag sa SDK), at hindi pagsunod sa mga kinakailangan sa targetSdk. Kapag may nakitang paglabag, ang app ay maaaring tanggihan o alisin sa publikasyon.

Ang Google Play ay nag-publish ng Developer Program Policies — isang hanay ng mga patakaran na sumasaklaw sa nilalaman, pag-uugali ng app, monetization, at privacy. Mga pangunahing seksyon: Restricted Content (karahasan, poot, ilegal na aktibidad), Deceptive Behavior (maling pahayag, paggaya sa ibang app), Monetization and Ads (tapat na advertising, pagsunod sa patakaran sa IAP), Privacy and Security (pagkolekta ng data, encryption), Store Listing and Promotion (tumpak na paglalarawan, tamang pagkakategorya).

Ang Google ay aktibong lumalaban sa spyware at deceptive SDK. Noong 2024-2025, inalis ng Google ang mahigit 1.5 milyong app na lumalabag sa mga patakaran sa privacy. Espesyal na atensyon — mga SDK na kumokolekta ng data nang walang kaalaman ng gumagamit (pagsubaybay sa lokasyon nang walang pahintulot, pagbabasa ng mga contact at SMS). Bago ang pag-publish, suriin ang mga ginamit na SDK para sa pagsunod sa Google Play Policy — maraming sikat na SDK (halimbawa, ilang advertising network) ang na-block dahil sa paglabag sa patakaran.

Proseso ng apela: kung ang app ay tinanggihan, ang developer ay makakatanggap ng abiso sa Play Console na may dahilan at mga rekomendasyon. Maaaring mag-apela sa pamamagitan ng Play Console → Policy → Appeals. Ang oras ng pagsusuri — hanggang 7 araw. Ang paulit-ulit na paglabag sa parehong patakaran ay humahantong sa babala (strike), tatlong beses na paglabag — sa pag-block ng developer account. Ang pagpapanumbalik ng naka-block na account ay isang napakahirap na proseso, na nangangailangan ng nakasulat na apela at ebidensya ng pag-aayos ng mga paglabag.

Upang mabawasan ang mga panganib: gamitin ang Google Play Integrity API para sa pag-verify ng authenticity ng mga kahilingan, ipatupad ang Data Safety Section (sapilitan mula 2023 — ipahiwatig ang lahat ng nakolektang data at mga layunin ng pagkolekta), suriin ang lahat ng SDK para sa pagsunod sa Developer Program Policies, gamitin ang Play Console Policy Insights para sa pagsubaybay ng mga potensyal na paglabag bago ang pag-publish. Sa pag-develop sa IT Sectr, sinusuri namin ang bawat app sa pamamagitan ng internal testing sa totoong mga device bago ang Production release.