التوافق مع حِزم 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.
• دعم بنيات وحدة معالجة مركزية مختلفة مع كل حزمة 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 واحدة).

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

ويتم تحديد الأجهزة التي تتلقّى كل حزمة 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> "صحيحة" إذا لم تذكرها بطريقة أخرى. ومع ذلك، بما أنّ السمة 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 منفصلة يستهدِف كل منها نطاقًا مختلفًا من واجهات برمجة التطبيقات، انتقِل إلى إعداد نماذج المنتجات.

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

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



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

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

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

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

  • إذا كان رمز الإصدار 0400 الذي حمّلته لمستويات واجهة برمجة التطبيقات 16 والمستويات الأعلى (Android 4.1.x+ ) يتضمّن رمز الإصدار 0400، يجب أن يكون رمز الإصدار 0401 أو الإصدارات الأحدث من حزمة APK للمستويات 21 لواجهة برمجة التطبيقات والإصدارات الأحدث (Android 5.0 والإصدارات الأحدث). في هذه الحالة، يكون مستوى واجهة برمجة التطبيقات هو الفلتر الوحيد المتوافق، لذلك يجب أن تزداد رموز الإصدار بشكل مرتبط بمستوى التوافق مع مستوى واجهة برمجة التطبيقات لكل حزمة APK، وذلك لكي يتم تحديث المستخدمين عند تلقّي تحديث للنظام.
  • إذا كان لديك حزمة APK واحدة مخصّصة للمستوى 16 لواجهة برمجة التطبيقات (والمستويات الأعلى) والشاشات الصغيرة والكبيرة، وحزمة APK أخرى من المستوى 21 لواجهة برمجة التطبيقات (والمستويات الأعلى) وكذلك للشاشات الكبيرة الحجم، يجب أن تزداد رموز الإصدار بالنسبة إلى مستويات واجهة برمجة التطبيقات. في هذه الحالة، يتم استخدام فلتر على مستوى واجهة برمجة التطبيقات لتمييز كل حزمة APK، وكذلك حجم الشاشة. نظرًا لأن أحجام الشاشات تتداخل (تتوافق كل من ملفات APK مع الشاشات الكبيرة)، يجب أن تظل رموز الإصدار بالترتيب. وهذا يضمن أنّ الجهاز ذي الشاشة الكبيرة الذي يتلقّى تحديثًا للنظام إلى المستوى 21 من واجهة برمجة التطبيقات سيتلقّى تحديثًا لملف APK الثاني.
  • إذا كان لديك ملف APK واحد للمستوى 16 من واجهة برمجة التطبيقات (والمستويات الأعلى) وكذلك إلى شاشات صغيرة عادية وأخرى صغيرة، وحزمة APK أخرى من المستوى 21 لواجهة برمجة التطبيقات (والمستويات الأعلى) وكذلك للشاشات الكبيرة الحجم الكبيرة، يعني ذلك أنّ رموز الإصدار لن تحتاج إلى زيادتها بالارتباط مع مستويات واجهة برمجة التطبيقات. وبسبب عدم حدوث تداخل في فلتر حجم الشاشة، ما مِن أجهزة من المحتمل أن تتنقل بين حزمتَي APK هاتين، وبالتالي لا حاجة إلى زيادة رموز الإصدار من المستوى الأدنى لواجهة برمجة التطبيقات إلى المستوى الأعلى من واجهة برمجة التطبيقات.
  • إذا كان لديك حزمة APK واحدة مخصّصة من المستوى 16 لواجهة برمجة التطبيقات (والمستويات الأعلى) ووحدات المعالجة المركزية ARMv7، وحزمة APK أخرى من المستوى 21 لواجهة برمجة التطبيقات (والمستويات الأعلى) ووحدات معالجة مركزية (CPU) من نوع ARMv5TE، من المفترض أن تزداد رموز الإصدار بالارتباط مع مستويات واجهة برمجة التطبيقات. في هذه الحالة، يتم استخدام فلتر مستوى واجهة برمجة التطبيقات لتمييز كل حزمة APK، وكذلك الحال بالنسبة إلى بنية وحدة المعالجة المركزية. تتداخل حِزم APK مع مكتبات ARMv5TE مع الأجهزة التي تحتوي على وحدة معالجة مركزية (CPU) من خلال ARMv7، وبالتالي فإنّ هذه الميزة تتداخل مع حِزم APK. وبالتالي، يجب أن يكون رمز إصدار ملف APK الذي يتوافق مع المستوى 21 من واجهة برمجة التطبيقات والإصدارات الأحدث أعلى منه. وهذا يضمن أنّ الجهاز المزوَّد بوحدة معالجة مركزية (CPU) ARMv7 ويتلقى تحديثًا للنظام إلى المستوى 21 من واجهة برمجة التطبيقات سيتلقّى تحديثًا لحزمة APK الثانية المصمّمة للمستوى 21 من واجهة برمجة التطبيقات. ومع ذلك، بما أنّ هذا النوع من التحديث ينتج عنه استخدام جهاز ARMv7 باستخدام حزمة APK لم يتم تحسينها بالكامل لوحدة المعالجة المركزية (CPU) لهذا الجهاز، يجب توفير 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 لنظام التشغيل ARMv5. وهذا يعني أنّ حزمة 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 الحالية إلى حزمة 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 من المستوى 11 على الشكل التالي 0400310 و1100310 على التوالي. يتم الاحتفاظ بالرقمين الأولين لمستوى واجهة برمجة التطبيقات (4 و11 على التوالي)، بينما يشير الرقمان الأوسطان إلى أحجام الشاشة أو تنسيقات زخرفة GL (غير مستخدمة في هذه الأمثلة)، والأرقام الثلاثة الأخيرة مخصصة لاسم إصدار التطبيق (3.1.0). يوضح الشكل 1 مثالين يتم تقسيمهما بناءً على إصدار النظام الأساسي (مستوى واجهة برمجة التطبيقات) وحجم الشاشة.

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

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

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