في حال نشر تطبيقك على 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، أي واجهة برمجة التطبيقات لنظام التشغيل Android 1.x؟ كيف الحال؟" يمكنك ببساطة قول "ما مدى تقدّم ملف APK لتطبيق Blue؟".
وضع كل الرموز البرمجية والموارد الشائعة في مشروع مكتبة
سواء كنت تعمل على تعديل تطبيق Android حالي أو كنت تبدأ تطبيقًا من نقطة الصفر، فهذا هو أول شيء يجب عليك فعله في قاعدة الرموز، بل هو الأهم إلى حدٍ كبير. يجب تحديث كل ما يتعلق بمشروع المكتبة مرة واحدة فقط (فكر في السلاسل المترجَمة للّغة، ومظاهر الألوان، والأخطاء التي تم إصلاحها في الرمز المشترك)، مما يحسّن وقت التطوير ويقلل من احتمال حدوث الأخطاء التي كان من الممكن تجنبها بسهولة.
ملاحظة: في حين أنّ تفاصيل تنفيذ كيفية إنشاء مشاريع المكتبة وتضمينها خارج نطاق هذا الدرس، يمكنك التعرّف على كل ما هو جديد من خلال قراءة إنشاء مكتبة Android.
في حال تحويل تطبيق حالي لاستخدام دعم حِزم 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 متعددة من خلال Google Play، يتم اختيار حزمة 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 الأحمر هو دمج الكاميرا الأمامية مع وظائف جديدة رائعة تمت إضافتها في واجهة برمجة التطبيقات 11. ولكن تبين أنه ليست كل الأجهزة التي تدعم واجهة برمجة التطبيقات 11 حتى تحتوي على كاميرات أمامية! أمر مرعب!
لحسن الحظ، إذا كان أحد المستخدمين يتصفّح Google Play من أحد هذه الأجهزة، سيراجع Google Play ملف البيان وسيلاحظ أنّ Red يُدرج الكاميرا الأمامية كشرط أساسي، وسيتجاهله بهدوء بعد أن يتأكّد من أنّ 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 لا تتوافق إلا مع محتوى الكب كيك على شاشات XLARGE).
- يجب أن يكون بيان كل ملف APK فريدًا على الأقل من شاشة أو زخرفة OpenGL أو إصدار نظام أساسي واحد معتمدة
- حاوِل اختبار كل حزمة APK على جهاز واحد على الأقل. بخلاف ذلك، لديك أحد أكثر محاكيات الأجهزة قابلية للتخصيص في المجال على جهاز التطوير. يا للعجب!
ويجب أيضًا فحص APK الذي تم تجميعه قبل نشره في السوق، للتأكد من عدم وجود أي مفاجآت قد تخفي تطبيقك على Google Play. وهذا في الواقع بسيط للغاية باستخدام أداة "aapt". أداة Aapt (أداة تجميع مواد العرض في Android) هي جزء من عملية الإنشاء لإنشاء تطبيقات 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 تستهدف الأجهزة المقصودة. تهانينا، لقد انتهيت!