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. ज़रूरी शर्त का आईडी

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

• आईडी सिर्फ़ 'ज़रूरी है' शर्तों के लिए असाइन किया जाता है.
• STRONGLY RECOMMENDED के तौर पर मार्क की गई ज़रूरी शर्तों को [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 में मौजूद ज़रूरी शर्तों के आईडी के दो हिस्से होते हैं. पहला सेक्शन आईडी है, जैसा कि ऊपर बताया गया है. दूसरे हिस्से से, डिवाइस के साइज़, डाइमेंशन या कॉन्फ़िगरेशन और उससे जुड़ी ज़रूरी शर्तों के बारे में पता चलता है.

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

• सेक्शन 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 एमबी होनी चाहिए.

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

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

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

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

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

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

• [7.6.1/H-8-1] अगर डिफ़ॉल्ट डिसप्ले, क्यूएचडी (जैसे, क्यूडब्ल्यूएक्सजीए) तक के फ़्रेमबफ़र रिज़ॉल्यूशन का इस्तेमाल करता है, तो कर्नेल और यूज़रस्पेस के लिए उपलब्ध मेमोरी कम से कम 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] इंटेंट ACTION_HEADSET_PLUG को ब्रॉडकास्ट करना ज़रूरी है. साथ ही, "microphone" एक्स्ट्रा को 0 पर सेट करना ज़रूरी है.

यूएसबी ऑडियो टर्मिनल टाइप 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] ऐक्चुएटर को उस जगह के पास रखना चाहिए जहां आम तौर पर डिवाइस को हाथों से पकड़ा या छुआ जाता है.

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

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

• [7.10/H] एक्स-ऐक्सिस एलआरए की रेज़ोनेंट फ़्रीक्वेंसी 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 AVC
• [5.3/H-0-2] H.265 HEVC
• [5.3/H-0-3] MPEG-4 SP
• [5.3/H-0-4] VP8
• [5.3/H-0-5] VP9
• [5.3/H-0-6] AV1

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

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

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

• [9.11/H-0-4] लॉक स्क्रीन पर पुष्टि करने की प्रोसेस, आइसोलेटेड एक्ज़ीक्यूशन एनवायरमेंट में पूरी होनी चाहिए. साथ ही, पुष्टि होने के बाद ही, पुष्टि से जुड़ी कुंजियों का इस्तेमाल करने की अनुमति दी जानी चाहिए. लॉक स्क्रीन के क्रेडेंशियल को इस तरह से सेव किया जाना चाहिए कि सिर्फ़ आइसोलेटेड एक्ज़ीक्यूशन एनवायरमेंट, लॉक स्क्रीन की पुष्टि कर सके. अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट, 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 एपीआई के ज़रिए सिस्टम सर्वर को या ContentCaptureManager एपीआई के ज़रिए ContentCaptureService को माइक का ऑडियो डेटा या उससे मिला डेटा ट्रांसमिट कर सकती हो.

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

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

• [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] मेन प्रोफ़ाइल लेवल 4.1 के साथ, हर सेकंड में 60 फ़्रेम पर एचडी 1080 पिक्सल

अगर 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] डिवाइस को उस पिक्सल फ़ॉर्मैट के लिए, HDMI आउटपुट मोड को सबसे ज़्यादा रिज़ॉल्यूशन पर सेट करना ज़रूरी है जो बाहरी डिसप्ले के लिए 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 Television 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 ओपन सोर्स प्रोजेक्ट, 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 को डिफ़ॉल्ट के तौर पर अनुमति न दी जाए.

अगर Watch डिवाइसों पर कई उपयोगकर्ता हैं और उन्होंने 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 डिवाइस में सेट किए हुए सिस्टम में 3-ऐक्सिस से कम वाला जाइरोस्कोप शामिल है, तो:

• [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] ऐप्लिकेशन में खोज करने की सुविधा देने वाले ऐप्लिकेशन के लिए, ऐप्लिकेशन में खोज करने की सुविधा उपलब्ध होनी चाहिए.

• [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 ओपन सोर्स प्रोजेक्ट, 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 कॉन्फ़िगरेशन स्वीकार करना चाहिए जो परफ़ेक्टो के दस्तावेज़ में तय किए गए स्कीमा के मुताबिक हो.

  • [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] 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. सॉफ़्टवेयर

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] डिवाइस में, शेयर की गई लाइब्रेरी ExtShared और सेवाओं ExtServices के AOSP वर्शन को प्रीलोड करना ज़रूरी है. इनका वर्शन, हर एपीआई लेवल के लिए अनुमति वाले कम से कम वर्शन से ज़्यादा या उसके बराबर होना चाहिए. उदाहरण के लिए, Android 7.0 डिवाइसों पर एपीआई लेवल 24 का इस्तेमाल किया जाता है. इसलिए, इनमें कम से कम वर्शन 1 शामिल होना चाहिए.

• [C-0-2] सिर्फ़ एक्सटेंशन के मान्य वर्शन नंबर को वापस लाना ज़रूरी है. ये वर्शन नंबर, AOSP ने तय किए हों.

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

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

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

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

AOSP के ज़रिए लागू किए गए इस फ़ीचर में, इन ज़रूरी शर्तों को पूरा किया जाता है.

3.2. सॉफ़्ट एपीआई कंपैटिबिलिटी

सेक्शन 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 Intent API लागू करने होंगे.

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

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

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

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

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

• [C-12-3] एसडीके दस्तावेज़ में बताए गए तरीके से, इन इंटेंट को मैनेज करना ज़रूरी है. साथ ही, सिर्फ़ पहले से इंस्टॉल किए गए 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 Open Source Project से, यहां दी गई लाइब्रेरी के वर्शन का इस्तेमाल करें.

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 library)
  • 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] NDK में तय किए गए सभी 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 एबीआई के साथ काम करते हैं, तो इस एबीआई का इस्तेमाल करने वाले ऐप्लिकेशन के लिए:

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

  • Features:, इसके बाद डिवाइस पर काम करने वाली ARMv7 सीपीयू की किसी भी वैकल्पिक सुविधा की सूची.
  • CPU architecture: के बाद, एक पूर्णांक होता है.यह पूर्णांक, डिवाइस के सबसे नए ARM आर्किटेक्चर के बारे में बताता है. उदाहरण के लिए, 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] इसमें HTML5/W3C webstorage API काम करना चाहिए और 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() मैथड को true वैल्यू दिखानी चाहिए.

• [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] यह एनडीके लाइब्रेरी या किसी अन्य संगठन की लाइब्रेरी में नहीं होना चाहिए. इसके बारे में यहां बताया गया है.

अगर डिवाइस बनाने वाली कंपनी, ऊपर दिए गए किसी पैकेज नेमस्पेस को बेहतर बनाने का सुझाव देती है (जैसे कि किसी मौजूदा एपीआई में काम की नई सुविधा जोड़ना या नया एपीआई जोड़ना), तो उसे 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 डीपीआई (mdpi)
	180 डीपीआई (180dpi)
	200 डीपीआई (200dpi)
	213 डीपीआई (टीवीडीपीआई)
	220 डीपीआई (220dpi)	36 एमबी
	240 डीपीआई (hdpi)
	280 डीपीआई (280dpi)
	320 डीपीआई (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 डीपीआई (mdpi)
	180 डीपीआई (180dpi)	48 एमबी
	200 डीपीआई (200dpi)
	213 डीपीआई (टीवीडीपीआई)
	220 डीपीआई (220dpi)
	240 डीपीआई (hdpi)
	280 डीपीआई (280dpi)
	320 डीपीआई (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 डीपीआई (mdpi)
	180 डीपीआई (180dpi)	80MB
	200 डीपीआई (200dpi)
	213 डीपीआई (टीवीडीपीआई)
	220 डीपीआई (220dpi)
	240 डीपीआई (hdpi)
	280 डीपीआई (280dpi)	96 एमबी
	320 डीपीआई (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 डीपीआई (mdpi)
	180 डीपीआई (180dpi)	96 एमबी
	200 डीपीआई (200dpi)
	213 डीपीआई (टीवीडीपीआई)
	220 डीपीआई (220dpi)
	240 डीपीआई (hdpi)
	280 डीपीआई (280dpi)	144MB
	320 डीपीआई (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> टैग का इस्तेमाल करके आइकॉन उपलब्ध कराने पर, AdaptiveIconDrawable ऑब्जेक्ट को वापस भेजना ज़रूरी है. साथ ही, आइकॉन वापस पाने के लिए PackageManager तरीकों को कॉल किया जाता है.

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

• [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 एपीआई क्लास में बताए गए तरीके से, स्क्रीन पर सबसे ऊपर सूचना देने वाले कार्ड और संसाधनों का इस्तेमाल करना ज़रूरी है.

• [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 में Assist API शामिल हैं. इनकी मदद से, ऐप्लिकेशन यह तय कर सकते हैं कि डिवाइस पर मौजूद Assistant के साथ मौजूदा कॉन्टेक्स्ट की कितनी जानकारी शेयर की जाए.

• [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] Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES के AOSP दस्तावेज़ में बताए गए तरीके के मुताबिक, डाइनैमिक कलर टोनल पैलेट जनरेट करने ज़रूरी हैं (android.theme.customization.system_palette और android.theme.customization.theme_style देखें).

• [C-1-5] Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES दस्तावेज़ में दिए गए रंग वाली थीम स्टाइल का इस्तेमाल करके, डाइनैमिक कलर टोनल पैलेट जनरेट करना ज़रूरी है. android.theme.customization.theme_styles देखें. ये स्टाइल हैं: TONAL_SPOT, VIBRANT, EXPRESSIVE, SPRITZ, RAINBOW, FRUIT_SALAD, और MONOCHROMATIC.

  "सोर्स कलर" का इस्तेमाल, डाइनैमिक कलर टोनल पैलेट जनरेट करने के लिए किया जाता है. ऐसा तब होता है, जब इसे android.theme.customization.system_palette के साथ भेजा जाता है. इसके बारे में Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES में बताया गया है.

• [C-1-6] में CAM16 क्रोमा वैल्यू 5 या इससे ज़्यादा होनी चाहिए.

  • इसे com.android.systemui.monet.ColorScheme#getSeedColors के ज़रिए वॉलपेपर से लिया जाना चाहिए. इससे चुनने के लिए, कई मान्य सोर्स कलर मिलते हैं.

  • अगर दिए गए किसी भी रंग से, सोर्स कलर की ऊपर दी गई ज़रूरी शर्तें पूरी नहीं होती हैं, तो 0xFF1B6EF3 वैल्यू का इस्तेमाल करना चाहिए.

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

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

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

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

• [C-2-1] सिस्टम के स्टेटस आइकॉन (जैसे कि सिग्नल की ताकत और बैटरी लेवल) और सिस्टम से जारी की गई सूचनाओं के लिए, सफ़ेद रंग का इस्तेमाल करना ज़रूरी है. हालांकि, अगर आइकॉन किसी समस्या वाली स्थिति के बारे में बता रहा है या कोई ऐप्लिकेशन WindowInsetsController#APPEARANCE_LIGHT_STATUS_BARS फ़्लैग का इस्तेमाल करके, हल्के रंग वाले स्टेटस बार का अनुरोध करता है, तो ऐसा नहीं करना होगा.

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

3.8.7. लाइव वॉलपेपर

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

किसी डिवाइस के हार्डवेयर को लाइव वॉलपेपर चलाने के लिए तब सही माना जाता है, जब वह सभी लाइव वॉलपेपर को बिना किसी समस्या के चला सके. साथ ही, ऐसा करने पर डिवाइस के अन्य ऐप्लिकेशन पर कोई बुरा असर न पड़े और फ़्रेम रेट भी सही हो. अगर हार्डवेयर की सीमाओं की वजह से वॉलपेपर और/या ऐप्लिकेशन क्रैश हो जाते हैं, ठीक से काम नहीं करते हैं, बहुत ज़्यादा सीपीयू या बैटरी की खपत करते हैं या बहुत कम फ़्रेम रेट पर चलते हैं, तो हार्डवेयर को लाइव वॉलपेपर चलाने में सक्षम नहीं माना जाता है. उदाहरण के लिए, कुछ लाइव वॉलपेपर, कॉन्टेंट को रेंडर करने के लिए OpenGL 2.0 या 3.x कॉन्टेक्स्ट का इस्तेमाल कर सकते हैं. लाइव वॉलपेपर, ऐसे हार्डवेयर पर ठीक से काम नहीं करेगा जो एक से ज़्यादा OpenGL कॉन्टेक्स्ट के साथ काम नहीं करता. ऐसा इसलिए, क्योंकि लाइव वॉलपेपर के लिए OpenGL कॉन्टेक्स्ट का इस्तेमाल, OpenGL कॉन्टेक्स्ट का इस्तेमाल करने वाले अन्य ऐप्लिकेशन के साथ टकराव कर सकता है.

• ऊपर बताए गए तरीके से लाइव वॉलपेपर को भरोसेमंद तरीके से चलाने में सक्षम डिवाइसों को, लाइव वॉलपेपर की सुविधा लागू करनी चाहिए.

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

• [C-1-1] प्लैटफ़ॉर्म के फ़ीचर फ़्लैग android.software.live_wallpaper के बारे में बताना ज़रूरी है.

3.8.8. गतिविधि स्विच करना

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

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

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

• [C-1-1] कम से कम सात ऐक्टिविटी दिखाने की सुविधा होनी चाहिए.

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

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

• बंद करने का विकल्प ("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 का पूरा कवरेज. इसमें लैटिन एक्सटेंडेड A, B, C, और D रेंज के साथ-साथ, 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 डीपी से कम नहीं होना चाहिए. हालांकि, यह नियम पिक्चर-इन-पिक्चर मोड पर लागू नहीं होता.

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

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

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

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

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

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

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

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

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

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

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

• [C-3-5] ऐप्लिकेशन को पीआईपी मोड में दिखने से रोकने के लिए, उपयोगकर्ता को एक विकल्प देना होगा. AOSP में, सूचना पैनल में कंट्रोल मौजूद होते हैं. इसलिए, 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 API के सही एपीआई लेवल को लागू करना ज़रूरी है.

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 कॉन्टेंट कैप्चर और ऐप्लिकेशन खोज में बताई गई सेवाओं के लिए ऐसा किया जा सकता है.

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

• डिवाइस बनाने वाली कंपनी को, उपयोगकर्ता को हर ऐप्लिकेशन के लिए, अज्ञात सोर्स से ऐप्लिकेशन इंस्टॉल करने की अनुमति देने या रद्द करने का विकल्प देना चाहिए. हालांकि, अगर डिवाइस बनाने वाली कंपनी उपयोगकर्ताओं को यह विकल्प नहीं देना चाहती है, तो वह इसे नो-ऑप के तौर पर लागू कर सकती है और RESULT_CANCELED को startActivityForResult() के लिए दिखा सकती है. हालांकि, ऐसे मामलों में भी उन्हें उपयोगकर्ता को यह बताना चाहिए कि इस तरह का विकल्प क्यों नहीं दिया गया है.

• [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 प्रोफ़ाइल डिकोडर:

• ISO/IEC 23003-4 डाइनैमिक रेंज कंट्रोल प्रोफ़ाइल का इस्तेमाल करके, आवाज़ और डाइनैमिक रेंज कंट्रोल की सुविधा काम कर सकती है.

अगर ISO/IEC 23003-4 काम करता है और डिकोड किए गए बिटस्ट्रीम में ISO/IEC 23003-4 और ISO/IEC 14496-3, दोनों मेटाडेटा मौजूद हैं, तो:

• ISO/IEC 23003-4 मेटाडेटा को प्राथमिकता दी जाएगी.

सभी ऑडियो डिकोडर में, ये आउटपुट देने की सुविधा होनी चाहिए:

• [C-6-1] android.media.MediaCodec एपीआई के ज़रिए, पीसीएम 16-बिट नेटिव बाइट ऑर्डर वाले ऑडियो फ़्रेम.

अगर डिवाइस में, android.media.MediaCodec एपीआई में मौजूद डिफ़ॉल्ट AAC ऑडियो डिकोडर के ज़रिए, मल्टीचैनल स्ट्रीम (यानी कि दो से ज़्यादा चैनल) के AAC इनपुट बफ़र को पीसीएम में डिकोड करने की सुविधा है, तो इन सुविधाओं का होना ज़रूरी है:

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

• [C-7-2] डिकोड करते समय, डिकोडर को KEY_CHANNEL_MASK कुंजी के साथ आउटपुट फ़ॉर्मैट पर इस्तेमाल किए जा रहे चैनल मास्क का विज्ञापन करना होगा. इसके लिए, android.media.AudioFormat कॉन्स्टेंट का इस्तेमाल करना होगा (उदाहरण: CHANNEL_OUT_5POINT1).

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

• [C-SR-2] डिकोडर को ऐप्लिकेशन के ज़रिए कॉन्फ़िगर किया जा सकता है. इसके लिए, डिकोडिंग के साथ KEY_MAX_OUTPUT_CHANNEL_COUNT कुंजी का इस्तेमाल किया जाता है. इससे यह कंट्रोल किया जा सकता है कि कॉन्टेंट को स्टीरियो में डाउनमिक्स किया जाए (जब वैल्यू 2 का इस्तेमाल किया जा रहा हो) या चैनलों की मूल संख्या का इस्तेमाल करके आउटपुट किया जाए (जब वैल्यू उस संख्या के बराबर या उससे ज़्यादा हो). इसलिए, डिकोडर को ऐप्लिकेशन के ज़रिए कॉन्फ़िगर करने का सुझाव दिया जाता है. उदाहरण के लिए, 6 या इससे ज़्यादा वैल्यू होने पर, डिकोडर को 5.1 कॉन्टेंट देने पर, वह 6 चैनल आउटपुट करेगा.

• [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 एपीआई (या दोनों) के ज़रिए मीडिया कोडेक के लिए सहायता उपलब्ध करानी होगी. साथ ही, सुरक्षा उपायों को बंद या नाकाम नहीं करना होगा. इसका मतलब यह नहीं है कि हर कोडेक को 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 एपीआई में दी गई है. हालांकि, अगर कोई स्टैंडर्ड परफ़ॉर्मेंस पॉइंट किसी दूसरे स्टैंडर्ड परफ़ॉर्मेंस पॉइंट के दायरे में आता है, तो उसे सूची में शामिल करने की ज़रूरत नहीं है.

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

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 एमबीपीएस

अगर डिवाइस में सेट किए गए सिस्टम, मीडिया एपीआई के ज़रिए प्रोफ़ाइल 2 या प्रोफ़ाइल 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() API के ज़रिए परफ़ॉर्मेंस डेटा रिपोर्ट करना ज़रूरी है.

• [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' (HDR10Plus प्रोफ़ाइलों के लिए). साथ ही, यह भी ज़रूरी है कि वे बिटस्ट्रीम और/या कंटेनर से ज़रूरी एचडीआर मेटाडेटा को निकाल सकें और उसे आउटपुट कर सकें.
• [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 डीबी.

• ऑडियो इनपुट की सेंसिटिविटी को इस तरह से सेट किया जाना चाहिए कि 90 dB के साउंड प्रेशर लेवल (एसपीएल) पर 1000 हर्ट्ज़ का साइनसोडल टोन सोर्स (माइक्रोफ़ोन के बगल में मेज़र किया गया) चलाने पर, 16 बिट-सैंपल के लिए 1770 और 3530 की रेंज में आरएमएस 2500 का सही जवाब मिले. इसके अलावा, फ़्लोटिंग पॉइंट/डबल प्रिसिशन सैंपल के लिए -22.35 db ±3dB फ़ुल स्केल का सही जवाब मिले. यह जवाब, आवाज़ की पहचान करने वाले ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन के लिए होना चाहिए.

• आवाज़ पहचानने की सुविधा के लिए ऑडियो स्ट्रीम रिकॉर्ड की जानी चाहिए, ताकि पीसीएम ऐम्प्लिट्यूड लेवल, माइक्रोफ़ोन पर इनपुट एसपीएल में होने वाले बदलावों को कम से कम 30 dB की रेंज में लीनियर तरीके से ट्रैक कर सके. यह रेंज -18 dB से +12 dB re 90 dB एसपीएल तक होनी चाहिए.

• आवाज़ पहचानने की सुविधा के लिए, ऑडियो स्ट्रीम को रिकॉर्ड करना चाहिए. इसमें टोटल हार्मोनिक डिस्टॉर्शन (टीएचडी) 1% से कम होना चाहिए. यह 1 किलोहर्ट्ज़ पर 90 dB एसपीएल इनपुट लेवल पर माइक्रोफ़ोन पर होना चाहिए.

अगर डिवाइस लागू करने वाले लोग, बोली की पहचान के लिए ट्यून की गई android.hardware.microphone और नॉइज़ कैंसलेशन (कम करने) की टेक्नोलॉजी के बारे में बताते हैं, तो:

• [C-2-1] इस ऑडियो इफ़ेक्ट को android.media.audiofx.NoiseSuppressor एपीआई से कंट्रोल किया जा सकता है.
• [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. ऑडियो सिग्नल में कुछ समय के लिए रुकावट या गलत सैंपल वैल्यू. आम तौर पर, यह आउटपुट के लिए बफ़र अंडररन, इनपुट के लिए बफ़र ओवररन या डिजिटल या ऐनलॉग नॉइज़ के किसी अन्य सोर्स की वजह से होता है.

• औसत कुल डेविएशन (एमएडी). यह वैल्यू के सेट के लिए, औसत से विचलन की ऐब्सलूट वैल्यू का औसत होती है.

• टैप-टू-टोन लेटेंसी (टीटीएल) को सीटीएस वेरिफ़ायर से मेज़र किया जाता है. यह वह समय होता है जब स्क्रीन पर टैप किया जाता है और उस टैप के नतीजे के तौर पर जनरेट की गई टोन स्पीकर पर सुनाई देती है. यह औसत, आउटपुट के लिए 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 से मिले इनपुट और आउटपुट टाइमस्टैंप के आधार पर कैलकुलेट की गई दोतरफ़ा यात्रा लेटेंसी, AAUDIO_PERFORMANCE_MODE_NONEAAUDIO_PERFORMANCE_MODE_LOW_LATENCY स्पीकर, वायर्ड हेडसेट, और वायरलेस हेडसेट के लिए मेज़र की गई दोतरफ़ा यात्रा लेटेंसी के 200 मि॰से॰ के अंदर होनी चाहिए.

• [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. Secure Media

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

• [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 शेल कमांड को लागू करना ज़रूरी है, ताकि 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 dp x 720 dp होना चाहिए.

• [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] टेस्ट सूचियों में, 132317953 वर्शन और android.software.vulkan.deqp.level फ़ीचर फ़्लैग में बताए गए वर्शन के बीच, सभी Vulkan dEQP टेस्ट पास करना ज़रूरी है.

• [C-1-11] VK_KHR_video_queue, VK_KHR_video_decode_queue या VK_KHR_video_encode_queue एक्सटेंशन के लिए, सहायता की सूची नहीं बनानी चाहिए.

• [C-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. कीबोर्ड

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

• [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] टीवी डिवाइस पर लागू होने वाले ACTION=MAIN और CATEGORY=LAUNCHER या CATEGORY=LEANBACK_LAUNCHER के साथ सेट किए गए <intent-filter> वाली गतिविधि वाले इंस्टॉल किए गए ऐप्लिकेशन लॉन्च करने के लिए, उपयोगकर्ता को सुविधा देनी होगी. उपयोगकर्ता को यह सुविधा देने के लिए, होम फ़ंक्शन का इस्तेमाल किया जाना चाहिए.
• इसमें हाल ही के और वापस जाने के फ़ंक्शन के लिए बटन होने चाहिए.

अगर होम, हाल ही के या वापस जाएँ फ़ंक्शन उपलब्ध कराए जाते हैं, तो:

• [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] इसमें उपयोगकर्ताओं को स्क्रीन पर मौजूद बटन के ज़रिए नेविगेशन की सुविधा उपलब्ध होनी चाहिए. उदाहरण के लिए, सेटिंग में.
• स्क्रीन के मौजूदा ओरिएंटेशन के हिसाब से, सबसे नीचे के किनारे से ऊपर की ओर स्वाइप करने पर, होम फ़ंक्शन चालू होना चाहिए.
• SHOULD provide Recents function as a swipe up and hold before release, from the same area as the Home gesture.
• 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 की तरह ही क्वालिटी की ज़रूरी शर्तों को पूरा करने वाला TYPE_GYROSCOPE_UNCALIBRATED होना चाहिए.

• [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] यह सुझाव दिया जाता है कि स्पूफ़िंग और धोखाधड़ी से पुष्टि कराने की कोशिशों को स्वीकार करने की दर, Android Biometrics Test Protocols के मुताबिक, हर तरह के प्रेजेंटेशन अटैक इंस्ट्रूमेंट (पीएआई) के लिए 7% से ज़्यादा न हो.

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

• [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 की तरह ही है. हालांकि, इसमें P-STS सुरक्षा मोड चालू होता है.

  • CONFIG_ID_5: यह CONFIG_ID_2 की तरह ही है. हालांकि, इसमें P-STS सुरक्षा मोड चालू होता है.

  • 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] पूरे एपीआई को नो-ऑप्स के तौर पर लागू करना ज़रूरी है.

अगर डिवाइस में eUICC या eSIM/एम्बेड किए गए सिम कार्ड की सुविधा काम करती है और इसमें तीसरे पक्ष के डेवलपर के लिए, eSIM की सुविधा उपलब्ध कराने का मालिकाना हक वाला तरीका शामिल है, तो:

• [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 और आरसीएस, दोनों के लिए ImsService API को पूरी तरह से लागू करना ज़रूरी है. इसके अलावा, User Capability Exchange 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] SDK टूल के दस्तावेज़ में बताए गए तरीके के मुताबिक, 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 के लिए, एमएसी पता बदला गया होना चाहिए और वही बना रहना चाहिए.

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

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

• जब कोई ऐप्लिकेशन, WifiManager.createWifiLock() और WifiManager.WifiLock.acquire() एपीआई के ज़रिए WIFI_MODE_FULL_HIGH_PERF लॉक या WIFI_MODE_FULL_LOW_LATENCY लॉक हासिल करता है और लॉक चालू होता है, तो उसे वाई-फ़ाई के पावर सेव मोड को बंद कर देना चाहिए.

• [C-3-2] जब डिवाइस, वाई-फ़ाई लो लेटेंसी लॉक (WIFI_MODE_FULL_LOW_LATENCY) मोड में हो, तब डिवाइस और ऐक्सेस पॉइंट के बीच राउंड ट्रिप की औसत लेटेंसी, वाई-फ़ाई हाई परफ़ लॉक (WIFI_MODE_FULL_HIGH_PERF) मोड के दौरान होने वाली लेटेंसी से कम होनी चाहिए.

• [C-SR-3] जब भी कम समय में लॉक होने की सुविधा (WIFI_MODE_FULL_LOW_LATENCY) चालू होती है और लागू होती है, तब वाई-फ़ाई राउंड ट्रिप में लगने वाले समय को कम करने का सुझाव दिया जाता है.

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

• [C-2-1] उपयोगकर्ता को WifiManager.isScanAlwaysAvailable एपीआई तरीके से पढ़ी गई वैल्यू को चालू/बंद करने का विकल्प देना ज़रूरी है.

7.4.2.1. Wi-Fi Direct

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

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

अगर डिवाइस में वाई-फ़ाई डायरेक्ट की सुविधा काम करती है, तो:

• [C-1-1] एसडीके के दस्तावेज़ में बताए गए तरीके के मुताबिक, Android API को लागू करना ज़रूरी है.

• [C-1-2] हार्डवेयर की सुविधा android.hardware.wifi.direct के बारे में जानकारी देना ज़रूरी है.

• [C-1-3] यह ज़रूरी है कि यह डिवाइस, वाई-फ़ाई की सामान्य सुविधा के साथ काम करता हो.

• [C-1-4] यह ज़रूरी है कि डिवाइस, वाई-फ़ाई और वाई-फ़ाई डायरेक्ट की सुविधाओं को एक साथ इस्तेमाल करने की अनुमति देता हो.

• [C-SR-1] सभी नए Wi-Fi Direct कनेक्शन के लिए, डिवाइस का एमएसी पता बदलते रहने का सुझाव दिया जाता है.

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] यह ज़रूरी है कि डिवाइस में, वाई-फ़ाई और वाई-फ़ाई अवेयर की सुविधाएं एक साथ काम करती हों.

• [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वें पर्सेंटाइल पर इसकी सटीक दूरी दो मीटर के अंदर होनी चाहिए. इसकी गणना, संचयी बंटन फ़ंक्शन के हिसाब से की जाती है.

• [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] सिस्टम एपीआई 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] इसमें NFC Forum के रीडर/राइटर के तौर पर काम करने की सुविधा होनी चाहिए. इसके लिए, NFC Forum के तकनीकी स्पेसिफ़िकेशन NFCForum-TS-DigitalProtocol-1.0 में बताए गए इन NFC स्टैंडर्ड का इस्तेमाल किया जाना चाहिए:

  • 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] यह ज़रूरी है कि डिवाइस, डोज़ मोड में होने पर भी आईपीवी6 से कनेक्ट रहे.

• [C-0-5] रेट-लिमिटिंग की वजह से, डिवाइस को IPv6 कनेक्टिविटी नहीं खोनी चाहिए. ऐसा किसी भी IPv6 के साथ काम करने वाले नेटवर्क पर नहीं होना चाहिए. इस नेटवर्क में RA लाइफ़टाइम कम से कम 180 सेकंड का होना चाहिए.

• [C-0-6] जब डिवाइस IPv6 नेटवर्क से कनेक्ट हो, तो तीसरे पक्ष के ऐप्लिकेशन को नेटवर्क से सीधे IPv6 कनेक्टिविटी देनी होगी. साथ ही, डिवाइस पर स्थानीय तौर पर किसी भी तरह का पता या पोर्ट ट्रांसलेशन नहीं होना चाहिए. मैनेज किए गए एपीआई, जैसे कि 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] यह पक्का करना ज़रूरी है कि दूरी मेज़र करने के लिए, +/-15 cm की सीमा में 95% मेज़रमेंट किए गए हों. इसके लिए, बिना रिफ़्लेक्टिव चेंबर में 1 मीटर की दूरी पर, लाइन ऑफ़ साइट एनवायरमेंट में मेज़रमेंट किए गए हों.

• [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] MUST implement such a camera API using android.hardware.camera2 API.

• वेंडर, 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 की रिपोर्ट देनी चाहिए.
• 'MTP' के यूएसबी इंटरफ़ेस का नाम रिपोर्ट करना चाहिए.

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 कॉन्स्टेंट के साथ मैप करने की सुविधा होनी चाहिए. ये डेटा फ़ील्ड यहां दिए गए हैं:
  • इस्तेमाल से जुड़ा पेज (0xC) इस्तेमाल का आईडी (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 का इस्तेमाल करने का सुझाव दिया जाता है.
  • यूएसबी सुपरस्पीड डेटा ट्रांसफ़र करने की सुविधा होनी चाहिए.
  • डेटा और पावर रोल स्वैपिंग के लिए, Power Delivery की सुविधा के साथ काम करने वाले केबल इस्तेमाल करने का सुझाव दिया जाता है.
• [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 डीबी से ज़्यादा कम नहीं होना चाहिए.
• [C-1-2] 18.5 किलोहर्ट्ज़ से 20 किलोहर्ट्ज़ की फ़्रीक्वेंसी वाले माइक्रोफ़ोन के अनवेटेड सिग्नल से नॉइज़ का अनुपात, -26 dBFS पर 19 किलोहर्ट्ज़ टोन के लिए 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] कम से कम 30 एफ़पीएस पर 3840 x 2160 के 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] VR मोड में, डिसप्ले कम से कम 60 हर्ट्ज़ पर अपडेट होना चाहिए.
• [C-1-17] डिसप्ले में लो-पर्सिस्टेंस मोड काम करना चाहिए. इसमें पर्सिस्टेंस ≤ 5 मिलीसेकंड होना चाहिए. पर्सिस्टेंस का मतलब है कि कोई पिक्सल कितने समय तक रोशनी देता है.
• [C-1-18] इनमें ब्लूटूथ 4.2 और ब्लूटूथ स्मार्ट डेटा लेंथ एक्सटेंशन सेक्शन 7.4.3 काम करना चाहिए.
• [C-1-19] डिफ़ॉल्ट सेंसर टाइप के लिए, डायरेक्ट चैनल टाइप को सपोर्ट करना और उसकी सही जानकारी देना ज़रूरी है. ये डिफ़ॉल्ट सेंसर टाइप ये हैं:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED
• [C-SR-7] ऊपर दिए गए सभी डायरेक्ट चैनल टाइप के लिए, TYPE_HARDWARE_BUFFER डायरेक्ट चैनल टाइप का इस्तेमाल करने का सुझाव दिया जाता है.
• [C-1-21] android.hardware.hifi_sensors के लिए, जाइरोस्कोप, एक्सलरोमीटर, और मैग्नेटोमीटर से जुड़ी ज़रूरी शर्तों को पूरा करना ज़रूरी है. ये शर्तें सेक्शन 7.3.9 में बताई गई हैं.
• [C-SR-8] android.hardware.sensor.hifi_sensors सुविधा काम करनी चाहिए.
• [C-1-22] में, मोशन टू फ़ोटॉन लेटेंसी 28 मिलीसेकंड से ज़्यादा नहीं होनी चाहिए.
• [C-SR-9] यह सुझाव दिया जाता है कि मोशन से फ़ोटॉन तक की एंड-टू-एंड लेटेन्सी 20 मिलीसेकंड से ज़्यादा न हो.
• [C-1-23] इसमें पहले फ़्रेम का अनुपात होना चाहिए. यह अनुपात, काले से सफ़ेद रंग में ट्रांज़िशन होने के बाद पहले फ़्रेम के पिक्सल की चमक और स्थिर स्थिति में सफ़ेद पिक्सल की चमक के बीच का अनुपात होता है. यह अनुपात कम से कम 85% होना चाहिए.
• [C-SR-10] हमारा सुझाव है कि पहले फ़्रेम का अनुपात कम से कम 90% होना चाहिए.
• यह फ़ोरग्राउंड ऐप्लिकेशन को एक खास कोर उपलब्ध करा सकता है. साथ ही, यह Process.getExclusiveCores एपीआई के साथ काम कर सकता है, ताकि उन सीपीयू कोर की संख्या दिखाई जा सके जो टॉप फ़ोरग्राउंड ऐप्लिकेशन के लिए खास तौर पर उपलब्ध हैं.

अगर एक्सक्लूसिव कोर की सुविधा काम करती है, तो कोर:

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

7.10. हैप्टिक

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

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

• [7.10/C] Vibrator.hasVibrator() के लिए, 'गलत' वैल्यू दिखानी चाहिए.

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

• [C-1-1] Vibrator.hasVibrator() के लिए, true वैल्यू रिटर्न होनी चाहिए.
• इसमें ईआरएम हैप्टिक ऐक्चुएटर (वाइब्रेटर) का इस्तेमाल नहीं किया जाना चाहिए.
• android.view.HapticFeedbackConstants में क्लियर हैप्टिक्स के लिए, सभी सार्वजनिक कॉन्स्टेंट लागू किए जाने चाहिए. जैसे, (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY, VIRTUAL_KEY_RELEASE, CONFIRM, REJECT, GESTURE_START, और GESTURE_END).
• क्लियर हैप्टिक के लिए, android.os.VibrationEffect में सभी सार्वजनिक कॉन्स्टेंट लागू किए जाने चाहिए. जैसे, (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK, और EFFECT_DOUBLE_CLICK). साथ ही, रिच हैप्टिक के लिए, android.os.VibrationEffect.Composition में सभी सार्वजनिक PRIMITIVE_* कॉन्स्टेंट लागू किए जाने चाहिए. जैसे, (CLICK, TICK, LOW_TICK, QUICK_FALL, QUICK_RISE, SLOW_RISE, SPIN, THUD). इनमें से कुछ प्रिमिटिव, जैसे कि LOW_TICK और SPIN सिर्फ़ तब लागू किए जा सकते हैं, जब वाइब्रेटर कम फ़्रीक्वेंसी को सपोर्ट कर सकता हो.
• android.view.HapticFeedbackConstants में, सार्वजनिक कॉन्स्टेंट को मैप करने के लिए दिए गए दिशा-निर्देशों का पालन करना चाहिए. ऐसा, सुझाए गए android.os.VibrationEffect कॉन्स्टेंट के साथ-साथ, उनसे जुड़े ऐम्प्लिट्यूड के संबंधों के लिए किया जाना चाहिए.
• इन लिंक किए गए हैप्टिक कॉन्स्टेंट मैपिंग का इस्तेमाल करना चाहिए.
• उसे 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() एपीआई तरीके का इस्तेमाल करके, यह सटीक जानकारी देना ज़रूरी है कि डिवाइस में परफ़ॉर्मेंस मोड की सुविधा काम करती है या नहीं.

• इसमें Sustained Performance Mode की सुविधा होनी चाहिए.

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

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

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

• [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] वैकल्पिक रनटाइम को उन संसाधनों का ऐक्सेस नहीं दिया जाना चाहिए जिन्हें उन अनुमतियों से सुरक्षित किया गया है जिनके लिए रनटाइम की AndroidManifest.xml फ़ाइल में <uses-permission> मेकेनिज़्म के ज़रिए अनुरोध नहीं किया गया है.

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

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

• [C-2-1] हर उपयोगकर्ता इंस्टेंस के लिए, अलग और आइसोलेटेड शेयर किया गया ऐप्लिकेशन स्टोरेज (इसे /sdcard भी कहा जाता है) डायरेक्ट्री होनी चाहिए.

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

डिवाइस लागू करने वाले लोग या कंपनियां, एक ही ऐप्लिकेशन के दो इंस्टेंस चलाने के लिए, प्राइमरी यूज़र के लिए android.os.usertype.profile.CLONE टाइप की एक अतिरिक्त उपयोगकर्ता की प्रोफ़ाइल बना सकती हैं. हालांकि, यह प्रोफ़ाइल सिर्फ़ प्राइमरी यूज़र के लिए बनाई जा सकती है. ये दोनों इंस्टेंस, स्टोरेज को कुछ हद तक शेयर करते हैं. इन्हें लॉन्चर में एक साथ दिखाया जाता है और ये एक ही रीसेंट व्यू में दिखते हैं. उदाहरण के लिए, इसका इस्तेमाल ऐसे उपयोगकर्ता की मदद करने के लिए किया जा सकता है जो दो सिम वाले डिवाइस पर, एक ही ऐप्लिकेशन के दो अलग-अलग इंस्टेंस इंस्टॉल करता है.

अगर डिवाइसों पर, ऊपर बताई गई अतिरिक्त उपयोगकर्ता प्रोफ़ाइल बनाई जाती है, तो:

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

• [C-3-2] के पास इसे वर्क प्रोफ़ाइल के तौर पर इस्तेमाल करने का विकल्प नहीं होना चाहिए.

• [C-3-3] में, निजी ऐप्लिकेशन के डेटा डायरेक्ट्री को पैरंट उपयोगकर्ता खाते से अलग किया जाना चाहिए.

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

अगर डिवाइसों पर, ऊपर बताई गई अतिरिक्त उपयोगकर्ता प्रोफ़ाइल बनाई जाती है, तो:

• [C-4-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] यह सुझाव दिया जाता है कि डिवाइस एडमिन के अलावा, कोई अन्य व्यक्ति 2G को बंद और चालू करने की सुविधा को ओवरराइड न करे. इसके लिए, डिवाइस एडमिन को UserManager.DISALLOW_CELLULAR_2G का इस्तेमाल करना होगा.

• [C-SR-19] इस ज़रूरी शर्त को पूरा करने के लिए, TelephonyManager.setAllowedNetworkTypesForReason को ALLOWED_NETWORK_TYPES_REASON_ENABLE_2G वजह के साथ कॉल करने का सुझाव दिया जाता है.

• [C-SR-20] यह सुझाव दिया जाता है कि 2G के लिए, मोबाइल मॉडम के साथ काम करने की सुविधा का पता लगाने के लिए, TelephonyManager.getSupportedRadioAccessFamily को कॉल करें. ज़्यादा जानकारी के लिए, 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 क्लास में मौजूद जानकारी शामिल होती है. जैसे, अक्षांश, देशांतर, ऊंचाई. साथ ही, इसमें ऐसे आइडेंटिफ़ायर भी शामिल होते हैं जिन्हें जगह की जानकारी में बदला जा सकता है. लोकेशन की जानकारी, डीजीपीएस (डिफ़रेंशियल ग्लोबल पोज़िशनिंग सिस्टम) जितनी सटीक या देश के लेवल की लोकेशन (जैसे कि देश के कोड की लोकेशन - एमसीसी - मोबाइल कंट्री कोड) जितनी सामान्य हो सकती है.

यहां जगह की जानकारी के उन टाइप की सूची दी गई है जिनसे सीधे तौर पर किसी उपयोगकर्ता की जगह की जानकारी मिलती है या जिन्हें उपयोगकर्ता की जगह की जानकारी में बदला जा सकता है. यह पूरी सूची नहीं है. हालांकि, इसका इस्तेमाल इस उदाहरण के तौर पर किया जाना चाहिए कि जगह की जानकारी को सीधे तौर पर या किसी और तरीके से कहां से लिया जा सकता है:

• GPS/GNSS/DGPS/PPP

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

• यूनीक आइडेंटिफ़ायर वाली वायरलेस टेक्नोलॉजी, जैसे कि:

  • वाई-फ़ाई ऐक्सेस पॉइंट (MAC, BSSID, नाम या SSID)
  • ब्लूटूथ/BLE (MAC, BSSID, नाम या SSID)
  • UWB (MAC, BSSID, नाम या SSID)
  • सेल टावर आईडी (3G, 4G, 5G वगैरह. इसमें सेल्युलर मॉडम की आने वाली सभी टेक्नोलॉजी शामिल हैं, जिनके यूनीक आइडेंटिफ़ायर होते हैं)

मुख्य रेफ़रंस के तौर पर, उन Android API को देखें जिनके लिए ACCESS_FINE_Location या ACCESS_COARSE_Location अनुमतियों की ज़रूरत होती है.

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

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

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

• [C-0-3] यह पक्का करना ज़रूरी है कि 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" प्रोवाइडर अथॉरिटी का इस्तेमाल करता है. इससे ऐप्लिकेशन के स्टोरेज में फ़ाइलें डाउनलोड की जाती हैं.

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

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

• [C-1-1] ऐप्लिकेशन के डेटा ब्लोब को, उन ऐप्लिकेशन के साथ शेयर नहीं किया जाना चाहिए जिनके साथ शेयर करने की अनुमति नहीं दी गई है.जैसे, डिफ़ॉल्ट ऐक्सेस का दायरा और ऐक्सेस के अन्य मोड, जिन्हें BlobStoreManager.session#allowPackageAccess(), BlobStoreManager.session#allowSameSignatureAccess() या BlobStoreManager.session#allowPublicAccess() का इस्तेमाल करके तय किया जा सकता है. इनमें बदलाव नहीं किया जाना चाहिए. AOSP के रेफ़रंस के तौर पर लागू किए गए समाधान में, इन ज़रूरी शर्तों को पूरा किया गया है.

• [C-1-2] डिवाइस से बाहर डेटा नहीं भेजना चाहिए. साथ ही, डेटा के सुरक्षित हैश को अन्य ऐप्लिकेशन के साथ शेयर नहीं करना चाहिए. इन हैश का इस्तेमाल, ऐक्सेस को कंट्रोल करने के लिए किया जाता है.

9.8.12. संगीत की पहचान

Android, System API MusicRecognitionManager के ज़रिए, डिवाइसों पर लागू होने वाले एक ऐसे सिस्टम को सपोर्ट करता है जो ऑडियो रिकॉर्ड के आधार पर संगीत की पहचान करने का अनुरोध कर सकता है. साथ ही, संगीत की पहचान करने की सुविधा को MusicRecognitionService API लागू करने वाले किसी खास ऐप्लिकेशन को सौंप सकता है.

अगर डिवाइस में ऐसी सेवा शामिल है जो System API MusicRecognitionManager को लागू करती है या कोई ऐसी मालिकाना सेवा है जो ऊपर बताए गए तरीके से ऑडियो डेटा स्ट्रीम करती है, तो:

• [C-1-1] 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 सैंडबॉक्स किए गए एपीआई को लागू करने का तरीका देखें. यह ऐक्सेस, एक ऐसे पैकेज के ज़रिए किया जाता है जिसमें इनमें से एक या इससे ज़्यादा भूमिकाएँ होती हैं: System UI Intelligence, System Ambient Audio Intelligence, System Audio Intelligence, System Notification Intelligence, System Text Intelligence, या System Visual Intelligence.

  • सैंडबॉक्स के ज़रिए ऐक्सेस किया जाता है. इसे AOSP (HotwordDetectionService, WearableSensingService, VisualQueryDetector) में मौजूद तरीकों के ज़रिए लागू किया जाता है और लागू किया जाता है.

  • डिजिटल असिस्टेंट ऐप्लिकेशन, ऑडियो का ऐक्सेस इसलिए लेता है, ताकि आपको मदद मिल सके. यह SOURCE_HOTWORD को ऑडियो सोर्स के तौर पर इस्तेमाल करता है.

  • सिस्टम, डेटा को ऐक्सेस करता है. साथ ही, इसे ओपन सोर्स कोड की मदद से लागू किया जाता है.

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

• [C-SR-2] हमारा सुझाव है कि रिमोट वियरेबल डिवाइस से मिलने वाले कैमरे के डेटा पर भी वही शर्तें लागू करें जो 9.8.2 रिकॉर्डिंग, 9.8.6 ओएस-लेवल और आस-पास के डेटा, 9.8.15 सैंडबॉक्स किए गए एपीआई के इस्तेमाल, और 9.8.16 लगातार ऑडियो और कैमरे के डेटा पर लागू होती हैं.

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

• [C-1-1] रिमोट वियरेबल डिवाइस को यह जानकारी देनी होगी कि उसे वहां एक और इंडिकेटर दिखाना है.

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

• [C-2-1] यह पक्का करना ज़रूरी है कि इस तरह के बदलाव, android.app.role.ASSISTANT की भूमिका निभाने वाले पैकेज से किए गए हों.

• [C-2-2] यह पक्का करना ज़रूरी है कि इस तरह के डेटा को लागू करने के लिए, HotwordDetectionService और/या VisualQueryDetectionService Android 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), तो फ़ाइल के नाम, फ़ाइल के कॉन्टेंट, और फ़ाइल सिस्टम के मेटाडेटा को एन्क्रिप्ट (सुरक्षित) करने के लिए, ऊपर दिए गए AES पर आधारित विकल्पों का इस्तेमाल करना ज़रूरी है. 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 Project, 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. रीबूट करने के बाद फिर से शुरू करें

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

Resume-on-Reboot की सुविधा को लागू करने के दौरान यह पक्का करना ज़रूरी है कि जब कोई डिवाइस हमलावर के हाथ लग जाए, तो उसके लिए उपयोगकर्ता के CE-एन्क्रिप्ट (सुरक्षित) किए गए डेटा को वापस पाना बहुत मुश्किल हो. भले ही, डिवाइस चालू हो, CE स्टोरेज अनलॉक हो, और उपयोगकर्ता ने ओटीए मिलने के बाद डिवाइस को अनलॉक कर दिया हो. हम यह भी मानते हैं कि अंदरूनी व्यक्ति के हमले से बचने के लिए, हमलावर को ब्रॉडकास्ट क्रिप्टोग्राफ़िक साइनिंग कुंजियों का ऐक्सेस मिल जाता है.

खास तौर से:

• [C-0-1] CE स्टोरेज को कोई भी व्यक्ति नहीं पढ़ सकता. यहां तक कि वह हमलावर भी इसे नहीं पढ़ सकता जिसके पास डिवाइस का ऐक्सेस है. साथ ही, उसके पास ये सुविधाएं और सीमाएं हैं:

  • किसी भी वेंडर या कंपनी की साइनिंग कुंजी का इस्तेमाल करके, आर्बिट्रेरी मैसेज साइन कर सकता है.
  • इससे डिवाइस को ओटीए मिल सकता है.
  • नीचे दी गई जानकारी के मुताबिक, किसी भी हार्डवेयर (एपी, फ़्लैश वगैरह) के ऑपरेशन में बदलाव किया जा सकता है. हालांकि, इस तरह के बदलाव में कम से कम एक घंटे का समय लगता है. साथ ही, पावर साइकल की वजह से रैम का कॉन्टेंट मिट जाता है.
  • छेड़छाड़ से सुरक्षित हार्डवेयर (जैसे, 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 हार्डवेयर ऐब्स्ट्रैक्शन लेयर (एचएएल) और 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] इसमें पुष्टि करने के लिए, सुझाए गए मुख्य तरीकों में से किसी एक का इस्तेमाल करने के लिए फ़ॉल-बैक मैकेनिज़्म होना चाहिए. यह मैकेनिज़्म, किसी जाने-पहचाने सीक्रेट पर आधारित होता है.

• [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 की तुलना में क्वालिटी कॉन्स्टेंट ज़्यादा पाबंदी वाला होता है.

  • DevicePolicyManager.setRequiredPasswordComplexity() तरीका, जिसमें PASSWORD_COMPLEXITY_NONE की तुलना में ज़्यादा पाबंदियां हैं.

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

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

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

• [C-12-2] डिवाइस को TrustState.TRUSTABLE स्टेट में तब डालना ज़रूरी है, जब स्क्रीन बंद हो (जैसे कि बटन दबाने या डिसप्ले टाइम आउट होने पर) और TrustAgent ने भरोसे की स्थिति को रद्द न किया हो. AOSP इस ज़रूरी शर्त को पूरा करता है.

• [C-12-3] डिवाइस को TrustState.TRUSTABLE से TrustState.TRUSTED स्थिति में सिर्फ़ तब ले जाएं, जब TrustAgent अब भी [C-12-1] में दी गई ज़रूरी शर्तों के आधार पर भरोसा कर रहा हो.

.

• [C-12-4] की ज़रूरी शर्तों को पूरा करने के लिए, सुरक्षित और सटीक रेंजिंग पर निर्भर रहने वाले इंप्लीमेंटेशन को इनमें से किसी एक समाधान का इस्तेमाल करना होगा:

  • यूडब्ल्यूबी टेक्नोलॉजी का इस्तेमाल करके लागू किए गए सिस्टम:

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

• [C-1-3] IdentityCredential System (जैसे, android.security.identity.* एपीआई) को लागू करने के लिए ज़रूरी क्रिप्टोग्राफ़िक ऑपरेशन, पूरी तरह से भरोसेमंद ऐप्लिकेशन में किए जाने चाहिए. साथ ही, निजी कुंजी के मटीरियल को अलग एक्ज़ीक्यूशन एनवायरमेंट से कभी भी बाहर नहीं जाना चाहिए. ऐसा तब तक नहीं होना चाहिए, जब तक कि उच्च-स्तरीय एपीआई (जैसे, createEphemeralKeyPair() तरीका) के लिए इसकी खास तौर पर ज़रूरत न हो.

• [C-1-4] भरोसेमंद ऐप्लिकेशन को इस तरह से लागू किया जाना चाहिए कि उसकी सुरक्षा से जुड़ी प्रॉपर्टी पर कोई असर न पड़े. उदाहरण के लिए, क्रेडेंशियल डेटा तब तक रिलीज़ नहीं किया जाना चाहिए, जब तक कि ऐक्सेस कंट्रोल की शर्तें पूरी न हो जाएं. साथ ही, किसी भी डेटा के लिए MAC जनरेट नहीं किए जा सकते. ऐसा तब भी होना चाहिए, जब Android ठीक से काम न कर रहा हो या उसके साथ छेड़छाड़ की गई हो.

Android Open Source Project का अपस्ट्रीम, भरोसेमंद ऐप्लिकेशन (libeic) का रेफ़रंस इम्प्लीमेंटेशन उपलब्ध कराता है. इसका इस्तेमाल, Identity Credential सिस्टम को लागू करने के लिए किया जा सकता है.

9.12. डेटा हटाना

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

• [C-0-1] उपयोगकर्ताओं को "फ़ैक्ट्री डेटा रीसेट" करने का तरीका उपलब्ध कराना ज़रूरी है.
• [C-0-2] "फ़ैक्ट्री डेटा रीसेट" करने पर, उपयोगकर्ता के डेटा वाले फ़ाइल सिस्टम से पूरा डेटा मिटाना ज़रूरी है.
• [C-0-3] "फ़ैक्ट्री डेटा रीसेट" करते समय, डेटा को इस तरह से मिटाना होगा कि वह NIST SP800-88 जैसे इंडस्ट्री के मानकों के मुताबिक हो.
• [C-0-4] जब मुख्य उपयोगकर्ता का डिवाइस नीति कंट्रोलर ऐप्लिकेशन, DevicePolicyManager.wipeData() API को कॉल करता है, तब ऊपर दी गई "फ़ैक्ट्री डेटा रीसेट" प्रोसेस को ट्रिगर करना ज़रूरी है.
• MAY, डेटा को तेज़ी से मिटाने का विकल्प दे सकता है. इससे सिर्फ़ लॉजिकल डेटा मिटाया जाता है.

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.xml में config_developerVerificationPolicyDelegatePackageName को तय करके, चालू नीति को सेट करने के लिए किसी प्रतिनिधि को भी कॉन्फ़िगर कर सकता है.

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

• [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 5.1 से, अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट में ब्लॉक-आधारित ओटीए लागू किया गया है. इससे यह ज़रूरी शर्त पूरी होती है.

साथ ही, डिवाइसों में A/B सिस्टम अपडेट की सुविधा होनी चाहिए. AOSP, बूट कंट्रोल HAL का इस्तेमाल करके इस सुविधा को लागू करता है.

अगर किसी डिवाइस के रिलीज़ होने के बाद, उसके लागू करने में कोई गड़बड़ी मिलती है, लेकिन वह गड़बड़ी, प्रॉडक्ट के जीवनकाल के दौरान मिलती है. प्रॉडक्ट का जीवनकाल, Android Compatibility Team के साथ सलाह-मशविरे के बाद तय किया जाता है. इस गड़बड़ी से, तीसरे पक्ष के ऐप्लिकेशन के साथ डिवाइस के काम करने की क्षमता पर असर पड़ता है. ऐसे में:

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

Android में ऐसी सुविधाएं शामिल होती हैं जिनकी मदद से, डिवाइस के मालिक के ऐप्लिकेशन (अगर मौजूद है) को सिस्टम अपडेट इंस्टॉल करने की सुविधा मिलती है. अगर डिवाइसों के लिए सिस्टम अपडेट सबसिस्टम, android.software.device_admin की रिपोर्ट करता है, तो:

• [C-3-1] SystemUpdatePolicy क्लास में बताए गए व्यवहार को लागू करना ज़रूरी है.

12. दस्तावेज़ में हुए बदलावों का लॉग

Android 16 से, अलग से कोई बदलाव लॉग नहीं रखा जाता. पिछले वर्शन में किए गए सभी बदलावों को इस दस्तावेज़ में हाइलाइट किया गया है.

13. हमसे संपर्क करें

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