الزامات آزمون

تست های GTS ( GtsSafetyCenterTestCases )

تست های GTS محدودیت هایی را بر روی فایل پیکربندی اعمال می کنند. به به روز رسانی فایل پیکربندی مراجعه کنید. اگر دستگاه از مرکز ایمنی پشتیبانی نکند، دستگاهی از این آزمایش‌ها مستثنی است.

محدودیت ها به شرح زیر است:

  • باید حداقل هفت گروه منبع مرکز ایمنی وجود داشته باشد که باید در حالت تغییر نیافته یا پیش فرض باقی بمانند. برخی از فیلدهای خاص مانند عناوین منابع، وضعیت نمایش اولیه و خلاصه گاهی اوقات توسط رشته های قابل پوشش پشتیبانی می شوند و می توان آنها را تغییر داد.

  • برای GoogleAppSecuritySources :

    • منبع ایمنی GooglePlayProtect را حذف یا تغییر ندهید.
    • می‌توانید منبع ایمنی GoogleAppProtectionService را حذف یا تغییر دهید. اگر موجود باشد:
      • باید از ورود به سیستم پشتیبانی کند.
      • اگر نام بسته تغییر نکرده باشد، باید در Android 13 دارای initialDisplayState="hidden" باشد. در Android 14، به جای آن باید یک issue-only-safety-source باشد و deduplicationGroup باید بدون تغییر باقی بماند.
      • اگر نام بسته تغییر کند، باید نقش "android.app.role.SYSTEM_APP_PROTECTION_SERVICE" را داشته باشد. علاوه بر این در اندروید 14 نباید deduplicationGroup داشته باشد.

  • برای AndroidLockScreenSources :

    • نمونه summary گروه مورد نیاز است و می توانید آن را تغییر دهید، از جمله با یک پوشش رشته.
    • حداقل باید یک منبع ایمنی وجود داشته باشد.
    • اولین منبع ایمنی منبعی است که تنظیمات صفحه قفل را کنترل می‌کند و نباید بتواند مشکلات یا ورودی‌های شدیدتر از SEVERITY_LEVEL_RECOMMENDATION ( maxSeverityLevel="300" یا تا کارت‌های هشدار یا ورودی زرد) را تحت فشار قرار دهد. در Android 14، deduplicationGroup باید بدون تغییر باقی بماند.
    • سایر منابع ایمنی منابع مرتبط با مکانیسم های باز کردن قفل بیومتریک هستند و باید دارای maxSeverityLevel="0" باشند.

  • در Android 13، GoogleAccountSources ، GoogleDeviceFinderSources ، یا AndroidAdvancedSources را تغییر ندهید. در اندروید 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 برای همه OEM‌هایی اعمال می‌شود که از PermissionController پشتیبانی می‌کنند.

تست فایل پیکربندی ( XmlConfigTest )

این تست ها تضمین می کنند:

  • فایل پیکربندی XML تجزیه شده با پیکربندی تجزیه و تحلیل شده توسط مرکز ایمنی مطابقت دارد و این تجزیه موفقیت آمیز است.
  • اگر کنش intent android.settings.PRIVACY_ADVANCED_SETTINGS در فایل XML وجود دارد، این عمل باید برطرف شود.
  • اگر کنش intent android.settings.PRIVACY_CONTROLS در فایل XML وجود دارد، این عمل باید برطرف شود.

تست‌های رابط کاربری ( SafetyCenterActivityTest )

این تست ها تضمین می کنند:

  • اقدام intent android.intent.action.SAFETY_CENTER هنگامی که مرکز ایمنی فعال است صفحه تنظیمات امنیت و حریم خصوصی را برطرف می کند و هنگامی که مرکز ایمنی غیرفعال است صفحه تنظیمات را باز می کند.

تست های API ( SafetyCenterManagerTest )

هدف از تست‌های SafetyCenterManagerTest API این است که اطمینان حاصل شود که APIهای Safety Center طبق برنامه کار می‌کنند.

این تست ها موارد زیر را تضمین می کند:

  • SafetyCenterManager.isSafetyCenterEnabled توسط پرچم DeviceConfig مرتبط کنترل می شود.
  • در صورت غیرفعال شدن، APIهای مرکز ایمنی غیرفعال است.
  • APIهای Safety Center فقط زمانی قابل استفاده هستند که مجوزهای مربوطه حفظ شود.
  • داده‌ها را می‌توان فقط مطابق با پیکربندی اصلی به مرکز ایمنی ارائه کرد.
  • هنگامی که داده ها به مرکز ایمنی ارائه می شود، مطابق با آن ظاهر می شود.
  • APIها با مشخصات توضیح داده شده در استفاده از APIهای منبع مرکز ایمنی مطابقت دارند، به عنوان مثال، رفتار بازخوانی یا اسکن مجدد، تنظیم یا پاک کردن داده‌ها و گزارش خطاها.
  • APIهای داخلی در معرض UI به درستی کار می کنند، به عنوان مثال، داده ها به طور مناسب توسط Safety Center ادغام می شوند و داده ها می توانند به روز شوند.

تست پشتیبانی نشده مرکز ایمنی ( SafetyCenterUnsupportedTest )

این آزمایش تضمین می‌کند که وقتی دستگاه از آن پشتیبانی نمی‌کند، وقتی پشتیبانی در فایل پیکربندی فریمورک XML غیرفعال است، مرکز ایمنی غیرفعال می‌شود.

اگر دستگاه از Safety Center پشتیبانی می‌کند، این آزمایش اجرا نمی‌شود. اگر دستگاه از Safety Center پشتیبانی نمی‌کند، فقط این آزمایش و آزمون‌های کلاس‌های داده اجرا می‌شوند.

این تست موارد زیر را تضمین می کند:

  • کنش intent android.intent.action.SAFETY_CENTER صفحه تنظیمات را باز می کند.
  • SafetyCenterManager.isSafetyCenterEnabled false را برمی گرداند.
  • اکثر APIهای مرکز ایمنی هنگام فراخوانی پاسخ نمی‌دهند.

تست کلاس های داده ( SafetySourceDataTest ، SafetySourceIssueTest ، و غیره)

تست‌های کلاس داده‌ها مانند SafetySourceDataTest و SafetySourceIssueTest اطمینان حاصل می‌کنند که کلاس‌های داده‌ای که توسط Safety Center در معرض دید قرار می‌گیرند، به عنوان مثال SafetySourceData ، SafetySourceIssue و سایر کلاس‌های داخلی مرتبط کار می‌کنند.

تست های MTS ( SafetyCenterFunctionalTestCases و موارد دیگر)

این آزمایش‌ها در به‌روزرسانی‌های خط اصلی اجرا می‌شوند و برای همه OEMهایی که از PermissionController پشتیبانی می‌کنند اعمال می‌شوند. الزامات اعمال شده توسط این آزمایش‌ها ممکن است در به‌روزرسانی‌های خط اصلی تغییر کند.

تست های API ( SafetyCenterManagerTest )

این تست‌ها مشابه تست CTS SafetyCenterManagerTest هستند، با این حال الزامات مورد نیاز را آزمایش می‌کنند که می‌تواند در به‌روزرسانی‌های خط اصلی تغییر کند، برای مثال:

  • بررسی محتوای واقعی داده‌های بازگردانده شده توسط APIهای داخلی در معرض UI

تست‌های رابط کاربری ( SafetyCenterActivityTest ، SafetyCenterStatusCardTest ، SafetyCenterQsActivityTest ، و غیره)

این تست ها تضمین می کنند:

  • هدایت مجدد به مرکز ایمنی با پارامترهای خاص همانطور که در نظر گرفته شده است، به عنوان مثال، تغییر مسیر به یک مشکل خاص عمل می کند. به تغییر مسیر به مرکز ایمنی مراجعه کنید.
  • UI وضعیت ایمنی زیربنایی صحیح را نشان می دهد.
  • رابط کاربری اجازه می دهد تا به صفحه های جداگانه پیمایش کنید.
  • UI اجازه می دهد تا زمانی که توسط SafetySourceIssue مشخص شده است، مسائل ایمنی را مستقیماً از صفحه Safety Center حل کنید.
  • رابط کاربری چندین کارت اخطار را در یک مورد جمع می‌کند و اجازه می‌دهد آن را به چندین کارت هشدار بازگرداند.
  • هنگامی که صفحه Safety Center برای منابع مربوطه Safety Center باز می شود، داده ها به روز می شوند.
  • دکمه اسکن مجدد فقط در شرایط خاص ظاهر می شود.
  • ضربه زدن روی دکمه اسکن مجدد داده های جدید را واکشی می کند.

  • آزمایش های مشابهی برای مرکز ایمنی انجام می شود. به ایجاد کاشی های سفارشی تنظیمات سریع برای برنامه خود مراجعه کنید

  • موارد لبه اضافی مانند حالت های خطا و حالت های معلق.

تست های چند کاربره ( SafetyCenterMultiUsersTest )

هدف از این آزمایش‌ها اطمینان از عملکرد مناسب API زمانی است که داده‌ها برای چندین کاربر یا نمایه ارائه می‌شود. به ارائه داده برای چندین کاربر و نمایه مراجعه کنید. این راه‌اندازی با استفاده از یک کتابخانه داخلی به دست می‌آید که تنظیم کاربران و پروفایل‌های جداگانه را در دستگاه با استفاده از Bedstead تسهیل می‌کند.

این تست موارد زیر را تضمین می کند:

  • داده های متعلق به یک کاربر در صورت وجود، با نمایه مدیریت شده مرتبط با آن ادغام می شوند.
  • فقط منابعی که با profile="all_profiles" علامت گذاری شده اند می توانند داده ها را در نمایه مدیریت شده کاربر ارائه دهند.
  • یک ورودی جدید برای هر نمایه مدیریت شده مرتبط با یک کاربر ایجاد می شود.
  • داده های متعلق به یک کاربر به کاربر نامرتبط دیگر درز نمی کند.
،

تست های GTS ( GtsSafetyCenterTestCases )

تست های GTS محدودیت هایی را بر روی فایل پیکربندی اعمال می کنند. به به روز رسانی فایل پیکربندی مراجعه کنید. اگر دستگاه از مرکز ایمنی پشتیبانی نکند، دستگاهی از این آزمایش‌ها مستثنی است.

محدودیت ها به شرح زیر است:

  • باید حداقل هفت گروه منبع مرکز ایمنی وجود داشته باشد که باید در حالت تغییر نیافته یا پیش فرض باقی بمانند. برخی از فیلدهای خاص مانند عناوین منابع، وضعیت نمایش اولیه و خلاصه گاهی اوقات توسط رشته های قابل پوشش پشتیبانی می شوند و می توان آنها را تغییر داد.

  • برای GoogleAppSecuritySources :

    • منبع ایمنی GooglePlayProtect را حذف یا تغییر ندهید.
    • می‌توانید منبع ایمنی GoogleAppProtectionService را حذف یا تغییر دهید. اگر موجود باشد:
      • باید از ورود به سیستم پشتیبانی کند.
      • اگر نام بسته تغییر نکرده باشد، باید در Android 13 دارای initialDisplayState="hidden" باشد. در Android 14، به جای آن باید یک issue-only-safety-source باشد و deduplicationGroup باید بدون تغییر باقی بماند.
      • اگر نام بسته تغییر کند، باید نقش "android.app.role.SYSTEM_APP_PROTECTION_SERVICE" را داشته باشد. علاوه بر این در اندروید 14 نباید deduplicationGroup داشته باشد.

  • برای AndroidLockScreenSources :

    • نمونه summary گروه مورد نیاز است و می توانید آن را تغییر دهید، از جمله با یک پوشش رشته.
    • حداقل باید یک منبع ایمنی وجود داشته باشد.
    • اولین منبع ایمنی منبعی است که تنظیمات صفحه قفل را کنترل می‌کند و نباید بتواند مشکلات یا ورودی‌های شدیدتر از SEVERITY_LEVEL_RECOMMENDATION ( maxSeverityLevel="300" یا تا کارت‌های هشدار یا ورودی زرد) را تحت فشار قرار دهد. در Android 14، deduplicationGroup باید بدون تغییر باقی بماند.
    • سایر منابع ایمنی منابع مرتبط با مکانیسم های باز کردن قفل بیومتریک هستند و باید دارای maxSeverityLevel="0" باشند.

  • در Android 13، GoogleAccountSources ، GoogleDeviceFinderSources ، یا AndroidAdvancedSources را تغییر ندهید. در اندروید 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 برای همه OEM‌هایی اعمال می‌شود که از PermissionController پشتیبانی می‌کنند.

تست فایل پیکربندی ( XmlConfigTest )

این تست ها تضمین می کنند:

  • فایل پیکربندی XML تجزیه شده با پیکربندی تجزیه و تحلیل شده توسط مرکز ایمنی مطابقت دارد و این تجزیه موفقیت آمیز است.
  • اگر کنش intent android.settings.PRIVACY_ADVANCED_SETTINGS در فایل XML وجود دارد، این عمل باید برطرف شود.
  • اگر کنش intent android.settings.PRIVACY_CONTROLS در فایل XML وجود دارد، این عمل باید برطرف شود.

تست‌های رابط کاربری ( SafetyCenterActivityTest )

این تست ها تضمین می کنند:

  • اقدام intent android.intent.action.SAFETY_CENTER هنگامی که مرکز ایمنی فعال است صفحه تنظیمات امنیت و حریم خصوصی را برطرف می کند و هنگامی که مرکز ایمنی غیرفعال است صفحه تنظیمات را باز می کند.

تست های API ( SafetyCenterManagerTest )

هدف از تست‌های SafetyCenterManagerTest API این است که اطمینان حاصل شود که APIهای Safety Center طبق برنامه کار می‌کنند.

این تست ها موارد زیر را تضمین می کند:

  • SafetyCenterManager.isSafetyCenterEnabled توسط پرچم DeviceConfig مرتبط کنترل می شود.
  • در صورت غیرفعال شدن، APIهای مرکز ایمنی غیرفعال است.
  • APIهای Safety Center فقط زمانی قابل استفاده هستند که مجوزهای مربوطه حفظ شود.
  • داده‌ها را می‌توان فقط مطابق با پیکربندی اصلی به مرکز ایمنی ارائه کرد.
  • هنگامی که داده ها به مرکز ایمنی ارائه می شود، مطابق با آن ظاهر می شود.
  • APIها با مشخصات توضیح داده شده در استفاده از APIهای منبع مرکز ایمنی مطابقت دارند، به عنوان مثال، رفتار بازخوانی یا اسکن مجدد، تنظیم یا پاک کردن داده‌ها و گزارش خطاها.
  • APIهای داخلی در معرض UI به درستی کار می کنند، به عنوان مثال، داده ها به طور مناسب توسط Safety Center ادغام می شوند و داده ها می توانند به روز شوند.

تست پشتیبانی نشده مرکز ایمنی ( SafetyCenterUnsupportedTest )

این آزمایش تضمین می‌کند که وقتی دستگاه از آن پشتیبانی نمی‌کند، وقتی پشتیبانی در فایل پیکربندی فریمورک XML غیرفعال است، مرکز ایمنی غیرفعال می‌شود.

اگر دستگاه از Safety Center پشتیبانی می‌کند، این آزمایش اجرا نمی‌شود. اگر دستگاه از Safety Center پشتیبانی نمی‌کند، فقط این آزمایش و آزمون‌های کلاس‌های داده اجرا می‌شوند.

این تست موارد زیر را تضمین می کند:

  • کنش intent android.intent.action.SAFETY_CENTER صفحه تنظیمات را باز می کند.
  • SafetyCenterManager.isSafetyCenterEnabled false را برمی گرداند.
  • اکثر APIهای مرکز ایمنی هنگام فراخوانی پاسخ نمی‌دهند.

تست کلاس های داده ( SafetySourceDataTest ، SafetySourceIssueTest ، و غیره)

تست‌های کلاس داده‌ها مانند SafetySourceDataTest و SafetySourceIssueTest اطمینان حاصل می‌کنند که کلاس‌های داده‌ای که توسط Safety Center در معرض دید قرار می‌گیرند، به عنوان مثال SafetySourceData ، SafetySourceIssue و سایر کلاس‌های داخلی مرتبط کار می‌کنند.

تست های MTS ( SafetyCenterFunctionalTestCases و موارد دیگر)

این آزمایش‌ها در به‌روزرسانی‌های خط اصلی اجرا می‌شوند و برای همه OEMهایی که از PermissionController پشتیبانی می‌کنند اعمال می‌شوند. الزامات اعمال شده توسط این آزمایش‌ها ممکن است در به‌روزرسانی‌های خط اصلی تغییر کند.

تست های API ( SafetyCenterManagerTest )

این تست‌ها مشابه تست CTS SafetyCenterManagerTest هستند، با این حال الزامات مورد نیاز را آزمایش می‌کنند که می‌تواند در به‌روزرسانی‌های خط اصلی تغییر کند، برای مثال:

  • بررسی محتوای واقعی داده‌های بازگردانده شده توسط APIهای داخلی در معرض UI

تست‌های رابط کاربری ( SafetyCenterActivityTest ، SafetyCenterStatusCardTest ، SafetyCenterQsActivityTest ، و غیره)

این تست ها تضمین می کنند:

  • هدایت مجدد به مرکز ایمنی با پارامترهای خاص همانطور که در نظر گرفته شده است، به عنوان مثال، تغییر مسیر به یک مشکل خاص عمل می کند. به تغییر مسیر به مرکز ایمنی مراجعه کنید.
  • UI وضعیت ایمنی زیربنایی صحیح را نشان می دهد.
  • رابط کاربری اجازه می دهد تا به صفحه های جداگانه پیمایش کنید.
  • UI اجازه می دهد تا زمانی که توسط SafetySourceIssue مشخص شده است، مسائل ایمنی را مستقیماً از صفحه Safety Center حل کنید.
  • رابط کاربری چندین کارت اخطار را در یک مورد جمع می‌کند و اجازه می‌دهد آن را به چندین کارت هشدار بازگرداند.
  • هنگامی که صفحه Safety Center برای منابع مربوطه Safety Center باز می شود، داده ها به روز می شوند.
  • دکمه اسکن مجدد فقط در شرایط خاص ظاهر می شود.
  • ضربه زدن روی دکمه اسکن مجدد داده های جدید را واکشی می کند.

  • آزمایش های مشابهی برای مرکز ایمنی انجام می شود. به ایجاد کاشی های سفارشی تنظیمات سریع برای برنامه خود مراجعه کنید

  • موارد لبه اضافی مانند حالت های خطا و حالت های معلق.

تست های چند کاربره ( SafetyCenterMultiUsersTest )

هدف از این آزمایش‌ها اطمینان از عملکرد مناسب API زمانی است که داده‌ها برای چندین کاربر یا نمایه ارائه می‌شود. به ارائه داده برای چندین کاربر و نمایه مراجعه کنید. این راه‌اندازی با استفاده از یک کتابخانه داخلی به دست می‌آید که تنظیم کاربران و پروفایل‌های جداگانه را در دستگاه با استفاده از Bedstead تسهیل می‌کند.

این تست موارد زیر را تضمین می کند:

  • داده های متعلق به یک کاربر در صورت وجود، با نمایه مدیریت شده مرتبط با آن ادغام می شوند.
  • فقط منابعی که با profile="all_profiles" علامت گذاری شده اند می توانند داده ها را در نمایه مدیریت شده کاربر ارائه دهند.
  • یک ورودی جدید برای هر نمایه مدیریت شده مرتبط با یک کاربر ایجاد می شود.
  • داده های متعلق به یک کاربر به کاربر نامرتبط دیگر درز نمی کند.
،

تست های GTS ( GtsSafetyCenterTestCases )

تست های GTS محدودیت هایی را بر روی فایل پیکربندی اعمال می کنند. به به روز رسانی فایل پیکربندی مراجعه کنید. اگر دستگاه از مرکز ایمنی پشتیبانی نکند، دستگاهی از این آزمایش‌ها مستثنی است.

محدودیت ها به شرح زیر است:

  • باید حداقل هفت گروه منبع مرکز ایمنی وجود داشته باشد که باید در حالت تغییر نیافته یا پیش فرض باقی بمانند. برخی از فیلدهای خاص مانند عناوین منابع، وضعیت نمایش اولیه و خلاصه گاهی اوقات توسط رشته های قابل پوشش پشتیبانی می شوند و می توان آنها را تغییر داد.

  • برای GoogleAppSecuritySources :

    • منبع ایمنی GooglePlayProtect را حذف یا تغییر ندهید.
    • می‌توانید منبع ایمنی GoogleAppProtectionService را حذف یا تغییر دهید. اگر موجود باشد:
      • باید از ورود به سیستم پشتیبانی کند.
      • اگر نام بسته تغییر نکرده باشد، باید در Android 13 دارای initialDisplayState="hidden" باشد. در Android 14، به جای آن باید یک issue-only-safety-source باشد و deduplicationGroup باید بدون تغییر باقی بماند.
      • اگر نام بسته تغییر کند، باید نقش "android.app.role.SYSTEM_APP_PROTECTION_SERVICE" را داشته باشد. علاوه بر این در اندروید 14 نباید deduplicationGroup داشته باشد.

  • برای AndroidLockScreenSources :

    • نمونه summary گروه مورد نیاز است و می توانید آن را تغییر دهید، از جمله با یک پوشش رشته.
    • حداقل باید یک منبع ایمنی وجود داشته باشد.
    • اولین منبع ایمنی منبعی است که تنظیمات صفحه قفل را کنترل می‌کند و نباید بتواند مشکلات یا ورودی‌های شدیدتر از SEVERITY_LEVEL_RECOMMENDATION ( maxSeverityLevel="300" یا تا کارت‌های هشدار یا ورودی زرد) را تحت فشار قرار دهد. در Android 14، deduplicationGroup باید بدون تغییر باقی بماند.
    • سایر منابع ایمنی منابع مرتبط با مکانیسم های باز کردن قفل بیومتریک هستند و باید دارای maxSeverityLevel="0" باشند.

  • در Android 13، GoogleAccountSources ، GoogleDeviceFinderSources ، یا AndroidAdvancedSources را تغییر ندهید. در اندروید 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 برای همه OEM‌هایی اعمال می‌شود که از PermissionController پشتیبانی می‌کنند.

تست فایل پیکربندی ( XmlConfigTest )

این تست ها تضمین می کنند:

  • فایل پیکربندی XML تجزیه شده با پیکربندی تجزیه و تحلیل شده توسط مرکز ایمنی مطابقت دارد و این تجزیه موفقیت آمیز است.
  • اگر کنش intent android.settings.PRIVACY_ADVANCED_SETTINGS در فایل XML وجود دارد، این عمل باید برطرف شود.
  • اگر کنش intent android.settings.PRIVACY_CONTROLS در فایل XML وجود دارد، این عمل باید برطرف شود.

تست‌های رابط کاربری ( SafetyCenterActivityTest )

این تست ها تضمین می کنند:

  • اقدام intent android.intent.action.SAFETY_CENTER هنگامی که مرکز ایمنی فعال است صفحه تنظیمات امنیت و حریم خصوصی را برطرف می کند و هنگامی که مرکز ایمنی غیرفعال است صفحه تنظیمات را باز می کند.

تست های API ( SafetyCenterManagerTest )

هدف از تست‌های SafetyCenterManagerTest API این است که اطمینان حاصل شود که APIهای Safety Center طبق برنامه کار می‌کنند.

این تست ها موارد زیر را تضمین می کند:

  • SafetyCenterManager.isSafetyCenterEnabled توسط پرچم DeviceConfig مرتبط کنترل می شود.
  • در صورت غیرفعال شدن، APIهای مرکز ایمنی غیرفعال است.
  • APIهای Safety Center فقط زمانی قابل استفاده هستند که مجوزهای مربوطه حفظ شود.
  • داده‌ها را می‌توان فقط مطابق با پیکربندی اصلی به مرکز ایمنی ارائه کرد.
  • هنگامی که داده ها به مرکز ایمنی ارائه می شود، مطابق با آن ظاهر می شود.
  • APIها با مشخصات توضیح داده شده در استفاده از APIهای منبع مرکز ایمنی مطابقت دارند، به عنوان مثال، رفتار بازخوانی یا اسکن مجدد، تنظیم یا پاک کردن داده‌ها و گزارش خطاها.
  • APIهای داخلی در معرض UI به درستی کار می کنند، به عنوان مثال، داده ها به طور مناسب توسط Safety Center ادغام می شوند و داده ها می توانند به روز شوند.

تست پشتیبانی نشده مرکز ایمنی ( SafetyCenterUnsupportedTest )

این آزمایش تضمین می‌کند که وقتی دستگاه از آن پشتیبانی نمی‌کند، وقتی پشتیبانی در فایل پیکربندی فریمورک XML غیرفعال است، مرکز ایمنی غیرفعال می‌شود.

اگر دستگاه از Safety Center پشتیبانی می‌کند، این آزمایش اجرا نمی‌شود. اگر دستگاه از Safety Center پشتیبانی نمی‌کند، فقط این آزمایش و آزمون‌های کلاس‌های داده اجرا می‌شوند.

این تست موارد زیر را تضمین می کند:

  • کنش intent android.intent.action.SAFETY_CENTER صفحه تنظیمات را باز می کند.
  • SafetyCenterManager.isSafetyCenterEnabled false را برمی گرداند.
  • اکثر APIهای مرکز ایمنی هنگام فراخوانی پاسخ نمی‌دهند.

تست کلاس های داده ( SafetySourceDataTest ، SafetySourceIssueTest ، و غیره)

تست‌های کلاس داده‌ها مانند SafetySourceDataTest و SafetySourceIssueTest اطمینان حاصل می‌کنند که کلاس‌های داده‌ای که توسط Safety Center در معرض دید قرار می‌گیرند، به عنوان مثال SafetySourceData ، SafetySourceIssue و سایر کلاس‌های داخلی مرتبط کار می‌کنند.

تست های MTS ( SafetyCenterFunctionalTestCases و موارد دیگر)

این آزمایش‌ها در به‌روزرسانی‌های خط اصلی اجرا می‌شوند و برای همه OEMهایی که از PermissionController پشتیبانی می‌کنند اعمال می‌شوند. الزامات اعمال شده توسط این آزمایش‌ها ممکن است در به‌روزرسانی‌های خط اصلی تغییر کند.

تست های API ( SafetyCenterManagerTest )

این تست‌ها مشابه تست CTS SafetyCenterManagerTest هستند، با این حال الزامات مورد نیاز را آزمایش می‌کنند که می‌تواند در به‌روزرسانی‌های خط اصلی تغییر کند، برای مثال:

  • بررسی محتوای واقعی داده‌های بازگردانده شده توسط APIهای داخلی در معرض UI

تست‌های رابط کاربری ( SafetyCenterActivityTest ، SafetyCenterStatusCardTest ، SafetyCenterQsActivityTest ، و غیره)

این تست ها تضمین می کنند:

  • هدایت مجدد به مرکز ایمنی با پارامترهای خاص همانطور که در نظر گرفته شده است، به عنوان مثال، تغییر مسیر به یک مشکل خاص عمل می کند. به تغییر مسیر به مرکز ایمنی مراجعه کنید.
  • UI وضعیت ایمنی زیربنایی صحیح را نشان می دهد.
  • رابط کاربری اجازه می دهد تا به صفحه های جداگانه پیمایش کنید.
  • UI اجازه می دهد تا زمانی که توسط SafetySourceIssue مشخص شده است، مسائل ایمنی را مستقیماً از صفحه Safety Center حل کنید.
  • رابط کاربری چندین کارت اخطار را در یک مورد جمع می‌کند و اجازه می‌دهد آن را به چندین کارت هشدار بازگرداند.
  • هنگامی که صفحه Safety Center برای منابع مربوطه Safety Center باز می شود، داده ها به روز می شوند.
  • دکمه اسکن مجدد فقط در شرایط خاص ظاهر می شود.
  • ضربه زدن روی دکمه اسکن مجدد داده های جدید را واکشی می کند.

  • آزمایش های مشابهی برای مرکز ایمنی انجام می شود. به ایجاد کاشی های سفارشی تنظیمات سریع برای برنامه خود مراجعه کنید

  • موارد لبه اضافی مانند حالت های خطا و حالت های معلق.

تست های چند کاربره ( SafetyCenterMultiUsersTest )

هدف از این آزمایش‌ها اطمینان از عملکرد مناسب API زمانی است که داده‌ها برای چندین کاربر یا نمایه ارائه می‌شود. به ارائه داده برای چندین کاربر و نمایه مراجعه کنید. این راه‌اندازی با استفاده از یک کتابخانه داخلی به دست می‌آید که تنظیم کاربران و پروفایل‌های جداگانه را در دستگاه با استفاده از Bedstead تسهیل می‌کند.

این تست موارد زیر را تضمین می کند:

  • داده های متعلق به یک کاربر در صورت وجود، با نمایه مدیریت شده مرتبط با آن ادغام می شوند.
  • فقط منابعی که با profile="all_profiles" علامت گذاری شده اند می توانند داده ها را در نمایه مدیریت شده کاربر ارائه دهند.
  • یک ورودی جدید برای هر نمایه مدیریت شده مرتبط با یک کاربر ایجاد می شود.
  • داده های متعلق به یک کاربر به کاربر نامرتبط دیگر درز نمی کند.