Android 17 के साथ काम करने की सुविधा की परिभाषा

1. परिचय

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

"ज़रूरी है", "ज़रूरी नहीं है", "ज़रूरी है", "ज़रूरी है", "ज़रूरी नहीं है", "करना चाहिए", "नहीं करना चाहिए", "सुझाया गया है", "किया जा सकता है", और "ज़रूरी नहीं है" जैसे शब्दों का इस्तेमाल, आईईटीएफ़ स्टैंडर्ड RFC2119 के मुताबिक किया गया है.

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

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

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

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

इस दस्तावेज़ में लिंक किए गए कई संसाधन, सीधे या परोक्ष तौर पर Android 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 Television डिवाइस
  • A: Android Automotive को लागू करना
  • W: Android Watch में लागू करना
  • टैब: Android टैबलेट पर लागू करना
• शर्त का आईडी
  • जब किसी शर्त को पूरा करना बिलकुल ज़रूरी होता है, तो इस आईडी को 0 के तौर पर सेट किया जाता है.
  • जब किसी शर्त को किसी स्थिति में पूरा करना ज़रूरी होता है, तो पहली शर्त के लिए 1 असाइन किया जाता है. साथ ही, एक ही सेक्शन और एक ही डिवाइस टाइप में, यह संख्या 1 से बढ़ती है.
• ज़रूरी शर्त का आईडी
  • यह आईडी 1 से शुरू होता है और एक ही सेक्शन और एक ही शर्त के तहत, इसमें 1 की बढ़ोतरी होती है.

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

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

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

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

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

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

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

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

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

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

2.2. हाथ में पकड़कर इस्तेमाल किए जाने वाले डिवाइसों के लिए ज़रूरी शर्तें

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

अगर Android डिवाइस में ये सभी शर्तें पूरी होती हैं, तो उसे हैंडहेल्ड डिवाइस के तौर पर क्लासिफ़ाई किया जाता है:

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

इस सेक्शन में दी गई अन्य ज़रूरी शर्तें, 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% या उससे ज़्यादा पर सेट करना ज़रूरी है.

अगर हैंडहेल्ड डिवाइसों में 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 counter trace पैकेट प्रोटोकॉल के मुताबिक वैल्यू रिपोर्ट करना ज़रूरी है.

• [7.1.4.6/H-1-3] डिवाइस के GPU RenderStages के लिए, render stage trace packet proto के मुताबिक, ज़रूरी शर्तों को पूरा करने वाली वैल्यू रिपोर्ट करनी होंगी.

• [7.1.4.6/H-1-4] फ़ॉर्मैट में बताए गए तरीके से, जीपीयू फ़्रीक्वेंसी ट्रेसपॉइंट की जानकारी देना ज़रूरी है: power/gpu_frequency.

हैंडहेल्ड डिवाइसों में सेट किए गए सिस्टम के लिए:

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

• [7.2.1/H-0-1] इसमें तीसरे पक्ष के इनपुट पद्धति संपादक (IME) ऐप्लिकेशन के लिए सहायता शामिल होनी चाहिए.

• [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 हर्ट्ज़ की फ़्रीक्वेंसी तक इवेंट रिपोर्ट करने की सुविधा होनी चाहिए.

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

• [7.3.3/H-2-1] जीएनएसएस के मेज़रमेंट की जानकारी मिलते ही उसे रिपोर्ट करना ज़रूरी है. भले ही, जीपीएस/जीएनएसएस से कैलकुलेट की गई जगह की जानकारी अब तक न दी गई हो.

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

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

• [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] यह सुझाव दिया जाता है कि डिवाइस में, छह डिग्री ऑफ़ फ़्रीडम वाला पोज़ सेंसर काम करे.

हाथ में पकड़कर इस्तेमाल किए जाने वाले ऐसे डिवाइस जिनमें ब्लूटूथ LE की सुविधा काम करती है:

• [7.4.3/H-SR-1] यह सुझाव दिया जाता है कि डिवाइस में, ब्लूटूथ स्मार्ट Data Packet Length Extension की सुविधा काम करे.

अगर डिवाइस में 802.11 (वाई-फ़ाई) का इस्तेमाल किया जाता है, तो:

• [7.4.2.4/H-1-1] में Wi-Fi Passpoint के लिए सहायता शामिल होनी चाहिए.

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

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

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

हमारा सुझाव है कि आप मेज़रमेंट सेटअप के लिए, प्रेज़ेंस कैलिब्रेशन में दिया गया तरीका अपनाएं.

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

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

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

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

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

हैंडहेल्ड डिवाइसों में सेट किए गए सिस्टम के लिए:

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

• [7.6.1/H-0-2] कर्नेल और यूज़रस्पेस के लिए 1 जीबी से कम मेमोरी उपलब्ध होने पर, ActivityManager.isLowRamDevice() के लिए "true" वैल्यू दिखाना ज़रूरी है.

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

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

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

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

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

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

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

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

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

• [7.6.1/H-8-1] अगर डिफ़ॉल्ट डिसप्ले, QHD (जैसे, 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 का एलान करना ज़रूरी है.

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

• [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] एचआईडी कोड की यह सॉफ़्टवेयर मैपिंग उपलब्ध कराना ज़रूरी है:

फ़ंक्शन	मैपिंग	कॉन्टेक्स्ट	व्यवहार
A	एचआईडी यूसेज पेज: 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	HID usage page: 0x0C HID usage: 0x0EA Kernel key: KEY_VOLUMEDOWN Android key: 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 पर सेट करके, Intent ACTION_HEADSET_PLUG ब्रॉडकास्ट करना ज़रूरी है.

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

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

यूएसबी की मदद से कनेक्ट किए गए सहायक डिवाइस के कनेक्ट होने पर, एपीआई 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] अगर यूएसबी ऑडियो टर्मिनल टाइप फ़ील्ड 0x603 है, तो AudioDeviceInfo.TYPE_USB_DEVICE टाइप के डिवाइस और isSink() की भूमिका को सूची में शामिल करना ज़रूरी है.

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

• [7.8.2.2/H-4-6] अगर यूएसबी ऑडियो टर्मिनल टाइप फ़ील्ड 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] यूएसबी-सी ऑडियो पेरिफ़ेरल कनेक्ट करने पर, यूएसबी डिस्क्रिप्टर की गिनती करने, टर्मिनल टाइप की पहचान करने, और 1,000 मि॰से॰ से कम समय में Intent ACTION_HEADSET_PLUG ब्रॉडकास्ट करने का सुझाव दिया जाता है.

हैंडहेल्ड डिवाइस में सेट किए हुए सिस्टम के लिए ज़रूरी है कि वे android.hardware.audio.output और android.hardware.microphone का एलान करें. इसके लिए, सेक्शन 5.6 में आरटीएल और टीटीएल की ज़रूरी शर्तें देखें.

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

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

• [7.10/H] SHOULD position the placement of the actuator near the location where the device is typically held or touched by hands.

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

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

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

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

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

• [7.10/H]^* को हैप्टिक कॉन्स्टेंट के लिए, क्वालिटी असेसमेंट करना चाहिए.

• [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 प्रोफ़ाइल (AAC+)
• [5.1/H-0-5] AAC ELD (बेहतर लो डिले एएसी)

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

• [5.2/H-0-1] H.264 एवीसी
• [5.2/H-0-2] VP8
• [5.2/H-0-3] AV1

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

• [5.3/H-0-1] H.264 एवीसी
• [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] ऐप्लिकेशन में, एसडीके के दस्तावेज़ों में बताए गए ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE, और ACTION_CREATE_DOCUMENT इंटेंट को हैंडल करने की सुविधा होनी चाहिए. साथ ही, DocumentsProvider एपीआई का इस्तेमाल करके, दस्तावेज़ उपलब्ध कराने वाली कंपनी के डेटा को ऐक्सेस करने की सुविधा होनी चाहिए.

[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 API के ज़रिए तुरंत ऐक्सेस किया जा सकता है.

• [3.8.1/H-SR-3] हमारा सुझाव है कि डिवाइस में डिफ़ॉल्ट लॉन्चर ऐप्लिकेशन शामिल किया जाए. यह ऐप्लिकेशन, ऐप्लिकेशन के आइकॉन के लिए बैज दिखाता है.

• [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 के लिए, Notification.Remoteinput.Builder.setChoices की ओर से दिखाए गए जवाबों के साथ-साथ true को भी दिखाया जाए.

• [3.8.4/H-SR-1] डिवाइस पर Assistant को लागू करने का सुझाव दिया जाता है, ताकि Assistant की कार्रवाई को हैंडल किया जा सके.

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

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

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

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

• [3.8.3.1/H-0-1] लॉकस्क्रीन पर, लाइव अपडेट के प्रमोशन वाली सूचना को प्रमुखता से दिखाने वाली जगह पर दिखाना ज़रूरी है.

• [3.8.3.1/H-0-12] सूचनाओं के स्टैक में सबसे ऊपर स्क्रीन पर सबसे ऊपर दिखने वाली सूचना दिखनी चाहिए. साथ ही, रंगीन सूचनाओं के ऊपर दिखनी चाहिए (जहां setColorized, true है). ऐसा तब होना चाहिए, जब प्रमोट की गई लाइव अपडेट की सूचना, अन्य सूचनाओं के बीच दिखाई जाती है.

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

• [3.8.3.1/H-0-2] प्रमोट की गई लाइव अपडेट सूचना को, बड़ी की गई स्थिति में दिखाना ज़रूरी है.

• [3.8.3.1/H-0-3] ऊपर दी गई बड़ी की गई सूचना को छोटा करने के लिए, उपयोगकर्ता को कोई सुविधा नहीं देनी चाहिए.

• [3.8.3.1/H-0-4] यह ज़रूरी है कि प्रमोट की गई लाइव अपडेट सूचना में, टेक्स्ट कॉन्टेंट की बुनियादी स्टाइल (बोल्ड, इटैलिक, और अंडरलाइन) दिखाई जाएं. ये स्टाइल StyleSpan या UnderlineSpan से उपलब्ध कराई जाती हैं.

• [3.8.3.1/H-0-5] MUST display only standard action objects (via Notification.Action), and MUST hide non-standard action objects such as input boxes, reply buttons, and contextual actions (via addRemoteInput() and setContextual()) in a Promoted Live Update Notification, even when the notification contains them.

• [3.8.3.1/H-0-6] एसडीके के दस्तावेज़ में, प्रमोट की गई लाइव अपडेट सूचना के लिए, कॉम्पैक्ट रिप्रेजेंटेशन दिखाना ज़रूरी है. इसे स्टेटस चिप भी कहा जाता है. इसमें Notification.getSmallIcon() शामिल होना ज़रूरी है.

  • [3.8.3.1/H-0-7] कॉम्पैक्ट रिप्रेजेंटेशन के लिए, अन्य फ़ील्ड वैकल्पिक होते हैं. हालांकि, जब भी कॉम्पैक्ट रिप्रेजेंटेशन को बड़ा किया जा सकता है, तब Notification.getShortCriticalText() को दिखाना ज़रूरी है. ऐसा तब होता है, जब Notification.getShortCriticalText मौजूद न हो. अगर Notification.getShortCriticalText मौजूद है, तो Notification.when को दिखाना ज़रूरी है.

  • [3.8.3.1/H-0-8] जब एक से ज़्यादा लाइव अपडेट की सूचनाएं मौजूद हों, तो स्टेटस बार में उनमें से कम से कम एक सूचना को कॉम्पैक्ट तरीके से दिखाना ज़रूरी है.

  • [3.8.3.1/H-0-9] जब उपयोगकर्ता कॉम्पैक्ट वर्शन पर टैप करता है, तो उसे इससे जुड़ी सूचना दिखनी चाहिए (सुझाया गया) या इससे जुड़ा ऐप्लिकेशन खुलना चाहिए (Notification.contentIntent के ज़रिए).

  • [3.8.3.1/H-0-13] नोटिफ़िकेशन शेड में उपलब्ध कॉन्टेंट और उससे जुड़ी सूचना में मौजूद कॉन्टेंट एक जैसा होना चाहिए.

• [3.8.3.1/H-0-10] उपयोगकर्ता को किसी ऐप्लिकेशन की सूचनाओं को प्रमोट किए गए डिसप्ले पर दिखाने की सुविधा को बंद और चालू करने का विकल्प देना ज़रूरी है.

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

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

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

अगर हैंडहेल्ड डिवाइस में सेट किए गए सिस्टम में, 'ठीक है Google' सुविधा काम करती है, तो:

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

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

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

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

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

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

• [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 API के ज़रिए रजिस्टर की है.

• [3.8.16/H-1-6] डिवाइसों को उपयोगकर्ता के लिए उपलब्ध सुविधाओं को इस तरह से सटीक तौर पर रेंडर करना होगा:

  • अगर डिवाइस में config_supportsMultiWindow=true सेट है और ऐप्लिकेशन, ControlsProviderService के एलान में मेटाडेटा META_DATA_PANEL_ACTIVITY का एलान करता है, तो ऐप्लिकेशन को उपयोगकर्ता के लिए उपलब्ध इस सुविधा में, एपीआई के हिसाब से मान्य गतिविधि का कॉम्पोनेंट नेम शामिल करना होगा.
  • अगर ऐप्लिकेशन, मेटाडेटा 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 की सुविधाओं के बराबर या उनसे बेहतर होनी चाहिए. साथ ही, ये सेवाएं उन भाषाओं में उपलब्ध होनी चाहिए जिनके लिए पहले से इंस्टॉल किए गए टेक्स्ट-टू-स्पीच इंजन काम करते हैं. ये सेवाएं, TalkBack ओपन सोर्स प्रोजेक्ट में दी गई सुलभता सेवाओं के तौर पर उपलब्ध होनी चाहिए.

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

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

• [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 डीपी होनी चाहिए.

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

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

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

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

• [7.5.4/H-1-2] एसडीके में बताए गए तरीके के मुताबिक, वीडियो मोड में कैमरा लॉन्च करने के 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 से पार्स किए गए इंटेंट की ऐक्टिविटी शुरू करनी चाहिए.

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

• [8.1/H-0-1] फ़्रेम के इंतज़ार का समय एक जैसा होना चाहिए. फ़्रेम रेंडर होने में लगने वाले समय में अंतर या फ़्रेम रेंडर होने में देरी, एक सेकंड में पांच फ़्रेम से ज़्यादा बार नहीं होनी चाहिए. साथ ही, यह एक सेकंड में एक फ़्रेम से कम होनी चाहिए.

• [8.1/H-0-2] यूज़र इंटरफ़ेस की लेटेन्सी. डिवाइस में सेट किए गए सिस्टम के लिए, यह ज़रूरी है कि उपयोगकर्ता को कम समय में बेहतर अनुभव मिले. इसके लिए, Android Compatibility Test Suite (CTS) में बताई गई 10,000 लिस्ट एंट्री की सूची को 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] उपयोगकर्ता को ऐसे सभी ऐप्लिकेशन दिखाने की सुविधा देना ज़रूरी है जिन्हें ऐप्लिकेशन स्टैंडबाय और बैटरी बचाने वाले डोज़ मोड से छूट मिली है.

हैंडहेल्ड डिवाइसों में सेट किए गए सिस्टम के लिए:

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

• [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] उपयोगकर्ता को ऐसा अफ़ोर्डेंस देना ज़रूरी है जिससे वह फ़ोरग्राउंड में चल रही सभी सेवाओं या उपयोगकर्ता की ओर से शुरू किए गए कामों को देख सके. इनमें, इन सेवाओं के शुरू होने से लेकर अब तक की अवधि भी शामिल होनी चाहिए. इस बारे में एसडीके के दस्तावेज़ में बताया गया है.

• [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 इंटेंट के जवाब में, ऐसे ऐप्लिकेशन को ऐक्सेस करने की अनुमति दे सकें या अनुमति वापस ले सकें.

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

• [9.1/H-0-2] यह ज़रूरी है कि उस ऐप्लिकेशन के लिए, ACCESS_FINE_LOCATION को डिफ़ॉल्ट के तौर पर अनुमति न दी जाए.

डिवाइसों में android.software.credentials के साथ काम करने की सुविधा होनी चाहिए. साथ ही:

• [9/H-0-2] क्रेडेंशियल मैनेजर के लिए पसंदीदा सेवा देने वाली कंपनी को चुनने की अनुमति देने के लिए, android.settings.CREDENTIAL_PROVIDER इंटेंट का पालन करना ज़रूरी है. यह सेवा देने वाली कंपनी, जानकारी अपने-आप भरने की सुविधा के लिए चालू हो जाएगी. साथ ही, Credential Manager में डाले गए नए क्रेडेंशियल सेव करने के लिए, यह डिफ़ॉल्ट जगह भी होगी.

• [9/H-0-3] कम से कम दो क्रेडेंशियल प्रोवाइडर के साथ काम करना चाहिए और सेटिंग ऐप्लिकेशन में उपयोगकर्ताओं को यह सुविधा देनी चाहिए कि वे प्रोवाइडर को चालू या बंद कर सकें.

• [9.5/H-1-1] Android 16 में इस ज़रूरी शर्त को हटा दिया गया है.

हैंडहेल्ड डिवाइसों में सेट किए गए सिस्टम के लिए:

• [9.11/H-0-2] कीस्टोर को लागू करने के लिए, अलग से एक्ज़ीक्यूशन एनवायरमेंट में बैक अप लेना ज़रूरी है.

• [9.11/H-0-3] यह ज़रूरी है कि डिवाइस में आरएसए, एईएस, ईसीडीएसए, और एचएमएसी क्रिप्टोग्राफ़िक एल्गोरिदम के साथ-साथ MD5, SHA-1, और SHA-2 फ़ैमिली हैश फ़ंक्शन लागू किए गए हों. ऐसा इसलिए, ताकि Android Keystore सिस्टम के साथ काम करने वाले एल्गोरिदम को सही तरीके से इस्तेमाल किया जा सके. ये एल्गोरिदम, कर्नल और उससे ऊपर के लेयर पर चलने वाले कोड से सुरक्षित तरीके से अलग किए गए क्षेत्र में काम करते हैं. सुरक्षित आइसोलेशन को उन सभी संभावित तरीकों को ब्लॉक करना चाहिए जिनसे कर्नेल या यूज़रस्पेस कोड, आइसोलेट किए गए एनवायरमेंट की इंटरनल स्थिति को ऐक्सेस कर सकता है. इसमें डीएमए भी शामिल है. अपस्ट्रीम Android Open Source Project (AOSP), Trusty को लागू करके इस ज़रूरी शर्त को पूरा करता है. हालांकि, ARM TrustZone पर आधारित कोई अन्य समाधान या हाइपरवाइज़र पर आधारित आइसोलेशन को सुरक्षित तरीके से लागू करने वाला कोई ऐसा समाधान जिसे तीसरे पक्ष ने समीक्षा की हो, इसके विकल्प हैं.

• [9.11/H-0-4] लॉक स्क्रीन पर पुष्टि करने की प्रोसेस, अलग किए गए एक्ज़ीक्यूशन एनवायरमेंट में पूरी होनी चाहिए. साथ ही, पुष्टि हो जाने के बाद ही, पुष्टि से जुड़ी कुंजियों का इस्तेमाल करने की अनुमति दी जानी चाहिए. लॉक स्क्रीन के क्रेडेंशियल को इस तरह से सेव किया जाना चाहिए कि सिर्फ़ आइसोलेटेड एक्ज़ीक्यूशन एनवायरमेंट, लॉक स्क्रीन की पुष्टि कर सके. अपस्ट्रीम Android Open Source Project, Gatekeeper हार्डवेयर ऐब्स्ट्रैक्शन लेयर (HAL) और Trusty उपलब्ध कराता है. इनका इस्तेमाल इस ज़रूरी शर्त को पूरा करने के लिए किया जा सकता है.

• [9.11/H-0-5] यह ज़रूरी है कि डिवाइस में कुंजी की पुष्टि करने की सुविधा काम करती हो. इस सुविधा में, पुष्टि करने के लिए इस्तेमाल की जाने वाली कुंजी को सुरक्षित हार्डवेयर से सुरक्षित किया जाता है. साथ ही, पुष्टि करने की प्रोसेस को सुरक्षित हार्डवेयर में पूरा किया जाता है. अटेस्टेशन साइनिंग कुंजियों को डिवाइस के स्थायी आइडेंटिफ़ायर के तौर पर इस्तेमाल नहीं किया जाना चाहिए.

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

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

• [9.11/H-1-1] उपयोगकर्ता को सबसे कम स्लीप टाइमआउट चुनने की अनुमति देना ज़रूरी है. यह अनलॉक से लॉक होने की स्थिति में ट्रांज़िशन का समय है. यह 15 सेकंड या इससे कम होना चाहिए.

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

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

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

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

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

• [9.5/H-4-1] Android 16 में इस ज़रूरी शर्त को हटा दिया गया है.

• [9.5/H-4-2] Android 16 में इस ज़रूरी शर्त को हटा दिया गया है.

वे सेटिंग जिन पर पाबंदी लगाई गई है

पाबंदी वाली सेटिंग में, उपयोगकर्ता को चेतावनियां दिखती हैं. साथ ही, उपयोगकर्ता से पुष्टि करने के लिए कहा जाता है, ताकि उन ऐप्लिकेशन के लिए अनुमतियां दी जा सकें जो इनमें से कोई एक काम करते हैं:

• किसी ऐसे ऐप्लिकेशन से डाउनलोड किया गया हो जिसे "ऐप्लिकेशन स्टोर" के तौर पर PackageManager ने PACKAGE_DOWNLOADED_FILE के तौर पर नहीं पहचाना है. उदाहरण के लिए, कोई मैसेजिंग ऐप्लिकेशन या ब्राउज़र.

• लोकल फ़ाइल से इंस्टॉल किया गया हो (उदाहरण के लिए, ऐप्लिकेशन को साइडलोड किया गया हो) PackageManager ने इसकी पहचान PACKAGE_SOURCE_LOCAL_FILE के तौर पर की हो.

नीचे [9.8/H-0-5] में दी गई, लागू की गई अनुमतियों और उनसे जुड़े किसी भी आइडेंटिफ़ायर के लिए.

इस तरह के ऐप्लिकेशन को "शामिल किए गए ऐप्लिकेशन" के तौर पर लेबल किया जाता है. ऐसा इस सेक्शन में दी गई ज़रूरी शर्तों के लिए किया जाता है.

डिवाइस में सेट किए गए सिस्टम के लिए:

• [9.8/H-0-1] ऊपर बताई गई पाबंदियों वाली सेटिंग को इन पर लागू करना ज़रूरी है:

  • खास अनुमतियां

    • सुलभता (AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE)
    • सूचना को सुनने की सुविधा (AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS)
    • डिवाइस के एडमिन ऐप्लिकेशन (Manifest.permission.BIND_DEVICE_ADMIN)
    • दूसरे ऐप्लिकेशन के ऊपर दिखाना (AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW)
    • इस्तेमाल से जुड़े डेटा का ऐक्सेस (AppOpsManager.OPSTR_GET_USAGE_STATS)

  • भूमिकाएं (डिफ़ॉल्ट ऐप्लिकेशन)

    • Dialer (RoleManager.ROLE_DIALER)
    • मैसेज (एसएमएस) (RoleManager.ROLE_SMS)

  • रनटाइम अनुमतियां

    • एसएमएस भेजने में लगने वाला समय (Manifest.permission_group.SMS)

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

• [9.8/H-0-3] यह पक्का करना ज़रूरी है कि जिन ऐप्लिकेशन पर नीति लागू होती है उनमें से हर ऐप्लिकेशन के लिए, उपयोगकर्ता की पुष्टि की गई हो. ऐसा तब किया जाना चाहिए, जब नीति के तहत लागू की गई अनुमतियां दी जा सकती हों.

• [9.8/H-0-4] EnhancedConfirmationManager API का इस्तेमाल करके, Covered Application के AppInfo पेज से पाबंदी वाली सेटिंग को चालू करने के लिए, उपयोगकर्ता की पुष्टि की अनुमति सिर्फ़ तब दी जानी चाहिए, जब उपयोगकर्ता ने इसकी पुष्टि कर दी हो.

• [9.8/H-0-5] सभी खास अनुमतियों के लिए, EnhancedConfirmationManager के साथ इंटिग्रेट करने और इसे कॉल करने का सुझाव दिया जाता है, ताकि यह डाइनैमिक तरीके से तय किया जा सके कि वे प्रतिबंधित सेटिंग हैं या नहीं.

  • अलार्म और रिमाइंडर: AppOpsManager.OPSTR_SCHEDULE_EXACT_ALARM
  • सभी फ़ाइलों का ऐक्सेस: AppOpsManager.OPSTR_MANAGE_EXTERNAL_STORAGE
  • अन्य ऐप्लिकेशन के ऊपर दिखाएं: AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW
  • अनजान ऐप्लिकेशन इंस्टॉल करने की अनुमति: AppOpsManager.OPSTR_REQUEST_INSTALL_PACKAGES
  • मीडिया मैनेज करें: AppOpsManager.OPSTR_MANAGE_MEDIA
  • सिस्टम सेटिंग में बदलाव करने की अनुमति: AppOpsManager.OPSTR_WRITE_SETTINGS
  • पिक्चर में पिक्चर: AppOpsManager.OPSTR_PICTURE_IN_PICTURE
  • स्क्रीन चालू करें: AppOpsManager.OPSTR_TURN_SCREEN_ON
  • फ़ुल-स्क्रीन सूचनाएं: AppOpsManager.OPSTR_USE_FULL_SCREEN_INTENT
  • वाई-फ़ाई कंट्रोल: AppOpsManager.OPSTR_CHANGE_WIFI_STATE
  • सुलभता: AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE
  • सूचना को सुनने की सुविधा: AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS
  • इस्तेमाल से जुड़े डेटा का ऐक्सेस: AppOpsManager.OPSTR_GET_USAGE_STATS
  • डिवाइस एडमिन: Manifest.permission.BIND_DEVICE_ADMIN
  • परेशान न करें: Manifest.permission.MANAGE_NOTIFICATIONS

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] हॉटवर्ड का पता लगाने वाली सेवा को, आठ सेकंड से ज़्यादा पुराना बफ़र किया गया माइक्रोफ़ोन ऑडियो नहीं देना चाहिए.

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

• [9.8/H-1-6] हॉटवर्ड का पता लगाने वाली सेवा को, हॉटवर्ड का पता चलने पर 100 बाइट से ज़्यादा डेटा (ऑडियो स्ट्रीम को छोड़कर) ट्रांसमिट करने की अनुमति नहीं देनी चाहिए.

• [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 हार्डवेयर-ट्रिगर इवेंट में रीस्टार्ट किया जाए. इनमें से जो भी पहले हो.

अगर डिवाइस में ऐसे ऐप्लिकेशन शामिल हैं जो System API 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() से मिले माइक्रोफ़ोन का इस्तेमाल करने वाले हाल ही के और चालू ऐप्लिकेशन की सूची दिखाना ज़रूरी है. साथ ही, उनसे जुड़े एट्रिब्यूशन मैसेज भी दिखाने ज़रूरी हैं.

• [9.8.2/H-4-3] सिस्टम ऐप्लिकेशन के लिए, माइक्रोफ़ोन इंडिकेटर को नहीं छिपाना चाहिए. इन ऐप्लिकेशन के यूज़र इंटरफ़ेस दिखते हैं या ये सीधे तौर पर उपयोगकर्ता से इंटरैक्ट करते हैं.

• [9.8.2/H-4-4] 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() से मिले जवाब के तौर पर, हाल ही में इस्तेमाल किए गए और ऐक्टिव ऐप्लिकेशन को कैमरा इस्तेमाल करते हुए दिखाना ज़रूरी है. साथ ही, उनसे जुड़े एट्रिब्यूशन मैसेज भी दिखाने ज़रूरी हैं.

• [9.8.2/H-5-3] सिस्टम ऐप्लिकेशन के लिए, कैमरा इंडिकेटर को नहीं छिपाना चाहिए. इन ऐप्लिकेशन के यूज़र इंटरफ़ेस दिखते हैं या ये सीधे तौर पर उपयोगकर्ता से इंटरैक्ट करते हैं.

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

• [9.10/H-1-1] Android बूट सीक्वेंस के दौरान माउंट किए गए सभी रीड-ओनली पार्टिशन की पुष्टि करना ज़रूरी है. साथ ही, VBMeta डाइजेस्ट में, पुष्टि किए गए इन सभी पार्टिशन को शामिल करना ज़रूरी है.

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

हैंडहेल्ड डिवाइस में सेट किए गए सिस्टम के लिए (* टैबलेट के लिए लागू नहीं):

• [6.1/H-0-1]* यह ज़रूरी है कि डिवाइस, शेल कमांड cmd testharness के साथ काम करता हो.

हैंडहेल्ड डिवाइसों में सेट किए गए सिस्टम के लिए:

• Perfetto

  • [6.1/H-0-2] शेल उपयोगकर्ता के लिए, /system/bin/perfetto बाइनरी उपलब्ध कराना ज़रूरी है. यह बाइनरी, cmdline के साथ काम करती हो और परफ़ेक्टो के दस्तावेज़ के मुताबिक हो.

  • [6.1/H-0-3] perfetto बाइनरी को इनपुट के तौर पर, protobuf कॉन्फ़िगरेशन स्वीकार करना चाहिए. यह कॉन्फ़िगरेशन, परफ़ेक्टो के दस्तावेज़ में तय किए गए स्कीमा के मुताबिक होना चाहिए.

  • [6.1/H-0-4] perfetto बाइनरी को आउटपुट के तौर पर, एक ऐसा प्रोटोबफ़ ट्रेस लिखना होगा जो परफ़ेक्टो के दस्तावेज़ में तय किए गए स्कीमा के मुताबिक हो.

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

  • [6.1/H-0-6] Perfetto traced daemon डिफ़ॉल्ट रूप से चालू होना चाहिए (सिस्टम प्रॉपर्टी persist.traced.enable).

2.2.7. हाथ में पकड़कर इस्तेमाल किए जाने वाले डिवाइसों के लिए मीडिया परफ़ॉर्मेंस क्लास

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

2.2.7.1. मीडिया

अगर हैंडहेल्ड डिवाइसों पर लागू किए गए android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS के लिए, शून्य के अलावा कोई अन्य वैल्यू मिलती है, तो:

• यह ज़रूरी है कि डिवाइस, Android 17 CDD के सेक्शन 2.2.7.1 में बताई गई मीडिया से जुड़ी सभी ज़रूरी शर्तों को पूरा करता हो. ये शर्तें, डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से तय की जाती हैं.

• [5.1/H-1-1] डिवाइस को, मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, CodecCapabilities.getMaxSupportedInstances() और VideoCapabilities.getSupportedPerformancePoints() तरीकों का इस्तेमाल करके, किसी भी कोडेक कॉम्बिनेशन में एक साथ चलाए जा सकने वाले ज़्यादा से ज़्यादा हार्डवेयर वीडियो डिकोडर सेशन का विज्ञापन दिखाना होगा.

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

• [5.1/H-1-3] डिवाइस को, CodecCapabilities.getMaxSupportedInstances() और VideoCapabilities.getSupportedPerformancePoints() तरीकों का इस्तेमाल करके, किसी भी कोडेक कॉम्बिनेशन में एक साथ चलाए जा सकने वाले हार्डवेयर वीडियो एनकोडर सेशन की ज़्यादा से ज़्यादा संख्या का विज्ञापन दिखाना होगा. यह संख्या, डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से तय की जाती है.

• [5.1/H-1-4] डिवाइस में हार्डवेयर वीडियो एन्कोडर सेशन (AVC, HEVC, VP9, AV1 या बाद के वर्शन), एक साथ कई इंस्टेंस, और फ़्रेम ड्रॉप की सुविधा होनी चाहिए. यह सुविधा, डिवाइस के लिए तय किए गए मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से होनी चाहिए.

• [5.1/H-1-5] डिवाइस को, किसी भी कोडेक कॉम्बिनेशन में एक साथ चलने वाले ज़्यादा से ज़्यादा हार्डवेयर वीडियो एनकोडर और डिकोडर सेशन का विज्ञापन दिखाना होगा. इसके लिए, डिवाइस के लिए तय किए गए मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से CodecCapabilities.getMaxSupportedInstances() और VideoCapabilities.getSupportedPerformancePoints() तरीकों का इस्तेमाल करना होगा.

• [5.1/H-1-6] डिवाइस में हार्डवेयर वीडियो डिकोडर और हार्डवेयर वीडियो एन्कोडर सेशन (AVC, HEVC, VP9, AV1 या बाद के वर्शन) के साथ-साथ, डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से फ़्रेम ड्रॉप होने चाहिए.

• [5.1/H-1-7] डिवाइस पर लोड होने पर, सभी हार्डवेयर वीडियो एन्कोडर के लिए, 1080 पिक्सल या इससे कम रिज़ॉल्यूशन वाले वीडियो एन्कोडिंग सेशन के लिए, कोडेक शुरू होने में लगने वाला समय, डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से होना चाहिए.

• [5.1/H-1-8] सभी ऑडियो एन्कोडर के लिए, 128 केबीपीएस या उससे कम बिटरेट वाले ऑडियो एन्कोडिंग सेशन के लिए, कोडेक शुरू होने में लगने वाला समय कम होना चाहिए. ऐसा तब होना चाहिए, जब डिवाइस पर मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से लोड हो.

• [5.1/H-1-9] डिवाइस में सुरक्षित हार्डवेयर वीडियो डिकोडर के दो सेशन (AVC, HEVC, VP9, AV1 या बाद के वर्शन) होने चाहिए. साथ ही, डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से फ़्रेम ड्रॉप होने चाहिए.

• [5.1/H-1-10] यह ज़रूरी है कि डिवाइस में, असुरक्षित हार्डवेयर वीडियो डिकोडर के तीन इंस्टेंस और सुरक्षित हार्डवेयर वीडियो डिकोडर का एक इंस्टेंस (कुल चार इंस्टेंस) एक साथ काम करें. साथ ही, डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, AVC, HEVC, VP9, AV1 या बाद के वर्शन के रिज़ॉल्यूशन और फ़्रेम ड्रॉप की सुविधा काम करे.

• [5.1/H-1-11] यह ज़रूरी है कि डिवाइस में मौजूद हर हार्डवेयर AVC, HEVC, VP9 या AV1 डिकोडर के लिए, उससे जुड़े सुरक्षित डिकोडर का इस्तेमाल किया जाए. यह डिकोडर, डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के मुताबिक होना चाहिए.

• [5.1/H-1-12] डिवाइस पर लोड होने पर, सभी हार्डवेयर वीडियो डिकोडर के लिए, 1080 पिक्सल या इससे कम रिज़ॉल्यूशन वाले वीडियो डिकोडिंग सेशन के लिए, कोडेक शुरू होने में लगने वाला समय, डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से होना चाहिए.

• [5.1/H-1-13] डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, लोड होने पर सभी ऑडियो डिकोडर के लिए, 128 केबीपीएस या इससे कम बिटरेट वाले ऑडियो डिकोडिंग सेशन के लिए, कोडेक शुरू होने में लगने वाला समय कम होना चाहिए.

• [5.1/H-1-14] यह ज़रूरी है कि डिवाइस में, AV1 हार्डवेयर डिकोडर प्रोफ़ाइल, सुविधा, और डिसप्ले का तरीका काम करता हो. यह डिवाइस के लिए तय किए गए मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से होना चाहिए.

• [5.1/H-1-15] डिवाइस में कम से कम एक ऐसा हार्डवेयर वीडियो डिकोडर होना चाहिए जो 4K60 को सपोर्ट करता हो. यह डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से होना चाहिए.

• [5.1/H-1-16] डिवाइस में कम से कम एक ऐसा हार्डवेयर वीडियो एनकोडर होना चाहिए जो 4K60 को सपोर्ट करता हो. यह डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के मुताबिक होना चाहिए.

• [5.1/H-1-17] डिवाइस में कम से कम एक ऐसा हार्डवेयर इमेज डिकोडर होना चाहिए जो AVIF बेसलाइन प्रोफ़ाइल के साथ काम करता हो. यह डिवाइस के Media Performance Class Level के हिसाब से होना चाहिए.

• [5.1/H-1-18] इसमें AV1 एन्कोडर होना चाहिए. यह एन्कोडर, डिवाइस के लिए तय की गई मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से बिटरेट, फ़्रेम प्रति सेकंड, और रिज़ॉल्यूशन की ज़रूरी शर्तों को पूरा करता हो.

• [5.1/H-1-19] डिवाइस में 10-बिट (एचडीआर) हार्डवेयर वीडियो डिकोडर और हार्डवेयर वीडियो एन्कोडर सेशन (AVC, HEVC, VP9, AV1 या बाद के वर्शन) के तीन इंस्टेंस होने चाहिए. साथ ही, डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से रिज़ॉल्यूशन और फ़्रेम ड्रॉप होने चाहिए.

• [5.1/H-1-20] यह ज़रूरी है कि डिवाइस पर मौजूद सभी हार्डवेयर AV1 और HEVC एन्कोडर के लिए, Feature_HdrEditing सुविधा काम करती हो. ये एन्कोडर, डिवाइस के लिए तय किए गए मीडिया परफ़ॉर्मेंस क्लास लेवल के मुताबिक होने चाहिए.

• [5.1/H-1-21] यह ज़रूरी है कि डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, सभी हार्डवेयर वीडियो डिकोडर (AVC, HEVC, VP9, AV1 या बाद के वर्शन) के लिए FEATURE_DynamicColorAspect काम करे.

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

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

• [5.3/H-1-1] डिवाइस को, वीडियो सेशन की परफ़ॉर्मेंस और फ़्रेम ड्रॉप से जुड़ी ज़रूरी शर्तों को पूरा करना होगा. ये शर्तें, डिवाइस के लिए तय की गई मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से तय की जाती हैं.

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

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

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

• [5.6/H-1-3] डिवाइस के लिए तय किए गए मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, 24-बिट ऑडियो की ज़रूरी शर्तों को पूरा करना ज़रूरी है.

• [5.6/H-1-4] डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, चार या इससे ज़्यादा चैनल वाले यूएसबी ऑडियो डिवाइसों के साथ काम करना चाहिए.

• [5.6/H-1-5] क्लास के मुताबिक MIDI डिवाइसों के साथ काम करना ज़रूरी है. साथ ही, डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, MIDI फ़ीचर फ़्लैग का एलान करना ज़रूरी है.

• [5.6/H-1-9] डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, कम से कम 12 चैनल मिक्सिंग की सुविधा उपलब्ध होनी चाहिए.

• [5.6/H-SR-1] यह सुझाव दिया जाता है कि डिवाइस, ऑडियो चैनल मिक्सिंग की सुविधा के साथ काम करे. यह सुविधा, डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से काम करती है.

• [5.7/H-1-2] MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL के साथ काम करना ज़रूरी है. साथ ही, डिवाइस के लिए डिक्रिप्ट करने की क्षमताएं, मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से होनी चाहिए.

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

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

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

2.2.7.2. कैमरा

अगर हैंडहेल्ड डिवाइसों पर लागू किए गए android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS के लिए, शून्य के अलावा कोई अन्य वैल्यू मिलती है, तो:

• डिवाइस के लिए तय किए गए मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, Android 17 CDD के सेक्शन 2.2.7.2 में बताई गई कैमरे की ज़रूरी शर्तों को पूरा करना ज़रूरी है.

अगर हैंडहेल्ड डिवाइसों पर लागू किए गए android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS के लिए, शून्य के अलावा कोई अन्य वैल्यू मिलती है, तो:

• [7.5/H-1-1] डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, पीछे की ओर लगे मुख्य कैमरे के रिज़ॉल्यूशन और वीडियो कैप्चर करने की ज़रूरी शर्तों को पूरा करना ज़रूरी है.

• [7.5/H-1-2] डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, सामने की ओर लगे मुख्य कैमरे के रिज़ॉल्यूशन और वीडियो कैप्चर करने की ज़रूरी शर्तों को पूरा करना ज़रूरी है.

• [7.5/H-1-3] डिवाइस के लिए, android.info.supportedHardwareLevel प्रॉपर्टी की ज़रूरी शर्तों को पूरा करना ज़रूरी है. ये शर्तें, डिवाइस के लिए तय किए गए मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से होनी चाहिए.

• [7.5/H-1-4] डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, दोनों प्राइमरी कैमरों के लिए CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME की सुविधा उपलब्ध होनी चाहिए.

• [7.5/H-1-5] डिवाइस को, Camera2 API के ज़रिए JPEG फ़ोटो कैप्चर करने में लगने वाले समय से जुड़ी ज़रूरी शर्तों को पूरा करना होगा. ये शर्तें, डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से तय की जाती हैं.

• [7.5/H-1-6] डिवाइस के लिए, कैमरा2 के चालू होने में लगने वाले समय से जुड़ी ज़रूरी शर्तों को पूरा करना ज़रूरी है. ये शर्तें, डिवाइस के लिए तय की गई मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से तय की जाती हैं.

• [7.5/H-1-8] डिवाइस को, RAW फ़ॉर्मैट में फ़ोटो कैप्चर करने से जुड़ी ज़रूरी शर्तों को पूरा करना होगा. ये शर्तें, डिवाइस के लिए तय किए गए मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से तय की जाती हैं.

• [7.5/H-1-9] डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, पीछे की ओर लगे मुख्य कैमरे के लिए, हाई स्पीड वीडियो कैप्चर करने की ज़रूरी शर्तों को पूरा करना ज़रूरी है.

• [7.5/H-1-10] डिवाइस के लिए तय किए गए मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, ज़ूम रेशियो से जुड़ी ज़रूरी शर्तों को पूरा करना ज़रूरी है.

• [7.5/H-1-11] डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, प्राइमरी कैमरों पर एक साथ आगे और पीछे के कैमरे से स्ट्रीमिंग करने की सुविधा लागू करना ज़रूरी है.

• [7.5/H-1-12] डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, मुख्य बैक कैमरे के लिए वीडियो स्टेबलाइज़ेशन की सुविधा उपलब्ध होनी चाहिए.

• [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] यह ज़रूरी है कि डिवाइस के प्राइमरी कैमरे, चेहरे का पता लगाने की सुविधा के साथ काम करते हों. ये कैमरे, डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से होने चाहिए.

• [7.5/H-1-18] डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, मुख्य रियर और मुख्य फ़्रंट कैमरे के लिए JPEG_R की सुविधा काम करनी चाहिए.

• [7.5/H-1-19] डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, मुख्य रियर कैमरे के लिए CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION की सुविधा उपलब्ध होनी चाहिए.

• [7.5/H-1-20] यह ज़रूरी है कि डिवाइस के नेटिव कैमरा ऐप्लिकेशन में, डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, डिफ़ॉल्ट रूप से मुख्य रियर और मुख्य फ़्रंट कैमरे के लिए JPEG_R आउटपुट हो.

2.2.7.3. हार्डवेयर

अगर हैंडहेल्ड डिवाइसों पर लागू किए गए android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS के लिए, शून्य के अलावा कोई अन्य वैल्यू मिलती है, तो:

• डिवाइस के लिए, 2.2.7.3 में बताई गई हार्डवेयर से जुड़ी ज़रूरी शर्तों को पूरा करना ज़रूरी है. ये शर्तें, डिवाइस के लिए तय किए गए मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से होनी चाहिए.

अगर हैंडहेल्ड डिवाइसों पर लागू किए गए android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS के लिए, शून्य के अलावा कोई अन्य वैल्यू मिलती है, तो:

• [7.1.1.1/H-1-1] इस आइटम को जान-बूझकर नहीं चुना गया है.

• [7.1.1.1/H-2-1] डिवाइस का स्क्रीन रिज़ॉल्यूशन, मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से होना चाहिए.

• [7.1.1.3/H-1-1] इस आइटम को जान-बूझकर नहीं चुना गया है.

• [7.1.1.3/H-2-1] स्क्रीन की डेंसिटी, डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से होनी चाहिए.

• [7.1.1.3/H-3-1] डिवाइस के लिए तय की गई मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, एचडीआर डिसप्ले की ज़रूरी शर्तों को पूरा करना ज़रूरी है.

• [7.6.1/H-1-1] इस आइटम को जान-बूझकर नहीं चुना गया है.

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

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

अगर हैंडहेल्ड डिवाइसों पर लागू किए गए android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS के लिए, शून्य के अलावा कोई अन्य वैल्यू मिलती है, तो:

• डिवाइस के लिए तय की गई मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, Android 17 CDD के सेक्शन 2.2.7.4 में बताई गई परफ़ॉर्मेंस की ज़रूरी शर्तों को पूरा करना ज़रूरी है.

अगर हैंडहेल्ड डिवाइसों पर लागू किए गए android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS के लिए, शून्य के अलावा कोई अन्य वैल्यू मिलती है, तो:

• [8.2/H-1-1] ज़रूरी है कि डिवाइस में क्रम से लिखने की परफ़ॉर्मेंस, डिवाइस के लिए तय की गई मीडिया परफ़ॉर्मेंस क्लास लेवल के मुताबिक हो.

• [8.2/H-1-2] ज़रूरी है कि डिवाइस की रैंडम राइट परफ़ॉर्मेंस, डिवाइस के लिए तय किए गए मीडिया परफ़ॉर्मेंस क्लास लेवल के मुताबिक हो.

• [8.2/H-1-3] डिवाइस के लिए तय की गई मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, डिवाइस में डेटा को क्रम से पढ़ने की परफ़ॉर्मेंस अच्छी होनी चाहिए.

• [8.2/H-1-4] डिवाइस के लिए तय की गई मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, रैंडम रीड परफ़ॉर्मेंस को पक्का करना ज़रूरी है.

• [8.2/H-1-5] डिवाइस के लिए तय किए गए मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, पैरलल सीक्वेंशियल रीड और राइट परफ़ॉर्मेंस को पक्का करना ज़रूरी है.

2.2.7.5. ग्राफ़िक

अगर हैंडहेल्ड डिवाइसों पर लागू किए गए android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS के लिए, शून्य के अलावा कोई अन्य वैल्यू मिलती है, तो:

• [7.1.4.1/H-1-2] डिवाइस के लिए तय किए गए मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, ज़रूरी EGL एक्सटेंशन के साथ काम करना ज़रूरी है.

• [7.1.4.1/H-1-3] डिवाइस के लिए तय किए गए मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, ज़रूरी Vulkan सुविधाएं काम करनी चाहिए.

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

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

अगर Android डिवाइस इन सभी शर्तों को पूरा करते हैं, तो उन्हें टेलीविज़न के तौर पर क्लासिफ़ाई किया जाता है:

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

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

2.3.1. हार्डवेयर

टेलीविज़न डिवाइस में सेट किए गए सिस्टम के लिए:

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

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

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

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

• [7.6.1/T-1-1] अगर इनमें से किसी भी डेंसिटी का इस्तेमाल किया जाता है, तो कर्नल और यूज़रस्पेस के लिए उपलब्ध मेमोरी कम से कम 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 (बेहतर लो डिले एएसी)

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

• [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] मेन प्रोफ़ाइल हाई लेवल के साथ, हर सेकंड में 29.97 फ़्रेम पर एचडी 1080 पिक्सल.
• [5.3.1/T-1-2] 59.94 फ़्रेम प्रति सेकंड पर एचडी 1080i Main Profile High Level के साथ. उन्हें इंटरलेस्ड MPEG-2 वीडियो को डीइंटरलेस करना होगा. साथ ही, इसे तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराना होगा.

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

• [5.3.4/T-1-1] 60 फ़्रेम प्रति सेकंड पर एचडी 1080 पिक्सल रिज़ॉल्यूशन के साथ बेसललाइन प्रोफ़ाइल
• [5.3.4/T-1-2] मेन प्रोफ़ाइल के साथ, हर सेकंड में 60 फ़्रेम पर एचडी 1080 पिक्सल
• [5.3.4/T-1-3] 60 फ़्रेम प्रति सेकंड पर एचडी 1080 पिक्सल, High Profile Level 4.2 के साथ

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

• [5.3.5/T-1-1] 60 फ़्रेम प्रति सेकंड पर एचडी 1080 पिक्सल रिज़ॉल्यूशन के साथ Main Profile Level 4.1

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

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

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

• [5.3.6/T-1-1] हर सेकंड में 60 फ़्रेम पर एचडी 1080 पिक्सल रिज़ॉल्यूशन वाली डिकोडिंग प्रोफ़ाइल

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

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

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

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

टेलीविज़न डिवाइस में सेट किए गए सिस्टम के लिए:

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

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

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

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

• [5.8/T-1-1] HDCP 2.2 के साथ काम करना ज़रूरी है.

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

• [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] लॉक स्क्रीन पर सूचनाएं दिखाने की सुविधा होनी चाहिए. इसमें मीडिया सूचना टेंप्लेट भी शामिल है.

टेलीविज़न डिवाइस में सेट किए गए सिस्टम के लिए:

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

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

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

Android Television Input Framework (टीआईएफ़) की मदद से, Android Television डिवाइसों पर लाइव कॉन्टेंट आसानी से डिलीवर किया जा सकता है. TIF, Android Television डिवाइसों को कंट्रोल करने वाले इनपुट मॉड्यूल बनाने के लिए, एक स्टैंडर्ड एपीआई उपलब्ध कराता है.

टेलीविज़न डिवाइस में सेट किए गए सिस्टम के लिए:

• [3/T-0-2] प्लैटफ़ॉर्म की सुविधा android.software.live_tv का एलान करना ज़रूरी है.
• [3/T-0-3] में, सभी टीआईएफ़ एपीआई काम करने चाहिए, ताकि इन एपीआई और टीआईएफ़ पर आधारित तीसरे पक्ष के इनपुट का इस्तेमाल करने वाले ऐप्लिकेशन को डिवाइस पर इंस्टॉल और इस्तेमाल किया जा सके.

Android Television Tuner Framework (TF), Android Television डिवाइसों पर, ट्यूनर से मिलने वाले लाइव कॉन्टेंट और आईपी से मिलने वाले स्ट्रीमिंग कॉन्टेंट को एक साथ मैनेज करने की सुविधा देता है. Tuner Framework, Android TV Tuner का इस्तेमाल करने वाली इनपुट सेवाएं बनाने के लिए, एक स्टैंडर्ड एपीआई उपलब्ध कराता है.

अगर डिवाइस में Tuner की सुविधा काम करती है, तो:

• [3/T-1-1] MUST support all Tuner Framework APIs such that an application which uses these APIs can be installed and used on the device.

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] ऐप्लिकेशन को, उपयोगकर्ताओं को उन सभी ऐप्लिकेशन को दिखाने की सुविधा देनी होगी जिन्हें ऐप्लिकेशन स्टैंडबाय और बैटरी बचाने वाले डोज़ मोड से छूट मिली है.

टेलीविज़न डिवाइस में सेट किए गए सिस्टम के लिए:

• [8.4/T-0-1] हर कॉम्पोनेंट के लिए, पावर प्रोफ़ाइल उपलब्ध कराना ज़रूरी है. इसमें हर हार्डवेयर कॉम्पोनेंट के लिए, मौजूदा खपत की वैल्यू और समय के साथ कॉम्पोनेंट की वजह से तेज़ी से बैटरी खर्च होने की अनुमानित जानकारी शामिल होनी चाहिए. यह जानकारी, Android ओपन सोर्स प्रोजेक्ट की साइट पर मौजूद दस्तावेज़ में दी गई है.
• [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 सुविधा के बारे में एलान करना ज़रूरी है.

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

• [9.1/T-0-1] यह ज़रूरी है कि उस ऐप्लिकेशन के लिए, ACCESS_FINE_LOCATION को डिफ़ॉल्ट के तौर पर अनुमति न दी जाए.

टेलीविज़न डिवाइस में सेट किए गए सिस्टम के लिए:

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

• [9.11/T-0-4] इसमें कुंजी की पुष्टि करने की सुविधा होनी चाहिए. इस सुविधा में, पुष्टि करने के लिए इस्तेमाल की जाने वाली हस्ताक्षर कुंजी को सुरक्षित हार्डवेयर से सुरक्षित किया जाता है और हस्ताक्षर करने की प्रोसेस सुरक्षित हार्डवेयर में की जाती है. अटेस्टेशन साइनिंग कुंजियों को डिवाइस के स्थायी आइडेंटिफ़ायर के तौर पर इस्तेमाल नहीं किया जाना चाहिए.

ध्यान दें कि अगर किसी डिवाइस पर 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] इसमें प्रतिबंधित प्रोफ़ाइलों के लिए सहायता उपलब्ध नहीं होनी चाहिए. हालांकि, इसमें एओएसपी के कंट्रोल को लागू करने के तरीके के मुताबिक काम करना चाहिए, ताकि अन्य उपयोगकर्ताओं को वॉइस कॉल और एसएमएस ऐक्सेस करने की सुविधा चालू /बंद की जा सके.

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

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

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

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

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

टेलीविज़न डिवाइस में सेट किए गए सिस्टम के लिए:

• Perfetto

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

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] 3-ऐक्सिस एक्सलरोमीटर शामिल करने का सुझाव दिया जाता है.

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

• [7.3.3/W-1-1] जीएनएसएस के मेज़रमेंट की जानकारी मिलते ही उसे देना ज़रूरी है. भले ही, जीपीएस/जीएनएसएस से कैलकुलेट की गई जगह की जानकारी अब तक न दी गई हो.
• [7.3.3/W-1-2] जीएनएसएस की स्यूडोरेंज और स्यूडोरेंज रेट की जानकारी देना ज़रूरी है. खुले आसमान वाली जगहों में, जगह की जानकारी का पता लगाने के बाद, जब वाहन रुका हुआ हो या 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] MUST support uiMode = UI_MODE_TYPE_WATCH.
• [3.2.3.1/W-0-1] MUST preload one or more applications or service components with an intent handler, for all the public intent filter patterns defined by the following application intents listed here.

स्मार्टवॉच में सेट किए गए सिस्टम के लिए:

• [3.8.4/W-SR-1] डिवाइस पर असिस्टेंट को लागू करने का सुझाव दिया जाता है, ताकि सहायता पाने से जुड़ी कार्रवाई को हैंडल किया जा सके.

android.hardware.audio.output फ़ीचर फ़्लैग का एलान करने वाले स्मार्टवॉच डिवाइसों के लिए:

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

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

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

• [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 सुविधा के बारे में एलान करना ज़रूरी है.

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

• [9.1/W-0-1] यह ज़रूरी है कि उस ऐप्लिकेशन के लिए, ACCESS_FINE_LOCATION को डिफ़ॉल्ट के तौर पर अनुमति न दी जाए.

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

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

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

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

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

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

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

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

• जिन्हें किसी वाहन में एम्बेड किया गया हो या प्लग किया जा सकता हो.

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

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

2.5.1. हार्डवेयर

Automotive डिवाइस में सेट किए गए सिस्टम के लिए:

• [7.1.1.1/A-0-1] स्क्रीन का फ़िज़िकल डाइगोनल साइज़ कम से कम 6 इंच होना चाहिए.

• [7.1.1.1/A-0-2] में स्क्रीन का साइज़ कम से कम 750 dp x 480 dp होना चाहिए.

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

अगर Automotive डिवाइस में सेट किए गए सिस्टम में, एक साथ कई उपयोगकर्ताओं के साथ काम करने की सुविधा उपलब्ध है (इस सुविधा के तहत, एक साथ कई Android डिवाइस के एक से ज़्यादा उपयोगकर्ता डिवाइस के साथ इंटरैक्ट कर सकते हैं. इसके लिए, config_multiuserVisibleBackgroundUsers सुविधा चालू होने पर, हर उपयोगकर्ता अपने डिसप्ले का इस्तेमाल करता है), तो:

• [7.1.1.1/A-1-1] मुख्य डिसप्ले के लिए, हर ऑक्यूपेंट ज़ोन में कम से कम 6 इंच के फ़िज़िकल डायगोनल साइज़ वाली अलग स्क्रीन होनी चाहिए. इसे हर ऑक्यूपेंट ज़ोन के लिए, CarOccupantZoneManager.DISPLAY_TYPE_MAIN के तौर पर टैग किया जाना चाहिए.

• [7.1.1.1/A-1-2] हर मुख्य डिसप्ले के लिए, स्क्रीन का साइज़ कम से कम 750 dp x 480 dp होना चाहिए.

अगर Automotive डिवाइस में सेट किए गए सिस्टम में 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 लोडर शामिल होना चाहिए और सभी सिंबल एक्सपोर्ट होने चाहिए.

अगर Automotive डिवाइस में सेट किए गए सिस्टम में Vulkan का इस्तेमाल किया जाता है, तो:

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

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

• [7.1.4.5/A-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 एक्सटेंशन के लिए सहायता का विज्ञापन देना ज़रूरी है.

Automotive डिवाइस में सेट किए गए सिस्टम के लिए:

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

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

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

• [7.1.4.6/A-1-2] डिवाइस के जीपीयू काउंटर के लिए, gpu counter trace पैकेट प्रोटो के मुताबिक वैल्यू रिपोर्ट करनी होंगी.

• [7.1.4.6/A-1-3] डिवाइस के GPU RenderStages के लिए, render stage trace packet proto के मुताबिक, ज़रूरी है कि अनुपालन करने वाली वैल्यू की रिपोर्ट की जाए.

• [7.1.4.6/A-1-4] जीपीयू फ़्रीक्वेंसी ट्रेसपॉइंट को इस फ़ॉर्मैट में रिपोर्ट करना ज़रूरी है: power/gpu_frequency.

Automotive डिवाइस में सेट किए गए सिस्टम के लिए:

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

Automotive डिवाइस में सेट किए गए सिस्टम के लिए:

• [7.1.7/A-0-1] ड्राइवर की नज़र के सामने मौजूद सेकंडरी डिसप्ले को FLAG_PRIVATE के तौर पर कॉन्फ़िगर करना ज़रूरी है.

• [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() के ज़रिए अनुरोध की गई Location को मैप से मैच नहीं किया जाना चाहिए.

• [7.3.1/A-0-4] Android के कार सेंसर कोऑर्डिनेट सिस्टम का पालन करना ज़रूरी है.

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

• [7.3/A-SR-2] TYPE_HEADING सेंसर को लागू करने और उसके बारे में जानकारी देने का सुझाव दिया जाता है.

अगर Automotive डिवाइस में सेट किए गए सिस्टम में, एक साथ कई उपयोगकर्ताओं के साथ काम करने की सुविधा उपलब्ध है (इस सुविधा के तहत, एक साथ कई Android डिवाइस के एक से ज़्यादा उपयोगकर्ता डिवाइस के साथ इंटरैक्ट कर सकते हैं. इसके लिए, config_multiuserVisibleBackgroundUsers सुविधा चालू होने पर, हर उपयोगकर्ता अपने डिसप्ले का इस्तेमाल करता है), तो:

• [7.3/A-1-1] सभी डिसप्ले पर, NIGHT_MODE फ़्लैग की वैल्यू को डैशबोर्ड के डे/नाइट मोड के हिसाब से सेट करना ज़रूरी है. इसमें पीछे की सीट पर लगे डिसप्ले भी शामिल हैं.

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

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

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

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

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

• [7.3.1/A-1-3] TYPE_ACCELEROMETER_LIMITED_AXES सेंसर को लागू करना और उसके बारे में जानकारी देना ज़रूरी है.

• [7.3.1/A-1-4] TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED सेंसर को लागू करना और उसके बारे में जानकारी देना ज़रूरी है.

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

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

• [7.3.4/A-2-3] यह एक सेकंड में 250 डिग्री तक ओरिएंटेशन में होने वाले बदलावों को मेज़र कर सकता हो.

• [7.3.4/A-SR-1] यह सुझाव दिया जाता है कि जायरोस्कोप की मेज़रमेंट रेंज को +/-250 dps पर कॉन्फ़िगर करें, ताकि ज़्यादा से ज़्यादा रिज़ॉल्यूशन मिल सके.

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

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

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

• [7.3.4/A-4-1] TYPE_GYROSCOPE_LIMITED_AXES सेंसर को लागू करना और उसके बारे में जानकारी देना ज़रूरी है.

• [7.3.4/A-4-2] TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED सेंसर को लागू करना और उसके बारे में जानकारी देना ज़रूरी है.

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

• [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 में बताई गई जगह की सटीक जानकारी के साथ, अनुमानित जगह की जानकारी का इस्तेमाल किया जा सकता है. इसके अलावा, इन दोनों तरीकों का इस्तेमाल एक साथ भी किया जा सकता है.

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

• [7.3.4/A-4-3] कम से कम 1 हर्ट्ज़ की फ़्रीक्वेंसी तक इवेंट रिपोर्ट करने की सुविधा होनी चाहिए.

• [7.3.4/A-SR-3] कम से कम 10 हर्ट्ज़ की फ़्रीक्वेंसी तक इवेंट रिपोर्ट करने का सुझाव दिया जाता है.

• यह ट्रू नॉर्थ के हिसाब से होना चाहिए.

• गाड़ी के रुके होने पर भी यह सुविधा उपलब्ध होनी चाहिए.

• इसका रिज़ॉल्यूशन कम से कम 1 डिग्री होना चाहिए.

Automotive डिवाइस में सेट किए गए सिस्टम के लिए:

• [7.4.3/A-0-1] इनमें ब्लूटूथ काम करना चाहिए. साथ ही, इनमें ब्लूटूथ स्मार्ट काम करना चाहिए.

• [7.4.3/A-0-2] Android Automotive के साथ काम करने वाले डिवाइसों में, इन ब्लूटूथ प्रोफ़ाइलों का इस्तेमाल किया जा सकता है:

  • हैंड्स-फ़्री प्रोफ़ाइल (एचएफ़पी) के ज़रिए फ़ोन कॉल करने की सुविधा.
  • ऑडियो डिस्ट्रिब्यूशन प्रोफ़ाइल (A2DP) के ज़रिए मीडिया प्लेबैक.
  • रिमोट कंट्रोल प्रोफ़ाइल (एवीआरसीपी) के ज़रिए मीडिया प्लेबैक को कंट्रोल करना.
  • फ़ोन बुक ऐक्सेस प्रोफ़ाइल (पीबीएपी) का इस्तेमाल करके संपर्क शेयर करने की सुविधा.

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

अगर Automotive डिवाइस में सेट किए गए सिस्टम में, एक साथ कई उपयोगकर्ताओं के साथ काम करने की सुविधा उपलब्ध है (इस सुविधा के तहत, एक साथ कई Android डिवाइस के एक से ज़्यादा उपयोगकर्ता डिवाइस के साथ इंटरैक्ट कर सकते हैं. इसके लिए, config_multiuserVisibleBackgroundUsers सुविधा चालू होने पर, हर उपयोगकर्ता अपने डिसप्ले का इस्तेमाल करता है), तो:

• [7.4.3/A-1-1] यह ज़रूरी है कि यह सुविधा स्वतंत्र रूप से काम करे और अन्य उपयोगकर्ताओं के बीटी अनुभव में कोई रुकावट न डाले.

Automotive डिवाइस में सेट किए गए सिस्टम के लिए:

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

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

अगर डिवाइस में एएम/एफ़एम ब्रॉडकास्ट रेडियो की सुविधा शामिल है और यह सुविधा किसी भी ऐप्लिकेशन के लिए उपलब्ध है, तो:

• [7.4/A-1-1] FEATURE_BROADCAST_RADIO के साथ काम करने की सुविधा के बारे में बताना ज़रूरी है.

पीछे की ओर लगे कैमरे का मतलब है कि यह दुनिया की ओर फ़ेस करने वाला कैमरा है. इसे वाहन में किसी भी जगह पर लगाया जा सकता है. यह वाहन के केबिन के बाहर की ओर फ़ेस करता है. इसका मतलब है कि यह वाहन के पीछे के हिस्से के सीन की इमेज लेता है. जैसे, पीछे का कैमरा.

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

Automotive डिवाइस में सेट किए गए सिस्टम के लिए:

• [7.5/A-SR-1] में, एक या उससे ज़्यादा वर्ल्ड-फ़ेसिंग कैमरे शामिल करने का सुझाव दिया जाता है.

• इसमें एक या इससे ज़्यादा ऐसे कैमरे शामिल हो सकते हैं जो उपयोगकर्ता की ओर हों.

• [7.5/A-SR-2] एक साथ कई कैमरों से स्ट्रीमिंग करने की सुविधा देने का सुझाव दिया जाता है.

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

• [7.5/A-1-1] कैमरे को इस तरह से ओरिएंट किया जाना चाहिए कि कैमरे का लंबा डाइमेंशन, Android Automotive के सेंसर ऐक्सिस के X-Y प्लेन के साथ अलाइन हो.

• [7.5/A-SR-3] फ़िक्स्ड-फ़ोकस या ईडीओएफ़ (एक्सटेंडेड डेप्थ ऑफ़ फ़ील्ड) हार्डवेयर का इस्तेमाल करने का सुझाव दिया जाता है.

• [7.5/A-1-2] डिवाइस में, पीछे की ओर मौजूद कैमरे को प्राइमरी कैमरा होना चाहिए. साथ ही, उसका कैमरा आईडी सबसे कम होना चाहिए.

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

• [7.5/A-2-1] उपयोगकर्ता की ओर वाला मुख्य कैमरा, उपयोगकर्ता की ओर वाला वह कैमरा होना चाहिए जिसका कैमरा आईडी सबसे कम हो.

• इसे इस तरह से ओरिएंट किया जा सकता है कि कैमरे का लंबा डाइमेंशन, Android Automotive के सेंसर ऐक्सिस के X-Y प्लेन के साथ अलाइन हो.

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

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

अगर ऑटोमोटिव डिवाइसों में एक या उससे ज़्यादा ऐसे कैमरे शामिल हैं जिन्हें Extended View System Service के ज़रिए ऐक्सेस किया जा सकता है, तो ऐसे कैमरे के लिए:

• [7.5/A-5-1] कैमरे की झलक को घुमाया या हॉरिज़ॉन्टली मिरर नहीं किया जाना चाहिए.

• [7.5/A-SR-4] इनका रिज़ॉल्यूशन कम से कम 1.3 मेगापिक्सल होना चाहिए.

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

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

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

• [7.5/A-7-1] ऐसे कैमरा एपीआई को android.hardware.camera2 एपीआई या Extended View System API का इस्तेमाल करके लागू करना ज़रूरी है.

Automotive डिवाइस में सेट किए गए सिस्टम के लिए:

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

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

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

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

अगर Automotive डिवाइस में सेट किए गए सिस्टम में, एक साथ कई उपयोगकर्ताओं के साथ काम करने की सुविधा उपलब्ध है (इस सुविधा के तहत, एक साथ कई Android डिवाइस के एक से ज़्यादा उपयोगकर्ता डिवाइस के साथ इंटरैक्ट कर सकते हैं. इसके लिए, config_multiuserVisibleBackgroundUsers सुविधा चालू होने पर, हर उपयोगकर्ता अपने डिसप्ले का इस्तेमाल करता है), तो:

• [7.6.1/A-1-1] AAOS के एक इंस्टेंस पर, ऐप्लिकेशन के निजी डेटा (/data पार्टीशन) के लिए उपलब्ध नॉन-वोलैटाइल स्टोरेज में, एक साथ Android का इस्तेमाल करने वाले हर व्यक्ति के लिए कम से कम 4 जीबी स्टोरेज होना चाहिए.

अगर Automotive डिवाइस में सेट किए गए सिस्टम 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] अगर इनमें से किसी भी डेंसिटी का इस्तेमाल किया जाता है, तो कर्नेल और यूज़रस्पेस के लिए उपलब्ध मेमोरी, हर मुख्य डिसप्ले के लिए कम से कम 1824 एमबी होनी चाहिए:

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

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

Automotive डिवाइस में सेट किए गए सिस्टम के लिए:

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

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

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

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

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

Automotive डिवाइस में सेट किए गए सिस्टम के लिए:

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

Automotive डिवाइस में सेट किए गए सिस्टम के लिए:

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

अगर Automotive डिवाइस में सेट किए गए सिस्टम में, एक साथ कई उपयोगकर्ताओं के साथ काम करने की सुविधा उपलब्ध है (इस सुविधा के तहत, एक साथ कई Android डिवाइस के एक से ज़्यादा उपयोगकर्ता डिवाइस के साथ इंटरैक्ट कर सकते हैं. इसके लिए, config_multiuserVisibleBackgroundUsers सुविधा चालू होने पर, हर उपयोगकर्ता अपने डिसप्ले का इस्तेमाल करता है), तो:

• [7.8.2/A-1-1] एक साथ कई उपयोगकर्ताओं के सिस्टम के लिए, हर मुख्य डिसप्ले के लिए एक ऑडियो आउटपुट डिवाइस होना ज़रूरी है.

• [7.8.2/A-1-2] इसमें ड्राइवर ऑडियो ज़ोन होना चाहिए, जो ग्लोबल केबिन स्पीकर को कवर करता हो. आगे की सीट पर बैठा व्यक्ति, ड्राइवर के ऑडियो ज़ोन को शेयर कर सकता है या उसके पास अपना ऑडियो आउटपुट हो सकता है.

यूएसबी की मदद से कनेक्ट किए गए सहायक डिवाइस के चालू होने पर, AudioManager.getDevices() API को कॉल करने पर:

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

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

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

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

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

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

• [5.1/A-0-1] MPEG-4 AAC प्रोफ़ाइल (AAC LC)

• [5.1/A-0-2] MPEG-4 HE AAC प्रोफ़ाइल (AAC+)

• [5.1/A-0-3] AAC ELD (बेहतर लो डिले एएसी)

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

• [5.2/A-0-1] H.264 एवीसी

• [5.2/A-0-2] VP8

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

• [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

Automotive डिवाइस में सेट किए गए सिस्टम के लिए, वीडियो डिकोडिंग की इन सुविधाओं के साथ काम करना बेहद ज़रूरी है:

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

अगर Automotive डिवाइस में सेट किए गए सिस्टम में, एक साथ कई उपयोगकर्ताओं के साथ काम करने की सुविधा उपलब्ध है (इस सुविधा के तहत, एक साथ कई Android डिवाइस के एक से ज़्यादा उपयोगकर्ता डिवाइस के साथ इंटरैक्ट कर सकते हैं. इसके लिए, config_multiuserVisibleBackgroundUsers सुविधा चालू होने पर, हर उपयोगकर्ता अपने डिसप्ले का इस्तेमाल करता है), तो:

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

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

Automotive डिवाइस में सेट किए गए सिस्टम के लिए:

• [3/A-0-1] android.hardware.type.automotive सुविधा का एलान करना ज़रूरी है.

• [3/A-0-2] uiMode = UI_MODE_TYPE_CAR के साथ काम करना ज़रूरी है.

• [3/A-0-3] यह ज़रूरी है कि डिवाइस, android.car.* नेमस्पेस में मौजूद सभी सार्वजनिक एपीआई के साथ काम करता हो.

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

• [3/A-1-1] सिस्टम ऐप्लिकेशन को इन प्रॉपर्टी का इस्तेमाल करने के लिए, खास अनुमतियां नहीं देनी चाहिए. साथ ही, तीसरे पक्ष के ऐप्लिकेशन को इन प्रॉपर्टी का इस्तेमाल करने से नहीं रोकना चाहिए.

• [3/A-1-2] वाहन की ऐसी प्रॉपर्टी को दोहराया नहीं जाना चाहिए जो पहले से ही एसडीके में मौजूद है.

Automotive डिवाइस में सेट किए गए सिस्टम के लिए:

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

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

• [3.2.3.1/A-0-2] SDK टूल के दस्तावेज़ों में बताए गए तरीके के मुताबिक, ऐप्लिकेशन में ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE, और ACTION_CREATE_DOCUMENT इंटेंट को हैंडल करने की सुविधा होनी चाहिए. साथ ही, DocumentsProvider एपीआई का इस्तेमाल करके, दस्तावेज़ उपलब्ध कराने वाली कंपनी के डेटा को ऐक्सेस करने की सुविधा भी होनी चाहिए.

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

• [3.2.3.1/A-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 से पार्स किए गए इंटेंट की ऐक्टिविटी शुरू करनी चाहिए.

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

अगर Automotive डिवाइस में सेट किए गए सिस्टम में, एक साथ कई उपयोगकर्ताओं के साथ काम करने की सुविधा उपलब्ध है (इस सुविधा के तहत, एक साथ कई Android डिवाइस के एक से ज़्यादा उपयोगकर्ता डिवाइस के साथ इंटरैक्ट कर सकते हैं. इसके लिए, config_multiuserVisibleBackgroundUsers सुविधा चालू होने पर, हर उपयोगकर्ता अपने डिसप्ले का इस्तेमाल करता है), तो:

• [3.8/A-1-1] यह ज़रूरी है कि पूरी तरह से सेकंडरी यूज़र के लिए, UserRestrictions की पहले से तय की गई इस सूची को लागू किया जाए. ये ऐसे सेकंडरी यूज़र होते हैं जो फ़िलहाल फ़ोरग्राउंड यूज़र नहीं हैं, लेकिन उन्हें डिसप्ले का यूज़र इंटरफ़ेस (यूआई) ऐक्सेस करने की अनुमति मिली हुई है. UserRestrictions की सूची में ये शामिल हैं: DISALLOW_CONFIG_LOCALE, DISALLOW_CONFIG_BLUETOOTH, DISALLOW_BLUETOOTH, DISALLOW_CAMERA_TOGGLE, और DISALLOW_MICROPHONE_TOGGLE.

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

Automotive डिवाइस में सेट किए गए सिस्टम के लिए:

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

• [3.8.4/A-SR-1] डिवाइस पर असिस्टेंट को लागू करने का सुझाव दिया जाता है, ताकि असिस्ट करने की कार्रवाई को हैंडल किया जा सके.

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

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

Automotive डिवाइस में सेट किए गए सिस्टम के लिए:

• [3.8.3.1/A-0-1] Notifications on Automotive OS एसडीके के दस्तावेज़ में बताए गए तरीके से, संसाधनों को सही तरीके से रेंडर करना ज़रूरी है.

• [3.8.3.1/A-0-2] Notification.Builder.addAction() के ज़रिए उपलब्ध कराए गए विकल्पों के बजाय, सूचनाओं के लिए PLAY और MUTE विकल्प दिखाना ज़रूरी है

• [3.8.3.1/A] को सूचना चैनल के हिसाब से कंट्रोल करने जैसे बेहतर मैनेजमेंट टास्क के इस्तेमाल पर पाबंदी लगानी चाहिए. MAY use UI affordance per application to reduce controls.

अगर Automotive डिवाइस में सेट किए गए सिस्टम, उपयोगकर्ता एचएएल प्रॉपर्टी के साथ काम करते हैं, तो:

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

Automotive डिवाइस में सेट किए गए सिस्टम के लिए:

• [3.14/A-0-1] इसमें यूज़र इंटरफ़ेस (यूआई) फ़्रेमवर्क शामिल होना चाहिए, ताकि तीसरे पक्ष के ऐसे ऐप्लिकेशन काम कर सकें जो सेक्शन 3.14 में बताए गए मीडिया एपीआई का इस्तेमाल करते हैं.

• [3.14/A-0-2] गाड़ी चलाते समय, उपयोगकर्ता को मीडिया ऐप्लिकेशन के साथ सुरक्षित तरीके से इंटरैक्ट करने की अनुमति देना ज़रूरी है.

• [3.14/A-0-3] CAR_EXTRA_MEDIA_PACKAGE एक्स्ट्रा के साथ CAR_INTENT_ACTION_MEDIA_TEMPLATE इंप्लिसिट इंटेंट ऐक्शन के साथ काम करना ज़रूरी है.

• [3.14/A-0-4] मीडिया ऐप्लिकेशन की preference activity में नेविगेट करने की सुविधा उपलब्ध होनी चाहिए. हालांकि, इसे सिर्फ़ तब चालू किया जाना चाहिए, जब Car UX Restrictions लागू न हों.

• [3.14/A-0-5] मीडिया ऐप्लिकेशन से सेट किए गए गड़बड़ी के मैसेज दिखाने चाहिए. साथ ही, ERROR_RESOLUTION_ACTION_LABEL और ERROR_RESOLUTION_ACTION_INTENT के साथ काम करना चाहिए.

• [3.14/A-0-6] MUST support an in-app search affordance for apps that support searching.

• [3.14/A-0-7] MediaBrowser की हैरारकी दिखाते समय, CONTENT_STYLE_BROWSABLE_HINT और CONTENT_STYLE_PLAYABLE_HINT की परिभाषाओं का पालन करना ज़रूरी है.

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

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

Automotive डिवाइस में सेट किए गए सिस्टम के लिए:

• [3.8/A] MAY restrict the application requests to enter a full screen mode as described in immersive documentation.

• [3.8/A] स्टेटस बार और नेविगेशन बार को हमेशा दिखा सकता है.

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

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

• [8.1/A-0-1] फ़्रेम के रेंडर होने में लगने वाला समय एक जैसा होना चाहिए. फ़्रेम रेंडर होने में लगने वाले समय में अंतर या फ़्रेम रेंडर होने में देरी, एक सेकंड में पांच फ़्रेम से ज़्यादा बार नहीं होनी चाहिए. साथ ही, यह एक सेकंड में एक फ़्रेम से कम होनी चाहिए.

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

• [8.1/A-0-3] टास्क स्विच करना. जब एक से ज़्यादा ऐप्लिकेशन लॉन्च किए गए हों, तो पहले से चल रहे ऐप्लिकेशन को लॉन्च करने के बाद, उसे फिर से लॉन्च करने में एक सेकंड से कम समय लगना चाहिए.

Automotive डिवाइस में सेट किए गए सिस्टम के लिए:

• [8.2/A-0-1] हर प्रोसेस के यूआईडी के हिसाब से, नॉन-वोलाटाइल स्टोरेज में पढ़े और लिखे गए बाइट की संख्या की जानकारी देनी होगी, ताकि डेवलपर को सिस्टम एपीआई android.car.storagemonitoring.CarStorageMonitoringManager के ज़रिए आंकड़े मिल सकें. Android ओपन सोर्स प्रोजेक्ट, uid_sys_stats कर्नेल मॉड्यूल के ज़रिए इस ज़रूरी शर्त को पूरा करता है.

• [8.2/A-0-2] यह ज़रूरी है कि डिवाइस में, कम से कम 5 एमबी/सेकंड की सीक्वेंशियल राइट परफ़ॉर्मेंस हो.

• [8.2/A-0-3] यह पक्का करना ज़रूरी है कि रैंडम राइट परफ़ॉर्मेंस कम से कम 0.5 एमबी/सेकंड हो.

• [8.2/A-0-4] यह ज़रूरी है कि डिवाइस में, क्रम से डेटा पढ़ने की स्पीड कम से कम 15 एमबी/सेकंड हो.

• [8.2/A-0-5] यह पक्का करना ज़रूरी है कि रैंडम रीड की परफ़ॉर्मेंस कम से कम 3.5 एमबी/सेकंड हो.

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

• [8.2/A-1-1] यह पक्का करना ज़रूरी है कि सीक्वेंशियल राइट परफ़ॉर्मेंस कम से कम 150 एमबी/सेकंड हो.

• [8.2/A-1-2] ज़रूरी है कि रैंडम राइट परफ़ॉर्मेंस कम से कम 10 एमबी/सेकंड हो.

• [8.2/A-1-3] यह पक्का करना ज़रूरी है कि सीक्वेंशियल रीड परफ़ॉर्मेंस कम से कम 250 एमबी/सेकंड हो.

• [8.2/A-1-4] यह ज़रूरी है कि रैंडम रीड की परफ़ॉर्मेंस कम से कम 100 एमबी/सेकंड हो.

• [8.2/A-1-5] ज़रूरी है कि इसमें एक साथ क्रम से पढ़ने और लिखने की सुविधा हो. साथ ही, पढ़ने की स्पीड लिखने की स्पीड से दोगुनी हो और कम से कम 50 एमबी/सेकंड हो.

• [8.3/A-1-3] इसमें गैराज मोड की सुविधा होनी चाहिए.

• [8.3/A] हर ड्राइव के बाद, कम से कम 15 मिनट तक गैराज मोड में होना चाहिए. हालांकि, ऐसा तब नहीं होना चाहिए, जब:

  • बैटरी खत्म हो गई है.
  • कोई भी ऐसा जॉब शेड्यूल नहीं किया गया है जो कुछ समय से चल नहीं रहा है.
  • ड्राइवर, गैराज मोड से बाहर निकल जाता है.

• [8.4/A-0-1] हर कॉम्पोनेंट के लिए, पावर प्रोफ़ाइल उपलब्ध कराना ज़रूरी है. इसमें हर हार्डवेयर कॉम्पोनेंट के लिए, ऊर्जा की मौजूदा खपत की वैल्यू और समय के साथ कॉम्पोनेंट की वजह से तेज़ी से बैटरी खर्च होने की अनुमानित दर के बारे में बताया गया हो. यह जानकारी, Android ओपन सोर्स प्रोजेक्ट की साइट पर मौजूद दस्तावेज़ में दी गई हो.

• [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. सुरक्षा मॉडल

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

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

• [9.5/A-1-2] BOOT_COMPLETED से पहले, दूसरे उपयोगकर्ता के तौर पर स्विच करना ज़रूरी है.

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

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

• [9.8/A-1-1] यह पक्का करना ज़रूरी है कि क्वेरी का पता लगाने वाली सेवा, सिर्फ़ सिस्टम, ContentCaptureService या उपयोगकर्ता के डिवाइस पर मौजूद स्पीच रिकग्निशन सेवा (SpeechRecognizer#createOnDeviceSpeechRecognizer() ने बनाई है) को डेटा ट्रांसमिट कर सकती है.

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

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

• [9.8/A-1-4] उपयोगकर्ता की क्वेरी का पता चलने के तुरंत बाद, यूज़र इंटरफ़ेस (यूआई) में माइक्रोफ़ोन इंडिकेटर और उपयोगकर्ता की क्वेरी दिखनी चाहिए.

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

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

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

• [9.8.2/A-1-2] सिस्टम ऐप्लिकेशन के लिए, माइक्रोफ़ोन इंडिकेटर को नहीं छिपाना चाहिए. इन ऐप्लिकेशन के यूज़र इंटरफ़ेस दिखते हैं या ये सीधे तौर पर उपयोगकर्ता से इंटरैक्ट करते हैं.

• [9.8.2/A-1-3] सेटिंग ऐप्लिकेशन में, माइक्रोफ़ोन को टॉगल करने की सुविधा उपलब्ध होनी चाहिए.

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

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

• [9.8.2/A-2-2] सिस्टम ऐप्लिकेशन के लिए, कैमरा इंडिकेटर को नहीं छिपाना चाहिए. इन ऐप्लिकेशन के यूज़र इंटरफ़ेस दिखते हैं या ये सीधे तौर पर उपयोगकर्ता से इंटरैक्ट करते हैं.

• [9.8.2/A-2-3] उपयोगकर्ता को सेटिंग ऐप्लिकेशन में, कैमरे को टॉगल करने की सुविधा देनी होगी.

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

Automotive डिवाइस में सेट किए गए सिस्टम के लिए:

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

• [9.11/A-0-1] MUST back up the keystore implementation with an isolated execution environment.

• [9.11/A-0-2] Android Keystore सिस्टम के साथ काम करने वाले एल्गोरिदम को सही तरीके से सपोर्ट करने के लिए, इसमें आरएसए, एईएस, ईसीडीएसए, और एचएमएसी क्रिप्टोग्राफ़िक एल्गोरिदम के साथ-साथ MD5, SHA-1, और SHA-2 फ़ैमिली हैश फ़ंक्शन लागू होने चाहिए. ये एल्गोरिदम, कर्नल और उससे ऊपर के कोड से सुरक्षित तरीके से अलग किए गए क्षेत्र में लागू होने चाहिए. सुरक्षित आइसोलेशन को उन सभी संभावित तरीकों को ब्लॉक करना चाहिए जिनसे कर्नेल या यूज़रस्पेस कोड, आइसोलेट किए गए एनवायरमेंट की इंटरनल स्थिति को ऐक्सेस कर सकता है. इसमें डीएमए भी शामिल है. अपस्ट्रीम Android Open Source Project (AOSP), Trusty को लागू करके इस ज़रूरी शर्त को पूरा करता है. हालांकि, ARM TrustZone पर आधारित कोई अन्य समाधान या हाइपरवाइज़र पर आधारित आइसोलेशन को सुरक्षित तरीके से लागू करने वाला कोई ऐसा समाधान जिसे तीसरे पक्ष ने समीक्षा की हो, इसके विकल्प हैं.

• [9.11/A-0-3] लॉक स्क्रीन की पुष्टि, आइसोलेटेड एक्ज़ीक्यूशन एनवायरमेंट में की जानी चाहिए. साथ ही, पुष्टि हो जाने के बाद ही, पुष्टि से जुड़ी कुंजियों का इस्तेमाल करने की अनुमति दी जानी चाहिए. लॉक स्क्रीन के क्रेडेंशियल को इस तरह से सेव किया जाना चाहिए कि सिर्फ़ आइसोलेटेड एक्ज़ीक्यूशन एनवायरमेंट, लॉक स्क्रीन की पुष्टि कर सके. अपस्ट्रीम Android Open Source Project, Gatekeeper हार्डवेयर ऐब्स्ट्रैक्शन लेयर (HAL) और Trusty उपलब्ध कराता है. इनका इस्तेमाल इस ज़रूरी शर्त को पूरा करने के लिए किया जा सकता है.

• [9.11/A-0-4] यह ज़रूरी है कि डिवाइस में कुंजी की पुष्टि करने की सुविधा काम करती हो. इस सुविधा में, पुष्टि करने के लिए इस्तेमाल की जाने वाली कुंजी को सुरक्षित हार्डवेयर से सुरक्षित किया जाता है. साथ ही, हस्ताक्षर करने की प्रोसेस सुरक्षित हार्डवेयर में पूरी की जाती है. अटेस्टेशन साइनिंग कुंजियों को डिवाइस के स्थायी आइडेंटिफ़ायर के तौर पर इस्तेमाल नहीं किया जाना चाहिए.

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

Automotive डिवाइस में सेट किए गए सिस्टम के लिए:

• [9.14/A-0-1] Android फ़्रेमवर्क के वाहन सबसिस्टम से मिलने वाले मैसेज को मैनेज करना ज़रूरी है. उदाहरण के लिए, अनुमति वाले मैसेज टाइप और मैसेज सोर्स को अनुमति देना.

• [9.14/A-0-2] Android फ़्रेमवर्क या तीसरे पक्ष के ऐप्लिकेशन से होने वाले सेवा से इनकार (डिनॉयल ऑफ़ सर्विस) के हमलों से बचने के लिए, वॉचडॉग का इस्तेमाल करना ज़रूरी है. इससे, नुकसान पहुंचाने वाले सॉफ़्टवेयर को वाहन के नेटवर्क में ट्रैफ़िक बढ़ाने से रोका जा सकता है. ऐसा होने पर, वाहन के सबसिस्टम ठीक से काम नहीं कर पाते हैं.

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

Automotive डिवाइस में सेट किए गए सिस्टम के लिए:

• Perfetto

  • [6.1/A-0-1] शेल उपयोगकर्ता के लिए, /system/bin/perfetto बाइनरी को उपलब्ध कराना ज़रूरी है. इस बाइनरी का cmdline, Perfetto के दस्तावेज़ के मुताबिक होना चाहिए.

  • [6.1/A-0-2] perfetto बाइनरी को, इनपुट के तौर पर ऐसा protobuf कॉन्फ़िगरेशन स्वीकार करना चाहिए जो perfetto के दस्तावेज़ में तय किए गए स्कीमा के मुताबिक हो.

  • [6.1/A-0-3] perfetto बाइनरी को आउटपुट के तौर पर, protobuf ट्रेस लिखना होगा. यह ट्रेस, perfetto के दस्तावेज़ में तय किए गए स्कीमा के मुताबिक होना चाहिए.

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

  • [6.1/A-0-5] परफ़ेक्टो ट्रेस किए गए डेमॉन को डिफ़ॉल्ट रूप से चालू किया जाना चाहिए (सिस्टम प्रॉपर्टी persist.traced.enable).

2.6. टैबलेट से जुड़ी ज़रूरी शर्तें

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

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

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

2.6.1. हार्डवेयर

Gyroscope

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

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

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

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

वर्चुअल रिएलिटी मोड (सेक्शन 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] इसमें प्रतिबंधित प्रोफ़ाइलों के लिए सहायता उपलब्ध नहीं होनी चाहिए. हालांकि, इसमें एओएसपी के कंट्रोल को लागू करने के तरीके के मुताबिक काम करना चाहिए, ताकि अन्य उपयोगकर्ताओं को वॉइस कॉल और एसएमएस ऐक्सेस करने की सुविधा चालू /बंद की जा सके.

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

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

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

3.1. Managed API के साथ काम करने की सुविधा

मैनेज किया गया 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] तीसरे पक्ष के ऐप्लिकेशन को गैर-एसडीके इंटरफ़ेस इस्तेमाल करने की अनुमति नहीं देनी चाहिए. इन्हें Java लैंग्वेज पैकेज में ऐसे तरीकों और फ़ील्ड के तौर पर तय किया जाता है जो AOSP में बूट क्लासपाथ में होते हैं और सार्वजनिक एसडीके का हिस्सा नहीं होते. इसमें @hide एनोटेशन वाले एपीआई शामिल हैं, लेकिन @SystemAPI एनोटेशन वाले एपीआई शामिल नहीं हैं. इसके बारे में एसडीके के दस्तावेज़ों में बताया गया है. साथ ही, इसमें निजी और पैकेज-निजी क्लास के सदस्य भी शामिल हैं.

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

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

  हालांकि, वे:

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

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

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

Android डिवाइस में सेट किए गए सिस्टम के लिए:

• [C-0-1] MUST preload the AOSP implementation of both the shared library ExtShared and services ExtServices with versions greater than or equal to the minimum versions allowed per each API level. उदाहरण के लिए, 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. सॉफ़्ट एपीआई कंपैटिबिलिटी

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

3.2.1. अनुमतियां

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

3.2.2. पैरामीटर बनाना

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

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 में Package Manager ने लागू किया है.
• [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] एसडीके के दस्तावेज़ में बताए गए तरीके के मुताबिक, सिस्टम के सही इवेंट के जवाब में, यहां दिए गए सार्वजनिक ब्रॉडकास्ट इंटेंट ब्रॉडकास्ट करना ज़रूरी है. ध्यान दें कि यह ज़रूरी शर्त, सेक्शन 3.5 का उल्लंघन नहीं करती. ऐसा इसलिए, क्योंकि एसडीके के दस्तावेज़ में बैकग्राउंड ऐप्लिकेशन के लिए भी सीमाएं बताई गई हैं. कुछ ब्रॉडकास्ट इंटेंट, हार्डवेयर की उपलब्धता पर निर्भर करते हैं. अगर डिवाइस में ज़रूरी हार्डवेयर मौजूद है, तो उसे इंटेंट ब्रॉडकास्ट करने चाहिए. साथ ही, एसडीके के दस्तावेज़ के मुताबिक काम करना चाहिए.

3.2.3.5. शर्तें पूरी होने पर ऐप्लिकेशन इंटेंट ट्रिगर करना

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

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

अगर डिवाइसों के लिए लागू की गई सुविधाओं की रिपोर्ट android.software.home_screen है, तो:

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

अगर डिवाइसों के लिए लागू की गई सुविधाओं की रिपोर्ट android.hardware.telephony.calling है, तो:

• [C-2-1] MUST provide a settings menu that will call the android.provider.Telephony.ACTION_CHANGE_DEFAULT intent to show a dialog to change the default SMS application.

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

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

• [C-2-3] android.telecom.action.CHANGE_PHONE_ACCOUNTS इंटेंट का पालन करना ज़रूरी है, ताकि उपयोगकर्ता को PhoneAccounts से जुड़े ConnectionServices को कॉन्फ़िगर करने की सुविधा मिल सके. साथ ही, टेलीकम्यूनिकेशन सेवा देने वाली कंपनी, आउटगोइंग कॉल करने के लिए डिफ़ॉल्ट 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 इंटेंट को, पहले से लोड किए गए डायलर ऐप्लिकेशन के साथ इस्तेमाल किया जाए. यह ऐप्लिकेशन इन इंटेंट को हैंडल कर सकता है और एसडीके में बताए गए तरीके से अनुरोध पूरा कर सकता है.

अगर डिवाइसों के लिए लागू की गई सुविधाओं की रिपोर्ट android.hardware.nfc.hce है, तो:

• [C-3-1] MUST honor the android.settings.NFC_PAYMENT_SETTINGS intent to show a default app settings menu for Contactless payment.
• [C-3-2] SDK में बताए गए तरीके के मुताबिक, किसी कैटगरी के लिए डिफ़ॉल्ट कार्ड इम्यूलेशन सेवा बदलने के लिए, उपयोगकर्ता से पूछने वाला डायलॉग खोलने वाली गतिविधि दिखाने के लिए, android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT इंटेंट का पालन करना ज़रूरी है.

अगर डिवाइसों के लिए लागू की गई सुविधाओं की रिपोर्ट android.hardware.nfc है, तो:

• [C-4-1] एसडीके में बताए गए इन इंटेंट के लिए, डेवलपर की उम्मीदों को पूरा करने वाली गतिविधि दिखाने के लिए, इन इंटेंट का पालन करना ज़रूरी है: 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] MUST honor the 'android.bluetooth.adapter.action.REQUEST_DISCOVERABLE' intent and show a system activity that requests discoverable mode.

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

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

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

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

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

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

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

• [C-9-1] एसडीके के दस्तावेज़ में बताए गए तरीके के मुताबिक, Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI इंटेंट एपीआई लागू करने होंगे.

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

• [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] एसडीके दस्तावेज़ में बताए गए तरीके से, इन इंटेंट को मैनेज करना ज़रूरी है. साथ ही, सिर्फ़ पहले से इंस्टॉल किए गए Android ऐप्लिकेशन को इन इंटेंट को मैनेज करने की अनुमति देना ज़रूरी है: MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE, और MediaStore.ACTION_VIDEO_CAPTURE.

अगर डिवाइसों के लिए लागू की गई सुविधाओं की रिपोर्ट android.software.device_admin है, तो:

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

• [C-13-2] MUST honor the intents 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 and have an activity to provide fulfillment for these intents as described in SDK here.

अगर डिवाइसों में 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 इंटेंट पैटर्न को हैंडल करती हो. हालांकि, इसे no-op के तौर पर लागू किया जाना चाहिए. इसका मतलब है कि इसका व्यवहार वैसा ही होना चाहिए जैसा तब होता है, जब उपयोगकर्ता को ऐक्सेस देने से मना कर दिया जाता है.

अगर डिवाइस पर लागू किए गए सिस्टम, सेटिंग में 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 इंटेंट को पूरा करने के लिए, गतिविधि का इस्तेमाल करने का सुझाव दिया जाता है. इसके बारे में एसडीके में यहां बताया गया है.

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

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

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

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

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

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

• [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 Activities लॉन्च करने की अनुमति है और सेकंडरी डिसप्ले में android.view.Display.FLAG_PRIVATE फ़्लैग है, तो:

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

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

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

• [C-SR-1] हमारा सुझाव है कि अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट से, यहां दी गई लाइब्रेरी के वर्शन इस्तेमाल करें.

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

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

डिवाइस में सेट किए गए सिस्टम के लिए:

• [C-0-1] यह एक या उससे ज़्यादा तय किए गए Android NDK ABIs के साथ काम करना चाहिए.
• [C-0-2] इसमें मैनेज किए जा रहे एनवायरमेंट में चलने वाले कोड के लिए, नेटिव कोड को कॉल करने की सुविधा शामिल होनी चाहिए. इसके लिए, स्टैंडर्ड Java Native Interface (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
  • riscv64

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

  • libaaudio.so (AAudio नेटिव ऑडियो सपोर्ट)
  • libamidi.so (अगर सुविधा android.software.midi का दावा सेक्शन 5.9 में बताए गए तरीके से किया गया है, तो नेटिव 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] सिस्टम लाइब्रेरी के तौर पर AOSP में लागू की गई और उपलब्ध कराई गई किसी भी अन्य नेटिव लाइब्रेरी को, तीसरे पक्ष के उन ऐप्लिकेशन के लिए उपलब्ध नहीं कराया जाना चाहिए जो एपीआई लेवल 24 या इससे ज़्यादा को टारगेट करते हैं. ऐसा इसलिए, क्योंकि ये लाइब्रेरी रिज़र्व होती हैं.

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

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

• इसे अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट में उपलब्ध सोर्स कोड और हेडर फ़ाइलों का इस्तेमाल करके बनाया जाना चाहिए.

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

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

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

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

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

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

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

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

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

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

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

3.4.1. WebView के साथ काम करना

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

• [C-1-1] android.software.webview की जानकारी देना ज़रूरी है.

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

• [C-1-3] SDK लेवल 36 या इससे पहले के वर्शन को टारगेट करने वाले ऐप्लिकेशन के लिए, WebView से रिपोर्ट की गई उपयोगकर्ता एजेंट स्ट्रिंग इस फ़ॉर्मैट में होनी चाहिए:

  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 का वर्शन होना चाहिए.

  • डिवाइस लागू करने वाले लोग, उपयोगकर्ता एजेंट स्ट्रिंग में मोबाइल को शामिल न करें.

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

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

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

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

• [C-1-1] MUST support each of these APIs associated with HTML5:

  • application cache/offline operation
  • <video> टैग
  • जियोलोकेशन

• [C-1-2] MUST support the HTML5/W3C webstorage API and SHOULD support the HTML5/W3C IndexedDB API. ध्यान दें कि वेब डेवलपमेंट के स्टैंडर्ड तय करने वाली संस्थाएं, वेबस्टोरेज के बजाय IndexedDB को प्राथमिकता दे रही हैं. इसलिए, उम्मीद है कि Android के आने वाले वर्शन में IndexedDB को शामिल करना ज़रूरी हो जाएगा.

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

• स्टैंडअलोन ब्राउज़र ऐप्लिकेशन पर, ज़्यादा से ज़्यादा HTML5 के साथ काम करना चाहिए. यह अपस्ट्रीम WebKit ब्राउज़र ऐप्लिकेशन या तीसरे पक्ष के ब्राउज़र ऐप्लिकेशन पर आधारित हो सकता है.

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

• [C-2-1] को अब भी सार्वजनिक इंटेंट पैटर्न के साथ काम करना होगा. इनके बारे में section 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. ईसा पूर्व - 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 ओपन सोर्स प्रोजेक्ट के साथ व्यवहार से जुड़ी सेटिंग काम करती हों. यह ज़िम्मेदारी, इस सुविधा को लागू करने वाले व्यक्ति या कंपनी की होती है. इसलिए, डिवाइस बनाने वाली कंपनियों को जहां तक हो सके, Android ओपन सोर्स प्रोजेक्ट के ज़रिए उपलब्ध सोर्स कोड का इस्तेमाल करना चाहिए. इसके बजाय, उन्हें सिस्टम के अहम हिस्सों को फिर से लागू नहीं करना चाहिए.

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] को सेक्शन 3.5.1 में दी गई सभी ज़रूरी शर्तों को पूरा करना होगा. हालांकि, [C-1-6] और [C-1-3] को छोड़कर.
• [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-भाषा के सिग्नेचर पर कोई असर नहीं पड़ना चाहिए.
• [C-0-4] इसका विज्ञापन नहीं किया जाना चाहिए या इसे डेवलपर को नहीं दिखाया जाना चाहिए.

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

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

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

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

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

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

3.7. रनटाइम के साथ काम करता है या नहीं

डिवाइस में सेट किए गए सिस्टम के लिए:

• [C-0-1] इसमें पूरे Dalvik Executable (DEX) फ़ॉर्मैट और Dalvik bytecode specification and semantics के साथ काम करना ज़रूरी है.

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

• Android RunTime (ART) का इस्तेमाल करना चाहिए. यह Dalvik Executable Format का रेफ़रंस अपस्ट्रीम इम्प्लीमेंटेशन है. साथ ही, रेफ़रंस इम्प्लीमेंटेशन के पैकेज मैनेजमेंट सिस्टम का इस्तेमाल करना चाहिए.

• अलग-अलग मोड में फ़ज़ टेस्ट किए जाने चाहिए. साथ ही, रनटाइम की स्थिरता को पक्का करने के लिए, आर्किटेक्चर को टारगेट किया जाना चाहिए. Android ओपन सोर्स प्रोजेक्ट की वेबसाइट पर, JFuzz और DexFuzz के बारे में पढ़ें.

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

स्क्रीन लेआउट	स्क्रीन की सघनता	ऐप्लिकेशन के लिए कम से कम मेमोरी
Android Watch	120 डीपीआई (ldpi)	32 एमबी
	140 डीपीआई (140dpi)
	160 डीपीआई (एमडीपीआई)
	180 डीपीआई (180dpi)
	200 डीपीआई (200dpi)
	213 डीपीआई (टीवीडीपीआई)
	220 डीपीआई (220dpi)	36 एमबी
	240 डीपीआई (hdpi)
	280 डीपीआई (280dpi)
	320 dpi (xhdpi)	48 एमबी
	360 डीपीआई (360dpi)
	400 डीपीआई (400dpi)	56 एमबी
	420 डीपीआई (420dpi)	64 एमबी
	480 dpi (xxhdpi)	88 एमबी
	560 डीपीआई (560dpi)	112 एमबी
	640 dpi (xxxhdpi)	154 एमबी
छोटा/सामान्य	120 डीपीआई (ldpi)	32 एमबी
	140 डीपीआई (140dpi)
	160 डीपीआई (एमडीपीआई)
	180 डीपीआई (180dpi)	48 एमबी
	200 डीपीआई (200dpi)
	213 डीपीआई (टीवीडीपीआई)
	220 डीपीआई (220dpi)
	240 डीपीआई (hdpi)
	280 डीपीआई (280dpi)
	320 dpi (xhdpi)	80MB
	360 डीपीआई (360dpi)
	400 डीपीआई (400dpi)	96 एमबी
	420 डीपीआई (420dpi)	112 एमबी
	480 dpi (xxhdpi)	128 एमबी
	560 डीपीआई (560dpi)	192 एमबी
	640 dpi (xxxhdpi)	256 एमबी
बड़ा	120 डीपीआई (ldpi)	32 एमबी
	140 डीपीआई (140dpi)	48 एमबी
	160 डीपीआई (एमडीपीआई)
	180 डीपीआई (180dpi)	80MB
	200 डीपीआई (200dpi)
	213 डीपीआई (टीवीडीपीआई)
	220 डीपीआई (220dpi)
	240 डीपीआई (hdpi)
	280 डीपीआई (280dpi)	96 एमबी
	320 dpi (xhdpi)	128 एमबी
	360 डीपीआई (360dpi)	160 एमबी
	400 डीपीआई (400dpi)	192 एमबी
	420 डीपीआई (420dpi)	228MB
	480 dpi (xxhdpi)	256 एमबी
	560 डीपीआई (560dpi)	384MB
	640 dpi (xxxhdpi)	512 एमबी
xlarge	120 डीपीआई (ldpi)	48 एमबी
	140 डीपीआई (140dpi)	80MB
	160 डीपीआई (एमडीपीआई)
	180 डीपीआई (180dpi)	96 एमबी
	200 डीपीआई (200dpi)
	213 डीपीआई (टीवीडीपीआई)
	220 डीपीआई (220dpi)
	240 डीपीआई (hdpi)
	280 डीपीआई (280dpi)	144MB
	320 dpi (xhdpi)	192 एमबी
	360 डीपीआई (360dpi)	240 एमबी
	400 डीपीआई (400dpi)	288MB
	420 डीपीआई (420dpi)	336 एमबी
	480 dpi (xxhdpi)	384MB
	560 डीपीआई (560dpi)	576 एमबी
	640 dpi (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() एपीआई के तरीके से अनुरोध किए गए शॉर्टकट को जोड़ने से पहले, उपयोगकर्ता से अनुमति मांगना ज़रूरी है.

• [C-2-3] ऐप शॉर्टकट वाले पेज पर दिए गए दस्तावेज़ के मुताबिक, पिन किए गए शॉर्टकट और डाइनैमिक और स्टैटिक शॉर्टकट काम करने चाहिए.

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

• [C-3-1] ShortcutManager.isRequestPinShortcutSupported() के लिए, false की जानकारी देना ज़रूरी है.

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

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

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

• [C-5-1] NotificationChannel.setShowBadge() एपीआई के तरीके का पालन करना ज़रूरी है. दूसरे शब्दों में कहें, तो अगर वैल्यू को true के तौर पर सेट किया गया है, तो ऐप्लिकेशन के आइकॉन से जुड़ा विज़ुअल अफ़ॉर्डेंस दिखाएं. साथ ही, जब ऐप्लिकेशन के सभी सूचना चैनलों ने वैल्यू को false के तौर पर सेट किया हो, तब ऐप्लिकेशन के आइकॉन बैजिंग की कोई भी स्कीम न दिखाएं.

• तीसरे पक्ष के ऐप्लिकेशन, मालिकाना हक वाले एपीआई का इस्तेमाल करके, मालिकाना हक वाली बैजिंग स्कीम के साथ काम करने की सुविधा देते हैं. ऐसे में, MAY, ऐप्लिकेशन के आइकॉन बैज को मालिकाना हक वाली बैजिंग स्कीम से बदल सकता है. हालांकि, उसे एसडीके में बताए गए, सूचना बैज वाले एपीआई के ज़रिए उपलब्ध कराए गए संसाधनों और वैल्यू का इस्तेमाल करना चाहिए. जैसे, Notification.Builder.setNumber() और Notification.Builder.setBadgeIconType() एपीआई.

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

• [C-6-1] इनका इस्तेमाल सिर्फ़ तब किया जाना चाहिए, जब कोई उपयोगकर्ता इन्हें साफ़ तौर पर चालू करता है. उदाहरण के लिए, सेटिंग या वॉलपेपर चुनने वाले मेन्यू के ज़रिए.

3.8.2. विजेट

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

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

• लॉक स्क्रीन पर ऐप्लिकेशन विजेट दिखाने की सुविधा दे सकता है.

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

• [C-2-1] AppWidgetManager.html.isRequestPinAppWidgetSupported() के लिए true की जानकारी देना ज़रूरी है.

• [C-2-2] ऐप्लिकेशन के ज़रिए AppWidgetManager.requestPinAppWidget() एपीआई तरीके से अनुरोध किए गए शॉर्टकट को जोड़ने से पहले, उपयोगकर्ता से अनुमति मांगना ज़रूरी है.

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] एसडीके में, 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] यह सुझाव दिया जाता है कि उपयोगकर्ता के लिए, किसी तीसरे पक्ष के ऐप्लिकेशन की सूचना को हर चैनल और ऐप्लिकेशन पैकेज लेवल पर ब्लॉक करने की सुविधा अपने-आप चालू हो जाए. ऐसा तब होना चाहिए, जब उपयोगकर्ता उस सूचना को कई बार खारिज कर दे.

• रिच सूचनाएं दिखाने की सुविधा होनी चाहिए.

• उसे ज़्यादा प्राथमिकता वाली कुछ सूचनाओं को, स्क्रीन पर सबसे ऊपर दिखने वाली सूचनाओं के तौर पर दिखाना चाहिए.

• सूचनाओं को स्नूज़ करने के लिए, उपयोगकर्ता के पास विकल्प होना चाहिए.

• MAY सिर्फ़ यह मैनेज कर सकता है कि तीसरे पक्ष के ऐप्लिकेशन, उपयोगकर्ताओं को अहम इवेंट के बारे में कब सूचना दे सकते हैं. इससे ड्राइवर का ध्यान भटकने जैसी सुरक्षा से जुड़ी समस्याओं को कम किया जा सकता है.

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

डिवाइस में सेट किए गए सिस्टम के लिए:

• [C-SR-4] बातचीत से जुड़ी सूचनाओं को ग्रुप करके दिखाने का सुझाव दिया जाता है. साथ ही, conversation notifications को बातचीत से जुड़ी सूचनाओं के अलावा अन्य सूचनाओं से पहले दिखाने का सुझाव दिया जाता है. हालांकि, फ़ोरग्राउंड सेवा से जुड़ी सूचनाएं और importance:high सूचनाएं इसके अपवाद हैं.

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

• [C-SR-5] इस बातचीत को बबल के तौर पर दिखाने का सुझाव दिया जाता है. AOSP में, डिफ़ॉल्ट सिस्टम यूज़र इंटरफ़ेस (यूआई), सेटिंग, और लॉन्चर के साथ इन ज़रूरी शर्तों को पूरा किया जाता है.

अगर डिवाइस में रिच नोटिफ़िकेशन की सुविधा काम करती है, तो:

• [C-2-1] MUST use the exact resources as provided through the Notification.Style API class and its subclasses for the presented resource elements.

• Notification.Style एपीआई क्लास और इसकी सबक्लास में तय किए गए हर संसाधन एलिमेंट (जैसे, आइकॉन, टाइटल, और खास जानकारी वाला टेक्स्ट) को दिखाना चाहिए.

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

• [C-3-1] सूचनाएं दिखाते समय, Notification.Builder API क्लास में बताए गए तरीके से, स्क्रीन पर सबसे ऊपर सूचना देने वाला कार्ड और संसाधनों का इस्तेमाल करना ज़रूरी है.

• [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] suppressedVisualEffects की वैल्यू को NotificationManager.Policy के साथ पास किया जाना चाहिए. साथ ही, अगर किसी ऐप्लिकेशन ने SUPPRESSED_EFFECT_SCREEN_OFF या SUPPRESSED_EFFECT_SCREEN_ON फ़्लैग में से कोई भी फ़्लैग सेट किया है, तो उसे उपयोगकर्ता को यह बताना चाहिए कि 'परेशान न करें' सेटिंग मेन्यू में विज़ुअल इफ़ेक्ट बंद कर दिए गए हैं.

3.8.3.4. संवेदनशील सूचनाओं को सुरक्षित रखने की सुविधा

सूचना में मौजूद संवेदनशील जानकारी में, एक बार इस्तेमाल होने वाले पासवर्ड, एक बार इस्तेमाल होने वाले पुष्टि करने के कोड, और पुष्टि करने या रीसेट करने के ऐसे ही कोड शामिल होते हैं. ये कोड, लोगों को सूचनाओं में दिख सकते हैं.

अगर डिवाइसों पर तीसरे पक्ष के ऐप्लिकेशन को उपयोगकर्ताओं को खास इवेंट की सूचनाएं भेजने की अनुमति है, तो:

• [C-1-1] सूचना सुनने वाली सेवाओं को संवेदनशील सूचना की जानकारी देने से पहले, उसे छिपाना ज़रूरी है. हालांकि, अगर सूचना सुनने वाली सेवा इनमें से कोई एक है, तो ऐसा करना ज़रूरी नहीं है:

  • सिस्टम के ज़रिए साइन किए गए ऐसे ऐप्लिकेशन जिनके लिए uid < 10000
  • सिस्टम यूज़र इंटरफ़ेस (यूआई)
  • शेल
  • कंपैनियन डिवाइस के लिए तय किया गया ऐप्लिकेशन (CompanionDeviceManager के हिसाब से तय किया गया)
  • SYSTEM_AUTOMOTIVE_PROJECTION भूमिका
  • SYSTEM_NOTIFICATION_INTELLIGENCE भूमिका
  • HOME role

NotificationAssistantServices को AOSP में लागू करने से, इन ज़रूरी शर्तों के बारे में पता चलता है और ये पूरी होती हैं. उदाहरण के लिए, android.ext.services.notification देखें.

3.8.4. Assist API

Android में सहायता करने वाले एपीआई शामिल हैं. इनकी मदद से, ऐप्लिकेशन यह तय कर सकते हैं कि डिवाइस पर मौजूद असिस्टेंट के साथ मौजूदा कॉन्टेक्स्ट की कितनी जानकारी शेयर की जाए.

• [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] जिन भाषाओं के लिए Roboto उपलब्ध है उनके लिए, "sans-serif" फ़ॉन्ट फ़ैमिली को Roboto वर्शन 2.x पर सेट करना ज़रूरी है. इसके अलावा, यह भी ज़रूरी है कि उपयोगकर्ताओं को "sans-serif" फ़ॉन्ट फ़ैमिली के लिए इस्तेमाल किए गए फ़ॉन्ट को Roboto वर्शन 2.x पर बदलने का विकल्प दिया जाए. यह विकल्प उन भाषाओं के लिए उपलब्ध होना चाहिए जिनके लिए Roboto उपलब्ध है.

• [C-1-4] AOSP के Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES के दस्तावेज़ में बताए गए तरीके से, डाइनैमिक कलर टोनल पैलेट जनरेट करना ज़रूरी है (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 के साथ भेजा जाता है. इसके बारे में 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] कम से कम सात गतिविधियों को दिखाने की सुविधा होनी चाहिए.

• एक बार में कम से कम चार गतिविधियों के टाइटल दिखने चाहिए.

• हाल के ऐप्लिकेशन में, हाइलाइट करने के लिए इस्तेमाल किया गया रंग, आइकॉन, और स्क्रीन का टाइटल दिखना चाहिए.

• बंद करने का विकल्प ("x") दिखना चाहिए. हालांकि, उपयोगकर्ता के स्क्रीन से इंटरैक्ट करने तक इसे छिपाया जा सकता है.

• पिछली गतिविधि पर आसानी से स्विच करने के लिए, शॉर्टकट लागू करना चाहिए.

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

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

• ऐसा हो सकता है कि यह अफ़िलिएट किए गए हाल ही के आइटम को एक ऐसे ग्रुप के तौर पर दिखाए जो एक साथ मूव करता है.

• [C-SR-1] ओवरव्यू स्क्रीन के लिए, अपस्ट्रीम Android यूज़र इंटरफ़ेस (या थंबनेल पर आधारित मिलता-जुलता इंटरफ़ेस) इस्तेमाल करने का सुझाव दिया जाता है.

3.8.9. इनपुट मैनेजमेंट

Android में इनपुट मैनेजमेंट की सुविधा उपलब्ध है. साथ ही, इसमें तीसरे पक्ष के इनपुट मेथड एडिटर का इस्तेमाल किया जा सकता है.

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

• [C-1-1] प्लैटफ़ॉर्म की सुविधा android.software.input_methods का एलान करना ज़रूरी है. साथ ही, Android SDK के दस्तावेज़ में बताए गए IME API के साथ काम करना ज़रूरी है.

3.8.10. लॉक स्क्रीन पर मीडिया कंट्रोल करने की सुविधा

Android 5.0 से, Remote Control Client API को बंद कर दिया गया है. इसके बजाय, Media Notification Template का इस्तेमाल किया जाता है. इससे मीडिया ऐप्लिकेशन, लॉक स्क्रीन पर दिखने वाले प्लेबैक कंट्रोल के साथ इंटिग्रेट हो पाते हैं.

3.8.11. स्क्रीन सेवर (पहले इन्हें ड्रीम कहा जाता था)

स्क्रीन सेवर कॉन्फ़िगर करने के लिए, सेटिंग के बारे में जानने के लिए सेक्शन 3.2.3.5 देखें.

3.8.12. जगह

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

• [C-1-2] सेटिंग में मौजूद लोकेशन मेन्यू में, जगह की जानकारी का मौजूदा स्टेटस दिखाना ज़रूरी है.

• [C-1-3] सेटिंग में मौजूद जगह की जानकारी के मेन्यू में, जगह की जानकारी के मोड नहीं दिखने चाहिए.

3.8.13. यूनिकोड और फ़ॉन्ट

Android में, Unicode 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.

  • लैटिन, ग्रीक, और सिरिलिक के लिए, Unicode 7.0 का पूरा कवरेज. इसमें लैटिन एक्सटेंडेड ए, बी, सी, और डी रेंज के साथ-साथ, Unicode 7.0 के मुद्रा के चिह्न वाले ब्लॉक में मौजूद सभी ग्लिफ़ शामिल हैं.

• [C-1-3] सिस्टम इमेज में मौजूद NotoColorEmoji.tff को न तो हटाया जाना चाहिए और न ही उसमें बदलाव किया जाना चाहिए. (NotoColorEmoji.tff में इमोजी को ओवरराइड करने के लिए, नया इमोजी फ़ॉन्ट जोड़ा जा सकता है)

• इसमें स्किन टोन और अलग-अलग तरह के परिवार वाले इमोजी शामिल होने चाहिए. इनके बारे में यूनिकोड टेक्निकल रिपोर्ट #51 में बताया गया है.

अगर डिवाइस में IME शामिल है, तो:

• उपयोगकर्ता को इन इमोजी वर्णों के लिए, इनपुट का तरीका उपलब्ध कराना चाहिए.

Android में, म्यांमार के फ़ॉन्ट रेंडर करने की सुविधा शामिल है. म्यांमार की भाषाओं को रेंडर करने के लिए, म्यांमार में यूनिकोड के साथ काम न करने वाले कई फ़ॉन्ट उपलब्ध हैं. इन्हें आम तौर पर "Zawgyi" के नाम से जाना जाता है.

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

• [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] Android 16 में इस ज़रूरी शर्त को हटा दिया गया है.

• [C-1-3] अगर स्क्रीन की ऊंचाई 440 डीपी से कम है और स्क्रीन की चौड़ाई 440 डीपी से कम है, तो स्प्लिट-स्क्रीन या फ़्रीफ़ॉर्म मोड की सुविधा नहीं दी जानी चाहिए.

• [C-1-4] मल्टी-विंडो मोड में, किसी गतिविधि का साइज़ 220 dp से कम नहीं होना चाहिए. हालांकि, पिक्चर-इन-पिक्चर मोड में ऐसा किया जा सकता है.

• स्क्रीन साइज़ xlarge वाले डिवाइसों में, फ़्रीफ़ॉर्म मोड काम करना चाहिए.

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

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

• [C-2-3] MUST honor the declared AndroidManifestLayout_minWidth and AndroidManifestLayout_minHeight values of the third-party launcher application and not override these values in the course of showing some content of the docked activity.

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

• [C-3-1] ऐप्लिकेशन के इन मामलों में, गतिविधि को पिक्चर में पिक्चर वाले मल्टी-विंडो मोड में लॉन्च करना ज़रूरी है:

  • एपीआई लेवल 26 या उसके बाद के वर्शन को टारगेट करता हो और android:supportsPictureInPicture का एलान करता हो

  • एपीआई लेवल 25 या इससे पहले के लेवल को टारगेट कर रहा हो और android:resizeableActivity और android:supportsPictureInPicture, दोनों का एलान कर रहा हो.

• [C-3-2] setActions() एपीआई के ज़रिए, सिस्टमयूआई में कार्रवाइयों को दिखाना ज़रूरी है. ये कार्रवाइयां, मौजूदा पीआईपी गतिविधि के हिसाब से होनी चाहिए.

• [C-3-3] setAspectRatio() एपीआई के ज़रिए पीआईपी गतिविधि के लिए तय किए गए, 1:2.39 से ज़्यादा या इसके बराबर और 2.39:1 से कम या इसके बराबर के आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) के साथ काम करना चाहिए.

• [C-3-4] PIP विंडो को कंट्रोल करने के लिए, KeyEvent.KEYCODE_WINDOW का इस्तेमाल करना ज़रूरी है. अगर PIP मोड लागू नहीं किया गया है, तो यह कुंजी फ़ोरग्राउंड गतिविधि के लिए उपलब्ध होनी चाहिए.

• [C-3-5] ऐप्लिकेशन को पीआईपी मोड में दिखने से रोकने के लिए, उपयोगकर्ता को एक विकल्प देना होगा. AOSP में इस सुविधा को लागू करने के लिए, सूचना पैनल में कंट्रोल दिए गए हैं.

• [C-3-6] जब कोई ऐप्लिकेशन AndroidManifestLayout_minWidth और AndroidManifestLayout_minHeight के लिए कोई वैल्यू तय नहीं करता है, तो उसे पीआईपी विंडो के लिए कम से कम इतनी चौड़ाई और ऊंचाई तय करनी होगी:

  • जिन डिवाइसों में Configuration.uiMode को UI_MODE_TYPE_TELEVISION के अलावा किसी और वैल्यू पर सेट किया गया है उनमें कम से कम 108 dp की चौड़ाई और लंबाई होनी चाहिए.

  • Configuration.uiMode को UI_MODE_TYPE_TELEVISION पर सेट करने वाले डिवाइसों को, कम से कम 240 dp की चौड़ाई और 135 dp की ऊंचाई देनी होगी.

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

• [C-4-1] मल्टी-विंडो मोड के साथ काम करना ज़रूरी है.

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

• [C-5-1] WindowManager एक्सटेंशन में बताए गए तरीके के मुताबिक, Window Manager Extensions के एपीआई लेवल का सही वर्शन लागू करना ज़रूरी है.

3.8.15. डिसप्ले कटआउट

Android, डिसप्ले कटआउट की सुविधा के साथ काम करता है. इसके बारे में एसडीके के दस्तावेज़ में बताया गया है. 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.8.18. लोकेशन बटन

3.9. डिवाइस प्रबंधन

Android में ऐसी सुविधाएं शामिल हैं जिनकी मदद से, डिवाइस नीति कंट्रोलर ऐप्लिकेशन, सिस्टम लेवल पर डिवाइस एडमिनिस्ट्रेशन फ़ंक्शन कर सकते हैं. जैसे, Device Policy Manager API के ज़रिए पासवर्ड से जुड़ी नीतियां लागू करना या दूर से डिवाइस का डेटा मिटाना.

3.9.1. डिवाइस प्रॉविज़निंग

3.9.1.1. डिवाइस के मालिक के लिए प्रॉविज़निंग

अगर डिवाइसों में android.software.device_admin का एलान किया जाता है, तो:

• [C-1-1] डिवाइस में, Device Policy Controller (DPC) को डिवाइस के मालिक के तौर पर काम करने वाले ऐप्लिकेशन के तौर पर रजिस्टर करने की सुविधा होनी चाहिए. इसके बारे में यहां बताया गया है:

  • अगर डिवाइस पर उपयोगकर्ताओं और उपयोगकर्ता के डेटा, दोनों में से किसी को भी कॉन्फ़िगर नहीं किया गया है, तो:

    • [C-1-5] अगर डिवाइस, फ़ीचर फ़्लैग android.hardware.nfc के ज़रिए नियर-फ़ील्ड कम्यूनिकेशन (एनएफ़सी) की सुविधा उपलब्ध होने की जानकारी देता है और उसे MIME_TYPE_PROVISIONING_NFC एमआईएमई टाइप वाला रिकॉर्ड शामिल करने वाला एनएफ़सी मैसेज मिलता है, तो DPC ऐप्लिकेशन को डिवाइस के मालिक वाले ऐप्लिकेशन के तौर पर रजिस्टर करना होगा. इसके अलावा, DPC ऐप्लिकेशन को यह चुनने की अनुमति देनी होगी कि उसे डिवाइस का मालिक बनना है या प्रोफ़ाइल का मालिक.

    • [C-1-8] डिवाइस के मालिक के तौर पर डिवाइस को सेट अप करने की प्रोसेस शुरू होने के बाद, DPC ऐप्लिकेशन को ACTION_GET_PROVISIONING_MODE इंटेंट भेजना ज़रूरी है. इससे DPC ऐप्लिकेशन यह तय कर पाएगा कि उसे डिवाइस का मालिक बनना है या प्रोफ़ाइल का मालिक. यह फ़ैसला android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES की वैल्यू के आधार पर लिया जाएगा. हालांकि, अगर कॉन्टेक्स्ट से यह पता चलता है कि सिर्फ़ एक मान्य विकल्प है, तो ऐसा करने की ज़रूरत नहीं है.

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

  • अगर डिवाइस पर उपयोगकर्ता या उपयोगकर्ता का डेटा मौजूद है, तो:

    • [C-1-7] अब किसी भी DPC ऐप्लिकेशन को डिवाइस के मालिक के ऐप्लिकेशन के तौर पर रजिस्टर नहीं करना चाहिए.

• [C-1-2] Android 15 में इस ज़रूरी शर्त को हटा दिया गया है.

• [C-2-1] Android 15 में यह ज़रूरी शर्त हटा दी गई है.

• [C-2-2] Android 15 में इस ज़रूरी शर्त को हटा दिया गया है.

• [C-2-3] Android 15 में इस ज़रूरी शर्त को हटा दिया गया है.

3.9.1.2. मैनेज की जा रही प्रोफ़ाइल को उपलब्ध कराना

अगर डिवाइसों में android.software.managed_users का एलान किया जाता है, तो:

• [C-1-1] android.software.device_admin को यह एलान करना होगा कि वह एपीआई लागू करेगा. इससे डिवाइस पॉलिसी कंट्रोलर (डीपीसी) ऐप्लिकेशन, मैनेज की जा रही नई प्रोफ़ाइल का मालिक बन सकेगा.

• [C-1-2] Android 16 में इस ज़रूरी शर्त को हटा दिया गया है.

• [C-1-3] सेटिंग में उपयोगकर्ता को ये सुविधाएं मिलनी चाहिए, ताकि उसे यह पता चल सके कि डिवाइस नीति कंट्रोलर (डीपीसी) ने किसी सिस्टम फ़ंक्शन को कब बंद किया है:

  • किसी सेटिंग पर डिवाइस एडमिन की पाबंदी होने पर, उसे दिखाने के लिए एक जैसा आइकॉन या उपयोगकर्ता के लिए उपलब्ध अन्य सुविधा (उदाहरण के लिए, अपस्ट्रीम एओएसपी की जानकारी देने वाला आइकॉन).
  • डिवाइस एडमिन ने setShortSupportMessage के ज़रिए, कम शब्दों में जानकारी देने वाला मैसेज भेजा है.
  • डीपीसी ऐप्लिकेशन का आइकॉन.

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

• [C-1-5] ACTION_PROFILE_PROVISIONING_COMPLETE ब्रॉडकास्ट को वर्क प्रोफ़ाइल DPC को भेजना ज़रूरी है. ऐसा तब करना होगा, जब android.app.action.PROVISION_MANAGED_PROFILE इंटेंट से प्रोविज़निंग शुरू की गई हो.

• [C-1-6] प्रोफ़ाइल के मालिक के लिए डिवाइस सेट अप करने की प्रोसेस शुरू होने के बाद, DPC ऐप्लिकेशन को ACTION_GET_PROVISIONING_MODE इंटेंट भेजना ज़रूरी है. इससे DPC ऐप्लिकेशन यह तय कर पाएगा कि उसे डिवाइस का मालिक बनना है या प्रोफ़ाइल का मालिक. हालांकि, अगर डिवाइस सेट अप करने की प्रोसेस, android.app.action.PROVISION_MANAGED_PROFILE इंटेंट से शुरू होती है, तो ऐसा नहीं किया जा सकता.

• [C-1-7] प्रोफ़ाइल के मालिक के तौर पर किसी व्यक्ति को सेट अप करने के दौरान, वर्क प्रोफ़ाइल को ACTION_ADMIN_POLICY_COMPLIANCE इंटेंट भेजना ज़रूरी है. भले ही, सेट अप करने के लिए किसी भी तरीके का इस्तेमाल किया गया हो. हालांकि, ऐसा तब नहीं किया जाएगा, जब सेट अप करने की प्रोसेस को android.app.action.PROVISION_MANAGED_PROFILE इंटेंट से ट्रिगर किया गया हो. जब तक प्रोफ़ाइल के मालिक का ऐप्लिकेशन पूरा नहीं हो जाता, तब तक उपयोगकर्ता को सेटअप विज़र्ड में आगे बढ़ने की अनुमति नहीं मिलनी चाहिए.

• [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 ओपन सोर्स प्रोजेक्ट की साइट पर बताया गया है.

  • डीपीसी की पासवर्ड नीतियां सिर्फ़ मैनेज की जा रही प्रोफ़ाइल की लॉक स्क्रीन के क्रेडेंशियल पर लागू होनी चाहिए. हालांकि, getParentProfileInstance से मिले DevicePolicyManager इंस्टेंस के लिए ऐसा नहीं है.

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

3.9.3. मैनेज किए जा रहे उपयोगकर्ता के लिए सहायता

अगर डिवाइसों में android.software.managed_users का एलान किया जाता है, तो:

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

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

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

3.9.4. डिवाइस की नीति मैनेज करने की भूमिका के लिए ज़रूरी शर्तें

अगर डिवाइसों में android.software.device_admin का एलान किया जाता है, तो:

• [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. Device Policy Resolution Framework

अगर डिवाइसों में android.software.device_admin का एलान किया जाता है, तो:

• [C-1-1] डिवाइस की नीति से जुड़े टकरावों को हल करना होगा. इसके बारे में डिवाइस की नीति से जुड़े टकरावों को हल करने का फ़्रेमवर्क में बताया गया है.

3.10. सुलभता

Android में सुलभता की एक लेयर होती है. इससे दिव्यांग लोगों को अपने डिवाइसों को आसानी से नेविगेट करने में मदद मिलती है. इसके अलावा, Android ऐसे प्लैटफ़ॉर्म API उपलब्ध कराता है जिनकी मदद से, सुलभता सेवा को लागू किया जा सकता है. इससे, उपयोगकर्ता और सिस्टम इवेंट के लिए कॉलबैक मिलते हैं. साथ ही, लिखे गए शब्दों को सुनने की सुविधा, हैप्टिक फ़ीडबैक, और ट्रैकबॉल/डी-पैड नेविगेशन जैसे फ़ीडबैक के अन्य तरीके जनरेट किए जा सकते हैं.

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

• [C-1-1] Accessibility API के एसडीके दस्तावेज़ में बताए गए तरीके के मुताबिक, Android के सुलभता फ़्रेमवर्क को लागू करना ज़रूरी है.
• [C-1-2] SDK में दिए गए दस्तावेज़ के मुताबिक, सुलभता इवेंट जनरेट करने होंगे और सभी रजिस्टर किए गए AccessibilityService को सही AccessibilityEvent डिलीवर करने होंगे.
• [C-1-4] उपयोगकर्ता को ऐक्सेसिबिलिटी सेवाओं को कंट्रोल करने की सुविधा देनी होगी. ये सेवाएं, AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON का एलान करती हैं. ध्यान दें कि सिस्टम नेविगेशन बार वाले डिवाइसों में, उपयोगकर्ताओं को सिस्टम के नेविगेशन बार में एक बटन का विकल्प देना चाहिए. इससे वे इन सेवाओं को कंट्रोल कर पाएंगे.

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

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

3.11. लिखे गए शब्दों को सुनने की सुविधा

Android में ऐसे एपीआई शामिल हैं जिनकी मदद से ऐप्लिकेशन, टेक्स्ट-टू-स्पीच (टीटीएस) सेवाओं का इस्तेमाल कर सकते हैं. साथ ही, सेवा देने वाली कंपनियां टीटीएस सेवाओं को लागू कर सकती हैं.

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

• [C-1-1] ज़रूरी है कि इसमें Android TTS फ़्रेमवर्क एपीआई काम करते हों.

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

• [C-2-1] उपयोगकर्ता को सिस्टम लेवल पर इस्तेमाल करने के लिए, टीटीएस इंजन चुनने की सुविधा मिलनी चाहिए.

3.12. लागू नहीं

3.13. क्विक सेटिंग

Android में क्विक सेटिंग का यूज़र इंटरफ़ेस (यूआई) कॉम्पोनेंट होता है. इससे, अक्सर इस्तेमाल की जाने वाली या तुरंत ज़रूरी कार्रवाइयों को तुरंत ऐक्सेस किया जा सकता है.

अगर डिवाइस में क्विक सेटिंग यूज़र इंटरफ़ेस (यूआई) कॉम्पोनेंट शामिल है और यह तीसरे पक्ष की क्विक सेटिंग के साथ काम करता है, तो:

• [C-1-1] तीसरे पक्ष के ऐप्लिकेशन से quicksettings API के ज़रिए उपलब्ध कराई गई टाइलों को जोड़ने या हटाने की अनुमति उपयोगकर्ता को मिलनी चाहिए.
• [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

अगर डिवाइस में 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] उपयोगकर्ता को यह चुनने/पुष्टि करने की सुविधा देनी होगी कि कंपैनियन डिवाइस मौजूद है और काम कर रहा है. इसके लिए, AOSP में लागू किए गए मैसेज का इस्तेमाल करना होगा. इसमें कोई बदलाव नहीं किया जा सकता.

3.17. ज़्यादा संसाधन इस्तेमाल करने वाले ऐप्लिकेशन

अगर डिवाइसों में FEATURE_CANT_SAVE_STATE सुविधा का एलान किया जाता है, तो:

• [C-1-1] सिस्टम में एक बार में सिर्फ़ एक ऐसा इंस्टॉल किया गया ऐप्लिकेशन होना चाहिए जो cantSaveState को चालू कर सके. अगर उपयोगकर्ता किसी ऐप्लिकेशन को बंद किए बिना छोड़ देता है (उदाहरण के लिए, सिस्टम में चालू गतिविधि को छोड़ते समय, बैक बटन दबाने के बजाय होम बटन दबाता है), तो डिवाइसों को RAM में उस ऐप्लिकेशन को प्राथमिकता देनी चाहिए. ऐसा इसलिए, क्योंकि अन्य ऐप्लिकेशन को भी चालू रहने की ज़रूरत होती है. जैसे, फ़ोरग्राउंड सेवाएं. जब ऐसा ऐप्लिकेशन बैकग्राउंड में होता है, तब भी सिस्टम इस पर पावर मैनेजमेंट की सुविधाएं लागू कर सकता है. जैसे, सीपीयू और नेटवर्क ऐक्सेस को सीमित करना.
• [C-1-2] उपयोगकर्ता के cantSaveState एट्रिब्यूट के साथ घोषित किए गए दूसरे ऐप्लिकेशन को लॉन्च करने के बाद, यूज़र इंटरफ़ेस (यूआई) में एक ऐसा विकल्प होना चाहिए जिससे उपयोगकर्ता उस ऐप्लिकेशन को चुन सके जो सामान्य स्थिति में सेव/रीस्टोर करने की सुविधा में हिस्सा नहीं लेगा.
• [C-1-3] नीति में किए गए अन्य बदलावों को उन ऐप्लिकेशन पर लागू नहीं किया जाना चाहिए जिनमें cantSaveState की जानकारी दी गई है. जैसे, सीपीयू की परफ़ॉर्मेंस में बदलाव करना या शेड्यूलिंग की प्राथमिकता में बदलाव करना.

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

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

3.18. संपर्क

Android में Contacts Provider एपीआई शामिल हैं. इनकी मदद से, ऐप्लिकेशन को डिवाइस पर सेव की गई संपर्क जानकारी को मैनेज करने की अनुमति मिलती है. डिवाइस में सीधे तौर पर डाला गया संपर्क डेटा आम तौर पर, किसी वेब सेवा के साथ सिंक किया जाता है. हालांकि, ऐसा भी हो सकता है कि डेटा सिर्फ़ डिवाइस पर स्थानीय तौर पर मौजूद हो. सिर्फ़ डिवाइस पर सेव किए गए संपर्कों को लोकल संपर्क कहा जाता है.

RawContacts, किसी Account से "जुड़े होते हैं" या उसमें "स्टोर किए जाते हैं". ऐसा तब होता है, जब रॉ कॉन्टैक्ट के लिए ACCOUNT_NAME और ACCOUNT_TYPE कॉलम, खाते के Account.name और Account.type फ़ील्ड से मेल खाते हों.

डिफ़ॉल्ट लोकल खाता: यह ऐसे रॉ कॉन्टैक्ट के लिए होता है जो सिर्फ़ डिवाइस पर सेव होते हैं और AccountManager में मौजूद किसी खाते से जुड़े नहीं होते. इन्हें ACCOUNT_NAME और ACCOUNT_TYPE कॉलम के लिए null वैल्यू के साथ बनाया जाता है.

कस्टम लोकल खाता: यह ऐसे रॉ कॉन्टैक्ट के लिए होता है जो सिर्फ़ डिवाइस पर सेव होते हैं. ये 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] तीसरे पक्ष के ऐप्लिकेशन से डाले गए रॉ कॉन्टैक्ट, डिवाइस के डिफ़ॉल्ट कॉन्टैक्ट खाते में डाले जाने चाहिए. इसके लिए, खाते की जानकारी देना ज़रूरी नहीं है. अगर संपर्कों का डिफ़ॉल्ट खाता DEFAULT_ACCOUNT_STATE_LOCAL या DEFAULT_ACCOUNT_STATE_NOT_SET है, तो इन रॉ संपर्कों को कस्टम लोकल खाते में सेव करना होगा.

• [C-1-4] खातों को जोड़ने या हटाने पर, कस्टम लोकल खाते में डाले गए रॉ कॉन्टैक्ट नहीं हटाए जाने चाहिए.

• [C-1-5] कस्टम लोकल खाते से किए गए मिटाने के सभी ऑपरेशन के बाद, रॉ संपर्क तुरंत मिट जाने चाहिए. ऐसा तब भी होना चाहिए, जब CALLER_IS_SYNCADAPTER पैरामीटर को सही पर सेट किया गया हो. भले ही, CALLER_IS_SYNCADAPTER पैरामीटर को गलत पर सेट किया गया हो या उसे तय न किया गया हो.

3.18.2. सिस्टम कॉन्टैक्ट पिकर

3.19. भाषा की सेटिंग

डिवाइस में सेट किए गए सिस्टम के लिए:

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

3.20. Assistant की मदद से मिलने वाले अनुभव

3.20.1. Assistant की ऑडियो स्ट्रीम से जुड़ी ज़रूरी शर्तें

3.21. साथी डिवाइस को सिंक करने की सुविधाओं के साथ काम करता है

4. ऐप्लिकेशन पैकेजिंग की सुविधा के साथ काम करने की क्षमता

डिवाइसों में सेट किए गए सिस्टम के लिए:

• [C-0-1] Android के आधिकारिक Android SDK में शामिल "aapt" टूल से जनरेट की गई Android ".apk" फ़ाइलों को इंस्टॉल और चलाने की सुविधा होनी चाहिए.
  • ऊपर दी गई ज़रूरी शर्तें पूरी करना मुश्किल हो सकता है. इसलिए, डिवाइसों को AOSP के रेफ़रंस पैकेज मैनेजमेंट सिस्टम का इस्तेमाल करने का सुझाव दिया जाता है.

• [C-0-3] .apk, Android मेनिफ़ेस्ट, Dalvik बाइटकोड या RenderScript बाइटकोड फ़ॉर्मैट को इस तरह से नहीं बढ़ाया जाना चाहिए कि वे फ़ाइलें, ज़रूरी शर्तें पूरी करने वाले अन्य डिवाइसों पर सही तरीके से इंस्टॉल और रन न हो पाएं.

• [C-0-4] पैकेज के लिए, "इंस्टॉलर ऑफ़ रिकॉर्ड" के तौर पर सेट किए गए ऐप्लिकेशन के अलावा, किसी अन्य ऐप्लिकेशन को उपयोगकर्ता की पुष्टि के बिना ऐप्लिकेशन को साइलेंट तरीके से अनइंस्टॉल करने की अनुमति नहीं देनी चाहिए. इस बारे में, DELETE_PACKAGE अनुमति के लिए एसडीके में बताया गया है. सिर्फ़ दो मामलों में इस अनुमति की ज़रूरत नहीं होती. पहला, सिस्टम पैकेज वेरिफ़ायर ऐप्लिकेशन, 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 फ़ाइलों की पुष्टि करने की सुविधा होनी चाहिए.

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] पीसीएम/वेव
• [C-1-2] FLAC
• [C-1-3] Opus

सभी ऑडियो एन्कोडर में ये सुविधाएं होनी चाहिए:

• [C-3-1] android.media.MediaCodec एपीआई के ज़रिए, पीसीएम 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 प्रोफ़ाइल (AAC+)
• [C-1-3] MPEG-4 HE AACv2 प्रोफ़ाइल (बेहतर AAC+)
• [C-1-4] AAC ELD (बेहतर लो डिले एएसी)
• [C-1-5] FLAC
• [C-1-6] MP3
• [C-1-7] एमआईडीआई
• [C-1-8] Vorbis
• [C-1-9] पीसीएम/वेव, जिसमें 24 बिट, 192 किलोहर्ट्ज़ का सैंपलिंग रेट, और 8 चैनलों तक के हाई-रिज़ॉल्यूशन ऑडियो फ़ॉर्मैट शामिल हैं. ध्यान दें कि यह ज़रूरी शर्त सिर्फ़ डिकोडिंग के लिए है. साथ ही, किसी डिवाइस को प्लेबैक के दौरान डाउनसैंपल और डाउनमिक्स करने की अनुमति है.
• [C-1-10] Opus
• [C-1-11] xHE-AAC (ISO/IEC 23003-3 Extended HE AAC Profile, जिसमें USAC बेसलाइन प्रोफ़ाइल और ISO/IEC 23003-4 Dynamic Range Control Profile शामिल है)

अगर डिवाइस पर लागू किए गए सिस्टम में, android.media.MediaCodec एपीआई में मौजूद डिफ़ॉल्ट एएसी ऑडियो डिकोडर की मदद से, मल्टीचैनल स्ट्रीम (यानी कि दो से ज़्यादा चैनल) के एएसी इनपुट बफ़र को पीसीएम में डिकोड करने की सुविधा काम करती है, तो इन सुविधाओं का काम करना ज़रूरी है:

• [C-2-1] डिकोडिंग, डाउनमिक्सिंग के बिना की जानी चाहिए.उदाहरण के लिए, 5.0 AAC स्ट्रीम को पीसीएम के पांच चैनलों में डिकोड किया जाना चाहिए.वहीं, 5.1 AAC स्ट्रीम को पीसीएम के छह चैनलों में डिकोड किया जाना चाहिए.

• [C-2-2] डाइनैमिक रेंज का मेटाडेटा, ISO/IEC 14496-3 में "डाइनैमिक रेंज कंट्रोल (डीआरसी)" में बताए गए तरीके से होना चाहिए. साथ ही, android.media.MediaFormat डीआरसी कुंजियां, ऑडियो डिकोडर के डाइनैमिक रेंज से जुड़े व्यवहारों को कॉन्फ़िगर करने के लिए होनी चाहिए. AAC DRC कुंजियों को एपीआई 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] यह सुझाव दिया जाता है कि सभी एएसी ऑडियो डिकोडर, ऊपर दी गई C-2-1 और C-2-2 ज़रूरी शर्तों को पूरा करें.

USAC ऑडियो को डिकोड करते समय, MPEG-D (ISO/IEC 23003-4):

• [C-3-1] लाउडनेस और डीआरसी मेटाडेटा को MPEG-D DRC Dynamic Range Control Profile Level 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 प्रोफ़ाइल डिकोडर:

• आईएसओ/आईईसी 23003-4 डाइनैमिक रेंज कंट्रोल प्रोफ़ाइल का इस्तेमाल करके, तेज़ आवाज़ और डाइनैमिक रेंज कंट्रोल की सुविधा काम कर सकती है.

अगर ISO/IEC 23003-4 काम करता है और डिकोड किए गए बिटस्ट्रीम में ISO/IEC 23003-4 और ISO/IEC 14496-3, दोनों मेटाडेटा मौजूद हैं, तो:

• ISO/IEC 23003-4 मेटाडेटा को प्राथमिकता दी जाएगी.

सभी ऑडियो डिकोडर में, ये आउटपुट देने की सुविधा होनी चाहिए:

• [C-6-1] android.media.MediaCodec API के ज़रिए, पीसीएम 16-बिट नेटिव बाइट ऑर्डर वाले ऑडियो फ़्रेम.

अगर डिवाइस में, android.media.MediaCodec एपीआई में मौजूद डिफ़ॉल्ट AAC ऑडियो डिकोडर के ज़रिए, मल्टीचैनल स्ट्रीम (यानी कि दो से ज़्यादा चैनल) के AAC इनपुट बफ़र को पीसीएम में डिकोड करने की सुविधा है, तो इन सुविधाओं का होना ज़रूरी है:

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

• [C-7-2] डिकोड करते समय, डिकोडर को KEY_CHANNEL_MASK कुंजी के साथ आउटपुट फ़ॉर्मैट पर इस्तेमाल किए जा रहे चैनल मास्क का विज्ञापन करना होगा. इसके लिए, android.media.AudioFormat कॉन्स्टेंट का इस्तेमाल करना होगा. उदाहरण के लिए: CHANNEL_OUT_5POINT1.

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

• [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. ऑडियो कोडेक की जानकारी

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 बिटरेट कंट्रोल मोड, HEVCProfileMainStill प्रोफ़ाइल, और 512 x 512 पिक्सल फ़्रेम साइज़ के साथ काम करता हो.

5.1.5. इमेज डिकोडिंग

ज़्यादा जानकारी के लिए, 5.1.6 देखें. इमेज कोडेक की जानकारी.

डिवाइस में सेट किए गए सिस्टम में, इमेज को इस तरह से एन्कोड करने की सुविधा होनी चाहिए:

• [C-0-1] JPEG

• [C-0-2] GIF

• [C-0-3] PNG

• [C-0-4] बीएमपी

• [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] इनपुट सरफेस मोड के लिए, 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 एवीसी	ज़्यादा जानकारी के लिए, सेक्शन 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 का इस्तेमाल किया जा सकता है. OMX, क्रॉस-प्लैटफ़ॉर्म मल्टीमीडिया ऐक्सलरेशन एपीआई है. वहीं, Codec 2.0, कम ओवरहेड वाला मल्टीमीडिया ऐक्सलरेशन एपीआई है.

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

• [C-1-1] Android ओपन सोर्स प्रोजेक्ट की तरह, OMX या Codec 2.0 API (या दोनों) के ज़रिए मीडिया कोडेक के लिए सहायता उपलब्ध करानी होगी. साथ ही, सुरक्षा सुविधाओं को बंद नहीं करना होगा या उन्हें नाकाम नहीं करना होगा. इसका मतलब यह नहीं है कि हर कोडेक को 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 ओपन सोर्स प्रोजेक्ट से मिला Codec 2.0 सॉफ़्टवेयर कोडेक होना चाहिए. यह कोडेक, डिवाइस पर काम करने वाले हर मीडिया फ़ॉर्मैट और टाइप (एनकोडर या डिकोडर) के लिए उपलब्ध होना चाहिए.

• [C-3-2] Android Open Source Project में दिए गए तरीके के मुताबिक, Codec 2.0 सॉफ़्टवेयर कोडेक को सॉफ़्टवेयर कोडेक प्रोसेस में शामिल करना ज़रूरी है. इससे सॉफ़्टवेयर कोडेक का ऐक्सेस ज़्यादा सीमित तरीके से दिया जा सकेगा.

• [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 ओपन सोर्स प्रोजेक्ट में मौजूद नहीं होने वाले या उस प्रोजेक्ट के सोर्स कोड पर आधारित नहीं होने वाले कोडेक को वेंडर के तौर पर मार्क किया जाना चाहिए.

• [C-1-7] हार्डवेयर की मदद से तेज़ी लाने की सुविधा का इस्तेमाल करने वाले कोडेक को, हार्डवेयर की मदद से तेज़ी लाने की सुविधा के तौर पर मार्क किया जाना चाहिए.

• [C-1-8] कोडेक के नाम, गुमराह करने वाले नहीं होने चाहिए. उदाहरण के लिए, "decoders" नाम वाले कोडेक में डिकोडिंग की सुविधा होनी चाहिए. साथ ही, "encoders" नाम वाले कोडेक में एन्कोडिंग की सुविधा होनी चाहिए. जिन कोडेक के नाम में मीडिया फ़ॉर्मैट शामिल हैं उनके साथ उन फ़ॉर्मैट का इस्तेमाल किया जा सकता है.

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

• [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 पिक्सल (HEVC, VP9, AV1)

• [C-2-2] हार्डवेयर की मदद से तेज़ किए गए वीडियो कोडेक के लिए, परफ़ॉर्मेंस पॉइंट की जानकारी पब्लिश करना ज़रूरी है. उन्हें परफ़ॉर्मेंस के सभी स्टैंडर्ड पॉइंट (PerformancePoint API में दिए गए) की सूची बनानी होगी. हालांकि, अगर वे परफ़ॉर्मेंस के किसी अन्य स्टैंडर्ड पॉइंट के दायरे में आते हैं, तो ऐसा करना ज़रूरी नहीं है.

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

5.2. वीडियो एन्कोडिंग

अगर डिवाइस में वीडियो एन्कोडर काम करता है और इसे तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराया जाता है, तो
MediaFormat.KEY_BITRATE_MODE को BITRATE_MODE_VBR पर सेट करें, ताकि एन्कोडर वैरिएबल बिटरेट मोड में काम करे. ऐसा करने पर, एन्कोड किए गए बिटरेट पर कोई असर नहीं पड़ेगा, जब तक कि इससे कम से कम क्वालिटी फ़्लोर पर असर न पड़े.

• स्लाइडिंग विंडो में, इंट्राफ़्रेम (आई-फ़्रेम) इंटरवल के बीच बिटरेट में 15% से ज़्यादा का अंतर नहीं होना चाहिए.
• एक सेकंड की स्लाइडिंग विंडो में बिटरेट, 100% से ज़्यादा नहीं होना चाहिए.

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

• [C-SR-2] में यह सुझाव दिया जाता है कि एक सेकंड की स्लाइडिंग विंडो में, टारगेट बिटरेट से 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 के साथ काम करना ज़रूरी है. हालांकि, एएसओ (आर्बिट्ररी स्लाइस ऑडरिंग), एफ़एमओ (फ़्लेक्सिबल मैक्रोब्लॉक ऑर्डरिंग), और आरएस (रेडंडेंट स्लाइस) के लिए सहायता पाना ज़रूरी नहीं है. इसके अलावा, अन्य Android डिवाइसों के साथ काम करने के लिए, यह सुझाव दिया जाता है कि एन्कोडर, बेसलाइन प्रोफ़ाइल के लिए एएसओ, एफ़एमओ, और आरएस का इस्तेमाल न करें.
• [C-1-2] यहां दी गई टेबल में, एसडी (स्टैंडर्ड डेफ़िनिशन) वीडियो एन्कोडिंग प्रोफ़ाइलों के साथ काम करना ज़रूरी है.
• Main Profile Level 4 के साथ काम करना चाहिए.
• इसमें एचडी (हाई डेफ़िनिशन) वीडियो एन्कोडिंग प्रोफ़ाइलों के साथ काम करने की सुविधा होनी चाहिए. इसके बारे में यहां दी गई टेबल में बताया गया है.

अगर डिवाइस में मीडिया एपीआई के ज़रिए, 720 पिक्सल या 1080 पिक्सल रिज़ॉल्यूशन वाले वीडियो के लिए 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 प्रोजेक्ट की आरटीसी हार्डवेयर कोडिंग की ज़रूरी शर्तों को पूरा करता हो. इससे यह पक्का किया जा सकेगा कि वेब वीडियो स्ट्रीमिंग और वीडियो कॉन्फ़्रेंसिंग की सेवाएं अच्छी क्वालिटी में मिलें.

अगर डिवाइसों पर मीडिया एपीआई के ज़रिए, 720 पिक्सल या 1080 पिक्सल रिज़ॉल्यूशन वाले वीडियो के लिए 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] Profile 0 Level 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 एमबीपीएस

अगर डिवाइस में सेट किए गए सिस्टम, मीडिया एपीआई के ज़रिए Profile 2 या Profile 3 के साथ काम करने का दावा करते हैं, तो:

• 12-बिट फ़ॉर्मैट का इस्तेमाल करना ज़रूरी नहीं है.

5.2.5. H.265

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

• [C-1-1] 512 x 512 रिज़ॉल्यूशन तक, मुख्य प्रोफ़ाइल लेवल 3 के साथ काम करना ज़रूरी है.
• [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] नीचे दी गई टेबल में, HD1080p एन्कोडिंग प्रोफ़ाइल के साथ काम करना ज़रूरी है:

	एसडी	एचडी 720 पिक्सल	एचडी 1080 पिक्सल	यूएचडी
वीडियो का रिज़ॉल्यूशन	720 x 480 पिक्सल	1280 x 720 पिक्सल	1920 x 1080 पिक्सल	3840 x 2160 पिक्सल
वीडियो फ़्रेम रेट	30 एफ़पीएस	30 एफ़पीएस	30 एफ़पीएस	30 एफ़पीएस
वीडियो बिटरेट	5 एमबीपीएस	8 एमबीपीएस	16 एमबीपीएस	50 एमबीपीएस

5.3. वीडियो डिकोडिंग

5.3.1. MPEG-2

अगर डिवाइस में MPEG-2 डिकोडर काम करते हैं, तो:

• [C-1-1] यह ज़रूरी है कि डिवाइस, Main Profile High Level के साथ काम करता हो.

5.3.2. H.263

अगर डिवाइस में H.263 डिकोडर काम करते हैं, तो:

• [C-1-1] Baseline Profile Level 30 (30 एफ़पीएस पर 384 केबीपीएस के साथ सीआईएफ़, क्यूसीआईएफ़, और एसक्यूसीआईएफ़ रिज़ॉल्यूशन) और Level 45 (30 एफ़पीएस पर 128 केबीपीएस के साथ क्यूसीआईएफ़ और एसक्यूसीआईएफ़ रिज़ॉल्यूशन) के साथ काम करना ज़रूरी है.

5.3.3. MPEG-4

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

• [C-1-1] Simple Profile Level 3 के साथ काम करना ज़रूरी है.

5.3.4. H.264

अगर डिवाइसों में H.264 डिकोडर काम करते हैं, तो:

• [C-1-1] Main Profile Level 3.1 और बेसलाइन प्रोफ़ाइल के साथ काम करना ज़रूरी है. एएसओ (आर्बिट्ररी स्लाइस ऑर्डरिंग), एफ़एमओ (फ़्लेक्सिबल मैक्रोब्लॉक ऑर्डरिंग), और आरएस (रेडंडेंट स्लाइस) के लिए सहायता पाना ज़रूरी नहीं है.
• [C-1-2] में, इस टेबल में दी गई एसडी (स्टैंडर्ड डेफ़िनिशन) प्रोफ़ाइलों वाले वीडियो को डिकोड करने की सुविधा होनी चाहिए. साथ ही, ये वीडियो बेसलाइन प्रोफ़ाइल और मेन प्रोफ़ाइल लेवल 3.1 (इसमें 720p30 भी शामिल है) के साथ एन्कोड किए गए हों.
• इसमें एचडी (हाई डेफ़िनिशन) प्रोफ़ाइल वाले वीडियो डिकोड करने की सुविधा होनी चाहिए. इसके बारे में यहां दी गई टेबल में बताया गया है.

अगर Display.getSupportedModes() तरीके से रिपोर्ट की गई ऊंचाई, वीडियो रिज़ॉल्यूशन के बराबर या उससे ज़्यादा है, तो डिवाइसों पर लागू होने वाली ये शर्तें पूरी होनी चाहिए:

• [C-2-1] यहां दी गई टेबल में, एचडी 720 पिक्सल वीडियो डिकोडिंग प्रोफ़ाइलों के साथ काम करना ज़रूरी है.
• [C-2-2] यहां दी गई टेबल में बताई गई एचडी 1080 पिक्सल वीडियो डिकोडिंग प्रोफ़ाइलों के साथ काम करना ज़रूरी है.

	एसडी (खराब क्वालिटी)	एसडी (अच्छी क्वालिटी)	एचडी 720 पिक्सल	एचडी 1080 पिक्सल
वीडियो का रिज़ॉल्यूशन	320 x 240 पिक्सल	720 x 480 पिक्सल	1280 x 720 पिक्सल	1920 x 1080 पिक्सल
वीडियो फ़्रेम रेट	30 एफ़पीएस	30 एफ़पीएस	60 एफ़पीएस	30 एफ़पीएस (60 एफ़पीएसटेलीविज़न)
वीडियो बिटरेट	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] डिवाइसों में, यहां दी गई टेबल में मौजूद 720 पिक्सल की प्रोफ़ाइलों का इस्तेमाल किया जाना ज़रूरी है.
• [C-2-2] डिवाइसों में, यहां दी गई टेबल में बताई गई 1080 पिक्सल की प्रोफ़ाइलें काम करनी चाहिए.

	एसडी (खराब क्वालिटी)	एसडी (अच्छी क्वालिटी)	एचडी 720 पिक्सल	एचडी 1080 पिक्सल
वीडियो का रिज़ॉल्यूशन	320 x 180 पिक्सल	640 x 360 पिक्सल	1280 x 720 पिक्सल	1920 x 1080 पिक्सल
वीडियो फ़्रेम रेट	30 एफ़पीएस	30 एफ़पीएस	30 एफ़पीएस (60 एफ़पीएसटेलीविज़न)	30 (60 एफ़पीएसटेलीविज़न)
वीडियो बिटरेट	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 सभी एचडीआर प्रोफ़ाइलों के लिए और 'KEY_HDR10_PLUS_INFO' एचडीआर10Plus प्रोफ़ाइलों के लिए. इनमें बिटस्ट्रीम और/या कंटेनर से ज़रूरी एचडीआर मेटाडेटा निकालने और उसे आउटपुट करने की सुविधा भी होनी चाहिए.
• [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] इसमें मुख्य प्रोफ़ाइल के साथ-साथ 8-बिट और 10-बिट कॉन्टेंट भी काम करना चाहिए.

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

• [C-2-1] जब Display.getSupportedModes() तरीके से रिपोर्ट की गई ऊंचाई 720 पिक्सल के बराबर या उससे ज़्यादा हो, तब डिवाइस में नीचे दी गई टेबल में मौजूद, कम से कम HD 720 पिक्सल की वीडियो डिकोडिंग प्रोफ़ाइल को डिकोड करने की सुविधा होनी चाहिए.
• [C-2-2] जब Display.getSupportedModes() तरीके से रिपोर्ट की गई ऊंचाई 1080 पिक्सल के बराबर या उससे ज़्यादा हो, तो नीचे दी गई टेबल से कम से कम HD 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 के ज़रिए एचडीआर प्रोफ़ाइल का इस्तेमाल किया जा सकता है, तो:

• [C-3-1] बिटस्ट्रीम और/या कंटेनर से एचडीआर मेटाडेटा निकालने और उसे आउटपुट करने की सुविधा होनी चाहिए.

• [C-3-2] डिवाइस की स्क्रीन या स्टैंडर्ड वीडियो आउटपुट पोर्ट (जैसे, एचडीएमआई) पर एचडीआर कॉन्टेंट को सही तरीके से दिखाना होगा.

5.4. ऑडियो रिकॉर्डिंग

इस सेक्शन में बताई गई कुछ ज़रूरी शर्तों को Android 4.3 के बाद से SHOULD के तौर पर लिस्ट किया गया है. हालांकि, आने वाले समय में कंपैटिबिलिटी डेफ़िनिशन में इन शर्तों को MUST के तौर पर बदलने का प्लान है. मौजूदा और नए Android डिवाइसों के लिए, ज़ोरदार तरीके से यह सुझाव दिया जाता है कि वे 'ज़रूरी है' के तौर पर लिस्ट की गई इन ज़रूरी शर्तों को पूरा करें. ऐसा न करने पर, आने वाले समय में 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.

• इन सुविधाओं के साथ, रॉ ऑडियो कॉन्टेंट कैप्चर करने की अनुमति होनी चाहिए:

  • फ़ॉर्मैट: लीनियर पीसीएम, 16-बिट और 24-बिट
  • सैंपलिंग रेट: 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 हर्ट्ज़
  • चैनल: डिवाइस पर मौजूद माइक्रोफ़ोन की संख्या के बराबर चैनल

• [C-1-2] ऊपर दिए गए सैंपल रेट पर, बिना अप-सैंपलिंग के ऑडियो कैप्चर करना ज़रूरी है.

• [C-1-3] जब ऊपर दी गई सैंपल दरें, डाउन-सैंपलिंग के साथ कैप्चर की जाती हैं, तो उनमें एंटी-एलियासिंग फ़िल्टर शामिल होना चाहिए.

• इसमें एएम रेडियो और डीवीडी क्वालिटी में ऑडियो कॉन्टेंट कैप्चर करने की सुविधा होनी चाहिए. इसका मतलब है कि इसमें ये सुविधाएं होनी चाहिए:

  • फ़ॉर्मैट: लीनियर पीसीएम, 16-बिट
  • सैंपलिंग रेट: 22050, 48000 हर्ट्ज़
  • चैनल: स्टीरियो

• [C-1-4] MicrophoneInfo एपीआई का इस्तेमाल करना ज़रूरी है. साथ ही, डिवाइस पर उपलब्ध माइक्रोफ़ोन की जानकारी सही तरीके से भरनी होगी. ये माइक्रोफ़ोन, AudioManager.getMicrophones() एपीआई के ज़रिए तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध होते हैं. ऐसा MediaRecorder.AudioSources DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED या VOICE_PERFORMANCE का इस्तेमाल करके, AudioRecord को चालू करने के लिए किया जाता है. अगर डिवाइसों में एएम रेडियो और डीवीडी क्वालिटी में रॉ ऑडियो कॉन्टेंट कैप्चर करने की सुविधा उपलब्ध है, तो:

• [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 dB.

• [C-SR-2] में, ज़्यादा फ़्रीक्वेंसी रेंज में ऐम्प्लिट्यूड लेवल दिखाने का सुझाव दिया जाता है. खास तौर पर, आवाज़ पहचानने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन के लिए, 4,000 हर्ट्ज़ से 22 किलोहर्ट्ज़ तक ±30 dB की तुलना में, मिड-फ़्रीक्वेंसी रेंज.

• ऑडियो इनपुट की सेंसिटिविटी को इस तरह से सेट किया जाना चाहिए कि 90 dB के साउंड प्रेशर लेवल (एसपीएल) पर 1000 हर्ट्ज़ का साइनसोडल टोन सोर्स (माइक्रोफ़ोन के बगल में मेज़र किया गया) चलाने पर, 16 बिट-सैंपल के लिए 1770 और 3530 की रेंज में आरएमएस 2500 का सही जवाब मिले. इसके अलावा, फ़्लोटिंग पॉइंट/डबल प्रिसिशन सैंपल के लिए -22.35 db ±3dB फ़ुल स्केल का सही जवाब मिले. यह जवाब, आवाज़ की पहचान करने वाले ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन के लिए होना चाहिए.

• आवाज़ पहचानने की सुविधा के लिए ऑडियो स्ट्रीम रिकॉर्ड की जानी चाहिए, ताकि पीसीएम ऐम्प्लिट्यूड लेवल, माइक्रोफ़ोन पर इनपुट एसपीएल में होने वाले बदलावों को कम से कम 30 dB की रेंज में लीनियर तरीके से ट्रैक कर सके. यह रेंज -18 dB से +12 dB re 90 dB एसपीएल तक होनी चाहिए.

• आवाज़ पहचानने की सुविधा के लिए ऑडियो स्ट्रीम को रिकॉर्ड करते समय, माइक्रोफ़ोन पर 90 dB एसपीएल इनपुट लेवल पर 1 kHz के लिए, टोटल हार्मोनिक डिस्टॉर्शन (टीएचडी) 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 का इस्तेमाल करके कैप्चर करते समय, डिवाइस में ध्वनि को गूंजने से रोकने वाली टेक्नोलॉजी (एईसी) लागू होनी चाहिए. यह टेक्नोलॉजी, आवाज़ से बातचीत करने के लिए ट्यून की गई हो और कैप्चर पाथ पर लागू हो.

5.4.5. एक साथ कैप्चर करने की सुविधा

अगर डिवाइसों पर android.hardware.microphone का एलान किया जाता है, तो उन्हें इस दस्तावेज़ में बताए गए तरीके से, एक साथ कैप्चर करने की सुविधा लागू करनी होगी. खास तौर से:

• [C-1-1] डिवाइस में, एक साथ माइक्रोफ़ोन ऐक्सेस करने की अनुमति होनी चाहिए. जैसे, AudioSource.VOICE_RECOGNITION के साथ-साथ कम से कम एक ऐसा ऐप्लिकेशन जो AudioSource का इस्तेमाल करके ऑडियो कैप्चर करता हो.
• [C-1-2] डिवाइस में पहले से इंस्टॉल किए गए ऐसे ऐप्लिकेशन को माइक्रोफ़ोन का ऐक्सेस देना ज़रूरी है जो Assistant की भूमिका निभाता है. साथ ही, कम से कम एक ऐसे ऐप्लिकेशन को भी माइक्रोफ़ोन का ऐक्सेस देना ज़रूरी है जो AudioSource के साथ कैप्चर करता है. हालांकि, AudioSource.VOICE_COMMUNICATION या AudioSource.CAMCORDER को छोड़कर.
• [C-1-3] जब कोई ऐप्लिकेशन 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. ऑडियो आउटपुट वॉल्यूम

Automotive डिवाइस में सेट किए गए सिस्टम के लिए:

• कॉन्टेंट टाइप या इस्तेमाल के आधार पर, हर ऑडियो स्ट्रीम के लिए ऑडियो वॉल्यूम को अलग-अलग अडजस्ट करने की अनुमति होनी चाहिए. इसके लिए, AudioAttributes में बताए गए कॉन्टेंट टाइप या इस्तेमाल के आधार पर, हर ऑडियो स्ट्रीम के लिए ऑडियो वॉल्यूम को अलग-अलग अडजस्ट करने की अनुमति होनी चाहिए. साथ ही, कार में ऑडियो इस्तेमाल करने के बारे में सार्वजनिक तौर पर android.car.CarAudioManager में बताया गया है.

5.5.4. ऑडियो ऑफ़लोड

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

• [C-SR-1] AudioTrack gapless API और MediaPlayer के लिए मीडिया कंटेनर के ज़रिए बताए जाने पर, एक ही फ़ॉर्मैट की दो क्लिप के बीच बिना रुके चलने वाले ऑडियो कॉन्टेंट को ट्रिम करने का सुझाव दिया जाता है.

• [C-SR-2] AAC, MP3, OPUS, और PCM फ़ॉर्मैट के लिए, ऑफ़लोड प्लेबैक की सुविधा लागू करने का सुझाव दिया जाता है.

5.5.5. वीडियो चलाने के पैरामीटर

5.6. ऑडियो के इंतज़ार का समय

ऑडियो के इंतज़ार का समय, ऑडियो सिग्नल के सिस्टम से गुज़रने में लगने वाला समय होता है. कई तरह के ऐप्लिकेशन में, रीयल-टाइम में साउंड इफ़ेक्ट पाने के लिए, कम इंतज़ार के समय की ज़रूरत होती है.

इस सेक्शन के लिए, यहां दी गई परिभाषाओं का इस्तेमाल करें:

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

• कोल्ड आउटपुट में लगने वाला समय. जब ऑडियो आउटपुट सिस्टम, अनुरोध से पहले बंद हो और निष्क्रिय हो, तब आउटपुट स्ट्रीम शुरू होने और टाइमस्टैंप के आधार पर पहले फ़्रेम के दिखने के समय के बीच का समय.

• लगातार आउटपुट मिलने में लगने वाला समय. डिवाइस पर ऑडियो चलने के बाद, अगले फ़्रेम के लिए आउटपुट में लगने वाला समय.

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

• इनपुट नहीं मिला. इनपुट सिग्नल का शुरुआती हिस्सा, जिसका इस्तेमाल नहीं किया जा सकता या जो उपलब्ध नहीं है.

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

• लगातार इनपुट लेटेन्सी. डिवाइस के ऑडियो कैप्चर करने के दौरान, बाद के फ़्रेम के लिए इनपुट लेटेन्सी.

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

• OpenSL ES PCM बफ़र क्यू एपीआई. Android NDK में, पीसीएम से जुड़े OpenSL ES एपीआई का सेट.

• AAudio native audio API. Android NDK में AAudio API का सेट.

• टाइमस्टैंप. यह स्ट्रीम में फ़्रेम की रिलेटिव पोज़िशन और उस फ़्रेम के ऑडियो प्रोसेसिंग पाइपलाइन में शामिल होने या उससे बाहर निकलने के अनुमानित समय का पेयर होता है. यह भी देखें AudioTimestamp.

• glitch. ऑडियो सिग्नल में कुछ समय के लिए रुकावट या गलत सैंपल वैल्यू. आम तौर पर, यह आउटपुट के लिए बफ़र अंडररन, इनपुट के लिए बफ़र ओवररन या डिजिटल या ऐनलॉग नॉइज़ के किसी अन्य सोर्स की वजह से होता है.

• औसत कुल डेविएशन (एमएडी). यह वैल्यू के किसी सेट के लिए, औसत से विचलन की ऐब्सलूट वैल्यू का औसत होती है.

• CTS Verifier से मेज़र की गई टैप-टू-टोन लेटेंसी (टीटीएल), स्क्रीन पर टैप करने और उस टैप के नतीजे के तौर पर जनरेट हुई टोन के स्पीकर पर सुनाई देने के बीच का समय होता है. यह औसत, आउटपुट के लिए AAudio के नेटिव ऑडियो एपीआई का इस्तेमाल करके, पांच मेज़रमेंट के आधार पर निकाला जाता है.

• CTS Verifier से मेज़र की गई राउंड-ट्रिप लेटेंसी (आरटीएल), पांच मेज़रमेंट के हिसाब से औसत लगातार लेटेंसी होती है. इसे लूपबैक पाथ पर मेज़र किया जाता है. यह पाथ, AAudio नेटिव ऑडियो एपीआई का इस्तेमाल करके आउटपुट को वापस इनपुट में भेजता है.

  लूपबैक पाथ ये हैं:

  • स्पीकर/माइक: पहले से मौजूद स्पीकर से पहले से मौजूद माइक्रोफ़ोन.
  • ऐनालॉग: 3.5 मि॰मी॰ का ऐनालॉग जैक और लूपबैक अडैप्टर.
  • यूएसबी: यूएसबी से 3.5 मि॰मी॰ अडैप्टर और लूपबैक अडैप्टर या यूएसबी ऑडियो इंटरफ़ेस और लूपबैक केबल.

• FEATURE_AUDIO_LOW_LATENCY. android.hardware.audio.low_latency सुविधा का एलान किया गया हो.

• FEATURE_AUDIO_PRO. android.hardware.audio.pro सुविधा का एलान किया गया हो.

• एमपीसी. मीडिया परफ़ॉर्मेंस क्लास.

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

अगर डिवाइसों में android.hardware.audio.output का एलान किया जाता है, तो उन्हें यहां दी गई ज़रूरी शर्तों को पूरा करना होगा या इनसे बेहतर परफ़ॉर्म करना होगा:

• [C-1-1] Android 15 में इस ज़रूरी शर्त को हटा दिया गया है.

• [C-1-2] कोल्ड आउटपुट की लेटेन्सी 500 मिलीसेकंड या इससे कम हो.

• [C-1-3] AAudioStreamBuilder_openStream() का इस्तेमाल करके आउटपुट स्ट्रीम खोलने में 1000 मिलीसेकंड से कम समय लगना चाहिए.

• [C-1-4] AAudioStream_getTimestamp से मिले इनपुट और आउटपुट टाइमस्टैंप के आधार पर कैलकुलेट की गई राउंड-ट्रिप लेटेंसी, स्पीकर, वायर्ड हेडसेट, और वायरलेस हेडसेट के लिए मेज़र की गई राउंड-ट्रिप लेटेंसी के 200 मि॰से॰ के अंदर होनी चाहिए.AAUDIO_PERFORMANCE_MODE_NONEAAUDIO_PERFORMANCE_MODE_LOW_LATENCY

• [C-SR-1] Android 15 में इस ज़रूरी शर्त को हटा दिया गया है.

• [C-SR-2] Android 15 में इस ज़रूरी शर्त को हटा दिया गया है.

• [C-SR-4] Android 15 में इस ज़रूरी शर्त को हटा दिया गया है.

• [C-SR-5] Android 15 में इस ज़रूरी शर्त को हटा दिया गया है.

• [C-SR-6] Android 15 में इस ज़रूरी शर्त को हटा दिया गया है.

• [C-SR-7] Android 15 में इस ज़रूरी शर्त को हटा दिया गया है.

• [C-2-1] Android 15 में यह ज़रूरी शर्त हटा दी गई है.

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

• [C-3-1] Android 15 में इस ज़रूरी शर्त को हटा दिया गया है.

• [C-3-2] कोल्ड इनपुट लेटेन्सी 500 मिलीसेकंड या इससे कम होनी चाहिए.

• [C-3-3] AAudioStreamBuilder_openStream() का इस्तेमाल करके इनपुट स्ट्रीम खोलने में 1000 मिलीसेकंड से कम समय लगना चाहिए.

• [C-SR-8] Android 15 में इस ज़रूरी शर्त को हटा दिया गया है.

• [C-SR-11] Android 15 में इस ज़रूरी शर्त को हटा दिया गया है.

• [C-SR-12] Android 15 में इस ज़रूरी शर्त को हटा दिया गया है.

यहां दी गई टेबल में, हैंडहेल्ड डिवाइसों के लिए आरटीएल से जुड़ी ज़रूरी शर्तों के बारे में बताया गया है. ये शर्तें, 2.2.1 में बताई गई शर्तों के मुताबिक हैं. साथ ही, ये android.hardware.audio.output और android.hardware.microphone के बारे में बताती हैं.

इस टेबल में, हैंडहेल्ड डिवाइसों के लिए टीटीएल की ज़रूरी शर्तों के बारे में बताया गया है. ये शर्तें, 2.2.1 में बताई गई हैं. साथ ही, android.hardware.audio.output और android.hardware.microphone के बारे में भी बताया गया है.

अगर डिवाइस में हेड ट्रैकिंग के साथ spatial audio की सुविधा शामिल है और PackageManager.FEATURE_AUDIO_SPATIAL_HEADTRACKING_LOW_LATENCY फ़्लैग का एलान किया गया है, तो:

• [C-4-1] हेड ट्रैकिंग से ऑडियो अपडेट होने में ज़्यादा से ज़्यादा 300 मि॰से॰ की देरी होनी चाहिए.

5.7. नेटवर्क प्रोटोकॉल

डिवाइस में सेट किए हुए सिस्टम में, Android SDK के दस्तावेज़ में बताए गए तरीके से, ऑडियो और वीडियो चलाने के लिए मीडिया नेटवर्क प्रोटोकॉल काम करने चाहिए.

हर कोडेक और कंटेनर फ़ॉर्मैट के लिए, डिवाइस को लागू करने की ज़रूरत होती है. इसके लिए, डिवाइस को लागू करने के दौरान:

• [C-1-1] MUST support that codec or container over HTTP and HTTPS.

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

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

मीडिया सेगमेंट के फ़ॉर्मैट

सेगमेंट फ़ॉर्मैट	रेफ़रंस	कोडेक के साथ काम करने की सुविधा
MPEG-2 ट्रांसपोर्ट स्ट्रीम	ISO 13818	वीडियो कोडेक: H264 एवीसी 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	एएसी और इसके वैरिएंट के बारे में जानकारी के लिए, सेक्शन 5.1.1 देखें
WebVTT	WebVTT

RTSP (RTP, SDP)

प्रोफ़ाइल का नाम	रेफ़रंस	कोडेक के साथ काम करने की सुविधा
H264 एवीसी	RFC 6184	H264 AVC के बारे में ज़्यादा जानने के लिए, सेक्शन 5.1.8 देखें
MP4A-LATM	RFC 6416	एएसी और इसके वैरिएंट के बारे में जानकारी के लिए, सेक्शन 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	एएसी और इसके वैरिएंट के बारे में जानकारी के लिए, सेक्शन 5.1.3 देखें
MP2T	RFC 2250	ज़्यादा जानकारी के लिए, एचटीटीपी लाइव स्ट्रीमिंग के नीचे मौजूद MPEG-2 ट्रांसपोर्ट स्ट्रीम देखें

5.8. सुरक्षित मीडिया

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

• [C-1-1] Display.FLAG_SECURE के साथ काम करने की सुविधा का एलान करना ज़रूरी है.

अगर डिवाइस में सेट किए गए सिस्टम में Display.FLAG_SECURE और वायरलेस डिसप्ले प्रोटोकॉल के साथ काम करने की सुविधा उपलब्ध है, तो:

• [C-2-1] वायरलेस प्रोटोकॉल, जैसे कि Miracast के ज़रिए कनेक्ट किए गए डिसप्ले के लिए, लिंक को क्रिप्टोग्राफ़िक तौर पर मज़बूत तरीके से सुरक्षित करना ज़रूरी है. जैसे, HDCP 2.x या इससे नया वर्शन.

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

• [C-3-1] उपयोगकर्ता के लिए उपलब्ध वायर वाले पोर्ट से कनेक्ट किए गए सभी बाहरी डिसप्ले के लिए, HDCP 1.2 या इसके बाद वाले वर्शन का इस्तेमाल करना ज़रूरी है.

5.9. म्यूज़िकल इंस्ट्रुमेंट डिजिटल इंटरफ़ेस (एमआईडीआई)

अगर डिवाइस में सेट किए गए सिस्टम, android.content.pm.PackageManager क्लास के ज़रिए android.software.midi सुविधा के काम करने की जानकारी देते हैं, तो:

• [C-1-1] MIDI को सभी MIDI की सुविधा वाले हार्डवेयर ट्रांसपोर्ट पर काम करना चाहिए. इसके लिए, वे MIDI के अलावा अन्य कनेक्टिविटी की सुविधा देते हैं. ये ट्रांसपोर्ट इस तरह के होते हैं:

  • यूएसबी होस्ट मोड, section 7.7
  • सेंट्रल डिवाइस के तौर पर काम करने वाला ब्लूटूथ स्मार्ट पर MIDI, सेक्शन 7.4.3

• [C-1-2] ऐप्लिकेशन के बीच एमआईडीआई सॉफ़्टवेयर ट्रांसपोर्ट (वर्चुअल एमआईडीआई डिवाइस) की सुविधा काम करनी चाहिए

• [C-1-3] libamidi.so (नेटिव MIDI सपोर्ट) को शामिल करना ज़रूरी है

• इसमें यूएसबी के ज़रिए MIDI पेरिफ़रल मोड काम करना चाहिए. सेक्शन 7.7

5.10. प्रोफ़ेशनल ऑडियो

अगर डिवाइसों पर लागू की गई सुविधाओं की रिपोर्ट में, android.content.pm.PackageManager क्लास के ज़रिए android.hardware.audio.pro सुविधा के काम करने की जानकारी दी गई है, तो:

• [C-1-1] android.hardware.audio.low_latency सुविधा के साथ काम करने की जानकारी देना ज़रूरी है.

• [C-1-2] FEATURE_AUDIO_PRO के लिए, इंतज़ार के समय से जुड़ी ज़रूरी शर्तों को पूरा करना ज़रूरी है. इन शर्तों के बारे में, सेक्शन 5.6 ऑडियो के इंतज़ार का समय में बताया गया है.

• [C-1-3] में यूएसबी पोर्ट शामिल होने चाहिए, जो यूएसबी होस्ट मोड और यूएसबी पेरीफ़ेरल मोड के साथ काम करते हों.

• [C-1-4] यह ज़रूरी है कि डिवाइस, android.software.midi सुविधा के साथ काम करता हो.

• [C-1-5] MUST meet USB audio latency requirements using the AAudio native audio API and AAUDIO_PERFORMANCE_MODE_LOW_LATENCY.

• [C-1-6] में कोल्ड आउटपुट की लेटेन्सी 200 मिलीसेकंड या इससे कम होनी चाहिए.

• [C-1-7] कोल्ड इनपुट लेटेंसी 200 मिलीसेकंड या इससे कम होनी चाहिए.

अगर डिवाइस में 4 कंडक्टर वाला 3.5 मि॰मी॰ ऑडियो जैक शामिल है, तो:

• [C-2-2] Wired Audio Headset Specification (v1.1) के मोबाइल डिवाइस (जैक) की खास बातों वाले सेक्शन का पालन करना ज़रूरी है.

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

• [C-3-1] यूएसबी ऑडियो क्लास को लागू करना ज़रूरी है.

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] मिड-फ़्रीक्वेंसी रेंज में, ऐम्प्लिट्यूड-वर्सेस-फ़्रीक्वेंसी की विशेषताएं लगभग एक जैसी होनी चाहिए: खास तौर पर, 100 हर्ट्ज़ से 7,000 हर्ट्ज़ तक ±10 डीबी. यह शर्त, बिना प्रोसेस किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन पर लागू होती है.

• [C-1-3] कम फ़्रीक्वेंसी रेंज में ऐम्प्लिट्यूड लेवल दिखाना ज़रूरी है: खास तौर पर, 5 हर्ट्ज़ से 100 हर्ट्ज़ तक ±20 डीबी, जो कि बिना प्रोसेस किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन के लिए, मिड-फ़्रीक्वेंसी रेंज की तुलना में है.

• [C-1-4] हाई फ़्रीक्वेंसी रेंज में ऐम्प्लिट्यूड लेवल दिखाना ज़रूरी है: खास तौर पर, 7,000 हर्ट्ज़ से 22 किलोहर्ट्ज़ तक, ±30 डीबी की रेंज में. इसकी तुलना, बिना प्रोसेस किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन की मिड-फ़्रीक्वेंसी रेंज से की जाती है.

• [C-1-5] ऑडियो इनपुट की सेंसिटिविटी इस तरह से सेट की जानी चाहिए कि 94 dB के साउंड प्रेशर लेवल (एसपीएल) पर बजने वाले 1000 हर्ट्ज़ के साइनसोडल टोन सोर्स से, 16 बिट-सैंपल के लिए 520 का आरएमएस (या फ़्लोटिंग पॉइंट/डबल प्रेसिज़न सैंपल के लिए -36 dB फ़ुल स्केल) वाला रिस्पॉन्स मिले. ऐसा हर उस माइक्रोफ़ोन के लिए होना चाहिए जिसका इस्तेमाल बिना प्रोसेस किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए किया जाता है.

• [C-1-6] बिना प्रोसेस किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन के लिए, सिग्नल-टू-नॉइज़ रेशियो (एसएनआर) 60 डीबी या इससे ज़्यादा होना चाहिए. (जबकि एसएनआर को 94 dB एसपीएल और खुद के नॉइज़ के बराबर एसपीएल के बीच के अंतर के तौर पर मेज़र किया जाता है. इसमें A-वेटिंग का इस्तेमाल किया जाता है).

• [C-1-7] बिना प्रोसेस किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन के लिए, 90 dB एसपीएल इनपुट लेवल पर 1 किलोहर्ट्ज़ के लिए, टोटल हार्मोनिक डिस्टॉर्शन (टीएचडी) 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, एचडीआर टेक्नोलॉजी के साथ काम करता है. इसके बारे में आने वाले दस्तावेज़ में बताया गया है.

Pixel Format

अगर कोई वीडियो डिकोडर, COLOR_FormatYUVP010 के साथ काम करने का दावा करता है, तो:

• [C-1-1] सीपीयू से पढ़ने के लिए, P010 फ़ॉर्मैट काम करना चाहिए (ImageReader, MediaImage, ByteBuffer). Android 13 में, P010 को आसान बनाया गया है, ताकि Y और UV प्लैन के लिए आर्बिट्रेरी स्ट्राइड की अनुमति दी जा सके.

• [C-1-2] P010 आउटपुट बफ़र को GPU से सैंपल किया जा सकता है. हालांकि, ऐसा तब ही किया जा सकता है, जब GPU_SAMPLING का इस्तेमाल किया गया हो. इससे ऐप्लिकेशन को जीपीयू कंपोज़िशन और कस्टम टोन मैपिंग की सुविधा मिलती है.

अगर कोई वीडियो डिकोडर COLOR_Format32bitABGR2101010 के साथ काम करने का दावा करता है, तो:

• [C-2-1] आउटपुट सर्फ़ेस और सीपीयू के लिए पढ़ने लायक (ByteBuffer आउटपुट) के लिए, RGBA_1010102 फ़ॉर्मैट के साथ काम करना ज़रूरी है.

अगर कोई वीडियो एनकोडर, COLOR_FormatYUVP010 के साथ काम करने का विज्ञापन दिखाता है, तो:

• [C-3-1] ज़रूरी है कि इनपुट सरफेस और सीपीयू से लिखे जा सकने वाले (ImageWriter, MediaImage, ByteBuffer) इनपुट के लिए, P010 फ़ॉर्मैट काम करता हो.

अगर कोई वीडियो एनकोडर, COLOR_Format32bitABGR2101010 के साथ काम करने का विज्ञापन दिखाता है, तो:

• [C-4-1] इनपुट सरफेस और सीपीयू से लिखे जा सकने वाले (ImageWriter, ByteBuffer) इनपुट के लिए, RGBA_1010102 फ़ॉर्मैट के साथ काम करना ज़रूरी है. ध्यान दें: एनकोडर के लिए, अलग-अलग ट्रांसफ़र कर्व के बीच कन्वर्ज़न करना ज़रूरी नहीं है.

एचडीआर कैप्चर करने से जुड़ी ज़रूरी शर्तें

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

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

• इन्हें एचडीआर डाइनैमिक मेटाडेटा को इकट्ठा करना चाहिए, ताकि एन्कोड की गई स्ट्रीम के लिए सही एचडीआर स्टैटिक मेटाडेटा जनरेट किया जा सके. साथ ही, इन्हें हर एन्कोडिंग सेशन के आखिर में इसे आउटपुट करना चाहिए.

अगर डिवाइस पर CamcorderProfile API का इस्तेमाल करके एचडीआर कैप्चर की सुविधा काम करती है, तो:

• [C-6-1] Camera2 एपीआई के ज़रिए भी एचडीआर कैप्चर की सुविधा काम करनी चाहिए.

• [C-6-2] MUST support at least one hardware-accelerated video encoder for each HDR technology supported.

• [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] यहां दिए गए वीडियो एन्कोडर को ऐसे इनपुट फ़ॉर्मैट में काम करना चाहिए जो डिकोड किए गए एचडीआर सिग्नल पूरी तरह से आगे बढ़ाए:

  • RGBA_1010102 (already in the target transfer curve) for both input surface and ByteBuffer and MUST advertise support for COLOR_Format32bitABGR2101010.

अगर डिवाइस में ऐसे कोडेक शामिल हैं जो FEATURE_HdrEditing के साथ काम करते हैं, तो डिवाइस:

• [C-7-4] EXT_YUV_target OpenGL एक्सटेंशन के लिए काम की जानकारी देना ज़रूरी है.

एचडीआर डिसप्ले के लिए ज़रूरी शर्तें

अगर डिवाइसों में, ADATASPACE_TRANSFER_HLG का इस्तेमाल करके एन्कोड किया गया बफ़र कॉन्टेंट मिलता है और उस कॉन्टेंट को SurfaceControl.Transaction#setBuffer के ज़रिए डिसप्ले पर भेजा जाता है, तो:

• [C-8-1] BT. 2408-7 में दिए गए, ग्राफ़िक्स के लिए सफ़ेद रंग के सुझावों का पालन करना ज़रूरी है. साथ ही, सिर्फ़ ऐसे कॉन्टेंट को दिखाना ज़रूरी है जो एसडीआर कॉन्टेंट के मुकाबले ज़्यादा से ज़्यादा 4.926 गुना ज़्यादा हो.

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

6.1. डेवलपर टूल

डिवाइस में सेट किए गए सिस्टम के लिए:

• [C-0-1] Android SDK में दिए गए Android डेवलपर टूल के साथ काम करना ज़रूरी है.

• Android Debug Bridge (adb)

• [C-0-2] Android SDK और AOSP में दिए गए शेल कमांड में बताए गए तरीके से, adb का इस्तेमाल किया जा सकता है. ऐप्लिकेशन डेवलपर, इसका इस्तेमाल कर सकते हैं. जैसे, dumpsys, cmd stats, और Simpleperf.

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

• [C-0-3] dumpsys कमांड के ज़रिए लॉग किए गए डिवाइस सिस्टम इवेंट (batterystats, diskstats, fingerprint, graphicsstats, netstats, notification, procstats) के फ़ॉर्मैट या कॉन्टेंट में बदलाव नहीं किया जाना चाहिए.

• [C-0-10] यह ज़रूरी है कि इन इवेंट को बिना किसी बदलाव के रिकॉर्ड किया जाए. साथ ही, इन्हें cmd stats शेल कमांड और StatsManager सिस्टम एपीआई क्लास के लिए उपलब्ध कराया जाए.

  • ActivityForegroundStateChanged
  • AnomalyDetected
  • AppBreadcrumbReported
  • AppCrashOccurred
  • AppStartOccurred
  • BatteryLevelChanged
  • BatterySaverModeStateChanged
  • BleScanResultReceived
  • BleScanStateChanged
  • ChargingStateChanged
  • DeviceIdleModeStateChanged
  • ForegroundServiceStateChanged
  • GpsScanStateChanged
  • InputDeviceUsageReported
  • JobStateChanged
  • KeyboardConfigured
  • KeyboardSystemsEventReported
  • PluggedStateChanged
  • PressureStallInformation
  • ScheduledJobStateChanged
  • ScreenStateChanged
  • SyncStateChanged
  • SystemElapsedRealtime
  • TouchpadUsage
  • UidProcessStateChanged
  • WakelockStateChanged
  • WakeupAlarmOccurred
  • WifiLockStateChanged
  • WifiMulticastLockStateChanged
  • WifiScanStateChanged

• [C-0-4] डिवाइस-साइड adb डेमॉन डिफ़ॉल्ट रूप से बंद होना चाहिए. साथ ही, Android Debug Bridge को चालू करने के लिए, उपयोगकर्ता के पास एक ऐसा तरीका होना चाहिए जिसका इस्तेमाल वह आसानी से कर सके.

• [C-0-5] सुरक्षित ए़डीबी के साथ काम करना ज़रूरी है. Android में सुरक्षित adb की सुविधा उपलब्ध है. Secure adb की मदद से, पुष्टि किए गए होस्ट पर adb की सुविधा चालू की जा सकती है.

• [C-0-6] ऐसा तरीका उपलब्ध कराना ज़रूरी है जिससे adb को किसी होस्ट मशीन से कनेक्ट किया जा सके. खास तौर से:

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

• [C-3-1] लोकल-एरिया नेटवर्क (जैसे कि ईथरनेट या वाई-फ़ाई) के ज़रिए एडीबी को लागू करना ज़रूरी है.

• [C-3-2] Windows 7, 8, और 10 के लिए ड्राइवर उपलब्ध कराने ज़रूरी हैं. इससे डेवलपर, adb प्रोटोकॉल का इस्तेमाल करके डिवाइस से कनेक्ट कर पाएंगे.

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

• [C-4-1] AdbManager#isAdbWifiSupported() तरीके से true वापस मिलना चाहिए.

अगर डिवाइस में, वाई-फ़ाई या ईथरनेट के ज़रिए होस्ट मशीन से adb कनेक्शन की सुविधा काम करती है और उसमें कम से कम एक कैमरा शामिल है, तो:

• [C-5-1] AdbManager#isAdbWifiQrSupported() तरीके से true वापस मिलना चाहिए.

• Dalvik Debug Monitor Service (ddms)

  • [C-0-7] यह ज़रूरी है कि डिवाइस, Android SDK में बताई गई सभी ddms सुविधाओं के साथ काम करता हो. डीडीएमएस, एडीबी का इस्तेमाल करता है. इसलिए, डीडीएमएस की सुविधा डिफ़ॉल्ट रूप से बंद होनी चाहिए. हालांकि, जब उपयोगकर्ता ऊपर दिए गए तरीके से Android Debug Bridge को चालू करता है, तब डीडीएमएस की सुविधा चालू होनी चाहिए.

• SysTrace

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

• Perfetto

  • [C-SR-1] Are STRONGLY RECOMMENDED to expose a /system/bin/perfetto binary to the shell user which cmdline complies with the perfetto documentation.

  • [C-SR-2] हमारा सुझाव है कि perfetto बाइनरी, इनपुट के तौर पर ऐसे protobuf कॉन्फ़िगरेशन को स्वीकार करे जो परफ़ेक्टो के दस्तावेज़ में तय किए गए स्कीमा के मुताबिक हो.

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

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

• Low Memory Killer

  • [C-0-12] जब किसी ऐप्लिकेशन को लो मेमोरी किलर बंद कर देता है, तब statsd लॉग में LMK_KILL_OCCURRED_FIELD_NUMBER ऐटम लिखना ज़रूरी है.

• टेस्ट हार्नेस मोड

  अगर डिवाइस में सेट किए गए सिस्टम, शेल कमांड cmd testharness के साथ काम करते हैं और cmd testharness enable को चलाते हैं, तो:

  • [C-2-1] ActivityManager.isRunningInUserTestHarness() के लिए true एट्रिब्यूट की वैल्यू देना ज़रूरी है

  • [C-2-2] टेस्ट हार्नेस मोड के दस्तावेज़ में बताए गए तरीके के मुताबिक, टेस्ट हार्नेस मोड को लागू करना ज़रूरी है.

• जीपीयू के काम की जानकारी

  डिवाइस में सेट किए गए सिस्टम के लिए:

  • [C-0-13] dumpsys gpu --gpuwork शेल कमांड को लागू करना ज़रूरी है, ताकि dumpsys gpu --gpuwork कर्नल ट्रेसपॉइंट से मिले, एग्रीगेट किए गए जीपीयू वर्क डेटा को दिखाया जा सके. अगर ट्रेसपॉइंट मौजूद नहीं है, तो कोई डेटा नहीं दिखाया जाना चाहिए.power/gpu_work_period AOSP में लागू करने की सुविधा frameworks/native/services/gpuservice/gpuwork/ है.

अगर डिवाइस में Vulkan 1.0 या इसके बाद के वर्शन के साथ काम करने की जानकारी, android.hardware.vulkan.version फ़ीचर फ़्लैग के ज़रिए दी जाती है, तो:

• [C-1-1] ऐप्लिकेशन डेवलपर को जीपीयू डीबग लेयर चालू/बंद करने की सुविधा देनी होगी.

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

6.2. डेवलपर के लिए सेटिंग और टूल

Android में, डेवलपर के लिए ऐप्लिकेशन डेवलपमेंट से जुड़ी सेटिंग कॉन्फ़िगर करने की सुविधा शामिल है.

डिवाइस में डेवलपर विकल्पों के लिए, एक जैसा अनुभव उपलब्ध कराना ज़रूरी है. इसके लिए:

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

7. हार्डवेयर के साथ काम करने की सुविधा

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

• [C-0-1] डिवाइस में सेट किए गए सिस्टम के लिए, Android SDK के दस्तावेज़ में बताए गए तरीके से इस एपीआई को लागू करना ज़रूरी है.

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

• [C-0-2] कॉम्पोनेंट एपीआई के लिए, क्लास की पूरी परिभाषाएं (एसडीके में दी गई जानकारी के मुताबिक) अब भी दिखनी चाहिए.
• [C-0-3] एपीआई के व्यवहारों को, कुछ उचित तरीके से नो-ऑप के तौर पर लागू करना ज़रूरी है.
• [C-0-4] एपीआई के तरीकों को उन जगहों पर शून्य वैल्यू दिखानी चाहिए जहां एसडीके के दस्तावेज़ में इसकी अनुमति दी गई है.
• [C-0-5] एपीआई के तरीकों को क्लास के नो-ऑप इंप्लीमेंटेशन दिखाने चाहिए. इनमें एसडीके के दस्तावेज़ में, शून्य वैल्यू की अनुमति नहीं होती.
• [C-0-6] एपीआई के तरीकों से ऐसे अपवाद नहीं मिलने चाहिए जिनके बारे में एसडीके के दस्तावेज़ में नहीं बताया गया है.
• [C-0-7] डिवाइसों को एक ही बिल्ड फ़िंगरप्रिंट के लिए, android.content.pm.PackageManager क्लास पर getSystemAvailableFeatures() और hasSystemFeature(String) तरीकों का इस्तेमाल करके, हार्डवेयर कॉन्फ़िगरेशन की सटीक जानकारी लगातार रिपोर्ट करनी होगी.

इन ज़रूरी शर्तों के लागू होने का एक सामान्य उदाहरण, टेलीफ़ोनी एपीआई है: फ़ोन के अलावा अन्य डिवाइसों पर भी, इन एपीआई को नो-ऑप के तौर पर लागू किया जाना चाहिए.

7.1. डिसप्ले और ग्राफ़िक्स

Android में ऐसी सुविधाएं शामिल हैं जो डिवाइस के हिसाब से, ऐप्लिकेशन ऐसेट और यूज़र इंटरफ़ेस (यूआई) लेआउट को अपने-आप अडजस्ट करती हैं. इससे यह पक्का किया जा सकता है कि तीसरे पक्ष के ऐप्लिकेशन, अलग-अलग हार्डवेयर डिसप्ले और कॉन्फ़िगरेशन पर ठीक से काम करें. Android के साथ काम करने वाला डिसप्ले, एक ऐसी डिसप्ले स्क्रीन होती है जो Android Developers - स्क्रीन कंपैटिबिलिटी की खास जानकारी में बताए गए सभी व्यवहारों और एपीआई को लागू करती है. साथ ही, यह इस सेक्शन (7.1) और इसके सब-सेक्शन में बताए गए सभी व्यवहारों और एपीआई को भी लागू करती है. इसके अलावा, यह डिवाइस टाइप के हिसाब से, सेक्शन 2 में बताए गए सभी व्यवहारों को भी लागू करती है.

डिवाइस में सेट किए गए सिस्टम के लिए:

• [C-0-1] डिफ़ॉल्ट रूप से, तीसरे पक्ष के ऐप्लिकेशन सिर्फ़ Android के साथ काम करने वाले डिसप्ले पर रेंडर होने चाहिए.

इस सेक्शन में बताई गई ज़रूरी शर्तों में इस्तेमाल की गई इकाइयों की परिभाषा यहां दी गई है:

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

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

• आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात). स्क्रीन के लंबे डाइमेंशन के पिक्सल का अनुपात, छोटे डाइमेंशन के पिक्सल से. उदाहरण के लिए, 480 x 854 पिक्सल के डिसप्ले का आसपेक्ट रेशियो 854 / 480 = 1.779 होगा. इसे "16:9" भी कहा जा सकता है.

• डेंसिटी-इंडिपेंडेंट पिक्सल (डीपी). वर्चुअल पिक्सल यूनिट, जिसे 160 की स्क्रीन डेंसिटी के हिसाब से नॉर्मलाइज़ किया जाता है. कुछ डेंसिटी d और पिक्सल की संख्या p के लिए, डेंसिटी-इंडिपेंडेंट पिक्सल dp की संख्या इस तरह से कैलकुलेट की जाती है: dp = (160 / d) * p.

7.1.1. स्क्रीन कॉन्फ़िगरेशन

7.1.1.1. स्क्रीन का साइज़ और शेप

Android यूज़र इंटरफ़ेस (यूआई) फ़्रेमवर्क, अलग-अलग लॉजिकल स्क्रीन लेआउट साइज़ के साथ काम करता है. साथ ही, ऐप्लिकेशन को Configuration.screenLayout के ज़रिए, मौजूदा कॉन्फ़िगरेशन के स्क्रीन लेआउट साइज़ के बारे में क्वेरी करने की अनुमति देता है. इसके लिए, SCREENLAYOUT_SIZE_MASK और Configuration.smallestScreenWidthDp का इस्तेमाल किया जाता है.

डिवाइस में सेट किए गए सिस्टम के लिए:

• [C-0-1] Android SDK के दस्तावेज़ में बताए गए तरीके के मुताबिक, Configuration.screenLayout के लिए सही लेआउट साइज़ की जानकारी देना ज़रूरी है. खास तौर पर, डिवाइसों को लॉजिकल डेंसिटी-इंडिपेंडेंट पिक्सल (डीपी) के स्क्रीन डाइमेंशन की सही जानकारी देनी होगी. जैसे:

  • जिन डिवाइसों के लिए Configuration.uiMode को UI_MODE_TYPE_WATCH के अलावा किसी अन्य वैल्यू के तौर पर सेट किया गया है और Configuration.screenLayout के लिए small साइज़ की रिपोर्ट की जा रही है उनके लिए, कम से कम 426 डीपी x 320 डीपी होना ज़रूरी है.

  • Configuration.screenLayout के लिए normal साइज़ की जानकारी देने वाले डिवाइसों में, कम से कम 480 डीपी x 320 डीपी होना चाहिए.

  • Configuration.screenLayout के लिए large साइज़ की जानकारी देने वाले डिवाइसों का साइज़ कम से कम 640 dp x 480 dp होना चाहिए.

  • Configuration.screenLayout के लिए xlarge साइज़ की जानकारी देने वाले डिवाइसों में, कम से कम 960 डीपी x 720 डीपी होना चाहिए.

• [C-0-2] यह ज़रूरी है कि डिवाइस, ऐप्लिकेशन में बताई गई स्क्रीन साइज़ की जानकारी को सही तरीके से इस्तेमाल करे. इसके लिए, AndroidManifest.xml में <supports-screens> एट्रिब्यूट का इस्तेमाल किया जाता है. इसके बारे में Android SDK के दस्तावेज़ में बताया गया है.

• इसमें Android के साथ काम करने वाले डिसप्ले हो सकते हैं, जिनके कोने गोल होते हैं.

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

• [C-1-1] यह पक्का करना ज़रूरी है कि इस तरह के हर डिसप्ले के लिए, यहां दी गई कम से कम एक ज़रूरी शर्त पूरी की गई हो:

  • गोल किए गए कोनों का रेडियस, 38 डीपी से कम या इसके बराबर होना चाहिए.

  • जब 18 डीपी गुणा 18 डीपी वाला बॉक्स, लॉजिकल डिसप्ले के हर कोने पर ऐंकर किया जाता है, तब हर बॉक्स का कम से कम एक पिक्सल स्क्रीन पर दिखता है.

• इसमें उपयोगकर्ता के लिए, आयताकार कोनों वाले डिसप्ले मोड पर स्विच करने की सुविधा शामिल होनी चाहिए.

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

• [C-4-1] डिसप्ले कटआउट को छोड़कर, लेआउट का साइज़ कम से कम 596 डीपी x 384 डीपी या इससे ज़्यादा होना चाहिए.

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

• [C-4-1] Android 15 में इस ज़रूरी शर्त को हटा दिया गया है.

7.1.1.2. स्क्रीन का आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात)

इस सेक्शन को Android 14 में हटा दिया गया है.

7.1.1.3. स्क्रीन की सघनता

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

डिवाइस में सेट किए गए सिस्टम के लिए:

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

• इसमें Android के स्टैंडर्ड फ़्रेमवर्क की डेंसिटी तय की जानी चाहिए. यह डेंसिटी, स्क्रीन की फ़िज़िकल डेंसिटी के हिसाब से सबसे सही होनी चाहिए. इसके अलावा, इसमें ऐसी वैल्यू भी तय की जा सकती है जो हैंडहेल्ड डिवाइस के एंगुलर फ़ील्ड-ऑफ़-व्यू के मेज़रमेंट के बराबर हो.

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

• [C-1-1] डिसप्ले को 1.5 गुना से ज़्यादा बड़ा नहीं करना चाहिए DENSITY_DEVICE_STABLE या स्क्रीन के डाइमेंशन को 320 dp से कम नहीं करना चाहिए (यह रिसॉर्स क्वालिफ़ायर sw320dp के बराबर है). इनमें से जो भी पहले हो.

• [C-1-2] डिसप्ले को DENSITY_DEVICE_STABLE के 0.85 गुना से कम नहीं किया जाना चाहिए.

• बेहतर इस्तेमाल और फ़ॉन्ट के साइज़ में एकरूपता बनाए रखने के लिए, यह सुझाव दिया जाता है कि नेटिव डिसप्ले विकल्पों के लिए, यहां दी गई स्केलिंग का इस्तेमाल किया जाए. हालांकि, इसके लिए ऊपर दी गई सीमाओं का पालन करना ज़रूरी है:

  • छोटा: 0.85x
  • डिफ़ॉल्ट: 1x (नेटिव डिसप्ले स्केल)
  • बड़ा: 1.15x
  • ज़्यादा बड़ा: 1.3 गुना
  • सबसे बड़ा 1.45x

7.1.2. डिसप्ले मेट्रिक

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

• [C-1-1] android.util.DisplayMetrics एपीआई में बताई गई, Android के साथ काम करने वाली सभी डिसप्ले मेट्रिक के लिए सही वैल्यू रिपोर्ट करना ज़रूरी है.

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

• [C-2-1] Android के साथ काम करने वाले डिसप्ले की सही वैल्यू रिपोर्ट करना ज़रूरी है. ये वैल्यू, android.util.DisplayMetrics एपीआई में बताई गई वैल्यू के मुताबिक होनी चाहिए. यह एपीआई, डिफ़ॉल्ट रूप से view.Display को इम्यूलेट करता है.

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] Android 16 में इस ज़रूरी शर्त को हटा दिया गया है.

• [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] यह ज़रूरी है कि डिवाइस, OpenGL ES 1.1, 2.0, 3.0, और 3.1 के साथ काम करे. इसके बारे में Android SDK के दस्तावेज़ में बताया गया है.

• [C-SR-1] Android 15 में इस ज़रूरी शर्त को हटा दिया गया है.

• OpenGL ES 3.2 सपोर्ट करना चाहिए.

OpenGL ES dEQP टेस्ट को कई टेस्ट लिस्ट में बांटा गया है. हर लिस्ट में, तारीख/वर्शन नंबर दिया गया है. ये Android सोर्स ट्री में external/deqp/android/cts/main/glesXX-master-YYYY-MM-DD.txt पर मौजूद हैं. अगर कोई डिवाइस, 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] हर उस OpenGL ES वर्शन के लिए, टेस्ट लिस्ट में मौजूद सभी OpenGL ES dEQP टेस्ट पास करना ज़रूरी है जो 132383489 और android.software.opengles.deqp.level फ़ीचर फ़्लैग में बताए गए वर्शन के बीच का हो.

• [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 Extension Pack के साथ पूरी तरह से काम करना ज़रूरी है.

अगर डिवाइस में OpenGL ES Android Extension Pack की सभी सुविधाएं काम करती हैं, तो:

• [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 टेस्ट को कई टेस्ट लिस्ट में बांटा गया है. हर लिस्ट में, तारीख/वर्शन की जानकारी दी गई है. ये Android सोर्स ट्री में external/deqp/android/cts/main/vk-master-YYYY-MM-DD.txt पर मौजूद हैं. अगर कोई डिवाइस, खुद बताए गए लेवल पर Vulkan के साथ काम करता है, तो इसका मतलब है कि वह इस लेवल और इससे पहले के सभी लेवल की टेस्ट सूचियों में dEQP टेस्ट पास कर सकता है.

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

• [C-1-1] android.hardware.vulkan.level और android.hardware.vulkan.version फ़ीचर फ़्लैग के साथ सही पूर्णांक वैल्यू रिपोर्ट करना ज़रूरी है.

• [C-1-2] Vulkan नेटिव एपीआई vkEnumeratePhysicalDevices() के लिए, कम से कम एक VkPhysicalDevice की गिनती करना ज़रूरी है.

• [C-1-3] हर VkPhysicalDevice के लिए, Vulkan 1.1 एपीआई को पूरी तरह से लागू करना ज़रूरी है.

• [C-1-4] ऐप्लिकेशन पैकेज की नेटिव लाइब्रेरी डायरेक्ट्री में मौजूद, libVkLayer*.so नाम की नेटिव लाइब्रेरी में शामिल लेयर को Vulkan नेटिव एपीआई vkEnumerateInstanceLayerProperties() और vkEnumerateDeviceLayerProperties() के ज़रिए गिनना ज़रूरी है.

• [C-1-6] Vulkan नेटिव एपीआई के ज़रिए, उन सभी एक्सटेंशन स्ट्रिंग की जानकारी देना ज़रूरी है जिनके साथ काम किया जा सकता है. इसके उलट, उन एक्सटेंशन स्ट्रिंग की जानकारी नहीं देनी चाहिए जिनके साथ काम नहीं किया जा सकता.

• [C-1-8] android.software.vulkan.deqp.level फ़ीचर फ़्लैग के ज़रिए, Vulkan dEQP टेस्ट के उस वर्शन की जानकारी देना ज़रूरी है जो डिवाइस पर काम करता है.

• [C-1-9] android.software.vulkan.deqp.level फ़ीचर फ़्लैग में बताए गए, कम से कम 132317953 वर्शन (1 मार्च, 2019 से) को सपोर्ट करना ज़रूरी है.

• [C-1-10] टेस्ट लिस्ट में मौजूद सभी Vulkan dEQP टेस्ट पास करने ज़रूरी हैं. ये टेस्ट, वर्शन 132317953 और android.software.vulkan.deqp.level फ़ीचर फ़्लैग में बताए गए वर्शन के बीच होने चाहिए.

• [C-1-11] VK_KHR_video_queue, VK_KHR_video_decode_queue या VK_KHR_video_encode_queue एक्सटेंशन के लिए, सहायता की सूची नहीं बनानी चाहिए.

• [C-1-12] VK_KHR_performance_query एक्सटेंशन के साथ काम करने की सुविधा के बारे में नहीं बताना चाहिए.

• [C-SR-4] Android Baseline 2022 प्रोफ़ाइल में बताई गई ज़रूरी शर्तों को पूरा करने का सुझाव दिया जाता है.

• [C-SR-5] यह सुझाव दिया जाता है कि VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory और VK_EXT_global_priority काम करें.

• [C-SR-6] एचडब्ल्यूयूआई के साथ SkiaVk का इस्तेमाल करने का सुझाव दिया जाता है.

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

• [C-SR-8] यह सुझाव दिया जाता है कि Vulkan लोडर में बदलाव न करें.

• [C-1-14] "KHR", "GOOGLE" या "ANDROID" टाइप के Vulkan डिवाइस एक्सटेंशन की गिनती नहीं की जानी चाहिए. ऐसा तब तक नहीं किया जाना चाहिए, जब तक कि इन एक्सटेंशन को android.software.vulkan.deqp.level फ़ीचर फ़्लैग में शामिल न किया गया हो.

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

• [C-2-1] यह ज़रूरी है कि Vulkan के किसी भी फ़ीचर फ़्लैग (जैसे, android.hardware.vulkan.level, android.hardware.vulkan.version) का एलान न किया गया हो.

• [C-2-2] Vulkan नेटिव एपीआई vkEnumeratePhysicalDevices() के लिए, किसी भी VkPhysicalDevice को शामिल नहीं किया जाना चाहिए.

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 स्पेस में DCI-P3 के कम से कम 90% हिस्से को कवर करता हो.

• [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 में "कंपैटिबिलिटी मोड" होता है. इसमें फ़्रेमवर्क, "सामान्य" स्क्रीन साइज़ (320 डीपी चौड़ाई) मोड में काम करता है. इससे उन लेगसी ऐप्लिकेशन को फ़ायदा मिलता है जिन्हें Android के पुराने वर्शन के लिए डेवलप नहीं किया गया है. ये वर्शन, स्क्रीन साइज़ के हिसाब से काम करने की सुविधा से पहले के हैं.

7.1.6. स्क्रीन टेक्नोलॉजी

Android प्लैटफ़ॉर्म में ऐसे एपीआई शामिल होते हैं जिनकी मदद से ऐप्लिकेशन, Android के साथ काम करने वाले डिसप्ले पर बेहतर ग्राफ़िक रेंडर कर सकते हैं. डिवाइसों को Android SDK में बताए गए इन सभी एपीआई के साथ काम करना चाहिए. हालांकि, इस दस्तावेज़ में खास तौर पर अनुमति दी गई हो, तो ऐसा करने की ज़रूरत नहीं है.

डिवाइस में लागू किए गए Android के साथ काम करने वाले सभी डिसप्ले:

• [C-0-1] ज़रूरी है कि 16-बिट कलर ग्राफ़िक रेंडर कर सके.

• इसमें 24-बिट कलर ग्राफ़िक वाले डिसप्ले काम करने चाहिए.

• [C-0-2] ऐनिमेशन रेंडर करने की सुविधा होनी चाहिए.

• [C-0-3] पिक्सल आसपेक्ट रेशियो (पीएआर) 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-की) में से किसी एक से मेल न खाता हो.
• इसमें सॉफ़्ट कीबोर्ड को लागू करने के अतिरिक्त तरीके शामिल होने चाहिए.
• इसमें हार्डवेयर कीबोर्ड शामिल हो सकता है.

7.2.2. बिना छुए नेविगेट करने की सुविधा

Android में, बिना छुए नेविगेट करने के लिए डी-पैड, ट्रैकबॉल, और व्हील का इस्तेमाल किया जा सकता है.

डिवाइस में सेट किए गए सिस्टम के लिए:

• [C-0-1] android.content.res.Configuration.navigation के लिए सही वैल्यू रिपोर्ट करना ज़रूरी है.

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

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

7.2.3. मार्गदर्शक कुंजियां

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

• [C-0-1] MUST provide a user affordance to launch installed applications that have an activity with the <intent-filter> set with ACTION=MAIN and CATEGORY=LAUNCHER or CATEGORY=LEANBACK_LAUNCHER for Television device implementations. उपयोगकर्ता को यह सुविधा देने के लिए, होम फ़ंक्शन का इस्तेमाल किया जाना चाहिए.
• इसमें हाल ही में इस्तेमाल किए गए आइटम और वापस जाने के लिए बटन होने चाहिए.

अगर होम, हाल ही के या वापस जाएँ फ़ंक्शन उपलब्ध कराए जाते हैं, तो:

• [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 से कम हो, तब ऐप्लिकेशन के लिए मेन्यू फ़ंक्शन उपलब्ध कराना ज़रूरी है. इसके लिए, फ़िज़िकल बटन, सॉफ़्टवेयर कुंजी या जेस्चर का इस्तेमाल किया जा सकता है. यह मेन्यू फ़ंक्शन ऐक्सेस किया जा सकता है. हालांकि, इसे अन्य नेविगेशन फ़ंक्शन के साथ छिपाया जा सकता है.

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

• [C-4-1] जब अन्य नेविगेशन कुंजियां ऐक्सेस की जा सकती हैं, तब एक ही ऐक्शन (जैसे, टैप करना, दो बार क्लिक करना या जेस्चर) से, 'ठीक है Google' सुविधा को ऐक्सेस किया जा सकता हो.
• [C-SR-3] होम फ़ंक्शन पर लंबे समय तक दबाकर रखने की सुविधा का इस्तेमाल करने का सुझाव दिया जाता है.

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

• [C-5-1] नेविगेशन कुंजियों को स्क्रीन के अलग हिस्से पर इस्तेमाल किया जाना चाहिए. यह हिस्सा, ऐप्लिकेशन के लिए उपलब्ध नहीं होना चाहिए. साथ ही, यह हिस्सा ऐप्लिकेशन के लिए उपलब्ध स्क्रीन के हिस्से को न तो छिपाना चाहिए और न ही उसमें किसी तरह की रुकावट डालनी चाहिए.
• [C-5-2] डिसप्ले का कुछ हिस्सा, उन ऐप्लिकेशन के लिए उपलब्ध कराना होगा जो सेक्शन 7.1.1 में बताई गई ज़रूरी शर्तें पूरी करते हैं.
• [C-5-3] View.setSystemUiVisibility() एपीआई के तरीके से, ऐप्लिकेशन की ओर से सेट किए गए फ़्लैग का पालन करना ज़रूरी है, ताकि स्क्रीन के इस अलग हिस्से (नेविगेशन बार) को एसडीके में बताए गए तरीके से छिपाया जा सके.

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

• [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] अगर बाईं या दाईं ओर स्वाइप किए जा सकने वाले कस्टम सिस्टम पैनल दिए गए हैं, तो उन्हें स्क्रीन के ऊपरी एक-तिहाई हिस्से में रखना होगा. साथ ही, यह साफ़ तौर पर दिखना चाहिए कि पैनल को अंदर की ओर खींचने से, ऊपर बताए गए पैनल खुल जाएंगे. इसलिए, बैक बटन का इस्तेमाल नहीं किया जा सकेगा. उपयोगकर्ता, सिस्टम पैनल को इस तरह से कॉन्फ़िगर कर सकता है कि वह स्क्रीन के ऊपरी एक-तिहाई हिस्से के नीचे दिखे. हालांकि, सिस्टम पैनल को स्क्रीन के एक-तिहाई हिस्से से ज़्यादा जगह इस्तेमाल नहीं करनी चाहिए.
• [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 रिपोर्ट करना ज़रूरी है.

अगर डिवाइस में, इनपुट के लिए माउस या ट्रैकबॉल जैसे बाहरी इनपुट डिवाइस का इस्तेमाल किया जाता है (यानी कि सीधे तौर पर स्क्रीन को नहीं छुआ जाता है) और वह Android के साथ काम करने वाले प्राइमरी डिसप्ले पर इनपुट देता है, तो उसे सेक्शन 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] MUST report touch event with the action code that specifies the state change that occurs on the pointer going down or up on the screen.
• [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] में, एचआईडी इवेंट को नीचे दी गई टेबल में दिए गए InputEvent कॉन्स्टेंट से मैप करने की सुविधा होनी चाहिए. अपस्ट्रीम Android के लागू होने से, यह ज़रूरी शर्त पूरी हो जाती है.

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

• [C-2-1] android.hardware.gamepad फ़ीचर फ़्लैग के बारे में एलान करना ज़रूरी है

बटन	एचआईडी का इस्तेमाल2	Android बटन
A1	0x09 0x0001	KEYCODE_BUTTON_A (96)
B1	0x09 0x0002	KEYCODE_BUTTON_B (97)
X1	0x09 0x0004	KEYCODE_BUTTON_X (99)
Y1	0x09 0x0005	KEYCODE_BUTTON_Y (100)
डी-पैड में अप ऐरो वाला बटन1 डी-पैड में डाउन ऐरो वाला बटन1	0x01 0x00393	AXIS_HAT_Y4
डी-पैड में लेफ़्ट ऐरो वाला बटन1 डी-पैड में राइट ऐरो वाला बटन1	0x01 0x00393	AXIS_HAT_X4
लेफ़्ट शोल्डर बटन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

1 MotionEvent

7.2.7. रिमोट कंट्रोल

डिवाइस से जुड़ी ज़रूरी शर्तों के लिए, सेक्शन 2.3.1 देखें.

7.3. सेंसर

अगर डिवाइस में किसी खास तरह का सेंसर शामिल है और तीसरे पक्ष के डेवलपर के लिए उससे जुड़ा एपीआई उपलब्ध है, तो डिवाइस में उस एपीआई को लागू करना ज़रूरी है. इसे Android SDK के दस्तावेज़ में बताया गया है. साथ ही, सेंसर के बारे में Android Open Source के दस्तावेज़ में भी इसकी जानकारी दी गई है.

डिवाइस में सेट किए गए सिस्टम के लिए:

• [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] MUST report the event time in nanoseconds as defined in the Android SDK documentation, representing the time the event happened and synchronized with the SystemClock.elapsedRealtimeNano() clock.

• [C-SR-1] टाइमस्टैंप सिंक करने से जुड़ी गड़बड़ी 100 मिलीसेकंड से कम होनी चाहिए. साथ ही, यह गड़बड़ी 1 मिलीसेकंड से कम होनी चाहिए.

• कई सेंसर चालू होने पर, बिजली की खपत, हर सेंसर की बताई गई बिजली की खपत के योग से ज़्यादा नहीं होनी चाहिए.

ऊपर दी गई सूची में सभी जानकारी शामिल नहीं है. Android SDK टूल और सेंसर के बारे में Android Open Source Documentations में दी गई जानकारी को आधिकारिक माना जाएगा.

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

• [C-1-6] सभी सेंसर के लिए, शून्य से अलग रिज़ॉल्यूशन सेट करना ज़रूरी है. साथ ही, Sensor.getResolution() एपीआई तरीके से वैल्यू की जानकारी देना ज़रूरी है.

कुछ सेंसर कंपोज़िट होते हैं. इसका मतलब है कि उन्हें एक या एक से ज़्यादा अन्य सेंसर से मिले डेटा से बनाया जा सकता है. (उदाहरण के लिए, ओरिएंटेशन सेंसर और लीनियर ऐक्सलरेशन सेंसर.)

डिवाइस में सेट किए गए सिस्टम के लिए:

• इन सेंसर टाइप को लागू करना चाहिए. हालांकि, ऐसा तब ही किया जाना चाहिए, जब इनमें सेंसर टाइप में बताए गए ज़रूरी फ़िज़िकल सेंसर शामिल हों.

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

• [C-2-1] सेंसर को Android Open Source के दस्तावेज़ में बताए गए तरीके से लागू करना ज़रूरी है. यह दस्तावेज़ कंपोज़िट सेंसर के बारे में है.

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

• [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 API में दी गई जानकारी के मुताबिक, Android सेंसर कोऑर्डिनेट सिस्टम का पालन करना ज़रूरी है.

• [C-1-4] में किसी भी ऐक्सिस पर, फ़्रीफ़ॉल से लेकर gravity(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 सेंसर को लागू करने और उसके बारे में जानकारी देने का सुझाव दिया जाता है.

अगर डिवाइस में 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-ऐक्सिस मैग्नेटोमीटर (कंपास) शामिल करने का सुझाव दिया जाता है.

अगर डिवाइस में 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 mW से कम बिजली खर्च करनी चाहिए.

7.3.3. जीपीएस

डिवाइस में सेट किए गए सिस्टम के लिए:

• [C-SR-1] इनमें जीपीएस/जीएनएसएस रिसीवर शामिल करने का सुझाव दिया जाता है.

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

• [C-1-1] LocationManager#requestLocationUpdate के ज़रिए अनुरोध किए जाने पर, जगह की जानकारी के आउटपुट के साथ, कम से कम 1 हर्ट्ज़ की दर से काम करना चाहिए.

• [C-1-2] 0.5 एमबीपीएस या इससे ज़्यादा डेटा स्पीड वाले इंटरनेट कनेक्शन से कनेक्ट होने पर, खुले आसमान वाली जगहों (तेज़ सिग्नल, न के बराबर मल्टीपाथ, HDOP < 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 लोकेशन प्रोवाइडर एपीआई के ज़रिए सामान्य जीपीएस/जीएनएसएस लोकेशन आउटपुट देने का सुझाव दिया जाता है.

• [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 सेंसर को लागू करने और उसके बारे में जानकारी देने का सुझाव दिया जाता है.

अगर डिवाइस में 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 होनी चाहिए. यह समुद्र तल पर ~200 मीटर के बदलाव पर ~1 मीटर की ऐक्युरेसी के बराबर है.

ऐसे डिवाइस जिनमें सिस्टम प्रॉपर्टी sensor.barometer.high_quality.implemented का इस्तेमाल किया जाता है:

• [C-2-1] डिवाइस को 300 hPa से 1100 hPa के बीच के प्रेशर मेज़रमेंट की जानकारी देनी चाहिए. साथ ही, इसकी सटीक वैल्यू +/- 1 hPa होनी चाहिए.

• [C-2-2] इसमें 100 hPa की रेंज में 0.15 hPa की रिलेटिव एक्यूरेसी होनी चाहिए. यह समुद्र तल पर ~1000 मीटर के बदलाव पर ~1 मीटर की एक्यूरेसी के बराबर है.

• [C-2-3] उपयोगकर्ता के डिवाइस को टैप, दबाने या निचोड़ने पर, बैरोमीटर में +/- 0.5 hPa का अंतर होना चाहिए.

• [C-2-4] जब उपयोगकर्ता डिवाइस को हाथ में लेकर या जेब में रखकर चलता है, तब बैरोमीटर को +/- 0.15 hPa के अंदर स्थिर रहना चाहिए.

• [C-2-5] 5 हर्ट्ज़ से ज़्यादा की फ़्रीक्वेंसी पर, 300 मि॰से॰ से ज़्यादा के टाइम कॉन्स्टेंट का इस्तेमाल करके, डेटा को स्मूथ नहीं किया जाना चाहिए. साथ ही, स्मूथ किए गए डेटा को सेंसर ऐक्टिवेशन के बीच शेयर नहीं किया जाना चाहिए.

• [C-2-6] रोज़ाना इस्तेमाल होने वाली रोशनी और ब्लूटूथ, मोबाइल इंटरनेट कनेक्शन या वाई-फ़ाई जैसे सामान्य सोर्स से मिलने वाली रेडियो फ़्रीक्वेंसी के संपर्क में आने पर, यह +/- 0.15 hPa के अंदर स्थिर होना चाहिए.

7.3.6. Thermometer

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

• [C-1-1] एंबियंट टेंपरेचर सेंसर के लिए SENSOR_TYPE_AMBIENT_TEMPERATURE को तय करना ज़रूरी है. साथ ही, सेंसर को उस जगह का एंबियंट (कमरे/वाहन का केबिन) तापमान मेज़र करना चाहिए जहां से उपयोगकर्ता डिवाइस के साथ इंटरैक्ट कर रहा है. यह तापमान डिग्री सेल्सियस में होना चाहिए.

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

• [C-2-1] तापमान मापने वाले सेंसर के लिए, SENSOR_TYPE_AMBIENT_TEMPERATURE को तय नहीं किया जाना चाहिए.

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

• [C-SR-1] PowerManager.getThermalHeadroom API का इस्तेमाल करने का सुझाव दिया जाता है.

7.3.7. फ़ोटोमीटर

• डिवाइस में फ़ोटोमीटर (स्क्रीन की रोशनी को अपने-आप घटाने-बढ़ाने वाला सेंसर) शामिल हो सकता है.

7.3.8. निकटता सेंसर

• डिवाइस में प्रॉक्सिमिटी सेंसर शामिल किया जा सकता है.

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

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

• [C-1-2] में एक बिट या इससे ज़्यादा की सटीक जानकारी होनी चाहिए.

• [C-1-3] नज़दीकी रीडिंग के लिए 0 सेंटीमीटर और दूर की रीडिंग के लिए 5 सेंटीमीटर का इस्तेमाल करना ज़रूरी है.

• [C-1-4] ज़्यादा से ज़्यादा रेंज और 5 के रिज़ॉल्यूशन की जानकारी देना ज़रूरी है.

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 एलएसबी/ग्राम होना चाहिए.

  • मेज़रमेंट की फ़्रीक्वेंसी कम से कम 12.5 हर्ट्ज़ या इससे कम होनी चाहिए.

  • मेज़रमेंट की फ़्रीक्वेंसी ज़्यादा से ज़्यादा 400 हर्ट्ज़ या इससे ज़्यादा होनी चाहिए; इसमें SensorDirectChannel RATE_VERY_FAST की सुविधा होनी चाहिए.

  • मेज़रमेंट नॉइज़ 400 μg/√Hz से ज़्यादा नहीं होना चाहिए.

  • इस सेंसर के नॉन-वेक-अप फ़ॉर्म को लागू करना ज़रूरी है. साथ ही, इसमें कम से कम 3,000 सेंसर इवेंट को बफ़र करने की सुविधा होनी चाहिए.

  • बैटरी की खपत 3 mW से ज़्यादा नहीं होनी चाहिए.

  • [C-SR-1] में, नाइक्विस्ट फ़्रीक्वेंसी के कम से कम 80% के 3 डीबी मेज़रमेंट बैंडविथ का इस्तेमाल करने का सुझाव दिया जाता है. साथ ही, इस बैंडविथ में व्हाइट नॉइज़ स्पेक्ट्रम का इस्तेमाल करने का सुझाव दिया जाता है.

  • कमरे के तापमान पर जांच करने पर, एक्सलरेशन रैंडम वॉक 30 μg √Hz से कम होना चाहिए.

  • तापमान के मुकाबले, इसमें ≤ +/- 1 मिलीग्राम/°C का बदलाव होना चाहिए.

  • इसमें सबसे सही फ़िट होने वाली लाइन की नॉन-लीनियैरिटी ≤ 0.5% होनी चाहिए. साथ ही, तापमान के हिसाब से सेंसिटिविटी में बदलाव ≤ 0.03%/C° होना चाहिए.

  • डिवाइस के ऑपरेटिंग तापमान की रेंज में, क्रॉस-ऐक्सिस की संवेदनशीलता 2.5 % से कम होनी चाहिए. साथ ही, क्रॉस-ऐक्सिस की संवेदनशीलता में बदलाव 0.2% से कम होना चाहिए.

• [C-2-2] में TYPE_ACCELEROMETER_UNCALIBRATED होना चाहिए. साथ ही, इसकी क्वालिटी से जुड़ी ज़रूरी शर्तें TYPE_ACCELEROMETER के जैसी होनी चाहिए.

• [C-2-3] डिवाइस में TYPE_GYROSCOPE सेंसर होना ज़रूरी है. यह सेंसर:

  • मेज़रमेंट की रेंज, कम से कम -1000 और +1000 dps के बीच होनी चाहिए.

  • इसका मेज़रमेंट रिज़ॉल्यूशन कम से कम 16 एलएसबी/डीपीएस होना चाहिए.

  • मेज़रमेंट की फ़्रीक्वेंसी कम से कम 12.5 हर्ट्ज़ या इससे कम होनी चाहिए.

  • मेज़रमेंट की फ़्रीक्वेंसी ज़्यादा से ज़्यादा 400 हर्ट्ज़ या इससे ज़्यादा होनी चाहिए; इसमें SensorDirectChannel RATE_VERY_FAST की सुविधा होनी चाहिए.

  • मेज़रमेंट नॉइज़ 0.014&°/s/√Hz से ज़्यादा नहीं होना चाहिए.

  • [C-SR-2] में, नाइक्विस्ट फ़्रीक्वेंसी के कम से कम 80% के 3 डीबी मेज़रमेंट बैंडविड्थ और इस बैंडविड्थ के अंदर व्हाइट नॉइज़ स्पेक्ट्रम को शामिल करने का सुझाव दिया जाता है.

  • कमरे के तापमान पर जांच करने पर, रेट रैंडम वॉक 0.001&°/s √Hz से कम होना चाहिए.

  • तापमान के हिसाब से, बायस में बदलाव ≤ +/- 0.05&°/ s / °C होना चाहिए.

  • तापमान में ≤ 0.02% / °C के हिसाब से बदलाव होने पर, सेंसिटिविटी में बदलाव होना चाहिए.

  • इसमें सबसे सही फ़िट वाली लाइन की नॉन-लीनियरिटी ≤ 0.2% होनी चाहिए.

  • इसमें नॉइज़ डेंसिटी ≤ 0.007&°/s/√Hz होनी चाहिए.

  • डिवाइस के स्थिर होने पर, तापमान की रेंज 10 ~ 40 ℃ में कैलिब्रेशन की गड़बड़ी 0.002 रेडियन/सेकंड से कम होनी चाहिए.

  • g-सेंसिटिविटी 0.1&°/s/g से कम होनी चाहिए.

  • डिवाइस के ऑपरेटिंग तापमान की रेंज में, क्रॉस-ऐक्सिस की संवेदनशीलता 4.0 % से कम होनी चाहिए और क्रॉस-ऐक्सिस की संवेदनशीलता में बदलाव 0.3% से कम होना चाहिए.

• [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_MAGNETIC_FIELD_UNCALIBRATED एट्रिब्यूट की वैल्यू के तौर पर दी गई इमेज की क्वालिटी, TYPE_GEOMAGNETIC_FIELD एट्रिब्यूट की वैल्यू के तौर पर दी गई इमेज की क्वालिटी के बराबर होनी चाहिए. साथ ही:

  • इस सेंसर के लिए, नॉन-वेक-अप फ़ॉर्म को लागू करना ज़रूरी है. साथ ही, इसमें कम से कम 600 सेंसर इवेंट को बफ़र करने की सुविधा होनी चाहिए.

  • [C-SR-3] अगर रिपोर्टिंग की दर 50 हर्ट्ज़ या इससे ज़्यादा है, तो यह सुझाव दिया जाता है कि लगातार एक जैसी आवाज़ (वाइट नॉइज़) स्पेक्ट्रम 1 हर्ट्ज़ से कम से कम 10 हर्ट्ज़ तक हो.

• [C-2-7] TYPE_PRESSURE सेंसर का होना ज़रूरी है. साथ ही, यह भी ज़रूरी है कि:

  • इसका मेज़रमेंट रेंज कम से कम 300 और 1100 hPa के बीच होनी चाहिए.

  • इसका मेज़रमेंट रिज़ॉल्यूशन कम से कम 80 एलएसबी/एचपीए होना चाहिए.

  • मेज़रमेंट की फ़्रीक्वेंसी कम से कम 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] ऐक्सिलरोमीटर, जायरोस्कोप, और मैग्नेटोमीटर से रिपोर्ट किए गए एक ही फ़िज़िकल इवेंट के इवेंट टाइमस्टैंप के बीच 2.5 मिलीसेकंड से ज़्यादा का अंतर नहीं होना चाहिए. ऐक्सिलरोमीटर और जायरोस्कोप से रिपोर्ट किए गए एक ही फ़िज़िकल इवेंट का टाइमस्टैंप, एक-दूसरे से 0.25 मिलीसेकंड के अंदर होना चाहिए.

• [C-2-14] जाइरोस्कोप सेंसर इवेंट के टाइमस्टैंप, कैमरा सबसिस्टम के टाइमस्टैंप के साथ मैच होने चाहिए. साथ ही, इनमें एक मिलीसेकंड से ज़्यादा का अंतर नहीं होना चाहिए.

• [C-2-15] ऐप्लिकेशन को ऊपर दिए गए किसी भी फ़िज़िकल सेंसर पर डेटा उपलब्ध होने के पांच मिलीसेकंड के अंदर, ऐप्लिकेशन को सैंपल डिलीवर करने होंगे.

• [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-4-4] ऐप्लिकेशन को BiometricPrompt में कस्टम कॉन्टेंट जोड़ने की अनुमति देनी होगी. इसके लिए, PromptContentView के कॉन्टेंट डिसप्ले फ़ॉर्मैट का इस्तेमाल करना होगा. कॉन्टेंट दिखाने के फ़ॉर्मैट को इस तरह से नहीं बढ़ाया जाना चाहिए कि उसमें इमेज, लिंक, इंटरैक्टिव कॉन्टेंट या मीडिया के अन्य फ़ॉर्म शामिल किए जा सकें. ऐसा सिर्फ़ तब किया जा सकता है, जब वे पहले से ही BiometricPromptAPI का हिस्सा हों. इस कॉन्टेंट में ऐसे बदलाव किए जा सकते हैं जिनसे कॉन्टेंट में कोई बदलाव न हो, वह छिपा न हो या छोटा न हो. जैसे, पोज़िशन, पैडिंग, मार्जिन, और टाइपोग्राफ़ी बदलना.

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

• [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] इस सेक्शन में बताई गई, क्लास 3 के लिए ज़रूरी शर्तों को पूरा करना ज़रूरी है.

• [C-6-2] जब पुष्टि करने के लिए BIOMETRIC_STRONG की ज़रूरत हो या पुष्टि करने की प्रोसेस को CryptoObject के साथ शुरू किया गया हो, तब सिर्फ़ क्लास 3 बायोमेट्रिक्स का इस्तेमाल करना ज़रूरी है.

अगर डिवाइस में सेट किए गए सिस्टम, बायोमेट्रिक सेंसर को क्लास 1 (पहले इसे सुविधा कहा जाता था) के तौर पर इस्तेमाल करना चाहते हैं, तो उन्हें:

• [C-1-1] ज़रूरी है कि फ़ॉल्स ऐक्सेप्टेंस रेट 0.002% से कम हो.

• [C-1-2] अगर Android Biometrics Test Protocols के मुताबिक, स्पूफ़िंग और धोखाधड़ी से पुष्टि होने की दर 7% से ज़्यादा है, तो यह बताना ज़रूरी है कि यह मोड, किसी मुश्किल पिन, पैटर्न या पासवर्ड के मुकाबले कम सुरक्षित हो सकता है. साथ ही, इसे चालू करने से जुड़े जोखिमों के बारे में साफ़ तौर पर बताना ज़रूरी है.

• [C-1-9] बीस बार गलत तरीके से बायोमेट्रिक की पुष्टि करने की कोशिश करने के बाद, उपयोगकर्ता को पुष्टि करने के लिए सुझाए गए मुख्य तरीके (जैसे, पिन, पैटर्न, पासवर्ड) का इस्तेमाल करने के लिए कहना होगा.साथ ही, बायोमेट्रिक की पुष्टि करने के लिए, कम से कम नब्बे सेकंड का बैकऑफ़ समय देना होगा. यहां, गलत तरीके से बायोमेट्रिक की पुष्टि करने की कोशिश का मतलब है कि बायोमेट्रिक की क्वालिटी अच्छी है (BIOMETRIC_ACQUIRED_GOOD), लेकिन वह रजिस्टर किए गए बायोमेट्रिक से मेल नहीं खाती.

• [C-SR-4] अगर Android Biometrics Test Protocols के मुताबिक, स्पूफ़िंग और धोखेबाज़ों के लिए पुष्टि स्वीकार किए जाने की दर 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 Biometrics Test Protocols के हिसाब से तय की जाती है.

• [C-1-4] नई बायोमेट्रिक जानकारी जोड़ने से पहले, भरोसे की चेन बनाना ज़रूरी है. इसके लिए, उपयोगकर्ता को मौजूदा डिवाइस क्रेडेंशियल (पिन/पैटर्न/पासवर्ड) की पुष्टि करनी होगी या नया डिवाइस क्रेडेंशियल जोड़ना होगा. यह क्रेडेंशियल टीईई से सुरक्षित होना चाहिए. 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 घंटे या उससे कम समय में, उपयोगकर्ता को पुष्टि करने के लिए सुझाए गए मुख्य तरीके (जैसे, पिन, पैटर्न, पासवर्ड) का इस्तेमाल करने के लिए कहना ज़रूरी है.

• [C-1-8] इनमें से कोई भी कार्रवाई होने के बाद, उपयोगकर्ता को सुझाए गए मुख्य पुष्टि करने के तरीके (जैसे कि पिन, पैटर्न, पासवर्ड) या क्लास 3 (मज़बूत) बायोमेट्रिक का इस्तेमाल करने के लिए कहना ज़रूरी है:

  • चार घंटे तक कोई गतिविधि न होने पर टाइम आउट हो जाता है.
  • बायोमेट्रिक ऑथेंटिकेशन की पुष्टि करने के लिए तीन बार कोशिश की गई, लेकिन पुष्टि नहीं हो सकी.
  • डिवाइस के क्रेडेंशियल की पुष्टि हो जाने के बाद, निष्क्रियता की समयसीमा और पुष्टि न होने की संख्या रीसेट हो जाती है.

• [C-SR-7] नए डिवाइसों के लिए, Android Open Source Project की ओर से दिए गए फ़्रेमवर्क में मौजूद लॉजिक का इस्तेमाल करने का सुझाव दिया जाता है. इससे [C-1-7] और [C-1-8] में बताई गई पाबंदियों को लागू किया जा सकेगा.

• [C-SR-8] यह सुझाव दिया जाता है कि डिवाइस पर मेज़र किए गए फ़िंगरप्रिंट के लिए, गलत तरीके से अस्वीकार किए जाने की दर 10% से कम होनी चाहिए.

• [C-SR-9] यह सुझाव दिया जाता है कि बायोमेट्रिक डेटा का पता चलने से लेकर स्क्रीन अनलॉक होने तक, हर बायोमेट्रिक के लिए एक सेकंड से कम समय लगना चाहिए.

• [C-1-12] Android Biometrics Test Protocols के मुताबिक, हर तरह के प्रेजेंटेशन अटैक इंस्ट्रूमेंट (पीएआई) के लिए, स्पूफ़िंग और धोखेबाज़ों को स्वीकार करने की दर 40% से ज़्यादा नहीं होनी चाहिए.

• [C-SR-13] Android Biometrics Test Protocols के मुताबिक, हर तरह के प्रज़ेंटेशन अटैक इंस्ट्रूमेंट (पीएआई) के लिए, स्पूफ़ और धोखेबाज़ के तौर पर स्वीकार किए जाने की दर 30% से ज़्यादा नहीं होनी चाहिए.

• [C-SR-8] यह सुझाव दिया जाता है कि डिवाइस पर मेज़र किए गए फ़िंगरप्रिंट के लिए, गलत तरीके से अस्वीकार किए जाने की दर 10% से कम होनी चाहिए.

• [C-1-15] उपयोगकर्ताओं को एक या एक से ज़्यादा बायोमेट्रिक डेटा हटाने की अनुमति देनी होगी.

• [C-SR-14] बायोमेट्रिक सेंसर की बायोमेट्रिक क्लास और उसे चालू करने से जुड़े जोखिमों के बारे में जानकारी देने का सुझाव दिया जाता है.

• [C-SR-17] नए एआईडीएल इंटरफ़ेस (जैसे कि IFace.aidl और IFingerprint.aidl) लागू करने का सुझाव दिया जाता है.

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

• [C-2-1] को ऊपर दी गई क्लास 1 की सभी ज़रूरी शर्तों को पूरा करना होगा.

• [C-2-2] ज़रूरी है कि स्पूफ़ और धोखेबाज़ के तौर पर स्वीकार किए जाने की दर 20% से ज़्यादा न हो. साथ ही, (1) लेवल A के प्रज़ेंटेशन अटैक इंस्ट्रूमेंट (पीएआई) के लिए, स्पूफ़ और धोखेबाज़ के तौर पर स्वीकार किए जाने की दर 20% से ज़्यादा न हो. इसके अलावा, (2) लेवल B के पीएआई के लिए, स्पूफ़ और धोखेबाज़ के तौर पर स्वीकार किए जाने की दर 30% से ज़्यादा न हो. यह दर, Android Biometrics Test Protocols के हिसाब से तय की जाती है.

• [C-SR-15] Android Biometrics Test Protocols के मुताबिक, हर तरह के प्रज़ेंटेशन अटैक इंस्ट्रूमेंट (पीएआई) के लिए, स्पूफ़िंग और धोखाधड़ी करने वाले व्यक्ति की पहचान स्वीकार करने की दर 20% से ज़्यादा नहीं होनी चाहिए.

• [C-2-3] बायोमेट्रिक मैचिंग को, Android उपयोगकर्ता या कर्नेल स्पेस से बाहर, अलग एक्ज़ीक्यूशन एनवायरमेंट में करना ज़रूरी है. जैसे, ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट (टीईई). यह काम, अलग एक्ज़ीक्यूशन एनवायरमेंट के साथ सुरक्षित चैनल वाले चिप पर या प्रोटेक्टेड वर्चुअल मशीन पर किया जाना चाहिए. प्रोटेक्टेड वर्चुअल मशीन, सेक्शन 9.17 में दी गई ज़रूरी शर्तों को पूरा करती हो.

• [C-2-4] ऐसे सभी डेटा को एन्क्रिप्ट (सुरक्षित) किया जाना चाहिए जिससे पहचान ज़ाहिर होती हो. साथ ही, क्रिप्टोग्राफ़िक तरीके से पुष्टि की जानी चाहिए, ताकि उन्हें अलग एक्ज़ीक्यूशन एनवायरमेंट या अलग एक्ज़ीक्यूशन एनवायरमेंट के साथ सुरक्षित चैनल वाले चिप के बाहर हासिल, पढ़ा या बदला न जा सके. इसकी जानकारी, Android ओपन सोर्स प्रोजेक्ट की साइट पर मौजूद लागू करने के दिशा-निर्देशों में दी गई है. इसके अलावा, हाइपरवाइज़र से कंट्रोल की जाने वाली सुरक्षित वर्चुअल मशीन के लिए, सेक्शन 9.17 में दी गई ज़रूरी शर्तों को पूरा करना ज़रूरी है.

• [C-2-5] कैमरे पर आधारित बायोमेट्रिक डेटा के लिए, बायोमेट्रिक डेटा के आधार पर पुष्टि करने या रजिस्टर करने के दौरान:

  • कैमरे को ऐसे मोड में चलाना होगा जिससे कैमरे के फ़्रेम को आइसोलेटेड एक्ज़ीक्यूशन एनवायरमेंट के बाहर न तो पढ़ा जा सके और न ही बदला जा सके. इसके अलावा, कैमरे को ऐसे चिप के साथ चलाना होगा जिसमें आइसोलेटेड एक्ज़ीक्यूशन एनवायरमेंट के लिए सुरक्षित चैनल हो. इसके अलावा, कैमरे को हाइपरवाइज़र से कंट्रोल की जाने वाली ऐसी प्रोटेक्टेड वर्चुअल मशीन के साथ चलाना होगा जो सेक्शन 9.17 में दी गई ज़रूरी शर्तों को पूरा करती हो.

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

• [C-2-6] तीसरे पक्ष के ऐप्लिकेशन को, अलग-अलग बायोमेट्रिक रजिस्ट्रेशन के बीच अंतर करने की अनुमति नहीं देनी चाहिए.

• [C-2-7] पहचान ज़ाहिर करने वाले बायोमेट्रिक डेटा या उससे मिले किसी भी डेटा (जैसे, एम्बेडिंग) को, ऐप्लिकेशन प्रोसेसर को बिना एन्क्रिप्ट (सुरक्षित) किए ऐक्सेस करने की अनुमति नहीं देनी चाहिए. ऐसा टीईई या हाइपरवाइज़र के कंट्रोल वाली सुरक्षित वर्चुअल मशीन के कॉन्टेक्स्ट के बाहर नहीं किया जाना चाहिए. हाइपरवाइज़र को सेक्शन 9.17 में दी गई ज़रूरी शर्तों को पूरा करना होगा. Android 9 या इससे पहले के वर्शन पर लॉन्च किए गए डिवाइसों को अपग्रेड करने पर, [C-2-7] से छूट नहीं मिलती.

• [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 Biometrics Test Protocols के हिसाब से तय की जाती है.

• [C-3-4] डिवाइस को हर 72 घंटे या उससे कम समय में, उपयोगकर्ता से पुष्टि करने के लिए सुझाए गए मुख्य तरीके (जैसे कि पिन, पैटर्न, पासवर्ड) का इस्तेमाल करने के लिए कहना होगा.

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

• [C-3-6] तीसरे पक्ष के ऐप्लिकेशन के लिए, बायोमेट्रिक डेटा की मदद से सुरक्षित की गई कीस्टोर कुंजियां चालू करनी होंगी.

• [C-SR-16] यह सुझाव दिया जाता है कि स्पूफ़िंग और धोखाधड़ी करने वाले व्यक्ति की पहचान स्वीकार करने की दर, हर तरह के प्रेजेंटेशन अटैक इंस्ट्रूमेंट (पीएआई) के लिए 7% से ज़्यादा न हो. इसकी जांच Android Biometrics Test Protocols के ज़रिए की जाती है.

अगर डिवाइस में डिसप्ले में मौजूद फ़िंगरप्रिंट सेंसर (यूडीएफ़पीएस) शामिल है, तो:

• [C-SR-11] में यह सुझाव दिया गया है कि यूडीएफ़पीएस के टच किए जा सकने वाले हिस्से को तीन बटन वाले नेविगेशन में रुकावट डालने से रोकने के लिए, यह ज़रूरी है कि यूडीएफ़पीएस का टच किया जा सकने वाला हिस्सा, स्क्रीन के निचले हिस्से में मौजूद तीन बटन वाले नेविगेशन के ऊपर न हो. ऐसा इसलिए, क्योंकि कुछ उपयोगकर्ताओं को ऐक्सेसिबिलिटी के लिए इसकी ज़रूरत पड़ सकती है.

7.3.11. पोज़ सेंसर

डिवाइस में सेट किए गए सिस्टम के लिए:

• इसमें छह डिग्री ऑफ़ फ़्रीडम वाले पोज़ सेंसर की सुविधा हो सकती है.

अगर डिवाइस में 6 डिग्री ऑफ़ फ़्रीडम के साथ पोज़ सेंसर काम करता है, तो:

• [C-1-1] TYPE_POSE_6DOF सेंसर को लागू करना और उसके बारे में जानकारी देना ज़रूरी है.

• [C-1-2] को सिर्फ़ रोटेशन वेक्टर से ज़्यादा सटीक होना चाहिए.

7.3.12. हिंज ऐंगल सेंसर

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

• [C-1-1] TYPE_HINGE_ANGLE को लागू करना और उसके बारे में जानकारी देना ज़रूरी है.

• [C-1-2] 0 से 360 डिग्री के बीच कम से कम दो रीडिंग के साथ काम करना ज़रूरी है. इसमें 0 और 360 डिग्री शामिल हैं.

• [C-1-3] getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE) के लिए, wakeup सेंसर की वैल्यू रिटर्न करना ज़रूरी है.

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 जैसा ही है. हालांकि, इसमें पी-एसटीएस सुरक्षा मोड चालू होता है.

  • CONFIG_ID_5: यह CONFIG_ID_2 जैसा ही है. हालांकि, इसमें पी-एसटीएस सुरक्षा मोड चालू होता है.

  • CONFIG_ID_6: यह CONFIG_ID_3 जैसा ही है. हालांकि, इसमें पी-एसटीएस सुरक्षा मोड चालू होता है.

  • CONFIG_ID_7: यह CONFIG_ID_2 की तरह ही है. हालांकि, इसमें P-STS के लिए कंट्रोल किए जाने वाले व्यक्ति का मुख्य मोड चालू होता है.

• [C-1-4] डिवाइस में, उपयोगकर्ता को यूडब्ल्यूबी रेडियो को चालू/बंद करने का विकल्प देना ज़रूरी है.

• [C-1-5] यह ज़रूरी है कि यूडब्ल्यूबी रेडियो का इस्तेमाल करने वाले ऐप्लिकेशन के पास, UWB_RANGING अनुमति हो. यह अनुमति, NEARBY_DEVICES अनुमतियों के समूह के तहत आती है.

मानक तय करने वाली संस्थाओं के तय किए गए, ज़रूरी स्टैंडर्ड और सर्टिफ़िकेशन टेस्ट पास करने से यह पक्का करने में मदद मिलती है कि 802.1.15.4 ठीक से काम कर रहा है. इनमें FIRA, CCC, और CSA शामिल हैं.

7.3.14. कस्टम सेंसर

अलग-अलग डिवाइसों पर अलग-अलग अनुभव देने के लिए, डिवाइसों में Android या Wear OS के साथ काम न करने वाले अतिरिक्त सेंसर शामिल किए जा सकते हैं. पहले से लोड किए गए ऐप्लिकेशन, इन सेंसर को ऐक्सेस कर सकते हैं.

ऐसे सेंसर के लिए, सेंसर आईडी:

• [C-0-1] 65536 से ज़्यादा होना चाहिए.

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

• [C-0-2] इसे प्लैटफ़ॉर्म की अनुमति या सिस्टम की अनुमति से सुरक्षित किया जाना चाहिए.

7.4. डेटा कनेक्टिविटी

7.4.1. टेलीफ़ोनी

Android API और इस दस्तावेज़ में इस्तेमाल किया गया "टेलीफ़ोनी" शब्द, खास तौर पर वॉइस कॉल करने और एसएमएस भेजने से जुड़े हार्डवेयर के लिए इस्तेमाल किया जाता है. इसके अलावा, यह मोबाइल (जैसे, GSM, CDMA, LTE, NR) GSM या CDMA नेटवर्क के ज़रिए मोबाइल डेटा सेट अप करने के लिए भी इस्तेमाल किया जाता है. "टेलीफ़ोनी" की सुविधा वाले डिवाइस, कॉल, मैसेज, और डेटा सेवाओं में से कुछ या सभी सेवाएं उपलब्ध करा सकते हैं.

• Android का इस्तेमाल उन डिवाइसों पर किया जा सकता है जिनमें टेलीफ़ोनी हार्डवेयर शामिल नहीं है. इसका मतलब है कि Android, फ़ोन के अलावा अन्य डिवाइसों के साथ भी काम करता है.

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

• [C-1-1] टेक्नोलॉजी के हिसाब से, android.hardware.telephony फ़ीचर फ़्लैग और अन्य सब-फ़ीचर फ़्लैग के बारे में एलान करना ज़रूरी है.

• [C-1-2] उस टेक्नोलॉजी के लिए, एपीआई की पूरी सुविधा लागू करनी होगी.

• आपातकालीन कॉल के दौरान, सभी तरह की मोबाइल सेवा (2G, 3G, 4G, 5G वगैरह) का इस्तेमाल किया जा सकता है. भले ही, SetAllowedNetworkTypeBitmap() ने नेटवर्क के टाइप सेट किए हों या नहीं.

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

• [C-2-1] पूरे एपीआई को नो-ऑप्स के तौर पर लागू करना ज़रूरी है.

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

• [C-3-1] android.hardware.telephony.euicc फ़ीचर फ़्लैग के बारे में एलान करना ज़रूरी है.

अगर डिवाइसों में सिस्टम प्रॉपर्टी ro.telephony.iwlan_operation_mode को legacy पर सेट नहीं किया जाता है, तो:

• [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 Configuration API का इस्तेमाल करके, ऑटो कॉन्फ़िगरेशन सर्वर (एसीएस) या मालिकाना हक वाले अन्य प्रोविज़निंग मैकेनिज़्म के ज़रिए प्रोविज़निंग को पूरी तरह से लागू करना होगा.

अगर डिवाइसों पर 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 API का इस्तेमाल करना होगा. packages/apps/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 के सभी इंस्टेंस को एक ही सदस्यता के तौर पर दिखाना होगा. साथ ही, group UUIDs को भी एक ही सदस्यता के तौर पर दिखाना होगा. ऐसा उन सभी सुविधाओं में करना होगा जो उपयोगकर्ताओं को दिखती हैं और जिनमें सिम कार्ड की जानकारी दिखती है और उसे कंट्रोल किया जा सकता है. इस तरह की सुविधाओं के उदाहरणों में, Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS या EuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS से मिलते-जुलते सेटिंग इंटरफ़ेस शामिल हैं.

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

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

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

• [C-SR-1] हमारा सुझाव है कि डेटा के लिए चालू सदस्यता को प्रतिनिधि सदस्यता के तौर पर चुना जाए. हालांकि, अगर डिवाइस पर वॉइस कॉल चल रहा है, तो हमारा सुझाव है कि वॉइस कॉल के लिए चालू सदस्यता को प्रतिनिधि सदस्यता के तौर पर चुना जाए.

अगर डिवाइसों पर android.hardware.telephony सुविधा उपलब्ध है, तो:

• [C-6-7] ETSI TS 102 221 के मुताबिक, हर UICC के लिए ज़्यादा से ज़्यादा लॉजिकल चैनल (कुल 20) खोलने और उनका एक साथ इस्तेमाल करने की सुविधा होनी चाहिए.

• [C-6-8] TelephonyManager#getCarrierServicePackageName के तौर पर डेज़िग्नेट किए गए, चालू कैरियर ऐप्लिकेशन पर इनमें से कोई भी व्यवहार अपने-आप या उपयोगकर्ता की साफ़ तौर पर पुष्टि किए बिना लागू नहीं होना चाहिए:

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

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

• [C-8-1] उसी ग्रुप में मौजूद, मौकापरस्त सदस्यताएं अपने-आप बंद होनी चाहिए.

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

• [C-9-1] PackageManager#FEATURE_TELEPHONY_CDMA का एलान नहीं किया जाना चाहिए.

• [C-9-2] अगर कोई ऐप्लिकेशन, पसंदीदा या अनुमति वाले नेटवर्क टाइप के बिटमास्क में किसी भी 3GPP2 नेटवर्क टाइप को सेट करने की कोशिश करता है, तो उसे IllegalArgumentException दिखाना होगा.

• [C-9-3] TelephonyManager#getMeid से खाली स्ट्रिंग दिखानी होगी.

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

• [C-10-1] android.hardware.telephony.euicc.mep फ़ीचर फ़्लैग के बारे में एलान करना ज़रूरी है.

7.4.1.1. नंबर ब्लॉक करने की सुविधा के साथ काम करने वाले डिवाइस

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

• [C-1-1] MUST include number blocking support

• [C-1-2] एसडीके के दस्तावेज़ में बताए गए तरीके के मुताबिक, BlockedNumberContract और इससे जुड़े एपीआई को पूरी तरह से लागू करना ज़रूरी है.

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

• [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] एसडीके में बताए गए ConnectionService एपीआई के साथ काम करना ज़रूरी है.

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

• [C-1-3] ज़रूरी है कि डिवाइस में ऐसा ऐप्लिकेशन हो जो InCallService को लागू करता हो.

• [C-SR-1] उपयोगकर्ता को यह सूचना देना ज़रूरी है कि इनकमिंग कॉल का जवाब देने पर, चालू कॉल बंद हो जाएगा.

  AOSP में, इन ज़रूरी शर्तों को पूरा किया जाता है. इसके लिए, स्क्रीन पर सबसे ऊपर सूचना देने वाला कार्ड दिखाया जाता है. इससे उपयोगकर्ता को पता चलता है कि इनकमिंग कॉल का जवाब देने पर, दूसरा कॉल बंद हो जाएगा.

• [C-SR-2] डिफ़ॉल्ट डायलर ऐप्लिकेशन को पहले से लोड करने का सुझाव दिया जाता है. यह ऐप्लिकेशन, कॉल लॉग में कॉल लॉग एंट्री और तीसरे पक्ष के ऐप्लिकेशन का नाम दिखाता है. ऐसा तब होता है, जब तीसरे पक्ष का ऐप्लिकेशन अपने PhoneAccount पर EXTRA_LOG_SELF_MANAGED_CALLS एक्स्ट्रा कुंजी को 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 कीपअलाइव ऑफ़लोड

डिवाइस में सेट किए गए सिस्टम के लिए:

• इसमें सेल्युलर कीपअलाइव ऑफ़लोड के लिए समर्थन शामिल होना चाहिए.

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

• [C-1-1] इसमें SocketKeepAlive API की सुविधा होनी चाहिए.

• [C-1-2] सेल्यूलर नेटवर्क पर, कम से कम एक साथ चालू रहने वाले कीपअलाइव स्लॉट के साथ काम करना ज़रूरी है.

• [C-1-3] यह ज़रूरी है कि डिवाइस, सेल्युलर रेडियो एचएएल के साथ काम करने वाले सेल्युलर कीपअलाइव स्लॉट के साथ काम करे.

• [C-SR-1] हर रेडियो इंस्टेंस के लिए, कम से कम तीन सेल्यूलर कीपअलाइव स्लॉट इस्तेमाल करने का सुझाव दिया जाता है.

अगर डिवाइस में, मोबाइल डेटा को चालू रखने की सुविधा के लिए, डेटा को ऑफ़लोड करने की सुविधा शामिल नहीं है, तो:

• [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] एसडीके के दस्तावेज़ में बताए गए तरीके से, मल्टीकास्ट एपीआई को लागू करना ज़रूरी है.

• [C-1-4] डिवाइस में mDNS की सुविधा काम करनी चाहिए. साथ ही, डिवाइस के चालू रहने के दौरान, mDNS पैकेट (224.0.0.251 या ff02::fb) को फ़िल्टर नहीं किया जाना चाहिए. भले ही, स्क्रीन चालू न हो. हालांकि, अगर मल्टीकास्ट लॉक नहीं है और पैकेट को APF फ़िल्टर करता है, तो ऐसा किया जा सकता है. फ़िलहाल, NsdManager API के ज़रिए ऐप्लिकेशन ने mDNS से जुड़ी जिन कार्रवाइयों का अनुरोध किया है उन्हें पूरा करने के लिए, इन पैकेट की ज़रूरत नहीं है. हालांकि, अगर टारगेट मार्केट में लागू होने वाली कानूनी शर्तों के मुताबिक, बिजली की खपत की तय सीमा में रहना ज़रूरी है, तो डिवाइस mDNS पैकेट को फ़िल्टर कर सकता है.

• [C-1-5] WifiManager.enableNetwork() एपीआई के तरीके को कॉल करने को, Network को स्विच करने के लिए ज़रूरी संकेत के तौर पर नहीं माना जाना चाहिए. Network का इस्तेमाल, ऐप्लिकेशन के ट्रैफ़िक के लिए डिफ़ॉल्ट रूप से किया जाता है. साथ ही, इसे ConnectivityManager एपीआई के तरीके से वापस लाया जाता है. जैसे, getActiveNetwork और registerDefaultNetworkCallback. दूसरे शब्दों में कहें, तो वे किसी अन्य नेटवर्क सेवा देने वाली कंपनी (जैसे, मोबाइल डेटा) से मिले इंटरनेट ऐक्सेस को सिर्फ़ तब बंद कर सकते हैं, जब वे यह पुष्टि कर लें कि वाई-फ़ाई नेटवर्क से इंटरनेट ऐक्सेस मिल रहा है.

• [C-1-6] ConnectivityManager.reportNetworkConnectivity() एपीआई के तरीके को कॉल करने पर, Network पर इंटरनेट ऐक्सेस का फिर से आकलन करने का सुझाव दिया जाता है. साथ ही, आकलन से यह पता चलने पर कि मौजूदा Network अब इंटरनेट ऐक्सेस नहीं देता है, इंटरनेट ऐक्सेस देने वाले किसी अन्य उपलब्ध नेटवर्क (जैसे, मोबाइल डेटा) पर स्विच करने का सुझाव दिया जाता है.

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

• [C-1-8] एक स्कैन के दौरान भेजे गए प्रोब रिक्वेस्ट फ़्रेम के हर ग्रुप को एक ही एमएसी पते का इस्तेमाल करना चाहिए. स्कैन के बीच में एमएसी पता नहीं बदलना चाहिए.

• [C-1-9] प्रोब रिक्वेस्ट फ़्रेम की क्रम संख्या, स्कैन के दौरान सामान्य रूप से क्रम में बढ़ती रहनी चाहिए.

• [C-1-10] किसी स्कैन की आखिरी प्रोब रिक्वेस्ट और अगले स्कैन की पहली प्रोब रिक्वेस्ट के बीच में प्रोब रिक्वेस्ट की क्रम संख्या को बदलते रहना चाहिए.

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

  • डिवाइस को हर SSID (पासपॉइंट के लिए FQDN) के साथ कम्यूनिकेट करते समय, बदला हुआ एक अलग एमएसी पता इस्तेमाल करना चाहिए.

  • डिवाइस को उपयोगकर्ता को हर SSID (पासपॉइंट के लिए FQDN) के लिए एमएसी पता बदलने या न बदलने का विकल्प देना चाहिए. साथ ही, नए वाई-फ़ाई कॉन्फ़िगरेशन के लिए डिफ़ॉल्ट के तौर पर सेट किया गया मोड बदला हुआ होना चाहिए.

• [C-SR-2] किसी भी एपी को बनाते समय एक ऐसे BSSID का इस्तेमाल किया जाना चाहिए जिसे बदला गया है.

  • एपी के इस्तेमाल किए गए हर SSID के लिए, एमएसी पता बदला गया होना चाहिए और वही बना रहना चाहिए.

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

अगर डिवाइस में, आईईईई 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] एसडीके के दस्तावेज़ में बताए गए तरीके के मुताबिक, Android API को लागू करना ज़रूरी है.

• [C-1-2] हार्डवेयर की सुविधा android.hardware.wifi.direct के बारे में जानकारी देना ज़रूरी है.

• [C-1-3] यह ज़रूरी है कि यह डिवाइस, वाई-फ़ाई की सामान्य सुविधा के साथ काम करता हो.

• [C-1-4] यह ज़रूरी है कि यह वाई-फ़ाई और वाई-फ़ाई डायरेक्ट, दोनों के साथ एक ही समय में काम करता हो.

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

7.4.2.2. वाई-फ़ाई टनल वाले डायरेक्ट लिंक का सेटअप

डिवाइस में सेट किए गए सिस्टम के लिए:

• इसमें Android SDK के दस्तावेज़ में बताए गए तरीके के मुताबिक, वाई-फ़ाई टनल वाले डायरेक्ट लिंक सेटअप (टीडीएलएस) की सुविधा शामिल होनी चाहिए.

अगर डिवाइस में TDLS की सुविधा काम करती है और WiFiManager API के ज़रिए TDLS चालू किया गया है, तो:

• [C-1-1] WifiManager.isTdlsSupported के ज़रिए, TDLS के साथ काम करने की जानकारी देना ज़रूरी है.

• टीडीएलएस का इस्तेमाल सिर्फ़ तब करना चाहिए, जब ऐसा करना मुमकिन हो और फ़ायदेमंद हो.

• इसमें कुछ अनुमानित तरीके होने चाहिए. साथ ही, जब इसकी परफ़ॉर्मेंस वाई-फ़ाई ऐक्सेस पॉइंट से कनेक्ट करने पर बेहतर हो सकती है, तब इसे टीडीएलएस का इस्तेमाल नहीं करना चाहिए.

7.4.2.3. Wi-Fi Aware

डिवाइस में सेट किए गए सिस्टम के लिए:

• Wi-Fi Aware के साथ काम करना चाहिए.

अगर डिवाइसों में Wi-Fi Aware की सुविधा काम करती है और तीसरे पक्ष के ऐप्लिकेशन के लिए यह सुविधा उपलब्ध है, तो:

• [C-1-1] एसडीके के दस्तावेज़ में बताए गए तरीके के मुताबिक, WifiAwareManager एपीआई लागू करना ज़रूरी है.

• [C-1-2] android.hardware.wifi.aware फ़ीचर फ़्लैग के बारे में एलान करना ज़रूरी है.

• [C-1-3] यह ज़रूरी है कि डिवाइस, वाई-फ़ाई और Wi-Fi Aware की सुविधाओं को एक साथ इस्तेमाल करने की अनुमति देता हो.

• [C-1-4] Wi-Fi Aware के मैनेजमेंट इंटरफ़ेस के पते को हर 30 मिनट में बदलना ज़रूरी है. साथ ही, जब भी Wi-Fi Aware चालू हो, तब भी इसे बदलना ज़रूरी है. हालांकि, अगर Aware की रेंजिंग की प्रोसेस चल रही है या Aware का डेटा-पाथ चालू है, तो इसे बदलने की ज़रूरत नहीं है. डेटा-पाथ चालू रहने तक, पते को बदलने की ज़रूरत नहीं है.

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

• [C-2-1] MUST implement the location-aware discovery APIs: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm, and onServiceDiscoveredWithinRange.

7.4.2.4. वाई-फ़ाई पासपॉइंट

अगर डिवाइस में 802.11 (वाई-फ़ाई) का इस्तेमाल किया जाता है, तो:

• इसमें Wi-Fi Passpoint की सुविधा होनी चाहिए.

अगर डिवाइस में वाई-फ़ाई पासपॉइंट की सुविधा काम करती है, तो:

• [C-1-2] एसडीके के दस्तावेज़ में बताए गए तरीके से, 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] को AAA सर्वर सर्टिफ़िकेट को प्रोसेस करना होगा. इसके बारे में Hotspot 2.0 R3 स्पेसिफ़िकेशन में बताया गया है.

• [C-1-8] वाई-फ़ाई पिकर के ज़रिए, डिवाइस को चालू करने की सुविधा को कंट्रोल करने का विकल्प उपलब्ध होना चाहिए.

• [C-1-9] यह ज़रूरी है कि रीबूट करने पर भी, Passpoint कॉन्फ़िगरेशन बने रहें.

• [C-SR-1] यह सुझाव दिया जाता है कि नियम और शर्तों को स्वीकार करने की सुविधा काम करती हो.

• [C-SR-2] यह ज़रूरी है कि जगह की जानकारी की सुविधा काम करती हो.

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

• [C-3-1] Passpoint को डिफ़ॉल्ट रूप से चालू करना ज़रूरी है.

7.4.2.5. वाई-फ़ाई की जगह की जानकारी (वाई-फ़ाई राउंड ट्रिप टाइम - आरटीटी)

डिवाइस में सेट किए गए सिस्टम के लिए:

• इसमें वाई-फ़ाई की जगह की जानकारी की सुविधा शामिल होनी चाहिए.

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

• [C-1-1] एसडीके के दस्तावेज़ में बताए गए तरीके के मुताबिक, WifiRttManager एपीआई लागू करना ज़रूरी है.

• [C-1-2] android.hardware.wifi.rtt फ़ीचर फ़्लैग के बारे में एलान करना ज़रूरी है.

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

• [C-1-4] 80 मेगाहर्ट्ज़ बैंडविथ पर, 68वें पर्सेंटाइल (संचयी बंटन फ़ंक्शन के हिसाब से कैलकुलेट किया गया) पर, यह 2 मीटर के अंदर सटीक होना चाहिए.

• [C-SR-1] यह सुझाव दिया जाता है कि 68वें पर्सेंटाइल पर 80 मेगाहर्ट्ज़ बैंडविथ के साथ, 1.5 मीटर के दायरे में सटीक जानकारी दी जाए. इसकी गणना, संचयी बंटन फ़ंक्शन के हिसाब से की जाती है.

7.4.2.6. वाई-फ़ाई कीपअलाइव ऑफ़लोड

डिवाइस में सेट किए गए सिस्टम के लिए:

• इसमें वाई-फ़ाई कीपअलाइव ऑफ़लोड की सुविधा होनी चाहिए.

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

• [C-1-1] SocketKeepAlive एपीआई के साथ काम करना ज़रूरी है.

• [C-1-2] वाई-फ़ाई पर कम से कम तीन कीपअलाइव स्लॉट के साथ काम करना ज़रूरी है

अगर डिवाइसों में, वाई-फ़ाई कीपअलाइव ऑफ़लोड की सुविधा काम नहीं करती, तो:

• [C-2-1] ERROR_UNSUPPORTED को वापस लाना ज़रूरी है.

7.4.2.7. वाई-फ़ाई ईज़ी कनेक्ट (डिवाइस प्रोविज़निंग प्रोटोकॉल)

डिवाइस में सेट किए गए सिस्टम के लिए:

• इसमें वाई-फ़ाई इज़ी कनेक्ट (डीपीपी) की सुविधा होनी चाहिए.

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

• [C-1-1] WifiManager#isEasyConnectSupported() तरीके से true वैल्यू वापस मिलनी चाहिए.

7.4.2.8. Enterprise Wi-Fi Server Certificate Validation

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

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

7.4.2.9. ट्रस्ट ऑन फ़र्स्ट यूज़ (टीओएफ़यू)

अगर डिवाइसों में ट्रस्ट ऑन फ़र्स्ट यूज़ (टीओएफ़यू) की सुविधा काम करती है और उपयोगकर्ता को WPA/WPA2/WPA3-Enterprise कॉन्फ़िगरेशन तय करने की अनुमति मिलती है, तो:

• [C-4-1] उपयोगकर्ता को TOFU का इस्तेमाल करने का विकल्प देना ज़रूरी है.

7.4.2.10. वाई-फ़ाई की मदद से नज़दीकी डिवाइसों का पता लगाना (पीयर-टू-पीयर प्रॉक्सिमिटी रेंजिंग)

7.4.3. ब्लूटूथ

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

• इसमें अडवांस ऑडियो कोडेक और ब्लूटूथ ऑडियो कोडेक (जैसे, LDAC) काम करने चाहिए.

अगर डिवाइस में HFP, A2DP, और AVRCP काम करते हैं, तो:

• डिवाइस में कम से कम पांच कनेक्ट किए गए डिवाइसों के साथ काम करने की सुविधा होनी चाहिए.

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

• [C-1-1] इनमें ब्लूटूथ 4.2 और ब्लूटूथ स्मार्ट डेटा लेंथ एक्सटेंशन काम करना चाहिए.

Android में ब्लूटूथ और ब्लूटूथ लो एनर्जी की सुविधा काम करती है.

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

• [C-2-1] प्लैटफ़ॉर्म की काम की सुविधाओं (android.hardware.bluetooth और android.hardware.bluetooth_le) के बारे में एलान करना और प्लैटफ़ॉर्म के एपीआई लागू करना ज़रूरी है.

• डिवाइस के हिसाब से, काम की ब्लूटूथ प्रोफ़ाइलें लागू करनी चाहिए. जैसे, A2DP, AVRCP, OBEX, HFP वगैरह.

अगर डिवाइस में ब्लूटूथ लो एनर्जी (बीएलई) की सुविधा काम करती है, तो:

• [C-3-1] हार्डवेयर की सुविधा android.hardware.bluetooth_le के बारे में एलान करना ज़रूरी है.

• [C-3-2] एसडीके टूल के दस्तावेज़ और android.bluetooth में बताए गए तरीके से, GATT (जेनेरिक एट्रिब्यूट प्रोफ़ाइल) पर आधारित Bluetooth API चालू करना ज़रूरी है.

• [C-3-3] BluetoothAdapter.isOffloadedFilteringSupported() के लिए सही वैल्यू रिपोर्ट करना ज़रूरी है, ताकि यह पता चल सके कि ScanFilter एपीआई क्लास के लिए फ़िल्टर करने का लॉजिक लागू किया गया है या नहीं.

• [C-3-4] BluetoothAdapter.isMultipleAdvertisementSupported() एट्रिब्यूट के लिए सही वैल्यू रिपोर्ट करना ज़रूरी है, ताकि यह पता चल सके कि लो एनर्जी एडवर्टाइज़िंग की सुविधा उपलब्ध है या नहीं.

• [C-3-5] डिवाइस को, हल किए जा सकने वाले निजी पते (आरपीए) के लिए 15 मिनट से ज़्यादा का टाइम आउट लागू नहीं करना चाहिए. साथ ही, टाइम आउट होने पर पते को रोटेट करना चाहिए, ताकि उपयोगकर्ता की निजता की सुरक्षा की जा सके. ऐसा तब करना चाहिए, जब डिवाइस स्कैनिंग या विज्ञापन के लिए BLE का इस्तेमाल कर रहा हो. टाइमिंग अटैक को रोकने के लिए, टाइम आउट इंटरवल को भी 5 से 15 मिनट के बीच में रैंडमाइज़ किया जाना चाहिए.

• ScanFilter API को लागू करते समय, फ़िल्टर करने के लॉजिक को ब्लूटूथ चिपसेट पर ऑफ़लोड करने की सुविधा होनी चाहिए.

• डिवाइस में, ब्लूटूथ चिपसेट पर एक साथ कई डिवाइसों को स्कैन करने की सुविधा होनी चाहिए.

• इसमें कम से कम चार स्लॉट के साथ एक से ज़्यादा विज्ञापन दिखाने की सुविधा होनी चाहिए.

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

• [C-4-1] उपयोगकर्ता को System API BluetoothAdapter.isBleScanAlwaysAvailable() के ज़रिए वैल्यू को पढ़ने की सुविधा चालू/बंद करने का विकल्प देना होगा.

अगर डिवाइस में ब्लूटूथ स्मार्ट और Hearing Aids Profile के साथ काम करने की सुविधा शामिल है, जैसा कि ब्लूटूथ स्मार्ट का इस्तेमाल करके कान की मशीन में ऑडियो सुनने की सुविधा में बताया गया है, तो:

• [C-5-1] BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID) के लिए, true को वापस लाना ज़रूरी है.

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

• [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 Extended advertising की सुविधा काम करनी चाहिए.

• [C-7-4] ज़रूरी है कि CIG में कम से कम दो सीआईएस कनेक्शन हों.

• [C-7-5] BAP यूनिकास्ट क्लाइंट, CSIP सेट कोऑर्डिनेटर, एमसीपी सर्वर, वीसीपी कंट्रोलर, और सीसीपी सर्वर को एक साथ चालू करना ज़रूरी है.

• [C-SR-1] एचएपी यूनिकास्ट क्लाइंट को चालू करने का सुझाव दिया जाता है.

अगर डिवाइस में लागू किए गए सिस्टम, BluetoothAdapter.isLeAudioBroadcastSourceSupported() एपीआई के लिए true दिखाते हैं, तो:

• [C-8-1] ज़रूरी है कि बीआईएस में कम से कम दो लिंक शामिल किए जा सकें.

• [C-8-2] BAP ब्रॉडकास्ट सोर्स और BAP ब्रॉडकास्ट असिस्टेंट, दोनों को एक साथ चालू करना ज़रूरी है.

• [C-8-3] LE Periodic advertising के साथ काम करना ज़रूरी है.

अगर डिवाइस में लागू किए गए सिस्टम, BluetoothAdapter.isLeAudioBroadcastAssistantSupported() एपीआई के लिए true दिखाते हैं, तो:

• [C-9-1] PAST (Periodic Advertising Sync Transfer) के साथ काम करना ज़रूरी है.

• [C-9-2] LE पीरियोडिक विज्ञापन की सुविधा काम करनी चाहिए.

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

• [C-10-1] रेफ़रंस डिवाइस से एक मीटर की दूरी पर, 95% मेज़रमेंट के लिए आरएसएसआई मेज़रमेंट, +/-9 डीबी के बीच होना चाहिए. रेफ़रंस डिवाइस, लाइन ऑफ़ साइट एनवायरमेंट में ADVERTISE_TX_POWER_HIGH पर ट्रांसमिट करता है.

• [C-10-2] हर चैनल के डेविएशन को कम करने के लिए, Rx/Tx में सुधार करना ज़रूरी है, ताकि 95% मेज़रमेंट के लिए, तीन में से हर चैनल और हर ऐंटेना (अगर एक से ज़्यादा का इस्तेमाल किया जाता है) पर मेज़रमेंट, एक-दूसरे से +/-3 dB के अंतर में हों.

अगर डिवाइसों में FEATURE_BLUETOOTH_LE_CHANNEL_SOUNDING का एलान किया जाता है, तो:

• [C-11-1] हार्डवेयर फ़ीचर फ़्लैग android.hardware.bluetooth_le.channel_sounding की जानकारी देना ज़रूरी है.

• [C-11-2] 90वें पर्सेंटाइल पर, 1 मीटर की दूरी पर, संचयी बंटन फ़ंक्शन का इस्तेमाल करके, रेंज को +/- 0.5 मीटर के अंतर के साथ सटीक तौर पर रिपोर्ट करना ज़रूरी है.

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

• [C-SR-2] आरएक्स ऑफ़सेट को मेज़र करने और उसकी भरपाई करने का सुझाव दिया जाता है, ताकि यह पक्का किया जा सके कि ADVERTISE_TX_POWER_HIGH पर ट्रांसमिट करने वाले रेफ़रंस डिवाइस से 1 मीटर की दूरी पर, मीडियन बीएलई आरएसएसआई -60 डीबीएम +/-10 डीबी हो. यहां डिवाइसों को इस तरह से रखा जाता है कि वे 'पैरलल प्लेन' पर हों और उनकी स्क्रीन एक ही दिशा में हों.

• [C-SR-3] टीएक्स ऑफ़सेट को मेज़र करने और उसकी भरपाई करने के लिए, इन शर्तों को पूरा करना ज़रूरी है. इससे यह पक्का किया जा सकेगा कि जब किसी रेफ़रंस डिवाइस से स्कैन किया जा रहा हो, तब बीएलई आरएसएसआई का मीडियन -60 dBm +/-10 dB हो. रेफ़रंस डिवाइस को 1 मीटर की दूरी पर रखा गया हो और वह ADVERTISE_TX_POWER_HIGH पर ट्रांसमिट कर रहा हो. साथ ही, डिवाइसों को इस तरह से रखा गया हो कि वे 'पैरलल प्लेन' पर हों और उनकी स्क्रीन एक ही दिशा में हों.

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

7.4.4. नियर-फ़ील्ड कम्यूनिकेशन

डिवाइस में सेट किए गए सिस्टम के लिए:

• इसमें नियर-फ़ील्ड कम्यूनिकेशन (एनएफ़सी) के लिए, ट्रांसीवर और उससे जुड़ा हार्डवेयर शामिल होना चाहिए.

• [C-0-1] android.nfc.NdefMessage और android.nfc.NdefRecord एपीआई को लागू करना ज़रूरी है. भले ही, इनमें एनएफ़सी के लिए सहायता शामिल न हो या android.hardware.nfc सुविधा को क्लास के तौर पर एलान न किया गया हो. ऐसा इसलिए, क्योंकि क्लास, प्रोटोकॉल से अलग डेटा प्रज़ेंटेशन फ़ॉर्मैट को दिखाती हैं.

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

• [C-1-1] android.content.pm.PackageManager.hasSystemFeature() तरीके से, android.hardware.nfc सुविधा के बारे में जानकारी देना ज़रूरी है.

• इन NFC स्टैंडर्ड के ज़रिए, NDEF मैसेज पढ़ने और लिखने की सुविधा होनी चाहिए:

• [C-1-2] इसमें एनएफ़सी फ़ोरम रीडर/राइटर के तौर पर काम करने की सुविधा होनी चाहिए. इसके लिए, एनएफ़सी फ़ोरम की तकनीकी जानकारी (NFCForum-TS-DigitalProtocol-1.0) में बताए गए इन एनएफ़सी स्टैंडर्ड का इस्तेमाल किया जाना चाहिए:

  • NfCA (ISO14443-3A)
  • NfcB (ISO14443-3B)
  • NfcF (JIS X 6319-4)
  • IsoDep (ISO 14443-4)
  • NFC फ़ोरम के टैग टाइप 2, 3, 4, 5 (NFC फ़ोरम के हिसाब से तय किए गए)

• [C-SR-1] यह सुझाव दिया जाता है कि डिवाइस में, एनएफ़सी के इन स्टैंडर्ड के ज़रिए एनडीईएफ़ मैसेज और रॉ डेटा को पढ़ने और लिखने की सुविधा होनी चाहिए. ध्यान दें कि एनएफ़सी के मानकों को STRONGLY RECOMMENDED के तौर पर बताया गया है. हालांकि, आने वाले समय में, Compatibility Definition में इन मानकों को MUST के तौर पर बदलने का प्लान है. इस वर्शन में इन मानकों का पालन करना ज़रूरी नहीं है. हालांकि, आने वाले वर्शन में इनका पालन करना ज़रूरी होगा. Android के इस वर्शन का इस्तेमाल करने वाले मौजूदा और नए डिवाइसों को, इन ज़रूरी शर्तों को अभी पूरा करने का सुझाव दिया जाता है. इससे वे आने वाले समय में, प्लैटफ़ॉर्म के नए वर्शन पर अपग्रेड कर पाएंगे.

• [C-1-13] NFC डिस्कवरी मोड में होने पर, डिवाइस को उन सभी टेक्नोलॉजी के लिए पोल करना होगा जिनके साथ वह काम करता है.

• डिवाइस के चालू होने पर, एनएफ़सी को डिस्कवरी मोड में होना चाहिए. साथ ही, स्क्रीन चालू होनी चाहिए और लॉक-स्क्रीन अनलॉक होनी चाहिए.

• Thinfilm NFC Barcode प्रॉडक्ट के बारकोड और यूआरएल (अगर कोड में बदला गया है) को पढ़ने में सक्षम होना चाहिए.

ध्यान दें कि ऊपर बताए गए JIS, ISO, और NFC फ़ोरम के स्पेसिफ़िकेशन के लिए, सार्वजनिक तौर पर उपलब्ध लिंक मौजूद नहीं हैं.

Android में, एनएफ़सी होस्ट कार्ड एम्युलेशन (एचसीई) मोड की सुविधा काम करती है.

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

• [C-2-1] android.hardware.nfc.hce सुविधा के बारे में जानकारी देना ज़रूरी है.

• [C-2-2] Android SDK में बताए गए NFC HCE API के साथ काम करना ज़रूरी है.

अगर डिवाइस में NFC कंट्रोलर चिपसेट शामिल है, जो NfcF के लिए HCE की सुविधा देता है और तीसरे पक्ष के ऐप्लिकेशन के लिए इस सुविधा को लागू करता है, तो:

• [C-3-1] android.hardware.nfc.hcef सुविधा के बारे में लगातार जानकारी देना ज़रूरी है.

• [C-3-2] Android SDK में बताए गए NfcF Card Emulation APIs को लागू करना ज़रूरी है.

अगर डिवाइसों में, इस सेक्शन में बताई गई सामान्य एनएफ़सी की सुविधा शामिल है और वे रीडर/राइटर के तौर पर MIFARE टेक्नोलॉजी (MIFARE Classic, MIFARE Ultralight, MIFARE Classic पर NDEF) के साथ काम करते हैं, तो:

• [C-4-1] Android SDK के दस्तावेज़ में बताए गए Android API को लागू करना ज़रूरी है.

• [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 Kbit/सेकंड या इससे ज़्यादा की स्पीड से डेटा ट्रांसफ़र कर सके. इस ज़रूरी शर्त को पूरा करने वाली टेक्नोलॉजी के उदाहरणों में, EDGE, HSPA, EV-DO, 802.11g, Ethernet, और Bluetooth PAN शामिल हैं.

• जब फ़िज़िकल नेटवर्किंग स्टैंडर्ड (जैसे, ईथरनेट) प्राइमरी डेटा कनेक्शन हो, तब कम से कम एक सामान्य वायरलेस डेटा स्टैंडर्ड (जैसे, 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] MUST provide third-party applications with direct IPv6 connectivity to the network when connected to an IPv6 network, without any form of address or port translation happening locally on the device. मैनेज किए गए एपीआई, जैसे कि Socket#getLocalAddress या Socket#getLocalPort और NDK एपीआई, जैसे कि getsockname() या IPV6_PKTINFO, दोनों को आईपी पता और पोर्ट वापस भेजना होगा. इस आईपी पते और पोर्ट का इस्तेमाल, नेटवर्क पर पैकेट भेजने और पाने के लिए किया जाता है. साथ ही, यह इंटरनेट (वेब) सर्वर को सोर्स आईपी और पोर्ट के तौर पर दिखता है.

IPv6 के लिए ज़रूरी सहायता का लेवल, नेटवर्क टाइप पर निर्भर करता है. इसके बारे में यहां बताया गया है.

अगर डिवाइस में वाई-फ़ाई की सुविधा काम करती है, तो:

• [C-1-1] यह ज़रूरी है कि वाई-फ़ाई पर ड्यूअल-स्टैक और सिर्फ़ IPv6 का इस्तेमाल किया जा सके.

अगर डिवाइस में ईथरनेट का इस्तेमाल किया जा सकता है, तो:

• [C-2-1] डिवाइस में, ईथरनेट पर ड्यूअल-स्टैक और सिर्फ़ IPv6 का इस्तेमाल करने की सुविधा होनी चाहिए.

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

• [C-3-1] डिवाइस में, सेल्युलर नेटवर्क पर IPv6 का इस्तेमाल किया जा सकता हो. इसमें IPv6-only और डुअल-स्टैक, दोनों शामिल हैं.

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

• [C-4-1] जब डिवाइस एक साथ एक से ज़्यादा नेटवर्क टाइप से कनेक्ट हो, तो उसे हर नेटवर्क पर ऊपर दी गई ज़रूरी शर्तों को एक साथ पूरा करना होगा.

7.4.5.3. कैप्टिव पोर्टल

कैप्टिव पोर्टल, ऐसे नेटवर्क को कहते हैं जिसमें इंटरनेट ऐक्सेस करने के लिए साइन इन करना ज़रूरी होता है.

अगर डिवाइस में सेट किए गए सिस्टम में android.webkit.Webview API को पूरी तरह से लागू किया गया है, तो:

• [C-1-1] इसे एक कैप्टिव पोर्टल ऐप्लिकेशन उपलब्ध कराना होगा, ताकि ACTION_CAPTIVE_PORTAL_SIGN_IN इंटेंट को हैंडल किया जा सके. साथ ही, System API 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 नेटवर्किंग एपीआई (जैसे, java.net.Socket) और नेटिव एपीआई (जैसे, connect()) के लिए डिफ़ॉल्ट रूप से इस्तेमाल किया जाने वाला नेटवर्क होना चाहिए.

7.4.6. सिंक करने की सुविधा की सेटिंग

डिवाइस में सेट किए गए सिस्टम के लिए:

• [C-0-1] मास्टर अपने-आप सिंक होने की सेटिंग डिफ़ॉल्ट रूप से चालू होनी चाहिए, ताकि getMasterSyncAutomatically() तरीका "true" वैल्यू दिखाए.

7.4.7. डेटा बचाने की सेटिंग

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

• [C-SR-1] डेटा बचाने की सेटिंग वाला मोड उपलब्ध कराने का सुझाव दिया जाता है.

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

• [C-1-1] एसडीके के दस्तावेज़ में बताए गए तरीके के मुताबिक, ConnectivityManager क्लास में मौजूद सभी एपीआई के साथ काम करना ज़रूरी है

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

• [C-2-1] ConnectivityManager.getRestrictBackgroundStatus() के लिए, RESTRICT_BACKGROUND_STATUS_DISABLED वैल्यू रिटर्न होनी चाहिए

• [C-2-2] ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED को ब्रॉडकास्ट नहीं करना चाहिए.

7.4.8. सुरक्षा चिप

अगर डिवाइसों में Open Mobile API-capable सुरक्षित एलिमेंट इस्तेमाल किए जाते हैं और उन्हें तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराया जाता है, तो:

• [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 के साथ काम करने वाले सभी ज़रूरी यूडब्ल्यूबी प्रोफ़ाइलों के साथ काम करना ज़रूरी है.

• [C-1-4] डिवाइस में, उपयोगकर्ता को यूडब्ल्यूबी रेडियो को चालू/बंद करने का विकल्प देना ज़रूरी है.

• [C-1-5] यह ज़रूरी है कि UWB रेडियो का इस्तेमाल करने वाले ऐप्लिकेशन के पास, UWB_RANGING अनुमति हो. यह अनुमति, NEARBY_DEVICES अनुमतियों के समूह के तहत आती है.

• [C-SR-1] हमारा सुझाव है कि ये स्टैंडर्ड संगठनों के तय किए गए, ज़रूरी शर्तों के मुताबिक काम करने और सर्टिफ़िकेशन से जुड़े टेस्ट पास करें. इनमें FIRA, CCC, और CSA शामिल हैं.

• [C-1-6] यह पक्का करना ज़रूरी है कि नॉन-रिफ़्लेक्टिव चेंबर में, 1 मीटर की दूरी पर लाइन ऑफ़ साइट एनवायरमेंट में, 95% मेज़रमेंट के लिए दूरी के मेज़रमेंट, +/-15 सेमी के अंदर हों.

• [C-1-7] यह पक्का करना ज़रूरी है कि रेफ़रंस डिवाइस से 1 मीटर की दूरी पर, दूरी के मेज़रमेंट का मीडियन [0.75 मीटर, 1.25 मीटर] के बीच हो. इसमें, असल दूरी को DUT के ऊपरी किनारे से मापा जाता है.

• [C-SR-2] उपयोगकर्ता की मौजूदगी का पता लगाने की सुविधा के लिए कैलिब्रेशन से जुड़ी ज़रूरी शर्तें में दिए गए मेज़रमेंट सेटअप के चरणों का पालन करने का सुझाव दिया जाता है.

7.5. कैमरे

अगर डिवाइसों में कम से कम एक कैमरा शामिल है, तो:

• [C-1-1] android.hardware.camera.any फ़ीचर फ़्लैग के बारे में एलान करना ज़रूरी है.

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

• [C-1-3] यह पक्का करना ज़रूरी है कि पहले से इंस्टॉल किया गया डिफ़ॉल्ट कैमरा ऐप्लिकेशन, इमेज के मेटाडेटा से उपयोगकर्ता की जगह की जानकारी हटा दे. ऐसा तब किया जाता है, जब ऐप्लिकेशन को MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE या MediaStore.ACTION_VIDEO_CAPTURE इंटेंट हैंडल करने के लिए, इमेज को दूसरे ऐप्लिकेशन को भेजना होता है और उस ऐप्लिकेशन के पास ACCESS_FINE_LOCATION नहीं होता है.

अगर डिवाइस में कम से कम एक कैमरा मौजूद है और पहले से इंस्टॉल किया गया कैमरा ऐप्लिकेशन, इंटेंट MediaStore.ACTION_MOTION_PHOTO_CAPTURE या MediaStore.ACTION_MOTION_PHOTO_CAPTURE_SECURE को हैंडल करता है, तो:

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

• [C-1-5] को यह पक्का करना होगा कि वापस की गई मोशन फ़ोटो, मोशन फ़ोटो फ़ॉर्मैट 1.0 के स्पेसिफ़िकेशन का इस्तेमाल करती हो.

अगर डिवाइस में एचडीआर 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-2-1] कैमरा प्रीव्यू की सुविधा चालू होने पर, फ़्लैश लैंप चालू नहीं होना चाहिए. हालांकि, अगर ऐप्लिकेशन ने Camera.Parameters ऑब्जेक्ट के FLASH_MODE_AUTO या FLASH_MODE_ON एट्रिब्यूट चालू करके, फ़्लैश को चालू करने की अनुमति दी है, तो फ़्लैश लैंप चालू हो सकता है.android.hardware.Camera.PreviewCallback ध्यान दें कि यह पाबंदी, डिवाइस में पहले से मौजूद सिस्टम कैमरा ऐप्लिकेशन पर लागू नहीं होती. यह सिर्फ़ Camera.PreviewCallback का इस्तेमाल करने वाले तीसरे पक्ष के ऐप्लिकेशन पर लागू होती है.

7.5.2. सामने वाला कैमरा

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

डिवाइस में सेट किए गए सिस्टम के लिए:

• इसमें सामने की ओर कैमरा हो सकता है.

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

• [C-1-1] android.hardware.camera.any और android.hardware.camera.front फ़ीचर फ़्लैग की जानकारी देना ज़रूरी है.

• [C-1-2] का रिज़ॉल्यूशन कम से कम वीजीए (640x480 पिक्सल) होना चाहिए.

• [C-1-3] Camera API के लिए, सामने वाले कैमरे को डिफ़ॉल्ट कैमरे के तौर पर इस्तेमाल नहीं किया जाना चाहिए. साथ ही, 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] डिवाइस में एक साथ अनकोड की गई / MJPEG स्ट्रीम (QVGA या इससे ज़्यादा रिज़ॉल्यूशन) ऐक्सेस की जा सकती हो.

7.5.4. कैमरा API का व्यवहार

Android में कैमरे को ऐक्सेस करने के लिए, दो एपीआई पैकेज शामिल हैं. नया android.hardware.camera2 API, ऐप्लिकेशन को कैमरे का लोअर-लेवल कंट्रोल देता है. इसमें ज़ीरो-कॉपी बर्स्ट/स्ट्रीमिंग फ़्लो और एक्सपोज़र, गेन, व्हाइट बैलेंस गेन, कलर कन्वर्ज़न, नॉइज़ कम करना, शार्पनिंग वगैरह के फ़्रेम-दर-फ़्रेम कंट्रोल शामिल हैं.

Android 5.0 में, पुराने एपीआई पैकेज android.hardware.Camera को 'अब काम नहीं करता' के तौर पर मार्क किया गया है. हालांकि, यह अब भी ऐप्लिकेशन के लिए उपलब्ध होना चाहिए. Android डिवाइसों पर, इस सेक्शन और Android SDK में बताए गए तरीके से, एपीआई का इस्तेमाल जारी रहना चाहिए.

बंद किए गए android.hardware.Camera क्लास और नए android.hardware.camera2 पैकेज में मौजूद सभी सुविधाओं की परफ़ॉर्मेंस और क्वालिटी, दोनों एपीआई में एक जैसी होनी चाहिए. उदाहरण के लिए, एक जैसी सेटिंग के साथ ऑटोफ़ोकस की स्पीड और सटीक होने की क्षमता एक जैसी होनी चाहिए. साथ ही, कैप्चर की गई इमेज की क्वालिटी भी एक जैसी होनी चाहिए. जिन सुविधाओं के लिए, दोनों एपीआई के अलग-अलग सिमैंटिक की ज़रूरत होती है उनके लिए, स्पीड या क्वालिटी का एक जैसा होना ज़रूरी नहीं है. हालांकि, यह ज़रूरी है कि वे ज़्यादा से ज़्यादा एक जैसी हों.

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

• [C-0-1] जब किसी ऐप्लिकेशन ने कभी android.hardware.Camera.Parameters.setPreviewFormat(int) को कॉल नहीं किया हो, तब ऐप्लिकेशन कॉलबैक को दिए गए झलक डेटा के लिए, android.hardware.PixelFormat.YCbCr_420_SP का इस्तेमाल करना ज़रूरी है.

• [C-0-2] जब कोई ऐप्लिकेशन android.hardware.Camera.PreviewCallback इंस्टेंस रजिस्टर करता है और सिस्टम onPreviewFrame() तरीके को कॉल करता है और प्रीव्यू फ़ॉर्मैट YCbCr_420_SP होता है, तो onPreviewFrame() में पास किया गया byte[] में मौजूद डेटा, NV21 एन्कोडिंग फ़ॉर्मैट में होना चाहिए. इसका मतलब है कि 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] कैमरे को इस तरह से ओरिएंट किया जाना चाहिए कि कैमरे का लंबा डाइमेंशन, स्क्रीन के लंबे डाइमेंशन के साथ अलाइन हो. इसका मतलब है कि जब डिवाइस को लैंडस्केप ओरिएंटेशन में रखा जाता है, तो कैमरों को लैंडस्केप ओरिएंटेशन में इमेज कैप्चर करनी चाहिए. यह डिवाइस के स्क्रीन की दिशा पर निर्भर नहीं करता. इसका मतलब है कि यह लैंडस्केप-प्राइमरी डिवाइसों के साथ-साथ पोर्ट्रेट-प्राइमरी डिवाइसों पर भी लागू होता है.

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

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

  • ऐसे डिवाइस जिनमें स्क्रीन को घुमाने की सुविधा नहीं होती. जैसे, Automotive डिवाइस.

7.6. डिवाइस की मेमोरी और स्टोरेज

7.6.1. कम से कम मेमोरी और स्टोरेज

डिवाइस में सेट किए गए सिस्टम के लिए:

• [C-0-1] इसमें डाउनलोड मैनेजर शामिल होना चाहिए. ऐप्लिकेशन इसका इस्तेमाल, डेटा फ़ाइलें डाउनलोड करने के लिए कर सकते हैं. साथ ही, इसमें कम से कम 100 एमबी साइज़ की अलग-अलग फ़ाइलें, डिफ़ॉल्ट "कैश" लोकेशन पर डाउनलोड करने की सुविधा होनी चाहिए.

7.6.2. ऐप्लिकेशन के लिए शेयर किया गया स्टोरेज

डिवाइस में सेट किए गए सिस्टम के लिए:

• [C-0-1] ऐप्लिकेशन को शेयर किया जाने वाला स्टोरेज उपलब्ध कराना ज़रूरी है. इसे अक्सर "शेयर किया गया बाहरी स्टोरेज", "ऐप्लिकेशन के साथ शेयर किया गया स्टोरेज" या Linux पाथ "/sdcard" के तौर पर भी जाना जाता है.
• [C-0-2] इसे डिफ़ॉल्ट रूप से माउंट किए गए शेयर किए गए स्टोरेज के साथ कॉन्फ़िगर किया जाना चाहिए.दूसरे शब्दों में, "आउट ऑफ़ द बॉक्स" होना चाहिए. भले ही, स्टोरेज को डिवाइस के स्टोरेज कॉम्पोनेंट या हटाने लायक स्टोरेज मीडियम (जैसे, सिक्योर डिजिटल कार्ड स्लॉट) पर लागू किया गया हो.
• [C-0-3] ऐप्लिकेशन को शेयर किए गए स्टोरेज को सीधे तौर पर Linux पाथ sdcard पर माउंट करना होगा या sdcard से लेकर माउंट पॉइंट तक Linux सिंबॉलिक लिंक शामिल करना होगा.
• [C-0-4] एपीआई लेवल 29 या इसके बाद के वर्शन को टारगेट करने वाले सभी ऐप्लिकेशन के लिए, डिफ़ॉल्ट रूप से स्कोप किए गए स्टोरेज को चालू करना ज़रूरी है. हालांकि, इन स्थितियों में ऐसा नहीं करना होगा:
  • जब ऐप्लिकेशन ने अपने मेनिफ़ेस्ट में android:requestLegacyExternalStorage="true" का अनुरोध किया हो.
• [C-0-5] MediaStore के ज़रिए ऐक्सेस की गई मीडिया फ़ाइलों में सेव की गई जगह की जानकारी का मेटाडेटा को छिपाना ज़रूरी है. जैसे, जीपीएस Exif टैग. हालांकि, ऐसा तब नहीं किया जाना चाहिए, जब कॉलिंग ऐप्लिकेशन के पास ACCESS_MEDIA_LOCATION की अनुमति हो.

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

• उपयोगकर्ता के लिए उपलब्ध रिमूवेबल स्टोरेज, जैसे कि सिक्योर डिजिटल (एसडी) कार्ड स्लॉट.
• Android ओपन सोर्स प्रोजेक्ट (AOSP) में लागू की गई इंटरनल (हटाए नहीं जा सकने वाली) स्टोरेज का एक हिस्सा.

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

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

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

• संगठन में काम करने वालों के साथ शेयर किए गए ऐप्लिकेशन के लिए, इंटरनल ऐप्लिकेशन शेयर किए गए स्टोरेज के AOSP वर्शन का इस्तेमाल करना चाहिए.
• स्टोरेज स्पेस को ऐप्लिकेशन के निजी डेटा के साथ शेयर कर सकता है.

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

• [C-3-1] होस्ट कंप्यूटर से, ऐप्लिकेशन के शेयर किए गए स्टोरेज में मौजूद डेटा को ऐक्सेस करने का तरीका उपलब्ध कराना ज़रूरी है.
• Android की मीडिया स्कैनर सेवा और android.provider.MediaStore के ज़रिए, दोनों स्टोरेज पाथ से कॉन्टेंट को पारदर्शी तरीके से दिखाना चाहिए.
• यूएसबी मास स्टोरेज का इस्तेमाल किया जा सकता है. हालांकि, इस ज़रूरी शर्त को पूरा करने के लिए, मीडिया ट्रांसफ़र प्रोटोकॉल का इस्तेमाल करना चाहिए.

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

• यह रेफ़रंस Android MTP होस्ट, Android File Transfer के साथ काम करना चाहिए.
• इसे यूएसबी डिवाइस क्लास 0x00 की रिपोर्ट देनी चाहिए.
• 'एमटीपी' के यूएसबी इंटरफ़ेस का नाम रिपोर्ट करना चाहिए.

7.6.3. एडॉप्टेबल स्टोरेज

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

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

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

• [C-SR-2] एडॉप्टेबल स्टोरेज को लागू करने का सुझाव दिया जाता है.

7.7. यूएसबी

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

• उसमें यूएसबी डिवाइस मोड की सुविधा होनी चाहिए.

• डिवाइस में यूएसबी होस्ट मोड की सुविधा होनी चाहिए.

• यूएसबी से डेटा सिग्नल भेजने की प्रोसेस को बंद करने की सुविधा होनी चाहिए.

7.7.1. यूएसबी डिवाइस मोड

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

• [C-2-1] यह ज़रूरी है कि हार्डवेयर की android.hardware.usb.accessory सुविधा के साथ काम करने का एलान किया गया हो.
• [C-2-2] यूएसबी मास स्टोरेज क्लास में, यूएसबी मास स्टोरेज के इंटरफ़ेस के ब्यौरे iInterface स्ट्रिंग के आखिर में "android" स्ट्रिंग शामिल होनी चाहिए

7.7.2. यूएसबी होस्ट मोड

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

• [C-1-1] यह ज़रूरी है कि डिवाइस, Android SDK में दिए गए Android USB होस्ट एपीआई को लागू करे. साथ ही, यह भी ज़रूरी है कि वह हार्डवेयर की सुविधा android.hardware.usb.host के साथ काम करने की जानकारी दे.
• [C-1-2] स्टैंडर्ड यूएसबी सहायक डिवाइसों को कनेक्ट करने की सुविधा उपलब्ध कराना ज़रूरी है. इनमें से कोई एक होना ज़रूरी है:
  • डिवाइस में यूएसबी टाइप-सी पोर्ट होना चाहिए. इसके अलावा, डिवाइस के साथ ऐसी केबल होनी चाहिए जो डिवाइस के मालिकाना हक वाले पोर्ट को स्टैंडर्ड यूएसबी टाइप-सी पोर्ट (यूएसबी टाइप-सी डिवाइस) में बदल सके.
  • उपयोगकर्ता के डिवाइस पर यूएसबी टाइप-ए पोर्ट होना चाहिए या डिवाइस के साथ ऐसी केबल होनी चाहिए जो उपयोगकर्ता के डिवाइस पर मालिकाना हक वाले पोर्ट को स्टैंडर्ड यूएसबी टाइप-ए पोर्ट में बदलती हो.
  • डिवाइस में मौजूद माइक्रो-एबी यूएसबी पोर्ट. इसके साथ एक ऐसी केबल होनी चाहिए जो स्टैंडर्ड यूएसबी टाइप-ए पोर्ट के साथ काम करती हो.
• [C-1-3] इसे यूएसबी टाइप-ए या माइक्रो-एबी पोर्ट को यूएसबी टाइप-सी पोर्ट (रिसेप्टेकल) में बदलने वाले अडैप्टर के साथ शिप नहीं किया जाना चाहिए.
• [C-SR-1] Android SDK के दस्तावेज़ में बताए गए तरीके से, यूएसबी ऑडियो क्लास को लागू करने का सुझाव दिया जाता है.
• होस्ट मोड में कनेक्ट किए गए यूएसबी पेरिफ़ेरल डिवाइस को चार्ज करने की सुविधा होनी चाहिए. साथ ही, यूएसबी टाइप-सी कनेक्टर के लिए, यूएसबी टाइप-सी केबल और कनेक्टर स्पेसिफ़िकेशन, वर्शन 1.2 के टर्मिनेशन पैरामीटर सेक्शन में बताए गए तरीके के मुताबिक, कम से कम 1.5 ऐंपियर के सोर्स करंट का विज्ञापन करना चाहिए. इसके अलावा, माइक्रो-एबी कनेक्टर के लिए, यूएसबी बैटरी चार्जिंग स्पेसिफ़िकेशन, वर्शन 1.2 में बताए गए तरीके के मुताबिक, चार्जिंग डाउनस्ट्रीम पोर्ट (सीडीपी) के आउटपुट करंट रेंज का इस्तेमाल करना चाहिए.
• इसमें यूएसबी टाइप-सी स्टैंडर्ड लागू होने चाहिए और यह उनके साथ काम करना चाहिए.

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

• [C-2-1] यूएसबी एचआईडी क्लास के साथ काम करना ज़रूरी है.
• [C-2-2] यूएसबी एचआईडी यूसेज टेबल और वॉइस कमांड यूसेज रिक्वेस्ट में बताए गए, एचआईडी के इन डेटा फ़ील्ड का पता लगाने और उन्हें KeyEvent कॉन्स्टेंट के साथ मैप करने की सुविधा होनी चाहिए. ये डेटा फ़ील्ड यहां दिए गए हैं:
  • Usage Page (0xC) Usage ID (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
  • Usage Page (0xC) Usage ID (0x0E9): KEYCODE_VOLUME_UP
  • Usage Page (0xC) Usage ID (0x0EA): KEYCODE_VOLUME_DOWN
  • इस्तेमाल से जुड़ा पेज (0xC) इस्तेमाल का आईडी (0x0CF): KEYCODE_VOICE_ASSIST

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

• [C-3-1] यह ज़रूरी है कि डिवाइस, रिमोट से कनेक्ट किए गए किसी भी एमटीपी (मीडिया ट्रांसफर प्रोटोकॉल) डिवाइस को पहचान सके. साथ ही, ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, और ACTION_CREATE_DOCUMENT इंटेंट के ज़रिए, डिवाइस के कॉन्टेंट को ऐक्सेस किया जा सके.

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

• [C-4-1] यूएसबी टाइप-सी के स्पेसिफ़िकेशन (सेक्शन 4.5.1.3.3) में बताई गई ड्यूअल रोल पावर (डीआरपी) की सुविधा लागू करना ज़रूरी है. डीआरपी पोर्ट वाले डिवाइसों पर, यूएसबी पावर सिंक का पता लगाने की सुविधा (होस्ट मोड) डिफ़ॉल्ट रूप से बंद हो सकती है. हालांकि, उपयोगकर्ता के लिए इसे चालू करना ज़रूरी है. इन डिवाइसों में 3.5 मि॰मी॰ का ऑडियो जैक शामिल होता है.
• [C-SR-2] DisplayPort का इस्तेमाल करने का सुझाव दिया जाता है.
  • यूएसबी सुपरस्पीड डेटा रेट के साथ काम करना चाहिए.
  • डेटा और पावर रोल स्वैपिंग के लिए, पावर डिलीवरी की सुविधा का इस्तेमाल करने के लिए, इन केबल का इस्तेमाल करने का सुझाव दिया जाता है.
• [C-SR-3] यह सुझाव दिया जाता है कि यूएसबी टाइप-सी केबल और कनेक्टर स्पेसिफ़िकेशन के वर्शन 1.2 के अपेंडिक्स A में बताए गए तरीके के मुताबिक, ऑडियो अडैप्टर ऐक्सेसरी मोड काम न करे.
• डिवाइस के फ़ॉर्म फ़ैक्टर के लिए सबसे सही Try.* मॉडल लागू करना चाहिए. उदाहरण के लिए, हैंडहेल्ड डिवाइस में Try.SNK मॉडल लागू होना चाहिए.

7.7.3. यूएसबी पावर डिलीवरी

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. ऑडियो आउटपुट

अगर डिवाइसों में स्पीकर या ऑडियो/मल्टीमीडिया आउटपुट पोर्ट शामिल हैं, ताकि ऑडियो आउटपुट पेरिफ़ेरल का इस्तेमाल किया जा सके. जैसे, चार कंडक्टर वाला 3.5 मि॰मी॰ ऑडियो जैक या यूएसबी ऑडियो क्लास का इस्तेमाल करने वाला यूएसबी होस्ट मोड पोर्ट, तो:

• [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] में कम से कम एक ऑडियो पोर्ट को 4 कंडक्टर 3.5 मि॰मी॰ ऑडियो जैक के तौर पर शामिल करने का सुझाव दिया जाता है.

अगर डिवाइसों में चार कंडक्टर वाला 3.5 मि॰मी॰ का ऑडियो जैक है, तो:

• [C-1-1] ज़रूरी है कि यह स्टीरियो हेडफ़ोन और माइक्रोफ़ोन वाले स्टीरियो हेडसेट पर ऑडियो चलाने की सुविधा के साथ काम करता हो.
• [C-1-2] ज़रूरी है कि डिवाइस, CTIA पिन-आउट ऑर्डर वाले टीआरआरएस ऑडियो प्लग के साथ काम करता हो.
• [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] ओएमटीपी पिन-आउट ऑर्डर के साथ ऑडियो प्लग इस्तेमाल करने का सुझाव दिया जाता है.
• [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 किलोहर्ट्ज़ से 20 किलोहर्ट्ज़ बैंड में माइक्रोफ़ोन की औसत पावर रिस्पॉन्स, 2 किलोहर्ट्ज़ पर रिस्पॉन्स से 15 dB से ज़्यादा कम नहीं होना चाहिए.
• [C-1-2] 18.5 किलोहर्ट्ज़ से 20 किलोहर्ट्ज़ की फ़्रीक्वेंसी वाले माइक्रोफ़ोन के लिए, 19 किलोहर्ट्ज़ टोन पर -26 dBFS के लिए, अनवेटेड सिग्नल-टू-नॉइज़ रेशियो 50 dB से कम नहीं होना चाहिए.

अगर PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND की वैल्यू "true" है, तो:

• [C-2-1] स्पीकर का 18.5 किलोहर्ट्ज़ से 20 किलोहर्ट्ज़ के बीच का औसत रिस्पॉन्स, 2 किलोहर्ट्ज़ के रिस्पॉन्स से 40 डेसिबल से कम नहीं होना चाहिए.

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	SNR
पहले से मौजूद मुख्य स्पीकर, जिसे बाहरी रेफ़रंस माइक्रोफ़ोन का इस्तेमाल करके मेज़र किया जाता है	< 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 को लागू करना ज़रूरी है. साथ ही, उपलब्ध EGL एक्सटेंशन की सूची में एक्सटेंशन दिखाना ज़रूरी है.
• [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 कम से कम 2 हो.
• [C-1-7] जीपीयू और डिसप्ले को शेयर किए गए फ़्रंट बफ़र को इस तरह से सिंक करना होगा कि दो रेंडर कॉन्टेक्स्ट के साथ 60 फ़्रेम प्रति सेकंड (एफ़पीएस) पर वीआर कॉन्टेंट की बारी-बारी से रेंडरिंग की जा सके. साथ ही, डिसप्ले पर कोई भी टीयरिंग आर्टफ़ैक्ट न दिखे.
• [C-1-9] NDK में बताए गए तरीके के मुताबिक, AHardwareBuffer फ़्लैग AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA और AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT के लिए सहायता लागू करना ज़रूरी है.
• [C-1-10] कम से कम इन फ़ॉर्मैट के लिए, इस्तेमाल के फ़्लैग AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT के किसी भी कॉम्बिनेशन के साथ AHardwareBuffer के लिए सहायता लागू करना ज़रूरी है: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
• [C-SR-5] यह सुझाव दिया जाता है कि AHardwareBuffers को एक से ज़्यादा लेयर और C-1-10 में बताए गए फ़्लैग और फ़ॉर्मैट के साथ असाइन किया जाए.
• [C-1-11] कम से कम 3840 x 2160 पिक्सल के रिज़ॉल्यूशन और 30 एफ़पीएस पर H.264 डिकोडिंग की सुविधा होनी चाहिए. साथ ही, इसे औसतन 40 एमबीपीएस पर कंप्रेस किया जाना चाहिए. यह 30 एफ़पीएस पर 1920 x 1080 पिक्सल के रिज़ॉल्यूशन वाले चार इंस्टेंस (10 एमबीपीएस) या 60 एफ़पीएस पर 1920 x 1080 पिक्सल के रिज़ॉल्यूशन वाले दो इंस्टेंस (20 एमबीपीएस) के बराबर है.
• [C-1-12] इसमें HEVC और VP9 को सपोर्ट करने की सुविधा होनी चाहिए. साथ ही, यह 30 एफ़पीएस पर कम से कम 1920 x 1080 पिक्सल वाले वीडियो को डिकोड कर सके. इस वीडियो को औसतन 10 एमबीपीएस पर कंप्रेस किया गया हो. इसके अलावा, यह 30 एफ़पीएस पर 3840 x 2160 पिक्सल वाले वीडियो को डिकोड कर सके. इस वीडियो को 20 एमबीपीएस पर कंप्रेस किया गया हो. यह 30 एफ़पीएस पर 1920 x 1080 पिक्सल वाले चार वीडियो को डिकोड करने के बराबर है. इन वीडियो को 5 एमबीपीएस पर कंप्रेस किया गया हो.
• [C-1-13] इसमें HardwarePropertiesManager.getDeviceTemperatures API काम करना चाहिए और त्वचा के तापमान की सटीक वैल्यू दिखनी चाहिए.
• [C-1-14] में एक एम्बेड की गई स्क्रीन होनी चाहिए. साथ ही, इसका रिज़ॉल्यूशन कम से कम 1920 x 1080 होना चाहिए.
• [C-SR-6] इनका डिसप्ले रिज़ॉल्यूशन कम से कम 2560 x 1440 होना चाहिए.
• [C-1-15] वीआर मोड में, डिसप्ले कम से कम 60 हर्ट्ज़ पर अपडेट होना चाहिए.
• [C-1-17] डिसप्ले में, कम समय तक इमेज दिखने वाला मोड काम करना चाहिए. इसमें इमेज, ज़्यादा से ज़्यादा पांच मिलीसेकंड तक दिखनी चाहिए. इमेज दिखने का समय, पिक्सल के रोशनी छोड़ने के समय के हिसाब से तय होता है.
• [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] MUST have end-to-end motion to photon latency not higher than 28 milliseconds.
• [C-SR-9] यह सुझाव दिया जाता है कि मोशन से फ़ोटॉन तक की एंड-टू-एंड लेटेन्सी 20 मिलीसेकंड से ज़्यादा न हो.
• [C-1-23] पहले फ़्रेम का रेशियो कम से कम 85% होना चाहिए. यह रेशियो, काले से सफ़ेद रंग में ट्रांज़िशन होने के बाद पहले फ़्रेम के पिक्सल की चमक और स्थिर स्थिति में सफ़ेद पिक्सल की चमक के बीच का अनुपात होता है.
• [C-SR-10] यह सुझाव दिया जाता है कि पहले फ़्रेम का अनुपात कम से कम 90% हो.
• यह फ़ोरग्राउंड ऐप्लिकेशन को एक खास कोर उपलब्ध करा सकता है. साथ ही, यह Process.getExclusiveCores एपीआई के साथ काम कर सकता है, ताकि टॉप फ़ोरग्राउंड ऐप्लिकेशन के लिए खास तौर पर उपलब्ध सीपीयू कोर की संख्या दिखाई जा सके.

अगर एक्सक्लूसिव कोर की सुविधा काम करती है, तो कोर:

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

7.10. हैप्टिक

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

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

• [7.10/C] Vibrator.hasVibrator() के लिए, 'गलत' वैल्यू दिखानी चाहिए.

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

• [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.os.VibrationEffect के सुझाए गए कॉन्स्टेंट के साथ-साथ, android.view.HapticFeedbackConstants में सार्वजनिक कॉन्स्टेंट को मैप करने के लिए दिए गए दिशा-निर्देशों का पालन करना चाहिए. साथ ही, उनसे जुड़े ऐम्प्लिट्यूड के संबंधों का भी पालन करना चाहिए.
• इन लिंक किए गए हैप्टिक कॉन्स्टेंट मैपिंग का इस्तेमाल करना चाहिए.
• उसे createOneShot() और createWaveform() एपीआई के लिए, क्वालिटी का आकलन करना चाहिए.
• उन्हें यह पुष्टि करनी चाहिए कि सार्वजनिक android.os.Vibrator.hasAmplitudeControl() एपीआई के नतीजे में, उनके वाइब्रेटर की क्षमताओं के बारे में सही जानकारी दी गई हो.
• उसे android.os.Vibrator.hasAmplitudeControl() चलाकर, ऐम्प्लिट्यूड स्केलेबिलिटी की क्षमताओं की पुष्टि करनी चाहिए.

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

• android.os.Vibrator.areAllEffectsSupported() और android.os.Vibrator.arePrimitivesSupported() एपीआई चलाकर, लागू करने की स्थिति की पुष्टि करनी चाहिए.
• हैप्टिक कॉन्स्टेंट के लिए, क्वालिटी का आकलन करना ज़रूरी है.
• कॉन्स्टेंट के लिए लागू करने के दिशा-निर्देश में बताए गए तरीके के मुताबिक, जिन प्रिमिटिव का इस्तेमाल नहीं किया जा सकता उनके लिए फ़ॉलबैक कॉन्फ़िगरेशन की पुष्टि करें. साथ ही, अगर ज़रूरी हो, तो उसे अपडेट करें.
• उसे फ़ेल होने के जोखिम को कम करने के लिए, फ़ॉलबैक सहायता देनी चाहिए. इसके बारे में यहां बताया गया है.

7.11. मीडिया परफ़ॉर्मेंस क्लास

डिवाइस पर लागू की गई मीडिया परफ़ॉर्मेंस क्लास की जानकारी, android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS एपीआई से मिल सकती है. मीडिया परफ़ॉर्मेंस क्लास की ज़रूरी शर्तें, Android के हर वर्शन के लिए तय की गई हैं. ये शर्तें, R (वर्शन 30) से शुरू होने वाले वर्शन के लिए लागू होती हैं. खास वैल्यू 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. बैटरी सेव करने वाले मोड

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

• [C-1-1] ऐप्लिकेशन स्टैंडबाय और डोज़ मोड में बैटरी बचाने की सुविधा को ट्रिगर करने, चालू रखने, और वेकअप करने के लिए, एओएसपी के लागू किए गए तरीके से अलग एल्गोरिदम का इस्तेमाल नहीं किया जाना चाहिए. साथ ही, ग्लोबल सिस्टम सेटिंग या DeviceConfig का इस्तेमाल किया जाना चाहिए.
• [C-1-2] ऐप्लिकेशन स्टैंडबाय मोड में, हर बकेट में मौजूद ऐप्लिकेशन के लिए, ग्लोबल सेटिंग या DeviceConfig का इस्तेमाल करके, जॉब, अलार्म, और नेटवर्क की थ्रॉटलिंग को मैनेज करने के लिए, AOSP के लागू करने के तरीके से अलग नहीं होना चाहिए.
• [C-1-3] ऐप्लिकेशन स्टैंडबाय के लिए इस्तेमाल किए जाने वाले ऐप्लिकेशन स्टैंडबाय बकेट की संख्या, AOSP के लागू करने के तरीके से अलग नहीं होनी चाहिए.
• [C-1-4] ऐप्लिकेशन स्टैंडबाय बकेट और डोज़ मोड को लागू करना ज़रूरी है. इसके बारे में पावर मैनेजमेंट में बताया गया है.
• [C-1-5] डिवाइस के पावर सेव मोड में होने पर, true को PowerManager.isPowerSaveMode() वापस भेजना ज़रूरी है.
• [C-1-6] ऐप्लिकेशन को, उन सभी ऐप्लिकेशन को दिखाने की सुविधा देनी होगी जिन्हें ऐप्लिकेशन स्टैंडबाय और डोज़ मोड में बैटरी बचाने की सुविधा या बैटरी को ऑप्टिमाइज़ करने की किसी भी सुविधा से छूट मिली है. साथ ही, उसे ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS इंटेंट लागू करना होगा, ताकि उपयोगकर्ता से किसी ऐप्लिकेशन को बैटरी ऑप्टिमाइज़ेशन की सुविधा को अनदेखा करने की अनुमति मांगी जा सके.
• [C-SR-1] यह सुझाव दिया जाता है कि उपयोगकर्ता को बैटरी सेवर मोड चालू और बंद करने की सुविधा दी जाए.
• [C-SR-2] उपयोगकर्ताओं को उन सभी ऐप्लिकेशन को दिखाने की सुविधा देने का सुझाव दिया जाता है जिन्हें ऐप्लिकेशन स्टैंडबाय और बैटरी बचाने वाले डोज़ मोड से छूट मिली है.

अगर डिवाइस में, AOSP में शामिल पावर मैनेजमेंट की सुविधाओं को बढ़ाया जाता है और यह एक्सटेंशन, रेयर ऐप स्टैंडबाय बकेट की तुलना में ज़्यादा सख्त पाबंदियां लागू करता है, तो सेक्शन 3.5.1 देखें.

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

अगर डिवाइस में ACPI के हिसाब से S4 पावर स्टेट लागू की जाती है, तो:

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

अगर डिवाइस में ACPI के हिसाब से S3 पावर स्टेट लागू की जाती है, तो:

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

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

  उदाहरण के लिए, तीसरे पक्ष के ऐप्लिकेशन, FLAG_KEEP_SCREEN_ON के ज़रिए स्क्रीन को चालू रखने या PARTIAL_WAKE_LOCK के ज़रिए सीपीयू को चालू रखने का अनुरोध करते हैं. हालांकि, डिवाइस को S3 स्टेट में तब तक नहीं जाना चाहिए, जब तक उपयोगकर्ता ने C-1-1 में बताए गए तरीके से, डिवाइस को निष्क्रिय स्थिति में रखने के लिए साफ़ तौर पर कोई कार्रवाई न की हो. इसके उलट, जब तीसरे पक्ष के ऐप्लिकेशन, JobScheduler के ज़रिए कोई टास्क ट्रिगर करते हैं या Firebase Cloud Messaging को तीसरे पक्ष के ऐप्लिकेशन पर डिलीवर किया जाता है, तो डिवाइस को S3 मोड से बाहर निकलना होगा. ऐसा तब तक नहीं किया जा सकता, जब तक उपयोगकर्ता ने डिवाइस को निष्क्रिय स्थिति में न रखा हो. ये पूरी तरह से उदाहरण नहीं हैं. AOSP, इस स्थिति से डिवाइस को चालू करने के लिए कई वेक-अप सिग्नल लागू करता है.

8.4. पावर की खपत का हिसाब रखने की सुविधा

बिजली की खपत का ज़्यादा सटीक हिसाब और रिपोर्टिंग से, ऐप्लिकेशन डेवलपर को इंसेंटिव और टूल, दोनों मिलते हैं. इनसे ऐप्लिकेशन में बिजली के इस्तेमाल के पैटर्न को ऑप्टिमाइज़ किया जा सकता है.

डिवाइस में सेट किए गए सिस्टम के लिए:

• [C-SR-1] हर कॉम्पोनेंट के लिए, पावर प्रोफ़ाइल देने का सुझाव दिया जाता है. इससे हर हार्डवेयर कॉम्पोनेंट के लिए, करंट की खपत की वैल्यू का पता चलता है. साथ ही, Android ओपन सोर्स प्रोजेक्ट की साइट पर दिए गए दस्तावेज़ के मुताबिक, समय के साथ कॉम्पोनेंट की वजह से तेज़ी से बैटरी खर्च होने का अनुमान लगाया जा सकता है.
• [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() एपीआई तरीके का इस्तेमाल करके, यह सटीक जानकारी देना ज़रूरी है कि डिवाइस में परफ़ॉर्मेंस मोड की सुविधा काम करती है या नहीं.

• इसमें लगातार परफ़ॉर्मेंस मोड काम करना चाहिए.

अगर डिवाइस, परफ़ॉर्मेंस मोड को बनाए रखने की सुविधा के साथ काम करते हैं, तो:

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

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

• कम से कम एक ऐसा खास कोर उपलब्ध कराना चाहिए जिसे टॉप फ़ोरग्राउंड ऐप्लिकेशन के लिए रिज़र्व किया जा सके.

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

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

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

• [C-3-1] Process.getExclusiveCores() एपीआई तरीके से, खाली सूची को वापस लाना ज़रूरी है.

8.6. ऐप्लिकेशन के लिए मेमोरी की सीमाएं

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 के भूमिकाओं के मॉडल के साथ काम करता हो. खास तौर पर, उन्हें एसडीके के दस्तावेज़ में बताई गई हर अनुमति और भूमिका को लागू करना होगा. किसी भी अनुमति और भूमिका को छोड़ा, बदला या अनदेखा नहीं किया जा सकता.

• ज़्यादा अनुमतियां जोड़ सकता है. हालांकि, नई अनुमति के आईडी स्ट्रिंग android.\* नेमस्पेस में नहीं होने चाहिए.

• [C-0-2] protectionLevel की PROTECTION_FLAG_PRIVILEGED वाली अनुमतियां, सिर्फ़ उन ऐप्लिकेशन को दी जानी चाहिए जो सिस्टम इमेज के खास पाथ में पहले से इंस्टॉल हैं. साथ ही, ये अनुमतियां APEX फ़ाइलों के लिए भी होनी चाहिए. इसके अलावा, ये अनुमतियां हर ऐप्लिकेशन के लिए, साफ़ तौर पर अनुमति दी गई अनुमतियों के सबसेट में होनी चाहिए. AOSP, इस ज़रूरी शर्त को पूरा करता है. इसके लिए, वह etc/permissions/ पाथ में मौजूद फ़ाइलों से, हर ऐप्लिकेशन के लिए अनुमति दी गई अनुमतियों को पढ़ता है और उनका पालन करता है. साथ ही, system/priv-app पाथ को खास पाथ के तौर पर इस्तेमाल करता है.

• [C-SR-1] protectionLevel की PROTECTION_SIGNATURE वाली अनुमतियां, सिर्फ़ इन लोगों को देने का सुझाव दिया जाता है:

  • सिस्टम इमेज पर पहले से इंस्टॉल किए गए ऐप्लिकेशन और APEX फ़ाइलें.

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

खतरनाक लेवल की सुरक्षा वाली अनुमतियां, रनटाइम अनुमतियां होती हैं. targetSdkVersion > 22 वाले ऐप्लिकेशन, रनटाइम के दौरान अनुमतियों का अनुरोध करते हैं.

डिवाइस में सेट किए गए सिस्टम के लिए:

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

• [C-0-5] ऐप्लिकेशन को रनटाइम की कोई भी अनुमति तब तक नहीं देनी चाहिए, जब तक कि:

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

  या

  • रनटाइम अनुमतियां, अनुमति देने की डिफ़ॉल्ट नीति के तहत दी जाती हैं. इसके अलावा, ये अनुमतियां किसी प्लैटफ़ॉर्म की भूमिका के लिए भी दी जाती हैं.

• [C-0-6] android.permission.RECOVER_KEYSTORE अनुमति सिर्फ़ उन सिस्टम ऐप्लिकेशन को देनी होगी जो सुरक्षित तरीके से रजिस्टर किए गए रिकवरी एजेंट हैं. सुरक्षित रिकवरी एजेंट को उपयोगकर्ता के डिवाइस पर मौजूद ऐसे सॉफ़्टवेयर एजेंट के तौर पर परिभाषित किया जाता है जो डिवाइस से बाहर मौजूद रिमोट स्टोरेज के साथ सिंक होता है. इसमें सुरक्षित हार्डवेयर होता है, जो Google Cloud Key Vault Service में बताए गए सुरक्षा उपायों के बराबर या उससे ज़्यादा सुरक्षा देता है. इससे लॉकस्क्रीन के नॉलेज फ़ैक्टर पर ब्रूट-फ़ोर्स अटैक को रोका जा सकता है.

डिवाइस में सेट किए गए सिस्टम के लिए:

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

  • डिवाइस की जगह की जानकारी (जैसे, अक्षांश और देशांतर), जैसा कि सेक्शन 9.8.8 में बताया गया है.

  • ऐसी जानकारी जिसका इस्तेमाल डिवाइस की जगह का पता लगाने या उसका अनुमान लगाने के लिए किया जा सकता है. जैसे, SSID, BSSID, सेल आईडी या डिवाइस से कनेक्ट किए गए नेटवर्क की जगह.

  • उपयोगकर्ता की शारीरिक गतिविधि या शारीरिक गतिविधि का क्लासिफ़िकेशन.

खास तौर पर, डिवाइस में सेट किए गए सिस्टम के लिए:

• [C-0-8] किसी ऐप्लिकेशन को जगह की जानकारी या शारीरिक गतिविधि से जुड़ा डेटा ऐक्सेस करने की अनुमति देने के लिए, उपयोगकर्ता की सहमति लेना ज़रूरी है.

• [C-0-9] सिर्फ़ उस ऐप्लिकेशन को रनटाइम की अनुमति मिलनी चाहिए जिसके पास एसडीके टूल में बताई गई ज़रूरी अनुमति हो. उदाहरण के लिए, 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 अनुमति वाले ऐप्लिकेशन को सिर्फ़ सीमित ऐक्सेस मिलना चाहिए. साथ ही, उन्हें तब तक पूरा ऐक्सेस नहीं मिलना चाहिए, जब तक उन्हें एसडीके में बताए गए तरीके से अनुमति वाली सूची में शामिल न कर लिया जाए. एसडीके में, हर softRestricted अनुमति के लिए, पूरे और सीमित ऐक्सेस के बारे में बताया गया है. उदाहरण के लिए, READ_EXTERNAL_STORAGE.

• [C-0-12] setPermissionPolicy और setPermissionGrantState एपीआई में तय की गई अनुमति से जुड़ी पाबंदियों को बायपास करने के लिए, कोई कस्टम फ़ंक्शन या एपीआई उपलब्ध नहीं कराना चाहिए.

• [C-0-13] Android की गतिविधियों और सेवाओं से, नुकसान पहुंचाने वाली अनुमतियों से सुरक्षित किए गए डेटा के हर प्रोग्रामैटिक ऐक्सेस को रिकॉर्ड और ट्रैक करने के लिए, AppOpsManager API का इस्तेमाल करना ज़रूरी है.

• [C-0-14] सिर्फ़ उन ऐप्लिकेशन को भूमिकाएं असाइन करनी चाहिए जिनमें भूमिका की ज़रूरी शर्तों को पूरा करने वाले फ़ंक्शन मौजूद हों.

• [C-0-15] ऐसी भूमिकाएं तय नहीं की जानी चाहिए जो प्लैटफ़ॉर्म की ओर से तय की गई भूमिकाओं की डुप्लीकेट हों या उनके सुपरसेट फ़ंक्शन हों.

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

• [C-0-16] अगर HealthPermissions में इससे जुड़ी कोई अनुमति मौजूद है, तो android.permission-group.HEALTH से मिली प्लैटफ़ॉर्म की अनुमतियों के ज़रिए इसकी सुरक्षा करना ज़रूरी है.

• [C-0-17] अगर कोई प्लैटफ़ॉर्म अनुमति, ज़रूरी डेटा टाइप से मेल नहीं खाती है, तो उसे सिस्टम की कस्टम अनुमति से सुरक्षित रखना ज़रूरी है. (उदाहरण के लिए, ELECTROCARDIOGRAM.)

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

• [C-1-1] एडमिन को इन अनुमतियों को चुपचाप नहीं देना चाहिए:

  • जगह (ACCESS_BACKGROUND_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION).
  • कैमरा (CAMERA)
  • माइक्रोफ़ोन (RECORD_AUDIO)
  • बॉडी सेंसर (BODY_SENSORS)
  • स्वास्थ्य (HealthPermissions)
  • शारीरिक गतिविधि (ACTIVITY_RECOGNITION)

अगर डिवाइसों की रिपोर्ट में 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] पूरी तरह से मैनेज किए जा रहे डिवाइस को सेट अप करते समय (डिवाइस के मालिक का सेट अप), यह डिसक्लेमर दिखाना ज़रूरी है कि आईटी एडमिन के पास, फ़ोन की सेटिंग को कंट्रोल करने की अनुमति होगी. इसमें माइक्रोफ़ोन, कैमरा, और जगह की जानकारी शामिल है. साथ ही, उपयोगकर्ता के पास सेट अप जारी रखने या सेट अप से बाहर निकलने के विकल्प होने चाहिए. हालांकि, अगर एडमिन ने डिवाइस पर अनुमतियों को कंट्रोल करने की सुविधा से ऑप्ट आउट किया है, तो ऐसा नहीं होगा.

अगर डिवाइसों में, सिस्टम यूज़र इंटरफ़ेस (यूआई) 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.15. Sandboxed API लागू करने की प्रोसेस.

9.2. यूआईडी और अलग-अलग प्रोसेस के लिए टेक्नोलॉजी

डिवाइस में सेट किए गए सिस्टम के लिए:

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

9.3. फ़ाइल सिस्टम से जुड़ी अनुमतियां

डिवाइस में सेट किए गए सिस्टम के लिए:

• [C-0-1] Android के फ़ाइल ऐक्सेस करने की अनुमतियों के मॉडल के साथ काम करना ज़रूरी है. इसके बारे में सुरक्षा और अनुमतियों के बारे में जानकारी में बताया गया है.

9.4. वैकल्पिक एक्ज़ीक्यूशन एनवायरमेंट

डिवाइसों में Android की सुरक्षा और अनुमति मॉडल को एक जैसा रखना ज़रूरी है. भले ही, उनमें ऐसे रनटाइम एनवायरमेंट शामिल हों जो Dalvik Executable Format या नेटिव कोड के अलावा, किसी अन्य सॉफ़्टवेयर या टेक्नोलॉजी का इस्तेमाल करके ऐप्लिकेशन को एक्ज़ीक्यूट करते हों. दूसरे शब्दों में:

• [C-0-1] वैकल्पिक रनटाइम, Android ऐप्लिकेशन होने चाहिए. साथ ही, उन्हें Android के स्टैंडर्ड सिक्योरिटी मॉडल का पालन करना चाहिए. इसके बारे में सेक्शन 9 में बताया गया है.

• [C-0-2] <uses-permission> मैकेनिज़्म के ज़रिए, रनटाइम की AndroidManifest.xml फ़ाइल में अनुरोध नहीं की गई अनुमतियों से सुरक्षित किए गए संसाधनों का ऐक्सेस, अन्य रनटाइम को नहीं दिया जाना चाहिए.

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

• [C-0-4] वैकल्पिक रनटाइम को Android सैंडबॉक्स मॉडल का पालन करना होगा. साथ ही, वैकल्पिक रनटाइम का इस्तेमाल करके इंस्टॉल किए गए ऐप्लिकेशन, डिवाइस पर इंस्टॉल किए गए किसी अन्य ऐप्लिकेशन के सैंडबॉक्स का फिर से इस्तेमाल नहीं कर सकते. हालांकि, वे शेयर किए गए User-ID और हस्ताक्षर किए गए सर्टिफ़िकेट के स्टैंडर्ड 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] अगर डिवाइस में बाहरी स्टोरेज के लिए एसडी कार्ड का इस्तेमाल किया जाता है, तो मल्टीयूज़र मोड चालू होने पर एसडी कार्ड के कॉन्टेंट को एन्क्रिप्ट (सुरक्षित) करना ज़रूरी है. इसके लिए, ऐसी कुंजी का इस्तेमाल करना होगा जिसे सिर्फ़ सिस्टम ऐक्सेस कर सकता हो और जिसे हटाया न जा सके. इससे होस्ट पीसी पर मीडिया को पढ़ा नहीं जा सकेगा. इसलिए, डिवाइसों को एमटीपी या इसी तरह के किसी अन्य सिस्टम पर स्विच करना होगा, ताकि होस्ट पीसी को मौजूदा उपयोगकर्ता के डेटा का ऐक्सेस दिया जा सके.

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

• [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-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] MUST inherit all device policy user restrictions and selected non-user restrictions(list below) applied on the primary user of the device to this additional user profile.

  • 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-5] अतिरिक्त प्रोफ़ाइल में सिर्फ़ उन ऐप्लिकेशन को अनुमति दी जानी चाहिए जिनमें लॉन्चर ऐक्टिविटी होती है. इससे वे उन संपर्कों को ऐक्सेस कर पाते हैं जिन्हें पैरंट यूज़र प्रोफ़ाइल पहले से ही ऐक्सेस कर सकती है.

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

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

9.6. प्रीमियम एसएमएस की चेतावनी

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

अगर डिवाइस में android.hardware.telephony के साथ काम करने की सुविधा उपलब्ध है, तो:

• [C-1-1] डिवाइस में मौजूद /data/misc/sms/codes.xml फ़ाइल में तय किए गए रेगुलर एक्सप्रेशन से पहचाने गए नंबरों पर एसएमएस भेजने से पहले, उपयोगकर्ताओं को चेतावनी देनी होगी. अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट, इस ज़रूरी शर्त को पूरा करने वाला एक तरीका उपलब्ध कराता है.

9.7. Security Features

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

Android सैंडबॉक्स में ऐसी सुविधाएं शामिल होती हैं जो Security-Enhanced Linux (SELinux) के ज़रूरी ऐक्सेस कंट्रोल (एमएसी) सिस्टम, seccomp सैंडबॉक्सिंग, और Linux कर्नल में मौजूद अन्य सुरक्षा सुविधाओं का इस्तेमाल करती हैं. डिवाइस में सेट किए गए सिस्टम के लिए:

• [C-0-1] मौजूदा ऐप्लिकेशन के साथ काम करना ज़रूरी है. भले ही, Android फ़्रेमवर्क के नीचे SELinux या कोई अन्य सुरक्षा सुविधा लागू की गई हो.

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

• [C-0-3] SELinux या Android फ़्रेमवर्क के नीचे लागू की गई किसी भी अन्य सुरक्षा सुविधा को, उपयोगकर्ता या ऐप्लिकेशन डेवलपर के लिए कॉन्फ़िगर करने की अनुमति नहीं होनी चाहिए.

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

• [C-0-5] मीडिया फ़्रेमवर्क को कई प्रोसेस में बांटना ज़रूरी है, ताकि हर प्रोसेस के लिए ऐक्सेस को ज़्यादा सीमित किया जा सके. इसके बारे में, Android Open Source Project की साइट पर बताया गया है.

• [C-0-6] कर्नेल ऐप्लिकेशन सैंडबॉक्सिंग की सुविधा लागू करना ज़रूरी है. इससे मल्टीथ्रेड प्रोग्राम से कॉन्फ़िगर की जा सकने वाली नीति का इस्तेमाल करके, सिस्टम कॉल को फ़िल्टर किया जा सकता है. अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट, इस ज़रूरी शर्त को पूरा करता है. इसके लिए, वह थ्रेडग्रुप सिंक्रनाइज़ेशन (टीएसवाईएनसी) के साथ seccomp-BPF को चालू करता है. इसके बारे में source.android.com के कर्नल कॉन्फ़िगरेशन सेक्शन में बताया गया है.

कर्नल की सुरक्षा और खुद की सुरक्षा करने की सुविधाएं, Android की सुरक्षा के लिए ज़रूरी हैं. डिवाइस में सेट किए गए सिस्टम के लिए:

• [C-0-7] कर्नेल स्टैक बफ़र ओवरफ़्लो से सुरक्षा देने वाले तरीके लागू करना ज़रूरी है. इस तरह के कुछ उदाहरण यहां दिए गए हैं: CC_STACKPROTECTOR_REGULAR और CONFIG_CC_STACKPROTECTOR_STRONG.

• [C-0-8] कर्नल मेमोरी के लिए, सुरक्षा से जुड़ी सख्त नीतियां लागू करनी होंगी. जैसे, एक्ज़ीक्यूटेबल कोड सिर्फ़ पढ़ा जा सकता है, सिर्फ़ पढ़े जा सकने वाले डेटा को एक्ज़ीक्यूट नहीं किया जा सकता और न ही उसमें बदलाव किया जा सकता है. साथ ही, बदलाव किए जा सकने वाले डेटा को एक्ज़ीक्यूट नहीं किया जा सकता. उदाहरण के लिए, rodata और CONFIG_STRICT_KERNEL_RWX, दोनों चालू हैं.

• [C-0-9] API लेवल 28 या इसके बाद के वर्शन के साथ शिप किए गए डिवाइसों पर, उपयोगकर्ता-स्पेस और कर्नल-स्पेस के बीच कॉपी की गई फ़ाइलों के लिए, स्टैटिक और डाइनैमिक ऑब्जेक्ट के साइज़ की सीमा की जांच लागू करना ज़रूरी है. उदाहरण के लिए, CONFIG_HARDENED_USERCOPY.

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

• [C-0-11] एपीआई लेवल 28 या इसके बाद के वर्शन वाले डिवाइसों पर, कर्नल को सामान्य usercopy ऐक्सेस एपीआई (जैसे, हार्डवेयर पैन या CONFIG_CPU_SW_DOMAIN_PAN या CONFIG_ARM64_SW_TTBR0_PAN के ज़रिए इम्यूलेट किया गया) के बाहर, उपयोगकर्ता-स्पेस मेमोरी को न तो पढ़ना चाहिए और न ही लिखना चाहिए.

• [C-0-12] अगर हार्डवेयर, CVE-2017-5754 से जुड़ी समस्या से प्रभावित है, तो एपीआई लेवल 28 या इसके बाद के वर्शन (जैसे, CONFIG_PAGE_TABLE_ISOLATION या CONFIG_UNMAP_KERNEL_AT_EL0) के साथ शिप किए गए सभी डिवाइसों पर कर्नेल पेज टेबल आइसोलेशन लागू करना ज़रूरी है.

• [C-0-13] अगर हार्डवेयर, CVE-2017-5715 से जुड़ी समस्या से प्रभावित है, तो ब्रांच प्रेडिक्शन हार्डनिंग को लागू करना ज़रूरी है. यह समस्या, उन सभी डिवाइसों पर होती है जो मूल रूप से एपीआई लेवल 28 या इसके बाद के वर्शन (जैसे, CONFIG_HARDEN_BRANCH_PREDICTOR) के साथ शिप किए गए थे.

• [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) से अतिरिक्त सुरक्षा मिलती है.

• [C-SR-4] जिन कॉम्पोनेंट पर कंट्रोल-फ़्लो इंटिग्रिटी (सीएफ़आई), शैडो कॉल स्टैक (एससीएस) या इंटिजर ओवरफ़्लो सैनिटाइज़ेशन (इंटसैन) चालू है उन्हें बंद न करने का सुझाव दिया जाता है.

• [C-SR-5] सुरक्षा के लिहाज़ से संवेदनशील यूज़रस्पेस कॉम्पोनेंट के लिए, सीएफ़आई, एससीए, और IntSan को चालू करने का सुझाव दिया जाता है. इनके बारे में सीएफ़आई और IntSan में बताया गया है.

• [C-SR-6] कर्नेल में स्टैक इनिशियलाइज़ेशन को चालू करने का सुझाव दिया जाता है, ताकि बिना इनिशियलाइज़ किए गए लोकल वैरिएबल (CONFIG_INIT_STACK_ALL या CONFIG_INIT_STACK_ALL_ZERO) का इस्तेमाल न किया जा सके. साथ ही, डिवाइसों को लागू करने वाले लोगों को यह नहीं मानना चाहिए कि कंपाइलर, लोकल वैरिएबल को इनिशियलाइज़ करने के लिए किस वैल्यू का इस्तेमाल करता है.

• [C-SR-7] कर्नेल में हीप इनिशियलाइज़ेशन को चालू करने का सुझाव दिया जाता है, ताकि बिना इनिशियलाइज़ किए गए हीप ऐलोकेशन (CONFIG_INIT_ON_ALLOC_DEFAULT_ON) का इस्तेमाल न किया जा सके. साथ ही, उन्हें कर्नेल की ओर से इस्तेमाल की गई वैल्यू को इन ऐलोकेशन को इनिशियलाइज़ करने के लिए नहीं मानना चाहिए.

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

• [C-1-1] SELinux को लागू करना ज़रूरी है.

• [C-1-2] SELinux को ग्लोबल एनफ़ोर्सिंग मोड पर सेट करना ज़रूरी है.

• [C-1-3] सभी डोमेन को एनफ़ोर्सिंग मोड में कॉन्फ़िगर करना ज़रूरी है. अनुमति वाले मोड के किसी भी डोमेन को अनुमति नहीं है. इनमें डिवाइस/वेंडर से जुड़े डोमेन भी शामिल हैं.

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

• उन्हें Android Open Source Project के सिस्टम/sepolicy फ़ोल्डर में दी गई डिफ़ॉल्ट SELinux नीति को बनाए रखना चाहिए. साथ ही, अपने डिवाइस के हिसाब से कॉन्फ़िगरेशन के लिए, इस नीति में सिर्फ़ कुछ और चीज़ें जोड़नी चाहिए.

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

• [C-2-1] ज़रूरी है कि डिवाइस में, SELinux के बराबर का मैंडेटरी ऐक्सेस कंट्रोल सिस्टम इस्तेमाल किया जा रहा हो.

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

• [C-SR-9] डीएमए की सुविधा वाले हर I/O डिवाइस को अलग रखने का सुझाव दिया जाता है. इसके लिए, आईओएमएमयू (जैसे, ARM SMMU) का इस्तेमाल करें.

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

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

• [C-SR-10] यह सुझाव दिया जाता है कि इन टेस्ट को, उपयोगकर्ताओं के स्पेस में मेमोरी से जुड़ी गड़बड़ियों का पता लगाने वाले टूल की मदद से किया जाए. जैसे, ARMv9 डिवाइसों के लिए MTE, ARMv8+ डिवाइसों के लिए HWASan या अन्य डिवाइस टाइप के लिए ASan.

• [C-SR-11] कर्नेल मेमोरी से जुड़ी गड़बड़ी का पता लगाने वाले टूल का इस्तेमाल करके, इनकी जांच करने का सुझाव दिया जाता है. जैसे, KASAN (ARMv9 डिवाइसों के लिए CONFIG_KASAN, 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 के एक्सेप्शन लेवल के साथ काम करने की सुविधा है, तो इसे सुरक्षित पार्टिशन मैनेजर के ज़रिए लागू किया जाना चाहिए. अगर ऐसा नहीं है, तो इसे टीईई ओएस के ज़रिए लागू किया जाना चाहिए.

मेमोरी सेफ़्टी टेक्नोलॉजी, एक ऐसी टेक्नोलॉजी है जो android:memtagMode मेनिफ़ेस्ट विकल्प का इस्तेमाल करने वाले ऐप्लिकेशन में, कम से कम इन तरह के बग को ठीक करती है. इन बग के ठीक होने की संभावना ज़्यादा (> 90%) होती है:

• हीप बफ़र ओवरफ़्लो
• use after free
• डबल फ़्री
• wild free (free of a non-malloc pointer)

डिवाइस में सेट किए गए सिस्टम के लिए:

• [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 ओपन सोर्स प्रोजेक्ट, MTE बूटलोडर प्रोटोकॉल के ज़रिए, ऊपर दी गई ज़रूरी शर्तों को पूरा करता है. इसके लिए, बूटलोडर का इस्तेमाल किया जाता है.

अगर कोई डिवाइस android.hardware.telephony का एलान करता है, CAPABILITY_USES_ALLOWED_NETWORK_TYPES_BITMASK रेडियो की सुविधा के साथ काम करता है, और इसमें 2G कनेक्शन के साथ काम करने वाला सेल्युलर मॉडेम शामिल है, तो डिवाइस को इन शर्तों को पूरा करना होगा:

• [C-SR-17] उपयोगकर्ता को 2G की सुविधा बंद और चालू करने का विकल्प देने का सुझाव दिया जाता है.

• [C-SR-18] यह सुझाव दिया जाता है कि डिवाइस एडमिन के अलावा, कोई अन्य डिवाइस इकाई UserManager.DISALLOW_CELLULAR_2G का इस्तेमाल करके, 2G को बंद और चालू करने की उपयोगकर्ता की सुविधा को न बदले.

• [C-SR-19] इस ज़रूरी शर्त को पूरा करने के लिए, TelephonyManager.setAllowedNetworkTypesForReason को ALLOWED_NETWORK_TYPES_REASON_ENABLE_2G वजह के साथ कॉल करने का सुझाव दिया जाता है.

• [C-SR-20] TelephonyManager.getSupportedRadioAccessFamily को कॉल करके, 2G के लिए सेल्युलर मॉडम के काम करने की स्थिति का पता लगाने का सुझाव दिया जाता है. ज़्यादा जानकारी के लिए, 2G बंद करना लेख पढ़ें.

9.8. निजता

9.8.1. इस्तेमाल का इतिहास

Android, उपयोगकर्ता की प्राथमिकताओं का इतिहास सेव करता है. साथ ही, UsageStatsManager की मदद से इस इतिहास को मैनेज करता है.

डिवाइस में सेट किए गए सिस्टम के लिए:

• [C-0-1] को उपयोगकर्ता के इस तरह के इतिहास को सेव करने की अवधि तय करनी होगी.

• [C-SR-1] यह सुझाव दिया जाता है कि डेटा को सेव करके रखने की अवधि 14 दिन ही रखी जाए. यह अवधि, AOSP के डिफ़ॉल्ट कॉन्फ़िगरेशन में तय की गई है.

Android, सिस्टम इवेंट को StatsLog आइडेंटिफ़ायर का इस्तेमाल करके सेव करता है. साथ ही, StatsManager और IncidentManager System API की मदद से, इस तरह के इतिहास को मैनेज करता है.

डिवाइस में सेट किए गए सिस्टम के लिए:

• [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] MediaProjection.createVirtualDisplay() या मालिकाना हक वाले एपीआई के ज़रिए स्क्रीन कास्टिंग या स्क्रीन रिकॉर्डिंग की सुविधा चालू होने पर, उपयोगकर्ता को चेतावनी दिखानी होगी. साथ ही, उपयोगकर्ता की साफ़ तौर पर सहमति लेनी होगी. इससे, उपयोगकर्ता की स्क्रीन पर दिखने वाली संवेदनशील जानकारी को हर बार कैप्चर किया जा सकेगा.

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

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

• [C-0-4] Android 16 में इस ज़रूरी शर्त को हटा दिया गया है.

डिवाइस में सेट किए गए सिस्टम के लिए:

• [C-0-7] संवेदनशील जानकारी को रिकॉर्ड, प्रोजेक्ट या कास्ट नहीं किया जाना चाहिए. जैसे:

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

अगर डिवाइस के सिस्टम में ऐसी सुविधा शामिल है जो स्क्रीन पर दिखने वाले कॉन्टेंट को कैप्चर करती है और/या सिस्टम एपीआई ContentCaptureService के अलावा, डिवाइस पर चलने वाली ऑडियो स्ट्रीम को रिकॉर्ड करती है या सेक्शन 9.8.6 ओएस-लेवल और आस-पास के डेटा में बताए गए अन्य मालिकाना हक वाले तरीकों का इस्तेमाल करती है, तो:

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

अगर डिवाइसों में ऐसा कॉम्पोनेंट शामिल है जो बॉक्स से बाहर ही चालू हो जाता है और आस-पास की आवाज़ और/या डिवाइस पर चलने वाले ऑडियो को रिकॉर्ड कर सकता है, ताकि उपयोगकर्ता के कॉन्टेक्स्ट के बारे में काम की जानकारी का अनुमान लगाया जा सके, तो:

• [C-2-1] रिकॉर्ड किए गए रॉ ऑडियो या किसी ऐसे फ़ॉर्मैट को डिवाइस के परसिस्टेंट स्टोरेज में सेव नहीं करना चाहिए या डिवाइस से बाहर नहीं भेजना चाहिए जिसे वापस ओरिजनल ऑडियो या उसके जैसा ऑडियो में बदला जा सकता हो. हालांकि, उपयोगकर्ता की साफ़ तौर पर सहमति मिलने पर ऐसा किया जा सकता है.

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

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

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

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

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

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

• [C-SR-1] यह सुझाव दिया जाता है कि जब कोई ऐप्लिकेशन माइक्रोफ़ोन से ऑडियो डेटा ऐक्सेस कर रहा हो, तब माइक्रोफ़ोन इंडिकेटर दिखाया जाए. हालांकि, ऐसा तब नहीं होना चाहिए, जब माइक्रोफ़ोन को सिर्फ़ HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService या सेक्शन 9.1 में बताई गई भूमिकाओं वाले ऐप्लिकेशन [C-3-X] ऐक्सेस कर रहे हों.

• [C-SR-2] PermissionManager.getIndicatorAppOpUsageData() से मिले, हाल ही में और चालू ऐप्लिकेशन की सूची को दिखाने का सुझाव दिया जाता है. साथ ही, उनसे जुड़े एट्रिब्यूशन मैसेज भी दिखाने का सुझाव दिया जाता है.

• [C-SR-3] यह सुझाव दिया जाता है कि सिस्टम ऐप्लिकेशन के लिए, माइक्रोफ़ोन इंडिकेटर को न छिपाएं. इन ऐप्लिकेशन के यूज़र इंटरफ़ेस दिखते हैं या ये सीधे तौर पर उपयोगकर्ता से इंटरैक्ट करते हैं.

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

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

• [C-SR-5] PermissionManager.getIndicatorAppOpUsageData() से मिले कैमरे का इस्तेमाल करके, हाल ही में इस्तेमाल किए गए और चालू ऐप्लिकेशन दिखाने का सुझाव दिया जाता है. साथ ही, उनसे जुड़े एट्रिब्यूशन मैसेज भी दिखाने का सुझाव दिया जाता है.

• [C-SR-6] यह सुझाव दिया जाता है कि सिस्टम ऐप्लिकेशन के लिए, कैमरा इंडिकेटर को न छिपाएं. इन ऐप्लिकेशन में दिखने वाले उपयोगकर्ता इंटरफ़ेस होते हैं या उपयोगकर्ता सीधे तौर पर इंटरैक्ट करते हैं.

9.8.3. कनेक्टिविटी

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

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

9.8.4. नेटवर्क ट्रैफ़िक

डिवाइस में सेट किए गए सिस्टम के लिए:

• [C-0-1] सिस्टम के भरोसेमंद सर्टिफ़िकेट देने वाली संस्था (सीए) के स्टोर के लिए, एक जैसे रूट सर्टिफ़िकेट पहले से इंस्टॉल होने चाहिए. ये सर्टिफ़िकेट, अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट में दिए गए सर्टिफ़िकेट के जैसे होने चाहिए.

• [C-0-2] डिवाइस को खाली उपयोगकर्ता रूट सीए स्टोर के साथ शिप किया जाना चाहिए.

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

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

• [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, सिम का सीरियल नंबर, और इंटरनैशनल मोबाइल सब्सक्राइबर आइडेंटिटी (आईएमएसआई) का ऐक्सेस भी नहीं मिलना चाहिए. हालांकि, अगर ऐप्लिकेशन इनमें से कोई एक ज़रूरी शर्त पूरी करता है, तो उसे ऐक्सेस दिया जा सकता है:
  • यह मोबाइल और इंटरनेट सेवा देने वाली कंपनी का ऐसा ऐप्लिकेशन है जिस पर हस्ताक्षर किया गया है. इसकी पुष्टि डिवाइस बनाने वाली कंपनियां करती हैं.
  • को READ_PRIVILEGED_PHONE_STATE की अनुमति दी गई हो.
  • यूआईसीसी कैरियर के खास अधिकार में बताए गए कैरियर के खास अधिकार हों.
  • डिवाइस का मालिक या प्रोफ़ाइल का मालिक हो और उसे READ_PHONE_STATE अनुमति दी गई हो.
  • (सिर्फ़ सिम सीरियल नंबर/आईसीसीआईडी के लिए) स्थानीय नियमों के मुताबिक, ऐप्लिकेशन को यह पता लगाना होगा कि सदस्य की पहचान में क्या बदलाव हुए हैं.

9.8.6. ओएस-लेवल और आस-पास के डेटा को सुरक्षित रखने वाला

• [C-1-7] उपयोगकर्ता को, AppSearch या मालिकाना हक वाले तरीकों से इकट्ठा किए गए डेटा को Android प्लैटफ़ॉर्म (जैसे, लॉन्चर) में दिखाए जाने से ऑप्ट-आउट करने की सुविधा देनी होगी.

• [C-SR-1] इंटरनेट की अनुमति का अनुरोध न करने का सुझाव दिया जाता है.

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

• [C-SR-4] इन्हें Android SDK API या ओईएम के मालिकाना हक वाली मिलती-जुलती ओपन-सोर्स रिपॉज़िटरी के साथ लागू करने का सुझाव दिया जाता है. इसके अलावा, इन्हें सैंडबॉक्स किए गए तरीके से लागू किया जा सकता है. इसके लिए, 9.8.15 सैंडबॉक्स किए गए एपीआई लागू करने का तरीका देखें.

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

9.8.7. क्लिपबोर्ड का ऐक्सेस

डिवाइस में सेट किए गए सिस्टम के लिए:

• [C-0-1] क्लिपबोर्ड से काटा गया डेटा (जैसे, ClipboardManager एपीआई के ज़रिए) तब तक वापस नहीं भेजा जाना चाहिए, जब तक कि तीसरे पक्ष का ऐप्लिकेशन डिफ़ॉल्ट आईएमई न हो या वह ऐप्लिकेशन न हो जिस पर फ़िलहाल फ़ोकस है.

• [C-0-2] क्लिपबोर्ड में डेटा रखे जाने या क्लिपबोर्ड से डेटा पढ़े जाने के 60 मिनट के अंदर, क्लिपबोर्ड का डेटा मिटा देना चाहिए.

9.8.8. जगह

जगह की जानकारी में, Android Location क्लास में मौजूद जानकारी शामिल होती है. जैसे, अक्षांश, देशांतर, ऊंचाई. साथ ही, इसमें ऐसे आइडेंटिफ़ायर भी शामिल होते हैं जिन्हें जगह की जानकारी में बदला जा सकता है. लोकेशन की जानकारी, डीजीपीएस (डिफ़रेंशियल ग्लोबल पॉज़िशनिंग सिस्टम) जितनी सटीक या देश के लेवल की लोकेशन (जैसे कि देश के कोड की लोकेशन - एमसीसी - मोबाइल कंट्री कोड) जितनी सामान्य हो सकती है.

यहां जगह की जानकारी के उन टाइप की सूची दी गई है जिनसे सीधे तौर पर किसी उपयोगकर्ता की जगह की जानकारी मिलती है या जिन्हें उपयोगकर्ता की जगह की जानकारी में बदला जा सकता है. यह पूरी सूची नहीं है. हालांकि, इसका इस्तेमाल इस उदाहरण के तौर पर किया जाना चाहिए कि जगह की जानकारी को सीधे तौर पर या किसी और तरीके से कहां से लिया जा सकता है:

• जीपीएस/जीएनएसएस/डीजीपीएस/पीपीपी

  • ग्लोबल पोज़िशनिंग सॉल्यूशन या ग्लोबल नेविगेशन सैटलाइट सिस्टम या डिफ़रेंशियल ग्लोबल पोज़िशनिंग सॉल्यूशन
  • इसमें जीएनएसएस के मेज़रमेंट से जुड़ा रॉ डेटा और जीएनएसएस स्टेटस भी शामिल है
    • जीएनएसएस के रॉ मेज़रमेंट से सटीक जगह की जानकारी का पता लगाया जा सकता है

• यूनीक आइडेंटिफ़ायर वाली वायरलेस टेक्नोलॉजी, जैसे कि:

  • वाई-फ़ाई ऐक्सेस पॉइंट (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] यह पक्का करना ज़रूरी है कि Emergency Location Bypass API 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 जैसे ऐप्लिकेशन).

  • Download Provider, "downloads" provider authority का इस्तेमाल करता है. इससे ऐप्लिकेशन के स्टोरेज में फ़ाइलें डाउनलोड की जा सकती हैं.

  • ऐसे मीडिया ट्रांसफ़र प्रोटोकॉल (एमटीपी) ऐप्लिकेशन जिन पर प्लैटफ़ॉर्म के हस्ताक्षर होते हैं और जो फ़ाइलों को किसी दूसरे डिवाइस पर ट्रांसफ़र करने के लिए, खास अनुमति ACCESS_MTP का इस्तेमाल करते हैं.

  • अन्य ऐप्लिकेशन इंस्टॉल करने वाले और INSTALL_PACKAGES अनुमति रखने वाले ऐप्लिकेशन, APK एक्सपैंशन फ़ाइलों को मैनेज करने के लिए सिर्फ़ "obb" डायरेक्ट्री को ऐक्सेस कर सकते हैं.

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 के ज़रिए ऐप्लिकेशन को सिस्टम में डेटा ब्लोब भेजने की अनुमति देता है. इससे, चुने गए ऐप्लिकेशन के साथ डेटा ब्लोब शेयर किए जा सकते हैं.

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

• [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] MUST enforce that the caller of MusicRecognitionManager holds the MANAGE_MUSIC_RECOGNITION permission

• [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] जब कोई ऐप्लिकेशन, ब्लॉक किए गए माइक्रोफ़ोन या कैमरे को ऐक्सेस करने की कोशिश करता है, तो उसे उपयोगकर्ता को एक ऐसा विकल्प दिखाना होगा जिसे खारिज नहीं किया जा सकता. इसमें साफ़ तौर पर यह बताया गया हो कि सेंसर ब्लॉक है और उसे ब्लॉक करना जारी रखने या अनब्लॉक करने के लिए, उपयोगकर्ता को विकल्प चुनना होगा. यह विकल्प, एओएसपी के उस वर्शन के मुताबिक होना चाहिए जो इस ज़रूरी शर्त को पूरा करता है.

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

9.8.14. लागू नहीं

9.8.16. ऑडियो और कैमरे का लगातार डेटा

अगर डिवाइसों पर लागू किए गए सिस्टम, अनुच्छेद 9.8.2 या अनुच्छेद 9.8.6 में बताए गए किसी भी डेटा को कैप्चर करते हैं और अगर वे लागू किए गए सिस्टम, AudioRecord, SoundTrigger या अन्य ऑडियो एपीआई के ज़रिए बैकग्राउंड में (लगातार) हासिल किए गए ऑडियो डेटा या CameraManager या अन्य कैमरा एपीआई के ज़रिए बैकग्राउंड में (लगातार) हासिल किए गए कैमरा डेटा का इस्तेमाल करते हैं, तो:

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

  • यह ऐक्सेस, सैंडबॉक्स किए गए तरीके से लागू किया जाता है. इसके बारे में जानने के लिए, 9.8.15 सैंडबॉक्स किए गए एपीआई को लागू करने का तरीका देखें. यह ऐक्सेस, एक ऐसे पैकेज के ज़रिए किया जाता है जिसमें इनमें से एक या इससे ज़्यादा भूमिकाएँ होती हैं: सिस्टम यूज़र इंटरफ़ेस (यूआई) इंटेलिजेंस, सिस्टम ऐंबियंट ऑडियो इंटेलिजेंस, सिस्टम ऑडियो इंटेलिजेंस, सिस्टम सूचना इंटेलिजेंस, सिस्टम टेक्स्ट इंटेलिजेंस, या सिस्टम विज़ुअल इंटेलिजेंस.

  • ऐक्सेस, सैंडबॉक्स के ज़रिए किया जाता है. इसे 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 API का इस्तेमाल किया गया हो.

9.8.17. Telemetry

Android, StatsLog API का इस्तेमाल करके सिस्टम और ऐप्लिकेशन के लॉग सेव करता है. इन लॉग को StatsManager API के ज़रिए मैनेज किया जाता है. इनका इस्तेमाल खास सिस्टम ऐप्लिकेशन कर सकते हैं.

StatsManager, निजता बनाए रखने के तरीके का इस्तेमाल करने वाले डिवाइसों से, निजता के लिहाज़ से संवेदनशील डेटा इकट्ठा करने का तरीका भी उपलब्ध कराता है. खास तौर पर, StatsManager::query एपीआई की मदद से, पाबंदी वाली मेट्रिक कैटगरी के बारे में क्वेरी की जा सकती है. इन कैटगरी को StatsLog में तय किया गया है.

StatsManager से प्रतिबंधित मेट्रिक के बारे में क्वेरी करने और उन्हें इकट्ठा करने वाला कोई भी तरीका:

• [C-0-1] यह डिवाइस पर मौजूद एकमात्र ऐप्लिकेशन/इस्तेमाल होना चाहिए. साथ ही, इसके पास READ_RESTRICTED_STATS की अनुमति होनी चाहिए.

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

• [C-0-3] ऐसे डेटा को डिवाइस पर मौजूद किसी भी उपयोगकर्ता की पहचान (जैसे कि खाता) से नहीं जोड़ा जाना चाहिए.

• [C-0-4] इस तरह के डेटा को ओएस के उन कॉम्पोनेंट के साथ शेयर नहीं किया जाना चाहिए जो इस सेक्शन (9.8.17. टेलीमेट्री).

• [C-0-5] उपयोगकर्ता को निजता बनाए रखने वाले टेलीमेट्री डेटा को इकट्ठा करने, इस्तेमाल करने, और शेयर करने की सुविधा को चालू/बंद करने का विकल्प देना ज़रूरी है.

• [C-0-6] अगर डेटा को डिवाइस पर किसी भी फ़ॉर्म में सेव किया जाता है, तो लागू करने वाली कंपनी को उपयोगकर्ता को ऐसा विकल्प देना होगा जिससे वह उस डेटा को मिटा सके जिसे लागू करने वाली कंपनी इकट्ठा करती है. अगर उपयोगकर्ता ने डेटा मिटाने का विकल्प चुना है, तो डिवाइस पर सेव किया गया सारा डेटा मिटाना ज़रूरी है.

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

• [C-0-8] इस सेक्शन में, डेटा के बाहर जाने से जुड़ी नीतियों को लागू करना ज़रूरी है, ताकि StatsLog में तय की गई, प्रतिबंधित मेट्रिक कैटगरी में डेटा इकट्ठा करने पर रोक लगाई जा सके.

9.8.18. एजेंटिक फ़ंक्शन की निजता

9.9. डेटा स्टोरेज एन्क्रिप्शन

सभी डिवाइसों को सेक्शन 9.9.1 में दी गई ज़रूरी शर्तों को पूरा करना होगा. जिन डिवाइसों को इस दस्तावेज़ में बताए गए एपीआई लेवल से पहले लॉन्च किया गया था उन्हें सेक्शन 9.9.2 और 9.9.3 में बताई गई ज़रूरी शर्तों से छूट दी गई है. हालांकि, उन्हें Android Compatibility Definition document के सेक्शन 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 में बताए गए तरीके के मुताबिक, हर उपयोगकर्ता के लिए ब्लॉक-लेवल एन्क्रिप्शन.

9.9.3. एन्क्रिप्ट (सुरक्षित) करने के तरीके

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

• [C-1-1] डिवाइस को बिना क्रेडेंशियल के बूट अप करना होगा. साथ ही, ACTION_LOCKED_BOOT_COMPLETED मैसेज ब्रॉडकास्ट होने के बाद, डायरेक्ट बूट की सुविधा वाले ऐप्लिकेशन को डिवाइस एन्क्रिप्ट (डीई) किए गए स्टोरेज को ऐक्सेस करने की अनुमति देनी होगी.

• [C-1-2] क्रेडेंशियल एन्क्रिप्ट (सीई) किए गए स्टोरेज को तब तक ऐक्सेस करने की अनुमति नहीं देनी चाहिए, जब तक कि ये दोनों शर्तें पूरी न हो जाएं:

  • उपयोगकर्ता, पुष्टि करने के मुख्य तरीके (जैसे, पासवर्ड, पैटर्न या पिन) का इस्तेमाल करके डिवाइस को अनलॉक करता है.
  • ACTION_USER_UNLOCKED मैसेज ब्रॉडकास्ट किया जाता है.

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

• [C-1-4] वेरिफ़ाइड बूट का इस्तेमाल करना ज़रूरी है.

9.9.3.1. मेटाडेटा एन्क्रिप्शन के साथ फ़ाइल के आधार पर एन्क्रिप्शन

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

• [C-1-5] फ़ाइल के कॉन्टेंट और फ़ाइल सिस्टम के मेटाडेटा को AES-256-XTS या Adiantum का इस्तेमाल करके एन्क्रिप्ट (सुरक्षित) करना ज़रूरी है. AES-256-XTS का मतलब, 256-बिट साइफ़र कुंजी की लंबाई वाला Advanced Encryption Standard है. यह 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] अगर डिवाइस में ऐडवांस एन्क्रिप्शन स्टैंडर्ड (एईएस) के निर्देश हैं (जैसे, ARM पर आधारित डिवाइसों पर ARMv8 क्रिप्टोग्राफ़ी एक्सटेंशन या x86 पर आधारित डिवाइसों पर AES-NI), तो फ़ाइल के नाम, फ़ाइल के कॉन्टेंट, और फ़ाइल सिस्टम के मेटाडेटा को एन्क्रिप्ट (सुरक्षित) करने के लिए, ऊपर दिए गए एईएस पर आधारित विकल्पों का इस्तेमाल करना ज़रूरी है. Adiantum का इस्तेमाल नहीं किया जाना चाहिए.
• [C-1-13] CE और DE की से ज़रूरी सब-की (जैसे, हर फ़ाइल के लिए अलग-अलग की) पाने के लिए, क्रिप्टोग्राफ़िक तरीके से सुरक्षित और नॉन-रिवर्सिबल की डेरीवेशन फ़ंक्शन (जैसे, HKDF-SHA512) का इस्तेमाल करना ज़रूरी है. "क्रिप्टोग्राफ़िक रूप से मज़बूत और नॉन-रिवर्सिबल" का मतलब है कि कुंजी बनाने वाले फ़ंक्शन में कम से कम 256 बिट की सुरक्षा होती है और यह अपने इनपुट पर स्यूडोरैंडम फ़ंक्शन फ़ैमिली के तौर पर काम करता है.
• [C-1-14] अलग-अलग क्रिप्टोग्राफ़िक कामों के लिए, एक ही फ़ाइल आधारित एन्क्रिप्शन (एफ़बीई) कुंजियों या सबकुंजियों का इस्तेमाल नहीं करना चाहिए. जैसे, एन्क्रिप्शन और कुंजी डेलिवरी, दोनों के लिए या दो अलग-अलग एन्क्रिप्शन एल्गोरिदम के लिए.
• [C-1-15] यह पक्का करना ज़रूरी है कि परसिस्टेंट स्टोरेज पर, एन्क्रिप्ट (सुरक्षित) की गई फ़ाइल के कॉन्टेंट के सभी गैर-मिटाए गए ब्लॉक को एन्क्रिप्शन की और इनिशियलाइज़ेशन वेक्टर (आईवी) के कॉम्बिनेशन का इस्तेमाल करके एन्क्रिप्ट (सुरक्षित) किया गया हो. यह कॉम्बिनेशन, फ़ाइल और फ़ाइल में ऑफ़सेट, दोनों पर निर्भर करता है. इसके अलावा, इस तरह के सभी कॉम्बिनेशन अलग-अलग होने चाहिए. हालांकि, अगर एन्क्रिप्शन के लिए इनलाइन एन्क्रिप्शन हार्डवेयर का इस्तेमाल किया जा रहा है, तो ऐसा करना ज़रूरी नहीं है. यह हार्डवेयर सिर्फ़ 32 बिट की आईवी लेंथ के साथ काम करता है.
• [C-1-16] यह पक्का करना ज़रूरी है कि अलग-अलग डायरेक्ट्री में मौजूद परसिस्टेंट स्टोरेज में, मिटाए नहीं गए सभी एन्क्रिप्ट (सुरक्षित) किए गए फ़ाइल नामों को एन्क्रिप्शन कुंजी और इनिशियलाइज़ेशन वेक्टर (आईवी) के अलग-अलग कॉम्बिनेशन का इस्तेमाल करके एन्क्रिप्ट (सुरक्षित) किया गया हो.

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

• ये कुंजियां, सीई और डीई स्टोरेज एरिया और फ़ाइल सिस्टम के मेटाडेटा को सुरक्षित रखती हैं:

  • [C-1-7] इसे क्रिप्टोग्राफ़िक तरीके से, हार्डवेयर से सुरक्षित कुंजी या डेटा वाले कीस्टोर से बाइंड किया जाना चाहिए. यह कीस्टोर, वेरिफ़ाइड बूट और डिवाइस के हार्डवेयर रूट ऑफ़ ट्रस्ट से जुड़ा होना चाहिए.
  • [C-1-8] CE कुंजियों को उपयोगकर्ता की लॉक स्क्रीन के क्रेडेंशियल से बाइंड किया जाना चाहिए.
  • [C-1-9] अगर उपयोगकर्ता ने लॉक स्क्रीन के क्रेडेंशियल नहीं दिए हैं, तो सीई कुंजियों को डिफ़ॉल्ट पासवर्ड से बाइंड किया जाना चाहिए.
  • [C-1-10] यूनीक और अलग होना चाहिए. दूसरे शब्दों में कहें, तो किसी भी उपयोगकर्ता के CE या DE कुंजी का मिलान, किसी अन्य उपयोगकर्ता के CE या DE कुंजी से नहीं होना चाहिए.
  • [C-1-11] ज़रूरी तौर पर इस्तेमाल किए जाने वाले सिफ़र, कुंजी की लंबाई, और मोड का इस्तेमाल करना ज़रूरी है.
  • [C-1-12] बूटलोडर को अनलॉक और लॉक करने के दौरान, यहां बताए गए तरीके के मुताबिक, इसे सुरक्षित तरीके से मिटाना ज़रूरी है.

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

अपस्ट्रीम Android Open Source प्रोजेक्ट, Linux कर्नल की "fscrypt" एन्क्रिप्शन सुविधा के आधार पर, अलग-अलग फ़ाइलों को अलग-अलग तरीकों से एन्क्रिप्ट करने का तरीका उपलब्ध कराता है. साथ ही, Linux कर्नल की "dm-default-key" सुविधा के आधार पर, मेटाडेटा को एन्क्रिप्ट करने का तरीका उपलब्ध कराता है.

9.9.3.2. हर उपयोगकर्ता के लिए ब्लॉक-लेवल एन्क्रिप्शन

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

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

• [C-1-4] उपयोगकर्ता के पार्टिशन के ब्लॉक-लेवल एन्क्रिप्शन के लिए, AES-256-XTS का इस्तेमाल करना ज़रूरी है.

• हर उपयोगकर्ता के हिसाब से ब्लॉक-लेवल पर एन्क्रिप्ट (सुरक्षित) किए गए डिवाइसों की सुरक्षा करने वाली कुंजियां:

  • [C-1-5] इसे क्रिप्टोग्राफ़िक तरीके से, हार्डवेयर से सुरक्षित कुंजी या डेटा वाले कीस्टोर से बाइंड किया जाना चाहिए. यह कीस्टोर, वेरिफ़ाइड बूट और डिवाइस के हार्डवेयर रूट ऑफ़ ट्रस्ट से जुड़ा होना चाहिए.
  • [C-1-6] यह उपयोगकर्ता की लॉक स्क्रीन के क्रेडेंशियल से जुड़ा होना चाहिए.

हर उपयोगकर्ता के लिए ब्लॉक-लेवल एन्क्रिप्शन को लागू किया जा सकता है. इसके लिए, हर उपयोगकर्ता के लिए बनाए गए पार्टीशन पर Linux कर्नल की "dm-crypt" सुविधा का इस्तेमाल किया जा सकता है.

9.9.4. रीबूट करने के बाद फिर से शुरू करें

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

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

खास तौर से:

• [C-0-1] सीई स्टोरेज को कोई भी व्यक्ति नहीं पढ़ सकता. भले ही, उसके पास डिवाइस हो. साथ ही, उसके पास ये सुविधाएं और सीमाएं हों:

  • आर्बिट्रेरी मैसेज पर हस्ताक्षर करने के लिए, किसी भी वेंडर या कंपनी की साइनिंग पासकोड का इस्तेमाल कर सकता है.
  • इससे डिवाइस को ओटीए मिल सकता है.
  • नीचे दी गई जानकारी के मुताबिक, किसी भी हार्डवेयर (एपी, फ़्लैश वगैरह) के ऑपरेशन में बदलाव किया जा सकता है. हालांकि, इस तरह के बदलाव में कम से कम एक घंटे का समय लगता है. साथ ही, पावर साइकल की वजह से रैम का कॉन्टेंट मिट जाता है.
  • छेड़छाड़ से सुरक्षित हार्डवेयर (जैसे, 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) और सार्वजनिक पासकोड के साइज़ (RSA-2048) के लिए, NIST की मौजूदा सलाह के मुताबिक, पुष्टि करने वाले एल्गोरिदम का इस्तेमाल करना ज़रूरी है.
• [C-1-6] सिस्टम की पुष्टि न होने पर, बूटिंग पूरी करने की अनुमति नहीं देनी चाहिए. हालांकि, अगर उपयोगकर्ता बूटिंग जारी रखने की सहमति देता है, तो बूटिंग की अनुमति दी जा सकती है. ऐसे में, पुष्टि न किए गए किसी भी स्टोरेज ब्लॉक से मिले डेटा का इस्तेमाल नहीं किया जाना चाहिए.
• [C-1-7] डिवाइस पर पुष्टि किए गए पार्टिशन में बदलाव करने की अनुमति नहीं दी जानी चाहिए. ऐसा तब तक नहीं किया जाना चाहिए, जब तक उपयोगकर्ता ने बूटलोडर को साफ़ तौर पर अनलॉक न कर दिया हो.
• [C-1-8] छेड़छाड़ से सुरक्षित स्टोरेज का इस्तेमाल करना ज़रूरी है: यह जानकारी सेव करने के लिए कि बूटलोडर अनलॉक है या नहीं. छेड़छाड़ का पता लगाने वाले स्टोरेज का मतलब है कि बूटलोडर यह पता लगा सकता है कि Android के अंदर से स्टोरेज में छेड़छाड़ की गई है या नहीं.
• [C-1-9] डिवाइस का इस्तेमाल करते समय, उपयोगकर्ता को यह प्रॉम्प्ट मिलना ज़रूरी है. साथ ही, बूटलोडर लॉक मोड से बूटलोडर अनलॉक मोड पर स्विच करने की अनुमति देने से पहले, उपयोगकर्ता से पुष्टि कराना ज़रूरी है.
• [C-1-10] Android के इस्तेमाल किए गए पार्टीशन (जैसे कि बूट, सिस्टम पार्टीशन) के लिए, रोलबैक सुरक्षा लागू करना ज़रूरी है. साथ ही, ओएस के कम से कम ज़रूरी वर्शन का पता लगाने के लिए इस्तेमाल किए गए मेटाडेटा को सेव करने के लिए, छेड़छाड़ से सुरक्षित स्टोरेज का इस्तेमाल करना ज़रूरी है.

• [C-1-11] बूटलोडर अनलॉक और लॉक करने के दौरान, उपयोगकर्ता के सभी डेटा को सुरक्षित तरीके से मिटाना ज़रूरी है. ऐसा '9.12 के मुताबिक किया जाना चाहिए. डेटा मिटाना' (इसमें उपयोगकर्ता डेटा का बंटवारा और कोई भी NVRAM स्पेस शामिल है).

• [C-1-14] सिस्टम कॉन्फ़िगरेशन में require-strict-signature के तौर पर लिस्ट किए गए, अनुमति वाली सूची में शामिल पैकेज के लिए, हर बूट पर कम से कम एक बार हस्ताक्षर की पुष्टि करना ज़रूरी है.

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

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

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

अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट, external/avb/ रिपॉज़िटरी में इस सुविधा को लागू करने का सबसे सही तरीका बताता है. इसे Android लोड करने के लिए इस्तेमाल किए जाने वाले बूटलोडर में इंटिग्रेट किया जा सकता है.

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

• [C-2-1] पूरी फ़ाइल पढ़े बिना, फ़ाइल के कॉन्टेंट की क्रिप्टोग्राफ़िक तरीके से पुष्टि करने की सुविधा.

• [C-2-2] सुरक्षित की गई फ़ाइल पर पढ़ने के अनुरोधों को तब तक पूरा नहीं किया जाना चाहिए, जब तक कि पढ़े जाने वाले कॉन्टेंट की पुष्टि ऊपर दिए गए [C-2-1] के मुताबिक न हो जाए.

• [C-2-4] चालू की गई फ़ाइलों के लिए, फ़ाइल के चेकसम को O(1) में दिखाना ज़रूरी है.

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

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-1-1] कीस्टोर को लागू करने के लिए, अलग से एक्ज़ीक्यूशन एनवायरमेंट का इस्तेमाल करना ज़रूरी है.

• [C-1-3] लॉक स्क्रीन पर पुष्टि करने की प्रोसेस, आइसोलेटेड एक्ज़ीक्यूशन एनवायरमेंट में पूरी होनी चाहिए. साथ ही, पुष्टि हो जाने के बाद ही, पुष्टि से जुड़ी कुंजियों का इस्तेमाल करने की अनुमति दी जानी चाहिए. लॉक स्क्रीन के क्रेडेंशियल इस तरह से सेव किए जाने चाहिए कि सिर्फ़ आइसोलेटेड एक्ज़ीक्यूशन एनवायरमेंट ही लॉक स्क्रीन की पुष्टि कर सके. अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट, Gatekeeper हार्डवेयर ऐब्स्ट्रैक्शन लेयर (HAL) और Trusty उपलब्ध कराता है. इनका इस्तेमाल इस ज़रूरी शर्त को पूरा करने के लिए किया जा सकता है.

• [C-1-4] इसमें कुंजी की पुष्टि करने की सुविधा होनी चाहिए. साथ ही, पुष्टि करने के लिए इस्तेमाल की जाने वाली हस्ताक्षर कुंजी को सुरक्षित हार्डवेयर से सुरक्षित किया जाना चाहिए और हस्ताक्षर करने की प्रोसेस को सुरक्षित हार्डवेयर में पूरा किया जाना चाहिए. अटेस्टेशन साइनिंग कुंजियों को डिवाइस के स्थायी आइडेंटिफ़ायर के तौर पर इस्तेमाल नहीं किया जाना चाहिए.

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

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

• [C-1-6] IKeymasterDevice 3.0 या इसके बाद के वर्शन या IKeyMintDevice 1 या इसके बाद के वर्शन पर काम करना चाहिए.

9.11.1. सुरक्षित लॉक स्क्रीन, पुष्टि करने की सुविधा, और वर्चुअल डिवाइस

AOSP में, पुष्टि करने के लिए टियर वाला मॉडल इस्तेमाल किया जाता है. इसमें, जानकारी पर आधारित पुष्टि करने के मुख्य तरीके के साथ-साथ, बायोमेट्रिक पुष्टि करने का दूसरा मज़बूत तरीका या पुष्टि करने के तीसरे कमज़ोर तरीके का इस्तेमाल किया जा सकता है.

डिवाइस में सेट किए गए सिस्टम के लिए:

• [C-SR-1] यह सुझाव दिया जाता है कि पुष्टि करने के मुख्य तरीके के तौर पर, इनमें से सिर्फ़ एक को सेट किया जाए:

  • अंकों वाला पिन
  • अक्षर और अंक वाला पासवर्ड
  • ठीक 3x3 बिंदुओं वाली ग्रिड पर स्वाइप करने का पैटर्न

  ध्यान दें कि ऊपर दिए गए पुष्टि करने के तरीकों को इस दस्तावेज़ में, पुष्टि करने के सुझाए गए मुख्य तरीके के तौर पर बताया गया है.

• [C-0-1] मुख्य पुष्टि करने की कोशिशों की संख्या सीमित होनी चाहिए.

• [C-SR-5] हम यह सुझाव देते हैं कि डिवाइस में, पुष्टि करने के मुख्य तरीके से 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] MUST have a fall-back mechanism to use one of the recommended primary authentication methods which is based on a known secret.

• [C-4-3] इसे बंद किया जाना चाहिए.साथ ही, डिवाइस के नीति नियंत्रक (डीपीसी) ऐप्लिकेशन के DevicePolicyManager.setKeyguardDisabledFeatures() तरीके को कॉल करके, कीगार्ड सुविधा की नीति सेट करने पर, स्क्रीन को अनलॉक करने के लिए सिर्फ़ सुझाए गए मुख्य पुष्टि करने के तरीके का इस्तेमाल करने की अनुमति दी जानी चाहिए. साथ ही, इससे जुड़े किसी भी बायोमेट्रिक फ़्लैग (जैसे कि KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE या KEYGUARD_DISABLE_IRIS) का इस्तेमाल किया जाना चाहिए.

अगर बायोमेट्रिक ऑथेंटिकेशन के तरीके, क्लास 3 (पहले मज़बूत) की ज़रूरी शर्तों को पूरा नहीं करते हैं, जैसा कि सेक्शन 7.3.10 में बताया गया है, तो:

• [C-5-1] अगर डिवाइस नीति नियंत्रक (डीपीसी) ऐप्लिकेशन ने DevicePolicyManager.setRequiredPasswordComplexity() का इस्तेमाल करके, पासवर्ड की ज़रूरी शर्तों से जुड़ी नीति को PASSWORD_COMPLEXITY_LOW से ज़्यादा पाबंदियों वाले कॉम्प्लेक्सिटी बकेट पर सेट किया है, तो इन तरीकों को बंद करना ज़रूरी है. इसके अलावा, अगर डीपीसी ऐप्लिकेशन ने DevicePolicyManager.setPasswordQuality() का इस्तेमाल करके, पासवर्ड की ज़रूरी शर्तों से जुड़ी नीति को PASSWORD_QUALITY_BIOMETRIC_WEAK से ज़्यादा पाबंदियों वाले क्वालिटी कॉन्स्टेंट पर सेट किया है, तो भी इन तरीकों को बंद करना ज़रूरी है.

• [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) तरीका.

  • DevicePolicyManager.setPasswordQuality() तरीका, जिसमें PASSWORD_QUALITY_NONE की तुलना में क्वालिटी कॉन्स्टेंट ज़्यादा पाबंदी वाला होता है.

  • PASSWORD_COMPLEXITY_NONE की तुलना में, ज़्यादा पाबंदियों वाले कॉम्प्लेक्सिटी बकेट के साथ DevicePolicyManager.setRequiredPasswordComplexity() तरीका.

• [C-6-3] उपयोगकर्ता को कम से कम हर चार घंटे में एक बार, पुष्टि करने के लिए सुझाए गए मुख्य तरीकों (जैसे कि पिन, पैटर्न या पासवर्ड) में से किसी एक का इस्तेमाल करने के लिए कहा जाना चाहिए. जब कोई फ़िज़िकल टोकन, C-X में TrustAgent लागू करने की ज़रूरी शर्तों को पूरा करता है, तो [C-9-5] में तय की गई समयसीमा से जुड़ी पाबंदियां लागू होती हैं.

• [C-6-4] नए तरीके को सुरक्षित लॉक स्क्रीन के तौर पर नहीं माना जाना चाहिए. साथ ही, इसे नीचे C-8 में दी गई पाबंदियों का पालन करना चाहिए.

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

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

• [C-7-2] DevicePolicyManager क्लास में मौजूद सभी भरोसेमंद एजेंट एपीआई का पालन करना होगा और उन्हें पूरी तरह से लागू करना होगा. जैसे, KEYGUARD_DISABLE_TRUST_AGENTS कॉन्स्टेंट.

• [C-7-3] TrustAgentService.addEscrowToken() फ़ंक्शन को ऐसे डिवाइस पर पूरी तरह से लागू नहीं किया जाना चाहिए जिसका इस्तेमाल मुख्य तौर पर निजी डिवाइस के तौर पर किया जाता है. जैसे, हैंडहेल्ड डिवाइस. हालाँकि, इस फ़ंक्शन को ऐसे डिवाइस पर पूरी तरह से लागू किया जा सकता है जिनका इस्तेमाल आम तौर पर शेयर किया जाता है. जैसे, Android TV या कार में लगा डिवाइस.

• [C-7-4] यह ज़रूरी है कि TrustAgentService.addEscrowToken() से जोड़े गए सभी सेव किए गए टोकन को एन्क्रिप्ट (सुरक्षित) किया जाए.

• [C-7-5] एन्क्रिप्शन की या एस्क्रो टोकन को उस डिवाइस पर सेव नहीं किया जाना चाहिए जिस पर कुंजी का इस्तेमाल किया जाता है. उदाहरण के लिए, फ़ोन में सेव की गई किसी कुंजी का इस्तेमाल करके, टीवी पर किसी उपयोगकर्ता खाते को अनलॉक किया जा सकता है. ऑटोमोटिव डिवाइसों के लिए, एस्क्रो टोकन को वाहन के किसी भी हिस्से में सेव करने की अनुमति नहीं है.

• [C-7-6] डेटा स्टोरेज को डिक्रिप्ट करने के लिए, एस्क्रो टोकन चालू करने से पहले, उपयोगकर्ता को सुरक्षा से जुड़ी समस्याओं के बारे में सूचना देना ज़रूरी है.

• [C-7-7] MUST have a fall-back mechanism to use one of the recommended primary authentication methods.

• [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] Android 16 में इस ज़रूरी शर्त को हटा दिया गया है.

• [C-10-3] Android 16 में इस ज़रूरी शर्त को हटा दिया गया है.

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

• [C-10-5] हर उपयोगकर्ता के लिए, वर्चुअल डिवाइस के अलग-अलग इंस्टेंस होने चाहिए

• [C-10-6] DevicePolicyManager.setNearbyAppStreamingPolicy के मुताबिक, ऐप्लिकेशन स्ट्रीमिंग की सुविधा बंद करना ज़रूरी है.

• [C-10-7] Android 16 में इस ज़रूरी शर्त को हटा दिया गया है.

• [C-10-11] वर्चुअल डिवाइसों पर पुष्टि करने वाले यूज़र इंटरफ़ेस (यूआई) को बंद करना ज़रूरी है. इनमें ये शामिल हैं: जानकारी देने वाले फ़ैक्टर की एंट्री और बायोमेट्रिक प्रॉम्प्ट

• [C-10-12] Android 16 में इस ज़रूरी शर्त को हटा दिया गया है.

• [C-10-13] Android Keystore System के साथ, उपयोगकर्ता की पुष्टि करने के लिए वर्चुअल डिवाइस लॉक की स्थिति का इस्तेमाल नहीं करना चाहिए. KeyGenParameterSpec.Builder.setUserAuthentication* देखें.

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

• [C-10-15] क्लिपबोर्ड के डेटा को ऐक्सेस करने पर, सूचनाएं दिखानी ज़रूरी हैं. ये सूचनाएं, उस डिवाइस पर भी दिखनी चाहिए जिससे डेटा को ऐक्सेस किया गया था और उस डिवाइस पर भी दिखनी चाहिए जिससे क्लिपबोर्ड बनाया गया था.

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

• [C-11-1] सोर्स डिवाइस से टारगेट डिवाइस पर नॉलेज फ़ैक्टर ट्रांसफ़र करते समय, उसे एन्क्रिप्ट (सुरक्षित) करना ज़रूरी है. इसके लिए, Google Cloud Key Vault Service के सुरक्षा वाइटपेपर में बताई गई सुरक्षा सुविधाओं का इस्तेमाल करना होगा. इससे यह पक्का किया जा सकेगा कि नॉलेज फ़ैक्टर को रिमोट तरीके से डिक्रिप्ट न किया जा सके. साथ ही, इसका इस्तेमाल रिमोट तरीके से किसी भी डिवाइस को अनलॉक करने के लिए न किया जा सके.

• [C-11-2] सोर्स डिवाइस पर, टारगेट डिवाइस पर नॉलेज फ़ैक्टर ट्रांसफ़र करने से पहले , उपयोगकर्ता से सोर्स डिवाइस के नॉलेज फ़ैक्टर की पुष्टि करने के लिए कहना ज़रूरी है.

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

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

• [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] की ज़रूरी शर्तों को पूरा करने के लिए, सुरक्षित और सटीक रेंजिंग पर भरोसा करने वाले इंप्लीमेंटेशन को इनमें से किसी एक समाधान का इस्तेमाल करना होगा:

  • यूडब्ल्यूबी का इस्तेमाल करके लागू किए गए सिस्टम:

    • यूडब्ल्यूबी के लिए, 7.4.9 में बताई गई कैलिब्रेशन की ज़रूरी शर्तों के साथ-साथ, पुष्टि, सर्टिफ़िकेशन, और सटीक होने की ज़रूरी शर्तों को पूरा करना होगा.

    • 7.4.9 में दिए गए पी-एसटीएस के सुरक्षा मोड में से किसी एक का इस्तेमाल करना ज़रूरी है.

  • वाई-फ़ाई नेबरहुड अवेयरनेस नेटवर्किंग (एनएएन) का इस्तेमाल करके लागू की गई सुविधाएं:

    • 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 के ज़रिए दिखाया जाने वाला कॉन्टेंट भी शामिल है.

अगर डिवाइस में, 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 की मदद से, ऐप्लिकेशन डेवलपर क्रिप्टोग्राफ़िक कुंजियों को एक खास सुरक्षित प्रोसेसर में सेव कर सकते हैं. साथ ही, ऊपर बताए गए आइसोलेटेड एक्ज़ीक्यूशन एनवायरमेंट में भी सेव कर सकते हैं. इस तरह के सुरक्षित प्रोसेसर को "StrongBox" कहा जाता है. नीचे दी गई 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] इसमें एक अलग सीपीयू होना चाहिए, जो ऐप्लिकेशन प्रोसेसर (एपी) के साथ कैश, DRAM, कोप्रोसेसर या अन्य कोर संसाधनों को शेयर न करता हो.

• [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] इसमें ऐसा हार्डवेयर शामिल होना चाहिए जिसे Secure IC Protection Profile BSI-CC-PP-0084-2014 या BSI-CC-PP-0117-2022 के तहत सर्टिफ़िकेट मिला हो. इसके अलावा, इसे राष्ट्रीय स्तर पर मान्यता प्राप्त टेस्टिंग लैब ने भी जांचा हो. इसमें Common Criteria Application of Attack Potential to Smartcards के मुताबिक, ज़्यादा हमले की आशंका वाली कमज़ोरियों का आकलन शामिल हो.

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

• [C-SR-2] यह सुझाव दिया जाता है कि ऐसे हार्डवेयर को शामिल किया जाए जिसका आकलन, सिक्योरिटी टारगेट और इवैल्यूएशन अश्योरेंस लेवल (ईएएल) 5 का इस्तेमाल करके किया गया हो. साथ ही, एवीए_वीएएन.5 का इस्तेमाल करके उसे बेहतर बनाया गया हो. ऐसा हो सकता है कि आने वाले समय में, EAL 5 सर्टिफ़िकेशन ज़रूरी हो जाए.

• [C-SR-3] को इनसाइडर अटैक से बचाने के लिए, STRONGLY RECOMMENDED किया जाता है. इसका मतलब है कि फ़र्मवेयर पर हस्ताक्षर करने वाली कुंजियों को ऐक्सेस करने वाला कोई इनसाइडर, ऐसा फ़र्मवेयर नहीं बना सकता जिसकी वजह से StrongBox के सीक्रेट लीक हो जाएं. साथ ही, वह फ़ंक्शनल सुरक्षा से जुड़ी ज़रूरी शर्तों को बायपास नहीं कर सकता या किसी अन्य तरीके से, संवेदनशील उपयोगकर्ता डेटा को ऐक्सेस नहीं कर सकता. IAR को लागू करने का सबसे सही तरीका यह है कि फ़र्मवेयर अपडेट की अनुमति सिर्फ़ तब दी जाए, जब प्राइमरी यूज़र का पासवर्ड IAuthSecret HAL के ज़रिए दिया गया हो.

9.11.3. पहचान से जुड़ा क्रेडेंशियल

आइडेंटिटी क्रेडेंशियल सिस्टम को android.security.identity.* पैकेज में मौजूद सभी एपीआई लागू करके तय किया जाता है. इन एपीआई की मदद से, ऐप्लिकेशन डेवलपर को उपयोगकर्ता की पहचान से जुड़े दस्तावेज़ों को सेव करने और उन्हें वापस पाने की अनुमति मिलती है. डिवाइस में सेट किए गए सिस्टम के लिए:

• [C-SR-1] यह सुझाव दिया जाता है कि आइडेंटिटी क्रेडेंशियल सिस्टम लागू किया जाए.

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

• [C-1-1] IdentityCredentialStore#getInstance() तरीके के लिए, शून्य नहीं है वाली वैल्यू रिटर्न होनी चाहिए.

• [C-1-2] Identity Credential System (जैसे, android.security.identity.* API) को लागू करना ज़रूरी है.इसके लिए, कोड को किसी भरोसेमंद ऐप्लिकेशन के साथ कम्यूनिकेट करना होगा. यह कोड, कर्नल और उससे ऊपर के कोड से सुरक्षित तरीके से अलग किया गया हो. सुरक्षित आइसोलेशन को उन सभी संभावित तरीकों को ब्लॉक करना चाहिए जिनसे कर्नेल या यूज़रस्पेस कोड, आइसोलेट किए गए एनवायरमेंट की इंटरनल स्थिति को ऐक्सेस कर सकता है. इसमें डीएमए भी शामिल है.

• [C-1-3] IdentityCredential System को लागू करने के लिए ज़रूरी क्रिप्टोग्राफ़िक ऑपरेशन (जैसे, android.security.identity.* एपीआई) पूरी तरह से भरोसेमंद ऐप्लिकेशन में किए जाने चाहिए. साथ ही, निजी कुंजी के मटीरियल को अलग किए गए एक्ज़ीक्यूशन एनवायरमेंट से कभी भी बाहर नहीं जाना चाहिए. ऐसा तब तक नहीं होना चाहिए, जब तक कि उच्च-स्तरीय एपीआई (जैसे, createEphemeralKeyPair() तरीका) के लिए इसकी खास तौर पर ज़रूरत न हो.

• [C-1-4] भरोसेमंद ऐप्लिकेशन को इस तरह से लागू किया जाना चाहिए कि उसकी सुरक्षा से जुड़ी प्रॉपर्टी पर कोई असर न पड़े. उदाहरण के लिए, क्रेडेंशियल डेटा तब तक रिलीज़ नहीं किया जाना चाहिए, जब तक कि ऐक्सेस कंट्रोल की शर्तें पूरी न हो जाएं. साथ ही, किसी भी डेटा के लिए MAC जनरेट नहीं किए जा सकते. ऐसा तब भी होना चाहिए, जब Android ठीक से काम न कर रहा हो या उसके साथ छेड़छाड़ की गई हो.

अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट, भरोसेमंद ऐप्लिकेशन (libeic) का रेफ़रंस इम्प्लीमेंटेशन उपलब्ध कराता है. इसका इस्तेमाल, Identity Credential सिस्टम को लागू करने के लिए किया जा सकता है.

9.12. डेटा हटाना

डिवाइस में सेट किए गए सभी सिस्टम के लिए:

• [C-0-1] उपयोगकर्ताओं को "फ़ैक्ट्री डेटा रीसेट" करने का तरीका उपलब्ध कराना ज़रूरी है.
• [C-0-2] "फ़ैक्ट्री डेटा रीसेट" करने पर, उपयोगकर्ता के डेटा वाले फ़ाइल सिस्टम से सारा डेटा मिटाना ज़रूरी है.
• [C-0-3] "फ़ैक्ट्री डेटा रीसेट" करते समय, डेटा को इस तरह से मिटाना होगा कि वह NIST SP800-88 जैसे इंडस्ट्री के मानकों के मुताबिक हो.
• [C-0-4] जब मुख्य उपयोगकर्ता का डिवाइस नीति कंट्रोलर ऐप्लिकेशन, DevicePolicyManager.wipeData() API को कॉल करता है, तब ऊपर दी गई "फ़ैक्ट्री डेटा रीसेट" प्रोसेस को ट्रिगर करना ज़रूरी है.
• ऐसा हो सकता है कि यह डिवाइस, डेटा को तेज़ी से मिटाने का विकल्प दे. हालांकि, इससे सिर्फ़ लॉजिकल डेटा मिटाया जाता है.

9.13. सुरक्षित बूट मोड

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

डिवाइस में सेट किए गए सिस्टम के लिए:

• [C-SR-1] सुरक्षित बूट मोड को लागू करने का सुझाव दिया जाता है.

अगर डिवाइस में सेफ़ बूट मोड लागू किया जाता है, तो:

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

• [C-1-2] उपयोगकर्ता को सुरक्षित मोड में, तीसरे पक्ष के किसी भी ऐप्लिकेशन को अनइंस्टॉल करने की सुविधा मिलनी चाहिए.

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

9.14. ऑटोमोटिव वाहन सिस्टम आइसोलेशन

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

डेटा के आदान-प्रदान को सुरक्षित किया जा सकता है. इसके लिए, 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 Virtualization Framework (AVF) API (android.system.virtualmachine.*) की मदद से, ऐप्लिकेशन उपयोगकर्ता के डिवाइस पर वर्चुअल मशीनें (वीएम), सुरक्षित वर्चुअल मशीनें (पीवीएम), और गैर-सुरक्षित वर्चुअल मशीनें (नॉन-पीवीएम) बना सकते हैं. ये मशीनें, नेटिव बाइनरी को पेलोड के तौर पर लोड और रन करती हैं.

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

• [C-1-1] यह पक्का करना ज़रूरी है कि android.system.virtualmachine.VirtualMachineManager.getCapabilities() इनमें से कोई एक वैल्यू दिखाए:
  • CAPABILITY_PROTECTED_VM
  • CAPABILITY_NON_PROTECTED_VM
  • CAPABILITY_NON_PROTECTED_VM | CAPABILITY_PROTECTED_VM

9.18. डेवलपर सत्यापन

एपीआई लेवल 36.1 या इसके बाद के वर्शन का इस्तेमाल करने वाले डिवाइसों के लिए:

• इसमें डेवलपर की पुष्टि करने वाली सेवा के लिए सहायता शामिल हो सकती है, ताकि यह पुष्टि की जा सके कि ऐप्लिकेशन किसी जाने-माने डेवलपर ने बनाए हैं.

एपीआई लेवल 36.1 या इसके बाद के वर्शन का इस्तेमाल करने वाले डिवाइसों के लिए, डेवलपर की पुष्टि करने वाले व्यक्ति को कॉन्फ़िगर करना ज़रूरी है. इसके लिए, config.xml में config_developerVerificationServiceProviderPackageName को तय करें:

• [9.18/C-1-1] हर ऐप्लिकेशन पैकेज इंस्टॉलेशन के लिए, कॉन्फ़िगर किए गए android.content.pm.verify.developer.DeveloperVerifierService को लागू करना ज़रूरी है. इसमें नए इंस्टॉलेशन और मौजूदा ऐप्लिकेशन के अपडेट, दोनों शामिल हैं.

एपीआई लेवल 36.1 या इसके बाद के वर्शन का इस्तेमाल करने वाले डिवाइसों के लिए:

• config_developerVerificationPolicyDelegatePackageName में config_developerVerificationPolicyDelegatePackageName को तय करके, चालू नीति को सेट करने के लिए किसी प्रतिनिधि को भी कॉन्फ़िगर कर सकता है.config.xml

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

• [9.18/C-2-1] डेवलपर की पुष्टि करने वाले व्यक्ति या उसके कॉन्फ़िगर किए गए डेलिगेट को ही, android.content.pm.PackageInstaller में बताई गई इंस्टॉल करने की नीति सेट करने की अनुमति होनी चाहिए.

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

• [9.18/C-3-1] अगर ऐसा होता है, तो ऐप्लिकेशन पैकेज को इंस्टॉल होने से रोकना ज़रूरी है:

  • डेवलपर की पहचान की पुष्टि नहीं हो पाती.

  • इंस्टॉल करने के सेशन के लिए, डेवलपर की पहचान की पुष्टि करने से जुड़ी नीति को DEVELOPER_VERIFICATION_POLICY_NONE के अलावा किसी अन्य वैल्यू पर सेट किया गया हो.

  • जब तक 9.18/C-3-2 या 9.18/C-3-3 लागू न हो.

• [9.18/C-3-3] अगर ये सभी शर्तें पूरी होती हैं, तो किसी ऐप्लिकेशन पैकेज को इंस्टॉल करने से नहीं रोका जाना चाहिए:

  • नीति को DEVELOPER_VERIFICATION_POLICY_BLOCK_FAIL_WARN या DEVELOPER_VERIFICATION_POLICY_BLOCK_FAIL_OPEN पर सेट किया गया हो.

  • पुष्टि की प्रक्रिया पूरी नहीं हुई है.

  • इंस्टॉलर से पता चलता है कि उपयोगकर्ता ने साफ़ तौर पर DEVELOPER_VERIFICATION_USER_RESPONSE_INSTALL_ANYWAY की रिपोर्ट करके, इंस्टॉलेशन जारी रखने का अनुरोध किया है.

10. सॉफ़्टवेयर कंपैटिबिलिटी टेस्टिंग

डिवाइसों को लागू करने के लिए, इस सेक्शन में बताए गए सभी टेस्ट पास करना ज़रूरी है. हालांकि, ध्यान दें कि कोई भी सॉफ़्टवेयर टेस्ट पैकेज पूरी तरह से भरोसेमंद नहीं होता. इस वजह से, डिवाइस बनाने वाली कंपनियों को सख्ती से सलाह दी जाती है कि वे Android Open Source Project से उपलब्ध Android के रेफ़रंस और पसंदीदा वर्शन में कम से कम बदलाव करें. इससे, ऐसी गड़बड़ियां होने का जोखिम कम हो जाएगा जिनकी वजह से, ऐप्लिकेशन ठीक से काम नहीं कर पाएगा. इसके लिए, ऐप्लिकेशन को फिर से बनाना पड़ सकता है और डिवाइस को अपडेट करना पड़ सकता है.

10.1. Compatibility Test Suite

डिवाइस में सेट किए गए सिस्टम के लिए:

• [C-0-1] डिवाइस पर शिपिंग के लिए उपलब्ध फ़ाइनल सॉफ़्टवेयर का इस्तेमाल करके, Android Compatibility Test Suite (CTS) को पास करना ज़रूरी है. यह Android Open Source Project से उपलब्ध है.

• [C-0-2] यह ज़रूरी है कि सीटीएस में अस्पष्टता होने पर, यह रेफ़रंस सोर्स कोड के कुछ हिस्सों को फिर से लागू करने के साथ काम करे.

CTS को किसी असली डिवाइस पर चलाने के लिए डिज़ाइन किया गया है. किसी भी सॉफ़्टवेयर की तरह, सीटीएस में भी गड़बड़ियां हो सकती हैं. सीटीएस का वर्शन, इस कंपैटिबिलिटी डेफ़िनिशन से अलग होगा. साथ ही, Android 17 के लिए सीटीएस के कई वर्शन रिलीज़ किए जा सकते हैं.

डिवाइस में सेट किए गए सिस्टम के लिए:

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

• Android Open Source ट्री में मौजूद रेफ़रंस इंप्लीमेंटेशन का ज़्यादा से ज़्यादा इस्तेमाल करना चाहिए.

10.2. सीटीएस की पुष्टि करने वाला टूल

CTS Verifier, Compatibility Test Suite में शामिल होता है. इसे किसी व्यक्ति को चलाना होता है, ताकि उन सुविधाओं की जांच की जा सके जिनकी जांच ऑटोमेटेड सिस्टम नहीं कर सकता. जैसे, कैमरे और सेंसर का सही तरीके से काम करना.

डिवाइस में सेट किए गए सिस्टम के लिए:

• [C-0-1] CTS verifier में, लागू होने वाले सभी मामलों को सही तरीके से लागू करना ज़रूरी है.

CTS Verifier में कई तरह के हार्डवेयर के लिए टेस्ट मौजूद हैं. इनमें कुछ ऐसे हार्डवेयर भी शामिल हैं जो ज़रूरी नहीं हैं.

डिवाइस में सेट किए गए सिस्टम के लिए:

• [C-0-2] यह ज़रूरी है कि डिवाइस में मौजूद हार्डवेयर के लिए, सभी टेस्ट पास किए जाएं. उदाहरण के लिए, अगर किसी डिवाइस में एक्सलरोमीटर है, तो यह ज़रूरी है कि वह CTS Verifier में एक्सलरोमीटर टेस्ट केस को सही तरीके से पूरा करे.

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

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

11. अपडेट किया जा सकने वाला सॉफ़्टवेयर

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

  • "ओवर-द-एयर (ओटीए)" डाउनलोड की सुविधा. इसके तहत, रीबूट करके ऑफ़लाइन अपडेट किया जा सकता है.
  • होस्ट पीसी से यूएसबी के ज़रिए "टेथर्ड" अपडेट.
  • "ऑफ़लाइन" अपडेट, रीबूट करके और हटाने लायक स्टोरेज डिवाइस पर मौजूद फ़ाइल से अपडेट करके किए जाते हैं.

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

• [C-0-3] पूरे अपडेट पर हस्ताक्षर होना ज़रूरी है. साथ ही, उपयोगकर्ता के डिवाइस पर अपडेट करने वाले सिस्टम को, डिवाइस पर सेव की गई सार्वजनिक कुंजी के हिसाब से अपडेट और हस्ताक्षर की पुष्टि करनी होगी.

• [C-SR-1] साइनिंग मैकेनिज़्म को SHA-256 की मदद से अपडेट को हैश करने का सुझाव दिया जाता है. साथ ही, ECDSA NIST P-256 का इस्तेमाल करके, सार्वजनिक पासकोड के ख़िलाफ़ हैश की पुष्टि करने का सुझाव दिया जाता है.

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

• [C-1-1] में, रीबूट करके ऑफ़लाइन अपडेट करने के साथ-साथ, ओटीए डाउनलोड करने की सुविधा होनी चाहिए.

डिवाइसों को यह पुष्टि करनी चाहिए कि ओटीए के बाद, सिस्टम इमेज बाइनरी के तौर पर, अनुमानित नतीजे के जैसी ही है. अपस्ट्रीम Android Open Source Project में ब्लॉक-आधारित OTA लागू करने की सुविधा, Android 5.1 के बाद से जोड़ी गई है. यह सुविधा इस ज़रूरी शर्त को पूरा करती है.

साथ ही, डिवाइसों में A/B सिस्टम अपडेट की सुविधा होनी चाहिए. AOSP, बूट कंट्रोल HAL का इस्तेमाल करके इस सुविधा को लागू करता है.

अगर किसी डिवाइस के रिलीज़ होने के बाद, उसके लागू करने में कोई गड़बड़ी मिलती है, लेकिन वह गड़बड़ी प्रॉडक्ट के जीवनकाल के दौरान मिलती है. यह जीवनकाल, Android Compatibility Team के साथ सलाह-मशवरा करके तय किया जाता है. इस गड़बड़ी से तीसरे पक्ष के ऐप्लिकेशन की संगतता पर असर पड़ता है. ऐसे में:

• [C-2-1] डिवाइस बनाने वाली कंपनी को, सॉफ़्टवेयर अपडेट के ज़रिए गड़बड़ी को ठीक करना होगा. यह अपडेट, ऊपर बताए गए तरीके के मुताबिक लागू किया जा सकता है.

Android में ऐसी सुविधाएं शामिल होती हैं जिनकी मदद से, डिवाइस के मालिक के ऐप्लिकेशन (अगर मौजूद है) को सिस्टम अपडेट इंस्टॉल करने की सुविधा मिलती है. अगर डिवाइसों के लिए सिस्टम अपडेट सबसिस्टम, android.software.device_admin की रिपोर्ट करता है, तो:

• [C-3-1] SystemUpdatePolicy क्लास में बताए गए व्यवहार को लागू करना ज़रूरी है.

12. दस्तावेज़ में हुए बदलावों का लॉग

Android 16 से, अलग से कोई बदलाव लॉग नहीं रखा जाता. पिछले वर्शन में किए गए सभी बदलावों को इस दस्तावेज़ में हाइलाइट किया गया है.

13. हमसे संपर्क करें

Android के साथ काम करने वाले डिवाइसों के फ़ोरम में शामिल होकर, साफ़ तौर पर जानकारी देने का अनुरोध किया जा सकता है. इसके अलावा, ऐसी किसी भी समस्या के बारे में बताया जा सकता है जिसके बारे में दस्तावेज़ में जानकारी नहीं दी गई है.