التعرّف على جودة التطبيقات المصمّمة لأجهزة متعدّدة ونشرها على أجهزة غير الأجهزة الجوّالة على Google Play

مرحبًا بالجميع.

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

أنا "جان كلاينرت"، مهندس علاقات المطوّرين في فريق "Android للسيارات".

وأنا "فوستين لياو"، مديرة عمليات في فريق الثقة والسلامة في Google Play.

يسرّنا كثيرًا انضمامكم إلينا اليوم.

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

واليوم، يتفاعل المستخدمون مع التطبيقات في غرف المعيشة على Android TV، أو ربما في سياراتهم أثناء التنقل مع الآخرين أو أثناء شحن سياراتهم على Android Auto أو نظام التشغيل Automotive، أو على معاصمهم باستخدام Wear OS، وبشكل متزايد في المساحات الثلاثية الأبعاد الغامرة باستخدام Android XR.

يُعدّ ذلك فرصة هائلة للنمو، ولكن التوسّع ليشمل أشكال الأجهزة هذه يعني أنّ هناك بعض الاعتبارات الهامشية التي يجب أخذها في الاعتبار في استراتيجية النشر.

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

أنشِئ تطبيقك وجهِّزه، ثم أنشِئ بطاقة بيانات المتجر في Play Console، واختبِر تطبيقك، وحمِّل الإصدار النهائي وأرسِله، ثم انتظِر المراجعة والموافقة.

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

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

لنبدأ بالأساسيات: كيفية تصميم تطبيقك وتجميعه.

لذا، قبل استخدام Google Play Console، عليك اتخاذ قرار مهم بشأن البنية.

هل تنشئ حزمة تطبيق واحدة موحّدة تحتوي على كل شيء لجميع أشكال الأجهزة التي تتيحها، أم تقسّم تطبيقك إلى وحدات خاصة بأشكال الأجهزة وتنشئ مجموعات حزمات تطبيق Android (أو ملفات AAB) لكل منها؟

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

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

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

إليك مثال يوضّح سبب اقتراحنا لهذا النهج القائم على الوحدات.

لنفترض أنّ لديك تطبيقًا متوافقًا مع كلّ من الأجهزة الجوّالة وAndroid TV.

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

سيؤثر ذلك في إصدار تطبيق Android TV وتطبيقك المتوافق مع الأجهزة الجوّالة.

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

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

لذلك، إذا كانت لديك وحدات منفصلة لتطبيقك المتوافق مع الأجهزة الجوّالة وتطبيق بث تلفزيوني، يمكنك إنشاء مجموعات حزمات تطبيق Android منفصلة لكل منهما.

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

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

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

في ما يلي مثال واحد على نهج لتقسيم تطبيق كتب مسموعة يتضمّن تجربة على الأجهزة الجوّالة وتجربة على نظام التشغيل Android Automotive.

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

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

تظهر وحدات البيانات باللون الأزرق، وفي الأسفل، لدينا الوحدات الأساسية أو الشائعة، والتي تُستخدم عادةً لاحتواء الرموز البرمجية التي تستخدمها الوحدات الأخرى بشكل متكرر.

بعد ذلك، في ملفات إعدادات Gradle الخاصة بمشروعك، يمكنك تضمين إعدادات Gradle المتعدّدة الوحدات هذه وإعدادها لإتاحة هذا النوع من التقسيم إلى وحدات.

...

rootProject.name = "MultiFormFactorApp"

// Define modules for each form factor
include(":app:automotive")
include(":app:mobile")
include(":core:network")
include(":data:books")
include(":data:reviews")
include(":feature:home")
include(":feature:player")
include(":feature:reviews")

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

يرتبط هذا النهج القائم على الوحدات مباشرةً باستراتيجية قنوات الإصدار في Play Console.

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

بالنسبة إلى Android TV وAndroid XR ونظام التشغيل Android Automotive، لديك خياران.

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

ومع ذلك، هناك استثناءان.

بالنسبة إلى Wear OS، يجب استخدام قناة الإصدار المخصّصة له.

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

إذا كنت تدير مسارات متعددة، فإنّ تحديد الإصدارات أمر بالغ الأهمية.

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

على سبيل المثال، ‎01 للأجهزة الجوّالة، و‎02 لنظام التشغيل Wear OS، و‎03 لنظام التشغيل Android Automotive، وهكذا.

ننصح عمومًا بأن تتكوّن رموز الإصدارات من سبعة أرقام على الأقل، حتى يمكن استخدام الأرقام المتبقية لإصدار التطبيق.

يساعد ذلك في منع تعارض رموز الإصدارات في Play Console.

بعد تجميع تطبيقك، يحين وقت اختباره.

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

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

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

لذا، يُعدّ الاختبار الداخلي نقطة بداية رائعة.

فهو يتيح لك توزيع تطبيقك بسرعة على ما يصل إلى 100 مختبِر، والأهم من ذلك أنّه لا يتطلّب مراجعة من Google Play.

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

ومن خلال الاختبارات الداخلية، ستحصل على عنوان URL فريد يمكنك مشاركته مع هؤلاء المختبِرين.

بعد أن تصبح راضيًا عن نتائج الاختبار الداخلي، يمكنك الانتقال إلى الاختبار المغلق والاختبار المفتوح.

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

يمكنك إدارة مجموعات الاختبار المغلق إما كقوائم لعناوين البريد الإلكتروني أو من خلال "مجموعات Google".

من ناحية أخرى، يساعدك الاختبار المفتوح في إجراء اختبار مع مجموعة أكبر من المستخدمين على Google Play.

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

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

تؤدي مسارات الاختبار المفتوحة والمغلقة هذه إلى إجراء مراجعات.

هذه ميزة كبيرة في الواقع.

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

لنتحدّث قليلاً عن عملية المراجعة وما تتضمّنه وأهميتها.

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

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

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

أعتقد أنّ أفضل مكان للبدء هو الاطّلاع على إرشادات جودة التطبيقات التي تركّز على شكل تجربة المستخدم الرائعة.

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

هاتان المجموعتان من الإرشادات معًا هما مكان جيد للبدء.

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

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

لذلك، من المهم جدًا التأكّد من التزام تطبيقك بها.

في ما يلي نظرة سريعة على الأسباب الأكثر شيوعًا لرفض التطبيقات على كل شكل من أشكال الأجهزة.

ولكن يُرجى العِلم أنّ هذه القائمة ليست شاملة لجميع إرشادات جودة التطبيقات.

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

لنبدأ إذًا بـ Android TV.

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

من الأسباب الشائعة لرفض تطبيقات Android TV عدم توفّر صورة بانر للشاشة الرئيسية لكل لغة يتيحها التطبيق.

لذا، ما عليك فعله هو تقديم صورة بدقة 320 × 180 بكسل تتضمّن نصًا مترجمًا يحدّد تطبيقك.

تعرض الصورة في هذه الشريحة مثالاً على بانر الشاشة الرئيسية الذي يلتزم بهذه المعايير.

ثانيًا، على معظم أجهزة التلفزيون، سيتفاعل المستخدمون مع الجهاز باستخدام جهاز تحكّم عن بُعد يتضمّن لوحة تحكّم.

لذلك، من المهم جدًا أن تتيح التنقل والتركيز باستخدام لوحة التحكّم بشكل صحيح.

تأكَّد من توفير الحد الأدنى من عناصر التحكّم في لوحة التحكّم لتجنُّب أي حالات رفض بناءً على هذه المعايير.

السبب الشائع الثالث لرفض تطبيقات Android TV هو عدم توفّر فلتر intent CATEGORY_LEANBACK_LAUNCHER في ملف بيان Android.

<application ...>
...
<activity
    android:name="com.example.TvActivity"
    android:label="@string/app_name"
    android:theme="@style/Theme.Leanback">
    <intent-filter>
      <action android:name=
           "android.intent.action.MAIN" />
      <category android:name=
           "Android.intent.category.
            LEANBACK_LAUNCHER" />
    </intent-filter>
  </activity>
</application>

سيحدّد هذا الفلتر تطبيقك على أنّه مفعَّل للتلفزيون، ويتيح لـ Google Play أيضًا تحديده كتطبيق بث تلفزيوني للمستخدمين.

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

لذا تأكَّد من تضمينه في بيان التطبيق.

‫Android XR هو الخطوة التالية.

عند إنشاء تطبيقات لسماعات الرأس أو النظارات بنظام الواقع الممتد التي تعمل بنظام Android XR، يجب الانتباه بشكل خاص إلى أداء تطبيقاتك وعرضها واستقرارها.

يمكنك استخدام Perfetto لتحليل أداء التطبيقات التي تم إنشاؤها باستخدام حزمة تطوير البرامج (SDK) لـ Jetpack XR للمساعدة في ضمان الالتزام بالحدّ الأدنى لمتطلبات عدد اللقطات في الثانية.

وإذا كنت تنشئ اللعبة باستخدام محرّك في الوقت الفعلي مثل Unity، يمكنك استخدام أدوات التحليل المضمّنة في هذا المحرّك للتأكّد من توافق اللعبة مع متطلبات العرض.

بعد ذلك، لدينا السيارات، والتي تتضمّن كلاً من Android Auto ونظام التشغيل Android Automotive.

بالنسبة إلى Android Auto ونظام التشغيل Android Automotive، هناك مفهوم الفئات، وهو فريد من نوعه إلى حدّ ما بالنسبة إلى شكل الجهاز هذا.

ويُسمح بنشر فئات معيّنة فقط من التطبيقات على السيارات.

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

لذا اسمحوا لي أن أريكم ما أعنيه بمزيد من التفصيل.

في الأعلى، يمكنك الاطّلاع على نظرة عامة على فئات التطبيقات المتوافقة مع السيارات لكل نظام أساسي، بالإضافة إلى مدى توفّرها.

سواء كانت في إصدار تجريبي أو مفتوح، ما يعني أنّها متاحة للجمهور العام، أو غير متاحة بعد، وهو ما يُشار إليه هنا بعبارة "ستتوفّر قريبًا".

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

أما الفئات الأخرى، مثل تطبيقات الاتصال المخصّصة لـ Android Auto، فهي في مرحلة تجريبية.

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

ويمكنك الاطّلاع على مزيد من التفاصيل حول ذلك وغيره في أدلة المطوّرين الخاصة بـ "Android للسيارات".

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

من الأسباب الشائعة الأخرى لرفض التطبيقات عدم توفّر مواصفات لقطات الشاشة لنظام التشغيل Android Automotive أو عدم صحتها.

لذا، عند تقديم لقطات شاشة لنظام التشغيل Android Automotive، يجب التأكّد من تضمين لقطتَي شاشة على الأقل بالوضع العمودي ولقطتَي شاشة على الأقل بالوضع الأفقي بالأبعاد المذكورة هنا.

ويمكنك استخدام محاكي نظام التشغيل Android Automotive لمساعدتك في التقاطها.

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

وأخيرًا، الأمان هو الأهم في التطبيقات المخصّصة للسيارات.

لذا، إذا لم يلتزم تطبيقك بإرشادات تشتيت السائق، فسيتم رفضه.

على سبيل المثال، يجب أن يوقف تطبيق الفيديو التشغيل مؤقتًا، ولا يمكن أن يكون مرئيًا أثناء تحرّك المركبة.

أخيرًا وليس آخرًا، لدينا Wear OS.

لذلك، قد يتم رفض تطبيقات Wear OS إذا لم تكن محسّنة ومصمّمة للشاشات الصغيرة المستديرة.

لذا ننصح هنا باستخدام أحدث إصدار ثابت من Compose لنظام التشغيل Wear OS للتأكّد من عدم اقتطاع المحتوى عند الحواف على الأجهزة ذات الأحجام المختلفة، أو على سبيل المثال، للتأكّد من ظهور شريط التمرير عندما يكون هناك محتوى قابل للتمرير.

@Composable
fun MyText() {
  Text(
    text = stringResource(R.string.compose_for_wear_os),
    modifier = Modifier.fillMaxWidth(),
    textAlign = TextAlign.Center,
    style = MaterialTheme.typography.titleLarge
  )
}

وعلى غرار ما ذكرناه بشأن "نظام التشغيل Android Automotive"، يمكن أيضًا رفض تطبيقات Wear OS بسبب عدم توفّر لقطات شاشة لها أو عدم دقتها.

إليك مثال جيد على لقطة شاشة من بطاقة بيانات "متجر Google Play" لنموذج تطبيق Androidify، وهو يستوفي المتطلبات.

لذا تأكَّد من إرسال لقطة شاشة واحدة على الأقل تعرض تطبيقك أثناء تشغيله على جهاز Wear OS.

ما هي الخلاصة؟

اقرأ إرشادات جودة التطبيق الخاصة بالشكل المحدّد واختبِر تطبيقك وفقًا لها قبل إرساله.

إليك أيضًا بعض النصائح المهمة.

إذا كان تطبيقك يتطلّب تسجيل الدخول، عليك تقديم حساب تجريبي نشط وبيانات اعتماد صالحة في قسم "الوصول إلى التطبيق" في Play Console.

إذا لم يتمكّن المراجعون من تسجيل الدخول، فلن نتمكّن من اختبار تطبيقك وسيتم رفضه تلقائيًا.

احرص أيضًا على الوفاء بما تعد به.

لا تستخدِم لقطات شاشة من الأجهزة الجوّالة فقط.

إذا كان تطبيقك متاحًا على Wear OS وAndroid TV، فتأكَّد من تحميل لقطات شاشة عالية الجودة لأشكال الأجهزة المحدّدة هذه في Play Console.

أخيرًا وليس آخرًا، يجب أن تكون وصفيًا.

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

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

شكرًا جزيلاً على وقتكم اليوم.

نحن متحمّسون لرؤية تجاربكم الرائعة على Google Play المصمّمة لأجهزة متعدّدة.