إذا كنت تنشر تطبيقك على 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 جديدة
يجب أن يكون هناك مشروع 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. على حدة، سيكون النطاق المحتمل لكل حزمة 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 أيضًا رمز إصدار أعلى، نعرف أنّه من حيث قيم versionCode، يكون الأحمر ≥ الأخضر ≥ الأزرق. وبالتالي، يمكننا تصغير الرسم البياني بفعالية ليظهر على النحو التالي:
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
لنفترض الآن أنّ حزمة APK الحمراء تتضمّن بعض المتطلبات التي لا تتضمنها الحزمتَان الأخريان. تتضمّن صفحة الفلاتر على Google Play في دليل مطوّري تطبيقات Android قائمة كاملة بالعوامل المحتمَلة. على سبيل المثال، لنفترض أنّ اللون الأحمر يتطلب استخدام كاميرا أمامية. في الواقع، الغرض من ملف APK الأحمر هو دمج الكاميرا الأمامية مع وظائف جديدة رائعة تمت إضافتها في واجهة برمجة التطبيقات 11. ولكن تبيّن أنّ بعض الأجهزة المتوافقة مع واجهة برمجة التطبيقات 11 لا تتضمّن كاميرات أمامية. الفظاعة
لحسن الحظ، إذا كان أحد المستخدمين يتصفّح Google Play من أحد هذه الأجهزة، سيراجع Google Playملف البيان، وسيلاحظ أنّ تطبيق Red يُدرج الكاميرا الأمامية كشرط أساسي، وسيتجاهله بهدوء، بعد أن تأكد من أنّ تطبيق Red غير متوافق مع هذا الجهاز. سيتبيّن للتطبيق بعد ذلك أنّه لا يكون Green متوافقًا مع الإصدارات الأحدث فقط من الأجهزة التي تعمل بواجهة برمجة التطبيقات 11 (لأنّه لم يتم تحديد maxSdkVersion)، ولكنه لا يهتم أيضًا بما إذا كانت هناك كاميرا أمامية أم لا. لا يزال بإمكان المستخدم تنزيل التطبيق من Google Play، لأنّه على الرغم من المشكلة المتعلّقة بالكاميرا الأمامية، لا يزال هناك حزمة APK متوافقة مع مستوى واجهة برمجة التطبيقات هذا.
للحفاظ على جميع حِزم APK في "قنوات إصدار" منفصلة، من المهم أن يكون لديك رمز إصدار مخطّط جيد. يمكن العثور على الرمز المقترَح في قسم رموز الإصدار في دليل المطوّر. بما أنّ مجموعة حِزم APK النموذجية لا تتعامل إلا مع أحد السمات الثلاث المحتملة، يكفي فصل كل حزمة APK بفاصل 1000، وضبط أول رقمين على variedSdkVersion لحزمة 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 في إصدار النظام الأساسي، يجب أن يتضمّن ملف APK الذي يتضمّن إصدار minSdkVersion أعلى رمز إصدار أعلى.
- تحقّق جيدًا من فلاتر البيان بحثًا عن أي معلومات متضاربة (لن يظهر ملف APK الذي يتوافق فقط مع Cupcake على الشاشات الكبيرة جدًا لأي مستخدم).
- يجب أن يكون ملف بيان كل حزمة 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، تأكَّد من عدم توفّر قيم متضاربة لسمتي supports-screens وcompatible-screens، ومن عدم توفّر قيم "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 تستهدف الأجهزة المقصودة. تهانينا، لقد أكملت الخطوات المطلوبة.