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 — واجهة برمجية للتحقق من صحة الجهاز والتطبيق (بديل 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 ساعة إلى أسبوعين. بدون التحقق، لن يُنشر التطبيق في مسار 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+) — استبدال الوصول المباشر للمعرض بمنتقي النظام؛ قيود جديدة على الخدمات الخلفية. كل تغيير سلوك قد يتطلب تغييرات في الكود.

API Play Console لأتمتة الامتثال

Google Play Developer API (REST) تسمح بأتمتة فحص الامتثال لـ targetSdk لجميع التطبيقات في الحساب. طريقة applications.get تُرجع معلومات targetSdkVersion. يُنصح بإعداد مراقبة عبر API قبل 120 يوماً من الموعد النهائي للحصول على قائمة التطبيقات التي تحتاج تحديثاً. للتطبيقات ذات قاعدة الكود الكبيرة، الجهد المقدر من يومين إلى أسبوعين لتغييرات السلوك.

// فحص الامتثال targetSdk في كود التطبيق
import android.os.Build

class TargetSdkCompliance {

    // الحد الأدنى targetSdk المطلوب من Google Play في 2026
    companion object {
        const val REQUIRED_TARGET_SDK = 35
    }

    // فحص: هل نحتاج لمعالجة تغيير سلوك 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) {
            // تأكد من أن جميع الخدمات الأمامية لها نوع مُعلن في البيان
            warnings.add("تحقق: جميع الخدمات الأمامية تُعلن عن نوع في 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: الفواتير داخل التطبيق، الاشتراكات و AdMob

الربح في Google Play يشمل عدة نماذج: تحميل مدفوع، منتجات داخل التطبيق (مشتريات لمرة واحدة: قابلة للاستهلاك — عملة اللعبة؛ غير قابلة للاستهلاك — إزالة الإعلانات)، اشتراكات (اشتراكات متجددة تلقائياً عبر Google Play Billing)، إعلانات (AdMob، Google Ad Manager، شبكات خارجية) و Google Play Pass (اشتراك في حزمة تطبيقات، يُوزع الدخل بين المطورين حسب وقت الاستخدام).

Google Play Billing Library (الإصدار الحالي — 7.x في 2026) هي الأداة الإلزامية لبيع السلع الرقمية داخل التطبيق. أنظمة الدفع البديلة محظورة للسلع الرقمية (استثناء — كوريا الجنوبية، الهند، قانون الأسواق الرقمية للاتحاد الأوروبي). Billing Library 7.x تتطلب الترحيل من المشتريات القائمة على SKU إلى نماذج قائمة على المنتج (ProductDetails بدلاً من SkuDetails) وتدعم Kotlin Coroutines و Flow للعمليات غير المتزامنة.

عمولة Google Play: 30% قياسية، 15% لأول $1 مليون إيراد سنوياً (مشابه لبرنامج الأعمال الصغيرة من Apple). بعد الوصول إلى حد $1 مليون، تعود العمولة إلى 30% لبقية العام. الاشتراكات: 30% السنة الأولى، 15% اعتباراً من السنة الثانية (مشابه لـ App Store). لبرامج Google Play Pass — يُوزع الدخل بناءً على المشاركة (وقت استخدام المشتركين Pass للتطبيق)، وليس عمولة ثابتة.

AdMob من Google هي الأداة الرئيسية للربح من الإعلانات. تدعم الإعلانات اللوحية، البينية، الأصلية والمكافأة. 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) وعدم الامتثال لمتطلبات targetSdk. عند اكتشاف انتهاك، قد يُرفض التطبيق أو يُحذف من النشر.

تنشر Google Play Developer Program Policies — مجموعة قواعد تغطي المحتوى، سلوك التطبيق، الربح والخصوصية. الأقسام الرئيسية: Restricted Content (عنف، كراهية، نشاط غير قانوني)، Deceptive Behavior (ادعاءات كاذبة، تقليد تطبيقات أخرى)، Monetization and Ads (إعلانات صادقة، الامتثال لسياسة المشتريات داخل التطبيق)، Privacy and Security (جمع البيانات، التشفير)، Store Listing and Promotion (وصف دقيق، تصنيف صحيح).

تحارب Google بنشاط برامج التجسس و SDK الخادعة. في 2024-2025، أزالت Google أكثر من 1.5 مليون تطبيق ينتهك سياسات الخصوصية. اهتمام خاص — SDK التي تجمع البيانات دون علم المستخدم (تتبع الموقع دون موافقة، قراءة جهات الاتصال والرسائل النصية). قبل النشر، تحقق من SDK التي تستخدمها للامتثال لسياسات Google Play — العديد من SDK الشائعة (مثل بعض شبكات الإعلانات) تم حظرها لانتهاك السياسات.

عملية الاستئناف: إذا رُفض التطبيق، يتلقى المطور إشعاراً في Play Console مع السبب والتوصيات. يمكن تقديم استئناف عبر Play Console → Policy → Appeals. مدة المراجعة — حتى 7 أيام. الانتهاكات المتكررة لنفس السياسة تؤدي إلى تحذير (strike)، الانتهاك الثالث يؤدي إلى تعليق حساب المطور. استعادة حساب معلق هي عملية صعبة للغاية تتطلب استئنافاً كتابياً وأدلة على تصحيح الانتهاكات.

لتقليل المخاطر: استخدم Google Play Integrity API للتحقق من صحة الطلبات، طبق قسم أمان البيانات (إلزامي منذ 2023 — حدد جميع البيانات المجمعة وأغراض الجمع)، تحقق من جميع SDK للامتثال لسياسات برنامج المطورين، استخدم Play Console Policy Insights لتتبع الانتهاكات المحتملة قبل النشر. عند التطوير في IT Sectr، نختبر كل تطبيق عبر الاختبار الداخلي على أجهزة حقيقية قبل إصدار Production.