متطلبات الاختبار

اختبارات GTS ( GtsSafetyCenterTestCases )

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

القيود هي كما يلي:

  • يجب أن تكون هناك سبع مجموعات مصادر لمركز الأمان على الأقل، والتي يجب أن تظل في الحالة الافتراضية أو غير المعدلة. يتم أحيانًا دعم بعض الحقول المحددة مثل عناوين المصادر وحالة العرض الأولية والملخص بسلاسل قابلة للتراكب ويمكن تعديلها.
  • بالنسبة إلى GoogleAppSecuritySources :

    • لا تقم بإزالة أو تعديل مصدر الأمان GooglePlayProtect .
    • يمكنك إزالة أو تغيير مصدر أمان GoogleAppProtectionService . إذا كان موجودا:
      • يجب أن يدعم التسجيل.
      • إذا لم يتغير اسم الحزمة، فيجب أن تحتوي على initialDisplayState="hidden" في Android 13؛ في Android 14، يجب أن يكون issue-only-safety-source ، ويجب أن تظل deduplicationGroup دون تغيير.
      • إذا تم تغيير اسم الحزمة، فيجب أن تحمل الدور "android.app.role.SYSTEM_APP_PROTECTION_SERVICE" ؛ بالإضافة إلى ذلك، في Android 14، يجب ألا تحتوي على deduplicationGroup .
  • بالنسبة إلى AndroidLockScreenSources :

    • يلزم وجود مثيل summary للمجموعة ويمكنك تعديله، بما في ذلك تراكب السلسلة.
    • يجب أن يكون هناك مصدر أمان واحد على الأقل.
    • يهدف مصدر الأمان الأول إلى أن يكون المصدر الذي يتحكم في إعدادات شاشة القفل ولا ينبغي أن يكون قادرًا على دفع المشكلات أو الإدخالات بشكل أكثر خطورة من SEVERITY_LEVEL_RECOMMENDATION ( maxSeverityLevel="300" أو ما يصل إلى بطاقات الإدخال أو التحذير الصفراء). في Android 14، يجب أن تظل deduplicationGroup دون تغيير.
    • تهدف مصادر الأمان الأخرى إلى أن تكون مصادر مرتبطة بآليات فتح القفل البيومترية ويجب أن تحتوي على maxSeverityLevel="0" .
  • في Android 13، لا تقم بتعديل GoogleAccountSources أو GoogleDeviceFinderSources أو AndroidAdvancedSources . في Android 14، يمكنك إزالة بعض المصادر الجديدة التي تم تقديمها في هذه المجموعات (مثل النسخ الاحتياطي والاستعادة)، ويمكنك أيضًا إلحاق مصادر ثابتة جديدة بمجموعة AndroidAdvancedSources .

  • بالنسبة إلى GoogleUpdateSources :

    • يمكنك تغيير intentAction لـ GoogleSecurityUpdates ويمكنك تعديله باستخدام تراكب السلسلة.
    • لا تقم بتعديل GooglePlaySystemUpdate .
  • بالنسبة إلى AndroidPrivacySources :

    • يمكنك إضافة أو إزالة أو تعديل بعض المصادر، طالما أنها issue-only .
    • يجب عليهم الاحتفاظ بـ packageName="com.google.android.permissioncontroller" .
    • لا تقم بتعديل بقية مصادر AndroidPrivacySources .
  • بالنسبة لبقية مجموعات مصادر الأمان (إن وجدت):

    • يجب ألا تحتوي المجموعات summary أو statelessIconType ، مما يؤدي إلى مجموعة SAFETY_SOURCES_GROUP_TYPE_RIGID ( SAFETY_SOURCES_GROUP_TYPE_STATELESS في Android 14).
    • يجب أن يكون كل مصدر داخل كل مجموعة ثابتًا أو أن يكون به maxSeverityLevel="0" ، على سبيل المثال، يُسمح له بإرسال إدخالات باللون الرمادي أو الأخضر ولكن دون حدوث مشكلات.

اختبارات CTS ( CtsSafetyCenterTestCases )

بدءًا من Android 13، تنطبق اختبارات CTS على جميع مصنعي المعدات الأصلية الذين يدعمون PermissionController .

اختبارات ملف التكوين ( XmlConfigTest )

تضمن هذه الاختبارات:

  • يتطابق ملف تكوين XML الذي تم تحليله مع التكوين الذي تم تحليله وعرضه بواسطة مركز الأمان وأن هذا التحليل ناجح.
  • إذا كان الإجراء المقصود android.settings.PRIVACY_ADVANCED_SETTINGS موجودًا في ملف XML، فيجب حل هذا الإجراء.
  • إذا كان الإجراء المقصود android.settings.PRIVACY_CONTROLS موجودًا في ملف XML، فيجب حل هذا الإجراء.

اختبارات واجهة المستخدم ( SafetyCenterActivityTest )

تضمن هذه الاختبارات:

  • يعمل إجراء الهدف android.intent.action.SAFETY_CENTER على حل وفتح شاشة إعدادات الأمان والخصوصية عند تمكين مركز الأمان، وشاشة الإعدادات عند تعطيل مركز الأمان.

اختبارات واجهة برمجة التطبيقات ( SafetyCenterManagerTest )

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

تضمن هذه الاختبارات ما يلي:

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

اختبار مركز الأمان غير مدعوم ( SafetyCenterUnsupportedTest )

يضمن هذا الاختبار تعطيل مركز الأمان عندما لا يدعمه الجهاز عند تعطيل الدعم في ملف تكوين XML لإطار العمل.

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

يضمن هذا الاختبار ما يلي:

  • يفتح إجراء الهدف android.intent.action.SAFETY_CENTER شاشة الإعدادات.
  • يقوم SafetyCenterManager.isSafetyCenterEnabled بإرجاع false .
  • لا تستجيب معظم واجهات برمجة تطبيقات مركز الأمان عند الاتصال بها.

اختبارات فئات البيانات ( SafetySourceDataTest ، SafetySourceIssueTest ، إلخ)

تضمن اختبارات فئة البيانات مثل SafetySourceDataTest و SafetySourceIssueTest أن فئات البيانات التي يعرضها مركز الأمان تعمل على النحو المنشود، على سبيل المثال، SafetySourceData و SafetySourceIssue والفئات الداخلية الأخرى ذات الصلة.

اختبارات MTS ( SafetyCenterFunctionalTestCases وغيرها)

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

اختبارات واجهة برمجة التطبيقات ( SafetyCenterManagerTest )

تشبه هذه الاختبارات اختبار CTS SafetyCenterManagerTest ، إلا أنها تختبر المتطلبات التي يمكن أن تتغير عبر التحديثات الرئيسية، على سبيل المثال:

  • التحقق من المحتوى الفعلي للبيانات التي يتم إرجاعها بواسطة واجهات برمجة التطبيقات الداخلية المعرضة لواجهة المستخدم

اختبارات واجهة المستخدم ( SafetyCenterActivityTest ، SafetyCenterStatusCardTest ، SafetyCenterQsActivityTest ، إلخ)

تضمن هذه الاختبارات:

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

  • حالات الحافة الإضافية مثل حالات الخطأ والحالات المعلقة.

اختبارات المستخدمين المتعددين ( SafetyCenterMultiUsersTest )

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

يضمن هذا الاختبار ما يلي:

  • يتم دمج البيانات الخاصة بالمستخدم مع ملف التعريف المُدار المرتبط به إذا كان موجودًا.
  • يمكن فقط للمصادر التي تم وضع علامة profile="all_profiles" عليها توفير البيانات في الملف الشخصي المُدار للمستخدم.
  • يتم إنشاء إدخال جديد لكل ملف تعريف مُدار مرتبط بمستخدم.
  • لا تتسرب البيانات الخاصة بمستخدم واحد إلى مستخدم آخر لا علاقة له به.