الفلاتر في Google Play

عندما يبحث المستخدم عن تطبيقات لتنزيلها من Google Play أو يتصفّحها، يتم فلترة النتائج بناءً على التطبيقات المتوافقة مع الجهاز. على سبيل المثال، إذا كان التطبيق يتطلب كاميرا، لن يعرض Google Play التطبيق على الأجهزة التي لا تحتوي على كاميرا. تساعد الفلاتر هذه المطوّرين في إدارة توزيع تطبيقاتهم وضمان تقديم أفضل تجربة ممكنة للمستخدمين.

تعتمد التصفية في Google Play على عدة أنواع من البيانات الوصفية للتطبيق وإعدادات الضبط، بما في ذلك بيانات البيان والمكتبات المطلوبة والتبعيات المتعلقة بالبنية وعناصر التحكم في التوزيع المحددة في Google Play Console، مثل الاستهداف الجغرافي والأسعار وغير ذلك.

وتستند فلترة Google Play جزئيًا على بيانات البيان وغيرها من جوانب إطار عمل Android، إلا أنّ سلوكيات الفلترة الفعلية تكون مختلفة عن إطار العمل ولا تكون مرتبطة بمستويات محدَّدة من واجهات برمجة التطبيقات. ويحدّد هذا المستند قواعد الفلترة الحالية التي يستخدمها Google Play.

آلية عمل الفلاتر على Google Play

يستخدم Google Play قيود الفلاتر الموضّحة أدناه لتحديد ما إذا كان سيتم عرض تطبيقك للمستخدم الذي يتصفّح التطبيقات أو يبحث عنها من تطبيق Google Play.

عند تحديد ما إذا كان سيتم عرض تطبيقك أم لا، يتحقّق Google Play من متطلبات الأجهزة والبرامج على الجهاز، بالإضافة إلى مشغّل شبكة الجوّال وموقعه الجغرافي وخصائصه الأخرى. ثم يقارن تلك القيود بالقيود والتبعيات التي تم التعبير عنها من خلال ملف بيان التطبيق وتفاصيل النشر.

إذا كان التطبيق متوافقًا مع الجهاز وفقًا لقواعد التصفية، فسيعرض Google Play التطبيق للمستخدم. وإلا سيخفي Google Play تطبيقك من نتائج البحث والتصفح حسب الفئة، حتى إذا طلب المستخدم التطبيق تحديدًا من خلال النقر على رابط لصفحة في التطبيق يشير مباشرةً إلى رقم تعريف التطبيق في Google Play.

يمكنك استخدام أي مجموعة من الفلاتر المتاحة لتطبيقك. على سبيل المثال، يمكنك ضبط متطلبات minSdkVersion على "4" وضبط smallScreens="false" في التطبيق، ثم عند تحميل التطبيق إلى Google Play، يمكنك استهداف البلدان الأوروبية (مشغِّلي شبكات الجوّال) فقط. وبالتالي، ستمنع فلاتر Google Play التطبيق من توفره على أي جهاز لا يستوفي جميع هذه المتطلبات الثلاثة.

ترتبط جميع قيود الفلترة بإصدار التطبيق ويمكن أن تتغير بين الإصدارات. على سبيل المثال، إذا ثبَّت مستخدم تطبيقك ونشرت تحديثًا يجعل التطبيق غير مرئي للمستخدم، لن يرى المستخدم أنّ هناك تحديثًا متاحًا.

الفلترة على موقع Google Play الإلكتروني

عندما يتصفح المستخدمون موقع Google Play الإلكتروني، يمكنهم الاطّلاع على جميع التطبيقات المنشورة. يقارن موقع Google Play على الويب متطلبات التطبيق بكل جهاز من الأجهزة المسجلة للمستخدم من أجل التوافق، وعلى الرغم من ذلك، يسمح لهم بتثبيت التطبيق فقط إذا كان متوافقًا مع أجهزتهم.

الفلترة استنادًا إلى بيان التطبيق

يتم تشغيل معظم الفلاتر بواسطة عناصر داخل ملف بيان التطبيق، AndroidManifest.xml (على الرغم من أنه ليس كل ما في ملف البيان يمكن أن يؤدي إلى تشغيل الفلترة). يسرد الجدول 1 عناصر البيان التي يجب عليك استخدامها لتشغيل التصفية، ويشرح كيفية عمل التصفية لكل عنصر.

الجدول 1. عناصر البيان التي تؤدي إلى التصفية على Google Play.

عنصر البيان	اسم الفلتر	طريقة العمل
<supports-screens>	حجم الشاشة	يشير التطبيق إلى أحجام الشاشة التي يمكن استخدامها من خلال ضبط سمات العنصر <supports-screens>. وعند نشر التطبيق، يستخدم Google Play هذه السمات لتحديد ما إذا كان سيتم عرض التطبيق للمستخدمين أم لا، بناءً على أحجام شاشات أجهزتهم. بشكل عام، يفترض Google Play أنّ النظام الأساسي على الجهاز يمكنه تكييف التنسيقات الأصغر حجمًا مع الشاشات الأكبر حجمًا، ولكن لا يمكنه تعديل التنسيقات الأكبر حجمًا مع الشاشات الأصغر حجمًا. وبالتالي، إذا أعلن تطبيق عن توافقه مع حجم الشاشة "العادي" فقط، يتيح Google Play التطبيق لكل من الأجهزة ذات الشاشات العادية والكبيرة، ولكنه تتم فلترة التطبيق بحيث لا يكون متاحًا للأجهزة ذات الشاشات الصغيرة. إذا لم يعلن أحد التطبيقات عن سمات لـ <supports-screens>، يستخدم Google Play القيم التلقائية لتلك السمات، والتي تختلف حسب مستوى واجهة برمجة التطبيقات. ونخصّ بالذكر الشرط التالي: بالنسبة إلى التطبيقات التي تضبط android: minSdkVersion أو android: targetSdkVersion على 3 أو أقل، يكون العنصر <supports-screens> نفسه غير محدّد ولا تتوفّر أي سمات. في هذه الحالة، يفترض Google Play أنّ التطبيق مصمّمًا للشاشات ذات الحجم العادي ويعرض التطبيق على الأجهزة التي تحتوي على شاشات عادية أو أكبر. وعند ضبط السمة android: minSdkVersion أو android: targetSdkVersion على 4 أو أعلى، يكون الإعداد التلقائي لكل السمات هو "true". وبهذه الطريقة، يعتبر التطبيق أن التطبيق يدعم جميع أحجام الشاشات بشكل افتراضي. مثال 1 يذكر البيان <uses-sdk android:minSdkVersion="3"> ولا يتضمّن عنصر <supports-screens>. النتيجة: لن يعرض Google Play التطبيق لمستخدم على جهاز ذي شاشة صغيرة، ولكنّه سيعرضه لمستخدمي الأجهزة العادية والكبيرة ما لم يتم تطبيق فلاتر أخرى. المثال 2 يضم البيان <uses-sdk android:minSdkVersion="3" android:targetSdkVersion="4"> ولا يتضمن عنصر <supports-screens>. النتيجة: سيعرض Google Play التطبيق للمستخدمين على جميع الأجهزة، ما لم يتم تطبيق فلاتر أخرى عليه. المثال 3 يضم البيان <uses-sdk android:minSdkVersion="4"> ولا يتضمن عنصر <supports-screens>. النتيجة: سيعرض Google Play التطبيق لجميع المستخدمين، ما لم يتم تطبيق فلاتر أخرى عليه. لمزيد من المعلومات حول طريقة تعريف التوافق مع أحجام الشاشات في تطبيقك، يمكنك الاطّلاع على <supports-screens> وإتاحة الشاشات المتعددة.
<uses-configuration>	إعدادات الجهاز: لوحة المفاتيح، التنقل، الشاشة التي تعمل باللمس	يمكن للتطبيق طلب ميزات أجهزة معيّنة، وسيعرض Google Play التطبيق فقط على الأجهزة التي تتضمّن الأجهزة المطلوبة. المثال 1 يتضمّن البيان <uses-configuration android:reqFiveWayNav="true" />، ويبحث المستخدم عن تطبيقات على جهاز لا يتضمّن عناصر تحكُّم تنقّل خماسية الاتجاه. النتيجة: لن يعرض Google Play التطبيق للمستخدم. المثال 2 لا يتضمّن البيان عنصر <uses-configuration>. النتيجة: سيعرض Google Play التطبيق لجميع المستخدمين ما لم يتم تطبيق فلاتر أخرى عليه. لمزيد من التفاصيل، يُرجى الاطّلاع على <uses-configuration>.
<uses-feature>	ميزات الجهاز (name)	يمكن أن يتطلب أحد التطبيقات وجود ميزات محددة على الجهاز. تم تقديم هذه الوظيفة في نظام التشغيل Android 2.0 (المستوى 5 من واجهة برمجة التطبيقات). المثال 1 يتضمّن البيان <uses-feature android:name="android.hardware.sensor.light" />، ويبحث أحد المستخدمين عن تطبيقات على جهاز لا يحتوي على أداة استشعار للضوء. النتيجة: لن يعرض Google Play التطبيق للمستخدم. المثال 2 لا يتضمّن البيان عنصرًا <uses-feature>. النتيجة: سيعرض Google Play التطبيق لجميع المستخدمين، ما لم يتم تطبيق فلاتر أخرى عليه. للحصول على المعلومات الكاملة، يُرجى الاطّلاع على <uses-feature> . الفلترة استنادًا إلى الميزات الضمنية: في بعض الحالات، يفسّر Google Play الأذونات التي يتم طلبها من خلال عناصر <uses-permission> على أنّها متطلبات ميزات مكافئة للأذونات التي تم تعريفها في عناصر <uses-feature>. انظر <uses-permission>، أدناه.
	إصدار OpenGL-ES (openGlEsVersion)	قد يتطلّب أحد التطبيقات أن يتوافق الجهاز مع إصدار معيّن من OpenGL-ES باستخدام السمة <uses-feature android:openGlEsVersion="int">. المثال 1 يطلب أحد التطبيقات عدة إصدارات من OpenGL-ES من خلال تحديد openGlEsVersion عدة مرات في البيان. النتيجة: يفترض Google Play أنّ التطبيق يتطلب أعلى الإصدارات المُشار إليها. المثال 2 يطلب أحد التطبيقات الإصدار 1.1 من OpenGL-ES، ويبحث أحد المستخدمين عن تطبيقات على جهاز متوافق مع الإصدار 2.0 من OpenGL-ES. النتيجة: سيعرض Google Play التطبيق للمستخدم ما لم يتم تطبيق فلاتر أخرى عليه. إذا أبلغ أحد الأجهزة عن توافقه مع الإصدار X-ES من OpenGL، يفترض Google Play أنّه يتوافق أيضًا مع أي إصدار أقدم من X. المثال 3 يبحث مستخدم عن تطبيقات على جهاز لا يعرض إصدار OpenGL-ES (على سبيل المثال، جهاز يعمل بالإصدار 1.5 من نظام التشغيل Android أو إصدار أقدم). النتيجة: يفترض Google Play أنّ الجهاز لا يتوافق إلا مع OpenGL-ES 1.0. سيعرض Google Play فقط التطبيقات التي لا تحدّد openGlEsVersion، أو التطبيقات التي لا تحدّد إصدار OpenGL-ES أعلى من 1.0. مثال 4 لا يحدّد البيان السمة openGlEsVersion. النتيجة: سيعرض Google Play التطبيق لجميع المستخدمين ما لم يتم تطبيق فلاتر أخرى عليه. لمزيد من التفاصيل، يُرجى الاطّلاع على <uses-feature>.
<uses-library>	مكتبات البرامج	وقد يتطلّب أحد التطبيقات توفُّر مكتبات مشتركة محدّدة على الجهاز. المثال 1 يتطلب أحد التطبيقات مكتبة com.google.android.maps، ويبحث المستخدم عن تطبيقات على جهاز لا يحتوي على مكتبة com.google.android.maps. النتيجة: لن يعرض Google Play التطبيق للمستخدم. مثال 2 لا يتضمّن البيان عنصر <uses-library>. النتيجة: سيعرض Google Play التطبيق لجميع المستخدمين ما لم يتم تطبيق فلاتر أخرى عليه. لمزيد من التفاصيل، يُرجى الاطّلاع على <uses-library>.
<uses-permission>		على وجه التحديد، لا تتوفر في Google Play أي فلاتر استنادًا إلى عناصر <uses-permission>. ومع ذلك، يقرأ التطبيق العناصر لتحديد ما إذا كان يتضمّن متطلبات ميزات الأجهزة التي ربما لم يتم توضيحها بشكل صحيح في عناصر <uses-feature>. على سبيل المثال، إذا طلب أحد التطبيقات إذن CAMERA ولكنّه لم يعلن عن عنصر <uses-feature> في android.hardware.camera، يعتبر Google Play أنّ التطبيق يتطلّب كاميرا ويجب ألا يظهر للمستخدمين الذين لا توفّر أجهزتهم كاميرا. بشكل عام، إذا طلب تطبيق أذونات تتعلّق بالأجهزة، يفترض Google Play أنّ التطبيق يتطلب ميزات الأجهزة الأساسية، على الرغم من أنه قد لا يكون هناك ما يتوافق مع تعريفات <uses-feature>. وبعد ذلك، تُعِدّ خدمة Google Play الفلترة استنادًا إلى الميزات التي تتضمّنها نماذج البيان <uses-feature>. للحصول على قائمة بالأذونات التي تشير إلى ميزات الأجهزة، راجِع مستندات عنصر <uses-feature>.
<uses-sdk>	الحد الأدنى لإصدار إطار العمل (minSdkVersion)	يمكن أن يتطلب التطبيق حدًا أدنى من مستوى واجهة برمجة التطبيقات. المثال 1 يتضمّن البيان <uses-sdk android:minSdkVersion="3">، ويستخدم التطبيق واجهات برمجة التطبيقات التي تم تقديمها في المستوى 3 من واجهة برمجة التطبيقات. لنفترض أن هناك مستخدمًا يبحث عن تطبيقات على جهاز يحتوي على المستوى 2 من واجهة برمجة التطبيقات. النتيجة: لن يعرض Google Play التطبيق للمستخدم. المثال 2 لا يتضمّن البيان minSdkVersion، ويستخدم التطبيق واجهات برمجة التطبيقات التي تم تقديمها في المستوى 3 من واجهة برمجة التطبيقات. لنفترض أن هناك مستخدمًا يبحث عن تطبيقات على جهاز يحتوي على المستوى 2 من واجهة برمجة التطبيقات. النتيجة: يفترض Google Play أنّ قيمة minSdkVersion هي "1" وأنّ التطبيق متوافق مع جميع إصدارات Android. يعرض Google Play التطبيق للمستخدم ويسمح للمستخدم بتنزيله. يتعطّل التطبيق في وقت التشغيل. بما أنّك تريد تجنُّب هذا السيناريو الثاني، ننصحك بالإعلان عن minSdkVersion دائمًا. لمعرفة التفاصيل، يُرجى الاطّلاع على android:minSdkVersion.
	الحد الأقصى لإصدار إطار العمل (maxSdkVersion)	تمت إزالة هذا العمود. لا يتحقّق الإصدار 2.1 من نظام التشغيل Android والإصدارات الأحدث من السمة maxSdkVersion أو يفرضها، ولن يتم تجميع حزمة تطوير البرامج (SDK) في حال ضبط maxSdkVersion في بيان التطبيق. بالنسبة إلى الأجهزة التي سبق أن تم تجميعها باستخدام maxSdkVersion، سيراعي Google Play هذا الترميز وسيستخدمه في الفلترة. ولا يُنصح بتعريف maxSdkVersion. لمعرفة التفاصيل، يُرجى الاطّلاع على android:maxSdkVersion.

فلاتر البيان المتقدّمة

بالإضافة إلى عناصر البيان في الجدول 1، يمكن لتطبيق Google Play أيضًا فلترة التطبيقات بناءً على عناصر البيان المتقدمة في الجدول 2.

إنّ عناصر البيان هذه والتصفية التي تشغّلها هي لحالات استخدام استثنائية فقط. وقد صممت هذه التطبيقات لأنواع معيّنة من الألعاب العالية الأداء والتطبيقات المشابهة التي تتطلّب عناصر تحكّم صارمة في توزيع التطبيقات. يجب ألا تستخدم معظم التطبيقات هذه الفلاتر مطلقًا.

الجدول 2. عناصر البيان المتقدمة لتصفية Google Play.

عنصر البيان	ملخّص
<compatible-screens>	يُفلتِر Google Play التطبيق إذا لم يتطابق حجم شاشة الجهاز وكثافته مع أي من إعدادات الشاشة (التي يتم توضيحها من خلال عنصر <screen>) في العنصر <compatible-screens>. تنبيه: عادةً، يجب عدم استخدام عنصر البيان هذا. يمكن أن يؤدي استخدام هذا العنصر إلى تقليل قاعدة المستخدمين المحتملة لتطبيقك بشكل كبير، عن طريق استبعاد جميع مجموعات حجم وكثافة الشاشة التي لم تدرجها. وبدلاً من ذلك، يجب استخدام عنصر البيان <supports-screens> (الموضّح أعلاه في الجدول 1) لتفعيل وضع توافق الشاشة لعمليات ضبط الشاشة التي لم يتم أخذها في الحسبان من خلال الموارد البديلة.
<supports-gl-texture>	يعمل Google Play على تصفية التطبيق ما لم يكن الجهاز متوافقًا أيضًا مع تنسيق واحد أو أكثر من تنسيقات ضغط بنية GL التي يدعمها التطبيق.

الفلاتر الأخرى

يستخدم Google Play خصائص التطبيق الأخرى لتحديد ما إذا كان سيتم إظهار أو إخفاء تطبيق لمستخدم معين على جهاز معين، كما هو موضح في الجدول أدناه.

الجدول 3. خصائص التطبيق والنشر التي تؤثر في التصفية على Google Play.

اسم الفلتر	طريقة العمل
حالة النشر	ولن تظهر سوى التطبيقات المنشورة في عمليات البحث والتصفح ضمن Google Play. حتى إذا تم إلغاء نشر تطبيق، يمكن تثبيته إذا كان بإمكان المستخدمين مشاهدته في منطقة "عمليات التنزيل" بين التطبيقات التي اشتروها أو ثبّتها أو تم إلغاء تثبيتها مؤخرًا. وإذا تم تعليق أحد التطبيقات، لن يتمكن المستخدمون من إعادة تثبيته أو تحديثه، حتى إذا ظهر في "عمليات التنزيل".
حالة السعر	قد لا يتمكّن بعض المستخدمين من الاطّلاع على التطبيقات المدفوعة. لعرض التطبيقات المدفوعة، يجب أن يعمل الجهاز بالإصدار 1.1 من نظام التشغيل Android أو إصدار أحدث، وأن يكون في بلد تتوفر فيه التطبيقات المدفوعة. إذا كان الجهاز يحتوي على شريحة SIM، سيحدِّد مشغّل شبكة الجوّال لشريحة SIM ما إذا كانت التطبيقات المدفوعة متاحة. إذا كان الجهاز لا يتضمن شريحة SIM، يتم استخدام عنوان IP الخاص بالجهاز لتحديد ما إذا كان الجهاز في بلد تتوفّر فيه التطبيقات المدفوعة.
استهداف البلدان	عند تحميل تطبيقك إلى Google Play، يمكنك اختيار البلدان التي سيتم توزيع التطبيق فيها ضمن الأسعار والتوزيع. وبعد ذلك، سيكون التطبيق متوفرًا للمستخدمين في البلدان التي تختارها فقط.
بنية وحدة المعالجة المركزية (ABI)	ولا يكون التطبيق الذي يتضمن المكتبات الأصلية التي تستهدف بنية وحدة معالجة مركزية (ARM EABI v7 أو x86 مثلاً) مرئيًا إلا على الأجهزة المتوافقة مع هذه البنية. للحصول على تفاصيل حول NDK واستخدام المكتبات الأصلية، يمكنك مراجعة ما المقصود بـ Android NDK؟
التطبيقات المحمية بالنسخ	لم يعُد Google Play يتيح استخدام ميزة "حماية النسخ" في Play Console، ولم يعُد يعمل على فلترة التطبيقات بناءً عليها. لتأمين تطبيقك، يُرجى استخدام ترخيص التطبيقات بدلاً من ذلك. راجِع استبدال حماية النسخ للحصول على مزيد من المعلومات.

نشر حِزم APK متعددة باستخدام فلاتر مختلفة

تسمح لك بعض فلاتر Google Play المحددة بنشر عدة حِزم APK للتطبيق نفسه، وذلك بهدف توفير حزمة APK مختلفة لتهيئات جهاز مختلفة. على سبيل المثال، إذا كنت تنشئ لعبة فيديو تستخدم أصول رسومات عالية الدقة، يمكنك إنشاء ملفَّي APK يدعم كل منهما تنسيقات مختلفة لضغط الزخرفة. وبهذه الطريقة، يمكنك تقليل حجم ملف APK من خلال تضمين الزخارف المطلوبة لكل تهيئة جهاز. استنادًا إلى توافُق كل جهاز مع تنسيقات ضغط البنية، سيقدّم Google Play له حزمة APK التي أعلنت أنّها تتوافق مع هذا الجهاز.

في الوقت الحالي، لا يسمح لك Google Play بنشر العديد من حِزم APK للتطبيق نفسه إلا عندما توفّر كل حزمة APK فلاتر مختلفة بناءً على الإعدادات التالية:

• تنسيقات ضغط مظهر OpenGL

  باستخدام العنصر <supports-gl-texture>.

• حجم الشاشة (وكثافة الشاشة اختياريًا)

  باستخدام العنصر <supports-screens> أو <compatible-screens>

• مستوى واجهة برمجة التطبيقات

  باستخدام العنصر <uses-sdk>.

• بنية وحدة المعالجة المركزية (ABI)

  من خلال تضمين المكتبات الأصلية التي تم إنشاؤها باستخدام Android NDK والتي تستهدف بنية وحدة معالجة مركزية معيّنة (على سبيل المثال، AM EABI v7 أو x86).

تظل جميع الفلاتر الأخرى تعمل على النحو المعتاد، ولكن هذه الفلاتر الأربعة هي الوحيدة التي يمكنها التمييز بين حزمة APK وحزمة أخرى ضمن بطاقة بيانات التطبيق نفسها على Google Play. على سبيل المثال، لا يمكنك نشر عدة حِزم APK للتطبيق نفسه إذا كانت مختلفة استنادًا إلى ما إذا كان الجهاز يحتوي على كاميرا فقط.

تنبيه: إنّ نشر عدة حِزم APK للتطبيق نفسه يُعَدّ ميزة متقدّمة، ويجب أن ينشر معظم التطبيقات ملف APK واحدًا فقط متوافقًا مع مجموعة واسعة من عمليات ضبط الأجهزة. يتطلب نشر ملفات APK متعددة اتباع قواعد محددة ضمن الفلاتر والتركيز بشكل أكبر على رموز الإصدارات لكل حزمة APK لضمان مسارات التحديث المناسبة لكل إعداد.

إذا كنت بحاجة إلى مزيد من المعلومات حول كيفية نشر عدة ملفات APK على Google Play، يُرجى الاطّلاع على مقالة دعم حِزم APK متعددة.

راجع أيضًا

1. التوافق مع نظام التشغيل Android
2. التوافق مع عدّة حِزم APK