التوافق مع حِزم APK المتعددة

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

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

قد تختلف الأجهزة التي تعمل بنظام التشغيل Android بعدة طرق، ومن المهم لنجاح تطبيقك أن تتيحه على أكبر عدد ممكن من الأجهزة. تعمل تطبيقات Android عادةً على معظم الأجهزة المتوافقة باستخدام ملف APK واحد، وذلك من خلال توفير موارد بديلة لإعدادات مختلفة (مثل تنسيقات مختلفة لمختلف أحجام الشاشات)، ويعمل نظام Android على اختيار الموارد المناسبة للجهاز أثناء التشغيل. في بعض الحالات، يُرجى العِلم أنّ حزمة APK واحدة لا يمكنها إتاحة جميع إعدادات الأجهزة، لأنّه تؤدي الموارد البديلة إلى زيادة حجم حزمة APK بشكل كبير أو تؤدي تحديات فنية أخرى إلى منع حزمة APK واحدة من العمل على جميع الأجهزة.

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

من خلال نشر تطبيقك باستخدام حِزم APK متعددة، يمكنك إجراء ما يلي:

• أن تتيح استخدام صيغ مختلفة لضغط بنية OpenGL مع كل حزمة APK
• أن يكون متوافقًا مع أحجام وكثافات شاشات مختلفة في كل ملف APK
• إتاحة مجموعات ميزات مختلفة للأجهزة مع كل حزمة APK
• أن يكون متوافقًا مع إصدارات مختلفة من النظام الأساسي مع كل حزمة APK
• أن يكون متوافقًا مع بنى مختلفة لوحدة المعالجة المركزية (CPU) مع كل حزمة APK (مثل ARM أو x86، عندما يستخدم تطبيقك مجموعة تطوير البرامج (NDK) من Android)
• تحسين الأداء على الأجهزة المنخفضة المواصفات مثل الأجهزة التي تعمل بنظام Android (إصدار Go)

في الوقت الحالي، هذه هي خصائص الأجهزة الوحيدة التي يتيح Google Play نشر حِزم APK متعددة كتطبيق واحد.

ملاحظة: للتعرّف على كيفية إعداد ونشرملف APK على Google Play، يُرجى الاطّلاع على مقالة الدعم إعداد الإصدارات وطرحها.

آلية عمل حِزم APK المتعدّدة

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

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

الفلاتر المتوافقة

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

• تنسيقات ضغط بنية OpenGL

  ويستند ذلك إلى عناصر <supports-gl-texture> في ملف البيان.

  على سبيل المثال، عند تطوير لعبة تستخدم OpenGL ES، يمكنك توفير حزمة APK واحدة لأجهزة التي تتيح ضغط نسيج ATI وحزمة APK منفصلة للأجهزة التي تتيح ضغط PowerVR (من بين العديد من الأجهزة الأخرى).

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

  ويستند ذلك إلى عنصر <supports-screens> أو <compatible-screens> في ملف البيان. يجب عدم استخدام كلا العنصرَين مطلقًا، ويجب استخدام <supports-screens> فقط كلما أمكن ذلك.

  على سبيل المثال، يمكنك تقديم حزمة APK واحدة متوافقة مع الشاشات الصغيرة والعادية وحزمة APK أخرى متوافقة مع الشاشات الكبيرة والكبيرة جدًا. لمزيد من المعلومات عن إنشاء حِزم APK منفصلة استنادًا إلى حجم الشاشة أو كثافتها، انتقِل إلى إنشاء حِزم APK متعددة.

  ننصحك باتّباع أفضل الممارسات التالية لتوفير التوافق مع جميع أحجام الشاشة:

  • يقدّم نظام Android دعمًا قويًا للتطبيقات من أجل إتاحة جميع إعدادات الشاشة باستخدام حزمة APK واحدة. يجب تجنُّب إنشاء حِزم APK متعددة لتتوافق مع شاشات مختلفة ما لم يكن ذلك ضروريًا تمامًا، والالتزام بدلاً من ذلك بالدليل المتعلق بإتاحة التطبيق على عدة شاشات حتى يكون تطبيقك مرنًا ويمكنه التكيّف مع جميع إعدادات الشاشة باستخدام حزمة APK واحدة.
  • تكون جميع سمات حجم الشاشة في العنصر <supports-screens> تلقائيًا "true" إذا لم يتم تحديد قيمة أخرى لها. ومع ذلك، بما أنّه تمت إضافة سمة android:xlargeScreens في الإصدار 2.3 من نظام التشغيل Android (المستوى 9 لواجهة برمجة التطبيقات)، سيفترض Google Play أنّها "خطأ" إذا لم يضبط تطبيقك قيمة "9" أو أعلى لسمة android:minSdkVersion أو android:targetSdkVersion.
  • يجب عدم دمج كل من العنصرين <supports-screens> و <compatible-screens> في ملف البيان. يؤدي استخدام كليهما إلى زيادة فرص حدوث خطأ بسبب التعارض بينهما. للحصول على مساعدة في تحديد الشاشة التي تريد نشر التطبيق عليها، يُرجى الاطّلاع على مقالة النشر على شاشات محدّدة. إذا لم تتمكّن من تجنُّب استخدام كليهما، يُرجى العِلم أنّه في حال حدوث أي تعارضات في التوافق مع حجم معيّن، سيتم استخدام القيمة "false".

• مجموعات ميزات الجهاز

  ويستند ذلك إلى عناصر <uses-feature> ملف البيان.

  على سبيل المثال، يمكنك تقديم حزمة APK واحدة للأجهزة التي تتيح ميزة اللمس المتعدّد وحزمة APK أخرى للأجهزة التي لا تتيح هذه الميزة. اطّلِع على مرجع ميزات منصّة Google Analytics 4 للحصول على قائمة بالميزات المتوافقة مع المنصة.

• Android (الإصدار Go)

  لاستهداف الأجهزة التي تعمل بنظام Android (إصدار Go)، يجب أن يعلن ملف APK عن <uses-feature android:name="android.hardware.ram.low" android:required="true">، وأن يستهدف المستوى 26 من واجهة برمجة التطبيقات على الأقل، وأن يكون رمز إصداره أعلى من رمز إصدار ملف APK غير المتوافق مع إصدار Go.

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

  ويستند ذلك إلى عنصر <uses-sdk> في ملف البيان. يمكنك استخدام سمتَي android:minSdkVersion وandroid:maxSdkVersion لتحديد مدى توفّر مستويات مختلفة من واجهة برمجة التطبيقات.

  على سبيل المثال، يمكنك نشر تطبيقك باستخدام حزمة APK واحدة متوافقة مع المستويات 16 إلى 19 لواجهة برمجة التطبيقات (Android 4.1.x إلى 4.4.4)، وذلك باستخدام واجهات برمجة التطبيقات المتاحة منذ المستوى 16 لواجهة برمجة التطبيقات أو أقل، وحزمة APK أخرى متوافقة مع المستويات 21 والإصدارات الأحدث لواجهة برمجة التطبيقات (Android 5.0 والإصدارات الأحدث)، وذلك باستخدام واجهات برمجة التطبيقات المتاحة منذ المستوى 21 لواجهة برمجة التطبيقات أو أقل. للتعرّف على كيفية إنشاء حِزم APK منفصلة تستهدف كلّ منها نطاقًا مختلفًا من واجهات برمجة التطبيقات، انتقِل إلى مقالة ضبط أنواع المنتجات.

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

  يجب تجنُّب استخدام android:maxSdkVersion بشكل عام، لأنّه طالما أنّك طوّرت تطبيقك بشكل صحيح باستخدام واجهات برمجة التطبيقات المتاحة للجميع، سيكون دائمًا متوافقًا مع الإصدارات المستقبلية من Android. إذا أردت نشر حزمة APK مختلفة لمستويات أعلى من واجهة برمجة التطبيقات، لن تحتاج إلى تحديد الحد الأقصى للإصدار، لأنّه إذا كان android:minSdkVersion هو "16" في حزمة APK واحدة و"21" في حزمة أخرى، ستتلقّى الأجهزة التي تتوافق مع المستوى 21 من واجهة برمجة التطبيقات أو مستوى أعلى حزمة APK الثانية دائمًا (لأنّ رمز إصدارها أعلى، وفقًا للملاحظة السابقة).



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

  توفّر بعض المكتبات الأصلية حِزمًا منفصلة لأنواع معيّنة من Application Binary Interfaces (ABIs) أو بنية وحدة المعالجة المركزية (CPU). بدلاً من تجميع كل المكتبات المتاحة في حزمة APK واحدة، يمكنك إنشاء حزمة APK منفصلة لكل واجهة ABI وتضمين المكتبات التي تحتاج إليها فقط لتلك الواجهة. لمزيد من المعلومات عن إنشاء حِزم APK منفصلة استنادًا إلى ABI المستهدَف، انتقِل إلى مقالة إنشاء حِزم APK متعددة.

لا يزال يتم تطبيق عناصر البيان الأخرى التي تفعِّل فلاتر Google Play، والتي لم يتم ذكرها أعلاه، على كل حزمة APK كالمعتاد. ومع ذلك، لا يسمح Google Play بنشر حِزم APK منفصلة استنادًا إلى الاختلافات في خصائص الجهاز هذه. وبالتالي، لا يمكنك نشر حِزم APK متعددة إذا كانت الفلاتر المذكورة أعلاه متطابقة لكل حزمة APK (ولكن تختلف حِزم APK استنادًا إلى خصائص أخرى في البيان أو حزمة APK). على سبيل المثال، لا يمكنك تقديم حِزم APK مختلفة تختلف فقط في خصائص <uses-configuration>.

قواعد حِزم APK المتعدّدة

قبل نشر حِزم APK متعددة لتطبيقك، عليك معرفة القواعد التالية:

• يجب أن تتضمّن جميع حِزم APK التي تنشرها للتطبيق نفسه اسم الحِزمة نفسه وأن يتم توقيعها باستخدام مفتاح الشهادة نفسه.
• يجب أن يكون لكل ملف APK رمز إصدار مختلف، يتم تحديده من خلال سمة android:versionCode.
• يجب ألا يتطابق كل ملف APK تمامًا مع الإعدادات المتوافقة مع ملف APK آخر.

  وهذا يعني أنّ كل حزمة APK يجب أن تحدّد توافقًا مختلفًا قليلاً مع أحد فلاتر Google Play المتوافقة (المُدرَجة أعلاه) على الأقل.

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

• لا يمكنك تفعيل حِزمة APK جديدة لها رمز إصدار أقل من رمز إصدار حِزمة APK التي تستبدلها. على سبيل المثال، لنفترض أنّ لديك حزمة APK نشطة لأحجام الشاشة الصغيرة إلى العادية برمز الإصدار 0400، ثم حاول استبدالها بحزمة APK لأحجام الشاشة نفسها برمز الإصدار 0300. يؤدي ذلك إلى ظهور خطأ، لأنّه يعني أنّ مستخدمي ملف APK السابق لن يتمكّنوا من تحديث التطبيق.
• يجب أن يتضمّن ملف APK الذي يتطلّب مستوى أعلى لواجهة برمجة التطبيقات رمز إصدار أعلى.

  لا ينطبق ذلك إلا في الحالتَين التاليتَين: تختلف حِزم APK فقط استنادًا إلى مستويات واجهة برمجة التطبيقات المتوافقة (لا تُميِّز الفلاتر المتوافقة بين حِزم APK) أو عندما تستخدم حِزم APK فلترًا آخر متوافقًا، ولكن يتداخل محتوى حِزم APK ضمن هذا الفلتر.

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

  ملاحظة: لا يهمّ حجم زيادة رمز الإصدار، فما عليه سوى أن يكون أكبر في الإصدار المتوافق مع مستويات أعلى لواجهة برمجة التطبيقات.

  في ما يلي بعض الأمثلة:

  • إذا كان ملف APK الذي حمّلته لمستويات واجهة برمجة التطبيقات 16 والإصدارات الأحدث (Android 4.1.x والإصدارات الأحدث) يتضمّن رمز إصدار هو 0400، يجب أن يكون ملف APK لمستويات واجهة برمجة التطبيقات 21 والإصدارات الأحدث (Android 5.0 والإصدارات الأحدث) هو 0401 أو أكبر. في هذه الحالة، يكون مستوى واجهة برمجة التطبيقات هو الفلتر الوحيد المتوافق المستخدَم، لذا يجب زيادة رموز الإصدارات بما يتوافق مع مستوى توافق واجهة برمجة التطبيقات لكل ملف APK، حتى يتلقّى المستخدمون تحديثًا عند تلقّي تحديث للنظام.
  • إذا كان لديك حِزمة APK واحدة مخصّصة للمستوى 16 لواجهة برمجة التطبيقات (والإصدارات الأحدث) والشاشات الصغيرة وحتى الكبيرة، وحِزمة APK أخرى مخصّصة للمستوى 21 لواجهة برمجة التطبيقات (والإصدارات الأحدث) والشاشات الكبيرة جدًا وحتى الشاشات الكبيرة، يجب زيادة رموز الإصدارات بما يتوافق مع مستويات واجهة برمجة التطبيقات. في هذه الحالة، يتم استخدام فلتر مستوى واجهة برمجة التطبيقات لتمييز كل حزمة APK، ولكن يتم أيضًا استخدام حجم الشاشة. وبما أنّ أحجام الشاشات تتداخل (تتوافق حِزم APK مع الشاشات الكبيرة)، يجب أن تظل رموز الإصدارات مرتبة. يضمن ذلك أنّه إذا تلقّى جهاز شاشة كبيرة تحديثًا للنظام إلى المستوى 21 لواجهة برمجة التطبيقات، سيتلقّى تحديثًا لملف APK الثاني.
  • إذا كان لديك ملف APK مخصّص لمستوى واجهة برمجة التطبيقات 16 (أو إصدار أحدث) و الشاشات الصغيرة أو المتوسطة، وملف APK آخر مخصّص لمستوى واجهة برمجة التطبيقات 21 (أو إصدار أحدث) و الشاشات الكبيرة أو الكبيرة جدًا، ليس من الضروري زيادة رموز الإصدارات وفقًا لمستويات واجهة برمجة التطبيقات. وبما أنّه لا يتوفّر تداخل في فلتر حجم الشاشة، لا تتوفّر أي أجهزة يمكنها الانتقال بين ملفي APK هذين، لذا ليس من الضروري أن تتغيّر رموز الإصدارات من مستوى واجهة برمجة التطبيقات الأدنى إلى مستوى واجهة برمجة التطبيقات الأعلى.
  • إذا كان لديك حزمة APK واحدة مخصّصة للمستوى 16 من واجهة برمجة التطبيقات (أو الإصدارات الأحدث) ومعالجات ARMv7، وحزمة APK أخرى مخصّصة للمستوى 21 من واجهة برمجة التطبيقات (أو الإصدارات الأحدث) ومعالجات ARMv5TE، يجب أن تزداد رموز الإصدارات بما يتناسب مع مستويات واجهة برمجة التطبيقات. في هذه الحالة، يتم استخدام فلتر مستوى واجهة برمجة التطبيقات لتمييز كل حزمة APK، وكذلك بنية وحدة المعالجة المركزية. بما أنّ حزمة APK التي تتضمّن مكتبات ARMv5TE متوافقة مع الأجهزة التي تحتوي على وحدة معالجة مركزية ARMv7، تتداخل حِزم APK في هذه السمة. وبالتالي، يجب أن يكون رمز إصدار حزمة APK المتوافقة مع المستوى 21 من واجهة برمجة التطبيقات والإصدارات الأحدث أعلى. يضمن ذلك أنّ الجهاز الذي يحتوي على وحدة معالجة مركزية ARMv7 والذي يتلقّى تحديثًا للنظام إلى المستوى 21 من واجهة برمجة التطبيقات سيتلقّى تحديثًا لحزمة APK الثانية المصمّمة للمستوى 21 من واجهة برمجة التطبيقات. ومع ذلك، بما أنّ هذا النوع من التحديثات يؤدي إلى استخدام جهاز ARMv7 لحزمة APK لم تتم تحسينها بالكامل لوحدة المعالجة المركزية لهذا الجهاز، عليك توفير حزمة APK لكل من معمارية ARMv5TE وARMv7 في كل مستوى لواجهة برمجة التطبيقات من أجل تحسين أداء التطبيق على كل وحدة معالجة مركزية. ملاحظة: لا ينطبق ذلك إلا عند مقارنة حِزم APK بمكتبتَي ARMv5TE و ARMv7، وليس عند مقارنة المكتبات الأصلية الأخرى.

يؤدي عدم الالتزام بالقواعد أعلاه إلى ظهور خطأ على Google Play Console عند تفعيل حِزم APK، ولن تتمكّن من نشر تطبيقك إلا بعد حلّ الخطأ.

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

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

  ملاحظة: إذا كنت تنشئ حِزم APK منفصلة لمعماريات وحدة المعالجة المركزية المختلفة، يُرجى العِلم أنّ حزمة APK لوحدة المعالجة المركزية ARMv5TE ستتداخل مع حزمة APK لوحدة المعالجة المركزية ARMv7. وهذا يعني أنّه تتوافق حزمة APK المصمّمة لمعالج ARMv5TE مع جهاز ARMv7، ولكن العكس غير صحيح (حزمة APK التي تتضمّن مكتبات ARMv7 فقط لا تتوافق مع جهاز ARMv5TE).

عند حدوث تعارضات كهذه، ستظهر لك رسالة تحذير، ولكن سيظل بإمكانك نشر التطبيق.

إنشاء حِزم APK متعددة

بعد أن تقرّر نشر حِزم APK متعددة، قد تحتاج إلى إنشاء مشاريع Android منفصلة لكل حزمة APK تريد نشرها حتى تتمكّن من تطويرها بشكلٍ مناسب بشكل منفصل. يمكنك إجراء ذلك ببساطة عن طريق تكرار مشروعك الحالي ومنحه اسمًا جديدًا. (بدلاً من ذلك، يمكنك استخدام نظام تصميم يمكنه عرض موارد مختلفة، مثل الملمس، استنادًا إلى إعدادات التصميم).

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

عند إنشاء مشاريع متعددة للتطبيق نفسه، من الجيد تحديد كل مشروع باسم يشير إلى قيود الجهاز التي سيتم فرضها على حزمة APK، حتى تتمكّن من التعرّف عليها بسهولة. على سبيل المثال، قد يكون "HelloWorld_21" اسمًا جيدًا لتطبيق مصمّم للإصدار 21 لواجهة برمجة التطبيقات والإصدارات الأحدث.

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

منح رموز الإصدار

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

طلب رموز الإصدار

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

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

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

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

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

استخدام مخطّط رمز الإصدار

للسماح لملفات APK المختلفة بتحديث رموز إصداراتها بشكل مستقل عن غيرها (مثلاً، عند إصلاح خطأ في ملف APK واحد فقط، لكي لا تحتاج إلى تحديث جميع ملفات APK)، يجب استخدام أسلوب لأرقام الإصدارات يوفر مساحة كافية بين كل ملف APK حتى تتمكّن من زيادة الرمز في ملف واحد بدون الحاجة إلى زيادة رمز في الملفات الأخرى. يجب أيضًا تضمين اسم الإصدار الفعلي في الرمز (أي الإصدار المرئي للمستخدم والمخصّص للعنصر android:versionName)، لكي يكون من السهل عليك ربط رمز الإصدار باسمه.

ملاحظة: عند زيادة رمز إصدار حزمة APK، سيطلب Google Play من مستخدمي الإصدار السابق تحديث التطبيق. وبالتالي، لتجنُّب التحديثات غير الضرورية، يجب عدم زيادة رمز الإصدار لحِزم APK التي لا تشمل تغييرات فعلية.

نقترح استخدام رمز إصدار يتألّف من 7 أرقام على الأقل: الأرقام الصحيحة التي تمثّل الإعدادات المتوافقة تكون في الأرقام ذات الترتيب الأعلى، ويكون اسم الإصدار (من android:versionName) في الأرقام ذات الترتيب الأدنى. على سبيل المثال، عندما يكون اسم إصدار التطبيق هو 3.1.0، ستكون رموز إصدار ملف APK للمستوى 4 لواجهة برمجة التطبيقات وملف APK للمستوى 11 لواجهة برمجة التطبيقات على النحو التالي: 0400310 و1100310 على التوالي. إنّ الرقمين الأولين محجوزان لمستوى واجهة برمجة التطبيقات (4 و11 على التوالي)، والرقمَين الأوسطَين مخصّصان لإما أحجام الشاشة أو تنسيقات نسيج GL (لا يتم استخدامهما في هذه الأمثلة)، والرقمَين الأخيرَين مخصّصان لاسم إصدار التطبيق (3.1.0). يعرض الشكل 1 مثالَين تم تقسيمهما استنادًا إلى إصدار النظام الأساسي (مستوى واجهة برمجة التطبيقات) وحجم الشاشة.

الشكل 1: مخطّط مقترَح لرموز الإصدارات، باستخدام أول رقمَين لمستوى واجهة برمجة التطبيقات، والرقمَين الثاني والثالث لحجم الشاشة الأدنى والقصوى (يشير الرقمان 1 و4 إلى كل حجم من الأحجام الأربعة) أو للإشارة إلى تنسيقات النسيج والأرقام الثلاثة الأخيرة لإصدار التطبيق

هذا المخطّط لرموز الإصدارات هو مجرد اقتراح لكيفية إنشاء نمط قابل للتطوير مع تطور تطبيقك. على وجه التحديد، لا يوضّح هذا المخطّط حلًا لتحديد تنسيقات ضغط النسيج المختلفة. قد يكون أحد الخيارات هو تحديد جدولك الخاص الذي يحدّد عددًا صحيحًا مختلفًا لكل تنسيق من تنسيقات الضغط المختلفة التي يتيحها تطبيقك (على سبيل المثال، قد يتوافق الرقم 1 مع ETC1 والرقم 2 مع ATITC، وما إلى ذلك).

يمكنك استخدام أي مخطّط تريده، ولكن عليك التفكير بعناية في كيفية زيادة رموز الإصدارات المستقبلية لتطبيقك وكيفية تلقّي الأجهزة للتحديثات عند تغيُّر إعدادات الجهاز (على سبيل المثال، بسبب تحديث النظام) أو عند تعديل ملف APK واحد أو عدة ملفات APK لتتوافق مع الإعدادات.