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

1. शुरुआती जानकारी

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• डिवाइस टाइप आईडी (ज़्यादा जानकारी के लिए, 2. डिवाइस टाइप)
  • C: कोर (ऐसी ज़रूरी शर्तें जो Android डिवाइस में सेट किए गए किसी भी सिस्टम पर लागू होती हैं)
  • H: Android हैंडहेल्ड डिवाइस
  • T: Android Television डिवाइस
  • A: Android Automotive को लागू करना
  • टैब: 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] इसमें कम से कम 2.5 इंच की स्क्रीन होनी चाहिए.
• [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-1] इसमें होम, हाल ही के ऐप्लिकेशन, और वापस जाने की सुविधा होनी चाहिए.
• [7.2.3/H-0-2] बैक फ़ंक्शन (KEYCODE_BACK) के सामान्य और लंबे समय तक दबाकर रखने वाले, दोनों इवेंट को फ़ोरग्राउंड ऐप्लिकेशन पर भेजना ज़रूरी है. सिस्टम को इन इवेंट का इस्तेमाल नहीं करना चाहिए.साथ ही, इन्हें Android डिवाइस के बाहर से ट्रिगर किया जा सकता है. जैसे, Android डिवाइस से कनेक्ट किया गया बाहरी हार्डवेयर कीबोर्ड.
• [7.2.4/H-0-1] इसमें टचस्क्रीन इनपुट की सुविधा होनी चाहिए.
• [7.2.4/H-SR] अगर फ़ोरग्राउंड ऐक्टिविटी, KEYCODE_MEDIA_PLAY_PAUSE या KEYCODE_HEADSETHOOK को दबाकर रखने वाले इवेंट को हैंडल नहीं करती है, तो उपयोगकर्ता की ओर से चुने गए असिस्ट ऐप्लिकेशन को लॉन्च करने का सुझाव दिया जाता है. दूसरे शब्दों में, VoiceInteractionService को लागू करने वाले ऐप्लिकेशन या ACTION_ASSIST को हैंडल करने वाली ऐक्टिविटी को लॉन्च करने का सुझाव दिया जाता है.
• [7.3.1/H-SR] 3-ऐक्सिस एक्सलरोमीटर शामिल करने का सुझाव दिया जाता है.

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

• [7.3.1/H-1-1] कम से कम 100 हर्ट्ज़ की फ़्रीक्वेंसी पर इवेंट रिपोर्ट करने की सुविधा होनी चाहिए.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [5.1.1/H-0-1] AMR-NB
• [5.1.1/H-0-2] AMR-WB
• [5.1.1/H-0-3] MPEG-4 AAC प्रोफ़ाइल (AAC LC)
• [5.1.1/H-0-4] MPEG-4 HE AAC प्रोफ़ाइल (AAC+)
• [5.1.1/H-0-5] AAC ELD (बेहतर लो डिले एएसी)

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

• [5.1.2/H-0-1] AMR-NB
• [5.1.2/H-0-2] AMR-WB

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [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-SR] MPEG-2

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

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

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

• [5.3.5.4/T-1-1] मेन प्रोफ़ाइल लेवल 4.1 के साथ, हर सेकंड में 60 फ़्रेम पर एचडी 1080 पिक्सल

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

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

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

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

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

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

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

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

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

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

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

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

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

• [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 ओपन सोर्स प्रोजेक्ट, uid_cputime कर्नेल मॉड्यूल को लागू करके इस ज़रूरी शर्त को पूरा करता है.
• [8.4/W-0-4] ऐप्लिकेशन डेवलपर के लिए, adb shell dumpsys batterystats शेल कमांड के ज़रिए, बैटरी के इस्तेमाल की जानकारी उपलब्ध कराना ज़रूरी है.
• [8.4/W] अगर किसी ऐप्लिकेशन को हार्डवेयर कॉम्पोनेंट की पावर इस्तेमाल करने का क्रेडिट नहीं दिया जा सकता, तो हार्डवेयर कॉम्पोनेंट को ही क्रेडिट दिया जाना चाहिए.

2.5. ऑटोमोटिव से जुड़ी ज़रूरी शर्तें

Android Automotive implementation का मतलब है कि वाहन की हेड यूनिट, 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.1/A-SR] 3-ऐक्सिस एक्सलरोमीटर शामिल करने का सुझाव दिया जाता है.

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

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

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

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

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

• [7.3.11/A-0-1] मौजूदा गियर को SENSOR_TYPE_GEAR के तौर पर उपलब्ध कराना ज़रूरी है.

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

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

• स्क्रीन की रोशनी को अपने-आप घटाने-बढ़ाने वाला सेंसर, फ़ोटोमीटर के जैसा हो सकता है.

• [7.3.11.4/A-0-1] SENSOR_TYPE_CAR_SPEED में बताई गई गाड़ी की स्पीड की जानकारी देना ज़रूरी है.

• [7.3.11.5/A-0-1] SENSOR_TYPE_PARKING_BRAKE में बताए गए तरीके के मुताबिक, पार्किंग ब्रेक की स्थिति की जानकारी देना ज़रूरी है.

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

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

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

• [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 या इससे ज़्यादा
  • बड़ी स्क्रीन पर 400 डीपीआई या इससे ज़्यादा
  • ज़्यादा बड़ी स्क्रीन पर 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 या इससे ज़्यादा
  • बड़ी स्क्रीन पर 400 डीपीआई या इससे ज़्यादा
  • ज़्यादा बड़ी स्क्रीन पर 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 Profile (AAC+)
• [5.1/A-0-3] AAC ELD (बेहतर लो डिले एएसी)

Automotive डिवाइस में सेट किए गए सिस्टम में, यहां दी गई वीडियो एन्कोडिंग का इस्तेमाल किया जाना चाहिए:

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

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

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

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

• [5.3/A-SR] 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.4.1/A-0-1] android.webkit.Webview एपीआई को पूरी तरह से लागू करना ज़रूरी है.

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

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

• [3.13/A-SR] इनमें क्विक सेटिंग यूज़र इंटरफ़ेस (यूआई) कॉम्पोनेंट को शामिल करने का सुझाव दिया जाता है.

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

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

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

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

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

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

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

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

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

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

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

• [9.5/A-1-1] इसमें एक गेस्ट खाता शामिल होना चाहिए. इससे उपयोगकर्ता को लॉग इन किए बिना, वाहन के सिस्टम की सभी सुविधाओं का इस्तेमाल करने की अनुमति मिलती है.

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

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

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

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

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

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

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

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

2.4.1. हार्डवेयर

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

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

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

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

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

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

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

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

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

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

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] तीसरे पक्ष के ऐप्लिकेशन को छिपे हुए एपीआई का इस्तेमाल करने से रोकना ज़रूरी है. छिपे हुए एपीआई, android नेमस्पेस में मौजूद ऐसे एपीआई होते हैं जिन्हें @hidden एनोटेशन के साथ डेकोरेट किया जाता है, लेकिन @SystemAPI या @TestApi के साथ नहीं. इनके बारे में एसडीके के दस्तावेज़ों में बताया गया है. साथ ही, इन्हें उन सभी छिपे हुए एपीआई के साथ शिप किया जाता है जो AOSP में एपीआई लेवल की सही ब्रांच के लिए, prebuilts/runtime/appcompat/ पाथ में मौजूद प्रोविज़नल लिस्ट और डेनायल लिस्ट फ़ाइलों के ज़रिए उपलब्ध कराई गई पाबंदियों वाली सूचियों में शामिल हैं. हालांकि, ये:

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

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

पैरामीटर	जानकारी
VERSION.RELEASE	Android सिस्टम के मौजूदा वर्शन की जानकारी, जिसे कोई भी व्यक्ति आसानी से पढ़ सकता है. इस फ़ील्ड में, 9 में दी गई स्ट्रिंग वैल्यू में से कोई एक वैल्यू होनी चाहिए.
VERSION.SDK	यह Android सिस्टम के उस वर्शन की जानकारी देता है जो फ़िलहाल चल रहा है. यह जानकारी, तीसरे पक्ष के ऐप्लिकेशन कोड के लिए उपलब्ध होती है. Android 9 के लिए, इस फ़ील्ड में पूर्णांक वैल्यू 9_INT होनी चाहिए.
VERSION.SDK_INT	यह Android सिस्टम के उस वर्शन की जानकारी देता है जो फ़िलहाल चल रहा है. यह जानकारी, तीसरे पक्ष के ऐप्लिकेशन कोड के लिए उपलब्ध होती है. Android 9 के लिए, इस फ़ील्ड में पूर्णांक वैल्यू 9_INT होनी चाहिए.
VERSION.INCREMENTAL	यह वैल्यू, डिवाइस बनाने वाली कंपनी चुनती है. इससे, फ़िलहाल चल रहे Android सिस्टम के खास बिल्ड के बारे में पता चलता है. यह वैल्यू, इंसानों के पढ़ने लायक फ़ॉर्मैट में होती है. इस वैल्यू का दोबारा इस्तेमाल, असली उपयोगकर्ताओं के लिए उपलब्ध कराई गई अलग-अलग बिल्ड के लिए नहीं किया जाना चाहिए. इस फ़ील्ड का इस्तेमाल आम तौर पर यह बताने के लिए किया जाता है कि बिल्ड जनरेट करने के लिए, किस बिल्ड नंबर या सोर्स-कंट्रोल चेंज आइडेंटिफ़ायर का इस्तेमाल किया गया था. इस फ़ील्ड के लिए, किसी खास फ़ॉर्मैट की ज़रूरत नहीं है. हालांकि, यह ज़रूरी है कि यह फ़ील्ड शून्य या खाली स्ट्रिंग ("") न हो.
बोर्ड	डिवाइस को लागू करने वाले व्यक्ति या कंपनी की चुनी गई वैल्यू, जिससे डिवाइस में इस्तेमाल किए गए इंटरनल हार्डवेयर की पहचान होती है. यह वैल्यू, इंसानों के पढ़ने लायक फ़ॉर्मैट में होती है. इस फ़ील्ड का इस्तेमाल, डिवाइस को पावर देने वाले बोर्ड के खास वर्शन के बारे में बताने के लिए किया जा सकता है. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर कोड में बदला जा सकता है. साथ ही, यह रेगुलर एक्सप्रेशन “^[a-zA-Z0-9_-]+$” से मेल खानी चाहिए.
ब्रैंड	यह वैल्यू, डिवाइस से जुड़े ब्रैंड के नाम को दिखाती है. यह नाम, असली उपयोगकर्ताओं को दिखता है. यह ऐसा फ़ॉर्मैट होना चाहिए जिसे आसानी से पढ़ा जा सके. साथ ही, इससे डिवाइस के मैन्युफ़ैक्चरर या उस कंपनी के ब्रैंड का पता चलना चाहिए जिसके नाम पर डिवाइस की मार्केटिंग की जाती है. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर कोड में बदला जा सकता है. साथ ही, यह रेगुलर एक्सप्रेशन “^[a-zA-Z0-9_-]+$” से मेल खानी चाहिए.
SUPPORTED_ABIS	नेटिव कोड के निर्देश सेट (सीपीयू टाइप + एबीआई कन्वेंशन) का नाम. सेक्शन 3.3 देखें. Native API Compatibility.
SUPPORTED_32_BIT_ABIS	नेटिव कोड के निर्देश सेट (सीपीयू टाइप + एबीआई कन्वेंशन) का नाम. सेक्शन 3.3 देखें. Native API Compatibility.
SUPPORTED_64_BIT_ABIS	नेटिव कोड के दूसरे इंस्ट्रक्शन सेट (सीपीयू टाइप + एबीआई कन्वेंशन) का नाम. सेक्शन 3.3 देखें. Native API Compatibility.
CPU_ABI	नेटिव कोड के निर्देश सेट (सीपीयू टाइप + एबीआई कन्वेंशन) का नाम. सेक्शन 3.3 देखें. Native API Compatibility.
CPU_ABI2	नेटिव कोड के दूसरे इंस्ट्रक्शन सेट (सीपीयू टाइप + एबीआई कन्वेंशन) का नाम. सेक्शन 3.3 देखें. Native API Compatibility.
डिवाइस	यह वैल्यू, डिवाइस को लागू करने वाले व्यक्ति या कंपनी ने चुनी होती है. इसमें डेवलपमेंट का नाम या कोड नेम होता है. इससे डिवाइस के हार्डवेयर की सुविधाओं और इंडस्ट्रियल डिज़ाइन के कॉन्फ़िगरेशन की पहचान होती है. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर कोड में बदला जाना चाहिए. साथ ही, यह रेगुलर एक्सप्रेशन “^[a-zA-Z0-9_-]+$” से मेल खानी चाहिए. प्रॉडक्ट के जीवनकाल के दौरान, डिवाइस का यह नाम नहीं बदलना चाहिए.
FINGERPRINT	यह एक स्ट्रिंग होती है, जो इस बिल्ड की खास तौर पर पहचान करती है. यह ऐसा होना चाहिए जिसे आसानी से पढ़ा जा सके. यह इस टेंप्लेट के मुताबिक होना चाहिए: $(BRAND)/$(PRODUCT)/     $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) उदाहरण के लिए: acme/myproduct/     mydevice:9/LMYXX/3359:userdebug/test-keys फ़िंगरप्रिंट में खाली सफ़ेद जगह वाले वर्ण शामिल नहीं होने चाहिए. अगर ऊपर दिए गए टेंप्लेट में शामिल अन्य फ़ील्ड में खाली सफ़ेद जगह वाले वर्ण हैं, तो उन्हें बिल्ड फ़िंगरप्रिंट में किसी दूसरे वर्ण से बदलना होगा. जैसे, अंडरस्कोर ("_") वर्ण. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर कोड में बदला जा सकता है.
हार्डवेयर	हार्डवेयर का नाम (कर्नेल कमांड लाइन या /proc से). यह ऐसा होना चाहिए जिसे आसानी से पढ़ा जा सके. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर कोड में बदला जा सकता है. साथ ही, यह रेगुलर एक्सप्रेशन “^[a-zA-Z0-9_-]+$” से मेल खानी चाहिए.
HOST	यह एक ऐसी स्ट्रिंग होती है जो उस होस्ट की खास तौर पर पहचान करती है जिस पर बिल्ड बनाया गया था. यह स्ट्रिंग, ऐसे फ़ॉर्मैट में होती है जिसे कोई भी व्यक्ति आसानी से पढ़ सकता है. इस फ़ील्ड के लिए, किसी खास फ़ॉर्मैट की ज़रूरत नहीं है. हालांकि, यह ज़रूरी है कि यह फ़ील्ड शून्य या खाली स्ट्रिंग ("") न हो.
ID	यह एक आइडेंटिफ़ायर है. इसे डिवाइस बनाने वाली कंपनी चुनती है. इसका इस्तेमाल किसी खास रिलीज़ को रेफ़र करने के लिए किया जाता है. यह आइडेंटिफ़ायर, ऐसा फ़ॉर्मैट होता है जिसे आसानी से पढ़ा जा सकता है. यह फ़ील्ड, android.os.Build.VERSION.INCREMENTAL के जैसा हो सकता है. हालांकि, यह ऐसा होना चाहिए जिससे असली उपयोगकर्ता, सॉफ़्टवेयर बिल्ड के बीच अंतर कर सकें. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर कोड में बदला जा सकता है. साथ ही, यह रेगुलर एक्सप्रेशन “^[a-zA-Z0-9._-]+$” से मेल खानी चाहिए.
निर्माता	प्रॉडक्ट के ओरिजनल इक्विपमेंट मैन्युफ़ैक्चरर (ओईएम) का ट्रेड नेम. इस फ़ील्ड के लिए, किसी खास फ़ॉर्मैट की ज़रूरत नहीं होती. हालांकि, यह ज़रूरी है कि यह फ़ील्ड शून्य या खाली स्ट्रिंग ("") न हो. प्रॉडक्ट के लाइफ़टाइम के दौरान, इस फ़ील्ड में बदलाव नहीं किया जाना चाहिए.
MODEL	डिवाइस को लागू करने वाले व्यक्ति या कंपनी की चुनी गई वैल्यू. इसमें डिवाइस का वह नाम होता है जो उपयोगकर्ता को दिखता है. यह वही नाम होना चाहिए जिससे डिवाइस को मार्केट में लाया जाता है और असली उपयोगकर्ताओं को बेचा जाता है. इस फ़ील्ड के लिए, किसी खास फ़ॉर्मैट की ज़रूरत नहीं होती. हालांकि, यह ज़रूरी है कि यह फ़ील्ड शून्य या खाली स्ट्रिंग ("") न हो. प्रॉडक्ट के लाइफ़टाइम के दौरान, इस फ़ील्ड में बदलाव नहीं किया जाना चाहिए.
प्रॉडक्ट	डिवाइस बनाने वाली कंपनी की चुनी गई वैल्यू. इसमें किसी खास प्रॉडक्ट (एसकेयू) का डेवलपमेंट नेम या कोड नेम होता है. यह एक ही ब्रैंड के लिए यूनीक होना चाहिए. यह ऐसा होना चाहिए जिसे लोग आसानी से पढ़ सकें. हालांकि, यह ज़रूरी नहीं है कि इसे असली उपयोगकर्ता देखें. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर कोड में बदला जाना चाहिए. साथ ही, यह रेगुलर एक्सप्रेशन “^[a-zA-Z0-9_-]+$” से मेल खानी चाहिए. प्रॉडक्ट के जीवनकाल के दौरान, प्रॉडक्ट का नाम नहीं बदलना चाहिए.
सीरियल	"UNKNOWN" वैल्यू दिखाना ज़रूरी है.
टैग	डिवाइस बनाने वाली कंपनी की ओर से चुने गए टैग की कॉमा लगाकर अलग की गई सूची. इससे बिल्ड को और बेहतर तरीके से पहचाना जा सकता है. इस फ़ील्ड में, Android प्लैटफ़ॉर्म के तीन सामान्य साइनिंग कॉन्फ़िगरेशन में से किसी एक से मेल खाने वाली वैल्यू होनी चाहिए: release-keys, dev-keys, test-keys.
समय	यह वैल्यू, बिल्ड होने के समय के टाइमस्टैंप को दिखाती है.
वाई-फ़ाई के टाइप के बारे में जानकारी	डिवाइस बनाने वाली कंपनी की ओर से चुनी गई वैल्यू, जो बिल्ड के रनटाइम कॉन्फ़िगरेशन के बारे में बताती है. इस फ़ील्ड में, Android के तीन सामान्य रनटाइम कॉन्फ़िगरेशन में से किसी एक की वैल्यू होनी चाहिए: उपयोगकर्ता, उपयोगकर्ता डीबग या इंजीनियरिंग.
उपयोगकर्ता	उस उपयोगकर्ता (या अपने-आप काम करने वाले उपयोगकर्ता) का नाम या यूज़र आईडी जिसने बिल्ड जनरेट किया है. इस फ़ील्ड के लिए, किसी खास फ़ॉर्मैट की ज़रूरत नहीं है. हालांकि, यह ज़रूरी है कि यह फ़ील्ड शून्य या खाली स्ट्रिंग ("") न हो.
SECURITY_PATCH	यह वैल्यू, किसी बिल्ड के सुरक्षा पैच के लेवल के बारे में बताती है. इससे यह पता चलना चाहिए कि बिल्ड में, Android के सार्वजनिक सुरक्षा बुलेटिन में बताई गई किसी भी समस्या का कोई खतरा नहीं है. यह [YYYY-MM-DD] फ़ॉर्मैट में होना चाहिए. साथ ही, यह Android के सार्वजनिक सुरक्षा बुलेटिन या Android की सुरक्षा से जुड़ी सलाह में दिए गए स्ट्रिंग से मेल खाना चाहिए. उदाहरण के लिए, "2015-11-01".
BASE_OS	यह वैल्यू, बिल्ड के FINGERPRINT पैरामीटर को दिखाती है. यह बिल्ड, Android Public Security Bulletin में दिए गए पैच को छोड़कर, इस बिल्ड के जैसा ही होता है. इसे सही वैल्यू रिपोर्ट करनी चाहिए. अगर ऐसा कोई बिल्ड मौजूद नहीं है, तो खाली स्ट्रिंग ("") रिपोर्ट करें.
बूटलोडर	डिवाइस में सेट किए गए सिस्टम को लागू करने वाले व्यक्ति या कंपनी की चुनी गई वैल्यू. इससे डिवाइस में इस्तेमाल किए गए इंटरनल बूटलोडर के खास वर्शन की पहचान होती है. यह वैल्यू, इंसानों के पढ़ने लायक फ़ॉर्मैट में होती है. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर कोड में बदला जा सकता है. साथ ही, यह रेगुलर एक्सप्रेशन “^[a-zA-Z0-9._-]+$” से मेल खानी चाहिए.
getRadioVersion()	यह डिवाइस बनाने वाली कंपनी की चुनी गई वैल्यू होनी चाहिए. इससे डिवाइस में इस्तेमाल किए गए इंटरनल रेडियो/मॉडम के वर्शन की पहचान होती है. यह वैल्यू, इंसानों के पढ़ने लायक फ़ॉर्मैट में होनी चाहिए. अगर किसी डिवाइस में कोई इंटरनल रेडियो/मॉडेम नहीं है, तो उसे NULL वैल्यू दिखानी होगी. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर कोड में बदला जा सकता है. साथ ही, यह रेगुलर एक्सप्रेशन “^[a-zA-Z0-9._-,]+$” से मेल खानी चाहिए.
getSerial()	यह हार्डवेयर का सीरियल नंबर होना चाहिए. यह एक ही मॉडल और मैन्युफ़ैक्चरर के सभी डिवाइसों के लिए उपलब्ध और यूनीक होना चाहिए. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर कोड में बदला जा सकता है. साथ ही, यह रेगुलर एक्सप्रेशन “^[a-zA-Z0-9._-,]+$” से मेल खानी चाहिए.

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

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

Android इंटेंट की मदद से, ऐप्लिकेशन कॉम्पोनेंट, Android के अन्य कॉम्पोनेंट से फ़ंक्शन के लिए अनुरोध कर सकते हैं. Android अपस्ट्रीम प्रोजेक्ट में, 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] ऐप्लिकेशन में सेटिंग मेन्यू होना चाहिए. इससे android.provider.Telephony.ACTION_CHANGE_DEFAULT इंटेंट को कॉल किया जा सके, ताकि डिफ़ॉल्ट एसएमएस ऐप्लिकेशन बदलने के लिए डायलॉग दिखाया जा सके.

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

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

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

अगर डिवाइसों के लिए लागू की गई सुविधाओं की रिपोर्ट 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] यह ज़रूरी है कि एपीआई, प्राइमरी डिसप्ले पर चल रही गतिविधि के साथ काम करे.
• [C-1-3] ActivityOptions.setLaunchDisplayId() एपीआई के ज़रिए टारगेट डिसप्ले तय किए बिना नई गतिविधि लॉन्च करने पर, उसे उसी डिसप्ले पर लॉन्च करना होगा जिस पर उसे लॉन्च करने वाली गतिविधि चल रही थी.
• [C-1-4] Display.FLAG_PRIVATE फ़्लैग वाले डिसप्ले को हटाने पर, सभी गतिविधियों को मिटाना ज़रूरी है.
• [C-1-5] अगर डिसप्ले का साइज़ बदला जाता है, तो VirtualDisplay पर की जाने वाली सभी गतिविधियों का साइज़ भी उसी के हिसाब से बदलना चाहिए.
• जब टेक्स्ट डालने वाला फ़ील्ड, सेकंडरी डिसप्ले पर फ़ोकस करता है, तब प्राइमरी डिसप्ले पर IME (इनपुट मेथड एडिटर, यह एक ऐसा कंट्रोल होता है जिसकी मदद से उपयोगकर्ता टेक्स्ट डाल सकते हैं) दिख सकता है.
• अगर टच या बटन से इनपुट देने की सुविधा उपलब्ध है, तो सेकंडरी डिसप्ले पर इनपुट फ़ोकस को प्राइमरी डिसप्ले से अलग तौर पर लागू करना चाहिए.
• इसमें android.content.res.Configuration होना चाहिए, ताकि इसे डिसप्ले किया जा सके, यह सही तरीके से काम कर सके, और अगर किसी गतिविधि को सेकंडरी डिसप्ले पर लॉन्च किया जाता है, तो यह उसके साथ काम कर सके.

अगर डिवाइस में, सेकंडरी डिसप्ले पर सामान्य Android Activities लॉन्च करने की सुविधा है और प्राइमरी और सेकंडरी डिसप्ले में अलग-अलग android.util.DisplayMetrics हैं, तो:

• [C-2-1] एपीआई लेवल 23 या इससे पहले के लेवल को टारगेट करने वाले ऐप्लिकेशन और ऐसी गतिविधियां जिनका साइज़ नहीं बदला जा सकता (जिनमें resizeableActivity=false में AndroidManifest.xml है) को सेकंडरी डिसप्ले पर अनुमति नहीं दी जानी चाहिए.

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

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

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

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

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

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 की नेटिव ऑडियो सहायता)

  • 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 Open Source Project के अपस्ट्रीम में उपलब्ध सोर्स कोड और हेडर फ़ाइलों का इस्तेमाल करके बनाया जाना चाहिए

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

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

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

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

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

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

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

• [C-2-2] ज़रूरी है कि ये ऑपरेशन हमेशा उपलब्ध रहें. भले ही, एबीआई को 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 9 ब्रांच पर 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 Open Source Project के अपस्ट्रीम में मौजूद Chromium का वर्शन होना चाहिए.
  • डिवाइस लागू करने वाले लोग, उपयोगकर्ता एजेंट स्ट्रिंग में मोबाइल को शामिल न करें.

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

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

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

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

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

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

3.5. एपीआई के व्यवहार से जुड़ी कंपैटिबिलिटी

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

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

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

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

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

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

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

• [C-SR] उपयोगकर्ताओं को यह सुविधा देने का सुझाव दिया जाता है कि वे पाबंदी वाले ऐप्लिकेशन की सूची देख सकें.
• [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] ऊपर दिए गए नेमस्पेस में मौजूद एपीआई में, सार्वजनिक तौर पर उपलब्ध कराए गए कोई भी एलिमेंट (जैसे कि क्लास या इंटरफ़ेस या मौजूदा क्लास या इंटरफ़ेस में फ़ील्ड या तरीके) या टेस्ट या सिस्टम एपीआई नहीं जोड़े जाने चाहिए. “सार्वजनिक तौर पर उपलब्ध एलिमेंट” ऐसा कोई भी कंस्ट्रक्ट होता है जिसे अपस्ट्रीम Android सोर्स कोड में इस्तेमाल किए गए “@hide” मार्कर से नहीं सजाया गया है.

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

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

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

• [C-0-5] MUST NOT be in a namespace owned by or referring to another organization. उदाहरण के लिए, डिवाइस बनाने वाली कंपनियों को 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 के बारे में पढ़ें.

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

स्क्रीन लेआउट	स्क्रीन की सघनता	ऐप्लिकेशन के लिए कम से कम मेमोरी
Android Watch	120 डीपीआई (ldpi)	32 एमबी
	160 डीपीआई (एमडीपीआई)
	213 डीपीआई (टीवीडीपीआई)
	240 डीपीआई (hdpi)	36 एमबी
	280 डीपीआई (280dpi)
	320 dpi (xhdpi)	48MB
	360 डीपीआई (360dpi)
	400 डीपीआई (400dpi)	56 एमबी
	420 डीपीआई (420dpi)	64MB
	480 dpi (xxhdpi)	88 एमबी
	560 dpi (560dpi)	112 एमबी
	640 dpi (xxxhdpi)	154 एमबी
छोटा/सामान्य	120 डीपीआई (ldpi)	32 एमबी
	160 डीपीआई (एमडीपीआई)
	213 डीपीआई (टीवीडीपीआई)	48MB
	240 डीपीआई (hdpi)
	280 डीपीआई (280dpi)
	320 dpi (xhdpi)	80 एमबी
	360 डीपीआई (360dpi)
	400 डीपीआई (400dpi)	96 एमबी
	420 डीपीआई (420dpi)	112 एमबी
	480 dpi (xxhdpi)	128 एमबी
	560 dpi (560dpi)	192 एमबी
	640 dpi (xxxhdpi)	256 एमबी
बड़ा	120 डीपीआई (ldpi)	32 एमबी
	160 डीपीआई (एमडीपीआई)	48MB
	213 डीपीआई (टीवीडीपीआई)	80 एमबी
	240 डीपीआई (hdpi)
	280 डीपीआई (280dpi)	96 एमबी
	320 dpi (xhdpi)	128 एमबी
	360 डीपीआई (360dpi)	160 एमबी
	400 डीपीआई (400dpi)	192 एमबी
	420 डीपीआई (420dpi)	228MB
	480 dpi (xxhdpi)	256 एमबी
	560 dpi (560dpi)	384MB
	640 dpi (xxxhdpi)	512MB
xlarge	120 डीपीआई (ldpi)	48MB
	160 डीपीआई (एमडीपीआई)	80 एमबी
	213 डीपीआई (टीवीडीपीआई)	96 एमबी
	240 डीपीआई (hdpi)
	280 डीपीआई (280dpi)	144 एमबी
	320 dpi (xhdpi)	192 एमबी
	360 डीपीआई (360dpi)	240 एमबी
	400 डीपीआई (400dpi)	288MB
	420 डीपीआई (420dpi)	336MB
	480 dpi (xxhdpi)	384MB
	560 dpi (560dpi)	576 एमबी
	640 dpi (xxxhdpi)	768 एमबी

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

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

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

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

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

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

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

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

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

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

• [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] एसडीके के दस्तावेज़ में बताए गए तरीके के मुताबिक, हार्डवेयर की सुविधाओं का इस्तेमाल करने वाली सूचनाओं के लिए सहायता उपलब्ध करानी होगी. साथ ही, डिवाइस में लागू किए गए हार्डवेयर के साथ जितना हो सके उतना काम करना होगा. उदाहरण के लिए, अगर किसी डिवाइस में वाइब्रेटर शामिल है, तो उसमें वाइब्रेशन एपीआई को सही तरीके से लागू करना ज़रूरी है. अगर किसी डिवाइस में हार्डवेयर मौजूद नहीं है, तो उससे जुड़े एपीआई को नो-ऑप के तौर पर लागू करना ज़रूरी है. इस बारे में ज़्यादा जानकारी, सेक्शन 7 में दी गई है.
• [C-1-2] APIs में दिए गए या स्टेटस/सिस्टम बार आइकॉन स्टाइल गाइड में दिए गए सभी संसाधनों (आइकॉन, ऐनिमेशन फ़ाइलें वगैरह) को सही तरीके से रेंडर करना ज़रूरी है. हालांकि, ये 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] MUST implement the APIs that allow third-party applications to add suggestions to the search box when it is run in global search mode.

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

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

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

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

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

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

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

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

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

• [C-1-1] ऐप्लिकेशन के व्यवहार और Android SDK मल्टी-विंडो मोड के साथ काम करने से जुड़े दस्तावेज़ में बताए गए एपीआई के मुताबिक, मल्टी-विंडो मोड लागू करना ज़रूरी है. साथ ही, इन ज़रूरी शर्तों को पूरा करना भी ज़रूरी है:
• [C-1-2] ऐप्लिकेशन, AndroidManifest.xml फ़ाइल में यह जानकारी दे सकते हैं कि वे मल्टी-विंडो मोड में काम कर सकते हैं या नहीं. इसके लिए, वे android:resizeableActivity एट्रिब्यूट को true पर सेट कर सकते हैं. इसके अलावा, वे targetSdkVersion > 24 सेट करके भी यह जानकारी दे सकते हैं. जिन ऐप्लिकेशन ने अपने मेनिफ़ेस्ट में इस एट्रिब्यूट को false पर सेट किया है उन्हें मल्टी-विंडो मोड में लॉन्च नहीं किया जाना चाहिए. targetSdkVersion < 24 वाले पुराने ऐप्लिकेशन, जिन्होंने इस android:resizeableActivity एट्रिब्यूट को सेट नहीं किया है उन्हें मल्टी-विंडो मोड में लॉन्च किया जा सकता है. हालांकि, सिस्टम को यह चेतावनी देनी होगी कि ऐप्लिकेशन, मल्टी-विंडो मोड में उम्मीद के मुताबिक काम नहीं कर सकता.
• [C-1-3] अगर स्क्रीन की ऊंचाई और चौड़ाई, दोनों 440 डीपी से कम हैं, तो स्प्लिट-स्क्रीन या फ़्रीफ़ॉर्म मोड की सुविधा नहीं दी जानी चाहिए.
• स्क्रीन साइज़ 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] PIP विंडो के लिए, कम से कम 108 डीपी की चौड़ाई और ऊंचाई तय करनी होगी. साथ ही, जब Configuration.uiMode को UI_MODE_TYPE_TELEVISION के तौर पर कॉन्फ़िगर किया जाता है, तब PIP विंडो के लिए कम से कम 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] डिवाइस में Device Policy Client (DPC) को डिवाइस के मालिक के तौर पर इस्तेमाल होने वाले ऐप्लिकेशन के तौर पर रजिस्टर करने की सुविधा होनी चाहिए. इसके बारे में यहां बताया गया है:
  • जब डिवाइस के लिए उपयोगकर्ता का कोई डेटा कॉन्फ़िगर नहीं किया गया होता है, तो:
    • [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 वाला रिकॉर्ड शामिल करने वाला एनएफ़सी मैसेज मिलता है, तो 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 से शुरू होने वाला फ़्लो) में उपयोगकर्ताओं को मिलने वाला अनुभव, AOSP के साथ काम करने वाला होना चाहिए.

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

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

3.9.2 मैनेज की जा रही प्रोफ़ाइल की सुविधा

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

• [C-1-1] android.app.admin.DevicePolicyManager APIs के ज़रिए मैनेज की गई प्रोफ़ाइलों के साथ काम करना ज़रूरी है.
• [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] Accessibility API के एसडीके दस्तावेज़ में बताए गए तरीके के मुताबिक, Android ऐक्सेसिबिलिटी फ़्रेमवर्क को लागू करना ज़रूरी है.
• [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 Television डिवाइसों को कंट्रोल करने वाले इनपुट मॉड्यूल बनाने के लिए, एक स्टैंडर्ड एपीआई उपलब्ध कराता है.

अगर डिवाइस में 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-1] MediaItem आइकॉन और सूचना के आइकॉन में कोई बदलाव नहीं होना चाहिए.
• [C-1-2] MUST display those items as described by MediaSession, e.g., metadata, icons, imagery.
• [C-1-3] ऐप्लिकेशन का टाइटल दिखना ज़रूरी है.
• [C-1-4] MediaBrowser के क्रम को दिखाने के लिए, इसमें ड्रॉअर या कोई अन्य तरीका होना चाहिए. साथ ही, 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] इंस्टॉल किए गए ऐप्लिकेशन को डिवाइस पर मौजूद इंस्टैंट ऐप्लिकेशन के बारे में जानकारी नहीं दिखनी चाहिए. ऐसा तब तक नहीं होना चाहिए, जब तक इंस्टैंट ऐप्लिकेशन, इंस्टॉल किए गए ऐप्लिकेशन से साफ़ तौर पर कनेक्ट न हो.

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 SDK में शामिल “aapt” टूल से जनरेट की गई Android “.apk” फ़ाइलों को इंस्टॉल और चलाने की सुविधा होनी चाहिए.
• ऊपर दी गई ज़रूरी शर्तें पूरी करना मुश्किल हो सकता है. इसलिए, डिवाइस बनाने वाली कंपनियों को यह सुझाव दिया जाता है कि वे AOSP के रेफ़रंस पैकेज मैनेजमेंट सिस्टम का इस्तेमाल करें.

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

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

• [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] पीसीएम/वेव

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] एएसी ईएलडी (बेहतर लो डिले एएसी)
• [C-1-11] xHE-AAC (ISO/IEC 23003-3 Extended HE AAC Profile, which includes the USAC Baseline Profile, and 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] पीसीएम/वेव
• [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.

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 मेटाडेटा को प्राथमिकता दी जाएगी.

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

फ़ॉर्मैट/कोडेक	जानकारी	इस्तेमाल किए जा सकने वाले फ़ाइल टाइप/कंटेनर फ़ॉर्मैट
MPEG-4 AAC प्रोफ़ाइल (AAC LC)	मोनो/स्टीरियो/5.0/5.1 कॉन्टेंट के लिए, 8 से 48 किलोहर्ट्ज़ तक के स्टैंडर्ड सैंपलिंग रेट का इस्तेमाल किया जा सकता है.	3GPP (.3gp) MPEG-4 (.mp4, .m4a) ADTS रॉ एएसी (.aac, ADIF फ़ॉर्मैट काम नहीं करता) MPEG-TS (.ts, इसमें खोज नहीं की जा सकती)
MPEG-4 HE AAC प्रोफ़ाइल (AAC+)	मोनो/स्टीरियो/5.0/5.1 कॉन्टेंट के साथ काम करता है. इसमें 16 से 48 किलोहर्ट्ज़ तक के स्टैंडर्ड सैंपलिंग रेट इस्तेमाल किए जाते हैं.
MPEG-4 HE AACv2 प्रोफ़ाइल (बेहतर AAC+)	मोनो/स्टीरियो/5.0/5.1 कॉन्टेंट के साथ काम करता है. इसमें 16 से 48 किलोहर्ट्ज़ तक के स्टैंडर्ड सैंपलिंग रेट इस्तेमाल किए जाते हैं.
AAC ELD (बेहतर लो डिले AAC)	मोनो/स्टीरियो कॉन्टेंट के लिए, 16 से 48 किलोहर्ट्ज़ तक के स्टैंडर्ड सैंपलिंग रेट का इस्तेमाल किया जा सकता है.
USAC	मोनो/स्टीरियो कॉन्टेंट के लिए, 7.35 से 48 किलोहर्ट्ज़ तक के स्टैंडर्ड सैंपलिंग रेट का इस्तेमाल किया जा सकता है.	MPEG-4 (.mp4, .m4a)
AMR-NB	8 किलोहर्ट्ज़ पर सैंपल किया गया 4.75 से 12.2 केबीपीएस	3GPP (.3gp)
AMR-WB	6.60 केबिट/सेकंड से 23.85 केबिट/सेकंड तक के नौ रेट, जिन्हें 16 किलोहर्ट्ज़ पर सैंपल किया गया है
FLAC	मोनो/स्टीरियो (मल्टीचैनल नहीं). सैंपल रेट 48 किलोहर्ट्ज़ तक (हालांकि, 44.1 किलोहर्ट्ज़ आउटपुट वाले डिवाइसों पर 44.1 किलोहर्ट्ज़ का इस्तेमाल करने का सुझाव दिया जाता है, क्योंकि 48 से 44.1 किलोहर्ट्ज़ डाउनसैंपलर में लो-पास फ़िल्टर शामिल नहीं होता). 16-बिट का इस्तेमाल करने का सुझाव दिया जाता है. 24-बिट के लिए, डिथरिंग लागू नहीं की जाती.	सिर्फ़ FLAC (.flac)
MP3	मोनो/स्टीरियो 8-320 केबीपीएस स्थिर (सीबीआर) या वैरिएबल बिटरेट (वीबीआर)	MP3 (.mp3)
MIDI	एमआईडीआई टाइप 0 और 1. DLS के वर्शन 1 और 2. XMF और Mobile XMF. रिंगटोन के फ़ॉर्मैट RTTTL/RTX, OTA, और iMelody के साथ काम करता है	टाइप 0 और 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) ओटीए (.ota) iMelody (.imy)
Vorbis		Ogg (.ogg) Matroska (.mkv, Android 4.0+)
PCM/WAVE	16-बिट लीनियर पीसीएम (हार्डवेयर की सीमा तक की दरें). डिवाइसों पर, रॉ पीसीएम रिकॉर्डिंग के लिए सैंपलिंग रेट की सुविधा होनी चाहिए. यह सुविधा 8000, 11025, 16000, और 44100 हर्ट्ज़ फ़्रीक्वेंसी पर काम करनी चाहिए.	WAVE (.wav)
Opus		Matroska (.mkv), Ogg(.ogg)

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

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

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

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

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)

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

फ़ॉर्मैट/कोडेक	जानकारी	इस्तेमाल किए जा सकने वाले फ़ाइल टाइप/कंटेनर फ़ॉर्मैट
JPEG	बेस+प्रोग्रेसिव	JPEG (.jpg)
GIF		GIF (.gif)
PNG		PNG (.png)
BMP		BMP (.bmp)
WebP		WebP (.webp)
Raw		ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw)
HEIF	इमेज, इमेज का कलेक्शन, इमेज का क्रम	HEIF (.heif), HEIC (.heic)

5.1.7. वीडियो कोडेक

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

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

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

• [C-1-2] वीडियो एन्कोडर और डिकोडर में, YUV420 फ़्लेक्सिबल कलर फ़ॉर्मैट (COLOR_FormatYUV420Flexible) काम करना चाहिए.

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

• [C-2-1] एचडीआर स्टैटिक मेटाडेटा पार्स करने और उसे मैनेज करने की सुविधा होनी चाहिए.

अगर डिवाइस में लागू किए गए सिस्टम, MediaCodecInfo.CodecCapabilities क्लास में FEATURE_IntraRefresh के ज़रिए इंट्रा रीफ़्रेश की सुविधा का विज्ञापन दिखाते हैं, तो:

• [C-3-1] ज़रूरी है कि यह 10 से 60 फ़्रेम की रेंज में रीफ़्रेश होने की अवधि के साथ काम करे. साथ ही, कॉन्फ़िगर की गई रीफ़्रेश होने की अवधि के 20% के अंदर सटीक तरीके से काम करे.

5.1.8. वीडियो कोडेक की सूची

फ़ॉर्मैट/कोडेक	जानकारी	इस्तेमाल किए जा सकने वाले फ़ाइल टाइप/ कंटेनर फ़ॉर्मैट
H.263		3GPP (.3gp) MPEG-4 (.mp4)
H.264 एवीसी	ज़्यादा जानकारी के लिए, सेक्शन 5.2 और 5.3 देखें	3GPP (.3gp) MPEG-4 (.mp4) MPEG-2 टीएस (.ts, सिर्फ़ AAC ऑडियो, इसमें खोज करने की सुविधा नहीं है, Android 3.0+)
H.265 HEVC	ज़्यादा जानकारी के लिए, सेक्शन 5.3 देखें	MPEG-4 (.mp4)
MPEG-2	मुख्य प्रोफ़ाइल	MPEG2-TS
MPEG-4 SP		3GPP (.3gp)
VP8	ज़्यादा जानकारी के लिए, सेक्शन 5.2 और 5.3 देखें	WebM (.webm) Matroska (.mkv)
VP9	ज़्यादा जानकारी के लिए, सेक्शन 5.3 देखें	WebM (.webm) Matroska (.mkv)

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 वीडियो एन्कोडर काम करता है और यह तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध है, तो:

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

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

	एसडी (खराब क्वालिटी)	एसडी (अच्छी क्वालिटी)	एचडी 720 पिक्सल	एचडी 1080 पिक्सल
वीडियो रिज़ॉल्यूशन	320 x 240 पिक्सल	720 x 480 पिक्सल	1280 x 720 पिक्सल	1920 x 1080 पिक्सल
वीडियो फ़्रेम रेट	20 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड
वीडियो बिटरेट	384 केबीपीएस	2 एमबीपीएस	4 एमबीपीएस	10 एमबीपीएस

5.2.3. VP8

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

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

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

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

	एसडी (खराब क्वालिटी)	एसडी (अच्छी क्वालिटी)	एचडी 720 पिक्सल	एचडी 1080 पिक्सल
वीडियो रिज़ॉल्यूशन	320 x 180 पिक्सल	640 x 360 पिक्सल	1280 x 720 पिक्सल	1920 x 1080 पिक्सल
वीडियो फ़्रेम रेट	30 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड
वीडियो बिटरेट	800 केबीपीएस	2 एमबीपीएस	4 एमबीपीएस	10 एमबीपीएस

5.2.4. VP9

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

• Matroska WebM फ़ाइलें लिखने की सुविधा होनी चाहिए.

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

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

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

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

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

5.3.1. MPEG-2

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

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

5.3.2. H.263

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

• [C-1-1] Baseline Profile Level 30 और 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 और Baseline Profile के साथ काम करना ज़रूरी है. एएसओ (आर्बिट्ररी स्लाइस ऑर्डरिंग), एफ़एमओ (फ़्लेक्सिबल मैक्रोब्लॉक ऑर्डरिंग), और आरएस (रेडंडेंट स्लाइस) के लिए सहायता पाना ज़रूरी नहीं है.
• [C-1-2] में, नीचे दी गई टेबल में बताई गई एसडी (स्टैंडर्ड डेफ़िनिशन) प्रोफ़ाइलों वाले वीडियो को डिकोड करने की सुविधा होनी चाहिए. साथ ही, ये वीडियो बेसलाइन प्रोफ़ाइल और मेन प्रोफ़ाइल लेवल 3.1 (इसमें 720p30 भी शामिल है) के साथ एन्कोड किए गए हों.
• इसमें एचडी (हाई डेफ़िनिशन) प्रोफ़ाइल वाले वीडियो डिकोड करने की सुविधा होनी चाहिए. इसके बारे में यहां दी गई टेबल में बताया गया है.

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

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

	एसडी (खराब क्वालिटी)	एसडी (अच्छी क्वालिटी)	एचडी 720 पिक्सल	एचडी 1080 पिक्सल
वीडियो रिज़ॉल्यूशन	320 x 240 पिक्सल	720 x 480 पिक्सल	1280 x 720 पिक्सल	1920 x 1080 पिक्सल
वीडियो फ़्रेम रेट	30 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड	60 एफ़पीएस	30 फ़्रेम प्रति सेकंड (60 फ़्रेम प्रति सेकंडटेलीविज़न)
वीडियो बिटरेट	800 केबीपीएस	2 एमबीपीएस	8 एमबीपीएस	20 एमबीपीएस

5.3.5. H.265 (HEVC)

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

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

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

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

	एसडी (खराब क्वालिटी)	एसडी (अच्छी क्वालिटी)	एचडी 720 पिक्सल	एचडी 1080 पिक्सल	यूएचडी
वीडियो रिज़ॉल्यूशन	352 x 288 पिक्सल	720 x 480 पिक्सल	1280 x 720 पिक्सल	1920 x 1080 पिक्सल	3840 x 2160 पिक्सल
वीडियो फ़्रेम रेट	30 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड	30/60 एफ़पीएस (60 एफ़पीएसH.265 हार्डवेयर डिकोडिंग की सुविधा वाला टेलीविज़न)	60 एफ़पीएस
वीडियो बिटरेट	600 केबीपीएस	1.6 एमबीपीएस	4 एमबीपीएस	5 एमबीपीएस	20 एमबीपीएस

5.3.6. VP8

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

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

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

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

	एसडी (खराब क्वालिटी)	एसडी (अच्छी क्वालिटी)	एचडी 720 पिक्सल	एचडी 1080 पिक्सल
वीडियो रिज़ॉल्यूशन	320 x 180 पिक्सल	640 x 360 पिक्सल	1280 x 720 पिक्सल	1920 x 1080 पिक्सल
वीडियो फ़्रेम रेट	30 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड (60 फ़्रेम प्रति सेकंडटेलीविज़न)	30 (60 फ़्रेम प्रति सेकंडटेलीविज़न)
वीडियो बिटरेट	800 केबीपीएस	2 एमबीपीएस	8 एमबीपीएस	20 एमबीपीएस

5.3.7. VP9

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

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

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

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

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

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

	एसडी (खराब क्वालिटी)	एसडी (अच्छी क्वालिटी)	एचडी 720 पिक्सल	एचडी 1080 पिक्सल	यूएचडी
वीडियो रिज़ॉल्यूशन	320 x 180 पिक्सल	640 x 360 पिक्सल	1280 x 720 पिक्सल	1920 x 1080 पिक्सल	3840 x 2160 पिक्सल
वीडियो फ़्रेम रेट	30 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड	30 एफ़पीएस (60 एफ़पीएसVP9 हार्डवेयर डिकोडिंग की सुविधा वाला टेलीविज़न)	60 एफ़पीएस
वीडियो बिटरेट	600 केबीपीएस	1.6 एमबीपीएस	4 एमबीपीएस	5 एमबीपीएस	20 एमबीपीएस

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

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

5.4.1. Raw Audio Capture

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

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

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

• [C-1-2] ज़रूरी है कि वह अप-सैंपलिंग के बिना, ऊपर दिए गए सैंपल रेट पर कैप्चर करे.

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

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

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

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

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

अगर डिवाइसों में, आवाज़ पहचानने के लिए तैयार की गई 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.5. ऑडियो प्लेबैक

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

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

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

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

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

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

  • सैंपलिंग रेट: 24000, 48000

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 के ज़रिए कंट्रोल किया जा सकता है.

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

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

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

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

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

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

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

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

• [C-SR] कोल्ड आउटपुट की लेटेन्सी 100 मिलीसेकंड या इससे कम हो
• [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-1-1] ज़रूरी है कि कम समय में ऑडियो ट्रांसफ़र करने की सुविधा के बारे में जानकारी न दी जाए.

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

• [C-SR] कोल्ड इनपुट लेटेन्सी 100 मिलीसेकंड या इससे कम हो.
• [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 टेबल में दिए गए, RTP ऑडियो वीडियो प्रोफ़ाइल और उससे जुड़े कोडेक के साथ काम करना चाहिए. अपवादों के लिए, कृपया सेक्शन 5.1 में टेबल के फ़ुटनोट देखें.

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

सेगमेंट के फ़ॉर्मैट	रेफ़रंस	कोडेक के साथ काम करने की सुविधा
MPEG-2 ट्रांसपोर्ट स्ट्रीम	ISO 13818	वीडियो कोडेक: H264 एवीसी MPEG-4 SP MPEG-2 H264 AVC, MPEG2-4 SP, और MPEG-2 के बारे में ज़्यादा जानने के लिए, सेक्शन 5.1.3 देखें. ऑडियो कोडेक: AAC AAC और इसके वैरिएंट के बारे में ज़्यादा जानने के लिए, सेक्शन 5.1.1 देखें.
ADTS फ़्रेमिंग और ID3 टैग के साथ AAC	ISO 13818-7	एएसी और इसके वैरिएंट के बारे में जानकारी के लिए, सेक्शन 5.1.1 देखें
WebVTT	WebVTT

RTSP (RTP, SDP)

प्रोफ़ाइल नाम	रेफ़रंस	कोडेक के साथ काम करने की सुविधा
H264 एवीसी	RFC 6184	H264 AVC के बारे में ज़्यादा जानने के लिए, सेक्शन 5.1.3 देखें
MP4A-LATM	RFC 6416	एएसी और इसके वैरिएंट के बारे में जानकारी के लिए, सेक्शन 5.1.1 देखें
H263-1998	RFC 3551 RFC 4629 RFC 2190	H263 के बारे में ज़्यादा जानकारी के लिए, सेक्शन 5.1.3 देखें
H263-2000	RFC 4629	H263 के बारे में ज़्यादा जानकारी के लिए, सेक्शन 5.1.3 देखें
एएमआर	RFC 4867	एएमआर-एनबी के बारे में ज़्यादा जानकारी के लिए, सेक्शन 5.1.1 देखें
AMR-WB	RFC 4867	AMR-WB के बारे में जानकारी के लिए, सेक्शन 5.1.1 देखें
MP4V-ES	RFC 6416	MPEG-4 SP के बारे में ज़्यादा जानकारी के लिए, सेक्शन 5.1.3 देखें
mpeg4-generic	RFC 3640	एएसी और इसके वैरिएंट के बारे में जानकारी के लिए, सेक्शन 5.1.1 देखें
MP2T	RFC 2250	ज़्यादा जानकारी के लिए, एचटीटीपी लाइव स्ट्रीमिंग के नीचे मौजूद MPEG-2 ट्रांसपोर्ट स्ट्रीम देखें

5.8. Secure Media

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

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

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

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

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

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

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

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

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

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

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

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] ऑडियो चालू होने और सीपीयू लोड में बदलाव होने पर, सीपीयू की परफ़ॉर्मेंस का एक जैसा लेवल बनाए रखने का सुझाव दिया जाता है. इसकी जांच, SimpleSynth कमिट 1bd6391 का इस्तेमाल करके की जानी चाहिए. SimpleSynth ऐप्लिकेशन को नीचे दिए गए पैरामीटर के साथ चलाना होगा. साथ ही, 10 मिनट के बाद इसमें कोई भी अंडररन नहीं होना चाहिए:
  • काम के घंटे: 2,00,000
  • वैरिएबल लोड: चालू है. इससे हर दो सेकंड में, वर्क साइकल की वैल्यू 100% और 10% के बीच स्विच होगी. इसे सीपीयू गवर्नर के व्यवहार की जांच करने के लिए डिज़ाइन किया गया है
  • स्टेबलाइज़ किया गया लोड: बंद है
• ऑडियो क्लॉक में होने वाली गड़बड़ी और स्टैंडर्ड टाइम के हिसाब से उसमें होने वाले बदलाव को कम करना चाहिए.
• जब दोनों चालू हों, तो सीपीयू CLOCK_MONOTONIC के मुकाबले ऑडियो क्लॉक ड्रिफ्ट को कम करना चाहिए.
• डिवाइस पर मौजूद ट्रांसड्यूसर के ज़रिए ऑडियो ट्रांसफ़र करने में कम से कम समय लगना चाहिए.
• यूएसबी डिजिटल ऑडियो पर ऑडियो लेटेंसी को कम करना चाहिए.
• सभी पाथ पर ऑडियो लेटेंसी मेज़रमेंट की जानकारी देने वाला दस्तावेज़ होना चाहिए.
• ऑडियो बफ़र पूरा होने पर कॉलबैक एंट्री के समय में जिटर को कम करना चाहिए. इससे कॉलबैक के ज़रिए इस्तेमाल किए जा सकने वाले सीपीयू बैंडविथ के प्रतिशत पर असर पड़ता है.
• सामान्य इस्तेमाल के दौरान, रिपोर्ट की गई लेटेन्सी पर, ऑडियो अंडररन (आउटपुट) या ओवररन (इनपुट) नहीं होना चाहिए.
• SHOULD provide zero inter-channel latency difference.
• सभी ट्रांसपोर्ट पर एमआईडीआई की औसत लेटेन्सी को कम करना चाहिए.
• सभी ट्रांसपोर्ट पर, लोड (जिटर) के दौरान एमआईडीआई के रिस्पॉन्स में लगने वाले समय में होने वाले बदलाव को कम से कम करना चाहिए.
• सभी ट्रांसपोर्ट पर, एमआईडीआई के सटीक टाइमस्टैंप देने चाहिए.
• डिवाइस पर मौजूद ट्रांसड्यूसर से आने वाले ऑडियो सिग्नल में, कम से कम नॉइज़ होनी चाहिए. इसमें कोल्ड स्टार्ट के तुरंत बाद की अवधि भी शामिल है.
• जब दोनों एंड-पॉइंट चालू हों, तब इनपुट और आउटपुट के बीच ऑडियो क्लॉक का अंतर शून्य होना चाहिए. इससे जुड़े एंड-पॉइंट के उदाहरणों में, डिवाइस पर मौजूद माइक्रोफ़ोन और स्पीकर या ऑडियो जैक इनपुट और आउटपुट शामिल हैं.
• जब इनपुट और आउटपुट, दोनों चालू हों, तब इसे एक ही थ्रेड पर, संबंधित एंड-पॉइंट के इनपुट और आउटपुट, दोनों के लिए ऑडियो बफ़र पूरा होने के कॉलबैक को हैंडल करना चाहिए. साथ ही, इनपुट कॉलबैक से वापस आने के तुरंत बाद, आउटपुट कॉलबैक में शामिल होना चाहिए. अगर एक ही थ्रेड पर कॉल बैक को मैनेज करना मुमकिन नहीं है, तो इनपुट कॉल बैक डालने के कुछ समय बाद आउटपुट कॉल बैक डालें. इससे ऐप्लिकेशन को इनपुट और आउटपुट, दोनों के लिए एक जैसा समय तय करने की अनुमति मिलती है.
• इनपुट और आउटपुट के लिए, HAL ऑडियो बफ़रिंग के बीच फ़ेज़ के अंतर को कम से कम करना चाहिए.
• स्क्रीन को छूने पर होने वाली देरी को कम करना चाहिए.
• लोड होने के दौरान, टच के इंतज़ार के समय में होने वाले बदलाव (जिटर) को कम से कम करना चाहिए.
• टच इनपुट से ऑडियो आउटपुट तक की लेटेन्सी 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-4-1] कम से कम एक कॉन्फ़िगरेशन में, स्टीरियो और आठ चैनलों में 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 डीबी, बिना प्रोसेस किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन के लिए, मिड-फ़्रीक्वेंसी रेंज की तुलना में.

• [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-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 Debug Bridge को चालू करता है, तब डीडीएमएस की सुविधा चालू होनी चाहिए.
• Monkey
  • [C-0-8] इसमें Monkey फ़्रेमवर्क शामिल होना चाहिए. साथ ही, इसे ऐप्लिकेशन के इस्तेमाल के लिए उपलब्ध कराना ज़रूरी है.
• SysTrace
  • [C-0-9] यह ज़रूरी है कि डिवाइस, Android SDK में दिए गए दस्तावेज़ के मुताबिक, systrace टूल के साथ काम करे. Systrace डिफ़ॉल्ट रूप से बंद होना चाहिए. साथ ही, Systrace को चालू करने के लिए, उपयोगकर्ता के लिए उपलब्ध एक तरीका होना चाहिए.

अगर डिवाइस में सेट किए गए सिस्टम, 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] एपीआई के तरीकों को, क्लास के no-op इंप्लीमेंटेशन (ऐसे इंप्लीमेंटेशन जिनमें कोई कार्रवाई नहीं की जाती) दिखाने चाहिए. ऐसा तब करना चाहिए, जब SDK टूल के दस्तावेज़ में शून्य वैल्यू की अनुमति न हो.
• [C-0-6] एपीआई के तरीकों से ऐसी गड़बड़ियां नहीं होनी चाहिए जिनके बारे में एसडीके के दस्तावेज़ में नहीं बताया गया है.
• [C-0-7] डिवाइसों में सेट किए गए सिस्टम के लिए, एक ही बिल्ड फ़िंगरप्रिंट के लिए, android.content.pm.PackageManager क्लास में getSystemAvailableFeatures() और hasSystemFeature(String) तरीकों का इस्तेमाल करके, हार्डवेयर कॉन्फ़िगरेशन की सटीक जानकारी लगातार रिपोर्ट करना ज़रूरी है.

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

7.1. डिसप्ले और ग्राफ़िक्स

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 dp x 320 dp होना चाहिए.
  • 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> एट्रिब्यूट के ज़रिए, ऐप्लिकेशन के लिए स्क्रीन साइज़ के बारे में बताई गई जानकारी का सही तरीके से पालन करना ज़रूरी है.

• स्क्रीन के कोने गोल हो सकते हैं.

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

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

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

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

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

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

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

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

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

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

  • 120 डीपीआई (ldpi)
  • 160 डीपीआई (एमडीपीआई)
  • 213 डीपीआई (टीवीडीपीआई)
  • 240 डीपीआई (hdpi)
  • 260 डीपीआई (260dpi)
  • 280 डीपीआई (280dpi)
  • 300 डीपीआई (300dpi)
  • 320 dpi (xhdpi)
  • 340 डीपीआई (340dpi)
  • 360 डीपीआई (360dpi)
  • 400 डीपीआई (400dpi)
  • 420 डीपीआई (420dpi)
  • 480 dpi (xxhdpi)
  • 560 dpi (560dpi)
  • 640 dpi (xxxhdpi)

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

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

• [C-1-1] डिसप्ले साइज़ को, नेटिव डेंसिटी के 1.5 गुना से ज़्यादा नहीं बढ़ाया जाना चाहिए. इसके अलावा, स्क्रीन के डाइमेंशन को 320dp (संसाधन क्वालिफ़ायर sw320dp के बराबर) से कम नहीं किया जाना चाहिए. इनमें से जो भी पहले हो उसे लागू किया जाना चाहिए.
• [C-1-2] डिसप्ले साइज़ को नेटिव डेनसिटी के 0.85 गुना से कम नहीं किया जाना चाहिए.
• बेहतर इस्तेमाल और फ़ॉन्ट के साइज़ में एकरूपता बनाए रखने के लिए, हमारा सुझाव है कि नेटिव डिसप्ले के विकल्पों को ऊपर दी गई सीमाओं के मुताबिक, इस तरह से स्केल किया जाए
• छोटा: 0.85x
• डिफ़ॉल्ट: 1x (नेटिव डिसप्ले स्केल)
• बड़ा: 1.15x
• ज़्यादा हिस्से में दिखाएं: 1.3x
• सबसे बड़ा 1.45x

7.1.2. डिसप्ले मेट्रिक

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

• [C-1-1] android.util.DisplayMetrics एपीआई में तय की गई सभी डिसप्ले मेट्रिक के लिए, सही वैल्यू रिपोर्ट करनी होंगी.

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

• [C-2-1] android.util.DisplayMetrics API में तय की गई सभी डिसप्ले मेट्रिक के लिए, इम्यूलेट किए गए डिफ़ॉल्ट view.Display के लिए सही वैल्यू रिपोर्ट करनी होंगी.

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

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

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

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

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

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

7.1.4.1 OpenGL ES

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

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

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

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

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

• [C-3-1] libGLESv2.so लाइब्रेरी में OpenGL ES 2.0 के फ़ंक्शन सिंबल के साथ-साथ, इन वर्शन के लिए भी फ़ंक्शन सिंबल एक्सपोर्ट करने होंगे.

अगर डिवाइस में 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] MUST enumerate layers, contained in native libraries named as libVkLayer*.so in the application package’s native library directory, through the Vulkan native APIs vkEnumerateInstanceLayerProperties() and 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 एक्सटेंशन के साथ काम करना ज़रूरी है.

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

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

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

• [C-3-1] SYNC_FD बाहरी सेमाफ़ोर और हैंडल टाइप के लिए, सहायता उपलब्ध कराना ज़रूरी है.
• [SR] 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_KHR_gl_colorspace_display_p3 एक्सटेंशन के लिए सहायता उपलब्ध कराने का विज्ञापन देना ज़रूरी है.
• [SR] GL_EXT_sRGB का इस्तेमाल करने का सुझाव दिया जाता है.

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

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

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

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

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

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

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

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

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

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-3-1] यह पक्का करना होगा कि targetSdkVersion की वैल्यू 10 से कम होने पर, ऐप्लिकेशन के लिए मेन्यू फ़ंक्शन उपलब्ध हो. इसके लिए, वे फ़िज़िकल बटन, सॉफ़्टवेयर कुंजी या जेस्चर का इस्तेमाल कर सकते हैं. यह मेन्यू फ़ंक्शन तब तक ऐक्सेस किया जा सकता है, जब तक इसे अन्य नेविगेशन फ़ंक्शन के साथ न छिपाया गया हो.

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

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

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

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

बटन	एचआईडी डिवाइस का इस्तेमाल2	Android बटन
A1	0x09 0x0001	KEYCODE_BUTTON_A (96)
B1	0x09 0x0002	KEYCODE_BUTTON_B (97)
X1	0x09 0x0004	KEYCODE_BUTTON_X (99)
Y1	0x09 0x0005	KEYCODE_BUTTON_Y (100)
डी-पैड ऊपर की ओर1 डी-पैड नीचे की ओर1	0x01 0x00393	AXIS_HAT_Y4
डी-पैड बाईं ओर1 डी-पैड दाईं ओर1	0x01 0x00393	AXIS_HAT_X4
लेफ़्ट शोल्डर बटन1	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
राइट शोल्डर बटन1	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
लेफ़्ट स्टिक क्लिक करें1	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
राइट स्टिक क्लिक करें1	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
Home1	0x0c 0x0223	KEYCODE_HOME (3)
वापस जाएं1	0x0c 0x0224	KEYCODE_BACK (4)

1 KeyEvent

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

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

4 MotionEvent

ऐनलॉग कंट्रोल1	एचआईडी का इस्तेमाल	Android बटन
लेफ़्ट ट्रिगर	0x02 0x00C5	AXIS_LTRIGGER
राइट ट्रिगर	0x02 0x00C4	AXIS_RTRIGGER
लेफ़्ट जॉयस्टिक	0x01 0x0030 0x01 0x0031	AXIS_X AXIS_Y
राइट जॉयस्टिक	0x01 0x0032 0x01 0x0035	AXIS_Z AXIS_RZ

1 MotionEvent

7.2.7. रिमोट कंट्रोल

डिवाइस के हिसाब से ज़रूरी शर्तों के बारे में जानने के लिए, सेक्शन 2.3.1 देखें.

7.3. सेंसर

अगर डिवाइस में किसी खास तरह का सेंसर शामिल है और तीसरे पक्ष के डेवलपर के लिए उससे जुड़ा एपीआई उपलब्ध है, तो डिवाइस में उस एपीआई को लागू करना ज़रूरी है. इसे Android SDK के दस्तावेज़ और सेंसर के बारे में Android Open Source के दस्तावेज़ में बताया गया है.

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

• [C-0-1] android.content.pm.PackageManager क्लास के हिसाब से, सेंसर के मौजूद होने या न होने की सटीक जानकारी देना ज़रूरी है.
• [C-0-2] SensorManager.getSensorList() और इसी तरह के अन्य तरीकों से, काम करने वाले सेंसर की सही सूची दिखाना ज़रूरी है.
• [C-0-3] सभी अन्य सेंसर एपीआई के लिए, डिवाइस को सही तरीके से काम करना चाहिए. उदाहरण के लिए, जब ऐप्लिकेशन लिसनर रजिस्टर करने की कोशिश करें, तो ज़रूरत के हिसाब से true या false वैल्यू दिखाना. साथ ही, जब संबंधित सेंसर मौजूद न हों, तो सेंसर लिसनर को कॉल न करना वगैरह.

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

• [C-1-1] Android SDK के दस्तावेज़ में बताए गए हर सेंसर टाइप के लिए, इकाइयों की अंतरराष्ट्रीय प्रणाली (मेट्रिक) की वैल्यू का इस्तेमाल करके, सेंसर से जुड़ी सभी मेज़रमेंट रिपोर्ट करना ज़रूरी है.
• [C-1-2] जब ऐप्लिकेशन प्रोसेसर चालू हो, तब सेंसर के डेटा को 100 मिलीसेकंड + 2 * sample_time की ज़्यादा से ज़्यादा लेटेन्सी के साथ रिपोर्ट करना ज़रूरी है. ऐसा तब करना होगा, जब सेंसर को कम से कम 5 मिलीसेकंड + 2 * sample_time की लेटेन्सी के साथ स्ट्रीम किया गया हो. इस देरी में, फ़िल्टर करने में लगने वाला समय शामिल नहीं है.
• [C-1-3] सेंसर के चालू होने के 400 मिलीसेकंड + 2 * sample_time के अंदर, सेंसर के पहले सैंपल की जानकारी देना ज़रूरी है. इस सैंपल के लिए, सटीक होने की दर 0 हो सकती है.

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

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

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

• कई सेंसर चालू होने पर, बिजली की खपत, हर सेंसर की बताई गई बिजली की खपत के योग से ज़्यादा नहीं होनी चाहिए.

ऊपर दी गई सूची पूरी नहीं है. Android SDK और Android Open Source Documentations में सेंसर के बारे में दी गई जानकारी को आधिकारिक माना जाएगा.

कुछ सेंसर कंपोज़िट होते हैं. इसका मतलब है कि उन्हें एक या एक से ज़्यादा अन्य सेंसर से मिले डेटा से बनाया जा सकता है. (उदाहरण के लिए, ओरिएंटेशन सेंसर और लीनियर ऐक्सलरेशन सेंसर.)

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

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

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

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

7.3.1. एक्सलरोमीटर

• डिवाइस में 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 SDK के दस्तावेज़ में बताए गए तरीके के मुताबिक, TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER कंपोज़िट सेंसर लागू करने चाहिए.
• कम से कम 200 हर्ट्ज़ तक के इवेंट रिपोर्ट करने चाहिए.
• इसका रिज़ॉल्यूशन कम से कम 16-बिट होना चाहिए.
• डिवाइस के इस्तेमाल के दौरान, इसे कैलिब्रेट किया जाना चाहिए. ऐसा तब किया जाना चाहिए, जब डिवाइस के लाइफ़साइकल के दौरान इसकी विशेषताओं में बदलाव होता है. साथ ही, डिवाइस को रीबूट करने के दौरान, कंपनसेशन पैरामीटर को सुरक्षित रखना चाहिए.
• तापमान के हिसाब से सही होना चाहिए.
• TYPE_ACCELEROMETER_UNCALIBRATED सेंसर को भी लागू करना चाहिए.

अगर डिवाइस में 3-ऐक्सिस एक्सलरोमीटर और TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER में से कोई भी कंपोज़िट सेंसर लागू किया गया है, तो:

• [C-2-1] इनकी बिजली की खपत का कुल योग हमेशा 4 मिलीवॉट से कम होना चाहिए.
• डिवाइस के डाइनैमिक या स्टैटिक मोड में होने पर, दोनों की वैल्यू 2 mW और 0.5 mW से कम होनी चाहिए.

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

• [C-3-1] TYPE_GRAVITY और TYPE_LINEAR_ACCELERATION कंपोज़िट सेंसर को लागू करना ज़रूरी है.
• TYPE_GAME_ROTATION_VECTOR कंपोज़िट सेंसर का होना चाहिए.
• [SR] मौजूदा और नए Android डिवाइसों में TYPE_GAME_ROTATION_VECTOR सेंसर को लागू करने का सुझाव दिया जाता है.

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

• [C-4-1] TYPE_ROTATION_VECTOR कंपोज़िट सेंसर का होना ज़रूरी है.

7.3.2. मैग्नेटोमीटर

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

• [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. जीपीएस

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

• इसमें जीपीएस/जीएनएसएस रिसीवर शामिल होना चाहिए.

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

• [C-1-1] LocationManager#requestLocationUpdate के ज़रिए अनुरोध किए जाने पर, जगह की जानकारी के आउटपुट के साथ, कम से कम 1 हर्ट्ज़ की दर से काम करना चाहिए.
• [C-1-2] खुले आसमान वाली जगहों (मज़बूत सिग्नल, न के बराबर मल्टीपाथ, HDOP < 2) में, 0.5 एमबीपीएस या इससे ज़्यादा डेटा स्पीड वाले इंटरनेट कनेक्शन से कनेक्ट होने पर, 10 सेकंड के अंदर जगह की जानकारी का पता लगाना ज़रूरी है (पहली बार जगह की जानकारी का पता लगाने में कम समय लगना). आम तौर पर, इस ज़रूरत को पूरा करने के लिए, किसी तरह की असिस्टेड या अनुमानित जीपीएस/जीएनएसएस तकनीक का इस्तेमाल किया जाता है. इससे जीपीएस/जीएनएसएस लॉक-ऑन टाइम को कम किया जा सकता है. सहायता डेटा में रेफ़रंस टाइम, रेफ़रंस लोकेशन, और सैटेलाइट एफ़ेमेरिस/क्लॉक शामिल होती है.
  • [C-1-6] जगह की जानकारी का पता लगाने के बाद, डिवाइसों को खुले आसमान वाली जगहों में पांच सेकंड के अंदर, जगह की जानकारी का पता लगाना ज़रूरी है. यह जानकारी, पिछली बार जगह की जानकारी मिलने के एक घंटे बाद तक की होगी. भले ही, यह अनुरोध डेटा कनेक्शन के बिना और/or डिवाइस बंद करके फिर चालू करने के बाद भेजा गया हो.

• जगह की जानकारी का पता लगाने के बाद, खुले आसमान वाली जगहों में, जब वाहन रुका हो या उसका ऐक्सलरेशन एक मीटर प्रति सेकंड स्क्वेयर्ड से कम हो, तब:

  • [C-1-3] कम से कम 95% समय में, 20 मीटर के दायरे तक जगह की जानकारी का पता लगाना और 0.5 मीटर प्रति सेकंड की स्पीड का पता लगाना ज़रूरी है.
  • [C-1-4] एक ही कॉन्स्टलेशन के कम से कम आठ सैटलाइट को एक साथ ट्रैक करना और GnssStatus.Callback के ज़रिए उनकी जानकारी देना ज़रूरी है.
  • अलग-अलग कॉन्स्टलेशन के कम से कम 24 सैटलाइट एक साथ ट्रैक करने चाहिए. जैसे, जीपीएस और Glonass, Beidou, Galileo में से कोई एक.
  • [C-1-5] टेस्ट एपीआई ‘getGnssYearOfHardware’ के ज़रिए, जीएनएसएस टेक्नोलॉजी जनरेशन की जानकारी देना ज़रूरी है.
  • [एसआर] आपातकालीन फ़ोन कॉल के दौरान, सामान्य जीपीएस/जीएनएसएस की जगह की जानकारी देना जारी रखें.
  • [एसआर] एसबीएएस को अपवाद मानकर, ट्रैक किए गए सभी कॉन्स्टलेशन (इनके बारे में GnssStatus मैसेज में बताया गया है) से जीएनएसएस के मेज़रमेंट की जानकारी दें.
  • [SR] एजीसी और जीएनएसएस मेज़रमेंट की फ़्रीक्वेंसी की रिपोर्ट करें.
  • [SR] हर जीपीएस/जीएनएसएस की जगह की जानकारी के हिस्से के तौर पर, सभी सटीक अनुमानों के बारे में बताएं. इनमें बियरिंग, स्पीड, और वर्टिकल शामिल हैं.
  • [SR] हमारा सुझाव है कि टेस्ट एपीआई LocationManager.getGnssYearOfHardware() के ज़रिए साल "2016" या "2017" की रिपोर्ट करने वाले डिवाइसों के लिए, अतिरिक्त ज़रूरी शर्तों को पूरा किया जाए.

अगर डिवाइसों में जीपीएस/जीएनएसएस रिसीवर शामिल हैं और वे android.hardware.location.gps फ़ीचर फ़्लैग के ज़रिए ऐप्लिकेशन को इस सुविधा के बारे में जानकारी देते हैं, साथ ही LocationManager.getGnssYearOfHardware() Test API "2016" या उसके बाद का साल दिखाता है, तो:

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

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

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

अगर डिवाइसों में जीपीएस/जीएनएसएस रिसीवर शामिल हैं और वे android.hardware.location.gps फ़ीचर फ़्लैग के ज़रिए ऐप्लिकेशन को इस सुविधा के बारे में जानकारी देते हैं, साथ ही LocationManager.getGnssYearOfHardware() Test API "2018" या उसके बाद के साल की जानकारी देता है, तो:

• [C-4-1] मोबाइल स्टेशन पर आधारित (एमएस-आधारित) नेटवर्क से शुरू की गई आपातकालीन सेशन कॉल के दौरान, ऐप्लिकेशन को सामान्य जीपीएस/जीएनएसएस आउटपुट देना जारी रखना ज़रूरी है.
• [C-4-2] GNSS Location Provider API को पोज़िशन और मेज़रमेंट की जानकारी देना ज़रूरी है.

7.3.4. जाइरोस्कोप

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

• इसमें जाइरोस्कोप (ऐंगुलर चेंज सेंसर) शामिल होना चाहिए.
• इसमें जाइरोस्कोप सेंसर शामिल नहीं होना चाहिए, जब तक कि 3-ऐक्सिस एक्सलरोमीटर भी शामिल न हो.

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

• [C-1-1] कम से कम 50 हर्ट्ज़ की फ़्रीक्वेंसी तक इवेंट रिपोर्ट करने की सुविधा होनी चाहिए.
• [C-1-2] TYPE_GYROSCOPE सेंसर को लागू करना ज़रूरी है. साथ ही, TYPE_GYROSCOPE_UNCALIBRATED सेंसर को भी लागू करना चाहिए.
• [C-1-3] में, ओरिएंटेशन में होने वाले बदलावों को हर सेकंड में 1,000 डिग्री तक मेज़र करने की सुविधा होनी चाहिए.
• [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] मौजूदा और नए Android डिवाइसों में SENSOR_TYPE_GYROSCOPE_UNCALIBRATED सेंसर को लागू करने का सुझाव दिया जाता है.
• [SR] यह सुझाव दिया जाता है कि जब डिवाइस कमरे के तापमान पर स्थिर हो, तब कैलिब्रेशन की गड़बड़ी 0.01 रेडियन/सेकंड से कम होनी चाहिए.
• कम से कम 200 हर्ट्ज़ तक के इवेंट रिपोर्ट करने चाहिए.

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

• [C-2-1] TYPE_ROTATION_VECTOR कंपोज़िट सेंसर का होना ज़रूरी है.

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

• [C-3-1] TYPE_GRAVITY और TYPE_LINEAR_ACCELERATION कंपोज़िट सेंसर को लागू करना ज़रूरी है.
• [SR] मौजूदा और नए Android डिवाइसों में TYPE_GAME_ROTATION_VECTOR सेंसर को लागू करने का सुझाव दिया जाता है.
• TYPE_GAME_ROTATION_VECTOR कंपोज़िट सेंसर का होना चाहिए.

7.3.5. बैरोमीटर

• डिवाइस में बैरोमीटर (आस-पास की हवा के दबाव को मापने वाला सेंसर) शामिल होना चाहिए.

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

• [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] किसी और तरह के तापमान को नहीं मापना चाहिए.

ध्यान दें कि 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_UNCALIBRATED होना चाहिए. इसकी क्वालिटी से जुड़ी शर्तें, TYPE_ACCELEROMETER के जैसी ही होनी चाहिए.

• [C-2-3] डिवाइस में TYPE_GYROSCOPE सेंसर होना ज़रूरी है. यह सेंसर:

  • मेज़रमेंट की रेंज कम से कम -1000 और +1000 dps के बीच होनी चाहिए.
  • इसका मेज़रमेंट रिज़ॉल्यूशन कम से कम 16 एलएसबी/डीपीएस होना चाहिए.
  • मेज़रमेंट की फ़्रीक्वेंसी कम से कम 12.5 हर्ट्ज़ या इससे कम होनी चाहिए.
  • मेज़रमेंट की फ़्रीक्वेंसी ज़्यादा से ज़्यादा 400 हर्ट्ज़ या इससे ज़्यादा होनी चाहिए; इसमें SensorDirectChannel RATE_VERY_FAST काम करना चाहिए.
  • मेज़रमेंट नॉइज़ 0.014°/s/√Hz से ज़्यादा नहीं होना चाहिए.
  • [C-SR] में, नाइक्विस्ट फ़्रीक्वेंसी के कम से कम 80% के 3dB मेज़रमेंट बैंडविड्थ और इस बैंडविड्थ में व्हाइट नॉइज़ स्पेक्ट्रम का होना ज़रूरी है.
  • कमरे के तापमान पर जांच करने पर, रेट रैंडम वॉक 0.001 °/s √Hz से कम होना चाहिए.
  • तापमान के हिसाब से, बायस में बदलाव ≤ +/- 0.05 °/ s / °C होना चाहिए.
  • तापमान में ≤ 0.02% / °C के हिसाब से बदलाव होने पर, संवेदनशीलता में बदलाव होना चाहिए.
  • इसमें सबसे सही फ़िट वाली लाइन की नॉन-लीनियरिटी ≤ 0.2% होनी चाहिए.
  • इसमें नॉइज़ डेंसिटी ≤ 0.007 °/s/√Hz होनी चाहिए.
  • डिवाइस के स्थिर होने पर, तापमान 10 ~ 40 ℃ के बीच कैलिब्रेशन की गड़बड़ी 0.002 रेडियन/सेकंड से कम होनी चाहिए.
  • इसमें 0.1°/s/g से कम की 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 सेंसर होना ज़रूरी है. यह सेंसर:
  • इस सेंसर के नॉन-वेक-अप फ़ॉर्म को लागू करना ज़रूरी है. साथ ही, इसमें कम से कम 300 सेंसर इवेंट को बफ़र करने की सुविधा होनी चाहिए.
  • बैटरी की खपत 4 mW से ज़्यादा नहीं होनी चाहिए.
• [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. बायोमेट्रिक सेंसर

7.3.10.1. फ़िंगरप्रिंट सेंसर

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

• इसमें फ़िंगरप्रिंट सेंसर शामिल होना चाहिए.

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

• [C-1-1] यह ज़रूरी है कि android.hardware.fingerprint सुविधा के साथ काम करने का एलान किया गया हो.
• [C-1-2] Android SDK के दस्तावेज़ में बताए गए तरीके से, एपीआई को पूरी तरह से लागू करना ज़रूरी है.
• [C-1-3] में, गलत तरीके से स्वीकार किए जाने की दर 0.002% से ज़्यादा नहीं होनी चाहिए.
• [SR] हमारा सुझाव है कि स्पूफ़ और इंपोस्टर के तौर पर पहचान किए गए लोगों के कॉल स्वीकार किए जाने की दर 7% से ज़्यादा नहीं होनी चाहिए.
• [C-1-4] अगर स्पूफ़िंग और धोखाधड़ी के मामलों में, पहचान स्वीकार किए जाने की दर 7% से ज़्यादा है, तो यह जानकारी देना ज़रूरी है कि यह मोड, किसी मुश्किल पिन, पैटर्न या पासवर्ड के मुकाबले कम सुरक्षित हो सकता है. साथ ही, इसे चालू करने से जुड़े जोखिमों के बारे में साफ़ तौर पर बताना ज़रूरी है.
• [C-1-5] फ़िंगरप्रिंट की पुष्टि करने के लिए, पांच बार गलत तरीके से कोशिश करने के बाद, कम से कम 30 सेकंड तक कोशिशों को सीमित करना ज़रूरी है.
• [C-1-6] में हार्डवेयर की मदद से कीस्टोर लागू करने की सुविधा होनी चाहिए. साथ ही, फ़िंगरप्रिंट मैचिंग की प्रोसेस, ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट (टीईई) में या टीईई के साथ सुरक्षित चैनल वाली चिप पर होनी चाहिए.
• [C-1-7] पहचान ज़ाहिर करने वाले सभी फ़िंगरप्रिंट डेटा को एन्क्रिप्ट (सुरक्षित) किया जाना चाहिए. साथ ही, क्रिप्टोग्राफ़िक तरीके से पुष्टि की जानी चाहिए, ताकि टीईई या टीईई के साथ सुरक्षित चैनल वाले चिप के बाहर, उन्हें हासिल न किया जा सके, पढ़ा न जा सके या बदला न जा सके. इसके बारे में, Android Open Source Project की साइट पर लागू करने के दिशा-निर्देशों में बताया गया है.
• [C-1-8] फ़िंगरप्रिंट जोड़ने से पहले, भरोसे की चेन बनाना ज़रूरी है. इसके लिए, उपयोगकर्ता को मौजूदा डिवाइस क्रेडेंशियल की पुष्टि करनी होगी या नया डिवाइस क्रेडेंशियल (पिन/पैटर्न/पासवर्ड) जोड़ना होगा, जिसे टीईई से सुरक्षित किया गया हो. Android Open Source Project के लागू करने से, फ़्रेमवर्क में ऐसा करने का तरीका मिलता है.
• [C-1-9] यह ज़रूरी है कि तीसरे पक्ष के ऐप्लिकेशन को, अलग-अलग फ़िंगरप्रिंट के बीच अंतर करने की अनुमति न दी जाए.
• [C-1-10] DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT फ़्लैग का पालन करना ज़रूरी है.
• [C-1-11] Android 6.0 से पहले के वर्शन से अपग्रेड करने पर, फ़िंगरप्रिंट के डेटा को सुरक्षित तरीके से माइग्रेट किया जाना चाहिए, ताकि ऊपर दी गई ज़रूरी शर्तों को पूरा किया जा सके. अगर ऐसा नहीं किया जाता है, तो डेटा को हटा दिया जाना चाहिए.
• [C-1-12] जब किसी उपयोगकर्ता का खाता हटाया जाता है, तो उसके फ़िंगरप्रिंट का ऐसा सारा डेटा पूरी तरह से मिटा दिया जाना चाहिए जिससे उसकी पहचान की जा सकती हो. खाता फ़ैक्ट्री रीसेट करके भी हटाया जा सकता है.
• [C-1-13] ऐप्लिकेशन प्रोसेसर को, पहचान किए जा सकने वाले फ़िंगरप्रिंट डेटा या उससे मिले किसी भी डेटा (जैसे कि एम्बेडिंग) को बिना एन्क्रिप्ट (सुरक्षित) किए ऐक्सेस करने की अनुमति नहीं देनी चाहिए.
• [SR] डिवाइस पर मेज़र किए गए फ़ॉल्स रिजेक्शन रेट के लिए, यह सुझाव दिया जाता है कि यह 10% से कम होना चाहिए.
• [SR] एक उंगली के लिए, फ़िंगरप्रिंट सेंसर को छूने से लेकर स्क्रीन अनलॉक होने तक, एक सेकंड से कम समय लगने का सुझाव दिया जाता है.
• Android ओपन सोर्स प्रोजेक्ट में दिए गए Android फ़िंगरप्रिंट आइकॉन का इस्तेमाल करना चाहिए.

7.3.10.2. अन्य बायोमेट्रिक सेंसर

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

• [C-1-1] ज़रूरी है कि फ़ॉल्स एक्सेप्टेंस रेट 0.002% से ज़्यादा न हो.
• [C-SR] यह सुझाव दिया जाता है कि स्पूफ़ और इंपोस्टर के तौर पर स्वीकार किए जाने की दर 7% से ज़्यादा न हो.
• [C-1-2] अगर स्पूफ़िंग और धोखाधड़ी करने वाले लोगों के कॉल स्वीकार किए जाने की दर 7% से ज़्यादा है, तो यह जानकारी देना ज़रूरी है कि यह मोड, किसी मुश्किल पिन, पैटर्न या पासवर्ड के मुकाबले कम सुरक्षित हो सकता है. साथ ही, इसे चालू करने से होने वाले जोखिमों के बारे में साफ़ तौर पर बताना ज़रूरी है.
• [C-1-3] बायोमेट्रिक पुष्टि के लिए पांच बार गलत तरीके से कोशिश करने के बाद, कम से कम 30 सेकंड तक कोशिशों को सीमित करना ज़रूरी है. गलत तरीके से कोशिश करने का मतलब है कि कैप्चर की गई क्वालिटी (ACQUIRED_GOOD) अच्छी है, लेकिन वह रजिस्टर किए गए बायोमेट्रिक से मेल नहीं खाती
• [C-1-4] इसमें हार्डवेयर की मदद से काम करने वाले कीस्टोर को लागू करना ज़रूरी है. साथ ही, टीईई या टीईई के साथ सुरक्षित चैनल वाली चिप में बायोमेट्रिक मैचिंग की सुविधा होनी चाहिए.
• [C-1-5] में, पहचान ज़ाहिर करने वाले सभी डेटा को एन्क्रिप्ट (सुरक्षित) किया जाना चाहिए. साथ ही, क्रिप्टोग्राफ़िक तरीके से पुष्टि की जानी चाहिए, ताकि टीईई या टीईई के साथ सुरक्षित चैनल वाले चिप के बाहर, डेटा को हासिल, पढ़ा या बदला न जा सके. इसके बारे में, Android Open Source Project की साइट पर लागू करने के दिशा-निर्देशों में बताया गया है.
• [C-1-6] नई बायोमेट्रिक जानकारी जोड़ने से पहले, भरोसे की चेन बनाना ज़रूरी है. इसके लिए, उपयोगकर्ता को मौजूदा डिवाइस क्रेडेंशियल (पिन/पैटर्न/पासवर्ड) की पुष्टि करनी होगी या नया डिवाइस क्रेडेंशियल जोड़ना होगा. यह क्रेडेंशियल, टीईई से सुरक्षित होना चाहिए. Android Open Source Project के तहत लागू किए गए फ़्रेमवर्क में, ऐसा करने का तरीका बताया गया है.
• [C-1-7] तीसरे पक्ष के ऐप्लिकेशन को, बायोमेट्रिक डेटा के आधार पर किए गए रजिस्ट्रेशन के बीच अंतर करने की अनुमति नहीं देनी चाहिए.
• [C-1-8] उस बायोमेट्रिक के लिए, अलग-अलग फ़्लैग (जैसे: DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE या DevicePolicymanager.KEYGUARD_DISABLE_IRIS) का पालन करना ज़रूरी है.
• [C-1-9] जब किसी उपयोगकर्ता का खाता हटा दिया जाता है, तब डिवाइस को उपयोगकर्ता की पहचान करने वाले सभी बायोमेट्रिक डेटा को पूरी तरह से हटाना होगा. इसमें फ़ैक्ट्री रीसेट के ज़रिए हटाया गया डेटा भी शामिल है.
• [C-1-10] टीईई के बाहर, ऐप्लिकेशन प्रोसेसर को पहचान किए जा सकने वाले बायोमेट्रिक डेटा या उससे मिले किसी भी डेटा (जैसे कि एम्बेडिंग) को बिना एन्क्रिप्ट (सुरक्षित) किए ऐक्सेस करने की अनुमति नहीं देनी चाहिए.
• [C-SR] डिवाइस पर मेज़र किए गए फ़िंगरप्रिंट के हिसाब से, फ़िंगरप्रिंट के अस्वीकार होने की दर 10% से कम होनी चाहिए. ऐसा करने का सुझाव दिया जाता है.
• [C-SR] यह सुझाव दिया जाता है कि बायोमेट्रिक ऑथेंटिकेशन की प्रोसेस में एक सेकंड से कम समय लगना चाहिए. यह समय, बायोमेट्रिक का पता चलने से लेकर स्क्रीन अनलॉक होने तक का होता है. यह समय, रजिस्टर किए गए हर बायोमेट्रिक के लिए होना चाहिए.

7.3.11. सिर्फ़ Android Automotive के लिए सेंसर

ऑटोमोटिव से जुड़े सेंसर के बारे में android.car.CarSensorManager API में बताया गया है.

7.3.11.1. मौजूदा गियर

डिवाइस से जुड़ी ज़रूरी शर्तों के लिए, सेक्शन 2.5.1 देखें.

7.3.11.2. दिन रात मोड

डिवाइस से जुड़ी ज़रूरी शर्तों के लिए, सेक्शन 2.5.1 देखें.

7.3.11.3. ड्राइविंग स्टेटस

इस ज़रूरी शर्त को हटा दिया गया है.

7.3.11.4. पहिए की रफ़्तार

डिवाइस से जुड़ी ज़रूरी शर्तों के लिए, सेक्शन 2.5.1 देखें.

7.3.11.5. पार्किंग ब्रेक

डिवाइस से जुड़ी ज़रूरी शर्तों के लिए, सेक्शन 2.5.1 देखें.

7.3.12. पोज़ सेंसर

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

• इसमें 6 डिग्री ऑफ़ फ़्रीडम वाले पोज़ सेंसर की सुविधा हो सकती है.

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

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-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 Television डिवाइसों में, स्टैंडबाय पावर स्टेट में होने पर भी ऐसा होता है.
• [C-1-5] WifiManager.enableNetwork() एपीआई के तरीके को कॉल करने को, Network को स्विच करने के लिए ज़रूरी शर्त के तौर पर नहीं माना जाना चाहिए. Network का इस्तेमाल, ऐप्लिकेशन के ट्रैफ़िक के लिए डिफ़ॉल्ट रूप से किया जाता है. साथ ही, इसे ConnectivityManager एपीआई के तरीके से वापस लाया जाता है. जैसे, getActiveNetwork और registerDefaultNetworkCallback. दूसरे शब्दों में कहें, तो वे सिर्फ़ तब इंटरनेट ऐक्सेस बंद कर सकते हैं, जब वे यह पुष्टि कर लें कि वाई-फ़ाई नेटवर्क से इंटरनेट ऐक्सेस किया जा रहा है. ऐसा तब किया जा सकता है, जब इंटरनेट सेवा देने वाली कोई अन्य कंपनी (जैसे कि मोबाइल डेटा) इंटरनेट ऐक्सेस दे रही हो.
• [C-SR] ConnectivityManager.reportNetworkConnectivity() एपीआई तरीके को कॉल करने पर, Network पर इंटरनेट ऐक्सेस का फिर से आकलन करने का सुझाव दिया जाता है. साथ ही, आकलन से यह पता चलने पर कि मौजूदा Network अब इंटरनेट ऐक्सेस नहीं देता है, तो इंटरनेट ऐक्सेस देने वाले किसी अन्य उपलब्ध नेटवर्क (जैसे, मोबाइल डेटा) पर स्विच करने का सुझाव दिया जाता है.
• [C-SR] जब एसटीए डिसकनेक्ट हो, तब हर स्कैन की शुरुआत में प्रोब रिक्वेस्ट के एमएसी पते और क्रम संख्या को बदलना ज़रूरी है.
  • एक स्कैन के दौरान भेजे गए प्रोब रिक्वेस्ट फ़्रेम के हर ग्रुप को एक ही एमएसी पते का इस्तेमाल करना चाहिए. स्कैन के बीच में एमएसी पता नहीं बदलना चाहिए.
  • प्रोब रिक्वेस्ट फ़्रेम की क्रम संख्या, स्कैन के दौरान सामान्य रूप से क्रम में बढ़ती रहनी चाहिए.
  • किसी स्कैन की आखिरी प्रोब रिक्वेस्ट और अगले स्कैन की पहली प्रोब रिक्वेस्ट के बीच में क्रम संख्या को बदलते रहना चाहिए.
• [C-SR] STA के डिसकनेक्ट होने पर, प्रोब अनुरोध फ़्रेम में सिर्फ़ इन एलिमेंट को शामिल करने का सुझाव दिया जाता है:
  • SSID पैरामीटर सेट (0)
  • DS पैरामीटर सेट (3)

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

• [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 टनल वाले डायरेक्ट लिंक सेटअप (टीडीएलएस) की सुविधा शामिल होनी चाहिए.

अगर डिवाइस में TDLS की सुविधा काम करती है और WiFiManager API के ज़रिए TDLS चालू किया गया है, तो:

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

7.4.2.3. Wi-Fi Aware

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

• इसमें Wi-Fi Aware की सुविधा होनी चाहिए.

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

• [C-1-1] एसडीके के दस्तावेज़ में बताए गए तरीके के मुताबिक, WifiAwareManager एपीआई लागू करना ज़रूरी है.
• [C-1-2] android.hardware.wifi.aware फ़ीचर फ़्लैग के बारे में एलान करना ज़रूरी है.
• [C-1-3] यह ज़रूरी है कि डिवाइस, वाई-फ़ाई और वाई-फ़ाई अवेयर की सुविधाओं को एक साथ इस्तेमाल करने की अनुमति देता हो.
• [C-1-4] यह ज़रूरी है कि वाई-फ़ाई अवेयर मैनेजमेंट इंटरफ़ेस का पता, हर 30 मिनट में बदला जाए. साथ ही, जब भी वाई-फ़ाई अवेयर की सुविधा चालू हो, तब भी ऐसा किया जाए.

अगर डिवाइसों में, सेक्शन 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. वाई-फ़ाई पासपॉइंट

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

• इसमें वाई-फ़ाई पासपॉइंट की सुविधा होनी चाहिए.

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

• [C-1-1] एसडीके के दस्तावेज़ में बताए गए तरीके के मुताबिक, Passpoint से जुड़े WifiManager एपीआई लागू करना ज़रूरी है.
• [C-1-2] डिवाइस में IEEE 802.11u स्टैंडर्ड का इस्तेमाल किया जाना चाहिए. यह स्टैंडर्ड, खास तौर पर नेटवर्क डिस्कवरी और नेटवर्क चुनने से जुड़ा है. जैसे, जेनेरिक एडवर्टाइज़मेंट सर्विस (जीएएस) और ऐक्सेस नेटवर्क क्वेरी प्रोटोकॉल (एएनक्यूपी).

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

• [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.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 मिनट से ज़्यादा का टाइमआउट लागू न करें. साथ ही, टाइमआउट के दौरान पते को रोटेट करें.

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

• [C-4-1] उपयोगकर्ता को सिस्टम एपीआई BluetoothAdapter.isBleScanAlwaysAvailable() के ज़रिए पढ़ी गई वैल्यू को चालू/बंद करने की सुविधा देनी होगी.

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

  • ISO 18092
  • LLCP 1.2 (NFC फ़ोरम के हिसाब से तय किया गया)
  • SDP 1.0 (NFC फ़ोरम के मुताबिक)
  • एनडीईएफ़ पुश प्रोटोकॉल
  • SNEP 1.0 (NFC फ़ोरम के मुताबिक)
• [C-1-4] इसमें Android बीम की सुविधा होनी चाहिए. साथ ही, Android बीम की सुविधा डिफ़ॉल्ट रूप से चालू होनी चाहिए.
• [C-1-5] Android Beam चालू होने या NFC P2p मोड चालू होने पर, Android Beam का इस्तेमाल करके डेटा भेजा और पाया जा सकता हो.
• [C-1-6] SNEP डिफ़ॉल्ट सर्वर को लागू करना ज़रूरी है. डिफ़ॉल्ट एसएनईपी सर्वर को मिले मान्य एनडीईएफ़ मैसेज, android.nfc.ACTION_NDEF_DISCOVERED इंटेंट का इस्तेमाल करके ऐप्लिकेशन को भेजे जाने चाहिए. सेटिंग में जाकर Android Beam की सुविधा बंद करने पर, आने वाले NDEF मैसेज को भेजने की सुविधा बंद नहीं होनी चाहिए.
• [C-1-7] एनएफ़सी शेयर करने की सेटिंग दिखाने के लिए, android.settings.NFCSHARING_SETTINGS के इंटेंट का पालन करना ज़रूरी है.
• [C-1-8] एनपीपी सर्वर को लागू करना ज़रूरी है. एनपीपी सर्वर को मिले मैसेज को उसी तरह से प्रोसेस किया जाना चाहिए जिस तरह से एसएनईपी के डिफ़ॉल्ट सर्वर को मिले मैसेज को प्रोसेस किया जाता है.
• [C-1-9] Android Beam चालू होने पर, SNEP क्लाइंट को लागू करना होगा. साथ ही, डिफ़ॉल्ट SNEP सर्वर को आउटबाउंड P2P NDEF भेजने की कोशिश करनी होगी. अगर कोई डिफ़ॉल्ट एसएनईपी सर्वर नहीं मिलता है, तो क्लाइंट को एनपीपी सर्वर को डेटा भेजने की कोशिश करनी चाहिए.
• [C-1-10] MUST allow foreground activities to set the outbound P2P NDEF message using android.nfc.NfcAdapter.setNdefPushMessage, and android.nfc.NfcAdapter.setNdefPushMessageCallback, and android.nfc.NfcAdapter.enableForegroundNdefPush.
• उसे आउटबाउंड पी2पी एनडीईएफ़ मैसेज भेजने से पहले, 'बीम करने के लिए छुएं' जैसे जेस्चर या स्क्रीन पर पुष्टि करने की सुविधा का इस्तेमाल करना चाहिए.
• [C-1-11] अगर डिवाइस पर ब्लूटूथ ऑब्जेक्ट पुश प्रोफ़ाइल काम करती है, तो उसमें एनएफ़सी कनेक्शन को ब्लूटूथ पर ट्रांसफ़र करने की सुविधा होनी चाहिए.
• [C-1-12] android.nfc.NfcAdapter.setBeamPushUris का इस्तेमाल करते समय, ब्लूटूथ पर कनेक्शन हैंडओवर करने की सुविधा काम करनी चाहिए. इसके लिए, NFC फ़ोरम के “Connection Handover version 1.2” और “Bluetooth Secure Simple Pairing Using NFC version 1.0” स्पेसिफ़िकेशन लागू करने होंगे. इस तरह के डिवाइसों को, हैंडओवर एलएलसीपी सेवा को लागू करना होगा. इसके लिए, सेवा का नाम “urn:nfc:sn:handover” होना चाहिए, ताकि एनएफ़सी पर हैंडओवर का अनुरोध/चुने गए रिकॉर्ड का आदान-प्रदान किया जा सके. साथ ही, डिवाइसों को ब्लूटूथ ऑब्जेक्ट पुश प्रोफ़ाइल का इस्तेमाल करना होगा, ताकि ब्लूटूथ पर डेटा ट्रांसफ़र किया जा सके. लेगसी की वजहों से (Android 4.1 डिवाइसों के साथ काम करने के लिए), लागू करने वाले को अब भी NFC पर हैंडओवर का अनुरोध/चुनिंदा रिकॉर्ड बदलने के लिए, SNEP GET अनुरोधों को स्वीकार करना चाहिए. हालांकि, कनेक्शन हैंडओवर करने के लिए, किसी भी सुविधा को एसएनईपी के GET अनुरोध नहीं भेजने चाहिए.
• [C-1-13] NFC डिस्कवरी मोड में, डिवाइस के साथ काम करने वाली सभी टेक्नोलॉजी के लिए पोल करना ज़रूरी है.
• डिवाइस के चालू होने पर, एनएफ़सी को डिस्कवरी मोड में होना चाहिए. साथ ही, स्क्रीन चालू होनी चाहिए और लॉक-स्क्रीन अनलॉक होनी चाहिए.
• बारकोड और यूआरएल (अगर कोड में बदला गया है) को पढ़ने में सक्षम होना चाहिए. यह Thinfilm NFC Barcode प्रॉडक्ट के लिए ज़रूरी है.

ध्यान दें कि ऊपर बताए गए JIS, ISO, और NFC फ़ोरम के स्पेसिफ़िकेशन के लिए, सार्वजनिक तौर पर उपलब्ध लिंक मौजूद नहीं हैं.

Android में, NFC होस्ट कार्ड एम्युलेशन (एचसीई) मोड के साथ काम करने की सुविधा शामिल है.

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

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. Camera 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.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-SR] यह सुझाव दिया जाता है कि लॉजिकल कैमरा डिवाइस, CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA सुविधा के साथ काम करे. यह सुविधा, एक ही दिशा में फ़ोकस करने वाले कई कैमरों वाले डिवाइसों के लिए होती है. इसमें उस दिशा में फ़ोकस करने वाले हर फ़िज़िकल कैमरे को शामिल किया जाता है. हालांकि, इसके लिए ज़रूरी है कि फ़िज़िकल कैमरे का टाइप, फ़्रेमवर्क के साथ काम करता हो और फ़िज़िकल कैमरों के लिए CameraCharacteristics.INFO_SUPPORTED_HARDWARE_LEVEL, LIMITED, FULL या LEVEL_3 हो.

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

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

• उपयोगकर्ता के लिए उपलब्ध रिमूवेबल स्टोरेज, जैसे कि सिक्योर डिजिटल (एसडी) कार्ड स्लॉट.
• Android ओपन सोर्स प्रोजेक्ट (एओएसपी) में लागू की गई इंटरनल (हटाने योग्य नहीं) स्टोरेज का एक हिस्सा.

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

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

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

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

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

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

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

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

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

• [C-2-1] android.hardware.microphone सुविधा के कॉन्स्टेंट की जानकारी नहीं देनी चाहिए.
• [C-2-2] सेक्शन 7 के मुताबिक, ऑडियो रिकॉर्डिंग वाले एपीआई को कम से कम no-ops के तौर पर लागू करना ज़रूरी है.

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] कम से कम एक ऑडियो पोर्ट में, चार कंडक्टर वाला 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.3. अल्ट्रासाउंड के आस-पास की फ़्रीक्वेंसी

नियर-अल्ट्रासाउंड ऑडियो, 18.5 किलोहर्ट्ज़ से 20 किलोहर्ट्ज़ बैंड होता है.

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

• AudioManager.getProperty एपीआई के ज़रिए, नियर-अल्ट्रासाउंड ऑडियो की सुविधा के बारे में सही जानकारी देनी होगी. इसके लिए, यह तरीका अपनाएं:

अगर PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND "सही" है, तो VOICE_RECOGNITION और UNPROCESSED ऑडियो सोर्स को इन ज़रूरी शर्तों को पूरा करना होगा:

• [C-1-1] 18.5 किलोहर्ट्ज़ से 20 किलोहर्ट्ज़ बैंड में माइक्रोफ़ोन की औसत पावर रिस्पॉन्स, 2 किलोहर्ट्ज़ पर रिस्पॉन्स से 15 dB से ज़्यादा कम नहीं होना चाहिए.
• [C-1-2] 18.5 किलोहर्ट्ज़ से 20 किलोहर्ट्ज़ की फ़्रीक्वेंसी वाले माइक्रोफ़ोन के लिए, 19 किलोहर्ट्ज़ टोन पर -26 dBFS का अनवेटेड सिग्नल-टू-नॉइज़ रेशियो 50 dB से कम नहीं होना चाहिए.

अगर PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND "true" है, तो:

• [C-2-1] स्पीकर का 18.5 किलोहर्ट्ज़ से 20 किलोहर्ट्ज़ के बीच का औसत रिस्पॉन्स, 2 किलोहर्ट्ज़ के रिस्पॉन्स से 40 डेसिबल से कम नहीं होना चाहिए.

7.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] H.264 डिकोडिंग के साथ काम करना ज़रूरी है. यह कम से कम 3840 x 2160 पिक्सल पर 30 एफ़पीएस पर काम करना चाहिए. इसे औसतन 40 एमबीपीएस पर कंप्रेस किया गया हो. यह 1920 x 1080 पिक्सल पर 30 एफ़पीएस पर 10 एमबीपीएस के चार इंस्टेंस या 1920 x 1080 पिक्सल पर 60 एफ़पीएस पर 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] VR मोड में, डिसप्ले कम से कम 60 हर्ट्ज़ पर अपडेट होना चाहिए.
• [C-1-17] डिसप्ले में लो-पर्सिस्टेंस मोड काम करना चाहिए. साथ ही, पर्सिस्टेंस 5 मिलीसेकंड या इससे कम होना चाहिए. पर्सिस्टेंस का मतलब है कि कोई पिक्सल कितने समय तक रोशनी देता है.
• [C-1-18] इनमें ब्लूटूथ 4.2 और ब्लूटूथ स्मार्ट डेटा लेंथ एक्सटेंशन सेक्शन 7.4.3 काम करना चाहिए.
• [C-1-19] इन सभी डिफ़ॉल्ट सेंसर टाइप के लिए, डायरेक्ट चैनल टाइप को सपोर्ट करना और उसकी सही जानकारी देना ज़रूरी है:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED
• [C-SR] यह सुझाव दिया जाता है कि ऊपर दिए गए सभी डायरेक्ट चैनल टाइप के लिए, 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 Open Source Project की साइट पर मौजूद है.
• [SR] बिजली की खपत की सभी वैल्यू को मिलीऐंपियर घंटे (mAh) में रिपोर्ट करने का सुझाव दिया जाता है.
• [SR] हर प्रोसेस के यूआईडी के हिसाब से, सीपीयू की पावर खपत की जानकारी देने का सुझाव दिया जाता है. Android ओपन सोर्स प्रोजेक्ट, uid_cputime कर्नेल मॉड्यूल को लागू करके इस ज़रूरी शर्त को पूरा करता है.
• [SR] हमारा सुझाव है कि ऐप्लिकेशन डेवलपर को, adb shell dumpsys batterystats शेल कमांड के ज़रिए बैटरी के इस्तेमाल की जानकारी उपलब्ध कराई जाए.
• अगर किसी ऐप्लिकेशन को हार्डवेयर कॉम्पोनेंट के पावर इस्तेमाल करने का श्रेय नहीं दिया जा सकता, तो हार्डवेयर कॉम्पोनेंट को ही इसका श्रेय दिया जाना चाहिए.

8.5. लगातार अच्छी परफ़ॉर्मेंस

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

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

• [C-0-1] PowerManager.isSustainedPerformanceModeSupported() एपीआई तरीके का इस्तेमाल करके, यह सटीक जानकारी देना ज़रूरी है कि डिवाइस में Sustained Performance Mode की सुविधा काम करती है.

• सस्टेंड परफ़ॉर्मेंस मोड काम करना चाहिए.

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

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

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

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

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

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

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

• [C-3-1] Process.getExclusiveCores() एपीआई मेथड के ज़रिए, खाली सूची को नतीजे के तौर पर दिखाना ज़रूरी है.

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 में बताए गए सुरक्षा उपायों के बराबर या उससे ज़्यादा सुरक्षा देता है. इससे लॉकस्क्रीन के नॉलेज फ़ैक्टर पर ब्रूट-फ़ोर्स अटैक को रोका जा सकता है.

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

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

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

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

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

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

9.6. प्रीमियम एसएमएस की चेतावनी

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

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

• [C-1-1] डिवाइस में मौजूद /data/misc/sms/codes.xml फ़ाइल में तय किए गए रेगुलर एक्सप्रेशन से पहचाने गए नंबरों पर एसएमएस भेजने से पहले, उपयोगकर्ताओं को चेतावनी देनी होगी. अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट, इस ज़रूरी शर्त को पूरा करने वाला एक तरीका उपलब्ध कराता है.

9.7. सुरक्षा से जुड़ी सुविधाएं

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

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 ओपन सोर्स प्रोजेक्ट, इस ज़रूरी शर्त को पूरा करता है. इसके लिए, वह थ्रेडग्रुप सिंक्रनाइज़ेशन (टीएसवाईएनसी) के साथ seccomp-BPF को चालू करता है. इसके बारे में source.android.com के कर्नल कॉन्फ़िगरेशन सेक्शन में बताया गया है.

कर्नल की सुरक्षा और खुद की सुरक्षा करने की सुविधाएं, Android की सुरक्षा के लिए ज़रूरी हैं. डिवाइस में सेट किए गए सिस्टम के लिए:

• [C-0-7] कर्नेल स्टैक बफ़र ओवरफ़्लो से सुरक्षा देने वाली सुविधाओं (जैसे कि 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] कर्नेल मोड में एक्ज़ीक्यूट करते समय, उपयोगकर्ता-स्पेस मेमोरी को एक्ज़ीक्यूट नहीं करना चाहिए. जैसे, एपीआई लेवल 28 या इससे ज़्यादा के साथ शिप किए गए डिवाइसों पर, हार्डवेयर पीएक्सएन या CONFIG_CPU_SW_DOMAIN_PAN या CONFIG_ARM64_SW_TTBR0_PAN के ज़रिए इम्यूलेट किया गया.
• [C-0-11] एपीआई लेवल 28 या इसके बाद के वर्शन वाले डिवाइसों पर, कर्नल को सामान्य usercopy ऐक्सेस एपीआई (जैसे, हार्डवेयर पैन या CONFIG_CPU_SW_DOMAIN_PAN या CONFIG_ARM64_SW_TTBR0_PAN के ज़रिए इम्यूलेट किया गया) के बाहर, उपयोगकर्ता-स्पेस मेमोरी को न तो पढ़ना चाहिए और न ही उसमें लिखना चाहिए.
• [C-0-12] एपीआई लेवल 28 या इसके बाद के वर्शन के साथ शिप किए गए सभी डिवाइसों पर, कर्नेल पेज टेबल आइसोलेशन लागू करना ज़रूरी है. जैसे, CONFIG_PAGE_TABLE_ISOLATION या `CONFIG_UNMAP_KERNEL_AT_EL0.
• [SR] यह सुझाव दिया जाता है कि कर्नेल डेटा को सिर्फ़ शुरू करने के दौरान लिखा जाए.साथ ही, शुरू करने के बाद उसे सिर्फ़ पढ़ने के लिए मार्क किया जाए. उदाहरण के लिए, __ro_after_init.
• [SR] कर्नेल कोड और मेमोरी के लेआउट को रैंडमाइज़ करने का सुझाव दिया जाता है.साथ ही, ऐसे एक्सपोज़र से बचने का सुझाव दिया जाता है जिनसे रैंडमाइज़ेशन से समझौता हो सकता है. जैसे, /chosen/kaslr-seed Device Tree node या EFI_RNG_PROTOCOL के ज़रिए बूटलोडर एंट्रॉपी के साथ CONFIG_RANDOMIZE_BASE.

अगर डिवाइस में 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 में कई लेयर की सुरक्षा से जुड़ी सुविधाएं मौजूद हैं. ये सुविधाएं, डिवाइस की सुरक्षा के लिए ज़रूरी हैं.

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

• [C-SR] जिन कॉम्पोनेंट पर कंट्रोल-फ़्लो इंटिग्रिटी (सीएफ़आई) या पूर्णांक ओवरफ़्लो सैनिटाइज़ेशन (इंटसैन) की सुविधा चालू है उन्हें बंद न करने का सुझाव दिया जाता है.
• [C-SR] सुरक्षा के लिहाज़ से संवेदनशील किसी भी अतिरिक्त यूज़रस्पेस कॉम्पोनेंट के लिए, सीएफ़आई और IntSan, दोनों को चालू करने का सुझाव दिया जाता है. इनके बारे में सीएफ़आई और IntSan में बताया गया है.

9.8. निजता

9.8.1. इस्तेमाल का इतिहास

Android, उपयोगकर्ता की पसंद का इतिहास सेव करता है. साथ ही, UsageStatsManager की मदद से इस इतिहास को मैनेज करता है.

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

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

Android, सिस्टम इवेंट को StatsLog आइडेंटिफ़ायर का इस्तेमाल करके सेव करता है. साथ ही, StatsManager और IncidentManager System API की मदद से, इस इतिहास को मैनेज करता है.

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

• [C-0-2] सिस्टम एपीआई क्लास IncidentManager से बनाई गई घटना की रिपोर्ट में, सिर्फ़ DEST_AUTOMATIC के तौर पर मार्क किए गए फ़ील्ड शामिल होने चाहिए.
• [C-0-3] StatsLog SDK टूल के दस्तावेज़ों में बताए गए इवेंट के अलावा, किसी अन्य इवेंट को लॉग करने के लिए सिस्टम इवेंट आइडेंटिफ़ायर का इस्तेमाल नहीं किया जाना चाहिए. अगर अतिरिक्त सिस्टम इवेंट लॉग किए जाते हैं, तो वे 1,00,000 से 2,00,000 के बीच की रेंज में मौजूद किसी दूसरे ऐटम आइडेंटिफ़ायर का इस्तेमाल कर सकते हैं.

9.8.2. रिकॉर्डिंग

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

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

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

• [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.9. डेटा स्टोरेज एन्क्रिप्शन

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

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

अगर एईएस की क्रिप्टोग्राफ़िक परफ़ॉर्मेंस 50 MiB/सेकंड या इससे कम है, तो डिवाइस के लिए Adiantum-XChaCha12-AES का इस्तेमाल किया जा सकता है. इसके बजाय, यहां दिए गए किसी भी एईएस का इस्तेमाल किया जा सकता है: सेक्शन 9.9.2 [C-1-5] में AES-256-XTS; सेक्शन 9.9.2 [C-1-6] में CBS-CTS मोड में AES-256; सेक्शन 9.9.3 [C-1-1] में AES; सेक्शन 9.9.3 [C-1-3] में AES.

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

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

• उसे फ़ाइल आधारित एन्क्रिप्शन (एफ़बीई) लागू करके, डेटा स्टोरेज को एन्क्रिप्ट करने की ऊपर दी गई ज़रूरी शर्त को पूरा करना चाहिए.

9.9.1. डायरेक्ट बूट

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

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

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

9.9.2. अलग-अलग फ़ाइलों को अलग-अलग तरीकों से एन्क्रिप्ट करने का तरीका

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

• [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 का इस्तेमाल करके एन्क्रिप्ट (सुरक्षित) करने की सुविधा होनी चाहिए. AES-256-XTS का मतलब है, 256-बिट की कुंजी की लंबाई वाला ऐडवांस एन्क्रिप्शन स्टैंडर्ड, जो XTS मोड में काम करता है. XTS कुंजी की पूरी लंबाई 512 बिट होती है.

• [C-1-6] CBC-CTS मोड में AES-256 का इस्तेमाल करके, फ़ाइल के नामों को एन्क्रिप्ट (सुरक्षित) करने की सुविधा होनी चाहिए.

• सीई और डीई स्टोरेज एरिया को सुरक्षित रखने वाले पासकोड:

• [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 कर्नेल ext4 एन्क्रिप्शन सुविधा के आधार पर, इस सुविधा को लागू करने का पसंदीदा तरीका उपलब्ध कराता है.

9.9.3. पूरी डिस्क को एन्क्रिप्ट (सुरक्षित) करना

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

• [C-1-1] स्टोरेज के लिए डिज़ाइन किए गए मोड में AES का इस्तेमाल करना ज़रूरी है. उदाहरण के लिए, XTS या CBC-ESSIV. साथ ही, सिफ़र कुंजी की लंबाई 128 बिट या इससे ज़्यादा होनी चाहिए.
• [C-1-2] एन्क्रिप्शन की को रैप करने के लिए, डिफ़ॉल्ट पासकोड का इस्तेमाल करना ज़रूरी है. साथ ही, एन्क्रिप्ट (सुरक्षित) किए बिना, एन्क्रिप्शन की को किसी भी समय स्टोरेज में नहीं लिखना चाहिए.
• [C-1-3] डिफ़ॉल्ट रूप से, एन्क्रिप्शन कुंजी को AES से एन्क्रिप्ट (सुरक्षित) करना ज़रूरी है. हालांकि, अगर उपयोगकर्ता साफ़ तौर पर ऑप्ट आउट करता है, तो ऐसा नहीं किया जाएगा. ऐसा तब भी नहीं किया जाएगा, जब इसका इस्तेमाल किया जा रहा हो. साथ ही, लॉक स्क्रीन के क्रेडेंशियल को धीरे-धीरे स्ट्रेच करने वाले एल्गोरिदम (जैसे, PBKDF2 या scrypt) का इस्तेमाल करके स्ट्रेच किया जाता है.
• [C-1-4] अगर उपयोगकर्ता ने लॉक स्क्रीन के क्रेडेंशियल नहीं दिए हैं या एन्क्रिप्शन के लिए पासकोड के इस्तेमाल को बंद कर दिया है और डिवाइस में हार्डवेयर की मदद से सुरक्षित किया गया कीस्टोर मौजूद है, तो ऊपर दिया गया डिफ़ॉल्ट पासवर्ड स्ट्रेचिंग एल्गोरिदम, उस कीस्टोर से क्रिप्टोग्राफ़िक रूप से जुड़ा होना चाहिए.
• [C-1-5] डिवाइस से एन्क्रिप्शन कुंजी को बाहर नहीं भेजना चाहिए. भले ही, इसे उपयोगकर्ता के पासकोड और/या हार्डवेयर से जुड़ी कुंजी के साथ रैप किया गया हो.

अपस्ट्रीम Android Open Source प्रोजेक्ट, इस सुविधा को लागू करने का सबसे अच्छा तरीका बताता है. यह Linux कर्नल की सुविधा dm-crypt पर आधारित है.

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 फ़ाइलों की पुष्टि करने का सुझाव दिया जाता है. इसके लिए, /system में मौजूद भरोसे की चेन का इस्तेमाल करें. /system को वेरिफ़ाइड बूट की प्रोसेस से सुरक्षित किया जाता है.
• [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] यह पक्का करना ज़रूरी है कि सुरक्षित हार्डवेयर, टच स्क्रीन को पूरी तरह से कंट्रोल करे.

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 को लागू करके इस ज़रूरी शर्त को पूरा करता है. हालांकि, एआरएम TrustZone पर आधारित कोई अन्य समाधान या तीसरे पक्ष की ओर से समीक्षा किया गया, हाइपरवाइज़र पर आधारित आइसोलेशन को सुरक्षित तरीके से लागू करने का तरीका भी इस्तेमाल किया जा सकता है.
• [C-1-3] लॉक स्क्रीन की पुष्टि, आइसोलेटेड एक्ज़ीक्यूशन एनवायरमेंट में ही की जानी चाहिए. साथ ही, पुष्टि हो जाने के बाद ही, पुष्टि से जुड़ी कुंजियों का इस्तेमाल करने की अनुमति दी जानी चाहिए. लॉक स्क्रीन के क्रेडेंशियल को इस तरह से सेव किया जाना चाहिए कि सिर्फ़ आइसोलेटेड एक्ज़ीक्यूशन एनवायरमेंट ही लॉक स्क्रीन की पुष्टि कर सके. अपस्ट्रीम Android Open Source Project, Gatekeeper Hardware Abstraction Layer (HAL) और Trusty उपलब्ध कराता है. इनका इस्तेमाल इस ज़रूरी शर्त को पूरा करने के लिए किया जा सकता है.
• [C-1-4] इसमें कुंजी की पुष्टि करने की सुविधा होनी चाहिए. इसमें पुष्टि करने के लिए इस्तेमाल की जाने वाली हस्ताक्षर कुंजी को सुरक्षित हार्डवेयर से सुरक्षित किया जाता है और हस्ताक्षर करने की प्रोसेस सुरक्षित हार्डवेयर में की जाती है. पुष्टि करने के लिए इस्तेमाल की जाने वाली साइनिंग कुंजियों को ज़्यादा से ज़्यादा डिवाइसों के साथ शेयर किया जाना चाहिए, ताकि इन कुंजियों का इस्तेमाल डिवाइस आइडेंटिफ़ायर के तौर पर न किया जा सके. इस ज़रूरी शर्त को पूरा करने का एक तरीका यह है कि जब तक किसी एसकेयू की कम से कम 1,00,000 यूनिट नहीं बन जातीं, तब तक एक ही पुष्टि करने वाली कुंजी शेयर की जाए. अगर किसी एसकेयू की 1,00,000 से ज़्यादा इकाइयां बनाई जाती हैं, तो हर 1,00,000 इकाइयों के लिए अलग कुंजी का इस्तेमाल किया जा सकता है.
• [C-1-5] उपयोगकर्ता को, अनलॉक से लॉक की गई स्थिति में ट्रांज़िशन के लिए, स्लीप टाइमआउट चुनने की अनुमति देनी होगी. इसके लिए, कम से कम 15 सेकंड का टाइमआउट सेट किया जा सकता है.

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

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-4-1] सेक्शन 7.3.10.2 में बताई गई सभी ज़रूरी शर्तें पूरी करनी चाहिए.
• [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() तरीके को कॉल करके, keguard सुविधा की नीति सेट करने पर, स्क्रीन को अनलॉक करने के लिए सिर्फ़ सुझाए गए मुख्य पुष्टि करने के तरीके का इस्तेमाल किया जाना चाहिए. इसके साथ ही, बायोमेट्रिक से जुड़े किसी भी फ़्लैग (जैसे कि KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE या KEYGUARD_DISABLE_IRIS) का इस्तेमाल किया जाना चाहिए.
• [C-4-4] उपयोगकर्ता को कम से कम हर 72 घंटे में एक बार या उससे कम समय में, पुष्टि करने के लिए सुझाए गए मुख्य तरीके (जैसे, पिन, पैटर्न, पासवर्ड) का इस्तेमाल करने के लिए कहना ज़रूरी है.
• [C-4-5] इसमें फ़िंगरप्रिंट सेंसर के लिए ज़रूरी फ़ॉल्स ऐक्सेप्टेंस रेट (एफ़एआर) के बराबर या उससे कम एफ़एआर होना चाहिए. इसके बारे में सेक्शन 7.3.10 में बताया गया है. अगर ऐसा नहीं होता है, तो इसे बंद कर देना चाहिए. साथ ही, डिवाइस पॉलिसी कंट्रोलर (डीपीसी) ऐप्लिकेशन के DevicePolicyManager.setPasswordQuality() तरीके से, PASSWORD_QUALITY_BIOMETRIC_WEAK से ज़्यादा पाबंदी वाले क्वालिटी कॉन्स्टेंट के साथ पासवर्ड क्वालिटी की नीति सेट करने पर, स्क्रीन को अनलॉक करने के लिए सिर्फ़ सुझाए गए प्राइमरी ऑथेंटिकेशन की अनुमति देनी चाहिए.
• [C-SR] में, स्पूफ़ और इंपोस्टर को स्वीकार करने की दरें, फ़िंगरप्रिंट सेंसर के लिए ज़रूरी दरों के बराबर या उनसे ज़्यादा होनी चाहिए. इसके बारे में सेक्शन 7.3.10 में बताया गया है.
• [C-4-6] इसमें सुरक्षित प्रोसेसिंग पाइपलाइन होनी चाहिए, ताकि ऑपरेटिंग सिस्टम या कर्नल से समझौता होने पर, डेटा को सीधे तौर पर इंजेक्ट न किया जा सके. इससे उपयोगकर्ता के तौर पर गलत तरीके से पुष्टि की जा सकती है.
• [C-4-7] अगर ऐप्लिकेशन, KeyGenParameterSpec.Built.setUserAuthenticationRequired() के लिए true सेट करता है और बायोमेट्रिक डेटा पैसिव है (जैसे कि चेहरा या आइरिस, जहां इरादे का कोई साफ़ तौर पर सिग्नल मौजूद नहीं है), तो कीस्टोर की कुंजियों को ऐक्सेस करने की अनुमति देने के लिए, इसे साफ़ तौर पर पुष्टि करने की कार्रवाई (जैसे: बटन दबाना) के साथ जोड़ा जाना चाहिए.
• [C-SR] पैसिव बायोमेट्रिक्स के लिए, पुष्टि करने की कार्रवाई को इस तरह से सुरक्षित किया जाना चाहिए कि ऑपरेटिंग सिस्टम या कर्नेल से छेड़छाड़ करने वाला कोई व्यक्ति इसे स्पूफ़ न कर सके. उदाहरण के लिए, इसका मतलब है कि किसी बटन पर आधारित पुष्टि करने की कार्रवाई को, सुरक्षित एलिमेंट (एसई) के सिर्फ़ इनपुट वाले सामान्य मकसद के इनपुट/आउटपुट (जीपीआईओ) पिन के ज़रिए रूट किया जाता है. इसे बटन दबाने के अलावा किसी और तरीके से नहीं किया जा सकता.

अगर बायोमेट्रिक ऑथेंटिकेशन के तरीके, सेक्शन 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] उपयोगकर्ता को कम से कम हर 72 घंटे में एक बार, पुष्टि करने के लिए सुझाए गए मुख्य तरीकों (जैसे, पिन, पैटर्न, पासवर्ड) में से किसी एक का इस्तेमाल करने के लिए कहा जाना चाहिए.
• [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 या Automotive डिवाइस.
• [C-7-4] यह ज़रूरी है कि TrustAgentService.addEscrowToken() से जोड़े गए सभी सेव किए गए टोकन को एन्क्रिप्ट (सुरक्षित) किया जाए.
• [C-7-5] एन्क्रिप्शन की कुंजी को उस डिवाइस पर सेव नहीं किया जाना चाहिए जिस पर कुंजी का इस्तेमाल किया जाता है. उदाहरण के लिए, फ़ोन में सेव की गई पासकी का इस्तेमाल करके, टीवी पर उपयोगकर्ता खाते को अनलॉक किया जा सकता है.
• [C-7-6] डेटा स्टोरेज को डिक्रिप्ट करने के लिए एस्क्रो टोकन चालू करने से पहले, उपयोगकर्ता को सुरक्षा से जुड़ी समस्याओं के बारे में बताना ज़रूरी है.
• [C-7-7] पुष्टि करने के सुझाए गए मुख्य तरीकों में से किसी एक का इस्तेमाल करने के लिए, फ़ॉल-बैक मैकेनिज़्म होना ज़रूरी है.
• [C-7-8] उपयोगकर्ता को कम से कम हर 72 घंटे में एक बार, पुष्टि करने के लिए सुझाई गई मुख्य तरीकों (जैसे: पिन, पैटर्न, पासवर्ड) में से किसी एक का इस्तेमाल करने के लिए कहा जाना चाहिए.
• [C-7-9] डिवाइस का इस्तेमाल न होने पर, चार घंटे की समयसीमा खत्म होने के बाद, उपयोगकर्ता को पुष्टि करने के सुझाए गए मुख्य तरीकों (जैसे: पिन, पैटर्न, पासवर्ड) में से किसी एक का इस्तेमाल करने के लिए कहा जाना चाहिए. डिवाइस क्रेडेंशियल की पुष्टि हो जाने के बाद, निष्क्रियता की वजह से टाइम आउट होने की अवधि रीसेट हो जाती है.
• [C-7-10] को सुरक्षित लॉक स्क्रीन के तौर पर नहीं माना जाना चाहिए. साथ ही, इसे नीचे दिए गए C-8 में बताई गई पाबंदियों का पालन करना चाहिए.

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

• [C-8-1] अगर डिवाइस नीति कंट्रोलर (डीपीसी) ऐप्लिकेशन ने DevicePolicyManager.setPasswordQuality() तरीके से पासवर्ड की क्वालिटी से जुड़ी नीति सेट की है और क्वालिटी कॉन्स्टेंट PASSWORD_QUALITY_UNSPECIFIED से ज़्यादा पाबंदी वाला है, तो नए तरीके को बंद करना होगा.
• [C-8-2] उन्हें DevicePolicyManager.setPasswordExpirationTimeout() की ओर से सेट किए गए, पासवर्ड की समयसीमा खत्म होने के टाइमर को रीसेट नहीं करना चाहिए.
• [C-8-3] जब ऐप्लिकेशन, KeyGenParameterSpec.Builder.setUserAuthenticationRequired() के लिए true सेट करता है, तब उन्हें कीस्टोर के ऐक्सेस की पुष्टि नहीं करनी चाहिए.

9.11.2. StrongBox

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

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

• [C-SR] 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] को उपयोगकर्ता के जनरेट किए गए सभी डेटा को मिटाना होगा. इसका मतलब है कि इन डेटा को छोड़कर, बाकी सभी डेटा:
  • सिस्टम इमेज
  • सिस्टम इमेज के लिए ज़रूरी ऑपरेटिंग सिस्टम की कोई भी फ़ाइल
• [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 डिवाइसों से यह उम्मीद की जाती है कि वे वाहन के एचएएल का इस्तेमाल करके, वाहन के ज़रूरी सबसिस्टम के साथ डेटा शेयर करें. साथ ही, CAN बस जैसे वाहन के नेटवर्क पर मैसेज भेजें और पाएं.

डेटा एक्सचेंज को सुरक्षित किया जा सकता है. इसके लिए, 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 9 के लिए सीटीएस के कई वर्शन रिलीज़ किए जा सकते हैं.

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

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

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

• [C-1-1] डिवाइस में, रीबूट करके ऑफ़लाइन अपडेट करने की सुविधा के साथ-साथ, ओटीए डाउनलोड करने की सुविधा भी होनी चाहिए.

Android 6.0 और इसके बाद के वर्शन के साथ लॉन्च किए गए डिवाइसों के लिए, अपडेट करने के तरीके में यह पुष्टि करने की सुविधा होनी चाहिए कि ओटीए के बाद, सिस्टम इमेज बाइनरी के तौर पर, अनुमानित नतीजे के जैसी है. Android 5.1 से, अपस्ट्रीम Android Open Source Project में ब्लॉक-आधारित OTA लागू करने की सुविधा जोड़ी गई है. इससे इस ज़रूरी शर्त को पूरा किया जा सकता है.

साथ ही, डिवाइसों में 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 फ़ोरम में शामिल होकर, साफ़ तौर पर जानकारी माँगी जा सकती है. इसके अलावा, ऐसी कोई भी समस्या बताई जा सकती है जिसके बारे में दस्तावेज़ में जानकारी नहीं दी गई है.