Android 10 के साथ काम करने की जानकारी

1. परिचय

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

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

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

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

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

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

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

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

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

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

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

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

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

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

हर आईडी की जानकारी यहां दी गई है:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2.1. हार्डवेयर

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

• [7.1.1.1/H-0-1] डिवाइस में कम से कम एक ऐसा डिसप्ले होना चाहिए जो Android के साथ काम करता हो. साथ ही, उसका डाइगनल साइज़ कम से कम 2.5 इंच होना चाहिए. Android के साथ काम करने वाले हर डिसप्ले को, इस दस्तावेज़ में बताई गई सभी ज़रूरी शर्तों को पूरा करना होगा.
• [7.1.1.3/H-SR] यह सुझाव दिया जाता है कि उपयोगकर्ताओं को डिसप्ले साइज़ (स्क्रीन डेंसिटी) बदलने की सुविधा दी जाए.

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

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

• [7.4.7/H-1-1] में डेटा बचाने वाला मोड उपलब्ध होना चाहिए.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [7.8.2.2/H-2-1] डिवाइस को Intent ACTION_HEADSET_PLUG ब्रॉडकास्ट करना होगा. साथ ही, "microphone" एक्स्ट्रा को 0 पर सेट करना होगा.

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

• [7.8.2.2/H-3-1] MUST broadcast Intent ACTION_HEADSET_PLUG with "microphone" extra set to 1.

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

• [7.8.2.2/H-4-1] अगर यूएसबी ऑडियो टर्मिनल टाइप फ़ील्ड 0x0302 है, तो AudioDeviceInfo.TYPE_USB_HEADSET टाइप के डिवाइस को सूची में शामिल करना होगा. साथ ही, role 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 टाइप के डिवाइस को सूची में शामिल करना ज़रूरी है. साथ ही, role isSource() होना चाहिए.

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

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

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

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.3/H-0-1] H.264 एवीसी
• [5.3/H-0-2] H.265 HEVC
• [5.3/H-0-3] MPEG-4 SP
• [5.3/H-0-4] VP8
• [5.3/H-0-5] VP9

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.4.1/H-0-1] android.webkit.Webview एपीआई को पूरी तरह से लागू करना ज़रूरी है.
• [3.4.2/H-0-1] इसमें सामान्य उपयोगकर्ता के लिए, वेब ब्राउज़िंग के लिए अलग से ब्राउज़र ऐप्लिकेशन शामिल होना चाहिए.
• [3.8.1/H-SR] यह सुझाव दिया जाता है कि डिफ़ॉल्ट लॉन्चर को लागू किया जाए. यह लॉन्चर, शॉर्टकट, विजेट, और widgetFeatures को ऐप्लिकेशन में पिन करने की सुविधा के साथ काम करता हो.
• [3.8.1/H-SR] यह सुझाव दिया जाता है कि डिफ़ॉल्ट लॉन्चर को लागू किया जाए. इससे तीसरे पक्ष के ऐप्लिकेशन से मिले अतिरिक्त शॉर्टकट को ShortcutManager API के ज़रिए तुरंत ऐक्सेस किया जा सकता है.
• [3.8.1/H-SR] यह सुझाव दिया जाता है कि डिवाइस में डिफ़ॉल्ट लॉन्चर ऐप्लिकेशन शामिल हो. यह ऐप्लिकेशन, ऐप्लिकेशन आइकॉन के लिए बैज दिखाता हो.
• [3.8.2/H-SR] तीसरे पक्ष के ऐप्लिकेशन के विजेट इस्तेमाल करने की सुविधा देने का सुझाव दिया जाता है.
• [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] हमारा सुझाव है कि RemoteInput.Builder setChoices() के ज़रिए उपलब्ध कराए गए पहले विकल्प को, नोटिफ़िकेशन शेड में दिखाया जाए. इसके लिए, उपयोगकर्ता के इंटरैक्शन की ज़रूरत नहीं होती.
• [3.8.3/H-SR] जब उपयोगकर्ता, सूचना पैनल में मौजूद सभी सूचनाओं को बड़ा करता है, तब सूचना पैनल में RemoteInput.Builder setChoices() के ज़रिए उपलब्ध कराए गए सभी विकल्पों को दिखाने का सुझाव दिया जाता है.
• [3.8.3.1/H-SR] Notification.Remoteinput.Builder.setChoices की ओर से दिखाए गए जवाबों के साथ-साथ, उन कार्रवाइयों को भी दिखाने का सुझाव दिया जाता है जिनके लिए Notification.Action.Builder.setContextual को true के तौर पर सेट किया गया है.
• [3.8.4/H-SR] डिवाइस पर असिस्टेंट को लागू करने का सुझाव दिया जाता है, ताकि सहायता पाने से जुड़ी कार्रवाई को हैंडल किया जा सके.

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

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

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

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

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

• [3.9/H-1-1] Android SDK के दस्तावेज़ में बताई गई, डिवाइस एडमिनिस्ट्रेशन से जुड़ी सभी नीतियों को लागू करना ज़रूरी है.
• [3.9/H-1-2] android.software.managed_users फ़ीचर फ़्लैग के ज़रिए, मैनेज की गई प्रोफ़ाइलों के साथ काम करने की सुविधा के बारे में जानकारी देना ज़रूरी है. हालांकि, ऐसा तब नहीं करना होगा, जब डिवाइस को इस तरह कॉन्फ़िगर किया गया हो कि वह खुद को कम रैम वाला डिवाइस रिपोर्ट करे या वह इंटरनल (हटाए नहीं जा सकने वाले) स्टोरेज को शेयर किए गए स्टोरेज के तौर पर असाइन करे.

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

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

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

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

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

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

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

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

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 Open Source Project, 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 के मकसद का पालन करना ज़रूरी है. साथ ही, एक सेटिंग मेन्यू दिखाना ज़रूरी है, जिसमें बैटरी के इस्तेमाल की जानकारी दिखती हो.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.2/T-SR] 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

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

• [5.3.1/T-1-1] मेन प्रोफ़ाइल हाई लेवल के साथ, हर सेकंड में 29.97 फ़्रेम पर एचडी 1080 पिक्सल.
• [5.3.1/T-1-2] 59.94 फ़्रेम प्रति सेकंड पर एचडी 1080i, मेन प्रोफ़ाइल हाई लेवल के साथ. उन्हें इंटरलेस्ड 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] हाई प्रोफ़ाइल लेवल 4.2 के साथ, हर सेकंड में 60 फ़्रेम पर एचडी 1080 पिक्सल

टेलीविज़न डिवाइसों में 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] डिवाइस में, Main10 Level 5 Main Tier प्रोफ़ाइल के साथ 60 फ़्रेम प्रति सेकंड पर यूएचडी डिकोडिंग प्रोफ़ाइल काम करनी चाहिए.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [3/T-0-1] यह ज़रूरी है कि android.software.leanback और android.hardware.type.television सुविधाओं का एलान किया गया हो.
• [3.4.1/T-0-1] में android.webkit.Webview एपीआई को पूरी तरह से लागू करना ज़रूरी है.

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

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

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

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

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

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

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

• [3.12/T-0-1] TV Input Framework के साथ काम करना ज़रूरी है.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.4.1. हार्डवेयर

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [7.8.2/W] MAY but SHOULD NOT have audio output.

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

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

• [3.10/W-1-1] तीसरे पक्ष की सुलभता सेवाओं के साथ काम करना ज़रूरी है.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [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-0-1] जीपीएस/जीएनएसएस को अन्य सेंसर के साथ जोड़कर, जगह की जानकारी का अनुमान लगाया जा सकता है. अगर जगह की जानकारी की डेड रैकिंग हो जाती है, तो इस्तेमाल किए गए सेंसर टाइप और/या वाहन की प्रॉपर्टी के आईडी को लागू करने और उनकी रिपोर्ट करने का सुझाव दिया जाता है.
• [7.3/A-0-2] LocationManager#requestLocationUpdates() के ज़रिए अनुरोध की गई जगह की जानकारी को मैप से मैच नहीं किया जाना चाहिए.

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

• [7.3.1/A-1-1] को कम से कम 100 हर्ट्ज़ की फ़्रीक्वेंसी तक इवेंट रिपोर्ट करने में सक्षम होना चाहिए.
• [7.3.1/A-1-2] को Android कार सेंसर कोऑर्डिनेट सिस्टम का पालन करना होगा.

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

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

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

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

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

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

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

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

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

एक्सटीरियर व्यू कैमरा, ऐसा कैमरा होता है जो डिवाइस के बाहर के सीन की इमेज लेता है. जैसे, डैशकैम.

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

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

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

• [7.5/A-1-1] बाहरी व्यू वाले कैमरे, Android Camera API के ज़रिए ऐक्सेस नहीं किए जा सकते. हालांकि, अगर वे कैमरे की बुनियादी ज़रूरी शर्तों का पालन करते हैं, तो उन्हें ऐक्सेस किया जा सकता है.
• [7.5/A-SR] कैमरे की झलक को घुमाने या हॉरिज़ॉन्टल तौर पर मिरर करने का सुझाव नहीं दिया जाता.
• [7.5.5/A-SR] यह सुझाव दिया जाता है कि कैमरे को इस तरह से लगाया जाए कि उसका लंबा हिस्सा, हॉरिज़ॉन्टल हो.
• [7.5/A-SR] इनका रिज़ॉल्यूशन कम से कम 1.3 मेगापिक्सल होना चाहिए.
• इसमें फ़िक्स्ड-फ़ोकस या ईडॉफ़ (एक्सटेंडेड डेप्थ ऑफ़ फ़ील्ड) हार्डवेयर होना चाहिए.
• कैमरा ड्राइवर में, हार्डवेयर ऑटो-फ़ोकस या सॉफ़्टवेयर ऑटो-फ़ोकस की सुविधा लागू की गई हो सकती है.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

अगर 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 एमबी होनी चाहिए:

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

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

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

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

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

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

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

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

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 एवीसी
• [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] H.265 HEVC

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.* नेमस्पेस में मौजूद सभी सार्वजनिक एपीआई के साथ काम करता हो.

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

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

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

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

अगर 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.14/A-0-1] इसमें यूज़र इंटरफ़ेस (यूआई) फ़्रेमवर्क शामिल होना चाहिए, ताकि तीसरे पक्ष के ऐप्लिकेशन, सेक्शन 3.14 में बताए गए मीडिया एपीआई का इस्तेमाल कर सकें.
• [3.14/A-0-2] MUST allow the user to safely interact with Media Applications while driving.
• [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 limit the ability to enter a full screen mode as described in immersive documentation.
• [3.8/A] स्टेटस बार और नेविगेशन बार को हमेशा दिखा सकता है.
• [3.8/A] ऐप्लिकेशन के अनुरोधों को सीमित किया जा सकता है, ताकि सिस्टम यूज़र इंटरफ़ेस (यूआई) एलिमेंट के पीछे के रंगों को बदलने की सुविधा को सीमित किया जा सके. इससे यह पक्का किया जा सकेगा कि ये एलिमेंट हमेशा साफ़ तौर पर दिखें. इसके बारे में WindowManager.LayoutParams#FLAG_TRANSLUCENT_STATUS और WindowManager.LayoutParams#FLAG_TRANSLUCENT_NAVIGATION में बताया गया है.

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

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

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

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

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

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

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

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 बाइनरी को, आउटपुट के तौर पर एक प्रोटोबफ़ ट्रेस लिखना होगा. यह ट्रेस, परफ़ेक्टो के दस्तावेज़ में बताए गए स्कीमा के मुताबिक होना चाहिए.
  • [6.1/A-0-4] Perfetto के दस्तावेज़ में बताए गए डेटा सोर्स को, Perfetto बाइनरी के ज़रिए उपलब्ध कराना ज़रूरी है.

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

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

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

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

2.6.1. हार्डवेयर

स्क्रीन का साइज़

• [7.1.1.1/Tab-0-1] स्क्रीन का साइज़ 7 से 18 इंच के बीच होना चाहिए.

Gyroscope

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 पाथ में प्रोविज़नल लिस्ट और डेनायल लिस्ट फ़्लैग के ज़रिए उपलब्ध कराई गई हैं.

  हालांकि, वे:

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

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

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

Android में, एपीआई लेवल के वर्शन को बदले बिना मैनेज किए गए एपीआई को बढ़ाने की सुविधा शामिल है.

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

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

3.2.1. अनुमतियां

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

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

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

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

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

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

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

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

  • डेस्क क्लॉक
  • ब्राउज़र
  • Calendar
  • संपर्क
  • गैलरी
  • GlobalSearch
  • लॉन्चर
  • संगीत
  • सेटिंग

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

• [C-0-1] Android एक एक्सटेंसिबल प्लैटफ़ॉर्म है. इसलिए, डिवाइसों पर 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 है, तो:

• [C-2-1] MUST provide a settings menu that will call the RoleManager.createRequestRoleIntent(String) intent with RoleManager.ROLE_SMS to show a dialog to change the default SMS application.

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

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

• [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 भूमिका वाला ऐप्लिकेशन चुन सके.

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

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

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

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

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

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

• [C-1-1] android.software.activities_on_secondary_displays फ़ीचर फ़्लैग को सेट करना ज़रूरी है.
• [C-1-2] MUST guarantee API compatibility similar to an activity running on the primary display.
• [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. नेटिव एपीआई के साथ काम करने की सुविधा

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

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

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

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

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

• [C-0-1] को एक या उससे ज़्यादा तय किए गए ABI के साथ काम करना चाहिए. साथ ही, Android NDK के साथ काम करने की सुविधा लागू करनी चाहिए.
• [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
  • armeabi-v7a
  • arm64-v8a
  • x86
  • x86-64

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

  • libaaudio.so (AAudio नेटिव ऑडियो सपोर्ट)

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

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

• [C-0-9] /vendor/etc/public.libraries.txt में, सीधे तौर पर तीसरे पक्ष के ऐप्लिकेशन को उपलब्ध कराई गई, AOSP के अलावा अन्य लाइब्रेरी की सूची देना ज़रूरी है.
• [C-0-10] सिस्टम लाइब्रेरी के तौर पर AOSP में लागू की गई और उपलब्ध कराई गई किसी भी अन्य नेटिव लाइब्रेरी को, एपीआई लेवल 24 या उसके बाद के वर्शन को टारगेट करने वाले तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध नहीं कराना चाहिए. ऐसा इसलिए, क्योंकि ये लाइब्रेरी रिज़र्व होती हैं.
• [C-0-11] NDK में बताए गए सभी OpenGL ES 3.1 और Android Extension Pack फ़ंक्शन सिंबल को libGLESv3.so लाइब्रेरी के ज़रिए एक्सपोर्ट करना ज़रूरी है. ध्यान दें कि सभी सिंबल मौजूद होने चाहिए. हालांकि, सेक्शन 7.1.4.1 में इस बारे में ज़्यादा जानकारी दी गई है कि हर फ़ंक्शन को पूरी तरह से लागू करने के लिए, कौनसी ज़रूरी शर्तें पूरी करनी होंगी.
• [C-0-12] libvulkan.so लाइब्रेरी के ज़रिए, Vulkan 1.0 के मुख्य फ़ंक्शन सिंबल के साथ-साथ VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1, और VK_KHR_get_physical_device_properties2 एक्सटेंशन के लिए फ़ंक्शन सिंबल एक्सपोर्ट करना ज़रूरी है. ध्यान दें कि सभी सिंबल मौजूद होने चाहिए. हालांकि, सेक्शन 7.1.4.2 में इस बारे में ज़्यादा जानकारी दी गई है कि हर फ़ंक्शन को पूरी तरह से लागू करने की ज़रूरत कब होती है.
• इसे Android ओपन सोर्स प्रोजेक्ट के अपस्ट्रीम में उपलब्ध सोर्स कोड और हेडर फ़ाइलों का इस्तेमाल करके बनाया जाना चाहिए

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

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

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

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

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

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

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

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

  • SWP और SWPB निर्देश.
  • SETEND निर्देश.
  • 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 10 ब्रांच पर Android Open Source Project से बनाए गए Chromium प्रोजेक्ट का इस्तेमाल करना ज़रूरी है.

• [C-1-3] 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 के ज़रिए सिस्टम की ज़रूरी सेवाओं का ऐक्सेस होना चाहिए. WebView का AOSP वर्शन, इस ज़रूरी शर्त को पूरा करता है.

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

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

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

• [C-1-1] यह ज़रूरी है कि डिवाइस, 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-9] डिवाइसों को, Security.getProviders() तरीके से मिले सुरक्षा प्रोवाइडर की सूची में, पहले सात सुरक्षा प्रोवाइडर की जानकारी इस क्रम में देनी होगी: 1. Google Play Protect, 2. Google SafetyNet, 3. Google Trust Services, 4. Google Play Integrity API, 5. Google Play Custom Security Provider, 6. Google Play Device Intelligence, 7. Google Play App Signing. साथ ही, उनके नाम और क्लास भी वही होने चाहिए जो 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 Open Source Project के साथ व्यवहार से जुड़ी ज़रूरी शर्तों का पालन किया गया हो. इस वजह से, डिवाइस बनाने वाली कंपनियों को जहां तक हो सके, Android ओपन सोर्स प्रोजेक्ट के ज़रिए उपलब्ध सोर्स कोड का इस्तेमाल करना चाहिए. इसके बजाय, उन्हें सिस्टम के अहम हिस्सों को फिर से लागू नहीं करना चाहिए.

3.5.1. बैकग्राउंड की गतिविधियों पर रोक लगाना

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

• [C-1-1] उपयोगकर्ता को ऐसा विकल्प देना ज़रूरी है जिससे वह पाबंदी वाले ऐप्लिकेशन की सूची देख सके.
• [C-1-2] उपयोगकर्ताओं को हर ऐप्लिकेशन के लिए, पाबंदियां चालू / बंद करने की सुविधा देनी होगी.
• [C-1-3] सिस्टम के ठीक से काम न करने के सबूत के बिना, अपने-आप पाबंदियां लागू नहीं होनी चाहिए. हालांकि, सिस्टम के ठीक से काम न करने का पता चलने पर, ऐप्लिकेशन पर पाबंदियां लागू की जा सकती हैं. जैसे, वेकलॉक की समस्या, लंबे समय तक चलने वाली सेवाएं, और अन्य शर्तें. डिवाइस बनाने वाली कंपनियां, इन शर्तों को तय कर सकती हैं. हालांकि, ये शर्तें सिस्टम की परफ़ॉर्मेंस पर ऐप्लिकेशन के असर से जुड़ी होनी चाहिए. सिस्टम की परफ़ॉर्मेंस से जुड़ी अन्य शर्तों का इस्तेमाल नहीं किया जाना चाहिए. जैसे, बाज़ार में ऐप्लिकेशन की लोकप्रियता कम होना.
• [C-1-4] अगर किसी उपयोगकर्ता ने ऐप्लिकेशन पर पाबंदियां लगाने की सुविधा को मैन्युअल तरीके से बंद कर दिया है, तो ऐप्लिकेशन पर पाबंदियां अपने-आप लागू नहीं होनी चाहिए. हालांकि, उपयोगकर्ता को ऐप्लिकेशन पर पाबंदियां लगाने का सुझाव दिया जा सकता है.
• [C-1-5] अगर किसी ऐप्लिकेशन पर पाबंदियां अपने-आप लागू होती हैं, तो उपयोगकर्ताओं को इसकी सूचना देना ज़रूरी है.
• [C-1-6] जब प्रतिबंधित ऐप्लिकेशन इस एपीआई को कॉल करता है, तब ActivityManager.isBackgroundRestricted() के लिए true को वापस लाना ज़रूरी है.
• [C-1-7] को फ़ोरग्राउंड में चल रहे उस ऐप्लिकेशन पर पाबंदी नहीं लगानी चाहिए जिसे उपयोगकर्ता ने साफ़ तौर पर इस्तेमाल किया है.
• [C-1-8] जब उपयोगकर्ता, पाबंदी वाले ऐप्लिकेशन का इस्तेमाल करना शुरू करता है, तो उस ऐप्लिकेशन पर लगी पाबंदियां हटा दी जानी चाहिए. ऐसा तब किया जाना चाहिए, जब वह ऐप्लिकेशन टॉप फ़ोरग्राउंड ऐप्लिकेशन बन जाता है.

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> मेकेनिज़्म का इस्तेमाल किया जाता है.

अगर डिवाइस बनाने वाली कंपनी, ऊपर दिए गए किसी पैकेज नेमस्पेस को बेहतर बनाने का सुझाव देती है (जैसे कि किसी मौजूदा एपीआई में काम की नई सुविधा जोड़ना या नया एपीआई जोड़ना), तो उसे 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 Open Source Project की वेबसाइट पर, JFuzz और DexFuzz के बारे में जानकारी देखें.

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

3.8. यूज़र इंटरफ़ेस के साथ काम करने की सुविधा

3.8.1. लॉन्चर (होम स्क्रीन)

Android में लॉन्चर ऐप्लिकेशन (होम स्क्रीन) शामिल होता है. साथ ही, इसमें डिवाइस लॉन्चर (होम स्क्रीन) को बदलने के लिए, तीसरे पक्ष के ऐप्लिकेशन इस्तेमाल करने की सुविधा भी होती है.

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

• [C-1-1] प्लैटफ़ॉर्म की सुविधा android.software.home_screen के बारे में एलान करना ज़रूरी है.
• [C-1-2] तीसरे पक्ष का ऐप्लिकेशन, अपना आइकॉन दिखाने के लिए <adaptive-icon> टैग का इस्तेमाल करता है. साथ ही, आइकॉन वापस पाने के लिए PackageManager तरीकों को कॉल किया जाता है. ऐसे में, AdaptiveIconDrawable ऑब्जेक्ट को वापस लाना ज़रूरी है.

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

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

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

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

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

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

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

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

3.8.2. विजेट

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

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

• [C-1-1] यह ज़रूरी है कि प्लैटफ़ॉर्म की सुविधा android.software.app_widgets के साथ काम करने का एलान किया गया हो.
• [C-1-2] लॉन्चर में, AppWidget के लिए पहले से मौजूद सहायता शामिल होनी चाहिए. साथ ही, लॉन्चर में सीधे तौर पर AppWidget जोड़ने, कॉन्फ़िगर करने, देखने, और हटाने के लिए, उपयोगकर्ता इंटरफ़ेस की सुविधाएं उपलब्ध होनी चाहिए.
• [C-1-3] में, स्टैंडर्ड ग्रिड साइज़ में 4 x 4 वाले विजेट रेंडर करने की सुविधा होनी चाहिए. ज़्यादा जानकारी के लिए, Android SDK के दस्तावेज़ में ऐप्लिकेशन विजेट के डिज़ाइन से जुड़े दिशा-निर्देश देखें.
• लॉक स्क्रीन पर ऐप्लिकेशन विजेट दिखाने की सुविधा दे सकता है.

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

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

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

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

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

• [C-3-1] सूचनाएं दिखाते समय, Notification.Builder एपीआई क्लास में बताए गए तरीके से, स्क्रीन पर सबसे ऊपर सूचना देने वाले कार्ड और संसाधनों का इस्तेमाल करना ज़रूरी है.
• [C-3-2] Notification.Builder.addAction() के ज़रिए उपलब्ध कराई गई कार्रवाइयों को सूचना के कॉन्टेंट के साथ दिखाना ज़रूरी है. इसके लिए, उपयोगकर्ता के किसी अन्य इंटरैक्शन की ज़रूरत नहीं होनी चाहिए. इस बारे में एसडीके में बताया गया है.

3.8.3.2. सूचना सुनने की सेवा

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

अगर डिवाइसों पर लागू की गई सुविधाओं से, फ़ीचर फ़्लैग android.hardware.ram.normal की रिपोर्ट मिलती है, तो:

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

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

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

3.8.3.3. डीएनडी (परेशान न करें)

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

• [C-1-1] ऐप्लिकेशन को ऐसी ऐक्टिविटी लागू करनी होगी जो ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS इंटेंट का जवाब दे सके. UI_MODE_TYPE_NORMAL के साथ लागू करने के लिए, यह ऐसी ऐक्टिविटी होनी चाहिए जहां उपयोगकर्ता, ऐप्लिकेशन को DND नीति के कॉन्फ़िगरेशन का ऐक्सेस दे सके या उसे अस्वीकार कर सके.
• [C-1-2] डिवाइस को यह सुविधा देनी होगी कि उपयोगकर्ता, तीसरे पक्ष के ऐप्लिकेशन को 'परेशान न करें' मोड की नीति के कॉन्फ़िगरेशन को ऐक्सेस करने की अनुमति दे या न दे. साथ ही, उसे ऐप्लिकेशन की बनाई गई 'परेशान न करें' मोड की अपने-आप लागू होने वाली सेटिंग को, उपयोगकर्ता की बनाई गई और पहले से तय की गई सेटिंग के साथ दिखाना होगा.
• [C-1-3] NotificationManager.Policy के साथ पास की गई suppressedVisualEffects वैल्यू का पालन करना ज़रूरी है. अगर किसी ऐप्लिकेशन ने SUPPRESSED_EFFECT_SCREEN_OFF या SUPPRESSED_EFFECT_SCREEN_ON फ़्लैग में से कोई भी फ़्लैग सेट किया है, तो उसे उपयोगकर्ता को यह बताना चाहिए कि 'परेशान न करें' सेटिंग मेन्यू में विज़ुअल इफ़ेक्ट बंद कर दिए गए हैं.

3.8.4. खोजें

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

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

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

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

अगर ग्लोबल सर्च की सुविधा का इस्तेमाल करने वाले तीसरे पक्ष के कोई भी ऐप्लिकेशन इंस्टॉल नहीं किए गए हैं, तो:

• डिफ़ॉल्ट रूप से, वेब सर्च इंजन के नतीजे और सुझाव दिखने चाहिए.

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

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

• [C-2-1] असली उपयोगकर्ता को यह साफ़ तौर पर बताना ज़रूरी है कि कॉन्टेक्स्ट कब शेयर किया जाता है. इसके लिए, इनमें से कोई एक तरीका अपनाएं:
  • जब भी डिजिटल असिस्टेंट ऐप्लिकेशन कॉन्टेक्स्ट को ऐक्सेस करता है, तब स्क्रीन के किनारों पर सफ़ेद रंग की लाइट दिखती है. यह लाइट, Android Open Source Project के लागू करने की अवधि और चमक के बराबर या उससे ज़्यादा होती है.
  • पहले से इंस्टॉल किए गए असिस्ट ऐप्लिकेशन के लिए, डिफ़ॉल्ट वॉइस इनपुट और असिस्टेंट ऐप्लिकेशन की सेटिंग के मेन्यू से दो से कम नेविगेशन में उपयोगकर्ता को सुविधा देना. साथ ही, असिस्ट ऐप्लिकेशन के लिए सिर्फ़ तब कॉन्टेक्स्ट शेयर करना, जब उपयोगकर्ता ने हॉटवर्ड या असिस्ट नेविगेशन कुंजी के इनपुट के ज़रिए साफ़ तौर पर इसे चालू किया हो.
• [C-2-2] सेक्शन 7.2.3 में बताए गए तरीके से, सहायता करने वाले ऐप्लिकेशन को लॉन्च करने के लिए तय की गई बातचीत से, उपयोगकर्ता के चुने गए सहायता करने वाले ऐप्लिकेशन को लॉन्च किया जाना चाहिए. दूसरे शब्दों में, VoiceInteractionService को लागू करने वाले ऐप्लिकेशन या ACTION_ASSIST इंटेंट को हैंडल करने वाली गतिविधि को लॉन्च किया जाना चाहिए.

3.8.5. सूचनाएं और सूचनाएं

ऐप्लिकेशन, Toast एपीआई का इस्तेमाल करके, असली उपयोगकर्ता को छोटी नॉन-मोडल स्ट्रिंग दिखा सकते हैं. ये स्ट्रिंग कुछ समय बाद गायब हो जाती हैं. साथ ही, TYPE_APPLICATION_OVERLAY विंडो टाइप एपीआई का इस्तेमाल करके, अन्य ऐप्लिकेशन के ऊपर ओवरले के तौर पर सूचना वाली विंडो दिखा सकते हैं.

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

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

• [C-1-2] Toast API का इस्तेमाल करना ज़रूरी है. साथ ही, ऐप्लिकेशन से मिले टॉस्ट को असली उपयोगकर्ताओं को इस तरह दिखाना ज़रूरी है कि वे आसानी से दिखें.

3.8.6. थीम

Android, ऐप्लिकेशन के लिए “थीम” उपलब्ध कराता है. इससे ऐप्लिकेशन, पूरी गतिविधि या ऐप्लिकेशन पर स्टाइल लागू कर सकते हैं.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [C-1-1] कम से कम सात गतिविधियों को दिखाने की सुविधा होनी चाहिए.
• एक बार में कम से कम चार गतिविधियों के टाइटल दिखने चाहिए.
• [C-1-2] स्क्रीन पिन करने की सुविधा को लागू करना ज़रूरी है. साथ ही, उपयोगकर्ता को इस सुविधा को टॉगल करने के लिए, सेटिंग मेन्यू उपलब्ध कराना ज़रूरी है.
• हाल के ऐप्लिकेशन में, हाइलाइट करने के लिए इस्तेमाल किया गया रंग, आइकॉन, और स्क्रीन का टाइटल दिखना चाहिए.
• इसमें बंद करने का विकल्प ("x") दिखना चाहिए. हालांकि, उपयोगकर्ता के स्क्रीन से इंटरैक्ट करने तक इसे दिखाने में देरी की जा सकती है.
• पिछली गतिविधि पर आसानी से स्विच करने के लिए, शॉर्टकट लागू करना चाहिए.
• जब हाल ही में इस्तेमाल किए गए ऐप्लिकेशन की फ़ंक्शन बटन को दो बार टैप किया जाता है, तो इससे हाल ही में इस्तेमाल किए गए दो ऐप्लिकेशन के बीच तुरंत स्विच करने का ऐक्शन ट्रिगर होना चाहिए.
• अगर स्प्लिट-स्क्रीन मल्टीविंडो मोड की सुविधा उपलब्ध है, तो हाल ही के ऐप्लिकेशन की फ़ंक्शन कुंजी को दबाकर रखने पर, यह मोड चालू होना चाहिए.
• ऐसा हो सकता है कि यह अफ़िलिएट किए गए हाल ही के आइटम को एक ऐसे ग्रुप के तौर पर दिखाए जो एक साथ मूव करता है.
• [SR] खास तौर पर, ओवरव्यू स्क्रीन के लिए अपस्ट्रीम Android यूज़र इंटरफ़ेस (या थंबनेल पर आधारित इसी तरह का इंटरफ़ेस) इस्तेमाल करने का सुझाव दिया जाता है.

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

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

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

• [C-1-1] ऐप्लिकेशन को android.software.input_methods प्लैटफ़ॉर्म फ़ीचर के बारे में बताना होगा. साथ ही, Android SDK के दस्तावेज़ में बताए गए IME API के साथ काम करना होगा.
• [C-1-2] android.settings.INPUT_METHOD_SETTINGS इंटेंट के जवाब में, तीसरे पक्ष के इनपुट मेथड जोड़ने और कॉन्फ़िगर करने के लिए, उपयोगकर्ता के लिए उपलब्ध एक तरीका देना होगा.

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

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

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

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

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

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

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

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

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

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

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

* [C-2-1] MUST render text with Unicode compliant font as default;
  non-Unicode compliant font MUST NOT be set as default font unless the user
  chooses it in the language picker.
* [C-2-2] MUST support a Unicode font and a non-Unicode compliant font if a
  non-Unicode compliant font is supported on the device.  Non-Unicode
  compliant font MUST NOT remove or overwrite the Unicode font.
* [C-2-3] MUST render text with non-Unicode compliant font ONLY IF a
  language code with [script code Qaag](
  http://unicode.org/reports/tr35/#unicode_script_subtag_validity) is
  specified (e.g. my-Qaag). No other ISO language or region codes (whether
  assigned, unassigned, or reserved) can be used to refer to non-Unicode
  compliant font for Myanmar. App developers and web page authors can
  specify my-Qaag as the designated language code as they would for any
  other language.

3.8.14. मल्टी-विंडो

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

• [C-1-1] Android SDK मल्टी-विंडो मोड के साथ काम करने से जुड़े दस्तावेज़ में बताए गए ऐप्लिकेशन के व्यवहार और एपीआई के मुताबिक, मल्टी-विंडो मोड लागू करना ज़रूरी है. साथ ही, इन ज़रूरी शर्तों को पूरा करना भी ज़रूरी है:
• [C-1-2] इस SDK में बताए गए तरीके के मुताबिक, ऐप्लिकेशन की ओर से AndroidManifest.xml फ़ाइल में सेट किए गए android:resizeableActivity का पालन करना ज़रूरी है.
• [C-1-3] अगर स्क्रीन की ऊंचाई 440 डीपी से कम है और स्क्रीन की चौड़ाई 440 डीपी से कम है, तो स्प्लिट-स्क्रीन या फ़्रीफ़ॉर्म मोड की सुविधा नहीं देनी चाहिए.
• [C-1-4] मल्टी-विंडो मोड में, किसी गतिविधि का साइज़ 220 डीपी से कम नहीं होना चाहिए. हालांकि, पिक्चर-इन-पिक्चर मोड में ऐसा हो सकता है.
• स्क्रीन साइज़ xlarge वाले डिवाइसों में, फ़्रीफ़ॉर्म मोड काम करना चाहिए.

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

• [C-2-1] डिफ़ॉल्ट रूप से, रीसाइज़ किए जा सकने वाले लॉन्चर को प्रीलोड करना ज़रूरी है.
• [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() एपीआई का इस्तेमाल करना ज़रूरी है.
• [C-3-3] में, setAspectRatio() एपीआई के ज़रिए पीआईपी गतिविधि में बताए गए आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) का इस्तेमाल किया जाना चाहिए. यह अनुपात 1:2.39 से ज़्यादा या उसके बराबर और 2.39:1 से कम या उसके बराबर होना चाहिए.
• [C-3-4] पीआईपी विंडो को कंट्रोल करने के लिए, KeyEvent.KEYCODE_WINDOW का इस्तेमाल करना ज़रूरी है. अगर पीआईपी मोड लागू नहीं किया गया है, तो यह बटन फ़ोरग्राउंड गतिविधि के लिए उपलब्ध होना चाहिए.
• [C-3-5] ऐप्लिकेशन को, उपयोगकर्ता को यह सुविधा देनी होगी कि वह ऐप्लिकेशन को पीआईपी मोड में दिखने से रोक सके. AOSP में इस सुविधा को लागू किया गया है. इसमें सूचना पैनल में कंट्रोल होते हैं.
• [C-3-6] Configuration.uiMode को UI_MODE_TYPE_TELEVISION के तौर पर कॉन्फ़िगर किए जाने पर, पीआईपी विंडो की चौड़ाई और लंबाई कम से कम 108 डीपी होनी चाहिए. साथ ही, पीआईपी विंडो की चौड़ाई कम से कम 240 डीपी और लंबाई 135 डीपी होनी चाहिए.

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

Android, एसडीके के दस्तावेज़ में बताए गए तरीके से डिसप्ले कटआउट की सुविधा देता है. DisplayCutout एपीआई, डिसप्ले के किनारे पर मौजूद एक ऐसे क्षेत्र को तय करता है जहां कॉन्टेंट नहीं दिखाया जा सकता.

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

• [C-1-1] डिवाइस के छोटे किनारे पर ही कटआउट होने चाहिए. इसके उलट, अगर डिवाइस का आसपेक्ट रेशियो(लंबाई-चौड़ाई का अनुपात) 1.0(1:1) है, तो उनमें कटआउट नहीं होने चाहिए.
• [C-1-2] हर किनारे पर एक से ज़्यादा कटआउट नहीं होने चाहिए.
• [C-1-3] एसडीके में बताए गए तरीके के मुताबिक, WindowManager.LayoutParams एपीआई के ज़रिए ऐप्लिकेशन से सेट किए गए डिसप्ले कटआउट फ़्लैग का पालन करना ज़रूरी है.
• [C-1-4] DisplayCutout एपीआई में तय की गई सभी कटआउट मेट्रिक के लिए, सही वैल्यू रिपोर्ट करनी चाहिए.

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

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

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

• [C-1-1] android.software.device_admin का एलान करना ज़रूरी है.
• [C-1-2] में, डिवाइस के मालिक के लिए प्रोविज़निंग की सुविधा होनी चाहिए. इसके बारे में सेक्शन 3.9.1 और सेक्शन 3.9.1.1 में बताया गया है.

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

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

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

• [C-1-1] डिवाइस में, डिवाइस नीति क्लाइंट (डीपीसी) को डिवाइस के मालिक वाले ऐप्लिकेशन के तौर पर रजिस्टर करने की सुविधा होनी चाहिए. इसके लिए, यहां दिया गया तरीका अपनाएं:
  • जब डिवाइस पर उपयोगकर्ता का कोई डेटा कॉन्फ़िगर नहीं किया गया होता है, तो:
    • [C-1-3] DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE) के लिए true की जानकारी देना ज़रूरी है.
    • [C-1-4] DPC ऐप्लिकेशन को डिवाइस के मालिक वाले ऐप्लिकेशन के तौर पर रजिस्टर करना ज़रूरी है. ऐसा इंटेंट ऐक्शन android.app.action.PROVISION_MANAGED_DEVICE के जवाब में किया जाना चाहिए.
    • [C-1-5] अगर डिवाइस, फ़ीचर फ़्लैग android.hardware.nfc के ज़रिए नियर-फ़ील्ड कम्यूनिकेशन (एनएफ़सी) की सुविधा के बारे में बताता है और उसे MIME_TYPE_PROVISIONING_NFC MIME टाइप वाला रिकॉर्ड शामिल करने वाला एनएफ़सी मैसेज मिलता है, तो DPC ऐप्लिकेशन को डिवाइस के मालिक के तौर पर रजिस्टर करना होगा.
  • अगर डिवाइस पर उपयोगकर्ता का डेटा मौजूद है, तो:
    • [C-1-6] DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE) के लिए, false की जानकारी देना ज़रूरी है.
    • [C-1-7] अब किसी भी DPC ऐप्लिकेशन को डिवाइस के मालिक के तौर पर रजिस्टर नहीं करना चाहिए.
• [C-1-2] डिवाइस के मालिक के तौर पर ऐप्लिकेशन को सेट करने की प्रोसेस के दौरान, सहमति देने के लिए कुछ ज़रूरी कार्रवाई करनी होगी. सहमति, उपयोगकर्ता की कार्रवाई के ज़रिए या डिवाइस को चालू करने के दौरान प्रोग्राम के ज़रिए ली जा सकती है. हालांकि, इसे हार्ड कोड नहीं किया जाना चाहिए. साथ ही, इससे डिवाइस के मालिक के अन्य ऐप्लिकेशन के इस्तेमाल पर रोक नहीं लगनी चाहिए.

अगर डिवाइसों पर android.software.device_admin लागू किया गया है, लेकिन उनमें डिवाइस के मालिक के तौर पर काम करने वाले मैनेजमेंट सलूशन को भी शामिल किया गया है. साथ ही, उनके पास ऐसा तरीका है जिससे वे अपने सलूशन में कॉन्फ़िगर किए गए किसी ऐप्लिकेशन को, स्टैंडर्ड Android DevicePolicyManager एपीआई के ज़रिए पहचाने गए स्टैंडर्ड "डिवाइस के मालिक" के तौर पर "डिवाइस के मालिक के बराबर" प्रमोट कर सकते हैं, तो:

• [C-2-1] यह पुष्टि करने के लिए कि जिस ऐप्लिकेशन का प्रमोशन किया जा रहा है वह एंटरप्राइज़ डिवाइस मैनेजमेंट के भरोसेमंद समाधान से जुड़ा है, उसके पास एक प्रोसेस होनी चाहिए. साथ ही, यह पुष्टि करने के लिए कि उसे मालिकाना समाधान में पहले से कॉन्फ़िगर किया गया है, ताकि उसके पास "डिवाइस के मालिक" के बराबर अधिकार हों.
• [C-2-2] DPC ऐप्लिकेशन को "डिवाइस का मालिक" के तौर पर रजिस्टर करने से पहले, android.app.action.PROVISION_MANAGED_DEVICE की ओर से शुरू किए गए फ़्लो में, AOSP डिवाइस के मालिक की सहमति से जुड़ी जानकारी दिखनी चाहिए.
• डीपीसी ऐप्लिकेशन को "डिवाइस का मालिक" के तौर पर रजिस्टर करने से पहले, डिवाइस पर उपयोगकर्ता का डेटा मौजूद हो सकता है.

3.9.1.2 मैनेज की जा रही प्रोफ़ाइल को चालू करना

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

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

• [C-1-2] मैनेज की जा रही प्रोफ़ाइल को चालू करने की प्रोसेस (android.app.action.PROVISION_MANAGED_PROFILE से शुरू होने वाला फ़्लो) का उपयोगकर्ता अनुभव, एओएसपी के साथ काम करने वाला होना चाहिए.

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

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

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

3.9.3 मैनेज किए जा रहे उपयोगकर्ता के लिए सहायता

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

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

3.10. सुलभता

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

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

• [C-1-1] सुलभता एपीआई के एसडीके के दस्तावेज़ में बताए गए तरीके के मुताबिक, Android accessibility framework को लागू करना ज़रूरी है.
• [C-1-2] SDK में दिए गए दस्तावेज़ के मुताबिक, सुलभता इवेंट जनरेट करने होंगे. साथ ही, रजिस्टर किए गए सभी AccessibilityService को सही AccessibilityEvent डिलीवर करना होगा.
• [C-1-3] android.settings.ACCESSIBILITY_SETTINGS का पालन करना ज़रूरी है. इसका मकसद, तीसरे पक्ष की ऐक्सेसिबिलिटी सेवाओं के साथ-साथ पहले से इंस्टॉल की गई ऐक्सेसिबिलिटी सेवाओं को चालू और बंद करने के लिए, उपयोगकर्ता के लिए उपलब्ध एक तरीका देना है.
• [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. टीवी इनपुट फ़्रेमवर्क

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

अगर डिवाइस में TIF फ़ाइलें इस्तेमाल की जा सकती हैं, तो:

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

3.13. क्विक सेटिंग

Android में क्विक सेटिंग का यूज़र इंटरफ़ेस (यूआई) कॉम्पोनेंट होता है. इससे, अक्सर इस्तेमाल की जाने वाली या तुरंत ज़रूरी कार्रवाइयों को तुरंत ऐक्सेस किया जा सकता है.

अगर डिवाइस में क्विक सेटिंग यूज़र इंटरफ़ेस (यूआई) कॉम्पोनेंट शामिल है, तो:

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

3.14. मीडिया यूज़र इंटरफ़ेस (यूआई)

अगर डिवाइसों में ऐसे ऐप्लिकेशन (ऐप्लिकेशन) शामिल हैं जिन्हें आवाज़ से चालू नहीं किया जाता है और जो MediaBrowser या MediaSession के ज़रिए तीसरे पक्ष के ऐप्लिकेशन के साथ इंटरैक्ट करते हैं, तो ऐप्लिकेशन:

• [C-1-2] MediaDescription में बताए गए तरीके के मुताबिक, getIconBitmap() या getIconUri() से मिले आइकॉन और getTitle() से मिले टाइटल को साफ़ तौर पर दिखाना ज़रूरी है. सुरक्षा से जुड़े नियमों का पालन करने के लिए, टाइटल छोटे किए जा सकते हैं. उदाहरण के लिए, ड्राइवर का ध्यान भटकाने वाले कॉन्टेंट से जुड़े नियम.

• [C-1-3] तीसरे पक्ष के इस ऐप्लिकेशन से मिले कॉन्टेंट को दिखाते समय, तीसरे पक्ष के ऐप्लिकेशन का आइकॉन दिखाना ज़रूरी है.

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

• [C-1-5] MediaSession.Callback#onMediaButtonEvent के लिए, KEYCODE_HEADSETHOOK या KEYCODE_MEDIA_PLAY_PAUSE को दो बार टैप करने को KEYCODE_MEDIA_NEXT के तौर पर माना जाना चाहिए.

3.15. Instant Apps

डिवाइसों पर लागू किए गए सिस्टम को इन ज़रूरी शर्तों को पूरा करना होगा:

• [C-0-1] इंस्टेंट ऐप्लिकेशन को सिर्फ़ वे अनुमतियां दी जानी चाहिए जिनके लिए android:protectionLevel को "instant" पर सेट किया गया है.
• [C-0-2] झटपट ऐप्लिकेशन, इंस्टॉल किए गए ऐप्लिकेशन के साथ इंप्लिसिट इंटेंट के ज़रिए इंटरैक्ट नहीं कर सकते. हालांकि, ऐसा तब किया जा सकता है, जब इनमें से कोई एक शर्त पूरी होती हो:
  • कॉम्पोनेंट का इंटेंट पैटर्न फ़िल्टर चालू है और उसमें CATEGORY_BROWSABLE मौजूद है
  • ऐक्शन, ACTION_SEND, ACTION_SENDTO या ACTION_SEND_MULTIPLE में से कोई एक हो
  • टारगेट को android:visibleToInstantApps के साथ साफ़ तौर पर दिखाया गया हो
• [C-0-3] इंस्टैंट ऐप्लिकेशन को इंस्टॉल किए गए ऐप्लिकेशन के साथ साफ़ तौर पर इंटरैक्ट नहीं करना चाहिए. हालांकि, अगर कॉम्पोनेंट को android:visibleToInstantApps के ज़रिए दिखाया जाता है, तो ऐसा किया जा सकता है.
• [C-0-4] इंस्टॉल किए गए ऐप्लिकेशन को डिवाइस पर मौजूद इंस्टैंट ऐप्लिकेशन के बारे में जानकारी नहीं दिखनी चाहिए. ऐसा तब तक नहीं होना चाहिए, जब तक इंस्टैंट ऐप्लिकेशन, इंस्टॉल किए गए ऐप्लिकेशन से साफ़ तौर पर कनेक्ट न हो.
• डिवाइसों में, Instant Apps के साथ इंटरैक्ट करने के लिए उपयोगकर्ताओं को ये सुविधाएं ज़रूर मिलनी चाहिए. AOSP, डिफ़ॉल्ट सिस्टम यूज़र इंटरफ़ेस (यूआई), सेटिंग, और लॉन्चर के साथ ज़रूरी शर्तों को पूरा करता है. डिवाइसों पर लागू करने से जुड़ी जानकारी:
  • [C-0-5] उपयोगकर्ता को, हर ऐप्लिकेशन पैकेज के लिए स्थानीय तौर पर कैश मेमोरी में सेव किए गए झटपट ऐप्लिकेशन को देखने और मिटाने की सुविधा देनी होगी.
  • [C-0-6] इंस्टैंट ऐप्लिकेशन के फ़ोरग्राउंड में चलने के दौरान, उपयोगकर्ता को ऐसी सूचना दिखनी चाहिए जिसे छोटा किया जा सके. उपयोगकर्ता को मिलने वाली इस सूचना में यह जानकारी ज़रूर शामिल होनी चाहिए कि इंस्टैंट ऐप्लिकेशन को इंस्टॉल करने की ज़रूरत नहीं होती. साथ ही, इसमें उपयोगकर्ता को एक ऐसा विकल्प मिलना चाहिए जिससे वह सेटिंग में जाकर ऐप्लिकेशन की जानकारी वाली स्क्रीन पर जा सके. वेब इंटेंट के ज़रिए लॉन्च किए गए इंस्टेंट ऐप्लिकेशन के लिए, कार्रवाई को Intent.ACTION_VIEW पर सेट करके और "http" या "https" स्कीम का इस्तेमाल करके इंटेंट को तय किया जाता है. ऐसे में, उपयोगकर्ता को एक अतिरिक्त विकल्प मिलना चाहिए. इससे वह इंस्टेंट ऐप्लिकेशन लॉन्च न करके, उससे जुड़ा लिंक कॉन्फ़िगर किए गए वेब ब्राउज़र में लॉन्च कर सके. हालांकि, ऐसा तब ही किया जा सकता है, जब डिवाइस पर कोई ब्राउज़र उपलब्ध हो.
  • [C-0-7] अगर डिवाइस पर 'हाल ही के ऐप्लिकेशन' फ़ंक्शन उपलब्ध है, तो ऐप्लिकेशन को इस फ़ंक्शन से ऐक्सेस करने की अनुमति देनी होगी.

3.16. कंपैनियन डिवाइस को जोड़ना

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

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

• [C-1-1] FEATURE_COMPANION_DEVICE_SETUP फ़ीचर फ़्लैग के बारे में एलान करना ज़रूरी है .
• [C-1-2] यह पक्का करना ज़रूरी है कि android.companion पैकेज में मौजूद एपीआई पूरी तरह से लागू किए गए हों.
• [C-1-3] यह ज़रूरी है कि उपयोगकर्ता को यह चुनने/पुष्टि करने की सुविधा मिले कि कंपैनियन डिवाइस मौजूद है और काम कर रहा है.

3.17. ज़्यादा संसाधन इस्तेमाल करने वाले ऐप्लिकेशन

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

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

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

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

4. ऐप्लिकेशन पैकेजिंग की सुविधा के साथ काम करने की क्षमता

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

• [C-0-1] इसमें Android के आधिकारिक एसडीके में शामिल “aapt” टूल से जनरेट की गई Android “.apk” फ़ाइलों को इंस्टॉल और चलाने की सुविधा होनी चाहिए.
• ऊपर दी गई ज़रूरी शर्त को पूरा करना मुश्किल हो सकता है. इसलिए, डिवाइसों को AOSP के रेफ़रंस पैकेज मैनेजमेंट सिस्टम का इस्तेमाल करने का सुझाव दिया जाता है.

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

• [C-0-2] यह ज़रूरी है कि “.apk” फ़ाइलों की पुष्टि करने के लिए, APK सिग्नेचर स्कीम v3, APK सिग्नेचर स्कीम v2, और JAR signing का इस्तेमाल किया जा सके.
• [C-0-3] .apk, Android मेनिफ़ेस्ट, Dalvik बाइटकोड या RenderScript बाइटकोड फ़ॉर्मैट को इस तरह से नहीं बढ़ाया जाना चाहिए कि वे फ़ाइलें, ज़रूरी शर्तें पूरी करने वाले अन्य डिवाइसों पर सही तरीके से इंस्टॉल और रन न हो पाएं.

• [C-0-4] पैकेज के लिए, "इंस्टॉलर ऑफ़ रिकॉर्ड" के तौर पर सेट किए गए ऐप्लिकेशन के अलावा, किसी अन्य ऐप्लिकेशन को उपयोगकर्ता की पुष्टि के बिना ऐप्लिकेशन को साइलेंट तरीके से अनइंस्टॉल करने की अनुमति नहीं देनी चाहिए. इस बारे में, DELETE_PACKAGE अनुमति के लिए एसडीके में बताया गया है. सिर्फ़ दो मामलों में इस अनुमति की ज़रूरत नहीं होती. पहला, सिस्टम पैकेज वेरिफ़ायर ऐप्लिकेशन, PACKAGE_NEEDS_VERIFICATION इंटेंट को हैंडल करता है. दूसरा, स्टोरेज मैनेजर ऐप्लिकेशन, ACTION_MANAGE_STORAGE इंटेंट को हैंडल करता है.

• [C-0-5] में ऐसी गतिविधि होनी चाहिए जो android.settings.MANAGE_UNKNOWN_APP_SOURCES इंटेंट को हैंडल करती हो.

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

  • इसके लिए, REQUEST_INSTALL_PACKAGES अनुमति का एलान करना ज़रूरी है. इसके अलावा, android:targetSdkVersion को 24 या इससे कम पर सेट करना भी ज़रूरी है.
  • उपयोगकर्ता ने उसे नामालूम सोर्स से ऐप्लिकेशन इंस्टॉल करने की अनुमति दी हो.

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

• [C-0-7] ऐप्लिकेशन में कोई गतिविधि शुरू करने से पहले, उपयोगकर्ता को चेतावनी वाला डायलॉग दिखाना ज़रूरी है. इस डायलॉग में, सिस्टम एपीआई PackageManager.setHarmfulAppWarning के ज़रिए दी गई चेतावनी वाली स्ट्रिंग शामिल होनी चाहिए. यह स्ट्रिंग, उस ऐप्लिकेशन के लिए दी गई हो जिसे सिस्टम एपीआई PackageManager.setHarmfulAppWarning ने संभावित रूप से नुकसान पहुंचाने वाला ऐप्लिकेशन के तौर पर मार्क किया है.

• चेतावनी वाले डायलॉग पर, उपयोगकर्ता को ऐप्लिकेशन अनइंस्टॉल करने या लॉन्च करने का विकल्प देना चाहिए.

5. मल्टीमीडिया फ़ाइलों के साथ काम करने की सुविधा

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

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

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

• SHOULD aim for minimum codec latency, in others words, they
  • इनपुट बफ़र का इस्तेमाल नहीं करना चाहिए और उन्हें सेव नहीं करना चाहिए. साथ ही, प्रोसेस होने के बाद सिर्फ़ एक बार इनपुट बफ़र वापस करना चाहिए.
  • डिकोड किए गए बफ़र को स्टैंडर्ड (जैसे, एसपीएस) में तय की गई अवधि से ज़्यादा समय तक सेव नहीं करना चाहिए.
  • 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 API के ज़रिए, पीसीएम 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-11] xHE-AAC (ISO/IEC 23003-3 Extended HE AAC Profile, जिसमें USAC बेसलाइन प्रोफ़ाइल और ISO/IEC 23003-4 Dynamic Range Control Profile शामिल है)
• [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

अगर डिवाइस पर लागू किए गए सॉफ़्टवेयर, 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.
• [SR] यह सुझाव दिया जाता है कि ऊपर दी गई ज़रूरी शर्तें C-2-1 और C-2-2, सभी एएसी ऑडियो डिकोडर के लिए पूरी की गई हों.

USAC ऑडियो को डिकोड करते समय, MPEG-D (ISO/IEC 23003-4):

• [C-3-1] लाउडनेस और डीआरसी मेटाडेटा को MPEG-D DRC Dynamic Range Control Profile Level 1 के मुताबिक समझा और लागू किया जाना चाहिए.
• [C-3-2] डिकोडर को, इन android.media.MediaFormat कुंजियों के साथ सेट किए गए कॉन्फ़िगरेशन के मुताबिक काम करना चाहिए: KEY_AAC_DRC_TARGET_REFERENCE_LEVEL और KEY_AAC_DRC_EFFECT_TYPE.

MPEG-4 AAC, HE AAC, और HE AACv2 प्रोफ़ाइल डिकोडर:

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

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

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

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

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

5.1.3. ऑडियो कोडेक की जानकारी

5.1.4. इमेज एन्कोडिंग

ज़्यादा जानकारी के लिए, 5.1.6 देखें. इमेज कोडेक की जानकारी.

डिवाइस में सेट किए गए सिस्टम में, इमेज को इस तरह से एन्कोड करने की सुविधा होनी चाहिए:

• [C-0-1] JPEG
• [C-0-2] PNG
• [C-0-3] WebP

अगर डिवाइस में, मीडिया टाइप 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] HEIF (HEIC)

ज़्यादा बिट डेप्थ वाले फ़ॉर्मैट (हर चैनल के लिए 9 से ज़्यादा बिट) के साथ काम करने वाले इमेज डिकोडर

• [C-1-1] अगर ऐप्लिकेशन अनुरोध करता है, तो उसे 8-बिट के बराबर फ़ॉर्मैट में आउटपुट देना ज़रूरी है. उदाहरण के लिए, android.graphics.Bitmap के ARGB_8888 कॉन्फ़िगरेशन के ज़रिए.

5.1.6. इमेज कोडेक की जानकारी

MediaCodec API के ज़रिए इमेज एन्कोडर और डीकोडर उपलब्ध कराए जाते हैं

• [C-1-1] CodecCapabilities के ज़रिए, YUV420 8:8:8 फ़्लेक्सिबल कलर फ़ॉर्मैट (COLOR_FormatYUV420Flexible) को सपोर्ट करना ज़रूरी है.

• [SR] इनपुट सरफेस मोड के लिए, 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 के बराबर). हालांकि, दोनों को सपोर्ट करने का सुझाव दिया जाता है.

• [SR] वीडियो एन्कोडर और डिकोडर में, हार्डवेयर के हिसाब से ऑप्टिमाइज़ किए गए प्लानर या सेमीप्लानर 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. वीडियो कोडेक की सूची

5.1.9. मीडिया कोडेक की सुरक्षा

डिवाइसों को, मीडिया कोडेक की सुरक्षा से जुड़ी सुविधाओं का पालन करना होगा. इनके बारे में यहां बताया गया है.

Android में, OMX के साथ-साथ Codec 2.0 का इस्तेमाल किया जा सकता है. OMX, क्रॉस-प्लैटफ़ॉर्म मल्टीमीडिया ऐक्सलरेशन एपीआई है. वहीं, Codec 2.0, कम ओवरहेड वाला मल्टीमीडिया ऐक्सलरेशन एपीआई है.

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

• [C-1-1] Android ओपन सोर्स प्रोजेक्ट की तरह, OMX या Codec 2.0 API (या दोनों) के ज़रिए मीडिया कोडेक के लिए सहायता देनी होगी. साथ ही, सुरक्षा से जुड़ी सुविधाओं को बंद या नाकाम नहीं करना होगा. इसका मतलब यह नहीं है कि हर कोडेक को OMX या Codec 2.0 API का इस्तेमाल करना होगा. इसका मतलब सिर्फ़ यह है कि इनमें से कम से कम एक एपीआई के लिए सहायता उपलब्ध होनी चाहिए. साथ ही, उपलब्ध एपीआई के लिए सहायता में मौजूद सुरक्षा सुविधाओं को शामिल किया जाना चाहिए.
• [C-SR] Codec 2.0 API के साथ काम करने की सुविधा शामिल करने का सुझाव दिया जाता है.

अगर डिवाइसों पर Codec 2.0 API काम नहीं करता है, तो:

• [C-2-1] डिवाइस पर काम करने वाले हर मीडिया फ़ॉर्मैट और टाइप (एनकोडर या डिकोडर) के लिए, Android Open Source Project से जुड़ा OMX सॉफ़्टवेयर कोडेक शामिल करना ज़रूरी है. हालांकि, ऐसा तब ही किया जा सकता है, जब यह उपलब्ध हो.
• [C-2-2] "OMX.google." से शुरू होने वाले नाम वाले कोडेक यह Android Open Source Project के सोर्स कोड पर आधारित होना चाहिए.
• [C-SR] यह सुझाव दिया जाता है कि OMX सॉफ़्टवेयर कोडेक, कोडेक प्रोसेस में काम करें. इस प्रोसेस के पास मेमोरी मैपर के अलावा, अन्य हार्डवेयर ड्राइवर का ऐक्सेस न हो.

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

• [C-3-1] डिवाइस पर काम करने वाले हर मीडिया फ़ॉर्मैट और टाइप (एनकोडर या डिकोडर) के लिए, Android Open Source Project से जुड़ा Codec 2.0 सॉफ़्टवेयर कोडेक शामिल करना ज़रूरी है. हालांकि, ऐसा तब ही किया जा सकता है, जब यह उपलब्ध हो.
• [C-3-2] Android Open Source Project में दिए गए निर्देशों के मुताबिक, Codec 2.0 सॉफ़्टवेयर कोडेक को सॉफ़्टवेयर कोडेक प्रोसेस में शामिल करना ज़रूरी है. इससे, सॉफ़्टवेयर कोडेक का ऐक्सेस ज़्यादा सीमित तौर पर दिया जा सकेगा.
• [C-3-3] "c2.android." से शुरू होने वाले कोडेक यह Android Open Source Project के सोर्स कोड पर आधारित होना चाहिए.

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] कोडेक के नाम, गुमराह करने वाले नहीं होने चाहिए. उदाहरण के लिए, "डिकोडर" नाम वाले कोडेक में डिकोडिंग की सुविधा होनी चाहिए. साथ ही, "एनकोडर" नाम वाले कोडेक में एनकोडिंग की सुविधा होनी चाहिए. मीडिया फ़ॉर्मैट वाले नामों के साथ कोडेक, उन फ़ॉर्मैट के साथ काम करने चाहिए.

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

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

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

5.2. वीडियो एन्कोडिंग

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

• स्लाइडिंग विंडो के दो हिस्सों में, इंट्राफ़्रेम (आई-फ़्रेम) इंटरवल के बीच बिटरेट में 15% से ज़्यादा का अंतर नहीं होना चाहिए.
• एक सेकंड की स्लाइडिंग विंडो में, बिटरेट 100% से ज़्यादा नहीं होना चाहिए.

अगर डिवाइसों में कम से कम 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] हार्डवेयर से तेज़ किए गए सभी वीडियो और इमेज एन्कोडर को, हार्डवेयर कैमरे से फ़्रेम एन्कोड करने की सुविधा देनी होगी.
• सभी वीडियो या इमेज एन्कोडर के ज़रिए, हार्डवेयर कैमरे से फ़्रेम एन्कोड करने की सुविधा होनी चाहिए.

5.2.1. H.263

अगर डिवाइस पर H.263 एन्कोडर काम करते हैं और तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध हैं, तो:

• [C-1-1] बेसलाइन प्रोफ़ाइल लेवल 45 के साथ काम करना ज़रूरी है.
• सपोर्ट किए गए एनकोडर के लिए, डाइनैमिक रूप से कॉन्फ़िगर किए जा सकने वाले बिटरेट के साथ काम करना चाहिए.

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] यहां दी गई टेबल में मौजूद एन्कोडिंग प्रोफ़ाइलों के साथ काम करना ज़रूरी है.

5.2.3. VP8

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

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

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

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

5.2.4. VP9

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

• [C-1-2] Profile 0 Level 3 के साथ काम करना ज़रूरी है.
• [C-1-1] Matroska WebM फ़ाइलें लिखने की सुविधा होनी चाहिए.
• [C-1-3] CodecPrivate डेटा जनरेट करना ज़रूरी है.
• इसमें एचडी डिकोडिंग प्रोफ़ाइलों के लिए सहायता होनी चाहिए. इसके बारे में यहां दी गई टेबल में बताया गया है.
• [SR] अगर कोई हार्डवेयर एन्कोडर है, तो यहां दी गई टेबल में बताई गई एचडी डिकोडिंग प्रोफ़ाइलों के साथ काम करने का सुझाव दिया जाता है.

अगर डिवाइस में लागू किए गए सिस्टम, Media API के ज़रिए Profile 2 या Profile 3 के साथ काम करने का दावा करते हैं, तो:

• 12-बिट फ़ॉर्मैट का इस्तेमाल करना ज़रूरी नहीं है.

5.2.5. H.265

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

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

5.3. वीडियो डिकोडिंग

अगर डिवाइसों में VP8, VP9, H.264 या H.265 कोडेक काम करते हैं, तो:

• [C-1-1] यह ज़रूरी है कि डिवाइस में मौजूद VP8, VP9, H.264, और H.265 कोडेक के लिए, एक ही स्ट्रीम में Android के स्टैंडर्ड एपीआई के ज़रिए वीडियो रिज़ॉल्यूशन और फ़्रेम रेट को डाइनैमिक तरीके से स्विच किया जा सके. ऐसा रीयल टाइम में और डिवाइस पर हर कोडेक के लिए उपलब्ध ज़्यादा से ज़्यादा रिज़ॉल्यूशन तक किया जाना चाहिए.

5.3.1. MPEG-2

अगर डिवाइस में MPEG-2 डिकोडर काम करते हैं, तो:

• [C-1-1] यह ज़रूरी है कि डिवाइस, Main Profile High Level के साथ काम करता हो.

5.3.2. H.263

अगर डिवाइस में H.263 डिकोडर काम करते हैं, तो:

• [C-1-1] बेसलाइन प्रोफ़ाइल Level 30 और Level 45 के साथ काम करना ज़रूरी है.

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 पिक्सल वीडियो डिकोडिंग प्रोफ़ाइलों के साथ काम करना ज़रूरी है.

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 डिकोडिंग में से कम से कम एक को सपोर्ट करना ज़रूरी है.

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

• [C-3-1] डिवाइसों को MediaCodec API का इस्तेमाल करके, ऐप्लिकेशन से मिले ज़रूरी एचडीआर मेटाडेटा (सभी एचडीआर प्रोफ़ाइलों के लिए MediaFormat#KEY_HDR_STATIC_INFO) को स्वीकार करना होगा. साथ ही, उन्हें बिटस्ट्रीम और/या कंटेनर से ज़रूरी एचडीआर मेटाडेटा (सभी एचडीआर प्रोफ़ाइलों के लिए MediaFormat#KEY_HDR_STATIC_INFO और HDR10Plus प्रोफ़ाइलों के लिए MediaFormat#KEY_HDR10_PLUS_INFO) निकालने की सुविधा देनी होगी. यह सुविधा, संबंधित स्पेसिफ़िकेशन के मुताबिक होनी चाहिए. यह भी ज़रूरी है कि वे बिटस्ट्रीम और/या कंटेनर से, ज़रूरी एचडीआर मेटाडेटा (सभी एचडीआर प्रोफ़ाइलों के लिए MediaFormat#KEY_HDR_STATIC_INFO) को आउटपुट कर सकें. ऐसा, संबंधित खास बातों के मुताबिक होना चाहिए.

• [C-SR] डिवाइसों पर, MediaCodec#getOutputFormat(int). के ज़रिए HDR10Plus प्रोफ़ाइलों के लिए, MediaFormat#KEY_HDR10_PLUS_INFO मेटाडेटा को आउटपुट करने की सुविधा होनी चाहिए. हमारा सुझाव है कि डिवाइसों पर यह सुविधा ज़रूर होनी चाहिए

• [C-3-2] डिवाइसों को, डिवाइस की स्क्रीन या स्टैंडर्ड वीडियो आउटपुट पोर्ट (जैसे, एचडीएमआई) पर HEVCProfileMain10HDR10 प्रोफ़ाइल के लिए, एचडीआर कॉन्टेंट को सही तरीके से डिसप्ले करना होगा.

• [C-SR] डिवाइसों पर, HEVCProfileMain10HDR10Plus प्रोफ़ाइल के लिए एचडीआर कॉन्टेंट को सही तरीके से दिखाने का सुझाव दिया जाता है. ऐसा डिवाइस की स्क्रीन पर या स्टैंडर्ड वीडियो आउटपुट पोर्ट (जैसे, एचडीएमआई) पर किया जा सकता है.

5.3.6. VP8

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

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

अगर Display.getSupportedModes() तरीके से रिपोर्ट की गई ऊंचाई, वीडियो रिज़ॉल्यूशन के बराबर या उससे ज़्यादा है, तो:

• [C-2-1] डिवाइसों में, यहां दी गई टेबल में बताई गई 720p प्रोफ़ाइलें काम करनी चाहिए.
• [C-2-2] डिवाइसों में, यहां दी गई टेबल में बताई गई 1080 पिक्सल की प्रोफ़ाइलें काम करनी चाहिए.

5.3.7. VP9

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

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

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

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

अगर Display.getSupportedModes() तरीके से रिपोर्ट की गई ऊंचाई, वीडियो रिज़ॉल्यूशन के बराबर या उससे ज़्यादा है, तो:

• [C-3-1] डिवाइसों में, 720, 1080, और यूएचडी प्रोफ़ाइलों के लिए, VP9 या H.265 में से कम से कम एक कोडेक का इस्तेमाल करके डिकोडिंग की सुविधा होनी चाहिए.

अगर डिवाइस में सेट किए गए सिस्टम, 'CodecProfileLevel' मीडिया एपीआई के ज़रिए VP9Profile2 या VP9Profile3 के साथ काम करने का दावा करते हैं, तो:

• 12-बिट फ़ॉर्मैट का इस्तेमाल करना ज़रूरी नहीं है.

अगर डिवाइसों में मीडिया एपीआई के ज़रिए, एचडीआर प्रोफ़ाइल (VP9Profile2HDR, VP9Profile2HDR10Plus, VP9Profile3HDR, VP9Profile3HDR10Plus) के साथ काम करने का दावा किया जाता है, तो:

• [C-4-1] डिवाइसों को MediaCodec API का इस्तेमाल करके, ऐप्लिकेशन से मिले ज़रूरी एचडीआर मेटाडेटा को स्वीकार करना होगा. इसमें सभी एचडीआर प्रोफ़ाइलों के लिए MediaFormat#KEY_HDR_STATIC_INFO और HDR10Plus प्रोफ़ाइलों के लिए पैरामीटर MediaCodec#PARAMETER_KEY_HDR10_PLUS_INFO शामिल हैं. साथ ही, उन्हें बिटस्ट्रीम और/या कंटेनर से ज़रूरी एचडीआर मेटाडेटा को निकालने की सुविधा देनी होगी. इसमें सभी एचडीआर प्रोफ़ाइलों के लिए MediaFormat#KEY_HDR_STATIC_INFO और HDR10Plus प्रोफ़ाइलों के लिए MediaFormat#KEY_HDR10_PLUS_INFO शामिल हैं. यह मेटाडेटा, संबंधित स्पेसिफ़िकेशन के मुताबिक होना चाहिए. साथ ही, उन्हें बिटस्ट्रीम और/या कंटेनर से ज़रूरी एचडीआर मेटाडेटा (सभी एचडीआर प्रोफ़ाइलों के लिए MediaFormat#KEY_HDR_STATIC_INFO) को आउटपुट करने की सुविधा देनी होगी. यह सुविधा, ज़रूरी शर्तों के मुताबिक होनी चाहिए.

• [C-4-2] डिवाइसों को, डिवाइस की स्क्रीन या स्टैंडर्ड वीडियो आउटपुट पोर्ट (जैसे, एचडीएमआई) पर VP9Profile2HDR और VP9Profile3HDR प्रोफ़ाइलों के लिए, एचडीआर कॉन्टेंट को सही तरीके से डिसप्ले करना होगा.

• [C-SR] डिवाइसों में, MediaCodec#getOutputFormat(int) के ज़रिए HDR10Plus प्रोफ़ाइलों के लिए, मेटाडेटा MediaFormat#KEY_HDR10_PLUS_INFO को आउटपुट करने की सुविधा देने का सुझाव दिया जाता है.

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

5.3.8. Dolby Vision

अगर डिवाइस में सेट किए गए सिस्टम, HDR_TYPE_DOLBY_VISION के ज़रिए Dolby Vision डिकोडर के साथ काम करने की सुविधा के बारे में बताते हैं, तो:

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

5.3.9. AV1

अगर डिवाइस में AV1 कोडेक काम करता है, तो:

• [C-1-1] इसमें 10-बिट कॉन्टेंट के साथ-साथ, प्रोफ़ाइल 0 के साथ काम करने की सुविधा होनी चाहिए.

5.4. ऑडियो रिकॉर्डिंग

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

5.4.1. रॉ ऑडियो कैप्चर और माइक्रोफ़ोन की जानकारी

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

• [C-1-1] डिवाइस में, रॉ ऑडियो कॉन्टेंट को कैप्चर करने की सुविधा होनी चाहिए. इसमें ये विशेषताएं होनी चाहिए:

  • फ़ॉर्मैट: लीनियर पीसीएम, 16-बिट
  • सैंपलिंग रेट: 8000, 11025, 16000, 44100, 48000 हर्ट्ज़
  • चैनल: मोनो

• इसमें रॉ ऑडियो कॉन्टेंट को कैप्चर करने की सुविधा होनी चाहिए. साथ ही, इसमें ये विशेषताएं होनी चाहिए:

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

• [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 हर्ट्ज़ तक ±3 डीबी.
• आवाज़ पहचानने की सुविधा के लिए, ऑडियो स्ट्रीम को रिकॉर्ड करना चाहिए. इसके लिए, इनपुट सेंसिटिविटी को इस तरह से सेट किया जाना चाहिए कि 1000 हर्ट्ज़ पर 90 dB साउंड पावर लेवल (एसपीएल) सोर्स, 16-बिट सैंपल के लिए 2500 का आरएमएस दे.
• आवाज़ पहचानने की सुविधा के लिए ऑडियो स्ट्रीम रिकॉर्ड की जानी चाहिए, ताकि पीसीएम ऐम्प्लिट्यूड लेवल, माइक्रोफ़ोन पर -18 dB से +12 dB re 90 dB एसपीएल तक कम से कम 30 dB की रेंज में, इनपुट एसपीएल में हुए बदलावों को लीनियर तरीके से ट्रैक कर सकें.
• आवाज़ पहचानने की सुविधा के लिए, ऑडियो स्ट्रीम को रिकॉर्ड करना चाहिए. इसमें 1 किलोहर्ट्ज़ की फ़्रीक्वेंसी वाले 90 dB एसपीएल इनपुट लेवल पर, माइक्रोफ़ोन के लिए टोटल हार्मोनिक डिस्टॉर्शन (टीएचडी) 1% से कम होना चाहिए.

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

• [C-2-1] इस ऑडियो इफ़ेक्ट को android.media.audiofx.NoiseSuppressor API से कंट्रोल किया जा सकता है.
• [C-2-2] AudioEffect.Descriptor.uuid फ़ील्ड के ज़रिए, शोर को दबाने की टेक्नोलॉजी के हर इस्तेमाल की खास तौर पर पहचान करना ज़रूरी है.

5.4.3. प्लेबैक को फिर से रूट करने के लिए कैप्चर करना

android.media.MediaRecorder.AudioSource क्लास में REMOTE_SUBMIX ऑडियो सोर्स शामिल होता है.

अगर डिवाइसों में android.hardware.audio.output और android.hardware.microphone, दोनों को सेट किया गया है, तो:

• [C-1-1] REMOTE_SUBMIX ऑडियो सोर्स को सही तरीके से लागू करना ज़रूरी है, ताकि जब कोई ऐप्लिकेशन इस ऑडियो सोर्स से रिकॉर्ड करने के लिए android.media.AudioRecord API का इस्तेमाल करे, तो वह इन ऑडियो स्ट्रीम को छोड़कर बाकी सभी ऑडियो स्ट्रीम को कैप्चर करे:

  • AudioManager.STREAM_RING
  • AudioManager.STREAM_ALARM
  • AudioManager.STREAM_NOTIFICATION

5.4.4. अकूस्टिक इको कैंसलर

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

• आवाज़ से बातचीत करने के लिए, ध्वनि को गूंजने से रोकने वाली (एईसी) टेक्नोलॉजी का इस्तेमाल करना चाहिए. साथ ही, AudioSource.VOICE_COMMUNICATION का इस्तेमाल करके कैप्चर करते समय, इसे कैप्चर पाथ पर लागू करना चाहिए

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

• [C-SR] AcousticEchoCanceler API के AcousticEchoCanceler.isAvailable() तरीके का इस्तेमाल करके, इस बारे में जानकारी देने का सुझाव दिया जाता है
• [C-SR] AcousticEchoCanceler API की मदद से, इस ऑडियो इफ़ेक्ट को कंट्रोल करने की अनुमति देने का सुझाव दिया जाता है.
• [C-SR] AudioEffect.Descriptor.uuid फ़ील्ड के ज़रिए, एईसी टेक्नोलॉजी के हर इस्तेमाल की खास तौर पर पहचान करने का सुझाव दिया जाता है.

5.4.5. एक साथ कैप्चर करने की सुविधा

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

• [C-1-1] सुलभता सेवा को AudioSource.VOICE_RECOGNITION के साथ-साथ, कम से कम एक ऐसे ऐप्लिकेशन को माइक्रोफ़ोन का ऐक्सेस देना ज़रूरी है जो किसी AudioSource के साथ कैप्चर करता हो.
• [C-1-2] डिवाइस में पहले से इंस्टॉल किए गए ऐसे ऐप्लिकेशन को माइक्रोफ़ोन का ऐक्सेस एक साथ मिलना चाहिए जो Assistant की भूमिका निभाता है. साथ ही, कम से कम एक ऐसे ऐप्लिकेशन को भी माइक्रोफ़ोन का ऐक्सेस एक साथ मिलना चाहिए जो AudioSource.VOICE_COMMUNICATION या AudioSource.CAMCORDER को छोड़कर, किसी भी AudioSource के साथ कैप्चर करता है.
• [C-1-3] जब कोई ऐप्लिकेशन AudioSource.VOICE_COMMUNICATION या AudioSource.CAMCORDER का इस्तेमाल करके ऑडियो कैप्चर कर रहा हो, तब उसे सुलभता सेवा के अलावा किसी अन्य ऐप्लिकेशन के लिए ऑडियो कैप्चर करने की सुविधा बंद करनी होगी. हालांकि, अगर कोई ऐप्लिकेशन AudioSource.VOICE_COMMUNICATION के ज़रिए कैप्चर कर रहा है, तो दूसरा ऐप्लिकेशन वॉइस कॉल को कैप्चर कर सकता है. इसके लिए, यह ज़रूरी है कि वह ऐप्लिकेशन, विशेषाधिकार वाला (पहले से इंस्टॉल) ऐप्लिकेशन हो और उसके पास CAPTURE_AUDIO_OUTPUT की अनुमति हो.
• [C-1-4] अगर दो या उससे ज़्यादा ऐप्लिकेशन एक साथ ऑडियो कैप्चर कर रहे हैं और किसी भी ऐप्लिकेशन का यूज़र इंटरफ़ेस (यूआई) सबसे ऊपर नहीं है, तो ऑडियो उस ऐप्लिकेशन को मिलेगा जिसने हाल ही में कैप्चर करना शुरू किया है.

5.4.6. माइक्रोफ़ोन के गेन लेवल

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

• मिड-फ़्रीक्वेंसी रेंज में, एंप्लीट्यूड-वर्सेस-फ़्रीक्वेंसी की विशेषताएं लगभग एक जैसी होनी चाहिए: खास तौर पर, आवाज़ पहचानने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन के लिए, 100 हर्ट्ज़ से 4,000 हर्ट्ज़ तक ±3dB.
• ऑडियो इनपुट की सेंसिटिविटी इस तरह से सेट की जानी चाहिए कि 90 dB के साउंड प्रेशर लेवल (एसपीएल) पर 1,000 हर्ट्ज़ का साइनसोडल टोन सोर्स चलाने पर, 16 बिट-सैंपल के लिए 2,500 का आरएमएस (या फ़्लोटिंग पॉइंट/डबल प्रिसिशन सैंपल के लिए -22.35 dB फ़ुल स्केल) मिले. ऐसा हर उस माइक्रोफ़ोन के लिए होना चाहिए जिसका इस्तेमाल, आवाज़ पहचानने वाले ऑडियो सोर्स को रिकॉर्ड करने के लिए किया जाता है.
• [C-SR] में, कम फ़्रीक्वेंसी रेंज में ऐम्प्लिट्यूड लेवल दिखाने का सुझाव दिया जाता है. खास तौर पर, आवाज़ की पहचान करने वाले ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन के लिए, मिड-फ़्रीक्वेंसी रेंज की तुलना में 5 हर्ट्ज़ से 100 हर्ट्ज़ तक ±20 dB.
• [C-SR] में, ज़्यादा फ़्रीक्वेंसी रेंज में ऐम्प्लिट्यूड लेवल दिखाने का सुझाव दिया जाता है. खास तौर पर, आवाज़ पहचानने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन के लिए, मिड-फ़्रीक्वेंसी रेंज की तुलना में 4000 हर्ट्ज़ से 22 किलोहर्ट्ज़ तक ±30 dB.

5.5. ऑडियो चलाने की सुविधा

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

5.5.1. रॉ ऑडियो प्लेबैक

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

• [C-1-1] डिवाइस में, रॉ ऑडियो कॉन्टेंट को चलाने की सुविधा होनी चाहिए. इसमें ये विशेषताएं होनी चाहिए:

  • सोर्स फ़ॉर्मैट: लीनियर पीसीएम, 16-बिट, 8-बिट, फ़्लोट
  • चैनल: मोनो, स्टीरियो, ज़्यादा से ज़्यादा आठ चैनलों के साथ मान्य मल्टीचैनल कॉन्फ़िगरेशन
  • सैंपलिंग की दर (हर्ट्ज़ में):
    • ऊपर दिए गए चैनल कॉन्फ़िगरेशन के लिए, 8000, 11025, 16000, 22050, 32000, 44100, 48000
    • मोनो और स्टीरियो में 96,000

• इसमें रॉ ऑडियो कॉन्टेंट को चलाने की सुविधा होनी चाहिए. साथ ही, इसमें ये विशेषताएं होनी चाहिए:

  • सैंपलिंग की दरें: 24000

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 के ज़रिए कंट्रोल किया जा सकता हो.
• इसमें EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB, और EFFECT_TYPE_VIRTUALIZER लागू करने की सुविधा होनी चाहिए. इन्हें AudioEffect सब-क्लास BassBoost, EnvironmentalReverb, PresetReverb, और Virtualizer के ज़रिए कंट्रोल किया जा सकता है.
• [C-SR] फ़्लोटिंग-पॉइंट और मल्टीचैनल में इफ़ेक्ट इस्तेमाल करने का सुझाव दिया जाता है.

5.5.3. ऑडियो आउटपुट वॉल्यूम

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

• कॉन्टेंट टाइप या इस्तेमाल के आधार पर, हर ऑडियो स्ट्रीम के लिए ऑडियो वॉल्यूम को अलग-अलग अडजस्ट करने की अनुमति होनी चाहिए. इसके लिए, AudioAttributes और कार के ऑडियो सिस्टम के इस्तेमाल के बारे में सार्वजनिक तौर पर उपलब्ध जानकारी android.car.CarAudioManager में दी गई परिभाषा का इस्तेमाल किया जाना चाहिए.

5.6. ऑडियो के इंतज़ार का समय

ऑडियो के इंतज़ार का समय, ऑडियो सिग्नल के सिस्टम से गुज़रने में लगने वाला समय होता है. कई तरह के ऐप्लिकेशन, रीयल-टाइम में साउंड इफ़ेक्ट पाने के लिए कम इंतज़ार के समय पर निर्भर करते हैं.

इस सेक्शन के लिए, यहां दी गई परिभाषाओं का इस्तेमाल करें:

• आउटपुट में लगने वाला समय. यह उस समय के बीच का अंतर होता है, जब कोई ऐप्लिकेशन पीसीएम-कोड किए गए डेटा का फ़्रेम लिखता है और जब डिवाइस पर मौजूद ट्रांसड्यूसर पर उससे जुड़ी आवाज़ सुनाई देती है. इसके अलावा, यह उस समय के बीच का अंतर भी होता है, जब सिग्नल किसी पोर्ट के ज़रिए डिवाइस से बाहर जाता है और उसे बाहर से देखा जा सकता है.
• कोल्ड आउटपुट में लगने वाला समय. पहले फ़्रेम के लिए आउटपुट में लगने वाला समय. ऐसा तब होता है, जब ऑडियो आउटपुट सिस्टम अनुरोध से पहले बंद हो गया हो.
• लगातार आउटपुट मिलने में लगने वाला समय. डिवाइस पर ऑडियो चलने के बाद, अगले फ़्रेम के लिए आउटपुट में लगने वाला समय.
• इनपुट के इंतज़ार का समय. यह वह समय होता है जब डिवाइस पर मौजूद ट्रांसड्यूसर या पोर्ट के ज़रिए, डिवाइस को परिवेश से कोई आवाज़ सुनाई जाती है और जब कोई ऐप्लिकेशन, पीसीएम-कोड वाले डेटा के फ़्रेम को पढ़ता है.
• इनपुट नहीं मिला. इनपुट सिग्नल का शुरुआती हिस्सा, जिसका इस्तेमाल नहीं किया जा सकता या जो उपलब्ध नहीं है.
• कोल्ड इनपुट के लिए इंतज़ार का समय. ऑडियो इनपुट सिस्टम के निष्क्रिय होने और अनुरोध से पहले बंद होने पर, पहले फ़्रेम के लिए इनपुट में लगने वाले समय और इनपुट में लगने वाले समय का योग.
• लगातार इनपुट लेटेन्सी. डिवाइस के ऑडियो कैप्चर करने के दौरान, बाद के फ़्रेम के लिए इनपुट लेटेन्सी.
• कोल्ड आउटपुट जिटर. कोल्ड आउटपुट की लेटेन्सी वैल्यू के अलग-अलग मेज़रमेंट के बीच का अंतर.
• कोल्ड इनपुट जिटर. कोल्ड इनपुट लेटेन्सी की वैल्यू के अलग-अलग मेज़रमेंट के बीच का अंतर.
• लगातार राउंड-ट्रिप में लगने वाला समय. यह लगातार इनपुट लेटेन्सी, लगातार आउटपुट लेटेन्सी, और एक बफ़र अवधि का योग होता है. बफ़र पीरियड से, ऐप्लिकेशन को सिग्नल प्रोसेस करने और इनपुट और आउटपुट स्ट्रीम के बीच फ़ेज़ के अंतर को कम करने का समय मिलता है.
• OpenSL ES PCM बफ़र क्यू एपीआई. Android NDK में, पीसीएम से जुड़े OpenSL ES एपीआई का सेट.
• AAudio native audio API. Android NDK में मौजूद AAudio एपीआई का सेट.
• timestamp. यह एक ऐसा पेयर होता है जिसमें स्ट्रीम में फ़्रेम की रिलेटिव पोज़िशन और वह अनुमानित समय शामिल होता है, जब वह फ़्रेम, ऑडियो प्रोसेसिंग पाइपलाइन में शामिल होता है या उससे बाहर निकलता है. AudioTimestamp भी देखें.
• glitch. ऑडियो सिग्नल में कुछ समय के लिए रुकावट या गलत सैंपल वैल्यू. आम तौर पर, यह आउटपुट के लिए बफ़र अंडररन, इनपुट के लिए बफ़र ओवररन या डिजिटल या ऐनलॉग नॉइज़ के किसी अन्य सोर्स की वजह से होता है.

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

• [C-1-1] AudioTrack.getTimestamp और AAudioStream_getTimestamp से मिले आउटपुट टाइमस्टैंप में +/- 2 मि॰से॰ तक का अंतर हो सकता है.
• [C-1-2] कोल्ड आउटपुट की लेटेन्सी 500 मिलीसेकंड या इससे कम हो.

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

• [C-SR] कोल्ड आउटपुट की लेटेन्सी 100 मिलीसेकंड या इससे कम हो. Android के इस वर्शन पर काम करने वाले मौजूदा और नए डिवाइसों को, अब इन ज़रूरी शर्तों को पूरा करने का सुझाव दिया जाता है. साल 2021 में, प्लैटफ़ॉर्म के आने वाले वर्शन में, कोल्ड आउटपुट लेटेन्सी 200 मि॰से॰ या इससे कम होना ज़रूरी है.
• [C-SR] लगातार आउटपुट मिलने में लगने वाला समय 45 मिलीसेकंड या इससे कम होना चाहिए.
• [C-SR] Minimize the cold output jitter.
• [C-SR] AudioTrack.getTimestamp और AAudioStream_getTimestamp से मिला आउटपुट टाइमस्टैंप, +/- 1 मि॰से॰ तक सटीक होता है.

अगर डिवाइस, ऊपर दी गई ज़रूरी शर्तों को पूरा करते हैं, तो शुरुआती कैलिब्रेशन के बाद, OpenSL ES PCM बफ़र क्यू और AAudio नेटिव ऑडियो एपीआई, दोनों का इस्तेमाल करने पर, कम से कम एक ऑडियो आउटपुट डिवाइस पर लगातार आउटपुट मिलने में लगने वाला समय और पहली बार आउटपुट मिलने में लगने वाला समय ये होना चाहिए:

• [C-SR] android.hardware.audio.low_latency फ़ीचर फ़्लैग के बारे में एलान करके, कम समय में ऑडियो ट्रांसफ़र करने की सुविधा के बारे में जानकारी देने का सुझाव दिया जाता है.
• [C-SR] AAudio API के ज़रिए, कम समय में ऑडियो ट्रांसफ़र करने की सुविधा से जुड़ी ज़रूरी शर्तों को पूरा करने का सुझाव दिया जाता है.
• [C-SR] यह सुझाव दिया जाता है कि AAudioStream_getPerformanceMode() से AAUDIO_PERFORMANCE_MODE_LOW_LATENCY दिखाने वाली स्ट्रीम के लिए, AAudioStream_getFramesPerBurst() से दिखाई गई वैल्यू, प्रॉपर्टी की AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER के लिए android.media.AudioManager.getProperty(String) से दिखाई गई वैल्यू से कम या उसके बराबर हो.

अगर डिवाइस पर OpenSL ES PCM बफ़र कतार और AAudio नेटिव ऑडियो एपीआई, दोनों के ज़रिए कम समय में ऑडियो प्रोसेस करने की सुविधा से जुड़ी ज़रूरी शर्तें पूरी नहीं होती हैं, तो:

• [C-2-1] ज़रूरी है कि कम समय में ऑडियो ट्रांसफ़र करने की सुविधा के बारे में जानकारी न दी जाए.

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

• [C-3-1] AudioRecord.getTimestamp या AAudioStream_getTimestamp से मिले इनपुट टाइमस्टैंप में गड़बड़ी को +/- 2 मि॰से॰ तक सीमित करें. यहां "गड़बड़ी" का मतलब, सही वैल्यू से डेविएट होना है.
• [C-3-2] कोल्ड इनपुट लेटेन्सी 500 मिलीसेकंड या इससे कम होनी चाहिए.

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

• [C-SR] कोल्ड इनपुट लेटेन्सी 100 मिलीसेकंड या इससे कम हो. Android के इस वर्शन पर काम करने वाले मौजूदा और नए डिवाइसों को, अब इन ज़रूरी शर्तों को पूरा करने का सुझाव दिया जाता है. साल 2021 में, प्लैटफ़ॉर्म के आने वाले वर्शन में, कोल्ड इनपुट लेटेन्सी 200 मि॰से॰ या इससे कम होना ज़रूरी है.
• [C-SR] लगातार इनपुट लेटेन्सी 30 मिलीसेकंड या इससे कम होनी चाहिए.
• [C-SR] लगातार राउंड-ट्रिप में लगने वाला समय 50 मिलीसेकंड या इससे कम हो.
• [C-SR] कोल्ड इनपुट जिटर को कम करें.
• [C-SR] AudioRecord.getTimestamp या AAudioStream_getTimestamp से मिले इनपुट टाइमस्टैंप में गड़बड़ी को +/- 1 मि॰से॰ तक सीमित करें.

5.7. नेटवर्क प्रोटोकॉल

डिवाइस में सेट किए हुए सिस्टम में, ऑडियो और वीडियो चलाने के लिए मीडिया नेटवर्क प्रोटोकॉल काम करने चाहिए. इनके बारे में Android SDK के दस्तावेज़ में बताया गया है.

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

• [C-1-1] एचटीटीपी(एस) पर, सेक्शन 5.1 में बताए गए सभी ज़रूरी कोडेक और कंटेनर फ़ॉर्मैट काम करने चाहिए.

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

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

मीडिया सेगमेंट के फ़ॉर्मैट

RTSP (RTP, SDP)

5.8. सुरक्षित मीडिया

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

• [C-1-1] Display.FLAG_SECURE के साथ काम करने की सुविधा का एलान करना ज़रूरी है.

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

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

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

• [C-3-1] उपयोगकर्ता के लिए उपलब्ध वायर वाले पोर्ट से कनेक्ट किए गए सभी बाहरी डिसप्ले के लिए, HDCP 1.2 या इसके बाद के वर्शन का इस्तेमाल करना ज़रूरी है.

5.9. म्यूज़िकल इंस्ट्रुमेंट डिजिटल इंटरफ़ेस (एमआईडीआई)

अगर डिवाइस में लागू किए गए सिस्टम, android.content.pm.PackageManager क्लास के ज़रिए android.software.midi सुविधा के लिए सहायता की रिपोर्ट करते हैं, तो:

• [C-1-1] MIDI-capable हार्डवेयर ट्रांसपोर्ट के सभी ट्रांसपोर्ट पर MIDI काम करना चाहिए. इसके लिए, वे MIDI के अलावा कनेक्टिविटी की सुविधा देते हैं. ये ट्रांसपोर्ट इस तरह के होते हैं:

  • यूएसबी होस्ट मोड, section 7.7
  • यूएसबी पेरिफ़ेरल मोड, section 7.7
  • सेंट्रल डिवाइस के तौर पर काम करने वाला ब्लूटूथ स्मार्ट पर MIDI, सेक्शन 7.4.3

• [C-1-2] में, इंटर-ऐप्लिकेशन एमआईडीआई सॉफ़्टवेयर ट्रांसपोर्ट (वर्चुअल एमआईडीआई डिवाइस) की सुविधा होनी चाहिए

• [C-1-3] libamidi.so (नेटिव MIDI सपोर्ट) को शामिल करना ज़रूरी है

5.10. प्रोफ़ेशनल ऑडियो

अगर डिवाइसों पर, android.content.pm.PackageManager क्लास के ज़रिए android.hardware.audio.pro सुविधा के काम करने की जानकारी मिलती है, तो:

• [C-1-1] यह ज़रूरी है कि सुविधा android.hardware.audio.low_latency के साथ काम करने की जानकारी दी जाए.
• [C-1-2] सेक्शन 5.6 ऑडियो लेटेंसी में बताए गए तरीके के मुताबिक, ऑडियो के इंतज़ार का समय लगातार 20 मिलीसेकंड या इससे कम होना चाहिए. साथ ही, यह कम से कम एक ऐसे पाथ पर 10 मिलीसेकंड या इससे कम होना चाहिए जिस पर यह सुविधा काम करती है.
• [C-1-3] में यूएसबी होस्ट मोड और यूएसबी पेरीफ़ेरल मोड के साथ काम करने वाला यूएसबी पोर्ट शामिल होना चाहिए.
• [C-1-4] यह ज़रूरी है कि डिवाइस, android.software.midi सुविधा के साथ काम करता हो.
• [C-1-5] OpenSL ES पीसीएम बफ़र क्यू एपीआई और AAudio नेटिव ऑडियो एपीआई के कम से कम एक पाथ का इस्तेमाल करके, लेटेंसी और यूएसबी ऑडियो की ज़रूरी शर्तों को पूरा करना होगा.
• [SR] एमएमएपी पाथ के बजाय, AAudio नेटिव ऑडियो एपीआई का इस्तेमाल करके, लेटेंसी और यूएसबी ऑडियो से जुड़ी ज़रूरी शर्तों को पूरा करने का सुझाव दिया जाता है.
• [C-1-6] में कोल्ड आउटपुट की लेटेन्सी 200 मिलीसेकंड या इससे कम होनी चाहिए.
• [C-1-7] कोल्ड इनपुट लेटेंसी 200 मिलीसेकंड या इससे कम होनी चाहिए.
• [SR] ऑडियो चालू होने और सीपीयू लोड में बदलाव होने पर, सीपीयू की परफ़ॉर्मेंस का लेवल एक जैसा रखने का सुझाव दिया जाता है. इसकी जांच, Android ऐप्लिकेशन के SynthMark के कमिट आईडी 09b13c6f49ea089f8c31e5d035f912cc405b7ab8 का इस्तेमाल करके की जानी चाहिए. SynthMark, एक सॉफ़्टवेयर सिंथेसाइज़र का इस्तेमाल करता है. यह सिंथेसाइज़र, ऑडियो फ़्रेमवर्क पर काम करता है. इससे सिस्टम की परफ़ॉर्मेंस का पता चलता है. SynthMark ऐप्लिकेशन को “ऑटोमेटेड टेस्ट” विकल्प का इस्तेमाल करके चलाना होगा. साथ ही, ये नतीजे पाने होंगे:
  • voicemark.90 >= 32 आवाज़ें
  • latencymark.fixed.little <= 15 मि॰से॰
  • latencymark.dynamic.little <= 50 मि॰से॰

बेंचमार्क के बारे में जानने के लिए, SynthMark का दस्तावेज़ देखें.

• ऑडियो क्लॉक में, स्टैंडर्ड टाइम के हिसाब से कम से कम अंतर होना चाहिए.
• जब दोनों चालू हों, तो सीपीयू CLOCK_MONOTONIC के मुकाबले ऑडियो क्लॉक ड्रिफ्ट को कम करना चाहिए.
• उपयोगकर्ता के डिवाइस पर मौजूद ट्रांसड्यूसर के ज़रिए, ऑडियो के इंतज़ार के समय को कम से कम करना चाहिए.
• यूएसबी डिजिटल ऑडियो पर ऑडियो के इंतज़ार के समय को कम करना चाहिए.
• सभी पाथ पर ऑडियो के इंतज़ार के समय की जानकारी देनी चाहिए.
• ऑडियो बफ़र पूरा होने पर कॉलबैक एंट्री के समय में जिटर को कम करना चाहिए. इससे, कॉलबैक के ज़रिए इस्तेमाल किए जा सकने वाले सीपीयू बैंडविड्थ के प्रतिशत पर असर पड़ता है.
• सामान्य इस्तेमाल के दौरान, रिपोर्ट की गई लेटेन्सी पर ऑडियो में कोई गड़बड़ी नहीं होनी चाहिए.
• इन्हें चैनलों के बीच इंतज़ार के समय में कोई अंतर नहीं रखना चाहिए.
• सभी ट्रांसपोर्ट पर एमआईडीआई की औसत लेटेन्सी को कम करना चाहिए.
• सभी ट्रांसपोर्ट पर, लोड (जिटर) के दौरान एमआईडीआई के रिस्पॉन्स में लगने वाले समय में होने वाले बदलाव को कम से कम करना चाहिए.
• सभी ट्रांसपोर्ट पर, एमआईडीआई के सटीक टाइमस्टैंप देने चाहिए.
• डिवाइस पर मौजूद ट्रांसड्यूसर से आने वाले ऑडियो सिग्नल में मौजूद नॉइज़ को कम करना चाहिए. इसमें कोल्ड स्टार्ट के तुरंत बाद की अवधि भी शामिल है.
• जब दोनों एंड-पॉइंट चालू हों, तब इनपुट और आउटपुट के बीच ऑडियो क्लॉक का अंतर शून्य होना चाहिए. इससे जुड़े एंड-पॉइंट के उदाहरणों में, डिवाइस पर मौजूद माइक्रोफ़ोन और स्पीकर या ऑडियो जैक इनपुट और आउटपुट शामिल हैं.
• जब दोनों चालू हों, तो इसे एक ही थ्रेड पर, इनपुट और आउटपुट, दोनों के लिए ऑडियो बफ़र पूरा होने पर कॉल किए जाने वाले कॉलबैक को हैंडल करना चाहिए. साथ ही, इनपुट कॉलबैक से वापस आने के तुरंत बाद, आउटपुट कॉलबैक में जाना चाहिए. अगर एक ही थ्रेड पर कॉल बैक को मैनेज करना मुमकिन नहीं है, तो इनपुट कॉल बैक डालने के कुछ समय बाद आउटपुट कॉल बैक डालें. इससे ऐप्लिकेशन को इनपुट और आउटपुट, दोनों के लिए एक जैसा समय तय करने की अनुमति मिलती है.
• इनपुट और आउटपुट के लिए, HAL ऑडियो बफ़रिंग के बीच फ़ेज़ के अंतर को कम करना चाहिए.
• टच करने के बाद, स्क्रीन पर दिखने में लगने वाला समय कम होना चाहिए.
• डिवाइस पर लोड होने के दौरान, टच के इंतज़ार के समय में होने वाले बदलाव (jitter) को कम से कम करना चाहिए.
• टच इनपुट से ऑडियो आउटपुट तक की लेटेन्सी 40 मि॰से॰ या इससे कम होनी चाहिए.

अगर डिवाइसों में ऊपर दी गई सभी ज़रूरी शर्तें पूरी की जाती हैं, तो:

• [SR] android.content.pm.PackageManager क्लास के ज़रिए, android.hardware.audio.pro सुविधा के लिए सहायता उपलब्ध कराने की जानकारी देने का सुझाव दिया जाता है.

अगर डिवाइस में 4 कंडक्टर वाला 3.5 मि॰मी॰ ऑडियो जैक शामिल है, तो:

• [C-2-1] ऑडियो जैक के पाथ पर, ऑडियो के लगातार राउंड-ट्रिप में लगने वाला समय 20 मिलीसेकंड या इससे कम होना चाहिए.
• [SR] वायर्ड ऑडियो हेडसेट स्पेसिफ़िकेशन (v1.1) के सेक्शन मोबाइल डिवाइस (जैक) स्पेसिफ़िकेशन का पालन करने का सुझाव दिया जाता है.
• ऑडियो जैक के पाथ पर, ऑडियो के इंतज़ार का समय लगातार 10 मिलीसेकंड या इससे कम होना चाहिए.

अगर डिवाइस में चार कंडक्टर वाला 3.5 मि॰मी॰ का ऑडियो जैक नहीं है और उसमें यूएसबी होस्ट मोड के साथ काम करने वाला यूएसबी पोर्ट है, तो:

• [C-3-1] यूएसबी ऑडियो क्लास को लागू करना ज़रूरी है.
• [C-3-2] यूएसबी ऑडियो क्लास का इस्तेमाल करके, यूएसबी होस्ट मोड पोर्ट पर ऑडियो की राउंड-ट्रिप लेटेन्सी लगातार 20 मिलीसेकंड या इससे कम होनी चाहिए.
• यूएसबी ऑडियो क्लास का इस्तेमाल करके, यूएसबी होस्ट मोड पोर्ट पर ऑडियो की राउंड-ट्रिप लेटेन्सी लगातार 10 मिलीसेकंड या उससे कम होनी चाहिए.
• [C-SR] अगर यूएसबी ऑडियो पेरिफ़ेरल का इस्तेमाल किया जा रहा है, तो यह ज़रूरी है कि वह इन ज़रूरी शर्तों को पूरा करता हो. साथ ही, यह भी ज़रूरी है कि वह एक साथ दोनों दिशाओं में आठ चैनलों तक I/O, 96 किलोहर्ट्ज़ का सैंपल रेट, और 24-बिट या 32-बिट डेप्थ को सपोर्ट करता हो.

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

• कम से कम एक कॉन्फ़िगरेशन में, 20-बिट या 24-बिट डेप्थ और 192 किलोहर्ट्ज़ पर, स्टीरियो और आठ चैनलों में आउटपुट देने की सुविधा होनी चाहिए. साथ ही, बिट-डेप्थ में कोई कमी नहीं होनी चाहिए या रीसैंपलिंग नहीं होनी चाहिए.

5.11. प्रोसेस नहीं किए गए वीडियो के लिए कैप्चर करना

Android में, android.media.MediaRecorder.AudioSource.UNPROCESSED ऑडियो सोर्स के ज़रिए बिना प्रोसेस किए गए ऑडियो को रिकॉर्ड करने की सुविधा शामिल है. OpenSL ES में, इसे रिकॉर्ड प्रीसेट SL_ANDROID_RECORDING_PRESET_UNPROCESSED की मदद से ऐक्सेस किया जा सकता है.

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

• [C-1-1] android.media.AudioManager प्रॉपर्टी PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED के ज़रिए, सहायता के बारे में जानकारी देना ज़रूरी है.

• [C-1-2] मिड-फ़्रीक्वेंसी रेंज में, ऐम्प्लिट्यूड-वर्सेस-फ़्रीक्वेंसी की विशेषताएं लगभग एक जैसी होनी चाहिए: खास तौर पर, बिना प्रोसेस किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन के लिए, 100 हर्ट्ज़ से 7,000 हर्ट्ज़ तक ±10dB.

• [C-1-3] लो फ़्रीक्वेंसी रेंज में ऐम्प्लिट्यूड लेवल दिखाना ज़रूरी है: खास तौर पर, 5 हर्ट्ज़ से 100 हर्ट्ज़ तक ±20 dB, जो कि बिना प्रोसेस किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन के लिए, मिड-फ़्रीक्वेंसी रेंज की तुलना में है.

• [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 kHZ के लिए, टोटल हार्मोनिक डिस्टॉर्शन (टीएचडी) 1% से कम होना चाहिए.

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

• [C-1-8] अगर किसी वजह से आर्किटेक्चर में सिग्नल प्रोसेसिंग मौजूद है, तो उसे बंद करना होगा. साथ ही, सिग्नल पाथ में किसी तरह की देरी या अतिरिक्त इंतज़ार का समय नहीं होना चाहिए.
• [C-1-9] लेवल मल्टीप्लायर को पाथ पर इस्तेमाल करने की अनुमति है. हालांकि, इससे सिग्नल पाथ में देरी या लेटेन्सी नहीं होनी चाहिए.

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

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

• [C-2-1] AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) एपीआई तरीके के लिए, null को वापस भेजना ज़रूरी है, ताकि यह सही तरीके से पता चल सके कि यह सुविधा काम नहीं करती.
• [SR] अब भी यह सुझाव दिया जाता है कि बिना प्रोसेस किए गए रिकॉर्डिंग सोर्स के सिग्नल पाथ के लिए, ज़्यादा से ज़्यादा ज़रूरी शर्तों को पूरा किया जाए.

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

6.1. डेवलपर टूल

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

• [C-0-1] Android SDK में दिए गए Android डेवलपर टूल के साथ काम करना ज़रूरी है.

• Android Debug Bridge (adb)

  • [C-0-2] Android SDK में दिए गए दस्तावेज़ और AOSP में दी गई शेल कमांड के मुताबिक, adb का इस्तेमाल किया जा सकता है. ऐप्लिकेशन डेवलपर इनका इस्तेमाल कर सकते हैं. इनमें dumpsys cmd stats भी शामिल है
  • [C-SR] यह सुझाव दिया जाता है कि डिवाइस, शेल कमांड cmd testharness के साथ काम करे.
  • [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
    • JobStateChanged
    • PluggedStateChanged
    • ScheduledJobStateChanged
    • ScreenStateChanged
    • SyncStateChanged
    • SystemElapsedRealtime
    • 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 को कनेक्ट किया जा सके. उदाहरण के लिए:

    • जिन डिवाइसों में यूएसबी पोर्ट नहीं है और जो पेरिफ़ेरल मोड के साथ काम नहीं करते हैं उनमें स्थानीय नेटवर्क (जैसे, इथरनेट या वाई-फ़ाई) के ज़रिए adb को लागू करना ज़रूरी है.
    • Windows 7, 9, और 10 के लिए ड्राइवर उपलब्ध कराने होंगे. इससे डेवलपर, adb प्रोटोकॉल का इस्तेमाल करके डिवाइस से कनेक्ट कर पाएंगे.

• Dalvik Debug Monitor Service (ddms)

  • [C-0-7] यह ज़रूरी है कि डिवाइस, Android SDK में बताई गई सभी ddms सुविधाओं के साथ काम करता हो. डीडीएमएस, एडीबी का इस्तेमाल करता है. इसलिए, डीडीएमएस की सुविधा डिफ़ॉल्ट रूप से बंद होनी चाहिए. हालांकि, जब उपयोगकर्ता ऊपर बताए गए तरीके से Android डीबग ब्रिज को चालू करता है, तब डीडीएमएस की सुविधा चालू होनी चाहिए.
• Monkey
  • [C-0-8] इसमें Monkey फ़्रेमवर्क शामिल होना चाहिए. साथ ही, इसे ऐप्लिकेशन के इस्तेमाल के लिए उपलब्ध कराना चाहिए.
• SysTrace
  • [C-0-9] यह ज़रूरी है कि डिवाइस, Android SDK में दिए गए दस्तावेज़ के मुताबिक, systrace टूल के साथ काम करे. Systrace डिफ़ॉल्ट रूप से बंद होना चाहिए. साथ ही, इसे चालू करने के लिए उपयोगकर्ता के पास एक ऐसा तरीका होना चाहिए जिसे वह आसानी से ऐक्सेस कर सके.

• Perfetto

  • [C-SR] Are STRONGLY RECOMMENDED to expose a /system/bin/perfetto binary to the shell user which cmdline complies with the perfetto documentation.
  • [C-SR] यह सुझाव दिया जाता है कि perfetto बाइनरी, इनपुट के तौर पर ऐसे protobuf कॉन्फ़िगरेशन को स्वीकार करे जो परफ़ेक्टो के दस्तावेज़ में तय किए गए स्कीमा के मुताबिक हो.
  • [C-SR] यह सुझाव दिया जाता है कि perfetto बाइनरी, आउटपुट के तौर पर एक प्रोटोबफ़ ट्रेस लिखे. यह ट्रेस, परफ़ेक्टो के दस्तावेज़ में तय किए गए स्कीमा के मुताबिक होना चाहिए.
  • [C-SR] यह सुझाव दिया जाता है कि कम से कम Perfetto के दस्तावेज़ में बताए गए डेटा सोर्स, Perfetto बाइनरी के ज़रिए उपलब्ध कराए जाएं.

• टेस्ट हार्नेस मोड

  अगर डिवाइस में सेट किए गए सिस्टम, शेल कमांड cmd testharness के साथ काम करते हैं और cmd testharness enable चलाते हैं, तो:

  • [C-2-1] ActivityManager.isRunningInUserTestHarness() के लिए true एट्रिब्यूट की वैल्यू देना ज़रूरी है
  • [C-2-2] हार्नेस मोड के दस्तावेज़ में बताए गए तरीके से, टेस्ट हार्नेस मोड को लागू करना ज़रूरी है.

अगर डिवाइस में सेट किए गए सिस्टम, android.hardware.vulkan.version फ़ीचर फ़्लैग के ज़रिए Vulkan 1.0 या इसके बाद के वर्शन के साथ काम करने की जानकारी देते हैं, तो:

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

6.2. डेवलपर के लिए सेटिंग और टूल

Android में, डेवलपर के लिए ऐप्लिकेशन डेवलपमेंट से जुड़ी सेटिंग कॉन्फ़िगर करने की सुविधा शामिल है.

डिवाइस में सेट किए हुए सिस्टम में, डेवलपर विकल्पों के लिए एक जैसा अनुभव होना चाहिए. जैसे:

• [C-0-1] ऐप्लिकेशन डेवलपमेंट से जुड़ी सेटिंग दिखाने के लिए, android.settings.APPLICATION_DEVELOPMENT_SETTINGS इंटेंट का इस्तेमाल करना ज़रूरी है. Android के अपस्ट्रीम वर्शन में, डेवलपर के लिए सेटिंग और टूल वाला मेन्यू डिफ़ॉल्ट रूप से छिपा होता है. हालांकि, उपयोगकर्ता सेटिंग > डिवाइस के बारे में जानकारी > बिल्ड नंबर मेन्यू आइटम पर सात (7) बार दबाकर, डेवलपर के लिए सेटिंग और टूल को लॉन्च कर सकते हैं.
• [C-0-2] डिफ़ॉल्ट रूप से, डेवलपर के लिए सेटिंग और टूल छिपाने होंगे.
• [C-0-3] डेवलपर के विकल्पों को चालू करने के लिए, एक ऐसा तरीका उपलब्ध कराना ज़रूरी है जिसमें किसी एक तीसरे पक्ष के ऐप्लिकेशन को दूसरे की तुलना में ज़्यादा प्राथमिकता न दी गई हो. सार्वजनिक तौर पर दिखने वाला ऐसा दस्तावेज़ या वेबसाइट उपलब्ध कराना ज़रूरी है जिसमें डेवलपर के लिए सेटिंग और टूल को चालू करने का तरीका बताया गया हो. इस दस्तावेज़ या वेबसाइट को Android SDK के दस्तावेज़ों से लिंक किया जाना चाहिए.
• जब डेवलपर के लिए सेटिंग और टूल चालू हों और उपयोगकर्ता की सुरक्षा को लेकर चिंता हो, तो उपयोगकर्ता को लगातार विज़ुअल सूचना मिलनी चाहिए.
• उपयोगकर्ता की सुरक्षा से जुड़े मामलों में, ध्यान भटकने से रोकने के लिए, डेवलपर के विकल्पों वाले मेन्यू के ऐक्सेस को कुछ समय के लिए सीमित कर सकता है. इसके लिए, मेन्यू को छिपाया जा सकता है या बंद किया जा सकता है.

7. हार्डवेयर के साथ काम करने की सुविधा

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

• [C-0-1] डिवाइस में सेट किए गए सिस्टम के लिए, Android SDK के दस्तावेज़ में बताए गए तरीके से एपीआई लागू करना ज़रूरी है.

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

• [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 के साथ काम करने वाले तीसरे पक्ष के सभी ऐप्लिकेशन चल सकते हैं, डिवाइसों को इन एपीआई और व्यवहारों को सही तरीके से लागू करना होगा. इनके बारे में इस सेक्शन में बताया गया है.

इस सेक्शन में बताई गई ज़रूरी शर्तों में इस्तेमाल की गई इकाइयों की परिभाषा यहां दी गई है:

• फ़िज़िकल डाइगोनल साइज़. डिसप्ले के उस हिस्से के दो विपरीत कोनों के बीच की दूरी जो रोशनी में है. यह दूरी इंच में होती है.
• डॉट्स पर इंच (डीपीआई). यह 1 इंच के लीनियर हॉरिज़ॉन्टल या वर्टिकल स्पैन में शामिल पिक्सल की संख्या होती है. जहां डीपीआई की वैल्यू दी गई हैं वहां हॉरिज़ॉन्टल और वर्टिकल, दोनों डीपीआई की वैल्यू इस रेंज में होनी चाहिए.
• आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात). स्क्रीन के लंबे डाइमेंशन के पिक्सल का अनुपात, छोटे डाइमेंशन के पिक्सल से. उदाहरण के लिए, 480x854 पिक्सल के डिसप्ले का आसपेक्ट रेशियो 854/480 = 1.779 होगा. इसे “16:9” भी कहा जा सकता है.
• डेंसिटी-इंडिपेंडेंट पिक्सल (डीपी). वर्चुअल पिक्सल यूनिट को 160 डीपीआई वाली स्क्रीन के हिसाब से नॉर्मलाइज़ किया जाता है. इसे इस तरह से कैलकुलेट किया जाता है: पिक्सल = डीपी * (डेंसिटी/160).

7.1.1. स्क्रीन कॉन्फ़िगरेशन

7.1.1.1. स्क्रीन का साइज़ और शेप

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

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

• [C-0-1] Android SDK के दस्तावेज़ में बताए गए तरीके के मुताबिक, Configuration.screenLayout के लिए सही लेआउट साइज़ की जानकारी देना ज़रूरी है. खास तौर पर, डिवाइसों को लॉजिकल डेंसिटी-इंडिपेंडेंट पिक्सल (डीपी) के स्क्रीन डाइमेंशन की सही जानकारी देनी होगी. जैसे:

  • ऐसे डिवाइसों के लिए, Configuration.uiMode को UI_MODE_TYPE_WATCH के अलावा किसी अन्य वैल्यू के तौर पर सेट किया गया है और Configuration.screenLayout के लिए small साइज़ की जानकारी दी गई है. ऐसे डिवाइसों का डाइमेंशन कम से कम 426 डीपी x 320 डीपी होना चाहिए.
  • Configuration.screenLayout के लिए normal साइज़ की जानकारी देने वाले डिवाइसों में, कम से कम 480 डीपी x 320 डीपी होना चाहिए.
  • Configuration.screenLayout के लिए large साइज़ की जानकारी देने वाले डिवाइसों में, कम से कम 640 dp x 480 dp होना चाहिए.
  • Configuration.screenLayout के लिए xlarge साइज़ की जानकारी देने वाले डिवाइसों में, कम से कम 960 डीपी x 720 डीपी होना चाहिए.

• [C-0-2] Android SDK के दस्तावेज़ में बताए गए तरीके के मुताबिक, AndroidManifest.xml फ़ाइल में <supports-screens> एट्रिब्यूट के ज़रिए, ऐप्लिकेशन के लिए स्क्रीन साइज़ के बारे में बताई गई जानकारी का सही तरीके से पालन करना ज़रूरी है.

• इसमें Android के साथ काम करने वाले डिसप्ले हो सकते हैं, जिनके कोने गोल होते हैं.

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

• [C-1-1] यह पक्का करना ज़रूरी है कि गोल किए गए कोनों का रेडियस, 38 डीपी से कम या उसके बराबर हो.
• उपयोगकर्ता के पास, आयताकार कोनों वाले डिसप्ले मोड पर स्विच करने का विकल्प होना चाहिए.

7.1.1.2. स्क्रीन का आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात)

Android के साथ काम करने वाले डिसप्ले के लिए, फ़िज़िकल डिसप्ले के आसपेक्ट रेशियो(लंबाई-चौड़ाई का अनुपात) पर कोई पाबंदी नहीं है. हालांकि, लॉजिकल डिसप्ले के आसपेक्ट रेशियो के लिए ये ज़रूरी शर्तें पूरी करना ज़रूरी है. लॉजिकल डिसप्ले पर तीसरे पक्ष के ऐप्लिकेशन रेंडर किए जाते हैं. इसका पता, view.Display एपीआई और Configuration एपीआई के ज़रिए रिपोर्ट की गई ऊंचाई और चौड़ाई की वैल्यू से लगाया जा सकता है:

• [C-0-1] जिन डिवाइसों में Configuration.uiMode को UI_MODE_TYPE_NORMAL पर सेट किया गया है उनमें आसपेक्ट रेशियो की वैल्यू 1.86 (लगभग 16:9) से कम या इसके बराबर होनी चाहिए. हालांकि, अगर ऐप्लिकेशन इनमें से कोई एक शर्त पूरी करता है, तो ऐसा करना ज़रूरी नहीं है:

  • ऐप्लिकेशन ने android.max_aspect मेटाडेटा वैल्यू के ज़रिए यह एलान किया है कि यह बड़े आसपेक्ट रेशियो वाली स्क्रीन पर काम करता है.
  • ऐप्लिकेशन, android:resizeableActivity एट्रिब्यूट के ज़रिए यह जानकारी देता है कि उसका साइज़ बदला जा सकता है.
  • ऐप्लिकेशन, एपीआई लेवल 24 या उसके बाद के लेवल को टारगेट करता हो. साथ ही, android:maxAspectRatio का एलान न करता हो, जिससे अनुमति वाले आसपेक्ट रेशियो पर पाबंदी लगती हो.

• [C-0-2] Configuration.uiMode को UI_MODE_TYPE_NORMAL पर सेट करने वाले डिवाइसों में, आसपेक्ट रेशियो की वैल्यू 1.3333 (4:3) के बराबर या उससे ज़्यादा होनी चाहिए. हालांकि, अगर ऐप्लिकेशन इन शर्तों में से किसी एक को पूरा करता है, तो उसे ज़्यादा चौड़ाई में स्ट्रेच किया जा सकता है:

  • ऐप्लिकेशन, android:resizeableActivity एट्रिब्यूट के ज़रिए यह जानकारी देता है कि उसका साइज़ बदला जा सकता है.
  • ऐप्लिकेशन, android:minAspectRatio का एलान करता है. इससे, आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) पर पाबंदी लग जाएगी.

• [C-0-3] Configuration.uiMode को UI_MODE_TYPE_WATCH के तौर पर सेट करने वाले डिवाइसों में, आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) की वैल्यू 1.0 (1:1) के तौर पर सेट होनी चाहिए.

7.1.1.3. स्क्रीन की सघनता

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

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

• डिवाइसों को, Android फ़्रेमवर्क की स्टैंडर्ड डेंसिटी तय करनी चाहिए. यह डेंसिटी, स्क्रीन की फ़िज़िकल डेंसिटी के सबसे करीब होनी चाहिए. हालांकि, ऐसा तब तक किया जाना चाहिए, जब तक लॉजिकल डेंसिटी की वजह से स्क्रीन का साइज़, कम से कम साइज़ से कम न हो जाए. अगर फ़िज़िकल डेंसिटी के सबसे करीब वाली स्टैंडर्ड Android फ़्रेमवर्क डेंसिटी की वजह से, स्क्रीन का साइज़, साथ काम करने वाली सबसे छोटी स्क्रीन के साइज़ (320 डीपी चौड़ाई) से छोटा हो जाता है, तो डिवाइसों को स्टैंडर्ड Android फ़्रेमवर्क डेंसिटी की अगली सबसे कम वैल्यू रिपोर्ट करनी चाहिए.

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

• [C-1-1] डिसप्ले साइज़ को, नेटिव डेंसिटी के 1.5 गुना से ज़्यादा नहीं बढ़ाया जाना चाहिए. साथ ही, स्क्रीन के डाइमेंशन को 320dp (संसाधन क्वालिफ़ायर sw320dp के बराबर) से कम नहीं किया जाना चाहिए. इनमें से जो भी पहले हो उसे लागू किया जाना चाहिए.
• [C-1-2] डिसप्ले साइज़ को नेटिव डेनसिटी के 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] इम्यूलेट किए गए डिफ़ॉल्ट view.Display के लिए, android.util.DisplayMetrics एपीआई में तय किए गए Android के साथ काम करने वाले डिसप्ले की सही वैल्यू रिपोर्ट करना ज़रूरी है.

7.1.3. स्क्रीन अभिविन्यास

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

• [C-0-1] यह बताना ज़रूरी है कि ऐप्लिकेशन, स्क्रीन के किन ओरिएंटेशन (android.hardware.screen.portrait और/या android.hardware.screen.landscape) के साथ काम करता है. साथ ही, कम से कम एक ओरिएंटेशन के बारे में बताना ज़रूरी है. उदाहरण के लिए, लैंडस्केप मोड में फ़िक्स की गई स्क्रीन वाले डिवाइस, जैसे कि टेलीविज़न या लैपटॉप को सिर्फ़ android.hardware.screen.landscape की वैल्यू रिपोर्ट करनी चाहिए.
• [C-0-2] android.content.res.Configuration.orientation, android.view.Display.getOrientation() या अन्य एपीआई के ज़रिए क्वेरी किए जाने पर, डिवाइस की मौजूदा ओरिएंटेशन की सही वैल्यू रिपोर्ट करनी चाहिए.

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

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

7.1.4. 2D और 3D ग्राफ़िक ऐक्सेलरेशन

7.1.4.1 OpenGL ES

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

• [C-0-1] यह ज़रूरी है कि डिवाइस, मैनेज किए गए एपीआई (जैसे कि GLES10.getString() तरीके से) और नेटिव एपीआई के ज़रिए, OpenGL ES के सपोर्ट किए गए वर्शन (1.1, 2.0, 3.0, 3.1, 3.2) की सही पहचान करे.
• [C-0-2] यह ज़रूरी है कि डिवाइस में, OpenGL ES के हर उस वर्शन के लिए मैनेज किए गए सभी एपीआई और नेटिव एपीआई काम करते हों जिनके साथ डिवाइस काम कर सकता है.

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

• [C-1-1] Android SDK के दस्तावेज़ में बताए गए तरीके के मुताबिक, OpenGL ES 1.1 और 2.0, दोनों के साथ काम करना ज़रूरी है.
• [C-SR] OpenGL ES 3.1 को सपोर्ट करने का सुझाव दिया जाता है.
• OpenGL ES 3.2 सपोर्ट करना चाहिए.

अगर डिवाइस में सेट किए गए सिस्टम में 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-SR] EGL_KHR_partial_update और OES_EGL_image_external एक्सटेंशन सपोर्ट करने का सुझाव दिया जाता है.
• उन्हें getString() तरीके का इस्तेमाल करके, टेक्सचर कंप्रेस करने के हर उस फ़ॉर्मैट की सटीक जानकारी देनी चाहिए जो उनके डिवाइस पर काम करता है. आम तौर पर, यह जानकारी वेंडर के हिसाब से अलग-अलग होती है.

अगर डिवाइस में OpenGL ES 3.0, 3.1 या 3.2 के साथ काम करने की सुविधा उपलब्ध है, तो:

• [C-3-1] libGLESv2.so लाइब्रेरी में OpenGL ES 2.0 के फ़ंक्शन सिंबल के साथ-साथ, इन वर्शन के लिए भी फ़ंक्शन सिंबल एक्सपोर्ट करने होंगे.
• [SR] यह सुझाव दिया जाता है कि 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 का इस्तेमाल किया जा सकता है, तो:

• [SR] Vulkan 1.1 के साथ काम करने की सुविधा शामिल करने का सुझाव दिया जाता है.

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

• Vulkan 1.1 के साथ काम करना चाहिए.

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

• [C-1-1] android.hardware.vulkan.level और android.hardware.vulkan.version फ़ीचर फ़्लैग के साथ सही पूर्णांक वैल्यू रिपोर्ट करना ज़रूरी है.
• [C-1-2] Vulkan नेटिव एपीआई vkEnumeratePhysicalDevices() के लिए, कम से कम एक VkPhysicalDevice की गिनती करना ज़रूरी है .
• [C-1-3] हर VkPhysicalDevice के लिए, Vulkan 1.0 एपीआई को पूरी तरह से लागू करना ज़रूरी है.
• [C-1-4] ऐप्लिकेशन पैकेज की नेटिव लाइब्रेरी डायरेक्ट्री में मौजूद, libVkLayer*.so नाम की नेटिव लाइब्रेरी में शामिल लेयर को Vulkan नेटिव एपीआई vkEnumerateInstanceLayerProperties() और vkEnumerateDeviceLayerProperties() के ज़रिए दिखाना ज़रूरी है .
• [C-1-5] ऐप्लिकेशन पैकेज के बाहर की लाइब्रेरी से मिली लेयर को नहीं गिना जाना चाहिए. इसके अलावा, Vulkan API को ट्रेस या इंटरसेप्ट करने के अन्य तरीके भी नहीं दिए जाने चाहिए. हालांकि, ऐसा तब किया जा सकता है, जब ऐप्लिकेशन में android:debuggable एट्रिब्यूट को true के तौर पर सेट किया गया हो.
• [C-1-6] Vulkan नेटिव एपीआई के ज़रिए, उन सभी एक्सटेंशन स्ट्रिंग की जानकारी देनी होगी जिनके साथ वे काम करते हैं. इसके उलट, उन एक्सटेंशन स्ट्रिंग की जानकारी नहीं देनी होगी जिनके साथ वे ठीक से काम नहीं करते.
• [C-1-7] VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, और VK_KHR_incremental_present एक्सटेंशन के साथ काम करना ज़रूरी है.
• [C-SR] यह सुझाव दिया जाता है कि VK_KHR_driver_properties और VK_GOOGLE_display_timing एक्सटेंशन काम करें.

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

• [C-2-1] यह ज़रूरी है कि Vulkan के किसी भी फ़ीचर फ़्लैग (जैसे, android.hardware.vulkan.level, android.hardware.vulkan.version) का एलान न किया गया हो.
• [C-2-2] Vulkan नेटिव एपीआई vkEnumeratePhysicalDevices() के लिए, किसी भी VkPhysicalDevice को नहीं गिनना चाहिए.

अगर डिवाइस में Vulkan 1.1 के साथ काम करने की सुविधा शामिल है और Vulkan के किसी भी फ़ीचर फ़्लैग का एलान किया गया है, तो:

• [C-3-1] SYNC_FD एक्सटर्नल सेमाफ़ोर और हैंडल टाइप के साथ-साथ VK_ANDROID_external_memory_android_hardware_buffer एक्सटेंशन के लिए काम की जानकारी देना ज़रूरी है.

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] GL_EXT_sRGB का इस्तेमाल करने का सुझाव दिया जाता है.

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

• [C-2-1] CIE 1931 xyY स्पेस में, sRGB के 100% या इससे ज़्यादा हिस्से को कवर करना चाहिए. हालांकि, स्क्रीन कलर गैमट तय नहीं किया गया है.

7.1.5. लेगसी ऐप्लिकेशन कंपैटबिलिटी मोड

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

7.1.6. स्क्रीन टेक्नोलॉजी

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

डिवाइस में लागू किए गए Android के साथ काम करने वाले सभी डिसप्ले:

• [C-0-1] ज़रूरी है कि 16-बिट कलर ग्राफ़िक रेंडर कर सके.
• इसमें 24-बिट कलर ग्राफ़िक वाले डिसप्ले काम करने चाहिए.
• [C-0-2] ऐनिमेशन रेंडर करने की सुविधा होनी चाहिए.
• [C-0-3] पिक्सल आसपेक्ट रेशियो (पीएआर) 0.9 और 1.15 के बीच होना चाहिए. इसका मतलब है कि पिक्सल का आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) स्क्वेयर (1.0) के आस-पास होना चाहिए. इसमें 10 से 15% का अंतर हो सकता है.

7.1.7. दूसरे डिसप्ले

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

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

• [C-1-1] Android SDK के दस्तावेज़ में बताए गए तरीके के मुताबिक, DisplayManager सिस्टम सेवा और एपीआई को लागू करना ज़रूरी है.

7.2. इनपुट डिवाइस

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

• [C-0-1] यूज़र इंटरफ़ेस (यूआई) एलिमेंट के बीच नेविगेट करने के लिए, इनपुट मैकेनिज़्म शामिल करना ज़रूरी है. जैसे, टचस्क्रीन या बिना टच किए नेविगेट करने की सुविधा.

7.2.1. कीबोर्ड

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

• [C-1-1] android.software.input_methods फ़ीचर फ़्लैग के बारे में एलान करना ज़रूरी है.
• [C-1-2] Input Management Framework को पूरी तरह से लागू करना ज़रूरी है
• [C-1-3] में सॉफ़्टवेयर कीबोर्ड पहले से इंस्टॉल होना चाहिए.

डिवाइस पर लागू होने वाली शर्तें: * [C-0-1] डिवाइस में ऐसा हार्डवेयर कीबोर्ड शामिल नहीं होना चाहिए जो android.content.res.Configuration.keyboard में बताए गए फ़ॉर्मैट (QWERTY या 12-की) में से किसी एक से मेल न खाता हो. * इसमें सॉफ़्ट कीबोर्ड को लागू करने की अन्य सुविधाएं शामिल होनी चाहिए. * इसमें हार्डवेयर कीबोर्ड शामिल हो सकता है.

7.2.2. बिना छुए नेविगेट करने की सुविधा

Android में, बिना टच किए नेविगेट करने के लिए डी-पैड, ट्रैकबॉल, और व्हील का इस्तेमाल किया जा सकता है.

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

• [C-0-1] android.content.res.Configuration.navigation के लिए सही वैल्यू रिपोर्ट करना ज़रूरी है.

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

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

7.2.3. मार्गदर्शक कुंजियां

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

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

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

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

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

• [SR] हमारा सुझाव है कि मेन्यू फ़ंक्शन के लिए इनपुट मैकेनिज़्म उपलब्ध न कराएं, क्योंकि Android 4.0 के बाद से इसे ऐक्शन बार के पक्ष में बंद कर दिया गया है.

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

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

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

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

• [C-4-1] जब नेविगेशन की अन्य कुंजियां ऐक्सेस की जा सकती हैं, तब एक ही ऐक्शन (जैसे, टैप करना, दो बार क्लिक करना या जेस्चर) से, 'ठीक है Google' सुविधा को ऐक्सेस किया जा सकता हो.
• [SR] इस इंटरैक्शन के लिए, होम फ़ंक्शन पर देर तक दबाकर रखने की सुविधा का इस्तेमाल करने का सुझाव दिया जाता है.

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

• [C-5-1] नेविगेशन कुंजियों को स्क्रीन के ऐसे हिस्से का इस्तेमाल करना चाहिए जो ऐप्लिकेशन के लिए उपलब्ध न हो. साथ ही, उन्हें स्क्रीन के उस हिस्से को धुंधला नहीं करना चाहिए या उसमें किसी तरह की रुकावट नहीं डालनी चाहिए जो ऐप्लिकेशन के लिए उपलब्ध है.
• [C-5-2] ऐप्लिकेशन के लिए, डिसप्ले का वह हिस्सा उपलब्ध कराना ज़रूरी है जो सेक्शन 7.1.1 में बताई गई ज़रूरी शर्तों को पूरा करता हो.
• [C-5-3] View.setSystemUiVisibility() एपीआई के तरीके से, ऐप्लिकेशन की ओर से सेट किए गए फ़्लैग का पालन करना ज़रूरी है, ताकि स्क्रीन के इस अलग हिस्से (नेविगेशन बार) को एसडीके में बताए गए तरीके से छिपाया जा सके.

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

• [C-6-1] WindowInsets#getMandatorySystemGestureInsets() का इस्तेमाल, सिर्फ़ होम जेस्चर की पहचान करने वाले एरिया की जानकारी देने के लिए किया जाना चाहिए.
• [C-6-2] अगर फ़ोरग्राउंड ऐप्लिकेशन, View#setSystemGestureExclusionRects() के ज़रिए कोई एक्सक्लूज़न रेक्ट उपलब्ध कराता है, तो नेविगेशन फ़ंक्शन के लिए ऐसे जेस्चर को इंटरसेप्ट नहीं किया जाना चाहिए जो एक्सक्लूज़न रेक्ट के अंदर से शुरू होते हैं, लेकिन WindowInsets#getMandatorySystemGestureInsets() के बाहर होते हैं. ऐसा तब तक नहीं किया जाना चाहिए, जब तक एक्सक्लूज़न रेक्ट को View#setSystemGestureExclusionRects() के दस्तावेज़ में बताई गई एक्सक्लूज़न की ज़्यादा से ज़्यादा सीमा के अंदर अनुमति मिली हो.
• [C-6-3] अगर फ़ोरग्राउंड ऐप्लिकेशन को पहले MotionEvent.ACTION_DOWN इवेंट भेजा गया था, तो सिस्टम के जेस्चर के लिए टच इंटरसेप्ट किए जाने पर, फ़ोरग्राउंड ऐप्लिकेशन को MotionEvent.ACTION_CANCEL इवेंट भेजना ज़रूरी है.
• [C-6-4] उपयोगकर्ताओं को स्क्रीन पर मौजूद बटन के ज़रिए नेविगेशन की सुविधा उपलब्ध कराना ज़रूरी है. उदाहरण के लिए, सेटिंग में.
• स्क्रीन के मौजूदा ओरिएंटेशन में, सबसे नीचे के किनारे से ऊपर की ओर स्वाइप करने पर, होम फ़ंक्शन चालू होना चाहिए.
• उन्हें होम जेस्चर वाली जगह से, ऊपर की ओर स्वाइप करके रिलीज़ करने से पहले, रीसेंट ऐप्लिकेशन फ़ंक्शन को उपलब्ध कराना चाहिए.
• WindowInsets#getMandatorySystemGestureInsets() के अंदर शुरू होने वाले जेस्चर पर, फ़ोरग्राउंड ऐप्लिकेशन के View#setSystemGestureExclusionRects() के ज़रिए दिए गए एक्सक्लूज़न रेक्ट का असर नहीं पड़ना चाहिए.

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

• [C-7-1] नेविगेशन फ़ंक्शन, 'वापस जाएं' वाला होना चाहिए. साथ ही, इसे स्क्रीन के मौजूदा ओरिएंटेशन के हिसाब से, बाएं और दाएं दोनों किनारों से स्वाइप करके ऐक्सेस किया जा सकता हो.
• [C-7-2] अगर बाईं या दाईं ओर स्वाइप किए जा सकने वाले कस्टम सिस्टम पैनल दिए गए हैं, तो उन्हें स्क्रीन के ऊपरी एक-तिहाई हिस्से में रखना होगा. साथ ही, यह साफ़ तौर पर दिखना चाहिए कि अंदर की ओर खींचने से, ऊपर बताए गए पैनल खुलेंगे. इसलिए, ऐसा करने से 'वापस जाएं' सुविधा काम नहीं करेगी. उपयोगकर्ता, सिस्टम पैनल को इस तरह से कॉन्फ़िगर कर सकता है कि वह स्क्रीन के किनारे के ऊपरी एक-तिहाई हिस्से के नीचे दिखे. हालांकि, सिस्टम पैनल को किनारे के एक-तिहाई हिस्से से ज़्यादा जगह का इस्तेमाल नहीं करना चाहिए.
• [C-7-3] जब फ़ोरग्राउंड ऐप्लिकेशन में View.SYSTEM_UI_FLAG_IMMERSIVE या View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY फ़्लैग सेट हों, तो किनारों से स्वाइप करने पर वही व्यवहार होना चाहिए जो AOSP में लागू किया गया है. इसके बारे में एसडीके में बताया गया है.
• [C-7-4] जब फ़ोरग्राउंड ऐप्लिकेशन में View.SYSTEM_UI_FLAG_IMMERSIVE या View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY फ़्लैग सेट हों, तो कस्टम स्वाइप किए जा सकने वाले सिस्टम पैनल तब तक छिपे रहने चाहिए, जब तक उपयोगकर्ता सिस्टम बार (नेविगेशन और स्टेटस बार) को AOSP में लागू किए गए तरीके से नहीं लाता.

7.2.4. टचस्क्रीन इनपुट

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

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

• इसमें किसी तरह का पॉइंटर इनपुट सिस्टम (माउस जैसा या टच) होना चाहिए.
• पूरी तरह से अलग-अलग ट्रैक किए गए पॉइंटर के साथ काम करना चाहिए.

अगर डिवाइसों में टचस्क्रीन (सिंगल-टच या इससे बेहतर) शामिल है, तो:

• [C-1-1] Configuration.touchscreen एपीआई फ़ील्ड के लिए, TOUCHSCREEN_FINGER की जानकारी देना ज़रूरी है.
• [C-1-2] android.hardware.touchscreen और android.hardware.faketouch फ़ीचर फ़्लैग की जानकारी देना ज़रूरी है.

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

• [C-2-1] डिवाइस पर मौजूद टचस्क्रीन के टाइप के हिसाब से, सही फ़ीचर फ़्लैग android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct, android.hardware.touchscreen.multitouch.jazzhand रिपोर्ट करना ज़रूरी है.

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

• [C-3-1] android.hardware.touchscreen से शुरू होने वाले किसी भी फ़ीचर फ़्लैग की जानकारी नहीं देनी चाहिए. साथ ही, सिर्फ़ android.hardware.faketouch की जानकारी देनी चाहिए.

7.2.5. फ़र्ज़ी टच इनपुट

नकली टच वाला इंटरफ़ेस, उपयोगकर्ता को इनपुट सिस्टम उपलब्ध कराता है. यह सिस्टम, टचस्क्रीन की कुछ सुविधाओं के जैसा होता है. उदाहरण के लिए, माउस या रिमोट कंट्रोल से स्क्रीन पर कर्सर को घुमाने पर, टच करने जैसा अनुभव मिलता है. हालांकि, इसके लिए उपयोगकर्ता को पहले पॉइंट करना या फ़ोकस करना होता है. इसके बाद, क्लिक करना होता है. माउस, ट्रैकपैड, जायरोस्कोप पर आधारित एयर माउस, जायरो-पॉइंटर, जॉयस्टिक, और मल्टी-टच ट्रैकपैड जैसे कई इनपुट डिवाइसों पर, नकली टच इंटरैक्शन की सुविधा काम कर सकती है. Android में android.hardware.faketouch कॉन्स्टेंट की सुविधा शामिल है. यह सुविधा, माउस या ट्रैकपैड जैसे हाई-फ़िडेलिटी नॉन-टच (पॉइंटर पर आधारित) इनपुट डिवाइस से जुड़ी है. यह टच-आधारित इनपुट (इसमें बुनियादी जेस्चर सपोर्ट भी शामिल है) को सही तरीके से इम्यूलेट कर सकता है. इससे पता चलता है कि डिवाइस, टचस्क्रीन की सुविधा के इम्यूलेट किए गए सबसेट के साथ काम करता है.

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

• android.hardware.faketouch फ़ीचर फ़्लैग के लिए सहायता का एलान करना चाहिए.

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

• [C-1-1] पॉइंटर की जगह की स्क्रीन पर X और Y की सटीक पोज़िशन की जानकारी देनी होगी. साथ ही, स्क्रीन पर विज़ुअल पॉइंटर दिखाना होगा.
• [C-1-2] टच इवेंट की जानकारी देते समय, ऐक्शन कोड का इस्तेमाल करना ज़रूरी है. इससे यह पता चलता है कि स्क्रीन पर पॉइंटर के नीचे या ऊपर जाने पर क्या बदलाव हुआ.
• [C-1-3] स्क्रीन पर मौजूद किसी ऑब्जेक्ट पर पॉइंटर को नीचे और ऊपर ले जाने की सुविधा होनी चाहिए. इससे उपयोगकर्ता, स्क्रीन पर मौजूद किसी ऑब्जेक्ट पर टैप करने की कार्रवाई को दोहरा सकते हैं.
• [C-1-4] इसमें, स्क्रीन पर मौजूद किसी ऑब्जेक्ट पर, एक तय समय के अंदर पॉइंटर को नीचे ले जाने, ऊपर ले जाने, नीचे ले जाने, और फिर ऊपर ले जाने की सुविधा होनी चाहिए. इससे लोगों को स्क्रीन पर मौजूद किसी ऑब्जेक्ट पर दो बार टैप करने की सुविधा मिलती है.
• [C-1-5] स्क्रीन पर किसी भी पॉइंट पर पॉइंटर डाउन करने की सुविधा होनी चाहिए. साथ ही, स्क्रीन पर किसी भी पॉइंट पर पॉइंटर को ले जाने और फिर पॉइंटर अप करने की सुविधा होनी चाहिए. इससे उपयोगकर्ता, टच ड्रैग की सुविधा का इस्तेमाल कर पाएंगे.
• [C-1-6] इसमें पॉइंटर डाउन करने की सुविधा होनी चाहिए. साथ ही, उपयोगकर्ताओं को ऑब्जेक्ट को स्क्रीन पर किसी दूसरी जगह पर तेज़ी से ले जाने और फिर स्क्रीन पर पॉइंटर अप करने की सुविधा मिलनी चाहिए. इससे उपयोगकर्ता, स्क्रीन पर किसी ऑब्जेक्ट को फ़्लिंग कर सकते हैं.
• [C-1-7] Configuration.touchscreen एपीआई फ़ील्ड के लिए, TOUCHSCREEN_NOTOUCH की जानकारी देना ज़रूरी है.

अगर डिवाइस में सेट किए गए सिस्टम में 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. बटन मैपिंग

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

• [C-1-1] MUST have embed a controller or ship with a separate controller in the box, that would provide means to input all the events listed in the below tables.
• [C-1-2] HID इवेंट को, उससे जुड़े Android view.InputEvent कॉन्स्टेंट पर मैप करने की सुविधा होनी चाहिए. इन कॉन्स्टेंट की सूची यहां दी गई टेबल में दी गई है. Android के अपस्ट्रीम वर्शन में, गेम कंट्रोलर के लिए इस सुविधा को लागू किया गया है. इससे यह ज़रूरी शर्त पूरी होती है.

1 KeyEvent

2 ऊपर दिए गए एचआईडी इस्तेमाल को गेम पैड सीए (0x01 0x0005) में शामिल करना ज़रूरी है.

3 इस इस्तेमाल में, लॉजिकल मिनिमम 0, लॉजिकल मैक्सिमम 7, फ़िज़िकल मिनिमम 0, फ़िज़िकल मैक्सिमम 315, यूनिट डिग्री में, और रिपोर्ट का साइज़ 4 होना चाहिए. लॉजिकल वैल्यू को वर्टिकल ऐक्सिस से क्लॉकवाइज़ रोटेशन के तौर पर तय किया जाता है. उदाहरण के लिए, लॉजिकल वैल्यू 0 का मतलब है कि कोई रोटेशन नहीं हुआ है और ऊपर की ओर वाला बटन दबाया गया है. वहीं, लॉजिकल वैल्यू 1 का मतलब है कि 45 डिग्री का रोटेशन हुआ है और ऊपर की ओर और बाईं ओर वाले दोनों बटन दबाए गए हैं.

4 MotionEvent

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] ऐप्लिकेशन प्रोसेसर के चालू होने पर, सेंसर स्ट्रीम के लिए ज़्यादा से ज़्यादा 0 मि॰से॰ की अनुरोध की गई लेटेन्सी के मामले में, सेंसर डेटा को ज़्यादा से ज़्यादा 100 मि॰से॰ + 2 * sample_time की लेटेन्सी के साथ रिपोर्ट करना ज़रूरी है. इस देरी में, फ़िल्टर करने में लगने वाला समय शामिल नहीं है.
• [C-1-3] सेंसर के चालू होने के 400 मिलीसेकंड + 2 * sample_time के अंदर, सेंसर के पहले सैंपल की जानकारी देना ज़रूरी है. इस सैंपल के लिए, सटीकता का स्कोर 0 हो सकता है.

• [SR] Android SDK के दस्तावेज़ में बताए गए तरीके के मुताबिक, नैनोसेकंड में इवेंट का समय रिपोर्ट करना चाहिए. इससे यह पता चलता है कि इवेंट कब हुआ और SystemClock.elapsedRealtimeNano() क्लॉक के साथ कब सिंक हुआ. हमारा सुझाव है कि मौजूदा और नए Android डिवाइस इन ज़रूरी शर्तों को पूरा करें, ताकि वे आने वाले समय में प्लैटफ़ॉर्म के नए वर्शन पर अपग्रेड कर सकें. ऐसा इसलिए, क्योंकि आने वाले समय में यह ज़रूरी कॉम्पोनेंट बन सकता है. सिंक करने में होने वाली गड़बड़ी 100 मिलीसेकंड से कम होनी चाहिए.

• [C-1-4] Android SDK के दस्तावेज़ में बताए गए किसी भी एपीआई के लिए, डिवाइसों को समय-समय पर डेटा सैंपल उपलब्ध कराने होंगे. Android SDK के दस्तावेज़ में बताया गया है कि यह एपीआई, लगातार काम करने वाला सेंसर है. इन डेटा सैंपल में जिटर 3% से कम होना चाहिए. जिटर को इस तरह से तय किया जाता है: लगातार होने वाले इवेंट के बीच, रिपोर्ट किए गए टाइमस्टैंप वैल्यू के अंतर का स्टैंडर्ड डेविएशन.

• [C-1-5] यह पक्का करना ज़रूरी है कि सेंसर इवेंट स्ट्रीम की वजह से, डिवाइस का सीपीयू निलंबित न हो या निलंबित होने के बाद चालू न हो.

• कई सेंसर चालू होने पर, बिजली की खपत, हर सेंसर की बताई गई बिजली की खपत के योग से ज़्यादा नहीं होनी चाहिए.

ऊपर दी गई सूची में सभी सेंसर शामिल नहीं हैं. Android SDK और Android Open Source Project के दस्तावेज़ों में, सेंसर के बारे में दी गई जानकारी को आधिकारिक माना जाएगा.

कुछ सेंसर टाइप कंपोज़िट होते हैं. इसका मतलब है कि उन्हें एक या एक से ज़्यादा अन्य सेंसर से मिले डेटा से बनाया जा सकता है. (उदाहरण के लिए, ओरिएंटेशन सेंसर और लीनियर ऐक्सलरेशन सेंसर.)

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

• इन सेंसर टाइप को लागू करना चाहिए, जब इनमें सेंसर टाइप में बताए गए ज़रूरी फ़िज़िकल सेंसर शामिल हों.

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

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

7.3.1. एक्सलरोमीटर

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

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

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

• [C-1-1] कम से कम 50 हर्ट्ज़ की फ़्रीक्वेंसी तक इवेंट रिपोर्ट करने की सुविधा होनी चाहिए.
• [C-1-2] TYPE_ACCELEROMETER सेंसर को लागू करना और उसके बारे में जानकारी देना ज़रूरी है.
• [C-1-3] Android API में दी गई जानकारी के मुताबिक, Android सेंसर कोऑर्डिनेट सिस्टम का पालन करना ज़रूरी है.
• [C-1-4] यह किसी भी ऐक्सिस पर, फ़्रीफ़ॉल से लेकर चार गुना गुरुत्वाकर्षण(4g) या इससे ज़्यादा को मेज़र करने में सक्षम होना चाहिए.
• [C-1-5] इसका रिज़ॉल्यूशन कम से कम 12 बिट का होना चाहिए.
• [C-1-6] इसका स्टैंडर्ड डेविएशन 0.05 m/s^ से ज़्यादा नहीं होना चाहिए. स्टैंडर्ड डेविएशन की गिनती, हर ऐक्सिस के हिसाब से की जानी चाहिए. इसके लिए, सबसे तेज़ सैंपलिंग रेट पर कम से कम तीन सेकंड तक इकट्ठा किए गए सैंपल का इस्तेमाल किया जाना चाहिए.
• [SR] TYPE_SIGNIFICANT_MOTION कंपोज़िट सेंसर का होना ज़रूरी है.
• [SR] TYPE_ACCELEROMETER_UNCALIBRATED सेंसर को लागू करने और उसके बारे में जानकारी देने का सुझाव दिया जाता है. हमारा सुझाव है कि Android डिवाइसों पर इस ज़रूरी शर्त को पूरा किया जाए, ताकि वे आने वाले समय में प्लैटफ़ॉर्म के नए वर्शन पर अपग्रेड कर सकें. ऐसा हो सकता है कि आने वाले समय में यह ज़रूरी शर्त बन जाए.
• Android SDK के दस्तावेज़ में बताए गए तरीके के मुताबिक, TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER कंपोज़िट सेंसर लागू करने चाहिए.
• कम से कम 200 हर्ट्ज़ तक के इवेंट की जानकारी देनी चाहिए.
• इसका रिज़ॉल्यूशन कम से कम 16-बिट होना चाहिए.
• डिवाइस के इस्तेमाल के दौरान, इसे कैलिब्रेट किया जाना चाहिए. ऐसा तब किया जाना चाहिए, जब डिवाइस के लाइफ़साइकल के दौरान इसकी विशेषताओं में बदलाव होता है. साथ ही, डिवाइस को रीबूट करने के दौरान, कंपनसेशन पैरामीटर को सुरक्षित रखना चाहिए.
• तापमान के हिसाब से सही होना चाहिए.

अगर डिवाइसों में 3-ऐक्सिस एक्सलरोमीटर और TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER में से कोई भी कंपोज़िट सेंसर लागू किया गया है, तो:

• [C-2-1] इनकी बिजली की खपत का कुल योग हमेशा 4 मिलीवॉट से कम होना चाहिए.
• डिवाइस के डाइनैमिक या स्टैटिक मोड में होने पर, दोनों की वैल्यू 2 mW और 0.5 mW से कम होनी चाहिए.

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

• [C-3-1] TYPE_GRAVITY और TYPE_LINEAR_ACCELERATION कंपोज़िट सेंसर को लागू करना ज़रूरी है.
• [C-SR] TYPE_GAME_ROTATION_VECTOR कंपोज़िट सेंसर को लागू करने का सुझाव दिया जाता है.

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

• [C-4-1] TYPE_ROTATION_VECTOR कंपोज़िट सेंसर का होना ज़रूरी है.

7.3.2. मैग्नेटोमीटर

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

• [C-SR] इनमें 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 से ज़्यादा नहीं होना चाहिए.
• TYPE_MAGNETIC_FIELD_UNCALIBRATED सेंसर को लागू किया जाना चाहिए.
• [SR] मौजूदा और नए Android डिवाइसों में 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] जीपीएस/जीएनएसएस रिसीवर शामिल करने का सुझाव दिया जाता है.

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

• [C-1-1] LocationManager#requestLocationUpdate के ज़रिए अनुरोध किए जाने पर, जगह की जानकारी के आउटपुट के साथ, कम से कम 1 हर्ट्ज़ की दर से काम करना चाहिए.
• [C-1-2] खुले आसमान वाली जगहों (मज़बूत सिग्नल, न के बराबर मल्टीपाथ, HDOP < 2) में, 0.5 एमबीपीएस या इससे तेज़ डेटा स्पीड वाले इंटरनेट कनेक्शन से कनेक्ट होने पर, 10 सेकंड के अंदर जगह की जानकारी का पता लगाना ज़रूरी है (पहली बार जगह की जानकारी का पता लगाने में लगने वाला समय). आम तौर पर, इस ज़रूरत को पूरा करने के लिए, किसी तरह की असिस्टेड या अनुमानित जीपीएस/जीएनएसएस तकनीक का इस्तेमाल किया जाता है. इससे जीपीएस/जीएनएसएस लॉक-ऑन टाइम को कम किया जा सकता है. सहायता डेटा में रेफ़रंस टाइम, रेफ़रंस लोकेशन, और सैटेलाइट एफ़ेमेरिस/क्लॉक शामिल होता है.
  • [C-1-6] जगह की जानकारी का पता लगाने के बाद, डिवाइसों को खुले आसमान वाली जगहों में पांच सेकंड के अंदर, जगह की जानकारी का पता लगाना ज़रूरी है. यह जानकारी, पिछली बार जगह की जानकारी मिलने के एक घंटे बाद तक की होगी. भले ही, यह अनुरोध डेटा कनेक्शन के बिना और/या डिवाइस बंद करके फिर चालू करने के बाद भेजा गया हो.

• जगह की जानकारी का पता लगाने के बाद, खुले आसमान वाली जगहों में, जब वाहन रुका हो या उसका ऐक्सलरेशन एक मीटर प्रति सेकंड स्क्वेयर्ड से कम हो, तब:

  • [C-1-3] कम से कम 95% समय में, 20 मीटर के दायरे तक जगह की जानकारी का पता लगाना और 0.5 मीटर प्रति सेकंड की स्पीड का पता लगाना ज़रूरी है.
  • [C-1-4] एक ही कॉन्स्टलेशन के कम से कम आठ सैटलाइट को एक साथ ट्रैक करना और GnssStatus.Callback के ज़रिए उनकी जानकारी देना ज़रूरी है.
  • अलग-अलग कॉन्स्टलेशन के कम से कम 24 सैटलाइट एक साथ ट्रैक करने चाहिए. जैसे, जीपीएस और Glonass, Beidou, Galileo में से कोई एक.
  • [C-SR] आपातकालीन फ़ोन कॉल के दौरान, जीएनएसएस लोकेशन प्रोवाइडर एपीआई के ज़रिए सामान्य जीपीएस/जीएनएसएस लोकेशन आउटपुट देने का सुझाव दिया जाता है.
  • [C-SR] एसबीएएस को अपवाद मानकर, ट्रैक किए गए सभी कॉन्स्टलेशन (इनके बारे में GnssStatus मैसेज में बताया गया है) से जीएनएसएस के मेज़रमेंट की जानकारी देने का सुझाव दिया जाता है.
  • [C-SR] एजीसी और जीएनएसएस मेज़रमेंट की फ़्रीक्वेंसी की जानकारी देने का सुझाव दिया जाता है.
  • [C-SR] हर जीपीएस/जीएनएसएस की जगह की जानकारी के हिस्से के तौर पर, सभी सटीक अनुमानों के बारे में बताने का सुझाव दिया जाता है. इनमें बियरिंग, स्पीड, और वर्टिकल शामिल हैं.
  • [C-SR] जीएनएसएस मेज़रमेंट की जानकारी मिलते ही उसे रिपोर्ट करने का सुझाव दिया जाता है. भले ही, जीपीएस/जीएनएसएस से कैलकुलेट की गई जगह की जानकारी अब तक रिपोर्ट न की गई हो.
  • [C-SR] जीएनएसएस की स्यूडोरेंज और स्यूडोरेंज रेट की जानकारी देने का सुझाव दिया जाता है. खुले आसमान वाली जगहों में, जगह की जानकारी का पता लगाने के बाद, जब वाहन रुका हुआ हो या 0.2 मीटर प्रति सेकंड स्क्वेयर्ड से कम ऐक्सलरेशन के साथ चल रहा हो, तब कम से कम 95% समय में, 20 मीटर के दायरे तक जगह की जानकारी और 0.2 मीटर प्रति सेकंड की स्पीड का पता लगाना ज़रूरी है.

7.3.4. जाइरोस्कोप

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

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

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

• [C-1-1] कम से कम 50 हर्ट्ज़ की फ़्रीक्वेंसी तक इवेंट रिपोर्ट करने की सुविधा होनी चाहिए.
• [C-1-2] TYPE_GYROSCOPE सेंसर को लागू करना ज़रूरी है. साथ ही, TYPE_GYROSCOPE_UNCALIBRATED सेंसर को भी लागू करने का सुझाव दिया जाता है.
• [C-1-4] इसका रिज़ॉल्यूशन 12 बिट या इससे ज़्यादा होना चाहिए. साथ ही, इसका रिज़ॉल्यूशन 16 बिट या इससे ज़्यादा होना चाहिए.
• [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 से ज़्यादा नहीं होना चाहिए.
• [SR] यह सुझाव दिया जाता है कि जब डिवाइस कमरे के तापमान पर स्थिर हो, तब कैलिब्रेशन की गड़बड़ी 0.01 रेडियन/सेकंड से कम होनी चाहिए.
• कम से कम 200 हर्ट्ज़ तक के इवेंट की जानकारी देनी चाहिए.

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

• [C-2-1] TYPE_ROTATION_VECTOR कंपोज़िट सेंसर का होना ज़रूरी है.

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

• [C-3-1] TYPE_GRAVITY और TYPE_LINEAR_ACCELERATION कंपोज़िट सेंसर को लागू करना ज़रूरी है.
• [C-SR] TYPE_GAME_ROTATION_VECTOR कंपोज़िट सेंसर को लागू करने का सुझाव दिया जाता है.

7.3.5. बैरोमीटर

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

• [C-SR] बैरोमीटर (आस-पास की हवा के दबाव को मापने वाला सेंसर) शामिल करने का सुझाव दिया जाता है.

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

• [C-1-1] TYPE_PRESSURE सेंसर को लागू करना और उसके बारे में जानकारी देना ज़रूरी है.
• [C-1-2] को 5 हर्ट्ज़ या इससे ज़्यादा की फ़्रीक्वेंसी पर इवेंट डिलीवर करने में सक्षम होना चाहिए.
• [C-1-3] तापमान के हिसाब से सही होना चाहिए.
• [SR] 300hPa से 1100hPa की रेंज में प्रेशर मेज़रमेंट की जानकारी देने का सुझाव दिया जाता है.
• इसमें 1hPa की सटीक जानकारी होनी चाहिए.
• इसकी रिलेटिव ऐक्युरसी 20hPa रेंज में 0.12hPa होनी चाहिए. यह समुद्र तल पर ~200 मीटर के बदलाव पर ~1 मीटर की ऐक्युरसी के बराबर है.

7.3.6. Thermometer

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

• इसमें आस-पास के तापमान को मापने वाला थर्मामीटर (तापमान मापने वाला सेंसर) शामिल हो सकता है.
• इसमें सीपीयू का तापमान मापने वाला सेंसर शामिल किया जा सकता है, लेकिन इसे शामिल नहीं किया जाना चाहिए.

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

• [C-1-1] इसे SENSOR_TYPE_AMBIENT_TEMPERATURE के तौर पर तय किया जाना चाहिए. साथ ही, इससे कमरे/वाहन के केबिन के तापमान को मापा जाना चाहिए. यह तापमान डिग्री सेल्सियस में होना चाहिए.
• [C-1-2] इसे SENSOR_TYPE_TEMPERATURE के तौर पर तय करना ज़रूरी है.
• [C-1-3] डिवाइस के सीपीयू का तापमान मापना ज़रूरी है.
• [C-1-4] MUST NOT measure any other temperature.

ध्यान दें कि SENSOR_TYPE_TEMPERATURE सेंसर टाइप को Android 4.0 में बंद कर दिया गया था.

7.3.7. फ़ोटोमीटर

• डिवाइस में फ़ोटोमीटर (स्क्रीन की रोशनी को अपने-आप घटाने-बढ़ाने वाला सेंसर) शामिल हो सकता है.

7.3.8. निकटता सेंसर

• डिवाइस में प्रॉक्सिमिटी सेंसर शामिल किया जा सकता है.

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

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

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] में, नाइक्विस्ट फ़्रीक्वेंसी के कम से कम 80% के 3dB मेज़रमेंट बैंडविड्थ और इस बैंडविड्थ में व्हाइट नॉइज़ स्पेक्ट्रम का होना ज़रूरी है.
  • कमरे के तापमान पर जांच करने पर, ऐक्सलरेशन रैंडम वॉक 30 μg √Hz से कम होना चाहिए.
  • तापमान के मुकाबले, इसमें ≤ +/- 1 मिलीग्राम/°C का बदलाव होना चाहिए.
  • इसमें सबसे सही फ़िट वाली लाइन की नॉन-लीनियरिटी ≤ 0.5% होनी चाहिए. साथ ही, तापमान के हिसाब से सेंसिटिविटी में बदलाव ≤ 0.03%/C° होना चाहिए.
  • इसमें क्रॉस-ऐक्सिस सेंसिटिविटी 2.5 % से कम होनी चाहिए. साथ ही, डिवाइस के ऑपरेटिंग तापमान की रेंज में क्रॉस-ऐक्सिस सेंसिटिविटी में बदलाव 0.2% से कम होना चाहिए.

• [C-2-2] में TYPE_ACCELEROMETER की तरह ही क्वालिटी की ज़रूरी शर्तों को पूरा करने वाला TYPE_ACCELEROMETER_UNCALIBRATED होना चाहिए.

• [C-2-3] डिवाइस में TYPE_GYROSCOPE सेंसर होना ज़रूरी है. यह सेंसर:

  • यह ज़रूरी है कि इसकी मेज़रमेंट रेंज, कम से कम -1000 और +1000 dps के बीच हो.
  • इसका मेज़रमेंट रिज़ॉल्यूशन कम से कम 16 एलएसबी/डीपीएस होना चाहिए.
  • मेज़रमेंट की फ़्रीक्वेंसी कम से कम 12.5 हर्ट्ज़ या इससे कम होनी चाहिए.
  • मेज़रमेंट की फ़्रीक्वेंसी ज़्यादा से ज़्यादा 400 हर्ट्ज़ या इससे ज़्यादा होनी चाहिए; इसमें SensorDirectChannel RATE_VERY_FAST काम करना चाहिए.
  • मेज़रमेंट नॉइज़ 0.014°/s/√Hz से ज़्यादा नहीं होना चाहिए.
  • [C-SR] में, नाइक्विस्ट फ़्रीक्वेंसी के कम से कम 80% के 3dB मेज़रमेंट बैंडविड्थ और इस बैंडविड्थ में व्हाइट नॉइज़ स्पेक्ट्रम का होना ज़रूरी है.
  • कमरे के तापमान पर जांच करने पर, रेट रैंडम वॉक 0.001 °/s √Hz से कम होना चाहिए.
  • तापमान के मुकाबले, बायस में बदलाव ≤ +/- 0.05 °/ s / °C होना चाहिए.
  • तापमान में ≤ 0.02% / °C के हिसाब से बदलाव होने पर, सेंसिटिविटी में बदलाव होना चाहिए.
  • इसमें सबसे सही फ़िट वाली लाइन की नॉन-लीनियरिटी ≤ 0.2% होनी चाहिए.
  • इसमें नॉइज़ डेंसिटी ≤ 0.007 °/s/√Hz होनी चाहिए.
  • डिवाइस के स्थिर होने पर, तापमान 10 ~ 40 ℃ के बीच होने पर, कैलिब्रेशन की गड़बड़ी 0.002 रेडियन/सेकंड से कम होनी चाहिए.
  • इसमें g-सेंसिटिविटी 0.1°/s/g से कम होनी चाहिए.
  • डिवाइस के ऑपरेटिंग तापमान की रेंज में, क्रॉस-ऐक्सिस की संवेदनशीलता 4.0 % से कम होनी चाहिए. साथ ही, क्रॉस-ऐक्सिस की संवेदनशीलता में बदलाव 0.3% से कम होना चाहिए.

• [C-2-4] में TYPE_GYROSCOPE_UNCALIBRATED होना चाहिए. इसकी क्वालिटी से जुड़ी शर्तें, TYPE_GYROSCOPE के जैसी होनी चाहिए.

• [C-2-5] डिवाइस में TYPE_GEOMAGNETIC_FIELD सेंसर होना ज़रूरी है. साथ ही, यह सेंसर:

  • मेज़रमेंट की रेंज, कम से कम -900 और +900 μT के बीच होनी चाहिए.
  • इसका मेज़रमेंट रिज़ॉल्यूशन कम से कम 5 LSB/uT होना चाहिए.
  • मेज़रमेंट की फ़्रीक्वेंसी कम से कम 5 हर्ट्ज़ या इससे कम होनी चाहिए.
  • मेज़रमेंट की फ़्रीक्वेंसी ज़्यादा से ज़्यादा 50 हर्ट्ज़ या इससे ज़्यादा होनी चाहिए.
  • इसमें मेज़रमेंट नॉइज़ 0.5 uT से ज़्यादा नहीं होना चाहिए.

• [C-2-6] में TYPE_MAGNETIC_FIELD_UNCALIBRATED एट्रिब्यूट की वैल्यू, TYPE_GEOMAGNETIC_FIELD एट्रिब्यूट की वैल्यू के बराबर होनी चाहिए. साथ ही, इसमें ये शर्तें भी पूरी होनी चाहिए:

  • इस सेंसर के लिए, नॉन-वेक-अप फ़ॉर्म को लागू करना ज़रूरी है. साथ ही, इसमें कम से कम 600 सेंसर इवेंट को बफ़र करने की सुविधा होनी चाहिए.
  • [C-SR] अगर रिपोर्ट रेट 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 मि॰वॉ॰ से ज़्यादा नहीं होनी चाहिए. वहीं, डिवाइस के मूव होने पर, बिजली की खपत 1.5 मि॰वॉ॰ से ज़्यादा नहीं होनी चाहिए.
• [C-2-10] डिवाइस में TYPE_STEP_DETECTOR सेंसर होना चाहिए. यह सेंसर:
  • इस सेंसर के नॉन-वेक-अप फ़ॉर्म को लागू करना ज़रूरी है. साथ ही, इसमें कम से कम 100 सेंसर इवेंट को बफ़र करने की सुविधा होनी चाहिए.
  • डिवाइस के स्थिर होने पर, बिजली की खपत 0.5 मि॰वॉ॰ से ज़्यादा नहीं होनी चाहिए. वहीं, डिवाइस के मूव होने पर, बिजली की खपत 1.5 मि॰वॉ॰ से ज़्यादा नहीं होनी चाहिए.
  • बैटरी की खपत 4 mW से ज़्यादा नहीं होनी चाहिए.
• [C-2-11] डिवाइस में TYPE_STEP_COUNTER सेंसर होना ज़रूरी है. यह सेंसर:
  • डिवाइस के स्थिर होने पर, बिजली की खपत 0.5 मि॰वॉ॰ से ज़्यादा नहीं होनी चाहिए. वहीं, डिवाइस के मूव होने पर, बिजली की खपत 1.5 मि॰वॉ॰ से ज़्यादा नहीं होनी चाहिए.
• [C-2-12] डिवाइस में TILT_DETECTOR सेंसर होना ज़रूरी है. यह सेंसर:
  • डिवाइस के स्थिर होने पर, बिजली की खपत 0.5 मि॰वॉ॰ से ज़्यादा नहीं होनी चाहिए. वहीं, डिवाइस के मूव होने पर, बिजली की खपत 1.5 मि॰वॉ॰ से ज़्यादा नहीं होनी चाहिए.
• [C-2-13] ऐक्सिलरोमीटर, जायरोस्कोप, और मैग्नेटोमीटर से रिपोर्ट किए गए एक ही फ़िज़िकल इवेंट का टाइमस्टैंप, एक-दूसरे से 2.5 मिलीसेकंड के अंदर होना चाहिए. ऐक्सिलरोमीटर और जायरोस्कोप से रिपोर्ट किए गए एक ही फ़िज़िकल इवेंट का टाइमस्टैंप, एक-दूसरे से 0.25 मिलीसेकंड के अंदर होना चाहिए.
• [C-2-14] जाइरोस्कोप सेंसर इवेंट के टाइमस्टैंप, कैमरा सबसिस्टम के टाइमस्टैंप के साथ मैच होने चाहिए. साथ ही, इनमें एक मिलीसेकंड से ज़्यादा का अंतर नहीं होना चाहिए.
• [C-2-15] ऐप्लिकेशन को सैंपल, पांच मिलीसेकंड के अंदर डिलीवर किए जाने चाहिए. यह समय, ऐप्लिकेशन को ऊपर दिए गए किसी भी फ़िज़िकल सेंसर पर डेटा उपलब्ध होने के समय से शुरू होता है.
• [C-2-16] जब डिवाइस स्थिर हो, तब बिजली की खपत 0.5 मि॰वॉ॰ से ज़्यादा नहीं होनी चाहिए. साथ ही, जब डिवाइस चल रहा हो, तब बिजली की खपत 2.0 मि॰वॉ॰ से ज़्यादा नहीं होनी चाहिए. ऐसा तब होना चाहिए, जब इनमें से किसी भी सेंसर का इस्तेमाल किया जा रहा हो:
  • 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 API के ज़रिए, डायरेक्ट चैनल टाइप और डायरेक्ट रिपोर्ट रेट लेवल के बारे में सही जानकारी देना ज़रूरी है.
• [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. बायोमेट्रिक सेंसर

बायोमेट्रिक अनलॉक की सुरक्षा को मेज़र करने के बारे में ज़्यादा जानकारी के लिए, कृपया बायोमेट्रिक सुरक्षा को मेज़र करने से जुड़ा दस्तावेज़ देखें.

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

• बायोमेट्रिक सेंसर शामिल होना चाहिए

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

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

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

तीसरे पक्ष के ऐप्लिकेशन और डिवाइसों को कीस्टोर की कुंजियों का ऐक्सेस देने के लिए:

• [C-0-2] इस दस्तावेज़ में बताई गई, मज़बूत की ज़रूरी शर्तों को पूरा करना ज़रूरी है.

इनके अलावा:

• [C-0-3] अगर मज़बूत बायोमेट्रिक ऑथेंटिकेशन पैसिव है (जैसे, चेहरे या आइरिस की पहचान, जहां उपयोगकर्ता के इरादे का कोई साफ़ सिग्नल मौजूद नहीं है), तो इसे पुष्टि करने की कार्रवाई (जैसे, बटन दबाना) के साथ जोड़ा जाना चाहिए.
  • [C-SR] पैसिव बायोमेट्रिक्स के लिए, पुष्टि करने की कार्रवाई को इस तरह से सुरक्षित रखने का सुझाव दिया जाता है कि ऑपरेटिंग सिस्टम या कर्नेल से छेड़छाड़ करने वाला कोई व्यक्ति इसे स्पूफ़ न कर सके. उदाहरण के लिए, इसका मतलब है कि किसी बटन को दबाकर पुष्टि करने की कार्रवाई, सुरक्षित एलिमेंट (एसई) के सिर्फ़ इनपुट वाले सामान्य मकसद के इनपुट/आउटपुट (जीपीआईओ) पिन से होकर जाती है. इस पिन को बटन दबाने के अलावा किसी और तरीके से कंट्रोल नहीं किया जा सकता.

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

• [C-1-1] ज़रूरी है कि फ़ॉल्स ऐक्सेप्टेंस रेट 0.002% से कम हो.
• [C-1-2] अगर स्पूफ़िंग और धोखाधड़ी के मामलों में, पहचान स्वीकार किए जाने की दर 7% से ज़्यादा है, तो यह जानकारी देना ज़रूरी है कि यह मोड, किसी मुश्किल पिन, पैटर्न या पासवर्ड के मुकाबले कम सुरक्षित हो सकता है. साथ ही, इसे चालू करने से जुड़े जोखिमों के बारे में साफ़ तौर पर बताना ज़रूरी है.
• [C-1-3] बायोमेट्रिक पुष्टि के लिए पांच बार गलत तरीके से कोशिश करने के बाद, कम से कम 30 सेकंड तक कोशिशों को सीमित करना ज़रूरी है. गलत तरीके से कोशिश करने का मतलब है कि कैप्चर की गई क्वालिटी (BIOMETRIC_ACQUIRED_GOOD) अच्छी है, लेकिन वह रजिस्टर किए गए बायोमेट्रिक से मेल नहीं खाती.
• [C-1-4] MUST prevent adding new biometrics without first establishing a chain of trust by having the user confirm existing or add a new device credential (PIN/pattern/password) that's secured by TEE; the Android Open Source Project implementation provides the mechanism in the framework to do so.
• [C-1-5] जब किसी उपयोगकर्ता का खाता हटाया जाता है, तो डिवाइस को उस उपयोगकर्ता के सभी बायोमेट्रिक डेटा को पूरी तरह से हटाना होगा. इसमें फ़ैक्ट्री रीसेट के ज़रिए हटाया गया डेटा भी शामिल है.
• [C-1-6] उस बायोमेट्रिक के लिए, अलग-अलग फ़्लैग का पालन करना ज़रूरी है. जैसे, DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE या DevicePolicymanager.KEYGUARD_DISABLE_IRIS .
• [C-1-7] Android 10 के साथ लॉन्च होने वाले नए डिवाइसों के लिए, उपयोगकर्ता को हर 24 घंटे या उससे कम समय में एक बार, पुष्टि करने के सुझाए गए मुख्य तरीके (जैसे कि पिन, पैटर्न, पासवर्ड) का इस्तेमाल करने के लिए कहना ज़रूरी है. साथ ही, Android के पिछले वर्शन से अपग्रेड करने वाले डिवाइसों के लिए, हर 72 घंटे या उससे कम समय में एक बार, पुष्टि करने के सुझाए गए मुख्य तरीके का इस्तेमाल करने के लिए कहना ज़रूरी है.

• [C-1-8] डिवाइस को इनमें से किसी एक स्थिति में होने पर, उपयोगकर्ता को पुष्टि करने के सुझाए गए मुख्य तरीके (जैसे: पिन, पैटर्न, पासवर्ड) का इस्तेमाल करने के लिए कहना चाहिए:

  • चार घंटे तक कोई गतिविधि न होने पर टाइम आउट हो जाएगा या
  • बायोमेट्रिक ऑथेंटिकेशन की पुष्टि करने के लिए तीन बार कोशिश की गई, लेकिन पुष्टि नहीं हो सकी.
  • डिवाइस के क्रेडेंशियल की पुष्टि हो जाने के बाद, निष्क्रियता की समयसीमा और पुष्टि न होने की संख्या रीसेट हो जाती है.

  डिवाइसों को Android के पुराने वर्शन से अपग्रेड करने पर, C-1-8 से छूट मिल सकती है.

• [C-SR] डिवाइस पर मेज़र किए गए फ़िंगरप्रिंट के हिसाब से, फ़िंगरप्रिंट मैच न होने की दर 10% से कम होनी चाहिए.

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

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

• [C-2-1] को ऊपर बताई गई सुविधा से जुड़ी सभी ज़रूरी शर्तों को पूरा करना होगा. हालांकि, [C-1-2] को छोड़कर.
• [C-2-2] ज़रूरी है कि स्पूफ़िंग और धोखाधड़ी वाले ईमेल स्वीकार किए जाने की दर 20% से ज़्यादा न हो.
• [C-2-3] में हार्डवेयर की मदद से कीस्टोर लागू करना ज़रूरी है. साथ ही, बायोमेट्रिक मैचिंग को Android उपयोगकर्ता या कर्नल स्पेस के बाहर, अलग किए गए एक्ज़ीक्यूशन एनवायरमेंट में करना ज़रूरी है. जैसे, ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट (टीईई) या अलग किए गए एक्ज़ीक्यूशन एनवायरमेंट के साथ सुरक्षित चैनल वाली चिप पर.
• [C-2-4] में, पहचान ज़ाहिर करने वाले सभी डेटा को एन्क्रिप्ट (सुरक्षित) किया जाना चाहिए. साथ ही, क्रिप्टोग्राफ़िक तरीके से पुष्टि की जानी चाहिए, ताकि उन्हें अलग किए गए एक्ज़ीक्यूशन एनवायरमेंट या Android Open Source Project की साइट पर लागू करने के दिशा-निर्देशों में बताए गए अलग किए गए एक्ज़ीक्यूशन एनवायरमेंट के साथ सुरक्षित चैनल वाले चिप के बाहर न तो हासिल किया जा सके, न ही पढ़ा जा सके या न ही बदला जा सके.
• [C-2-5] कैमरे से लिए गए बायोमेट्रिक डेटा के लिए, बायोमेट्रिक डेटा के आधार पर ऑथेंटिकेशन या एनरोलमेंट के दौरान:
  • कैमरे को ऐसे मोड में चलाना ज़रूरी है जिससे कैमरा फ़्रेम को आइसोलेटेड एक्ज़ीक्यूशन एनवायरमेंट या आइसोलेटेड एक्ज़ीक्यूशन एनवायरमेंट के साथ सुरक्षित चैनल वाले चिप के बाहर न पढ़ा जा सके और न ही बदला जा सके.
  • आरजीबी सिंगल-कैमरा सलूशन के लिए, कैमरा फ़्रेम को अलग किए गए एक्ज़ीक्यूशन एनवायरमेंट के बाहर पढ़ा जा सकता है. इससे, रजिस्ट्रेशन के लिए झलक जैसी कार्रवाइयों में मदद मिलती है. हालांकि, इसमें बदलाव नहीं किया जा सकता.
• [C-2-6] तीसरे पक्ष के ऐप्लिकेशन को, अलग-अलग बायोमेट्रिक रजिस्ट्रेशन के बीच अंतर करने की अनुमति नहीं देनी चाहिए.
• [C-2-7] टीईई के बाहर, ऐप्लिकेशन प्रोसेसर को पहचान किए जा सकने वाले बायोमेट्रिक डेटा या उससे मिले किसी भी डेटा (जैसे, एम्बेडिंग) को बिना एन्क्रिप्ट (सुरक्षित) किए ऐक्सेस करने की अनुमति नहीं देनी चाहिए.

• [C-2-8] इसमें सुरक्षित प्रोसेसिंग पाइपलाइन होनी चाहिए, ताकि ऑपरेटिंग सिस्टम या कर्नल के साथ समझौता करने पर, डेटा को सीधे तौर पर उपयोगकर्ता के तौर पर गलत तरीके से पुष्टि करने के लिए इंजेक्ट न किया जा सके.

  अगर डिवाइसों को Android के पुराने वर्शन पर पहले ही लॉन्च कर दिया गया है और सिस्टम सॉफ़्टवेयर को अपडेट करके, C-2-8 की ज़रूरी शर्तें पूरी नहीं की जा सकती हैं, तो हो सकता है कि उन्हें इस ज़रूरी शर्त से छूट मिल जाए.

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

• [C-3-1] को ऊपर बताई गई कमज़ोर की सभी ज़रूरी शर्तों को पूरा करना होगा. डिवाइसों को Android के पुराने वर्शन से अपग्रेड करने पर, C-2-7 से छूट नहीं मिलती है.
• [C-3-2] ज़रूरी है कि स्पूफ़िंग और धोखाधड़ी वाले ईमेल स्वीकार किए जाने की दर 7% से ज़्यादा न हो.
• [C-3-3] उपयोगकर्ता को हर 72 घंटे या उससे कम समय में, सुझाए गए प्राइमरी तरीके (जैसे, पिन, पैटर्न, पासवर्ड) से पुष्टि करने के लिए कहना होगा.

7.3.12. पोज़ सेंसर

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

• इसमें छह डिग्री ऑफ़ फ़्रीडम वाले पोज़ सेंसर की सुविधा हो सकती है.

अगर डिवाइस में 6 डिग्री ऑफ़ फ़्रीडम के साथ पोज़ सेंसर काम करता है, तो:

• [C-1-1] TYPE_POSE_6DOF सेंसर को लागू करना और उसके बारे में जानकारी देना ज़रूरी है.
• [C-1-2] को सिर्फ़ रोटेशन वेक्टर से ज़्यादा सटीक होना चाहिए.

7.4. डेटा कनेक्टिविटी

7.4.1. टेलीफ़ोनी

Android API और इस दस्तावेज़ में इस्तेमाल किया गया “टेलीफ़ोनी” शब्द, खास तौर पर GSM या CDMA नेटवर्क के ज़रिए वॉइस कॉल करने और एसएमएस भेजने से जुड़े हार्डवेयर के लिए इस्तेमाल किया जाता है. ऐसा हो सकता है कि ये वॉइस कॉल पैकेट-स्विच किए गए हों या न किए गए हों. हालांकि, Android के लिए इन्हें किसी भी डेटा कनेक्टिविटी से अलग माना जाता है. इस कनेक्टिविटी को एक ही नेटवर्क का इस्तेमाल करके लागू किया जा सकता है. दूसरे शब्दों में कहें, तो Android की “टेलीफ़ोनी” सुविधा और एपीआई का इस्तेमाल सिर्फ़ वॉइस कॉल और एसएमएस के लिए किया जाता है. उदाहरण के लिए, ऐसे डिवाइसों को टेलीफ़ोनी डिवाइस नहीं माना जाता है जिन पर कॉल नहीं किए जा सकते या एसएमएस नहीं भेजे/पाए जा सकते. भले ही, वे डेटा कनेक्टिविटी के लिए सेल्युलर नेटवर्क का इस्तेमाल करते हों.

• Android का इस्तेमाल उन डिवाइसों पर किया जा सकता है जिनमें टेलीफ़ोनी हार्डवेयर शामिल नहीं है. इसका मतलब है कि Android, फ़ोन के अलावा अन्य डिवाइसों के साथ भी काम करता है.

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

• [C-1-1] टेक्नोलॉजी के हिसाब से, android.hardware.telephony फ़ीचर फ़्लैग और अन्य सब-फ़ीचर फ़्लैग के बारे में एलान करना ज़रूरी है.
• [C-1-2] उस टेक्नोलॉजी के लिए, एपीआई की पूरी सुविधा लागू करनी होगी.

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

• [C-2-1] पूरे एपीआई को नो-ऑप्स के तौर पर लागू करना ज़रूरी है.

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

• [C-3-1] EuiccManager API को पूरी तरह से लागू करना ज़रूरी है.

7.4.1.1. नंबर ब्लॉक करने की सुविधा के साथ काम करने वाले डिवाइस

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

• [C-1-1] MUST include number blocking support
• [C-1-2] एसडीके के दस्तावेज़ में बताए गए तरीके के मुताबिक, BlockedNumberContract और उससे जुड़े एपीआई को पूरी तरह से लागू करना ज़रूरी है.
• [C-1-3] ऐप्लिकेशन के साथ किसी भी तरह की बातचीत किए बिना, 'BlockedNumberProvider' में मौजूद किसी फ़ोन नंबर से आने वाले सभी कॉल और मैसेज ब्लॉक किए जाने चाहिए. हालांकि, एसडीके के दस्तावेज़ में बताए गए तरीके से, नंबर ब्लॉक करने की सुविधा को कुछ समय के लिए बंद किया जा सकता है.
• [C-1-4] ब्लॉक किए गए कॉल के लिए, कॉल लॉग की जानकारी देने वाली कंपनी को जानकारी नहीं भेजनी चाहिए.
• [C-1-5] ब्लॉक किए गए मैसेज के लिए, टेलीफ़ोनी की सेवा देने वाली कंपनी को नहीं लिखना चाहिए.
• [C-1-6] ऐप्लिकेशन में, ब्लॉक किए गए नंबर मैनेज करने के लिए यूज़र इंटरफ़ेस (यूआई) होना चाहिए. यह यूज़र इंटरफ़ेस (यूआई), TelecomManager.createManageBlockedNumbersIntent() तरीके से मिले इंटेंट के साथ खुलता है.
• [C-1-7] दूसरे क्रम के उपयोगकर्ताओं को, डिवाइस पर ब्लॉक किए गए नंबर देखने या उनमें बदलाव करने की अनुमति नहीं देनी चाहिए. ऐसा इसलिए, क्योंकि Android प्लैटफ़ॉर्म यह मानता है कि डिवाइस पर टेलीफ़ोनी सेवाओं का पूरा कंट्रोल, प्राथमिक उपयोगकर्ता के पास होता है. सेकंडरी उपयोगकर्ताओं के लिए, ब्लॉक करने से जुड़ा पूरा यूज़र इंटरफ़ेस (यूआई) छिपा होना चाहिए. साथ ही, ब्लॉक किए गए लोगों की सूची का पालन किया जाना चाहिए.
• जब कोई डिवाइस Android 7.0 पर अपडेट होता है, तो ब्लॉक किए गए नंबरों को सेवा देने वाली कंपनी के पास माइग्रेट करना चाहिए.

7.4.1.2. Telecom API

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

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

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

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

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

• [C-SR] android.telecom एपीआई के लिए, ऑडियो हेडसेट के KEYCODE_MEDIA_PLAY_PAUSE और KEYCODE_HEADSETHOOK इवेंट को मैनेज करने का सुझाव दिया जाता है. इसके लिए, यहां दिया गया तरीका अपनाएं:
  • कॉल चालू होने के दौरान, बटन को कुछ देर के लिए दबाने पर Connection.onDisconnect() को कॉल करें.
  • इनकमिंग कॉल के दौरान, मुख्य इवेंट को कम समय के लिए दबाने का पता चलने पर, Connection.onAnswer() को कॉल करें.
  • इनकमिंग कॉल के दौरान, बटन को दबाकर रखने पर Connection.onReject() को कॉल करें.
  • CallAudioState के म्यूट होने की स्थिति को टॉगल करें.

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] मल्टीकास्ट डीएनएस (एमडीएनएस) का इस्तेमाल किया जा सकता है. साथ ही, डिवाइस के चालू रहने के दौरान, एमडीएनएस पैकेट (224.0.0.251) को फ़िल्टर नहीं किया जाना चाहिए. जैसे:
  • भले ही, स्क्रीन चालू न हो.
  • Android TV डिवाइसों में, स्टैंडबाय मोड में होने पर भी ऐसा होता है.
• [C-1-5] WifiManager.enableNetwork() एपीआई के तरीके को कॉल करने को, डिफ़ॉल्ट रूप से इस्तेमाल किए जा रहे Network को स्विच करने के लिए काफ़ी नहीं माना जाना चाहिए. इसका इस्तेमाल ऐप्लिकेशन के ट्रैफ़िक के लिए किया जाता है. साथ ही, इसे ConnectivityManager एपीआई के तरीकों से वापस लाया जाता है. जैसे, getActiveNetwork और registerDefaultNetworkCallback. दूसरे शब्दों में कहें, तो वे सिर्फ़ तब किसी अन्य नेटवर्क सेवा देने वाली कंपनी (जैसे, मोबाइल डेटा) से मिले इंटरनेट ऐक्सेस को बंद कर सकते हैं, जब वे यह पुष्टि कर लें कि वाई-फ़ाई नेटवर्क से इंटरनेट ऐक्सेस मिल रहा है.
• [C-1-6] ConnectivityManager.reportNetworkConnectivity() एपीआई के तरीके को कॉल करने पर, Network पर इंटरनेट ऐक्सेस का फिर से आकलन करने का सुझाव दिया जाता है. साथ ही, आकलन से यह पता चलने पर कि मौजूदा Network अब इंटरनेट ऐक्सेस नहीं देता है, इंटरनेट ऐक्सेस देने वाले किसी अन्य उपलब्ध नेटवर्क (जैसे, मोबाइल डेटा) पर स्विच करने का सुझाव दिया जाता है.
• [C-SR] जब एसटीए डिसकनेक्ट हो, तब हर स्कैन की शुरुआत में प्रोब रिक्वेस्ट के एमएसी पते और क्रम संख्या को बदलना ज़रूरी है.
  • एक स्कैन के दौरान भेजे गए प्रोब रिक्वेस्ट फ़्रेम के हर ग्रुप को एक ही एमएसी पते का इस्तेमाल करना चाहिए. स्कैन के बीच में एमएसी पता नहीं बदलना चाहिए.
  • प्रोब रिक्वेस्ट फ़्रेम की क्रम संख्या, स्कैन के दौरान सामान्य रूप से क्रम में बढ़ती रहनी चाहिए.
  • किसी स्कैन की आखिरी प्रोब रिक्वेस्ट और अगले स्कैन की पहली प्रोब रिक्वेस्ट के बीच में क्रम संख्या को बदलते रहना चाहिए.
• [C-SR] STA के डिसकनेक्ट होने पर, प्रोब अनुरोध फ़्रेम में सिर्फ़ इन एलिमेंट को अनुमति देने का सुझाव दिया जाता है:
  • SSID पैरामीटर सेट (0)
  • DS पैरामीटर सेट (3)

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

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

7.4.2.2. वाई-फ़ाई टनल वाले डायरेक्ट लिंक का सेटअप

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

• इसमें Android SDK के दस्तावेज़ में बताए गए तरीके से, Wi-Fi टनल वाले डायरेक्ट लिंक सेटअप (टीडीएलएस) की सुविधा शामिल होनी चाहिए.

अगर डिवाइस में टीडीलएस की सुविधा काम करती है और WiFiManager API के ज़रिए टीडीलएस चालू किया गया है, तो:

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

7.4.2.3. Wi-Fi Aware

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

• Wi-Fi Aware के साथ काम करना चाहिए.

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

• [C-1-1] एसडीके के दस्तावेज़ में बताए गए तरीके के मुताबिक, WifiAwareManager एपीआई लागू करना ज़रूरी है.
• [C-1-2] android.hardware.wifi.aware फ़ीचर फ़्लैग के बारे में एलान करना ज़रूरी है.
• [C-1-3] यह ज़रूरी है कि डिवाइस, वाई-फ़ाई और Wi-Fi Aware की सुविधाओं को एक साथ इस्तेमाल करने की अनुमति देता हो.
• [C-1-4] यह ज़रूरी है कि Wi-Fi Aware मैनेजमेंट इंटरफ़ेस के पते को 30 मिनट से ज़्यादा के अंतराल पर और जब भी Wi-Fi Aware चालू हो, तब रैंडमाइज़ किया जाए.

अगर डिवाइसों में, सेक्शन 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. वाई-फ़ाई पासपॉइंट

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

• इसमें Wi-Fi Passpoint की सुविधा होनी चाहिए.

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

• [C-1-1] एसडीके के दस्तावेज़ में बताए गए तरीके के मुताबिक, Passpoint से जुड़े WifiManager एपीआई लागू करने होंगे.
• [C-1-2] डिवाइस में IEEE 802.11u स्टैंडर्ड का इस्तेमाल किया जाना चाहिए. खास तौर पर, नेटवर्क डिस्कवरी और नेटवर्क चुनने से जुड़े स्टैंडर्ड का इस्तेमाल किया जाना चाहिए. जैसे, जेनेरिक एडवर्टाइज़मेंट सर्विस (जीएएस) और ऐक्सेस नेटवर्क क्वेरी प्रोटोकॉल (एएनक्यूपी).

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

• [C-2-1] Passpoint से जुड़े WifiManager एपीआई को लागू करने पर, UnsupportedOperationException थ्रो करना ज़रूरी है.

7.4.2.5. वाई-फ़ाई की जगह की जानकारी (वाई-फ़ाई राउंड ट्रिप टाइम - आरटीटी)

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

• इसमें वाई-फ़ाई की जगह की जानकारी की सुविधा शामिल होनी चाहिए.

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

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

7.4.2.6. वाई-फ़ाई कीपअलाइव ऑफ़लोड

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

• इसमें वाई-फ़ाई कीपअलाइव ऑफ़लोड की सुविधा होनी चाहिए.

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

• [C-1-1] SocketKeepAlive एपीआई के साथ काम करना ज़रूरी है.

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

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

• [C-2-1] ERROR_UNSUPPORTED को वापस करना ज़रूरी है.

7.4.2.7. वाई-फ़ाई ईज़ी कनेक्ट (डिवाइस प्रोविज़निंग प्रोटोकॉल)

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

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

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

• [C-1-1] एसडीके के दस्तावेज़ में बताए गए तरीके के मुताबिक, Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI इंटेंट एपीआई लागू करना ज़रूरी है.
• [C-1-2] में, WifiManager#isEasyConnectSupported() तरीके से true वैल्यू वापस मिलनी चाहिए.

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 (जेनेरिक एट्रिब्यूट प्रोफ़ाइल) पर आधारित ब्लूटूथ एपीआई चालू करना ज़रूरी है.
• [C-3-3] BluetoothAdapter.isOffloadedFilteringSupported() के लिए सही वैल्यू रिपोर्ट करना ज़रूरी है, ताकि यह पता चल सके कि ScanFilter एपीआई क्लास के लिए फ़िल्टर करने का लॉजिक लागू किया गया है या नहीं.
• [C-3-4] BluetoothAdapter.isMultipleAdvertisementSupported() के लिए सही वैल्यू रिपोर्ट करना ज़रूरी है, ताकि यह पता चल सके कि लो एनर्जी एडवर्टाइज़िंग की सुविधा काम करती है या नहीं.
• ScanFilter API लागू करते समय, फ़िल्टर करने की प्रोसेस को ब्लूटूथ चिपसेट पर ऑफ़लोड करने की सुविधा होनी चाहिए.
• डिवाइस में, ब्लूटूथ चिपसेट पर बैच स्कैनिंग की सुविधा होनी चाहिए.

• इसमें कम से कम चार स्लॉट के साथ एक से ज़्यादा विज्ञापन दिखाने की सुविधा होनी चाहिए.

• [SR] उपयोगकर्ता की निजता की सुरक्षा के लिए, यह सुझाव दिया जाता है कि हल किए जा सकने वाले निजी पते (आरपीए) के टाइम आउट को 15 मिनट से ज़्यादा न रखें. साथ ही, टाइम आउट होने पर पते को बदल दें.

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

• [C-4-1] उपयोगकर्ता को System API BluetoothAdapter.isBleScanAlwaysAvailable() के ज़रिए पढ़ी गई वैल्यू को चालू/बंद करने की सुविधा देनी होगी.

अगर डिवाइस में, ब्लूटूथ LE का इस्तेमाल करके कान की मशीन से ऑडियो सुनने की सुविधा में बताए गए तरीके से, ब्लूटूथ LE और Hearing Aids Profile के लिए सहायता शामिल है, तो:

• [C-5-1] BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID) के लिए, true को वापस भेजना ज़रूरी है.

7.4.4. नियर-फ़ील्ड कम्यूनिकेशन

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

• इसमें नियर-फ़ील्ड कम्यूनिकेशन (एनएफ़सी) के लिए, ट्रांसीवर और उससे जुड़ा हार्डवेयर शामिल होना चाहिए.
• [C-0-1] android.nfc.NdefMessage और android.nfc.NdefRecord एपीआई को लागू करना ज़रूरी है. भले ही, इनमें एनएफ़सी की सुविधा काम न करती हो या android.hardware.nfc सुविधा का एलान न किया गया हो. ऐसा इसलिए, क्योंकि क्लास, प्रोटोकॉल से अलग डेटा प्रज़ेंटेशन फ़ॉर्मैट को दिखाती हैं.

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

• [C-1-1] android.content.pm.PackageManager.hasSystemFeature() तरीके से, android.hardware.nfc सुविधा के बारे में जानकारी देना ज़रूरी है.
• इनमें, एनएफ़सी के इन स्टैंडर्ड के ज़रिए, एनडीईएफ़ मैसेज पढ़ने और लिखने की सुविधा होनी चाहिए:
• [C-1-2] यह डिवाइस, एनएफ़सी फ़ोरम के रीडर/राइटर के तौर पर काम कर सकता हो. इसके लिए, एनएफ़सी फ़ोरम की तकनीकी जानकारी NFCForum-TS-DigitalProtocol-1.0 में बताए गए एनएफ़सी स्टैंडर्ड का इस्तेमाल किया जाता है:
  • NfCA (ISO14443-3A)
  • NfCB (ISO14443-3B)
  • NfcF (JIS X 6319-4)
  • IsoDep (ISO 14443-4)
  • NFC फ़ोरम के टैग टाइप 1, 2, 3, 4, 5 (NFC फ़ोरम के हिसाब से)

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

अगर डिवाइस में, इस सेक्शन में बताई गई सामान्य एनएफ़सी की सुविधा शामिल है और रीडर/राइटर की भूमिका में 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. नेटवर्क की कम से कम क्षमता

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

• [C-0-1] डिवाइस में, एक या उससे ज़्यादा तरह के डेटा नेटवर्किंग की सुविधा होनी चाहिए. खास तौर पर, डिवाइस में कम से कम एक ऐसा डेटा स्टैंडर्ड होना चाहिए जो 200 Kbit/सेकंड या इससे ज़्यादा की स्पीड से डेटा ट्रांसफ़र कर सके. इस ज़रूरी शर्त को पूरा करने वाली टेक्नोलॉजी के उदाहरणों में EDGE, HSPA, EV-DO, 802.11g, Ethernet, और Bluetooth PAN शामिल हैं.
• जब फ़िज़िकल नेटवर्किंग स्टैंडर्ड (जैसे कि ईथरनेट) प्राइमरी डेटा कनेक्शन हो, तब कम से कम एक सामान्य वायरलेस डेटा स्टैंडर्ड, जैसे कि 802.11 (वाई-फ़ाई) के लिए भी सहायता शामिल होनी चाहिए.
• डेटा कनेक्टिविटी के एक से ज़्यादा तरीके लागू कर सकता है.
• [C-0-2] इसमें IPv6 नेटवर्किंग स्टैक शामिल होना चाहिए. साथ ही, मैनेज किए गए एपीआई (जैसे, java.net.Socket और java.net.URLConnection) और नेटिव एपीआई (जैसे, AF_INET6 सॉकेट) का इस्तेमाल करके, IPv6 कम्यूनिकेशन की सुविधा होनी चाहिए.
• [C-0-3] IPv6 को डिफ़ॉल्ट रूप से चालू करना ज़रूरी है.
• यह पक्का करना ज़रूरी है कि IPv6 कम्यूनिकेशन, IPv4 जितना भरोसेमंद हो. उदाहरण के लिए:
  • [C-0-4] यह ज़रूरी है कि डिवाइस, डॉज़ मोड में होने पर भी IPv6 से कनेक्ट रहे.
  • [C-0-5] दर सीमित करने की वजह से, डिवाइस को आईपीवी6 के साथ काम करने वाले किसी भी ऐसे नेटवर्क पर आईपीवी6 कनेक्टिविटी नहीं खोनी चाहिए जो आरए लाइफ़टाइम के तौर पर कम से कम 180 सेकंड का इस्तेमाल करता है.
• [C-0-6] जब डिवाइस IPv6 नेटवर्क से कनेक्ट हो, तो उसे तीसरे पक्ष के ऐप्लिकेशन को नेटवर्क से सीधे IPv6 कनेक्टिविटी देनी होगी. इसके लिए, डिवाइस पर स्थानीय तौर पर किसी भी तरह का पता या पोर्ट ट्रांसलेशन नहीं होना चाहिए. मैनेज किए गए एपीआई (जैसे, Socket#getLocalAddress या Socket#getLocalPort) और NDK एपीआई (जैसे, getsockname() या IPV6_PKTINFO) दोनों को, नेटवर्क पर पैकेट भेजने और पाने के लिए इस्तेमाल किया गया आईपी पता और पोर्ट दिखाना ज़रूरी है.

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

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

• [C-1-1] यह ज़रूरी है कि वाई-फ़ाई पर ड्यूअल-स्टैक और सिर्फ़ IPv6 ऑपरेशन काम करे.

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

• [C-2-1] ज़रूरी है कि यह इथरनेट पर ड्यूअल-स्टैक ऑपरेशन के साथ काम करता हो.

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

• सेल्युलर नेटवर्क पर IPv6 ऑपरेशन (सिर्फ़ IPv6 और ड्यूअल-स्टैक) काम करना चाहिए.

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

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

7.4.6. सिंक करने की सुविधा की सेटिंग

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

• [C-0-1] मास्टर ऑटो-सिंक सेटिंग डिफ़ॉल्ट रूप से चालू होनी चाहिए, ताकि getMasterSyncAutomatically() तरीके से “true” वैल्यू मिले.

7.4.7. डेटा बचाने की सेटिंग

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

• [SR] डेटा सेवर मोड उपलब्ध कराने का सुझाव दिया जाता है.

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

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

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

• [C-2-1] ConnectivityManager.getRestrictBackgroundStatus() के लिए, RESTRICT_BACKGROUND_STATUS_DISABLED वैल्यू रिटर्न होनी चाहिए
• [C-2-2] ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED को ब्रॉडकास्ट नहीं करना चाहिए.
• [C-2-3] में ऐसी गतिविधि होनी चाहिए जो Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS इंटेंट को हैंडल करती हो. हालांकि, इसे नो-ऑप के तौर पर लागू किया जा सकता है.

7.4.8. सुरक्षा चिप

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

• [C-1-1] android.se.omapi.SEService.getReaders() तरीके को कॉल करने पर, उपलब्ध Secure Elements रीडर की सूची दिखाना ज़रूरी है.

7.5. कैमरे

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

• [C-1-1] android.hardware.camera.any फ़ीचर फ़्लैग के बारे में एलान करना ज़रूरी है.
• [C-1-2] किसी ऐप्लिकेशन के लिए, डिवाइस पर सबसे ज़्यादा रिज़ॉल्यूशन वाले कैमरा सेंसर से ली गई इमेज के साइज़ के बराबर, तीन RGBA_8888 बिटमैप एक साथ असाइन करना ज़रूरी है. ऐसा तब होना चाहिए, जब कैमरा बुनियादी तौर पर प्रीव्यू करने और फ़ोटो कैप्चर करने के लिए खुला हो.
• [C-1-3] यह पक्का करना ज़रूरी है कि पहले से इंस्टॉल किया गया डिफ़ॉल्ट कैमरा ऐप्लिकेशन, इमेज के मेटाडेटा से उपयोगकर्ता की जगह की जानकारी हटा दे. ऐसा तब किया जाता है, जब उसे MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE या MediaStore.ACTION_VIDEO_CAPTURE इंटेंट हैंडल करने के लिए कहा जाता है और जिस ऐप्लिकेशन को इमेज भेजी जा रही है उसके पास ACCESS_FINE_LOCATION नहीं है.

7.5.1. रियर कैमरा

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

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

• इसमें पीछे की ओर कैमरा होना चाहिए.

अगर डिवाइसों में कम से कम एक पीछे की ओर वाला कैमरा शामिल है, तो:

• [C-1-1] android.hardware.camera और android.hardware.camera.any फ़ीचर फ़्लैग की जानकारी देना ज़रूरी है.
• [C-1-2] इसका रिज़ॉल्यूशन कम से कम 2 मेगापिक्सल होना चाहिए.
• कैमरा ड्राइवर में, हार्डवेयर ऑटो-फ़ोकस या सॉफ़्टवेयर ऑटो-फ़ोकस की सुविधा होनी चाहिए. यह सुविधा, ऐप्लिकेशन सॉफ़्टवेयर के लिए पारदर्शी होनी चाहिए.
• इसमें फ़िक्स्ड-फ़ोकस या ईडॉफ़ (एक्सटेंडेड डेप्थ ऑफ़ फ़ील्ड) हार्डवेयर हो सकता है.
• इसमें फ़्लैश शामिल हो सकता है.

अगर कैमरे में फ़्लैश की सुविधा है, तो:

• [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 के लिए, फ़्रंट कैमरे को डिफ़ॉल्ट कैमरे के तौर पर इस्तेमाल नहीं किया जाना चाहिए. साथ ही, एपीआई को इस तरह कॉन्फ़िगर नहीं किया जाना चाहिए कि फ़्रंट कैमरे को डिफ़ॉल्ट रियर कैमरे के तौर पर माना जाए. भले ही, डिवाइस पर सिर्फ़ एक कैमरा हो.
• [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() में पास किया गया बाइट[] में मौजूद डेटा, NV21 एन्कोडिंग फ़ॉर्मैट में होना चाहिए. इसका मतलब है कि NV21 डिफ़ॉल्ट फ़ॉर्मैट होना चाहिए.
• [C-0-3] android.hardware.Camera के लिए, सामने और पीछे वाले, दोनों कैमरों की झलक दिखाने के लिए, YV12 फ़ॉर्मैट (android.graphics.ImageFormat.YV12 कॉन्स्टेंट के तौर पर दिखाया गया है) का इस्तेमाल करना ज़रूरी है. (हार्डवेयर वीडियो एन्कोडर और कैमरा, किसी भी नेटिव पिक्सल फ़ॉर्मैट का इस्तेमाल कर सकते हैं. हालांकि, डिवाइस पर YV12 में बदलने की सुविधा होनी चाहिए.)
• [C-0-4] android.hardware.camera2 डिवाइसों के लिए, android.media.ImageReader API के ज़रिए आउटपुट के तौर पर 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-SR] एक ही दिशा में फ़ोकस करने वाले कई RGB कैमरों वाले डिवाइसों के लिए, यह सुझाव दिया जाता है कि वे एक लॉजिकल कैमरा डिवाइस इस्तेमाल करें. इसमें CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA सुविधा उपलब्ध हो. साथ ही, इसमें उस दिशा में फ़ोकस करने वाले सभी RGB कैमरे, फ़िज़िकल सब-डिवाइस के तौर पर शामिल हों.

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

• [C-1-1] MUST implement such a camera API using android.hardware.camera2 API.
• android.hardware.camera2 एपीआई को वेंडर टैग और/या एक्सटेंशन दे सकता है.

7.5.5. कैमरे का ओरिएंटेशन

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

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

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] SDK में बताए गए तरीके के मुताबिक, इस शेयर की गई मेमोरी पर android.permission.WRITE_EXTERNAL_STORAGE अनुमति लागू करना ज़रूरी है.
• [C-0-5] एपीआई लेवल 29 या उसके बाद के लेवल को टारगेट करने वाले सभी ऐप्लिकेशन के लिए, स्कोप किए गए स्टोरेज को डिफ़ॉल्ट रूप से चालू करना ज़रूरी है. हालांकि, इन स्थितियों में ऐसा नहीं करना होगा:
  • जब डिवाइस को एपीआई लेवल 29 पर अपग्रेड करने से पहले ऐप्लिकेशन इंस्टॉल किया गया हो. भले ही, ऐप्लिकेशन का टारगेट एपीआई कुछ भी हो.
  • जब ऐप्लिकेशन ने अपने मेनिफ़ेस्ट में android:requestLegacyExternalStorage="true" का अनुरोध किया हो.
  • जब ऐप्लिकेशन को android.permission.WRITE_MEDIA_STORAGE की अनुमति दी जाती है.
• [C-0-6] यह ज़रूरी है कि स्कोप किए गए स्टोरेज की सुविधा वाले ऐप्लिकेशन को, उनके ऐप्लिकेशन से जुड़ी डायरेक्ट्री के बाहर की फ़ाइलों को सीधे तौर पर ऐक्सेस करने की अनुमति न हो. ये डायरेक्ट्री, Context एपीआई के तरीकों से मिलती हैं. जैसे, Context.getExternalFilesDirs(), Context.getExternalCacheDirs(), Context.getExternalMediaDirs(), और Context.getObbDirs() तरीके.
• [C-0-7] जब MediaStore के ज़रिए मीडिया फ़ाइलों को ऐक्सेस किया जाता है, तो उनमें मौजूद जगह की जानकारी का मेटाडेटा छिपाना ज़रूरी है. जैसे, जीपीएस Exif टैग. हालांकि, अगर कॉलिंग ऐप्लिकेशन के पास ACCESS_MEDIA_LOCATION की अनुमति है, तो ऐसा करना ज़रूरी नहीं है.

डिवाइस में सेट किए गए सिस्टम, ऊपर दी गई ज़रूरी शर्तों को इनमें से किसी एक तरीके से पूरा कर सकते हैं:

• उपयोगकर्ता के लिए उपलब्ध रिमूवेबल स्टोरेज, जैसे कि सिक्योर डिजिटल (एसडी) कार्ड स्लॉट.
• Android ओपन सोर्स प्रोजेक्ट (एओएसपी) में लागू की गई इंटरनल (नॉन-रीमूवेबल) स्टोरेज का एक हिस्सा.

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

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

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

• संगठन में काम करने वालों के साथ ऐप्लिकेशन शेयर करने की सुविधा के लिए, इंटरनल ऐप्लिकेशन के शेयर किए गए स्टोरेज के एओएसपी वर्शन का इस्तेमाल करना चाहिए.
• स्टोरेज स्पेस को ऐप्लिकेशन के निजी डेटा के साथ शेयर कर सकता है.

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

• [C-2-1] सिर्फ़ पहले से इंस्टॉल किए गए और खास अधिकारों वाले Android ऐप्लिकेशन को, सेकंडरी बाहरी स्टोरेज में डेटा लिखने की WRITE_MEDIA_STORAGE अनुमति देनी होगी. हालांकि, ऐसा तब नहीं करना होगा, जब वे अपने पैकेज से जुड़ी डायरेक्ट्री में डेटा लिख रहे हों या ACTION_OPEN_DOCUMENT_TREE इंटेंट को ट्रिगर करने पर मिले URI में डेटा लिख रहे हों.
• [C-2-2] यह ज़रूरी है कि android.permission.WRITE_MEDIA_STORAGE अनुमति से जुड़ा डायरेक्ट ऐक्सेस, सिर्फ़ उन ऐप्लिकेशन को दिया जाए जो लोगों को दिखते हैं. ऐसा तब किया जाना चाहिए, जब android.permission.WRITE_EXTERNAL_STORAGE अनुमति भी दी गई हो.
• [SR] हमारा सुझाव है कि पहले से इंस्टॉल किए गए और खास अधिकारों वाले Android ऐप्लिकेशन, स्टोरेज डिवाइसों से इंटरैक्ट करने के लिए android.permission.WRITE_MEDIA_STORAGE से मिले सीधे ऐक्सेस पर भरोसा करने के बजाय, MediaStore जैसे सार्वजनिक एपीआई का इस्तेमाल करें.

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

• [C-3-1] होस्ट कंप्यूटर से, ऐप्लिकेशन के शेयर किए गए स्टोरेज में मौजूद डेटा को ऐक्सेस करने का तरीका उपलब्ध कराना ज़रूरी है.
• Android की मीडिया स्कैनर सेवा और android.provider.MediaStore के ज़रिए, दोनों स्टोरेज पाथ से कॉन्टेंट को साफ़ तौर पर दिखाना चाहिए.
• इस ज़रूरी शर्त को पूरा करने के लिए, यूएसबी मास स्टोरेज का इस्तेमाल किया जा सकता है. हालांकि, मीडिया ट्रांसफ़र प्रोटोकॉल का इस्तेमाल करना चाहिए.

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

• यह रेफ़रंस Android MTP होस्ट, Android File Transfer के साथ काम करना चाहिए.
• इसे यूएसबी डिवाइस क्लास 0x00 की रिपोर्ट देनी चाहिए.
• 'एमटीपी' के यूएसबी इंटरफ़ेस का नाम रिपोर्ट करना चाहिए.

7.6.3. एडॉप्टेबल स्टोरेज

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

• [SR] यह सुझाव दिया जाता है कि अडॉप्टेबल स्टोरेज को लंबे समय तक इस्तेमाल करने के लिए, किसी ऐसी जगह पर रखा जाए जहां वह सुरक्षित रहे. ऐसा इसलिए, क्योंकि गलती से स्टोरेज को डिस्कनेक्ट करने पर, डेटा मिट सकता है या खराब हो सकता है.

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

• [SR] एडॉप्टेबल स्टोरेज को लागू करने का सुझाव दिया जाता है.

7.7. यूएसबी

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

• इसमें यूएसबी पेरिफ़ेरल मोड और यूएसबी होस्ट मोड काम करना चाहिए.

7.7.1. यूएसबी पेरिफ़ेरल मोड

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

• [C-1-1] पोर्ट को ऐसे यूएसबी होस्ट से कनेक्ट किया जा सकता हो जिसमें स्टैंडर्ड टाइप-ए या टाइप-सी यूएसबी पोर्ट हो.
• [C-1-2] android.os.Build.SERIAL के ज़रिए, यूएसबी स्टैंडर्ड डिवाइस डिस्क्रिप्टर में iSerialNumber की सही वैल्यू रिपोर्ट करना ज़रूरी है.
• [C-1-3] टाइप-सी रजिस्टर के स्टैंडर्ड के मुताबिक, 1.5A और 3.0A चार्जर का पता लगाना ज़रूरी है. साथ ही, अगर वे टाइप-सी यूएसबी के साथ काम करते हैं, तो विज्ञापन में हुए बदलावों का पता लगाना ज़रूरी है.
• [SR] पोर्ट में माइक्रो-बी, माइक्रो-एबी या टाइप-सी यूएसबी फ़ॉर्म फ़ैक्टर का इस्तेमाल किया जाना चाहिए. हमारा सुझाव है कि मौजूदा और नए Android डिवाइसों पर इन ज़रूरी शर्तों को पूरा किया जाए, ताकि उन्हें आने वाले समय में प्लैटफ़ॉर्म के नए वर्शन पर अपग्रेड किया जा सके.
• [एसआर] पोर्ट को डिवाइस के निचले हिस्से में होना चाहिए (नैचुरल ओरिएंटेशन के हिसाब से) या सभी ऐप्लिकेशन (होम स्क्रीन भी शामिल है) के लिए सॉफ़्टवेयर स्क्रीन रोटेशन की सुविधा चालू होनी चाहिए, ताकि डिवाइस को पोर्ट के साथ नीचे की ओर रखने पर डिसप्ले सही तरीके से दिखे. हमारा सुझाव है कि मौजूदा और नए Android डिवाइसों पर इन ज़रूरी शर्तों को पूरा किया जाए, ताकि उन्हें आने वाले समय में प्लैटफ़ॉर्म के नए वर्शन पर अपग्रेड किया जा सके.
• [एसआर] यूएसबी बैटरी चार्जिंग स्पेसिफ़िकेशन, रिविज़न 1.2 में बताए गए तरीके के मुताबिक, एचएस चिरप और ट्रैफ़िक के दौरान 1.5 A करंट को सपोर्ट करने की सुविधा लागू करनी चाहिए. हमारा सुझाव है कि मौजूदा और नए Android डिवाइसों पर इन ज़रूरी शर्तों को पूरा किया जाए, ताकि उन्हें आने वाले समय में प्लैटफ़ॉर्म के नए वर्शन पर अपग्रेड किया जा सके.
• [SR] हमारा सुझाव है कि मालिकाना हक वाली चार्जिंग की ऐसी तकनीकों का इस्तेमाल न करें जो Vbus वोल्टेज को डिफ़ॉल्ट लेवल से ज़्यादा बढ़ा देती हैं या सिंक/सोर्स की भूमिकाओं में बदलाव करती हैं. ऐसा इसलिए, क्योंकि इससे उन चार्जर या डिवाइसों के साथ इंटरऑपरेबिलिटी की समस्याएं हो सकती हैं जो यूएसबी पावर डिलीवरी की स्टैंडर्ड तकनीकों के साथ काम करते हैं. हालांकि, इसे "बेहद ज़रूरी" बताया गया है, लेकिन आने वाले समय में Android के वर्शन में, हम सभी टाइप-सी डिवाइसों के लिए यह ज़रूरी कर सकते हैं कि वे स्टैंडर्ड टाइप-सी चार्जर के साथ पूरी तरह से काम करें.
• [SR] यह सुझाव दिया जाता है कि डिवाइस में डेटा और पावर रोल स्वैपिंग के लिए पावर डिलीवरी की सुविधा काम करे. इसके लिए, डिवाइस में टाइप-सी यूएसबी और यूएसबी होस्ट मोड की सुविधा होनी चाहिए.
• इसमें ज़्यादा वोल्टेज वाली चार्जिंग के लिए, पावर डिलीवरी की सुविधा होनी चाहिए. साथ ही, डिसप्ले आउट जैसे वैकल्पिक मोड के लिए भी सहायता उपलब्ध होनी चाहिए.
• Android Open Accessory (AOA) API और स्पेसिफ़िकेशन को लागू करना चाहिए. इसके बारे में Android SDK के दस्तावेज़ में बताया गया है.

अगर डिवाइस में यूएसबी पोर्ट शामिल है और 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] MUST implement support to connect standard USB peripherals, in other words, they MUST either:
  • डिवाइस में टाइप सी पोर्ट हो या डिवाइस के साथ ऐसी केबल दी गई हों जो डिवाइस के मालिकाना हक वाले पोर्ट को स्टैंडर्ड यूएसबी टाइप-सी पोर्ट (यूएसबी टाइप-सी डिवाइस) में बदलती हों.
  • डिवाइस में टाइप ए पोर्ट हो या डिवाइस के साथ ऐसी केबल दी गई हो जो डिवाइस के मालिकाना हक वाले पोर्ट को स्टैंडर्ड यूएसबी टाइप-ए पोर्ट में बदलती हो.
  • डिवाइस में माइक्रो-एबी पोर्ट होना चाहिए. साथ ही, डिवाइस के साथ एक ऐसी केबल भी होनी चाहिए जो स्टैंडर्ड टाइप-ए पोर्ट के साथ काम करती हो.
• [C-1-3] इसे यूएसबी टाइप ए या माइक्रो-एबी पोर्ट को टाइप-सी पोर्ट (रिसेप्टेकल) में बदलने वाले अडैप्टर के साथ शिप नहीं किया जाना चाहिए.
• [C-SR] Android SDK के दस्तावेज़ में बताए गए तरीके से, यूएसबी ऑडियो क्लास को लागू करने का सुझाव दिया जाता है.
• होस्ट मोड में कनेक्ट किए गए यूएसबी सहायक डिवाइस को चार्ज करने की सुविधा होनी चाहिए. साथ ही, यूएसबी टाइप-सी कनेक्टर के लिए, यूएसबी टाइप-सी केबल और कनेक्टर स्पेसिफ़िकेशन, वर्शन 1.2 के टर्मिनेशन पैरामीटर सेक्शन में बताए गए तरीके के मुताबिक, कम से कम 1.5 ऐंपियर का सोर्स करंट उपलब्ध कराना चाहिए. इसके अलावा, माइक्रो-एबी कनेक्टर के लिए, यूएसबी बैटरी चार्जिंग स्पेसिफ़िकेशन, वर्शन 1.2 में बताए गए तरीके के मुताबिक, चार्जिंग डाउनस्ट्रीम पोर्ट(सीडीपी) के आउटपुट करंट की रेंज का इस्तेमाल करना चाहिए.
• इसमें यूएसबी टाइप-सी स्टैंडर्ड लागू होने चाहिए और यह उनके साथ काम करना चाहिए.

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

• [C-2-1] यूएसबी एचआईडी क्लास के साथ काम करना ज़रूरी है.
• [C-2-2] यूएसबी एचआईडी यूसेज टेबल और वॉइस कमांड यूसेज रिक्वेस्ट में बताए गए, एचआईडी के इन डेटा फ़ील्ड का पता लगाने और उन्हें KeyEvent कॉन्स्टेंट से मैप करने की सुविधा होनी चाहिए. ये डेटा फ़ील्ड यहां दिए गए हैं:
  • Usage Page (0xC) Usage ID (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
  • Usage Page (0xC) Usage ID (0x0E9): KEYCODE_VOLUME_UP
  • Usage Page (0xC) Usage ID (0x0EA): KEYCODE_VOLUME_DOWN
  • इस्तेमाल से जुड़ा पेज (0xC) इस्तेमाल का आईडी (0x0CF): KEYCODE_VOICE_ASSIST

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

• [C-3-1] इसे रिमोट से कनेक्ट किए गए किसी भी एमटीपी (मीडिया ट्रांसफर प्रोटोकॉल) डिवाइस को पहचानना चाहिए. साथ ही, ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, और ACTION_CREATE_DOCUMENT इंटेंट के ज़रिए, डिवाइस के कॉन्टेंट को ऐक्सेस करने की सुविधा देनी चाहिए.

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

• [C-4-1] यूएसबी टाइप-सी के स्पेसिफ़िकेशन (सेक्शन 4.5.1.3.3) में बताई गई ड्यूअल रोल पोर्ट की सुविधा को लागू करना ज़रूरी है.
• [SR] यह सुझाव दिया जाता है कि DisplayPort काम करे. साथ ही, यह ज़रूरी है कि यूएसबी सुपरस्पीड डेटा रेट काम करे. इसके अलावा, यह सुझाव दिया जाता है कि डेटा और पावर रोल स्वैपिंग के लिए, Power Delivery की सुविधा काम करे.
• [SR] हमारा सुझाव है कि यूएसबी टाइप-सी केबल और कनेक्टर स्पेसिफ़िकेशन के वर्शन 1.2 के अपेंडिक्स A में बताए गए ऑडियो अडैप्टर ऐक्सेसरी मोड का इस्तेमाल न करें.
• डिवाइस के फ़ॉर्म फ़ैक्टर के हिसाब से, Try.* मॉडल लागू करना चाहिए. उदाहरण के लिए, हैंडहेल्ड डिवाइस को Try.SNK मॉडल लागू करना चाहिए.

7.8. ऑडियो

7.8.1. माइक्रोफ़ोन

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

• [C-1-1] android.hardware.microphone सुविधा के कॉन्सटेंट के बारे में बताना ज़रूरी है.
• [C-1-2] सेक्शन 5.4 में बताई गई ऑडियो रिकॉर्डिंग की ज़रूरी शर्तों को पूरा करना ज़रूरी है.
• [C-1-3] को सेक्शन 5.6 में बताई गई ऑडियो लेटेंसी की ज़रूरी शर्तों को पूरा करना होगा.
• [SR] सेक्शन 7.8.3 में बताए गए तरीके से, नियर-अल्ट्रासाउंड रिकॉर्डिंग की सुविधा देने का सुझाव दिया जाता है.

अगर डिवाइसों में माइक्रोफ़ोन नहीं है, तो:

• [C-2-1] android.hardware.microphone सुविधा के कॉन्स्टेंट की जानकारी नहीं देनी चाहिए.
• [C-2-2] सेक्शन 7 के मुताबिक, ऑडियो रिकॉर्डिंग एपीआई को कम से कम नो-ऑप्स के तौर पर लागू करना ज़रूरी है.

7.8.2. ऑडियो आउटपुट

अगर डिवाइसों में स्पीकर या ऑडियो/मल्टीमीडिया आउटपुट पोर्ट शामिल हैं, ताकि ऑडियो आउटपुट पेरिफ़ेरल का इस्तेमाल किया जा सके. जैसे, 4 कंडक्टर वाला 3.5 मि॰मी॰ ऑडियो जैक या यूएसबी ऑडियो क्लास का इस्तेमाल करने वाला यूएसबी होस्ट मोड पोर्ट, तो:

• [C-1-1] android.hardware.audio.output सुविधा के कॉन्सटेंट के बारे में बताना ज़रूरी है.
• [C-1-2] को सेक्शन 5.5 में बताई गई, ऑडियो चलाने की ज़रूरी शर्तों को पूरा करना होगा.
• [C-1-3] को सेक्शन 5.6 में बताई गई ऑडियो लेटेंसी की ज़रूरी शर्तों को पूरा करना होगा.
• [SR] सेक्शन 7.8.3 में बताए गए तरीके से, नियर-अल्ट्रासाउंड प्लेबैक की सुविधा देने का सुझाव दिया जाता है.

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

• [C-2-1] android.hardware.audio.output सुविधा की जानकारी नहीं देनी चाहिए.
• [C-2-2] ऑडियो आउटपुट से जुड़े एपीआई को कम से कम नो-ऑप के तौर पर लागू करना ज़रूरी है.

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

7.8.2.1. ऐनालॉग ऑडियो पोर्ट

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

• [C-SR] कम से कम एक ऑडियो पोर्ट को 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] ओएमटीपी पिन-आउट ऑर्डर के साथ ऑडियो प्लग इस्तेमाल करने का सुझाव दिया जाता है.
• [C-SR] यह सुझाव दिया जाता है कि ये स्टीरियो हेडसेट से ऑडियो रिकॉर्डिंग की सुविधा के साथ काम करें.

अगर डिवाइसों में चार कंडक्टर वाला 3.5 मि॰मी॰ का ऑडियो जैक है और वे माइक्रोफ़ोन के साथ काम करते हैं, तो उन्हें android.intent.action.HEADSET_PLUG को ब्रॉडकास्ट करना होगा. इसमें माइक्रोफ़ोन की अतिरिक्त वैल्यू को 1 के तौर पर सेट करना होगा. ऐसा करने पर:

• [C-2-1] यह ज़रूरी है कि प्लग इन की गई ऑडियो ऐक्सेसरी पर माइक्रोफ़ोन का पता लगाने की सुविधा काम करती हो.

7.8.2.2. डिजिटल ऑडियो पोर्ट

यह हेडसेट, यूएसबी-सी कनेक्टर का इस्तेमाल करने वाले हेडसेट और अन्य ऑडियो ऐक्सेसरी के साथ काम करता है. साथ ही, यह Android यूएसबी हेडसेट के स्पेसिफ़िकेशन में बताए गए तरीके से, Android के पूरे सिस्टम में (यूएसबी ऑडियो क्लास) लागू करता है.

डिवाइस से जुड़ी ज़रूरी शर्तों के लिए, सेक्शन 2.2.1 देखें.

7.8.3. अल्ट्रासाउंड के आस-पास की फ़्रीक्वेंसी

नियर-अल्ट्रासाउंड ऑडियो, 18.5 किलोहर्ट्ज़ से 20 किलोहर्ट्ज़ बैंड होता है.

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

• AudioManager.getProperty एपीआई के ज़रिए, डिवाइस में नियर-अल्ट्रासाउंड ऑडियो की सुविधा के बारे में सही जानकारी देनी होगी. इसके लिए, यह तरीका अपनाएं:

अगर PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND "सही" है, तो VOICE_RECOGNITION और UNPROCESSED ऑडियो सोर्स को ये ज़रूरी शर्तें पूरी करनी होंगी:

• [C-1-1] 18.5 किलोहर्ट्ज़ से 20 किलोहर्ट्ज़ बैंड में माइक्रोफ़ोन की औसत पावर रिस्पॉन्स, 2 किलोहर्ट्ज़ पर रिस्पॉन्स से 15 dB से ज़्यादा कम नहीं होना चाहिए.
• [C-1-2] -26 dBFS पर 19 kHz टोन के लिए, 18.5 kHz से 20 kHz तक माइक्रोफ़ोन का अनवेटेड सिग्नल-टू-नॉइज़ रेशियो 50 dB से कम नहीं होना चाहिए.

अगर PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND "true" है, तो:

• [C-2-1] स्पीकर का 18.5 किलोहर्ट्ज़ से 20 किलोहर्ट्ज़ के बीच का औसत रिस्पॉन्स, 2 किलोहर्ट्ज़ के रिस्पॉन्स से 40 डेसिबल से कम नहीं होना चाहिए.

7.8.4. सिग्नल इंटिग्रिटी

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

• हाथ में पकड़कर इस्तेमाल किए जाने वाले डिवाइसों पर, इनपुट और आउटपुट, दोनों स्ट्रीम के लिए बिना किसी गड़बड़ी वाला ऑडियो सिग्नल पाथ उपलब्ध कराना चाहिए. गड़बड़ी न होने का मतलब है कि हर पाथ के लिए एक मिनट के टेस्ट के दौरान, कोई गड़बड़ी नहीं मिली. [OboeTester] (https://github.com/google/oboe/tree/master/apps/OboeTester) का इस्तेमाल करके, “ऑटोमेटेड ग्लिच टेस्ट” करें.

इस टेस्ट के लिए, ऑडियो लूपबैक डोंगल की ज़रूरत होती है. इसे सीधे तौर पर 3.5 मि॰मी॰ जैक में इस्तेमाल किया जाता है और/या यूएसबी-सी से 3.5 मि॰मी॰ अडैप्टर के साथ इस्तेमाल किया जाता है. सभी ऑडियो आउटपुट पोर्ट की जांच की जानी चाहिए.

OboeTester फ़िलहाल AAudio पाथ के साथ काम करता है. इसलिए, AAudio का इस्तेमाल करके गड़बड़ियों की जांच के लिए, इन कॉम्बिनेशन का इस्तेमाल किया जाना चाहिए:

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

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_OVR_multiview_multisampled_render_to_texture, GL_EXT_protected_textures को लागू करना ज़रूरी है. साथ ही, उपलब्ध GL एक्सटेंशन की सूची में एक्सटेंशन दिखाना ज़रूरी है.
• [C-SR] यह सुझाव दिया जाता है कि GL_EXT_external_buffer और GL_EXT_EGL_image_array को लागू करें. साथ ही, उपलब्ध GL एक्सटेंशन की सूची में एक्सटेंशन दिखाएं.
• [C-SR] Vulkan 1.1 के साथ काम करने का सुझाव दिया जाता है.
• [C-SR] VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing, VK_KHR_shared_presentable_image को लागू करने और इसे उपलब्ध Vulkan एक्सटेंशन की सूची में दिखाने का सुझाव दिया जाता है.
• [C-SR] कम से कम एक 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 के साथ इस्तेमाल किए जाने वाले फ़्लैग AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT के किसी भी कॉम्बिनेशन के साथ काम करता हो. साथ ही, कम से कम इन फ़ॉर्मैट के साथ काम करता हो: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
• [C-SR] यह सुझाव दिया जाता है कि AHardwareBuffers को एक से ज़्यादा लेयर और C-1-10 में बताए गए फ़्लैग और फ़ॉर्मैट के साथ काम करना चाहिए.
• [C-1-11] कम से कम 3840 x 2160 के रिज़ॉल्यूशन और 30 एफ़पीएस पर H.264 डिकोडिंग की सुविधा होनी चाहिए. इसे औसतन 40 एमबीपीएस पर कंप्रेस किया गया हो. यह 30 एफ़पीएस पर 1920 x 1080 के रिज़ॉल्यूशन वाले चार इंस्टेंस (10 एमबीपीएस) या 60 एफ़पीएस पर 1920 x 1080 के रिज़ॉल्यूशन वाले दो इंस्टेंस (20 एमबीपीएस) के बराबर है.
• [C-1-12] इसमें HEVC और VP9 को सपोर्ट करने की सुविधा होनी चाहिए. साथ ही, यह 30 एफ़पीएस पर कम से कम 1920 x 1080 पिक्सल वाले वीडियो को डिकोड कर सके. इस वीडियो को औसतन 10 एमबीपीएस पर कंप्रेस किया गया हो. इसके अलावा, यह 30 एफ़पीएस पर 3840 x 2160 पिक्सल वाले वीडियो को डिकोड कर सके. इस वीडियो को 20 एमबीपीएस पर कंप्रेस किया गया हो. यह 30 एफ़पीएस पर 1920 x 1080 पिक्सल वाले चार वीडियो को डिकोड करने के बराबर है. इन वीडियो को 5 एमबीपीएस पर कंप्रेस किया गया हो.
• [C-1-13] में HardwarePropertiesManager.getDeviceTemperatures एपीआई का इस्तेमाल किया जाना चाहिए. साथ ही, त्वचा के तापमान की सटीक वैल्यू दिखानी चाहिए.
• [C-1-14] में एक एम्बेड की गई स्क्रीन होनी चाहिए. साथ ही, इसका रिज़ॉल्यूशन कम से कम 1920 x 1080 होना चाहिए.
• [C-SR] इनका डिसप्ले रिज़ॉल्यूशन कम से कम 2560 x 1440 होना चाहिए.
• [C-1-15] वीआर मोड में, डिसप्ले कम से कम 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] यह सुझाव दिया जाता है कि ऊपर दिए गए सभी डायरेक्ट चैनल टाइप के लिए, TYPE_HARDWARE_BUFFER डायरेक्ट चैनल टाइप का इस्तेमाल किया जाए.
• [C-1-21] android.hardware.hifi_sensors के लिए, जाइरोस्कोप, एक्सलरोमीटर, और मैग्नेटोमीटर से जुड़ी ज़रूरी शर्तों को पूरा करना ज़रूरी है. इनके बारे में सेक्शन 7.3.9 में बताया गया है.
• [C-SR] android.hardware.sensor.hifi_sensors सुविधा काम करनी चाहिए.
• [C-1-22] MUST have end-to-end motion to photon latency not higher than 28 milliseconds.
• [C-SR] यह सुझाव दिया जाता है कि मोशन से फ़ोटॉन के दिखने के समय का अंतर 20 मिलीसेकंड से ज़्यादा न हो.
• [C-1-23] इसमें पहले फ़्रेम का रेशियो कम से कम 85% होना चाहिए. यह रेशियो, काले से सफ़ेद रंग में ट्रांज़िशन होने के बाद पहले फ़्रेम के पिक्सल की चमक और स्थिर स्थिति में सफ़ेद पिक्सल की चमक के बीच का रेशियो होता है.
• [C-SR] हमारा सुझाव है कि पहले फ़्रेम का अनुपात कम से कम 90% होना चाहिए.
• यह स्क्रीन पर दिखने वाले ऐप्लिकेशन को एक खास कोर दे सकता है. साथ ही, यह Process.getExclusiveCores एपीआई के साथ काम कर सकता है. इससे, स्क्रीन पर दिखने वाले ऐप्लिकेशन के लिए खास तौर पर उपलब्ध सीपीयू कोर की संख्या का पता लगाया जा सकता है.

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

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

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

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

8.1. उपयोगकर्ता अनुभव में एकरूपता

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

8.2. फ़ाइल I/O ऐक्सेस करने की परफ़ॉर्मेंस

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

• सीक्वेंशियल राइट परफ़ॉर्मेंस. इसे 10 एमबी के राइट बफ़र का इस्तेमाल करके, 256 एमबी की फ़ाइल लिखने के आधार पर मापा जाता है.
• रैंडम राइट परफ़ॉर्मेंस. इसे 4 केबी के राइट बफ़र का इस्तेमाल करके, 256 एमबी की फ़ाइल लिखने के आधार पर मापा जाता है.
• सीक्वेंशियल रीड परफ़ॉर्मेंस. इसे 10 एमबी के राइट बफ़र का इस्तेमाल करके, 256 एमबी की फ़ाइल को पढ़ने के आधार पर मापा जाता है.
• रैंडम रीड परफ़ॉर्मेंस. इसे 4 केबी के राइट बफ़र का इस्तेमाल करके, 256 एमबी की फ़ाइल को पढ़ने के आधार पर मापा जाता है.

8.3. बैटरी सेव करने वाले मोड

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

• [C-1-1] ऐप्लिकेशन स्टैंडबाय और बैटरी बचाने वाले डोज़ मोड की ग्लोबल सिस्टम सेटिंग के इस्तेमाल के लिए, ट्रिगर करने, रखरखाव करने, और वेकअप एल्गोरिदम के लिए, एओएसपी के लागू करने के तरीके से अलग नहीं होना चाहिए.
• [C-1-2] ऐप्लिकेशन स्टैंडबाय के लिए, हर बकेट में मौजूद ऐप्लिकेशन के लिए, ग्लोबल सेटिंग का इस्तेमाल करके जॉब, अलार्म, और नेटवर्क की थ्रॉटलिंग को मैनेज करने के लिए, AOSP के लागू करने के तरीके से अलग नहीं होना चाहिए.
• [C-1-3] ऐप्लिकेशन स्टैंडबाय बकेट की संख्या के लिए, AOSP के लागू किए गए तरीके से अलग नहीं होना चाहिए.
• [C-1-4] पावर मैनेजमेंट में बताए गए तरीके से, ऐप्लिकेशन स्टैंडबाय बकेट और डोज़ मोड को लागू करना ज़रूरी है.
• [C-1-5] डिवाइस के पावर सेव मोड में होने पर, PowerManager.isPowerSaveMode() के लिए true को जवाब देना होगा.
• [C-SR] उपयोगकर्ताओं को बैटरी सेवर मोड चालू और बंद करने की सुविधा देने का सुझाव दिया जाता है.
• [C-SR] हमारा सुझाव है कि उपयोगकर्ता को उन सभी ऐप्लिकेशन को दिखाने की सुविधा दें जिन्हें ऐप्लिकेशन स्टैंडबाय और बैटरी बचाने वाले डोज़ मोड से छूट मिली है.

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

अगर डिवाइस सिस्टम, ACPI के हिसाब से S4 पावर स्टेट लागू करते हैं, तो:

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

अगर डिवाइस में ACPI के हिसाब से S3 पावर स्टेट लागू की जाती है, तो:

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

  इसके उलट, जब तीसरे पक्ष के ऐप्लिकेशन को सिस्टम संसाधनों की ज़रूरत हो, तो S3 मोड से बाहर निकलना ज़रूरी है. इसके बारे में इस SDK टूल में बताया गया है.

  उदाहरण के लिए, तीसरे पक्ष के ऐप्लिकेशन FLAG_KEEP_SCREEN_ON के ज़रिए स्क्रीन चालू रखने या PARTIAL_WAKE_LOCK के ज़रिए सीपीयू चालू रखने का अनुरोध करते हैं. हालांकि, डिवाइस को S3 स्टेट में तब तक नहीं जाना चाहिए, जब तक कि उपयोगकर्ता ने C-1-1 में बताए गए तरीके से, डिवाइस को निष्क्रिय स्थिति में रखने के लिए साफ़ तौर पर कोई कार्रवाई न की हो. इसके उलट, जब JobScheduler के ज़रिए तीसरे पक्ष के ऐप्लिकेशन लागू किए गए किसी टास्क को ट्रिगर किया जाता है या तीसरे पक्ष के ऐप्लिकेशन को Firebase Cloud Messaging डिलीवर किया जाता है, तो डिवाइस को S3 मोड से बाहर निकलना होगा. हालांकि, ऐसा तब तक नहीं किया जाएगा, जब तक उपयोगकर्ता ने डिवाइस को निष्क्रिय स्थिति में न रखा हो. ये पूरी तरह से उदाहरण नहीं हैं. AOSP, इस स्थिति से डिवाइस को चालू करने के लिए कई वेक-अप सिग्नल लागू करता है.

8.4. पावर की खपत का हिसाब रखने की सुविधा

ऊर्जा की खपत का ज़्यादा सटीक हिसाब और रिपोर्टिंग से, ऐप्लिकेशन डेवलपर को इंसेंटिव और ऐसे टूल मिलते हैं जिनसे ऐप्लिकेशन में ऊर्जा के इस्तेमाल के पैटर्न को ऑप्टिमाइज़ किया जा सकता है.

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

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

8.5. लगातार अच्छी परफ़ॉर्मेंस

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

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

• [C-0-1] PowerManager.isSustainedPerformanceModeSupported() एपीआई तरीके का इस्तेमाल करके, परफ़ॉर्मेंस मोड को बनाए रखने की सुविधा के बारे में सटीक जानकारी देना ज़रूरी है.

• इसमें लगातार परफ़ॉर्मेंस मोड काम करना चाहिए.

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

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

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

• कम से कम एक ऐसा कोर उपलब्ध कराना चाहिए जिसे सबसे ऊपर दिखने वाला ऐप्लिकेशन रिज़र्व कर सके.

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

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

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

• [C-3-1] Process.getExclusiveCores() एपीआई तरीके से, खाली सूची को वापस लाना ज़रूरी है.

9. सुरक्षा मॉडल के साथ काम करने की सुविधा

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

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

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

9.1. अनुमतियां

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

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

• ज़्यादा अनुमतियां जोड़ सकता है. हालांकि, नई अनुमति के आईडी स्ट्रिंग, android.\* नेमस्पेस में नहीं होने चाहिए.

• [C-0-2] PROTECTION_FLAG_PRIVILEGED के protectionLevel वाली अनुमतियां, सिर्फ़ उन ऐप्लिकेशन को दी जानी चाहिए जो सिस्टम इमेज के खास पाथ में पहले से इंस्टॉल हैं. साथ ही, ये अनुमतियां हर ऐप्लिकेशन के लिए, साफ़ तौर पर अनुमति दी गई अनुमतियों के सबसेट में होनी चाहिए. AOSP, इस ज़रूरी शर्त को पूरा करता है. इसके लिए, वह etc/permissions/ पाथ में मौजूद फ़ाइलों से, हर ऐप्लिकेशन के लिए अनुमति दी गई अनुमतियों को पढ़ता है और उनका पालन करता है. साथ ही, system/priv-app पाथ को खास पाथ के तौर पर इस्तेमाल करता है.

खतरनाक लेवल की अनुमतियां, रनटाइम अनुमतियां होती हैं. targetSdkVersion > 22 वाले ऐप्लिकेशन, रनटाइम के दौरान अनुमतियों का अनुरोध करते हैं.

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

• [C-0-3] उपयोगकर्ता को एक खास इंटरफ़ेस दिखाना ज़रूरी है, ताकि वह यह तय कर सके कि रनटाइम के दौरान मांगी गई अनुमतियां देनी हैं या नहीं. साथ ही, उपयोगकर्ता को रनटाइम की अनुमतियां मैनेज करने के लिए भी एक इंटरफ़ेस उपलब्ध कराना ज़रूरी है.
• [C-0-4] दोनों यूज़र इंटरफ़ेस को लागू करने का सिर्फ़ एक तरीका होना चाहिए.
• [C-0-5] पहले से इंस्टॉल किए गए ऐप्लिकेशन को रनटाइम की कोई भी अनुमति तब तक नहीं दी जानी चाहिए, जब तक कि:
  • ऐप्लिकेशन के इस डेटा का इस्तेमाल करने से पहले, उपयोगकर्ता की सहमति ली जा सकती है.
  • रनटाइम की अनुमतियां, इंटेंट पैटर्न से जुड़ी होती हैं. इसके लिए, पहले से इंस्टॉल किए गए ऐप्लिकेशन को डिफ़ॉल्ट हैंडलर के तौर पर सेट किया जाता है.
• [C-0-6] android.permission.RECOVER_KEYSTORE अनुमति सिर्फ़ उन सिस्टम ऐप्लिकेशन को देनी होगी जो सुरक्षित तरीके से रजिस्टर किए गए रिकवरी एजेंट हैं. सुरक्षित रिकवरी एजेंट, डिवाइस पर मौजूद एक सॉफ़्टवेयर एजेंट होता है. यह डिवाइस से बाहर मौजूद रिमोट स्टोरेज के साथ सिंक होता है. इसमें सुरक्षित हार्डवेयर होता है. यह हार्डवेयर, लॉकस्क्रीन के नॉलेज फ़ैक्टर पर ब्रूट-फ़ोर्स हमलों को रोकने के लिए, Google Cloud Key Vault Service में बताए गए सुरक्षा के स्तर के बराबर या उससे ज़्यादा सुरक्षा देता है.

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

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

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

खास तौर पर, डिवाइस में सेट किए गए सिस्टम के लिए:

• [C-0-8] किसी ऐप्लिकेशन को जगह की जानकारी या शारीरिक गतिविधि से जुड़ा डेटा ऐक्सेस करने की अनुमति देने के लिए, उपयोगकर्ता की सहमति लेना ज़रूरी है.
• [C-0-9] सिर्फ़ उस ऐप्लिकेशन को रनटाइम की अनुमति देनी होगी जिसके पास एसडीके टूल में बताई गई ज़रूरी अनुमति हो. उदाहरण के लिए, TelephonyManager#getServiceState के लिए android.permission.ACCESS_FINE_LOCATION की ज़रूरत होती है).

अनुमतियों को 'पाबंदी लगाई गई' के तौर पर मार्क किया जा सकता है. इससे उनके व्यवहार में बदलाव होता है.

• [C-0-10] hardRestricted फ़्लैग के तौर पर मार्क की गई अनुमतियां, किसी ऐप्लिकेशन को तब तक नहीं दी जानी चाहिए, जब तक:

  • ऐप्लिकेशन की APK फ़ाइल, सिस्टम पार्टीशन में मौजूद हो.
  • उपयोगकर्ता, ऐप्लिकेशन को ऐसी भूमिका असाइन करता है जो hardRestricted की अनुमतियों से जुड़ी हो.
  • इंस्टॉलर, किसी ऐप्लिकेशन को hardRestricted देता है.
  • किसी ऐप्लिकेशन को Android के पुराने वर्शन पर hardRestricted दिया गया हो.

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

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

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

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

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

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

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

अगर डिवाइसों पर एक से ज़्यादा उपयोगकर्ता हैं, तो:

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

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] Android फ़्रेमवर्क के नीचे लागू की गई SELinux या किसी अन्य सुरक्षा सुविधा को, उपयोगकर्ता या ऐप्लिकेशन डेवलपर के लिए कॉन्फ़िगर करने की अनुमति नहीं होनी चाहिए.
• [C-0-4] किसी ऐसे ऐप्लिकेशन को अनुमति नहीं देनी चाहिए जो एपीआई (जैसे कि डिवाइस एडमिनिस्ट्रेशन एपीआई) के ज़रिए किसी दूसरे ऐप्लिकेशन पर असर डाल सकता है. साथ ही, उसे ऐसी नीति कॉन्फ़िगर करने की अनुमति नहीं देनी चाहिए जो कंपैटिबिलिटी से जुड़ी समस्या पैदा करती हो.
• [C-0-5] मीडिया फ़्रेमवर्क को कई प्रोसेस में बांटना ज़रूरी है, ताकि Android Open Source Project की साइट पर बताए गए तरीके से, हर प्रोसेस के लिए ऐक्सेस दिया जा सके.
• [C-0-6] कर्नेल ऐप्लिकेशन सैंडबॉक्सिंग की सुविधा लागू करना ज़रूरी है. इससे मल्टीथ्रेड प्रोग्राम से, कॉन्फ़िगर की जा सकने वाली नीति का इस्तेमाल करके सिस्टम कॉल को फ़िल्टर किया जा सकता है. अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट, इस ज़रूरी शर्त को पूरा करता है. इसके लिए, वह थ्रेडग्रुप सिंक्रनाइज़ेशन (टीएसवाईएनसी) के साथ सेस्कॉम्प-बीपीएफ़ को चालू करता है. इसके बारे में source.android.com के कर्नल कॉन्फ़िगरेशन सेक्शन में बताया गया है.

कर्नल की सुरक्षा और खुद की सुरक्षा करने की सुविधाएं, Android की सुरक्षा के लिए ज़रूरी हैं. डिवाइस में सेट किए गए सिस्टम के लिए:

• [C-0-7] कर्नेल स्टैक बफ़र ओवरफ़्लो से सुरक्षा देने वाले तरीके लागू करना ज़रूरी है. इस तरह के मेकेनिज़्म के उदाहरण CC_STACKPROTECTOR_REGULAR और CONFIG_CC_STACKPROTECTOR_STRONG हैं.
• [C-0-8] कर्नल मेमोरी के लिए, सुरक्षा से जुड़ी सख्त शर्तों को पूरा करना ज़रूरी है.जैसे, एक्ज़ीक्यूटेबल कोड सिर्फ़ पढ़ा जा सकता है, सिर्फ़ पढ़े जा सकने वाले डेटा को न तो एक्ज़ीक्यूट किया जा सकता है और न ही लिखा जा सकता है. साथ ही, लिखे जा सकने वाले डेटा को एक्ज़ीक्यूट नहीं किया जा सकता (जैसे, CONFIG_DEBUG_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] अगर हार्डवेयर, एपीआई लेवल 28 या इसके बाद के वर्शन के साथ शिप किए गए सभी डिवाइसों पर CVE-2017-5715 से प्रभावित हो सकता है, तो ब्रांच प्रेडिक्शन हार्डनिंग को लागू करना ज़रूरी है. जैसे, CONFIG_HARDEN_BRANCH_PREDICTOR.
• [SR] यह सुझाव दिया जाता है कि कर्नेल डेटा को सिर्फ़ शुरुआत में लिखा जाए.साथ ही, शुरुआत के बाद उसे सिर्फ़ पढ़ने के लिए मार्क किया जाए. उदाहरण के लिए, __ro_after_init.

• [C-SR] कर्नेल कोड और मेमोरी के लेआउट को रैंडमाइज़ करने का सुझाव दिया जाता है.साथ ही, ऐसे एक्सपोज़र से बचने का सुझाव दिया जाता है जिनसे रैंडमाइज़ेशन से समझौता हो सकता है. उदाहरण के लिए, /chosen/kaslr-seed Device Tree node या EFI_RNG_PROTOCOL के ज़रिए बूटलोडर एंट्रॉपी के साथ CONFIG_RANDOMIZE_BASE.

• [C-SR] यह सुझाव दिया जाता है कि कर्नल में कंट्रोल फ़्लो इंटिग्रिटी (सीएफ़आई) की सुविधा चालू करें. इससे कोड के दोबारा इस्तेमाल से होने वाले हमलों (जैसे, CONFIG_CFI_CLANG और CONFIG_SHADOW_CALL_STACK) से अतिरिक्त सुरक्षा मिलती है.

• [C-SR] जिन कॉम्पोनेंट पर कंट्रोल-फ़्लो इंटिग्रिटी (सीएफ़आई), शैडो कॉल स्टैक (एससीएस) या पूर्णांक ओवरफ़्लो सैनिटाइज़ेशन (इंटसैन) चालू है उन्हें बंद न करने का सुझाव दिया जाता है.
• [C-SR] सुरक्षा के लिहाज़ से संवेदनशील किसी भी अतिरिक्त यूज़रस्पेस कॉम्पोनेंट के लिए, सीएफ़आई, एससीए, और IntSan को चालू करने का सुझाव दिया जाता है. इनके बारे में सीएफ़आई और IntSan में बताया गया है.

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

• [C-1-1] SELinux को लागू करना ज़रूरी है.
• [C-1-2] SELinux को ग्लोबल एनफ़ोर्सिंग मोड पर सेट करना ज़रूरी है.
• [C-1-3] सभी डोमेन को एनफ़ोर्सिंग मोड में कॉन्फ़िगर करना ज़रूरी है. अनुमति वाले मोड के किसी भी डोमेन का इस्तेमाल नहीं किया जा सकता. इनमें किसी डिवाइस/वेंडर के लिए खास तौर पर बनाए गए डोमेन भी शामिल हैं.
• [C-1-4] यह ज़रूरी है कि सिस्टम/sepolicy फ़ोल्डर में मौजूद neverallow नियमों में बदलाव न किया गया हो, उन्हें हटाया न गया हो या बदला न गया हो. यह फ़ोल्डर, अपस्ट्रीम Android Open Source Project (AOSP) में दिया गया है. साथ ही, यह भी ज़रूरी है कि नीति में मौजूद सभी neverallow नियमों का पालन किया गया हो. ऐसा AOSP SELinux डोमेन और डिवाइस/वेंडर के हिसाब से बने डोमेन, दोनों के लिए ज़रूरी है.
• [C-1-5] तीसरे पक्ष के ऐप्लिकेशन को, एपीआई लेवल 28 या इसके बाद के वर्शन के हिसाब से डिज़ाइन किया गया होना चाहिए. साथ ही, उन्हें हर ऐप्लिकेशन के हिसाब से SELinux सैंडबॉक्स में चलाना होगा. इसके अलावा, हर ऐप्लिकेशन की निजी डेटा डायरेक्ट्री पर, हर ऐप्लिकेशन के हिसाब से SELinux की पाबंदियां लागू होनी चाहिए.
• उन्हें Android Open Source Project के अपस्ट्रीम के system/sepolicy फ़ोल्डर में दी गई डिफ़ॉल्ट SELinux नीति को बनाए रखना चाहिए. साथ ही, अपने डिवाइस के हिसाब से कॉन्फ़िगरेशन के लिए, इस नीति में सिर्फ़ कुछ और चीज़ें जोड़नी चाहिए.

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

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

• [C-2-1] ज़रूरी है कि SELinux के बराबर का मैंडेटरी ऐक्सेस कंट्रोल सिस्टम इस्तेमाल किया जाए.

Android में कई लेयर वाली सुरक्षा की सुविधाएं मौजूद हैं. ये सुविधाएं, डिवाइस की सुरक्षा के लिए ज़रूरी हैं.

9.8. निजता

9.8.1. इस्तेमाल का इतिहास

Android, उपयोगकर्ता की पसंद का इतिहास सेव करता है. साथ ही, UsageStatsManager की मदद से इस इतिहास को मैनेज करता है.

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

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

Android, सिस्टम इवेंट को StatsLog आइडेंटिफ़ायर का इस्तेमाल करके सेव करता है. साथ ही, StatsManager और IncidentManager सिस्टम एपीआई के ज़रिए इस इतिहास को मैनेज करता है.

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

• [C-0-2] सिस्टम एपीआई क्लास IncidentManager से बनाई गई घटना की रिपोर्ट में, सिर्फ़ DEST_AUTOMATIC के तौर पर मार्क किए गए फ़ील्ड शामिल होने चाहिए.
• [C-0-3] StatsLog SDK टूल के दस्तावेज़ों में बताए गए इवेंट के अलावा, किसी अन्य इवेंट को लॉग करने के लिए सिस्टम इवेंट आइडेंटिफ़ायर का इस्तेमाल नहीं किया जाना चाहिए. अगर अतिरिक्त सिस्टम इवेंट लॉग किए जाते हैं, तो वे 1,00,000 से 2,00,000 के बीच की रेंज में मौजूद किसी दूसरे ऐटम आइडेंटिफ़ायर का इस्तेमाल कर सकते हैं.

9.8.2. रिकॉर्डिंग के दौरान

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

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

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

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

अगर डिवाइसों में ऐसी सुविधाएं शामिल हैं जो सिस्टम में मौजूद कॉन्टेंट को कैप्चर करती हैं और/या सिस्टम एपीआई ContentCaptureService के अलावा, डिवाइस पर चलने वाली ऑडियो स्ट्रीम को रिकॉर्ड करती हैं या सेक्शन 9.8.6 कॉन्टेंट कैप्चर में बताए गए अन्य मालिकाना हक वाले तरीकों का इस्तेमाल करती हैं, तो:

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

अगर डिवाइसों में ऐसा कॉम्पोनेंट शामिल है जो बॉक्स से बाहर निकलने पर चालू हो जाता है और आस-पास की आवाज़ रिकॉर्ड कर सकता है और/या डिवाइस पर चलने वाले ऑडियो को रिकॉर्ड कर सकता है, ताकि उपयोगकर्ता के कॉन्टेक्स्ट के बारे में काम की जानकारी मिल सके, तो:

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

9.8.3. कनेक्टिविटी

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

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

9.8.4. नेटवर्क ट्रैफ़िक

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

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

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

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

अगर डिवाइसों में ऐसा सिस्टम मौजूद है जो प्रॉक्सी सर्वर या वीपीएन गेटवे के ज़रिए नेटवर्क डेटा ट्रैफ़िक को रूट करता है, तो:android.permission.CONTROL_VPN

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

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

• [C-3-1] जिन ऐप्लिकेशन में हमेशा चालू रहने वाले वीपीएन की सेवा काम नहीं करती उनके लिए, AndroidManifest.xml फ़ाइल में इस सुविधा को बंद करना ज़रूरी है. इसके लिए, SERVICE_META_DATA_SUPPORTS_ALWAYS_ON एट्रिब्यूट को false पर सेट करें.

9.8.5. डिवाइस आइडेंटिफ़ायर

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

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

9.8.6. सामग्री कैप्चर

Android, सिस्टम एपीआई ContentCaptureService या मालिकाना हक वाले अन्य तरीकों से, डिवाइसों पर लागू होने वाले ऐसे तरीके का इस्तेमाल करता है जिससे ऐप्लिकेशन और उपयोगकर्ता के बीच होने वाले इन इंटरैक्शन को कैप्चर किया जा सके.

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

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

• [C-1-1] डिवाइस में सेव किए जाने पर, इस तरह के सभी डेटा को एन्क्रिप्ट (सुरक्षित) करना ज़रूरी है. इस एन्क्रिप्शन को Android के फ़ाइल आधारित एन्क्रिप्शन या Cipher SDK में बताए गए, एपीआई वर्शन 26 या उसके बाद के वर्शन के तौर पर लिस्ट किए गए किसी भी सिफ़र का इस्तेमाल करके किया जा सकता है.
• [C-1-2] Android बैकअप या बैकअप लेने के किसी अन्य तरीके का इस्तेमाल करके, न तो रॉ डेटा और न ही एन्क्रिप्ट (सुरक्षित) किए गए डेटा का बैक अप लिया जाना चाहिए.
• [C-1-3] को निजता बनाए रखने वाले तरीके का इस्तेमाल करके, इस तरह का सारा डेटा और डिवाइस का लॉग भेजना होगा. निजता बनाए रखने वाले मेकेनिज़्म को इस तरह से परिभाषित किया गया है: “ऐसे मेकेनिज़्म जो सिर्फ़ एग्रीगेट किए गए डेटा का विश्लेषण करने की अनुमति देते हैं और लॉग किए गए इवेंट या निकाले गए नतीजों को अलग-अलग उपयोगकर्ताओं से मैच होने से रोकते हैं”. इससे, किसी भी उपयोगकर्ता के डेटा की जांच नहीं की जा सकती. उदाहरण के लिए, RAPPOR जैसी डिफ़रेंशियल प्राइवसी टेक्नोलॉजी का इस्तेमाल करके इसे लागू किया जाता है.
• [C-1-4] इस तरह के डेटा को डिवाइस पर मौजूद किसी भी उपयोगकर्ता की पहचान (जैसे कि Account) से नहीं जोड़ा जाना चाहिए. हालांकि, डेटा को हर बार जोड़ने से पहले, उपयोगकर्ता की साफ़ तौर पर सहमति ली जानी चाहिए.
• [C-1-5] ऐसे डेटा को अन्य ऐप्लिकेशन के साथ शेयर नहीं किया जाना चाहिए. हालांकि, उपयोगकर्ता की सहमति मिलने पर ही ऐसा किया जा सकता है.
• [C-1-6] अगर डिवाइस पर किसी भी फ़ॉर्म में डेटा सेव किया जाता है, तो ContentCaptureService या मालिकाना हक वाली कंपनी को उपयोगकर्ता को ऐसा डेटा मिटाने की सुविधा देनी होगी.

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

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

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

  • टेलीफ़ोनी, संपर्क, सिस्टम यूज़र इंटरफ़ेस (यूआई), और मीडिया

9.8.7. क्लिपबोर्ड का ऐक्सेस

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

• [C-0-1] क्लिपबोर्ड पर मौजूद डेटा को काटा नहीं जाना चाहिए (जैसे, ClipboardManager एपीआई के ज़रिए). ऐसा तब तक नहीं किया जाना चाहिए, जब तक कि ऐप्लिकेशन डिफ़ॉल्ट IME न हो या वह ऐप्लिकेशन न हो जिस पर फ़िलहाल फ़ोकस किया जा रहा है.

9.8.8. जगह

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

• [C-0-1] उपयोगकर्ता की सहमति के बिना या उपयोगकर्ता के अनुरोध के बिना, डिवाइस की जगह की जानकारी की सेटिंग और वाई-फ़ाई/ब्लूटूथ डिवाइस का पता लगाने की सुविधा की सेटिंग को चालू/बंद नहीं करना चाहिए.
• [C-0-2] ऐप्लिकेशन को उपयोगकर्ता को जगह की जानकारी से जुड़ी जानकारी ऐक्सेस करने की सुविधा देनी होगी. इसमें जगह की जानकारी के लिए हाल ही में किए गए अनुरोध, ऐप्लिकेशन के लेवल की अनुमतियां, और जगह की जानकारी का पता लगाने के लिए वाई-फ़ाई/ब्लूटूथ स्कैनिंग का इस्तेमाल शामिल है.
• [C-0-3] यह पक्का करना ज़रूरी है कि Emergency Location Bypass API [LocationRequest.setLocationSettingsIgnored()] का इस्तेमाल करने वाला ऐप्लिकेशन, उपयोगकर्ता की ओर से शुरू किया गया आपातकालीन सेशन हो. जैसे, 911 पर कॉल करना या 911 पर मैसेज भेजना.
• [C-0-4] इमरजेंसी लोकेशन बाईपास एपीआई को, डिवाइस की जगह की जानकारी की सेटिंग में बदलाव किए बिना, उन्हें बाईपास करने की सुविधा देनी होगी.
• [C-0-5] बैकग्राउंड में ऐप्लिकेशन के [ACCESS_BACKGROUND_LOCATION] अनुमति का इस्तेमाल करके, उपयोगकर्ता की जगह की जानकारी ऐक्सेस करने के बाद, सूचना शेड्यूल करनी होगी. इस सूचना में, उपयोगकर्ता को इस बारे में याद दिलाया जाएगा.

9.9. डेटा स्टोरेज एन्क्रिप्शन

सभी डिवाइसों को सेक्शन 9.9.1 में दी गई ज़रूरी शर्तों को पूरा करना होगा. जिन डिवाइसों को इस दस्तावेज़ में बताए गए एपीआई लेवल से पहले के एपीआई लेवल पर लॉन्च किया गया था उन्हें सेक्शन 9.9.2 और 9.9.3 में बताई गई ज़रूरी शर्तों को पूरा करने से छूट मिली है. हालांकि, उन्हें Android Compatibility Definition दस्तावेज़ के सेक्शन 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. अलग-अलग फ़ाइलों को अलग-अलग तरीकों से एन्क्रिप्ट करने का तरीका

एन्क्रिप्ट (सुरक्षित) किए गए डिवाइस:

• [C-1-1] डिवाइस को बूट अप करने के लिए, उपयोगकर्ता से क्रेडेंशियल नहीं मांगे जाने चाहिए. साथ ही, ACTION_LOCKED_BOOT_COMPLETED मैसेज ब्रॉडकास्ट होने के बाद, डायरेक्ट बूट की सुविधा वाले ऐप्लिकेशन को डिवाइस के एन्क्रिप्ट (डीई) किए गए स्टोरेज को ऐक्सेस करने की अनुमति दी जानी चाहिए.
• [C-1-2] उपयोगकर्ता के डिवाइस को अनलॉक करने के बाद ही, क्रेडेंशियल एन्क्रिप्ट (सीई) किए गए स्टोरेज को ऐक्सेस करने की अनुमति मिलनी चाहिए. इसके लिए, उपयोगकर्ता को अपने क्रेडेंशियल (जैसे, पासकोड, पिन, पैटर्न या फ़िंगरप्रिंट) देने होंगे और ACTION_USER_UNLOCKED मैसेज ब्रॉडकास्ट किया जाएगा.
• [C-1-3] CE से सुरक्षित स्टोरेज को अनलॉक करने के लिए, उपयोगकर्ता के दिए गए क्रेडेंशियल या रजिस्टर की गई एस्क्रो कुंजी के बिना कोई तरीका नहीं दिया जाना चाहिए.
• [C-1-4] वेरिफ़ाइड बूट का इस्तेमाल करना ज़रूरी है. साथ ही, यह पक्का करना ज़रूरी है कि DE कुंजियां, डिवाइस के हार्डवेयर रूट ऑफ़ ट्रस्ट से क्रिप्टोग्राफ़िक तौर पर जुड़ी हों.
• [C-1-5] फ़ाइल के कॉन्टेंट को AES-256-XTS या Adiantum का इस्तेमाल करके एन्क्रिप्ट (सुरक्षित) करना ज़रूरी है. AES-256-XTS का मतलब है, 256-बिट साइफ़र कुंजी की लंबाई वाला ऐडवांस एन्क्रिप्शन स्टैंडर्ड, जो XTS मोड में काम करता है. कुंजी की पूरी लंबाई 512 बिट होती है. Adiantum का मतलब Adiantum-XChaCha12-AES से है. इसके बारे में https://github.com/google/adiantum पर बताया गया है.
• [C-1-6] फ़ाइल के नामों को AES-256-CBC-CTS या Adiantum का इस्तेमाल करके एन्क्रिप्ट (सुरक्षित) करना ज़रूरी है.

• [C-1-12] अगर डिवाइस में ऐडवांस एन्क्रिप्शन स्टैंडर्ड (एईएस) के निर्देश हैं, तो फ़ाइल के कॉन्टेंट के लिए AES-256-XTS और फ़ाइल के नामों के लिए AES-256-CBC-CTS (Adiantum के बजाय) का इस्तेमाल करना ज़रूरी है. एईएस के निर्देश, एआरएम पर आधारित डिवाइसों पर ARMv8 क्रिप्टोग्राफ़ी एक्सटेंशन या x86 पर आधारित डिवाइसों पर AES-NI होते हैं. अगर डिवाइस में एईएस के निर्देश नहीं हैं, तो डिवाइस Adiantum का इस्तेमाल कर सकता है.

• सीई और डीई स्टोरेज एरिया को सुरक्षित रखने वाले पासकोड:

• [C-1-7] इसे क्रिप्टोग्राफ़िक तरीके से, हार्डवेयर से सुरक्षित कुंजी या डेटा वाले कीस्टोर से बाइंड किया जाना चाहिए.

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

• [C-SR] यह सुझाव दिया जाता है कि फ़ाइल सिस्टम के मेटाडेटा को एन्क्रिप्ट (सुरक्षित) किया जाए. जैसे, फ़ाइल का साइज़, मालिकाना हक, मोड, और एक्सटेंडेड एट्रिब्यूट (xattrs). इसके लिए, क्रिप्टोग्राफ़िक तरीके से डिवाइस के हार्डवेयर रूट ऑफ़ ट्रस्ट से जुड़ी कुंजी का इस्तेमाल करें.

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

अपस्ट्रीम Android Open Source प्रोजेक्ट, Linux कर्नल की "fscrypt" एन्क्रिप्शन सुविधा के आधार पर, इस सुविधा को लागू करने का पसंदीदा तरीका उपलब्ध कराता है.

9.10. डिवाइस इंटिग्रिटी

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

• [C-0-1] सिस्टम एपीआई के PersistentDataBlockManager.getFlashLockState() तरीके का इस्तेमाल करके, यह सही तरीके से रिपोर्ट करना ज़रूरी है कि बूटलोडर की स्थिति, सिस्टम इमेज को फ़्लैश करने की अनुमति देती है या नहीं. FLASH_LOCK_UNKNOWN स्थिति, Android के पुराने वर्शन से अपग्रेड करने वाले डिवाइसों के लिए रिज़र्व की गई है. ऐसा इसलिए, क्योंकि इस नए सिस्टम एपीआई तरीके का इस्तेमाल पुराने वर्शन में नहीं किया जा सकता था.

• [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-SR] अगर डिवाइस में कई अलग-अलग चिप मौजूद हैं (जैसे, रेडियो, इमेज प्रोसेसर), तो हमारा सुझाव है कि बूट होने पर हर स्टेज की पुष्टि की जाए.
• [C-1-8] छेड़छाड़ से सुरक्षित स्टोरेज का इस्तेमाल करना ज़रूरी है: यह जानकारी सेव करने के लिए कि बूटलोडर अनलॉक है या नहीं. टैंपर-एविडेंट स्टोरेज का मतलब है कि बूटलोडर यह पता लगा सकता है कि Android के अंदर से स्टोरेज में छेड़छाड़ की गई है या नहीं.
• [C-1-9] डिवाइस का इस्तेमाल करते समय, उपयोगकर्ता को सूचना देनी चाहिए. साथ ही, बूटलोडर लॉक मोड से बूटलोडर अनलॉक मोड पर स्विच करने की अनुमति देने से पहले, उपयोगकर्ता से पुष्टि करानी चाहिए.
• [C-1-10] Android के इस्तेमाल किए गए पार्टीशन (जैसे, बूट, सिस्टम पार्टीशन) के लिए, रोलबैक सुरक्षा लागू करनी होगी. साथ ही, ओएस के कम से कम ज़रूरी वर्शन का पता लगाने के लिए इस्तेमाल किए गए मेटाडेटा को सेव करने के लिए, छेड़छाड़ से सुरक्षित स्टोरेज का इस्तेमाल करना होगा.
• [C-SR] सभी विशेषाधिकार वाले ऐप्लिकेशन की APK फ़ाइलों की पुष्टि करने का सुझाव दिया जाता है. इसके लिए, भरोसे की चेन का इस्तेमाल करें. यह चेन, वेरिफ़ाइड बूट से सुरक्षित किए गए पार्टीशन से जुड़ी होनी चाहिए.
• [C-SR] यह बेहद ज़रूरी है कि विशेषाधिकार वाला ऐप्लिकेशन, अपनी APK फ़ाइल के बाहर से लोड किए गए किसी भी एक्ज़ीक्यूटेबल आर्टफ़ैक्ट (जैसे, डाइनैमिक तरीके से लोड किया गया कोड या कंपाइल किया गया कोड) की पुष्टि करने के बाद ही उसे लागू करे. यह भी बेहद ज़रूरी है कि वह उन्हें लागू न करे.
• उसे ऐसे किसी भी कॉम्पोनेंट के लिए रोलबैक सुरक्षा लागू करनी चाहिए जिसमें फ़र्मवेयर लगातार काम करता रहता है. जैसे, मॉडेम, कैमरा. साथ ही, उसे ऐसे स्टोरेज का इस्तेमाल करना चाहिए जिसमें छेड़छाड़ का पता चल सके. इस स्टोरेज में, कम से कम अनुमत वर्शन का पता लगाने के लिए इस्तेमाल किया गया मेटाडेटा सेव किया जाता है.

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

अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट, external/avb/ रिपॉज़िटरी में इस सुविधा को लागू करने का सबसे अच्छा तरीका बताता है. इसे Android लोड करने के लिए इस्तेमाल किए जाने वाले बूटलोडर में इंटिग्रेट किया जा सकता है.

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

• [C-R] Android Protected Confirmation API के साथ काम करने का सुझाव दिया जाता है.

अगर डिवाइस में Android Protected Confirmation API काम करता है, तो:

• [C-3-1] ConfirmationPrompt.isSupported() एपीआई के लिए, true की रिपोर्ट करना ज़रूरी है.

• [C-3-2] यह पक्का करना ज़रूरी है कि Android OS में चल रहा कोड, उपयोगकर्ता के इंटरैक्शन के बिना पॉज़िटिव रिस्पॉन्स जनरेट न कर सके. भले ही, वह कोड नुकसान पहुंचाने वाला हो या न हो.

• [C-3-3] यह पक्का करना ज़रूरी है कि उपयोगकर्ता, प्रॉम्प्ट किए गए मैसेज की समीक्षा कर सके और उसे स्वीकार कर सके. भले ही, Android OS और उसके कर्नेल से समझौता किया गया हो.

9.11. कुंजियां और क्रेडेंशियल

Android Keystore System की मदद से, ऐप्लिकेशन डेवलपर क्रिप्टोग्राफ़िक पासकोड को किसी कंटेनर में सेव कर सकते हैं. साथ ही, KeyChain API या Keystore API के ज़रिए, क्रिप्टोग्राफ़िक कार्रवाइयों में उनका इस्तेमाल कर सकते हैं. डिवाइस में सेट किए गए सिस्टम के लिए:

• [C-0-1] कम से कम 8,192 कुंजियां इंपोर्ट या जनरेट करने की अनुमति होनी चाहिए.
• [C-0-2] लॉक स्क्रीन पर पुष्टि करने की कोशिशों पर दर की सीमा लागू होनी चाहिए. साथ ही, इसमें एक्सपोनेंशियल बैकऑफ़ एल्गोरिदम होना चाहिए. अगर 150 बार कोशिश करने के बाद भी पुष्टि नहीं हो पाती है, तो हर बार कोशिश करने के बीच कम से कम 24 घंटे का अंतर होना चाहिए.
• जनरेट की जा सकने वाली कुंजियों की संख्या को सीमित नहीं करना चाहिए

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

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

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

• [C-1-5] उपयोगकर्ता को यह चुनने की अनुमति होनी चाहिए कि डिवाइस के अनलॉक से लॉक होने के बीच कितना समय लगे. यह समय कम से कम 15 सेकंड होना चाहिए.

9.11.1. सुरक्षित लॉक स्क्रीन और पुष्टि करने की सुविधा

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

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

• [C-SR] यह सुझाव दिया जाता है कि पुष्टि करने के मुख्य तरीके के तौर पर, इनमें से सिर्फ़ एक को सेट किया जाए:
  • अंकों वाला पिन
  • अक्षर और अंक वाला पासवर्ड
  • ठीक 3x3 बिंदुओं वाली ग्रिड पर स्वाइप करने का पैटर्न

ध्यान दें कि पुष्टि करने के ऊपर दिए गए तरीकों को इस दस्तावेज़ में, पुष्टि करने के सुझाए गए मुख्य तरीकों के तौर पर बताया गया है.

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

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

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

• [C-3-1] इनपुट की सबसे छोटी मान्य लंबाई की एंट्रॉपी, 10 बिट से ज़्यादा होनी चाहिए.
• [C-3-2] सभी संभावित इनपुट की ज़्यादा से ज़्यादा एंट्रॉपी 18 बिट से ज़्यादा होनी चाहिए.
• [C-3-3] पुष्टि करने के नए तरीके से, AOSP में लागू किए गए और दिए गए, पुष्टि करने के सुझाए गए मुख्य तरीकों (जैसे, पिन, पैटर्न, पासवर्ड) में से किसी को भी नहीं बदला जाना चाहिए.
• [C-3-4] अगर डिवाइस नीति कंट्रोलर (डीपीसी) ऐप्लिकेशन ने DevicePolicyManager.setPasswordQuality() तरीके से पासवर्ड की क्वालिटी से जुड़ी नीति सेट की है और क्वालिटी कॉन्स्टेंट PASSWORD_QUALITY_SOMETHING से ज़्यादा पाबंदी वाला है, तो पुष्टि करने के नए तरीके को बंद करना होगा.
• [C-3-5] पुष्टि करने के नए तरीकों को हर 72 घंटे या उससे कम समय में, पुष्टि करने के सुझाए गए मुख्य तरीकों (जैसे, पिन, पैटर्न, पासवर्ड) पर वापस आना चाहिए. इसके अलावा, उपयोगकर्ता को साफ़ तौर पर यह बताना चाहिए कि उसके डेटा की निजता बनाए रखने के लिए, कुछ डेटा का बैक अप नहीं लिया जाएगा.

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

• [C-4-1] सुविधा के लिए, सेक्शन 7.3.10 में बताई गई सभी ज़रूरी शर्तों को पूरा करना ज़रूरी है.
• [C-4-2] MUST have a fall-back mechanism to use one of the recommended primary authentication methods which is based on a known secret.
• [C-4-3] इसे बंद किया जाना चाहिए.साथ ही, डिवाइस नीति कंट्रोलर (डीपीसी) ऐप्लिकेशन के DevicePolicyManager.setKeyguardDisabledFeatures() तरीके को कॉल करके, कीगार्ड की सुविधा से जुड़ी नीति सेट करने पर, स्क्रीन को अनलॉक करने के लिए सिर्फ़ पुष्टि करने के सुझाए गए मुख्य तरीके का इस्तेमाल करने की अनुमति दी जानी चाहिए. साथ ही, इससे जुड़े किसी भी बायोमेट्रिक फ़्लैग (जैसे कि KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE या KEYGUARD_DISABLE_IRIS) का इस्तेमाल किया जाना चाहिए.

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

• [C-5-1] अगर डिवाइस नीति कंट्रोलर (डीपीसी) ऐप्लिकेशन ने DevicePolicyManager.setPasswordQuality() तरीके से, PASSWORD_QUALITY_BIOMETRIC_WEAK से ज़्यादा पाबंदी वाली क्वालिटी कॉन्स्टेंट के साथ पासवर्ड क्वालिटी की नीति सेट की है, तो इन तरीकों को बंद करना होगा.
• [C-5-2] चार घंटे तक डिवाइस का इस्तेमाल न करने के बाद, उपयोगकर्ता को पुष्टि करने के सुझाए गए मुख्य तरीके (जैसे: पिन, पैटर्न, पासवर्ड) का इस्तेमाल करने के लिए कहा जाना चाहिए. डिवाइस क्रेडेंशियल की पुष्टि हो जाने के बाद, निष्क्रियता की वजह से सेशन खत्म होने की अवधि रीसेट हो जाती है.
• [C-5-3] इन तरीकों को सुरक्षित लॉक स्क्रीन के तौर पर नहीं माना जाना चाहिए. साथ ही, इन्हें इस सेक्शन में नीचे दी गई C-8 से शुरू होने वाली ज़रूरी शर्तों को पूरा करना चाहिए.

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

• [C-6-1] उनके पास, पुष्टि करने के सुझाए गए मुख्य तरीकों में से किसी एक का इस्तेमाल करने के लिए, फ़ॉल-बैक मैकेनिज़्म होना चाहिए. यह मैकेनिज़्म, किसी जाने-पहचाने सीक्रेट पर आधारित होता है. साथ ही, यह सुरक्षित लॉक स्क्रीन के तौर पर इस्तेमाल किए जाने की ज़रूरी शर्तों को पूरा करता है.
• [C-6-2] डिवाइस नीति कंट्रोलर (डीपीसी) ऐप्लिकेशन ने DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) या DevicePolicyManager.setPasswordQuality() तरीके से नीति सेट की हो और PASSWORD_QUALITY_UNSPECIFIED से ज़्यादा पाबंदी वाली क्वालिटी कॉन्स्टेंट का इस्तेमाल किया हो, तो नए तरीके को बंद करना होगा. साथ ही, स्क्रीन को अनलॉक करने के लिए, पुष्टि करने के सुझाए गए मुख्य तरीकों में से सिर्फ़ एक तरीके का इस्तेमाल करने की अनुमति देनी होगी.
• [C-6-3] उपयोगकर्ता को कम से कम हर चार घंटे में एक बार, पुष्टि करने के लिए सुझाए गए मुख्य तरीकों (जैसे, पिन, पैटर्न, पासवर्ड) में से किसी एक का इस्तेमाल करने के लिए कहा जाना चाहिए.
• [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-8] उपयोगकर्ता को हर 72 घंटे में कम से कम एक बार, पुष्टि करने के लिए सुझाई गई मुख्य तरीकों (जैसे: पिन, पैटर्न, पासवर्ड) में से किसी एक का इस्तेमाल करने के लिए कहा जाना चाहिए. हालांकि, अगर उपयोगकर्ता की सुरक्षा (जैसे कि ड्राइवर का ध्यान भटकना) से जुड़ी कोई समस्या है, तो ऐसा नहीं किया जाना चाहिए.
• [C-7-9] अगर उपयोगकर्ता ने चार घंटे तक डिवाइस का इस्तेमाल नहीं किया है, तो उसे पुष्टि करने के लिए, सुझाए गए किसी एक तरीके (जैसे: पिन, पैटर्न, पासवर्ड) का इस्तेमाल करने के लिए कहा जाना चाहिए. हालांकि, अगर उपयोगकर्ता की सुरक्षा (जैसे कि ड्राइवर का ध्यान भटकना) से जुड़ी कोई समस्या है, तो ऐसा नहीं किया जाना चाहिए. डिवाइस क्रेडेंशियल की पुष्टि हो जाने के बाद, निष्क्रियता की वजह से सेशन खत्म होने की अवधि रीसेट हो जाती है.
• [C-7-10] को सुरक्षित लॉक स्क्रीन के तौर पर नहीं माना जाना चाहिए. साथ ही, इसे नीचे C-8 में दी गई पाबंदियों का पालन करना चाहिए.
• [C-7-11] मुख्य निजी डिवाइसों (जैसे: हैंडहेल्ड) पर TrustAgents को डिवाइस अनलॉक करने की अनुमति नहीं दी जानी चाहिए.साथ ही, इनका इस्तेमाल सिर्फ़ पहले से अनलॉक किए गए डिवाइस को ज़्यादा से ज़्यादा चार घंटे तक अनलॉक रखने के लिए किया जा सकता है. AOSP में TrustManagerService को डिफ़ॉल्ट रूप से लागू करने पर, यह ज़रूरी शर्त पूरी हो जाती है.
• [C-7-12] स्टोरेज डिवाइस से टारगेट डिवाइस में एस्क्रो टोकन भेजने के लिए, क्रिप्टोग्राफ़िक तौर पर सुरक्षित (जैसे, UKEY2) कम्यूनिकेशन चैनल का इस्तेमाल करना ज़रूरी है.

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

• [C-8-1] अगर डिवाइस नीति कंट्रोलर (डीपीसी) ऐप्लिकेशन ने DevicePolicyManager.setPasswordQuality() तरीके से पासवर्ड की क्वालिटी की नीति सेट की है और क्वालिटी का कॉन्स्टेंट PASSWORD_QUALITY_UNSPECIFIED से ज़्यादा पाबंदी वाला है, तो नए तरीके को बंद करना होगा.
• [C-8-2] उन्हें DevicePolicyManager.setPasswordExpirationTimeout() की ओर से सेट किए गए, पासवर्ड की समयसीमा खत्म होने के टाइमर को रीसेट नहीं करना चाहिए.
• [C-8-3] उन्हें तीसरे पक्ष के ऐप्लिकेशन को लॉक की स्थिति बदलने के लिए, एपीआई का इस्तेमाल करने की अनुमति नहीं देनी चाहिए.

9.11.2. StrongBox

Android Keystore System की मदद से, ऐप्लिकेशन डेवलपर क्रिप्टोग्राफ़िक कुंजियों को एक सुरक्षित प्रोसेसर में सेव कर सकते हैं. साथ ही, ऊपर बताए गए आइसोलेटेड एक्ज़ीक्यूशन एनवायरमेंट में भी सेव कर सकते हैं. इस तरह के सुरक्षित प्रोसेसर को "StrongBox" कहा जाता है. नीचे दी गई ज़रूरी शर्तें C-1-3 से C-1-11 तक, उन ज़रूरी शर्तों के बारे में बताती हैं जिन्हें पूरा करने के बाद ही किसी डिवाइस को StrongBox के तौर पर इस्तेमाल किया जा सकता है.

डिवाइस में सेट किए गए ऐसे सिस्टम जिनमें एक खास सुरक्षित प्रोसेसर होता है. इनके लिए ज़रूरी है कि:

• [C-SR] StrongBox का इस्तेमाल करने का सुझाव दिया जाता है. ऐसा हो सकता है कि आने वाले समय में, StrongBox का इस्तेमाल करना ज़रूरी हो जाए.

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

• [C-1-1] FEATURE_STRONGBOX_KEYSTORE का एलान करना ज़रूरी है.

• [C-1-2] MUST provide dedicated secure hardware that is used to back keystore and secure user authentication. सुरक्षित हार्डवेयर का इस्तेमाल अन्य कामों के लिए भी किया जा सकता है.

• [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] MUST have secure storage which ensures confidentiality, integrity, authenticity, consistency, and freshness of the contents. StrongBox API से अनुमति मिलने के अलावा, स्टोरेज को पढ़ा या बदला नहीं जा सकता.

• [C-1-3] से लेकर [C-1-9] तक की शर्तों का पालन करने की पुष्टि करने के लिए, डिवाइस में सेट किए गए सिस्टम:

  • [C-1-10] इसमें ऐसा हार्डवेयर शामिल होना चाहिए जिसे Secure IC Protection Profile BSI-CC-PP-0084-2014 के तहत सर्टिफ़िकेट मिला हो. इसके अलावा, इसे राष्ट्रीय स्तर पर मान्यता प्राप्त टेस्टिंग लैब ने भी जांचा हो. इस लैब ने Common Criteria Application of Attack Potential to Smartcards के मुताबिक, हाई अटैक पोटेंशियल की कमज़ोरियों का आकलन किया हो.
  • [C-1-11] इसमें ऐसा फ़र्मवेयर शामिल होना चाहिए जिसका आकलन, राष्ट्रीय स्तर पर मान्यता प्राप्त टेस्टिंग लैब ने किया हो. साथ ही, इसमें स्मार्टकार्ड के लिए, हमले की संभावना का आकलन करने के लिए कॉमन क्राइटेरिया के मुताबिक, हमले की ज़्यादा संभावना वाले जोखिम का आकलन शामिल होना चाहिए.
  • [C-SR] यह सुझाव दिया जाता है कि ऐसे हार्डवेयर को शामिल किया जाए जिसका आकलन, सिक्योरिटी टारगेट, इवैल्यूएशन अश्योरेंस लेवल (ईएएल) 5, और AVA_VAN.5 का इस्तेमाल करके किया गया हो. ऐसा हो सकता है कि आने वाले समय में, EAL 5 सर्टिफ़िकेशन ज़रूरी हो जाए.

• [C-SR] को अंदरूनी हमले से बचाने के लिए, STRONGLY RECOMMENDED किया जाता है. इसका मतलब है कि फ़र्मवेयर पर हस्ताक्षर करने वाली कुंजियों का ऐक्सेस रखने वाला कोई व्यक्ति ऐसा फ़र्मवेयर नहीं बना सकता जिसकी वजह से StrongBox से सीक्रेट लीक हो जाएं, सुरक्षा से जुड़ी ज़रूरी शर्तों को दरकिनार किया जा सके या लोगों के संवेदनशील डेटा का ऐक्सेस मिल जाए. IAR को लागू करने का सबसे सही तरीका यह है कि फ़र्मवेयर अपडेट की अनुमति सिर्फ़ तब दी जाए, जब IAuthSecret HAL के ज़रिए मुख्य उपयोगकर्ता का पासवर्ड दिया गया हो.

9.12. डेटा हटाना

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

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

9.13. सुरक्षित बूट मोड

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

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

• [SR] सुरक्षित बूट मोड लागू करने का सुझाव दिया जाता है.

अगर डिवाइस में सेफ़ बूट मोड लागू किया जाता है, तो:

• [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().

10. सॉफ़्टवेयर कंपैटिबिलिटी टेस्टिंग

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

10.1. Compatibility Test Suite

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

• [C-0-1] डिवाइस पर शिपिंग के लिए उपलब्ध फ़ाइनल सॉफ़्टवेयर का इस्तेमाल करके, Android Open Source Project से उपलब्ध Android Compatibility Test Suite (CTS) को पास करना ज़रूरी है.

• [C-0-2] यह पक्का करना ज़रूरी है कि सीटीएस में अस्पष्टता होने पर, यह सुविधा काम करे. साथ ही, रेफ़रंस सोर्स कोड के कुछ हिस्सों को फिर से लागू करने पर भी यह सुविधा काम करे.

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

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

• [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] साइनिंग मैकेनिज़्म के लिए, SHA-256 का इस्तेमाल करके अपडेट को हैश करने का सुझाव दिया जाता है. साथ ही, ECDSA NIST P-256 का इस्तेमाल करके, सार्वजनिक पासकोड के ख़िलाफ़ हैश की पुष्टि करने का सुझाव दिया जाता है.

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

• [C-1-1] में, रीबूट करके ऑफ़लाइन अपडेट करने के साथ-साथ, ओटीए डाउनलोड करने की सुविधा होनी चाहिए.

Android 6.0 और उसके बाद के वर्शन के साथ लॉन्च होने वाले डिवाइसों के लिए, अपडेट करने के तरीके में यह पुष्टि करने की सुविधा होनी चाहिए कि सिस्टम इमेज, ओटीए के बाद उम्मीद के मुताबिक बाइनरी के तौर पर एक जैसी है. Android 5.1 से, अपस्ट्रीम Android Open Source Project में ब्लॉक-आधारित ओटीए लागू करने की सुविधा जोड़ी गई है. इससे यह ज़रूरी शर्त पूरी होती है.

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

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

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

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

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

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

इस रिलीज़ में, कंपैटबिलिटी डेफ़िनिशन में किए गए बदलावों की खास जानकारी के लिए:

• दस्तावेज़ में किए गए बदलावों की जानकारी

व्यक्तियों से जुड़े सेक्शन में हुए बदलावों की खास जानकारी के लिए:

1. शुरुआती जानकारी
2. डिवाइस टाइप
3. सॉफ़्टवेयर
4. ऐप्लिकेशन पैकेजिंग
5. मल्टीमीडिया
6. डेवलपर टूल और विकल्प
7. हार्डवेयर के साथ काम करने की सुविधा
8. परफ़ॉर्मेंस और पावर
9. सुरक्षा मॉडल
10. सॉफ़्टवेयर की कंपैटिबिलिटी की जांच करना
11. अपडेट किया जा सकने वाला सॉफ़्टवेयर
12. दस्तावेज़ में हुए बदलावों का लॉग
13. हमसे संपर्क करें

12.1. बदलावों का लॉग देखने से जुड़े सुझाव

बदलावों को इस तरह मार्क किया गया है:

• सीडीडी
  साथ काम करने से जुड़ी ज़रूरी शर्तों में अहम बदलाव.

• दस्तावेज़
  कॉस्मेटिक या बिल्ड से जुड़े बदलाव.

बेहतर तरीके से देखने के लिए, अपने बदलाव के लॉग वाले यूआरएल में pretty=full और no-merges यूआरएल पैरामीटर जोड़ें.

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

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