1. مقدّمة
يسرد هذا المستند المتطلبات التي يجب استيفاؤها لكي تكون الأجهزة متوافقة مع الإصدار 12 من نظام التشغيل Android.
يتم استخدام الكلمات "يجب" و"يجب ألّا" و"مطلوب" و"يجب" و"يجب ألّا" و"يُفضَّل" و"يُفضَّل ألّا" و"مُستحسَن" و"يجوز" و "اختياري" وفقًا لمعيار IETF المحدّد في RFC2119.
وفقًا لما هو مذكور في هذا المستند، يشير "منفذ الجهاز" أو "منفذ" إلى شخص أو مؤسسة تطوّر حلًّا للأجهزة/البرامج يعمل بنظام التشغيل Android 12. "تنفيذ الجهاز" أو "التنفيذ" هو الحلّ المطوَّر للأجهزة أو البرامج.
لكي تُعتبر الحلول المتوافقة مع Android 12، يجب أن تستوفي عمليات تنفيذ التطبيقات على الأجهزة المتطلبات الواردة في تعريف التوافق هذا، بما في ذلك أي مستندات تم دمجها من خلال الإشارة إليها.
إذا كان هذا التعريف أو اختبارات البرامج الموضّحة في الفقرة 10 غير واضح أو ملتبس أو غير مكتمل، تقع على عاتق مُنفِّذ الجهاز مسؤولية ضمان التوافق مع عمليات التنفيذ الحالية.
لهذا السبب، يُعدّ المشروع المفتوح المصدر لنظام Android الإصدار المرجعي والمفضّل من Android. ننصح بشدة مطوّري التطبيقات المتوافقة مع الأجهزة بالاستناد إلى أقصى حد ممكن إلى رمز المصدر "الأساسي" المتاح من "مشروع Android المفتوح المصدر". على الرغم من أنّه يمكن نظريًا استبدال بعض المكوّنات بعمليات تنفيذ بديلة، يُنصح بشدة بعدم اتّباع هذه الممارسة، لأنّ اجتياز اختبارات البرامج سيصبح أكثر صعوبة. تقع على عاتق الجهة المنفِّذة مسؤولية ضمان التوافق التام السلوكي مع التنفيذ العادي لنظام التشغيل Android، بما في ذلك مجموعة أدوات اختبار التوافق وما عداها. أخيرًا، يُرجى العلم أنّ هذا المستند يحظر صراحةً بعض عمليات بديلة المكونات وتعديلاتها.
إنّ العديد من الموارد المُشار إليها في هذا المستند مستمَدة مباشرةً أو بشكل غير مباشر من حزمة تطوير البرامج (SDK) لنظام التشغيل Android، وستكون متطابقة من الناحية الوظيفية مع المعلومات الواردة في مستندات حزمة SDK هذه. في أيّ حالات يتعارض فيها "تعريف التوافق" أو "مجموعة اختبار التوافق" مع مستندات حزمة SDK، تُعتبر مستندات حزمة SDK مرجعية. إنّ أي تفاصيل فنية مقدَّمة في الموارد المرتبطة في هذا المستند تُعدّ جزءًا من تعريف التوافق هذا.
1.1 بنية المستند
1.1.1. المتطلبات حسب نوع الجهاز
يحتوي القسم 2 على جميع المتطلبات التي تنطبق على نوع جهاز معيّن. كل قسم فرعي من القسم 2 مخصّص لنوع جهاز معيّن.
يتم إدراج جميع المتطلبات الأخرى التي تنطبق بشكل عام على أي عمليات تنفيذ على أجهزة Android في الأقسام بعد القسم 2. يُشار إلى هذه المتطلبات باسم "المتطلبات الأساسية" في هذا المستند.
1.1.2. رقم تعريف المتطلّبات
يتمّ منح معرّف المتطلّبات للمتطلّبات التي يجب استيفاؤها.
- يتم منح المعرّف لمتطلبات MUST فقط.
- يتم وضع علامة [SR] على المتطلبات التي يُنصح بها بشدة، ولكن لا يتم تحديد معرّف لها.
- يتألّف المعرّف من : معرّف نوع الجهاز - معرّف الشرط - معرّف المتطلّبات (مثل C-0-1).
يتم تعريف كل معرّف على النحو التالي:
- رقم تعريف نوع الجهاز (اطّلِع على مزيد من المعلومات في 2. أنواع الأجهزة)
- ج: الأساسية (المتطلبات التي يتم تطبيقها على جميع عمليات التنفيذ على أجهزة Android)
- H: جهاز Android المحمول
- T: جهاز Android Television
- أ: عملية تنفيذ Android Automotive
- W: Android Watch implementation
- علامة التبويب: تنفيذ التطبيق على جهاز Android اللوحي
- رقم تعريف الحالة
- عندما يكون الشرط غير مشروط، يتم ضبط هذا المعرّف على 0.
- عندما يكون الشرط شَرطًا شرطيًا، يتمّ تخصيص الرقم 1 للشرَط الأول ويزداد الرقم بمقدار 1 ضمن القسم نفسه ونوع الجهاز نفسه.
- رقم تعريف المتطلّب
- يبدأ هذا المعرّف من 1 ويزيد بمقدار 1 ضمن القسم نفسه والشرط نفسه.
1.1.3. رقم تعريف المتطلّبات في القسم 2
تتألّف أرقام تعريف المتطلّبات في القسم 2 من جزأين. يتوافق العنصر الأول مع معرّف القسم كما هو موضّح أعلاه. يحدِّد الجزء الثاني شكل الجهاز والمتطلّبات الخاصة به.
رقم تعريف القسم متبوعًا برقم تعريف المتطلّبات الموضّح أعلاه
- يتكوّن رقم التعريف في القسم 2 من: رقم تعريف القسم / رقم تعريف نوع الجهاز - رقم تعريف الحالة - رقم تعريف المتطلّبات (مثل 7.4.3/A-0-1).
2- أنواع الأجهزة
يوفّر "المشروع المفتوح المصدر لنظام Android" حِزم برامج يمكن استخدامها لأنواع مختلفة من الأجهزة وأشكالها. لتوفير الأمان على الأجهزة، من المتوقّع أن يتم تنفيذ حِزمة البرامج، بما في ذلك أي نظام تشغيل بديل أو تنفيذ بديل لنظام التشغيل ، في بيئة آمنة كما هو موضّح في القسم 9 وفي أماكن أخرى ضمن هذا "ملحق أمان الجهاز". هناك بضعة أنواع من الأجهزة التي تتضمّن منظومة متكاملة لتوزيع التطبيقات بشكل أفضل نسبيًا.
يصف هذا القسم أنواع الأجهزة هذه والمتطلبات الإضافية والاقتراحات التي تنطبق على كل نوع من أنواع الأجهزة.
يجب أن تستوفي جميع عمليات تنفيذ أجهزة Android التي لا تندرج ضمن أي من أنواع الأجهزة الموضّحة جميع المتطلبات الواردة في الأقسام الأخرى من تعريف التوافق هذا.
2.1 إعدادات الجهاز
للاطّلاع على الاختلافات الرئيسية في إعدادات الأجهزة حسب نوع الجهاز، اطّلِع على المتطلبات الخاصة بالأجهزة الواردة في هذا القسم.
2.2. متطلبات الأجهزة الجوّالة
يشير جهاز Android المحمول إلى عملية تنفيذ جهاز Android يتم استخدامها عادةً من خلال الاحتفاظ بها في اليد، مثل مشغل mp3 أو هاتف أو جهاز لوحي.
يتم تصنيف عمليات تنفيذ أجهزة Android على أنّها أجهزة محمولة إذا كانت تستوفي جميع ال المعايير التالية:
- أن يكون مزوّدًا بمصدر طاقة يتيح إمكانية التنقل، مثل بطارية
- أن يكون حجم الشاشة الأفقى في حدود 3.3 بوصة (أو 2.5 بوصة لعمليات تنفيذ الأجهزة التي تم شحنها بالإصدار 29 من واجهة برمجة التطبيقات أو إصدار سابق) حتى 8 بوصة
إنّ المتطلبات الإضافية الواردة في بقية هذا القسم خاصة بعمليات تنفيذ التطبيقات على الأجهزة المزوّدة بنظام Android الأجهزة الجوّالة.
2.2.1. الأجهزة
عمليات تنفيذ الأجهزة المحمولة:
- [7.1.1.1/H-0-1] يجب أن يتضمّن الجهاز شاشة واحدة على الأقل متوافقة مع Android تستوفي جميع المتطلبات الموضّحة في هذا المستند.
[7.1.1.3/H-SR-1] يُنصح بشدة بمنح المستخدمين إمكانية تغيير حجم الشاشة (كثافة الشاشة).
[7.1.1.1/H-0-2] يجب أن تتيح وحدة معالجة الرسومات إنشاء ملف تعريف رسومات بحجم لا يقل عن أعلى درجة دقة لأي شاشة مدمجة.
إذا كانت عمليات تنفيذ الأجهزة الجوّالة تتيح تدوير الشاشة باستخدام البرامج، يجب أن تستوفي الشروط التالية:
- [7.1.1.1/H-1-1]* يجب أن تكون الشاشة المنطقية التي تتوفّر لتطبيقات الجهات الخارجية لا تقلّ عن 5.08 سم على ناحية الجانب القصير و6.86 سم على ناحية الجانب الطويل. قد يتم استثناء الأجهزة التي تم شحنها مع المستوى 29 أو إصدار أقدم من واجهة برمجة التطبيقات من هذا الشرط.
إذا كانت عمليات تنفيذ الأجهزة الجوّالة لا تتيح تدوير الشاشة باستخدام البرامج، يجب:
- [7.1.1.1/H-2-1]* يجب أن تكون الشاشة المنطقية التي تتوفّر للتطبيقات التابعة لجهات خارجية 2.7 بوصة على الأقل على الحواف القصيرة. قد يتم استثناء الأجهزة التي تم شحنها باستخدام المستوى 29 أو إصدار أقدم من واجهة برمجة التطبيقات من هذا الشرط.
إذا كانت عمليات تنفيذ الأجهزة الجوّالة تدّعي توفّر شاشات مزوّدة بتقنية النطاق العالي الديناميكية
من خلال Configuration.isScreenHdr()
، يجب استيفاء الشروط التالية:
- [7.1.4.5/H-1-1] يجب الإعلان عن توفّر الإضافات التالية:
EGL_EXT_gl_colorspace_bt2020_pq
وEGL_EXT_surface_SMPTE2086_metadata
وEGL_EXT_surface_CTA861_3_metadata
وVK_EXT_swapchain_colorspace
وVK_EXT_hdr_metadata
.
عمليات تنفيذ الأجهزة المحمولة:
- [7.1.4.6/H-0-1] يجب الإبلاغ عمّا إذا كان الجهاز
يتوافق مع ميزة إعداد ملفّات تعريف وحدة معالجة الرسومات من خلال خاصيّة نظام
graphics.gpu.profiler.support
.
إذا كانت عمليات تنفيذ الأجهزة الجوّالة تعلن عن التوافق من خلال خاصية نظام
graphics.gpu.profiler.support
، يجب أن تستوفي الشروط التالية:
- [7.1.4.6/H-1-1] يجب أن يُبلغ عن مسار traced protobuf الذي يتوافق مع مخطّط عدّادات وحدة معالجة الرسومات ومراحل عرض وحدة معالجة الرسومات المحدّدة في مستندات Perfetto.
- [7.1.4.6/H-1-2] يجب أن تُبلغ عن قيم متوافقة لعدادات وحدة معالجة الرسومات في الجهاز وفقًا لملف بروتوكول حزمة تتبُّع عداد وحدة معالجة الرسومات.
- [7.1.4.6/H-1-3] يجب الإبلاغ عن قيم متوافقة لمراحل عرض وحدة معالجة الرسومات في الجهاز وفقًا لملف بروتوكول حزمة تتبُّع مرحلة العرض.
- [7.1.4.6/H-1-4] يجب الإبلاغ عن نقطة تتبُّع وحدة معالجة الرسومات كما هو محدّد في التنسيق: power/gpu_frequency.
عمليات تنفيذ الأجهزة المحمولة:
- [7.1.5/H-0-1] يجب أن يتضمّن الإصدار ميزة "وضع التوافق مع التطبيقات القديمة" كما هو منفذ في الرمز المصدر المفتوح لنظام التشغيل Android. وهذا يعني أنّه يجب ألّا تغيّر عمليات تنفيذ الأجهزة عوامل التفعيل أو الحدود الدنيا التي يتم عندها تفعيل وضع التوافق، ويجب ألّا تغيّر سلوك وضع التوافق نفسه.
- [7.2.1/H-0-1] يجب أن تتضمّن التطبيقات إمكانية استخدام تطبيقات "محرر أسلوب الإدخال" (IME) التابعة لجهات خارجية.
- [7.2.3/H-0-3] يجب توفير وظيفة "الصفحة الرئيسية" على جميع الشاشات المتوافقة مع Android التي توفّر الشاشة الرئيسية.
- [7.2.3/H-0-4] يجب توفير وظيفة "الرجوع" على جميع الشاشات المتوافقة مع Android ووظيفة "التطبيقات المستخدَمة مؤخرًا" على الأقل على أحد الشاشات المتوافقة مع Android.
- [7.2.3/H-0-2] يجب إرسال حدثي الضغط العادي والضغط مع الاستمرار
لدالّة الرجوع (
KEYCODE_BACK
) إلى التطبيق الذي يعمل في المقدّمة. يجب ألّا يستخدِم النظام هذه الأحداث ويمكن أن يتم تشغيلها من خارج جهاز Android (مثل الأجهزة الخارجية لوحة المفاتيح المتصلة بجهاز Android). - [7.2.4/H-0-1] يجب أن يتيح الجهاز إدخال البيانات من خلال شاشة اللمس.
- [7.2.4/H-SR-1] يُنصح بشدة بتشغيل
تطبيق المساعدة الذي يختاره المستخدم، أي التطبيق الذي ينفِّذ
VoiceInteractionService، أو نشاط يعالج
ACTION_ASSIST
عند الضغط مع الاستمرار علىKEYCODE_MEDIA_PLAY_PAUSE
أوKEYCODE_HEADSETHOOK
إذا كان النشاط الذي يعمل في المقدّمة لا يعالج أحداث الضغط مع الاستمرار هذه. - [7.3.1/H-SR-1] يُنصح بشدة بتضمين مقياس تسارع ثلاثي المحاور.
إذا كانت عمليات تنفيذ الأجهزة المحمولة باليد تتضمّن مقياس تسارع ثلاثي المحاور، يجب استيفاء الشروط التالية:
- [7.3.1/H-1-1] يجب أن يكون الجهاز قادرًا على تسجيل الأحداث التي تصل إلى تردد 100 هرتز على الأقل.
إذا كانت عمليات تنفيذ الأجهزة المحمولة باليد تتضمّن جهاز استقبال لنظام تحديد المواقع العالمي (GPS) أو نظام تحديد المواقع العالمي (GNSS) وتُبلغ عن
القدرة للتطبيقات من خلال علامة
ميزة android.hardware.location.gps
، يجب استيفاء الشروط التالية:
- [7.3.3/H-2-1] يجب الإبلاغ عن قياسات GNSS فور العثور عليها، حتى إذا لم يتم الإبلاغ عن موقع جغرافي تم احتسابه من نظام تحديد المواقع العالمي (GPS) أو نظام تحديد المواقع العالمي عبر الأقمار الصناعية (GNSS) بعد.
- [7.3.3/H-2-2] يجب الإبلاغ عن نطاقات GNSS الزائفة ومعدّلات النطاق الزائف، والتي تكون كافية لاحتساب الموقع الجغرافي ضمن 20 مترًا والسرعة ضمن 0.2 متر في الثانية في 95% من الوقت على الأقل، وذلك في ظروف السماء المفتوحة بعد تحديد الموقع الجغرافي، سواء كان الجهاز مثبّتًا أو متحركًا بمعدّل تسارع أقل من 0.2 متر في الثانية المربعة.
إذا كانت عمليات تنفيذ الأجهزة المحمولة باليد تتضمّن أداة جيروسكوب بثلاثة محاور، يجب استيفاء الشروط التالية:
- [7.3.4/H-3-1] يجب أن يكون الجهاز قادرًا على تسجيل الأحداث التي تصل إلى تردد 100 هرتز على الأقل.
- [7.3.4/H-3-2] يجب أن يكون الجهاز قادرًا على قياس تغييرات الاتجاه بسرعة تصل إلى 1,000 درجة في الثانية.
عمليات تنفيذ الأجهزة الجوّالة التي يمكنها إجراء مكالمة صوتية وتحديد
أي قيمة غير PHONE_TYPE_NONE
في getPhoneType
:
- [7.3.8/H] يجب أن يتضمّن الجهاز أداة استشعار التقارب.
عمليات تنفيذ الأجهزة المحمولة:
- [7.3.11/H-SR-1] يُنصح بتوفُّر أداة استشعار الوضع بـ 6 درجات حرية.
- [7.4.3/H] يجب أن يتضمّن الإصدار تقنية البلوتوث وتكنولوجيا Bluetooth LE.
إذا كانت عمليات تنفيذ الأجهزة المحمولة باليد تتضمّن جهاز كاميرا منطقيًا يسرد
الإمكانات باستخدام
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
،
يجب استيفاء الشروط التالية:
- [7.5.4/H-1-1] يجب أن يكون مجال الرؤية (FOV) عاديًا تلقائيًا ويجب أن يكون بين 50 و95 درجة.
عمليات تنفيذ الأجهزة المحمولة:
- [7.6.1/H-0-1] يجب أن يتوفّر مساحة تخزين غير متقلبة تبلغ 4 غيغابايت على الأقل لبيانات التطبيق الخاصة (المعروفة أيضًا باسم قسم "/data").
- [7.6.1/H-0-2] يجب أن يعرض القيمة "true" لملف تعريف الارتباط
ActivityManager.isLowRamDevice()
عندما تكون سعة الذاكرة المتاحة للنواة ومساحة المستخدم أقل من 1 غيغابايت.
إذا كانت عمليات تنفيذ الأجهزة الجوّالة تعلن عن توافقها مع ABI 32 بت فقط:
[7.6.1/H-1-1] يجب أن تكون الذاكرة المتاحة للنواة ومساحة المستخدم 416 ميغابايت على الأقل إذا كانت الشاشة التلقائية تستخدم دقة framebuffer تصل إلى qHD (مثل FWVGA).
[7.6.1/H-2-1] يجب أن تكون الذاكرة المتاحة للنواة ومساحة المستخدم 592 ميغابايت على الأقل إذا كانت الشاشة التلقائية تستخدم دقة framebuffer تصل إلى HD+ (مثل HD وWSVGA).
[7.6.1/H-3-1] يجب أن تكون الذاكرة المتاحة للنواة ومساحة المستخدم 896 ميغابايت على الأقل إذا كانت الشاشة التلقائية تستخدم دقة framebuffer تصل إلى FHD (مثل WSXGA+).
[7.6.1/H-4-1] يجب أن تكون الذاكرة المتاحة للنواة ومساحة المستخدم 1344 ميغابايت على الأقل إذا كانت الشاشة التلقائية تستخدم درجات دقة إطار الذاكرة المؤقتة تصل إلى QHD (مثل QWXGA).
إذا كانت عمليات تنفيذ الأجهزة الجوّالة تعلن عن توافقها مع أي واجهة برمجة تطبيقات (ABI) بإصدار 64 بت (مع أي واجهة برمجة تطبيقات بإصدار 32 بت أو بدونها):
[7.6.1/H-5-1] يجب أن تكون الذاكرة المتاحة للنواة ومساحة المستخدم بسعة 816 ميغابايت على الأقل إذا كانت الشاشة التلقائية تستخدم دقة إطارات الذاكرة المؤقتة التي تصل إلى qHD (مثل FWVGA).
[7.6.1/H-6-1] يجب أن تكون الذاكرة المتاحة للنواة ومساحة المستخدم 944 ميغابايت على الأقل إذا كانت الشاشة التلقائية تستخدم درجات دقة إطار الذاكرة حتى دقة عالية+ (مثلاً، دقة عالية أو WSVGA).
[7.6.1/H-7-1] يجب أن تكون الذاكرة المتاحة للنواة ومساحة المستخدم 1280 ميغابايت على الأقل إذا كانت الشاشة التلقائية تستخدم دقة إطار الذاكرة حتى FHD (مثل WSXGA+).
[7.6.1/H-8-1] يجب أن تكون الذاكرة المتاحة للنواة ومساحة المستخدم 1824 ميغابايت على الأقل إذا كانت الشاشة التلقائية تستخدم دقة إطارات الذاكرة المؤقتة التي تصل إلى QHD (مثل QWXGA).
يُرجى العِلم أنّ "الذاكرة المتاحة للنواة ومساحة المستخدم" أعلاه تشير إلى مساحة الذاكرة المقدَّمة بالإضافة إلى أي ذاكرة مخصّصة مسبقًا لمكونات الأجهزة، مثل الراديو والفيديو وما إلى ذلك، والتي لا تخضع لرقابة النواة في عمليات تنفيذ الأجهزة.
إذا كانت عمليات تنفيذ الأجهزة الجوّالة تتضمّن ذاكرة بسعة أقل من 1 غيغابايت أو تساويها تتوفّر للنواة ومساحة المستخدم، يجب استيفاء الشروط التالية:
- [7.6.1/H-9-1] يجب الإفصاح عن علامة الميزة
android.hardware.ram.low
. - [7.6.1/H-9-2] يجب أن يتوفّر لدى التطبيق 1.1 غيغابايت على الأقل من مساحة التخزين الدائمة لحفظ data الخاصة بالتطبيق (المعروفة أيضًا باسم قسم "/data").
إذا كانت عمليات تنفيذ الأجهزة الجوّالة تتضمّن أكثر من 1 غيغابايت من الذاكرة المتاحة للنواة ومساحة المستخدم، يجب استيفاء الشروط التالية:
- [7.6.1/H-10-1] يجب أن يتوفّر لدى الجهاز مساحة تخزين غير متقلبة بسعة 4 غيغابايت على الأقل لتخزين data الخاصة بالتطبيق (المعروفة أيضًا باسم "/data").
- يجب الإفصاح عن علامة الميزة
android.hardware.ram.normal
.
إذا كانت عمليات تنفيذ الأجهزة الجوّالة تتضمّن ذاكرة بسعة أكبر من 2 غيغابايت أو مساوية لها وأقل من 4 غيغابايت متاحة للنواة ومساحة المستخدم، يجب استيفاء الشروط التالية:
- [7.6.1/H-SR-1] يُنصح بشدة بتوفير مساحة المستخدم بنظام 32 بت فقط (كل من التطبيقات ورموز النظام)
إذا كانت عمليات تنفيذ الأجهزة الجوّالة تتضمّن ذاكرة أقل من 2 غيغابايت متاحة للنواة ومساحة المستخدم، يجب استيفاء الشروط التالية:
- [7.6.1/H-1-1] يجب أن تتوافق مع واجهة برمجة تطبيقات ثنائية واحدة فقط (إما 64 بت فقط أو 32 بت فقط).
عمليات تنفيذ الأجهزة المحمولة:
- [7.6.2/H-0-1] يجب عدم توفير مساحة تخزين مشترَكة للتطبيق أصغر من 1 غيغابايت.
- [7.7.1/H] يجب أن يتضمّن منفذ USB يتوافق مع وضع الأجهزة الملحقة.
إذا كانت عمليات تنفيذ الأجهزة المحمولة باليد تتضمّن منفذ USB متوافقًا مع وضع استخدام الأجهزة الطرفية، يجب استيفاء الشروط التالية:
- [7.7.1/H-1-1] يجب تنفيذ واجهة برمجة التطبيقات لنظام Android Open Accessory (AOA).
إذا كانت عمليات تنفيذ الأجهزة المحمولة باليد تتضمّن منفذ USB متوافقًا مع وضع المضيف، يجب استيفاء الشروط التالية:
- [7.7.2/H-1-1] يجب تنفيذ فئة الصوت عبر USB كما هو موضّح في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
عمليات تنفيذ الأجهزة المحمولة:
- [7.8.1/H-0-1] يجب أن يتضمّن الجهاز ميكروفونًا.
- [7.8.2/H-0-1] يجب أن يتضمّن الجهاز مخرجًا للصوت وأن يتم الإفصاح عنه
android.hardware.audio.output
.
إذا كانت عمليات تنفيذ الأجهزة الجوّالة قادرة على استيفاء جميع متطلبات الأداء لإتاحة وضع الواقع الافتراضي وتضمين إتاحة هذا الوضع، يجب استيفاء ما يلي:
- [7.9.1/H-1-1] يجب الإفصاح عن ميزة
android.hardware.vr.high_performance
. - [7.9.1/H-1-2] يجب أن يتضمّن التطبيق
تطبيقًا لتنفيذ
android.service.vr.VrListenerService
يمكن تفعيله من خلال تطبيقات VR عبرandroid.app.Activity#setVrModeEnabled
.
إذا كانت عمليات تنفيذ الأجهزة المزوّدة بشاشة تعمل باللمس تتضمّن منفذ USB-C واحدًا أو أكثر في وضع المضيف وتنفِّذ (فئة صوت USB)، بالإضافة إلى المتطلبات الواردة في الفقرة 7.7.2، يجب استيفاء ما يلي:
- [7.8.2.2/H-1-1] يجب توفير ربط البرامج التالي لرموز HID:
الوظيفة | عمليات الربط | السياق | السُلوك |
---|---|---|---|
A | صفحة استخدام HID: 0x0C استخدام HID: 0x0CD مفتاح kernel: KEY_PLAYPAUSE مفتاح Android: KEYCODE_MEDIA_PLAY_PAUSE |
تشغيل الوسائط | الإدخال: الضغط لفترة قصيرة النتيجة: التشغيل أو الإيقاف المؤقت |
الإدخال: الضغط مع الاستمرار الإخراج: تفعيل الأمر الصوتي الإرسال: android.speech.action.VOICE_SEARCH_HANDS_FREE إذا كان الجهاز
مقفلاً أو كانت شاشته مطفأة، يتم إرسالandroid.speech.RecognizerIntent.ACTION_WEB_SEARCH في الحالات الأخرى |
|||
مكالمة واردة | الإدخال: الضغط لفترة قصيرة النتيجة: قبول المكالمة |
||
الإدخال: الضغط مع الاستمرار النتيجة: رفض المكالمة |
|||
مكالمة جارية | الإدخال: الضغط لفترة قصيرة النتيجة: إنهاء المكالمة |
||
الإدخال: الضغط مع الاستمرار الإخراج: كتم صوت الميكروفون أو إعادة صوته |
|||
B | صفحة استخدام HID: 0x0C استخدام HID: 0x0E9 مفتاح kernel: KEY_VOLUMEUP مفتاح Android: VOLUME_UP |
تشغيل الوسائط، مكالمة جارية | الإدخال: الضغط لفترة قصيرة أو طويلة الإخراج: رفع مستوى صوت النظام أو سماعة الرأس |
C | صفحة استخدام HID: 0x0C استخدام HID: 0x0EA مفتاح kernel: KEY_VOLUMEDOWN مفتاح Android: VOLUME_DOWN |
تشغيل الوسائط، مكالمة جارية | الإدخال: الضغط لفترة قصيرة أو طويلة الإخراج: خفض مستوى صوت النظام أو سماعة الرأس |
D | صفحة استخدام HID: 0x0C استخدام HID: 0x0CF مفتاح kernel: KEY_VOICECOMMAND مفتاح Android: KEYCODE_VOICE_ASSIST |
الكل. يمكن تشغيلها في أيّ مثيل. | الإدخال: الضغط لفترة قصيرة أو طويلة النتيجة: تفعيل الطلب الصوتي |
- [7.8.2.2/H-1-2] يجب تنشيط ACTION_HEADSET_PLUG عند إدخال مقبس، ولكن فقط بعد تحديد واجهات الصوت ونقاط النهاية USB بشكل صحيح لتحديد نوع المحطة المتصلة.
عند رصد أنواع وحدات التحكّم في الصوت عبر USB 0x0302، يتم تنفيذ ما يلي:
- [7.8.2.2/H-2-1] يجب بث Intent ACTION_HEADSET_PLUG مع تحديد قيمة 0 لسمة "microphone" الإضافية.
عند رصد أنواع وحدات تحكّم الصوت عبر USB 0x0402، يتم تنفيذ ما يلي:
- [7.8.2.2/H-3-1] يجب بث Intent ACTION_HEADSET_PLUG مع تحديد قيمة 1 لسمة "microphone" الإضافية.
عند استدعاء واجهة برمجة التطبيقات AudioManager.getDevices() أثناء توصيل جهاز USB، يتم تنفيذ ما يلي:
[7.8.2.2/H-4-1] يجب إدراج جهاز من النوع AudioDeviceInfo.TYPE_USB_HEADSET ويكون دوره isSink() إذا كان حقل نوع وحدة الإدخال/الإخراج الصوتية عبر USB هو 0x0302.
[7.8.2.2/H-4-2] يجب إدراج جهاز من النوع AudioDeviceInfo.TYPE_USB_HEADSET ودور isSink() إذا كان حقل نوع وحدة التحكّم في الصوت عبر USB هو 0x0402.
[7.8.2.2/H-4-3] يجب إدراج جهاز من النوع AudioDeviceInfo.TYPE_USB_HEADSET ودور isSource() إذا كان حقل نوع تجهيز الصوت بمنفذ USB 0x0402.
[7.8.2.2/H-4-4] يجب إدراج جهاز من النوع AudioDeviceInfo.TYPE_USB_DEVICE ويكون دوره isSink() إذا كان حقل نوع وحدة الإدخال/الإخراج الصوتية عبر USB هو 0x603.
[7.8.2.2/H-4-5] يجب إدراج جهاز من النوع AudioDeviceInfo.TYPE_USB_DEVICE ويكون دوره isSource() إذا كان حقل نوع تجهيز الصوت بمنفذ USB 0x604.
[7.8.2.2/H-4-6] يجب إدراج جهاز من النوع AudioDeviceInfo.TYPE_USB_DEVICE ودور isSink() إذا كان حقل نوع وحدة التحكّم في الصوت USB يساوي 0x400.
[7.8.2.2/H-4-7] يجب إدراج جهاز من النوع AudioDeviceInfo.TYPE_USB_DEVICE ويكون دوره isSource() إذا كان حقل نوع وحدة التحكّم في الصوت عبر USB هو 0x400.
[7.8.2.2/H-SR-1] يُنصح بشدة عند توصيل جهاز محيطي للصوت بمنفذ USB-C بإجراء عملية سرد لموصّفات USB وتحديد أنواع المحطات وبث Intent ACTION_HEADSET_PLUG في أقل من 1000 ملي ثانية.
إذا كانت عمليات تنفيذ الأجهزة الجوّالة تعرِض android.hardware.audio.output
و
android.hardware.microphone
، يجب:
- [5.6(#56_audio-latency)/H-1-1] يجب أن يكون متوسّط وقت الاستجابة المستمر لسلسلة الإرسال والاستقبال 800 ملي ثانية أو أقل على مدار 5 قياسات، مع متوسّط اختلاف مطلق أقل من 100 ملي ثانية، على مسار واحد متوافق على الأقل.
إذا كانت عمليات تنفيذ الأجهزة المحمولة تتضمن محرّكًا لمسيًا واحدًا على الأقل، يجب استيفاء الشروط التالية:
- [7.10/ساعة]* يجب عدم استخدام كتلة دوّارة غريبة الأطوار (ERM) مشغّل لمسي (مُحرِّك اهتزازي).
- [7.10/ساعة]* يجب وضع المحرِّك بالقرب من المكان الذي يتم عادةً فيه حمل الجهاز أو لمسه باليدين.
- [7.10/H]* يجب تنفيذ جميع الثوابت العامة لسمة اللمسات الواضحة في android.view.HapticFeedbackConstants ، وهي (CLOCK_TICK وCONTEXT_CLICK وKEYBOARD_PRESS وKEYBOARD_RELEASE وKEYBOARD_TAP وLONG_PRESS وTEXT_HANDLE_MOVE وVIRTUAL_KEY وVIRTUAL_KEY_RELEASE وCONFIRM وREJECT وGESTURE_START وGESTURE_END).
- [7.10/ساعة]* يجب أن تُنفِّذ جميع الثوابت العامة لسمة اللمسات الواضحة في android.os.VibrationEffect ، وهي (EFFECT_TICK وEFFECT_CLICK وEFFECT_HEAVY_CLICK و EFFECT_DOUBLE_CLICK) وجميع الثوابت العامة لسمة اللمسات الغنية في android.os.VibrationEffect.Composition ، وهي (PRIMITIVE_CLICK وPRIMITIVE_TICK).
- [7.10/ساعة]* يجب أن تستخدم هذه الثابتة المرتبط عمليات الربط.
- [7.10/ساعة]* يجب أن يتّبع
تقييم الجودة
لواجهات برمجة التطبيقات
createOneShot()
وcreateWaveform()
. - [7.10/H]* يجب التحقّق من إمكانات توسيع نطاق amplitude
من خلال تنفيذ
android.os.Vibrator.hasAmplitudeControl()
.
المحرّك الخطي للمعايرة (LRA) هو نظام زنبرك ذو كتلة واحدة يمتلك ترددًا مميّزًا للمعايرة حيث تتحرك الكتلة في اتجاه الحركة المطلوبة.
إذا كانت عمليات تنفيذ الأجهزة المحمولة تتضمن عنصرًا واحدًا على الأقل من عناصر التحكّم المتعلّقة بالترددات التوافقية، يجب استيفاء الشروط التالية:
- [7.10/ساعة]* من المفترض أن يحرك المحرِّك اللمسي على محور X في اتجاه عمودي.
إذا كانت عمليات تنفيذ الأجهزة المحمولة تحتوي على محرّك لمسي وهو محرّك رنان خطي (LRA) على محور X، يجب استيفاء الشروط التالية:
- [7.10/ساعة]* يجب أن يكون تردد الرنين للمحور X LRA أقل من 200 هرتز.
إذا كانت عمليات تنفيذ الأجهزة الجوّالة تتّبع تعيين الثوابت اللمسية، فإنّها:
- [7.10/H]* يجب التحقّق من حالة التنفيذ من خلال تشغيل واجهتَي برمجة التطبيقات android.os.Vibrator.areAllEffectsSupported() وandroid.os.Vibrator.arePrimitvesSupported().
- [7.10/ساعة]* يجب إجراء تقييم للجودة للثوابت اللمسية.
- [7.10/H]* يجب أن توفّر إمكانية استخدام بديل للحدّ من خطر حدوث خطأ كما هو موضّح هنا.
2.2.2. وسائط متعددة
يجب أن تتيح عمليات تنفيذ الأجهزة الجوّالة تنسيقات ترميز و ترميز الصوت التالية وأن توفّرها للتطبيقات التابعة لجهات خارجية:
- [5.1/H-0-1] AMR-NB
- [5.1/H-0-2] AMR-WB
- [5.1/H-0-3] MPEG-4 AAC Profile (AAC LC)
- [5.1/H-0-4] MPEG-4 HE AAC Profile (AAC+)
- [5.1/H-0-5] AAC ELD (ترميز AAC المحسّن المنخفض التأخير)
يجب أن تتيح عمليات التنفيذ على الأجهزة الجوّالة تنسيقات ترميز الفيديوهات التالية وأن توفّرها للتطبيقات التابعة لجهات خارجية:
يجب أن تتيح آليات التنفيذ على الأجهزة الجوّالة تنسيقات فك ترميز الفيديوهات التالية وأن توفّرها للتطبيقات التابعة لجهات خارجية:
- [5.3/H-0-1] H.264 AVC
- [5.3/H-0-2] H.265 HEVC
- [5.3/H-0-3] MPEG-4 SP
- [5.3/H-0-4] VP8
- [5.3/H-0-5] VP9
2.2.3. البرامج
عمليات تنفيذ الأجهزة المحمولة:
- [3.2.3.1/H-0-1] يجب أن يتضمّن التطبيق
إمكانية معالجة طلبات
ACTION_GET_CONTENT
ACTION_OPEN_DOCUMENT
ACTION_OPEN_DOCUMENT_TREE
وACTION_CREATE_DOCUMENT
كما هو موضّح في مستندات حزمة SDK، وأن يقدّم للمستخدم إمكانية الوصول إلى بيانات مقدّم المستندات باستخدام واجهة برمجة التطبيقاتDocumentsProvider
. - [3.2.3.1/H-0-2]* يجب تحميل تطبيقات أو مكونات خدمة واحدة أو أكثر مزوّدة بمعالج للطلبات، وذلك لتطبيق جميع أنماط فلاتر الطلبات العامة التي تحدّدها طلبات التطبيق التالية المدرَجة هنا.
- [3.2.3.1/H-SR-1] يُنصح بشدة بتحميل تطبيق بريد إلكتروني مسبقًا يمكنه معالجة نوايا ACTION_SENDTO أو ACTION_SEND أو ACTION_SEND_MULTIPLE لإرسال رسالة إلكترونية.
- [3.4.1/H-0-1] يجب أن يوفّر التطبيق تنفيذًا كاملاً
لواجهة برمجة تطبيقات
android.webkit.Webview
. - [3.4.2/H-0-1] يجب أن يتضمّن التطبيق متصفحًا مستقلاً لتصفّح الويب من قِبل المستخدمين بشكل عام.
- [3.8.1/H-SR-1] يُنصح بشدة باستخدام مشغّل افتراضي يتيح تثبيت الاختصارات والتطبيقات المصغّرة وwidgetFeatures داخل التطبيق.
- [3.8.1/H-SR-2] يُنصح بشدة باستخدام مشغّل افتراضي يتيح الوصول السريع إلى ال اختصارات إضافية التي تقدّمها التطبيقات التابعة لجهات خارجية من خلال واجهة برمجة التطبيقات ShortcutManager.
- [3.8.1/H-SR-3] يُنصح بشدة بتضمين تطبيق مشغّل تلقائي يعرض شارات لرمز التطبيق.
- [3.8.2/H-SR-1] يُنصح بشدة بإتاحة التطبيقات المصغّرة التابعة لجهات خارجية.
- [3.8.3/H-0-1] يجب السماح للتطبيقات التابعة لجهات خارجية
بإرسال إشعارات إلى المستخدمين بشأن الأحداث البارزة من خلال فئات واجهتَي برمجة التطبيقات
Notification
وNotificationManager
. - [3.8.3/H-0-2] يجب أن تتيح الرسائل الإشعارات الغنية.
- [3.8.3/H-0-3] يجب أن يتيح التطبيق إرسال تنبيهات مفاجئة.
- [3.8.3/H-0-4] يجب أن يتضمّن ظلّ الإشعارات، ما يمنح المستخدم إمكانية التحكّم مباشرةً في الإشعارات (مثل الردّ أو الإيقاف المؤقت أو الإغلاق أو الحظر) من خلال ميزات مساعدة المستخدم، مثل buttons buttons أو لوحة التحكّم كما هو مُطبَّق في AOSP.
- [3.8.3/H-0-5] يجب عرض الخيارات
المقدَّمة من خلال
RemoteInput.Builder setChoices()
في مركز الإشعارات. - [3.8.3/H-SR-1] يُنصح بشدة
بعرض الخيار الأول المقدَّم من خلال
RemoteInput.Builder setChoices()
في نافذة الإشعارات بدون تفاعل إضافي من المستخدم. - [3.8.3/H-SR-2] يُنصح بشدة
بعرض جميع الخيارات المقدَّمة من خلال
RemoteInput.Builder setChoices()
في مركز الإشعارات عندما يوسّع المستخدم جميع الإشعارات في مركز الإشعارات. - [3.8.3.1/H-SR-1] يُنصح بشدة
بعرض الإجراءات التي تم ضبط
Notification.Action.Builder.setContextual
على أنّهاtrue
مع الردّات التي يعرضهاNotification.Remoteinput.Builder.setChoices
. - [3.8.4/H-SR-1] يُنصح بشدة بتنفيذ مساعد على الجهاز لمعالجة الإجراء المساعد.
إذا كانت عمليات تنفيذ الأجهزة الجوّالة تتيح إجراء "المساعدة"، يجب أن تستوفي الشروط التالية:
- [3.8.4/H-SR-2] يُنصح بشدة
باستخدام الضغط مع الاستمرار على مفتاح
HOME
كتفاعل محدّد لتشغيل تطبيق المساعدة كما هو موضّح في الفقرة 7.2.3. يجب أن يؤدي إلى تشغيل تطبيق المساعدة الذي يختاره المستخدم، أي التطبيق الذي ينفذVoiceInteractionService
، أو نشاط يعالج النيةACTION_ASSIST
.
إذا كانت عمليات تنفيذ الأجهزة الجوّالة تتيح استخدام conversation notifications
وتجميعها في قسم منفصل عن الإشعارات غير المحادثة التي تتضمن تنبيهات وإشعارات صامتة، يجب:
- [3.8.4/H-1-1]* يجب عرض إشعارات المحادثات قبل الإشعارات غير المتعلّقة بالمحادثات، باستثناء إشعارات الخدمات التي تعمل في المقدّمة وإشعارات importance:high.
إذا كانت عمليات تنفيذ أجهزة Android المحمولة تتيح قفل الشاشة، يجب أن تستوفي الشروط التالية:
- [3.8.10/H-1-1] يجب عرض إشعارات شاشة القفل، بما في ذلك نموذج إشعار الوسائط.
إذا كانت عمليات تنفيذ الأجهزة الجوّالة تتيح شاشة قفل آمنة، يجب أن تستوفي الشروط التالية:
- [3.9/H-1-1] يجب تنفيذ المجموعة الكاملة من سياسات إدارة الجهاز المحدّدة في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
إذا كانت عمليات تنفيذ الأجهزة الجوّالة تتضمّن إتاحة استخدام واجهتَي برمجة التطبيقات
ControlsProviderService
وControl
والسماح للتطبيقات التابعة لجهات خارجية بنشر عناصر التحكّم في الأجهزة، يجب استيفاء الشروط التالية:
- [3.8.16/H-1-1] يجب الإفصاح عن علامة
الميزة
android.software.controls
وضبطها علىtrue
. - [3.8.16/H-1-2] يجب أن يوفّر التطبيق للمستخدم ميزات تتيح له إضافة عناصر التحكّم المفضّلة لديه في الجهاز وتعديلها واختيارها وتشغيلها من عناصر التحكّم المسجّلة من خلال التطبيقات التابعة لجهات خارجية من خلال واجهات برمجة التطبيقات
ControlsProviderService
وControl
. - [3.8.16/H-1-3] يجب توفير إمكانية الوصول إلى هذه الميزة للمستخدم في غضون ثلاث تفاعلات من مشغّل التطبيقات التلقائي.
- [3.8.16/H-1-4] يجب أن يعرض هذا العنصر المتاح للمستخدمين اسم كل تطبيق تابع لجهة خارجية يقدّم عناصر تحكّم من خلال واجهة برمجة التطبيقات
ControlsProviderService
بالإضافة إلى أي حقول محدّدة تقدّمها واجهات برمجة التطبيقاتControl
بدقة.
في المقابل، إذا لم تُنفِّذ عمليات تنفيذ الأجهزة الجوّالة عناصر التحكّم هذه، يحدث ما يلي:
- [3.8.16/H-2-1] يجب الإبلاغ عن
null
لأجل واجهتَي برمجة التطبيقاتControlsProviderService
وControl
. - [3.8.16/H-2-2] يجب الإفصاح عن علامة
الميزة
android.software.controls
وضبطها علىfalse
.
عمليات تنفيذ الأجهزة المحمولة:
- [3.10/H-0-1] يجب أن يتيح استخدام خدمات сторонних جهات لتحسين إمكانية الاستخدام.
- [3.10/H-SR-1] يُنصح بشدة-1 بتثبيت خدمات اتّباع الإجراءات اللازمة لتحسين إمكانية الاستخدام على الجهاز مسبقًا، والتي توفّر وظائف مماثلة أو أفضل مما توفره خدمات اتّباع الإجراءات اللازمة لتحسين إمكانية الاستخدام "الوصول عبر مفتاح التحويل" وTalkBack (للغات المتوافقة مع ميزة تحويل الكلام إلى نص) كما هو موضّح في مشروع talkback المفتوح المصدر.
- [3.11/H-0-1] يجب أن تتيح إمكانية تثبيت محرّكات تحويل النص إلى كلام التابعة لجهات خارجية.
- [3.11/H-SR-1] يُنصح بشدة بتضمين محرك تحويل النص إلى كلام يتيح اللغات المتاحة على الجهاز.
- [3.13/H-SR-1] يُنصح بشدة بتضمين مكوّن واجهة مستخدم "الإعدادات السريعة".
إذا كانت عمليات تنفيذ الأجهزة الجوّالة التي تعمل بنظام التشغيل Android تعلن عن توافقها مع FEATURE_BLUETOOTH
أو
FEATURE_WIFI
، يجب أن تستوفي الشروط التالية:
- [3.16/H-1-1] يجب أن يتيح الجهاز ميزة إقران الجهاز المصاحب.
إذا تم توفير وظيفة التنقّل كإجراء على الشاشة يستند إلى الإيماءات:
- [7.2.3/H] يجب ألا يزيد ارتفاع منطقة التعرّف على الإيماءات لميزة "منزل" عن 32 dp من أسفل الشاشة.
إذا كانت عمليات تنفيذ الأجهزة الجوّالة توفّر وظيفة تنقّل بالإيماءات من أي مكان على الحافتَين اليمنى واليسرى للشاشة:
- [7.2.3/H-0-1] يجب أن يكون عرض منطقة الإيماءات الخاصة بوظيفة التنقّل أقل من 40 وحدة كثافة بكسل على كل جانب. يجب أن يكون عرض منطقة الإيماءة 24 وحدة بكسل بشكل تلقائي.
إذا كانت عمليات تنفيذ الأجهزة الجوّالة تتيح شاشة قفل آمنة وكانت تحتوي على ذاكرة بسعة 2 غيغابايت أو أكثر متاحة للنواة ومساحة المستخدم، يجب أن تستوفي المتطلبات التالية:
- [3.9/H-1-2] يجب الإفصاح عن توفّر الملفات الشخصية المُدارة من خلال علامة ميزة
android.software.managed_users
.
إذا كانت عمليات تنفيذ الأجهزة الجوّالة التي تعمل بنظام التشغيل Android تقدّم بيانًا يتضمّن إمكانية استخدام الكاميرا من خلال
android.hardware.camera.any
، يجب أن تستوفي المتطلبات التالية:
- [7.5.4/H-1-1] يجب الالتزام بنيتي
android.media.action.STILL_IMAGE_CAMERA
وandroid.media.action.STILL_IMAGE_CAMERA_SECURE
وتشغيل الكاميرا في وضع الصور الثابتة كما هو موضّح في حزمة تطوير البرامج (SDK). - [7.5.4/H-1-2] يجب الالتزام
android.media.action.VIDEO_CAMERA
بطلب تشغيل الكاميرا في وضع الفيديو كما هو موضّح في حزمة تطوير البرامج (SDK).
2.2.4. الأداء والقوة
- [8.1/H-0-1] وقت استجابة ثابت للإطار يجب ألا يحدث وقت استجابة غير متّسق للّقطات أو تأخّر في عرض اللقطات أكثر من 5 لقطات في الثانية، ويجب أن يكون أقل من لقطة واحدة في الثانية.
- [8.1/H-0-2] وقت استجابة واجهة المستخدم يجب أن تضمن عمليات تنفيذ الأجهزة تجربة استخدام ذات وقت استجابة منخفض من خلال الانتقال في قائمة تتضمّن 10,000 إدخال كما هو محدّد في مجموعة أدوات اختبار التوافق (CTS) لنظام التشغيل Android في أقل من 36 ثانية.
- [8.1/H-0-3] تبديل المهام عند تشغيل عدة تطبيقات، يجب ألا يستغرق إعادة تشغيل تطبيق قيد التشغيل سوى أقل من ثانية واحدة.
عمليات تنفيذ الأجهزة المحمولة:
- [8.2/H-0-1] يجب أن يضمن الأداء التسلسلي للكتابة سرعة لا تقل عن 5 ميغابايت في الثانية.
- [8.2/H-0-2] يجب أن يضمن كتابة عشوائية بسرعة لا تقل عن 0.5 ميغا بايت في الثانية.
- [8.2/H-0-3] يجب أن تضمن سرعة قراءة متسلسلة تبلغ 15 ميغابايت في الثانية على الأقل.
- [8.2/H-0-4] يجب أن تضمن سرعة قراءة ملف عشوائي بمعدل 3.5 ميغابايت في الثانية على الأقل.
إذا كانت عمليات تنفيذ الأجهزة المحمولة باليد تتضمّن ميزات لتحسين إدارة استهلاك الطاقة في الجهاز والمضمّنة في AOSP أو توسيع نطاق الميزات المضمّنة في AOSP، يجب استيفاء الشروط التالية:
- [8.3/H-1-1] يجب أن توفّر واجهة المستخدم إمكانية تفعيل وإيقاف ميزة توفير شحن البطارية.
- [8.3/H-1-2] يجب أن توفّر واجهة المستخدم إمكانية عرض جميع التطبيقات المعفاة من وضعَي "الاستراحة" و"الاستعداد" لتوفير الطاقة.
عمليات تنفيذ الأجهزة المحمولة:
- [8.4/H-0-1] يجب توفيرملف شخصي للطاقة لكل مكوّن يحدِّد قيمة الاستهلاك الحالي لكل مكوّن من مكوّنات الأجهزة ومعدل استنزاف البطارية التقريبي الذي تتسبّب فيه المكوّنات بمرور الوقت كما هو موضّح في الموقع الإلكتروني لمشروع Android المفتوح المصدر.
- [8.4/H-0-2] يجب الإبلاغ عن جميع قيم استهلاك الطاقة بالمللي أمبير ساعة (mAh).
- [8.4/H-0-3] يجب الإبلاغ عن استهلاك طاقة وحدة المعالجة المركزية (CPU)
حسب رقم تعريف مستخدم لكل عملية. يستوفي "مشروع مفتوح المصدر لنظام Android"
المتطلبات من خلال تنفيذ وحدة نواة
uid_cputime
. - [8.4/H-0-4] يجب أن يتيح مطوّر التطبيق استخدام الطاقة
هذا من خلال أمر shell
adb shell dumpsys batterystats
. - [8.4/ح] يجب تحديد مصدره على أنّه مكوّن الجهاز نفسه في حال تعذُّر تحديد مصدر استهلاك طاقة مكوّن الجهاز لتطبيق معيّن.
إذا كانت عمليات تنفيذ الأجهزة المحمولة في اليد تتضمّن شاشة أو إخراج فيديو، يجب استيفاء الشروط التالية:
- [8.4/H-1-1] يجب أن يراعي الجهاز نية العميل المتعلّقة بالطاقة
android.intent.action.POWER_USAGE_SUMMARY
وأن يعرض قائمة إعدادات تعرض مقدار استهلاك الطاقة.
2.2.5. نموذج الأمان
عمليات تنفيذ الأجهزة المحمولة:
- [9.1/H-0-1] يجب السماح للتطبيقات التابعة لجهات خارجية بالوصول إلى
إحصاءات الاستخدام من خلال إذن
android.permission.PACKAGE_USAGE_STATS
، ويجب توفير آلية يمكن للمستخدم الوصول إليها لمنح إذن الوصول إلى هذه التطبيقات أو إبطاله استجابةً لطلبandroid.settings.ACTION_USAGE_ACCESS_SETTINGS
.
عمليات تنفيذ الأجهزة المحمولة:
- [9.11/H-0-2] يجب الاحتفاظ بنسخة احتياطية من عملية تنفيذ ملف تخزين المفاتيح باستخدام بيئة تنفيذ معزولة.
- [9.11/H-0-3] يجب أن تتضمّن عمليات تنفيذ خوارزميات التشفير RSA وAES وECDSA وHMAC ووظائف التجزئة من مجموعة MD5 وSHA1 وSHA-2 لتتوافق بشكل صحيح مع خوارزميات المتاحة في نظام "متجر مفاتيح Android" في منطقة معزولة بشكل آمن عن الرمز البرمجي الذي يعمل على النواة والإصدارات الأحدث. يجب أن تحظر ميزة "العزل الآمن" جميع الآليات المحتملة التي يمكن من خلالها لرمز kernel أو مساحة المستخدم الوصول إلى الحالة الداخلية للبيئة المعزولة، بما في ذلك DMA. يستوفي "المشروع المفتوح المصدر لنظام Android" (AOSP) هذا الشرط من خلال استخدام عملية تنفيذ Trusty، ولكن هناك خياران بديلة هما حلّ آخر يستند إلى ARM TrustZone أو عملية تنفيذ آمنة تمت مراجعتها من قِبل جهة خارجية لتوفير عزل مناسب يستند إلى أداة إدارة الأجهزة الافتراضية.
- [9.11/H-0-4] يجب تنفيذ مصادقة شاشة القفل في بيئة التنفيذ المعزولة، والسماح باستخدام المفاتيح المرتبطة بالمصادقة فقط عند اختلاف. يجب تخزين بيانات اعتماد شاشة القفل بطريقة لا تسمح إلا لبيئة التنفيذ المعزولة بإجراء مصادقة شاشة القفل. يقدّم مشروع Android Open Source Project الإصدارات السابقة من Gatekeeper Hardware Abstraction Layer (HAL) وTrusty، والتي يمكن استخدامها لاستيفاء هذا الشرط.
- [9.11/H-0-5] يجب أن تتيح المصادقة على المفاتيح حيث يتم حماية مفتاح توقيع المصادقة باستخدام جهاز آمن ويتم تنفيذ التوقيع على جهاز آمن. يجب مشاركة مفاتيح توقيع الإثبات على عدد كبير بما يكفي من الأجهزة لمنع استخدام المفاتيح كمعرّفات للأجهزة. وإحدى الطرق لاستيفاء هذا الشرط هي مشاركة مفتاح الإثبات نفسه ما لم يتم تصنيع 100,000 وحدة على الأقل من رمز التخزين التعريفي معيّن. إذا تم إنتاج أكثر من 100,000 وحدة من رمز التخزين التعريفي، قد يتم استخدام مفتاح مختلف لكل 100,000 وحدة.
- [9/H-0-1] يجب الإفصاح عن ميزة "android.hardware.security.model.compatible" .
يُرجى العلم أنّه إذا سبق إطلاق عملية تنفيذ على جهاز باستخدام إصدار قديم من Android
، يتم إعفاء هذا الجهاز من شرط توفُّر متجر مفاتيح
مدعوم من بيئة تنفيذ معزولة ومتوافق مع شهادة إثبات ملكية المفتاح،
ما لم يعلن عن ميزة android.hardware.fingerprint
التي تتطلّب متجر مفاتيح
مدعومًا من بيئة تنفيذ معزولة.
عند توفُّر شاشة قفل آمنة في عمليات تنفيذ الأجهزة الجوّالة، يجب أن تستوفي الشروط التالية:
- [9.11/H-1-1] يجب السماح للمستخدم باختيار أقصر مهلة للوضع "الاستراحة"، أي مدة الانتقال من الحالة "غير مقفل" إلى الحالة "مقفَل"، بحيث لا تزيد عن 15 ثانية.
- [9.11/H-1-2] يجب أن توفّر إمكانية للمستخدم لإخفاء الإشعارات وإيقاف جميع أشكال المصادقة باستثناء المصادقة الأساسية الموضّحة في 9.11.1 شاشة القفل الآمنة. يستوفي AOSP المتطلّبات المتعلقة بوضع التأمين.
إذا كانت عمليات تنفيذ الأجهزة الجوّالة تتضمّن مستخدمين متعدّدين ولم يتم الإفصاح عن علامة ميزة android.hardware.telephony
، يتم تنفيذ ما يلي:
- [9.5/H-2-1] يجب أن تتيح إمكانية استخدام الملفات الشخصية المحظورة، وهي ميزة تتيح لمالكي الأجهزة إدارة مستخدمين إضافيين وتحديد أذوناتهم على الجهاز. باستخدام الملفات الشخصية المحظورة، يمكن لمالكي الأجهزة إعداد بيئات منفصلة بسرعة ليستخدمها مستخدمون إضافيون، مع إمكانية إدارة قيود أكثر دقة في التطبيقات التي تتوفّر في تلك البيئات.
إذا كانت عمليات تنفيذ الأجهزة الجوّالة تتضمّن مستخدمين متعدّدين ويُعلن عنها باستخدام علامة ميزة android.hardware.telephony
، يتم تنفيذ ما يلي:
- [9.5/H-3-1] يجب ألّا يتوافق مع الملفات الشخصية المقيّدة، بل يجب أن يكون متوافقًا مع تنفيذ عناصر التحكّم في AOSP لتشغيل /إيقاف إمكانية وصول المستخدمين الآخرين إلى المكالمات الصوتية والرسائل القصيرة.
يتيح نظام التشغيل Android من خلال واجهة برمجة التطبيقات System API VoiceInteractionService آلية لرصد الكلمات المهمة الصوتية بشكل آمن وبدون إشارة إلى الوصول إلى الميكروفون.
إذا كانت عمليات تنفيذ الأجهزة الجوّالة متوافقة مع System API
HotwordDetectionService
أو آلية أخرى لرصد الكلمات الرئيسية بدون إعلام بالوصول إلى المايكروفون، يجب أن تستوفي المتطلبات التالية:
- [9.8/H-1-1] يجب التأكّد من أنّ خدمة رصد الكلمات الرئيسية لا يمكنها إرسال سوى البيانات إلى System أو ContentCaptureService
- [9.8/H-1-2] يجب التأكّد من أنّ خدمة رصد الكلمات الرئيسية لا يمكنها نقل سوى data
الصوتية من الميكروفون أو البيانات المستمدة منها إلى خادم النظام من خلال واجهة برمجة التطبيقات
HotwordDetectionService
، أو إلىContentCaptureService
من خلال واجهة برمجة التطبيقاتContentCaptureManager
. - [9.8/H-1-3] يجب عدم توفير صوت من الميكروفون أطول من 30 ثانية لطلب individual individual hardware-triggered request إلى خدمة رصد الكلمات الرئيسية.
- [9.8/H-1-4] يجب عدم تقديم صوت من الميكروفون تم تخزينه مؤقتًا ويبلغ عمره أكثر من 8 ثوانٍ لطلب individual request إلى خدمة رصد الكلمات المهمة.
- [9.8/H-1-5] يجب عدم إرسال تسجيلات صوتية مسجّلة من الميكروفون أقدم من 30 ثانية إلى خدمة التفاعل الصوتي أو كيان مشابه.
- [9.8/H-1-6] يجب عدم السماح بنقل أكثر من 100 بايت من البيانات خارج خدمة رصد الكلمات الرئيسية عند ظهور كل نتيجة ناجحة للكلمة الرئيسية.
- [9.8/H-1-7] يجب عدم السماح بنقل أكثر من 5 بت من البيانات خارج خدمة رصد الكلمات الرئيسية في كل نتيجة سلبية للكلمة الرئيسية.
- [9.8/H-1-8] يجب عدم السماح بنقل البيانات خارج خدمة الكشف عن الكلمات المميّزة إلا عند تلقّي طلب التحقّق من الكلمة المميّزة من خادم النظام.
- [9.8/H-1-9] يجب عدم السماح لتطبيق يمكن للمستخدم تثبيته بتقديم خدمة رصد الكلمات الرئيسية.
- [9.8/H-1-10] يجب عدم عرض بيانات كمية عن استخدام الميكروفون من قِبل خدمة رصد الكلمات الرئيسية في واجهة المستخدم.
- [9.8/H-1-11] يجب تسجيل عدد البايتات المضمّنة في كل عملية إرسال من خدمة رصد الكلمات الرئيسية للسماح بفحصها من قِبل باحثي الأمان.
- [9.8/H-1-12] يجب أن يتيح وضع تصحيح الأخطاء تسجيل المحتوى الأوّلي لكل عملية إرسال من خدمة رصد الكلمات الرئيسية للسماح لباحثي الأمان بالفحص.
- [9.8/H-1-13] يجب إعادة تشغيل العملية التي تستضيف خدمة رصد الكلمات الرئيسية مرة واحدة على الأقل كل ساعة أو بعد كل 30 حدثًا يتم تشغيله بالأجهزة، أيهما أولاً.
- [9.8/H-1-14] يجب عرض مؤشر الميكروفون، كما هو موضّح في القسم 9.8.2، عند إرسال نتيجة كلمة تشغيل ناجحة إلى خدمة التفاعل الصوتي أو كيان مشابه.
- [9.8/H-SR-1] يُنصح بشدة بإشعار المستخدمين قبل ضبط التطبيق كمقدّم خدمة رصد الكلمات الرئيسية.
- [9.8/H-SR-2] يُنصح بشدة بعدم السماح بإرسال data غير منظَّمة خارج خدمة رصد الكلمات الرئيسية.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن تطبيقًا يستخدم واجهة برمجة التطبيقات System API
HotwordDetectionService
أو آلية مشابهة لرصد الكلمات المفتاحية بدون إعلام باستخدام
الميكروفون، يجب أن يستوفي التطبيق الشروط التالية:
- [9.8/H-2-1] يجب تقديم إشعار واضح للمستخدم بشأن كل عبارة من عبارات الكلمات التلقائية المتوافقة.
- [9.8/H-2-2] يجب عدم الاحتفاظ ببيانات الصوت الأوّلية أو البيانات المستمدة منها من خلال خدمة رصد الكلمات الرئيسية.
- [9.8/H-2-3] يجب عدم نقل بيانات ملف صوتي أو
بيانات يمكن استخدامها لإعادة إنشاء الملف الصوتي (كليًا أو جزئيًا) أو محتوًى صوتيًا غير مرتبط بعبارة الطلب نفسها، إلا إلى
ContentCaptureService
.
إذا كانت عمليات تنفيذ الأجهزة الجوّالة تعرِض android.hardware.microphone
، يعني ذلك ما يلي:
- [9.8.2/H-4-1] يجب عرض مؤشر الميكروفون عندما
يحصل تطبيق على بيانات صوتية من الميكروفون، ولكن ليس عندما يتم استخدام
الميكروفون من قِبل
HotwordDetectionService
أوSOURCE_HOTWORD
أوContentCaptureService
أو التطبيقات التي تمتلك الأدوار الموضّحة في الفقرة 9.1 باستخدام معرّف CDD [C-4-X]. . - [9.8.2/H-4-2] يجب عرض قائمة التطبيقات
المستخدَمة مؤخرًا والنشطة التي تستخدم الميكروفون كما هو موضّح في
PermissionManager.getIndicatorAppOpUsageData()
، بالإضافة إلى أي رسائل تحديد مصدر مرتبطة بها. - [9.8.2/H-4-3] يجب عدم إخفاء مؤشر الميكروفون ل تطبيقات النظام التي تتضمّن واجهات مستخدم مرئية أو تفاعلًا مباشرًا مع المستخدم.
- [9.8.2/H-4-4] يجب عرض قائمة التطبيقات المستخدَمة مؤخرًا والنشطة
التي تستخدم الميكروفون كما هو موضّح في
PermissionManager.getIndicatorAppOpUsageData()
، بالإضافة إلى أي رسائل تحديد مصدر مرتبطة بها.
إذا كانت عمليات تنفيذ الأجهزة الجوّالة تعرِض android.hardware.camera.any
، يعني ذلك ما يلي:
- [9.8.2/H-5-1] يجب عرض مؤشر الكاميرا عندما يحصل أحد التطبيقات على بيانات الكاميرا المباشرة، ولكن ليس عندما تحصل التطبيقات التي تمتلك الأدوار المذكورة في الفقرة 9.1 باستخدام معرّف CDD [C-4-X] على بيانات الكاميرا فقط.
- [9.8.2/H-5-2] يجب عرض التطبيقات المستخدَمة مؤخرًا والتطبيقات النشطة التي تستخدم
الكاميرا كما هو موضّح في
PermissionManager.getIndicatorAppOpUsageData()
، بالإضافة إلى أي رسائل تحديد مصدر مرتبطة بها. - [9.8.2/H-5-3] يجب عدم إخفاء مؤشر الكاميرا في تطبيقات النظام التي تتضمّن واجهات مستخدم مرئية أو تفاعلًا مباشرًا مع المستخدم.
2.2.6. توافق أدوات المطوّرين وخياراته
عمليات تنفيذ الأجهزة الجوّالة (* لا تنطبق على الأجهزة اللوحية):
- [6.1/H-0-1]* يجب أن يكون متوافقًا مع الأمر shell
cmd testharness
.
عمليات تنفيذ الأجهزة الجوّالة ("* لا ينطبق على الجهاز اللوحي"):
- Perfetto
- [6.1/H-0-2]* يجب أن يعرض
/system/bin/perfetto
ملفًا ثنائيًا لمستخدم shell يكون cmdline متوافقًا مع مستندات perfetto. - [6.1/H-0-3]* يجب أن يقبل ملف perfetto الثنائي كأحد المدخلات ملف إعدادات protobuf متوافقًا مع المخطّط المحدّد في مستندات perfetto.
- [6.1/H-0-4]* يجب أن يكتب ملف perfetto الثنائي أثر protobuf كأحد المخرجات يتوافق مع المخطط المحدّد في مستندات perfetto.
- [6.1/H-0-5]* يجب أن يوفّر، من خلال ملف برمجي binaro لـ perfetto، على الأقل مصادر البيانات الموضّحة في مستندات perfetto.
- [6.1/H-0-6]* يجب أن يكون العميل المُتتبّع في perfetto
مفعّلاً تلقائيًا (خاصية النظام
persist.traced.enable
).
- [6.1/H-0-2]* يجب أن يعرض
2.2.7. فئة أداء الوسائط على الأجهزة الجوّالة
راجِع القسم 7.11 للاطّلاع على تعريف فئة أداء الوسائط.
2.2.7.1. الوسائط
إذا كانت عمليات تنفيذ الأجهزة الجوّالة تعرض android.os.Build.VERSION_CODES.R
لحالة
android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS
، يعني ذلك أنّها:
- يجب استيفاء متطلبات الوسائط الواردة في CDD لنظام التشغيل Android 11 القسم 2.2.7.1
إذا كانت عمليات تنفيذ الأجهزة الجوّالة تعرض android.os.Build.VERSION_CODES.S
لـ android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS
، يعني ذلك أنّها:
- [5.1/H-1-1] يجب الإعلان عن الحد الأقصى لعدد جلسات فك ترميز الفيديو في الأجهزة
التي يمكن تشغيلها بشكل متزامن في أي مجموعة من برامج الترميز من خلال الطريقتَين
CodecCapabilities.getMaxSupportedInstances()
وVideoCapabilities.getSupportedPerformancePoints()
. - [5.1/H-1-2] يجب أن يكون متوافقًا مع 6 عمليات تشغيل لملفات ترميز الفيديو في الأجهزة (AVC أو HEVC أو VP9* أو الإصدارات الأحدث) في أي مجموعة من برامج الترميز التي تعمل بالتزامن بدقة 720p بمعدّل 30 لقطة في الثانية. *لا يلزم سوى مثيلَين في حال توفّر برنامج ترميز VP9.
- [5.1/H-1-3] يجب الإعلان عن الحد الأقصى لعدد جلسات فاقدي ترميز الفيديو في الأجهزة
التي يمكن تشغيلها بشكل متزامن في أي مجموعة من برامج الترميز من خلال الأسلوبين
CodecCapabilities.getMaxSupportedInstances()
وVideoCapabilities.getSupportedPerformancePoints()
. - [5.1/H-1-4] يجب أن يكون متوافقًا مع 6 عمليات برمجية لجلسات رمز ترميز الفيديو في الأجهزة (AVC أو HEVC أو VP9* أو الإصدارات الأحدث) في أي مجموعة من برامج الترميز التي تعمل بالتزامن بدقة 720p بمعدّل 30 لقطة في الثانية. *لا يلزم سوى مثيلَين في حال توفّر برنامج ترميز VP9.
- [5.1/H-1-5] يجب الإعلان عن الحد الأقصى لعدد جلسات ترميز وفك ترميز الفيديوهات باستخدام الأجهزة التي يمكن تشغيلها بشكل متزامن في أي مجموعة من برامج الترميز من خلال
CodecCapabilities.getMaxSupportedInstances()
وVideoCapabilities.getSupportedPerformancePoints()
. - [5.1/H-1-6] يجب أن يكون الجهاز مزوّدًا بـ 6 عمليات فك ترميز للفيديو و6 جلسات لتشفير الفيديو (AVC أو HEVC أو VP9* أو الإصدارات الأحدث) في أي مجموعة من برامج الترميز التي تعمل بشكل متزامن بدقة 720p ومعدل 30 لقطة في الثانية. *لا يلزم سوى مثيلَين في حال توفّر برنامج ترميز VP9.
- [5.1/H-1-7] يجب أن يكون وقت استجابة إعداد ترميز الفيديو 50 ملي ثانية أو أقل لجلسة ترميز فيديو بدقة 1080p أو أقل لجميع برامج ترميز الفيديو المزوّدة بالأجهزة (باستثناء برنامج ترميز Dolby Vision) عند تحميلها. يتم تعريف "التحميل" هنا على أنّه جلسة تحويل ترميز متزامنة للفيديوهات فقط من دقة 1080p إلى 720p باستخدام برامج ترميز فيديو على الأجهزة مع بدء تسجيل الصوت والفيديو بدقة 1080p.
- [5.1/H-1-8] يجب أن يكون وقت استجابة إعداد ترميز الصوت 40 ملي ثانية أو أقل لجلسة ترميز صوت بمعدل 128 كيلوبت في الثانية أو أقل لجميع برامج ترميز الصوت عند معالجة حمولة. يتم تعريف "التحميل" هنا على أنّه جلسة تحويل ترميز متزامنة للفيديوهات فقط من دقة 1080p إلى 720p باستخدام برامج ترميز الفيديو على الأجهزة مع بدء تسجيل الصوت والفيديو بدقة 1080p.
- [5.3/H-1-1] يجب ألا يتم إسقاط أكثر من لقتَين في 10 ثوانٍ (أي أقل من 0.333 في المئة من عدد اللقطات) لجلسة فيديو بدقة 1080p وعدد لقطات في الثانية 60 أثناء التحميل. يتم تعريف "الحمل" على أنّه جلسة تحويل ترميز متزامنة للفيديوهات فقط من دقة 1080p إلى 720p باستخدام برامج ترميز الفيديو للأجهزة، بالإضافة إلى تشغيل محتوى صوتي بتنسيق AAC بمعدّل 128 كيلوبت في الثانية.
- [5.3/H-1-2] يجب عدم إسقاط أكثر من إطارَين في 10 ثوانٍ أثناء تغيير درجة دقة الفيديو في جلسة فيديو بمعدل 60 لقطة في الثانية أثناء التحميل. يتم تعريف "الحمل" على أنّه جلسة ترميز للفيديوهات فقط تتم بشكل متزامن من دقة 1080p إلى 720p باستخدام برامج ترميز للفيديوهات على الأجهزة، بالإضافة إلى تشغيل صوت بترميز AAC بمعدّل 128 كيلوبت في الثانية.
- [5.6/H-1-1] يجب أن يكون وقت استجابة النقر إلى الصوت أقل من 100 ملي ثانية باستخدام اختبار النقر إلى الصوت في OboeTester أو اختبار النقر إلى الصوت في CTS Verifier.
2.2.7.2. الكاميرا
إذا كانت عمليات تنفيذ الأجهزة الجوّالة تعرض android.os.Build.VERSION_CODES.R
لحالة
android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS
، يعني ذلك أنّها:
- يجب استيفاء متطلبات الكاميرا الواردة في CDD لنظام التشغيل Android 11 القسم 2.2.7.2
إذا كانت عمليات تنفيذ الأجهزة الجوّالة تعرض android.os.Build.VERSION_CODES.S
لـ android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS
، يعني ذلك أنّها:
- [7.5/H-1-1] يجب أن تتضمّن الكاميرا الأساسية الخلفية دقة 12 ميغابكسل على الأقل مع إمكانية تسجيل الفيديو بدقة 4K بمعدل 30 لقطة في الثانية. الكاميرا الخلفية الأساسية هي الكاميرا الخلفية التي تحمل رقم تعريف الكاميرا الأقل.
- [7.5/H-1-2] يجب أن تتضمّن الكاميرا الأمامية الأساسية دقة rzęd 5 ميغابكسل على الأقل وأن تتيح تسجيل الفيديوهات بدقة 1080p بمعدّل 30 لقطة في الثانية. الكاميرا الأمامية primary هي الكاميرا الأمامية التي تحمل رقم تعريف الكاميرا الأقل.
- [7.5/H-1-3] يجب أن يكون الجهاز متوافقًا مع
android.info.supportedHardwareLevel
بدرجةFULL
أو أعلى للكاميرا الأساسية الخلفية وLIMITED
أو أعلى للكاميرا الأساسية الأمامية. - [7.5/H-1-4] يجب أن يكون الجهاز متوافقًا مع
CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME
لكل من الكاميرتين الأساسيتين. - [7.5/H-1-5] يجب أن يكون وقت استجابة التقاط ملف JPEG في الكاميرا2 أقل من 1000 ملي ثانية عند استخدام دقة 1080p، وذلك وفقًا لما يتم قياسه من خلال اختبار أداء الكاميرا في CTS في ظروف الإضاءة ITS (3000K) لكلتا الكاميرتين الأساسيتين.
- [7.5/H-1-6] يجب أن يكون وقت استجابة بدء تشغيل camera2 (فتح الكاميرا إلى أول ملف شخصي إطار) أقل من 600 ملي ثانية كما تم قياسه من خلال اختبار أداء كاميرا CTS في ظل ظروف الإضاءة ITS (3000K) لكلتا الكاميرتين الأساسيتين.
- [7.5/H-1-8] يجب أن تكون الكاميرا الخلفية الأساسية متوافقة مع
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW
وandroid.graphics.ImageFormat.RAW_SENSOR
.
2.2.7.3. الأجهزة
إذا كانت عمليات تنفيذ الأجهزة الجوّالة تعرض android.os.Build.VERSION_CODES.R
لـ android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS
، يعني ذلك أنّها:
- يجب استيفاء متطلبات الأجهزة الواردة في CDD لنظام التشغيل Android 11 القسم 2.2.7.3
إذا كانت عمليات تنفيذ الأجهزة الجوّالة تعرض android.os.Build.VERSION_CODES.S
لحالة
android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS
، يعني ذلك أنّها:
- [7.1.1.1/H-2-1] يجب أن تكون درجة دقة الشاشة 1080p على الأقل.
- [7.1.1.3/H-2-1] يجب أن تكون كثافة الشاشة 400 نقطة لكل بوصة على الأقل.
- [7.6.1/H-2-1] يجب أن يكون الجهاز مزوّدًا بذاكرة أساسية لا تقلّ عن 6 غيغابايت.
2.2.7.4. الأداء
إذا كانت عمليات تنفيذ الأجهزة الجوّالة تعرض android.os.Build.VERSION_CODES.R
لحالة
android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS
، يعني ذلك أنّها:
- يجب استيفاء متطلبات الأداء الواردة في CDD لنظام التشغيل Android 11 القسم 2.2.7.4
إذا كانت عمليات تنفيذ الأجهزة الجوّالة تعرض android.os.Build.VERSION_CODES.S
لحالة
android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS
، يعني ذلك أنّها:
- [8.2/H-2-1] يجب أن يضمن أداء الكتابة التسلسلي سرعة لا تقل عن 125 ميغابايت في الثانية.
- [8.2/H-2-2] يجب أن يضمن أداء الكتابة العشوائي سرعة لا تقل عن 10 ميغابايت في الثانية.
- [8.2/H-2-3] يجب أن يضمن أداء القراءة التسلسلي سرعة لا تقل عن 250 ميغابايت في الثانية.
- [8.2/H-2-4] يجب أن يضمن أداء القراءة العشوائية سرعة لا تقل عن 40 ميغابايت في الثانية.
2.3. متطلبات التلفزيون
يشير جهاز Android Television إلى استخدام جهاز Android كهيئات ترفيهية للاستفادة من الوسائط الرقمية والأفلام والألعاب والتطبيقات و/أو التلفزيون المباشر للمستخدمين الذين يجلسون على بُعد حوالي ثلاثة أمتار (واجهة مستخدِم "للاسترخاء" أو "للمشاهدة من مسافة ثلاثة أمتار").
يتم تصنيف عمليات تنفيذ أجهزة Android على أنّها أجهزة تلفزيون إذا كانت تستوفي كل المعايير التالية:
- أن تكون قد وفّرت آلية للتحكّم عن بُعد في واجهة المستخدم المعروضة على الشاشة التي قد تكون على بُعد ثلاثة أمتار من المستخدم
- أن تتضمّن شاشة مدمجة بطول قطري أكبر من 24 بوصة أو أن تتضمّن منفذ إخراج فيديو، مثل VGA أو HDMI أو DisplayPort أو منفذ لاسلكي لعرض المحتوى
إنّ المتطلبات الإضافية الواردة في بقية هذا القسم خاصة بعمليات تنفيذ التطبيقات على أجهزة Android Television.
2.3.1. الأجهزة
عمليات تنفيذ أجهزة التلفزيون:
- [7.2.2/T-0-1] يجب أن يكون الجهاز مزوّدًا بدواسة ألعاب.
- [7.2.3/T-0-1] يجب توفير وظيفتَي "الصفحة الرئيسية" و"الرجوع" .
- [7.2.3/T-0-2] يجب إرسال حدثي الضغط العادي والضغط مع الاستمرار
لدالّة الرجوع (
KEYCODE_BACK
) إلى التطبيق الذي يعمل في المقدّمة. - [7.2.6.1/T-0-1] يجب أن تتضمّن ميزة التحكّم في الألعاب ويجب الإفصاح عن علامة ميزة
android.hardware.gamepad
. - [7.2.7/T] يجب توفير جهاز تحكّم عن بُعد يمكن للمستخدمين من خلاله استخدام inputsللتنقّل بدون لمس الشاشة ومفاتيح التنقّل الأساسية.
إذا كانت عمليات تنفيذ أجهزة التلفزيون تتضمّن جيروسكوبًا ثلاثي المحاور، يجب استيفاء الشروط التالية:
- [7.3.4/T-1-1] يجب أن يكون الجهاز قادرًا على تسجيل الأحداث التي تصل إلى تردد 100 هرتز على الأقل.
- [7.3.4/T-1-2] يجب أن يكون الجهاز قادرًا على قياس تغييرات الاتجاه بسرعة تصل إلى 1000 درجة في الثانية.
عمليات تنفيذ أجهزة التلفزيون:
- [7.4.3/T-0-1] يجب أن يكون الجهاز متوافقًا مع البلوتوث وتكنولوجيا Bluetooth LE.
- [7.6.1/T-0-1] يجب أن يتوفّر لدى الجهاز مساحة تخزين غير متقلبة تبلغ 4 غيغابايت على الأقل لبيانات التطبيق الخاصة (المعروفة أيضًا باسم قسم "/data").
إذا كانت عمليات تنفيذ أجهزة التلفزيون تتضمّن منفذ USB متوافقًا مع وضع المضيف، يجب أن تستوفي الشروط التالية:
- [7.5.3/T-1-1] يجب أن يتضمّن الجهاز إمكانية استخدام كاميرا خارجية يتم توصيلها من خلال منفذ USB هذا ولكن ليس بالضرورة أن تكون متصلة دائمًا.
إذا كانت عمليات تنفيذ أجهزة التلفزيون تعمل بنظام 32 بت:
[7.6.1/T-1-1] يجب أن تكون الذاكرة المتاحة للنواة ومساحة المستخدم 896 ميغابايت على الأقل في حال استخدام أي من الكثافات التالية:
- 400 نقطة في البوصة أو أعلى على الشاشات الصغيرة/العادية
- xhdpi أو إصدار أحدث على الشاشات الكبيرة
- tvdpi أو أعلى على الشاشات الكبيرة جدًا
إذا كانت عمليات تنفيذ أجهزة التلفزيون تعمل بنظام 64 بت:
[7.6.1/T-2-1] يجب أن تكون الذاكرة المتاحة للنواة ومساحة المستخدم 1280 ميغابايت على الأقل في حال استخدام أي من الكثافات التالية:
- 400 نقطة في البوصة أو أعلى على الشاشات الصغيرة/العادية
- xhdpi أو إصدار أحدث على الشاشات الكبيرة
- tvdpi أو أعلى على الشاشات الكبيرة جدًا
يُرجى العِلم أنّ "الذاكرة المتاحة للنواة ومساحة المستخدم" أعلاه تشير إلى مساحة الذاكرة المقدَّمة بالإضافة إلى أي ذاكرة مخصّصة سابقًا لمكونات الأجهزة، مثل الراديو والفيديو وما إلى ذلك، والتي لا تخضع لسيطرة النواة على عمليات تنفيذ الأجهزة.
عمليات تنفيذ أجهزة التلفزيون:
- [7.8.1/T] يجب أن يتضمّن الجهاز ميكروفونًا.
- [7.8.2/T-0-1] يجب أن يتضمّن الجهاز مخرجًا للصوت وأن يتم الإفصاح عنه
android.hardware.audio.output
.
2.3.2. وسائط متعددة
يجب أن تكون عمليات تنفيذ أجهزة التلفزيون متوافقة مع تنسيقات ترميز وفك ترميز الصوت التالية وأن تتيح استخدامها للتطبيقات التابعة لجهات خارجية:
- [5.1/T-0-1] MPEG-4 AAC Profile (AAC LC)
- [5.1/T-0-2] MPEG-4 HE AAC Profile (AAC+)
- [5.1/T-0-3] AAC ELD (ترميز AAC المحسّن المنخفض التأخير)
يجب أن تتيح عمليات تنفيذ أجهزة التلفزيون تنسيقات ترميز الفيديوهات التالية وأن توفّرها للتطبيقات التابعة لجهات خارجية:
عمليات تنفيذ أجهزة التلفزيون:
- [5.2.2/T-SR-1] يُنصح بشدة بتوفير ميزة ترميز H.264 للفيديوهات بدقة 720p و1080p بمعدّل 30 لقطة في الثانية.
يجب أن تتيح عمليات تنفيذ أجهزة التلفزيون تنسيقات فك ترميز الفيديوهات التالية وأن توفّرها للتطبيقات التابعة لجهات خارجية:
- [5.3.3/T-0-1] MPEG-4 SP
- [5.3.4/T-0-2] H.264 AVC
- [5.3.5/T-0-3] H.265 HEVC
- [5.3.6/T-0-4] VP8
- [5.3.7/T-0-5] VP9
- [5.3.1/T-0-6] MPEG-2
يجب أن تتيح عمليات تنفيذ أجهزة التلفزيون فك ترميز MPEG-2، كما هو موضّح بالتفصيل في الفقرة 5.3.1، بمعدّلات لقطات عادية للفيديوهات ودرجات دقة تصل إلى بما في ذلك:
- [5.3.1/T-1-1] دقة عالية 1080p بمعدّل 29.97 لقطة في الثانية باستخدام المستوى العالي للملف الشخصي الرئيسي
- [5.3.1/T-1-2] دقة عالية 1080i بمعدل 59.94 لقطة في الثانية مع المستوى العالي للملف الشخصي الرئيسي ويجب أن تزيل هذه الأجهزة التداخل في فيديو MPEG-2 المُعدّ للعرض على شاشة عريضة وتوفّره للتطبيقات التابعة لجهات خارجية.
يجب أن تتيح عمليات تنفيذ أجهزة التلفزيون فك ترميز H.264، كما هو موضّح بالتفصيل في الفقرة 5.3.4، بمعدّلات لقطات الفيديو العادية ودرجات الدقة التي تصل إلى ما يلي:
- [5.3.4/T-1-1] دقة عالية 1080p بمعدل 60 لقطة في الثانية باستخدام ملف الوصف الأساسي
- [5.3.4/T-1-2] دقة عالية 1080p بمعدل 60 لقطة في الثانية مع الملف الشخصي الرئيسي
- [5.3.4/T-1-3] دقة عالية 1080p بمعدل 60 لقطة في الثانية باستخدام المستوى 4.2 من High Profile
يجب أن تتيح عمليات تنفيذ أجهزة التلفزيون المزوّدة ببرامج فك ترميز الأجهزة لتنسيق H.265 فسدت الترميز باستخدام تنسيق H.265، كما هو موضّح بالتفصيل في القسم 5.3.5، بمعدّلات عرض اللقطات العادية للفيديو ودرجات الدقة التي تصل إلى ما يلي:
- [5.3.5/T-1-1] دقة عالية 1080p بمعدل 60 لقطة في الثانية باستخدام المستوى 4.1 من الملف الشخصي الرئيسي
إذا كانت عمليات تنفيذ أجهزة التلفزيون التي تتضمّن برامج فك ترميز الأجهزة لتنسيق H.265 تتيح فك ترميز H.265 وملف فك ترميز المحتوى بدقة عالية جدًا، يجب أن تستوفي المتطلبات التالية:
- [5.3.5/T-2-1] يجب أن يكون متوافقًا مع ملف تعريف فك ترميز الفيديوهات بدقة فائقة بسرعة 60 لقطة في الثانية باستخدام ملف تعريف Main10 من المستوى 5 من الفئة الرئيسية
يجب أن تتيح عمليات تنفيذ أجهزة التلفزيون فك ترميز VP8، كما هو موضّح بالتفصيل في الفقرة 5.3.6، بمعدّلات لقطات الفيديو العادية ودرجات الدقة التي تصل إلى بما في ذلك:
- [5.3.6/T-1-1] ملف ترميز/فك ترميز محتوى بدقة عالية 1080p بمعدّل 60 لقطة في الثانية
يجب أن تتيح عمليات تنفيذ أجهزة التلفزيون المزوّدة بأجهزة فك ترميز VP9 ميزة فك ترميز VP9، كما هو موضّح بالتفصيل في القسم 5.3.7، بمعدّلات عرض اللقطات العادية للفيديوهات وبدرجة دقة تصل إلى ما يلي:
- [5.3.7/T-1-1] دقة عالية 1080p بمعدل 60 لقطة في الثانية باستخدام الملف الشخصي 0 (عمق ألوان 8 بت)
إذا كانت عمليات تنفيذ أجهزة التلفزيون التي تتضمّن برامج ترميز الأجهزة لفك ترميز VP9 تتيح فك ترميز VP9 وملف فك ترميز UHD، يجب أن تستوفي الشروط التالية:
- [5.3.7/T-2-1] يجب أن يكون الجهاز متوافقًا مع ملف تعريف فك ترميز الفيديو بدقة فائقة بمعدل 60 لقطة في الثانية باستخدام الملف الشخصي 0 (عمق الألوان 8 بت).
- [5.3.7/T-2-1] يُنصح بشدة بتوفير ملف الشخصي لترميز/فك ترميز المحتوى بدقة فائقة بمعدل 60 لقطة في الثانية باستخدام الملف الشخصي 2 (عمق الألوان 10 بت).
عمليات تنفيذ أجهزة التلفزيون:
- [5.5/T-0-1] يجب أن يتضمّن الجهاز ميزة التحكّم في مستوى هبوط كثافة الصوت في النظام ومستوى إخراج الصوت الرقمي على جميع مخارج الصوت المتوافقة، باستثناء مخرج الصوت المضغوط (حيث لا يتم فك ترميز الصوت على الجهاز).
إذا لم تتضمّن عمليات تنفيذ أجهزة التلفزيون شاشة مدمجة، ولكنها تتيح بدلاً من ذلك استخدام شاشة خارجية متصلة عبر HDMI، يجب استيفاء الشروط التالية:
- [5.8/T-0-1] يجب ضبط وضع إخراج HDMI على اختيار الحد الأقصى للدقة التي يمكن أن تكون متوافقة مع معدل إعادة التحديث إما 50 هرتز أو 60 هرتز.
- [5.8/T-SR-1] يُنصح بشدة بتوفير أداة اختيار معدل تحديث HDMI يمكن للمستخدم تعديلها.
- [5.8] يجب ضبط معدل تحديث وضع إخراج HDMI على 50 هرتز أو 60 هرتز، استنادًا إلى معدل تحديث الفيديو في المنطقة التي يتم بيع الجهاز فيها.
إذا لم تتضمّن عمليات تنفيذ أجهزة التلفزيون شاشة مدمجة، ولكنها تتيح بدلاً من ذلك استخدام شاشة خارجية متصلة عبر HDMI، يجب استيفاء الشروط التالية:
- [5.8/T-1-1] يجب أن يكون الجهاز متوافقًا مع معيار HDCP 2.2.
إذا كانت عمليات تنفيذ أجهزة التلفزيون لا تتيح فك ترميز محتوى UHD، ولكنها تتيح بدلاً من ذلك شاشة خارجية متصلة عبر HDMI، يجب أن تستوفي الشروط التالية:
- [5.8/T-2-1] يجب أن يكون متوافقًا مع معيار HDCP 1.4
2.3.3. البرامج
عمليات تنفيذ أجهزة التلفزيون:
- [3/T-0-1] يجب الإفصاح عن الميزتَين
android.software.leanback
وandroid.hardware.type.television
. - [3.2.3.1/T-0-1] يجب تحميل تطبيق واحد أو أكثر أو مكونات خدمة واحدة أو أكثر مسبقًا باستخدام معالِج طلبات بحث، وذلك لجميع أنماط فلاتر طلبات البحث العامة التي تحدّدها طلبات بحث التطبيقات التالية المُدرَجة هنا.
- [3.4.1/T-0-1] يجب توفير تنفيذ كامل
لواجهة برمجة تطبيقات
android.webkit.Webview
.
إذا كانت عمليات تنفيذ أجهزة Android Television تتيح شاشة القفل، يجب أن تستوفي الشروط التالية:
- [3.8.10/T-1-1] يجب عرض إشعارات شاشة القفل، بما في ذلك نموذج إشعار الوسائط.
عمليات تنفيذ أجهزة التلفزيون:
- [3.8.14/T-SR-1] يُنصح بشدة بإتاحة وضع "صورة في صورة" (PIP) في وضع النوافذ المتعدّدة.
- [3.10/T-0-1] يجب أن يتيح استخدام خدمات сторонних جهات لتحسين إمكانية الاستخدام.
- [3.10/T-SR-1] يُنصح بشدة بتحميل خدمات تسهيل الاستخدام مسبقًا على الجهاز بما يعادل أو يتجاوز وظائف خدمات تسهيل الاستخدام "الوصول عبر مفتاح التحويل" وTalkBack (للغات المتوافقة مع محرك تحويل النص إلى كلام المثبَّت مسبقًا) على النحو الوارد في مشروع TalkBack المفتوح المصدر.
إذا أبلغت عمليات تنفيذ أجهزة التلفزيون عن الميزة
android.hardware.audio.output
، يتم تنفيذ ما يلي:
- [3.11/T-SR-1] يُنصح بشدة بتضمين محرك تحويل النص إلى كلام يتيح اللغات المتاحة على الجهاز.
- [3.11/T-1-1] يجب أن تتيح إمكانية تثبيت محرّكات تحويل النص إلى كلام التابعة لجهات خارجية.
عمليات تنفيذ أجهزة التلفزيون:
- [3.12/T-0-1] يجب أن يكون متوافقًا مع إطار عمل إدخال التلفزيون.
2.3.4. الأداء والقوة
- [8.1/T-0-1] وقت استجابة ثابت للإطارات يجب ألا يحدث وقت استجابة غير متّسق للّقطات أو تأخّر في عرض اللقطات أكثر من 5 لقطات في الثانية، ويجب أن يكون أقل من لقطة واحدة في الثانية.
- [8.2/T-0-1] يجب أن يضمن الأداء التسلسلي للكتابة سرعة لا تقل عن 5 ميغابايت في الثانية.
- [8.2/T-0-2] يجب أن يضمن كتابة عشوائية بسرعة لا تقل عن 0.5 ميغابايت في الثانية.
- [8.2/T-0-3] يجب أن يضمن الأداء التسلسلي لقراءة ملف بمعدل لا يقل عن 15 ميغابايت في الثانية.
- [8.2/T-0-4] يجب أن يضمن سرعة قراءة ملف عشوائي تبلغ 3.5 ميغا بايت في الثانية على الأقل.
إذا كانت عمليات تنفيذ أجهزة التلفزيون تتضمّن ميزات لتحسين إدارة استهلاك الطاقة في الجهاز والتي تكون مضمّنة في AOSP أو توسيع نطاق الميزات المضمّنة في AOSP، يجب استيفاء الشروط التالية:
- [8.3/T-1-1] يجب أن توفّر واجهة المستخدم إمكانية تفعيل وإيقاف ميزة "توفير شحن البطارية".
إذا لم تكن عمليات تنفيذ أجهزة التلفزيون مزوّدة ببطارية، يجب أن تستوفي الشروط التالية:
- [8.3/T-1-2] يجب تسجيل الجهاز على أنّه جهاز بدون بطارية كما هو موضّح في إتاحة الأجهزة التي لا تعمل بالبطارية.
إذا كانت عمليات تنفيذ أجهزة التلفزيون تحتوي على بطارية، يجب استيفاء الشروط التالية:
- [8.3/T-1-3] يجب أن يقدّم التطبيق للمستخدم ميزة لعرض جميع التطبيقات المعفاة من وضعَي "الاستراحة" و"الاستراحة الذكية" لتوفير الطاقة.
عمليات تنفيذ أجهزة التلفزيون:
- [8.4/T-0-1] يجب تقديم ملف تعريف استهلاك الطاقة لكل مكوّن يحدّد قيمة الاستهلاك الحالي لكل مكوّن من مكوّنات الأجهزة ومعدل استنزاف البطارية التقريبي الذي يتسبب فيه المكوّنات بمرور الوقت كما هو موضّح في الموقع الإلكتروني لمشروع Android المفتوح المصدر.
- [8.4/T-0-2] يجب الإبلاغ عن جميع قيم استهلاك الطاقة بالمللي أمبير ساعة (mAh).
- [8.4/T-0-3] يجب الإبلاغ عن استهلاك طاقة وحدة المعالجة المركزية (CPU)
حسب المعرّف الفريد لكل عملية. يستوفي "مشروع مفتوح المصدر لنظام Android"
المتطلبات من خلال تنفيذ وحدة نواة
uid_cputime
. - [8.4/T] يجب أن يُنسَب إلى مكوّن الجهاز نفسه في حال تعذُّر تحديد تطبيق معيّن يستخدِم طاقة مكوّن الجهاز.
- [8.4/T-0-4] يجب أن يتيح مطوّر التطبيقات استخدام الطاقة
هذا من خلال الأمر
adb shell dumpsys batterystats
في واجهة سطر الأوامر.
2.3.5. نموذج الأمان
عمليات تنفيذ أجهزة التلفزيون:
- [9.11/T-0-1] يجب الاحتفاظ بنسخة احتياطية من عملية تنفيذ ملف تخزين المفاتيح باستخدام بيئة تنفيذ معزولة.
- [9.11/T-0-2] يجب أن تتضمّن عمليات تنفيذ خوارزميات التشفير RSA وAES وECDSA وHMAC ووظائف التجزئة من مجموعة MD5 وSHA1 وSHA-2 لدعم خوارزميات نظام "متجر مفاتيح Android" المتاحة بشكلٍ سليم في منطقة معزولة بشكلٍ آمن عن الرمز البرمجي الذي يعمل على النواة والإصدارات الأحدث. يجب أن تحظر ميزة "العزل الآمن" جميع الآليات المحتملة التي يمكن من خلالها لرمز kernel أو مساحة المستخدم الوصول إلى الحالة الداخلية للبيئة المعزولة، بما في ذلك DMA. يستوفي "المشروع المفتوح المصدر لنظام Android" (AOSP) هذا الشرط من خلال استخدام عملية تنفيذ Trusty، ولكن هناك خياران بديلة هما حلّ آخر يستند إلى ARM TrustZone أو عملية تنفيذ آمنة تمت مراجعتها من قِبل جهة خارجية لتوفير عزل مناسب يستند إلى أداة إدارة الأجهزة الافتراضية.
- [9.11/T-0-3] يجب تنفيذ مصادقة شاشة القفل في بيئة التنفيذ المعزولة، وعند نجاح المصادقة فقط، يجب السماح باستخدام المفاتيح المرتبطة بالمصادقة. يجب تخزين بيانات اعتماد شاشة القفل بطريقة لا تسمح إلا لبيئة التنفيذ المعزولة بإجراء مصادقة شاشة القفل. يقدّم مشروع Android Open Source Project الإصدارات السابقة من Gatekeeper Hardware Abstraction Layer (HAL) وTrusty، والتي يمكن استخدامها لاستيفاء هذا الشرط.
- [9.11/T-0-4] يجب أن يكون متوافقًا مع مصادقة المفتاح حيث يتم حماية مفتاح توقيع المصادقة باستخدام جهاز آمن ويتم تنفيذ التوقيع على جهاز آمن. يجب مشاركة مفاتيح توقيع الإثبات على عدد كبير بما يكفي من الأجهزة لمنع استخدام المفاتيح كمعرّفات للأجهزة. وإحدى الطرق لاستيفاء هذا الشرط هي مشاركة مفتاح الإثبات نفسه ما لم يتم تصنيع 100,000 وحدة على الأقل من رمز التخزين التعريفي معيّن. إذا تم إنتاج أكثر من 100,000 وحدة من رمز التخزين التعريفي، قد يتم استخدام مفتاح مختلف لكل 100,000 وحدة.
- [9/T-0-1] يجب الإفصاح عن ميزة "android.hardware.security.model.compatible" .
يُرجى العلم أنّه إذا سبق إطلاق عملية تنفيذ على جهاز باستخدام إصدار قديم من Android
، يتم إعفاء هذا الجهاز من شرط توفُّر متجر مفاتيح
مدعوم من بيئة تنفيذ معزولة ومتوافق مع شهادة إثبات ملكية المفتاح،
ما لم يعلن عن ميزة android.hardware.fingerprint
التي تتطلّب متجر مفاتيح
مدعومًا من بيئة تنفيذ معزولة.
إذا كانت عمليات تنفيذ أجهزة التلفزيون تتيح شاشة قفل آمنة، يجب أن تستوفي الشروط التالية:
- [9.11/T-1-1] يجب أن يسمح الجهاز للمستخدم باختيار مهلة وضع "الاستراحة" للانتقال من الحالة "غير مقفل" إلى الحالة "مقفَل"، مع تحديد الحد الأدنى للمهلة المسموح بها بما يصل إلى 15 ثانية أو أقل.
إذا كانت عمليات تنفيذ أجهزة التلفزيون تتضمّن مستخدمين متعدّدين ولم يتم تحديد علامة ميزة android.hardware.telephony
، يتم تنفيذ ما يلي:
- [9.5/T-2-1] يجب أن تتيح إمكانية استخدام الملفات الشخصية المحظورة، وهي ميزة تتيح لمالكي الأجهزة إدارة مستخدمين إضافيين وتحديد أذوناتهم على الجهاز. باستخدام الملفات الشخصية المحظورة، يمكن لمالكي الأجهزة إعداد بيئات منفصلة بسرعة ليستخدمها مستخدمون إضافيون، مع إمكانية إدارة قيود أكثر دقة في التطبيقات التي تتوفّر في تلك البيئات.
إذا كانت عمليات تنفيذ أجهزة التلفزيون تتضمّن مستخدمين متعدّدين ويُعلن عنها
باستخدام علامة ميزة android.hardware.telephony
، يتم تنفيذ ما يلي:
- [9.5/T-3-1] يجب ألّا يتيح الجهاز استخدام ملف شخصي محدود، بل يجب أن يكون متوافقًا مع طريقة AOSP في تنفيذ عناصر التحكّم للسماح للمستخدمين الآخرين بالوصول إلى المكالمات الصوتية والرسائل القصيرة أو حظر وصولهم إليها.
إذا كانت عمليات تنفيذ أجهزة التلفزيون تعرِض android.hardware.microphone
، يعني ذلك ما يلي:
- [9.8.2/T-4-1] يجب عرض مؤشر الميكروفون عندما يحصل تطبيق على بيانات صوتية من الميكروفون، ولكن ليس عندما يتم الوصول إلى الميكروفون من خلال HotwordDetectionService أو SOURCE_HOTWORD أو ContentCaptureService أو التطبيقات التي تمتلك الأدوار المذكورة في القسم 9.1 أذونات مع معرّف CDD C-3-X].
- [9.8.2/T-4-2] يجب عدم إخفاء مؤشر الميكروفون لتطبيقات النظام التي تتضمّن واجهات مستخدم مرئية أو تفاعلًا مباشرًا مع المستخدم.
إذا كانت عمليات تنفيذ أجهزة التلفزيون تعرِض android.hardware.camera.any
، يعني ذلك ما يلي:
- [9.8.2/T-5-1] يجب عرض مؤشر الكاميرا عندما يحصل أحد التطبيقات على بيانات الكاميرا المباشرة، ولكن ليس عندما يحصل على بيانات الكاميرا فقط تطبيقات تمتلك الأدوار الموضّحة في القسم 9.1. ينبغي أن يكون لدى التطبيقات التي تحصل على بيانات الكاميرا معرّف CDD [C-3-X].
- [9.8.2/T-5-2] يجب عدم إخفاء مؤشر الكاميرا ل تطبيقات النظام التي تتضمّن واجهات مستخدم مرئية أو تفاعلًا مباشرًا مع المستخدم.
2.3.6. توافق أدوات المطوّرين وخياراته
عمليات تنفيذ أجهزة التلفزيون:
- Perfetto
- [6.1/T-0-1] يجب عرض
/system/bin/perfetto
ملف ثنائي لمستخدم shell يكون cmdline متوافقًا مع مستندات perfetto. - [6.1/T-0-2] يجب أن يقبل ملف perfetto الثنائي كأحد المدخلات ملف إعدادات protobuf متوافقًا مع المخطّط المحدّد في مستندات perfetto.
- [6.1/T-0-3] يجب أن يكتب ملف perfetto الثنائي كملف أثر protobuf يتوافق مع المخطط المحدّد في مستندات perfetto.
- [6.1/T-0-4] يجب أن يوفّر الإصدار، من خلال ملف برمجي ثنائي لـ perfetto، على الأقل مصادر البيانات الموضّحة في مستندات perfetto.
- [6.1/T-0-1] يجب عرض
2.4. متطلبات المشاهدة
يشير جهاز Android Watch إلى عملية تنفيذ جهاز Android مخصّصة للارتداء على الجسم، ربما على المعصم.
يتم تصنيف عمليات تنفيذ أجهزة Android على أنّها ساعات إذا كانت تستوفي جميع المعايير التالية:
- أن تكون الشاشة ذات طول قطري يتراوح بين 1.1 و2.5 بوصة
- أن تتوفّر فيها آلية لارتدائها على الجسم
إنّ المتطلبات الإضافية الواردة في بقية هذا القسم خاصة بعمليات تنفيذ التطبيقات على أجهزة Android Watch.
2.4.1. الأجهزة
اطّلِع على عمليات تنفيذ الأجهزة:
[7.1.1.1/W-0-1] يجب أن يكون الجهاز مزوّدًا بشاشة قياسها قطريًا بين 1.1 و2.5 بوصة.
[7.2.3/W-0-1] يجب أن تتوفّر للمستخدم دالة Home والدالة Back باستثناء الحالات التي يكون فيها الجهاز في وضع
UI_MODE_TYPE_WATCH
.[7.2.4/W-0-1] يجب أن تتيح إمكانية إدخال البيانات من خلال شاشة اللمس.
[7.3.1/W-SR-1] يُنصح بشدة بتضمين accelerometer (مقياس تسارع) بثلاثة محاور.
إذا كانت عمليات تنفيذ أجهزة الساعة تتضمّن جهاز استقبال لنظام تحديد المواقع العالمي (GPS) أو نظام تحديد المواقع العالمي (GNSS) وتُبلغ عن
القدرة للتطبيقات من خلال علامة ميزة android.hardware.location.gps
، يجب استيفاء الشروط التالية:
- [7.3.3/W-1-1] يجب الإبلاغ عن قياسات GNSS فور العثور عليها، حتى إذا لم يتم الإبلاغ عن موقع جغرافي تم احتسابه من نظام تحديد المواقع العالمي (GPS) أو نظام تحديد المواقع العالمي (GNSS) بعد.
- [7.3.3/W-1-2] يجب الإبلاغ عن نطاقات GNSS الزائفة ومعدّلات النطاق الزائف، والتي تكون كافية لاحتساب الموقع الجغرافي ضمن 20 مترًا والسرعة ضمن 0.2 متر في الثانية، في 95% من الوقت على الأقل، وذلك في ظروف السماء المفتوحة بعد تحديد الموقع الجغرافي، سواء كان الجهاز مثبّتًا أو متحركًا بمعدّل تسارع أقل من 0.2 متر في الثانية المربعة.
إذا كانت عمليات تنفيذ أجهزة الساعة تتضمّن جيروسكوبًا ثلاثي المحاور، يجب استيفاء الشروط التالية:
- [7.3.4/W-2-1] يجب أن يكون الجهاز قادرًا على قياس تغييرات الاتجاه بسرعة تصل إلى 1000 درجة في الثانية.
اطّلِع على عمليات تنفيذ الأجهزة:
[7.4.3/W-0-1] يجب أن يكون الجهاز متوافقًا مع البلوتوث.
[7.6.1/W-0-1] يجب أن يتوفّر مساحة تخزين دائمة بسعة 1 غيغابايت على الأقل لبيانات التطبيق الخاصة (المعروفة أيضًا باسم قسم "/data").
[7.6.1/W-0-2] يجب أن تتوفّر ذاكرة بسعة 416 ميغابايت على الأقل للنواة ومساحة المستخدم.
[7.8.1/W-0-1] يجب أن يتضمّن الجهاز ميكروفونًا.
[7.8.2/W] قد يتضمّن مخرج صوت.
2.4.2. وسائط متعددة
ما مِن متطلبات إضافية.
2.4.3. البرامج
اطّلِع على عمليات تنفيذ الأجهزة:
- [3/W-0-1] يجب الإفصاح عن الميزة
android.hardware.type.watch
. - [3/W-0-2] يجب أن يكون متوافقًا مع uiMode = UI_MODE_TYPE_WATCH.
- [3.2.3.1/W-0-1] يجب تحميل تطبيقات أو مكونات خدمة واحدة أو أكثر مسبقًا باستخدام معالِج طلبات بحث، وذلك لتطبيق جميع أنماط فلاتر طلبات البحث المتاحة للجميع والمحدّدة من خلال طلبات البحث التالية للتطبيق والمدرَجة هنا.
اطّلِع على عمليات تنفيذ الأجهزة:
- [3.8.4/W-SR-1] يُنصح بشدة بتنفيذ مساعد على الجهاز لمعالجة الإجراء المساعد.
راقِب عمليات التنفيذ على الأجهزة التي تحدّد android.hardware.audio.output
علامة الفلاش المميّزة:
- [3.10/W-1-1] يجب أن تتيح التطبيقات خدمات تسهيل الاستخدام التابعة لجهات خارجية.
- [3.10/W-SR-1] يُنصح بشدة بتثبيت خدمات أدوات تسهيل الاستخدام على الجهاز مسبقًا، والتي توفّر وظائف مماثلة أو أفضل مما تقدّمه خدمات أدوات تسهيل الاستخدام Switch Access وTalkBack (للغات المتوافقة مع ميزة تحويل النص إلى كلام المثبَّتة مسبقًا)، وذلك على النحو الموضّح في المشروع المفتوح المصدر لتطبيق TalkBack.
إذا كانت عمليات تنفيذ أجهزة الساعة تُبلغ عن الميزة android.hardware.audio.output، يحدث ما يلي:
[3.11/W-SR-1] يُنصح بشدة بتضمين محرك تحويل النص إلى كلام يتيح اللغات المتاحة على الجهاز.
[3.11/W-0-1] يجب أن تتيح تثبيت محرّكات تحويل النص إلى كلام التابعة لجهات خارجية.
2.4.4. الأداء والقوة
إذا كانت عمليات تنفيذ أجهزة الساعة تتضمّن ميزات لتحسين إدارة استهلاك الطاقة في الجهاز والتي تكون مضمّنة في AOSP أو توسيع نطاق الميزات المضمّنة في AOSP، يجب استيفاء الشروط التالية:
- [8.3/W-SR-1] يُنصح بشدة بتوفير إمكانية للمستخدم لعرض جميع التطبيقات المعفاة من وضعَي "الاستراحة" و"الاستراحة الذكية" لتوفير الطاقة.
- [8.3/W-SR-2] يُنصح بشدة بتوفير إمكانية للمستخدم لتفعيل ميزة "توفير شحن البطارية" وإيقافها.
اطّلِع على عمليات تنفيذ الأجهزة:
- [8.4/W-0-1] يجب تقديم ملف تعريف استهلاك الطاقة لكل مكوّن يحدّد قيمة الاستهلاك الحالي لكل مكوّن من مكونات الجهاز ومعدل استنزاف البطارية التقريبي الذي يتسبب فيه المكوّنات بمرور الوقت كما هو موضّح في الموقع الإلكتروني لمشروع Android Open Source Project.
- [8.4/W-0-2] يجب الإبلاغ عن جميع قيم استهلاك الطاقة بالمللي أمبير ساعة (mAh).
- [8.4/W-0-3] يجب الإبلاغ عن استهلاك طاقة وحدة المعالجة المركزية (CPU)
حسب المعرّف الفريد لكل عملية. يستوفي "مشروع مفتوح المصدر لنظام Android"
المتطلبات من خلال تنفيذ وحدة نواة
uid_cputime
. - [8.4/W-0-4] يجب أن يتيح مطوّر التطبيق استخدام الطاقة
هذا من خلال الأمر
adb shell dumpsys batterystats
في واجهة سطر الأوامر. - [8.4/واط] يجب أن يُنسَب إلى مكوّن الجهاز نفسه في حال تعذُّر تحديد تطبيق معيّن يستخدِم طاقة مكوّن الجهاز.
2.4.5. نموذج الأمان
اطّلِع على عمليات تنفيذ الأجهزة:
- [9/W-0-1] يجب الإفصاح عن ميزة
android.hardware.security.model.compatible
.
إذا كانت عمليات تنفيذ تطبيقك على أجهزة الساعة تتضمّن مستخدمين متعدّدين ولم يتم تحديد علامة ميزة android.hardware.telephony
، سيتم تنفيذ ما يلي:
- [9.5/W-1-1] يجب أن تتيح إمكانية استخدام الملفات الشخصية المحظورة، وهي ميزة تتيح لمالكي الأجهزة إدارة مستخدمين إضافيين وتحديد أذوناتهم على الجهاز. باستخدام الملفات الشخصية المحظورة، يمكن لمالكي الأجهزة إعداد بيئات منفصلة بسرعة ليستخدمها مستخدمون إضافيون، مع إمكانية إدارة قيود أكثر دقة في التطبيقات التي تتوفّر في تلك البيئات.
إذا كانت عمليات تنفيذ تطبيقك على أجهزة الساعة تتضمّن مستخدمين متعدّدين ويُعلن التطبيق عن ميزة android.hardware.telephony
، يتم تنفيذ ما يلي:
- [9.5/W-2-1] يجب ألّا يتيح الجهاز استخدام ملف شخصي محدود، بل يجب أن يكون متوافقًا مع طريقة AOSP في استخدام عناصر التحكّم للسماح للمستخدمين الآخرين بالوصول إلى المكالمات الصوتية والرسائل القصيرة أو حظر وصولهم إليها.
2.5. متطلبات السيارات
يشير تنفيذ Android Automotive إلى وحدة الترفيه في السيارة التي تعمل بنظام التشغيل Android كنظام تشغيل لبعض وظائف النظام و/أو وظائف الترفيه والمعلومات أو كلّها.
يتم تصنيف عمليات تنفيذ أجهزة Android على أنّها Automotive إذا كانت تعلن عن
الميزة android.hardware.type.automotive
أو تستوفي كل المعايير التالية.
- تكون مضمّنة كجزء من مركبة أو قابلة للتوصيل بها
- استخدام شاشة في صف مقعد السائق كشاشة رئيسية
إنّ المتطلبات الإضافية الواردة في بقية هذا القسم خاصة بعمليات تنفيذ تطبيقات Android Automotive على الأجهزة المخصّصة للسيارات.
2.5.1. الأجهزة
عمليات تنفيذ الأجهزة في السيارات:
- [7.1.1.1/A-0-1] يجب أن يكون حجم الشاشة على الأقل 6 بوصة في شكلها العمودي.
[7.1.1.1/A-0-2] يجب أن يتضمّن تنسيق حجم الشاشة 750 dp x 480 dp على الأقل.
[7.2.3/A-0-1] يجب أن يوفّر زر الصفحة الرئيسية، ويمكن أن يوفّر زرَّي الرجوع والتطبيقات الحديثة.
[7.2.3/A-0-2] يجب إرسال حدثي الضغط العادي والضغط مع الاستمرار لدالّة الرجوع (
KEYCODE_BACK
) إلى التطبيق الذي يعمل في المقدّمة.[7.3/A-0-1] يجب تنفيذ
GEAR_SELECTION
وNIGHT_MODE
وPERF_VEHICLE_SPEED
وPARKING_BRAKE_ON
والإبلاغ عنها.[7.3/A-0-2] يجب أن تكون قيمة العلامة
NIGHT_MODE
متسقة مع وضع لوحة البيانات النهاري/الليلي، ويجب أن تستند إلى مدخلات أداة استشعار الإضاءة المحيطة. قد تكون أداة استشعار الإضاءة المحيطة الأساسية مماثلة لـ مقياس الإضاءة.[7.3/A-0-3] يجب تقديم حقل معلومات إضافية عن جهاز الاستشعار
TYPE_SENSOR_PLACEMENT
كجزء من SensorAdditionalInfo لكل جهاز استشعار مقدَّم.[7.3/أ-0-1] يجوز استخدام طريقة التقدير التقريبي للموقع الجغرافي من خلال دمج نظام تحديد المواقع العالمي (GPS)/نظام تحديد المواقع العالمي عبر الأقمار الصناعية (GNSS) مع أجهزة استشعار إضافية. إذا تم احتساب الموقع الجغرافي باستخدام طريقة التقدير التقريبي، ننصحك بشدة بتنفيذ وتسجيل أنواع الاستشعار المقابلة و/أو أرقام تعريف خصائص المركبات المستخدَمة.
[7.3/A-0-2] الموقع الجغرافي الذي تم طلبه من خلال LocationManager#requestLocationUpdates() يجب ألّا يكون مطابقًا للخريطة.
إذا كانت عمليات تنفيذ الأجهزة في السيارات متوافقة مع OpenGL ES 3.1، يجب استيفاء الشروط التالية:
- [7.1.4.1/A-0-1] يجب الإفصاح عن استخدام OpenGL ES 3.1 أو إصدار أحدث.
- [7.1.4.1/A-0-2] يجب أن يكون متوافقًا مع Vulkan 1.1.
- [7.1.4.1/A-0-3] يجب أن يتضمّن أداة تحميل Vulkan وتصدير جميع الرموز.
إذا كانت عمليات تنفيذ الأجهزة في السيارات تتضمّن مقياس تسارع ثلاثي المحاور، يجب استيفاء الشروط التالية:
- [7.3.1/A-1-1] يجب أن يكون الجهاز قادرًا على تسجيل الأحداث التي تصل إلى تردد 100 هرتز على الأقل.
- [7.3.1/A-1-2] يجب أن يكون متوافقًا مع نظام إحداثيات أدوات استشعار السيارات في Android.
إذا كانت عمليات تنفيذ الأجهزة في السيارات تتضمّن جيروسكوبًا ثلاثي المحاور، يجب استيفاء الشروط التالية:
- [7.3.4/A-2-1] يجب أن يكون الجهاز قادرًا على تسجيل الأحداث التي تصل ترددها إلى 100 هرتز على الأقل.
- [7.3.4/أ-2-3] يجب أن يكون الجهاز قادرًا على قياس تغييرات الاتجاه بسرعة تصل إلى 250 درجة في الثانية.
- [7.3.4/A-SR-1] يُنصح بشدة بضبط نطاق قياس الجيروسكوب على 250dps +/- من أجل زيادة الحد الأقصى لدقة المقدور
إذا كانت عمليات تنفيذ الأجهزة المخصّصة للسيارات تتضمّن جهاز استقبال لنظام تحديد المواقع العالمي (GPS) أو نظام تحديد المواقع العالمي (GNSS)، ولكن لا تشمل إمكانية الاتصال بالبيانات المستندة إلى الشبكة الخلوية، يجب استيفاء الشروط التالية:
- [7.3.3/أ-3-1] يجب تحديد الموقع الجغرافي في المرة الأولى التي يتم فيها تشغيل جهاز استقبال نظام تحديد المواقع العالمي (GPS) أو بعد 4 أيام أو أكثر خلال 60 ثانية.
- [7.3.3/أ-3-2] يجب استيفاء معايير وقت الإصلاح الأول كما هو описан في 7.3.3/ج-1-2 و7.3.3/ج-1-6 لجميع طلبات تحديد الموقع الجغرافي الأخرى (أي الطلبات التي ليست المرة الأولى على الإطلاق أو بعد 4 أيام أو أكثر). يتم عادةً استيفاء المتطلب 7.3.3/C-1-2 في المركبات التي لا تتيح إمكانية الاتصال بالبيانات المستندة إلى شبكة الجوّال، وذلك باستخدام توقّعات مدارات نظام تحديد المواقع العالمي (GNSS) المحسوبة على جهاز الاستقبال، أو باستخدام آخر موقع جغرافي معروف للمركبة بالإضافة إلى إمكانية استخدام طريقة التقدير التقريبي لمدة 60 ثانية على الأقل بدقة موقع جغرافي تستوفي 7.3.3/C-1-3، أو باستخدام كليهما.
عمليات تنفيذ الأجهزة في السيارات:
- [7.4.3/A-0-1] يجب أن يكون الجهاز متوافقًا مع البلوتوث ويجب أن يكون متوافقًا مع البلوتوث منخفض الطاقة.
- [7.4.3/A-0-2] يجب أن تتوافق عمليات تنفيذ Android Automotive
مع ملفات تعريف البلوتوث التالية:
- إجراء مكالمات هاتفية عبر ملف الإعدادات بدون لمس الجهاز (HFP)
- تشغيل الوسائط عبر ملف تعريف توزيع الصوت (A2DP)
- التحكّم في تشغيل الوسائط من خلال ملف التحكم عن بُعد (AVRCP)
- مشاركة جهات الاتصال باستخدام ملف الوصول إلى دفتر العناوين (PBAP)
[7.4.3/A-SR-1] يُنصح بشدة بتوفير ملف تعريف الوصول إلى الرسائل (MAP).
[7.4.5/أ] يجب أن يتضمّن الجهاز إمكانية الربط بشبكة بيانات جوّال.
[7.4.5/أ] يجوز استخدام ثابت System API
NetworkCapabilities#NET_CAPABILITY_OEM_PAID
للشبكة التي يجب أن تكون متاحة لتطبيقات النظام.
كاميرا الرؤية الخارجية هي كاميرا تلتقط صورًا للمشاهد خارج نطاق الجهاز التنفيذ، مثل كاميرا داش.
عمليات تنفيذ الأجهزة في السيارات:
- يجب أن تتضمّن كاميرا واحدة أو أكثر للعرض الخارجي.
إذا كانت عمليات تنفيذ الأجهزة في السيارات تتضمّن كاميرا للرؤية الخارجية، يجب أن تستوفي هذه الكاميرات الشروط التالية:
- [7.5/A-1-1] يجب ألّا تتيح كاميرات الرؤية الخارجية الوصول إليها من خلال واجهات برمجة تطبيقات كاميرا Android، ما لم تكن متوافقة مع المتطلبات الأساسية للكاميرا.
- [7.5/A-SR-1] يُنصح بشدة بعدم تدوير معاينة الكاميرا أو عكسها أفقيًا.
- [7.5.5/A-SR-1] يُنصح بشدة بتوجيه الكاميرا بحيث تتماشى الجانب الطويل من الكاميرا مع الأفق.
- [7.5/A-SR-2] يُنصح بشدة بأن تكون درجة دقة الصور 1.3 ميغابكسل على الأقل.
- يجب أن يكون مزوّدًا بأجهزة ذات تركيز ثابت أو بميزة "عمق مجال الصورة الموسّع".
- يجب أن يكون متوافقًا مع إطار عمل مزامنة Android.
- قد تتضمّن ميزة التركيز التلقائي للأجهزة أو التركيز التلقائي للبرامج في برنامج تشغيل الكاميرا.
عمليات تنفيذ الأجهزة في السيارات:
[7.6.1/A-0-1] يجب أن يتوفّر مساحة تخزين غير متقلبة بسعة 4 غيغابايت على الأقل لبيانات التطبيق الخاصة (المعروفة أيضًا باسم قسم "/data").
[7.6.1/أ] يجب تنسيق قسم البيانات لتوفير أداء أفضل وعمر تخزين أطول في ذاكرة الفلاش، على سبيل المثال، باستخدام نظام الملفات
f2fs
.
إذا كانت عمليات تنفيذ الأجهزة المخصّصة للسيارات توفّر مساحة تخزين خارجية مشترَكة من خلال جزء من مساحة التخزين الداخلية غير القابلة للإزالة، يجب أن تستوفي المتطلبات التالية:
- [7.6.1/A-SR-1] يُنصح بشدة بتخفيض
الوقت المستغرَق لنقل البيانات في العمليات التي يتم إجراؤها على مساحة التخزين الخارجية، على سبيل المثال باستخدام
SDCardFS
.
إذا كانت عمليات تنفيذ الأجهزة في السيارات تستخدم الإصدار 32 بت:
[7.6.1/A-1-1] يجب أن تكون الذاكرة المتاحة للنواة ومساحة المستخدم 512 ميغابايت على الأقل في حال استخدام أي من الكثافات التالية:
- 280 نقطة في البوصة أو أقل على الشاشات الصغيرة/العادية
- ldpi أو أقل على الشاشات الكبيرة جدًا
- mdpi أو أقل على الشاشات الكبيرة
[7.6.1/A-1-2] يجب أن تكون الذاكرة المتاحة للنواة ومساحة المستخدم 608 ميغابايت على الأقل في حال استخدام أي من الكثافات التالية:
- xhdpi أو أعلى على الشاشات الصغيرة/العادية
- دقة عالية جدًا أو أعلى على الشاشات الكبيرة
- mdpi أو أعلى على الشاشات الكبيرة جدًا
[7.6.1/A-1-3] يجب أن تكون الذاكرة المتاحة للنواة ومساحة المستخدم 896 ميغابايت على الأقل في حال استخدام أي من الكثافات التالية:
- 400 نقطة في البوصة أو أعلى على الشاشات الصغيرة/العادية
- xhdpi أو إصدار أحدث على الشاشات الكبيرة
- tvdpi أو أعلى على الشاشات الكبيرة جدًا
[7.6.1/A-1-4] يجب أن تكون الذاكرة المتاحة للنواة ومساحة المستخدم 1344 ميغابايت على الأقل في حال استخدام أي من الكثافات التالية:
- 560 نقطة في البوصة أو أعلى على الشاشات الصغيرة/العادية
- 400 نقطة في البوصة أو أعلى على الشاشات الكبيرة
- xhdpi أو أعلى على الشاشات الكبيرة جدًا
إذا كانت عمليات تنفيذ الأجهزة في السيارات تعمل بنظام 64 بت:
[7.6.1/A-2-1] يجب أن تكون الذاكرة المتاحة للنواة ومساحة المستخدم 816 ميغابايت على الأقل في حال استخدام أي من الكثافات التالية:
- 280 نقطة في البوصة أو أقل على الشاشات الصغيرة/العادية
- ldpi أو أقل على الشاشات الكبيرة جدًا
- mdpi أو أقل على الشاشات الكبيرة
[7.6.1/A-2-2] يجب أن تكون الذاكرة المتاحة للنواة ومساحة المستخدم 944 ميغابايت على الأقل في حال استخدام أي من الكثافات التالية:
- xhdpi أو أعلى على الشاشات الصغيرة/العادية
- دقة عالية جدًا أو أعلى على الشاشات الكبيرة
- mdpi أو أعلى على الشاشات الكبيرة جدًا
[7.6.1/A-2-3] يجب أن تكون الذاكرة المتاحة للنواة ومساحة المستخدم 1280 ميغابايت على الأقل في حال استخدام أي من الكثافات التالية:
- 400 نقطة في البوصة أو أعلى على الشاشات الصغيرة/العادية
- xhdpi أو إصدار أحدث على الشاشات الكبيرة
- tvdpi أو أعلى على الشاشات الكبيرة جدًا
[7.6.1/A-2-4] يجب أن تكون الذاكرة المتاحة للنواة ومساحة المستخدم 1824 ميغابايت على الأقل في حال استخدام أي من الكثافات التالية:
- 560 نقطة في البوصة أو أعلى على الشاشات الصغيرة/العادية
- 400 نقطة في البوصة أو أعلى على الشاشات الكبيرة
- xhdpi أو أعلى على الشاشات الكبيرة جدًا
يُرجى العِلم أنّ "الذاكرة المتاحة للنواة ومساحة المستخدم" أعلاه تشير إلى مساحة الذاكرة المقدَّمة بالإضافة إلى أي ذاكرة مخصّصة مسبقًا لمكونات الأجهزة، مثل الراديو والفيديو وما إلى ذلك، والتي لا تخضع لرقابة النواة في عمليات تنفيذ الأجهزة.
عمليات تنفيذ الأجهزة في السيارات:
- [7.7.1/أ] يجب أن يتضمّن منفذ USB يتوافق مع وضع الأجهزة الملحقة.
عمليات تنفيذ الأجهزة في السيارات:
- [7.8.1/A-0-1] يجب أن يتضمّن الجهاز ميكروفونًا.
عمليات تنفيذ الأجهزة في السيارات:
- [7.8.2/A-0-1] يجب أن يتضمّن الجهاز مخرجًا للصوت وأن يتم الإفصاح عنه
android.hardware.audio.output
.
2.5.2. وسائط متعددة
يجب أن تتيح عمليات تنفيذ الأجهزة في السيارات تنسيقات ترميز وفك ترميز الصوت التالية وأن تجعلها متاحة للتطبيقات التابعة لجهات خارجية:
- [5.1/A-0-1] MPEG-4 AAC Profile (AAC LC)
- [5.1/A-0-2] MPEG-4 HE AAC Profile (AAC+)
- [5.1/A-0-3] AAC ELD (ترميز AAC المتقدّم المنخفض التأخير)
يجب أن تتيح عمليات تنفيذ الأجهزة في السيارات تنسيقات ترميز الفيديوهات التالية وأن توفّرها للتطبيقات التابعة لجهات خارجية:
يجب أن تتيح عمليات تنفيذ الأجهزة في المركبات تنسيقات فك ترميز الفيديوهات التالية وأن توفّرها للتطبيقات التابعة لجهات خارجية:
ننصح بشدة بتوفير ميزة فك ترميز الفيديو التالية في عمليات تنفيذ الأجهزة في المركبات:
- [5.3/A-SR-1] H.265 HEVC
2.5.3. البرامج
عمليات تنفيذ الأجهزة في السيارات:
[3/A-0-1] يجب الإفصاح عن الميزة
android.hardware.type.automotive
.[3/A-0-2] يجب أن يكون متوافقًا مع uiMode =
UI_MODE_TYPE_CAR
.[3/A-0-3] يجب أن تتوافق مع جميع واجهات برمجة التطبيقات المتاحة للجميع في مساحة имен
android.car.*
.
إذا كانت عمليات تنفيذ الأجهزة في السيارات توفّر واجهة برمجة تطبيقات خاصة باستخدام
android.car.CarPropertyManager
مع
android.car.VehiclePropertyIds
،
يجب استيفاء الشروط التالية:
- [3/أ-1-1] يجب عدم ربط امتيازات خاصة باستخدام تطبيق النظام لهذه السمات، أو منع التطبيقات التابعة لجهات خارجية من استخدام هذه السمات.
- [3/أ-1-2] يجب عدم تكرار سمة مركبة متوفرة في حزمة SDK.
عمليات تنفيذ الأجهزة في السيارات:
[3.2.1/A-0-1] يجب أن يتيح التطبيق استخدام كل CONSTANT للأذونات ويفرض استخدامها كما هو موضّح في صفحة مرجع أذونات السيارات.
[3.2.3.1/A-0-1] يجب تحميل تطبيق واحد أو أكثر أو مكونات خدمة واحدة أو أكثر مسبقًا باستخدام معالِج طلبات بحث، وذلك لجميع أنماط فلاتر طلبات البحث العامة التي تحدّدها طلبات بحث التطبيقات التالية المُدرَجة هنا.
[3.4.1/A-0-1] يجب أن يوفّر التطبيق تنفيذًا كاملاً لواجهة برمجة التطبيقات
android.webkit.Webview
.[3.8.3/A-0-1] يجب عرض إعلامات تستخدم واجهة برمجة التطبيقات
Notification.CarExtender
عند طلبها من تطبيقات تابعة لجهات خارجية.[3.8.4/A-SR-1] يُنصح بشدة بتنفيذ مساعد على الجهاز لمعالجة الإجراء المساعد.
إذا كانت عمليات تنفيذ الأجهزة المخصّصة للسيارات تتضمّن زرًا للضغط والتحدث، يجب استيفاء الشروط التالية:
- [3.8.4/أ-1-1] يجب استخدام ضغطة قصيرة على
زر الضغط للتحدث كتفاعل محدّد لتشغيل
تطبيق المساعدة الذي يختاره المستخدم، أي التطبيق الذي ينفّذ
VoiceInteractionService
.
عمليات تنفيذ الأجهزة في السيارات:
- [3.8.3.1/A-0-1] يجب أن يتم عرض الموارد بشكلٍ سليم كما هو موضّح في مستندات حزمة
Notifications on Automotive OS
SDK. - [3.8.3.1/A-0-2] يجب عرض رمزَي التشغيل وكتم الصوت لإجراءات الإشعارات بدلاً من الرموز المقدَّمة من خلال
Notification.Builder.addAction()
. - [3.8.3.1/أ] يجب أن تحد من استخدام مهام الإدارة المفصّلة، مثل عناصر التحكّم في كل قناة إشعار. يجوز استخدام واجهة مستخدم لكل تطبيق لتقليل عناصر التحكّم.
إذا كانت عمليات تنفيذ الأجهزة في السيارات متوافقة مع سمات HAL للمستخدم، يجب أن تستوفي الشروط التالية:
- [3.9.3/A-1-1] يجب تنفيذ كلّ
خصائص رحلة المستخدِم
INITIAL_USER_INFO
،SWITCH_USER
،CREATE_USER
،REMOVE_USER
.
عمليات تنفيذ الأجهزة في السيارات:
- [3.14/أ-0-1] يجب أن يتضمّن إطار عمل واجهة المستخدم إتاحة استخدام التطبيقات التابعة لجهات خارجية التي تستخدم واجهات برمجة تطبيقات الوسائط كما هو موضّح في القسم 3.14.
- [3.14/A-0-2] يجب أن يسمح الجهاز للمستخدم بالتفاعل بأمان مع تطبيقات الوسائط أثناء القيادة.
- [3.14/A-0-3] يجب أن تتيح الإضافة تنفيذ الإجراء "القصد الضمني"
CAR_INTENT_ACTION_MEDIA_TEMPLATE
باستخدام العنصرCAR_EXTRA_MEDIA_PACKAGE
الإضافي. - [3.14/A-0-4] يجب توفير عنصر تحكم للانتقال إلى نشاط الإعدادات المفضّلة في تطبيق الوسائط، ولكن يجب عدم تفعيله إلا عندما لا تكون قيود تجربة المستخدم في السيارة سارية.
- [3.14/A-0-5] يجب أن يعرض التطبيق
رسائل الخطأ
التي تحدّدها تطبيقات الوسائط، ويجب أن يكون متوافقًا مع الإضافات الاختيارية
ERROR_RESOLUTION_ACTION_LABEL
وERROR_RESOLUTION_ACTION_INTENT
. - [3.14/A-0-6] يجب أن يتيح التطبيق ميزة البحث داخل التطبيق للتطبيقات التي تتيح البحث.
- [3.14/A-0-7] يجب الالتزام بتعريفات
CONTENT_STYLE_BROWSABLE_HINT
وCONTENT_STYLE_PLAYABLE_HINT
عند عرض التسلسل الهرمي MediaBrowser.
إذا كانت عمليات تنفيذ الأجهزة المخصّصة للسيارات تتضمّن تطبيق مشغّل تلقائيًا، يجب استيفاء الشروط التالية:
- [3.14/A-1-1] يجب أن تتضمّن خدمات الوسائط وفتحها
باستخدام
CAR_INTENT_ACTION_MEDIA_TEMPLATE
intent.
عمليات تنفيذ الأجهزة في السيارات:
- [3.8/أ] يجوز للتطبيق منع requests للدخول إلى وضع ملء الشاشة كما هو موضّح في
immersive documentation
. - [3.8/أ] يجوز إبقاء شريط الحالة وشريط التنقّل مرئيَين في جميع الأوقات.
- [3.8/أ] يجوز للتطبيق تقييد requests لتغيير الألوان التي تظهر خلف عناصر واجهة مستخدم النظام، لضمان ظهور تلك العناصر بوضوح في جميع الأوقات.
2.5.4. الأداء والقوة
عمليات تنفيذ الأجهزة في السيارات:
- [8.2/A-0-1] يجب الإبلاغ عن عدد
البايت التي تم قراءتها وكتابتها في مساحة التخزين غير القابلة للفقد لكل معرّف مستخدم فريد لكل عملية حتى تكون
الإحصاءات متاحة للمطوّرين من خلال System API
android.car.storagemonitoring.CarStorageMonitoringManager
. يستوفي "مشروع مفتوح المصدر لنظام Android" المتطلّبات من خلال وحدة نواةuid_sys_stats
. - [8.3/أ-1-3] يجب أن يكون الجهاز متوافقًا مع وضع المرآب.
- [8.3/أ] يجب أن يكون الجهاز في وضع "المرآب" لمدة
15 دقيقة على الأقل بعد كل رحلة ما لم يكن:
- تم تفريغ شحن البطارية.
- لا يتم جدولة أي مهام غير نشطة.
- يخرج السائق من "وضع المرآب".
- [8.4/A-0-1] يجب تقديم ملف تعريف استهلاك الطاقة لكل مكوّن يحدّد قيمة الاستهلاك الحالي لكل مكوّن من مكوّنات الأجهزة ومعدل استنزاف البطارية التقريبي الذي يسببه المكوّنات بمرور الوقت كما هو موضّح في الموقع الإلكتروني لمشروع Android Open Source Project.
- [8.4/A-0-2] يجب الإبلاغ عن جميع قيم استهلاك الطاقة بالمللي أمبير ساعة (mAh).
- [8.4/A-0-3] يجب الإبلاغ عن استهلاك طاقة وحدة المعالجة المركزية (CPU)
حسب المعرّف الفريد لكل عملية. يستوفي "مشروع مفتوح المصدر لنظام Android"
المتطلبات من خلال تنفيذ وحدة نواة
uid_cputime
. - [8.4/أ] يجب أن يُنسَب إلى مكوّن الجهاز نفسه في حال تعذُّر تحديد تطبيق معيّن لاستخدام طاقة مكوّن الجهاز.
- [8.4/A-0-4] يجب أن يتيح مطوّر التطبيق استخدام الطاقة
هذا من خلال الأمر
adb shell dumpsys batterystats
في واجهة سطر الأوامر.
2.5.5. نموذج الأمان
إذا كانت عمليات تنفيذ الأجهزة في السيارات تتيح استخدام حسابات متعددة، يجب أن:
- [9.5/A-1-1] يجب عدم السماح للمستخدمين بالتفاعل مع مستخدم النظام غير المرئي أو التبديل إليه، إلا في ما يتعلق بإعداد الجهاز.
- [9.5/أ-1-2] يجب التبديل إلى مستخدم ثانوي
قبل
BOOT_COMPLETED
. - [9.5/أ-1-3] يجب أن يتيح التطبيق إمكانية إنشاء حساب مستخدم ضيف حتى عند بلوغ الحد الأقصى لعدد المستخدمين على الجهاز.
عمليات تنفيذ الأجهزة في السيارات:
- [9.11/A-0-1] يجب الاحتفاظ بنسخة احتياطية من تنفيذ ملف تخزين المفاتيح باستخدام بيئة تنفيذ معزولة.
- [9.11/A-0-2] يجب أن تتضمّن عمليات تنفيذ خوارزميات التشفير RSA وAES وECDSA وHMAC ووظائف التجزئة من مجموعة MD5 وSHA1 وSHA-2 لتتوافق بشكلٍ سليم مع خوارزميات نظام "متجر مفاتيح Android" المتوافقة في منطقة معزولة بشكلٍ آمن عن الرمز البرمجي الذي يعمل على النواة والإصدارات الأحدث. يجب أن تحظر ميزة "العزل الآمن" جميع الآليات المحتملة التي يمكن من خلالها لرمز kernel أو مساحة المستخدم الوصول إلى الحالة الداخلية للبيئة المعزولة، بما في ذلك DMA. يستوفي "المشروع المفتوح المصدر لنظام Android" (AOSP) هذا الشرط من خلال استخدام عملية تنفيذ Trusty، ولكن هناك خياران بديلة هما حلّ آخر يستند إلى ARM TrustZone أو عملية تنفيذ آمنة تمت مراجعتها من قِبل جهة خارجية لتوفير عزل مناسب يستند إلى أداة إدارة الأجهزة الافتراضية.
- [9.11/A-0-3] يجب تنفيذ مصادقة شاشة القفل في بيئة التنفيذ المعزولة، وعند نجاح عملية المصادقة فقط، يجب السماح باستخدام المفاتيح المرتبطة بالمصادقة. يجب تخزين بيانات اعتماد شاشة القفل بطريقة لا تسمح إلا لبيئة التنفيذ المعزولة بإجراء مصادقة شاشة القفل. يقدّم مشروع Android Open Source Project الإصدارات السابقة من Gatekeeper Hardware Abstraction Layer (HAL) وTrusty، والتي يمكن استخدامها لاستيفاء هذا الشرط.
- [9.11/A-0-4] يجب أن يكون متوافقًا مع مصادقة المفتاح حيث يتم حماية مفتاح توقيع المصادقة باستخدام جهاز آمن ويتم تنفيذ التوقيع على جهاز آمن. يجب مشاركة مفاتيح توقيع الإثبات على عدد كبير بما يكفي من الأجهزة لمنع استخدام المفاتيح كمعرّفات للأجهزة. وإحدى الطرق لاستيفاء هذا الشرط هي مشاركة مفتاح الإثبات نفسه ما لم يتم تصنيع 100,000 وحدة على الأقل من رمز التخزين التعريفي معيّن. إذا تم إنتاج أكثر من 100,000 وحدة من رمز التخزين التعريفي، قد يتم استخدام مفتاح مختلف لكل 100,000 وحدة.
- [9/A-0-1] يجب الإفصاح عن ميزة "android.hardware.security.model.compatible" .
يُرجى العلم أنّه إذا سبق إطلاق عملية تنفيذ على جهاز باستخدام إصدار قديم من Android
، يتم إعفاء هذا الجهاز من شرط توفُّر متجر مفاتيح
مدعوم من بيئة تنفيذ معزولة ومتوافق مع شهادة إثبات ملكية المفتاح،
ما لم يعلن عن ميزة android.hardware.fingerprint
التي تتطلّب متجر مفاتيح
مدعومًا من بيئة تنفيذ معزولة.
عمليات تنفيذ الأجهزة في السيارات:
- [9.14/A-0-1] يجب أن تتحكّم في الرسائل المرسَلة من الأنظمة الفرعية للمركبات في إطار عمل Android، مثلاً، من خلال السماح بأنواع الرسائل المسموح بها ومصادر الرسائل.
- [9.14/A-0-2] يجب أن يتم تطبيق مراقب النظام ضد هجمات الحرمان من الخدمة من إطار عمل Android أو التطبيقات التابعة لجهات خارجية. يحمي ذلك من البرامج الضارة التي تغمر شبكة المركبة بحركة مرور، ما قد يؤدي إلى تعطُّل الأنظمة الفرعية للمركبة.
2.5.6. توافق أدوات المطوّرين وخياراته
عمليات تنفيذ الأجهزة في السيارات:
- Perfetto
- [6.1/A-0-1] يجب عرض
/system/bin/perfetto
ملف ثنائي لمستخدم shell يكون cmdline متوافقًا مع مستندات perfetto. - [6.1/A-0-2] يجب أن يقبل ملف perfetto الثنائي كأحد مدخلات ملف إعدادات protobuf متوافق مع المخطّط المحدّد في مستندات perfetto.
- [6.1/A-0-3] يجب أن يكتب ملف perfetto الثنائي أثر protobuf كأحد المخرجات، على أن يكون متوافقًا مع المخطط المحدّد في مستندات perfetto.
- [6.1/A-0-4] يجب أن يوفّر الإصدار، من خلال ملف برمجي ثنائي لـ perfetto ، على الأقل مصادر البيانات الموضّحة في مستندات perfetto.
- [6.1/A-0-1] يجب عرض
2.6. متطلبات الجهاز اللوحي
يشير جهاز Android اللوحي إلى عملية تنفيذ جهاز Android التي عادةً ما تستوفي جميع المعايير التالية:
- يتم استخدامه من خلال الإمساك به بكلتا اليدين.
- لا يتضمّن الجهاز تصميمًا قابلاً للطي أو قابلاً للتحويل.
- يتم توصيل تطبيقات لوحة المفاتيح الخارجية المستخدمة مع الجهاز باستخدام اتصال عادي (مثل USB أو بلوتوث).
- أن يكون مزوّدًا بمصدر طاقة يوفر إمكانية التنقل، مثل بطارية
- أن يكون حجم شاشة العرض أكبر من 7 بوصات وأقل من 18 بوصة، ويتم قياسه باتجاه قطري
تتطلب عمليات تنفيذ التطبيقات على الأجهزة اللوحية متطلبات مشابهة لعمليات تنفيذ التطبيقات على الأجهزة المزوّدة بشاشة تعمل باللمس. يتم الإشارة إلى الاستثناءات بعلامة * في ذلك القسم وإدراجها للرجوع إليها في هذا القسم.
2.6.1. الأجهزة
الجيروسكوب
إذا كانت عمليات تنفيذ الأجهزة اللوحية تتضمّن جيروسكوبًا ثلاثي المحاور، يجب استيفاء الشروط التالية:
- [7.3.4/Tab-1-1] يجب أن يكون الجهاز قادرًا على قياس التغيُّرات في اتجاهه بسرعة تصل إلى 1,000 درجة في الثانية.
الحد الأدنى للذاكرة ومساحة التخزين (الفقرة 7.6.1)
لا تسري كثافات الشاشة المُدرَجة للّوحات الصغيرة/العادية في متطلبات الأجهزة المزوّدة بشاشة تعمل باللمس على الأجهزة اللوحية.
وضع جهاز USB الملحق (الفقرة 7.7.1)
إذا كانت عمليات تنفيذ الأجهزة اللوحية تتضمّن منفذ USB متوافقًا مع وضع استخدام الأجهزة الطرفية، يجب استيفاء الشروط التالية:
- [7.7.1/Tab] يجوز تنفيذ واجهة برمجة التطبيقات Android Open Accessory (AOA).
وضع الواقع الافتراضي (الفقرة 7.9.1)
الأداء العالي للواقع الافتراضي (الفقرة 7.9.2)
لا تسري متطلبات الواقع الافتراضي على الأجهزة اللوحية.
2.6.2. نموذج الأمان
المفاتيح وبيانات الاعتماد (الفقرة 9.11)
يُرجى الرجوع إلى القسم [9.11].
إذا كانت عمليات تنفيذ الأجهزة اللوحية تتضمّن مستخدمين متعدّدين ولم يتم تحديد علامة ميزة android.hardware.telephony
، يحدث ما يلي:
- [9.5/T-1-1] يجب أن تتيح إمكانية استخدام الملفات الشخصية المحظورة، وهي ميزة تتيح لمالكي الأجهزة إدارة مستخدمين إضافيين وتحديد أذوناتهم على الجهاز. باستخدام الملفات الشخصية المحظورة، يمكن لمالكي الأجهزة إعداد بيئات منفصلة بسرعة ليستخدمها مستخدمون إضافيون، مع إمكانية إدارة قيود أكثر دقة في التطبيقات التي تتوفّر في تلك البيئات.
إذا كانت عمليات تنفيذ الأجهزة اللوحية تتضمّن مستخدمين متعدّدين ويُعلن عنها
باستخدام علامة ميزة android.hardware.telephony
، يتم تنفيذ ما يلي:
- [9.5/T-2-1] يجب ألّا يتوافق مع الملفات الشخصية المقيّدة، بل يجب أن يكون متوافقًا مع طريقة تنفيذ عناصر التحكّم في AOSP لتشغيل /إيقاف إمكانية وصول المستخدمين الآخرين إلى المكالمات الصوتية والرسائل القصيرة.
2.6.2. البرامج
- [3.2.3.1/Tab-0-1] يجب تحميل تطبيقات أو مكونات خدمة واحدة أو أكثر مسبقًا باستخدام معالِج أهداف، وذلك لجميع نماذج فلاتر الأهداف العامة التي تحدّدها أهداف التطبيقات التالية المدرَجة هنا.
3- البرامج
3.1. التوافق مع واجهة برمجة التطبيقات المُدارة
تشكّل بيئة تنفيذ رمز بايت Dalvik المُدارة الوسيلة الأساسية لتشغيل تطبيقات Android. واجهة برمجة تطبيقات Android هي مجموعة من واجهات نظام Android الأساسي التي يتم عرضها للتطبيقات التي تعمل في بيئة التشغيل المُدارة.
عمليات التنفيذ على الأجهزة:
[C-0-1] يجب توفير عمليات تنفيذ كاملة، بما في ذلك جميع السلوكيات الموثَّقة ، لأي واجهة برمجة تطبيقات موثَّقة يوفّرها حزمة تطوير البرامج (SDK) لنظام التشغيل Android أو أي واجهة برمجة تطبيقات تم تزيينها بعلامة "@SystemApi" في رمز المصدر لنظام التشغيل Android.
[C-0-2] يجب أن تتوافق/تحافظ على جميع الفئات والأساليب والعناصر المرتبطة التي تم وضع التعليق التوضيحي TestApi عليها ("@TestApi").
[C-0-3] يجب عدم حذف أي واجهات برمجة تطبيقات مُدارة أو تغيير واجهات برمجة التطبيقات أو توقيعاتها، أو الانحراف عن السلوك المُسجَّل، أو تضمين عمليات لا تؤدي إلى أيّ تأثير، إلا في الحالات التي يسمح فيها تحديد التوافق هذا تحديدًا بذلك.
[C-0-4] يجب أن تظل واجهات برمجة التطبيقات متوفّرة وأن تعمل بطريقة معقولة، حتى في حال حذف بعض ميزات الأجهزة التي يتضمّن Android واجهات برمجة تطبيقات لها. اطّلِع على القسم 7 لمعرفة المتطلبات المحدّدة لهذا السيناريو.
[C-0-5] يجب عدم السماح للتطبيقات التابعة لجهات خارجية باستخدام واجهات غير متوفرة في حزمة SDK، والتي يتم تحديدها على أنّها طُرق وحقول في حِزم لغة Java التي يتم تضمينها في مسار تحميل البرامج في AOSP، والتي لا تشكّل جزءًا من حزمة SDK العامة. ويشمل ذلك واجهات برمجة التطبيقات التي تم تزيينها بالتعليق التوضيحي
@hide
وليس باستخدام@SystemAPI
، كما هو موضّح في مستندات حزمة تطوير البرامج (SDK) وعناصر الفئات الخاصة والخاصة بالحزمة.[C-0-6] يجب أن يتم شحن كل واجهة برمجة تطبيقات غير مضمّنة في حزمة تطوير البرامج (SDK) مع كل قوائم التطبيقات المحظورة نفسها كما هو موضح من خلال علامتَي المؤقتة وقائمة الرفض في
prebuilts/runtime/appcompat/hiddenapi-flags.csv
مسار الإصدار المناسب لمستوى واجهة برمجة التطبيقات في AOSP.[C-0-7] يجب أن يكون التطبيق متوافقًا مع آلية التعديل الديناميكي للإعدادات الموقَّعة لإزالة الواجهات غير المضمّنة في حزمة تطوير البرامج (SDK) من قائمة محظورة من خلال تضمين الإعدادات الموقَّعة في أي حزمة APK باستخدام المفاتيح العامة الحالية المتوفّرة في AOSP.
ومع ذلك، فإنّه:
- يجوز، في حال عدم توفّر واجهة برمجة تطبيقات مخفية أو تنفيذها بشكل مختلف على عملية تنفيذ التطبيق، نقل واجهة برمجة التطبيقات المخفية إلى القائمة المرفوضة أو حذفها من جميع القوائم المحظورة.
- يجوز إضافة واجهة برمجة التطبيقات المخفية إلى أي من القوائم المحظورة، إذا لم تكن واجهة برمجة التطبيقات المخفية متوفّرة في AOSP.
3.1.1. إضافات Android
يتيح Android توسيع نطاق واجهة برمجة التطبيقات المُدارة لمستوى معيّن من واجهة برمجة التطبيقات من خلال
تعديل إصدار الإضافة لهذا المستوى من واجهة برمجة التطبيقات. تعرض واجهة برمجة التطبيقات
android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel)
إصدار الإضافةapiLevel
المقدَّم، في حال توفّر إضافات لمستوى
واجهة برمجة التطبيقات هذا.
عمليات تنفيذ أجهزة Android:
[C-0-1] يجب تحميل حزمة AOSP المُنفِّذة لكلٍّ من المكتبة المشترَكة
ExtShared
والخدماتExtServices
مسبقًا باستخدام إصدارات أكبر من أو مساوية للحد الأدنى من الإصدارات المسموح بها لكل مستوى من مستويات واجهة برمجة التطبيقات. على سبيل المثال، في عمليات تنفيذ الأجهزة التي تعمل بالإصدار 7.0 من نظام التشغيل Android والمستوى 24 لواجهة برمجة التطبيقات، يجب أن يتضمّن الإصدار 1 على الأقل.[C-0-2] يجب ألا يعرض سوى رقم إصدار صالح للإضافة تم تحديده من خلال AOSP.
[C-0-3] يجب أن تتوافق مع جميع واجهات برمجة التطبيقات المحدّدة من خلال إصدارات الإضافة التي يعرضها
android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel)
بالطريقة نفسها التي تتوافق بها واجهات برمجة التطبيقات المُدارة الأخرى، وذلك باتّباع requirements في الفقرة 3.1.
3.1.2. مكتبة Android
بسبب إيقاف برنامج Apache HTTP client نهائيًا، في عمليات التنفيذ على الأجهزة:
- [C-0-1] يجب عدم وضع مكتبة
org.apache.http.legacy
في bootclasspath. - [C-0-2] يجب إضافة مكتبة
org.apache.http.legacy
إلى ملف classpath للتطبيق فقط عندما يستوفي التطبيق أحد الشروط التالية:- تستهدف المستوى 28 أو أقل من واجهة برمجة التطبيقات
- يُعلن في البيان أنّه يحتاج إلى المكتبة من خلال ضبط سمة
android:name
لـ<uses-library>
علىorg.apache.http.legacy
.
يستوفي تطبيق AOSP هذه المتطلبات.
3.2. التوافق مع واجهة برمجة التطبيقات
بالإضافة إلى واجهات برمجة التطبيقات المُدارة من الفقرة 3.1، يحتوي Android أيضًا على واجهة برمجة تطبيقات "غير حاسمة" مهمة تعمل أثناء التشغيل فقط، في شكل عناصر مثل النوايا والأذونات والجوانب المشابهة لتطبيقات Android التي لا يمكن فرضها في وقت تجميع التطبيق.
3.2.1. الأذونات
- [C-0-1] على جهات تنفيذ الأجهزة توفير كل ثباتات الأذونات وفرضها كما هو موضّح في صفحة مرجع الأذونات. يُرجى العلم أنّ الفقرة 9 تسرد متطلبات إضافية تتعلّق بنموذج أمان Android.
3.2.2. مَعلمات التصميم
تتضمّن واجهات برمجة تطبيقات Android عددًا من الثوابت في فئة android.os.Build المخصّصة لوصف الجهاز الحالي.
- [C-0-1] لتوفير قيم متسقة وذات مغزى في جميع عمليات تنفيذ الأجهزة، يتضمّن الجدول أدناه قيودًا إضافية على تنسيقات هذه القيم التي يجب أن تتوافق معها عمليات تنفيذ الأجهزة.
المَعلمة | التفاصيل |
---|---|
VERSION.RELEASE | إصدار نظام Android الذي يتم تنفيذه حاليًا بتنسيق يمكن للمستخدمين قراءته يجب أن يحتوي هذا الحقل على إحدى قيم السلاسل المحدّدة في سلاسل الإصدارات المسموح بها لنظام التشغيل Android 12. |
VERSION.SDK | إصدار نظام Android الذي يتم تنفيذه حاليًا بتنسيق يمكن لرمز التطبيق التابع لجهة خارجية الوصول إليه بالنسبة إلى Android 12، يجب أن يحتوي هذا الحقل على القيمة الصحيحة 12_INT. |
VERSION.SDK_INT | إصدار نظام Android الذي يتم تنفيذه حاليًا بتنسيق يمكن لرمز التطبيق التابع لجهة خارجية الوصول إليه بالنسبة إلى Android 12، يجب أن يحتوي هذا الحقل على القيمة الصحيحة 12_INT. |
VERSION.INCREMENTAL | قيمة يختارها مُنفِّذ الجهاز لتحديد الإصدار المحدد من نظام Android الذي يتم تنفيذه حاليًا، بتنسيق يمكن لشخص عادي قراءته يجب عدم إعادة استخدام هذه القيمة في الإصدارات المختلفة المتاحة للمستخدمين النهائيين. أحد استخدامات هذا الحقل المعتادة هي الإشارة إلى رقم الإصدار أو معرّف تغيير التحكّم في المصدر الذي تم استخدامه لإنشاء الإصدار. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII القابل للطباعة المكوّن من 7 بتات وأن تتطابق مع العبارة العادية "^[^ :\/~]+$". |
ألعاب ألواح | قيمة يختارها منفذ الجهاز لتحديد المكونات الداخلية المحدّدة التي يستخدمها الجهاز، بتنسيق يمكن لشخص عادي قراءته من بين الاستخدامات المحتملة لهذا الحقل الإشارة إلى المراجعة المحدّدة للوحة التي توفّر питаниеً للجهاز. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بت ويجب أن تتماثل مع التعبير العادي "^[a-zA-Z0-9_-]+$". |
العلامة التجارية | قيمة تعكس اسم العلامة التجارية المرتبط بالجهاز كما هو معروف للمستخدمين النهائيين يجب أن يكون بتنسيق يسهل قراءته ويجب أن يمثّل الشركة المصنّعة للجهاز أو علامة الشركة التجارية التي يتم تحتها التسويق للجهاز. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بتات وأن تتطابق مع التعبير العادي "^[a-zA-Z0-9_-]+$". |
SUPPORTED_ABIS | اسم مجموعة التعليمات (نوع وحدة المعالجة المركزية + اصطلاح ABI) للرمز المبرمَج الأصلي راجِع الفقرة 3.3. توافق واجهة برمجة التطبيقات المدمجة |
SUPPORTED_32_BIT_ABIS | اسم مجموعة التعليمات (نوع وحدة المعالجة المركزية + اصطلاح ABI) للرمز المبرمَج الأصلي راجِع الفقرة 3.3. توافق واجهة برمجة التطبيقات المدمجة |
SUPPORTED_64_BIT_ABIS | اسم مجموعة التعليمات الثانية (نوع وحدة المعالجة المركزية + اصطلاح ABI) للرمز البرمجي الأصلي راجِع الفقرة 3.3. التوافق مع واجهة برمجة التطبيقات الأساسية |
CPU_ABI | اسم مجموعة التعليمات (نوع وحدة المعالجة المركزية + اصطلاح ABI) للرمز المبرمَج الأصلي راجِع الفقرة 3.3. توافق واجهة برمجة التطبيقات المدمجة |
CPU_ABI2 | اسم مجموعة التعليمات الثانية (نوع وحدة المعالجة المركزية + اصطلاح ABI) للرمز البرمجي الأصلي راجِع الفقرة 3.3. التوافق مع واجهة برمجة التطبيقات الأساسية |
الجهاز | قيمة يختارها منفذ الجهاز تحتوي على اسم التطوير أو الاسم الرمزي الذي يحدِّد إعدادات ميزات الجهاز والتصميم الصناعي للجهاز. يجب أن تكون قيمة هذا الحقل قابلة للترميز على أنّها 7 بت ASCII وأن تتطابق مع التعبير العادي “^[a-zA-Z0-9_-]+$”. يجب ألّا يتغيّر اسم الجهاز هذا أثناء فترة استخدام المنتج. |
بصمة الإصبع | سلسلة تحدّد هذا الإصدار بشكل فريد يجب أن يكون سهل القراءة
إلى حدٍّ معقول. يجب أن يتّبع هذا النموذج:
$(BRAND)/$(PRODUCT)/ مثلاً: acme/myproduct/ يجب ألّا يتضمّن بصمة الجهاز أحرف مسافات بيضاء. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بتات. |
الأجهزة | اسم الجهاز (من سطر أوامر kernel أو /proc) يجب أن يكون المحتوى سهل القراءة على الإنسان. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بتات وأن تتطابق مع التعبير العادي “^[a-zA-Z0-9_-]+$”. |
مضيف | سلسلة تحدِّد بشكل فريد المضيف الذي تم إنشاء الإصدار عليه، بتنسيق يمكن لشخص عادي قراءته ما مِن متطلبات بشأن التنسيق المحدّد لهذا الحقل، باستثناء أنّه يجب ألّا يكون فارغًا أو سلسلة فارغة (""). |
رقم التعريف | معرّف يختاره منفذ الجهاز للإشارة إلى إصدار معيّن بتنسيق يسهل على المستخدم قراءته يمكن أن يكون هذا الحقل هو نفسه android.os.Build.VERSION.INCREMENTAL، ولكن يجب أن يكون قيمة ذات مغزى كافٍ للمستخدمين النهائيين من أجل التمييز بين إصدارات البرامج. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بتات وأن تتطابق مع التعبير العادي “^[a-zA-Z0-9._-]+$”. |
الشركة المصنّعة | الاسم التجاري للمصنّع الأصلي للجهاز الذي يصنع المنتج ما مِن متطلبات حول التنسيق المحدّد لهذا الحقل، باستثناء أنّه يجب ألّا يكون فارغًا أو سلسلة فارغة (""). يجب ألّا يتغيّر هذا الحقل خلال فترة توفّر المنتج. |
SOC_MANUFACTURER | الاسم التجاري للشركة المصنّعة للمنظومة الأساسية على الرقاقة (SoC) المستخدَمة في المنتج. يجب أن تستخدم الأجهزة التي تحمل الشركة المصنّعة نفسها للنظام على الرقاقة القيمة الثابتة نفسها. يُرجى طلب المتغيّر الصحيح من الشركة المصنّعة لوحدة التحكّم في الشريحة. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بتات، ويجب أن تتطابق مع التعبير العادي "^([0-9A-Za-z ]+)"، ويجب ألّا تبدأ بمسافة أو تنتهي بها، ويجب ألّا تساوي "غير معروف". ويجب ألّا يتغيّر هذا الحقل خلال فترة استخدام المنتج. |
SOC_MODEL | اسم طراز المنظومة الأساسية على الرقاقة (SoC) المستخدَمة في المنتج. يجب أن تستخدم الأجهزة التي تتضمّن طراز وحدة المعالجة المركزية (SOC) نفسه القيمة الثابتة نفسها. يُرجى سؤال الشركة المصنّعة لوحدة التحكّم في الشريحة عن القيمة الثابتة الصحيحة التي يجب استخدامها. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بتات وأن تتطابق مع التعبير العادي "^([0-9A-Za-z ._/+-]+)$"، ويجب ألّا تبدأ أو تنتهي بمسافة بيضاء، ويجب ألّا تساوي "غير معروف". يجب ألّا يتغيّر هذا الحقل أثناء فترة استخدام المنتج. |
الطراز | قيمة يختارها منفذ الجهاز تحتوي على اسم الجهاز كما يعرفه المستخدم النهائي. يجب أن يكون هذا هو الاسم نفسه الذي يتم بموجبه تسويق الجهاز وبيعه للمستخدمين النهائيين. ما مِن متطلبات تتعلّق بالتنسيق المحدّد لهذا الحقل، باستثناء أنّه يجب ألا يكون فارغًا أو سلسلة فارغة (""). يجب ألا يتغيّر هذا الحقل خلال فترة توفّر المنتج. |
المنتج | قيمة يختارها مُنفِّذ الجهاز تحتوي على اسم التطوير أو الاسم الرمزي للمنتج المحدّد (رمز التخزين التعريفي) الذي يجب أن يكون فريدًا ضمن العلامة التجارية نفسها. يجب أن تكون قابلة للقراءة من قِبل البشر، ولكن ليس بالضرورة أن تكون مخصّصة للعرض من قِبل المستخدمين النهائيين. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بت ويجب أن تتطابق مع التعبير العادي "^[a-zA-Z0-9_-]+$". ويجب ألّا يتغيّر اسم المنتج خلال فترة استخدام المنتج. |
ODM_SKU | قيمة اختيارية يختارها منفذ الجهاز تحتوي على
رمز التخزين التعريفي (SKU) المستخدَم لتتبُّع إعدادات محدّدة
للجهاز، مثل أي أجهزة ملحقة مضمّنة مع الجهاز عند بيعه.
يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بتات وأن تتطابق مع
التعبير العادي ^([0-9A-Za-z.,_-]+)$ . |
SERIAL | يجب أن يعرض العنصر القيمة "UNKNOWN". |
العلامات | قائمة مفصولة بفواصل بالعلامات التي اختارها مُنفِّذ الجهاز والتي تُميِّز الإصدار بشكلٍ أكبر يجب أن تكون العلامات قابلة للترميز بترميز ASCII المكوّن من 7 بت وأن تتطابق مع التعبير العادي "^[a-zA-Z0-9._-]+"، ويجب أن تتضمن إحدى القيم المقابلة لإعدادات توقيع نظام التشغيل Android الثلاثة النموذجية: مفاتيح الإصدار ومفاتيح المطوّرين ومفاتيح الاختبار. |
الوقت | قيمة تمثّل الطابع الزمني لوقت إنشاء الإصدار |
النوع | قيمة يختارها مُنفِّذ الجهاز لتحديد إعدادات وقت التشغيل للإصدار يجب أن يحتوي هذا الحقل على إحدى القيم التالية التي تتوافق مع الإعدادات الثلاثة المعتادة لوقت تشغيل Android: user أو userdebug أو eng. |
المستخدم | اسم أو رقم تعريف المستخدم (أو المستخدم المبرمَج) الذي أنشأ النسخة ما مِن متطلبات بشأن التنسيق المحدّد لهذا الحقل، باستثناء أنّه يجب ألّا يكون فارغًا أو سلسلة فارغة (""). |
SECURITY_PATCH | قيمة تشير إلى مستوى تصحيح الأمان لإصدار معيّن يجب أن يشير ذلك إلى أنّ الإصدار ليس معرّضًا بأي شكل من الأشكال لأي من المشاكل الموضّحة في نشرة أمان Android العامة المحدّدة. يجب أن تكون بالتنسيق [YYYY-MM-DD]، وأن تتطابق مع سلسلة محدّدة موثّقة في نشرة أمان Android العامة أو في إشعار أمان Android، على سبيل المثال "2015-11-01". |
BASE_OS | قيمة تمثّل مَعلمة FINGERPRINT للإصدار الذي هو مطابق لهذا الإصدار باستثناء الرقع المقدَّمة في نشرة الأمان العام لنظام التشغيل Android يجب أن يعرض الإصدار القيمة الصحيحة، وإذا لم يكن هذا الإصدار متوفّرًا، يجب عرض سلسلة فارغة (""). |
برنامج تحميل التشغيل | قيمة يختارها منفذ الجهاز لتحديد إصدار bootloader الداخلي المُستخدَم في الجهاز بتنسيق يمكن لشخص عادي قراءته يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بتات وأن تتطابق مع التعبير العادي "^[a-zA-Z0-9._-]+$". |
getRadioVersion() | يجب أن تكون (أو تعرض) قيمة يختارها منفذ الجهاز لتحديد إصدار الراديو/المودم الداخلي المحدّد المستخدَم في الجهاز، بتنسيق يمكن لشخص عادي قراءته. إذا لم يكن الجهاز يحتوي على أي إشارة تردد لاسلكي/مودم داخلي، يجب أن يعرض القيمة NULL. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بتات وأن تتطابق مع التعبير العادي “^[a-zA-Z0-9._-,]+$”. |
getSerial() | يجب أن يكون (أو يعرض) رقمًا تسلسليًا للأجهزة، ويجب أن يكون متاحًا وفريدًا على مستوى الأجهزة التي تحمل الطراز والشركة المصنّعة نفسها. يجب أن تكون قيمة هذا الحقل قابلة للترميز بترميز ASCII المكوّن من 7 بتات وأن تتطابق مع التعبير العادي “^[a-zA-Z0-9._-,]+$”. |
3.2.3. توافق الغرض
3.2.3.1. نوايا التطبيقات الشائعة
تسمح رسائل Intent في Android لمكوّنات التطبيقات بطلب وظائف من مكوّنات Android الأخرى. يتضمّن مشروع Android upstream قائمة بالتطبيقات التي تُنفِّذ عدّة أنماط للنوايا لتنفيذ الإجراءات الشائعة.
عمليات التنفيذ على الأجهزة:
- [C-SR-1] يُنصح بشدة بتثبيت تطبيق واحد أو أكثر أو مكونات خدمة واحدة أو أكثر مسبقًا باستخدام معالِج أهداف، وذلك لجميع أنماط فلاتر الأهداف العامة التي تحدّدها أهداف التطبيقات التالية المدرَجة هنا، وتوفير الامتثال، أي تلبية توقعات المطوّر لهذه الأهداف المشترَكة للتطبيقات كما هو موضّح في حزمة تطوير البرامج (SDK).
يُرجى الرجوع إلى القسم 2 للاطّلاع على أذونات التطبيقات الإلزامية لكل نوع من أنواع الأجهزة.
3.2.3.2. حلّ النية
[C-0-1] بما أنّ Android هو نظام أساسي قابل للتوسيع، يجب أن تسمح عمليات تنفيذ الأجهزة بتجاوز كل نمط نية تتم الإشارة إليه في الفقرة 3.2.3.1 ، باستثناء "الإعدادات"، من خلال التطبيقات التابعة لجهات خارجية. يسمح الإصدار الأحدث من Android المفتوح المصدر بذلك تلقائيًا.
[C-0-2] يجب ألا يربط مورّدو الأجهزة امتيازات خاصة باستخدام تطبيقات النظام لنماذج النوايا هذه، أو يمنع التطبيقات التابعة لجهات خارجية من الربط بهذه الأنماط وتولي التحكّم فيها. ويشمل هذا الحظر تحديدًا، على سبيل المثال لا الحصر، إيقاف واجهة مستخدم "أداة الاختيار" التي تسمح للمستخدم بالاختيار بين تطبيقات متعددة تعالج جميعًا نمط الطلب نفسه.
[C-0-3] يجب أن توفّر عمليات تنفيذ الأجهزة واجهة مستخدم تتيح للمستخدمين تعديل النشاط التلقائي للنوايا.
ومع ذلك، قد تقدّم عمليات تنفيذ الأجهزة أنشطة تلقائية لنماذج عناوين URI معيّنة (مثل http://play.google.com) عندما يوفّر النشاط التلقائي سمة أكثر تحديدًا لعنوان URL للبيانات. على سبيل المثال، يكون نمط فلتر الأهداف الذي يحدِّد معرّف الموارد المنتظم للبيانات "http://www.android.com" أكثر تحديدًا من نمط العمل الأساسي للمتصفّح الذي يحدِّد "http://".
يتضمّن Android أيضًا آلية تتيح للتطبيقات التابعة لجهات خارجية الإفصاح عن سلوك ربط التطبيقات التلقائي والموثوق به لأنواع معيّنة من نوايا معرّفات الموارد المنتظمة (URI) للويب. عند تحديد هذه البيانات الموثوقة في أنماط فلاتر الأهداف للتطبيق، تُنفِّذ الأجهزة ما يلي:
- [C-0-4] يجب محاولة التحقّق من صحة أي فلاتر أهداف من خلال تنفيذ خطوات التحقّق المحدّدة في مواصفات روابط التنقل إلى مواد العرض الرقمية كما نفّذها "مدير الحِزم" في "مشروع Android Open Source" المرتبط.
- [C-0-5] يجب محاولة التحقّق من فلاتر الأهداف أثناء تثبيت التطبيق وضبط جميع فلاتر أهداف عناوين URL التي تم التحقّق منها بنجاح على أنّها معالجات التطبيقات التلقائية لعناوين URL الخاصة بها.
- يجوز لها ضبط فلاتر أهداف معيّنة لعناوين URL كمعالِجات تطبيق تلقائية لمعرّفات URL الخاصة بها، إذا تم التحقّق منها بنجاح ولكن تعذّر التحقّق من فلاتر عناوين URL المعنيّة الأخرى. إذا كان تنفيذ الجهاز يفعل ذلك، يجب أن يقدّم عمليات إلغاء أنماط لكل معرّف موارد منتظم (URI) مناسبة للمستخدم في قائمة الإعدادات.
- يجب أن يوفّر التطبيق للمستخدم عناصر التحكّم في "روابط التطبيقات" لكل تطبيق في "الإعدادات" على النحو التالي:
- [C-0-6] يجب أن يتمكّن المستخدم من إلغاء السلوك التلقائي ل روابط التطبيقات بشكل كامل لكي يكون التطبيق: مفتوحًا دائمًا أو يسأل المستخدم دائمًا أو لا يفتح أبدًا، وذلك يجب أن ينطبق على جميع فلاتر الأغراض لمعرّفات الموارد المنتظمة المعنيّة بالتساوي.
- [C-0-7] يجب أن يتمكّن المستخدم من الاطّلاع على قائمة بفلاتر بنية URI المعنيّة.
- قد يمنح تنفيذ الجهاز المستخدم إمكانية تجاوز فلاتر أهداف معرّفات الموارد المنتظمة (URI) المرشحة المحدّدة التي تم التحقّق منها بنجاح، وذلك على أساس كل فلتر هدف.
- [C-0-8] يجب أن يمنح تنفيذ الجهاز للمستخدمين إمكانية عرض فلاتر أهداف معيّنة لمعرّفات الموارد المنتظمة (URI) المرشحة وإلغاء تطبيقها إذا كان تنفيذ الجهاز يسمح لبعض فلاتر أهداف معرّفات الموارد المنتظمة (URI) المرشحة بالنجاح في التحقّق بينما يمكن أن يفشل البعض الآخر.
3.2.3.3. مساحات أسماء الأهداف
- [C-0-1] يجب ألا تتضمّن عمليات تنفيذ الأجهزة أي مكوّن Android يراعي أي أنماط جديدة لأهداف البث أو الأهداف باستخدام سلسلة مفتاح ACTION أو CATEGORY أو سلسلة مفتاح أخرى في مساحة الاسم android.* أو com.android.*.
- [C-0-2] يجب ألا يُدرِج مورّدو الأجهزة أيّ مكونات Android تراعي أيّ أنماط جديدة لطلبات التشغيل أو أنماط طلبات البث باستخدام سلسلة مفتاح ACTION أو CATEGORY أو سلسلة مفتاح أخرى في مساحة حزمة تابعة لمؤسسة أخرى.
- [C-0-3] على جهات تنفيذ الأجهزة عدم تغيير أيّ من نماذج النوايا المُدرَجة في الفقرة 3.2.3.1 أو توسيع نطاقها.
- قد تتضمّن عمليات تنفيذ الأجهزة أنماط النية باستخدام مساحات الاسم التي تكون مرتبطة بوضوح بمؤسستها. هذا الحظر هو مشابه للحظر المحدّد لفئات لغة Java في الفقرة 3.6.
3.2.3.4. نوايا البث
تعتمد التطبيقات التابعة لجهات خارجية على المنصة لبث بيانات نية معيّنة بهدف إعلامها بالتغييرات في بيئة الأجهزة أو البرامج.
عمليات التنفيذ على الأجهزة:
- [C-0-1] يجب بث نوايا البث العام المدرَجة هنا استجابةً لأحداث النظام المناسبة كما هو موضّح في مستندات حِزم تطوير البرامج (SDK). يُرجى العلم أنّ هذا الشرط لا يتعارض مع القسم 3.5 لأنّه تتم أيضًا الإشارة إلى حدود التطبيقات التي تعمل في الخلفية في مستندات حِزم تطوير البرامج (SDK). تعتمد بعض نوايا البث أيضًا على توفُّر الأجهزة اللازمة، فإذا كان الجهاز يتضمّن الأجهزة اللازمة، يجب أن يبث رسائل برمجية لتنفيذ هذه النوايا وأن يقدّم السلوك بما يتوافق مع مستندات حزمة SDK.
3.2.3.5. نوايا التطبيقات المشروطة
يتضمّن Android إعدادات توفّر للمستخدمين طريقة سهلة لاختيار تطبيقاتهم التلقائية، على سبيل المثال، للشاشة الرئيسية أو الرسائل القصيرة.
يجب أن تقدّم عمليات تنفيذ الأجهزة ملفًا مماثلاً لإعدادات الملف وأن تكون متوافقة مع نمط فلتر الأهداف وطرق واجهة برمجة التطبيقات الموضّحة في مستندات حزمة تطوير البرامج (SDK) كما هو موضّح أدناه.
إذا أبلغت عمليات تنفيذ الأجهزة عن android.software.home_screen
، يعني ذلك ما يلي:
- [C-1-1] يجب الالتزام
android.settings.HOME_SETTINGS
بنية عرض قائمة إعدادات التطبيق التلقائية على الشاشة الرئيسية.
إذا أبلغت عمليات تنفيذ الأجهزة عن android.hardware.telephony
، يعني ذلك ما يلي:
[C-2-1] يجب توفير قائمة إعدادات تستدعي
android.provider.Telephony.ACTION_CHANGE_DEFAULT
intent لعرض مربّع حوار لتغيير تطبيق الرسائل القصيرة التلقائي.[C-2-2] يجب الالتزام
android.telecom.action.CHANGE_DEFAULT_DIALER
بنية عرض مربّع حوار للسماح للمستخدم بتغيير تطبيق الهاتف التلقائي.- يجب استخدام واجهة المستخدم التلقائية لتطبيق "الهاتف" التي يختارها المستخدم للمكالمات الواردة والصادرة باستثناء مكالمات الطوارئ التي ستستخدم تطبيق "الهاتف" المثبَّت مسبقًا.
[C-2-3] يجب الالتزام بغرض android.telecom.action.CHANGE_PHONE_ACCOUNTS لتوفير إمكانية ضبط
ConnectionServices
المرتبطة بـPhoneAccounts
، بالإضافة إلى PhoneAccount التلقائي الذي سيستخدمه مقدّم خدمة الاتصالات الهاتفية لإجراء المكالمات الصادرة. يستوفي تطبيق AOSP هذا الشرط من خلال تضمين قائمة "خيارات حسابات الاتصال" ضمن قائمة إعدادات "المكالمات".[C-2-4] يجب السماح
android.telecom.CallRedirectionService
لتطبيق يشغل دورandroid.app.role.CALL_REDIRECTION
.[C-2-5] يجب أن توفّر للمستخدم إمكانية اختيار تطبيق يمتلك دور
android.app.role.CALL_REDIRECTION
.[C-2-6] يجب أن يتوافق التطبيق مع نيتي android.intent.action.SENDTO وandroid.intent.action.VIEW وأن يقدّم نشاطًا لإرسال رسائل SMS أو عرضها.
[C-SR-1] يُنصح بشدة بتنفيذ إجراءات android.intent.action.ANSWER، android.intent.action.CALL، android.intent.action.CALL_BUTTON، android.intent.action.VIEW & android.intent.action.DIAL باستخدام تطبيق اتصال مُحمَّل مسبقًا يمكنه معالجة هذه الإجراءات و توفير الامتثال كما هو موضّح في حزمة تطوير البرامج (SDK).
إذا أبلغت عمليات تنفيذ الأجهزة عن android.hardware.nfc.hce
، يعني ذلك ما يلي:
- [C-3-1] يجب الالتزام بهدف android.settings.NFC_PAYMENT_SETTINGS لعرض قائمة إعدادات تلقائية للتطبيق للدفع بدون تلامس الأجهزة.
- [C-3-2] يجب الالتزام بغرض android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT لعرض نشاط يفتح مربّع حوار لطلب المستخدم تغيير خدمة محاكاة البطاقات التلقائية لفئة معيّنة كما هو موضّح في حزمة تطوير البرامج (SDK).
إذا أبلغت عمليات تنفيذ الأجهزة عن android.hardware.nfc
، يعني ذلك ما يلي:
- [C-4-1] يجب أن يراعي التطبيق ملفات Intent التالية android.nfc.action.NDEF_DISCOVERED، android.nfc.action.TAG_DISCOVERED وandroid.nfc.action.TECH_DISCOVERED، لعرض نشاط يستوفي توقعات المطوّرين بشأن ملفات Intent هذه كما هو описан في حزمة تطوير البرامج (SDK).
إذا أبلغت عمليات تنفيذ الأجهزة عن android.hardware.bluetooth
، يعني ذلك ما يلي:
- [C-5-1] يجب أن يحترم النشاط ‘android.bluetooth.adapter.action.REQUEST_ENABLE’ وعرض نشاط نظام للسماح للمستخدم بتفعيل البلوتوث.
- [C-5-2] يجب الالتزام بغرض ‘android.bluetooth.adapter.action.REQUEST_DISCOVERABLE’ وعرض نشاط نظام يطلب وضع "الاكتشاف التلقائي".
إذا كانت عمليات تنفيذ الأجهزة تتيح ميزة "عدم الإزعاج"، فإنّها:
- [C-6-1] يجب تنفيذ نشاط يستجيب للintent
ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS
، وبالنسبة إلى عمليات التنفيذ التي تستخدم UI_MODE_TYPE_NORMAL، يجب أن يكون نشاطًا يمكن فيه للمستخدم منح التطبيق إذن الوصول إلى إعدادات سياسة "عدم الإزعاج" أو رفضه.
إذا كانت عمليات تنفيذ الأجهزة تسمح للمستخدمين باستخدام طرق إدخال تابعة لجهات خارجية على الجهاز، عليهم اتّباع ما يلي:
- [C-7-1] يجب توفير آلية يمكن للمستخدم الوصول إليها لإضافة
أساليب إدخال تابعة لجهات خارجية وضبطها استجابةً لمحاولة
android.settings.INPUT_METHOD_SETTINGS
التفاعل.
إذا كانت عمليات تنفيذ الأجهزة متوافقة مع خدمات إمكانية الوصول التابعة لجهات خارجية، يجب استيفاء الشروط التالية:
- [C-8-1] يجب الالتزام
android.settings.ACCESSIBILITY_SETTINGS
بهدف توفير آلية يمكن للمستخدم الوصول إليها لتفعيل خدمات تسهيل الاستخدام التابعة لجهات خارجية وإيقافها إلى جانب خدمات تسهيل الاستخدام المثبَّتة مسبقًا.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة ميزة "الاتصال السهل بشبكة Wi-Fi" وتوفير هذه الميزة للتطبيقات التابعة لجهات خارجية، يجب استيفاء الشروط التالية:
- [C-9-1] يجب تنفيذ واجهات برمجة التطبيقات Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI Intent كما هو موضّح في مستندات حزمة تطوير البرامج (SDK).
إذا كانت عمليات تنفيذ الأجهزة توفّر وضع توفير البيانات، يجب أن:
- [C-10-1] يجب توفير واجهة مستخدم في الإعدادات تعالج
Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS
القصد، ما يسمح للمستخدمين بإضافة تطبيقات إلى ملف الإعدادات أو إزالتها منه.
إذا لم توفّر عمليات تنفيذ الأجهزة وضع "توفير البيانات"، يجب أن تستوفي الشروط التالية:
- [C-11-1] يجب أن يتضمّن نشاطًا يعالج هدف ملف APK
Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS
، ولكن يجوز تنفيذه كإجراء لا يؤدي إلى أيّ تأثير.
إذا كانت عمليات تنفيذ الأجهزة تعلن عن توفّر كاميرا من خلال
android.hardware.camera.any
، يجب أن:
- [C-12-3] يجب السماح فقط لتطبيقات Android المثبَّتة مسبقًا بمعالجة
النوايا التالية
MediaStore.ACTION_IMAGE_CAPTURE
،MediaStore.ACTION_IMAGE_CAPTURE_SECURE
، وMediaStore.ACTION_VIDEO_CAPTURE
على النحو الموضّح في مستند حزمة تطوير البرامج (SDK).
إذا أبلغت عمليات تنفيذ الأجهزة عن android.software.device_admin
، يعني ذلك ما يلي:
[C-13-1] يجب أن تلتزم بالهدف
android.app.action.ADD_DEVICE_ADMIN
لتشغيل واجهة مستخدم لتوجيه المستخدم إلى إضافة مشرف الجهاز إلى النظام (أو السماح له برفضه).[C-13-2] يجب أن تلتزم التطبيقات بالطلبات التالية: android.app.action.PROVISION_MANAGED_PROFILE، android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD، android.app.action.SET_NEW_PASSWORD & android.app.action.START_ENCRYPTION ويجب أن تتضمّن نشاطًا لتنفيذ هذه الطلبات على النحو الموضّح في حِزمة تطوير البرامج (SDK) هنا.
إذا كانت عمليات تنفيذ الأجهزة تعلن عن علامة ميزة android.software.autofill
، يعني ذلك ما يلي:
- [C-14-1] يجب تنفيذ واجهات برمجة التطبيقات
AutofillService
وAutofillManager
بالكامل والالتزام بغرض android.settings.REQUEST_SET_AUTOFILL_SERVICE لعرض قائمة إعدادات التطبيق التلقائية لتفعيل ميزة الملء التلقائي وإيقافها وتغيير خدمة الملء التلقائي التلقائية للمستخدم.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن تطبيقًا مثبَّتًا مسبقًا أو إذا أردت السماح للتطبيقات التابعة لجهات خارجية بالوصول إلى إحصاءات الاستخدام، يجب اتّباع الخطوات التالية:
- [C-SR-2] يُنصح بشدة بتوفير آلية يمكن للمستخدم الوصول إليها لمنح
أو إبطال إذن الوصول إلى إحصاءات الاستخدام استجابةً لمحاولة تنفيذ الإجراء
android.settings.ACTION_USAGE_ACCESS_SETTINGS
للتطبيقات التي تذكر إذن
android.permission.PACKAGE_USAGE_STATS
.
إذا كانت عمليات تنفيذ الأجهزة تهدف إلى منع أي تطبيقات، بما في ذلك التطبيقات المُثبَّتة مسبقًا، من الوصول إلى إحصاءات الاستخدام، يجب أن تستوفي ما يلي:
- [C-15-1] يجب أن يتضمّن التطبيق نشاطًا يعالج android.settings.ACTION_USAGE_ACCESS_SETTINGS نمط الطلب، ولكن يجب تنفيذه كإجراء لا يؤدي إلى أيّ تأثير، أي أن يكون له سلوك مماثل لما يحدث عند رفض وصول المستخدم.
إذا كانت عمليات تنفيذ التطبيق على الأجهزة تعرض روابط تؤدي إلى الأنشطة المحدّدة من قِبل AutofillService_passwordsActivity في "الإعدادات" أو روابط تؤدي إلى كلمات مرور المستخدمين من خلال آلية مشابهة، يجب أن تستوفي المتطلبات التالية:
- [C-16-1] يجب عرض هذه الروابط لجميع خدمات الملء التلقائي المثبَّتة.
إذا كانت عمليات تنفيذ الأجهزة متوافقة مع VoiceInteractionService
وكان لديها أكثر
من تطبيق واحد يستخدم واجهة برمجة التطبيقات هذه مثبّتًا في الوقت نفسه، فإنّها:
- [C-18-1] يجب الالتزام
android.settings.ACTION_VOICE_INPUT_SETTINGS
بهدف عرض قائمة إعدادات تلقائية للتطبيق لإدخال الصوت والمساعدة.
إذا أبلغت عمليات تنفيذ الأجهزة عن الميزة android.hardware.audio.output
،
يحدث ما يلي:
- [C-SR-3] يُنصح بشدة بتوفير نشاط لتنفيذ طلبات android.intent.action.TTS_SERVICE و android.speech.tts.engine.INSTALL_TTS_DATA و android.speech.tts.engine.GET_SAMPLE_TEXT كما هو موضّح في حزمة تطوير البرامج (SDK) هنا.
يتيح Android استخدام شاشات الاستراحة التفاعلية، والتي كانت تُعرف سابقًا باسم "الأحلام". تسمح ميزات "شاشة الاستراحة" للمستخدمين بالتفاعل مع التطبيقات عندما يكون الجهاز متصلاً بمصدر طاقة في وضع الخمول أو في وضع الإرساء في قاعدة تثبيت مكتبية. عمليات تنفيذ الأجهزة:
- يجب أن تتضمّن ميزة توفير خلفيات شاشة وأن تقدّم خيار إعدادات لسماح
للمستخدمين بضبط خلفيات الشاشة استجابةً لintent
android.settings.DREAM_SETTINGS
.
3.2.4. الأنشطة على الشاشات الثانوية/المتعدّدة
إذا كانت عمليات تنفيذ الأجهزة تسمح بتشغيل أنشطة Android العادية على أكثر من شاشة واحدة، يجب أن تستوفي المتطلبات التالية:
- [C-1-1] يجب ضبط
android.software.activities_on_secondary_displays
علامة الميزة. - [C-1-2] يجب أن تضمن توافق واجهة برمجة التطبيقات مع النشاط الذي يتم تشغيله على الشاشة الأساسية.
- [C-1-3] يجب أن يعرض النشاط الجديد على الشاشة نفسها التي يعرض عليها النشاط الذي بدأه، وذلك عند بدء النشاط الجديد بدون تحديد شاشة مستهدَفة من خلال واجهة برمجة التطبيقات
ActivityOptions.setLaunchDisplayId()
. - [C-1-4] يجب محو جميع الأنشطة عند إزالة علامة
Display.FLAG_PRIVATE
. - [C-1-5] يجب إخفاء المحتوى بأمان على جميع الشاشات عندما يكون الجهاز مقفلًا
باستخدام شاشة قفل آمنة، ما لم يوافق التطبيق على عرضه أعلى شاشة
القفل باستخدام واجهة برمجة التطبيقات
Activity#setShowWhenLocked()
. - يجب أن يتضمّن
android.content.res.Configuration
الرمز الذي يتوافق مع هذا العرض من أجل عرضه وعمله بشكل صحيح والحفاظ على التوافق في حال بدء نشاط على الشاشة الثانوية.
إذا كانت عمليات تنفيذ الأجهزة تسمح بتشغيل أنشطة Android العادية على الشاشات الثانوية وكانت إحدى الشاشات الثانوية تتضمّن العلامة android.view.Display.FLAG_PRIVATE:
- [C-3-1] يجب أن يتمكّن من الانتقال إلى هذا العرض فقط مالك هذا العرض والنظام والأنشطة التي تظهر فيه حاليًا. يمكن للجميع الإطلاق على شاشة تتضمّن العلامة android.view.Display.FLAG_PUBLIC.
3.3. التوافق مع واجهات برمجة التطبيقات الأصلية
إنّ توافق الرموز البرمجية الأصلية يشكّل تحديًا. لهذا السبب، يُرجى العِلم أنّه على مُنفّذِي الأجهزة:
- [C-SR-1] يُنصح بشدة باستخدام عمليات تنفيذ المكتبات المُدرَجة أدناه من مشروع Android Open Source Project.
3.3.1. واجهات التطبيق الثنائية
يمكن لرمز Dalvik الثنائي المُدار استدعاء رمز أصلي متوفر في ملف
.apk
التطبيق كملف .so
ELF تم تجميعه للبنية المناسبة لأجهزة
الجهاز. بما أنّ الرموز البرمجية الأصلية تعتمد بشكل كبير على تكنولوجيا المعالج الأساسية، يحدِّد Android عددًا من واجهات ABI في IDE لنظام التشغيل Android.
عمليات التنفيذ على الأجهزة:
- [C-0-1] يجب أن يكون متوافقًا مع واجهة برمجة التطبيقات لنظام التشغيل Android NDK محدّدة واحدة أو أكثر.
- [C-0-2] يجب أن يتضمّن التطبيق إمكانية تشغيل الرموز البرمجية في البيئة المُدارة لبدء تنفيذ رمز برمجي أصلي باستخدام بنية Java Native Interface (JNI) المعتادة.
- [C-0-3] يجب أن يكون متوافقًا مع المصدر (أي متوافقًا مع الرأس) ومتوافقًا مع الثنائي (لمعيار ABI) مع كل مكتبة مطلوبة في القائمة أدناه.
- [C-0-5] يجب الإبلاغ بدقة عن واجهة التطبيق الثنائية (ABI) الأصلية المتوافقة مع الجهاز، وذلك من خلال المَعلمات
android.os.Build.SUPPORTED_ABIS
وandroid.os.Build.SUPPORTED_32_BIT_ABIS
وandroid.os.Build.SUPPORTED_64_BIT_ABIS
، وكلّ منها عبارة عن قائمة مفصولة بفواصل لواجهات ABI مرتبة من الأكثر إلى الأقل تفضيلًا. [C-0-6] يجب الإبلاغ، من خلال المَعلمات أعلاه، عن مجموعة فرعية من قائمة ABI التالية، ويجب عدم الإبلاغ عن أي ABI غير مُدرَج في القائمة.
armeabi
(لم يعُد متوافقًا مع NDK)armeabi-v7a
arm64-v8a
x86
x86-64
[C-0-7] يجب إتاحة جميع المكتبات التالية، التي توفّر واجهات برمجة تطبيقات أصلية، للتطبيقات التي تتضمّن رموزًا برمجية أصلية:
- libaaudio.so (دعم الصوت الأصلي في AAudio)
- libamidi.so (لإتاحة استخدام تنسيق MIDI الأصلي، إذا تمّت المطالبة بالميزة
android.software.midi
كما هو موضّح في القسم 5.9) - libandroid.so (لتوفير وظائف الأنشطة الأصلية في Android)
- libc (مكتبة C)
- libcamera2ndk.so
- libdl (الرابط الديناميكي)
- libEGL.so (إدارة سطح OpenGL الأصلي)
- libGLESv1_CM.so (OpenGL ES 1.x)
- libGLESv2.so (OpenGL ES 2.0)
- libGLESv3.so (OpenGL ES 3.x)
- libicui18n.so
- libicuuc.so
- libjnigraphics.so
- liblog (تسجيل Android)
- libmediandk.so (تتيح استخدام واجهات برمجة التطبيقات الأصلية للوسائط)
- libm (مكتبة الرياضيات)
- libneuralnetworks.so (Neural Networks API)
- libOpenMAXAL.so (لتوفير دعم OpenMAX AL 1.0.1)
- libOpenSLES.so (دعم الصوت في OpenSL ES 1.0.1)
- libRS.so
- libstdc++ (الحد الأدنى من الدعم لـ C++)
- libvulkan.so (Vulkan)
- libz (ضغط Zlib)
- واجهة JNI
[C-0-8] يجب عدم إضافة أو إزالة الدوال العامة للمكتبات الأصلية المُدرَجة أعلاه.
[C-0-9] يجب إدراج مكتبات إضافية غير تابعة لمشروع AOSP ومفتوحة مباشرةً أمام التطبيقات التابعة لجهات خارجية في
/vendor/etc/public.libraries.txt
.[C-0-10] يجب عدم إتاحة أي مكتبات أخرى مجمّعة من رموز برمجية أصلية تم تنفيذها و تقديمها في AOSP كمكتبات نظام للتطبيقات التابعة لجهات خارجية تستهدف واجهة برمجة التطبيقات المستوى 24 أو إصدارًا أحدث، لأنّ هذه المكتبات محجوزة.
[C-0-11] يجب تصدير جميع رموز دوال OpenGL ES 3.1 ومجموعة ملحقات Android ، كما هو محدّد في حزمة NDK، من خلال مكتبة
libGLESv3.so
. يُرجى العلم أنّه على الرغم من أنّه يجب أن تكون جميع الرموز متوفّرة، يصف القسم 7.1.4.1 بمزيد من التفصيل متطلبات وقت التنفيذ الكامل لكلٍّ من الدوالّ المقابلة.[C-0-12] يجب تصدير رموز الدوالّ الأساسية لرمودفدالّ Vulkan 1.0، بالإضافة إلى الإضافات
VK_KHR_surface
وVK_KHR_android_surface
VK_KHR_swapchain
وVK_KHR_maintenance1
وVK_KHR_get_physical_device_properties2
من خلال مكتبةlibvulkan.so
. يُرجى العِلم أنّه على الرغم من أنّه يجب أن تكون جميع الرموز متوفّرة، يصف القسم 7.1.4.2 بمزيد من التفصيل متطلبات وقت تنفيذ كل دالة مقابلة بالكامل.يجب إنشاؤها باستخدام رمز المصدر وملفات الرأس المتاحة في المشروع المصدر لنظام التشغيل Android المفتوح المصدر
يُرجى العلم أنّ الإصدارات المستقبلية من Android قد توفّر دعمًا لمزيد من IDE.
3.3.2. توافق الرمز الأصلي لنظام ARM 32 بت
إذا أبلغت عمليات تنفيذ الأجهزة عن توفّر armeabi
ABI، يتم تنفيذ ما يلي:
- [C-3-1] يجب أن يكون التطبيق متوافقًا أيضًا مع
armeabi-v7a
وأن يُبلغ عن توافقه، لأنّarmeabi
مخصّص للتوافق مع الإصدارات القديمة من التطبيقات فقط.
إذا أبلغت عمليات تنفيذ الأجهزة عن توافقها مع ABI armeabi-v7a
، بالنسبة إلى التطبيقات
التي تستخدم ABI هذا، يتم تنفيذ ما يلي:
[C-2-1] يجب تضمين السطور التالية في
/proc/cpuinfo
، ويجب عدم تغيير القيم على الجهاز نفسه، حتى عندما تتم قراءتها بواسطة واجهات برمجة التطبيقات الأخرى لنظام التشغيل.Features:
، متبوعة بقائمة بأي ميزات اختيارية لوحدة المعالجة المركزية ARMv7 متوافقة مع الجهازCPU architecture:
، متبوعًا بعدد صحيح يصف أعلى بنية ARM متوافقة للجهاز (مثل "8" لأجهزة ARMv8).
[C-2-2] يجب دائمًا إبقاء العمليات التالية متاحة، حتى في حالة تنفيذ ABI على بنية ARMv8، إما من خلال دعم وحدة المعالجة المركزية الأصلية أو من خلال محاكاة البرامج:
- تعليمات SWP وSWPB
- عمليات الحواجز CP15ISB وCP15DSB وCP15DMB
[C-2-3] يجب أن تتضمّن واجهة برمجة التطبيقات إمكانية استخدام وحدة Advanced SIMD (المعروفة أيضًا باسم NEON).
3.4. توافق الويب
3.4.1. توافق WebView
إذا كانت عمليات تنفيذ الأجهزة توفّر تنفيذًا كاملاً لواجهة برمجة التطبيقات
android.webkit.Webview
، فإنّها:
- [C-1-1] يجب الإبلاغ عن
android.software.webview
. - [C-1-2] يجب استخدام إصدار Chromium
من مشروع Android Open Source Project في الإصدار 12 من Android
لتنفيذ واجهة برمجة التطبيقات
android.webkit.WebView
. [C-1-3] يجب أن تكون سلسلة وكيل المستخدم التي يُبلغ عنها WebView بالتنسيق التالي:
Mozilla/5.0 (Linux; Android $(VERSION); [$(MODEL)] [Build/$(BUILD)]; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36
- يجب أن تكون قيمة السلسلة $(VERSION) هي نفسها قيمة android.os.Build.VERSION.RELEASE.
- يجوز أن تكون السلسلة $(MODEL) فارغة، ولكن إذا لم تكن فارغة، يجب أن يكون لديها القيمة نفسها مثل android.os.Build.MODEL.
- يجوز حذف "الإصدار/$(BUILD)"، ولكن إذا كان متوفّرًا، يجب أن تكون السلسلة $(BUILD) نفسها قيمة android.os.Build.ID.
- يجب أن تكون قيمة السلسلة $(CHROMIUM_VER) هي إصدار Chromium في المشروع المفتوح المصدر لنظام التشغيل Android.
- قد تحذف عمليات تنفيذ الأجهزة كلمة Mobile في سلسلة وكيل المستخدم.
يجب أن يتضمّن مكوّن WebView ميزات HTML5 بقدرٍ كبيرٍ ممكن، وإذا كان يتيح استخدام ميزة معيّنة، يجب أن يكون متوافقًا مع مواصفات HTML5.
[C-1-4] يجب عرض المحتوى المقدَّم أو محتوى عنوان URL البعيد في عملية مختلفة عن التطبيق الذي ينشئ WebView. على وجه التحديد، يجب أن تحصل عملية عرض الصور المنفصلة على امتيازات أقل، وأن يتم تشغيلها باستخدام معرّف مستخدم منفصل، وألا تتمكن من الوصول إلى دليل بيانات التطبيق، وألا تتمكن من الوصول إلى الشبكة مباشرةً، وألا تتمكن من الوصول إلا إلى الحد الأدنى من خدمات النظام المطلوبة من خلال Binder. يستوفي تطبيق WebView المُطبَّق على AOSP هذا الشرط.
يُرجى العلم أنّه إذا كانت عمليات تنفيذ الأجهزة ذات 32 بت أو تعلن عن علامة الميزة
android.hardware.ram.low
، يتم استثناؤها من C-1-3.
3.4.2. توافق المتصفّح
إذا كانت عمليات تنفيذ الأجهزة تتضمّن تطبيق متصفّح مستقلًا لتصفُّح الويب بشكل عام، يجب استيفاء الشروط التالية:
- [C-1-1] يجب أن تتوافق مع كل واجهات برمجة التطبيقات التالية المرتبطة بتكنولوجيا HTML5:
- [C-1-2] يجب أن تكون متوافقة مع webstorage API في HTML5/W3C، ويجب أن تكون متوافقة مع IndexedDB API في HTML5/W3C. يُرجى العِلم أنّه مع انتقال الهيئات التي تضع معايير تطوير الويب إلى تفضيل IndexedDB على قاعدة بيانات webstorage، من المتوقّع أن يصبح IndexedDB مكوّنًا مطلوبًا في أحد إصدارات Android القادمة.
- يجوز شحن سلسلة وكيل مستخدم مخصّصة في تطبيق المتصفّح المستقل.
- يجب أن يتيح استخدام أكبر قدر ممكن من HTML5 في تطبيق المتصفّح المستقل (سواء كان مستندًا إلى تطبيق WebKit Browser المتوافق مع الإصدارات السابقة أو بديلاً تابعًا لجهة خارجية).
ومع ذلك، إذا لم تتضمّن عمليات التنفيذ على الأجهزة تطبيقًا مستقلاً للمتصفّح، يجب استيفاء الشروط التالية:
- [C-2-1] يجب أن يظلّ التطبيق متوافقًا مع أنماط الأغراض العامة كما هو موضّح في القسم 3.2.3.1.
3.5. التوافق السلوكي لواجهة برمجة التطبيقات
عمليات التنفيذ على الأجهزة:
- [C-0-9] يجب التأكّد من تطبيق التوافق السلوكي لواجهات برمجة التطبيقات على جميع التطبيقات المُثبَّتة ما لم يتم حظرها على النحو الموضّح في الفقرة 3.5.1.
- [C-0-10] يجب عدم تنفيذ نهج القائمة المسموح بها الذي يضمن التوافق السلوكي لواجهة برمجة التطبيقات فقط للتطبيقات التي يختارها مطوّرو الأجهزة.
يجب أن تكون سلوكيات كل نوع من أنواع واجهات برمجة التطبيقات (المُدارة واللينة والبرامج الأصلية والويب) متسقة مع التنفيذ المفضّل لإصدار الإصدارات السابقة لمشروع Android Open Source Project. في ما يلي بعض مجالات التوافق المحدّدة:
- [C-0-1] يجب ألا تغيّر الأجهزة سلوك نية عادية أو دلالة ذلك السلوك.
- [C-0-2] يجب ألا تغيّر الأجهزة دورة الحياة أو دلالات دورة الحياة لنوع معيّن من مكوّنات النظام (مثل الخدمة أو النشاط أو ContentProvider أو غير ذلك).
- [C-0-3] يجب ألا تغيّر الأجهزة معنى الإذن العادي.
- يجب ألا تغيّر الأجهزة القيود المفروضة على التطبيقات التي تعمل في الخلفية.
وعلى وجه التحديد، بالنسبة إلى التطبيقات التي تعمل في الخلفية:
- [C-0-4] يجب إيقاف تنفيذ عمليات الاستدعاء التي سجّلها تطبيق
لتلقّي النتائج من
GnssMeasurement
وGnssNavigationMessage
. - [C-0-5] يجب أن تحدّ من معدّل تكرار التحديثات التي يتم
إرسالها إلى التطبيق من خلال فئة واجهة برمجة التطبيقات
LocationManager
أو الطريقةWifiManager.startScan()
. - [C-0-6] إذا كان التطبيق يستهدف المستوى 25 من واجهة برمجة التطبيقات أو إصدارًا أحدث، يجب ألّا
يسمح بتسجيل أدوات استقبال البث للبث الضمني لهدف
Android العادي في ملف بيان التطبيق، ما لم يكن هدف البث
يتطلّب إذن
"signature"
أو"signatureOrSystem"
protectionLevel
أو كان مُدرَجًا في قائمة الاستثناءات. - [C-0-7] إذا كان التطبيق يستهدف المستوى 25 أو أعلى من واجهة برمجة التطبيقات، يجب أن يوقف
خدمات التطبيق التي تعمل في الخلفية، تمامًا كما لو كان التطبيق قد استدعى
stopSelf()
خدمات، ما لم يتم وضع التطبيق في قائمة مسموح بها مؤقتة لمعالجة مهمة تظهر للمستخدم. - [C-0-8] إذا كان التطبيق يستهدف المستوى 25 أو أعلى لواجهة برمجة التطبيقات، يجب إزالة عمليات قفل التنشيط التي يحتفظ بها التطبيق.
- [C-0-4] يجب إيقاف تنفيذ عمليات الاستدعاء التي سجّلها تطبيق
لتلقّي النتائج من
- [C-0-11] يجب أن تعرض الأجهزة مقدّمي خدمات الأمان التاليين كأول
قيم سبعة صفائف من الأسلوب
Security.getProviders()
، بالترتيب المحدّد وبالأسماء المحدّدة (كما تعرضهاProvider.getName()
) والفئات، ما لم يُعدِّل التطبيق القائمة من خلالinsertProviderAt()
أوremoveProvider()
. قد تعرِض الأجهزة مزوّدين إضافيين بعد قائمة المزوّدين المحدّدة أدناه.- AndroidNSSP -
android.security.net.config.NetworkSecurityConfigProvider
- AndroidOpenSSL -
com.android.org.conscrypt.OpenSSLProvider
- CertPathProvider -
sun.security.provider.CertPathProvider
- AndroidKeyStoreBCWorkaround -
android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
- BC -
com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
- HarmonyJSSE -
com.android.org.conscrypt.JSSEProvider
- AndroidKeyStore -
android.security.keystore.AndroidKeyStoreProvider
- AndroidNSSP -
يُرجى العِلم أنّ القائمة أعلاه ليست شاملة. تختبر مجموعة أدوات اختبار التوافق (CTS) أجزاءً كبيرة من المنصة للتحقّق من التوافق السلوكي، ولكن ليس كلها. تقع على عاتق المنفِّذ مسؤولية ضمان التوافق السلوكي مع "مشروع Android المفتوح المصدر". لهذا السبب، على مطوّري الأجهزة استخدام الرمز المصدر المتاح من خلال "المشروع المفتوح المصدر لنظام Android" كلما أمكن، بدلاً من إعادة تنفيذ أجزاء مهمة من النظام.
3.5.1. قيود التطبيق
إذا كانت عمليات تنفيذ الأجهزة تطبّق آلية خاصة بها لتقييد التطبيقات وكانت هذه الآلية أكثر تقييدًا من مجموعة التطبيقات المحظورة في وضع الاستعداد، يجب:
- [C-1-1] يجب توفير ميزات لاستخدام المستخدمين تتيح لهم الاطّلاع على قائمة التطبيقات المحظورة.
- [C-1-2] يجب أن يقدّم التطبيق للمستخدم إمكانية تفعيل القيود أو إيقافها في كل تطبيق.
- [C-1-3] يجب عدم تطبيق القيود تلقائيًا بدون دليل على سوء سلوك حالة النظام، ولكن يجوز تطبيق القيود على التطبيقات عند رصد سوء سلوك حالة النظام، مثل عمليات قفل التنشيط المتوقفة والخدمات التي تعمل لفترة طويلة وغيرها من المعايير. يمكن أن يحدّد خبراء تنفيذ الأجهزة المعايير، ولكن يجب أن تكون مرتبطة أثر التطبيق في صحة النظام. يجب عدم استخدام معايير أخرى غير مرتبطة بصحة النظام فقط، مثل عدم رواج التطبيق في السوق.
- [C-1-4] يجب عدم تطبيق قيود التطبيقات تلقائيًا على التطبيقات عندما يوقف أحد المستخدمين قيود التطبيقات يدويًا، ويمكن أن يقترح على المستخدم تطبيق قيود التطبيقات.
- [C-1-5] يجب إبلاغ المستخدمين إذا تم تطبيق قيود التطبيق على تطبيق تلقائيًا. يجب تقديم هذه المعلومات في غضون 24 ساعة من تطبيق القيود.
- [C-1-6] يجب عرض القيمة
true
للعنصرActivityManager.isBackgroundRestricted()
عندما يستدعي التطبيق المحظور واجهة برمجة التطبيقات هذه. - [C-1-7] يجب عدم حظر التطبيق الأهم في المقدّمة والذي يستخدمه المستخدم صراحةً.
- [C-1-8] يجب تعليق القيود المفروضة على التطبيق الذي يصبح التطبيق الأهم في المقدّمة عندما يبدأ المستخدم استخدام التطبيق الذي كان محدودًا بشكل صريح.
- [C-1-10] يجب عدم السماح بوضع التطبيق تلقائيًا في حزمة التطبيقات المحظورة في غضون ساعتَين من آخر استخدام للمستخدِم.
إذا كانت عمليات تنفيذ الأجهزة تُوسّع نطاق قيود التطبيقات التي يتم تنفيذها في AOSP، يجب أن تستوفي ما يلي:
- [C-2-1] يجب اتّباع عملية التنفيذ الموضّحة في هذا المستند.
3.5.2. إسبات التطبيق
إذا كانت عمليات تنفيذ التطبيق تتضمّن ميزة "وضع السكون للتطبيقات" المضمّنة في AOSP أو تُوسّع نطاق الميزة المضمّنة في AOSP، يجب استيفاء الشروط التالية:
- يجب أن يستوفي [C-1-1] جميع المتطلبات الواردة في القسم 3.5.1 باستثناء [C-1-6] و[C-1-3].
- [C-1-2] يجب عدم تطبيق القيود على التطبيق إلا إذا توفّر دليل على أنّ المستخدم لم يستخدم التطبيق لفترة زمنية معيّنة. ننصح بشدة بأن تكون هذه المدة شهرًا واحدًا أو أكثر. يجب تحديد الاستخدام إما من خلال تفاعل المستخدم الصريح عبر واجهة برمجة التطبيقات UsageStats#getLastTimeVisible() أو أي إجراء قد يتسبب في خروج التطبيق من حالة الإيقاف القسري، بما في ذلك عمليات ربط الخدمات وعمليات ربط موفّري المحتوى وعمليات البث الصريحة وما إلى ذلك، وسيتم تتبُّعها من خلال واجهة برمجة التطبيقات الجديدة UsageStats#getLastTimeAnyComponentUsed().
- [C-1-3] يجب عدم تطبيق القيود التي تؤثر في جميع مستخدمي الجهاز إلا عند توفُّر دليل على عدم استخدام أي مستخدم للحزمة لفترة معيّنة من الزمن. ننصحك بشدة بأن تكون هذه المدة شهرًا واحدًا أو أكثر.
- [C-1-4] يجب ألّا تؤدي إلى منع التطبيق من الاستجابة لطلبات النشاط أو عمليات ربط الخدمات أو طلبات مقدّمي المحتوى أو عمليات البث الصريحة.
تستوفي ميزة "وضع السكون للتطبيقات" في AOSP المتطلبات المذكورة أعلاه.
3.6. مساحات أسماء واجهة برمجة التطبيقات
يتّبع نظام التشغيل Android اصطلاحات مساحة اسم الحزمة والفئة التي تحدّدها لغة برمجة Java. لضمان التوافق مع التطبيقات التابعة لجهات خارجية، يجب ألا يُجري مورّدو الأجهزة أي تعديلات محظورة (راجِع المعلومات أدناه) على مساحات أسماء الحِزم التالية:
java.*
javax.*
sun.*
android.*
androidx.*
com.android.*
وهذا يعني أنّها:
- [C-0-1] يجب عدم تعديل واجهات برمجة التطبيقات المتاحة للجميع على نظام Android عن طريق تغيير أي توقيعات طُرق أو فئات، أو عن طريق إزالة فئات أو حقول فئات.
- [C-0-2] يجب عدم إضافة أي عناصر متاحة للجميع (مثل الفصول الدراسية أو واجهة برمجة التطبيقات أو الحقول أو الطرق إلى الفصول الدراسية أو واجهات برمجة التطبيقات الحالية) أو واجهات برمجة تطبيقات اختبار أو النظام إلى واجهات برمجة التطبيقات في مساحات الأسماء أعلاه. "العنصر المعروض علنيًا" هو أيّ عنصر لم يتم تزيينه بالعلامة "@hide" كما هو مستخدَم في رمز المصدر الأصلي لنظام التشغيل Android.
يجوز لمطوّري الأجهزة تعديل التنفيذ الأساسي لواجهات برمجة التطبيقات، ولكن: يجب مراعاة ما يلي عند إجراء هذه التعديلات:
- [C-0-3] يجب ألا يؤثر في السلوك المذكور وتوقيع لغة Java ل أي واجهات برمجة تطبيقات متاحة للجميع.
- [C-0-4] يجب عدم الإعلان عن هذه التطبيقات أو عرضها على المطوّرين بأي شكل من الأشكال.
ومع ذلك، يجوز لمطوّري الأجهزة إضافة واجهات برمجة تطبيقات مخصّصة خارج مساحة اسم Android المعيارية، ولكن يجب استيفاء الشروط التالية في واجهات برمجة التطبيقات المخصّصة:
- [C-0-5] يجب ألّا يكون في مساحة اسم تملكها مؤسسة أخرى أو تشير إليها. على سبيل المثال، يجب ألّا يضيف مورّدو الأجهزة واجهات برمجة تطبيقات إلى مساحة الاسم
com.google.*
أو مساحة اسم مشابهة، بل يمكن لشركة Google فقط إجراء ذلك. وبالمثل، يجب ألّا تضيف Google واجهات برمجة تطبيقات إلى مساحات أسماء الشركات الأخرى. - [C-0-6] يجب تجميعها في مكتبة مشترَكة لنظام التشغيل Android لكي تتأثّر فقط التطبيقات التي تستخدمها صراحةً (من خلال آلية <uses-library>) بزيادة استخدام الذاكرة لهذه واجهات برمجة التطبيقات.
يجوز لمطوّري الأجهزة إضافة واجهات برمجة تطبيقات مخصّصة باللغات الأصلية، خارج واجهات برمجة تطبيقات NDK، ولكن يجب استيفاء الشروط التالية في واجهات برمجة التطبيقات المخصّصة:
- [C-1-1] يجب ألّا تكون في مكتبة NDK أو مكتبة مملوكة لمؤسسة أخرى كما هو موضّح هنا.
إذا اقترح مطوّر الأجهزة تحسين إحدى مساحات أسماء الحِزم المذكورة أعلاه (مثلاً، عن طريق إضافة وظيفة جديدة مفيدة إلى واجهة برمجة تطبيقات حالية أو إضافة واجهة برمجة تطبيقات جديدة)، على المطوّر الانتقال إلى source.android.com وبدء عملية المساهمة بالتغييرات و الرمز البرمجي، وفقًا للمعلومات الواردة في هذا الموقع الإلكتروني.
يُرجى العِلم أنّ القيود الواردة أعلاه تتوافق مع الاتفاقيات العادية لتسمية واجهة برمجة التطبيقات في لغة Java البرمجية، ويهدف هذا القسم ببساطة إلى تعزيز هذه الاتفاقيات وجعلها ملزمة من خلال تضمينها في تعريف التوافق هذا.
3.7 التوافق مع بيئة التشغيل
عمليات التنفيذ على الأجهزة:
[C-0-1] يجب أن يكون متوافقًا مع تنسيق Dalvik Executable (DEX) الكامل ومواصفات ودلالات رمز Dalvik البرمجي.
[C-0-2] يجب ضبط أوقات تشغيل Dalvik لتخصيص الذاكرة وفقًا لنظام Android الأساسي، وكما هو محدّد في الجدول التالي. (اطّلِع على الفقرة 7.1.1 للاطّلاع على تعريفات حجم الشاشة وكثافة الشاشة).
يجب استخدام Android RunTime (ART)، وهو التنفيذ المرجعي لتنسيق Dalvik القابل للتنفيذ، ونظام إدارة الحِزم المرجعي للتنفيذ.
يجب إجراء اختبارات التداخل في أوضاع تنفيذ مختلفة والتصاميم المستهدفة لضمان ثبات وقت التشغيل. راجِع JFuzz وDexFuzz على الموقع الإلكتروني لمشروع Android Open Source Project.
يُرجى العِلم أنّ قيم الذاكرة المحدّدة أدناه تُعدّ الحدّ الأدنى للقيم، وقد تخصص عمليات تنفيذ الأجهزة مزيدًا من الذاكرة لكل تطبيق.
تنسيق الشاشة | كثافة الشاشة | الحد الأدنى لذاكرة التطبيق |
---|---|---|
ساعة Android | 120 نقطة لكل بوصة (ldpi) | 32 ميغابايت |
140 نقطة لكل بوصة (140dpi) | ||
160 نقطة لكل بوصة (mdpi) | ||
180 نقطة في البوصة (180dpi) | ||
200 نقطة لكل بوصة (200dpi) | ||
213 نقطة لكل بوصة (tvdpi) | ||
220 نقطة لكل بوصة (220dpi) | 36 ميغابايت | |
240 نقطة لكل بوصة (دقة عالية) | ||
280 نقطة لكل بوصة (280dpi) | ||
320 نقطة لكل بوصة (xhdpi) | 48 ميغابايت | |
360 نقطة في البوصة (360dpi) | ||
400 نقطة لكل بوصة (400dpi) | 56 ميغابايت | |
420 نقطة لكل بوصة (420dpi) | 64 ميغابايت | |
480 نقطة لكل بوصة (xxhdpi) | 88 ميغابايت | |
560 نقطة في البوصة (560dpi) | 112 ميغابايت | |
640 نقطة لكل بوصة (xxxhdpi) | 154 ميغابايت | |
صغير/عادي | 120 نقطة لكل بوصة (ldpi) | 32 ميغابايت |
140 نقطة لكل بوصة (140dpi) | ||
160 نقطة لكل بوصة (mdpi) | ||
180 نقطة في البوصة (180dpi) | 48 ميغابايت | |
200 نقطة لكل بوصة (200dpi) | ||
213 نقطة لكل بوصة (tvdpi) | ||
220 نقطة لكل بوصة (220dpi) | ||
240 نقطة لكل بوصة (دقة عالية) | ||
280 نقطة لكل بوصة (280dpi) | ||
320 نقطة لكل بوصة (xhdpi) | 80 ميغابايت | |
360 نقطة في البوصة (360dpi) | ||
400 نقطة لكل بوصة (400dpi) | 96 ميغابايت | |
420 نقطة لكل بوصة (420dpi) | 112 ميغابايت | |
480 نقطة لكل بوصة (xxhdpi) | 128 ميغابايت | |
560 نقطة في البوصة (560dpi) | 192 ميغابايت | |
640 نقطة لكل بوصة (xxxhdpi) | 256 ميغابايت | |
كبير | 120 نقطة لكل بوصة (ldpi) | 32 ميغابايت |
140 نقطة لكل بوصة (140dpi) | 48 ميغابايت | |
160 نقطة لكل بوصة (mdpi) | ||
180 نقطة في البوصة (180dpi) | 80 ميغابايت | |
200 نقطة لكل بوصة (200dpi) | ||
213 نقطة لكل بوصة (tvdpi) | ||
220 نقطة لكل بوصة (220dpi) | ||
240 نقطة لكل بوصة (دقة عالية) | ||
280 نقطة لكل بوصة (280dpi) | 96 ميغابايت | |
320 نقطة لكل بوصة (xhdpi) | 128 ميغابايت | |
360 نقطة في البوصة (360dpi) | 160 ميغابايت | |
400 نقطة لكل بوصة (400dpi) | 192 ميغابايت | |
420 نقطة لكل بوصة (420dpi) | 228 ميغابايت | |
480 نقطة لكل بوصة (xxhdpi) | 256 ميغابايت | |
560 نقطة في البوصة (560dpi) | 384 ميغابايت | |
640 نقطة لكل بوصة (xxxhdpi) | 512 ميغابايت | |
كبير جدًا | 120 نقطة لكل بوصة (ldpi) | 48 ميغابايت |
140 نقطة لكل بوصة (140dpi) | 80 ميغابايت | |
160 نقطة لكل بوصة (mdpi) | ||
180 نقطة في البوصة (180dpi) | 96 ميغابايت | |
200 نقطة لكل بوصة (200dpi) | ||
213 نقطة لكل بوصة (tvdpi) | ||
220 نقطة لكل بوصة (220dpi) | ||
240 نقطة لكل بوصة (دقة عالية) | ||
280 نقطة لكل بوصة (280dpi) | 144 ميغابايت | |
320 نقطة لكل بوصة (xhdpi) | 192 ميغابايت | |
360 نقطة في البوصة (360dpi) | 240 ميغابايت | |
400 نقطة لكل بوصة (400dpi) | 288 ميغابايت | |
420 نقطة لكل بوصة (420dpi) | 336 ميغابايت | |
480 نقطة لكل بوصة (xxhdpi) | 384 ميغابايت | |
560 نقطة في البوصة (560dpi) | 576 ميغابايت | |
640 نقطة لكل بوصة (xxxhdpi) | 768 ميغابايت |
3.8. توافق واجهة المستخدم
3.8.1. مشغّل التطبيقات (الشاشة الرئيسية)
يتضمّن نظام التشغيل Android تطبيق مشغّل (الشاشة الرئيسية) وإمكانية استخدام تطبيقات تابعة لجهات خارجية لتحل محل مشغّل الجهاز (الشاشة الرئيسية).
إذا كانت عمليات تنفيذ الأجهزة تسمح للتطبيقات التابعة لجهات خارجية باستبدال الشاشة الرئيسية للجهاز، يجب أن تستوفي التطبيقات المتطلبات التالية:
- [C-1-1] يجب الإفصاح عن ميزة المنصة
android.software.home_screen
. - [C-1-2] يجب عرض العنصر
AdaptiveIconDrawable
عندما يستخدم التطبيق التابع لجهة خارجية علامة<adaptive-icon>
لعرض رمزه، ويتم استدعاء طرقPackageManager
لاسترداد الرموز.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن مشغّل تطبيقات تلقائيًا يتيح تثبيت الاختصارات داخل التطبيق، يجب أن تستوفي المتطلبات التالية:
- [C-2-1] يجب الإبلاغ عن
true
لأجلShortcutManager.isRequestPinShortcutSupported()
. - [C-2-2] يجب أن تتضمّن واجهة المستخدم طلبًا من المستخدم قبل إضافة اختصار تطلبه التطبيقات عبر
ShortcutManager.requestPinShortcut()
طريقة واجهة برمجة التطبيقات. - [C-2-3] يجب أن يتيح التطبيق استخدام الاختصارات المثبَّتة والاختصارات الديناميكية والثابتة كما هو موضّح في صفحة "اختصارات التطبيقات".
في المقابل، إذا كانت عمليات تنفيذ الأجهزة لا تتيح تثبيت الاختصارات داخل التطبيق، يتم تنفيذ ما يلي:
- [C-3-1] يجب الإبلاغ عن
false
لأجلShortcutManager.isRequestPinShortcutSupported()
.
إذا كانت عمليات تنفيذ الأجهزة تستخدم مشغّل تطبيقات تلقائيًا يوفر إمكانية الوصول السريع إلى الاختصارات الإضافية التي تقدّمها التطبيقات التابعة لجهات خارجية من خلال واجهة برمجة التطبيقات ShortcutManager، يجب أن تستوفي المتطلبات التالية:
- [C-4-1] يجب أن توفّر جميع ميزات الاختصارات الموثَّقة (مثل الاختصارات الثابتة
والاختصارات الديناميكية، وتثبيت الاختصارات) وأن تنفِّذ بالكامل واجهات برمجة التطبيقات الخاصة بفئة
ShortcutManager
API.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن تطبيق مشغّل تلقائيًا يعرض شارات لرموز التطبيقات، يجب أن تستوفي التطبيقات المتثبّتة على الجهاز الشروط التالية:
- [C-5-1] يجب أن تتوافق مع طريقة واجهة برمجة التطبيقات
NotificationChannel.setShowBadge()
. بعبارة أخرى، يجب عرض ميزة مرئية مرتبطة برمز التطبيق إذا تم ضبط القيمة علىtrue
، وعدم عرض أي مخطط لشارة رمز التطبيق عندما يتم ضبط القيمة علىfalse
في كل قنوات الإشعارات للتطبيق. - يجوز للتطبيقات إلغاء شارات رمز التطبيق باستخدام مخطّط الشارة الخاص بها عندما تشير التطبيقات التابعة لجهات خارجية إلى توافقها مع مخطّط الشارة الخاص بها
من خلال استخدام واجهات برمجة التطبيقات الخاصة، ولكن يجب استخدام الموارد والقيم
المقدَّمة من خلال واجهات برمجة تطبيقات شارات الإشعارات الموضّحة في حزمة تطوير البرامج (SDK)،
مثل واجهتَي برمجة التطبيقات
Notification.Builder.setNumber()
وNotification.Builder.setBadgeIconType()
.
3.8.2. التطبيقات المصغَّرة
يتيح نظام التشغيل Android تطبيقات المصغّرات التابعة لجهات خارجية من خلال تحديد نوع المكوّن و واجهة برمجة التطبيقات ودورة الحياة المقابلة التي تسمح للتطبيقات بعرض "AppWidget" للمستخدم النهائي.
إذا كانت عمليات تنفيذ الأجهزة تتيح استخدام التطبيقات المصغّرة التابعة لجهات خارجية، يجب أن تستوفي التطبيقات المصغّرة المتطلبات التالية:
- [C-1-1] يجب الإفصاح عن توافق التطبيق مع ميزة المنصة
android.software.app_widgets
. - [C-1-2] يجب أن يتضمّن التطبيق ميزات مدمجة لاستخدام التطبيقات المصغّرة وتوفير عناصر واجهة مستخدِم لإضافة التطبيقات المصغّرة وضبطها وعرضها وإزالتها مباشرةً من خلال مشغّل التطبيقات.
- [C-1-3] يجب أن يكون التطبيق قادرًا على عرض التطبيقات المصغّرة التي تبلغ مساحتها 4 × 4 بحجم الشبكة العادي. اطّلِع على إرشادات تصميم التطبيقات المصغّرة في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android للاطّلاع على التفاصيل.
- قد تتيح التطبيقات المصغّرة على شاشة القفل.
إذا كانت عمليات تنفيذ الأجهزة تتيح استخدام التطبيقات المصغّرة التابعة لجهات خارجية وتثبيت الاختصارات داخل التطبيقات، يجب أن تستوفي المتطلبات التالية:
- [C-2-1] يجب الإبلاغ عن
true
لأجلAppWidgetManager.html.isRequestPinAppWidgetSupported()
. - [C-2-2] يجب أن تتضمّن واجهة المستخدم طلبًا من المستخدم قبل إضافة اختصار تطلبه التطبيقات عبر
AppWidgetManager.requestPinAppWidget()
طريقة واجهة برمجة التطبيقات.
3.8.3. الإشعارات
يتضمّن نظام التشغيل Android واجهات برمجة التطبيقات Notification
و
NotificationManager
التي تسمح لمطوّري التطبيقات التابعين لجهات خارجية بإرسال إشعارات إلى المستخدمين بشأن الأحداث البارزة
وجذب انتباههم باستخدام مكوّنات الأجهزة (مثل الصوت والاهتزاز
والضوء) وميزات البرامج (مثل مربّع الإشعارات وشريط النظام) في
الجهاز.
3.8.3.1. عرض الإشعارات
إذا كانت عمليات تنفيذ الأجهزة تسمح للتطبيقات التابعة لجهات خارجية بإرسال إشعارات إلى المستخدمين بشأن الأحداث البارزة، يجب أن تستوفي التطبيقات المتطلبات التالية:
- [C-1-1] يجب أن تتيح الإشعارات التي تستخدم ميزات الأجهزة، كما هو موضّح في مستندات حزمة SDK، وبقدر الإمكان مع تنفيذ الجهاز الأجهزة. على سبيل المثال، إذا كان تنفيذ الجهاز يتضمّن أداة اهتزاز، يجب تنفيذ واجهات برمجة التطبيقات الخاصة بالاهتزاز بشكل صحيح. إذا كان تنفيذ الجهاز لا يتضمّن معدات، يجب تنفيذ واجهات برمجة التطبيقات المقابلة كعمليات لا تؤدي إلى أيّ إجراء. يمكنك الاطّلاع على مزيد من التفاصيل حول هذا السلوك في الفقرة 7.
- [C-1-2] يجب عرض جميع الموارد (الرموز وملفات الصور المتحركة وما إلى ذلك) بشكل صحيح في واجهات برمجة التطبيقات أو في دليل نمط الرموز الخاص بملف الحالة/شريط النظام، على الرغم من أنّه يجوز أن يوفّر تجربة بديلة للمستخدمين بشأن الإشعارات مقارنةً بتلك التي يوفّرها تطبيق Android Open Source المرجعي.
- [C-1-3] يجب الالتزام بالسلوكيات الموضّحة في واجهات برمجة التطبيقات وتنفيذها بشكل صحيح لتعديل الإشعارات وإزالتها وتجميعها.
- [C-1-4] يجب تقديم السلوك الكامل لواجهة برمجة تطبيقات NotificationChannel الموثَّقة في حزمة SDK.
- [C-1-5] يجب أن يقدّم التطبيق ميزة تتيح للمستخدم حظر إشعار معيّن من تطبيق تابع لجهة خارجية وتعديله على مستوى كل قناة وحزمة تطبيق.
- [C-1-6] يجب أيضًا توفير ميزة للمستخدم لعرض قنوات الإشعارات التي تم حذفها.
- [C-1-7] يجب عرض جميع الموارد (الصور والملصقات والرموز وغيرها) بشكل صحيح من خلال Notification.MessagingStyle بجانب نص الإشعار بدون تفاعل إضافي من المستخدم. على سبيل المثال، يجب أن تعرض جميع الموارد، بما في ذلك الرموز المقدَّمة من خلال android.app.Person في محادثة جماعية يتم إعدادها من خلال setGroupConversation.
- [C-SR-1] يُنصح بشدة بعرض ميزة تلقائية للمستخدمين لحظر إشعار تطبيق تابع لجهة خارجية معيّن على مستوى كل قناة وملف برمجي للتطبيق بعد أن يرفض المستخدم هذا الإشعار عدة مرات.
- [C-SR-2] يُنصح بشدة بتوفير ميزة للمستخدم للتحكّم في الإشعارات التي يتم عرضها للتطبيقات التي تم منحها إذن "مستمع الإشعارات". يجب أن تكون الدقة بحيث يمكن للمستخدم التحكّم في كل مستمع إشعارات من هذا النوع في أنواع الإشعارات التي يتم ربطها بهذا المستمع. يجب أن تتضمّن الأنواع إشعارات "المحادثات" و"الإشعارات المنبّهة" و"الإشعارات الصامتة" و "الإشعارات الجارية المهمة" .
- [C-SR-3] يُنصح بشدة بتوفير ميزة للمستخدمين لتحديد التطبيقات التي سيتم استبعادها من إرسال إشعارات إلى أي مستمع إشعارات محدّد.
- يجب أن تتيح إرسال إشعارات غنية.
- يجب عرض بعض الإشعارات ذات الأولوية الأعلى كإشعارات تنبيه.
- يجب أن يتضمّن عنصرًا يتيح للمستخدم تأجيل الإشعارات.
- يمكن أن تدير فقط مستوى ظهور التطبيقات التابعة لجهات خارجية وتوقيت إرسالها إشعارات للمستخدمين بشأن الأحداث البارزة للحدّ من مشاكل السلامة، مثل تشتيت انتباه السائق.
يقدّم الإصدار 11 من Android ميزة إشعارات المحادثات، وهي إشعارات تستخدِم MessagingStyle وتوفّر معرّف اختصار الأشخاص منشورًا.
عمليات التنفيذ على الأجهزة:
- [C-SR-4] يُنصح بشدة بتجميع إشعارات
conversation notifications
وعرضها قبل الإشعارات غير المتعلّقة بالمحادثات، باستثناء إشعارات الخدمات التي تعمل في المقدّمة وإشعاراتimportance:high
.
إذا كانت عمليات تنفيذ الأجهزة متوافقة مع conversation notifications
وقدّم التطبيق البيانات المطلوبة ل
bubbles
، يتم تنفيذ ما يلي:
- [C-SR-5] يُنصح بشدة بعرض هذه المحادثة كفقاعة محادثة. يستوفي تطبيق AOSP هذه المتطلبات من خلال واجهة المستخدم التلقائية للنظام والإعدادات وقاذفة التطبيقات.
إذا كانت عمليات تنفيذ الأجهزة تتيح الإشعارات الغنية، يتم تنفيذ ما يلي:
- [C-2-1] يجب استخدام الموارد بالضبط كما هو موضح
من خلال فئة واجهة برمجة التطبيقات
Notification.Style
وفئاتها الفرعية لعناصر الموارد المعروضة. - يجب أن تعرِض كل عنصر من عناصر المورد (مثل
الرمز والعنوان والنص التلخيصي) المحدّد في فئة
Notification.Style
واجهة برمجة التطبيقات وفئاتها الفرعية.
إذا كانت عمليات تنفيذ الأجهزة تتيح إشعارات التنبيهات الفورية:
- [C-3-1] يجب استخدام عرض الإشعارات المنبثقة والموارد
كما هو موضّح في فئة واجهة برمجة التطبيقات
Notification.Builder
عند عرض الإشعارات المنبثقة. - [C-3-2] يجب عرض الإجراءات المقدَّمة من خلال
Notification.Builder.addAction()
بالإضافة إلى محتوى الإشعار بدون تفاعل إضافي من المستخدم كما هو موضّح في حزمة تطوير البرامج (SDK).
3.8.3.2. خدمة تلقّي الإشعارات الصوتية
يتضمّن Android NotificationListenerService
واجهات برمجة تطبيقات تسمح للتطبيقات (بعد أن يفعّلها المستخدم صراحةً) بتلقّي نسخة من
جميع الإشعارات عند نشرها أو تعديلها.
عمليات التنفيذ على الأجهزة:
- [C-0-1] يجب تعديل الإشعارات بالكامل بشكل صحيح وسريع لجميع خدمات الاستماع المثبَّتة والمفعَّلة من قِبل المستخدم، بما في ذلك أي وجميع البيانات الوصفية المرفقة بعنصر الإشعار.
- [C-0-2] يجب أن تتوافق مع استدعاء واجهة برمجة التطبيقات
snoozeNotification()
وإغلاق الإشعار وإجراء مكالمة لاحقة بعد انقضاء مدّة التأخير التي تم ضبطها في استدعاء واجهة برمجة التطبيقات.
إذا كانت عمليات تنفيذ الأجهزة تتيح للمستخدم تأجيل الإشعارات، يجب أن:
- [C-1-1] يجب أن تعكس حالة الإشعار المؤجَّل بشكل صحيح
من خلال واجهات برمجة التطبيقات العادية، مثل
NotificationListenerService.getSnoozedNotifications()
. - [C-1-2] يجب أن يتيح هذا الخيار للمستخدم إيقاف الإشعارات مؤقتًا من كل تطبيق تابع لجهة خارجية مثبَّت، ما لم تكن من خدمات مستمرّة/تعمل في المقدّمة.
3.8.3.3. عدم الإزعاج
إذا كانت عمليات تنفيذ الأجهزة تتيح ميزة "عدم الإزعاج"، فإنّها:
- [C-1-1] يجب أن يعرض الجهاز قواعد الوضع "عدم الإزعاج" التلقائية التي أنشأتها التطبيقات إلى جانب القواعد التي أنشأها المستخدم وتلك المحدَّدة مسبقًا، وذلك عندما يقدّم تنفيذ الجهاز وسيلة للمستخدم لمنح التطبيقات التابعة لجهات خارجية الإذن بالوصول إلى إعدادات سياسة "عدم الإزعاج" أو منعها من ذلك.
- [C-1-3] يجب أن تلتزم بالقيم
suppressedVisualEffects
التي تم تمريرها على طولNotificationManager.Policy
وإذا ضبط أحد التطبيقات أيًا من علامتَي SUPPRESSED_EFFECT_SCREEN_OFF أو SUPPRESSED_EFFECT_SCREEN_ON، يجب أن يشير إلى المستخدم إلى أنّه تم إيقاف التأثيرات المرئية في قائمة إعدادات "وضع عدم الإزعاج".
3.8.4. واجهات برمجة تطبيقات Assist
يتضمّن Android Assist APIs للسماح للتطبيقات باختيار مقدار المعلومات التي يتم مشاركتها مع "مساعد Google" على الجهاز.
إذا كانت عمليات تنفيذ الأجهزة تتيح إجراء "المساعدة"، فإنّها:
- [C-2-1] يجب أن يشير التطبيق بوضوح إلى المستخدم النهائي عند مشاركة السياق، وذلك من خلال:
إما:
- في كل مرة يصل فيها التطبيق المساعد إلى السياق، يتم عرض ضوء أبيض حول حواف الشاشة يستوفي مدة تنفيذ "مشروع Android المفتوح المصدر" ومقدار سطوعه أو يتجاوزهما.
- بالنسبة إلى تطبيق المساعدة المثبَّت مسبقًا، يجب توفير ميزة للمستخدم لا تبعد عن قائمة إعدادات تطبيق المساعدة وميزة الإدخال الصوتي التلقائية سوى تنقّلَين، وعدم مشاركة السياق إلا عندما يشغِّل المستخدم تطبيق المساعدة صراحةً من خلال كلمة تشغيل أو إدخال مفتاح تنقّل في تطبيق المساعدة.
- [C-2-2] يجب أن يؤدي التفاعل المحدّد لبدء تطبيق المساعدة كما هو موضّح في الفقرة 7.2.3 إلى بدء تطبيق المساعدة الذي يختاره المستخدم، أي التطبيق الذي ينفّذ
VoiceInteractionService
، أو نشاط يعالج النيةACTION_ASSIST
.
3.8.5. التنبيهات والرسائل المنبثقة
يمكن للتطبيقات استخدام واجهة برمجة التطبيقات Toast
لعرض سلاسل قصيرة غير مشروطة للمستخدم النهائي والتي تختفي بعد
فترة زمنية قصيرة، واستخدام واجهة برمجة التطبيقات TYPE_APPLICATION_OVERLAY
لنوع النافذة لعرض نوافذ تنبيه كعنصر تراكبي فوق التطبيقات الأخرى.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن شاشة أو إخراج فيديو، يجب أن تستوفي الشروط التالية:
[C-1-1] يجب أن يوفّر التطبيق للمستخدم ميزة حظر عرض نوافذ تنبيه تستخدم الرمز
TYPE_APPLICATION_OVERLAY
. يستوفي تطبيق AOSP هذا الشرط من خلال توفير عناصر تحكّم في نافذة الإشعارات.[C-1-2] يجب الالتزام بواجهة برمجة التطبيقات Toast API وعرض إشعارات Toast من التطبيقات للمستخدمين النهائيين بطريقة واضحة للغاية.
3.8.6. المظاهر
يقدّم Android "المظاهر" كآلية للتطبيقات لتطبيق الأنماط على نشاط أو تطبيق كامل.
يتضمن Android مجموعة مظاهر "Holo" و"Material" كمجموعة من الأنماط المحددة التي يمكن لمطوِّري التطبيقات استخدامها إذا أرادوا مطابقة مظهر ومظهر Holo على النحو المحدّد في حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن شاشة أو إخراج فيديو، يجب أن تستوفي الشروط التالية:
- [C-1-1] يجب عدم تغيير أي من سمات مظهر Holo المعروضة للتطبيقات.
- [C-1-2] يجب أن تكون متوافقة مع عائلة المظاهر "المادية"، ويجب ألّا تغيّر أيًا من سمات المظهر المادي أو مواد العرض المعروضة للتطبيقات.
- [C-1-3] يجب ضبط عائلة الخطوط "sans-serif" على الإصدار 2.x من Roboto للغات التي يتوافق معها Roboto، أو توفير عنصر تحكم للمستخدم لتغيير الخط المستخدَم لعائلة الخطوط "sans-serif" إلى الإصدار 2.x من Roboto للغات التي يتوافق معها Roboto.
يتضمّن Android أيضًا مجموعة مظاهر "تلقائي على الجهاز" كمجموعة من الأنماط المحدّدة التي يمكن لمطوّري التطبيقات استخدامها إذا أرادوا مطابقة مظهر ومضمون مظهر الجهاز كما حدّده مُنفِّذ الجهاز.
- قد تعدِّل عمليات تنفيذ الأجهزة سمات المظهر التلقائي للجهاز المعروضة للتطبيقات.
يتيح نظام Android استخدام مظهر متغير مع أشرطة نظام شفافة، ما يسمح لمطوّري التطبيقات بملء المنطقة خلف شريط الحالة وشريط التنقّل بمحتوى تطبيقاتهم. لتوفير تجربة متّسقة للمطوّرين في هذا الإعداد، من المهم الحفاظ على نمط رمز شريط الحالة في عمليات التنفيذ المختلفة للأجهزة.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن شريط حالة النظام، يجب أن تستوفي الشروط التالية:
- [C-2-1] يجب استخدام اللون الأبيض لرمز حالة النظام (مثل قوة الإشارة و مستوى البطارية) والإشعارات الصادرة عن النظام، ما لم يكن الرمز يشير إلى حالة مشكلة أو يطلب أحد التطبيقات استخدام شريط حالة خفيف باستخدام العلامة WindowInsetsController#APPEARANCE_LIGHT_STATUS_BARS.
- [C-2-2] يجب أن تغيّر عمليات التنفيذ على أجهزة Android لون رموز حالة النظام إلى الأسود (للحصول على التفاصيل، يُرجى الرجوع إلى R.style) عندما يطلب أحد التطبيقات استخدام شريط حالة فاتح.
3.8.7. خلفيات متحركة
يحدِّد Android نوع المكوّن وواجهة برمجة التطبيقات ودورة الحياة المقابلة التي تسمح للتطبيقات بعرض واحد أو أكثر من "الخلفيات المتحركة" للمستخدم النهائي. الخلفيات المتحركة هي صور متحركة أو أنماط أو صور مشابهة تتضمّن إمكانات إدخال محدودة ويتم عرضها كخلفية، خلف التطبيقات الأخرى.
يُعتبر الجهاز قادرًا على تشغيل الخلفيات المتحركة بشكل موثوق إذا كان بإمكانه تشغيل جميع الخلفيات المتحركة بدون أي قيود على الوظائف وبمعدل عرض مقبولاً للصور بدون أي تأثيرات سلبية على التطبيقات الأخرى. إذا كانت القيود المفروضة على الأجهزة تؤدي إلى تعطُّل الخلفيات و/أو التطبيقات أو حدوث خلل فيها أو استهلاك موارد مفرطة لوحدة المعالجة المركزية أو البطارية أو تشغيلها بمعدّلات عرض إطارات منخفضة بشكل غير مقبول، يعني ذلك أنّه لا يمكن تشغيل الخلفية الحية على الجهاز. على سبيل المثال، قد تستخدم بعض خلفيات الصور المتحركة سياق OpenGL 2.0 أو 3.x لعرض محتواها. لن تعمل الخلفية الحية بشكل موثوق على الأجهزة التي لا تتوافق مع سياقات OpenGL المتعدّدة، لأنّ استخدام الخلفية الحية لسياق OpenGL قد يتعارض مع التطبيقات الأخرى التي تستخدم أيضًا سياق OpenGL.
- يجب أن تتضمّن عمليات تنفيذ الأجهزة التي يمكنها تشغيل الخلفيات المتحركة بشكل موثوق كما هو موضّح أعلاه خلفيات متحركة.
إذا كانت عمليات تنفيذ الأجهزة توفّر خلفيات متحركة، يجب أن تستوفي الشروط التالية:
- [C-1-1] يجب الإبلاغ عن علامة ميزة النظام الأساسي android.software.live_wallpaper.
3.8.8. التبديل بين الأنشطة
يتضمّن رمز المصدر في Android المرسَل إلى المطوّرين الشاشة الإجمالية، وهي واجهة مستخدم على مستوى النظام للتبديل بين المهام وعرض الأنشطة والمهام التي تم الوصول إليها مؤخرًا باستخدام صورة مصغّرة لحالة التطبيق الرسومية في لحظة مغادرة المستخدم للتطبيق آخر مرة.
قد تؤدي عمليات تنفيذ التطبيقات على الأجهزة بما في ذلك مفتاح التنقّل في وظائف التطبيقات الأخيرة كما هو موضّح بالتفصيل في الفقرة 7.2.3 إلى تغيير الواجهة.
إذا كانت عمليات تنفيذ الجهاز، بما في ذلك مفتاح التنقّل في وظائف التطبيقات الأخيرة كما هو موضّح بالتفصيل في القسم 7.2.3، تغيّر الواجهة، يجب أن تستوفي المتطلبات التالية:
- [C-1-1] يجب أن تتيح عرض ما يصل إلى 7 أنشطة على الأقل.
- يجب أن يعرض عنوان 4 أنشطة على الأقل في المرة الواحدة.
- [C-1-2] يجب تنفيذ سلوك تثبيت الشاشة وتوفير قائمة إعدادات للمستخدم لتفعيل الميزة أو إيقافها.
- من المفترض أن يتم عرض لون التمييز والرمز وعنوان الشاشة في قسم "العناصر الأخيرة".
- يجب أن تعرض عنصر مساعدة لإغلاق الشاشة ("x")، ولكن يجوز تأخير ذلك إلى أن يتفاعل المستخدم مع الشاشات.
- يجب توفير اختصار للتبديل بسهولة إلى النشاط السابق.
- من المفترض أن يؤدي النقر مرّتين على مفتاح الوظائف "التطبيقات المستخدَمة مؤخرًا" إلى بدء إجراء التبديل السريع بين التطبيقَين المستخدَمَين مؤخرًا.
- من المفترض أن يؤدي الضغط مع الاستمرار على مفتاح وظائف التطبيقات الأخيرة إلى تفعيل وضع تقسيم الشاشة المتعدّد، في حال توفّره.
- قد يتم عرض المحتوى الأخير المرتبط كمجموعة تتحرك معًا.
- [SR-1] يُنصح بشدة باستخدام واجهة مستخدم Android الأحدث (أو واجهة مشابهة مستندة إلى الصور المصغّرة) لشاشة النظرة العامة.
3.8.9. إدارة الإدخال
يتيح نظام Android استخدام ميزة إدارة الإدخال واستخدام برامج تحرير طرق الإدخال التابعة لجهات خارجية.
إذا كانت عمليات تنفيذ الأجهزة تسمح للمستخدمين باستخدام طرق إدخال تابعة لجهات خارجية على الجهاز، عليهم اتّباع ما يلي:
- [C-1-1] يجب الإفصاح عن ميزة النظام الأساسي android.software.input_methods و إتاحة واجهات برمجة تطبيقات IME كما هو محدّد في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
3.8.10. عناصر التحكّم في الوسائط على شاشة القفل
تم إيقاف Remote Control Client API نهائيًا في Android 5.0 لصالح Media Notification Template الذي يتيح لتطبيقات الوسائط الدمج مع عناصر التحكّم في التشغيل التي يتم عرضها على شاشة القفل.
3.8.11. شاشات الاستراحة (المعروفة سابقًا باسم "الأحلام")
راجِع القسم 3.2.3.5 للاطّلاع على إعدادات intent لضبط حوامل الشاشة.
3.8.12. الموقع الجغرافي
إذا كانت عمليات تنفيذ الأجهزة تتضمّن أداة استشعار للأجهزة (مثل نظام تحديد المواقع العالمي (GPS)) قادرة على تقديم إحداثيات الموقع الجغرافي،
- [C-1-2] يجب عرض الحالة الحالية للموقع الجغرافي في قائمة "الموقع الجغرافي" ضمن "الإعدادات".
- [C-1-3] يجب عدم عرض أوضاع الموقع الجغرافي في قائمة "الموقع الجغرافي" ضمن "الإعدادات".
3.8.13. يونيكود والخط
يتيح نظام Android استخدام أحرف الرموز التعبيرية المحدّدة في Unicode 10.0.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن شاشة أو إخراج فيديو، يجب أن تستوفي الشروط التالية:
- [C-1-1] يجب أن يكون النظام قادرًا على عرض أحرف الرموز التعبيرية هذه برمز مميّز بالألوان.
- [C-1-2] يجب أن تتضمّن ميزة الدعم ما يلي:
- خط Roboto 2 بدرجات مختلفة من السماكة، مثل sans-serif-thin وsans-serif-light وsans-serif-medium وsans-serif-black وsans-serif-condensed وsans-serif-condensed-light للغات المتوفّرة على الجهاز
- تغطية كاملة لـ Unicode 7.0 للغة اللاتينية واليونانية والسيريلية، بما في ذلك النطاقات A وB وC وD الموسّعة للغة اللاتينية وجميع الأحرف الرسومية في مجموعة رموز العملة في Unicode 7.0
- [C-1-3] يجب عدم إزالة ملف NotoColorEmoji.tff أو تعديله في صورة النظام. (يُسمح بإضافة خط رموز تعبيرية جديد لتجاهل الرموز التعبيرية فيملف NotoColorEmoji.tff)
- يجب أن تتيح استخدام رموز الإيموجي التي تُظهر درجات لون البشرة المختلفة وأفراد العائلة المتنوعة كما هو موضّح في التقرير الفني 51 حول يونيكود.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن IME، يجب أن تستوفي الشروط التالية:
- يجب أن يوفّر التطبيق طريقة إدخال للمستخدمين لاستخدام رموز الإيموجي هذه.
يتيح نظام التشغيل Android عرض خطوط ميانمار. تستخدم ميانمار عدة خطوط غير متوافقة مع Unicode، وتُعرف هذه الخطوط عادةً باسم "Zawgyi"، وهي مخصّصة لعرض محتوى بلغات ميانمار.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة اللغة البورمية، يجب أن تستوفي الشروط التالية:
- [C-2-1] يجب عرض النص باستخدام خط متوافق مع Unicode كخط تلقائي، ويجب عدم ضبط خط غير متوافق مع Unicode كخط تلقائي ما لم يكن المستخدم يختاره في أداة اختيار اللغة.
- [C-2-2] يجب أن يكون التطبيق متوافقًا مع خط Unicode وخط غير متوافق مع Unicode إذا كان هناك خط غير متوافق مع Unicode على الجهاز. يجب ألّا يزيل الخط غير المتوافق مع ملف يونيكود أو يستبدل خط يونيكود.
- [C-2-3] يجب عرض النص بخط غير متوافق مع Unicode فقط في حال تحديد رمز لغة يحتوي على رمز نص Qaag (مثل my-Qaag). لا يمكن استخدام أي رموز أخرى للغة أو المنطقة وفقًا لمعيار ISO (سواء كانت مخصّصة أو غير مخصّصة أو محجوزة) للإشارة إلى خط غير متوافق مع تنسيق Unicode في ميانمار. يمكن لمطوّري التطبيقات ومؤلفي صفحات الويب تحديد my-Qaag كرمز اللغة المحدّد كما يفعلون مع أي لغة أخرى.
3.8.14. النوافذ المتعددة
إذا كانت عمليات تنفيذ الأجهزة تتيح عرض أنشطة متعددة في الوقت نفسه، يجب أن:
- [C-1-1] يجب تنفيذ أوضاع النوافذ المتعددة هذه بما يتوافق مع سلوكيات التطبيقات وواجهات برمجة التطبيقات الموضّحة في مستندات دعم وضع النوافذ المتعددة لحزمة تطوير البرامج(SDK) لنظام التشغيل Android واستيفاء المتطلبات التالية:
- [C-1-2] يجب الالتزام بإعدادات
android:resizeableActivity
التي يضبطها أحد التطبيقات في ملفAndroidManifest.xml
على النحو الموضّح في حزمة تطوير البرامج هذه. - [C-1-3] يجب عدم توفير وضع "تقسيم الشاشة" أو وضع "التنسيق الحر" إذا كان طول الشاشة أقل من 440 وحدة كثافة بكسل وعرض الشاشة أقل من 440 وحدة كثافة بكسل.
- [C-1-4] يجب ألّا يتم تغيير حجم النشاط إلى حجم أصغر من 220dp في أوضاع النوافذ المتعدّدة بخلاف وضع "نافذة ضمن نافذة".
- يجب أن تتيح عمليات تنفيذ الأجهزة التي يبلغ حجم شاشته
xlarge
استخدام وضع الشكل الحر.
إذا كانت عمليات تنفيذ الأجهزة تتيح أوضاع النوافذ المتعددة ووضع شاشة التقسيم، يجب أن تستوفي المتطلبات التالية:
- [C-2-2] يجب اقتصاص النشاط المُثبَّت في نافذة متعدّدة على الشاشة المُقسّمة، ولكن يجب عرض بعض محتواه إذا كان تطبيق مشغِّل التطبيقات هو النافذة التي يتم التركيز عليها.
- [C-2-3] يجب أن يحترم القيم المعلَن عنها
AndroidManifestLayout_minWidth
وAndroidManifestLayout_minHeight
لتطبيق مشغّل التطبيقات التابع لجهة خارجية وألا تلغي هذه القيم أثناء عرض بعض محتوى النشاط المُثبَّت.
إذا كانت عمليات تنفيذ الأجهزة تتيح أوضاع النوافذ المتعددة ووضع "نافذة ضمن نافذة" وضع النوافذ المتعددة، يجب أن تستوفي المتطلبات التالية:
[C-3-1] يجب تشغيل الأنشطة في وضع "نافذة ضمن النافذة" المتعدّد المهام عندما يكون التطبيق:
- استهداف المستوى 26 من واجهة برمجة التطبيقات أو الإصدارات الأحدث وبيان
android:supportsPictureInPicture
- استهداف المستوى 25 أو أقل لواجهة برمجة التطبيقات وتحديد كل من
android:resizeableActivity
وandroid:supportsPictureInPicture
- استهداف المستوى 26 من واجهة برمجة التطبيقات أو الإصدارات الأحدث وبيان
[C-3-2] يجب عرض الإجراءات في SystemUI كما هو موضح في نشاط وضع الصورة في الصورة الحالي من خلال واجهة برمجة التطبيقات
setActions()
.[C-3-3] يجب أن تتيح استخدام نسب عرض إلى ارتفاع أكبر من أو تساوي 1:2.39 وأصغر من أو تساوي 2.39:1، كما هو محدّد في نشاط "صورة داخل صورة" من خلال واجهة برمجة التطبيقات
setAspectRatio()
.[C-3-4] يجب استخدام
KeyEvent.KEYCODE_WINDOW
للتحكّم في نافذة الصورة في الصورة. وفي حال عدم تنفيذ وضع الصورة في الصورة، يجب أن يكون المفتاح متاحًا للنشاط الذي يظهر في المقدّمة.[C-3-5] يجب أن يقدّم التطبيق ميزة تتيح للمستخدم حظر عرض التطبيق في وضع "صورة في صورة"، ويلبي تطبيق AOSP هذا الشرط من خلال توفير عناصر تحكّم في نافذة الإشعارات.
[C-3-6] يجب تخصيص الحد الأدنى التالي للعرض والارتفاع لملف PIP العرضي عندما لا يعلن التطبيق عن أي قيمة لسمتي
AndroidManifestLayout_minWidth
وAndroidManifestLayout_minHeight
:- بالنسبة إلى الأجهزة التي تم ضبط Configuration.uiMode فيها على قيمة غير
UI_MODE_TYPE_TELEVISION
، يجب أن يكون الحد الأدنى للعرض والارتفاع 108 dp. - بالنسبة إلى الأجهزة التي تم ضبط Configuration.uiMode فيها على
UI_MODE_TYPE_TELEVISION
، يجب أن يكون الحد الأدنى للعرض 240 بكسل مستقل الكثافة والحد الأدنى للارتفاع 135 بكسل مستقل الكثافة.
- بالنسبة إلى الأجهزة التي تم ضبط Configuration.uiMode فيها على قيمة غير
3.8.15. جزء مقتطع من الشاشة
يتوافق Android مع ميزة "اقتصاص الشاشة" كما هو موضّح
في مستند حزمة تطوير البرامج (SDK). تحدِّد واجهة برمجة التطبيقات DisplayCutout
منطقة على جانب الشاشة قد لا تكون صالحة للاستخدام في أحد التطبيقات
بسبب وجود مساحة مخصّصة للكاميرا أو شاشة منحنية على الجانبين.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن فتحات للشاشة، يجب استيفاء الشروط التالية:
- [C-1-5] يجب ألّا تتضمّن لقطات الشاشة أيّ أجزاء مُقتطعة إذا كانت نسبة العرض إلى الارتفاع للجهاز 1.0(1:1).
- [C-1-2] يجب ألا يتضمّن أكثر من فتحة واحدة لكل جانب.
- [C-1-3] يجب أن يراعي التطبيق علامات اقتصاص الشاشة التي يضبطها من خلال واجهة برمجة التطبيقات
WindowManager.LayoutParams
كما هو موضّح في حزمة تطوير البرامج (SDK). - [C-1-4] يجب أن تُبلغ عن قيم صحيحة لجميع مقاييس القطع المحدّدة في واجهة برمجة التطبيقات
DisplayCutout
.
3.8.16. عناصر التحكّم بالأجهزة
يتضمّن نظام التشغيل Android واجهات برمجة التطبيقات ControlsProviderService
وControl
للسماح للتطبيقات التابعة لجهات خارجية بنشر عناصر تحكّم في الجهاز للاطّلاع على الحالة والإجراء بسرعة.
راجِع القسم 2_2_3 لمعرفة المتطلبات الخاصة بالأجهزة.
3.9. إدارة الجهاز
يتضمّن نظام Android ميزات تتيح للتطبيقات المهتمة بالأمان تنفيذ وظائف إدارة الجهاز على مستوى النظام، مثل فرض سياسات كلمات المرور أو تنفيذ ميزة "محو البيانات عن بُعد" من خلال واجهة برمجة التطبيقات Android Device Administration API.
إذا كانت عمليات تنفيذ الأجهزة تنفِّذ المجموعة الكاملة من سياسات إدارة الجهاز المحدّدة في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android، فإنّها:
- [C-1-1] يجب أن يُعلن عن
android.software.device_admin
. - [C-1-2] يجب أن تتيح الخدمة إعداد حساب مالك الجهاز كما هو موضّح في الفقرة 3.9.1 و الفقرة 3.9.1.1.
3.9.1 إدارة الجهاز
3.9.1.1 إعداد حساب مالك الجهاز
إذا كانت عمليات تنفيذ الأجهزة تعرِض android.software.device_admin
، يعني ذلك ما يلي:
- [C-1-1] يجب أن يتيح التطبيق تسجيل "وحدة تحكّم بسياسة الجهاز" (DPC) كأحد
تطبيقات مالك الجهاز
على النحو الموضّح أدناه:
- عندما لا يتم ضبط بيانات المستخدمين في عملية تنفيذ الجهاز بعد، يتم تنفيذ ما يلي:
- [C-1-5] يجب تسجيل تطبيق DPC كتطبيق "مالك الجهاز" إذا كان
الجهاز يعلن عن توافقه مع تقنية "الاتصال القصير المدى" (NFC) من خلال علامة
الميزة
android.hardware.nfc
ويتلقّى رسالة NFC تحتوي على سجلّ بنوع MIMEMIME_TYPE_PROVISIONING_NFC
. - [C-1-8] يجب إرسال ACTION_GET_PROVISIONING_MODE intent بعد بدء عملية إعداد مالك الجهاز حتى تتمكّن DPC app من اختيار ما إذا كان يريد أن يصبح مالك جهاز أو ملف شخصي Owner ما لم يكن من الممكن تحديد من السياق أنّه لا يوجد سوى خيار واحد صالح (مثل عملية الإعداد المستندة إلى NFC حيث لا تكون عملية إعداد ملف شخصي Owner متاحة).
- [C-1-9] يجب إرسال ACTION_ADMIN_POLICY_COMPLIANCE بهدف إلى تطبيق "مالك الجهاز" في حال تم إنشاء مالك جهاز أثناء عملية الإعداد بغض النظر عن طريقة الإعداد المستخدَمة. يجب ألا يتمكّن المستخدم من المتابعة في معالج الإعداد إلى أن ينتهي تطبيق "مالك الجهاز".
- [C-1-5] يجب تسجيل تطبيق DPC كتطبيق "مالك الجهاز" إذا كان
الجهاز يعلن عن توافقه مع تقنية "الاتصال القصير المدى" (NFC) من خلال علامة
الميزة
- عندما يتضمّن تطبيق الجهاز بيانات المستخدمين، يتم تنفيذ ما يلي:
- [C-1-7] يجب عدم تسجيل أي تطبيق DPC كتطبيق "مالك الجهاز" بعد الآن.
- عندما لا يتم ضبط بيانات المستخدمين في عملية تنفيذ الجهاز بعد، يتم تنفيذ ما يلي:
- [C-1-2] يجب أن يطلب التطبيق اتخاذ إجراء إيجابي قبل عملية الإعداد أو أثناءها للموافقة على ضبط التطبيق كـ "مالك الجهاز". يمكن الحصول على الموافقة من خلال إجراء يتّخذه المستخدم أو من خلال بعض الوسائل الآلية، ولكن يجب عرض إشعار الإفصاح المناسب (كما هو مذكور في AOSP) قبل بدء عملية تجهيز مالك الجهاز. بالإضافة إلى ذلك، يجب ألا تؤدي آلية الموافقة الآلية لمالكي الأجهزة التي تستخدمها (المؤسسات) لتوفير مالك الجهاز إلى التداخل مع تجربة الاستخدام خارج العلبة للاستخدام غير المرتبط بالمؤسسة.
- [C-1-3] يجب عدم تضمين الموافقة في الرمز البرمجي الثابت أو منع استخدام تطبيقات مالك الجهاز الأخرى.
إذا كانت عمليات تنفيذ الأجهزة تُعلن عن android.software.device_admin
، ولكنها أيضًا
تتضمّن حلّ إدارة مالك الجهاز المملوك وتوفر آلية
لتعزيز تطبيق تم ضبطه في حلّها على أنّه "مالك جهاز مماثل" لـ "مالك الجهاز" العادي كما هو معترف به من واجهات برمجة التطبيقات العادية لنظام التشغيل Android
DevicePolicyManager
، يجب استيفاء الشروط التالية:
- [C-2-1] يجب أن تتوفّر عملية للتحقّق من أنّ التطبيق المعني الذي يتم الترويج له ينتمي إلى حلّ شرعي لإدارة devices في المؤسسات وأنّه سبق أن تم ضبطه في الحلّ المملوك للحصول على حقوق مساوية لحقوق "مالك الجهاز".
- [C-2-2] يجب عرض بيان الإفصاح عن الموافقة نفسه لمالك الجهاز في AOSP مثل مسار المعالجة الذي بدأه
android.app.action.PROVISION_MANAGED_DEVICE
قبل تسجيل تطبيق "إدارة الخدمات الجوّالة للمؤسسات" بصفته "مالك الجهاز". - قد تتوفّر لديه بيانات المستخدم على الجهاز قبل تسجيل تطبيق وحدة التحكّم بسياسة الجهاز (DPC) بصفتك "مالك الجهاز".
3.9.1.2 توفير الملف الشخصي المُدار
إذا كانت عمليات تنفيذ الأجهزة تعرِض android.software.managed_users
، يعني ذلك ما يلي:
[C-1-1] يجب تنفيذ واجهات برمجة التطبيقات التي تسمح لتطبيق "وحدة التحكّم بسياسة الجهاز" (DPC) بأن يصبح مالك ملف شخصي مُدار جديد.
[C-1-2] يجب أن تكون عملية توفير الملف الشخصي المُدار (التدفق الذي يبدأه "مدير الخدمات الجوّالة للمؤسسات" باستخدام android.app.action.PROVISION_MANAGED_PROFILE) أو من خلال النظام الأساسي) وشاشة الموافقة وتجربة المستخدم متوافقة مع تنفيذ AOSP.
[C-1-3] يجب توفير ميزات الاستخدام التالية للمستخدم ضمن "الإعدادات" ل إعلام المستخدم عندما يتم إيقاف وظيفة نظام معيّنة من قِبل "وحدة التحكّم بسياسة الجهاز" (DPC):
- رمز متسق أو عنصر تحكم آخر للمستخدم (مثل رمز معلومات AOSP في المصدر المفتوح) للإشارة إلى حظر إعداد معيّن من قِبل أحد مشرفي الجهاز
- رسالة شرح موجزة، كما قدّمها مشرف الجهاز من خلال
setShortSupportMessage
- رمز تطبيق "مركز التحكّم في البيانات"
[C-1-4] يجب تشغيل معالِج طلب ACTION_PROVISIONING_SUCCESSFUL في الملف الشخصي للعمل في حال تم إنشاء مالك ملف شخصي عند بدء عملية الإعداد من خلال طلب android.app.action.PROVISION_MANAGED_PROFILE وتنفيذ وحدة التحكّم في نقطة النهاية (DPC) للمعالِج.
[C-1-5] يجب إرسال بث ACTION_PROFILE_PROVISIONING_COMPLETE إلى DPC الخاص بملف العمل عند بدء عملية الإعداد من خلال android.app.action.PROVISION_MANAGED_PROFILE intent.
[C-1-6] يجب إرسال ACTION_GET_PROVISIONING_MODE intent بعد بدء عملية إعداد مالك الملف الشخصي حتى تتمكّن DPC app من اختيار ما إذا كان يريد أن يصبح مالك جهاز أو مالك ملف شخصي، باستثناء الحالات التي يتم فيها بدء عملية الإعداد من خلال android.app.action.PROVISION_MANAGED_PROFILE.
[C-1-7] يجب إرسال ACTION_ADMIN_POLICY_COMPLIANCE القصد إلى الملف الشخصي للعمل عند إنشاء مالك ملف أثناء الإعداد بغض النظر عن طريقة الإعداد المستخدَمة إلا عند بدء الإعداد من خلال القصد android.app.action.PROVISION_MANAGED_PROFILE. يجب ألا يتمكّن المستخدم من المتابعة في معالج الإعداد إلى أن ينتهي تطبيق "ملف العميل المالك".
[C-1-8] يجب إرسال ACTION_MANAGED_PROFILE_PROVISIONED بثًا إلى وحدة التحكّم في حدود الحساب (DPC) للملف الشخصي عند إنشاء مالك ملف شخصي، بغض النظر عن طريقة الإعداد المستخدَمة.
3.9.2 توافق الملف الشخصي المُدار
إذا كانت عمليات تنفيذ الأجهزة تعرِض android.software.managed_users
، يعني ذلك ما يلي:
- [C-1-1] يجب أن تتيح التطبيقات إدارة الملفات التجارية من خلال
android.app.admin.DevicePolicyManager
واجهات برمجة التطبيقات. - [C-1-2] يجب السماح بإنشاء ملف شخصي مُدار واحد فقط.
- [C-1-3] يجب استخدام شارة رمز (مثل شارة العمل في AOSP) لتمثيل التطبيقات المصغّرة والتطبيقات المُدارة وعناصر واجهة المستخدم الأخرى التي تحمل شارة، مثل "التطبيقات المستخدَمة مؤخرًا" و"الإشعارات".
- [C-1-4] يجب عرض رمز إشعار (يشبه شارة العمل في AOSP) للإشارة إلى وقت استخدام المستخدم لتطبيق ملف شخصي مُدار.
- [C-1-6] في حال توفّر ملف شخصي مُدار، يجب عرض عنصر تحكم مرئي في "أداة اختيار" الإجراء للسماح للمستخدم بإعادة توجيه الإجراء من الملف الشخصي المُدار إلى المستخدم الأساسي أو العكس، إذا فعّل ذلك "عنصر التحكّم في سياسة الجهاز".
- [C-1-7] في حال توفّر ملف شخصي مُدار، يجب عرض ميزات الاستخدام التالية لكل من المستخدم الأساسي والملف الشخصي المُدار:
- احتساب استخدام البطارية والموقع الجغرافي وبيانات الجوّال ومساحة التخزين بشكل منفصل للمستخدم الأساسي والملف الشخصي المُدار
- إدارة مستقلة لتطبيقات VPN المثبَّتة في الملف الشخصي الأساسي للمستخدم أو الملف الشخصي المُدار
- إدارة مستقلة للتطبيقات المثبَّتة في الملف الشخصي الأساسي أو الملف الشخصي المُدار
- إدارة مستقلة للحسابات ضمن الملف الشخصي للمستخدم الأساسي أو الملف الشخصي المُدار
- [C-1-8] يجب التأكّد من أنّ تطبيقات جهات الاتصال والاتصال والرسائل المُثبَّتة مسبقًا يمكنها البحث عن معلومات المتصل والاطّلاع عليها من الملف الشخصي المُدار (إذا كان متوفّرًا) إلى جانب تلك الواردة من الملف الشخصي الأساسي، إذا كان جهاز التحكّم في سياسة الجهاز يسمح بذلك.
- [C-1-9] يجب التأكّد من استيفاء جميع متطلبات الأمان الواجبة التطبيق على جهاز تم تفعيل ميزة "المستخدمون المتعدّدون" عليه (راجِع الفقرة 9.5)، حتى إذا لم يتم احتساب الملف الشخصي المُدار كمستخدم آخر بالإضافة إلى المستخدم الأساسي.
إذا كانت عمليات تنفيذ الأجهزة تعرِض android.software.managed_users
و
android.software.secure_lock_screen
، فإنّها:
- [C-2-1] يجب أن تتيح إمكانية تحديد شاشة قفل منفصلة تستوفي
المتطلبات التالية لمنح إذن الوصول إلى التطبيقات التي تعمل في ملف شخصي
مُدار فقط.
- يجب أن تلتزم عمليات تنفيذ الأجهزة بحالة العميل
DevicePolicyManager.ACTION_SET_NEW_PASSWORD
وأن تعرض واجهة لضبط بيانات اعتماد شاشة قفل منفصلة للملف الشخصي المُدار. - يجب أن تستخدِم بيانات اعتماد شاشة القفل للملف الشخصي المُدار آليات تخزين بيانات الاعتماد وإدارتها نفسها المستخدَمة في الملف الشخصي الرئيسي، كما هو موضّح في موقع مشروع Android Open Source Project الإلكتروني.
- سياسات كلمات المرور في DPC: يجب أن تنطبق فقط على بيانات اعتماد شاشة القفل للملف الشخصي المُدار ما لم يتم استدعاء مثيل
DevicePolicyManager
الذي تم إرجاعه من getParentProfileInstance.
- يجب أن تلتزم عمليات تنفيذ الأجهزة بحالة العميل
- عند عرض جهات الاتصال من الملف الشخصي المُدار في سجلّ المكالمات المثبَّت مسبقًا وواجهة المستخدم أثناء المكالمة والإشعارات المتعلّقة بالمكالمات الجارية والمُفوَّتة وتطبيقات جهات الاتصال والرسائل، يجب وضع الشارة نفسها المستخدَمة للإشارة إلى تطبيقات الملف الشخصي المُدار.
3.9.3 دعم المستخدِم المُدار
إذا كانت عمليات تنفيذ الأجهزة تعرِض android.software.managed_users
، يعني ذلك ما يلي:
- [C-1-1] يجب توفير عنصر تحكم للمستخدم من أجل تسجيل الخروج من حساب المستخدم الحالي والعودة إلى حساب المستخدم الأساسي في جلسة متعددة المستخدمين عندما يعرض
isLogoutEnabled
true
. يجب أن يكون بإمكان المستخدم الوصول إلى واجهة المستخدم من شاشة القفل بدون فتح قفل الجهاز.
إذا كانت عمليات تنفيذ الأجهزة تحدّد android.software.device_admin
وتوفّر
إمكانية للمستخدم على الجهاز لإضافة مستخدمين ثانويين إضافيين، فإنّها:
- [C-SR-1] يُنصح بشدة بعرض بيانات الإفصاح عن الموافقة على AOSP Device نفسها التي تم عرضها في العملية التي بدأها android.app.action.PROVISION_MANAGED_DEVICE، قبل السماح بإضافة حسابات في المستخدم الثانوي الجديد، لكي يفهم المستخدمون أنّ الجهاز مُدار.
3.10. تسهيل الاستخدام
يقدّم نظام التشغيل Android طبقة تسهيل الاستخدام تساعد المستخدمين الذين يعانون من عجز في التنقّل في أجهزتهم بسهولة أكبر. بالإضافة إلى ذلك، يقدّم Android واجهات برمجة تطبيقات النظام التي تتيح لعمليات تنفيذ خدمات تسهيل الاستخدام تلقّي عمليات استدعاء لأحداث المستخدم والنظام وإنشاء آليات ملاحظات بديلة، مثل تحويل النص إلى كلام والملاحظات اللمسية والتنقّل باستخدام كرة التتبُّع أو لوحة التوجيه.
إذا كانت عمليات تنفيذ الأجهزة متوافقة مع خدمات إمكانية الوصول التابعة لجهات خارجية، يجب استيفاء الشروط التالية:
- [C-1-1] يجب توفير تنفيذ لإطار عمل تسهيل الاستخدام في Android كما هو موضّح في مستندات حزمة تطوير البرامج (SDK) الخاصة بواجهات برمجة تطبيقات تسهيل الاستخدام.
- [C-1-2] يجب إنشاء أحداث تسهيل الاستخدام وإرسال
AccessibilityEvent
المناسب إلى جميع عمليات التنفيذ المسجّلةAccessibilityService
كما هو موضّح في حزمة تطوير البرامج (SDK). - [C-1-4] يجب أن يوفّر التطبيق عنصر تحكم للمستخدم للتحكّم في خدمات تسهيل الاستخدام التي تعلن عن العنصر AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON. يُرجى العلم أنّه بالنسبة إلى عمليات تنفيذ الأجهزة التي تتضمّن شريط تنقّل في النظام، يجب أن يُتاح للمستخدم خيار زر في شريط تنقّل النظام للتحكّم في هذه الخدمات.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن خدمات تسهيل الاستخدام المثبَّتة مسبقًا، يجب أن تستوفي المتطلبات التالية:
- [C-2-1] يجب تنفيذ خدمات تسهيل الاستخدام هذه المثبَّتة مسبقًا كتطبيقات متوافقة مع ميزة "التمهيد المباشر" عند تشفير مساحة تخزين البيانات باستخدام ميزة "التشفير المستند إلى الملفات" (FBE).
- يجب أن توفّر آلية في عملية الإعداد للمستخدمين لتفعيل خدمات تسهيل الاستخدام ذات الصلة، بالإضافة إلى خيارات لضبط حجم الخط وحجم الشاشة وإيماءات التكبير.
3.11. تحويل النص إلى كلام
يتضمّن Android واجهات برمجة تطبيقات تتيح للتطبيقات الاستفادة من خدمات تحويل النص إلى كلام (TTS) وتسمح لمقدّمي الخدمات بتوفير عمليات تنفيذ لخدمات تحويل النص إلى كلام.
في حال كانت عمليات تنفيذ الأجهزة تُبلغ عن الميزة android.hardware.audio.output، يجب أن:
- [C-1-1] يجب أن يكون التطبيق متوافقًا مع واجهات برمجة تطبيقات إطار عمل تحويل النص إلى كلام (TTS) في Android.
إذا كانت عمليات تنفيذ الأجهزة تتيح تثبيت محرّكات تحويل النص إلى كلام التابعة لجهات خارجية، يجب أن تستوفي الشروط التالية:
- [C-2-1] يجب أن توفّر إمكانات الاستخدام للمستخدم للسماح له باختيار محرك تحويل محتوى إلى كلام (TTS) لاستخدامه على مستوى النظام.
3.12. إطار عمل إدخال التلفزيون
يعمل إطار عمل إدخال Android Television (TIF) على تبسيط عملية إرسال المحتوى المباشر إلى أجهزة Android Television. توفّر واجهة TIF واجهة برمجة تطبيقات عادية لإنشاء وحدات إدخال تتحكّم في أجهزة Android Television.
إذا كانت عمليات تنفيذ الأجهزة متوافقة مع TIF، يجب أن تستوفي الشروط التالية:
- [C-1-1] يجب الإفصاح عن ميزة المنصة
android.software.live_tv
. - [C-1-2] يجب أن يكون متوافقًا مع جميع واجهات برمجة تطبيقات TIF حتى يمكن تثبيت تطبيق يستخدم هذه الواجهات والخدمات التابعة لجهات خارجية المستندة إلى TIF على الجهاز واستخدامه.
3.13. الإعدادات السريعة
يقدّم Android مكوّن واجهة مستخدم "الإعدادات السريعة" الذي يتيح الوصول السريع إلى الإجراء المستخدَم بشكل متكرّر أو المطلوب بشكل عاجل.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن مكوّن واجهة مستخدم "الإعدادات السريعة" وتتوافق مع تطبيقات "الإعدادات السريعة" التابعة لجهات خارجية، يجب أن تستوفي المتطلبات التالية:
- [C-1-1] يجب أن يسمح التطبيق للمستخدم بإضافة أو إزالة المربّعات المقدَّمة من خلال واجهات برمجة تطبيقات
quicksettings
من تطبيق تابع لجهة خارجية. - [C-1-2] يجب عدم إضافة شاشة معلومات تلقائيًا من تطبيق تابع لجهة خارجية مباشرةً إلى "الإعدادات السريعة".
- [C-1-3] يجب عرض جميع المربّعات التي أضافها المستخدم من تطبيقات تابعة لجهات خارجية إلى جانب مربّعات الإعدادات السريعة التي يوفّرها النظام.
3.14. واجهة مستخدم الوسائط
إذا كانت عمليات تنفيذ الأجهزة تتضمّن تطبيقات لا يتم تفعيلها باستخدام الصوت (التطبيقات) تتفاعل مع
تطبيقات تابعة لجهات خارجية من خلال MediaBrowser
أو MediaSession
،
يجب أن تستوفي التطبيقات الشروط التالية:
[C-1-2] يجب أن يعرض التطبيق بوضوح الرموز التي تم الحصول عليها من خلال
getIconBitmap()
أوgetIconUri()
والعناوين التي تم الحصول عليها من خلالgetTitle()
على النحو الموضّح فيMediaDescription
. قد يتم تقصير العناوين للالتزام بأنظمة السلامة (مثل تشتيت انتباه السائق).[C-1-3] يجب عرض رمز التطبيق التابع لجهة خارجية عند عرض محتوى يوفّره هذا التطبيق التابع لجهة خارجية.
[C-1-4] يجب أن يسمح التطبيق للمستخدم بالتفاعل مع التدرّج الهرمي الكامل
MediaBrowser
. يجوز للنظام حظر الوصول إلى جزء من التسلسل الهرمي للامتثال للوائح السلامة (مثل تشتيت انتباه السائق)، ولكن يجب عدم منح معاملة تفضيلية استنادًا إلى المحتوى أو مقدّم المحتوى.[C-1-5] يجب اعتبار النقر مرّتين على
KEYCODE_HEADSETHOOK
أوKEYCODE_MEDIA_PLAY_PAUSE
على أنّهKEYCODE_MEDIA_NEXT
لرمزMediaSession.Callback#onMediaButtonEvent
.
3.15. التطبيقات الفورية
إذا كانت عمليات تنفيذ التطبيقات على الأجهزة تتيح تطبيقات فورية، يجب أن تستوفي التطبيقات المتطلبات التالية:
- [C-1-1] يجب عدم منح التطبيقات الفورية سوى الأذونات التي تم ضبط
android:protectionLevel
على"instant"
. - [C-1-2] يجب ألّا تتفاعل التطبيقات الفورية مع التطبيقات المثبّتة من خلال المهام الضمنية
ما لم يكن أحد الشروط التالية صحيحًا:
- يتم عرض فلتر نمط أهداف المكوّن ويتضمّن CATEGORY_BROWSABLE.
- الإجراء هو أحد الإجراءات التالية: ACTION_SEND أو ACTION_SENDTO أو ACTION_SEND_MULTIPLE
- يتم عرض الهدف بشكل صريح باستخدام android:visibleToInstantApps
- [C-1-3] يجب ألّا تتفاعل التطبيقات الفورية بشكل صريح مع التطبيقات المثبّتة ما لم يتم عرض العنصر باستخدام android:visibleToInstantApps.
- [C-1-4] يجب ألا تظهر تفاصيل عن التطبيقات الفورية على الجهاز للتطبيقات المثبَّتة ما لم يتصل التطبيق الفوري بالتطبيق المثبَّت بشكل صريح.
يجب أن توفّر عمليات التنفيذ على الأجهزة ميزات الاستخدام التالية للمستخدمين من أجل التفاعل مع التطبيقات الفورية. يستوفي AOSP المتطلبات من خلال واجهة المستخدم و"الإعدادات" و"المشغِّل" التلقائيَين للنظام. عمليات التنفيذ على الأجهزة:
- [C-1-5] يجب أن يوفّر التطبيق ميزة للمستخدم لعرض التطبيقات الفورية وحذفها التي تم تخزينها مؤقتًا على الجهاز لكل حزمة تطبيق فردية.
- [C-1-6] يجب أن يقدّم التطبيق إشعارًا دائمًا للمستخدم يمكنه
تصغيره أثناء تشغيل تطبيق فوري في المقدّمة. يجب أن يتضمّن إعلام المستخدمين
هذا أنّ التطبيقات الفورية لا تتطلّب التثبيت
وأن يقدّم ميزة للمستخدمين توجّههم إلى شاشة معلومات التطبيق
في الإعدادات. بالنسبة إلى التطبيقات الفورية التي يتم تشغيلها من خلال نوايا الويب، كما هو موضح
باستخدام نية تم ضبط الإجراء فيها على
Intent.ACTION_VIEW
باستخدام مخطّط "http" أو "https"، يجب أن توفّر ميزة إضافية للمستخدمين إمكانية عدم تشغيل التطبيق الفوري وتشغيل الرابط المرتبط باستخدام متصفّح الويب الذي تم ضبطه، إذا كان متصفّحًا متاحًا على الجهاز. - [C-1-7] يجب السماح بالوصول إلى التطبيقات الفورية التي يتم تشغيلها من خلال ميزة "التطبيقات المستخدَمة مؤخرًا" إذا كانت ميزة "التطبيقات المستخدَمة مؤخرًا" متاحة على الجهاز.
[C-1-8] يجب تحميل تطبيق أو مكوّن خدمة واحد أو أكثر مسبقًا مع معالِج أهداف للأهداف المدرَجة في حزمة تطوير البرامج (SDK) هنا وإظهار الأهداف لتطبيقات Android الفورية.
3.16. إقران الجهاز المصاحب
يتيح نظام التشغيل Android إقران الأجهزة المصاحبة لإدارة عملية الربط بالأجهزة المصاحبة بفعالية أكبر، كما يقدّم واجهة برمجة التطبيقات CompanionDeviceManager
للتطبيقات للوصول إلى هذه الميزة.
إذا كانت عمليات تنفيذ الأجهزة تتيح ميزة إقران الجهاز المصاحب، يجب أن تستوفي الشروط التالية:
- [C-1-1] يجب الإفصاح عن علامة الميزة
FEATURE_COMPANION_DEVICE_SETUP
. - [C-1-2] يجب التأكّد من تنفيذ واجهات برمجة التطبيقات في حزمة
android.companion
بالكامل. - [C-1-3] يجب أن توفّر إمكانات الاستخدام للمستخدم لاختيار/تأكيد توفّر جهاز مصاحب وتشغيله.
3.17. التطبيقات الثقيلة
إذا كانت عمليات تنفيذ الأجهزة تحدّد الميزة FEATURE_CANT_SAVE_STATE
،
يعني ذلك أنّها:
- [C-1-1] يجب أن يكون هناك تطبيق واحد فقط مثبَّت يحدِّد
cantSaveState
الذي يعمل في النظام في كل مرة. إذا خرج المستخدم من هذا التطبيق بدون الخروج منه صراحةً (على سبيل المثال، من خلال الضغط على زر الرجوع أثناء مغادرة نشاط نشط في النظام، بدلاً من الضغط على زر الرجوع بدون أن تبقى أي أنشطة نشطة في النظام)، يجب أن تمنح عمليات تنفيذ التطبيقات على الجهاز الأولوية لهذا التطبيق في ذاكرة الوصول العشوائي كما تفعل مع التطبيقات الأخرى التي يُتوقّع أن تظل قيد التشغيل، مثل الخدمات التي تعمل في المقدّمة. وعندما يكون هذا التطبيق في الخلفية، لا يزال بإمكان النظام تطبيق ميزات إدارة الطاقة عليه، مثل الحد من الوصول إلى وحدة المعالجة المركزية والشبكة. - [C-1-2] يجب توفير عنصر واجهة مستخدم لاختيار التطبيق الذي لن يشارك في آلية حفظ/استعادة الحالة العادية بعد أن يبدأ المستخدم تطبيقًا ثانيًا تم تحديده باستخدام سمة
cantSaveState
. - [C-1-3] يجب عدم تطبيق تغييرات أخرى في السياسة على التطبيقات التي تحدّد
cantSaveState
، مثل تغيير أداء وحدة المعالجة المركزية أو تغيير الأولوية في تحديد الجداول الزمنية.
إذا لم تُعلِن عمليات تنفيذ الميزات على الأجهزة عن الميزات
FEATURE_CANT_SAVE_STATE
،
يحدث ما يلي:
- [C-1-1] يجب تجاهل سمة
cantSaveState
التي تحدّدها التطبيقات، ويجب عدم تغيير سلوك التطبيق استنادًا إلى سمة هذه.
3.18. جهات الاتصال
يتضمّن Android Contacts
Provider
واجهات برمجة تطبيقات للسماح للتطبيقات بإدارة معلومات جهات الاتصال المخزّنة على الجهاز.
تتم عادةً مزامنة بيانات جهات الاتصال التي يتم إدخالها مباشرةً في الجهاز
مع خدمة ويب، ولكن قد تبقى البيانات أيضًا على الجهاز فقط.
تُعرف جهات الاتصال التي يتم تخزينها على الجهاز فقط باسم جهات
الاتصال المحلية.
تكون RawContacts "مرتبطة" أو "مخزّنة في"
Account
عندما تتطابق أعمدة ACCOUNT_NAME
وACCOUNT_TYPE
لجهات الاتصال الأوّلية مع حقلَي Account.name
وAccount.type
المرتبطَين بالحساب.
الحساب المحلي التلقائي: حساب لجهات الاتصال الأوّلية التي يتم تخزينها فقط على
الجهاز وغير مرتبطة بحساب في AccountManager، ويتم
إنشاؤه باستخدام قيم null للعمودين
ACCOUNT_NAME
،
و
ACCOUNT_TYPE
.
حساب محلي مخصّص: حساب للجهات التي لم تتم معالجتها والتي يتم تخزينها فقط على
الجهاز وغير مرتبطة بحساب في AccountManager، ويتم
إنشاؤها باستخدام قيمة واحدة على الأقل غير صفرية للعمودين
ACCOUNT_NAME
و
ACCOUNT_TYPE
.
عمليات التنفيذ على الأجهزة:
- [C-SR-1] يُنصح بشدة بعدم إنشاء حسابات محلية مخصّصة.
إذا كانت عمليات تنفيذ الأجهزة تستخدم حسابًا محليًا مخصّصًا:
- [C-1-1] يجب أن يتم إرجاع
ACCOUNT_NAME
، من الحساب المحلي المخصّص من قِبلContactsContract.RawContacts.getLocalAccountName
- [C-1-2] يجب أن يتم إرجاع
ACCOUNT_TYPE
، من الحساب المحلي المخصّص من قِبلContactsContract.RawContacts.getLocalAccountType
- [C-1-3] يجب إدراج جهات الاتصال الأوّلية التي تُدرجها تطبيقات تابعة لجهات خارجية باستخدام
الحساب المحلي التلقائي (أي من خلال ضبط قيم فارغة لملفَّي
ACCOUNT_NAME
وACCOUNT_TYPE
) في الحساب المحلي المخصّص . - [C-1-4] يجب عدم إزالة جهات الاتصال الأوّلية التي تم إدراجها في الحساب المحلي المخصّص عند إضافة حسابات أو إزالتها.
- [C-1-5] يجب أن تؤدي عمليات الحذف التي يتم إجراؤها على الحساب المحلي المخصّص
إلى محو جهات الاتصال الأوّلية على الفور (كما لو تم ضبط المَعلمة
CALLER_IS_SYNCADAPTER
على true)، حتى إذا تم ضبط المَعلمةCALLER\_IS\_SYNCADAPTER
على false أو لم يتم تحديدها.
4. توافق حِزم التطبيقات
عمليات تنفيذ الأجهزة:
- [C-0-1] يجب أن يكون التطبيق قادرًا على تثبيت ملفات Android بتنسيق ".apk" وتشغيلها على النحو الذي تشكلت به باستخدام أداة aapt المضمّنة في حزمة تطوير البرامج (SDK) الرسمية لنظام التشغيل Android.
- بما أنّ الشرط أعلاه قد يكون صعبًا، ننصح باستخدام نظام إدارة الحِزم في التنفيذ المرجعي لنظام التشغيل AOSP عند تنفيذ الأجهزة.
عمليات التنفيذ على الأجهزة:
- [C-0-2] يجب أن تتيح عملية التحقّق من ملفات ".apk" باستخدام الإصدار 3 من مخطّط توقيع حِزم APK والإصدار 2 من مخطّط توقيع حِزم APK وتوقيع JAR.
- [C-0-3] يجب عدم توسيع تنسيقات ملف .apk أو بيان Android أو الرمز الثنائي لنظام Dalvik أو الرمز الثنائي لـ RenderScript بطريقة تمنع تثبيت هذه الملفات وتشغيلها بشكل صحيح على الأجهزة المتوافقة الأخرى.
[C-0-4] يجب عدم السماح للتطبيقات غير "مُثبِّت الحِزمة" الحالي بالانتقام من التطبيق بدون تأكيد من العميل، كما هو موضّح في حزمة تطوير البرامج (SDK) لإذن
DELETE_PACKAGE
. الاستثناءات الوحيدة هي تطبيق مدقّق حِزم النظام الذي يتعامل مع PACKAGE_NEEDS_VERIFICATION intent وتطبيق مدير مساحة التخزين الذي يتعامل مع ACTION_MANAGE_STORAGE intent.[C-0-5] يجب أن يتضمّن نشاطًا يعالج هدف
android.settings.MANAGE_UNKNOWN_APP_SOURCES
.[C-0-6] يجب عدم تثبيت حِزم التطبيقات من مصادر غير معروفة، ما لم يستوفِ التطبيق الذي يطلب التثبيت جميع المتطلبات التالية:
- يجب أن يعلن التطبيق عن إذن
REQUEST_INSTALL_PACKAGES
أو ضبطandroid:targetSdkVersion
على 24 أو أقل. - يجب أن يكون المستخدم قد منح الإذن بتثبيت التطبيقات من مصادر غير معروفة.
- يجب أن يعلن التطبيق عن إذن
يجب أن يوفّر عنصر تحكم للمستخدم لمنح/سحب الإذن لتثبيت التطبيقات من مصادر غير معروفة لكل تطبيق، ولكن يجوز له اختيار تنفيذ ذلك كإجراء لا يؤدي إلى أيّ إجراء وعرض القيمة
RESULT_CANCELED
بدلاً منstartActivityForResult()
، إذا كان تنفيذ الجهاز لا يريد السماح للمستخدمين بهذا الخيار. ومع ذلك، حتى في هذه الحالات، يجب أن يوضّح التطبيق للمستخدم سبب عدم توفّر هذا الخيار.[C-0-7] يجب أن يعرض التطبيق مربّع حوار تحذيريًا يتضمّن سلسلة التحذير التي يتم تقديمها من خلال واجهة برمجة التطبيقات للنظام
PackageManager.setHarmfulAppWarning
للمستخدم قبل بدء نشاط في تطبيق تم وضع علامة عليه من خلال واجهة برمجة التطبيقات للنظامPackageManager.setHarmfulAppWarning
نفسها على أنّه قد يكون ضارًا.يجب أن يوفّر للمستخدم خيارًا لإلغاء تثبيت تطبيق أو تشغيله في مربّع الحوار التحذيري.
[C-0-8] يجب توفير إمكانية استخدام نظام الملفات المتزايد كما هو موضّح في المستندات هنا.
[C-0-9] يجب أن تتيح التحقق من ملفات APK .باستخدام الإصدار 4 من مخطّط توقيع حِزم APK.
5. توافق الوسائط المتعددة
عمليات التنفيذ على الأجهزة:
- [C-0-1] يجب أن يكون متوافقًا مع تنسيقات الوسائط وبرامج الترميز وفك الترميز وأنواع الملفات
وتنسيقات الحاويات المحدّدة في الفقرة 5.1
لكل مُشفِّر أعلن عنه
MediaCodecList
. - [C-0-2] يجب الإفصاح عن توفّر برامج الترميز وفك الترميز المتاحة
للتطبيقات التابعة لجهات خارجية والإبلاغ عنها من خلال
MediaCodecList
. - [C-0-3] يجب أن يكون بإمكانه فك ترميز جميع التنسيقات التي يمكنه ترميزها بشكل صحيح وإتاحتها
للتطبيقات التابعة لجهات خارجية. ويشمل ذلك جميع مجموعات البيانات التي تنشئها
برامج الترميز والملفات الشخصية التي يتم الإبلاغ عنها في
CamcorderProfile
.
عمليات التنفيذ على الأجهزة:
- يجب أن تهدف إلى الحد الأدنى من وقت استجابة ترميز الفيديو، بعبارة أخرى، يجب أن تراعي
- يجب عدم استخدام وحفظ وحدات تخزين المؤقتة للإدخال وإرجاع وحدات تخزين المؤقتة للإدخال فقط بعد معالجتها.
- يجب عدم الاحتفاظ بوحدات التخزين المؤقتة التي تم فك ترميزها لفترة أطول من المدة المحدّدة في المعيار (مثل SPS).
- يجب عدم الاحتفاظ بمخازن مؤقتة مُشفَّرة لفترة أطول من الوقت المطلوب وفقًا لبنية GOP.
يتم توفير جميع برامج الترميز المدرَجة في القسم أدناه كتطبيقات برمجية في طريقة التنفيذ المفضّلة لنظام التشغيل Android من "مشروع Android المفتوح المصدر".
يُرجى العِلم أنّ Google أو تحالف Open Handset Alliance لا يقدّمان أي تأكيد بأنّ برامج الترميز هذه خالية من براءات اختراع تابعة لجهات خارجية. ننصحك بأنّه إذا أردت استخدام رمز المصدر هذا في منتجات الأجهزة أو البرامج، قد تتطلّب عمليات تنفيذ هذا الرمز، بما في ذلك في البرامج المفتوحة المصدر أو البرامج المشترَكة، تراخيص براءات اختراع من مالكي براءات الاختراع المعنيّين.
5.1. برامج ترميز الوسائط
5.1.1. ترميز الصوت
يمكنك الاطّلاع على مزيد من التفاصيل في 5.1.3. تفاصيل برامج ترميز الصوت
إذا كانت عمليات تنفيذ الأجهزة تُعلن عن android.hardware.microphone
،
يجب أن تتيح ترميز تنسيقات الصوت التالية وإتاحتها
للتطبيقات التابعة لجهات خارجية:
- [C-1-1] PCM/WAVE
- [C-1-2] FLAC
- [C-1-3] Opus
يجب أن تكون جميع برامج ترميز الصوت متوافقة مع ما يلي:
- [C-3-1] إطارات صوتية بتنسيق PCM بسعة 16 بت بترتيب البايت الأصلي من خلال واجهة برمجة التطبيقات
android.media.MediaCodec
5.1.2. فك ترميز الصوت
يمكنك الاطّلاع على مزيد من التفاصيل في 5.1.3. تفاصيل برامج ترميز الصوت
إذا كانت عمليات تنفيذ الأجهزة تعلن عن توافقها مع ميزة
android.hardware.audio.output
، يجب أن تكون متوافقة مع فك ترميز التنسيقات التالية:
- [C-1-1] الملف الشخصي MPEG-4 AAC (AAC LC)
- [C-1-2] ملف تعريف MPEG-4 HE AAC (AAC+)
- [C-1-3] الملف الشخصي MPEG-4 HE AACv2 (الترميز المحسّن للصوت بترميز متقدّم)
- [C-1-4] AAC ELD (الترميز المتقدّم لصوت AAC المنخفض التأخير)
- [C-1-11] xHE-AAC (ملف الإصدار الموسّع من HE AAC وفقًا لمعيار ISO/IEC 23003-3، والذي يتضمّن الملف الأساسي USAC وملف التحكّم في النطاق الديناميكي وفقًا لمعيار ISO/IEC 23003-4)
- [C-1-5] FLAC
- [C-1-6] MP3
- [C-1-7] MIDI
- [C-1-8] Vorbis
- [C-1-9] تنسيق PCM/WAVE بما في ذلك تنسيقات الصوت بدقة عالية تصل إلى 24 بت ومعدّل أخذ العينات 192 كيلوهرتز و8 قنوات يُرجى العِلم أنّ هذا الشرط مخصّص لفك التشفير فقط، ويُسمح للجهاز بتقليل معدل العينة وخفض مستوى الصوت أثناء مرحلة التشغيل.
- [C-1-10] Opus
إذا كانت عمليات تنفيذ الأجهزة تتيح فك ترميز وحدات تخزين الإدخال في ترميز AAC لبث المحتوى المتعدّد القنوات (أي أكثر من قناتين) إلى PCM من خلال وحدة فك ترميز الصوت التلقائية في ترميز AAC في واجهة برمجة التطبيقات android.media.MediaCodec
، يجب أن يكون ما يلي متوافقًا:
- [C-2-1] يجب تنفيذ عملية فك التشفير بدون تقليل القنوات الصوتية (على سبيل المثال، يجب فك تشفير بث AAC بتنسيق 5.0 إلى خمس قنوات بتنسيق PCM، ويجب فك تشفير بث AAC بتنسيق 5.1 إلى ست قنوات بتنسيق PCM).
- [C-2-2] يجب أن تكون البيانات الوصفية للنطاق الديناميكي كما هو محدّد في "Dynamic Range Control
(DRC)" في ISO/IEC 14496-3، ومفاتيح
android.media.MediaFormat
DRC لمحاولة ضبط السلوكيات ذات الصلة بالنطاق الديناميكي لبرنامج ترميز الصوت. تمّت إضافة مفاتيح DRC لتنسيق AAC في الإصدار 21 من واجهة برمجة التطبيقات، وهي:KEY_AAC_DRC_ATTENUATION_FACTOR
وKEY_AAC_DRC_BOOST_FACTOR
وKEY_AAC_DRC_HEAVY_COMPRESSION
وKEY_AAC_DRC_TARGET_REFERENCE_LEVEL
وKEY_AAC_ENCODED_TARGET_LEVEL
. - [SR-1] يُنصح بشدة بأن تستوفي جميع برامج ترميز الصوت بترميز AAC المتطلّبات C-2-1 وC-2-2 أعلاه.
عند فك ترميز الصوت بتنسيق USAC، يجب استيفاء متطلبات MPEG-D (ISO/IEC 23003-4):
- [C-3-1] يجب تفسير البيانات الوصفية لمستوى الصوت وDRC وتطبيقها وفقًا لملف تعريف التحكّم في النطاق الديناميكي MPEG-D DRC المستوى 1.
- [C-3-2] يجب أن يعمل برنامج الترميز وفقًا للإعدادات
التي تم ضبطها باستخدام مفاتيح
android.media.MediaFormat
التالية:KEY_AAC_DRC_TARGET_REFERENCE_LEVEL
وKEY_AAC_DRC_EFFECT_TYPE
.
برامج ترميز الملف الشخصي MPEG-4 AAC وHE AAC وHE AACv2:
- قد تتيح إمكانية التحكّم في مستوى الصوت والنطاق الديناميكي باستخدام الملف الشخصي للتحكّم في النطاق الديناميكي ISO/IEC 23003-4.
إذا كان معيار ISO/IEC 23003-4 متوافقًا وإذا كانت كل من البيانات الوصفية ISO/IEC 23003-4 و ISO/IEC 14496-3 متوفّرة في بث بت تم فك ترميزه، فيُرجى اتّباع الخطوات التالية:
- يجب أن تكون البيانات الوصفية وفقًا لمعيار ISO/IEC 23003-4 لها الأولوية.
يجب أن تتيح جميع برامج ترميز الصوت إخراج ما يلي:
- [C-6-1] إطارات صوتية بتنسيق PCM بسعة 16 بت بترتيب وحدات البايت الأصلي من خلال واجهة برمجة التطبيقات
android.media.MediaCodec
5.1.3. تفاصيل برامج ترميز الصوت
التنسيق/برنامج الترميز | التفاصيل | أنواع الملفات/تنسيقات الحاويات المتوافقة |
---|---|---|
الملف الشخصي لبرنامج الترميز المتقدّم للصوت (AAC) في MPEG-4 (AAC LC) |
إتاحة المحتوى أحادي الصوت/ستيريو/5.0/5.1 بمعدّلات قياسية للتسجيل من 8 إلى 48 كيلوهرتز |
|
الملف الشخصي MPEG-4 HE AAC (AAC+) | إتاحة محتوى صوت أحادي/استيريو/5.0/5.1 بمعدّلات قياسية للبيانات في الملف الصوتي من 16 إلى 48 كيلوهرتز |
|
MPEG-4 HE AACv2 الملف الشخصي (الترميز المحسّن للصوت بترميز متقدّم) |
إتاحة محتوى صوت أحادي/استيريو/5.0/5.1 بمعدّلات قياسية للبيانات في الملف الصوتي من 16 إلى 48 كيلوهرتز |
|
الترميز المتقدّم للصوت بوقت استجابة منخفض (AAC ELD) | إتاحة المحتوى الصوتي الأحادي أو الاستيريو بمعدّلات بيانات عادية تتراوح بين 16 و 48 كيلوهرتز |
|
USAC | إتاحة المحتوى الأحادي/الإستيريو بمعدّلات بيانات عادية في الملف الصوتي تتراوح بين 7.35 و48 كيلوهرتز | MPEG-4 (.mp4 و.m4a) |
AMR-NB | من 4.75 إلى 12.2 كيلوبت في الثانية بمعدل أخذ عينات يبلغ 8 كيلوهرتز | 3GPP (.3gp) |
AMR-WB | 9 معدلات من 6.60 كيلوبت في الثانية إلى 23.85 كيلوبت في الثانية بمعدل أخذ عينات يبلغ 16 كيلوهرتز، كما هو محدّد في AMR-WB، برنامج ترميز الكلام المتعدّد المعدّلات ذي النطاق العريض | 3GPP (.3gp) |
FLAC | لكل من برنامج الترميز وبرنامج فك التشفير: يجب أن يكون وضعَا الصوت الأحادي والاستيريو متوفران على الأقل. يجب أن تكون معدلات أخذ العينات متوافقة مع ما يصل إلى 192 كيلوهرتز، ويجب أن تكون درجة الدقة 16 بت و24 بت متوافقة. يجب أن تكون معالجة بيانات الصوت بتنسيق FLAC بدقة 24 بت متوفرة مع إعدادات الصوت بنقطة عائمة. |
|
MP3 | صوت أحادي/صوت استيريو بمعدّل نقل بيانات ثابت من 8 إلى 320 كيلوبت في الثانية (معدل نقل بيانات ثابت) أو بمعدّل نقل بيانات متغيّر (VBR) |
|
MIDI | نوعا MIDI 0 و1 الإصداران 1 و2 من DLS XMF وMobile XMF التوافق مع تنسيقات نغمات الرنين RTTTL/RTX وOTA وiMelody |
|
Vorbis |
|
|
PCM/WAVE | يجب أن يتيح برنامج ترميز PCM تنسيق PCM الخطي بترميز 16 بت وتنسيق PCM العائم بترميز 16 بت. يجب أن يتيح مستخرج WAVE ترميز PCM الخطي بسعة 16 بت و24 بت و32 بت وتنسيق PCM المتغير بسعة 32 بت (بمعدلات تصل إلى الحد الأقصى للأجهزة). يجب أن تكون معدّلات أخذ العينات متوافقة من 8 كيلوهرتز إلى 192 كيلوهرتز. | WAVE (.wav) |
Opus | فك التشفير: يتيح الجهاز فك تشفير المحتوى الأحادي الصوت والصوت الاستيريو وصوت 5.0 و5.1
بمعدّلات أخذ العينات 8000 و12000 و16000 و24000 و48000 هرتز.
التشفير: يتيح الجهاز تشفير المحتوى الأحادي الصوت والصوت الاستيريو بمعدّلات أخذ العينات 8000 و12000 و16000 و24000 و48000 هرتز. |
|
5.1.4. ترميز الصور
يمكنك الاطّلاع على مزيد من التفاصيل في 5.1.6. تفاصيل برامج ترميز الصور
يجب أن تتيح عمليات تنفيذ الأجهزة ترميز الصور التالية:
- [C-0-1] JPEG
- [C-0-2] ملف بتنسيق PNG
- [C-0-3] WebP
إذا كانت عمليات تنفيذ الأجهزة تتيح ترميز HEIC من خلال android.media.MediaCodec
لنوع الوسائط MIMETYPE_IMAGE_ANDROID_HEIC
،
يجب أن تستوفي المتطلبات التالية:
- [C-1-1] يجب توفير برنامج ترميز HEVC مُسرَّع بالأجهزة ويتوافق مع
BITRATE_MODE_CQ
وضع التحكّم في معدل نقل البيانات وHEVCProfileMainStill
الملف الشخصي وحجم اللقطة 512 × 512 بكسل.
5.1.5. فك ترميز الصور
يمكنك الاطّلاع على مزيد من التفاصيل في 5.1.6. تفاصيل برامج ترميز الصور
يجب أن تتيح عمليات تنفيذ الأجهزة فك ترميز الصور التالية:
- [C-0-1] JPEG
- [C-0-2] GIF
- [C-0-3] ملف بتنسيق PNG
- [C-0-4] BMP
- [C-0-5] WebP
- [C-0-6] ملف خام
إذا كانت عمليات تنفيذ الأجهزة تتيح فك ترميز الفيديو باستخدام HEVC، يجب أن تستوفي الشروط التالية:
- [C-1-1] يجب أن يكون متوافقًا مع فك ترميز صور HEIF (HEIC).
برامج ترميز الصور المتوافقة مع تنسيقات عالية بعمق البت (أكثر من 9 بت لكل قناة):
- [C-2-1] يجب أن يتيح الجهاز عرض تنسيق مكافئ 8 بت إذا طلبه
التطبيق، على سبيل المثال، من خلال ضبط
ARGB_8888
android.graphics.Bitmap
.
5.1.6. تفاصيل برامج ترميز الصور
التنسيق/برنامج الترميز | التفاصيل | أنواع الملفات/تنسيقات الحاويات المتوافقة |
---|---|---|
JPEG | قاعدة + رسوم متحركة | JPEG (.jpg) |
ملف GIF | GIF (.gif) | |
PNG | PNG (.png) | |
BMP | BMP (.bmp) | |
WebP | WebP (.webp) | |
عرض أوّلي | ARW (.arw)، وCR2 (.cr2)، وDNG (.dng)، وNEF (.nef)، وNRW (.nrw)، وORF (.orf)، PEF (.pef)، وRAF (.raf)، وRW2 (.rw2)، وSRW (.srw) | |
HEIF | صورة، مجموعة صور، سلسلة صور | HEIF (.heif) وHEIC (.heic) |
برامج ترميز الصور وفك ترميزها المعروضة من خلال واجهة برمجة التطبيقات MediaCodec
[C-1-1] يجب أن يكون الجهاز متوافقًا مع تنسيق ملف YUV420 8:8:8 المتوافق مع ألوان شاشة عريضة (
COLOR_FormatYUV420Flexible
) حتىCodecCapabilities
.[SR-1] يُنصح بشدة بتوفُّر تنسيق اللون RGB888 لوضع Surface الإدخال.
[C-1-3] يجب أن يكون الجهاز متوافقًا مع أحد تنسيقَي YUV420 8:8:8 المسطح أو شبه المسطح:
COLOR_FormatYUV420PackedPlanar
(المكافئ لCOLOR_FormatYUV420Planar
) أوCOLOR_FormatYUV420PackedSemiPlanar
(المكافئ لCOLOR_FormatYUV420SemiPlanar
). ننصح بشدة باستخدام كليهما.
5.1.7. برامج ترميز الفيديو
- للحصول على جودة مقبولة لخدمات بث الفيديو على الويب ومكالمات الفيديو، يجب أن تستخدم عمليات تنفيذ الأجهزة برنامج ترميز VP8 للأجهزة الذي يستوفي المتطلبات.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن برنامج ترميز أو فك ترميز للفيديو:
[C-1-1] يجب أن تتيح برامج ترميز الفيديو أحجام ذاكرة التخزين المؤقت للبايت في كل من الإدخال والإخراج التي تسمح بأكبر إطار مضغوط وغير مضغوط ممكن وفقًا للمعيار والإعدادات، ولكن بدون تخصيص مساحة زائدة.
[C-1-2] يجب أن تتيح برامج ترميز الفيديو وفك ترميزه استخدام تنسيقات ملفّات YUV420 8:8:8 المرنة للألوان (
COLOR_FormatYUV420Flexible
) حتىCodecCapabilities
.[C-1-3] يجب أن تتيح برامج ترميز الفيديو وفك ترميزه استخدام تنسيق ألوان واحد على الأقل من تنسيقات YUV420 8:8:8 المسطحة أو شبه المسطحة:
COLOR_FormatYUV420PackedPlanar
(المكافئCOLOR_FormatYUV420Planar
) أوCOLOR_FormatYUV420PackedSemiPlanar
(المكافئCOLOR_FormatYUV420SemiPlanar
). ننصح بشدة باستخدام كليهما.[SR-1] يُنصح بشدة بأن تتيح برامج ترميز الفيديو وفك ترميزه استخدام أحد التنسيقات التالية على الأقل: تنسيق YUV420 8:8:8 المسطح أو شبه المسطح المحسَّن للأجهزة (YV12 أو NV12 أو NV21 أو تنسيق محسَّن مكافئ من المورّد).
[C-1-5] يجب أن تتيح برامج فك ترميز الفيديو التي تتوافق مع تنسيقات ذات عمق بت مرتفع (9 بت أو أكثر لكل قناة) إخراج تنسيق مكافئ بدقة 8 بت إذا طلب ذلك التطبيق. يجب أن يظهر ذلك من خلال إتاحة تنسيق ألوان YUV420 8:8:8 عبر
android.media.MediaCodecInfo
.
إذا كانت عمليات تنفيذ الأجهزة تعلن عن توافق الملف الشخصي لتقنية HDR من خلال
Display.HdrCapabilities
،
يجب أن تستوفي الشروط التالية:
- [C-2-1] يجب أن يكون متوافقًا مع تحليل البيانات الوصفية الثابتة ذات تنسيق HDR ومعالجتها.
إذا كانت عمليات تنفيذ الأجهزة تعلن عن توفّر ميزة إعادة التحميل أثناء التشغيل من خلال FEATURE_IntraRefresh
في فئة MediaCodecInfo.CodecCapabilities
، يجب استيفاء الشروط التالية:
- [C-3-1] يجب أن تتيح فترات التحديث في النطاق من 10 إلى 60 لقطة و تعمل بدقة في غضون% 20 من فترة التحديث التي تم ضبطها.
ما لم يحدّد التطبيق خلاف ذلك باستخدام مفتاح التنسيق KEY_COLOR_FORMAT
، يجب أن تستوفي آليات تنفيذ برامج فك ترميز الفيديو الشروط التالية:
- [C-4-1] يجب ضبط الإعداد التلقائي على تنسيق الألوان المحسَّن لشاشة الجهاز في حال الضبط باستخدام إخراج Surface.
- [C-4-2] يجب أن يكون تنسيق اللون التلقائي هو YUV420 8:8:8 المحسَّن لقراءة وحدة المعالجة المركزية (CPU) في حال ضبطه على عدم استخدام إخراج Surface.
5.1.8. قائمة برامج ترميز الفيديو
التنسيق/برنامج الترميز | التفاصيل | أنواع الملفات/تنسيقات الحاويات المتوافقة |
---|---|---|
H.263 |
|
|
H.264 AVC | راجِع الفقرة 5.2 و5.3 للاطّلاع على التفاصيل. |
|
H.265 HEVC | راجِع الفقرة 5.3 لمعرفة التفاصيل. |
|
MPEG-2 | الجودة الرئيسية |
|
MPEG-4 SP |
|
|
VP8 | راجِع الفقرة 5.2 و 5.3 للاطّلاع على التفاصيل. |
|
VP9 | راجِع الفقرة 5.3 لمعرفة التفاصيل. |
|
5.1.9. أمان برامج ترميز الوسائط
يجب أن تضمن عمليات تنفيذ الأجهزة الامتثال لميزات أمان ترميز الوسائط كما هو موضّح أدناه.
يتيح نظام Android استخدام OMX، وهي واجهة برمجة تطبيقات لتسريع تشغيل الوسائط على جميع المنصات، بالإضافة إلى Codec 2.0، وهي واجهة برمجة تطبيقات لتسريع تشغيل الوسائط باستهلاك منخفض للموارد.
إذا كانت عمليات تنفيذ الأجهزة تتيح الوسائط المتعددة، يجب أن:
- [C-1-1] يجب أن يقدّم التطبيق دعمًا لبرامج ترميز الوسائط إما من خلال واجهات برمجة التطبيقات OMX أو Codec 2.0 (أو كليهما) كما هو الحال في مشروع Android Open Source Project، وألا يؤدي إلى إيقاف إجراءات الحماية الأمنية أو التحايل عليها. لا يعني ذلك تحديدًا أنّه يجب أن يستخدم كل ملف ترميز إما واجهة برمجة التطبيقات OMX أو Codec 2.0، بل يجب فقط أن يتوفّر دعم لواحد على الأقل من واجهات برمجة التطبيقات هذه، ويجب أن يتضمّن دعم واجهات برمجة التطبيقات المتاحة إجراءات الحماية الأمنية المتاحة.
- [C-SR-1] يُنصح بشدة بتضمين واجهة Codec 2.0 API.
إذا كانت عمليات تنفيذ الأجهزة لا تتوافق مع واجهة برمجة التطبيقات Codec 2.0، يجب أن تستوفي الشروط التالية:
- [C-2-1] يجب أن يتضمّن برنامج ترميز OMX المعني من "مشروع Android المفتوَح" (إذا كان متاحًا) لكل تنسيق وسائط ونوعه (المشفِّر أو المُشفِّر العكسي) المتوافقَين مع الجهاز.
- [C-2-2] برامج الترميز التي تحمل أسماء تبدأ بـ "OMX.google." يجب أن تستند إلى رمز المصدر في "مشروع Android المفتوح المصدر".
- [C-SR-2] يُنصح بشدة بتشغيل برامج ترميز OMX في عملية ترميز لا يمكنها الوصول إلى برامج تشغيل الأجهزة بخلاف أدوات ربط الذاكرة.
إذا كانت عمليات تنفيذ الأجهزة متوافقة مع واجهة برمجة التطبيقات Codec 2.0، يجب أن تستوفي الشروط التالية:
- [C-3-1] يجب أن يتضمّن البرنامج برنامج ترميز Codec 2.0 المقابل من مشروع Android Open Source Project (إذا كان متاحًا) لكل تنسيق وسائط ونوعها (برنامج ترميز أو فك ترميز) متوافق مع الجهاز.
- [C-3-2] يجب أن تتضمّن برامج الترميز 2.0 برامج الترميز البرمجية في عملية الترميز البرمجي كما هو موضّح في مشروع Android Open Source Project لكي يصبح من الممكن منح إذن الوصول إلى برامج الترميز البرمجية بشكل أكثر تقييدًا.
- [C-3-3] برامج الترميز التي تحمل أسماء تبدأ بـ "c2.android." يجب أن تستند إلى رمز المصدر في "مشروع Android المفتوح المصدر".
5.1.10. تحديد برنامج ترميز الوسائط
إذا كانت عمليات تنفيذ الأجهزة متوافقة مع برامج ترميز الوسائط، فإنّها:
- [C-1-1] يجب أن تعرض القيم الصحيحة لخصائص ترميز الوسائط من خلال واجهة برمجة التطبيقات
MediaCodecInfo
.
ويشمل ذلك على وجه الخصوص:
- [C-1-2] برامج الترميز التي تحمل أسماء تبدأ بـ "OMX." يجب أن تستخدم واجهات برمجة التطبيقات OMX ويكون لها أسماء تتوافق مع إرشادات التسمية في OMX IL.
- [C-1-3] برامج الترميز التي تحمل أسماء تبدأ بـ "c2." يجب استخدام واجهة برمجة التطبيقات Codec 2.0 ويجب أن تتوافق الأسماء مع إرشادات تسمية Codec 2.0 لنظام التشغيل Android.
- [C-1-4] برامج الترميز التي تحمل أسماء تبدأ بـ "OMX.google." أو "c2.android." يجب عدم تصنيفها على أنّها من المورّدين أو مُسرَّعة بالأجهزة.
- [C-1-5] يجب عدم تحديد برامج الترميز التي تعمل في عملية ترميز (للمورّد أو النظام) والتي يمكنها الوصول إلى برامج تشغيل الأجهزة غير أدوات تخصيص الذاكرة وربطها على أنّها برامج فقط.
- [C-1-6] يجب تصنيف برامج الترميز التي لا تتوفّر في مشروع Android Open Source Project أو التي لا تستند إلى رمز المصدر في هذا المشروع على أنّها برامج تابعة لمورّد.
- [C-1-7] يجب أن يتم تصنيف برامج الترميز التي تستخدم ميزة "تسريع الأجهزة" على أنّها مسرَّعة على الأجهزة.
- [C-1-8] يجب ألّا تكون أسماء برامج الترميز مضلِّلة. على سبيل المثال، يجب أن تتيح برامج الترميز المُسمّاة "برامج فك الترميز" فك الترميز، ويجب أن تتيح تلك المُسمّاة "برامج الترميز" التشفير. يجب أن تكون برامج الترميز التي تحمل أسماء تحتوي على تنسيقات الوسائط متوافقة مع هذين التنسيقَين.
إذا كانت آليات تنفيذ الأجهزة متوافقة مع برامج ترميز الفيديو:
- [C-2-1] يجب أن تنشر جميع برامج ترميز الفيديو بيانات معدل عرض اللقطات الذي يمكن تحقيقه للأحجام التالية إذا كانت برامج الترميز متوافقة معها:
الدقة العادية (جودة منخفضة) | الدقة العادية (جودة عالية) | دقة عالية - 720p | دقة عالية - 1080p | دقة فائقة | |
---|---|---|---|---|---|
دقة الفيديو |
|
|
|
1920 × 1080 بكسل (بتنسيق آخر غير MPEG4) | 3840 × 2160 بكسل (HEVC وVP9) |
- [C-2-2] يجب أن تنشر برامج ترميز الفيديو التي يتم تصنيفها على أنّها مسرَّعة على الأجهزة
معلومات نقاط الأداء. ويجب أن يُدرج كلّ منها جميع نقاط الأداء العادية المتوافقة (المدرَجة في واجهة برمجة التطبيقات
PerformancePoint
)، ما لم تكن مضمّنة في نقطة أداء عادية أخرى متوافقة. - بالإضافة إلى ذلك، يجب أن تنشر نقاط أداء إضافية إذا كانت توفّر ميزة تحسين الأداء المستمر في الفيديوهات غير تلك المُدرَجة في النقاط العادية.
5.2. ترميز الفيديو
إذا كانت عمليات تنفيذ الأجهزة تتيح استخدام أيّ برنامج ترميز فيديو وتوفّره للتطبيقات التابعة لجهات خارجية، يجب أن تستوفي الشروط التالية:
- يجب ألا تزيد سرعة نقل البيانات عن معدّل نقل البيانات بنسبة تزيد عن% 15 على مدار نافذتَين متتاليتَين بين فواصل اللقطات الداخلية (اللقطات I).
- يجب ألا تزيد عن معدّل نقل البيانات بنسبة% 100 على مدار فترة زمنية متحركة تبلغ ثانية واحدة.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن شاشة مضمّنة بطول قياسي أفقي لا يقل عن 6.35 سم أو تتضمّن منفذ إخراج فيديو أو تشير إلى توفّر كاميرا من خلال android.hardware.camera.any
علامة الميزة، يجب استيفاء الشروط التالية:
- [C-1-1] يجب أن تتضمّن إتاحة استخدام أحد برامج ترميز الفيديو VP8 أو H.264 على الأقل، وأن تكون متاحة للتطبيقات التابعة لجهات خارجية.
- يجب أن يكون متوافقًا مع برنامجَي ترميز الفيديو VP8 وH.264، وأن يكون متاحًا للتطبيقات التابعة لجهات خارجية.
إذا كانت عمليات تنفيذ الأجهزة تتيح استخدام أي من برامج ترميز الفيديو H.264 أو VP8 أو VP9 أو HEVC وتوفّرها للتطبيقات التابعة لجهات خارجية، يجب استيفاء الشروط التالية:
- [C-2-1] يجب أن تتيح إمكانية ضبط معدلات نقل البيانات ديناميكيًا.
- يجب أن يكون متوافقًا مع عدد اللقطات المتغير في الثانية، حيث يجب أن يحدِّد برنامج ترميز الفيديو مدّة اللقطة الفورية استنادًا إلى الطوابع الزمنية لمخازن الوسائط المؤقتة للدخل، ويجب أن يخصّص حزمة البيانات استنادًا إلى مدة اللقطة هذه.
إذا كانت عمليات تنفيذ الأجهزة متوافقة مع برنامج ترميز الفيديو MPEG-4 SP وتوفره للتطبيقات التابعة لجهات خارجية، يجب أن تستوفي المتطلبات التالية:
- يجب أن تتيح معدلات نقل بيانات قابلة للضبط ديناميكيًا لبرنامج الترميز المتوافق.
إذا كانت عمليات تنفيذ الأجهزة توفّر برامج ترميز للصور أو الفيديوهات مسرّعة بالأجهزة،
وتتيح كاميرا واحدة أو أكثر من كاميرات الأجهزة المُرفَقة أو القابلة للتوصيل من خلال
واجهات برمجة تطبيقات android.camera
:
- [C-4-1] يجب أن تتوافق جميع برامج ترميز الفيديو والصور المُسرَّعة للأجهزة مع ترميز اللقطات من كاميرات الأجهزة.
- يجب أن تتيح ترميز اللقطات من كاميرات الأجهزة من خلال جميع برامج ترميز الفيديو أو الصور.
إذا كانت عمليات تنفيذ الأجهزة توفّر ترميز HDR، يجب أن تستوفي الشروط التالية:
- [C-SR-1] يُنصح بشدة بتوفير مكوّن إضافي لواجهة برمجة التطبيقات لتحويل الترميز بسلاسة من تنسيق HDR إلى تنسيق SDR.
5.2.1. H.263
إذا كانت عمليات تنفيذ الأجهزة متوافقة مع برامج ترميز H.263 وتوفّرها للتطبيقات التابعة لجهات خارجية، يجب استيفاء الشروط التالية:
- [C-1-1] يجب أن يكون الجهاز متوافقًا مع المستوى 45 من "ملف المرجع".
- يجب أن تتيح معدلات نقل بيانات قابلة للضبط ديناميكيًا لبرنامج الترميز المتوافق.
5.2.2. H.264
إذا كانت عمليات تنفيذ الأجهزة متوافقة مع برنامج ترميز H.264، يجب أن تستوفي الشروط التالية:
- [C-1-1] يجب أن يكون متوافقًا مع المستوى 3 من "ملف المرجع". ومع ذلك، فإنّ إتاحة ASO (ترتيب الشرائح التعسّفي) وFMO (ترتيب وحدات الماكروبلوك المرن) وRS (شرائح زائدة) هو اختياري. بالإضافة إلى ذلك، للحفاظ على التوافق مع أجهزة Android الأخرى، ننصح بعدم استخدام أدوات الترميز لميزة ASO وFMO وRS في الملف الشخصي الأساسي.
- [C-1-2] يجب أن يكون الجهاز متوافقًا مع الملفات الشخصية لترميز الفيديو بدقة عادية (SD) المذكورة في الجدول التالي.
- يجب أن يكون متوافقًا مع المستوى 4 من الملف الشخصي الرئيسي.
- يجب أن تتيح ملفات التعريف هذه ترميز الفيديوهات العالية الدقة كما هو موضح في الجدول التالي.
إذا أبلغت عمليات تنفيذ الأجهزة عن توفّر برنامج ترميز H.264 للفيديوهات بدقة 720p أو 1080p من خلال واجهات برمجة تطبيقات الوسائط، يعني ذلك ما يلي:
- [C-2-1] يجب أن يكون متوافقًا مع الملفات الشخصية لتشفير الفيديو في الجدول التالي.
الدقة العادية (جودة منخفضة) | الدقة العادية (جودة عالية) | دقة عالية - 720p | دقة عالية - 1080p | |
---|---|---|---|---|
دقة الفيديو | 320 × 240 بكسل | 720 × 480 بكسل | 1280 × 720 بكسل | 1920 × 1080 بكسل |
عدد اللقطات في الثانية في الفيديو | 20 لقطة في الثانية | 30 إطارًا في الثانية | 30 إطارًا في الثانية | 30 إطارًا في الثانية |
معدّل نقل بيانات الفيديو | 384 كيلوبت في الثانية | 2 ميغابت في الثانية | 4 ميغابت في الثانية | 10 ميغابت في الثانية |
5.2.3. VP8
إذا كانت عمليات تنفيذ الأجهزة متوافقة مع برنامج ترميز VP8، يجب أن تستوفي الشروط التالية:
- [C-1-1] يجب أن يكون متوافقًا مع ملفات تعريف ترميز الفيديوهات بدقة عادية.
- يجب أن تتوافق مع الملفات الشخصية التالية لترميز الفيديوهات العالية الدقة.
- [C-1-2] يجب أن تتيح كتابة ملفات Matroska WebM.
- يجب أن يوفّر برنامج ترميز VP8 للأجهزة يستوفي متطلبات ترميز الأجهزة في مشروع WebM RTC، لضمان جودة مقبولة لخدمات بث الفيديو على الويب واجتماعات الفيديو.
إذا أبلغت عمليات تنفيذ الأجهزة عن توفّر ترميز VP8 للفيديوهات بدقة 720p أو 1080p من خلال واجهات برمجة التطبيقات الخاصة بالوسائط، يجب استيفاء الشروط التالية:
- [C-2-1] يجب أن يكون متوافقًا مع الملفات الشخصية لتشفير الفيديو في الجدول التالي.
الدقة العادية (جودة منخفضة) | الدقة العادية (جودة عالية) | دقة عالية - 720p | دقة عالية - 1080p | |
---|---|---|---|---|
دقة الفيديو | 320 × 180 بكسل | 640 × 360 بكسل | 1280 × 720 بكسل | 1920 × 1080 بكسل |
عدد اللقطات في الثانية في الفيديو | 30 إطارًا في الثانية | 30 إطارًا في الثانية | 30 إطارًا في الثانية | 30 إطارًا في الثانية |
معدّل نقل بيانات الفيديو | 800 كيلوبت في الثانية | 2 ميغابت في الثانية | 4 ميغابت في الثانية | 10 ميغابت في الثانية |
5.2.4. VP9
إذا كانت عمليات تنفيذ الأجهزة متوافقة مع برنامج ترميز VP9، يجب أن تستوفي الشروط التالية:
- [C-1-2] يجب أن يكون متوافقًا مع الملف الشخصي 0، المستوى 3.
- [C-1-1] يجب أن تتيح كتابة ملفات Matroska WebM.
- [C-1-3] يجب إنشاء بيانات CodecPrivate.
- يجب أن تتيح الملفات الشخصية لفك ترميز المحتوى بدقة عالية كما هو موضّح في الجدول التالي.
- [C-SR-1] يُنصح بشدة بتوفير ملفات تعريف فك ترميز الفيديوهات بدقة عالية كما هو موضح في الجدول التالي في حال توفّر برنامج ترميز للأجهزة.
دقة عادية | دقة عالية - 720p | دقة عالية - 1080p | دقة فائقة | |
---|---|---|---|---|
دقة الفيديو | 720 × 480 بكسل | 1280 × 720 بكسل | 1920 × 1080 بكسل | 3840 × 2160 بكسل |
عدد اللقطات في الثانية في الفيديو | 30 إطارًا في الثانية | 30 إطارًا في الثانية | 30 إطارًا في الثانية | 30 إطارًا في الثانية |
معدّل نقل بيانات الفيديو | 1.6 ميغابت في الثانية | 4 ميغابت في الثانية | 5 ميغابت في الثانية | 20 ميغابت في الثانية |
إذا كانت عمليات تنفيذ الأجهزة تدّعي أنّها متوافقة مع الملف الشخصي 2 أو الملف الشخصي 3 من خلال Media APIs:
- إنّ إتاحة التنسيق 12 بت اختيارية.
5.2.5. H.265
إذا كانت عمليات تنفيذ الأجهزة متوافقة مع برنامج ترميز H.265، يجب أن تستوفي الشروط التالية:
- [C-1-1] يجب أن يكون الجهاز متوافقًا مع المستوى 3 من "الملف الشخصي الرئيسي".
- يجب أن تكون متوافقة مع الملفات الشخصية لترميز المحتوى بدقة عالية كما هو موضّح في الجدول التالي.
- [C-SR-1] يُنصح بشدة بتوفير ملفات تعريف ترميز بدقة عالية كما هو موضح في الجدول التالي في حال توفّر برنامج ترميز للأجهزة.
دقة عادية | دقة عالية - 720p | دقة عالية - 1080p | دقة فائقة | |
---|---|---|---|---|
دقة الفيديو | 720 × 480 بكسل | 1280 × 720 بكسل | 1920 × 1080 بكسل | 3840 × 2160 بكسل |
عدد اللقطات في الثانية في الفيديو | 30 إطارًا في الثانية | 30 إطارًا في الثانية | 30 إطارًا في الثانية | 30 إطارًا في الثانية |
معدّل نقل بيانات الفيديو | 1.6 ميغابت في الثانية | 4 ميغابت في الثانية | 5 ميغابت في الثانية | 20 ميغابت في الثانية |
5.3. فك ترميز الفيديو
إذا كانت عمليات تنفيذ الأجهزة متوافقة مع برامج ترميز VP8 أو VP9 أو H.264 أو H.265، يجب أن تستوفي الشروط التالية:
- [C-1-1] يجب أن تتيح إمكانية تغيير دقة الفيديو الديناميكية ومعدل عرض اللقطات من خلال واجهات برمجة التطبيقات العادية لنظام التشغيل Android ضمن البث نفسه لجميع برامج ترميز VP8 وVP9 وH.264 وH.265 في الوقت الفعلي وبحد أقصى دقة يتيحها كل برنامج ترميز على الجهاز.
5.3.1. MPEG-2
إذا كانت عمليات تنفيذ الأجهزة متوافقة مع برامج ترميز MPEG-2، يجب أن تستوفي الشروط التالية:
- [C-1-1] يجب أن يكون متوافقًا مع المستوى العالي للملف الشخصي الرئيسي.
5.3.2. H.263
إذا كانت عمليات تنفيذ الأجهزة متوافقة مع برامج فك ترميز H.263، يجب أن تستوفي الشروط التالية:
- [C-1-1] يجب أن يكون متوافقًا مع المستوى 30 والمستوى 45 من الملف الشخصي الأساسي.
5.3.3. MPEG-4
في حال استخدام أجهزة مع برامج ترميز MPEG-4، يجب:
- [C-1-1] يجب أن يكون متوافقًا مع المستوى 3 من الملف الشخصي البسيط.
5.3.4. H.264
إذا كانت عمليات تنفيذ الأجهزة متوافقة مع برامج فك ترميز H.264، يتم تنفيذ ما يلي:
- [C-1-1] يجب أن يكون الجهاز متوافقًا مع المستوى 3.1 من الملف الشخصي الرئيسي والملف الشخصي الأساسي. إنّ إتاحة ميزة ASO (ترتيب الشرائح التعسّفي) وFMO (ترتيب الوحدات المجمّعة المرنة) وRS (شرائح زائدة) هو اختياري.
- [C-1-2] يجب أن يكون الجهاز قادرًا على فك ترميز الفيديوهات باستخدام ملفات تعريف الدقة المتوسّطة (SD) المُدرَجة في الجدول التالي والمُشفَّرة باستخدام ملف التعريف الأساسي وملف التعريف الرئيسي المستوى 3.1 (بما في ذلك 720p30).
- يجب أن تكون قادرة على فك ترميز الفيديوهات باستخدام الملفات الشخصية بدقة عالية (HD) كما هو موضّح في الجدول التالي.
إذا كان الارتفاع الذي يتم الإبلاغ عنه من خلال طريقة Display.getSupportedModes()
يساوي دقة الفيديو أو يزيد عنها، تكون عمليات تنفيذ الأجهزة:
- [C-2-1] يجب أن يكون الجهاز متوافقًا مع الملفات الشخصية لفك ترميز الفيديوهات بدقة 720p عالية الدقة في الجدول التالي.
- [C-2-2] يجب أن يكون متوافقًا مع ملفات تعريف فك ترميز الفيديوهات بدقة عالية 1080p الواردة في جدول التوافق التالي.
الدقة العادية (جودة منخفضة) | الدقة العادية (جودة عالية) | دقة عالية - 720p | دقة عالية - 1080p | |
---|---|---|---|---|
دقة الفيديو | 320 × 240 بكسل | 720 × 480 بكسل | 1280 × 720 بكسل | 1920 × 1080 بكسل |
عدد اللقطات في الثانية في الفيديو | 30 إطارًا في الثانية | 30 إطارًا في الثانية | 60 لقطة في الثانية | 30 لقطة في الثانية (60 لقطة في الثانيةعلى التلفزيون) |
معدّل نقل بيانات الفيديو | 800 كيلوبت في الثانية | 2 ميغابت في الثانية | 8 ميغابت في الثانية | 20 ميغابت في الثانية |
5.3.5. H.265 (HEVC)
إذا كانت عمليات تنفيذ الأجهزة متوافقة مع برنامج ترميز H.265، يجب أن تستوفي الشروط التالية:
- [C-1-1] يجب أن يكون الجهاز متوافقًا مع المستوى 3 من الفئة الرئيسية لملف التعريف الرئيسي وملفات تعريف فك ترميز الفيديوهات بدقة عادية كما هو موضّح في الجدول التالي.
- يجب أن تتيح الملفات الشخصية لفك ترميز المحتوى بدقة عالية كما هو موضّح في الجدول التالي.
- [C-1-2] يجب أن يكون الجهاز متوافقًا مع الملفات الشخصية لفك ترميز المحتوى بدقة عالية كما هو موضّح في الجدول التالي في حال توفّر وحدة فك ترميز للأجهزة.
إذا كان الارتفاع الذي يتم تسجيله باستخدام الطريقة Display.getSupportedModes()
يساوي درجة دقة الفيديو أو يتجاوزها، يتم تنفيذ ما يلي:
- [C-2-1] يجب أن تتيح عمليات تنفيذ الأجهزة فك ترميز أحد ملفّات تعريف H.265 أو VP9 بدقة 720 و1080 وUHD على الأقل.
الدقة العادية (جودة منخفضة) | الدقة العادية (جودة عالية) | دقة عالية - 720p | دقة عالية - 1080p | دقة فائقة | |
---|---|---|---|---|---|
دقة الفيديو | 352 × 288 بكسل | 720 × 480 بكسل | 1280 × 720 بكسل | 1920 × 1080 بكسل | 3840 × 2160 بكسل |
عدد اللقطات في الثانية في الفيديو | 30 إطارًا في الثانية | 30 إطارًا في الثانية | 30 إطارًا في الثانية | 30/60 لقطة في الثانية (60 لقطة في الثانيةتلفزيون مزوّد بميزة فك ترميز H.265 على مستوى الأجهزة) | 60 لقطة في الثانية |
معدّل نقل بيانات الفيديو | 600 كيلوبت في الثانية | 1.6 ميغابت في الثانية | 4 ميغابت في الثانية | 5 ميغابت في الثانية | 20 ميغابت في الثانية |
إذا كانت عمليات تنفيذ الأجهزة تدّعي أنّها متوافقة مع ملف HDR من خلال واجهات برمجة التطبيقات Media APIs:
- [C-3-1] يجب أن تقبل عمليات تنفيذ الأجهزة البيانات الوصفية المطلوبة لتقنية HDR من التطبيق، وأن تتيح استخراج البيانات الوصفية المطلوبة لتقنية HDR وعرضها من بث البتات و/أو الحاوية.
- [C-3-2] يجب أن تعرِض عمليات تنفيذ الأجهزة محتوى HDR بشكل صحيح على شاشة الجهاز أو على منفذ إخراج فيديو عادي (مثل منفذ HDMI).
5.3.6. VP8
إذا كانت عمليات تنفيذ الأجهزة متوافقة مع برنامج ترميز VP8، يجب أن تستوفي الشروط التالية:
- [C-1-1] يجب أن يكون الجهاز متوافقًا مع الملفات الشخصية لفك ترميز الفيديوهات بدقة عادية الواردة في الجدول التالي.
- يجب استخدام برنامج ترميز VP8 للأجهزة الذي يستوفي المتطلبات.
- يجب أن تتيح الملفات الشخصية لفك ترميز المحتوى بدقة عالية في الجدول التالي.
إذا كان الارتفاع الذي تم قياسه باستخدام الطريقة Display.getSupportedModes()
يساوي
أو أكبر من درجة دقة الفيديو، عليك اتّباع الخطوات التالية:
- [C-2-1] يجب أن تتوافق عمليات تنفيذ الأجهزة مع الملفات الشخصية بدقة 720p في جدول التوافق التالي.
- [C-2-2] يجب أن تتوافق عمليات تنفيذ الأجهزة مع الملفات الشخصية بدقة 1080p في الجدول التالي.
الدقة العادية (جودة منخفضة) | الدقة العادية (جودة عالية) | دقة عالية - 720p | دقة عالية - 1080p | |
---|---|---|---|---|
دقة الفيديو | 320 × 180 بكسل | 640 × 360 بكسل | 1280 × 720 بكسل | 1920 × 1080 بكسل |
عدد اللقطات في الثانية في الفيديو | 30 إطارًا في الثانية | 30 إطارًا في الثانية | 30 لقطة في الثانية (60 لقطة في الثانيةعلى التلفزيون) | 30 (60 لقطة في الثانيةتلفزيون) |
معدّل نقل بيانات الفيديو | 800 كيلوبت في الثانية | 2 ميغابت في الثانية | 8 ميغابت في الثانية | 20 ميغابت في الثانية |
5.3.7. VP9
إذا كانت عمليات تنفيذ الأجهزة متوافقة مع برنامج ترميز VP9، يجب أن تستوفي الشروط التالية:
- [C-1-1] يجب أن يكون الجهاز متوافقًا مع الملفات الشخصية لفك ترميز الفيديوهات بدقة عادية كما هو موضّح في الجدول التالي.
- يجب أن تتيح الملفات الشخصية لفك ترميز المحتوى بدقة عالية كما هو موضّح في الجدول التالي.
إذا كانت عمليات تنفيذ الأجهزة متوافقة مع برنامج ترميز VP9 وبرنامج فك ترميز الأجهزة:
- [C-2-1] يجب أن يكون الجهاز متوافقًا مع الملفات الشخصية لفك ترميز المحتوى بدقة عالية كما هو موضّح في الجدول التالي.
إذا كان الارتفاع الذي يتم تسجيله باستخدام الطريقة Display.getSupportedModes()
يساوي درجة دقة الفيديو أو يتجاوزها، يتم تنفيذ ما يلي:
- [C-3-1] يجب أن تتيح عمليات تنفيذ الأجهزة استخدام أحد تنسيقَي VP9 أو H.265 أو كليهما لفك ترميز الملفات بتنسيقات 720p و1080p وUHD.
الدقة العادية (جودة منخفضة) | الدقة العادية (جودة عالية) | دقة عالية - 720p | دقة عالية - 1080p | دقة فائقة | |
---|---|---|---|---|---|
دقة الفيديو | 320 × 180 بكسل | 640 × 360 بكسل | 1280 × 720 بكسل | 1920 × 1080 بكسل | 3840 × 2160 بكسل |
عدد اللقطات في الثانية في الفيديو | 30 إطارًا في الثانية | 30 إطارًا في الثانية | 30 إطارًا في الثانية | 30 لقطة في الثانية (60 لقطة في الثانيةعلى التلفزيون المزوّد بميزة فك ترميز VP9 على مستوى الأجهزة) | 60 لقطة في الثانية |
معدّل نقل بيانات الفيديو | 600 كيلوبت في الثانية | 1.6 ميغابت في الثانية | 4 ميغابت في الثانية | 5 ميغابت في الثانية | 20 ميغابت في الثانية |
إذا كانت عمليات تنفيذ الأجهزة تدّعي أنّها متوافقة مع VP9Profile2
أو VP9Profile3
من خلال واجهات برمجة تطبيقات الوسائط 'CodecProfileLevel':
- إنّ إتاحة التنسيق 12 بت اختيارية.
إذا كانت عمليات تنفيذ الأجهزة تدّعي أنّها متوافقة مع أحد الملفات الشخصية للمحتوى بدقة عالية الديناميكية (VP9Profile2HDR
أو
VP9Profile2HDR10Plus
أو VP9Profile3HDR
أو VP9Profile3HDR10Plus
) من خلال
واجهات برمجة تطبيقات الوسائط:
- [C-4-1] يجب أن تقبل عمليات تنفيذ الأجهزة البيانات الوصفية المطلوبة لميزة HDR
(
KEY_HDR_STATIC_INFO
لجميع الملفات الشخصية لميزة HDR، بالإضافة إلى 'KEY_HDR10_PLUS_INFO' لملفّات HDR10Plus الشخصية) من التطبيق. ويجب أن تتيح أيضًا استخراج البيانات الوصفية المطلوبة لتقنية HDR وإخراجها من بث البتات و/أو الحاوية. - [C-4-2] يجب أن تعرض عمليات تنفيذ الأجهزة محتوى HDR بشكل صحيح على شاشة الجهاز أو على منفذ إخراج فيديو عادي (مثل منفذ HDMI).
5.3.8. Dolby Vision
إذا كانت عمليات تنفيذ الأجهزة تعلن عن توافقها مع وحدة ترميز Dolby Vision من خلال
HDR_TYPE_DOLBY_VISION
، يجب استيفاء الشروط التالية:
- [C-1-1] يجب توفير أداة استخراج متوافقة مع تقنية Dolby Vision.
- [C-1-2] يجب أن يعرض الجهاز محتوى Dolby Vision بشكل صحيح على شاشة الجهاز أو على منفذ إخراج فيديو عادي (مثل منفذ HDMI).
- [C-1-3] يجب ضبط فهرس المقطع الصوتي للطبقات الأساسية المتوافقة مع الإصدارات القديمة (إذا كانت متوفّرة) ليكون مطابقًا لفهرس المقطع الصوتي لطبقة Dolby Vision المجمّعة.
5.3.9. AV1
إذا كانت عمليات تنفيذ الأجهزة متوافقة مع برنامج ترميز AV1، فإنّها:
- [C-1-1] يجب أن يكون متوافقًا مع الملف الشخصي 0، بما في ذلك المحتوى بدقة 10 بت.
5.4. تسجيل الصوت
على الرغم من أنّ بعض المتطلبات الموضّحة في هذا القسم مُدرَجة على أنّها مطلوبة منذ Android 4.3، من المخطّط أن يتم تعديل تعريف التوافق في الإصدارات المستقبلية ليصبح "يجب". ننصح بشدة بأن تستوفي أجهزة Android الحالية والجديدة هذه المتطلبات المُدرجة ضمن "يجب"، وإلا لن تتمكّن من التوافق مع Android عند الترقية إلى الإصدار القادم.
5.4.1. معلومات حول تسجيل الصوت الخام والميكروفون
إذا كانت عمليات تنفيذ الأجهزة تعرِض android.hardware.microphone
، يعني ذلك ما يلي:
[C-1-1] يجب أن تسمح بتسجيل محتوى صوتي أولي بالخصائص التالية:
- التنسيق: Linear PCM، بسعة 16 بت
- معدّلات أخذ العينات: 8000 و11025 و16000 و44100 و48000 هرتز
- القنوات: صوت أحادي
يجب أن تسمح بتسجيل محتوى صوتي أوليّ بالخصائص التالية:
- التنسيق: Linear PCM و16 بت و24 بت
- معدّلات أخذ العينات: 8000 و11025 و16000 و22050 و24000 و32000 و44100 48000 هرتز
- القنوات: عدد القنوات يساوي عدد الميكروفونات في الجهاز
[C-1-2] يجب تسجيل المحتوى بمعدّلات أعلى من معدّلات أخذ العينات بدون زيادة معدّل أخذ العينات.
[C-1-3] يجب أن يتضمّن فلترًا مناسبًا لإزالة التمويه عند تسجيل معدلات أخذ العينات المذكورة أعلاه باستخدام ميزة "تقليل العينة".
يجب أن تسمح بتسجيل محتوى صوتي خام بجودة راديو AM وDVD، ويعني ذلك السمات التالية:
- التنسيق: Linear PCM، بسعة 16 بت
- معدّلات أخذ العينات: 22050 و48000 هرتز
- القنوات: صوت استيريو
[C-1-4] يجب الالتزام بواجهة برمجة التطبيقات
MicrophoneInfo
وملء معلومات الميكروفونات المتاحة على الجهاز التي يمكن للتطبيقات التابعة لجهات خارجية الوصول إليها من خلال واجهة برمجة التطبيقاتAudioManager.getMicrophones()
والميكروفونات النشطة حاليًا التي يمكن للتطبيقات التابعة لجهات خارجية الوصول إليها من خلال واجهتَي برمجة التطبيقاتAudioRecord.getActiveMicrophones()
وMediaRecorder.getActiveMicrophones()
. إذا كانت عمليات تنفيذ الأجهزة تسمح بتسجيل محتوى صوتي بدائي بجودة راديو AM وأقراص DVD، يجب أن تستوفي المتطلبات التالية:[C-2-1] يجب تسجيل المحتوى بدون زيادة في معدل أخذ العينات بأي نسبة أعلى من 16000:22050 أو 44100:48000.
[C-2-2] يجب أن يتضمّن فلترًا مناسبًا لإزالة التمويه لأي نوع من عمليات زيادة أو تقليل العينات.
5.4.2. تسجيل الصوت للتعرّف عليه
إذا كانت عمليات تنفيذ الأجهزة تعرِض android.hardware.microphone
، يعني ذلك ما يلي:
- [C-1-1] يجب تسجيل
android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION
مصدر الصوت عند أحد معدّلات أخذ العينات، 44100 و48000. - [C-1-2] يجب إيقاف أي معالجة صوتية للحد من الضوضاء تلقائيًا عند تسجيل بث صوتي من مصدر
AudioSource.VOICE_RECOGNITION
الصوت. - [C-1-3] يجب إيقاف أيّ ميزة تلقائية للتحكّم في مستوى الصوت تلقائيًا عند تسجيل
بثّ صوتي من مصدر الصوت
AudioSource.VOICE_RECOGNITION
. - يجب تسجيل بث الصوت للتعرّف على الصوت مع خصائص اتّساع تقريبية نسبتها ±3 ديسيبل مقابل التردد، وتحديدًا من 100 هرتز إلى 4000 هرتز.
- يجب تسجيل بث الصوت للتعرّف على الصوت مع ضبط حساسية الإدخال بحيث ينتج مصدر طاقة صوتية (SPL) بقدرة 90 ديسيبل عند 1000 هرتز قيمة RMS تبلغ 2500 لعيّنات 16 بت.
- يجب تسجيل بث الصوت لميزة التعرّف على الصوت بحيث تتتبّع مستويات كثافة PCM الصوتية بشكل خطي تغييرات مستوى الضغط الصوتي (SPL) للإدخال على نطاق 30 ديسيبل على الأقل من -18 ديسيبل إلى +12 ديسيبل مقارنةً بمستوى الضغط الصوتي البالغ 90 ديسيبل عند الميكروفون.
- يجب أن يسجِّل بث الصوت الخاص بميزة التعرّف على الصوت مجموع التشوه التوافقي (THD) بنسبة أقل من% 1 عند تردد 1 كيلوهرتز ومستوى إدخال 90 ديسيبل SPL في الميكروفون.
إذا كانت عمليات تنفيذ الأجهزة تُعلن عن تكنولوجيات android.hardware.microphone
وتكنولوجيات معالجة الضوضاء (تقليلها) المُعدّة للتعرّف على الكلام، يجب أن تستوفي المتطلبات التالية:
- [C-2-1] يجب السماح بالتحكّم في هذا المؤثر الصوتي باستخدام واجهة برمجة التطبيقات
android.media.audiofx.NoiseSuppressor
. - [C-2-2] يجب تحديد كل عملية تنفيذ تكنولوجيات
تقليل الضوضاء بشكل فريد من خلال الحقل
AudioEffect.Descriptor.uuid
.
5.4.3. تسجيل لإعادة توجيه التشغيل
تتضمّن فئة android.media.MediaRecorder.AudioSource
مصدر الصوت REMOTE_SUBMIX
.
إذا كانت عمليات تنفيذ الأجهزة تحدّد كلاً من android.hardware.audio.output
و
android.hardware.microphone
، يتم تنفيذ ما يلي:
[C-1-1] يجب تنفيذ مصدر الصوت
REMOTE_SUBMIX
بشكل صحيح لكي تتمكّن التطبيقات من استخدام واجهة برمجة التطبيقاتandroid.media.AudioRecord
لتسجيل المحتوى من مصدر الصوت هذا، وتسجيل مزيج من جميع مصادر الصوت باستثناء ما يلي:AudioManager.STREAM_RING
AudioManager.STREAM_ALARM
AudioManager.STREAM_NOTIFICATION
5.4.4. ميزة "إلغاء الصدى الصوتي"
إذا كانت عمليات تنفيذ الأجهزة تعرِض android.hardware.microphone
، يعني ذلك ما يلي:
- يجب استخدام تقنية إلغاء الصدى الصوتي
(AEC) التي تم ضبطها للتواصل الصوتي وتطبيقها على مسار الالتقاط
عند الالتقاط باستخدام
AudioSource.VOICE_COMMUNICATION
إذا كانت عمليات تنفيذ الأجهزة توفّر ميزة "إلغاء الصدى الصوتي" التي يتم
إدراجها في مسار الصوت الذي يتم تسجيله عند اختيار AudioSource.VOICE_COMMUNICATION
، يتم تنفيذ ما يلي:
- [C-SR-1] يُنصح بشدة بتحديد ذلك من خلال AcousticEchoCanceler طريقة واجهة برمجة التطبيقات AcousticEchoCanceler.isAvailable()
- [C-SR-2] يُنصح بشدة بالسماح بالتحكم في تأثير الصوت هذا باستخدام واجهة برمجة التطبيقات AcousticEchoCanceler.
- [C-SR-3] يُنصح بشدة بتحديد كل عملية تنفيذ لتكنولوجيا AEC بشكل فريد من خلال الحقل AudioEffect.Descriptor.uuid.
5.4.5. التسجيل المتزامن
إذا كانت عمليات تنفيذ الأجهزة تعرِض android.hardware.microphone
، يجب
تنفيذ الالتقاط المتزامن كما هو موضّح في هذا المستند. وعلى وجه التحديد:
- [C-1-1] يجب السماح بالوصول المتزامن إلى الميكروفون من خلال
خدمة تسهيل الاستخدام التي تسجِّل باستخدام
AudioSource.VOICE_RECOGNITION
وتطبيق واحد على الأقل يسجِّل باستخدام أيAudioSource
. - [C-1-2] يجب السماح بالوصول المتزامن إلى الميكروفون من خلال تطبيق pre-installed
يحمل دور "مساعد Google" وتطبيق واحد على الأقل
يستخدم أي
AudioSource
باستثناءAudioSource.VOICE_COMMUNICATION
أوAudioSource.CAMCORDER
. - [C-1-3] يجب كتم صوت تسجيل الصوت لأي تطبيق آخر، باستثناء
خدمة تسهيل الاستخدام، عندما يكون أحد التطبيقات يُسجّل باستخدام
AudioSource.VOICE_COMMUNICATION
أوAudioSource.CAMCORDER
. ومع ذلك، عندما يُسجِّل تطبيق المكالمة عبرAudioSource.VOICE_COMMUNICATION
، يمكن لتطبيق آخر تسجيل المكالمة الصوتية إذا كان تطبيقًا مفوَّضًا (مثبَّتًا مسبقًا) لديه إذنCAPTURE_AUDIO_OUTPUT
. - [C-1-4] إذا كان تطبيقان أو أكثر يسجّلان المحتوى في الوقت نفسه ولم يكن لدى أي من التطبيقَين واجهة مستخدم في أعلى الشاشة، يتلقّى التطبيق الذي بدأ التسجيل مؤخرًا المحتوى الصوتي.
5.4.6. مستويات تضخيم الصوت في الميكروفون
إذا كانت عمليات تنفيذ الأجهزة تعرِض android.hardware.microphone
، يعني ذلك ما يلي:
- يجب أن يُظهر الميكروفون خصائص تقريبية مسطّحة لسعة الإشارة مقابل التردد في نطاق التردد المتوسط: على وجه التحديد ±3 ديسيبل من 100 هرتز إلى 4000 هرتز لكل ميكروفون مستخدَم لتسجيل مصدر ملف صوتي التعرّف على الصوت.
- يجب ضبط حساسية إدخال الصوت بحيث ينتج مصدر نغمة سينوسoidal بتردد 1000 هرتز يتم تشغيله عند مستوى ضغط صوت (SPL) يبلغ 90 ديسيبل استجابة بمتوسط طاقة 2500 لمعاينات 16 بت (أو -22.35 ديسيبل على النطاق الكامل لمعاينات نقطة التنقّل/الدقة المزدوجة) لكل ميكروفون يتم استخدامه لتسجيل مصدر الصوت المخصّص للتعرّف على الكلام.
- [C-SR-1] يُنصح بشدة بعرض مستويات السعة في نطاق التردد المنخفض: على وجه التحديد من ±20 ديسيبل من 5 هرتز إلى 100 هرتز مقارنةً بنطاق التردد المتوسط لكل ميكروفون مستخدَم لتسجيل مصدر الصوت الذي يستند إليه التعرّف على الصوت.
- [C-SR-2] يُنصح بشدة بعرض مستويات السعة في نطاق التردد العالي: على وجه التحديد من ±30 ديسيبل من 4000 هرتز إلى 22 كيلوهرتز مقارنةً بنطاق التردد المتوسط لكل ميكروفون مستخدَم لتسجيل مصدر الصوت لميزة التعرّف على الصوت.
5.5. تشغيل الصوت
يتيح نظام التشغيل Android للتطبيقات تشغيل الصوت من خلال وحدة تحكم خارجية لمخرجات الصوت كما هو موضّح في القسم 7.8.2.
5.5.1. تشغيل الصوت غير المُعالج
إذا كانت عمليات تنفيذ الأجهزة تعرِض android.hardware.audio.output
، يعني ذلك ما يلي:
[C-1-1] يجب أن تسمح بتشغيل المحتوى الصوتي الأوّلي بالخصائص التالية:
- تنسيقات المصدر: Linear PCM و16 بت و8 بت وقيمة عائمة
- القنوات: صوت أحادي وصوت استيريو وإعدادات صالحة للقنوات المتعدّدة بما يصل إلى 8 قنوات
- معدلات أخذ العينات (بالهرتز):
- 8000 و11025 و16000 و22050 و24000 و32000 و44100 و48000 في إعدادات القناة المذكورة أعلاه
- 96000 بصوت أحادي واستيريو
5.5.2. التأثيرات الصوتية
يوفّر Android واجهة برمجة تطبيقات للتأثيرات الصوتية لعمليات التنفيذ على الأجهزة.
إذا كانت عمليات تنفيذ الأجهزة تقدّم بيانًا عن الميزة android.hardware.audio.output
،
يجب أن تستوفي الشروط التالية:
- [C-1-1] يجب أن يتيح التطبيق تنفيذ
EFFECT_TYPE_EQUALIZER
وEFFECT_TYPE_LOUDNESS_ENHANCER
القابلَين للتحكّم من خلالEqualizer
وLoudnessEnhancer
، وهما فئتا فرعيتان من فئة AudioEffect. - [C-1-2] يجب أن تتيح تنفيذ واجهة برمجة التطبيقات لعرض البيانات، والتي يمكن التحكّم فيها من خلال
فئة
Visualizer
. - [C-1-3] يجب أن تتيح تنفيذ
EFFECT_TYPE_DYNAMICS_PROCESSING
التي يمكن التحكّم فيها من خلال فئة فرعية من AudioEffectDynamicsProcessing
. - يجب أن تتيح تنفيذ
EFFECT_TYPE_BASS_BOOST
وEFFECT_TYPE_ENV_REVERB
EFFECT_TYPE_PRESET_REVERB
وEFFECT_TYPE_VIRTUALIZER
التي يمكن التحكّم فيها من خلال الفئات الفرعيةAudioEffect
BassBoost
EnvironmentalReverb
وPresetReverb
وVirtualizer
. - [C-SR-1] يُنصح بشدة بتوفّر تأثيرات بتنسيق النقطة العائمة و قنوات المتعددة.
5.5.3. مستوى صوت إخراج الصوت
عمليات تنفيذ الأجهزة في السيارات:
- يجب أن تسمح بضبط مستوى الصوت
بشكل منفصل لكل بث صوتي باستخدام نوع المحتوى أو الاستخدام على النحو المحدّد
بواسطة AudioAttributes
واستخدام الصوت في السيارة على النحو المحدّد علنًا في
android.car.CarAudioManager
.
5.5.4. إزالة المحتوى الصوتي
إذا كانت عمليات تنفيذ الأجهزة تتيح تشغيل الصوت المُنزَّل، فإنّها:
- [C-SR-1] يُنصح بشدة بقطع محتوى الصوت الذي يتم تشغيله بدون انقطاع عند تحديده من خلال واجهة برمجة التطبيقات AudioTrack gapless API وحاوية الوسائط الخاصة بـ MediaPlayer.
5.6. وقت استجابة الصوت
وقت استجابة الصوت هو الفترة الزمنية التي تستغرقها إشارة الصوت أثناء مرورها عبر النظام. تعتمد العديد من فئات التطبيقات على أوقات استجابة قصيرة لتحقيق تأثيرات صوتية في الوقت الفعلي.
لأغراض هذا القسم، يُرجى استخدام التعريفات التالية:
- وقت استجابة الإخراج الفاصل الزمني بين وقت كتابة التطبيق لإطار من البيانات المُشفَّرة بترميز PCM ووقت عرض الصوت المقابل للبيئة عند محوِّل صوتي على الجهاز أو عندما تغادر الإشارة الجهاز عبر منفذ ويمكن رصدها خارجيًا
- وقت استجابة الإخراج غير المتوفّر في الذاكرة الوقت المستغرَق بين بدء بث الإخراج ووقت عرض الإطار الأول استنادًا إلى الطوابع الزمنية، عندما يكون نظام إخراج الصوت في وضع السكون ومطفأً قبل الطلب
- وقت استجابة الإخراج المستمر وقت استجابة الإخراج للّقطات اللاحقة، بعد أن يبدأ الجهاز بتشغيل الصوت
- وقت استجابة الإدخال: الفاصل الزمني بين وقت عرض الصوت من البيئة إلى الجهاز عند محوِّل صوتي على الجهاز أو إشارة تدخل الجهاز عبر منفذ ووقت قراءة التطبيق للإطار المقابل للبيانات المُشفَّرة بترميز PCM
- فقدان الإدخال الجزء الأول من إشارة الإدخال غير القابلة للاستخدام أو غير المتوفّرة.
- وقت استجابة الإدخال من البداية الوقت المستغرَق بين بدء البث وتلقّي الإطار الصالح الأول، عندما يكون نظام إدخال الصوت في وضع السكون وقد تم إيقافه قبل الطلب
- وقت استجابة إدخال مستمر وقت استجابة الإدخال للّقطات اللاحقة، أثناء تسجيل الجهاز للصوت
- التشويش في إخراج الفيديو غير المشغّل التباين بين القياسات المنفصلة لقيم وقت استجابة الإخراج البطيء
- التشويش في الإدخال غير المُعدّ مسبقًا التباين بين القياسات المنفصلة لقيم وقت استجابة الإدخال البارد
- وقت استجابة مستمر للذهاب والعودة مجموع وقت استجابة الإدخال المتواصل بالإضافة إلى وقت استجابة الإخراج المتواصل بالإضافة إلى فترة تخزين مؤقت واحد تسمح فترة التخزين المؤقت للتطبيق بمعالجة الإشارة والوقت الذي يحتاجه التطبيق للتخفيف من اختلاف مرحلته بين مصادر الإدخال والإخراج.
- واجهة برمجة التطبيقات لصفيف ذاكرة التخزين المؤقت لـ PCM في OpenSL ES مجموعة واجهات برمجة تطبيقات OpenSL ES ذات الصلة بتنسيق PCM ضمن Android NDK
- واجهة برمجة التطبيقات لنظام AAudio الصوتي الأصلي مجموعة واجهتَي برمجة تطبيقات AAudio ضمن Android NDK
- الطابع الزمني: زوج يتألف من موضع إطار نسبي ضمن البث والوقت المقدَّر الذي يدخل فيه هذا الإطار أو يغادر فيه مسار معالجة الصوت على نقطة النهاية المرتبطة راجِع أيضًا AudioTimestamp.
- خطأ انقطاع مؤقت أو قيمة عيّنة غير صحيحة في إشارة الصوت، ويحدث ذلك عادةً بسبب توقّف مؤقت للذاكرة المؤقتة في الإخراج أو تجاوز الذاكرة المؤقتة في الإدخال أو أي مصدر آخر للضوضاء الرقمية أو التناظرية.
- متوسّط الانحراف المطلق متوسّط القيمة المطلقة للانحرافات عن المتوسط لمجموعة من القيم
- وقت استجابة ميزة "النقر للتحدث" الوقت المستغرَق بين النقر على الشاشة وسماع نغمة تم إنشاؤها نتيجةً لذلك النقر على مكبّر الصوت
إذا كانت عمليات تنفيذ الأجهزة تعرِض android.hardware.audio.output
، يجب أن تستوفي
المتطلبات التالية أو تتجاوزها:
- [C-1-1] يجب أن يكون الطابع الزمني الناتج الذي يعرضه كل من AudioTrack.getTimestamp
و
AAudioStream_getTimestamp
دقيقًا بمعدل ± 2 ملي ثانية. - [C-1-2] وقت استجابة الإخراج عند التشغيل على البارد لا يتجاوز 500 ملي ثانية
إذا كانت عمليات تنفيذ الأجهزة تُعلن عن android.hardware.audio.output
، يُنصح بشدة بالتأكّد من استيفاء المتطلبات التالية أو تجاوزها:
- [C-SR-1] يجب أن يكون وقت استجابة الإخراج بدون محتوى 100 ملي ثانية أو أقل على مسار بيانات مكبّر الصوت. ننصح بشدة بالامتثال لهذه المتطلبات الآن على الأجهزة الحالية والجديدة التي تعمل بهذا الإصدار من Android. في إصدار قادم من المنصة، سنشترط أن يكون وقت استجابة الإخراج بدون ذاكرة تخزين مؤقت 200 ملي ثانية أو أقل.
- [C-SR-2] يجب أن يكون وقت استجابة ميزة "النقر للتشغيل" 80 ملي ثانية أو أقل.
- [C-SR-3] الحدّ من التقلّبات في إخراج التشغيل على البارد
- [C-SR-4] يجب أن يكون الطابع الزمني الناتج الذي يعرضه كل من AudioTrack.getTimestamp
و
AAudioStream_getTimestamp
دقيقًا بمعدل ± 1 ملي ثانية.
إذا كانت عمليات تنفيذ الأجهزة تستوفي المتطلبات المذكورة أعلاه، بعد أي عملية قياس أولي، عند استخدام واجهة برمجة التطبيقات AAudio الأصلية للصوت، يجب أن تكون مدة الاستجابة للإخراج المستمر ومدة الاستجابة للإخراج عند بدء التشغيل على جهاز واحد على الأقل متوافق لإخراج الصوت على النحو التالي:
- [C-SR-5] يُنصح بشدة بالإبلاغ عن الصوت المنخفض الاستجابة من خلال تحديد علامة ميزة
android.hardware.audio.low_latency
. - [C-SR-6] يُنصح بشدة باستيفاء متطلبات معالجة الصوت بوقت استجابة منخفض عبر واجهة برمجة التطبيقات AAudio API.
- [C-SR-7] يُنصح بشدة بالتأكّد من أنّ قيم البث التي تعرض
AAUDIO_PERFORMANCE_MODE_LOW_LATENCY
منAAudioStream_getPerformanceMode()
، تكون القيمة التي تعرِضهاAAudioStream_getFramesPerBurst()
أقل من أو مساوية للقيمة التي تعرِضهاandroid.media.AudioManager.getProperty(String)
لمفتاح الموقعAudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER
.
إذا لم تستوفِ عمليات تنفيذ الأجهزة متطلبات الصوت المنخفض الاستجابة من خلال واجهة برمجة التطبيقات AAudio الأصلية للصوت، سيتم تنفيذ ما يلي:
- [C-2-1] يجب عدم الإبلاغ عن توفّر ميزة الصوت بوقت استجابة منخفض.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن android.hardware.microphone
، يجب أن تستوفي
متطلبات الصوت في الإدخال التالية:
- [C-3-1] يجب الحد من الخطأ في الطوابع الزمنية للإدخال، كما تظهر في القيمة التي تعرِضها AudioRecord.getTimestamp أو
AAudioStream_getTimestamp
، إلى ± 2 ملي ثانية. ويشير "الخطأ" هنا إلى الانحراف عن القيمة الصحيحة. - [C-3-2] وقت استجابة الإدخال من حالة السكون 500 ملي ثانية أو أقل
إذا كانت عمليات تنفيذ الأجهزة تتضمّن android.hardware.microphone
، يُنصح بشدة
باستيفائها لمتطلبات الصوت في الإدخال التالية:
- [C-SR-8] وقت استجابة الإدخال بدون تحضير يبلغ 100 ملي ثانية أو أقل عبر مسار بيانات الميكروفون بالنسبة إلى الأجهزة الحالية والجديدة التي تعمل بهذا الإصدار من Android، ننصحك بشدة باستيفاء هذه المتطلبات الآن. في إصدار قادم من المنصة، سنشترط بشكلٍ حاسم أن يكون وقت استجابة الإدخال من حالة السكون 200 ملي ثانية أو أقل.
- [C-SR-9] وقت استجابة مستمر للإدخال يبلغ 30 ملي ثانية أو أقل
- [C-SR-10] الحدّ من الارتعاش في الإدخال غير المُعدّ مسبقًا
- [C-SR-11] يجب الحد من الخطأ في الطوابع الزمنية للدخل، كما تظهر في AudioRecord.getTimestamp
أو
AAudioStream_getTimestamp
، إلى ± 1 ملي ثانية.
إذا كانت عمليات تنفيذ الأجهزة تعرِض android.hardware.audio.output
و
android.hardware.microphone
، فإنّها:
- [C-SR-12] يُنصح بشدة بتحقيق متوسّط وقت استجابة إرسال البيانات واستقبالها المستمر الذي يبلغ 50 ملي ثانية أو أقل على مدار 5 قياسات، مع متوسّط انحراف مطلق أدنى من 10 ملي ثانية، على مسار واحد متوافق على الأقل.
5.7. بروتوكولات الشبكة
يجب أن تتيح عمليات تنفيذ الأجهزة استخدام بروتوكولات شبكة الوسائط لتشغيل الصوت والفيديو على النحو المحدّد في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
لكلّ ترميز وتنسيق حاوية يجب أن يتوافق معهما تنفيذ الجهاز، يجب أن يستوفي تنفيذ الجهاز الشروط التالية:
[C-1-1] يجب أن يكون متوافقًا مع برنامج الترميز أو الحاوية هذاَين عبر بروتوكولَي HTTP وHTTPS.
[C-1-2] يجب أن يكون متوافقًا مع تنسيقات مقاطع الوسائط المقابلة كما هو موضّح في جدول تنسيقات مقاطع الوسائط أدناه باستخدام مسودة بروتوكول البث المباشر باستخدام بروتوكول HTTP، الإصدار 7.
[C-1-3] يجب أن يكون متوافقًا مع تنسيقات حمولة RTSP المقابلة كما هو موضّح في جدول RTSP أدناه. للاطّلاع على الاستثناءات، يُرجى الاطّلاع على حواشي الجدول في القسم 5.1.
تنسيقات مقاطع الوسائط
تنسيقات الشرائح | المراجع | توفُّر برامج الترميز المطلوبة |
---|---|---|
MPEG-2 Transport Stream | ISO 13818 |
برامج ترميز الفيديو:
وMPEG-2. برامج ترميز الصوت:
|
الترميز المتقدّم للصوت مع إطارات ADTS وعلامات ID3 | ISO 13818-7 | راجِع الفقرة 5.1.1 للاطّلاع على تفاصيل حول الترميز المتقدّم للصوت (AAC) وأنواعه. |
WebVTT | WebVTT |
RTSP (RTP وSDP)
اسم الملف الشخصي | المراجع | توفُّر برامج الترميز المطلوبة |
---|---|---|
H264 AVC | RFC 6184 | راجِع القسم 5.1.8 للاطّلاع على تفاصيل عن H264 AVC. |
MP4A-LATM | RFC 6416 | راجِع الفقرة 5.1.3 للاطّلاع على تفاصيل حول الترميز المتقدّم للصوت (AAC) وأنواعه. |
H263-1998 |
RFC 3551 RFC 4629 RFC 2190 |
راجِع الفقرة 5.1.8 للاطّلاع على تفاصيل عن H263. |
H263-2000 | RFC 4629 | راجِع الفقرة 5.1.8 للاطّلاع على تفاصيل عن H263. |
AMR | RFC 4867 | راجِع القسم 5.1.3 للاطّلاع على تفاصيل حول AMR-NB. |
AMR-WB | RFC 4867 | راجِع الفقرة 5.1.3 للاطّلاع على تفاصيل حول AMR-WB. |
MP4V-ES | RFC 6416 | راجِع القسم 5.1.8 للاطّلاع على تفاصيل عن MPEG-4 SP. |
mpeg4-generic | RFC 3640 | راجِع الفقرة 5.1.3 للاطّلاع على تفاصيل حول الترميز المتقدّم للصوت (AAC) وأنواعه. |
MP2T | RFC 2250 | راجِع MPEG-2 Transport Stream ضمن "البث المباشر عبر HTTP" للاطّلاع على التفاصيل. |
5.8. الوسائط الآمنة
إذا كانت عمليات تنفيذ الأجهزة تتيح إخراج الفيديو الآمن وتكون قادرة على إتاحة مساحات العرض الآمنة، يجب أن تستوفي الشروط التالية:
- [C-1-1] يجب الإفصاح عن توافق التطبيق مع
Display.FLAG_SECURE
.
إذا كانت عمليات تنفيذ الأجهزة تعلن عن توافقها مع Display.FLAG_SECURE
و
بروتوكول العرض اللاسلكي، يجب أن تستوفي المتطلبات التالية:
- [C-2-1] يجب تأمين الرابط باستخدام آلية تشفير قوية، مثل HDCP 2.x أو إصدار أحدث للشاشات المتصلة عبر بروتوكولات لاسلكية، مثل Miracast.
إذا كانت عمليات تنفيذ الأجهزة تعلن عن توفّر Display.FLAG_SECURE
و
تتيح استخدام شاشة خارجية سلكية، فإنّها:
- [C-3-1] يجب أن يكون متوافقًا مع معيار HDCP 1.2 أو إصدار أحدث لجميع الشاشات الخارجية التي يتم ربطها من خلال منفذ سلكي يمكن للمستخدم الوصول إليه.
5.9. الواجهة الرقمية للآلات الموسيقية (MIDI)
إذا أبلغت عمليات تنفيذ الأجهزة عن توفّر ميزة android.software.midi
من خلال فئة
android.content.pm.PackageManager
، يعني ذلك ما يلي:
[C-1-1] يجب أن تتوافق مع MIDI عبر جميع عمليات نقل الأجهزة المتوافقة مع MIDI التي توفر اتصالاً عامًا غير MIDI، حيث تكون عمليات النقل هذه:
- وضع مضيف USB، الفقرة 7.7
- MIDI عبر Bluetooth LE في دور مركزي، الفقرة 7.4.3
[C-1-2] يجب أن تتيح نقل MIDI بين التطبيقات (أجهزة MIDI الافتراضية)
[C-1-3] يجب تضمين libamidi.so (دعم MIDI الأصلي)
يجب أن يكون متوافقًا مع وضع MIDI عبر USB الملحق، الفقرة 7.7
5.10. الصوت الاحترافي
إذا أبلغت عمليات تنفيذ الأجهزة عن توفّر ميزة
android.hardware.audio.pro
من خلال فئة
android.content.pm.PackageManager
، يعني ذلك ما يلي:
- [C-1-1] يجب الإبلاغ عن توفّر ميزة
android.hardware.audio.low_latency
. - [C-1-2] يجب أن يكون وقت استجابة إرسال البيانات واستقبالها للصوت بشكل مستمر، كما هو محدّد في الفقرة 5.6 وقت استجابة إرسال البيانات واستقبالها للصوت، 20 ملي ثانية أو أقل ويجب أن يكون 10 ملي ثانية أو أقل على مسار واحد متوافق على الأقل.
- [C-1-3] يجب أن يتضمّن الجهاز منافذ USB متوافقة مع وضع مضيف USB ووضع جهاز USB محيطي.
- [C-1-4] يجب الإبلاغ عن توفّر الميزة
android.software.midi
. - [C-1-5] يجب استيفاء متطلبات وقت الاستجابة والصوت عبر USB باستخدام واجهة برمجة التطبيقات AAudio native audio.
- [C-1-6] يجب أن يكون وقت استجابة الإخراج غير القابل للتقديم أو الإيقاف 200 ملي ثانية أو أقل.
- [C-1-7] يجب أن يكون وقت استجابة الإدخال في وضع "التشغيل لأول مرة" 200 ملي ثانية أو أقل.
- [C-SR-1] يُنصح بشدة باستيفاء أوقات الاستجابة كما هو محدّد في القسم 5.6 وقت استجابة الصوت، والذي يبلغ 20 ملي ثانية أو أقل، على مدار 5 قياسات مع متوسّط انحراف مطلق أقل من 5 ملي ثانية على مسار انتقال الصوت من مكبّر الصوت إلى الميكروفون.
- [C-SR-2] يُنصح بشدة باستيفاء متطلبات Pro Audio لوقت الاستجابة المستمر للصوت في كل اتجاه ووقت الاستجابة عند بدء تشغيل الإدخال ووقت الاستجابة عند بدء تشغيل الإخراج ومتطلبات الصوت عبر USB باستخدام واجهة برمجة التطبيقات AAudio native audio على مسار MMAP.
- [C-SR-3] يُنصح بشدة بتوفير مستوى ثابت من أداء وحدة المعالجة المركزية
أثناء تشغيل الصوت وتغيُّر حمولة وحدة المعالجة المركزية. يجب اختبار ذلك باستخدام تطبيق Android SynthMark.
تستخدِم أداة SynthMark برنامجًا مركبًا يعمل على إطار عمل صوتي اصطناعي
يقيس أداء النظام. يجب تشغيل تطبيق SynthMark باستخدام خيار
"الاختبار المبرمَج" وتحقيق النتائج التالية:
- voicemark.90 >= 32 صوتًا
- latencymark.fixed.little <= 15 msec
- latencymark.dynamic.little <= 50 msec
راجِع مستندات SynthMark للحصول على شرح لمقاييس الأداء.
- يجب تقليل عدم دقة الساعة الصوتية وانحرافها مقارنةً بالوقت العادي.
- من المفترض أن تقلّل هذه الميزة من انحراف ساعة الصوت بالنسبة إلى وحدة المعالجة المركزية
CLOCK_MONOTONIC
عندما يكون كلاهما نشطًا. - يجب تقليل وقت استجابة الصوت عبر محوِّلات الطاقة على الجهاز.
- يجب أن تقلّل من وقت استجابة الصوت عبر الصوت الرقمي عبر USB.
- يجب تسجيل قياسات وقت استجابة الصوت على جميع المسارات.
- يجب تقليل الارتعاش في أوقات إدخال طلب معاودة الاتصال لإكمال ذاكرة التخزين المؤقت للصوت، لأنّ ذلك يؤثر في النسبة المئوية القابلة للاستخدام من معدل نقل البيانات الكامل لوحدة المعالجة المركزية من خلال طلب معاودة الاتصال.
- يجب ألا يتضمّن أي مشاكل في الصوت أثناء الاستخدام العادي وفقًا لوقت الاستجابة المسجَّل.
- يجب ألا يختلف وقت الاستجابة بين القنوات.
- يجب تقليل متوسط وقت استجابة MIDI على جميع عمليات النقل.
- يجب تقليل التباين في وقت استجابة MIDI أثناء التحميل (التشويش) على جميع عمليات النقل.
- يجب أن يوفّر الطوابع الزمنية MIDI دقيقة على جميع عمليات النقل.
- يجب تقليل الضوضاء في إشارة الصوت عبر محوِّلات الطاقة على الجهاز، بما في ذلك الفترة التي تلي التشغيل على البارد مباشرةً.
- يجب أن لا يكون هناك أي فرق في ساعة الصوت بين جانبَي الإدخال والإخراج للنقاط الطرفية المقابلة، عندما يكون كلاهما نشطًا. تشمل أمثلة نقاط النهاية المقابلة الميكروفون ومكبّر الصوت على الجهاز، أو إدخال ومقبس إخراج الصوت.
- يجب أن تعالج عمليات تسجيل الإشعارات عند اكتمال تخزين مؤقت للصوت في جانبَي الإدخال والإخراج للنقاط الطرفية المقابلة في سلسلة المحادثات نفسها عندما يكون كلاهما نشطًا، ويجب إدخال إشعار الإدخال فورًا بعد العودة من إشعار الإخراج. أو إذا لم يكن من الممكن معالجة طلبات الاستدعاء في سلسلة المهام نفسها، أدخِل طلب استدعاء الإخراج بعد وقت قصير من إدخال طلب استدعاء الإدخال للسماح للتطبيق بتحديد توقيت متسق لكل من جانبَي الإدخال والإخراج.
- يجب تقليل الفرق في الطور بين التخزين المؤقت للصوت في HAL لكل من جانبَي الإدخال والإخراج في نقاط النهاية المقابلة.
- يجب أن تقلِّل من وقت استجابة اللمس.
- يجب تقليل التباين في وقت استجابة اللمس أثناء التحميل (التشويش).
- يجب أن يكون وقت الاستجابة من الإدخال باللمس إلى إخراج الصوت أقل من أو مساوياً 40 ملي ثانية.
إذا كانت عمليات تنفيذ الأجهزة تستوفي جميع المتطلبات أعلاه، فإنّها:
- [C-SR-4] يُنصح بشدة بالإبلاغ عن توفّر الميزة
android.hardware.audio.pro
من خلال فئةandroid.content.pm.PackageManager
.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقبس صوت مقاس 3.5 ملم مزوّدًا بأربعة موصلات، يجب استيفاء الشروط التالية:
- [C-2-1] يجب أن يكون متوسّط وقت استجابة إرسال البيانات واستقبالها للصوت بشكل مستمر، كما هو محدّد في الفقرة 5.6 وقت استجابة إرسال البيانات واستقبالها للصوت، 20 ملي ثانية أو أقل، على مدار 5 قياسات مع متوسّط انحراف مطلق أقل من 5 ملي ثانية على مدار مسار مقبس الصوت.
- [C-SR-5] يُنصح بشدة بالالتزام بقسم مواصفات الجهاز الجوّال (مقبس) في مواصفات سماعة الرأس السلكية للصوت (الإصدار 1.1).
إذا كانت عمليات تنفيذ الأجهزة لا تتضمّن مقبس صوت 3.5 ملم مزوّدًا بأربعة موصلات وتتضمّن منافذ USB متوافقة مع وضع مضيف USB، يجب استيفاء الشروط التالية:
- [C-3-1] يجب تنفيذ فئة الصوت في USB.
- [C-3-2] يجب أن يكون متوسّط وقت استجابة الصوت المستمر لإرسال البيانات واستقبالها هو 25 ملي ثانية أو أقل، على مدار 5 قياسات مع متوسّط انحراف مطلق أدنى من 5 ملي ثانية عبر منفذ وضع مضيف USB باستخدام فئة الصوت في USB. (يمكن قياس ذلك باستخدام محوِّل USB-3.5 ملم وجهاز تحكم بديل لإعادة توجيه الصوت ، أو باستخدام واجهة صوت USB مع كابلات توصيل تربط المدخلات بالمخارج).
- [C-SR-6] يُنصح بشدة بتوفير إمكانية نقل البيانات في كل من الاتجاهين في ما يصل إلى 8 قنوات في كل اتجاه، بمعدّل أخذ عينات يبلغ 96 كيلوهرتز وعمق 24 أو 32 بت، عند استخدامها مع أجهزة صوتية USB خارجية تتوافق أيضًا مع هذه المتطلبات.
- [C-SR-7] يُنصح بشدة باستيفاء هذه المجموعة من المتطلبات باستخدام واجهة برمجة التطبيقات الأصلية للصوت AAudio على مسار MMAP.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ HDMI، يجب أن تستوفي المتطلبات التالية:
- يجب أن يكون الجهاز متوافقًا مع إخراج الصوت الاستيريو وثماني قنوات بمعدل بت 20 أو 24 بت و192 كيلوهرتز بدون فقدان عمق البت أو إعادة أخذ العينات، في إعداد واحد على الأقل.
5.11. التقاط بيانات "لم تتمّ المعالجة"
يتيح نظام التشغيل Android تسجيل الصوت غير المعالج من خلال مصدر الصوت
android.media.MediaRecorder.AudioSource.UNPROCESSED
. في
OpenSL ES، يمكن الوصول إليه باستخدام الإعداد المُسبَق للتسجيل
SL_ANDROID_RECORDING_PRESET_UNPROCESSED
.
إذا كانت عمليات تنفيذ الأجهزة تهدف إلى إتاحة مصدر الصوت غير المعالج للتطبيقات التابعة لجهات خارجية، يجب أن تستوفي المتطلبات التالية:
[C-1-1] يجب الإبلاغ عن مدى التوفّر من خلال
android.media.AudioManager
السمة PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED.[C-1-2] يجب أن يُظهر الجهاز خصائص تقريبية مسطّحة لسعة النبضة في مقابل التردد في نطاق التردد المتوسط: على وجه التحديد ±10 ديسيبل من 100 هرتز إلى 7000 هرتز لكل ميكروفون مستخدَم لتسجيل مصدر الصوت غير المعالج.
[C-1-3] يجب أن يعرض مستويات الجهارة في ملف الاختبار النطاق المنخفض للترددات: على وجه التحديد من ±20 ديسيبل من 5 هرتز إلى 100 هرتز مقارنةً بملف الاختبار النطاق المتوسط للترددات لكل ميكروفون مستخدَم لتسجيل مصدر الصوت غير المعالج.
[C-1-4] يجب أن يعرض مستويات الجهارة في نطاق التردد العالي: على وجه التحديد من ±30 ديسيبل من 7000 هرتز إلى 22 كيلوهرتز مقارنةً بنطاق التردد المتوسط لكل ميكروفون مستخدَم لتسجيل مصدر الصوت غير المعالج.
[C-1-5] يجب ضبط حساسية إدخال الصوت بحيث ينتج عن مصدر نغمة سينوسويدال بتردد 1000 هرتز يتم تشغيله عند مستوى ضغط صوتي (SPL) يبلغ 94 ديسيبل استجابة ناتجة عن كثافة طاقة ضوضاء 520 لمعاينات بسعة 16 بت (أو -36 ديسيبل على النطاق الكامل لمعاينات النقطة العائمة/الدقة المزدوجة) لكل ميكروفون يتم استخدامه لتسجيل مصدر الصوت الذي لم تتم معالجته.
[C-1-6] يجب أن تكون نسبة الإشارة إلى الضوضاء (SNR) 60 ديسيبل أو أعلى لكلٍّ من كل ميكروفون مستخدَم لتسجيل مصدر الصوت غير المعالج. (في حين أنّ نسبة SNR تُقاس على أنّها الفرق بين 94 ديسيبل SPL وقيمة مكافئة للمستوى الصوتي للضوضاء الذاتية، وفقًا لمقياس A-weighted).
[C-1-7] يجب أن يكون التشويه التوافقي الكلي (THD) أقل من 1% عند تردد 1 كيلوهرتز ومستوى إدخال 90 ديسيبل للضغط الصوتي في كل ميكروفون يتم استخدامه لتسجيل مصدر الصوت غير المعالج.
[C-1-8] يجب ألا يتضمّن المسار أي معالجة أخرى للإشارة (مثل التحكّم التلقائي في التراكم أو فلتر التردد العالي أو إلغاء الصدى) باستثناء عامل ضرب لمستوى الصوت لضبطه على النطاق المطلوب. بعبارة أخرى:
- [C-1-9] إذا كان هناك أيّ معالجة إشارة في البنية لأيّ سبب، يجب إيقافها وتقديم أي تأخير أو وقت استجابة إضافي إلى مسار الإشارة.
- [C-1-10] يجب ألا يؤدي مُضاعِف المستوى، على الرغم من السماح بوجوده في المسار، إلى إدخال تأخير أو وقت استجابة في مسار الإشارة.
يتم إجراء جميع قياسات مستوى الضغط الصوتي مباشرةً بجانب الميكروفون الذي يتم اختباره. بالنسبة إلى إعدادات الميكروفونات المتعدّدة، تنطبق هذه المتطلبات على كل ميكروفون.
إذا كانت عمليات تنفيذ الأجهزة تُعلن عن android.hardware.microphone
ولكنها لا تسمح
باستخدام مصدر صوت غير معالج، يجب أن تستوفي الشروط التالية:
- [C-2-1] يجب أن تُرجع
null
لطريقةAudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED)
API، للإشارة بشكل صحيح إلى عدم توفّر الدعم. - [C-SR-1] لا يزال يُنصح بشدة باستيفاء أكبر عدد ممكن من المتطلبات لمسار الإشارة لمصدر التسجيل غير المعالج.
6. توافق أدوات المطوّرين وخياراته
6.1. أدوات مطوّري البرامج
عمليات التنفيذ على الأجهزة:
- [C-0-1] يجب أن تكون متوافقة مع أدوات مطوّري تطبيقات Android المقدَّمة في حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
-
- [C-0-2] يجب أن تكون متوافقة مع adb كما هو موضّح في حزمة تطوير البرامج (SDK) لنظام التشغيل Android وshell
الأوامر المقدّمة في AOSP، والتي يمكن لمطوّري التطبيقات استخدامها،
بما في ذلك
dumpsys
cmd stats
- [C-0-11] يجب أن يكون متوافقًا مع الأمر
cmd testharness
في shell. قد يتم استثناء عمليات ترقية عمليات تنفيذ الأجهزة من إصدار Android أقدم بدون توفُّر كتلة بيانات دائمة من C-0-11. - [C-0-3] يجب عدم تغيير تنسيق أو محتوى أحداث نظام الجهاز (batterystats وdiskstats وfingerprint وgraphicsstats وnetstats وnotification وprocstats) التي يتم تسجيلها من خلال الأمر dumpsys.
- [C-0-10] يجب تسجيل الأحداث التالية بدون حذفها وإتاحة الوصول إليها من خلال الأمر
cmd stats
shell وStatsManager
فئة System API.- ActivityForegroundStateChanged
- AnomalyDetected
- AppBreadcrumbReported
- AppCrashOccurred
- AppStartOccurred
- BatteryLevelChanged
- BatterySaverModeStateChanged
- BleScanResultReceived
- BleScanStateChanged
- ChargingStateChanged
- DeviceIdleModeStateChanged
- ForegroundServiceStateChanged
- GpsScanStateChanged
- JobStateChanged
- PluggedStateChanged
- ScheduledJobStateChanged
- ScreenStateChanged
- SyncStateChanged
- SystemElapsedRealtime
- UidProcessStateChanged
- WakelockStateChanged
- WakeupAlarmOccurred
- WifiLockStateChanged
- WifiMulticastLockStateChanged
- WifiScanStateChanged
- [C-0-4] يجب أن يكون برنامج adb الخفي غير مفعّل تلقائيًا على الجهاز، ويجب أن تتوفّر آلية يمكن للمستخدم الوصول إليها لتفعيل أداة Android Debug Bridge.
- [C-0-5] يجب أن يكون متوافقًا مع adb الآمن. يتيح نظام Android استخدام أداة adb الآمنة. تفعِّل أداة adb الآمنة أداة adb على المضيفين المعروفين الذين تمّت مصادقتهم.
- [C-0-6] يجب توفير آلية تسمح بربط adb من جهاز مضيف. وعلى وجه التحديد:
إذا كانت عمليات تنفيذ الأجهزة التي لا تتضمّن منفذ USB تتيح وضع الجهاز الملحق، يجب أن تستوفي الشروط التالية:
- [C-3-1] يجب تنفيذ adb عبر شبكة منطقة محلية (مثل إيثرنت أو Wi-Fi).
- [C-3-2] يجب توفير برامج تشغيل لنظام التشغيل Windows 7 و8 و10، ما يسمح للمطوّرين بالاتصال بالجهاز باستخدام بروتوكول adb.
إذا كانت عمليات تنفيذ الأجهزة تتيح اتصالات adb بجهاز مضيف عبر Wi-Fi، يجب استيفاء الشروط التالية:
- [C-4-1] يجب أن تتضمّن الطريقة
AdbManager#isAdbWifiSupported()
true
.
إذا كانت عمليات تنفيذ الأجهزة تتيح عمليات اتصال adb بجهاز مضيف عبر Wi-Fi وتتضمن كاميرا واحدة على الأقل، يجب استيفاء الشروط التالية:
- [C-5-1] يجب أن تؤدي الطريقة
AdbManager#isAdbWifiQrSupported()
إلى عرض القيمةtrue
.
- [C-0-2] يجب أن تكون متوافقة مع adb كما هو موضّح في حزمة تطوير البرامج (SDK) لنظام التشغيل Android وshell
الأوامر المقدّمة في AOSP، والتي يمكن لمطوّري التطبيقات استخدامها،
بما في ذلك
Dalvik Debug Monitor Service (ddms)
- [C-0-7] يجب أن تتوافق مع جميع ميزات ddms كما هو موضّح في حزمة تطوير البرامج (SDK) لنظام التشغيل Android. بما أنّ أداة ddms تستخدم adb، من المفترض أن تكون أداة ddms غير مفعّلة تلقائيًا، ولكن يجب أن تكون مفعّلة عندما يفعّل المستخدم أداة Android Debug Bridge، كما هو موضّح أعلاه.
-
- [C-0-8] يجب أن يتضمّن إطار عمل Monkey وأن يكون متاحًا للاستخدام في التطبيقات.
-
- [C-0-9] يجب أن تكون متوافقة مع أداة systrace كما هو موضّح في حزمة تطوير البرامج (SDK) لنظام التشغيل Android. يجب أن تكون أداة Systrace غير مفعّلة تلقائيًا ويجب أن تتوفّر آلية يمكن للمستخدم تفعيلها.
-
- [C-SR-1] يُنصح بشدة بعرض
/system/bin/perfetto
ملف ثنائي لمستخدم shell يكون cmdline متوافقًا مع مستندات perfetto. - [C-SR-2] يُنصح بشدة بقبول ملف ثنائي لبرنامج perfetto كإدخال لملف برمجة protobuf متوافق مع المخطط المحدّد في مستندات perfetto.
- [C-SR-3] يُنصح بشدة باستخدام ملف perfetto الثنائي لكتابة أثر protobuf يتوافق مع المخطّط المحدّد في مستندات perfetto.
- [C-SR-4] يُنصح بشدة بتوفير، من خلال ملفّ perfetto الثنائي، على الأقل مصادر البيانات الموضّحة في مستندات perfetto.
- [C-SR-1] يُنصح بشدة بعرض
-
- [C-0-10] يجب كتابة
LMK_KILL_OCCURRED_FIELD_NUMBER
Atom في log statsd عندما يتم إنهاء أحد التطبيقات بواسطة Low Memory Killer.
- [C-0-10] يجب كتابة
وضع "مفعّل الاختبار" إذا كانت عمليات تنفيذ الأجهزة تتيح استخدام الأمر
cmd testharness
وcmd testharness enable
في ملف شل، يمكنها تنفيذ ما يلي:- [C-2-1] يجب إرجاع
true
لأجلActivityManager.isRunningInUserTestHarness()
- [C-2-2] يجب تنفيذ وضع "مفعِّل الاختبار" كما هو موضّح في مستندات وضع "مفعِّل الاختبار".
- [C-2-1] يجب إرجاع
إذا أبلغت عمليات تنفيذ الأجهزة عن توفّر Vulkan 1.0 أو إصدار أحدث من خلال علامات ميزات
android.hardware.vulkan.version
، يتم تنفيذ ما يلي:
- [C-1-1] يجب أن يقدّم التطبيق ميزة تتيح لمطوّره تفعيل/إيقاف طبقات تصحيح أخطاء وحدة معالجة الرسومات.
- [C-1-2] عند تفعيل طبقات تصحيح أخطاء وحدة معالجة الرسومات، يجب سرد الطبقات في المكتبات التي تقدّمها أدوات خارجية (أي ليست جزءًا من النظام الأساسي أو حزمة التطبيق) والتي يمكن العثور عليها في الدليل الأساسي للتطبيقات القابلة لتصحيح الأخطاء، وذلك لتمتثل لوظيفتَي واجهة برمجة التطبيقات vkEnumerateInstanceLayerProperties() وvkCreateInstance() .
6.2. خيارات المطوّرين
يتيح نظام التشغيل Android للمطوّرين ضبط الإعدادات المتعلقة بتطوير التطبيقات.
يجب أن تقدّم عمليات تنفيذ الأجهزة تجربة متّسقة لميزة "خيارات المطوّر"، ويجب أن تستوفي الشروط التالية:
- [C-0-1] يجب أن يراعي التطبيق android.settings.APPLICATION_DEVELOPMENT_SETTINGS لعرض الإعدادات ذات الصلة بتطوير التطبيقات. يؤدي تنفيذ Android المصدري إلى إخفاء قائمة "خيارات المطوّرين" تلقائيًا، ويتيح للمستخدمين تشغيل "خيارات المطوّرين" بعد الضغط سبع (7) مرات على الإعدادات > لمحة عن الجهاز > رقم الإصدار.
- [C-0-2] يجب إخفاء "خيارات المطوّرين" تلقائيًا.
- [C-0-3] يجب توفير آلية واضحة لا تمنح معاملة أولى لأحد التطبيقات التابعة لجهة خارجية مقارنةً بتطبيق آخر لتفعيل خيارات المطوّر. يجب تقديم مستند أو موقع إلكتروني متاح للجميع يصف كيفية تفعيل "خيارات المطوّر". يجب أن يكون هذا المستند أو الموقع الإلكتروني قابلاً للربط من مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
- يجب أن يعرض التطبيق إشعارًا مرئيًا مستمرًا للمستخدم عند تفعيل "خيارات المطوّر" وظهور مشكلة في أمان المستخدم.
- يجوز لنا تقييد الوصول مؤقتًا إلى قائمة "خيارات المطوّر"، وذلك من خلال إخفاء القائمة أو إيقافها، لمنع تشتيت الانتباه في السيناريوهات التي يُعتبَر فيها أمان المستخدم مصدر قلق.
7. توافق الأجهزة
إذا كان الجهاز يتضمّن مكوّنًا معيّنًا للأجهزة يتضمّن واجهة برمجة تطبيقات مقابلة للمطوّرين التابعين لجهات خارجية:
- [C-0-1] يجب أن ينفِّذ تطبيق الجهاز واجهة برمجة التطبيقات (IDE) هذه كما هو موضّح في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
إذا كانت واجهة برمجة تطبيقات في حزمة SDK تتفاعل مع مكوّن أجهزة تم تحديده كعنصر اختياري ولم يكن تنفيذ الجهاز يحتوي على هذا المكوّن:
- [C-0-2] يجب تقديم تعريفات الفئات الكاملة (كما هو موضّح في حزمة تطوير البرامج (SDK)) لواجهة برمجة التطبيقات المكوّنة.
- [C-0-3] يجب تنفيذ سلوكيات واجهة برمجة التطبيقات كعمليات لا تؤدي إلى أيّ إجراء بطريقة معقولة.
- [C-0-4] يجب أن تعرض طُرق واجهة برمجة التطبيقات قيمًا فارغة حيثما يسمح بذلك مستند حزمة SDK.
- [C-0-5] يجب أن تعرِض طُرق واجهة برمجة التطبيقات عمليات تنفيذ لا تؤدي إلى أيّ إجراء للفئات التي لا تسمح مستندات حِزم تطوير البرامج (SDK) بالقيم الخالية.
- [C-0-6] يجب ألّا تُعرِض طُرق واجهة برمجة التطبيقات استثناءات لم يتم توثيقها في مستندات حزمة تطوير البرامج (SDK).
- [C-0-7] يجب أن تُبلغ عمليات تنفيذ الأجهزة بشكلٍ منتظم عن معلومات دقيقة عن ملف تكوين الأجهزة
من خلال الطريقتَين
getSystemAvailableFeatures()
وhasSystemFeature(String)
في فئة android.content.pm.PackageManager للمحرِّر نفسه.
ومن الأمثلة الشائعة على السيناريوهات التي تنطبق فيها هذه المتطلبات واجهة برمجة تطبيقات معالجة المكالمات الهاتفية: حتى على الأجهزة غير الهاتفية، يجب تنفيذ واجهات برمجة التطبيقات هذه على أنّها وظائف مقبولة بلا عمليات.
7.1. الشاشة والرسومات
يتضمّن نظام التشغيل Android مرافق تعمل تلقائيًا على تعديل مواد عرض التطبيق وتصاميم واجهة المستخدم بشكل مناسب للجهاز لضمان عمل التطبيقات التابعة لجهات خارجية بشكل جيد على مجموعة متنوعة من إعدادات الأجهزة. على شاشات Android المتوافقة التي يمكن تشغيل جميع التطبيقات المتوافقة مع Android التابعة لجهات خارجية عليها، يجب أن تُنفِّذ عمليات تنفيذ الأجهزة واجهات برمجة التطبيقات هذه والسلوكيات بشكل صحيح، كما هو موضّح بالتفصيل في هذا القسم.
يتم تعريف الوحدات التي تشير إليها المتطلبات في هذا القسم على النحو التالي:
- الحجم المادي القطري المسافة بين جهتَين متقابلتَين من الجزء المضيء من الشاشة، بالبوصة
- النقاط لكل بوصة (dpi) عدد وحدات البكسل التي تتضمنها مساحة قياسية أفقية أو عمودية بحجم 1 بوصة. في الأماكن التي يتم فيها إدراج قيم النقاط لكل بوصة، يجب أن تقع قيم النقاط لكل بوصة الافقية والعمودية ضمن النطاق.
- نسبة العرض إلى الارتفاع نسبة وحدات البكسل في البُعد الأطول إلى البُعد الأقصر للشاشة على سبيل المثال، سيكون تنسيق شاشة بدقة 480×854 بكسل هو 854/480 = 1.779، أو 16:9 تقريبًا.
- وحدة البكسل المستقلة عن الكثافة (dp) وحدة البكسل الافتراضية التي تم تسويتها لشاشة بكثافة 160 نقطة لكل بوصة، ويتم احتسابها على النحو التالي: وحدات البكسل = عدد النقاط لكل بوصة * (الكثافة/160).
7.1.1. إعدادات الشاشة
7.1.1.1. حجم الشاشة وشكلها
يتيح إطار عمل واجهة مستخدم Android مجموعة متنوعة من أحجام تنسيق الشاشة المنطقي المختلفة، ويسمح للتطبيقات بالاستعلام عن حجم تنسيق الشاشة في الإعدادات الحالية من خلال Configuration.screenLayout
باستخدام SCREENLAYOUT_SIZE_MASK
وConfiguration.smallestScreenWidthDp
.
عمليات التنفيذ على الأجهزة:
[C-0-1] يجب الإبلاغ عن حجم التنسيق الصحيح لملف
Configuration.screenLayout
كما هو محدّد في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android. وعلى وجه التحديد، يجب أن تُبلغ عمليات تنفيذ الأجهزة عن الأبعاد المنطقية الصحيحة لوحدات البكسل المستقلة الكثافة (dp) على الشاشة على النحو التالي:- يجب أن تكون الأجهزة التي تم ضبط
Configuration.uiMode
فيها على أي قيمة غير UI_MODE_TYPE_WATCH، والتي تُبلغ عن حجمsmall
لسمةConfiguration.screenLayout
، أبعادها 426 dp x 320 dp على الأقل. - بالنسبة إلى الأجهزة التي تُبلغ عن حجم
normal
للشاشةConfiguration.screenLayout
، يجب أن يكون حجم الشاشة فيها 480 نقطة لكل بوصة × 320 نقطة لكل بوصة على الأقل. - بالنسبة إلى الأجهزة التي تُبلغ عن حجم
large
للشاشةConfiguration.screenLayout
، يجب أن يكون حجم الشاشة فيها 640 dp x 480 dp على الأقل. - يجب أن تكون الأجهزة التي تُبلغ عن حجم
xlarge
لشاشةConfiguration.screenLayout
، بدقة 960 نقطة لكل بوصة × 720 نقطة لكل بوصة على الأقل.
- يجب أن تكون الأجهزة التي تم ضبط
[C-0-2] يجب أن تتوافق التطبيقات بشكلٍ صحيح مع أحجام الشاشة المُعلَن عنها من خلال سمة <
supports-screens
> في ملف AndroidManifest.xml، كما هو موضّح في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.يمكن أن تتضمّن شاشات متوافقة مع Android وزوايا دائرية.
إذا كانت عمليات تنفيذ الأجهزة متوافقة مع UI_MODE_TYPE_NORMAL
وتتضمّن
شاشات متوافقة مع Android ذات زوايا مستديرة، يجب استيفاء الشروط التالية:
[C-1-1] يجب التأكّد من استيفاء أحد المتطلبات التالية على الأقل:
- أن يكون نصف قطر الزوايا المستديرة أقل من أو يساوي 38 وحدة بكسل
- عند تثبيت مربّع أبعاده 15 وحدة بكسل في كلّ زاوية من زوايا الشاشة المنطقية، يظهر بكسل واحد على الأقل من كلّ مربّع على الشاشة.
يجب أن تتضمّن إمكانات الاستخدام التي يحصل عليها المستخدم للتبديل إلى وضع العرض مع الزوايا المستطيلة.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن شاشات متوافقة مع Android قابلة للطي، أو تتضمّن مفصلاً قابلاً للطي بين لوحات عرض متعددة وتوفر هذه الشاشات لعرض التطبيقات التابعة لجهات خارجية، يجب استيفاء الشروط التالية:
- [C-2-1] يجب استخدام أحدث إصدار ثابت متاح من واجهة برمجة تطبيقات الإضافات أو الإصدار الثابت من واجهة برمجة تطبيقات Sidecar لكي تستخدمه مكتبة Window Manager Jetpack.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن شاشات متوافقة مع Android قابلة للطي، أو تتضمّن مفصلاً قابلاً للطي بين لوحات عرض متعددة، وإذا كان المفصل أو الطي يتجاوز نافذة تطبيق بملء الشاشة، يجب استيفاء الشروط التالية:
- [C-3-1] يجب الإبلاغ عن موضع المفصل أو الطي وحدوده وحالته من خلال واجهة برمجة التطبيقات للإضافات أو واجهة برمجة التطبيقات الجانبية للتطبيق.
لمعرفة تفاصيل عن تنفيذ واجهات برمجة التطبيقات الخاصة بالتطبيق المصاحب أو الإضافة بشكل صحيح، يُرجى الرجوع إلى المستندات العامة لنظام إدارة النوافذ Jetpack.
7.1.1.2. نسبة العرض إلى الارتفاع للشاشة
على الرغم من عدم فرض أي قيود على نسبة العرض إلى الارتفاع للشاشة الفعلية
للشاشات المتوافقة مع Android، يجب أن تستوفي نسبة العرض إلى الارتفاع للشاشة المنطقية
التي يتم عرض التطبيقات التابعة لجهات خارجية عليها، والتي يمكن اشتقاقها من قيم الارتفاع
والعرض التي يتم الإبلاغ عنها من خلال واجهات برمجة تطبيقات view.Display
وConfiguration
، المتطلبات التالية:
[C-0-1] في عمليات تنفيذ الأجهزة التي تم ضبط
Configuration.uiMode
فيها علىUI_MODE_TYPE_NORMAL
، يجب أن تكون قيمة نسبة العرض إلى الارتفاع أقل من أو تساوي 1.86 (16:9 تقريبًا)، ما لم يستوفِ التطبيق أحد الشروط التالية:- أعلن التطبيق أنّه يتوافق مع نسبة عرض إلى ارتفاع أكبر للشاشة
من خلال قيمة البيانات الوصفية
android.max_aspect
. - يُعلِن التطبيق أنّه يمكن تغيير حجمه من خلال السمة android:resizeableActivity.
- يستهدف التطبيق المستوى 24 من واجهة برمجة التطبيقات أو المستويات الأعلى ولا يعلن عن
android:maxAspectRatio
يؤدي إلى تقييد نسبة العرض إلى الارتفاع المسموح بها.
- أعلن التطبيق أنّه يتوافق مع نسبة عرض إلى ارتفاع أكبر للشاشة
من خلال قيمة البيانات الوصفية
[C-0-3] في عمليات تنفيذ الأجهزة التي تم ضبط
Configuration.uiMode
فيها علىUI_MODE_TYPE_WATCH
، يجب ضبط قيمة نسبة العرض إلى الارتفاع على 1.0 (1:1).
7.1.1.3. كثافة الشاشة
يحدِّد إطار عمل واجهة مستخدم Android مجموعة من الكثافات المنطقية العادية لمساعدة مطوّري التطبيقات في استهداف موارد التطبيقات.
[C-0-1] بشكلٍ تلقائي، يجب أن تُبلغ عمليات تنفيذ الأجهزة عن كثافة واحدة فقط من كثافات إطار عمل Android المُدرَجة في
DisplayMetrics
من خلال واجهة برمجة التطبيقاتDENSITY_DEVICE_STABLE
، ويجب ألّا تتغيّر هذه القيمة في أي وقت. ومع ذلك، يجوز للجهاز الإبلاغ عن كثافة متغيرة عشوائية وفقًا لتغييرات إعدادات الشاشة التي أجراها المستخدم (مثل حجم الشاشة) والتي تم ضبطها بعد التمهيد الأولي.يجب أن تحدِّد عمليات تنفيذ الأجهزة كثافة إطار عمل Android العادية التي تكون الأقرب رقميًا إلى الكثافة الفعلية للشاشة، ما لم تؤدي كثافة المنطق إلى خفض حجم الشاشة المسجَّل إلى ما دون الحد الأدنى المسموح به. إذا كانت كثافة إطار عمل Android العادية الأقرب رقميًا إلى الكثافة الفعلية تؤدي إلى حجم شاشة أصغر من أصغر حجم شاشة متوافق متوافق (320 نقطة لكل بوصة)، يجب أن تُبلغ عمليات تنفيذ الأجهزة عن كثافة إطار عمل Android العادية الأقل تاليًا.
إذا كان هناك عنصر تحكم لتغيير حجم شاشة الجهاز:
- [C-1-1] يجب عدم تكبير حجم الشاشة أكثر من 1.5 مرة من الكثافة الأصلية أو أن يؤدي إلى الحد الأدنى الفعال لبُعد الشاشة الذي يقل عن 320dp (أي ما يعادل مُحدِّد المورد sw320dp)، أيهما يحدث أولاً.
- [C-1-2] يجب ألا يتم تصغير حجم الشاشة إلى أقل من 0.85 ضعف الكثافة الأصلية.
- لضمان سهولة الاستخدام وأحجام الخطوط المتسقة، ننصحك بتقديم الحجم التالي لخيارات العرض الأصلية (مع الالتزام بالحدود المذكورة أعلاه):
- صغير: 0.85x
- الإعداد التلقائي: 1x (مقياس الشاشة الأصلي)
- كبير: 1.15x
- أكبر: 1.3x
- أكبر حجمًا 1.45x
7.1.2. مقاييس الشبكة الإعلانية
إذا كانت عمليات تنفيذ الأجهزة تتضمّن شاشات متوافقة مع Android أو إخراج الفيديو إلى شاشات العرض المتوافقة مع Android، يجب استيفاء الشروط التالية:
- [C-1-1] يجب الإبلاغ عن قيم صحيحة لجميع مقاييس شاشة
التوافقية مع Android المحدّدة في واجهة برمجة التطبيقات
android.util.DisplayMetrics
.
إذا لم تتضمّن عمليات تنفيذ الأجهزة شاشة أو إخراج فيديو مضمّنًا، يجب مراعاة ما يلي:
- [C-2-1] يجب عرض القيم الصحيحة للشاشة المتوافقة مع Android
كما هو محدّد في واجهة برمجة التطبيقات
android.util.DisplayMetrics
للشاشة التلقائية المحاكيةview.Display
.
7.1.3. اتجاه الشاشة
عمليات التنفيذ على الأجهزة:
- [C-0-1] يجب الإبلاغ عن أوضاع الشاشة المتاحة
(
android.hardware.screen.portrait
و/أوandroid.hardware.screen.landscape
) ويجب الإبلاغ عن اتجاه واحد على الأقل متاح. على سبيل المثال، يجب أن يُبلغ الجهاز الذي يتضمّن شاشة عمودية ثابتة، مثل التلفزيون أو الكمبيوتر المحمول، عنandroid.hardware.screen.landscape
فقط. - [C-0-2] يجب عرض القيمة الصحيحة لاتجاه
الجهاز الحالي، عند الاستعلام من خلال
android.content.res.Configuration.orientation
أوandroid.view.Display.getOrientation()
أو واجهات برمجة تطبيقات أخرى.
إذا كانت عمليات تنفيذ الأجهزة تتيح وضعَي الشاشة، يجب أن:
- [C-1-1] يجب أن تتيح التطبيقات اتجاهًا ديناميكيًا للشاشة سواءً كان عموديًا أو أفقيًا. وهذا يعني أنّه يجب أن يراعي الجهاز طلب التطبيق باتجاه شاشة محدّد.
- [C-1-2] يجب عدم تغيير حجم الشاشة أو كثافتها المُبلَّغ عنها عند تغيير الاتجاه.
- يمكن اختيار الاتجاه العمودي أو الأفقي كإعداد تلقائي.
7.1.4. ميزة "تسريع الرسومات" ثنائية وثلاثية الأبعاد
7.1.4.1 OpenGL ES
عمليات التنفيذ على الأجهزة:
- [C-0-1] يجب تحديد إصدارات OpenGL ES المتوافقة (1.1 و2.0
و3.0 و3.1 و3.2) بشكل صحيح من خلال واجهات برمجة التطبيقات المُدارة (مثلاً من خلال
GLES10.getString()
) وواجهات برمجة التطبيقات الأصلية. - [C-0-2] يجب أن تتضمّن التوافق مع جميع واجهات برمجة التطبيقات المُدارة المقابلة و واجهات برمجة التطبيقات الأصلية لكل إصدارات OpenGL ES التي تم تحديدها للتوافق معها.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن شاشة أو إخراج فيديو، يجب أن تستوفي الشروط التالية:
- [C-1-1] يجب أن تكون متوافقة مع كلّ من OpenGL ES 1.1 و2.0، على النحو الموضّح بالتفصيل في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
- [C-SR-1] يُنصح بشدة بتوفُّر OpenGL ES 3.1.
- يجب أن يكون متوافقًا مع OpenGL ES 3.2.
يتم تقسيم اختبارات OpenGL ES dEQP إلى عدد من قوائم الاختبارات، ولكل منها
تاريخ أو رقم إصدار مرتبط. يمكنك العثور على هذه المراجع في شجرة مصدر Android على الرابط
external/deqp/android/cts/main/glesXX-master-YYYY-MM-DD.txt
. يشير الجهاز الذي
يتوافق مع OpenGL ES على مستوى تم الإبلاغ عنه ذاتيًا إلى أنّه يمكنه اجتياز اختبارات dEQP
في جميع قوائم الاختبارات من هذا المستوى والإصدارات الأقدم.
إذا كانت عمليات تنفيذ الأجهزة متوافقة مع أي من إصدارات OpenGL ES، يجب أن تستوفي الشروط التالية:
- [C-2-1] يجب الإبلاغ من خلال واجهات برمجة التطبيقات المُدارة وواجهات برمجة التطبيقات الأصلية لـ OpenGL ES عن أي إضافات أخرى لـ OpenGL ES تم تنفيذها، وعلى العكس يجب عدم الإبلاغ عن سلاسل الإضافات التي لا تتوافق معها.
- [C-2-2] يجب أن تكون متوافقًا مع الإضافات
EGL_KHR_image
وEGL_KHR_image_base
EGL_ANDROID_image_native_buffer
وEGL_ANDROID_get_native_client_buffer
EGL_KHR_wait_sync
وEGL_KHR_get_all_proc_addresses
EGL_ANDROID_presentation_time
وEGL_KHR_swap_buffers_with_damage
EGL_ANDROID_recordable
وEGL_ANDROID_GLES_layers
. - [C-2-3] يجب الإبلاغ عن الحد الأقصى لإصدار اختبارات dEQP في OpenGL ES
المتوافقة من خلال علامة ميزة
android.software.opengles.deqp.level
. - [C-2-4] يجب أن يكون متوافقًا مع الإصدار 132383489 على الأقل (اعتبارًا من 1 آذار (مارس) 2020) كما هو مذكور في علامة ميزة
android.software.opengles.deqp.level
. - [C-2-5] يجب اجتياز جميع اختبارات dEQP في OpenGL ES في قوائم الاختبار بين الإصدار
132383489 والإصدار المحدّد في علامة ميزة
android.software.opengles.deqp.level
، لكل إصدار متوافق من OpenGL ES. - [C-SR-2] يُنصح بشدة بتوفّر الإضافتَين
EGL_KHR_partial_update
وOES_EGL_image_external
. - يجب الإبلاغ بدقة من خلال طريقة
getString()
عن أي تنسيق ضغط رسومات يتوافق معه التطبيق، والذي يكون عادةً خاصًا بالمورّد.
إذا كانت عمليات تنفيذ الأجهزة تعلن عن توافقها مع OpenGL ES 3.0 أو 3.1 أو 3.2، يجب أن تستوفي المتطلبات التالية:
- [C-3-1] يجب تصدير رموز الدوالّ المقابلة لهذه الإصدارات بالإضافة إلى رموز دوالّ OpenGL ES 2.0 في مكتبة libGLESv2.so.
- [C-SR-3] يُنصح بشدة بتوفُّر إضافة
OES_EGL_image_external_essl3
.
إذا كانت عمليات تنفيذ الأجهزة متوافقة مع OpenGL ES 3.2، يجب أن تستوفي الشروط التالية:
- [C-4-1] يجب أن يكون متوافقًا مع حزمة OpenGL ES Android Extension Pack بالكامل.
إذا كانت عمليات تنفيذ الأجهزة متوافقة مع مجموعة إضافات Android لـ OpenGL ES بالكامل، يجب أن تستوفي الشروط التالية:
- [C-5-1] يجب تحديد مدى توفّر الميزة من خلال
android.hardware.opengles.aep
علامة الميزة.
إذا كانت عمليات تنفيذ الأجهزة تتيح استخدام الإضافة EGL_KHR_mutable_render_buffer
، فإنّها:
- [C-6-1] يجب أن تتيح أيضًا إضافة
EGL_ANDROID_front_buffer_auto_refresh
.
7.1.4.2 Vulkan
يتيح نظام التشغيل Android استخدام Vulkan ، وهي واجهة برمجة تطبيقات متعددة المنصات ذات تكلفة منخفضة للرسومات الثلاثية الأبعاد العالية الأداء.
إذا كانت عمليات تنفيذ الأجهزة متوافقة مع OpenGL ES 3.1، يجب أن تستوفي الشروط التالية:
- [C-SR-1] يُنصح بشدة بتضمين دعم لـ Vulkan 1.1.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن شاشة أو إخراج فيديو، يجب أن تستوفي الشروط التالية:
- يجب أن تتضمّن واجهة برمجة التطبيقات إمكانية استخدام Vulkan 1.1.
يتم تقسيم اختبارات Vulkan dEQP إلى عدد من قوائم الاختبارات، ولكل منها تاريخ أو إصدار مرتبط. يمكنك العثور على هذه المراجع في شجرة مصدر Android على الرابط
external/deqp/android/cts/main/vk-master-YYYY-MM-DD.txt
. يشير الجهاز الذي يتوافق مع Vulkan على مستوى تم الإبلاغ عنه ذاتيًا إلى أنّه يمكنه اجتياز اختبارات dEQP في جميع قوائم الاختبار من هذا المستوى والإصدارات الأقدم.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن توافقًا مع Vulkan 1.0 أو إصدار أحدث، يجب استيفاء الشروط التالية:
- [C-1-1] يجب الإبلاغ عن القيمة الصحيحة للعدد الصحيح باستخدام علامتَي ميزة
android.hardware.vulkan.level
وandroid.hardware.vulkan.version
. - [C-1-2] يجب إدراج
VkPhysicalDevice
واحدة على الأقل لواجهة برمجة التطبيقاتvkEnumeratePhysicalDevices()
الأصلية لـ Vulkan . - [C-1-3] يجب تنفيذ واجهات برمجة تطبيقات Vulkan 1.0 بالكامل لكل ملف شخصي مُدرَج
VkPhysicalDevice
. - [C-1-4] يجب إدراج الطبقات، المضمّنة في المكتبات المجمّعة من رموز برمجية أصلية والتي تحمل الاسم
libVkLayer*.so
في دليل المكتبة المجمّعة من رموز برمجية أصلية لحزمة التطبيق، من خلال واجهات برمجة التطبيقات المجمّعة من رموز برمجية أصلية لـ VulkanvkEnumerateInstanceLayerProperties()
وvkEnumerateDeviceLayerProperties()
. - [C-1-5] يجب عدم إدراج الطبقات التي تقدّمها المكتبات خارج
حزمة التطبيق، أو توفير طرق أخرى لتتبُّع واجهة برمجة التطبيقات
Vulkan أو اعتراضها، ما لم يكن التطبيق يحتوي على سمة
android:debuggable
تم ضبطها علىtrue
. - [C-1-6] يجب الإبلاغ عن جميع سلاسل الإضافات التي تتوافق معها عبر واجهات برمجة تطبيقات Vulkan الأصلية، وفي المقابل يجب ألا تبلغ عن سلاسل الإضافات التي لا تتوافق معها بشكل صحيح.
- [C-1-7] يجب أن يكون متوافقًا مع إضافات VK_KHR_surface وVK_KHR_android_surface وVK_KHR_swapchain وVK_KHR_incremental_present.
- [C-1-8] يجب الإبلاغ عن الحد الأقصى لإصدار اختبارات Vulkan dEQP
المتوافقة من خلال علامة ميزة
android.software.vulkan.deqp.level
. - [C-1-9] يجب أن يكون متوافقًا مع الإصدار
132317953
على الأقل (اعتبارًا من 1 آذار (مارس) 2019) كما هو مذكور في علامة ميزةandroid.software.vulkan.deqp.level
. - [C-1-10] يجب اجتياز جميع اختبارات Vulkan dEQP في قوائم الاختبار بين
الإصدار
132317953
والإصدار المحدّد في علامة ميزةandroid.software.vulkan.deqp.level
. - [C-1-11] يجب عدم إدراج توافق مع الإضافات VK_KHR_video_queue أو VK_KHR_video_decode_queue أو VK_KHR_video_encode_queue.
- [C-SR-2] يُنصح بشدة بتوفير دعم للإضافتَين VK_KHR_driver_properties و VK_GOOGLE_display_timing.
إذا لم تتضمّن عمليات تنفيذ الأجهزة ميزة التوافق مع Vulkan 1.0، يجب أن تستوفي الشروط التالية:
- [C-2-1] يجب عدم الإفصاح عن أي من مفاتيح تبديل أوضاع ميزات Vulkan (مثل
android.hardware.vulkan.level
وandroid.hardware.vulkan.version
). - [C-2-2] يجب عدم إدراج أي
VkPhysicalDevice
لواجهة برمجة التطبيقات الأصلية لـ VulkanvkEnumeratePhysicalDevices()
.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن توافقًا مع Vulkan 1.1 وتعلن عن أي من علامات ميزات Vulkan، يجب أن تستوفي المتطلبات التالية:
- [C-3-1] يجب أن توفّر إمكانية استخدام نوعَي
SYNC_FD
إشارة الانتظار الخارجية وhandle وإضافةVK_ANDROID_external_memory_android_hardware_buffer
.
7.1.4.3 RenderScript
- [C-0-1] يجب أن تكون عمليات تنفيذ الأجهزة متوافقة مع Android RenderScript، على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
7.1.4.4 ميزة "تسريع الرسومات ثنائية الأبعاد"
يتضمّن نظام التشغيل Android آلية تتيح للتطبيقات الإفصاح عن رغبتها في تفعيل ميزة "التسريع بالأجهزة" للرسومات ثنائية الأبعاد على مستوى التطبيق أو النشاط أو النافذة أو العرض من خلال استخدام علامة البيان android:hardwareAccelerated أو طلبات مباشرة لواجهة برمجة التطبيقات.
عمليات التنفيذ على الأجهزة:
- [C-0-1] يجب تفعيل ميزة "تسريع الأجهزة" تلقائيًا، ويجب إيقافها إذا طلب المطوِّر ذلك من خلال ضبط قيمة android:hardwareAccelerated="false” أو إيقافها مباشرةً من خلال واجهات برمجة التطبيقات Android View APIs.
- [C-0-2] يجب أن يعرض التطبيق سلوكًا متوافقًا مع مستندات IDE لنظام التشغيل Android بشأن تسريع الأجهزة.
يتضمّن Android عنصر TextureView الذي يتيح للمطوّرين دمج ملمس OpenGL ES المُسرَّع بالأجهزة مباشرةً كأهداف للعرض في التسلسل الهرمي لواجهة المستخدم.
عمليات التنفيذ على الأجهزة:
- [C-0-3] يجب أن يكون متوافقًا مع واجهة برمجة التطبيقات TextureView API، ويجب أن يعرض سلوكًا متناسقًا مع التنفيذ في Android.
7.1.4.5 شاشات النطاق اللوني الواسع
إذا كانت عمليات تنفيذ الأجهزة تدّعي توفّر شاشات النطاق اللوني الواسع من خلال
Configuration.isScreenWideColorGamut()
، يجب أن تستوفي الشروط التالية:
- [C-1-1] يجب أن يكون الجهاز مزوّدًا بشاشة تم ضبط ألوانها.
- [C-1-2] يجب أن يكون الجهاز مزوّدًا بشاشة تغطي نطاق ألوان sRGB بالكامل في مساحة CIE 1931 xyY.
- [C-1-3] يجب أن يكون الجهاز مزوّدًا بشاشة تبلغ مساحة نطاق الألوان فيها 90% على الأقل من DCI-P3 في مساحة CIE 1931 xyY.
- [C-1-4] يجب أن يكون متوافقًا مع OpenGL ES 3.1 أو 3.2 وأن يتم الإبلاغ عنه بشكل صحيح.
- [C-1-5] يجب الإعلان عن توفّر الإضافات
EGL_KHR_no_config_context
وEGL_EXT_pixel_format_float
وEGL_KHR_gl_colorspace
وEGL_EXT_gl_colorspace_scrgb
وEGL_EXT_gl_colorspace_scrgb_linear
وEGL_EXT_gl_colorspace_display_p3
وEGL_EXT_gl_colorspace_display_p3_linear
وEGL_EXT_gl_colorspace_display_p3_passthrough
. - [C-SR-1] يُنصح بشدة بتوفّر
GL_EXT_sRGB
.
في المقابل، إذا كانت عمليات تنفيذ الأجهزة لا تتيح استخدام شاشات النطاق اللوني الواسع، يتم تنفيذ ما يلي:
- [C-2-1] يجب أن تغطي نسبة% 100 أو أكثر من sRGB في مساحة CIE 1931 xyY، على الرغم من أنّه لم يتم تحديد نطاق ألوان الشاشة.
7.1.5. وضع التوافق مع التطبيقات القديمة
يحدِّد Android "وضع التوافق" الذي يعمل فيه إطار العمل في وضع مكافئ لحجم الشاشة "العادي" (بعرض 320dp) لمنفعة التطبيقات القديمة التي لم يتم تطويرها لإصدارات Android القديمة التي تسبق الاستقلالية عن حجم الشاشة.
7.1.6. تكنولوجيا الشاشة
تتضمّن منصة Android واجهات برمجة تطبيقات تتيح للتطبيقات عرض رسومات غنية على شاشة متوافقة مع Android. يجب أن تكون الأجهزة متوافقة مع كل واجهات برمجة التطبيقات هذه على النحو المحدّد في حزمة تطوير البرامج (SDK) لنظام التشغيل Android، ما لم يُسمح بذلك تحديدًا في هذا المستند.
جميع شاشات التنفيذ المتوافقة مع Android للجهاز:
- [C-0-1] يجب أن يكون الجهاز قادرًا على عرض رسومات ملونة بدقة 16 بت.
- يجب أن تكون متوافقة مع الشاشات التي يمكنها عرض الرسومات الملوّنة بدقة 24 بت.
- [C-0-2] يجب أن يكون الجهاز قادرًا على عرض الرسوم المتحركة.
- [C-0-3] يجب أن تكون نسبة العرض إلى الارتفاع (PAR) للبكسل بين 0.9 و1.15. وهذا يعني أنّ نسبة عرض البكسل إلى ارتفاعه يجب أن تكون قريبة من نسبة العرض إلى الارتفاع المربّع (1.0) مع هامش خطأ يتراوح بين 10% و15%.
7.1.7. الشاشات الثانوية
يتيح نظام التشغيل Android استخدام شاشات ثانوية متوافقة معه لتفعيل ميزات مشاركة الوسائط وواجهات برمجة التطبيقات للمطوّرين للوصول إلى الشاشات الخارجية.
إذا كانت عمليات تنفيذ الأجهزة تتيح استخدام شاشة خارجية عبر اتصال سلكي أو لاسلكي أو اتصال بشاشة إضافية مدمجة، يجب أن تستوفي الشروط التالية:
- [C-1-1] يجب تنفيذ خدمة النظام
DisplayManager
وواجهة برمجة التطبيقات على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
7.2. أجهزة إدخال بيانات
عمليات التنفيذ على الأجهزة:
- [C-0-1] يجب أن يتضمّن آلية إدخال، مثل شاشة لمس أو تنقّل بدون لمس، للتنقّل بين عناصر واجهة المستخدم.
7.2.1. لوحة المفاتيح
إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة استخدام تطبيقات محرر أسلوب الإدخال (IME) التابعة لجهات خارجية، يجب أن تستوفي المتطلبات التالية:
- [C-1-1] يجب الإفصاح عن علامة ميزة
android.software.input_methods
. - [C-1-2] يجب تنفيذ
Input Management Framework
بالكامل - [C-1-3] يجب أن يكون الجهاز مزوّدًا بلوحة مفاتيح برمجية مثبَّتة مسبقًا.
عمليات التنفيذ على الأجهزة:
- [C-0-1] يجب عدم تضمين لوحة مفاتيح أجهزة لا تتطابق مع أحد التنسيقات المحدّدة في android.content.res.Configuration.keyboard (QWERTY أو 12 مفتاحًا).
- يجب أن تتضمّن عمليات تنفيذ إضافية للوحة المفاتيح.
- قد تتضمّن لوحة مفاتيح جهاز.
7.2.2. التنقّل بدون لمس الشاشة
يتيح نظام التشغيل Android استخدام لوحة التوجيه وكرة التتبُّع والعجلة كآليات للتنقّل بدون لمس الشاشة.
عمليات التنفيذ على الأجهزة:
- [C-0-1] يجب الإبلاغ عن القيمة الصحيحة لملف برمجي android.content.res.Configuration.navigation.
إذا كانت عمليات تنفيذ الأجهزة لا تتضمّن طرق تنقّل بدون لمس، فإنّها:
- [C-1-1] يجب توفير آلية بديلّة معقولة لواجهة المستخدم لتحديد النص وتعديله، وأن تكون متوافقة مع محرّكات إدارة الإدخال. يتضمّن الإصدار الأحدث من الإصدار المفتوح المصدر من Android آلية اختيار مناسبة للاستخدام مع الأجهزة التي لا تتضمّن إدخالات تنقّل غير تعمل باللمس.
7.2.3. مفاتيح التنقل
إنّ وظائف الصفحة الرئيسية والتطبيقات المستخدَمة مؤخرًا والرجوع ، التي يتم توفيرها عادةً من خلال التفاعل مع زرّ فعلي مخصّص أو جزء محدّد من شاشة اللمس، هي وظائف أساسية لنموذج التنقل في Android وبالتالي لعمليات تنفيذ الأجهزة:
- [C-0-1] يجب توفير عنصر تحكم للمستخدم لتشغيل التطبيقات المثبَّتة
التي لها نشاط مع
<intent-filter>
تم ضبطه علىACTION=MAIN
وCATEGORY=LAUNCHER
أوCATEGORY=LEANBACK_LAUNCHER
لعمليات تنفيذ أجهزة التلفزيون. يجب أن تكون وظيفة "المنزل" هي الآلية التي توفّر هذا الخيار للمستخدم. - يجب أن يوفّر التطبيق زرَّين للوظيفتَين "التطبيقات المستخدَمة مؤخرًا" و"الرجوع".
في حال توفّر وظائف "الصفحة الرئيسية" أو "العناصر الأخيرة" أو "رجوع"، يجب أن تستوفي الشروط التالية:
- [C-1-1] يجب أن يكون بالإمكان الوصول إلى العناصر باستخدام إجراء واحد (مثل النقر أو النقر مرّتين أو إيماءة) عندما يكون بالإمكان الوصول إلى أيّ منها.
- [C-1-2] يجب تقديم إشارة واضحة إلى الإجراء الفردي الذي يؤدي إلى بدء كل وظيفة. ومن الأمثلة على ذلك تضمين رمز مرئي على الزر، أو عرض رمز برنامج على جزء شريط التنقّل من الشاشة، أو توجيه المستخدم خلال مجرى توضيحي إرشادي خطوة بخطوة أثناء تجربة الإعداد خارج العلبة.
عمليات التنفيذ على الأجهزة:
- [C-SR-1] يُنصح بشدة بعدم توفير آلية الإدخال لسمة وظيفة القائمة لأنّها متوقّفة نهائيًا لصالح شريط الإجراءات منذ Android 4.0.
إذا كانت عمليات تنفيذ الأجهزة توفّر وظيفة "القائمة"، يجب أن:
- [C-2-1] يجب عرض زر القائمة المنبثقة لعرض المزيد من الإجراءات عندما لا تكون القائمة المنبثقة لعرض المزيد من الإجراءات فارغة ويكون شريط الإجراءات مرئيًا.
- [C-2-2] يجب عدم تعديل موضع النافذة المنبثقة لعرض الإجراءات الإضافية التي يتم عرضها من خلال النقر على زر القائمة في شريط الإجراءات، ولكن يجوز عرض النافذة المنبثقة لعرض الإجراءات الإضافية في موضع معدَّل على الشاشة عند عرضها من خلال النقر على وظيفة القائمة.
إذا لم توفّر عمليات تنفيذ الأجهزة وظيفة Menu، يجب أن تلتزم بما يلي للحفاظ على التوافق مع الإصدارات القديمة:
- [C-3-1] يجب إتاحة وظيفة "القائمة" للتطبيقات عندما يكون عدد التطبيقات المثبَّتة على الجهاز هو
targetSdkVersion
أقل من 10، إما من خلال زرّ خارجي أو مفتاح برمجي أو إيماءات. يجب أن تكون وظيفة القائمة هذه متاحة للوصول إليها ما لم يتم إخفاؤها مع وظائف التنقّل الأخرى.
إذا كانت عمليات تنفيذ الأجهزة توفّر وظيفة المساعدة، يجب أن تستوفي الشروط التالية:
- [C-4-1] يجب أن تتيح إمكانية الوصول إلى وظيفة "المساعدة" من خلال إجراء واحد (مثل النقر أو النقر مرّتين أو إيماءة) عندما يمكن الوصول إلى مفاتيح التنقّل الأخرى.
- [C-SR-2] يُنصح بشدة باستخدام الضغط مع الاستمرار على وظيفة HOME لأنّه التفاعل المحدّد.
إذا كانت عمليات تنفيذ الأجهزة تستخدِم جزءًا محددًا من الشاشة لعرض مفاتيح التنقّل، يجب أن تستوفي المتطلبات التالية:
- [C-5-1] يجب أن تستخدم مفاتيح التنقّل جزءًا محددًا من الشاشة غير متاح للتطبيقات، ويجب ألّا تحجب أو تتداخل مع الجزء من الشاشة المتاح للتطبيقات.
- [C-5-2] يجب أن يتيح الجهاز جزءًا من الشاشة للتطبيقات التي تفي بالمتطلبات المحدّدة في الفقرة 7.1.1.
- [C-5-3] يجب أن يراعي التطبيق العلامات التي يضبطها من خلال
View.setSystemUiVisibility()
طريقة واجهة برمجة التطبيقات، وذلك لإخفاء هذا الجزء الواضح من الشاشة (المعروف أيضًا باسم شريط التنقّل) بشكلٍ سليم كما هو موضّح في مستندات IDE.
إذا تم توفير وظيفة التنقّل كإجراء على الشاشة يستند إلى الإيماءات:
- [C-6-1]
WindowInsets#getMandatorySystemGestureInsets()
يجب استخدام هذا الرمز فقط للإبلاغ عن منطقة التعرّف على إيماءات Home. - [C-6-2] يجب عدم اعتراض الإيماءات التي تبدأ داخل مستطيل استبعاد كما يقدّمها
التطبيق الذي يعمل في المقدّمة من خلال
View#setSystemGestureExclusionRects()
، ولكن خارجWindowInsets#getMandatorySystemGestureInsets()
، لوظيفة التنقّل ما دام مستطيل الاستبعاد مسموحًا به ضمن الحد الأقصى للاستبعاد على النحو المحدّد في مستنداتView#setSystemGestureExclusionRects()
. - [C-6-3] يجب إرسال حدث
MotionEvent.ACTION_CANCEL
إلى التطبيق المعروض في المقدّمة بعد بدء اعتراض اللمسات لتنفيذ إيماءة نظام، إذا سبق أن تم إرسال حدثMotionEvent.ACTION_DOWN
إلى التطبيق المعروض في المقدّمة. - [C-6-4] يجب أن توفّر ميزة للمستخدم للتبديل إلى تنقّل على الشاشة يستند إلى buttons (مثلاً، في الإعدادات).
- يجب أن توفّر وظيفة "الشاشة الرئيسية" من خلال التمرير سريعًا من الحافة السفلية لاتجاه الشاشة الحالي.
- يجب أن توفّر وظيفة "التطبيقات المستخدَمة مؤخرًا" من خلال التمرير سريعًا للأعلى مع الاستمرار قبل تحرير الإصبع، من المنطقة نفسها التي يتم فيها استخدام إيماءة "الرجوع إلى الشاشة الرئيسية".
- يجب ألا تتأثر الإيماءات التي تبدأ في
WindowInsets#getMandatorySystemGestureInsets()
بأشكال الاستبعاد التي يوفّرها التطبيق في المقدّمة من خلالView#setSystemGestureExclusionRects()
.
إذا تم توفير وظيفة تنقّل من أي مكان على الحافتَين اليسرى واليمنى لاتجاه الشاشة الحالي:
- [C-7-1] يجب أن تكون وظيفة التنقّل هي "رجوع" وأن يتم توفيرها من خلال التمرير سريعًا من كل من الحافة اليسرى واليمنى للاتجاه الحالي للشاشة.
- [C-7-2] في حال توفُّر لوحات نظام مخصّصة يمكن التمرير عليها على الحافة اليسرى أو اليمنى، يجب وضعها في الثلث العلوي من الشاشة مع تقديم إشارة مرئية واضحة ومستمرة بأنّ سحب المحتوى سيؤدي إلى عرض اللوحات المذكورة أعلاه، وبالتالي لن يؤدي إلى عرض رمز الرجوع. يجوز للمستخدم ضبط لوحة النظام بحيث تقع أسفل ثلث أعلى شاشة الحواف، ولكن يجب ألا تستخدم لوحة النظام أكثر من ثلث الحواف.
- [C-7-3] عندما يكون للتطبيق الذي يعمل في المقدّمة علامة التمييز View.SYSTEM_UI_FLAG_IMMERSIVE أو View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY أو WindowInsetsController.BEHAVIOR_DEFAULT أو WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE، يجب أن يكون سلوك التمرير السريع من الحواف كما هو مُطبَّق في AOSP، وهو مُوثَّق في حِزمة تطوير البرامج (SDK).
- [C-7-4] عندما يكون للتطبيق الذي يعمل في المقدّمة علامة View.SYSTEM_UI_FLAG_IMMERSIVE أو View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY أو WindowInsetsController.BEHAVIOR_DEFAULT أو WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE، يجب إخفاء لوحات النظام المخصّصة التي يمكن التمرير عليها إلى أن يعرض المستخدم بارات النظام (المعروفة أيضًا باسم شريط التنقّل وشريط الحالة) أو يزيل تمويهها كما هو معمول به في AOSP.
7.2.4. الإدخال من خلال شاشة تعمل باللمس
يتيح Android استخدام مجموعة متنوعة من أنظمة إدخال المؤشر، مثل الشاشات التي تعمل باللمس ولوحات اللمس وأجهزة إدخال اللمس الزائف. عمليات تنفيذ الأجهزة المستندة إلى الشاشة التي تعمل باللمس: تكون مرتبطة بشاشة بحيث يشعر المستخدم أنّه يشغّل العناصر على الشاشة مباشرةً. بما أنّ المستخدم يلمس الشاشة مباشرةً، لا يتطلّب النظام أيّ عناصر تحكم إضافية للإشارة إلى الأجسام التي يتم التحكّم فيها.
عمليات التنفيذ على الأجهزة:
- يجب أن يتضمّن نظام إدخال مؤشر من نوع ما (إما مثل الماوس أو باللمس).
- يجب أن تتيح استخدام مؤشرات يتم تتبُّعها بشكل مستقل بالكامل.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن شاشة تعمل باللمس (شاشة تعمل باللمس بلمسة واحدة أو أفضل) على شاشة أساسية متوافقة مع Android، يجب استيفاء الشروط التالية:
- [C-1-1] يجب الإبلاغ عن
TOUCHSCREEN_FINGER
لحقل واجهة برمجة التطبيقاتConfiguration.touchscreen
. - [C-1-2] يجب الإبلاغ عن علامتَي ميزة
android.hardware.touchscreen
وandroid.hardware.faketouch
.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن شاشة تعمل باللمس يمكنها تتبُّع أكثر من لمسة واحدة على شاشة أساسية متوافقة مع Android، يجب استيفاء الشروط التالية:
- [C-2-1] يجب الإبلاغ عن علامات الميزات المناسبة
android.hardware.touchscreen.multitouch
،android.hardware.touchscreen.multitouch.distinct
،android.hardware.touchscreen.multitouch.jazzhand
التي تتوافق مع نوع الشاشة التي تعمل باللمس المحدّدة على الجهاز.
إذا كانت عمليات تنفيذ الأجهزة تعتمد على جهاز إدخال خارجي، مثل الماوس أو كرة المسار (أي عدم لمس الشاشة مباشرةً) لإدخال البيانات على شاشة primary متوافقة مع Android واستيفاء متطلبات اللمس الزائف في الفقرة 7.2.5، يجب استيفاء الشروط التالية:
- [C-3-1] يجب عدم الإبلاغ عن أي علامة ميزة تبدأ بالرمز
android.hardware.touchscreen
. - [C-3-2] يجب الإبلاغ عن
android.hardware.faketouch
فقط. - [C-3-3] يجب الإبلاغ عن
TOUCHSCREEN_NOTOUCH
لحقلConfiguration.touchscreen
واجهة برمجة التطبيقات.
7.2.5. الإدخال باللمس الزائف
توفّر واجهة اللمس الزائف نظامًا لإدخال المستخدمين يقارب مجموعة فرعية من إمكانات الشاشة التي تعمل باللمس. على سبيل المثال، يُعدّ الماوس أو جهاز التحكّم عن بُعد الذي يشغّل مؤشرًا على الشاشة مشابهًا لللمس، ولكنّه يتطلّب من المستخدم أولاً الإشارة أو التركيز ثم النقر. يمكن أن تتيح العديد من أجهزة الإدخال، مثل الماوس ولوحة اللمس واللوحة التصويرية المزوّدة بجهاز استشعار الدوران وماوس الهواء المزوّد بجهاز استشعار الدوران والمؤشر المزوّد بجهاز استشعار الدوران وعصا التحكم ولوحة اللمس المزوّدة بتقنية اللمس المتعدّد، تفاعلات مماثلة لللمس. يتضمّن نظام التشغيل Android الثابت المتعلق بالميزة android.hardware.faketouch، والذي يتوافق مع جهاز إدخال عالي الدقة غير مستنِد إلى اللمس (يستند إلى المؤشر)، مثل الماوس أو لوحة اللمس، والذي يمكنه محاكاة الإدخال المستنِد إلى اللمس بشكلٍ كافٍ (بما في ذلك إتاحة الإيماءات الأساسية)، ويشير إلى أنّه يتوافق الجهاز مع مجموعة فرعية محاكية من وظائف الشاشة التي تعمل باللمس.
إذا كانت عمليات تنفيذ الأجهزة لا تتضمّن شاشة تعمل باللمس ولكن تتضمّن نظام إدخال مؤشر آخر يريدون إتاحته، عليهم اتّباع الخطوات التالية:
- يجب الإفصاح عن توافق التطبيق مع علامة ميزة
android.hardware.faketouch
.
إذا كانت عمليات تنفيذ الأجهزة تعلن عن توافقها مع android.hardware.faketouch
،
يجب أن تستوفي الشروط التالية:
- [C-1-1] يجب الإبلاغ عن الموضع المطلق للشاشة على محورَي X وY لموضع المؤشر وعرض مؤشر مرئي على الشاشة.
- [C-1-2] يجب الإبلاغ عن حدث اللمس باستخدام رمز الإجراء الذي يحدّد تغيير الحالة الذي يحدث على المؤشر عند التحرك للأسفل أو للأعلى على الشاشة.
- [C-1-3] يجب أن تتيح أدوات التحكم تحريك المؤشر للأسفل وللأعلى على عنصر على الشاشة، ما يسمح للمستخدمين بمحاكاة النقر على عنصر على الشاشة.
- [C-1-4] يجب أن يتيح استخدام مؤشر الماوس للأسفل ثم للأعلى ثم للأسفل ثم للأعلى في المكان نفسه على عنصر على الشاشة خلال حد زمني معيّن، ما يسمح للمستخدمين بمحاكاة النقر مرّتين على عنصر على الشاشة.
- [C-1-5] يجب أن يتيح المؤشر الانتقال للأسفل في نقطة عشوائية على الشاشة، وانتقال المؤشر إلى أي نقطة عشوائية أخرى على الشاشة، ثم الانتقال للأعلى، ما يتيح للمستخدمين محاكاة السحب باللمس.
- [C-1-6] يجب أن يتيح المؤشر للأسفل للمستخدمين تحريك العنصر بسرعة إلى موضع مختلف على الشاشة ثم المؤشر للأعلى على الشاشة، ما يسمح للمستخدمين برمي عنصر على الشاشة.
إذا كانت عمليات تنفيذ الأجهزة تعلن عن توافقها مع
android.hardware.faketouch.multitouch.distinct
، يعني ذلك ما يلي:
- [C-2-1] يجب الإفصاح عن توافق التطبيق مع
android.hardware.faketouch
. - [C-2-2] يجب أن تتيح إمكانية تتبُّع دقيق لمدخلَين أو أكثر من مدخلات مؤشر مستقلة.
إذا كانت عمليات تنفيذ الأجهزة تعلن عن توافقها مع
android.hardware.faketouch.multitouch.jazzhand
، يعني ذلك ما يلي:
- [C-3-1] يجب الإفصاح عن توافق التطبيق مع
android.hardware.faketouch
. - [C-3-2] يجب أن يتيح الجهاز تتبُّعًا دقيقًا لـ 5 (تتبُّع يد مكوّنة من أصابع) أو أكثر من إشارات المؤشر بشكل مستقل تمامًا.
7.2.6. توافق مع أجهزة التحكّم في الألعاب
7.2.6.1. عمليات ربط الأزرار
عمليات التنفيذ على الأجهزة:
- [C-1-1] يجب أن يكون النظام قادرًا على ربط أحداث HID بثوابت
InputEvent
المقابلة كما هو موضّح في الجداول أدناه. يستوفي تطبيق Android هذا الشرط.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن وحدة تحكّم أو يتم شحنها مع وحدة تحكّم منفصلة في العلبة توفّر وسائل لإدخال جميع الأحداث المدرَجة في الجداول أدناه، يجب استيفاء الشروط التالية:
- [C-2-1] يجب الإفصاح عن علامة الميزة
android.hardware.gamepad
زرّ | استخدام HID2 | زر Android |
---|---|---|
أ1 | 0x09 0x0001 | KEYCODE_BUTTON_A (96) |
ب1 | 0x09 0x0002 | KEYCODE_BUTTON_B (97) |
X1 | 0x09 0x0004 | KEYCODE_BUTTON_X (99) |
نعم1 | 0x09 0x0005 | KEYCODE_BUTTON_Y (100) |
أداة التوجيه العلوية1 أداة التوجيه السفلية1 |
0x01 0x00393 | AXIS_HAT_Y4 |
الزر الأيسر في لوحة التحكم1 الزر الأيمن في لوحة التحكم1 |
0x01 0x00393 | AXIS_HAT_X4 |
زرّ أعلى ذراع التحكّم الأيسر1 | 0x09 0x0007 | KEYCODE_BUTTON_L1 (102) |
زرّ أعلى ذراع التحكّم الأيمن1 | 0x09 0x0008 | KEYCODE_BUTTON_R1 (103) |
النقر على العصا اليسرى1 | 0x09 0x000E | KEYCODE_BUTTON_THUMBL (106) |
النقر على ذراع التحكم الأيمن1 | 0x09 0x000F | KEYCODE_BUTTON_THUMBR (107) |
رجوع1 | 0x0c 0x0224 | KEYCODE_BACK (4) |
1 KeyEvent
2 يجب الإفصاح عن استخدامات HID المذكورة أعلاه ضمن CA لجهاز تحكّم في الألعاب (0x01 0x0005).
3 يجب أن يكون الحد الأدنى المنطقي لهذا الاستخدام هو 0، والحد الأقصى المنطقي هو 7، والحد الأدنى المادي هو 0، والحد الأقصى المادي هو 315، والوحدات بالدرجات، وحجم التقرير هو 4. يتم تعريف القيمة المنطقية على أنّها الدوران باتجاه عقارب الساعة بعيدًا عن المحور العمودي. على سبيل المثال، تمثل القيمة المنطقية 0 عدم دوران ويتم الضغط على الزر "أعلى"، في حين تمثل القيمة المنطقية 1 دورانًا بزاوية 45 درجة ويتم الضغط على كل من الزرَّين "أعلى" و"يسار".
4 MotionEvent
عناصر التحكّم التناظرية1 | استخدام HID | زر Android |
---|---|---|
المشغِّل الأيسر | 0x02 0x00C5 | AXIS_LTRIGGER |
مشغِّل الإجراء الأيمن | 0x02 0x00C4 | AXIS_RTRIGGER |
ذراع التحكّم الأيسر | 0x01 0x0030 0x01 0x0031 |
AXIS_X AXIS_Y |
ذراع التحكّم الأيمن | 0x01 0x0032 0x01 0x0035 |
AXIS_Z AXIS_RZ |
1 MotionEvent
7.2.7. جهاز التحكّم عن بُعد
اطّلِع على الفقرة 2.3.1 لمعرفة المتطلبات الخاصة بالأجهزة.
7.3. أجهزة الاستشعار
إذا كانت عمليات تنفيذ الأجهزة تتضمّن نوعًا معيّنًا من أجهزة الاستشعار يتضمّن واجهة برمجة تطبيقات مقابلة للمطوّرين التابعين لجهات خارجية، يجب أن تُنفِّذ عملية تنفيذ الجهاز واجهة برمجة التطبيقات هذه على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android ومستندات أجهزة الاستشعار في المصدر المفتوح لنظام التشغيل Android.
عمليات التنفيذ على الأجهزة:
- [C-0-1] يجب الإبلاغ بدقة عن توفّر أدوات الاستشعار أو عدم توفّرها وفقًا ل
android.content.pm.PackageManager
الفئة. - [C-0-2] يجب أن يعرض التطبيق قائمة دقيقة بأجهزة الاستشعار المتوافقة من خلال
SensorManager.getSensorList()
والطرق المشابهة. - [C-0-3] يجب أن تعمل بشكل معقول مع جميع واجهات برمجة التطبيقات الأخرى الخاصة بأجهزة الاستشعار (على سبيل المثال، عن طريق
عرض
true
أوfalse
حسب الاقتضاء عندما تحاول التطبيقات تسجيل المستمعين، وعدم استدعاء مستمعي أجهزة الاستشعار عندما لا تكون أجهزة الاستشعار المقابلة متوفّرة، وما إلى ذلك).
إذا كانت عمليات تنفيذ الأجهزة تتضمّن نوعًا معيّنًا من أجهزة الاستشعار التي تحتوي على IDE corresponding API للمطوّرين التابعين لجهات خارجية، عليهم:
- [C-1-1] يجب الإبلاغ عن جميع قياسات أجهزة الاستشعار باستخدام قيم النظام الدولي للوحدات (المقياس) ذات الصلة لكل نوع من أجهزة الاستشعار كما هو محدّد في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
- [C-1-2] يجب الإبلاغ عن بيانات أجهزة الاستشعار بحد أقصى لمُدد الاستجابة يبلغ 100 ملي ثانية + 2 * وقت_التحليل في حال بث بيانات أجهزة الاستشعار بحد أقصى لمُدد الاستجابة المطلوبة يبلغ 0 ملي ثانية عندما يكون معالج التطبيقات نشطًا. ولا يشمل هذا التأخير أي تأخيرات في الفلترة.
- [C-1-3] يجب الإبلاغ عن أول عيّنة من بيانات المستشعر في غضون 400 ملي ثانية + 2 * وقت_العيّنة من وقت تفعيل المستشعر. من المقبول أن تبلغ دقة هذه العيّنة 0.
- [C-1-4] بالنسبة إلى أيّ واجهة برمجة تطبيقات يشير مستند حزمة تطوير البرامج (SDK) لنظام التشغيل Android إلى أنّها جهاز استشعار مستمر، يجب أن تقدّم عمليات تنفيذ الأجهزة باستمرار عيّنات بيانات دورية يجب أن يكون لها انحرافًا أقل من %3، حيث يتم تعريف الانحراف على أنّه التباين المعياري للفرق بين قيم الطوابع الزمنية المسجّلة بين الأحداث المتتالية.
- [C-1-5] يجب التأكّد من أنّه يجب ألا يمنع بث أحداث الاستشعار وحدة المعالجة المركزية (CPU) في الجهاز من الدخول في حالة تعليق أو الاستيقاظ من حالة تعليق.
- [C-1-6] يجب تسجيل وقت الحدث بالنانو ثانية كما هو محدّد في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android، ما يمثّل وقت وقوع الحدث ومزامنة مع الساعة SystemClock.elapsedRealtimeNano().
- [C-SR-1] يُنصح بشدة بأن يكون خطأ مزامنة الطابع الزمني أقل من 100 مللي ثانية، ويجب أن يكون خطأ مزامنة الطابع الزمني أقل من 1 مللي ثانية.
- عند تفعيل عدة أدوات استشعار، يجب ألا يتجاوز استهلاك الطاقة مجموع استهلاك الطاقة المسجَّل لكل أداة استشعار فردية.
القائمة أعلاه ليست شاملة، ويجب اعتبار السلوك الموثَّق لحزمة SDK لنظام التشغيل Android ومستندات Android Open Source حول أجهزة الاستشعار مرجعيًا.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن نوعًا معيّنًا من أجهزة الاستشعار التي تحتوي على IDE corresponding API للمطوّرين التابعين لجهات خارجية، عليهم:
- [C-1-6] يجب ضبط درجة دقة غير صفرية لجميع أجهزة الاستشعار والإبلاغ عن القيمة
من خلال
Sensor.getResolution()
طريقة واجهة برمجة التطبيقات.
بعض أنواع أجهزة الاستشعار مركبة، ما يعني أنّه يمكن الحصول عليها من بيانات يوفّرها جهاز استشعار واحد أو أكثر. (تشمل الأمثلة أداة استشعار الاتجاه ومقاييس التسارع الخطي).
عمليات التنفيذ على الأجهزة:
- يجب تنفيذ أنواع أجهزة الاستشعار هذه، عندما تشمل أجهزة الاستشعار المادية المطلوبة كما هو موضّح في أنواع أجهزة الاستشعار.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن أداة استشعار مركبة، يجب استيفاء الشروط التالية:
- [C-2-1] يجب تنفيذ أداة الاستشعار كما هو موضّح في مستندات أجهزة الاستشعار المركبة المتوفّرة في المصدر المفتوح لنظام التشغيل Android.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن نوعًا معيّنًا من أجهزة الاستشعار يحتوي على واجهة برمجة تطبيقات مكافئة للمطوّرين التابعين لجهات خارجية، ولا يُبلِغ جهاز الاستشعار إلا عن قيمة واحدة، تكون عمليات تنفيذ الأجهزة:
- [C-3-1] يجب ضبط درجة الدقة على 1 لجهاز الاستشعار والإبلاغ عن القيمة
من خلال طريقة واجهة برمجة التطبيقات
Sensor.getResolution()
.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن نوعًا معيّنًا من أجهزة الاستشعار يتيح استخدام SensorAdditionalInfo#TYPE_VEC3_CALIBRATION وكانت أجهزة الاستشعار متاحة للمطوّرين التابعين لجهات خارجية، يمكنهم إجراء ما يلي:
- [C-4-1] يجب عدم تضمين أي مَعلمات قياس ثابتة تحدّدها الشركة المصنّعة في البيانات المقدَّمة.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن مجموعة من أدوات قياس التسارع بثلاثة محاور أو جهاز استشعار جيروسكوب بثلاثة محاور أو جهاز استشعار مقياس مغناطيسي، تكون على النحو التالي:
- [C-SR-2] يُنصح بشدة بضمان أن يكون لمقياس التسارع والجيروسكوب ومقاييس المغناطيسية موضع نسبي ثابت، بحيث إذا كان الجهاز قابلاً للتحويل (مثلاً قابلاً للطي)، تظل محاور أداة الاستشعار متوافقة ومتسقة مع نظام إحداثيات أداة الاستشعار في جميع حالات التحويل المحتمَلة للجهاز.
7.3.1. مقياس التسارع
عمليات التنفيذ على الأجهزة:
- [C-SR-1] يُنصح بشدة بتضمين مقياس تسارع ثلاثي المحاور.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقياس تسارع ثلاثي المحاور، يجب استيفاء الشروط التالية:
- [C-1-1] يجب أن يكون الجهاز قادرًا على تسجيل الأحداث بمعدّل تكرار لا يقل عن 50 هرتز.
- [C-1-2] يجب تنفيذ
TYPE_ACCELEROMETER
جهاز الاستشعار والإبلاغ عنه. - [C-1-3] يجب أن تكون متوافقة مع نظام إحداثيات أدوات استشعار Android كما هو موضّح بالتفصيل في واجهات برمجة تطبيقات Android.
- [C-1-4] يجب أن يكون الجهاز قادرًا على قياس التسارع من السقوط الحر إلى أربع مرات كثافة الجاذبية(4g) أو أكثر على أي محور.
- [C-1-5] يجب أن تكون درجة دقة الصورة 12 بت على الأقل.
- [C-1-6] يجب أن يكون التباين المعياري لا يزيد عن 0.05 متر في الثانية المربعة، حيث يجب احتساب التباين المعياري لكل محور على أساس عيّنات يتم جمعها على مدار 3 ثوانٍ على الأقل بأسرع معدّل تحليل.
- يُنصح بشدة باستخدام [C-SR-2] لتنفيذ أداة الاستشعار
TYPE_SIGNIFICANT_MOTION
المركّبة. - [C-SR-3] يُنصح بشدة بتنفيذ
TYPE_ACCELEROMETER_UNCALIBRATED
الاستشعار والإبلاغ عنه. ننصح بشدة بتوافق أجهزة Android مع هذا الشرط حتى تتمكّن من الترقية إلى إصدار المنصة المستقبلي الذي قد يصبح فيه هذا الشرط مطلوبًا. - يجب تنفيذ أدوات الاستشعار المركبة
TYPE_SIGNIFICANT_MOTION
وTYPE_TILT_DETECTOR
TYPE_STEP_DETECTOR
وTYPE_STEP_COUNTER
كما هو موضّح في مستند حزمة تطوير البرامج (SDK) لنظام التشغيل Android. - يجب الإبلاغ عن الأحداث التي تصل إلى 200 هرتز على الأقل.
- يجب أن تكون درجة دقتها 16 بت على الأقل.
- يجب معايرة هذه الخصائص أثناء الاستخدام إذا تغيّرت على مدار دورة الحياة، ويجب تعويضها والحفاظ على مَعلمات التعويض بين عمليات إعادة تشغيل الجهاز.
- يجب أن يتم تصحيحها حسب درجة الحرارة.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن أداة تسارع 3 محاور وأيًا من أجهزة الاستشعار المركبة
TYPE_SIGNIFICANT_MOTION
وTYPE_TILT_DETECTOR
وTYPE_STEP_DETECTOR
TYPE_STEP_COUNTER
:
- [C-2-1] يجب أن يكون مجموع استهلاك الطاقة أقل من 4 ملي واط في أي وقت.
- يجب أن يكون كل منهما أقل من 2 ملي واط و0.5 ملي واط عندما يكون الجهاز في حالة ديناميكية أو ساكنة.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقياس تسارع ثلاثي المحاور وجهاز استشعار جيروسكوب ثلاثي المحاور، يجب أن:
- [C-3-1] يجب تنفيذ أداتَي الاستشعار المركبتَين
TYPE_GRAVITY
وTYPE_LINEAR_ACCELERATION
. - [C-SR-4] يُنصح بشدة بتنفيذ أداة الاستشعار المركبة
TYPE_GAME_ROTATION_VECTOR
.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقياس تسارع ثلاثي المحاور وجهاز استشعار جيروسكوب ثلاثي المحاور وجهاز استشعار للمغناطيسية، يجب استيفاء الشروط التالية:
- [C-4-1] يجب استخدام أداة استشعار مركبة
TYPE_ROTATION_VECTOR
.
7.3.2. مقياس المغناطيسية
عمليات التنفيذ على الأجهزة:
- [C-SR-1] يُنصح بشدة بتضمين مقياس مغناطيسي ثلاثي المحاور (بوصلة).
إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقياس مغناطيسية بثلاثة محاور، يجب استيفاء الشروط التالية:
- [C-1-1] يجب تنفيذ أداة استشعار
TYPE_MAGNETIC_FIELD
. - [C-1-2] يجب أن يكون الجهاز قادرًا على تسجيل الأحداث بمعدّل تكرار لا يقل عن 10 هرتز، ويجب أن يسجِّل الأحداث بمعدّل تكرار لا يقل عن 50 هرتز.
- [C-1-3] يجب أن يكون متوافقًا مع نظام إحداثيات أدوات استشعار Android كما هو موضّح بالتفصيل في واجهات برمجة تطبيقات Android.
- [C-1-4] يجب أن يكون الجهاز قادرًا على قياس قيم تتراوح بين -900 و+900 µT على كل محور قبل الوصول إلى التشبع.
- [C-1-5] يجب أن تكون قيمة إزاحة الحديد الصلب أقل من 700 ميكرو تسلا، ويجب أن تكون قيمتها أقل من 200 ميكرو تسلا، وذلك من خلال وضع مقياس المغناطيسية بعيدًا عن الحقول المغناطيسية الديناميكية (المُنشأة بالتيار الكهربي) والثابتة (المُنشأة بالمغناطيس).
- [C-1-6] يجب أن تكون درجة الدقة مساوية أو أعلى من 0.6 ميكرو تسلا.
- [C-1-7] يجب أن يتيح الجهاز معايرة الانحراف المغناطيسي للحديد الصلب وإصلاحه على الإنترنت، والحفاظ على مَعلمات التعويض بين عمليات إعادة تشغيل الجهاز.
- [C-1-8] يجب تطبيق التعويض عن الحديد اللين، ويمكن إجراء المعايرة أثناء الاستخدام أو أثناء إنتاج الجهاز.
- [C-1-9] يجب أن يكون الانحراف المعياري، الذي يتم احتسابه لكل محور على أساس العينات التي تم جمعها على مدار فترة لا تقل عن 3 ثوانٍ بأسرع معدل جمع عينات، لا يزيد عن 1.5 ميكرو تسلا، ويجب أن يكون الانحراف المعياري لا يزيد عن 0.5 ميكرو تسلا.
- [C-1-10] يجب تنفيذ ميزة
TYPE_MAGNETIC_FIELD_UNCALIBRATED
الاستشعار.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقياس مغناطيسية ثلاثي المحاور ومقياس تسارع وجهاز استشعار جيروسكوب ثلاثي المحاور، يجب استيفاء الشروط التالية:
- [C-2-1] يجب تنفيذ أداة استشعار مركبة
TYPE_ROTATION_VECTOR
.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقياس مغناطيسية ثلاثي المحاور ومقياس تسارع، يجب استيفاء الشروط التالية:
- يجوز تنفيذ أداة استشعار
TYPE_GEOMAGNETIC_ROTATION_VECTOR
.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقياس مغناطيسية ثلاثي المحاور ومقياس تسارع وجهاز استشعار
TYPE_GEOMAGNETIC_ROTATION_VECTOR
، يجب استيفاء الشروط التالية:
- [C-3-1] يجب أن يستهلك الجهاز طاقة أقل من 10 ملي واط.
- يجب أن يستهلك طاقة أقل من 3 ملي واط عند تسجيل المستشعر في وضع الحِزم بمعدل 10 هرتز.
7.3.3. نظام تحديد المواقع العالمي (GPS)
عمليات التنفيذ على الأجهزة:
- [C-SR-1] يُنصح بشدة بتضمين جهاز استقبال GPS/GNSS.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن جهاز استقبال لنظام تحديد المواقع العالمي (GPS) أو نظام تحديد المواقع العالمي (GNSS) وتُبلغ عن إمكانية
استخدام التطبيقات من خلال علامة ميزة android.hardware.location.gps
، يجب استيفاء الشروط التالية:
- [C-1-1] يجب أن تتيح مخرجات الموقع الجغرافي بمعدّل لا يقل عن 1 هرتز عند طلبها من خلال
LocationManager#requestLocationUpdate
. - [C-1-2] يجب أن يكون الجهاز قادرًا على تحديد الموقع الجغرافي في ظروف السماء المفتوحة
(إشارات قوية، ومسارات متعددة لا يُعتد بها، وHDOP < 2) في غضون 10 ثوانٍ (وقت تحديد الموقع الجغرافي الأول سريع)، عند الاتصال بالإنترنت بسرعة بيانات تبلغ 0.5 ميغابت في الثانية أو أكثر. يتم عادةً استيفاء هذا الشرط من خلال استخدام أحد أشكال تقنية GPS/GNSS المساعدة أو المتوقّعة لخفض وقت الربط بنظام GPS/GNSS إلى الحد الأدنى (تشمل بيانات المساعدة الوقت المرجعي والموقع الجغرافي المرجعي وجدول المدّ والجزر للأقمار الصناعية/الساعة).
- [C-1-6] بعد إجراء عملية احتساب الموقع الجغرافي هذه، يجب أن تحدِّد عمليات تنفيذ التطبيقات على الجهاز موقعه الجغرافي في السماء المفتوحة في غضون 5 ثوانٍ عند إعادة تشغيل طلبات الموقع الجغرافي، ويجب أن يتم ذلك في غضون ساعة واحدة كحد أقصى من احتساب الموقع الجغرافي الأولي، حتى في حال إجراء الطلب التالي بدون اتصال بالبيانات و/أو بعد إعادة تشغيل الجهاز.
في ظروف السماء المفتوحة بعد تحديد الموقع الجغرافي، أثناء الثبات أو الحركة بسرعة تسارع أقل من متر واحد في الثانية المربعة:
- [C-1-3] يجب أن يكون الجهاز قادرًا على تحديد الموقع الجغرافي ضمن نطاق 20 مترًا، وسرعة التنقّل ضمن نطاق 0.5 متر في الثانية، في% 95 من الوقت على الأقل.
- [C-1-4] يجب تتبُّع 8 أقمار صناعية على الأقل من مجموعة نجوم واحدة والإبلاغ عنها في الوقت نفسه من خلال
GnssStatus.Callback
. - يجب أن يكون الجهاز قادرًا على تتبُّع 24 قمرًا صناعيًا على الأقل في وقت واحد من أنظمة تحديد المواقع المتعدّدة (مثل نظام تحديد المواقع العالمي (GPS) ونظام GLONASS ونظام Beidou ونظام Galileo على الأقل).
[C-SR-2] يُنصح بشدة بمواصلة عرض نتائج الموقع الجغرافي العادية من خلال واجهات برمجة التطبيقات GNSS Location Provider API أثناء مكالمة هاتفية للطوارئ.
[C-SR-3] يُنصح بشدة بالإبلاغ عن قياسات نظام تحديد المواقع العالمي (GNSS) من جميع المجموعات النجمية التي يتم تتبُّعها (كما هو موضّح في رسائل GnssStatus)، باستثناء نظام SBAS.
[C-SR-4] يُنصح بشدة بالإبلاغ عن AGC ومعدّل قياس GNSS.
[C-SR-5] يُنصح بشدة بالإبلاغ عن جميع تقديرات الدقة (بما في ذلك الاتجاه والسرعة والقيمة العمودية) كجزء من كل موقع جغرافي لنظام تحديد المواقع العالمي (GPS) أو نظام تحديد المواقع العالمي (GNSS).
[C-SR-6] يُنصح بشدة بالإبلاغ عن قياسات نظام تحديد المواقع العالمي (GNSS) فورًا عند العثور عليها، حتى إذا لم يتم الإبلاغ عن موقع جغرافي تم احتسابه من نظام تحديد المواقع العالمي (GPS)/نظام تحديد المواقع العالمي (GNSS).
[C-SR-7] يُنصح بشدة بالإبلاغ عن نطاقات GNSS الزائفة ومقدّرات النطاقات الزائفة، والتي تكون كافية لاحتساب الموقع الجغرافي ضمن 20 مترًا والسرعة ضمن 0.2 متر في الثانية في 95% من الوقت على الأقل، وذلك في ظروف السماء المفتوحة بعد تحديد الموقع الجغرافي، سواء كان الجهاز ثابتًا أو متحركًا بمعدّل تسارع أقل من 0.2 متر في الثانية المربعة.
7.3.4. الجيروسكوب
عمليات التنفيذ على الأجهزة:
- [C-SR-1] يُنصح بشدة بتضمين أداة استشعار جيروسكوب.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن جيروسكوبًا ثلاثي المحاور، يجب استيفاء الشروط التالية:
- [C-1-1] يجب أن يكون الجهاز قادرًا على تسجيل الأحداث بمعدّل تكرار لا يقل عن 50 هرتز.
- [C-1-2] يجب تنفيذ أداة استشعار
TYPE_GYROSCOPE
. - [C-1-4] يجب أن تكون درجة دقة الصورة 12 بت أو أكثر.
- [C-1-5] يجب أن يكون مُعدَّلاً للحرارة.
- [C-1-6] يجب معايرة الجهاز وتعويضه أثناء الاستخدام، والحفاظ على مَعلمات التعويض بين عمليات إعادة تشغيل الجهاز.
- [C-1-7] يجب ألا يزيد التباين عن 1e-7 rad^2 / s^2 لكل هرتز (التباين لكل هرتز أو rad^2 / s). يُسمح باختلاف التباين مع معدل أخذ العينات، ولكن يجب أن يكون مقيّدًا بهذه القيمة. بعبارة أخرى، إذا measuredيتم قياس التباين في أداة الاستشعار الدوراني بمعدّل أخذ عينات يبلغ 1 هرتز، يجب ألا يزيد عن 1e-7 rad^2/s^2.
- [C-SR-2] يُنصح بشدة بأن يكون خطأ المعايرة أقل من 0.01 راد/ث عندما يكون الجهاز ثابتًا في درجة حرارة الغرفة.
- [C-SR-3] ننصح بشدة بتنفيذ أداة الاستشعار
TYPE_GYROSCOPE_UNCALIBRATED
. - [C-SR-4] يُنصح بشدة بدرجة دقة 16 بت أو أكثر.
- يجب الإبلاغ عن الأحداث التي تصل إلى 200 هرتز على الأقل.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن جيروسكوبًا ثلاثي المحاور وجهاز استشعار تسارع وجهاز استشعار مغناطيسية، يجب استيفاء الشروط التالية:
- [C-2-1] يجب تنفيذ أداة استشعار مركبة
TYPE_ROTATION_VECTOR
.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقياس تسارع ثلاثي المحاور وجهاز استشعار دوار ثلاثي المحاور، يجب استيفاء الشروط التالية:
- [C-3-1] يجب تنفيذ أداتَي الاستشعار المركبتَين
TYPE_GRAVITY
وTYPE_LINEAR_ACCELERATION
. - [C-SR-5] يُنصح بشدة بتنفيذ أداة الاستشعار المركبة
TYPE_GAME_ROTATION_VECTOR
.
7.3.5. مقياس الضغط الجوي
عمليات التنفيذ على الأجهزة:
- [C-SR-1] يُنصح بشدة بتضمين مقياس ضغط جوي (جهاز استشعار ضغط الهواء المحيط).
إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقياس ضغط جوي، يجب استيفاء الشروط التالية:
- [C-1-1] يجب تنفيذ
TYPE_PRESSURE
sensor والإبلاغ عنه. - [C-1-2] يجب أن يكون الجهاز قادرًا على إرسال الأحداث بمعدّل 5 هرتز أو أكثر.
- [C-1-3] يجب أن يكون مُعدَّلاً للحرارة.
- [C-SR-2] يُنصح بشدة بإمكانية تسجيل قياسات الضغط في النطاق من 300hPa إلى 1100hPa.
- يجب أن تكون الدقة المطلقة 1hPa.
- يجب أن تكون الدقة النسبية 0.12hPa على نطاق 20hPa (أي ما يعادل دقة متر واحد تقريبًا على نطاق 200 متر تقريبًا على مستوى سطح البحر).
7.3.6. مقياس درجة الحرارة
إذا كانت عمليات تنفيذ الأجهزة تتضمّن ميزان حرارة للبيئة المحيطة (أداة استشعار درجة الحرارة)، يجب أن تستوفي الشروط التالية:
- [C-1-1] يجب تحديد
SENSOR_TYPE_AMBIENT_TEMPERATURE
لجهاز استشعار درجة الحرارة المحيطة، ويجب أن يقيس الجهاز درجة الحرارة المحيطة (درجة حرارة الغرفة أو مقصورة المركبة) من حيث يتفاعل المستخدم مع الجهاز بالدرجات المئوية.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن أداة استشعار ميزان حرارة تقيس درجة حرارة غير درجة الحرارة المحيطة، مثل درجة حرارة وحدة المعالجة المركزية، يجب استيفاء الشروط التالية:
- [C-2-1] يجب عدم تحديد
SENSOR_TYPE_AMBIENT_TEMPERATURE
لجهاز استشعار الحرارة.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن أداة استشعار لمراقبة درجة حرارة الجلد، يجب استيفاء الشروط التالية:
- [C-SR-1] يُنصح بشدة بتوفُّر واجهة برمجة التطبيقات PowerManager.getThermalHeadroom.
7.3.7. مقياس الإضاءة
- قد تتضمّن عمليات تنفيذ الأجهزة مقياسًا للضوء (أداة استشعار الضوء المحيط).
7.3.8. أداة استشعار التقارب
- قد تتضمّن عمليات تنفيذ الأجهزة أداة استشعار التقارب.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن أداة استشعار التقارب ولا تُبلغ إلا عن قراءة ثنائية "قريب" أو "بعيد"، يجب أن تستوفي الشروط التالية:
- [C-1-1] يجب قياس مدى قرب الجسم من الشاشة في الاتجاه نفسه. وهذا يعني أنّه يجب توجيه أداة استشعار التقارب لرصد الأجسام بالقرب من الشاشة، لأنّ الغرض الأساسي من هذا النوع من أدوات الاستشعار هو رصد هاتف يستخدمه المستخدم. إذا كانت عمليات تنفيذ الأجهزة تتضمّن مستشعر قرب مع أي اتجاه آخر، يجب عدم السماح بالوصول إليه من خلال واجهة برمجة التطبيقات هذه.
- [C-1-2] يجب أن تكون الدقة 1 بت أو أكثر.
- [C-1-3] يجب استخدام 0 سنتيمتر كقراءة قريبة و5 سنتيمترات كقراءة بعيدة.
- [C-1-4] يجب أن يُبلغ عن الحد الأقصى للنطاق ودرجة الدقة 5.
7.3.9. أجهزة الاستشعار العالية الدقة
إذا كانت عمليات تنفيذ الأجهزة تتضمّن مجموعة من أجهزة الاستشعار ذات الجودة العالية كما هو محدّد في هذا القسم، وتوفّرها للتطبيقات التابعة لجهات خارجية، يجب استيفاء الشروط التالية:
- [C-1-1] يجب تحديد الميزة من خلال علامة الميزة
android.hardware.sensor.hifi_sensors
.
إذا كانت عمليات تنفيذ الأجهزة تعرِض android.hardware.sensor.hifi_sensors
،
تُطبَّق الإجراءات التالية:
[C-2-1] يجب أن يتضمّن جهازك أداة استشعار
TYPE_ACCELEROMETER
تستوفي الشروط التالية:- يجب أن يكون نطاق القياس بين -8 غرام و+8 غرام على الأقل، ويُنصح بشدة بأن يكون نطاق القياس بين -16 غرام و+16 غرام على الأقل.
- يجب أن يكون دقة القياس 2048 LSB/g على الأقل.
- يجب أن يكون الحد الأدنى لعدد مرات القياس 12.5 هرتز أو أقل.
- يجب أن يكون الحد الأقصى لعدد مرات القياس 400 هرتز أو أعلى، ويجب أن يكون متوافقًا مع SensorDirectChannel
RATE_VERY_FAST
. - يجب أن يكون التشويش في القياس أقل من 400 ميكروغرام/√هرتز.
- يجب استخدام شكل غير مُشغِّل لهذا المستشعر مع ميزة معالجة مؤقتة لأحداث المستشعر التي لا تقل عن 3000 حدث.
- يجب أن يكون استهلاك الطاقة في وضع "المعالجة المجمّعة" لا يزيد عن 3 ملي واط.
- [C-SR-1] يُنصح بشدة بتوفير نطاق قياس 3 ديسيبل لا يقل عن% 80 من تردد Nyquist، ويجب أن يكون نطاق الضوضاء البيضاء ضمن هذا النطاق.
- يجب أن يكون هناك انحراف عشوائي للتسارع أقل من 30 μg √Hz تم اختباره عند درجة حرارة الغرفة.
- من المفترض أن يكون هناك تغيير في الانحياز مقابل درجة الحرارة بمقدار 1 مجم/درجة مئوية كحد أقصى أو أدنى.
- يجب أن يكون خط أفضل الملاءمة غير خطي بنسبة ≤ 0.5%، ويجب أن يكون تغيير الحساسية حسب درجة الحرارة ≤ 0.03%/درجة مئوية.
- يجب أن تكون حساسية المحاور المتقاطعة أقل من % 2.5 وأن يكون التباين في حساسية المحاور المتقاطعة أقل من% 0.2 في نطاق درجة حرارة تشغيل الجهاز.
[C-2-2] يجب أن يكون لدى
TYPE_ACCELEROMETER_UNCALIBRATED
متطلبات الجودة نفسها التي يتطلبهاTYPE_ACCELEROMETER
.[C-2-3] يجب أن يتضمّن جهازك أداة استشعار
TYPE_GYROSCOPE
تستوفي الشروط التالية:- يجب أن يكون نطاق القياس بين -1000 و1000 دورة في الثانية على الأقل.
- يجب أن تكون دقة القياس 16 LSB/dps على الأقل.
- يجب أن يكون الحد الأدنى لعدد مرات القياس 12.5 هرتز أو أقل.
- يجب أن يكون الحد الأقصى لعدد مرات القياس 400 هرتز أو أعلى، ويجب أن يكون متوافقًا مع SensorDirectChannel
RATE_VERY_FAST
. - يجب أن يكون التشويش في القياس أقل من 0.014 درجة في الثانية لكل جذر هرتز.
- [C-SR-2] يُنصح بشدة بتوفير نطاق قياس 3 ديسيبل لا يقل عن% 80 من تردد Nyquist، ويجب أن يكون نطاق قياس الضوضاء البيضاء ضمن هذا النطاق.
- يجب أن يكون معدل التنقّل العشوائي أقل من 0.001 درجة/ثانية √هرتز عند اختباره في درجة حرارة الغرفة.
- يجب أن يكون هناك تغيير في الانحياز مقارنةً بدرجة الحرارة بمقدار 0.05 درجة / ثانية / درجة مئوية كحد أقصى أو أدنى.
- يجب أن يكون هناك تغيير في الحساسية مقارنةً بدرجة الحرارة بمقدار 0.02% / درجة مئوية كحد أقصى.
- يجب أن يكون الخط الأنسب غير خطي بنسبة لا تزيد عن %0.2.
- يجب أن تكون كثافة الضوضاء ≤ 0.007 درجة/ثانية/√هرتز.
- يجب أن يكون خطأ المعايرة أقل من 0.002 راد/ثانية في نطاق درجة الحرارة من 10 إلى 40 درجة مئوية عندما يكون الجهاز ثابتًا.
- يجب أن تكون حساسية التسارع أقل من 0.1 درجة في الثانية لكل متر في الثانية.
- يجب أن تكون الحساسية على جميع المحاور أقل من % 4.0 وأن يكون التباين في الحساسية على جميع المحاور أقل من% 0.3 في نطاق درجة حرارة تشغيل الجهاز.
[C-2-4] يجب أن يتضمّن
TYPE_GYROSCOPE_UNCALIBRATED
متطلبات الجودة نفسها التي يتضمّنهاTYPE_GYROSCOPE
.[C-2-5] يجب أن يكون الجهاز مزوّدًا بمستشعر
TYPE_GEOMAGNETIC_FIELD
يستوفي الشروط التالية:- يجب أن يكون نطاق القياس بين -900 و+900 μT على الأقل.
- يجب أن يكون دقة القياس 5 LSB/uT على الأقل.
- يجب أن يكون الحد الأدنى لعدد مرات القياس 5 هرتز أو أقل.
- يجب أن يكون الحد الأقصى لعدد مرات القياس 50 هرتز أو أعلى.
- يجب أن يكون التشويش في القياس أقل من 0.5 ميكرو تسلا.
[C-2-6] يجب أن يتضمّن
TYPE_MAGNETIC_FIELD_UNCALIBRATED
متطلبات الجودة نفسها التي يتضمّنهاTYPE_GEOMAGNETIC_FIELD
، بالإضافة إلى ما يلي:- يجب استخدام شكل غير مُشغِّل لهذا المستشعر مع ميزة معالجة مؤقتة لأحداث المستشعر التي لا تقل عن 600 حدث.
- [C-SR-3] يُنصح بشدة بتوفير نطاق للضوضاء البيضاء من 1 هرتز إلى 10 هرتز على الأقل عندما يكون معدّل الإبلاغ 50 هرتز أو أعلى.
[C-2-7] يجب أن يتضمّن جهاز
TYPE_PRESSURE
أداة استشعار تستوفي الشروط التالية:- يجب أن يكون نطاق القياس بين 300 و1100 hPa على الأقل.
- يجب أن يكون دقة القياس 80 LSB/hPa على الأقل.
- يجب أن يكون الحد الأدنى لعدد مرات القياس 1 هرتز أو أقل.
- يجب أن يكون الحد الأقصى لعدد مرات القياس 10 هرتز أو أعلى.
- يجب أن يكون التشويش في القياس أقل من 2 باسكال/√هرتز.
- يجب استخدام شكل غير مُشغِّل لهذا المستشعر مع ميزة معالجة مؤقتة تسمح بتسجيل 300 حدث على الأقل من أدوات الاستشعار.
- يجب أن يكون استهلاك الطاقة في وضع "المعالجة المجمّعة" لا يزيد عن 2 ملي واط.
[C-2-8] يجب أن يتضمّن جهازك أداة استشعار
TYPE_GAME_ROTATION_VECTOR
.[C-2-9] يجب أن يتضمّن جهازك أداة استشعار
TYPE_SIGNIFICANT_MOTION
تستوفي الشروط التالية:- يجب أن يكون استهلاك الطاقة أقل من 0.5 ملي واط عندما يكون الجهاز ثابتًا و1.5 ملي واط عندما يكون الجهاز متحركًا.
[C-2-10] يجب أن يتضمّن جهازك أداة استشعار
TYPE_STEP_DETECTOR
تستوفي الشروط التالية:- يجب تنفيذ شكل غير مُشغِّل لهذا المستشعر مع ميزة معالجة مؤقتة لأحداث المستشعر التي لا تقل عن 100 حدث.
- يجب أن يكون استهلاك الطاقة أقل من 0.5 ملي واط عندما يكون الجهاز ثابتًا و1.5 ملي واط عندما يكون الجهاز متحركًا.
- يجب أن يكون استهلاك الطاقة في وضع "المعالجة المجمّعة" لا يزيد عن 4 ملي واط.
[C-2-11] يجب أن يكون الجهاز مزوّدًا بجهاز استشعار
TYPE_STEP_COUNTER
يستوفي الشروط التالية:- يجب أن يكون استهلاك الطاقة أقل من 0.5 ملي واط عندما يكون الجهاز ثابتًا و1.5 ملي واط عندما يكون الجهاز متحركًا.
[C-2-12] يجب أن يتضمّن جهاز
TILT_DETECTOR
أداة استشعار تستوفي الشروط التالية:- يجب أن يكون استهلاك الطاقة أقل من 0.5 ملي واط عندما يكون الجهاز ثابتًا و1.5 ملي واط عندما يكون الجهاز متحركًا.
[C-2-13] يجب أن يكون الطابع الزمني للحدث نفسه الذي يُبلغ عنه كل من قياس التسارع والجيروسكوب والمقياس المغناطيسي ضمن 2.5 ملي ثانية من بعضها. يجب أن يكون الطابع الزمني للحدث المادي نفسه الذي يُبلغ عنه كل من accelerometer وgyroscope ضمن 0.25 ملي ثانية من بعضهم.
[C-2-14] يجب أن تتضمّن الطوابع الزمنية لأحداث جهاز استشعار الدوران قاعدة زمنية مماثلة لقاعدة الوقت في النظام الفرعي للكاميرا ويجب ألا يتجاوز الخطأ ملي ثانية واحدة.
[C-2-15] يجب إرسال عيّنات إلى التطبيقات في غضون 5 مللي ثانية من الوقت الذي تتوفّر فيه البيانات على أي من أجهزة الاستشعار البدنية المذكورة أعلاه إلى التطبيق.
[C-2-16] يجب ألا يتجاوز استهلاك الطاقة 0.5 ملي واط عندما يكون الجهاز ثابتًا و2.0 ملي واط عندما يكون الجهاز متحركًا عند تفعيل أي مجموعة من أجهزة الاستشعار التالية:
SENSOR_TYPE_SIGNIFICANT_MOTION
SENSOR_TYPE_STEP_DETECTOR
SENSOR_TYPE_STEP_COUNTER
SENSOR_TILT_DETECTORS
[C-2-17] يجوز أن يتضمّن جهاز التحكّم في السرعة أداة استشعار
TYPE_PROXIMITY
، ولكن في حال توفّرها، يجب أن توفّر سعة تخزين مؤقت لا تقل عن 100 حدث استشعار.
يُرجى العلم أنّ جميع متطلبات استهلاك الطاقة الواردة في هذا القسم لا تشمل استهلاك الطاقة لمعالج التطبيقات. ويشمل ذلك الطاقة التي يتم سحبها من خلال سلسلة أجهزة الاستشعار بالكامل، أي جهاز الاستشعار وأي دوائر كهربائية داعمة وأي نظام مخصّص لمعالجة بيانات أجهزة الاستشعار وما إلى ذلك.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة استخدام أداة الاستشعار مباشرةً، يجب أن تستوفي ما يلي:
- [C-3-1] يجب أن يُعلن التطبيق بشكل صحيح عن توفّر أنواع القنوات المباشرة ومستوى تقارير معدلات التحويل المباشرة من خلال واجهتَي برمجة التطبيقات
isDirectChannelTypeSupported
وgetHighestDirectReportRateLevel
. - [C-3-2] يجب أن يكون متوافقًا مع نوع واحد على الأقل من نوعَي قناة الاستشعار المباشر لجميع أدوات الاستشعار التي تعلن عن توافقها مع قناة الاستشعار المباشر.
- يجب أن تتيح أداة الاستشعار إعداد تقارير الأحداث من خلال قناة الاستشعار المباشرة لأداة الاستشعار الأساسية (الصيغة غير المخصّصة للتنشيط) من الأنواع التالية:
TYPE_ACCELEROMETER
TYPE_ACCELEROMETER_UNCALIBRATED
TYPE_GYROSCOPE
TYPE_GYROSCOPE_UNCALIBRATED
TYPE_MAGNETIC_FIELD
TYPE_MAGNETIC_FIELD_UNCALIBRATED
7.3.10. أجهزة الاستشعار الحيوية
للحصول على معلومات إضافية عن قياس أمان ميزة "فتح الجهاز ببصمة الإصبع"، يُرجى الاطّلاع على مستندات قياس أمان المقاييس الحيوية.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن شاشة قفل آمنة، يجب استيفاء الشروط التالية:
- يجب أن يتضمّن جهاز استشعار حيويًا
يمكن تصنيف أدوات الاستشعار الحيوية على أنّها من الفئة 3 (المعروفة سابقًا باسم قوية)، الفئة 2 (المعروفة سابقًا باسم ضعيفة)، أو الفئة 1 (المعروفة سابقًا باسم سهلة الاستخدام) استنادًا إلى معدّلات قبول عمليات التزوير والتزييف، وإلى أمان مسار المعالجة المتعلّق بالمقاييس الحيوية. يحدِّد هذا التصنيف إمكانات المستشعر البيومتري للتفاعل مع المنصة وتطبيقات الجهات الخارجية. يتم تصنيف أجهزة الاستشعار على أنّها من الفئة 1 تلقائيًا، ويجب أن تستوفي متطلبات إضافية كما هو موضّح أدناه إذا أرادت أن يتم تصنيفها على أنّها من الفئة 2 أو الفئة 3. تحصل ميزات الفئة 2 والفئة 3 البيومترية على إمكانات إضافية كما هو موضّح أدناه.
إذا كانت عمليات تنفيذ الأجهزة تتيح أداة استشعار المقاييس الحيوية لتطبيقات تابعة لجهات خارجية من خلال android.hardware.biometrics.BiometricManager، android.hardware.biometrics.BiometricPrompt، وandroid.provider.Settings.ACTION_BIOMETRIC_ENROLL، يجب أن تستوفي التطبيقات المتطلبات التالية:
- [C-4-1] يجب أن تستوفي المتطلبات المتعلقة بالمقاييس الحيوية من الفئة 3 أو الفئة 2 كما هو محدّد في هذا المستند.
- [C-4-2] يجب التعرّف على كل اسم مَعلمة محدّد كثابت في فئة المصادقين وأي مجموعات منه والامتثال له. في المقابل، يجب عدم الامتثال أو التعرّف على الثوابت الصحيحة التي يتم تمريرها إلى الأسلوبين canAuthenticate(int) وsetAllowedAuthenticators(int) بخلاف تلك التي تم توثيقها كثوابت عامة في Authenticators وأي مجموعات منها.
- [C-4-3] يجب تنفيذ الإجراء ACTION_BIOMETRIC_ENROLL على الأجهزة التي تتضمّن مقاييس حيوية من الفئة 3 أو الفئة 2. يجب أن يقدّم هذا الإجراء نقاط دخول التسجيل فقط لتقنيات الفئة 3 أو الفئة 2 البيومترية.
إذا كانت عمليات تنفيذ الأجهزة تتيح استخدام المقاييس الحيوية غير التفاعلية، يجب أن تستوفي الشروط التالية:
- [C-5-1] يجب أن تتطلّب تلقائيًا خطوة تأكيد إضافية (مثل الضغط على زر).
- [C-SR-1] يُنصح بشدة بتوفير إعداد للسماح للمستخدمين بتجاوز الإعدادات المفضّلة للتطبيق وفرض خطوة تأكيد مصاحبة دائمًا.
- [C-SR-2] يُنصح بشدة بتأمين إجراء التأكيد بحيث لا يمكن لخداع نظام التشغيل أو نواة النظام. على سبيل المثال، يعني ذلك أنّ إجراء التأكيد المستنِد إلى زرّ مادي يتم توجيهه من خلال دبوس إدخال/إخراج (GPIO) للأغراض العامة المخصّص للإدخال فقط في عنصر آمن (SE) لا يمكن تشغيله بأي وسيلة أخرى غير الضغط على زرّ مادي.
- [C-5-2] يجب أيضًا تنفيذ عملية مصادقة ضمنية (بدون خطوة تأكيد) تتوافق مع setConfirmationRequired(boolean)، التي يمكن للتطبيقات ضبطها لاستخدامها في عمليات تسجيل الدخول.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن أدوات استشعار متعددة للمقاييس الحيوية، يجب أن تستوفي المتطلبات التالية:
- [C-SR-3] يُنصح بشدة بطلب تأكيد مقياس حيوي واحد فقط لكل عملية مصادقة (على سبيل المثال، إذا كانت أداتا استشعار بصمة الإصبع والوجه متوفرة على الجهاز، يجب إرسال onAuthenticationSucceeded بعد تأكيد أيٍّ منهما).
لكي تسمح عمليات تنفيذ الأجهزة بالوصول إلى مفاتيح ملف تخزين المفاتيح لتطبيقات تابعة لجهات خارجية، يجب أن تستوفي الشروط التالية:
- [C-6-1] يجب أن تستوفي المتطلبات الخاصة بالفئة 3 على النحو المحدّد في هذا القسم أدناه.
- [C-6-2] يجب تقديم المقاييس الحيوية من الفئة 3 فقط عندما تتطلّب المصادقة BIOMETRIC_STRONG، أو يتمّ استدعاء المصادقة باستخدام CryptoObject.
إذا أرادت عمليات تنفيذ الأجهزة التعامل مع أداة استشعار المقاييس الحيوية على أنّها من الفئة 1 (المعروفة سابقًا باسم الراحة)، يجب أن تستوفي المتطلبات التالية:
- [C-1-1] يجب أن يكون معدّل القبول الخاطئ أقل من 0.002%.
- [C-1-2] يجب الإفصاح عن أنّ هذا الوضع قد يكون أقل أمانًا من استخدام رقم تعريف شخصي أو نقش أو كلمة مرور قويَين، ويجب سرد مخاطر تفعيله بوضوح، إذا كانت معدلات قبول عمليات التزوير والتصيّد الاحتيالي أعلى من% 7 وفقًا لما يتم قياسه في بروتوكولات اختبار المقاييس الحيوية في Android.
- [C-1-9] يجب أن يطلب الجهاز من المستخدم إجراء المصادقة الأساسية المُقترَحة (مثل رقم التعريف الشخصي أو النمط أو كلمة المرور) بعد إجراء عشرين محاولة غير ناجحة كحد أقصى وبفاصل زمني لا يقل عن تسعين ثانية لإجراء عملية التحقّق من المقاييس الحيوية، حيث تكون المحاولة غير الناجحة هي محاولة ذات جودة تسجيل مناسبة (BIOMETRIC_ACQUIRED_GOOD) لا تتطابق مع المقاييس الحيوية المسجَّلة.
- [C-SR-4] يُنصح بشدة بخفض إجمالي عدد التجارب الخاطئة لإثبات الهوية بالاستناد إلى المقاييس الحيوية المحدّدة في [C-1-9] إذا كانت معدّلات قبول المحاكاة والتزوير أعلى من% 7 وفقًا لبروتوكولات اختبار المقاييس الحيوية في Android.
- [C-1-3] يجب تحديد عدد المحاولات المسموح به لإجراء عملية إثبات الهوية باستخدام المقاييس الحيوية، حيث تكون المحاولة
خاطئة إذا كانت جودة التسجيل مناسبة
(
BIOMETRIC_ACQUIRED_GOOD
) ولا تتطابق مع المقاييس الحيوية المسجَّلة. - [C-SR-5] يُنصح بشدة بتحديد عدد المحاولات في الدقيقة لمدة 30 ثانية على الأقل بعد خمس محاولات خاطئة للتحقّق من المقاييس الحيوية للوصول إلى الحد الأقصى لعدد المحاولات الخاطئة وفقًا لما هو موضّح في [C-1-9]، حيث تكون المحاولة الخاطئة هي التي تتسم بجودة تسجيل مناسبة (BIOMETRIC_ACQUIRED_GOOD) ولا تتطابق مع مقياس حيوي مسجَّل.
- [C-SR-6] يُنصح بشدة بتضمين كل منطق الحدّ من معدّل نقل البيانات في TEE.
- [C-1-10] يجب إيقاف المقاييس الحيوية بعد بدء المدة الزمنية الإضافية للمصادقة الأساسية للمرة الأولى على النحو الموضّح في [C-0-2] من القسم 9.11.
- [C-1-4] يجب منع إضافة مقاييس حيوية جديدة بدون إنشاء سلسلسة ثقة أولاً من خلال مطالبة المستخدم بتأكيد بيانات اعتماد الجهاز الحالية أو إضافة بيانات اعتماد جديدة (رقم التعريف الشخصي أو النمط أو كلمة المرور) التي تم تأمينها من خلال TEE، ويوفر تنفيذ مشروع Android Open sourced في إطار العمل آلية للقيام بذلك.
- [C-1-5] يجب إزالة جميع البيانات البيومترية القابلة للتحديد الخاصة بالمستخدم بالكامل عند إزالة حساب المستخدم (بما في ذلك من خلال إعادة الضبط على الإعدادات الأصلية).
- [C-1-6] يجب الالتزام بالعلامة الفردية للمقياس الحيوي (أي
DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT
أوDevicePolicymanager.KEYGUARD_DISABLE_FACE
أوDevicePolicymanager.KEYGUARD_DISABLE_IRIS
). - [C-1-7] يجب أن يطلب التطبيق من المستخدم المصادقة الأساسية المُقترَحة (مثل رقم التعريف الشخصي أو النقش أو كلمة المرور): (أ) مرة واحدة كل 24 ساعة أو أقل للأجهزة التي تعمل بالإصدار 9 من Android أو الإصدارات الأحدث، أو (ب) مرة واحدة كل 72 ساعة أو أقل للأجهزة التي يتم ترقيتها من الإصدار 8 من Android أو الإصدارات الأقدم.
[C-1-8] يجب أن يطلب الجهاز من المستخدم إثبات هويته باستخدام المصادقة الأساسية المُقترَحة (مثل رقم التعريف الشخصي أو النقش أو كلمة المرور) أو المقاييس الحيوية من الفئة 3 (قوية) بعد حدوث أحد الإجراءَين التاليَين:
- مهلة عدم النشاط لمدة 4 ساعات
3 محاولات مصادقة بالمقاييس الحيوية غير ناجحة
[C-SR-7] يُنصح بشدة باستخدام المنطق في إطار العمل الذي يوفّره مشروع Android Open Source لفرض القيود المحدّدة في [C-1-7] و[C-1-8] للأجهزة الجديدة.
[C-SR-8] يُنصح بشدة بأن يكون معدّل الرفض الخاطئ أقل من 10%، كما يتم قياسه على الجهاز.
[C-SR-9] يُنصح بشدة بخفض وقت الاستجابة إلى أقل من ثانية واحدة، ويتم قياسه من وقت رصد المقياس الحيوي إلى وقت فتح قفل الشاشة لكل مقياس حيوي مسجَّل.
إذا أرادت عمليات تنفيذ الأجهزة التعامل مع أداة استشعار المقاييس الحيوية على أنّها من الفئة 2 (المعروفة سابقًا باسم ضعيفة)، يجب أن تستوفي ما يلي:
- [C-2-1] يجب استيفاء جميع متطلبات الفئة 1 أعلاه.
- [C-2-2] يجب ألا يزيد معدّل قبول عمليات التزوير والتصيّد الاحتيالي عن %20، كما يتم قياسه من خلال بروتوكولات اختبار المقاييس الحيوية في Android.
- [C-2-3] يجب تنفيذ عملية المطابقة البيومترية في بيئة تنفيذ معزولة خارج مساحة مستخدم Android أو مساحة نظام التشغيل، مثل بيئة التنفيذ الموثوقة (TEE)، أو على شريحة تتضمّن قناة آمنة تؤدي إلى بيئة التنفيذ المعزولة.
- [C-2-4] يجب أن تكون جميع البيانات التعريفية مشفّرة ومصادق عليها cryptographically بحيث لا يمكن الحصول عليها أو قراءتها أو تغييرها خارج بيئة التنفيذ المعزولة أو شريحة تتضمّن قناة آمنة تؤدي إلى بيئة التنفيذ المعزولة كما هو موضّح في إرشادات التنفيذ على الموقع الإلكتروني لمشروع Android Open Source Project.
- [C-2-5] بالنسبة إلى المقاييس الحيوية المستندة إلى الكاميرا، أثناء المصادقة أو التسجيل المستندَين إلى المقاييس الحيوية:
- يجب تشغيل الكاميرا في وضع يمنع قراءة إطارات الكاميرا أو تغييرها خارج بيئة التنفيذ المعزولة أو شريحة تتضمّن قناة آمنة تؤدي إلى بيئة التنفيذ المعزولة.
- بالنسبة إلى حلول الكاميرا الواحدة ذات الإضاءة الملوّنة (RGB)، يمكن قراءة إطارات الكاميرا خارج بيئة التنفيذ المعزولة لدعم العمليات، مثل المعاينة للتسجيل، ولكن يجب ألّا تكون قابلة للتغيير.
- [C-2-6] يجب عدم السماح للتطبيقات التابعة لجهات خارجية بالتمييز بين عمليات التسجيل البيومتري الفردية.
- [C-2-7] يجب عدم السماح بالوصول غير المشفَّر إلى بيانات قياس البصمات الحيوية القابلة للتحديد أو أي بيانات مشتقة منها (مثل البيانات المضمَّنة) إلى معالج التطبيقات خارج سياق وحدة TEE. لا يتم استثناء الأجهزة التي تم ترقيتها وكانت تعمل بالإصدار 9 من Android أو الإصدارات الأقدم من القاعدة C-2-7.
[C-2-8] يجب أن يتضمّن مسار معالجة آمنًا بحيث لا تؤدي عملية اختراق لنظام التشغيل أو kernel إلى السماح بإدخال البيانات مباشرةً لإجراء مصادقة زائفة على أنّه المستخدم.
[C-SR-10] يُنصح بشدة بتضمين ميزة "التحقق من صحة التفاعل" لجميع الوضعيات المقاييس الحيوية وميزة "التعرّف على الانتباه" للمقاييس الحيوية للوجه.
[C-2-9] يجب إتاحة أداة الاستشعار الحيوية للتطبيقات التابعة لجهات خارجية.
إذا أرادت عمليات تنفيذ الأجهزة التعامل مع أداة استشعار المقاييس الحيوية على أنّها من الفئة 3 (المعروفة سابقًا باسم قوية)، يجب أن تستوفي المتطلبات التالية:
- يجب أن يستوفي [C-3-1] جميع متطلبات الفئة 2 أعلاه، باستثناء [C-1-7] و[C-1-8].
- [C-3-2] يجب أن يكون هناك تطبيق لمستودع مفاتيح مستند إلى الأجهزة.
- [C-3-3] يجب ألا يزيد معدّل قبول عمليات التزوير والتصيّد الاحتيالي عن %7، كما يتم قياسه من خلال بروتوكولات اختبار المقاييس الحيوية في Android.
- [C-3-4] يجب أن يطلب الجهاز من المستخدم إدخال مصادقة أساسية مقترَحة (مثل رقم التعريف الشخصي أو النقش أو كلمة المرور) مرة واحدة كل 72 ساعة أو أقل.
- [C-3-5] يجب إعادة إنشاء معرّف المصادقة لجميع ميزات المقاييس الحيوية من الفئة 3 المتوافقة على الجهاز في حال إعادة تسجيل أي منها.
- [C-3-6] يجب تفعيل مفاتيح ملف تخزين المفاتيح المستندة إلى المقاييس الحيوية لتطبيقات الجهات الخارجية.
إذا كانت عمليات تنفيذ الأجهزة تحتوي على أداة استشعار بصمة الإصبع تحت الشاشة (UDFPS)، يجب مراعاة ما يلي:
- [C-SR-11] يُنصح بشدة بمنع المنطقة القابلة للمس في UDFPS من التدخل في التنقّل باستخدام 3 أزرار (الذي قد يحتاجه بعض المستخدمين لأغراض تسهيل الاستخدام).
7.3.12. أداة استشعار الوضعية
عمليات التنفيذ على الأجهزة:
- قد تتيح استخدام أداة استشعار الوضع بـ 6 درجات من الحرية.
إذا كانت عمليات تنفيذ الأجهزة تتيح استخدام أداة استشعار الوضع بـ 6 درجات من الحرية، يجب استيفاء الشروط التالية:
- [C-1-1] يجب تنفيذ
TYPE_POSE_6DOF
جهاز الاستشعار والإبلاغ عنه. - [C-1-2] يجب أن تكون أكثر دقة من متجه الدوران وحده.
7.3.13. أداة استشعار زاوية المفصل
إذا كانت عمليات تنفيذ الأجهزة تتيح استخدام أداة استشعار زاوية المفصل، يجب أن تستوفي الشروط التالية:
- [C-1-1] يجب تنفيذ
TYPE_HINGLE_ANGLE
والإبلاغ عنه. - [C-1-2] يجب أن يتيح الجهاز قراءة قراءتَين على الأقل بين 0 و360 درجة (بما في ذلك 0 و360 درجة).
- [C-1-3] يجب عرض مستشعر
للتنشيط
getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE)
.
7.4. إمكانية الوصول إلى البيانات
7.4.1. الاتصالات الهاتفية
يشير مصطلح "الهاتف" كما تستخدمه واجهات برمجة تطبيقات Android وهذا المستند تحديدًا إلى الأجهزة ذات الصلة بإجراء المكالمات الصوتية وإرسال الرسائل القصيرة عبر شبكة GSM أو CDMA. على الرغم من أنّ هذه المكالمات الصوتية قد تكون أو لا تكون مُدارة عبر تبديل الحِزم، فإنّها لأغراض Android تُعتبر مستقلة عن أي اتصال بالبيانات قد يتم تنفيذه باستخدام الشبكة نفسها. بعبارة أخرى، تشير وظائف "الهاتف" وواجهات برمجة التطبيقات في Android تحديدًا إلى المكالمات الصوتية والرسائل القصيرة. على سبيل المثال، لا تُعدّ عمليات تنفيذ الأجهزة التي لا يمكنها إجراء مكالمات أو إرسال رسائل SMS أو تلقّيها من أجهزة اتصال هاتفي، بغض النظر عن ما إذا كانت تستخدم شبكة خلوية للاتصال بالبيانات.
- يجوز استخدام Android على الأجهزة التي لا تتضمّن أجهزة اتصال هاتفي. وهذا يعني أنّ نظام Android متوافق مع الأجهزة غير الهواتف.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن خدمات الهاتف الجوّال GSM أو CDMA، يجب استيفاء الشروط التالية:
- [C-1-1] يجب الإفصاح عن علامة ميزة
android.hardware.telephony
وغيرها من علامات الميزات الفرعية وفقًا للتكنولوجيا. - [C-1-2] يجب توفير دعم كامل لواجهة برمجة التطبيقات لهذه التكنولوجيا.
- يجب أن يسمح بالاتصال بجميع أنواع خدمات الجوّال المتاحة (الجيل الثاني والثالث والرابع والخامس وما إلى ذلك)
أثناء المكالمات في حالات الطوارئ (بغض النظر عن أنواع الشبكات التي تم ضبطها من قِبل
SetAllowedNetworkTypeBitmap()
).
إذا لم تتضمّن عمليات تنفيذ الأجهزة أجهزة اتصال هاتفي، يجب استيفاء الشروط التالية:
- [C-2-1] يجب تنفيذ واجهات برمجة التطبيقات الكاملة كعمليات لا تتطلّب تدخلًا.
إذا كانت عمليات تنفيذ الأجهزة متوافقة مع شرائح eUICC أو شرائح eSIM/شرائح SIM المضمّنة وتتضمن آلية خاصة بحقوق الملكية لتوفير وظائف شرائح eSIM لمطوّري التطبيقات التابعين لجهات خارجية، يجب أن:
- [C-3-1] يجب تقديم تنفيذ كامل
EuiccManager API
.
إذا لم تضبط عمليات تنفيذ الأجهزة سمة النظام ro.telephony.iwlan\_operation\_mode
على "قديم"، فإنّها:
- [C-4-1] يجب عدم الإبلاغ عن NETWORK_TYPE_IWLAN من خلال NetworkRegistrationInfo#getAccessNetworkTechnology() عندما يتم الإبلاغ عن NetworkRegistrationInfo#getTransportType() على أنّه TRANSPORT_TYPE_WWAN لنسخة NetworkRegistrationInfo نفسها.
إذا كانت عمليات تنفيذ الأجهزة تتيح تسجيلًا واحدًا لنظام IP Multimedia Subsystem (IMS) لكل من خدمة الهاتف الجوّال للوسائط المتعددة (MMTEL) وميزات خدمة الاتصالات التفاعلية (RCS) ومن المتوقّع أن تمتثل لمتطلبات مشغّل شبكة الجوّال في ما يتعلّق باستخدام تسجيل واحد لنظام IMS لجميع عمليات إرسال الإشارات في IMS، يجب أن تستوفي الأجهزة المتطلبات التالية:
- [C-5-1] يجب الإفصاح عن علامة ميزة
android.hardware.telephony.ims
وتوفير تنفيذ كامل لواجهة برمجة التطبيقات ImsService API لكل من MMTEL وUser Capability Exchange API لخدمات RCS. - [C-5-2] يجب الإفصاح عن
android.hardware.telephony.ims.singlereg
علامة الميزة وتوفير تنفيذ كامل SipTransport API، GbaService API، وإشارات حاملة البيانات المخصّصة باستخدام IRadio 1.6 HAL، وإعداد التطبيق من خلال خادم الإعداد التلقائي (ACS) أو آلية إعداد أخرى مملوكة باستخدام IMS Configuration API.
7.4.1.1. توافق حظر الأرقام
إذا أبلغت عمليات تنفيذ الأجهزة عن android.hardware.telephony feature
، يعني ذلك ما يلي:
- [C-1-1] يجب أن تتضمّن ميزة حظر الأرقام
- [C-1-2] يجب تنفيذ
BlockedNumberContract
وواجهة برمجة التطبيقات المقابلة لها بالكامل على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK). - [C-1-3] يجب حظر جميع المكالمات والرسائل الواردة من رقم هاتف في ملف "موفِّر الأرقام المحظورة" بدون أي تفاعل مع التطبيقات. ويتمثل الاستثناء الوحيد في رفع حظر الأرقام مؤقتًا كما هو موضّح في مستندات SDK.
- [C-1-4] يجب عدم الكتابة إلى مقدّم سجلّ المكالمات في النظام الأساسي لطلب مكالمة محظورة.
- [C-1-5] يجب عدم الكتابة إلى مقدّم خدمة الاتصال الهاتفي بشأن رسالة محظورة.
- [C-1-6] يجب تنفيذ واجهة مستخدم لإدارة الأرقام المحظورة، والتي يتم فتحها
باستخدام النية التي تعرضها طريقة
TelecomManager.createManageBlockedNumbersIntent()
. - [C-1-7] يجب عدم السماح للمستخدمين الثانويين بالاطّلاع على الأرقام المحظورة أو تعديلها على الجهاز لأنّ نظام Android يفترض أنّ المستخدم الأساسي لديه إمكانية التحكّم الكامل في خدمات الهاتف، وهي نسخة واحدة على الجهاز. يجب أن تكون كل واجهة مستخدم مرتبطة بحظر المحتوى مخفية للمستخدمين الثانويين، ويجب أن تظل القائمة المحظورة مفعّلة.
- من المفترض نقل الأرقام المحظورة إلى مقدّم الخدمة عند تحديث أحد الأجهزة إلى Android 7.0.
7.4.1.2. Telecom API
إذا أبلغت عمليات تنفيذ الأجهزة عن android.hardware.telephony
، يعني ذلك ما يلي:
- [C-1-1] يجب أن تتوافق مع واجهات برمجة تطبيقات
ConnectionService
الموضّحة في حزمة تطوير البرامج (SDK). - [C-1-2] يجب عرض مكالمة واردة جديدة وتوفير إمكانات للمستخدم لقبول المكالمة الواردة أو رفضها عندما يكون المستخدم في مكالمة جارية
يجريها تطبيق تابع لجهة خارجية لا يتيح ميزة الانتظار
المحدَّدة من خلال
CAPABILITY_SUPPORT_HOLD
. - [C-1-3] يجب أن يتضمّن التطبيق فئة برمجة التطبيقات InCallService.
[C-SR-1] يُنصح بشدة بإعلام المستخدم بأنّ الردّ على مكالمة واردة سيؤدي إلى إنهاء مكالمة حالية.
يستوفي تنفيذ AOSP هذه المتطلبات من خلال إشعار تنبيه يشير إلى المستخدم بأنّ الردّ على مكالمة واردة سيؤدي إلى إنهاء المكالمة الأخرى.
[C-SR-1] يُنصح بشدة بتثبيت تطبيق الاتصال التلقائي الذي يعرض إدخال سجلّ المكالمات واسم تطبيق تابع لجهة خارجية في سجلّ المكالمات، وذلك عندما يضبط التطبيق التابع لجهة خارجية مفتاح
EXTRA_LOG_SELF_MANAGED_CALLS
الإضافات علىPhoneAccount
إلىtrue
.[C-SR-2] يُنصح بشدة بمعالجة حدثَي
KEYCODE_MEDIA_PLAY_PAUSE
وKEYCODE_HEADSETHOOK
لسماعات الرأس الصوتية في واجهات برمجة التطبيقاتandroid.telecom
على النحو التالي:- اتصل بالرقم
Connection.onDisconnect()
عند رصد ضغطة قصيرة على الحدث الرئيسي أثناء مكالمة جارية. - اتصل بالرقم
Connection.onAnswer()
عند رصد ضغطة قصيرة على الحدث الرئيسي أثناء مكالمة واردة. - اتصل بالرقم
Connection.onReject()
عند رصد الضغط مع الاستمرار على الحدث الرئيسي أثناء مكالمة واردة. - فعِّل أو أوقِف ميزة كتم الصوت في
CallAudioState
.
- اتصل بالرقم
7.4.2. معيار IEEE 802.11 (لشبكات Wi-Fi)
عمليات التنفيذ على الأجهزة:
- يجب أن تتضمّن إتاحة استخدام شكل واحد أو أكثر من 802.11.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة 802.11 وتعرض الوظيفة لتطبيق تابع لجهة خارجية، يجب استيفاء الشروط التالية:
- [C-1-1] يجب تنفيذ واجهة برمجة تطبيقات Android المقابلة.
- [C-1-2] يجب الإبلاغ عن علامة ميزة الجهاز
android.hardware.wifi
. - [C-1-3] يجب تنفيذ واجهة برمجة التطبيقات لبث الوسائط المتعدّدة على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK).
- [C-1-4] يجب أن يكون متوافقًا مع نظام أسماء النطاقات ذي البث المتعدد (mDNS) ويجب عدم فلترة حزم mDNS
(224.0.0.251) في أي وقت من التشغيل، بما في ذلك:
- حتى عندما تكون الشاشة غير نشطة
- لعمليات تنفيذ أجهزة Android Television، حتى في حالات وضع الاستعداد حالات الطاقة
- [C-1-5] يجب عدم التعامل مع طلب بيانات من واجهة برمجة التطبيقات
WifiManager.enableNetwork()
كإشارة كافية لتبديلNetwork
النشط حاليًا والذي يتم استخدامه تلقائيًا للزيارات الواردة إلى التطبيق ويتم إرجاعه بواسطة طرق واجهة برمجة التطبيقاتConnectivityManager
مثلgetActiveNetwork
وregisterDefaultNetworkCallback
. بعبارة أخرى، يجوز لهم إيقاف إمكانية الوصول إلى الإنترنت المقدَّمة من أي مزوّد شبكة آخر (مثل بيانات الجوّال) فقط إذا تم التحقّق بنجاح من أنّ شبكة Wi-Fi توفّر إمكانية الوصول إلى الإنترنت. - [C-1-6] يُنصح بشدة بإعادة تقييم إمكانية الوصول إلى الإنترنت على
Network
عند استدعاءConnectivityManager.reportNetworkConnectivity()
طريقة واجهة برمجة التطبيقات، وبالتبديل إلى أي شبكة أخرى متاحة (مثل بيانات الشبكة اللاسلكية للأجهزة الجوّالة) تتيح الوصول إلى الإنترنت بعد أن يحدِّد التقييم أنّNetwork
الحالية لم تعُد تتيح الوصول إلى الإنترنت. - [C-1-7] يجب إنشاء عنوان MAC المصدر ورقم التسلسل لإطارات طلب الفحص بشكل عشوائي، مرة واحدة في بداية كل عملية بحث، عندما يكون STA غير متصل.
- [C-1-8] يجب استخدام عنوان MAC واحد ثابت (يجب عدم إنشاء عنوان MAC عشوائي في منتصف عملية البحث).
- [C-1-9] يجب تكرار رقم تسلسل طلب الفحص كالمعتاد (بشكل تسلسلي) بين طلبات الفحص في عملية الفحص.
- [C-1-10] يجب أن يكون رقم تسلسل طلب الفحص عشوائيًا بين طلب الفحص المُرسَل الأخير لعملية مسح وأول طلب فحص لمُهمّة المسح التالية.
- [C-SR-1] يُنصح بشدة بتعيين عنوان MAC المصدر بشكل عشوائي ليستخدمه
كل جهاز STA للتواصل مع نقطة وصول (AP) أثناء الربط
والربط.
- يجب أن يستخدم الجهاز عنوان MAC عشوائيًا مختلفًا لكل SSID (FQDN لبروتوكول Passpoint) يتواصل معه.
- يجب أن يقدّم الجهاز للمستخدم خيارًا للتحكّم في عملية التبديل العمياء لكل معرّف SSID (FQDN لبروتوكول Passpoint) من خلال خيارات غير عشوائية وأخرى عشوائية، ويجب ضبط الوضع التلقائي لعمليات ضبط Wi-Fi الجديدة على أن تكون عشوائية.
- [C-SR-2] ننصح بشدة باستخدام معرّف BSSID عشوائي لأي نقطة اتصال يتم
إنشاؤها.
- يجب أن يكون عنوان MAC عشوائيًا ومستمرًا لكل SSID يستخدمه العميل.
- يجوز للجهاز أن يقدّم للمستخدم خيارًا لإيقاف هذه الميزة. في حال توفّر هذا الخيار، يجب تفعيل وضع "العرض العشوائي" تلقائيًا.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة وضع توفير الطاقة في Wi-Fi كما هو محدّد في معيار IEEE 802.11، يجب أن تستوفي ما يلي:
- يجب إيقاف وضع "توفير الطاقة في Wi-Fi" عندما يحصل تطبيق على
قفل
WIFI_MODE_FULL_HIGH_PERF
أو قفلWIFI_MODE_FULL_LOW_LATENCY
من خلال واجهات برمجة التطبيقاتWifiManager.createWifiLock()
وWifiManager.WifiLock.acquire()
ويكون القفل مفعّلاً. - [C-3-2] يجب أن يكون متوسّط وقت الاستجابة لرحلة الذهاب والعودة بين الجهاز
ونقطة وصول أثناء تشغيل وضع "قفل وقت الاستجابة المنخفض لشبكة Wi-Fi"
(
WIFI_MODE_FULL_LOW_LATENCY
) أقصر من وقت الاستجابة أثناء تشغيل وضع "قفل الأداء العالي لشبكة Wi-Fi" (WIFI_MODE_FULL_HIGH_PERF
). - [C-SR-3] يُنصح بشدة بتقليل وقت استجابة جولة Wi-Fi بالكامل
عند الحصول على قفل وقت الاستجابة المنخفض (
WIFI_MODE_FULL_LOW_LATENCY
) وبدء تطبيقه.
إذا كانت عمليات تنفيذ الأجهزة تتيح استخدام شبكة Wi-Fi وتستخدمها للبحث عن الموقع الجغرافي، يجب أن تستوفي ما يلي:
- [C-2-1] يجب توفير عنصر تحكم للمستخدم لتفعيل/إيقاف قراءة القيمة
من خلال طريقة واجهة برمجة التطبيقات
WifiManager.isScanAlwaysAvailable
.
7.4.2.1. اتصال Wi-Fi مباشر
عمليات التنفيذ على الأجهزة:
- يجب أن تتضمّن تقنية Wi-Fi Direct (الاتصال المباشر عبر Wi-Fi).
إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة تقنية Wi-Fi Direct، يجب أن تستوفي الشروط التالية:
- [C-1-1] يجب تنفيذ واجهة برمجة تطبيقات Android المقابلة كما هو موضّح في مستندات حزمة تطوير البرامج (SDK).
- [C-1-2] يجب الإبلاغ عن ميزة الجهاز
android.hardware.wifi.direct
. - [C-1-3] يجب أن يكون الجهاز متوافقًا مع شبكة Wi-Fi العادية.
- [C-1-4] يجب أن يكون الجهاز متوافقًا مع شبكة Wi-Fi وعمليات Wi-Fi Direct في الوقت نفسه.
- [C-SR-1] يُنصح بشدة باختيار عنوان MAC المصدر بشكل عشوائي لجميع عمليات الربط التي تم إنشاؤها حديثًا باستخدام Wi-Fi Direct.
7.4.2.2. إعداد رابط مباشر عبر نفق Wi-Fi
عمليات التنفيذ على الأجهزة:
- يجب أن تتضمّن ميزة إعداد رابط مباشر عبر نفق Wi-Fi (TDLS) كما هو موضّح في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة بروتوكول TDLS وتم تفعيله من خلال واجهة برمجة التطبيقات WiFiManager API، يتم تنفيذ ما يلي:
- [C-1-1] يجب الإفصاح عن توفّر بروتوكول TDLS من خلال
WifiManager.isTdlsSupported
. - يجب استخدام بروتوكول TDLS فقط عندما يكون ذلك ممكنًا ومفيدًا.
- يجب أن يتضمّن بعض الأساليب الاستقرائية وألا يستخدم بروتوكول TDLS عندما يكون أداؤه أسوأ من استخدام نقطة وصول Wi-Fi.
7.4.2.3. Wi-Fi Aware
عمليات التنفيذ على الأجهزة:
- يجب أن تتضمّن ميزة Wi-Fi Aware.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة استخدام ميزة Wi-Fi Aware وعرض الوظائف للتطبيقات التابعة لجهات خارجية، يجب أن تستوفي المتطلبات التالية:
- [C-1-1] يجب تنفيذ واجهات برمجة تطبيقات
WifiAwareManager
على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK). - [C-1-2] يجب الإفصاح عن علامة ميزة
android.hardware.wifi.aware
. - [C-1-3] يجب أن يكون متوافقًا مع عمليات Wi-Fi وWi-Fi Aware في الوقت نفسه.
- [C-1-4] يجب إنشاء عنوان واجهة إدارة Wi-Fi Aware بشكل عشوائي على فترات زمنية لا تزيد عن 30 دقيقة وكلما تم تفعيل Wi-Fi Aware ما لم تكن عملية الاستكشاف قيد التنفيذ أو كان مسار بيانات Aware نشطًا (لا يُتوقّع استخدام الترتيب العشوائي طيلة فترة نشاط مسار البيانات).
إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة ميزتَي "الاستشعار عبر Wi-Fi" و "تحديد الموقع الجغرافي عبر Wi-Fi" كما هو موضّح في الفقرة 7.4.2.5 وكانت تتيح هذه الوظائف للتطبيقات التابعة لجهات خارجية، يجب أن تستوفي المتطلبات التالية:
- [C-2-1] يجب تنفيذ واجهات برمجة تطبيقات الاستكشاف المستندة إلى الموقع الجغرافي: setRangingEnabled، setMinDistanceMm، setMaxDistanceMm ، و onServiceDiscoveredWithinRange.
7.4.2.4. Wi-Fi Passpoint
إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة استخدام معيار 802.11 (Wi-Fi)، يجب أن تستوفي المتطلبات التالية:
- [C-1-1] يجب أن تتضمّن Wi-Fi Passpoint.
- [C-1-2] يجب تنفيذ واجهات برمجة التطبيقات
WifiManager
ذات الصلة ببرنامج Passpoint كما هو описан في مستندات حزمة تطوير البرامج (SDK). - [C-1-3] يجب أن يكون متوافقًا مع معيار IEEE 802.11u، خاصةً في ما يتعلّق باكتشاف الشبكة واختيارها، مثل "خدمة الإعلانات الشاملة" (GAS) و"بروتوكول طلب الوصول إلى الشبكة" (ANQP).
- [C-1-4] يجب الإفصاح عن علامة ميزة
android.hardware.wifi.passpoint
. - [C-1-5] يجب اتّباع عملية التنفيذ في AOSP للتعرّف على شبكات Passpoint ومطابقتها وربطها بها.
- [C-1-6] يجب أن تتوافق مع المجموعة الفرعية التالية على الأقل من بروتوكولات إعداد الأجهزة كما هو محدّد في Wi-Fi Alliance Passpoint R2: مصادقة EAP-TTLS وSOAP-XML.
- [C-1-7] يجب معالجة شهادة خادم إدارة الهوية وإمكانية الوصول (AAA) كما هو موضّح في مواصفات Hotspot 2.0 R3.
- [C-1-8] يجب أن يتيح للمستخدم التحكّم في عملية الإعداد من خلال أداة اختيار Wi-Fi.
- [C-1-9] يجب أن تظل إعدادات Passpoint ثابتة عند إعادة التشغيل.
- [C-SR-1] يُنصح بشدة بتفعيل ميزة قبول الأحكام والشروط.
- [C-SR-2] يُنصح بشدة بتوفير ميزة "معلومات عن المكان".
في المقابل، إذا كانت عمليات تنفيذ الأجهزة لا تتضمّن إتاحة Wi-Fi Passpoint:
- [C-2-1] يجب أن يؤدي تنفيذ
WifiManager
واجهات برمجة التطبيقات ذات الصلة بنقطة المرور إلى طرحUnsupportedOperationException
.
في حال توفُّر مفتاح تحكّم عام في إيقاف Passpoint، يتم تنفيذ ما يلي:
- [C-3-1] يجب تفعيل Passpoint تلقائيًا.
7.4.2.5. الموقع الجغرافي لشبكة Wi-Fi (مدّة الرحلة ذهابًا وإيابًا لشبكة Wi-Fi)
عمليات التنفيذ على الأجهزة:
- يجب أن تتضمّن ميزة تحديد الموقع الجغرافي من خلال شبكة Wi-Fi.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة ميزة "تحديد الموقع الجغرافي من خلال Wi-Fi" وتعرض الوظيفة للتطبيقات التابعة لجهات خارجية، يجب أن تستوفي الشروط التالية:
- [C-1-1] يجب تنفيذ واجهات برمجة تطبيقات
WifiRttManager
على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK). - [C-1-2] يجب الإفصاح عن علامة ميزة
android.hardware.wifi.rtt
. - [C-1-3] يجب اختيار عنوان MAC المصدر بشكل عشوائي لكل رشقة RTT التي يتم تنفيذها عندما لا تكون واجهة Wi-Fi التي يتم تنفيذ RTT عليها مرتبطة بنقطة وصول.
- [C-1-4] يجب أن تكون الدقة ضمن مترَين عند عرض النطاق البالغ 80 ميغاهرتز في المعدل المئوي 68 (كما يتم احتسابه باستخدام دالة التوزيع المتراكم).
7.4.2.6. نقل بيانات ميزة "إبقاء الاتصال بالإنترنت" في Wi-Fi
عمليات التنفيذ على الأجهزة:
- يجب أن تتضمّن إتاحة ميزة "إبقاء الاتصال بالإنترنت" في شبكة Wi-Fi.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة ميزة "إبقاء الاتصال بالإنترنت" في Wi-Fi و إتاحة الوظيفة للتطبيقات التابعة لجهات خارجية، يجب استيفاء الشروط التالية:
[C-1-1] يجب أن تتوافق مع واجهة برمجة التطبيقات SocketKeepAlive.
[C-1-2] يجب أن يتيح الجهاز ثلاث خانات متوافقة على الأقل للحفاظ على الاتّصال عبر شبكة Wi-Fi و خانة واحدة على الأقل للحفاظ على الاتّصال عبر شبكة الجوّال.
إذا لم تتضمّن عمليات تنفيذ الأجهزة ميزة تفريغ عمليات الاحتفاظ بحالة الاتصال بشبكة Wi-Fi، يحدث ما يلي:
- [C-2-1] يجب أن يعرض العنصر
ERROR_UNSUPPORTED
.
7.4.2.7. Wi-Fi Easy Connect (بروتوكول توفير الأجهزة)
عمليات التنفيذ على الأجهزة:
- يجب أن تتضمّن ميزة Wi-Fi Easy Connect (DPP).
إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة ميزة "الاتصال السهل بشبكة Wi-Fi" وتوفير هذه الميزة للتطبيقات التابعة لجهات خارجية، يجب استيفاء الشروط التالية:
- [C-1-1] يجب أن تُعرِض الطريقة WifiManager#isEasyConnectSupported()
true
.
7.4.2.8. التحقّق من شهادة خادم شبكة Wi-Fi في المؤسسة
في حال عدم التحقّق من شهادة خادم Wi-Fi أو عدم ضبط اسم نطاق خادم Wi-Fi، تُنفّذ عمليات تثبيت الجهاز ما يلي:
- [C-SR-1] يُنصح بشدة بعدم منح المستخدم خيارًا لإضافة شبكة Wi-Fi للمؤسسات يدويًا في تطبيق "الإعدادات".
7.4.3. البلوتوث
إذا كانت عمليات تنفيذ الأجهزة متوافقة مع الملف الشخصي للصوت عبر البلوتوث، يجب أن تستوفي الشروط التالية:
- يجب أن تكون متوافقة مع برامج ترميز الصوت المتقدّمة وبرامج ترميز صوت البلوتوث (مثل LDAC).
إذا كانت عمليات تنفيذ الأجهزة متوافقة مع HFP وA2DP وAVRCP، يجب أن تستوفي الشروط التالية:
- يجب أن يكون متوافقًا مع 5 أجهزة متصلة على الأقل.
إذا كانت عمليات تنفيذ الأجهزة تذكر ميزة android.hardware.vr.high_performance
، يجب أن تستوفي الشروط التالية:
- [C-1-1] يجب أن يكون الجهاز متوافقًا مع معيارَي Bluetooth 4.2 وBluetooth LE Data Length Extension.
يتيح نظام Android استخدام البلوتوث والبلوتوث المنخفض الطاقة.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة تقنية البلوتوث وتقنية البلوتوث المنخفضة الطاقة، يجب أن تستوفي المتطلبات التالية:
- [C-2-1] يجب الإفصاح عن ميزات المنصة ذات الصلة
(
android.hardware.bluetooth
وandroid.hardware.bluetooth_le
على التوالي) وتنفيذ واجهات برمجة تطبيقات المنصة. - يجب تنفيذ الملفات الشخصية ذات الصلة بالبلوتوث، مثل A2DP وAVRCP وOBEX وHFP وما إلى ذلك، حسبما يناسب الجهاز.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة تقنية البلوتوث المنخفض الطاقة (BLE)، يجب استيفاء الشروط التالية:
- [C-3-1] يجب الإفصاح عن ميزة الجهاز
android.hardware.bluetooth_le
. - [C-3-2] يجب تفعيل واجهات برمجة التطبيقات (API) لتقنية Bluetooth المستندة إلى GATT (ملف الخصائص العام) على النحو الموضّح في مستندات حزمة تطوير البرامج (SDK) وandroid.bluetooth.
- [C-3-3] يجب الإبلاغ عن القيمة الصحيحة لسمة
BluetoothAdapter.isOffloadedFilteringSupported()
للإشارة إلى ما إذا تم تنفيذ منطق filtering لصفوف واجهة برمجة التطبيقات ScanFilter. - [C-3-4] يجب الإبلاغ عن القيمة الصحيحة لسمة
BluetoothAdapter.isMultipleAdvertisementSupported()
للإشارة إلى ما إذا كان الإعلان المنخفض الطاقة متوافقًا. - [C-3-5] يجب تنفيذ مهلة لعنوان RPA لا تزيد عن 15 دقيقة وتبديل العنوان عند انتهاء المهلة لحماية خصوصية المستخدم عندما يستخدم الجهاز تقنية BLE بشكل نشط للبحث أو الإعلان. لمنع هجمات التوقيت، يجب أيضًا اختيار الفواصل الزمنية للمهلة بشكل عشوائي بين 5 و15 دقيقة.
- يجب أن تتيح واجهة برمجة التطبيقات نقل منطق الفلترة إلى شريحة البلوتوث عند تنفيذ واجهة ScanFilter API.
- يجب أن تتيح ميزة "البحث المجمّع" نقل البيانات إلى مجموعة شرائح البلوتوث.
- يجب أن تتيح عرض إعلانات متعددة مع 4 خانات على الأقل.
إذا كانت عمليات تنفيذ الأجهزة متوافقة مع تقنية Bluetooth LE وتستخدمها لأجل البحث عن الموقع الجغرافي، يجب أن تستوفي المتطلبات التالية:
- [C-4-1] يجب توفير عنصر تحكم للمستخدم لتفعيل/إيقاف القيمة التي يتم قراءتها
من خلال System API
BluetoothAdapter.isBleScanAlwaysAvailable()
.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة استخدام ملف Bluetooth LE وملف سماعات الأذن الطبية، كما هو موضّح في إتاحة استخدام ملف سماعات الأذن الطبية باستخدام Bluetooth LE، يجب استيفاء الشروط التالية:
- [C-5-1] يجب عرض القيمة
true
لصيغة BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID).
إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة تقنية البلوتوث أو تقنية "البلوتوث المنخفض الطاقة"، يجب أن:
- [C-6-1] يجب حظر الوصول إلى أي بيانات وصفية عن البلوتوث (مثل نتائج البحث) التي يمكن استخدامها لتحديد الموقع الجغرافي للجهاز، ما لم يجتاز التطبيق الذي يطلب إذن الوصول إلى البلوتوث
android.permission.ACCESS_FINE_LOCATION
فحصًا للوصول استنادًا إلى حالته الحالية في المقدّمة أو الخلفية.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة استخدام البلوتوث أو البلوتوث المنخفض الطاقة ولا يتضمّن بيان التطبيق بيانًا من المطوّر يوضّح فيه أنّه لا يستخرج بيانات الموقع الجغرافي من البلوتوث، يعني ذلك أنّه:
- [C-6-2] يجب حظر الوصول إلى البلوتوث من خلال
android.permission.ACCESS_FINE_LOCATION
.
7.4.4. تقنية الاتصال القصير المدى
عمليات التنفيذ على الأجهزة:
- يجب أن يتضمّن جهاز إرسال واستقبال والأجهزة ذات الصلة للاتصال القصير المدى (NFC).
- [C-0-1] يجب تنفيذ واجهات برمجة التطبيقات
android.nfc.NdefMessage
وandroid.nfc.NdefRecord
حتى إذا لم تتضمّن إتاحة استخدام NFC أو إعلان ميزةandroid.hardware.nfc
لأنّ الفئات تمثّل تنسيقًا لتمثيل البيانات لا يعتمد على البروتوكول.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن أجهزة NFC وتخطط لإتاحتها للتطبيقات التابعة لجهات خارجية، يجب أن:
- [C-1-1] يجب الإبلاغ عن الميزة
android.hardware.nfc
من خلال طريقةandroid.content.pm.PackageManager.hasSystemFeature()
. - يجب أن يكون الجهاز قادرًا على قراءة رسائل NDEF وكتابتها من خلال معايير NFC التالية كما هو موضّح أدناه:
- [C-1-2] يجب أن يكون الجهاز قادرًا على العمل كقارئ/كاتب في NFC Forum
(على النحو المحدّد في المواصفة الفنية لـ NFC Forum
NFCForum-TS-DigitalProtocol-1.0) من خلال معايير NFC التالية:
- NfcA (ISO14443-3A)
- NfcB (ISO14443-3B)
- NfcF (JIS X 6319-4)
- IsoDep (ISO 14443-4)
- أنواع علامات NFC التي حدّدها المنتدى 1 و2 و3 و4 و5
[C-SR-1] يُنصح بشدة بأن يكون الجهاز قادرًا على قراءة رسائل NDEF وكتابتها بالإضافة إلى البيانات الأولية من خلال معايير NFC التالية. يُرجى العلم أنّه على الرغم من أنّ معايير NFC مُدرجة على أنّها "مُستحسَنة بشدة"، من المخطّط أن يتم تغيير هذه المعايير في ملف تعريف التوافق لإصدار مستقبلي ليصبح "يجب". هذه المعايير اختيارية في هذا الإصدار، ولكنها ستكون مطلوبة في الإصدارات المستقبلية. ننصح بشدة بتلبية هذه المتطلبات الآن على الأجهزة الحالية والجديدة التي تعمل بهذا الإصدار من Android حتى تتمكّن من الترقية إلى إصدارات المنصة المستقبلية.
[C-1-13] يجب إجراء استطلاع لجميع التكنولوجيات المتوافقة أثناء استخدام وضع اكتشاف NFC.
يجب أن يكون الجهاز في وضع اكتشاف NFC عندما يكون مفعَّلاً وبشاشة نشطة وشاشة القفل مفتوحة.
يجب أن يكون قادرًا على قراءة الرمز الشريطي وعنوان URL (إذا كان مُرمّزًا) لمنتجات الرمز الشريطي NFC المُدمَج في فيلم رقيق.
يُرجى العلم أنّ الروابط المتاحة للجميع غير متاحة لمواصفات JIS وISO وNFC Forum المذكورة أعلاه.
يتيح نظام Android وضع "محاكاة البطاقة المضيفة" (HCE) عبر NFC.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن مجموعة شرائح تحكّم في NFC قادرة على استخدام تقنية HCE (لنوعَي برمجة التطبيقات NfcA و/أو NfcB) وتتوافق مع توجيه معرّف التطبيق (AID)، يجب استيفاء الشروط التالية:
- [C-2-1] يجب الإبلاغ عن ثابت الميزة
android.hardware.nfc.hce
. - [C-2-2] يجب أن تكون متوافقة مع واجهات برمجة تطبيقات NFC HCE كما هو описан في حزمة SDK لنظام التشغيل Android.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن شريحة تحكم NFC قادرة على استخدام تقنية HCE لبروتوكول NfcF، وتنفيذ الميزة للتطبيقات التابعة لجهات خارجية، يجب استيفاء الشروط التالية:
- [C-3-1] يجب الإبلاغ عن ثابت الميزة
android.hardware.nfc.hcef
. - [C-3-2] يجب تنفيذ واجهات برمجة تطبيقات محاكاة بطاقات NfcF على النحو المحدّد في حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة NFC بشكل عام كما هو موضّح في هذا القسم وتتيح تقنيات MIFARE (MIFARE Classic وMIFARE Ultralight وNDEF على MIFARE Classic) في دور القارئ/الكاتب، يجب أن تستوفي المتطلبات التالية:
- [C-4-1] يجب تنفيذ واجهات برمجة تطبيقات Android المقابلة كما هو موضّح في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
- [C-4-2] يجب الإبلاغ عن الميزة
com.nxp.mifare
من الوسيطةandroid.content.pm.PackageManager.hasSystemFeature
(). يُرجى العِلم أنّ هذه ليست ميزة عادية في Android، وبالتالي لا تظهر كقيمة ثابتة في فئةandroid.content.pm.PackageManager
.
7.4.5. بروتوكولات الشبكات وواجهات برمجة التطبيقات
7.4.5.1. الحد الأدنى من إمكانات الشبكة
عمليات التنفيذ على الأجهزة:
- [C-0-1] يجب أن يتضمّن الجهاز إمكانية استخدام شكل واحد أو أكثر من شبكات البيانات. وعلى وجه التحديد، يجب أن تتضمّن عمليات تنفيذ الأجهزة إمكانية استخدام معيار بيانات واحد على الأقل يمكنه نقل البيانات بسرعة 200 كيلوبت في الثانية أو أكثر. تشمل الأمثلة على التكنولوجيات التي تستوفي هذا الشرط EDGE وHSPA وEV-DO و 802.11g وEthernet وBluetooth PAN.
- يجب أن يتضمّن أيضًا معيارًا واحدًا على الأقل لتكنولوجيات نقل البيانات اللاسلكية الشائعة، مثل 802.11 (Wi-Fi)، عندما يكون معيار الشبكة المادية (مثل تكنولوجيات نقل البيانات اللاسلكية) هو اتصال البيانات الأساسي.
- يجوز تنفيذ أكثر من شكل واحد للربط بالبيانات.
7.4.5.2. بروتوكول IPv6
عمليات التنفيذ على الأجهزة:
- [C-0-2] يجب أن تتضمّن حِزمة شبكة IPv6 وأن تتيح مشاركة IPv6
باستخدام واجهات برمجة التطبيقات المُدارة، مثل
java.net.Socket
وjava.net.URLConnection
، بالإضافة إلى واجهات برمجة التطبيقات الأصلية، مثلAF_INET6
مقابس التوصيل. - [C-0-3] يجب تفعيل بروتوكول IPv6 تلقائيًا.
- يجب التأكّد من أنّ اتصالات IPv6 موثوقة مثل اتصالات IPv4، على سبيل المثال:
- [C-0-4] يجب الحفاظ على إمكانية الاتصال بشبكة IPv6 في وضع السكون.
- [C-0-5] يجب ألّا يؤدي الحدّ من معدّل الإرسال إلى فقدان الجهاز لإمكانية الاتصال عبر IPv6 على أي شبكة متوافقة مع IPv6 تستخدم مدد صلاحية RA تبلغ 180 ثانية على الأقل.
- يجب التأكّد من أنّ اتصالات IPv6 موثوقة مثل اتصالات IPv4، على سبيل المثال:
- [C-0-6] يجب أن توفّر التطبيقات التابعة لجهات خارجية إمكانية اتصال IPv6 المباشر
بالشبكة عند الاتصال بشبكة IPv6، بدون أي شكل من أشكال ترجمة العناوين أو
المنافذ التي تحدث محليًا على الجهاز. يجب أن تعرض كلّ من واجهات برمجة التطبيقات المُدارة، مثل
Socket#getLocalAddress
أوSocket#getLocalPort
) وواجهات برمجة التطبيقات في NDK، مثلgetsockname()
أوIPV6_PKTINFO
، عنوان IP والمنفذ المستخدَمين فعليًا لإرسال الحِزم واستلامها على الشبكة، وأن يظهرا كعنوان IP المصدر والمنفذ لخوادم الإنترنت (الويب).
يعتمد المستوى المطلوب من توافق IPv6 على نوع الشبكة، كما هو موضّح في المتطلبات التالية.
إذا كانت عمليات تنفيذ الأجهزة متوافقة مع Wi-Fi، يجب أن تستوفي الشروط التالية:
- [C-1-1] يجب أن يكون الجهاز متوافقًا مع الحزمة المزدوجة واستخدام بروتوكول IPv6 فقط على شبكة Wi-Fi.
إذا كانت عمليات تنفيذ الأجهزة متوافقة مع إيثرنت، يجب أن تستوفي الشروط التالية:
- [C-2-1] يجب أن يكون الجهاز متوافقًا مع الحزمة المزدوجة واستخدام IPv6 فقط على فاقمة Ethernet.
إذا كانت عمليات تنفيذ الأجهزة تتيح استخدام بيانات الجوّال، يتم تنفيذ ما يلي:
- [C-3-1] يجب أن يكون الجهاز متوافقًا مع بروتوكول IPv6 (IPv6 فقط وربما الإصدار المزدوج) على شبكة الجيل الثالث أو الجيل الرابع.
إذا كانت عمليات تنفيذ الأجهزة متوافقة مع أكثر من نوع شبكة واحد (مثل شبكة Wi-Fi وبيانات شبكة الجوّال)، اتّبِع الخطوات التالية:
- [C-4-1] يجب استيفاء المتطلبات المذكورة أعلاه في كل شبكة في الوقت نفسه عندما يكون الجهاز متصلاً في الوقت نفسه بأكثر من نوع شبكة واحد.
7.4.5.3. المداخل المشروط الوصول إليها
يشير مدخل الشبكة المشروط الوصول إليها إلى شبكة تتطلب تسجيل الدخول من أجل الوصول إلى الإنترنت.
إذا كانت عمليات تنفيذ الأجهزة توفّر تنفيذًا كاملاً لملف android.webkit.Webview API
،
تلتزم بما يلي:
- [C-1-1] يجب توفير تطبيق بوابة إلكترونية لمعالجة الطلب
ACTION_CAPTIVE_PORTAL_SIGN_IN
وعرض صفحة تسجيل الدخول إلى البوابة الإلكترونية، وذلك من خلال إرسال هذا الطلب عند الاتصال بواجهة برمجة تطبيقات النظامConnectivityManager#startCaptivePortalApp(Network, Bundle)
. - [C-1-2] يجب أن يتم رصد بوابات الربط ويجب أن يتيح التطبيق تسجيل الدخول من خلال بوابة الربط عندما يكون الجهاز متصلاً بأي نوع من الشبكات، بما في ذلك شبكة الجوّال/الشبكة الخلوية أو شبكة Wi-Fi أو إيثرنت أو البلوتوث.
- [C-1-3] يجب أن يتيح الجهاز تسجيل الدخول إلى البوابات المُدارة باستخدام نظام أسماء النطاقات النصي الواضح عندما يكون الجهاز مُعدًّا لاستخدام الوضع الصارم لنظام أسماء النطاقات الخاص.
- [C-1-4] يجب استخدام نظام أسماء النطاقات المشفَّر وفقًا لمستندات حزمة تطوير البرامج (SDK) لتطبيق
android.net.LinkProperties.getPrivateDnsServerName
وandroid.net.LinkProperties.isPrivateDnsActive
لجميع حركة بيانات الشبكة التي لا تتواصل صراحةً معبوابة الربط. - [C-1-5] يجب التأكّد من أنّ الشبكة التلقائية التي تستخدمها التطبيقات (كما تظهر في
ConnectivityManager.getActiveNetwork
وConnectivityManager.registerDefaultNetworkCallback
، والتي تستخدمها واجهات برمجة تطبيقات Java للشبكات تلقائيًا، مثل java.net.Socket، وواجهات برمجة التطبيقات الأصلية، مثل connect()) هي أي شبكة متاحة أخرى توفّر إمكانية الوصول إلى الإنترنت، إن توفّرت.
7.4.6. إعدادات المزامنة
عمليات التنفيذ على الأجهزة:
- [C-0-1] يجب تفعيل الإعداد الرئيسي للمزامنة التلقائية تلقائيًا لكي تُعرِض الوسيلة
getMasterSyncAutomatically()
قيمة "true".
7.4.7. توفير البيانات
إذا كانت عمليات تنفيذ الأجهزة تتضمّن اتصالاً بمقدار محدّد، تكون على النحو التالي:
- [C-SR-1] يُنصح بشدة بتوفير وضع توفير البيانات.
إذا كانت عمليات تنفيذ الأجهزة توفّر وضع توفير البيانات، يجب أن:
- [C-1-1] يجب أن تتوافق مع جميع واجهات برمجة التطبيقات في فئة
ConnectivityManager
كما هو موضّح في مستندات حزمة تطوير البرامج (SDK)
إذا لم توفّر عمليات تنفيذ الأجهزة وضع "توفير البيانات"، يجب أن تستوفي الشروط التالية:
- [C-2-1] يجب عرض القيمة
RESTRICT_BACKGROUND_STATUS_DISABLED
لمحاولةConnectivityManager.getRestrictBackgroundStatus()
- [C-2-2] يجب عدم بث
ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED
.
7.4.8. العناصر الآمنة
إذا كانت عمليات تنفيذ الأجهزة متوافقة مع Open Mobile API، وتحتوي على عناصر آمنة، وتوفّرها للتطبيقات التابعة لجهات خارجية، فإنّها:
[C-1-1] يجب إدراج أدوات قراءة العناصر الآمنة المتاحة من خلال واجهة برمجة التطبيقات
android.se.omapi.SEService.getReaders()
.[C-1-2] يجب الإفصاح عن علامات الميزات الصحيحة من خلال
android.hardware.se.omapi.uicc
للجهاز الذي يتضمّن عناصر أمان مستندة إلى شريحة UICC،android.hardware.se.omapi.ese
للجهاز الذي يتضمّن عناصر أمان مستندة إلى شريحة eSE،android.hardware.se.omapi.sd
للجهاز الذي يتضمّن عناصر أمان مستندة إلى شريحة SD.
7.5. الكاميرات
إذا كانت عمليات تنفيذ الأجهزة تتضمّن كاميرا واحدة على الأقل، يجب أن تستوفي الشروط التالية:
- [C-1-1] يجب الإفصاح عن علامة ميزة
android.hardware.camera.any
. - [C-1-2] يجب أن يكون من الممكن للتطبيق تخصيص ملفّات رسومات bitmap RGBA_8888 وعددها 3 متزامنة تساوي حجم الصور التي تنتجها أداة استشعار الكاميرا ذات الدقة الأعلى على الجهاز، وذلك عندما تكون الكاميرا مفتوحة بغرض المعاينة الأساسية وتصوير الصور الثابتة.
- [C-1-3] يجب التأكّد من أنّ تطبيق الكاميرا التلقائي المثبَّت مسبقًا
الذي يعالج النوايا
MediaStore.ACTION_IMAGE_CAPTURE
،MediaStore.ACTION_IMAGE_CAPTURE_SECURE
، أوMediaStore.ACTION_VIDEO_CAPTURE
، هو المسؤول عن إزالة الموقع الجغرافي للمستخدم في البيانات الوصفية للصورة قبل إرسالها إلى التطبيق المستلِم عندما لا يحتوي التطبيق المستلِم علىACCESS_FINE_LOCATION
.
7.5.1. الكاميرا الخلفية
الكاميرا الخلفية هي كاميرا موجودة على جانب الجهاز المقابل للشاشة، أي أنها تلتقط صورًا للمشاهد على الجانب البعيد من الجهاز، مثل الكاميرا التقليدية.
عمليات التنفيذ على الأجهزة:
- يجب أن تتضمّن كاميرا خلفية.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن كاميرا خلفية واحدة على الأقل، يجب استيفاء الشروط التالية:
- [C-1-1] يجب الإبلاغ عن علامة الميزة
android.hardware.camera
وandroid.hardware.camera.any
. - [C-1-2] يجب أن تكون درجة دقة الصورة 2 ميغابكسل على الأقل.
- يجب أن يتضمّن ميزة ضبط التركيز التلقائي بالأجهزة أو البرامج في برنامج تشغيل الكاميرا (شفّاف لبرنامج التطبيق).
- قد تحتوي على أجهزة ذات تركيز ثابت أو ميزة "عمق مجال ممتد".
- قد تتضمّن وميضًا.
إذا كانت الكاميرا تتضمّن فلاشًا:
- [C-2-1] يجب ألّا يكون مصباح الفلاش مضاءً أثناء تسجيل مثيل
android.hardware.Camera.PreviewCallback
على سطح معاينة الكاميرا، ما لم يفعِّل التطبيقFLASH_MODE_AUTO
بوضوح فلاشًا من خلال تفعيل سمةFLASH_MODE_AUTO
أوFLASH_MODE_ON
لعنصرCamera.Parameters
. يُرجى العِلم أنّ هذا القيد لا ينطبق على تطبيق كاميرا النظام المضمّن في الجهاز، بل على التطبيقات التابعة لجهات خارجية فقط التي تستخدمCamera.PreviewCallback
.
7.5.2. الكاميرا الأمامية
الكاميرا الأمامية هي كاميرا موجودة على جانب الجهاز نفسه الذي تقع عليه الشاشة، أي كاميرا تُستخدَم عادةً لتصوير المستخدم، مثل مكالمات الفيديو والتطبيقات المشابهة.
عمليات التنفيذ على الأجهزة:
- قد تتضمّن كاميرا أمامية.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن كاميرا أمامية واحدة على الأقل، يجب استيفاء الشروط التالية:
- [C-1-1] يجب الإبلاغ عن علامة الميزة
android.hardware.camera.any
وandroid.hardware.camera.front
. - [C-1-2] يجب أن تكون درجة دقة الفيديوهات على الأقل VGA (640x480 بكسل).
- [C-1-3] يجب عدم استخدام الكاميرا الأمامية كإعداد تلقائي لواجهة برمجة التطبيقات Camera API، ويجب عدم ضبط واجهة برمجة التطبيقات لمعالجة الكاميرا الأمامية على أنّها الكاميرا الخلفية التلقائية، حتى إذا كانت الكاميرا الوحيدة على الجهاز.
- [C-1-4] يجب أن تكون معاينة الكاميرا معكوسة أفقيًا بالنسبة إلى الاتجاه الذي يحدّده التطبيق عندما يطلب التطبيق الحالي صراحةً تدوير شاشة الكاميرا من خلال طلب
android.hardware.Camera.setDisplayOrientation()
. في المقابل، يجب عكس المعاينة على محوره الأفقي التلقائي للجهاز عندما لا يطلب التطبيق الحالي صراحةً تبديل شاشة الكاميرا من خلال استدعاء الأسلوبandroid.hardware.Camera.setDisplayOrientation()
. - [C-1-5] يجب عدم عكس صور الفيديو أو الصور الثابتة النهائية التي تم التقاطها المرسَلة إلى طلبات استدعاء التطبيق أو التي تم حفظها في مساحة تخزين الوسائط.
- [C-1-6] يجب أن تعكس الصورة المعروضة في معاينة المشاركة بالطريقة نفسها مثل بث صورة معاينة الكاميرا.
- قد تتضمّن ميزات (مثل التركيز التلقائي والفلاش وما إلى ذلك) متاحة لكاميرات الرؤية الخلفية كما هو موضّح في الفقرة 7.5.1.
إذا كان بإمكان المستخدم تدوير عمليات تنفيذ الأجهزة (مثل تلقائيًا من خلال مقياس تسارع أو يدويًا من خلال إدخال المستخدم):
- [C-2-1] يجب أن تكون معاينة الكاميرا معكوسة أفقيًا بالنسبة إلى اتجاه الجهاز الحالي.
7.5.3. الكاميرا الخارجية
عمليات التنفيذ على الأجهزة:
- قد تتضمّن إتاحة استخدام كاميرا خارجية ليست متصلة دائمًا بالضرورة.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن إتاحة استخدام كاميرا خارجية، يجب أن تستوفي الشروط التالية:
- [C-1-1] يجب الإفصاح عن علامتَي ميزة المنصة
android.hardware.camera.external
وandroid.hardware camera.any
. - [C-1-2] يجب أن تكون متوافقة مع فئة USB Video Class (UVC 1.0 أو إصدار أحدث) في حال ربط الكاميرا الخارجية من خلال منفذ مضيف USB.
- [C-1-3] يجب اجتياز اختبارات CTS للكاميرا مع توصيل كاميرا خارجية. تتوفّر تفاصيل اختبار مجموعة أدوات اختبار التوافق (CTS) للكاميرا على source.android.com.
- يجب أن تتيح ضغط الفيديوهات، مثل MJPEG، لنقل مجريات بث بدون ترميز وبجودة عالية (أي مجريات بث صور خام أو مضغوط بشكل مستقل).
- قد تتيح استخدام كاميرات متعددة.
- قد تتيح ميزة ترميز الفيديو المستند إلى الكاميرا.
في حال توفّر ميزة ترميز الفيديو بالاستناد إلى الكاميرا:
- [C-2-1] يجب أن يكون بالإمكان بث محتوى متزامن غير مشفَّر أو بتنسيق MJPEG (بدقة QVGA أو أعلى) لإتمام عملية تنفيذ الجهاز.
7.5.4. سلوك Camera API
يتضمّن Android حِزمتَي واجهة برمجة تطبيقات للوصول إلى الكاميرا، وتعرض واجهة برمجة التطبيقات الأحدث android.hardware.camera2 للتطبيق عناصر تحكّم من المستوى الأدنى في الكاميرا، بما في ذلك عمليات البث أو اللقطات السريعة الفعّالة بدون نسخ وعناصر التحكّم في كل إطار من ناحية مستوى الإضاءة ودرجة الإضاءة ودرجة توازن اللون الأبيض وتحويل الألوان وإزالة الضوضاء والتحسين وغيرها.
تم وضع علامة على حزمة واجهة برمجة التطبيقات القديمة،android.hardware.Camera
، بأنّها متوقّفة نهائيًا في
Android 5.0، ولكن من المفترض أن تظل متاحة للتطبيقات لاستخدامها. يجب أن تضمن عمليات تنفيذ التطبيقات على أجهزة Android مواصلة توفُّر واجهة برمجة التطبيقات كما هو موضّح في
هذا القسم وفي حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
يجب أن يكون الأداء والجودة متطابقَين في كلتا حِزم واجهتَي برمجة التطبيقات لكل الميزات المشتركة بين فئة android.hardware.Camera المهجورة وحزمة android.hardware.camera2 الأحدث. على سبيل المثال، يجب أن تكون سرعة ضبط التركيز التلقائي ودقته متطابقتين عند استخدام الإعدادات نفسها، ويجب أن تكون جودة الصور التي تم التقاطها متطابقة. بالنسبة إلى الميزات التي تعتمد على المعاني المختلفة لواجهتَي برمجة التطبيقات، ليس من المطلوب أن تتطابق سرعتها أو جودتها، ولكن يجب أن تتطابق بأكبر قدر ممكن.
يجب أن تطبّق عمليات تنفيذ الأجهزة السلوكيات التالية لواجهتَي برمجة التطبيقات المتعلّقتَين بالكاميرا، وذلك لجميع الكاميرات المتاحة. عمليات التنفيذ على الأجهزة:
- [C-0-1] يجب استخدام
android.hardware.PixelFormat.YCbCr_420_SP
لمعاينة البيانات المقدَّمة إلى عمليات استدعاء التطبيق عندما لم يسبق للتطبيق استخدامandroid.hardware.Camera.Parameters.setPreviewFormat(int)
. - [C-0-2] يجب أن يكون
android.hardware.Camera.PreviewCallback
بتنسيق ترميز NV21 أيضًا عندما يسجِّل أحد التطبيقات مثيلًا منandroid.hardware.Camera.PreviewCallback
ويطلب النظام طريقةonPreviewFrame()
ويكون تنسيق المعاينة هو YCbCr_420_SP، ويتم تمرير البيانات في بايت[] إلىonPreviewFrame()
. وهذا يعني أنّه يجب أن يكون NV21 هو الإعداد التلقائي. - [C-0-3] يجب أن يكون الجهاز متوافقًا مع تنسيق YV12 (كما هو موضّح في الثابت
android.graphics.ImageFormat.YV12
) لمعاينات الكاميرا لكلٍّ من الكاميرا الأمامية والخلفية فيandroid.hardware.Camera
. (قد يستخدم جهاز الترميز الفيديو والكاميرا أي تنسيق أصلي للبكسل، ولكن يجب أن يتيح تنفيذ الجهاز التحويل إلى YV12). - [C-0-4] يجب أن تتوافق مع تنسيقَي
android.hardware.ImageFormat.YUV_420_888
وandroid.hardware.ImageFormat.JPEG
كمخرجات من خلال واجهة برمجة التطبيقاتandroid.media.ImageReader
لأجهزةandroid.hardware.camera2
التي تُعلِن عن إمكانيةREQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE
فيandroid.request.availableCapabilities
. - [C-0-5] يجب أن يظلّ تطبيقك ينفذ Camera API بالكامل
المُدرَجة في مستندات حزمة تطوير البرامج (SDK) لنظام Android، بغض النظر عمّا إذا كان الجهاز
يتضمّن ميزة ضبط التركيز التلقائي للأجهزة أو إمكانات أخرى. على سبيل المثال، يجب أن تظل الكاميرات التي carece of autofocus تستدعي أي مثيلات registered
android.hardware.Camera.AutoFocusCallback
(على الرغم من أنّ هذا ليس له صلة بكاميرا لا تتضمّن ميزة ضبط التركيز التلقائي). يُرجى العِلم أنّ ذلك ينطبق على الكاميرات المزوّدة بمثبّت كاميرا أمامي. على سبيل المثال، على الرغم من أنّ معظم الكاميرات المزوّدة بمثبّت كاميرا أمامي لا تتيح استخدام ميزة "التركيز التلقائي"، يجب أن تظلّ عمليات استدعاء واجهة برمجة التطبيقات "مزوّرة" كما هو موضّح. - [C-0-6] يجب أن يتعرّف على كل اسم مَعلمة ويحترمه
يُحدَّد على أنّه ثابت في فئة
android.hardware.Camera.Parameters
وفئةandroid.hardware.camera2.CaptureRequest
. في المقابل، يجب ألا تلتزم عمليات تنفيذ الأجهزة بثوابت السلاسل المُرسَلة إلى طريقةandroid.hardware.Camera.setParameters()
أو تتعرّف عليها، باستثناء تلك المُوثَّقة كثوابت فيandroid.hardware.Camera.Parameters
. وهذا يعني أنّه يجب أن تتوافق تطبيقات الأجهزة مع جميع مَعلمات الكاميرا العادية إذا كان الجهاز يسمح بذلك، ويجب ألّا تتوافق مع أنواع مَعلمات الكاميرا المخصّصة. على سبيل المثال، يجب أن تتيح عمليات تنفيذ الأجهزة التي تتيح التقاط الصور باستخدام تقنيات التصوير بنطاق عالي الديناميكية (HDR) استخدام مَعلمة الكاميراCamera.SCENE_MODE_HDR
. - [C-0-7] يجب الإبلاغ عن المستوى المناسب من التوافق باستخدام السمة
android.info.supportedHardwareLevel
كما هو موضّح في حزمة تطوير البرامج (SDK) لنظام التشغيل Android والإبلاغ عن رموز ميزات إطار العمل المناسبة. - [C-0-8] يجب أيضًا الإفصاح عن إمكانات الكاميرا الفردية التي تبلغ
android.hardware.camera2
من خلال السمةandroid.request.availableCapabilities
، والإفصاح عن رموز الميزات المناسبة، ويجب تحديد رمز الميزة إذا كان أي من أجهزة الكاميرا المُرفَقة توفّر الميزة. - [C-0-9] يجب بث
Camera.ACTION_NEW_PICTURE
intent عند التقاط صورة جديدة بالكاميرا وإضافة إدخال الصورة إلى "متجر الوسائط". - [C-0-10] يجب بث
Camera.ACTION_NEW_VIDEO
intent عند تسجيل فيديو جديد بواسطة الكاميرا وإضافة إدخال picture إلى "متجر الوسائط". - [C-0-11] يجب أن تكون جميع الكاميرات متاحة للوصول إليها من خلال واجهة برمجة التطبيقات
android.hardware.Camera
المتوقفة نهائيًا، كما يجب أن تكون متاحة للوصول إليها من خلال واجهة برمجة التطبيقاتandroid.hardware.camera2
. - [C-0-12] يجب التأكّد من عدم تغيير مظهر الوجه، بما في ذلك
ولكن ليس على سبيل الحصر، تغيير شكل الوجه أو درجة لون البشرة أو
تنعيم البشرة لأي واجهة برمجة تطبيقات
android.hardware.camera2
أوandroid.hardware.Camera
. - [C-SR-1] بالنسبة إلى الأجهزة التي تحتوي على كاميرات RGB متعددة تواجه الاتجاه نفسه،
ننصح بشدة بتوفير جهاز كاميرا منطقي يسرد
القدرة
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
، المكوّن من جميع كاميرات RGB التي تواجه هذا الاتجاه كأجهزة فرعية مادية.
إذا كانت عمليات تنفيذ الأجهزة توفّر واجهة برمجة تطبيقات خاصة بالكاميرا لتطبيقات الجهات الخارجية، يجب أن:
- [C-1-1] يجب تنفيذ واجهة برمجة تطبيقات الكاميرا هذه باستخدام واجهة برمجة التطبيقات
android.hardware.camera2
. - يجوز تقديم علامات المورّدين و/أو الإضافات إلى واجهة برمجة التطبيقات
android.hardware.camera2
.
7.5.5. اتجاه الكاميرا
إذا كانت عمليات تنفيذ الأجهزة تتضمّن كاميرا أمامية أو خلفية، يجب أن تستوفي هذه الكاميرات الشروط التالية:
- [C-1-1] يجب توجيهها بحيث يكون الجانب الطويل من الكاميرا متوافقًا مع الجانب الطويل من الشاشة. وهذا يعني أنّه عند حمل الجهاز في الوضع الافقي ، يجب أن تلتقط الكاميرات الصور في الوضع الأفقي. وينطبق ذلك بغض النظر عن الاتجاه الطبيعي للجهاز، أي أنّه ينطبق على الأجهزة التي تستخدم الوضع الأفقي بشكل أساسي وكذلك الأجهزة التي تستخدم الوضع العمودي بشكل أساسي.
إنّ الأجهزة التي تستوفي جميع المعايير التالية معفاة من الشرط أعلاه:
- يستخدم الجهاز شاشات ذات أشكال هندسية متغيرة، مثل الشاشات القابلة للطي أو المزوّدة بمفصلة.
- عند تغيير حالة الجهاز المُثبَّت عليه الغطاء أو المفصل، يبدِّل الجهاز بين اتجاهين: الوضع العمودي الأساسي إلى الوضع الأفقي الأساسي (أو العكس).
7.6. الذاكرة ومساحة التخزين
7.6.1. الحد الأدنى للذاكرة ومساحة التخزين
عمليات التنفيذ على الأجهزة:
- [C-0-1] يجب أن يتضمّن التطبيق مدير تنزيل يمكن للتطبيقات استخدامه لتنزيل ملفات البيانات، ويجب أن يكون قادرًا على تنزيل ملفات فردية بحجم 100 ميغابايت على الأقل إلى المسار التلقائي "للذاكرة المؤقتة".
7.6.2. مساحة التخزين المشتركة للتطبيق
عمليات التنفيذ على الأجهزة:
- [C-0-1] يجب أن يوفّر مساحة تخزين تتم مشاركتها بين التطبيقات، والتي يُشار إليها أيضًا في كثير من الأحيان باسم "مساحة التخزين الخارجية المشتركة" أو "مساحة التخزين المشتركة للتطبيقات" أو باسم مسار Linux "/sdcard" الذي يتم تثبيتها عليه.
- [C-0-2] يجب ضبطه باستخدام مساحة تخزين مشترَكة يتم تركيبها تلقائيًا، بعبارة أخرى "جاهز للاستخدام"، بغض النظر عمّا إذا كانت مساحة التخزين مضمّنة في مكوّن تخزين داخلي أو وسيط تخزين قابل للإزالة (مثل قاعدة تركيب البطاقة الرقمية الآمنة).
- [C-0-3] يجب ربط مساحة التخزين المشتركة للتطبيق مباشرةً بمسار Linux
sdcard
أو تضمين رابط رمزي لنظام التشغيل Linux منsdcard
إلى نقطة الربط الفعلية. - [C-0-4] يجب تفعيل
مساحة التخزين ذات النطاق المحدّد
تلقائيًا لجميع
التطبيقات التي تستهدف المستوى 29 أو أعلى لواجهة برمجة التطبيقات، باستثناء الحالة التالية:
- عندما يطلب التطبيق
android:requestLegacyExternalStorage="true"
في بيانه
- عندما يطلب التطبيق
- [C-0-5] يجب إخفاء البيانات الوصفية للموقع الجغرافي، مثل علامات Exif لنظام تحديد المواقع العالمي (GPS)، المخزّنة في
ملفات الوسائط عند الوصول إلى هذه الملفات من خلال
MediaStore
، إلا عندما يحصل التطبيق المُرسِل على إذنACCESS_MEDIA_LOCATION
.
قد تستوفي عمليات تنفيذ الأجهزة المتطلبات المذكورة أعلاه باستخدام أي من الخطوات التالية:
- مساحة تخزين قابلة للإزالة يمكن للمستخدم الوصول إليها، مثل فتحة بطاقة Secure Digital (SD)
- جزء من مساحة التخزين الداخلية (غير القابلة للإزالة) كما هو مُنفَّذ في المشروع المفتوح المصدر لنظام Android (AOSP)
إذا كانت عمليات تنفيذ الأجهزة تستخدم مساحة تخزين قابلة للإزالة لاستيفاء ال requirements أعلاه، يجب استيفاء الشروط التالية:
- [C-1-1] يجب أن توفّر واجهة مستخدم تحذيرية معروضة على الشاشة أو نافذة منبثقة تحذّر المستخدم في حال عدم إدخال وسيط تخزين في الفتحة.
- [C-1-2] يجب أن يتضمّن الجهاز وسيط تخزين بتنسيق FAT (مثل بطاقة SD) أو يجب أن يُظهر على العلبة والمواد الأخرى المتوفّرة في وقت الشراء أنّه يجب شراء وسيط التخزين بشكل منفصل.
إذا كانت عمليات تنفيذ الأجهزة تستخدِم جزءًا من مساحة التخزين غير القابلة للإزالة لتلبية المتطلبات أعلاه، يجب استيفاء ما يلي:
- يجب استخدام واجهة برمجة التطبيقات AOSP لمساحة التخزين المشترَكة للتطبيق الداخلي.
- يجوز له مشاركة مساحة التخزين مع البيانات الخاصة بالتطبيق.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ USB متوافقًا مع وضع الأجهزة الطرفية USB، يجب أن تستوفي الشروط التالية:
- [C-3-1] يجب توفير آلية للوصول إلى البيانات في التطبيق مساحة التخزين المشتركة من جهاز كمبيوتر مضيف.
- يجب أن يعرض المحتوى من كلا مسارَي التخزين بشكل شفاف من خلال
خدمة الماسح الضوئي للوسائط في Android و
android.provider.MediaStore
. - يجوز استخدام وحدة تخزين USB المجمّعة، ولكن يجب استخدام بروتوكول نقل الوسائط لتلبية هذا الشرط.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ USB مع وضع USB للأجهزة الطرفية وتتوافق مع بروتوكول نقل الوسائط، يجب أن تستوفي المتطلبات التالية:
- يجب أن يكون متوافقًا مع مضيف MTP المرجعي لنظام التشغيل Android، وهو نقل ملفات Android.
- يجب أن يُبلغ عن فئة جهاز USB 0x00.
- يجب أن يُبلغ عن اسم واجهة USB "MTP".
7.6.3. مساحة تخزين قابلة للاستخدام
إذا كان من المتوقّع أن يكون الجهاز جوّالاً بطبيعته على عكس التلفزيون، تكون عمليات تنفيذ الأجهزة على النحو التالي:
- [C-SR-1] يُنصح بشدة بتنفيذ مساحة التخزين القابلة للتخصيص في موقع ثابت على المدى الطويل، لأنّ فصلها عن الجهاز عن طريق الخطأ يمكن أن يؤدي إلى فقدان البيانات أو تلفها.
إذا كان منفذ جهاز التخزين القابل للإزالة في مكان ثابت على المدى الطويل، مثل داخل مقصورة البطارية أو غطاء واقي آخر، تكون عمليات تنفيذ الجهاز على النحو التالي:
- [C-SR-2] ننصح بشدة بتنفيذ وحدة تخزين قابلة للاستخدام.
7.7. USB
إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ USB، يجب استيفاء الشروط التالية:
- يجب أن يكون متوافقًا مع وضع الجهاز الملحق USB ووضع مضيف USB.
- يجب أن يتيح الجهاز إيقاف إرسال البيانات عبر USB.
7.7.1. وضع الأجهزة الملحقة USB
إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ USB متوافقًا مع وضع الجهاز الملحق:
- [C-1-1] يجب أن يكون المنفذ قابلاً للتوصيل بجهاز مضيف USB يحتوي على منفذ USB عادي من النوع A أو من النوع C.
- [C-1-2] يجب الإبلاغ عن القيمة الصحيحة لـ
iSerialNumber
في معيار USB وصف الجهاز من خلالandroid.os.Build.SERIAL
. - [C-1-3] يجب أن يرصد الشاحنان اللذان يستهلكان 1.5 أمبير و3.0 أمبير وفقًا لمعيار المقاوم لـ Type-C، ويجب أن يرصد التغييرات في الإعلان إذا كانا متوافقَين مع USB Type-C.
- [C-SR-1] يجب أن يستخدم المنفذ عامل شكل USB من النوع micro-B أو micro-AB أو Type-C. ننصح بشدة بتوافق أجهزة Android الحالية والجديدة مع هذه المتطلبات حتى تتمكّن من الترقية إلى إصدارات المنصة المستقبلية.
- [C-SR-2] يجب أن يكون المنفذ في أسفل الجهاز (وفقًا للاتجاه الطبيعي) أو تفعيل ميزة دوران الشاشة من خلال البرامج في جميع التطبيقات (بما في ذلك الشاشة الرئيسية)، حتى يتم عرض المحتوى على الشاشة بشكل صحيح عند توجيه الجهاز مع وضع المنفذ في أسفل الجهاز. ننصح بشدة بتوافق أجهزة Android الحالية والجديدة مع هذه المتطلبات حتى تتمكّن من الترقية إلى إصدارات المنصة المستقبلية.
- [C-SR-3] يجب أن يتيح الجهاز سحب تيار 1.5 أمبير أثناء إشارة HS chirp وعمليات نقل البيانات على النحو المحدّد في مواصفة شحن البطارية عبر USB، المراجعة 1.2. ننصح بشدة بتوافق أجهزة Android الحالية والجديدة مع هذه المتطلبات حتى تتمكّن من الترقية إلى إصدارات المنصة المستقبلية.
- [C-SR-4] يُنصح بشدة بعدم استخدام طرق الشحن الخاصة التي تعمل على تعديل جهد Vbus الكهربائي إلى ما بعد المستويات التلقائية، أو تغيير أدوار الحوض/المصدر على النحو، قد يؤدي ذلك إلى حدوث مشاكل في إمكانية التشغيل التفاعلي مع الشواحن أو الأجهزة التي تتوافق مع طرق "توصيل الطاقة عبر USB" العادية. على الرغم من أنّه يُنصح بشدة باستخدام هذه الطريقة، قد نشترط في الإصدارات المستقبلية من Android أن تتوافق جميع الأجهزة التي تستخدم موصلات من النوع C مع الشواحن العادية من النوع C.
- [C-SR-5] يُنصح بشدة بتوفُّر ميزة "إرسال الطاقة" لنقل البيانات و تبديل دور الطاقة عندما يتوفّر منفذ USB من النوع C ووضع مضيف USB.
- يجب أن يكون متوافقًا مع ميزة "إرسال الطاقة" للشحن بتيار عالي الجهد ويجب أن يكون متوافقًا مع الأوضاع البديلة، مثل "إخراج الشاشة".
- يجب تنفيذ واجهة برمجة التطبيقات وتحديد مواصفات Android Open Accessory (AOA) كما هو موضح في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ USB وتنفِّذ مواصفات AOA ، يجب أن تستوفي المتطلبات التالية:
- [C-2-1] يجب الإفصاح عن توافق التطبيق مع ميزة الجهاز
android.hardware.usb.accessory
. - [C-2-2] يجب أن تتضمّن فئة وحدة تخزين USB الضخمة السلسلة "android" في
نهاية سلسلة وصف الواجهة
iInterface
لوحدة تخزين USB الضخمة.
7.7.2. وضع مضيف USB
إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ USB متوافقًا مع وضع المضيف، يجب أن تستوفي المتطلبات التالية:
- [C-1-1] يجب تنفيذ واجهة برمجة التطبيقات Android USB host API كما هو موضّح في مستندات
حزمة تطوير البرامج (SDK) لنظام التشغيل Android، ويجب الإفصاح عن توفّر ميزة الأجهزة
android.hardware.usb.host
. - [C-1-2] يجب أن تتيح إمكانية توصيل أجهزة USB الملحقة العادية،
بمعنى آخر، يجب أن:
- أن يتضمّن الجهاز منفذًا من النوع C أو أن يتم شحنه مع كابلات تتيح تحويل منفذ مملوك على الجهاز إلى منفذ USB عادي من النوع C (جهاز USB من النوع C)
- أن يكون مزوّدًا بمنفذ من النوع "أ" على الجهاز أو أن يتم شحنه مع كابلات تتيح تحويل منفذ خاص على الجهاز إلى منفذ USB عادي من النوع "أ"
- أن يتضمّن منفذ micro-AB على الجهاز، والذي من المفترض أن يتم شحنه مع كابل محوِّل إلى منفذ من النوع A عادي
- [C-1-3] يجب عدم شحن الجهاز مع محوِّل يحول منفذ USB من النوع A أو منفذَي micro-AB إلى منفذ من النوع C (مقبس).
- [C-SR-1] يُنصح بشدة بتنفيذ فئة الصوت عبر USB كما هو موضّح في مستندات حزمة تطوير البرامج (SDK) لنظام التشغيل Android.
- يجب أن يكون متوافقًا مع شحن الجهاز الملحق USB المتصل به أثناء بدء التشغيل، وأن يعرض تيار مصدر لا يقل عن 1.5 أمبير كما هو موضّح في قسم "مَعلمات إنهاء الاتصال" من الإصدار 1.2 من مواصفات كابل USB ووصلاته من النوع C لموصّلات USB من النوع C أو استخدام نطاق تيار الإخراج لاتصال منفذ الشحن(CDP) كما هو موضّح فيمواصفات شحن البطارية عبر USB، الإصدار 1.2 لموصّلات Micro-AB.
- يجب أن تتوافق مع معايير USB من النوع C وأن تتيح استخدامها.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ USB متوافقًا مع وضع المضيف وفئة USB للصوت، يجب أن تستوفي المتطلبات التالية:
- [C-2-1] يجب أن يكون متوافقًا مع فئة USB HID.
- [C-2-2] يجب أن يتيح الجهاز رصد حقول بيانات HID التالية
وربطها كما هو محدّد في جداول استخدام USB HID
وطلب استخدام الأوامر الصوتية
بثوابت
KeyEvent
على النحو التالي:- رقم تعريف صفحة الاستخدام (0xC) ورقم تعريف الاستخدام (0x0CD):
KEYCODE_MEDIA_PLAY_PAUSE
- رقم تعريف صفحة الاستخدام (0xC) ورقم تعريف الاستخدام (0x0E9):
KEYCODE_VOLUME_UP
- رقم تعريف استخدام صفحة الاستخدام (0xC):
KEYCODE_VOLUME_DOWN
- صفحة الاستخدام (0xC) معرّف الاستخدام (0x0CF):
KEYCODE_VOICE_ASSIST
- رقم تعريف صفحة الاستخدام (0xC) ورقم تعريف الاستخدام (0x0CD):
إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ USB متوافقًا مع وضع المضيف و إطار عمل الوصول إلى مساحة التخزين (SAF)، يجب استيفاء الشروط التالية:
- [C-3-1] يجب أن يتعرّف التطبيق على أي أجهزة متصلة عن بُعد من خلال بروتوكول نقل الوسائط (MTP)
ويتيح الوصول إلى محتوياتها من خلال طلبات الإجراء
ACTION_GET_CONTENT
وACTION_OPEN_DOCUMENT
وACTION_CREATE_DOCUMENT
. .
إذا كانت عمليات تنفيذ الأجهزة تتضمّن منفذ USB متوافقًا مع وضع المضيف وUSB Type-C، يجب استيفاء الشروط التالية:
- [C-4-1] يجب تنفيذ وظيفة "منفذ الدور المزدوج" كما هو محدّد في مواصفة USB Type-C (الفقرة 4.5.1.3.3).
- [C-SR-2] يُنصح بشدة بتوفير منفذ DisplayPort، ويجب أن يتوافق مع سرعات نقل البيانات الفائقة USB ، ويُنصح بشدة بتوفير ميزة Power Delivery لتبادل دور نقل البيانات والطاقة.
- [C-SR-3] يُنصح بشدة بعدم إتاحة "وضع ملحق محوِّل الصوت" كما هو описан في "الملحق أ" من المراجعة 1.2 لمواصفات كابل USB من النوع C وموصّله.
- يجب تنفيذ نموذج Try.* الأنسب لشكل الجهاز. على سبيل المثال، يجب أن ينفِّذ الجهاز المحمول طراز Try.SNK.
7.8. الصوت
7.8.1. الميكروفون
إذا كانت عمليات تنفيذ الأجهزة تتضمّن ميكروفونًا، يجب أن تستوفي الشروط التالية:
- [C-1-1] يجب الإبلاغ عن ثابت الميزة
android.hardware.microphone
. - [C-1-2] يجب استيفاء متطلبات التسجيل الصوتي في الفقرة 5.4.
- [C-1-3] يجب استيفاء متطلبات وقت استجابة الصوت في القسم 5.6.
- [C-SR-1] يُنصح بشدة بتوفير ميزة تسجيل الصوت بالقرب من ترددات الموجات فوق الصوتية كما هو موضّح في الفقرة 7.8.3.
إذا حذفت عمليات تنفيذ الأجهزة ميكروفونًا، يجب أن:
- [C-2-1] يجب عدم الإبلاغ عن ثابت الميزة
android.hardware.microphone
. - [C-2-2] يجب تنفيذ واجهة برمجة التطبيقات لتسجيل الصوت على الأقل كعمليات لا تتطلب تدخلًا، وفقًا لتعليمات الفقرة 7.
7.8.2. إخراج الصوت
إذا كانت عمليات تنفيذ الأجهزة تتضمّن مكبّر صوت أو منفذ مخرج صوت/وسائط متعددة لجهاز صوتي خارجي، مثل مقبس صوت 3.5 ملم مزوّد بأربعة موصلات أو منفذ وضع مضيف USB باستخدام فئة صوت USB، يجب استيفاء الشروط التالية:
- [C-1-1] يجب الإبلاغ عن ثابت الميزة
android.hardware.audio.output
. - [C-1-2] يجب أن تستوفي متطلبات تشغيل الصوت الواردة في الفقرة 5.5.
- [C-1-3] يجب استيفاء متطلبات وقت استجابة الصوت في القسم 5.6.
- [C-SR-1] يُنصح بشدة بتوفير ميزة تشغيل المحتوى بالقرب من الحد الأقصى لترددات فوق الصوتية كما هو موضّح في الفقرة 7.8.3.
إذا لم تتضمّن عمليات تنفيذ الأجهزة مكبّر صوت أو منفذ إخراج صوت، يجب أن تستوفي المتطلبات التالية:
- [C-2-1] يجب عدم الإبلاغ عن ميزة
android.hardware.audio.output
. - [C-2-2] يجب تنفيذ واجهات برمجة التطبيقات ذات الصلة بإخراج الصوت كعمليات لا تؤدي إلى أيّ إجراء على الأقل.
لأغراض هذا القسم، "منفذ الإخراج" هو واجهة مادية مثل مقبس صوت مقاس 3.5 ملم أو منفذ HDMI أو منفذ وضع مضيف USB مع فئة صوت USB. لا يُعدّ توفُّر مخرج صوت عبر بروتوكولات تستند إلى البث اللاسلكي، مثل البلوتوث أو WiFi أو الشبكة الخلوية، مؤهلاً لتضمين "منفذ إخراج".
7.8.2.1. منافذ الصوت التناظري
لكي تكون متوافقة مع سماعات الرأس وملحقات الصوت الأخرى التي تستخدم مقبس الصوت مقاس 3.5 ملم في منظومة Android المتكاملة، إذا كانت تطبيقات الأجهزة تتضمّن منفذًا واحدًا أو أكثر للصوت التناظري، يجب أن تستوفي المتطلبات التالية:
- [C-SR-1] يُنصح بشدة بتضمين مقبس صوت 3.5 ملم مزوّد بأربعة موصلات على الأقل في أحد منافذ الوسائط الصوتية على الأقل.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقبس صوت مقاس 3.5 ملم مزوّدًا بأربعة موصلات، يجب استيفاء الشروط التالية:
- [C-1-1] يجب أن تتيح إمكانية تشغيل الصوت على سماعات الرأس الاستيريو وسماعات الرأس الاستيريو المزوّدة بميكروفون.
- [C-1-2] يجب أن تتيح استخدام مقابس الصوت TRRS بترتيب دبوس CTIA.
- [C-1-3] يجب أن يتيح الجهاز رصد نطاقات المقاومة المكافئة التالية بين الميكروفون وموصّلات الدائرة الأرضية في مقبس الصوت وربطها بالرموز الرئيسية:
- 70 أوم أو أقل:
KEYCODE_HEADSETHOOK
- 210-290 ohm:
KEYCODE_VOLUME_UP
- 360-680 ohm:
KEYCODE_VOLUME_DOWN
- 70 أوم أو أقل:
- [C-1-4] يجب أن يؤدي إدخال القابس إلى تنشيط
ACTION_HEADSET_PLUG
، ولكن فقط بعد أن تلمس جميع جهات الاتصال في القابس الأجزاء ذات الصلة في المقبس. - [C-1-5] يجب أن يكون قادرًا على توفير 150 مللي فولت ± 10% من الجهد الكهربي الخارج على ممانعة مكبّر صوت تبلغ 32 أوم.
- [C-1-6] يجب أن يكون جهد الميكروفون المرجعي بين 1.8 فولت و2.9 فولت.
- [C-1-7] يجب رصد ونَسْق رمز المفتاح التالي
لمدى المقاومة المكافئة بين الميكروفون وسلكان الأرض
في مقبس الصوت:
- من 110 إلى 180 أوم:
KEYCODE_VOICE_ASSIST
- من 110 إلى 180 أوم:
- [C-SR-2] يُنصح بشدة بتوفير مقابس صوت تتضمّن ترتيب دبوس OMTP.
- [C-SR-3] يُنصح بشدة بتوفُّر ميزة تسجيل الصوت من سماعات الرأس المزوّدة بميكروفون والتي توفّر صوتًا ستيريو.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن مقبس صوت 3.5 ملم مزوّدًا بأربعة موصلات وتتوافق مع استخدام
الميكروفون، وبثّت الرسالة android.intent.action.HEADSET_PLUG
مع ضبط قيمة الملحق المتمثل في الميكروفون على 1، يعني ذلك ما يلي:
- [C-2-1] يجب أن يكون الجهاز مزوّدًا بميزة رصد الميكروفون في ملحق الصوت الموصول.
7.8.2.2. منافذ الصوت الرقمي
أن تكون متوافقة مع سماعات الرأس وملحقات الصوت الأخرى التي تستخدم قوابس USB-C وتنفيذ (فئة الصوت عبر USB) على مستوى منظومة Android المتكاملة كما هو محدّد في مواصفات سماعات الرأس USB لأجهزة Android
راجِع القسم 2.2.1 لمعرفة المتطلبات الخاصة بالأجهزة.
7.8.3. الموجات فوق الصوتية القريبة
يتراوح نطاق الصوت بالقرب من الموجات فوق الصوتية بين 18.5 كيلوهرتز و20 كيلوهرتز.
عمليات التنفيذ على الأجهزة:
- يجب الإبلاغ بشكل صحيح عن توفُّر ميزة الصوت بالقرب من الموجات فوق الصوتية من خلال واجهة برمجة التطبيقات AudioManager.getProperty على النحو التالي:
إذا كانت قيمة PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND
هي "صحيح"، يجب استيفاء المتطلبات التالية لمصادر الصوت
VOICE_RECOGNITION
وUNPROCESSED
:
- [C-1-1] يجب ألا يقلّ متوسط استجابة الطاقة للميكروفون في النطاق من 18.5 كيلوهرتز إلى 20 كيلوهرتز عن 15 ديسيبل عن الاستجابة عند 2 كيلوهرتز.
- [C-1-2] يجب ألا تقل نسبة الإشارة إلى الضوضاء غير المحسوبة للميكروفون عن 50 ديسيبل عند سماع نغمة بتردد 19 كيلوهرتز ومستوى -26 ديسيبل في نطاقات التردد من 18.5 كيلوهرتز إلى 20 كيلوهرتز.
إذا كانت قيمة PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND
هي "true":
- [C-2-1] يجب ألا يقل متوسّط استجابة مكبّر الصوت في النطاق من 18.5 كيلوهرتز إلى 20 كيلوهرتز عن 40 ديسيبل أقل من الاستجابة عند 2 كيلوهرتز.
7.8.4. سلامة الإشارة
عمليات التنفيذ على الأجهزة:
- يجب أن يوفّر مسار إشارة صوتيًا خاليًا من الأعطال لكل من بثّي الإدخال والإخراج على الأجهزة الجوّالة، كما هو محدّد من خلال عدم حدوث أي أعطال يتم قياسها خلال اختبار لمدة دقيقة واحدة لكل مسار. يمكنك إجراء الاختبار باستخدام OboeTester "اختبار الأعطال التلقائي".
يتطلّب الاختبار استخدام محوّل صوت يُستخدَم مباشرةً في مقبس 3.5 ملم و/أو مع محوّل USB-C إلى 3.5 ملم. يجب اختبار جميع منافذ إخراج الصوت.
يتيح OboeTester حاليًا مسارات AAudio، لذا يجب اختبار المجموعات التالية بحثًا عن أي مشاكل باستخدام AAudio:
وضع الأداء | المشاركة | معدّل البيانات في الملف الصوتي الناتج | في Chans | Out Chans |
---|---|---|---|---|
LOW_LATENCY | حصري | غير محدّد | 1 | 2 |
LOW_LATENCY | حصري | غير محدّد | 2 | 1 |
LOW_LATENCY | مشترك | غير محدّد | 1 | 2 |
LOW_LATENCY | مشترك | غير محدّد | 2 | 1 |
لم يتم اختيار لون | مشترك | 48000 | 1 | 2 |
لم يتم اختيار لون | مشترك | 48000 | 2 | 1 |
لم يتم اختيار لون | مشترك | 44100 | 1 | 2 |
لم يتم اختيار لون | مشترك | 44100 | 2 | 1 |
لم يتم اختيار لون | مشترك | 16000 | 1 | 2 |
لم يتم اختيار لون | مشترك | 16000 | 2 | 1 |
يجب أن يستوفي البث الموثوق المعايير التالية لنسبة الإشارة إلى الضوضاء (SNR) وإجمالي التشوه التوافقي (THD) لموجة جيبية بتردد 2000 هرتز.
محوّل طاقة صوتية | THD | معدّل الضوضاء الديناميكي |
---|---|---|
مكبّر الصوت المدمج الأساسي، تم قياسه باستخدام ميكروفون مرجعي خارجي | أقل من %3.0 | >= 50 ديسيبل |
الميكروفون المدمج الأساسي، ويتم قياسه باستخدام مكبّر صوت مرجعي خارجي | أقل من %3.0 | >= 50 ديسيبل |
مقابس 3.5 ملم تناظرية مدمجة، تم اختبارها باستخدام محوّل loopback | أقل من %1 | >= 60 ديسيبل |
محوِّلات USB المزوَّدة مع الهاتف، والتي تم اختبارها باستخدام محوِّل loopback | أقل من %1 | >= 60 ديسيبل |
7.9. الواقع الافتراضي
يتضمّن نظام Android واجهات برمجة التطبيقات ووسائل مساعدة لإنشاء تطبيقات "الواقع الافتراضي" (VR) ، بما في ذلك تجارب الواقع الافتراضي العالية الجودة على الأجهزة الجوّالة. يجب أن تنفِّذ عمليات تنفيذ التطبيقات على الأجهزة واجهات برمجة التطبيقات والسلوكيات هذه بشكل سليم، كما هو موضّح بالتفصيل في هذا القسم.
7.9.1. وضع الواقع الافتراضي
يتيح Android استخدام وضع الواقع الافتراضي، وهو ميزة تتعامل مع العرض المجسم للإشعارات وتوقِف مكونات واجهة المستخدم أحادية العين للنظام عندما يركز المستخدم على تطبيق الواقع الافتراضي.
7.9.2. وضع الواقع الافتراضي - الأداء العالي
إذا كانت عمليات تنفيذ الأجهزة تتيح وضع الواقع الافتراضي، يجب أن تستوفي الشروط التالية:
- [C-1-1] يجب أن يكون الجهاز مزوّدًا بنوى فعلية اثنتين على الأقل.
- [C-1-2] يجب الإفصاح عن ميزة
android.hardware.vr.high_performance
. - [C-1-3] يجب أن يكون الجهاز متوافقًا مع وضع الأداء المستدام.
- [C-1-4] يجب أن يكون متوافقًا مع OpenGL ES 3.2.
- [C-1-5] يجب أن يكون متوافقًا مع
android.hardware.vulkan.level
0. - يجب أن يكون متوافقًا مع الإصدار 1 من
android.hardware.vulkan.level
أو إصدار أحدث. - [C-1-6] يجب تنفيذ
EGL_KHR_mutable_render_buffer
،EGL_ANDROID_front_buffer_auto_refresh
،EGL_ANDROID_get_native_client_buffer
،EGL_KHR_fence_sync
،EGL_KHR_wait_sync
،EGL_IMG_context_priority
،EGL_EXT_protected_content
،EGL_EXT_image_gl_colorspace
، وعرض الإضافات في قائمة إضافات EGL المتاحة. - [C-1-8] يجب تنفيذ
GL_EXT_multisampled_render_to_texture2
،GL_OVR_multiview
،GL_OVR_multiview2
،GL_EXT_protected_textures
، وعرض الإضافات في قائمة إضافات GL المتاحة. - [C-SR-1] يُنصح بشدة بتنفيذ
GL_EXT_external_buffer
،GL_EXT_EGL_image_array
،GL_OVR_multiview_multisampled_render_to_texture
، وعرض الإضافات في قائمة إضافات GL المتاحة. - [C-SR-2] يُنصح بشدة بتوفير دعم لـ Vulkan 1.1.
- [C-SR-3] يُنصح بشدة بتنفيذ
VK_ANDROID_external_memory_android_hardware_buffer
،VK_GOOGLE_display_timing
،VK_KHR_shared_presentable_image
، وعرضها في قائمة إضافات Vulkan المتاحة. - [C-SR-4] يُنصح بشدة بعرض عائلة قوائم انتظار Vulkan واحدة على الأقل حيث يحتوي
flags
على كل منVK_QUEUE_GRAPHICS_BIT
وVK_QUEUE_COMPUTE_BIT
، ويكونqueueCount
2 على الأقل. - [C-1-7] يجب أن يكون بإمكان وحدة معالجة الرسومات والشاشة مزامنة الوصول إلى ملف التخزين المؤقت المشترَك في المقدّمة، وذلك لعرض محتوى الواقع الافتراضي بالتناوب بين العينَين بمعدّل 60 لقطة في الثانية باستخدام سياقَي عرض بدون أيّ تمزّق مرئي.
- [C-1-9] يجب توفير إمكانية استخدام
AHardwareBuffer
العلاماتAHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER
وAHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA
وAHARDWAREBUFFER_USAGE_PROTECTED_CONTENT
كما هو موضّح في حزمة NDK. - [C-1-10] يجب أن تتيح التطبيقات استخدام
AHardwareBuffer
مع أي تركيبة من علامات الاستخدامAHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT
،AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE
،AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT
لأشكال الإعلانات التالية على الأقل:AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM
،AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM
،AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM
،AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT
. - [C-SR-5] يُنصح بشدة بتفعيل تخصيص
AHardwareBuffer
s التي تحتوي على أكثر من طبقة واحدة والعلامات والتنسيقات المحدّدة في C-1-10. - [C-1-11] يجب أن يكون الجهاز متوافقًا مع ترميز H.264 بدرجة دقة 3840 × 2160 على الأقل بمعدّل 30 لقطة في الثانية، ومضغوطًا بمعدّل 40 ميغابت في الثانية في المتوسط (أي ما يعادل 4 مرات دقة 1920 × 1080 بمعدّل 10 ميغابت في الثانية أو مرّتين بدقة 1920 × 1080 بمعدّل 20 ميغابت في الثانية).
- [C-1-12] يجب أن يكون متوافقًا مع HEVC وVP9، ويجب أن يكون قادرًا على فك ترميز محتوى بدقة 1920 x 1080 على الأقل بمعدّل 30 لقطة في الثانية مضغوطًا بمتوسط 10 ميغابت في الثانية، ويجب أن يكون قادرًا على فك ترميز محتوى بدقة 3840 x 2160 بمعدّل 30 لقطة في الثانية أو 20 ميغابت في الثانية (أي ما يعادل 4 مرات بدقة 1920 x 1080 بمعدّل 30 لقطة في الثانية أو 5 ميغابت في الثانية).
- [C-1-13] يجب أن يكون الجهاز متوافقًا مع واجهة برمجة التطبيقات
HardwarePropertiesManager.getDeviceTemperatures
وأن يعرض قيمًا دقيقة لدرجة حرارة الجلد. - [C-1-14] يجب أن يكون الجهاز مزوّدًا بشاشة مدمجة، ويجب ألا تقل درجة دقتها عن 1920 × 1080.
- [C-SR-6] يُنصح بشدة بضبط درجة دقة الشاشة على 2560 x 1440 على الأقل.
- [C-1-15] يجب أن يتم تعديل الشاشة بمعدّل 60 هرتز على الأقل أثناء استخدام "وضع الواقع الافتراضي".
- [C-1-17] يجب أن تتيح الشاشة وضعًا بفترة بقاء منخفضة لا تزيد عن 5 مللي ثانية، وفترة البقاء هي المدة التي يُصدر فيها البكسل ضوءًا.
- [C-1-18] يجب أن يكون متوافقًا مع البلوتوث 4.2 وإضافة طول البيانات في البلوتوث منخفض الطاقة (LE) الفقرة 7.4.3.
- [C-1-19] يجب أن يتيح الجهاز بشكل صحيح تسجيل
نوع القناة المباشرة
لجميع أنواع أجهزة الاستشعار التلقائية التالية:
TYPE_ACCELEROMETER
TYPE_ACCELEROMETER_UNCALIBRATED
TYPE_GYROSCOPE
TYPE_GYROSCOPE_UNCALIBRATED
TYPE_MAGNETIC_FIELD
TYPE_MAGNETIC_FIELD_UNCALIBRATED
- [C-SR-7] يُنصح بشدة بتوفّر نوع القناة المباشرة
TYPE_HARDWARE_BUFFER
لجميع أنواع القنوات المباشرة المُدرَجة أعلاه. - [C-1-21] يجب استيفاء متطلبات
الجيروسكوب ومقياس التسارع ومقياس المغناطيسية المتعلقة
android.hardware.hifi_sensors
، على النحو المحدّد في الفقرة 7.3.9. - [C-SR-8] يُنصح بشدة بتوفّر ميزة
android.hardware.sensor.hifi_sensors
. - [C-1-22] يجب ألا يزيد وقت استجابة انتقال الصور من البداية إلى النهاية عن 28 ملي ثانية.
- [C-SR-9] يُنصح بشدة بضبط وقت استجابة الحركة إلى الفوتون من البداية إلى النهاية ليكون لا يزيد عن 20 مللي ثانية.
- [C-1-23] يجب أن تكون نسبة اللقطة الأولى، وهي نسبة بين brightness بكسل اللقطة الأولى بعد الانتقال من الأسود إلى الأبيض وbrightness بكسل الأبيض في الحالة الثابتة، لا تقل عن %85.
- [C-SR-10] يُنصح بشدة بأن تكون نسبة اللقطة الأولى 90% على الأقل.
- قد توفّر وحدة معالجة مركزية حصرية لتطبيق foreground
، وقد تتوافق مع واجهة برمجة التطبيقات
Process.getExclusiveCores
لعرض أعداد وحدات المعالجة المركزية الحصرية لتطبيق foreground الأكثر أهمية.
إذا كان التطبيق يتضمّن ميزة "النواة الحصرية"، يجب أن يستوفي النواة الشروط التالية:
- [C-2-1] يجب عدم السماح بتشغيل أي عمليات أخرى في مساحة المستخدم (باستثناء برامج تشغيل الأجهزة التي يستخدمها التطبيق)، ولكن يجوز السماح بتشغيل بعض عمليات ملف التمهيد حسب الضرورة.
7.10. أجهزة تعمل باللمس
راجِع القسم 2.2.1 لمعرفة المتطلبات الخاصة بالأجهزة.
7.11. فئة أداء الوسائط
يمكن الحصول على فئة أداء الوسائط لتنفيذ الجهاز من
android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS
. يتم تحديد متطلبات
فئة أداء الوسائط لكل إصدار من Android بدءًا من
R (الإصدار 30). تشير القيمة الخاصة 0 إلى أنّ الجهاز ليس من
فئة أداء الوسائط.
إذا كانت عمليات تنفيذ الأجهزة تعرض قيمة غير صفرية لسمة
android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS
، فإنّها:
[C-1-1] يجب أن تعرِض قيمة
android.os.Build.VERSION_CODES.R
على الأقل.[C-1-2] يجب أن يكون التنفيذ على جهاز محمول باليد.
[C-1-3] يجب استيفاء جميع متطلبات "فئة أداء الوسائط" الموضّحة في الفقرة 2.2.7.
اطّلِع على الفقرة 2.2.7 للاطّلاع على المتطلّبات المتعلّقة بالأجهزة.
8. الأداء والقوة
إنّ بعض الحد الأدنى من معايير الأداء واستهلاك الطاقة ضرورية لتجربة المستخدم، وتؤثّر في الافتراضات الأساسية التي يتّبعها المطوّرون عند تطوير التطبيقات.
8.1. اتساق تجربة المستخدم
يمكن توفير واجهة مستخدم سلسة للمستخدِم النهائي إذا كانت هناك متطلبات أساسية معيّنة لضمان معدّل عرض ثابت للإطارات وأوقات استجابة مناسبة للتطبيقات والألعاب. قد يكون لتنفيذ التطبيقات على الأجهزة، استنادًا إلى نوع الجهاز، متطلبات قابلة للقياس لوقت استجابة واجهة المستخدم ووقت تبديل المهام كما هو موضّح في القسم 2.
8.2. أداء الوصول إلى الإدخال/الإخراج من الملفات
من خلال توفير مرجع قياسي شائع لأداء الوصول إلى الملفات بشكلٍ متسق على
مساحة تخزين البيانات الخاصة بالتطبيق (قسم /data
)، يمكن لمطوّري التطبيقات
وضع توقّعات مناسبة تساعدهم في تصميم برامجهم. قد تفرض عمليات تنفيذ التطبيقات على الأجهزة، استنادًا إلى نوع الجهاز، متطلبات معيّنة описанة في القسم 2 لعمليات القراءة
والكتابة التالية:
- أداء الكتابة التسلسلية: يتم قياسها من خلال كتابة ملف بحجم 256 ميغابايت باستخدام ملف تدوين كتابة بحجم 10 ميغابايت.
- أداء الكتابة العشوائية يتم قياسها من خلال كتابة ملف بحجم 256 ميغابايت باستخدام ذاكرة تخزين مؤقت للكتابة بسعة 4 كيلوبايت.
- أداء القراءة التسلسلية: تم قياس السرعة من خلال قراءة ملف بحجم 256 ميغابايت باستخدام ملف تدوين كتابة بحجم 10 ميغابايت.
- أداء القراءة العشوائية يتم قياسه من خلال قراءة ملف بحجم 256 ميغابايت باستخدام ذاكرة تخزين مؤقت للكتابة بسعة 4 كيلوبايت.
8.3. أوضاع توفير الطاقة
إذا كانت عمليات تنفيذ التطبيق على الجهاز تتضمّن ميزات لتحسين إدارة الطاقة في الجهاز التي يتم تضمينها في AOSP (مثل "مجموعة التطبيقات في وضع الاستعداد" و"وضع السكون") أو توسيع نطاق الميزات لتطبيق قيود أقوى من مجموعة التطبيقات في وضع الاستعداد المحظور، يجب استيفاء الشروط التالية:
- [C-1-1] يجب عدم الانحراف عن تنفيذ AOSP لبدء تطبيقات وضع "الاستعداد" وDeviceConfig ووضع "الاستراحة الذكية" وخوارزمية الاحتفاظ بالطاقة واستخدام إعدادات النظام الشاملة.
- [C-1-2] يجب عدم الانحراف عن تنفيذ AOSP لاستخدام الإعدادات العموية أو DeviceConfig لإدارة الحدّ من عدد المهام وعمليات التنبيه و الشبكة للتطبيقات في كل مجموعة للوضع "الاستعداد للتطبيقات".
- [C-1-3] يجب عدم الانحراف عن طريقة تنفيذ AOSP لعدد مجموعات وضع "التطبيقات في وضع الاستعداد" المستخدَمة في وضع "التطبيقات في وضع الاستعداد".
- [C-1-4] يجب تنفيذ مجموعات تطبيقات وضع الاستعداد وميزة "الاستراحة" كما هو описан في إدارة الطاقة.
- [C-1-5] يجب عرض القيمة
true
لـPowerManager.isPowerSaveMode()
عندما يكون الجهاز في وضع توفير الطاقة. - [C-1-6] يجب أن يقدّم التطبيق للمستخدم إمكانية عرض كل التطبيقات التي تم استثناؤها من وضعَي "الاستراحة" و"الاستعداد" للتوفير في استهلاك الطاقة أو أي تحسينات على البطارية، ويجب أن ينفذ التطبيق الإجراء ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS لطلب السماح للتطبيق بتجاهل تحسينات البطارية.
- [C-SR-1] يُنصح بشدة بتوفير إمكانات للمستخدم لتفعيل ميزة "توفير البطارية" وإيقافها.
- [C-SR-2] يُنصح بشدة بتوفير ميزة للمستخدم لعرض كل التطبيقات التي تم استثناؤها من وضعَي "الاستراحة" و"الاستراحة الذكية" لتوفير الطاقة.
إذا كانت عمليات تنفيذ الأجهزة توفّر ميزات إدارة الطاقة المضمّنة في AOSP وكانت هذه الميزات تفرض قيودًا أكثر صرامة من مجموعة التطبيقات التي نادرًا ما تكون في وضع الاستعداد، يُرجى الرجوع إلى الفقرة 3.5.1.
بالإضافة إلى أوضاع توفير الطاقة، يجوز لعمليات تنفيذ أجهزة Android تنفيذ أي من حالات الطاقة الأربعة للاستعداد أو جميعها على النحو المحدّد من خلال واجهة الضبط والطاقة المتقدّمة (ACPI).
إذا كانت عمليات تنفيذ الأجهزة تطبّق حالات الطاقة S4 على النحو المحدّد في ACPI، فإنّها:
- [C-1-1] يجب عدم الدخول في هذه الحالة إلا بعد أن يتّخذ المستخدم إجراءً صريحًا لوضع الجهاز في حالة غير نشطة (مثل إغلاق غطاء يشكّل جزءًا من الجهاز أو إطفاء مركبة أو تلفزيون) وقبل أن يعيد المستخدم تفعيل الجهاز (مثل فتح الغطاء أو إعادة تشغيل المركبة أو التلفزيون).
إذا كانت عمليات تنفيذ الأجهزة تطبّق حالات الطاقة S3 على النحو المحدّد في ACPI، فإنّها:
[C-2-1] يجب استيفاء C-1-1 أعلاه، أو يجب الدخول إلى حالة S3 فقط عندما لا تحتاج التطبيقات التابعة لجهات خارجية إلى موارد النظام (مثل الشاشة ووحدة المعالجة المركزية).
في المقابل، يجب الخروج من حالة S3 عندما تحتاج التطبيقات التابعة لجهات خارجية إلى موارد النظام، كما هو موضّح في حزمة تطوير البرامج (SDK) هذه.
على سبيل المثال، عندما تطلب التطبيقات التابعة لجهات خارجية إبقاء الشاشة مشغّلة من خلال
FLAG_KEEP_SCREEN_ON
أو إبقاء وحدة المعالجة المركزية (CPU) تعمل من خلالPARTIAL_WAKE_LOCK
، يجب ألّا يدخل الجهاز في حالة S3 ما لم يتّخذ المستخدم إجراءً صريحًا لوضع الجهاز في حالة غير نشط، كما هو موضّح في C-1-1. في المقابل، في الوقت الذي يتم فيه بدء مهمة تنفذها التطبيقات التابعة لجهات خارجية من خلال JobScheduler أو يتم فيه إرسال Firebase Cloud Messaging إلى التطبيقات التابعة لجهات خارجية، يجب أن يخرج الجهاز من حالة S3 ما لم يكن المستخدم قد وضع الجهاز في حالة غير نشطة. هذه ليست مثالاً كاملاً، وينفِّذ AOSP إشارات استيقاظ مكثفة تؤدي إلى الاستيقاظ من هذه الحالة.
8.4. احتساب استهلاك الطاقة
إنّ احتساب استهلاك الطاقة وإعداد تقارير أكثر دقة يقدّم لمطوّر التطبيقات كلّ من الحوافز والأدوات لتحسين نمط استخدام التطبيقات للطاقة.
عمليات التنفيذ على الأجهزة:
- [C-SR-1] يُنصح بشدة بتقديم ملفات تعريف الطاقة لكل مكوّن تحدد قيمة الاستهلاك الحالي لكل مكوّن من مكونات الأجهزة ومعدل استنزاف البطارية التقريبي الذي يسببه المكوّنات بمرور الوقت كما هو موضّح في الموقع الإلكتروني لمشروع Android Open Source Project.
- [C-SR-2] يُنصح بشدة بالإبلاغ عن جميع قيم استهلاك الطاقة بالمللي أمبير ساعة (mAh).
- [C-SR-3] يُنصح بشدة بالإبلاغ عن استهلاك طاقة وحدة المعالجة المركزية لكل معرّف مستخدم لكل عملية.
يستوفي "مشروع مفتوح المصدر لنظام Android" المتطلّبات من خلال تنفيذ
uid_cputime
وحدة النواة. - [C-SR-4] يُنصح بشدة بإتاحة استخدام الطاقة هذا من خلال استخدام الأمر
adb shell dumpsys batterystats
shell من قِبل مطوّر التطبيق. - يجب أن يُنسَب إلى مكوّن الجهاز نفسه في حال تعذّر تحديد تطبيق معيّن كمصدر استهلاك الطاقة في مكوّن الجهاز.
8.5. الأداء المتسق
يمكن أن يتفاوت الأداء بشكل كبير في التطبيقات العالية الأداء التي تعمل لفترة طويلة، إما بسبب التطبيقات الأخرى التي تعمل في الخلفية أو بسبب الحد من سرعة وحدة المعالجة المركزية بسبب الحدود القصوى لدرجة الحرارة. يتضمّن نظام التشغيل Android واجهات برمجة تطبيقات لكي يتمكّن التطبيق الأهم في المقدّمة من طلب تحسين تخصيص الموارد من النظام لمواجهة هذه التقلبات عندما يكون الجهاز مزوّدًا بالإمكانية اللازمة.
عمليات التنفيذ على الأجهزة:
[C-0-1] يجب الإبلاغ بدقة عن توفّر "وضع الأداء المستدام" من خلال استخدام
PowerManager.isSustainedPerformanceModeSupported()
طريقة واجهة برمجة التطبيقات.يجب أن يكون متوافقًا مع "وضع الأداء المستدام".
إذا أبلغت عمليات تنفيذ الأجهزة عن توفّر "وضع الأداء المستدام"، يعني ذلك أنّها:
- [C-1-1] يجب أن يقدّم التطبيق الأهم في المقدّمة مستوى ثبات في الأداء لمدة 30 دقيقة على الأقل عندما يطلب ذلك.
- [C-1-2] يجب الالتزام بواجهة برمجة التطبيقات
Window.setSustainedPerformanceMode()
API وواجهات برمجة التطبيقات الأخرى ذات الصلة.
إذا كانت عمليات تنفيذ الأجهزة تتضمّن نواتين أو أكثر من وحدات المعالجة المركزية، يتم تنفيذ ما يلي:
- يجب أن يوفّر معالجًا مركزيًا حصريًا واحدًا على الأقل يمكن حجز استخدامه من قِبل التطبيق الأهم في foreground.
إذا كانت عمليات تنفيذ الأجهزة تتيح حجز نواة حصرية واحدة للتطبيق الأهم في المقدّمة، فإنّها:
- [C-2-1] يجب الإبلاغ من خلال
Process.getExclusiveCores()
واجهة برمجة التطبيقات عن أرقام تعريف النوى الحصرية التي يمكن حجزها من خلال التطبيق الأهم الذي يعمل في المقدّمة. - [C-2-2] يجب عدم السماح بأي عمليات في مساحة المستخدم باستثناء برامج تشغيل الأجهزة التي يستخدمها التطبيق لتشغيلها على النوى الحصرية، ولكن يجوز السماح بتشغيل بعض عمليات نواة النظام حسب الضرورة.
إذا كانت عمليات تنفيذ الأجهزة لا تتيح استخدام نواة حصرية، يتم تنفيذ ما يلي:
- [C-3-1] يجب أن تعرض قائمة فارغة من خلال استخدام واجهة برمجة التطبيقات
Process.getExclusiveCores()
.
9. توافق نموذج الأمان
عمليات التنفيذ على الأجهزة:
[C-0-1] يجب تنفيذ نموذج أمان متوافق مع نموذج أمان نظام Android الأساسي كما هو محدّد في مستند مرجعي حول الأمان والأذونات في واجهات برمجة التطبيقات الواردة في مستندات مطوّري تطبيقات Android.
[C-0-2] يجب أن تتيح تثبيت التطبيقات الموقَّعة ذاتيًا بدون طلب أي أذونات أو شهادات إضافية من أي جهات خارجية أو سلطات.
إذا كانت عمليات تنفيذ الأجهزة تذكر ميزة android.hardware.security.model.compatible
، يعني ذلك ما يلي:
- [C-1-1] يجب أن تستوفي المتطلبات الواردة في الأقسام الفرعية التالية.
9.1. الأذونات
عمليات التنفيذ على الأجهزة:
[C-0-1] يجب أن يكون متوافقًا مع نموذج أذونات Android ونموذج أدوار Android كما هو محدّد في مستندات مطوّري تطبيقات Android. وعلى وجه التحديد، يجب أن تفرض هذه التطبيقات كل إذن ودور محدّدَين على النحو الموضّح في مستندات IDE، ولا يجوز حذف أي أذونات أو أدوار أو تعديلها أو تجاهلها.
يجوز إضافة أذونات إضافية، شرط ألا تكون سلاسل أرقام تعريف الأذونات الجديدة في مساحة الاسم
android.\*
.[C-0-2] يجب عدم منح الأذونات التي تحمل
protectionLevel
منPROTECTION_FLAG_PRIVILEGED
إلا للتطبيقات المثبَّتة مسبقًا في المسارات المميَّزة لملف system وداخل المجموعة الفرعية من الأذونات المدرَجة في القائمة المسموح بها لكل تطبيق. يستوفي تطبيق AOSP هذا الشرط من خلال قراءة الأذونات المدرَجة في القائمة المسموح بها لكل تطبيق من الملفات في مسار etc/permissions/
واستخدام مسار system/priv-app
كمسار مميَّز.
إنّ الأذونات التي يكون مستوى حمايتها خطيرًا هي أذونات وقت التشغيل.
تطلب التطبيقات التي تحتوي على targetSdkVersion
> 22 هذه الأذونات أثناء التشغيل.
عمليات التنفيذ على الأجهزة:
- [C-0-3] يجب أن يعرض التطبيق واجهة مخصّصة للمستخدم ليقرر ما إذا كان سيمنح أذونات التشغيل المطلوبة، كما يجب أن يقدّم واجهة للمستخدم لإدارة أذونات التشغيل.
- [C-0-4] يجب أن يكون هناك تنفيذ واحد فقط لكلتا جهتي واجهة العميل.
- [C-0-5] يجب عدم منح أي أذونات تشغيل للتطبيقات preinstalled
إلا في الحالات التالية:
- يمكن الحصول على موافقة المستخدم قبل أن يستخدم التطبيق هذه البيانات.
- ترتبط أذونات التشغيل بنمط نية يتم ضبط التطبيق المثبَّت مسبقًا كمعالج تلقائي له.
- [C-0-6] يجب منح الإذن
android.permission.RECOVER_KEYSTORE
فقط لتطبيقات النظام التي تسجِّل وكيل استرداد آمنًا بشكلٍ صحيح. يتم تعريف وكيل الاسترداد الآمن على أنّه وكيل برامج على الجهاز تتم مزامنته مع مساحة تخزين عن بُعد خارج الجهاز ومزوّدة بأجهزة آمنة توفّر حماية مماثلة أو أقوى مما هو описан في خدمة Google Cloud Key Vault لمنع هجمات القوة الغاشمة على عامل المعلومات في شاشة القفل.
عمليات التنفيذ على الأجهزة:
[C-0-7] يجب الالتزام بخصائص إذن الوصول إلى الموقع الجغرافي في Android عندما يطلب التطبيق بيانات الموقع الجغرافي أو النشاط البدني من خلال واجهة برمجة التطبيقات العادية لنظام التشغيل Android أو آلية خاصة. وتشمل هذه البيانات على سبيل المثال لا الحصر ما يلي:
- الموقع الجغرافي للجهاز (مثل خط العرض وخط الطول) كما هو موضّح في الفقرة 9.8.8
- المعلومات التي يمكن استخدامها لتحديد الموقع الجغرافي للجهاز أو تقديره (مثل معرّف شبكة WLAN أو معرّف مجموعة الخدمات الأساسية أو معرّف الخلية أو الموقع الجغرافي للشبكة التي يكون الجهاز متصلاً بها)
- النشاط البدني للمستخدم أو تصنيف النشاط البدني
وعلى وجه التحديد، تؤدي عمليات تنفيذ الأجهزة إلى ما يلي:
- [C-0-8] يجب الحصول على موافقة المستخدم للسماح للتطبيق بالوصول إلى data الموقع الجغرافي أو النشاط البدني.
- [C-0-9] يجب منح إذن التشغيل للتطبيق الذي يملك
إذنًا كافيًا كما هو موضّح في حزمة SDK فقط. على سبيل المثال، تتطلّب TelephonyManager#getServiceState
android.permission.ACCESS_FINE_LOCATION
.
الاستثناءات الوحيدة لميزات إذن الموقع الجغرافي على Android المذكورة أعلاه هي التطبيقات التي لا تصل إلى الموقع الجغرافي لاستخراج موقع المستخدم الجغرافي أو تحديده، وعلى وجه التحديد:
- عندما تحصل التطبيقات على إذن
RADIO_SCAN_WITHOUT_LOCATION
- لأغراض ضبط الجهاز وإعداده، حيث تمتلك تطبيقات النظام إذن
NETWORK_SETTINGS
أوNETWORK_SETUP_WIZARD
يمكن وضع علامة على الأذونات على أنّها محظورة، ما يؤدي إلى تغيير سلوكها.
[C-0-10] يجب عدم منح الأذونات التي تم وضع العلامة
hardRestricted
عليها لأي تطبيق ما لم يكن:- ملف APK للتطبيق في قسم النظام
- يمنح المستخدم دورًا مرتبطًا بأذونات
hardRestricted
لتطبيق معيّن. - يمنح برنامج التثبيت إذن
hardRestricted
لتطبيق معيّن. - تم منح أحد التطبيقات إذن
hardRestricted
على إصدار سابق من Android.
[C-0-11] يجب أن تحصل التطبيقات التي تمتلك إذن
softRestricted
على إذن بالوصول محدود فقط، ويجب ألا تحصل على إذن بالوصول الكامل إلى أن يتم إدراجها في القائمة المسموح بها كما هو موضّح في مستندات حزمة تطوير البرامج (SDK)، حيث يتم تحديد إذن الوصول الكامل والمحدود لكل إذنsoftRestricted
(على سبيل المثال،READ_EXTERNAL_STO