إنشاء حِزم 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.

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

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

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

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