سجل تغيير مستند تعريف توافق Android

تنظيم صفحاتك في مجموعات يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.

أندرويد 13

19 أكتوبر 2022

2. أنواع الأجهزة

  • 2.2.3 البرمجيات

    انظر المراجعة

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

    • [3.8.17 / H-1-1] يجب أن يقدم تأكيدًا للمستخدم بأن البيانات قد تم نسخها إلى الحافظة (على سبيل المثال ، صورة مصغرة أو تنبيه "تم نسخ المحتوى".). بالإضافة إلى ذلك ، قم هنا بتضمين إشارة إلى ما إذا كانت بيانات الحافظة ستتم مزامنتها عبر الأجهزة.

3. البرمجيات

  • 3.2.3.5. نوايا التطبيق الشرطي

    انظر المراجعة

    إذا كان تطبيق إعدادات تنفيذ الجهاز ينفذ وظيفة مقسمة ، باستخدام تضمين النشاط ، فإنهم:

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

  • 3.4.1 التوافق مع Webview

    انظر المراجعة

    • [C-1-4] يجب أن يعرض "المحتوى المقدم أو محتوى عنوان URL البعيد في عملية تختلف عن التطبيق الذي ينشئ WebView. على وجه التحديد ، يجب أن تحتفظ عملية العارض المنفصلة بامتيازات أقل ، وأن تعمل كمعرف مستخدم منفصل ، ولا تتمتع بإمكانية الوصول إلى دليل بيانات التطبيق ، ولا تتمتع بوصول مباشر إلى الشبكة ، ولا تتمتع إلا بالوصول إلى الحد الأدنى من خدمات النظام المطلوبة عبر Binder. يلبي تطبيق AOSP لـ WebView هذا المطلب.

7. توافق الأجهزة

  • 7.4.2 IEEE 802.11 (Wi-Fi)

    انظر المراجعة

    إذا تضمنت تطبيقات الجهاز دعمًا لوضع توفير طاقة Wi-Fi على النحو المحدد في معيار IEEE 802.11 ، فإنها:

  • 7.4.3 بلوتوث

    انظر المراجعة

    إذا تضمنت تطبيقات الجهاز دعم Bluetooth منخفض الطاقة (BLE) ، فإنها:

    • [C-3-5] يجب أن تنفذ مهلة العنوان الخاص القابل للحل (RPA) لمدة لا تزيد عن 15 دقيقة وتدوير العنوان في المهلة لحماية خصوصية المستخدم عندما يستخدم الجهاز BLE بشكل نشط للمسح أو الإعلان. لمنع هجمات التوقيت ، يجب أيضًا اختيار فترات المهلة بشكل عشوائي بين 5 و 15 دقيقة.

  • 7.5.5 اتجاه الكاميرا

    انظر المراجعة

    إذا كانت تطبيقات الجهاز تحتوي على كاميرا أمامية أو خلفية ، فإن هذه الكاميرا (الكاميرات):

    • [C-1-1] يجب أن تكون موجهة بحيث يتماشى البعد الطويل للكاميرا مع البعد الطويل للشاشة. أي عندما يكون الجهاز في الاتجاه الأفقي ، يجب أن تلتقط الكاميرات الصور في الاتجاه الأفقي. ينطبق هذا بغض النظر عن الاتجاه الطبيعي للجهاز ؛ أي أنه ينطبق على الأجهزة ذات المناظر الطبيعية الأساسية وكذلك الأجهزة الرأسية الأساسية.

    الأجهزة التي تستوفي جميع المعايير التالية معفاة من المتطلبات المذكورة أعلاه:

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

9. التوافق مع نموذج الأمان

  • 9.11 المفاتيح وبيانات الاعتماد

    انظر المراجعة

    عندما يدعم تنفيذ الجهاز شاشة قفل آمنة ، فإنه:

    • [C-1-6] يجب أن يدعم IKeymasterDevice 4.0 ، IKeymasterDevice 4.1 ، IKeyMintDevice الإصدار 1 أو IKeyMintDevice الإصدار 2.

  • 9.17 إطار عمل المحاكاة الافتراضية لنظام Android

    انظر المراجعة

    إذا كان الجهاز يطبق دعمًا لواجهات برمجة تطبيقات Android Virtualization Framework ( android.system.virtualmachine.* ) ، فإن مضيف Android:

    • [C-1-3] يجب ألا تعدل أو تحذف أو تستبدل القواعد "أبدًا" الموجودة في النظام / سياسة الفصل المقدمة في مشروع Android مفتوح المصدر (AOSP) ويجب أن يتم تجميع السياسة مع جميع القواعد الموجودة على الإطلاق.

    إذا كان الجهاز يطبق دعمًا لواجهات برمجة تطبيقات Android Virtualization Framework ( android.system.virtualmachine.* ) ، فإن أي مثيل جهاز ظاهري محمي:

    • [C-2-4] يجب ألا تعدل أو تحذف أو تستبدل القواعد التي لا تسمح مطلقًا الموجودة داخل النظام / sepolicy / microdroid المتوفرة في مشروع Android مفتوح المصدر (AOSP).

    إذا كان الجهاز يطبق دعمًا لواجهات برمجة تطبيقات Android Virtualization Framework ، فعندئذٍ لإدارة المفاتيح:

    • [C-6-2] يجب أن تفعل DICE بشكل صحيح ، أي توفير القيم الصحيحة. لكنها قد لا تضطر إلى الذهاب إلى هذا المستوى من التفاصيل.

15 أغسطس 2022

2. أنواع الأجهزة

  • 2.2.1 الأجهزة : تغييرات على متطلبات الأجهزة على النحو التالي.

    • أجهزة إدخال:

      انظر المراجعة

      تطبيقات الجهاز المحمول:

      • [ 7.2 .3 / H-0-5] يجب استدعاء OnBackInvokedCallback.onBackStarted() على النافذة المركزة الحالية عند بدء إيماءة الرجوع أو الضغط على زر الرجوع ( KEYCODE_BACK ) لأسفل.
      • [ 7.2 .3 / H-0-6] يجب استدعاء OnBackInvokedCallback.onBackInvoked() عند تنفيذ إيماءة الرجوع أو تحرير زر الرجوع (UP).
      • [ 7.2 .3 / H-0-7] يجب استدعاء OnBackInvokedCallback.onBackCancelled() عندما لا يتم الالتزام بإيماءة الرجوع أو يتم إلغاء الحدث KEYCODE_BACK .

      إذا كانت الأجهزة تدعم بروتوكول WiFi Neighbor Awareness Networking (NAN) من خلال الإعلان عن PackageManager.FEATURE_WIFI_AWARE وموقع Wi-Fi (Wi-Fi Round Trip Time - RTT) من خلال الإعلان عن PackageManager.FEATURE_WIFI_RTT ، فإنهم:

      • [ 7.4 .2.5 / H-1-1] يجب الإبلاغ عن النطاق بدقة في حدود +/- متر واحد عند عرض نطاق 160 ميجا هرتز عند النسبة المئوية 68 (كما تم حسابه باستخدام وظيفة التوزيع التراكمي) ، +/- 2 متر عند عرض النطاق الترددي 80 ميجا هرتز عند النسبة المئوية 68 ، +/- 4 أمتار عند عرض النطاق الترددي 40 ميجاهرتز عند النسبة المئوية 68 ، و +/- 8 أمتار عند عرض النطاق الترددي 20 ميجاهرتز عند النسبة المئوية 68 على مسافات 10 سم ، و 1 م ، و 3 م ، و 5 م ، مثل لوحظ عبر WifiRttManager # startRanging Android API .

      • [ 7.4 .2.5 / H-SR] يُنصح بشدة بالإبلاغ عن النطاق بدقة ضمن +/- متر واحد عند عرض النطاق الترددي 160 ميجاهرتز عند النسبة المئوية التسعين (كما تم حسابه باستخدام وظيفة التوزيع التراكمي) ، +/- 2 متر عند 80 ميجاهرتز عرض النطاق الترددي عند النسبة المئوية 90 ، +/- 4 أمتار عند عرض النطاق الترددي 40 ميجاهرتز عند النسبة المئوية 90 ، و +/- 8 أمتار عند عرض النطاق الترددي 20 ميجاهرتز عند النسبة المئوية التسعين على مسافات 10 سم ، كما لوحظ عبر WifiRttManager # startRanging Android API .

      يوصى بشدة باتباع خطوات إعداد القياس المحددة في متطلبات معايرة الحضور .

    • زمن انتقال الصوت:

      انظر المراجعة

      إذا أعلنت تطبيقات الأجهزة المحمولة عن android.hardware.audio.output و android.hardware.microphone ، فإنها:

      • [ 5.6 / H-1-1] يجب أن يكون متوسط ​​زمن انتقال ذهابًا وإيابًا مستمرًا يبلغ 500 800 مللي ثانية أو أقل على 5 قياسات ، بمتوسط ​​انحراف مطلق أقل من 50 100 مللي ثانية ، عبر مسارات البيانات التالية: "مكبر صوت إلى ميكروفون" ، محول استرجاع 3.5 مم (إذا كان مدعومًا) ، استرجاع USB (إذا كان مدعومًا). مسار واحد مدعوم على الأقل.

      • [ 5.6 / H-1-1] يجب أن يكون متوسط ​​زمن انتقال النقر للنغمة 500 مللي ثانية أو أقل خلال 5 قياسات على الأقل عبر السماعة إلى مسار بيانات الميكروفون.

    • المدخلات اللمسية:

      انظر المراجعة

      إذا اشتملت تطبيقات الأجهزة المحمولة باليد على مشغل لمسي واحد على الأقل ، فإنها:

      • [ 7.10 / H] * يجب ألا تستخدم محركًا لمسيًا (هزاز).
      • [ 7.10 / H] * يجب وضع موضع المشغل بالقرب من الموقع حيث يتم عادةً إمساك الجهاز أو لمسه باليدين.
      • [ 7.10 / H] * يجب تنفيذ جميع الثوابت العامة لملامسات واضحة في android.view.HapticFeedbackConstants وهي (CLOCK_TICK و CONTEXT_CLICK و KEYBOARD_PRESS و KEYBOARD_RELEASE و KEYBOARD_TAP و LONG_PRESS و TEXT_HANDLE_MOVTURE و VESTURE
      • [ 7.10 / H] * ينبغي تنفيذ جميع الثوابت العامة لملامسات واضحة في android.os.VibrationEffect وهي (EFFECT_TICK و EFFECT_CLICK و EFFECT_HEAVY_CLICK و EFFECT_DOUBLE_CLICK) وجميع الثوابت العامة الممكنة PRIMITIVE_* لملامسات غنية في android.os.VibrationEffect.Comect . (PRIMITIVE_CLICK و PRIMITIVE_TICK) (CLICK ، TICK ، LOW_TICK ، QUICK_FALL ، QUICK_RISE ، SLOW_RISE ، SPIN ، THUD). قد تكون بعض هذه العناصر الأولية ، مثل LOW_TICK و SPIN ممكنة فقط إذا كان بإمكان الهزاز دعم الترددات المنخفضة نسبيًا.

      • [ 7.10 / H] * يجب استخدام تعيينات الثوابت اللمسية المرتبطة.

      إذا اشتملت تطبيقات الأجهزة المحمولة باليد على مشغل طنين خطي واحد على الأقل ، فإنها:

      • [ 7.10 / H] * يجب أن يحرك المشغل اللمسي في المحور X (من اليسار إلى اليمين) للاتجاه الرأسي.

      • [ 7.10 / H] * يجب التحقق والتحديث إذا لزم الأمر التكوين الاحتياطي للأوليات غير المدعومة كما هو موضح في إرشادات التنفيذ للثوابت.

      • [7.10 / H] * يجب تقديم دعم احتياطي لتقليل مخاطر الفشل كما هو موضح هنا .

  • 2.2.3 البرمجيات :

    • مصادقة Cotntrols جهاز تافه:

      انظر المراجعة

      • [ 3.8 .16 / H-1-5] يجب أن يوفر للمستخدم إمكانية الانسحاب Control.isAuthRequired عناصر التحكم في الجهاز التافهة المخصصة للتطبيق من عناصر التحكم المسجلة بواسطة تطبيقات الطرف الثالث من خلال ControlsProviderService و Control API.

    • إخطارات MediaStyle:

      انظر المراجعة

      إذا كانت تطبيقات الأجهزة المحمولة تدعم إشعارات MediaStyle فإنها:

      • [3.8.3.1/H-1-SR] يوصى بشدة بتوفير تكلفة للمستخدم (على سبيل المثال "محول الإخراج") يتم الوصول إليها من واجهة مستخدم النظام التي تسمح للمستخدمين بالتبديل بين مسارات الوسائط المتاحة المناسبة (مثل أجهزة البلوتوث والمسارات المقدمة إلى MediaRouter2Manager ) عندما ينشر أحد التطبيقات إشعار MediaStyle برمز MediaSession .

  • 2.2.4 الأداء والقوة : مطلب جديد للتطبيقات التي تشغل خدمات في المقدمة.

    انظر المراجعة

    تطبيقات الجهاز المحمول:

    • يجب أن يوفر [ 8.5 / H-0-1] رسومًا للمستخدم في قائمة الإعدادات مع القدرة على إيقاف تطبيق يقوم بتشغيل خدمة مقدمة وعرض جميع التطبيقات التي تحتوي على خدمات مقدمة نشطة ومدة كل خدمة من هذه الخدمات منذ ذلك الحين بدأت كما هو موضح في مستند SDK .
      • قد يتم إعفاء بعض التطبيقات من أن يتم إيقافها أو إدراجها في منحة المستخدم كما هو موضح في مستند SDK .

  • 2.2.7.1 الوسائط : تحديثات قسم وسائط المتطلبات المحمولة على النحو التالي:

    انظر المراجعة

    إذا أعادت تطبيقات الأجهزة المحمولة باليد android.os.Build.VERSION_CODES.T لـ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS ، فإنها:

    • يجب أن يعلن [5.1 / H-1-1] عن الحد الأقصى لعدد جلسات وحدة فك ترميز فيديو الأجهزة التي يمكن تشغيلها بشكل متزامن في أي مجموعة ترميز عبر أساليب CodecCapabilities.getMaxSupportedInstances() و VideoCapabilities.getSupportedPerformancePoints() .
    • [5.1 / H-1-2] يجب أن تدعم 6 مثيلات لجلسات وحدة فك ترميز فيديو الأجهزة (AVC ، HEVC ، VP9 ، AV1 أو أحدث) في أي مجموعة ترميز تعمل بشكل متزامن بدقة 1080 بكسل @ 30 إطارًا في الثانية.
    • يجب أن تعلن [5.1 / H-1-3] عن الحد الأقصى لعدد جلسات تشفير فيديو الأجهزة التي يمكن تشغيلها بشكل متزامن في أي مجموعة ترميز عبر أساليب CodecCapabilities.getMaxSupportedInstances() و VideoCapabilities.getSupportedPerformancePoints() .
    • [5.1 / H-1-4] يجب أن تدعم 6 مثيلات لجلسات تشفير فيديو الأجهزة (AVC ، HEVC ، VP9 ، AV1 أو أحدث) في أي مجموعة ترميز تعمل بشكل متزامن بدقة 1080 بكسل @ 30 إطارًا في الثانية.
    • يجب أن تعلن [5.1 / H-1-5] عن الحد الأقصى لعدد جلسات وحدة تشفير الفيديو وفك التشفير التي يمكن تشغيلها بشكل متزامن في أي مجموعة ترميز عبر CodecCapabilities.getMaxSupportedInstances() و VideoCapabilities.getSupportedPerformancePoints() .
    • [5.1 / H-1-6] يجب أن تدعم 6 مثيلات لوحدة فك ترميز فيديو الأجهزة وجلسات تشفير فيديو الأجهزة (AVC ، HEVC ، VP9 ، AV1 أو أحدث) في أي مجموعة ترميز تعمل بشكل متزامن بدقة 1080p @ 30fps.
    • [5.1 / H-1-7] يجب أن يكون وقت استجابة برنامج الترميز 40 مللي ثانية أو أقل لجلسة تشفير فيديو 1080 بكسل أو أصغر لجميع أجهزة تشفير الفيديو عند التحميل. يُعرَّف التحميل هنا بأنه جلسة تحويل ترميز فيديو فقط من 1080p إلى 720p متزامنة باستخدام برامج ترميز الفيديو للأجهزة مع تهيئة تسجيل الصوت والفيديو 1080 بكسل.
    • [5.1 / H-1-8] يجب أن يكون وقت استجابة برنامج الترميز 30 مللي ثانية أو أقل لجلسة تشفير صوت بمعدل بتات 128 كيلوبت في الثانية أو أقل لجميع مشفرات الصوت عند التحميل. يُعرَّف التحميل هنا بأنه جلسة تحويل ترميز فيديو فقط من 1080p إلى 720p متزامنة باستخدام برامج ترميز الفيديو للأجهزة مع تهيئة تسجيل الصوت والفيديو 1080 بكسل.
    • يجب أن يدعم [5.1 / H-1-9] مثيلين من جلسات فك تشفير فيديو الأجهزة الآمنة (AVC ، HEVC ، VP9 ، AV1 أو أحدث) في أي مجموعة ترميز تعمل بشكل متزامن بدقة 1080 بكسل بمعدل 30 إطارًا في الثانية.
    • [5.1 / H-1-10] يجب أن تدعم 3 مثيلات من جلسات فك تشفير فيديو الأجهزة غير الآمنة جنبًا إلى جنب مع مثيل واحد من جلسة فك تشفير فيديو الأجهزة الآمنة (إجمالي 4 مثيلات) (AVC ، HEVC ، VP9 ، AV1 أو أحدث) في أي برنامج ترميز تركيبة تعمل بشكل متزامن بدقة 1080 بكسل @ 30 إطارًا في الثانية.
    • يجب أن يدعم [5.1 / H-1-11] وحدة فك ترميز آمنة لكل جهاز فك ترميز AVC أو HEVC أو VP9 أو AV1 على الجهاز.
    • [5.1 / H-1-12] يجب أن يكون وقت استجابة مفكك تشفير الفيديو 40 مللي ثانية أو أقل.
    • [5.1 / H-1-13] يجب أن يكون وقت استجابة مفكك تشفير الصوت 30 مللي ثانية أو أقل.
    • [5.1 / H-1-14] يجب أن تدعم وحدة فك ترميز الأجهزة AV1 Main 10 ، المستوى 4.1.
    • ينصح بشدة [5.1 / H-SR] لدعم Film Grain لوحدة فك ترميز أجهزة AV1.
    • [5.1 / H-1-15] يجب أن يحتوي على الأقل على وحدة فك ترميز فيديو واحدة للأجهزة تدعم 4K60.
    • [5.1 / H-1-16] يجب أن يحتوي على جهاز تشفير فيديو واحد على الأقل يدعم 4K60.
    • [5.3 / H-1-1] يجب عدم إسقاط أكثر من إطار واحد في 10 ثوانٍ (أي انخفاض إطار أقل من 0.167 بالمائة) لجلسة فيديو 1080 بكسل 60 إطارًا في الثانية تحت التحميل. يُعرَّف التحميل بأنه جلسة تحويل ترميز فيديو فقط من 1080p إلى 720p متزامنة باستخدام برامج ترميز فيديو الأجهزة ، بالإضافة إلى تشغيل صوت AAC بسرعة 128 كيلوبت في الثانية.
    • [5.3 / H-1-2] يجب ألا يسقط أكثر من إطار واحد في 10 ثوان أثناء تغيير دقة الفيديو في جلسة فيديو 60 إطارًا في الثانية تحت التحميل. يُعرَّف التحميل بأنه جلسة تحويل ترميز فيديو فقط من 1080p إلى 720p متزامنة باستخدام برامج ترميز فيديو الأجهزة ، بالإضافة إلى تشغيل صوت AAC بسرعة 128 كيلوبت في الثانية.
    • [5.6 / H-1-1] يجب أن يكون زمن انتقال النقر إلى النغمة 80 مللي ثانية أو أقل باستخدام اختبار الضغط إلى النغمة OboeTester أو اختبار 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.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 إطارًا في الثانية

  • 2.2.7.2 الكاميرا : تحديثات متطلبات الكاميرا من فئة Media Performance.

    انظر المراجعة

    إذا أعادت تطبيقات الأجهزة المحمولة باليد android.os.Build.VERSION_CODES.T لـ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS ، فإنها:

    • [7.5 / H-1-1] يجب أن يكون لديك كاميرا خلفية أساسية مع دقة لا تقل عن 12 ميجابكسل تدعم التقاط الفيديو بمعدل 4k @ 30 إطارًا في الثانية. الكاميرا الخلفية الأساسية هي الكاميرا الخلفية مع أدنى معرف للكاميرا.
    • [7.5 / H-1-2] يجب أن يكون لديك كاميرا أمامية أولية بدقة لا تقل عن 5 ميغا بكسل ودعم التقاط الفيديو بدقة 1080 بكسل في 30 إطارًا في الثانية. الكاميرا الأمامية الأساسية هي الكاميرا الأمامية مع أدنى معرف للكاميرا.
    • [7.5 / H-1-3] يجب أن يدعم android.info.supportedHardwareLevel خاصية FULL أو أفضل لكلا الكاميرات الأساسية.
    • [7.5 / H-1-4] يجب أن تدعم CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME لكل من الكاميرات الأساسية.
    • [7.5 / H-1-5] يجب أن يكون لديك camera2 JPEG التقاط زمن انتقال <1000 مللي ثانية لدقة 1080 بكسل كما تم قياسها بواسطة اختبار أداء كاميرا CTS في ظل ظروف إضاءة ITS (3000K) لكلا الكاميرتين الأساسيتين.
    • [7.5 / H-1-6] يجب أن يكون زمن انتقال بدء تشغيل camera2 (الكاميرا المفتوحة لإطار المعاينة الأول) <500 مللي ثانية كما تم قياسه بواسطة اختبار أداء كاميرا CTS تحت ظروف إضاءة ITS (3000 كيلو) لكلا الكاميرتين الأساسيتين.
    • [7.5 / H-1-8] يجب أن تدعم CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW و android.graphics.ImageFormat.RAW_SENSOR للكاميرا الخلفية الأساسية.
    • [7.5 / H-1-9] يجب أن يكون لديك كاميرا خلفية أساسية تدعم 720p أو 1080p @ 240fps.
    • [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 للكاميرات الأساسية إذا كان هناك أكثر من 1 كاميرات RGB تواجه نفس الاتجاه.
    • [7.5 / H-1-14] يجب أن تدعم قدرة STREAM_USE_CASE لكل من الكاميرا الخلفية الأساسية والأساسية.

  • 2.2.7.3 الأجهزة : تحديثات متطلبات فئة أداء الوسائط للأجهزة.

    انظر المراجعة

    إذا أعادت تطبيقات الأجهزة المحمولة باليد android.os.Build.VERSION_CODES.T لـ 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.6.1 / H-2-1] يجب أن يحتوي على 8 جيجا بايت على الأقل من الذاكرة الفعلية.

  • 2.2.7.4 الأداء : تحديثات فئة أداء الوسائط للأداء.

    انظر المراجعة

    إذا أعادت تطبيقات الأجهزة المحمولة باليد android.os.Build.VERSION_CODES.T لـ android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS ، فإنها:

    • [8.2 / H-1-1] يجب أن تضمن أداء كتابة متسلسل لا يقل عن 125 ميغا بايت / ثانية.
    • [8.2 / H-1-2] يجب أن تضمن أداء كتابة عشوائي لا يقل عن 10 ميغا بايت / ثانية.
    • [8.2 / H-1-3] يجب أن تضمن أداء قراءة متسلسل لا يقل عن 250 ميغا بايت / ثانية.
    • [8.2 / H-1-4] يجب أن تضمن أداء قراءة عشوائي لا يقل عن 40 ميغا بايت / ثانية.

  • 2.5.1 الأجهزة : تحديثات متطلبات مقياس التسارع ثلاثي المحاور والجيروسكوب ثلاثي المحاور ، بالإضافة إلى متطلبات كاميرا الرؤية الخارجية.

    انظر المراجعة

    تطبيقات جهاز السيارات:

    • [ 7.3 .1 / A-0-4] يجب أن يتوافق مع نظام إحداثيات مستشعر السيارة Android.
    • [ 7.3 / A-SR] يُنصح بشدة بتضمين مقياس تسارع ثلاثي المحاور وجيروسكوب ثلاثي المحاور.
    • [ 7.3 / A-SR] يُنصح بشدة بتنفيذ مستشعر TYPE_HEADING والإبلاغ عنه.

    إذا اشتملت تطبيقات أجهزة السيارات على مقياس تسارع ، فإنها:

    • [ 7.3 .1 / A-1-1] يجب أن تكون قادرة على الإبلاغ عن أحداث تصل إلى تردد لا يقل عن 100 هرتز.

    إذا تضمنت تطبيقات الجهاز مقياس تسارع ثلاثي المحاور ، فإنها:

    • [ 7.3 .1 / A-SR] يوصى بشدة بتنفيذ المستشعر المركب لمقياس التسارع المحدود المحاور.

    إذا اشتملت تطبيقات أجهزة السيارات على مقياس تسارع بأقل من 3 محاور ، فإنها:

    • [ 7.3 .1 / A-1-3] يجب تنفيذ والإبلاغ عن مستشعر TYPE_ACCELEROMETER_LIMITED_AXES .
    • [ 7.3 .1 / A-1-4] يجب تنفيذ مستشعر TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED والإبلاغ عنه.

    إذا كانت تطبيقات أجهزة السيارات تشتمل على جيروسكوب ، فإنها:

    • [ 7.3 .4 / A-2-1] يجب أن يكون قادرًا على الإبلاغ عن الأحداث بتردد لا يقل عن 100 هرتز.
    • [ 7.3 .4 / A-2-3] يجب أن تكون قادرة على قياس تغيرات الاتجاه حتى 250 درجة في الثانية.
    • [ 7.3 .4 / A-SR] يُنصح بشدة بتكوين نطاق قياس الجيروسكوب إلى +/- 250dps من أجل تعظيم الدقة الممكنة.

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

    • [ 7.3 .4 / A-SR] يوصى بشدة بتنفيذ المستشعر المركب لمحاور جيروسكوب محدودة.

    إذا اشتملت تطبيقات أجهزة السيارات على جيروسكوب بأقل من 3 محاور ، فإنها:

    • [ 7.3 .4 / A-4-1] يجب تنفيذ والإبلاغ عن مستشعر TYPE_GYROSCOPE_LIMITED_AXES .
    • [ 7.3 .4 / A-4-2] يجب تنفيذ مستشعر TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED والإبلاغ عنه.

    إذا اشتملت تطبيقات أجهزة السيارات على مستشعر TYPE_HEADING ، فإنها:

    • [ 7.3 .4 / A-4-3] يجب أن تكون قادرة على الإبلاغ عن أحداث تصل إلى تردد لا يقل عن 1 هرتز.
    • [ 7.3 .4 / A-SR] STRONGLY_RECOMMENDED للإبلاغ عن الأحداث بتردد لا يقل عن 10 هرتز.
    • يجب أن يكون في إشارة إلى الشمال الحقيقي.
    • يجب أن تكون متاحة حتى عندما تكون السيارة لا تزال.
    • يجب أن يكون القرار بدرجة واحدة على الأقل.

    كاميرا الرؤية الخارجية عبارة عن كاميرا تصور المشاهد خارج تنفيذ الجهاز ، مثل كاميرا الرؤية الخلفية كاميرا داش كام .

    إذا كانت تطبيقات جهاز السيارات تشتمل على كاميرا رؤية خارجية ، بالنسبة لمثل هذه الكاميرا ، فإنها:

    • [ 7.5 .5 / A-SR] من المستحسن بشدة أن يتم توجيهها بحيث يتماشى البعد الطويل للكاميرا مع الأفق.

    • قد يكون لديك إما تركيز تلقائي للأجهزة أو تركيز تلقائي للبرامج مطبق في برنامج تشغيل الكاميرا.

    إذا تضمنت تطبيقات أجهزة السيارات واحدة أو أكثر من كاميرات الرؤية الخارجية ، وتحميل خدمة نظام الرؤية الخارجية (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 .

  • 2.5.5 نموذج الأمان : متطلبات جديدة لأذونات الكاميرا لأجهزة السيارات.

    انظر المراجعة

    إذا أعلنت تطبيقات أجهزة السيارات عن android.hardware.camera.any ، فإنها:

    • [ 9.8.2 / A-2-1] يجب أن يعرض مؤشر الكاميرا عند وصول أحد التطبيقات إلى بيانات الكاميرا الحية ، ولكن ليس عندما يتم الوصول إلى الكاميرا فقط عن طريق التطبيق (التطبيقات) الذي يحتفظ بالأدوار المذكورة في القسم 9.1 الأذونات مع CDD المعرف [C-3-X].

    • [ 9.8.2 / A-2-2] يجب عدم إخفاء مؤشر الكاميرا لتطبيقات النظام التي تحتوي على واجهات مستخدم مرئية أو تفاعل مباشر للمستخدم.

  • 2.6.1 متطلبات الجهاز اللوحي - الأجهزة : التحديث لمتطلبات حجم شاشة الكمبيوتر اللوحي.

    انظر المراجعة

    يشير جهاز Android Tablet إلى تنفيذ جهاز Android الذي يلبي عادةً جميع المعايير التالية:

    • لها شاشة بحجم أكبر من 7 "وأقل من 18" ، مقاسة قطريًا.

    حجم الشاشة

    • يجب أن يكون [ 7.1 .1.1 / Tab-0-1] شاشة في نطاق 7 إلى 18 بوصة.

3. البرمجيات

  • 3.2.2 معلمات الإنشاء : أحرف ASCII المحدثة في getSerial() .

    انظر المراجعة

    • [C-0-1] لتوفير قيم متسقة وذات مغزى عبر تطبيقات الأجهزة ، يتضمن الجدول أدناه قيودًا إضافية على تنسيقات هذه القيم التي يجب أن تتوافق معها تطبيقات الجهاز.
    معامل تفاصيل
    getSerial () يجب أن يكون (أو يُرجع) رقمًا تسلسليًا للجهاز ، والذي يجب أن يكون متاحًا وفريدًا عبر الأجهزة التي لها نفس الطراز والمصنع. يجب أن تكون قيمة هذا الحقل قابلة للتشفير كـ ASCII 7 بت وأن تطابق التعبير العادي "^ [a-zA-Z0-9] + $" .

  • 3.2.3.5 أهداف التطبيق الشرطي : تحديث لمتطلبات أهداف التطبيق الشرطي.

    انظر المراجعة

    إذا اشتملت تطبيقات الجهاز على شاشة عرض كبيرة (بشكل عام يكون عرضها وارتفاعها 600dp +) وتدعم وظيفة الانقسام ، فإنها:

  • 3.5.1 تقييد التطبيق : تحديثات قيود التطبيق.

    انظر المراجعة

    إذا نفذت عمليات تنفيذ الجهاز آلية خاصة لتقييد التطبيقات (مثل تغيير أو تقييد سلوكيات واجهة برمجة التطبيقات الموضحة في SDK) وكانت هذه الآلية أكثر تقييدًا من مجموعة Restricted App Standby ، فإنها:

    • [C-1-1] يجب أن يسمح للمستخدم برؤية قائمة التطبيقات المحظورة.
    • [C-1-2] يجب أن يوفر للمستخدم القدرة على تشغيل / إيقاف تشغيل كل قيود الملكية هذه على كل تطبيق.
    • [C-1-3] يجب ألا تطبق قيود الملكية هذه تلقائيًا دون دليل على السلوك الصحي السيئ للنظام ، ولكن قد تطبق القيود على التطبيقات عند اكتشاف السلوك الصحي للنظام السيئ مثل wakelocks المتوقفة والخدمات طويلة المدى ومعايير أخرى. قد يتم تحديد المعايير بواسطة منفذي الأجهزة ولكن يجب أن تكون مرتبطة بتأثير التطبيق على صحة النظام. المعايير الأخرى التي لا تتعلق فقط بسلامة النظام ، مثل افتقار التطبيق إلى الشعبية في السوق ، يجب عدم استخدامها كمعايير.
    • [C-1-4] يجب ألا يطبق قيود الملكية هذه تلقائيًا على التطبيقات عندما يقوم المستخدم بإيقاف تشغيل قيود التطبيق يدويًا ، وقد يقترح المستخدم تطبيق قيود الملكية هذه.
    • [C-1-5] يجب إبلاغ المستخدمين إذا تم تطبيق قيود الملكية هذه على التطبيق تلقائيًا. يجب تقديم هذه المعلومات في فترة الـ 24 ساعة السابقة لتطبيق قيود الملكية هذه.

    • [C-1-6] يجب أن يعود صحيحًا لأسلوب ActivityManager.isBackgroundRestricted () لأي استدعاءات لواجهة برمجة التطبيقات من أحد التطبيقات.

    • [C-1-7] يجب ألا يقيد التطبيق الأمامي الذي يستخدمه المستخدم بشكل صريح.

    • [C-1-8] يجب تعليق قيود الملكية هذه على تطبيق ما عندما يبدأ المستخدم في استخدام التطبيق بشكل صريح ، مما يجعله أفضل تطبيق في المقدمة.

    • [C-1-9] يجب الإبلاغ عن كل أحداث قيود الملكية هذه عبر UsageStats.

    • [C-1-10] يجب توفير مستند أو موقع ويب عام وواضح يصف كيفية تطبيق قيود الملكية. يجب أن يكون هذا المستند أو موقع الويب قابلاً للربط من مستندات Android SDK ويجب أن يتضمن:

      • تفعيل شروط قيود الملكية.
      • ماذا وكيف يمكن تقييد التطبيق.
      • كيف يمكن استثناء تطبيق من هذه القيود.
      • كيف يمكن لتطبيق ما طلب إعفاء من قيود الملكية ، إذا كانت تدعم مثل هذا الإعفاء للتطبيقات التي يمكن للمستخدم تثبيتها.

    إذا تم تثبيت أحد التطبيقات مسبقًا على الجهاز ولم يتم استخدامه صراحة من قبل المستخدم لأكثر من 30 يومًا ، يتم استثناء [C-1-3] [C-1-5].

  • 3.8.1 Launcher (الشاشة الرئيسية) : تحديثات لدعم monochrome/adaptive-icon .

    انظر المراجعة

    إذا كانت تطبيقات الجهاز تدعم الرموز أحادية اللون ، فإن هذه الرموز:

    • يجب استخدام [C-6-1] فقط عندما يقوم المستخدم بتمكينهم صراحةً (على سبيل المثال عبر الإعدادات أو قائمة منتقي الخلفية).

  • 3.8.2 الأدوات : قم بالتحديث لوجود عنصر واجهة مستخدم تطبيقات تابع لجهة خارجية في المشغل.

    انظر المراجعة

    إذا كانت تطبيقات الجهاز تدعم أدوات تطبيقات الجهات الخارجية ، فإنها:

    • [C-1-2] يجب أن يتضمن دعمًا مضمنًا لـ AppWidgets وفضح إمكانيات واجهة المستخدم لإضافة ، تكوين ، عرض ، وإزالة AppWidgets مباشرة داخل المشغل.

  • 3.8.3.1 تقديم الإخطارات : توضيح تعريف إخطارات التنبيه.

    انظر المراجعة

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

  • 3.8.3.3 DND (عدم الإزعاج) / وضع الأولوية : التحديث ليشمل وضع الأولوية في متطلبات DND (عدم الإزعاج).

    انظر المراجعة

    3.8.3.3. DND (عدم الإزعاج) / وضع الأولوية

    إذا كانت تطبيقات الجهاز تدعم ميزة DND (تسمى أيضًا وضع الأولوية) ، فإنها:

  • 3.8.6 السمات : متطلبات جديدة للوحات درجات الألوان الديناميكية.

    انظر المراجعة

    إذا تضمنت عمليات تنفيذ الجهاز شاشة أو إخراج فيديو ، فإنها:

    • [C-1-4] يجب إنشاء لوحات android.theme.customization.theme_style لونية ديناميكية على النحو المحدد في وثائق android.theme.customization.system_palette Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES .

    • [ android.theme.customization.theme_styles - EXPRESSIVE ] VIBRANT إنشاء لوحات درجات SPRITZ ديناميكية باستخدام أنماط سمات FRUIT_SALAD التي RAINBOW تعدادها في Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES TONAL_SPOT

      يُستخدم "لون المصدر" لإنشاء لوحات درجات لونية ديناميكية عند إرسالها باستخدام android.theme.customization.system_palette (كما هو موثق في Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES ).

    • [C-1-6] يجب أن تكون قيمة صفاء CAM16 5 أو أكبر.

      • يجب اشتقاقها من الخلفية عبر com.android.systemui.monet.ColorScheme#getSeedColors ، والتي توفر ألوان مصدر متعددة صالحة لاختيار واحد منها.

      • يجب استخدام القيمة 0xFF1B6EF3 ، إذا لم يفي أي من الألوان المتوفرة بمتطلبات لون المصدر أعلاه.

  • 3.8.17 الحافظة : تمت إضافة قسم المتطلبات الجديدة للمحتوى الموجود في الحافظة.

    انظر المراجعة

    3.8.17. الحافظة

    تطبيقات الجهاز:

    • [C-0-1] يجب ألا ترسل بيانات الحافظة إلى أي مكون أو نشاط أو خدمة أو عبر أي اتصال بالشبكة ، بدون إجراء صريح من المستخدم (على سبيل المثال ، الضغط على زر على التراكب) ، باستثناء الخدمات المذكورة في 9.8.6 المحتوى الالتقاط والبحث في التطبيق .

    إذا كانت تطبيقات الجهاز تنشئ معاينة مرئية للمستخدم عند نسخ المحتوى إلى الحافظة لأي عنصر ClipData حيث يحتوي ClipData.getDescription().getExtras() على android.content.extra.IS_SENSITIVE ، فهي:

    • [C-1-1] يجب تنقيح معاينة المستخدم المرئية

    يلبي تطبيق مرجع AOSP متطلبات الحافظة هذه.

  • 3.9.1.1 توفير مالك الجهاز : تحديثات متطلبات توفير مالك الجهاز.

    انظر المراجعة

    إذا أعلنت تطبيقات الجهاز android.software.device_admin ، فإنها:

    • يجب أن يدعم [C-1-1] تسجيل عميل نهج الجهاز (DPC) باعتباره تطبيق مالك الجهاز كما هو موضح أدناه:
      • عندما لا يحتوي تطبيق الجهاز على مستخدمين ولا تكوين بيانات مستخدم ، فإنه:
        • [C-1-5] يجب تسجيل تطبيق DPC باعتباره تطبيق مالك الجهاز أو تمكين تطبيق DPC لاختيار ما إذا كنت تريد أن تصبح مالك جهاز أو مالك ملف تعريف ، إذا أعلن الجهاز دعم اتصالات المجال القريب (NFC) عبر الميزة ضع علامة على android.hardware.nfc واستلام رسالة NFC تحتوي على سجل بنوع MIME_TYPE_PROVISIONING_NFC .
        • [C-1-8] يجب إرسال نية ACTION_GET_PROVISIONING_MODE بعد تشغيل إدارة حسابات مالك الجهاز بحيث يمكن لتطبيق DPC اختيار ما إذا كان سيصبح مالك الجهاز أو مالك الملف الشخصي ، اعتمادًا على قيم android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES ، ما لم يمكن تحديده من السياق أنه لا يوجد سوى خيار واحد صالح. (مثل التوفير المستند إلى NFC حيث لا يتم دعم توفير ملف تعريف مالك).
        • يجب أن ترسل [C-1-9] نية ACTION_ADMIN_POLICY_COMPLIANCE إلى تطبيق "مالك الجهاز" إذا تم إنشاء "مالك الجهاز" أثناء التوفير بغض النظر عن طريقة التوفير المستخدمة. يجب ألا يكون المستخدم قادرًا على المتابعة في معالج الإعداد حتى ينتهي تطبيق "مالك الجهاز".
      • عندما يكون لتطبيق الجهاز بيانات مستخدمين أو مستخدمين ، فإنه:
        • [C-1-7] يجب عدم تسجيل أي تطبيق DPC كتطبيق مالك الجهاز بعد الآن.
    • يجب أن يُظهر [C-1-2] إشعار إفشاء مناسبًا (مثل المشار إليه في AOSP ) وأن يحصل على موافقة مؤكدة من المستخدم النهائي قبل تعيين التطبيق كمالك الجهاز ، ما لم يتم تكوين الجهاز برمجيًا لوضع العرض التوضيحي للبيع بالتجزئة قبل على الشاشة ، تفاعل المستخدم النهائي. تتطلب بعض الإجراءات الإيجابية قبل أو أثناء عملية التوفير للموافقة على تعيين أحد التطبيقات كمالك الجهاز. يمكن أن تكون الموافقة من خلال إجراء المستخدم أو عن طريق بعض الوسائل الآلية ، ولكن يجب إظهار إشعار الإفصاح المناسب (كما هو مشار إليه في AOSP) قبل بدء توفير مالك الجهاز. أيضًا ، يجب ألا تتداخل آلية موافقة مالك الجهاز الآلية المستخدمة (بواسطة المؤسسات) لتوفير مالك الجهاز مع "التجربة خارج الصندوق" للاستخدام خارج نطاق المؤسسة.
    • [C-1-3] يجب ألا يرمز إلى الموافقة أو يمنع استخدام تطبيقات مالك الجهاز الأخرى.

    إذا أعلنت تطبيقات الجهاز android.software.device_admin ، فإنها تتضمن أيضًا ملف مالك الجهاز حل إدارة الجهاز وتوفير آلية للترويج لتطبيق تم تكوينه في الحل الخاص بهم باعتباره "مكافئ مالك الجهاز" لـ "مالك الجهاز" القياسي كما هو معترف به بواسطة واجهات برمجة تطبيقات Android DevicePolicyManager القياسية ، فإنهم:

    • [C-2-1] يجب أن يكون لديه عملية قائمة للتحقق من أن التطبيق المحدد الذي يتم الترويج له ينتمي إلى حل إدارة جهاز مؤسسي شرعي وأنه قد تم تكوينه في حل الملكية للحصول على الحقوق المكافئة كـ "مالك الجهاز".
    • [C-2-2] يجب أن يُظهر نفس الإفصاح عن موافقة مالك جهاز AOSP مثل التدفق الذي بدأه android.app.action.PROVISION_MANAGED_DEVICE قبل تسجيل تطبيق DPC باسم "مالك الجهاز".
    • [C-2-3] يجب ألا يرمز إلى الموافقة أو يمنع استخدام تطبيقات مالك الجهاز الأخرى.
    • قد يكون لديك بيانات المستخدم على الجهاز قبل تسجيل تطبيق DPC باسم "مالك الجهاز".

  • 3.9.4 متطلبات دور إدارة الجهاز : تمت إضافة قسم لمتطلبات دور إدارة الأجهزة.

    انظر المراجعة

    3.9.4 متطلبات دور إدارة نهج الجهاز

    إذا أبلغت تطبيقات الجهاز عن android.software.device_admin أو android.software.managed_users ، فإنها:

    • [C-1-1] يجب أن يدعم دور إدارة سياسة الجهاز على النحو المحدد في القسم 9.1 . يمكن تحديد التطبيق الذي يحتفظ بدور إدارة سياسة الجهاز عن طريق تعيين config_devicePolicyManagement إلى اسم الحزمة. يجب أن يتبع اسم الحزمة : وشهادة التوقيع ما لم يتم تحميل التطبيق مسبقًا.

    إذا لم يتم تعريف اسم الحزمة لـ config_devicePolicyManagement كما هو موضح أعلاه:

    إذا تم تحديد اسم حزمة لـ config_devicePolicyManagement كما هو موضح أعلاه:

    • [C-3-1] يجب تثبيت التطبيق على جميع ملفات التعريف للمستخدم .
    • [C-3-2] قد تحدد تطبيقات الجهاز تطبيقًا يقوم بتحديث صاحب دور إدارة سياسة الجهاز قبل التزويد عن طريق إعداد config_devicePolicyManagementUpdater .

    إذا تم تحديد اسم حزمة لـ config_devicePolicyManagementUpdater كما هو موضح أعلاه:

    • [C-4-1] يجب تثبيت التطبيق مسبقًا على الجهاز.
    • [C-4-2] يجب أن ينفذ التطبيق مرشح الهدف الذي يحل android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER .

  • 3.18 جهات الاتصال : إضافة معلومات لجهات اتصال جديدة.

    انظر المراجعة

    الحساب الافتراضي لجهات الاتصال الجديدة: يوفر موفر جهات الاتصال واجهات برمجة التطبيقات لإدارة إعداد الحساب الافتراضي عند إنشاء جهة اتصال جديدة.

    في حالة تحميل تطبيقات الجهاز مسبقًا لتطبيق جهات الاتصال ، فحينئذٍ يكون تطبيق جهات الاتصال المحمّل مسبقًا:

    • يجب أن يتعامل [C-2-1] مع ContactsContract.Settings.ACTION_SET_DEFAULT_ACCOUNT لإطلاق واجهة مستخدم لاختيار الحساب وحفظ الإعداد إلى مزود جهات الاتصال عند تحديد حساب.

    • يجب أن تحترم [C-2-2] إعداد الحساب الافتراضي عند التعامل مع Intent.ACTION_INSERT and Intent.ACTION_INSERT_OR_EDIT لـ ContactsContracts.Contacts.CONTENT_TYPE و ContactsContract.RawContacts.CONTENT_TYPE عن طريق تحديد الحساب مبدئيًا.

4. توافق تغليف التطبيق

5. توافق الوسائط المتعددة

  • 5.1.2 فك تشفير الصوت : تمت إضافة متطلبات جديدة لأجهزة فك التشفير القادرة على إخراج صوت متعدد القنوات.

    انظر المراجعة

    إذا كانت تطبيقات الجهاز تدعم فك تشفير مخازن إدخال AAC للتدفقات متعددة القنوات (أي أكثر من قناتين) إلى PCM من خلال وحدة فك ترميز الصوت AAC الافتراضية في android.media.MediaCodec API ، فيجب دعم ما يلي:

    • [C-7-1] يجب أن يكون قادرًا على تكوينه بواسطة التطبيق باستخدام فك التشفير بالمفتاح KEY_MAX_OUTPUT_CHANNEL_COUNT للتحكم في ما إذا كان المحتوى مختلطًا إلى صوت ستريو (عند استخدام قيمة 2) أو يتم إخراجه باستخدام العدد الأصلي للقنوات ( عند استخدام قيمة مساوية أو أكبر لهذا الرقم). على سبيل المثال ، فإن القيمة 6 أو أكبر من شأنها تكوين وحدة فك ترميز لإخراج 6 قنوات عند تغذية محتوى 5.1.
    • [C-7-2] عند فك التشفير ، يجب أن تعلن وحدة فك التشفير عن قناع القناة المستخدم في تنسيق الإخراج باستخدام مفتاح KEY_CHANNEL_MASK ، باستخدام ثوابت android.media.AudioFormat (مثال: CHANNEL_OUT_5POINT1 ).

    إذا كانت تطبيقات الجهاز تدعم مفككات تشفير الصوت بخلاف وحدة فك ترميز الصوت AAC الافتراضية وقادرة على إخراج صوت متعدد القنوات (أي أكثر من قناتين) عند تغذية محتوى مضغوط متعدد القنوات ، فعندئذٍ:

    • [C-SR] من المستحسن بشدة أن تتم تهيئة وحدة فك التشفير بواسطة التطبيق باستخدام فك التشفير باستخدام المفتاح KEY_MAX_OUTPUT_CHANNEL_COUNT للتحكم في ما إذا كان المحتوى مختلطًا إلى صوت ستريو (عند استخدام القيمة 2) أو يتم إخراجها باستخدام الرقم الأصلي عدد القنوات (عند استخدام قيمة مساوية أو أكبر لهذا الرقم). على سبيل المثال ، فإن القيمة 6 أو أكبر من شأنها تكوين وحدة فك ترميز لإخراج 6 قنوات عند تغذية محتوى 5.1.
    • [C-SR] عند فك التشفير ، يوصى بشدة بوحدة فك التشفير للإعلان عن قناع القناة المستخدم في تنسيق الإخراج باستخدام مفتاح KEY_CHANNEL_MASK ، باستخدام ثوابت android.media.AudioFormat (مثال: CHANNEL_OUT_5POINT1 ).

  • 5.4.1 معلومات عن التقاط الصوت الخام والميكروفون : تحديثات لمصادر الصوت المدعومة لتدفقات إدخال الصوت.

    انظر المراجعة

    إذا أعلنت تطبيقات الجهاز عن android.hardware.microphone ، فإنها:

    • [C-1-1] يجب أن يسمح بالتقاط محتوى صوتي خام بالخصائص التالية لأي AudioRecord أو تيار AAudio INPUT يتم فتحه بنجاح. كحد أدنى ، يجب دعم الخصائص التالية :

      • التنسيق: Linear PCM ، 16 بت
      • معدلات أخذ العينات: 8000 ، 11025 ، 16000 ، 44100 ، 48000 هرتز
      • القنوات: مونو
      • مصادر الصوت: DEFAULT أو MIC أو CAMCORDER أو VOICE_RECOGNITION أو VOICE_COMMUNICATION أو UNPROCESSED أو VOICE_PERFORMANCE . ينطبق هذا أيضًا على إعدادات الإدخال المسبقة المكافئة في AAudio ، على سبيل المثال ، AAUDIO_INPUT_PRESET_CAMCORDER .
      • [C-1-4] يجب أن تحترم MicrophoneInfo API وتعبئ بشكل صحيح المعلومات الخاصة بالميكروفونات المتاحة على الجهاز التي يمكن الوصول إليها من قبل تطبيقات الطرف الثالث عبر AudioManager.getMicrophones() API ، لتسجيل الصوت النشط باستخدام MediaRecorder.AudioSources DEFAULT ، MIC ، CAMCORDER أو VOICE_RECOGNITION أو VOICE_COMMUNICATION أو UNPROCESSED أو VOICE_PERFORMANCE . والميكروفونات النشطة حاليًا التي يمكن الوصول إليها من قبل تطبيقات الجهات الخارجية عبر واجهات برمجة تطبيقات AudioRecord.getActiveMicrophones() و MediaRecorder.getActiveMicrophones() .

  • 5.4.2 الالتقاط من أجل التعرف على الصوت : المتطلبات المحدثة لدفق صوت التعرف على الصوت والمتطلبات المضافة لمستويات كسب الميكروفون.

    انظر المراجعة

    إذا أعلنت تطبيقات الجهاز عن android.hardware.microphone ، فإنها:

    • يجب تسجيل دفق صوت التعرف على الصوت بسعة مسطحة تقريبًا مقابل خصائص التردد: على وجه التحديد ، ± 3 ديسيبل ، من 100 هرتز إلى 4000 هرتز.
    • يجب تسجيل دفق صوت التعرف على الصوت مع مجموعة حساسية الإدخال بحيث ينتج عن مصدر مستوى طاقة الصوت (SPL) 90 ديسيبل عند 1000 هرتز RMS 2500 لعينات 16 بت.

    • يجب أن تعرض خصائص السعة المسطحة تقريبًا مقابل التردد في نطاق التردد المتوسط: على وجه التحديد ± 3 ديسيبل من 100 هرتز إلى 4000 هرتز لكل ميكروفون مستخدم لتسجيل مصدر صوت التعرف على الصوت.
    • يُنصح بشدة باستخدام [C-SR] لعرض مستويات السعة في نطاق التردد المنخفض: تحديدًا من 20 ديسيبل من 30 هرتز إلى 100 هرتز مقارنة بمدى التردد المتوسط ​​لكل ميكروفون مستخدم لتسجيل مصدر صوت التعرف على الصوت.
    • يُنصح بشدة باستخدام [C-SR] لعرض مستويات الاتساع في نطاق التردد العالي: على وجه التحديد من ± 30 ديسيبل من 4000 هرتز إلى 22 كيلو هرتز مقارنة بنطاق التردد المتوسط ​​لكل ميكروفون مستخدم لتسجيل مصدر صوت التعرف على الصوت.
    • يجب تعيين حساسية إدخال الصوت بحيث ينتج عن مصدر النغمة الجيبية 1000 هرتز الذي يتم تشغيله عند 90 ديسيبل مستوى ضغط الصوت (SPL) (يقاس بجوار الميكروفون) استجابة مثالية تبلغ RMS 2500 في نطاق 1770 و 3530 لعينات 16 بت ( أو -22.35 ديسيبل ± 3 ديسيبل مقياس كامل للنقطة العائمة / عينات الدقة المزدوجة) لكل ميكروفون مستخدم لتسجيل مصدر صوت التعرف على الصوت.

  • 5.4.6 مستويات اكتساب الميكروفون : تم نقل المتطلبات لمستويات اكتساب الميكروفون إلى القسم 5.4.2.

    انظر المراجعة

    5.4.6. مستويات اكتساب الميكروفون [انتقل إلى 5.4.2]

    إذا أعلنت تطبيقات الجهاز عن android.hardware.microphone ، فإنها:

    • يجب أن تعرض خصائص السعة المسطحة تقريبًا مقابل التردد في نطاق التردد المتوسط: على وجه التحديد ± 3 ديسيبل من 100 هرتز إلى 4000 هرتز لكل ميكروفون مستخدم لتسجيل مصدر صوت التعرف على الصوت.
    • يُنصح بشدة باستخدام [C-SR] لعرض مستويات السعة في نطاق التردد المنخفض: تحديدًا من 20 ديسيبل من 5 هرتز إلى 100 هرتز مقارنة بنطاق التردد المتوسط ​​لكل ميكروفون مستخدم لتسجيل مصدر صوت التعرف على الصوت.
    • يُنصح بشدة باستخدام [C-SR] لعرض مستويات الاتساع في نطاق التردد العالي: على وجه التحديد من ± 30 ديسيبل من 4000 هرتز إلى 22 كيلو هرتز مقارنة بنطاق التردد المتوسط ​​لكل ميكروفون مستخدم لتسجيل مصدر صوت التعرف على الصوت.
    • SHOULD set audio input sensitivity such that a 1000 Hz sinusoidal tone source played at 90 dB Sound Pressure Level (SPL) yields a response with RMS of 2500 for 16 bit-samples (or -22.35 dB Full Scale for floating point/double precision samples) for each and every microphone used to record the voice recognition audio source.

  • 5.5.4 Audio Offload : Updates to the audio offload playback requirements.

    See revision

    If device implementations support audio offload playback , they:

    • [C-SR] Are STRONGLY RECOMMENDED to trim the played gapless audio content between two clips with the same format when specified by the AudioTrack gapless API and the media container for MediaPlayer.

  • 5.6 Audio Latency : Updates to the audio latency requirements.

    See revision

    For the purposes of this section, use the following definitions:

    • cold output jitter . The variability among separate measurements of cold output latency values.
    • cold input jitter . The variability among separate measurements of cold input latency values.

    If device implementations declare android.hardware.audio.output , they MUST meet or exceed the following requirements:

    • [C-1-2] Cold output latency of 500 milliseconds or less.
    • [C-1-3] Opening an output stream using AAudioStreamBuilder_openStream() MUST take less than 1000 milliseconds.

    If device implementations declare android.hardware.audio.output they are STRONGLY RECOMMENDED to meet or exceed the following requirements:

    • [C-SR] Cold output latency of 100 milliseconds or less over the speaker data path. Existing and new devices that run this version of Android are VERY STRONGLY RECOMMENDED to meet these requirements now. In a future platform release, we will require Cold output latency of 200 ms or less as a MUST.
    • [C-SR] Minimize the cold output jitter.

    If device implementations include android.hardware.microphone , they MUST meet these input audio requirements:

    • [C-3-2] Cold input latency of 500 milliseconds or less.
    • [C-3-3] Opening an input stream using AAudioStreamBuilder_openStream() MUST take less than 1000 milliseconds.

    If device implementations include android.hardware.microphone , they are STRONGLY RECOMMENDED to meet these input audio requirements:

    • [C-SR] Cold input latency of 100 milliseconds or less over the microphone data path. Existing and new devices that run this version of Android are VERY STRONGLY RECOMMENDED to meet these requirements now. In a future platform release we will require Cold input latency of 200 ms or less as a MUST.

    • [C-SR] Continuous input latency of 30 milliseconds or less.
    • [C-SR] Minimize the cold input jitter.

  • 5.10 Professional Audio : Updates to audio latency requirements for professional audio support.

    See revision

    If device implementations report support for feature android.hardware.audio.pro via the android.content.pm.PackageManager class, they:

    • [C-1-2] MUST have the continuous round-trip audio latency, as defined in section 5.6 Audio Latency of 25 milliseconds or less and SHOULD be 10 milliseconds or less over at least one supported path.
    • [C-1-5] MUST meet latencies and USB audio requirements using the AAudio native audio API and AAUDIO_PERFORMANCE_MODE_LOW_LATENCY .
    • [C-1-8] MUST have an average Tap-to-tone latency of 80 milliseconds or less over at least 5 measurements over the speaker to microphone data path.
    • [C-SR] Are STRONGLY RECOMMENDED to provide a consistent level of CPU performance while audio is active and CPU load is varying. This should be tested using the Android app SynthMark . SynthMark uses a software synthesizer running on a simulated audio framework that measures system performance. See the SynthMark documentation for an explanation of the benchmarks. The SynthMark app needs to be run using the “Automated Test” option and achieve the following results: * voicemark.90 >= 32 voices * latencymark.fixed.little <= 15 msec * latencymark.dynamic.little <= 50 msec
    • SHOULD have a latency from touch input to audio output of less than or equal to 40 ms.

    If device implementations include a 4 conductor 3.5mm audio jack, they:

    • [C-2-1] MUST have a mean Continuous Round-trip Audio Latency, as defined in section 5.6 Audio Latency , of 20 milliseconds or less, over 5 measurements with a Mean Absolute Deviation less than 5 milliseconds over the audio jack path using an audio loopback dongle .

  • 5.12 HDR Video : Added a new section for HDR Video requirements.

6. Developer Tools and Options Compatibility

  • 6.1 Developer Tools : Updates to connectivity and GPU Kernel requirements.

    See revision

    If device implementations support adb connections to a host machine via Wi-Fi or Ethernet , they:

    • [C-4-1] MUST have the AdbManager#isAdbWifiSupported() method return true .

    If device implementations support adb connections to a host machine via Wi-Fi or Ethernet , and includes at least one camera, they:

    • [C-5-1] MUST have the AdbManager#isAdbWifiQrSupported() method return true .

    • GPU work information

      Device implementations:

      • [C-6-1] MUST implement the shell command dumpsys gpu --gpuwork to display the aggregated GPU work data returned by the power/gpu_work_period kernel tracepoint, or display no data if the tracepoint is not supported. The AOSP implementation is frameworks/native/services/gpuservice/gpuwork/ .

7. Hardware Compatibility

  • 7.1.4.1 OpenGL ES : Update to recommended extensions.

    See revision

    If device implementations support any of the OpenGL ES versions, they:

    • SHOULD support the EGL_IMG_context_priority and EGL_EXT_protected_content extensions.

  • 7.1.4.2 Vulkan : Updates to version supported for Vulkan.

    See revision

    If device implementations support OpenGL ES 3.1, they:

    • [SR] Are STRONGLY RECOMMENDED to include support for Vulkan 1.3 . Vulkan 1.1
    • MUST NOT support a Vulkan Variant version (ie the variant part of the Vulkan core version MUST be zero).

    If device implementations include a screen or video output, they:

    • [SR] Are STRONGLY RECOMMENDED to include support for Vulkan 1.3 . Vulkan 1.1

    If device implementations include support for Vulkan 1.0 or higher, they:

    • SHOULD support VkPhysicalDeviceProtectedMemoryFeatures and VK_EXT_global_priority .
    • [C-1-12] MUST NOT enumerate support for the VK_KHR_performance_query extension.
    • [C-SR] Are STRONGLY RECOMMENDED to satisfy the requirements specified by the Android Baseline 2021 profile.

  • 7.2.3 Navigation Keys :

    See revision

    Device implementations:

    • [C-SR] Are STRONGLY RECOMMENDED to provide all navigation functions as cancellable. 'Cancellable' is defined as the user's ability to prevent the navigation function from executing (eg going home, going back, etc.) if the swipe is not released past a certain threshold.

    If the back navigation function is provided and the user cancels the Back gesture, then:

    • [C-8-1] OnBackInvokedCallback.onBackCancelled() MUST be called.
    • [C-8-2] OnBackInvokedCallback.onBackInvoked() MUST NOT be called.
    • [C-8-3] KEYCODE_BACK event MUST NOT be dispatched.

    If the back navigation function is provided but the foreground application does NOT have an OnBackInvokedCallback registered, then:

    • The system SHOULD provide an animation for the foreground application that suggests that the user is going back, as provided in AOSP.

    If device implementations provide support for the system API setNavBarMode to allow any system app with android.permission.STATUS_BAR permission to set the navigation bar mode, then they:

    • [C-9-1] MUST provide support for kid-friendly icons or button-based navigation as provided in the AOSP code.

  • 7.3.1 Accelerometer : Updates to sensor requirements for accelerometers.

    See revision

    If device implementations include an accelerometer, a 3-axis accelerometer, they:

    • [C-1-2] MUST implement and report TYPE_ACCELEROMETER sensor.
    • [SR] are STRONGLY RECOMMENDED to implement the TYPE_SIGNIFICANT_MOTION composite sensor.
    • [SR] are STRONGLY RECOMMENDED to implement and report TYPE_ACCELEROMETER_UNCALIBRATED sensor. Android devices are STRONGLY RECOMMENDED to meet this requirement so they will be able to upgrade to the future platform release where this might become REQUIRED.
    • SHOULD implement the TYPE_SIGNIFICANT_MOTION , TYPE_TILT_DETECTOR , TYPE_STEP_DETECTOR , TYPE_STEP_COUNTER composite sensors as described in the Android SDK document.

    If device implementations include a 3-axis accelerometer, they:

    • [C-2-1] MUST implement and report TYPE_ACCELEROMETER sensor.
    • [C-SR] Are STRONGLY RECOMMENDED to implement the TYPE_SIGNIFICANT_MOTION composite sensor.
    • [C-SR] Are STRONGLY RECOMMENDED to implement and report TYPE_ACCELEROMETER_UNCALIBRATED sensor. Android devices are STRONGLY RECOMMENDED to meet this requirement so they will be able to upgrade to the future platform release where this might become REQUIRED.
    • SHOULD implement the TYPE_SIGNIFICANT_MOTION , TYPE_TILT_DETECTOR , TYPE_STEP_DETECTOR , TYPE_STEP_COUNTER composite sensors as described in the Android SDK document.

    If device implementations include an accelerometer with less than 3 axes, they:

    • [C-3-1] MUST implement and report TYPE_ACCELEROMETER_LIMITED_AXES sensor.
    • [C-SR] Are STRONGLY_RECOMMENDED to implement and report TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED sensor.

    If device implementations include a 3-axis accelerometer and any of the TYPE_SIGNIFICANT_MOTION , TYPE_TILT_DETECTOR , TYPE_STEP_DETECTOR , TYPE_STEP_COUNTER composite sensors are implemented:

    • [C-4-1] The sum of their power consumption MUST always be less than 4 mW.

    If device implementations include a 3-axis accelerometer and a 3-axis gyroscope sensor, they:

    • [C-5-1] MUST implement the TYPE_GRAVITY and TYPE_LINEAR_ACCELERATION composite sensors.

    If device implementations include a 3-axis accelerometer, a 3-axis gyroscope sensor, and a magnetometer sensor, they:

    • [C-6-1] MUST implement a TYPE_ROTATION_VECTOR composite sensor.

  • 7.3.4 Gyroscopes : Updates to sensor requirements for gyroscopes.

    See revision

    If device implementations include a gyroscope, they:

    • [C-1-1] MUST be able to report events up to a frequency of at least 50 Hz.
    • [C-1-4] MUST have a resolution of 12-bits or more.
    • [C-1-5] MUST be temperature compensated.
    • [C-1-6] MUST be calibrated and compensated while in use, and preserve the compensation parameters between device reboots.
    • [C-1-7] MUST have a variance no greater than 1e-7 rad^2 / s^2 per Hz (variance per Hz, or rad^2 / s). The variance is allowed to vary with the sampling rate, but MUST be constrained by this value. In other words, if you measure the variance of the gyro at 1 Hz sampling rate it SHOULD be no greater than 1e-7 rad^2/s^2.
    • [C-SR] Calibration error is STRONGLY RECOMMENDED to be less than 0.01 rad/s when device is stationary at room temperature.
    • [C-SR] Are STRONGLY RECOMMENDED to have a resolution of 16-bits or more.
    • SHOULD report events up to at least 200 Hz.

    If device implementations include a 3-axis gyroscope, they:

    • [C-2-1] MUST implement the TYPE_GYROSCOPE sensor.

    If device implementations include a gyroscope with less than 3 axes, they:

    • [C-3-1] MUST implement and report TYPE_GYROSCOPE_LIMITED_AXES sensor.
    • [C-SR] Are STRONGLY_RECOMMENDED to implement and report TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED sensor.

    If device implementations include a 3-axis gyroscope, an accelerometer sensor and a magnetometer sensor, they:

    • [C-4-1] MUST implement a TYPE_ROTATION_VECTOR composite sensor.

    If device implementations include a 3-axis accelerometer and a 3-axis gyroscope sensor, they:

    • [C-5-1] MUST implement the TYPE_GRAVITY and TYPE_LINEAR_ACCELERATION composite sensors.

  • 7.3.10 Biometric Sensors : Updates to sensor requirements for biometric sensors.

    See revision

    Biometric sensors can be classified as Class 3 (formerly Strong ), Class 2 (formerly Weak ), or Class 1 (formerly Convenience ) based on their spoof and imposter acceptance rates, and on the security of the biometric pipeline. This classification determines the capabilities the biometric sensor has to interface with the platform and with third-party applications. Sensors need to meet additional requirements as detailed below if they wish to be classified as either Class 1 , Class 2 or Class 3 . Sensors are classified as Class 1 by default, and need to meet additional requirements as detailed below if they wish to be classified as either Class 2 or Class 3 . Both Class 2 and Class 3 biometrics get additional capabilities as detailed below.

    If device implementations wish to treat a biometric sensor as Class 1 (formerly Convenience ), they:

    • [C-1-11] MUST have a spoof and imposter acceptance rate not higher than 30%, with (1) a spoof and imposter acceptance rate for Level A presentation attack instrument (PAI) species not higher than 30%, and (2) a spoof and imposter acceptance rate of Level B PAI species not higher than 40%, as measured by the Android Biometrics Test Protocols.

    If device implementations wish to treat a biometric sensor as Class 2 (formerly Weak ), they:

    • [C-2-2] MUST have a spoof and imposter acceptance rate not higher than 20%, with (1) a spoof and imposter acceptance rate for Level A presentation attack instrument (PAI) species not higher than 20%, and (2) a spoof and imposter acceptance rate of Level B PAI species not higher than 30%, as measured by the Android Biometrics Test Protocols .

    If device implementations wish to treat a biometric sensor as Class 3 (formerly Strong ), they:

    • [C-3-3] MUST have a spoof and imposter acceptance rate not higher than 7%, with (1) a spoof and imposter acceptance rate for Level A presentation attack instrument (PAI) species not higher than 7%, and (2) a spoof and imposter acceptance rate of Level B PAI species not higher than 20%, as measured by the Android Biometrics Test Protocols .

  • 7.3.13 IEEE 802.1.15.4 (UWB) : Added a new requirements section for UWB.

    See revision

    7.3.13. IEEE 802.1.15.4 (UWB)

    If device implementations include support for 802.1.15.4 and expose the functionality to a third-party application, they:

    • [C-1-1] MUST implement the corresponding Android API in android.uwb.
    • [C-1-2] MUST report the hardware feature flag android.hardware.uwb.
    • [C-1-3] MUST support all the relevant UWB profiles defined in Android implementation.
    • [C-1-4] MUST provide a user affordance to allow the user to toggle the UWB radio on/off state.
    • [C-1-5] MUST enforce that apps using UWB radio hold UWB_RANGING permission (under NEARBY_DEVICES permission group).
    • [C-1-6] Are STRONGLY RECOMMENDED to pass the relevant conformance and certification tests defined by standard organizations, including FIRA , CCC and CSA .

  • 7.4.1 Telephony : Updates to telephony requirements for GSM and CDMA telephony, and cellular usage settings.

    See revision

    If device implementations support eUICCs or eSIMs/embedded SIMs and include a proprietary mechanism to make eSIM functionality available for third-party developers, they:

    If device implementations include GSM or CDMA telephony, then:

    If the device device implementations include GSM or CDMA telephony and provide a system status bar, then:

    • [C-6-7] MUST select a representative active subscription for a given group UUID to display to the user in any affordances that provide SIM status information. Examples of such affordances include the status bar cellular signal icon or quick settings tile.
    • [C-SR] It is STRONGLY RECOMMENDED that the representative subscription is chosen to be the active data subscription unless the device is in a voice call, during which it is STRONGLY RECOMMENDED that the representative subscription is the active voice subscription.

    If device implementations include GSM or CDMA telephony, then:

    • [C-6-8] MUST be capable of opening and concurrently utilizing the maximum number of logical channels (20 in total) for each UICC per ETSI TS 102 221.
    • [C-6-10] MUST NOT apply any of the following behaviors to active carrier apps (as designated by TelephonyManager#getCarrierServicePackageName ) automatically or without explicit user confirmation:
      • Revoke or limit network access
      • Revoke permissions
      • Restrict background or foreground app execution beyond the existing power management features included in AOSP
      • Disable or uninstall the app

    If device device implementations include GSM or CDMA telephony and all active, non-opportunistic subscriptions that share a group UUID are disabled, physically removed from the device, or marked opportunistic, then the device:

    • [C-7-1] MUST automatically disable all remaining active opportunistic subscriptions in the same group.

    If device implementations include GSM telephony but not CDMA telephony, they:

    If the device implementations support eUICCs with multiple ports and profiles, they:

  • 7.4.1.1 Number Blocking Compatibility : Updates to the number blocking requirements.

    See revision

    If device implementations report the android.hardware.telephony feature , they:

    • [C-1-4] MUST write to the platform call log provider for a blocked call and MUST filter calls with BLOCKED_TYPE out of the default call log view in the pre-installed dialer app.
    • SHOULD provide a user affordance to show blocked calls in the pre-installed dialer app.

  • 7.4.1.3 Cellular NAT-T Keepalive Offload : New section for Cellular NAT-T Keepalive Offload.

    See revision

    7.4.1.3. Cellular NAT-T Keepalive Offload

    Device implementations:

    • SHOULD include support for Cellular keepalive offload.

    If device implementations include support for Cellular keepalive offload and exposes the functionality to third-party apps, they:

    • [C-1-1] MUST support the SocketKeepAlive API.
    • [C-1-2] MUST support at least one concurrent keepalive slot over cellular.
    • [C-1-3] MUST support as many concurrent cellular keepalive slots as are supported by the Cellular Radio HAL.
    • [C-SR] Are STRONGLY RECOMMENDED to support at least three cellular keepalive slots per radio instance.

    If device implementations do not include support for cellular keepalive offload, they:

    • [C-2-1] MUST return ERROR_UNSUPPORTED.

  • 7.4.2.5 Wi-Fi Location (Wi-Fi Round Trip Time - RTT) : Updates to Wi-Fi location accuracy.

    See revision

    If device implementations include support for Wi-Fi Location and expose the functionality to third-party apps, then they:

    • [C-1-4] MUST be accurate to within 2 meters at 80 MHz bandwidth at the 68th percentile (as calculated with the Cumulative Distribution Function).
    • [C-SR] Are STRONGLY RECOMMENDED to report it accurately to within 1.5 meters at 80 MHz bandwidth at the 68th percentile (as calculated with the Cumulative Distribution Function).

  • 7.4.2.6 Wi-Fi Keepalive Offload : Updated to add cellular keepalive offload requirements.

    See revision

    Device implementations:

    • SHOULD include support for Wi-Fi keepalive offload.

    If device implementations include support for Wi-Fi keepalive offload and expose the functionality to third-party apps, they:

    • [C-1-1] MUST support the SocketKeepAlive API.
    • [C-1-2] MUST support at least three concurrent keepalive slots over Wi-Fi
      and at least one keepalive slot over cellular.

    If device implementations do not include support for Wi-Fi keepalive offload, they:

  • 7.4.2.9 Trust On First Use (TOFU) : Added Trust on First Use requirements section.

    See revision

    7.4.2.9 Trust On First Use (TOFU)

    If device implementations support Trust on first usage (TOFU) and allow the user to define WPA/WPA2/WPA3-Enterprise configurations, then they:

    • [C-4-1] MUST provide the user an option to select to use TOFU.

  • 7.4.3 Bluetooth : Update to Bluetooth requirements.

    See revision

    If device implementations support Bluetooth Audio profile, they:

    • SHOULD support Advanced Audio Codecs and Bluetooth Audio Codecs (eg LDAC) with A2DP.

    If device implementations return true for the BluetoothAdapter.isLeAudioSupported() API, then they:

    • [C-7-1] MUST support unicast client.
    • [C-7-2] MUST support 2M PHY.
    • [C-7-3] MUST support LE Extended advertising.
    • [C-7-4] MUST support at least 2 CIS connections in a CIG.
    • [C-7-5] MUST enable BAP unicast client, CSIP set coordinator, MCP server, VCP controller, CCP server simultaneously.
    • [C-SR] Are STRONGLY RECOMMENDED to enable HAP unicast client.

    If device implementations return true for the BluetoothAdapter.isLeAudioBroadcastSourceSupported() API, then they:

    • [C-8-1] MUST support at least 2 BIS links in a BIG.
    • [C-8-2] MUST enable BAP broadcast source, BAP broadcast assistant simultaneously.
    • [C-8-3] MUST support LE Periodic advertising.

    If device implementations return true for the BluetoothAdapter.isLeAudioBroadcastAssistantSupported() API, then they:

    • [C-9-1] MUST support PAST (Periodic Advertising Sync Transfer).
    • [C-9-2] MUST support LE Periodic advertising.

    If device implementations declare FEATURE_BLUETOOTH_LE , they:

    • [C-10-1] MUST have RSSI measurements be within +/-9dB for 95% of the measurements at 1m distance from a reference device transmitting at ADVERTISE_TX_POWER_HIGH in line of sight environment.
    • [C-10-2] MUST include Rx/Tx corrections to reduce per-channel deviations so that the measurements on each of the 3 channels, on each of the antennas (if multiple are used), are within +/-3dB of one another for 95% of the measurements.
    • [C-SR] Are STRONGLY RECOMMENDED to measure and compensate for Rx offset to ensure the median BLE RSSI is -60dBm +/-10 dB at 1m distance from a reference device transmitting at ADVERTISE_TX_POWER_HIGH , where devices are oriented such that they are on 'parallel planes' with screens facing the same direction.
    • [C-SR] Are STRONGLY RECOMMENDED to measure and compensate for Tx offset to ensure the median BLE RSSI is -60dBm +/-10 dB when scanning from a reference device positioned at 1m distance and transmitting at ADVERTISE_TX_POWER_HIGH , where devices are oriented such that they are on 'parallel planes' with screens facing the same direction.

    يوصى بشدة باتباع خطوات إعداد القياس المحددة في متطلبات معايرة الحضور .

    If device implementations support Bluetooth version 5.0, then they:

    • [C-SR] Are STRONGLY RECOMMENDED to provide support for:
      • LE 2M PHY
      • LE Codec PHY
      • LE Advertising Extension
      • Periodic advertising
      • At least 10 advertisement sets
      • At least 8 LE concurrent connections. Each connection can be in either connection topology roles.
      • LE Link Layer Privacy
      • A "resolving list" size of at least 8 entries

  • 7.4.9 UWB : Added a requirements section for UWB hardware.

    See revision

    7.4.9. UWB

    If device implementations report support for feature android.hardware.uwb via the android.content.pm.PackageManager class, then they:

    • [C-1-1] MUST ensure the distance measurements are within +/-15 cm for 95% of the measurements in the line of sight environment at 1m distance in a non-reflective chamber.
    • [C-1-2] MUST ensure that the median of the distance measurements at 1m from the reference device is within [0.75m, 1.25m], where ground truth distance is measured from the top edge of the DUT held face up and tilted 45 degrees.

    يوصى بشدة باتباع خطوات إعداد القياس المحددة في متطلبات معايرة الحضور .

  • 7.5 Cameras : Updates to the requirements for HDR 10-bit output capability.

    See revision

    If device implementations support HDR 10-bit output capability, then they:

    • [C-2-1] MUST support at least the HLG HDR profile for every camera device that supports 10-bit output.
    • [C-2-2] MUST support 10-bit output for either the primary rear-facing or the primary front-facing camera.
    • [C-SR] Are STRONGLY RECOMMENDED to support 10-bit output for both primary cameras.
    • [C-2-3] MUST support the same HDR profiles for all BACKWARD_COMPATIBLE-capable physical sub-cameras of a logical camera, and the logical camera itself.

    For Logical camera devices which support 10-bit HDR that implement the android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO API, they:

    • [C-3-1] MUST support switching between all the backwards-compatible physical cameras via the CONTROL_ZOOM_RATIO control on the logical camera.

  • 7.7.2 USB Host Mode : Revisions for dual role ports.

    See revision

    If device implementations include a USB port supporting host mode and USB Type-C, they:

    • [C-4-1] MUST implement Dual Role Port functionality as defined by the USB Type-C specification (section 4.5.1.3.3). For Dual Role Ports, On devices that include a 3.5mm audio jack, the USB sink detection (host mode) MAY be off by default but it MUST be possible for the user to enable it.

  • 7.11 Media Performance Class : Updated to include Android T.

    See revision

    If device implementations return non-zero value for android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS , they:

    • [C-1-3] MUST meet all requirements for "Media Performance Class" described in section 2.2.7 .

    In other words, media performance class in Android T is only defined for handheld devices at version T, S or R.

    See section 2.2.7 for device-specific requirements.

9. Security Model Compatibility

  • 9.1 Permissions : Extend accepted paths for permissions allowlists for preinstalled apps to APEX files.

    See revision

    • [C-0-2] Permissions with a protectionLevel of PROTECTION_FLAG_PRIVILEGED MUST only be granted to apps preinstalled in the privileged path(s) of the system image (as well as APEX files ) and be within the subset of the explicitly allowlisted permissions for each app. The AOSP implementation meets this requirement by reading and honoring the allowlisted permissions for each app from the files in the etc/permissions/ path and using the system/priv-app path as the privileged path.

  • 9.7 Security Features : Updates to initialization requirements to maintain kernel integrity.

    See revision

    Kernel integrity and self-protection features are integral to Android security. Device implementations:

    • [C-SR] Are STRONGLY RECOMMENDED to enable stack initialization in the kernel to prevent uses of uninitialized local variables ( CONFIG_INIT_STACK_ALL or CONFIG_INIT_STACK_ALL_ZERO ). Also, device implementations SHOULD NOT assume the value used by the compiler to initialize the locals.

  • 9.8.7 Privacy — Clipboard Access : Automatically clear clipboard data after 60 minutes following a cut/copy/paste activity to protect user privacy.

    See revision

    Device implementations:

    • [C-0-1] MUST NOT return a clipped data from the clipboard (eg via the ClipboardManager API) unless the 3rd-party app is the default IME or is the app that currently has focus.
    • [C-0-2] MUST clear clipboard data at most 60 minutes after it has last been placed in a clipboard or read from a clipboard.

  • 9.11 Keys and Credentials : Updates to the secure lock screen requirements, including the addition of ECDH and 3DES to crypto algorithms.

    See revision

    When the device implementation supports a secure lock screen, it:

    • [C-1-2] MUST have implementations of RSA, AES, ECDSA, ECDH (if IKeyMintDevice is supported), 3DES, and HMAC cryptographic algorithms and MD5, SHA1, and SHA-2 family hash functions to properly support the Android Keystore system's supported algorithms in an area that is securely isolated from the code running on the kernel and above. يجب أن يحظر العزل الآمن جميع الآليات المحتملة التي قد تصل من خلالها kernel أو رمز مساحة المستخدمين إلى الحالة الداخلية للبيئة المعزولة ، بما في ذلك DMA. يلبي مشروع Android مفتوح المصدر (AOSP) المنبع هذا المطلب باستخدام تطبيق Trusty ، لكن حلًا آخر قائمًا على ARM TrustZone أو تطبيقًا آمنًا تمت مراجعته من قِبل جهة خارجية لعزل مناسب قائم على برنامج Hypervisor يعد خيارات بديلة.

  • 9.11.1 Secure Lock Screen, Authentication, and Virtual Devices : Added requirements section for virtual devices and authentication transfers.

    See revision

    If device implementations add or modify the authentication methods to unlock the lock screen and a new authentication method is based on a physical token or the location:

    • [C-6-3] The user MUST be challenged for one of the recommended primary authentication methods (egPIN, pattern, password) at least once every 4 hours or less. When a physical token meets the requirements for TrustAgent implementations in CX, timeout restrictions defined in C-9-5 apply instead.

    If device implementations allow applications to create secondary virtual displays and do not support associated input events, such as via VirtualDeviceManager , they:

    • [C-9-1] MUST lock these secondary virtual display(s) when the device's default display is locked, and unlock these secondary virtual display(s) when the device's default display is unlocked.

    If device implementations allow applications to create secondary virtual displays and support associated input events, such as via VirtualDeviceManager , they:

    • [C-10-1] MUST support separate lock states per virtual device
    • [C-10-2] MUST disconnect all virtual devices upon idle timeout
    • [C-10-3] MUST have an idle timeout
    • [C-10-4] MUST lock all displays when the user initiates a lockdown , including via the lockdown user affordance required for handheld devices (see Section 2.2.5[9.11/H-1-2] )
    • [C-10-5] MUST have separate virtual device instances per user
    • [C-10-6] MUST disable the creation of associated input events via VirtualDeviceManager when indicated by DevicePolicyManager.setNearbyAppStreamingPolicy
    • [C-10-7] MUST use a separate clipboard solely for each virtual device (or disable the clipboard for virtual devices)
    • [C-10-11] MUST disable authentication UI on virtual devices, including knowledge factor entry and biometric prompt
    • [C-10-12] MUST restrict intents initiated from a virtual device to display only on the same virtual device
    • [C-10-13] MUST not use a virtual device lock state as user authentication authorization with the Android Keystore System. See KeyGenParameterSpec.Builder.setUserAuthentication* .

    When device implementations allow the user to transfer the primary authentication knowledge-factor from a source device to a target device, such as for initial setup of the target device, they:

    • [C-11-1] MUST encrypt the knowledge-factor with protection guarantees similar to those described in the Google Cloud Key Vault Service security whitepaper when transferring the knowledge-factor from the source device to the target device such that the knowledge-factor cannot be remotely decrypted or used to remotely unlock either device.
    • [C-11-2] MUST, on the source device , ask the user to confirm the knowledge-factor of the source device before transferring the knowledge-factor to the target device.
    • [C-11-3] MUST, on a target device lacking any set primary authentication knowledge-factor, ask the user to confirm a transferred knowledge-factor on the target device before setting that knowledge-factor as the primary authentication knowledge-factor for the target device and before making available any data transferred from a source device.

    If device implementations have a secure lock screen and include one or more trust agents, which call the TrustAgentService.grantTrust() System API with the FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE flag they:

    • [C-12-1] MUST only call grantTrust() with the flag when connected to a proximate physical device with a lockscreen of its own, and when the user has authenticated their identity against that lockscreen. Proximate devices can use on-wrist or on-body detection mechanisms after a one-time user unlock to satisfy the user authentication requirement.
    • [C-12-2] MUST put the device implementation into the TrustState.TRUSTABLE state when the screen is turned off (such as via a button press or display time out) and the TrustAgent has not revoked trust. The AOSP satisfies this requirement.
    • [C-12-3] MUST only move the device from TrustState.TRUSTABLE to the TrustState.TRUSTED state if the TrustAgent is still granting trust based on the requirements in C-12-1.
    • [C-12-4] MUST call TrustManagerService.revokeTrust() after a maximum of 24 hours from granting trust, an 8 hour idle window, or when the underlying connection to the proximate physical device is lost.

    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-8] MUST block activities with the attribute android:canDisplayOnRemoteDevices or the meta-data android.activity.can_display_on_remote_devices set to false from being started on the virtualdevice.
    • [C-13-9] MUST block activities which do not explicitly enable streaming and which indicate they show sensitive content, including via SurfaceView#setSecure, FLAG_SECURE, or SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS, from being started on the virtual device.
    • [C-13-10] MUST disable installation of apps initiated from virtual devices.

  • 9.11.2 Strongbox : Making insider attack resistance (IAR) a necessary requirement.

    See revision

    To validate compliance with [C-1-3] through [C-1-9], device implementations:

    • [C-SR] are STRONGLY RECOMMENDED to provide insider attack resistance (IAR), which means that an insider with access to firmware signing keys cannot produce firmware that causes the StrongBox to leak secrets, to bypass functional security requirements or otherwise enable access to sensitive user data. The recommended way to implement IAR is to allow firmware updates only when the primary user password is provided via the IAuthSecret HAL. IAR will become a MUST requirement in Android 14 (AOSP experimental).

  • 9.11.3 Identity Credential : Added information about the Identity Credential system reference implementation.

    See revision

    The Identity Credential System is defined and achieved by implementing all APIs in the android.security.identity.* package. These APIs allows app developers to store and retrieve user identity documents. Device implementations:

    The upstream Android Open Source Project provides a reference implementation of a trusted application ( libeic ) that can be used to implement the Identity Credential system.

  • 9.11.4 ID Attestation : Added a section for ID attestation requirement.

    See revision

    9.11.4. ID Attestation

    Device implementations MUST support ID attestation .

  • 9.17 Android Virtualization Framework : Added a requirements section for Android Virtualization Framework.

    See revision

    9.17. Android Virtualization Framework

    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.
    • [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 NOT allow untrusted code (eg 3p apps) to create and run a Protected Virtual Machine. Note: This might change in future Android releases.
    • [C-1-5] MUST NOT allow a Protected Virtual Machine 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.

    If the device implements support for the Android Virtualization Framework APIs ( android.system.virtualmachine.* ), then any Protected Virtual Machine instance:

    • [C-2-1] MUST be able to run all operating systems available in the virtualization APEX in a Protected Virtual Machine.
    • [C-2-2] MUST NOT allow a Protected Virtual Machine 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 Machine 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 Machine defense-in-depth mechanisms (eg SELinux for pVMs) even for non-Microdroid operating systems.
    • [C-2-6] MUST ensure that the pVM firmware refuses to boot if it cannot verify the initial image.
    • [C-2-7] MUST ensure that the pVM firmware refuses to 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 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 VM and before it is returned to the host (eg the pVM is destroyed).
    • [C-3-3] MUST ensure that the pVM firmware is loaded and executed prior to any code in a pVM.
    • [C-3-4] MUST ensure that BCC and CDIs provided to a pVM instance can only be derived by that particular instance.

    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 support Isolated Compilation 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-6-2] MUST do DICE properly ie provide the correct values. But it might not have to go to that level of detail.

Back to top