Android 14 के साथ काम करने की परिभाषा

1. परिचय

इस दस्तावेज़ में उन ज़रूरी शर्तों के बारे में बताया गया है जिन्हें पूरा करने पर, डिवाइसों पर Android 14 काम करेगा.

RFC2119 में बताए गए IETF स्टैंडर्ड के मुताबिक, "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", और "OPTIONAL" का इस्तेमाल किया जाता है.

इस दस्तावेज़ में, "डिवाइस लागू करने वाला" या "लागू करने वाला" व्यक्ति या संगठन, Android 14 पर चलने वाला हार्डवेयर/सॉफ़्टवेयर सलूशन डेवलप करता है. "डिवाइस पर लागू करना" या "लागू करना", हार्डवेयर/सॉफ़्टवेयर का ऐसा समाधान है जिसे डिवाइस पर लागू किया गया है.

Android 14 के साथ काम करने के लिए, डिवाइस के लागू होने की प्रक्रिया को, डिवाइस के साथ काम करने की शर्तों की इस परिभाषा में बताई गई शर्तों को पूरा करना होगा. इनमें, रेफ़रंस के ज़रिए शामिल किए गए दस्तावेज़ भी शामिल हैं.

अगर सेक्शन 10 में दी गई इस परिभाषा या सॉफ़्टवेयर की जांच के बारे में कुछ नहीं बताया गया है, अस्पष्ट जानकारी दी गई है या जानकारी अधूरी है, तो डिवाइस को लागू करने वाले व्यक्ति या कंपनी की यह ज़िम्मेदारी है कि वह यह पक्का करे कि डिवाइस, पहले से लागू किए गए सिस्टम के साथ काम करता हो.

इस वजह से, Android Open Source Project, Android के रेफ़रंस और उसे लागू करने का सबसे सही तरीका है. डिवाइस में इस सुविधा को लागू करने वाले लोगों को हमारा सुझाव है कि वे Android Open Source Project से उपलब्ध "अपस्ट्रीम" सोर्स कोड का ज़्यादा से ज़्यादा इस्तेमाल करें. कुछ कॉम्पोनेंट को, वैकल्पिक तरीके से लागू करने की कोशिश की जा सकती है. हालांकि, हमारा सुझाव है कि ऐसा न करें, क्योंकि इससे सॉफ़्टवेयर की जांच पास करना काफ़ी मुश्किल हो जाएगा. यह पक्का करना लागू करने वाले व्यक्ति या कंपनी की ज़िम्मेदारी है कि डिवाइस, Android के स्टैंडर्ड वर्शन के साथ पूरी तरह से काम करता हो. इसमें, Compatibility Test Suite के साथ-साथ, इसके अलावा भी डिवाइस के काम करने की जांच की जाती है. आखिर में, ध्यान दें कि इस दस्तावेज़ में कुछ कॉम्पोनेंट के बदले दूसरे कॉम्पोनेंट इस्तेमाल करने और उनमें बदलाव करने की अनुमति नहीं है.

इस दस्तावेज़ में लिंक किए गए कई संसाधन, सीधे या indirectly Android SDK टूल से लिए गए हैं. साथ ही, ये संसाधन, SDK टूल के दस्तावेज़ में दी गई जानकारी के जैसे ही काम करेंगे. अगर इस 'काम करने की शर्तों' या काम करने की जांच करने वाले सुइट में SDK टूल के दस्तावेज़ से कोई अंतर है, तो SDK टूल के दस्तावेज़ को आधिकारिक माना जाएगा. इस दस्तावेज़ में लिंक किए गए संसाधनों में दी गई कोई भी तकनीकी जानकारी, इस 'काम करने के तरीके की परिभाषा' का हिस्सा मानी जाती है.

1.1 दस्तावेज़ का स्ट्रक्चर

1.1.1. डिवाइस के टाइप के हिसाब से ज़रूरी शर्तें

सेक्शन 2 में, किसी खास डिवाइस टाइप पर लागू होने वाली सभी ज़रूरी शर्तें शामिल हैं. सेक्शन 2 का हर सब-सेक्शन, किसी खास तरह के डिवाइस के लिए है.

सेक्शन 2 के बाद के सेक्शन में, Android डिवाइस पर लागू होने वाली अन्य सभी ज़रूरी शर्तों के बारे में बताया गया है. इस दस्तावेज़ में, इन ज़रूरी शर्तों को "मुख्य ज़रूरी शर्तें" कहा गया है.

1.1.2. ज़रूरी शर्त का आईडी

ज़रूरी शर्तों के लिए, ज़रूरी शर्त आईडी असाइन किया जाता है.

• यह आईडी सिर्फ़ ज़रूरी शर्तों के लिए असाइन किया जाता है.
• ज़रूरी शर्तों को [SR] के तौर पर मार्क किया जाता है, लेकिन कोई आईडी असाइन नहीं किया जाता.
• आईडी में ये चीज़ें शामिल होती हैं : डिवाइस टाइप आईडी - स्थिति आईडी - ज़रूरी शर्त आईडी (उदाहरण के लिए, C-0-1).

हर आईडी को यहां बताया गया है:

• डिवाइस टाइप आईडी (ज़्यादा जानकारी के लिए, 2. डिवाइस टाइप)
  • C: मुख्य (Android डिवाइस पर लागू होने वाली ज़रूरी शर्तें)
  • H: Android हैंडहेल्ड डिवाइस
  • T: Android टेलीविज़न डिवाइस
  • जवाब: Android Automotive को लागू करना
  • W: Android Watch पर लागू करना
  • टैब: Android टैबलेट पर लागू करना
• शर्त का आईडी
  • अगर शर्त बिना किसी शर्त के लागू होती है, तो यह आईडी 0 पर सेट होता है.
  • जब शर्तें लागू होती हैं, तो पहली शर्त के लिए 1 असाइन किया जाता है. साथ ही, एक ही सेक्शन और एक ही डिवाइस टाइप में संख्या 1 बढ़ जाती है.
• ज़रूरी शर्त का आईडी
  • यह आईडी 1 से शुरू होता है और एक ही सेक्शन और एक ही शर्त में, एक से बढ़कर एक होता जाता है.

1.1.3. सेक्शन 2 में ज़रूरी शर्त का आईडी

सेक्शन 2 में मौजूद ज़रूरी शर्तों के आईडी के दो हिस्से होते हैं. पहला आइडेंटिफ़ायर, ऊपर बताए गए सेक्शन आईडी से जुड़ा होता है. दूसरे हिस्से में, डिवाइस के नाप या आकार और उससे जुड़ी ज़रूरी शर्तों की जानकारी होती है.

सेक्शन आईडी के बाद, ऊपर बताए गए ज़रूरी शर्तों का आईडी होता है.

• सेक्शन 2 में मौजूद आईडी में ये चीज़ें शामिल होती हैं: सेक्शन आईडी / डिवाइस टाइप आईडी - स्थिति आईडी - ज़रूरी शर्त आईडी (उदाहरण के लिए, 7.4.3/A-0-1).

2. डिवाइस टाइप

Android ओपन सोर्स प्रोजेक्ट, एक ऐसा सॉफ़्टवेयर स्टैक उपलब्ध कराता है जिसका इस्तेमाल, कई तरह के डिवाइसों और नाप या आकार के लिए किया जा सकता है. डिवाइसों पर सुरक्षा देने के लिए, सॉफ़्टवेयर स्टैक को सुरक्षित माहौल में चलाया जाना चाहिए. इसमें, ओएस बदलने या किसी अन्य कर्नेल को लागू करने की सुविधा भी शामिल है. इस बारे में, सीडीडी के सेक्शन 9 और अन्य जगहों पर बताया गया है. कुछ डिवाइसों के लिए, ऐप्लिकेशन डिस्ट्रिब्यूशन नेटवर्क का बेहतर तरीके से इस्तेमाल किया जा सकता है.

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

यहां बताए गए डिवाइस टाइप में शामिल न होने वाले सभी Android डिवाइसों को, इस डिवाइस के साथ काम करने की शर्तों के दूसरे सेक्शन में बताई गई सभी ज़रूरी शर्तें पूरी करनी होंगी.

2.1 डिवाइस कॉन्फ़िगरेशन

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

2.2. हाथ से इस्तेमाल करने की ज़रूरी शर्तें

Android हैंडहेल्ड डिवाइस से, ऐसे Android डिवाइस का मतलब है जिसका इस्तेमाल आम तौर पर हाथ में रखकर किया जाता है. जैसे, एमपी3 प्लेयर, फ़ोन या टैबलेट.

Android डिवाइस को हैंडहेल्ड के तौर पर तब ही माना जाता है, जब वह इन सभी शर्तों को पूरा करता हो:

• इसमें बैटरी जैसा कोई पावर सोर्स होना चाहिए.
• डिवाइस की डायगनल स्क्रीन का साइज़, 4 इंच से लेकर 8 इंच तक हो. डिवाइस में एपीआई लेवल 29 या उससे पहले के वर्शन का इस्तेमाल करने पर, स्क्रीन का डायगनल साइज़ 3.3 इंच (या 2.5 इंच) हो सकता है .
• टचस्क्रीन इनपुट इंटरफ़ेस हो.

इस सेक्शन के बाकी हिस्से में दी गई अतिरिक्त ज़रूरी शर्तें, Android डिवाइसों पर लागू होती हैं.

ध्यान दें: Android टैबलेट डिवाइसों पर लागू न होने वाली ज़रूरी शर्तों को * से मार्क किया गया है.

2.2.1. हार्डवेयर

हैंडहेल्ड डिवाइस पर लागू करने के लिए:

• [7.1.1.1/H-0-1] डिवाइस में कम से कम एक ऐसा डिसप्ले होना चाहिए जो Android के साथ काम करता हो और इस दस्तावेज़ में बताई गई सभी ज़रूरी शर्तों को पूरा करता हो. डिसप्ले का छोटा हिस्सा कम से कम 2.2” और लंबा हिस्सा कम से कम 3.4” होना चाहिए.

• [7.1.1.3/H-SR-1] उपयोगकर्ताओं को डिसप्ले साइज़ (स्क्रीन डेंसिटी) बदलने की सुविधा देने का ज़रूर सुझाव दिया जाता है.

• [7.1.1.1/H-0-2] यह ज़रूरी है कि डिवाइस में, कम से कम डिवाइस में पहले से मौजूद किसी भी डिसप्ले के सबसे ज़्यादा रिज़ॉल्यूशन के बराबर के ग्राफ़िक बफ़र के लिए, जीपीयू कॉम्पोज़िशन की सुविधा काम करती हो.

नई ज़रूरी शर्तें लागू करना

• [7.1.1.1/H-0-3]* तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराए गए हर UI_MODE_NORMAL डिसप्ले को, बिना किसी रुकावट वाले डिसप्ले एरिया पर मैप करना ज़रूरी है. यह एरिया, छोटे किनारे पर कम से कम 2.2 इंच और लंबे किनारे पर कम से कम 3.4 इंच होना चाहिए.

• [7.1.1.3/H-0-1]* DENSITY_DEVICE_STABLE की वैल्यू को, डिसप्ले के असल, फ़िज़िकल डेंसिटी से 92% या उससे ज़्यादा पर सेट करना ज़रूरी है.

नई ज़रूरी शर्तें खत्म करना

अगर हैंडहेल्ड डिवाइस पर, सॉफ़्टवेयर की मदद से स्क्रीन को घुमाने की सुविधा काम करती है, तो:

• [7.1.1.1/H-1-1]* तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराई गई लॉजिकल स्क्रीन के छोटे किनारों की लंबाई कम से कम दो इंच और लंबे किनारों की लंबाई कम से कम 2.7 इंच होनी चाहिए. Android के एपीआई लेवल 29 या उससे पहले के वर्शन पर शिप किए गए डिवाइसों को, इस ज़रूरी शर्त से छूट मिल सकती है.

अगर हैंडहेल्ड डिवाइस पर, सॉफ़्टवेयर की मदद से स्क्रीन घुमाने की सुविधा काम नहीं करती है, तो:

• [7.1.1.1/H-2-1]* तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराई गई लॉजिकल स्क्रीन के छोटे किनारे की लंबाई कम से कम 2.7 इंच होनी चाहिए. Android के एपीआई लेवल 29 या उससे पहले के वर्शन पर शिप किए गए डिवाइसों को, इस ज़रूरी शर्त से छूट मिल सकती है.

नई ज़रूरी शर्तें लागू करना

अगर हाथ में पकड़े जा सकने वाले डिवाइसों में Vulkan की सुविधा शामिल है, तो:

• [7.1.4.2/H-1-1] Android Baseline 2021 प्रोफ़ाइल में बताई गई ज़रूरी शर्तों को पूरा करना ज़रूरी है.

नई ज़रूरी शर्तें खत्म करना

अगर हैंडहेल्ड डिवाइस पर Configuration.isScreenHdr() के ज़रिए, हाई डाइनैमिक रेंज डिसप्ले के साथ काम करने का दावा किया जाता है, तो:

• [7.1.4.5/H-1-1] EGL_EXT_gl_colorspace_bt2020_pq, EGL_EXT_surface_SMPTE2086_metadata, EGL_EXT_surface_CTA861_3_metadata, VK_EXT_swapchain_colorspace, और VK_EXT_hdr_metadata एक्सटेंशन के लिए सहायता का विज्ञापन दिखाना ज़रूरी है.

हैंडहेल्ड डिवाइस पर लागू करने के लिए:

• [7.1.4.6/H-0-1] यह ज़रूरी है कि डिवाइस, सिस्टम प्रॉपर्टी graphics.gpu.profiler.support की मदद से, जीपीयू की प्रोफ़ाइलिंग की सुविधा के साथ काम करता है या नहीं, इसकी जानकारी दे.

अगर हैंडहेल्ड डिवाइस के लागू होने की जानकारी, सिस्टम प्रॉपर्टी के ज़रिए दी जाती है graphics.gpu.profiler.support, तो:

• [7.1.4.6/H-1-1] आउटपुट के तौर पर, ऐसा प्रोटोबस ट्रैक दिखाना ज़रूरी है जो Perfetto दस्तावेज़ में बताए गए जीपीयू काउंटर और जीपीयू रेंडरस्टेज के स्कीमा के मुताबिक हो.
• [7.1.4.6/H-1-2] डिवाइस के GPU काउंटर के लिए, gpu काउंटर ट्रेस पैकेट प्रोटो के मुताबिक, मानकों के मुताबिक वैल्यू रिपोर्ट करना ज़रूरी है.
• [7.1.4.6/H-1-3] डिवाइस के GPU रेंडर स्टेज के लिए, रेंडर स्टेज ट्रेस पैकेट प्रोटो के मुताबिक, सही वैल्यू की जानकारी देनी ज़रूरी है.
• [7.1.4.6/H-1-4] जीपीयू फ़्रीक्वेंसी ट्रैसपॉइंट की रिपोर्ट ज़रूर देनी चाहिए. यह रिपोर्ट, power/gpu_frequency फ़ॉर्मैट में दी जानी चाहिए.

हैंडहेल्ड डिवाइस पर लागू करने के लिए:

• [7.1.5/H-0-1] इसमें, लेगसी ऐप्लिकेशन के साथ काम करने वाले मोड के लिए सहायता शामिल होनी चाहिए. इसे Android के अपस्ट्रीम ओपन सोर्स कोड के ज़रिए लागू किया गया है. इसका मतलब है कि डिवाइस में लागू करने से, उन ट्रिगर या थ्रेशोल्ड में बदलाव नहीं होना चाहिए जिन पर कम्पैटबिलिटी मोड चालू होता है. साथ ही, कम्पैटबिलिटी मोड के व्यवहार में भी बदलाव नहीं होना चाहिए.
• [7.2.1/H-0-1] इसमें तीसरे पक्ष के इनपुट के तरीके के संपादक (आईएमई) ऐप्लिकेशन के लिए सहायता शामिल होनी चाहिए.
• [7.2.3/H-0-2] फ़ोरग्राउंड ऐप्लिकेशन को, बैक फ़ंक्शन (KEYCODE_BACK) के सामान्य और ज़्यादा देर तक दबाने के इवेंट, दोनों को भेजना ज़रूरी है. ये इवेंट, सिस्टम के ज़रिए इस्तेमाल नहीं किए जाने चाहिए.साथ ही, इन्हें Android डिवाइस के बाहर से ट्रिगर किया जा सकता है. जैसे, Android डिवाइस से कनेक्ट किया गया बाहरी हार्डवेयर कीबोर्ड.
• [7.2.3/H-0-3] Android के साथ काम करने वाले उन सभी डिसप्ले पर होम फ़ंक्शन होना चाहिए जिन पर होम स्क्रीन उपलब्ध होती है.
• [7.2.3/H-0-4] Android के साथ काम करने वाले सभी डिसप्ले पर, 'वापस जाएं' फ़ंक्शन और Android के साथ काम करने वाले कम से कम एक डिसप्ले पर, 'हाल ही में खोले गए' फ़ंक्शन होना ज़रूरी है.
• [7.2.4/H-0-1] टचस्क्रीन इनपुट की सुविधा होनी चाहिए.
• [7.2.4/H-SR-1] हमारा सुझाव है कि आप उपयोगकर्ता के चुने गए असिस्ट ऐप्लिकेशन को लॉन्च करें. दूसरे शब्दों में, वह ऐप्लिकेशन जो VoiceInteractionService को लागू करता है या अगर फ़ोरग्राउंड गतिविधि उन लॉन्ग-प्रेस इवेंट को मैनेज नहीं करती है, तो KEYCODE_MEDIA_PLAY_PAUSE या KEYCODE_HEADSETHOOK को दबाकर ACTION_ASSIST को मैनेज करने वाली गतिविधि.
• [7.3.1/H-SR-1] हमारा सुझाव है कि आप 3-ऐक्सिस एक्सलरोमीटर शामिल करें.

अगर हाथ में पकड़े जाने वाले डिवाइस में 3-ऐक्सिस एक्सलरोमीटर शामिल है, तो:

• [7.3.1/H-1-1] यह ज़रूरी है कि डिवाइस कम से कम 100 हर्ट्ज़ तक की फ़्रीक्वेंसी वाले इवेंट की रिपोर्ट कर सके.

अगर हैंडहेल्ड डिवाइस में GPS/GNSS रिसीवर शामिल है और android.hardware.location.gps सुविधा के फ़्लैग के ज़रिए ऐप्लिकेशन को इसकी जानकारी दी जाती है, तो:

• [7.3.3/H-2-1] जीएनएसएस मेज़रमेंट मिलने के तुरंत बाद, उन्हें रिपोर्ट करना ज़रूरी है. भले ही, जीपीएस/जीएनएसएस से कैलकुलेट की गई जगह की जानकारी अब तक रिपोर्ट न की गई हो.
• [7.3.3/H-2-2] GNSS स्यूडोरेंज और स्यूडोरेंज रेट की जानकारी देना ज़रूरी है. ये ऐसे होते हैं जो जगह की जानकारी तय करने के बाद, खुले आसमान में, स्थिर रहने या 0.2 मीटर प्रति सेकंड स्क्वेयर से कम की रफ़्तार से चलने पर, कम से कम 95% समय तक, जगह की जानकारी 20 मीटर के अंदर और रफ़्तार 0.2 मीटर प्रति सेकंड के अंदर कैलकुलेट करने के लिए काफ़ी होते हैं.

अगर हाथ में पकड़े जाने वाले डिवाइस में तीन ऐक्सिस वाला गायरोस्कोप शामिल है, तो:

• [7.3.4/H-3-1] यह ज़रूरी है कि डिवाइस कम से कम 100 हर्ट्ज़ तक की फ़्रीक्वेंसी वाले इवेंट की रिपोर्ट कर सके.
• [7.3.4/H-3-2] यह ज़रूरी है कि यह हर सेकंड में 1,000 डिग्री तक ओरिएंटेशन में हुए बदलावों को मेज़र कर सके.

ऐसे हैंडहेल्ड डिवाइस जिन पर वॉइस कॉल करने की सुविधा है और जो getPhoneType में PHONE_TYPE_NONE के अलावा कोई भी वैल्यू दिखा सकते हैं:

• [7.3.8/H] इसमें प्रॉक्सिमिटी सेंसर शामिल होना चाहिए.

हैंडहेल्ड डिवाइस पर लागू करने के लिए:

• [7.3.11/H-SR-1] हमारा सुझाव है कि आप ऐसे पोज़ सेंसर का इस्तेमाल करें जिसमें छह डिग्री की फ़्रीडम हो.
• [7.4.3/H] इसमें ब्लूटूथ और ब्लूटूथ एलई के लिए सहायता शामिल होनी चाहिए.

अगर डिवाइसों में PackageManager.FEATURE_WIFI_AWARE का एलान करके, वाई-फ़ाई नेबर अवेयरनेस नेटवर्किंग (एनएएन) प्रोटोकॉल और PackageManager.FEATURE_WIFI_RTT का एलान करके, वाई-फ़ाई लोकेशन (वाई-फ़ाई राउंड ट्रिप टाइम — आरटीटी) की सुविधा काम करती है, तो वे:

• [7.4.2.5/H-1-1] WifiRttManager#startRanging Android API के ज़रिए पता चला है कि 10 सेंटीमीटर, 1 मीटर, 3 मीटर, और 5 मीटर की दूरियों पर, 160 मेगाहर्ट्ज़ बैंडविड्थ के लिए 68वें पर्सेंटाइल (कुल डिस्ट्रिब्यूशन फ़ंक्शन के हिसाब से कैलकुलेट किया गया) में, +/-1 मीटर, 80 मेगाहर्ट्ज़ बैंडविड्थ के लिए 68वें पर्सेंटाइल में, +/-2 मीटर, 40 मेगाहर्ट्ज़ बैंडविड्थ के लिए 68वें पर्सेंटाइल में, +/-4 मीटर, और 20 मेगाहर्ट्ज़ बैंडविड्थ के लिए 68वें पर्सेंटाइल में, +/-8 मीटर तक की रेंज सटीक तौर पर रिपोर्ट की जानी चाहिए.

• [7.4.2.5/H-SR-1] हमारा सुझाव है कि रेंज की सटीक जानकारी दें. इसके लिए, 10 सेंटीमीटर की दूरी पर, 90वें प्रतिशत में 160 मेगाहर्ट्ज़ बैंडविड्थ पर +/-1 मीटर, 90वें प्रतिशत में 80 मेगाहर्ट्ज़ बैंडविड्थ पर +/-2 मीटर, 90वें प्रतिशत में 40 मेगाहर्ट्ज़ बैंडविड्थ पर +/-4 मीटर, और 90वें प्रतिशत में 20 मेगाहर्ट्ज़ बैंडविड्थ पर +/-8 मीटर की जानकारी दें. यह जानकारी, WifiRttManager#startRanging Android API से मिली है.

हमारा सुझाव है कि आप मौजूदगी को कैलिब्रेट करने में बताए गए मेज़रमेंट सेटअप के चरणों का पालन करें.

नई ज़रूरी शर्तें लागू करना

अगर हैंडहेल्ड डिवाइस पर FEATURE_BLUETOOTH_LE का इस्तेमाल किया जाता है, तो:

• [7.4.3/H-1-3] Rx ऑफ़सेट को मेज़र करना और उसका समाधान करना ज़रूरी है, ताकि यह पक्का किया जा सके कि ADVERTISE_TX_POWER_HIGH पर ट्रांसमिशन करने वाले रेफ़रंस डिवाइस से 1 मीटर की दूरी पर, मीडियन बीएलई आरएसएसआई -50dBm +/-15 dB हो.
• [7.4.3/H-1-4] Tx ऑफ़सेट को मेज़र करना और उसका समाधान करना ज़रूरी है, ताकि यह पक्का किया जा सके कि 1 मीटर की दूरी पर मौजूद रेफ़रंस डिवाइस से स्कैन करते समय और ADVERTISE_TX_POWER_HIGH पर ट्रांसमिट करते समय, मीडियन बीएलई आरएसएसआई -50dBm +/-15 dB हो.

नई ज़रूरी शर्तें खत्म करना

अगर हाथ में पकड़े जा सकने वाले डिवाइस के लागू होने में, एक लॉजिकल कैमरा डिवाइस शामिल है, जो CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA का इस्तेमाल करके सुविधाओं की सूची बनाता है, तो:

• [7.5.4/H-1-1] डिफ़ॉल्ट रूप से, फ़ील्ड ऑफ़ व्यू (एफ़ओवी) सामान्य होना चाहिए और यह 50 से 90 डिग्री के बीच होना चाहिए.

हैंडहेल्ड डिवाइस पर लागू करने के लिए:

• [7.6.1/H-0-1] ऐप्लिकेशन के निजी डेटा (जिसे "/data" पार्टीशन भी कहा जाता है) के लिए, कम से कम 4 जीबी का नॉन-वॉल्व्यूलेट स्टोरेज होना चाहिए.
• [7.6.1/H-0-2] जब कर्नेल और यूज़रस्पेस के लिए 1 जीबी से कम मेमोरी उपलब्ध हो, तो ActivityManager.isLowRamDevice() के लिए “सही” दिखाना ज़रूरी है.

अगर हैंडहेल्ड डिवाइस के लिए, सिर्फ़ 32-बिट एबीआई के साथ काम करने की जानकारी दी गई है, तो:

• [7.6.1/H-1-1] अगर डिफ़ॉल्ट डिसप्ले में qHD (जैसे, FWVGA) तक के फ़्रेमबफ़र रिज़ॉल्यूशन का इस्तेमाल किया जाता है, तो कर्नेल और यूज़रस्पेस के लिए कम से कम 416 एमबी मेमोरी होनी चाहिए.

• [7.6.1/H-2-1] अगर डिफ़ॉल्ट डिसप्ले में एचडी+ (जैसे, एचडी, WSVGA) तक के फ़्रेमबफ़र रिज़ॉल्यूशन का इस्तेमाल किया जाता है, तो कर्नेल और यूज़रस्पेस के लिए कम से कम 592 एमबी मेमोरी होनी चाहिए.

• [7.6.1/H-3-1] अगर डिफ़ॉल्ट डिसप्ले, एफ़एचडी (उदाहरण के लिए, WSXGA+) तक के फ़्रेमबफ़र रिज़ॉल्यूशन का इस्तेमाल करता है, तो कर्नेल और यूज़रस्पेस के लिए कम से कम 896 एमबी मेमोरी होनी चाहिए.

• [7.6.1/H-4-1] अगर डिफ़ॉल्ट डिसप्ले में क्वाड हाई डेफ़िनिशन (जैसे, QWXGA) तक के फ़्रेमबफ़र रिज़ॉल्यूशन का इस्तेमाल किया जाता है, तो कर्नेल और यूज़रस्पेस के लिए कम से कम 1344 एमबी मेमोरी उपलब्ध होनी चाहिए.

अगर हैंडहेल्ड डिवाइस पर, 32-बिट एबीआई के साथ या उसके बिना, किसी 64-बिट एबीआई के साथ काम करने की सुविधा उपलब्ध है, तो:

• [7.6.1/H-5-1] अगर डिफ़ॉल्ट डिसप्ले में qHD (उदाहरण के लिए, FWVGA) तक के फ़्रेमबफ़र रिज़ॉल्यूशन का इस्तेमाल किया जाता है, तो कर्नेल और यूज़रस्पेस के लिए कम से कम 816 एमबी मेमोरी उपलब्ध होनी चाहिए.

• [7.6.1/H-6-1] अगर डिफ़ॉल्ट डिसप्ले में एचडी+ (जैसे, एचडी, WSVGA) तक के फ़्रेमबफ़र रिज़ॉल्यूशन का इस्तेमाल किया जाता है, तो कर्नेल और यूज़रस्पेस के लिए कम से कम 944 एमबी मेमोरी होनी चाहिए.

• [7.6.1/H-7-1] अगर डिफ़ॉल्ट डिसप्ले, एफ़एचडी (उदाहरण के लिए, WSXGA+) तक के फ़्रेमबफ़र रिज़ॉल्यूशन का इस्तेमाल करता है, तो कर्नेल और यूज़रस्पेस के लिए उपलब्ध मेमोरी कम से कम 1280 एमबी होनी चाहिए.

• [7.6.1/H-8-1] अगर डिफ़ॉल्ट डिसप्ले में क्यूएचडी (उदाहरण के लिए, QWXGA) तक के फ़्रेमबफ़र रिज़ॉल्यूशन का इस्तेमाल किया जाता है, तो कर्नेल और यूज़रस्पेस के लिए कम से कम 1824 एमबी मेमोरी उपलब्ध होनी चाहिए.

ध्यान दें कि ऊपर दी गई "कर्नल और यूज़रस्पेस के लिए उपलब्ध मेमोरी" से, रेडियो, वीडियो वगैरह जैसे हार्डवेयर कॉम्पोनेंट के लिए पहले से तय मेमोरी के अलावा, डिवाइस में लागू करने के लिए, कर्नेल के कंट्रोल में न होने वाली मेमोरी का मतलब है.

अगर हैंडहेल्ड डिवाइस में, कर्नेल और यूज़रस्पेस के लिए 1 जीबी से कम या उसके बराबर मेमोरी उपलब्ध है, तो:

• [7.6.1/H-9-1] फ़ीचर फ़्लैग के बारे में जानकारी देना ज़रूरी है android.hardware.ram.low.
• [7.6.1/H-9-2] ऐप्लिकेशन के निजी डेटा (जिसे "/data" पार्टीशन भी कहा जाता है) के लिए, कम से कम 1.1 जीबी का नॉन-वॉल्व्यूस्ट स्टोरेज होना चाहिए.

अगर हैंडहेल्ड डिवाइस में, कर्नेल और यूज़रस्पेस के लिए 1 जीबी से ज़्यादा मेमोरी उपलब्ध है, तो:

• [7.6.1/H-10-1] ऐप्लिकेशन के निजी डेटा (जिसे "/data" पार्टीशन भी कहा जाता है) के लिए, कम से कम 4 जीबी का नॉन-वॉल्व्यूस्ट स्टोरेज होना चाहिए.
• फ़ीचर फ़्लैग android.hardware.ram.normal का एलान करना चाहिए.

अगर हैंडहेल्ड डिवाइस में, कर्नेल और यूज़रस्पेस के लिए 2 जीबी या उससे ज़्यादा और 4 जीबी से कम मेमोरी उपलब्ध है, तो:

• [7.6.1/H-SR-1] हमारा सुझाव है कि आप सिर्फ़ 32-बिट यूज़रस्पेस (ऐप्लिकेशन और सिस्टम कोड, दोनों) के साथ काम करें

अगर हैंडहेल्ड डिवाइस में, कर्नेल और यूज़रस्पेस के लिए 2 जीबी से कम मेमोरी उपलब्ध है, तो:

• [7.6.1/H-1-1] यह ज़रूरी है कि यह सिर्फ़ एक एबीआई (सिर्फ़ 64-बिट या सिर्फ़ 32-बिट) के साथ काम करे.

हैंडहेल्ड डिवाइस पर लागू करने के लिए:

• [7.6.2/H-0-1] ऐप्लिकेशन के लिए, 1 जीबी से कम का शेयर किया गया स्टोरेज नहीं दिया जाना चाहिए.
• [7.7.1/H] इसमें, पेरिफ़ेरल मोड के साथ काम करने वाला यूएसबी पोर्ट होना चाहिए.

अगर हाथ में पकड़े जा सकने वाले डिवाइस में, यूएसबी पोर्ट के साथ-साथ, पेरिफ़रल मोड भी काम करता है, तो:

• [7.7.1/H-1-1] Android Open Accessory (AOA) API को लागू करना ज़रूरी है.

अगर हाथ में पकड़े जा सकने वाले डिवाइस में, होस्ट मोड के साथ काम करने वाला यूएसबी पोर्ट शामिल है, तो:

• [7.7.2/H-1-1] Android SDK टूल के दस्तावेज़ में बताए गए तरीके के मुताबिक, यूएसबी ऑडियो क्लास को लागू करना ज़रूरी है.

हैंडहेल्ड डिवाइस पर लागू करने के लिए:

• [7.8.1/H-0-1] इसमें माइक्रोफ़ोन होना ज़रूरी है.
• [7.8.2/H-0-1] इसमें ऑडियो आउटपुट होना चाहिए और इसकी जानकारी दी गई होandroid.hardware.audio.output.

अगर हैंडहेल्ड डिवाइस पर, VR मोड के साथ काम करने के लिए परफ़ॉर्मेंस से जुड़ी सभी ज़रूरी शर्तें पूरी की जा सकती हैं और उसमें VR मोड के साथ काम करने की सुविधा शामिल है, तो:

• [7.9.1/H-1-1] android.hardware.vr.high_performance फ़ीचर फ़्लैग के बारे में ज़रूर बताएं.
• [7.9.1/H-1-2] इसमें ऐसा ऐप्लिकेशन होना चाहिए जिसमें android.service.vr.VrListenerService लागू किया गया हो. साथ ही, android.app.Activity#setVrModeEnabled की मदद से वीआर ऐप्लिकेशन इसे चालू कर सकें.

अगर हैंडहेल्ड डिवाइस में होस्ट मोड में एक या एक से ज़्यादा यूएसबी-सी पोर्ट शामिल हैं और सेक्शन 7.7.2 में बताई गई ज़रूरी शर्तों के अलावा, यूएसबी ऑडियो क्लास को लागू किया गया है, तो:

• [7.8.2.2/H-1-1] एचआईडी कोड के लिए, यहां दी गई सॉफ़्टवेयर मैपिंग ज़रूर उपलब्ध कराएं:

फ़ंक्शन	मैपिंग	संदर्भ	व्यवहार
ए	एचआईडी के इस्तेमाल का पेज: 0x0C एचआईडी के इस्तेमाल की जानकारी: 0x0CD कर्नल पासकोड: KEY_PLAYPAUSE Android पासकोड: KEYCODE_MEDIA_PLAY_PAUSE	मीडिया प्लेबैक	इनपुट: थोड़ी देर के लिए दबाएं आउटपुट: चलाएं या रोकें
			इनपुट: लंबे समय तक दबाएं आउटपुट: बोलकर निर्देश देने की सुविधा चालू करें भेजता है: android.speech.action.VOICE_SEARCH_HANDS_FREE अगर डिवाइस लॉक है या उसकी स्क्रीन बंद है. इसके अलावा, android.speech.RecognizerIntent.ACTION_WEB_SEARCH भेजता है
		आने वाला (इनकमिंग) कॉल	इनपुट: थोड़ी देर के लिए दबाएं आउटपुट: कॉल स्वीकार करना
			इनपुट: दबाकर रखें आउटपुट: कॉल को अस्वीकार करना
		पहले से जारी कॉल	इनपुट: थोड़ी देर के लिए दबाएं आउटपुट: कॉल खत्म करें
			इनपुट: दबाकर रखें आउटपुट: माइक्रोफ़ोन को म्यूट या अनम्यूट करना
B	एचआईडी के इस्तेमाल का पेज: 0x0C एचआईडी के इस्तेमाल की जानकारी: 0x0E9 कर्नल पासकोड: KEY_VOLUMEUP Android पासकोड: VOLUME_UP	मीडिया प्लेबैक, कॉल जारी है	इनपुट: थोड़ी देर या ज़्यादा देर तक दबाएं आउटपुट: सिस्टम या हेडसेट की आवाज़ बढ़ाता है
C	एचआईडी के इस्तेमाल से जुड़ा पेज: 0x0C एचआईडी के इस्तेमाल से जुड़ी जानकारी: 0x0EA कर्नल पासकोड: KEY_VOLUMEDOWN Android पासकोड: VOLUME_DOWN	मीडिया प्लेबैक, कॉल जारी है	इनपुट: थोड़ी देर या ज़्यादा देर तक दबाएं आउटपुट: सिस्टम या हेडसेट की आवाज़ कम हो जाती है
D	एचआईडी के इस्तेमाल से जुड़ा पेज: 0x0C एचआईडी के इस्तेमाल से जुड़ी जानकारी: 0x0CF कर्नल पासकोड: KEY_VOICECOMMAND Android पासकोड: KEYCODE_VOICE_ASSIST	सभी थ्रेड के लिए. किसी भी इंस्टेंस में ट्रिगर किया जा सकता है.	इनपुट: थोड़ी देर या ज़्यादा देर तक दबाएं आउटपुट: बोलकर निर्देश देने की सुविधा चालू करें

• [7.8.2.2/H-1-2] प्लग डालने पर, ACTION_HEADSET_PLUG को ट्रिगर करना ज़रूरी है. हालांकि, ऐसा सिर्फ़ तब किया जाना चाहिए, जब यूएसबी ऑडियो इंटरफ़ेस और एंडपॉइंट को सही तरीके से एनोटेट किया गया हो, ताकि कनेक्ट किए गए टर्मिनल के टाइप की पहचान की जा सके.

जब यूएसबी ऑडियो टर्मिनल टाइप 0x0302 का पता चलता है, तो:

• [7.8.2.2/H-2-1] "माइक्रोफ़ोन" एक्सट्रा को 0 पर सेट करके, ACTION_HEADSET_PLUG इंटेंट को ब्रॉडकास्ट करना ज़रूरी है.

जब यूएसबी ऑडियो टर्मिनल टाइप 0x0402 का पता चलता है, तो:

• [7.8.2.2/H-3-1] "माइक्रोफ़ोन" को 1 पर सेट करके, ज़रूर से 'इंटेंट ACTION_HEADSET_PLUG' ब्रॉडकास्ट करें.

जब यूएसबी डिवाइस कनेक्ट होने के दौरान, API AudioManager.getDevices() को कॉल किया जाता है, तो:

• [7.8.2.2/H-4-1] अगर यूएसबी ऑडियो टर्मिनल टाइप फ़ील्ड 0x0302 है, तो AudioDeviceInfo.TYPE_USB_HEADSET टाइप का डिवाइस और भूमिका isSink() ज़रूर शामिल करें.

• [7.8.2.2/H-4-2] अगर यूएसबी ऑडियो टर्मिनल टाइप फ़ील्ड 0x0402 है, तो डिवाइस के टाइप के तौर पर AudioDeviceInfo.TYPE_USB_HEADSET और भूमिका के तौर पर isSink() की जानकारी देना ज़रूरी है.

• [7.8.2.2/H-4-3] अगर यूएसबी ऑडियो टर्मिनल टाइप फ़ील्ड 0x0402 है, तो टाइप के तौर पर AudioDeviceInfo.TYPE_USB_HEADSET और भूमिका isSource() वाला डिवाइस ज़रूर शामिल करना चाहिए.

• [7.8.2.2/H-4-4] AudioDeviceInfo.TYPE_USB_DEVICE टाइप का डिवाइस और भूमिका isSink() की सूची ज़रूर होनी चाहिए. ऐसा तब करना होगा, जब यूएसबी ऑडियो टर्मिनल टाइप फ़ील्ड 0x603 हो.

• [7.8.2.2/H-4-5] अगर यूएसबी ऑडियो टर्मिनल टाइप फ़ील्ड 0x604 है, तो डिवाइस के टाइप के तौर पर AudioDeviceInfo.TYPE_USB_DEVICE और भूमिका के तौर पर isSource() की जानकारी देना ज़रूरी है.

• [7.8.2.2/H-4-6] अगर USB ऑडियो टर्मिनल टाइप फ़ील्ड 0x400 है, तो टाइप के तौर पर AudioDeviceInfo.TYPE_USB_DEVICE और भूमिका के तौर पर isSink() वाला डिवाइस ज़रूर शामिल करना चाहिए.

• [7.8.2.2/H-4-7] अगर यूएसबी ऑडियो टर्मिनल टाइप फ़ील्ड 0x400 है, तो डिवाइस के टाइप के तौर पर AudioDeviceInfo.TYPE_USB_DEVICE और भूमिका के तौर पर isSource() की जानकारी देना ज़रूरी है.

• [7.8.2.2/H-SR-1] USB-C ऑडियो डिवाइस को कनेक्ट करने पर, इनका इस्तेमाल करने का ज़रूर सुझाव दिया जाता है. इससे, USB डिस्क्रिप्टर की गिनती की जा सकती है, टर्मिनल टाइप की पहचान की जा सकती है, और 1,000 मिलीसेकंड से भी कम समय में Intent ACTION_HEADSET_PLUG ब्रॉडकास्ट किया जा सकता है.

अगर हैंडहेल्ड डिवाइस पर android.hardware.audio.output और android.hardware.microphone का एलान किया जाता है, तो:

• [5.6/H-1-1] पांच मेज़रमेंट में, 300 मिलीसेकंड या इससे कम का औसत राउंड-ट्रिप विलंब होना चाहिए. साथ ही, इन डेटा पाथ पर, 30 मिलीसेकंड से कम का औसत एब्सोल्यूट डेविएशन होना चाहिए: "स्पीकर से माइक्रोफ़ोन", 3.5 मि॰मी॰ का लूपबैक अडैप्टर (अगर काम करता है), यूएसबी लूपबैक (अगर काम करता है).

• [5.6/H-1-2] टैप-टू-टोन के लिए, स्पीकर से माइक्रोफ़ोन के डेटा पाथ के कम से कम पांच मेज़रमेंट में, औसतन 300 मिलीसेकंड या उससे कम का इंतज़ार होना चाहिए.

अगर हैंडहेल्ड डिवाइस में कम से कम एक हैप्टिक ऐक्ट्यूएटर शामिल है, तो:

• [7.10/H]* इसमें एक्ससेंट्रिक रोटेटेड मैस (ईआरएम) वाले हैप्टिक ऐक्चुएटर (वाइब्रेटर) का इस्तेमाल नहीं किया जाना चाहिए.
• [7.10/H]* android.view.HapticFeedbackConstants में, साफ़ तौर पर महसूस होने वाले वाइब्रेशन के लिए सभी सार्वजनिक कॉन्स्टेंट लागू करने चाहिए. जैसे, CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY, VIRTUAL_KEY_RELEASE, CONFIRM, REJECT, GESTURE_START, और GESTURE_END.
• [7.10/H]* android.os.VibrationEffect में, साफ़-साफ़ महसूस होने वाले वाइब्रेशन के लिए सभी सार्वजनिक कॉन्स्टेंट लागू करने चाहिए. जैसे, (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK, और EFFECT_DOUBLE_CLICK). साथ ही, android.os.VibrationEffect.Composition में, ज़्यादा महसूस होने वाले वाइब्रेशन के लिए सभी संभावित सार्वजनिक PRIMITIVE_* कॉन्स्टेंट लागू करने चाहिए. जैसे, (CLICK, TICK, LOW_TICK, QUICK_FALL, QUICK_RISE, SLOW_RISE, SPIN, THUD). इनमें से कुछ प्राइमिटिव, जैसे कि LOW_TICK और SPIN सिर्फ़ तब काम कर सकते हैं, जब वाइब्रेटर कम फ़्रीक्वेंसी पर काम कर सकता हो.
• [7.10/H]* को android.view.HapticFeedbackConstants में सार्वजनिक कॉन्स्टेंट को मैप करने के लिए दिशा-निर्देशों का पालन करना चाहिए. साथ ही, सुझाई गई android.os.VibrationEffect कॉन्स्टेंट के साथ, अम्प्ल्यट्यूड के संबंधों का पालन करना चाहिए.
• [7.10/H]* को createOneShot() और createWaveform() एपीआई के लिए, क्वालिटी की जांच की प्रक्रिया का पालन करना चाहिए.
• [7.10/H]* यह पुष्टि करनी चाहिए कि सार्वजनिक android.os.Vibrator.hasAmplitudeControl() एपीआई का नतीजा, उनके वाइब्रेटर की क्षमताओं को सही तरीके से दिखाता है.
• [7.10/H]* ऐक्चुएटर को उस जगह के आस-पास रखना चाहिए जहां आम तौर पर डिवाइस को हाथ से पकड़ा जाता है या छुआ जाता है.

लीनियर रेज़ॉनैंट ऐक्चुएटर (एलआरए) एक सिंगल-मास स्प्रिंग सिस्टम है. इसमें एक मुख्य रेज़ॉनैंट फ़्रीक्वेंसी होती है, जहां मास, अपनी पसंद की गति की दिशा में ट्रांसलेट करता है.

अगर हाथ में पकड़े जाने वाले डिवाइस में कम से कम एक सामान्य 7.10 लीनियर रेज़ॉनैंट ऐक्चुएटर शामिल है, तो:

नई ज़रूरी शर्तें लागू करना

• [7.10/H] ऐक्चुएटर को उस जगह के आस-पास रखना चाहिए जहां डिवाइस को आम तौर पर हाथों से पकड़ा जाता है या छुआ जाता है.

नई ज़रूरी शर्तें खत्म करना

• [7.10/H] हैप्टिक ऐक्चुएटर को डिवाइस के सामान्य पोर्ट्रेट ओरिएंटेशन के X-ऐक्सिस (बाएं-दाएं) में ले जाना चाहिए.

अगर हैंडहेल्ड डिवाइस में सामान्य तौर पर इस्तेमाल होने वाला haptic actuator है, जो X-axis लीनियर रेज़ॉनैंट ऐक्चुएटर (LRA) है, तो:

• [7.10/H] X-ऐक्सिस एलआरए की अनुनाद फ़्रीक्वेंसी 200 हर्ट्ज़ से कम होनी चाहिए.

अगर हैंडहेल्ड डिवाइस पर, स्पर्श से जुड़ी कॉन्स्टेंट मैपिंग का इस्तेमाल किया जाता है, तो:

• [7.10/H]* को android.os.Vibrator.areAllEffectsSupported() और android.os.Vibrator.arePrimitivesSupported() एपीआई को चलाकर, लागू होने की स्थिति की पुष्टि करनी चाहिए.

• [7.10/घंटा]* को वाइब्रेशन के लिए, क्वालिटी का आकलन करना चाहिए.

• [7.10/H]* कॉन्स्टेंट के लिए लागू करने के दिशा-निर्देश में बताए गए तरीके के मुताबिक, काम न करने वाले प्राइमिटिव के लिए फ़ॉलबैक कॉन्फ़िगरेशन की पुष्टि करनी चाहिए और ज़रूरत पड़ने पर उसे अपडेट करना चाहिए.

2.2.2. मल्टीमीडिया

हैंडहेल्ड डिवाइस पर, ऑडियो कोडिंग और डिकोडिंग के लिए इन फ़ॉर्मैट का इस्तेमाल किया जाना चाहिए. साथ ही, इन्हें तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराया जाना चाहिए:

• [5.1/H-0-1] AMR-NB
• [5.1/H-0-2] AMR-WB
• [5.1/H-0-3] MPEG-4 AAC प्रोफ़ाइल (AAC LC)
• [5.1/H-0-4] MPEG-4 HE AAC Profile (AAC+)
• [5.1/H-0-5] AAC ELD (कम देरी वाला बेहतर AAC)

हैंडहेल्ड डिवाइस पर, वीडियो को इन फ़ॉर्मैट में एन्कोड किया जा सकता है. साथ ही, इन्हें तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराया जा सकता है:

• [5.2/H-0-1] H.264 AVC
• [5.2/H-0-2] VP8

नई ज़रूरी शर्तें लागू करना

• [5.2/H-0-3] AV1

नई ज़रूरी शर्तें खत्म करना

हैंडहेल्ड डिवाइस पर, वीडियो को डिकोड करने के लिए इन फ़ॉर्मैट का इस्तेमाल किया जाना चाहिए. साथ ही, इन्हें तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराया जाना चाहिए:

• [5.3/H-0-1] H.264 AVC
• [5.3/H-0-2] H.265 HEVC
• [5.3/H-0-3] MPEG-4 SP
• [5.3/H-0-4] VP8
• [5.3/H-0-5] VP9

नई ज़रूरी शर्तें लागू करना

• [5.3/H-0-6] AV1

नई ज़रूरी शर्तें खत्म करना

2.2.3. सॉफ़्टवेयर

हैंडहेल्ड डिवाइस पर लागू करने के लिए:

• [3.2.3.1/H-0-1] ऐप्लिकेशन में, SDK टूल के दस्तावेज़ों में बताए गए ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE, और ACTION_CREATE_DOCUMENT के ज़रिए, इंटेंट मैनेज करने की सुविधा होनी चाहिए. साथ ही, DocumentsProvider एपीआई का इस्तेमाल करके, दस्तावेज़ उपलब्ध कराने वाली कंपनी का डेटा ऐक्सेस करने के लिए, उपयोगकर्ता को सुविधा देनी चाहिए.
• [3.2.3.1/H-0-2]* यहां दिए गए ऐप्लिकेशन इंटेंट के मुताबिक तय किए गए सभी सार्वजनिक इंटेंट फ़िल्टर पैटर्न के लिए, एक या उससे ज़्यादा ऐप्लिकेशन या सेवा कॉम्पोनेंट को इंटेंट हैंडलर के साथ पहले से लोड करना ज़रूरी है.
• [3.2.3.1/H-SR-1] हमारा सुझाव है कि आप ईमेल भेजने के लिए, ACTION_SENDTO या ACTION_SEND या ACTION_SEND_MULTIPLE इंटेंट को मैनेज करने वाला ईमेल ऐप्लिकेशन पहले से लोड करें.
• [3.4.1/H-0-1] android.webkit.Webview एपीआई को पूरी तरह से लागू करना ज़रूरी है.
• [3.4.2/H-0-1] इसमें, सामान्य उपयोगकर्ता के वेब ब्राउज़ करने के लिए, अलग से उपलब्ध ब्राउज़र ऐप्लिकेशन होना चाहिए.
• [3.8.1/H-SR-1] हमारा सुझाव है कि आप डिफ़ॉल्ट लॉन्चर लागू करें. यह लॉन्चर, शॉर्टकट, विजेट, और widgetFeatures को ऐप्लिकेशन में पिन करने की सुविधा देता है.
• [3.8.1/H-SR-2] हमारा सुझाव है कि आप डिफ़ॉल्ट लॉन्चर लागू करें. इससे, ShortcutManager एपीआई की मदद से, तीसरे पक्ष के ऐप्लिकेशन के अतिरिक्त शॉर्टकट को तुरंत ऐक्सेस किया जा सकता है.
• [3.8.1/H-SR-3] हमारा सुझाव है कि आप डिफ़ॉल्ट लॉन्चर ऐप्लिकेशन शामिल करें. यह ऐप्लिकेशन, ऐप्लिकेशन के आइकॉन के लिए बैज दिखाता है.
• [3.8.2/H-SR-1] तीसरे पक्ष के ऐप्लिकेशन के विजेट के साथ काम करने के लिए, ऐसा करने का ज़रूर सुझाव दिया जाता है.
• [3.8.3/H-0-1] तीसरे पक्ष के ऐप्लिकेशन को Notification और NotificationManager एपीआई क्लास की मदद से, उपयोगकर्ताओं को अहम इवेंट की सूचना देने की अनुमति देनी चाहिए.
• [3.8.3/H-0-2] रिच सूचनाओं के साथ काम करना चाहिए.
• [3.8.3/H-0-3] ऐप्लिकेशन में हेड्स-अप सूचनाएं भेजने की सुविधा होनी चाहिए.
• [3.8.3/H-0-4] ऐप्लिकेशन में सूचना शेड होना ज़रूरी है. इससे उपयोगकर्ता, सूचनाओं को सीधे तौर पर कंट्रोल कर सकता है. जैसे, जवाब देना, स्नूज़ करना, खारिज करना, ब्लॉक करना. इसके लिए, उपयोगकर्ता को AOSP में लागू किए गए ऐक्शन बटन या कंट्रोल पैनल जैसे यूज़र अफ़र्डेंस की ज़रूरत होती है.
• [3.8.3/H-0-5] नोटिफ़िकेशन शेड में, RemoteInput.Builder setChoices() के ज़रिए दिए गए विकल्प दिखाने ज़रूरी हैं.
• [3.8.3/H-SR-1] हमारा सुझाव है कि आप सूचना शेड में, RemoteInput.Builder setChoices() के ज़रिए दिया गया पहला विकल्प दिखाएं. इसके लिए, उपयोगकर्ता से कोई और इंटरैक्शन ज़रूरी नहीं है.
• [3.8.3/H-SR-2] हमारा सुझाव है कि जब उपयोगकर्ता, नोटिफ़िकेशन शेड में सभी सूचनाओं को बड़ा करे, तो नोटिफ़िकेशन शेड में RemoteInput.Builder setChoices() के ज़रिए दिए गए सभी विकल्प दिखाए जाएं.
• [3.8.3.1/H-SR-1] हमारा सुझाव है कि आप उन कार्रवाइयों को दिखाएं जिनके लिए Notification.Action.Builder.setContextual को true के तौर पर सेट किया गया है. ये कार्रवाइयां, Notification.Remoteinput.Builder.setChoices से दिखाए गए जवाबों के साथ-साथ दिखेंगी.
• [3.8.4/H-SR-1] Assist ऐक्शन को मैनेज करने के लिए, डिवाइस पर किसी असिस्टेंट को लागू करने का ज़रूर सुझाव दिया जाता है.

अगर हैंडहेल्ड डिवाइस पर MediaStyle सूचनाएं काम करती हैं, तो:

• [3.8.3.1/H-SR-2] हमारा सुझाव है कि आप अपने ऐप्लिकेशन में, उपयोगकर्ताओं को सिस्टम यूज़र इंटरफ़ेस (यूआई) से ऐक्सेस किया जा सकने वाला आउटपुट स्विचर जैसा कोई ऐसा फ़ंक्शन दें जिससे वे MediaSession टोकन के साथ MediaStyle सूचना पोस्ट करने पर, उपलब्ध मीडिया रूट (उदाहरण के लिए, ब्लूटूथ डिवाइस और MediaRouter2Manager को दिए गए रूट) के बीच स्विच कर सकें.

नई ज़रूरी शर्तें लागू करना

अगर डिवाइस में हाल ही के फ़ंक्शन की नेविगेशन बटन के साथ-साथ, 7.2.3 सेक्शन में बताई गई अन्य सुविधाएं लागू करने पर इंटरफ़ेस में बदलाव होता है, तो:

• [3.8.3/H-1-1] स्क्रीन पिन करने की सुविधा को लागू करना ज़रूरी है. साथ ही, उपयोगकर्ता को सेटिंग मेन्यू उपलब्ध कराना होगा, ताकि वह इस सुविधा को टॉगल कर सके.

नई ज़रूरी शर्तें खत्म करना

अगर हैंडहेल्ड डिवाइस पर, असिस्ट ऐक्शन की सुविधा काम करती है, तो:

• [3.8.4/H-SR-2] हमारा सुझाव है कि आप HOME बटन को दबाकर रखें, ताकि सहायता ऐप्लिकेशन को लॉन्च किया जा सके. इस बारे में सेक्शन 7.2.3 में बताया गया है. उपयोगकर्ता के चुने गए असिस्ट ऐप्लिकेशन को लॉन्च करना ज़रूरी है. दूसरे शब्दों में, वह ऐप्लिकेशन जो VoiceInteractionService को लागू करता है या ACTION_ASSIST इंटेंट को मैनेज करने वाली गतिविधि.

अगर हैंडहेल्ड डिवाइस पर conversation notifications की सुविधा काम करती है और सूचनाओं को सूचना देने वाली और साइलेंट मोड में मिलने वाली सूचनाओं से अलग सेक्शन में रखा जाता है, तो:

• [3.8.4/H-1-1]* बातचीत से जुड़ी सूचनाओं को, बातचीत से जुड़ी सूचनाओं के अलावा अन्य सूचनाओं से पहले दिखाना ज़रूरी है. हालांकि, फ़ोरग्राउंड सेवा की चल रही सूचनाओं और ज़रूरत:ज़्यादा वाली सूचनाओं को छोड़कर.

अगर Android डिवाइस पर लॉक स्क्रीन की सुविधा काम करती है, तो:

• [3.8.10/H-1-1] ऐप्लिकेशन को Lock screen पर सूचनाएं दिखानी चाहिए. इनमें मीडिया सूचना टेंप्लेट भी शामिल है.

अगर हैंडहेल्ड डिवाइस पर सुरक्षित लॉक स्क्रीन की सुविधा काम करती है, तो:

• [3.9/H-1-1] Android SDK के दस्तावेज़ में बताई गई, डिवाइस मैनेजमेंट से जुड़ी सभी नीतियों को लागू करना ज़रूरी है.

अगर हैंडहेल्ड डिवाइस के लागू होने में, ControlsProviderService और Control एपीआई के साथ-साथ तीसरे पक्ष के ऐप्लिकेशन को डिवाइस कंट्रोल पब्लिश करने की अनुमति शामिल है, तो:

• [3.8.16/H-1-1] सुविधा के लिए, फ़्लैग android.software.controls का एलान करना ज़रूरी है और इसे true पर सेट करना ज़रूरी है.
• [3.8.16/H-1-2] ऐप्लिकेशन में, उपयोगकर्ता को ControlsProviderService और Control एपीआई की मदद से, तीसरे पक्ष के ऐप्लिकेशन के रजिस्टर किए गए कंट्रोल में से, अपने डिवाइस के पसंदीदा कंट्रोल जोड़ने, उनमें बदलाव करने, उन्हें चुनने, और इस्तेमाल करने की सुविधा देनी ज़रूरी है.
• [3.8.16/H-1-3] डिफ़ॉल्ट लॉन्चर से तीन इंटरैक्शन के अंदर, उपयोगकर्ता को इस सुविधा का ऐक्सेस देना ज़रूरी है.

• [3.8.16/H-1-4] इस यूज़र अवर्डेंस में, तीसरे पक्ष के हर उस ऐप्लिकेशन का नाम और आइकॉन सटीक तरीके से रेंडर करना ज़रूरी है जो ControlsProviderService एपीआई के ज़रिए कंट्रोल उपलब्ध कराता है. साथ ही, Control एपीआई से मिले किसी भी खास फ़ील्ड को भी रेंडर करना ज़रूरी है.

• [3.8.16/H-1-5] ऐप्लिकेशन के लिए तय किए गए, डिवाइस के ऐसे कंट्रोल से ऑप्ट आउट करने के लिए, उपयोगकर्ता को अवसर देना ज़रूरी है जो तीसरे पक्ष के ऐप्लिकेशन ने ControlsProviderService और Control Control.isAuthRequired एपीआई की मदद से रजिस्टर किए हैं.

नई ज़रूरी शर्तें लागू करना

• [3.8.16/H-1-6] डिवाइस के लागू होने के बाद, उपयोगकर्ता के लिए उपलब्ध सुविधाओं को इस तरह सटीक तरीके से रेंडर करना ज़रूरी है:
  • अगर डिवाइस पर config_supportsMultiWindow=true सेट है और ऐप्लिकेशन ने ControlsProviderService एलान में, मेटाडेटा META_DATA_PANEL_ACTIVITY एलान किया है, जिसमें मान्य गतिविधि का ComponentName (जैसा कि एपीआई ने बताया है) शामिल है, तो ऐप्लिकेशन को इस उपयोगकर्ता के लिए उपलब्ध सुविधा में बताई गई गतिविधि को एम्बेड करना होगा.
  • अगर ऐप्लिकेशन में मेटाडेटा META_DATA_PANEL_ACTIVITY का एलान नहीं किया गया है, तो उसे ControlsProviderService एपीआई के ज़रिए बताए गए फ़ील्ड के साथ-साथ, Control एपीआई के ज़रिए बताए गए फ़ील्ड भी रेंडर करने होंगे.
• [3.8.16/H-1-7] अगर ऐप्लिकेशन में मेटाडेटा META_DATA_PANEL_ACTIVITY का एलान किया गया है, तो एम्बेड की गई गतिविधि को लॉन्च करते समय, उसे [3.8.16/H-1-5] में बताई गई सेटिंग की वैल्यू EXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS का इस्तेमाल करके पास करनी होगी.

नई ज़रूरी शर्तें खत्म करना

इसके उलट, अगर हैंडहेल्ड डिवाइस पर ऐसे कंट्रोल लागू नहीं किए जाते हैं, तो:

• [3.8.16/H-2-1] ControlsProviderService और Control एपीआई के लिए, null की जानकारी देना ज़रूरी है.
• [3.8.16/H-2-2] सुविधा के लिए, फ़्लैग android.software.controls का एलान करना ज़रूरी है और इसे false पर सेट करना ज़रूरी है.

अगर हैंडहेल्ड डिवाइस पर लॉक टास्क मोड में काम नहीं किया जा रहा है, तो क्लिपबोर्ड पर कॉपी किए गए कॉन्टेंट के लिए:

• [3.8.17/H-1-1] उपयोगकर्ता को यह पुष्टि करनी चाहिए कि डेटा को क्लिपबोर्ड पर कॉपी कर लिया गया है. उदाहरण के लिए, “कॉन्टेंट कॉपी हो गया है” का थंबनेल या सूचना. इसके अलावा, यहां यह जानकारी भी शामिल करें कि क्लिपबोर्ड का डेटा सभी डिवाइसों पर सिंक किया जाएगा या नहीं.

हैंडहेल्ड डिवाइस पर लागू करने के लिए:

• [3.10/H-0-1] ऐप्लिकेशन में, तीसरे पक्ष की सुलभता सेवाओं के साथ काम करने की सुविधा होनी चाहिए.
• [3.10/H-SR-1] हमारा सुझाव है कि डिवाइस पर सुलभता सेवाओं को पहले से लोड करें. ये सेवाएं, TalkBack के ओपन सोर्स प्रोजेक्ट में बताई गई, Switch Access और TalkBack (पहले से इंस्टॉल किए गए टेक्स्ट-टू-स्पीच इंजन के साथ काम करने वाली भाषाओं के लिए) की सुलभता सेवाओं के बराबर या उनसे बेहतर होनी चाहिए.
• [3.11/H-0-1] तीसरे पक्ष के टीटीएस इंजन को इंस्टॉल करने की सुविधा होनी चाहिए.
• [3.11/H-SR-1] हमारा सुझाव है कि आप डिवाइस पर उपलब्ध भाषाओं के साथ काम करने वाला TTS इंजन शामिल करें.
• [3.13/H-SR-1] हमारा सुझाव है कि आप क्विक सेटिंग यूज़र इंटरफ़ेस (यूआई) कॉम्पोनेंट शामिल करें.

अगर Android हैंडहेल्ड डिवाइस पर FEATURE_BLUETOOTH या FEATURE_WIFI की सुविधा काम करती है, तो:

• [3.16/H-1-1] यह ऐप्लिकेशन, साथ में इस्तेमाल किए जाने वाले डिवाइस को जोड़ने की सुविधा के साथ काम करना चाहिए.

अगर नेविगेशन फ़ंक्शन, स्क्रीन पर जेस्चर के आधार पर कार्रवाई करने के तौर पर दिया गया है, तो:

• [7.2.3/H] होम फ़ंक्शन के लिए, जेस्चर की पहचान करने वाला ज़ोन, स्क्रीन के सबसे नीचे से 32 डीपी से ज़्यादा नहीं होना चाहिए.

अगर हैंडहेल्ड डिवाइस पर, स्क्रीन के बाएं और दाएं किनारों पर कहीं से भी जेस्चर के तौर पर नेविगेशन फ़ंक्शन उपलब्ध कराया जाता है, तो:

• [7.2.3/H-0-1] नेविगेशन फ़ंक्शन के जेस्चर एरिया की चौड़ाई, हर तरफ़ 40 डीपी से कम होनी चाहिए. जेस्चर एरिया की चौड़ाई, डिफ़ॉल्ट रूप से 24 dp होनी चाहिए.

अगर हैंडहेल्ड डिवाइस पर सुरक्षित लॉक स्क्रीन की सुविधा काम करती है और उसके कर्नेल और यूज़रस्पेस में 2 जीबी या उससे ज़्यादा मेमोरी उपलब्ध है, तो:

• [3.9/H-1-2] android.software.managed_users सुविधा फ़्लैग की मदद से, मैनेज की जा रही प्रोफ़ाइलों के साथ काम करने की सुविधा के बारे में ज़रूर बताएं.

अगर Android वाले हैंडहेल्ड डिवाइस में, android.hardware.camera.any के ज़रिए कैमरे के काम करने की जानकारी दी गई है, तो:

• [7.5.4/H-1-1] SDK टूल में बताए गए तरीके के मुताबिक, android.media.action.STILL_IMAGE_CAMERA और android.media.action.STILL_IMAGE_CAMERA_SECURE इंटेंट को पूरा करना ज़रूरी है. साथ ही, कैमरे को स्टिल इमेज मोड में लॉन्च करना ज़रूरी है.
• [7.5.4/H-1-2] SDK टूल में बताए गए तरीके के मुताबिक, कैमरे को वीडियो मोड में लॉन्च करने के लिए, android.media.action.VIDEO_CAMERA के इरादे का सम्मान करना ज़रूरी है.

अगर डिवाइस पर लागू किए गए सेटिंग ऐप्लिकेशन में, गतिविधि को एम्बेड करने की सुविधा का इस्तेमाल करके अलग-अलग फ़ंक्शन लागू किए जाते हैं, तो:

• [3.2.3.1/ H-1-1] स्प्लिट फ़ंक्शन चालू होने पर, इसमें ऐसी गतिविधि होनी चाहिए जो Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY इंटेंट को मैनेज करती हो. गतिविधि को android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK से सुरक्षित किया जाना चाहिए. साथ ही, यह Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI से पार्स किए गए इंटेंट की गतिविधि शुरू करनी चाहिए.

नई ज़रूरी शर्तें लागू करना

अगर डिवाइस के लागू होने से, उपयोगकर्ताओं को किसी भी तरह के कॉल करने की अनुमति मिलती है, तो वे

• [7.4.1.2/H-0-1] फ़ीचर फ़्लैग android.software.telecom का एलान करना ज़रूरी है.
• [7.4.1.2/H-0-2] टेलीकॉम फ़्रेमवर्क लागू करना ज़रूरी है.

नई ज़रूरी शर्तें खत्म करना

2.2.4. परफ़ॉर्मेंस और पावर

• [8.1/H-0-1] फ़्रेम के लोड होने में लगने वाला समय एक जैसा होना. फ़्रेम रेट में उतार-चढ़ाव या फ़्रेम रेंडर होने में लगने वाला समय, एक सेकंड में पांच फ़्रेम से ज़्यादा नहीं होना चाहिए. साथ ही, यह एक सेकंड में एक फ़्रेम से कम होना चाहिए.
• [8.1/H-0-2] यूज़र इंटरफ़ेस में लगने वाला समय. डिवाइस में लागू करने के लिए, यह ज़रूरी है कि उपयोगकर्ता को कम इंतज़ार का अनुभव मिले. इसके लिए, Android Compatibility Test Suite (CTS) के मुताबिक, 10 हज़ार सूची वाली एंट्री को 36 सेकंड से कम समय में स्क्रोल किया जाना चाहिए.
• [8.1/H-0-3] टास्क स्विच करना. जब कई ऐप्लिकेशन लॉन्च किए जाते हैं, तो पहले से चल रहे ऐप्लिकेशन को फिर से लॉन्च करने में एक सेकंड से कम समय लगना चाहिए.

हैंडहेल्ड डिवाइस पर लागू करने के लिए:

• [8.2/H-0-1] यह पक्का करना ज़रूरी है कि क्रम से लिखने की परफ़ॉर्मेंस कम से कम 5 एमबी/सेकंड हो.
• [8.2/H-0-2] यह पक्का करना ज़रूरी है कि रैंडम राइटिंग की परफ़ॉर्मेंस कम से कम 0.5 एमबी/सेकंड हो.
• [8.2/H-0-3] यह पक्का करना ज़रूरी है कि क्रम से पढ़ने की परफ़ॉर्मेंस कम से कम 15 एमबी/सेकंड हो.
• [8.2/H-0-4] यह पक्का करना ज़रूरी है कि रैंडम रीड की परफ़ॉर्मेंस कम से कम 3.5 एमबी/सेकंड हो.

अगर हाथ में पकड़े जा सकने वाले डिवाइसों में, डिवाइस के पावर मैनेजमेंट को बेहतर बनाने के लिए AOSP में शामिल सुविधाएं शामिल की जाती हैं या AOSP में शामिल सुविधाओं को बढ़ाया जाता है, तो:

• [8.3/H-1-1] बैटरी सेवर मोड को चालू और बंद करने के लिए, उपयोगकर्ता को आसानी से ऐक्सेस करने की सुविधा देना ज़रूरी है.
• [8.3/H-1-2] ऐप्लिकेशन स्टैंडबाय और Doze पावर-सेविंग मोड से छूट पाने वाले सभी ऐप्लिकेशन दिखाने के लिए, उपयोगकर्ता को सुविधा देना ज़रूरी है.

हैंडहेल्ड डिवाइस पर लागू करने के लिए:

• [8.4/H-0-1] हर कॉम्पोनेंट के लिए, बिजली की खपत की प्रोफ़ाइल देना ज़रूरी है. इससे हर हार्डवेयर कॉम्पोनेंट के लिए, बिजली की खपत की वैल्यू और समय के साथ कॉम्पोनेंट की वजह से बैटरी की खपत के अनुमान की जानकारी मिलती है. इस बारे में Android Open Source Project की साइट पर जानकारी दी गई है.
• [8.4/H-0-2] बिजली की खपत की सभी वैल्यू को मिलीऐंपियर घंटे (mAh) में रिपोर्ट करना ज़रूरी है.
• [8.4/H-0-3] हर प्रोसेस के यूआईडी के हिसाब से, सीपीयू की बिजली की खपत की जानकारी देना ज़रूरी है. Android ओपन सोर्स प्रोजेक्ट, uid_cputime कर्नेल मॉड्यूल लागू करने की ज़रूरी शर्तें पूरी करता है.
• [8.4/H-0-4] ऐप्लिकेशन डेवलपर को, बिजली की खपत की जानकारी adb shell dumpsys batterystats शेल कमांड के ज़रिए उपलब्ध कराना ज़रूरी है.
• [8.4/H] अगर हार्डवेयर कॉम्पोनेंट के पावर इस्तेमाल को किसी ऐप्लिकेशन के लिए एट्रिब्यूट नहीं किया जा सकता, तो इसे हार्डवेयर कॉम्पोनेंट के लिए एट्रिब्यूट किया जाना चाहिए.

अगर हैंडहेल्ड डिवाइस के लागू होने में स्क्रीन या वीडियो आउटपुट शामिल है, तो:

• [8.4/H-1-1] ऐप्लिकेशन को android.intent.action.POWER_USAGE_SUMMARY के इंटेंट का सम्मान करना चाहिए और एक सेटिंग मेन्यू दिखाना चाहिए, जिसमें बिजली के इस्तेमाल की जानकारी दिखे.

हैंडहेल्ड डिवाइस पर लागू करने के लिए:

• [8.5/H-0-1] सेटिंग मेन्यू में, उपयोगकर्ता को ऐप्लिकेशन इस्तेमाल करने के लिए एक विकल्प देना ज़रूरी है, ताकि वह ऐसे सभी ऐप्लिकेशन देख सके जिनमें फ़ोरग्राउंड सेवाएं चालू हैं या उपयोगकर्ता ने कोई जॉब शुरू किया है. इसमें, SDK दस्तावेज़ में बताए गए तरीके के हिसाब से, इन सेवाओं के शुरू होने से लेकर अब तक की अवधि भी दिखनी चाहिए. साथ ही, उपयोगकर्ता को किसी ऐसे ऐप्लिकेशन को बंद करने की सुविधा भी देनी चाहिए जिसमें फ़ोरग्राउंड सेवाएं चालू हों या उपयोगकर्ता ने कोई जॉब शुरू किया हो.इसके अलावा, उपयोगकर्ता को ऐसे सभी ऐप्लिकेशन भी दिखाने चाहिए जिनमें फ़ोरग्राउंड सेवाएं चालू हों. साथ ही, SDK दस्तावेज़ में बताए गए तरीके के हिसाब से, इन सेवाओं के शुरू होने से लेकर अब तक की अवधि भी दिखनी चाहिए.
  • SDK टूल के दस्तावेज़ में बताए गए उपयोगकर्ता के ऐसे ऐफ़र्डेंस में, कुछ ऐप्लिकेशन को रोकने या सूची में शामिल करने से छूट मिल सकती है.

नई ज़रूरी शर्तें लागू करना

• [8.5/H-0-2]ऐसे ऐप्लिकेशन को रोकने के लिए, उपयोगकर्ता को कोई सुविधा देनी ज़रूरी है जो फ़ोरग्राउंड सेवा या उपयोगकर्ता की ओर से शुरू की गई कोई कार्रवाई कर रहा हो.

नई ज़रूरी शर्तें खत्म करना

2.2.5. सुरक्षा मॉडल

हैंडहेल्ड डिवाइस पर लागू करने के लिए:

• [9/H-0-1] android.hardware.security.model.compatible सुविधा के बारे में एलान करना ज़रूरी है.
• [9.1/H-0-1] ऐप्लिकेशन को android.permission.PACKAGE_USAGE_STATS अनुमति की मदद से, तीसरे पक्ष के ऐप्लिकेशन के इस्तेमाल के आंकड़ों को ऐक्सेस करने की अनुमति देनी चाहिए. साथ ही, android.settings.ACTION_USAGE_ACCESS_SETTINGS इंटेंट के जवाब में, ऐसे ऐप्लिकेशन को ऐक्सेस देने या ऐक्सेस वापस लेने के लिए, उपयोगकर्ता के लिए ऐक्सेस करने का तरीका उपलब्ध कराना चाहिए.

नई ज़रूरी शर्तें लागू करना

अगर डिवाइस पर android.hardware.telephony की सुविधा काम करती है, तो:

• [9.5/H-1-1] UserManager.isHeadlessSystemUserMode को true पर सेट नहीं किया जाना चाहिए.

नई ज़रूरी शर्तों को खत्म करना

हैंडहेल्ड डिवाइस पर लागू करने के लिए:

• [9.11/H-0-2] अलग से एक्ज़ीक्यूशन एनवायरमेंट का इस्तेमाल करके, पासकोड को लागू करने के लिए, पासकोड का बैक अप लेना ज़रूरी है.
• [9.11/H-0-3] इसमें RSA, AES, ECDSA, और HMAC क्रिप्टोग्राफ़िक एल्गोरिदम और MD5, SHA1, और SHA-2 फ़ैमिली के हैश फ़ंक्शन लागू होने चाहिए. इससे, Android Keystore सिस्टम के काम करने वाले एल्गोरिदम को सही तरीके से इस्तेमाल किया जा सकता है. यह एल्गोरिदम, कोर और उसके बाद के लेवल पर चलने वाले कोड से सुरक्षित तरीके से अलग होता है. सुरक्षित आइसोलेशन की सुविधा, उन सभी संभावित तरीकों को ब्लॉक करनी चाहिए जिनकी मदद से कर्नेल या यूज़रस्पेस कोड, डीएमए के साथ-साथ आइसोलेट किए गए एनवायरमेंट की इंटरनल स्टेटस को ऐक्सेस कर सकता है. अपस्ट्रीम Android Open Source Project (AOSP), Trusty को लागू करके इस ज़रूरी शर्त को पूरा करता है. हालांकि, ARM TrustZone पर आधारित कोई दूसरा समाधान या तीसरे पक्ष की समीक्षा के बाद, हाइपरवाइजर पर आधारित सही आइसोलेशन को सुरक्षित तरीके से लागू करना, इसके विकल्प हैं.
• [9.11/H-0-4] लॉक स्क्रीन की पुष्टि, अलग से चलाए जाने वाले प्रोग्राम में करनी चाहिए. पुष्टि होने के बाद ही, पुष्टि करने के लिए इस्तेमाल की जाने वाली कुंजियों का इस्तेमाल करने की अनुमति दें. लॉक स्क्रीन के क्रेडेंशियल को इस तरह से सेव करना ज़रूरी है कि सिर्फ़ अलग-अलग इकोसिस्टम में काम करने वाले प्रोग्राम के लिए, लॉक स्क्रीन की पुष्टि की जा सके. अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट, Gatekeeper Hardware Abstraction Layer (HAL) और Trusty उपलब्ध कराता है. इनका इस्तेमाल, इस ज़रूरी शर्त को पूरा करने के लिए किया जा सकता है.
• [9.11/H-0-5] यह ज़रूरी है कि कुंजी की पुष्टि करने की सुविधा काम करे. इसमें, पुष्टि करने के लिए इस्तेमाल होने वाली साइनिंग कुंजी को सुरक्षित हार्डवेयर से सुरक्षित किया गया हो और साइनिंग की प्रोसेस को सुरक्षित हार्डवेयर में किया गया हो. पुष्टि करने के लिए इस्तेमाल होने वाली साइनिंग पासकोड को ज़रूर ज़्यादा से ज़्यादा डिवाइसों के साथ शेयर किया जाना चाहिए. इससे, इन पासकोड का इस्तेमाल डिवाइस आइडेंटिफ़ायर के तौर पर नहीं किया जा सकेगा. इस शर्त को पूरा करने का एक तरीका यह है कि जब तक किसी SKU की कम से कम 1,00,000 यूनिट का प्रॉडक्शन न हो जाए, तब तक एक ही पुष्टि करने वाली कुंजी शेयर की जाए. अगर किसी SKU की 1,00,000 से ज़्यादा यूनिट बनाई जाती हैं, तो हर 1,00,000 यूनिट के लिए, अलग-अलग कुंजी का इस्तेमाल किया जा सकता है.

ध्यान दें कि अगर किसी डिवाइस पर, Android के किसी पुराने वर्शन में पहले से ही एन्क्रिप्शन लागू है, तो उस डिवाइस को अलग से एन्क्रिप्शन करने वाले एनवायरमेंट के साथ काम करने वाले पासकोड सेव करने की सुविधा और पासकोड की पुष्टि करने की सुविधा का इस्तेमाल करने की ज़रूरत नहीं होती. हालांकि, ऐसा तब तक नहीं किया जा सकता, जब तक डिवाइस में android.hardware.fingerprint सुविधा का इस्तेमाल नहीं किया जाता. इस सुविधा के लिए, अलग से एन्क्रिप्शन करने वाले एनवायरमेंट के साथ काम करने वाले पासकोड सेव करने की सुविधा और पासकोड की पुष्टि करने की सुविधा का इस्तेमाल करना ज़रूरी होता है.

जब हैंडहेल्ड डिवाइस पर सुरक्षित लॉक स्क्रीन की सुविधा काम करती है, तो:

• [9.11/H-1-1] डिवाइस के लिए, उपयोगकर्ता को स्लीप मोड का सबसे कम टाइम आउट चुनने की अनुमति होनी चाहिए. इसका मतलब है कि डिवाइस को अनलॉक से लॉक होने में 15 सेकंड या उससे कम समय लगना चाहिए.
• [9.11/H-1-2] उपयोगकर्ता को सूचनाएं छिपाने और पुष्टि करने के सभी तरीकों को बंद करने की सुविधा देनी चाहिए. हालांकि, 9.11.1 सुरक्षित लॉक स्क्रीन में बताए गए मुख्य तरीके को बंद नहीं किया जा सकता. AOSP, लॉकडाउन मोड के तौर पर ज़रूरी शर्तें पूरी करता है.

नई ज़रूरी शर्तें लागू करना

अगर डिवाइस में सुरक्षित लॉक स्क्रीन है और एक या उससे ज़्यादा भरोसेमंद एजेंट हैं, जो TrustAgentService सिस्टम एपीआई को लागू करते हैं, तो:

• [9.11.1/H-1-1] पुष्टि करने के लिए सुझाए गए मुख्य तरीकों (जैसे, पिन, पैटर्न, पासवर्ड) में से किसी एक का इस्तेमाल करके, उपयोगकर्ता को हर 72 घंटे से ज़्यादा बार पुष्टि करने के लिए कहा जाना चाहिए.

नई ज़रूरी शर्तें खत्म करना

अगर हैंडहेल्ड डिवाइस पर एक से ज़्यादा उपयोगकर्ताओं को अनुमति दी गई है और android.hardware.telephony सुविधा फ़्लैग का एलान नहीं किया गया है, तो:

• [9.5/H-2-1] डिवाइस पर प्रतिबंधित प्रोफ़ाइलों की सुविधा काम करती हो. इस सुविधा की मदद से, डिवाइस के मालिक अन्य उपयोगकर्ताओं और उनके ऐक्सेस को मैनेज कर सकते हैं. पाबंदी वाली प्रोफ़ाइलों की मदद से, डिवाइस के मालिक, दूसरे उपयोगकर्ताओं के लिए अलग-अलग एनवायरमेंट तुरंत सेट अप कर सकते हैं. साथ ही, उन एनवायरमेंट में उपलब्ध ऐप्लिकेशन पर ज़्यादा सटीक पाबंदियां भी लगा सकते हैं.

अगर हैंडहेल्ड डिवाइस के लागू होने में कई उपयोगकर्ता शामिल हैं और android.hardware.telephony सुविधा फ़्लैग का एलान किया जाता है, तो:

• [9.5/H-3-1] यह ज़रूरी है कि यह ऐप्लिकेशन, पाबंदी वाली प्रोफ़ाइलों के साथ काम न करे. हालांकि, यह AOSP के कंट्रोल के साथ काम करना चाहिए, ताकि अन्य उपयोगकर्ताओं को वॉइस कॉल और एसएमएस ऐक्सेस करने की अनुमति दी या बंद की जा सके.

नई ज़रूरी शर्तें लागू करना

अगर हैंडहेल्ड डिवाइस के लागू होने पर UserManager.isHeadlessSystemUserMode को true पर सेट किया जाता है, तो

• [9.5/H-4-1] में, eUICC और कॉल करने की सुविधा वाले ई-सिम के लिए सहायता शामिल नहीं होनी चाहिए.
• [9.5/H-4-2] ऐप्लिकेशन में android.hardware.telephony के साथ काम करने की सुविधा का एलान नहीं किया जाना चाहिए.

नई ज़रूरी शर्तें खत्म करना

Android, System API VoiceInteractionService की मदद से, माइक्रोफ़ोन के ऐक्सेस के बारे में सूचना दिए बिना, हमेशा चालू रहने वाले हॉटवर्ड का पता लगाने की सुविधा देता है. साथ ही, माइक्रोफ़ोन या कैमरे के ऐक्सेस के बारे में सूचना दिए बिना, हमेशा चालू रहने वाली क्वेरी का पता लगाने की सुविधा भी देता है.

अगर हैंडहेल्ड डिवाइस पर, सिस्टम एपीआईHotwordDetectionService या माइक्रोफ़ोन ऐक्सेस के संकेत के बिना, हॉटवर्ड का पता लगाने के लिए कोई दूसरा तरीका काम करता है, तो:

• [9.8/H-1-1] यह पक्का करना ज़रूरी है कि बोले गए शब्दों को पहचानने वाली सेवा, डेटा को सिर्फ़ सिस्टम, ContentCaptureService या SpeechRecognizer#createOnDeviceSpeechRecognizer() की बनाई गई, डिवाइस पर बोली पहचानने वाली सेवा को भेजे.
• [9.8/H-1-2] यह पक्का करना ज़रूरी है कि बोले गए शब्दों का पता लगाने वाली सेवा, माइक से रिकॉर्ड किए गए ऑडियो डेटा या उससे मिला डेटा, सिर्फ़ HotwordDetectionService एपीआई की मदद से सिस्टम सर्वर पर भेजे. इसके अलावा, ContentCaptureService पर भेजने के लिए, ContentCaptureManager एपीआई का इस्तेमाल किया जाना चाहिए.
• [9.8/H-1-3] हार्डवेयर से ट्रिगर किए गए किसी अनुरोध के लिए, माइक से रिकॉर्ड किया गया ऑडियो 30 सेकंड से ज़्यादा का नहीं होना चाहिए. यह अनुरोध, बोले गए शब्दों का पता लगाने वाली सेवा के लिए किया जाता है.
• [9.8/H-1-4] हॉटवर्ड की पहचान करने वाली सेवा के लिए, किसी व्यक्ति के अनुरोध पर, बफ़र किए गए माइक ऑडियो को 8 सेकंड से ज़्यादा पुराना नहीं होना चाहिए.
• [9.8/H-1-5] वॉइस इंटरैक्शन सेवा या इसी तरह की इकाई को, बफ़र किया गया ऐसा माइक ऑडियो नहीं देना चाहिए जो 30 सेकंड से ज़्यादा पुराना हो.
• [9.8/H-1-6] हॉटवर्ड का पता लगाने वाली सेवा से, हर हॉटवर्ड के नतीजे के लिए 100 बाइट से ज़्यादा डेटा ट्रांसफ़र नहीं किया जाना चाहिए. HotwordAudioStream से भेजे गए ऑडियो डेटा को छोड़कर.
• [9.8/H-1-7] हर नेगेटिव हॉटवर्ड के नतीजे पर, हॉटवर्ड का पता लगाने वाली सेवा से ज़्यादा से ज़्यादा पांच बिट का डेटा भेजने की अनुमति नहीं दी जानी चाहिए.
• [9.8/H-1-8] सिस्टम सर्वर से, हॉटवर्ड की पुष्टि करने के अनुरोध पर ही, हॉटवर्ड का पता लगाने वाली सेवा से डेटा ट्रांसफ़र करने की अनुमति होनी चाहिए.
• [9.8/H-1-9] उपयोगकर्ता के इंस्टॉल किए जा सकने वाले ऐप्लिकेशन को, हॉटवर्ड का पता लगाने की सेवा देने की अनुमति नहीं दी जानी चाहिए.
• [9.8/H-1-10] हॉटवर्ड की पहचान करने वाली सेवा के ज़रिए माइक के इस्तेमाल के बारे में, यूज़र इंटरफ़ेस (यूआई) में संख्या के हिसाब से डेटा नहीं दिखना चाहिए.
• [9.8/H-1-11] सुरक्षा से जुड़े शोधकर्ताओं को जांच करने की अनुमति देने के लिए, हॉटवर्ड की पहचान करने वाली सेवा से हर ट्रांसमिशन में शामिल बाइट की संख्या को लॉग करना ज़रूरी है.
• [9.8/H-1-12] यह ज़रूरी है कि डिवाइस में डीबग मोड की सुविधा हो. इससे, हॉटवर्ड डिटेक्शन सेवा से हर ट्रांसमिशन के रॉ कॉन्टेंट को लॉग किया जा सकता है. इससे, सुरक्षा से जुड़े शोधकर्ताओं को जांच करने में मदद मिलती है.
• [9.8/H-1-14] जब वॉइस इंटरैक्शन सेवा या मिलती-जुलती इकाई को हॉटवर्ड का सही नतीजा भेजा जाता है, तो माइक्रोफ़ोन इंडिकेटर दिखाना ज़रूरी है. इस बारे में 9.8.2 सेक्शन में बताया गया है.

नई ज़रूरी शर्तें लागू करना

• [9.8/H-1-15] यह पक्का करना ज़रूरी है कि हॉटवर्ड के सही नतीजों पर दी गई ऑडियो स्ट्रीम, हॉटवर्ड डिटेक्शन सेवा से वॉइस इंटरैक्शन सेवा पर एकतरफ़ा भेजी जाती हैं.

नई ज़रूरी शर्तें खत्म करना

• [9.8/H-SR-1] हमारा सुझाव है कि किसी ऐप्लिकेशन को, बोले गए शब्दों को पहचानने की सेवा देने वाली कंपनी के तौर पर सेट करने से पहले, उपयोगकर्ताओं को इसकी सूचना दें.
• [9.8/H-SR-2] हमारा सुझाव है कि आप हॉटवर्ड की पहचान करने वाली सेवा से, बिना स्ट्रक्चर वाले डेटा को ट्रांसफ़र करने की अनुमति न दें.
• [9.8/H-SR-3] हमारा सुझाव है कि आप कम से कम हर घंटे या हर 30 हार्डवेयर-ट्रिगर इवेंट में से जो भी पहले हो, उसमें हॉटवर्ड की पहचान करने वाली सेवा को होस्ट करने की प्रोसेस को रीस्टार्ट करें.

अगर डिवाइस में कोई ऐसा ऐप्लिकेशन शामिल है जो सिस्टम एपीआईHotwordDetectionService का इस्तेमाल करता है या माइक्रोफ़ोन के इस्तेमाल के संकेत के बिना, हॉटवर्ड का पता लगाने के लिए मिलते-जुलते तरीके का इस्तेमाल करता है, तो ऐप्लिकेशन:

• [9.8/H-2-1] इस्तेमाल किए जा सकने वाले हर हॉटवर्ड वाक्यांश के लिए, उपयोगकर्ता को साफ़ तौर पर सूचना देना ज़रूरी है.
• [9.8/H-2-2] हॉटवर्ड की पहचान करने वाली सेवा की मदद से, रॉ ऑडियो डेटा या उससे मिला डेटा सेव नहीं किया जाना चाहिए.
• [9.8/H-2-3] हॉटवर्ड का पता लगाने वाली सेवा, ऑडियो डेटा, ऐसे डेटा को डिवाइस से बाहर नहीं भेजना चाहिए जिसका इस्तेमाल ऑडियो को पूरी तरह या कुछ हद तक फिर से बनाने के लिए किया जा सकता है. इसके अलावा, हॉटवर्ड से जुड़े ऑडियो कॉन्टेंट को भी डिवाइस से बाहर नहीं भेजना चाहिए. हालांकि, ContentCaptureService या डिवाइस पर बोली पहचानने की सेवा के लिए ऐसा किया जा सकता है.

नई ज़रूरी शर्तें लागू करना

अगर हैंडहेल्ड डिवाइस पर, सिस्टम एपीआईVisualQueryDetectionService या क्वेरी का पता लगाने के लिए, माइक और/या कैमरे के ऐक्सेस के संकेत के बिना कोई अन्य तरीका काम करता है, तो:

• [9.8/H-3-1] यह पक्का करना ज़रूरी है कि क्वेरी का पता लगाने वाली सेवा, सिर्फ़ सिस्टम या ContentCaptureService या डिवाइस पर बोली पहचानने की सेवा (SpeechRecognizer#createOnDeviceSpeechRecognizer() ने बनाई है) को डेटा भेज सके.
• [9.8/H-3-2] VisualQueryDetectionService के अलावा, किसी भी ऑडियो या वीडियो जानकारी को ContentCaptureService या डिवाइस पर बोली को लेख में बदलने वाली सेवा के अलावा, किसी और को भेजने की अनुमति नहीं दी जानी चाहिए.
• [9.8/H-3-3] जब डिवाइस को उपयोगकर्ता के डिजिटल असिस्टेंट ऐप्लिकेशन के साथ इंटरैक्ट करने का पता चलता है, तो उसे सिस्टम यूज़र इंटरफ़ेस (यूआई) में उपयोगकर्ता की सूचना दिखानी चाहिए.उदाहरण के लिए, कैमरे की मदद से उपयोगकर्ता की मौजूदगी का पता लगाकर.
• [9.8/H-3-4] उपयोगकर्ता की क्वेरी का पता चलने के तुरंत बाद, माइक्रोफ़ोन का इंडिकेटर दिखाना ज़रूरी है. साथ ही, यूज़र इंटरफ़ेस में उपयोगकर्ता की क्वेरी दिखानी चाहिए.
• [9.8/H-3-5] उपयोगकर्ता के इंस्टॉल किए जा सकने वाले ऐप्लिकेशन को, विज़ुअल क्वेरी का पता लगाने की सेवा देने की अनुमति नहीं दी जानी चाहिए.

नई ज़रूरी शर्तें खत्म करना

अगर हैंडहेल्ड डिवाइस पर android.hardware.microphone का इस्तेमाल किया जाता है, तो:

• [9.8.2/H-4-1] जब कोई ऐप्लिकेशन माइक्रोफ़ोन से ऑडियो डेटा ऐक्सेस कर रहा हो, तो माइक्रोफ़ोन इंडिकेटर दिखाना ज़रूरी है. हालांकि, जब माइक्रोफ़ोन को सिर्फ़ HotwordDetectionService, SOURCE_HOTWORD,ContentCaptureService या सेक्शन 9.1 में बताई गई भूमिकाओं वाले ऐप्लिकेशन ऐक्सेस करते हैं, तब ऐसा नहीं करना चाहिए. इन भूमिकाओं के लिए, सीडीडी आइडेंटिफ़ायर [C-4-X] का इस्तेमाल किया जाता है.
• [9.8.2/H-4-2] माइक्रोफ़ोन का इस्तेमाल करके, हाल ही में इस्तेमाल किए गए और चालू ऐप्लिकेशन की सूची दिखानी ज़रूरी है. यह सूची, PermissionManager.getIndicatorAppOpUsageData() से मिली जानकारी के हिसाब से होनी चाहिए. साथ ही, उन ऐप्लिकेशन से जुड़े एट्रिब्यूशन मैसेज भी दिखाए जाने चाहिए.

अगर हैंडहेल्ड डिवाइस पर android.hardware.camera.any का इस्तेमाल किया जाता है, तो:

• [9.8.2/H-5-1] जब कोई ऐप्लिकेशन कैमरे का लाइव डेटा ऐक्सेस कर रहा हो, तो कैमरा इंडिकेटर दिखाना ज़रूरी है. हालांकि, जब कैमरे को सिर्फ़ ऐसे ऐप्लिकेशन ऐक्सेस कर रहे हों जिनके पास सेक्शन 9.1 में बताई गई भूमिकाएं हैं और जिनमें सीडीडी आइडेंटिफ़ायर [C-4-X] है, तब कैमरा इंडिकेटर नहीं दिखाना चाहिए.
• [9.8.2/H-5-2] PermissionManager.getIndicatorAppOpUsageData() से मिले कैमरे के इस्तेमाल से, हाल ही में इस्तेमाल किए गए और ऐक्टिव ऐप्लिकेशन के साथ-साथ उनसे जुड़े एट्रिब्यूशन मैसेज भी दिखाने चाहिए.

2.2.6. डेवलपर टूल और विकल्पों के साथ काम करने की सुविधा

हैंडहेल्ड डिवाइस पर लागू होने वाले तरीके (* टैबलेट पर लागू नहीं):

• [6.1/H-0-1]* शेल कमांड के साथ काम करना चाहिए cmd testharness.

हैंडहेल्ड डिवाइस पर लागू होने वाले तरीके (* टैबलेट पर लागू नहीं):

• Perfetto
  • [6.1/H-0-2]* शेल उपयोगकर्ता को /system/bin/perfetto बाइनरी दिखानी चाहिए, जो cmdline के साथ काम करती हो और perfetto दस्तावेज़ के मुताबिक हो.
  • [6.1/H-0-3]* perfetto दस्तावेज़ में बताए गए स्कीमा के मुताबिक, protobuf कॉन्फ़िगरेशन को इनपुट के तौर पर स्वीकार करना, ज़रूरी है.
  • [6.1/H-0-4]* perfetto दस्तावेज़ में बताए गए स्कीमा के मुताबिक, 'perfetto' बाइनरी को आउटपुट के तौर पर protobuf ट्रेस लिखना चाहिए.
  • [6.1/H-0-5]* आपको perfetto दस्तावेज़ में बताए गए डेटा सोर्स के साथ-साथ, कम से कम एक और डेटा सोर्स, perfetto बाइनरी के ज़रिए उपलब्ध कराना होगा.
  • [6.1/H-0-6]* Perfetto ट्रैक किया गया डेमन, डिफ़ॉल्ट रूप से चालू होना चाहिए (सिस्टम प्रॉपर्टी persist.traced.enable).

2.2.7. मोबाइल डिवाइस पर वीडियो की परफ़ॉर्मेंस की क्लास

मीडिया परफ़ॉर्मेंस क्लास की परिभाषा के लिए, सेक्शन 7.11 देखें.

2.2.7.1. मीडिया

अगर android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS के लिए, हैंडहेल्ड डिवाइस के लागू होने की जानकारी android.os.Build.VERSION_CODES.T के तौर पर दिखती है, तो:

• Android 13 के सीडीडी सेक्शन 2.2.7.1 में बताई गई मीडिया से जुड़ी ज़रूरी शर्तों को पूरा करना ज़रूरी है.

नई ज़रूरी शर्तें लागू करना

अगर हाथ में पकड़े जाने वाले डिवाइस के लागू होने पर, android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS के लिए android.os.Build.VERSION_CODES.U दिखता है, तो:

• [5.1/H-1-1] CodecCapabilities.getMaxSupportedInstances() और VideoCapabilities.getSupportedPerformancePoints() तरीकों की मदद से, किसी भी कोडेक कॉम्बिनेशन में एक साथ चलाए जा सकने वाले, ज़्यादा से ज़्यादा हार्डवेयर वीडियो डिकोडर सेशन का विज्ञापन करना ज़रूरी है.
• [5.1/H-1-2] यह ज़रूरी है कि डिवाइस पर 8-बिट (एसडीआर) हार्डवेयर वीडियो डिकोडर सेशन (AVC, HEVC, VP9, AV1 या इसके बाद के वर्शन) के छह इंस्टेंस काम करते हों. साथ ही, ये किसी भी कोडेक कॉम्बिनेशन में, 1080 पिक्सल रिज़ॉल्यूशन पर 30 फ़्रेम प्रति सेकंड और 4K रिज़ॉल्यूशन पर 30 फ़्रेम प्रति सेकंड के तीन सेशन के साथ काम करते हों. AV1 कोडेक को सिर्फ़ 1080p रिज़ॉल्यूशन के साथ काम करना चाहिए. हालांकि, इसके लिए 1080p30fps पर छह इंस्टेंस के साथ काम करना ज़रूरी है.
• [5.1/H-1-3] CodecCapabilities.getMaxSupportedInstances() और VideoCapabilities.getSupportedPerformancePoints() तरीकों की मदद से, किसी भी कोडेक कॉम्बिनेशन में एक साथ चलाए जा सकने वाले, ज़्यादा से ज़्यादा हार्डवेयर वीडियो एन्कोडर सेशन का विज्ञापन करना ज़रूरी है.
• [5.1/H-1-4] यह ज़रूरी है कि डिवाइस पर 8-बिट (एसडीआर) हार्डवेयर वीडियो एन्कोडर सेशन (AVC, HEVC, VP9, AV1 या उसके बाद के वर्शन) के छह इंस्टेंस काम करते हों. साथ ही, ये इंस्टेंस किसी भी कोडेक कॉम्बिनेशन में, 1080p रिज़ॉल्यूशन पर 30 fps और 4K रिज़ॉल्यूशन पर 30fps के चार सेशन के साथ काम करते हों. AV1 कोडेक को सिर्फ़ 1080p रिज़ॉल्यूशन के साथ काम करना चाहिए. हालांकि, इसके लिए 1080p30fps पर छह इंस्टेंस के साथ काम करना ज़रूरी है.
• [5.1/H-1-5] CodecCapabilities.getMaxSupportedInstances() और VideoCapabilities.getSupportedPerformancePoints() तरीकों की मदद से, किसी भी कोडेक कॉम्बिनेशन में एक साथ चलाए जा सकने वाले, हार्डवेयर वीडियो एन्कोडर और डिकोडर सेशन की ज़्यादा से ज़्यादा संख्या का विज्ञापन करना ज़रूरी है.
• [5.1/H-1-6] यह ज़रूरी है कि डिवाइस में 8-बिट (एसडीआर) हार्डवेयर वीडियो डिकोडर और हार्डवेयर वीडियो एन्कोडर सेशन (एवीसी, एचईवीसी, VP9, AV1 या इसके बाद के वर्शन) के छह इंस्टेंस काम करते हों. ये इंस्टेंस, किसी भी कोडेक कॉम्बिनेशन में 4K@30fps रिज़ॉल्यूशन पर तीन सेशन के साथ काम करते हों. इनमें से ज़्यादा से ज़्यादा दो सेशन एन्कोडर सेशन और तीन सेशन 1080p रिज़ॉल्यूशन पर काम करते हों. AV1 कोडेक को सिर्फ़ 1080p रिज़ॉल्यूशन के साथ काम करना चाहिए. हालांकि, इसके लिए 1080p30fps पर छह इंस्टेंस के साथ काम करना ज़रूरी है.
• [5.1/H-1-19] यह ज़रूरी है कि यह डिवाइस, 4K@30fps रिज़ॉल्यूशन पर एक साथ चलने वाले किसी भी कोडेक कॉम्बिनेशन में, 10-बिट (एचडीआर) हार्डवेयर वीडियो डिकोडर और हार्डवेयर वीडियो एन्कोडर सेशन (AVC, HEVC, VP9, AV1 या उसके बाद के वर्शन) के तीन इंस्टेंस के साथ काम करे. इनमें से ज़्यादा से ज़्यादा एक एन्कोडर सेशन हो सकता है, जिसे GL सरफ़ेस की मदद से RGBA_1010102 इनपुट फ़ॉर्मैट में कॉन्फ़िगर किया जा सकता है. अगर GL प्लैटफ़ॉर्म से एन्कोड किया जा रहा है, तो एन्कोडर के ज़रिए HDR मेटाडेटा जनरेट करने की ज़रूरत नहीं है. AV1 कोडेक सेशन में सिर्फ़ 1080p रिज़ॉल्यूशन का इस्तेमाल किया जा सकता है. भले ही, ज़रूरत पड़ने पर 4K रिज़ॉल्यूशन का इस्तेमाल किया जा सकता है.
• [5.1/H-1-7] लोड होने पर, सभी हार्डवेयर वीडियो एन्कोडर के लिए, 1080 पिक्सल या उससे कम वीडियो को एन्कोड करने के सेशन के लिए, कोडेक शुरू होने में लगने वाला समय 40 मिलीसेकंड या उससे कम होना चाहिए. यहां लोड को, 1080 पिक्सल से 720 पिक्सल वाले वीडियो को एक साथ ट्रांसकोड करने वाले सेशन के तौर पर परिभाषित किया गया है. इस सेशन में, हार्डवेयर वीडियो कोडेक का इस्तेमाल किया जाता है. साथ ही, 1080 पिक्सल वाली ऑडियो-वीडियो रिकॉर्डिंग को शुरू किया जाता है. Dolby vision कोडेक के लिए, कोडेक शुरू होने में लगने वाला समय 50 मिलीसेकंड या उससे कम होना चाहिए.
• [5.1/H-1-8] लोड होने पर, सभी ऑडियो एन्कोडर के लिए 128 केबीपीएस या उससे कम बिटरेट वाले ऑडियो एन्कोडिंग सेशन के लिए, कोडेक शुरू होने में लगने वाला समय 30 एमएस या उससे कम होना चाहिए. यहां लोड को, 1080 पिक्सल से 720 पिक्सल वाले वीडियो को एक साथ ट्रांसकोड करने वाले सेशन के तौर पर परिभाषित किया गया है. इस सेशन में, हार्डवेयर वीडियो कोडेक का इस्तेमाल किया जाता है. साथ ही, 1080 पिक्सल वाली ऑडियो-वीडियो रिकॉर्डिंग को शुरू किया जाता है.
• [5.1/H-1-9] यह ज़रूरी है कि डिवाइस पर, 8-बिट (एसडीआर) और 10-बिट एचडीआर, दोनों तरह के कॉन्टेंट के लिए 1080 पिक्सल रिज़ॉल्यूशन पर 30 एफ़पीएस के साथ, किसी भी कोडेक कॉम्बिनेशन में एक साथ काम करने वाले दो सेशन के लिए, सुरक्षित हार्डवेयर वीडियो डिकोडर (एवीसी, एचईवीसी, VP9, AV1 या उसके बाद के वर्शन) की सुविधा हो.
• [5.1/H-1-10] यह ज़रूरी है कि यह डिवाइस, किसी भी कोडेक कॉम्बिनेशन में 4K रिज़ॉल्यूशन@30 fps पर चलने वाले तीन सेशन के साथ-साथ, सुरक्षित हार्डवेयर वीडियो डिकोडर सेशन के एक इंस्टेंस के साथ-साथ, तीन ऐसे सेशन के साथ काम करे जो सुरक्षित न हों (कुल चार इंस्टेंस) (AVC, HEVC, VP9, AV1 या इसके बाद के वर्शन). इनमें से एक सेशन, सुरक्षित डिकोडर सेशन और एक सेशन, 1080p रिज़ॉल्यूशन@30fps पर चलने वाला ऐसा सेशन होना चाहिए जो सुरक्षित न हो. साथ ही, ज़्यादा से ज़्यादा दो सेशन 10-बिट HDR में हो सकते हैं. AV1 कोडेक सेशन में सिर्फ़ 1080p रिज़ॉल्यूशन का इस्तेमाल किया जा सकता है. भले ही, ज़रूरत पड़ने पर 4K रिज़ॉल्यूशन का इस्तेमाल किया जा सकता है.
• [5.1/H-1-11] डिवाइस पर मौजूद हर हार्डवेयर AVC, HEVC, VP9 या AV1 डिकोडर के लिए, सुरक्षित डिकोडर की सुविधा काम करनी चाहिए.
• [5.1/H-1-12] सभी हार्डवेयर वीडियो डिकोडर के लिए, 1080 पिक्सल या उससे कम रिज़ॉल्यूशन वाले वीडियो को डिकोड करने के दौरान, कोडेक को शुरू करने में लगने वाला समय 40 मिलीसेकंड या उससे कम होना चाहिए. यहां लोड को, 1080 पिक्सल से 720 पिक्सल वाले वीडियो को एक साथ ट्रांसकोड करने वाले सेशन के तौर पर परिभाषित किया गया है. इस सेशन में, हार्डवेयर वीडियो कोडेक का इस्तेमाल किया जाता है. साथ ही, 1080 पिक्सल वाले ऑडियो-वीडियो को प्लेबैक करने की प्रोसेस शुरू की जाती है. Dolby vision कोडेक के लिए, कोडेक शुरू होने में लगने वाला समय 50 मिलीसेकंड या उससे कम होना चाहिए.
• [5.1/H-1-13] लोड होने पर, सभी ऑडियो डिकोडर के लिए 128 केबीपीएस या उससे कम बिटरेट वाले ऑडियो डिकोडिंग सेशन के लिए, कोडेक को शुरू करने में लगने वाला समय 30 मिलीसेकंड या उससे कम होना चाहिए. यहां लोड को, 1080 पिक्सल से 720 पिक्सल वाले वीडियो के लिए, एक साथ ट्रांसकोड करने वाले सेशन के तौर पर परिभाषित किया गया है. इस सेशन में, हार्डवेयर वीडियो कोडेक का इस्तेमाल किया जाता है. साथ ही, 1080 पिक्सल वाले ऑडियो-वीडियो को प्लेबैक करने की प्रोसेस शुरू की जाती है.
• [5.1/H-1-14] यह ज़रूरी है कि डिवाइस में AV1 हार्डवेयर डिकोडर Main 10, लेवल 4.1, और फ़िल्म ग्रेन की सुविधा काम करती हो.
• [5.1/H-1-15] इसमें कम से कम एक हार्डवेयर वीडियो डिकोडर होना चाहिए, जो 4K60 को सपोर्ट करता हो.
• [5.1/H-1-16] इसमें कम से कम एक ऐसा हार्डवेयर वीडियो एन्कोडर होना चाहिए जो 4K60 को सपोर्ट करता हो.
• [5.3/H-1-1] लोड के दौरान, 4K 60 fps वीडियो सेशन के लिए, 10 सेकंड में एक से ज़्यादा फ़्रेम नहीं छोड़े जाने चाहिए.इसका मतलब है कि फ़्रेम ड्रॉप 0.167 प्रतिशत से कम होना चाहिए.
• [5.3/H-1-2] 4K सेशन के लिए लोड के दौरान, 60 एफ़पीएस वाले वीडियो सेशन में वीडियो रिज़ॉल्यूशन बदलने के दौरान, 10 सेकंड में एक से ज़्यादा फ़्रेम नहीं छोड़े जाने चाहिए.
• [5.6/H-1-1] CTS पुष्टि करने वाले टैप-टू-टोन टेस्ट का इस्तेमाल करके, टैप-टू-टोन के लिए इंतज़ार का समय 80 मिलीसेकंड या उससे कम होना चाहिए.
• [5.6/H-1-2] कम से कम एक काम करने वाले डेटा पाथ पर, ऑडियो के राउंड-ट्रिप में लगने वाला समय 80 मिलीसेकंड या उससे कम होना चाहिए.
• [5.6/H-1-3] अगर 3.5 मिमी ऑडियो जैक मौजूद हैं, तो स्टीरियो आउटपुट के लिए 24-बिट ऑडियो की सुविधा होनी चाहिए. साथ ही, कम इंतज़ार और स्ट्रीमिंग कॉन्फ़िगरेशन के लिए, पूरे डेटा पाथ में यूएसबी ऑडियो की सुविधा होनी चाहिए. कम लेटेंसी वाले कॉन्फ़िगरेशन के लिए, ऐप्लिकेशन को AAudio का इस्तेमाल कम लेटेंसी वाले कॉलबैक मोड में करना चाहिए. स्ट्रीमिंग कॉन्फ़िगरेशन के लिए, ऐप्लिकेशन को Java AudioTrack का इस्तेमाल करना चाहिए. कम इंतज़ार और स्ट्रीमिंग, दोनों कॉन्फ़िगरेशन में, एचएएल आउटपुट सिंक को अपने टारगेट आउटपुट फ़ॉर्मैट के लिए, 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] यह ज़रूरी है कि डिवाइस में चार चैनल वाले यूएसबी ऑडियो डिवाइसों के साथ काम करने की सुविधा हो. डीजे कंट्रोलर, गाने की झलक दिखाने के लिए इसका इस्तेमाल करते हैं.
• [5.6/H-1-5] यह ज़रूरी है कि ऐप्लिकेशन, क्लास के मुताबिक काम करने वाले MIDI डिवाइसों के साथ काम करे और MIDI सुविधा के फ़्लैग का एलान करे.
• [5.6/H-1-9] यह कम से कम 12 चैनल मिक्सिंग के साथ काम करना चाहिए. इसका मतलब है कि 7.1.4 चैनल मास्क के साथ ऑडियो ट्रैक खोला जा सकता है और सभी चैनलों को सही तरीके से स्पेसलाइज़ या स्टीरियो में डाउनमिक्स किया जा सकता है.
• [5.6/H-SR] हमारा सुझाव है कि आप 24 चैनल मिक्सिंग की सुविधा का इस्तेमाल करें. इसके लिए, कम से कम 9.1.6 और 22.2 चैनल मास्क की सुविधा का इस्तेमाल करें.
• [5.7/H-1-2] कॉन्टेंट को डिक्रिप्ट करने के लिए, MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL के साथ इन सुविधाओं का इस्तेमाल करना ज़रूरी है.

सैंपल का कम से कम साइज़	4 एमबी
सबसैंपल की कम से कम संख्या - H264 या HEVC	32
सब-सैंपल की कम से कम संख्या - VP9	9
सब-सैंपल की कम से कम संख्या - AV1	288
सबसैंपल बफ़र का कम से कम साइज़	1 एमबी
सामान्य क्रिप्टो बफ़र का कम से कम साइज़	500 केआईबी
एक साथ चल रहे सेशन की कम से कम संख्या	30
हर सेशन के लिए कुंजियों की कम से कम संख्या	20
सभी सेशन के लिए, कुंजियों की कम से कम कुल संख्या	80
डीआरएम कुंजियों की कम से कम कुल संख्या (सभी सेशन)	6
मैसेज का साइज़	16 केआईबी
हर सेकंड डिक्रिप्ट किए गए फ़्रेम	60 FPS (फ़्रेम प्रति सेकंड)

• [5.1/H-1-17] डिवाइस में कम से कम एक ऐसा हार्डवेयर इमेज डिकोडर होना चाहिए जो AVIF के आधारभूत प्रोफ़ाइल के साथ काम करता हो.
• [5.1/H-1-18] यह AV1 एन्कोडर के साथ काम करना चाहिए, जो 30fps और 1 एमबीपीएस पर 480 पिक्सल तक का रिज़ॉल्यूशन एन्कोड कर सकता है.
• [5.12/H-1-1] ज़रूरी है [5.12/H-SR] डिवाइस पर मौजूद सभी हार्डवेयर AV1 और HEVC एन्कोडर के लिए, Feature_HdrEditing की सुविधा के साथ काम करने का सुझाव दिया जाता है.
• [5.12/H-1-2] डिवाइस पर मौजूद सभी हार्डवेयर AV1 और HEVC एन्कोडर के लिए, RGBA_1010102 कलर फ़ॉर्मैट के साथ काम करना ज़रूरी है.
• [5.12/H-1-3] 8 और 10-बिट, दोनों YUV टेक्सचर से सैंपल लेने के लिए, EXT_YUV_target एक्सटेंशन के साथ काम करने की जानकारी देना ज़रूरी है.
• [7.1.4/H-1-1] डिसप्ले प्रोसेसिंग यूनिट (डीपीयू) में कम से कम छह हार्डवेयर ओवरले होने चाहिए. इनमें से कम से कम दो ओवरले, 10-बिट वीडियो कॉन्टेंट दिखाने में सक्षम होने चाहिए.

अगर हैंडहेल्ड डिवाइस पर android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS के लिए android.os.Build.VERSION_CODES.U दिखता है और उनमें हार्डवेयर AVC या HEVC एन्कोडर के लिए सहायता शामिल है, तो:

• [5.2/H-2-1] यह ज़रूरी है कि हार्डवेयर AVC और HEVC कोडेक के लिए, वीडियो एन्कोडर रेट-डिस्टॉर्शन कर्व के हिसाब से तय की गई क्वालिटी के टारगेट को पूरा किया जाए. इस बारे में रन परफ़ॉर्मेंस क्लास 14 (PC14)-वीडियो एन्कोडिंग क्वालिटी (वीईक्यू) टेस्ट में बताया गया है.

नई ज़रूरी शर्तें खत्म करना

2.2.7.2. कैमरा

अगर android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS के लिए, हैंडहेल्ड डिवाइस के लागू होने की जानकारी android.os.Build.VERSION_CODES.T के तौर पर दिखती है, तो:

• Android 13 के सीडीडी सेक्शन 2.2.7.2 में बताई गई मीडिया से जुड़ी ज़रूरी शर्तों को पूरा करना ज़रूरी है.

नई ज़रूरी शर्तें लागू करना

अगर हाथ में पकड़े जाने वाले डिवाइस के लागू होने पर, android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS के लिए android.os.Build.VERSION_CODES.U दिखता है, तो:

• [7.5/H-1-1] डिवाइस में पीछे की तरफ़ एक मुख्य कैमरा होना चाहिए. इसका रिज़ॉल्यूशन कम से कम 12 मेगापिक्सल होना चाहिए और यह 4K@30fps पर वीडियो कैप्चर कर सकता हो. मुख्य पीछे वाला कैमरा, सबसे कम कैमरा आईडी वाला पीछे वाला कैमरा होता है.
• [7.5/H-1-2] डिवाइस में, कम से कम 6 मेगापिक्सल का मुख्य फ़्रंट कैमरा होना चाहिए. साथ ही, यह 1080 पिक्सल@30fps पर वीडियो कैप्चर करने की सुविधा भी देना चाहिए. मुख्य सामने वाला कैमरा, सबसे कम कैमरा आईडी वाला सामने वाला कैमरा होता है.
• [7.5/H-1-3] android.info.supportedHardwareLevel प्रॉपर्टी के साथ काम करना चाहिए. साथ ही, बैक प्राइमरी कैमरे के लिए FULL या इससे बेहतर और फ़्रंट प्राइमरी कैमरे के लिए LIMITED या इससे बेहतर होना चाहिए.
• [7.5/H-1-4] दोनों मुख्य कैमरों के लिए, CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME की सुविधा काम करती हो.
• [7.5/H-1-5] 1080p रिज़ॉल्यूशन के लिए, camera2 JPEG कैप्चर में लगने वाला समय 1000 900 सेकंड से कम होना चाहिए. यह समय, दोनों प्राइमरी कैमरों के लिए, CTS कैमरा की परफ़ॉर्मेंस की जांच के दौरान, रोशनी की उन स्थितियों (3000K) में मेज़र किया गया है.
• [7.5/H-1-6] कैमरा चालू होने में लगने वाला समय (कैमरा खोलने से लेकर, पहले झलक फ़्रेम तक) 500 मिलीसेकंड से कम होना चाहिए. यह समय, दोनों मुख्य कैमरों के लिए, CTS कैमरा परफ़ॉर्मेंस टेस्ट के तहत, रोशनी की आईटीएस स्थितियों (3000K) में मेज़र किया जाता है.
• [7.5/H-1-8] प्राइमरी बैक कैमरे के लिए, CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW और android.graphics.ImageFormat.RAW_SENSOR के साथ काम करना चाहिए.
• [7.5/H-1-9] डिवाइस में पीछे की ओर वाला मुख्य कैमरा होना चाहिए, जो 240 FPS पर 720 पिक्सल या 1080 पिक्सल के साथ काम करता हो.
• [7.5/H-1-10] अगर एक ही दिशा में देखने वाला अल्ट्रा-वाइड आरजीबी कैमरा है, तो मुख्य कैमरों के लिए ZOOM_RATIO की वैल्यू कम से कम 1.0 से कम होनी चाहिए.
• [7.5/H-1-11] मुख्य कैमरों पर, एक साथ सामने और पीछे की स्ट्रीमिंग की सुविधा लागू करना ज़रूरी है.
• [7.5/H-1-12] मुख्य फ़्रंट और मुख्य बैक कैमरे, दोनों के लिए CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION काम करना चाहिए.
• [7.5/H-1-13] अगर पीछे एक से ज़्यादा आरजीबी कैमरे हैं, तो मुख्य पीछे वाले कैमरे के लिए LOGICAL_MULTI_CAMERA सुविधा काम करती होनी चाहिए.
• [7.5/H-1-14] मुख्य फ़्रंट और मुख्य बैक कैमरे, दोनों के लिए STREAM_USE_CASE सुविधा काम करती होनी चाहिए.
• [7.5/H-1-15] मुख्य कैमरों के लिए, CameraX और Camera2 एक्सटेंशन, दोनों के ज़रिए बोकेह और रात मोड एक्सटेंशन की सुविधा काम करती होनी चाहिए.
• [7.5/H-1-16] प्राइमरी कैमरों के लिए, DYNAMIC_RANGE_TEN_BIT की सुविधा काम करती हो.
• [7.5/H-1-17] मुख्य कैमरों के लिए, CONTROL_SCENE_MODE_FACE_PRIORITY और चेहरे का पता लगाने की सुविधा (STATISTICS_FACE_DETECT_MODE_SIMPLE या STATISTICS_FACE_DETECT_MODE_FULL) का इस्तेमाल करना ज़रूरी है.

नई ज़रूरी शर्तें खत्म करना

2.2.7.3. हार्डवेयर

अगर हाथ में पकड़े जाने वाले डिवाइस के लागू होने पर, android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS के लिए android.os.Build.VERSION_CODES.T दिखता है, तो:

• Android 13 के सीडीडी सेक्शन 2.2.7.3 में बताई गई मीडिया से जुड़ी ज़रूरी शर्तों को पूरा करना ज़रूरी है.

नई ज़रूरी शर्तें लागू करना

अगर हाथ में पकड़े जाने वाले डिवाइस के लागू होने पर, android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS के लिए android.os.Build.VERSION_CODES.U दिखता है, तो:

• [7.1.1.1/H-2-1] स्क्रीन का रिज़ॉल्यूशन कम से कम 1080p होना चाहिए.
• [7.1.1.3/H-2-1] स्क्रीन का डीपीआई कम से कम 400 डीपीआई होना चाहिए.
• [7.1.1.3/H-3-1] डिवाइस में एचडीआर डिसप्ले होना चाहिए, जो कम से कम 1,000 निट के औसत पर काम करता हो.
• [7.6.1/H-2-1] डिवाइस में कम से कम 8 जीबी फ़िज़िकल मेमोरी होनी चाहिए.

नई ज़रूरी शर्तें खत्म करना

2.2.7.4. परफ़ॉर्मेंस

अगर हाथ में पकड़े जाने वाले डिवाइस के लागू होने पर, android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS के लिए android.os.Build.VERSION_CODES.T दिखता है, तो:

• Android 13 CDD सेक्शन 2.2.7.4 में दी गई परफ़ॉर्मेंस से जुड़ी ज़रूरी शर्तों को पूरा करना ज़रूरी है.

नई ज़रूरी शर्तें लागू करना

अगर हाथ में पकड़े जाने वाले डिवाइस के लागू होने पर, android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS के लिए android.os.Build.VERSION_CODES.U दिखता है, तो:

• [8.2/H-1-1] यह पक्का करना ज़रूरी है कि सीक्वेंशियल राइटिंग की परफ़ॉर्मेंस कम से कम 150 एमबी/सेकंड हो.
• [8.2/H-1-2] यह पक्का करना ज़रूरी है कि रैंडम राइटिंग की परफ़ॉर्मेंस कम से कम 10 एमबी/सेकंड हो.
• [8.2/H-1-3] यह पक्का करना ज़रूरी है कि सीक्वेंशियल रीड परफ़ॉर्मेंस कम से कम 250 एमबी/सेकंड हो.
• [8.2/H-1-4] यह पक्का करना ज़रूरी है कि रैंडम रीड परफ़ॉर्मेंस कम से कम 100 एमबी/सेकंड हो.
• [8.2/H-1-5] यह ज़रूरी है कि एक साथ कई फ़ाइलों को पढ़ने और लिखने की परफ़ॉर्मेंस बेहतर हो. साथ ही, पढ़ने की परफ़ॉर्मेंस, लिखने की परफ़ॉर्मेंस से दो गुनी हो और कम से कम 50 एमबी/सेकंड हो.

नई ज़रूरी शर्तों को खत्म करना

2.3. टेलिविज़न से जुड़ी ज़रूरी शर्तें

Android Television डिवाइस से, Android डिवाइस के उस वर्शन का मतलब है जो मनोरंजन के लिए इंटरफ़ेस के तौर पर काम करता है. इस डिवाइस पर, डिजिटल मीडिया, फ़िल्में, गेम, ऐप्लिकेशन, और/या लाइव टीवी देखने के लिए, उपयोगकर्ताओं को करीब 10 फ़ीट की दूरी पर बैठना पड़ता है. इसे “लेन बैक” या “10 फ़ीट यूज़र इंटरफ़ेस” भी कहा जाता है.

Android डिवाइस को टीवी के तौर पर तब ही माना जाता है, जब वह इन सभी शर्तों को पूरा करता हो:

• डिसप्ले पर रेंडर किए गए यूज़र इंटरफ़ेस को रिमोट से कंट्रोल करने की सुविधा दी गई हो. यह डिसप्ले, उपयोगकर्ता से 10 फ़ीट दूर भी हो सकता है.
• डिवाइस में एम्बेड की गई स्क्रीन डिसप्ले की डायगनल लंबाई 24 इंच से ज़्यादा हो या डिसप्ले के लिए वीजीए, एचडीएमआई, DisplayPort या वाई-फ़ाई पोर्ट जैसे वीडियो आउटपुट पोर्ट शामिल हों.

इस सेक्शन के बाकी हिस्से में दी गई अतिरिक्त ज़रूरी शर्तें, Android TV डिवाइस पर लागू होती हैं.

2.3.1. हार्डवेयर

टीवी डिवाइस पर लागू करने के लिए:

• [7.2.2/T-0-1] D-pad के साथ काम करना चाहिए.
• [7.2.3/T-0-1] होम और बैक बटन की सुविधाएं उपलब्ध कराना ज़रूरी है.
• [7.2.3/T-0-2] फ़ोरग्राउंड ऐप्लिकेशन को, बैक फ़ंक्शन (KEYCODE_BACK) के सामान्य और लंबे समय तक दबाए जाने के इवेंट, दोनों को भेजना ज़रूरी है.
• [7.2.6.1/T-0-1] गेम कंट्रोलर के लिए सहायता शामिल करना ज़रूरी है. साथ ही, android.hardware.gamepad सुविधा फ़्लैग का एलान करना ज़रूरी है.
• [7.2.7/T] डिवाइस में रिमोट कंट्रोल होना चाहिए, जिससे उपयोगकर्ता टच न करने वाले नेविगेशन और मुख्य नेविगेशन बटन के इनपुट को ऐक्सेस कर सकें.

अगर टीवी डिवाइस में 3-ऐक्सिस जाइरोस्कोप शामिल है, तो:

• [7.3.4/T-1-1] यह ज़रूरी है कि यह कम से कम 100 हर्ट्ज़ की फ़्रीक्वेंसी तक इवेंट की रिपोर्ट कर सके.
• [7.3.4/T-1-2] यह ज़रूरी है कि यह हर सेकंड 1,000 डिग्री तक ओरिएंटेशन में हुए बदलावों को मेज़र कर सके.

टीवी डिवाइस पर लागू करने के लिए:

• [7.4.3/T-0-1] डिवाइस में ब्लूटूथ और ब्लूटूथ LE की सुविधा होनी चाहिए.
• [7.6.1/T-0-1] ऐप्लिकेशन के निजी डेटा (जिसे "/data" पार्टीशन भी कहा जाता है) के लिए, कम से कम 4 जीबी का नॉन-वॉल्व्यूलेट स्टोरेज होना चाहिए.

अगर टेलिविज़न डिवाइस में, होस्ट मोड के साथ काम करने वाला यूएसबी पोर्ट शामिल है, तो:

• [7.5.3/T-1-1] इसमें, ऐसे बाहरी कैमरे के लिए सहायता शामिल होनी चाहिए जो इस यूएसबी पोर्ट से कनेक्ट होता है. हालांकि, यह ज़रूरी नहीं है कि वह हमेशा कनेक्ट रहे.

अगर टीवी डिवाइस पर 32-बिट प्रोसेसर का इस्तेमाल किया जा रहा है, तो:

• [7.6.1/T-1-1] अगर इनमें से किसी भी डेंसिटी का इस्तेमाल किया जाता है, तो kernel और userspace के लिए कम से कम 896 एमबी मेमोरी उपलब्ध होनी चाहिए:

  • छोटी/सामान्य स्क्रीन पर 400 डीपीआई या उससे ज़्यादा
  • बड़ी स्क्रीन पर xhdpi या उससे ज़्यादा
  • बहुत बड़ी स्क्रीन पर tvdpi या उससे ज़्यादा

अगर टीवी डिवाइस पर 64-बिट प्रोसेसर का इस्तेमाल किया जा रहा है, तो:

• [7.6.1/T-2-1] अगर इनमें से किसी भी डेंसिटी का इस्तेमाल किया जाता है, तो कर्नेल और यूज़रस्पेस के लिए उपलब्ध मेमोरी कम से कम 1280 एमबी होनी चाहिए:

  • छोटी/सामान्य स्क्रीन पर 400 डीपीआई या उससे ज़्यादा
  • बड़ी स्क्रीन पर xhdpi या उससे ज़्यादा
  • बहुत बड़ी स्क्रीन पर tvdpi या उससे ज़्यादा

ध्यान दें कि ऊपर दी गई "कर्नल और यूज़रस्पेस के लिए उपलब्ध मेमोरी" का मतलब, रेडियो, वीडियो वगैरह जैसे हार्डवेयर कॉम्पोनेंट के लिए पहले से तय मेमोरी के अलावा, डिवाइस में उपलब्ध मेमोरी स्पेस से है. ये कॉम्पोनेंट, डिवाइस में लागू करने के दौरान, कर्नेल के कंट्रोल में नहीं होते.

टीवी डिवाइस पर लागू करने के लिए:

• [7.8.1/T] इसमें माइक्रोफ़ोन होना चाहिए.
• [7.8.2/T-0-1] इसमें ऑडियो आउटपुट होना चाहिए और इसकी जानकारी दी गई हो android.hardware.audio.output.

2.3.2. मल्टीमीडिया

टीवी डिवाइस पर, ऑडियो को एन्कोड करने और डिकोड करने के लिए, इन फ़ॉर्मैट का इस्तेमाल किया जाना चाहिए. साथ ही, इन्हें तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराया जाना चाहिए:

• [5.1/T-0-1] MPEG-4 AAC प्रोफ़ाइल (AAC LC)
• [5.1/T-0-2] MPEG-4 HE AAC Profile (AAC+)
• [5.1/T-0-3] AAC ELD (बेहतर कम देरी वाला AAC)

टीवी डिवाइस पर, वीडियो को इन फ़ॉर्मैट में एन्कोड किया जा सकता है. साथ ही, इन्हें तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराया जा सकता है:

• [5.2/T-0-1] H.264
• [5.2/T-0-2] VP8

नई ज़रूरी शर्तें लागू करना

• [5.2/T-0-3] AV1

नई ज़रूरी शर्तें खत्म करना

टीवी डिवाइस पर लागू करने के लिए:

• [5.2.2/T-SR-1] हमारा सुझाव है कि आप 720 पिक्सल और 1080 पिक्सल रिज़ॉल्यूशन वाले वीडियो को 30 फ़्रेम प्रति सेकंड पर H.264 एन्कोडिंग के साथ इस्तेमाल करें.

टेलिविज़न डिवाइस में, वीडियो को डिकोड करने के लिए इन फ़ॉर्मैट का इस्तेमाल किया जाना चाहिए. साथ ही, इन्हें तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराना चाहिए:

• [5.3.3/T-0-1] MPEG-4 SP
• [5.3.4/T-0-2] H.264 AVC
• [5.3.5/T-0-3] H.265 HEVC
• [5.3.6/T-0-4] VP8
• [5.3.7/T-0-5] VP9
• [5.3.1/T-0-6] MPEG-2

नई ज़रूरी शर्तें लागू करना

• [5.3.2/T-0-7] AV1

नई ज़रूरी शर्तें खत्म करना

टेलिविज़न डिवाइस में, MPEG-2 को डिकोड करने की सुविधा होनी चाहिए. इस बारे में, सेक्शन 5.3.1 में बताया गया है. साथ ही, यह ज़रूरी है कि डिवाइस में स्टैंडर्ड वीडियो फ़्रेम रेट और रिज़ॉल्यूशन की सुविधा हो. इनमें ये शामिल हैं:

• [5.3.1/T-1-1] एचडी 1080 पिक्सल, 29.97 फ़्रेम प्रति सेकंड पर, मुख्य प्रोफ़ाइल के हाई लेवल के साथ.
• [5.3.1/T-1-2] एचडी 1080i, 59.94 फ़्रेम प्रति सेकंड पर, मुख्य प्रोफ़ाइल के हाई लेवल के साथ. उन्हें इंटरलेस किए गए MPEG-2 वीडियो को डिइंटरलेस करना होगा और उसे तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराना होगा.

टीवी डिवाइस में H.264 डिकोडिंग की सुविधा होनी चाहिए, जैसा कि सेक्शन 5.3.4 में बताया गया है. साथ ही, यह सुविधा स्टैंडर्ड वीडियो फ़्रेम रेट और रिज़ॉल्यूशन पर काम करनी चाहिए. इनमें ये शामिल हैं:

• [5.3.4/T-1-1] बेसलाइन प्रोफ़ाइल के साथ, 60 फ़्रेम प्रति सेकंड पर एचडी 1080p
• [5.3.4/T-1-2] मुख्य प्रोफ़ाइल के साथ 60 फ़्रेम प्रति सेकंड पर एचडी 1080p
• [5.3.4/T-1-3] हाई प्रोफ़ाइल लेवल 4.2 के साथ, 60 फ़्रेम प्रति सेकंड पर एचडी 1080 पिक्सल

H.265 हार्डवेयर डीकोडर वाले टेलिविज़न डिवाइसों में, H.265 डिकोडिंग की सुविधा काम करनी चाहिए. इस बारे में, सेक्शन 5.3.5 में बताया गया है. साथ ही, यह सुविधा स्टैंडर्ड वीडियो फ़्रेम रेट और रिज़ॉल्यूशन पर काम करनी चाहिए. इनमें ये शामिल हैं:

• [5.3.5/T-1-1] मुख्य प्रोफ़ाइल लेवल 4.1 के साथ, 60 फ़्रेम प्रति सेकंड पर एचडी 1080p

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

• [5.3.5/T-2-1] यह ज़रूरी है कि डिवाइस, Main10 लेवल 5 के मुख्य टीयर की प्रोफ़ाइल के साथ, 60 फ़्रेम प्रति सेकंड पर यूएचडी डिकोडिंग प्रोफ़ाइल के साथ काम करे

टीवी डिवाइस पर VP8 डिकोडिंग की सुविधा काम करनी चाहिए. इस बारे में ज़्यादा जानकारी, सेक्शन 5.3.6 में दी गई है. साथ ही, यह सुविधा इन स्टैंडर्ड वीडियो फ़्रेम रेट और रिज़ॉल्यूशन पर काम करनी चाहिए:

• [5.3.6/T-1-1] 60 फ़्रेम प्रति सेकंड पर एचडी 1080 पिक्सल की डिकोडिंग प्रोफ़ाइल

VP9 हार्डवेयर डिकोडर वाले टीवी डिवाइसों में, VP9 डिकोडिंग की सुविधा काम करनी चाहिए. इस बारे में सेक्शन 5.3.7 में बताया गया है. यह सुविधा, स्टैंडर्ड वीडियो फ़्रेम रेट और रिज़ॉल्यूशन पर काम करनी चाहिए. साथ ही, यह सुविधा इन रिज़ॉल्यूशन तक काम करनी चाहिए:

• [5.3.7/T-1-1] प्रोफ़ाइल 0 (8 बिट कलर डेप्थ) के साथ, 60 फ़्रेम प्रति सेकंड पर एचडी 1080 पिक्सल

अगर टीवी डिवाइस में VP9 हार्डवेयर डिकोडर का इस्तेमाल किया गया है और वे VP9 डिकोडिंग और यूएचडी डिकोडिंग प्रोफ़ाइल के साथ काम करते हैं, तो:

• [5.3.7/T-2-1] यह ज़रूरी है कि डिवाइस, प्रोफ़ाइल 0 (8 बिट कलर डेप्थ) के साथ 60 फ़्रेम प्रति सेकंड पर, यूएचडी डिकोडिंग प्रोफ़ाइल के साथ काम करे.
• [5.3.7/T-SR1] हमारा सुझाव है कि आप प्रोफ़ाइल 2 (10 बिट कलर डेप्थ) के साथ, 60 फ़्रेम प्रति सेकंड पर यूएचडी डिकोडिंग प्रोफ़ाइल का इस्तेमाल करें.

टीवी डिवाइस पर लागू करने के लिए:

• [5.5/T-0-1] इसमें सिस्टम के मुख्य वॉल्यूम और काम करने वाले आउटपुट पर डिजिटल ऑडियो आउटपुट वॉल्यूम कम करने की सुविधा शामिल होनी चाहिए. हालांकि, यह सुविधा कंप्रेस किए गए ऑडियो पासथ्रू आउटपुट के लिए नहीं होनी चाहिए. कंप्रेस किए गए ऑडियो पासथ्रू आउटपुट में, डिवाइस पर ऑडियो को डिकोड नहीं किया जाता.

अगर टीवी डिवाइस में डिसप्ले पहले से मौजूद नहीं है, लेकिन एचडीएमआई के ज़रिए कनेक्ट किए गए किसी बाहरी डिसप्ले के साथ काम करता है, तो:

• [5.8/T-0-1] HDMI आउटपुट मोड को, चुने गए पिक्सल फ़ॉर्मैट के लिए सबसे ज़्यादा रिज़ॉल्यूशन पर सेट करना ज़रूरी है. यह फ़ॉर्मैट, बाहरी डिसप्ले के लिए 50Hz या 60Hz रिफ़्रेश रेट के साथ काम करता है. यह रिफ़्रेश रेट, डिवाइस को बेचे जाने वाले इलाके के वीडियो रिफ़्रेश रेट पर निर्भर करता है. HDMI आउटपुट मोड को सेट करना ज़रूरी है, ताकि 50Hz या 60Hz रिफ़्रेश रेट के साथ काम करने वाला ज़्यादा से ज़्यादा रिज़ॉल्यूशन चुना जा सके.
• [5.8/T-SR-1] हमारा सुझाव है कि उपयोगकर्ता के लिए, एचडीएमआई रीफ़्रेश रेट चुनने का विकल्प उपलब्ध कराएं.
• [5.8] डिवाइस को जिस देश/इलाके में बेचा जाता है वहां के वीडियो रीफ़्रेश रेट के हिसाब से, HDMI आउटपुट मोड के रीफ़्रेश रेट को 50Hz या 60Hz पर सेट करना चाहिए.

अगर टीवी डिवाइस में डिसप्ले पहले से मौजूद नहीं है, लेकिन एचडीएमआई के ज़रिए कनेक्ट किए गए किसी बाहरी डिसप्ले के साथ काम करता है, तो:

• [5.8/T-1-1] यह HDCP 2.2 के साथ काम करना चाहिए.

अगर टीवी डिवाइस में यूएचडी डिकोडिंग की सुविधा नहीं है, लेकिन एचडीएमआई के ज़रिए कनेक्ट किए गए बाहरी डिसप्ले की सुविधा है, तो:

• [5.8/T-2-1] यह HDCP 1.4 के साथ काम करना चाहिए

2.3.3. सॉफ़्टवेयर

टीवी डिवाइस पर लागू करने के लिए:

• [3/T-0-1] android.software.leanback और android.hardware.type.television सुविधाओं के बारे में ज़रूर बताएं.
• [3.2.3.1/T-0-1] यहां दिए गए ऐप्लिकेशन इंटेंट के मुताबिक तय किए गए सभी सार्वजनिक इंटेंट फ़िल्टर पैटर्न के लिए, इंटेंट हैंडलर के साथ एक या एक से ज़्यादा ऐप्लिकेशन या सेवा कॉम्पोनेंट को पहले से लोड करना ज़रूरी है.
• [3.4.1/T-0-1] android.webkit.Webview एपीआई को पूरी तरह से लागू करना ज़रूरी है.

अगर Android Television डिवाइस पर लॉक स्क्रीन की सुविधा काम करती है,तो:

• [3.8.10/T-1-1] ऐप्लिकेशन को Lock screen पर सूचनाएं दिखानी चाहिए. इनमें मीडिया सूचना टेंप्लेट भी शामिल है.

टीवी डिवाइस पर लागू करने के लिए:

• [3.8.14/T-SR-1] हमारा सुझाव है कि आप मल्टी-विंडो में पिक्चर में पिक्चर (पीआईपी) मोड का इस्तेमाल करें.
• [3.10/T-0-1] ऐप्लिकेशन में, तीसरे पक्ष की सुलभता सेवाओं के साथ काम करने की सुविधा होनी चाहिए.
• [3.10/T-SR-1] हमारा सुझाव है कि डिवाइस पर सुलभता सेवाओं को पहले से लोड करें. ये सेवाएं, TalkBack के ओपन सोर्स प्रोजेक्ट में बताई गई, Switch Access और TalkBack (पहले से इंस्टॉल किए गए टेक्स्ट-टू-स्पीच इंजन के साथ काम करने वाली भाषाओं के लिए) जैसी सुलभता सेवाओं के बराबर या उनसे बेहतर होनी चाहिए.

अगर टेलिविज़न डिवाइस पर लागू की गई सुविधा के बारे में android.hardware.audio.output की शिकायत की जाती है, तो:

• [3.11/T-SR-1] हमारा सुझाव है कि आप डिवाइस पर उपलब्ध भाषाओं के साथ काम करने वाला TTS इंजन शामिल करें.
• [3.11/T-1-1] तीसरे पक्ष के टीटीएस इंजन को इंस्टॉल करने की सुविधा होनी चाहिए.

टीवी डिवाइस पर लागू करने के लिए:

• [3.12/T-0-1] यह ज़रूरी है कि यह टीवी इनपुट फ़्रेमवर्क के साथ काम करे.

2.3.4. परफ़ॉर्मेंस और पावर

• [8.1/T-0-1] फ़्रेम के इंतज़ार का समय एक जैसा होना. फ़्रेम रेट में उतार-चढ़ाव या फ़्रेम रेंडर होने में लगने वाला समय, एक सेकंड में पांच फ़्रेम से ज़्यादा नहीं होना चाहिए. साथ ही, यह एक सेकंड में एक फ़्रेम से कम होना चाहिए.
• [8.2/T-0-1] यह पक्का करना ज़रूरी है कि क्रम से लिखने की परफ़ॉर्मेंस कम से कम 5 एमबी/सेकंड हो.
• [8.2/T-0-2] यह पक्का करना ज़रूरी है कि रैंडम राइटिंग की परफ़ॉर्मेंस कम से कम 0.5 एमबी/सेकंड हो.
• [8.2/T-0-3] यह पक्का करना ज़रूरी है कि क्रम से पढ़ने की परफ़ॉर्मेंस कम से कम 15 एमबी/सेकंड हो.
• [8.2/T-0-4] यह पक्का करना ज़रूरी है कि रैंडम रीड की परफ़ॉर्मेंस कम से कम 3.5 एमबी/सेकंड हो.

अगर टीवी डिवाइस में, AOSP में शामिल डिवाइस की पावर मैनेजमेंट को बेहतर बनाने वाली सुविधाएं शामिल हैं या AOSP में शामिल सुविधाओं को बढ़ाया गया है, तो:

• [8.3/T-1-1] बैटरी सेवर मोड को चालू और बंद करने के लिए, उपयोगकर्ता को आसानी से ऐक्सेस करने की सुविधा देना ज़रूरी है.

अगर टीवी डिवाइस में बैटरी नहीं है, तो:

• [8.3/T-1-2] डिवाइस को बैटरी रहित डिवाइस के तौर पर रजिस्टर करना ज़रूरी है, जैसा कि बैटरी रहित डिवाइसों के साथ काम करने की सुविधा में बताया गया है.

अगर टीवी डिवाइस में बैटरी है, तो:

• [8.3/T-1-3] ऐप्लिकेशन स्टैंडबाय और Doze पावर-सेविंग मोड से छूट पाने वाले सभी ऐप्लिकेशन दिखाने के लिए, उपयोगकर्ता को सुविधा देना ज़रूरी है.

टीवी डिवाइस पर लागू करने के लिए:

• [8.4/T-0-1] हर कॉम्पोनेंट के लिए, बिजली की खपत की प्रोफ़ाइल देना ज़रूरी है. इससे हर हार्डवेयर कॉम्पोनेंट के लिए, बिजली की खपत की वैल्यू और समय के साथ कॉम्पोनेंट की वजह से बैटरी की खपत के अनुमान के बारे में पता चलता है. इस बारे में Android Open Source Project की साइट पर जानकारी दी गई है.
• [8.4/T-0-2] बिजली की खपत की सभी वैल्यू को मिलीऐंपियर घंटे (mAh) में रिपोर्ट करना ज़रूरी है.
• [8.4/T-0-3] हर प्रोसेस के यूआईडी के हिसाब से, सीपीयू की बिजली की खपत की जानकारी देना ज़रूरी है. Android ओपन सोर्स प्रोजेक्ट, uid_cputime कर्नेल मॉड्यूल लागू करने की ज़रूरी शर्तें पूरी करता है.
• [8.4/T] अगर किसी ऐप्लिकेशन के लिए, हार्डवेयर कॉम्पोनेंट के पावर इस्तेमाल को एट्रिब्यूट नहीं किया जा सकता, तो इसे हार्डवेयर कॉम्पोनेंट को एट्रिब्यूट किया जाना चाहिए.
• [8.4/T-0-4] ऐप्लिकेशन डेवलपर को, बिजली की खपत की जानकारी adb shell dumpsys batterystats शेल कमांड के ज़रिए उपलब्ध कराना ज़रूरी है.

2.3.5. सुरक्षा मॉडल

टीवी डिवाइस पर लागू करने के लिए:

• [9/T-0-1] android.hardware.security.model.compatible सुविधा का एलान करना ज़रूरी है.
• [9.11/T-0-1] अलग से एक्ज़ीक्यूशन एनवायरमेंट का इस्तेमाल करके, पासकोड को लागू करने के लिए बैक अप लेना ज़रूरी है.
• [9.11/T-0-2] इसमें आरएसए, एईएस, ईसीडीएसए, और एचएमएससी क्रिप्टोग्राफ़िक एल्गोरिदम और MD5, SHA1, और SHA-2 फ़ैमिली के हैश फ़ंक्शन लागू होने चाहिए. इससे, Android Keystore सिस्टम के काम करने वाले एल्गोरिदम को सही तरीके से काम करने में मदद मिलती है. यह एल्गोरिदम, कोर और उसके बाद के लेवल पर चलने वाले कोड से सुरक्षित तरीके से अलग होता है. सुरक्षित आइसोलेशन की सुविधा, उन सभी संभावित तरीकों को ब्लॉक करनी चाहिए जिनकी मदद से कर्नेल या यूज़रस्पेस कोड, डीएमए के साथ-साथ आइसोलेट किए गए एनवायरमेंट की इंटरनल स्टेटस को ऐक्सेस कर सकता है. अपस्ट्रीम Android Open Source Project (AOSP), Trusty को लागू करके इस ज़रूरी शर्त को पूरा करता है. हालांकि, ARM TrustZone पर आधारित कोई दूसरा समाधान या तीसरे पक्ष की समीक्षा के बाद, हाइपरवाइजर पर आधारित सही आइसोलेशन को सुरक्षित तरीके से लागू करना, इसके विकल्प हैं.
• [9.11/T-0-3] लॉक स्क्रीन की पुष्टि, अलग से चलाए जाने वाले प्रोग्राम में करनी चाहिए. पुष्टि होने के बाद ही, पुष्टि करने के लिए इस्तेमाल की जाने वाली कुंजियों का इस्तेमाल किया जा सकता है. लॉक स्क्रीन के क्रेडेंशियल को इस तरह से सेव करना ज़रूरी है कि सिर्फ़ अलग-अलग इकोसिस्टम में काम करने वाले प्रोग्राम के लिए, लॉक स्क्रीन की पुष्टि की जा सके. अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट, Gatekeeper Hardware Abstraction Layer (HAL) और Trusty उपलब्ध कराता है. इनका इस्तेमाल, इस ज़रूरी शर्त को पूरा करने के लिए किया जा सकता है.
• [9.11/T-0-4] यह ज़रूरी है कि कुंजी की पुष्टि करने की सुविधा काम करे. इसमें, पुष्टि करने के लिए इस्तेमाल होने वाली साइनिंग कुंजी को सुरक्षित हार्डवेयर से सुरक्षित किया गया हो और साइनिंग की प्रोसेस को सुरक्षित हार्डवेयर में किया गया हो. पुष्टि करने के लिए इस्तेमाल होने वाली साइनिंग पासकोड को ज़रूर ज़्यादा से ज़्यादा डिवाइसों के साथ शेयर किया जाना चाहिए. इससे, इन पासकोड का इस्तेमाल डिवाइस आइडेंटिफ़ायर के तौर पर नहीं किया जा सकेगा. इस शर्त को पूरा करने का एक तरीका यह है कि जब तक किसी SKU की कम से कम 1,00,000 यूनिट का प्रॉडक्शन न हो जाए, तब तक एक ही पुष्टि करने वाली कुंजी शेयर की जाए. अगर किसी SKU की 1,00,000 से ज़्यादा यूनिट बनाई जाती हैं, तो हर 1,00,000 यूनिट के लिए, अलग-अलग कुंजी का इस्तेमाल किया जा सकता है.

ध्यान दें कि अगर किसी डिवाइस पर, Android के किसी पुराने वर्शन में पहले से ही एन्क्रिप्शन लागू है, तो उस डिवाइस को अलग से एन्क्रिप्शन करने वाले एनवायरमेंट के साथ काम करने वाले पासकोड सेव करने की सुविधा और पासकोड की पुष्टि करने की सुविधा का इस्तेमाल करने की ज़रूरत नहीं होती. हालांकि, ऐसा तब तक नहीं किया जा सकता, जब तक डिवाइस में android.hardware.fingerprint सुविधा का इस्तेमाल नहीं किया जाता. इस सुविधा के लिए, अलग से एन्क्रिप्शन करने वाले एनवायरमेंट के साथ काम करने वाले पासकोड सेव करने की सुविधा और पासकोड की पुष्टि करने की सुविधा का इस्तेमाल करना ज़रूरी होता है.

अगर टीवी डिवाइस पर सुरक्षित लॉक स्क्रीन की सुविधा काम करती है, तो:

• [9.11/T-1-1] डिवाइस को अनलॉक से लॉक होने में लगने वाले समय के लिए, उपयोगकर्ता को स्लीप मोड का टाइम आउट चुनने की अनुमति होनी चाहिए. यह टाइम आउट 15 सेकंड या उससे कम होना चाहिए.

अगर टेलिविज़न डिवाइस के लागू होने की प्रोसेस में कई उपयोगकर्ता शामिल हैं और android.hardware.telephony सुविधा फ़्लैग का एलान नहीं किया गया है, तो:

• [9.5/T-2-1] डिवाइस पर प्रतिबंधित प्रोफ़ाइलों का इस्तेमाल किया जा सकता हो. इस सुविधा की मदद से, डिवाइस के मालिक अतिरिक्त उपयोगकर्ताओं और उनके ऐक्सेस को मैनेज कर सकते हैं. पाबंदी वाली प्रोफ़ाइलों की मदद से, डिवाइस के मालिक, दूसरे उपयोगकर्ताओं के लिए अलग-अलग एनवायरमेंट तुरंत सेट अप कर सकते हैं. साथ ही, उन एनवायरमेंट में उपलब्ध ऐप्लिकेशन पर ज़्यादा सटीक पाबंदियां भी लगा सकते हैं.

अगर टेलिविज़न डिवाइस के लागू होने की प्रोसेस में एक से ज़्यादा उपयोगकर्ता शामिल हैं और android.hardware.telephony सुविधा फ़्लैग का एलान किया जाता है, तो:

• [9.5/T-3-1] यह ज़रूरी है कि यह ऐप्लिकेशन, पाबंदी वाली प्रोफ़ाइलों के साथ काम न करे. हालांकि, यह AOSP के कंट्रोल के साथ काम करना चाहिए, ताकि अन्य उपयोगकर्ताओं को वॉइस कॉल और एसएमएस ऐक्सेस करने की अनुमति दी या बंद की जा सके.

अगर टीवी डिवाइस पर android.hardware.microphone लागू किया जाता है, तो:

• [9.8.2/T-4-1] जब कोई ऐप्लिकेशन माइक्रोफ़ोन से ऑडियो डेटा ऐक्सेस कर रहा हो, तो माइक्रोफ़ोन इंडिकेटर दिखाना ज़रूरी है.हालांकि, जब माइक्रोफ़ोन को सिर्फ़ HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService या सीडीडी आइडेंटिफ़ायर C-3-X वाली अनुमतियों वाले ऐप्लिकेशन ऐक्सेस करते हैं, तब ऐसा नहीं करना चाहिए.
• [9.8.2/T-4-2] सिस्टम के उन ऐप्लिकेशन के लिए माइक्रोफ़ोन इंडिकेटर को नहीं छिपाना चाहिए जिनमें यूज़र इंटरफ़ेस दिखते हैं या उपयोगकर्ता सीधे तौर पर इंटरैक्ट करते हैं.

अगर टीवी डिवाइस पर android.hardware.camera.any लागू किया जाता है, तो:

• [9.8.2/T-5-1] जब कोई ऐप्लिकेशन कैमरे का लाइव डेटा ऐक्सेस कर रहा हो, तो कैमरा इंडिकेटर दिखाना ज़रूरी है.हालांकि, जब कैमरे को सिर्फ़ उन ऐप्लिकेशन के ज़रिए ऐक्सेस किया जा रहा हो जिनके पास सीडीडी आइडेंटिफ़ायर [C-3-X] वाली अनुमतियां हैं, तो कैमरा इंडिकेटर नहीं दिखाना चाहिए.
• [9.8.2/T-5-2] सिस्टम ऐप्लिकेशन के लिए, कैमरे के इंडिकेटर को नहीं छिपाना चाहिए. ऐसा उन ऐप्लिकेशन के लिए करना ज़रूरी है जिनमें उपयोगकर्ता इंटरफ़ेस दिखते हैं या उपयोगकर्ता सीधे तौर पर इंटरैक्ट करते हैं.

2.3.6. डेवलपर टूल और विकल्पों के साथ काम करने की सुविधा

टीवी डिवाइस पर लागू करने के लिए:

• Perfetto
  • [6.1/T-0-1] शेल उपयोगकर्ता को /system/bin/perfetto बाइनरी दिखानी चाहिए, जो cmdline के साथ काम करती हो और perfetto दस्तावेज़ के मुताबिक हो.
  • [6.1/T-0-2] perfetto दस्तावेज़ में बताए गए स्कीमा के मुताबिक, protobuf कॉन्फ़िगरेशन को इनपुट के तौर पर स्वीकार करना ज़रूरी है.
  • [6.1/T-0-3] perfetto दस्तावेज़ में बताए गए स्कीमा के मुताबिक, protobuf ट्रैक को आउटपुट के तौर पर लिखने के लिए, यह ज़रूरी है कि perfetto बाइनरी का इस्तेमाल किया जाए.
  • [6.1/T-0-4] perfetto दस्तावेज़ में बताए गए कम से कम डेटा सोर्स, perfetto बाइनरी के ज़रिए उपलब्ध कराने होंगे.

2.4. स्मार्टवॉच से जुड़ी ज़रूरी शर्तें

Android Watch डिवाइस से, ऐसे Android डिवाइस का मतलब है जिसे पहना जा सकता है. जैसे, कलाई पर पहना जाने वाला स्मार्टवॉच.

Android डिवाइस को स्मार्टवॉच के तौर पर तब ही माना जाता है, जब वह इन सभी शर्तों को पूरा करता हो:

• स्क्रीन का डायगनल 1.1 से 2.5 इंच के बीच होना चाहिए.
• शरीर पर पहने जाने के लिए डिवाइस में कोई सुविधा हो.

इस सेक्शन के बाकी हिस्से में दी गई अतिरिक्त ज़रूरी शर्तें, Android Watch डिवाइस पर लागू होती हैं.

2.4.1. हार्डवेयर

डिवाइस पर लागू करने के तरीके देखें:

• [7.1.1.1/W-0-1] डिवाइस की स्क्रीन का डायगनल साइज़ 1.1 से 2.5 इंच के बीच होना चाहिए.

• [7.2.3/W-0-1] उपयोगकर्ता के लिए होम फ़ंक्शन और UI_MODE_TYPE_WATCH में होने पर, बैक फ़ंक्शन उपलब्ध होना चाहिए.

• [7.2.4/W-0-1] टचस्क्रीन इनपुट की सुविधा होनी चाहिए.

• [7.3.1/W-SR-1] हमारा सुझाव है कि आप तीन ऐक्सिस वाला ऐक्सीलेरोमीटर शामिल करें.

अगर स्मार्टवॉच डिवाइस में GPS/GNSS रिसीवर शामिल है और android.hardware.location.gps सुविधा के फ़्लैग के ज़रिए ऐप्लिकेशन को इसकी जानकारी दी जाती है, तो:

• [7.3.3/W-1-1] जीएनएसएस से मिली जानकारी मिलने के तुरंत बाद, उसे रिपोर्ट करना ज़रूरी है. भले ही, जीपीएस/जीएनएसएस से कैलकुलेट की गई जगह की जानकारी अब तक रिपोर्ट न की गई हो.
• [7.3.3/W-1-2] GNSS स्यूडोरेंज और स्यूडोरेंज रेट की रिपोर्ट देना ज़रूरी है. ये रेट, खुले आसमान में जगह की जानकारी तय करने के बाद, स्थिर रहने या 0.2 मीटर प्रति सेकंड स्क्वेयर से कम की रफ़्तार से चलने पर, कम से कम 95% समय तक जगह की जानकारी और रफ़्तार का हिसाब लगाने के लिए 20 मीटर और 0.2 मीटर प्रति सेकंड के अंदर होती है.

अगर स्मार्टवॉच में 3-ऐक्सिस जाइरोस्कोप शामिल है, तो:

• [7.3.4/W-2-1] यह ज़रूरी है कि डिवाइस, हर सेकंड में 1,000 डिग्री तक के ओरिएंटेशन में हुए बदलावों को मेज़र कर सके.

डिवाइस पर लागू करने के तरीके देखें:

• [7.4.3/W-0-1] डिवाइस में ब्लूटूथ की सुविधा होनी चाहिए.

• [7.6.1/W-0-1] ऐप्लिकेशन के निजी डेटा (जिसे "/data" पार्टीशन भी कहा जाता है) के लिए, कम से कम 1 जीबी का नॉन-वॉल्व्यूस्ट स्टोरेज होना चाहिए.

• [7.6.1/W-0-2] कम से कम 416 एमबी मेमोरी, कर्नेल और यूज़रस्पेस के लिए उपलब्ध होनी चाहिए.

• [7.8.1/W-0-1] इसमें माइक्रोफ़ोन होना ज़रूरी है.

• [7.8.2/W] में ऑडियो आउटपुट हो सकता है.

2.4.2. मल्टीमीडिया

कोई अन्य ज़रूरी शर्त नहीं.

2.4.3. सॉफ़्टवेयर

डिवाइस पर लागू करने के तरीके देखें:

• [3/W-0-1] इस सुविधा के बारे में ज़रूर बताएं android.hardware.type.watch.
• [3/W-0-2] uiMode = UI_MODE_TYPE_WATCH के साथ काम करना चाहिए.
• [3.2.3.1/W-0-1] यहां दिए गए ऐप्लिकेशन इंटेंट के हिसाब से तय किए गए सभी सार्वजनिक इंटेंट फ़िल्टर पैटर्न के लिए, इंटेंट हैंडलर के साथ एक या उससे ज़्यादा ऐप्लिकेशन या सेवा कॉम्पोनेंट को पहले से लोड करना ज़रूरी है.

डिवाइस पर लागू करने के तरीके देखें:

• [3.8.4/W-SR-1] हमारा सुझाव है कि Assist ऐक्शन को मैनेज करने के लिए, डिवाइस पर कोई सहायक लागू करें.

android.hardware.audio.output सुविधा फ़्लैग का एलान करने वाले डिवाइस इंप्लीमेंटेशन देखें:

• [3.10/W-1-1] ऐप्लिकेशन में, तीसरे पक्ष की सुलभता सेवाओं के साथ काम करने की सुविधा होनी चाहिए.
• [3.10/W-SR-1] हमारा सुझाव है कि डिवाइस पर सुलभता सेवाओं को पहले से लोड करें. ये सेवाएं, TalkBack के ओपन सोर्स प्रोजेक्ट में बताई गई, Switch Access और TalkBack (पहले से इंस्टॉल किए गए टेक्स्ट-टू-स्पीच इंजन के साथ काम करने वाली भाषाओं के लिए) की सुलभता सेवाओं के बराबर या उनसे बेहतर होनी चाहिए.

अगर स्मार्टवॉच डिवाइस में android.hardware.audio.output सुविधा लागू की गई है, तो:

• [3.11/W-SR-1] हमारा सुझाव है कि आप डिवाइस पर उपलब्ध भाषाओं के साथ काम करने वाला TTS इंजन शामिल करें.

• [3.11/W-0-1] तीसरे पक्ष के टीटीएस इंजन को इंस्टॉल करने की सुविधा होनी चाहिए.

2.4.4. परफ़ॉर्मेंस और पावर

अगर स्मार्टवॉच डिवाइस में, डिवाइस की बैटरी मैनेजमेंट को बेहतर बनाने के लिए AOSP में शामिल सुविधाएं शामिल की गई हैं या AOSP में शामिल सुविधाओं को बढ़ाया गया है, तो:

• [8.3/W-SR-1] हमारा सुझाव है कि आप उपयोगकर्ता को उन सभी ऐप्लिकेशन को दिखाने की सुविधा दें जिन्हें ऐप्लिकेशन स्टैंडबाय और बिजली बचाने वाले डोज़ मोड से छूट मिली है.
• [8.3/W-SR-2] हमारा सुझाव है कि आप उपयोगकर्ता को बैटरी सेवर की सुविधा चालू और बंद करने का विकल्प दें.

डिवाइस पर लागू करने के तरीके देखें:

• [8.4/W-0-1] हर कॉम्पोनेंट के लिए, बिजली की खपत की प्रोफ़ाइल देना ज़रूरी है. इससे हर हार्डवेयर कॉम्पोनेंट के लिए, बिजली की खपत की वैल्यू और समय के साथ कॉम्पोनेंट की वजह से बैटरी की खपत के अनुमान की जानकारी मिलती है. इस बारे में Android Open Source Project की साइट पर जानकारी दी गई है.
• [8.4/W-0-2] बिजली की खपत की सभी वैल्यू को मिलीऐंपियर घंटे (mAh) में रिपोर्ट करना ज़रूरी है.
• [8.4/W-0-3] हर प्रोसेस के यूआईडी के हिसाब से, सीपीयू की बिजली की खपत की जानकारी देना ज़रूरी है. Android ओपन सोर्स प्रोजेक्ट, uid_cputime कर्नेल मॉड्यूल लागू करने की ज़रूरी शर्तें पूरी करता है.
• [8.4/W-0-4] ऐप्लिकेशन डेवलपर को, बिजली की खपत की जानकारी adb shell dumpsys batterystats शेल कमांड के ज़रिए उपलब्ध कराना ज़रूरी है.
• अगर हार्डवेयर कॉम्पोनेंट के बिजली के इस्तेमाल को किसी ऐप्लिकेशन के लिए एट्रिब्यूट नहीं किया जा सकता, तो [8.4/W] को हार्डवेयर कॉम्पोनेंट के लिए एट्रिब्यूट किया जाना चाहिए.

2.4.5. सुरक्षा मॉडल

डिवाइस पर लागू करने के तरीके देखें:

• [9/W-0-1] android.hardware.security.model.compatible सुविधा के बारे में एलान करना ज़रूरी है.

अगर Watch डिवाइस पर एक से ज़्यादा उपयोगकर्ताओं को ऐक्सेस दिया गया है और android.hardware.telephony सुविधा फ़्लैग का एलान नहीं किया गया है, तो:

• [9.5/W-1-1] डिवाइस पर प्रतिबंधित प्रोफ़ाइलों की सुविधा काम करती हो. इस सुविधा की मदद से, डिवाइस के मालिक अन्य उपयोगकर्ताओं और उनके ऐक्सेस को मैनेज कर सकते हैं. पाबंदी वाली प्रोफ़ाइलों की मदद से, डिवाइस के मालिक, दूसरे उपयोगकर्ताओं के लिए अलग-अलग एनवायरमेंट तुरंत सेट अप कर सकते हैं. साथ ही, उन एनवायरमेंट में उपलब्ध ऐप्लिकेशन पर ज़्यादा सटीक पाबंदियां भी लगा सकते हैं.

अगर Watch डिवाइस पर एक से ज़्यादा उपयोगकर्ताओं को ऐप्लिकेशन इस्तेमाल करने की अनुमति दी गई है और android.hardware.telephony सुविधा फ़्लैग का एलान किया गया है, तो:

• [9.5/W-2-1] यह ज़रूरी है कि यह ऐप्लिकेशन, पाबंदी वाली प्रोफ़ाइलों के साथ काम न करे. हालांकि, यह AOSP के कंट्रोल के साथ काम करना चाहिए, ताकि अन्य उपयोगकर्ताओं को वॉइस कॉल और एसएमएस ऐक्सेस करने की अनुमति दी या बंद की जा सके.

नई ज़रूरी शर्तें लागू करना

अगर डिवाइस में सुरक्षित लॉक स्क्रीन है और एक या उससे ज़्यादा भरोसेमंद एजेंट हैं, जो TrustAgentService सिस्टम एपीआई को लागू करते हैं, तो:

• [9.11.1/W-1-1] यह ज़रूरी है कि उपयोगकर्ता को हर 72 घंटे से ज़्यादा बार, पुष्टि करने के सुझाए गए मुख्य तरीकों (जैसे, पिन, पैटर्न, पासवर्ड) में से किसी एक का इस्तेमाल करने के लिए कहा जाए.

नई ज़रूरी शर्तें खत्म करना

2.5. वाहन से जुड़ी ज़रूरी शर्तें

Android Automotive को लागू करना का मतलब है कि वाहन की हेड यूनिट, सिस्टम और/या मनोरंजक तरीके से पेश की जाने वाली सूचना (इंफ़ोटेनमेंट) की सुविधा के कुछ हिस्से या पूरे हिस्से के लिए, ऑपरेटिंग सिस्टम के तौर पर Android का इस्तेमाल कर रही हो.

Android डिवाइस को Automotive के तौर पर तब ही माना जाता है, जब वे android.hardware.type.automotive सुविधा का एलान करते हों या यहां दी गई सभी शर्तों को पूरा करते हों.

• वाहन में एम्बेड किए गए हों या वाहन में प्लग किए जा सकते हों.
• ड्राइवर की सीट की पंक्ति में मौजूद स्क्रीन को मुख्य डिसप्ले के तौर पर इस्तेमाल किया जा रहा हो.

इस सेक्शन के बाकी हिस्से में दी गई अतिरिक्त शर्तें, Android Auto के साथ काम करने वाले डिवाइसों के लिए खास तौर पर बनाई गई हैं.

2.5.1. हार्डवेयर

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

• [7.1.1.1/A-0-1] डिवाइस की स्क्रीन का डायगनल साइज़ कम से कम 6 इंच होना चाहिए.
• [7.1.1.1/A-0-2] स्क्रीन साइज़ का लेआउट कम से कम 750 dp x 480 dp होना चाहिए.
• [7.2.3/A-0-1] होम फ़ंक्शन ज़रूर होना चाहिए. साथ ही, हो सकता है कि बैक और हाल ही के फ़ंक्शन भी उपलब्ध हों.
• [7.2.3/A-0-2] फ़ोरग्राउंड ऐप्लिकेशन को, बैक फ़ंक्शन (KEYCODE_BACK) के सामान्य और ज़्यादा देर दबाने के इवेंट, दोनों को भेजना ज़रूरी है.
• [7.3/A-0-1] GEAR_SELECTION, NIGHT_MODE, PERF_VEHICLE_SPEED, और PARKING_BRAKE_ON को लागू करना और उनकी रिपोर्ट करना ज़रूरी है.
• [7.3/A-0-2] NIGHT_MODE फ़्लैग की वैल्यू, डैशबोर्ड के दिन/रात मोड के हिसाब से होनी चाहिए. साथ ही, यह वैल्यू, ऐंबियंट लाइट सेंसर के इनपुट पर आधारित होनी चाहिए. हो सकता है कि स्क्रीन की रोशनी को अपने-आप घटाने-बढ़ाने वाला सेंसर, फ़ोटोमीटर जैसा ही हो.
• [7.3/A-0-3] दिए गए हर सेंसर के लिए, SensorAdditionalInfo के हिस्से के तौर पर, सेंसर की अतिरिक्त जानकारी वाला फ़ील्ड TYPE_SENSOR_PLACEMENT होना चाहिए.
• [7.3/A-SR1] जीपीएस/जीएनएसएस को अन्य सेंसर के साथ फ़्यूज़ करके, जगह की जानकारी का अनुमान लगाया जा सकता है. अगर जगह की जानकारी का अनुमान लगाया गया है, तो हमारा सुझाव है कि आप उससे जुड़े सेंसर टाइप और/या इस्तेमाल किए गए वाहन प्रॉपर्टी आईडी को लागू करें और उनकी रिपोर्ट दें.

• [7.3/A-0-4] LocationManager#requestLocationUpdates() के ज़रिए मांगी गई जगह की जानकारी, मैप से मैच नहीं होनी चाहिए.

• [7.3.1/A-0-4] ऐप्लिकेशन को Android के कार सेंसर कोऑर्डिनेट सिस्टम का पालन करना चाहिए.

• [7.3/A-SR-1] हमारा सुझाव है कि आप 3-ऐक्सिस एक्सलरोमीटर और 3-ऐक्सिस जाइरोस्कोप शामिल करें.

• [7.3/A-SR-2] TYPE_HEADING सेंसर को लागू करने और उसकी रिपोर्ट करने का STRONGLY_RECOMMENDED.

अगर वाहन से जुड़े डिवाइसों में OpenGL ES 3.1 का इस्तेमाल किया जा रहा है, तो:

• [7.1.4.1/A-0-1] OpenGL ES 3.1 या इसके बाद के वर्शन का एलान करना ज़रूरी है.
• [7.1.4.1/A-0-2] यह Vulkan 1.1 के साथ काम करना चाहिए.
• [7.1.4.1/A-0-3] इसमें Vulkan लोडर को शामिल करना ज़रूरी है और सभी सिंबल एक्सपोर्ट करने होंगे.

अगर वाहन में इस्तेमाल होने वाले डिवाइस में ऐक्सीलरॉमीटर शामिल है, तो:

• [7.3.1/A-1-1] यह ज़रूरी है कि डिवाइस कम से कम 100 हर्ट्ज़ तक की फ़्रीक्वेंसी वाले इवेंट की रिपोर्ट कर सके.

अगर डिवाइस में 3-ऐक्सिस एक्सलरोमीटर शामिल है, तो:

• [7.3.1/A-SR-1] हमारा सुझाव है कि सीमित ऐक्सिस वाले एक्सलरोमीटर के लिए, कॉम्पोज़िट सेंसर लागू करें.

अगर वाहन से जुड़े डिवाइस में, तीन ऐक्सिस से कम वाला एक्सलरोमीटर शामिल है, तो:

• [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-1] हमारा सुझाव है कि जियोस्कोप की मेज़रमेंट रेंज को +/-250dps पर कॉन्फ़िगर करें, ताकि रिज़ॉल्यूशन को ज़्यादा से ज़्यादा बढ़ाया जा सके.

अगर वाहन से जुड़े डिवाइस में 3-ऐक्सिस जाइरोस्कोप शामिल है, तो:

• [7.3.4/A-SR-2] हमारा सुझाव है कि सीमित अक्ष वाले gyroscope के लिए, कॉम्पोज़िट सेंसर लागू करें.

अगर वाहन से जुड़े डिवाइस में तीन से कम ऐक्सिस वाला गायरोस्कोप शामिल है, तो:

• [7.3.4/A-4-1] TYPE_GYROSCOPE_LIMITED_AXES सेंसर को लागू करना और उसकी रिपोर्ट करना ज़रूरी है.
• [7.3.4/A-4-2] TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED सेंसर को लागू करना और उसकी रिपोर्ट करना ज़रूरी है.

अगर वाहन में इस्तेमाल होने वाले डिवाइस में जीपीएस/जीएनएसएस रिसीवर शामिल है, लेकिन सेल्युलर नेटवर्क पर आधारित डेटा कनेक्टिविटी शामिल नहीं है, तो:

• [7.3.3/A-3-1] जीपीएस/जीएनएसएस रिसीवर के चालू होने पर या चार दिन से ज़्यादा समय के बाद, जगह की जानकारी 60 सेकंड के अंदर मिलनी चाहिए.
• [7.3.3/A-3-2] जगह की जानकारी के लिए किए गए सभी अनुरोधों के लिए, 7.3.3/C-1-2 और 7.3.3/C-1-6 में बताए गए, समस्या को ठीक करने में लगने वाले समय की शर्तें पूरी करनी ज़रूरी हैं.जैसे, ऐसे अनुरोध जो पहली बार या चार दिन से ज़्यादा समय बाद किए गए हों. 7.3.3/C-1-2 की ज़रूरी शर्तें, आम तौर पर उन वाहनों में पूरी की जाती हैं जिनमें मोबाइल नेटवर्क पर आधारित डेटा कनेक्टिविटी नहीं होती. इसके लिए, रिसीवर पर कैलकुलेट किए गए जीएनएसएस ऑर्बिट के अनुमान का इस्तेमाल किया जाता है. इसके अलावा, वाहन की पिछली लोकेशन का इस्तेमाल करके, कम से कम 60 सेकंड तक डेड रेकनिंग की सुविधा का इस्तेमाल किया जाता है. साथ ही, 7.3.3/C-1-3 की शर्तों के मुताबिक, जगह की सटीक जानकारी भी दी जाती है. इसके अलावा, दोनों का इस्तेमाल भी किया जा सकता है.

अगर वाहन से जुड़े डिवाइस में TYPE_HEADING सेंसर शामिल है, तो:

• [7.3.4/A-4-3] यह ज़रूरी है कि यह कम से कम 1 हर्ट्ज़ तक की फ़्रीक्वेंसी वाले इवेंट की रिपोर्ट कर सके.
• [7.3.4/A-SR-3] कम से कम 10 हर्ट्ज़ की फ़्रीक्वेंसी तक के इवेंट की रिपोर्ट करने का STRONGLY_RECOMMENDED.
• यह सही उत्तर दिशा के हिसाब से होना चाहिए.
• यह सुविधा, गाड़ी के रुकने पर भी उपलब्ध होनी चाहिए.
• इसका रिज़ॉल्यूशन कम से कम एक डिग्री होना चाहिए.

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

• [7.4.3/A-0-1] डिवाइस में ब्लूटूथ की सुविधा होनी चाहिए. साथ ही, डिवाइस में ब्लूटूथ LE की सुविधा होनी चाहिए.
• [7.4.3/A-0-2] Android Automotive के लागू होने के लिए, इन ब्लूटूथ प्रोफ़ाइलों के साथ काम करना ज़रूरी है:
  • Hands-Free Profile (एचएफ़पी) की मदद से फ़ोन कॉल करना.
  • ऑडियो डिस्ट्रिब्यूशन प्रोफ़ाइल (A2DP) पर मीडिया चलाना.
  • रिमोट कंट्रोल प्रोफ़ाइल (एवीआरसीपी) की मदद से, मीडिया प्लेबैक को कंट्रोल करना.
  • फ़ोन बुक ऐक्सेस करने वाली प्रोफ़ाइल (पीबीएपी) का इस्तेमाल करके संपर्क शेयर करना.

• [7.4.3/A-SR-1] मैसेज ऐक्सेस प्रोफ़ाइल (एमएपी) के साथ काम करने का सुझाव दिया जाता है.

• [7.4.5/A] इसमें मोबाइल नेटवर्क पर आधारित डेटा कनेक्टिविटी की सुविधा शामिल होनी चाहिए.

• [7.4.5/A] सिस्टम एपीआई के NetworkCapabilities#NET_CAPABILITY_OEM_PAID कॉन्स्टेंट का इस्तेमाल उन नेटवर्क के लिए किया जा सकता है जो सिस्टम ऐप्लिकेशन के लिए उपलब्ध होने चाहिए.

नई ज़रूरी शर्तें लागू करना

अगर डिवाइस में AM/FM ब्रॉडकास्ट रेडियो की सुविधा शामिल है और किसी ऐप्लिकेशन को यह सुविधा दी गई है, तो:

• [7.4.10/A-0-1] FEATURE_BROADCAST_RADIO के लिए सहायता देने का एलान करना ज़रूरी है.

नई ज़रूरी शर्तें खत्म करना

बाहरी व्यू कैमरा, ऐसा कैमरा होता है जो डिवाइस के बाहर की इमेज कैप्चर करता है. जैसे, पीछे की तरफ़ दिखने वाली इमेज कैप्चर करने वाला कैमरा.

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

• इसमें एक या उससे ज़्यादा बाहरी व्यू कैमरे होने चाहिए.

अगर वाहन से जुड़े डिवाइस में बाहरी व्यू कैमरा शामिल है, तो ऐसे कैमरे के लिए:

• [7.5/A-1-1] बाहरी कैमरों को Android Camera API के ज़रिए ऐक्सेस नहीं किया जा सकता. ऐसा तब तक नहीं किया जा सकता, जब तक वे कैमरे मुख्य ज़रूरी शर्तों के मुताबिक न हों.

• [7.5/A-SR-1] हमारा सुझाव है कि कैमरे की झलक को घुमाएं या तिरछा न करें.

• [7.5/A-SR-2] हमारा सुझाव है कि इमेज का रिज़ॉल्यूशन कम से कम 1.3 मेगापिक्सल हो.

• इसमें फ़िक्स्ड-फ़ोकस या ईडीओएफ़ (एक्सटेंडेड डेप्थ ऑफ़ फ़ील्ड) हार्डवेयर होना चाहिए.

• कैमरा ड्राइवर में, हार्डवेयर ऑटो-फ़ोकस या सॉफ़्टवेयर ऑटो-फ़ोकस की सुविधा हो सकती है.

अगर वाहन में एक या उससे ज़्यादा एक्सटीरियर व्यू कैमरे लगाए गए हैं और एक्सटीरियर व्यू सिस्टम (ईवीएस) सेवा लोड की गई है, तो ऐसे कैमरे के लिए:

• [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 में बताई गई, पीछे की ओर वाले कैमरे के लिए उपलब्ध सुविधाएं (जैसे, ऑटो-फ़ोकस वगैरह) शामिल हो सकती हैं.

नई ज़रूरी शर्तें लागू करना

पीछे वाला कैमरा, वाहन के बाहर की तरफ़ होता है. इसे वाहन के किसी भी हिस्से में लगाया जा सकता है. यह वाहन के केबिन के बाहर की तरफ़ होता है. इसका मतलब है कि यह पीछे की तरफ़ दिखने वाले दृश्यों को रिकॉर्ड करता है, जैसे कि रियर-व्यू कैमरा.

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

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

• [7.5/A-SR-1] हमारा सुझाव है कि आप एक या उससे ज़्यादा ऐसे कैमरे शामिल करें जिनसे बाहर की ओर दिखने वाली चीज़ें रिकॉर्ड की जा सकें.
• इसमें एक या उससे ज़्यादा उपयोगकर्ता-फ़ेसिंग कैमरे शामिल हो सकते हैं.
• [7.5/A-SR-2] हमारा सुझाव है कि एक साथ कई कैमरों की स्ट्रीमिंग की सुविधा उपलब्ध कराएं.

अगर वाहन में इस्तेमाल किए जाने वाले डिवाइस में, कम से कम एक ऐसा कैमरा शामिल है जो बाहर की ओर है, तो ऐसे कैमरे के लिए:

• [7.5/A-1-1] कैमरे को इस तरह से ओरिएंट करना ज़रूरी है कि कैमरे का लंबा डाइमेंशन, Android वाहन सेंसर के अक्षों के X-Y प्लेन के साथ अलाइन हो.
• [7.5/A-SR-3] हमारा सुझाव है कि आपके पास फ़िक्स्ड-फ़ोकस या EDOF (एक्सटेंडेड डेप्थ ऑफ़ फ़ील्ड) हार्डवेयर हो.
• [7.5/A-1-2] मुख्य व्यू के तौर पर इस्तेमाल होने वाले कैमरे का आईडी, सबसे कम होना चाहिए.

अगर वाहन से जुड़े डिवाइस में कम से कम एक ऐसा कैमरा शामिल है जो उपयोगकर्ता के सामने होता है, तो ऐसे कैमरे के लिए:

• [7.5/A-2-1] उपयोगकर्ता के सामने वाला मुख्य कैमरा, सबसे कम कैमरा आईडी वाला कैमरा होना चाहिए.
• कैमरे को इस तरह से ऑर्डर किया जा सकता है कि उसका लंबा डाइमेंशन, Android Automotive सेंसर ऐक्सिस के X-Y प्लैन के साथ अलाइन हो जाए.

अगर वाहन से जुड़े डिवाइस में ऐसा कैमरा शामिल है जिसे android.hardware.Camera या android.hardware.camera2 एपीआई के ज़रिए ऐक्सेस किया जा सकता है, तो:

• [7.5/A-3-1] यह ज़रूरी है कि ऐप्लिकेशन, सेक्शन 7.5 में बताई गई कैमरे से जुड़ी बुनियादी ज़रूरी शर्तों को पूरा करता हो.

अगर वाहन से जुड़े डिवाइस में ऐसा कैमरा शामिल है जिसे android.hardware.Camera या android.hardware.camera2 एपीआई के ज़रिए ऐक्सेस नहीं किया जा सकता, तो:

• [7.5/A-4-1] इसे एक्सटेंडेड व्यू सिस्टम सेवा के ज़रिए ऐक्सेस किया जा सकता है.

अगर वाहन में इस्तेमाल किए जाने वाले डिवाइस में एक या उससे ज़्यादा कैमरे हैं, जिन्हें एक्सटेंडेड व्यू सिस्टम सेवा की मदद से ऐक्सेस किया जा सकता है, तो ऐसे कैमरे के लिए:

• [7.5/A-5-1] कैमरे की झलक को घुमाया या हॉरिज़ॉन्टल तौर पर मिरर नहीं किया जाना चाहिए.
• [7.5/A-SR-4] हमारा सुझाव है कि इमेज का रिज़ॉल्यूशन कम से कम 1.3 मेगापिक्सल हो.

अगर वाहन में एक या उससे ज़्यादा कैमरे इस्तेमाल किए जा रहे हैं, जिन्हें एक्सटेंडेड व्यू सिस्टम सेवा और android.hardware.Camera या android.hardware.Camera2 एपीआई, दोनों के ज़रिए ऐक्सेस किया जा सकता है, तो ऐसे कैमरे के लिए:

• [7.5/A-6-1] एक ही कैमरा आईडी की जानकारी देनी होगी.

अगर वाहन से जुड़े डिवाइसों में, मालिकाना हक वाला कैमरा एपीआई उपलब्ध कराया जाता है, तो:

• [7.5/A-7-1] android.hardware.camera2 एपीआई या एक्सटेंडेड व्यू सिस्टम एपीआई का इस्तेमाल करके, ऐसा कैमरा एपीआई लागू करना ज़रूरी है.

नई ज़रूरी शर्तें खत्म करना

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

• [7.6.1/A-0-1] ऐप्लिकेशन के निजी डेटा (जिसे "/data" पार्टीशन भी कहा जाता है) के लिए, कम से कम 4 जीबी का नॉन-वॉल्व्यूलेट स्टोरेज होना चाहिए.

• [7.6.1/A] फ़्लैश स्टोरेज पर बेहतर परफ़ॉर्मेंस और लंबी लाइफ़ देने के लिए, डेटा पार्टीशन को फ़ॉर्मैट करना चाहिए. उदाहरण के लिए, f2fs फ़ाइल-सिस्टम का इस्तेमाल करना.

अगर वाहन से जुड़े डिवाइसों में, डिवाइस के अंदर मौजूद ऐसे स्टोरेज का इस्तेमाल करके शेयर किया गया बाहरी स्टोरेज उपलब्ध कराया जाता है जिसे हटाया नहीं जा सकता, तो:

• [7.6.1/A-SR-1] हमारा सुझाव है कि बाहरी स्टोरेज पर किए जाने वाले ऑपरेशन के लिए, I/O ओवरहेड को कम करें. उदाहरण के लिए, SDCardFS का इस्तेमाल करके.

अगर वाहन से जुड़े डिवाइसों पर 64-बिट प्रोसेसिंग की सुविधा है, तो:

• [7.6.1/A-2-1] अगर इनमें से किसी भी डेंसिटी का इस्तेमाल किया जाता है, तो कर्नेल और यूज़रस्पेस के लिए कम से कम 816 एमबी मेमोरी उपलब्ध होनी चाहिए:

  • छोटी/सामान्य स्क्रीन पर 280 डीपीआई या उससे कम
  • बहुत बड़ी स्क्रीन पर ldpi या उससे कम
  • बड़ी स्क्रीन पर mdpi या उससे कम

• [7.6.1/A-2-2] अगर इनमें से किसी भी डेंसिटी का इस्तेमाल किया जाता है, तो कर्नेल और यूज़रस्पेस के लिए उपलब्ध मेमोरी कम से कम 944 एमबी होनी चाहिए:

  • छोटी/सामान्य स्क्रीन पर xhdpi या उससे ज़्यादा
  • बड़ी स्क्रीन पर hdpi या उससे ज़्यादा
  • ज़्यादा बड़ी स्क्रीन पर mdpi या उससे ज़्यादा

• [7.6.1/A-2-3] अगर इनमें से किसी भी डेंसिटी का इस्तेमाल किया जाता है, तो कर्नेल और यूज़रस्पेस के लिए उपलब्ध मेमोरी कम से कम 1280 एमबी होनी चाहिए:

  • छोटी/सामान्य स्क्रीन पर 400 डीपीआई या उससे ज़्यादा
  • बड़ी स्क्रीन पर xhdpi या उससे ज़्यादा
  • बहुत बड़ी स्क्रीन पर tvdpi या उससे ज़्यादा

• [7.6.1/A-2-4] अगर इनमें से किसी भी डेंसिटी का इस्तेमाल किया जाता है, तो kernel और userspace के लिए उपलब्ध मेमोरी कम से कम 1824 एमबी होनी चाहिए:

  • छोटी/सामान्य स्क्रीन पर 560 डीपीआई या उससे ज़्यादा
  • बड़ी स्क्रीन पर 400 डीपीआई या उससे ज़्यादा
  • बहुत बड़ी स्क्रीन पर xhdpi या उससे ज़्यादा

ध्यान दें कि ऊपर दी गई "कर्नल और यूज़रस्पेस के लिए उपलब्ध मेमोरी" से, रेडियो, वीडियो वगैरह जैसे हार्डवेयर कॉम्पोनेंट के लिए पहले से तय मेमोरी के अलावा, डिवाइस में लागू करने के लिए, कर्नेल के कंट्रोल में न होने वाली मेमोरी का मतलब है.

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

• [7.7.1/A] इसमें पेरिफ़ेरल मोड के साथ काम करने वाला यूएसबी पोर्ट शामिल होना चाहिए.

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

• [7.8.1/A-0-1] इसमें माइक्रोफ़ोन होना ज़रूरी है.

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

• [7.8.2/A-0-1] इसमें ऑडियो आउटपुट होना चाहिए और इसकी जानकारी ज़ाहिर की जानी चाहिए android.hardware.audio.output.

2.5.2. मल्टीमीडिया

वाहन से जुड़े डिवाइसों के लिए, ऑडियो को एन्कोड करने और डिकोड करने के लिए, यहां दिए गए फ़ॉर्मैट का इस्तेमाल करना ज़रूरी है. साथ ही, इन्हें तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराना ज़रूरी है:

• [5.1/A-0-1] MPEG-4 AAC प्रोफ़ाइल (AAC LC)
• [5.1/A-0-2] MPEG-4 HE AAC Profile (AAC+)
• [5.1/A-0-3] AAC ELD (बेहतर कम देरी वाला AAC)

वाहन से जुड़े डिवाइसों पर, वीडियो को एन्कोड करने के लिए इन फ़ॉर्मैट का इस्तेमाल किया जाना चाहिए. साथ ही, इन्हें तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराना चाहिए:

• [5.2/A-0-1] H.264 AVC
• [5.2/A-0-2] VP8

वाहन से जुड़े डिवाइसों में, वीडियो को डिकोड करने के लिए इन फ़ॉर्मैट का इस्तेमाल किया जाना चाहिए. साथ ही, इन्हें तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराना चाहिए:

• [5.3/A-0-1] H.264 AVC
• [5.3/A-0-2] MPEG-4 SP
• [5.3/A-0-3] VP8
• [5.3/A-0-4] VP9

हमारा सुझाव है कि वाहन से जुड़े डिवाइसों पर, वीडियो को डिकोड करने के लिए इन फ़ॉर्मैट का इस्तेमाल करें:

• [5.3/A-SR-1] H.265 HEVC

2.5.3. सॉफ़्टवेयर

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

• [3/A-0-1] इस सुविधा के बारे में ज़रूर बताएं android.hardware.type.automotive.

• [3/A-0-2] uiMode = UI_MODE_TYPE_CAR के साथ काम करना चाहिए.

• [3/A-0-3] android.car.* नेमस्पेस में मौजूद सभी सार्वजनिक एपीआई के साथ काम करना चाहिए.

अगर वाहन के लिए बने डिवाइस में, android.car.VehiclePropertyIds के साथ android.car.CarPropertyManager का इस्तेमाल करके मालिकाना एपीआई उपलब्ध कराया जाता है, तो:

• [3/A-1-1] सिस्टम ऐप्लिकेशन को इन प्रॉपर्टी के इस्तेमाल के लिए खास सुविधाएं नहीं देनी चाहिए. इसके अलावा, तीसरे पक्ष के ऐप्लिकेशन को इन प्रॉपर्टी का इस्तेमाल करने से नहीं रोकना चाहिए.
• [3/A-1-2] SDK में पहले से मौजूद वाहन की ऐसी प्रॉपर्टी का डुप्लीकेट नहीं बनाया जाना चाहिए.

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

• [3.2.1/A-0-1] वाहन संबंधित अनुमति के रेफ़रंस पेज में बताए गए सभी अनुमतियों के लिए, अनुमतियों के सभी कॉन्स्टेंट काम करने चाहिए और उन्हें लागू करना चाहिए.

• [3.2.3.1/A-0-1] यहां दिए गए ऐप्लिकेशन इंटेंट के हिसाब से तय किए गए सभी सार्वजनिक इंटेंट फ़िल्टर पैटर्न के लिए, इंटेंट हैंडलर के साथ एक या उससे ज़्यादा ऐप्लिकेशन या सेवा कॉम्पोनेंट को पहले से लोड करना ज़रूरी है.

• [3.4.1/A-0-1] android.webkit.Webview एपीआई को पूरी तरह से लागू करना ज़रूरी है.

नई ज़रूरी शर्तें लागू करना

• [3.8/A-0-1] फ़ोरग्राउंड में मौजूद मौजूदा उपयोगकर्ता के अलावा, दूसरे सभी उपयोगकर्ताओं को गतिविधियां लॉन्च करने और किसी भी डिसप्ले पर यूज़र इंटरफ़ेस (यूआई) को ऐक्सेस करने की अनुमति नहीं होनी चाहिए.

नई ज़रूरी शर्तें खत्म करना

• [3.8.3/A-0-1] तीसरे पक्ष के ऐप्लिकेशन के अनुरोध करने पर, Notification.CarExtender एपीआई का इस्तेमाल करने वाली सूचनाएं दिखानी ज़रूरी हैं.

• [3.8.4/A-SR-1] हमारा सुझाव है कि Assist ऐक्शन को मैनेज करने के लिए, डिवाइस पर कोई सहायक लागू करें.

अगर वाहन में इस्तेमाल होने वाले डिवाइस में, बोलने के लिए पुश बटन शामिल है, तो:

• [3.8.4/A-1-1] उपयोगकर्ता के चुने गए सहायता ऐप्लिकेशन को लॉन्च करने के लिए, डिवाइस पर बने पुश-टू-टॉक बटन को हल्का-सा दबाकर, इंटरैक्शन करना ज़रूरी है. दूसरे शब्दों में, VoiceInteractionService को लागू करने वाले ऐप्लिकेशन को लॉन्च करने के लिए, डिवाइस पर बने पुश-टू-टॉक बटन को हल्का-सा दबाकर, इंटरैक्शन करना ज़रूरी है.

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

• [3.8.3.1/A-0-1] Notifications on Automotive OS SDK टूल के दस्तावेज़ में बताए गए तरीके से, संसाधनों को सही तरीके से रेंडर करना ज़रूरी है.
• [3.8.3.1/A-0-2] सूचना से जुड़ी कार्रवाइयों के लिए, Notification.Builder.addAction() के ज़रिए दी गई कार्रवाइयों के बजाय, 'चलाएं' और 'म्यूट करें' को दिखाना ज़रूरी है
• [3.8.3.1/A] को बेहतर मैनेजमेंट टास्क के इस्तेमाल पर पाबंदी लगानी चाहिए. जैसे, हर सूचना चैनल के लिए कंट्रोल. कंट्रोल को कम करने के लिए, हर ऐप्लिकेशन के लिए यूज़र इंटरफ़ेस (यूआई) के फ़ायदे का इस्तेमाल किया जा सकता है.

अगर वाहन से जुड़े डिवाइसों के लागू होने पर, उपयोगकर्ता HAL प्रॉपर्टी काम करती हैं, तो:

• [3.9.3/A-1-1] सभी उपयोगकर्ता लाइफ़साइकल प्रॉपर्टी को लागू करना ज़रूरी है
  • INITIAL_USER_INFO, SWITCH_USER, CREATE_USER, REMOVE_USER.

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

• [3.14/A-0-1] इसमें यूज़र इंटरफ़ेस (यूआई) फ़्रेमवर्क होना चाहिए, ताकि मीडिया एपीआई का इस्तेमाल करने वाले तीसरे पक्ष के ऐप्लिकेशन काम कर सकें. इस बारे में 3.14 सेक्शन में बताया गया है.
• [3.14/A-0-2] यह ज़रूरी है कि ऐप्लिकेशन, ड्राइविंग के दौरान उपयोगकर्ता को मीडिया ऐप्लिकेशन के साथ सुरक्षित तरीके से इंटरैक्ट करने की अनुमति दे.
• [3.14/A-0-3] ऐप्लिकेशन में, CAR_INTENT_ACTION_MEDIA_TEMPLATE के साथ काम करने वाले, CAR_EXTRA_MEDIA_PACKAGE के साथ काम करने वाले, और इंप्लिसिट इंटेंट ऐक्शन के लिए ज़रूरी है.
• [3.14/A-0-4] किसी मीडिया ऐप्लिकेशन की प्राथमिकता गतिविधि पर नेविगेट करने के लिए, ऐप्लिकेशन में एक सुविधा उपलब्ध कराई जानी चाहिए. हालांकि, यह सुविधा सिर्फ़ तब चालू की जानी चाहिए, जब कार के यूज़र एक्सपीरियंस से जुड़ी पाबंदियां लागू न हों.
• [3.14/A-0-5] मीडिया ऐप्लिकेशन से सेट किए गए गड़बड़ी के मैसेज दिखाने चाहिए. साथ ही, इसमें वैकल्पिक अतिरिक्त सुविधाओं ERROR_RESOLUTION_ACTION_LABEL और ERROR_RESOLUTION_ACTION_INTENT का इस्तेमाल किया जा सकता है.
• [3.14/A-0-6] खोजने की सुविधा वाले ऐप्लिकेशन के लिए, इन-ऐप्लिकेशन सर्च अवर्डेंस की सुविधा ज़रूर होनी चाहिए.
• [3.14/A-0-7] MediaBrowser के लेआउट को दिखाते समय, CONTENT_STYLE_BROWSABLE_HINT और CONTENT_STYLE_PLAYABLE_HINT की परिभाषाओं का पालन करना ज़रूरी है.

अगर वाहन से जुड़े डिवाइसों में डिफ़ॉल्ट लॉन्चर ऐप्लिकेशन शामिल है, तो:

• [3.14/A-1-1] इसमें मीडिया सेवाएं शामिल होनी चाहिए और उन्हें CAR_INTENT_ACTION_MEDIA_TEMPLATE के इंटेंट से खोलना चाहिए.

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

• [3.8/A] immersive documentation में बताए गए तरीके से, फ़ुल स्क्रीन मोड में जाने के लिए किए गए ऐप्लिकेशन के अनुरोधों पर पाबंदी लगा सकता है.
• [3.8/A] ऐप्लिकेशन में, स्टेटस बार और नेविगेशन बार को हमेशा दिखने की अनुमति दी जा सकती है.
• [3.8/A] सिस्टम यूज़र इंटरफ़ेस (यूआई) एलिमेंट के पीछे के रंगों को बदलने के लिए, ऐप्लिकेशन के अनुरोधों पर पाबंदी लगाई जा सकती है. इससे यह पक्का किया जा सकेगा कि वे एलिमेंट हर समय साफ़ तौर पर दिखें.

2.5.4. परफ़ॉर्मेंस और पावर

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

• [8.2/A-0-1] हर प्रोसेस के यूआईडी के हिसाब से, नॉन-वोलिटाइल स्टोरेज में पढ़े और लिखे गए बाइट की संख्या की जानकारी देना ज़रूरी है, ताकि डेवलपर को System API android.car.storagemonitoring.CarStorageMonitoringManager के ज़रिए आंकड़े उपलब्ध कराए जा सकें. Android ओपन सोर्स प्रोजेक्ट, uid_sys_stats कर्नेल मॉड्यूल की मदद से ज़रूरी शर्तें पूरी करता है.
• [8.3/A-1-3] यह गैरेज मोड के साथ काम करना चाहिए.
• [8.3/A] हर ड्राइव के बाद, कम से कम 15 मिनट तक गैराज मोड में होना चाहिए. ऐसा तब तक करना चाहिए, जब तक:
  • बैटरी खत्म हो गई है.
  • कोई भी ऐसा जॉब शेड्यूल नहीं किया गया है जो काम नहीं कर रहा है.
  • ड्राइवर, गैराज मोड से बाहर निकलता है.
• [8.4/A-0-1] हर कॉम्पोनेंट के लिए, बिजली की खपत की प्रोफ़ाइल देना ज़रूरी है. इससे हर हार्डवेयर कॉम्पोनेंट के लिए, बिजली की खपत की वैल्यू और समय के साथ कॉम्पोनेंट की वजह से बैटरी की खपत के अनुमान की जानकारी मिलती है. इस बारे में Android Open Source Project की साइट पर जानकारी दी गई है.
• [8.4/A-0-2] बिजली की खपत की सभी वैल्यू को मिलीऐंपियर घंटे (mAh) में रिपोर्ट करना ज़रूरी है.
• [8.4/A-0-3] हर प्रोसेस के यूआईडी के हिसाब से, सीपीयू की बिजली की खपत की जानकारी देना ज़रूरी है. Android ओपन सोर्स प्रोजेक्ट, uid_cputime कर्नेल मॉड्यूल लागू करने की ज़रूरी शर्तें पूरी करता है.
• [8.4/A] अगर किसी ऐप्लिकेशन के लिए, हार्डवेयर कॉम्पोनेंट के पावर इस्तेमाल को एट्रिब्यूट नहीं किया जा सकता, तो उसे हार्डवेयर कॉम्पोनेंट को एट्रिब्यूट किया जाना चाहिए.
• [8.4/A-0-4] ऐप्लिकेशन डेवलपर को, बिजली की खपत की जानकारी adb shell dumpsys batterystats शेल कमांड के ज़रिए उपलब्ध कराना ज़रूरी है.

2.5.5. सुरक्षा मॉडल

अगर वाहन से जुड़े डिवाइसों के लागू होने की सुविधा, कई उपयोगकर्ताओं के लिए काम करती है, तो:

• [9.5/A-1-1] उपयोगकर्ताओं को डिवाइस की प्रोवाइज़िंग के अलावा, हेडलेस सिस्टम उपयोगकर्ता के साथ इंटरैक्ट करने या उसमें स्विच करने की अनुमति नहीं देनी चाहिए.
• [9.5/A-1-2] BOOT_COMPLETED से पहले, सेकंडरी उपयोगकर्ता पर स्विच करना ज़रूरी है.
• [9.5/A-1-3] डिवाइस पर उपयोगकर्ताओं की तय सीमा पूरी होने के बाद भी, मेहमान उपयोगकर्ता बनाने की सुविधा होनी चाहिए.

नई ज़रूरी शर्तें लागू करना

अगर वाहन से जुड़े डिवाइसों के लागू होने की जानकारी में android.hardware.microphone का एलान किया गया है, तो:

• [9.8.2/A-1-1] जब कोई ऐप्लिकेशन माइक्रोफ़ोन से ऑडियो डेटा ऐक्सेस कर रहा हो, तो माइक्रोफ़ोन इंडिकेटर दिखाना ज़रूरी है. हालांकि, जब माइक्रोफ़ोन को सिर्फ़ HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService या CDD आइडेंटिफ़ायर [C-4-X] के साथ सेक्शन 9.1 में बताई गई भूमिकाओं वाले ऐप्लिकेशन ऐक्सेस करते हैं, तब ऐसा नहीं करना चाहिए.
• [9.8.2/A-1-2] सिस्टम के उन ऐप्लिकेशन के लिए माइक्रोफ़ोन इंडिकेटर को नहीं छिपाना चाहिए जिनमें यूज़र इंटरफ़ेस दिखते हैं या उपयोगकर्ता सीधे तौर पर इंटरैक्ट करते हैं.
• [9.8.2/A-1-3] सेटिंग ऐप्लिकेशन में माइक्रोफ़ोन को टॉगल करने के लिए, उपयोगकर्ता को अवसर देना ज़रूरी है.

नई ज़रूरी शर्तों को खत्म करना

अगर वाहन से जुड़े डिवाइस के लागू होने की जानकारी में android.hardware.camera.any का एलान किया जाता है, तो:

• [9.8.2/A-2-1] जब कोई ऐप्लिकेशन कैमरे का लाइव डेटा ऐक्सेस कर रहा हो, तो कैमरा इंडिकेटर दिखाना ज़रूरी है. हालांकि, जब कैमरे को सिर्फ़ उन ऐप्लिकेशन के ज़रिए ऐक्सेस किया जा रहा हो जिनके पास सेक्शन 9.1 अनुमतियां में बताई गई भूमिकाएं हैं, तो कैमरा इंडिकेटर नहीं दिखाना चाहिए. इन भूमिकाओं के लिए, सीडीडी आइडेंटिफ़ायर [C-4-X][C-3-X] का इस्तेमाल किया जाता है.
• [9.8.2/A-2-2] सिस्टम के उन ऐप्लिकेशन के लिए कैमरे के इंडिकेटर को नहीं छिपाना चाहिए जिनमें यूज़र इंटरफ़ेस दिखते हैं या जिनमें उपयोगकर्ता सीधे तौर पर इंटरैक्ट करता है.

नई ज़रूरी शर्तें लागू करना

• [9.8.2/A-2-3] सेटिंग ऐप्लिकेशन में कैमरे को टॉगल करने के लिए, उपयोगकर्ता को सुविधा देना ज़रूरी है.
• [9.8.2/A-2-4] PermissionManager.getIndicatorAppOpUsageData() से मिले कैमरे के इस्तेमाल से, हाल ही में इस्तेमाल किए गए और ऐक्टिव ऐप्लिकेशन के साथ-साथ उनसे जुड़े एट्रिब्यूशन मैसेज भी दिखाने होंगे.

नई ज़रूरी शर्तें खत्म करना

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

• [9/A-0-1] android.hardware.security.model.compatible सुविधा का एलान करना ज़रूरी है.
• [9.11/A-0-1] अलग से एक्ज़ीक्यूशन एनवायरमेंट का इस्तेमाल करके, पासकोड लागू करने के तरीके का बैक अप लेना ज़रूरी है.
• [9.11/A-0-2] इसमें आरएसए, एईएस, ईसीडीएसए, और एचएमएससी क्रिप्टोग्राफ़िक एल्गोरिदम और MD5, SHA1, और SHA-2 फ़ैमिली के हैश फ़ंक्शन लागू होने चाहिए. इससे, Android Keystore सिस्टम के काम करने वाले एल्गोरिदम को सही तरीके से काम करने में मदद मिलती है. यह एल्गोरिदम, कोर और उसके बाद के लेवल पर चलने वाले कोड से सुरक्षित तरीके से अलग होता है. सुरक्षित आइसोलेशन की सुविधा, उन सभी संभावित तरीकों को ब्लॉक करनी चाहिए जिनकी मदद से कर्नेल या यूज़रस्पेस कोड, डीएमए के साथ-साथ आइसोलेट किए गए एनवायरमेंट की इंटरनल स्टेटस को ऐक्सेस कर सकता है. अपस्ट्रीम Android Open Source Project (AOSP), Trusty को लागू करके इस ज़रूरी शर्त को पूरा करता है. हालांकि, ARM TrustZone पर आधारित कोई दूसरा समाधान या तीसरे पक्ष की समीक्षा के बाद, हाइपरवाइजर पर आधारित सही आइसोलेशन को सुरक्षित तरीके से लागू करना, इसके विकल्प हैं.
• [9.11/A-0-3] लॉक स्क्रीन पर पुष्टि करने की प्रोसेस, अलग से चलाए जाने वाले प्रोग्राम में पूरी की जानी चाहिए. पुष्टि होने के बाद ही, पुष्टि करने के लिए इस्तेमाल की जाने वाली कुंजियों का इस्तेमाल किया जा सकता है. लॉक स्क्रीन के क्रेडेंशियल को इस तरह से सेव करना ज़रूरी है कि सिर्फ़ अलग-अलग इकोसिस्टम में काम करने वाले प्रोग्राम के लिए, लॉक स्क्रीन की पुष्टि की जा सके. अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट, Gatekeeper Hardware Abstraction Layer (HAL) और Trusty उपलब्ध कराता है. इनका इस्तेमाल, इस ज़रूरी शर्त को पूरा करने के लिए किया जा सकता है.
• [9.11/A-0-4] यह ज़रूरी है कि कुंजी की पुष्टि करने की सुविधा काम करे. इसमें, पुष्टि करने के लिए इस्तेमाल होने वाली साइनिंग कुंजी को सुरक्षित हार्डवेयर से सुरक्षित किया गया हो और साइनिंग की प्रोसेस, सुरक्षित हार्डवेयर में की गई हो. पुष्टि करने के लिए इस्तेमाल होने वाली साइनिंग पासकोड को ज़रूर ज़्यादा से ज़्यादा डिवाइसों के साथ शेयर किया जाना चाहिए. इससे, इन पासकोड का इस्तेमाल डिवाइस आइडेंटिफ़ायर के तौर पर नहीं किया जा सकेगा. इस शर्त को पूरा करने का एक तरीका यह है कि जब तक किसी SKU की कम से कम 1,00,000 यूनिट का प्रॉडक्शन न हो जाए, तब तक एक ही पुष्टि करने वाली कुंजी शेयर की जाए. अगर किसी SKU की 1,00,000 से ज़्यादा यूनिट बनाई जाती हैं, तो हर 1,00,000 यूनिट के लिए, अलग-अलग कुंजी का इस्तेमाल किया जा सकता है.

ध्यान दें कि अगर किसी डिवाइस पर, Android के किसी पुराने वर्शन में पहले से ही एन्क्रिप्शन लागू है, तो उस डिवाइस को अलग से एन्क्रिप्शन करने वाले एनवायरमेंट के साथ काम करने वाले पासकोड सेव करने की सुविधा और पासकोड की पुष्टि करने की सुविधा का इस्तेमाल करने की ज़रूरत नहीं होती. हालांकि, ऐसा तब तक नहीं किया जा सकता, जब तक डिवाइस में android.hardware.fingerprint सुविधा का इस्तेमाल नहीं किया जाता. इस सुविधा के लिए, अलग से एन्क्रिप्शन करने वाले एनवायरमेंट के साथ काम करने वाले पासकोड सेव करने की सुविधा और पासकोड की पुष्टि करने की सुविधा का इस्तेमाल करना ज़रूरी होता है.

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

• [9.14/A-0-1] Android फ़्रेमवर्क के वाहन के सबसिस्टम से मैसेज को कंट्रोल करना ज़रूरी है. उदाहरण के लिए, अनुमति वाले मैसेज टाइप और मैसेज के सोर्स की अनुमति देना.
• [9.14/A-0-2] Android फ़्रेमवर्क या तीसरे पक्ष के ऐप्लिकेशन से, सेवा के अस्वीकार होने से जुड़े हमलों से बचने के लिए, निगरानी करना ज़रूरी है. इससे, नुकसान पहुंचाने वाले सॉफ़्टवेयर को वाहन के नेटवर्क पर ट्रैफ़िक भेजने से रोका जा सकता है. इससे वाहन के सबसिस्टम के काम करने में रुकावट आ सकती है.

2.5.6. डेवलपर टूल और विकल्पों के साथ काम करने की सुविधा

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

• Perfetto
  • [6.1/A-0-1] शेल उपयोगकर्ता को /system/bin/perfetto बाइनरी दिखानी चाहिए, जो cmdline के साथ काम करती हो और perfetto दस्तावेज़ के मुताबिक हो.
  • [6.1/A-0-2] perfetto दस्तावेज़ में बताए गए स्कीमा के मुताबिक, protobuf कॉन्फ़िगरेशन को इनपुट के तौर पर स्वीकार करना ज़रूरी है.
  • [6.1/A-0-3] perfetto दस्तावेज़ में बताए गए स्कीमा के मुताबिक, protobuf ट्रेस को आउटपुट के तौर पर लिखने के लिए, यह ज़रूरी है कि perfetto बाइनरी का इस्तेमाल किया जाए.
  • [6.1/A-0-4] perfetto दस्तावेज़ में बताए गए कम से कम डेटा सोर्स, perfetto बाइनरी के ज़रिए उपलब्ध कराए जाने चाहिए.

2.6. टैबलेट के लिए ज़रूरी शर्तें

Android टैबलेट डिवाइस से, ऐसे Android डिवाइस का मतलब है जो आम तौर पर इन सभी शर्तों को पूरा करता है:

• इसे दोनों हाथों से पकड़कर इस्तेमाल किया जाता है.
• इसमें क्लैमशेल या कन्वर्टिबल कॉन्फ़िगरेशन नहीं है.
• डिवाइस के साथ इस्तेमाल किए जाने वाले फ़िज़िकल कीबोर्ड, स्टैंडर्ड कनेक्शन (जैसे, यूएसबी, ब्लूटूथ) के ज़रिए कनेक्ट होते हैं.

• इसमें बैटरी जैसा पावर सोर्स हो, जिससे इसे कहीं भी ले जाया जा सके.

• स्क्रीन का डाइमेंशन 7" से ज़्यादा और 18" से कम होना चाहिए.

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

2.6.1. हार्डवेयर

जाइरोस्कोप

अगर टैबलेट डिवाइस में 3-ऐक्सिस जाइरोस्कोप शामिल है, तो:

• [7.3.4/Tab-1-1] यह ज़रूरी है कि यह हर सेकंड 1,000 डिग्री तक ओरिएंटेशन में होने वाले बदलावों को मेज़र कर सके.

ज़रूरी मेमोरी और स्टोरेज (सेक्शन 7.6.1)

हैंडहेल्ड डिवाइसों के लिए तय की गई ज़रूरी शर्तों में, छोटी/सामान्य स्क्रीन के लिए बताई गई स्क्रीन डेंसिटी, टैबलेट पर लागू नहीं होती हैं.

यूएसबी पेरिफ़रल मोड (सेक्शन 7.7.1)

अगर टैबलेट डिवाइस में, यूएसबी पोर्ट के साथ-साथ, पेरिफ़रल मोड की सुविधा भी है, तो:

• [7.7.1/Tab] Android Open Accessory (AOA) API लागू किया जा सकता है.

वर्चुअल रिएलिटी मोड (सेक्शन 7.9.1)

वर्चुअल रिएलिटी की बेहतर परफ़ॉर्मेंस (सेक्शन 7.9.2)

वर्चुअल रिएलिटी की ज़रूरी शर्तें, टैबलेट पर लागू नहीं होतीं.

2.6.2. सुरक्षा मॉडल

कुंजियां और क्रेडेंशियल (सेक्शन 9.11)

सेक्शन [9.11] देखें.

अगर टैबलेट डिवाइस पर एक से ज़्यादा उपयोगकर्ताओं को अनुमति दी गई है और android.hardware.telephony सुविधा फ़्लैग का एलान नहीं किया गया है, तो:

• [9.5/T-1-1] डिवाइस पर प्रतिबंधित प्रोफ़ाइलों की सुविधा काम करती हो. इस सुविधा की मदद से, डिवाइस के मालिक अन्य उपयोगकर्ताओं और उनके ऐक्सेस को मैनेज कर सकते हैं. पाबंदी वाली प्रोफ़ाइलों की मदद से, डिवाइस के मालिक, दूसरे उपयोगकर्ताओं के लिए अलग-अलग एनवायरमेंट तुरंत सेट अप कर सकते हैं. साथ ही, उन एनवायरमेंट में उपलब्ध ऐप्लिकेशन पर ज़्यादा सटीक पाबंदियां भी लगा सकते हैं.

अगर टैबलेट डिवाइस पर एक से ज़्यादा उपयोगकर्ताओं को ऐक्सेस दिया गया है और android.hardware.telephony सुविधा फ़्लैग का एलान किया गया है, तो:

• [9.5/T-2-1] यह ज़रूरी है कि यह ऐप्लिकेशन, पाबंदी वाली प्रोफ़ाइलों के साथ काम न करे. हालांकि, यह AOSP के कंट्रोल के साथ काम करना चाहिए, ताकि अन्य उपयोगकर्ताओं को वॉइस कॉल और एसएमएस ऐक्सेस करने की अनुमति दी या बंद की जा सके.

2.6.2. सॉफ़्टवेयर

• [3.2.3.1/Tab-0-1] यहां दिए गए ऐप्लिकेशन इंटेंट के हिसाब से तय किए गए सभी सार्वजनिक इंटेंट फ़िल्टर पैटर्न के लिए, इंटेंट हैंडलर के साथ एक या उससे ज़्यादा ऐप्लिकेशन या सेवा कॉम्पोनेंट को पहले से लोड करना ज़रूरी है.

3. सॉफ़्टवेयर

3.1. मैनेज किए जा रहे एपीआई के साथ काम करने की सुविधा

मैनेज किया गया Dalvik बाइटकोड, Android ऐप्लिकेशन के लिए मुख्य साधन है. Android ऐप्लिकेशन प्रोग्रामिंग इंटरफ़ेस (एपीआई), Android प्लैटफ़ॉर्म के इंटरफ़ेस का सेट है. इसे मैनेज किए जा रहे रनटाइम एनवायरमेंट में चलने वाले ऐप्लिकेशन के लिए उपलब्ध कराया जाता है.

डिवाइस पर लागू करने के तरीके:

• [C-0-1] Android SDK के ज़रिए एक्सपोज़ किए गए किसी भी दस्तावेज़ वाले एपीआई या अपस्ट्रीम Android सोर्स कोड में “@SystemApi” मार्कर के साथ सजाए गए किसी भी एपीआई के सभी दस्तावेज़ किए गए व्यवहारों के साथ-साथ, एपीआई को पूरी तरह से लागू करना ज़रूरी है.

• [C-0-2] TestApi एनोटेशन (@TestApi) से मार्क की गई सभी क्लास, मेथड, और उनसे जुड़े एलिमेंट के साथ काम करना चाहिए/उनका रखरखाव करना चाहिए.

• [C-0-3] मैनेज किए जा रहे किसी भी एपीआई को नहीं छोड़ना चाहिए, एपीआई इंटरफ़ेस या हस्ताक्षर में बदलाव नहीं करना चाहिए, दस्तावेज़ में बताए गए तरीके से काम नहीं करना चाहिए या कोई काम न करने वाला एपीआई शामिल नहीं करना चाहिए. हालांकि, अगर इस सुविधा के साथ काम करने की शर्तों में ऐसा करने की अनुमति दी गई है, तो ऐसा किया जा सकता है.

• [C-0-4] एपीआई को अब भी मौजूद रखना चाहिए और सही तरीके से काम करना चाहिए. भले ही, Android में एपीआई शामिल करने वाली कुछ हार्डवेयर सुविधाओं को हटा दिया गया हो. इस स्थिति के लिए ज़रूरी शर्तों के बारे में जानने के लिए, सेक्शन 7 देखें.

• [C-0-5] तीसरे पक्ष के ऐप्लिकेशन को ऐसे इंटरफ़ेस इस्तेमाल करने की अनुमति नहीं देनी चाहिए जिनमें SDK टूल नहीं है. ये इंटरफ़ेस, Java भाषा के पैकेज में मौजूद तरीकों और फ़ील्ड के तौर पर तय किए जाते हैं. ये पैकेज, AOSP के बूट क्लासपाथ में होते हैं और सार्वजनिक SDK टूल का हिस्सा नहीं होते. इसमें ऐसे एपीआई शामिल हैं जिन्हें @hide एनोटेशन से सजाया गया है, लेकिन @SystemAPI से नहीं, जैसा कि एसडीके दस्तावेज़ों में बताया गया है. साथ ही, इसमें निजी और पैकेज-निजी क्लास के सदस्य भी शामिल हैं.

• [C-0-6] यह ज़रूरी है कि हर ऐसे इंटरफ़ेस को, पाबंदी वाली उन ही सूचियों में शामिल किया जाए जिनमें AOSP में सही एपीआई लेवल की शाखा के लिए, prebuilts/runtime/appcompat/hiddenapi-flags.csv पाथ में मौजूद, 'पाबंदी' और 'पाबंदी वाली सूची' फ़्लैग की मदद से जानकारी दी गई है.

• [C-0-7] साइन किए गए कॉन्फ़िगरेशन के डाइनैमिक अपडेट मैकेनिज्म के साथ काम करना चाहिए, ताकि AOSP में मौजूद मौजूदा सार्वजनिक कुंजियों का इस्तेमाल करके, किसी भी APK में साइन किए गए कॉन्फ़िगरेशन को जोड़कर, SDK टूल के बाहर के इंटरफ़ेस को पाबंदी वाली सूची से हटाया जा सके.

  हालांकि, ये:

  • अगर कोई छिपा हुआ एपीआई मौजूद नहीं है या डिवाइस पर अलग तरीके से लागू किया गया है, तो छिपे हुए एपीआई को पाबंदी वाली सूची में डालें या उसे पाबंदी वाली सभी सूचियों से हटाएं.
  • अगर AOSP में पहले से कोई छिपा हुआ एपीआई मौजूद नहीं है, तो छिपे हुए एपीआई को पाबंदी वाली किसी भी सूची में जोड़ा जा सकता है.

नई ज़रूरी शर्तें लागू करना

• [C-0-8] यह ज़रूरी है कि डिवाइस पर, एपीआई लेवल 23 से पहले के वर्शन को टारगेट करने वाले ऐप्लिकेशन इंस्टॉल न किए जा सकें.

नई ज़रूरी शर्तों को खत्म करना

3.1.1. Android एक्सटेंशन

Android, किसी खास एपीआई लेवल के मैनेज किए जा रहे एपीआई के प्लैटफ़ॉर्म को बड़ा करने की सुविधा देता है. इसके लिए, उस एपीआई लेवल के लिए एक्सटेंशन वर्शन को अपडेट किया जाता है. अगर उस एपीआई लेवल के लिए एक्सटेंशन मौजूद हैं, तो android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) एपीआई, दिए गए apiLevel का एक्सटेंशन वर्शन दिखाता है.

Android डिवाइस पर लागू करने के लिए:

• [C-0-1] ऐप्लिकेशन को, शेयर की गई लाइब्रेरी ExtShared और सेवाओं ExtServices, दोनों के AOSP वर्शन को पहले से लोड करना चाहिए. ये वर्शन, हर एपीआई लेवल के लिए तय किए गए कम से कम वर्शन से ज़्यादा या उसके बराबर होने चाहिए. उदाहरण के लिए, Android 7.0 पर काम करने वाले डिवाइसों में, एपीआई लेवल 24 के कम से कम वर्शन 1 का इस्तेमाल करना ज़रूरी है.

• [C-0-2] यह फ़ंक्शन सिर्फ़ उस एक्सटेंशन वर्शन का नंबर दिखाए जो AOSP ने तय किया है.

• [C-0-3] यह ज़रूरी है कि एक्सटेंशन के उन सभी वर्शन के लिए एपीआई काम करें जो android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) के ज़रिए दिखाए जाते हैं. साथ ही, यह भी ज़रूरी है कि एपीआई ठीक उसी तरह काम करें जिस तरह मैनेज किए जा रहे अन्य एपीआई काम करते हैं. इसके लिए, सेक्शन 3.1 में दी गई ज़रूरी शर्तों का पालन करना होगा.

3.1.2. Android लाइब्रेरी

Apache HTTP क्लाइंट के बंद होने की वजह से, डिवाइस पर लागू होने वाले ये बदलाव होंगे:

• [C-0-1] org.apache.http.legacy लाइब्रेरी को बूटक्लॉसपैथ में नहीं डालना चाहिए.
• [C-0-2] ऐप्लिकेशन के क्लासपाथ में org.apache.http.legacy लाइब्रेरी को सिर्फ़ तब जोड़ना ज़रूरी है, जब ऐप्लिकेशन इनमें से किसी एक शर्त को पूरा करता हो:
  • एपीआई लेवल 28 या इससे पहले के वर्शन को टारगेट करता हो.
  • अपने मेनिफ़ेस्ट में यह एलान करता है कि उसे लाइब्रेरी की ज़रूरत है. इसके लिए, <uses-library> के android:name एट्रिब्यूट को org.apache.http.legacy पर सेट किया जाता है.

AOSP को लागू करने से ये ज़रूरी शर्तें पूरी होती हैं.

3.2. Soft API Compatibility

सेक्शन 3.1 में मौजूद मैनेज किए जा रहे एपीआई के अलावा, Android में सिर्फ़ रनटाइम के लिए एक अहम “सॉफ़्ट” एपीआई भी शामिल है. यह एपीआई, इंटेंट, अनुमतियों, और Android ऐप्लिकेशन के ऐसे ही अन्य पहलुओं के तौर पर काम करता है जिन्हें ऐप्लिकेशन को कंपाइल करते समय लागू नहीं किया जा सकता.

3.2.1. अनुमतियां

• [C-0-1] डिवाइस लागू करने वाले लोगों को, अनुमति के रेफ़रंस पेज में बताई गई अनुमति के सभी कॉन्स्टेंट का इस्तेमाल करना होगा और उन्हें लागू करना होगा. ध्यान दें कि सेक्शन 9 में, Android के सुरक्षा मॉडल से जुड़ी अन्य ज़रूरी शर्तें बताई गई हैं.

3.2.2. बिल्ड पैरामीटर

Android API में, android.os.Build क्लास पर कई कॉन्स्टेंट शामिल होते हैं. इनका मकसद, मौजूदा डिवाइस के बारे में बताना होता है.

• [C-0-1] डिवाइस पर लागू करने के लिए, एक जैसी और काम की वैल्यू देने के लिए, नीचे दी गई टेबल में इन वैल्यू के फ़ॉर्मैट पर अतिरिक्त पाबंदियां शामिल हैं. डिवाइस पर लागू करने के लिए, इनका पालन करना ज़रूरी है.

पैरामीटर	जानकारी
VERSION.RELEASE	फ़िलहाल चल रहे Android सिस्टम का वर्शन, ऐसे फ़ॉर्मैट में जिसे कोई भी व्यक्ति आसानी से पढ़ सकता है. इस फ़ील्ड में, Android 14 के लिए अनुमति वाली वर्शन स्ट्रिंग में बताई गई स्ट्रिंग वैल्यू में से कोई एक वैल्यू होनी चाहिए.
VERSION.SDK	फ़िलहाल चल रहे Android सिस्टम का वर्शन, तीसरे पक्ष के ऐप्लिकेशन कोड के ऐक्सेस किए जा सकने वाले फ़ॉर्मैट में. Android 14 के लिए, इस फ़ील्ड में पूर्णांक की वैल्यू 14_INT होनी चाहिए.
VERSION.SDK_INT	फ़िलहाल चल रहे Android सिस्टम का वर्शन, तीसरे पक्ष के ऐप्लिकेशन कोड के ऐक्सेस किए जा सकने वाले फ़ॉर्मैट में. Android 14 के लिए, इस फ़ील्ड में पूर्णांक की वैल्यू 14_INT होनी चाहिए.
VERSION.INCREMENTAL	डिवाइस लागू करने वाले व्यक्ति की चुनी गई वैल्यू, जो फ़िलहाल चल रहे Android सिस्टम के खास बिल्ड को, इंसान के पढ़ने लायक फ़ॉर्मैट में दिखाती है. इस वैल्यू का इस्तेमाल, असली उपयोगकर्ताओं के लिए उपलब्ध कराए गए अलग-अलग बिल्ड के लिए दोबारा नहीं किया जाना चाहिए. इस फ़ील्ड का आम तौर पर इस्तेमाल, यह बताने के लिए किया जाता है कि बिल्ड जनरेट करने के लिए, किस बिल्ड नंबर या सोर्स-कंट्रोल बदलाव आइडेंटिफ़ायर का इस्तेमाल किया गया था. इस फ़ील्ड की वैल्यू, प्रिंट किए जा सकने वाले सात बिट वाले ASCII के तौर पर कोड की जानी चाहिए. साथ ही, यह वैल्यू रेगुलर एक्सप्रेशन “^[^ :\/~]+$” से मेल खानी चाहिए.
बोर्ड	डिवाइस लागू करने वाले व्यक्ति की चुनी गई वैल्यू, जिसमें डिवाइस के इस्तेमाल किए गए खास इंटरनल हार्डवेयर की जानकारी होती है. यह जानकारी, इंसान के पढ़ने लायक फ़ॉर्मैट में होती है. इस फ़ील्ड का इस्तेमाल, डिवाइस को पावर देने वाले बोर्ड के खास वर्शन की जानकारी देने के लिए किया जा सकता है. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है. साथ ही, यह वैल्यू रेगुलर एक्सप्रेशन “^[a-zA-Z0-9_-]+$” से मेल खानी चाहिए.
ब्रैंड	यह वैल्यू, डिवाइस से जुड़े ब्रैंड के नाम को दिखाती है. यह नाम, असली उपयोगकर्ताओं को पता होता है. यह एट्रिब्यूट, लोगों के पढ़ने लायक फ़ॉर्मैट में होना चाहिए. साथ ही, इसमें डिवाइस के मैन्युफ़ैक्चरर या उस कंपनी के ब्रैंड का नाम होना चाहिए जिसका नाम डिवाइस के लिए मार्केटिंग में इस्तेमाल किया जाता है. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है. साथ ही, यह वैल्यू रेगुलर एक्सप्रेशन “^[a-zA-Z0-9_-]+$” से मैच करनी चाहिए.
SUPPORTED_ABIS	नेटिव कोड के निर्देश सेट (सीपीयू टाइप + एबीआई कॉन्वेंशन) का नाम. सेक्शन 3.3 देखें. नेटिव एपीआई के साथ काम करना.
SUPPORTED_32_BIT_ABIS	नेटिव कोड के निर्देश सेट (सीपीयू टाइप + एबीआई कॉन्वेंशन) का नाम. सेक्शन 3.3 देखें. नेटिव एपीआई के साथ काम करना.
SUPPORTED_64_BIT_ABIS	नेटिव कोड के दूसरे निर्देश सेट (सीपीयू टाइप + एबीआई कन्वेंशन) का नाम. सेक्शन 3.3 देखें. नेटिव एपीआई के साथ काम करना.
CPU_ABI	नेटिव कोड के निर्देश सेट (सीपीयू टाइप + एबीआई कॉन्वेंशन) का नाम. सेक्शन 3.3 देखें. नेटिव एपीआई के साथ काम करना.
CPU_ABI2	नेटिव कोड के दूसरे निर्देश सेट (सीपीयू टाइप + एबीआई कन्वेंशन) का नाम. सेक्शन 3.3 देखें. नेटिव एपीआई के साथ काम करना.
डिवाइस	डिवाइस लागू करने वाले व्यक्ति या कंपनी की चुनी गई वैल्यू. इसमें डिवाइस के हार्डवेयर की सुविधाओं और डिवाइस के इंडस्ट्रियल डिज़ाइन के कॉन्फ़िगरेशन की पहचान करने वाला डेवलपमेंट का नाम या कोड नेम होता है. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है. साथ ही, यह वैल्यू रेगुलर एक्सप्रेशन “^[a-zA-Z0-9_-]+$” से मेल खानी चाहिए. प्रॉडक्ट के लाइफ़टाइम के दौरान, डिवाइस का यह नाम नहीं बदलना चाहिए.
फ़िंगरप्रिंट	इस स्ट्रिंग से, इस बिल्ड की खास तौर पर पहचान की जाती है. यह किसी व्यक्ति के लिए आसानी से पढ़ा जा सकने वाला होना चाहिए. यह इस टेंप्लेट के मुताबिक होना चाहिए: $(BRAND)/$(PRODUCT)/     $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) उदाहरण के लिए: acme/myproduct/     mydevice:14/LMYXX/3359:userdebug/test-keys फ़िंगरप्रिंट में खाली सफ़ेद जगह वाले वर्ण नहीं होने चाहिए. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है.
हार्डवेयर	हार्डवेयर का नाम (कर्नल कमांड लाइन या /proc से). यह किसी व्यक्ति के लिए आसानी से पढ़ा जा सकने वाला होना चाहिए. इस फ़ील्ड की वैल्यू, 7-बिट ASCII के तौर पर कोड की जानी चाहिए. साथ ही, यह रेगुलर एक्सप्रेशन “^[a-zA-Z0-9_-]+$” से मेल खानी चाहिए.
होस्ट	यह एक ऐसी स्ट्रिंग होती है जो उस होस्ट की खास तौर पर पहचान करती है जिस पर बिल्ड बनाया गया था. यह स्ट्रिंग, आम तौर पर पढ़े जा सकने वाले फ़ॉर्मैट में होती है. इस फ़ील्ड के फ़ॉर्मैट के लिए कोई ज़रूरी शर्त नहीं है. हालांकि, यह शर्त ज़रूरी है कि यह शून्य या खाली स्ट्रिंग ("") न हो.
आईडी	डिवाइस लागू करने वाला व्यक्ति, किसी रिलीज़ के बारे में बताने के लिए, यह आइडेंटिफ़ायर चुनता है. यह आइडेंटिफ़ायर, आम तौर पर पढ़े जा सकने वाले फ़ॉर्मैट में होता है. यह फ़ील्ड, android.os.Build.VERSION.INCREMENTAL जैसा हो सकता है. हालांकि, यह ज़रूरी है कि इसकी वैल्यू, असली उपयोगकर्ताओं के लिए सॉफ़्टवेयर के बिल्ड के बीच अंतर करने के लिहाज़ से काम की हो. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है. साथ ही, यह वैल्यू रेगुलर एक्सप्रेशन “^[a-zA-Z0-9._-]+$” से मेल खानी चाहिए.
मैन्युफ़ैक्चरर	प्रॉडक्ट के ओरिजनल इक्विपमेंट मैन्युफ़ैक्चरर (OEM) का ट्रेड नेम. इस फ़ील्ड के फ़ॉर्मैट के लिए कोई ज़रूरी शर्त नहीं है. हालांकि, यह शर्त ज़रूरी है कि यह शून्य या खाली स्ट्रिंग ("") न हो. साथ ही, प्रॉडक्ट के लाइफ़टाइम के दौरान इस फ़ील्ड में बदलाव नहीं किया जाना चाहिए.
SOC_MANUFACTURER	प्रॉडक्ट में इस्तेमाल किए गए प्राइमरी सिस्टम ऑन चिप (एसओसी) के मैन्युफ़ैक्चरर का ट्रेड नेम. एक ही SoC मैन्युफ़ैक्चरर वाले डिवाइसों के लिए, एक ही कॉन्स्टेंट वैल्यू का इस्तेमाल किया जाना चाहिए. कृपया एसओसी मैन्युफ़ैक्चरर से पूछें कि इस्तेमाल करने के लिए कौनसा सही कॉन्स्टेंट है. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है. यह वैल्यू, रेगुलर एक्सप्रेशन “^([0-9A-Za-z ]+)” से मैच करनी चाहिए. साथ ही, यह वैल्यू व्हाइटस्पेस से शुरू या खत्म नहीं होनी चाहिए. यह वैल्यू “unknown” के बराबर नहीं होनी चाहिए. प्रॉडक्ट के लाइफ़टाइम के दौरान, इस फ़ील्ड में बदलाव नहीं किया जाना चाहिए.
SOC_MODEL	प्रॉडक्ट में इस्तेमाल किए गए चिप पर सिस्टम (SoC) के प्राइमरी मॉडल का नाम. एक ही एसओसी मॉडल वाले डिवाइसों को एक ही कॉन्स्टेंट वैल्यू का इस्तेमाल करना चाहिए. कृपया एसओसी मैन्युफ़ैक्चरर से पूछें कि इस्तेमाल करने के लिए सही कॉन्स्टेंट क्या है. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है. साथ ही, यह रेगुलर एक्सप्रेशन “^([0-9A-Za-z ._/+-]+)$” से मैच करनी चाहिए. यह वैल्यू, व्हाइटस्पेस से शुरू या खत्म नहीं होनी चाहिए. साथ ही, यह “unknown” के बराबर नहीं होनी चाहिए. प्रॉडक्ट के लाइफ़टाइम के दौरान, इस फ़ील्ड की वैल्यू में बदलाव नहीं किया जाना चाहिए.
MODEL	डिवाइस लागू करने वाले व्यक्ति की चुनी गई वैल्यू, जिसमें डिवाइस का नाम होता है, जैसा कि आखिरी उपयोगकर्ता को पता होता है. यह वही नाम होना चाहिए जिससे डिवाइस को मार्केट में लाया जाता है और असल उपयोगकर्ताओं को बेचा जाता है. इस फ़ील्ड के लिए, किसी खास फ़ॉर्मैट की ज़रूरत नहीं है. हालांकि, यह शर्त ज़रूरी है कि यह शून्य या खाली स्ट्रिंग ("") न हो. साथ ही, प्रॉडक्ट के लाइफ़टाइम के दौरान इस फ़ील्ड में कोई बदलाव नहीं होना चाहिए.
प्रॉडक्ट	डिवाइस लागू करने वाले व्यक्ति या कंपनी की चुनी गई वैल्यू. इसमें किसी खास प्रॉडक्ट (SKU) का डेवलपमेंट नाम या कोड नाम शामिल होता है. यह वैल्यू, एक ही ब्रैंड के लिए यूनीक होनी चाहिए. यह कोड, लोगों के लिए पढ़ने लायक होना चाहिए. हालांकि, यह ज़रूरी नहीं है कि इसे असली उपयोगकर्ता देखें. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है. साथ ही, यह वैल्यू रेगुलर एक्सप्रेशन “^[a-zA-Z0-9_-]+$” से मेल खानी चाहिए. प्रॉडक्ट के लाइफ़टाइम के दौरान, इस प्रॉडक्ट के नाम में बदलाव नहीं किया जाना चाहिए.
ODM_SKU	डिवाइस लागू करने वाला व्यक्ति, वैकल्पिक वैल्यू चुन सकता है. इसमें डिवाइस के खास कॉन्फ़िगरेशन को ट्रैक करने के लिए इस्तेमाल किया जाने वाला SKU (स्टॉक रखने की यूनिट) शामिल होता है. उदाहरण के लिए, डिवाइस बेचते समय उसमें शामिल किए गए किसी भी पेरिफ़रल. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है. साथ ही, यह वैल्यू रेगुलर एक्सप्रेशन ^([0-9A-Za-z.,_-]+)$ से मैच करनी चाहिए.
SERIAL	"UNKNOWN" दिखाना ज़रूरी है.
टैग	डिवाइस लागू करने वाले व्यक्ति के चुने गए टैग की सूची, जिसे कॉमा लगाकर अलग किया गया है. इससे, बिल्ड को और भी अलग किया जा सकता है. टैग को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है और यह रेगुलर एक्सप्रेशन “^[a-zA-Z0-9._-]+” से मैच करता है. साथ ही, इसमें Android प्लैटफ़ॉर्म के तीन सामान्य साइनिंग कॉन्फ़िगरेशन: रिलीज़-की, डेवलपर-की, और टेस्ट-की से जुड़ी कोई एक वैल्यू होनी चाहिए.
समय	यह वैल्यू, बिल्ड होने के समय का टाइमस्टैंप दिखाती है.
वाई-फ़ाई के टाइप के बारे में जानकारी	डिवाइस इंप्लीमेंटर की चुनी गई वैल्यू, जो बिल्ड के रनटाइम कॉन्फ़िगरेशन के बारे में बताती है. इस फ़ील्ड में, Android के तीन सामान्य रनटाइम कॉन्फ़िगरेशन में से किसी एक की वैल्यू होनी चाहिए: user, userdebug या eng.
उपयोगकर्ता	उस उपयोगकर्ता (या ऑटोमेटेड उपयोगकर्ता) का नाम या यूज़र आईडी जिसने बिल्ड जनरेट किया है. इस फ़ील्ड के फ़ॉर्मैट के लिए कोई ज़रूरी शर्त नहीं है. हालांकि, यह शर्त ज़रूरी है कि यह शून्य या खाली स्ट्रिंग ("") न हो.
SECURITY_PATCH	यह वैल्यू, किसी बिल्ड के सुरक्षा पैच के लेवल को दिखाती है. इससे यह पता चलना चाहिए कि बाइल्ड, Android के सार्वजनिक सुरक्षा बुलेटिन में बताई गई किसी भी समस्या से किसी भी तरह से सुरक्षित है. यह [YYYY-MM-DD] फ़ॉर्मैट में होना चाहिए. यह Android के सार्वजनिक सुरक्षा बुलेटिन या Android की सुरक्षा से जुड़ी सलाह में दी गई स्ट्रिंग से मेल खानी चाहिए. उदाहरण के लिए, "2015-11-01".
BASE_OS	इस वैल्यू से, बिल्ड के FINGERPRINT पैरामीटर की जानकारी मिलती है. यह वैल्यू, Android के सार्वजनिक सुरक्षा बुलेटिन में दिए गए पैच को छोड़कर, इस बिल्ड से पूरी तरह मेल खाती है. यह सही वैल्यू दिखानी चाहिए. अगर ऐसा कोई बिल्ड मौजूद नहीं है, तो खाली स्ट्रिंग ("") दिखाएं.
BOOTLOADER	डिवाइस लागू करने वाले व्यक्ति की चुनी गई वैल्यू, जो डिवाइस में इस्तेमाल किए गए खास इंटरनल बूटलोडर वर्शन की पहचान करती है. यह वैल्यू, इंसान के पढ़ने लायक फ़ॉर्मैट में होती है. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है. साथ ही, यह वैल्यू रेगुलर एक्सप्रेशन “^[a-zA-Z0-9._-]+$” से मेल खानी चाहिए.
getRadioVersion()	डिवाइस लागू करने वाले व्यक्ति की चुनी गई वैल्यू होनी चाहिए या वह वैल्यू दिखानी चाहिए. यह वैल्यू, डिवाइस में इस्तेमाल किए गए खास इंटरनल रेडियो/मॉडेम वर्शन की पहचान करती है. साथ ही, यह वैल्यू, इंसान के पढ़ने लायक फ़ॉर्मैट में होनी चाहिए. अगर किसी डिवाइस में कोई इंटरनल रेडियो/मॉडेम नहीं है, तो यह फ़ंक्शन NULL दिखाना चाहिए. इस फ़ील्ड की वैल्यू, 7-बिट ASCII के तौर पर कोड की जानी चाहिए. साथ ही, यह रेगुलर एक्सप्रेशन “^[a-zA-Z0-9._-,]+$” से मेल खानी चाहिए.
getSerial()	यह हार्डवेयर का सीरियल नंबर होना चाहिए. यह एक ही मॉडल और मैन्युफ़ैक्चरर के सभी डिवाइसों के लिए उपलब्ध और यूनीक होना चाहिए. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है. साथ ही, यह वैल्यू रेगुलर एक्सप्रेशन “^[a-zA-Z0-9]+$” से मेल खानी चाहिए.

3.2.3. इंटेंट की कंपैटिबिलिटी

3.2.3.1. ऐप्लिकेशन के सामान्य इंटेंट

Android इंटेंट की मदद से, ऐप्लिकेशन कॉम्पोनेंट, अन्य Android कॉम्पोनेंट से फ़ंक्शन का अनुरोध कर सकते हैं. Android अपस्ट्रीम प्रोजेक्ट में उन ऐप्लिकेशन की सूची शामिल होती है जो सामान्य कार्रवाइयां करने के लिए, कई इंटेंट पैटर्न लागू करते हैं.

डिवाइस पर लागू करने के तरीके:

• [C-SR-1] हमारा सुझाव है कि आप यहां दिए गए ऐप्लिकेशन इंटेंट के हिसाब से तय किए गए सभी सार्वजनिक इंटेंट फ़िल्टर पैटर्न के लिए, एक या उससे ज़्यादा ऐप्लिकेशन या सेवा कॉम्पोनेंट को इंटेंट हैंडलर के साथ पहले से लोड करें. साथ ही, एसडीके में बताए गए इन सामान्य ऐप्लिकेशन इंटेंट के लिए, डेवलपर की उम्मीदों के मुताबिक काम करें.

हर तरह के डिवाइस के लिए, ऐप्लिकेशन के ज़रूरी इंटेंट के बारे में जानने के लिए, कृपया सेक्शन 2 देखें.

3.2.3.2. इंटेंट रिज़ॉल्यूशन

• [C-0-1] Android एक एक्सटेंसिबल प्लैटफ़ॉर्म है. इसलिए, डिवाइस पर लागू होने वाले सिस्टम को, सेक्शन 3.2.3.1 में बताए गए हर इंटेंट पैटर्न को तीसरे पक्ष के ऐप्लिकेशन से बदलने की अनुमति देनी चाहिए. हालांकि, सेटिंग को बदलने की अनुमति नहीं दी जानी चाहिए. Android के ओपन सोर्स वर्शन में, डिफ़ॉल्ट रूप से इसकी अनुमति होती है.

• [C-0-2] डिवाइस लागू करने वाले लोगों को, सिस्टम ऐप्लिकेशन के इन इंटेंट पैटर्न के इस्तेमाल के लिए खास विशेषाधिकार नहीं देने चाहिए. इसके अलावा, तीसरे पक्ष के ऐप्लिकेशन को इन पैटर्न से बाइंड करने और उनका कंट्रोल लेने से भी नहीं रोकना चाहिए. इस पाबंदी में, “चुने गए” उपयोगकर्ता इंटरफ़ेस को बंद करना शामिल है. हालांकि, इसमें और भी चीज़ें शामिल हो सकती हैं. इस इंटरफ़ेस की मदद से, उपयोगकर्ता एक ही इंटेंट पैटर्न को मैनेज करने वाले कई ऐप्लिकेशन में से किसी एक को चुन सकता है.

• [C-0-3] डिवाइस पर लागू करने के लिए, उपयोगकर्ताओं को यूज़र इंटरफ़ेस देना ज़रूरी है, ताकि वे इंटेंट के लिए डिफ़ॉल्ट गतिविधि में बदलाव कर सकें.

• हालांकि, डिवाइस पर लागू होने पर, कुछ खास यूआरआई पैटर्न (जैसे, http://play.google.com) के लिए डिफ़ॉल्ट गतिविधियां दी जा सकती हैं. ऐसा तब होता है, जब डिफ़ॉल्ट गतिविधि, डेटा यूआरआई के लिए ज़्यादा सटीक एट्रिब्यूट देती है. उदाहरण के लिए, डेटा यूआरआई “http://www.android.com” की जानकारी देने वाला इंटेंट फ़िल्टर पैटर्न, “http://” के लिए ब्राउज़र के मुख्य इंटेंट पैटर्न से ज़्यादा सटीक होता है.

Android में तीसरे पक्ष के ऐप्लिकेशन के लिए भी एक तरीका शामिल है. इससे वेब यूआरआई के कुछ खास इंटेंट के लिए, आधिकारिक डिफ़ॉल्ट ऐप्लिकेशन लिंक करने का तरीका तय किया जा सकता है. जब किसी ऐप्लिकेशन के इंटेंट फ़िल्टर पैटर्न में, आधिकारिक एलान किए जाते हैं, तो डिवाइस पर ये काम किए जाते हैं:

• [C-0-4] डिजिटल एसेट लिंक की खास जानकारी में बताए गए पुष्टि करने के चरणों को पूरा करके, किसी भी इंटेंट फ़िल्टर की पुष्टि करना ज़रूरी है. ये चरण, अपस्ट्रीम Android Open Source Project में पैकेज मैनेजर ने लागू किए हैं.
• [C-0-5] ऐप्लिकेशन के इंस्टॉल होने के दौरान, इंटेंट फ़िल्टर की पुष्टि की कोशिश करनी चाहिए. साथ ही, पुष्टि हो चुके सभी यूआरआई इंटेंट फ़िल्टर को उनके यूआरआई के लिए डिफ़ॉल्ट ऐप्लिकेशन हैंडलर के तौर पर सेट करना चाहिए.
• अगर यूआरआई की पुष्टि हो जाती है, लेकिन अन्य यूआरआई फ़िल्टर की पुष्टि नहीं हो पाती है, तो यूआरआई के लिए डिफ़ॉल्ट ऐप्लिकेशन हैंडलर के तौर पर, यूआरआई इंटेंट फ़िल्टर सेट किए जा सकते हैं. अगर किसी डिवाइस पर ऐसा किया जाता है, तो उसे सेटिंग मेन्यू में, उपयोगकर्ता के लिए हर यूआरआई पैटर्न के हिसाब से बदलाव करना होगा.
• उपयोगकर्ता को सेटिंग में, हर ऐप्लिकेशन के लिए ऐप्लिकेशन लिंक के कंट्रोल देने होंगे. ये कंट्रोल इस तरह होने चाहिए:
  • [C-0-6] उपयोगकर्ता को किसी ऐप्लिकेशन के लिए, डिफ़ॉल्ट रूप से लिंक खुलने के व्यवहार को पूरी तरह से बदलने की अनुमति होनी चाहिए. जैसे: हमेशा खोलें, हमेशा पूछें या कभी न खोलें. यह सभी संभावित यूआरआई इंटेंट फ़िल्टर पर समान रूप से लागू होना चाहिए.
  • [C-0-7] उपयोगकर्ता को संभावित यूआरआई इंटेंट फ़िल्टर की सूची दिखनी चाहिए.
  • डिवाइस पर लागू करने पर, उपयोगकर्ता को हर इंटेंट फ़िल्टर के आधार पर, पुष्टि किए गए कुछ खास उम्मीदवार यूआरआई इंटेंट फ़िल्टर को बदलने की सुविधा मिल सकती है.
  • [C-0-8] डिवाइस पर लागू करने की सुविधा, उपयोगकर्ताओं को कुछ खास यूआरआई इंटेंट फ़िल्टर देखने और उन्हें बदलने की अनुमति देनी चाहिए. ऐसा तब ज़रूरी है, जब डिवाइस पर लागू करने की सुविधा से कुछ खास यूआरआई इंटेंट फ़िल्टर की पुष्टि हो जाए, जबकि कुछ अन्य फ़िल्टर की पुष्टि न हो पाए.

3.2.3.3. इंटेंट नेमस्पेस

• [C-0-1] डिवाइस पर लागू किए जाने वाले किसी भी Android कॉम्पोनेंट में, ऐसा कोई कॉम्पोनेंट शामिल नहीं होना चाहिए जो android.* या com.android.* नेमस्पेस में ACTION, CATEGORY या किसी अन्य मुख्य स्ट्रिंग का इस्तेमाल करके, किसी नए इंटेंट या ब्रॉडकास्ट इंटेंट पैटर्न को लागू करता हो.
• [C-0-2] डिवाइस लागू करने वाले लोगों को ऐसे किसी भी Android कॉम्पोनेंट को शामिल नहीं करना चाहिए जो किसी दूसरे संगठन के पैकेज स्पेस में, ACTION, CATEGORY या किसी अन्य मुख्य स्ट्रिंग का इस्तेमाल करके, किसी नए इंटेंट या ब्रॉडकास्ट इंटेंट पैटर्न को लागू करता हो.
• [C-0-3] डिवाइस लागू करने वाले लोगों को सेक्शन 3.2.3.1 में दिए गए किसी भी इंटेंट पैटर्न में बदलाव नहीं करना चाहिए या उसे बड़ा नहीं करना चाहिए.
• डिवाइस पर लागू करने के लिए, ऐसे इंटेंट पैटर्न शामिल किए जा सकते हैं जिनमें नेमस्पेस का इस्तेमाल किया गया हो और जो साफ़ तौर पर उनके संगठन से जुड़े हों. यह पाबंदी, सेक्शन 3.6 में Java भाषा की क्लास के लिए बताई गई पाबंदी से मिलती-जुलती है.

3.2.3.4. ब्रॉडकास्ट इंटेंट

तीसरे पक्ष के ऐप्लिकेशन, कुछ इंटेंट ब्रॉडकास्ट करने के लिए प्लैटफ़ॉर्म पर भरोसा करते हैं, ताकि उन्हें हार्डवेयर या सॉफ़्टवेयर एनवायरमेंट में हुए बदलावों के बारे में सूचना मिल सके.

डिवाइस पर लागू करने के तरीके:

• [C-0-1] SDK टूल के दस्तावेज़ में बताए गए सिस्टम इवेंट के जवाब में, यहां दी गई सूची में शामिल सार्वजनिक ब्रॉडकास्ट इंटेंट को ब्रॉडकास्ट करना ज़रूरी है. ध्यान दें कि यह शर्त, सेक्शन 3.5 के मुताबिक है. ऐसा इसलिए है, क्योंकि बैकग्राउंड में काम करने वाले ऐप्लिकेशन से जुड़ी सीमा के बारे में एसडीके दस्तावेज़ में भी बताया गया है. साथ ही, कुछ ब्रॉडकास्ट इंटेंट, हार्डवेयर के साथ काम करने की शर्त पर निर्भर होते हैं. अगर डिवाइस में ज़रूरी हार्डवेयर मौजूद है, तो उसे इंटेंट ब्रॉडकास्ट करने होंगे और SDK टूल के दस्तावेज़ के मुताबिक काम करना होगा.

3.2.3.5. शर्तों के हिसाब से ऐप्लिकेशन इंटेंट

Android में ऐसी सेटिंग शामिल हैं जिनकी मदद से, उपयोगकर्ता आसानी से डिफ़ॉल्ट ऐप्लिकेशन चुन सकते हैं. जैसे, होम स्क्रीन या एसएमएस के लिए.

जहां भी ज़रूरी हो, डिवाइस पर लागू करने के लिए, सेटिंग का एक जैसा मेन्यू उपलब्ध कराना ज़रूरी है. साथ ही, यह मेन्यू, एसडीके दस्तावेज़ में बताए गए इंटेंट फ़िल्टर पैटर्न और एपीआई के तरीकों के साथ काम करना चाहिए.

अगर डिवाइस पर लागू करने की रिपोर्ट में android.software.home_screen दिखता है, तो:

• [C-1-1] होम स्क्रीन पर ऐप्लिकेशन का डिफ़ॉल्ट सेटिंग मेन्यू दिखाने के लिए, android.settings.HOME_SETTINGS के इंटेंट का पालन करना ज़रूरी है.

अगर डिवाइस पर लागू करने की रिपोर्ट में android.hardware.telephony.calling दिखता है, तो:

• [C-2-1] डिफ़ॉल्ट एसएमएस ऐप्लिकेशन बदलने के लिए डायलॉग दिखाने के लिए, android.provider.Telephony.ACTION_CHANGE_DEFAULT इंटेंट को कॉल करने वाला सेटिंग मेन्यू ज़रूर उपलब्ध कराएं.

• [C-2-2] उपयोगकर्ता को डिफ़ॉल्ट फ़ोन ऐप्लिकेशन बदलने की अनुमति देने के लिए, डायलॉग दिखाने के android.telecom.action.CHANGE_DEFAULT_DIALER Intent का पालन करना ज़रूरी है.

  • आने वाले और किए जाने वाले कॉल के लिए, उपयोगकर्ता के चुने गए डिफ़ॉल्ट Phone ऐप्लिकेशन के यूज़र इंटरफ़ेस (यूआई) का इस्तेमाल करना ज़रूरी है. हालांकि, आपातकालीन कॉल के लिए, डिवाइस में पहले से इंस्टॉल Phone ऐप्लिकेशन का इस्तेमाल किया जाएगा.

• [C-2-3] android.telecom.action.CHANGE_PHONE_ACCOUNTS के मकसद को पूरा करना ज़रूरी है, ताकि उपयोगकर्ता PhoneAccounts से जुड़े ConnectionServices को कॉन्फ़िगर कर सके. साथ ही, वह डिफ़ॉल्ट PhoneAccount को भी कॉन्फ़िगर कर सके. टेलीकम्यूनिकेशन सेवा देने वाली कंपनी, आउटगोइंग कॉल करने के लिए इस डिफ़ॉल्ट PhoneAccount का इस्तेमाल करेगी. AOSP में इस ज़रूरी शर्त को पूरा करने के लिए, "कॉल" सेटिंग मेन्यू में "कॉल करने के लिए इस्तेमाल किए जाने वाले खाते का विकल्प" मेन्यू शामिल किया गया है.

• [C-2-4] android.app.role.CALL_REDIRECTION भूमिका वाले ऐप्लिकेशन के लिए, android.telecom.CallRedirectionService की अनुमति ज़रूर होनी चाहिए.

• [C-2-5] उपयोगकर्ता को ऐसा ऐप्लिकेशन चुनने की सुविधा देनी चाहिए जिसमें android.app.role.CALL_REDIRECTION की भूमिका हो.

• [C-2-6] ऐप्लिकेशन को android.intent.action.SENDTO और android.intent.action.VIEW इंटेंट का पालन करना चाहिए. साथ ही, एसएमएस भेजने/दिखाने के लिए कोई गतिविधि उपलब्ध करानी चाहिए.

• [C-SR-1] हमारा सुझाव है कि आप पहले से लोड किए गए डायलर ऐप्लिकेशन के साथ, android.intent.action.ANSWER, android.intent.action.CALL, android.intent.action.CALL_BUTTON, android.intent.action.VIEW & android.intent.action.DIAL इंटेंट का इस्तेमाल करें. यह ऐप्लिकेशन इन इंटेंट को मैनेज कर सकता है और SDK टूल में बताए गए तरीके से इनका जवाब दे सकता है.

अगर डिवाइस पर लागू करने की रिपोर्ट में android.hardware.nfc.hce दिखता है, तो:

• [C-3-1] टच किए बिना पेमेंट करने के लिए, डिफ़ॉल्ट ऐप्लिकेशन सेटिंग मेन्यू दिखाने के लिए, android.settings.NFC_PAYMENT_SETTINGS के इंटेंट का पालन करना ज़रूरी है.
• [C-3-2] android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT के इंटेंट का पालन करना ज़रूरी है, ताकि एक ऐसी ऐक्टिविटी दिखाई जा सके जो उपयोगकर्ता से किसी कैटगरी के लिए डिफ़ॉल्ट कार्ड इम्यूलेशन सेवा बदलने के लिए कहे. इस बारे में SDK टूल में बताया गया है.

अगर डिवाइस पर लागू करने की रिपोर्ट में android.hardware.nfc दिखता है, तो:

• [C-4-1] SDK में बताए गए इन इंटेंट के लिए डेवलपर की उम्मीदों को पूरा करने वाली गतिविधि दिखाने के लिए, इन इंटेंट android.nfc.action.NDEF_DISCOVERED, android.nfc.action.TAG_DISCOVERED & android.nfc.action.TECH_DISCOVERED का पालन करना ज़रूरी है.

अगर डिवाइस पर लागू करने की रिपोर्ट में android.hardware.bluetooth दिखता है, तो:

• [C-5-1] ‘android.bluetooth.adapter.action.REQUEST_ENABLE’ के ज़रिए भेजे गए इंटेंट का पालन करना ज़रूरी है. साथ ही, उपयोगकर्ता को ब्लूटूथ चालू करने की अनुमति देने के लिए, सिस्टम गतिविधि दिखानी होगी.
• [C-5-2] ऐप्लिकेशन को ‘android.bluetooth.adapter.action.REQUEST_DISCOVERABLE’ इंटेंट का पालन करना चाहिए. साथ ही, वह सिस्टम गतिविधि दिखाए जो डिस्कवर किए जा सकने वाले मोड का अनुरोध करती है.

अगर डिवाइस पर डीएनडी मोड की सुविधा काम करती है, तो:

• [C-6-1] ऐसी ऐक्टिविटी लागू करना ज़रूरी है जो इंटेंट ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS का जवाब दे. UI_MODE_TYPE_NORMAL के साथ लागू करने के लिए, यह ज़रूरी है कि यह ऐसी ऐक्टिविटी हो जिसमें उपयोगकर्ता, ऐप्लिकेशन को डीएनडी नीति के कॉन्फ़िगरेशन का ऐक्सेस दे या न दे.

अगर डिवाइस पर, उपयोगकर्ताओं को तीसरे पक्ष के इनपुट तरीकों का इस्तेमाल करने की अनुमति है, तो वे:

• [C-7-1] android.settings.INPUT_METHOD_SETTINGS के इंटेंट के जवाब में, तीसरे पक्ष के इनपुट तरीकों को जोड़ने और कॉन्फ़िगर करने के लिए, उपयोगकर्ता के ऐक्सेस की सुविधा देने वाली सुविधा देना ज़रूरी है.

अगर डिवाइस पर तीसरे पक्ष की सुलभता सेवाएं काम करती हैं, तो:

• [C-8-1] ऐप्लिकेशन में, पहले से लोड की गई सुलभता सेवाओं के साथ-साथ तीसरे पक्ष की सुलभता सेवाओं को चालू और बंद करने के लिए, उपयोगकर्ता के लिए ऐक्सेस करने लायक तरीका उपलब्ध कराना android.settings.ACCESSIBILITY_SETTINGS ज़रूरी है.

अगर डिवाइस में वाई-फ़ाई आसानी से कनेक्ट करने की सुविधा शामिल है और तीसरे पक्ष के ऐप्लिकेशन के लिए इस सुविधा का ऐक्सेस दिया गया है, तो:

• [C-9-1] SDK के दस्तावेज़ में बताए गए तरीके के मुताबिक, Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI Intent API लागू करना ज़रूरी है.

अगर डिवाइस में डेटा बचाने वाला मोड उपलब्ध है, तो:

• [C-10-1] सेटिंग में ऐसा यूज़र इंटरफ़ेस होना चाहिए जो Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS के इंटेंट को मैनेज करता हो. इससे उपयोगकर्ता, अनुमति वाली सूची में ऐप्लिकेशन जोड़ सकते हैं या उससे ऐप्लिकेशन हटा सकते हैं.

अगर डिवाइस में डेटा बचाने वाला मोड उपलब्ध नहीं है, तो:

• [C-11-1] ऐप्लिकेशन में ऐसी गतिविधि होनी चाहिए जो Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS इंटेंट को मैनेज करती हो. हालांकि, इसे बिना किसी कार्रवाई के लागू किया जा सकता है.

अगर डिवाइस में android.hardware.camera.any के ज़रिए कैमरे के साथ काम करने की सुविधा का एलान किया गया है, तो:

• [C-12-3] SDK दस्तावेज़ में बताए गए इनटेंट MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE, और MediaStore.ACTION_VIDEO_CAPTURE को मैनेज करना ज़रूरी है. साथ ही, पहले से इंस्टॉल किए गए Android ऐप्लिकेशन को सिर्फ़ इन इनटेंट को मैनेज करने की अनुमति देनी होगी.

अगर डिवाइस पर लागू करने की रिपोर्ट में android.software.device_admin दिखता है, तो:

• [C-13-1] उपयोगकर्ता को सिस्टम में डिवाइस एडमिन जोड़ने (या उसे अस्वीकार करने की अनुमति देने) के लिए, यूज़र इंटरफ़ेस (यूआई) को शुरू करने के लिए, इंटेंट android.app.action.ADD_DEVICE_ADMIN का पालन करना ज़रूरी है.

• [C-13-2] ऐप्लिकेशन को इन इंटेंट का पालन करना होगा: android.app.action.PROVISION_MANAGED_PROFILE, android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD, android.app.action.SET_NEW_PASSWORD & android.app.action.START_ENCRYPTION. साथ ही, इसमें ऐसी गतिविधि होनी चाहिए जो इन इंटेंट को पूरा करती हो. इस बारे में यहां SDK में बताया गया है.

अगर डिवाइस पर लागू किए गए ऐप्लिकेशन में android.software.autofill फ़ीचर फ़्लैग का एलान किया जाता है, तो:

• [C-14-1] AutofillService और AutofillManager एपीआई को पूरी तरह से लागू करना ज़रूरी है. साथ ही, android.settings.REQUEST_SET_AUTOFILL_SERVICE इंटेंट का पालन करना ज़रूरी है, ताकि उपयोगकर्ता को जानकारी अपने-आप भरने की सुविधा चालू और बंद करने के लिए, ऐप्लिकेशन की डिफ़ॉल्ट सेटिंग मेन्यू दिखाया जा सके. साथ ही, उपयोगकर्ता के लिए जानकारी अपने-आप भरने की डिफ़ॉल्ट सेवा बदली जा सके.

अगर डिवाइस में पहले से इंस्टॉल किया गया कोई ऐप्लिकेशन है या तीसरे पक्ष के ऐप्लिकेशन को इस्तेमाल के आंकड़े ऐक्सेस करने की अनुमति देनी है, तो:

• [C-SR-2] ऐप्लिकेशन के लिए, android.permission.PACKAGE_USAGE_STATS अनुमति का एलान करने वाले ऐप्लिकेशन के लिए, android.settings.ACTION_USAGE_ACCESS_SETTINGS इंटेंट के जवाब में, इस्तेमाल के आंकड़ों का ऐक्सेस देने या रद्द करने के लिए, उपयोगकर्ता के ऐक्सेस करने की सुविधा देने का सुझाव दिया जाता है.

अगर डिवाइस पर लागू किए गए तरीकों से, पहले से इंस्टॉल किए गए ऐप्लिकेशन के साथ-साथ किसी भी ऐप्लिकेशन को इस्तेमाल के आंकड़े ऐक्सेस करने से रोकना है, तो:

• [C-15-1] ऐप्लिकेशन में अब भी ऐसी ऐक्टिविटी होनी चाहिए जो android.settings.ACTION_USAGE_ACCESS_SETTINGS इंटेंट पैटर्न को मैनेज करती हो. हालांकि, इसे बिना किसी कार्रवाई के लागू करना ज़रूरी है. इसका मतलब है कि ऐप्लिकेशन में ऐसा व्यवहार होना चाहिए जो उपयोगकर्ता को ऐक्सेस देने से अस्वीकार करने पर होता है.

अगर डिवाइस पर, सेटिंग में AutofillService_passwordsActivity से तय की गई गतिविधियों के लिंक या इसी तरह के किसी तरीके से उपयोगकर्ता के पासवर्ड के लिंक दिखाए जाते हैं, तो:

• [C-16-1] यह ज़रूरी है कि इंस्टॉल की गई सभी ऑटोमैटिक भरने की सेवाओं के लिए, ऐसे लिंक दिखाए जाएं.

अगर डिवाइस पर VoiceInteractionService काम करता है और एक से ज़्यादा ऐप्लिकेशन इस एपीआई का इस्तेमाल करते हैं, तो:

• [C-18-1] वॉइस इनपुट और असिस्ट के लिए, डिफ़ॉल्ट ऐप्लिकेशन सेटिंग मेन्यू दिखाने के android.settings.ACTION_VOICE_INPUT_SETTINGS के इंटेंट का पालन करना ज़रूरी है.

अगर डिवाइस पर लागू की गई सुविधाओं में android.hardware.audio.output की जानकारी दी गई है, तो:

• [C-SR-3] हमारा सुझाव है कि आप android.intent.action.TTS_SERVICE, android.speech.tts.engine.INSTALL_TTS_DATA & android.speech.tts.engine.GET_SAMPLE_TEXT इंटेंट का इस्तेमाल करें. इन इंटेंट के लिए, SDK में यहां बताई गई गतिविधि की मदद से इन इंटेंट को पूरा किया जा सकता है.

Android में इंटरैक्टिव स्क्रीनसेवर की सुविधा शामिल है. इसे पहले ड्रीम्स कहा जाता था. स्क्रीन सेवर की मदद से, उपयोगकर्ता उन ऐप्लिकेशन के साथ इंटरैक्ट कर सकते हैं जो पावर सोर्स से कनेक्ट किए गए डिवाइस पर, स्क्रीन बंद होने या डेस्क डॉक में डॉक किए जाने पर चालू रहते हैं. डिवाइस पर लागू करना:

• इसमें स्क्रीन सेवर की सुविधा शामिल होनी चाहिए. साथ ही, उपयोगकर्ताओं को android.settings.DREAM_SETTINGS इंटेंट के जवाब में, स्क्रीन सेवर को कॉन्फ़िगर करने के लिए सेटिंग का विकल्प भी देना चाहिए.

नई ज़रूरी शर्तें लागू करना

अगर डिवाइस पर लागू करने की प्रोसेस की रिपोर्ट में android.hardware.nfc.uicc या android.hardware.nfc.ese दिखता है, तो:

• [C-19-1] NfcAdapter.ACTION_TRANSACTION_DETECTED Intent API को लागू करना ज़रूरी है. इसे “EVT_TRANSACTION” के तौर पर लागू किया जाना चाहिए, जैसा कि GSM Association की तकनीकी जानकारी देने वाली खास जानकारी TS.26 - NFC हैंडसेट की ज़रूरी शर्तों में बताया गया है.

नई ज़रूरी शर्तें खत्म करना

3.2.4. सेकंडरी/एक से ज़्यादा डिसप्ले पर की गई गतिविधियां

अगर डिवाइस पर एक से ज़्यादा डिसप्ले पर सामान्य Android गतिविधियां लॉन्च करने की अनुमति है, तो:

• [C-1-1] android.software.activities_on_secondary_displays फ़ीचर फ़्लैग को सेट करना ज़रूरी है.
• [C-1-2] यह ज़रूरी है कि ऐप्लिकेशन, मुख्य डिसप्ले पर चल रही ऐक्टिविटी की तरह ही एपीआई के साथ काम करता हो.
• [C-1-3] अगर नई गतिविधि को ActivityOptions.setLaunchDisplayId() एपीआई के ज़रिए टारगेट डिसप्ले तय किए बिना लॉन्च किया जाता है, तो नई गतिविधि को उसी डिसप्ले पर ले जाना चाहिए जिस पर गतिविधि शुरू की गई थी.
• [C-1-4] Display.FLAG_PRIVATE फ़्लैग वाले डिसप्ले को हटाने पर, सभी गतिविधियों को मिटाना ज़रूरी है.
• [C-1-5] जब डिवाइस को सुरक्षित लॉक स्क्रीन से लॉक किया गया हो, तब सभी स्क्रीन पर कॉन्टेंट को सुरक्षित तरीके से छिपाना ज़रूरी है. ऐसा तब तक करना होगा, जब तक कि ऐप्लिकेशन Activity#setShowWhenLocked() एपीआई का इस्तेमाल करके, लॉक स्क्रीन पर सबसे ऊपर दिखने के लिए ऑप्ट इन न कर दे.
• उसमें android.content.res.Configuration होना चाहिए, जो उस डिसप्ले से जुड़ा हो, ताकि उसे दिखाया जा सके, सही तरीके से काम किया जा सके, और अगर कोई गतिविधि सेकंडरी डिसप्ले पर लॉन्च की जाती है, तो उस डिसप्ले के साथ काम किया जा सके.

अगर डिवाइस पर सेकंडरी डिसप्ले पर सामान्य Android गतिविधियां शुरू करने की अनुमति है और सेकंडरी डिसप्ले पर android.view.Display.FLAG_PRIVATE फ़्लैग है, तो:

• [C-3-1] सिर्फ़ उस डिसप्ले, सिस्टम, और गतिविधियों का मालिक ही उसे लॉन्च कर सकता है जो पहले से उस डिसप्ले पर मौजूद हैं. कोई भी व्यक्ति उस डिसप्ले पर ऐप्लिकेशन लॉन्च कर सकता है जिसमें android.view.Display.FLAG_PUBLIC फ़्लैग मौजूद हो.

3.3. नेटिव एपीआई के साथ काम करना

नेटिव कोड के साथ काम करना मुश्किल है. इस वजह से, डिवाइस लागू करने वाले लोग:

• [C-SR-1] हमारा सुझाव है कि आप ऊपर दी गई सूची में मौजूद लाइब्रेरी का इस्तेमाल करें. ये लाइब्रेरी, Android Open Source Project से ली गई हैं.

3.3.1. ऐप्लिकेशन बाइनरी इंटरफ़ेस

मैनेज किया गया Dalvik बाइटकोड, ऐप्लिकेशन .apk फ़ाइल में दिए गए नेटिव कोड को कॉल कर सकता है. यह कोड, डिवाइस के हार्डवेयर आर्किटेक्चर के हिसाब से, ELF .so फ़ाइल के तौर पर कंपाइल किया जाता है. नेटिव कोड, प्रोसेसर की टेक्नोलॉजी पर काफ़ी निर्भर करता है. इसलिए, Android NDK में Android कई ऐप्लिकेशन बाइनरी इंटरफ़ेस (एबीआई) तय करता है.

डिवाइस पर लागू करने के तरीके:

• [C-0-1] यह एक या उससे ज़्यादा तय किए गए Android NDK ABIs के साथ काम करना चाहिए.
• [C-0-2] इसमें, मैनेज किए जा रहे एनवायरमेंट में चल रहे कोड के लिए, नेटिव कोड को कॉल करने की सुविधा शामिल होनी चाहिए. इसके लिए, स्टैंडर्ड Java नेटिव इंटरफ़ेस (JNI) के सेमेटिक्स का इस्तेमाल किया जाना चाहिए.
• [C-0-3] यह ज़रूरी है कि यह नीचे दी गई सूची में मौजूद हर ज़रूरी लाइब्रेरी के साथ, सोर्स के साथ काम करे (यानी हेडर के साथ काम करे) और एबीआई के लिए बाइनरी के साथ काम करे.
• [C-0-5] android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS, और android.os.Build.SUPPORTED_64_BIT_ABIS पैरामीटर की मदद से, डिवाइस पर काम करने वाले नेटिव ऐप्लिकेशन बाइनरी इंटरफ़ेस (एबीआई) की सटीक जानकारी देनी चाहिए. हर पैरामीटर में, एबीआई की सूची को कॉमा लगाकर अलग-अलग किया गया है. यह सूची, सबसे ज़्यादा से लेकर सबसे कम प्राथमिकता वाले एबीआई के क्रम में होती है.

• [C-0-6] ऊपर दिए गए पैरामीटर की मदद से, एबीआई की इस सूची के सबसेट की रिपोर्ट देना ज़रूरी है. साथ ही, सूची में शामिल नहीं किए गए किसी भी एबीआई की रिपोर्ट नहीं देनी चाहिए.

  • armeabi (NDK अब इसे टारगेट के तौर पर इस्तेमाल नहीं करता)
  • armeabi-v7a
  • arm64-v8a
  • x86
  • x86-64

• [C-0-7] नेटिव एपीआई उपलब्ध कराने वाली इन सभी लाइब्रेरी को, नेटिव कोड वाले ऐप्लिकेशन के लिए उपलब्ध कराना ज़रूरी है:

  • libaaudio.so (AAudio नेटिव ऑडियो सपोर्ट)
  • libamidi.so (नेटिव MIDI की सुविधा, अगर सेक्शन 5.9 में बताए गए तरीके के मुताबिक android.software.midi की सुविधा का दावा किया गया है)
  • libandroid.so (नेटिव Android गतिविधि के लिए सहायता)
  • libc (C लाइब्रेरी)
  • libcamera2ndk.so
  • libdl (डाइनैमिक लिंकर)
  • libEGL.so (नेटिव OpenGL सरफ़ेस मैनेजमेंट)
  • libGLESv1_CM.so (OpenGL ES 1.x)
  • libGLESv2.so (OpenGL ES 2.0)
  • libGLESv3.so (OpenGL ES 3.x)
  • libicui18n.so
  • libicuuc.so
  • libjnigraphics.so
  • liblog (Android लॉगिंग)
  • libmediandk.so (नेटिव मीडिया एपीआई के लिए सहायता)
  • libm (गणित लाइब्रेरी)
  • libneuralnetworks.so (Neural Networks API)
  • libOpenMAXAL.so (OpenMAX AL 1.0.1 के साथ काम करता है)
  • libOpenSLES.so (OpenSL ES 1.0.1 ऑडियो की सुविधा)
  • libRS.so
  • libstdc++ (C++ के लिए कम से कम सहायता)
  • libvulkan.so (Vulkan)
  • libz (Zlib कंप्रेशन)
  • JNI इंटरफ़ेस

• [C-0-8] ऊपर दी गई नेटिव लाइब्रेरी के लिए, सार्वजनिक फ़ंक्शन को जोड़ना या हटाना ज़रूरी नहीं है.

• [C-0-9] /vendor/etc/public.libraries.txt में, सीधे तौर पर तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराई गई, AOSP लाइब्रेरी के अलावा अन्य लाइब्रेरी की सूची देना ज़रूरी है.

• [C-0-10] एपीआई लेवल 24 या इसके बाद के वर्शन को टारगेट करने वाले तीसरे पक्ष के ऐप्लिकेशन के लिए, AOSP में सिस्टम लाइब्रेरी के तौर पर लागू और उपलब्ध कराई गई किसी भी अन्य नेटिव लाइब्रेरी को एक्सपोज़ नहीं किया जाना चाहिए, क्योंकि ये लाइब्रेरी रिज़र्व हैं.

• [C-0-11] libGLESv3.so लाइब्रेरी की मदद से, NDK में बताए गए सभी OpenGL ES 3.1 और Android एक्सटेंशन पैकेज फ़ंक्शन के सिंबल एक्सपोर्ट करना ज़रूरी है. ध्यान दें कि सभी सिंबल मौजूद होने चाहिए. हालांकि, सेक्शन 7.1.4.1 में, इससे जुड़ी ज़रूरी शर्तों के बारे में ज़्यादा जानकारी दी गई है.

• [C-0-12] Vulkan 1.0 के मुख्य फ़ंक्शन के लिए फ़ंक्शन सिंबल और Vulkan 1.1 के फ़ंक्शन सिंबल के साथ-साथ, VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1, और VK_KHR_get_physical_device_properties2 एक्सटेंशन को libvulkan.so लाइब्रेरी के ज़रिए एक्सपोर्ट करना ज़रूरी है. ध्यान दें कि सभी सिंबल मौजूद होने चाहिए. हालांकि, सेक्शन 7.1.4.2 में, इस बारे में ज़्यादा जानकारी दी गई है कि हर फ़ंक्शन को पूरी तरह से लागू करने के लिए, क्या ज़रूरी है.

• इसे, अपस्ट्रीम Android Open Source Project में मौजूद सोर्स कोड और हेडर फ़ाइलों का इस्तेमाल करके बनाया जाना चाहिए.

ध्यान दें कि आने वाले समय में, Android के रिलीज़ में अन्य एबीआई के लिए सहायता उपलब्ध कराई जा सकती है.

3.3.2. 32-बिट ARM नेटिव कोड के साथ काम करना

अगर डिवाइस पर armeabi ABI काम करता है, तो:

• [C-3-1] armeabi-v7a के साथ भी काम करना चाहिए और इसकी जानकारी देनी चाहिए, क्योंकि armeabi सिर्फ़ पुराने ऐप्लिकेशन के साथ काम करने के लिए है.

अगर डिवाइस पर armeabi-v7a एबीआई का इस्तेमाल करने वाले ऐप्लिकेशन के लिए, एबीआई के काम करने की जानकारी मिलती है, तो:

• [C-2-1] /proc/cpuinfo में ये लाइनें शामिल होनी चाहिए. साथ ही, एक ही डिवाइस पर वैल्यू में बदलाव नहीं किया जाना चाहिए. भले ही, उन्हें अन्य एबीआई ने पढ़ा हो.

  • Features:, इसके बाद डिवाइस पर काम करने वाली ARMv7 सीपीयू की वैकल्पिक सुविधाओं की सूची दी गई है.
  • CPU architecture: के बाद, एक पूर्णांक होता है. इससे डिवाइस पर काम करने वाले सबसे बेहतर ARM आर्किटेक्चर के बारे में पता चलता है (उदाहरण के लिए, "8" के लिए ARMv8 डिवाइसों).

• [C-2-2] यहां दिए गए ऑपरेशन हमेशा उपलब्ध होने चाहिए. भले ही, एबीआई को ARMv8 आर्किटेक्चर पर लागू किया गया हो. ऐसा, नेटिव सीपीयू के साथ काम करने की सुविधा या सॉफ़्टवेयर इम्यूलेशन की मदद से किया जा सकता है:

  • SWP और SWPB के लिए निर्देश.
  • CP15ISB, CP15DSB, और CP15DMB बैरियर ऑपरेशंस.

• [C-2-3] इसमें Advanced SIMD (जिसे NEON भी कहा जाता है) एक्सटेंशन के लिए सहायता शामिल होनी चाहिए.

3.4. वेब के साथ काम करना

3.4.1. वेबव्यू के साथ काम करना

अगर डिवाइस पर android.webkit.Webview एपीआई को पूरी तरह से लागू किया गया है, तो:

• [C-1-1] android.software.webview की रिपोर्ट करना ज़रूरी है.
• [C-1-2] android.webkit.WebView एपीआई को लागू करने के लिए, Android 14 ब्रैंच पर अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट से Chromium प्रोजेक्ट के बिल्ड का इस्तेमाल करना ज़रूरी है.

• [C-1-3] वेबव्यू की रिपोर्ट की गई यूज़र एजेंट स्ट्रिंग इस फ़ॉर्मैट में होनी चाहिए:

  Mozilla/5.0 (Linux; Android $(VERSION); [$(MODEL)] [Build/$(BUILD)]; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36

  • $(VERSION) स्ट्रिंग की वैल्यू, android.os.Build.VERSION.RELEASE की वैल्यू के बराबर होनी चाहिए.
  • $(MODEL) स्ट्रिंग खाली हो सकती है. हालांकि, अगर यह खाली नहीं है, तो इसकी वैल्यू, android.os.Build.MODEL की वैल्यू के बराबर होनी चाहिए.
  • "Build/$(BUILD)" को छोड़ा जा सकता है. हालांकि, अगर यह मौजूद है, तो $(BUILD) स्ट्रिंग, android.os.Build.ID की वैल्यू के बराबर होनी चाहिए.
  • $(CHROMIUM_VER) स्ट्रिंग की वैल्यू, अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट में मौजूद Chromium का वर्शन होनी चाहिए.
  • डिवाइस लागू करने पर, हो सकता है कि उपयोगकर्ता एजेंट स्ट्रिंग में मोबाइल को शामिल न किया जाए.

• वेबव्यू कॉम्पोनेंट में, ज़्यादा से ज़्यादा HTML5 सुविधाओं के साथ काम करने की सुविधा होनी चाहिए. अगर यह सुविधा काम करती है, तो यह HTML5 स्पेसिफ़िकेशन के मुताबिक होनी चाहिए.

• [C-1-4] दिए गए कॉन्टेंट या रिमोट यूआरएल के कॉन्टेंट को ऐसी प्रोसेस में रेंडर करना चाहिए जो वेबव्यू को इंस्टैंशिएट करने वाले ऐप्लिकेशन से अलग हो. खास तौर पर, अलग रेंडरर प्रोसेस के पास कम से कम अनुमतियां होनी चाहिए. साथ ही, वह अलग यूज़र आईडी के तौर पर चलनी चाहिए. इसके अलावा, उसके पास ऐप्लिकेशन की डेटा डायरेक्ट्री का ऐक्सेस नहीं होना चाहिए. साथ ही, उसके पास सीधे तौर पर नेटवर्क का ऐक्सेस नहीं होना चाहिए. इसके अलावा, उसके पास Binder के ज़रिए सिर्फ़ ज़रूरी सिस्टम सेवाओं का ऐक्सेस होना चाहिए. AOSP में वेबव्यू लागू करने की सुविधा, इस ज़रूरी शर्त को पूरा करती है.

ध्यान दें कि अगर डिवाइस पर 32-बिट प्रोसेसर का इस्तेमाल किया जा रहा है या सुविधा फ़्लैग android.hardware.ram.low का एलान किया गया है, तो उन्हें C-1-3 से छूट मिलती है.

3.4.2. ब्राउज़र किस-किस के साथ काम करता है

अगर डिवाइस में सामान्य वेब ब्राउज़िंग के लिए स्टैंडअलोन ब्राउज़र ऐप्लिकेशन शामिल है, तो:

• [C-1-1] एपीआई को HTML5 से जुड़े इन सभी एपीआई के साथ काम करना चाहिए:
  • ऐप्लिकेशन की कैश मेमोरी/ऑफ़लाइन काम करना
  • <video> टैग
  • जगह की जानकारी
• [C-1-2] यह ज़रूरी है कि यह HTML5/W3C के webstorage API के साथ काम करे. साथ ही, यह HTML5/W3C के IndexedDB API के साथ काम करे. ध्यान दें कि वेब डेवलपमेंट के स्टैंडर्ड से जुड़ी संस्थाएं, वेबस्टोरेज के बजाय IndexedDB का इस्तेमाल करने की ओर बढ़ रही हैं. इसलिए, आने वाले समय में Android के वर्शन में IndexedDB एक ज़रूरी कॉम्पोनेंट बन सकता है.
• स्टैंडअलोन ब्राउज़र ऐप्लिकेशन में, कस्टम उपयोगकर्ता एजेंट स्ट्रिंग भेजी जा सकती है.
• स्टैंडअलोन ब्राउज़र ऐप्लिकेशन पर, ज़्यादा से ज़्यादा HTML5 के लिए सहायता लागू की जानी चाहिए. भले ही, यह अपस्ट्रीम WebKit ब्राउज़र ऐप्लिकेशन पर आधारित हो या तीसरे पक्ष के किसी ब्राउज़र पर.

हालांकि, अगर डिवाइस पर लागू किए गए टूल में स्टैंडअलोन ब्राउज़र ऐप्लिकेशन शामिल नहीं है, तो:

• [C-2-1] अब भी सेक्शन 3.2.3.1 में बताए गए पब्लिक इंटेंट पैटर्न के साथ काम करना चाहिए.

3.5. एपीआई के काम करने का तरीका

डिवाइस पर लागू करने के तरीके:

• [C-0-9] यह पक्का करना ज़रूरी है कि इंस्टॉल किए गए सभी ऐप्लिकेशन के लिए, एपीआई के साथ काम करने की सुविधा लागू हो. हालांकि, अगर उन पर सेक्शन 3.5.1 में बताई गई पाबंदी लगी है, तो यह ज़रूरी नहीं है.
• [C-0-10] अनुमति वाली सूची के उस तरीके को लागू नहीं करना चाहिए जिससे यह पक्का हो सके कि एपीआई, सिर्फ़ उन ऐप्लिकेशन के साथ काम करता है जिन्हें डिवाइस लागू करने वाले लोगों ने चुना है.

एपीआई के हर टाइप (मैनेज किया गया, सॉफ़्ट, नेटिव, और वेब) का व्यवहार, अपस्ट्रीम Android Open Source Project के पसंदीदा तरीके से लागू होने के मुताबिक होना चाहिए. साथ काम करने से जुड़ी कुछ खास बातें:

• [C-0-1] डिवाइसों को स्टैंडर्ड इंटेंट के व्यवहार या सेमेटिक्स में बदलाव नहीं करना चाहिए.
• [C-0-2] डिवाइसों को किसी खास तरह के सिस्टम कॉम्पोनेंट (जैसे, सेवा, गतिविधि, ContentProvider वगैरह) के लाइफ़साइकल या लाइफ़साइकल सेमेटिक्स में बदलाव नहीं करना चाहिए.
• [C-0-3] डिवाइसों को स्टैंडर्ड अनुमति के सेमेटिक्स में बदलाव नहीं करना चाहिए.
• डिवाइसों को बैकग्राउंड ऐप्लिकेशन पर लागू की गई सीमाओं में बदलाव नहीं करना चाहिए. खास तौर पर, बैकग्राउंड में काम करने वाले ऐप्लिकेशन के लिए:
  • [C-0-4] GnssMeasurement और GnssNavigationMessage से आउटपुट पाने के लिए, ऐप्लिकेशन के रजिस्टर किए गए कॉलबैक को चलाना बंद करना होगा.
  • [C-0-5] डेवलपर को, LocationManager एपीआई क्लास या WifiManager.startScan() तरीके से, ऐप्लिकेशन को मिलने वाले अपडेट की फ़्रीक्वेंसी को रेट-सीमा में रखना होगा.
  • [C-0-6] अगर ऐप्लिकेशन, एपीआई लेवल 25 या उसके बाद के वर्शन को टारगेट कर रहा है, तो उसे ऐप्लिकेशन के मेनिफ़ेस्ट में, स्टैंडर्ड Android इंटेंट के लिए, अपने-आप होने वाले ब्रॉडकास्ट के लिए ब्रॉडकास्ट रिसीवर रजिस्टर करने की अनुमति नहीं देनी चाहिए. ऐसा तब तक नहीं किया जाना चाहिए, जब तक कि ब्रॉडकास्ट इंटेंट के लिए "signature" या "signatureOrSystem" protectionLevel अनुमति की ज़रूरत न हो या वे छूट वाली सूची में शामिल न हों.
  • [C-0-7] अगर ऐप्लिकेशन, एपीआई लेवल 25 या उसके बाद के वर्शन को टारगेट कर रहा है, तो उसे ऐप्लिकेशन की बैकग्राउंड सेवाओं को बंद करना होगा. ऐसा तब भी करना होगा, जब ऐप्लिकेशन ने सेवाओं के stopSelf() तरीकों को कॉल किया हो. हालांकि, अगर ऐप्लिकेशन को किसी ऐसे टास्क को मैनेज करने के लिए, कुछ समय के लिए अनुमति वाली सूची में रखा गया है जो उपयोगकर्ता को दिखता है, तो ऐसा नहीं करना होगा.
  • [C-0-8] अगर ऐप्लिकेशन, एपीआई लेवल 25 या उसके बाद के वर्शन को टारगेट कर रहा है, तो उसे वेक लॉक रिलीज़ करने होंगे.
• [C-0-11] डिवाइसों को यहां दिए गए सुरक्षा प्रोवाइडर, Security.getProviders() वाले तरीके से, पहले सात ऐरे वैल्यू के तौर पर दिखाने चाहिए. साथ ही, ये वैल्यू दिए गए क्रम में और दिए गए नामों (Provider.getName() से मिली वैल्यू के तौर पर) और क्लास के साथ होनी चाहिए. ऐसा तब तक करना होगा, जब तक ऐप्लिकेशन ने insertProviderAt() या removeProvider() के ज़रिए सूची में बदलाव न कर दिया हो. डिवाइसों पर, यहां दी गई सेवा देने वाली कंपनियों की सूची के बाद, अन्य सेवा देने वाली कंपनियों की जानकारी भी दिख सकती है.
  1. AndroidNSSP - android.security.net.config.NetworkSecurityConfigProvider
  2. AndroidOpenSSL - com.android.org.conscrypt.OpenSSLProvider
  3. CertPathProvider - sun.security.provider.CertPathProvider
  4. AndroidKeyStoreBCWorkaround - android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
  5. BC - com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
  6. HarmonyJSSE - com.android.org.conscrypt.JSSEProvider
  7. AndroidKeyStore - android.security.keystore.AndroidKeyStoreProvider

ऊपर दी गई सूची पूरी नहीं है. Compatibility Test Suite (CTS), प्लैटफ़ॉर्म के काम करने के तरीके के हिसाब से, उसके अहम हिस्सों की जांच करता है. हालांकि, वह सभी हिस्सों की जांच नहीं करता. इसे लागू करने वाले व्यक्ति या कंपनी की ज़िम्मेदारी है कि वह Android ओपन सोर्स प्रोजेक्ट के साथ, इस सुविधा के काम करने का तरीका ठीक से काम करता है या नहीं. इस वजह से, डिवाइस को लागू करने वाले लोगों को सिस्टम के अहम हिस्सों को फिर से लागू करने के बजाय, जहां भी हो सके वहां Android Open Source Project के ज़रिए उपलब्ध सोर्स कोड का इस्तेमाल करना चाहिए.

3.5.1. ऐप्लिकेशन पर पाबंदी

अगर डिवाइस में ऐप्लिकेशन पर पाबंदी लगाने के लिए, मालिकाना हक वाला कोई तरीका लागू किया जाता है (जैसे, एसडीके में बताए गए एपीआई के व्यवहार में बदलाव करना या उस पर पाबंदी लगाना), और वह तरीका प्रतिबंधित ऐप्लिकेशन की स्टैंडबाय बकेट से ज़्यादा पाबंदी वाला है, तो:

• [C-1-1] उपयोगकर्ता को पाबंदी वाले ऐप्लिकेशन की सूची देखने की अनुमति देनी चाहिए.
• [C-1-2] हर ऐप्लिकेशन पर, मालिकाना हक से जुड़ी इन सभी पाबंदियों को चालू या बंद करने के लिए, उपयोगकर्ता को सुविधा देना ज़रूरी है.

• [C-1-3] सिस्टम की परफ़ॉर्मेंस खराब होने के सबूत के बिना, इन मालिकाना हक वाली पाबंदियों को अपने-आप लागू नहीं करना चाहिए. हालांकि, सिस्टम की परफ़ॉर्मेंस खराब होने का पता चलने पर, ऐप्लिकेशन पर पाबंदियां लगाई जा सकती हैं. जैसे, स्टिक किए गए वेकलॉक, लंबे समय तक चलने वाली सेवाएं, और अन्य शर्तें. डिवाइस को डिलीवर करने वाली कंपनियां, शर्तें तय कर सकती हैं. हालांकि, ये शर्तें सिस्टम की परफ़ॉर्मेंस पर ऐप्लिकेशन के असर से जुड़ी होनी चाहिए. सिस्टम की परफ़ॉर्मेंस से पूरी तरह से जुड़ी अन्य शर्तों का इस्तेमाल नहीं किया जाना चाहिए. जैसे, ऐप्लिकेशन की मार्केट में लोकप्रियता न होना.

• [C-1-4] जब कोई उपयोगकर्ता ऐप्लिकेशन की पाबंदियों को मैन्युअल तरीके से बंद कर देता है, तो ऐप्लिकेशन के लिए ये मालिकाना पाबंदियां अपने-आप लागू नहीं होनी चाहिए. हालांकि, उपयोगकर्ता को इन मालिकाना पाबंदियों को लागू करने का सुझाव दिया जा सकता है.

• [C-1-5] अगर किसी ऐप्लिकेशन पर मालिकाना हक से जुड़ी ये पाबंदियां अपने-आप लागू होती हैं, तो उपयोगकर्ताओं को इसकी जानकारी देना ज़रूरी है. यह जानकारी, मालिकाना हक से जुड़ी इन पाबंदियों के लागू होने से पहले के 24 घंटे के अंदर दी जानी चाहिए.

• [C-1-6] किसी ऐप्लिकेशन से किए गए किसी भी एपीआई कॉल के लिए, ActivityManager.isBackgroundRestricted() मैथड के लिए 'सही' दिखाना ज़रूरी है.

• [C-1-7] फ़ोरग्राउंड में मौजूद उस ऐप्लिकेशन पर पाबंदी नहीं लगानी चाहिए जिसका इस्तेमाल उपयोगकर्ता साफ़ तौर पर करता है.

• [C-1-8] जब भी कोई उपयोगकर्ता ऐप्लिकेशन का साफ़ तौर पर इस्तेमाल करना शुरू करता है, तो ऐप्लिकेशन पर मालिकाना हक से जुड़ी ये पाबंदियां निलंबित करनी चाहिए. इससे ऐप्लिकेशन, फ़ोरग्राउंड में सबसे ऊपर दिखने वाला ऐप्लिकेशन बन जाता है.

• [C-1-10] सार्वजनिक और साफ़ तौर पर जानकारी देने वाला दस्तावेज़ या वेबसाइट देना ज़रूरी है. इसमें यह जानकारी होनी चाहिए कि मालिकाना हक से जुड़ी पाबंदियां कैसे लागू की जाती हैं. यह दस्तावेज़ या वेबसाइट, Android SDK के दस्तावेज़ों से लिंक की जानी चाहिए. साथ ही, इसमें ये चीज़ें शामिल होनी चाहिए:

  • मालिकाना हक से जुड़ी पाबंदियों के लिए ट्रिगर करने वाली शर्तें.
  • किसी ऐप्लिकेशन पर किस तरह की पाबंदी लगाई जा सकती है और कैसे.
  • किसी ऐप्लिकेशन को इन पाबंदियों से छूट कैसे मिल सकती है.
  • अगर उपयोगकर्ता के इंस्टॉल किए जा सकने वाले ऐप्लिकेशन के लिए, मालिकाना हक से जुड़ी पाबंदियों से छूट मिल सकती है, तो कोई ऐप्लिकेशन इस छूट का अनुरोध कैसे कर सकता है.

अगर कोई ऐप्लिकेशन डिवाइस पर पहले से इंस्टॉल है और किसी उपयोगकर्ता ने 30 दिनों से ज़्यादा समय तक उसका इस्तेमाल नहीं किया है, तो [C-1-3] [C-1-5] से छूट मिलती है.

अगर डिवाइस में, AOSP में लागू की गई ऐप्लिकेशन पाबंदियों को बढ़ाया जाता है, तो:

• [C-2-1]इस दस्तावेज़ में बताए गए तरीके का पालन करना ज़रूरी है.

3.5.2. ऐप्लिकेशन का हाइबरनेशन मोड

अगर डिवाइस में, AOSP में शामिल ऐप्लिकेशन हाइबरनेट करने की सुविधा या AOSP में शामिल सुविधा को बेहतर बनाने की सुविधा शामिल है, तो:

• [C-1-1] को [C-1-6] और [C-1-3] को छोड़कर, सेक्शन 3.5.1 की सभी ज़रूरी शर्तें पूरी करनी होंगी.
• [C-1-2] किसी उपयोगकर्ता के लिए ऐप्लिकेशन पर पाबंदी सिर्फ़ तब लगानी चाहिए, जब इस बात का सबूत हो कि उपयोगकर्ता ने कुछ समय से ऐप्लिकेशन का इस्तेमाल नहीं किया है. हमारा सुझाव है कि आप इस अवधि को एक महीने या उससे ज़्यादा रखें. इस्तेमाल की जानकारी, UsageStats#getLastTimeVisible() एपीआई के ज़रिए उपयोगकर्ता के साफ़ तौर पर इंटरैक्ट करने या किसी ऐसे ऐप्लिकेशन से मिलनी चाहिए जिसकी वजह से ऐप्लिकेशन को 'जबर्दस्ती बंद किया गया' स्टेटस से बाहर निकाला गया हो. इनमें सेवा बाइंडिंग, कॉन्टेंट देने वाली कंपनी की बाइंडिंग, साफ़ तौर पर दिखाए जाने वाले ब्रॉडकास्ट वगैरह शामिल हैं. इनकी जानकारी, नए एपीआई UsageStats#getLastTimeAnyComponentUsed से ट्रैक की जाएगी.
• [C-1-3] डिवाइस के सभी उपयोगकर्ताओं पर असर डालने वाली पाबंदियां सिर्फ़ तब लागू की जानी चाहिए, जब इस बात का सबूत हो कि किसी उपयोगकर्ता ने कुछ समय तक पैकेज का इस्तेमाल नहीं किया है. हमारा सुझाव है कि यह अवधि एक महीने या उससे ज़्यादा होनी चाहिए.
• [C-1-4] ऐप्लिकेशन को गतिविधि के इंटेंट, सेवा बाइंडिंग, कॉन्टेंट देने वाले के अनुरोधों या साफ़ तौर पर ब्रॉडकास्ट किए जाने वाले कॉन्टेंट का जवाब देने में असमर्थ नहीं होना चाहिए.

AOSP में ऐप्लिकेशन हाइबरनेट करने की सुविधा, ऊपर दी गई ज़रूरी शर्तों को पूरा करती है.

3.6. एपीआई नेमस्पेस

Android, पैकेज और क्लास नेमस्पेस के उन नियमों का पालन करता है जिन्हें Java प्रोग्रामिंग भाषा ने तय किया है. तीसरे पक्ष के ऐप्लिकेशन के साथ काम करने की सुविधा देने के लिए, डिवाइस लागू करने वाले लोगों को इन पैकेज नेमस्पेस में, पाबंदी वाले बदलाव नहीं करने चाहिए (नीचे देखें):

• java.*
• javax.*
• sun.*
• android.*
• androidx.*
• com.android.*

इसका मतलब है कि वे:

• [C-0-1] Android प्लैटफ़ॉर्म पर सार्वजनिक तौर पर उपलब्ध एपीआई में बदलाव नहीं किया जाना चाहिए. इसके लिए, किसी भी मेथड या क्लास के हस्ताक्षर में बदलाव करना या क्लास या क्लास फ़ील्ड को हटाना ज़रूरी नहीं है.
• [C-0-2] ऊपर दिए गए नेमस्पेस में मौजूद एपीआई में, सार्वजनिक तौर पर दिखाए जाने वाले एलिमेंट (जैसे, क्लास या इंटरफ़ेस या मौजूदा क्लास या इंटरफ़ेस के फ़ील्ड या तरीके) या टेस्ट या सिस्टम एपीआई नहीं जोड़ने चाहिए. "सार्वजनिक तौर पर दिखाया गया एलिमेंट", ऐसा कोई भी कॉन्स्ट्रक्ट होता है जिसे "@hide" मार्कर से नहीं सजाया गया है. इस मार्कर का इस्तेमाल, अपस्ट्रीम Android सोर्स कोड में किया जाता है.

डिवाइस पर एपीआई लागू करने वाले लोग, एपीआई के लागू होने के तरीके में बदलाव कर सकते हैं. हालांकि, ऐसे बदलाव:

• [C-0-3] सार्वजनिक तौर पर उपलब्ध किसी भी एपीआई के बताए गए व्यवहार और Java-language के हस्ताक्षर पर असर नहीं डालना चाहिए.
• [C-0-4] इसका विज्ञापन नहीं किया जाना चाहिए या डेवलपर को किसी भी तरह से इसका ऐक्सेस नहीं दिया जाना चाहिए.

हालांकि, डिवाइस लागू करने वाले लोग, स्टैंडर्ड Android नेमस्पेस के बाहर कस्टम एपीआई जोड़ सकते हैं. हालांकि, कस्टम एपीआई:

• [C-0-5] यह किसी ऐसे नेमस्पेस में नहीं होना चाहिए जिसका मालिकाना हक किसी दूसरे संगठन के पास हो या जो किसी दूसरे संगठन का रेफ़रंस देता हो. उदाहरण के लिए, डिवाइस लागू करने वाले लोगों को com.google.* या मिलते-जुलते नेमस्पेस में एपीआई नहीं जोड़ने चाहिए: सिर्फ़ Google ऐसा कर सकता है. इसी तरह, Google को अन्य कंपनियों के नेमस्पेस में एपीआई नहीं जोड़ने चाहिए.
• [C-0-6] को Android की शेयर की गई लाइब्रेरी में पैकेज किया जाना चाहिए, ताकि ऐसे एपीआई के ज़्यादा मेमोरी इस्तेमाल करने से सिर्फ़ उन ऐप्लिकेशन पर असर पड़े जो <uses-library> प्रोसेस के ज़रिए, साफ़ तौर पर उनका इस्तेमाल करते हैं.

डिवाइस लागू करने वाले लोग, नेटिव भाषाओं में कस्टम एपीआई जोड़ सकते हैं. ये एपीआई, एनडीके एपीआई के बाहर के होते हैं. हालांकि, कस्टम एपीआई:

• [C-1-1] यह ज़रूरी है कि यह NDK लाइब्रेरी या किसी ऐसे संगठन की लाइब्रेरी में न हो जिसके बारे में यहां बताया गया है.

अगर डिवाइस इंप्लीमेंटर, ऊपर दिए गए पैकेज नेमस्पेस में से किसी एक को बेहतर बनाने का सुझाव देता है, तो उसे source.android.com पर जाना चाहिए. इसके बाद, उस साइट पर दी गई जानकारी के मुताबिक, बदलाव और कोड में योगदान देने की प्रोसेस शुरू करनी चाहिए. जैसे, किसी मौजूदा एपीआई में काम की नई सुविधा जोड़ना या नया एपीआई जोड़ना.

ध्यान दें कि ऊपर बताई गई पाबंदियां, Java प्रोग्रामिंग भाषा में एपीआई के नाम रखने के लिए तय किए गए स्टैंडर्ड नियमों के मुताबिक हैं. इस सेक्शन का मकसद, उन नियमों को दोबारा लागू करना और उन्हें इस 'काम करने के तरीके की परिभाषा' में शामिल करके, उन्हें ज़रूरी बनाना है.

3.7. रनटाइम के साथ काम करने की सुविधा

डिवाइस पर लागू करने के तरीके:

• [C-0-1] यह पूरी तरह से Dalvik Executable (DEX) फ़ॉर्मैट और Dalvik बाइटकोड स्पेसिफ़िकेशन और सेमेंटेक्स के साथ काम करना चाहिए.

• [C-0-2] अपस्ट्रीम Android प्लैटफ़ॉर्म के मुताबिक मेमोरी को बांटने के लिए, Dalvik रनटाइम को कॉन्फ़िगर करना ज़रूरी है. साथ ही, यह भी ज़रूरी है कि मेमोरी को बांटने का तरीका, नीचे दी गई टेबल में बताए गए तरीके के मुताबिक हो. (स्क्रीन साइज़ और स्क्रीन डेंसिटी की परिभाषाओं के लिए, सेक्शन 7.1.1 देखें.)

• Android RunTime (ART), Dalvik Executable Format के रेफ़रंस अपस्ट्रीम लागू करने के तरीके, और रेफ़रंस लागू करने के तरीके के पैकेज मैनेजमेंट सिस्टम का इस्तेमाल करना चाहिए.

• रनटाइम के स्थिर होने की पुष्टि करने के लिए, फ़ज़ टेस्ट को अलग-अलग तरीके से चलाना चाहिए और टारगेट किए गए आर्किटेक्चर का इस्तेमाल करना चाहिए. Android Open Source Project की वेबसाइट पर, JFuzz और DexFuzz के बारे में जानें.

ध्यान दें कि यहां दी गई मेमोरी वैल्यू को कम से कम वैल्यू माना जाता है. साथ ही, डिवाइस में हर ऐप्लिकेशन के लिए ज़्यादा मेमोरी भी असाइन की जा सकती है.

स्क्रीन लेआउट	स्क्रीन की सघनता	ऐप्लिकेशन के लिए ज़रूरी मेमोरी
Android Watch	120 डीपीआई (ldpi)	32 एमबी
	140 डीपीआई (140dpi)
	160 डीपीआई (एमडीपीआई)
	180 डीपीआई (180dpi)
	200 डीपीआई (200dpi)
	213 डीपीआई (tvdpi)
	220 डीपीआई (220dpi)	36 एमबी
	240 डीपीआई (एचडीपीआई)
	280 डीपीआई (280dpi)
	320 डीपीआई (xhdpi)	48 एमबी
	360 डीपीआई (360dpi)
	400 डीपीआई (400dpi)	56 एमबी
	420 डीपीआई (420dpi)	64 एमबी
	480 डीपीआई (xxhdpi)	88 एमबी
	560 डीपीआई (560dpi)	112 एमबी
	640 डीपीआई (xxxhdpi)	154 एमबी
छोटा/सामान्य	120 डीपीआई (ldpi)	32 एमबी
	140 डीपीआई (140dpi)
	160 डीपीआई (एमडीपीआई)
	180 डीपीआई (180dpi)	48 एमबी
	200 डीपीआई (200dpi)
	213 डीपीआई (tvdpi)
	220 डीपीआई (220dpi)
	240 डीपीआई (एचडीपीआई)
	280 डीपीआई (280dpi)
	320 डीपीआई (xhdpi)	80 एमबी
	360 डीपीआई (360dpi)
	400 डीपीआई (400dpi)	96 एमबी
	420 डीपीआई (420dpi)	112 एमबी
	480 डीपीआई (xxhdpi)	128 एमबी
	560 डीपीआई (560dpi)	192 एमबी
	640 डीपीआई (xxxhdpi)	256 एमबी
बड़ा	120 डीपीआई (ldpi)	32 एमबी
	140 डीपीआई (140dpi)	48 एमबी
	160 डीपीआई (एमडीपीआई)
	180 डीपीआई (180dpi)	80 एमबी
	200 डीपीआई (200dpi)
	213 डीपीआई (tvdpi)
	220 डीपीआई (220dpi)
	240 डीपीआई (एचडीपीआई)
	280 डीपीआई (280dpi)	96 एमबी
	320 डीपीआई (xhdpi)	128 एमबी
	360 डीपीआई (360dpi)	160 एमबी
	400 डीपीआई (400dpi)	192 एमबी
	420 डीपीआई (420dpi)	228 एमबी
	480 डीपीआई (xxhdpi)	256 एमबी
	560 डीपीआई (560dpi)	384 एमबी
	640 डीपीआई (xxxhdpi)	512 एमबी
xlarge	120 डीपीआई (ldpi)	48 एमबी
	140 डीपीआई (140dpi)	80 एमबी
	160 डीपीआई (एमडीपीआई)
	180 डीपीआई (180dpi)	96 एमबी
	200 डीपीआई (200dpi)
	213 डीपीआई (tvdpi)
	220 डीपीआई (220dpi)
	240 डीपीआई (एचडीपीआई)
	280 डीपीआई (280dpi)	144 एमबी
	320 डीपीआई (xhdpi)	192 एमबी
	360 डीपीआई (360dpi)	240 एमबी
	400 डीपीआई (400dpi)	288 एमबी
	420 डीपीआई (420dpi)	336 एमबी
	480 डीपीआई (xxhdpi)	384 एमबी
	560 डीपीआई (560dpi)	576 एमबी
	640 डीपीआई (xxxhdpi)	768 एमबी

3.8. यूज़र इंटरफ़ेस किस-किस के साथ काम करता है

3.8.1. लॉन्चर (होम स्क्रीन)

Android में एक लॉन्चर ऐप्लिकेशन (होम स्क्रीन) होता है. साथ ही, डिवाइस के लॉन्चर (होम स्क्रीन) की जगह लेने के लिए, तीसरे पक्ष के ऐप्लिकेशन इस्तेमाल किए जा सकते हैं.

अगर डिवाइस में तीसरे पक्ष के ऐप्लिकेशन को डिवाइस की होम स्क्रीन बदलने की अनुमति है, तो वे:

• [C-1-1] प्लैटफ़ॉर्म की सुविधा android.software.home_screen के बारे में एलान करना ज़रूरी है.
• [C-1-2] जब तीसरे पक्ष का ऐप्लिकेशन अपना आइकॉन देने के लिए <adaptive-icon> टैग का इस्तेमाल करता है और आइकॉन वापस पाने के लिए PackageManager तरीकों को कॉल किया जाता है, तो AdaptiveIconDrawable ऑब्जेक्ट को दिखाना ज़रूरी है.

अगर डिवाइस में कोई ऐसा डिफ़ॉल्ट लॉन्चर है जो ऐप्लिकेशन में शॉर्टकट पिन करने की सुविधा देता है, तो:

• [C-2-1] ShortcutManager.isRequestPinShortcutSupported() के लिए, true की रिपोर्ट करना ज़रूरी है.
• [C-2-2] ShortcutManager.requestPinShortcut() API के ज़रिए, ऐप्लिकेशन के अनुरोध किए गए शॉर्टकट को जोड़ने से पहले, उपयोगकर्ता से पूछने के लिए यूज़र अफ़र्डेंस होना चाहिए.
• [C-2-3] ऐप्लिकेशन के शॉर्टकट पेज पर बताए गए तरीके के मुताबिक, पिन किए गए शॉर्टकट, डाइनैमिक, और स्टैटिक शॉर्टकट के साथ काम करना चाहिए.

इसके उलट, अगर डिवाइस पर शॉर्टकट को ऐप्लिकेशन में पिन करने की सुविधा काम नहीं करती है, तो:

• [C-3-1] ShortcutManager.isRequestPinShortcutSupported() के लिए, false की रिपोर्ट करना ज़रूरी है.

अगर डिवाइस में कोई ऐसा डिफ़ॉल्ट लॉन्चर लागू किया जाता है जो ShortcutManager एपीआई की मदद से, तीसरे पक्ष के ऐप्लिकेशन के अतिरिक्त शॉर्टकट को तुरंत ऐक्सेस करने की सुविधा देता है, तो:

• [C-4-1] यह ज़रूरी है कि ऐप्लिकेशन में, दस्तावेज़ में बताई गई शॉर्टकट की सभी सुविधाएं काम करती हों.जैसे, स्टैटिक और डाइनैमिक शॉर्टकट, पिन किए गए शॉर्टकट वगैरह. साथ ही, यह ज़रूरी है कि ऐप्लिकेशन में ShortcutManager एपीआई क्लास के एपीआई पूरी तरह से लागू हों.

अगर डिवाइस में कोई डिफ़ॉल्ट लॉन्चर ऐप्लिकेशन शामिल है, जो ऐप्लिकेशन के आइकॉन के लिए बैज दिखाता है, तो:

• [C-5-1] NotificationChannel.setShowBadge() के एपीआई तरीके का पालन करना ज़रूरी है. दूसरे शब्दों में, अगर वैल्यू true के तौर पर सेट है, तो ऐप्लिकेशन आइकॉन से जुड़ा विज़ुअल अवफ़र्डेंस दिखाएं. साथ ही, जब ऐप्लिकेशन के सभी सूचना चैनलों ने वैल्यू को false के तौर पर सेट किया हो, तो ऐप्लिकेशन आइकॉन की बैजिंग स्कीम न दिखाएं.
• जब तीसरे पक्ष के ऐप्लिकेशन, मालिकाना हक वाले एपीआई का इस्तेमाल करके, मालिकाना हक वाले बैजिंग स्कीम के साथ काम करने की जानकारी देते हैं, तो ऐप्लिकेशन आइकॉन के बैज को अपने मालिकाना हक वाले बैजिंग स्कीम से बदला जा सकता है. हालांकि, SDK टूल में बताए गए सूचना बैज एपीआई के ज़रिए दिए गए संसाधनों और वैल्यू का इस्तेमाल करना चाहिए. जैसे, Notification.Builder.setNumber() और Notification.Builder.setBadgeIconType() एपीआई.

अगर डिवाइस पर मोनोक्रोम आइकॉन इस्तेमाल किए जा सकते हैं, तो ये आइकॉन:

• [C-6-1] का इस्तेमाल सिर्फ़ तब किया जाना चाहिए, जब कोई उपयोगकर्ता साफ़ तौर पर उन्हें चालू करता है. उदाहरण के लिए, सेटिंग या वॉलपेपर पिकर मेन्यू के ज़रिए.

3.8.2. विजेट

Android, तीसरे पक्ष के ऐप्लिकेशन विजेट के साथ काम करता है. इसके लिए, यह कॉम्पोनेंट टाइप और उससे जुड़े एपीआई और लाइफ़साइकल तय करता है. इससे ऐप्लिकेशन, असली उपयोगकर्ता को “AppWidget” दिखा सकते हैं.

अगर डिवाइस पर तीसरे पक्ष के ऐप्लिकेशन के विजेट काम करते हैं, तो:

• [C-1-1] प्लैटफ़ॉर्म की सुविधा के साथ काम करने के बारे में ज़रूर बताएं android.software.app_widgets.

• [C-1-2] ऐप्लिकेशन विजेट के लिए, पहले से मौजूद सहायता शामिल होनी चाहिए. साथ ही, ऐप्लिकेशन विजेट जोड़ने, कॉन्फ़िगर करने, देखने, और हटाने के लिए, उपयोगकर्ता इंटरफ़ेस के फ़ंक्शन उपलब्ध कराने चाहिए

• [C-1-3] यह ज़रूरी है कि यह स्टैंडर्ड ग्रिड साइज़ में, 4 x 4 वाले विजेट को रेंडर कर सके. ज़्यादा जानकारी के लिए, Android SDK के दस्तावेज़ में ऐप्लिकेशन विजेट के डिज़ाइन से जुड़े दिशा-निर्देश देखें.

• लॉक स्क्रीन पर ऐप्लिकेशन विजेट काम कर सकते हैं.

अगर डिवाइस पर तीसरे पक्ष के ऐप्लिकेशन के विजेट और ऐप्लिकेशन में शॉर्टकट पिन करने की सुविधा काम करती है, तो:

• [C-2-1] AppWidgetManager.html.isRequestPinAppWidgetSupported() के लिए, true की रिपोर्ट करना ज़रूरी है.
• [C-2-2] AppWidgetManager.requestPinAppWidget() API के ज़रिए, ऐप्लिकेशन के अनुरोध किए गए शॉर्टकट को जोड़ने से पहले, उपयोगकर्ता से पूछने के लिए यूज़र अफ़र्डेंस होना चाहिए.

3.8.3. सूचनाएं

Android में Notification और NotificationManager एपीआई शामिल हैं. इनकी मदद से, तीसरे पक्ष के ऐप्लिकेशन डेवलपर, उपयोगकर्ताओं को अहम इवेंट की सूचना दे सकते हैं. साथ ही, डिवाइस के हार्डवेयर कॉम्पोनेंट (जैसे, आवाज़, वाइब्रेशन, और लाइट) और सॉफ़्टवेयर सुविधाओं (जैसे, सूचना शेड, सिस्टम बार) का इस्तेमाल करके, उपयोगकर्ताओं का ध्यान खींच सकते हैं.

3.8.3.1. सूचनाओं का प्रज़ेंटेशन

अगर डिवाइस पर लागू किए गए तरीकों से, तीसरे पक्ष के ऐप्लिकेशन को उल्लेखनीय इवेंट के बारे में उपयोगकर्ताओं को सूचना देने की अनुमति मिलती है, तो वे:

• [C-1-1] SDK टूल के दस्तावेज़ में बताए गए तरीके के मुताबिक, हार्डवेयर की सुविधाओं का इस्तेमाल करने वाली सूचनाओं के साथ काम करना चाहिए. साथ ही, यह डिवाइस में लागू किए गए हार्डवेयर के साथ भी काम करना चाहिए. उदाहरण के लिए, अगर किसी डिवाइस में वाइब्रेटर शामिल है, तो उसे वाइब्रेशन एपीआई को सही तरीके से लागू करना होगा. अगर किसी डिवाइस पर एपीआई लागू करने के लिए ज़रूरी हार्डवेयर मौजूद नहीं है, तो उससे जुड़े एपीआई को नो-ऑप के तौर पर लागू करना ज़रूरी है. इस व्यवहार के बारे में ज़्यादा जानकारी सेक्शन 7 में दी गई है.
• [C-1-2] एपीआई या स्टेटस/सिस्टम बार के आइकॉन स्टाइल गाइड में दिए गए सभी रिसॉर्स (आइकॉन, ऐनिमेशन फ़ाइलें वगैरह) को सही तरीके से रेंडर करना ज़रूरी है. हालांकि, हो सकता है कि वे सूचनाओं के लिए, रेफ़रंस के तौर पर दिए गए Android Open Source के मुकाबले, उपयोगकर्ता को अलग अनुभव दें.
• [C-1-3] सूचनाओं को अपडेट करने, हटाने, और ग्रुप करने के लिए, एपीआई के लिए बताए गए व्यवहारों को सही तरीके से लागू करना ज़रूरी है.
• [C-1-4] SDK टूल में दिए गए NotificationChannel एपीआई के पूरे व्यवहार की जानकारी देना ज़रूरी है.
• [C-1-5] उपयोगकर्ता को यह सुविधा देनी चाहिए कि वह हर चैनल और ऐप्लिकेशन पैकेज के लेवल पर, तीसरे पक्ष के किसी ऐप्लिकेशन की सूचना को ब्लॉक कर सके और उसमें बदलाव कर सके.
• [C-1-6] मिटाए गए सूचना चैनलों को दिखाने के लिए, उपयोगकर्ता को सुविधा भी देनी होगी.

• [C-1-7] Notification.MessagingStyle के ज़रिए दिए गए सभी संसाधनों (इमेज, स्टिकर, आइकॉन वगैरह) को सही तरीके से रेंडर करना चाहिए.साथ ही, सूचना के टेक्स्ट के साथ-साथ, उपयोगकर्ता को कोई और इंटरैक्शन किए बिना रेंडर करना चाहिए. उदाहरण के लिए, setGroupConversation के ज़रिए सेट की गई ग्रुप बातचीत में, android.app.Person के ज़रिए दिए गए आइकॉन के साथ-साथ सभी रिसॉर्स दिखाना ज़रूरी है.

• [C-SR-1] हमारा सुझाव है कि उपयोगकर्ता को सूचना सुनने की अनुमति वाले ऐप्लिकेशन को भेजी जाने वाली सूचनाओं को कंट्रोल करने की सुविधा दें. यह ज़रूरी है कि उपयोगकर्ता, हर सूचना सुनने वाले के लिए यह कंट्रोल कर सके कि इस सुनने वाले को किस तरह की सूचनाएं भेजी जाएं. इनमें "बातचीत", "सूचनाएं", "साइलेंट", और "मौजूदा ज़रूरी" सूचनाएं शामिल होनी चाहिए.

• [C-SR-2] हमारा सुझाव है कि उपयोगकर्ताओं को यह तय करने का विकल्प दें कि किन ऐप्लिकेशन को सूचना सुनने वाले किसी खास ऐप्लिकेशन को सूचना देने से बाहर रखना है.

• [C-SR-3] हमारा सुझाव है कि जब उपयोगकर्ता किसी सूचना को कई बार खारिज कर दे, तो हर चैनल और ऐप्लिकेशन पैकेज के लेवल पर, तीसरे पक्ष के किसी ऐप्लिकेशन की सूचना को ब्लॉक करने के लिए, उपयोगकर्ता को अपने-आप एक विकल्प दिखे.

• रिच सूचनाओं के साथ काम करना चाहिए.

• ज़्यादा प्राथमिकता वाली कुछ सूचनाओं को स्क्रीन पर सबसे ऊपर सूचना देने वाले कार्ड के तौर पर दिखाना चाहिए.

• सूचनाओं को स्नूज़ करने के लिए, उपयोगकर्ता के पास विकल्प होना चाहिए.

• तीसरे पक्ष के ऐप्लिकेशन, उपयोगकर्ताओं को अहम इवेंट की सूचना कब दे सकते हैं, यह मैनेज किया जा सकता है. इससे ड्राइवर का ध्यान भटकने जैसी सुरक्षा से जुड़ी समस्याओं को कम करने में मदद मिलती है.

Android 11 में बातचीत की सूचनाओं के लिए सहायता की सुविधा जोड़ी गई है. ये ऐसी सूचनाएं होती हैं जो MessagingStyle का इस्तेमाल करती हैं और पब्लिश किया गया लोग शॉर्टकट आईडी देती हैं.

डिवाइस पर लागू करने के तरीके:

• [C-SR-4] हमारा सुझाव है कि आप conversation notifications को ग्रुप में डालें और उसे बातचीत से जुड़ी सूचनाओं के बजाय पहले दिखाएं. हालांकि, फ़ोरग्राउंड सेवा की सूचनाओं और importance:high की सूचनाओं को छोड़कर.

अगर डिवाइस पर conversation notifications को लागू करने की सुविधा उपलब्ध है और ऐप्लिकेशन, bubbles के लिए ज़रूरी डेटा उपलब्ध कराता है, तो:

• [C-SR-5] हमारा सुझाव है कि इस बातचीत को बबल के तौर पर दिखाया जाए. AOSP के लागू होने से, डिफ़ॉल्ट सिस्टम यूज़र इंटरफ़ेस, सेटिंग, और लॉन्चर की मदद से ये ज़रूरी शर्तें पूरी होती हैं.

अगर डिवाइस पर रिच नोटिफ़िकेशन की सुविधा काम करती है, तो:

• [C-2-1] Notification.Style एपीआई क्लास और उसके सबक्लास के ज़रिए दिए गए संसाधनों का इस्तेमाल करना ज़रूरी है.
• Notification.Style एपीआई क्लास और उसकी सबक्लास में बताए गए हर संसाधन एलिमेंट (जैसे, आइकॉन, टाइटल, और खास जानकारी वाला टेक्स्ट) को दिखाना चाहिए.

हेड्स अप सूचनाएं, ऐसी सूचनाएं होती हैं जो उपयोगकर्ता को तब दिखती हैं, जब वे उस प्लैटफ़ॉर्म पर मौजूद न हों जिस पर सूचनाएं भेजी गई हैं. अगर डिवाइस पर हेड्स-अप सूचनाएं पाने की सुविधा काम करती है, तो:

• [C-3-1] हेड-अप सूचनाएं दिखाने के लिए, Notification.Builder एपीआई क्लास में बताए गए हेड-अप सूचना व्यू और संसाधनों का इस्तेमाल करना ज़रूरी है.
• [C-3-2] SDK टूल में बताए गए तरीके के मुताबिक, सूचना के कॉन्टेंट के साथ-साथ, Notification.Builder.addAction() के ज़रिए दी गई कार्रवाइयां भी दिखनी चाहिए. इसके लिए, उपयोगकर्ता को कोई और इंटरैक्शन नहीं करना चाहिए.

3.8.3.2. सूचना सुनने की सुविधा

Android में NotificationListenerService एपीआई शामिल हैं. इनकी मदद से, ऐप्लिकेशन को सभी सूचनाओं की कॉपी तब मिलती है, जब उन्हें पोस्ट या अपडेट किया जाता है. हालांकि, इसके लिए उपयोगकर्ता को साफ़ तौर पर अनुमति देनी होगी.

डिवाइस पर लागू करने के तरीके:

• [C-0-1] ऐप्लिकेशन को, इंस्टॉल की गई और उपयोगकर्ता की ओर से चालू की गई सभी लिसनर सेवाओं के लिए, सूचनाओं को सही तरीके से और तुरंत अपडेट करना ज़रूरी है. इसमें, सूचना ऑब्जेक्ट से जुड़ा कोई भी और पूरा मेटाडेटा शामिल है.
• [C-0-2] snoozeNotification() एपीआई कॉल का पालन करना चाहिए. साथ ही, सूचना को खारिज करना चाहिए और एपीआई कॉल में सेट की गई स्नूज़ अवधि के बाद कॉलबैक करना चाहिए.

अगर डिवाइस पर सूचनाएं स्नूज़ करने की सुविधा उपलब्ध है, तो:

• [C-1-1] NotificationListenerService.getSnoozedNotifications() जैसे स्टैंडर्ड एपीआई के ज़रिए, स्नूज़ की गई सूचना की स्थिति को सही तरीके से दिखाना ज़रूरी है.
• [C-1-2] तीसरे पक्ष के हर इंस्टॉल किए गए ऐप्लिकेशन की सूचनाओं को स्नूज़ करने के लिए, यह सुविधा उपलब्ध कराना ज़रूरी है. हालांकि, यह ज़रूरी नहीं है कि यह सुविधा, हमेशा चालू रहने वाली/फ़ोरग्राउंड सेवाओं के लिए उपलब्ध हो.

3.8.3.3. परेशान न करें (डीएनडी) / प्राथमिकता मोड

अगर डिवाइस पर डीएनडी मोड (इसे प्राथमिकता मोड भी कहा जाता है) की सुविधा काम करती है, तो:

• [C-1-1] डिवाइस में, उपयोगकर्ता को 'परेशान न करें' नीति के कॉन्फ़िगरेशन को ऐक्सेस करने के लिए, तीसरे पक्ष के ऐप्लिकेशन को अनुमति देने या अनुमति न देने का विकल्प दिया गया हो. ऐसे में, उपयोगकर्ता के बनाए गए और पहले से तय नियमों के साथ-साथ, ऐप्लिकेशन के बनाए गए परेशान न करें मोड के अपने-आप लागू होने वाले नियम दिखाना ज़रूरी है.
• [C-1-3] NotificationManager.Policy के साथ भेजी गई suppressedVisualEffects वैल्यू का पालन करना ज़रूरी है. अगर किसी ऐप्लिकेशन ने SUPPRESSED_EFFECT_SCREEN_OFF या SUPPRESSED_EFFECT_SCREEN_ON फ़्लैग में से कोई एक सेट किया है, तो उसे उपयोगकर्ता को यह बताना चाहिए कि 'परेशान न करें' सेटिंग मेन्यू में विज़ुअल इफ़ेक्ट बंद हैं.

3.8.4. Assist API

Android में Assist API शामिल हैं, ताकि ऐप्लिकेशन यह चुन सकें कि डिवाइस पर Assistant के साथ मौजूदा कॉन्टेक्स्ट की कितनी जानकारी शेयर की जाए.

अगर डिवाइस पर Assist ऐक्शन की सुविधा काम करती है, तो:

• [C-2-1] असली उपयोगकर्ता को साफ़ तौर पर यह बताना ज़रूरी है कि कॉन्टेक्स्ट कब शेयर किया गया है. इसके लिए, इनमें से कोई एक तरीका अपनाएं:
  • जब भी सहायक ऐप्लिकेशन कॉन्टेक्स्ट को ऐक्सेस करता है, तो स्क्रीन के किनारों के आस-पास एक सफ़ेद रोशनी दिखती है. यह रोशनी, Android Open Source Project के लागू होने की अवधि और चमक के बराबर या उससे ज़्यादा होती है.
  • पहले से इंस्टॉल किए गए असिस्ट ऐप्लिकेशन के लिए, उपयोगकर्ता को डिफ़ॉल्ट वॉइस इनपुट और असिस्ट ऐप्लिकेशन के सेटिंग मेन्यू से दो नेविगेशन से कम की दूरी पर, उपयोगकर्ता के लिए आसानी से ऐक्सेस करने की सुविधा उपलब्ध कराना. साथ ही, सिर्फ़ तब संदर्भ शेयर करना, जब उपयोगकर्ता ने हॉटवर्ड या असिस्ट नेविगेशन बटन के इनपुट की मदद से, असिस्ट ऐप्लिकेशन को साफ़ तौर पर चालू किया हो.
• [C-2-2] सेक्शन 7.2.3 में बताए गए तरीके से, असिस्ट ऐप्लिकेशन को लॉन्च करने के लिए तय किया गया इंटरैक्शन, उपयोगकर्ता के चुने गए असिस्ट ऐप्लिकेशन को लॉन्च करना चाहिए. दूसरे शब्दों में, वह ऐप्लिकेशन जो VoiceInteractionService को लागू करता है या ACTION_ASSIST इंटेंट को मैनेज करने वाली गतिविधि.

3.8.5. सूचनाएं और टॉस्ट

ऐप्लिकेशन, Toast एपीआई का इस्तेमाल करके, असली उपयोगकर्ता को कुछ समय के लिए दिखने वाली छोटी और बिना मोडल वाली स्ट्रिंग दिखा सकते हैं. साथ ही, अन्य ऐप्लिकेशन पर ओवरले के तौर पर सूचना वाली विंडो दिखाने के लिए, TYPE_APPLICATION_OVERLAY विंडो टाइप एपीआई का इस्तेमाल कर सकते हैं.

अगर डिवाइस में स्क्रीन या वीडियो आउटपुट शामिल है, तो:

• [C-1-1] ऐप्लिकेशन को TYPE_APPLICATION_OVERLAY का इस्तेमाल करके सूचना वाली विंडो दिखाने से रोकने के लिए, उपयोगकर्ता को कोई सुविधा देनी होगी. AOSP के तहत, सूचना शेड में कंट्रोल होने की वजह से यह ज़रूरी शर्त पूरी हो जाती है.

• [C-1-2] ऐप्लिकेशन को Toast API का इस्तेमाल करना चाहिए. साथ ही, ऐप्लिकेशन से असली उपयोगकर्ताओं को, साफ़ तौर पर दिखने वाले तरीके से सूचनाएं दिखानी चाहिए.

3.8.6. थीम

Android, ऐप्लिकेशन के लिए “थीम” उपलब्ध कराता है, ताकि वे पूरी गतिविधि या ऐप्लिकेशन में स्टाइल लागू कर सकें.

Android में “Holo” और "Material" थीम फ़ैमिली शामिल है. यह, तय की गई स्टाइल के सेट के तौर पर होती है. ऐप्लिकेशन डेवलपर इसका इस्तेमाल तब कर सकते हैं, जब उन्हें Android SDK टूल में बताई गई Holo थीम के लुक और स्टाइल से मैच करना हो.

अगर डिवाइस में स्क्रीन या वीडियो आउटपुट शामिल है, तो:

• [C-1-1] ऐप्लिकेशन के लिए उपलब्ध Holo थीम एट्रिब्यूट में बदलाव नहीं किया जाना चाहिए.
• [C-1-2] यह “Material” थीम फ़ैमिली के साथ काम करना चाहिए. साथ ही, Material थीम एट्रिब्यूट या ऐप्लिकेशन के लिए उपलब्ध कराई गई उनकी ऐसेट में कोई बदलाव नहीं करना चाहिए.

• [C-1-3] "sans-serif" फ़ॉन्ट फ़ैमिली को, Roboto के साथ काम करने वाली भाषाओं के लिए, Roboto वर्शन 2.x पर सेट करना ज़रूरी है. इसके अलावा, उपयोगकर्ता को "sans-serif" फ़ॉन्ट फ़ैमिली के लिए इस्तेमाल किए गए फ़ॉन्ट को, Roboto के साथ काम करने वाली भाषाओं के लिए, Roboto वर्शन 2.x पर बदलने का विकल्प देना ज़रूरी है.

• [C-1-4] Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES के AOSP दस्तावेज़ में बताए गए तरीके के मुताबिक, डाइनैमिक कलर टोन वाले पैलेट जनरेट करने चाहिए (android.theme.customization.system_palette और android.theme.customization.theme_style देखें).

• [C-1-5] Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES दस्तावेज़ (android.theme.customization.theme_styles देखें) में बताई गई कलर थीम स्टाइल का इस्तेमाल करके, डाइनैमिक कलर टोन वाले पैलेट जनरेट करने चाहिए. जैसे, TONAL_SPOT, VIBRANT, EXPRESSIVE, SPRITZ, RAINBOW, FRUIT_SALAD, औरMONOCHROMATIC.

  "सोर्स कलर" का इस्तेमाल, डाइनैमिक कलर टोन वाले पैलेट जनरेट करने के लिए किया जाता है. ऐसा तब किया जाता है, जब इसे android.theme.customization.system_palette के साथ भेजा जाता है (जैसा कि Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES में बताया गया है).

• [C-1-6] CAM16 की क्रोमा वैल्यू 5 या उससे ज़्यादा होनी चाहिए.

  • com.android.systemui.monet.ColorScheme#getSeedColors के ज़रिए वॉलपेपर से लिया जाना चाहिए. इससे, एक को चुनने के लिए कई मान्य सोर्स कलर मिलते हैं.

  • अगर दिए गए रंगों में से कोई भी रंग, सोर्स के रंग से जुड़ी ऊपर दी गई ज़रूरी शर्त को पूरा नहीं करता है, तो 0xFF1B6EF3 वैल्यू का इस्तेमाल करना चाहिए.

Android में, “डिवाइस की डिफ़ॉल्ट” थीम फ़ैमिली भी शामिल होती है. यह, तय की गई स्टाइल के सेट के तौर पर होती है. ऐप्लिकेशन डेवलपर इसका इस्तेमाल तब कर सकते हैं, जब उन्हें डिवाइस की थीम के लुक और स्टाइल को डिवाइस इंप्लीमेंटर के तय किए गए स्टाइल से मैच करना हो.

• डिवाइस के लागू होने से, ऐप्लिकेशन के लिए दिखाए गए डिवाइस की डिफ़ॉल्ट थीम के एट्रिब्यूट में बदलाव हो सकता है.

Android, पारदर्शी सिस्टम बार वाली वैरिएंट थीम के साथ काम करता है. इससे ऐप्लिकेशन डेवलपर, स्टेटस और नेविगेशन बार के पीछे के हिस्से को अपने ऐप्लिकेशन के कॉन्टेंट से भर सकते हैं. इस कॉन्फ़िगरेशन में डेवलपर को एक जैसा अनुभव देने के लिए, यह ज़रूरी है कि अलग-अलग डिवाइसों पर स्टेटस बार के आइकॉन का स्टाइल एक जैसा रहे.

अगर डिवाइस में सिस्टम स्टेटस बार शामिल है, तो:

• [C-2-1] सिस्टम के स्टेटस आइकॉन (जैसे, सिग्नल की क्षमता और बैटरी लेवल) और सिस्टम से मिलने वाली सूचनाओं के लिए, सफ़ेद रंग का इस्तेमाल करना ज़रूरी है. हालांकि, ऐसा तब तक नहीं किया जाना चाहिए, जब तक आइकॉन से किसी समस्या का पता न चल रहा हो या कोई ऐप्लिकेशन, WindowInsetsController#APPEARANCE_LIGHT_STATUS_BARS फ़्लैग का इस्तेमाल करके, लाइट स्टेटस बार का अनुरोध न कर रहा हो.
• [C-2-2] जब कोई ऐप्लिकेशन हल्के रंग के स्टेटस बार का अनुरोध करता है, तो Android डिवाइस के लागू होने पर, सिस्टम के स्टेटस आइकॉन का रंग काला होना चाहिए. ज़्यादा जानकारी के लिए, R.style देखें.

3.8.7. लाइव वॉलपेपर

Android, कॉम्पोनेंट टाइप और उससे जुड़े एपीआई और लाइफ़साइकल तय करता है. इससे ऐप्लिकेशन, असली उपयोगकर्ता को एक या एक से ज़्यादा “लाइव वॉलपेपर” दिखा सकते हैं. लाइव वॉलपेपर, ऐनिमेशन, पैटर्न या मिलती-जुलती इमेज होती हैं. इनमें इनपुट की सुविधाएं सीमित होती हैं. ये वॉलपेपर के तौर पर, दूसरे ऐप्लिकेशन के पीछे दिखती हैं.

किसी हार्डवेयर को लाइव वॉलपेपर चलाने की क्षमता वाला माना जाता है, अगर वह सभी लाइव वॉलपेपर को बिना किसी फ़ंक्शनल सीमित के, सही फ़्रेम रेट पर चला सकता है. साथ ही, इससे दूसरे ऐप्लिकेशन पर कोई बुरा असर नहीं पड़ता. अगर हार्डवेयर की सीमाओं की वजह से वॉलपेपर और/या ऐप्लिकेशन क्रैश हो जाते हैं, ठीक से काम नहीं करते हैं, सीपीयू या बैटरी का ज़्यादा इस्तेमाल करते हैं या बहुत कम फ़्रेम रेट पर चलते हैं, तो माना जाता है कि हार्डवेयर पर लाइव वॉलपेपर नहीं चल सकता. उदाहरण के लिए, कुछ लाइव वॉलपेपर अपने कॉन्टेंट को रेंडर करने के लिए, OpenGL 2.0 या 3.x कॉन्टेक्स्ट का इस्तेमाल कर सकते हैं. लाइव वॉलपेपर, ऐसे हार्डवेयर पर ठीक से काम नहीं करेगा जो एक से ज़्यादा OpenGL कॉन्टेक्स्ट के साथ काम नहीं करता. ऐसा इसलिए, क्योंकि लाइव वॉलपेपर में OpenGL कॉन्टेक्स्ट का इस्तेमाल करने से, उन अन्य ऐप्लिकेशन के साथ समस्या आ सकती है जो OpenGL कॉन्टेक्स्ट का इस्तेमाल करते हैं.

• ऊपर बताए गए तरीके से, लाइव वॉलपेपर को भरोसेमंद तरीके से चलाने वाले डिवाइसों पर, लाइव वॉलपेपर की सुविधा को लागू किया जाना चाहिए.

अगर डिवाइस पर लाइव वॉलपेपर लागू किए जाते हैं, तो:

• [C-1-1] प्लैटफ़ॉर्म की सुविधा के फ़्लैग android.software.live_wallpaper की जानकारी देना ज़रूरी है.

3.8.8. गतिविधि स्विच करना

अपस्ट्रीम Android सोर्स कोड में, खास जानकारी वाली स्क्रीन शामिल होती है. यह टास्क स्विच करने और हाल ही में ऐक्सेस की गई गतिविधियों और टास्क दिखाने के लिए, सिस्टम-लेवल का यूज़र इंटरफ़ेस होता है. इसमें, उपयोगकर्ता के आखिरी बार ऐप्लिकेशन छोड़ने के समय, ऐप्लिकेशन की ग्राफ़िकल स्थिति की थंबनेल इमेज का इस्तेमाल किया जाता है.

डिवाइस पर लागू किए गए बदलावों की वजह से, इंटरफ़ेस में बदलाव हो सकता है. इन बदलावों में, सेक्शन 7.2.3 में बताई गई हाल ही के ऐप्लिकेशन के नेविगेशन बटन की सुविधा भी शामिल है.

अगर डिवाइस में हाल ही के ऐप्लिकेशन के नेविगेशन बटन के साथ-साथ, सेक्शन 7.2.3 में बताई गई अन्य सुविधाएं लागू करने पर इंटरफ़ेस में बदलाव होता है, तो:

• [C-1-1] कम से कम सात गतिविधियां दिखाई जानी चाहिए.
• इसमें कम से कम चार गतिविधियों का टाइटल एक साथ दिखना चाहिए.

• [C-1-2] स्क्रीन पिन करने की सुविधा को लागू करना ज़रूरी है. साथ ही, उपयोगकर्ता को इस सुविधा को टॉगल करने के लिए, सेटिंग मेन्यू उपलब्ध कराना ज़रूरी है.

• हाल ही में इस्तेमाल किए गए आइटम में, हाइलाइट का रंग, आइकॉन, और स्क्रीन का टाइटल दिखना चाहिए.
• इसमें बंद करने का विकल्प ("x") दिखना चाहिए. हालांकि, उपयोगकर्ता के स्क्रीन से इंटरैक्ट करने तक इसे दिखाने में देरी की जा सकती है.
• पिछली गतिविधि पर आसानी से स्विच करने के लिए, शॉर्टकट लागू करना चाहिए.
• हाल ही में इस्तेमाल किए गए फ़ंक्शन बटन पर दो बार टैप करने पर, हाल ही में इस्तेमाल किए गए दो ऐप्लिकेशन के बीच तुरंत स्विच करने की सुविधा चालू होनी चाहिए.
• अगर डिवाइस में स्प्लिट-स्क्रीन मल्टीविंडो मोड की सुविधा काम करती है, तो हाल ही के फ़ंक्शन की बटन को दबाकर रखने पर, यह मोड चालू हो जाना चाहिए.
• हाल ही में देखे गए ऐसे वीडियो को एक ग्रुप के तौर पर दिखाया जा सकता है जो एक साथ चलते हैं.
• [C-SR-1] हमारा सुझाव है कि खास जानकारी वाली स्क्रीन के लिए, अपस्ट्रीम Android यूज़र इंटरफ़ेस (या थंबनेल पर आधारित मिलते-जुलते इंटरफ़ेस) का इस्तेमाल करें.

3.8.9. इनपुट मैनेजमेंट

Android में, इनपुट मैनेजमेंट और तीसरे पक्ष के इनपुट के तरीके के एडिटर के लिए सहायता शामिल है.

अगर डिवाइस पर, उपयोगकर्ताओं को तीसरे पक्ष के इनपुट तरीकों का इस्तेमाल करने की अनुमति है, तो वे:

• [C-1-1] Android SDK के दस्तावेज़ में बताए गए मुताबिक, प्लैटफ़ॉर्म की सुविधा android.software.input_methods का एलान करना ज़रूरी है. साथ ही, IME API के साथ काम करना ज़रूरी है.

3.8.10. लॉक स्क्रीन पर मीडिया कंट्रोल

Android 5.0 के बाद, रिमोट कंट्रोल क्लाइंट एपीआई का इस्तेमाल नहीं किया जा सकता. इसके बजाय, मीडिया सूचना टेंप्लेट का इस्तेमाल किया जा सकता है. इससे मीडिया ऐप्लिकेशन, लॉक स्क्रीन पर दिखने वाले प्लेबैक कंट्रोल के साथ इंटिग्रेट हो सकते हैं.

3.8.11. स्क्रीन सेवर (पहले इन्हें ड्रीम्स कहा जाता था)

स्क्रीन सेवर को कॉन्फ़िगर करने के लिए, सेटिंग के इंटेंट के बारे में जानने के लिए सेक्शन 3.2.3.5 देखें.

3.8.12. जगह की जानकारी

अगर डिवाइस में कोई ऐसा हार्डवेयर सेंसर (जैसे, जीपीएस) शामिल है जो जगह की जानकारी के निर्देशांक दे सकता है, तो

• [C-1-2] सेटिंग में मौजूद जगह की जानकारी वाले मेन्यू में, जगह की जानकारी का मौजूदा स्टेटस दिखाना ज़रूरी है.
• [C-1-3] सेटिंग में जगह की जानकारी वाले मेन्यू में, जगह की जानकारी के मोड नहीं दिखाए जाने चाहिए.

3.8.13. यूनिकोड और फ़ॉन्ट

Android में, यूनिकोड 10.0 में बताए गए इमोजी वर्णों के इस्तेमाल की सुविधा शामिल है.

अगर डिवाइस में स्क्रीन या वीडियो आउटपुट शामिल है, तो:

• [C-1-1] इन इमोजी वर्ण को कलर ग्लिफ़ में रेंडर करने की सुविधा होनी चाहिए.
• [C-1-2] इसमें इनके लिए सहायता शामिल होनी चाहिए:
  • डिवाइस पर उपलब्ध भाषाओं के लिए, अलग-अलग वेट वाला Roboto 2 फ़ॉन्ट—sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed, sans-serif-condensed-light.
  • यूनिकोड 7.0 में, लैटिन, ग्रीक, और सिरिलिक भाषाओं के लिए पूरी कवरेज. इसमें लैटिन एक्सटेंडेड A, B, C, और D रेंज के साथ-साथ, यूनिकोड 7.0 के मुद्रा के चिह्नों वाले ब्लॉक में मौजूद सभी ग्लिफ़ शामिल हैं.
• [C-1-3] सिस्टम इमेज में NotoColorEmoji.tff को न तो हटाएं और न ही उसमें बदलाव करें. (NotoColorEmoji.tff में मौजूद इमोजी को बदलने के लिए, नया इमोजी फ़ॉन्ट जोड़ा जा सकता है)
• यूनिकोड तकनीकी रिपोर्ट #51 में बताए गए मुताबिक, स्किन टोन और अलग-अलग फ़ैमिली इमोजी के साथ काम करना चाहिए.

अगर डिवाइस में लागू किए गए IME में कोई IME शामिल है, तो:

• इन इमोजी वर्ण के लिए, उपयोगकर्ता को इनपुट का तरीका उपलब्ध कराना चाहिए.

Android में म्यांमार फ़ॉन्ट रेंडर करने की सुविधा शामिल है. म्यांमार में कई ऐसे फ़ॉन्ट हैं जो यूनिकोड के मुताबिक नहीं हैं. इन्हें आम तौर पर “ज़ॉग्यी” कहा जाता है. इनका इस्तेमाल, म्यांमार की भाषाओं को रेंडर करने के लिए किया जाता है.

अगर डिवाइस पर बर्मी भाषा के लिए सहायता शामिल है, तो:

• [C-2-1] टेक्स्ट को डिफ़ॉल्ट रूप से यूनिकोड फ़ॉन्ट में रेंडर करना चाहिए. ऐसा तब तक नहीं किया जाना चाहिए, जब तक कि उपयोगकर्ता भाषा चुनने वाले टूल में किसी दूसरे फ़ॉन्ट को न चुन ले.
• [C-2-2] डिवाइस पर यूनिकोड फ़ॉन्ट के साथ-साथ, ऐसे फ़ॉन्ट का भी इस्तेमाल किया जा सकता है जो यूनिकोड के साथ काम नहीं करता. यूनिकोड के मुताबिक न बने फ़ॉन्ट को, यूनिकोड फ़ॉन्ट को न तो हटाना चाहिए और न ही उस पर ओवरराइट करना चाहिए.
• [C-2-3] टेक्स्ट को ऐसे फ़ॉन्ट में रेंडर करना ज़रूरी है जो यूनिकोड के मुताबिक न हो. ऐसा सिर्फ़ तब करना चाहिए, जब स्क्रिप्ट कोड Qaag वाला भाषा कोड (उदाहरण के लिए, my-Qaag) दिया गया हो. म्यांमार के लिए, यूनिकोड के मुताबिक न होने वाले फ़ॉन्ट का रेफ़रंस देने के लिए, किसी भी अन्य ISO भाषा या इलाके के कोड (चाहे असाइन किए गए हों, असाइन नहीं किए गए हों या रिज़र्व किए गए हों) का इस्तेमाल नहीं किया जा सकता. ऐप्लिकेशन डेवलपर और वेब पेज के लेखक, my-Qaag को भाषा के लिए तय किए गए कोड के तौर पर बता सकते हैं, जैसे कि वे किसी दूसरी भाषा के लिए बताते हैं.

3.8.14. मल्टी-विंडो (एक से ज़्यादा ऐप्लिकेशन, एक साथ)

अगर डिवाइस पर एक साथ कई गतिविधियां दिख सकती हैं, तो:

• [C-1-1] Android SDK के मल्टी-विंडो मोड के लिए सहायता दस्तावेज़ में बताए गए ऐप्लिकेशन के व्यवहार और एपीआई के मुताबिक, ऐसे मल्टी-विंडो मोड लागू करना ज़रूरी है. साथ ही, इन ज़रूरी शर्तों को पूरा करना ज़रूरी है:
• [C-1-2] इस SDK टूल में बताए गए तरीके के मुताबिक, AndroidManifest.xml फ़ाइल में ऐप्लिकेशन से सेट की गई android:resizeableActivity का पालन करना ज़रूरी है.
• [C-1-3] अगर स्क्रीन की ऊंचाई 440 dp और चौड़ाई 440 dp से कम है, तो स्प्लिट-स्क्रीन या फ़्रीफ़ॉर्म मोड की सुविधा नहीं दी जानी चाहिए.
• [C-1-4] किसी गतिविधि का साइज़, पिक्चर में पिक्चर मोड के अलावा, कई विंडो वाले मोड में 220dp से कम नहीं होना चाहिए.
• स्क्रीन साइज़ xlarge वाले डिवाइसों पर, फ़्रीफ़ॉर्म मोड काम करना चाहिए.

अगर डिवाइस पर मल्टी-विंडो मोड और स्प्लिट स्क्रीन मोड काम करते हैं, तो:

• [C-2-2] स्प्लिट-स्क्रीन वाली मल्टी-विंडो में, डॉक की गई गतिविधि को काटना ज़रूरी है. हालांकि, अगर लॉन्चर ऐप्लिकेशन फ़ोकस की गई विंडो है, तो उसका कुछ कॉन्टेंट दिखाना चाहिए.
• [C-2-3] तीसरे पक्ष के लॉन्चर ऐप्लिकेशन की बताई गई AndroidManifestLayout_minWidth और AndroidManifestLayout_minHeight वैल्यू का पालन करना ज़रूरी है. साथ ही, डॉक की गई गतिविधि का कुछ कॉन्टेंट दिखाने के दौरान, इन वैल्यू को बदलना नहीं चाहिए.

अगर डिवाइस पर मल्टी-विंडो मोड और पिक्चर में पिक्चर वाले मल्टी-विंडो मोड काम करते हैं, तो:

• [C-3-1] ऐप्लिकेशन के इन स्थितियों में, गतिविधियों को पिक्चर में पिक्चर वाले मल्टी-विंडो मोड में लॉन्च करना ज़रूरी है: * ऐप्लिकेशन, एपीआई लेवल 26 या उसके बाद के वर्शन को टारगेट करता हो और android:supportsPictureInPicture का एलान करता हो * ऐप्लिकेशन, एपीआई लेवल 25 या उससे पहले के वर्शन को टारगेट करता हो और android:resizeableActivity और android:supportsPictureInPicture, दोनों का एलान करता हो.
• [C-3-2] setActions() API के ज़रिए, मौजूदा पीआईपी गतिविधि के मुताबिक, अपने SystemUI में ऐक्शन दिखाना ज़रूरी है.
• [C-3-3] आसपेक्ट रेशियो 1:2.39 से ज़्यादा या उसके बराबर और 2.39:1 से कम या उसके बराबर होना चाहिए. जैसा कि setAspectRatio() एपीआई के ज़रिए पीआईपी गतिविधि में बताया गया है.
• [C-3-4] पीआईपी विंडो को कंट्रोल करने के लिए, KeyEvent.KEYCODE_WINDOW का इस्तेमाल करना ज़रूरी है. अगर पीआईपी मोड लागू नहीं किया गया है, तो फ़ोरग्राउंड गतिविधि के लिए बटन उपलब्ध होना चाहिए.
• [C-3-5] उपयोगकर्ता को यह सुविधा देनी चाहिए कि वह किसी ऐप्लिकेशन को पीआईपी मोड में दिखने से रोक सके. AOSP में, सूचना शेड में कंट्रोल होने की वजह से यह ज़रूरी शर्त पूरी हो जाती है.

• [C-3-6] अगर कोई ऐप्लिकेशन AndroidManifestLayout_minWidth और AndroidManifestLayout_minHeight के लिए कोई वैल्यू नहीं तय करता है, तो पीआईपी विंडो के लिए कम से कम यह चौड़ाई और ऊंचाई तय करना ज़रूरी है:

  • जिन डिवाइसों में Configuration.uiMode की वैल्यू, UI_MODE_TYPE_TELEVISION के अलावा किसी दूसरी वैल्यू पर सेट है उनके लिए, कम से कम 108 डीपी की चौड़ाई और ऊंचाई तय करना ज़रूरी है.
  • जिन डिवाइसों में Configuration.uiMode को UI_MODE_TYPE_TELEVISION पर सेट किया गया है उनके लिए, कम से कम 240 dp चौड़ाई और 135 dp ऊंचाई का फ़्रेम तय करना ज़रूरी है.

3.8.15. डिसप्ले कटआउट

Android, डिसप्ले कटिंग की सुविधा के साथ काम करता है. इस बारे में, SDK टूल के दस्तावेज़ में बताया गया है. DisplayCutout एपीआई, डिसप्ले के किनारे पर मौजूद उस जगह की जानकारी देता है जो ऐप्लिकेशन के लिए काम की नहीं हो सकती. ऐसा, किनारे पर मौजूद डिसप्ले के कटी हुई जगह या घुमावदार डिसप्ले की वजह से हो सकता है.

अगर डिवाइस में डिसप्ले कटआउट शामिल हैं, तो:

• [C-1-5] अगर डिवाइस का आसपेक्ट रेशियो 1.0(1:1) है, तो उसमें कोई कटआउट नहीं होना चाहिए.
• [C-1-2] हर किनारे पर एक से ज़्यादा कट्सआउट नहीं होने चाहिए.
• [C-1-3] ऐप्लिकेशन को, डिसप्ले में काट-छांट करने के लिए, WindowManager.LayoutParams एपीआई के ज़रिए सेट किए गए फ़्लैग का पालन करना चाहिए. इस बारे में एसडीके में बताया गया है.
• [C-1-4] DisplayCutout एपीआई में तय की गई सभी कटआउट मेट्रिक के लिए, सही वैल्यू रिपोर्ट करना ज़रूरी है.

3.8.16. डिवाइस कंट्रोल

Android में ControlsProviderService और Control एपीआई शामिल हैं. इनकी मदद से, तीसरे पक्ष के ऐप्लिकेशन, डिवाइस के कंट्रोल पब्लिश कर सकते हैं, ताकि उपयोगकर्ताओं को डिवाइस की स्थिति और कार्रवाई के बारे में तुरंत जानकारी मिल सके.

डिवाइस से जुड़ी ज़रूरी शर्तों के बारे में जानने के लिए, सेक्शन 2_2_3 देखें.

3.8.17. क्लिपबोर्ड

डिवाइस पर लागू करने के तरीके:

• [C-0-1] क्लिपबोर्ड का डेटा, किसी भी कॉम्पोनेंट, गतिविधि, सेवा या किसी भी नेटवर्क कनेक्शन पर, उपयोगकर्ता की साफ़ तौर पर की गई कार्रवाई (उदाहरण के लिए, ओवरले पर बटन दबाना) या भेजे जा रहे कॉन्टेंट के संकेत के बिना नहीं भेजा जाना चाहिए. हालांकि, 9.8.6 कॉन्टेंट कैप्चर और ऐप्लिकेशन सर्च में बताई गई सेवाओं के लिए ऐसा किया जा सकता है.

अगर डिवाइस पर कॉन्टेंट को क्लिपबोर्ड पर कॉपी करने पर, उपयोगकर्ता को दिखने वाली झलक जनरेट होती है, तो:ClipDataClipData.getDescription().getExtras()android.content.extra.IS_SENSITIVE

• [C-1-1] उपयोगकर्ता को दिखने वाली झलक में, संवेदनशील जानकारी को छिपाना ज़रूरी है

AOSP के रेफ़रंस के तौर पर लागू किया गया तरीका, क्लिपबोर्ड से जुड़ी इन ज़रूरी शर्तों को पूरा करता है.

3.9. डिवाइस प्रबंधन

Android में ऐसी सुविधाएं शामिल हैं जिनकी मदद से, सुरक्षा के बारे में जानकारी रखने वाले ऐप्लिकेशन, सिस्टम लेवल पर डिवाइस मैनेजमेंट फ़ंक्शन कर सकते हैं. जैसे, Android डिवाइस एडमिनिस्ट्रेशन एपीआई की मदद से, पासवर्ड की नीतियों को लागू करना या डिवाइस को रिमोट से मिटाना.

अगर डिवाइस पर, Android SDK टूल के दस्तावेज़ में बताई गई डिवाइस मैनेजमेंट की सभी नीतियों को लागू किया जाता है, तो:

• [C-1-1] android.software.device_admin का एलान करना ज़रूरी है.
• [C-1-2] डिवाइस के मालिक को डिवाइस सेट अप करने की सुविधा देनी चाहिए, जैसा कि सेक्शन 3.9.1 और सेक्शन 3.9.1.1 में बताया गया है.

3.9.1 डिवाइस प्रॉविज़निंग

3.9.1.1 डिवाइस के मालिक के लिए प्रॉविज़निंग

अगर डिवाइस पर android.software.device_admin लागू किया जाता है, तो:

• [C-1-1] डिवाइस नीति क्लाइंट (डीपीसी) को डिवाइस के मालिक के ऐप्लिकेशन के तौर पर रजिस्टर करने की सुविधा होनी चाहिए. इसके लिए, यह ज़रूरी है कि:
  • जब डिवाइस पर लागू किए गए नीति के लिए, उपयोगकर्ताओं और उपयोगकर्ता के डेटा, दोनों को कॉन्फ़िगर नहीं किया गया है, तो:
    • [C-1-5] अगर डिवाइस, सुविधा फ़्लैग android.hardware.nfc के ज़रिए नियर-फ़ील्ड कम्यूनिकेशन (एनएफ़सी) के साथ काम करने की जानकारी देता है और उसे एनएफ़सी मैसेज मिलता है, जिसमें MIME टाइप MIME_TYPE_PROVISIONING_NFC वाला रिकॉर्ड होता है, तो DPC ऐप्लिकेशन को डिवाइस के मालिक के ऐप्लिकेशन के तौर पर रजिस्टर करना ज़रूरी है या DPC ऐप्लिकेशन को यह चुनने की अनुमति देनी होगी कि वह डिवाइस का मालिक बनेगा या प्रोफ़ाइल का मालिक.
    • [C-1-8] डिवाइस के मालिक के लिए डिवाइस सेट अप करने की सुविधा ट्रिगर होने के बाद, ACTION_GET_PROVISIONING_MODE इंटेंट भेजना ज़रूरी है, ताकि डीपीसी ऐप्लिकेशन यह चुन सके कि उसे डिवाइस का मालिक बनाना है या प्रोफ़ाइल का मालिक. यह विकल्प, android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES की वैल्यू के आधार पर तय किया जाता है. ऐसा तब तक करना होगा, जब तक कॉन्टेक्स्ट से यह पता नहीं चल जाता कि सिर्फ़ एक मान्य विकल्प है.
    • [C-1-9] डिवाइस के मालिक के ऐप्लिकेशन को ACTION_ADMIN_POLICY_COMPLIANCE इंटेंट भेजना ज़रूरी है. ऐसा तब करना होगा, जब डिवाइस के मालिक की जानकारी, डिवाइस को कॉन्फ़िगर करने के दौरान डाली गई हो. भले ही, डिवाइस को कॉन्फ़िगर करने के लिए किसी भी तरीके का इस्तेमाल किया गया हो. डिवाइस के मालिक का ऐप्लिकेशन पूरा होने तक, उपयोगकर्ता को सेटअप विज़र्ड में आगे बढ़ने की अनुमति नहीं मिलनी चाहिए.
  • जब डिवाइस पर लागू किए गए ऐप्लिकेशन में उपयोगकर्ता या उपयोगकर्ता का डेटा मौजूद हो, तो:
    • [C-1-7] अब किसी भी डीपीसी ऐप्लिकेशन को डिवाइस के मालिक के ऐप्लिकेशन के तौर पर रजिस्टर नहीं करना चाहिए.

• [C-1-2] ऐप्लिकेशन को डिवाइस के मालिक के तौर पर सेट करने से पहले, ज़ाहिर की जाने वाली जानकारी की सही सूचना दिखाना ज़रूरी है. जैसे, AOSP में दी गई जानकारी. साथ ही, असली उपयोगकर्ता से सहमति लेना ज़रूरी है. हालांकि, अगर डिवाइस को स्क्रीन पर असली उपयोगकर्ता के इंटरैक्शन से पहले, प्रोग्राम के हिसाब से रीटेल डेमो मोड के लिए कॉन्फ़िगर किया गया है, तो ऐसा करना ज़रूरी नहीं है. अगर डिवाइस के लागू होने की जानकारी में android.software.device_admin का एलान किया गया है, लेकिन इसमें डिवाइस मैनेजमेंट का मालिकाना हक वाला समाधान भी शामिल है और अपने समाधान में कॉन्फ़िगर किए गए ऐप्लिकेशन को "डिवाइस के मालिक के बराबर" के तौर पर प्रमोट करने का तरीका भी दिया गया है, तो:

• [C-2-1] यह ज़रूरी है कि आपके पास यह पुष्टि करने की प्रोसेस हो कि जिस ऐप्लिकेशन का प्रमोशन किया जा रहा है वह किसी मान्य एंटरप्राइज़ डिवाइस मैनेजमेंट सलूशन से जुड़ा हो. साथ ही, उसे मालिकाना हक वाले सलूशन में कॉन्फ़िगर किया गया हो, ताकि उसके पास "डिवाइस के मालिक" के बराबर अधिकार हों.

• [C-2-2] DPC ऐप्लिकेशन को "डिवाइस के मालिक" के तौर पर रजिस्टर करने से पहले, डिवाइस के मालिक के तौर पर सहमति देने के लिए, AOSP में बताई गई वही जानकारी ज़ाहिर करनी होगी जो android.app.action.PROVISION_MANAGED_DEVICE ने शुरू की थी.

• [C-2-3] ऐप्लिकेशन को सहमति को हार्ड कोड नहीं करना चाहिए या डिवाइस के मालिक के दूसरे ऐप्लिकेशन के इस्तेमाल को रोकना चाहिए.

3.9.1.2 मैनेज की जा रही प्रोफ़ाइल को डिवाइस पर सेट अप करना

अगर डिवाइस पर android.software.managed_users लागू किया जाता है, तो:

• [C-1-1] एपीआई लागू करने ज़रूरी हैं, ताकि डिवाइस नीति नियंत्रक (डीपीसी) ऐप्लिकेशन, मैनेज की जा रही नई प्रोफ़ाइल का मालिक बन सके.

• [C-1-2] मैनेज की जा रही प्रोफ़ाइल को उपलब्ध कराने की प्रोसेस (android.app.action.PROVISION_MANAGED_PROFILE का इस्तेमाल करके डीपीसी से शुरू किया गया फ़्लो) या प्लैटफ़ॉर्म से, सहमति स्क्रीन और उपयोगकर्ता अनुभव को एओएसपी के लागू होने के साथ अलाइन करना ज़रूरी है.

• [C-1-3] डिवाइस नीति कंट्रोलर (डीपीसी) की ओर से किसी खास सिस्टम फ़ंक्शन को बंद किए जाने पर, उपयोगकर्ता को इसकी जानकारी देने के लिए, सेटिंग में ये सुविधाएं उपलब्ध कराई जानी चाहिए:

  • डिवाइस एडमिन ने किसी सेटिंग पर पाबंदी लगाई है, तो यह बताने के लिए एक आइकॉन या उपयोगकर्ता के लिए कोई अन्य सुविधा (उदाहरण के लिए, अपस्ट्रीम AOSP का जानकारी वाला आइकॉन).
  • setShortSupportMessage के ज़रिए डिवाइस एडमिन की ओर से दिया गया, कम शब्दों में जानकारी देने वाला मैसेज.
  • डीपीसी ऐप्लिकेशन का आइकॉन.

• [C-1-4] अगर android.app.action.PROVISION_MANAGED_PROFILE इंटेंट से प्रोवाइज़निंग शुरू करने पर, प्रोफ़ाइल का मालिक तय हो जाता है और डीपीसी ने हैंडलर लागू कर दिया है, तो वर्क प्रोफ़ाइल में ACTION_PROVISIONING_SUCCESSFUL इंटेंट के लिए हैंडलर लॉन्च करना ज़रूरी है.

• [C-1-5] android.app.action.PROVISION_MANAGED_PROFILE के ज़रिए प्रोविज़न करने की प्रोसेस शुरू होने पर, वर्क प्रोफ़ाइल के डीपीसी को ACTION_PROFILE_PROVISIONING_COMPLETE ब्रॉडकास्ट भेजना ज़रूरी है.

• [C-1-6] प्रोफ़ाइल के मालिक के लिए डिवाइस को प्रोवाइड करने की सुविधा ट्रिगर होने के बाद, ACTION_GET_PROVISIONING_MODE इंटेंट भेजना ज़रूरी है. इससे डीपीसी ऐप्लिकेशन यह चुन सकता है कि उसे डिवाइस का मालिक बनाना है या प्रोफ़ाइल का. हालांकि, अगर इंटेंट android.app.action.PROVISION_MANAGED_PROFILE से प्रोवाइड करने की सुविधा ट्रिगर होती है, तो ऐसा नहीं करना होगा.

• [C-1-7] प्रोवाइज़न करने के दौरान, अगर प्रोफ़ाइल का मालिक तय किया जाता है, तो वर्क प्रोफ़ाइल को ACTION_ADMIN_POLICY_COMPLIANCE इंटेंट भेजना ज़रूरी है. इससे कोई फ़र्क़ नहीं पड़ता कि प्रोवाइज़न करने के लिए किस तरीके का इस्तेमाल किया जा रहा है. हालांकि, अगर प्रोवाइज़न करने की प्रोसेस, android.app.action.PROVISION_MANAGED_PROFILE इंटेंट से ट्रिगर होती है, तो ऐसा करना ज़रूरी नहीं है. जब तक Profile Owner ऐप्लिकेशन इंस्टॉल नहीं हो जाता, तब तक उपयोगकर्ता को सेटअप विज़र्ड में आगे बढ़ने की अनुमति नहीं मिलनी चाहिए.

• [C-1-8] प्रोफ़ाइल का मालिक तय होने पर, निजी प्रोफ़ाइल के डीपीसी को ACTION_MANAGED_PROFILE_PROVISIONED ब्रॉडकास्ट भेजना ज़रूरी है. भले ही, प्रोफ़ाइल को उपलब्ध कराने का तरीका कुछ भी हो.

3.9.2 मैनेज की जा रही प्रोफ़ाइल के लिए सहायता

अगर डिवाइस पर android.software.managed_users लागू किया जाता है, तो:

• [C-1-1] android.app.admin.DevicePolicyManager एपीआई की मदद से, मैनेज की जा रही प्रोफ़ाइलों को इस्तेमाल करने की सुविधा होनी चाहिए.
• [C-1-2] सिर्फ़ एक मैनेज की जा रही प्रोफ़ाइल बनाने की अनुमति होनी चाहिए.
• [C-1-3] मैनेज किए जा रहे ऐप्लिकेशन और विजेट के साथ-साथ, बैज वाले अन्य यूज़र इंटरफ़ेस (यूआई) एलिमेंट को दिखाने के लिए, आइकॉन बैज का इस्तेमाल करना ज़रूरी है. जैसे, हाल ही में इस्तेमाल किए गए ऐप्लिकेशन और सूचनाएं. यह बैज, AOSP अपस्ट्रीम वर्क बैज जैसा होना चाहिए.
• [C-1-4] यह ज़रूरी है कि जब उपयोगकर्ता मैनेज की जा रही प्रोफ़ाइल वाले ऐप्लिकेशन का इस्तेमाल कर रहा हो, तब सूचना आइकॉन दिखे. यह आइकॉन, AOSP अपस्ट्रीम वर्क बैज जैसा होना चाहिए.
• [C-1-5] डिवाइस के चालू होने (ACTION_USER_PRESENT) और फ़ोरग्राउंड ऐप्लिकेशन के मैनेज की गई प्रोफ़ाइल में होने पर, उपयोगकर्ता को एक टॉस्ट दिखाना ज़रूरी है. इस टॉस्ट से यह पता चलना चाहिए कि उपयोगकर्ता मैनेज की गई प्रोफ़ाइल में है.
• [C-1-6] अगर कोई मैनेज की जा रही प्रोफ़ाइल मौजूद है, तो इंटेंट 'चुने जाने वाले' में विज़ुअल अवफ़र्डेंस दिखाना ज़रूरी है. इससे उपयोगकर्ता, मैनेज की जा रही प्रोफ़ाइल से प्राइमरी उपयोगकर्ता को इंटेंट फ़ॉरवर्ड कर सकता है. इसके अलावा, अगर डिवाइस नीति कंट्रोलर की ओर से चालू किया गया है, तो प्राइमरी उपयोगकर्ता से मैनेज की जा रही प्रोफ़ाइल को इंटेंट फ़ॉरवर्ड किया जा सकता है.
• [C-1-7] अगर कोई मैनेज की जा रही प्रोफ़ाइल मौजूद है, तो प्राइमरी उपयोगकर्ता और मैनेज की जा रही प्रोफ़ाइल, दोनों के लिए ये सुविधाएं ज़रूर उपलब्ध कराएं:
  • प्राइमरी उपयोगकर्ता और मैनेज की जा रही प्रोफ़ाइल के लिए, बैटरी, जगह की जानकारी, मोबाइल डेटा, और स्टोरेज के इस्तेमाल का अलग-अलग हिसाब.
  • मुख्य उपयोगकर्ता या मैनेज की जा रही प्रोफ़ाइल में इंस्टॉल किए गए वीपीएन ऐप्लिकेशन को अलग से मैनेज किया जा सकता है.
  • मुख्य उपयोगकर्ता या मैनेज की जा रही प्रोफ़ाइल में इंस्टॉल किए गए ऐप्लिकेशन को अलग से मैनेज किया जा सकता है.
  • मुख्य उपयोगकर्ता या मैनेज की जा रही प्रोफ़ाइल में मौजूद खातों को अलग से मैनेज करना.
• [C-1-8] यह पक्का करना ज़रूरी है कि पहले से इंस्टॉल किए गए डायलर, संपर्क, और मैसेजिंग ऐप्लिकेशन, डिवाइस नीति कंट्रोलर की अनुमति मिलने पर, प्राइमरी प्रोफ़ाइल के साथ-साथ मैनेज की जा रही प्रोफ़ाइल (अगर कोई मौजूद है) से भी कॉलर की जानकारी खोज और देख सकें.
• [C-1-9] यह पक्का करना ज़रूरी है कि यह उन सभी सुरक्षा ज़रूरी शर्तों को पूरा करता हो जो एक से ज़्यादा उपयोगकर्ताओं के लिए चालू किए गए डिवाइस पर लागू होती हैं (सेक्शन 9.5 देखें). भले ही, मैनेज की जा रही प्रोफ़ाइल को मुख्य उपयोगकर्ता के अलावा किसी दूसरे उपयोगकर्ता के तौर पर नहीं गिना जाता.

नई ज़रूरी शर्तें लागू करना

• [C-1-10] यह पक्का करना ज़रूरी है कि स्क्रीनशॉट का डेटा, वर्क प्रोफ़ाइल के स्टोरेज में सेव हो. ऐसा तब होगा, जब स्क्रीनशॉट किसी ऐसी topActivity विंडो से लिया गया हो जिस पर फ़ोकस हो (जिस पर उपयोगकर्ता ने सभी गतिविधियों में से आखिरी बार इंटरैक्ट किया हो) और वह वर्क प्रोफ़ाइल ऐप्लिकेशन से जुड़ी हो.
• [C-1-11] वर्क प्रोफ़ाइल में स्क्रीनशॉट सेव करते समय, वर्क प्रोफ़ाइल ऐप्लिकेशन की विंडो/विंडो के अलावा, स्क्रीन का कोई अन्य कॉन्टेंट (सिस्टम बार, सूचनाएं या निजी प्रोफ़ाइल का कोई कॉन्टेंट) कैप्चर नहीं किया जाना चाहिए. इससे यह पक्का किया जा सकेगा कि निजी प्रोफ़ाइल का डेटा, वर्क प्रोफ़ाइल में सेव न हो.

नई ज़रूरी शर्तें खत्म करना

अगर डिवाइस पर android.software.managed_users और android.software.secure_lock_screen का एलान किया जाता है, तो:

• [C-2-1] यह ज़रूरी है कि डिवाइस पर, अलग लॉक स्क्रीन सेट की जा सके. साथ ही, यह भी ज़रूरी है कि सिर्फ़ मैनेज की जा रही प्रोफ़ाइल में चल रहे ऐप्लिकेशन को ऐक्सेस करने के लिए, लॉक स्क्रीन सेट करने की इन ज़रूरी शर्तों को पूरा किया जा सके.
  • डिवाइस पर लागू करने के लिए, DevicePolicyManager.ACTION_SET_NEW_PASSWORD के इंटेंट का पालन करना ज़रूरी है. साथ ही, मैनेज की जा रही प्रोफ़ाइल के लिए, लॉक स्क्रीन का अलग क्रेडेंशियल कॉन्फ़िगर करने के लिए इंटरफ़ेस दिखाना ज़रूरी है.
  • मैनेज की जा रही प्रोफ़ाइल की लॉक स्क्रीन के क्रेडेंशियल के लिए, वही क्रेडेंशियल स्टोरेज और मैनेजमेंट का तरीका इस्तेमाल करना ज़रूरी है जो पैरंट प्रोफ़ाइल के लिए इस्तेमाल किया जाता है. इस बारे में Android Open Source Project की साइट पर जानकारी दी गई है.
  • डीपीसी की पासवर्ड नीतियां, सिर्फ़ मैनेज की जा रही प्रोफ़ाइल की लॉक स्क्रीन के क्रेडेंशियल पर लागू होनी चाहिए. ऐसा तब तक करना ज़रूरी है, जब तक getParentProfileInstance से मिले DevicePolicyManager इंस्टेंस पर कॉल नहीं किया जाता.
• जब मैनेज की जा रही प्रोफ़ाइल के संपर्क, पहले से इंस्टॉल किए गए कॉल लॉग, कॉल के दौरान दिखने वाले यूज़र इंटरफ़ेस, कॉल के दौरान और छूटे हुए कॉल की सूचनाओं, संपर्कों, और मैसेजिंग ऐप्लिकेशन में दिखते हैं, तो उन्हें उसी बैज के साथ दिखाया जाना चाहिए जिसका इस्तेमाल मैनेज की जा रही प्रोफ़ाइल के ऐप्लिकेशन के लिए किया जाता है.

3.9.3 मैनेज किए जा रहे उपयोगकर्ता के लिए सहायता

अगर डिवाइस पर android.software.managed_users लागू किया जाता है, तो:

• [C-1-1] उपयोगकर्ता को मौजूदा उपयोगकर्ता से लॉग आउट करने और कई उपयोगकर्ता वाले सेशन में प्राइमरी उपयोगकर्ता पर वापस स्विच करने के लिए, उपयोगकर्ता को अवसर देना ज़रूरी है. ऐसा तब करना होगा, जब isLogoutEnabled true दिखाए. डिवाइस को अनलॉक किए बिना, लॉकस्क्रीन से यूज़र अफ़र्डेंस को ऐक्सेस किया जा सकता है.

अगर डिवाइस पर android.software.device_admin का एलान किया जाता है और सेकंडरी उपयोगकर्ता जोड़ने के लिए, डिवाइस पर उपयोगकर्ता के लिए कोई सुविधा उपलब्ध कराई जाती है, तो:

• [C-SR-1] हमारा सुझाव है कि डिवाइस के मालिक की सहमति से जुड़ी जानकारी ज़ाहिर करने के लिए, AOSP के उसी फ़ॉर्म का इस्तेमाल करें जो android.app.action.PROVISION_MANAGED_DEVICE से शुरू होने वाले फ़्लो में दिखाया गया था. ऐसा इसलिए, ताकि उपयोगकर्ता यह समझ सकें कि डिवाइस मैनेज किया जा रहा है. साथ ही, नए सेकंडरी उपयोगकर्ता के खाते जोड़ने की अनुमति देने से पहले, ऐसा करना ज़रूरी है.

3.9.4 डिवाइस नीति मैनेजमेंट की भूमिका से जुड़ी ज़रूरी शर्तें

अगर डिवाइस पर लागू करने की रिपोर्ट में android.software.device_admin या android.software.managed_users दिखता है, तो इसका मतलब है कि:

• [C-1-1] यह ज़रूरी है कि यह सेक्शन 9.1 में बताई गई डिवाइस नीति मैनेजमेंट भूमिका के साथ काम करे. डिवाइस नीति मैनेजमेंट की भूमिका वाले ऐप्लिकेशन को, पैकेज के नाम के तौर पर config_devicePolicyManagement सेट करके तय किया जा सकता है. अगर ऐप्लिकेशन पहले से लोड नहीं किया गया है, तो पैकेज के नाम के बाद : और हस्ताक्षर करने के सर्टिफ़िकेट का होना ज़रूरी है.

अगर ऊपर बताए गए तरीके से, config_devicePolicyManagement के लिए पैकेज का नाम तय नहीं किया गया है, तो:

• [C-2-1] डिवाइस पर लागू किए गए वर्शन में, डिवाइस नीति मैनेजमेंट की भूमिका रखने वाले ऐप्लिकेशन के बिना भी डिवाइस को डिवाइस के तौर पर इस्तेमाल करने की सुविधा चालू करने की सुविधा होनी चाहिए (AOSP, डिवाइस को डिवाइस के तौर पर इस्तेमाल करने की सुविधा चालू करने का रेफ़रंस देता है).

अगर ऊपर बताए गए तरीके से 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.9.5 डिवाइस नीति से जुड़ी समस्या हल करने का फ़्रेमवर्क

अगर डिवाइस पर लागू करने की रिपोर्ट में android.software.device_admin या android.software.managed_users दिखता है, तो इसका मतलब है कि:

• [C-1-1] डिवाइस नीति से जुड़ी समस्याओं को हल करने के फ़्रेमवर्क में बताए गए तरीके के मुताबिक, डिवाइस नीति से जुड़ी समस्याओं को हल करना ज़रूरी है.

नई ज़रूरी शर्तें खत्म करना

3.10. सुलभता

Android में सुलभता लेयर की सुविधा उपलब्ध होती है. इससे, दिव्यांग उपयोगकर्ताओं को अपने डिवाइसों को आसानी से इस्तेमाल करने में मदद मिलती है. इसके अलावा, Android ऐसे प्लैटफ़ॉर्म एपीआई उपलब्ध कराता है जिनकी मदद से, सुलभता सेवा को उपयोगकर्ता और सिस्टम इवेंट के लिए कॉलबैक मिलते हैं. साथ ही, टेक्स्ट-टू-स्पीच, हैप्टिक फ़ीडबैक, और ट्रैकबॉल/डी-पैड नेविगेशन जैसे अन्य फ़ीडबैक मैकेनिज्म जनरेट किए जाते हैं.

अगर डिवाइस पर तीसरे पक्ष की सुलभता सेवाएं काम करती हैं, तो:

• [C-1-1] ऐप्लिकेशन में, Android के सुलभता फ़्रेमवर्क को लागू करना ज़रूरी है. इसके बारे में, Accessibility API के SDK दस्तावेज़ में बताया गया है.
• [C-1-2] SDK टूल में बताए गए तरीके के मुताबिक, सुलभता इवेंट जनरेट करने चाहिए और रजिस्टर किए गए सभी AccessibilityService लागू करने के लिए सही AccessibilityEvent डिलीवर करने चाहिए.
• [C-1-4] ऐक्सेसibiliti सेवाओं को कंट्रोल करने के लिए, उपयोगकर्ता को एक सुविधा देनी ज़रूरी है. ये सेवाएं, AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON का एलान करती हैं. ध्यान दें कि सिस्टम नेविगेशन बार वाले डिवाइसों के लिए, उपयोगकर्ता को सिस्टम के नेविगेशन बार में एक बटन का विकल्प देना चाहिए, ताकि वह इन सेवाओं को कंट्रोल कर सके.

अगर डिवाइस में पहले से इंस्टॉल की गई सुलभता सेवाएं शामिल हैं, तो:

• [C-2-1] अगर डेटा स्टोरेज को फ़ाइल-आधारित एन्क्रिप्शन (एफ़बीई) की मदद से एन्क्रिप्ट किया गया है, तो पहले से इंस्टॉल की गई इन सुलभता सेवाओं को डायरेक्ट बूट अवेयर ऐप्लिकेशन के तौर पर लागू करना ज़रूरी है.
• उपयोगकर्ताओं को सुलभता से जुड़ी ज़रूरी सेवाएं चालू करने के लिए, डिवाइस के सेटअप फ़्लो में एक तरीका उपलब्ध कराना चाहिए. साथ ही, फ़ॉन्ट साइज़, डिसप्ले साइज़, और ज़ूम करने के जेस्चर में बदलाव करने के विकल्प भी उपलब्ध कराने चाहिए.

3.11. लिखे गए शब्दों को सुनने की सुविधा

Android में ऐसे एपीआई शामिल हैं जिनकी मदद से ऐप्लिकेशन, टेक्स्ट को बोली में बदलने (टीटीएस) की सेवाओं का इस्तेमाल कर सकते हैं. साथ ही, सेवा देने वाली कंपनियां, टीटीएस सेवाओं को लागू कर सकती हैं.

अगर डिवाइस में android.hardware.audio.output सुविधा लागू की गई है, तो:

• [C-1-1] ऐप्लिकेशन को Android TTS फ़्रेमवर्क के एपीआई के साथ काम करना चाहिए.

अगर डिवाइस पर तीसरे पक्ष के TTS इंजन इंस्टॉल किए जा सकते हैं, तो:

• [C-2-1] सिस्टम लेवल पर इस्तेमाल करने के लिए, उपयोगकर्ता को TTS इंजन चुनने की अनुमति देने के लिए, उपयोगकर्ता के लिए सुविधाएं उपलब्ध कराएं.

3.12. टीवी इनपुट फ़्रेमवर्क

Android Television Input Framework (TIF) की मदद से, Android Television डिवाइसों पर लाइव कॉन्टेंट को आसानी से डिलीवर किया जा सकता है. TIF, Android Television डिवाइसों को कंट्रोल करने वाले इनपुट मॉड्यूल बनाने के लिए, एक स्टैंडर्ड एपीआई उपलब्ध कराता है.

अगर डिवाइस पर TIF फ़ाइलें इस्तेमाल की जा सकती हैं, तो:

• [C-1-1] प्लैटफ़ॉर्म की सुविधा android.software.live_tv के बारे में एलान करना ज़रूरी है.
• [C-1-2] यह सभी TIF एपीआई के साथ काम करना चाहिए, ताकि इन एपीआई और तीसरे पक्ष के TIF-आधारित इनपुट की सेवा का इस्तेमाल करने वाले ऐप्लिकेशन को डिवाइस पर इंस्टॉल और इस्तेमाल किया जा सके.

3.13. क्विक सेटिंग

Android में क्विक सेटिंग यूज़र इंटरफ़ेस (यूआई) कॉम्पोनेंट होता है. इससे, अक्सर इस्तेमाल होने वाली या ज़रूरत पड़ने पर तुरंत की जाने वाली कार्रवाइयों को तुरंत ऐक्सेस किया जा सकता है.

अगर डिवाइस में क्विक सेटिंग का यूज़र इंटरफ़ेस (यूआई) कॉम्पोनेंट शामिल है और तीसरे पक्ष की क्विक सेटिंग काम करती है, तो:

• [C-1-1] उपयोगकर्ता को तीसरे पक्ष के ऐप्लिकेशन से, quicksettings एपीआई के ज़रिए दी गई टाइल जोड़ने या हटाने की अनुमति देनी चाहिए.
• [C-1-2] किसी तीसरे पक्ष के ऐप्लिकेशन की टाइल को सीधे क्विक सेटिंग में अपने-आप नहीं जोड़ना चाहिए.
• [C-1-3] सिस्टम की ओर से दी गई क्विक सेटिंग टाइल के साथ-साथ, तीसरे पक्ष के ऐप्लिकेशन से उपयोगकर्ता की जोड़ी गई सभी टाइल भी दिखनी चाहिए.

3.14. मीडिया का यूज़र इंटरफ़ेस (यूआई)

अगर डिवाइस में ऐसे ऐप्लिकेशन (ऐप्लिकेशन) शामिल हैं जो बोलकर दिए गए निर्देशों पर काम नहीं करते और MediaBrowser या MediaSession के ज़रिए तीसरे पक्ष के ऐप्लिकेशन के साथ इंटरैक्ट करते हैं, तो ऐप्लिकेशन:

• [C-1-2] MediaDescription में बताए गए तरीके से, getIconBitmap() या getIconUri() से मिले आइकॉन और getTitle() से मिले टाइटल साफ़ तौर पर दिखने चाहिए. सुरक्षा से जुड़े नियमों का पालन करने के लिए, वीडियो के टाइटल छोटे किए जा सकते हैं. जैसे, ड्राइवर का ध्यान भटकाना.

• [C-1-3] तीसरे पक्ष के इस ऐप्लिकेशन से मिलने वाला कॉन्टेंट दिखाते समय, तीसरे पक्ष के ऐप्लिकेशन का आइकॉन दिखाना ज़रूरी है.

• [C-1-4] उपयोगकर्ता को पूरी MediaBrowser के साथ इंटरैक्ट करने की अनुमति देनी चाहिए. सुरक्षा से जुड़े नियमों (जैसे, ड्राइवर का ध्यान भटकना) का पालन करने के लिए, हैरारकी के कुछ हिस्से के ऐक्सेस पर पाबंदी लगाई जा सकती है. हालांकि, कॉन्टेंट या कॉन्टेंट उपलब्ध कराने वाले के आधार पर, किसी को भी प्राथमिकता नहीं दी जानी चाहिए.

• [C-1-5] MediaSession.Callback#onMediaButtonEvent के लिए, KEYCODE_HEADSETHOOK या KEYCODE_MEDIA_PLAY_PAUSE पर दो बार टैप करने को KEYCODE_MEDIA_NEXT के तौर पर स्वीकार करना ज़रूरी है.

3.15. Instant Apps

अगर डिवाइस पर इंस्टैंट ऐप्लिकेशन काम करते हैं, तो उन्हें इन ज़रूरी शर्तों को पूरा करना होगा:

• [C-1-1] Instant Apps को सिर्फ़ ऐसी अनुमतियां दी जानी चाहिए जिनके लिए android:protectionLevel को "instant" पर सेट किया गया हो.
• [C-1-2] 'झटपट ऐप्लिकेशन' को अहम इंटेंट के ज़रिए, इंस्टॉल किए गए ऐप्लिकेशन के साथ इंटरैक्ट नहीं करना चाहिए. ऐसा तब तक नहीं किया जाना चाहिए, जब तक इनमें से कोई एक बात सही न हो:
  • कॉम्पोनेंट का इंटेंट पैटर्न फ़िल्टर एक्सपोज़ किया गया है और उसमें CATEGORY_BROWSABLE है
  • यह कार्रवाई, ACTION_SEND, ACTION_SENDTO, ACTION_SEND_MULTIPLE में से कोई एक होनी चाहिए
  • टारगेट को android:visibleToInstantApps के साथ साफ़ तौर पर दिखाया गया हो
• [C-1-3] इंस्टैंट ऐप्लिकेशन को इंस्टॉल किए गए ऐप्लिकेशन के साथ तब तक इंटरैक्ट नहीं करना चाहिए, जब तक कि कॉम्पोनेंट को android:visibleToInstantApps के ज़रिए एक्सपोज़ नहीं किया जाता.
• [C-1-4] इंस्टॉल किए गए ऐप्लिकेशन को डिवाइस पर इंस्टैंट ऐप्लिकेशन की जानकारी तब तक नहीं दिखनी चाहिए, जब तक इंस्टैंट ऐप्लिकेशन, इंस्टॉल किए गए ऐप्लिकेशन से साफ़ तौर पर कनेक्ट न हो.

• डिवाइस पर इंस्टैंट ऐप्लिकेशन के साथ इंटरैक्ट करने के लिए, उपयोगकर्ता को ये सुविधाएं उपलब्ध कराई जानी चाहिए. AOSP, डिफ़ॉल्ट सिस्टम यूज़र इंटरफ़ेस (यूआई), सेटिंग, और लॉन्चर की ज़रूरी शर्तों को पूरा करता है. डिवाइस पर लागू करने के तरीके:

  • [C-1-5] उपयोगकर्ता को यह सुविधा देनी चाहिए कि वह हर ऐप्लिकेशन पैकेज के लिए, कैश मेमोरी में सेव किए गए Instant Apps को देख सके और मिटा सके.
  • [C-1-6] उपयोगकर्ता को लगातार सूचना देनी चाहिए. यह सूचना, फ़ोरग्राउंड में इंस्टैंट ऐप्लिकेशन के चलने के दौरान छोटी की जा सकती है. उपयोगकर्ता को मिलने वाली इस सूचना में यह ज़रूर शामिल होना चाहिए कि Instant Apps को इंस्टॉल करने की ज़रूरत नहीं होती. साथ ही, इसमें उपयोगकर्ता को सेटिंग में जाकर, ऐप्लिकेशन की जानकारी वाली स्क्रीन पर ले जाने वाला यूज़र अफ़र्डेंस भी होना चाहिए. वेब इंटेंट की मदद से लॉन्च किए गए इंस्टैंट ऐप्लिकेशन के लिए, उपयोगकर्ता को एक और विकल्प दिया जाना चाहिए. इससे, उपयोगकर्ता को इंस्टैंट ऐप्लिकेशन लॉन्च करने के बजाय, कॉन्फ़िगर किए गए वेब ब्राउज़र में लिंक को लॉन्च करने का विकल्प मिलता है. हालांकि, ऐसा तब ही किया जा सकता है, जब डिवाइस पर कोई ब्राउज़र उपलब्ध हो. ऐसा करने के लिए, Intent.ACTION_VIEW पर सेट किए गए ऐक्शन और "http" या "https" स्कीम वाले इंटेंट का इस्तेमाल किया जाना चाहिए.
  • [C-1-7] अगर डिवाइस पर 'हाल ही में इस्तेमाल किए गए' फ़ंक्शन उपलब्ध है, तो ऐप्लिकेशन को इस फ़ंक्शन से ऐक्सेस करने की अनुमति देनी चाहिए.

• [C-1-8] एसडीके टूल में यहां बताए गए इंटेंट के लिए, एक या एक से ज़्यादा ऐप्लिकेशन या सेवा कॉम्पोनेंट को इंटेंट हैंडलर के साथ पहले से लोड करना ज़रूरी है. साथ ही, इंस्टैंट ऐप्लिकेशन के लिए इंटेंट दिखाना ज़रूरी है.

3.16. कंपैनियन डिवाइस को जोड़ना

Android में, साथी डिवाइसों को जोड़ने की सुविधा शामिल है. इससे, साथी डिवाइसों के साथ असोसिएशन को ज़्यादा असरदार तरीके से मैनेज किया जा सकता है. साथ ही, ऐप्लिकेशन के लिए CompanionDeviceManager एपीआई उपलब्ध कराया जाता है, ताकि वे इस सुविधा को ऐक्सेस कर सकें.

अगर डिवाइस में, साथ में इस्तेमाल किए जाने वाले डिवाइस को जोड़ने की सुविधा काम करती है, तो:

• [C-1-1] FEATURE_COMPANION_DEVICE_SETUP फ़ीचर फ़्लैग का एलान करना ज़रूरी है.
• [C-1-2] यह पक्का करना ज़रूरी है कि android.companion पैकेज में मौजूद एपीआई पूरी तरह से लागू हों.
• [C-1-3] उपयोगकर्ता को यह चुनने/पुष्टि करने के लिए, उपयोगकर्ता के लिए ज़रूरी है कि वह साथी डिवाइस मौजूद है और काम कर रहा है.

3.17. ज़्यादा मेमोरी इस्तेमाल करने वाले ऐप्लिकेशन

अगर डिवाइस में सुविधा FEATURE_CANT_SAVE_STATE का एलान किया जाता है, तो:

• [C-1-1] डिवाइस में सिर्फ़ एक ऐसा ऐप्लिकेशन इंस्टॉल होना चाहिए जो यह बताता हो कि सिस्टम में एक बार में cantSaveState कौनसा ऐप्लिकेशन चल रहा है. अगर उपयोगकर्ता किसी ऐप्लिकेशन से साफ़ तौर पर बाहर निकले बिना उसे छोड़ देता है, तो डिवाइस के लागू होने पर, उस ऐप्लिकेशन को रैम में प्राथमिकता दी जानी चाहिए. ठीक उसी तरह जैसे फ़ोरग्राउंड सेवाओं जैसी अन्य चीज़ों को प्राथमिकता दी जाती है. उदाहरण के लिए, सिस्टम में कोई चालू गतिविधि न होने पर, बैक बटन दबाने के बजाय होम बटन दबाकर ऐप्लिकेशन से बाहर निकलना. जब कोई ऐप्लिकेशन बैकग्राउंड में चल रहा होता है, तब भी सिस्टम उस पर पावर मैनेजमेंट की सुविधाएं लागू कर सकता है. जैसे, सीपीयू और नेटवर्क ऐक्सेस को सीमित करना.
• [C-1-2] उपयोगकर्ता के cantSaveState एट्रिब्यूट के साथ बताए गए दूसरे ऐप्लिकेशन को लॉन्च करने के बाद, सामान्य स्थिति को सेव/बहाल करने वाले मैकेनिज़्म में हिस्सा न लेने वाले ऐप्लिकेशन को चुनने के लिए, यूज़र इंटरफ़ेस (यूआई) की सुविधा देना ज़रूरी है.
• [C-1-3] नीति में किए गए अन्य बदलावों को उन ऐप्लिकेशन पर लागू नहीं किया जाना चाहिए जिनमें cantSaveState के बारे में बताया गया है. जैसे, सीपीयू की परफ़ॉर्मेंस में बदलाव करना या शेड्यूल करने के लिए प्राथमिकता में बदलाव करना.

अगर डिवाइस में लागू करने की सुविधा के लिए, FEATURE_CANT_SAVE_STATE सुविधा का एलान नहीं किया जाता है, तो:

• [C-1-1] ऐप्लिकेशन से सेट किए गए cantSaveState एट्रिब्यूट को अनदेखा करना ज़रूरी है. साथ ही, उस एट्रिब्यूट के आधार पर ऐप्लिकेशन के व्यवहार में बदलाव नहीं करना चाहिए.

3.18. संपर्क

Android में ऐसे एपीआई शामिल हैं जिनकी मदद से, ऐप्लिकेशन डिवाइस पर सेव की गई संपर्क जानकारी को मैनेज कर सकते हैं. इन एपीआई को Contacts Provider कहा जाता है. सीधे डिवाइस में डाले गए संपर्क डेटा को आम तौर पर किसी वेब सेवा के साथ सिंक किया जाता है. हालांकि, हो सकता है कि डेटा सिर्फ़ डिवाइस पर सेव हो. सिर्फ़ डिवाइस में सेव किए गए संपर्कों को लोकल संपर्क कहा जाता है.

RawContacts, किसी खाते से "जुड़े हुए" या "उसमें सेव किए गए" होते हैं, जब रॉ संपर्कों के लिए ACCOUNT_NAME और ACCOUNT_TYPE कॉलम, खाते के Account.name और Account.type फ़ील्ड से मेल खाते हैं.

डिफ़ॉल्ट लोकल खाता: यह उन रॉ संपर्कों का खाता है जो सिर्फ़ डिवाइस पर सेव किए जाते हैं और AccountManager में किसी खाते से नहीं जुड़े होते. इन्हें ACCOUNT_NAME और ACCOUNT_TYPE कॉलम के लिए शून्य वैल्यू के साथ बनाया जाता है.

कस्टम लोकल खाता: यह उन रॉ संपर्कों के लिए खाता है जिन्हें सिर्फ़ डिवाइस पर सेव किया जाता है. यह खाता, AccountManager में मौजूद किसी खाते से नहीं जुड़ा होता. इसे ACCOUNT_NAME और ACCOUNT_TYPE कॉलम के लिए, कम से कम एक ऐसी वैल्यू के साथ बनाया जाता है जो शून्य न हो.

डिवाइस पर लागू करने के तरीके:

• [C-SR-1] हमारा सुझाव है कि कस्टम लोकल खाते न बनाएं.

अगर डिवाइस पर लागू करने के लिए, पसंद के मुताबिक बनाए गए स्थानीय खाते का इस्तेमाल किया जाता है, तो:

• [C-1-1] कस्टम लोकल खाते का ACCOUNT_NAME, ContactsContract.RawContacts.getLocalAccountName से वापस लौटाया जाना चाहिए
• [C-1-2] कस्टम लोकल खाते का ACCOUNT_TYPE, ContactsContract.RawContacts.getLocalAccountType से वापस लाया जाना चाहिए
• [C-1-3] तीसरे पक्ष के ऐप्लिकेशन, डिफ़ॉल्ट लोकल खाते के साथ रॉ संपर्क डालते हैं.जैसे, ACCOUNT_NAME और ACCOUNT_TYPE के लिए शून्य वैल्यू सेट करके. ऐसे रॉ संपर्क, कस्टम लोकल खाते में डाले जाने चाहिए.
• [C-1-4] खाते जोड़ने या हटाने पर, कस्टम लोकल खाते में डाले गए रॉ संपर्कों को हटाया नहीं जाना चाहिए.
• [C-1-5] कस्टम लोकल खाते के लिए किए गए मिटाएं ऑपरेशन के बाद, रॉ संपर्क तुरंत मिटा दिए जाने चाहिए (जैसे कि CALLER_IS_SYNCADAPTER पैरामीटर को 'सही' पर सेट किया गया हो), भले ही CALLER\_IS\_SYNCADAPTER पैरामीटर को 'गलत' पर सेट किया गया हो या उसकी जानकारी न दी गई हो.

4. ऐप्लिकेशन को पैकेज करने की सुविधा के साथ काम करना

डिवाइसों पर लागू करने के लिए:

• [C-0-1] यह ज़रूरी है कि यह टूल, आधिकारिक Android SDK में शामिल "aapt" टूल से जनरेट की गई Android ".apk" फ़ाइलों को इंस्टॉल और चला सके.

  • ऊपर बताई गई शर्त को पूरा करना मुश्किल हो सकता है. इसलिए, डिवाइस में इसे लागू करने के लिए, हमारा सुझाव है कि आप AOSP के रेफ़रंस के तौर पर लागू किए गए पैकेज मैनेजमेंट सिस्टम का इस्तेमाल करें.

• [C-0-2] यह ज़रूरी है कि APK सिग्नेचर स्कीम v3.1, APK सिग्नेचर स्कीम v3, APK सिग्नेचर स्कीम v2 और JAR साइनिंग का इस्तेमाल करके, ".apk" फ़ाइलों की पुष्टि की जा सके.

• [C-0-3] .apk, Android मेनिफ़ेस्ट, Dalvik बाइटकोड या रेंडरस्क्रिप्ट बाइटकोड फ़ॉर्मैट को इस तरह से एक्सटेंड़ नहीं किया जाना चाहिए कि उन फ़ाइलों को काम करने वाले अन्य डिवाइसों पर सही तरीके से इंस्टॉल और चलाने में समस्या आएं.

• [C-0-4] पैकेज के लिए, मौजूदा "इंस्टॉलर ऑफ़ रिकॉर्ड" के अलावा किसी दूसरे ऐप्लिकेशन को, उपयोगकर्ता की पुष्टि के बिना ऐप्लिकेशन को चुपचाप अनइंस्टॉल करने की अनुमति नहीं देनी चाहिए. इस बारे में, DELETE_PACKAGE अनुमति के लिए SDK टूल में जानकारी दी गई है. हालांकि, PACKAGE_NEEDS_VERIFICATION इंटेंट को मैनेज करने वाले सिस्टम पैकेज की पुष्टि करने वाले ऐप्लिकेशन और ACTION_MANAGE_STORAGE इंटेंट को मैनेज करने वाले स्टोरेज मैनेजर ऐप्लिकेशन पर यह नीति लागू नहीं होती.

• [C-0-5] इसमें ऐसी गतिविधि होनी चाहिए जो android.settings.MANAGE_UNKNOWN_APP_SOURCES इंटेंट को मैनेज करती हो.

• [C-0-6] ऐप्लिकेशन के पैकेज, अज्ञात स्रोतों से इंस्टॉल नहीं किए जाने चाहिए. ऐसा तब तक नहीं किया जाना चाहिए, जब तक इंस्टॉल करने का अनुरोध करने वाला ऐप्लिकेशन इन सभी ज़रूरी शर्तों को पूरा न करता हो:

  • इसमें REQUEST_INSTALL_PACKAGES अनुमति का एलान करना ज़रूरी है या android:targetSdkVersion को 24 या उससे कम पर सेट करना होगा.
  • उपयोगकर्ता ने अज्ञात सोर्स से ऐप्लिकेशन इंस्टॉल करने की अनुमति दी हो.

• उपयोगकर्ता को हर ऐप्लिकेशन के लिए, अनजान सोर्स से ऐप्लिकेशन इंस्टॉल करने की अनुमति देने/रद्द करने का विकल्प देना चाहिए. हालांकि, अगर डिवाइस पर इसे लागू करने के लिए, उपयोगकर्ताओं को यह विकल्प नहीं देना है, तो इसे बिना किसी कार्रवाई के लागू किया जा सकता है और startActivityForResult() के लिए RESULT_CANCELED दिखाया जा सकता है. हालांकि, ऐसे मामलों में भी उन्हें उपयोगकर्ता को यह बताना चाहिए कि ऐसा विकल्प क्यों नहीं दिया गया है.

• [C-0-7] किसी ऐप्लिकेशन में कोई गतिविधि शुरू करने से पहले, उपयोगकर्ता को चेतावनी वाली स्ट्रिंग के साथ चेतावनी वाला डायलॉग दिखाना ज़रूरी है. यह स्ट्रिंग, सिस्टम एपीआई PackageManager.setHarmfulAppWarning के ज़रिए दी जाती है. साथ ही, यह गतिविधि उसी सिस्टम एपीआई PackageManager.setHarmfulAppWarning के ज़रिए संभावित रूप से नुकसान पहुंचाने वाली के तौर पर मार्क की गई हो.

• चेतावनी वाले डायलॉग में, उपयोगकर्ता को ऐप्लिकेशन को अनइंस्टॉल करने या लॉन्च करने का विकल्प देना चाहिए.

• [C-0-8] यहां बताए गए तरीके के मुताबिक, इंक्रीमेंटल फ़ाइल सिस्टम के लिए सहायता लागू करना ज़रूरी है.

• [C-0-9] APK सिग्नेचर स्कीम v4 और APK सिग्नेचर स्कीम v4 .1 का इस्तेमाल करके, .apk फ़ाइलों की पुष्टि करने की सुविधा होनी चाहिए.

ध्यान दें: Android 10 या उससे पहले के वर्शन पर शिप किए गए डिवाइसों के लिए, सिस्टम सॉफ़्टवेयर के अपडेट की मदद से [C-0-8] और [C-0-9] की ज़रूरी शर्तें पूरी नहीं की जा सकतीं. ऐसे डिवाइसों को इन ज़रूरी शर्तों से छूट मिल सकती है.

5. मल्टीमीडिया के साथ काम करना

डिवाइस पर लागू करने के तरीके:

• [C-0-1] MediaCodecList के ज़रिए बताए गए हर कोडेक के लिए, सेक्शन 5.1 में बताए गए मीडिया फ़ॉर्मैट, एन्कोडर, डिकोडर, फ़ाइल टाइप, और कंटेनर फ़ॉर्मैट के साथ काम करना चाहिए.
• [C-0-2] MediaCodecList के ज़रिए, तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध एन्कोडर और डिकोडर के साथ काम करने की जानकारी देना और उनकी शिकायत करना ज़रूरी है.
• [C-0-3] यह ज़रूरी है कि यह सभी फ़ॉर्मैट को सही तरीके से डिकोड कर सके और तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कर सके. इसमें, एन्कोडर से जनरेट होने वाली सभी बिटस्ट्रीम और CamcorderProfile में रिपोर्ट की गई प्रोफ़ाइलें शामिल हैं.

डिवाइस पर लागू करने के तरीके:

• कोडेक के इंतज़ार का समय कम से कम होना चाहिए. दूसरे शब्दों में, वे
  • इनपुट बफ़र का इस्तेमाल और सेव नहीं करना चाहिए. साथ ही, प्रोसेस होने के बाद ही इनपुट बफ़र को दिखाना चाहिए.
  • डिकोड किए गए बफ़र को स्टैंडर्ड (जैसे, एसपीएस) में बताए गए समय से ज़्यादा समय तक सेव नहीं रखना चाहिए.
  • कोड में बदले गए बफ़र को GOP स्ट्रक्चर के लिए ज़रूरी समय से ज़्यादा समय तक नहीं रखना चाहिए.

यहां दिए गए सेक्शन में बताए गए सभी कोडेक, Android Open Source Project के पसंदीदा Android वर्शन में, सॉफ़्टवेयर के तौर पर लागू किए जाते हैं.

कृपया ध्यान दें कि न तो Google और न ही Open Handset Alliance ने यह ज़ाहिर किया है कि ये कोडेक, तीसरे पक्ष के पेटेंट से मुक्त हैं. जिन लोगों को इस सोर्स कोड का इस्तेमाल हार्डवेयर या सॉफ़्टवेयर प्रॉडक्ट में करना है उन्हें यह सलाह दी जाती है कि इस कोड को लागू करने के लिए, उन्हें ज़रूरी हो सकता है कि वे पेटेंट के मालिकों से पेटेंट लाइसेंस लें. ऐसा ओपन सोर्स सॉफ़्टवेयर या शेयरवेयर में भी किया जा सकता है.

5.1. मीडिया कोडेक

5.1.1. ऑडियो एन्कोडिंग

ज़्यादा जानकारी के लिए, 5.1.3 देखें. ऑडियो कोडेक की जानकारी.

अगर डिवाइस में android.hardware.microphone का एलान किया गया है, तो उसे इन ऑडियो फ़ॉर्मैट को एन्कोड करने की सुविधा देनी होगी और उन्हें तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराना होगा:

• [C-1-1] PCM/WAVE
• [C-1-2] FLAC
• [C-1-3] Opus

सभी ऑडियो एन्कोडर में ये सुविधाएं होनी चाहिए:

• [C-3-1] android.media.MediaCodec एपीआई के ज़रिए, PCM 16-बिट नेटिव बाइट ऑर्डर ऑडियो फ़्रेम.

5.1.2. ऑडियो को डिकोड करना

ज़्यादा जानकारी के लिए, 5.1.3 देखें. ऑडियो कोडेक की जानकारी.

अगर डिवाइस में android.hardware.audio.output सुविधा काम करती है, तो उस पर इन ऑडियो फ़ॉर्मैट को डिकोड करने की सुविधा होनी चाहिए:

• [C-1-1] MPEG-4 AAC प्रोफ़ाइल (AAC LC)
• [C-1-2] MPEG-4 HE AAC Profile (AAC+)
• [C-1-3] MPEG-4 HE AACv2 प्रोफ़ाइल (बेहतर AAC+)
• [C-1-4] AAC ELD (कम देरी वाला बेहतर एएसी)
• [C-1-11] xHE-AAC (ISO/IEC 23003-3 एक्सटेंडेड HE AAC प्रोफ़ाइल, जिसमें USAC बेसलाइन प्रोफ़ाइल और ISO/IEC 23003-4 डाइनैमिक रेंज कंट्रोल प्रोफ़ाइल शामिल है)
• [C-1-5] FLAC
• [C-1-6] MP3
• [C-1-7] एमआईडीआई
• [C-1-8] Vorbis
• [C-1-9] PCM/WAVE, जिसमें 24 बिट तक के हाई रिज़ॉल्यूशन वाले ऑडियो फ़ॉर्मैट, 192 किलोहर्ट्ज़ का सैंपलिंग रेट, और आठ चैनल शामिल हैं. ध्यान दें कि यह शर्त सिर्फ़ डिकोड करने के लिए है. साथ ही, डिवाइस को वीडियो चलाने के दौरान, उसे डाउनसैंपल और डाउनमिक्स करने की अनुमति है.
• [C-1-10] Opus

अगर डिवाइस पर, android.media.MediaCodec API में डिफ़ॉल्ट AAC ऑडियो डिकोडर की मदद से, कई चैनलों वाली स्ट्रीम (यानी दो से ज़्यादा चैनलों वाली) के AAC इनपुट बफ़र को PCM में डिकोड करने की सुविधा काम करती है, तो इनके काम करने की ज़रूरत है:

• [C-2-1] डिकोडिंग, डाउनमिक्स किए बिना की जानी चाहिए.उदाहरण के लिए, 5. 0 AAC स्ट्रीम को PCM के पांच चैनलों में डिकोड किया जाना चाहिए.5.1 AAC स्ट्रीम को PCM के छह चैनलों में डिकोड किया जाना चाहिए.
• [C-2-2] डाइनैमिक रेंज का मेटाडेटा, ISO/IEC 14496-3 में "डाइनैमिक रेंज कंट्रोल (डीआरसी)" में बताए गए तरीके के मुताबिक होना चाहिए. साथ ही, ऑडियो डिकोडर के डाइनैमिक रेंज से जुड़े व्यवहार को कॉन्फ़िगर करने के लिए, android.media.MediaFormat डीआरसी बटन का इस्तेमाल किया जाना चाहिए. एएसी डीआरसी पासकोड, एपीआई 21 में जोड़े गए थे. ये पासकोड ये हैं: KEY_AAC_DRC_ATTENUATION_FACTOR, KEY_AAC_DRC_BOOST_FACTOR, KEY_AAC_DRC_HEAVY_COMPRESSION, KEY_AAC_DRC_TARGET_REFERENCE_LEVEL, और KEY_AAC_ENCODED_TARGET_LEVEL.
• [C-SR-1] हमारा सुझाव है कि सभी AAC ऑडियो डिकोडर, ऊपर बताई गई ज़रूरी शर्तें C-2-1 और C-2-2 पूरी करें.

USAC ऑडियो को डिकोड करते समय, MPEG-D (ISO/IEC 23003-4):

• [C-3-1] लाउडनेस और डीआरसी मेटाडेटा को MPEG-D डीआरसी डाइनैमिक रेंज कंट्रोल प्रोफ़ाइल लेवल 1 के मुताबिक समझा और लागू किया जाना चाहिए.
• [C-3-2] डिकोडर को इन android.media.MediaFormat कुंजियों के साथ सेट किए गए कॉन्फ़िगरेशन के हिसाब से काम करना चाहिए: KEY_AAC_DRC_TARGET_REFERENCE_LEVEL और KEY_AAC_DRC_EFFECT_TYPE.

MPEG-4 AAC, HE AAC, और HE AACv2 प्रोफ़ाइल डीकोडर:

• ISO/IEC 23003-4 डाइनैमिक रेंज कंट्रोल प्रोफ़ाइल का इस्तेमाल करके, आवाज़ की लाउडनेस और डाइनैमिक रेंज को कंट्रोल किया जा सकता है.

अगर ISO/IEC 23003-4 काम करता है और डिकोड किए गए बिटस्ट्रीम में ISO/IEC 23003-4 और ISO/IEC 14496-3, दोनों मेटाडेटा मौजूद हैं, तो:

• ISO/IEC 23003-4 मेटाडेटा को प्राथमिकता दी जाएगी.

सभी ऑडियो डिकोडर में, इन फ़ॉर्मैट में आउटपुट देने की सुविधा होनी चाहिए:

• [C-6-1] android.media.MediaCodec एपीआई के ज़रिए, PCM 16-बिट नेटिव बाइट ऑर्डर ऑडियो फ़्रेम.

अगर डिवाइस में, android.media.MediaCodec एपीआई में डिफ़ॉल्ट AAC ऑडियो डिकोडर की मदद से, कई चैनलों वाली स्ट्रीम (यानी दो से ज़्यादा चैनल) के AAC इनपुट बफ़र को PCM में डिकोड करने की सुविधा है, तो इनके काम करने की ज़रूरत है:

• [C-7-1] ऐप्लिकेशन को डिकोडिंग का इस्तेमाल करके, कुंजी KEY_MAX_OUTPUT_CHANNEL_COUNT के साथ कॉन्फ़िगर किया जा सकता है. इससे यह कंट्रोल किया जा सकता है कि कॉन्टेंट को स्टीरियो में डाउनमिक्स किया जाए (2 की वैल्यू का इस्तेमाल करने पर) या चैनलों की नेटिव संख्या का इस्तेमाल करके आउटपुट किया जाए (उस संख्या के बराबर या उससे ज़्यादा की वैल्यू का इस्तेमाल करने पर). उदाहरण के लिए, 6 या उससे ज़्यादा की वैल्यू से, 5.1 कॉन्टेंट फ़ीड करने पर, डिकोडर को छह चैनल आउटपुट करने के लिए कॉन्फ़िगर किया जाएगा.
• [C-7-2] डिकोड करते समय, डिकोडर को android.media.AudioFormat कॉन्स्टेंट (उदाहरण के लिए: CHANNEL_OUT_5POINT1) का इस्तेमाल करके, आउटपुट फ़ॉर्मैट पर इस्तेमाल किए जा रहे चैनल मास्क का विज्ञापन करना चाहिए.KEY_CHANNEL_MASK

अगर डिवाइस में डिफ़ॉल्ट AAC ऑडियो डिकोडर के अलावा अन्य ऑडियो डिकोडर काम करते हैं और कंप्रेस किए गए मल्टी-चैनल कॉन्टेंट को चलाने पर, मल्टी-चैनल ऑडियो (यानी दो से ज़्यादा चैनल) आउटपुट करने की सुविधा होती है, तो:

• [C-SR-2] हमारा सुझाव है कि डिकोडर को ऐप्लिकेशन के ज़रिए कॉन्फ़िगर किया जाए. इसके लिए, डिकोडिंग के लिए कुंजी KEY_MAX_OUTPUT_CHANNEL_COUNT का इस्तेमाल करें. इससे यह कंट्रोल किया जा सकता है कि कॉन्टेंट को स्टीरियो में डाउनमिक्स किया जाए (2 की वैल्यू का इस्तेमाल करने पर) या चैनलों की नेटिव संख्या का इस्तेमाल करके आउटपुट किया जाए (उस संख्या के बराबर या उससे ज़्यादा की वैल्यू का इस्तेमाल करने पर). उदाहरण के लिए, 6 या उससे ज़्यादा की वैल्यू से, 5.1 कॉन्टेंट फ़ीड करने पर, डिकोडर को छह चैनल आउटपुट करने के लिए कॉन्फ़िगर किया जाएगा.
• [C-SR-3] डिकोड करते समय, डिकोडर को KEY_CHANNEL_MASK बटन की मदद से, आउटपुट फ़ॉर्मैट में इस्तेमाल किए जा रहे चैनल मास्क का विज्ञापन करने का सुझाव दिया जाता है. इसके लिए, android.media.AudioFormat के कॉन्स्टेंट का इस्तेमाल करें. उदाहरण के लिए: CHANNEL_OUT_5POINT1.

5.1.3. ऑडियो कोडेक के बारे में जानकारी

फ़ॉर्मैट/कोडेक	जानकारी	इस्तेमाल किए जा सकने वाले फ़ाइल टाइप/कंटेनर फ़ॉर्मैट
MPEG-4 AAC प्रोफ़ाइल (AAC LC)	स्टैंडर्ड सैंपलिंग रेट (8 से 48 किलोहर्ट्ज़) के साथ, मोनो/स्टीरियो/5.0/5.1 कॉन्टेंट के लिए काम करता है.	3GPP (.3gp) MPEG-4 (.mp4, .m4a) ADTS रॉ AAC (.aac, ADIF काम नहीं करता) एमपीईजी-टीएस (.ts, आगे-पीछे नहीं किया जा सकता, सिर्फ़ डीकोड किया जा सकता है) Matroska (.mkv, सिर्फ़ डिकोड करने के लिए)
MPEG-4 HE AAC Profile (AAC+)	मोनो/स्टीरियो/5.0/5.1 ऑडियो वाले कॉन्टेंट के लिए, 16 से 48 किलोहर्ट्ज़ के स्टैंडर्ड सैंपलिंग रेट की सुविधा.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
MPEG-4 HE AACv2 प्रोफ़ाइल (बेहतर AAC+)	मोनो/स्टीरियो/5.0/5.1 ऑडियो वाले कॉन्टेंट के लिए, 16 से 48 किलोहर्ट्ज़ के स्टैंडर्ड सैंपलिंग रेट की सुविधा.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
AAC ELD (बेहतर कम इंतज़ार वाला AAC)	मोनो/स्टीरियो कॉन्टेंट के लिए, 16 से लेकर 48 किलोहर्ट्ज़ तक के स्टैंडर्ड सैंपलिंग रेट का इस्तेमाल किया जा सकता है.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
USAC	मोनो/स्टीरियो कॉन्टेंट के लिए, 7.35 से 48 kHz तक के स्टैंडर्ड सैंपलिंग रेट का इस्तेमाल किया जा सकता है.	MPEG-4 (.mp4, .m4a)
AMR-NB	8 केएचज़ पर सैंपल किए गए 4.75 से 12.2 केबीपीएस	3GPP (.3gp)
AMR-WB	AMR-WB, Adaptive Multi-Rate - Wideband Speech Codec के मुताबिक, 16 किलोहर्ट्ज़ पर सैंपल किए गए 6.60 केबीटी/सेकंड से 23.85 केबीटी/सेकंड तक के नौ रेट	3GPP (.3gp)
FLAC	एन्कोडर और डिकोडर, दोनों के लिए: कम से कम मोनो और स्टीरियो मोड काम करने चाहिए. 192 किलोहर्ट्ज़ तक के सैंपल रेट काम करने चाहिए. साथ ही, 16-बिट और 24-बिट रिज़ॉल्यूशन काम करने चाहिए. फ़्लोटिंग पॉइंट ऑडियो कॉन्फ़िगरेशन के साथ, FLAC 24-बिट ऑडियो डेटा मैनेजमेंट की सुविधा ज़रूर होनी चाहिए.	FLAC (.flac) MPEG-4 (.mp4, .m4a, सिर्फ़ डिकोड करने के लिए) Matroska (.mkv, सिर्फ़ डिकोड करने के लिए)
MP3	मोनो/स्टीरियो 8-320 केबीपीएस कॉन्स्टेंट (सीबीआर) या वैरिएबल बिटरेट (वीबीआर)	MP3 (.mp3) MPEG-4 (.mp4, .m4a, सिर्फ़ डिकोड करने के लिए) Matroska (.mkv, सिर्फ़ डिकोड करने के लिए)
MIDI	एमआईडीआई टाइप 0 और 1. डीएलएस का वर्शन 1 और 2. XMF और Mobile XMF. रिंगटोन के लिए, RTTTL/RTX, OTA, और iMelody फ़ॉर्मैट का इस्तेमाल किया जा सकता है	टाइप 0 और 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) iMelody (.imy)
Vorbis	डिकोडिंग: 8000, 12000, 16000, 24000, और 48000 हर्ट्ज़ की सैंपलिंग रेट वाले मोनो, स्टीरियो, 5.0, और 5.1 कॉन्टेंट के लिए काम करता है. एंकोडिंग: 8000, 12000, 16000, 24000, और 48000 हर्ट्ज़ की सैंपलिंग रेट वाले मोनो और स्टीरियो कॉन्टेंट के लिए काम करता है.	Ogg (.ogg) MPEG-4 (.mp4, .m4a, सिर्फ़ डिकोड करने के लिए) Matroska (.mkv) Webm (.webm)
PCM/WAVE	PCM कोडेक, 16-बिट लीनियर PCM और 16-बिट फ़्लोट के साथ काम करना चाहिए. WAVE एक्सट्रैक्टर में 16-बिट, 24-बिट, 32-बिट लीनियर PCM, और 32-बिट फ़्लोट (हार्डवेयर की सीमा तक रेट) का इस्तेमाल किया जा सकता है. सैंपलिंग रेट, 8 किलोहर्ट्ज़ से लेकर 192 किलोहर्ट्ज़ के बीच होने चाहिए.	WAVE (.wav)
Opus	डिकोडिंग: 8000, 12000, 16000, 24000, और 48000 हर्ट्ज़ की सैंपलिंग रेट के साथ, मोनो, स्टीरियो, 5.0, और 5.1 कॉन्टेंट के लिए काम करता है. कोडिंग: 8000, 12000, 16000, 24000, और 48000 हर्ट्ज़ की सैंपलिंग रेट के साथ, मोनो और स्टीरियो कॉन्टेंट के लिए काम करता है.	Ogg (.ogg) MPEG-4 (.mp4, .m4a, सिर्फ़ डिकोड करने के लिए) Matroska (.mkv) Webm (.webm)

5.1.4. इमेज को कोड में बदलना

ज़्यादा जानकारी के लिए, 5.1.6 देखें. इमेज कोडेक की जानकारी.

डिवाइस पर इमेज एन्कोड करने की सुविधा, इन फ़ॉर्मैट में काम करनी चाहिए:

• [C-0-1] JPEG
• [C-0-2] PNG
• [C-0-3] WebP

नई ज़रूरी शर्तें लागू करना

• [C-0-4] AVIF
  • डिवाइसों पर BITRATE_MODE_CQ और बेसलाइन प्रोफ़ाइल काम करनी चाहिए.

नई ज़रूरी शर्तें खत्म करना

अगर डिवाइस पर, मीडिया टाइप MIMETYPE_IMAGE_ANDROID_HEIC के लिए android.media.MediaCodec के ज़रिए HEIC एन्कोडिंग की सुविधा काम करती है, तो:

• [C-1-1] हार्डवेयर की मदद से तेज़ी से काम करने वाला HEVC एन्कोडर कोडेक उपलब्ध कराना ज़रूरी है. यह कोडेक, बिटरेट कंट्रोल मोड, BITRATE_MODE_CQ प्रोफ़ाइल, और 512 x 512 पिक्सल के फ़्रेम साइज़ के साथ काम करना चाहिए.HEVCProfileMainStill

5.1.5. इमेज डिकोड करना

ज़्यादा जानकारी के लिए, 5.1.6 देखें. इमेज कोडेक की जानकारी.

डिवाइस पर इमेज एन्कोडिंग को डिकोड करने की सुविधा होनी चाहिए:

• [C-0-1] JPEG
• [C-0-2] GIF
• [C-0-3] PNG
• [C-0-4] BMP
• [C-0-5] WebP
• [C-0-6] रॉ
• [C-0-7] AVIF (बेसलाइन प्रोफ़ाइल)

अगर डिवाइस में HEVC वीडियो को डिकोड करने की सुविधा काम करती है, तो: * [C-1-1] डिवाइस में HEIF (HEIC) इमेज को डिकोड करने की सुविधा काम करनी चाहिए.

ज़्यादा बिट-डेप्थ फ़ॉर्मैट (हर चैनल के लिए 9 से ज़्यादा बिट) के साथ काम करने वाले इमेज डिकोडर:

• [C-2-1] अगर ऐप्लिकेशन से अनुरोध किया जाता है, तो 8-बिट वाले मिलते-जुलते फ़ॉर्मैट को आउटपुट करने की सुविधा होनी चाहिए. उदाहरण के लिए, android.graphics.Bitmap के ARGB_8888 कॉन्फ़िगरेशन के ज़रिए.

5.1.6. इमेज कोडेक की जानकारी

फ़ॉर्मैट/कोडेक	जानकारी	इस्तेमाल किए जा सकने वाले फ़ाइल टाइप/कंटेनर फ़ॉर्मैट
JPEG	बेस+प्रोग्रेसिव	JPEG (.jpg)
GIF		GIF (.gif)
PNG		PNG (.png)
BMP		BMP (.bmp)
WebP		WebP (.webp)
Raw		ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw)
HEIF	इमेज, इमेज कलेक्शन, इमेज का क्रम	HEIF (.heif), HEIC (.heic)
AVIF (बेसलाइन प्रोफ़ाइल)	इमेज, इमेज कलेक्शन, इमेज सीक्वेंस की बेसलाइन प्रोफ़ाइल	HEIF कंटेनर (.avif)

MediaCodec API के ज़रिए एक्सपोज़ की गई इमेज एन्कोडर और डीकोडर

• [C-1-1] CodecCapabilities की मदद से, YUV420 8:8:8 फ़्लेक्सिबल कलर फ़ॉर्मैट (COLOR_FormatYUV420Flexible) के साथ काम करना चाहिए.

• [C-SR-1] इनपुट के लिए, Surface mode में RGB888 कलर फ़ॉर्मैट का इस्तेमाल करने का सुझाव दिया जाता है.

• [C-1-3] यह ज़रूरी है कि यह प्लैनर या सेमी-प्लानर YUV420 8:8:8 कलर फ़ॉर्मैट में से कम से कम एक फ़ॉर्मैट के साथ काम करे: COLOR_FormatYUV420PackedPlanar (COLOR_FormatYUV420Planar के बराबर) या COLOR_FormatYUV420PackedSemiPlanar (COLOR_FormatYUV420SemiPlanar के बराबर). हमारा सुझाव है कि यह दोनों फ़ॉर्मैट के साथ काम करे.

5.1.7. वीडियो कोडेक

• वेब वीडियो स्ट्रीमिंग और वीडियो कॉन्फ़्रेंस सेवाओं की अच्छी क्वालिटी के लिए, डिवाइस में ऐसे हार्डवेयर VP8 कोडेक का इस्तेमाल किया जाना चाहिए जो ज़रूरी शर्तों को पूरा करता हो.

अगर डिवाइस में वीडियो डीकोडर या एन्कोडर शामिल है, तो:

• [C-1-1] वीडियो कोडेक में, आउटपुट और इनपुट बाइटबफ़र के ऐसे साइज़ का इस्तेमाल करना ज़रूरी है जिनमें स्टैंडर्ड और कॉन्फ़िगरेशन के मुताबिक, सबसे बड़े संपीड़ित और अनकंप्रेस किए गए फ़्रेम को शामिल किया जा सके. साथ ही, इनका साइज़ ज़रूरत से ज़्यादा न हो.

• [C-1-2] वीडियो एन्कोडर और डिकोडर को CodecCapabilities की मदद से, YUV420 8:8:8 फ़्लेक्सिबल कलर फ़ॉर्मैट (COLOR_FormatYUV420Flexible) के साथ काम करना चाहिए.

• [C-1-3] वीडियो एन्कोडर और डिकोडर, प्लैनर या सेमीप्लेनर YUV420 8:8:8 कलर फ़ॉर्मैट में से कम से कम एक के साथ काम करने चाहिए: COLOR_FormatYUV420PackedPlanar (COLOR_FormatYUV420Planar के बराबर) या COLOR_FormatYUV420PackedSemiPlanar (COLOR_FormatYUV420SemiPlanar के बराबर). दोनों फ़ॉर्मैट के साथ काम करने का सुझाव दिया जाता है.

• [C-SR-1] हमारा सुझाव है कि वीडियो एन्कोडर और डिकोडर, कम से कम एक हार्डवेयर ऑप्टिमाइज़्ड प्लैनर या सेमी-प्लानर YUV420 8:8:8 कलर फ़ॉर्मैट (YV12, NV12, NV21 या वेंडर के ऑप्टिमाइज़ किए गए मिलते-जुलते फ़ॉर्मैट) के साथ काम करें.

• [C-1-5] ज़्यादा बिट-डेप्थ फ़ॉर्मैट (हर चैनल के लिए 9 से ज़्यादा बिट) के साथ काम करने वाले वीडियो डिकोडर को, 8-बिट वाले मिलते-जुलते फ़ॉर्मैट को आउटपुट करने की सुविधा देनी चाहिए. ऐसा तब करना होगा, जब ऐप्लिकेशन से अनुरोध किया जाए. यह android.media.MediaCodecInfo के ज़रिए YUV420 8:8:8 कलर फ़ॉर्मैट के साथ काम करने की सुविधा के तौर पर दिखना चाहिए.

अगर डिवाइस में एचडीआर प्रोफ़ाइल के साथ काम करने की सुविधा का विज्ञापन, Display.HdrCapabilities के ज़रिए किया जाता है, तो:

• [C-2-1] एचडीआर स्टैटिक मेटाडेटा को पार्स और मैनेज करने की सुविधा होनी चाहिए.

अगर डिवाइस के लागू होने की जानकारी, MediaCodecInfo.CodecCapabilities क्लास में FEATURE_IntraRefresh के ज़रिए, इंटरा रीफ़्रेश की सुविधा के साथ दी जाती है, तो:

• [C-3-1] यह ज़रूरी है कि डिवाइस, 10 से 60 फ़्रेम की रेंज में रीफ़्रेश पीरियड के साथ काम करे. साथ ही, कॉन्फ़िगर किए गए रीफ़्रेश पीरियड के 20% के अंदर सटीक तरीके से काम करे.

जब तक ऐप्लिकेशन में KEY_COLOR_FORMAT फ़ॉर्मैट बटन का इस्तेमाल करके, वीडियो डिकोडर के इस्तेमाल के बारे में अलग से कुछ नहीं बताया गया है, तब तक वीडियो डिकोडर के इस्तेमाल के लिए:

• [C-4-1] अगर Surface आउटपुट का इस्तेमाल करके कॉन्फ़िगर किया गया है, तो डिफ़ॉल्ट रूप से हार्डवेयर डिसप्ले के लिए ऑप्टिमाइज़ किए गए कलर फ़ॉर्मैट का इस्तेमाल करना चाहिए.
• [C-4-2] अगर Surface आउटपुट का इस्तेमाल न करने के लिए कॉन्फ़िगर किया गया है, तो डिफ़ॉल्ट रूप से YUV420 8:8:8 कलर फ़ॉर्मैट का इस्तेमाल करना चाहिए. यह फ़ॉर्मैट, सीपीयू के लिए ऑप्टिमाइज़ किया गया है.

5.1.8. वीडियो कोडेक की सूची

फ़ॉर्मैट/कोडेक	जानकारी	इस्तेमाल किए जा सकने वाले फ़ाइल टाइप/कंटेनर फ़ॉर्मैट
H.263		3GPP (.3gp) MPEG-4 (.mp4) Matroska (.mkv, सिर्फ़ डिकोड करने के लिए)
H.264 AVC	ज़्यादा जानकारी के लिए, सेक्शन 5.2 और 5.3 देखें	3GPP (.3gp) MPEG-4 (.mp4) MPEG-2 टीएस (.ts, इसमें आगे-पीछे नहीं जाया जा सकता) Matroska (.mkv, सिर्फ़ डिकोड करने के लिए)
H.265 HEVC	ज़्यादा जानकारी के लिए, सेक्शन 5.3 देखें	MPEG-4 (.mp4) Matroska (.mkv, सिर्फ़ डिकोड करने के लिए)
MPEG-2	मुख्य प्रोफ़ाइल	MPEG2-TS (.ts, इसमें आगे-पीछे नहीं जाया जा सकता) MPEG-4 (.mp4, सिर्फ़ डिकोड करने के लिए) Matroska (.mkv, सिर्फ़ डिकोड करने के लिए)
MPEG-4 SP		3GPP (.3gp) MPEG-4 (.mp4) Matroska (.mkv, सिर्फ़ डिकोड करने के लिए)
VP8	ज़्यादा जानकारी के लिए, सेक्शन 5.2 और 5.3 देखें	WebM (.webm) Matroska (.mkv)
VP9	ज़्यादा जानकारी के लिए, सेक्शन 5.3 देखें	WebM (.webm) Matroska (.mkv)
AV1	ज़्यादा जानकारी के लिए, सेक्शन 5.2 और सेक्शन 5.3 देखें	MPEG-4 (.mp4) Matroska (.mkv, सिर्फ़ डिकोड करने के लिए)

5.1.9. मीडिया कोडेक की सुरक्षा

डिवाइस में लागू करने के लिए, यह ज़रूरी है कि मीडिया कोडेक की सुरक्षा से जुड़ी सुविधाओं का पालन किया जाए, जैसा कि यहां बताया गया है.

Android में OMX, एक क्रॉस-प्लैटफ़ॉर्म मल्टीमीडिया ऐक्सेलरेशन एपीआई के साथ-साथ, Codec 2.0, एक कम ओवरहेड मल्टीमीडिया ऐक्सेलरेशन एपीआई की सुविधा शामिल है.

अगर डिवाइस पर मल्टीमीडिया की सुविधा काम करती है, तो:

• [C-1-1] Android Open Source Project की तरह, OMX या Codec 2.0 एपीआई (या दोनों) के ज़रिए मीडिया कोडेक के लिए सहायता देना ज़रूरी है. साथ ही, सुरक्षा उपायों को बंद या गच्चा नहीं देना चाहिए. इसका मतलब यह नहीं है कि हर कोडेक को OMX या Codec 2.0 API में से किसी एक का इस्तेमाल करना ज़रूरी है. इसका मतलब सिर्फ़ यह है कि इनमें से कम से कम एक एपीआई के लिए सहायता उपलब्ध होनी चाहिए. साथ ही, उपलब्ध एपीआई के लिए, सुरक्षा से जुड़ी मौजूदा सुविधाएं भी शामिल होनी चाहिए.
• [C-SR-1] हमारा सुझाव है कि आप Codec 2.0 API के लिए सहायता शामिल करें.

अगर डिवाइस में Codec 2.0 API काम नहीं करता है, तो:

• [C-2-1] डिवाइस पर काम करने वाले हर मीडिया फ़ॉर्मैट और टाइप (एन्कोडर या डिकोडर) के लिए, Android Open Source Project से मिलता-जुलता OMX सॉफ़्टवेयर कोडेक शामिल करना ज़रूरी है. हालांकि, ऐसा तब ही करें, जब यह उपलब्ध हो.
• [C-2-2] ऐसे कोडेक जिनके नाम "OMX.google" से शुरू होते हैं. यह ज़रूरी है कि वे Android ओपन सोर्स प्रोजेक्ट के सोर्स कोड पर आधारित हों.
• [C-SR-2] हमारा सुझाव है कि OMX सॉफ़्टवेयर कोडेक, ऐसी कोडेक प्रोसेस में चलाए जाएं जिसके पास मेमोरी मैपर्स के अलावा, हार्डवेयर ड्राइवर का ऐक्सेस न हो.

अगर डिवाइस पर Codec 2.0 API काम करता है, तो:

• [C-3-1] डिवाइस पर काम करने वाले हर मीडिया फ़ॉर्मैट और टाइप (एन्कोडर या डिकोडर) के लिए, Android Open Source Project (अगर उपलब्ध हो) से मिलते-जुलते Codec 2.0 सॉफ़्टवेयर कोडेक को शामिल करना ज़रूरी है.
• [C-3-2] सॉफ़्टवेयर कोडेक की प्रोसेस में, Codec 2.0 सॉफ़्टवेयर कोडेक को शामिल करना ज़रूरी है. ऐसा Android Open Source Project में बताए गए तरीके के मुताबिक करना होगा, ताकि सॉफ़्टवेयर कोडेक का ऐक्सेस ज़्यादा सटीक तरीके से दिया जा सके.
• [C-3-3] ऐसे कोडेक जिनके नाम "c2.android" से शुरू होते हैं. यह ज़रूरी है कि वे Android ओपन सोर्स प्रोजेक्ट के सोर्स कोड पर आधारित हों.

5.1.10. मीडिया कोडेक की जानकारी

अगर डिवाइस पर मीडिया कोडेक काम करते हैं, तो:

• [C-1-1] एपीआई के ज़रिए, मीडिया कोडेक की विशेषताओं की सही वैल्यू दिखानी चाहिए.MediaCodecInfo

खास तौर पर:

• [C-1-2] "OMX" से शुरू होने वाले नाम वाले कोडेक. OMX API का इस्तेमाल करना ज़रूरी है और नाम, OMX IL के नाम तय करने के दिशा-निर्देशों के मुताबिक होने चाहिए.
• [C-1-3] ऐसे कोडेक जिनके नाम "c2" से शुरू होते हैं. Codec 2.0 API का इस्तेमाल करना ज़रूरी है. साथ ही, इनके नाम, Android के लिए Codec 2.0 के नाम रखने के दिशा-निर्देशों के मुताबिक होने चाहिए.
• [C-1-4] ऐसे कोडेक जिनके नाम "OMX.google" या "c2.android" से शुरू होते हैं. इसे वेंडर या हार्डवेयर-ऐक्सेलरेटेड के तौर पर नहीं दिखाया जाना चाहिए.
• [C-1-5] ऐसे कोडेक जिन्हें कोडेक प्रोसेस (वेंडर या सिस्टम) में चलाया जाता है और जिनके पास मेमोरी ऐलोकेटर और मैपर के अलावा हार्डवेयर ड्राइवर का ऐक्सेस होता है, उन्हें सिर्फ़ सॉफ़्टवेयर के तौर पर नहीं दिखाया जाना चाहिए.
• [C-1-6] Android Open Source Project में मौजूद कोडेक या उस प्रोजेक्ट के सोर्स कोड पर आधारित नहीं होने वाले कोडेक को वेंडर के तौर पर दिखाना ज़रूरी है.
• [C-1-7] हार्डवेयर से तेज़ी लाने की सुविधा का इस्तेमाल करने वाले कोडेक को, हार्डवेयर से तेज़ी लाने की सुविधा के तौर पर दिखाना ज़रूरी है.
• [C-1-8] कोडेक के नाम गुमराह करने वाले नहीं होने चाहिए. उदाहरण के लिए, "डीकोडर" नाम वाले कोडेक में डीकोडिंग की सुविधा होनी चाहिए. साथ ही, "एन्कोडर" नाम वाले कोडेक में एन्कोडिंग की सुविधा होनी चाहिए. जिन कोडेक के नाम में मीडिया फ़ॉर्मैट शामिल हैं वे उन फ़ॉर्मैट के साथ काम करने चाहिए.

अगर डिवाइस पर वीडियो कोडेक काम करते हैं, तो:

• [C-2-1] अगर कोडेक इन साइज़ के साथ काम करता है, तो सभी वीडियो कोडेक को इन साइज़ के लिए, फ़्रेम रेट का डेटा पब्लिश करना होगा:

	एसडी (कम क्वालिटी)	एसडी (अच्छी क्वालिटी)	एचडी 720 पिक्सल	एचडी 1080 पिक्सल	यूएचडी
वीडियो रिज़ॉल्यूशन	176 x 144 पिक्सल (H263, MPEG2, MPEG4) 352 x 288 पिक्सल (MPEG4 एन्कोडर, H263, MPEG2) 320 x 180 पिक्सल (VP8, VP8) 320 x 240 पिक्सल (अन्य)	704 x 576 पिक्सल (H263) 640 x 360 पिक्सल (VP8, VP9) 640 x 480 पिक्सल (MPEG4 एन्कोडर) 720 x 480 पिक्सल (अन्य, AV1)	1408 x 1152 पिक्सल (H263) 1280 x 720 पिक्सल (अन्य, AV1)	1920 x 1080 पिक्सल (MPEG4, AV1 के अलावा)	3840 x 2160 पिक्सल (एचईवीसी, VP9, AV1)

• [C-2-2] हार्डवेयर की मदद से तेज़ किए गए वीडियो कोडेक के लिए, परफ़ॉर्मेंस पॉइंट की जानकारी पब्लिश करना ज़रूरी है. हर एक एपीआई में, काम करने वाले सभी स्टैंडर्ड परफ़ॉर्मेंस पॉइंट (PerformancePoint एपीआई में दिए गए) की सूची होनी चाहिए. ऐसा तब तक करना होगा, जब तक कि वे किसी दूसरे काम करने वाले स्टैंडर्ड परफ़ॉर्मेंस पॉइंट में शामिल न हों.
• इसके अलावा, अगर वे सूची में दिए गए स्टैंडर्ड पॉइंट के अलावा, वीडियो की परफ़ॉर्मेंस को बेहतर बनाने में मदद करते हैं, तो उन्हें एक्सटेंडेड परफ़ॉर्मेंस पॉइंट पब्लिश करने चाहिए.

5.2. वीडियो एन्कोडिंग

अगर डिवाइस पर किसी वीडियो एन्कोडर को लागू किया गया है और उसे तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराया गया है, तो:

• दो स्लाइडिंग विंडो में, इंटरफ़्रेम (आई-फ़्रेम) इंटरवल के बीच बिटरेट से 15% ज़्यादा नहीं होना चाहिए.
• यह बिटरेट से 100% से ज़्यादा नहीं होना चाहिए.

नई ज़रूरी शर्तें लागू करना

अगर डिवाइस पर किसी भी वीडियो एन्कोडर का इस्तेमाल किया जा सकता है और उसे तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराया जाता है, तो
MediaFormat.KEY_BITRATE_MODE को BITRATE_MODE_VBR पर सेट करें, ताकि एन्कोडर वैरिएबल बिटरेट मोड में काम कर सके. जब तक इससे कम से कम क्वालिटी पर असर नहीं पड़ता, तब तक एन्कोड किया गया बिटरेट :

• [C-5-1] एक स्लाइडिंग विंडो में, इंटरफ़्रेम (आई-फ़्रेम) इंटरवल के बीच बिटरेट से 15% ज़्यादा नहीं होना चाहिए इससे ज़्यादा नहीं होना चाहिए.
• [C-5-2] ज़रूरी है एक सेकंड की स्लाइडिंग विंडो में, बिटरेट से 100% ज़्यादा नहीं होना चाहिए.

अगर डिवाइस पर किसी भी वीडियो एन्कोडर का इस्तेमाल किया जा सकता है और उसे तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराया जाता है, तो एन्कोडर को लगातार बिटरेट मोड में काम करने के लिए, MediaFormat.KEY_BITRATE_MODE को BITRATE_MODE_CBR पर सेट किया जाता है. ऐसे में, एन्कोडेड बिटरेट:

• [C-6-1] यह ज़रूरी है कि [C-SR-2] बिटरेट, 1 सेकंड की स्लाइडिंग विंडो में टारगेट बिटरेट से 15% से ज़्यादा न हो. ऐसा करने का ज़रूर सुझाव दिया जाता है.

नई ज़रूरी शर्तें खत्म करना

अगर डिवाइस में एम्बेड की गई स्क्रीन डिसप्ले की डायगनल लंबाई कम से कम 2.5 इंच है या उसमें वीडियो आउटपुट पोर्ट है या android.hardware.camera.any सुविधा फ़्लैग की मदद से कैमरे के काम करने की जानकारी दी गई है, तो:

• [C-1-1] इसमें कम से कम एक VP8 या H.264 वीडियो एन्कोडर का इस्तेमाल करना ज़रूरी है. साथ ही, इसे तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराना होगा.
• यह VP8 और H.264, दोनों वीडियो एन्कोडर के साथ काम करना चाहिए. साथ ही, इसे तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराना चाहिए.

अगर डिवाइस में H.264, VP8, VP9 या HEVC वीडियो एन्कोडर का इस्तेमाल किया जा सकता है और उसे तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराया जाता है, तो:

• [C-2-1] डाइनैमिक तौर पर कॉन्फ़िगर किए जा सकने वाले बिटरेट के साथ काम करना चाहिए.
• यह अलग-अलग फ़्रेम रेट के साथ काम करना चाहिए. इसमें वीडियो एन्कोडर को इनपुट बफ़र के टाइमस्टैंप के आधार पर, फ़्रेम की तय अवधि तय करनी चाहिए. साथ ही, उस फ़्रेम की अवधि के आधार पर बिटरेट तय करना चाहिए.

अगर डिवाइस में MPEG-4 SP वीडियो एन्कोडर की सुविधा काम करती है और इसे तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराया जाता है, तो:

• यह ज़रूरी है कि काम करने वाले एन्कोडर के लिए, डाइनैमिक तौर पर कॉन्फ़िगर की जा सकने वाली बिटरेट की सुविधा काम करे.

अगर डिवाइस में हार्डवेयर की मदद से तेज़ी से वीडियो या इमेज एन्कोड करने की सुविधा उपलब्ध है और एक या एक से ज़्यादा अटैच किए गए या प्लग किए जा सकने वाले हार्डवेयर कैमरे काम करते हैं, तो android.camera एपीआई के ज़रिए उन्हें दिखाया जा सकता है:

• [C-4-1] हार्डवेयर से तेज़ की गई वीडियो और इमेज एन्कोडर के लिए, हार्डवेयर कैमरे से फ़्रेम को एन्कोड करने की सुविधा ज़रूरी है.
• सभी वीडियो या इमेज एन्कोडर की मदद से, हार्डवेयर कैमरे से फ़्रेम को एन्कोड करने की सुविधा होनी चाहिए.

अगर डिवाइस पर एचडीआर कोडिंग की सुविधा उपलब्ध है, तो:

• [C-SR-1] हमारा सुझाव है कि आप एचडीआर फ़ॉर्मैट को एसडीआर फ़ॉर्मैट में बदलने के लिए, आसानी से ट्रांसकोड करने वाले एपीआई के लिए प्लग इन उपलब्ध कराएं.

5.2.1. H.263

अगर डिवाइस में H.263 एन्कोडर काम करते हैं और तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध होते हैं, तो:

• [C-1-1] यह ज़रूरी है कि डिवाइस, बेसलाइन प्रोफ़ाइल लेवल 45 का इस्तेमाल करके, QCIF रिज़ॉल्यूशन (176 x 144) के साथ काम करे. SQCIF रिज़ॉल्यूशन का इस्तेमाल करना ज़रूरी नहीं है.
• इसमें, इस्तेमाल किए जा सकने वाले एन्कोडर के लिए, डाइनैमिक तौर पर कॉन्फ़िगर की जा सकने वाली बिटरेट की सुविधा होनी चाहिए.

5.2.2. H.264

अगर डिवाइस में H.264 कोडेक काम करता है, तो:

• [C-1-1] यह ज़रूरी है कि यह बेसलाइन प्रोफ़ाइल लेवल 3 के साथ काम करे. हालांकि, ASO (स्लाइस का मनमुताबिक क्रम), FMO (फ़्लेक्सिबल मैक्रोब्लॉक ऑर्डरिंग) और RS (ज़रूरत से ज़्यादा स्लाइस) के लिए सहायता देना ज़रूरी नहीं है. इसके अलावा, अन्य Android डिवाइसों के साथ काम करने के लिए, हमारा सुझाव है कि एन्कोडर, बेसलाइन प्रोफ़ाइल के लिए ASO, FMO, और RS का इस्तेमाल न करें.
• [C-1-2] यह ज़रूरी है कि यह नीचे दी गई टेबल में बताई गई एसडी (स्टैंडर्ड डेफ़िनिशन) वीडियो एन्कोडिंग प्रोफ़ाइलों के साथ काम करे.
• मुख्य प्रोफ़ाइल के लेवल 4 के साथ काम करना चाहिए.
• यह एचडी (हाई डेफ़िनिशन) वीडियो एन्कोडिंग प्रोफ़ाइलों के साथ काम करना चाहिए, जैसा कि नीचे दी गई टेबल में बताया गया है.

अगर डिवाइस में मीडिया एपीआई की मदद से, 720p या 1080p रिज़ॉल्यूशन वाले वीडियो के लिए H.264 एन्कोडिंग की सुविधा काम करती है, तो:

• [C-2-1] यह ज़रूरी है कि यह टूल, नीचे दी गई टेबल में मौजूद एन्कोडिंग प्रोफ़ाइलों के साथ काम करे.

	एसडी (कम क्वालिटी)	एसडी (अच्छी क्वालिटी)	एचडी 720 पिक्सल	एचडी 1080 पिक्सल
वीडियो रिज़ॉल्यूशन	320 x 240 पिक्सल	720 x 480 पिक्सल	1280 x 720 पिक्सल	1920 x 1080 पिक्सल
वीडियो फ़्रेम रेट	20 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड
वीडियो बिटरेट	384 केबीपीएस	2 एमबीपीएस	4 एमबीपीएस	10 एमबीपीएस

5.2.3. VP8

अगर डिवाइस में VP8 कोडेक काम करता है, तो:

• [C-1-1] यह ज़रूरी है कि यह एसडी वीडियो एन्कोडिंग प्रोफ़ाइलों के साथ काम करे.
• यह एचडी (हाई डेफ़िनिशन) वीडियो एन्कोडिंग प्रोफ़ाइलों के साथ काम करना चाहिए.
• [C-1-2] Matroska WebM फ़ाइलें लिखने की सुविधा होनी चाहिए.
• ऐसा हार्डवेयर VP8 कोडेक उपलब्ध कराना चाहिए जो WebM प्रोजेक्ट आरटीसी हार्डवेयर कोडिंग की ज़रूरी शर्तों को पूरा करता हो. इससे, वेब वीडियो स्ट्रीमिंग और वीडियो कॉन्फ़्रेंस की सेवाओं की अच्छी क्वालिटी को पक्का किया जा सकेगा.

अगर डिवाइस में लागू किए गए मीडिया एपीआई के ज़रिए, 720p या 1080p रिज़ॉल्यूशन वाले वीडियो के लिए VP8 एन्कोडिंग की सुविधा काम करती है, तो:

• [C-2-1] यह ज़रूरी है कि यह टूल, नीचे दी गई टेबल में मौजूद एन्कोडिंग प्रोफ़ाइलों के साथ काम करे.

	एसडी (कम क्वालिटी)	एसडी (अच्छी क्वालिटी)	एचडी 720 पिक्सल	एचडी 1080 पिक्सल
वीडियो रिज़ॉल्यूशन	320 x 180 पिक्सल	640 x 360 पिक्सल	1280 x 720 पिक्सल	1920 x 1080 पिक्सल
वीडियो फ़्रेम रेट	30 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड
वीडियो बिटरेट	800 केबीपीएस	2 एमबीपीएस	4 एमबीपीएस	10 एमबीपीएस

5.2.4. VP9

अगर डिवाइस में VP9 कोडेक काम करता है, तो:

• [C-1-2] यह प्रोफ़ाइल 0 लेवल 3 के साथ काम करना चाहिए.
• [C-1-1] Matroska WebM फ़ाइलें लिखने की सुविधा होनी चाहिए.
• [C-1-3] CodecPrivate डेटा जनरेट करना ज़रूरी है.
• यह एचडी डिकोडिंग प्रोफ़ाइलों के साथ काम करना चाहिए, जैसा कि नीचे दी गई टेबल में बताया गया है.
• [C-SR-1] हमारा सुझाव है कि अगर हार्डवेयर एन्कोडर है, तो एचडी डिकोडिंग प्रोफ़ाइलों का इस्तेमाल करें. इन प्रोफ़ाइलों के बारे में यहां दी गई टेबल में बताया गया है.

	एसडी	एचडी 720 पिक्सल	एचडी 1080 पिक्सल	यूएचडी
वीडियो रिज़ॉल्यूशन	720 x 480 पिक्सल	1280 x 720 पिक्सल	1920 x 1080 पिक्सल	3840 x 2160 पिक्सल
वीडियो फ़्रेम रेट	30 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड
वीडियो बिटरेट	1.6 एमबीपीएस	4 एमबीपीएस	5 एमबीपीएस	20 एमबीपीएस

अगर डिवाइस में Media APIs की मदद से, प्रोफ़ाइल 2 या प्रोफ़ाइल 3 के साथ काम करने का दावा किया जाता है, तो:

• 12-बिट फ़ॉर्मैट का इस्तेमाल करना ज़रूरी नहीं है.

5.2.5. H.265

अगर डिवाइस में H.265 कोडेक काम करता है, तो:

• [C-1-1] मुख्य प्रोफ़ाइल लेवल 3 के साथ काम करना चाहिए. साथ ही, इसका रिज़ॉल्यूशन 512 x 512 तक होना चाहिए.
• इसमें एचडी एन्कोडिंग प्रोफ़ाइलों के साथ काम करने की सुविधा होनी चाहिए, जैसा कि इस टेबल में बताया गया है.
• [C-SR-1] हमारा सुझाव है कि अगर हार्डवेयर एन्कोडर है, तो 720 x 480 एसडी प्रोफ़ाइल और एचडी प्रोफ़ाइल को एन्कोड करने की सुविधा का इस्तेमाल करें. इन प्रोफ़ाइल के बारे में नीचे दी गई टेबल में बताया गया है.

	एसडी	एचडी 720 पिक्सल	एचडी 1080 पिक्सल	यूएचडी
वीडियो रिज़ॉल्यूशन	720 x 480 पिक्सल	1280 x 720 पिक्सल	1920 x 1080 पिक्सल	3840 x 2160 पिक्सल
वीडियो फ़्रेम रेट	30 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड
वीडियो बिटरेट	1.6 एमबीपीएस	4 एमबीपीएस	5 एमबीपीएस	20 एमबीपीएस

नई ज़रूरी शर्तें लागू करना

5.2.6. AV1

अगर डिवाइस में AV1 कोडेक काम करता है, तो:

• [C-1-1] यह ज़रूरी है कि डिवाइस, 8-बिट और 10-बिट वाले कॉन्टेंट के साथ-साथ, मुख्य प्रोफ़ाइल के साथ काम करे.

• [C-1-2] परफ़ॉर्मेंस डेटा पब्लिश करना ज़रूरी है. इसका मतलब है कि नीचे दी गई टेबल में दिए गए रिज़ॉल्यूशन के लिए, getSupportedFrameRatesFor() या getSupportedPerformancePoints() एपीआई के ज़रिए परफ़ॉर्मेंस डेटा को रिपोर्ट करना ज़रूरी है.

• [C-1-3] एचडीआर मेटाडेटा को स्वीकार करना और उसे बिटरस्ट्रीम में आउटपुट करना ज़रूरी है

अगर AV1 एन्कोडर को हार्डवेयर से तेज़ किया जाता है, तो:

• [C-2-1] यह ज़रूरी है कि डिवाइस, नीचे दी गई टेबल में दी गई एचडी1080p एन्कोडिंग प्रोफ़ाइल के साथ काम करे:

	एसडी	एचडी 720 पिक्सल	एचडी 1080 पिक्सल	यूएचडी
वीडियो रिज़ॉल्यूशन	720 x 480 पिक्सल	1280 x 720 पिक्सल	1920 x 1080 पिक्सल	3840 x 2160 पिक्सल
वीडियो फ़्रेम रेट	30 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड
वीडियो बिटरेट	5 एमबीपीएस	8 एमबीपीएस	16 एमबीपीएस	50 एमबीपीएस

नई ज़रूरी शर्तें खत्म करना

5.3. वीडियो डिकोड करना

अगर डिवाइस पर VP8, VP9, H.264 या H.265 कोडेक काम करते हैं, तो:

• [C-1-1] यह ज़रूरी है कि डिवाइस पर सभी VP8, VP9, H.264, और H.265 कोडेक के लिए, एक ही स्ट्रीम में स्टैंडर्ड Android API की मदद से, रियल टाइम में डाइनैमिक वीडियो रिज़ॉल्यूशन और फ़्रेम रेट स्विच करने की सुविधा काम करे. साथ ही, यह सुविधा डिवाइस पर हर कोडेक के लिए, सबसे ज़्यादा रिज़ॉल्यूशन तक काम करे.

5.3.1. MPEG-2

अगर डिवाइस में MPEG-2 डिकोडर काम करते हैं, तो:

• [C-1-1] मुख्य प्रोफ़ाइल के हाई लेवल के साथ काम करना चाहिए.

5.3.2. H.263

अगर डिवाइस में H.263 डीकोडर काम करते हैं, तो:

• [C-1-1] यह ज़रूरी है कि डिवाइस, बेसलाइन प्रोफ़ाइल लेवल 30 के साथ काम करे (30fps @ 384kbps पर CIF, QCIF, और SQCIF रिज़ॉल्यूशन) और लेवल 45 के साथ काम करे (30fps @ 128kbps पर QCIF और SQCIF रिज़ॉल्यूशन).

5.3.3. MPEG-4

अगर डिवाइस में MPEG-4 डिकोडर लागू किए गए हैं, तो:

• [C-1-1] यह ज़रूरी है कि ऐप्लिकेशन, सिंपल प्रोफ़ाइल के लेवल 3 के साथ काम करे.

5.3.4. H.264

अगर डिवाइस में H.264 डीकोडर काम करते हैं, तो:

• [C-1-1] मुख्य प्रोफ़ाइल लेवल 3.1 और बेसलाइन प्रोफ़ाइल के साथ काम करना चाहिए. ASO (स्लाइस का मनमुताबिक क्रम), FMO (फ़्लेक्सिबल मैक्रोब्लॉक ऑर्डरिंग), और RS (रिडंडेंट स्लाइस) के लिए, सहायता देना ज़रूरी नहीं है.
• [C-1-2] यह ज़रूरी है कि डिवाइस, नीचे दी गई टेबल में दी गई एसडी (स्टैंडर्ड डेफ़िनिशन) प्रोफ़ाइल वाले वीडियो को डिकोड कर सके. साथ ही, यह भी ज़रूरी है कि डिवाइस, बेसलाइन प्रोफ़ाइल और मुख्य प्रोफ़ाइल लेवल 3.1 (इसमें 720p30 भी शामिल है) के साथ एन्कोड किए गए वीडियो को डिकोड कर सके.
• यह एचडी (हाई डेफ़िनिशन) प्रोफ़ाइलों वाले वीडियो को डिकोड कर सकता है, जैसा कि नीचे दी गई टेबल में बताया गया है.

अगर Display.getSupportedModes() तरीके से रिपोर्ट की गई ऊंचाई, वीडियो रिज़ॉल्यूशन के बराबर या उससे ज़्यादा है, तो डिवाइस पर लागू होने वाले ये नियम:

• [C-2-1] यह ज़रूरी है कि डिवाइस, नीचे दी गई टेबल में बताई गई एचडी 720p वीडियो डिकोडिंग प्रोफ़ाइल के साथ काम करे.
• [C-2-2] यह ज़रूरी है कि डिवाइस, नीचे दी गई टेबल में दी गई एचडी 1080p वीडियो डिकोडिंग प्रोफ़ाइल के साथ काम करे.

	एसडी (कम क्वालिटी)	एसडी (अच्छी क्वालिटी)	एचडी 720 पिक्सल	एचडी 1080 पिक्सल
वीडियो रिज़ॉल्यूशन	320 x 240 पिक्सल	720 x 480 पिक्सल	1280 x 720 पिक्सल	1920 x 1080 पिक्सल
वीडियो फ़्रेम रेट	30 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड	60 एफ़पीएस (फ़्रेम प्रति सेकंड)	30 FPS (60 FPS^टेलीविज़न)
वीडियो बिटरेट	800 केबीपीएस	2 एमबीपीएस	8 एमबीपीएस	20 एमबीपीएस

5.3.5. H.265 (HEVC)

अगर डिवाइस में H.265 कोडेक काम करता है, तो:

• [C-1-1] यह ज़रूरी है कि यह मेन प्रोफ़ाइल लेवल 3 के मुख्य टीयर और एसडी वीडियो डिकोड करने वाली प्रोफ़ाइलों के साथ काम करे, जैसा कि नीचे दी गई टेबल में बताया गया है.
• यह एचडी डिकोडिंग प्रोफ़ाइलों के साथ काम करना चाहिए, जैसा कि नीचे दी गई टेबल में बताया गया है.
• [C-1-2] अगर डिवाइस में हार्डवेयर डिकोडर है, तो यह ज़रूरी है कि वह एचडी डिकोडिंग प्रोफ़ाइल के साथ काम करे. इन प्रोफ़ाइलों के बारे में नीचे दी गई टेबल में बताया गया है.

अगर Display.getSupportedModes() तरीके से रिपोर्ट की गई ऊंचाई, वीडियो रिज़ॉल्यूशन के बराबर या उससे ज़्यादा है, तो:

• [C-2-1] डिवाइस पर, 720, 1080, और यूएचडी प्रोफ़ाइलों को डिकोड करने के लिए, H.265 या VP9 में से कम से कम एक कोडिंग का इस्तेमाल किया जाना चाहिए.

	एसडी (कम क्वालिटी)	एसडी (अच्छी क्वालिटी)	एचडी 720 पिक्सल	एचडी 1080 पिक्सल	यूएचडी
वीडियो रिज़ॉल्यूशन	352 x 288 पिक्सल	720 x 480 पिक्सल	1280 x 720 पिक्सल	1920 x 1080 पिक्सल	3840 x 2160 पिक्सल
वीडियो फ़्रेम रेट	30 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड	30/60 एफ़पीएस (60 एफ़पीएस^H.265 हार्डवेयर डिकोडिंग की सुविधा वाला टीवी)	60 एफ़पीएस (फ़्रेम प्रति सेकंड)
वीडियो बिटरेट	600 केबीपीएस	1.6 एमबीपीएस	4 एमबीपीएस	5 एमबीपीएस	20 एमबीपीएस

अगर डिवाइस पर Media API के ज़रिए एचडीआर प्रोफ़ाइल काम करने का दावा किया जाता है, तो:

• [C-3-1] डिवाइस में एचडीआर की सुविधा लागू करने के लिए, यह ज़रूरी है कि वह ऐप्लिकेशन से ज़रूरी एचडीआर मेटाडेटा स्वीकार करे. साथ ही, बिटरस्ट्रीम और/या कंटेनर से ज़रूरी एचडीआर मेटाडेटा को निकालने और उसे आउटपुट करने की सुविधा भी दे.
• [C-3-2] डिवाइस पर एचडीआर कॉन्टेंट को डिवाइस की स्क्रीन या स्टैंडर्ड वीडियो आउटपुट पोर्ट (उदाहरण के लिए, एचडीएमआई).

5.3.6. VP8

अगर डिवाइस में VP8 कोडेक काम करता है, तो:

• [C-1-1] यह ज़रूरी है कि डिवाइस, नीचे दी गई टेबल में मौजूद एसडी डिकोडिंग प्रोफ़ाइलों के साथ काम करे.
• ऐसे हार्डवेयर VP8 कोडेक का इस्तेमाल करना चाहिए जो ज़रूरी शर्तों को पूरा करता हो.
• यह टेबल में दी गई एचडी डिकोडिंग प्रोफ़ाइलों के साथ काम करनी चाहिए.

अगर Display.getSupportedModes() तरीके से मिली ऊंचाई, वीडियो रिज़ॉल्यूशन के बराबर या उससे ज़्यादा है, तो:

• [C-2-1] डिवाइस पर, नीचे दी गई टेबल में बताई गई 720p प्रोफ़ाइलें काम करनी चाहिए.
• [C-2-2] डिवाइस पर, नीचे दी गई टेबल में बताई गई 1080p प्रोफ़ाइलों का इस्तेमाल किया जा सकता है.

	एसडी (कम क्वालिटी)	एसडी (अच्छी क्वालिटी)	एचडी 720 पिक्सल	एचडी 1080 पिक्सल
वीडियो रिज़ॉल्यूशन	320 x 180 पिक्सल	640 x 360 पिक्सल	1280 x 720 पिक्सल	1920 x 1080 पिक्सल
वीडियो फ़्रेम रेट	30 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड	30 FPS (60 FPS^टेलीविज़न)	30 (60 fps^टेलीविज़न)
वीडियो बिटरेट	800 केबीपीएस	2 एमबीपीएस	8 एमबीपीएस	20 एमबीपीएस

5.3.7. VP9

अगर डिवाइस में VP9 कोडेक काम करता है, तो:

• [C-1-1] यह ज़रूरी है कि डिवाइस, एसडी वीडियो को डिकोड करने वाली प्रोफ़ाइलों के साथ काम करे. इन प्रोफ़ाइलों के बारे में यहां दी गई टेबल में बताया गया है.
• यह एचडी डिकोडिंग प्रोफ़ाइलों के साथ काम करना चाहिए, जैसा कि नीचे दी गई टेबल में बताया गया है.

अगर डिवाइस पर VP9 कोडेक और हार्डवेयर डिकोडर काम करते हैं, तो:

• [C-2-1] एचडी डिकोडिंग प्रोफ़ाइलों के साथ काम करना चाहिए, जैसा कि नीचे दी गई टेबल में बताया गया है.

अगर Display.getSupportedModes() तरीके से रिपोर्ट की गई ऊंचाई, वीडियो रिज़ॉल्यूशन के बराबर या उससे ज़्यादा है, तो:

• [C-3-1] डिवाइस पर, 720, 1080, और यूएचडी प्रोफ़ाइलों को डिकोड करने के लिए, VP9 या H.265 में से कम से कम एक कोडिंग सिस्टम का इस्तेमाल किया जाना चाहिए.

	एसडी (कम क्वालिटी)	एसडी (अच्छी क्वालिटी)	एचडी 720 पिक्सल	एचडी 1080 पिक्सल	यूएचडी
वीडियो रिज़ॉल्यूशन	320 x 180 पिक्सल	640 x 360 पिक्सल	1280 x 720 पिक्सल	1920 x 1080 पिक्सल	3840 x 2160 पिक्सल
वीडियो फ़्रेम रेट	30 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड	30 एफ़पीएस (60 एफ़पीएस^टीवी पर VP9 हार्डवेयर डिकोडिंग)	60 एफ़पीएस (फ़्रेम प्रति सेकंड)
वीडियो बिटरेट	600 केबीपीएस	1.6 एमबीपीएस	4 एमबीपीएस	5 एमबीपीएस	20 एमबीपीएस

अगर डिवाइस में 'CodecProfileLevel' मीडिया एपीआई की मदद से, VP9Profile2 या VP9Profile3 के साथ काम करने का दावा किया जाता है, तो:

• 12-बिट फ़ॉर्मैट का इस्तेमाल करना ज़रूरी नहीं है.

अगर डिवाइस में, मीडिया एपीआई के ज़रिए एचडीआर प्रोफ़ाइल (VP9Profile2HDR, VP9Profile2HDR10Plus, VP9Profile3HDR, VP9Profile3HDR10Plus) के साथ काम करने का दावा किया जाता है, तो:

• [C-4-1] डिवाइस पर लागू होने वाले एप्लिकेशन में, एचडीआर मेटाडेटा की ज़रूरी शर्तें पूरी होनी चाहिए. जैसे, सभी एचडीआर प्रोफ़ाइलों के लिए KEY_HDR_STATIC_INFO और एचडीआर10 प्लस प्रोफ़ाइलों के लिए 'KEY_HDR10_PLUS_INFO'. साथ ही, इनमें बिटरस्ट्रीम और/या कंटेनर से ज़रूरी एचडीआर मेटाडेटा को निकालने और उसे आउटपुट करने की सुविधा भी होनी चाहिए.
• [C-4-2] डिवाइस पर एचडीआर वीडियो को डिवाइस की स्क्रीन या स्टैंडर्ड वीडियो आउटपुट पोर्ट (उदाहरण के लिए, एचडीएमआई).

5.3.8. Dolby Vision

अगर डिवाइस में, HDR_TYPE_DOLBY_VISION के ज़रिए Dolby Vision डिकोडर के साथ काम करने की सुविधा का एलान किया गया है, तो:

• [C-1-1] आपको Dolby Vision की सुविधा वाला एक्सट्रैक्टर देना होगा.
• [C-1-2] डिवाइस की स्क्रीन या स्टैंडर्ड वीडियो आउटपुट पोर्ट (उदाहरण के लिए, एचडीएमआई).
• [C-1-3] अगर पिछली वर्शन के साथ काम करने वाली बेस लेयर मौजूद हैं, तो उनका ट्रैक आईडी, एक साथ काम करने वाली Dolby Vision लेयर के ट्रैक आईडी जैसा होना चाहिए.

5.3.9. AV1

अगर डिवाइस में AV1 कोडेक काम करता है, तो:

• [C-1-1] यह ज़रूरी है कि डिवाइस, 10-बिट वाले कॉन्टेंट के साथ-साथ प्रोफ़ाइल 0 के साथ काम करे.

नई ज़रूरी शर्तें लागू करना

अगर डिवाइस में AV1 कोडेक काम करता है और उसे तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराया जाता है, तो:

• [C-1-1] यह ज़रूरी है कि डिवाइस, 8-बिट और 10-बिट वाले कॉन्टेंट के साथ-साथ, मुख्य प्रोफ़ाइल के साथ काम करे.

अगर डिवाइस में हार्डवेयर से तेज़ किए गए डिकोडर के साथ AV1 कोडेक की सुविधा उपलब्ध है, तो:

• [C-2-1] अगर Display.getSupportedModes() के तरीके से रिपोर्ट की गई ऊंचाई 720p के बराबर या उससे ज़्यादा है, तो यह ज़रूरी है कि डिवाइस, नीचे दी गई टेबल में दी गई कम से कम एचडी 720p वीडियो डिकोडिंग प्रोफ़ाइलों को डिकोड कर सके.
• [C-2-2] अगर Display.getSupportedModes() के तरीके से रिपोर्ट की गई ऊंचाई 1080 पिक्सल या उससे ज़्यादा है, तो यह ज़रूरी है कि डिवाइस, नीचे दी गई टेबल में दी गई कम से कम एचडी 1080 पिक्सल वीडियो डिकोडिंग प्रोफ़ाइलों को डिकोड कर सके.

	एसडी	एचडी 720 पिक्सल	एचडी 1080 पिक्सल	यूएचडी
वीडियो रिज़ॉल्यूशन	720 x 480 पिक्सल	1280 x 720 पिक्सल	1920 x 1080 पिक्सल	3840 x 2160 पिक्सल
वीडियो फ़्रेम रेट	30 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड
वीडियो बिटरेट	5 एमबीपीएस	8 एमबीपीएस	16 एमबीपीएस	50 एमबीपीएस

अगर डिवाइस पर Media API की मदद से HDR प्रोफ़ाइल काम करती है, तो:

• [C-3-1] यह ज़रूरी है कि एचडीआर मेटाडेटा को बिटस्ट्रीम और/या कंटेनर से निकाला और आउटपुट किया जा सके.
• [C-3-2] डिवाइस की स्क्रीन या स्टैंडर्ड वीडियो आउटपुट पोर्ट (उदाहरण के लिए, एचडीएमआई) पर एचडीआर कॉन्टेंट सही तरीके से दिखना चाहिए.

नई ज़रूरी शर्तें खत्म करना

5.4. ऑडियो रिकॉर्डिंग

इस सेक्शन में बताई गई कुछ ज़रूरी शर्तों को Android 4.3 के बाद से 'चाहिए' के तौर पर दिखाया गया है. हालांकि, आने वाले वर्शन के लिए, 'चाहिए' को 'ज़रूरी है' में बदलने का प्लान है. मौजूदा और नए Android डिवाइसों के लिए, इसका ज़रूर सुझाव दिया जाता है कि वे 'ज़रूरी है' के तौर पर दी गई इन शर्तों को पूरा करें. ऐसा न करने पर, आने वाले समय में डिवाइसों को Android के नए वर्शन पर अपग्रेड नहीं किया जा सकेगा.

5.4.1. रॉ ऑडियो कैप्चर और माइक्रोफ़ोन की जानकारी

अगर डिवाइस पर android.hardware.microphone लागू किया जाता है, तो:

• [C-1-1] किसी भी AudioRecord या AAudio इनपुट स्ट्रीम के लिए, रॉ ऑडियो कॉन्टेंट को कैप्चर करने की अनुमति होनी चाहिए. कम से कम, इन सुविधाओं के साथ काम करना ज़रूरी है:

  • फ़ॉर्मैट: लीनियर पीसीएम, 16-बिट
  • सैंपलिंग रेट: 8000, 11025, 16000, 44100, 48000 हर्ट्ज़
  • चैनल: मोनो
  • ऑडियो के सोर्स: DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED, या VOICE_PERFORMANCE. यह AAudio में मौजूद, इनपुट प्रीसेट के बराबर पर भी लागू होता है. उदाहरण के लिए, AAUDIO_INPUT_PRESET_CAMCORDER.

• इसकी मदद से, रॉ ऑडियो कॉन्टेंट को कैप्चर करने की अनुमति होनी चाहिए. यह कॉन्टेंट इन विशेषताओं वाला होना चाहिए:

  • फ़ॉर्मैट: लीनियर PCM, 16-बिट, और 24-बिट
  • सैंपलिंग रेट: 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 हर्ट्ज़
  • चैनल: डिवाइस पर मौजूद माइक्रोफ़ोन की संख्या के बराबर चैनल

• [C-1-2] अप-सैंपलिंग के बिना, ऊपर दी गई सैंपल दरों पर रिकॉर्ड करना ज़रूरी है.

• [C-1-3] ऊपर दी गई सैंपल रेट, डाउन-सैंपलिंग की मदद से कैप्चर किए जाने पर, इसमें सही ऐंटी-ऐलिऐसिंग फ़िल्टर ज़रूर शामिल होना चाहिए.

• रॉ ऑडियो कॉन्टेंट को AM रेडियो और डीवीडी क्वालिटी में कैप्चर करने की अनुमति होनी चाहिए. इसका मतलब है कि:

  • फ़ॉर्मैट: लीनियर पीसीएम, 16-बिट
  • सैंपलिंग रेट: 22050, 48000 हर्ट्ज़
  • चैनल: स्टीरियो

• [C-1-4] MicrophoneInfo एपीआई का पालन करना ज़रूरी है. साथ ही, डिवाइस पर उपलब्ध माइक्रोफ़ोन की जानकारी सही तरीके से भरनी होगी, ताकि तीसरे पक्ष के ऐप्लिकेशन AudioManager.getMicrophones() एपीआई की मदद से उनका इस्तेमाल कर सकें. यह जानकारी, MediaRecorder.AudioSources DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED या VOICE_PERFORMANCE का इस्तेमाल करके, ऑडियो रिकॉर्ड करने की सुविधा चालू करने के लिए भरी जानी चाहिए. अगर डिवाइस में AM रेडियो और डीवीडी क्वालिटी में रॉ ऑडियो कॉन्टेंट कैप्चर करने की सुविधा है, तो:

• [C-2-1] 16000:22050 या 44100:48000 से ज़्यादा के रेशियो में, अप-सैंपलिंग के बिना रिकॉर्ड करना ज़रूरी है.

• [C-2-2] अप-सैंपलिंग या डाउन-सैंपलिंग के लिए, सही ऐंटी-ऐलिऐसिंग फ़िल्टर शामिल करना ज़रूरी है.

5.4.2. आवाज़ पहचानने की सुविधा के लिए रिकॉर्ड करना

अगर डिवाइस पर android.hardware.microphone लागू किया जाता है, तो:

• [C-1-1] android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION ऑडियो सोर्स को 44100 और 48000 में से किसी एक सैंपलिंग रेट पर कैप्चर करना ज़रूरी है.
• [C-1-2] AudioSource.VOICE_RECOGNITION ऑडियो सोर्स से ऑडियो स्ट्रीम रिकॉर्ड करते समय, शोर कम करने वाली ऑडियो प्रोसेसिंग को डिफ़ॉल्ट रूप से बंद करना ज़रूरी है.

• [C-1-3] AudioSource.VOICE_RECOGNITION ऑडियो सोर्स से ऑडियो स्ट्रीम रिकॉर्ड करते समय, डिफ़ॉल्ट रूप से ऑटोमैटिक गेन कंट्रोल की सुविधा बंद होनी चाहिए.

• यह माइक्रोफ़ोन, मध्य-फ़्रीक्वेंसी रेंज में, ऐम्प्ल्यट्यूड-बनाम-फ़्रीक्वेंसी की सुविधाओं को लगभग फ़्लैट दिखाता है. खास तौर पर, आवाज़ पहचानने वाले ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन के लिए, 100 हर्ट्ज़ से 4,000 हर्ट्ज़ तक ±3dB.

• [C-SR-1] हमारा सुझाव है कि कम फ़्रीक्वेंसी रेंज में, ऐम्प्ल्यट्यूड लेवल दिखाएं: खास तौर पर, वॉइस पहचानने वाले ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन के लिए, मध्य फ़्रीक्वेंसी रेंज की तुलना में 30 हर्ट्ज़ से 100 हर्ट्ज़ तक ±20 डीबी.

• [C-SR-2] हमारा सुझाव है कि आप आवाज़ पहचानने वाले ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए जाने वाले हर माइक्रोफ़ोन के लिए, हाई फ़्रीक्वेंसी रेंज में ऐम्प्ल्यट्यूड लेवल दिखाएं. खास तौर पर, 4,000 हर्ट्ज़ से 22 केएचज़ तक ±30 डीबी की रेंज में.

• ऑडियो इनपुट की संवेदनशीलता को इस तरह सेट करना चाहिए कि 1000 हर्ट्ज़ का साइनसोइडल टोन सोर्स, 90 डीबी साउंड प्रेशर लेवल (एसपीएल) पर चलता रहे. एसपीएल को माइक्रोफ़ोन से 30 सेंटीमीटर की दूरी पर माइक्रोफ़ोन के बगल में मापा जाता है. इससे, वॉइस रिकॉग्निशन ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन के लिए, 16 बिट-सैंपल के लिए 1770 और 3530 की रेंज में आरएमएस 2500 का आदर्श रिस्पॉन्स मिलता है. इसके अलावा, फ़्लोटिंग पॉइंट/डबल प्रिसीज़न सैंपल के लिए -22.35 डीबी ±3 डीबी फ़ुल स्केल मिलता है.

• वॉइस रिकॉग्निशन ऑडियो स्ट्रीम को रिकॉर्ड करना चाहिए, ताकि पीसीएम ऐम्प्लिटीड लेवल, इनपुट एसपीएल में हुए बदलावों को कम से कम 30 डीबी की रेंज में, माइक्रोफ़ोन पर -18 डीबी से +12 डीबी तक के एसपीएल में लीनियर तरीके से ट्रैक कर सकें.

• माइक्रोफ़ोन पर 90 dB SPL इनपुट लेवल पर, 1 kHz के लिए कुल हार्मोनिक डिस्टॉर्शन (THD) 1% से कम होना चाहिए.

अगर डिवाइस में android.hardware.microphone और शोर कम करने की टेक्नोलॉजी का इस्तेमाल किया गया है, तो:

• [C-2-1] इस ऑडियो इफ़ेक्ट को android.media.audiofx.NoiseSuppressor API की मदद से कंट्रोल करने की अनुमति होनी चाहिए.
• [C-2-2] AudioEffect.Descriptor.uuid फ़ील्ड की मदद से, हर ग़ैर-ज़रूरी आवाज़ को कम करने वाली टेक्नोलॉजी के लागू होने की खास तौर पर पहचान की जानी चाहिए.

5.4.3. वीडियो चलाने की जगह बदलने के लिए कैप्चर करना

android.media.MediaRecorder.AudioSource क्लास में REMOTE_SUBMIX ऑडियो सोर्स शामिल होता है.

अगर डिवाइस पर लागू किए गए एपीआई में android.hardware.audio.output और android.hardware.microphone, दोनों का एलान किया गया है, तो:

• [C-1-1] REMOTE_SUBMIX ऑडियो सोर्स को सही तरीके से लागू करना ज़रूरी है, ताकि जब कोई ऐप्लिकेशन इस ऑडियो सोर्स से रिकॉर्ड करने के लिए android.media.AudioRecord एपीआई का इस्तेमाल करे, तो वह इनके अलावा सभी ऑडियो स्ट्रीम को रिकॉर्ड करे:

  • AudioManager.STREAM_RING
  • AudioManager.STREAM_ALARM
  • AudioManager.STREAM_NOTIFICATION

5.4.4. अकूस्टिक इको कैंसलर

अगर डिवाइस पर android.hardware.microphone लागू किया जाता है, तो:

• AudioSource.VOICE_COMMUNICATION का इस्तेमाल करके कैप्चर करते समय, अकूस्टिक इको रद्द करने वाली (एईसी) टेक्नोलॉजी को लागू करना चाहिए. यह टेक्नोलॉजी, वॉइस कम्यूनिकेशन के लिए बनाई गई है और कैप्चर पाथ पर लागू की जाती है.

अगर डिवाइस में इको को खत्म करने की सुविधा है, तो AudioSource.VOICE_COMMUNICATION को चुनने पर, इसे कैप्चर किए गए ऑडियो के पाथ में जोड़ दिया जाता है. ऐसा करने पर:

• [C-SR-1] हमारा सुझाव है कि आप AcousticEchoCanceler एपीआई के AcousticEchoCanceler.isAvailable() तरीके से, इसकी जानकारी दें
• [C-SR-2] हमारा सुझाव है कि इस ऑडियो इफ़ेक्ट को AcousticEchoCanceler एपीआई की मदद से कंट्रोल किया जा सकता है.
• [C-SR-3] हमारा सुझाव है कि AudioEffect.Descriptor.uuid फ़ील्ड का इस्तेमाल करके, एईसी टेक्नोलॉजी के हर लागू होने की खास तौर पर पहचान करें.

5.4.5. एक साथ कई स्क्रीन कैप्चर करना

अगर डिवाइस में android.hardware.microphone का एलान किया गया है, तो उसे इस दस्तावेज़ में बताए गए तरीके से, एक साथ कई फ़ोटो कैप्चर करने की सुविधा लागू करनी होगी. खास तौर से:

• [C-1-1] ऐक्सेस करने की अनुमति देने वाली किसी सुलभता सेवा को AudioSource.VOICE_RECOGNITION और कम से कम एक ऐप्लिकेशन को एक साथ माइक्रोफ़ोन का ऐक्सेस देना चाहिए.AudioSource
• [C-1-2] डिवाइस में पहले से इंस्टॉल किए गए ऐसे ऐप्लिकेशन को माइक्रोफ़ोन का ऐक्सेस देना ज़रूरी है जो Assistant की भूमिका निभाता हो. साथ ही, कम से कम एक ऐसा ऐप्लिकेशन भी होना चाहिए जो AudioSource.VOICE_COMMUNICATION या AudioSource.CAMCORDER के अलावा किसी भी AudioSource की मदद से ऑडियो रिकॉर्ड करता हो.
• [C-1-3] ऐक्सेसibiliti सेवा को छोड़कर, किसी भी दूसरे ऐप्लिकेशन के लिए ऑडियो कैप्चर को बंद करना ज़रूरी है. ऐसा तब करना होगा, जब कोई ऐप्लिकेशन AudioSource.VOICE_COMMUNICATION या AudioSource.CAMCORDER का इस्तेमाल करके कैप्चर कर रहा हो. हालांकि, जब कोई ऐप्लिकेशन AudioSource.VOICE_COMMUNICATION के ज़रिए कॉल रिकॉर्ड कर रहा हो, तो कोई दूसरा ऐप्लिकेशन भी कॉल रिकॉर्ड कर सकता है. इसके लिए ज़रूरी है कि वह ऐप्लिकेशन, पहले से इंस्टॉल किया गया ऐप्लिकेशन हो और उसके पास CAPTURE_AUDIO_OUTPUT अनुमति हो.
• [C-1-4] अगर एक साथ दो या उससे ज़्यादा ऐप्लिकेशन कैप्चर कर रहे हैं और अगर किसी भी ऐप्लिकेशन के सबसे ऊपर यूज़र इंटरफ़ेस (यूआई) नहीं है, तो सबसे हाल ही में कैप्चर शुरू करने वाले ऐप्लिकेशन को ऑडियो मिलता है.

5.5. ऑडियो प्लेबैक

Android में, ऐप्लिकेशन को ऑडियो आउटपुट डिवाइस के ज़रिए ऑडियो चलाने की अनुमति देने की सुविधा शामिल है. इस बारे में, सेक्शन 7.8.2 में बताया गया है.

5.5.1. रॉ ऑडियो चलाना

अगर डिवाइस पर android.hardware.audio.output लागू किया जाता है, तो:

• [C-1-1] ऐप्लिकेशन में रॉ ऑडियो कॉन्टेंट को चलाने की अनुमति होनी चाहिए. साथ ही, यह कॉन्टेंट इनके मुताबिक होना चाहिए:

  • सोर्स फ़ॉर्मैट: लीनियर पीसीएम, 16-बिट, 8-बिट, फ़्लोट
  • चैनल: मोनो, स्टीरियो, और ज़्यादा से ज़्यादा आठ चैनलों वाले मान्य मल्टीचैनल कॉन्फ़िगरेशन
  • सैंपलिंग रेट (हर्ट्ज़ में):
    • ऊपर दिए गए चैनल कॉन्फ़िगरेशन में, 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000
    • मोनो और स्टीरियो में 96,000

5.5.2. ऑडियो इफ़ेक्ट

डिवाइस पर लागू करने के लिए, Android ऑडियो इफ़ेक्ट के लिए एपीआई उपलब्ध कराता है.

अगर डिवाइस में android.hardware.audio.output सुविधा का एलान किया गया है, तो:

• [C-1-1] EFFECT_TYPE_EQUALIZER और EFFECT_TYPE_LOUDNESS_ENHANCER को लागू करने की सुविधा होनी चाहिए. इन्हें, AudioEffect के सबक्लास Equalizer और LoudnessEnhancer की मदद से कंट्रोल किया जा सकता है.
• [C-1-2] विज़ुअलाइज़र एपीआई को लागू करने की सुविधा होनी चाहिए. इसे Visualizer क्लास की मदद से कंट्रोल किया जा सकता है.
• [C-1-3] EFFECT_TYPE_DYNAMICS_PROCESSING को लागू करने की सुविधा के साथ काम करना चाहिए, जिसे AudioEffect सबक्लास DynamicsProcessing की मदद से कंट्रोल किया जा सकता है.

नई ज़रूरी शर्तें लागू करना

• [C-1-4] यह ज़रूरी है कि फ़्लोटिंग-पॉइंट इनपुट और आउटपुट के साथ, ऑडियो इफ़ेक्ट काम करते हों.
• [C-1-5] यह पक्का करना ज़रूरी है कि ऑडियो इफ़ेक्ट, मिक्सर चैनल की संख्या तक कई चैनलों के साथ काम करते हों. मिक्सर चैनल की संख्या को FCC_LIMIT भी कहा जाता है.

नई ज़रूरी शर्तें खत्म करना

• EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB, और EFFECT_TYPE_VIRTUALIZER को लागू करने के लिए, AudioEffect सब-क्लास BassBoost, EnvironmentalReverb, PresetReverb, और Virtualizer के ज़रिए कंट्रोल किया जा सकता है.
• [C-SR-1] हमारा सुझाव है कि फ़्लोटिंग-पॉइंट और कई चैनलों में इफ़ेक्ट का इस्तेमाल किया जाए.

5.5.3. ऑडियो आउटपुट का वॉल्यूम

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

• AudioAttributes में बताए गए कॉन्टेंट टाइप या इस्तेमाल के हिसाब से, हर ऑडियो स्ट्रीम के लिए ऑडियो वॉल्यूम को अलग से अडजस्ट करने की अनुमति होनी चाहिए. साथ ही, android.car.CarAudioManager में सार्वजनिक तौर पर बताए गए कार ऑडियो के इस्तेमाल के हिसाब से भी ऐसा किया जा सकता है.

5.5.4. ऑडियो ऑफ़लोड करना

अगर डिवाइस पर ऑडियो ऑफ़लोड करके चलाने की सुविधा काम करती है, तो:

• [C-SR-1] हमारा सुझाव है कि एक ही फ़ॉर्मैट वाली दो क्लिप के बीच, बिना किसी रुकावट के चलने वाले ऑडियो कॉन्टेंट को ट्रिम करें. ऐसा तब करें, जब AudioTrack gapless API और MediaPlayer के मीडिया कंटेनर में ऐसा करने के लिए कहा गया हो.

5.6. ऑडियो के इंतज़ार का समय

ऑडियो के इंतज़ार का समय, वह समय होता है जो किसी सिस्टम से ऑडियो सिग्नल पास होने में लगता है. रीयल-टाइम में साउंड इफ़ेक्ट पाने के लिए, कई तरह के ऐप्लिकेशन कम इंतज़ार के समय पर निर्भर करते हैं.

इस सेक्शन के लिए, इन परिभाषाओं का इस्तेमाल करें:

• आउटपुट में लगने वाला समय. जब कोई ऐप्लिकेशन, पीसीएम कोड वाले डेटा का फ़्रेम लिखता है और जब उससे जुड़ी आवाज़, डिवाइस पर मौजूद ट्रांसड्यूसर की मदद से, आस-पास के माहौल में सुनाई देती है या सिग्नल किसी पोर्ट से डिवाइस से बाहर निकलता है और उसे बाहर से देखा जा सकता है, तो उस बीच का समय.
• कोल्ड आउटपुट में लगने वाला समय. टाइमस्टैंप के आधार पर, आउटपुट स्ट्रीम शुरू होने और पहले फ़्रेम के प्रज़ेंटेशन के समय के बीच का समय. ऐसा तब होता है, जब अनुरोध से पहले ऑडियो आउटपुट सिस्टम बंद हो और काम न कर रहा हो.
• आउटपुट में लगने वाला लगातार समय. डिवाइस पर ऑडियो चलने के बाद, अगले फ़्रेम के लिए आउटपुट में लगने वाला समय.
• इनपुट में लगने वाला समय. यह समय अंतराल होता है, जब किसी ऑब्जेक्ट से आने वाली आवाज़, डिवाइस पर मौजूद ट्रांसड्यूसर पर पहुंचती है या सिग्नल किसी पोर्ट से डिवाइस में आता है और जब कोई ऐप्लिकेशन, PCM कोड वाले डेटा के उस फ़्रेम को पढ़ता है.
• इनपुट नहीं मिला. इनपुट सिग्नल का वह शुरुआती हिस्सा जो इस्तेमाल नहीं किया जा सकता या उपलब्ध नहीं है.
• कोल्ड इनपुट लैटेंसी. स्ट्रीम शुरू करने से लेकर, पहला मान्य फ़्रेम मिलने तक का समय. ऐसा तब होता है, जब अनुरोध करने से पहले ऑडियो इनपुट सिस्टम बंद हो और काम न कर रहा हो.

• इनपुट में लगातार होने वाली देरी. डिवाइस के ऑडियो कैप्चर करने के दौरान, अगले फ़्रेम के लिए इनपुट में लगने वाला समय.

• कंटेंट के लोड होने में लगने वाला कुल समय. लगातार इनपुट में लगने वाले समय, लगातार आउटपुट में लगने वाले समय, और बफ़र पीरियड को जोड़ने पर मिलने वाला समय. बफ़र पीरियड की मदद से, ऐप्लिकेशन को सिग्नल को प्रोसेस करने और इनपुट और आउटपुट स्ट्रीम के बीच फ़ेज़ के अंतर को कम करने का समय मिलता है.

• OpenSL ES PCM बफ़र क्यू एपीआई. Android NDK में, PCM से जुड़े OpenSL ES एपीआई का सेट.

• AAudio नेटिव ऑडियो एपीआई. Android एनडीके में, AAudio एपीआई का सेट.

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

• glitch. ऑडियो सिग्नल में कुछ समय के लिए रुकावट आना या सैंपल की गलत वैल्यू दिखना. आम तौर पर, ऐसा आउटपुट के लिए बफ़र में डेटा कम होना, इनपुट के लिए बफ़र में डेटा ज़्यादा होना या डिजिटल या एनालॉग नॉइज़ के किसी अन्य सोर्स की वजह से होता है.

• कुल डेविएशन का माध्य. वैल्यू के किसी सेट के लिए, औसत से होने वाले बदलावों की कुल वैल्यू का औसत.

• टैप-टू-टोन के इंतज़ार का समय. स्क्रीन पर टैप करने और उस टैप की वजह से जनरेट हुई टोन के स्पीकर पर सुनाई देने के बीच का समय.

अगर डिवाइस में android.hardware.audio.output का एलान किया जाता है, तो उसे इन ज़रूरी शर्तों को पूरा करना होगा या उनसे बेहतर होना चाहिए:

• [C-1-1] AudioTrack.getTimestamp और AAudioStream_getTimestamp से मिला आउटपुट टाइमस्टैंप, +/- 2 मिलीसेकंड तक सटीक होता है.

• [C-1-2] कोल्ड आउटपुट में लगने वाला समय 500 मिलीसेकंड या उससे कम होना चाहिए.

• [C-1-3] AAudioStreamBuilder_openStream() का इस्तेमाल करके आउटपुट स्ट्रीम खोलने में 1,000 मिलीसेकंड से कम समय लगना चाहिए.

अगर डिवाइस पर android.hardware.audio.output का एलान किया जाता है, तो हमारा सुझाव है कि वे इन ज़रूरी शर्तों को पूरा करें या उनसे बेहतर बनाएं:

• [C-SR-1] स्पीकर के डेटा पाथ पर, 100 मिलीसेकंड या उससे कम का आउटपुट इंतज़ार का समय.
• [C-SR-2] टैप-टू-टोन में लगने वाला समय 80 मिलीसेकंड या उससे कम होना चाहिए.

• [C-SR-4] AudioTrack.getTimestamp और AAudioStream_getTimestamp से मिला आउटपुट टाइमस्टैंप, +/- 1 मिलीसेकंड तक सटीक होता है.

नई ज़रूरी शर्तें लागू करना

• [C-SR-4] AAudioStream_getTimestamp से मिले इनपुट और आउटपुट टाइमस्टैंप के आधार पर, राउंड ट्रिप के लिए गिनती की गई देरी का सुझाव दिया जाता है कि वह AAUDIO_PERFORMANCE_MODE_NONE और AAUDIO_PERFORMANCE_MODE_LOW_LATENCY के लिए, मापी गई राउंड ट्रिप देरी के 30 एमएसईसी के अंदर हो. साथ ही, स्पीकर, वायर वाले और वायरलेस हेडसेट के लिए भी ऐसा ही हो.

नई ज़रूरी शर्तें खत्म करना

अगर डिवाइस में ऊपर बताई गई ज़रूरी शर्तें पूरी की जाती हैं, तो AAudio नेटिव ऑडियो एपीआई का इस्तेमाल करने पर, शुरुआती कैलिब्रेशन के बाद, कम से कम एक ऑडियो आउटपुट डिवाइस पर लगातार आउटपुट में लगने वाला विलंब और आउटपुट शुरू होने में लगने वाला विलंब, इनके हिसाब से होना चाहिए:

• [C-SR-5] हमारा सुझाव है कि आप android.hardware.audio.low_latency सुविधा फ़्लैग का एलान करके, कम इंतज़ार वाले ऑडियो की शिकायत करें.
• [C-SR-6] हमारा सुझाव है कि आप AAudio API की मदद से, कम इंतज़ार वाले ऑडियो की ज़रूरी शर्तें पूरी करें.
• [C-SR-7] हमारा सुझाव है कि AAudioStream_getPerformanceMode() से AAUDIO_PERFORMANCE_MODE_LOW_LATENCY दिखाने वाली स्ट्रीम के लिए, AAudioStream_getFramesPerBurst() से मिली वैल्यू, प्रॉपर्टी कुंजी AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER के लिए android.media.AudioManager.getProperty(String) से मिली वैल्यू से कम या उसके बराबर हो.

अगर डिवाइस पर लागू किए गए तरीके, AAudio नेटिव ऑडियो एपीआई की मदद से कम इंतज़ार वाले ऑडियो की ज़रूरी शर्तों को पूरा नहीं करते, तो:

• [C-2-1] कम इंतज़ार वाले ऑडियो की सुविधा के काम करने की जानकारी नहीं दी जानी चाहिए.

अगर डिवाइस में android.hardware.microphone लागू किया गया है, तो उसे इनपुट ऑडियो से जुड़ी ये ज़रूरी शर्तें पूरी करनी होंगी:

• [C-3-1] AudioRecord.getTimestamp या AAudioStream_getTimestamp से मिले इनपुट टाइमस्टैंप में, +/- 2 मिलीसेकंड तक की गड़बड़ी की सीमा तय करें. यहां "गड़बड़ी" का मतलब सही वैल्यू से अलग होने से है.
• [C-3-2] कोल्ड इनपुट में लगने वाला समय 500 मिलीसेकंड या उससे कम होना चाहिए.
• [C-3-3] AAudioStreamBuilder_openStream() का इस्तेमाल करके इनपुट स्ट्रीम खोलने में 1,000 मिलीसेकंड से कम समय लगना चाहिए.

अगर डिवाइस में android.hardware.microphone को लागू किया जा रहा है, तो हमारा सुझाव है कि वे इनपुट ऑडियो से जुड़ी इन ज़रूरी शर्तों को पूरा करें:

• [C-SR-8] माइक्रोफ़ोन के डेटा पाथ पर, इनपुट के शुरू होने में 100 मिलीसेकंड या उससे कम समय लगना चाहिए.

• [C-SR-11] AudioRecord.getTimestamp या AAudioStream_getTimestamp से मिले इनपुट टाइमस्टैंप में, गड़बड़ी की सीमा को +/- 1 मिलीसेकंड तक सीमित करें.

अगर डिवाइस पर android.hardware.audio.output और android.hardware.microphone का एलान किया जाता है, तो:

• [C-SR-12] हमारा सुझाव है कि पांच मेज़रमेंट में, लगातार राउंड-ट्रिप के लिए औसत इंतज़ार का समय 50 मिलीसेकंड या उससे कम हो. साथ ही, कम से कम एक काम करने वाले पाथ पर, औसत एब्सोल्यूट डेविएशन 10 मिलीसेकंड से कम हो.

5.7. नेटवर्क प्रोटोकॉल

डिवाइस में लागू किए गए SDK टूल, ऑडियो और वीडियो चलाने के लिए, मीडिया नेटवर्क प्रोटोकॉल के साथ काम करने चाहिए. इस बारे में Android SDK टूल के दस्तावेज़ में बताया गया है.

हर उस कोडेक और कंटेनर फ़ॉर्मैट के लिए जिसे डिवाइस पर लागू करने की ज़रूरत है, डिवाइस पर लागू करने के लिए:

• [C-1-1] यह ज़रूरी है कि एचटीटीपी और एचटीटीपीएस पर, उस कोडेक या कंटेनर का इस्तेमाल किया जा सके.

• [C-1-2] एचटीटीपी लाइव स्ट्रीमिंग ड्राफ़्ट प्रोटोकॉल, वर्शन 7 के साथ, मीडिया सेगमेंट फ़ॉर्मैट की टेबल में दिखाए गए मीडिया सेगमेंट फ़ॉर्मैट के साथ काम करना चाहिए.

• [C-1-3] यह ज़रूरी है कि यह उसी RTSP पेलोड फ़ॉर्मैट के साथ काम करे जो नीचे दी गई टेबल में दिखाए गए हैं. अपवादों के बारे में जानने के लिए, कृपया सेक्शन 5.1 में टेबल के फ़ुटनोट देखें.

मीडिया सेगमेंट के फ़ॉर्मैट

सेगमेंट फ़ॉर्मैट	रेफ़रंस	ज़रूरी कोडेक के साथ काम करना
MPEG-2 ट्रांसपोर्ट स्ट्रीम	ISO 13818	वीडियो कोडेक: H264 AVC MPEG-4 SP MPEG-2 H264 AVC, MPEG2-4 SP, और MPEG-2 के बारे में जानकारी के लिए, सेक्शन 5.1.8 देखें. ऑडियो कोडेक: AAC AAC और इसके वैरिएंट के बारे में जानकारी के लिए, सेक्शन 5.1.3 देखें.
ADTS फ़्रेमिंग और ID3 टैग के साथ AAC	ISO 13818-7	AAC और इसके वैरिएंट के बारे में जानकारी के लिए, सेक्शन 5.1.1 देखें
WebVTT	WebVTT

आरटीएसपी (आरटीपी, एसडीपी)

प्रोफ़ाइल का नाम	रेफ़रंस	ज़रूरी कोडेक के साथ काम करना
H264 AVC	RFC 6184	H264 AVC के बारे में जानकारी के लिए, सेक्शन 5.1.8 देखें
MP4A-LATM	RFC 6416	AAC और इसके वैरिएंट के बारे में जानकारी के लिए, सेक्शन 5.1.3 देखें
H263-1998	RFC 3551 RFC 4629 RFC 2190	H263 के बारे में जानकारी के लिए, सेक्शन 5.1.8 देखें
H263-2000	RFC 4629	H263 के बारे में जानकारी के लिए, सेक्शन 5.1.8 देखें
एएमआर	RFC 4867	AMR-NB के बारे में जानकारी के लिए, सेक्शन 5.1.3 देखें
AMR-WB	RFC 4867	AMR-WB के बारे में जानकारी के लिए, सेक्शन 5.1.3 देखें
MP4V-ES	RFC 6416	MPEG-4 SP के बारे में जानकारी के लिए, सेक्शन 5.1.8 देखें
mpeg4-generic	RFC 3640	AAC और इसके वैरिएंट के बारे में जानकारी के लिए, सेक्शन 5.1.3 देखें
MP2T	RFC 2250	ज़्यादा जानकारी के लिए, एचटीटीपी लाइव स्ट्रीमिंग के नीचे एमपीईजी-2 ट्रांसपोर्ट स्ट्रीम देखें

5.8. Secure Media

अगर डिवाइस पर सुरक्षित वीडियो आउटपुट की सुविधा काम करती है और डिवाइस पर सुरक्षित प्लैटफ़ॉर्म का इस्तेमाल किया जा सकता है, तो:

• [C-1-1] Display.FLAG_SECURE के लिए सहायता उपलब्ध कराने का एलान करना ज़रूरी है.

अगर डिवाइस में Display.FLAG_SECURE और वाई-फ़ाई डिसप्ले प्रोटोकॉल के साथ काम करने की सुविधा है, तो:

• [C-2-1] Miracast जैसे वायरलेस प्रोटोकॉल से कनेक्ट किए गए डिसप्ले के लिए, लिंक को एन्क्रिप्ट करने के लिए, एचडीसीपी 2.x या उसके बाद के वर्शन जैसी किसी मज़बूत एन्क्रिप्शन सुविधा का इस्तेमाल करना ज़रूरी है.

अगर डिवाइस में Display.FLAG_SECURE की सुविधा काम करती है और तार से कनेक्ट किए गए बाहरी डिसप्ले की सुविधा काम करती है, तो:

• [C-3-1] उपयोगकर्ता के ऐक्सेस वाले वायर्ड पोर्ट से कनेक्ट किए गए सभी बाहरी डिसप्ले के लिए, HDCP 1.2 या इसके बाद के वर्शन का इस्तेमाल करना ज़रूरी है.

5.9. म्यूज़िकल इंस्ट्रुमेंट डिजिटल इंटरफ़ेस (एमआईडीआई)

अगर डिवाइस पर लागू की गई सुविधाओं की जानकारी देने वाली रिपोर्ट में, android.content.pm.PackageManager क्लास के ज़रिए android.software.midi सुविधा के काम करने की जानकारी दी गई है, तो:

• [C-1-1] एमआईडीआई की सुविधा वाले सभी हार्डवेयर ट्रांसपोर्ट के लिए, एमआईडीआई की सुविधा काम करनी चाहिए. इसके लिए, वे सामान्य गैर-एमआईडीआई कनेक्टिविटी उपलब्ध कराते हैं. ये ट्रांसपोर्ट ये हैं:

  • यूएसबी होस्ट मोड, सेक्शन 7.7
  • ब्लूटूथ LE पर MIDI, मुख्य भूमिका में काम कर रहा है, सेक्शन 7.4.3

• [C-1-2] ऐप्लिकेशन के बीच एमआईडीआई सॉफ़्टवेयर ट्रांसपोर्ट (वर्चुअल एमआईडीआई डिवाइस) के साथ काम करना चाहिए

• [C-1-3] इसमें libamidi.so (नेटिव MIDI सपोर्ट) शामिल होना चाहिए

• यूएसबी की मदद से कनेक्ट किए गए सहायक डिवाइस मोड में, एमआईडीआई की सुविधा काम करनी चाहिए, सेक्शन 7.7

5.10. प्रोफ़ेशनल ऑडियो

अगर डिवाइस में android.content.pm.PackageManager क्लास की मदद से, android.hardware.audio.pro सुविधा के काम करने की जानकारी दी गई है, तो:

• [C-1-1] android.hardware.audio.low_latency सुविधा के लिए सहायता की जानकारी देना ज़रूरी है.
• [C-1-2] ऑडियो के लिए, 5.6 ऑडियो के लिए इंतज़ार का समय सेक्शन में बताए गए, कम से कम एक काम करने वाले पाथ पर, ऑडियो के लिए लगातार राउंड-ट्रिप इंतज़ार का समय 25 मिलीसेकंड या उससे कम होना चाहिए.
• [C-1-3] इसमें यूएसबी होस्ट मोड और यूएसबी डिवाइस मोड के साथ काम करने वाला यूएसबी पोर्ट होना चाहिए.
• [C-1-4] android.software.midi सुविधा के लिए सहायता की जानकारी देना ज़रूरी है.
• [C-1-5] AAudio नेटिव ऑडियो एपीआई और AAUDIO_PERFORMANCE_MODE_LOW_LATENCY का इस्तेमाल करके, इंतज़ार के समय और यूएसबी ऑडियो की ज़रूरी शर्तों को पूरा करना ज़रूरी है.
• [C-1-6] कोल्ड आउटपुट में लगने वाला समय 200 मिलीसेकंड या उससे कम होना चाहिए.
• [C-1-7] कोल्ड इनपुट में लगने वाला समय 200 मिलीसेकंड या उससे कम होना चाहिए.

• [C-1-8] स्पीकर से माइक्रोफ़ोन के डेटा पाथ पर, कम से कम पांच बार मेज़रमेंट करने पर, टैप-टू-टोन के औसत इंतज़ार का समय 80 मिलीसेकंड या उससे कम होना चाहिए.

• [C-SR-1] हमारा सुझाव है कि आप 5.6 ऑडियो लैटेंसी सेक्शन में बताए गए लैटेंसी को पूरा करें. यह लैटेंसी, स्पीकर से माइक्रोफ़ोन तक के पाथ में 20 मिलीसेकंड या इससे कम होनी चाहिए. साथ ही, पांच मेज़रमेंट में, औसत एब्सोल्यूट डिविएशन पांच मिलीसेकंड से कम होना चाहिए.

• [C-SR-2] हमारा सुझाव है कि आप एमएमएपी पाथ पर AAudio नेटिव ऑडियो एपीआई का इस्तेमाल करके, ऑडियो के लगातार राउंड-ट्रिप के इंतज़ार का समय, कोल्ड इनपुट के इंतज़ार का समय, और कोल्ड आउटपुट के इंतज़ार का समय कम करने के लिए, Pro Audio की ज़रूरी शर्तें पूरी करें. साथ ही, यूएसबी ऑडियो की ज़रूरी शर्तें भी पूरी करें.

• [C-SR-3] हमारा सुझाव है कि ऑडियो चालू होने और सीपीयू लोड में बदलाव होने के दौरान, सीपीयू की परफ़ॉर्मेंस को एक जैसा बनाए रखें. इसकी जांच, Android ऐप्लिकेशन SynthMark का इस्तेमाल करके की जानी चाहिए. SynthMark, सिस्टम की परफ़ॉर्मेंस का आकलन करने के लिए, सिम्युलेट किए गए ऑडियो फ़्रेमवर्क पर चलने वाले सॉफ़्टवेयर सिंथेसाइज़र का इस्तेमाल करता है. मानदंडों के बारे में जानने के लिए, SynthMark दस्तावेज़ देखें. SynthMark ऐप्लिकेशन को “ऑटोमेटेड टेस्ट” विकल्प का इस्तेमाल करके चलाया जाना चाहिए. इससे आपको ये नतीजे मिलेंगे:

  • voicemark.90 >= 32 voices
  • latencymark.fixed.little <= 15 msec
  • latencymark.dynamic.little <= 50 msec

• ऑडियो क्लॉक की गड़बड़ी और स्टैंडर्ड टाइम के मुकाबले ड्रिफ़्ट को कम करना चाहिए.

• जब दोनों चालू हों, तो सीपीयू CLOCK_MONOTONIC के मुकाबले ऑडियो क्लॉक ड्रिफ़्ट को कम करना चाहिए.

• डिवाइस पर मौजूद ट्रांसड्यूसर की मदद से, ऑडियो के इंतज़ार का समय कम होना चाहिए.

• यूएसबी डिजिटल ऑडियो पर ऑडियो के इंतज़ार का समय कम होना चाहिए.

• सभी पाथ पर ऑडियो के इंतज़ार का समय मेज़र करना चाहिए.

• ऑडियो बफ़र पूरा होने के कॉलबैक एंट्री के समय में जिटर को कम करना चाहिए, क्योंकि इससे कॉलबैक के ज़रिए सीपीयू की पूरी बैंडविड्थ के इस्तेमाल किए जा सकने वाले प्रतिशत पर असर पड़ता है.

• सामान्य इस्तेमाल के दौरान, रिपोर्ट किए गए इंतज़ार के समय में ऑडियो में कोई गड़बड़ी नहीं होनी चाहिए.

• अलग-अलग चैनलों के बीच इंतज़ार का समय एक जैसा होना चाहिए.

• सभी ट्रांसपोर्ट पर एमआईडीआई के इंतज़ार का औसत समय कम होना चाहिए.

• सभी ट्रांसपोर्ट पर लोड (जटर) के दौरान, एमआईडीआई के इंतज़ार का समय कम से कम होना चाहिए.

• सभी ट्रांसपोर्ट के लिए, सटीक एमआईडीआई टाइमस्टैंप देने चाहिए.

• डिवाइस पर मौजूद ट्रांसड्यूसर पर ऑडियो सिग्नल के शोर को कम करना चाहिए. इसमें कोल्ड स्टार्ट के तुरंत बाद का समय भी शामिल है.

• जब दोनों एंडपॉइंट चालू हों, तो इनके इनपुट और आउटपुट साइड के बीच ऑडियो क्लॉक में कोई अंतर नहीं होना चाहिए. मिलते-जुलते एंड-पॉइंट के उदाहरणों में, डिवाइस पर मौजूद माइक्रोफ़ोन और स्पीकर या ऑडियो जैक इनपुट और आउटपुट शामिल हैं.

• जब दोनों एंड-पॉइंट चालू हों, तब एक ही थ्रेड पर इनपुट और आउटपुट साइड के लिए, ऑडियो बफ़र पूरा होने के कॉलबैक मैनेज करने चाहिए. साथ ही, इनपुट कॉलबैक से वापस आने के तुरंत बाद आउटपुट कॉलबैक में जाना चाहिए. अगर एक ही थ्रेड पर कॉलबैक मैनेज करना मुमकिन नहीं है, तो इनपुट कॉलबैक डालने के कुछ समय बाद आउटपुट कॉलबैक डालें. इससे ऐप्लिकेशन को इनपुट और आउटपुट साइड के लिए एक जैसी समयावधि तय करने में मदद मिलेगी.

• इससे, एंड-पॉइंट के इनपुट और आउटपुट साइड के लिए, एचएएल ऑडियो बफ़रिंग के बीच फ़ेज़ के अंतर को कम किया जा सकता है.

• टच में लगने वाले समय को कम करना चाहिए.

• लोड (जटर) के दौरान, टच रिस्पॉन्स में लगने वाले समय में होने वाले बदलाव को कम करना चाहिए.

अगर डिवाइस में ऊपर दी गई सभी ज़रूरी शर्तें पूरी की जाती हैं, तो:

• [C-SR-4] हमारा सुझाव है कि android.content.pm.PackageManager क्लास की मदद से, android.hardware.audio.pro सुविधा के लिए सहायता पाने का अनुरोध करें.

अगर डिवाइस में चार कंडक्टर वाला 3.5 मि॰मी॰ ऑडियो जैक शामिल है, तो:

• [C-2-1] 5.6 ऑडियो लैटेंसी सेक्शन में बताए गए तरीके के हिसाब से, ऑडियो जैक पाथ पर लगातार होने वाले राउंड-ट्रिप ऑडियो लैटेंसी का औसत 20 मिलीसेकंड या उससे कम होना चाहिए. इसके लिए, ऑडियो लूपबैक डोंगल का इस्तेमाल करके, पांच से ज़्यादा मेज़रमेंट किए जाने चाहिए. साथ ही, इन मेज़रमेंट में ऑडियो जैक पाथ पर होने वाले औसत लैटेंसी में 5 मिलीसेकंड से कम का अंतर होना चाहिए.

• [C-SR-5] हमारा सुझाव है कि आप वायर वाले ऑडियो हेडसेट के लिए स्पेसिफ़िकेशन (v1.1) के मोबाइल डिवाइस (जैक) के स्पेसिफ़िकेशन सेक्शन का पालन करें.

अगर डिवाइस में चार कंडक्टर वाला 3.5 मि॰मी॰ ऑडियो जैक नहीं है और यूएसबी होस्ट मोड के साथ काम करने वाले यूएसबी पोर्ट शामिल हैं, तो:

• [C-3-1] यूएसबी ऑडियो क्लास को लागू करना ज़रूरी है.
• [C-3-2] यूएसबी ऑडियो क्लास का इस्तेमाल करने वाले यूएसबी होस्ट मोड पोर्ट पर, लगातार पांच बार मापने पर, ऑडियो के लिए राउंड-ट्रिप लेटेंसी का औसत 25 मिलीसेकंड या उससे कम होना चाहिए. साथ ही, औसत का एब्सोल्यूट डिविएशन पांच मिलीसेकंड से कम होना चाहिए. (इसे यूएसबी-3.5 मि॰मी॰ अडैप्टर और ऑडियो लूपबैक डोंगल का इस्तेमाल करके मेज़र किया जा सकता है. इसके अलावा, इनपुट को आउटपुट से जोड़ने वाली पैच केबल के साथ यूएसबी ऑडियो इंटरफ़ेस का इस्तेमाल करके भी मेज़र किया जा सकता है).
• [C-SR-6] हमारा सुझाव है कि इनका इस्तेमाल, USB ऑडियो डिवाइसों के साथ किया जाए. इन डिवाइसों में, हर डायरेक्शन में ज़्यादा से ज़्यादा आठ चैनल, 96 किलोहर्ट्ज़ सैंपल रेट, और 24-बिट या 32-बिट डेप्थ के साथ एक साथ I/O की सुविधा होनी चाहिए.
• [C-SR-7] हमारा सुझाव है कि आप एमएमएपी पाथ पर AAudio के नेटिव ऑडियो एपीआई का इस्तेमाल करके, ज़रूरी शर्तों के इस ग्रुप को पूरा करें.

अगर डिवाइस में एचडीएमआई पोर्ट शामिल है, तो:

• कम से कम एक कॉन्फ़िगरेशन में, 20-बिट या 24-बिट डेप्थ और 192 केएचज़ पर, स्टीरियो और आठ चैनलों में आउटपुट की सुविधा होनी चाहिए. साथ ही, बिट-डेप्थ में कोई कमी या फिर रीसैंपलिंग नहीं होनी चाहिए.

5.11. प्रोसेस नहीं हुए डेटा के लिए कैप्चर

Android में, android.media.MediaRecorder.AudioSource.UNPROCESSED ऑडियो सोर्स की मदद से, बिना प्रोसेस किए गए ऑडियो को रिकॉर्ड करने की सुविधा शामिल है. OpenSL ES में, इसे रिकॉर्ड करने के लिए पहले से सेट किए गए पैरामीटर SL_ANDROID_RECORDING_PRESET_UNPROCESSED का इस्तेमाल करके ऐक्सेस किया जा सकता है.

अगर डिवाइस में बिना प्रोसेस किए गए ऑडियो सोर्स का इस्तेमाल करने और उसे तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराने का मकसद है, तो:

• [C-1-1] android.media.AudioManager प्रॉपर्टी PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED के ज़रिए, सहायता की जानकारी देना ज़रूरी है.

• [C-1-2] माइक्रोफ़ोन की परफ़ॉर्मेंस, मध्य फ़्रीक्वेंसी रेंज में, ऐम्प्ल्यट्यूड-बनाम-फ़्रीक्वेंसी के हिसाब से, ज़्यादा-से-ज़्यादा 10 dB तक होनी चाहिए. खास तौर पर, बिना प्रोसेस किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन के लिए, 100 Hz से 7,000 Hz तक की फ़्रीक्वेंसी रेंज में यह 10 dB तक होनी चाहिए.

• [C-1-3] कम फ़्रीक्वेंसी वाली रेंज में, ऐम्प्ल्यट्यूड लेवल दिखाना ज़रूरी है: खास तौर पर, बिना प्रोसेस किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन के लिए, मध्य फ़्रीक्वेंसी रेंज की तुलना में 5 z से 100 Hz तक ±20 dB.

• [C-1-4] यह ज़रूरी है कि अम्प्ल्यट्यूड लेवल, हाई फ़्रीक्वेंसी रेंज में हो: खास तौर पर, बिना प्रोसेस किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन के लिए, मीडियम फ़्रीक्वेंसी रेंज की तुलना में, 7,000 हर्ट्ज़ से 22 केएचज़ तक ±30 डीबी.

• [C-1-5] ऑडियो इनपुट की संवेदनशीलता को इस तरह से सेट करना ज़रूरी है कि 94 dB साउंड प्रेशर लेवल (एसपीएल) पर चलाया गया 1000 Hz साइनसोइडल टोन सोर्स, 16 बिट-सैंपल के लिए 520 आरएमएस (या फ़्लोटिंग पॉइंट/डबल सटीक सैंपल के लिए -36 dB फ़ुल स्केल) का रिस्पॉन्स दे. ऐसा हर उस माइक्रोफ़ोन के लिए करना ज़रूरी है जिसका इस्तेमाल, बिना प्रोसेस किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए किया जाता है.

• [C-1-6] बिना प्रोसेस किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन का सिग्नल-टू-नॉइज़ रेशियो (एसएनआर) 60 dB या उससे ज़्यादा होना चाहिए. (जबकि एसएनआर को 94 dB SPL और सेल्फ़ नॉइज़ के बराबर एसपीएल, A-वज़्ड के बीच के अंतर के तौर पर मेज़र किया जाता है).

• [C-1-7] प्रोसेस न किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन में, 90 dB SPL इनपुट लेवल पर 1 kHz के लिए, कुल हार्मोनिक डिस्टॉर्शन (THD) 1% से कम होना चाहिए.

• [C-1-8] लेवल को सही रेंज में लाने के लिए, पाथ में लेवल मल्टीप्लायर के अलावा कोई अन्य सिग्नल प्रोसेसिंग (जैसे, ऑटोमैटिक गेन कंट्रोल, हाई पास फ़िल्टर या गूंज खत्म करने की सुविधा) नहीं होनी चाहिए. दूसरे शब्दों में:

  • [C-1-9] अगर किसी वजह से आर्किटेक्चर में कोई सिग्नल प्रोसेसिंग मौजूद है, तो उसे बंद करना ज़रूरी है. साथ ही, सिग्नल पाथ में शून्य देरी या अतिरिक्त इंतज़ार का समय शामिल करना चाहिए.
  • [C-1-10] लेवल मल्टीप्लायर को पाथ में शामिल करने की अनुमति है. हालांकि, यह सिग्नल पाथ में देरी या लैटेंसी नहीं ला सकता.

सभी एसपीएल मेज़रमेंट, टेस्ट किए जा रहे माइक्रोफ़ोन के बगल में किए जाते हैं. एक से ज़्यादा माइक्रोफ़ोन कॉन्फ़िगरेशन के लिए, ये ज़रूरी शर्तें हर माइक्रोफ़ोन पर लागू होती हैं.

अगर डिवाइस पर android.hardware.microphone का एलान किया गया है, लेकिन बिना प्रोसेस किए गए ऑडियो सोर्स के साथ काम नहीं करता है, तो:

• [C-2-1] AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) एपीआई तरीके के लिए, null दिखाना ज़रूरी है, ताकि यह साफ़ तौर पर पता चल सके कि यह तरीका काम नहीं करता.
• [C-SR-1] हमारा सुझाव है कि प्रोसेस नहीं किए गए रिकॉर्डिंग सोर्स के सिग्नल पाथ के लिए, ज़्यादा से ज़्यादा ज़रूरी शर्तें पूरी करें.

5.12. एचडीआर वीडियो

Android 13 में एचडीआर टेक्नोलॉजी काम करती हैं. इस बारे में आने वाले समय में एक दस्तावेज़ में बताया जाएगा.

पिक्सल फ़ॉर्मैट

अगर कोई वीडियो डिकोडर, COLOR_FormatYUVP010 के साथ काम करने का दावा करता है, तो:

• [C-1-1] सीपीयू से पढ़ने के लिए, P010 फ़ॉर्मैट के साथ काम करना चाहिए (ImageReader, MediaImage, ByteBuffer). Android 13 में, Y और UV प्लैन के लिए मनमुताबिक स्ट्राइड की अनुमति देने के लिए, P010 को आसान बनाया गया है.

• [C-1-2] GPU_SAMPLING के इस्तेमाल के साथ असाइन किए जाने पर, P010 आउटपुट बफ़र का सैंपलिंग होना ज़रूरी है. इससे ऐप्लिकेशन, जीपीयू कंपज़िशन और कस्टम टोन मैपिंग का इस्तेमाल कर सकते हैं.

अगर कोई वीडियो डिकोडर, COLOR_Format32bitABGR2101010 के साथ काम करने का दावा करता है, तो इसका मतलब है कि:

• [C-2-1] आउटपुट प्लैटफ़ॉर्म के लिए RGBA_1010102 फ़ॉर्मैट और सीपीयू के लिए पढ़ने लायक (ByteBuffer आउटपुट) फ़ॉर्मैट का इस्तेमाल करना ज़रूरी है.

अगर कोई वीडियो एन्कोडर, COLOR_FormatYUVP010 के साथ काम करने का दावा करता है, तो इसका मतलब है कि:

• [C-3-1] इनपुट प्लैटफ़ॉर्म और सीपीयू में लिखे जा सकने वाले (ImageWriter, MediaImage, ByteBuffer) इनपुट के लिए, P010 फ़ॉर्मैट का इस्तेमाल किया जाना चाहिए.

ध्यान दें: Android 13 में, Y और UV प्लेन के लिए मनमुताबिक स्ट्राइड की अनुमति देने के लिए, P010 को आसान बनाया गया है. (यह P010 फ़ॉर्मैट ऑप्टिमाइज़ किया जा सकता है और यह Camera2 P010 फ़ॉर्मैट से अलग हो सकता है.)

अगर कोई वीडियो एन्कोडर, COLOR_Format32bitABGR2101010 के साथ काम करने का दावा करता है, तो इसका मतलब है कि:

• [C-4-1] इनपुट प्लैटफ़ॉर्म और सीपीयू में लिखे जा सकने वाले (ImageWriter, ByteBuffer) इनपुट के लिए, RGBA_1010102 फ़ॉर्मैट का इस्तेमाल करना ज़रूरी है. ध्यान दें: एन्कोडर के लिए, अलग-अलग ट्रांसफ़र कर्व के बीच बदलाव करना ज़रूरी नहीं है.

एचडीआर कैप्चर करने से जुड़ी ज़रूरी शर्तें

एचडीआर प्रोफ़ाइल और डिवाइस पर लागू होने वाली सुविधाओं के साथ काम करने वाले सभी वीडियो एन्कोडर के लिए:

• [C-5-1] यह नहीं मानना चाहिए कि HDR मेटाडेटा सटीक है. उदाहरण के लिए, एन्कोड किए गए फ़्रेम में, चमक के पीक लेवल से ज़्यादा पिक्सल हो सकते हैं या हो सकता है कि हिस्टोग्राम, फ़्रेम को सही तरीके से न दिखा रहा हो.

• एन्कोड की गई स्ट्रीम के लिए सही एचडीआर स्टैटिक मेटाडेटा जनरेट करने के लिए, एचडीआर डाइनैमिक मेटाडेटा को इकट्ठा करना चाहिए. साथ ही, उन्हें हर एन्कोडिंग सेशन के आखिर में इसे आउटपुट करना चाहिए.

अगर डिवाइस पर CamcorderProfile API का इस्तेमाल करके एचडीआर कैप्चर की सुविधा काम करती है, तो:

• [C-6-1] यह ज़रूरी है कि Camera2 API की मदद से भी एचडीआर कैप्चर की सुविधा काम करे.

• [C-6-2] यह ज़रूरी है कि एचडीआर क्वालिटी के साथ काम करने वाली हर टेक्नोलॉजी के लिए, कम से कम एक हार्डवेयर-ऐक्सेलेरेटेड वीडियो एन्कोडर काम करता हो.

• [C-6-3] यह कम से कम एचएलजी कैप्चर को सपोर्ट करना चाहिए.

• [C-6-4] कैप्चर की गई वीडियो फ़ाइल में एचडीआर मेटाडेटा (अगर एचडीआर टेक्नोलॉजी पर लागू हो) को लिखने की सुविधा होनी चाहिए. AV1, HEVC, और DolbyVision के लिए, इसका मतलब है कि एन्कोड किए गए बिटस्ट्रीम में मेटाडेटा शामिल करना.

• [C-6-5] P010 और COLOR_FormatYUVP010 के साथ काम करना चाहिए.

• [C-6-6] कैप्चर की गई प्रोफ़ाइल के लिए, डिफ़ॉल्ट रूप से हार्डवेयर से तेज़ किए गए डिकोडर में, एचडीआर से एसडीआर टोन मैपिंग की सुविधा होनी चाहिए. दूसरे शब्दों में, अगर कोई डिवाइस HDR10+ HEVC कैप्चर कर सकता है, तो डिफ़ॉल्ट HEVC डिकोडर को कैप्चर की गई स्ट्रीम को एसडीआर में डिकोड करना चाहिए.

एचडीआर वीडियो में बदलाव करने से जुड़ी ज़रूरी शर्तें

अगर डिवाइस में एचडीआर एडिटिंग की सुविधा वाले वीडियो एन्कोडर शामिल हैं, तो:

• एचडीआर मेटाडेटा मौजूद न होने पर, कम से कम इंतज़ार का समय इस्तेमाल करना चाहिए. साथ ही, उन स्थितियों को आसानी से मैनेज करना चाहिए जहां मेटाडेटा कुछ फ़्रेम के लिए मौजूद है और कुछ के लिए नहीं. यह मेटाडेटा सटीक होना चाहिए. उदाहरण के लिए, फ़्रेम के असल पीक ल्यूमिनेंस और हिस्टोग्राम को दिखाना.

अगर डिवाइस में FEATURE_HdrEditing के साथ काम करने वाले कोडेक शामिल हैं, तो वे कोडेक:

• [C-7-1] यह कम से कम एक एचडीआर प्रोफ़ाइल के साथ काम करना चाहिए.

• [C-7-2] कोडेक के विज्ञापन में बताई गई सभी एचडीआर प्रोफ़ाइलों के लिए, FEATURE_HdrEditing के साथ काम करना ज़रूरी है. दूसरे शब्दों में, अगर एचडीआर मेटाडेटा का इस्तेमाल करने वाली सभी एचडीआर प्रोफ़ाइलों के लिए, एचडीआर मेटाडेटा मौजूद नहीं है, तो उसे जनरेट करने की सुविधा होनी चाहिए.

• [C-7-3] वीडियो एन्कोडर के इन इनपुट फ़ॉर्मैट के साथ काम करना चाहिए, ताकि एचडीआर वीडियो को डिकोड करने के बाद, उसके सिग्नल को पूरी तरह से सुरक्षित रखा जा सके:

  • इनपुट स्क्रीन और ByteBuffer, दोनों के लिए RGBA_1010102 (पहले से ही टारगेट ट्रांसफ़र कर्व में है). साथ ही, COLOR_Format32bitABGR2101010 के साथ काम करने की जानकारी देना ज़रूरी है.

अगर डिवाइस में ऐसे कोडेक शामिल हैं जो FEATURE_HdrEditing के साथ काम करते हैं, तो डिवाइस:

• [C-7-4] EXT_YUV_target OpenGL एक्सटेंशन के साथ काम करने की जानकारी देना ज़रूरी है.

6. डेवलपर टूल और विकल्पों के साथ काम करने की सुविधा

6.1. डेवलपर टूल

डिवाइस पर लागू करने के तरीके:

• [C-0-1] यह ज़रूरी है कि यह Android SDK में दिए गए Android डेवलपर टूल के साथ काम करे.

• Android डीबग ब्रिज (adb)

  • [C-0-2] यह ज़रूरी है कि यह Android SDK टूल और AOSP में दिए गए शेल कमांड के साथ काम करे. इनका इस्तेमाल ऐप्लिकेशन डेवलपर कर सकते हैं. इनमें dumpsys cmd stats भी शामिल है
  • [C-0-11] यह ज़रूरी है कि शेल कमांड cmd testharness काम करे. डिवाइस पर पहले से मौजूद Android वर्शन को, बिना किसी डेटा ब्लॉक के नए वर्शन पर अपग्रेड करने पर, C-0-11 से छूट मिल सकती है.
  • [C-0-3] डिवाइस के सिस्टम इवेंट (batterystats , diskstats, fingerprint, graphicsstats, netstats, notification, procstats) के फ़ॉर्मैट या कॉन्टेंट में बदलाव नहीं किया जाना चाहिए. ये इवेंट, dumpsys कमांड की मदद से लॉग किए जाते हैं.
  • [C-0-10] इन इवेंट को रिकॉर्ड करना ज़रूरी है. साथ ही, इन्हें cmd stats शेल कमांड और StatsManager सिस्टम एपीआई क्लास के लिए ऐक्सेस और उपलब्ध कराना ज़रूरी है.
    • ActivityForegroundStateChanged
    • AnomalyDetected
    • AppBreadcrumbReported
    • AppCrashOccurred
    • AppStartOccurred
    • BatteryLevelChanged
    • BatterySaverModeStateChanged
    • BleScanResultReceived
    • BleScanStateChanged
    • ChargingStateChanged
    • DeviceIdleModeStateChanged
    • ForegroundServiceStateChanged
    • GpsScanStateChanged
    • JobStateChanged
    • PluggedStateChanged
    • ScheduledJobStateChanged
    • ScreenStateChanged
    • SyncStateChanged
    • SystemElapsedRealtime
    • UidProcessStateChanged
    • WakelockStateChanged
    • WakeupAlarmOccurred
    • WifiLockStateChanged
    • WifiMulticastLockStateChanged
    • WifiScanStateChanged
  • [C-0-4] डिवाइस पर adb डेमन, डिफ़ॉल्ट रूप से बंद होना चाहिए. साथ ही, Android Debug Bridge को चालू करने के लिए, उपयोगकर्ता के पास कोई ऐसा तरीका होना चाहिए जिसका इस्तेमाल किया जा सके.
  • [C-0-5] यह ज़रूरी है कि यह सुरक्षित adb के साथ काम करे. Android में सुरक्षितADB की सुविधा शामिल है. Secure adb, पुष्टि किए गए होस्ट पर adb को चालू करता है.
  • [C-0-6] होस्ट मशीन से adb को कनेक्ट करने की सुविधा देनी ज़रूरी है. खास तौर से:

  अगर यूएसबी पोर्ट के बिना डिवाइसों को लागू करने की सुविधा, सहायक डिवाइस मोड के साथ काम करती है, तो:

  • [C-3-1] लोकल-एरिया नेटवर्क (जैसे, ईथरनेट या वाई-फ़ाई) के ज़रिए adb को लागू करना ज़रूरी है.
  • [C-3-2] Windows 7, 8, और 10 के लिए ड्राइवर उपलब्ध कराना ज़रूरी है, ताकि डेवलपर adb प्रोटोकॉल का इस्तेमाल करके डिवाइस से कनेक्ट कर सकें.

  अगर डिवाइस में वाई-फ़ाई या ईथरनेट के ज़रिए होस्ट मशीन से adb कनेक्शन बनाने की सुविधा है, तो:

  • [C-4-1] AdbManager#isAdbWifiSupported() का तरीका, true को दिखाना चाहिए.

  अगर डिवाइस में वाई-फ़ाई या ईथरनेट के ज़रिए होस्ट मशीन से adb कनेक्शन की सुविधा काम करती है और उसमें कम से कम एक कैमरा है, तो:

  • [C-5-1] AdbManager#isAdbWifiQrSupported() का तरीका, true को ज़रूर दिखाना चाहिए.

• Dalvik डीबग मॉनिटर सेवा (ddms)

  • [C-0-7] Android SDK टूल में बताई गई सभी ddms सुविधाओं के साथ काम करना चाहिए. ddms, adb का इस्तेमाल करता है. इसलिए, ddms के लिए सहायता डिफ़ॉल्ट रूप से बंद होनी चाहिए. हालांकि, जब भी उपयोगकर्ता ने ऊपर बताए गए तरीके से Android Debug Bridge चालू किया हो, तब ddms के लिए सहायता चालू होनी चाहिए.

• SysTrace

  • [C-0-9] Android SDK में बताए गए तरीके से, systrace टूल के साथ काम करना चाहिए. Systrace की सुविधा डिफ़ॉल्ट रूप से बंद होनी चाहिए. साथ ही, Systrace को चालू करने के लिए, उपयोगकर्ता के पास कोई ऐसा तरीका होना चाहिए जिसका इस्तेमाल किया जा सके.

• Perfetto

  • [C-SR-1] हमारा सुझाव है कि शेल उपयोगकर्ता को /system/bin/perfetto बाइनरी उपलब्ध कराएं, जिसका cmdline, perfetto दस्तावेज़ के मुताबिक हो.
  • [C-SR-2] हमारा सुझाव है कि आप perfetto दस्तावेज़ में बताए गए स्कीमा के मुताबिक, protobuf कॉन्फ़िगरेशन को इनपुट के तौर पर स्वीकार करने के लिए, perfetto बाइनरी का इस्तेमाल करें.
  • [C-SR-3] हमारा सुझाव है कि आप perfetto दस्तावेज़ में बताए गए स्कीमा के मुताबिक, protobuf ट्रैक को आउटपुट के तौर पर लिखें.
  • [C-SR-4] हमारा सुझाव है कि आप perfetto दस्तावेज़ में बताए गए डेटा सोर्स के साथ-साथ, कम से कम perfetto बाइनरी भी उपलब्ध कराएं.

• Low Memory Killer

  • [C-0-12] जब किसी ऐप्लिकेशन को कम मेमोरी किलर की वजह से बंद किया जाता है, तो LMK_KILL_OCCURRED_FIELD_NUMBER ऐटम को statsd लॉग में लिखना ज़रूरी है.

• टेस्ट हार्नेस मोड अगर डिवाइस पर, शेल कमांड cmd testharness और cmd testharness enable काम करते हैं, तो:

  • [C-2-1] ActivityManager.isRunningInUserTestHarness() के लिए true दिखाना ज़रूरी है
  • [C-2-2] टेस्ट हार्नेस मोड के दस्तावेज़ में बताए गए तरीके के मुताबिक, टेस्ट हार्नेस मोड को लागू करना ज़रूरी है.

• जीपीयू के काम करने की जानकारी

  डिवाइस पर लागू करने के तरीके:

  • [C-0-13] power/gpu_work_period कर्नेल ट्रैसपॉइंट से मिले, इकट्ठा किए गए GPU के काम के डेटा को दिखाने के लिए, शेल कमांड dumpsys gpu --gpuwork को लागू करना ज़रूरी है. अगर ट्रैसपॉइंट काम नहीं करता है, तो कोई डेटा न दिखाएं. AOSP का लागू किया गया वर्शन frameworks/native/services/gpuservice/gpuwork/ है.

अगर डिवाइस में android.hardware.vulkan.version सुविधा फ़्लैग की मदद से, Vulkan 1.0 या इसके बाद के वर्शन के साथ काम करने की सुविधा मौजूद है, तो:

• [C-1-1] ऐप्लिकेशन डेवलपर को जीपीयू डीबग लेयर को चालू/बंद करने की सुविधा देनी ज़रूरी है.
• [C-1-2] GPU डीबग लेयर चालू होने पर, vkEnumerateInstanceLayerProperties() और vkCreateInstance() एपीआई तरीकों के साथ काम करने के लिए, डीबग किए जा सकने वाले ऐप्लिकेशन की बेस डायरेक्ट्री में, बाहरी टूल (यानी प्लैटफ़ॉर्म या ऐप्लिकेशन पैकेज का हिस्सा नहीं) से मिलने वाली लाइब्रेरी में लेयर की गिनती करना ज़रूरी है.

6.2. डेवलपर के लिए सेटिंग और टूल

Android में डेवलपर के लिए, ऐप्लिकेशन के डेवलपमेंट से जुड़ी सेटिंग कॉन्फ़िगर करने की सुविधा शामिल है.

डिवाइस में लागू किए गए 'डेवलपर के विकल्प', एक जैसा अनुभव देने चाहिए. इसके लिए, ये ज़रूरी हैं:

• [C-0-1] ऐप्लिकेशन डेवलपमेंट से जुड़ी सेटिंग दिखाने के लिए, android.settings.APPLICATION_DEVELOPMENT_SETTINGS इंटेंट का पालन करना ज़रूरी है. Android के अपस्ट्रीम वर्शन में, डिफ़ॉल्ट रूप से डेवलपर के विकल्प मेन्यू को छिपा दिया जाता है. साथ ही, उपयोगकर्ताओं को सेटिंग > डिवाइस के बारे में जानकारी > बिल्ड नंबर मेन्यू आइटम पर सात (7) बार दबाने के बाद, डेवलपर के विकल्प लॉन्च करने की सुविधा मिलती है.
• [C-0-2] ऐप्लिकेशन में, 'डेवलपर के लिए सेटिंग और टूल' को डिफ़ॉल्ट रूप से छिपाना ज़रूरी है.
• [C-0-3] डेवलपर के विकल्पों को चालू करने के लिए, ऐसा सटीक तरीका दिया जाना चाहिए जिससे तीसरे पक्ष के किसी एक ऐप्लिकेशन को दूसरे ऐप्लिकेशन के मुकाबले प्राथमिकता न दी जाए. सार्वजनिक तौर पर दिखने वाला ऐसा दस्तावेज़ या वेबसाइट देना ज़रूरी है जिसमें डेवलपर के विकल्प चालू करने का तरीका बताया गया हो. यह दस्तावेज़ या वेबसाइट, Android SDK टूल के दस्तावेज़ों से लिंक की जानी चाहिए.
• जब डेवलपर के विकल्प चालू हों और उपयोगकर्ता की सुरक्षा को लेकर चिंता हो, तो उपयोगकर्ता को विज़ुअल सूचना दिखनी चाहिए.
• उपयोगकर्ता की सुरक्षा को ध्यान में रखते हुए, कुछ समय के लिए डेवलपर के विकल्प मेन्यू के ऐक्सेस पर पाबंदी लगाई जा सकती है. इसके लिए, मेन्यू को छिपाया या बंद किया जा सकता है.

7. हार्डवेयर के साथ काम करना

अगर किसी डिवाइस में कोई ऐसा हार्डवेयर कॉम्पोनेंट शामिल है जिसके लिए तीसरे पक्ष के डेवलपर के पास एपीआई है, तो:

• [C-0-1] डिवाइस में लागू किए गए एपीआई को, Android SDK के दस्तावेज़ में बताए गए तरीके से लागू करना ज़रूरी है.

अगर SDK टूल में मौजूद कोई एपीआई, ऐसे हार्डवेयर कॉम्पोनेंट के साथ इंटरैक्ट करता है जिसे ज़रूरी नहीं बताया गया है और डिवाइस में वह कॉम्पोनेंट मौजूद नहीं है, तो:

• [C-0-2] कॉम्पोनेंट एपीआई के लिए, अब भी पूरी क्लास की परिभाषाएं (SDK टूल के दस्तावेज़ के मुताबिक) ज़रूर दी जानी चाहिए.
• [C-0-3] एपीआई के व्यवहार को किसी सही तरीके से, नो-ऑप के तौर पर लागू करना ज़रूरी है.
• [C-0-4] SDK दस्तावेज़ में अनुमति होने पर, एपीआई के तरीके को शून्य वैल्यू दिखानी चाहिए.
• [C-0-5] एपीआई के तरीके, उन क्लास के लिए कोई कार्रवाई नहीं करने वाले लागू होने चाहिए जहां SDK टूल के दस्तावेज़ में, शून्य वैल्यू की अनुमति नहीं है.
• [C-0-6] एपीआई के तरीकों से ऐसे अपवाद नहीं होने चाहिए जिनके बारे में SDK टूल के दस्तावेज़ में नहीं बताया गया है.
• [C-0-7] डिवाइस के लागू होने पर, एक ही बिल्ड फ़िंगरप्रिंट के लिए, android.content.pm.PackageManager क्लास पर getSystemAvailableFeatures() और hasSystemFeature(String) तरीकों से, हार्डवेयर कॉन्फ़िगरेशन की सटीक जानकारी लगातार रिपोर्ट की जानी चाहिए.

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

7.1. डिसप्ले और ग्राफ़िक

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

नई ज़रूरी शर्तें लागू करना

डिवाइस पर लागू करने के तरीके:

• [C-0-1] डिफ़ॉल्ट रूप से, तीसरे पक्ष के ऐप्लिकेशन सिर्फ़ Android के साथ काम करने वाले डिसप्ले पर रेंडर होने चाहिए.

नई ज़रूरी शर्तें खत्म करना

इस सेक्शन में दी गई ज़रूरी शर्तों में बताई गई इकाइयों की परिभाषा इस तरह दी गई है:

• डायगनल साइज़. डिसप्ले के रोशन हिस्से के दो विपरीत कोनों के बीच की दूरी, इंच में.
• डॉट्स पर इंच (डीपीआई)डेंसिटी. एक इंच के लीनियर वर्टिकल या हॉरिज़ॉन्टल स्पैन में मौजूद पिक्सल की संख्या. इसे पिक्सल प्रति इंच (पीपीआई या डीपीआई) के तौर पर दिखाया जाता है. जहां dpi और ppi और dpi वैल्यू दी गई हैं वहां हॉरिज़ॉन्टल और वर्टिकल, दोनों dpi वैल्यू दी गई सीमा के अंदर होनी चाहिए.
• आसपेक्ट रेशियो. स्क्रीन के लंबे डाइमेंशन के पिक्सल का स्क्रीन के छोटे डाइमेंशन के पिक्सल से अनुपात. उदाहरण के लिए, 480x854 पिक्सल के डिसप्ले का अनुपात 854/480 = 1.779 या करीब-करीब “16:9” होगा.
• डेंसिटी-इंडिपेंडेंट पिक्सल (डीपी). A वर्चुअल पिक्सल यूनिट, 160 डीपीआई स्क्रीन के लिए स्क्रीन डेंसिटी 160 के हिसाब से तय की गई है. किसी डेंसिटी d और पिक्सल की संख्या p के लिए, डेंसिटी-इंडिपेंडेंट पिक्सल (dp) की संख्या का हिसाब इस तरह लगाया जाता है: पिक्सल = डीपीएस * (डेंसिटी/160) डीपी = (160 / d) * p .

7.1.1. स्क्रीन कॉन्फ़िगरेशन

7.1.1.1. स्क्रीन का साइज़ और आकार

Android यूज़र इंटरफ़ेस (यूआई) फ़्रेमवर्क, अलग-अलग लॉजिकल स्क्रीन लेआउट साइज़ के साथ काम करता है. साथ ही, ऐप्लिकेशन को SCREENLAYOUT_SIZE_MASK और Configuration.smallestScreenWidthDp के साथ Configuration.screenLayout के ज़रिए, मौजूदा कॉन्फ़िगरेशन के स्क्रीन लेआउट साइज़ के बारे में क्वेरी करने की अनुमति देता है.

डिवाइस पर लागू करने के तरीके:

• [C-0-1] Android SDK टूल के दस्तावेज़ में बताए गए तरीके के मुताबिक, Configuration.screenLayout के लिए सही लेआउट साइज़ की जानकारी देना ज़रूरी है. खास तौर पर, डिवाइस के लागू होने पर, डेंसिटी-इंडिपेंडेंट पिक्सल (डीपी) के हिसाब से स्क्रीन के डाइमेंशन सही होने चाहिए. इन डाइमेंशन की जानकारी यहां दी गई है:

  • जिन डिवाइसों पर Configuration.uiMode को UI_MODE_TYPE_WATCH के अलावा किसी और वैल्यू पर सेट किया गया है और Configuration.screenLayout के लिए small साइज़ की जानकारी दी गई है उनके लिए, डिवाइस का डाइमेंशन कम से कम 426 dp x 320 dp होना चाहिए.
  • जिन डिवाइसों के लिए Configuration.screenLayout का साइज़ normal बताया गया है उनके लिए, कम से कम 480 डीपी x 320 डीपी का साइज़ ज़रूरी है.
  • Configuration.screenLayout के लिए large साइज़ की जानकारी देने वाले डिवाइसों का स्क्रीन साइज़, कम से कम 640 dp x 480 dp होना चाहिए.
  • Configuration.screenLayout के लिए xlarge साइज़ की जानकारी देने वाले डिवाइसों का डाइमेंशन, कम से कम 960 dp x 720 dp होना चाहिए.

• [C-0-2] Android SDK के दस्तावेज़ में बताए गए तरीके के मुताबिक, AndroidManifest.xml में <supports-screens> एट्रिब्यूट की मदद से, ऐप्लिकेशन के लिए बताई गई स्क्रीन साइज़ के साथ सही तरीके से काम करना चाहिए.

• इसमें Android के साथ काम करने वाले ऐसे डिसप्ले हो सकते हैं जिनके कोने गोल हों.

अगर डिवाइस में UI_MODE_TYPE_NORMAL साइज़ कॉन्फ़िगरेशन के साथ काम करने वाली स्क्रीन और Android के साथ काम करने वाले डिवाइस शामिल हैं, तो इन स्क्रीन को रेंडर करने के लिए, राउंड किए गए कोनों वाले डिसप्ले का इस्तेमाल किया जाता है.

• [C-1-1] यह पक्का करना ज़रूरी है कि हर ऐसे डिसप्ले के लिए, इनमें से कम से कम एक ज़रूरी शर्त पूरी की गई हो:

  • गोल किए गए कोनों की त्रिज्या 38 डीपी से कम या उसके बराबर हो.
  • जब लॉजिकल डिसप्ले के हर कोने में 1518 डीपी का 1518 डीपी बॉक्स ऐंकर किया जाता है, तो स्क्रीन पर हर बॉक्स का कम से कम एक पिक्सल दिखता है.

• इसमें उपयोगकर्ता के लिए, रेक्टैंगल कोनों वाले डिसप्ले मोड पर स्विच करने की सुविधा शामिल होनी चाहिए.

नई ज़रूरी शर्तें लागू करना

अगर डिवाइस में सिर्फ़ NO_KEYS कीबोर्ड कॉन्फ़िगरेशन की सुविधा काम करती है और UI_MODE_TYPE_NORMAL यूज़र इंटरफ़ेस (यूआई) मोड कॉन्फ़िगरेशन के साथ काम करने की सुविधा की जानकारी देनी है, तो:

• [C-4-1] डिसप्ले के किसी भी कटी हुई जगह को छोड़कर, लेआउट का साइज़ कम से कम 596 dp x 384 dp या इससे ज़्यादा होना चाहिए.

नई ज़रूरी शर्तें खत्म करना

अगर डिवाइस में Android के साथ काम करने वाला ऐसा डिसप्ले शामिल है जो फ़ोल्ड किया जा सकता है या एक से ज़्यादा डिसप्ले पैनल के बीच फ़ोल्डिंग हिंज है और तीसरे पक्ष के ऐप्लिकेशन को रेंडर करने के लिए ऐसा डिसप्ले उपलब्ध कराया जाता है, तो:

• [C-2-1] Window Manager Jetpack लाइब्रेरी का इस्तेमाल करने के लिए, extensions API का सबसे नया वर्शन या sidecar API का स्टैबल वर्शन लागू करना ज़रूरी है.

अगर डिवाइस में Android के साथ काम करने वाला ऐसा डिसप्ले शामिल है जो फ़ोल्ड किया जा सकता है या एक से ज़्यादा डिसप्ले पैनल के बीच फ़ोल्डिंग हिंज है और अगर हिंज या फ़ोल्ड, फ़ुलस्क्रीन ऐप्लिकेशन विंडो को पार करता है, तो:

• [C-3-1] ऐप्लिकेशन में, एक्सटेंशन या साइडकार एपीआई के ज़रिए, हिंज या फ़ोल्ड की स्थिति, सीमाएं, और स्थिति की जानकारी देना ज़रूरी है.

साइडकार या एक्सटेंशन एपीआई को सही तरीके से लागू करने के बारे में जानने के लिए, Window Manager Jetpack के सार्वजनिक दस्तावेज़ देखें.

नई ज़रूरी शर्तें लागू करना

अगर डिवाइस में, Android के साथ काम करने वाले एक या एक से ज़्यादा फ़ोल्ड किए जा सकने वाले डिसप्ले पैनल शामिल हैं या Android के साथ काम करने वाले एक से ज़्यादा डिसप्ले पैनल के बीच फ़ोल्डिंग हिंज शामिल है और ऐसे डिसप्ले पैनल ऐप्लिकेशन के लिए उपलब्ध हैं, तो:

• [C-4-1] WindowManager एक्सटेंशन में बताए गए एपीआई लेवल के हिसाब से, Window Manager एक्सटेंशन का सही वर्शन लागू करना ज़रूरी है.

नई ज़रूरी शर्तें खत्म करना

7.1.1.2. स्क्रीन का आसपेक्ट रेशियो

Android के साथ काम करने वाले डिसप्ले के लिए, फ़िज़िकल डिसप्ले के आसपेक्ट रेशियो पर कोई पाबंदी नहीं है. हालांकि, तीसरे पक्ष के ऐप्लिकेशन रेंडर किए जाने वाले लॉजिकल डिसप्ले के आसपेक्ट रेशियो को इन ज़रूरी शर्तों को पूरा करना होगा. इस आसपेक्ट रेशियो को view.Display एपीआई और कॉन्फ़िगरेशन एपीआई के ज़रिए दी गई ऊंचाई और चौड़ाई की वैल्यू से पता लगाया जा सकता है:

• [C-0-1] Configuration.uiMode को UI_MODE_TYPE_NORMAL पर सेट करने वाले डिवाइस के लिए, आसपेक्ट रेशियो की वैल्यू 1.86 (लगभग 16:9) से कम या उसके बराबर होनी चाहिए. ऐसा तब तक ज़रूरी है, जब तक ऐप्लिकेशन इनमें से किसी एक शर्त को पूरा न करता हो:

  • ऐप्लिकेशन ने android.max_aspect मेटाडेटा वैल्यू के ज़रिए, यह एलान किया है कि यह बड़ी स्क्रीन के आसपेक्ट रेशियो के साथ काम करता है.
  • ऐप्लिकेशन, android:resizeableActivity एट्रिब्यूट की मदद से यह एलान करता है कि उसका साइज़ बदला जा सकता है.
  • ऐप्लिकेशन, एपीआई लेवल 24 या उसके बाद के वर्शन को टारगेट करता हो और उसमें ऐसा android:maxAspectRatio न दिया गया हो जिससे ऐस्पेक्ट रेशियो पर पाबंदी लगे.

• [C-0-3] Configuration.uiMode को UI_MODE_TYPE_WATCH के तौर पर सेट करने वाले डिवाइसों के लिए, आसपेक्ट रेशियो की वैल्यू 1.0 (1:1) पर सेट होनी चाहिए.

7.1.1.3. स्क्रीन की सघनता

Android यूज़र इंटरफ़ेस (यूआई) फ़्रेमवर्क, स्टैंडर्ड लॉजिकल डेंसिटी का एक सेट तय करता है. इससे ऐप्लिकेशन डेवलपर को ऐप्लिकेशन के संसाधनों को टारगेट करने में मदद मिलती है.

डिवाइस पर लागू करना:

• [C-0-1] डिफ़ॉल्ट रूप से, डिवाइस पर लागू किए गए ऐप्लिकेशन को सिर्फ़ उनमें से किसी एक Android फ़्रेमवर्क डेंसिटी की जानकारी देनी चाहिए जो DENSITY_DEVICE_STABLE एपीआई के ज़रिए DisplayMetrics पर दी गई हैं. साथ ही, यह वैल्यू हर फ़िज़िकल डिसप्ले के लिए स्टैटिक वैल्यू होनी चाहिए. किसी भी समय नहीं बदलना चाहिए; हालांकि, हालांकि डिवाइस, डिसप्ले कॉन्फ़िगरेशन में उपयोगकर्ता के किए गए बदलावों (उदाहरण के लिए, डिसप्ले का साइज़) के आधार पर, किसी भी डिसप्ले डेंसिटी के बारे में बता सकता है. ये बदलाव, डिवाइस के शुरू में बूट होने के बाद सेट किए जाते हैं.DisplayMetrics.density

• डिवाइस पर लागू होने वाले Android फ़्रेमवर्क की डेंसिटी, डिवाइस की स्क्रीन की डेंसिटी के हिसाब से तय की जानी चाहिए. हालांकि, ऐसा तब तक नहीं किया जाना चाहिए, जब तक कि तय की गई डेंसिटी की वजह से, स्क्रीन का साइज़, काम करने वाले सबसे छोटे साइज़ से कम न हो जाए. अगर डिवाइस पर काम करने वाली सबसे छोटी स्क्रीन साइज़ (320 dp चौड़ाई) से भी छोटी स्क्रीन साइज़, डिवाइस पर काम करने वाली सबसे छोटी स्क्रीन साइज़ के करीब है, तो डिवाइस पर काम करने वाले स्टैंडर्ड Android फ़्रेमवर्क की डेंसिटी, डिवाइस पर काम करने वाली सबसे छोटी स्क्रीन साइज़ से थोड़ी कम होनी चाहिए.

नई ज़रूरी शर्तें लागू करना

• इस एट्रिब्यूट की वैल्यू, Android फ़्रेमवर्क की स्टैंडर्ड डेंसिटी होनी चाहिए, जो संख्या के हिसाब से स्क्रीन की डेंसिटी के सबसे करीब हो. इसके अलावा, यह वैल्यू किसी हैंडहेल्ड डिवाइस के ऐंगल फ़ील्ड-ऑफ़-व्यू के मेज़रमेंट के बराबर होनी चाहिए.

नई ज़रूरी शर्तों को खत्म करना

अगर डिवाइस पर लागू किए गए ऐप्लिकेशन में, डिवाइस के डिसप्ले साइज़ को बदलने का विकल्प दिया गया है, तो ऐप्लिकेशन:

• [C-1-1] डिसप्ले का साइज़, DENSITY_DEVICE_STABLE नेटिव डेंसिटी के 1.5 गुने से ज़्यादा नहीं होना चाहिए या स्क्रीन का कम से कम असरदार डाइमेंशन 320dp (रिसॉर्स क्वालीफ़ायर sw320dp के बराबर) से कम नहीं होना चाहिए.
• [C-1-2] डिसप्ले के साइज़ को किसी भी तरह से स्केल नहीं किया जाना चाहिए. साथ ही, DENSITY_DEVICE_STABLE नेटिव डेंसिटी के 0.85 गुने से कम पर डिसप्ले को स्केल नहीं किया जाना चाहिए.
• बेहतर इस्तेमाल और फ़ॉन्ट के साइज़ में एक जैसी जानकारी देने के लिए, हमारा सुझाव है कि नेटिव डिसप्ले विकल्पों के लिए, ऊपर बताई गई सीमाओं का पालन करते हुए, यहां बताई गई स्केलिंग का इस्तेमाल करें
  • छोटा: 0.85x
  • डिफ़ॉल्ट: 1x (नेटिव डिसप्ले स्केल)
  • बड़ा: 1.15x
  • बड़ा: 1.3x
  • सबसे बड़ा 1.45x

7.1.2. डिसप्ले मेट्रिक

अगर डिवाइस में Android के साथ काम करने वाले डिसप्ले या Android के साथ काम करने वाली डिसप्ले स्क्रीन पर वीडियो आउटपुट शामिल है, तो:

• [C-1-1] android.util.DisplayMetrics API में बताई गई, Android डिवाइसों के साथ काम करने वाली सभी डिसप्ले मेट्रिक के लिए, सही वैल्यू रिपोर्ट करना ज़रूरी है.

अगर डिवाइस में एम्बेड की गई स्क्रीन या वीडियो आउटपुट शामिल नहीं है, तो:

• [C-2-1] एमुलेट किए गए डिफ़ॉल्ट view.Display के लिए, android.util.DisplayMetrics एपीआई में बताई गई, Android के साथ काम करने वाले डिसप्ले की सही वैल्यू दिखानी चाहिए.

7.1.3. स्क्रीन अभिविन्यास

डिवाइस पर लागू करने के तरीके:

• [C-0-1] यह बताना ज़रूरी है कि ऐप्लिकेशन किन स्क्रीन ओरिएंटेशन (android.hardware.screen.portrait और/या android.hardware.screen.landscape) के साथ काम करता है. साथ ही, यह भी बताना ज़रूरी है कि ऐप्लिकेशन कम से कम एक ओरिएंटेशन के साथ काम करता है. उदाहरण के लिए, टेलिविज़न या लैपटॉप जैसे ऐसे डिवाइसों के लिए, सिर्फ़ android.hardware.screen.landscape को रिपोर्ट किया जाना चाहिए जिनकी स्क्रीन का ओरिएंटेशन लैंडस्केप में फ़िक्स होता है.
• [C-0-2] जब भी android.content.res.Configuration.orientation, android.view.Display.getOrientation() या अन्य एपीआई के ज़रिए डिवाइस के मौजूदा ओरिएंटेशन के बारे में क्वेरी की जाती है, तो डिवाइस के ओरिएंटेशन की सही वैल्यू दिखानी चाहिए.

अगर डिवाइस पर स्क्रीन के दोनों ओरिएंटेशन काम करते हैं, तो:

• [C-1-1] ऐप्लिकेशन को पोर्ट्रेट या लैंडस्केप स्क्रीन ओरिएंटेशन में, डाइनैमिक ओरिएंटेशन की सुविधा देनी चाहिए. इसका मतलब है कि डिवाइस को किसी खास स्क्रीन ओरिएंटेशन के लिए, ऐप्लिकेशन के अनुरोध का पालन करना होगा.
• [C-1-2] ओरिएंटेशन बदलते समय, स्क्रीन का रिपोर्ट किया गया साइज़ या डेंसिटी नहीं बदलनी चाहिए.
• डिफ़ॉल्ट रूप से, पोर्ट्रेट या लैंडस्केप ओरिएंटेशन में से किसी एक को चुना जा सकता है.

7.1.4. 2D और 3D ग्राफ़िक एक्सेलरेशन

7.1.4.1 OpenGL ES

डिवाइस पर लागू करने के तरीके:

• [C-0-1] मैनेज किए जा रहे एपीआई (जैसे, GLES10.getString() तरीके से) और नेटिव एपीआई के ज़रिए, काम करने वाले OpenGL ES वर्शन (1.1, 2.0, 3.0, 3.1, 3.2) की सही पहचान करनी चाहिए.
• [C-0-2] इसमें, उन सभी मैनेज किए जा रहे एपीआई और नेटिव एपीआई के लिए सहायता शामिल होनी चाहिए जिनके लिए उन्होंने OpenGL ES के हर उस वर्शन की पहचान की है जिस पर ये काम करते हैं.

अगर डिवाइस में स्क्रीन या वीडियो आउटपुट शामिल है, तो:

• [C-1-1] Android SDK के दस्तावेज़ में बताए गए तरीके से, OpenGL ES 1.1 और 2.0, दोनों के साथ काम करना चाहिए.
• [C-SR-1] हमारा सुझाव है कि आप OpenGL ES 3.1 का इस्तेमाल करें.
• यह OpenGL ES 3.2 के साथ काम करना चाहिए.

OpenGL ES dEQP टेस्ट को कई टेस्ट सूचियों में बांटा गया है. इनमें से हर सूची में, टेस्ट की तारीख/वर्शन नंबर शामिल होता है. ये external/deqp/android/cts/main/glesXX-main-YYYY-MM-DD.txt पर Android सोर्स ट्री में मौजूद हैं. अगर कोई डिवाइस, खुद से बताए गए लेवल पर OpenGL ES के साथ काम करता है, तो इसका मतलब है कि वह इस लेवल और उससे पहले के सभी टेस्ट की सूचियों में dEQP टेस्ट पास कर सकता है.

अगर डिवाइस पर लागू किए गए वर्शन, OpenGL ES के किसी वर्शन के साथ काम करते हैं, तो:

• [C-2-1] ऐप्लिकेशन में लागू किए गए किसी भी अन्य OpenGL ES एक्सटेंशन की जानकारी, OpenGL ES मैनेज किए जाने वाले एपीआई और नेटिव एपीआई के ज़रिए दी जानी चाहिए. इसके अलावा, उन एक्सटेंशन स्ट्रिंग की जानकारी नहीं दी जानी चाहिए जिन पर ऐप्लिकेशन काम नहीं करता.
• [C-2-2] यह EGL_KHR_image, EGL_KHR_image_base, EGL_ANDROID_image_native_buffer, EGL_ANDROID_get_native_client_buffer, EGL_KHR_wait_sync, EGL_KHR_get_all_proc_addresses, EGL_ANDROID_presentation_time, EGL_KHR_swap_buffers_with_damage, EGL_ANDROID_recordable, और EGL_ANDROID_GLES_layers एक्सटेंशन के साथ काम करना चाहिए.
• [C-2-3] android.software.opengles.deqp.level सुविधा फ़्लैग की मदद से काम करने वाले OpenGL ES dEQP टेस्ट के ज़्यादा से ज़्यादा वर्शन की रिपोर्ट करना ज़रूरी है.
• [C-2-4] android.software.opengles.deqp.level सुविधा फ़्लैग में बताए गए मुताबिक, कम से कम 132383489 वर्शन (1 मार्च, 2020 से) के साथ काम करना चाहिए.
• [C-2-5] यह ज़रूरी है कि ऐप्लिकेशन, 132383489 वर्शन और android.software.opengles.deqp.level सुविधा फ़्लैग में बताए गए वर्शन के बीच, टेस्ट की सूचियों में मौजूद सभी OpenGL ES dEQP टेस्ट पास करे. ऐसा, काम करने वाले हर OpenGL ES वर्शन के लिए करना होगा.
• [C-SR-2] हमारा सुझाव है कि आप EGL_KHR_partial_update और OES_EGL_image_external एक्सटेंशन का इस्तेमाल करें.

• getString() तरीके से, उन सभी टेक्सचर को सही तरीके से रिपोर्ट करना चाहिए जिनका इस्तेमाल वे कर सकते हैं. आम तौर पर, ये टेक्सचर वेंडर के हिसाब से होते हैं.

• EGL_IMG_context_priority और EGL_EXT_protected_content एक्सटेंशन के साथ काम करना चाहिए.

अगर डिवाइस में OpenGL ES 3.0, 3.1 या 3.2 का इस्तेमाल किया जा रहा है, तो:

• [C-3-1] libGLESv2.so लाइब्रेरी में मौजूद OpenGL ES 2.0 फ़ंक्शन सिंबल के अलावा, इन वर्शन के लिए भी संबंधित फ़ंक्शन सिंबल एक्सपोर्ट करने होंगे.
• [C-SR-3] OES_EGL_image_external_essl3 एक्सटेंशन के साथ काम करने का सुझाव दिया जाता है.

अगर डिवाइस पर OpenGL ES 3.2 वर्शन काम करता है, तो:

• [C-4-1] यह ज़रूरी है कि ऐप्लिकेशन, OpenGL ES Android एक्सटेंशन पैक के सभी वर्शन के साथ काम करे.

अगर डिवाइस पर OpenGL ES Android एक्सटेंशन पैक के सभी वर्शन काम करते हैं, तो:

• [C-5-1] android.hardware.opengles.aep फ़ीचर फ़्लैग की मदद से, सहायता की पहचान करना ज़रूरी है.

अगर डिवाइस में EGL_KHR_mutable_render_buffer एक्सटेंशन के साथ काम करने की सुविधा मौजूद है, तो:

• [C-6-1] यह EGL_ANDROID_front_buffer_auto_refresh एक्सटेंशन के साथ भी काम करना चाहिए.

7.1.4.2 Vulkan

Android में Vulkan के साथ काम करने की सुविधा शामिल है. यह कम ओवरहेड वाला क्रॉस-प्लैटफ़ॉर्म एपीआई है, जो बेहतर परफ़ॉर्मेंस वाले 3D ग्राफ़िक के लिए इस्तेमाल किया जाता है.

अगर डिवाइस पर OpenGL ES 3.1 काम करता है, तो:

• [C-SR-1] हमारा सुझाव है कि आप Vulkan 1.3 के साथ काम करने की सुविधा शामिल करें.
• [C-4-1] यह ज़रूरी है कि यह Vulkan के वैरिएंट वर्शन के साथ काम न करे. इसका मतलब है कि Vulkan के मुख्य वर्शन का वैरिएंट हिस्सा शून्य होना चाहिए.

अगर डिवाइस में स्क्रीन या वीडियो आउटपुट शामिल है, तो:

• [C-SR-2] हमारा सुझाव है कि आप Vulkan 1.3 के साथ काम करने की सुविधा शामिल करें.

Vulkan dEQP टेस्ट को कई टेस्ट सूचियों में बांटा गया है. इनमें से हर सूची में, टेस्ट की तारीख/वर्शन शामिल होता है. ये external/deqp/android/cts/main/vk-main-YYYY-MM-DD.txt पर Android सोर्स ट्री में मौजूद हैं. अगर किसी डिवाइस पर, खुद से बताए गए लेवल पर Vulkan काम करता है, तो इसका मतलब है कि वह इस लेवल और उससे पहले के सभी टेस्ट की सूचियों में dEQP टेस्ट पास कर सकता है.

अगर डिवाइस में Vulkan 1.0 या उसके बाद के वर्शन का इस्तेमाल किया जा सकता है, तो:

• [C-1-1] android.hardware.vulkan.level और android.hardware.vulkan.version सुविधा फ़्लैग के साथ, सही पूर्णांक वैल्यू की रिपोर्ट करना ज़रूरी है.
• [C-1-2] Vulkan नेटिव एपीआई vkEnumeratePhysicalDevices() के लिए, कम से कम एक VkPhysicalDevice एट्रिब्यूट की वैल्यू देना ज़रूरी है.
• [C-1-3] सूची में दिए गए हर VkPhysicalDevice के लिए, Vulkan 1.0 और Vulkan 1.1 एपीआई को पूरी तरह से लागू करना ज़रूरी है.
• [C-1-4] ऐप्लिकेशन पैकेज की नेटिव लाइब्रेरी डायरेक्ट्री में, libVkLayer*.so नाम वाली नेटिव लाइब्रेरी में मौजूद लेयर की सूची बनाना ज़रूरी है. इसके लिए, Vulkan नेटिव एपीआई vkEnumerateInstanceLayerProperties() और vkEnumerateDeviceLayerProperties() का इस्तेमाल करें.
• [C-1-5] ऐप्लिकेशन पैकेज के बाहर की लाइब्रेरी से मिलने वाली लेयर की सूची नहीं दी जानी चाहिए. इसके अलावा, Vulkan API को ट्रैक करने या उसे इंटरसेप्ट करने के अन्य तरीके भी नहीं दिए जाने चाहिए. ऐसा तब तक नहीं किया जाना चाहिए, जब तक ऐप्लिकेशन में android:debuggable एट्रिब्यूट को true के तौर पर सेट नहीं किया गया है या मेटाडेटा com.android.graphics.injectLayers.enable को true पर सेट नहीं किया गया है .
• [C-1-6] ऐप्लिकेशन को उन सभी एक्सटेंशन स्ट्रिंग की जानकारी देनी चाहिए जिनके साथ Vulkan नेटिव एपीआई काम करते हैं. इसके अलावा , उन एक्सटेंशन स्ट्रिंग की जानकारी नहीं देनी चाहिए जिनके साथ Vulkan नेटिव एपीआई काम नहीं करते.
• [C-1-7] VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, और VK_KHR_incremental_present एक्सटेंशन के साथ काम करना चाहिए.
• [C-1-8] android.software.vulkan.deqp.level सुविधा फ़्लैग की मदद से काम करने वाले, Vulkan dEQP टेस्ट के ज़्यादा से ज़्यादा वर्शन की रिपोर्ट करना ज़रूरी है.
• [C-1-9] android.software.vulkan.deqp.level सुविधा फ़्लैग में बताए गए वर्शन 132317953 (1 मार्च, 2019 से) के साथ काम करना चाहिए.
• [C-1-10] 132317953 वर्शन और android.software.vulkan.deqp.level सुविधा फ़्लैग में बताए गए वर्शन के बीच, टेस्ट की सूचियों में मौजूद सभी Vulkan dEQP टेस्ट पास करने होंगे.
• [C-1-11] VK_KHR_video_queue, VK_KHR_video_decode_queue या VK_KHR_video_encode_queue एक्सटेंशन के लिए, काम करने की जानकारी नहीं दी जानी चाहिए.
• [C-SR-3] VK_KHR_driver_properties और VK_GOOGLE_display_timing एक्सटेंशन के साथ काम करने के लिए, हमारा सुझाव है कि आप ऐसा करें.

• VkPhysicalDeviceProtectedMemoryFeatures और VK_EXT_global_priority के साथ काम करना चाहिए.

• [C-1-12] VK_KHR_performance_query एक्सटेंशन के लिए, काम करने की जानकारी नहीं दी जानी चाहिए.

• [C-1-13] Android Baseline 2021 प्रोफ़ाइल में बताई गई ज़रूरी शर्तों को पूरा करना ज़रूरी है.

• [C-SR-4] हमारा सुझाव है कि आप Android Baseline 2022 प्रोफ़ाइल में बताई गई ज़रूरी शर्तों को पूरा करें.

नई ज़रूरी शर्तें लागू करना

• [C-SR-5] VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory और VK_EXT_global_priority के साथ काम करने के लिए, ज़रूर इस्तेमाल करें.

• [C-SR-6] हमारा सुझाव है कि आप HWUI के साथ SkiaVk का इस्तेमाल करें.

नई ज़रूरी शर्तें खत्म करना

अगर डिवाइस में Vulkan 1.0 का इस्तेमाल नहीं किया जा सकता, तो:

• [C-2-1] Vulkan की किसी भी सुविधा के फ़्लैग (उदाहरण के लिए, android.hardware.vulkan.level, android.hardware.vulkan.version) का एलान नहीं किया जाना चाहिए.
• [C-2-2] Vulkan नेटिव एपीआई के लिए, किसी भी VkPhysicalDevice को एनोटेट नहीं किया जाना चाहिए vkEnumeratePhysicalDevices().

अगर डिवाइस में Vulkan 1.1 की सुविधा शामिल है और यहां बताए गए Vulkan की सुविधा वाले किसी भी फ़्लैग का एलान किया गया है, तो:

• [C-3-1] SYNC_FD एक्सटर्नल सिग्नल और हैंडल टाइप के साथ-साथ VK_ANDROID_external_memory_android_hardware_buffer एक्सटेंशन के लिए, सहायता उपलब्ध कराना ज़रूरी है.

नई ज़रूरी शर्तें लागू करना

• [C-SR-7] हमारा सुझाव है कि VK_KHR_external_fence_fd एक्सटेंशन को तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराएं. साथ ही, ऐप्लिकेशन को फ़ेंस पेलोड को POSIX फ़ाइल डिस्क्रिप्टर में एक्सपोर्ट करने और उससे फ़ेंस पेलोड इंपोर्ट करने की सुविधा दें. इसके बारे में यहां बताया गया है.

नई ज़रूरी शर्तें खत्म करना

7.1.4.3 RenderScript

• [C-0-1] डिवाइस पर Android RenderScript का इस्तेमाल किया जा सकता है. इस बारे में ज़्यादा जानकारी, Android SDK के दस्तावेज़ में दी गई है.

7.1.4.4 2D ग्राफ़िक एक्सेलरेशन

Android में एक ऐसा तरीका शामिल है जिससे ऐप्लिकेशन यह एलान कर सकते हैं कि उन्हें ऐप्लिकेशन, गतिविधि, विंडो या व्यू लेवल पर, 2D ग्राफ़िक के लिए हार्डवेयर ऐक्सेलरेशन की सुविधा चालू करनी है. इसके लिए, उन्हें मेनिफ़ेस्ट टैग android:hardwareAccelerated का इस्तेमाल करना होगा या सीधे तौर पर एपीआई कॉल करने होंगे.

डिवाइस पर लागू करने के तरीके:

• [C-0-1] हार्डवेयर से तेज़ी लाने की सुविधा को डिफ़ॉल्ट रूप से चालू करना ज़रूरी है. साथ ही, अगर डेवलपर ने android:hardwareAccelerated="false” को सेट करके या सीधे Android View API की मदद से हार्डवेयर से तेज़ी लाने की सुविधा को बंद करने का अनुरोध किया है, तो उसे बंद करना ज़रूरी है.
• [C-0-2] हार्डवेयर से तेज़ी लाने की सुविधा के लिए, Android SDK टूल के दस्तावेज़ में बताए गए तरीके के मुताबिक काम करना चाहिए.

Android में TextureView ऑब्जेक्ट शामिल होता है. इसकी मदद से, डेवलपर सीधे तौर पर हार्डवेयर से तेज़ किए गए OpenGL ES टेक्स्चर को, यूज़र इंटरफ़ेस (यूआई) के लेआउट में रेंडरिंग टारगेट के तौर पर इंटिग्रेट कर सकते हैं.

डिवाइस पर लागू करने के तरीके:

• [C-0-3] यह ज़रूरी है कि यह TextureView API के साथ काम करे. साथ ही, यह Android के अपस्ट्रीम वर्शन के साथ एक जैसा व्यवहार करे.

7.1.4.5 वाइड-गैमेट डिसप्ले

अगर डिवाइस में Configuration.isScreenWideColorGamut() के ज़रिए वाइड-गैमेट डिसप्ले के साथ काम करने का दावा किया जाता है, तो:

• [C-1-1] डिसप्ले का कलर कैलिब्रेट होना ज़रूरी है.
• [C-1-2] डिसप्ले का गैमट, CIE 1931 xyY स्पेस में sRGB कलर गैमट को पूरी तरह कवर करता हो.
• [C-1-3] डिसप्ले का गैमट, CIE 1931 xyY स्पेस में कम से कम 90% DCI-P3 होना चाहिए.
• [C-1-4] यह ज़रूरी है कि ऐप्लिकेशन, OpenGL ES 3.1 या 3.2 के साथ काम करे और इसकी सही तरीके से शिकायत करे.
• [C-1-5] EGL_KHR_no_config_context, EGL_EXT_pixel_format_float, EGL_KHR_gl_colorspace, EGL_EXT_gl_colorspace_scrgb, EGL_EXT_gl_colorspace_scrgb_linear, EGL_EXT_gl_colorspace_display_p3, EGL_EXT_gl_colorspace_display_p3_linear, और EGL_EXT_gl_colorspace_display_p3_passthrough एक्सटेंशन के लिए सहायता का विज्ञापन दिखाना ज़रूरी है.
• [C-SR-1] GL_EXT_sRGB के साथ काम करने के लिए, हमारा सुझाव है कि आप ज़रूर इसकी जांच करें.

इसके उलट, अगर डिवाइस पर लागू किए गए एलिमेंट, वाइड-गैमेट डिसप्ले के साथ काम नहीं करते, तो:

• [C-2-1] CIE 1931 xyY स्पेस में sRGB का 100% या उससे ज़्यादा हिस्सा कवर करना चाहिए. हालांकि, स्क्रीन का कलर गैमट तय नहीं है.

7.1.5. लेगसी ऐप्लिकेशन के साथ काम करने वाला मोड

Android में “कंपैटिबिलिटी मोड” की सुविधा होती है. इसमें फ़्रेमवर्क, स्क्रीन के 'सामान्य' साइज़ (320dp चौड़ाई) वाले मोड में काम करता है. ऐसा उन लेगसी ऐप्लिकेशन के लिए किया जाता है जिन्हें Android के पुराने वर्शन के लिए डिज़ाइन नहीं किया गया है. ये ऐसे वर्शन हैं जो स्क्रीन के साइज़ पर निर्भर नहीं थे.

7.1.6. स्क्रीन टेक्नोलॉजी

Android प्लैटफ़ॉर्म में ऐसे एपीआई शामिल होते हैं जिनकी मदद से ऐप्लिकेशन, Android के साथ काम करने वाले डिसप्ले पर बेहतर ग्राफिक्स रेंडर कर सकते हैं. डिवाइसों में, Android SDK टूल में बताए गए सभी एपीआई काम करने चाहिए. ऐसा तब तक ज़रूरी है, जब तक इस दस्तावेज़ में खास तौर पर अनुमति न दी गई हो.

किसी डिवाइस पर लागू किए गए Android के साथ काम करने वाले सभी डिसप्ले:

• [C-0-1] यह 16-बिट कलर ग्राफ़िक रेंडर करने में सक्षम होना चाहिए.
• यह 24-बिट कलर ग्राफ़िक्स वाले डिसप्ले के साथ काम करना चाहिए.
• [C-0-2] ऐनिमेशन रेंडर करने की सुविधा होनी चाहिए.
• [C-0-3] पिक्सल आसपेक्ट रेशियो (PAR) 0.9 से 1.15 के बीच होना चाहिए. इसका मतलब है कि पिक्सल का आसपेक्ट रेशियो, स्क्वेयर (1.0) के आस-पास होना चाहिए. इसमें 10 से 15% तक की गड़बड़ी हो सकती है.

7.1.7. दूसरे डिसप्ले

Android में, Android के साथ काम करने वाले सेकंडरी डिसप्ले के लिए सहायता शामिल है. इससे, मीडिया शेयर करने की सुविधाएं चालू की जा सकती हैं. साथ ही, बाहरी डिसप्ले को ऐक्सेस करने के लिए, डेवलपर एपीआई का इस्तेमाल किया जा सकता है.

अगर डिवाइस में वायर, वायरलेस या डिसप्ले के लिए अतिरिक्त कनेक्शन की सुविधा के ज़रिए, बाहरी डिसप्ले को कनेक्ट करने की सुविधा है, तो:

• [C-1-1] Android SDK टूल के दस्तावेज़ में बताए गए तरीके के मुताबिक, DisplayManager सिस्टम सेवा और एपीआई को लागू करना ज़रूरी है.

7.2. इनपुट डिवाइस

डिवाइस पर लागू करने के तरीके:

• [C-0-1] यूज़र इंटरफ़ेस (यूआई) एलिमेंट के बीच नेविगेट करने के लिए, इसमें टचस्क्रीन या नॉन-टच नेविगेशन जैसा कोई इनपुट सिस्टम होना चाहिए.

7.2.1. कीबोर्ड

अगर डिवाइस में तीसरे पक्ष के इनपुट के तरीके के संपादक (आईएमई) वाले ऐप्लिकेशन के लिए सहायता शामिल है, तो:

• [C-1-1] android.software.input_methods के फ़ीचर फ़्लैग का एलान करना ज़रूरी है.
• [C-1-2] इसे पूरी तरह से लागू करना ज़रूरी है Input Management Framework
• [C-1-3] डिवाइस में पहले से इंस्टॉल किया गया सॉफ़्टवेयर कीबोर्ड होना चाहिए.

डिवाइस पर लागू करने के तरीके:

• [C-0-1] डिवाइस में ऐसा हार्डवेयर कीबोर्ड शामिल नहीं होना चाहिए जो android.content.res.Configuration.keyboard में बताए गए किसी एक फ़ॉर्मैट (QWERTY या 12-key) से मेल न खाता हो.
• इसमें अन्य सॉफ़्ट कीबोर्ड लागू करने की सुविधा शामिल होनी चाहिए.
• इसमें हार्डवेयर कीबोर्ड शामिल हो सकता है.

7.2.2. बिना छुए नेविगेट करने की सुविधा

Android में, टच किए बिना नेविगेट करने के लिए, डी-पैड, ट्रैकबॉल, और व्हील की सुविधा शामिल है.

डिवाइस पर लागू करने के तरीके:

• [C-0-1] android.content.res.Configuration.navigation के लिए सही वैल्यू की जानकारी देनी ज़रूरी है.

अगर डिवाइस में बिना छुए नेविगेट करने की सुविधा नहीं है, तो:

• [C-1-1] टेक्स्ट चुनने और उसमें बदलाव करने के लिए, यूज़र इंटरफ़ेस का कोई ऐसा विकल्प देना ज़रूरी है जो इनपुट मैनेजमेंट इंजन के साथ काम करता हो. Android के ओपन सोर्स को लागू करने के लिए, एक चुनने का तरीका शामिल किया गया है. यह तरीका उन डिवाइसों के साथ इस्तेमाल करने के लिए सही है जिनमें नॉन-टच नेविगेशन इनपुट नहीं होते.

7.2.3. मार्गदर्शक कुंजियां

होम, हाल ही में इस्तेमाल किए गए, और वापस जाएं फ़ंक्शन, आम तौर पर किसी खास बटन या टच स्क्रीन के किसी खास हिस्से के इंटरैक्शन से मिलते हैं. ये फ़ंक्शन, Android नेविगेशन पैराडाइम और इसलिए, डिवाइस पर लागू करने के लिए ज़रूरी हैं:

• [C-0-1] आपको उपयोगकर्ताओं को, ऐसे इंस्टॉल किए गए ऐप्लिकेशन को लॉन्च करने की सुविधा देनी होगी जिनमें <intent-filter> सेट की गई गतिविधि के साथ-साथ, टेलिविज़न डिवाइस पर लागू करने के लिए ACTION=MAIN और CATEGORY=LAUNCHER या CATEGORY=LEANBACK_LAUNCHER सेट किया गया हो. होम फ़ंक्शन, इस उपयोगकर्ता के लिए उपलब्ध सुविधा के तौर पर काम करना चाहिए.
• हाल ही में इस्तेमाल किए गए आइटम और 'वापस जाएं' फ़ंक्शन के लिए बटन होने चाहिए.

अगर होम, हाल ही में इस्तेमाल किए गए आइटम या वापस जाने के फ़ंक्शन दिए गए हैं, तो:

• [C-1-1] अगर इनमें से किसी भी विकल्प को ऐक्सेस किया जा सकता है, तो उसे एक ही कार्रवाई (जैसे, टैप, दो बार क्लिक करना या जेस्चर) से ऐक्सेस किया जा सकता है.
• [C-1-2] यह साफ़ तौर पर बताया जाना चाहिए कि कौनसी एक कार्रवाई से हर फ़ंक्शन ट्रिगर होगा. बटन पर दिखने वाला आइकॉन, स्क्रीन के नेविगेशन बार पर सॉफ़्टवेयर आइकॉन दिखाना या डिवाइस के साथ मिलने वाले सेटअप के दौरान, उपयोगकर्ता को सिलसिलेवार निर्देशों के साथ डेमो फ़्लो दिखाना, इस तरह के संकेत के उदाहरण हैं.

डिवाइस पर लागू करने के तरीके:

• [C-SR-1] हमारा सुझाव है कि आप मेन्यू फ़ंक्शन के लिए इनपुट मैकेनिज्म न दें. ऐसा इसलिए, क्योंकि Android 4.0 के बाद से, ऐक्शन बार के पक्ष में इसे बंद कर दिया गया है.

• [C-SR-2] हमारा सुझाव है कि सभी नेविगेशन फ़ंक्शन को रद्द किया जा सके. 'रद्द किया जा सकता है' का मतलब है कि उपयोगकर्ता, स्वाइप करने के बाद एक तय समयसीमा के अंदर उसे छोड़कर, नेविगेशन फ़ंक्शन (जैसे, होम पर जाना, वापस जाना वगैरह) को लागू होने से रोक सकता है.

अगर डिवाइस में मेन्यू फ़ंक्शन उपलब्ध है, तो:

• [C-2-1] जब भी ऐक्शन ओवरफ़्लो मेन्यू पॉप-अप खाली न हो और ऐक्शन बार दिख रहा हो, तब ऐक्शन ओवरफ़्लो बटन दिखना चाहिए.
• [C-2-2] ऐक्शन बार में ओवरफ़्लो बटन चुनकर दिखाए गए ऐक्शन ओवरफ़्लो पॉप-अप की पोज़िशन में बदलाव नहीं किया जाना चाहिए. हालांकि, मेन्यू फ़ंक्शन चुनकर दिखाए जाने पर, ऐक्शन ओवरफ़्लो पॉप-अप को स्क्रीन पर बदली गई पोज़िशन पर रेंडर किया जा सकता है.

अगर डिवाइस में मेन्यू फ़ंक्शन उपलब्ध नहीं है, तो पुराने वर्शन के साथ काम करने के लिए, ये काम किए जाते हैं:

• [C-3-1] targetSdkVersion के 10 से कम होने पर, ऐप्लिकेशन के लिए मेन्यू फ़ंक्शन उपलब्ध कराना ज़रूरी है. यह फ़ंक्शन, फ़िज़िकल बटन, सॉफ़्टवेयर बटन या जेस्चर की मदद से उपलब्ध कराया जा सकता है. इस मेन्यू फ़ंक्शन को तब तक ऐक्सेस किया जा सकता है, जब तक इसे अन्य नेविगेशन फ़ंक्शन के साथ छिपाया नहीं जाता.

अगर डिवाइस में Assist फ़ंक्शन उपलब्ध है, तो:

• [C-4-1] अन्य नेविगेशन बटन ऐक्सेस किए जा सकने पर, Assist फ़ंक्शन को सिर्फ़ एक ऐक्शन (जैसे, टैप, डबल-क्लिक या जेस्चर) से ऐक्सेस किया जा सकता है.
• [C-SR-3] हमारा सुझाव है कि होम बटन को दबाकर रखने की सुविधा का इस्तेमाल करें, क्योंकि यह इंटरैक्शन के लिए तय किया गया है.

अगर डिवाइस पर नेविगेशन बटन दिखाने के लिए, स्क्रीन के किसी अलग हिस्से का इस्तेमाल किया जाता है, तो:

• [C-5-1] नेविगेशन बटन, स्क्रीन के उस हिस्से पर होने चाहिए जो ऐप्लिकेशन के लिए उपलब्ध नहीं है. साथ ही, इन बटन को स्क्रीन के उस हिस्से पर नहीं होना चाहिए जो ऐप्लिकेशन के लिए उपलब्ध है.
• [C-5-2] डिसप्ले का एक हिस्सा, उन ऐप्लिकेशन के लिए उपलब्ध कराना ज़रूरी है जो सेक्शन 7.1.1 में बताई गई ज़रूरी शर्तों को पूरा करते हैं.
• [C-5-3] ऐप्लिकेशन को View.setSystemUiVisibility() एपीआई के तरीके से सेट किए गए फ़्लैग का पालन करना चाहिए, ताकि स्क्रीन के इस खास हिस्से (जिसे नेविगेशन बार भी कहा जाता है) को SDK टूल में बताए गए तरीके से सही तरीके से छिपाया जा सके.

अगर नेविगेशन फ़ंक्शन, स्क्रीन पर जेस्चर के आधार पर कार्रवाई करने के तौर पर दिया गया है, तो:

• [C-6-1] WindowInsets#getMandatorySystemGestureInsets() इसका इस्तेमाल सिर्फ़ होम जेस्चर की पहचान करने वाले एरिया की रिपोर्टिंग के लिए किया जाना चाहिए.
• [C-6-2] View#setSystemGestureExclusionRects() के ज़रिए फ़ोरग्राउंड ऐप्लिकेशन से मिले एक्सक्लूज़न रेक्ट में शुरू होने वाले, लेकिन WindowInsets#getMandatorySystemGestureInsets() के बाहर के जेस्चर को नेविगेशन फ़ंक्शन के लिए इंटरसेप्ट नहीं किया जाना चाहिए. ऐसा तब तक नहीं किया जाना चाहिए, जब तक एक्सक्लूज़न रेक्ट को एक्सक्लूज़न की तय सीमा के अंदर रखा जाता है. इस सीमा के बारे में View#setSystemGestureExclusionRects() के दस्तावेज़ में बताया गया है.
• [C-6-3] अगर फ़ोरग्राउंड ऐप्लिकेशन को पहले कोई MotionEvent.ACTION_DOWN इवेंट भेजा गया था, तो सिस्टम जेस्चर के लिए टच को इंटरसेप्ट करने के बाद, फ़ोरग्राउंड ऐप्लिकेशन को MotionEvent.ACTION_CANCEL इवेंट भेजना ज़रूरी है.
• [C-6-4] उपयोगकर्ता को स्क्रीन पर बटन के आधार पर नेविगेट करने की सुविधा देनी चाहिए. उदाहरण के लिए, सेटिंग में.
• होम फ़ंक्शन को स्क्रीन के मौजूदा ओरिएंटेशन के सबसे नीचे से ऊपर की ओर स्वाइप करके उपलब्ध कराया जाना चाहिए.
• हाल ही में इस्तेमाल किए गए आइटम देखने की सुविधा, होम जेस्चर वाले हिस्से से ऊपर की ओर स्वाइप करके और रिलीज़ करने से पहले दबाकर चालू की जानी चाहिए.
• WindowInsets#getMandatorySystemGestureInsets() में शुरू होने वाले जेस्चर पर, फ़ोरग्राउंड ऐप्लिकेशन के View#setSystemGestureExclusionRects() के ज़रिए दिए गए एक्सक्लूज़न रीक्ट का असर नहीं पड़ना चाहिए.

अगर स्क्रीन के मौजूदा ओरिएंटेशन के बाएं और दाएं किनारों पर, कहीं से भी नेविगेशन फ़ंक्शन दिया गया है, तो:

• [C-7-1] नेविगेशन फ़ंक्शन 'वापस जाएं' होना चाहिए. साथ ही, इसे स्क्रीन के मौजूदा ओरिएंटेशन के बाएं और दाएं किनारों से स्वाइप करके उपलब्ध कराया जाना चाहिए.
• [C-7-2] अगर बाईं या दाईं ओर, स्वाइप किए जा सकने वाले कस्टम सिस्टम पैनल दिए गए हैं, तो उन्हें स्क्रीन के सबसे ऊपर 1/3 हिस्से में रखा जाना चाहिए. साथ ही, यह साफ़ तौर पर और लगातार दिखना चाहिए कि पैनल को खींचकर लाने पर, ऊपर बताए गए पैनल खुलेंगे, न कि 'वापस जाएं' बटन. उपयोगकर्ता, सिस्टम पैनल को इस तरह कॉन्फ़िगर कर सकता है कि वह स्क्रीन के सबसे ऊपरी एक तिहाई हिस्से के नीचे दिखे. हालांकि, सिस्टम पैनल के लिए एक तिहाई से ज़्यादा हिस्से का इस्तेमाल नहीं किया जाना चाहिए.
• [C-7-3] जब फ़ोरग्राउंड ऐप्लिकेशन में, View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT या WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE फ़्लैग सेट हों, तो किनारों से स्वाइप करने पर, AOSP में लागू किए गए तरीके के मुताबिक काम करना चाहिए. इस बारे में SDK में जानकारी दी गई है.
• [C-7-4] जब फ़ोरग्राउंड ऐप्लिकेशन में, View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT या WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE फ़्लैग सेट हों, तो स्वाइप किए जा सकने वाले कस्टम सिस्टम पैनल तब तक छिपे होने चाहिए, जब तक उपयोगकर्ता AOSP में लागू किए गए सिस्टम बार (जिसे नेविगेशन और स्टेटस बार भी कहा जाता है) को नहीं दिखाता या उनका कलर ज़्यादा नहीं करता.

अगर 'वापस जाएं' नेविगेशन फ़ंक्शन उपलब्ध कराया गया है और उपयोगकर्ता 'वापस जाएं' जेस्चर को रद्द करता है, तो:

• [C-8-1] OnBackInvokedCallback.onBackCancelled() को कॉल करना ज़रूरी है.
• [C-8-2] OnBackInvokedCallback.onBackInvoked() को कॉल नहीं किया जाना चाहिए.
• [C-8-3] KEYCODE_BACK इवेंट को डिस्पैच नहीं किया जाना चाहिए.

अगर 'वापस जाएं' नेविगेशन फ़ंक्शन उपलब्ध है, लेकिन फ़ोरग्राउंड ऐप्लिकेशन में OnBackInvokedCallback रजिस्टर नहीं है, तो:

• सिस्टम को फ़ोरग्राउंड ऐप्लिकेशन के लिए ऐसा ऐनिमेशन उपलब्ध कराना चाहिए जिससे यह पता चलता हो कि उपयोगकर्ता वापस जा रहा है. यह ऐनिमेशन, AOSP में बताए गए तरीके से होना चाहिए.

अगर डिवाइस में, सिस्टम एपीआई setNavBarMode के लिए सहायता उपलब्ध कराई जाती है, ताकि android.permission.STATUS_BAR अनुमति वाले किसी भी सिस्टम ऐप्लिकेशन को नेविगेशन बार मोड सेट करने की अनुमति दी जा सके, तो:

• [C-9-1] AOSP कोड में बताए गए मुताबिक, बच्चों के हिसाब से बने आइकॉन या बटन पर आधारित नेविगेशन की सुविधा देना ज़रूरी है.

7.2.4. टचस्क्रीन इनपुट

Android में कई तरह के पॉइंटर इनपुट सिस्टम के साथ काम करने की सुविधा शामिल है. जैसे, टचस्क्रीन, टच पैड, और फ़ेक टच इनपुट डिवाइस. टचस्क्रीन पर काम करने वाले डिवाइसों पर लागू होने वाले एक्सटेंशन, डिसप्ले से जुड़े होते हैं. इससे उपयोगकर्ता को ऐसा लगता है कि वह स्क्रीन पर मौजूद आइटम को सीधे तौर पर मैनेज कर रहा है. उपयोगकर्ता सीधे तौर पर स्क्रीन को छू रहा है, इसलिए सिस्टम को ऑब्जेक्ट में बदलाव किए जा रहे हैं, यह बताने के लिए किसी और सुविधा की ज़रूरत नहीं है.

डिवाइस पर लागू करने के तरीके:

• इसमें किसी तरह का पॉइंटर इनपुट सिस्टम होना चाहिए (माउस जैसा या टच).
• यह पूरी तरह से स्वतंत्र रूप से ट्रैक किए गए पॉइंटर के साथ काम करना चाहिए.

अगर डिवाइस में, Android के साथ काम करने वाले मुख्य डिसप्ले पर टचस्क्रीन (सिंगल-टच या बेहतर) शामिल है, तो:

• [C-1-1] Configuration.touchscreen एपीआई फ़ील्ड के लिए, TOUCHSCREEN_FINGER की जानकारी देना ज़रूरी है.
• [C-1-2] android.hardware.touchscreen और android.hardware.faketouch सुविधा फ़्लैग की रिपोर्ट करना ज़रूरी है.

अगर डिवाइस में ऐसी टचस्क्रीन है जो Android के साथ काम करने वाले मुख्य डिसप्ले पर, एक से ज़्यादा टच को ट्रैक कर सकती है, तो:

• [C-2-1] डिवाइस पर मौजूद टचस्क्रीन के टाइप के हिसाब से, android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct, android.hardware.touchscreen.multitouch.jazzhand के हिसाब से सही फ़ीचर फ़्लैग की जानकारी देनी ज़रूरी है.

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

• [C-3-1] android.hardware.touchscreen से शुरू होने वाले किसी भी सुविधा फ़्लैग की शिकायत नहीं की जानी चाहिए.
• [C-3-2] सिर्फ़ android.hardware.faketouch की रिपोर्ट देनी होगी.
• [C-3-3] Configuration.touchscreen एपीआई फ़ील्ड के लिए, TOUCHSCREEN_NOTOUCH की जानकारी देना ज़रूरी है.

7.2.5. नकली टच इनपुट

नकली टच इंटरफ़ेस, उपयोगकर्ता इनपुट सिस्टम उपलब्ध कराता है. यह टचस्क्रीन की सुविधाओं के सबसेट के बराबर होता है. उदाहरण के लिए, माउस या रिमोट कंट्रोल की मदद से, स्क्रीन पर कर्सर को घुमाया जा सकता है. हालांकि, इसके लिए उपयोगकर्ता को पहले कर्सर को पॉइंट करना या फ़ोकस करना पड़ता है. इसके बाद, क्लिक करना पड़ता है. माउस, ट्रैकपैड, घुमाव-आधारित एयर माउस, घुमाव-पॉइंटर, जॉयस्टिक, और मल्टी-टच ट्रैकपैड जैसे कई इनपुट डिवाइसों पर, फ़ेक टच इंटरैक्शन की सुविधा काम कर सकती है. Android में, सुविधा के लिए एक कॉन्स्टेंट होता है, जिसे android.hardware.faketouch कहा जाता है. यह कॉन्स्टेंट, हाई-फ़िडेलिटी वाले ऐसे इनपुट डिवाइस से जुड़ा होता है जो टच (पॉइंटर पर आधारित) नहीं होता. जैसे, माउस या ट्रैकपैड. यह डिवाइस, टच पर आधारित इनपुट (इसमें बुनियादी जेस्चर की सुविधा भी शामिल है) को ठीक से एमुलेट कर सकता है. साथ ही, यह बताता है कि डिवाइस, टचस्क्रीन की सुविधा के एमुलेट किए गए सबसेट के साथ काम करता है.

अगर डिवाइस में टचस्क्रीन नहीं है, लेकिन कोई ऐसा पॉइंटर इनपुट सिस्टम है जिसे उपलब्ध कराना है, तो:

• android.hardware.faketouch फ़ीचर फ़्लैग के साथ काम करने की जानकारी देनी चाहिए.

अगर डिवाइस पर android.hardware.faketouch की सुविधा काम करती है, तो:

• [C-1-1] पॉइंटर की जगह की स्क्रीन पर पूरी X और Y पोज़िशन की जानकारी देनी चाहिए. साथ ही, स्क्रीन पर विज़ुअल पॉइंटर दिखाना चाहिए.
• [C-1-2] टच इवेंट को उस ऐक्शन कोड के साथ रिपोर्ट करना ज़रूरी है जो स्क्रीन पर नीचे या ऊपर जाने वाले पॉइंटर पर होने वाले स्टेटस में बदलाव के बारे में बताता है.
• [C-1-3] स्क्रीन पर मौजूद किसी ऑब्जेक्ट पर कर्सर को नीचे और ऊपर ले जाने की सुविधा होनी चाहिए. इससे, उपयोगकर्ताओं को स्क्रीन पर मौजूद किसी ऑब्जेक्ट पर टैप करने की सुविधा मिलती है.
• [C-1-4] स्क्रीन पर किसी ऑब्जेक्ट पर, एक तय समयसीमा के अंदर, पॉइंटर को नीचे, ऊपर, फिर नीचे और फिर ऊपर ले जाने की सुविधा होनी चाहिए. इससे उपयोगकर्ता, स्क्रीन पर किसी ऑब्जेक्ट पर डबल टैप करने की सुविधा का इस्तेमाल कर सकते हैं.
• [C-1-5] यह ज़रूरी है कि स्क्रीन पर किसी भी बिंदु पर कर्सर को नीचे की ओर ले जाया जा सके. इसके बाद, कर्सर को स्क्रीन पर किसी भी बिंदु पर ले जाया जा सके. इसके बाद, कर्सर को ऊपर की ओर ले जाया जा सके. इससे उपयोगकर्ता, टच ड्रैग की सुविधा का इस्तेमाल कर सकते हैं.
• [C-1-6] ऐप्लिकेशन में पॉइंटर डाउन की सुविधा होनी चाहिए. इसके बाद, उपयोगकर्ताओं को स्क्रीन पर किसी ऑब्जेक्ट को तुरंत किसी दूसरी जगह ले जाने की अनुमति मिलनी चाहिए. इसके बाद, स्क्रीन पर पॉइंटर अप की सुविधा होनी चाहिए, ताकि उपयोगकर्ता स्क्रीन पर किसी ऑब्जेक्ट को फ़्लिंग कर सकें.

अगर डिवाइस पर android.hardware.faketouch.multitouch.distinct का इस्तेमाल करने की सुविधा उपलब्ध है, तो:

• [C-2-1] android.hardware.faketouch के लिए सहायता उपलब्ध कराने का एलान करना ज़रूरी है.
• [C-2-2] यह ज़रूरी है कि यह दो या उससे ज़्यादा इंडिपेंडेंट पॉइंटर इनपुट की अलग-अलग ट्रैकिंग की सुविधा देता हो.

अगर डिवाइस पर android.hardware.faketouch.multitouch.jazzhand का इस्तेमाल करने की सुविधा उपलब्ध है, तो:

• [C-3-1] android.hardware.faketouch के लिए सहायता देने का एलान करना ज़रूरी है.
• [C-3-2] यह ज़रूरी है कि डिवाइस, पांच (हाथ की उंगलियों को ट्रैक करना) या उससे ज़्यादा पॉइंटर इनपुट को अलग-अलग ट्रैक कर सके.

7.2.6. गेम कंट्रोलर के लिए सहायता

7.2.6.1. बटन मैपिंग

डिवाइस पर लागू करने के तरीके:

• [C-1-1] यह ज़रूरी है कि HID इवेंट को, नीचे दी गई टेबल में दी गई InputEvent कॉन्स्टेंट से मैप किया जा सके. Android के अपस्ट्रीम वर्शन में, यह ज़रूरी शर्त पूरी की जाती है.

अगर डिवाइस में कोई कंट्रोलर जोड़ा गया है या बॉक्स में अलग कंट्रोलर दिया गया है, तो नीचे दी गई टेबल में दिए गए सभी इवेंट को इनपुट करने के लिए:

• [C-2-1] फ़ीचर फ़्लैग android.hardware.gamepad का एलान करना ज़रूरी है

बटन	एचआईडी का इस्तेमाल^2	Android बटन
A^1	0x09 0x0001	KEYCODE_BUTTON_A (96)
B^1	0x09 0x0002	KEYCODE_BUTTON_B (97)
X^1	0x09 0x0004	KEYCODE_BUTTON_X (99)
Y^1	0x09 0x0005	KEYCODE_BUTTON_Y (100)
डी-पैड अप^1 डी-पैड डाउन^1	0x01 0x0039^3	AXIS_HAT_Y^4
डी-पैड बाईं ओर1 डी-पैड दाईं ओर^1	0x01 0x0039^3	AXIS_HAT_X^4
लेफ़्ट शोल्डर बटन^1	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
राइट शोल्डर बटन^1	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
लेफ़्ट स्टिक क्लिक^1	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
राइट स्टिक क्लिक^1	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
वापस जाएं^1	0x0c 0x0224	KEYCODE_BACK (4)

1 KeyEvent

2 ऊपर बताए गए एचआईडी के इस्तेमाल की जानकारी, गेमपैड सीए (0x01 0x0005) में दी जानी चाहिए.

3 इस इस्तेमाल के लिए, लॉजिकल तौर पर कम से कम 0 और ज़्यादा से ज़्यादा 7, फ़िज़िकल तौर पर कम से कम 0 और ज़्यादा से ज़्यादा 315, डिग्री में यूनिट, और रिपोर्ट का साइज़ 4 होना चाहिए. लॉजिकल वैल्यू को वर्टिकल ऐक्सिस से, घड़ी की सुई के घूमने की दिशा में घुमाने के तौर पर तय किया गया है. उदाहरण के लिए, लॉजिकल वैल्यू 0 का मतलब है कि कोई घुमाव नहीं है और अप बटन दबाया गया है. वहीं, लॉजिकल वैल्यू 1 का मतलब है कि 45 डिग्री का घुमाव है और अप और लेफ़्ट बटन, दोनों दबाए गए हैं.

4 MotionEvent

ऐनलॉग कंट्रोल^1	एचआईडी का इस्तेमाल	Android बटन
लेफ़्ट ट्रिगर	0x02 0x00C5	AXIS_LTRIGGER
राइट ट्रिगर	0x02 0x00C4	AXIS_RTRIGGER
लेफ़्ट जॉयस्टिक	0x01 0x0030 0x01 0x0031	AXIS_X AXIS_Y
राइट जॉयस्टिक	0x01 0x0032 0x01 0x0035	AXIS_Z AXIS_RZ

एक MotionEvent

7.2.7. रिमोट कंट्रोल

डिवाइस के हिसाब से ज़रूरी शर्तों के बारे में जानने के लिए, सेक्शन 2.3.1 देखें.

7.3. सेंसर

अगर डिवाइस में किसी खास तरह का सेंसर शामिल है, जिसके लिए तीसरे पक्ष के डेवलपर के पास एपीआई है, तो डिवाइस में उस एपीआई को लागू करना ज़रूरी है. इसके बारे में, Android SDK टूल के दस्तावेज़ और सेंसर के बारे में Android के ओपन सोर्स दस्तावेज़ में बताया गया है.

डिवाइस पर लागू करने के तरीके:

• [C-0-1] android.content.pm.PackageManager क्लास के हिसाब से, सेंसर की मौजूदगी या अनुपस्थिति की सटीक जानकारी देनी चाहिए.
• [C-0-2] SensorManager.getSensorList() और मिलते-जुलते तरीकों की मदद से, काम करने वाले सेंसर की सटीक सूची दिखानी चाहिए.
• [C-0-3] अन्य सभी सेंसर एपीआई के लिए, सही तरीके से काम करना चाहिए. उदाहरण के लिए, जब ऐप्लिकेशन, सुनने वालों को रजिस्टर करने की कोशिश करते हैं, तो true या false को ज़रूरत के हिसाब से दिखाना. साथ ही, जब संबंधित सेंसर मौजूद न हों, तो सेंसर सुनने वालों को कॉल न करना वगैरह.

अगर डिवाइस में किसी खास तरह का सेंसर शामिल है, जिसके लिए तीसरे पक्ष के डेवलपर के पास एपीआई है, तो:

• [C-1-1] Android SDK टूल के दस्तावेज़ में बताए गए हर सेंसर टाइप के लिए, सभी सेंसर मेज़रमेंट की रिपोर्ट भेजना ज़रूरी है. इसके लिए, इंटरनैशनल सिस्टम ऑफ़ यूनिट (मेट्रिक) की सही वैल्यू का इस्तेमाल करना होगा.
• [C-1-2] सेंसर डेटा को 100 मिलीसेकंड + 2 * sample_time के ज़्यादा से ज़्यादा इंतज़ार के साथ रिपोर्ट करना ज़रूरी है. ऐसा तब करना होगा, जब ऐप्लिकेशन प्रोसेसर चालू हो और सेंसर स्ट्रीम के लिए, ज़्यादा से ज़्यादा इंतज़ार का अनुरोध 0 मिलीसेकंड हो. इस समय में, फ़िल्टर करने में लगने वाला समय शामिल नहीं है.
• [C-1-3] सेंसर के चालू होने के 400 मिलीसेकंड + 2 * sample_time के अंदर, सेंसर के पहले सैंपल की जानकारी देनी ज़रूरी है. इस सैंपल के लिए, सटीक होने की वैल्यू 0 हो सकती है.
• [C-1-4] Android SDK दस्तावेज़ में बताए गए किसी भी एपीआई को कंटिन्यूअस सेंसर के तौर पर इस्तेमाल करने के लिए, डिवाइस में लागू किए गए एपीआई को समय-समय पर डेटा सैंपल उपलब्ध कराने होंगे. इन सैंपल में जिटर 3% से कम होना चाहिए. जिटर को, लगातार होने वाले इवेंट के बीच रिपोर्ट किए गए टाइमस्टैंप की वैल्यू के अंतर के स्टैंडर्ड डेविएशन के तौर पर परिभाषित किया जाता है.
• [C-1-5] यह पक्का करना ज़रूरी है कि सेंसर इवेंट स्ट्रीम, डिवाइस के सीपीयू को निलंबित होने या निलंबित होने के बाद फिर से चालू होने से न रोके.
• [C-1-6] Android SDK टूल के दस्तावेज़ में बताए गए मुताबिक, इवेंट के समय की जानकारी, नैनोसेकंड में देनी ज़रूरी है. इससे, इवेंट के होने का समय पता चलता है. साथ ही, यह जानकारी SystemClock.elapsedRealtimeNano() घड़ी के साथ सिंक होती है.
• [C-SR-1] हमारा सुझाव है कि टाइमस्टैंप सिंक करने में होने वाली गड़बड़ी 100 मिलीसेकंड से कम होनी चाहिए. साथ ही, टाइमस्टैंप सिंक करने में होने वाली गड़बड़ी 1 मिलीसेकंड से कम होनी चाहिए.
• जब कई सेंसर चालू होते हैं, तो बिजली की खपत, अलग-अलग सेंसर की बिजली की खपत के कुल योग से ज़्यादा नहीं होनी चाहिए.

ऊपर दी गई सूची पूरी नहीं है. सेंसर के लिए, Android SDK टूल और Android के ओपन सोर्स दस्तावेज़ों के व्यवहार को आधिकारिक माना जाएगा.

अगर डिवाइस में किसी खास तरह का सेंसर शामिल है, जिसके लिए तीसरे पक्ष के डेवलपर के पास एपीआई है, तो:

• [C-1-6] सभी सेंसर के लिए, शून्य से अलग रिज़ॉल्यूशन सेट करना ज़रूरी है. साथ ही, Sensor.getResolution() एपीआई के तरीके से वैल्यू की रिपोर्ट करनी होगी.

कुछ सेंसर टाइप कंपोजिट होते हैं. इसका मतलब है कि उन्हें एक या एक से ज़्यादा अन्य सेंसर से मिले डेटा से लिया जा सकता है. उदाहरण के लिए, ओरिएंटेशन सेंसर और ऐक्सेलरेशन सेंसर.

डिवाइस पर लागू करने के तरीके:

• सेंसर टाइप में बताए गए ज़रूरी फ़िज़िकल सेंसर शामिल होने पर, इन सेंसर टाइप को लागू करना चाहिए.

अगर डिवाइस में कॉम्पोज़िट सेंसर शामिल है, तो:

• [C-2-1] कंपोज़िट सेंसर के लिए, Android के ओपन सोर्स दस्तावेज़ में बताए गए तरीके के मुताबिक सेंसर को लागू करना ज़रूरी है.

अगर डिवाइस में लागू किए गए किसी सेंसर टाइप में, तीसरे पक्ष के डेवलपर के लिए एपीआई है और सेंसर सिर्फ़ एक वैल्यू रिपोर्ट करता है, तो डिवाइस में लागू किए गए:

• [C-3-1] सेंसर के लिए रिज़ॉल्यूशन को 1 पर सेट करना ज़रूरी है. साथ ही, Sensor.getResolution() एपीआई के तरीके से वैल्यू की रिपोर्ट करनी होगी.

अगर डिवाइस में लागू किए गए किसी सेंसर टाइप में SensorAdditionalInfo#TYPE_VEC3_CALIBRATION का इस्तेमाल किया जा सकता है और वह सेंसर तीसरे पक्ष के डेवलपर के लिए उपलब्ध है, तो वे:

• [C-4-1] दिए गए डेटा में, फ़ैक्ट्री से तय किए गए कैलिब्रेशन पैरामीटर शामिल नहीं होने चाहिए.

अगर डिवाइस में 3-ऐक्सिस एक्सलरोमीटर, 3-ऐक्सिस जाइरोस्कोप सेंसर या मैग्नेटोमीटर सेंसर का कॉम्बिनेशन शामिल है, तो वे:

• [C-SR-2] हमारा सुझाव है कि आप यह पक्का करें कि एक्सलरोमीटर, जाइरोस्कोप, और मैग्नेटोमीटर की रिलेटिव पोज़िशन एक जैसी हो. इससे, अगर डिवाइस को बदला जा सकता है, जैसे कि फ़ोल्ड किया जा सकता है, तो सेंसर ऐक्सिस, डिवाइस के बदलाव की सभी स्थितियों में सेंसर कोऑर्डिनेट सिस्टम के साथ अलाइन और एक जैसा बना रहता है.

7.3.1. एक्सलरोमीटर

डिवाइस पर लागू करने के तरीके:

• [C-SR-1] हमारा सुझाव है कि आप 3-ऐक्सिस एक्सलरोमीटर शामिल करें.

अगर डिवाइस में एक्सलरोमीटर शामिल है, तो:

• [C-1-1] यह ज़रूरी है कि डिवाइस कम से कम 50 हर्ट्ज़ तक की फ़्रीक्वेंसी वाले इवेंट की रिपोर्ट कर सके.
• [C-1-3] Android एपीआई में बताए गए Android सेंसर कोऑर्डिनेट सिस्टम का पालन करना ज़रूरी है.
• [C-1-4] यह ज़रूरी है कि यह किसी भी अक्ष पर, गुरुत्वाकर्षण के चार गुना(4g) या उससे ज़्यादा तक के फ़्रीफ़ॉल को मेज़र कर सके.
• [C-1-5] का रिज़ॉल्यूशन कम से कम 12-बिट होना चाहिए.
• [C-1-6] का स्टैंडर्ड डेविएशन 0.05 मीटर/सेकंड^ से ज़्यादा नहीं होना चाहिए. यहां स्टैंडर्ड डेविएशन का हिसाब, हर अक्ष के आधार पर लगाया जाना चाहिए. इसके लिए, कम से कम तीन सेकंड के दौरान इकट्ठा किए गए सैंपल का इस्तेमाल करना चाहिए. सैंपल इकट्ठा करने की दर सबसे तेज़ होनी चाहिए.
• कम से कम 200 हर्ट्ज़ तक के इवेंट रिपोर्ट करने चाहिए.
• इसका रिज़ॉल्यूशन कम से कम 16-बिट होना चाहिए.
• अगर लाइफ़ साइकल के दौरान प्रॉपर्टी में बदलाव होता है और उन्हें कैलिब्रेट किया जाता है, तो डिवाइस के रीबूट होने के बीच, कैलिब्रेशन पैरामीटर को बनाए रखा जाना चाहिए.
• तापमान के हिसाब से अडजस्ट होना चाहिए.

अगर डिवाइस में 3-ऐक्सिस एक्सलरोमीटर शामिल है, तो:

• [C-2-1] TYPE_ACCELEROMETER सेंसर को लागू करना और उसकी रिपोर्ट देना ज़रूरी है.
• [C-SR-4] हमारा सुझाव है कि आप TYPE_SIGNIFICANT_MOTION कंपोज़िट सेंसर को लागू करें.
• [C-SR-5] TYPE_ACCELEROMETER_UNCALIBRATED सेंसर को लागू करने और उसकी रिपोर्ट करने का ज़रूर सुझाव दिया जाता है. हमारा सुझाव है कि Android डिवाइसों को इस ज़रूरी शर्त को पूरा करना चाहिए, ताकि वे आने वाले समय में प्लैटफ़ॉर्म के उस रिलीज़ पर अपग्रेड कर सकें जहां यह ज़रूरी हो सकता है.
• Android SDK दस्तावेज़ में बताए गए तरीके के मुताबिक, TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER कंपोज़िट सेंसर लागू करने चाहिए.

अगर डिवाइस में तीन ऐक्सिस से कम वाला एक्सलरोमीटर शामिल है, तो:

• [C-3-1] TYPE_ACCELEROMETER_LIMITED_AXES सेंसर को लागू करना और उसकी रिपोर्ट देना ज़रूरी है.
• [C-SR-6] TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED सेंसर को लागू करने और उसकी रिपोर्ट करने का STRONGLY_RECOMMENDED.

अगर डिवाइस में 3-ऐक्सिस ऐक्सीलरॉमीटर और TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER में से कोई एक कंपोजिट सेंसर लागू किया गया है, तो:

• [C-4-1] इनके बिजली खर्च का कुल योग हमेशा 4 mW से कम होना चाहिए.
• डिवाइस के डाइनैमिक या स्टैटिक होने पर, हर एक काफ़ी कम होना चाहिए. जैसे, 2 mW और 0.5 mW से कम.

अगर डिवाइस में 3-ऐक्सिस एक्सलरोमीटर और 3-ऐक्सिस जाइरोस्कोप सेंसर शामिल हैं, तो:

• [C-5-1] TYPE_GRAVITY और TYPE_LINEAR_ACCELERATION के कॉम्पोनेंट सेंसर लागू करने ज़रूरी हैं.
• [C-SR-7] TYPE_GAME_ROTATION_VECTOR कंपोजिट सेंसर को लागू करने का ज़रूर सुझाव दिया जाता है.

अगर डिवाइस में 3-ऐक्सिस एक्सलरोमीटर, 3-ऐक्सिस जाइरोस्कोप सेंसर, और मैग्नेटोमीटर सेंसर शामिल हैं, तो:

• [C-6-1] TYPE_ROTATION_VECTOR कंपोजिट सेंसर को लागू करना ज़रूरी है.

7.3.2. मैग्नेटोमीटर

डिवाइस पर लागू करने के तरीके:

• [C-SR-1] हमारा सुझाव है कि आप 3-ऐक्सिस मैग्नेटोमीटर (कम्पास) शामिल करें.

अगर डिवाइस में तीन ऐक्सिस वाला मैग्नेटोमीटर शामिल है, तो:

• [C-1-1] TYPE_MAGNETIC_FIELD सेंसर को लागू करना ज़रूरी है.
• [C-1-2] यह ज़रूरी है कि डिवाइस कम से कम 10 हर्ट्ज़ की फ़्रीक्वेंसी तक के इवेंट रिपोर्ट कर सके और कम से कम 50 हर्ट्ज़ तक के इवेंट रिपोर्ट करे.
• [C-1-3] Android API में बताए गए Android सेंसर कोऑर्डिनेट सिस्टम के मुताबिक होना चाहिए.
• [C-1-4] यह ज़रूरी है कि सैचुरेट होने से पहले, हर अक्ष पर -900 µT से +900 µT के बीच मेज़रमेंट किया जा सके.
• [C-1-5] मैग्नेटोमीटर को डाइनैमिक (इंजन से जनरेट होने वाले चुंबकीय क्षेत्र) और स्टैटिक (चुंबक से जनरेट होने वाले चुंबकीय क्षेत्र) चुंबकीय क्षेत्रों से दूर रखकर, हार्ड आयरन ऑफ़सेट की वैल्यू 700 µT से कम होनी चाहिए. साथ ही, यह वैल्यू 200 µT से कम होनी चाहिए.
• [C-1-6] का रिज़ॉल्यूशन 0.6 µT के बराबर या उससे ज़्यादा होना चाहिए.
• [C-1-7] यह ज़रूरी है कि डिवाइस, हार्ड आयरन बायस के ऑनलाइन कैलिब्रेशन और कंपेसेशन की सुविधा देता हो. साथ ही, डिवाइस के रीबूट होने के बीच कंपेसेशन पैरामीटर को सेव रखता हो.
• [C-1-8] डिवाइस में सॉफ़्ट आयरन कम्पेंसेशन की सुविधा होनी चाहिए. डिवाइस के इस्तेमाल के दौरान या उसके प्रोडक्शन के दौरान, कैलिब्रेशन किया जा सकता है.
• [C-1-9] स्टैंडर्ड डेविएशन होना चाहिए. इसका हिसाब, हर अक्ष के आधार पर, कम से कम तीन सेकंड की अवधि में इकट्ठा किए गए सैंपल के हिसाब से लगाया जाता है. सैंपलिंग की सबसे तेज़ दर 1.5 µT से ज़्यादा नहीं होनी चाहिए. स्टैंडर्ड डेविएशन 0.5 µT से ज़्यादा नहीं होना चाहिए.
• [C-1-10] TYPE_MAGNETIC_FIELD_UNCALIBRATED सेंसर को लागू करना ज़रूरी है.

अगर डिवाइस में 3-ऐक्सिस मैग्नेटोमीटर, एक्सलरोमीटर सेंसर, और 3-ऐक्सिस जाइरोस्कोप सेंसर शामिल हैं, तो:

• [C-2-1] TYPE_ROTATION_VECTOR कंपोजिट सेंसर को लागू करना ज़रूरी है.

अगर डिवाइस में 3-ऐक्सिस मैग्नेटोमीटर और एक्सलरोमीटर शामिल हैं, तो:

• TYPE_GEOMAGNETIC_ROTATION_VECTOR सेंसर लागू किया जा सकता है.

अगर डिवाइस में 3-ऐक्सिस मैग्नेटोमीटर, एक्सलरोमीटर, और TYPE_GEOMAGNETIC_ROTATION_VECTOR सेंसर शामिल हैं, तो:

• [C-3-1] यह 10 mW से कम ऊर्जा का इस्तेमाल करता हो.
• जब सेंसर को 10 हर्ट्ज़ पर बैच मोड के लिए रजिस्टर किया गया हो, तो यह 3 एमडब्ल्यू से कम ऊर्जा का इस्तेमाल करना चाहिए.

7.3.3. जीपीएस

डिवाइस पर लागू करने के तरीके:

• [C-SR-1] हमारा सुझाव है कि आप जीपीएस/जीएनएसएस रिसीवर शामिल करें.

अगर डिवाइस में GPS/GNSS रिसीवर शामिल है और android.hardware.location.gps सुविधा फ़्लैग के ज़रिए ऐप्लिकेशन को इसकी जानकारी दी जाती है, तो:

• [C-1-1] LocationManager#requestLocationUpdate के ज़रिए अनुरोध किए जाने पर, जगह की जानकारी के आउटपुट कम से कम 1 हर्ट्ज़ की दर से मिलने चाहिए.
• [C-1-2] 0.5 एमबीपीएस या इससे तेज़ डेटा स्पीड वाले इंटरनेट कनेक्शन से कनेक्ट होने पर, खुले आसमान वाली जगहों पर (ज़्यादा सिग्नल, कम मल्टीपाथ, एचडीओपी < 2) 10 सेकंड (पहले फ़िक्स में लगने वाला कम समय) में जगह की जानकारी तय करनी चाहिए. आम तौर पर, इस ज़रूरी शर्त को पूरा करने के लिए, जीपीएस/जीएनएसएस लॉक-ऑन समय को कम करने के लिए, असिस्टेड या अनुमानित जीपीएस/जीएनएसएस तकनीक का इस्तेमाल किया जाता है. असिस्टेंस डेटा में, रेफ़रंस टाइम, रेफ़रंस लोकेशन, और सैटलाइट एफ़ेमेरिस/क्लॉक शामिल होते हैं.
  • [C-1-6] जगह की जानकारी का हिसाब लगाने के बाद, डिवाइस के लागू होने पर, जगह की जानकारी के अनुरोध फिर से शुरू होने पर, डिवाइस को खुले आसमान में, पांच सेकंड के अंदर अपनी जगह की जानकारी तय करनी चाहिए. यह जानकारी, जगह की जानकारी का पहला हिसाब लगाने के एक घंटे बाद तक तय की जानी चाहिए. भले ही, इसके बाद का अनुरोध, डेटा कनेक्शन के बिना और/या पावर साइकल के बाद किया गया हो.

• खुले आसमान में जगह का पता लगाने के बाद, एक मीटर प्रति सेकंड स्क्वेयर से कम की रफ़्तार से चलने या एक जगह पर खड़े होने पर:

  • [C-1-3] यह ज़रूरी है कि डिवाइस, कम से कम 95% समय तक, जगह की जानकारी 20 मीटर के अंदर और गति को 0.5 मीटर प्रति सेकंड के अंदर बता सके.
  • [C-1-4] एक ही कॉन्स्टेलेशन के कम से कम आठ उपग्रहों को एक साथ ट्रैक और GnssStatus.Callback के ज़रिए रिपोर्ट करना ज़रूरी है.
  • एक साथ कम से कम 24 सैटलाइट ट्रैक करने चाहिए. ये सैटलाइट, कई कॉन्स्टेलेशन (जैसे, जीपीएस + कम से कम एक Glonass, Beidou, Galileo) से होने चाहिए.

• [C-SR-2] हमारा सुझाव है कि आपातकालीन फ़ोन कॉल के दौरान, GNSS Location Provider API के ज़रिए सामान्य जीपीएस/जीएनएसएस जगह की जानकारी के आउटपुट डिलीवर करना जारी रखें.

• [C-SR-3] हमारा सुझाव है कि ट्रैक किए गए सभी कॉन्स्टेलेशन (जैसा कि GnssStatus मैसेज में बताया गया है) से मिले जीएनएसएस मेज़रमेंट की रिपोर्ट दी जाए. हालांकि, एसबीएएस को छोड़कर.

• [C-SR-4] हमारा सुझाव है कि आप एजीसी और जीएनएसएस से जुड़ी माप की फ़्रीक्वेंसी की जानकारी दें.

• [C-SR-5] हमारा सुझाव है कि हर जीपीएस/जीएनएसएस लोकेशन के हिस्से के तौर पर, सटीक जानकारी के सभी अनुमान (इनमें दिशा, स्पीड, और वर्टिकल शामिल हैं) की रिपोर्ट करें.

• [C-SR-6] हमारा सुझाव है कि जीएनएसएस मेज़रमेंट मिलने के तुरंत बाद, उन्हें रिपोर्ट करें. भले ही, जीपीएस/जीएनएसएस से कैलकुलेट की गई जगह की जानकारी अब तक रिपोर्ट न की गई हो.

• [C-SR-7] हमारा सुझाव है कि जीएनएसएस स्यूडोरेंज और स्यूडोरेंज रेट की जानकारी दें. ये ऐसे डेटा होते हैं जो खुले आसमान में जगह की जानकारी तय करने के बाद, गतिहीन या 0.2 मीटर प्रति सेकंड स्क्वेयर से कम की गति से चलने पर, कम से कम 95% समय में जगह की जानकारी 20 मीटर के अंदर और गति 0.2 मीटर प्रति सेकंड के अंदर का हिसाब लगाने के लिए काफ़ी होते हैं.

7.3.4. जाइरोस्कोप

डिवाइस पर लागू करने के तरीके:

• [C-SR-1] हमारा सुझाव है कि आप जाइरोस्कोप सेंसर शामिल करें.

अगर डिवाइस में जियोस्कोप की सुविधा है, तो:

• [C-1-1] यह ज़रूरी है कि डिवाइस कम से कम 50 हर्ट्ज़ तक की फ़्रीक्वेंसी वाले इवेंट की रिपोर्ट कर सके.
• [C-1-4] का रिज़ॉल्यूशन 12 बिट या उससे ज़्यादा होना चाहिए.
• [C-1-5] तापमान के हिसाब से अडजस्ट होना चाहिए.
• [C-1-6] इस्तेमाल के दौरान, कैलिब्रेट और कंपेसेशन करना ज़रूरी है. साथ ही, डिवाइस के रीबूट होने के बीच कंपेसेशन पैरामीटर को बनाए रखना ज़रूरी है.
• [C-1-7] हर हर्ट्ज़ के लिए, वैरिएंस 1e-7 rad^2 / s^2 से ज़्यादा नहीं होना चाहिए (हर हर्ट्ज़ के लिए वैरिएंस या rad^2 / s). वैरिएंस को सैंपलिंग रेट के हिसाब से बदलने की अनुमति है, लेकिन यह वैल्यू से ज़्यादा नहीं होना चाहिए. दूसरे शब्दों में, अगर 1 हर्ट्ज़ के सैंपलिंग रेट पर, घुमाव की दर का अंतर मापा जाता है, तो यह 1e-7 rad^2/s^2 से ज़्यादा नहीं होना चाहिए.
• [C-SR-2] हमारा सुझाव है कि जब डिवाइस कमरे के तापमान पर स्थिर हो, तो कैलिब्रेशन में होने वाली गड़बड़ी 0.01 रेडियन/सेकंड से कम हो.
• [C-SR-3] हमारा सुझाव है कि आपका रिज़ॉल्यूशन 16-बिट या इससे ज़्यादा हो.
• कम से कम 200 हर्ट्ज़ तक के इवेंट रिपोर्ट करने चाहिए.

अगर डिवाइस में 3-ऐक्सिस जाइरोस्कोप शामिल है, तो:

• [C-2-1] TYPE_GYROSCOPE सेंसर को लागू करना ज़रूरी है.
• [C-SR-4] TYPE_GYROSCOPE_UNCALIBRATED सेंसर को लागू करने का सुझाव दिया जाता है.

अगर डिवाइस में तीन से कम ऐक्सिस वाला गायरोस्कोप शामिल है, तो:

• [C-3-1] TYPE_GYROSCOPE_LIMITED_AXES सेंसर को लागू करना और उसकी रिपोर्ट देना ज़रूरी है.
• [C-SR-5] TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED सेंसर को लागू करने और उसकी रिपोर्ट करने का STRONGLY_RECOMMENDED.

अगर डिवाइस में 3-एक्सिस जाइरोस्कोप, एक्सलरोमीटर सेंसर, और मैग्नेटोमीटर सेंसर शामिल हैं, तो:

• [C-4-1] TYPE_ROTATION_VECTOR कंपोजिट सेंसर लागू करना ज़रूरी है.

अगर डिवाइस में 3-ऐक्सिस एक्सलरोमीटर और 3-ऐक्सिस जाइरोस्कोप सेंसर शामिल हैं, तो:

• [C-5-1] TYPE_GRAVITY और TYPE_LINEAR_ACCELERATION के कॉम्पोनेंट सेंसर लागू करने ज़रूरी हैं.
• [C-SR-6] हमारा सुझाव है कि आप TYPE_GAME_ROTATION_VECTOR कॉम्पोज़िट सेंसर को लागू करें.

7.3.5. बैरोमीटर

डिवाइस पर लागू करने के तरीके:

• [C-SR-1] हमारा सुझाव है कि आप बैरोमीटर (एंबियंट एयर प्रेशर सेंसर) शामिल करें.

अगर डिवाइस में बैरोमीटर शामिल है, तो:

• [C-1-1] TYPE_PRESSURE सेंसर को लागू करना और उसकी रिपोर्ट देना ज़रूरी है.
• [C-1-2] इवेंट को 5 हर्ट्ज़ या उससे ज़्यादा पर डिलीवर करना चाहिए.
• [C-1-3] तापमान के हिसाब से अडजस्ट होना चाहिए.
• [C-SR-2] हमारा सुझाव है कि आप 300hPa से 1100hPa की सीमा में, दबाव के मेज़रमेंट की जानकारी दें.
• यह 1hPa तक सटीक होना चाहिए.
• 20hPa की रेंज में, रिलेटिव सटीक 0.12hPa होनी चाहिए (समुद्र तल पर ~200m के बदलाव में ~1m की सटीक जानकारी).

7.3.6. Thermometer

अगर डिवाइस में आस-पास के तापमान को मापने वाला थर्मामीटर (तापमान सेंसर) शामिल है, तो:

• [C-1-1] एंबियंट तापमान सेंसर के लिए SENSOR_TYPE_AMBIENT_TEMPERATURE को ज़रूर तय करना चाहिए. साथ ही, सेंसर को उस जगह के एंबियंट (कमरे/वाहन के केबिन) तापमान को सेल्सियस डिग्री में मेज़र करना चाहिए जहां उपयोगकर्ता डिवाइस से इंटरैक्ट कर रहा है.

अगर डिवाइस में थर्मामीटर सेंसर शामिल है, जो आस-पास के तापमान के अलावा किसी और तापमान को मापता है, जैसे कि सीपीयू का तापमान, तो:

• [C-2-1] तापमान मापने वाले सेंसर के लिए, SENSOR_TYPE_AMBIENT_TEMPERATURE को तय नहीं किया जाना चाहिए.

अगर डिवाइस में त्वचा के तापमान को मॉनिटर करने के लिए सेंसर शामिल है, तो:

• [C-SR-1] हमारा सुझाव है कि आप PowerManager.getThermalHeadroom एपीआई का इस्तेमाल करें.

7.3.7. फ़ोटोमीटर

• डिवाइस में फ़ोटोमीटर (स्क्रीन की रोशनी को अपने-आप घटाने-बढ़ाने वाला सेंसर) शामिल हो सकता है.

7.3.8. निकटता सेंसर

• डिवाइस में लागू करने के लिए, प्रॉक्सिमिटी सेंसर का इस्तेमाल किया जा सकता है.

अगर डिवाइस में प्रॉक्सिमिटी सेंसर शामिल है और वह सिर्फ़ “पास” या “दूर” के बाइनरी रीडिंग की जानकारी देता है, तो:

• [C-1-1] किसी ऑब्जेक्ट की निकटता को उसी दिशा में मेज़र करना चाहिए जिस दिशा में स्क्रीन है. इसका मतलब है कि प्रॉक्सिमिटी सेंसर को स्क्रीन के आस-पास मौजूद ऑब्जेक्ट का पता लगाने के लिए ऑर्डर करना ज़रूरी है. इस तरह के सेंसर का मुख्य मकसद, उपयोगकर्ता के इस्तेमाल में मौजूद फ़ोन का पता लगाना होता है. अगर डिवाइस में किसी अन्य ओरिएंटेशन के साथ प्रोक्सिमिटी सेंसर शामिल है, तो उसे इस एपीआई के ज़रिए ऐक्सेस नहीं किया जा सकता.
• [C-1-2] सटीक जानकारी देने के लिए, 1 बिट या उससे ज़्यादा की जानकारी होनी चाहिए.
• [C-1-3] नियर रीडिंग के तौर पर 0 सेंटीमीटर और फ़ार रीडिंग के तौर पर 5 सेंटीमीटर का इस्तेमाल करना ज़रूरी है.
• [C-1-4] ज़्यादा से ज़्यादा पांच रेंज और रिज़ॉल्यूशन की रिपोर्ट करनी चाहिए.

7.3.9. हाई फ़िडेलिटी सेंसर

अगर डिवाइस में, इस सेक्शन में बताए गए तौर पर बेहतर क्वालिटी वाले सेंसर शामिल हैं और उन्हें तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराया जाता है, तो:

• [C-1-1] android.hardware.sensor.hifi_sensors फ़ीचर फ़्लैग के ज़रिए, सुविधा की पहचान करना ज़रूरी है.

अगर डिवाइस पर लागू किए गए बदलावों में android.hardware.sensor.hifi_sensors का एलान किया गया है, तो:

• [C-2-1] इसमें TYPE_ACCELEROMETER सेंसर होना चाहिए, जो:

  • मेज़रमेंट की रेंज कम से कम -8g से +8g के बीच होनी चाहिए. साथ ही, हमारा सुझाव है कि मेज़रमेंट की रेंज कम से कम -16g से +16g के बीच होनी चाहिए.
  • इसका मेज़रमेंट रिज़ॉल्यूशन कम से कम 2048 LSB/g होना चाहिए.
  • मेज़रमेंट फ़्रीक्वेंसी कम से कम 12.5 हर्ट्ज़ या उससे कम होनी चाहिए.
  • मेज़रमेंट फ़्रीक्वेंसी 400 हर्ट्ज़ या इससे ज़्यादा होनी चाहिए. साथ ही, SensorDirectChannel RATE_VERY_FAST के साथ काम करना चाहिए.
  • मेज़रमेंट नॉइज़ 400 μg/√Hz से ज़्यादा नहीं होना चाहिए.
  • इस सेंसर के लिए, कम से कम 3,000 सेंसर इवेंट को बफ़र करने की सुविधा के साथ, नॉन-वेक-अप फ़ॉर्म लागू करना ज़रूरी है.
  • बैचिंग के दौरान, डिवाइस की बिजली की खपत 3 mW से ज़्यादा नहीं होनी चाहिए.
  • [C-SR-1] हमारा सुझाव है कि 3dB मेज़रमेंट बैंडविड्थ, कम से कम 80% नक्विस्ट फ़्रीक्वेंसी हो. साथ ही, इस बैंडविड्थ में व्हाइट नॉइज़ स्पेक्ट्रम हो.
  • कमरे के तापमान पर जांचे गए ऐक्सेलरेशन रैंडम वॉक की वैल्यू 30 μg √Hz से कम होनी चाहिए.
  • तापमान के हिसाब से, बायस में बदलाव ≤ +/- 1 mg/°C होना चाहिए.
  • सबसे अच्छी फ़िट लाइन की गैर-लीनियरिटी ≤ 0.5% होनी चाहिए. साथ ही, तापमान के हिसाब से सेंसिटिविटी में बदलाव ≤ 0.03%/C° होना चाहिए.
  • क्रॉस-ऐक्सिस सेंसिटिविटी 2.5 % से कम होनी चाहिए. साथ ही, डिवाइस के ऑपरेशन के तापमान की रेंज में क्रॉस-ऐक्सिस सेंसिटिविटी में 0.2% से कम का अंतर होना चाहिए.

• [C-2-2] TYPE_ACCELEROMETER_UNCALIBRATED में TYPE_ACCELEROMETER जैसी ही क्वालिटी की ज़रूरी शर्तें होनी चाहिए.

• [C-2-3] इसमें TYPE_GYROSCOPE सेंसर होना चाहिए, जो:

  • मेज़रमेंट की रेंज कम से कम -1,000 से +1,000 डीपीएस के बीच होनी चाहिए.
  • मेज़रमेंट रिज़ॉल्यूशन कम से कम 16 LSB/dps होना चाहिए.
  • मेज़रमेंट फ़्रीक्वेंसी कम से कम 12.5 हर्ट्ज़ या उससे कम होनी चाहिए.
  • मेज़रमेंट फ़्रीक्वेंसी 400 हर्ट्ज़ या इससे ज़्यादा होनी चाहिए. साथ ही, SensorDirectChannel RATE_VERY_FAST के साथ काम करना चाहिए.
  • मेज़रमेंट नॉइज़ 0.014°/s/√Hz से ज़्यादा नहीं होना चाहिए.
  • [C-SR-2] हमारा सुझाव है कि 3dB मेज़रमेंट बैंडविड्थ, कम से कम 80% नक्विस्ट फ़्रीक्वेंसी हो. साथ ही, यह बैंडविड्थ, व्हाइट नॉइज़ स्पेक्ट्रम में हो.
  • कमरे के तापमान पर जांचे गए रेट रैंडम वॉक की वैल्यू 0.001 °/s √Hz से कम होनी चाहिए.
  • तापमान के हिसाब से, बायस में बदलाव ≤ +/- 0.05 °/ s / °C होना चाहिए.
  • तापमान के हिसाब से सेंसिविटी में होने वाला बदलाव, 0.02% / °C से कम होना चाहिए.
  • सबसे अच्छी फ़िट लाइन की नॉन-लीनियरिटी 0.2% से कम होनी चाहिए.
  • शोर की डेंसिटी 0.007 °/s/√Hz से कम होनी चाहिए.
  • डिवाइस के स्थिर होने पर, 10 से 40 डिग्री सेल्सियस के तापमान में कैलिब्रेशन की गड़बड़ी 0.002 रेडियन/सेकंड से कम होनी चाहिए.
  • जी-सेंसिटिविटी 0.1°/s/g से कम होनी चाहिए.
  • डिवाइस के ऑपरेशन के तापमान की रेंज में, क्रॉस-ऐक्सिस संवेदनशीलता का वैरिएशन 0.3 % से कम और क्रॉस-ऐक्सिस संवेदनशीलता 4.0% से कम होनी चाहिए.

• [C-2-4] TYPE_GYROSCOPE_UNCALIBRATED की क्वालिटी की वही शर्तें होनी चाहिए जो TYPE_GYROSCOPE के लिए हैं.

• [C-2-5] इसमें TYPE_GEOMAGNETIC_FIELD सेंसर होना चाहिए, जो:

  • मेज़रमेंट रेंज कम से कम -900 और +900 μT के बीच होनी चाहिए.
  • मेज़रमेंट का रिज़ॉल्यूशन कम से कम 5 LSB/uT होना चाहिए.
  • मेज़रमेंट फ़्रीक्वेंसी कम से कम 5 हर्ट्ज़ या उससे कम होनी चाहिए.
  • मेज़रमेंट की फ़्रीक्वेंसी 50 हर्ट्ज़ या इससे ज़्यादा होनी चाहिए.
  • मेज़रमेंट नॉइज़ 0.5 uT से ज़्यादा नहीं होना चाहिए.

• [C-2-6] TYPE_GEOMAGNETIC_FIELD की तरह ही क्वालिटी की ज़रूरी शर्तों वाला TYPE_MAGNETIC_FIELD_UNCALIBRATED होना चाहिए. इसके अलावा:

  • इस सेंसर के लिए, कम से कम 600 सेंसर इवेंट को बफ़र करने की सुविधा के साथ, नॉन-वेक-अप फ़ॉर्म लागू करना ज़रूरी है.
  • [C-SR-3] हमारा सुझाव है कि रिपोर्ट रेट 50 हर्ट्ज़ या उससे ज़्यादा होने पर, व्हाइट नॉइज़ स्पेक्ट्रम 1 हर्ट्ज़ से कम से कम 10 हर्ट्ज़ होना चाहिए.

• [C-2-7] इसमें TYPE_PRESSURE सेंसर होना चाहिए, जो:

  • मेज़रमेंट की रेंज कम से कम 300 और 1100 hPa के बीच होनी चाहिए.
  • माप का रिज़ॉल्यूशन कम से कम 80 LSB/hPa होना चाहिए.
  • मेज़रमेंट फ़्रीक्वेंसी कम से कम 1 हर्ट्ज़ या उससे कम होनी चाहिए.
  • मेज़रमेंट की फ़्रीक्वेंसी 10 हर्ट्ज़ या इससे ज़्यादा होनी चाहिए.
  • मेज़रमेंट नॉइज़ 2 Pa/√Hz से ज़्यादा नहीं होना चाहिए.
  • इस सेंसर के लिए, बिना 'जागने' वाले फ़ॉर्म को लागू करना ज़रूरी है. साथ ही, यह फ़ॉर्म कम से कम 300 सेंसर इवेंट को बफ़र करने की सुविधा के साथ होना चाहिए.
  • बैचिंग के दौरान बिजली की खपत 2 mW से ज़्यादा नहीं होनी चाहिए.

• [C-2-8] इसमें TYPE_GAME_ROTATION_VECTOR सेंसर होना चाहिए.

• [C-2-9] इसमें TYPE_SIGNIFICANT_MOTION सेंसर होना चाहिए, जो:

  • डिवाइस के स्टैटिक होने पर, बिजली की खपत 0.5 mW से ज़्यादा नहीं होनी चाहिए. साथ ही, डिवाइस के मूव होने पर, बिजली की खपत 1.5 mW से ज़्यादा नहीं होनी चाहिए.

• [C-2-10] इसमें TYPE_STEP_DETECTOR सेंसर होना चाहिए, जो:

  • इस सेंसर के लिए, बिना 'जागने' वाले फ़ॉर्म को लागू करना ज़रूरी है. साथ ही, यह फ़ॉर्म कम से कम 100 सेंसर इवेंट को बफ़र करने की सुविधा के साथ होना चाहिए.
  • डिवाइस के स्टैटिक होने पर, बिजली की खपत 0.5 mW से ज़्यादा नहीं होनी चाहिए. साथ ही, डिवाइस के मूव होने पर, बिजली की खपत 1.5 mW से ज़्यादा नहीं होनी चाहिए.
  • बैचिंग के दौरान बिजली की खपत 4 mW से ज़्यादा नहीं होनी चाहिए.

• [C-2-11] इसमें TYPE_STEP_COUNTER सेंसर होना चाहिए, जो:

  • डिवाइस के स्टैटिक होने पर, बिजली की खपत 0.5 mW से ज़्यादा नहीं होनी चाहिए. साथ ही, डिवाइस के मूव होने पर, बिजली की खपत 1.5 mW से ज़्यादा नहीं होनी चाहिए.

• [C-2-12] इसमें TILT_DETECTOR सेंसर होना चाहिए, जो:

  • डिवाइस के स्टैटिक होने पर, बिजली की खपत 0.5 mW से ज़्यादा नहीं होनी चाहिए. साथ ही, डिवाइस के मूव होने पर, बिजली की खपत 1.5 mW से ज़्यादा नहीं होनी चाहिए.

• [C-2-13] एक ही फ़िज़िकल इवेंट के लिए, Accelerometer, Gyroscope, और Magnetometer से मिले इवेंट टाइमस्टैंप में 2.5 मिलीसेकंड से ज़्यादा का अंतर नहीं होना चाहिए. एक ही फ़िज़िकल इवेंट के लिए, Accelerometer और Gyroscope से मिले टाइमस्टैंप में 0.25 मिलीसेकंड से ज़्यादा का अंतर नहीं होना चाहिए.

• [C-2-14] यह ज़रूरी है कि Gyroscope सेंसर इवेंट के टाइमस्टैंप, कैमरा सबसिस्टम के टाइमबेस के मुताबिक हों और गड़बड़ी 1 मिलीसेकंड के अंदर हो.

• [C-2-15] ऊपर दिए गए किसी भी फ़िज़िकल सेंसर पर डेटा उपलब्ध होने के बाद, ऐप्लिकेशन को सैंपल 5 मिलीसेकंड के अंदर डिलीवर करने होंगे.

• [C-2-16] डिवाइस के स्टैटिक होने पर, बिजली की खपत 0.5 mW से ज़्यादा और डिवाइस के चलने पर 2.0 mW से ज़्यादा नहीं होनी चाहिए. ऐसा तब होगा, जब इन सेंसर में से किसी भी कॉम्बिनेशन को चालू किया गया हो:

  • SENSOR_TYPE_SIGNIFICANT_MOTION
  • SENSOR_TYPE_STEP_DETECTOR
  • SENSOR_TYPE_STEP_COUNTER
  • SENSOR_TILT_DETECTORS

• [C-2-17] इसमें TYPE_PROXIMITY सेंसर हो सकता है. हालांकि, अगर सेंसर मौजूद है, तो कम से कम 100 सेंसर इवेंट का बफ़र होना चाहिए.

ध्यान दें कि इस सेक्शन में, बिजली खर्च से जुड़ी सभी ज़रूरी शर्तों में, ऐप्लिकेशन प्रोसेसर की बिजली खपत शामिल नहीं है. इसमें सेंसर चेन से खींची गई बिजली भी शामिल है. जैसे, सेंसर, सहायक सर्किट, सेंसर प्रोसेसिंग सिस्टम वगैरह.

अगर डिवाइस में सेंसर की सुविधा सीधे तौर पर काम करती है, तो:

• [C-3-1] isDirectChannelTypeSupported और getHighestDirectReportRateLevel एपीआई के ज़रिए, सीधे चैनल के टाइप और सीधे रिपोर्ट रेट के लेवल के लिए, सही तरीके से सहायता का एलान करना ज़रूरी है.
• [C-3-2] सेंसर डायरेक्ट चैनल के साथ काम करने वाले सभी सेंसर के लिए, सेंसर डायरेक्ट चैनल के कम से कम एक टाइप के साथ काम करना ज़रूरी है.
  • TYPE_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE
• यह सेंसर डायरेक्ट चैनल के ज़रिए इवेंट रिपोर्टिंग की सुविधा देनी चाहिए. यह सुविधा, इन टाइप के प्राइमरी सेंसर (नॉन-वेकअप वैरिएंट) के लिए होनी चाहिए:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. बायोमेट्रिक सेंसर

बायोमेट्रिक अनलॉक की सुरक्षा को मेज़र करने के बारे में ज़्यादा जानकारी के लिए, कृपया बायोमेट्रिक सुरक्षा को मेज़र करने से जुड़ा दस्तावेज़ देखें.

अगर डिवाइस में सुरक्षित लॉक स्क्रीन की सुविधा शामिल है, तो:

• इसमें बायोमेट्रिक सेंसर होना चाहिए

बायोमेट्रिक सेंसर को क्लास 3 (पहले इसे स्ट्रॉन्ग कहा जाता था), क्लास 2 (पहले इसे वीक कहा जाता था) या क्लास 1 (पहले इसे कंवेंनिएंस कहा जाता था) के तौर पर बांटा जा सकता है. यह बांटने का आधार, स्पूफ़ और झूठी पहचान स्वीकार करने की दरों के साथ-साथ, बायोमेट्रिक पाइपलाइन की सुरक्षा पर निर्भर करता है. इस कैटगरी से यह तय होता है कि प्लैटफ़ॉर्म और तीसरे पक्ष के ऐप्लिकेशन के साथ इंटरफ़ेस करने के लिए, बायोमेट्रिक सेंसर में कौनसी सुविधाएं होनी चाहिए. अगर सेंसर को क्लास 1, क्लास 2 या क्लास 3 के तौर पर बांटना है, तो उन्हें यहां दी गई अन्य ज़रूरी शर्तें पूरी करनी होंगी. क्लास 2 और क्लास 3, दोनों तरह के बायोमेट्रिक डेटा के लिए, यहां बताई गई अतिरिक्त सुविधाएं मिलती हैं.

अगर डिवाइस में android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt, और android.provider.Settings.ACTION_BIOMETRIC_ENROLL के ज़रिए, तीसरे पक्ष के ऐप्लिकेशन के लिए बायोमेट्रिक सेंसर उपलब्ध कराया जाता है, तो:

• [C-4-1] इस दस्तावेज़ में बताई गई क्लास 3 या क्लास 2 की बायोमेट्रिक ज़रूरी शर्तों को पूरा करना ज़रूरी है.
• [C-4-2] Authenticators क्लास में, हर पैरामीटर के नाम को एक कॉन्स्टेंट के तौर पर तय किया जाना चाहिए. साथ ही, इस नाम को पहचाना जाना चाहिए और इसका इस्तेमाल किया जाना चाहिए. इसके उलट, canAuthenticate(int) और setAllowedAuthenticators(int) तरीकों में, Authenticators में सार्वजनिक कॉन्स्टेंट के तौर पर दर्ज किए गए कॉन्स्टेंट के अलावा किसी और कॉन्स्टेंट को स्वीकार नहीं किया जाना चाहिए.
• [C-4-3] क्लास 3 या क्लास 2 बायोमेट्रिक्स वाले डिवाइसों पर, ACTION_BIOMETRIC_ENROLL कार्रवाई लागू करना ज़रूरी है. इस कार्रवाई में, सिर्फ़ क्लास 3 या क्लास 2 बायोमेट्रिक्स के लिए, रजिस्टर करने के एंट्री पॉइंट दिखाए जाने चाहिए.

अगर डिवाइस पर पैसिव बायोमेट्रिक्स की सुविधा काम करती है, तो:

• [C-5-1] डिफ़ॉल्ट रूप से, पुष्टि करने के लिए एक और चरण ज़रूर होना चाहिए. जैसे, बटन दबाना.
• [C-SR-1] हमारा सुझाव है कि आप ऐप्लिकेशन की प्राथमिकता को बदलने की अनुमति देने के लिए, एक सेटिंग उपलब्ध कराएं. साथ ही, पुष्टि करने के लिए उपयोगकर्ताओं को हमेशा एक चरण पूरा करना पड़े.
• [C-SR-2] हमारा सुझाव है कि पुष्टि करने की कार्रवाई को इस तरह से सुरक्षित किया जाए कि ऑपरेटिंग सिस्टम या कर्नेल में छेड़छाड़ करके, इस कार्रवाई को न बदला जा सके. उदाहरण के लिए, इसका मतलब है कि किसी बटन को दबाकर पुष्टि करने की कार्रवाई, सुरक्षित एलिमेंट (एसई) के सिर्फ़ इनपुट के लिए बने सामान्य-इस्तेमाल वाले इनपुट/आउटपुट (जीपीआईओ) पिन से रूट की जाती है. इस पिन को किसी बटन को दबाकर ही चालू किया जा सकता है.
• [C-5-2] इसके अलावा, setConfirmationRequired(boolean) के हिसाब से, पुष्टि के चरण के बिना, पुष्टि करने का फ़्लो लागू करना ज़रूरी है. ऐप्लिकेशन, साइन इन फ़्लो के लिए इसका इस्तेमाल कर सकते हैं.

अगर डिवाइस में एक से ज़्यादा बायोमेट्रिक सेंसर हैं, तो:

नई ज़रूरी शर्तें लागू करना

• [C-7-1] ज़रूरी है कि जब कोई बायोमेट्रिक लॉकआउट में हो (जैसे, जब तक उपयोगकर्ता मुख्य ऑथेंटिकेशन की मदद से अनलॉक नहीं करता, तब तक बायोमेट्रिक बंद रहता है) या समयसीमा के हिसाब से लॉकआउट (जैसे, जब तक उपयोगकर्ता किसी तय समय के लिए इंतज़ार नहीं करता, तब तक बायोमेट्रिक बंद रहता है), तो कम बायोमेट्रिक क्लास की सभी अन्य बायोमेट्रिक को भी लॉक आउट कर दे. तय समय के लिए लॉकआउट करने की सुविधा के मामले में, बायोमेट्रिक पुष्टि के लिए बैकऑफ़ समय, तय समय के लिए लॉकआउट करने की सुविधा में मौजूद सभी बायोमेट्रिक के लिए बैकऑफ़ समय से ज़्यादा होना चाहिए.

• [C-SR-12] जब किसी बायोमेट्रिक को लॉक आउट किया गया हो (जैसे, जब उपयोगकर्ता मुख्य ऑथेंटिकेशन की मदद से अनलॉक करने तक बायोमेट्रिक बंद हो) या समयसीमा के हिसाब से लॉक आउट किया गया हो (जैसे, जब उपयोगकर्ता किसी तय समय तक इंतज़ार करने तक बायोमेट्रिक बंद हो), तो एक ही बायोमेट्रिक क्लास के सभी बायोमेट्रिक को लॉक आउट करने के लिए, ऐसा करने का ज़रूर सुझाव दिया जाता है. समयसीमा वाले लॉकआउट के मामले में, हमारा सुझाव है कि बायोमेट्रिक पुष्टि के लिए बैकऑफ़ समय, समयसीमा वाले लॉकआउट में सभी बायोमेट्रिक के लिए ज़्यादा से ज़्यादा बैकऑफ़ समय हो.

• [C-7-2] लॉक आउट होने वाले बायोमेट्रिक आइटम के लिए लॉकआउट काउंटर को रीसेट करने के लिए, उपयोगकर्ता को पुष्टि करने के लिए सुझाए गए मुख्य तरीके (जैसे: पिन, पैटर्न, पासवर्ड) का इस्तेमाल करना ज़रूरी है. क्लास 3 बायोमेट्रिक की मदद से, लॉक किए गए उसी या उससे कम क्लास के बायोमेट्रिक के लिए, लॉकआउट काउंटर को रीसेट किया जा सकता है. क्लास 2 या क्लास 1 बायोमेट्रिक्स को किसी भी बायोमेट्रिक्स के लिए, लॉकआउट रीसेट करने की अनुमति नहीं दी जानी चाहिए.

नई ज़रूरी शर्तों को खत्म करना

• [C-SR-3] हमारा सुझाव है कि पुष्टि करने के लिए, सिर्फ़ एक बायोमेट्रिक डेटा की ज़रूरत हो. उदाहरण के लिए, अगर डिवाइस पर फ़िंगरप्रिंट और चेहरे के सेंसर, दोनों उपलब्ध हैं, तो onAuthenticationSucceeded को इनमें से किसी एक की पुष्टि होने के बाद भेजा जाना चाहिए.

डिवाइस में लागू किए गए तरीके से, तीसरे पक्ष के ऐप्लिकेशन को पासकोड की कुंजियों का ऐक्सेस देने के लिए, ये ज़रूरी हैं:

• [C-6-1] इसे नीचे दिए गए सेक्शन में बताई गई तीसरी कैटगरी की ज़रूरी शर्तों को पूरा करना होगा.
• [C-6-2] अगर पुष्टि के लिए BIOMETRIC_STRONG की ज़रूरत है या पुष्टि करने के लिए CryptoObject का इस्तेमाल किया जाता है, तो सिर्फ़ क्लास 3 बायोमेट्रिक की जानकारी देनी होगी.

अगर डिवाइस में बायोमेट्रिक सेंसर को क्लास 1 (पहले इसे सुविधा कहा जाता था) के तौर पर इस्तेमाल करना है, तो:

• [C-1-1] गलत स्वीकार किए जाने की दर 0.002% से कम होनी चाहिए.
• [C-1-2] यह ज़रूरी है कि यह बताया जाए कि यह मोड, किसी मुश्किल पिन, पैटर्न या पासवर्ड के मुकाबले कम सुरक्षित हो सकता है. साथ ही, अगर Android बायोमेट्रिक्स टेस्ट प्रोटोकॉल के हिसाब से, किसी दूसरे व्यक्ति के डिवाइस पर फ़ेस अनलॉक की सुविधा इस्तेमाल करने की दर 7% से ज़्यादा है, तो इस मोड को चालू करने से जुड़े जोखिमों के बारे में साफ़ तौर पर बताया जाना चाहिए.
• [C-1-9] उपयोगकर्ता को 20 से ज़्यादा बार गलत तरीके से पुष्टि करने की कोशिश करने के बाद, सुझाए गए मुख्य पुष्टि करने के तरीके (जैसे, पिन, पैटर्न, पासवर्ड) के लिए ज़रूर चुनौती देनी चाहिए.साथ ही, बायोमेट्रिक पुष्टि के लिए, 90 सेकंड से कम का बैकऑफ़ समय होना चाहिए. गलत तरीके से पुष्टि करने की कोशिश करने का मतलब है कि कैप्चर की गई क्वालिटी (BIOMETRIC_ACQUIRED_GOOD) अच्छी है, लेकिन वह रजिस्टर की गई बायोमेट्रिक जानकारी से मेल नहीं खाती.
• [C-SR-4] अगर Android बायोमेट्रिक्स टेस्ट प्रोटोकॉल के हिसाब से, स्पूफ़ और इंपोस्टर स्वीकार करने की दर 7% से ज़्यादा है, तो [C-1-9] में बताई गई बायोमेट्रिक पुष्टि के लिए, गलत कोशिशों की कुल संख्या कम करने का सुझाव दिया जाता है.
• [C-1-3] बायोमेट्रिक पुष्टि के लिए, कोशिशों की दर को सीमित करना ज़रूरी है - जहां गलत कोशिश का मतलब है कि कैप्चर की गई क्वालिटी (BIOMETRIC_ACQUIRED_GOOD) ठीक है, लेकिन वह रजिस्टर की गई बायोमेट्रिक जानकारी से मेल नहीं खाती.
• [C-SR-5] हमारा सुझाव है कि बायोमेट्रिक पुष्टि के लिए, पांच बार गलत तरीके से कोशिश करने के बाद, कम से कम 30 सेकंड के लिए कोशिश करने की दर को सीमित कर दें. ऐसा [C-1-9] में बताई गई, गलत तरीके से कोशिश करने की ज़्यादा से ज़्यादा संख्या के लिए किया जाना चाहिए. गलत तरीके से कोशिश करने का मतलब है, कैप्चर की गई अच्छी क्वालिटी (BIOMETRIC_ACQUIRED_GOOD) का डेटा, रजिस्टर किए गए बायोमेट्रिक डेटा से मेल न खाना.
• [C-SR-6] हमारा सुझाव है कि टीईई में, दर को सीमित करने का पूरा लॉजिक शामिल करें.

• [C-1-10] मुख्य ऑथेंटिकेशन बैकऑफ़ ट्रिगर होने के बाद, बायोमेट्रिक ऑथेंटिकेशन की सुविधा बंद करनी ज़रूरी है. इस बारे में, सेक्शन 9.11 के [C-0-2] में बताया गया है.

• [C-1-11] स्पूफ़ और इंपोस्टर स्वीकार करने की दर 30% से ज़्यादा नहीं होनी चाहिए. साथ ही, (1) लेवल A के प्रज़ेंटेशन अटैक इंस्ट्रूमेंट (पीएआई) प्रजाति के लिए स्पूफ़ और इंपोस्टर स्वीकार करने की दर 30% से ज़्यादा नहीं होनी चाहिए और (2) लेवल B के पीएआई प्रजाति के लिए स्पूफ़ और इंपोस्टर स्वीकार करने की दर 40% से ज़्यादा नहीं होनी चाहिए. इसे Android के बायोमेट्रिक टेस्ट प्रोटोकॉल से मेज़र किया जाता है.

• [C-1-4] उपयोगकर्ता को मौजूदा पुष्टि करने या TEE से सुरक्षित डिवाइस क्रेडेंशियल (पिन/पैटर्न/पासवर्ड) जोड़ने के लिए कहकर, भरोसे की चेन सेट अप किए बिना, नई बायोमेट्रिक्स जोड़ने से रोकना ज़रूरी है. Android Open Source Project के लागू होने से, ऐसा करने के लिए फ़्रेमवर्क में एक तरीका मिलता है.

• [C-1-5] उपयोगकर्ता का खाता हटाने पर, उपयोगकर्ता की पहचान ज़ाहिर करने वाला सारा बायोमेट्रिक डेटा पूरी तरह से हटाना ज़रूरी है. इसमें फ़ैक्ट्री रीसेट करने पर भी ऐसा करना ज़रूरी है.

• [C-1-6] उस बायोमेट्रिक के लिए, अलग-अलग फ़्लैग का इस्तेमाल करना ज़रूरी है. जैसे, DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE , या DevicePolicymanager.KEYGUARD_DISABLE_IRIS .

• [C-1-7] उपयोगकर्ता को हर 24 घंटे या उससे कम समय में, सुझाई गई पुष्टि करने के लिए ज़रूर कहा जाना चाहिए. जैसे, पिन, पैटर्न, पासवर्ड. ध्यान दें: Android 9 या उससे पहले के वर्शन पर लॉन्च किए गए डिवाइसों को अपग्रेड करने के लिए, उपयोगकर्ता को हर 72 घंटे या उससे कम समय में, सुझाई गई मुख्य पुष्टि करने की सुविधा (जैसे, पिन, पैटर्न, पासवर्ड) का इस्तेमाल करना होगा.

• [C-1-8] उपयोगकर्ता को इनमें से किसी एक स्थिति के बाद, सुझाई गई मुख्य पुष्टि करने के लिए चुनौती देनी चाहिए (उदाहरण के लिए: पिन, पैटर्न, पासवर्ड) या क्लास 3 (बेहतर) बायोमेट्रिक पुष्टि करने के लिए चुनौती देनी चाहिए:

  • चार घंटे तक इस्तेमाल में न रहने पर टाइम आउट की अवधि, या
  • बायोमेट्रिक ऑथेंटिकेशन की तीन बार कोशिश करने के बाद भी पुष्टि नहीं हो सकी.
  • डिवाइस के क्रेडेंशियल की पुष्टि होने के बाद, डिवाइस के इस्तेमाल में न होने पर टाइम आउट की अवधि और पुष्टि न होने की संख्या रीसेट हो जाती है. ध्यान दें: Android 9 या उससे पहले के वर्शन पर लॉन्च किए गए डिवाइसों को अपग्रेड करने पर, हो सकता है कि उन्हें C-1-8 से छूट मिल जाए.

• [C-SR-7] नए डिवाइसों के लिए, [C-1-7] और [C-1-8] में बताई गई पाबंदियों को लागू करने के लिए, Android Open Source Project के फ़्रेमवर्क में दिए गए लॉजिक का इस्तेमाल करने का ज़रूर सुझाव दिया जाता है.

• [C-SR-8] हमारा सुझाव है कि डिवाइस पर मेज़र किए गए फ़ॉल्स रिजेक्शन रेट (गलत तरीके से अस्वीकार किए जाने की दर) 10% से कम हो.

• [C-SR-9] हमारा सुझाव है कि रजिस्टर की गई हर बायोमेट्रिक जानकारी के लिए, रिस्पॉन्स में लगने वाला समय एक सेकंड से कम हो. यह समय, बायोमेट्रिक जानकारी का पता चलने से लेकर स्क्रीन अनलॉक होने तक के समय को मेज़र करके निकाला जाता है.

नई ज़रूरी शर्तें लागू करना

• [C-1-12] Android बायोमेट्रिक्स टेस्ट प्रोटोकॉल के मुताबिक, प्रज़ेंटेशन अटैक इंस्ट्रूमेंट (पीएआई) की हर प्रजाति के लिए, स्पूफ़ और इंपोस्टर स्वीकार करने की दर 40% से ज़्यादा नहीं होनी चाहिए.

• [C-SR-13] हमारा सुझाव है कि Android बायोमेट्रिक्स टेस्ट प्रोटोकॉल के हिसाब से, प्रज़ेंटेशन अटैक इंस्ट्रूमेंट (पीएआई) के हिसाब से, स्पूफ़ और इंपोस्टर स्वीकार करने की दर 30% से ज़्यादा न हो.

• [C-SR-14] हमारा सुझाव है कि आप बायोमेट्रिक सेंसर की क्लास और उसे चालू करने से जुड़े जोखिमों के बारे में बताएं.

• [C-SR-17] हमारा सुझाव है कि आप नए AIDL इंटरफ़ेस (जैसे, IFace.aidl और IFingerprint.aidl) लागू करें.

नई ज़रूरी शर्तें खत्म करना

अगर डिवाइस में बायोमेट्रिक सेंसर को क्लास 2 (पहले इसे कम सुरक्षित कहा जाता था) के तौर पर इस्तेमाल करना है, तो:

• [C-2-1] यह ज़रूरी है कि आपका ऐप्लिकेशन, ऊपर बताई गई क्लास 1 की सभी ज़रूरी शर्तें पूरी करता हो.

• [C-2-2] स्पूफ़ और इंपोस्टर स्वीकार करने की दर 20% से ज़्यादा नहीं होनी चाहिए. इसमें (1) लेवल A के प्रज़ेंटेशन अटैक इंस्ट्रूमेंट (पीएआई) टाइप के लिए स्पूफ़ और इंपोस्टर स्वीकार करने की दर 20% से ज़्यादा नहीं होनी चाहिए और (2) लेवल B के पीएआई टाइप के लिए स्पूफ़ और इंपोस्टर स्वीकार करने की दर 30% से ज़्यादा नहीं होनी चाहिए. इसे Android बायोमेट्रिक्स टेस्ट प्रोटोकॉल से मेज़र किया जाता है.

नई ज़रूरी शर्तें लागू करना

• [C-SR-15] हमारा सुझाव है कि Android बायोमेट्रिक्स टेस्ट प्रोटोकॉल के हिसाब से, प्रज़ेंटेशन अटैक इंस्ट्रूमेंट (पीएआई) के हर टाइप के लिए, स्पूफ़ और इंपोस्टर स्वीकार करने की दर 20% से ज़्यादा न हो.

नई ज़रूरी शर्तें खत्म करना

• [C-2-3] बायोमेट्रिक मैचिंग की प्रोसेस, Android उपयोगकर्ता या कर्नेल स्पेस के बाहर, किसी अलग सेटअप किए गए एक्ज़ीक्यूशन एनवायरमेंट में की जानी चाहिए. जैसे, ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट (टीईई), या किसी ऐसी चिप पर जिसका अलग सेटअप किया गया एक्ज़ीक्यूशन एनवायरमेंट से सुरक्षित चैनल हो या सेक्शन 9.17 में दी गई ज़रूरी शर्तें पूरी करने वाली सुरक्षित वर्चुअल मशीन पर.
• [C-2-4] पहचाने जा सकने वाले सभी डेटा को एन्क्रिप्ट (सुरक्षित) करना ज़रूरी है. साथ ही, क्रिप्टोग्राफ़ी की मदद से पुष्टि करना ज़रूरी है, ताकि उसे अलग से चलाए जाने वाले प्रोसेसिंग एनवायरमेंट या अलग से चलाए जाने वाले प्रोसेसिंग एनवायरमेंट के लिए सुरक्षित चैनल वाले चिप के बाहर हासिल, पढ़ा या बदला न जा सके. इस बारे में, Android Open Source Project की साइट पर लागू करने के दिशा-निर्देशों में बताया गया है. इसके अलावा, हाइपरवाइजर से कंट्रोल की जाने वाली ऐसी सुरक्षित वर्चुअल मशीन भी हो सकती है जो सेक्शन 9.17 की ज़रूरी शर्तों को पूरा करती हो.
• [C-2-5] कैमरे पर आधारित बायोमेट्रिक्स के लिए, बायोमेट्रिक ऑथेंटिकेशन या रजिस्टर करने के दौरान:
  • कैमरे को ऐसे मोड में चलाना ज़रूरी है जिससे कैमरे के फ़्रेम को, अलग से चलाए जा रहे प्रोग्राम के एनवायरमेंट के बाहर न पढ़ा जा सके या उनमें बदलाव न किया जा सके. इसके अलावा, कैमरे को ऐसे चिप के साथ चलाना ज़रूरी है जिसमें अलग से चलाए जा रहे प्रोग्राम के एनवायरमेंट के लिए सुरक्षित चैनल हो. इसके अलावा, कैमरे को ऐसी सुरक्षित वर्चुअल मशीन के साथ चलाना ज़रूरी है जिसे हाइपरवाइजर कंट्रोल करता हो और जो सेक्शन 9.17 में दी गई ज़रूरी शर्तों को पूरा करती हो.
  • आरजीबी सिंगल-कैमरा सलूशन के लिए, कैमरे के फ़्रेम को अलग से चलाए जाने वाले एनवायरमेंट के बाहर पढ़ा जा सकता है. इससे, रजिस्ट्रेशन के लिए झलक देखने जैसे कामों में मदद मिलती है. हालांकि, इन फ़्रेम में बदलाव नहीं किया जा सकता.
• [C-2-6] तीसरे पक्ष के ऐप्लिकेशन को, अलग-अलग बायोमेट्रिक डेटा के बीच अंतर करने की अनुमति नहीं दी जानी चाहिए.
• [C-2-7] ऐप्लिकेशन प्रोसेसर को, TEE के संदर्भ के बाहर, पहचान ज़ाहिर करने वाले बायोमेट्रिक डेटा या उससे मिले किसी भी डेटा (जैसे, एम्बेड किए गए डेटा) को अनक्रिप्ट किए बिना ऐक्सेस करने की अनुमति नहीं देनी चाहिए. इसके अलावा, ऐप्लिकेशन प्रोसेसर को, हाइपरवाइजर के कंट्रोल वाली सुरक्षित वर्चुअल मशीन के संदर्भ के बाहर, पहचान ज़ाहिर करने वाले बायोमेट्रिक डेटा या उससे मिले किसी भी डेटा (जैसे, एम्बेड किए गए डेटा) को अनक्रिप्ट किए बिना ऐक्सेस करने की अनुमति नहीं देनी चाहिए. यह वर्चुअल मशीन, सेक्शन 9.17 में दी गई ज़रूरी शर्तों को पूरा करती हो. Android के 9 या इससे पहले के वर्शन पर लॉन्च किए गए डिवाइसों को C-2-7 से छूट नहीं दी गई है.

• [C-2-8] प्रोसेसिंग की सुरक्षित पाइपलाइन होनी चाहिए, ताकि ऑपरेटिंग सिस्टम या कोर में हुए बदलाव से, डेटा को सीधे तौर पर इंजेक्ट करके, उपयोगकर्ता के तौर पर झूठी पुष्टि न की जा सके. ध्यान दें: अगर डिवाइस पर Android के 9 या उससे पहले के वर्शन पर पहले से ही सुविधाएं लागू हैं और सिस्टम सॉफ़्टवेयर के अपडेट की मदद से, C-2-8 की ज़रूरी शर्त को पूरा नहीं किया जा सकता, तो हो सकता है कि उन्हें इस शर्त से छूट दी जाए.

• [C-SR-10] हमारा सुझाव है कि सभी बायोमेट्रिक मोड में, 'लाइवनेस की पहचान' और चेहरे की पहचान करने वाली सुविधा में, 'ध्यान देने की पहचान' शामिल करें.

• [C-2-9] तीसरे पक्ष के ऐप्लिकेशन के लिए, बायोमेट्रिक सेंसर को उपलब्ध कराना ज़रूरी है.

अगर डिवाइस में बायोमेट्रिक सेंसर को क्लास 3 (पहले इसे स्ट्रॉन्ग कहा जाता था) के तौर पर इस्तेमाल करना है, तो:

• [C-3-1] को ऊपर बताई गई क्लास 2 की सभी ज़रूरी शर्तें पूरी करनी होंगी. हालांकि, [C-1-7] और [C-1-8] को छोड़कर.
• [C-3-2] इसमें हार्डवेयर के साथ काम करने वाला पासकोड स्टोर होना चाहिए.
• [C-3-3] स्पूफ़ और इंपोस्टर स्वीकार करने की दर 7% से ज़्यादा नहीं होनी चाहिए. इसमें (1) लेवल A के प्रज़ेंटेशन अटैक इंस्ट्रूमेंट (पीएआई) टाइप के लिए स्पूफ़ और इंपोस्टर स्वीकार करने की दर 7% से ज़्यादा नहीं होनी चाहिए और (2) लेवल B के पीएआई टाइप के लिए स्पूफ़ और इंपोस्टर स्वीकार करने की दर 20% से ज़्यादा नहीं होनी चाहिए. इन दरों को Android बायोमेट्रिक टेस्ट प्रोटोकॉल से मेज़र किया जाता है.
• [C-3-4] उपयोगकर्ता को हर 72 घंटे या उससे कम समय में, सुझाई गई पुष्टि करने की मुख्य विधि (जैसे, पिन, पैटर्न, पासवर्ड) के लिए ज़रूर चुनौती देनी चाहिए.
• [C-3-5] अगर डिवाइस पर काम करने वाली क्लास 3 की सभी बायोमेट्रिक सुविधाओं में से किसी एक को फिर से रजिस्टर किया जाता है, तो Authenticator आईडी को फिर से जनरेट करना ज़रूरी है.
• [C-3-6] तीसरे पक्ष के ऐप्लिकेशन के लिए, बायोमेट्रिक तरीके से सुरक्षित की गई पासकोड वाली कुंजियों को चालू करना ज़रूरी है.

नई ज़रूरी शर्तें लागू करना

• [C-SR-16] हमारा सुझाव है कि Android बायोमेट्रिक्स टेस्ट प्रोटोकॉल के हिसाब से, प्रज़ेंटेशन अटैक इंस्ट्रूमेंट (पीएआई) के हिसाब से, स्पूफ़ और इंपोस्टर स्वीकार करने की दर 7% से ज़्यादा नहीं होनी चाहिए.

नई ज़रूरी शर्तें खत्म करना

अगर डिवाइस में डिसप्ले में मौजूद फ़िंगरप्रिंट सेंसर (UDFPS) है, तो:

• [C-SR-11] हमारा सुझाव है कि यूडीएफ़पीएस के टच किए जा सकने वाले हिस्से को, तीन बटन वाले नेविगेशन से अलग रखें. ऐसा इसलिए, क्योंकि कुछ उपयोगकर्ताओं को ऐक्सेस के मकसद से तीन बटन वाले नेविगेशन की ज़रूरत पड़ सकती है.

7.3.11. आसन का पता लगाने वाला सेंसर

डिवाइस पर लागू करने के तरीके:

• हो सकता है कि यह 6 डिग्री ऑफ़ फ़्रीडम वाले पोज़ सेंसर के साथ काम करे.

अगर डिवाइस पर, पोज़ सेंसर की सुविधा 6 डिग्री ऑफ़ फ़्रीडम के साथ काम करती है, तो:

• [C-1-1] TYPE_POSE_6DOF सेंसर को लागू करना और उसकी रिपोर्ट देना ज़रूरी है.
• [C-1-2] यह सिर्फ़ रोटेशन वेक्टर के मुकाबले ज़्यादा सटीक होना चाहिए.

7.3.12. हिंज ऐंगल सेंसर

अगर डिवाइस में हिंज ऐंगल सेंसर की सुविधा काम करती है, तो:

• [C-1-1] TYPE_HINGLE_ANGLE को लागू करना और उसकी रिपोर्ट करना ज़रूरी है.
• [C-1-2] यह ज़रूरी है कि डिवाइस, 0 से 360 डिग्री के बीच कम से कम दो रीडिंग दिखाता हो.
• [C-1-3] getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE) के लिए, जागने वाला सेंसर दिखाना ज़रूरी है.

7.3.13. आईईईई 802.1.15.4 (यूडब्ल्यूबी)

अगर डिवाइस में 802.1.15.4 के साथ काम करने की सुविधा शामिल है और तीसरे पक्ष के ऐप्लिकेशन के लिए इस सुविधा को उपलब्ध कराया गया है, तो:

नई ज़रूरी शर्तें लागू करना

• [C-1-2] हार्डवेयर की सुविधा के फ़्लैग android.hardware.uwb की जानकारी देना ज़रूरी है.
• [C-1-3] यह ज़रूरी है कि यह AOSP के लागू होने के दौरान तय किए गए, यहां दिए गए सभी कॉन्फ़िगरेशन सेट (FIRA UCI पैरामीटर के पहले से तय किए गए कॉम्बिनेशन) के साथ काम करे.
  • CONFIG_ID_1: FiRa के मुताबिक यूनीकास्ट STATIC STS DS-TWR रेंजिंग, डिफ़र्ड मोड, रेंजिंग इंटरवल 240 मिलीसेकंड.
  • CONFIG_ID_2: FiRa के मुताबिक, एक से ज़्यादा डिवाइसों के लिए STATIC STS DS-TWR रेंजिंग, डिफ़र्ड मोड, रेंजिंग इंटरवल 200 मिलीसेकंड. इस्तेमाल का सामान्य उदाहरण: स्मार्ट फ़ोन, कई स्मार्ट डिवाइसों के साथ इंटरैक्ट करता है.
  • CONFIG_ID_3: CONFIG_ID_1 जैसा ही, सिवाय इसके कि आने के कोण (AoA) का डेटा रिपोर्ट नहीं किया जाता.
  • CONFIG_ID_4: CONFIG_ID_1 जैसा ही, सिवाय इसके कि P-STS सिक्योरिटी मोड चालू है.
  • CONFIG_ID_5: CONFIG_ID_2 जैसा ही, सिवाय इसके कि P-STS सिक्योरिटी मोड चालू है.
  • CONFIG_ID_6: CONFIG_ID_3 जैसा ही, सिवाय इसके कि P-STS सिक्योरिटी मोड चालू है.
  • CONFIG_ID_7: CONFIG_ID_2 जैसा ही, सिवाय इसके कि P-STS के लिए, कंट्रोल किए जाने वाले व्यक्ति का अलग-अलग पासकोड मोड चालू है.
• [C-1-4] उपयोगकर्ता को UWB रेडियो की स्थिति को चालू/बंद करने की अनुमति देने के लिए, उपयोगकर्ता के लिए सुविधा उपलब्ध कराना ज़रूरी है.
• [C-1-5] यह ज़रूरी है कि UWB रेडियो का इस्तेमाल करने वाले ऐप्लिकेशन के पास, NEARBY_DEVICES अनुमति ग्रुप के तहत UWB_RANGING अनुमति हो.

FIRA, CCC, और CSA जैसे स्टैंडर्ड ऑर्गनाइज़ेशन के तय किए गए, ज़रूरी नियमों और सर्टिफ़िकेट से जुड़े टेस्ट पास करने से, यह पक्का करने में मदद मिलती है कि 802.1.15.4 सही तरीके से काम कर रहा है.

नई ज़रूरी शर्तें खत्म करना

7.4. डेटा कनेक्टिविटी

7.4.1. टेलीफ़ोनी

Android API और इस दस्तावेज़ में, “टेलीफ़ोन” का इस्तेमाल खास तौर पर, वॉइस कॉल करने और एसएमएस भेजने से जुड़े हार्डवेयर के लिए किया गया है. इसके अलावा, मोबाइल (जैसे, GSM, CDMA, LTE, NR) या CDMA नेटवर्क के ज़रिए मोबाइल डेटा सेट अप करने के लिए भी इसका इस्तेमाल किया जाता है. “टेलीफ़ोन” की सुविधा वाले डिवाइस में, प्रॉडक्ट के हिसाब से कॉल, मैसेजिंग, और डेटा सेवाओं में से कुछ या सभी को उपलब्ध कराया जा सकता है.

जीएसएम या सीडीएमए नेटवर्क के ज़रिए. ये वॉइस कॉल, पैकेट-स्विच किए जा सकते हैं या नहीं, लेकिन Android के लिए इन्हें उसी नेटवर्क का इस्तेमाल करके लागू की जाने वाली किसी भी डेटा कनेक्टिविटी से अलग माना जाता है. दूसरे शब्दों में, Android की “टेलीफ़ोन” सुविधा और एपीआई, खास तौर पर वॉइस कॉल और एसएमएस के बारे में बताते हैं. उदाहरण के लिए, ऐसे डिवाइसों को टेलीफ़ोन डिवाइस नहीं माना जाता जिनसे कॉल नहीं किए जा सकते या एसएमएस नहीं भेजे और पाए जा सकते. भले ही, वे डेटा कनेक्टिविटी के लिए सेल्युलर नेटवर्क का इस्तेमाल करते हों.

• Android का इस्तेमाल ऐसे डिवाइसों पर किया जा सकता है जिनमें टेलीफ़ोन हार्डवेयर शामिल नहीं है. इसका मतलब है कि Android, फ़ोन के अलावा दूसरे डिवाइसों पर भी काम करता है.

अगर डिवाइस में जीएसएम या सीडीएमए टेलीफ़ोनी शामिल है, तो:

• [C-1-1] तकनीक के हिसाब से, android.hardware.telephony फ़ीचर फ़्लैग और अन्य सब-फ़ीचर फ़्लैग का एलान करना ज़रूरी है.
• [C-1-2] उस टेक्नोलॉजी के लिए, एपीआई की पूरी सहायता लागू करना ज़रूरी है.
• आपातकालीन कॉल के दौरान, सभी उपलब्ध मोबाइल सेवाओं (2G, 3G, 4G, 5G वगैरह) का इस्तेमाल किया जा सकता है. भले ही, SetAllowedNetworkTypeBitmap() नेटवर्क के टाइप तय किए हों.

अगर डिवाइस में टेलीफ़ोन हार्डवेयर शामिल नहीं है, तो:

• [C-2-1] सभी एपीआई को नो-ऑप के तौर पर लागू करना ज़रूरी है.

अगर डिवाइस में eUICC या ई-सिम/एम्बेड किए गए सिम की सुविधाएं काम करती हैं और तीसरे पक्ष के डेवलपर के लिए ई-सिम की सुविधा उपलब्ध कराने के लिए, मालिकाना हक वाला कोई तरीका शामिल है, तो:

• [C-3-1] android.hardware.telephony.euicc फ़ीचर फ़्लैग के बारे में एलान करना ज़रूरी है.

अगर डिवाइस पर लागू करने की प्रोसेस, सिस्टम प्रॉपर्टी ro.telephony.iwlan\_operation\_mode को 'लेगसी' पर सेट नहीं करती है, तो:

• [C-4-1] जब एक ही NetworkRegistrationInfo इंस्टेंस के लिए, NetworkRegistrationInfo#getTransportType() को 'TRANSPORT_TYPE_WWAN' के तौर पर रिपोर्ट किया जाता है, तो NetworkRegistrationInfo#getAccessNetworkTechnology() के ज़रिए 'NETWORK_TYPE_IWLAN' को रिपोर्ट नहीं किया जाना चाहिए.

अगर डिवाइस में मल्टीमीडिया टेलीफ़ोन सेवा (एमएमटीईएल) और रिच कम्यूनिकेशन सेवा (आरसीएस) दोनों सुविधाओं के लिए, एक ही आईपी मल्टीमीडिया सबसिस्टम (आईएमएस) रजिस्ट्रेशन का इस्तेमाल किया जा सकता है और सभी आईएमएस सिग्नल ट्रैफ़िक के लिए, एक ही आईएमएस रजिस्ट्रेशन का इस्तेमाल करने से जुड़ी मोबाइल और इंटरनेट सेवा देने वाली कंपनी की ज़रूरी शर्तों का पालन किया जा सकता है, तो:

• [C-5-1] android.hardware.telephony.ims सुविधा फ़्लैग का एलान करना ज़रूरी है. साथ ही, MMTEL और आरसीएस User Capability Exchange API, दोनों के लिए ImsService API को पूरी तरह से लागू करना ज़रूरी है.
• [C-5-2] android.hardware.telephony.ims.singlereg सुविधा फ़्लैग का एलान करना ज़रूरी है. साथ ही, SipTransport API, GbaService API, और IRadio 1.6 HAL का इस्तेमाल करके, डिवाइस के लिए खास तौर पर बने बियरर इंंडिकेशन के साथ-साथ, ऑटो कॉन्फ़िगरेशन सर्वर (एसीएस) या IMS कॉन्फ़िगरेशन एपीआई का इस्तेमाल करके, प्रोवाइज़न करने की अन्य मालिकाना सुविधाओं को पूरी तरह से लागू करना ज़रूरी है.

अगर डिवाइस पर android.hardware.telephony सुविधा लागू करने पर, इसकी शिकायत की जाती है, तो:

• [C-6-1] टेक्स्ट मैसेज भेजने की सुविधा देने के लिए, SmsManager#sendTextMessage और SmsManager#sendMultipartTextMessage के लिए, CarrierMessagingService को कॉल करना ज़रूरी है. मल्टीमीडिया मैसेजिंग की सुविधा देने के लिए, SmsManager#sendMultimediaMessage और SmsManager#downloadMultimediaMessage के लिए, CarrierMessagingService को कॉल भेजना ज़रूरी है.
• [C-6-2] android.provider.Telephony.Sms#getDefaultSmsPackage के ज़रिए तय किए गए ऐप्लिकेशन को, एसएमएस और मल्टीमीडिया मैसेज (एमएमएस) भेजने और पाने के लिए, SmsManager एपीआई का इस्तेमाल करना ज़रूरी है. पैकेज/ऐप्लिकेशन/Messaging में AOSP रेफ़रंस लागू करने से, यह ज़रूरी शर्त पूरी हो जाती है.
• [C-6-3] Intent#ACTION_DIAL के जवाब देने वाले ऐप्लिकेशन में, *#*#CODE#*#* के तौर पर फ़ॉर्मैट किए गए डायलर कोड डालने की सुविधा होनी चाहिए. साथ ही, उससे जुड़ा TelephonyManager#ACTION_SECRET_CODE ब्रॉडकास्ट ट्रिगर होना चाहिए.
• [C-6-4] अगर ऐप्लिकेशन में विज़ुअल वॉइसमेल ट्रांसक्रिप्शन की सुविधा काम करती है, तो उपयोगकर्ताओं को विज़ुअल वॉइसमेल ट्रांसक्रिप्शन दिखाने के लिए, Intent#ACTION_DIAL के जवाब देने वाले ऐप्लिकेशन को VoicemailContract.Voicemails#TRANSCRIPTION का इस्तेमाल करना होगा.
• [C-6-5] उपयोगकर्ता को दिखने वाले सभी ऐसे फ़ंक्शन में, एक ही सदस्यता के तौर पर सभी SubscriptionInfo को एक जैसे ग्रुप UUIDs के साथ दिखाना ज़रूरी है जो SIM कार्ड की जानकारी दिखाते और कंट्रोल करते हैं. ऐसे अवसरों के उदाहरणों में, सेटिंग इंटरफ़ेस शामिल हैं जो Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS या EuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS से मेल खाते हैं.
• [C-6-6] उपयोगकर्ता को दिखने वाले किसी भी ऐसे फ़ंक्शन में, ग्रुप UUID और ऑपर्च्यूनिस्टिक बिट के साथ, SubscriptionInfo को न दिखाएं या कंट्रोल करने की अनुमति न दें जो सिम कार्ड की सेटिंग को कॉन्फ़िगर या कंट्रोल करने की अनुमति देता हो.

अगर डिवाइस पर android.hardware.telephony सुविधा लागू की गई है और सिस्टम स्टेटस बार उपलब्ध है, तो:

• [C-7-1] किसी दिए गए ग्रुप UUID के लिए, उपयोगकर्ता को सिम की स्थिति की जानकारी देने वाले किसी भी अवसर पर दिखाने के लिए, एक प्रतिनिधि ऐक्टिव सदस्यता चुनना ज़रूरी है. ऐसे उदाहरणों में, स्टेटस बार में मौजूद मोबाइल नेटवर्क सिग्नल का आइकॉन या क्विक सेटिंग टाइल शामिल है.
• [C-SR-1] हमारा सुझाव है कि प्रतिनिधि की सदस्यता को ऐक्टिव डेटा सदस्यता के तौर पर चुना जाए. ऐसा तब तक करें, जब तक डिवाइस पर कोई वॉइस कॉल न हो. अगर डिवाइस पर कोई वॉइस कॉल चल रहा है, तो हमारा सुझाव है कि प्रतिनिधि की सदस्यता को ऐक्टिव वॉइस सदस्यता के तौर पर चुना जाए.

अगर डिवाइस पर android.hardware.telephony सुविधा लागू करने पर, इसकी शिकायत की जाती है, तो:

• [C-6-7] यह ज़रूरी है कि यह ETSI TS 102 221 के मुताबिक, हर यूआईसीसी के लिए ज़्यादा से ज़्यादा लॉजिकल चैनल (कुल 20) खोल सके और एक साथ उनका इस्तेमाल कर सके.
• [C-6-8] चालू मोबाइल और इंटरनेट सेवा देने वाली कंपनी के ऐप्लिकेशन (TelephonyManager#getCarrierServicePackageName के मुताबिक) पर, इनमें से कोई भी कार्रवाई अपने-आप या उपयोगकर्ता की साफ़ तौर पर पुष्टि किए बिना नहीं की जानी चाहिए:
  • नेटवर्क का ऐक्सेस रद्द करना या सीमित करना
  • अनुमतियां वापस लेना
  • AOSP में मौजूद, पावर मैनेजमेंट की मौजूदा सुविधाओं के अलावा, बैकग्राउंड या फ़ोरग्राउंड में ऐप्लिकेशन के चलने पर पाबंदी लगाना
  • ऐप्लिकेशन को बंद या अनइंस्टॉल करना

अगर डिवाइस पर android.hardware.telephony सुविधा लागू होने की जानकारी मिलती है और ग्रुप UUID शेयर करने वाली सभी चालू, ऑपर्चुनिस्टिक सदस्यताएं बंद कर दी जाती हैं, डिवाइस से हटा दी जाती हैं या उन्हें ऑपर्चुनिस्टिक के तौर पर मार्क कर दिया जाता है, तो डिवाइस:

• [C-8-1] एक ही ग्रुप में, बाकी बची सभी चालू ऑपर्चुनिस्टिक सदस्यताओं को अपने-आप बंद कर देना चाहिए.

अगर डिवाइस में जीएसएम टेलीफ़ोन सेवा शामिल है, लेकिन सीडीएमए टेलीफ़ोन सेवा शामिल नहीं है, तो:

• [C-9-1] PackageManager#FEATURE_TELEPHONY_CDMA का एलान नहीं किया जाना चाहिए.
• [C-9-2] पसंदीदा या अनुमति वाले नेटवर्क टाइप के बिटमास्क में, 3GPP2 नेटवर्क टाइप सेट करने की कोशिश करने पर, IllegalArgumentException दिखाना ज़रूरी है.
• [C-9-3] TelephonyManager#getMeid से खाली स्ट्रिंग दिखानी चाहिए.

अगर डिवाइस में एक से ज़्यादा पोर्ट और प्रोफ़ाइलों वाले eUICC का इस्तेमाल किया जा सकता है, तो:

• [C-10-1] android.hardware.telephony.euicc.mep के लिए, ज़रूरी है कि आप android.hardware.telephony.euicc.mep के फ़ीचर फ़्लैग का एलान करें.

7.4.1.1. नंबर ब्लॉक करने की सुविधा के साथ काम करने वाले डिवाइस

अगर डिवाइस पर android.hardware.telephony.calling सुविधा लागू की गई है, तो:

• [C-1-1] इसमें नंबर ब्लॉक करने की सुविधा शामिल होनी चाहिए
• [C-1-2] SDK टूल के दस्तावेज़ में बताए गए तरीके से, BlockedNumberContract और उससे जुड़े एपीआई को पूरी तरह से लागू करना ज़रूरी है.

• [C-1-3] 'BlockedNumberProvider' में मौजूद किसी फ़ोन नंबर से आने वाले सभी कॉल और मैसेज को ब्लॉक करना ज़रूरी है. इसके लिए, ऐप्लिकेशन के साथ इंटरैक्ट करने की ज़रूरत नहीं है. हालांकि, SDK दस्तावेज़ में बताए गए तरीके के मुताबिक, नंबर ब्लॉक करने की सुविधा को कुछ समय के लिए हटाने पर, यह शर्त लागू नहीं होती.

• [C-1-4] ब्लॉक किए गए कॉल के लिए, प्लैटफ़ॉर्म के कॉल लॉग की सेवा देने वाली कंपनी को लिखना ज़रूरी है. साथ ही, पहले से इंस्टॉल किए गए डायलर ऐप्लिकेशन में, डिफ़ॉल्ट कॉल लॉग व्यू से BLOCKED_TYPE वाले कॉल को फ़िल्टर करना ज़रूरी है.

• [C-1-5] ब्लॉक किए गए मैसेज के लिए, टेलीफ़ोनी सेवा देने वाली कंपनी को पत्र नहीं लिखना चाहिए.

• [C-1-6] ब्लॉक किए गए नंबरों को मैनेज करने के लिए यूज़र इंटरफ़ेस (यूआई) लागू करना ज़रूरी है. यह यूआई, TelecomManager.createManageBlockedNumbersIntent() मैथड से मिले इंटेंट के साथ खुलता है.

• [C-1-7] डिवाइस पर दूसरे उपयोगकर्ताओं को ब्लॉक किए गए नंबर देखने या उनमें बदलाव करने की अनुमति नहीं दी जानी चाहिए. ऐसा इसलिए, क्योंकि Android प्लैटफ़ॉर्म यह मानता है कि डिवाइस पर टेलीफ़ोन सेवाओं का पूरा कंट्रोल, प्राइमरी उपयोगकर्ता के पास होता है. सेकंडरी उपयोगकर्ताओं के लिए, ब्लॉक करने से जुड़ा सारा यूज़र इंटरफ़ेस (यूआई) छिपाया जाना चाहिए. साथ ही, ब्लॉक की गई सूची को भी लागू रखना चाहिए.

• जब कोई डिवाइस Android 7.0 पर अपडेट होता है, तो ब्लॉक किए गए नंबरों को सेवा देने वाली कंपनी के पास माइग्रेट करना चाहिए.

• पहले से इंस्टॉल किए गए डायलर ऐप्लिकेशन में, ब्लॉक किए गए कॉल दिखाने के लिए उपयोगकर्ता को सुविधा देनी चाहिए.

7.4.1.2. Telecom API

अगर डिवाइस पर लागू करने की रिपोर्ट में android.hardware.telephony.calling दिखता है, तो:

• [C-1-1] SDK में बताए गए ConnectionService एपीआई के साथ काम करना चाहिए.
• [C-1-2] जब उपयोगकर्ता किसी तीसरे पक्ष के ऐसे ऐप्लिकेशन से कॉल पर हो जो CAPABILITY_SUPPORT_HOLD के ज़रिए बताई गई, कॉल को होल्ड करने की सुविधा के साथ काम नहीं करता, तो ऐप्लिकेशन को नया इनकमिंग कॉल दिखाना चाहिए. साथ ही, उपयोगकर्ता को इनकमिंग कॉल स्वीकार या अस्वीकार करने का विकल्प देना चाहिए.
• [C-1-3] इसमें ऐसा ऐप्लिकेशन होना चाहिए जो InCallService को लागू करता हो.

• [C-SR-1] हमारा सुझाव है कि उपयोगकर्ता को सूचना दी जाए कि आने वाले कॉल का जवाब देने पर, चल रहे कॉल को बंद कर दिया जाएगा.

  AOSP में, हेड्स-अप सूचना की मदद से इन ज़रूरी शर्तों को पूरा किया जाता है. इससे उपयोगकर्ता को यह पता चलता है कि किसी इनकमिंग कॉल का जवाब देने पर, दूसरा कॉल बंद हो जाएगा.

• [C-SR-2] हमारा सुझाव है कि डिफ़ॉल्ट डायलर ऐप्लिकेशन को पहले से लोड करें. ऐसा इसलिए, क्योंकि जब तीसरे पक्ष का ऐप्लिकेशन EXTRA_LOG_SELF_MANAGED_CALLS के एक्सट्रा बटन को PhoneAccount से true पर सेट करता है, तो डिफ़ॉल्ट डायलर ऐप्लिकेशन के कॉल लॉग में कॉल लॉग की एंट्री और तीसरे पक्ष के ऐप्लिकेशन का नाम दिखता है.

• [C-SR-3] हमारा सुझाव है कि आप android.telecom एपीआई के लिए, ऑडियो हेडसेट के KEYCODE_MEDIA_PLAY_PAUSE और KEYCODE_HEADSETHOOK इवेंट को यहां बताए गए तरीके से मैनेज करें:

  • कॉल के दौरान, मुख्य इवेंट को कुछ समय के लिए दबाने पर, Connection.onDisconnect() कॉल करें.
  • आने वाले कॉल के दौरान, मुख्य इवेंट को कुछ समय के लिए दबाने पर, Connection.onAnswer() कॉल करें.
  • आने वाले कॉल के दौरान, मुख्य इवेंट को दबाकर रखने पर, Connection.onReject() को कॉल करें.
  • CallAudioState को म्यूट करने की स्थिति को टॉगल करें.

7.4.1.3. सेल्युलर NAT-T Keepalive Offload

डिवाइस पर लागू करने के तरीके:

• इसमें मोबाइल डेटा के ज़रिए keepalive ऑफ़लोड करने की सुविधा शामिल होनी चाहिए.

अगर डिवाइस में सेल्युलर keepalive ऑफ़लोड की सुविधा शामिल है और वह तीसरे पक्ष के ऐप्लिकेशन के लिए इस सुविधा को उपलब्ध कराता है, तो:

• [C-1-1] यह SocketKeepAlive API के साथ काम करना चाहिए.
• [C-1-2] यह ज़रूरी है कि यह सेल्युलर नेटवर्क पर, कम से कम एक साथ एक 'कीप ऐलिव' स्लॉट के साथ काम करे.
• [C-1-3] यह ज़रूरी है कि यह Cellular Radio HAL के साथ काम करने वाले उतने ही सेल्युलर 'काइलिप्स' स्लॉट के साथ काम करे जितने कि Cellular Radio HAL के साथ काम करते हैं.
• [C-SR-1] हमारा सुझाव है कि हर रेडियो इंस्टेंस के लिए, कम से कम तीन सेल्युलर 'काइलिप्स' स्लॉट का इस्तेमाल किया जाए.

अगर डिवाइस में सेल्युलर keepalive ऑफ़लोड की सुविधा शामिल नहीं है, तो:

• [C-2-1] ERROR_UNSUPPORTED दिखाना ज़रूरी है.

7.4.2. आईईईई 802.11 (वाई-फ़ाई)

डिवाइस पर लागू करने के तरीके:

• इसमें 802.11 के एक या एक से ज़्यादा फ़ॉर्मैट के लिए सहायता शामिल होनी चाहिए.

अगर डिवाइस में 802.11 के साथ काम करने की सुविधा शामिल है और तीसरे पक्ष के ऐप्लिकेशन के लिए इस सुविधा को उपलब्ध कराया गया है, तो:

• [C-1-1] आपको उससे जुड़ा Android API लागू करना होगा.
• [C-1-2] हार्डवेयर की सुविधा के फ़्लैग android.hardware.wifi की जानकारी देना ज़रूरी है.
• [C-1-3] SDK के दस्तावेज़ में बताए गए तरीके के मुताबिक, मल्टीकास्ट एपीआई को लागू करना ज़रूरी है.
• [C-1-4] मल्टीकास्ट डीएनएस (mDNS) के साथ काम करना चाहिए. साथ ही, स्क्रीन के चालू न होने पर भी, mDNS पैकेट (224.0.0.251 या ff02::fb) को कभी भी फ़िल्टर नहीं करना चाहिए. हालांकि, टारगेट किए गए बाज़ार पर लागू होने वाली नियमों के मुताबिक, बिजली की खपत की तय सीमा के अंदर रहने के लिए, इन पैकेट को ड्रॉप या फ़िल्टर करना ज़रूरी हो सकता है. Android Television डिवाइस पर लागू करने के लिए, भले ही डिवाइस स्टैंडबाय मोड में हो.
• [C-1-5] WifiManager.enableNetwork() एपीआई के तरीके के कॉल को, फ़िलहाल चालू Network को स्विच करने के लिए, ज़रूरी संकेत के तौर पर नहीं माना जाना चाहिए. Network का इस्तेमाल, ऐप्लिकेशन ट्रैफ़िक के लिए डिफ़ॉल्ट रूप से किया जाता है और इसे ConnectivityManager एपीआई के तरीकों से दिखाया जाता है. जैसे, getActiveNetwork और registerDefaultNetworkCallback. दूसरे शब्दों में, अगर डिवाइस पर वाई-फ़ाई नेटवर्क से इंटरनेट ऐक्सेस मिल रहा है, तो डिवाइस पर किसी दूसरे नेटवर्क सेवा देने वाली कंपनी (जैसे, मोबाइल डेटा) से मिलने वाले इंटरनेट ऐक्सेस को बंद किया जा सकता है.
• [C-1-6] हमारा सुझाव है कि जब ConnectivityManager.reportNetworkConnectivity() एपीआई मेथड को कॉल किया जाए, तो Network पर इंटरनेट ऐक्सेस की फिर से जांच करें. जांच के बाद, अगर पता चलता है कि मौजूदा Network पर इंटरनेट ऐक्सेस नहीं है, तो इंटरनेट ऐक्सेस देने वाले किसी दूसरे उपलब्ध नेटवर्क (जैसे, मोबाइल डेटा) पर स्विच करें.
• [C-1-7] जब STA डिसकनेक्ट हो, तो हर स्कैन की शुरुआत में, प्रोब अनुरोध फ़्रेम के सोर्स मैक पते और क्रम संख्या को रैंडम क्रम में रखना ज़रूरी है.
• [C-1-8] एक ही मैक पते का इस्तेमाल करना ज़रूरी है. स्कैन के बीच में मैक पते को बदलना नहीं चाहिए.
• [C-1-9] स्कैन में, प्रोब अनुरोधों के बीच, प्रोब अनुरोध के क्रम की संख्या को सामान्य (क्रम से) दोहराना ज़रूरी है.
• [C-1-10] किसी स्कैन के आखिरी प्रोब अनुरोध और अगले स्कैन के पहले प्रोब अनुरोध के बीच, प्रोब अनुरोध के क्रम की संख्या को रैंडम क्रम में रखना ज़रूरी है.
• [C-SR-1] हमारा सुझाव है कि एसटीए को ऐक्सेस पॉइंट (एपी) से कनेक्ट करने और कनेक्ट होने के दौरान, एसटीए के सभी कम्यूनिकेशन के लिए इस्तेमाल किए जाने वाले सोर्स एमएसी पते को बदलें.
  • डिवाइस को हर उस एसएसआईडी (Passpoint के लिए FQDN) के लिए, किसी भी क्रम में लगाए गए अलग-अलग मैक पते का इस्तेमाल करना होगा जिससे वह संपर्क करता है.
  • डिवाइस में उपयोगकर्ता को यह कंट्रोल करने का विकल्प होना चाहिए कि हर एसएसआईडी (Passpoint के लिए FQDN) के लिए, रैंडमाइज़ेशन की सुविधा चालू हो या नहीं. इसके लिए, रैंडमाइज़ेशन की सुविधा के साथ-साथ, रैंडमाइज़ेशन की सुविधा के बिना भी विकल्प उपलब्ध कराए जाने चाहिए. साथ ही, डिवाइस में नए वाई-फ़ाई कॉन्फ़िगरेशन के लिए, रैंडमाइज़ेशन की सुविधा को डिफ़ॉल्ट मोड पर सेट किया जाना चाहिए.
• [C-SR-2] हमारा सुझाव है कि वे अपने बनाए गए हर एपी के लिए, कोई भी रैंडम बीएसएसआईडी इस्तेमाल करें.
  • मैक पता अपने-आप जनरेट होना चाहिए और एपी के इस्तेमाल किए गए हर एसएसआईडी के लिए सेव रहना चाहिए.
  • डिवाइस, उपयोगकर्ता को इस सुविधा को बंद करने का विकल्प दे सकता है. अगर ऐसा विकल्प दिया जाता है, तो रैंडमाइज़ेशन की सुविधा डिफ़ॉल्ट रूप से चालू होनी चाहिए.

अगर डिवाइस में, IEEE 802.11 स्टैंडर्ड के मुताबिक वाई-फ़ाई पावर सेव मोड की सुविधा शामिल है, तो:

• जब भी कोई ऐप्लिकेशन WifiManager.createWifiLock() और WifiManager.WifiLock.acquire() एपीआई के ज़रिए WIFI_MODE_FULL_HIGH_PERF लॉक या WIFI_MODE_FULL_LOW_LATENCY लॉक हासिल करता है और लॉक चालू होता है, तो वाई-फ़ाई पावर सेव मोड को बंद करना चाहिए.
• [C-3-2] डिवाइस के वाई-फ़ाई कम इंतज़ार वाला लॉक (WIFI_MODE_FULL_LOW_LATENCY) मोड चालू होने पर, डिवाइस और ऐक्सेस पॉइंट के बीच औसत राउंड ट्रिप इंतज़ार का समय, वाई-फ़ाई बेहतर परफ़ॉर्मेंस वाला लॉक (WIFI_MODE_FULL_HIGH_PERF) मोड चालू होने पर, डिवाइस और ऐक्सेस पॉइंट के बीच औसत राउंड ट्रिप इंतज़ार के समय से कम होना चाहिए.
• [C-SR-3] हमारा सुझाव है कि जब भी कम इंतज़ार वाला लॉक (WIFI_MODE_FULL_LOW_LATENCY) हासिल किया जाए और लागू हो जाए, तो वाई-फ़ाई के राउंड ट्रिप के इंतज़ार को कम करें.

अगर डिवाइस पर वाई-फ़ाई काम करता है और जगह की जानकारी स्कैन करने के लिए वाई-फ़ाई का इस्तेमाल किया जाता है, तो:

• [C-2-1] WifiManager.isScanAlwaysAvailable एपीआई के तरीके से, वैल्यू पढ़ने की सुविधा को चालू/बंद करने के लिए, उपयोगकर्ता को कोई सुविधा देना ज़रूरी है.

7.4.2.1. Wi-Fi Direct

डिवाइस पर लागू करने के तरीके:

• इसमें वाई-फ़ाई डायरेक्ट (वाई-फ़ाई पीयर-टू-पीयर) की सुविधा शामिल होनी चाहिए.

अगर डिवाइस में वाई-फ़ाई डायरेक्ट की सुविधा काम करती है, तो:

• [C-1-1] SDK टूल के दस्तावेज़ में बताए गए तरीके के मुताबिक, उससे जुड़ा Android API लागू करना ज़रूरी है.
• [C-1-2] हार्डवेयर की सुविधा android.hardware.wifi.direct की जानकारी ज़रूर दें.
• [C-1-3] डिवाइस पर वाई-फ़ाई की सुविधा काम करती हो.
• [C-1-4] यह ज़रूरी है कि डिवाइस पर वाई-फ़ाई और वाई-फ़ाई डायरेक्ट, दोनों एक साथ काम करते हों.
• [C-SR-1] हमारा सुझाव है कि नए वाई-फ़ाई डायरेक्ट कनेक्शन के लिए, सोर्स एमएसी पते को बदलें.

7.4.2.2. वाई-फ़ाई टनल वाला डायरेक्ट लिंक सेटअप करना

डिवाइस पर लागू करने के तरीके:

• इसमें Wi-Fi टनल किए गए डायरेक्ट लिंक सेटअप (TDLS) के लिए सहायता शामिल होनी चाहिए, जैसा कि Android SDK टूल के दस्तावेज़ में बताया गया है.

अगर डिवाइस में TDLS की सुविधा शामिल है और WiFiManager API ने TDLS को चालू किया है, तो:

• [C-1-1] WifiManager.isTdlsSupported के ज़रिए, यह ज़रूर बताना चाहिए कि टीडीएलएस की सुविधा काम करती है.
• TDLS का इस्तेमाल सिर्फ़ तब करना चाहिए, जब यह मुमकिन हो और फ़ायदेमंद हो.
• इसमें कुछ हेयुरिस्टिक्स होने चाहिए और जब TDLS की परफ़ॉर्मेंस, वाई-फ़ाई ऐक्सेस पॉइंट से कनेक्ट होने की परफ़ॉर्मेंस से खराब हो, तब इसका इस्तेमाल नहीं किया जाना चाहिए.

7.4.2.3. वाई-फ़ाई अवेयर

डिवाइस पर लागू करने के तरीके:

• इसमें Wi-Fi Aware के लिए सहायता शामिल होनी चाहिए.

अगर डिवाइस में वाई-फ़ाई अवेयर की सुविधा शामिल है और तीसरे पक्ष के ऐप्लिकेशन के लिए इस सुविधा का ऐक्सेस दिया गया है, तो:

• [C-1-1] WifiAwareManager एपीआई को SDK टूल के दस्तावेज़ में बताए गए तरीके से लागू करना ज़रूरी है.
• [C-1-2] android.hardware.wifi.aware फ़ीचर फ़्लैग का एलान करना ज़रूरी है.
• [C-1-3] यह ज़रूरी है कि डिवाइस पर वाई-फ़ाई और वाई-फ़ाई अवेयर, दोनों एक साथ काम कर सकें.
• [C-1-4] वाई-फ़ाई अवेयर मैनेजमेंट इंटरफ़ेस के पते को 30 मिनट से ज़्यादा के अंतराल पर और वाई-फ़ाई अवेयर के चालू होने पर, रैंडमाइज़ करना ज़रूरी है. ऐसा तब तक करना होगा, जब तक अवेयर रेंजिंग ऑपरेशन चल रहा है या अवेयर डेटा-पाथ चालू है. जब तक डेटा-पाथ चालू है, तब तक रैंडमाइज़ेशन नहीं किया जाना चाहिए.

अगर डिवाइस में सेक्शन 7.4.2.5 में बताए गए तरीके से, वाई-फ़ाई अवेयर और वाई-फ़ाई लोकेशन की सुविधाएं काम करती हैं और ये सुविधाएं तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध हैं, तो:

• [C-2-1] जगह की जानकारी के हिसाब से काम करने वाले डिस्कवरी एपीआई लागू करना ज़रूरी है: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm , और onServiceDiscoveredWithinRange.

7.4.2.4. वाई-फ़ाई पासपॉइंट

अगर डिवाइस में 802.11 (वाई-फ़ाई) की सुविधा काम करती है, तो:

• [C-1-1] इसमें Wi-Fi Passpoint के लिए सहायता शामिल होनी चाहिए.
• [C-1-2] SDK टूल के दस्तावेज़ में बताए गए तरीके के मुताबिक, Passpoint से जुड़े WifiManager एपीआई लागू करना ज़रूरी है.
• [C-1-3] यह ज़रूरी है कि डिवाइस, IEEE 802.11u स्टैंडर्ड के साथ काम करे. यह स्टैंडर्ड, नेटवर्क डिस्कवरी और नेटवर्क चुनने से जुड़ा है. जैसे, सामान्य विज्ञापन सेवा (जीएएस) और ऐक्सेस नेटवर्क क्वेरी प्रोटोकॉल (एएनक्यूपी).
• [C-1-4] android.hardware.wifi.passpoint फ़ीचर फ़्लैग का एलान करना ज़रूरी है.
• [C-1-5] पासपॉइंट नेटवर्क ढूंढने, मैच करने, और उनसे जुड़ने के लिए, AOSP के लागू होने का पालन करना ज़रूरी है.
• [C-1-6] यह ज़रूरी है कि यह डिवाइस को कॉन्फ़िगर करने के लिए, Wi-Fi Alliance Passpoint R2 में बताए गए प्रोटोकॉल के कम से कम इन सबसेट के साथ काम करे: EAP-TTLS पुष्टि करने की सुविधा और SOAP-XML.
• [C-1-7] Hotspot 2.0 R3 स्पेसिफ़िकेशन में बताए गए तरीके के मुताबिक, एएए सर्वर सर्टिफ़िकेट को प्रोसेस करना ज़रूरी है.
• [C-1-8] वाई-फ़ाई पिकर की मदद से, उपयोगकर्ता को प्रावधान करने की सुविधा को कंट्रोल करने की सुविधा होनी चाहिए.
• [C-1-9] रीबूट के बाद भी, Passpoint कॉन्फ़िगरेशन को बनाए रखना ज़रूरी है.
• [C-SR-1] नियमों और शर्तों को स्वीकार करने की सुविधा के साथ काम करने का सुझाव दिया जाता है.
• [C-SR-2] हमारा सुझाव है कि आप जगह की जानकारी देने वाली सुविधा का इस्तेमाल करें.

अगर Passpoint को बंद करने के लिए, उपयोगकर्ता के कंट्रोल वाला ग्लोबल स्विच उपलब्ध कराया जाता है, तो इसे लागू करने के लिए:

• [C-3-1] Passpoint को डिफ़ॉल्ट रूप से चालू करना ज़रूरी है.

7.4.2.5. वाई-फ़ाई की जगह की जानकारी (वाई-फ़ाई का राउंड ट्रिप टाइम - आरटीटी)

डिवाइस पर लागू करने के तरीके:

• इसमें वाई-फ़ाई लोकेशन की सुविधा शामिल होनी चाहिए.

अगर डिवाइस में वाई-फ़ाई लोकेशन की सुविधा काम करती है और तीसरे पक्ष के ऐप्लिकेशन के लिए इस सुविधा का ऐक्सेस उपलब्ध कराया जाता है, तो:

• [C-1-1] WifiRttManager एपीआई को SDK टूल के दस्तावेज़ में बताए गए तरीके से लागू करना ज़रूरी है.
• [C-1-2] android.hardware.wifi.rtt फ़ीचर फ़्लैग का एलान करना ज़रूरी है.
• [C-1-3] हर उस आरटीटी बर्स्ट के लिए सोर्स एमएसी पते को रैंडमाइज़ करना ज़रूरी है जो उस वाई-फ़ाई इंटरफ़ेस पर किया जाता है जिस पर आरटीटी किया जा रहा है और जो किसी ऐक्सेस पॉइंट से जुड़ा नहीं है.
• [C-1-4] 68वें प्रतिशत में, 80 मेगाहर्ट्ज़ बैंडविड्थ पर, 2 मीटर के अंदर सटीक होना चाहिए (जैसा कि क्युम्युलटिव डिस्ट्रिब्यूशन फ़ंक्शन के साथ कैलकुलेट किया गया है).
• [C-SR-1] हमारा सुझाव है कि आप 80 मेगाहर्ट्ज़ बैंडविड्थ पर, 68वें प्रतिशत में (जैसा कि संचयी डिस्ट्रिब्यूशन फ़ंक्शन के साथ कैलकुलेट किया गया है) 1.5 मीटर के अंदर, सटीक तौर पर रिपोर्ट करें.

7.4.2.6. वाई-फ़ाई Keepalive Offload

डिवाइस पर लागू करने के तरीके:

• इसमें वाई-फ़ाई की मदद से, डिवाइस को चालू रखने की सुविधा के लिए ऑफ़लोड की सुविधा शामिल होनी चाहिए.

अगर डिवाइस में वाई-फ़ाई की मदद से, डिवाइस को चालू रखने की सुविधा के साथ-साथ, तीसरे पक्ष के ऐप्लिकेशन के लिए इस सुविधा का ऐक्सेस दिया गया है, तो:

• [C-1-1] SocketKeepAlive एपीआई के साथ काम करना चाहिए.
• [C-1-2] यह ज़रूरी है कि डिवाइस, वाई-फ़ाई पर कम से कम तीन कनेक्शन को एक साथ बनाए रख सके

अगर डिवाइस में वाई-फ़ाई की keepalive सुविधा के साथ ऑफ़लोड करने की सुविधा काम नहीं करती है, तो:

• [C-2-1] को ERROR_UNSUPPORTED दिखाना चाहिए.

7.4.2.7. वाई-फ़ाई ईज़ी कनेक्ट (डिवाइस प्रोवाइज़निंग प्रोटोकॉल)

डिवाइस पर लागू करने के तरीके:

• इसमें Wi-Fi Easy Connect (DPP) के लिए सहायता शामिल होनी चाहिए.

अगर डिवाइस में वाई-फ़ाई आसानी से कनेक्ट करने की सुविधा शामिल है और तीसरे पक्ष के ऐप्लिकेशन के लिए इस सुविधा का ऐक्सेस दिया गया है, तो:

• [C-1-1] WifiManager#isEasyConnectSupported() method return true होना चाहिए.

7.4.2.8. एंटरप्राइज़ वाई-फ़ाई सर्वर सर्टिफ़िकेट की पुष्टि करना

अगर वाई-फ़ाई सर्वर सर्टिफ़िकेट की पुष्टि नहीं की गई है या वाई-फ़ाई सर्वर का डोमेन नेम सेट नहीं किया गया है, तो डिवाइस पर ये कार्रवाइयां की जाती हैं:

• [C-SR-1] हमारा सुझाव है कि उपयोगकर्ता को सेटिंग ऐप्लिकेशन में, मैन्युअल तरीके से Enterprise वाई-फ़ाई नेटवर्क जोड़ने का विकल्प न दें.

7.4.2.9. पहली बार इस्तेमाल करने पर भरोसा (टीओएफ़यू)

अगर डिवाइस पर, पहली बार इस्तेमाल करने पर भरोसा करने की सुविधा (TOFU) काम करती है और उपयोगकर्ता को WPA/WPA2/WPA3-Enterprise कॉन्फ़िगरेशन तय करने की अनुमति मिलती है, तो:

• [C-4-1] उपयोगकर्ता को TOFU का इस्तेमाल करने का विकल्प देना ज़रूरी है.

7.4.3. ब्लूटूथ

अगर डिवाइस पर ब्लूटूथ ऑडियो प्रोफ़ाइल काम करती है, तो:

• यह बेहतर ऑडियो कोडेक और ब्लूटूथ ऑडियो कोडेक (उदाहरण के लिए, LDAC) के साथ काम करना चाहिए

अगर डिवाइस पर HFP, A2DP, और AVRCP काम करते हैं, तो:

• यह कम से कम पांच कनेक्ट किए गए डिवाइसों के साथ काम करना चाहिए.

अगर डिवाइस पर android.hardware.vr.high_performance सुविधा लागू की जाती है, तो:

• [C-1-1] यह ज़रूरी है कि डिवाइस, ब्लूटूथ 4.2 और ब्लूटूथ ले डेटा लेंथ एक्सटेंशन के साथ काम करता हो.

Android में ब्लूटूथ और ब्लूटूथ लो एनर्जी की सुविधा शामिल है.

अगर डिवाइस में ब्लूटूथ और ब्लूटूथ लो एनर्जी (LE) की सुविधाएं शामिल हैं, तो:

• [C-2-1] प्लैटफ़ॉर्म की काम की सुविधाओं (android.hardware.bluetooth और android.hardware.bluetooth_le) के बारे में एलान करना और प्लैटफ़ॉर्म के एपीआई लागू करना ज़रूरी है.
• डिवाइस के हिसाब से, ज़रूरी ब्लूटूथ प्रोफ़ाइलें लागू करनी चाहिए. जैसे, A2DP, AVRCP, OBEX, HFP वगैरह.

अगर डिवाइस में ब्लूटूथ स्मार्ट (बीएलई) की सुविधा शामिल है, तो:

• [C-3-1] हार्डवेयर की सुविधा android.hardware.bluetooth_le के बारे में एलान करना ज़रूरी है.
• [C-3-2] SDK टूल के दस्तावेज़ और android.bluetooth में बताए गए तरीके से, GATT (जनरल एट्रिब्यूट प्रोफ़ाइल) पर आधारित ब्लूटूथ एपीआई चालू करना ज़रूरी है.
• [C-3-3] BluetoothAdapter.isOffloadedFilteringSupported() के लिए सही वैल्यू की जानकारी देनी ज़रूरी है, ताकि यह पता चल सके कि ScanFilter एपीआई क्लास के लिए फ़िल्टर करने का लॉजिक लागू किया गया है या नहीं.
• [C-3-4] BluetoothAdapter.isMultipleAdvertisementSupported() के लिए सही वैल्यू सबमिट करना ज़रूरी है, ताकि यह पता चल सके कि कम ऊर्जा वाले विज्ञापन दिखाने की सुविधा काम करती है या नहीं.

• [C-3-5] डिवाइस के स्कैनिंग या विज्ञापन दिखाने के लिए, BLE का इस्तेमाल करने पर, उपयोगकर्ता की निजता की सुरक्षा के लिए, रिज़ॉल्व किए जा सकने वाले निजी पते (आरपीए) के टाइम आउट को 15 मिनट से ज़्यादा नहीं होना चाहिए. साथ ही, टाइम आउट होने पर पता बदलना चाहिए. टाइमिंग अटैक को रोकने के लिए, टाइम आउट इंटरवल को भी 5 से 15 मिनट के बीच रैंडम तौर पर सेट किया जाना चाहिए.

• ScanFilter API को लागू करते समय, फ़िल्टर करने के लॉजिक को ब्लूटूथ चिपसेट पर ऑफ़लोड करने की सुविधा होनी चाहिए.

• ब्लूटूथ चिपसेट पर, एक साथ कई डिवाइसों को स्कैन करने की सुविधा काम करनी चाहिए.

• इसमें कम से कम चार स्लॉट के साथ कई विज्ञापन दिखाने की सुविधा होनी चाहिए.

अगर डिवाइस पर ब्लूटूथ LE काम करता है और जगह की जानकारी स्कैन करने के लिए ब्लूटूथ LE का इस्तेमाल किया जाता है, तो:

• [C-4-1] सिस्टम एपीआई BluetoothAdapter.isBleScanAlwaysAvailable() के ज़रिए, वैल्यू पढ़ने की सुविधा को चालू/बंद करने के लिए, उपयोगकर्ता को कोई सुविधा देनी ज़रूरी है.

अगर डिवाइस में ब्लूटूथ LE और Hearing Aids Profile की सुविधाएं शामिल हैं, जैसा कि ब्लूटूथ LE का इस्तेमाल करके, कान की मशीन के ऑडियो की सुविधा में बताया गया है, तो:

• [C-5-1] BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID) के लिए, true दिखाना ज़रूरी है.

अगर डिवाइस में ब्लूटूथ या ब्लूटूथ लो एनर्जी (LE) की सुविधा शामिल है, तो:

• [C-6-1] किसी भी ऐसे ब्लूटूथ मेटाडेटा (जैसे, स्कैन के नतीजे) के ऐक्सेस पर पाबंदी लगानी चाहिए जिसका इस्तेमाल डिवाइस की जगह की जानकारी पाने के लिए किया जा सकता है. ऐसा तब तक करना चाहिए, जब तक अनुरोध करने वाला ऐप्लिकेशन अपनी मौजूदा फ़ोरग्राउंड/बैकग्राउंड स्थिति के आधार पर, android.permission.ACCESS_FINE_LOCATION अनुमति की जांच को पास नहीं कर लेता.

अगर डिवाइस में ब्लूटूथ या ब्लूटूथ स्मार्टवॉच के लिए काम करने वाली सुविधा शामिल है और ऐप्लिकेशन मेनिफ़ेस्ट में डेवलपर का यह एलान शामिल नहीं है कि वे ब्लूटूथ से जगह की जानकारी नहीं ले रहे हैं, तो:

• [C-6-2] ब्लूटूथ ऐक्सेस को android.permission.ACCESS_FINE_LOCATION के पीछे रखना ज़रूरी है.

अगर डिवाइस पर लागू किए गए एपीआई, BluetoothAdapter.isLeAudioSupported() एपीआई के लिए true दिखाते हैं, तो:

• [C-7-1] यह यूनीकास्ट क्लाइंट के साथ काम करना चाहिए.
• [C-7-2] यह 2M PHY के साथ काम करना चाहिए.
• [C-7-3] यह ज़रूरी है कि यह LE एक्सटेंडेड विज्ञापन के साथ काम करे.
• [C-7-4] यह ज़रूरी है कि सीआईजी में कम से कम दो सीआईएस कनेक्शन काम करते हों.
• [C-7-5] BAP यूनीकास्ट क्लाइंट, सीएसआईपी सेट कोऑर्डिनेटर, एमसीपी सर्वर, वीसीपी कंट्रोलर, सीसीपी सर्वर को एक साथ चालू करना ज़रूरी है.
• [C-SR-1] हमारा सुझाव है कि आप HAP यूनीकास्ट क्लाइंट को चालू करें.

अगर डिवाइस पर लागू किए गए एपीआई, BluetoothAdapter.isLeAudioBroadcastSourceSupported() एपीआई के लिए true दिखाते हैं, तो:

• [C-8-1] यह ज़रूरी है कि किसी BIG में कम से कम दो बीआईएस लिंक काम करते हों.
• [C-8-2] BAP ब्रॉडकास्ट सोर्स और BAP ब्रॉडकास्ट असिस्टेंट को एक साथ चालू करना ज़रूरी है.
• [C-8-3] इसमें, समय-समय पर दिखने वाले विज्ञापनों की सुविधा होनी चाहिए.

अगर डिवाइस पर लागू किए गए एपीआई, BluetoothAdapter.isLeAudioBroadcastAssistantSupported() एपीआई के लिए true दिखाते हैं, तो:

• [C-9-1] इसमें PAST (Periodic Advertising Sync Transfer) की सुविधा होनी चाहिए.
• [C-9-2] यह ज़रूरी है कि डिवाइस, LE पर समय-समय पर विज्ञापन दिखाने की सुविधा के साथ काम करे.

अगर डिवाइस पर FEATURE_BLUETOOTH_LE लागू किया जाता है, तो:

• [C-10-1] लाइन ऑफ़ साइट वाले एनवायरमेंट में, ADVERTISE_TX_POWER_HIGH पर ट्रांसमिट करने वाले रेफ़रंस डिवाइस से 1 मीटर की दूरी पर, 95% माप के लिए आरएसएसआई की माप +/-9dB के अंदर होनी चाहिए.

• [C-10-2] हर चैनल के डेटा में होने वाले बदलावों को कम करने के लिए, Rx/Tx में सुधार करना ज़रूरी है. इससे, तीनों चैनलों और हर ऐंटेना (अगर एक से ज़्यादा ऐंटेना का इस्तेमाल किया जाता है) पर होने वाली 95% माप, एक-दूसरे से +/-3dB के अंदर होंगी.

• [C-SR-2] हमारा सुझाव है कि आप Rx ऑफ़सेट को मेज़र करें और उसका समाधान करें, ताकि यह पक्का किया जा सके कि ADVERTISE_TX_POWER_HIGH पर ट्रांसमिट करने वाले रेफ़रंस डिवाइस से 1 मीटर की दूरी पर, औसत बीएलई आरएसएसआई -60dBm +/-10 dB हो. ऐसा तब किया जा सकता है, जब डिवाइसों को इस तरह से ऑर्डर किया गया हो कि वे 'पैरलल प्लेन' पर हों और उनकी स्क्रीन एक ही दिशा में हों.

• [C-SR-3] हमारा सुझाव है कि आप Tx ऑफ़सेट को मेज़र करें और उसका समाधान करें, ताकि यह पक्का किया जा सके कि 1 मीटर की दूरी पर मौजूद रेफ़रंस डिवाइस से स्कैन करने और ADVERTISE_TX_POWER_HIGH पर ट्रांसमिट करने पर, मीडियन बीएलई आरएसएसआई -60dBm +/-10 dB हो. ऐसा तब किया जा सकता है, जब डिवाइसों को इस तरह से ऑर्डर किया गया हो कि वे एक ही दिशा में हों और स्क्रीन एक ही दिशा में हों.

  शर्तों [C-10-3] और [C-10-4] को 2.2.1 में ले जाया गया. हार्डवेयर.

• [C-10-3] यह ज़रूरी है कि Rx ऑफ़सेट को मेज़र किया जाए और उसका समाधान किया जाए, ताकि यह पक्का किया जा सके कि ADVERTISE_TX_POWER_HIGH पर ट्रांसमिट करने वाले रेफ़रंस डिवाइस से 1 मीटर की दूरी पर, औसत बीएलई आरएसएसआई -55dBm +/-10 dB हो.
• [C-10-4] Tx ऑफ़सेट को मेज़र करना और उसका समाधान करना ज़रूरी है, ताकि यह पक्का किया जा सके कि 1 मीटर की दूरी पर मौजूद रेफ़रंस डिवाइस से स्कैन करते समय और ADVERTISE_TX_POWER_HIGH पर ट्रांसमिट करते समय, मीडियन बीएलई आरएसएसआई -55dBm +/-10 dB हो.

हमारा सुझाव है कि आप मौजूदगी को कैलिब्रेट करने से जुड़ी ज़रूरी शर्तें में बताए गए मेज़रमेंट सेटअप करने के तरीके अपनाएं.

अगर डिवाइस पर ब्लूटूथ 5.0 वर्शन काम करता है, तो:

• [C-SR-4] हमारा सुझाव है कि आप इनके लिए सहायता दें:
  • LE 2M PHY
  • LE कोडेक PHY
  • LE विज्ञापन एक्सटेंशन
  • समय-समय पर विज्ञापन दिखाना
  • कम से कम 10 विज्ञापन सेट
  • एक साथ कम से कम आठ LE कनेक्शन. हर कनेक्शन, कनेक्शन टॉपोलॉजी की भूमिकाओं में से किसी एक में हो सकता है.
  • LE लिंक लेयर की निजता
  • "समस्या हल करने वाली सूची" में कम से कम आठ एंट्री होनी चाहिए

7.4.4. नियर फ़ील्ड कम्यूनिकेशन

डिवाइस पर लागू करने के तरीके:

• इसमें नियर-फ़ील्ड कम्यूनिकेशन (एनएफ़सी) के लिए, ट्रांसीवर और उससे जुड़ा हार्डवेयर शामिल होना चाहिए.
• [C-0-1] android.nfc.NdefMessage और android.nfc.NdefRecord एपीआई को लागू करना ज़रूरी है. भले ही, इनमें एनएफ़सी के लिए सहायता शामिल न हो या android.hardware.nfc सुविधा का एलान न किया गया हो. ऐसा इसलिए, क्योंकि क्लास, प्रोटोकॉल से स्वतंत्र डेटा दिखाने के फ़ॉर्मैट को दिखाती हैं.

अगर डिवाइस में एनएफ़सी हार्डवेयर शामिल है और इसे तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराने का प्लान है, तो:

• [C-1-1] android.hardware.nfc सुविधा की जानकारी, android.content.pm.PackageManager.hasSystemFeature() तरीके से देनी ज़रूरी है.
• यह ज़रूरी है कि डिवाइस, नीचे दिए गए एनएफ़सी स्टैंडर्ड के ज़रिए एनडीएफ़ मैसेज को पढ़ और लिख सके:
• [C-1-2] यह ज़रूरी है कि यह डिवाइस, एनएफ़सी फ़ोरम के रीडर/राइटर्स के तौर पर काम कर सके.इसके लिए, यह डिवाइस इन एनएफ़सी स्टैंडर्ड का इस्तेमाल करता है:
  • NfcA (ISO14443-3A)
  • NfcB (ISO14443-3B)
  • NfcF (JIS X 6319-4)
  • IsoDep (ISO 14443-4)
  • एनएफ़सी फ़ोरम टैग टाइप 1, 2, 3, 4, 5 (एनएफ़सी फ़ोरम के मुताबिक)

• [C-SR-1] हमारा सुझाव है कि आपके डिवाइस में, एनएफ़सी के इन स्टैंडर्ड का इस्तेमाल करके, एनडीएफ़ई मैसेज के साथ-साथ रॉ डेटा को पढ़ने और लिखने की सुविधा हो. ध्यान दें कि एनएफ़सी स्टैंडर्ड के लिए, 'इसका सुझाव ज़रूर दिया जाता है' के तौर पर बताया गया है. हालांकि, आने वाले समय में रिलीज़ होने वाले वर्शन के लिए, 'इसका इस्तेमाल करना ज़रूरी है' के तौर पर बदलाव किया जाएगा. इस वर्शन में ये स्टैंडर्ड ज़रूरी नहीं हैं, लेकिन आने वाले वर्शन में ये ज़रूरी होंगे. Android के इस वर्शन पर काम करने वाले मौजूदा और नए डिवाइसों को, इन ज़रूरी शर्तों को पूरा करने का सुझाव दिया जाता है. इससे, आने वाले समय में प्लैटफ़ॉर्म के रिलीज़ किए जाने वाले नए वर्शन पर अपग्रेड किया जा सकेगा.

• [C-1-13] एनएफ़सी डिस्कवरी मोड में, काम करने वाली सभी टेक्नोलॉजी के लिए ज़रूर पोल करें.

• डिवाइस के चालू होने पर, स्क्रीन चालू और लॉक-स्क्रीन अनलॉक होने पर, डिवाइस को एनएफ़सी डिस्कवरी मोड में होना चाहिए.

• थिनफ़िल्म एनएफ़सी बारकोड वाले प्रॉडक्ट के बारकोड और यूआरएल (अगर कोड में बदला गया हो) को पढ़ने की सुविधा होनी चाहिए.

ध्यान दें कि ऊपर बताए गए JIS, ISO, और NFC Forum के स्पेसिफ़िकेशन के लिए, सार्वजनिक तौर पर उपलब्ध लिंक उपलब्ध नहीं हैं.

Android में, एनएफ़सी होस्ट कार्ड एम्युलेशन (एचसीई) मोड के साथ काम करने की सुविधा शामिल है.

अगर डिवाइस में एनएफ़सी कंट्रोलर चिपसेट शामिल है, जो एचसीई (NfcA और/या NfcB के लिए) की सुविधा देता है और ऐप्लिकेशन आईडी (एआईडी) को रूट करने की सुविधा देता है, तो:

• [C-2-1] android.hardware.nfc.hce सुविधा के कॉन्स्टेंट की जानकारी देना ज़रूरी है.
• [C-2-2] Android SDK टूल में बताए गए तरीके के मुताबिक, एनएफ़सी एचसीई एपीआई के साथ काम करना चाहिए.

अगर डिवाइस में NfcF के लिए एचसीई की सुविधा वाला एनएफ़सी कंट्रोलर चिपसेट शामिल है और तीसरे पक्ष के ऐप्लिकेशन के लिए यह सुविधा लागू की गई है, तो:

• [C-3-1] android.hardware.nfc.hcef सुविधा के कॉन्स्टेंट की जानकारी देना ज़रूरी है.
• [C-3-2] Android SDK में बताए गए तरीके के मुताबिक, NfcF कार्ड इम्यूलेशन एपीआई लागू करना ज़रूरी है.

अगर डिवाइस में, इस सेक्शन में बताए गए सामान्य एनएफ़सी सपोर्ट के साथ-साथ, रीडर/राइटर्स की भूमिका में MIFARE टेक्नोलॉजी (MIFARE Classic, MIFARE Ultralight, MIFARE Classic पर NDEF) काम करती हैं, तो:

• [C-4-1] Android SDK टूल के दस्तावेज़ में बताए गए तरीके के मुताबिक, ज़रूरी Android एपीआई लागू करना ज़रूरी है.
• [C-4-2] android.content.pm.PackageManager.hasSystemFeature() के तरीके से, com.nxp.mifare सुविधा की जानकारी देना ज़रूरी है. ध्यान दें कि यह Android की स्टैंडर्ड सुविधा नहीं है. इसलिए, यह android.content.pm.PackageManager क्लास में एक कॉन्स्टेंट के तौर पर नहीं दिखती.

7.4.5. नेटवर्किंग प्रोटोकॉल और एपीआई

7.4.5.1. नेटवर्क की कम से कम क्षमता

डिवाइस पर लागू करने के तरीके:

• [C-0-1] इसमें डेटा नेटवर्किंग के एक या एक से ज़्यादा फ़ॉर्म के लिए सहायता शामिल होनी चाहिए. खास तौर पर, डिवाइस में कम से कम एक ऐसा डेटा स्टैंडर्ड होना चाहिए जो 200 केबीआईटी/सेकंड या उससे ज़्यादा की स्पीड पर काम करता हो. इस ज़रूरी शर्त को पूरा करने वाली टेक्नोलॉजी के उदाहरणों में, EDGE, HSPA, EV-DO, 802.11g, ईथरनेट, और ब्लूटूथ पैन शामिल हैं.
• अगर प्राइमरी डेटा कनेक्शन के तौर पर कोई फ़िज़िकल नेटवर्किंग स्टैंडर्ड (जैसे, इथरनेट) इस्तेमाल किया जा रहा है, तो इसमें कम से कम एक सामान्य वायरलेस डेटा स्टैंडर्ड (जैसे, 802.11 (वाई-फ़ाई)) के लिए भी सहायता शामिल होनी चाहिए.
• डेटा कनेक्टिविटी के एक से ज़्यादा फ़ॉर्म लागू किए जा सकते हैं.

7.4.5.2. IPv6

डिवाइस पर लागू करने के तरीके:

• [C-0-2] इसमें IPv6 नेटवर्किंग स्टैक शामिल होना चाहिए. साथ ही, java.net.Socket और java.net.URLConnection जैसे मैनेज किए जा रहे एपीआई के साथ-साथ AF_INET6 सॉकेट जैसे नेटिव एपीआई का इस्तेमाल करके, IPv6 कम्यूनिकेशन की सुविधा भी होनी चाहिए.
• [C-0-3] IPv6 को डिफ़ॉल्ट रूप से चालू करना ज़रूरी है.
  • यह पक्का करना ज़रूरी है कि IPv6 कम्यूनिकेशन, IPv4 की तरह ही भरोसेमंद हो. उदाहरण के लिए:
    • [C-0-4] यह ज़रूरी है कि डिवाइस, डॉज़ मोड में IPv6 कनेक्टिविटी बनाए रखे.
    • [C-0-5] दर को सीमित करने की वजह से, डिवाइस को IPv6 के मुताबिक काम करने वाले किसी भी नेटवर्क पर IPv6 कनेक्शन नहीं खोना चाहिए. यह ज़रूरी है कि नेटवर्क पर RA लाइफ़टाइम कम से कम 180 सेकंड का हो.
• [C-0-6] तीसरे पक्ष के ऐप्लिकेशन को, आईपीवी6 नेटवर्क से कनेक्ट होने पर, नेटवर्क से सीधे आईपीवी6 कनेक्टिविटी देनी चाहिए. इसके लिए, डिवाइस पर कोई भी पता या पोर्ट ट्रांसलेशन नहीं होना चाहिए. मैनेज किए जा रहे एपीआई, जैसे कि Socket#getLocalAddress या Socket#getLocalPort और एनडीके एपीआई, जैसे कि getsockname() या IPV6_PKTINFO, दोनों को वह आईपी पता और पोर्ट दिखाना चाहिए जिसका इस्तेमाल नेटवर्क पर पैकेट भेजने और पाने के लिए किया जाता है. यह इंटरनेट (वेब) सर्वर के लिए सोर्स आईपी और पोर्ट के तौर पर दिखता है.

IPv6 के साथ काम करने की ज़रूरी शर्तें, नेटवर्क के टाइप पर निर्भर करती हैं. इन शर्तों के बारे में यहां बताया गया है.

अगर डिवाइस में वाई-फ़ाई काम करता है, तो:

• [C-1-1] यह ज़रूरी है कि डिवाइस, वाई-फ़ाई पर ड्यूअल-स्टैक और सिर्फ़ IPv6 मोड में काम करता हो.

अगर डिवाइस में ईथरनेट काम करता है, तो:

• [C-2-1] यह ज़रूरी है कि एथरनेट पर ड्यूअल-स्टैक और सिर्फ़ IPv6 मोड काम करे.

अगर डिवाइस में सेल्युलर डेटा की सुविधा काम करती है, तो:

• [C-3-1] यह ज़रूरी है कि यह मोबाइल इंटरनेट पर IPv6 (सिर्फ़ IPv6 और शायद ड्यूअल-स्टैक) के साथ काम करे.

अगर डिवाइस पर एक से ज़्यादा तरह के नेटवर्क काम करते हैं, तो वाई-फ़ाई और मोबाइल डेटा का इस्तेमाल करने पर:

• [C-4-1] जब डिवाइस एक से ज़्यादा तरह के नेटवर्क से कनेक्ट हो, तो हर नेटवर्क पर ऊपर दी गई ज़रूरी शर्तें एक साथ पूरी करनी होंगी.

7.4.5.3. कैप्टिव पोर्टल

कैप्टिव पोर्टल, ऐसे नेटवर्क को कहते हैं जिससे इंटरनेट का ऐक्सेस पाने के लिए, साइन इन करना ज़रूरी होता है.

अगर डिवाइस पर android.webkit.Webview API को पूरी तरह से लागू किया गया है, तो:

• [C-1-1] इंटेंट को मैनेज करने के लिए, कैप्टिव पोर्टल ऐप्लिकेशन उपलब्ध कराना ज़रूरी हैACTION_CAPTIVE_PORTAL_SIGN_IN. साथ ही, सिस्टम एपीआई को कॉल करने पर, उस इंटेंट को भेजकर, कैप्टिव पोर्टल का लॉगिन पेज दिखाना ज़रूरी हैConnectivityManager#startCaptivePortalApp(Network, Bundle).
• [C-1-2] डिवाइस के किसी भी नेटवर्क से कनेक्ट होने पर, कैप्टिव पोर्टल का पता लगाना और कैप्टिव पोर्टल ऐप्लिकेशन के ज़रिए लॉगिन की सुविधा देना ज़रूरी है. इन नेटवर्क में सेल्युलर/मोबाइल नेटवर्क, वाई-फ़ाई, ईथरनेट या ब्लूटूथ शामिल हैं.
• [C-1-3] जब डिवाइस को निजी डीएनएस के स्ट्रिक्ट मोड का इस्तेमाल करने के लिए कॉन्फ़िगर किया गया हो, तब यह ज़रूरी है कि डिवाइस, सादे टेक्स्ट वाले डीएनएस का इस्तेमाल करके कैप्टिव पोर्टल में लॉग इन कर सके.
• [C-1-4] android.net.LinkProperties.getPrivateDnsServerName और android.net.LinkProperties.isPrivateDnsActive के लिए, एसडीके टूल के दस्तावेज़ के मुताबिक एन्क्रिप्ट किए गए डीएनएस का इस्तेमाल करना ज़रूरी है. यह ज़रूरी है कि ऐसा उन सभी नेटवर्क ट्रैफ़िक के लिए किया जाए जो कैप्टिव पोर्टल के साथ साफ़ तौर पर कम्यूनिकेट नहीं कर रहा है.
• [C-1-5] यह पक्का करना ज़रूरी है कि जब कोई उपयोगकर्ता कैप्टिव पोर्टल में लॉग इन कर रहा हो, तो ऐप्लिकेशन के लिए इस्तेमाल किया जाने वाला डिफ़ॉल्ट नेटवर्क, इंटरनेट ऐक्सेस देने वाला कोई भी उपलब्ध नेटवर्क हो. यह नेटवर्क, ConnectivityManager.getActiveNetwork और ConnectivityManager.registerDefaultNetworkCallback से मिलता है. साथ ही, java.net.Socket जैसे Java नेटवर्किंग एपीआई और connect() जैसे नेटिव एपीआई, डिफ़ॉल्ट रूप से इसका इस्तेमाल करते हैं.

7.4.6. समन्वयन सेटिंग

डिवाइस पर लागू करने के तरीके:

• [C-0-1] डिफ़ॉल्ट रूप से, अपने-आप सिंक होने की मुख्य सेटिंग चालू होनी चाहिए, ताकि getMasterSyncAutomatically() वाला तरीका “सही” दिखाए.

7.4.7. डेटा बचाने वाला विकल्प

अगर डिवाइस पर लागू किए गए कनेक्शन में मीटर वाला कनेक्शन शामिल है, तो वे ये हैं:

• [C-SR-1] हमारा सुझाव है कि आप डेटा बचाने वाला मोड उपलब्ध कराएं.

अगर डिवाइस में डेटा बचाने वाला मोड उपलब्ध है, तो:

• [C-1-1] SDK दस्तावेज़ में बताए गए तरीके के मुताबिक, ConnectivityManager क्लास में मौजूद सभी एपीआई के साथ काम करना चाहिए

अगर डिवाइस में डेटा बचाने वाला मोड उपलब्ध नहीं है, तो:

• [C-2-1] ConnectivityManager.getRestrictBackgroundStatus() के लिए, RESTRICT_BACKGROUND_STATUS_DISABLED वैल्यू दिखानी चाहिए
• [C-2-2] इसे ब्रॉडकास्ट नहीं किया जाना चाहिए ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED.

7.4.8. सुरक्षित एलिमेंट

अगर डिवाइस में Open Mobile API के साथ काम करने वाले सुरक्षित एलिमेंट लागू किए गए हैं और उन्हें तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराया गया है, तो:

• [C-1-1] android.se.omapi.SEService.getReaders() एपीआई के ज़रिए, उपलब्ध सुरक्षित एलिमेंट रीडर की सूची बनाना ज़रूरी है.

• [C-1-2] UICC पर आधारित सुरक्षित एलिमेंट वाले डिवाइस के लिए, android.hardware.se.omapi.uicc के ज़रिए, सुविधा के सही फ़्लैग का एलान करना ज़रूरी है. इसके अलावा, eSE पर आधारित सुरक्षित एलिमेंट वाले डिवाइस के लिए, android.hardware.se.omapi.ese और SD पर आधारित सुरक्षित एलिमेंट वाले डिवाइस के लिए, android.hardware.se.omapi.sd के ज़रिए, सुविधा के सही फ़्लैग का एलान करना ज़रूरी है.

7.4.9. यूडब्ल्यूबी

अगर डिवाइस में 802.1.15.4 के लिए सहायता शामिल है और इस सुविधा को तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराया गया है, तो:

• [C-1-1] android.uwb में, उससे जुड़े Android API को लागू करना ज़रूरी है.
• [C-1-2] हार्डवेयर की सुविधा के फ़्लैग android.hardware.uwb की जानकारी ज़रूर दें.
• [C-1-3] यह ज़रूरी है कि यह Android के लागू होने के दौरान तय की गई सभी ज़रूरी UWB प्रोफ़ाइलों के साथ काम करे.
• [C-1-4] उपयोगकर्ता को UWB रेडियो की स्थिति को चालू/बंद करने की अनुमति देने के लिए, उपयोगकर्ता के लिए सुविधा उपलब्ध कराना ज़रूरी है.
• [C-1-5] यह ज़रूरी है कि UWB रेडियो का इस्तेमाल करने वाले ऐप्लिकेशन के पास, UWB_RANGING अनुमति हो. यह अनुमति, NEARBY_DEVICES अनुमति ग्रुप में होती है.
• [C-SR-1] हमारा सुझाव है कि आप स्टैंडर्ड संगठनों के तय किए गए, ज़रूरी नियमों का पालन करें और सर्टिफ़िकेट पाने के लिए टेस्ट पास करें. इन संगठनों में FIRA, CCC, और CSA शामिल हैं.
• [C-1-6] यह पक्का करना ज़रूरी है कि बिना किसी गड़बड़ी वाले चेंबर में, एक मीटर की दूरी पर, सीधी रेखा में दिखने वाले 95% आइटम की दूरी का आकलन, +/-15 सेंटीमीटर के अंदर हो.
• [C-1-7] यह पक्का करना ज़रूरी है कि रेफ़रंस डिवाइस से 1 मीटर की दूरी पर, दूरी के मेज़रमेंट का औसत [0.75 मीटर, 1.25 मीटर] के बीच हो. यहां ग्राउंड ट्रूथ की दूरी, डीयूटी के ऊपरी किनारे से मेज़र की जाती है. डीयूटी को ऊपर की ओर रखकर 45 डिग्री के कोण पर झुकाया जाता है.
• [C-SR-2] हमारा सुझाव है कि आप मौजूदगी को कैलिब्रेट करने से जुड़ी ज़रूरी शर्तों में बताए गए, मेज़रमेंट सेटअप करने के चरणों का पालन करें.

7.5. कैमरे

अगर डिवाइस में कम से कम एक कैमरा है, तो:

• [C-1-1] android.hardware.camera.any फ़ीचर फ़्लैग का एलान करना ज़रूरी है.
• [C-1-2] ऐप्लिकेशन के लिए, डिवाइस पर सबसे ज़्यादा रिज़ॉल्यूशन वाले कैमरा सेंसर से जनरेट की गई इमेज के साइज़ के बराबर, तीन RGBA_8888 बिटमैप को एक साथ ऐलोकेट करना ज़रूरी है. ऐसा तब करना चाहिए, जब कैमरा बुनियादी झलक और स्टिल कैप्चर के मकसद से खुला हो.
• [C-1-3] यह पक्का करना ज़रूरी है कि पहले से इंस्टॉल किया गया डिफ़ॉल्ट कैमरा ऐप्लिकेशन, MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE या MediaStore.ACTION_VIDEO_CAPTURE इंटेंट को मैनेज करता हो. साथ ही, यह भी ज़रूरी है कि जब ACCESS_FINE_LOCATION के बिना, इमेज को पाने वाले ऐप्लिकेशन को भेजा जाए, तो इमेज के मेटाडेटा में उपयोगकर्ता की जगह की जानकारी हटाने की ज़िम्मेदारी, पहले से इंस्टॉल किए गए डिफ़ॉल्ट कैमरा ऐप्लिकेशन की हो.

अगर डिवाइस पर एचडीआर 10-बिट आउटपुट की सुविधा काम करती है, तो:

• [C-2-1] 10-बिट आउटपुट की सुविधा वाले हर कैमरा डिवाइस के लिए, कम से कम एचएलजी एचडीआर प्रोफ़ाइल का इस्तेमाल किया जाना चाहिए.
• [C-2-2] यह ज़रूरी है कि डिवाइस के पीछे या सामने मौजूद मुख्य कैमरे में 10-बिट आउटपुट की सुविधा हो.
• [C-SR-1] हमारा सुझाव है कि दोनों प्राइमरी कैमरों के लिए 10-बिट आउटपुट का इस्तेमाल करें.
• [C-2-3] किसी लॉजिकल कैमरे के BACKWARD_COMPATIBLE फ़ंक्शन वाले सभी फ़िज़िकल सब-कैमरे और खुद लॉजिकल कैमरे के लिए, एक ही एचडीआर प्रोफ़ाइल का इस्तेमाल किया जाना चाहिए.

10-बिट एचडीआर की सुविधा वाले लॉजिकल कैमरा डिवाइसों के लिए, android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO एपीआई लागू करने पर:

• [C-3-1] यह ज़रूरी है कि लॉजिकल कैमरे पर मौजूद CONTROL_ZOOM_RATIO कंट्रोल की मदद से, पुराने वर्शन के साथ काम करने वाले सभी फ़िज़िकल कैमरों के बीच स्विच किया जा सके.

7.5.1. पीछे वाला कैमरा

पीछे वाला कैमरा, डिवाइस के डिसप्ले के उलट दिशा में होता है. इसका मतलब है कि यह किसी पारंपरिक कैमरे की तरह, डिवाइस के दूसरी तरफ़ मौजूद ऑब्जेक्ट की तस्वीरें लेता है.

नई ज़रूरी शर्तें लागू करना

पीछे वाला कैमरा, डिवाइस के पीछे की ओर मौजूद होता है. यह डिवाइस के सामने की ओर मौजूद ऑब्जेक्ट की इमेज लेता है, ठीक वैसे ही जैसे कोई सामान्य कैमरा करता है. हैंडहेल्ड डिवाइसों पर, यह कैमरा डिवाइस के डिसप्ले के सामने की ओर मौजूद होता है.

नई ज़रूरी शर्तें खत्म करना

डिवाइस पर लागू करने के तरीके:

• इसमें पीछे वाला कैमरा होना चाहिए.

अगर डिवाइस में कम से कम एक पीछे वाला कैमरा है, तो:

• [C-1-1] सुविधा फ़्लैग android.hardware.camera और android.hardware.camera.any की शिकायत करना ज़रूरी है.
• [C-1-2] का रिज़ॉल्यूशन कम से कम 2 मेगापिक्सल होना चाहिए.
• कैमरा ड्राइवर में, हार्डवेयर ऑटो-फ़ोकस या सॉफ़्टवेयर ऑटो-फ़ोकस की सुविधा लागू होनी चाहिए. यह सुविधा, ऐप्लिकेशन सॉफ़्टवेयर के लिए पारदर्शी होनी चाहिए.
• इसमें फ़िक्स्ड-फ़ोकस या ईडीओएफ़ (एक्सटेंडेड डेप्थ ऑफ़ फ़ील्ड) हार्डवेयर हो सकता है.
• इसमें फ़्लैश शामिल हो सकता है.

अगर कैमरे में फ़्लैश है, तो:

• [C-2-1] कैमरे की झलक दिखाने वाले प्लैटफ़ॉर्म पर android.hardware.Camera.PreviewCallback इंस्टेंस के रजिस्टर होने के दौरान, फ़्लैश लैंप नहीं जलना चाहिए. ऐसा तब तक नहीं होना चाहिए, जब तक कि ऐप्लिकेशन ने Camera.Parameters ऑब्जेक्ट के FLASH_MODE_AUTO या FLASH_MODE_ON एट्रिब्यूट को चालू करके, फ़्लैश को साफ़ तौर पर चालू न किया हो. ध्यान दें कि यह पाबंदी, डिवाइस के पहले से मौजूद सिस्टम कैमरा ऐप्लिकेशन पर लागू नहीं होती. यह सिर्फ़ Camera.PreviewCallback का इस्तेमाल करने वाले तीसरे पक्ष के ऐप्लिकेशन पर लागू होती है.

7.5.2. सामने वाला कैमरा

सामने वाला कैमरा, डिवाइस के डिसप्ले के उसी हिस्से पर होता है जहां डिसप्ले होता है. इसका इस्तेमाल आम तौर पर, उपयोगकर्ता की इमेज लेने के लिए किया जाता है. जैसे, वीडियो कॉन्फ़्रेंसिंग और इससे मिलते-जुलते ऐप्लिकेशन के लिए.

नई ज़रूरी शर्तें लागू करना

सामने वाला कैमरा, उपयोगकर्ता के सामने होता है. इसका इस्तेमाल आम तौर पर उपयोगकर्ता की इमेज लेने के लिए किया जाता है. जैसे, वीडियो कॉन्फ़्रेंसिंग और इससे मिलते-जुलते ऐप्लिकेशन के लिए. हैंडहेल्ड डिवाइसों पर, यह कैमरा डिसप्ले के उसी हिस्से पर होता है.

नई ज़रूरी शर्तें खत्म करना

डिवाइस पर लागू करने के तरीके:

• इसमें सामने वाला कैमरा शामिल हो सकता है.

अगर डिवाइस में कम से कम एक सामने वाला कैमरा है, तो:

• [C-1-1] सुविधा फ़्लैग android.hardware.camera.any और android.hardware.camera.front की शिकायत करना ज़रूरी है.
• [C-1-2] इसका रिज़ॉल्यूशन कम से कम VGA (640x480 पिक्सल) होना चाहिए.
• [C-1-3] Camera API के लिए, डिफ़ॉल्ट तौर पर सामने वाले कैमरे का इस्तेमाल नहीं किया जाना चाहिए. साथ ही, एपीआई को इस तरह कॉन्फ़िगर नहीं किया जाना चाहिए कि वह सामने वाले कैमरे को डिफ़ॉल्ट तौर पर पीछे वाले कैमरे के तौर पर इस्तेमाल करे. भले ही, डिवाइस में सिर्फ़ यही कैमरा हो.
• [C-1-4] जब मौजूदा ऐप्लिकेशन ने साफ़ तौर पर अनुरोध किया हो कि android.hardware.Camera.setDisplayOrientation() के ज़रिए कॉल करके, कैमरे के डिसप्ले को घुमाया जाए, तो कैमरे की झलक को ऐप्लिकेशन के तय किए गए ओरिएंटेशन के हिसाब से, हॉरिज़ॉन्टल तौर पर दिखाना ज़रूरी है. इसके उलट, अगर मौजूदा ऐप्लिकेशन साफ़ तौर पर यह अनुरोध नहीं करता कि android.hardware.Camera.setDisplayOrientation() के ज़रिए कॉल करके, कैमरे के डिसप्ले को घुमाया जाए, तो झलक को डिवाइस के डिफ़ॉल्ट हॉरिज़ॉन्टल ऐक्सिस के साथ मिरर किया जाना चाहिए.
• [C-1-5] ऐप्लिकेशन कॉलबैक में भेजी गई फ़ाइनल इमेज या वीडियो स्ट्रीम को डुप्लीकेट नहीं करना चाहिए. इसके अलावा, मीडिया स्टोरेज में सेव की गई इमेज या वीडियो स्ट्रीम को भी डुप्लीकेट नहीं करना चाहिए.
• [C-1-6] पोस्टव्यू में दिखाई गई इमेज को उसी तरह से दिखाना चाहिए जिस तरह से कैमरे की झलक वाली इमेज स्ट्रीम दिखती है.
• इसमें सेक्शन 7.5.1 में बताई गई, पीछे की ओर फ़ोकस करने वाले कैमरों के लिए उपलब्ध सुविधाएं (जैसे, ऑटो-फ़ोकस, फ़्लैश वगैरह) शामिल हो सकती हैं.

अगर डिवाइस को उपयोगकर्ता घुमाने की सुविधा है, जैसे कि ऐक्सीलेरोमीटर की मदद से अपने-आप घूमना या उपयोगकर्ता के इनपुट से मैन्युअल तरीके से घूमना:

• [C-2-1] कैमरे की झलक, डिवाइस के मौजूदा ओरिएंटेशन के हिसाब से, हॉरिज़ॉन्टल तौर पर मिरर की जानी चाहिए.

7.5.3. बाहरी कैमरा

नई ज़रूरी शर्तें लागू करना

बाहरी कैमरा एक ऐसा कैमरा होता है जिसे किसी भी समय डिवाइस से अटैच या डिटैच किया जा सकता है. साथ ही, इसे किसी भी दिशा में रखा जा सकता है. जैसे, यूएसबी कैमरे.

नई ज़रूरी शर्तें खत्म करना

डिवाइस पर लागू करने के तरीके:

• इसमें किसी ऐसे बाहरी कैमरे के लिए सहायता शामिल हो सकती है जिसे ज़रूरी नहीं है कि वह हमेशा कनेक्ट रहे.

अगर डिवाइस में बाहरी कैमरे के साथ काम करने की सुविधा शामिल है, तो:

• [C-1-1] प्लैटफ़ॉर्म की सुविधा के फ़्लैग android.hardware.camera.external और android.hardware camera.any के बारे में ज़रूर बताना चाहिए.
• [C-1-2] अगर बाहरी कैमरा यूएसबी होस्ट पोर्ट से कनेक्ट होता है, तो यह ज़रूरी है कि डिवाइस, यूएसबी वीडियो क्लास (यूवीसी 1.0 या उसके बाद का वर्शन) के साथ काम करता हो.
• [C-1-3] कैमरे के लिए सीटीएस टेस्ट पास करना ज़रूरी है. इसके लिए, डिवाइस में कोई बाहरी कैमरा डिवाइस कनेक्ट होना चाहिए. कैमरे की सीटीएस जांच की जानकारी source.android.com पर उपलब्ध है.
• यह MJPEG जैसे वीडियो कंप्रेस करने की सुविधा के साथ काम करना चाहिए, ताकि बिना कोड वाली अच्छी क्वालिटी की स्ट्रीम (जैसे, रॉ या अलग से कंप्रेस की गई पिक्चर स्ट्रीम) को ट्रांसफ़र किया जा सके.
• एक से ज़्यादा कैमरे इस्तेमाल करने की सुविधा हो सकती है.
• कैमरे से वीडियो एन्कोड करने की सुविधा मिल सकती है.

अगर कैमरे से वीडियो एन्कोड करने की सुविधा काम करती है, तो:

• [C-2-1] डिवाइस पर एक साथ, कोड में बदले बिना स्ट्रीम की गई / एमजेपीईजी स्ट्रीम (QVGA या इससे ज़्यादा रिज़ॉल्यूशन) को ऐक्सेस किया जा सकता है.

7.5.4. Camera API का व्यवहार

Android में कैमरे को ऐक्सेस करने के लिए दो एपीआई पैकेज शामिल हैं. नया android.hardware.camera2 API, ऐप्लिकेशन को कैमरे के लोअर-लेवल कंट्रोल को एक्सपोज़ करता है. इसमें, ज़ीरो-कॉपी बर्स्ट/स्ट्रीमिंग फ़्लो और हर फ़्रेम के लिए एक्सपोज़र, गेन, व्हाइट बैलेंस गेन, कलर कन्वर्ज़न, ग़ैर-ज़रूरी चीज़ों को हटाना, शार्पनिंग वगैरह के कंट्रोल शामिल हैं.

पुराने एपीआई पैकेज,android.hardware.Camera को Android 5.0 में 'इस्तेमाल नहीं किया जा सकता' के तौर पर मार्क किया गया है. हालांकि, यह अब भी ऐप्लिकेशन के इस्तेमाल के लिए उपलब्ध होना चाहिए. Android डिवाइस पर एपीआई लागू करने के लिए, यह ज़रूरी है कि एपीआई के साथ काम करने की सुविधा, इस सेक्शन और Android SDK टूल में बताए गए तरीके से काम करती रहे.

बंद किए गए android.hardware.Camera क्लास और नए android.hardware.camera2 पैकेज के बीच, जो सुविधाएं एक जैसी हैं उनकी परफ़ॉर्मेंस और क्वालिटी, दोनों एपीआई में एक जैसी होनी चाहिए. उदाहरण के लिए, एक जैसी सेटिंग के साथ, ऑटोफ़ोकस की स्पीड और सटीक होने की दर एक जैसी होनी चाहिए. साथ ही, कैप्चर की गई इमेज की क्वालिटी भी एक जैसी होनी चाहिए. दो एपीआई के अलग-अलग सेमेटिक्स पर निर्भर करने वाली सुविधाओं के लिए, स्पीड या क्वालिटी का मेल खाना ज़रूरी नहीं है. हालांकि, इन सुविधाओं के मेल खाने की कोशिश ज़रूर की जानी चाहिए.

डिवाइस में कैमरे से जुड़े एपीआई लागू करने के लिए, सभी उपलब्ध कैमरों के लिए, कैमरे के काम करने का यह तरीका लागू करना ज़रूरी है. डिवाइस पर लागू करने के तरीके:

• [C-0-1] ऐप्लिकेशन के कॉलबैक के लिए दिए गए डेटा की झलक देखने के लिए, android.hardware.PixelFormat.YCbCr_420_SP का इस्तेमाल करना ज़रूरी है. ऐसा तब करना होगा, जब ऐप्लिकेशन ने कभी android.hardware.Camera.Parameters.setPreviewFormat(int) को कॉल न किया हो.
• [C-0-2] जब कोई ऐप्लिकेशन android.hardware.Camera.PreviewCallback इंस्टेंस रजिस्टर करता है और सिस्टम onPreviewFrame() तरीके को कॉल करता है और झलक का फ़ॉर्मैट YCbCr_420_SP होता है, तो डेटा को NV21 एन्कोडिंग फ़ॉर्मैट में होना चाहिए. यह डेटा, onPreviewFrame() में पास किए गए बाइट[] में होता है. इसका मतलब है कि NV21, डिफ़ॉल्ट तौर पर होना चाहिए.
• [C-0-3] android.hardware.Camera के लिए, सामने और पीछे के दोनों कैमरों की झलक दिखाने के लिए, YV12 फ़ॉर्मैट (जैसा कि android.graphics.ImageFormat.YV12 कॉन्स्टेंट से पता चलता है) का इस्तेमाल करना ज़रूरी है. (हार्डवेयर वीडियो एन्कोडर और कैमरा, किसी भी नेटिव पिक्सल फ़ॉर्मैट का इस्तेमाल कर सकते हैं. हालांकि, डिवाइस में YV12 में बदलाव करने की सुविधा होनी चाहिए.)
• [C-0-4] android.hardware.camera2 डिवाइसों के लिए, android.media.ImageReader एपीआई के ज़रिए आउटपुट के तौर पर android.hardware.ImageFormat.YUV_420_888 और android.hardware.ImageFormat.JPEG फ़ॉर्मैट का इस्तेमाल करना ज़रूरी है. ये ऐसे डिवाइस होते हैं जो android.request.availableCapabilities में REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE की सुविधा का विज्ञापन करते हैं.
• [C-0-5] Android SDK दस्तावेज़ में शामिल Camera API को पूरी तरह से लागू करना ज़रूरी है. भले ही, डिवाइस में हार्डवेयर ऑटोफ़ोकस या अन्य सुविधाएं हों. उदाहरण के लिए, जिन कैमरों में ऑटोफ़ोकस की सुविधा नहीं होती है उन्हें भी रजिस्टर किए गए किसी भी android.hardware.Camera.AutoFocusCallback इंस्टेंस को कॉल करना होगा. भले ही, यह सुविधा न होने वाले कैमरे के लिए काम की न हो. ध्यान दें कि यह फ़्रंट-फ़ेसिंग कैमरों पर भी लागू होता है. उदाहरण के लिए, ज़्यादातर फ़्रंट-फ़ेसिंग कैमरे ऑटोफ़ोकस की सुविधा के साथ काम नहीं करते. इसके बावजूद, एपीआई कॉलबैक को ऊपर बताए गए तरीके से “फ़ेक” किया जाना चाहिए.
• [C-0-6] android.hardware.Camera.Parameters क्लास और android.hardware.camera2.CaptureRequest क्लास में, हर पैरामीटर के नाम को एक कॉन्स्टेंट के तौर पर तय किया गया है. इसे पहचानना और इस्तेमाल करना ज़रूरी है. इसके उलट, डिवाइस पर लागू करने के लिए, android.hardware.Camera.setParameters() तरीके में पास की गई स्ट्रिंग कॉन्स्टेंट को स्वीकार नहीं किया जाना चाहिए. हालांकि, android.hardware.Camera.Parameters पर कॉन्स्टेंट के तौर पर दस्तावेज़ में दर्ज कॉन्स्टेंट को स्वीकार किया जा सकता है. इसका मतलब है कि अगर हार्डवेयर की अनुमति है, तो डिवाइस पर लागू किए गए कैमरे के सभी स्टैंडर्ड पैरामीटर काम करने चाहिए. साथ ही, कस्टम कैमरे के पैरामीटर टाइप काम नहीं करने चाहिए. उदाहरण के लिए, हाई डाइनैमिक रेंज (एचडीआर) इमेजिंग तकनीकों का इस्तेमाल करके इमेज कैप्चर करने की सुविधा वाले डिवाइसों में, कैमरा पैरामीटर Camera.SCENE_MODE_HDR का इस्तेमाल किया जाना चाहिए.
• [C-0-7] Android SDK में बताए गए तरीके के मुताबिक, android.info.supportedHardwareLevel प्रॉपर्टी के साथ सहायता के सही लेवल की जानकारी देना ज़रूरी है. साथ ही, फ़्रेमवर्क की सुविधा के फ़्लैग की सही जानकारी देना ज़रूरी है.
• [C-0-8] android.request.availableCapabilities प्रॉपर्टी के ज़रिए, android.hardware.camera2 के कैमरे की अलग-अलग सुविधाओं के बारे में भी एलान करना ज़रूरी है. साथ ही, सही सुविधा फ़्लैग का एलान करना ज़रूरी है. अगर डिवाइस से जुड़ा कोई कैमरा डिवाइस, इस सुविधा के साथ काम करता है, तो सुविधा फ़्लैग तय करना ज़रूरी है.
• [C-0-9] जब भी कैमरे से कोई नई फ़ोटो ली जाती है और फ़ोटो की एंट्री को मीडिया स्टोर में जोड़ दिया जाता है, तब Camera.ACTION_NEW_PICTURE इंटेंट को ब्रॉडकास्ट करना ज़रूरी है.
• [C-0-10] जब भी कैमरे से कोई नया वीडियो रिकॉर्ड किया जाता है और मीडिया स्टोर में फ़ोटो की एंट्री जोड़ी जाती है, तब Camera.ACTION_NEW_VIDEO इंटेंट को ब्रॉडकास्ट करना ज़रूरी है.
• [C-0-11] यह ज़रूरी है कि सभी कैमरों को, इस्तेमाल में न होने वाले android.hardware.Camera एपीआई के ज़रिए ऐक्सेस किया जा सके. साथ ही, उन्हें android.hardware.camera2 एपीआई के ज़रिए भी ऐक्सेस किया जा सके.
• [C-0-12] यह पक्का करना ज़रूरी है कि किसी भी android.hardware.camera2 या android.hardware.Camera एपीआई के लिए, चेहरे के रंग, चेहरे की बनावट या चेहरे की स्किन को चिकना करने जैसी चीज़ों में बदलाव न किया गया हो.
• [C-SR-1] जिन डिवाइसों में एक ही दिशा में एक-दूसरे के करीब और एक ही दिशा में फ़ोकस करने वाले एक से ज़्यादा आरजीबी कैमरे हैं उनके लिए, हमारा सुझाव है कि आप ऐसे लॉजिकल कैमरा डिवाइस का इस्तेमाल करें जिसमें कैमरे की सुविधा CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA की जानकारी दी गई हो. इसमें, उस दिशा में फ़ोकस करने वाले सभी आरजीबी कैमरे, फ़िज़िकल सब-डिवाइस के तौर पर शामिल होने चाहिए.

अगर डिवाइस में, तीसरे पक्ष के ऐप्लिकेशन के लिए मालिकाना हक वाला कैमरा एपीआई उपलब्ध कराया जाता है, तो:

• [C-1-1] android.hardware.camera2 एपीआई का इस्तेमाल करके, ऐसा कैमरा एपीआई लागू करना ज़रूरी है.
• android.hardware.camera2 एपीआई को वेंडर टैग और/या एक्सटेंशन दे सकता है.

7.5.5. कैमरे का ओरिएंटेशन

अगर डिवाइस में सामने या पीछे वाला कैमरा है, तो ऐसे कैमरे:

• [C-1-1] को इस तरह से ओरिएंट किया जाना चाहिए कि कैमरे का लंबा डाइमेंशन, स्क्रीन के लंबे डाइमेंशन के साथ अलाइन हो. इसका मतलब है कि जब डिवाइस को लैंडस्केप ओरिएंटेशन में रखा जाता है, तो कैमरों को लैंडस्केप ओरिएंटेशन में इमेज कैप्चर करनी चाहिए. यह डिवाइस के नेचुरल ओरिएंटेशन के बावजूद लागू होता है. इसका मतलब है कि यह मुख्य रूप से लैंडस्केप और पोर्ट्रेट ओरिएंटेशन वाले डिवाइसों पर लागू होता है.

ऊपर दी गई सभी शर्तें पूरी करने वाले डिवाइसों को ऊपर बताई गई ज़रूरी शर्त से छूट दी जाती है:

• डिवाइस में अलग-अलग आकार वाली स्क्रीन होती हैं. जैसे, फ़ोल्ड करने या हिंज करने वाली स्क्रीन.
• जब डिवाइस के फ़ोल्ड या हिंज की स्थिति बदलती है, तो डिवाइस पोर्ट्रेट-प्राइमरी से लैंडस्केप-प्राइमरी (या इसके उलट) ओरिएंटेशन पर स्विच हो जाता है.

नई ज़रूरी शर्तें लागू करना

• ऐसे डिवाइस जिनका इस्तेमाल करने वाला उन्हें घुमाने की सुविधा नहीं दे सकता. जैसे, वाहन से जुड़े डिवाइस.

नई ज़रूरी शर्तें खत्म करना

7.6. डिवाइस की मेमोरी और स्टोरेज

7.6.1. डिवाइस की कम से कम मेमोरी और स्टोरेज

डिवाइस पर लागू करने के तरीके:

• [C-0-1] इसमें ऐसा डाउनलोड मैनेजर होना चाहिए जिसका इस्तेमाल ऐप्लिकेशन, डेटा फ़ाइलें डाउनलोड करने के लिए कर सकें. साथ ही, यह ज़रूरी है कि वे डिफ़ॉल्ट "कैश मेमोरी" लोकेशन में, कम से कम 100 एमबी साइज़ की अलग-अलग फ़ाइलें डाउनलोड कर सकें.

7.6.2. ऐप्लिकेशन का शेयर किया गया स्टोरेज

डिवाइस पर लागू करने के तरीके:

• [C-0-1] ऐप्लिकेशन के लिए स्टोरेज उपलब्ध कराना ज़रूरी है. इसे अक्सर "शेयर किया गया बाहरी स्टोरेज", "ऐप्लिकेशन के लिए शेयर किया गया स्टोरेज" या लिनक्स पाथ "/sdcard" के तौर पर भी जाना जाता है.
• [C-0-2] इसे डिफ़ॉल्ट रूप से माउंट किए गए शेयर किए गए स्टोरेज के साथ कॉन्फ़िगर किया जाना चाहिए.दूसरे शब्दों में, "ऑउट ऑफ़ द बॉक्स". भले ही, स्टोरेज को किसी इंटरनल स्टोरेज कॉम्पोनेंट या हटाए जा सकने वाले स्टोरेज माध्यम (जैसे, सुरक्षित डिजिटल कार्ड स्लॉट) पर लागू किया गया हो.
• [C-0-3] ऐप्लिकेशन के शेयर किए गए स्टोरेज को सीधे तौर पर Linux पाथ sdcard पर माउंट करना ज़रूरी है. इसके अलावा, sdcard से असल माउंट पॉइंट तक Linux सिंबल लिंक शामिल किया जा सकता है.
• [C-0-4] एपीआई लेवल 29 या इसके बाद के वर्शन को टारगेट करने वाले सभी ऐप्लिकेशन के लिए, डिफ़ॉल्ट रूप से स्कोप वाला स्टोरेज चालू करना ज़रूरी है. हालांकि, यह ज़रूरी नहीं है कि इन स्थितियों में ऐसा किया जाए:
  • जब ऐप्लिकेशन ने अपने मेनिफ़ेस्ट में android:requestLegacyExternalStorage="true" का अनुरोध किया हो.
• [C-0-5] मीडिया फ़ाइलों में सेव की गई जगह की जानकारी के मेटाडेटा को हटाना ज़रूरी है. जैसे, जीपीएस Exif टैग. ऐसा तब किया जाना चाहिए, जब उन फ़ाइलों को MediaStore के ज़रिए ऐक्सेस किया जा रहा हो. हालांकि, अगर कॉल करने वाले ऐप्लिकेशन के पास ACCESS_MEDIA_LOCATION की अनुमति है, तो ऐसा नहीं करना चाहिए.

डिवाइस पर, ऊपर दी गई ज़रूरी शर्तें पूरी करने के लिए, इनमें से किसी एक का इस्तेमाल किया जा सकता है:

• उपयोगकर्ता के पास, हटाया जा सकने वाला स्टोरेज होना चाहिए. जैसे, सिक्योर डिजिटल (एसडी) कार्ड स्लॉट.
• Android Open Source Project (AOSP) में लागू किए गए, डिवाइस के स्टोरेज का वह हिस्सा जिसे हटाया नहीं जा सकता.

अगर डिवाइस में ऊपर बताई गई ज़रूरी शर्तों को पूरा करने के लिए, डिवाइस में मौजूद रिमूवेबल स्टोरेज का इस्तेमाल किया जाता है, तो:

• [C-1-1] स्लॉट में स्टोरेज का कोई माध्यम न होने पर, उपयोगकर्ता को चेतावनी देने के लिए, टॉस्ट या पॉप-अप यूज़र इंटरफ़ेस लागू करना ज़रूरी है.
• [C-1-2] इसमें FAT फ़ॉर्मैट वाला स्टोरेज मीडियम (जैसे, एसडी कार्ड) शामिल होना चाहिए. इसके अलावा, खरीदारी के समय बॉक्स और अन्य उपलब्ध कॉन्टेंट पर यह भी दिखना चाहिए कि स्टोरेज मीडियम को अलग से खरीदना होगा.

अगर डिवाइस में ऊपर बताई गई ज़रूरी शर्तों को पूरा करने के लिए, डिवाइस में पहले से मौजूद स्टोरेज का कुछ हिस्सा इस्तेमाल किया जाता है, तो:

• संगठन में काम करने वालों के साथ ऐप्लिकेशन शेयर करने की सुविधा के लिए, AOSP के मुताबिक डिवाइस के स्टोरेज का इस्तेमाल करना चाहिए.
• ऐप्लिकेशन के निजी डेटा के साथ स्टोरेज का इस्तेमाल किया जा सकता है.

अगर डिवाइस में यूएसबी पोर्ट है और वह यूएसबी पेरिफ़रल मोड के साथ काम करता है, तो:

• [C-3-1] होस्ट कंप्यूटर से, ऐप्लिकेशन के शेयर किए गए स्टोरेज में मौजूद डेटा को ऐक्सेस करने का तरीका देना ज़रूरी है.
• Android की मीडिया स्कैनर सेवा और android.provider.MediaStore की मदद से, दोनों स्टोरेज पाथ का कॉन्टेंट साफ़ तौर पर दिखाना चाहिए.
• यूएसबी स्टोरेज का इस्तेमाल किया जा सकता है. हालांकि, इस ज़रूरी शर्त को पूरा करने के लिए, मीडिया ट्रांसफ़र प्रोटोकॉल का इस्तेमाल करना चाहिए.

अगर डिवाइस में यूएसबी पेरिफ़रल मोड वाला यूएसबी पोर्ट है और वह मीडिया ट्रांसफ़र प्रोटोकॉल के साथ काम करता है, तो:

• यह Android File Transfer, रेफ़रंस के तौर पर इस्तेमाल किए जाने वाले Android MTP होस्ट के साथ काम करना चाहिए.
• यूएसबी डिवाइस क्लास 0x00 की रिपोर्ट करनी चाहिए.
• यूएसबी इंटरफ़ेस का नाम 'MTP' होना चाहिए.

7.6.3. एडॉप्टेबल स्टोरेज

अगर डिवाइस, टीवी के बजाय मोबाइल है, तो डिवाइस को लागू करने के लिए:

• [C-SR-1] हमारा सुझाव है कि डिवाइस के साथ इस्तेमाल किए जा सकने वाले स्टोरेज को ऐसी जगह पर सेट अप करें जहां वह लंबे समय तक काम करता रहे. ऐसा इसलिए, क्योंकि गलती से डिवाइस से डिसकनेक्ट होने पर, डेटा मिट सकता है या खराब हो सकता है.

अगर डिवाइस में, स्टोरेज डिवाइस का पोर्ट ऐसी जगह पर है जहां वह लंबे समय तक एक ही जगह पर रहता है, जैसे कि बैटरी कम्पार्टमेंट या सुरक्षा कवर के अंदर, तो डिवाइस को लागू करने के लिए ये तरीके अपनाए जा सकते हैं:

• [C-SR-2] एडॉप्टेबल स्टोरेज को लागू करने का ज़रूर सुझाव दिया जाता है.

7.7. यूएसबी

अगर डिवाइस में यूएसबी पोर्ट है, तो:

• यह यूएसबी पेरिफ़रल मोड और यूएसबी होस्ट मोड के साथ काम करना चाहिए.
• यह सुविधा, यूएसबी के ज़रिए डेटा सिग्नल भेजने की सुविधा को बंद करने के साथ काम करनी चाहिए.

7.7.1. यूएसबी पेरिफ़रल मोड

अगर डिवाइस में, यूएसबी पोर्ट के साथ-साथ, पेरिफ़रल मोड की सुविधा भी है, तो:

• [C-1-1] पोर्ट को ऐसे यूएसबी होस्ट से कनेक्ट किया जा सकता है जिसमें स्टैंडर्ड टाइप-A या टाइप-C यूएसबी पोर्ट हो.
• [C-1-2] android.os.Build.SERIAL के ज़रिए, USB स्टैंडर्ड डिवाइस डिस्क्रिप्टर में iSerialNumber की सही वैल्यू बताना ज़रूरी है.
• [C-1-3] टाइप-सी रेज़िस्टर स्टैंडर्ड के मुताबिक, 1.5A और 3.0A चार्जर का पता लगाना ज़रूरी है. साथ ही, अगर विज्ञापन में टाइप-सी यूएसबी की सुविधा का इस्तेमाल किया गया है, तो विज्ञापन में हुए बदलावों का पता लगाना ज़रूरी है.
• [C-SR-1] पोर्ट में माइक्रो-बी, माइक्रो-एबी या टाइप-सी यूएसबी फ़ॉर्म फ़ैक्टर का इस्तेमाल किया जाना चाहिए. मौजूदा और नए Android डिवाइसों के लिए, इन ज़रूरी शर्तों को पूरा करने का सुझाव दिया जाता है, ताकि वे आने वाले समय में प्लैटफ़ॉर्म के रिलीज़ किए जाने वाले वर्शन पर अपग्रेड कर सकें.
• [C-SR-2] पोर्ट, डिवाइस के सबसे नीचे होना चाहिए (डिवाइस के सामान्य ओरिएंटेशन के हिसाब से) या सभी ऐप्लिकेशन (होम स्क्रीन के साथ) के लिए, सॉफ़्टवेयर स्क्रीन रोटेशन की सुविधा चालू होनी चाहिए, ताकि डिवाइस को सबसे नीचे पोर्ट के साथ ओरिएंट करने पर, डिसप्ले सही तरीके से दिखे. मौजूदा और नए Android डिवाइसों के लिए, इन ज़रूरी शर्तों को पूरा करने का सुझाव दिया जाता है, ताकि वे आने वाले समय में प्लैटफ़ॉर्म के रिलीज़ किए जाने वाले वर्शन पर अपग्रेड कर सकें.
• [C-SR-3] यूएसबी बैटरी चार्जिंग स्पेसिफ़िकेशन, रिविज़न 1.2 में बताए गए तरीके के मुताबिक, एचएस चिर्प और ट्रैफ़िक के दौरान 1.5 ए करंट खींचने की सुविधा लागू करनी चाहिए. मौजूदा और नए Android डिवाइसों के लिए, इन ज़रूरी शर्तों को पूरा करने का सुझाव दिया जाता है, ताकि वे आने वाले समय में प्लैटफ़ॉर्म के रिलीज़ किए जाने वाले वर्शन पर अपग्रेड कर सकें.
• [C-SR-4] हमारा सुझाव है कि चार्ज करने के ऐसे मालिकाना तरीकों का इस्तेमाल न करें जो Vbus वोल्टेज को डिफ़ॉल्ट लेवल से ज़्यादा कर दें या सिंक/सोर्स की भूमिकाओं में बदलाव कर दें. ऐसा करने पर, USB Power Delivery के स्टैंडर्ड तरीकों के साथ काम करने वाले चार्जर या डिवाइसों के साथ इंटरऑपरेबिलिटी से जुड़ी समस्याएं हो सकती हैं. हालांकि, इसे "इसका सुझाव ज़रूर दिया जाता है" के तौर पर बताया गया है, लेकिन आने वाले समय में Android के वर्शन में, हो सकता है कि हम सभी टाइप-C डिवाइसों के लिए, स्टैंडर्ड टाइप-C चार्जर के साथ पूरी तरह से काम करने की ज़रूरी शर्त लागू करें.
• [C-SR-5] अगर डिवाइस में टाइप-सी यूएसबी और यूएसबी होस्ट मोड की सुविधा है, तो डेटा के लिए पावर डिलीवरी और पावर रोल स्वैपिंग की सुविधा का इस्तेमाल करने का सुझाव दिया जाता है.
• यह डिवाइस, ज़्यादा वोल्टेज चार्जिंग के लिए पावर डिलीवरी की सुविधा के साथ-साथ, डिसप्ले आउट जैसे अन्य मोड के साथ काम करना चाहिए.
• Android SDK टूल के दस्तावेज़ में बताए गए तरीके से, Android Open Accessory (AOA) API और स्पेसिफ़िकेशन को लागू करना चाहिए.

अगर डिवाइस में यूएसबी पोर्ट और AOA स्पेसिफ़िकेशन लागू किया गया है, तो:

• [C-2-1] यह ज़रूरी है कि आपने हार्डवेयर की सुविधा के साथ काम करने के बारे में बताया हो android.hardware.usb.accessory.
• [C-2-2] यूएसबी स्टोरेज क्लास में, यूएसबी स्टोरेज के इंटरफ़ेस की जानकारी वाली iInterface स्ट्रिंग के आखिर में "android" स्ट्रिंग ज़रूर होनी चाहिए

7.7.2. यूएसबी होस्ट मोड

अगर डिवाइस में होस्ट मोड के साथ काम करने वाला यूएसबी पोर्ट शामिल है, तो:

• [C-1-1] Android SDK में बताए गए तरीके के मुताबिक, Android यूएसबी होस्ट एपीआई को लागू करना ज़रूरी है. साथ ही, हार्डवेयर की सुविधा android.hardware.usb.host के साथ काम करने की जानकारी देना ज़रूरी है.
• [C-1-2] स्टैंडर्ड यूएसबी डिवाइसों को कनेक्ट करने के लिए, डिवाइस में इस सुविधा को लागू करना ज़रूरी है. इसका मतलब है कि डिवाइस में इनमें से कोई एक सुविधा होनी चाहिए:
  • डिवाइस में टाइप-सी पोर्ट होना चाहिए या डिवाइस में मौजूद मालिकाना पोर्ट को स्टैंडर्ड यूएसबी टाइप-सी पोर्ट (यूएसबी टाइप-सी डिवाइस) में बदलने वाली केबल के साथ शिप किया जाना चाहिए.
  • डिवाइस में यूएसबी टाइप-A पोर्ट होना चाहिए या डिवाइस में मौजूद मालिकाना पोर्ट को स्टैंडर्ड यूएसबी टाइप-A पोर्ट में बदलने वाली केबल के साथ डिवाइस को शिप किया जाना चाहिए.
  • डिवाइस में माइक्रो-AB पोर्ट होना चाहिए. साथ ही, डिवाइस के साथ एक केबल भी होनी चाहिए, जो स्टैंडर्ड टाइप-A पोर्ट के साथ काम करती हो.
• [C-1-3] डिवाइस को यूएसबी टाइप A या माइक्रो-AB पोर्ट से टाइप-C पोर्ट (जगह) में बदलने वाले अडैप्टर के साथ शिप नहीं किया जाना चाहिए.
• [C-SR-1] हमारा सुझाव है कि आप Android SDK के दस्तावेज़ में बताए गए तरीके से, यूएसबी ऑडियो क्लास को लागू करें.
• होस्ट मोड में, कनेक्ट किए गए यूएसबी डिवाइस को चार्ज करने की सुविधा होनी चाहिए. साथ ही, यूएसबी टाइप-सी कनेक्टर के लिए, यूएसबी टाइप-सी केबल और कनेक्टर स्पेसिफ़िकेशन रिविज़न 1.2 के टर्मिनेशन पैरामीटर सेक्शन में बताए गए मुताबिक, कम से कम 1.5 ऐंपियर का सोर्स करंट दिखाना चाहिए. इसके अलावा, माइक्रो-एबी कनेक्टर के लिए, यूएसबी बैटरी चार्जिंग स्पेसिफ़िकेशन, रिविज़न 1.2 में बताए गए मुताबिक, चार्जिंग डाउनस्ट्रीम पोर्ट (सीडीपी) आउटपुट करंट की रेंज का इस्तेमाल करना चाहिए.
• यूएसबी टाइप-सी स्टैंडर्ड को लागू और इस्तेमाल करना चाहिए.

अगर डिवाइस में होस्ट मोड और यूएसबी ऑडियो क्लास के साथ काम करने वाला यूएसबी पोर्ट शामिल है, तो:

• [C-2-1] यह यूएसबी एचआईडी क्लास के साथ काम करना चाहिए.
• [C-2-2] यह ज़रूरी है कि डिवाइस, यूएसबी एचआईडी के इस्तेमाल से जुड़ी टेबल और वॉइस कमांड के इस्तेमाल से जुड़े अनुरोध में बताए गए एचआईडी डेटा फ़ील्ड का पता लगा सके और उन्हें KeyEvent के साथ मैप कर सके. इन फ़ील्ड के नाम नीचे दिए गए हैं:
  • इस्तेमाल का पेज (0xC) इस्तेमाल का आईडी (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
  • इस्तेमाल का पेज (0xC) इस्तेमाल का आईडी (0x0E9): KEYCODE_VOLUME_UP
  • इस्तेमाल का पेज (0xC) इस्तेमाल का आईडी (0x0EA): KEYCODE_VOLUME_DOWN
  • इस्तेमाल का पेज (0xC) इस्तेमाल का आईडी (0x0CF): KEYCODE_VOICE_ASSIST

अगर डिवाइस में होस्ट मोड और स्टोरेज ऐक्सेस फ़्रेमवर्क (SAF) के साथ काम करने वाला यूएसबी पोर्ट शामिल है, तो:

• [C-3-1] यह ज़रूरी है कि ऐप्लिकेशन, रिमोट से कनेक्ट किए गए किसी भी MTP (मीडिया ट्रांसफ़र प्रोटोकॉल) डिवाइस को पहचाने और ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, और ACTION_CREATE_DOCUMENT इंटेंट की मदद से उनके कॉन्टेंट को ऐक्सेस करने की सुविधा दे. .

अगर डिवाइस में होस्ट मोड और यूएसबी टाइप-सी के साथ काम करने वाला यूएसबी पोर्ट शामिल है, तो:

• [C-4-1] यूएसबी टाइप-सी स्पेसिफ़िकेशन (सेक्शन 4.5.1.3.3) में बताए गए डबल रोल पोर्ट फ़ंक्शन को लागू करना ज़रूरी है. जिन डिवाइसों में 3.5 मिमी ऑडियो जैक होता है उनमें ड्यूअल रोल पोर्ट के लिए, यूएसबी सिंक डिटेक्शन (होस्ट मोड) डिफ़ॉल्ट रूप से बंद हो सकता है. हालांकि, उपयोगकर्ता के पास इसे चालू करने का विकल्प होना चाहिए.
• [C-SR-2] हमारा सुझाव है कि डिसप्लेपोर्ट के साथ काम करने वाले डिवाइसों का इस्तेमाल करें. साथ ही, यह भी ज़रूरी है कि वे यूएसबी सुपरस्पीड डेटा रेट के साथ काम करते हों. हमारा सुझाव है कि डेटा और पावर की भूमिका बदलने के लिए, डिवाइसों में पावर डिलीवरी की सुविधा भी होनी चाहिए.
• [C-SR-3] हमारा सुझाव है कि आप यूएसबी टाइप-सी केबल और कनेक्टर स्पेसिफ़िकेशन रिविज़न 1.2 के परिशिष्ट A में बताए गए तरीके के मुताबिक, ऑडियो अडैप्टर ऐक्सेसरी मोड का इस्तेमाल न करें.
• डिवाइस के फ़ॉर्म फ़ैक्टर के हिसाब से, Try.* मॉडल को लागू करना चाहिए. उदाहरण के लिए, हैंडहेल्ड डिवाइस पर Try.SNK मॉडल लागू किया जाना चाहिए.

7.8. ऑडियो

7.8.1. माइक्रोफ़ोन

अगर डिवाइस में माइक्रोफ़ोन शामिल है, तो:

• [C-1-1] android.hardware.microphone फ़ीचर कॉन्सटेंट की रिपोर्ट करना ज़रूरी है.
• [C-1-2] यह सेक्शन 5.4 में बताई गई ऑडियो रिकॉर्डिंग से जुड़ी ज़रूरी शर्तों को पूरा करता हो.
• [C-1-3] इसे सेक्शन 5.6 में बताई गई, ऑडियो के इंतज़ार के समय से जुड़ी ज़रूरी शर्तों को पूरा करना होगा.
• [C-SR-1] हमारा सुझाव है कि आप सेक्शन 7.8.3 में बताए गए तरीके से, नियर-अल्ट्रासाउंड रिकॉर्डिंग की सुविधा दें.

अगर डिवाइस में माइक्रोफ़ोन नहीं है, तो:

• [C-2-1] android.hardware.microphone फ़ीचर कॉन्स्टेंट की रिपोर्ट नहीं करनी चाहिए.
• [C-2-2] सेक्शन 7 के मुताबिक, ऑडियो रिकॉर्डिंग एपीआई को कम से कम नो-ऑप के तौर पर लागू करना ज़रूरी है.

7.8.2. ऑडियो आउटपुट

अगर डिवाइस में ऑडियो आउटपुट वाले किसी डिवाइस के लिए स्पीकर या ऑडियो/मल्टीमीडिया आउटपुट पोर्ट शामिल है, तो:

• [C-1-1] android.hardware.audio.output फ़ीचर कॉन्सटेंट की रिपोर्ट करना ज़रूरी है.
• [C-1-2] ऐप्लिकेशन को सेक्शन 5.5 में बताई गई, ऑडियो चलाने से जुड़ी ज़रूरी शर्तों को पूरा करना होगा.
• [C-1-3] इसे सेक्शन 5.6 में बताई गई, ऑडियो के इंतज़ार के समय से जुड़ी ज़रूरी शर्तों को पूरा करना होगा.
• [C-SR-1] हमारा सुझाव है कि आप सेक्शन 7.8.3 में बताए गए तरीके से, नियर-अल्ट्रासाउंड प्लेबैक की सुविधा उपलब्ध कराएं.

अगर डिवाइस में स्पीकर या ऑडियो आउटपुट पोर्ट शामिल नहीं है, तो:

• [C-2-1] android.hardware.audio.output सुविधा की शिकायत नहीं की जानी चाहिए.
• [C-2-2] ऑडियो आउटपुट से जुड़े एपीआई को कम से कम नो-ऑप के तौर पर लागू करना ज़रूरी है.

इस सेक्शन के लिए, "आउटपुट पोर्ट" एक ऐसा फ़िज़िकल इंटरफ़ेस है, जैसे कि 3.5 मि॰मी॰ ऑडियो जैक, एचडीएमआई या यूएसबी ऑडियो क्लास वाला यूएसबी होस्ट मोड पोर्ट. ब्लूटूथ, वाई-फ़ाई या मोबाइल नेटवर्क जैसे रेडियो-आधारित प्रोटोकॉल पर ऑडियो आउटपुट की सुविधा, "आउटपुट पोर्ट" के तौर पर शामिल नहीं की जा सकती.

7.8.2.1. ऐनालॉग ऑडियो पोर्ट

अगर डिवाइस में एक या एक से ज़्यादा एनालॉग ऑडियो पोर्ट शामिल हैं, तो वे हेडसेट और अन्य ऑडियो ऐक्सेसरी के साथ काम कर सकेंगे. इसके लिए, ज़रूरी है कि वे Android के सभी प्लैटफ़ॉर्म पर 3.5 मि॰मी॰ के ऑडियो प्लग का इस्तेमाल करते हों. साथ ही, ये बातें भी ज़रूरी हैं:

• [C-SR-1] हमारा सुझाव है कि कम से कम एक ऑडियो पोर्ट, चार कंडक्टर वाला 3.5mm ऑडियो जैक हो.

अगर डिवाइस में चार कंडक्टर वाला 3.5 मि॰मी॰ का ऑडियो जैक है, तो:

• [C-1-1] माइक्रोफ़ोन वाले स्टीरियो हेडफ़ोन और स्टीरियो हेडसेट पर ऑडियो चलाने की सुविधा होनी चाहिए.
• [C-1-2] CTIA पिन-आउट ऑर्डर के साथ TRRS ऑडियो प्लग काम करने चाहिए.
• [C-1-3] ऑडियो प्लग पर माइक्रोफ़ोन और ग्राउंड कंडक्टर के बीच, इवैलेंट इंपेडेन्स की इन तीन रेंज के लिए, कीकोड का पता लगाने और उन्हें मैप करने की सुविधा होनी चाहिए:
  • 70 ओम या उससे कम: KEYCODE_HEADSETHOOK
  • 210-290 ओम: KEYCODE_VOLUME_UP
  • 360-680 ओम: KEYCODE_VOLUME_DOWN
• [C-1-4] प्लग डालने पर ACTION_HEADSET_PLUG को ट्रिगर करना चाहिए, लेकिन ऐसा तब ही करना चाहिए, जब प्लग के सभी संपर्क, जैक पर अपने काम के सेगमेंट को छू रहे हों.
• [C-1-5] यह ज़रूरी है कि यह 32 ओम के स्पीकर इंपेडेन्स पर, कम से कम 150mV ± 10% का आउटपुट वोल्टेज दे सके.
• [C-1-6] माइक्रोफ़ोन का बायस वोल्टेज 1.8V से 2.9V के बीच होना चाहिए.
• [C-1-7] ऑडियो प्लग पर माइक्रोफ़ोन और ग्राउंड कंडक्टर के बीच, इवैलेंट इंपेडेन्स की इस रेंज के लिए, कीकोड का पता लगाना और उसे मैप करना ज़रूरी है:
  • 110-180 ओम: KEYCODE_VOICE_ASSIST
• [C-SR-2] हमारा सुझाव है कि आप OMTP पिन-आउट ऑर्डर वाले ऑडियो प्लग का इस्तेमाल करें.
• [C-SR-3] हमारा सुझाव है कि माइक्रोफ़ोन वाले स्टीरियो हेडसेट से ऑडियो रिकॉर्डिंग की सुविधा उपलब्ध कराएं.

अगर डिवाइस में चार कंडक्टर वाला 3.5 मि॰मी॰ का ऑडियो जैक है और वह माइक्रोफ़ोन के साथ काम करता है, तो android.intent.action.HEADSET_PLUG को माइक्रोफ़ोन की वैल्यू 1 के तौर पर सेट करके ब्रॉडकास्ट किया जा सकता है. ऐसा करने पर:

• [C-2-1] प्लग-इन की गई ऑडियो ऐक्सेसरी के माइक्रोफ़ोन का पता लगाने की सुविधा होनी चाहिए.

7.8.2.2. डिजिटल ऑडियो पोर्ट

डिवाइस से जुड़ी ज़रूरी शर्तों के बारे में जानने के लिए, सेक्शन 2.2.1 देखें.

7.8.3. नियर-अल्ट्रासाउंड

नियर-अल्ट्रासोनिक ऑडियो, 18.5 किलोहर्ट्ज़ से 20 किलोहर्ट्ज़ बैंड में होता है.

डिवाइस पर लागू करने के तरीके:

• AudioManager.getProperty एपीआई की मदद से, यह सही तरीके से बताना चाहिए कि डिवाइस पर नियर-अल्ट्रासाउंड ऑडियो की सुविधा काम करती है या नहीं. इसके लिए, यह तरीका अपनाएं:

अगर PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND "सही" है, तो VOICE_RECOGNITION और UNPROCESSED ऑडियो सोर्स को इन ज़रूरी शर्तों को पूरा करना होगा:

• [C-1-1] 18.5 kHz से 20 kHz बैंड में माइक्रोफ़ोन की औसत पावर रिस्पॉन्स, 2 kHz पर रिस्पॉन्स से 15 dB से ज़्यादा नहीं होनी चाहिए.
• [C-1-2] माइक्रोफ़ोन का बिना वेट किए गए सिग्नल-टू-नॉइज़ रेशियो, 18.5 केएचज़ से 20 केएचज़ के बीच होना चाहिए. साथ ही, -26 डीबीएफ़एस पर 19 केएचज़ टोन के लिए, यह रेशियो 50 डीबी से कम नहीं होना चाहिए.

अगर PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND "सही" है, तो:

• [C-2-1] स्पीकर का औसत रिस्पॉन्स, 18.5 kHz से 20 kHz के बीच, 2 kHz के रिस्पॉन्स से कम से कम 40 dB कम होना चाहिए.

7.8.4. सिग्नल इंटिग्रिटी

डिवाइस पर लागू करने के तरीके:

• यह हैंडहेल्ड डिवाइसों पर, इनपुट और आउटपुट, दोनों स्ट्रीम के लिए गड़बड़ी-मुक्त ऑडियो सिग्नल पाथ उपलब्ध कराएगा. इसका मतलब है कि हर पाथ के लिए एक मिनट के टेस्ट के दौरान, कोई गड़बड़ी नहीं हुई. OboeTester के "गड़बड़ी की ऑटोमेटेड जांच" का इस्तेमाल करके जांच करें.

जांच के लिए, ऑडियो लूपबैक डोंगल की ज़रूरत होती है. इसे सीधे 3.5 मि॰मी॰ जैक में और/या यूएसबी-सी से 3.5 मि॰मी॰ अडैप्टर के साथ इस्तेमाल किया जाता है. सभी ऑडियो आउटपुट पोर्ट की जांच की जानी चाहिए.

फ़िलहाल, OboeTester में AAudio पाथ काम करते हैं. इसलिए, AAudio का इस्तेमाल करके, इन कॉम्बिनेशन की जांच की जानी चाहिए:

परफ़ॉर्मेंस मोड	शेयर करें	आउटपुट सैंपल रेट	चैनल	आउट चान
LOW_LATENCY	खास	जानकारी उपलब्ध नहीं है	1	2
LOW_LATENCY	खास	जानकारी उपलब्ध नहीं है	2	1
LOW_LATENCY	शेयर किया गया	जानकारी उपलब्ध नहीं है	1	2
LOW_LATENCY	शेयर किया गया	जानकारी उपलब्ध नहीं है	2	1
कोई नहीं	शेयर किया गया	48000	1	2
कोई नहीं	शेयर किया गया	48000	2	1
कोई नहीं	शेयर किया गया	44100	1	2
कोई नहीं	शेयर किया गया	44100	2	1
कोई नहीं	शेयर किया गया	16000	1	2
कोई नहीं	शेयर किया गया	16000	2	1

किसी भरोसेमंद स्ट्रीम को, 2000 हर्ट्ज़ साइन के लिए, सिग्नल-टू-नॉइज़ रेशियो (एसएनआर) और कुल हार्मोनिक डिस्टॉर्शन (टीएचडी) से जुड़ी ये शर्तें पूरी करनी चाहिए.

ट्रांसड्यूसर	THD	एसएनआर
डिवाइस में पहले से मौजूद मुख्य स्पीकर, जिसे बाहरी रेफ़रंस माइक्रोफ़ोन का इस्तेमाल करके मेज़र किया जाता है	< 3.0%	>= 50 dB
डिवाइस में पहले से मौजूद मुख्य माइक्रोफ़ोन, जिसे बाहरी रेफ़रंस स्पीकर का इस्तेमाल करके मेज़र किया जाता है	< 3.0%	>= 50 dB
पहले से मौजूद एनालॉग 3.5 मि॰मी॰ जैक, जिनकी जांच लूपबैक अडैप्टर का इस्तेमाल करके की गई है	< 1%	>= 60 dB
फ़ोन के साथ दिए गए यूएसबी अडैप्टर, जिन्हें लूपबैक अडैप्टर का इस्तेमाल करके टेस्ट किया गया है	< 1.0%	>= 60 dB

7.9. आभासी वास्तविकता

Android में "वर्चुअल रिएलिटी" (वीआर) ऐप्लिकेशन बनाने के लिए एपीआई और सुविधाएं शामिल हैं. इनमें मोबाइल पर वीआर का बेहतरीन अनुभव भी शामिल है. डिवाइस पर लागू किए गए एपीआई और उनके काम करने के तरीके, इस सेक्शन में बताए गए तरीके के मुताबिक होने चाहिए.

7.9.1. वर्चुअल रिएलिटी मोड

Android में वीआर मोड की सुविधा उपलब्ध है. यह सुविधा, सूचनाओं को स्टीरियोस्कोपिक रेंडरिंग के तौर पर दिखाती है. साथ ही, वीआर ऐप्लिकेशन पर फ़ोकस होने पर, मोनोस्कोपिक सिस्टम यूज़र इंटरफ़ेस (यूआई) कॉम्पोनेंट को बंद कर देती है.

7.9.2. वर्चुअल रिएलिटी मोड - बेहतर परफ़ॉर्मेंस

अगर डिवाइस पर वीआर मोड काम करता है, तो:

• [C-1-1] इसमें कम से कम दो फ़िज़िकल कोर होने चाहिए.
• [C-1-2] android.hardware.vr.high_performance सुविधा का एलान करना ज़रूरी है.
• [C-1-3] यह ज़रूरी है कि डिवाइस में बेहतर परफ़ॉर्मेंस मोड की सुविधा काम करती हो.
• [C-1-4] यह ज़रूरी है कि ऐप्लिकेशन, OpenGL ES 3.2 के साथ काम करे.
• [C-1-5] android.hardware.vulkan.level 0 के साथ काम करना चाहिए.
• यह android.hardware.vulkan.level 1 या इसके बाद के वर्शन के साथ काम करना चाहिए.
• [C-1-6] EGL_KHR_mutable_render_buffer, EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_get_native_client_buffer, EGL_KHR_fence_sync, EGL_KHR_wait_sync, EGL_IMG_context_priority, EGL_EXT_protected_content, EGL_EXT_image_gl_colorspace को लागू करना ज़रूरी है. साथ ही, उपलब्ध ईजीएल एक्सटेंशन की सूची में एक्सटेंशन दिखाएं.
• [C-1-8] GL_EXT_multisampled_render_to_texture2, GL_OVR_multiview, GL_OVR_multiview2, GL_EXT_protected_textures को लागू करना ज़रूरी है. साथ ही, उपलब्ध GL एक्सटेंशन की सूची में एक्सटेंशन दिखाना ज़रूरी है.
• [C-SR-1] हमारा सुझाव है कि आप GL_EXT_external_buffer, GL_EXT_EGL_image_array, GL_OVR_multiview_multisampled_render_to_texture को लागू करें. साथ ही, उपलब्ध GL एक्सटेंशन की सूची में एक्सटेंशन दिखाएं.
• [C-SR-2] हमारा सुझाव है कि आप Vulkan 1.1 का इस्तेमाल करें.
• [C-SR-3] हमारा सुझाव है कि आप VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing, VK_KHR_shared_presentable_image को लागू करें और इसे उपलब्ध Vulkan एक्सटेंशन की सूची में शामिल करें.
• [C-SR-4] हमारा सुझाव है कि कम से कम एक Vulkan कतार फ़ैमिली को एक्सपोज़ करें, जिसमें flags में VK_QUEUE_GRAPHICS_BIT और VK_QUEUE_COMPUTE_BIT, दोनों शामिल हों और queueCount कम से कम दो हो.
• [C-1-7] जीपीयू और डिसप्ले को शेयर किए गए फ़्रंट बफ़र का ऐक्सेस सिंक करना होगा, ताकि दो रेंडर कॉन्टेक्स्ट के साथ 60fps पर, वैकल्पिक आंखों से रेंडर किए गए वीआर कॉन्टेंट को बिना किसी टियरिंग आर्टफ़ैक्ट के दिखाया जा सके.
• [C-1-9] NDK में बताए गए तरीके के मुताबिक, AHardwareBuffer फ़्लैग AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA और AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT के लिए, सहायता लागू करना ज़रूरी है.
• [C-1-10] AHardwareBuffer के लिए, इस्तेमाल के फ़्लैग के किसी भी कॉम्बिनेशन के साथ काम करने की सुविधा लागू करना ज़रूरी है. यह सुविधा, कम से कम इन फ़ॉर्मैट के लिए लागू होनी चाहिए: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUTAHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGEAHARDWAREBUFFER_USAGE_PROTECTED_CONTENT
• [C-SR-5] हमारा सुझाव है कि C-1-10 में बताई गई एक से ज़्यादा लेयर, फ़्लैग, और फ़ॉर्मैट के साथ AHardwareBuffers को असाइन करने की सुविधा जोड़ी जाए.
• [C-1-11] यह ज़रूरी है कि डिवाइस, कम से कम 3840 x 2160 रिज़ॉल्यूशन और 30 एफ़पीएस (फ़्रेम प्रति सेकंड) पर H.264 डिकोडिंग की सुविधा दे. साथ ही, वीडियो को औसतन 40 एमबीपीएस तक कंप्रेस किया जा सके. यह 30 एफ़पीएस और 10 एमबीपीएस पर 1920 x 1080 रिज़ॉल्यूशन के चार इंस्टेंस या 60 एफ़पीएस और 20 एमबीपीएस पर 1920 x 1080 रिज़ॉल्यूशन के दो इंस्टेंस के बराबर है.
• [C-1-12] यह एचईवीसी और VP9 के साथ काम करना चाहिए. साथ ही, यह कम से कम 1920 x 1080 रिज़ॉल्यूशन के वीडियो को 30 FPS पर, औसतन 10 एमबीपीएस तक कंप्रेस करके डिकोड कर सकता हो. साथ ही, यह 3840 x 2160 रिज़ॉल्यूशन के वीडियो को 30 FPS-20 एमबीपीएस पर डिकोड कर सकता हो. यह 30 FPS-5 एमबीपीएस पर, 1920 x 1080 रिज़ॉल्यूशन के चार वीडियो के बराबर है.
• [C-1-13] यह HardwarePropertiesManager.getDeviceTemperatures एपीआई के साथ काम करना चाहिए और त्वचा के तापमान की सटीक वैल्यू दिखानी चाहिए.
• [C-1-14] में एम्बेड की गई स्क्रीन होनी चाहिए और उसका रिज़ॉल्यूशन कम से कम 1920 x 1080 होना चाहिए.
• [C-SR-6] हमारा सुझाव है कि आपके डिसप्ले का रिज़ॉल्यूशन कम से कम 2560 x 1440 हो.
• [C-1-15] VR मोड में डिसप्ले को कम से कम 60 हर्ट्ज़ पर अपडेट होना चाहिए.
• [C-1-17] डिसप्ले में कम-टिकट वाला मोड होना चाहिए, जिसमें टिकट की अवधि 5 मिलीसेकंड से कम हो. टिकट की अवधि का मतलब है कि पिक्सल कितनी देर तक लाइट उत्सर्जित कर रहा है.
• [C-1-18] यह ज़रूरी है कि डिवाइस, ब्लूटूथ 4.2 और ब्लूटूथ एलई डेटा लेंथ एक्सटेंशन के साथ काम करता हो सेक्शन 7.4.3.
• [C-1-19] यहां दिए गए सभी डिफ़ॉल्ट सेंसर टाइप के लिए, डायरेक्ट चैनल टाइप के साथ काम करना चाहिए और उसे सही तरीके से रिपोर्ट करना चाहिए:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED
• [C-SR-7] हमारा सुझाव है कि आप ऊपर दिए गए सभी डायरेक्ट चैनल टाइप के लिए, TYPE_HARDWARE_BUFFER डायरेक्ट चैनल टाइप का इस्तेमाल करें.
• [C-1-21] android.hardware.hifi_sensors के लिए, जाइरोस्कोप, एक्सलरोमीटर, और मैग्नेटोमीटर से जुड़ी ज़रूरी शर्तें पूरी करनी ज़रूरी हैं. इन शर्तों के बारे में सेक्शन 7.3.9 में बताया गया है.
• [C-SR-8] हमारा सुझाव है कि आप android.hardware.sensor.hifi_sensors सुविधा का इस्तेमाल करें.
• [C-1-22] एंड-टू-एंड मोशन से फ़ोटोन के बीच लगने वाला समय 28 मिलीसेकंड से ज़्यादा नहीं होना चाहिए.
• [C-SR-9] हमारा सुझाव है कि मोशन से फ़ोटोन तक का इंतज़ार का समय 20 मिलीसेकंड से ज़्यादा न हो.
• [C-1-23] वीडियो में पहले फ़्रेम का अनुपात होना चाहिए. यह अनुपात, काले से सफ़ेद में ट्रांज़िशन के बाद पहले फ़्रेम के पिक्सल की चमक और स्थिर स्थिति में सफ़ेद पिक्सल की चमक के बीच का अनुपात होता है. यह अनुपात कम से कम 85% होना चाहिए.
• [C-SR-10] हमारा सुझाव है कि पहले फ़्रेम का अनुपात कम से कम 90% हो.
• फ़ोरग्राउंड ऐप्लिकेशन के लिए एक खास कोर उपलब्ध करा सकता है. साथ ही, Process.getExclusiveCores एपीआई के साथ काम करके, टॉप फ़ोरग्राउंड ऐप्लिकेशन के लिए खास तौर पर उपलब्ध सीपीयू कोर की संख्या दिखा सकता है.

अगर एक्सक्लूज़िव कोर काम करता है, तो कोर:

• [C-2-1] ऐप्लिकेशन के इस्तेमाल किए गए डिवाइस ड्राइवर के अलावा, किसी भी अन्य यूज़रस्पेस प्रोसेस को उस पर चलने की अनुमति नहीं देनी चाहिए. हालांकि, ज़रूरत पड़ने पर कुछ कर्नेल प्रोसेस को चलने की अनुमति दी जा सकती है.

7.10. हैप्टिक

नई ज़रूरी शर्तें लागू करना

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

अगर डिवाइस में सामान्य तौर पर इस्तेमाल होने वाला ऐसा हैप्टिक ऐक्ट्यूएटर शामिल नहीं है, तो:

• [7.10/C] Vibrator.hasVibrator() के लिए, false दिखाना ज़रूरी है.

अगर डिवाइस में कम से कम एक ऐसा सामान्य हैप्टिक ऐक्ट्यूएटर शामिल है, तो:

• [C-1-1] Vibrator.hasVibrator() के लिए, TRUE दिखाना ज़रूरी है.
• एक्ससेंट्रिक रोटेटेड मैस (ईआरएम) हैप्टिक ऐक्चुएटर (वाइब्रेटर) का इस्तेमाल नहीं करना चाहिए.
• android.view.HapticFeedbackConstants में साफ़ हप्टिक्स के लिए, सभी सार्वजनिक कॉन्स्टेंट लागू करने चाहिए. जैसे, (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY, VIRTUAL_KEY_RELEASE, CONFIRM, REJECT, GESTURE_START, और GESTURE_END).
• android.os.VibrationEffect में साफ़ हप्टिक्स के लिए सभी सार्वजनिक कॉन्स्टेंट लागू करने चाहिए, जैसे कि (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK, और EFFECT_DOUBLE_CLICK). साथ ही, android.os.VibrationEffect.Composition में रिच हप्टिक्स के लिए सभी संभावित सार्वजनिक PRIMITIVE_* कॉन्स्टेंट लागू करने चाहिए, जैसे कि (CLICK, TICK, LOW_TICK, QUICK_FALL, QUICK_RISE, SLOW_RISE, SPIN, THUD). इनमें से कुछ प्राइमिटिव, जैसे कि LOW_TICK और SPIN सिर्फ़ तब काम कर सकते हैं, जब वाइब्रेटर कम फ़्रीक्वेंसी के साथ काम कर सकता हो.
• android.view.HapticFeedbackConstants में, सार्वजनिक कॉन्स्टेंट को मैप करने के लिए दिशा-निर्देशों का पालन करना चाहिए. साथ ही, सुझाई गई android.os.VibrationEffect कॉन्स्टेंट के साथ, एम्प्लitude के संबंधों का पालन करना चाहिए.
• इन लिंक किए गए हैप्टिक कॉन्स्टेंट मैपिंग का इस्तेमाल करना चाहिए.
• createOneShot() और createWaveform() एपीआई के लिए, क्वालिटी की जांच की प्रक्रिया का पालन करना चाहिए.
• यह पुष्टि करनी चाहिए कि सार्वजनिक android.os.Vibrator.hasAmplitudeControl() एपीआई के नतीजे से, उनके वाइब्रेटर की क्षमताओं के बारे में सही जानकारी मिलती हो.
• android.os.Vibrator.hasAmplitudeControl() को चलाकर, ऐम्प्लिटीड को स्केल करने की क्षमताओं की पुष्टि करनी चाहिए.

अगर डिवाइस में हैप्टिक कंसटेंट मैपिंग का इस्तेमाल किया जाता है, तो:

• android.os.Vibrator.areAllEffectsSupported() और android.os.Vibrator.arePrimitivesSupported() एपीआई चलाकर, लागू होने की स्थिति की पुष्टि करनी चाहिए.
• आपको वाइब्रेशन के कॉन्स्टेंट के लिए, क्वालिटी का आकलन करना चाहिए.
• कॉन्स्टेंट के लिए लागू करने के दिशा-निर्देशों में बताए गए तरीके के मुताबिक, काम न करने वाले प्राइमिटिव के लिए फ़ॉलबैक कॉन्फ़िगरेशन की पुष्टि करनी चाहिए और ज़रूरत पड़ने पर उसे अपडेट करना चाहिए.
• यहां बताए गए तरीके के मुताबिक, फ़ॉलबैक सहायता देनी चाहिए, ताकि प्रॉडक्ट नाकामयाब होने का जोखिम कम हो.

नई ज़रूरी शर्तें खत्म करना

डिवाइस से जुड़ी ज़रूरी शर्तों के बारे में जानने के लिए, सेक्शन 2.2.1 देखें.

7.11. मीडिया की परफ़ॉर्मेंस क्लास

डिवाइस पर लागू किए गए मीडिया की परफ़ॉर्मेंस क्लास, android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS एपीआई से ली जा सकती है. मीडिया परफ़ॉर्मेंस क्लास के लिए ज़रूरी शर्तें, R (वर्शन 30) से शुरू होने वाले हर Android वर्शन के लिए तय की गई हैं. 0 की खास वैल्यू से पता चलता है कि डिवाइस, मीडिया परफ़ॉर्मेंस क्लास का नहीं है.

अगर डिवाइस पर लागू किए गए बदलावों की वजह से, android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS के लिए शून्य से ज़्यादा वैल्यू दिखती है, तो:

• [C-1-1] फ़ंक्शन को कम से कम android.os.Build.VERSION_CODES.R की वैल्यू दिखानी चाहिए.

• [C-1-2] यह हैंडहेल्ड डिवाइस पर लागू होना चाहिए.

• [C-1-3] सेक्शन 2.2.7 में बताई गई "मीडिया परफ़ॉर्मेंस क्लास" की सभी ज़रूरी शर्तें पूरी करनी होंगी.

दूसरे शब्दों में, Android T में मीडिया परफ़ॉर्मेंस क्लास की जानकारी सिर्फ़ उन डिवाइसों के लिए दी गई है जिनमें T, S या R वर्शन है.

डिवाइस के हिसाब से ज़रूरी शर्तों के बारे में जानने के लिए, सेक्शन 2.2.7 देखें.

8. परफ़ॉर्मेंस और पावर

परफ़ॉर्मेंस और पावर से जुड़ी कुछ बुनियादी शर्तें, उपयोगकर्ता अनुभव के लिए ज़रूरी हैं. साथ ही, इनसे ऐप्लिकेशन डेवलप करते समय, डेवलपर की बुनियादी मान्यताओं पर असर पड़ता है.

8.1. उपयोगकर्ता अनुभव में एकरूपता

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

8.2. फ़ाइल I/O ऐक्सेस की परफ़ॉर्मेंस

ऐप्लिकेशन के निजी डेटा स्टोरेज (/data पार्टीशन) पर फ़ाइल ऐक्सेस करने की परफ़ॉर्मेंस को एक जैसा रखने के लिए, एक सामान्य आधार उपलब्ध कराने से, ऐप्लिकेशन डेवलपर को सही उम्मीद सेट करने में मदद मिलती है. इससे, उन्हें अपने सॉफ़्टवेयर के डिज़ाइन में मदद मिलती है. डिवाइस के टाइप के हिसाब से, डिवाइस पर लागू करने के लिए, सेक्शन 2 में बताई गई कुछ ज़रूरी शर्तें पूरी करनी पड़ सकती हैं. ये शर्तें, नीचे दिए गए पढ़ने और लिखने के ऑपरेशन के लिए हैं:

• सीक्वेंशियल राइटिंग की परफ़ॉर्मेंस. इसे मेज़र करने के लिए, 10 एमबी के लिखने वाले बफ़र का इस्तेमाल करके 256 एमबी की फ़ाइल लिखी जाती है.
• रैंडम तौर पर डेटा लिखने की परफ़ॉर्मेंस. इसे मेज़र करने के लिए, 4 केबी के लिखने वाले बफ़र का इस्तेमाल करके 256 एमबी की फ़ाइल लिखी जाती है.
• सीक्वेंशियल रीड परफ़ॉर्मेंस. इसे 10 एमबी के राइट बफ़र का इस्तेमाल करके, 256 एमबी की फ़ाइल पढ़कर मेज़र किया जाता है.
• रैंडम रीड परफ़ॉर्मेंस. इसे मेज़र करने के लिए, 4 केबी के लिखने वाले बफ़र का इस्तेमाल करके 256 एमबी की फ़ाइल को पढ़ा जाता है.

8.3. बैटरी सेव करने वाले मोड

अगर डिवाइस में लागू की गई सुविधाओं में, डिवाइस की बैटरी मैनेजमेंट को बेहतर बनाने के लिए AOSP में शामिल सुविधाएं (जैसे, ऐप्लिकेशन स्टैंडबाय बकेट, Doze) शामिल हैं या RESTRICTED App Standby Bucket से ज़्यादा सख्त पाबंदियां लागू करने के लिए सुविधाओं को बढ़ाया गया है, तो:

• [C-1-1] ट्रिगर करने, मैनेज करने, स्मार्टवॉच को चालू करने वाले एल्गोरिदम, ग्लोबल सिस्टम सेटिंग या ऐप्लिकेशन स्टैंडबाय और Doze पावर-सेविंग मोड के DeviceConfig का इस्तेमाल करने के लिए, AOSP के तरीके से काम करना चाहिए.
• [C-1-2] ऐप्लिकेशन के स्टैंडबाय मोड के लिए, हर बकेट में ऐप्लिकेशन के लिए टास्क, अलार्म, और नेटवर्क को कम करने की सुविधा को मैनेज करने के लिए, ग्लोबल सेटिंग या DeviceConfig का इस्तेमाल करने के लिए, AOSP के तरीके से काम करना चाहिए.
• [C-1-3] ऐप्लिकेशन स्टैंडबाय के लिए इस्तेमाल की जाने वाली ऐप्लिकेशन स्टैंडबाय बकेट की संख्या के लिए, AOSP के लागू होने से अलग नहीं होना चाहिए.
• [C-1-4] पावर मैनेजमेंट में बताए गए तरीके के मुताबिक, ऐप्लिकेशन स्टैंडबाय बकेट और Doze मोड को लागू करना ज़रूरी है.
• [C-1-5] डिवाइस के पावर सेव मोड में होने पर, PowerManager.isPowerSaveMode() के लिए true दिखाना ज़रूरी है.
• [C-1-6] ऐप्लिकेशन स्टैंडबाय और Doze पावर-सेविंग मोड या बैटरी ऑप्टिमाइज़ेशन से छूट पाने वाले सभी ऐप्लिकेशन दिखाने के लिए, उपयोगकर्ता को सुविधा देनी ज़रूरी है. साथ ही, उपयोगकर्ता से किसी ऐप्लिकेशन को बैटरी ऑप्टिमाइज़ेशन को अनदेखा करने की अनुमति देने के लिए, ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS इंटेंट लागू करना ज़रूरी है.
• [C-SR-1] हमारा सुझाव है कि बैटरी सेवर मोड को चालू और बंद करने के लिए, उपयोगकर्ता को आसानी से ऐक्सेस करने की सुविधा दें.
• [C-SR-2] हमारा सुझाव है कि आप उपयोगकर्ता को उन सभी ऐप्लिकेशन को दिखाने की सुविधा दें जिन्हें ऐप्लिकेशन स्टैंडबाय और Doze मोड से छूट मिली है.

अगर डिवाइस में AOSP में शामिल, पावर मैनेजमेंट की सुविधाएं जोड़ी गई हैं और वह एक्सटेंशन, ऐप्लिकेशन के स्टैंडबाय मोड में होने पर उसकी बैटरी खर्च करने की दर से ज़्यादा पाबंदियां लगाता है, तो सेक्शन 3.5.1 देखें.

Android डिवाइस में, बिजली बचाने वाले मोड के अलावा, बेहतर कॉन्फ़िगरेशन और पावर इंटरफ़ेस (एसीपीआई) के मुताबिक, डिवाइस को स्लीप मोड में भेजने की चार स्थितियों में से किसी एक या सभी को लागू किया जा सकता है.

अगर डिवाइस में S4 पावर स्टेटस लागू किए जाते हैं, जैसा कि ACPI के मुताबिक बताया गया है, तो:

• [C-1-1] डिवाइस को इस स्थिति में सिर्फ़ तब डाला जाना चाहिए, जब उपयोगकर्ता ने डिवाइस को बंद करने के लिए कोई साफ़ तौर पर कार्रवाई की हो. उदाहरण के लिए, डिवाइस के किसी हिस्से को बंद करके या वाहन या टीवी को बंद करके. साथ ही, डिवाइस को इस स्थिति में तब तक रखना चाहिए, जब तक उपयोगकर्ता उसे फिर से चालू न कर दे. उदाहरण के लिए, डिवाइस के किसी हिस्से को खोलकर या वाहन या टीवी को फिर से चालू करके.

अगर डिवाइस में एस3 पावर स्टेटस को लागू किया जाता है, जैसा कि ACPI के मुताबिक बताया गया है, तो:

• [C-2-1] यह ज़रूरी है कि ऐप्लिकेशन, ऊपर बताई गई C-1-1 शर्त को पूरा करता हो. इसके अलावा, यह भी ज़रूरी है कि ऐप्लिकेशन S3 स्टेटस में सिर्फ़ तब स्विच करे, जब तीसरे पक्ष के ऐप्लिकेशन को सिस्टम के रिसॉर्स (जैसे, स्क्रीन, सीपीयू) की ज़रूरत न हो.

  इसके उलट, जब तीसरे पक्ष के ऐप्लिकेशन को सिस्टम संसाधनों की ज़रूरत होती है, तो उन्हें S3 स्टेटस से बाहर निकलना होगा. इस बारे में इस SDK टूल पर बताया गया है.

  उदाहरण के लिए, जब तीसरे पक्ष के ऐप्लिकेशन, FLAG_KEEP_SCREEN_ON के ज़रिए स्क्रीन को चालू रखने या PARTIAL_WAKE_LOCK के ज़रिए सीपीयू को चालू रखने का अनुरोध करते हैं, तब डिवाइस को S3 स्टेटस में तब तक नहीं जाना चाहिए, जब तक कि C-1-1 में बताए गए तरीके से, उपयोगकर्ता ने डिवाइस को इनऐक्टिव स्टेटस में डालने के लिए साफ़ तौर पर कार्रवाई न की हो. इसके उलट, जब तीसरे पक्ष के ऐप्लिकेशन, JobScheduler की मदद से कोई टास्क ट्रिगर करते हैं या तीसरे पक्ष के ऐप्लिकेशन को Firebase Cloud Messaging डिलीवर किया जाता है, तो डिवाइस को S3 स्टेटस से बाहर निकलना होगा. ऐसा तब तक करना होगा, जब तक उपयोगकर्ता ने डिवाइस को इनऐक्टिव स्टेटस में नहीं डाल दिया है. ये उदाहरण पूरी जानकारी नहीं देते. AOSP, डिवाइस को इस स्थिति से जगाने के लिए, कई तरह के वेक अप सिग्नल लागू करता है.

8.4. बिजली की खपत का हिसाब लगाना

ऐप्लिकेशन के डेवलपर को, बिजली की खपत के बारे में ज़्यादा सटीक जानकारी और रिपोर्ट मिलती है. इससे, ऐप्लिकेशन के बिजली के इस्तेमाल के पैटर्न को ऑप्टिमाइज़ करने के लिए, उन्हें इंसेंटिव और टूल, दोनों मिलते हैं.

डिवाइस पर लागू करने के तरीके:

• [C-SR-1] हमारा सुझाव है कि हर कॉम्पोनेंट के लिए पावर प्रोफ़ाइल दें. इससे हर हार्डवेयर कॉम्पोनेंट के लिए बिजली की खपत की वैल्यू और समय के साथ कॉम्पोनेंट की वजह से बैटरी की खपत के अनुमान की जानकारी मिलती है. इस बारे में Android Open Source Project की साइट पर जानकारी दी गई है.
• [C-SR-2] हमारा सुझाव है कि बिजली की खपत की सभी वैल्यू को मिलीऐंपीर घंटे (mAh) में रिपोर्ट करें.
• [C-SR-3] हमारा सुझाव है कि हर प्रोसेस के यूआईडी के हिसाब से, सीपीयू की खपत की रिपोर्ट दें. Android ओपन सोर्स प्रोजेक्ट, uid_cputime कर्नेल मॉड्यूल लागू करने की ज़रूरी शर्तें पूरी करता है.
• [C-SR-4] हमारा सुझाव है कि ऐप्लिकेशन डेवलपर को, बिजली की खपत की जानकारी को adb shell dumpsys batterystats शेल कमांड के ज़रिए उपलब्ध कराएं.
• अगर हार्डवेयर कॉम्पोनेंट के पावर इस्तेमाल को किसी ऐप्लिकेशन के लिए एट्रिब्यूट नहीं किया जा सकता, तो उसे हार्डवेयर कॉम्पोनेंट के लिए एट्रिब्यूट किया जाना चाहिए.

8.5. लगातार अच्छी परफ़ॉर्मेंस

लंबे समय तक चलने वाले और बेहतर परफ़ॉर्म करने वाले ऐप्लिकेशन की परफ़ॉर्मेंस में काफ़ी उतार-चढ़ाव हो सकता है. ऐसा, बैकग्राउंड में चल रहे दूसरे ऐप्लिकेशन की वजह से या तापमान की सीमाओं की वजह से सीपीयू की स्पीड कम होने की वजह से हो सकता है. Android में प्रोग्राम के हिसाब से इंटरफ़ेस शामिल होते हैं, ताकि डिवाइस के काम करने की क्षमता के हिसाब से, फ़ोरग्राउंड में चल रहे सबसे ज़्यादा इस्तेमाल किए जाने वाले ऐप्लिकेशन, सिस्टम से अनुरोध कर सकें कि वह संसाधनों के बंटवारे को ऑप्टिमाइज़ करे, ताकि इस तरह के उतार-चढ़ावों को ठीक किया जा सके.

डिवाइस पर लागू करने के तरीके:

• [C-0-1] PowerManager.isSustainedPerformanceModeSupported() API के तरीके से, बेहतर परफ़ॉर्मेंस मोड के साथ काम करने की जानकारी सटीक तरीके से देनी ज़रूरी है.

• यह बेहतर परफ़ॉर्मेंस वाले मोड के साथ काम करना चाहिए.

अगर डिवाइस पर, बेहतर परफ़ॉर्मेंस मोड की सुविधा काम करती है, तो:

• [C-1-1] जब कोई ऐप्लिकेशन अनुरोध करता है, तो फ़ोरग्राउंड में मौजूद मुख्य ऐप्लिकेशन को कम से कम 30 मिनट तक एक जैसी परफ़ॉर्मेंस देनी चाहिए.
• [C-1-2] Window.setSustainedPerformanceMode() एपीआई और उससे जुड़े अन्य एपीआई का पालन करना ज़रूरी है.

अगर डिवाइस में दो या उससे ज़्यादा सीपीयू कोर शामिल हैं, तो:

• कम से कम एक ऐसा खास कोर उपलब्ध कराना चाहिए जिसे टॉप फ़ोरग्राउंड ऐप्लिकेशन रिज़र्व कर सके.

अगर डिवाइस पर, सबसे ज़्यादा इस्तेमाल किए जा रहे फ़ोरग्राउंड ऐप्लिकेशन के लिए एक खास कोर को रिज़र्व करने की सुविधा काम करती है, तो:

• [C-2-1] Process.getExclusiveCores() एपीआई के तरीके से, खास कोर के आईडी नंबर की जानकारी देनी ज़रूरी है. इन कोर को टॉप फ़ोरग्राउंड ऐप्लिकेशन रिज़र्व कर सकता है.
• [C-2-2] ऐप्लिकेशन के इस्तेमाल किए गए डिवाइस ड्राइवर के अलावा, किसी भी उपयोगकर्ता स्पेस प्रोसेस को खास कोर पर चलने की अनुमति नहीं देनी चाहिए. हालांकि, ज़रूरत के हिसाब से कुछ कर्नेल प्रोसेस को चलने की अनुमति दी जा सकती है.

अगर डिवाइस पर लागू किए गए टूल, किसी खास कोर के साथ काम नहीं करते, तो वे:

• [C-3-1] Process.getExclusiveCores() एपीआई के तरीके से, खाली सूची दिखानी चाहिए.

9. सुरक्षा मॉडल के साथ काम करने की सुविधा

डिवाइस पर लागू करने के तरीके:

• [C-0-1] Android डेवलपर दस्तावेज़ में मौजूद एपीआई में, सुरक्षा और अनुमतियों के रेफ़रंस दस्तावेज़ में बताए गए तरीके के मुताबिक, Android प्लैटफ़ॉर्म के सुरक्षा मॉडल के मुताबिक सुरक्षा मॉडल लागू करना ज़रूरी है.

• [C-0-2] यह ज़रूरी है कि डिवाइस पर, खुद के हस्ताक्षर वाले ऐप्लिकेशन इंस्टॉल किए जा सकें. इसके लिए, किसी तीसरे पक्ष/अधिकारियों से अनुमति या सर्टिफ़िकेट लेने की ज़रूरत नहीं होनी चाहिए.

अगर डिवाइस में android.hardware.security.model.compatible सुविधा लागू की गई है, तो:

• [C-1-1] यह ज़रूरी है कि यह टूल, नीचे दिए गए सब-सेक्शन में बताई गई ज़रूरी शर्तों को पूरा करता हो.

9.1. अनुमतियां

डिवाइस पर लागू करने के तरीके:

• [C-0-1] यह ज़रूरी है कि यह Android की अनुमतियों के मॉडल और Android की भूमिकाओं के मॉडल के साथ काम करे. इन मॉडल के बारे में, Android डेवलपर के दस्तावेज़ में बताया गया है. खास तौर पर, उन्हें SDK दस्तावेज़ में बताई गई हर अनुमति और भूमिका को लागू करना होगा. किसी भी अनुमति और भूमिका को न तो छोड़ा जा सकता है, न ही उसमें बदलाव किया जा सकता है या उसे अनदेखा किया जा सकता है.

• ज़्यादा अनुमतियां जोड़ी जा सकती हैं. हालांकि, इसके लिए ज़रूरी है कि अनुमति के नए आईडी की स्ट्रिंग, android.\* नेमस्पेस में न हों.

• [C-0-2] PROTECTION_FLAG_PRIVILEGED के protectionLevel वाली अनुमतियां, सिर्फ़ उन ऐप्लिकेशन को दी जानी चाहिए जो सिस्टम इमेज के साथ-साथ APEX फ़ाइलों के खास पाथ में पहले से इंस्टॉल होते हैं. साथ ही, ये अनुमतियां हर ऐप्लिकेशन के लिए, साफ़ तौर पर अनुमति वाली सूची के सबसेट में होनी चाहिए. AOSP को लागू करने से यह ज़रूरी शर्त पूरी होती है. इसके लिए, etc/permissions/ पाथ में मौजूद फ़ाइलों से हर ऐप्लिकेशन के लिए, अनुमति वाली सूची को पढ़ा जाता है और उसे लागू किया जाता है. साथ ही, system/priv-app पाथ को खास पाथ के तौर पर इस्तेमाल किया जाता है.

सुरक्षा के लेवल के हिसाब से, खतरनाक अनुमतियां रनटाइम अनुमतियां होती हैं. जिन ऐप्लिकेशन में targetSdkVersion > 22 है वे रनटाइम के दौरान इनका अनुरोध करते हैं.

डिवाइस पर लागू करने के तरीके:

• [C-0-3] ऐप्लिकेशन को उपयोगकर्ता के लिए एक खास इंटरफ़ेस दिखाना चाहिए, ताकि वह यह तय कर सके कि अनुरोध की गई रनटाइम अनुमतियां देनी हैं या नहीं. साथ ही, उपयोगकर्ता को रनटाइम अनुमतियां मैनेज करने के लिए भी एक इंटरफ़ेस उपलब्ध कराना चाहिए.

• [C-0-4] दोनों यूज़र इंटरफ़ेस को एक ही बार लागू किया जाना चाहिए.

• [C-0-5] ऐप्लिकेशन को रनटाइम की कोई अनुमति तब तक नहीं देनी चाहिए, जब तक कि:

  • ये डिवाइस शिप होने के समय इंस्टॉल किए जाते हैं और

  • ऐप्लिकेशन को अनुमति का इस्तेमाल करने से पहले, उपयोगकर्ता की सहमति ली जा सकती है,

    या

  • रनटाइम की अनुमतियां, अनुमति देने की डिफ़ॉल्ट नीति के तहत या प्लैटफ़ॉर्म की भूमिका के लिए दी जाती हैं.

• [C-0-6] android.permission.RECOVER_KEYSTORE अनुमति सिर्फ़ उन सिस्टम ऐप्लिकेशन को दी जानी चाहिए जो ठीक से सुरक्षित किए गए रिकवरी एजेंट को रजिस्टर करते हैं. ठीक से सुरक्षित किए गए रिकवरी एजेंट को, डिवाइस पर मौजूद सॉफ़्टवेयर एजेंट के तौर पर परिभाषित किया जाता है. यह एजेंट, डिवाइस से बाहर के रिमोट स्टोरेज के साथ सिंक होता है. यह रिमोट स्टोरेज, सुरक्षित हार्डवेयर से लैस होता है. इस हार्डवेयर की सुरक्षा, Google Cloud Key Vault Service में बताई गई सुरक्षा के बराबर या उससे ज़्यादा होती है. इससे लॉकस्क्रीन पर मौजूद, उपयोगकर्ता के पास मौजूद जानकारी वाले फ़ैक्टर पर ब्रूट-फ़ोर्स अटैक को रोका जा सकता है.

डिवाइस पर लागू करने के तरीके:

• [C-0-7] जब कोई ऐप्लिकेशन, स्टैंडर्ड Android एपीआई या मालिकाना मशीनरी की मदद से जगह की जानकारी या शारीरिक गतिविधि के डेटा का अनुरोध करता है, तो उसे Android की जगह की जानकारी की अनुमति की प्रॉपर्टी का पालन करना ज़रूरी है. इस डेटा में ये चीज़ें शामिल हैं. हालांकि, इसमें और भी चीज़ें शामिल हो सकती हैं:

  • डिवाइस की जगह की जानकारी (उदाहरण के लिए, अक्षांश और देशांतर), जैसा कि सेक्शन 9.8.8 में बताया गया है.
  • ऐसी जानकारी जिसका इस्तेमाल डिवाइस की जगह का पता लगाने या उसका अनुमान लगाने के लिए किया जा सकता है. जैसे, SSID, BSSID, सेल आईडी या उस नेटवर्क की जगह जिससे डिवाइस कनेक्ट है.
  • उपयोगकर्ता की शारीरिक गतिविधि या शारीरिक गतिविधि की कैटगरी.

खास तौर पर, डिवाइस पर लागू करने के लिए:

• [C-0-8] किसी ऐप्लिकेशन को जगह की जानकारी या शारीरिक गतिविधि का डेटा ऐक्सेस करने की अनुमति देने के लिए, उपयोगकर्ता की सहमति लेना ज़रूरी है.
• [C-0-9] रनटाइम की अनुमति सिर्फ़ उस ऐप्लिकेशन को दी जानी चाहिए जिसके पास SDK टूल में बताई गई ज़रूरी अनुमतियां हों. उदाहरण के लिए, TelephonyManager#getServiceState के लिए android.permission.ACCESS_FINE_LOCATION की ज़रूरत होती है).

ऊपर बताई गई Android की जगह की जानकारी की अनुमति वाली प्रॉपर्टी के लिए, सिर्फ़ उन ऐप्लिकेशन को छूट दी जाती है जो उपयोगकर्ता की जगह की जानकारी का पता लगाने या उसकी पहचान करने के लिए, जगह की जानकारी को ऐक्सेस नहीं करते. खास तौर पर:

• जब ऐप्लिकेशन के पास RADIO_SCAN_WITHOUT_LOCATION अनुमति हो.
• डिवाइस के कॉन्फ़िगरेशन और सेटअप के लिए, जहां सिस्टम ऐप्लिकेशन के पास NETWORK_SETTINGS या NETWORK_SETUP_WIZARD अनुमति हो.

अनुमतियों के व्यवहार में बदलाव करके, उन्हें 'पाबंदी वाला' के तौर पर मार्क किया जा सकता है.

• [C-0-10] hardRestricted फ़्लैग के साथ मार्क की गई अनुमतियां, किसी ऐप्लिकेशन को तब तक नहीं दी जानी चाहिए, जब तक:

  • ऐप्लिकेशन की APK फ़ाइल, सिस्टम पार्टीशन में है.
  • उपयोगकर्ता, किसी ऐप्लिकेशन को hardRestricted अनुमतियों से जुड़ी भूमिका असाइन करता है.
  • इंस्टॉलर, किसी ऐप्लिकेशन को hardRestricted देता है.
  • किसी ऐप्लिकेशन को Android के पुराने वर्शन पर hardRestricted दिया गया हो.

• [C-0-11] softRestricted अनुमति वाले ऐप्लिकेशन को सिर्फ़ सीमित ऐक्सेस मिलना चाहिए. साथ ही, जब तक SDK टूल में बताई गई अनुमति सूची में शामिल नहीं किया जाता, तब तक उसे पूरा ऐक्सेस नहीं मिलना चाहिए. SDK टूल में, हर softRestricted अनुमति (उदाहरण के लिए, READ_EXTERNAL_STORAGE) के लिए पूरा और सीमित ऐक्सेस तय किया जाता है.

• [C-0-12] setPermissionPolicy और setPermissionGrantState एपीआई में बताई गई अनुमति से जुड़ी पाबंदियों को बायपास करने के लिए, कोई कस्टम फ़ंक्शन या एपीआई नहीं दिया जाना चाहिए.

• [C-0-13] Android गतिविधियों और सेवाओं से मिली खतरनाक अनुमतियों से सुरक्षित डेटा के हर प्रोग्राम के ऐक्सेस को रिकॉर्ड और ट्रैक करने के लिए, AppOpsManager API का इस्तेमाल करना ज़रूरी है.

• [C-0-14] सिर्फ़ उन ऐप्लिकेशन को भूमिकाएं असाइन करें जिनके फ़ंक्शन, भूमिका से जुड़ी ज़रूरी शर्तों को पूरा करते हों.

• [C-0-15] ऐसी भूमिकाएं तय नहीं करनी चाहिए जो डुप्लीकेट हों या प्लैटफ़ॉर्म की बताई गई भूमिकाओं के सुपरसेट फ़ंक्शन हों.

अगर डिवाइसों की रिपोर्ट में android.software.managed_users दिखता है, तो:

• [C-1-1] ऐप्लिकेशन को एडमिन की ओर से चुपचाप ये अनुमतियां नहीं मिलनी चाहिए:
  • जगह की जानकारी (ACCESS_BACKGROUND_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION).
  • कैमरा (CAMERA)
  • माइक्रोफ़ोन (RECORD_AUDIO)
  • बॉडी सेंसर (BODY_SENSORS)
  • शारीरिक गतिविधि (ACTIVITY_RECOGNITION)

अगर डिवाइस पर, उपयोगकर्ता को यह चुनने की सुविधा मिलती है कि कौनसे ऐप्लिकेशन, ACTION_MANAGE_OVERLAY_PERMISSION इंटेंट को मैनेज करने वाली गतिविधि के साथ, दूसरे ऐप्लिकेशन के ऊपर दिख सकते हैं, तो:

• [C-2-1] यह पक्का करना ज़रूरी है कि ACTION_MANAGE_OVERLAY_PERMISSION इंटेंट के लिए इंटेंट फ़िल्टर वाली सभी गतिविधियों में एक ही यूज़र इंटरफ़ेस (यूआई) स्क्रीन हो. भले ही, गतिविधि शुरू करने वाला ऐप्लिकेशन या उससे मिलने वाली जानकारी कुछ भी हो.

अगर डिवाइस पर लागू किए गए ऐप्लिकेशन में android.software.device_admin की जानकारी दी गई है, तो:

• [C-3-1] पूरी तरह से मैनेज किए जाने वाले डिवाइस के सेटअप (डिवाइस के मालिक का सेटअप) के दौरान, डिसक्लेमर दिखाना ज़रूरी है. इसमें यह जानकारी होनी चाहिए कि आईटी एडमिन के पास ऐप्लिकेशन को फ़ोन की सेटिंग कंट्रोल करने की अनुमति देने का विकल्प होगा. इन सेटिंग में माइक्रोफ़ोन, कैमरा, और जगह की जानकारी शामिल है. साथ ही, उपयोगकर्ता के पास सेटअप जारी रखने या सेटअप से बाहर निकलने का विकल्प होगा. हालांकि, ऐसा तब तक होगा, जब तक एडमिन ने डिवाइस पर अनुमतियों को कंट्रोल करने की सुविधा से ऑप्ट आउट न कर दिया हो.

अगर डिवाइस में पहले से ऐसे पैकेज इंस्टॉल हैं जिनमें System UI Intelligence, System Ambient Audio Intelligence, System Audio Intelligence, System Notification Intelligence, System Text Intelligence या System Visual Intelligence में से कोई भी भूमिका है, तो ये पैकेज:

• [C-4-1] डिवाइस पर लागू करने के लिए, इन सेक्शन में बताई गई सभी ज़रूरी शर्तों को पूरा करना ज़रूरी है: "9.8.6 कॉन्टेंट कैप्चर" "9.8.6 ऑपरेटिंग सिस्टम-लेवल और ऐंबियंट डेटा और 9.8.15 सैंडबॉक्स किए गए एपीआई लागू करना".

• [C-4-2] ऐप्लिकेशन में android.permission.INTERNET की अनुमति नहीं होनी चाहिए. यह शर्त, सेक्शन 9.8.6 में बताई गई 'इसका सुझाव दिया जाता है' शर्त से ज़्यादा सख्त है.
• [C-4-3] इसे इन सिस्टम ऐप्लिकेशन के अलावा, किसी अन्य ऐप्लिकेशन से बाइंड नहीं किया जाना चाहिए: ब्लूटूथ, संपर्क, मीडिया, टेलीफ़ोन, SystemUI, और इंटरनेट एपीआई उपलब्ध कराने वाले कॉम्पोनेंट. यह शर्त, सेक्शन 9.8.6 में बताई गई 'ज़रूरी' शर्त से ज़्यादा सख्त है.

नई ज़रूरी शर्तें लागू करना

अगर डिवाइस में VoiceInteractionService के साथ काम करने के लिए कोई डिफ़ॉल्ट ऐप्लिकेशन शामिल है, तो:

• [C-5-1] उस ऐप्लिकेशन के लिए, ACCESS_FINE_LOCATION को डिफ़ॉल्ट के तौर पर अनुमति नहीं दी जानी चाहिए.

नई ज़रूरी शर्तें खत्म करना

9.2. यूआईडी और प्रोसेस अलग करना

डिवाइस पर लागू करने के तरीके:

• [C-0-1] यह Android ऐप्लिकेशन के सैंडबॉक्स मॉडल के साथ काम करना चाहिए. इसमें हर ऐप्लिकेशन, यूनिकस स्टाइल के यूआईडी के तौर पर और एक अलग प्रोसेस में काम करता है.
• [C-0-2] एक ही Linux यूज़र आईडी के तौर पर कई ऐप्लिकेशन चलाने की सुविधा होनी चाहिए. हालांकि, इसके लिए ज़रूरी है कि ऐप्लिकेशन को सही तरीके से साइन किया गया हो और उन्हें सुरक्षा और अनुमतियों के रेफ़रंस में बताए गए तरीके से बनाया गया हो.

9.3. फ़ाइल सिस्टम की अनुमतियां

डिवाइस पर लागू करने के तरीके:

• [C-0-1] ऐप्लिकेशन को Android फ़ाइल ऐक्सेस करने की अनुमतियों के उस मॉडल के साथ काम करना चाहिए जिसकी जानकारी सुरक्षा और अनुमतियों के रेफ़रंस में दी गई है.

9.4. एक्ज़ीक्यूशन के अन्य एनवायरमेंट

डिवाइस में लागू किए गए सिस्टम में, Android की सुरक्षा और अनुमति के मॉडल को एक जैसा रखना ज़रूरी है. भले ही, उनमें ऐसे रनटाइम एनवायरमेंट शामिल हों जो Dalvik Executable Format या नेटिव कोड के अलावा किसी अन्य सॉफ़्टवेयर या टेक्नोलॉजी का इस्तेमाल करके ऐप्लिकेशन चलाते हों. दूसरे शब्दों में:

• [C-0-1] वैकल्पिक रनटाइम, Android ऐप्लिकेशन होने चाहिए. साथ ही, वे सेक्शन 9 में बताए गए स्टैंडर्ड Android सुरक्षा मॉडल का पालन करते होने चाहिए.

• [C-0-2] अन्य रनटाइम को उन संसाधनों का ऐक्सेस नहीं दिया जाना चाहिए जिन्हें <uses-permission> प्रोसेस के ज़रिए, रनटाइम की AndroidManifest.xml फ़ाइल में अनुरोध नहीं किया गया है.

• [C-0-3] अन्य रनटाइम को ऐप्लिकेशन को उन सुविधाओं का इस्तेमाल करने की अनुमति नहीं देनी चाहिए जिन्हें Android की अनुमतियों से सुरक्षित किया गया है और जिनका इस्तेमाल सिर्फ़ सिस्टम ऐप्लिकेशन कर सकते हैं.

• [C-0-4] अन्य रनटाइम को Android सैंडबॉक्स मॉडल का पालन करना चाहिए. साथ ही, अन्य रनटाइम का इस्तेमाल करने वाले इंस्टॉल किए गए ऐप्लिकेशन को डिवाइस पर इंस्टॉल किए गए किसी भी अन्य ऐप्लिकेशन के सैंडबॉक्स का फिर से इस्तेमाल नहीं करना चाहिए. हालांकि, शेयर किए गए उपयोगकर्ता आईडी और साइनिंग सर्टिफ़िकेट के स्टैंडर्ड Android तरीकों का इस्तेमाल करके ऐसा किया जा सकता है.

• [C-0-5] अन्य रनटाइम, दूसरे Android ऐप्लिकेशन के सैंडबॉक्स के साथ लॉन्च नहीं होने चाहिए, उन्हें सैंडबॉक्स का ऐक्सेस नहीं देना चाहिए, और न ही उन्हें सैंडबॉक्स का ऐक्सेस दिया जाना चाहिए.

• [C-0-6] अन्य रनटाइम को सुपरयूज़र (रूट) या किसी अन्य उपयोगकर्ता आईडी की अनुमतियों के साथ लॉन्च नहीं किया जाना चाहिए. साथ ही, उन्हें अन्य ऐप्लिकेशन को ये अनुमतियां नहीं देनी चाहिए.

• [C-0-7] जब डिवाइस पर लागू किए गए सिस्टम की इमेज में, वैकल्पिक रनटाइम की .apk फ़ाइलें शामिल की जाती हैं, तो उस पर ऐसी कुंजी से हस्ताक्षर करना ज़रूरी है जो डिवाइस पर लागू किए गए अन्य ऐप्लिकेशन पर हस्ताक्षर करने के लिए इस्तेमाल की गई कुंजी से अलग हो.

• [C-0-8] ऐप्लिकेशन इंस्टॉल करते समय, अन्य रनटाइम को ऐप्लिकेशन के लिए इस्तेमाल की जाने वाली Android अनुमतियों के लिए, उपयोगकर्ता की सहमति लेनी होगी.

• [C-0-9] जब किसी ऐप्लिकेशन को किसी ऐसे डिवाइस संसाधन का इस्तेमाल करना हो जिसके लिए Android की अनुमति (जैसे, कैमरा, जीपीएस वगैरह) हो, तो वैकल्पिक रनटाइम को उपयोगकर्ता को यह बताना होगा कि ऐप्लिकेशन उस संसाधन को ऐक्सेस कर पाएगा.

• [C-0-10] जब रनटाइम एनवायरमेंट, ऐप्लिकेशन की सुविधाओं को इस तरीके से रिकॉर्ड नहीं करता है, तो रनटाइम एनवायरमेंट को उस रनटाइम का इस्तेमाल करके किसी भी ऐप्लिकेशन को इंस्टॉल करते समय, रनटाइम के पास मौजूद सभी अनुमतियों की सूची देनी होगी.

• अन्य रनटाइम को PackageManager के ज़रिए, अलग-अलग Android सैंडबॉक्स (Linux यूज़र आईडी वगैरह) में ऐप्लिकेशन इंस्टॉल करने चाहिए.

• वैकल्पिक रनटाइम, एक ऐसा Android सैंडबॉक्स उपलब्ध करा सकते हैं जिसका इस्तेमाल, वैकल्पिक रनटाइम का इस्तेमाल करने वाले सभी ऐप्लिकेशन करते हैं.

9.5. एक डिवाइस पर कई लोगों के काम करने की सुविधा

Android में एक से ज़्यादा उपयोगकर्ताओं के लिए सहायता शामिल है.साथ ही, यह उपयोगकर्ता को पूरी तरह से अलग करने और कुछ हद तक अलग करने के साथ-साथ उपयोगकर्ता प्रोफ़ाइलों को क्लोन करने की सुविधा भी देता है. उदाहरण के लिए, android.os.usertype.profile.CLONE टाइप की एक अतिरिक्त उपयोगकर्ता प्रोफ़ाइल.

• डिवाइस में कई उपयोगकर्ताओं के लिए फ़ाइल शेयर करने की सुविधा चालू की जा सकती है. हालांकि, अगर डिवाइस में प्राइमरी बाहरी स्टोरेज के तौर पर रिमूवेबल मीडिया का इस्तेमाल किया जाता है, तो ऐसा नहीं किया जाना चाहिए.

अगर डिवाइस पर एक से ज़्यादा उपयोगकर्ताओं के लिए सहायता शामिल है, तो:

• [C-1-2] हर उपयोगकर्ता के लिए, एपीआई में सुरक्षा और अनुमतियों के रेफ़रंस दस्तावेज़ में बताए गए Android प्लैटफ़ॉर्म के सुरक्षा मॉडल के मुताबिक, सुरक्षा मॉडल लागू करना ज़रूरी है.
• [C-1-3] हर उपयोगकर्ता इंस्टेंस के लिए, अलग और अलग-अलग शेयर किए गए ऐप्लिकेशन स्टोरेज (/sdcard) डायरेक्ट्री होनी चाहिए.
• [C-1-4] यह पक्का करना ज़रूरी है कि किसी उपयोगकर्ता के मालिकाना हक वाली और उसकी ओर से चलने वाली फ़ाइलें, किसी दूसरे उपयोगकर्ता की फ़ाइलों को न देख सकें, न पढ़ सकें, और न ही उनमें बदलाव कर सकें. भले ही, दोनों उपयोगकर्ताओं का डेटा एक ही वॉल्यूम या फ़ाइल सिस्टम में सेव हो.
• [C-1-5] अगर डिवाइस में एक से ज़्यादा उपयोगकर्ताओं के लिए सुविधा चालू है, तो एसडी कार्ड के कॉन्टेंट को एन्क्रिप्ट करना ज़रूरी है. इसके लिए, ऐसी कुंजी का इस्तेमाल करना चाहिए जो सिर्फ़ डिवाइस में मौजूद ऐसे मीडिया पर सेव हो जिसे हटाया नहीं जा सकता. साथ ही, यह कुंजी सिर्फ़ सिस्टम ऐक्सेस कर सकता है. ऐसा तब करना होगा, जब डिवाइस में बाहरी स्टोरेज के एपीआई के लिए, हटाया जा सकने वाला मीडिया इस्तेमाल किया जाता हो. इससे होस्ट पीसी, मीडिया को पढ़ नहीं पाएगा. इसलिए, डिवाइस को MTP या मिलते-जुलते सिस्टम पर स्विच करना होगा, ताकि होस्ट पीसी को मौजूदा उपयोगकर्ता के डेटा का ऐक्सेस मिल सके.

अगर डिवाइस पर एक से ज़्यादा उपयोगकर्ताओं के लिए सुविधा उपलब्ध है, तो एक ही ऐप्लिकेशन के दो इंस्टेंस चलाने के लिए खास तौर पर बनाए गए उपयोगकर्ताओं को छोड़कर, सभी उपयोगकर्ताओं के लिए ये काम किए जाते हैं:

• [C-2-1] हर उपयोगकर्ता इंस्टेंस के लिए, ऐप्लिकेशन के शेयर किए गए स्टोरेज (जिसे /sdcard भी कहा जाता है) की अलग और अलग-अलग डायरेक्ट्री होनी चाहिए.
• [C-2-2] यह पक्का करना ज़रूरी है कि किसी उपयोगकर्ता के मालिकाना हक वाली और उसकी ओर से चलने वाली ऐप्लिकेशन, किसी दूसरे उपयोगकर्ता के मालिकाना हक वाली फ़ाइलों को न तो देख सकें, न ही उनमें बदलाव कर सकें और न ही उन्हें पढ़ सकें. भले ही, दोनों उपयोगकर्ताओं का डेटा एक ही वॉल्यूम या फ़ाइल सिस्टम में सेव हो.

डिवाइस पर लागू होने पर, एक ही ऐप्लिकेशन के दो इंस्टेंस चलाने के लिए, मुख्य उपयोगकर्ता के लिए android.os.usertype.profile.CLONE टाइप की एक अतिरिक्त उपयोगकर्ता प्रोफ़ाइल बनाई जा सकती है. यह प्रोफ़ाइल सिर्फ़ मुख्य उपयोगकर्ता के लिए बनाई जाती है. ये दो इंस्टेंस, कुछ हद तक अलग-अलग स्टोरेज शेयर करते हैं. साथ ही, ये लॉन्चर में एक ही समय पर असली उपयोगकर्ता को दिखाए जाते हैं और हाल ही में इस्तेमाल किए गए ऐप्लिकेशन के एक ही व्यू में दिखते हैं. उदाहरण के लिए, इसका इस्तेमाल करके उपयोगकर्ता को ड्यूअल-सिम डिवाइस पर, किसी एक ऐप्लिकेशन के दो अलग-अलग इंस्टेंस इंस्टॉल करने में मदद की जा सकती है.

अगर डिवाइस पर लागू करने से, ऊपर बताई गई अतिरिक्त उपयोगकर्ता प्रोफ़ाइल बनती है, तो:

• [C-3-1] ऐप्लिकेशन को सिर्फ़ उस स्टोरेज या डेटा का ऐक्सेस देना चाहिए जो पहले से ही पैरंट उपयोगकर्ता प्रोफ़ाइल के पास हो या जिसका मालिकाना हक सीधे तौर पर इस अतिरिक्त उपयोगकर्ता प्रोफ़ाइल के पास हो.
• [C-3-2] यह ज़रूरी है कि यह वर्क प्रोफ़ाइल के तौर पर न हो.
• [C-3-3] ऐप्लिकेशन के निजी डेटा की डायरेक्ट्री, माता-पिता के उपयोगकर्ता खाते से अलग होनी चाहिए.
• [C-3-4] अगर डिवाइस के लिए कोई मालिक तय किया गया है (सेक्शन 3.9.1 देखें), तो अतिरिक्त उपयोगकर्ता प्रोफ़ाइल बनाने की अनुमति नहीं दी जानी चाहिए. इसके अलावा, अतिरिक्त उपयोगकर्ता प्रोफ़ाइल को हटाए बिना, डिवाइस के मालिक को तय करने की अनुमति भी नहीं दी जानी चाहिए.

नई ज़रूरी शर्तें लागू करना

अगर डिवाइस पर लागू करने से, ऊपर बताई गई अतिरिक्त उपयोगकर्ता प्रोफ़ाइल बनती है, तो:

• [C-4-5] उपयोगकर्ताओं को आइकॉन दिखाते समय, ड्यूअल इंस्टेंस वाले ऐप्लिकेशन के आइकॉन को अलग-अलग दिखाना ज़रूरी है.
• [C-4-6] क्लोन की गई प्रोफ़ाइल का पूरा डेटा मिटाने के लिए, उपयोगकर्ता को कोई विकल्प देना ज़रूरी है.
• [C-4-7] जब उपयोगकर्ता, क्लोन प्रोफ़ाइल का पूरा डेटा मिटाने का विकल्प चुनता है, तो सभी क्लोन ऐप्लिकेशन को अनइंस्टॉल करना, निजी ऐप्लिकेशन के डेटा डायरेक्ट्री और उनका कॉन्टेंट मिटाना, और क्लोन प्रोफ़ाइल का डेटा मिटाना ज़रूरी है.
• आखिरी क्लोन ऐप्लिकेशन मिटाए जाने पर, उपयोगकर्ता को क्लोन प्रोफ़ाइल का पूरा डेटा मिटाने के लिए कहा जाना चाहिए.
• [C-4-8] उपयोगकर्ता को यह जानकारी देनी होगी कि क्लोन ऐप्लिकेशन को अनइंस्टॉल करने पर, ऐप्लिकेशन का डेटा मिट जाएगा. इसके अलावा, उपयोगकर्ताओं को यह विकल्प भी देना होगा कि डिवाइस से ऐप्लिकेशन को अनइंस्टॉल करने के बाद भी, ऐप्लिकेशन का डेटा सेव रहे.
• [C-4-9] जब उपयोगकर्ता अनइंस्टॉल के दौरान डेटा मिटाने का विकल्प चुनता है, तो निजी ऐप्लिकेशन के डेटा डायरेक्ट्री और उनके कॉन्टेंट को मिटाना ज़रूरी है.

• [C-4-1] डिवाइस पर प्राइमरी उपयोगकर्ता के ऐप्लिकेशन, अतिरिक्त प्रोफ़ाइल से आने वाले इन इंटेंट को मैनेज कर सकें:

  • Intent.ACTION_VIEW
  • Intent.ACTION_SENDTO
  • Intent.ACTION_SEND
  • Intent.ACTION_EDIT
  • Intent.ACTION_INSERT
  • Intent.ACTION_INSERT_OR_EDIT
  • Intent.ACTION_SEND_MULTIPLE
  • Intent.ACTION_PICK
  • Intent.ACTION_GET_CONTENT
  • MediaStore.ACTION_IMAGE_CAPTURE
  • MediaStore.ACTION_VIDEO_CAPTURE

• [C-4-2] इस अतिरिक्त उपयोगकर्ता प्रोफ़ाइल पर, डिवाइस की नीति के तहत उपयोगकर्ता के लिए तय की गई सभी पाबंदियां और डिवाइस के मुख्य उपयोगकर्ता पर लागू की गई कुछ ऐसी पाबंदियां(नीचे दी गई सूची) लागू होनी चाहिए जो उपयोगकर्ता के लिए नहीं हैं.

  • setScreenCaptureDisabled
  • setAccountManagementDisabled
  • setCameraDisabled
  • setPermittedInputMethods
  • setApplicationHidden
  • setPersonalAppsSuspended

• [C-4-3] इस अतिरिक्त प्रोफ़ाइल से संपर्कों को सिर्फ़ इन इंटेंट के ज़रिए लिखने की अनुमति होनी चाहिए:

  • ContactsContract.Intents.Insert.ACTION
  • Intent.ACTION_PICK
  • Intent.ACTION_EDIT
  • Intent.ACTION_INSERT_OR_EDIT

• [C-4-4] इस अतिरिक्त उपयोगकर्ता प्रोफ़ाइल में चल रहे ऐप्लिकेशन के लिए, संपर्क सिंक नहीं चलने चाहिए.

• [C-4-14] इस अतिरिक्त प्रोफ़ाइल में चल रहे ऐप्लिकेशन के लिए, अलग से अनुमति और स्टोरेज मैनेजमेंट होना चाहिए

• [C-4-5] अतिरिक्त प्रोफ़ाइल में मौजूद सिर्फ़ उन ऐप्लिकेशन को अनुमति दी जानी चाहिए जिनमें लॉन्चर गतिविधि होती है. इन ऐप्लिकेशन को उन संपर्कों को ऐक्सेस करने की अनुमति होनी चाहिए जो पहले से ही मुख्य उपयोगकर्ता प्रोफ़ाइल में ऐक्सेस किए जा सकते हैं.

नई ज़रूरी शर्तें खत्म करना

9.6. प्रीमियम एसएमएस की चेतावनी

Android में, उपयोगकर्ताओं को किसी भी तरह के प्रीमियम मैसेज भेजने से पहले चेतावनी देने की सुविधा शामिल है. प्रीमियम मैसेज, ऐसे टेक्स्ट मैसेज होते हैं जिन्हें मोबाइल और इंटरनेट सेवा देने वाली कंपनी के साथ रजिस्टर की गई किसी सेवा पर भेजा जाता है. इन मैसेज के लिए, उपयोगकर्ता से शुल्क लिया जा सकता है.

अगर डिवाइस पर android.hardware.telephony की सुविधा काम करती है, तो:

• [C-1-1] डिवाइस में मौजूद /data/misc/sms/codes.xml फ़ाइल में बताई गई रेगुलर एक्सप्रेशन से पहचाने गए नंबरों पर एसएमएस मैसेज भेजने से पहले, उपयोगकर्ताओं को चेतावनी देनी ज़रूरी है. अपस्ट्रीम Android Open Source Project, इस ज़रूरी शर्त को पूरा करने वाला एक तरीका उपलब्ध कराता है.

9.7. सुरक्षा से जुड़ी सुविधाएं

डिवाइस में लागू करने के लिए, यह ज़रूरी है कि वह नीचे बताए गए तरीके से, कर्नेल और प्लैटफ़ॉर्म, दोनों में सुरक्षा सुविधाओं का पालन करता हो.

Android सैंडबॉक्स में ऐसी सुविधाएं शामिल हैं जो Security-Enhanced Linux (SELinux) के ज़रूरी ऐक्सेस कंट्रोल (MAC) सिस्टम, seccomp सैंडबॉक्सिंग, और Linux कर्नेल की अन्य सुरक्षा सुविधाओं का इस्तेमाल करती हैं. डिवाइस पर लागू करने के तरीके:

• [C-0-1] यह ज़रूरी है कि मौजूदा ऐप्लिकेशन के साथ काम करने की सुविधा बनी रहे. भले ही, Android फ़्रेमवर्क के नीचे SELinux या सुरक्षा से जुड़ी कोई अन्य सुविधा लागू की गई हो.
• [C-0-2] जब सुरक्षा से जुड़ा कोई उल्लंघन पता चलता है और Android फ़्रेमवर्क के नीचे लागू की गई सुरक्षा सुविधा से उसे ब्लॉक कर दिया जाता है, तो यूज़र इंटरफ़ेस नहीं दिखना चाहिए. हालांकि, जब सुरक्षा से जुड़ा कोई उल्लंघन ब्लॉक नहीं किया जाता है और उसका फ़ायदा उठाया जाता है, तो यूज़र इंटरफ़ेस दिख सकता है.
• [C-0-3] उपयोगकर्ता या ऐप्लिकेशन डेवलपर के लिए, Android फ़्रेमवर्क के नीचे लागू की गई SELinux या अन्य सुरक्षा सुविधाओं को कॉन्फ़िगर करने की अनुमति नहीं दी जानी चाहिए.
• [C-0-4] किसी ऐसे ऐप्लिकेशन को नीति कॉन्फ़िगर करने की अनुमति नहीं देनी चाहिए जो किसी एपीआई (जैसे, डिवाइस एडमिनिस्ट्रेशन एपीआई) के ज़रिए किसी दूसरे ऐप्लिकेशन पर असर डाल सकता है. ऐसा करने से, ऐप्लिकेशन के साथ काम करने की सुविधा बंद हो सकती है.
• [C-0-5] मीडिया फ़्रेमवर्क को कई प्रोसेस में बांटना ज़रूरी है, ताकि Android Open Source Project की साइट पर बताए गए तरीके से, हर प्रोसेस के लिए ऐक्सेस को ज़्यादा सटीक तरीके से दिया जा सके.
• [C-0-6] ऐप्लिकेशन के लिए, कर्नेल सैंडबॉक्सिंग का ऐसा तरीका लागू करना ज़रूरी है जिससे मल्टी-थ्रेड वाले प्रोग्राम से, कॉन्फ़िगर की जा सकने वाली नीति का इस्तेमाल करके सिस्टम कॉल को फ़िल्टर किया जा सके. अपस्ट्रीम Android Open Source Project, source.android.com के कर्नेल कॉन्फ़िगरेशन सेक्शन में बताए गए तरीके के मुताबिक, थ्रेड ग्रुप सिंक्रोनाइज़ेशन (TSYNC) के साथ seccomp-BPF को चालू करके, इस ज़रूरी शर्त को पूरा करता है.

Android की सुरक्षा के लिए, कर्नेल इंटिग्रिटी और अपने-आप सुरक्षा करने की सुविधाएं ज़रूरी हैं. डिवाइस पर लागू करने के तरीके:

• [C-0-7] कर्नल स्टैक बफ़र ओवरफ़्लो से सुरक्षा देने वाले तरीकों को लागू करना ज़रूरी है. इस तरह के तरीकों के उदाहरण CC_STACKPROTECTOR_REGULAR और CONFIG_CC_STACKPROTECTOR_STRONG हैं.
• [C-0-8] जहां सिर्फ़ पढ़ने के लिए उपलब्ध कोड को चलाया जा सकता है, सिर्फ़ पढ़ने के लिए उपलब्ध डेटा को न तो चलाया जा सकता है और न ही उसमें बदलाव किया जा सकता है, और लिखने के लिए उपलब्ध डेटा को न तो चलाया जा सकता है और न ही उसमें बदलाव किया जा सकता है, वहां कर्नेल मेमोरी की सुरक्षा के सख्त उपाय लागू करने ज़रूरी हैं. उदाहरण के लिए, CONFIG_DEBUG_RODATA या CONFIG_STRICT_KERNEL_RWX.
• [C-0-9] एपीआई लेवल 28 या इसके बाद के वर्शन के साथ शिप होने वाले डिवाइसों पर, उपयोगकर्ता-स्पेस और कर्नेल-स्पेस (उदाहरण के लिए, CONFIG_HARDENED_USERCOPY) के बीच कॉपी के स्टैटिक और डाइनैमिक ऑब्जेक्ट साइज़ के बाउंड की जांच करना ज़रूरी है.
• [C-0-10] एपीआई लेवल 28 या उसके बाद के वर्शन वाले डिवाइसों पर, कर्नेल मोड (जैसे, हार्डवेयर PXN या CONFIG_CPU_SW_DOMAIN_PAN या CONFIG_ARM64_SW_TTBR0_PAN के ज़रिए एमुलेट किया गया) में प्रोग्राम चलाते समय, उपयोगकर्ता-स्पेस मेमोरी को इस्तेमाल नहीं किया जाना चाहिए.
• [C-0-11] एपीआई लेवल 28 या इसके बाद के वर्शन वाले डिवाइसों पर, उपयोगकर्ता के पास मौजूद सामान्य ऐक्सेस एपीआई (जैसे, हार्डवेयर पैन या CONFIG_CPU_SW_DOMAIN_PAN या CONFIG_ARM64_SW_TTBR0_PAN के ज़रिए एमुलेट किया गया) के अलावा, कर्नेल में उपयोगकर्ता-स्पेस मेमोरी को न तो पढ़ना चाहिए और न ही उसमें बदलाव करना चाहिए.
• [C-0-12] अगर एपीआई लेवल 28 या उसके बाद के वर्शन (जैसे, CONFIG_PAGE_TABLE_ISOLATION या CONFIG_UNMAP_KERNEL_AT_EL0) वाले सभी डिवाइसों पर, हार्डवेयर CVE-2017-5754 के शिकार होने की आशंका है, तो आपको कर्नेल पेज टेबल को अलग करने की सुविधा लागू करनी होगी.

• [C-0-13] अगर एपीआई लेवल 28 या उसके बाद के वर्शन (उदाहरण के लिए, CONFIG_HARDEN_BRANCH_PREDICTOR) के साथ शिप होने वाले सभी डिवाइसों पर, हार्डवेयर CVE-2017-5715 के लिए संवेदनशील है, तो ब्रैंच प्रिडिक्शन को बेहतर बनाने की सुविधा लागू करना ज़रूरी है.

• [C-SR-1] हमारा सुझाव है कि सिर्फ़ शुरू करने के दौरान लिखे गए कोर डेटा को शुरू करने के बाद, रीड-ओनली के तौर पर मार्क करें. जैसे, __ro_after_init.

• [C-SR-2] हमारा सुझाव है कि आप कर्नेल कोड और मेमोरी के लेआउट को रैंडमाइज़ करें.साथ ही, ऐसे एक्सपोज़र से बचें जिनसे रैंडमाइज़ेशन की सुविधा को नुकसान पहुंच सकता है. उदाहरण के लिए, /chosen/kaslr-seed Device Tree node या EFI_RNG_PROTOCOL के ज़रिए बूटलोडर एन्ट्रोपी के साथ CONFIG_RANDOMIZE_BASE.

• [C-SR-3] हमारा सुझाव है कि कोड के फिर से इस्तेमाल से जुड़े हमलों (जैसे, CONFIG_CFI_CLANG और CONFIG_SHADOW_CALL_STACK) से अतिरिक्त सुरक्षा पाने के लिए, कोर में कंट्रोल फ़्लो इंटिग्रिटी (CFI) को चालू करें.

• [C-SR-4] हमारा सुझाव है कि जिन कॉम्पोनेंट में कंट्रोल-फ़्लो इंटिग्रिटी (CFI), स्‍हेड कॉल स्टैक (SCS) या पूर्णांक ओवरफ़्लो सैनिटाइज़ेशन (IntSan) की सुविधा चालू है उन्हें बंद न करें.

• [C-SR-5] हमारा सुझाव है कि सुरक्षा से जुड़े किसी भी अतिरिक्त यूज़रस्पेस कॉम्पोनेंट के लिए, CFI, SCS, और IntSan को चालू करें. इस बारे में CFI और IntSan में बताया गया है.

• [C-SR-6] हमारा सुझाव है कि बिना शुरू किए गए लोकल वैरिएबल (CONFIG_INIT_STACK_ALL या CONFIG_INIT_STACK_ALL_ZERO) के इस्तेमाल को रोकने के लिए, कर्नेल में स्टैक शुरू करने की सुविधा चालू करें. साथ ही, डिवाइस के लागू होने पर, कंपाइलर के इस्तेमाल की गई वैल्यू को लोकल वैरिएबल के तौर पर शुरू नहीं किया जाना चाहिए.

• [C-SR-7] हमारा सुझाव है कि बिना शुरू किए गए हेप ऐलोकेशन (CONFIG_INIT_ON_ALLOC_DEFAULT_ON) के इस्तेमाल को रोकने के लिए, कोर में हेप को शुरू करने की सुविधा चालू करें. साथ ही, उन ऐलोकेशन को शुरू करने के लिए, कोर की इस्तेमाल की गई वैल्यू का इस्तेमाल नहीं करना चाहिए.

अगर डिवाइस में ऐसे Linux kernel का इस्तेमाल किया जाता है जो SELinux के साथ काम करता है, तो:

• [C-1-1] SELinux को लागू करना ज़रूरी है.
• [C-1-2] SELinux को ग्लोबल लागू करने वाले मोड पर सेट करना ज़रूरी है.
• [C-1-3] सभी डोमेन को लागू करने के मोड में कॉन्फ़िगर करना ज़रूरी है. अनुमति वाले मोड में, किसी भी डोमेन को अनुमति नहीं दी जा सकती. इसमें किसी डिवाइस/वेंडर के लिए खास तौर पर बनाए गए डोमेन भी शामिल हैं.
• [C-1-4] अपस्ट्रीम Android Open Source Project (AOSP) में दिए गए system/sepolicy फ़ोल्डर में मौजूद, कभी भी अनुमति न देने वाले नियमों में बदलाव नहीं किया जाना चाहिए, उन्हें हटाया नहीं जाना चाहिए या उन्हें बदला नहीं जाना चाहिए. साथ ही, नीति को AOSP SELinux डोमेन के साथ-साथ डिवाइस/वेंडर के हिसाब से बनाए गए डोमेन, दोनों के लिए मौजूद कभी भी अनुमति न देने वाले सभी नियमों के साथ कंपाइल किया जाना चाहिए.
• [C-1-5] तीसरे पक्ष के ऐसे ऐप्लिकेशन चलाने चाहिए जो हर ऐप्लिकेशन के लिए SELinux सैंडबॉक्स में, एपीआई लेवल 28 या उससे ज़्यादा को टारगेट करते हों. साथ ही, हर ऐप्लिकेशन की निजी डेटा डायरेक्ट्री पर, हर ऐप्लिकेशन के लिए SELinux की पाबंदियां भी होनी चाहिए.
• अपस्ट्रीम Android Open Source Project के system/sepolicy फ़ोल्डर में दी गई डिफ़ॉल्ट SELinux नीति को बनाए रखना चाहिए. साथ ही, अपने डिवाइस के हिसाब से कॉन्फ़िगरेशन के लिए, सिर्फ़ इस नीति में बदलाव करना चाहिए.

अगर डिवाइस पर, Linux के अलावा किसी दूसरे कर्नेल या SELinux के बिना Linux का इस्तेमाल किया जाता है, तो:

• [C-2-1] ज़रूरी ऐक्सेस कंट्रोल सिस्टम का इस्तेमाल करना ज़रूरी है, जो SELinux के बराबर हो.

अगर डिवाइस में डीएमए की सुविधा वाले I/O डिवाइसों का इस्तेमाल किया जाता है, तो:

• [C-SR-9] हमारा सुझाव है कि DMA की सुविधा वाले हर I/O डिवाइस को अलग करें. इसके लिए, IOMMU (जैसे, ARM SMMU) का इस्तेमाल करें.

Android में कई ऐसी सुविधाएं हैं जो डिवाइस की सुरक्षा के लिए ज़रूरी हैं. इसके अलावा, Android उन सामान्य गड़बड़ियों की मुख्य कैटगरी को कम करने पर फ़ोकस करता है जिनकी वजह से ऐप्लिकेशन की क्वालिटी और सुरक्षा खराब होती है.

मेमोरी से जुड़ी गड़बड़ियों को कम करने के लिए, डिवाइस में ये बदलाव करें:

• [C-SR-10] हमारा सुझाव है कि इनका टेस्ट, यूज़रस्पेस मेमोरी में गड़बड़ी का पता लगाने वाले टूल का इस्तेमाल करके किया जाए. जैसे, ARMv9 डिवाइसों के लिए MTE, ARMv8+ डिवाइसों के लिए HWASan या अन्य तरह के डिवाइसों के लिए ASan.
• [C-SR-11] हमारा सुझाव है कि इनका टेस्ट करने के लिए, KASAN (CONFIG_KASAN, ARMv9 डिवाइसों के लिए CONFIG_KASAN_HW_TAGS, ARMv8 डिवाइसों के लिए CONFIG_KASAN_SW_TAGS या अन्य डिवाइस टाइप के लिए CONFIG_KASAN_GENERIC) जैसे कर्नेल मेमोरी गड़बड़ी का पता लगाने वाले टूल का इस्तेमाल करें.
• [C-SR-12] हमारा सुझाव है कि आप प्रोडक्शन में, मेमोरी में गड़बड़ी का पता लगाने वाले टूल का इस्तेमाल करें. जैसे, MTE, GWP-ASan, और KFENCE.

अगर डिवाइस में Arm TrustZone पर आधारित टीईई का इस्तेमाल किया जाता है, तो:

• [C-SR-13] हमारा सुझाव है कि Android और टीईई के बीच मेमोरी शेयर करने के लिए, स्टैंडर्ड प्रोटोकॉल का इस्तेमाल करें. जैसे, Armv8-A (FF-A) के लिए Arm फ़र्मवेयर फ़्रेमवर्क.
• [C-SR-14] हमारा सुझाव है कि भरोसेमंद ऐप्लिकेशन को सिर्फ़ उस मेमोरी को ऐक्सेस करने की अनुमति दें जो ऊपर दिए गए प्रोटोकॉल के ज़रिए उनके साथ साफ़ तौर पर शेयर की गई है. अगर डिवाइस में Arm S-EL2 अपवाद लेवल की सुविधा है, तो इसे सुरक्षित सेगमेंट मैनेजर लागू करना चाहिए. ऐसा न होने पर, TEE OS को इसे लागू करना चाहिए.

नई ज़रूरी शर्तें लागू करना

मेमोरी सेफ़्टी टेक्नोलॉजी, ऐसी टेक्नोलॉजी है जो android:memtagMode मेनिफ़ेस्ट विकल्प का इस्तेमाल करने वाले ऐप्लिकेशन में, कम से कम इन क्लास के बग को कम करती है. इनमें बग होने की संभावना 90% से ज़्यादा होती है:

• हीप बफ़र ओवरफ़्लो
• मुफ़्त में आज़माने के बाद इस्तेमाल करना
• डबल फ़्री
• वाइल्ड फ़्री (non-malloc पॉइंटर के बिना)

डिवाइस पर लागू करने के तरीके:

• [C-SR-15] ro.arm64.memtag.bootctl_supported को सेट करने का ज़रूर सुझाव दिया जाता है.

अगर डिवाइस पर लागू करने की प्रोसेस में, सिस्टम प्रॉपर्टी ro.arm64.memtag.bootctl_supported को 'सही है' पर सेट किया जाता है, तो:

• [C-3-1] सिस्टम प्रॉपर्टी arm64.memtag.bootctl को, इन वैल्यू की सूची को कोमा लगाकर अलग करने की अनुमति देनी चाहिए. साथ ही, अगले रीबूट पर, इन वैल्यू का मनमुताबिक असर भी दिखना चाहिए:

  • memtag: ऊपर बताई गई मेमोरी सेफ़्टी टेक्नोलॉजी चालू है
  • memtag-once: ऊपर बताई गई मेमोरी सेफ़्टी टेक्नोलॉजी, कुछ समय के लिए चालू रहती है. अगले रीबूट के बाद, यह अपने-आप बंद हो जाती है
  • memtag-off: ऊपर बताई गई मेमोरी सुरक्षा टेक्नोलॉजी बंद है

• [C-3-2] शेल उपयोगकर्ता को arm64.memtag.bootctl सेट करने की अनुमति होनी चाहिए.

• [C-3-3] किसी भी प्रोसेस को arm64.memtag.bootctl पढ़ने की अनुमति देनी चाहिए.

• [C-3-4] बूट होने पर, arm64.memtag.bootctl को मौजूदा अनुरोध किए गए स्टेटस पर सेट करना ज़रूरी है. अगर डिवाइस पर लागू करने की सुविधा, सिस्टम प्रॉपर्टी में बदलाव किए बिना स्टेटस में बदलाव करने की अनुमति देती है, तो प्रॉपर्टी को भी अपडेट करना ज़रूरी है.

• [C-SR-16] हमारा सुझाव है कि आप एक ऐसी डेवलपर सेटिंग दिखाएं जो डिवाइस को रीबूट करने के साथ-साथ, memtag-once को सेट करती हो. काम करने वाले बूटलोडर की मदद से, Android Open Source Project, MTE बूटलोडर प्रोटोकॉल के ज़रिए ऊपर दी गई ज़रूरी शर्तों को पूरा करता है.

• [C-SR-17] हमारा सुझाव है कि आप सुरक्षा सेटिंग मेन्यू में एक सेटिंग दिखाएं, जिससे उपयोगकर्ता memtag को चालू कर सके.

नई ज़रूरी शर्तों को खत्म करना

9.8. निजता

9.8.1. इस्तेमाल का इतिहास

Android, उपयोगकर्ता की पसंद का इतिहास सेव करता है और UsageStatsManager की मदद से इस इतिहास को मैनेज करता है.

डिवाइस पर लागू करने के तरीके:

• [C-0-1] उपयोगकर्ता के इस इतिहास को तय समय तक सेव रखना ज़रूरी है.
• [C-SR-1] हमारा सुझाव है कि आप 14 दिनों के लिए डेटा सेव रखने की अवधि को, AOSP के लागू होने पर डिफ़ॉल्ट रूप से कॉन्फ़िगर किए गए तौर पर ही रखें.

Android, StatsLog आइडेंटिफ़ायर का इस्तेमाल करके सिस्टम इवेंट सेव करता है. साथ ही, StatsManager और IncidentManager सिस्टम एपीआई की मदद से इस तरह के इतिहास को मैनेज करता है.

डिवाइस पर लागू करने के तरीके:

• [C-0-2] System API क्लास IncidentManager से जनरेट की गई गड़बड़ी की रिपोर्ट में, सिर्फ़ DEST_AUTOMATIC के निशान वाले फ़ील्ड शामिल होने चाहिए.
• [C-0-3] StatsLog SDK दस्तावेज़ों में बताए गए इवेंट के अलावा, किसी दूसरे इवेंट को लॉग करने के लिए, सिस्टम इवेंट आइडेंटिफ़ायर का इस्तेमाल नहीं करना चाहिए. अगर अतिरिक्त सिस्टम इवेंट लॉग किए जाते हैं, तो वे 1,00,000 से 2,00,000 के बीच के किसी अलग ऐटम आइडेंटिफ़ायर का इस्तेमाल कर सकते हैं.

9.8.2. रिकॉर्डिंग

डिवाइस पर लागू करने के तरीके:

• [C-0-1] डिवाइस में पहले से मौजूद ऐसे सॉफ़्टवेयर कॉम्पोनेंट को डिवाइस में पहले से लोड या डिस्ट्रिब्यूट नहीं किया जाना चाहिए जो उपयोगकर्ता की सहमति लिए बिना या चल रही सूचनाओं को हटाकर, उपयोगकर्ता की निजी जानकारी (जैसे, कीस्ट्रोक, स्क्रीन पर दिखने वाला टेक्स्ट, गड़बड़ी की रिपोर्ट) को डिवाइस से भेजते हों.
• [C-0-2] उपयोगकर्ता को चेतावनी दिखानी होगी और उपयोगकर्ता की साफ़ तौर पर सहमति लेनी होगी. इससे उपयोगकर्ता की स्क्रीन पर दिखने वाली किसी भी संवेदनशील जानकारी को कैप्चर करने की अनुमति मिलती है. इसमें AOSP जैसा ही मैसेज शामिल होना चाहिए. जब भी स्क्रीन कैप्चर करने के लिए स्क्रीन कास्टिंग या स्क्रीन रिकॉर्डिंग की सुविधा चालू की जाती है, तो MediaProjection.createVirtualDisplay(), VirtualDeviceManager.createVirtualDisplay() या मालिकाना एपीआई के ज़रिए शुरू करने पर, यह मैसेज दिखना चाहिए. उपयोगकर्ताओं को, आने वाले समय में सहमति दिखाने की सुविधा बंद करने का विकल्प नहीं देना चाहिए.
• [C-0-3] स्क्रीन कास्टिंग या स्क्रीन रिकॉर्डिंग चालू होने पर, उपयोगकर्ता को सूचना मिलनी चाहिए. AOSP, स्टेटस बार में चल रही सूचना का आइकॉन दिखाकर, इस ज़रूरी शर्त को पूरा करता है.

नई ज़रूरी शर्तें लागू करना

• [C-SR-1] हमारा सुझाव है कि उपयोगकर्ता को चेतावनी देने वाला वही मैसेज दिखाया जाए जो AOSP में लागू किया गया है. हालांकि, इसमें बदलाव किया जा सकता है. हालांकि, यह ज़रूरी है कि मैसेज में उपयोगकर्ता को साफ़ तौर पर चेतावनी दी गई हो कि उसकी स्क्रीन पर मौजूद संवेदनशील जानकारी कैप्चर की जा रही है.

• [C-0-4] ऐप्लिकेशन को उपयोगकर्ताओं को स्क्रीन कैप्चर करने के लिए, सहमति देने के अनुरोधों को बंद करने की सुविधा नहीं देनी चाहिए. ऐसा तब तक नहीं किया जाना चाहिए, जब तक कि सेशन को किसी ऐसे सिस्टम ऐप्लिकेशन ने शुरू न किया हो जिसे उपयोगकर्ता ने associate() के साथ अनुमति दी हो या android.app.role.COMPANION_DEVICE_APP_STREAMING या android.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMING डिवाइस प्रोफ़ाइल के साथ अनुमति दी हो.

  नई ज़रूरी शर्तें खत्म करना

अगर डिवाइस में लागू किए गए सिस्टम में ऐसी सुविधा शामिल है जो स्क्रीन पर दिखने वाले कॉन्टेंट को कैप्चर करती है और/या डिवाइस पर System API ContentCaptureService या सेक्शन 9.8.6 OS-लेवल और ऐंबियंट डेटा में बताए गए मालिकाना हक वाले अन्य तरीकों के अलावा, किसी अन्य तरीके से डिवाइस पर चल रही ऑडियो स्ट्रीम को रिकॉर्ड करती है, तो:

• [C-1-1] जब भी यह सुविधा चालू हो और गतिविधि रिकॉर्ड की जा रही हो, तो उपयोगकर्ता को इसकी सूचना दी जानी चाहिए.

अगर डिवाइस में पहले से चालू कोई ऐसा कॉम्पोनेंट शामिल है जो आस-पास के ऑडियो को रिकॉर्ड कर सकता है और/या उपयोगकर्ता के संदर्भ के बारे में काम की जानकारी पाने के लिए, डिवाइस पर चलाए जा रहे ऑडियो को रिकॉर्ड कर सकता है, तो:

• [C-2-1] रिकॉर्ड किए गए रॉ ऑडियो या किसी ऐसे फ़ॉर्मैट को डिवाइस के स्टोरेज में सेव नहीं किया जाना चाहिए जिसे उपयोगकर्ता की साफ़ तौर पर सहमति के बिना, मूल ऑडियो या मिलते-जुलते ऑडियो में बदला जा सकता हो. इसके अलावा, डिवाइस से ऑडियो को कहीं भी नहीं भेजा जाना चाहिए.

“माइक्रोफ़ोन इंडिकेटर” का मतलब स्क्रीन पर दिखने वाले ऐसे व्यू से है जो उपयोगकर्ता को लगातार दिखता है और जिसे छिपाया नहीं जा सकता. इससे उपयोगकर्ताओं को पता चलता है कि माइक्रोफ़ोन का इस्तेमाल किया जा रहा है. यह जानकारी, यूनीक टेक्स्ट, रंग, आइकॉन या इनमें से किसी कॉम्बिनेशन के ज़रिए दी जाती है.

“कैमरा इंडिकेटर” का मतलब स्क्रीन पर दिखने वाले ऐसे व्यू से है जो उपयोगकर्ता को हमेशा दिखता है और जिसे छिपाया नहीं जा सकता. इससे उपयोगकर्ताओं को पता चलता है कि कैमरा इस्तेमाल में है. यह जानकारी, यूनीक टेक्स्ट, रंग, आइकॉन या इनमें से किसी कॉम्बिनेशन के ज़रिए दी जाती है.

एक सेकंड के बाद, इंडिकेटर का विज़ुअल बदल सकता है. जैसे, वह छोटा हो सकता है. साथ ही, उसे उसी तरह दिखाने की ज़रूरत नहीं है जिस तरह उसे मूल रूप से दिखाया गया था और समझा गया था.

माइक्रोफ़ोन इंडिकेटर को, चालू कैमरे के इंडिकेटर के साथ मर्ज किया जा सकता है. हालांकि, इसके लिए ज़रूरी है कि टेक्स्ट, आइकॉन या रंगों से उपयोगकर्ता को यह पता चलता हो कि माइक्रोफ़ोन का इस्तेमाल शुरू हो गया है.

कैमरे के इंडिकेटर को, माइक्रोफ़ोन के इंडिकेटर के साथ मर्ज किया जा सकता है. हालांकि, इसके लिए ज़रूरी है कि टेक्स्ट, आइकॉन या रंगों से उपयोगकर्ता को यह पता चलता हो कि कैमरे का इस्तेमाल शुरू हो गया है.

अगर डिवाइस पर android.hardware.microphone लागू किया जाता है, तो:

• [C-SR-1] हमारा सुझाव है कि जब कोई ऐप्लिकेशन माइक्रोफ़ोन से ऑडियो डेटा ऐक्सेस कर रहा हो, तो माइक्रोफ़ोन इंडिकेटर दिखाएं. हालांकि, जब माइक्रोफ़ोन को सिर्फ़ HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService या सीडीडी आइडेंटिफ़ायर [C-3-X] वाले सेक्शन 9.1 में बताई गई भूमिकाओं वाले ऐप्लिकेशन ऐक्सेस करते हैं, तब ऐसा न करें. .
• [C-SR-2] हमारा सुझाव है कि माइक्रोफ़ोन का इस्तेमाल करके, हाल ही में इस्तेमाल किए गए और चालू ऐप्लिकेशन की सूची दिखाएं. यह सूची, PermissionManager.getIndicatorAppOpUsageData() से मिली जानकारी के आधार पर बनाई जानी चाहिए. साथ ही, उन ऐप्लिकेशन से जुड़े एट्रिब्यूशन मैसेज भी दिखाए जाने चाहिए.
• [C-SR-3] हमारा सुझाव है कि ऐसे सिस्टम ऐप्लिकेशन के लिए माइक्रोफ़ोन इंडिकेटर को न छिपाएं जिनमें यूज़र इंटरफ़ेस दिखते हैं या जिनमें उपयोगकर्ता सीधे तौर पर इंटरैक्ट करता है.

अगर डिवाइस पर android.hardware.camera.any लागू किया जाता है, तो:

• [C-SR-4] हमारा सुझाव है कि जब कोई ऐप्लिकेशन कैमरे का लाइव डेटा ऐक्सेस कर रहा हो, तब कैमरे का इंडिकेटर दिखाया जाए.हालांकि, जब कैमरे को सिर्फ़ उन ऐप्लिकेशन के ज़रिए ऐक्सेस किया जा रहा हो जिनके पास सीडीडी आइडेंटिफ़ायर [C-3-X] के साथ अनुमतियां हैं, तब ऐसा न करें.
• [C-SR-5] हमारा सुझाव है कि PermissionManager.getIndicatorAppOpUsageData() से मिले कैमरे के डेटा का इस्तेमाल करके, हाल ही में इस्तेमाल किए गए और चालू ऐप्लिकेशन दिखाएं. साथ ही, उनसे जुड़े एट्रिब्यूशन मैसेज भी दिखाएं.
• [C-SR-6] हमारा सुझाव है कि ऐसे सिस्टम ऐप्लिकेशन के लिए कैमरे के इंडिकेटर को न छिपाएं जिनमें यूज़र इंटरफ़ेस या सीधे तौर पर उपयोगकर्ता इंटरैक्शन दिखता हो.

9.8.3. कनेक्टिविटी

अगर डिवाइस में यूएसबी पोर्ट है और वह यूएसबी पेरिफ़रल मोड के साथ काम करता है, तो:

• [C-1-1] यूएसबी पोर्ट से शेयर किए गए स्टोरेज के कॉन्टेंट का ऐक्सेस देने से पहले, उपयोगकर्ता से सहमति मांगने के लिए यूज़र इंटरफ़ेस (यूआई) दिखाना ज़रूरी है.

9.8.4. नेटवर्क ट्रैफ़िक

डिवाइस पर लागू करने के तरीके:

• [C-0-1] सिस्टम के भरोसेमंद सर्टिफ़िकेट देने वाली संस्था (सीए) के स्टोर के लिए, वही रूट सर्टिफ़िकेट पहले से इंस्टॉल होने चाहिए जो अपस्ट्रीम Android Open Source Project में उपलब्ध हैं.
• [C-0-2] यह ज़रूरी है कि उपयोगकर्ता के रूट सीए स्टोर में कोई डेटा न हो.
• [C-0-3] उपयोगकर्ता को चेतावनी दिखानी चाहिए, जिसमें बताया गया हो कि उपयोगकर्ता रूट सीए जोड़ने पर, नेटवर्क ट्रैफ़िक को मॉनिटर किया जा सकता है.

अगर डिवाइस का ट्रैफ़िक वीपीएन के ज़रिए भेजा जाता है, तो डिवाइस पर ये काम किए जा सकते हैं:

• [C-1-1] उपयोगकर्ता को चेतावनी दिखानी ज़रूरी है. इसमें इनमें से कोई एक जानकारी होनी चाहिए:
  • उस नेटवर्क ट्रैफ़िक को मॉनिटर किया जा सकता है.
  • वह नेटवर्क ट्रैफ़िक, वीपीएन की सुविधा देने वाले खास वीपीएन ऐप्लिकेशन से भेजा जा रहा है.

अगर डिवाइस में कोई ऐसा तरीका है जो डिफ़ॉल्ट रूप से चालू होता है और नेटवर्क डेटा ट्रैफ़िक को प्रॉक्सी सर्वर या वीपीएन गेटवे से रूट करता है, तो:android.permission.CONTROL_VPN

• [C-2-1] इस सुविधा को चालू करने से पहले, उपयोगकर्ता की सहमति लेना ज़रूरी है. ऐसा तब तक करना होगा, जब तक कि डिवाइस नीति नियंत्रक ने DevicePolicyManager.setAlwaysOnVpnPackage() के ज़रिए उस वीपीएन को चालू न कर दिया हो. इस मामले में, उपयोगकर्ता को अलग से सहमति देने की ज़रूरत नहीं है. हालांकि, उसे इसकी सूचना देना ज़रूरी है.

अगर डिवाइस में, तीसरे पक्ष के वीपीएन ऐप्लिकेशन के "हमेशा चालू वीपीएन" फ़ंक्शन को टॉगल करने के लिए, उपयोगकर्ता के लिए कोई सुविधा लागू की जाती है, तो:

• [C-3-1] AndroidManifest.xml फ़ाइल में, हमेशा चालू रहने वाली वीपीएन सेवा के साथ काम न करने वाले ऐप्लिकेशन के लिए, इस यूज़र अफ़र्डेंस को बंद करना ज़रूरी है. इसके लिए, SERVICE_META_DATA_SUPPORTS_ALWAYS_ON एट्रिब्यूट को false पर सेट करें.

9.8.5. डिवाइस पहचानकर्ता

डिवाइस पर लागू करने के तरीके:

• [C-0-1] ऐप्लिकेशन को डिवाइस के सीरियल नंबर और जहां लागू हो वहां IMEI/MEID, सिम का सीरियल नंबर, और इंटरनैशनल मोबाइल सब्सक्राइबर आइडेंटिटी (IMSI) को ऐक्सेस करने से रोकना चाहिए. ऐसा तब तक करना चाहिए, जब तक कि ऐप्लिकेशन इनमें से किसी एक ज़रूरी शर्त को पूरा न कर दे:
  • यह मोबाइल और इंटरनेट सेवा देने वाली कंपनी का ऐसा ऐप्लिकेशन है जिसकी पुष्टि डिवाइस बनाने वाली कंपनियों ने की है.
  • को READ_PRIVILEGED_PHONE_STATE अनुमति दी गई है.
  • यूआईसीसी के लिए कैरियर के खास अधिकार में बताए गए कैरियर के खास अधिकार हों.
  • डिवाइस का मालिक या प्रोफ़ाइल का मालिक हो और उसे READ_PHONE_STATE अनुमति मिली हो.
  • (सिर्फ़ सिम के सीरियल नंबर/आईसीसीआईडी के लिए) स्थानीय नियमों के मुताबिक, ऐप्लिकेशन को सदस्य की पहचान में हुए बदलावों का पता लगाना ज़रूरी है.

9.8.6. कॉन्टेंट कैप्चर और ऐप्लिकेशन सर्चओएस-लेवल और ऐंबियंट डेटा

Android, डिवाइस पर लागू करने के लिए एक तरीके का इस्तेमाल करता है. यह तरीका, सिस्टम एपीआई ContentCaptureService, AugmentedAutofillService, AppSearchGlobalManager.query या अन्य मालिकाना तरीकों के ज़रिए काम करता है. इसकी मदद से, ऐप्लिकेशन और उपयोगकर्ता के बीच डेटा इंटरैक्शन और संवेदनशील डेटा को कैप्चर किया जाता है:

• स्क्रीन पर रेंडर किया गया टेक्स्ट और ग्राफ़िक्स. इसमें AssistStructure एपीआई के ज़रिए सूचनाएं और सहायता डेटा के अलावा, और भी चीज़ें शामिल हो सकती हैं.
• डिवाइस पर रिकॉर्ड किया गया या चलाया गया मीडिया डेटा, जैसे कि ऑडियो या वीडियो.
• इनपुट इवेंट (जैसे, की, माउस, जेस्चर, आवाज़, वीडियो, और सुलभता).

नई ज़रूरी शर्तें लागू करना

• AugmentedAutofillService के ज़रिए सिस्टम को भेजी गई कोई भी स्क्रीन या अन्य डेटा.
• Content Capture एपीआई की मदद से ऐक्सेस की जा सकने वाली कोई भी स्क्रीन या अन्य डेटा.
• FieldClassificationService एपीआई के ज़रिए ऐक्सेस की जा सकने वाली कोई भी स्क्रीन या अन्य डेटा
• AppSearchManager एपीआई के ज़रिए सिस्टम को भेजा गया कोई भी ऐप्लिकेशन डेटा, जो AppSearchGlobalManager.query के ज़रिए ऐक्सेस किया जा सकता है.

नई ज़रूरी शर्तें खत्म करना

• ऐसे अन्य इवेंट जो कोई ऐप्लिकेशन, Content Capture एपीआई या AppSearchManager एपीआई के ज़रिए सिस्टम को उपलब्ध कराता है. ये एपीआई, Android और मालिकाना एपीआई के तौर पर काम करते हैं.

• टेक्स्ट का मतलब समझने के लिए, TextClassifier API के ज़रिए सिस्टम टेक्स्ट क्लासिफ़ायर यानी सिस्टम सेवा को भेजा गया कोई भी टेक्स्ट या अन्य डेटा. साथ ही, टेक्स्ट के आधार पर अनुमानित अगली कार्रवाइयां जनरेट करना.
• प्लैटफ़ॉर्म पर AppSearch लागू करने से इंडेक्स किया गया डेटा. इसमें टेक्स्ट, ग्राफ़िक्स, मीडिया डेटा या मिलता-जुलता अन्य डेटा शामिल है.

नई ज़रूरी शर्तें लागू करना

• बोली पहचानने की सुविधा के लागू होने पर, SpeechRecognizer#onDeviceSpeechRecognizer() का इस्तेमाल करने से मिला ऑडियो डेटा.
• AudioRecord, SoundTrigger या अन्य ऑडियो एपीआई की मदद से, बैकग्राउंड में (लगातार) इकट्ठा किया गया ऑडियो डेटा, जो उपयोगकर्ता को दिखने वाला इंडिकेटर नहीं दिखाता
• CameraManager या अन्य Camera API की मदद से, बैकग्राउंड में (लगातार) कैमरे का डेटा हासिल किया जाता है. इससे उपयोगकर्ता को कोई इंडिकेटर नहीं दिखता

नई ज़रूरी शर्तें खत्म करना

अगर डिवाइस पर लागू किए गए टूल, ऊपर दिए गए किसी भी डेटा को कैप्चर करते हैं, तो वे:

• [C-1-1] डिवाइस में सेव किए जाने पर, इस तरह के सभी डेटा को एन्क्रिप्ट करना ज़रूरी है. इस एन्क्रिप्शन को Android फ़ाइल के आधार पर एन्क्रिप्शन या Cipher SDK में बताए गए एपीआई वर्शन 26 और उसके बाद के वर्शन के तौर पर सूची में शामिल किसी भी सिफर का इस्तेमाल करके किया जा सकता है.
• [C-1-2] Android के बैकअप लेने के तरीकों या किसी भी दूसरे बैकअप लेने के तरीके का इस्तेमाल करके, रॉ या एन्क्रिप्ट (सुरक्षित) किए गए डेटा का बैक अप नहीं लेना चाहिए.
• [C-1-3] ऐप्लिकेशन को सिर्फ़ ऐसा डेटा और लॉग डिवाइस से बाहर भेजना चाहिए. इसके लिए, उसे निजता बनाए रखने वाले तरीके का इस्तेमाल करना होगा. हालांकि, हर बार डेटा शेयर करने के लिए, उपयोगकर्ता की साफ़ तौर पर सहमति लेना ज़रूरी है. निजता बनाए रखने वाले तरीके को “ऐसा तरीका कहा जाता है जो सिर्फ़ एग्रीगेट में विश्लेषण की अनुमति देता है और अलग-अलग उपयोगकर्ताओं के लिए, लॉग किए गए इवेंट या डेटा से मिले नतीजों को मैच करने से रोकता है”. ऐसा इसलिए किया जाता है, ताकि हर उपयोगकर्ता के डेटा को इंट्रोस्पेक्शन (विश्लेषण) से बचाया जा सके. उदाहरण के लिए, RAPPOR जैसी अलग-अलग निजता टेक्नोलॉजी का इस्तेमाल करके लागू किया जाता है.
• [C-1-4] इस तरह के डेटा को डिवाइस पर मौजूद किसी भी उपयोगकर्ता की पहचान (जैसे, Account) के साथ नहीं जोड़ा जाना चाहिए. हालांकि, डेटा को हर बार जोड़ने के लिए, उपयोगकर्ता की साफ़ तौर पर सहमति लेनी होगी.
• [C-1-5] इस डेटा को ऐसे ओएस कॉम्पोनेंट के साथ शेयर नहीं किया जाना चाहिए जो मौजूदा सेक्शन (9.8.6 कॉन्टेंट कैप्चर ओएस-लेवल और ऐंबियंट डेटा) में बताई गई ज़रूरी शर्तों का पालन नहीं करते. हालांकि, हर बार डेटा शेयर करने के लिए, उपयोगकर्ता की साफ़ तौर पर सहमति लेना ज़रूरी है. जब तक कि ऐसी सुविधा को Android SDK टूल के एपीआई (AmbientContext, HotwordDetectionService) के तौर पर न बनाया गया हो.
• [C-1-6] उपयोगकर्ता को ऐसा डेटा मिटाने का विकल्प देना ज़रूरी है जिसे ContentCaptureService के लागू होने या मालिकाना हक वाले तरीके से इकट्ठा किया गया हो. ऐसा तब करना होगा, जब डिवाइस पर डेटा किसी भी फ़ॉर्मैट में सेव किया गया हो. अगर उपयोगकर्ता ने डेटा मिटाने का विकल्प चुना है, तो इकट्ठा किया गया सारा पुराना डेटा हटाना ज़रूरी है.
• [C-1-7] उपयोगकर्ता को, AppSearch या मालिकाना हक वाले तरीकों से इकट्ठा किए गए डेटा को Android प्लैटफ़ॉर्म पर दिखाए जाने से ऑप्ट-आउट करने का विकल्प देना ज़रूरी है. जैसे, लॉन्चर.
• [C-SR-1] हमारा सुझाव है कि इंटरनेट की अनुमति का अनुरोध न करें.
• [C-SR-2] हमारा सुझाव है कि इंटरनेट को सिर्फ़ स्ट्रक्चर्ड एपीआई के ज़रिए ऐक्सेस करें. ये एपीआई, सार्वजनिक तौर पर उपलब्ध ओपन-सोर्स के ज़रिए काम करते हैं.

नई ज़रूरी शर्तें लागू करना

• [C-SR-4] हमारा सुझाव है कि इन्हें Android SDK API या OEM के मालिकाना हक वाली किसी ऐसी ही ओपन-सोर्स रिपॉज़िटरी के साथ लागू करें. इसके अलावा, इन्हें सैंडबॉक्स किए गए तरीके से भी लागू किया जा सकता है. इसके बारे में ज़्यादा जानने के लिए, 9.8.15 सैंडबॉक्स किए गए एपीआई को लागू करने का तरीका देखें.

नई ज़रूरी शर्तों को खत्म करना

अगर डिवाइस में ऐसी सेवा शामिल है जो System APIContentCaptureService, AppSearchManager.index या ऐसी मालिकाना सेवा को लागू करती है जो ऊपर बताए गए तरीके से डेटा कैप्चर करती है, तो:

• [C-2-1] उपयोगकर्ताओं को सेवाओं को, उपयोगकर्ता के इंस्टॉल किए जा सकने वाले ऐप्लिकेशन या सेवा से बदलने की अनुमति नहीं देनी चाहिए. साथ ही, सिर्फ़ पहले से इंस्टॉल की गई सेवाओं को ऐसा डेटा कैप्चर करने की अनुमति देनी चाहिए.
• [C-2-2] पहले से इंस्टॉल की गई सेवाओं के अलावा, किसी भी ऐप्लिकेशन को ऐसा डेटा कैप्चर करने की अनुमति नहीं दी जानी चाहिए.
• [C-2-3] सेवाओं को बंद करने के लिए, उपयोगकर्ता को आसानी से ऐक्सेस करने की सुविधा देना ज़रूरी है.
• [C-2-4] सेवाओं के पास मौजूद Android अनुमतियों को मैनेज करने के लिए, उपयोगकर्ता को अनुमति देने की सुविधा को शामिल करना ज़रूरी है. साथ ही, सेक्शन 9.1 में बताए गए Android अनुमतियों के मॉडल का पालन करना ज़रूरी है. अनुमति.

• [C-SR-3] हमारा सुझाव है कि सेवाओं को सिस्टम के अन्य कॉम्पोनेंट से अलग रखें.उदाहरण के लिए, सेवा को बाइंड न करना या प्रोसेस आईडी शेयर न करना. हालांकि, इन मामलों में ऐसा नहीं करना चाहिए:

  • टेलीफ़ोनी, संपर्क, सिस्टम यूज़र इंटरफ़ेस (यूआई), और मीडिया

Android, SpeechRecognizer#onDeviceSpeechRecognizer() की मदद से, नेटवर्क का इस्तेमाल किए बिना डिवाइस पर बोली पहचानने की सुविधा देता है. डिवाइस पर SpeechRecognizer को लागू करने के लिए, इस सेक्शन में बताई गई नीतियों का पालन करना ज़रूरी है.

9.8.7. क्लिपबोर्ड का ऐक्सेस

डिवाइस पर लागू करने के तरीके:

• [C-0-1] तीसरे पक्ष के ऐप्लिकेशन को क्लिपबोर्ड से कॉपी किया गया डेटा तब तक नहीं दिखाना चाहिए, जब तक वह डिफ़ॉल्ट IME ऐप्लिकेशन न हो या फ़िलहाल फ़ोकस में न हो. उदाहरण के लिए, ClipboardManager एपीआई के ज़रिए.

• [C-0-2] क्लिपबोर्ड में डेटा डालने या उससे डेटा पढ़ने के 60 मिनट के अंदर, उसे मिटा देना ज़रूरी है.

9.8.8. जगह की जानकारी

जगह की जानकारी में, Android Location क्लास की जानकारी शामिल होती है. जैसे, अक्षांश, रेखांश, और ऊंचाई. साथ ही, इसमें ऐसे आइडेंटिफ़ायर भी शामिल होते हैं जिन्हें जगह की जानकारी में बदला जा सकता है. जगह की जानकारी, डीजीपीएस (डफ़रेंशियल ग्लोबल पोज़िशनिंग सिस्टम) के ज़रिए ज़्यादा सटीक या देश के लेवल पर ज़्यादा कम सटीक हो सकती है. जैसे, देश कोड वाली जगह की जानकारी - एमसीसी - मोबाइल देश कोड.

यहां जगह की जानकारी के उन टाइप की सूची दी गई है जो सीधे तौर पर उपयोगकर्ता की जगह की जानकारी देते हैं या जिन्हें उपयोगकर्ता की जगह की जानकारी में बदला जा सकता है. यह पूरी सूची नहीं है. हालांकि, इसका इस्तेमाल इस उदाहरण के तौर पर किया जाना चाहिए कि जगह की जानकारी को सीधे या किसी और तरीके से कहां से हासिल किया जा सकता है:

• GPS/GNSS/DGPS/PPP
  • ग्लोबल पोज़िशनिंग सलूशन या ग्लोबल नेविगेशन सैटलाइट सिस्टम या डफ़रेंशियल ग्लोबल पोज़िशनिंग सलूशन
  • इसमें रॉ जीएनएसएस मेज़रमेंट और जीएनएसएस स्टेटस भी शामिल है
    • जीएनएसएस की रॉ मेज़रमेंट से, सटीक जगह की जानकारी मिल सकती है
• यूनीक आइडेंटिफ़ायर वाली वायरलेस टेक्नोलॉजी, जैसे:
  • वाई-फ़ाई ऐक्सेस पॉइंट (MAC, BSSID, नाम या SSID)
  • ब्लूटूथ/BLE (MAC, BSSID, नाम या SSID)
  • UWB (MAC, BSSID, नाम या SSID)
  • सेल टावर आईडी (3G, 4G, 5G… इसमें आने वाले समय में इस्तेमाल होने वाली सभी सेल्युलर मॉडेम टेक्नोलॉजी शामिल हैं जिनमें यूनीक आइडेंटिफ़ायर होते हैं)

मुख्य संदर्भ के तौर पर, उन Android API को देखें जिनके लिए ACCESS_FINE_Location या ACCESS_COARSE_Location अनुमतियां ज़रूरी हैं.

डिवाइस पर लागू करने के तरीके:

• [C-0-1] ऐप्लिकेशन को उपयोगकर्ता की सहमति लिए बिना या उपयोगकर्ता के निर्देश के बिना, डिवाइस की जगह की जानकारी की सेटिंग और वाई-फ़ाई/ब्लूटूथ स्कैन करने की सेटिंग को चालू/बंद नहीं करना चाहिए.
• [C-0-2] ऐप्लिकेशन को जगह की जानकारी से जुड़ी जानकारी ऐक्सेस करने के लिए, उपयोगकर्ता को सुविधा देनी चाहिए. इसमें जगह की जानकारी के लिए किए गए हाल ही के अनुरोध, ऐप्लिकेशन लेवल की अनुमतियां, और वाई-फ़ाई/ब्लूटूथ स्कैनिंग का इस्तेमाल शामिल है.
• [C-0-3] यह पक्का करना ज़रूरी है कि आपातकालीन जगह की जानकारी को बायपास करने वाले एपीआई [LocationRequest.setLocationSettingsIgnored()] का इस्तेमाल करने वाला ऐप्लिकेशन, उपयोगकर्ता के शुरू किए गए आपातकालीन सेशन के लिए हो. उदाहरण के लिए, 911 पर कॉल करना या 911 पर मैसेज भेजना. हालांकि, वाहन के लिए, किसी क्रैश/दुर्घटना का पता चलने पर, वाहन उपयोगकर्ता के इंटरैक्शन के बिना आपातकालीन सेशन शुरू कर सकता है. उदाहरण के लिए, eCall की ज़रूरी शर्तों को पूरा करने के लिए.
• [C-0-4] इमरजेंसी लोकेशन बायपास एपीआई की सेटिंग में बदलाव किए बिना, डिवाइस की जगह की जानकारी की सेटिंग को बायपास करने की सुविधा को बनाए रखना ज़रूरी है.
• [C-0-5] ऐप्लिकेशन को ऐसी सूचना शेड्यूल करनी चाहिए जिससे उपयोगकर्ता को यह याद दिलाया जा सके कि बैकग्राउंड में चल रहे किसी ऐप्लिकेशन ने [ACCESS_BACKGROUND_LOCATION] अनुमति का इस्तेमाल करके, उसकी जगह की जानकारी ऐक्सेस की है.

9.8.9. इंस्टॉल किए गए ऐप्लिकेशन

एपीआई लेवल 30 या उसके बाद के वर्शन को टारगेट करने वाले Android ऐप्लिकेशन, डिफ़ॉल्ट रूप से इंस्टॉल किए गए अन्य ऐप्लिकेशन की जानकारी नहीं देख सकते. ज़्यादा जानकारी के लिए, Android SDK के दस्तावेज़ में पैकेज की जानकारी दिखने की सुविधा देखें.

डिवाइस पर लागू करने के तरीके:

• [C-0-1] एपीआई लेवल 30 या उसके बाद के वर्शन को टारगेट करने वाले किसी भी ऐप्लिकेशन को, इंस्टॉल किए गए किसी भी अन्य ऐप्लिकेशन की जानकारी तब तक नहीं दिखाई जानी चाहिए, जब तक कि ऐप्लिकेशन, मैनेज किए जा रहे एपीआई की मदद से, इंस्टॉल किए गए अन्य ऐप्लिकेशन की जानकारी पहले से न देख पा रहा हो. इसमें, डिवाइस को लागू करने वाले व्यक्ति के जोड़े गए कस्टम एपीआई से ज़ाहिर की गई जानकारी या फ़ाइल सिस्टम के ज़रिए ऐक्सेस की जा सकने वाली जानकारी शामिल है. हालांकि, इसमें और भी चीज़ें शामिल हो सकती हैं.
• [C-0-2] किसी भी ऐप्लिकेशन को, बाहरी स्टोरेज में मौजूद किसी दूसरे ऐप्लिकेशन की खास तौर पर बनाई गई डायरेक्ट्री में मौजूद फ़ाइलों को पढ़ने या उनमें बदलाव करने का ऐक्सेस नहीं देना चाहिए. हालांकि, इन मामलों में यह शर्त लागू नहीं होती:
  • बाहरी स्टोरेज की सेवा देने वाली कंपनी (जैसे, DocumentsUI जैसे ऐप्लिकेशन).
  • डाउनलोड करने की सुविधा देने वाली सेवा, जो ऐप्लिकेशन के स्टोरेज में फ़ाइलें डाउनलोड करने के लिए, “डाउनलोड” की सुविधा देने वाली सेवा की अनुमति का इस्तेमाल करती है.
  • प्लैटफ़ॉर्म से साइन किए गए मीडिया ट्रांसफ़र प्रोटोकॉल (एमटीपी) वाले ऐप्लिकेशन, जो किसी दूसरे डिवाइस पर फ़ाइलें ट्रांसफ़र करने की सुविधा चालू करने के लिए, खास अनुमति ACCESS_MTP का इस्तेमाल करते हैं.
  • जिन ऐप्लिकेशन के पास INSTALL_PACKAGES अनुमति होती है और जो अन्य ऐप्लिकेशन इंस्टॉल करते हैं वे सिर्फ़ “obb” डायरेक्ट्री को ऐक्सेस कर सकते हैं. ऐसा, APK एक्सपैंशन फ़ाइलों को मैनेज करने के लिए किया जाता है.

9.8.10. कनेक्टिविटी से जुड़ी गड़बड़ी की शिकायत

अगर डिवाइस में android.hardware.telephony सुविधा फ़्लैग का एलान किया जाता है, तो:

• [C-1-1] BUGREPORT_MODE_TELEPHONY के साथ BugreportManager की मदद से, कनेक्टिविटी से जुड़ी गड़बड़ी की रिपोर्ट जनरेट करने की सुविधा होनी चाहिए.
• [C-1-2] रिपोर्ट जनरेट करने के लिए, हर बार BUGREPORT_MODE_TELEPHONY का इस्तेमाल करने पर, उपयोगकर्ता की सहमति लेना ज़रूरी है. साथ ही, उपयोगकर्ता को ऐप्लिकेशन के आने वाले समय के सभी अनुरोधों के लिए सहमति देने के लिए नहीं कहना चाहिए.
• [C-1-3] उपयोगकर्ता की साफ़ तौर पर सहमति के बिना, जनरेट की गई रिपोर्ट को अनुरोध करने वाले ऐप्लिकेशन को नहीं दिखाना चाहिए.
• [C-1-4] BUGREPORT_MODE_TELEPHONY का इस्तेमाल करके जनरेट की गई रिपोर्ट में, कम से कम यह जानकारी होनी चाहिए:
  • TelephonyDebugService डंप
  • TelephonyRegistry डंप
  • WifiService डंप
  • ConnectivityService डंप
  • कॉल करने वाले पैकेज के CarrierService इंस्टेंस का डंप (अगर बंधा हुआ हो)
  • रेडियो लॉग बफ़र
  • SubscriptionManagerService डंप
• [C-1-5] जनरेट की गई रिपोर्ट में ये शामिल नहीं होने चाहिए:
  • ऐसी कोई भी जानकारी जो सीधे तौर पर कनेक्टिविटी की गड़बड़ी को डीबग करने से जुड़ी न हो.
  • उपयोगकर्ता के इंस्टॉल किए गए ऐप्लिकेशन का ट्रैफ़िक लॉग या उपयोगकर्ता के इंस्टॉल किए गए ऐप्लिकेशन/पैकेज की ज़्यादा जानकारी वाली प्रोफ़ाइलें (यूआईडी ठीक हैं, पैकेज के नाम नहीं).
• इसमें ऐसी अतिरिक्त जानकारी शामिल हो सकती है जो किसी उपयोगकर्ता की पहचान से जुड़ी न हो. (उदाहरण के लिए, वेंडर लॉग).

अगर डिवाइस में गड़बड़ी की जानकारी वाली रिपोर्ट में अतिरिक्त जानकारी (जैसे, वेंडर लॉग) शामिल की जाती है और उस जानकारी से निजता/सुरक्षा/बैटरी/स्टोरेज/मेमोरी पर असर पड़ता है, तो:

• [C-SR-1] हमारा सुझाव है कि डेवलपर सेटिंग को डिफ़ॉल्ट रूप से बंद रखें. AOSP रेफ़रंस को लागू करने से, गड़बड़ी की रिपोर्ट में डिवाइस के हिसाब से अतिरिक्त वेंडर लॉग शामिल करने के लिए, डेवलपर सेटिंग में Enable verbose vendor logging विकल्प मिलता है.

9.8.11. डेटा ब्लॉब शेयर करना

Android, BlobStoreManager के ज़रिए, ऐप्लिकेशन को सिस्टम में डेटा ब्लॉब का योगदान देने की अनुमति देता है, ताकि उन्हें ऐप्लिकेशन के चुने गए सेट के साथ शेयर किया जा सके.

अगर डिवाइस में, SDK टूल के दस्तावेज़ में बताए गए तरीके से शेयर किए गए डेटा ब्लॉब काम करते हैं, तो:

• [C-1-1] ऐप्लिकेशन के डेटा ब्लॉब को, उनके लिए तय की गई अनुमति से ज़्यादा शेयर नहीं किया जाना चाहिए. जैसे, डिफ़ॉल्ट ऐक्सेस का दायरा और अन्य ऐक्सेस मोड, जिनमें BlobStoreManager.session#allowPackageAccess(), BlobStoreManager.session#allowSameSignatureAccess() या BlobStoreManager.session#allowPublicAccess() का इस्तेमाल करके बदलाव नहीं किया जाना चाहिए. AOSP रेफ़रंस लागू करने का तरीका, इन ज़रूरी शर्तों को पूरा करता है.
• [C-1-2] ऐप्लिकेशन को डिवाइस से डेटा ब्लॉब के सुरक्षित हैश को भेजना या अन्य ऐप्लिकेशन के साथ शेयर करना ज़रूरी नहीं है. इन हैश का इस्तेमाल, ऐक्सेस को कंट्रोल करने के लिए किया जाता है.

9.8.12. संगीत की पहचान

Android, System API MusicRecognitionManager की मदद से, डिवाइस पर संगीत की पहचान करने का अनुरोध करने के लिए एक सुविधा देता है. इसके लिए, ऑडियो रिकॉर्ड की ज़रूरत होती है. साथ ही, MusicRecognitionService API को लागू करने वाले किसी ऐप्लिकेशन को संगीत की पहचान करने का काम सौंपा जाता है.

अगर डिवाइस में ऐसी सेवा शामिल है जो System API MusicRecognitionManager को लागू करती है या ऊपर बताई गई तरह से ऑडियो डेटा स्ट्रीम करने वाली कोई मालिकाना सेवा है, तो:

• [C-1-1] यह पक्का करना ज़रूरी है कि MusicRecognitionManager को कॉल करने वाले के पास MANAGE_MUSIC_RECOGNITION की अनुमति हो
• [C-1-2] यह ज़रूरी है कि पहले से इंस्टॉल किया गया, संगीत की पहचान करने वाला कोई एक ऐप्लिकेशन, MusicRecognitionService को लागू करता हो.
• [C-1-3] उपयोगकर्ताओं को MusicRecognitionManagerService या MusicRecognitionService को, उपयोगकर्ता के इंस्टॉल किए जा सकने वाले ऐप्लिकेशन या सेवा से बदलने की अनुमति नहीं देनी चाहिए.
• [C-1-4] यह पक्का करना ज़रूरी है कि जब MusicRecognitionManagerService, ऑडियो रिकॉर्ड को ऐक्सेस करके उसे MusicRecognitionService को लागू करने वाले ऐप्लिकेशन को फ़ॉरवर्ड करे, तो ऑडियो ऐक्सेस को AppOpsManager.noteOp / startOp के इनवोकेशन के ज़रिए ट्रैक किया जाए.

अगर MusicRecognitionManagerService या MusicRecognitionService के डिवाइस के लागू होने पर, कैप्चर किया गया कोई भी ऑडियो डेटा सेव किया जाता है, तो:

• [C-2-1] डिस्क पर किसी भी रॉ ऑडियो या ऑडियो फ़िंगरप्रिंट को सेव नहीं करना चाहिए. इसके अलावा, मेमोरी में भी 14 दिनों से ज़्यादा समय तक सेव नहीं रखना चाहिए.
• [C-2-2] इस तरह के डेटा को MusicRecognitionService के अलावा किसी और के साथ शेयर नहीं किया जाना चाहिए. हालांकि, हर बार डेटा शेयर करने के लिए, उपयोगकर्ता की साफ़ तौर पर सहमति लेना ज़रूरी है.

9.8.13. SensorPrivacyManager

अगर डिवाइस के लागू होने के लिए, उपयोगकर्ता को कैमरे और/या माइक्रोफ़ोन इनपुट को बंद करने का सॉफ़्टवेयर अवसर मिलता है, तो:

• [C-1-1] supportsSensorToggle() एपीआई के काम के तरीके के लिए, 'सही' को सटीक तौर पर दिखाना ज़रूरी है.
• [C-1-2] जब कोई ऐप्लिकेशन ब्लॉक किए गए माइक्रोफ़ोन या कैमरे को ऐक्सेस करने की कोशिश करता है, तो उपयोगकर्ता को ऐसा यूज़र अवफ़र्डेंस दिखाना ज़रूरी है जिसे खारिज नहीं किया जा सकता. इससे साफ़ तौर पर पता चलता है कि सेंसर ब्लॉक है और उसे ब्लॉक करना जारी रखने या अनब्लॉक करने का विकल्प दिया जाता है. यह विकल्प, AOSP के लागू होने के हिसाब से दिया जाना चाहिए.
• [C-1-3] ऐप्लिकेशन को सिर्फ़ खाली (या नकली) कैमरा और ऑडियो डेटा भेजना चाहिए. साथ ही, ऊपर [C-1-2] में बताए गए उपयोगकर्ता के लिए उपलब्ध विकल्पों का इस्तेमाल करके, उपयोगकर्ता के कैमरा या माइक्रोफ़ोन चालू न करने की वजह से गड़बड़ी का कोड नहीं दिखाना चाहिए.

नई ज़रूरी शर्तें लागू करना

9.8.14. क्रेडेंशियल मैनेजर

हटाया गया.

9.8.15. सैंडबॉक्स किए गए एपीआई लागू करना

Android, डिलीगेट एपीआई के सेट की मदद से, ओएस-लेवल और ऐंबियंट डेटा को सुरक्षित तरीके से प्रोसेस करने का तरीका उपलब्ध कराता है. इस तरह की प्रोसेसिंग को, पहले से इंस्टॉल किए गए ऐप्लिकेशन को सौंपा जा सकता है. इसके लिए, ऐप्लिकेशन को खास ऐक्सेस और कम कम्यूनिकेशन की सुविधाएं दी जाती हैं. इसे सैंडबॉक्स किए गए एपीआई के तौर पर जाना जाता है.

सैंडबॉक्स किए गए किसी भी एपीआई को लागू करना:

• [C-0-1] इंटरनेट की अनुमति का अनुरोध नहीं करना चाहिए.
• [C-0-2] ऐप्लिकेशन को सिर्फ़ स्ट्रक्चर्ड एपीआई के ज़रिए इंटरनेट ऐक्सेस करना चाहिए. ये एपीआई, सार्वजनिक तौर पर उपलब्ध ओपन-सोर्स वाले ऐसे टूल के साथ काम करते हैं जो निजता बनाए रखने के तरीकों का इस्तेमाल करते हैं. इसके अलावा, ऐप्लिकेशन को Android SDK टूल के ज़रिए भी इंटरनेट ऐक्सेस करना चाहिए. निजता बनाए रखने वाले तरीके को "ऐसा तरीका कहा जाता है जो सिर्फ़ एग्रीगेट में विश्लेषण की अनुमति देता है और अलग-अलग उपयोगकर्ताओं के लिए, लॉग किए गए इवेंट या डेटा से मिले नतीजों को मैच करने से रोकता है". ऐसा इसलिए किया जाता है, ताकि हर उपयोगकर्ता के डेटा को इंट्रोस्पेक्शन (डेटा का विश्लेषण) न किया जा सके. उदाहरण के लिए, RAPPOR जैसी निजता बनाए रखने की अलग-अलग टेक्नोलॉजी का इस्तेमाल करके लागू किया जाता है.
• [C-0-3] सेवाओं को सिस्टम के अन्य कॉम्पोनेंट से अलग रखना ज़रूरी है.उदाहरण के लिए, सेवा को बाइंड न करना या प्रोसेस आईडी शेयर न करना. हालांकि, इनके लिए ऐसा करना ज़रूरी नहीं है:
  • टेलीफ़ोनी, संपर्क, सिस्टम यूज़र इंटरफ़ेस (यूआई), और मीडिया
• [C-0-4] उपयोगकर्ताओं को सेवाओं को, उपयोगकर्ता के इंस्टॉल किए जा सकने वाले ऐप्लिकेशन या सेवा से बदलने की अनुमति नहीं दी जानी चाहिए
• [C-0-5] सिर्फ़ पहले से इंस्टॉल की गई सेवाओं को इस तरह का डेटा कैप्चर करने की अनुमति देनी चाहिए. जब तक कि AOSP में बदलाव करने की सुविधा पहले से मौजूद न हो (जैसे, डिजिटल असिस्टेंट ऐप्लिकेशन के लिए).
• [C-0-6] पहले से इंस्टॉल की गई सेवाओं के अलावा, किसी भी ऐप्लिकेशन को ऐसा डेटा कैप्चर करने की अनुमति नहीं दी जानी चाहिए. जब तक कि इस तरह की कैप्चर करने की सुविधा, Android SDK टूल के एपीआई के साथ लागू न की गई हो.
• [C-0-7] सेवाओं को बंद करने के लिए, उपयोगकर्ता को आसानी से ऐक्सेस करने की सुविधा देना ज़रूरी है.
• [C-0-8] सेवाओं के पास मौजूद Android अनुमतियों को मैनेज करने के लिए, उपयोगकर्ता को अनुमति देने की सुविधा को शामिल करना ज़रूरी है. साथ ही, सेक्शन 9.1 में बताए गए तरीके के मुताबिक, Android अनुमति मॉडल का पालन करना ज़रूरी है. अनुमति.

9.8.16. ऑडियो और कैमरे का लगातार रिकॉर्ड किया जाने वाला डेटा

9.8.2 रिकॉर्डिंग, 9.8.6 ऑपरेटिंग सिस्टम-लेवल और बैकग्राउंड में रिकॉर्ड होने वाले डेटा, और 9.8.15 सैंडबॉक्स किए गए एपीआई के लागू होने से जुड़ी ज़रूरी शर्तों के अलावा, ऐसे लागू होने की शर्तें जो ऑडियो रिकॉर्ड, साउंड ट्रिगर या अन्य ऑडियो एपीआई के ज़रिए बैकग्राउंड में (लगातार) रिकॉर्ड किए गए ऑडियो डेटा या CameraManager या अन्य कैमरा एपीआई के ज़रिए बैकग्राउंड में (लगातार) रिकॉर्ड किए गए कैमरा डेटा का इस्तेमाल करते हैं:

• [C-0-1] कैमरे और/या माइक्रोफ़ोन के लिए, सेक्शन 9.8.2 रिकॉर्डिंग के मुताबिक इंडिकेटर दिखाना ज़रूरी है. ऐसा तब तक करना होगा, जब तक:
  • यह ऐक्सेस, सैंडबॉक्स किए गए एपीआई को लागू करने के दौरान किया जाता है (9.8.15 सैंडबॉक्स किए गए एपीआई को लागू करने के बारे में जानें). ऐसा, किसी ऐसे पैकेज के ज़रिए किया जाता है जिसमें इनमें से एक या उससे ज़्यादा भूमिकाएं हों: System UI Intelligence, System Ambient Audio Intelligence, System Audio Intelligence, System Notification Intelligence, System Text Intelligence या System Visual Intelligence.
  • ऐक्सेस, सैंडबॉक्स के ज़रिए किया जाता है. इसे AOSP (HotwordDetectionService, WearableSensingService, VisualQueryDetector) में मौजूद तरीकों से लागू और लागू किया जाता है.
  • डिजिटल असिस्टेंट ऐप्लिकेशन, सहायता के मकसद से ऑडियो ऐक्सेस करता है. यह SOURCE_HOTWORD को ऑडियो सोर्स के तौर पर इस्तेमाल करता है.
  • ऐक्सेस करने की प्रोसेस, सिस्टम की ओर से की जाती है और इसे ओपन सोर्स कोड की मदद से लागू किया जाता है.
• [C-SR-1] हमारा सुझाव है कि इस तरह के डेटा का इस्तेमाल करने वाली हर सुविधा के लिए, उपयोगकर्ता की सहमति लेना ज़रूरी हो. साथ ही, यह सुविधा डिफ़ॉल्ट रूप से बंद होनी चाहिए.
• [C-SR-2] हमारा सुझाव है कि पहने जाने वाले किसी रिमोट डिवाइस से आने वाले कैमरे के डेटा पर भी वही शर्तें लागू करें जो 9.8.2 रिकॉर्डिंग, 9.8.6 ओएस-लेवल और ऐंबियंट डेटा, 9.8.15 सैंडबॉक्स किए गए एपीआई लागू करने, और 9.8.16 लगातार रिकॉर्ड होने वाले ऑडियो और कैमरे के डेटा में बताई गई हैं.

अगर कैमरे का डेटा, किसी पहने जाने वाले डिवाइस से भेजा जाता है और उसे Android OS, सैंडबॉक्स किए गए वर्शन या WearableSensingManager की बनाई गई सैंडबॉक्स की गई सुविधा के बाहर, बिना एन्क्रिप्ट किए हुए ऐक्सेस किया जाता है, तो:

• [C-1-1] रिमोट पहने जाने वाले डिवाइस को, वहां एक और इंडिकेटर दिखाने के लिए ज़रूर बताना चाहिए.

अगर डिवाइस, असाइन किए गए कीवर्ड के बिना डिजिटल असिस्टेंट ऐप्लिकेशन के साथ इंटरैक्ट करने की सुविधा देते हैं (या तो उपयोगकर्ता की सामान्य क्वेरी को मैनेज करते हैं या कैमरे की मदद से उपयोगकर्ता की मौजूदगी का विश्लेषण करते हैं), तो:

• [C-2-1] पक्का करें कि ऐसा लागू करने के लिए, android.app.role.ASSISTANT भूमिका वाला पैकेज इस्तेमाल किया गया हो.
• [C-2-2] यह पक्का करना ज़रूरी है कि इस तरह के लागू करने में, HotwordDetectionService और/या VisualQueryDetectionService Android एपीआई का इस्तेमाल किया गया हो.

9.8.17. Telemetry

Android, StatsLog API का इस्तेमाल करके सिस्टम और ऐप्लिकेशन लॉग स्टोर करता है. इन लॉग को StatsManager API की मदद से मैनेज किया जाता है. इनका इस्तेमाल, खास सुविधाओं वाले सिस्टम ऐप्लिकेशन कर सकते हैं.

StatsManager, निजता बनाए रखने वाले तरीके का इस्तेमाल करके, डिवाइसों से निजता के लिहाज़ से संवेदनशील डेटा इकट्ठा करने का भी तरीका उपलब्ध कराता है. खास तौर पर, StatsManager::query एपीआई की मदद से, StatsLog में तय की गई पाबंदी वाली मेट्रिक कैटगरी के बारे में क्वेरी की जा सकती है.

StatsManager से पाबंदी वाली मेट्रिक को इकट्ठा करने और उनसे जुड़ी क्वेरी करने वाला कोई भी लागू करने वाला टूल:

• [C-0-1] यह डिवाइस पर मौजूद एकमात्र ऐप्लिकेशन/इंप्लिकेशन होना चाहिए और उसके पास READ_RESTRICTED_STATS की अनुमति होनी चाहिए.
• [C-0-2] निजता बनाए रखने वाले तरीके का इस्तेमाल करके, सिर्फ़ टेलीमेट्री डेटा और डिवाइस का लॉग भेजना ज़रूरी है. निजता बनाए रखने वाले तरीके को "सिर्फ़ एग्रीगेट में विश्लेषण करने की अनुमति देने वाले और अलग-अलग उपयोगकर्ताओं के लिए लॉग किए गए इवेंट या उनसे मिले नतीजों को मैच करने से रोकने वाले" के तौर पर परिभाषित किया गया है.ऐसा इसलिए किया जाता है, ताकि हर उपयोगकर्ता के डेटा को इंट्रोस्पेक्शन (विश्लेषण) से बचाया जा सके. उदाहरण के लिए, RAPPOR जैसी निजता बनाए रखने वाली अलग-अलग टेक्नोलॉजी का इस्तेमाल करके लागू किया गया.
• [C-0-3] इस तरह के डेटा को डिवाइस पर मौजूद उपयोगकर्ता की किसी भी पहचान (जैसे कि खाता) से नहीं जोड़ना चाहिए.
• [C-0-4] इस डेटा को ऐसे अन्य ओएस कॉम्पोनेंट के साथ शेयर नहीं किया जाना चाहिए जो मौजूदा सेक्शन (9.8.17 निजता बनाए रखने वाला टेलीमेट्री) में बताई गई ज़रूरी शर्तों का पालन नहीं करते.
• [C-0-5] उपयोगकर्ता को यह सुविधा देनी ज़रूरी है कि वह निजता बनाए रखने के लिए, टेलीमेट्री डेटा इकट्ठा करने, उसे इस्तेमाल करने, और शेयर करने की सुविधा को चालू या बंद कर सके.
• [C-0-6] उपयोगकर्ता को ऐसा विकल्प देना ज़रूरी है जिससे वह उस डेटा को मिटा सके जिसे लागू करने के दौरान इकट्ठा किया गया है. ऐसा तब करना होगा, जब डिवाइस पर डेटा किसी भी फ़ॉर्मैट में सेव हो. अगर उपयोगकर्ता ने डेटा मिटाने का विकल्प चुना है, तो डिवाइस पर मौजूद सारा डेटा मिटाना ज़रूरी है.
• [C-0-7] किसी ओपन सोर्स रिपॉज़िटरी में, निजता बनाए रखने वाले प्रोटोकॉल को लागू करने के तरीके के बारे में ज़रूर बताना चाहिए.
• [C-0-8 ]StatsLog में बताई गई प्रतिबंधित मेट्रिक कैटगरी में डेटा इकट्ठा करने से रोकने के लिए, इस सेक्शन में डेटा एक्सग्रेस की नीतियों को लागू करना ज़रूरी है.

नई ज़रूरी शर्तों को खत्म करना

9.9. डेटा स्टोरेज एन्क्रिप्शन

सभी डिवाइसों को सेक्शन 9.9.1 की ज़रूरी शर्तें पूरी करनी होंगी. इस दस्तावेज़ में बताए गए एपीआई लेवल से पहले लॉन्च किए गए डिवाइसों को, सेक्शन 9.9.2 और 9.9.3 की ज़रूरी शर्तों से छूट मिली है. इसके बजाय, उन्हें उस एपीआई लेवल के हिसाब से, Android के साथ काम करने की शर्तों के बारे में बताने वाले दस्तावेज़ के सेक्शन 9.9 में बताई गई ज़रूरी शर्तों को पूरा करना होगा जिस पर डिवाइस लॉन्च किया गया था.

9.9.1. डायरेक्ट बूट

डिवाइस पर लागू करने के तरीके:

• [C-0-1] डायरेक्ट बूट मोड एपीआई को लागू करना ज़रूरी है. भले ही, वे स्टोरेज एन्क्रिप्शन के साथ काम न करते हों.

• [C-0-2] डिवाइस को सीधे चालू करने की सुविधा वाले ऐप्लिकेशन को यह सिग्नल देने के लिए, ACTION_LOCKED_BOOT_COMPLETED और ACTION_USER_UNLOCKED इंटेंट अब भी ब्रॉडकास्ट किए जाने चाहिए कि डिवाइस को एन्क्रिप्ट (डीई) और क्रेडेंशियल को एन्क्रिप्ट (सीई) करने के लिए, स्टोरेज की जगहें उपयोगकर्ता के लिए उपलब्ध हैं.

9.9.2. एन्क्रिप्शन से जुड़ी ज़रूरी शर्तें

डिवाइस पर लागू करने के तरीके:

• [C-0-1] ऐप्लिकेशन के निजी डेटा (/data पार्टीशन) के साथ-साथ, ऐप्लिकेशन के शेयर किए गए स्टोरेज के पार्टीशन (/sdcard पार्टीशन) को एन्क्रिप्ट करना ज़रूरी है. हालांकि, ऐसा तब ही करना होगा, जब यह पार्टीशन डिवाइस का ऐसा हिस्सा हो जिसे हटाया न जा सके.
• [C-0-2] उपयोगकर्ता के आउट-ऑफ़-बॉक्स सेटअप पूरा करने के बाद, डेटा स्टोरेज एन्क्रिप्शन को डिफ़ॉल्ट रूप से चालू करना ज़रूरी है.

• [C-0-3] डेटा स्टोरेज को एन्क्रिप्ट करने से जुड़ी ऊपर दी गई ज़रूरी शर्त को पूरा करना ज़रूरी है. इसके लिए, एन्क्रिप्ट करने के इन दोनों तरीकों में से किसी एक को लागू करें:

  • फ़ाइल के आधार पर एन्क्रिप्शन (एफ़बीई) और मेटाडेटा एन्क्रिप्शन, जैसा कि सेक्शन 9.9.3.1 में बताया गया है.
  • हर उपयोगकर्ता के लिए ब्लॉक-लेवल एन्क्रिप्शन, जैसा कि सेक्शन 9.9.3.2 में बताया गया है.

ध्यान दें: एपीआई लेवल 28 या उससे पहले के वर्शन पर शिप किए गए डिवाइसों के लिए, सिस्टम सॉफ़्टवेयर अपडेट की मदद से 9.9.2 में दी गई ज़रूरी शर्तें पूरी करना ज़रूरी है. इसके लिए, डिवाइस के एपीआई लेवल के हिसाब से, Android Compatibility Definition दस्तावेज़ के सेक्शन 9.9 में दी गई ज़रूरी शर्तें पूरी करनी होंगी.

9.9.3. एन्क्रिप्ट (सुरक्षित) करने के तरीके

अगर डिवाइस पर एन्क्रिप्शन लागू किया गया है, तो:

• [C-1-1] डिवाइस को उपयोगकर्ता से क्रेडेंशियल मांगे बिना, ACTION_LOCKED_BOOT_COMPLETED मैसेज ब्रॉडकास्ट होने के बाद, डिवाइस को सीधे बूट करने की सुविधा वाले ऐप्लिकेशन को डिवाइस को एन्क्रिप्ट (DE) करने वाले स्टोरेज को ऐक्सेस करने की अनुमति देनी चाहिए.
• [C-1-2] उपयोगकर्ता के डिवाइस को अनलॉक करने के बाद ही, क्रेडेंशियल एन्क्रिप्ट (सीई) स्टोरेज को ऐक्सेस करने की अनुमति दी जानी चाहिए. इसके लिए, उपयोगकर्ता को अपने क्रेडेंशियल (जैसे, पासकोड, पिन, पैटर्न या फ़िंगरप्रिंट) डालने होंगे. साथ ही, ACTION_USER_UNLOCKED मैसेज ब्रॉडकास्ट किया जाना चाहिए.
• [C-1-13] उपयोगकर्ता से मिले क्रेडेंशियल, रजिस्टर की गई एस्क्रो पासकोड या सेक्शन 9.9.4 में बताई गई ज़रूरी शर्तों के मुताबिक, रीबूट करने पर फिर से शुरू होने की सुविधा के बिना, सीई से सुरक्षित स्टोरेज को अनलॉक करने का कोई तरीका नहीं दिया जाना चाहिए.
• [C-1-4] वेरिफ़ाइड बूट का इस्तेमाल करना ज़रूरी है.

9.9.3.1. मेटाडेटा एन्क्रिप्शन के साथ फ़ाइल के आधार पर एन्क्रिप्शन

अगर डिवाइस पर, मेटाडेटा एन्क्रिप्शन के साथ फ़ाइल के आधार पर एन्क्रिप्शन (सुरक्षित) करने का तरीका इस्तेमाल किया जाता है, तो:

• [C-1-5] फ़ाइल के कॉन्टेंट और फ़ाइल सिस्टम के मेटाडेटा को एईएस-256-एक्सटीएस या एडिएंटम का इस्तेमाल करके एन्क्रिप्ट करना ज़रूरी है. AES-256-XTS, ऐडवांस एन्क्रिप्शन स्टैंडर्ड का ही एक वर्शन है. इसमें 256-बिट साइफ़र कुंजी का इस्तेमाल किया जाता है. यह कुंजी, XTS मोड में काम करती है. इस कुंजी की पूरी लंबाई 512 बिट होती है. Adiantum का मतलब Adiantum-XChaCha12-AES से है, जैसा कि https://github.com/google/adiantum पर बताया गया है. फ़ाइल सिस्टम का मेटाडेटा, फ़ाइल के साइज़, मालिकाना हक, मोड, और एक्सटेंडेड एट्रिब्यूट (xattrs) जैसे डेटा से मिलकर बनता है.
• [C-1-6] फ़ाइल के नामों को AES-256-CBC-CTS, AES-256-HCTR2 या Adiantum का इस्तेमाल करके एन्क्रिप्ट करना ज़रूरी है.
• [C-1-12] अगर डिवाइस में Advanced Encryption Standard (AES) के निर्देश (जैसे कि ARM पर आधारित डिवाइसों पर ARMv8 क्रिप्टोग्राफ़ी एक्सटेंशन या x86 पर आधारित डिवाइसों पर AES-NI) हैं, तो फ़ाइल के नाम, फ़ाइल के कॉन्टेंट, और फ़ाइल सिस्टम के मेटाडेटा को एन्क्रिप्ट करने के लिए, ऊपर दिए गए AES-आधारित विकल्पों का इस्तेमाल करना ज़रूरी है, न कि Adiantum का.
• [C-1-13] सीई और डीई पासकोड से ज़रूरी सब-पासकोड (जैसे, हर फ़ाइल के लिए पासकोड) पाने के लिए, क्रिप्टोग्राफ़िक तरीके से सुरक्षित और रिवर्स नहीं की जा सकने वाली पासकोड जनरेशन की सुविधा (जैसे, HKDF-SHA512) का इस्तेमाल करना ज़रूरी है. "एन्क्रिप्शन के लिहाज़ से मज़बूत और उलटाया नहीं जा सकने वाला" का मतलब है कि पासकोड बनाने वाले फ़ंक्शन की सुरक्षा कम से कम 256 बिट की है. साथ ही, यह अपने इनपुट के लिए स्यूडोरैंडम फ़ंक्शन फ़ैमिली के तौर पर काम करता है.
• [C-1-14] अलग-अलग क्रिप्टोग्राफ़िक कामों के लिए, एक ही फ़ाइल पर आधारित एन्क्रिप्शन (एफ़बीई) कुंजियों या सब-कुंजियों का इस्तेमाल नहीं किया जाना चाहिए. जैसे, एन्क्रिप्शन और कुंजी बनाने के लिए या दो अलग-अलग एन्क्रिप्शन एल्गोरिदम के लिए.
• [C-1-15] यह पक्का करना ज़रूरी है कि हमेशा सेव रहने वाले स्टोरेज में, एन्क्रिप्ट (सुरक्षित) की गई फ़ाइल के कॉन्टेंट के उन ब्लॉक को मिटाया न गया हो जिन्हें एन्क्रिप्ट करने के लिए, एन्क्रिप्शन कुंजी और शुरू करने वाले वेक्टर (IV) के कॉम्बिनेशन का इस्तेमाल किया गया था. ये कॉम्बिनेशन, फ़ाइल और फ़ाइल में मौजूद ऑफ़सेट, दोनों पर निर्भर करते हैं. इसके अलावा, ऐसे सभी कॉम्बिनेशन अलग-अलग होने चाहिए. हालांकि, इनलाइन एन्क्रिप्शन हार्डवेयर का इस्तेमाल करके एन्क्रिप्ट करने पर ऐसा ज़रूरी नहीं है. यह हार्डवेयर सिर्फ़ 32 बिट के आईवी के साथ काम करता है.
• [C-1-16] यह पक्का करना ज़रूरी है कि अलग-अलग डायरेक्ट्री में मौजूद, हमेशा सेव रहने वाले स्टोरेज में मौजूद, एन्क्रिप्ट की गई सभी फ़ाइलों के नाम, एन्क्रिप्शन कुंजी और इनिशलाइज़ेशन वेक्टर (IV) के अलग-अलग कॉम्बिनेशन का इस्तेमाल करके एन्क्रिप्ट किए गए हों.

• [C-1-17] यह पक्का करना ज़रूरी है कि स्टोरेज में मौजूद फ़ाइल सिस्टम के सभी एन्क्रिप्ट किए गए मेटाडेटा ब्लॉक, एन्क्रिप्शन पासकोड और इनिशलाइज़ेशन वेक्टर (IV) के अलग-अलग कॉम्बिनेशन का इस्तेमाल करके एन्क्रिप्ट किए गए हों.

• सीई और डीई स्टोरेज एरिया और फ़ाइल सिस्टम मेटाडेटा को सुरक्षित रखने वाली कुंजियां:

  • [C-1-7] यह ज़रूरी है कि इसे क्रिप्टोग्राफ़िक तरीके से, हार्डवेयर के साथ काम करने वाले पासकोड स्टोर से जोड़ा गया हो. यह कीस्टोर, पुष्टि किए गए बूट और डिवाइस के हार्डवेयर के ट्रस्ट रूट से बंधा होना चाहिए.
  • [C-1-8] सीई पासकोड, उपयोगकर्ता की लॉक स्क्रीन के क्रेडेंशियल से बंधे होने चाहिए.
  • [C-1-9] अगर उपयोगकर्ता ने लॉक स्क्रीन के क्रेडेंशियल नहीं दिए हैं, तो सीई पासकोड को डिफ़ॉल्ट पासकोड से बंधा होना चाहिए.
  • [C-1-10] यह यूनीक और अलग-अलग होना चाहिए. दूसरे शब्दों में, किसी भी उपयोगकर्ता की सीई या डीई कुंजी, किसी दूसरे उपयोगकर्ता की सीई या डीई कुंजी से मेल नहीं खाती.
  • [C-1-11] ज़रूरी सिफर, कुंजी की लंबाई, और तरीकों का इस्तेमाल करना ज़रूरी है.
  • [C-1-12] बूटलोडर को अनलॉक और लॉक करने के दौरान, इसे सुरक्षित तरीके से मिटाना ज़रूरी है. इसके लिए, यहां दिया गया तरीका अपनाएं.

• पहले से इंस्टॉल किए गए ज़रूरी ऐप्लिकेशन (जैसे, अलार्म, फ़ोन, Messenger) को डायरेक्ट बूट के बारे में जानकारी देनी चाहिए.

अपस्ट्रीम Android Open Source प्रोजेक्ट, Linux kernel "fscrypt" एन्क्रिप्शन की सुविधा के आधार पर, फ़ाइल के आधार पर एन्क्रिप्शन को लागू करने का सुझाव देता है. साथ ही, Linux kernel "dm-default-key" सुविधा के आधार पर, मेटाडेटा एन्क्रिप्शन को लागू करने का सुझाव देता है.

ध्यान दें: एपीआई लेवल 28 या उससे पहले के वर्शन पर शिप किए गए डिवाइसों को, सिस्टम सॉफ़्टवेयर अपडेट की मदद से 9.9.3 में बताई गई ज़रूरी शर्तें पूरी करनी होंगी. इसके लिए, डिवाइस को उस एपीआई लेवल के हिसाब से, Android के साथ काम करने की जानकारी देने वाले दस्तावेज़ के सेक्शन 9.9 में बताई गई ज़रूरी शर्तें पूरी करनी होंगी जिस पर डिवाइस शिप किया गया था.

9.9.3.2. हर उपयोगकर्ता के लिए ब्लॉक-लेवल एन्क्रिप्शन

अगर डिवाइस पर लागू किए गए एन्क्रिप्शन में, हर उपयोगकर्ता के लिए ब्लॉक-लेवल एन्क्रिप्शन का इस्तेमाल किया जाता है, तो:

• [C-1-1] सेक्शन 9.5 में बताए गए तरीके से, एक से ज़्यादा उपयोगकर्ताओं के लिए सहायता की सुविधा चालू करना ज़रूरी है.
• [C-1-2] हर उपयोगकर्ता के लिए, रॉ पार्टिशन या लॉजिकल वॉल्यूम का इस्तेमाल करके, पार्टिशन उपलब्ध कराना ज़रूरी है.
• [C-1-3] ब्लॉक डिवाइसों को एन्क्रिप्ट (सुरक्षित) करने के लिए, हर उपयोगकर्ता के लिए यूनीक और अलग-अलग एन्क्रिप्शन पासकोड का इस्तेमाल करना ज़रूरी है.

• [C-1-4] उपयोगकर्ता के partition को ब्लॉक-लेवल पर एन्क्रिप्ट करने के लिए, AES-256-XTS का इस्तेमाल करना ज़रूरी है.

• हर उपयोगकर्ता के लिए, एन्क्रिप्ट किए गए डिवाइसों को ब्लॉक-लेवल पर सुरक्षित रखने वाली कुंजियां:

  • [C-1-5] इसे क्रिप्टोग्राफ़िक तरीके से, हार्डवेयर के साथ काम करने वाले पासकोड स्टोर से जोड़ा जाना चाहिए. यह कीस्टोर, पुष्टि किए गए बूट और डिवाइस के हार्डवेयर के ट्रस्ट रूट से बंधा होना चाहिए.
  • [C-1-6] यह ज़रूरी है कि यह पासवर्ड, उस उपयोगकर्ता की लॉक स्क्रीन के क्रेडेंशियल से जुड़ा हो.

हर उपयोगकर्ता के लिए, ब्लॉक-लेवल पर एन्क्रिप्शन लागू किया जा सकता है. इसके लिए, हर उपयोगकर्ता के लिए बने पार्टीशन पर, Linux kernel की "dm-crypt" सुविधा का इस्तेमाल किया जा सकता है.

9.9.4. रीबूट होने पर फिर से शुरू करना

'रिबूट होने पर फिर से शुरू करें' सुविधा की मदद से, ओटीए से रिबूट करने के बाद, सभी ऐप्लिकेशन के सीई स्टोरेज को अनलॉक किया जा सकता है. इनमें वे ऐप्लिकेशन भी शामिल हैं जो अब तक डायरेक्ट बूट की सुविधा के साथ काम नहीं करते. इस सुविधा की मदद से, उपयोगकर्ताओं को रीबूट करने के बाद, इंस्टॉल किए गए ऐप्लिकेशन से सूचनाएं मिलती हैं.

'रिबूट होने पर फिर से शुरू करें' सुविधा को लागू करने के बाद भी यह पक्का करना ज़रूरी है कि जब कोई डिवाइस, हमलावर के हाथों में पड़ जाए, तो वह उपयोगकर्ता के सीई से एन्क्रिप्ट किए गए डेटा को वापस पाने में काफ़ी मुश्किल हो. भले ही, डिवाइस चालू हो, सीई स्टोरेज अनलॉक हो, और उपयोगकर्ता ने ओटीए मिलने के बाद डिवाइस अनलॉक कर लिया हो. हम यह भी मानते हैं कि अंदरूनी हमले से बचने के लिए, हैकर को क्रिप्टोग्राफ़िक साइनिंग पासकोड ब्रॉडकास्ट करने का ऐक्सेस मिल गया है.

खास तौर से:

• [C-0-1] सीई स्टोरेज को हमलावर भी नहीं पढ़ सकता. भले ही, उसके पास डिवाइस हो. साथ ही, उसके पास ये सुविधाएं और सीमाएं होनी चाहिए:

  • किसी भी वेंडर या कंपनी की साइनिंग पासकोड का इस्तेमाल करके, मनमुताबिक मैसेज साइन किए जा सकते हैं.
  • इसकी वजह से, डिवाइस पर ओटीए (Over-The-Air) अपडेट मिल सकता है.
  • नीचे बताए गए एपी, फ़्लैश वगैरह के अलावा, किसी भी हार्डवेयर के काम करने के तरीके में बदलाव किया जा सकता है. हालांकि, ऐसा करने में कम से कम एक घंटे का समय लगता है. साथ ही, इसमें पावर साइकल भी शामिल होता है, जिससे रैम का कॉन्टेंट खत्म हो जाता है.
  • छेड़छाड़ से सुरक्षित हार्डवेयर (जैसे, Titan M) के काम करने के तरीके में बदलाव नहीं किया जा सकता.
  • लाइव डिवाइस की रैम को पढ़ा नहीं जा सका.
  • उपयोगकर्ता का क्रेडेंशियल (पिन, पैटर्न, पासवर्ड) हासिल नहीं किया जा सकता या उसे डालने के लिए कहा जा सकता है.

उदाहरण के लिए, यहां दी गई सभी जानकारी को लागू करने वाला डिवाइस, [C-0-1] का पालन करेगा.

9.10. डिवाइस इंटिग्रिटी

यहां दी गई ज़रूरी शर्तों से यह पक्का होता है कि डिवाइस के पूरी तरह से सुरक्षित होने की स्थिति के बारे में साफ़ तौर पर जानकारी दी गई हो. डिवाइस पर लागू करने के तरीके:

• [C-0-1] सिस्टम एपीआई के तरीके से, PersistentDataBlockManager.getFlashLockState() को सही तरीके से यह बताना चाहिए कि उनके बूटलोडर की स्थिति, सिस्टम इमेज को फ़्लैश करने की अनुमति देती है या नहीं.

• [C-0-2] डिवाइस इंटिग्रिटी के लिए, पुष्टि किए गए बूट मोड की सुविधा ज़रूर होनी चाहिए.

अगर डिवाइस पहले ही Android के किसी पुराने वर्शन पर लॉन्च हो चुके हैं और सिस्टम सॉफ़्टवेयर अपडेट की मदद से, पुष्टि करने की सुविधा को जोड़ा नहीं जा सकता, तो हो सकता है कि उन्हें इस ज़रूरी शर्त से छूट दी जाए.

वेरिफ़ाइड बूट की सुविधा, डिवाइस के सॉफ़्टवेयर की सुरक्षा की गारंटी देती है. अगर डिवाइस पर यह सुविधा काम करती है, तो:

• [C-1-1] प्लैटफ़ॉर्म की सुविधा के फ़्लैग के बारे में एलान करना ज़रूरी है android.software.verified_boot.
• [C-1-2] हर बूट सीक्वेंस पर पुष्टि करना ज़रूरी है.
• [C-1-3] पुष्टि की प्रोसेस, बदलाव न की जा सकने वाली हार्डवेयर कुंजी से शुरू होनी चाहिए. यह कुंजी, ट्रस्ट की जड़ होती है और सिस्टम के सभी हिस्सों तक जाती है.
• [C-1-4] अगले चरण में कोड को लागू करने से पहले, सभी बाइट की पुष्टि करना ज़रूरी है. इससे, अगले चरण में बाइट की पूरी सुरक्षा और पुष्टि की जा सकेगी.
• [C-1-5] पुष्टि करने के लिए, ऐसे एल्गोरिदम का इस्तेमाल करना ज़रूरी है जो हैशिंग एल्गोरिदम (SHA-256) और सार्वजनिक कुंजी के साइज़ (आरएसए-2048) के लिए, एनआईएसटी के मौजूदा सुझावों के मुताबिक हों.
• [C-1-6] सिस्टम की पुष्टि न होने पर, डिवाइस को बूट होने की अनुमति नहीं दी जानी चाहिए. ऐसा तब तक नहीं किया जाना चाहिए, जब तक उपयोगकर्ता बूट करने की कोशिश करने की सहमति न दे. ऐसे में, पुष्टि न किए गए किसी भी स्टोरेज ब्लॉक के डेटा का इस्तेमाल नहीं किया जाना चाहिए.
• [C-1-7] डिवाइस पर पुष्टि किए गए पार्टीशन में बदलाव करने की अनुमति नहीं दी जानी चाहिए, जब तक कि उपयोगकर्ता ने साफ़ तौर पर बूटलोडर को अनलॉक न किया हो.
• [C-SR-1] अगर डिवाइस में एक से ज़्यादा डिसक्रेट चिप (जैसे, रेडियो, विशेष इमेज प्रोसेसर) हैं, तो हमारा सुझाव है कि बूट करने के दौरान हर चरण की पुष्टि की जाए.
• [C-1-8] टेंपर-एविडेंस स्टोरेज का इस्तेमाल करना ज़रूरी है: यह सेव करने के लिए कि bootloader अनलॉक है या नहीं. टेंपर-एविडेंस स्टोरेज का मतलब है कि बूटलोडर यह पता लगा सकता है कि Android में स्टोरेज में छेड़छाड़ की गई है या नहीं.
• [C-1-9] डिवाइस का इस्तेमाल करते समय, उपयोगकर्ता को ज़रूर सूचना देनी चाहिए. साथ ही, बूटलोडर के लॉक मोड से अनलॉक मोड पर स्विच करने से पहले, उपयोगकर्ता से पुष्टि करने के लिए कहा जाना चाहिए.
• [C-1-10] Android के इस्तेमाल किए जाने वाले पार्टिशन (जैसे, बूट, सिस्टम पार्टिशन) के लिए, रोलबैक सुरक्षा लागू करना ज़रूरी है. साथ ही, इस्तेमाल किए जा सकने वाले कम से कम OS वर्शन का पता लगाने के लिए इस्तेमाल किए जाने वाले मेटाडेटा को सेव करने के लिए, बदलाव किए जाने से बचाने वाले स्टोरेज का इस्तेमाल करना ज़रूरी है.
• [C-1-11] '9.12' के मुताबिक, बूटलोडर को अनलॉक और लॉक करने के दौरान, उपयोगकर्ता का सारा डेटा सुरक्षित तरीके से मिटाना ज़रूरी है. डेटा मिटाने की सुविधा' (इसमें उपयोगकर्ता डेटा का पार्टीशन और कोई भी एनवीआरएएम स्पेस शामिल है).
• [C-SR-2] हमारा सुझाव है कि आप ऐप्लिकेशन के उन सभी APK फ़ाइलों की पुष्टि करें जिनके पास खास सुविधाएं हैं. इसके लिए, वेरिफ़ाइड बूट की प्रोसेस से सुरक्षित किए गए पार्टीशन में मौजूद, भरोसे की चेन का इस्तेमाल करें.
• [C-SR-3] हमारा सुझाव है कि किसी भी एक्ज़ीक्यूटेबल आर्टफ़ैक्ट को चलाने से पहले, उसकी पुष्टि कर लें. ऐसा, ऐप्लिकेशन के APK फ़ाइल के बाहर से, ऐप्लिकेशन को विशेष सुविधाएं देने वाले ऐप्लिकेशन से लोड किए गए आर्टफ़ैक्ट के लिए किया जाना चाहिए. जैसे, डाइनैमिक तौर पर लोड किया गया कोड या संकलित किया गया कोड. हमारा सुझाव है कि इन आर्टफ़ैक्ट को बिलकुल भी न चलाएं.
• ऐसे किसी भी कॉम्पोनेंट के लिए रोलबैक सुरक्षा लागू की जानी चाहिए जिसमें हमेशा चालू रहने वाला फ़र्मवेयर (जैसे, मॉडेम, कैमरा) हो. साथ ही, अनुमति वाले कम से कम वर्शन का पता लगाने के लिए इस्तेमाल किए जाने वाले मेटाडेटा को सेव करने के लिए, बदलाव होने से बचाने वाले स्टोरेज का इस्तेमाल किया जाना चाहिए.

अगर डिवाइस को Android के पुराने वर्शन पर, C-1-8 से C-1-11 तक की शर्तों के बिना पहले ही लॉन्च किया जा चुका है और सिस्टम सॉफ़्टवेयर अपडेट की मदद से, इन शर्तों के लिए सहायता नहीं जोड़ी जा सकती, तो हो सकता है कि उन्हें इन शर्तों से छूट दी जाए.

अपस्ट्रीम Android Open Source Project, external/avb/ रिपॉज़िटरी में इस सुविधा को लागू करने का सुझाव देता है. इसे Android को लोड करने के लिए इस्तेमाल किए जाने वाले बूटलोडर में इंटिग्रेट किया जा सकता है.

डिवाइस पर लागू करने का तरीका

अगर डिवाइस पर लागू किए गए टूल, हर पेज के हिसाब से फ़ाइल के कॉन्टेंट की पुष्टि कर सकते हैं, तो वे:

• [C-0-3 C-2-1] की मदद से, पूरी फ़ाइल को पढ़े बिना, भरोसेमंद कुंजी के आधार पर फ़ाइल के कॉन्टेंट की क्रिप्टोग्राफ़िक तरीके से पुष्टि की जा सकती है.

• [C-0-4 C-2-2] को, सुरक्षित फ़ाइल को पढ़ने के अनुरोधों को तब पूरा नहीं करना चाहिए, जब पढ़ा गया कॉन्टेंट भरोसेमंद पासकोड से पुष्टि न करता हो और ऊपर [C-2-1] के मुताबिक उसकी पुष्टि न की गई हो.

नई ज़रूरी शर्तें लागू करना

• [C-2-4] चालू की गई फ़ाइलों के लिए, फ़ाइल का चेकसम O(1) में दिखाना ज़रूरी है.

नई ज़रूरी शर्तें खत्म करना

अगर डिवाइस में पहले से ही, Android के पुराने वर्शन पर किसी भरोसेमंद कुंजी की मदद से फ़ाइल के कॉन्टेंट की पुष्टि करने की सुविधा उपलब्ध नहीं है और सिस्टम सॉफ़्टवेयर के अपडेट की मदद से, इस सुविधा को जोड़ा नहीं जा सकता, तो हो सकता है कि डिवाइस को इस ज़रूरी शर्त से छूट दी जाए. अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट, Linux kernel fs-verity सुविधा के आधार पर, इस सुविधा को लागू करने का सुझाव देता है.

डिवाइस पर लागू करने के तरीके:

• [C-SR-4] हमारा सुझाव है कि आप Android Protected Confirmation API का इस्तेमाल करें.

अगर डिवाइस पर Android Protected Confirmation API काम करता है, तो:

• [C-3-1] ConfirmationPrompt.isSupported() एपीआई के लिए, true की रिपोर्ट करना ज़रूरी है.

• [C-3-2] यह पक्का करना ज़रूरी है कि Android OS में चलने वाला कोड, उपयोगकर्ता के इंटरैक्शन के बिना कोई रिस्पॉन्स जनरेट न कर सके. इसमें, कोड का कर्नेल भी शामिल है. भले ही, वह कोड नुकसान पहुंचाने वाला हो या कोई और.

• [C-3-3] यह पक्का करना ज़रूरी है कि उपयोगकर्ता ने मैसेज की समीक्षा करके, उसे अनुमति दी हो. भले ही, Android OS और उसके कर्नेल को हैक कर लिया गया हो.

9.11. कुंजियां और क्रेडेंशियल

Android Keystore System की मदद से, ऐप्लिकेशन डेवलपर किसी कंटेनर में क्रिप्टोग्राफ़िक पासकोड सेव कर सकते हैं. साथ ही, KeyChain API या Keystore API की मदद से, क्रिप्टोग्राफ़िक ऑपरेशन में उनका इस्तेमाल कर सकते हैं. डिवाइस पर लागू करने के तरीके:

• [C-0-1] कम से कम 8,192 कुंजियों को इंपोर्ट या जनरेट करने की अनुमति होनी चाहिए.
• [C-0-2] लॉक स्क्रीन की पुष्टि करने की कोशिशें पूरी न होने पर, फिर से कोशिश करने के लिए एक समयावधि तय की जानी चाहिए. अगर n को असफल कोशिशों की संख्या माना जाए, तो 9 < n < 30 के लिए, समय अंतराल कम से कम 30 सेकंड होना चाहिए. अगर n > 29 है, तो समय इंटरवल की वैल्यू कम से कम 30*2^floor((n-30)/10)) सेकंड या कम से कम 24 घंटे होनी चाहिए.
• जनरेट की जा सकने वाली कुंजियों की संख्या को सीमित नहीं करना चाहिए

नई ज़रूरी शर्तें लागू करना

• [C-0-3] पुष्टि करने के लिए, मुख्य तरीके से की गई कोशिशों की संख्या को सीमित करना ज़रूरी है.
• [C-SR-2] हमारा सुझाव है कि पुष्टि करने के लिए, मुख्य तरीके से 20 बार कोशिश करने की सीमा तय करें. अगर उपयोगकर्ता इस सुविधा के लिए सहमति देते हैं और ऑप्ट-इन करते हैं, तो पुष्टि करने के लिए, मुख्य तरीके से 20 बार कोशिश करने की सीमा पार करने के बाद, "फ़ैक्ट्री डेटा रीसेट" करें.

अगर डिवाइस में लॉक स्क्रीन को अनलॉक करने के लिए, पुष्टि करने के तरीकों को जोड़ा जाता है या उनमें बदलाव किया जाता है, तो यह ज़रूरी है कि वे किसी ऐसे गुप्त पासवर्ड पर आधारित हों जिसकी जानकारी पहले से हो. साथ ही, स्क्रीन को लॉक करने के सुरक्षित तरीके के तौर पर इस्तेमाल किए जाने वाले नए पुष्टि करने के तरीके का इस्तेमाल किया जाता हो. इसके लिए:

• [C-SR-3] हमारा सुझाव है कि पिन कम से कम छह अंकों का हो या फिर 20-बिट एन्ट्रॉपी वाला हो.
• [C-2-1] छह अंकों से कम का पिन, उपयोगकर्ता के इंटरैक्शन के बिना अपने-आप नहीं डाला जाना चाहिए. ऐसा इसलिए, ताकि पिन की लंबाई ज़ाहिर न हो.

नई ज़रूरी शर्तें खत्म करना

जब डिवाइस पर सुरक्षित लॉक स्क्रीन की सुविधा काम करती है, तो:

• [C-1-1] अलग सेट अप किए गए प्रोग्राम के ज़रिए, पासकोड को लागू करने के लिए, पासकोड का बैक अप लेना ज़रूरी है.
• [C-1-2] इसमें आरएसए, एईएस, ईसीडीएसए, ईसीडीएच (अगर IKeyMintDevice काम करता है), 3डीईएस, और एचएमएसी क्रिप्टोग्राफ़िक एल्गोरिदम और MD5, SHA1, और SHA-2 फ़ैमिली हैश फ़ंक्शन लागू होने चाहिए. इससे, Android Keystore सिस्टम के काम करने वाले एल्गोरिदम को ठीक से काम करने में मदद मिलती है. यह एल्गोरिदम, कोर और उसके बाद के लेवल पर चलने वाले कोड से सुरक्षित तौर पर अलग होता है. सुरक्षित आइसोलेशन की सुविधा, उन सभी संभावित तरीकों को ब्लॉक करनी चाहिए जिनकी मदद से कर्नेल या यूज़रस्पेस कोड, डीएमए के साथ-साथ आइसोलेट किए गए एनवायरमेंट की इंटरनल स्टेटस को ऐक्सेस कर सकता है. अपस्ट्रीम Android Open Source Project (AOSP), Trusty को लागू करके इस ज़रूरी शर्त को पूरा करता है. हालांकि, ARM TrustZone पर आधारित कोई दूसरा समाधान या तीसरे पक्ष की समीक्षा के बाद, हाइपरवाइजर पर आधारित सही आइसोलेशन को सुरक्षित तरीके से लागू करना, इसके विकल्प हैं.
• [C-1-3] लॉक स्क्रीन की पुष्टि, अलग से चलाए जाने वाले प्रोग्राम में करनी चाहिए. पुष्टि होने के बाद ही, पुष्टि करने के लिए इस्तेमाल की जाने वाली कुंजियों का इस्तेमाल करने की अनुमति दें. लॉक स्क्रीन के क्रेडेंशियल को इस तरह से सेव करना ज़रूरी है कि सिर्फ़ अलग-अलग इकोसिस्टम में काम करने वाले ऐप्लिकेशन, लॉक स्क्रीन की पुष्टि कर सकें. अपस्ट्रीम Android Open Source Project, Gatekeeper Hardware Abstraction Layer (HAL) और Trusty उपलब्ध कराता है. इनका इस्तेमाल, इस ज़रूरी शर्त को पूरा करने के लिए किया जा सकता है.
• [C-1-4] यह ज़रूरी है कि कुंजी की पुष्टि करने की सुविधा काम करे. इसमें, पुष्टि करने के लिए इस्तेमाल होने वाली साइनिंग कुंजी को सुरक्षित हार्डवेयर से सुरक्षित किया गया हो और साइनिंग की प्रोसेस, सुरक्षित हार्डवेयर में की गई हो. पुष्टि करने के लिए इस्तेमाल होने वाली साइनिंग पासकोड को ज़रूर ज़्यादा से ज़्यादा डिवाइसों के साथ शेयर किया जाना चाहिए, ताकि इनका इस्तेमाल डिवाइस आइडेंटिफ़ायर के तौर पर न किया जा सके. इस ज़रूरी शर्त को पूरा करने का एक तरीका यह है कि एक ही पुष्टि करने वाली कुंजी तब तक शेयर की जाए, जब तक किसी दिए गए SKU की कम से कम 1,00,000 यूनिट तैयार न हो जाएं. अगर किसी SKU की 1,00,000 से ज़्यादा यूनिट बनाई जाती हैं, तो हर 1,00,000 यूनिट के लिए अलग-अलग कुंजी का इस्तेमाल किया जा सकता है.

ध्यान दें कि अगर किसी डिवाइस पर, Android के किसी पुराने वर्शन में पहले से ही एन्क्रिप्शन लागू है, तो उस डिवाइस को अलग से एन्क्रिप्शन करने वाले एनवायरमेंट के साथ काम करने वाले पासकोड सेव करने की सुविधा और पासकोड की पुष्टि करने की सुविधा का इस्तेमाल करने की ज़रूरत नहीं होती. हालांकि, ऐसा तब तक नहीं किया जा सकता, जब तक डिवाइस में android.hardware.fingerprint सुविधा का इस्तेमाल नहीं किया जाता. इस सुविधा के लिए, अलग से एन्क्रिप्शन करने वाले एनवायरमेंट के साथ काम करने वाले पासकोड सेव करने की सुविधा और पासकोड की पुष्टि करने की सुविधा का इस्तेमाल करना ज़रूरी होता है.

• [C-1-5] डिवाइस को अनलॉक किए जाने से लेकर लॉक होने तक के ट्रांज़िशन के लिए, उपयोगकर्ता को स्लीप मोड का टाइम आउट चुनने की अनुमति होनी चाहिए. टाइम आउट की कम से कम अवधि 15 सेकंड होनी चाहिए. वाहन से जुड़े ऐसे डिवाइसों में स्लीप टाइम आउट कॉन्फ़िगरेशन नहीं हो सकता जो हेड यूनिट बंद होने या उपयोगकर्ता के स्विच होने पर स्क्रीन को लॉक कर देते हैं.
• [C-1-6] यह इनमें से किसी एक के साथ काम करना चाहिए:
  • IKeymasterDevice 3.0,
  • IKeymasterDevice 4.0,
  • IKeymasterDevice 4.1,
  • IKeyMintDevice का वर्शन 1 या
  • IKeyMintDevice का वर्शन 2.
• [C-SR-1] हमारा सुझाव है कि आप IKeyMintDevice के वर्शन 1 का इस्तेमाल करें.

9.11.1. लॉक स्क्रीन, पुष्टि करने की सुविधा, और वर्चुअल डिवाइसों को सुरक्षित करना

AOSP को लागू करने के लिए, अलग-अलग लेवल वाले ऑथेंटिकेशन मॉडल का इस्तेमाल किया जाता है. इसमें, नॉलेज फ़ैक्ट्री पर आधारित मुख्य ऑथेंटिकेशन को, सेकंडरी लेवल पर किसी बेहतर बायोमेट्रिक या तीसरे लेवल पर किसी कम बेहतर मोडैलिटी से पुष्टि की जा सकती है.

डिवाइस पर लागू करने के तरीके:

• [C-SR-1] हमारा सुझाव है कि पुष्टि करने के लिए, इनमें से किसी एक को मुख्य तरीके के तौर पर सेट करें:

  • अंकों वाला पिन
  • अक्षर और अंकों वाला पासवर्ड

  • 3x3 बिंदुओं के ग्रिड पर स्वाइप पैटर्न

    ध्यान दें कि पुष्टि करने के ऊपर बताए गए तरीकों को, इस दस्तावेज़ में पुष्टि करने के मुख्य तरीकों के तौर पर सुझाया गया है.

नई ज़रूरी शर्तें लागू करना

• [C-0-1] पुष्टि करने के लिए, मुख्य तरीके से की गई कोशिशों की संख्या को सीमित करना ज़रूरी है.
• [C-SR-5] हमारा सुझाव है कि पुष्टि करने के लिए, मुख्य तरीके से 20 बार कोशिश करने की सीमा तय की जाए. अगर उपयोगकर्ता इस सुविधा के लिए सहमति देते हैं और इसमें ऑप्ट-इन करते हैं, तो पुष्टि करने के लिए, मुख्य तरीके से 20 बार कोशिश करने की सीमा पार करने के बाद, "फ़ैक्ट्री डेटा रीसेट" करें.

अगर डिवाइस पर पुष्टि करने के मुख्य तरीके के तौर पर, अंकों वाला पिन सेट किया जाता है, तो:

• [C-SR-6] हमारा सुझाव है कि पिन कम से कम छह अंकों का हो या फिर 20-बिट एन्ट्रॉपी वाला हो.
• [C-SR-7] हमारा सुझाव है कि छह से कम अंकों वाले पिन को, उपयोगकर्ता के इंटरैक्शन के बिना अपने-आप डालने की अनुमति न दें. इससे पिन की लंबाई ज़ाहिर नहीं होगी.

नई ज़रूरी शर्तें खत्म करना

अगर डिवाइस में पुष्टि करने के सुझाए गए मुख्य तरीकों को जोड़ा जाता है या उनमें बदलाव किया जाता है और स्क्रीन को लॉक करने के सुरक्षित तरीके के तौर पर पुष्टि करने के किसी नए तरीके का इस्तेमाल किया जाता है, तो पुष्टि करने का नया तरीका:

• [C-2-1] यह पुष्टि करने का ऐसा तरीका होना चाहिए जैसा कि कुंजी के इस्तेमाल के लिए उपयोगकर्ता की पुष्टि करना ज़रूरी है में बताया गया है.

अगर डिवाइस में लॉक स्क्रीन को अनलॉक करने के लिए, पुष्टि करने के तरीकों को जोड़ा जाता है या उनमें बदलाव किया जाता है, तो यह ज़रूरी है कि वे किसी ऐसे गुप्त पासवर्ड पर आधारित हों जिसकी जानकारी पहले से हो. साथ ही, पुष्टि करने के नए तरीके का इस्तेमाल, स्क्रीन को लॉक करने के सुरक्षित तरीके के तौर पर किया जाना चाहिए:

• [C-3-1] इनपुट की कम से कम अनुमति वाली लंबाई का एन्ट्रापी, 10 बिट से ज़्यादा होना चाहिए.
• [C-3-2] सभी संभावित इनपुट की ज़्यादा से ज़्यादा एन्ट्रापी, 18 बिट से ज़्यादा होनी चाहिए.
• [C-3-3] पुष्टि करने का नया तरीका, AOSP में लागू और दिए गए, पुष्टि करने के सुझाए गए मुख्य तरीकों (जैसे, पिन, पैटर्न, पासवर्ड) को बदलना चाहिए.
• [C-3-4] अगर डिवाइस नीति कंट्रोलर (डीपीसी) ऐप्लिकेशन ने DevicePolicyManager.setRequiredPasswordComplexity() के ज़रिए, पासवर्ड की ज़रूरी शर्तों की नीति को PASSWORD_COMPLEXITY_NONE से ज़्यादा पाबंदी वाले कॉन्स्टेंट के साथ सेट किया है या DevicePolicyManager.setPasswordQuality() के ज़रिए, PASSWORD_QUALITY_BIOMETRIC_WEAK से ज़्यादा पाबंदी वाले कॉन्स्टेंट के साथ सेट किया है, तो पुष्टि करने का नया तरीका बंद होना चाहिए.
• [C-3-5] पुष्टि करने के नए तरीकों को हर 72 घंटे या उससे कम समय में, पुष्टि करने के सुझाए गए मुख्य तरीकों (जैसे, पिन, पैटर्न, पासवर्ड) पर स्विच करना होगा. इसके अलावा, उपयोगकर्ता को साफ़ तौर पर यह बताना होगा कि उनके डेटा की निजता बनाए रखने के लिए, कुछ डेटा का बैक अप नहीं लिया जाएगा.

अगर डिवाइस में लॉक स्क्रीन को अनलॉक करने के लिए, पुष्टि करने के सुझाए गए मुख्य तरीकों में बदलाव किया जाता है या उन्हें जोड़ा जाता है और स्क्रीन को लॉक करने के सुरक्षित तरीके के तौर पर, बायोमेट्रिक्स पर आधारित पुष्टि करने के नए तरीके का इस्तेमाल किया जाता है, तो नए तरीके के लिए:

• [C-4-1] क्लास 1 (पहले इसे सुविधा कहा जाता था) के लिए, सेक्शन 7.3.10 में बताई गई सभी ज़रूरी शर्तें पूरी करनी चाहिए.
• [C-4-2] पुष्टि करने के लिए सुझाए गए किसी मुख्य तरीके का इस्तेमाल करने के लिए, आपके पास फ़ॉल-बैक मैकेनिज्म होना चाहिए. यह तरीका, किसी ऐसे गुप्त पासवर्ड पर आधारित होना चाहिए जिसकी जानकारी आपके पास हो.
• [C-4-3] इसे बंद करना ज़रूरी है.साथ ही, स्क्रीन को अनलॉक करने के लिए, सिर्फ़ सुझाई गई मुख्य पुष्टि करने की सुविधा का इस्तेमाल करने की अनुमति देनी चाहिए. ऐसा तब किया जाना चाहिए, जब डिवाइस नीति कंट्रोलर (डीपीसी) ऐप्लिकेशन ने DevicePolicyManager.setKeyguardDisabledFeatures() के साथ किसी भी बायोमेट्रिक फ़्लैग (जैसे, KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE या KEYGUARD_DISABLE_IRIS) का इस्तेमाल करके, तरीका कॉल करके कीवर्ड की सुविधा की नीति सेट की हो.

अगर बायोमेट्रिक ऑथेंटिकेशन के तरीके, सेक्शन 7.3.10 में बताई गई तीसरी क्लास (पहले इसे बेहतर कहा जाता था) की ज़रूरी शर्तों को पूरा नहीं करते हैं, तो:

• [C-5-1] अगर डिवाइस नीति कंट्रोलर (डीपीसी) ऐप्लिकेशन ने PASSWORD_COMPLEXITY_LOW से ज़्यादा पाबंदी वाली जटिलता वाली बकेट के साथ DevicePolicyManager.setRequiredPasswordComplexity() के ज़रिए पासवर्ड की ज़रूरी शर्तों की क्वालिटी से जुड़ी नीति सेट की है या PASSWORD_QUALITY_BIOMETRIC_WEAK से ज़्यादा पाबंदी वाली क्वालिटी कॉन्स्टेंट के साथ DevicePolicyManager.setPasswordQuality() का इस्तेमाल किया है, तो इन तरीकों को बंद करना ज़रूरी है.
• [C-5-2] उपयोगकर्ता को पुष्टि करने के लिए, सुझाई गई मुख्य पुष्टि करने की सुविधा (जैसे: पिन, पैटर्न, पासवर्ड) का इस्तेमाल करना ज़रूरी है. इस बारे में सेक्शन 7.3.10 में [C-1-7] और [C-1-8] में बताया गया है.
• [C-5-3] इन तरीकों को सुरक्षित लॉक स्क्रीन के तौर पर इस्तेमाल नहीं किया जाना चाहिए. साथ ही, इनके लिए यहां दिए गए सेक्शन में C-8 से शुरू होने वाली ज़रूरी शर्तें पूरी करना ज़रूरी है.

अगर डिवाइस में लॉक स्क्रीन को अनलॉक करने के लिए, पुष्टि करने के तरीकों को जोड़ा जाता है या उनमें बदलाव किया जाता है और पुष्टि करने का नया तरीका, किसी फ़िज़िकल टोकन या जगह की जानकारी पर आधारित है, तो:

• [C-6-1] पुष्टि करने के लिए सुझाए गए किसी एक मुख्य तरीके का इस्तेमाल करने के लिए, उनके पास फ़ॉल-बैक मैकेनिज्म होना चाहिए. यह तरीका, किसी ऐसे गुप्त पासवर्ड पर आधारित होना चाहिए जिसकी जानकारी सभी के पास हो. साथ ही, यह सुरक्षित लॉक स्क्रीन के तौर पर इस्तेमाल किए जाने की ज़रूरी शर्तें पूरी करता हो.
• [C-6-2] डिवाइस नीति कंट्रोलर (डीपीसी) ऐप्लिकेशन ने नीति को इनमें से किसी एक के साथ सेट किया हो, तो स्क्रीन अनलॉक करने के लिए, पुष्टि करने के सुझाए गए मुख्य तरीकों में से सिर्फ़ एक को अनुमति दी जानी चाहिए:
  • DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) वाला तरीका
  • PASSWORD_QUALITY_NONE के मुकाबले, क्वालिटी के लिए ज़्यादा पाबंदी वाला DevicePolicyManager.setPasswordQuality() तरीका.
  • PASSWORD_COMPLEXITY_NONE के मुकाबले, ज़्यादा पाबंदी वाली जटिलता वाली बकेट वाला DevicePolicyManager.setRequiredPasswordComplexity() तरीका.
• [C-6-3] उपयोगकर्ता को पुष्टि करने के लिए, सुझाए गए मुख्य तरीकों में से किसी एक का इस्तेमाल करना होगा.जैसे, पिन, पैटर्न, पासवर्ड.ऐसा हर चार घंटे या उससे कम समय में एक बार करना ज़रूरी है. जब कोई फ़िज़िकल टोकन, C-X में TrustAgent लागू करने की ज़रूरी शर्तें पूरी करता है, तो C-9-5 में बताई गई टाइम आउट की पाबंदियां लागू होती हैं.
• [C-6-4] नए तरीके को सुरक्षित लॉक स्क्रीन के तौर पर इस्तेमाल नहीं किया जाना चाहिए. साथ ही, इसे C-8 में बताई गई पाबंदियों का पालन करना चाहिए.

अगर डिवाइस में सुरक्षित लॉक स्क्रीन है और एक या एक से ज़्यादा ट्रस्ट एजेंट शामिल हैं, जो TrustAgentService सिस्टम एपीआई को लागू करते हैं, तो:

• [C-7-1] जब डिवाइस लॉक को कुछ समय के लिए रोका जाता है या उसे ट्रस्ट एजेंट अनलॉक कर सकते हैं, तो सेटिंग मेन्यू और लॉक स्क्रीन पर साफ़ तौर पर जानकारी दिखनी चाहिए. उदाहरण के लिए, AOSP इस ज़रूरी शर्त को पूरा करता है. इसके लिए, सेटिंग मेन्यू में "स्क्रीन अपने-आप लॉक होने की सेटिंग" और "पावर बटन से तुरंत लॉक हो जाता है" के लिए टेक्स्ट के तौर पर जानकारी दिखाता है. साथ ही, लॉक स्क्रीन पर एक अलग आइकॉन दिखाता है.
• [C-7-2] ऐप्लिकेशन को DevicePolicyManager क्लास में मौजूद सभी ट्रस्ट एजेंट एपीआई का पालन करना होगा और उन्हें पूरी तरह से लागू करना होगा. जैसे, KEYGUARD_DISABLE_TRUST_AGENTS कॉन्स्टेंट.
• [C-7-3] TrustAgentService.addEscrowToken() फ़ंक्शन को किसी ऐसे डिवाइस पर पूरी तरह से लागू नहीं किया जाना चाहिए जिसका इस्तेमाल मुख्य निजी डिवाइस (जैसे, हैंडहेल्ड) के तौर पर किया जाता है. हालांकि, इस फ़ंक्शन को आम तौर पर शेयर किए जाने वाले डिवाइसों (जैसे, Android Television या ऑटोमोटिव डिवाइस) पर पूरी तरह से लागू किया जा सकता है.
• [C-7-4] TrustAgentService.addEscrowToken() के जोड़े गए सभी सेव किए गए टोकन को एन्क्रिप्ट करना ज़रूरी है.
• [C-7-5] एन्क्रिप्शन कुंजी या एस्क्रो टोकन को उसी डिवाइस पर सेव नहीं करना चाहिए जिस पर कुंजी का इस्तेमाल किया जाता है. उदाहरण के लिए, फ़ोन पर सेव की गई कुंजी का इस्तेमाल करके, टीवी पर उपयोगकर्ता खाता अनलॉक किया जा सकता है. वाहन से जुड़े डिवाइसों के लिए, एस्क्रो टोकन को वाहन के किसी भी हिस्से पर सेव करने की अनुमति नहीं है.
• [C-7-6] डेटा स्टोरेज को डिक्रिप्ट करने के लिए, एस्क्रो टोकन को चालू करने से पहले, उपयोगकर्ता को सुरक्षा से जुड़े असर के बारे में ज़रूर बताना चाहिए.
• [C-7-7] पुष्टि करने के लिए सुझाए गए मुख्य तरीकों में से किसी एक का इस्तेमाल करने के लिए, फ़ॉल-बैक मैकेनिज्म होना चाहिए.
• [C-7-8] उपयोगकर्ता को पुष्टि करने के लिए, सुझाए गए मुख्य तरीकों (जैसे: पिन, पैटर्न, पासवर्ड) में से किसी एक का इस्तेमाल करने के लिए, कम से कम हर 72 घंटे या उससे कम समय में एक बार ज़रूर कहा जाना चाहिए. ऐसा तब तक करना चाहिए, जब तक उपयोगकर्ता की सुरक्षा (जैसे, ड्राइवर का ध्यान भटकना) को लेकर कोई समस्या न हो.
• [C-7-9] उपयोगकर्ता को पुष्टि करने के लिए, सेक्शन 7.3.10 में [C-1-7] और [C-1-8] में बताए गए पुष्टि करने के मुख्य तरीकों (जैसे: पिन, पैटर्न, पासवर्ड) में से किसी एक का इस्तेमाल करना ज़रूरी है. ऐसा तब तक करना होगा, जब तक कि उपयोगकर्ता की सुरक्षा (जैसे, ड्राइवर का ध्यान भटकना) को लेकर कोई समस्या न हो.
• [C-7-10] इसे सुरक्षित लॉक स्क्रीन के तौर पर इस्तेमाल नहीं किया जाना चाहिए. साथ ही, इसे यहां C-8 में बताई गई पाबंदियों का पालन करना चाहिए.
• [C-7-11] मुख्य निजी डिवाइसों (उदाहरण के लिए, हैंडहेल्ड) पर, TrustAgents को डिवाइस अनलॉक करने की अनुमति नहीं दी जानी चाहिए.साथ ही, इनका इस्तेमाल सिर्फ़ पहले से अनलॉक किए गए डिवाइस को अनलॉक की स्थिति में, ज़्यादा से ज़्यादा चार घंटे तक रखने के लिए किया जा सकता है. AOSP में डिफ़ॉल्ट रूप से लागू की गई TrustManagerService, इस ज़रूरी शर्त को पूरा करती है.
• [C-7-12] एस्क्रो टोकन को स्टोरेज डिवाइस से टारगेट डिवाइस पर भेजने के लिए, क्रिप्टोग्राफ़िक तरीके से सुरक्षित (उदाहरण के लिए, UKEY2) कम्यूनिकेशन चैनल का इस्तेमाल करना ज़रूरी है.

अगर डिवाइस में, ऊपर बताई गई सुरक्षित लॉक स्क्रीन को अनलॉक करने के लिए, पुष्टि करने के तरीकों को जोड़ा जाता है या उनमें बदलाव किया जाता है और कीगार्ड को अनलॉक करने के लिए, पुष्टि करने का नया तरीका इस्तेमाल किया जाता है, तो:

• [C-8-1] जब डिवाइस नीति कंट्रोलर (डीपीसी) ऐप्लिकेशन ने पासवर्ड की क्वालिटी से जुड़ी नीति को DevicePolicyManager.setPasswordQuality() के ज़रिए सेट किया हो, तो नया तरीका बंद करना ज़रूरी है. साथ ही, PASSWORD_QUALITY_NONE से ज़्यादा पाबंदी वाला क्वालिटी कॉन्स्टेंट या DevicePolicyManager.setRequiredPasswordComplexity() के ज़रिए सेट किया गया हो, तो भी नया तरीका बंद करना ज़रूरी है. साथ ही, 'PASSWORD_COMPLEXITY_NONE' से ज़्यादा पाबंदी वाला कॉन्स्टेंट इस्तेमाल किया गया हो.
• [C-8-2] उन्हें DevicePolicyManager.setPasswordExpirationTimeout() से सेट किए गए, पासवर्ड की समयसीमा खत्म होने के टाइमर को रीसेट नहीं करना चाहिए.
• [C-8-3] उन्हें तीसरे पक्ष के ऐप्लिकेशन के इस्तेमाल के लिए, एपीआई को ज़ाहिर नहीं करना चाहिए, ताकि वे लॉक की स्थिति बदल सकें.

अगर डिवाइस पर लागू किए गए तरीके से, ऐप्लिकेशन को सेकंडरी वर्चुअल डिसप्ले बनाने की अनुमति मिलती है और वे VirtualDeviceManager जैसे इनपुट इवेंट के साथ काम नहीं करते, तो:

• [C-9-1] डिवाइस का डिफ़ॉल्ट डिसप्ले लॉक होने पर, इन सेकंडरी वर्चुअल डिसप्ले को लॉक करना ज़रूरी है. साथ ही, डिवाइस का डिफ़ॉल्ट डिसप्ले अनलॉक होने पर, इन सेकंडरी वर्चुअल डिसप्ले को अनलॉक करना ज़रूरी है.

अगर डिवाइस के लागू होने से, ऐप्लिकेशन को सेकंडरी वर्चुअल डिसप्ले बनाने और उनसे जुड़े इनपुट इवेंट के साथ काम करने की अनुमति मिलती है, जैसे कि VirtualDeviceManager के ज़रिए, तो:

• [C-10-1] हर वर्चुअल डिवाइस के लिए, लॉक की अलग-अलग स्थितियों के साथ काम करना चाहिए
• [C-10-2] कोई भी वर्चुअल डिवाइस, इस्तेमाल में न होने पर तय समय के बाद डिसकनेक्ट हो जाना चाहिए
• [C-10-3] इसमें कोई आइडल टाइम आउट होना चाहिए
• [C-10-4] जब उपयोगकर्ता लॉकडाउन शुरू करता है, तो सभी डिसप्ले को लॉक करना ज़रूरी है. इसमें, हाथ में पकड़े जाने वाले डिवाइसों के लिए ज़रूरी लॉकडाउन यूज़र अफ़र्डेंस (उपयोगकर्ता के लिए उपलब्ध सुविधा) का इस्तेमाल करना भी शामिल है. ज़्यादा जानकारी के लिए, सेक्शन 2.2.5[9.11/H-1-2] देखें
• [C-10-5] हर उपयोगकर्ता के लिए, अलग-अलग वर्चुअल डिवाइस इंस्टेंस होने चाहिए
• [C-10-6] DevicePolicyManager.setNearbyAppStreamingPolicy के निर्देश मिलने पर, VirtualDeviceManager की मदद से, इनपुट इवेंट बनाने की सुविधा बंद करना ज़रूरी है
• [C-10-7] हर वर्चुअल डिवाइस के लिए, अलग क्लिपबोर्ड का इस्तेमाल करना ज़रूरी है (या वर्चुअल डिवाइसों के लिए क्लिपबोर्ड की सुविधा बंद करना)
• [C-10-11] वर्चुअल डिवाइसों पर पुष्टि करने के यूज़र इंटरफ़ेस (यूआई) को बंद करना ज़रूरी है. इसमें, जानकारी वाले फ़ैक्टर की एंट्री और बायोमेट्रिक प्रॉम्प्ट शामिल हैं
• [C-10-12] वर्चुअल डिवाइस से शुरू किए गए इंटेंट को सिर्फ़ उसी वर्चुअल डिवाइस पर दिखाने के लिए पाबंदी लगाना ज़रूरी है
• [C-10-13] Android Keystore System की मदद से, उपयोगकर्ता की पुष्टि करने के लिए, वर्चुअल डिवाइस लॉक की स्थिति का इस्तेमाल नहीं किया जाना चाहिए. KeyGenParameterSpec.Builder.setUserAuthentication* देखें.

जब डिवाइस पर पुष्टि करने के लिए इस्तेमाल होने वाले मुख्य फ़ैक्टर को सोर्स डिवाइस से टारगेट डिवाइस पर ट्रांसफ़र करने की अनुमति होती है, तो उपयोगकर्ता:

• [C-11-1] Google Cloud Key Vault Service की सुरक्षा से जुड़े व्हाइट पेपर में बताई गई सुरक्षा की गारंटी के साथ, नॉलेज फ़ैक्टर को एन्क्रिप्ट करना ज़रूरी है. ऐसा तब करना चाहिए, जब नॉलेज फ़ैक्टर को सोर्स डिवाइस से टारगेट डिवाइस पर ट्रांसफ़र किया जा रहा हो. इससे नॉलेज फ़ैक्टर को रिमोट तरीके से डिक्रिप्ट नहीं किया जा सकता या किसी भी डिवाइस को रिमोट तरीके से अनलॉक करने के लिए उसका इस्तेमाल नहीं किया जा सकता.
• [C-11-2] सोर्स डिवाइस पर, उपयोगकर्ता से टारगेट डिवाइस पर, ज़रूरी जानकारी ट्रांसफ़र करने से पहले, सोर्स डिवाइस पर मौजूद ज़रूरी जानकारी की पुष्टि करने के लिए कहा जाना चाहिए.
• [C-11-3] टारगेट डिवाइस पर पुष्टि करने के लिए कोई मुख्य पासवर्ड सेट न होने पर, उपयोगकर्ता से टारगेट डिवाइस पर ट्रांसफ़र किए गए पासवर्ड की पुष्टि करने के लिए कहा जाना चाहिए. ऐसा, टारगेट डिवाइस पर पुष्टि करने के लिए उस पासवर्ड को मुख्य पासवर्ड के तौर पर सेट करने से पहले और सोर्स डिवाइस से ट्रांसफ़र किए गए किसी भी डेटा को उपलब्ध कराने से पहले किया जाना चाहिए.

अगर डिवाइस में सुरक्षित लॉक स्क्रीन है और एक या उससे ज़्यादा ट्रस्ट एजेंट शामिल हैं, जो FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE फ़्लैग के साथ TrustAgentService.grantTrust() सिस्टम एपीआई को कॉल करते हैं, तो:

• [C-12-1] grantTrust() को सिर्फ़ तब फ़्लैग के साथ कॉल करना चाहिए, जब वह किसी ऐसे डिवाइस से कनेक्ट हो जिस पर लॉकस्क्रीन हो और उपयोगकर्ता ने उस लॉकस्क्रीन पर अपनी पहचान की पुष्टि की हो. उपयोगकर्ता की पहचान की पुष्टि करने की ज़रूरी शर्त को पूरा करने के लिए, उपयोगकर्ता के डिवाइस को एक बार अनलॉक करने के बाद, आस-पास मौजूद डिवाइसों में, स्मार्टवॉच या पहने हुए डिवाइस की पहचान करने की सुविधा का इस्तेमाल किया जा सकता है.
• [C-12-2] डिवाइस को TrustState.TRUSTABLE स्थिति में तब रखना ज़रूरी है, जब स्क्रीन बंद हो (जैसे, बटन दबाने या डिसप्ले के टाइम आउट की वजह से) और TrustAgent ने भरोसा वापस न लिया हो. AOSP, इस ज़रूरी शर्त को पूरा करता है.
• [C-12-3] डिवाइस को TrustState.TRUSTABLE से TrustState.TRUSTED स्थिति में सिर्फ़ तब ले जाना चाहिए, जब TrustAgent अब भी C-12-1 में बताई गई ज़रूरी शर्तों के आधार पर भरोसा दे रहा हो.
• [C-12-4] TrustManagerService.revokeTrust() को कॉल करना ज़रूरी है
  • भरोसा करने के 24 घंटे बाद या
  • आठ घंटे तक इस्तेमाल न करने के बाद या
  • अगर आस-पास मौजूद फ़िज़िकल डिवाइस से कनेक्शन टूटने पर, क्रिप्टोग्राफ़िक तरीके से सुरक्षित और सटीक रेंजिंग का इस्तेमाल नहीं किया जा रहा है, जैसा कि [C-12-5] में बताया गया है.
• [C-12-5] [C-12-4] की ज़रूरी शर्तों को पूरा करने के लिए, सुरक्षित और सटीक रेंजिंग पर आधारित लागू करने के लिए, इनमें से किसी एक समाधान का इस्तेमाल करना ज़रूरी है:
  • UWB का इस्तेमाल करके लागू करने के तरीके:
    • 7.4.9 में बताई गई, UWB के लिए तय की गई, कैलिब्रेशन की ज़रूरी शर्तों, सर्टिफ़िकेशन, सटीक जानकारी, और नियमों का पालन करना ज़रूरी है.
    • 7.4.9 में दिए गए P-STS के सुरक्षा मोड में से किसी एक का इस्तेमाल करना ज़रूरी है.
  • वाई-फ़ाई नेबरहुड अवेयरनेस नेटवर्किंग (एनएएन) का इस्तेमाल करके लागू करने के तरीके:
    • 2.2.1 [7.4.2.5/H-SR-1] में दी गई सटीक जानकारी से जुड़ी ज़रूरी शर्तों को पूरा करना ज़रूरी है. साथ ही, 160 मेगाहर्ट्ज़ (या इससे ज़्यादा) बैंडविड्थ का इस्तेमाल करना होगा. इसके अलावा, मौजूदगी को कैलिब्रेट करने के लिए, मेज़रमेंट सेटअप करने के चरणों का पालन करना होगा.
    • IEEE 802.11az में बताए गए तरीके के मुताबिक, सुरक्षित एलटीएफ़ का इस्तेमाल करना ज़रूरी है.

अगर डिवाइस में लागू किए गए तरीके से, ऐप्लिकेशन को सेकंडरी वर्चुअल डिसप्ले बनाने की अनुमति मिलती है और VirtualDeviceManager के ज़रिए इनसे जुड़े इनपुट इवेंट काम करते हैं और डिसप्ले को VIRTUAL_DISPLAY_FLAG_SECURE के साथ मार्क नहीं किया जाता है, तो:

• [C-13-8] वर्चुअल डिवाइस पर गतिविधियों को शुरू होने से रोकने के लिए, android:canDisplayOnRemoteDevices एट्रिब्यूट का इस्तेमाल करना चाहिए. इसके अलावा, मेटाडेटा android.activity.can_display_on_remote_devices को 'गलत' पर सेट किया जा सकता है.
• [C-13-9] वर्चुअल डिवाइस पर ऐसी गतिविधियां शुरू होने से रोकना ज़रूरी है जो साफ़ तौर पर स्ट्रीमिंग की सुविधा चालू नहीं करती हैं और जिनसे यह पता चलता है कि वे संवेदनशील कॉन्टेंट दिखाती हैं. इनमें SurfaceView#setSecure, FLAG_SECURE या SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS के ज़रिए भी ऐसा किया जा सकता है.
• [C-13-10] वर्चुअल डिवाइसों से शुरू किए गए ऐप्लिकेशन इंस्टॉल करने की सुविधा बंद करना ज़रूरी है.

अगर डिवाइस में DeviceStateManager के ज़रिए डिसप्ले की अलग-अलग पावर स्टेटस और KeyguardDisplayManager के ज़रिए डिसप्ले की अलग-अलग लॉक स्टेटस की सुविधा काम करती है, तो:

• [C-SR-2] डिफ़ॉल्ट डिवाइस डिसप्ले से डिवाइस को अनलॉक करने की सुविधा देने के लिए, हमारा सुझाव है कि आप सेक्शन 9.11.1 में बताई गई क्रेडेंशियल की ज़रूरी शर्तों को पूरा करने वाले क्रेडेंशियल का इस्तेमाल करें. इसके अलावा, सेक्शन 7.3.10 में बताई गई कम से कम क्लास 1 की विशेषताओं वाले बायोमेट्रिक क्रेडेंशियल का इस्तेमाल भी किया जा सकता है.
• [C-SR-3] हमारा सुझाव है कि डिसप्ले के लिए तय किए गए टाइम आउट की मदद से, अलग-अलग डिसप्ले को अनलॉक करने की सुविधा को सीमित करें.
• [C-SR-4] हमारा सुझाव है कि उपयोगकर्ता को मुख्य हैंडहेल्ड डिवाइस से लॉकडाउन की सुविधा देकर, दुनिया भर में सभी डिसप्ले को लॉक करने की अनुमति दी जाए.

9.11.2. StrongBox

Android Keystore System की मदद से, ऐप्लिकेशन डेवलपर, क्रिप्टोग्राफ़िक पासकोड को एक खास सुरक्षित प्रोसेसर में सेव कर सकते हैं. साथ ही, ऊपर बताए गए अलग-अलग प्रोसेसिंग एनवायरमेंट में भी सेव कर सकते हैं. इस तरह के खास और सुरक्षित प्रोसेसर को "स्ट्रॉन्गबॉक्स" कहा जाता है. यहां C-1-3 से C-1-11 तक की ज़रूरी शर्तों के बारे में बताया गया है. इन शर्तों को पूरा करने पर ही किसी डिवाइस को StrongBox के तौर पर मंज़ूरी दी जाती है.

डिवाइस में लागू किए गए ऐसे टूल जिनमें खास तौर पर सुरक्षित प्रोसेसर होता है:

• [C-SR-1] हमारा सुझाव है कि आप StrongBox का इस्तेमाल करें. आने वाले समय में, StrongBox का इस्तेमाल करना ज़रूरी हो सकता है.

अगर डिवाइस पर StrongBox की सुविधा काम करती है, तो:

• [C-1-1] FEATURE_STRONGBOX_KEYSTORE का एलान करना ज़रूरी है.

• [C-1-2] यह ज़रूरी है कि डिवाइस में खास तौर पर सुरक्षित हार्डवेयर दिया गया हो. इसका इस्तेमाल, पासकोड सेव करने और उपयोगकर्ता की पहचान की पुष्टि करने के लिए किया जाता है. खास तौर पर सुरक्षित किए गए हार्डवेयर का इस्तेमाल, अन्य कामों के लिए भी किया जा सकता है.

• [C-1-3] इसमें एक अलग सीपीयू होना चाहिए, जो ऐप्लिकेशन प्रोसेसर (एपी) के साथ कोई कैश, डीआरएएम, कोप्रोसेसर या अन्य मुख्य संसाधन शेयर न करता हो.

• [C-1-4] यह पक्का करना ज़रूरी है कि एपी के साथ शेयर किए गए किसी भी डिवाइस से, StrongBox की प्रोसेसिंग में कोई बदलाव न किया जा सके या StrongBox से कोई जानकारी न ली जा सके. एपी, StrongBox को ऐक्सेस करने की सुविधा को बंद या ब्लॉक कर सकता है.

• [C-1-5] इसमें एक ऐसी इंटरनल क्लॉक होनी चाहिए जो सटीक (+-10%) हो और एपी के मैनिपुलेशन से सुरक्षित हो.

• [C-1-6] इसमें सच्चा रैंडम नंबर जनरेटर होना चाहिए, जो एक जैसा डिस्ट्रिब्यूशन वाला और अनुमान न लगाने लायक आउटपुट देता हो.

• [C-1-7] इसमें बदलाव करने से रोकने की सुविधा होनी चाहिए. इसमें, डिवाइस में गड़बड़ी करने और उसे नुकसान पहुंचाने से रोकने की सुविधा भी शामिल है.

• [C-1-8] इसमें साइड-चैनल रेज़िस्टेंस होना चाहिए. इसमें पावर, टाइमिंग, इलेक्ट्रोमैग्नेटिक रेडिएशन, और थर्मल रेडिएशन साइड चैनलों के ज़रिए जानकारी लीक होने से रोकने की सुविधा भी शामिल है.

• [C-1-9] इसमें सुरक्षित स्टोरेज होना चाहिए, ताकि कॉन्टेंट की गोपनीयता, पूरी सुरक्षा, प्रामाणिकता, एक जैसी जानकारी, और अपडेट की गई जानकारी का रखरखाव किया जा सके. स्टोरेज को पढ़ा या उसमें बदलाव नहीं किया जा सकता. हालांकि, StrongBox API की अनुमति के मुताबिक ऐसा किया जा सकता है.

• [C-1-3] से [C-1-9] तक के नियमों का पालन करने के लिए, डिवाइस पर लागू होने वाले निर्देशों के बारे में जानकारी:

  • [C-1-10] इसमें ऐसा हार्डवेयर शामिल होना चाहिए जिसे सुरक्षित आईसी प्रोटेक्शन प्रोफ़ाइल BSI-CC-PP-0084-2014 के तहत सर्टिफ़ाइड किया गया हो या जिसकी जांच, राष्ट्रीय स्तर पर मान्यता वाली टेस्टिंग लैबोरेटरी ने की हो. इस लैबोरेटरी ने स्मार्ट कार्ड पर हमले की संभावना के लिए सामान्य मानदंड के मुताबिक, हमले की ज़्यादा संभावना वाली कमज़ोरियों का आकलन किया हो.
  • [C-1-11] इसमें ऐसा फ़र्मवेयर शामिल होना चाहिए जिसका आकलन, राष्ट्रीय स्तर पर मान्यता वाली टेस्टिंग लैबोरेटरी ने किया हो. इसमें स्मार्ट कार्ड पर हमले की संभावितता के लिए सामान्य मानदंड के मुताबिक, हमले की संभावित ज़्यादा जोखिम का आकलन शामिल होना चाहिए.
  • [C-SR-2] हमारा सुझाव है कि आप ऐसे हार्डवेयर को शामिल करें जिसका आकलन, सुरक्षा टारगेट, जांच के भरोसे के लेवल (ईएएल) 5 का इस्तेमाल करके किया गया हो. साथ ही, AVA_VAN.5 की मदद से इसकी जांच की गई हो. आने वाले समय में रिलीज़ होने वाले वर्शन के लिए, EAL 5 सर्टिफ़िकेशन होना ज़रूरी हो सकता है.
  • [C-SR-3] हमारा सुझाव है कि आप अपने डिवाइस में अंदरूनी हमले से सुरक्षा (आईएआर) की सुविधा दें. इसका मतलब है कि फ़र्मवेयर साइन करने की कुंजियों का ऐक्सेस रखने वाला कोई भी व्यक्ति, ऐसा फ़र्मवेयर नहीं बना सकता जिससे StrongBox से गोपनीय जानकारी लीक हो. साथ ही, वह सुरक्षा से जुड़ी ज़रूरी शर्तों को बायपास करने या उपयोगकर्ता के संवेदनशील डेटा को ऐक्सेस करने की सुविधा भी नहीं दे सकता. आईएआर को लागू करने का सुझाया गया तरीका यह है कि फ़र्मवेयर अपडेट की अनुमति सिर्फ़ तब दी जाए, जब मुख्य उपयोगकर्ता का पासवर्ड, IAuthSecret HAL के ज़रिए दिया गया हो.

9.11.3. आइडेंटिटी क्रेडेंशियल

android.security.identity.* पैकेज में सभी एपीआई लागू करके, आइडेंटिटी क्रेडेंशियल सिस्टम को तय किया जाता है और उसे हासिल किया जाता है. इन एपीआई की मदद से, ऐप्लिकेशन डेवलपर उपयोगकर्ता की पहचान से जुड़े दस्तावेज़ों को सेव और वापस पा सकते हैं. डिवाइस पर लागू करने के तरीके:

• [C-SR-1] को पहचान की पुष्टि करने वाले क्रेडेंशियल सिस्टम को लागू करने का ज़रूर सुझाव दिया जाता है.

अगर डिवाइस पर Identity Credential System लागू किया जाता है, तो:

• [C-1-1] IdentityCredentialStore#getInstance() तरीके के लिए, नॉल की वैल्यू नॉल नहीं होनी चाहिए.

• [C-1-2] पहचान की पुष्टि करने वाले सिस्टम (उदाहरण के लिए, android.security.identity.* एपीआई) को लागू करना ज़रूरी है. इसके लिए, कोड को किसी भरोसेमंद ऐप्लिकेशन के साथ, ऐसे एरिया में कम्यूनिकेट करना चाहिए जो कर्नेल और उससे ऊपर चलने वाले कोड से सुरक्षित रूप से अलग हो. सुरक्षित आइसोलेशन की सुविधा, उन सभी संभावित तरीकों को ब्लॉक करनी चाहिए जिनकी मदद से कर्नेल या यूज़रस्पेस कोड, डीएमए के साथ-साथ आइसोलेट किए गए एनवायरमेंट की इंटरनल स्टेटस को ऐक्सेस कर सकता है.

• [C-1-3] पहचान की पुष्टि करने वाले क्रेडेंशियल सिस्टम (जैसे, android.security.identity.* एपीआई) को लागू करने के लिए, क्रिप्टोग्राफ़िक ऑपरेशन पूरी तरह से भरोसेमंद ऐप्लिकेशन में किए जाने चाहिए. साथ ही, निजी कुंजी का कॉन्टेंट, अलग से चलाए जाने वाले एनवायरमेंट से कभी बाहर नहीं निकलना चाहिए. ऐसा तब तक नहीं होना चाहिए, जब तक कि उच्च लेवल के एपीआई (जैसे, createEphemeralKeyPair() तरीका) के लिए ज़रूरी न हो.

• [C-1-4] भरोसेमंद ऐप्लिकेशन को इस तरह से लागू करना ज़रूरी है कि उसकी सुरक्षा से जुड़ी प्रॉपर्टी पर कोई असर न पड़े. उदाहरण के लिए, ऐक्सेस कंट्रोल की शर्तें पूरी होने तक क्रेडेंशियल का डेटा रिलीज़ नहीं किया जाता. साथ ही, मनमुताबिक डेटा के लिए एमएसी नहीं बनाए जा सकते. भले ही, Android ठीक से काम न कर रहा हो या उसमें कोई गड़बड़ी हो.

अपस्ट्रीम Android Open Source Project, भरोसेमंद ऐप्लिकेशन (libeic) के लागू होने का रेफ़रंस देता है. इसका इस्तेमाल, आइडेंटिटी क्रेडेंशियल सिस्टम को लागू करने के लिए किया जा सकता है.

9.12. डेटा हटाना

सभी डिवाइसों पर लागू होने वाले टूल और फ़ॉर्मैट:

• [C-0-1] उपयोगकर्ताओं को "फ़ैक्ट्री डेटा रीसेट" करने का तरीका देना ज़रूरी है.
• [C-0-2] "फ़ैक्ट्री डेटा रीसेट" करते समय, उपयोगकर्ता डेटा फ़ाइल सिस्टम पर मौजूद सारा डेटा मिटाना ज़रूरी है.
• [C-0-3] डेटा को इस तरह मिटाएं कि "फ़ैक्ट्री डेटा रीसेट" करने पर, वह उद्योग के मानकों के मुताबिक हो. जैसे, NIST SP800-88.
• [C-0-4] जब मुख्य उपयोगकर्ता के डिवाइस नीति नियंत्रक ऐप्लिकेशन से DevicePolicyManager.wipeData() एपीआई को कॉल किया जाता है, तो ऊपर दी गई "फ़ैक्ट्री डेटा रीसेट" प्रोसेस को ट्रिगर करना ज़रूरी है.
• डेटा को तुरंत मिटाने का विकल्प दे सकता है. हालांकि, यह विकल्प सिर्फ़ उस डेटा को मिटाता है जो काम का नहीं है.

9.13. सेफ़ बूट मोड

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

डिवाइस पर लागू करने के तरीके:

• [C-SR-1] हमारा सुझाव है कि आप सुरक्षित मोड को लागू करें.

अगर डिवाइस में सुरक्षित बूट मोड लागू किया जाता है, तो:

• [C-1-1] डिवाइस पर इंस्टॉल किए गए तीसरे पक्ष के ऐप्लिकेशन, डिवाइस के सेफ़ बूट मोड में जाने की प्रक्रिया को बीच में न रोक सकें. हालांकि, अगर तीसरे पक्ष का ऐप्लिकेशन डिवाइस नीति कंट्रोल करने वाला ऐप्लिकेशन है और उसने UserManager.DISALLOW_SAFE_BOOT फ़्लैग को 'सही' के तौर पर सेट किया है, तो यह ज़रूरी नहीं है.

• [C-1-2] उपयोगकर्ता को सुरक्षित मोड में, तीसरे पक्ष के किसी भी ऐप्लिकेशन को अनइंस्टॉल करने की सुविधा देनी चाहिए.

• उपयोगकर्ता को बूट मेन्यू से, सुरक्षित मोड में जाने का विकल्प देना चाहिए. इसके लिए, सामान्य बूट से अलग वर्कफ़्लो का इस्तेमाल किया जाना चाहिए.

9.14. वाहन के सिस्टम को आइसोलेट करना

Android Automotive डिवाइसों को, गाड़ी के अहम सबसिस्टम के साथ डेटा शेयर करना चाहिए. इसके लिए, उन्हें वाहन के HAL का इस्तेमाल करना होगा. इससे, CAN बस जैसे वाहन नेटवर्क पर मैसेज भेजने और पाने में मदद मिलती है.

Android फ़्रेमवर्क लेयर के नीचे सुरक्षा सुविधाएं लागू करके, डेटा एक्सचेंज को सुरक्षित किया जा सकता है. इससे इन सबसिस्टम के साथ नुकसान पहुंचाने वाले या अनजाने में होने वाले इंटरैक्शन को रोका जा सकता है.

9.15. सदस्यता प्लान

"सदस्यता प्लान" से, बिलिंग रिलेशनशिप प्लान की जानकारी का मतलब है. यह जानकारी, मोबाइल और इंटरनेट सेवा देने वाली कंपनी SubscriptionManager.setSubscriptionPlans() के ज़रिए दी जाती है.

सभी डिवाइसों पर लागू होने वाले टूल और फ़ॉर्मैट:

• [C-0-1] सदस्यता के प्लान, सिर्फ़ उस मोबाइल और इंटरनेट सेवा देने वाली कंपनी के ऐप्लिकेशन पर वापस भेजे जाने चाहिए जिसने उन्हें मूल रूप से उपलब्ध कराया है.
• [C-0-2] सदस्यता के प्लान का रिमोट तौर पर बैक अप नहीं लेना चाहिए या उन्हें अपलोड नहीं करना चाहिए.
• [C-0-3] सिर्फ़ उस मोबाइल कैरियर ऐप्लिकेशन से बदलाव करने की अनुमति होनी चाहिए जो फ़िलहाल मान्य सदस्यता प्लान उपलब्ध करा रहा है. जैसे, SubscriptionManager.setSubscriptionOverrideCongested().

9.16. ऐप्लिकेशन का डेटा माइग्रेट करना

अगर डिवाइस में डेटा को एक डिवाइस से दूसरे डिवाइस पर माइग्रेट करने की सुविधा शामिल है और वह ऐप्लिकेशन डेटा को सिर्फ़ उस डेटा तक सीमित नहीं करता जिसे ऐप्लिकेशन डेवलपर ने android:fullBackupContent एट्रिब्यूट की मदद से मेनिफ़ेस्ट में कॉन्फ़िगर किया है, तो:

• [C-1-1] ऐसे डिवाइसों से ऐप्लिकेशन डेटा ट्रांसफ़र नहीं किया जाना चाहिए जिन पर उपयोगकर्ता ने 9.11.1 सुरक्षित लॉक स्क्रीन और पुष्टि में बताए गए तरीके से, मुख्य पुष्टि करने की सुविधा सेट नहीं की है.
• [C-1-2] सोर्स डिवाइस पर प्राइमरी पुष्टि की सुरक्षित तरीके से पुष्टि करना ज़रूरी है. साथ ही, डेटा ट्रांसफ़र करने से पहले, उपयोगकर्ता की ओर से सोर्स डिवाइस पर डेटा कॉपी करने के इंटेंट की पुष्टि करना ज़रूरी है.
• [C-1-3] सुरक्षा कुंजी की पुष्टि करने की सुविधा का इस्तेमाल करना ज़रूरी है, ताकि यह पक्का किया जा सके कि डिवाइस से डिवाइस पर माइग्रेट करने के दौरान, सोर्स डिवाइस और टारगेट डिवाइस, दोनों ही मान्य Android डिवाइस हों और उनका बूटलोडर लॉक हो.
• [C-1-4] ऐप्लिकेशन डेटा को टारगेट डिवाइस पर मौजूद उसी ऐप्लिकेशन में माइग्रेट करना चाहिए जिसका पैकेज नाम और साइनिंग सर्टिफ़िकेट एक ही हो.
• [C-1-5] सेटिंग मेन्यू में यह जानकारी दिखनी चाहिए कि सोर्स डिवाइस का डेटा, डिवाइस से डिवाइस पर डेटा माइग्रेट करने की सुविधा की मदद से माइग्रेट किया गया है. उपयोगकर्ता को यह संकेत नहीं हटाना चाहिए.

9.17. Android वर्चुअलाइज़ेशन फ़्रेमवर्क

अगर डिवाइस में Android वर्चुअलाइज़ेशन फ़्रेमवर्क एपीआई (android.system.virtualmachine.*) के लिए सहायता लागू की जाती है, तो Android होस्ट:

• [C-1-1] यह android.system.virtualmachine पैकेज में बताए गए सभी एपीआई के साथ काम करना चाहिए.
• [C-1-2] सुरक्षित वर्चुअल मशीनों (pVM) के मैनेजमेंट के लिए, Android SELinux और अनुमति मॉडल में बदलाव नहीं किया जाना चाहिए.

• [C-1-3] अपस्ट्रीम Android Open Source Project (AOSP) में दिए गए system/sepolicy में मौजूद, कभी भी अनुमति न देने वाले नियमों में बदलाव नहीं किया जाना चाहिए, उन्हें हटाया नहीं जाना चाहिए या उन्हें बदला नहीं जाना चाहिए. साथ ही, नीति को कभी भी अनुमति न देने वाले सभी नियमों के साथ कंपाइल किया जाना चाहिए.

• [C-1-4] सिर्फ़ प्लैटफ़ॉर्म पर हस्ताक्षर किए गए कोड और ऐप्लिकेशन को अनुमति दें. साथ ही, भरोसेमंद कोड (जैसे, तीसरे पक्ष के ऐप्लिकेशन) को सुरक्षित वर्चुअल मशीन (pVM)pVM बनाने और चलाने की अनुमति न दें. ध्यान दें: Android के आने वाले वर्शन में यह बदलाव हो सकता है.

• [C-1-5] सुरक्षित वर्चुअल मशीन pVM को ऐसे कोड को लागू करने की अनुमति नहीं देनी चाहिए जो फ़ैक्ट्री इमेज या उनके अपडेट का हिस्सा नहीं है. Android वेरिफ़ाइड बूट की सुविधा के दायरे में न आने वाली किसी भी चीज़ (जैसे, इंटरनेट से डाउनलोड की गई या साइडलोड की गई फ़ाइलें) को सुरक्षित वर्चुअल मशीन में चलाने की अनुमति नहीं दी जानी चाहिए .

नई ज़रूरी शर्तें लागू करना

• [C-1-5] फ़ैक्ट्री इमेज या उनके प्लैटफ़ॉर्म अपडेट से कोड को सिर्फ़ ऐसे pVM को चलाने की अनुमति देनी चाहिए जिसे डीबग नहीं किया जा सकता. इसमें खास ऐप्लिकेशन के अपडेट भी शामिल हैं.

नई ज़रूरी शर्तें खत्म करना

अगर डिवाइस पर Android वर्चुअलाइज़ेशन फ़्रेमवर्क एपीआई (android.system.virtualmachine.*) की सुविधा काम करती है, तो सुरक्षित वर्चुअल मशीन pVM का कोई भी इंस्टेंस:

• [C-2-1] यह ज़रूरी है कि वर्चुअलाइज़ेशन APEX में उपलब्ध सभी ऑपरेटिंग सिस्टम, सुरक्षित वर्चुअल मशीन pVM में चल सकें.
• [C-2-2] सुरक्षित वर्चुअल मशीन pVM को ऐसे ऑपरेटिंग सिस्टम को चलाने की अनुमति नहीं देनी चाहिए जिस पर डिवाइस लागू करने वाले व्यक्ति या ओएस वेंडर ने हस्ताक्षर न किया हो.
• [C-2-3] सुरक्षित वर्चुअल मशीन pVM को डेटा को कोड के तौर पर एक्ज़ीक्यूट करने की अनुमति नहीं देनी चाहिए (उदाहरण के लिए, SELinux कभी भी execmem की अनुमति नहीं देता).

• [C-2-4] अपस्ट्रीम Android Open Source Project (AOSP) में दिए गए system/sepolicy/microdroid में मौजूद, कभी भी अनुमति न देने वाले नियमों में बदलाव नहीं किया जाना चाहिए, उन्हें हटाया नहीं जाना चाहिए या उन्हें बदला नहीं जाना चाहिए.

• [C-2-5] सुरक्षित वर्चुअल मशीन pVM के लिए, सुरक्षा के बेहतर तरीके (जैसे, pVM के लिए SELinux) लागू करना ज़रूरी है. ऐसा Microdroid ऑपरेटिंग सिस्टम के अलावा, अन्य ऑपरेटिंग सिस्टम के लिए भी करना होगा.
• [C-2-6] यह पक्का करना ज़रूरी है कि pVM काम न करे और फ़र्मवेयर बूट न हो. ऐसा तब होता है, जब शुरुआती इमेज की पुष्टि न की जा सके. पुष्टि, वर्चुअल मशीन में ही करनी होगी.
• [C-2-7] यह पक्का करना ज़रूरी है कि instance.img की पूरी सुरक्षा बनाए रखने के लिए, pVM काम न करे फ़र्मवेयर बूट न हो .

अगर डिवाइस में Android वर्चुअलाइज़ेशन फ़्रेमवर्क एपीआई (android.system.virtualmachine.*) के लिए सहायता लागू की जाती है, तो हाइपरवाइजर:

• [C-3-1] यह पक्का करना ज़रूरी है कि किसी वर्चुअल मशीन (pVM या होस्ट वर्चुअल मशीन) के मालिकाना हक वाले मेमोरी पेजों को सिर्फ़ वर्चुअल मशीन या हाइपरवाइजर ऐक्सेस कर सके, न कि अन्य वर्चुअल मशीनें - चाहे वे सुरक्षित हों या असुरक्षित. किसी भी pVM को किसी दूसरी इकाई (जैसे, किसी दूसरे pVM या हाइपरवाइजर) के पेज का ऐक्सेस नहीं देना चाहिए. ऐसा तब तक नहीं किया जाना चाहिए, जब तक पेज के मालिक ने साफ़ तौर पर उसे शेयर न किया हो. इसमें होस्ट VM भी शामिल है. यह सीपीयू और डीएमए, दोनों के ऐक्सेस पर लागू होता है.
• [C-3-2] किसी पेज का इस्तेमाल करने के बाद, उसे pVM से मिटाना ज़रूरी है.साथ ही, होस्ट को वापस करने से पहले भी उसे मिटाना ज़रूरी है. उदाहरण के लिए, pVM को मिटाना.
• [C-3-3SR-1] इस बात का ज़रूर ध्यान रखें पक्का करें कि pVM में किसी भी कोड से पहले, pVM फ़र्मवेयर लोड और चलाया गया हो.
• [C-3-4] यह पक्का करना ज़रूरी है कि हर वर्चुअल मशीन (VM) के लिए एक सीक्रेट पासकोड जनरेट किया जाता है. {Boot Certificate Chain (BCC) और Compound Device Identifier (CDIs) provided to a pVM instance को सिर्फ़ उसी VMइंस्टेंस से जनरेट किया जा सकता है और फ़ैक्ट्री रीसेट और ओटीए (Over-The-Air) के बाद बदल जाता है.

अगर डिवाइस पर Android Virtualization Framework APIs की सुविधा काम करती है, तो:

• [C-4-1] pVM को ऐसा कोई फ़ंक्शन नहीं देना चाहिए जिससे Android Security Model को बायपास किया जा सके.

अगर डिवाइस में Android Virtualization Framework APIs की सुविधा काम करती है, तो:

• [C-5-1] डिवाइस में, अलग-अलग प्रोग्राम के लिए अलग-अलग कंपाइलेशन की सुविधा काम करती हो. हालांकि, ART रनटाइम अपडेट के डिवाइस शिपमेंट पर, अलग-अलग प्रोग्राम के लिए अलग-अलग कंपाइलेशन की सुविधा बंद की जा सकती है.

अगर डिवाइस में Android Virtualization Framework APIs की सुविधा काम करती है, तो पासकोड मैनेजमेंट के लिए:

• [C-6-1] DICE चेन को ऐसे पॉइंट पर रूट करना ज़रूरी है जहां उपयोगकर्ता बदलाव न कर सके. ऐसा, अनलॉक किए गए डिवाइसों पर भी करना ज़रूरी है. (यह पक्का करने के लिए कि इसे स्पूफ नहीं किया जा सकता).

• [C-SR-26-2] हमारा सुझाव है कि हर वर्चुअल मशीन के लिए, गुप्त पासकोड बनाने के तरीके के तौर पर DICE का इस्तेमाल करें. DICE को सही तरीके से लागू करना ज़रूरी है. इसका मतलब है कि सही वैल्यू देना.

10. सॉफ़्टवेयर की कंपैटिबिलिटी टेस्टिंग

डिवाइस लागू करने के लिए, इस सेक्शन में बताए गए सभी टेस्ट पास करने ज़रूरी हैं. हालांकि, ध्यान रखें कि कोई भी सॉफ़्टवेयर टेस्ट पैकेज पूरी तरह से काम का नहीं होता. इस वजह से, डिवाइस में Android को लागू करने वाले लोगों को इसका सुझाव दिया जाता है कि वे Android Open Source Project से, Android के रेफ़रंस और पसंदीदा वर्शन में कम से कम बदलाव करें. इससे, गड़बड़ियों की संभावना कम हो जाएगी. इन गड़बड़ियों की वजह से, डिवाइस के साथ काम करने में समस्याएं आ सकती हैं. इन समस्याओं को ठीक करने के लिए, आपको फिर से काम करना पड़ सकता है. साथ ही, डिवाइस के अपडेट भी किए जा सकते हैं.

10.1. Compatibility Test Suite

डिवाइस पर लागू करने के तरीके:

• [C-0-1] डिवाइस पर शिपिंग के लिए इस्तेमाल किए जाने वाले फ़ाइनल सॉफ़्टवेयर का इस्तेमाल करके, डिवाइस को Android Open Source Project से उपलब्ध Android Compatibility Test Suite (CTS) से पास करना ज़रूरी है.

• [C-0-2] यह ज़रूरी है कि CTS में किसी तरह की गड़बड़ी होने पर और रेफ़रंस सोर्स कोड के कुछ हिस्सों को फिर से लागू करने पर, कम्पैटबिलिटी की पुष्टि की जाए.

सीटीएस को किसी असली डिवाइस पर चलाने के लिए डिज़ाइन किया गया है. किसी भी सॉफ़्टवेयर की तरह, सीटीएस में भी गड़बड़ियां हो सकती हैं. CTS का वर्शन, इस 'काम करने के तरीके' से अलग होगा. साथ ही, Android 14 के लिए CTS के कई वर्शन रिलीज़ किए जा सकते हैं.

डिवाइस पर लागू करने के तरीके:

• [C-0-3] डिवाइस के सॉफ़्टवेयर के पूरा होने के समय, CTS के सबसे नए वर्शन को पास करना ज़रूरी है.

• ज़्यादा से ज़्यादा, Android Open Source Tree में रेफ़रंस के तौर पर लागू किए गए तरीके का इस्तेमाल करना चाहिए.

10.2. सीटीएस की पुष्टि करने वाला व्यक्ति

CTS Verifier, Compatibility Test Suite में शामिल है. इसे किसी व्यक्ति को चलाना होता है, ताकि ऐसी सुविधाओं की जांच की जा सके जिनकी जांच ऑटोमेटेड सिस्टम से नहीं की जा सकती. जैसे, कैमरे और सेंसर की सही तरीके से काम करना.

डिवाइस पर लागू करने के तरीके:

• [C-0-1] CTS की पुष्टि करने वाले टूल में, लागू होने वाले सभी केस सही तरीके से लागू होने चाहिए.

CTS Verifier में कई तरह के हार्डवेयर के लिए टेस्ट होते हैं. इनमें कुछ ऐसे हार्डवेयर भी शामिल हैं जिनका इस्तेमाल करना ज़रूरी नहीं है.

डिवाइस पर लागू करने के तरीके:

• [C-0-2] डिवाइस में मौजूद सभी हार्डवेयर के लिए, सभी टेस्ट पास करने होंगे. उदाहरण के लिए, अगर किसी डिवाइस में ऐक्सेलेरोमीटर है, तो उसे CTS Verifier में ऐक्सेलेरोमीटर टेस्ट केस को सही तरीके से पूरा करना होगा.

इस दस्तावेज़ में, जिन सुविधाओं को ज़रूरी नहीं बताया गया है उनके लिए टेस्ट केस को छोड़ा जा सकता है या हटाया जा सकता है.

• [C-0-2] ऊपर बताए गए मुताबिक, हर डिवाइस और हर बिल्ड में CTS Verifier सही तरीके से काम करना चाहिए. हालांकि, कई बिल्ड काफ़ी मिलते-जुलते होते हैं. इसलिए, डिवाइस को लागू करने वाले लोगों को उन बिल्ड पर सीटीएस की पुष्टि करने वाले टूल को साफ़ तौर पर चलाने की ज़रूरत नहीं होती जो सिर्फ़ मामूली अंतरों में अलग होते हैं. खास तौर पर, डिवाइस के ऐसे वर्शन के लिए, CTS Verifier टेस्ट को छोड़ा जा सकता है जो शामिल किए गए स्थानीय भाषाओं, ब्रैंडिंग वगैरह के सेट के हिसाब से, CTS Verifier टेस्ट पास करने वाले वर्शन से अलग हों.

11. अपडेट किया जा सकने वाला सॉफ़्टवेयर

• [C-0-1] डिवाइस को लागू करने के लिए, सिस्टम के पूरे सॉफ़्टवेयर को बदलने का तरीका ज़रूर होना चाहिए. इस प्रोसेस में, "लाइव" अपडेट करने की ज़रूरत नहीं होती. इसका मतलब है कि डिवाइस को रीस्टार्ट करना पड़ सकता है. किसी भी तरीके का इस्तेमाल किया जा सकता है. हालांकि, यह ज़रूरी है कि वह डिवाइस पर पहले से इंस्टॉल किए गए सभी सॉफ़्टवेयर को बदल सके. उदाहरण के लिए, इनमें से कोई भी तरीका अपनाने पर, यह ज़रूरी शर्त पूरी हो जाएगी:

  • रीबूट करके ऑफ़लाइन अपडेट करने के साथ, "ओवर-द-एयर (ओटीए)" डाउनलोड.
  • होस्ट पीसी से यूएसबी के ज़रिए "टethered" अपडेट.
  • रीबूट करने और हटाने लायक स्टोरेज में मौजूद फ़ाइल से अपडेट करने के ज़रिए, "ऑफ़लाइन" अपडेट.

• [C-0-2] अपडेट करने के लिए इस्तेमाल किए गए तरीके से, उपयोगकर्ता का डेटा मिटाए बिना अपडेट किए जाने की सुविधा होनी चाहिए. इसका मतलब है कि अपडेट करने के तरीके से, ऐप्लिकेशन का निजी डेटा और ऐप्लिकेशन का शेयर किया गया डेटा सुरक्षित रखना ज़रूरी है. ध्यान दें कि अपस्ट्रीम Android सॉफ़्टवेयर में, अपडेट करने का एक ऐसा तरीका शामिल होता है जो इस ज़रूरी शर्त को पूरा करता है.

• [C-0-3] पूरे अपडेट पर हस्ताक्षर होना चाहिए. साथ ही, डिवाइस पर अपडेट करने की सुविधा, डिवाइस पर सेव किए गए सार्वजनिक पासकोड के आधार पर, अपडेट और हस्ताक्षर की पुष्टि करनी चाहिए.

• [C-SR-1] हमारा सुझाव है कि अपडेट को SHA-256 का इस्तेमाल करके हैश करें और ECDSA NIST P-256 का इस्तेमाल करके, हैश की पुष्टि सार्वजनिक कुंजी से करें.

अगर डिवाइस में 802.11 या ब्लूटूथ पैन (निजी एरिया नेटवर्क) प्रोफ़ाइल जैसे बिना मीटर वाले डेटा कनेक्शन के लिए सहायता शामिल है, तो:

• [C-1-1] डिवाइस को रीबूट करके, ऑफ़लाइन अपडेट के साथ ओटीए डाउनलोड की सुविधा होनी चाहिए.

डिवाइस में लागू करने के दौरान, यह पुष्टि की जानी चाहिए कि ओटीए के बाद, सिस्टम इमेज और उम्मीद के मुताबिक नतीजे की बाइनरी एक जैसी हो. Android 5.1 के बाद से, अपस्ट्रीम Android Open Source Project में ब्लॉक के आधार पर ओटीए लागू करने की सुविधा जोड़ी गई है. यह सुविधा इस ज़रूरी शर्त को पूरा करती है.

साथ ही, डिवाइस पर A/B सिस्टम अपडेट की सुविधा काम करनी चाहिए. AOSP, बूट कंट्रोल एचएएल का इस्तेमाल करके इस सुविधा को लागू करता है.

अगर किसी डिवाइस को रिलीज़ करने के बाद, उसमें कोई गड़बड़ी मिलती है, लेकिन वह डिवाइस के तय किए गए लाइफ़टाइम के अंदर है, तो तीसरे पक्ष के ऐप्लिकेशन के साथ काम करने की सुविधा पर असर पड़ सकता है. इस लाइफ़टाइम को तय करने के लिए, Android के साथ काम करने की सुविधा से जुड़ी टीम से सलाह ली जाती है. ऐसे में:

• [C-2-1] डिवाइस लागू करने वाले व्यक्ति को, उपलब्ध सॉफ़्टवेयर अपडेट के ज़रिए गड़बड़ी को ठीक करना होगा. यह अपडेट, ऊपर बताए गए तरीके के मुताबिक लागू किया जा सकता है.

Android में ऐसी सुविधाएं शामिल हैं जिनकी मदद से, डिवाइस के मालिक के ऐप्लिकेशन (अगर मौजूद हो) से सिस्टम अपडेट को कंट्रोल किया जा सकता है. अगर डिवाइसों के लिए सिस्टम अपडेट सबसिस्टम, android.software.device_admin की रिपोर्ट करता है, तो:

• [C-3-1] SystemUpdatePolicy क्लास में बताए गए व्यवहार को लागू करना ज़रूरी है.

12. दस्तावेज़ में बदलाव का लॉग

इस रिलीज़ में, कंपैटबिलिटी डेफ़िनिशन में हुए बदलावों की खास जानकारी के लिए:

• बदलावों की जानकारी देने वाला दस्तावेज़

13. हमसे संपर्क करें

Android के साथ काम करने वाले डिवाइसों के बारे में जानकारी देने वाले फ़ोरम में शामिल होकर, इस बारे में ज़्यादा जानकारी मांगी जा सकती है. इसके अलावा, अगर आपको लगता है कि दस्तावेज़ में किसी समस्या के बारे में नहीं बताया गया है, तो उसके बारे में भी बताया जा सकता है.