التوافق مع حِزم 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، عندما يستخدم تطبيقك Android NDK)
• حسِّنها للأجهزة المبتدئة مثل الأجهزة التي تعمل بنظام التشغيل 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 واحدة).

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

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

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

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

• نظام التشغيل 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 منفصلة يستهدِف كل منها نطاقًا مختلفًا من واجهات برمجة التطبيقات، يُرجى الانتقال إلى Configure Product Flavors (إعداد نكهات المنتجات).

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

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



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

  توفّر بعض المكتبات الأصلية حزمًا منفصلة لبُنى وحدة معالجة مركزية محددة أو واجهات تطبيقات ثنائية (ABIs). وبدلاً من جمع كل المكتبات المتاحة في حزمة APK واحدة، يمكنك إنشاء حزمة APK منفصلة لكل واجهة تطبيق ABI وتضمين المكتبات التي تحتاجها فقط لواجهة التطبيق الثنائية (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 ضمن هذا الفلتر.

  هذه الخطوة مهمة لأنّ جهاز المستخدم لا يتلقّى تحديثًا للتطبيق من 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 من المستوى 21 (والمستويات الأعلى) ووحدات المعالجة المركزية ARMv5TE، من المفترض أن تزداد رموز الإصدار في ما يتعلّق بمستويات واجهة برمجة التطبيقات. في هذه الحالة، يتم استخدام فلتر مستوى واجهة برمجة التطبيقات للتمييز بين كل حزمة APK، وكذلك بنية وحدة المعالجة المركزية. بما أنّ حِزمة APK مع مكتبات ARMv5TE غير متوافقة مع الأجهزة المزوَّدة بوحدة معالجة مركزية (CPU) ARMv7، تتداخل حِزم APK مع هذه الخاصية. وبالتالي، يجب أن يكون رمز إصدار ملف APK الذي يتوافق مع المستوى 21 من واجهة برمجة التطبيقات والمستويات الأعلى أعلى. وهذا يضمن أنّ الجهاز المزوّد بوحدة معالجة مركزية (CPU) 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 لـ ARMv5TE ستتداخل مع حزمة APK للطراز ARMv7. وهذا يعني أنّ حزمة APK المصمّمة لـ ARMv5TE متوافقة مع أجهزة ARMv5TE، ولكن العكس ليس صحيحًا (فحِزم 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 مختلفة استنادًا إلى حجم الشاشة، مثلاً ملف APK صغير - عادي والآخر كبير - كبير جدًا، ولكن توقع وقتًا تريد فيه تغيير حِزم APK إلى صغيرة وأخرى للأحجام الصغيرة وواحدة للأحجام العادية - الكبيرة، لذا يجب جعل رمز الإصدار لحزمة APK الكبيرة والكبيرة أعلى. بهذه الطريقة، سيتلقّى الجهاز ذو الحجم العادي التحديث المناسب عند إجراء التغيير، لأنّ رمز الإصدار يرتفع من حزمة APK الحالية إلى حزمة APK الجديدة التي أصبحت متوافقة مع الجهاز.

وكذلك، عند إنشاء عدة حِزم APK تختلف استنادًا إلى التوافق مع تنسيقات ضغط زخرفة OpenGL المختلفة، يُرجى العلم بأنّ العديد من الأجهزة تتوافق مع تنسيقات متعددة. نظرًا لأنّ الجهاز يتلقّى ملف 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.