تلخص هذه الصفحة التغييرات التي تم إجراؤها على Camera Image Test Suite (ITS) في Android 11. وتندرج التغييرات ضمن الفئات التالية:
- تغييرات الأجهزة
- الاختبارات الإلزامية لمستوى واجهة برمجة التطبيقات (API) الأولى
- تم التحقق من صحة اختبار الإضاءة
- يتغير اسم المشهد
- اختبار التغييرات والإضافات
- زيادة اختبار الكاميرا المحدودة
تغييرات الأجهزة
يقدم Android 11 العديد من التغييرات على الأجهزة لتقليل التكلفة وزيادة التوفر. وتندرج هذه التغييرات ضمن الفئات التالية:
- الشركة المصنعة الإضافية
- طرق التصنيع الموحدة
- زيادة خيارات الجهاز اللوحي
- انخفاض فتح الجهاز اللوحي
- وحدة تحكم دمج أجهزة الاستشعار الجديدة
الشركة المصنعة الإضافية
إن Rahi Systems مؤهلة لإنتاج حاويات اختبار ITS بالإضافة إلى موردنا الحالي، تصميم MYWAY. معلومات الشركة للبائعين المؤهلين هي كما يلي:
شركة راي سيستمز
48303 شارع فريمونت، فريمونت كاليفورنيا 94538، الولايات المتحدة الأمريكية
rahisystems.com/products/android-device-testing-equipment/
androidpartner@rahisystems.com
+1-510-319-3802تصميم ماي واي
4F., No. 163, Fu-Ying Road, XinZhuang District, مدينة تايبيه الجديدة, تايوان
twmyway.com
sales@myway.tw
+886-2-29089060
طرق التصنيع الموحدة
تم إعادة تصميم حاوية اختبار ITS-in-a-box العادية (RFoV) لاستخدام طرق التصنيع المستخدمة في صندوق مجال الرؤية الواسع (WFoV) ومرفقات اختبار صندوق دمج المستشعر . الوظيفة متطابقة، ومن أجل البساطة، يُشار إلى التصميم باسم rev1a . تسمح إعادة التصميم للمصنعين بتخزين نوع واحد من البلاستيك لتصنيع جميع حاويات الاختبار. بالإضافة إلى ذلك، تم إعادة تصميم حامل الكمبيوتر اللوحي وحوامل الإضاءة للتعامل مع تنوع أكبر في الأجهزة اللوحية وأشرطة الإضاءة LED.
لتنزيل أحدث الأوصاف والرسومات الميكانيكية، راجع مربع RFoV (rev1a) ومربع WFoV (rev2.9) .
زيادة خيارات الجهاز اللوحي
تتم إضافة الأجهزة اللوحية بما في ذلك Samsung Galaxy Tab A 10.1 وChuwi Hi9 Air 10.1 إلى قائمة الأجهزة اللوحية الموصى بها. من المهم ألا يحتوي الجهاز اللوحي على تعديل عرض النبض (PWM) لضبط سطوع الشاشة للتخلص من النطاقات في الصور الملتقطة.
للحصول على أحدث المعلومات حول الأجهزة اللوحية الموصى بها، راجع متطلبات الأجهزة اللوحية .
انخفاض فتح الجهاز اللوحي
للسماح باستخدام جهاز Galaxy Tab A 10.1، تم تقليل ارتفاع فتحة الجهاز اللوحي قليلاً لكل من حاويات اختبار RFoV (rev1a) وWFoV (rev2). المراجعات التي تعكس هذه التغييرات هي rev1a.1 وrev2.9. بالنسبة لهذه الرسومات، راجع مربع RFoV (rev1a) ومربع WFoV (rev2.9) .
وحدة تحكم دمج أجهزة الاستشعار الجديدة
تم إعادة تصميم الأجهزة الخاصة بوحدة التحكم في دمج المستشعر لتحسين قابلية التصنيع. تعتمد وحدة التحكم الجديدة على Arduino ، مع درع لوحة توجيه مخصص يتم تركيبه أعلى Arduino. يوضح الشكل 1 الدرع والشكل 2 يوضح الرسم الميكانيكي للعلبة. يتم تشغيل وحدة التحكم الجديدة بواسطة مصدر إمداد واحد بجهد 5 فولت يعمل على تشغيل المحرك مباشرة. يتم التحكم في الإلكترونيات بالكامل من خلال موصل USB. يسمح مصدر الطاقة المنفصل بالعزل التام بين إلكترونيات التحكم ومحرك المؤازرة. بالإضافة إلى ذلك، يمكن لوحدة تحكم واحدة التحكم في ما يصل إلى ستة محركات مؤازرة.
الشكل 1. منظر علوي لدرع Arduino
الشكل 2. تصميم الضميمة
Android 11 متوافق مع الإصدارات السابقة مع وحدات التحكم الحالية. لاستدعاء الاختبار باستخدام وحدة التحكم المعتمدة على Arduino:
python tools/run_all_tests.py device=# camera=# rot_rig=arduino:1 scenes=sensor_fusion
مستوى API الأول
في Android 10، تم تعيين اختبارات ITS على أنها MANDATED
و NOT_YET_MANDATED
. لبدء التشغيل كجهاز يعمل بنظام التشغيل Android 10، يجب اجتياز جميع الاختبارات MANDATED
. يمكن أن تفشل اختبارات NOT_YET_MANDATED
ولكن يتم جدولتها على أنها PASS
لتقارير التحقق من CTS. تنطبق متطلبات الاختبارات MANDATED
أيضًا على الأجهزة التي تمت ترقيتها. أدى هذا المطلب الخاص بالأجهزة التي تمت ترقيتها لاجتياز جميع الاختبارات MANDATED
إلى تأخير الاختبارات لتصبح اختبارات MANDATED
لأن الأجهزة القديمة يجب أن تجتاز الاختبارات أيضًا.
في Android 11، يتم إجراء الاختبارات MANDATED
من خلال علامة مستوى واجهة برمجة التطبيقات الأولى من خصائص الهاتف. بالنسبة للأجهزة التي تقوم بالترقية إلى Android 11، يتم تشغيل الاختبارات كاختبارات NOT_YET_MANDATED
، مما يعني أن الاختبار يمكن أن يفشل ولكن يتم جدولته على أنه PASS
في CtsVerifier.apk
.
على سبيل المثال:
- في Android 11، يكون اختبار
test_channel_saturation
MANDATED
للأجهزة التي يكون فيها مستوى واجهة برمجة التطبيقات الأول أكبر من 29. - في Android 10، يكون اختبار
test_channel_saturation
MANDATED
لجميع الأجهزة.
التحقق من صحة إضاءة المشهد
في Android 11، يتم التحقق من صحة إضاءة المشهد من خلال تحليل السطوع في زوايا المشهد. يتم التحقق من صحة جميع المشاهد اليدوية للإضاءة، ويتم التحقق من صحة المشاهد المستندة إلى الكمبيوتر اللوحي لكاميرات RFoV في منصة اختبار RFoV وكاميرات WFoV في منصة اختبار WFoV. إذا كانت مستويات الإضاءة غير كافية، فسيتم الإبلاغ عن خطأ ويفشل الاختبار.
يتغير اسم المشهد
في Android 10، يمثل المشهد 1 غالبية الاختبارات ونسبة كبيرة من إجمالي وقت الاختبار. إذا فشل أي اختبار داخل المشهد 1، فيجب إعادة تشغيل المشهد بأكمله. حسب التصميم، فإن إعادة تشغيل المشهد بأكمله يقلل من مرور الاختبارات الهامشية. في Android 11، يتم تقليل أوقات إعادة التشغيل عن طريق تقسيم المشهد 1 إلى مشهدين، المشهد 1_1 والمشهد 1_2.
ويوضح الجدول التالي أوقات الاختبار المجدولة للكاميرا الخلفية لهاتف Pixel 4 للمشاهد المختلفة. يتم تقسيم عدد الاختبارات لتعادل وقت الاختبار، وليس لتعادل عدد الاختبارات.
بالإضافة إلى ذلك، هناك تنظيف الاسم. المشهد 2 مقسم بالأحرف والمشهد 1 مقسم بالأرقام. التسميات للامتدادات المختلفة هي:
- مشاهد بنفس الرسم البياني، لكن باختبارات مختلفة:
*_1,2,3
- مشاهد ذات مخططات مختلفة، ولكن نفس الاختبارات:
*_a,b,c
مشهد | عدد الاختبارات | وقت تشغيل Pixel 4 (الدقيقة:الثانية) |
---|---|---|
0 | 11 | 1:12 |
1_1 | 22 | 5:12 |
1_2 | 13 | 5:20 |
2_أ | 5 | 3:22 |
2_ب | 1 | 0:24 |
2_ج | 1 | 0:24 |
3 | 6 | 2:04 |
4 | 2 | 2:46 |
تغييرات الاختبار
تم تحديث الاختبارات لاستخدام مستوى API الأول
في Android 11، يتم تحديث الاختبارات الموضحة في الجدول التالي لاستخدام علامة مستوى واجهة برمجة التطبيقات الأولى. تستخدم كل هذه الاختبارات مستوى واجهة برمجة التطبيقات الأول وهو 29 باستثناء اختبار test_tonemap_curve
، الذي يستخدم مستوى واجهة برمجة التطبيقات الأول وهو 30.
مشهد | اسم الاختبار | مستوى API الأول | وصف |
---|---|---|---|
0 | test_tonemap_curve | 30 | تأكد من أن خط الأنابيب يحتوي على مخرجات ألوان مناسبة باستخدام خريطة نغمة خطية وإدخال صورة مثالي (يعتمد على test_test_patterns ). |
1 | test_ae_precapture_trigger | 29 | اختبر جهاز حالة AE عند استخدام مشغل الالتقاط المسبق. تأكد من أن مشغل الالتقاط المسبق المعطل AE ليس له أي تأثير. |
test_channel_saturation | 29 | تأكد من تشبع قنوات RGB بقيم مماثلة لإزالة الصبغة في المناطق المشبعة. | |
2_أ/ب/ج | test_num_faces | 29 | زيادة التنوع العمري في مشاهد الوجه. |
اختبارات مع التغييرات
تم تحديث الاختبارات الموضحة في الجدول التالي في Android 11. تم توضيح التغييرات في عمود وصف التغييرات .
مشهد | اسم الاختبار | مستوى API الأول | وصف التغييرات |
---|---|---|---|
1 | test_burst_sameness_manual | 30 | تقليل التسامح إلى 2٪. |
4 | test_aspect_ratio_and_crop | 30 | التغيير للتشغيل على أجهزة محدودة. |
test_multi_camera_alignment | 30 | انتقل عبر الكاميرات بشكل فردي إذا لم يكن الالتقاط متعدد الكاميرات مدعومًا. أعد صياغة منطق اختيار الكاميرا ليأخذ في الاعتبار الأنظمة ثلاثية وأربع كاميرات، وتخطي الكاميرات الأحادية والعمق فقط والأشعة تحت الحمراء. |
اختبارات جديدة
تم تمكين الاختبارات الواردة في الجدول التالي في Android 11. ويتم تلخيص الاختبارات في الجدول ويتم توفير الأوصاف التفصيلية في الأقسام التالية.
مشهد | اسم الاختبار | مستوى API الأول | وصف |
---|---|---|---|
0 | test_vibration_restrictions | 30 | تأكد من عدم تفعيل التنبيهات والاهتزازات أثناء التقاط الصور. |
2_أ | test_jpeg_quality | 30 | اختبر أن جداول القياس تقلل من الضغط لزيادة جودة JPEG. |
2_د/2_ه | test_num_faces | 30 | زيادة التنوع العمري للوجه. |
2_ه | test_continuous_picture | 30 | تأكد من استقرار 3A في android.control.afAvailableModes = CONTINUOUS_PICTURE. |
يتغير | test_scene_change | 31 | يتم التأكيد على android.control.afSceneChange عند تغيير المشهد. |
6 | test_zoom | 30 | اختبار android.control.zoomRatioRange . |
Scene0/test_vibration_restriction
لا يتطلب هذا الاختبار مشهدًا محددًا، ولكن يجب وضع الجهاز قيد الاختبار (DUT) على سطح صلب أو تثبيته عليه. يتضمن ذلك التثبيت على حاويات اختبار ITS-in-a-box.
يؤكد
- لا توجد اهتزازات أثناء استخدام الكاميرا
Scene2_a/test_jpeg_quality
طريقة
يتم تعريف الأجزاء المختلفة من ملف JPEG بواسطة علامات ثنائية البايت. لمزيد من المعلومات، راجع جى بي إي جي .
يستخرج الاختبار مصفوفات التكميم من التقاط JPEG. علامة مصفوفات التكميم في التقاط JPEG هي التسلسل، [255، 219]. عندما يتم العثور على العلامة، فإن عنصري القائمة التاليين هما الحجم. عادةً ما تكون علامة حجم JPEG DQT هي [0, 132] = 256*0+132 = 132، وهو ما يمثل حجم بيانات DQT في التقاط JPEG. البيانات المضمنة هي من النموذج: [255، 219، 0، 132، 0 (علامة لمى)، مصفوفة لوما 8x8، 1 (علامة صفاء)، مصفوفة صفاء 8x8].
يبدو الرقم 0
لعلامة مصفوفة Luma و 1
لعلامة chroma متسقًا لعدد من الأجهزة بما في ذلك الهواتف التي تفصل المصفوفتين إلى أقسام DQT منفصلة في ملف JPEG. تميل مصفوفات لوما إلى الحصول على مجموعة متنوعة من القيم مقارنة بمصفوفات الصفاء لأن العين البشرية أكثر حساسية للوما من صور الصفاء وJPEG التي تأخذ ذلك في الاعتبار.
يتم عرض عينة مصفوفات Luma وChroma المستخرجة أدناه لعوامل الجودة 85 و25 لكاميرا Pixel 4 الخلفية التي تلتقط المشهد 2_a مع جهاز اختبار ITS. تزداد قيم المصفوفة (تشير إلى زيادة الضغط) بشكل كبير لإعداد الجودة الأقل. تتم طباعة هذه المصفوفات فقط باستخدام البرنامج النصي في حالة تطبيق العلامة debug=True
. لاحظ التباين الأكبر في الإدخالات في مصفوفات لوما مقارنة بمصفوفات اللونا.
luma matrix (quality = 85) chroma matrix (quality = 85)
[[ 5 3 4 4 4 3 5 4] [[ 5 5 5 7 6 7 14 8]
[ 4 4 5 5 5 6 7 12] [ 8 14 30 20 17 20 30 30]
[ 8 7 7 7 7 15 11 11] [30 30 30 30 30 30 30 30]
[ 9 12 17 15 18 18 17 15] [30 30 30 30 30 30 30 30]
[17 17 19 22 28 23 19 20] [30 30 30 30 30 30 30 30]
[26 21 17 17 24 33 24 26] [30 30 30 30 30 30 30 30]
[29 29 31 31 31 19 23 34] [30 30 30 30 30 30 30 30]
[36 34 30 36 28 30 31 30]] [30 30 30 30 30 30 30 30]]
luma matrix (quality = 25) chroma matrix (quality = 25)
[[ 32 22 24 28 24 20 32 28] [[ 34 36 36 48 42 48 94 52]
[ 26 28 36 34 32 38 48 80] [ 52 94 198 132 112 132 198 198]
[ 52 48 44 44 48 98 70 74] [198 198 198 198 198 198 198 198]
[ 58 80 116 102 122 120 114 102] [198 198 198 198 198 198 198 198]
[112 110 128 144 184 156 128 136] [198 198 198 198 198 198 198 198]
[174 138 110 112 160 218 162 174] [198 198 198 198 198 198 198 198]
[190 196 206 208 206 124 154 226] [198 198 198 198 198 198 198 198]
[242 224 200 240 184 202 206 198]] [198 198 198 198 198 198 198 198]]
يوضح الشكل 3 متوسط قيم المصفوفة للكاميرا الخلفية لهاتف Pixel 4 مقابل جودة JPEG. مع زيادة جودة JPEG، ينخفض مستوى الضغط (متوسط مصفوفة Luma/chroma DQT).
الشكل 3. متوسطات مصفوفة Luma/Chroma DQT للكاميرا الخلفية Pixel 4 مقابل جودة JPEG
يؤكد
- بالنسبة لـ [25، 45، 65، 86]، +20 في الجودة لديها 20٪ من متوسطات مصفوفة القياس الكمي.
- حمولات مصفوفة DQT هي أرقام مربعة.
يوضح الشكل 4 مثالاً لهاتف يفشل في الاختبار. لاحظ أنه بالنسبة للصور ذات الجودة المنخفضة جدًا ( jpeg.quality < 50
)، لا توجد زيادة في الضغط في مصفوفة التكميم.
الشكل 4. مثال على الاختبار الفاشل
Scene2_d/e test_num_faces
تمت إضافة مشهدين جديدين للكشف عن الوجه لزيادة تنوع الوجه في عمليات فحص خوارزمية اكتشاف الوجه. مع الاختبار المتكرر لعدد من الكاميرات، من المتوقع أن يكون الوجه الأكثر تحديًا هو الوجه الموجود في أقصى اليسار في المشهد 2_د. على وجه الخصوص، هناك قبعة ولحية في العارضة، وهو شيء جديد في مشاهد الوجه. وتظهر المشاهد الجديدة في الشكل 5 و 6.
الشكل 5. المشهد2_د
الشكل 6. المشهد2_ه
يؤكد
-
num_faces == 3
Scene2_e/test_continious_picture
طريقة
يستخدم اختبار test_continuous_picture
المشهد 2_e ولكن يمكن تمكينه مع أي من مشاهد الوجوه. في هذا الاختبار، تم التقاط 50 إطارًا بدقة VGA مع طلب الالتقاط أولاً بتعيين android.control.afMode = 4 (CONTINUOUS_PICTURE)
.
من المتوقع أن يستقر نظام 3A عند نهاية التقاط 50 إطارًا.
يؤكد
- 3A في حالة متقاربة عند نهاية الالتقاط.
Scene_change/test_scene_change
طريقة
تم تمكين اختبار جديد لاختبار ما إذا تم تأكيد علامة android.control.afSceneChange
من خلال تغيير المشهد. يستخدم تغيير المشهد الكمبيوتر اللوحي الذي يعرض مشهد الوجه ثم تشغيل الجهاز اللوحي وإيقاف تشغيله لإنشاء تغيير المشهد. يعيد المشهد استخدام scene2_e ولكنه موجود في مشهد منفصل بسبب التحكم المطلوب في الكمبيوتر اللوحي.
بالإضافة إلى ذلك، بالنسبة للاختبار اليدوي، يمكن إجراء تغيير المشهد عن طريق التلويح بيدك أمام الكاميرا.
ويبين الشكل 7 مخطط توقيت الاختبار. يتم ضبط التوقيت بين إيقاف تشغيل الشاشة والالتقاط بناءً على نتائج الأحداث من اللقطات السابقة.
الشكل 7. مخطط توقيت test_scene_change
شروط التحول:
- إذا كان هناك تغيير في المشهد وكان
afSceneChange == 1
، فسيُرجع الاختبارPASS
. - إذا كان هناك تغيير في المشهد وكان
afSceneChange == 0
، فسيُزاح تغيير المشهد بمقدار 5 إطارات مسبقًا لإعطاء مزيد من الوقت لتأكيدafSceneChange
. - إذا لم يكن هناك تغيير في المشهد وكان
afSceneChange == 1
، فسيُرجع الاختبارFAIL
. - إذا لم يكن هناك تغيير في المشهد وكان
afSceneChange == 0
، فإن تغيير المشهد ينتقل بمقدار 30 إطارًا سابقًا للحصول على تغيير المشهد أثناء الالتقاط.
يؤكد
- تبديل الشاشة (المشهد).
- علامة
afSceneChange
موجودة في [0، 1]. - إذا لم يتغير المشهد، فإن 3A يتقارب (مطابق وظيفيًا لـ
test_continuous_picture
). - إذا كان
afSceneChange == 1
، فيجب أن يتغير السطوع في المشهد. -
PASS
خلال ست محاولات مع تغيير التوقيت بناءً على النتائج السابقة.
المشهد6/test_zoom
طريقة
مطلوب مشهد جديد لاختبار android.control.zoomRatioRange
نظرًا لأن المشاهد المحددة إما لا تحتوي على ميزة صغيرة بما يكفي لتكبيرها (المشاهد [1، 2، 4]) أو أن المشهد يحتوي على العديد من الكائنات التي لا يمكن التعرف عليها بسهولة تعقيد استخراج الميزة (المشهد 3).
ويبين الشكل 8 المشهد الجديد بمجموعة منتظمة من الدوائر. تعمل مجموعة الدوائر على تخفيف متطلبات توسيط DUT/المخطط وتسمح بدائرة دائمًا بالقرب من مركز الصورة الملتقطة. في هذا المشهد، تغطي مجموعة من الدوائر مقاس 9 × 5 ذات حدود سوداء الجهاز اللوحي بأكمله. يتم استبدال دائرة واحدة بمربع في الزاوية اليمنى العليا لإظهار الاتجاه. تتميز أحجام الدوائر بميزة تبلغ مساحتها حوالي 7500 بكسل ( radius=50pixels
) لمستشعر 4000 × 3000 تم التقاطه بمجال رؤية (FoV) يبلغ حوالي 80 درجة.
الشكل 8. مشهد test_zoom
الشكل 9. تكبير/تصغير كاميرا Pixel 4[0] = [1، 3.33، 5.67، 8] صور مع وجود دائرة
يوضح الشكل 9 الصور الملتقطة بالكاميرا الخلفية لجهاز Pixel 4 مع زيادة التكبير من 1 إلى 8x بأربع خطوات. تم التقاط هذه المجموعة من الصور دون أي رعاية خاصة للتوسيط باستثناء استخدام فتحة اختبار الهاتف ذات الفتحتين لتمكين اختبار الكاميرات الأمامية والخلفية. من المتوقع وجود إزاحة عن المركز، ويتم ملاحظتها حيث أن لوح الرسم البياني يقع على يسار المركز قليلاً. بالإضافة إلى ذلك، يظهر المخطط كافيًا للاختبار مع نسب تكبير أعلى من 8x.
العثور على الدوائر
يتضمن الاختبار طريقة find_circle()
باستخدام findContours
التي تعثر على جميع الخطوط الكنتورية وتضيق خطوط البحث وصولاً إلى الدوائر المطلوبة عن طريق اختبار ما يلي:
- يجب أن تكون مساحة الخطوط أكبر من 10 بكسل.
- يجب أن تحتوي الخطوط على
NUM_PTS >= 15
. - يجب أن تحتوي الخطوط على مراكز سوداء.
- يجب أن تشبه الخطوط الكنتورية دائرة، أي أن مساحتها قريبة من منطقة pi*r2 في الكفاف.
نطاق الاختبار
android.control.zoomRatioRange
مقسم إلى 10 خطوات.
- [1، 7] الاختبارات [1، 1.67، 2.33، 3، 3.67، 4.33، 5، 5.67، 6.33، 7]
يتم إيقاف التكبير/التصغير إذا لامست الدائرة الموجودة حدود الصورة. هناك فحص للتأكد من الوصول إلى مستوى تكبير كافٍ في الاختبار (10x).
يؤكد
- تم العثور على دائرة واحدة على الأقل في كل إعداد تكبير/تصغير.
- تم اختبار 10x أو الحد الأقصى لـ
android.control.zoomRatioRange
. - مقاييس نصف قطر الدائرة مع التكبير/التصغير (RTOL 10% من المتوقع).
- إزاحة مركز الدائرة من المقاييس المركزية مع التكبير (RTOL 10% من المتوقع).
- تم الوصول إلى مستوى التكبير/التصغير الكافي (2x).
زيادة اختبار الكاميرا المحدودة
في Android 11، تختبر الاختبارات في الجدول التالي LIMITED
الكاميرات. بالإضافة إلى الاختبارات الجديدة ، تم تحديث اختبار scene4/test_aspect_ratio_and_crop
لتمكين اختبار الأجهزة LIMITED
ذات مستوى واجهة برمجة التطبيقات الأول البالغ 30 أو أعلى.
مشهد | اسم الاختبار |
---|---|
0 | test_vibration_restrictions |
2_أ | test_jpeg_quality |
2_د/2_ه | test_num_faces |
4 | test_aspect_ratio_and_crop |
6 | test_zoom |
يوضح الشكل 10 حلقة فك التشفير السرية لنظام Android 11 الخاص به. تُظهر حلقة فك التشفير السرية إعدادات الاختبار التي يتم من خلالها إجراء الاختبارات الفردية. البوابة مرمزة بالألوان لسهولة المشاهدة. عناصر البوابات الرئيسية هي:
-
MANUAL_SENSOR
-
READ_3A
*يتطلبMANUAL SENSOR
-
COMPUTE_TARGET_EXPOSURES
*يتطلبMANUAL SENSOR
-
PER_FRAME_CONTROL
-
RAW
-
SENSORS
*REALTIME
-
MULTI_CAMERA
MANUAL SENSOR
و READ_3A
و COMPUTE_TARGET_EXPOSURES
و PER_FRAME_CONTROL
بوابة غالبية الاختبارات. بالإضافة إلى ذلك، يتم تمييز الاختبارات التي تم تمكينها لأجهزة LIMITED
باللون الأخضر الفاتح.
الشكل 10. حلقة فك التشفير السرية لنظام Android 11