دعم ملفات APK متعددة

الإعلانات

دعم ملفات APK متعددة

 

 

دعم ملفات APK متعدده هي ميزة على قوقل بلاي، تتيح لك نشر ملفات APK مختلفة لتطبيقك والتي يستهدف كلٍ منها تكوينات مختلفة للأجهزة.

يُعد كل ملف APK إصدار كامل ومستقل من تطبيقك، ولكنهم يتشاركون في قائمة التطبيقات نفسها على قوقل بلي..

ويجب أن يتشاركوا اسم الحزمة نفسه وأن يتم توقيعهم بإستخدام نفس مفتاح الإصدار.

هذه الميزة مفيدة للحالات التي لا يمكن لتطبيقك الوصول فيها إلى جميع الأجهزة المطلوبة بإستخدام ملف APK واحد.

قد تختلف الأجهزة التي تعمل بنظام الأندرويد من عدة نواحي، ومن المهم لنجاح تطبيقك أن تجعله متاحاً لأكبر عدد ممكن من الأجهزة.

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

للتكوينات المختلفة (مثل، مخططات مختلفة لأحجام مختلفة من الشاشة)..

ويقوم نظام الأندرويد بإختيار المصادر المناسبة للجهاز أثناء التشغيل.

مع ذلك، في حالات قليلة، يتعذر على ملف APK الواحد دعم كافة تكوينات الجهاز..

لأن المصادر البديله تجعل ملف APK أكبر من اللازم أو أي تحديات فنية أخرى تمنع ملف APK الواحد من العمل على جميع الأجهزة.

لمساعدتك في نشر تطبيقك على أكبر عدد ممكن من الأجهزة، يتيح لك قوقل بلي نشر ملفات APK المتعدده ضمن قائمة التطبيقات نفسها.

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

من خلال نشر تطبيقك بإستخدام ملفات APK متعدده، يمكنك:

  • دعم صيغ ضغط بنية OpenGL مختلفة مع كل ملف APK.
  • دعم أحجام وكثافات مختلفة للشاشه مع كل ملف APK.
  • دعم مجموعات خصائص مختلفة للجهاز مع كل ملف APK.
  • دعم إصدارات مختلفة من الأنظمة الأساسية مع كل ملف APK.
  • دعم بنى CPU “وحدة المعالجة المركزية” مختلفة مع كل ملف APK (مثل معالجات ARM أو معالجات x86 ..

عندما يستخدم تطبيقك أدوات تطوير برمجيات الأندرويد NDK).

  • تحسين الأجهزة ذات الفئات بالمستوى الأقل مثل الأجهزة التي تعمل بنظام أندرويد (إصدار Go).

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

ملاحظة: للتعرف على إعداد ونشر ملفات APK على قوقل بلي، أطلع على مقالة الدعم حول إعداد ونشر التطبيق.

 

 

 

 

كيف تعمل ملفات APK المتعددة


يتمثل مفهوم إستخدام ملفات APK المتعددة على قوقل بلي، في أنه لديك إدخالاً واحداً فقط لتطبيقك في قوقل بلي..

ولكن قد تقوم أجهزة مختلفة بتنزيل ملف APK مختلف. وهذا يعني أن: 

  • أنك تحتفظ بمجموعة واحدة فقط من تفاصيل المنتج (وصف التطبيق، الأيقونات، لقطات الشاشة، وما إلى ذلك).

وهذا يعني أيضاً أنه لا يمكنك فرض سعر مختلف لملفات APK المختلفة.

  • لا يرى جميع المستخدمين سوى إصدار واحد من تطبيقك على قوقل بلي، لذلك لا يتم الخلط بينه وبين..

الإصدارات المختلفة التي قد تكون نشرتها “للأجهزة اللوحية” أو “للهواتف”.

  • يتم تطبيق جميع آراء المستخدمين على قائمة التطبيقات نفسها..

على الرغم من أن المستخدمين قد يكون لديهم أجهزة مختلفة و ملفات APK مختلفة.

  • إذا نشرت ملفات APK مختلفة لإصدارات مختلفة من الأندرويد (لمستويات مختلفة من واجهة برمجة التطبيقات)..

فعندما يتلقى جهاز المستخدم تحديثاً للنظام يؤهله لملف APK مختلف قمت بنشره، يعمل قوقل بلي على تحديث تطبيق المستخدم..

إلى ملف APK المصمم للإصدار الأعلى من الأندرويد. يتم الإحتفاظ بأي بيانات للنظام مرتبطة بالتطبيق (تماماً مثل تحديثات التطبيق العادية عند إستخدام ملف APK واحد).

 

 

 

 

المرشحات المدعومة


يتم تحديد الأجهزة التي تستلم الملف المناسب لها من ملفات APK من خلال مرشحات قوقل بلي المحددة بواسطة العناصر في ملف الإيضاح لكل ملف APK.

مع ذلك، يتيح لك قوقل بلي نشر عدة ملفات APK فقط عندما يستخدم كل ملف APK مرشحات تدعم شكل مختلف من خصائص الجهاز التالية:

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

هذا يعتمد على عنصر (عناصر) ملف إيضاحك <supports-gl-texture>.

مثال، عند تطوير لعبة تستخدم مكتبة OpenGL ES، يمكنك توفير ملف APK واحد للأجهزة التي تدعم..

كرت الشاشة ATI وملف APK منفصل للأجهزة التي تدعم معالج الرسوميات PowerVR (من بين العديد من الأجهزة الأخرى).

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

يعتمد هذا على عناصر ملف إيضاحك <supports-screens> أو <compatible-screens>.

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

مثال، يمكنك توفير ملف APK يدعم الشاشات ذات الحجم الصغير والمتوسط و ملف APK آخر يدعم الشاشات ذات الحجم الكبير والأكبر.

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

 

ضع في إعتبارك أفضل الممارسات التالية لدعم جميع أحجام الشاشات:

  • يوفر نظام الأندرويد دعماً قوياً للتطبيقات، لتدعم كافة تكوينات الشاشة بإستخدام ملف APK واحد.

يجب تجنب إنشاء ملفات APK متعددة لدعم الشاشات المختلفة، ما لم يكن ذلك ضرورياً تماماً.

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

  • بشكلٍ إفتراضي، جميع سمات حجم الشاشة في عنصر <supports-screens> تأخذ القيمة “صحيح” إذا لم تقم بالإعلان عنها بخلاف ذلك. مع ذلك، لأنه تمت إضافة سمة

android:xlargeScreens في أندرويد 2.3 (مستوى API 9)، سيفترض قوقل بلي بأنها تأخذ القيمه “خطأ” إذا لم يضبط تطبيقك android:minSdkVersion أو android:targetSdkVersion إلى الإصدار “9” أو أعلى.

  • يجب عليك ألا تدمج عنصري <supports-screens> و <compatible-screens> في ملف إيضاحك. إستخدام كلاهما يزيد من فرص حدوث خطأ بسبب تعارضهما.

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

فكن على دراية بأنه في حالة وجود أي تعارض في الإتفاقيه بين الحجم المعطى، فإن القيمة ستكون “خطأ”.

 

 

 

دعم ملفات apk

 

مجموعات خصائص الجهاز


هذا يعتمد على عنصر (عناصر) ملف إيضاحك <uses-feature>.

مثال، يمكنك توفير ملف APK واحد للأجهزة التي تدعم اللمس المتعدد وملف APK آخر للأجهزة التي لا تدعم اللمس المتعدد.

اقرأ مرجع الخصائص للحصول على قائمة بالخصائص التي يدعمها النظام الأساسي.

 

 

أندرويد (إصدار Go)

لإستهداف الأجهزة التي تعمل بنظام الأندرويد (الإصدار Go)، يجب أن يعلن ملفك APK عن،

<"uses-feature android:name="android.hardware.ram.low" android:required="true>

يستهدف المستوى API 26 على الأقل، وأن يكون لديك كود إصدار أعلى من إصدار APK ليس إصدار GO.

 

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

يعتمد هذا على العنصر <uses-sdk> في ملف إيضاحك. يمكنك إستخدام كل من

android:minSdkVersion و android:maxSdkVersion لتحديد الدعم لمستويات واجهة برمجة التطبيقات المختلفة.

 

مثال، يمكنك نشر تطبيقك بإستخدام ملف APK واحد يدعم مستويات واجهة برمجة التطبيقات من المستوى 16 إلى المستوى 19 (أندرويد 4.1.x – 4.4.4)..

يستخدم فقط واجهات برمجة التطبيقات المتاحة منذ المستوى 16 أو أقل — وملف APK آخر يدعم مستويات API 21 فما فوق (أندرويد 5.0 +) ..

يستخدم واجهات برمجة التطبيقات المتاحة منذ مستوى API 21 أو أقل. دعم ملفات APK متعددة

لمعرفة كيفية إنشاء ملفات APK منفصلة كل منها يستهدف نطاق مختلف من واجهات برمجة التطبيقات، انتقل إلى تكوين نكهات المنتجات.

 

إذا كنت تستخدم هذه الخاصية كعامل للتمييز بين عدة ملفات APK، فإن ملف APK الذي يحتوي على قيمة أعلى

لـ android:minSdkVersion يجب أن يحتوي على قيمة أعلى لـandroid:versionCode.

وينطبق هذا أيضاً إذا تداخل ملفي APK على دعم أجهزتهما بناءً على مرشح مدعوم مختلف.

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

تم توضيح هذا المطلب بشكلٍ أكبر في القسم أدناه الذي يناقش قواعد تعدد ملفات APK.

بصفة عامه، ينبغي عليك تجنب إستخدام android:maxSdkVersion

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

إذا كنت تريد نشر ملف APK مختلف للمستويات الأعلى من واجهة برمجة التطبيقات..

فلا تزال لا تحتاج إلى تحديد الحد الأقصى للإصدار، لأنه إذا كان إصدار android:minSdkVersion هو “16” لأحد ملفات APK و “21” لملف آخر..

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

 

 

بنية وحدة المعالجة المركزية ( واجهة التطبيق الثنائيه ABI)

توفر بعض المكتبات الأصلية حزم منفصلة لبنى وحدة المعالجة المركزية المحددة أو واجهات التطبيق الثنائية (ABIs).

بدلاً من حزم جميع المكتبات المتاحة في ملف APK واحد، يمكنك إنشاء ملف APK مستقل لكل واجهة تطبيق ثنائيه ABI وفقط تضمين المكتبات التي تحتاج إليها لواجهة التطبيق الثنائية تلك.

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

عناصر الإيضاح الأخرى التي تقوم بتمكين مرشحات قوقل بلي – ولكنها غير مدرجة أعلاه – لا تزال تنطبق على كل ملف APK كالمعتاد.

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

وبالتالي لا يمكنك نشر عدة ملفات APK إذا كانت المرشحات المدرجة أعلاه هي نفسها لكل ملفات APK (ولكن ملفات APK تختلف بناءً على خصائص أخرى في ملف الإيضاح أو في ملف APK).

مثال، لا يمكنك تقديم ملفات APK مختلفة كلياً عن خصائص <uses-configuration>. 

 

 

 

دعم ملفات apk

 

قواعد لملفات APK المتعددة


قبل نشر عدة ملفات APK لتطبيقك، يجب عليك أن تفهم القواعد التالية:

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

أي أن كل ملف APK يجب أن يعلن عن دعم مختلف قليلاً، على الأقل لواحد من مرشحات قوقل بلي المعتمدة (المذكورة أعلاه).

عادة، ستقوم بتمييز ملفات APK الخاصة بك بناءً على خاصية معينة (مثل صيغ ضغط التراكيب المدعومة)..

وبالتالي ، فإن كل APK سيعلن عن دعمه لأجهزة مختلفة. ومع ذلك، لا بأس من نشر عدة ملفات APK تتداخل قليلاً مع دعمها.

عند تداخل ملفي APK (يدعمان بعض إعدادات الجهاز نفسها)، الجهاز الذي يقع ضمن نطاق التداخل سوف يتلقى ملف الـ APK برمز إصدار أعلى (محدد بواسطة android:versionCode).

  • لا يمكنك تنشيط ملف APK جديد يحتوي على رمز إصدار أقل من رمز ملف APK الذي يستبدله.

مثال، لنفترض أن لديك ملف APK نشطًا لأحجام الشاشة “الصغيرة – العادية” مع رمز الإصدار 0400..

ثم حاولت إستبداله بنسخة APK لأحجام الشاشات نفسها مع رمز الإصدار 0300. سيتسبب هذا في حدوث خطأ..

لأنه يعني أن مستخدمي ملف APK السابق لن يتمكنوا من تحديث التطبيق.

  • ملف APK الذي يتطلب مستوى أعلى من واجهة برمجة التطبيقات يجب أن يحتوي على رمز إصدار أعلى.

وهذا صحيح فقط إلا عندما: تختلف ملفات فقط APK بناءً على مستويات واجهة برمجة التطبيقات المدعومه (لا تميز أي مرشحات أخرى مدعومه ملفات APK عن بعضها)..

أو عندما تستخدم ملفات APK مرشح آخر مدعوم، ولكن هناك تداخل بين ملفات APK بداخل ذلك المرشح .

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

أعلى من رمز الإصدار لملف APK الموجود حالياً على الجهاز. وهذا يضمن أنه في حالة تلقي أحد الأجهزة تحديث من النظام..

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

 

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

 

إليك بعض الأمثلة:

  • إذا كان ملف APK الذي حملته لمستويات واجهة برمجة التطبيقات (API) 16 وما فوق (Android 4.1.x +) يحتوي على رمز الإصدار 0400..

فيجب أن يكون ملف APK لمستويات API 21 وأحدث (Android 5.0+) برمز الإصدار 0401 وأعلى.

في هذه الحالة، يكون مستوى واجهة برمجة التطبيقات هو المرشح المدعوم الوحيد والمستخدم..

لذا يجب أن تزداد رموز الإصدار بشكلٍ مرتبط مع مستوى واجهة برمجة التطبيقات المدعوم لكل ملف APK..

بحيث يحصل المستخدمون على تحديث عندما يتلقون تحديث للنظام.

 

  • إذا كان لديك ملف APK واحد لمستوى واجهة برمجة التطبيقات (API 16) وأحدث، وللشاشات الصغيرة والكبيرة..

وملف APK آخر لمستوى واجهة برمجة التطبيقات 21 وأحدث وللشاشات الكبيرة – والأكبر، فيجب أن تزيد رموز الإصدار بشكل مرتبط مع مستويات API.

في هذه الحالة، يتم إستخدام مرشح مستوى واجهة برمجة التطبيقات للتمييز بين كل ملف APK وآخر، وكذلك حجم الشاشة.

لأن أحجام الشاشات متداخله (كلا ملفي APK يدعم الشاشات الكبيرة)، يجب أن تكون رموز الإصدار مرتبه.

يضمن هذا أن الجهاز بالشاشة الكبيرة والذي يتلقى تحديث للنظام للمستوى API 21 سوف يتلقى تحديث لملف APK الثاني.

  • إذا كان لديك ملف APK واحد لمستوى واجهة برمجة التطبيقات (API 16) وأحدث وللشاشات الصغيرة – العادية..

وملف APK آخر لمستوى API 21 وأحدث وللشاشات الكبيرة – الأكبر، فلن تحتاج رموز الإصدار إلى زيادة مرتبطة بمستويات API.

نظراً لعدم وجود تداخل بداخل مرشح حجم الشاشة، لا توجد أجهزة يمكن أن تنتقل بين ملفي الـ APK هذين..

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

  • إذا كان لديك ملف APK واحد لمستوى واجهة برمجة التطبيقات (API) 16 وأحدث والإصدار السابع من معالجات ARM لوحدة المعالجة المركزية..

وملف APK آخر لمستوى واجهة برمجة التطبيقات 21 وأحدث والإصدار v5TE من معالجات ARM لوحدة المعالجة المركزية..

فيجب زيادة رموز الإصدار بشكلٍ مرتبط مع مستويات واجهة برمجة التطبيقات. في هذه الحالة..

يتم إستخدام مرشح مستوى واجهة برمجة التطبيقات للتمييز بين كل ملف APK وآخر، وكذلك بنية وحدة المعالجة المركزية.

لأن ملف APK الذي يحتوي على مكتبات معالجات ARMv5TE متوافق مع الأجهزة التي تحتوي على الإصدار السابع من معالجات ARM لوحدة المعالجة المركزية..

فإن ملفات APK سوف تتداخل مع هذه الخاصية. وهكذا، رمز الإصدار لملف APK الذي يدعم المستوى API 21 فما فوق يجب أن يكون أعلى.

و هذا يضمن أن الجهاز المزود بالإصدار السابع من معالجات ARM لوحدة المعالجة المركزية..

والذي يتلقى تحديث نظام للمستوى API 21 سوف يتلقى تحديثاً لملف APK الثاني الذي تم تصميمه لمستوى واجهة برمجة التطبيقات 21.

ومع ذلك، لأن هذا النوع من التحديث في جهاز ذو معالج ARMv7 يستخدم ملف APK غير ملائم تماماً لوحدة المعالجة المركزية لهذا الجهاز..

يجب عليك توفير ملف APK لتراكيب كل من معالجي ARMv5TE و ARMv7 لكل مستوى من واجهة برمجة التطبيقات لتحسين أداء التطبيق على كل وحدة معالجة مركزية.

ملاحظة: ينطبق هذا فقط عند مقارنة ملفات APK مع مكتبات ARMv5TE و ARMv7 ، ولا ينطبق عند مقارنة المكتبات الأصلية الأخرى.

 

 

يؤدي عدم الإلتزام بالقواعد المذكورة أعلاه إلى حدوث خطأ في وحدة تحكم قوقل بلي عند تنشيط ملفات APK..

ولن تتمكن من نشر التطبيق حتى يتم حل الخطأ.

 

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

  • عندما تقوم بتعديل ملف APK لـ “تقليص” الدعم لخصائص الجهاز ولا تدعم أي من ملفات APK الأخرى الأجهزة التي تقع خارج النطاق المدعوم.

مثال، إذا كان ملف APK يدعم حالياً الشاشات صغيرة الحجم و العادية وقمت بتغييره بحيث يدعم الشاشات الصغيرة فقط..

عندها تكون قد قلصت مجموعة الأجهزة المدعومة، ولن ترى بعض الأجهزة تطبيقك على قوقل بلي بعد الآن.

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

  • عندما تكون هناك “تداخلات” بين ملفي APK أو أكثر. مثال، إذا كان ملف APK يدعم أحجام الشاشة الصغيرة والعاديه والكبيرة..

في حين يدعم ملف APK آخر الأحجام الكبيرة والأكبر، فسيكون هناك تداخل، لأن كلا ملفي الـ APK يدعمان الشاشات الكبيرة.

إذا لم تحل هذه المشكلة، فإن الأجهزة المؤهلة لكلا ملفي APK (وهي الأجهزة ذات الشاشة الكبيرة في المثال) سوف تتلقى ملف APK الذي يحتوي على أعلى رمز للإصدار.

ملاحظة: إذا كنت تنشئ ملفات APK منفصلة لبنى وحدات المعالجة المركزية المختلفة، فكن على دراية بأن ملف APK لمكتبات ARMv5TE سيتداخل مع ملف APK لمكتبات ARMv7.

أي أن، ملف APK المصمم لمعالجات ARMv5TE سيكون متوافق مع جهاز بمعالج ARMv7، ولكن العكس ليس صحيحاً..

(ملف APK الذي يحتوي على مكتبات ARMv7 فقط سيكون غير متوافق مع جهاز بمعالج ARMv5TE).

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

 

 

 

دعم ملفات apk

 

إنشاء عدة ملفات APK


بمجرد أن تقرر نشر عدة ملفات APK، قد تحتاج إلى إنشاء مشاريع أندرويد منفصلة لكل ملف APK تنوي نشره بحيث يمكنك تطويره بشكلٍ منفصل.

يمكنك القيام بذلك ببساطة عن طريق تكرار مشروعك الحالي وإعطائه اسماً جديداً. (بدلاً من ذلك..

قد تستخدم نظام إنشاء يمكنه إنتاج مصادر مختلفة – مثل التراكيب – بناءً على تكوين البنية).

نصيحة: تتمثل إحدى الطرق لتجنب تكرار أجزاء كبيرة من كود التطبيق في إستخدام مكتبة للمشروع.

تحتوي مكتبة المشروع على كود ومصادر مشتركة، يمكنك تضمينها في مشاريع تطبيقك الفعلية.

عند إنشاء العديد من المشاريع لنفس التطبيق، من الممارسات الجيدة تحديد كل منها بأسم يشير إلى قيود الجهاز التي سيتم وضعها على ملف الـ APK..

بحيث يمكنك التعرف عليها بسهولة. مثال، قد يكون “HelloWorld_21” اسماً جيداً لأحد التطبيقات المصممة لمستوى واجهة التطبيقات 21 وما يليها.

ملاحظة: يجب أن تحتوي جميع ملفات APK التي تنشرها لنفس التطبيق على اسم الحزمة نفسه وأن يتم توقيعها بإستخدام مفتاح الشهادة نفسه.

تأكد أيضاً من فهم كافة القواعد لملفات APK المتعددة.

 

 

 

دعم ملفات apk

 

تعيين رموز الإصدار


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

يجب أن تكون حذراً بشأن تعيين رموز الإصدار عند نشر ملفات 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 ، لأنه يحتوي على أعلى رمز للإصدار.

في حالة عدم قدرة متجر قوقل بلي على تحديد ملف APK الصحيح لتثبيته على الجهاز المستهدف..

فقد تحتاج أيضاً إلى إنشاء ملف APK عالمي يتضمن مصادر لجميع صيغ الأجهزة المختلفة التي تريد دعمها.

إذا كنت تقدم ملف APK عالمي، فيجب عليك تعيينه على أدنى نسخه من versionCode.

لأن متجر قوقل بلي يقوم بتثبيت إصدار تطبيقك المتوافق مع الجهاز المستهدف ولديه أعلى نسخة من versionCode ..

لذا تعيين رمز نسخة أقل لملف APK العالمي يضمن أن متجر قوقل بلي سيحاول تثبيت أحد ملفاتك APK الأخرى قبل الرجوع إلى أكبر ملف APK عالمي.

 

 

دعم ملفات apk

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

 

للسماح لملفات APK المختلفة بتحديث رموز إصدارها بشكلٍ مستقل..

عن الملفات الأخرى (مثال، عند إصلاح خطأ في ملف APK واحد فقط ، لن تحتاج إلى تحديث جميع ملفات APK)..

يجب عليك إستخدام مخطط لرموز الإصدارات الذي يوفر مساحة كافية..

بين كل ملف APK وآخر بحيث يمكنك زيادة الرمز لملف دون الحاجة إلى زيادته في الآخر.

يجب عليك أيضاً تضمين اسم الإصدار الفعلي في الرمز (أي، الإصدار المرئي للمستخدم الذي تم تعيينه إلى android:versionName)..

بحيث يكون من السهل عليك الربط بين رمز الإصدار وأسم الإصدار.

ملاحظة: عند زيادة رمز الإصدار لملف APK، سيطالب قوقل بلي مستخدمي الإصدار السابق بتحديث التطبيق.

وهكذا، لتجنب التحديثات الغير ضرورية، يجب عليك عدم زيادة رمز الإصدار لملفات APK التي لا تحتوي على تغييرات فعليه.

 

نقترح إستخدام رمز إصدار مكون من 7 أرقام على الأقل: الأعداد الصحيحة التي تمثل التكوينات المدعومة موجودة في بتات ذات ترتيب أعلى..

ويكون اسم الإصدار (من android:versionName) في بتات ذات ترتيب أقل. مثال، عندما يكون اسم إصدار التطبيق هو 3.1.0 ..

فإن رموز الإصدار لمستوى واجهة برمجة التطبيقات 4 APK ومستوى 11 APK ستكون شيئاً مثل 0400310 و 1100310 على التوالي.

تم حجز أول رقمين لمستوى واجهة برمجة التطبيقات (4 و 11 على التوالي)، أما الرقمين الأوسطين..

فهما إما لأحجام الشاشات أو لصيغ تراكيب GL (غير المستخدمة في هذه الأمثلة)، والأرقام الثلاثة الأخيرة هي لاسم إصدار التطبيق.

(3.1.0). يوضح الشكل 1 مثالين لهذا التقسيم بناءً على كل من إصدار النظام الأساسي (مستوى واجهة برمجة التطبيقات) وحجم الشاشة.

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

 

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

قد يكون أحد الخيارات هو تحديد جدولك الخاص الذي يحدد عدد صحيح مختلف لكل من الصيغ المختلفة..

التي يدعمها تطبيقك (مثال، قد تتوافق 1 مع ETC1 و 2 تتوافق مع ATITC ، وهكذا).

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

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

أو لأنك قمت بتعديل دعم التكوين لملف أو أكثر من ملفات APK. ة 


للإطلاع على المقال باللغة الإنجليزية أضغط هنا.

الإعلانات