أندرويد 14
8 أبريل 2024
2. أنواع الأجهزة
انظر المراجعة
بدء متطلبات جديدة
إذا أعلنت تطبيقات الأجهزة المحمولة عن
FEATURE_BLUETOOTH_LE
، فإنها:- [ 7.4 .3/H-1-3] يجب قياس إزاحة Rx وتعويضها للتأكد من أن متوسط BLE RSSI هو -50dBm +/-15 dB على مسافة 1 متر من جهاز مرجعي يرسل عند
ADVERTISE_TX_POWER_HIGH
. - [ 7.4 .3/H-1-4] يجب قياس إزاحة Tx وتعويضها للتأكد من أن متوسط BLE RSSI هو -50dBm +/- 15 dB عند المسح من جهاز مرجعي متوضع على مسافة 1 متر والإرسال عند
ADVERTISE_TX_POWER_HIGH
.
- [ 7.4 .3/H-1-3] يجب قياس إزاحة Rx وتعويضها للتأكد من أن متوسط BLE RSSI هو -50dBm +/-15 dB على مسافة 1 متر من جهاز مرجعي يرسل عند
انظر المراجعة
إذا كانت تطبيقات الأجهزة المحمولة تدعم System API
HotwordDetectionService
أو آلية أخرى لاكتشاف الكلمات المهمة دون إشارة الوصول إلى الميكروفون، فإنها:- [9.8/H-1-6] يجب عدم السماح بنقل أكثر من 100 بايت من البيانات خارج خدمة الكشف عن الكلمة المهمة في كل نتيجة كلمة فعالة ناجحة باستثناء البيانات الصوتية التي تم تمريرها عبر HotwordAudioStream .
انظر المراجعة
قم بتغيير [9.8/H-1-13] إلى:
- [9.8/H-SR-3] يوصى بشدة بإعادة تشغيل عملية استضافة خدمة اكتشاف الكلمات المهمة مرة واحدة على الأقل كل ساعة أو كل 30 حدثًا لتشغيل الأجهزة، أيهما يأتي أولاً.
انظر المراجعة
تمت إزالة المتطلبات [9.8.2/H-4-3]، [9.8.2/H-4-4]، [9.8.2/H-5-3].
انظر المراجعة
إذا أعادت تطبيقات الأجهزة المحمولة
android.os.Build.VERSION_CODES.U
لـandroid.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
، فإنها:- [ 7.5 /H-1-3] يجب أن يدعم خاصية
android.info.supportedHardwareLevel
باعتبارهاFULL
أو أفضل للكاميرا الأساسية الخلفيةLIMITED
أو أفضل للكاميرا الأساسية الأمامية.
- [ 7.5 /H-1-3] يجب أن يدعم خاصية
انظر المراجعة
إذا لم تكن تطبيقات أجهزة التلفزيون تحتوي على شاشة عرض مدمجة، ولكنها بدلاً من ذلك تدعم شاشة خارجية متصلة عبر HDMI، فإنها:
- [ 5.8 /T-0-1] يجب ضبط وضع إخراج HDMI على أعلى دقة لتنسيق البكسل المختار الذي يعمل مع معدل تحديث 50 هرتز أو 60 هرتز للشاشة الخارجية، اعتمادًا على معدل تحديث الفيديو للمنطقة التي يباع فيها الجهاز يجب
ضبط وضع إخراج HDMI لتحديد الحد الأقصى للدقة التي يمكن دعمها بمعدل تحديث 50 هرتز أو 60 هرتز.
- [ 5.8 /T-0-1] يجب ضبط وضع إخراج HDMI على أعلى دقة لتنسيق البكسل المختار الذي يعمل مع معدل تحديث 50 هرتز أو 60 هرتز للشاشة الخارجية، اعتمادًا على معدل تحديث الفيديو للمنطقة التي يباع فيها الجهاز يجب
3. البرمجيات
انظر المراجعة
- تمت إزالة المتطلبات [C-1-9]
5. توافق الوسائط المتعددة
انظر المراجعة
إذا أعلنت تطبيقات الجهاز دعم وحدة فك ترميز Dolby Vision من خلال
HDR_TYPE_DOLBY_VISION
، فإنها:- [C-1-3] يجب تعيين معرف المسار للطبقة (الطبقات) الأساسية المتوافقة مع الإصدارات السابقة (إن وجدت) ليكون هو نفس معرف المسار لطبقة Dolby Vision المدمجة.
7. توافق الأجهزة
انظر المراجعة
إذا كانت تطبيقات الأجهزة تدعم الشاشات القادرة على تكوين حجم
UI_MODE_TYPE_NORMAL
وتستخدم شاشة (شاشات) فعلية ذات زوايا مستديرة لعرض هذه الشاشات، فإنها:- [C-1-1] يجب التأكد من استيفاء واحد على الأقل من المتطلبات التالية لكل شاشة من هذا القبيل:
- عندما يتم تثبيت مربع
15× 18 ×1518 بكسل في كل ركن من أركان الشاشة المنطقية، يكون بكسل واحد على الأقل من كل مربع مرئيًا على الشاشة.
- عندما يتم تثبيت مربع
- [C-1-1] يجب التأكد من استيفاء واحد على الأقل من المتطلبات التالية لكل شاشة من هذا القبيل:
انظر المراجعة
إعادة المتطلبات التالية:
إذا أعلنت تطبيقات الجهاز عن
FEATURE_BLUETOOTH_LE
، فإنها:[C-SR-2] يوصى بشدة بقياس إزاحة Rx وتعويضها لضمان أن متوسط BLE RSSI هو -60 ديسيبل ميلي واط +/- 10 ديسيبل على مسافة 1 متر من جهاز مرجعي يرسل عند
ADVERTISE_TX_POWER_HIGH
، حيث يتم توجيه الأجهزة بحيث تكون على "مستويات متوازية" بحيث تواجه الشاشات نفس الاتجاه.[C-SR-3] يوصى بشدة بقياس إزاحة Tx وتعويضها لضمان أن متوسط BLE RSSI هو -60 ديسيبل ميلي واط +/- 10 ديسيبل عند المسح من جهاز مرجعي متوضع على مسافة 1 متر والإرسال على
ADVERTISE_TX_POWER_HIGH
، حيث يتم توجيه الأجهزة بحيث تكون على "مستويات متوازية" بحيث تواجه الشاشات نفس الاتجاه.
انظر المراجعة
تم نقل المتطلبات [C-10-3] و[C-10-4] إلى 2.2.1. المعدات .
- [C-10-3] يجب قياس إزاحة Rx وتعويضها للتأكد من أن متوسط BLE RSSI هو -55dBm +/-10 dB على مسافة 1 متر من جهاز مرجعي يرسل عند
ADVERTISE_TX_POWER_HIGH
. - [C-10-4] يجب قياس إزاحة Tx وتعويضها للتأكد من أن متوسط BLE RSSI هو -55dBm +/-10 dB عند المسح من جهاز مرجعي متوضع على مسافة 1 متر والإرسال عند
ADVERTISE_TX_POWER_HIGH
.
20 نوفمبر 2023
2. أنواع الأجهزة
انظر المراجعة
إذا أعلنت تطبيقات الأجهزة المحمولة دعمها لأي واجهة برمجة تطبيقات 64 بت (مع أو بدون أي واجهة برمجة تطبيقات 32 بت):
انظر المراجعة
- [ 7.5 /H-1-13] يجب أن يدعم إمكانية
LOGICAL_MULTI_CAMERA
للكاميرا الخلفية الأساسية إذا كان هناك أكثر من كاميرا خلفية RGB واحدة.
- [ 7.5 /H-1-13] يجب أن يدعم إمكانية
انظر المراجعة
[ 5.8 /T-0-1] يجب ضبط وضع إخراج HDMI على أعلى دقة لتنسيق SDR أو HDR المختار الذي يعمل بمعدل تحديث 50 هرتز أو 60 هرتز للشاشة الخارجية.
يجب ضبط وضع إخراج HDMI لتحديد الحد الأقصى للدقة التي يمكن دعمها بمعدل تحديث 50 هرتز أو 60 هرتز.
انظر المراجعة
- [9/W-0-1] يجب الإعلان عن
android.hardware.security.model.compatible feature
.
- [9/W-0-1] يجب الإعلان عن
6. توافق أدوات المطورين وخياراتهم
انظر المراجعة
- [C-0-12] يجب كتابة
LMK_KILL_OCCURRED_FIELD_NUMBER
Atom إلى
انظر المراجعة
- [C-0-13] يجب تنفيذ أمر shell
dumpsys gpu --gpuwork
لعرضه
- [C-0-12] يجب كتابة
9. توافق نموذج الأمان
انظر المراجعة
إذا كانت تطبيقات الأجهزة تستخدم نواة Linux قادرة على دعم SELinux، فإنها:
انظر المراجعة
إذا كانت تطبيقات الأجهزة تستخدم نواة أخرى غير Linux أو Linux بدون SELinux، فإنها:
4 أكتوبر 2023
2. أنواع الأجهزة
انظر المراجعة
يتم تصنيف تطبيقات أجهزة Android على أنها أجهزة محمولة إذا كانت تستوفي جميع المعايير التالية:
- يتراوح حجم الشاشة القطرية الفعلية بين 4 بوصات
و3.3 بوصات (أو 2.5 بوصة لتطبيقات الأجهزة التي يتم شحنها على مستوى API 29 أو أقدم)إلى 8 بوصات.
بدء متطلبات جديدة
- لديك واجهة إدخال تعمل باللمس.
- يتراوح حجم الشاشة القطرية الفعلية بين 4 بوصات
انظر المراجعة
تطبيقات الأجهزة المحمولة:
- [ 7.1 .1.1/H-0-1] يجب أن يكون لديك
شاشة واحدة على الأقل متوافقة مع Android وتلبي جميع المتطلبات الموضحة في هذا المستند.شاشة يبلغ قياسها 2.2 بوصة على الأقل على الحافة القصيرة و3.4 بوصة على الحافة الطويلة.
إذا كانت تطبيقات الأجهزة المحمولة تدعم تدوير شاشة البرنامج، فإنها:
- [ 7.1 .1.1/H-1-1]* يجب جعل الشاشة المنطقية المتوفرة لتطبيقات الطرف الثالث لا تقل عن 2 بوصة على الحافة (الحافات) القصيرة و2.7 بوصة على الحافة (الحافات) الطويلة. قد يتم إعفاء الأجهزة التي يتم شحنها على مستوى Android API 29 أو الإصدارات الأقدم من هذا المطلب.
إذا كانت تطبيقات الأجهزة المحمولة لا تدعم تدوير شاشة البرنامج، فإنها:
- [ 7.1 .1.1/H-2-1]* يجب أن تكون الشاشة المنطقية المتاحة لتطبيقات الطرف الثالث 2.7 بوصة على الأقل على الحافة (الحواف) القصيرة. قد يتم إعفاء الأجهزة التي يتم شحنها على مستوى Android API 29 أو الإصدارات الأقدم من هذا المطلب.
بدء متطلبات جديدة
[ 7.1 .1.1/H-0-3]* يجب تعيين كل شاشة
UI_MODE_NORMAL
متاحة لتطبيقات الطرف الثالث على مساحة عرض فعلية خالية من العوائق تبلغ على الأقل 2.2 بوصة على الحافة القصيرة و3.4 بوصة على الحافة الطويلة.[ 7.1 .1.3/H-0-1]* يجب تعيين قيمة
DENSITY_DEVICE_STABLE
لتكون 92% أو أكبر من الكثافة المادية الفعلية للشاشة المقابلة.
إذا أعلنت تطبيقات الأجهزة المحمولة عن
android.hardware.audio.output
وandroid.hardware.microphone
، فإنها:[ 5.6 /H-1-1] يجب أن يكون متوسط زمن الوصول المستمر ذهابًا وإيابًا 300 مللي ثانية أو أقل خلال 5 قياسات، مع متوسط انحراف مطلق أقل من 30 مللي ثانية ، عبر مسارات البيانات التالية: "مكبر الصوت إلى الميكروفون"، 3.5 مم محول الاسترجاع (إذا كان مدعومًا)، استرجاع USB (إذا كان مدعومًا).
[ 5.6 /H-1-2] يجب أن يكون متوسط زمن الوصول للنقر إلى نغمة يبلغ 300 مللي ثانية أو أقل عبر 5 قياسات على الأقل عبر مسار بيانات مكبر الصوت إلى الميكروفون.
إذا كانت تطبيقات الأجهزة المحمولة تتضمن مشغلًا لمسيًا واحدًا على الأقل، فإنها:
- [ 7.10 /ح]* يجب عدم استخدام المحرك اللمسي للكتلة الدوارة اللامركزية (ERM) (الهزاز).
- [ 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، رفض وGESTURE_START وGESTURE_END).
- [ 7.10 /H] * يجب تنفيذ جميع الثوابت العامة للحصول على لمسيات واضحة في android.os.VibrationEffect وهي (EFFECT_TICK وEFFECT_CLICK وEFFECT_HEAVY_CLICK وEFFECT_DOUBLE_CLICK) وجميع الثوابت
PRIMITIVE_*
العامة الممكنة للملمسيات الغنية في android.os.VibrationEffect.Composition وهي ( انقر، ضع علامة، LOW_TICK، QUICK_FALL، QUICK_RISE، SLOW_RISE، SPIN، THUD). قد تكون بعض هذه البدائيات، مثل LOW_TICK وSPIN، ممكنة فقط إذا كان الهزاز قادرًا على دعم الترددات المنخفضة نسبيًا. - [7.10/H]* يجب أن يتبع الإرشادات الخاصة بتعيين الثوابت العامة في android.view.HapticFeedbackConstants إلى ثوابت android.os.VibrationEffect الموصى بها، مع علاقات السعة المقابلة.
- [ 7.10 /H]* يجب أن يتبع تقييم الجودة لواجهات برمجة التطبيقات createOneShot() و createWaveform() .
- [ 7.10 /H] * يجب التحقق من أن نتيجة واجهة برمجة التطبيقات android.os.Vibrator.hasAmplitudeControl() العامة تعكس بشكل صحيح قدرات الهزاز الخاصة بهم.
- [ 7.10 /ح]* يجب وضع موضع المشغل بالقرب من الموقع الذي يتم فيه عادةً حمل الجهاز أو لمسه باليدين.
إذا كانت تطبيقات الأجهزة المحمولة تشتمل على مشغل طنين خطي واحد على الأقل للأغراض العامة 7.10 ، فإنها:
- [ 7.10 /H] يجب وضع موضع المشغل بالقرب من الموقع الذي يتم فيه عادةً حمل الجهاز أو لمسه باليدين.
- [ 7.10 /H] يجب أن يحرك المشغل اللمسي في المحور السيني (يسار - يمين) للاتجاه
الرأسيالطبيعي للجهاز .
إذا كانت تطبيقات الأجهزة المحمولة تحتوي على مشغل لمسي للأغراض العامة وهو مشغل الرنين الخطي للمحور X (LRA)، فإنها:
- [ 7.10 /H] يجب أن يكون تردد الرنين للمحور X أقل من 200 هرتز.
- [ 7.1 .1.1/H-0-1] يجب أن يكون لديك
انظر المراجعة
يجب أن تدعم تطبيقات الأجهزة المحمولة تنسيقات ترميز الفيديو التالية وإتاحتها لتطبيقات الجهات الخارجية:
- [ 5.2 /ح-0-3] AV1
يجب أن تدعم تطبيقات الأجهزة المحمولة تنسيقات فك تشفير الفيديو التالية وإتاحتها لتطبيقات الجهات الخارجية:
- [ 5.3 /ح-0-6] AV1
انظر المراجعة
إذا كانت تطبيقات الجهاز بما في ذلك مفتاح التنقل لوظيفة الأحداث الأخيرة كما هو مفصل في القسم 7.2.3 تغير الواجهة، فإنها:
- [ 3.8 .3/H-1-1] يجب تنفيذ سلوك تثبيت الشاشة وتزويد المستخدم بقائمة إعدادات لتبديل الميزة.
إذا كانت تطبيقات الأجهزة المحمولة تتضمن دعمًا لـ
ControlsProviderService
وControl
APIs وتسمح لتطبيقات الجهات الخارجية بنشر عناصر التحكم في الجهاز ، فإنها:- [ 3.8 .16/H-1-6] يجب أن توفر تطبيقات الأجهزة القدرة على تحمل تكاليف المستخدم بدقة كما يلي:
- إذا قام الجهاز بتعيين
config_supportsMultiWindow=true
وأعلن التطبيق عن بيانات التعريفMETA_DATA_PANEL_ACTIVITY
في إعلانControlsProviderService
، بما في ذلك ComponentName للنشاط الصالح (كما هو محدد بواسطة واجهة برمجة التطبيقات)، فيجب على التطبيق تضمين النشاط المذكور في قدرة المستخدم هذه. - إذا لم يعلن التطبيق عن البيانات التعريفية
META_DATA_PANEL_ACTIVITY
، فيجب عليه عرض الحقول المحددة كما توفرها واجهة برمجة تطبيقاتControlsProviderService
بالإضافة إلى أي حقول محددة توفرها واجهات برمجة تطبيقات التحكم .
- إذا قام الجهاز بتعيين
- [ 3.8 .16/H-1-7] إذا أعلن التطبيق عن البيانات التعريفية
META_DATA_PANEL_ACTIVITY
، فيجب عليه تمرير قيمة الإعداد المحدد في [3.8.16/H-1-5] باستخدامEXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS
عند تشغيل النشاط المضمن.
إذا كانت تطبيقات الجهاز تسمح للمستخدمين بإجراء مكالمات من أي نوع، فإنها
- [ 7.4.1.2 /H-0-1] يجب أن يعلن عن علامة الميزة
android.software.telecom
. - [ 7.4.1.2 /H-0-2] يجب تنفيذ إطار عمل الاتصالات .
انظر المراجعة
تطبيقات الأجهزة المحمولة:
- [ 8.5 /H-0-1] يجب توفير إمكانية تحمل المستخدم
في قائمة الإعداداتلرؤية جميع التطبيقات مع الخدمات الأمامية النشطة أو المهام التي بدأها المستخدم، بما في ذلك مدة كل من هذه الخدمات منذ بدايتها كما هو موضح في مستند SDK .والقدرة على إيقاف تطبيق يقوم بتشغيل خدمة مقدمة أو مهمة يبدأها المستخدم.مع إمكانية إيقاف تطبيق يقوم بتشغيل خدمة مقدمة وعرض جميع التطبيقات التي لديها خدمات مقدمة نشطة ومدة كل من هذه الخدمات منذ بدايتها كما هو موضح في مستند SDK .- قد يتم إعفاء بعض التطبيقات من التوقف أو الإدراج في قائمة حقوق المستخدم كما هو موضح في مستند SDK .
- [ 8.5 /H-0-1] يجب توفير إمكانية تحمل المستخدم
- [ 8.5 /H-0-2]يجب أن توفر للمستخدم القدرة على إيقاف التطبيق الذي يقوم بتشغيل خدمة مقدمة أو مهمة بدأها المستخدم.
انظر المراجعة
إذا أعلنت تطبيقات الجهاز دعمها لـ android.hardware.telephony
، فإنها:
- [ 9.5 /H-1-1] يجب عدم ضبط
UserManager.isHeadlessSystemUserMode
علىtrue
.
إذا كانت تطبيقات الجهاز تحتوي على شاشة قفل آمنة وتتضمن وكيل ثقة واحدًا أو أكثر، والذي يقوم بتنفيذ TrustAgentService
System API، فإنها:
- [ 9.11.1 /H-1-1] يجب أن يتحدى المستخدم لإحدى طرق المصادقة الأساسية الموصى بها (على سبيل المثال: رقم التعريف الشخصي، النمط، كلمة المرور) أكثر من مرة واحدة كل 72 ساعة.
إذا قامت تطبيقات الأجهزة المحمولة بتعيين UserManager.isHeadlessSystemUserMode
على true
، فإنها
إذا كانت تطبيقات الأجهزة المحمولة تدعم System API HotwordDetectionService
أو آلية أخرى لاكتشاف الكلمات المهمة دون إشارة الوصول إلى الميكروفون، فإنها:
- [9.8/H-1-1] يجب التأكد من أن خدمة الكشف عن الكلمات المهمة يمكنها فقط نقل البيانات إلى النظام أو
ContentCaptureService
أو خدمة التعرف على الكلام على الجهاز التي تم إنشاؤها بواسطةSpeechRecognizer#createOnDeviceSpeechRecognizer()
. - [9.8/H-1-6] يجب ألا يسمح بنقل أكثر من 100 بايت من البيانات (باستثناء التدفقات الصوتية) من خدمة الكشف عن الكلمات المهمة في كل نتيجة ناجحة للكلمات المهمة.
- [9.8/H-1-15] يجب التأكد من أن التدفقات الصوتية المقدمة في نتائج الكلمات المهمة الناجحة يتم إرسالها في اتجاه واحد من خدمة اكتشاف الكلمات المهمة إلى خدمة التفاعل الصوتي.
إذا كانت تطبيقات الجهاز تتضمن تطبيقًا يستخدم System API HotwordDetectionService
، أو آلية مشابهة لاكتشاف الكلمات المهمة دون الإشارة إلى استخدام الميكروفون، فإن التطبيق:
- [9.8/H-2-3] يجب عدم الإرسال من خدمة الكشف عن الكلمة المهمة، البيانات الصوتية، أو البيانات التي يمكن استخدامها لإعادة بناء (كليًا أو جزئيًا) الصوت، أو محتويات الصوت غير المرتبطة بالكلمة المهمة نفسها، باستثناء
ContentCaptureService
أو خدمة التعرف على الكلام على الجهاز.
إذا كانت تطبيقات الأجهزة المحمولة تدعم System API VisualQueryDetectionService
أو آلية أخرى لاكتشاف الاستعلام دون إشارة الوصول إلى الميكروفون و/أو الكاميرا، فإنها:
- [9.8/H-3-1] يجب التأكد من أن خدمة اكتشاف الاستعلام يمكنها فقط نقل البيانات إلى النظام، أو
ContentCaptureService
، أو خدمة التعرف على الكلام على الجهاز (التي تم إنشاؤها بواسطةSpeechRecognizer#createOnDeviceSpeechRecognizer()
). - [9.8/H-3-2] يجب عدم السماح بنقل أي معلومات صوتية أو فيديو من
VisualQueryDetectionService
، باستثناءContentCaptureService
أو خدمة التعرف على الكلام على الجهاز. - [9.8/H-3-3] يجب عرض إشعار المستخدم في واجهة مستخدم النظام عندما يكتشف الجهاز نية المستخدم للتعامل مع تطبيق المساعد الرقمي (على سبيل المثال، عن طريق اكتشاف وجود المستخدم عبر الكاميرا).
- [9.8/H-3-4] يجب أن يعرض مؤشر الميكروفون ويعرض استعلام المستخدم المكتشف في واجهة المستخدم مباشرة بعد اكتشاف استعلام المستخدم.
- [9.8/H-3-5] يجب ألا يسمح لتطبيق قابل للتثبيت من قبل المستخدم بتوفير خدمة الكشف عن الاستعلام المرئي.
انظر المراجعة
إذا أعادت تطبيقات الأجهزة المحمولة android.os.Build.VERSION_CODES.T
لـ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
، فإنها:
- يجب أن يفي بمتطلبات الوسائط المدرجة في Android 13 CDD القسم 2.2.7.1 .
بدء متطلبات جديدة
إذا أعادت تطبيقات الأجهزة المحمولةandroid.os.Build.VERSION_CODES.U
لـ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
، فإنها:- [5.1/H-1-1] يجب الإعلان عن الحد الأقصى لعدد جلسات وحدة فك ترميز فيديو الأجهزة التي يمكن تشغيلها بشكل متزامن في أي مجموعة برامج ترميز عبر أساليب
CodecCapabilities.getMaxSupportedInstances()
وVideoCapabilities.getSupportedPerformancePoints()
. - [5.1/H-1-2] يجب أن يدعم 6 مثيلات لجلسات فك ترميز فيديو الأجهزة 8 بت (SDR) (AVC أو HEVC أو VP9 أو AV1 أو أحدث) في أي مجموعة ترميز تعمل بشكل متزامن مع 3 جلسات بدقة 1080 بكسل بمعدل 30 إطارًا في الثانية و3 جلسات بدقة 4K بمعدل 30 إطارًا في الثانية، ما لم يكن AV1. برامج ترميز AV1 مطلوبة فقط لدعم دقة 1080 بكسل، ولكنها لا تزال مطلوبة لدعم 6 مثيلات بدقة 1080 بكسل 30 إطارًا في الثانية.
- [5.1/H-1-3] يجب الإعلان عن الحد الأقصى لعدد جلسات تشفير فيديو الأجهزة التي يمكن تشغيلها بشكل متزامن في أي مجموعة برامج ترميز عبر أساليب
CodecCapabilities.getMaxSupportedInstances()
وVideoCapabilities.getSupportedPerformancePoints()
. - [5.1/H-1-4] يجب أن يدعم 6 مثيلات لجلسات تشفير فيديو الأجهزة 8 بت (SDR) (AVC أو HEVC أو VP9 أو AV1 أو أحدث) في أي مجموعة ترميز تعمل بشكل متزامن مع 4 جلسات بدقة 1080 بكسل بمعدل 30 إطارًا في الثانية وجلستين بدقة 4K بمعدل 30 إطارًا في الثانية، ما لم يكن AV1. برامج ترميز AV1 مطلوبة فقط لدعم دقة 1080 بكسل، ولكنها لا تزال مطلوبة لدعم 6 مثيلات بدقة 1080 بكسل 30 إطارًا في الثانية.
- [5.1/H-1-5] يجب الإعلان عن الحد الأقصى لعدد جلسات تشفير الفيديو ووحدة فك ترميز الأجهزة التي يمكن تشغيلها بشكل متزامن في أي مجموعة برامج ترميز عبر أساليب
CodecCapabilities.getMaxSupportedInstances()
وVideoCapabilities.getSupportedPerformancePoints()
. - [5.1/H-1-6] يجب أن يدعم 6 مثيلات لوحدة فك ترميز فيديو الأجهزة 8 بت (SDR) وجلسات تشفير فيديو الأجهزة (AVC أو HEVC أو VP9 أو AV1 أو أحدث) في أي مجموعة ترميز تعمل بشكل متزامن مع 3 جلسات بدقة 4K دقة تصل إلى 30 إطارًا في الثانية (ما لم يكن AV1)، منها جلستان على الأكثر للتشفير و3 جلسات بدقة 1080 بكسل. برامج ترميز AV1 مطلوبة فقط لدعم دقة 1080 بكسل، ولكنها لا تزال مطلوبة لدعم 6 مثيلات بدقة 1080 بكسل 30 إطارًا في الثانية.
- [5.1/H-1-19] يجب أن يدعم 3 مثيلات لوحدة فك ترميز فيديو الأجهزة 10 بت (HDR) وجلسات تشفير فيديو الأجهزة (AVC أو HEVC أو VP9 أو AV1 أو أحدث) في أي مجموعة ترميز تعمل بشكل متزامن بدقة 4K بمعدل 30 إطارًا في الثانية (ما لم يكن AV1) منها جلسة واحدة على الأكثر عبارة عن جلسة تشفير، والتي يمكن تكوينها بتنسيق إدخال RGBA_1010102 من خلال سطح GL. لا يلزم إنشاء بيانات تعريف HDR بواسطة برنامج التشفير في حالة التشفير من سطح GL. جلسات الترميز AV1 مطلوبة فقط لدعم دقة 1080 بكسل حتى عندما يتطلب هذا المتطلب دقة 4K.
- [5.1/H-1-7] يجب أن يكون زمن الوصول لتهيئة برنامج الترميز يبلغ 40 مللي ثانية أو أقل لجلسة ترميز فيديو بدقة 1080 بكسل أو أصغر لجميع أجهزة تشفير فيديو الأجهزة عندما تكون تحت التحميل. يتم تعريف التحميل هنا على أنه جلسة تحويل ترميز فيديو فقط بدقة 1080 بكسل إلى 720 بكسل متزامنة باستخدام برامج ترميز الفيديو الخاصة بالأجهزة مع تهيئة تسجيل الصوت والفيديو بدقة 1080 بكسل. بالنسبة لبرنامج ترميز Dolby Vision، يجب أن يكون زمن الوصول لتهيئة برنامج الترميز 50 مللي ثانية أو أقل.
- [5.1/H-1-8] يجب أن يكون زمن الوصول لتهيئة برنامج الترميز يبلغ 30 مللي ثانية أو أقل لجلسة ترميز صوتي بمعدل بت 128 كيلوبت في الثانية أو أقل لجميع أجهزة تشفير الصوت عندما تكون تحت التحميل. يتم تعريف التحميل هنا على أنه جلسة تحويل ترميز فيديو فقط بدقة 1080 بكسل إلى 720 بكسل متزامنة باستخدام برامج ترميز الفيديو الخاصة بالأجهزة مع تهيئة تسجيل الصوت والفيديو بدقة 1080 بكسل.
- [5.1/H-1-9] يجب أن يدعم مثيلين لجلسات فك ترميز الفيديو الآمنة (AVC، HEVC، VP9، AV1 أو الأحدث) في أي مجموعة ترميز تعمل بشكل متزامن بدقة 4K بمعدل 30 إطارًا في الثانية (ما لم AV1) لكلا 8- بت (SDR) ومحتوى HDR 10 بت. جلسات الترميز AV1 مطلوبة فقط لدعم دقة 1080 بكسل حتى عندما يتطلب هذا المتطلب 4K.
- [5.1/H-1-10] يجب أن يدعم 3 مثيلات لجلسات وحدة فك ترميز فيديو الأجهزة غير الآمنة مع مثيل واحد لجلسة وحدة فك ترميز فيديو الأجهزة الآمنة (إجمالي 4 مثيلات) (AVC أو HEVC أو VP9 أو AV1 أو أحدث) في أي برنامج ترميز تعمل المجموعة بشكل متزامن مع 3 جلسات بدقة 4K عند 30 إطارًا في الثانية (ما لم يكن AV1) والتي تتضمن جلسة وحدة فك ترميز واحدة آمنة وجلسة واحدة آمنة بدقة 1080 بكسل عند 30 إطارًا في الثانية حيث يمكن أن تكون جلستان على الأكثر بتقنية HDR 10 بت. جلسات الترميز AV1 مطلوبة فقط لدعم دقة 1080 بكسل حتى عندما يتطلب هذا المتطلب 4K.
- [5.1/H-1-11] يجب أن يدعم وحدة فك ترميز آمنة لكل وحدة فك ترميز AVC أو HEVC أو VP9 أو AV1 على الجهاز.
- [5.1/H-1-12] يجب أن يكون زمن الوصول لتهيئة برنامج الترميز يبلغ 40 مللي ثانية أو أقل لجلسة فك تشفير فيديو بدقة 1080 بكسل أو أصغر لجميع أجهزة فك ترميز الفيديو عندما تكون تحت التحميل. يتم تعريف التحميل هنا على أنه جلسة تحويل ترميز فيديو فقط بدقة 1080 بكسل إلى 720 بكسل متزامنة باستخدام برامج ترميز الفيديو الخاصة بالأجهزة مع تهيئة تشغيل الصوت والفيديو بدقة 1080 بكسل. بالنسبة لبرنامج ترميز Dolby Vision، يجب أن يكون زمن الوصول لتهيئة برنامج الترميز 50 مللي ثانية أو أقل.
- [5.1/H-1-13] يجب أن يكون زمن الوصول لتهيئة برنامج الترميز يبلغ 30 مللي ثانية أو أقل لجلسة فك تشفير الصوت بمعدل بت 128 كيلوبت في الثانية أو أقل لجميع أجهزة فك تشفير الصوت عندما تكون تحت التحميل. يتم تعريف التحميل هنا على أنه جلسة تحويل ترميز فيديو فقط بدقة 1080 بكسل إلى 720 بكسل متزامنة باستخدام برامج ترميز الفيديو الخاصة بالأجهزة مع تهيئة تشغيل الصوت والفيديو بدقة 1080 بكسل.
- [5.1/H-1-14] يجب أن يدعم جهاز فك ترميز أجهزة AV1 الرئيسي 10 والمستوى 4.1 وحبوب الأفلام.
- [5.1/H-1-15] يجب أن يكون لديك جهاز فك تشفير فيديو واحد على الأقل يدعم 4K60.
- [5.1/H-1-16] يجب أن يكون لديك جهاز تشفير فيديو واحد على الأقل يدعم 4K60.
- [5.3/H-1-1] يجب عدم إسقاط أكثر من إطار واحد في 10 ثوانٍ (أي أقل من 0.167 بالمائة من انخفاض الإطار) لجلسة فيديو بدقة 4K بمعدل 60 إطارًا في الثانية تحت التحميل.
- [5.3/H-1-2] يجب عدم إسقاط أكثر من إطار واحد في 10 ثوانٍ أثناء تغيير دقة الفيديو في جلسة فيديو بمعدل 60 إطارًا في الثانية تحت التحميل لجلسة 4K.
- [5.6/H-1-1] يجب أن يكون زمن استجابة النقر للنغمة 80 مللي ثانية أو أقل باستخدام اختبار النقر للنغمة CTS Verifier.
- [5.6/H-1-2] يجب أن يكون زمن الوصول الصوتي ذهابًا وإيابًا يبلغ 80 مللي ثانية أو أقل عبر مسار بيانات مدعوم واحد على الأقل.
- [5.6/H-1-3] يجب أن يدعم >= صوت 24 بت لإخراج الاستريو عبر مقابس صوت 3.5 مم إذا كان موجودًا وعبر صوت USB إذا كان مدعومًا من خلال مسار البيانات بالكامل لتكوينات الكمون المنخفض والبث. بالنسبة لتكوين زمن الاستجابة المنخفض، يجب أن يستخدم التطبيق AAudio في وضع رد الاتصال ذو زمن الاستجابة المنخفض. بالنسبة لتكوين البث، يجب أن يستخدم التطبيق Java AudioTrack. في كل من تكوينات الكمون المنخفض والتدفق، يجب أن يقبل مخزن إخراج HAL إما
AUDIO_FORMAT_PCM_24_BIT
أوAUDIO_FORMAT_PCM_24_BIT_PACKED
أوAUDIO_FORMAT_PCM_32_BIT
أوAUDIO_FORMAT_PCM_FLOAT
لتنسيق الإخراج المستهدف الخاص به. - [5.6/H-1-4] يجب أن يدعم >= 4 أجهزة صوت USB ذات قنوات (يُستخدم هذا بواسطة وحدات تحكم DJ لمعاينة الأغاني.)
- [5.6/H-1-5] يجب أن يدعم أجهزة MIDI المتوافقة مع الفئة ويعلن عن علامة ميزة MIDI.
- [5.6/H-1-9] يجب أن يدعم خلط 12 قناة على الأقل. وهذا يعني القدرة على فتح AudioTrack باستخدام قناع قناة 7.1.4 وتقسيم جميع القنوات إلى صوت استريو أو مزجها بشكل صحيح.
- [5.6/H-SR] يوصى بشدة بدعم خلط 24 قناة مع دعم على الأقل لأقنعة 9.1.6 و22.2 قناة.
- [5.7/H-1-2] يجب أن يدعم
MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL
مع إمكانيات فك تشفير المحتوى أدناه.
الحد الأدنى لحجم العينة | 4 ميجابايت |
الحد الأدنى لعدد العينات الفرعية - H264 أو HEVC | 32 |
الحد الأدنى لعدد العينات الفرعية - VP9 | 9 |
الحد الأدنى لعدد العينات الفرعية - AV1 | 288 |
الحد الأدنى لحجم المخزن المؤقت للعينة الفرعية | 1 ميجابايت |
الحد الأدنى لحجم مخزن التشفير العام | 500 كيلو بايت |
الحد الأدنى لعدد الجلسات المتزامنة | 30 |
الحد الأدنى لعدد المفاتيح لكل جلسة | 20 |
الحد الأدنى لإجمالي عدد المفاتيح (جميع الجلسات) | 80 |
الحد الأدنى لإجمالي عدد مفاتيح DRM (جميع الجلسات) | 6 |
حجم الرسالة | 16 كيلو بايت |
الإطارات التي تم فك تشفيرها في الثانية | 60 إطارًا في الثانية |
- [5.1/H-1-17] يجب أن يكون لديك وحدة فك ترميز صور واحدة على الأقل تدعم ملف تعريف AVIF الأساسي.
- [5.1/H-1-18] يجب أن يدعم برنامج التشفير AV1 الذي يمكنه تشفير دقة تصل إلى 480 بكسل بمعدل 30 إطارًا في الثانية و1 ميجابت في الثانية.
-
[5.12/H-1-1] يجب أن يكون[5.12/H-SR] موصى به بشدة لدعم ميزةFeature_HdrEditing
لجميع أجهزة تشفير AV1 وHEVC الموجودة على الجهاز. - [5.12/H-1-2] يجب أن يدعم تنسيق الألوان RGBA_1010102 لجميع أجهزة تشفير AV1 وHEVC الموجودة على الجهاز.
- [5.12/H-1-3] يجب الإعلان عن الدعم لامتداد EXT_YUV_target لأخذ عينات من أنسجة YUV في كل من 8 و10 بت.
- [7.1.4/H-1-1] يجب أن يحتوي على 6 تراكبات أجهزة على الأقل في وحدة معالجة البيانات (DPU) ومؤلف الأجهزة (HWC)، مع قدرة 2 منها على الأقل على عرض محتوى فيديو 10 بت.
إذا كانت تطبيقات الأجهزة المحمولة تعرض android.os.Build.VERSION_CODES.U
لـ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
وتتضمن دعمًا لبرنامج تشفير AVC أو HEVC للأجهزة، فإنها:
- [5.2/H-2-1] يجب أن يفي بالحد الأدنى من الجودة المستهدفة التي تحددها منحنيات معدل تشويه جهاز تشفير الفيديو لبرامج ترميز AVC وHEVC للأجهزة، كما هو محدد في الوثائق القادمة.
انظر المراجعة
android.os.Build.VERSION_CODES.U
لـ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
، فإنها:- [ 7.5 /H-1-1] يجب أن يكون لديك كاميرا خلفية أساسية بدقة لا تقل عن 12 ميجابكسل تدعم التقاط الفيديو بدقة 4K بمعدل 30 إطارًا في الثانية. الكاميرا الخلفية الأساسية هي الكاميرا الخلفية ذات معرف الكاميرا الأدنى.
- [ 7.5 /H-1-2] يجب أن يكون لديك كاميرا أمامية أساسية بدقة لا تقل عن 6 ميجابكسل وتدعم التقاط الفيديو بدقة 1080 بكسل بمعدل 30 إطارًا في الثانية. الكاميرا الأمامية الأساسية هي الكاميرا الأمامية ذات معرف الكاميرا الأدنى.
- [ 7.5 /H-1-3] يجب أن يدعم خاصية
android.info.supportedHardwareLevel
بشكل كامل أو أفضل لكلا الكاميرتين الأساسيتين. - [ 7.5 /H-1-4] يجب أن يدعم
CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME
لكلا الكاميرتين الأساسيتين. - [ 7.5 /H-1-5] يجب أن يكون لدى الكاميرا2 زمن انتقال لالتقاط JPEG < 1000
900مللي ثانية لدقة 1080 بكسل كما تم قياسه بواسطة اختبار أداء كاميرا CTS في ظل ظروف إضاءة ITS (3000K) لكلا الكاميرتين الأساسيتين. - [ 7.5 /H-1-6] يجب أن يكون زمن وصول بدء تشغيل الكاميرا 2 (فتح الكاميرا لإطار المعاينة الأول) أقل من 500 مللي ثانية كما تم قياسه بواسطة اختبار أداء كاميرا CTS في ظل ظروف إضاءة ITS (3000K) لكلا الكاميرتين الأساسيتين.
- [ 7.5 /H-1-8] يجب أن يدعم
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW
وandroid.graphics.ImageFormat.RAW_SENSOR
للكاميرا الخلفية الأساسية. - [ 7.5 /H-1-9] يجب أن يكون لديك كاميرا أساسية خلفية تدعم 720p أو 1080p @ 240 إطارًا في الثانية.
- [ 7.5 /H-1-10] يجب أن يكون الحد الأدنى لـ ZOOM_RATIO < 1.0 للكاميرات الأساسية إذا كانت هناك كاميرا RGB فائقة الاتساع تواجه نفس الاتجاه.
- [ 7.5 /H-1-11] يجب تنفيذ البث الأمامي والخلفي المتزامن على الكاميرات الأساسية.
- [ 7.5 /H-1-12] يجب أن يدعم
CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION
لكل من الكاميرا الأمامية والخلفية الأساسية. - [ 7.5 /H-1-13] يجب أن يدعم إمكانية
LOGICAL_MULTI_CAMERA
للكاميرات الأساسية إذا كان هناك أكثر من كاميرا RGB واحدة تواجه نفس الاتجاه. - [ 7.5 /H-1-14] يجب أن يدعم إمكانية
STREAM_USE_CASE
لكل من الكاميرا الأمامية والخلفية الأساسية. - [ 7.5 /H-1-15] يجب أن يدعم امتدادات الوضع
Bokeh &Night عبر امتدادي CameraX وCamera2 للكاميرات الأساسية. - [ 7.5 /H-1-16] يجب أن يدعم إمكانية DYNAMIC_RANGE_TEN_BIT للكاميرات الأساسية.
- [ 7.5 /H-1-17] يجب أن يدعم CONTROL_SCENE_MODE_FACE_PRIORITY واكتشاف الوجه ( STATISTICS_FACE_DETECT_MODE_SIMPLE أو STATISTICS_FACE_DETECT_MODE_FULL ) للكاميرات الأساسية.
انظر المراجعة
android.os.Build.VERSION_CODES.U
لـ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
، فإنها:- [7.1.1.1/H-2-1] يجب أن تكون دقة الشاشة 1080 بكسل على الأقل.
- [7.1.1.3/H-2-1] يجب أن تكون كثافة الشاشة 400 نقطة في البوصة على الأقل.
- [7.1.1.3/H-3-1] يجب أن يحتوي على شاشة HDR تدعم متوسط 1000 شمعة على الأقل.
- [7.6.1/H-2-1] يجب أن يكون لديك ما لا يقل عن 8 جيجابايت من الذاكرة الفعلية.
انظر المراجعة
android.os.Build.VERSION_CODES.U
لـ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
، فإنها:- [8.2/H-1-1] يجب أن يضمن أداء كتابة متسلسل لا يقل عن 150 ميجابايت/ثانية.
- [8.2/H-1-2] يجب أن يضمن أداء كتابة عشوائي لا يقل عن 10 ميجابايت/ثانية.
- [8.2/H-1-3] يجب ضمان أداء قراءة تسلسلي لا يقل عن 250 ميجابايت/ثانية.
- [8.2/H-1-4] يجب ضمان أداء قراءة عشوائي لا يقل عن 100 ميجابايت/ثانية.
- [8.2/H-1-5] يجب ضمان أداء قراءة وكتابة متسلسل متوازي مع أداء قراءة وكتابة 2x بسرعة 50 ميجابايت/ثانية على الأقل.
انظر المراجعة
يجب أن تدعم تطبيقات أجهزة التلفزيون تنسيقات ترميز الفيديو التالية وإتاحتها لتطبيقات الجهات الخارجية:
- [ 5.2 /ت-0-3]AV1
يجب أن تدعم تطبيقات أجهزة التلفزيون تنسيقات فك تشفير الفيديو التالية وإتاحتها لتطبيقات الجهات الخارجية:
- [ 5.3.2 /T-0-7] AV1
انظر المراجعة
إذا كانت تطبيقات الجهاز تحتوي على شاشة قفل آمنة وتتضمن وكيل ثقة واحدًا أو أكثر، والذي يقوم بتنفيذ TrustAgentService
System API، فإنها:
- [ 9.11.1 /W-1-1] يجب أن يتحدى المستخدم لإحدى طرق المصادقة الأساسية الموصى بها (على سبيل المثال: رقم التعريف الشخصي، النمط، كلمة المرور) أكثر من مرة واحدة كل 72 ساعة.
انظر المراجعة
إذا كانت تطبيقات الجهاز تتضمن دعمًا لراديو البث AM/FM وتعرض الوظيفة لأي تطبيق، فإنها:
- [ 7.4
.10/A-0-1] يجب أن يعلن عن دعمFEATURE_BROADCAST_RADIO
.
كاميرا الرؤية الخارجية هي كاميرا تقوم بتصوير مشاهد خارج تنفيذ الجهاز، مثل كاميرا الرؤية الخلفية.
تطبيقات أجهزة السيارات:
- يجب أن تتضمن واحدة أو أكثر من كاميرات الرؤية الخارجية.
إذا كانت تطبيقات أجهزة السيارات تشتمل على كاميرا رؤية خارجية، فإنها بالنسبة لهذه الكاميرا:
- [ 7.5 /A-1-1] يجب ألا تكون هناك كاميرات عرض خارجية يمكن الوصول إليها عبر Android Camera APIs ، ما لم تتوافق مع المتطلبات الأساسية للكاميرا.
- [ 7.5 /A-SR-1] يُنصح بشدة بعدم تدوير معاينة الكاميرا أو عكسها أفقيًا.
- [ 7.5 /A-SR-2] يوصى بشدة أن تكون دقة الشاشة 1.3 ميجابكسل على الأقل.
- يجب أن تحتوي على أجهزة ذات تركيز ثابت أو EDOF (عمق المجال الممتد).
- قد يكون لديك إما التركيز التلقائي للأجهزة أو التركيز التلقائي للبرنامج المطبق في برنامج تشغيل الكاميرا.
إذا كانت تطبيقات أجهزة السيارات تتضمن واحدة أو أكثر من كاميرات الرؤية الخارجية، وتحميل خدمة نظام الرؤية الخارجية (EVS)، فإنها بالنسبة لهذه الكاميرا:
- [ 7.5 /A-2-1] يجب عدم تدوير معاينة الكاميرا أو عكسها أفقيًا.
تطبيقات أجهزة السيارات:
- قد يتضمن كاميرا واحدة أو أكثر متاحة لتطبيقات الطرف الثالث.
إذا تضمنت تطبيقات أجهزة السيارات كاميرا واحدة على الأقل وجعلتها متاحة لتطبيقات الطرف الثالث، فإنها:
- [ 7.5 /A-3-1] يجب الإبلاغ عن علامة الميزة
android.hardware.camera.any
. - [ 7.5 /A-3-2] يجب عدم الإعلان عن الكاميرا ككاميرا نظام .
- قد يدعم الكاميرات الخارجية الموضحة في القسم 7.5.3 .
- قد تتضمن ميزات (مثل التركيز التلقائي، وما إلى ذلك) المتاحة للكاميرات الخلفية كما هو موضح في القسم 7.5.1 .
الكاميرا الخلفية تعني كاميرا مواجهة للعالم يمكن وضعها في أي مكان في السيارة وتواجه الجزء الخارجي من مقصورة السيارة؛ أي أنها تصور مشاهد على الجانب البعيد من جسم السيارة، مثل كاميرا الرؤية الخلفية.
الكاميرا الأمامية تعني الكاميرا التي تواجه المستخدم والتي يمكن وضعها في أي مكان في السيارة وتواجه داخل مقصورة السيارة؛ أي أنها تصور المستخدم، مثل مؤتمرات الفيديو والتطبيقات المشابهة.
تطبيقات أجهزة السيارات:
- [7.5/A-SR-1] يوصى بشدة بتضمين كاميرا واحدة أو أكثر مواجهة للعالم.
- قد يتضمن كاميرا واحدة أو أكثر تواجه المستخدم.
- [7.5/A-SR-2] يوصى بشدة بدعم البث المتزامن لكاميرات متعددة.
إذا كانت تطبيقات أجهزة السيارات تتضمن كاميرا واحدة على الأقل تواجهها عالميًا ، فهي: لمثل هذه الكاميرا ، فهي:
- [7.5/A-1-1] يجب أن يكون موجهًا بحيث يتوافق البعد الطويل للكاميرا مع المستوى XY لمحاور مستشعرات Android.
- [7.5/A-SR-3] يوصى بشدة بتركيزه أو إدف (العمق الموسع للحقل).
- [7.5/A-1-2] يجب أن يكون لدى الكاميرا العالمية الأساسية ككاميرا عالمية مع أدنى معرف الكاميرا.
إذا كانت تطبيقات أجهزة السيارات تتضمن كاميرا واحدة على الأقل تواجهها المستخدم ، لمثل هذه الكاميرا:
- [7.5/A-2-1] يجب أن تكون الكاميرا الأساسية التي تواجه المستخدم هي الكاميرا التي تواجه المستخدم مع أدنى معرف الكاميرا.
- قد يكون موجهًا بحيث يكون البعد الطويل للكاميرا محاذاة مع مستوى XY من محاور مستشعر السيارات Android.
إذا كانت تطبيقات أجهزة السيارات تتضمن كاميرا يمكن الوصول إليها عبر android.hardware.Camera
أو android.hardware.camera2
API ، ثم:
- [7.5/A-3-1] يجب أن يتوافق مع متطلبات الكاميرا الأساسية في القسم 7.5.
إذا كانت تطبيقات أجهزة السيارات تتضمن كاميرا لا يمكن الوصول إليها عبر android.hardware.Camera
أو android.hardware.camera2
API ، ثم:
- [7.5/A-4-1] يجب أن يكون متاحًا عبر خدمة نظام العرض الموسعة.
إذا كانت تطبيقات أجهزة السيارات تتضمن واحدة أو أكثر من الكاميرات التي يمكن الوصول إليها عبر خدمة نظام العرض الموسعة ، لمثل هذه الكاميرا ، فإنها:
- [7.5/A-5-1] يجب ألا تدور أو تعكس أفقيًا معاينة الكاميرا.
- [7.5/A-SR-4] يوصى بشدة بالحصول على حل لا يقل عن 1.3 ميجابكسل.
إذا كانت تطبيقات أجهزة السيارات تتضمن واحدة أو أكثر من الكاميرات التي يمكن الوصول إليها عبر كل من خدمة نظام العرض الموسعة و android.hardware.Camera
أو android.hardware.Camera2
API ثم ، لمثل هذه الكاميرا ، هم:
- [7.5/A-6-1] يجب الإبلاغ عن معرف الكاميرا نفسه.
إذا كانت تطبيقات أجهزة السيارات توفر واجهة برمجة تطبيقات كاميرا خاصة ، فإنها:
- [7.5/A-7-1] يجب تنفيذ API الكاميرا باستخدام
android.hardware.camera2
API أو واجهة برمجة تطبيقات العرض الموسعة.
انظر المراجعة
تطبيقات أجهزة السيارات:
- [ 3.8 /A-0-1] يجب ألا تسمح للمستخدمين الثانويين الكاملين الذين ليسوا من المستخدمين المقدمة الحاليين تشغيل الأنشطة والوصول إلى واجهة المستخدم على أي شاشات.
انظر المراجعة
إذا تعلنت تطبيقات جهاز السيارات android.hardware.microphone
، فإنها:
- [ 9.8.2 /A-1-1] يجب أن يعرض مؤشر الميكروفون عندما يصل التطبيق إلى بيانات الصوت من الميكروفون ، ولكن ليس عندما يتم الوصول إلى الميكروفون فقط بواسطة
HotwordDetectionService
أوSOURCE_HOTWORD
أوContentCaptureService
أو تطبيقات تحمل الأدوار في القسم 9.1 مع معرف CDD [C-4-X]. - [ 9.8.2 /A-1-2] يجب ألا تخفي مؤشر الميكروفون لتطبيقات النظام التي تحتوي على واجهات مستخدم مرئية أو تفاعل المستخدم المباشر.
- [ 9.8.2 /A-1-3] يجب أن يوفر مستخدمًا لتبديل الميكروفون في تطبيق الإعدادات.
إذا تعلنت تطبيقات جهاز السيارات android.hardware.camera.any
، فإنها:
- [ 9.8.2 /A-2-1] يجب أن تعرض مؤشر الكاميرا عندما يصل التطبيق إلى بيانات الكاميرا الحية ، ولكن ليس عندما يتم الوصول إلى الكاميرا فقط بواسطة التطبيق (التطبيقات) التي تحمل الأدوار كما هو
محددفي القسم 9.1 أذونات مع معرف CDD [C-4-X][C-3-X].
إذا كانت تطبيقات الأجهزة تحتوي على شاشة قفل آمنة وتتضمن وكيل ثقة واحد أو أكثر ، والذي ينفذ واجهة برمجة تطبيقات نظام TrustAgentService
، فإنها:
- [ 9.11.1 /A-1-1] يجب أن يتحدى المستخدم إحدى طرق المصادقة الأولية الموصى بها (على سبيل المثال: PIN ، نمط ، كلمة مرور) أكثر من مرة كل 336 ساعة.
3. البرمجيات
3.1. توافق واجهة برمجة التطبيقات المدارة :
انظر المراجعة
تطبيقات الجهاز:
- [C-0-8] يجب ألا يدعم تثبيت التطبيقات التي تستهدف مستوى API أقل من 23.
3.2.3.5. تطبيقات التطبيق الشرطي :
انظر المراجعة
إذا أبلغت تطبيقات الأجهزة
android.hardware.nfc.uicc
أوandroid.hardware.nfc.ese
، فإنها:- [C-19-1] يجب تنفيذ NFCADAPTER.ACTION_TRANSACTION_DETEDECTED API (كـ "evt_transaction" المحددة بواسطة المواصفات الفنية لجمعية GSM Ts.26-NFC متطلبات هاتف) .
انظر المراجعة
تطبيقات الجهاز:
- [C-0-12] يجب تصدير رموز دالة لرموز دالة
Vulkan 1.0Vulkan 1.1libvulkan.so
وكذلكVK_KHR_surface
،VK_KHR_android_surface
،VK_KHR_swapchain
،VK_KHR_maintenance1
وVK_KHR_get_physical_device_properties2
. لاحظ أنه على الرغم من أن جميع الرموز يجب أن تكون موجودة ، فإن القسم 7.1.4.2 يصف بمزيد من التفصيل متطلبات عندما يتوقع التنفيذ الكامل لكل وظائف مقابلة.
- [C-0-12] يجب تصدير رموز دالة لرموز دالة
انظر المراجعة
إذا كانت تطبيقات الجهاز تتضمن شاشة أو إخراج فيديو ، فإنها:
- [C-1-5]
EXPRESSIVE
TONAL_SPOT
MONOCHROMATIC
لوحات نغوية ألوانSPRITZ
باستخدامVIBRANT
السمةRAINBOW
المذكورةandroid.theme.customization.theme_styles
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
FRUIT_SALAD
.
- [C-1-5]
انظر المراجعة
إذا كانت تطبيقات الجهاز بما في ذلك مفتاح التنقل في دالة Recents كما هو مفصل في القسم 7.2.3 ، قم بتغيير الواجهة ، فهي:
- [C-1-2] يجب تنفيذ سلوك تثبيت الشاشة وتزويد المستخدم بقائمة إعدادات لتبديل الميزة.
3.9.2 دعم الملف الشخصي المدارة :
انظر المراجعة
إذا تعلنت تطبيقات الجهاز
android.software.managed_users
، فإنها:- [C-1-10] يجب أن يضمن حفظ بيانات لقطة الشاشة في تخزين ملف تعريف العمل عندما يتم التقاط لقطة شاشة مع نافذة
topActivity
لها التركيز (التي تفاعل المستخدم مع آخر جميع الأنشطة) وتنتمي إلى ملف تعريف عمل برنامج . - [C-1-11] يجب ألا يلتقط أي محتوى شاشة آخر (شريط النظام أو الإخطارات أو أي محتوى ملف تعريف شخصي) باستثناء نافذة تطبيق ملف تعريف العمل/Windows عند حفظ لقطة شاشة إلى ملف تعريف العمل (لضمان أن بيانات الملف الشخصي الشخصي لم يتم حفظه في ملف تعريف العمل).
- [C-1-10] يجب أن يضمن حفظ بيانات لقطة الشاشة في تخزين ملف تعريف العمل عندما يتم التقاط لقطة شاشة مع نافذة
3.9.5 إطار حل سياسة الجهاز : قسم جديد
انظر المراجعة
إذا أبلغت تطبيقات الجهاز
android.software.device_admin
أوandroid.software.managed_users
، فإنها:- [C-1-1] يجب حل تعارضات سياسة الجهاز كما هو موثق في وثائق AOSP.
5. توافق الوسائط المتعددة
انظر المراجعة
يجب أن تدعم تطبيقات الجهاز ترميز ترميز الصورة التالي:
- [C-0-4] Avif
- يجب أن تدعم الأجهزة
BITRATE_MODE_CQ
والملف الشخصي الأساسي.
- يجب أن تدعم الأجهزة
- [C-0-4] Avif
انظر المراجعة
يجب أن تدعم تطبيقات الجهاز فك تشفير الصورة التالية:
[C-0-7] AVIF (ملف تعريف خط الأساس)
5.1.6. تفاصيل برامج ترميز الصور :
انظر المراجعة
التنسيق/الترميز تفاصيل أنواع الملفات المدعومة/تنسيقات الحاويات جبيغ قاعدة+تقدمية JPEG (.jpg) GIF GIF (.gif) بي إن جي PNG (.png) بي إم بي BMP (.BMP) ويب بي WebP (.webp) خام ARW (.arw) ، cr2 (.cr2) ، dng (.dng) ، nef (.nef) ، nrw (.nrw) ، orf (.orf) ، PEF (. .rw2) ، SRW (.SRW) هيف الصورة ، جمع الصور ، تسلسل الصور Heef (.heif) ، Heic (. AVIF (ملف تعريف خط الأساس) الصورة ، جمع الصور ، ملف تعريف تسلسل الصور الأساس حاوية HEIF (.AVIF) 5.1.8. قائمة برامج ترميز الفيديو :
انظر المراجعة
التنسيق/الترميز تفاصيل أنواع الملفات/تنسيقات الحاويات المراد دعمها ح.263 - 3GPP (.3GP)
- MPEG-4 (.mp4)
- Matroska (.mkv ، فك التشفير فقط)
H.264 ايه في سي انظر القسم 5.2 و 5.3 للحصول على التفاصيل - 3GPP (.3GP)
- MPEG-4 (.mp4)
- MPEG-2 TS (.TS ، غير قابلة للبحث)
- Matroska (.mkv ، فك التشفير فقط)
H.265 HEVC انظر القسم 5.3 للحصول على التفاصيل - MPEG-4 (.mp4)
- Matroska (.mkv ، فك التشفير فقط)
مبيغ-2 الملف الرئيسي - MPEG2-TS (.TS ، لا يمكن البحث عنها)
- MPEG-4 (.mp4 ، فك الشفرة فقط)
- Matroska (.mkv ، فك التشفير فقط)
MPEG-4 sp - 3GPP (.3GP)
- MPEG-4 (.mp4)
- Matroska (.mkv ، فك التشفير فقط)
VP8 انظر القسم 5.2 و 5.3 للحصول على التفاصيل - ويب إم (.webm)
- متروسكا (.mkv)
VP9 انظر القسم 5.3 للحصول على التفاصيل - ويب إم (.webm)
- متروسكا (.mkv)
AV1 انظر القسم 5.2 والقسم 5.3 للحصول على التفاصيل - MPEG-4 (.mp4)
- Matroska (.mkv ، فك التشفير فقط)
انظر المراجعة
إذا كانت تطبيقات الجهاز تدعم برامج ترميز الفيديو:
- [C-2-1] يجب أن تنشر جميع برامج ترميز الفيديو بيانات معدل الإطارات القابلة للتحقيق للأحجام التالية إذا تم دعمها بواسطة برنامج الترميز:
SD (جودة منخفضة) SD (جودة عالية) HD 720p HD 1080p فائق الوضوح دقة الفيديو - 176 × 144 px (H263 ، MPEG2 ، MPEG4)
- 352 × 288 px (MPEG4 Encoder ، H263 ، MPEG2)
- 320 × 180 بكسل (VP8 ، VP8)
- 320 × 240 بكسل (آخر)
- 704 × 576 بكسل (H263)
- 640 × 360 بكسل (VP8 ، VP9)
- 640 × 480 بكسل (MPEG4 Encoder)
- 720 × 480 بكسل (آخر ، AV1 )
- 1408 × 1152 بكسل (H263)
- 1280 × 720 بكسل (آخر ، AV1 )
1920 × 1080 بكسل (بخلاف MPEG4 ، AV1 ) 3840 x 2160 px (HEVC ، VP9 ، AV1 ) انظر المراجعة
إذا كانت تطبيقات الجهاز تدعم أي تشفير فيديو وجعلها متاحة لتطبيقات الطرف الثالث ، فإنها:- لا ينبغي أن يكون ، أكثر من نافذتين منزلقين ، أكثر من 15 ٪ على البت بين الفواصل الزمنية داخل الإطار (I-Frame).
- لا ينبغي أن يكون أكثر من 100 ٪ على البت على نافذة انزلاق من ثانية واحدة.
إذا كانت تطبيقات الجهاز تدعم أي تشفير فيديو وجعله متاحًا لتطبيقات الطرف الثالث ، وتعيين
MediaFormat.KEY_BITRATE_MODE
إلىBITRATE_MODE_VBR
بحيث يعمل المشفر في وضع معدل البت المتغير ، ثم ، طالما أنه لا يؤثر على الحد الأدنى من الجودة ، فإن التوية المشفرة:- يجب ألا يكون
[C-5-1]، على نافذة منزلق واحدة ، أكثر من 15 ٪ على الفواصل بين البت بين الفواصل الداخلية (I-Frame). -
[C-5-2] يجبألا يكون أكثر من 100 ٪ على البت على نافذة انزلاق من ثانية واحدة.
إذا كانت تطبيقات الجهاز تدعم أي تشفير فيديو وجعلها متاحة لتطبيقات الطرف الثالث وتعيين
MediaFormat.KEY_BITRATE_MODE
إلىBITRATE_MODE_CBR
بحيث يعمل التشفير في وضع البت المستمر ، ثم البت المشفر:- يوصى بشدة
[C-6-1][C-SR-2] بعدم أن يكون أكثر من 15 ٪ على البت المستهدف على نافذة انزلاق من ثانية واحدة.
انظر المراجعة
إذا كانت تطبيقات الأجهزة تدعم H.263 ترميزها وجعلها متاحة لتطبيقات الطرف الثالث ، فإنها:
- [C-1-1] يجب أن يدعم دقة QCIF (176 × 144) باستخدام مستوى ملف تعريف الأساس 45. دقة SQCIF اختيارية.
-
يجب أن تدعم معدلات بت قابلة للتكوين ديناميكيًا للمشفر المدعوم.
انظر المراجعة
إذا كانت تطبيقات الجهاز تدعم برنامج ترميز H.265 ، فإنها:
- [C-1-1] يجب أن يدعم مستوى الملف الشخصي الرئيسي 3 حتى 512 × 512 دقة .
-
يجب دعم ملفات تعريف ترميز HD كما هو موضح في الجدول التالي. - [C-SR-1] يوصى بشدة بدعم ملف تعريف 720 × 480 SD وملفات تشفير HD كما هو موضح في الجدول التالي إذا كان هناك تشفير للأجهزة.
5.2.6. AV1 : قسم جديد
انظر المراجعة
إذا كانت تطبيقات الجهاز تدعم برنامج Codec AV1 ، فهي:
- [C-1-1] يجب أن يدعم الملف الشخصي الرئيسي بما في ذلك محتوى 8 بت و 10 بت.
[C-1-2] يجب أن تنشر بيانات الأداء ، أي بيانات الأداء للتقرير عبر
getSupportedFrameRatesFor()
أوgetSupportedPerformancePoints()
واجهات برمجة التطبيقات للقرارات المدعومة في الجدول أدناه.[C-1-3] يجب أن يقبل بيانات تعريف HDR وإخراجها إلى Bitstream
إذا تم تسريع جهاز تشفير AV1 ، فعندئذٍ:
- [C-2-1] يجب أن يدعم ما يصل إلى HD1080p التشفير من الجدول أدناه:
SD HD 720p HD 1080p فائق الوضوح دقة الفيديو 720 × 480 بكسل 1280 × 720 بكسل 1920 × 1080 بكسل 3840 × 2160 بكسل معدل إطار الفيديو 30 إطارًا في الثانية 30 إطارًا في الثانية 30 إطارًا في الثانية 30 إطارًا في الثانية عرض الفيديو 5 ميجابت في الثانية 8 ميغابت في الثانية 16 ميغابت في الثانية 50 ميجابت في الثانية انظر المراجعة
إذا كانت تطبيقات الأجهزة تدعم فك تشفير H.263 ، فإنها:
- [C-1-1] يجب أن يدعم مستوى ملف تعريف خط الأساس 30 (CIF ، QCIF و SQCIF دقة @ 30FPS 384KBPS) والمستوى 45 (قرارات QCIF و SQCIF @ 30FPS 128KBPS) .
انظر المراجعة
إذا كانت تطبيقات الجهاز تدعم برنامج ترميز AV1 ، فإنها:- [C-1-1] يجب أن يدعم الملف الشخصي 0 بما في ذلك المحتوى 10 بت.
إذا كانت تطبيقات الأجهزة تدعم برنامج ترميز AV1 وجعلها متاحة لتطبيقات الطرف الثالث ، فإنها:
- [C-1-1] يجب أن يدعم الملف الشخصي الرئيسي بما في ذلك محتوى 8 بت و 10 بت.
إذا كانت تطبيقات الأجهزة توفر الدعم لبرنامج Codec AV1 مع وحدة فك ترميز أجهزة متسارعة ، فإنها:
- [C-2-1] يجب أن يكون قادرًا على فك تشفير ملفات فك تشفير الفيديو HD 720p على الأقل من الجدول أدناه عندما يكون الارتفاع الذي تم الإبلاغ عنه بواسطة
Display.getSupportedModes()
متساوية أو أكبر من 720 بكسل. - [C-2-2] يجب أن يكون قادرًا على فك تشفير ملفات فك تشفير الفيديو HD 1080p على الأقل من الجدول أدناه عندما يكون الارتفاع الذي تم الإبلاغ عنه بواسطة
Display.getSupportedModes()
متساوية أو أكبر من 1080 بكسل.
SD HD 720p HD 1080p فائق الوضوح دقة الفيديو 720 × 480 بكسل 1280 × 720 بكسل 1920 × 1080 بكسل 3840 × 2160 بكسل معدل إطار الفيديو 30 إطارًا في الثانية 30 إطارًا في الثانية 30 إطارًا في الثانية 30 إطارًا في الثانية عرض الفيديو 5 ميجابت في الثانية 8 ميغابت في الثانية 16 ميغابت في الثانية 50 ميجابت في الثانية إذا كانت تطبيقات الجهاز تدعم ملف تعريف HDR من خلال واجهات برمجة التطبيقات الوسائط ، فإنها:
- [C-3-1] يجب أن تدعم استخراج وإخراج بيانات التعريف HDR من Bitstream و/أو الحاوية.
- [C-3-2] يجب أن يعرض محتوى HDR بشكل صحيح على شاشة الجهاز أو على منفذ إخراج الفيديو القياسي (على سبيل المثال ، HDMI).
5.4.2. التقاط للتعرف على الصوت :
انظر المراجعة
إذا تعلنت تطبيقات الجهاز
android.hardware.microphone
، فإنها:- يجب أن تضع حساسية مدخلات الصوت بحيث أن مصدر نغمة الجيوب الأنفية 1000 هرتز يتم تشغيله عند مستوى ضغط الصوت 90 ديسيبل (SPL) (يقاس
على مسافة 30 سم منبجوار الميكروفون) يحقق استجابة مثالية لـ RMS 2500 ضمن نطاق 1770 و 3530 لعينات 16 بت (أو -22.35 ديسيبل ± 3DB النطاق الكامل لعينات النقطة العائمة/الدقة المزدوجة) لكل ميكروفون يستخدم لتسجيل مصدر الصوت التعرف على الصوت.
- يجب أن تضع حساسية مدخلات الصوت بحيث أن مصدر نغمة الجيوب الأنفية 1000 هرتز يتم تشغيله عند مستوى ضغط الصوت 90 ديسيبل (SPL) (يقاس
انظر المراجعة
إذا أعلنت تطبيقات الجهاز ميزة
android.hardware.audio.output
، فإنها:- [C-1-4] يجب أن يدعم التأثيرات الصوتية مع الإدخال والإخراج العائم.
- يجب أن تتأكد [C-1-5] من أن تأثيرات الصوت تدعم قنوات متعددة حتى عدد قناة الخلاط المعروف أيضًا باسم FCC_LIMIT.
انظر المراجعة
إذا تعلنت تطبيقات الأجهزة
android.hardware.audio.output
، فمن المستحسن بشدة تلبية أو تجاوز المتطلبات التالية:- [C-SR-4] طابع الزمني للإخراج الذي تم إرجاعه بواسطة Audiotrack.getTimestamp و
AAudioStream_getTimestamp
دقيق إلى +/- 1 مللي ثانية.
- [C-SR-4] يوصى بشدة بإعداد زمنات الكمون المحسوبة للرحلات المستديرة على أساس الطوابع الزمنية للإدخال والمخرجات التي يتم إرجاعها بواسطة
AAudioStream_getTimestamp
في ضمن 30 ميللي ثانية من زمنAAUDIO_PERFORMANCE_MODE_LOW_LATENCY
الرحلة المقيسة للسماعات ، و WiredAAUDIO_PERFORMANCE_MODE_NONE
Wired و WiRENTER.
- [C-SR-4] طابع الزمني للإخراج الذي تم إرجاعه بواسطة Audiotrack.getTimestamp و
7. توافق الأجهزة
انظر المراجعة
يتضمن Android تسهيلات تقوم تلقائيًا بضبط أصول التطبيق وتخطيطات واجهة المستخدم بشكل مناسب للجهاز للتأكد من أن تطبيقات الطرف الثالث تعمل بشكل جيد على
مجموعة متنوعة من تكوينات الأجهزة .مجموعة متنوعة من عروض الأجهزة والتكوينات. الشاشة المتوافقة مع Android هي شاشة عرض تنفذ جميع السلوكيات وواجهة برمجة التطبيقات الموضحة في مطوري Android-نظرة عامة على توافق الشاشة ، هذا القسم (7.1) وأقسامه الفرعية ، وكذلك أي سلوكيات إضافية من نوع الجهاز موثقة في القسم 2 من هذا CDD.على الشاشة (الشاشة) المتوافقة مع Android حيث يمكن لجميع التطبيقات المتوافقة مع Android أن تنفذ تطبيقات الأجهزة هذه بشكل صحيح ، على النحو المفصل في هذا القسم.بدء متطلبات جديدة
تطبيقات الجهاز:
- [C-0-1] يجب ، افتراضيًا ، تقديم تطبيقات الطرف الثالث فقط على شاشات التوافق المتوافقة مع Android.
يتم تعريف الوحدات المشار إليها من قبل المتطلبات الواردة في هذا القسم على النحو التالي:
- الحجم القطري المادي . المسافة في بوصة بين زئنين معارضين للجزء المضيء من الشاشة.
-
نقاط لكل بوصة (DPI)الكثافة . عدد وحدات البكسل التي يشملها فترة أفقية أو عمودية خطي من 1 " ، معبراً عنها كبكسل لكل بوصة (PPI أو DPI) . عندما يتم سرد قيمDPIPPI و DPI ، يجب أن تقع كل من DPI الأفقية والعمودية ضمن النطاق المدرج . - ابعاد متزنة . نسبة البكسلات من البعد الأطول إلى البعد الأقصر للشاشة. على سبيل المثال ، سيكون عرض 480 × 854 بكسل 854/480 = 1.779 ، أو تقريبًا "16: 9".
- بكث الكثافة مستقلة بكسل (DP) . يتم حساب
وحدةالبكسل الافتراضية التي تم تطبيعها إلى كثافة شاشةشاشة 160 نقطة في البوصة160. بالنسبة لبعض الكثافة D ، وعدد من وحدات البكسل P ، عدد البكسلات المستقلة عن الكثافة ، على النحو التالي:Pixels = DPS * (الكثافة/160)dp = (160 / d) * p .
انظر المراجعة
إذا كانت تطبيقات الأجهزة تدعم الشاشات القادرة على تكوين حجم
UI_MODE_TYPE_NORMAL
وتتضمناستخدام (مواد) استخدام (زوايا) مدورة لتقديم هذه الشاشات ، فهي:- يجب أن يضمن [C-1-1] على الأقل واحدًا من المتطلبات التالية لكل شاشة من هذا القبيل :
- نصف قطر الزوايا المستديرة أقل من أو يساوي 38 DP.
عندما يتم تثبيت مربع 15 نقطة في الساعة 15 نقطة في كل ركن من أركان الشاشة المنطقية ، يكون بكسل واحد على الأقل من كل مربع مرئيًا على الشاشة.
يجب أن تتضمن تكاليف المستخدم للتبديل إلى وضع العرض مع الزوايا المستطيلة.
بدء متطلبات جديدة
إذا كانت تطبيقات الجهاز قادرة فقط على تكوين لوحة المفاتيح
NO_KEYS
، وتعتزم الإبلاغ عن دعم تكوين وضع واجهة المستخدمUI_MODE_TYPE_NORMAL
، فهي:- يجب أن يكون [C-4-1] حجم تخطيط ، باستثناء أي قواطع عرض ، لا يقل عن 596 DP × 384 DP أو أكثر.
إذا كانت تطبيقات الأجهزة تتضمن شاشة (شاشة) متوافقة مع Android قابلة للطي ، أو تتضمن مفصلًا قابلًا للطي بين لوحات العرض المتعددة ويجعل مثل هذه العرض (العروض) متاحة لتقديم تطبيقات الطرف الثالث ، فهي:
- [C-2-1] يجب أن تنفذ أحدث إصدار مستقر متاح من API extensions أو الإصدار المستقر من Sidecar API لاستخدامه بواسطة مكتبة Window Manager Jetpack .
إذا كانت تطبيقات الأجهزة تتضمن شاشة (شاشة) متوافقة مع Android قابلة للطي ، أو تتضمن مفصلًا قابلًا للطي بين لوحات العرض المتعددة وإذا كان المفصل أو الطية يعبر نافذة تطبيق ملء الشاشة ، فإنها:
- [C-3-1] يجب الإبلاغ عن الموضع والحدود وحالة المفصلات أو الطوية من خلال الامتدادات أو واجهات برمجة التطبيقات الجانبية للتطبيق.
إذا كانت تطبيقات الأجهزة تتضمن واحدة أو أكثر من مناطق عرض متوافقة مع Android قابلة للطي ، أو تتضمن مفصلاً قابلة للطي بين مناطق لوحة عرض متعددة متوافقة مع Android وإتاحة مناطق العرض هذه للتطبيقات ، فإنها:
- [C-4-1] يجب أن تنفذ الإصدار الصحيح من مستوى API Manager Manager كما هو موضح في الوثائق القادمة.
7.1.1.2. نسبة العرض إلى الارتفاع الشاشة : تمت إزالته
انظر المراجعة
تطبيقات الأجهزة:
- [C-0-1]
بشكل افتراضي ، يجب أن تقوم تطبيقات الأجهزةبالإبلاغ عن واحدةفقطمن كثافة إطار Android التي يتم إدراجها فيDisplayMetrics
من خلال APIDENSITY_DEVICE_STABLE
، ويجب أن تكون هذه القيمة قيمة ثابتة لكل شاشة فعليةلا يجب أن تتغير في أي وقت ؛ ومع ذلك ،يجوز للجهاز الإبلاغ عنDisplayMetrics.density
DisplayMetricsمختلفة.
- يجب أن تحدد تطبيقات الجهاز كثافة إطار Android القياسية التي هي الأقرب عدديًا إلى الكثافة المادية للشاشة ، ما لم تدفع هذه الكثافة المنطقية حجم الشاشة المبلغ عنها دون الحد الأدنى المدعوم. إذا كانت كثافة إطار عمل Android القياسية التي هي الأقرب إلى الكثافة الفعلية تؤدي إلى حجم شاشة أصغر من أصغر حجم شاشة متوافق مع المتوافق (عرض 320 DP) ، فيجب أن تقوم تطبيقات الأجهزة بالإبلاغ عن كثافة إطار عمل Android القياسية التالية.
بدء متطلبات جديدة
- يجب تحديد كثافة إطار Android القياسية التي هي الأقرب عدديًا إلى الكثافة المادية للشاشة ، أو قيمة من شأنها أن تخطط إلى نفس قياسات مجال الرؤية الزاوي نفسه لجهاز محمولة.
إذا توفرت تطبيقات الأجهزة
هناكتكاليف لتغيير حجم عرض الجهاز ، فإنها :- [C-1-1]
يجب ألا يتم قياس حجم العرض أيشاشة أكبر من 1.5 مرة منالكثافة الأصليةDENSITY_DEVICE_STABLE
أو تنتج بعدًا فعالًا للشفقة أصغر من 320 ديسمبر / الواسعة (أي ما يعادل مؤهلات الموارد SW320DP) ، أيهما يأتي أولاً. - [C-1-2]
يجب ألا يتم قياس حجم العرض أييجب ألا يؤدي إلى زيادة حجم الشاشة أصغر من 0.85 أضعاف الكثافةDENSITY_DEVICE_STABLE
للكثافة.
- [C-0-1]
انظر المراجعة
إذا كانت تطبيقات الأجهزة تتضمن دعم Vulkan
1.0 أو أعلى، فإنها:[C-1-3] يجب أن تنفذ بالكامل واجهات برمجة التطبيقات
Vulkan 1.0Vulkan 1.1 لكلVkPhysicalDevice
المُعداد.[C-1-5] يجب ألا تعدد الطبقات التي توفرها المكتبات خارج حزمة التطبيق ، أو توفر طرقًا أخرى لتتبع أو اعتراض API Vulkan ، ما لم يكن التطبيق يحتوي على السمة
android:debuggable
على أنهاtrue
أو metadatacom.android.graphics.injectLayers.enable
تعيين إلىtrue
.
- يجب أن يدعم
VkPhysicalDeviceProtectedMemoryFeatures
وVK_EXT_global_priority
.
- [C-1-13] يجب أن تفي بالمتطلبات المحددة بواسطة ملف تعريف Android الأساسي 2021 .
[C-SR-5] يوصى بشدة بدعم
VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory
وVK_EXT_global_priority
.[C-SR-6] يوصى بشدة باستخدام
SkiaVk
مع HWUI.
إذا كانت تطبيقات الأجهزة تتضمن دعمًا لـ Vulkan 1.1 وأعلن أي من أعلام ميزة Vulkan الموضحة هنا ، فإنها:
- [C-SR-7] يوصى بشدة بإحداث امتداد
VK_KHR_external_fence_fd
لتطبيقات الطرف الثالث وتمكين التطبيق من حمولة سياج تصدير إلى واستيراد حمولة السياج من واصفات ملف POSIX كما هو موضح هنا .
7.3.10. مستشعرات القياس الحيوي :
انظر المراجعة
إذا كانت تطبيقات الأجهزة تحتوي على أجهزة استشعار بيومترية متعددة ، فإنها:
[C-7-1] يجب ، عندما تكون القياس الحيوي في تأمين (أي يتم تعطيل القياس الحيوي حتى يتم فتح المستخدم مع المصادقة الأولية) أو القفل المقيد بالوقت (أي يتم تعطيل القياس الحيوي مؤقتًا حتى ينتظر المستخدم لفاصل زمني) نظرًا للعديد من المحاولات الفاشلة ، قم أيضًا بإغلاق جميع القياسات الحيوية الأخرى لفئة بيومترية منخفضة. في حالة تأمين المرتبط بالوقت ، يجب أن يكون وقت التراجع للتحقق البيومترية هو الحد الأقصى لوقت التراجع لجميع القياسات الحيوية في القفل المرتبط بالوقت.
يوصى بشدة [C-SR-12] ، عندما يكون القياس الحيوي في تأمين (أي يتم تعطيل القياس الحيوي حتى يتم فتح المستخدم مع المصادقة الأولية) أو القفل المرتبط بالوقت (أي يتم تعطيل القياس الحيوي مؤقتًا حتى ينتظر المستخدم لفترة زمنية الفاصل الزمني) نظرًا للعديد من المحاولات الفاشلة ، لإغلاق جميع القياسات الحيوية الأخرى لنفس الفئة البيومترية. في حالة تأمين المرتبط بالوقت ، يوصى بشدة أن يكون وقت التراجع عن وقت الاحتفاظ بوقت الاحتياطي الأقصى لجميع القياسات الحيوية في القفل المرتبط بالوقت.
[C-7-2] يجب أن يتحدى المستخدم للمصادقة الأولية الموصى بها (على سبيل المثال: PIN ، نمط ، كلمة مرور) لإعادة تعيين عداد القفل لقيام Biometric. يمكن السماح للقياسات الحيوية من الفئة 3 بإعادة ضبط عداد القفل لقياس بيومتر مقفل من نفس الفئة أو الفئة السفلية. يجب ألا يُسمح لقياسات الفئة 2 أو الفئة 1 بإكمال عملية إعادة تعيين قفل إعادة تعيين أي قياسات حيوية.
إذا كانت تطبيقات الأجهزة ترغب في علاج مستشعر القياس الحيوي كصف 1 ( الراحة سابقًا) ، فإنها:
[C-1-12] يجب أن يكون له معدل قبول محاكاة ساخرة ودجال لا يزيد عن 40 ٪ لكل نوع من أنواع هجوم العرض (PAI) ، كما تم قياسه بواسطة بروتوكولات اختبار القياسات الحيوية Android .
[C-SR-13] يوصى بشدة أن يكون معدل قبول محاكاة ساخرة ودجال لا يزيد عن 30 ٪ لكل نوع من أنواع أدوات هجوم العرض (PAI) ، كما تم قياسه بواسطة بروتوكولات اختبار القياسات الحيوية Android .
[C-SR-14] يوصى بشدة بالكشف عن الفئة البيومترية من المستشعر الحيوي والمخاطر المقابلة لتمكينه.
[C-SR-17] يوصى بشدة بتنفيذ واجهات AIDL الجديدة (مثل ،
IFace.aidl
وIFingerprint.aidl
).
إذا كانت تطبيقات الأجهزة ترغب في التعامل مع مستشعر القياس الحيوي على أنه الفئة 2 ( ضعيفة سابقًا) ، فإنها:
- يوصى بشدة [C-SR-15] بوجود معدل قبول محاكاة ساخرة ودجال لا يزيد عن 20 ٪ لكل نوع من أنواع أدوات هجوم العرض (PAI) ، كما تم قياسه بواسطة بروتوكولات اختبار القياسات الحيوية Android .
- [C-2-3] يجب أن تنفيذ المطابقة الحيوية في بيئة تنفيذ معزولة خارج مستخدم Android أو مساحة kernel ، مثل بيئة التنفيذ الموثوقة (TEE) ،
أوعلى شريحة مع قناة آمنة لبيئة التنفيذ المعزولة أو على محمية الجهاز الظاهري الذي يلبي المتطلبات في القسم 9.17 . - [C-2-4] يجب أن يكون لدى جميع البيانات المحددة مشفرة ومصادقة تشفيرًا بحيث لا يمكن الحصول عليها أو قراءةها أو تغييرها خارج بيئة التنفيذ المعزولة أو شريحة مع قناة آمنة لبيئة التنفيذ المعزولة كما هو موثق في إرشادات التنفيذ على موقع مشروع Android Open Source أو جهاز افتراضي محمي يتحكم فيه Hypervisor الذي يفي بالمتطلبات في القسم 9.17 .
- [C-2-5] لقياسات حيوية قائمة على الكاميرا ، في حين أن المصادقة أو التسجيل القائم على القياس الحيوي تحدث:
- يجب تشغيل الكاميرا في وضع يمنع إطارات الكاميرا من القراءة أو تغييرها خارج بيئة التنفيذ المعزولة أو شريحة مع قناة آمنة لبيئة التنفيذ المعزولة أو جهاز افتراضي محمي يتحكم فيه Hypervisor الذي يفي بالمتطلبات في القسم 9.17 .
- بالنسبة لحلول RGB أحادية الكاميرا ، يمكن قراءة إطارات الكاميرا خارج بيئة التنفيذ المعزولة لدعم عمليات مثل معاينة التسجيل ، ولكن لا يزال يجب تغييرها.
- [C-2-7] يجب ألا يسمح بالوصول غير المشفر إلى بيانات بيومترية قابلة للتحديد أو أي بيانات مستمدة منها (مثل التضمينات) إلى معالج التطبيق خارج سياق TEE أو الجهاز الافتراضي المحمي الذي يتحكم فيه Hypervisor الذي يفي بالمتطلبات في القسم 9.17 . لا يتم إعفاء الأجهزة الترقية التي تم إطلاقها على Android Version 9 أو سابقًا من C-2-7.
إذا كانت تطبيقات الأجهزة ترغب في التعامل مع مستشعر القياس الحيوي على أنه الفئة 3 ( قوية سابقًا) ، فإنها:
- يوصى بشدة [C-SR-16] بوجود معدل قبول محاكاة ساخرة ودجال لا يزيد عن 7 ٪ لكل نوع من أنواع أدوات هجوم العرض (PAI) ، كما تم قياسه بواسطة بروتوكولات اختبار القياسات الحيوية Android .
7.3.13. IEEE 802.1.15.4 (UWB) :
انظر المراجعة
إذا كانت تطبيقات الأجهزة تتضمن دعمًا لـ 802.1.15.4 وفضح الوظيفة لتطبيق طرف ثالث ، فإنهم:
- [C-1-2] يجب الإبلاغ عن علامة الجهاز
android.hardware.uwb
. - [C-1-3] يجب أن يدعم جميع مجموعات التكوين التالية (مجموعات محددة مسبقًا من معلمات Fira UCI ) المحددة في تطبيق AOSP.
-
CONFIG_ID_1
:STATIC STS DS-TWR
ثابت من FIRA ، وضع مؤجل ، فاصل زمني 240 مللي ثانية. -
CONFIG_ID_2
:STATIC STS DS-TWR
من طراز FIRA ، الوضع المؤجل ، يتراوح بين 200 مللي ثانية. حالة الاستخدام النموذجية: يتفاعل الهاتف الذكي مع العديد من الأجهزة الذكية. -
CONFIG_ID_3
: مثلCONFIG_ID_1
، باستثناء بيانات زاوية arnorival (AOA) لم يتم الإبلاغ عنها. -
CONFIG_ID_4
: مثلCONFIG_ID_1
، باستثناء وضع أمان P-STS. -
CONFIG_ID_5
: مثلCONFIG_ID_2
، باستثناء وضع أمان P-STS. -
CONFIG_ID_6
: مثلCONFIG_ID_3
، باستثناء وضع أمان P-STS. -
CONFIG_ID_7
: مثلCONFIG_ID_2
، باستثناء وضع مفتاح Controlee الفردي P-STS.
-
- [C-1-4] يجب أن توفر تكلفة المستخدم للسماح للمستخدم بتبديل حالة/إيقاف تشغيل راديو UWB.
- [C-1-5] يجب أن ينفذ هذا التطبيقات باستخدام راديو UWB عقد إذن
UWB_RANGING
(تحت مجموعة الإذنNEARBY_DEVICES
).
يساعد اجتياز اختبارات المطابقة وإصدار الشهادات ذات الصلة المحددة من قبل المنظمات القياسية ، بما في ذلك FIRA و CCC و CSA على ضمان 802.1.15.4 وظائف بشكل صحيح.
- [C-1-2] يجب الإبلاغ عن علامة الجهاز
انظر المراجعة
"Telephony" كما هو مستخدم من قبل واجهات برمجة تطبيقات Android ، ويشير هذا المستند على وجه التحديد إلى الأجهزة المتعلقة بوضع المكالمات الصوتية وإرسال رسائل SMS ، أو إنشاء بيانات الهاتف المحمول عبر شبكة الهاتف المحمول (مثل GSM ، CDMA ، LTE ، NR) GSM أو CDMA. قد يختار الجهاز الذي يدعم "Telephony" تقديم بعض أو جميع خدمات المكالمات والرسائل والبيانات كما تناسب المنتج.
عبر شبكة GSM أو CDMA. على الرغم من أن هذه المكالمات الصوتية قد تكون أو لا يتم تبديلها ، فهي لأغراض Android التي تعتبر مستقلة عن أي اتصال بيانات يمكن تنفيذها باستخدام نفس الشبكة. بمعنى آخر ، تشير وظيفة Android "Telephony" وواجهة برمجة التطبيقات على وجه التحديد إلى المكالمات الصوتية والرسائل القصيرة. على سبيل المثال ، لا تعتبر تطبيقات الأجهزة التي لا يمكنها إجراء مكالمات أو إرسال/تلقي رسائل SMS جهازًا هاتفيًا ، بغض النظر عما إذا كانت تستخدم شبكة خلوية لاتصال البيانات.انظر المراجعة
إذا كانت تطبيقات الأجهزة تتضمن دعم 802.11 وفضح الوظيفة لتطبيق الطرف الثالث ، فإنها:
- [C-1-4] يجب أن يدعم DNS متعددة البث (MDNs) ويجب ألا ترشح حزم MDNS (224.0.0.251 أو FF02 :: FB ) في أي وقت من التشغيل ، بما في ذلك عندما لا تكون الشاشة في حالة نشطة ، ما لم تسقط أو تسقط أو يعد تصفية هذه الحزم ضروريًا للبقاء ضمن نطاقات استهلاك الطاقة المطلوبة بموجب المتطلبات التنظيمية المطبقة على السوق المستهدفة.
لتطبيقات أجهزة التلفزيون Android ، حتى عندما تكون في حالات الطاقة الاستعداد.
- [C-1-4] يجب أن يدعم DNS متعددة البث (MDNs) ويجب ألا ترشح حزم MDNS (224.0.0.251 أو FF02 :: FB ) في أي وقت من التشغيل ، بما في ذلك عندما لا تكون الشاشة في حالة نشطة ، ما لم تسقط أو تسقط أو يعد تصفية هذه الحزم ضروريًا للبقاء ضمن نطاقات استهلاك الطاقة المطلوبة بموجب المتطلبات التنظيمية المطبقة على السوق المستهدفة.
انظر المراجعة
إذا كانت تطبيقات الجهاز تعلن ميزة _bluetooth_le ، فإنها:
- [C-SR-2] يوصى بشدة بقياس وتعويض إزاحة RX لضمان متوسط RSSI-BLE -60DBM +/- 10 ديسيبل على مسافة 1M من جهاز مرجعي يتم إرساله في
ADVERTISE_TX_POWER_HIGH
، حيث يتم توجيه الأجهزة بحيث تكون كذلك بحيث تكون كذلك. على "الطائرات الموازية" مع شاشات تواجه نفس الاتجاه. - [C-SR-3] ينصح بشدة لقياس وتعويض إزاحة TX لضمان متوسط RSSI-BLE -60DBM +/- 10 ديسيبل عند المسح الضوئي من جهاز مرجعي يتم وضعه على مسافة 1M ونقله في
ADVERTISE_TX_POWER_HIGH
، حيث يتم توجيه الأجهزة بحيث تكون على "طائرات متوازية" مع شاشات تواجه نفس الاتجاه.
- [C-10-3] يجب أن يقيس وتعويض عن إزاحة RX لضمان متوسط RSSI-ble هو -55dbm +/- 10 ديسيبل على مسافة 1M من جهاز مرجعي ينقل في
ADVERTISE_TX_POWER_HIGH
. - [C-10-4] يجب أن يقيس وتعويض إزاحة TX لضمان متوسط RSSI-ble هو -55dbm +/- 10 ديسيبل عند المسح من جهاز مرجعي يتم وضعه على مسافة 1 متر والانتقال في
ADVERTISE_TX_POWER_HIGH
.
إذا كانت تطبيقات الجهاز تدعم إصدار Bluetooth الإصدار 5.0 ، فعندئذٍ:
- [C-SR-4] يوصى بشدة بتوفير الدعم لـ:
- LE 2M PHY
- LE CODEC PHY
- LE Edvertising Extension
- الإعلان الدوري
- ما لا يقل عن 10 مجموعات إعلانات
- ما لا يقل عن 8 اتصالات متزامنة. يمكن أن يكون كل اتصال في أدوار طوبولوجيا الاتصال.
- خصوصية طبقة LE Link
- حجم "القائمة حل" لا يقل عن 8 إدخالات
- [C-SR-2] يوصى بشدة بقياس وتعويض إزاحة RX لضمان متوسط RSSI-BLE -60DBM +/- 10 ديسيبل على مسافة 1M من جهاز مرجعي يتم إرساله في
انظر المراجعة
- يجب أن يضمن [C-1-7] أن متوسط قياسات المسافة عند 1M من الجهاز المرجعي هو ضمن [0.75M ، 1.25M] ، حيث يتم قياس مسافة الحقيقة الأرضية من الحافة العلوية من DUT.
عقدت وجها وميل 45 درجة.
- يجب أن يضمن [C-1-7] أن متوسط قياسات المسافة عند 1M من الجهاز المرجعي هو ضمن [0.75M ، 1.25M] ، حيث يتم قياس مسافة الحقيقة الأرضية من الحافة العلوية من DUT.
7.5.1. الكاميرا الخلفية المواجهة :
انظر المراجعة
الكاميرا الخلفية هي كاميرا تقع على جانب الجهاز مقابل الشاشة ؛ أي أنه مصور مشاهد على الجانب الآخر من الجهاز ، مثل الكاميرا التقليدية.
الكاميرا الخلفية هي كاميرا عالمية تواجه مشاهد على الجانب الآخر من الجهاز ، مثل الكاميرا التقليدية ؛ على الأجهزة المحمولة ، هذه هي الكاميرا الموجودة على جانب الجهاز المقابل للشاشة.
انظر المراجعة
الكاميرا الأمامية هي كاميرا تقع على نفس الجانب من الجهاز مثل الشاشة ؛ وهذا يعني أن الكاميرا تستخدم عادة لتصوير المستخدم ، مثل مؤتمرات الفيديو والتطبيقات المماثلة.
الكاميرا الأمامية هي كاميرا تواجه مستخدم تستخدم عادة لتصوير المستخدم ، مثل مؤتمرات الفيديو والتطبيقات المماثلة ؛ على الأجهزة المحمولة ، هذه هي الكاميرا الموجودة على نفس الجانب من الجهاز مثل الشاشة.
انظر المراجعة
الكاميرا الخارجية عبارة عن كاميرا يمكن إرفاقها جسديًا أو منفصلًا من تطبيق الجهاز في أي وقت ويمكنها مواجهة أي اتجاه ؛ مثل كاميرات USB.
انظر المراجعة
Device implementations MUST implement the following behaviors for the camera-related APIs, for all available cameras. تطبيقات الجهاز:
- [C-SR-1] For devices with multiple RGB cameras in close proximity and facing in the same direction, it is STRONGLY RECOMMENDED to support a logical camera device that lists capability
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
, consisting of all of the RGB cameras facing that direction as physical sub-devices.
- [C-SR-1] For devices with multiple RGB cameras in close proximity and facing in the same direction, it is STRONGLY RECOMMENDED to support a logical camera device that lists capability
See revision
Devices that fulfill all of the following criteria are exempt from the requirement above:
- Device implementations that are not capable of being rotated by the user such as automotive devices.
See revision
Devices intended to be hand-held or worn may include a general purpose haptic actuator, available to applications for purposes including getting attention through ringtones, alarms, notifications, as well as general touch feedback.
If device implementations DO NOT include such a general purpose haptic actuator, they:
- [7.10/C] MUST return false for
Vibrator.hasVibrator()
.
If device implementations DO include at least one such general purpose haptic actuator, they:
- [C-1-1] MUST return true for
Vibrator.hasVibrator()
. - SHOULD NOT use an eccentric rotating mass (ERM) haptic actuator (vibrator).
- SHOULD implement all public constants for clear haptics in
android.view.HapticFeedbackConstants
namely (CLOCK_TICK
,CONTEXT_CLICK
,KEYBOARD_PRESS
,KEYBOARD_RELEASE
,KEYBOARD_TAP
,LONG_PRESS
,TEXT_HANDLE_MOVE
,VIRTUAL_KEY
,VIRTUAL_KEY_RELEASE
,CONFIRM
,REJECT
,GESTURE_START
andGESTURE_END
). - SHOULD implement all public constants for clear haptics in
android.os.VibrationEffect
namely (EFFECT_TICK
,EFFECT_CLICK
,EFFECT_HEAVY_CLICK
andEFFECT_DOUBLE_CLICK
) and all feasible publicPRIMITIVE_*
constants for rich haptics inandroid.os.VibrationEffect.Composition
namely (CLICK
,TICK
,LOW_TICK
,QUICK_FALL
,QUICK_RISE
,SLOW_RISE
,SPIN
,THUD
). Some of these primitives, such asLOW_TICK
andSPIN
may only be feasible if the vibrator can support relatively low frequencies. - SHOULD follow the guidance for mapping public constants in
android.view.HapticFeedbackConstants
to the recommendedandroid.os.VibrationEffect
constants, with the corresponding amplitude relationships. - SHOULD use these linked haptic constants mappings .
- SHOULD follow quality assessment for
createOneShot()
andcreateWaveform()
APIs. - SHOULD verify that the result of the public
android.os.Vibrator.hasAmplitudeControl()
API correctly reflects their vibrator's capabilities. - SHOULD verify the capabilities for amplitude scalability by running
android.os.Vibrator.hasAmplitudeControl()
.
If device implementations follow the haptic constants mapping, they:
- SHOULD verify the implementation status by running
android.os.Vibrator.areAllEffectsSupported()
andandroid.os.Vibrator.arePrimitivesSupported()
APIs. - SHOULD perform a quality assessment for haptic constants.
- SHOULD verify and update if needed the fallback configuration for unsupported primitives as described in the implementation guidance for constants.
- SHOULD provide fallback support to mitigate the risk of failure as described here .
See Section 2.2.1 for device-specific requirements.
- [7.10/C] MUST return false for
9. Security Model Compatibility
See revision
تطبيقات الجهاز:
- [C-0-4] MUST have one and only one implementation of both user interfaces.
If device implementations pre-install any packages that hold any of the System UI Intelligence , System Ambient Audio Intelligence , System Audio Intelligence , System Notification Intelligence , System Text Intelligence , or System Visual Intelligence roles, the packages:
- [C-4-1] MUST fulfill all requirements outlined for device implementations in sections
"9.8.6 Content Capture""9.8.6 OS-level and ambient data and 9.8.15 Sandboxed API implementations".
- [C-4-2] MUST NOT have android.permission.INTERNET permission. This is stricter than the STRONGLY RECOMMENDED listed in section 9.8.6.
- [C-4-3] MUST NOT bind to other apps, except for the following system apps: Bluetooth, Contacts, Media, Telephony, SystemUI, and components providing Internet APIs. This is stricter than the STRONGLY RECOMMENDED listed in section 9.8.6.
If device implementations include a default application to support the
VoiceInteractionService
they:- [C-5-1] MUST NOT grant
ACCESS_FINE_LOCATION
as the default for that application.
See revision
If device implementations create the additional user profile discussed above, then they:
- [C-4-5] MUST visually distinguish the dual instance application icons when the icons are presented to users.
- [C-4-6] MUST provide a user-affordance to delete entire clone profile data.
- [C-4-7] MUST uninstall all Clone apps, delete the private app data directories and their content, and delete Clone profile data, when the user chooses to delete entire Clone profile data.
- SHOULD prompt the user to delete entire Clone Profile data when the last clone app is deleted.
- [C-4-8] MUST inform the user that app data will be deleted when the clone application is uninstalled, or provide an option to users to keep app data when the application is uninstalled from the device.
- [C-4-9] MUST delete the private app data directories and their content, when the user chooses to delete the data during uninstall.
[C-4-1] MUST allow the below intents originating from the additional profile to be handled by applications of the primary user on the device:
-
Intent.ACTION_VIEW
-
Intent.ACTION_SENDTO
-
Intent.ACTION_SEND
-
Intent.ACTION_EDIT
-
Intent.ACTION_INSERT
-
Intent.ACTION_INSERT_OR_EDIT
-
Intent.ACTION_SEND_MULTIPLE
-
Intent.ACTION_PICK
-
Intent.ACTION_GET_CONTENT
-
MediaStore.ACTION_IMAGE_CAPTURE
-
MediaStore.ACTION_VIDEO_CAPTURE
-
[C-4-2] MUST inherit all device policy user restrictions and selected non-user restrictions(list below) applied on the primary user of the device to this additional user profile.
[C-4-3] MUST only allow writing contacts from this additional profile via the following intents:
[C-4-4] MUST NOT have contact syncs running for applications running in this additional user profile.
- [C-4-14] MUST have separate permission and storage management for the applications running in this additional profile
- [C-4-5] MUST only allow applications in the additional profile that have a launcher activity to access contacts that are already accessible to the parent user profile.
See revision
A Memory Safety technology is a technology that mitigates at least the following classes of bugs with a high (> 90%) probability in applications that use the
android:memtagMode
manifest option:- heap buffer overflow
- use after free
- double free
- wild free (free of a non-malloc pointer)
تطبيقات الجهاز:
- [C-SR-15] Are STRONGLY RECOMMENDED to set
ro.arm64.memtag.bootctl_supported
.
If device implementations set the system property
ro.arm64.memtag.bootctl_supported
to true, they:[C-3-1] MUST allow the system property
arm64.memtag.bootctl
to accept a comma-separated list of the following values, with the desired effect applied on the next subsequent reboot:-
memtag
: a Memory Safety technology as defined above is enabled -
memtag-once
: a Memory Safety technology as defined above is transiently enabled, and is automatically disabled upon, next reboot -
memtag-off
: a Memory Safety technology as defined above is disabled
-
[C-3-2] MUST allow the shell user to set
arm64.memtag.bootctl
.[C-3-3] MUST allow any process to read
arm64.memtag.bootctl
.[C-3-4] MUST set
arm64.memtag.bootctl
to the currently requested state upon boot, it MUST also update the property, if the device implementation allows to modify the state without changing the system property.[C-SR-16] Are STRONGLY RECOMMENDED to show a Developer Setting that sets memtag-once and reboots the device. With a compatible bootloader, the Android Open Source Project meets the above requirements through the MTE bootloader protocol .
- [C-SR-17] Are STRONGLY RECOMMENDED to show a Setting in the Security Settings menu that allows the user to enable
memtag
.
See revision
تطبيقات الجهاز:
- [C-0-2] MUST display a user warning and obtain explicit user consent allowing any sensitive information that is displayed on the user's screen to be captured
enabled that includes exactly the same message as AOSPwhenevereach and every time a session to capture the screencasting or screen recordingisenabledstarted via theMediaProjection.createVirtualDisplay()
,VirtualDeviceManager.createVirtualDisplay()
, or proprietary APIs.MUST NOT provide users an affordance to disable future display of the user consent.
[C-SR-1] Are STRONGLY RECOMMENDED to display a user warning which is exactly the same message as implemented in AOSP but CAN be altered as long as the message clearly warns the user that any sensitive information on the user's screen is captured.
[C-0-4] MUST NOT provide users an affordance to disable future prompts of the user consent to capture the screen, unless the session is started by a system app that the user has allowed to
associate()
with theandroid.app.role.COMPANION_DEVICE_APP_STREAMING
or theandroid.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMING
device profile.
- [C-0-2] MUST display a user warning and obtain explicit user consent allowing any sensitive information that is displayed on the user's screen to be captured
9.8.6. OS-level and ambient data : This section was renamed from Content Capture and App Search to OS-level and ambient data .
See revision
Android, through the System APIs
, supports a mechanism for device implementations to capture the followingContentCaptureService
,AugmentedAutofillService
,AppSearchGlobalManager.query
, or by other proprietary meansapplication data interactions between the applications and the usersensitive data :- Any screen or other data sent via the
AugmentedAutofillService
to the system. - Any screen or other data accessible via
Content Capture
API. - Any screen or other data accessible via
FieldClassificationService
API - Any application data passed to the system via the
AppSearchManager
API and accessible viaAppSearchGlobalManager.query
.
- Any other events that an application provides to the system via the
Content Capture
API or orAppSearchManager
API a similarly capable Android and proprietary API.
- Audio data obtained as a result of using
SpeechRecognizer#onDeviceSpeechRecognizer()
by the Speech Recognizer Implementation. - Audio data obtained in background (continuously) through
AudioRecord
,SoundTrigger
or other Audio APIs, and not resulting in a user-visible indicator - Camera data obtained in background (continuously) through CameraManager or other Camera APIs, and not resulting in a user-visible indicator
If device implementations capture any of the data above, they:
[C-1-3] MUST only send all such data
and the logoff the device using a privacy-preserving mechanism , except with explicit user consent every time the data is shared . The privacy-preserving mechanism is defined as “those which allow only analysis in aggregate and prevent matching of logged events or derived outcomes to individual users”, to prevent any per-user data being introspectable (eg, implemented using a differential privacy technology such asRAPPOR
).[C-1-5] MUST NOT share such data with other OS components that don't follow requirements outlined in the current section (9.8.6
Content CaptureOS-level and ambient data ), except with explicit user consent every time it is مشترك. Unless such functionality is built as an Android SDK API (AmbientContext
,HotwordDetectionService
).[C-1-6] MUST provide user affordance to erase such data that the
implementation or the proprietary means collectsContentCaptureService
ifwhen the data is stored in any form on the device. If the user chooses to erase the data, MUST remove all collected historical data.
- [C-SR-3] Are STRONGLY RECOMMENDED to be implemented with Android SDK API or a similar OEM-owned open-source repository; and / or be performed in a Sandboxed implementation (see 9.8.15 Sandboxed API implementations).
Android, through
SpeechRecognizer#onDeviceSpeechRecognizer()
provides ability to perform speech recognition on the device, without involving the network. Any implementation of on-device SpeechRecognizer MUST follow the policies outlined in this section.- Any screen or other data sent via the
9.8.10. Connectivity Bug Report :
See revision
If device implementations declare the
android.hardware.telephony
feature flag, they:- [C-1-4] Reports generated using
BUGREPORT_MODE_TELEPHONY
MUST contain at least the following information:-
SubscriptionManagerService
dump
-
- [C-1-4] Reports generated using
9.8.14. Credential Manager : Removed
9.8.15. Sandboxed API Implementations : New section
See revision
Android, through a set of delegate APIs provides a mechanism to process secure OS-level and ambient data. Such processing can be delegated to a preinstalled apk with privileged access and reduced communication capabilities, known as a Sandboxed API Implementation.
Any Sandboxed API implementation:
- [C-0-1] MUST NOT request the INTERNET permission.
- [C-0-2] MUST only access the internet through structured APIs backed by publicly available open-source implementations using privacy-preserving mechanisms, or indirectly via Android SDK APIs. The privacy-preserving mechanism is defined as "those which allow only analysis in aggregate and prevent matching of logged events or derived outcomes to individual users", to prevent any per-user data being introspectable (eg, implemented using a differential privacy technology such as RAPPOR ).
- [C-0-3] MUST keep the services separate from other system components (eg not binding the service or sharing process IDs) except for the following:
- Telephony, Contacts, System UI, and Media
- [C-0-4] MUST NOT allow users to replace the services with a user-installable application or service
- [C-0-5] MUST only allow the preinstalled services to capture such data. Unless the replacement capability is built into AOSP (eg for Digital Assistant Apps).
- [C-0-6] MUST NOT allow any apps other than the preinstalled services mechanism to be able to capture such data. Unless such capture capability is implemented with an Android SDK API.
- [C-0-7] MUST provide user affordance to disable the services.
- [C-0-8] MUST NOT omit user affordance to manage Android permissions that are held by the services and follow the Android permissions model as described in Section 9.1. إذن .
9.8.16. Continuous Audio and Camera data : New section
See revision
In addition to requirements outlined in 9.8.2 Recording, 9.8.6 OS-level and ambient data, and 9.8.15 Sandboxed API implementations, implementations that make use of Audio data obtained in background (continuously) through AudioRecord, SoundTrigger or other Audio APIs OR Camera data obtained in background (continuously) through CameraManager or other Camera APIs:
- [C-0-1] MUST enforce a corresponding indicator (camera and/or microphone as per section 9.8.2 Recording), unless:
- This access is performed in a Sandboxed implementation (see 9.8.15 Sandboxed API implementation), through a package holding one or more of the following roles: System UI Intelligence , System Ambient Audio Intelligence , System Audio Intelligence , System Notification Intelligence , System Text Intelligence , or System Visual Intelligence .
- The access is performed through a sandbox, implemented and enforced via mechanisms in AOSP (
HotwordDetectionService
,WearableSensingService
,VisualQueryDetector
). - Audio access is performed for assistive purposes by the Digital Assistant application, supplying
SOURCE_HOTWORD
as an audio source. - The access is performed by the system and implemented with open-source code.
- [C-SR-1] Is STRONGLY RECOMMENDED to require user consent for every functionality utilizing such data, and be disabled by default.
- [C-SR-2] STRONGLY RECOMMENDED to apply the same treatment (ie follow the restrictions outlined in 9.8.2 Recording, 9.8.6 OS-level and ambient data, 9.8.15 Sandboxed API implementations, and 9.8.16 Continuous Audio and Camera data) to Camera data coming from a remote wearable device.
If the Camera data is supplied from a remote wearable device and accessed in an unencrypted form outside Android OS, sandboxed implementation or a sandboxed functionality built by
WearableSensingManager
, then they:- [C-1-1] MUST indicate to the remote wearable device to display an additional indicator there.
If devices provide capability to engage with a Digital Assistant Application without the assigned keyword (either handling generic user queries, or analyzing user presence through camera):
- [C-2-1] MUST ensure such implementation is provided by a package holding the
android.app.role.ASSISTANT
role. - [C-2-2] MUST ensure such implementation utilizes
HotwordDetectionService
and/orVisualQueryDetectionService
Android APIs.
- [C-0-1] MUST enforce a corresponding indicator (camera and/or microphone as per section 9.8.2 Recording), unless:
9.8.17. Telemetry : New section
See revision
Android stores system and app logs using StatsLog APIs. These logs are managed via StatsManager APIs which can be used by privileged system applications.
StatsManager also provides a way to collect data categorized as privacy sensitive from devices with a privacy preserving mechanism. In particular,
StatsManager::query
API provides the ability to query restricted metric categories defined in StatsLog .Any implementation querying and collecting restricted metrics from StatsManager:
- [C-0-1] MUST be the sole application/implementation on the device and hold the
READ_RESTRICTED_STATS
permission. - [C-0-2] MUST only send telemetry data and the log of the device using a privacy-preserving mechanism. The privacy-preserving mechanism is defined as "those which allow only analysis in aggregate and prevent matching of logged events or derived outcomes to individual users", to prevent any per-user data being introspectable (eg, implemented using a differential privacy technology such as RAPPOR ).
- [C-0-3] MUST NOT associate such data with any user identity (such as Account ) on the device.
- [C-0-4] MUST NOT share such data with other OS components that don't follow requirements outlined in the current section (9.8.17 Privacy-preserving Telemetry).
- [C-0-5] MUST provide a user affordance to enable/disable privacy-preserving telemetry collection, use, and sharing.
- [C-0-6] MUST provide user affordance to erase such data that the implementation collects if the data is stored in any form on the device. If the user chose to erase the data, MUST remove all data currently stored on the device.
- [C-0-7] MUST disclose underlying privacy-preserving protocol implementation in an open source repository.
- [C-0-8 ]MUST enforce data egress policies in this section to gate collection of data in restricted metric categories defined in StatsLog .
- [C-0-1] MUST be the sole application/implementation on the device and hold the
See revision
Device implementationsIf device implementations have the ability to verify file content on the per-page basis, then they :
[
C-0-3C-2-1 ] support cryptographically verifying file contentagainst a trusted keywithout reading the whole file.[
C-0-4C-2-2 ] MUST NOT allow the read requests on a protected file to succeed when the read contentdo not verify against a trusted keyis not verified per [C-2-1] above .
- [C-2-4] MUST return file checksum in O(1) for enabled files.
See revision
The Android Keystore System allows app developers to store cryptographic keys in a container and use them in cryptographic operations through the KeyChain API or the Keystore API . تطبيقات الجهاز:
- [C-0-3] MUST limit the number of failed primary authentication attempts.
- [C-SR-2] Are STRONGLY RECOMMENDED to implement an upper bound of 20 failed primary authentication attempts and if users consent and opt-in the feature, perform a "Factory Data Reset" after exceeding the limit of failed primary authentication attempts.
If device implementations add or modify the authentication methods to unlock the lock screen if based on a known secret and use a new authentication method to be treated as a secure way to lock the screen, then:
- [C-SR-3] A PIN is STRONGLY RECOMMENDED to have at least 6 digits, or equivalently a 20-bit entropy.
- [C-2-1] A PIN of a length less than 6 digits MUST NOT allow automatic entry without user interaction to avoid revealing the PIN length.
9.11.1. Secure Lock Screen, Authentication and Virtual Devices :
See revision
تطبيقات الجهاز:
- [C-0-1] MUST limit the number of failed primary authentication attempts.
- [C-SR-5] Are STRONGLY RECOMMENDED to implement an upper bound of 20 failed primary authentication attempts and if users consent and opt-in the feature, perform a "Factory Data Reset" after exceeding the limit of failed primary authentication attempts.
If device implementations set a numerical PIN as the recommended primary authentication method, then:
- [C-SR-6] A PIN is STRONGLY RECOMMENDED to have at least 6 digits, or equivalently a 20-bit entropy.
- [C-SR-7] A PIN of a length less than 6 digits is STRONGLY RECOMMENDED NOT to allow automatic entry without user interaction to avoid revealing the PIN length.
If device implementations have a secure lock screen and include one or more trust agent, which implements the
TrustAgentService
System API, they:[C-7-8] The user MUST be challenged for one of the recommended primary authentication (eg: PIN, pattern, password) methods at least once every 72 hours or less unless the safety of the user (eg driver distraction) is of هَم.If device implementations allow applications to create secondary virtual displays and support associated input events such as via VirtualDeviceManager and the displays are not marked with VIRTUAL_DISPLAY_FLAG_SECURE, they:
[C-13-10] MUST disable installation of apps initiated from virtual devices.9.17. Android Virtualization Framework :
See revision
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*
), the Android host:- [C-1-1] MUST support all the APIs defined by the
android.system.virtualmachine
package. - [C-1-2] MUST NOT modify the Android SELinux and permission model for the management of Protected Virtual Machines (pVM) .
- [C-1-3] MUST NOT modify, omit, or replace the neverallow rules present within the system/sepolicy provided in the upstream Android Open Source Project (AOSP) and the policy MUST compile with all neverallow rules present.
- [C-1-4] MUST only allow platform signed code & privileged apps
MUST NOT allow untrusted code (eg 3p apps)to create and run aProtected Virtual MachinepVM . Note: This might change in future Android releases.
- [C-1-5] MUST NOT allow a
Protected Virtual MachinepVM to execute code that is not part of the factory image or their updates.Anything that is not covered by Android Verified Boot (eg files downloaded from the Internet or sideloaded) MUST NOT be allowed to be run in a Protected Virtual Machine.
- [C-1-5] MUST only allow a non-debuggable pVM to execute code from the factory image or their platform updates which also includes any updates to privileged apps.
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*
), then anyProtected Virtual MachinepVM instance:- [C-2-1] MUST be able to run all operating systems available in the virtualization APEX in a
Protected Virtual MachinepVM . - [C-2-2] MUST NOT allow a
Protected Virtual MachinepVM to run an operating system that is not signed by the device implementor or OS vendor. - [C-2-3] MUST NOT allow a
Protected Virtual MachinepVM to execute data as code (eg SELinux neverallow execmem).
- [C-2-4] MUST NOT modify, omit, or replace the neverallow rules present within the system/sepolicy/microdroid provided in the upstream Android Open Source Project (AOSP).
- [C-2-5] MUST implement
Protected Virtual MachinepVM defense-in-depth mechanisms (eg SELinux for pVMs) even for non-Microdroid operating systems. - [C-2-6] MUST ensure that the pVM fails
firmware refusesto boot ifit cannot verify the initialimages that the VM will run cannot be verified. The verification MUST be done inside the VM. - [C-2-7] MUST ensure that the pVM fails
firmware refusesto boot if the integrity of the instance.img is compromised.
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*
), then the hypervisor:- [C-3-1] MUST ensure that memory pages exclusively owned by a VM (either pVM or host VM) are accessible only to the virtual machine itself or the hypervisor, not by other virtual machines - either protected or non-protected.
MUST NOT allow any pVM to have access to a page belonging to another entity (ie other pVM or hypervisor), unless explicitly shared by the page owner. This includes the host VM. This applies to both CPU and DMA accesses. - [C-3-2] MUST wipe a page after it is used by a pVM and before it is returned to the host (eg the pVM is destroyed).
- [C-
3-3SR-1 ] Is STRONGLY RECOMMENDED to ensureMUST ensurethat that the pVM firmware is loaded and executed prior to any code in a pVM. - [C-3-4] MUST ensure that each VM derives a per-VM secret which
{Boot Certificate Chain (BCC) and Compound Device Identifier (CDIs) provided to a pVM instancecan only be derived by that particular VM instance and changes upon factory reset and OTA.
If the device implements support for the Android Virtualization Framework APIs, then across all areas:
- [C-4-1] MUST NOT provide functionality to a pVM that allows bypassing the Android Security Model.
If the device implements support for the Android Virtualization Framework APIs, then:
- [C-5-1] MUST be capable to support Isolated Compilation but may disable Isolated Compilation feature on the device shipment
of an ART runtime update.
If the device implements support for the Android Virtualization Framework APIs, then for Key Management:
- [C-6-1] MUST root DICE chain at a point that the user cannot modify, even on unlocked devices. (To ensure it cannot be spoofed).
- [C- SR-2
6-2] Is STRONGLY RECOMMENDED to use DICE as the per-VM secret derivation mechanism.MUST do DICE properly ie provide the correct values.
- [C-1-1] MUST support all the APIs defined by the