إنشاء حِزم APK متعدّدة لمستويات واجهة برمجة تطبيقات مختلفة

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

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

تأكيد الحاجة إلى حِزم APK متعدّدة

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

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

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

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

وضع مخطط للمتطلبات

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

لإنشاء مخطط APK متعدد، ابدأ بصف من الخلايا يمثل المستويات المتنوعة لواجهة برمجة التطبيقات في نظام Android الأساسي. وأضف خلية إضافية في النهاية لتمثيل إصدارات Android المستقبلية.

3 4 5 6 7 8 9 10 11 12 13 +

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

3 4 5 6 7 8 9 10 11 12 13 +

بمجرد إنشاء هذا المخطط، وزعه على فريقك. لقد أصبح التواصل بين أعضاء الفريق بشأن مشروعك أكثر بساطة على الفور، فبدلاً من طرح السؤال "كيف يبدو حجم ملف APK لمستويات واجهة برمجة التطبيقات من 3 إلى 6، هل تعلم أنّ الإصدار 1.x من نظام Android؟ كيف الحال؟" يمكنك ببساطة أن تقول "كيف سيتم تطوير حزمة APK باللون الأزرق؟"

وضع جميع الرموز والموارد الشائعة في مشروع مكتبة

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

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

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

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

إنشاء مشاريع APK جديدة

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

alexlucas:~/code/multi-apks-root$ ls
foo-blue
foo-green
foo-lib
foo-red

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

ضبط البيانات

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

  • يجب أن يُظهر البيان أنّ حِزمة APK معيّنة مؤهلة.
  • من بين حِزم APK المؤهلة، يفوز أعلى رقم إصدار

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

3 4 5 6 7 8 9 10 11 12 13 +
3 4 5 6 7 8 9 10 11 12 13 +
3 4 5 6 7 8 9 10 11 12 13 +

بما أنّه من الضروري أن يكون لدى حزمة APK التي تتضمّن إصدار minSdkVersion أعلى رمز إصدار أعلى، نعلم أنّ الرمز الأحمر ≥ أخضر ≥ أزرق في ما يتعلّق بقيم رمز الإصدار لذلك يمكننا تصغير المخطط بشكل فعال ليبدو كما يلي:

3 4 5 6 7 8 9 10 11 12 13 +

والآن، لنفترض أيضًا أن ملف APK الأحمر له بعض المتطلبات، على عكس الملفين الآخرين. تتضمن صفحة الفلاتر على Google Play في دليل مطوّري برامج Android قائمة كاملة بالأسباب المحتملة. على سبيل المثال، لنفترض أن اللون الأحمر يتطلب كاميرا أمامية. في الواقع، يكمن الهدف الأساسي لحزمة APK الحمراء في دمج الكاميرا الأمامية مع الوظائف الجديدة الرائعة التي تمت إضافتها في واجهة برمجة التطبيقات (API) 11. ولكن، اتضح أن بعض الأجهزة التي تتوافق مع واجهة برمجة التطبيقات 11 لا تحتوي حتى على كاميرات أمامية! رعب!

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

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

الأزرق: 03001، 03002، 03003، 03004...
الأخضر: 07001، 07002، 07003، 07004...
الأحمر:11001، 11002، 11003، 11004...

من خلال وضع كل هذه الخيارات معًا، قد تظهر ملفات بيانات Android على النحو التالي:

أزرق:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    android:versionCode="03001" android:versionName="1.0" package="com.example.foo">
    <uses-sdk android:minSdkVersion="3" />
    ...

أخضر:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    android:versionCode="07001" android:versionName="1.0" package="com.example.foo">
    <uses-sdk android:minSdkVersion="7" />
    ...

أحمر:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    android:versionCode="11001" android:versionName="1.0" package="com.example.foo">
    <uses-sdk android:minSdkVersion="11" />
    ...

مراجعة قائمة تحقق الإطلاق التجريبي

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

  • يجب أن يكون لجميع حِزم APK اسم الحزمة نفسه.
  • يجب توقيع جميع حِزم APK باستخدام الشهادة نفسها.
  • إذا تداخلت حِزم APK مع إصدار النظام الأساسي، يجب أن يتضمّن الإصدار الذي يحتوي على إصدار أعلى من minSdkVersion رمز إصدار أعلى.
  • تحقق مرة أخرى من فلاتر البيان بحثًا عن معلومات متضاربة (لن يتمكن أي شخص من رؤية ملف APK يتوافق فقط مع تنسيق cupK على شاشات XLARGE).
  • يجب أن يكون ملف البيان الخاص بكل حزمة APK فريدًا على شاشة واحدة على الأقل من الشاشات المتوافقة أو زخرفة openGL أو إصدار النظام الأساسي.
  • جرِّب اختبار كل حزمة APK على جهاز واحد على الأقل. بالإضافة إلى ذلك، لديك واحدة من أكثر محاكيات الأجهزة قابلية للتخصيص في نشاطك التجاري على جهاز التطوير الذي تستخدمه. يا إلهي!

كذلك، من المفيد فحص حزمة APK المُجمّعة قبل نشرها في السوق، للتأكد من عدم وجود أي مفاجآت قد تخفي تطبيقك على Google Play. يعد ذلك أمرًا بسيطًا للغاية باستخدام أداة "aapt". تُعد Aapt (أداة Android Asset Packaging Tool) جزءًا من عملية الإنشاء لإنشاء تطبيقات Android وتجميعها، وهي أيضًا أداة سهلة للغاية لفحصها.

>aapt dump badging
package: name='com.example.hello' versionCode='1' versionName='1.0'
sdkVersion:'11'
uses-permission:'android.permission.SEND_SMS'
application-label:'Hello'
application-icon-120:'res/drawable-ldpi/icon.png'
application-icon-160:'res/drawable-mdpi/icon.png'
application-icon-240:'res/drawable-hdpi/icon.png'
application: label='Hello' icon='res/drawable-mdpi/icon.png'
launchable-activity: name='com.example.hello.HelloActivity'  label='Hello' icon=''
uses-feature:'android.hardware.telephony'
uses-feature:'android.hardware.touchscreen'
main
supports-screens: 'small' 'normal' 'large' 'xlarge'
supports-any-density: 'true'
locales: '--_--'
densities: '120' '160' '240'

عند فحص مخرجات Aapt، تأكد من أنه ليس لديك قيم متعارضة لشاشات الدعم والشاشات المتوافقة، ومن أنه ليس لديك قيم "uses-feature" غير مقصودة تمت إضافتها كنتيجة للأذونات التي حددتها في البيان. في المثال أعلاه، لن تكون حزمة APK مرئية للعديد من الأجهزة.

ما السبب؟ بإضافة الإذن المطلوب SEND_SMS، تمت إضافة متطلبات ميزة android.hardware.telephony بشكلٍ ضمني. بما أنّ واجهة برمجة التطبيقات 11 هي Honeycomb (إصدار Android المخصّص للأجهزة اللوحية)، ولا تحتوي أجهزة Honeycomb على أجهزة هاتفية، سيعمل Google Play على فلترة حزمة APK هذه في جميع الحالات إلى أن يتم توفير أجهزة مستقبلية ذات مستوى أعلى من حيث مستوى واجهة برمجة التطبيقات وتملك أجهزة هاتفية.

ولحسن الحظ، يمكن إصلاح هذه المشكلة بسهولة من خلال إضافة ما يلي إلى ملف البيان:

<uses-feature android:name="android.hardware.telephony" android:required="false" />

تمت أيضًا إضافة شرط android.hardware.touchscreen ضمنيًا. إذا أردت أن يكون ملف APK مرئيًا على أجهزة التلفزيون التي لا تعمل على شاشات تعمل باللمس، يجب إضافة ما يلي إلى البيان:

<uses-feature android:name="android.hardware.touchscreen" android:required="false" />

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