टेस्ट से जुड़ी ज़रूरी शर्तें

GTS टेस्ट (GtsSafetyCenterTestCases)

जीटीएस टेस्ट, कॉन्फ़िगरेशन फ़ाइल पर पाबंदियां लगाते हैं. कॉन्फ़िगरेशन फ़ाइल अपडेट करना देखें. अगर किसी डिवाइस पर Safety Center काम नहीं करता है, तो उसे इन टेस्ट से छूट मिलती है.

ये पाबंदियां हैं:

  • Safety Center में कम से कम सात सोर्स ग्रुप होने चाहिए. इनमें कोई बदलाव नहीं किया जाना चाहिए या इन्हें डिफ़ॉल्ट स्थिति में ही रखना चाहिए. सोर्स के टाइटल, शुरुआती डिसप्ले स्टेटस, और खास जानकारी जैसे कुछ फ़ील्ड में, कभी-कभी ओवरले की जा सकने वाली स्ट्रिंग होती हैं. इनमें बदलाव किया जा सकता है.
  • GoogleAppSecuritySources के लिए:

    • GooglePlayProtect सुरक्षा सोर्स को न हटाएं और न ही उसमें बदलाव करें.
    • GoogleAppProtectionService सुरक्षा सोर्स को हटाया या बदला जा सकता है. अगर यह मौजूद है, तो:
      • इसमें लॉगिंग की सुविधा होनी चाहिए.
      • अगर पैकेज के नाम में कोई बदलाव नहीं किया गया है, तो Android 13 में उसका नाम initialDisplayState="hidden" होना चाहिए. 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 ग्रुप (Android 14 में SAFETY_SOURCES_GROUP_TYPE_STATELESS) बन जाता है.
    • हर ग्रुप में मौजूद हर सोर्स, स्टैटिक होना चाहिए या उसमें maxSeverityLevel="0" होना चाहिए. उदाहरण के लिए, स्लेटी या हरे रंग की एंट्री भेजने की अनुमति होनी चाहिए, लेकिन कोई समस्या नहीं होनी चाहिए.

सीटीएस टेस्ट (CtsSafetyCenterTestCases)

Android 13 से, CTS टेस्ट उन सभी OEM पर लागू होंगे जो PermissionController के साथ काम करते हैं.

कॉन्फ़िगरेशन फ़ाइल की जांच (XmlConfigTest)

इन जांचों से यह पक्का होता है कि:

  • पार्स की गई एक्सएमएल कॉन्फ़िगरेशन फ़ाइल, Safety Center के पार्स किए गए और ज़ाहिर किए गए कॉन्फ़िगरेशन से मेल खाती है. साथ ही, यह भी ज़रूरी है कि पार्स करने की प्रोसेस पूरी हो गई हो.
  • अगर एक्सएमएल फ़ाइल में इंटेंट ऐक्शन android.settings.PRIVACY_ADVANCED_SETTINGS मौजूद है, तो यह कार्रवाई पूरी होनी चाहिए.
  • अगर एक्सएमएल फ़ाइल में इंटेंट ऐक्शन android.settings.PRIVACY_CONTROLS मौजूद है, तो यह कार्रवाई पूरी होनी चाहिए.

यूज़र इंटरफ़ेस (यूआई) की जांच (SafetyCenterActivityTest)

इन जांचों से यह पक्का होता है कि:

  • android.intent.action.SAFETY_CENTER इंटेंट ऐक्शन से, Safety Center के चालू होने पर सुरक्षा और निजता सेटिंग स्क्रीन खुलती है. वहीं, Safety Center के बंद होने पर सेटिंग स्क्रीन खुलती है.

एपीआई टेस्ट (SafetyCenterManagerTest)

SafetyCenterManagerTest API टेस्ट का मकसद यह पक्का करना है कि Safety Center के एपीआई सही तरीके से काम कर रहे हैं या नहीं.

इन जांचों से यह पक्का होता है कि:

  • SafetyCenterManager.isSafetyCenterEnabled को इससे जुड़े DeviceConfig फ़्लैग से कंट्रोल किया जाता है.
  • बंद होने पर, Safety Center के एपीआई काम नहीं करते.
  • Safety Center के एपीआई का इस्तेमाल सिर्फ़ तब किया जा सकता है, जब उनसे जुड़ी अनुमतियां दी गई हों.
  • Safety Center को डेटा सिर्फ़ मौजूदा कॉन्फ़िगरेशन के हिसाब से दिया जा सकता है.
  • जब Safety Center को डेटा दिया जाता है, तो वह उसी हिसाब से दिखता है.
  • ये एपीआई, Safety Center के सोर्स एपीआई का इस्तेमाल करें में बताए गए स्पेसिफ़िकेशन से मेल खाते हैं. उदाहरण के लिए, रीफ़्रेश या फिर फिर से स्कैन करने का तरीका, डेटा सेट करना या मिटाना, और गड़बड़ियों की शिकायत करना.
  • यूज़र इंटरफ़ेस (यूआई) के लिए उपलब्ध कराए गए इंटरनल एपीआई ठीक से काम कर रहे हैं. उदाहरण के लिए, Safety Center में डेटा को सही तरीके से मर्ज किया गया है और डेटा को रीफ़्रेश किया जा सकता है.

Safety Center पर टेस्ट नहीं किया जा सकता (SafetyCenterUnsupportedTest)

इस जांच से यह पक्का होता है कि अगर डिवाइस पर Safety Center काम नहीं करता है, तो वह बंद हो जाएगा. ऐसा तब भी होता है, जब फ़्रेमवर्क की एक्सएमएल कॉन्फ़िगरेशन फ़ाइल में, इस सुविधा को बंद किया गया हो.

अगर डिवाइस पर Safety Center काम करता है, तो यह जांच नहीं की जाती. अगर डिवाइस पर Safety Center काम नहीं करता है, तो सिर्फ़ यह टेस्ट और डेटा क्लास के टेस्ट चलते हैं.

इस जांच से यह पक्का होता है कि:

  • android.intent.action.SAFETY_CENTER इंटेंट ऐक्शन से सेटिंग स्क्रीन खुलती है.
  • SafetyCenterManager.isSafetyCenterEnabled, false दिखाता है.
  • ज़्यादातर Safety Center API, कॉल किए जाने पर जवाब नहीं देते.

डेटा क्लास टेस्ट (SafetySourceDataTest, SafetySourceIssueTest वगैरह)

SafetySourceDataTest और SafetySourceIssueTest जैसी डेटा क्लास की जांच से यह पक्का होता है कि सुरक्षा केंद्र से एक्सपोज़ की गई डेटा क्लास, सही तरीके से काम कर रही हैं. उदाहरण के लिए, SafetySourceData, SafetySourceIssue, और इससे जुड़ी अन्य इंटरनल क्लास.

एमटीएस टेस्ट (SafetyCenterFunctionalTestCases और अन्य)

ये टेस्ट, मुख्य अपडेट के लिए चलाए जाते हैं. साथ ही, ये उन सभी OEM पर लागू होते हैं जिन पर PermissionController काम करता है. इन टेस्ट से लागू होने वाली ज़रूरी शर्तें, मुख्य अपडेट में बदल सकती हैं.

एपीआई टेस्ट (SafetyCenterManagerTest)

ये टेस्ट, सीटीएस टेस्ट SafetyCenterManagerTest से मिलते-जुलते हैं. हालांकि, इनमें उन ज़रूरी शर्तों की जांच की जाती है जो मुख्य अपडेट में बदल सकती हैं. उदाहरण के लिए:

  • यूज़र इंटरफ़ेस (यूआई) के लिए उपलब्ध इंटरनल एपीआई से मिले डेटा के असल कॉन्टेंट की जांच करना

यूज़र इंटरफ़ेस (यूआई) की जांच (SafetyCenterActivityTest, SafetyCenterStatusCardTest, SafetyCenterQsActivityTest वगैरह)

इन जांचों से यह पक्का होता है कि:

  • खास पैरामीटर के साथ सुरक्षा केंद्र पर रीडायरेक्ट करने की सुविधा, सही तरीके से काम करती है. उदाहरण के लिए, किसी खास समस्या पर रीडायरेक्ट करना. सुरक्षा केंद्र पर रीडायरेक्ट करें देखें.
  • यूज़र इंटरफ़ेस (यूआई), सुरक्षा की सही स्थिति दिखाता है.
  • यूज़र इंटरफ़ेस (यूआई) की मदद से, अलग-अलग स्क्रीन पर नेविगेट किया जा सकता है.
  • SafetySourceIssue के निर्देश पर, यूज़र इंटरफ़ेस (यूआई) की मदद से, सीधे सुरक्षा केंद्र की स्क्रीन से सुरक्षा से जुड़ी समस्याओं को हल किया जा सकता है.
  • यूज़र इंटरफ़ेस (यूआई), एक आइटम में कई चेतावनी कार्ड को छोटा कर देता है. साथ ही, इसे फिर से कई चेतावनी कार्ड में बड़ा करने की सुविधा देता है.
  • सुरक्षा केंद्र के काम के सोर्स के लिए, सुरक्षा केंद्र का पेज खोलने पर डेटा रीफ़्रेश हो जाता है.
  • 'फिर से स्कैन करें' बटन सिर्फ़ कुछ खास स्थितियों में दिखता है.
  • 'फिर से स्कैन करें' बटन पर टैप करने से नया डेटा फ़ेच होता है.
  • सुरक्षा केंद्र के लिए भी इसी तरह के टेस्ट किए जाते हैं. अपने ऐप्लिकेशन के लिए, कस्टम क्विक सेटिंग टाइल बनाना देखें

  • गड़बड़ी की स्थितियां और बाकी स्थितियां जैसे अन्य एज केस.

एक से ज़्यादा उपयोगकर्ताओं के लिए टेस्ट (SafetyCenterMultiUsersTest)

इन टेस्ट का मकसद यह पक्का करना है कि कई उपयोगकर्ताओं या प्रोफ़ाइलों के लिए डेटा उपलब्ध कराने पर, एपीआई सही तरीके से काम करे. एक से ज़्यादा उपयोगकर्ताओं और प्रोफ़ाइलों के लिए डेटा उपलब्ध कराना लेख पढ़ें. यह सेटअप, डिवाइस पर अलग-अलग उपयोगकर्ताओं और प्रोफ़ाइलों को सेट अप करने के लिए, Bedstead का इस्तेमाल करने वाली एक इंटरनल लाइब्रेरी का इस्तेमाल करके किया जाता है.

इस जांच से यह पक्का होता है कि:

  • अगर उपयोगकर्ता का कोई मैनेज की जा रही प्रोफ़ाइल मौजूद है, तो उसके डेटा को उस प्रोफ़ाइल के साथ मर्ज कर दिया जाता है.
  • सिर्फ़ profile="all_profiles" के साथ मार्क किए गए सोर्स, उपयोगकर्ता की मैनेज की जा रही प्रोफ़ाइल में डेटा दे सकते हैं.
  • उपयोगकर्ता से जुड़ी हर मैनेज की जा रही प्रोफ़ाइल के लिए, एक नई एंट्री बनाई जाती है.
  • एक उपयोगकर्ता का डेटा, किसी दूसरे उपयोगकर्ता के साथ शेयर नहीं किया जाता.