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

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

1. परिचय

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2.1. हार्डवेयर

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.3. टीवी के लिए ज़रूरी शर्तें

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

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

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

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

2.3.1. हार्डवेयर

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [3/T-0-1] android.software.leanback और android.hardware.type.television सुविधाओं के बारे में ज़रूर बताएं.
• [3.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 के ओपन सोर्स प्रोजेक्ट में बताई गई, Switch Access और TalkBack (पहले से इंस्टॉल किए गए Text-to-speech इंजन के साथ काम करने वाली भाषाओं के लिए) जैसी या उनसे बेहतर सुविधाएं देती हों.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.4.1. हार्डवेयर

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [7.8.2/W] में ऑडियो आउटपुट हो सकता है, लेकिन ऐसा नहीं होना चाहिए.

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

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

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

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

• [3/W-0-1] android.hardware.type.watch सुविधा के बारे में ज़रूर बताएं.
• [3/W-0-2] uiMode = UI_MODE_TYPE_WATCH के साथ काम करना चाहिए.

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

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

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

• [3.10/W-1-1] ऐप्लिकेशन में, तीसरे पक्ष की सुलभता सेवाओं के साथ काम करने की सुविधा होनी चाहिए.

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

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

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

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

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

• [8.3/W-SR] हमारा सुझाव है कि आप उपयोगकर्ताओं को उन सभी ऐप्लिकेशन को दिखाने की सुविधा दें जिन्हें ऐप्लिकेशन स्टैंडबाय और Doze मोड (बैटरी बचाने के लिए) से छूट मिली है.
• [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.4.5. सुरक्षा मॉडल

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

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

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

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

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

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

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

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

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

2.5.1. हार्डवेयर

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

अगर वाहन से जुड़े डिवाइसों में 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 एमबी मेमोरी उपलब्ध होनी चाहिए:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.6.1. हार्डवेयर

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

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

जाइरोस्कोप

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  हालांकि, वे:

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

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

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. Soft API Compatibility

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

3.2.1. अनुमतियां

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

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

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

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

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

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

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

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

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

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

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

3.2.3.5. ऐप्लिकेशन की डिफ़ॉल्ट सेटिंग

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

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

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

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

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

• [C-2-1] ऐसा सेटिंग मेन्यू होना चाहिए जो RoleManager.ROLE_SMS के साथ RoleManager.createRequestRoleIntent(String) इंटेंट को कॉल करेगा, ताकि डिफ़ॉल्ट एसएमएस ऐप्लिकेशन बदलने के लिए डायलॉग दिखाया जा सके.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • armeabi
  • armeabi-v7a
  • arm64-v8a
  • x86
  • x86-64

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [C-0-1] डिवाइसों को स्टैंडर्ड इंटेंट के व्यवहार या सेमेटिक्स में बदलाव नहीं करना चाहिए.
• [C-0-2] डिवाइसों को किसी खास तरह के सिस्टम कॉम्पोनेंट (जैसे, सेवा, गतिविधि, ContentProvider वगैरह) के लाइफ़साइकल या लाइफ़साइकल सेमेटिक्स में बदलाव नहीं करना चाहिए.
• [C-0-3] डिवाइसों को स्टैंडर्ड अनुमति के सेमेटिक्स में बदलाव नहीं करना चाहिए.
• डिवाइसों को बैकग्राउंड ऐप्लिकेशन पर लागू की गई सीमाओं में बदलाव नहीं करना चाहिए. खास तौर पर, बैकग्राउंड में चलने वाले ऐप्लिकेशन के लिए:
  • [C-0-4] उन्हें GnssMeasurement और GnssNavigationMessage से आउटपुट पाने के लिए, ऐप्लिकेशन से रजिस्टर किए गए कॉलबैक को चलाना बंद करना होगा.
  • [C-0-5] उन्हें LocationManager एपीआई क्लास या WifiManager.startScan() तरीके से, ऐप्लिकेशन को मिलने वाले अपडेट की फ़्रीक्वेंसी को रेट-सीमा में रखना होगा.
  • [C-0-6] अगर ऐप्लिकेशन, एपीआई लेवल 25 या उसके बाद के वर्शन को टारगेट कर रहा है, तो उसे ऐप्लिकेशन के मेनिफ़ेस्ट में स्टैंडर्ड Android इंटेंट के इम्प्लीसिट ब्रॉडकास्ट के लिए, ब्रॉडकास्ट रिसीवर को रजिस्टर करने की अनुमति नहीं देनी चाहिए. ऐसा तब तक नहीं किया जाना चाहिए, जब तक कि ब्रॉडकास्ट इंटेंट के लिए "signature" या "signatureOrSystem" protectionLevel की अनुमति की ज़रूरत न हो या वे छूट वाली सूची में शामिल न हों.
  • [C-0-7] अगर ऐप्लिकेशन, एपीआई लेवल 25 या उसके बाद के वर्शन को टारगेट कर रहा है, तो उसे ऐप्लिकेशन की बैकग्राउंड सेवाओं को बंद करना होगा. ऐसा तब भी करना होगा, जब ऐप्लिकेशन ने सेवाओं के stopSelf() तरीके को कॉल किया हो. हालांकि, अगर ऐप्लिकेशन को किसी ऐसे टास्क को मैनेज करने के लिए, कुछ समय के लिए अनुमति वाली सूची में रखा गया है जो उपयोगकर्ता को दिखता है, तो ऐसा नहीं करना होगा.
  • [C-0-8] अगर ऐप्लिकेशन, एपीआई लेवल 25 या उसके बाद के वर्शन को टारगेट कर रहा है, तो उसे वेक लॉक रिलीज़ करने होंगे.
• [C-0-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. BC - com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
  6. HarmonyJSSE - com.android.org.conscrypt.JSSEProvider
  7. AndroidKeyStore - android.security.keystore.AndroidKeyStoreProvider

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8. यूज़र इंटरफ़ेस किस-किस के साथ काम करता है

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

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

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

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

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

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

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

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

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

• [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] इसमें ऐप्लिकेशन विजेट के लिए, पहले से मौजूद सहायता शामिल होनी चाहिए. साथ ही, लॉन्चर में सीधे ऐप्लिकेशन विजेट जोड़ने, कॉन्फ़िगर करने, देखने, और हटाने के लिए, यूज़र इंटरफ़ेस के फ़ीचर भी शामिल होने चाहिए.
• [C-1-3] यह ज़रूरी है कि यह स्टैंडर्ड ग्रिड साइज़ में, 4 x 4 वाले विजेट रेंडर कर सके. ज़्यादा जानकारी के लिए, Android SDK के दस्तावेज़ में ऐप्लिकेशन विजेट के डिज़ाइन से जुड़े दिशा-निर्देश देखें.
• लॉक स्क्रीन पर ऐप्लिकेशन विजेट काम कर सकते हैं.

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

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

3.8.3. सूचनाएं

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

3.8.3.1. सूचनाओं का प्रज़ेंटेशन

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

• [C-1-1] SDK टूल के दस्तावेज़ में बताए गए तरीके के मुताबिक, हार्डवेयर की सुविधाओं का इस्तेमाल करने वाली सूचनाओं के साथ काम करना चाहिए. साथ ही, यह ज़रूरी है कि यह सुविधा, डिवाइस में लागू किए गए हार्डवेयर के साथ काम करे. उदाहरण के लिए, अगर किसी डिवाइस में वाइब्रेटर शामिल है, तो उसे वाइब्रेशन एपीआई को सही तरीके से लागू करना होगा. अगर किसी डिवाइस पर एपीआई लागू करने के लिए ज़रूरी हार्डवेयर मौजूद नहीं है, तो उससे जुड़े एपीआई को नो-ऑप के तौर पर लागू करना ज़रूरी है. इस व्यवहार के बारे में ज़्यादा जानकारी सेक्शन 7 में दी गई है.
• [C-1-2] एपीआई या स्टेटस/सिस्टम बार आइकॉन स्टाइल गाइड में दिए गए सभी रिसॉर्स (आइकॉन, ऐनिमेशन फ़ाइलें वगैरह) को सही तरीके से रेंडर करना ज़रूरी है. हालांकि, हो सकता है कि वे सूचनाओं के लिए, रेफ़रंस के तौर पर इस्तेमाल किए जा रहे Android Open Source के मुकाबले, उपयोगकर्ता को अलग अनुभव दें.
• [C-1-3] सूचनाओं को अपडेट करने, हटाने, और ग्रुप करने के लिए, एपीआई के लिए बताए गए व्यवहारों को सही तरीके से लागू करना ज़रूरी है.
• [C-1-4] SDK टूल में, NotificationChannel एपीआई के काम करने के तरीके के बारे में पूरी जानकारी होनी चाहिए.
• [C-1-5] हर चैनल और ऐप्लिकेशन पैकेज के लेवल पर, तीसरे पक्ष के किसी ऐप्लिकेशन की सूचना को ब्लॉक करने और उसमें बदलाव करने के लिए, उपयोगकर्ता को सुविधा देना ज़रूरी है.
• [C-1-6] मिटाए गए सूचना चैनलों को दिखाने के लिए, उपयोगकर्ता को सुविधा भी देनी होगी.
• [C-1-7] Notification.MessagingStyle की मदद से दिए गए सभी संसाधनों (इमेज, स्टिकर, आइकॉन वगैरह) को, सूचना के टेक्स्ट के साथ सही तरीके से रेंडर करना चाहिए.इसके लिए, उपयोगकर्ता को कोई और कार्रवाई नहीं करनी चाहिए. उदाहरण के लिए, setGroupConversation से सेट की गई ग्रुप बातचीत में, android.app.Person से मिले आइकॉन के साथ-साथ सभी रिसॉर्स दिखाना ज़रूरी है.
• [C-SR] हमारा सुझाव है कि उपयोगकर्ता किसी सूचना को कई बार खारिज करने के बाद, हर चैनल और ऐप्लिकेशन पैकेज के लेवल पर, तीसरे पक्ष के किसी ऐप्लिकेशन की सूचना को ब्लॉक करने के लिए, उपयोगकर्ता को अपने-आप सूचना दिखाने की सुविधा दें.
• रिच सूचनाओं के साथ काम करना चाहिए.
• ज़्यादा प्राथमिकता वाली कुछ सूचनाओं को स्क्रीन पर सबसे ऊपर सूचना देने वाले कार्ड के तौर पर दिखाना चाहिए.
• सूचनाओं को स्नूज़ करने के लिए, उपयोगकर्ता के पास विकल्प होना चाहिए.
• तीसरे पक्ष के ऐप्लिकेशन, उपयोगकर्ताओं को अहम इवेंट की सूचना कब दे सकते हैं, यह मैनेज किया जा सकता है. इससे ड्राइवर का ध्यान भटकने जैसी सुरक्षा से जुड़ी समस्याओं को कम करने में मदद मिलती है.

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

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

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

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

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

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

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

3.8.4. खोजें

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

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

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

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

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

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

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

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

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

3.8.5. सूचनाएं और टॉस्ट

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

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

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

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

3.8.6. थीम

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

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

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

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

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

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

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

3.8.12. जगह की जानकारी

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

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

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

Android में, यूनिकोड 10.0 में बताए गए इमोजी वर्णों के लिए सहायता शामिल है.

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

• [C-1-1] इन इमोजी वर्ण को कलर ग्लिफ़ में रेंडर करने की सुविधा होनी चाहिए.
• [C-1-2] इसमें इनके लिए सहायता शामिल होनी चाहिए:
  • डिवाइस पर उपलब्ध भाषाओं के लिए, अलग-अलग वेट वाला Roboto 2 फ़ॉन्ट—sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed, sans-serif-condensed-light.
  • यूनिकोड 7.0 में लैटिन, ग्रीक, और सिरिलिक भाषाओं के लिए पूरी कवरेज. इसमें लैटिन एक्सटेंडेड A, B, C, और D रेंज के साथ-साथ, यूनिकोड 7.0 के मुद्रा के चिह्नों वाले ब्लॉक में मौजूद सभी ग्लिफ़ शामिल हैं.
• यूनिकोड तकनीकी रिपोर्ट #51 में बताए गए मुताबिक, स्किन टोन और अलग-अलग फ़ैमिली इमोजी के साथ काम करना चाहिए.

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

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

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

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

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

3.8.14. मल्टी-विंडो (एक से ज़्यादा ऐप्लिकेशन, एक साथ)

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

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

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

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

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

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

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

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

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

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

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

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

अगर डिवाइस पर android.software.device_admin लागू किया जाता है, तो:

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

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

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

3.9.1.2 मैनेज की जा रही प्रोफ़ाइल को डिवाइस पर सेट अप करना

अगर डिवाइस पर android.software.managed_users लागू किया जाता है, तो:

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

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

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

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

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

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

3.12. टीवी इनपुट फ़्रेमवर्क

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

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

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

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

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

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

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

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

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

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

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

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

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

3.15. Instant Apps

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

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

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

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

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

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

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

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

• [C-1-1] सिस्टम में एक बार में सिर्फ़ एक ऐसा ऐप्लिकेशन इंस्टॉल होना चाहिए जो cantSaveState के चलने की जानकारी देता हो. अगर उपयोगकर्ता किसी ऐप्लिकेशन से साफ़ तौर पर बाहर निकले बिना उसे छोड़ देता है, तो डिवाइस के लागू होने पर, उस ऐप्लिकेशन को रैम में प्राथमिकता देनी चाहिए. ठीक उसी तरह जैसे फ़ोरग्राउंड सेवाओं जैसी अन्य चीज़ों को प्राथमिकता दी जाती है. उदाहरण के लिए, सिस्टम में कोई भी ऐक्टिव गतिविधि नहीं होने पर, बैक बटन दबाने के बजाय होम बटन दबाकर ऐप्लिकेशन से बाहर निकलना. बैकग्राउंड में चलने वाले ऐसे ऐप्लिकेशन पर, सिस्टम अब भी पावर मैनेजमेंट की सुविधाएं लागू कर सकता है. जैसे, सीपीयू और नेटवर्क ऐक्सेस को सीमित करना.
• [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 साइनिंग का इस्तेमाल करके, “.apk” फ़ाइलों की पुष्टि की जा सके.
• [C-0-3] .apk, Android मेनिफ़ेस्ट, Dalvik बाइटकोड या RenderScript बाइटकोड फ़ॉर्मैट को इस तरह से एक्सटेंड़ नहीं किया जाना चाहिए कि वे फ़ाइलें, काम करने वाले अन्य डिवाइसों पर सही तरीके से इंस्टॉल और काम न कर पाएं.

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

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

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

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

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

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

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

5. मल्टीमीडिया के साथ काम करना

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

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

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

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

नीचे दिए गए सेक्शन में दिए गए सभी कोडेक, Android Open Source Project के पसंदीदा Android वर्शन में सॉफ़्टवेयर के तौर पर लागू किए जाते हैं.

कृपया ध्यान दें कि न तो Google और न ही Open Handset Alliance ने यह दावा किया है कि ये कोडेक, तीसरे पक्ष के पेटेंट से मुक्त हैं. जो लोग इस सोर्स कोड का इस्तेमाल हार्डवेयर या सॉफ़्टवेयर प्रॉडक्ट में करना चाहते हैं उन्हें सलाह दी जाती है कि इस कोड को लागू करने के लिए, उन्हें ज़रूरी पेटेंट के मालिकों से पेटेंट लाइसेंस लेने पड़ सकते हैं. इनमें ओपन सोर्स सॉफ़्टवेयर या शेयरवेयर भी शामिल है.

5.1. मीडिया कोडेक

5.1.1. ऑडियो एन्कोडिंग

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

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

• [C-1-1] PCM/WAVE
• [C-1-2] FLAC
• [C-1-3] Opus

सभी ऑडियो एन्कोडर में ये सुविधाएं होनी चाहिए:

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

5.1.2. ऑडियो को डिकोड करना

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

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

• [C-1-1] MPEG-4 AAC प्रोफ़ाइल (AAC LC)
• [C-1-2] MPEG-4 HE AAC Profile (AAC+)
• [C-1-3] MPEG-4 HE AACv2 प्रोफ़ाइल (बेहतर AAC+)
• [C-1-4] AAC ELD (कम देरी वाला बेहतर एएसी)
• [C-1-11] xHE-AAC (ISO/IEC 23003-3 एक्सटेंडेड HE AAC प्रोफ़ाइल, जिसमें USAC बेसलाइन प्रोफ़ाइल और ISO/IEC 23003-4 डाइनैमिक रेंज कंट्रोल प्रोफ़ाइल शामिल है)
• [C-1-5] FLAC
• [C-1-6] MP3
• [C-1-7] एमआईडीआई
• [C-1-8] Vorbis
• [C-1-9] PCM/WAVE, जिसमें 24 बिट तक के हाई रिज़ॉल्यूशन वाले ऑडियो फ़ॉर्मैट, 192 किलोहर्ट्ज़ का सैंपलिंग रेट, और आठ चैनल शामिल हैं. ध्यान दें कि यह शर्त सिर्फ़ डिकोड करने के लिए है. साथ ही, किसी डिवाइस को वीडियो चलाने के दौरान, उसे डाउनसैंपल और डाउनमिक्स करने की अनुमति है.
• [C-1-10] Opus

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

• [C-2-1] डिकोडिंग, डाउनमिक्स किए बिना की जानी चाहिए.उदाहरण के लिए, 5. 0 AAC स्ट्रीम को PCM के पांच चैनलों में डिकोड किया जाना चाहिए.5.1 AAC स्ट्रीम को PCM के छह चैनलों में डिकोड किया जाना चाहिए.
• [C-2-2] डाइनैमिक रेंज का मेटाडेटा, ISO/IEC 14496-3 में "डाइनैमिक रेंज कंट्रोल (डीआरसी)" में बताए गए तरीके के मुताबिक होना चाहिए. साथ ही, ऑडियो डिकोडर की डाइनैमिक रेंज से जुड़े व्यवहार को कॉन्फ़िगर करने के लिए, android.media.MediaFormat डीआरसी बटन का इस्तेमाल किया जाना चाहिए. AAC डीआरसी पासकोड, एपीआई 21 में लॉन्च किए गए थे. ये पासकोड ये हैं: KEY_AAC_DRC_ATTENUATION_FACTOR, KEY_AAC_DRC_BOOST_FACTOR, KEY_AAC_DRC_HEAVY_COMPRESSION, KEY_AAC_DRC_TARGET_REFERENCE_LEVEL, और KEY_AAC_ENCODED_TARGET_LEVEL.
• [SR] हमारा सुझाव है कि सभी एएसी ऑडियो डिकोडर, ऊपर दी गई C-2-1 और C-2-2 शर्तों को पूरा करें.

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

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

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

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

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

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

सभी ऑडियो डिकोडर में इन फ़ॉर्मैट में आउटपुट देने की सुविधा होनी चाहिए:

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

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

5.1.4. इमेज को कोड में बदलना

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

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

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

अगर डिवाइस पर, मीडिया टाइप MIMETYPE_IMAGE_ANDROID_HEIC के लिए android.media.MediaCodec की मदद से HEIC एन्कोडिंग की सुविधा काम करती है, तो:

• [C-1-1] हार्डवेयर की मदद से तेज़ी से काम करने वाला HEVC एन्कोडर कोडेक उपलब्ध कराना ज़रूरी है. यह कोडेक, BITRATE_MODE_CQ बिटरेट कंट्रोल मोड, HEVCProfileMainStill प्रोफ़ाइल, और 512 x 512 पिक्सल के फ़्रेम साइज़ के साथ काम करना चाहिए.

5.1.5. इमेज डिकोड करना

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

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

• [C-0-1] JPEG
• [C-0-2] GIF
• [C-0-3] PNG
• [C-0-4] BMP
• [C-0-5] WebP
• [C-0-6] रॉ
• [C-0-7] HEIF (HEIC)

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

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

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

MediaCodec API के ज़रिए एक्सपोज़ की गई इमेज एन्कोडर और डीकोडर

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

• [SR] इनपुट के लिए, सरफ़ेस मोड में RGB888 कलर फ़ॉर्मैट का इस्तेमाल करने का सुझाव दिया जाता है.

• [C-1-3] यह ज़रूरी है कि यह प्लैनर या सेमी-प्लानर YUV420 8:8:8 कलर फ़ॉर्मैट में से कम से कम एक को सपोर्ट करता हो: COLOR_FormatYUV420PackedPlanar (COLOR_FormatYUV420Planar के बराबर) या COLOR_FormatYUV420PackedSemiPlanar (COLOR_FormatYUV420SemiPlanar के बराबर). हमारा सुझाव है कि यह दोनों को सपोर्ट करता हो.

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

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

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

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

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

• [C-1-3] वीडियो एन्कोडर और डिकोडर, प्लानर या सेमीप्लानर YUV420 8:8:8 कलर फ़ॉर्मैट में से कम से कम किसी एक के साथ काम करने चाहिए: COLOR_FormatYUV420PackedPlanar (COLOR_FormatYUV420Planar के बराबर) या COLOR_FormatYUV420PackedSemiPlanar (COLOR_FormatYUV420SemiPlanar के बराबर). हमारा सुझाव है कि वे दोनों के साथ काम करें.

• [SR] वीडियो एन्कोडर और डिकोडर के लिए, हार्डवेयर के हिसाब से ऑप्टिमाइज़ किए गए प्लानर या सेमीप्लानर YUV420 8:8:8 कलर फ़ॉर्मैट (YV12, NV12, NV21 या वेंडर के हिसाब से ऑप्टिमाइज़ किया गया कोई दूसरा फ़ॉर्मैट) में से कम से कम एक फ़ॉर्मैट का इस्तेमाल करने का सुझाव दिया जाता है.

• [C-1-5] ज़्यादा बिट-डेप्थ फ़ॉर्मैट (हर चैनल के लिए 9 से ज़्यादा बिट) के साथ काम करने वाले वीडियो डिकोडर को, ऐप्लिकेशन के अनुरोध पर 8-बिट वाले मिलते-जुलते फ़ॉर्मैट को आउटपुट करने की सुविधा देनी होगी. यह android.media.MediaCodecInfo के ज़रिए YUV420 8:8:8 कलर फ़ॉर्मैट के साथ काम करने की सुविधा के तौर पर दिखना चाहिए.

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

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

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

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

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

• [C-4-1] अगर Surface आउटपुट का इस्तेमाल करके कॉन्फ़िगर किया गया है, तो डिफ़ॉल्ट रूप से हार्डवेयर डिसप्ले के लिए ऑप्टिमाइज़ किए गए कलर फ़ॉर्मैट का इस्तेमाल करना चाहिए.
• [C-4-2] अगर Surface आउटपुट का इस्तेमाल न करने के लिए कॉन्फ़िगर किया गया है, तो डिफ़ॉल्ट रूप से YUV420 8:8:8 कलर फ़ॉर्मैट का इस्तेमाल करना चाहिए. यह फ़ॉर्मैट, सीपीयू रीडिंग के लिए ऑप्टिमाइज़ किया गया है.

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

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

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

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

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

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

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

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

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

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

5.1.10. मीडिया कोडेक की जानकारी

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

• [C-1-1] MediaCodecInfo एपीआई की मदद से, मीडिया कोडेक की विशेषताओं की सही वैल्यू दिखानी चाहिए.

खास तौर पर:

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

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

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

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

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

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

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

अगर डिवाइस में एम्बेड किया गया स्क्रीन डिसप्ले शामिल है, जिसका डायगनल कम से कम 2.5 इंच है या वीडियो आउटपुट पोर्ट शामिल है या android.hardware.camera.any फ़ीचर फ़्लैग की मदद से कैमरे के काम करने की जानकारी दी गई है, तो:

• [C-1-1] इसमें कम से कम एक VP8 या H.264 वीडियो एन्कोडर की सुविधा शामिल होनी चाहिए. साथ ही, इसे तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराना चाहिए.
• यह VP8 और H.264, दोनों वीडियो एन्कोडर के साथ काम करना चाहिए. साथ ही, इसे तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराना चाहिए.

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

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

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

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

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

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

5.2.1. H.263

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

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

5.2.2. H.264

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

• [C-1-1] यह ज़रूरी है कि यह बेसलाइन प्रोफ़ाइल लेवल 3 के साथ काम करे. हालांकि, ASO (स्लाइस का मनमुताबिक क्रम), FMO (फ़्लेक्सिबल मैक्रोब्लॉक ऑर्डरिंग), और RS (रिडंडेंट स्लाइस) के लिए सहायता देना ज़रूरी नहीं है. इसके अलावा, अन्य Android डिवाइसों के साथ काम करने के लिए, हमारा सुझाव है कि एन्कोडर, बेसलाइन प्रोफ़ाइल के लिए ASO, FMO, और RS का इस्तेमाल न करें.
• [C-1-2] यह ज़रूरी है कि प्लेयर, नीचे दी गई टेबल में दी गई एसडी (स्टैंडर्ड डेफ़िनिशन) वीडियो एन्कोडिंग प्रोफ़ाइल के साथ काम करे.
• मुख्य प्रोफ़ाइल के लेवल 4 के साथ काम करना चाहिए.
• इस टेबल में बताई गई एचडी (हाई डेफ़िनिशन) वीडियो कोडिंग प्रोफ़ाइलों के साथ काम करना चाहिए.

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

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

5.2.3. VP8

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

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

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

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

5.2.4. VP9

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

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

अगर डिवाइस में Media APIs की मदद से, प्रोफ़ाइल 2 या प्रोफ़ाइल 3 के साथ काम करने का दावा किया जाता है, तो:

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

5.2.5. H.265

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

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

5.3. वीडियो डिकोड करना

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

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

5.3.1. MPEG-2

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

• [C-1-1] मुख्य प्रोफ़ाइल के हाई लेवल के साथ काम करना चाहिए.

5.3.2. H.263

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

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

5.3.3. MPEG-4

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

• [C-1-1] यह ज़रूरी है कि ऐप्लिकेशन, सिंपल प्रोफ़ाइल के लेवल 3 के साथ काम करे.

5.3.4. H.264

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

• [C-1-1] मुख्य प्रोफ़ाइल लेवल 3.1 और बेसलाइन प्रोफ़ाइल के साथ काम करना चाहिए. ASO (स्लाइस का मनमुताबिक क्रम), FMO (फ़्लेक्सिबल मैक्रोब्लॉक ऑर्डरिंग) और RS (ज़रूरत से ज़्यादा स्लाइस) के लिए सहायता देना ज़रूरी नहीं है.
• [C-1-2] यह ज़रूरी है कि यह टूल, नीचे दी गई टेबल में दी गई एसडी (स्टैंडर्ड डेफ़िनिशन) प्रोफ़ाइलों वाले वीडियो को डिकोड कर सके. साथ ही, यह वीडियो, बेसलाइन प्रोफ़ाइल और मुख्य प्रोफ़ाइल लेवल 3.1 (इसमें 720p30 भी शामिल है) के साथ एन्कोड किए गए हों.
• यह एचडी (हाई डेफ़िनिशन) प्रोफ़ाइल वाले वीडियो को डिकोड कर सके, जैसा कि इस टेबल में बताया गया है.

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

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

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, दोनों में से कम से कम एक को डिकोड करने की सुविधा होनी चाहिए.

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

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

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

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

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

5.3.6. VP8

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

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

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

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

5.3.7. VP9

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

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

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

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

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

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

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

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

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

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

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

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

• [C-SR] डिवाइस की स्क्रीन या स्टैंडर्ड वीडियो आउटपुट पोर्ट (उदाहरण के लिए, एचडीएमआई).

5.3.8. Dolby Vision

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

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

5.3.9. AV1

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

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

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

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

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

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

• [C-1-1] यह ज़रूरी है कि ऐप्लिकेशन, रॉ ऑडियो कॉन्टेंट को इन विशेषताओं के साथ कैप्चर कर सके:

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

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

  • फ़ॉर्मैट: लीनियर PCM, 16-बिट, और 24-बिट
  • सैंपलिंग रेट: 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 हर्ट्ज़
  • चैनल: डिवाइस पर मौजूद माइक्रोफ़ोन की संख्या के हिसाब से चैनल

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

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

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

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

• [C-1-4] MicrophoneInfo एपीआई का पालन करना ज़रूरी है. साथ ही, डिवाइस पर उपलब्ध माइक्रोफ़ोन की जानकारी सही तरीके से भरनी होगी, ताकि तीसरे पक्ष के ऐप्लिकेशन उन्हें AudioManager.getMicrophones() एपीआई के ज़रिए ऐक्सेस कर सकें. साथ ही, AudioRecord.getActiveMicrophones() और MediaRecorder.getActiveMicrophones() एपीआई के ज़रिए, तीसरे पक्ष के ऐप्लिकेशन उन माइक्रोफ़ोन को ऐक्सेस कर सकें जो फ़िलहाल चालू हैं. अगर डिवाइस में AM रेडियो और डीवीडी क्वालिटी में रॉ ऑडियो कॉन्टेंट कैप्चर करने की सुविधा है, तो:

• [C-2-1] 16000:22050 या 44100:48000 से ज़्यादा के रेशियो में, अप-सैंपलिंग के बिना रिकॉर्ड करना ज़रूरी है.

• [C-2-2] अप-सैंपलिंग या डाउन-सैंपलिंग के लिए, सही ऐंटी-ऐलिऐसिंग फ़िल्टर शामिल करना ज़रूरी है.

5.4.2. आवाज़ पहचानने की सुविधा के लिए रिकॉर्ड करना

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

• [C-1-1] android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION ऑडियो सोर्स को 44100 और 48000 में से किसी एक सैंपलिंग रेट पर कैप्चर करना ज़रूरी है.
• [C-1-2] AudioSource.VOICE_RECOGNITION ऑडियो सोर्स से ऑडियो स्ट्रीम रिकॉर्ड करते समय, ग़ैर-ज़रूरी आवाज़ें कम करने वाली ऑडियो प्रोसेसिंग को डिफ़ॉल्ट रूप से बंद करना ज़रूरी है.
• [C-1-3] AudioSource.VOICE_RECOGNITION ऑडियो सोर्स से ऑडियो स्ट्रीम रिकॉर्ड करते समय, ऑटोमैटिक गेन कंट्रोल की सुविधा को डिफ़ॉल्ट रूप से बंद करना ज़रूरी है.
• आवाज़ की पहचान करने वाली ऑडियो स्ट्रीम को, फ़्रीक्वेंसी के हिसाब से लगभग फ़्लैट ऐम्प्ल्यट्यूड के साथ रिकॉर्ड करना चाहिए: खास तौर पर, 100 हर्ट्ज़ से 4,000 हर्ट्ज़ तक ±3 डीबी.
• आवाज़ पहचानने की सुविधा वाली ऑडियो स्ट्रीम को इनपुट सेंसिटिविटी के साथ रिकॉर्ड करना चाहिए, ताकि 1000 हर्ट्ज़ पर 90 डीबी साउंड पावर लेवल (एसपीएल) सोर्स से 16-बिट सैंपल के लिए आरएमएस 2500 मिल सके.
• वॉइस रिकॉग्निशन ऑडियो स्ट्रीम को रिकॉर्ड करना चाहिए, ताकि PCM ऐम्प्ल्यट्यूड लेवल, इनपुट एसपीएल में होने वाले बदलावों को कम से कम 30 डीबी की रेंज में, माइक्रोफ़ोन पर -18 डीबी से +12 डीबी तक के एसपीएल में ट्रैक कर सके.
• माइक्रोफ़ोन पर 90 dB SPL इनपुट लेवल पर, 1 kHz के लिए कुल हार्मोनिक डिस्टॉर्शन (THD) 1% से कम होने पर, वॉइस रिकॉग्निशन ऑडियो स्ट्रीम रिकॉर्ड होनी चाहिए.

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

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

5.4.3. वीडियो चलाने के लिए, स्क्रीन कैप्चर करना

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

अगर डिवाइस पर लागू किए गए एपीआई, android.hardware.audio.output और android.hardware.microphone, दोनों का एलान करते हैं, तो:

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

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

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

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

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

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

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

5.4.5. एक साथ कई स्क्रीन कैप्चर करना

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

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

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

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

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

5.5. ऑडियो प्लेबैक

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

5.5.1. रॉ ऑडियो चलाना

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

• [C-1-1] यह ज़रूरी है कि रॉ ऑडियो कॉन्टेंट को इन सुविधाओं के साथ चलाया जा सके:

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

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

  • सैंपलिंग रेट: 24,000

5.5.2. ऑडियो इफ़ेक्ट

डिवाइस पर लागू करने के लिए, Android ऑडियो इफ़ेक्ट के लिए एपीआई उपलब्ध कराता है.

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

• [C-1-1] EFFECT_TYPE_EQUALIZER और EFFECT_TYPE_LOUDNESS_ENHANCER को लागू करने की सुविधा होनी चाहिए. इन्हें AudioEffect के सबक्लास Equalizer और LoudnessEnhancer की मदद से कंट्रोल किया जा सकता है.
• [C-1-2] विज़ुअलाइज़र एपीआई को लागू करने की सुविधा होनी चाहिए. इसे Visualizer क्लास की मदद से कंट्रोल किया जा सकता है.
• [C-1-3] यह ज़रूरी है कि EFFECT_TYPE_DYNAMICS_PROCESSING को लागू करने की सुविधा, AudioEffect सबक्लास DynamicsProcessing की मदद से कंट्रोल की जा सके.
• EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB, और EFFECT_TYPE_VIRTUALIZER को लागू करने की सुविधा होनी चाहिए. इन्हें AudioEffect सब-क्लास BassBoost, EnvironmentalReverb, PresetReverb, और Virtualizer की मदद से कंट्रोल किया जा सकता है.
• [C-SR] हमारा सुझाव है कि फ़्लोटिंग-पॉइंट और मल्टीचैनल में इफ़ेक्ट इस्तेमाल करें.

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

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

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

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

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

इस सेक्शन के लिए, इन परिभाषाओं का इस्तेमाल करें:

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

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

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

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

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

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

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

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

• [C-2-1] कम इंतज़ार वाले ऑडियो की सुविधा के काम करने की जानकारी नहीं दी जानी चाहिए.

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

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

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

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

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

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

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

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

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

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

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

आरटीएसपी (आरटीपी, एसडीपी)

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] एमआईडीआई की सुविधा वाले सभी हार्डवेयर ट्रांसपोर्ट पर एमआईडीआई की सुविधा काम करनी चाहिए. इसके लिए, वे सामान्य गैर-एमआईडीआई कनेक्टिविटी उपलब्ध कराते हैं. ये ट्रांसपोर्ट ये हैं:

  • यूएसबी होस्ट मोड, सेक्शन 7.7
  • यूएसबी पेरिफ़रल मोड, सेक्शन 7.7
  • ब्लूटूथ LE पर MIDI, मुख्य भूमिका में काम कर रहा है, सेक्शन 7.4.3

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

• [C-1-3] इसमें libamidi.so (नेटिव MIDI सपोर्ट) शामिल होना चाहिए

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

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

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

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

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

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

• [SR] हमारा सुझाव है कि android.content.pm.PackageManager क्लास की मदद से, android.hardware.audio.pro सुविधा के लिए सहायता की शिकायत करें.

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

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

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

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

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

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

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

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

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

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

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

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

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

• [C-1-5] ऑडियो इनपुट की संवेदनशीलता को इस तरह सेट करना ज़रूरी है कि 94 डीबी साउंड प्रेशर लेवल (एसपीएल) पर चलाया गया 1,000 हर्ट्ज़ का साइनसोइडल टोन सोर्स, 16-बिट सैंपल के लिए 520 आरएमएस (या फ़्लोटिंग पॉइंट/डबल प्रिसीज़न सैंपल के लिए -36 डीबी फ़ुल स्केल) का रिस्पॉन्स दे. यह रिस्पॉन्स, बिना प्रोसेस किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन के लिए होना चाहिए.

• [C-1-6] बिना प्रोसेस किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन का सिग्नल-टू-नॉइज़ रेशियो (एसएनआर) 60 डीबी या उससे ज़्यादा होना चाहिए. (जबकि एसएनआर को 94 डीबी एसपीएल और सेल्फ़ नॉइज़ के बराबर एसपीएल, A-वज़्ड के बीच के अंतर के तौर पर मेज़र किया जाता है).

• [C-1-7] बिना प्रोसेस किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन में, 90 dB SPL इनपुट लेवल पर 1 kHz के लिए, कुल हार्मोनिक डिस्टॉर्शन (THD) 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 डीबग ब्रिज (adb)

  • [C-0-2] Android SDK और AOSP में दिए गए शेल कमांड के मुताबिक, adb के साथ काम करना चाहिए. इन कमांड का इस्तेमाल ऐप्लिकेशन डेवलपर कर सकते हैं. इनमें dumpsys cmd stats भी शामिल है
  • [C-SR] हमारा सुझाव है कि आप शेल कमांड cmd testharness का इस्तेमाल करें.
  • [C-0-3] dumpsys कमांड की मदद से लॉग किए गए डिवाइस के सिस्टम इवेंट (batterystats , diskstats, fingerprint, graphicsstats, netstats, notification, procstats) के फ़ॉर्मैट या कॉन्टेंट में बदलाव नहीं किया जाना चाहिए.
  • [C-0-10] इवेंट को बिना किसी छूट के रिकॉर्ड करना ज़रूरी है. साथ ही, इन इवेंट को cmd stats शेल कमांड और StatsManager सिस्टम एपीआई क्लास के लिए ऐक्सेस और उपलब्ध कराना ज़रूरी है.
    • ActivityForegroundStateChanged
    • AnomalyDetected
    • AppBreadcrumbReported
    • AppCrashOccurred
    • AppStartOccurred
    • BatteryLevelChanged
    • BatterySaverModeStateChanged
    • BleScanResultReceived
    • BleScanStateChanged
    • ChargingStateChanged
    • DeviceIdleModeStateChanged
    • ForegroundServiceStateChanged
    • GpsScanStateChanged
    • JobStateChanged
    • PluggedStateChanged
    • ScheduledJobStateChanged
    • ScreenStateChanged
    • SyncStateChanged
    • SystemElapsedRealtime
    • UidProcessStateChanged
    • WakelockStateChanged
    • WakeupAlarmOccurred
    • WifiLockStateChanged
    • WifiMulticastLockStateChanged
    • WifiScanStateChanged
  • [C-0-4] डिवाइस पर adb डेमन, डिफ़ॉल्ट रूप से बंद होना चाहिए. साथ ही, Android Debug Bridge को चालू करने के लिए, उपयोगकर्ता के पास कोई ऐसा तरीका होना चाहिए जिसका इस्तेमाल किया जा सके.
  • [C-0-5] यह ज़रूरी है कि यह सुरक्षित adb के साथ काम करे. Android में सुरक्षित adb के लिए सहायता शामिल है. Secure adb, पुष्टि किए गए होस्ट पर adb को चालू करता है.

  • [C-0-6] होस्ट मशीन से adb को कनेक्ट करने की सुविधा देने वाला कोई तरीका ज़रूर उपलब्ध कराएं. उदाहरण के लिए:

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

• Dalvik डीबग मॉनिटर सेवा (ddms)

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

• Perfetto

  • [C-SR] हमारा सुझाव है कि शेल उपयोगकर्ता को /system/bin/perfetto बाइनरी दिखाएं, जो perfetto दस्तावेज़ के मुताबिक cmdline का पालन करती हो.
  • [C-SR] हमारा सुझाव है कि perfetto बाइनरी, इनपुट के तौर पर protobuf कॉन्फ़िगरेशन स्वीकार करे. यह कॉन्फ़िगरेशन, perfetto दस्तावेज़ में बताए गए स्कीमा के मुताबिक होना चाहिए.
  • [C-SR] हमारा सुझाव है कि आप perfetto दस्तावेज़ में बताए गए स्कीमा के मुताबिक, आउटपुट के तौर पर protobuf ट्रेस लिखें.
  • [C-SR] हमारा सुझाव है कि आप perfetto बाइनरी के ज़रिए, कम से कम वे डेटा सोर्स दें जिनके बारे में perfetto दस्तावेज़ में बताया गया है.

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

  अगर डिवाइस पर शेल कमांड cmd testharness काम करता है और cmd testharness enable चलाया जा सकता है, तो:

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

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

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

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

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

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

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

7. हार्डवेयर के साथ काम करना

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

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

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

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

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

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

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

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

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

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

7.1.1.1. स्क्रीन का साइज़ और आकार

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

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

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

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

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

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

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

7.1.1.2. स्क्रीन का आसपेक्ट रेशियो

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

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

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

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

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

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

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

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

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

• डिवाइस के लागू होने पर, Android फ़्रेमवर्क की स्टैंडर्ड डेंसिटी तय की जानी चाहिए, जो संख्या के हिसाब से स्क्रीन की फ़िज़िकल डेंसिटी के सबसे करीब हो. हालांकि, ऐसा तब तक नहीं किया जाना चाहिए, जब तक कि लॉजिकल डेंसिटी, रिपोर्ट की गई स्क्रीन के साइज़ को काम करने वाले सबसे छोटे साइज़ से कम न कर दे. अगर Android फ़्रेमवर्क की स्टैंडर्ड सघनता, स्क्रीन के फ़िज़िकल सघनता के सबसे करीब होती है, तो उस स्क्रीन का साइज़, स्क्रीन के सबसे छोटे साइज़ (320 dp की चौड़ाई) से कम होता है. ऐसे में, Android फ़्रेमवर्क की डेंसिटी के हिसाब से, डिवाइस को लागू करने की प्रोसेस के अगले सबसे कम स्टैंडर्ड 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. डिसप्ले मेट्रिक

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

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

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

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

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

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

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

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

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

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

7.1.4.1 OpenGL ES

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

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

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

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

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

• [C-2-1] ऐप्लिकेशन में लागू किए गए किसी भी अन्य OpenGL ES एक्सटेंशन की रिपोर्ट, OpenGL ES मैनेज किए जाने वाले एपीआई और नेटिव एपीआई के ज़रिए दी जानी चाहिए. इसके अलावा, ऐसे एक्सटेंशन की रिपोर्ट नहीं दी जानी चाहिए जिनके साथ ऐप्लिकेशन काम नहीं करता.
• [C-2-2] यह EGL_KHR_image, EGL_KHR_image_base, EGL_ANDROID_image_native_buffer, EGL_ANDROID_get_native_client_buffer, EGL_KHR_wait_sync, EGL_KHR_get_all_proc_addresses, EGL_ANDROID_presentation_time, EGL_KHR_swap_buffers_with_damage, EGL_ANDROID_recordable, और EGL_ANDROID_GLES_layers एक्सटेंशन के साथ काम करना चाहिए.
• [C-SR] हमारा सुझाव है कि आप EGL_KHR_partial_update और OES_EGL_image_external एक्सटेंशन का इस्तेमाल करें.
• getString() तरीके से, टेक्सचर कंप्रेस करने के हर उस फ़ॉर्मैट की सटीक जानकारी देनी चाहिए जिसका इस्तेमाल किया जा सकता है. आम तौर पर, यह जानकारी वेंडर के हिसाब से अलग-अलग होती है.

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

• [C-3-1] libGLESv2.so लाइब्रेरी में मौजूद OpenGL ES 2.0 फ़ंक्शन सिंबल के अलावा, इन वर्शन के लिए भी फ़ंक्शन सिंबल एक्सपोर्ट करने होंगे.
• [SR] हमारा सुझाव है कि आप OES_EGL_image_external_essl3 एक्सटेंशन का इस्तेमाल करें.

अगर डिवाइस पर OpenGL ES 3.2 वर्शन काम करता है, तो:

• [C-4-1] यह ज़रूरी है कि ऐप्लिकेशन, OpenGL ES Android एक्सटेंशन पैक के सभी वर्शन के साथ काम करे.

अगर डिवाइस पर OpenGL ES Android एक्सटेंशन पैक पूरी तरह से काम करता है, तो:

• [C-5-1] android.hardware.opengles.aep सुविधा फ़्लैग की मदद से, सहायता की पहचान करना ज़रूरी है.

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

• [C-6-1] यह EGL_ANDROID_front_buffer_auto_refresh एक्सटेंशन के साथ भी काम करना चाहिए.

7.1.4.2 Vulkan

Android में Vulkan की सुविधा शामिल है. यह कम ओवरहेड वाला क्रॉस-प्लैटफ़ॉर्म एपीआई है, जो बेहतर परफ़ॉर्मेंस वाले 3D ग्राफ़िक के लिए इस्तेमाल किया जाता है.

अगर डिवाइस पर OpenGL ES 3.1 काम करता है, तो:

• [SR] हमारा सुझाव है कि आप Vulkan 1.1 के साथ काम करने की सुविधा शामिल करें.

अगर डिवाइस में स्क्रीन या वीडियो आउटपुट शामिल है, तो:

• इसमें Vulkan 1.1 के लिए सहायता शामिल होनी चाहिए.

अगर डिवाइस में Vulkan 1.0 की सुविधा शामिल है, तो:

• [C-1-1] android.hardware.vulkan.level और android.hardware.vulkan.version सुविधा फ़्लैग के साथ, सही पूर्णांक वैल्यू की रिपोर्ट करनी चाहिए.
• [C-1-2] Vulkan नेटिव एपीआई vkEnumeratePhysicalDevices() के लिए, कम से कम एक VkPhysicalDevice एट्रिब्यूट की वैल्यू देना ज़रूरी है .
• [C-1-3] सूची में शामिल हर VkPhysicalDevice के लिए, Vulkan 1.0 एपीआई को पूरी तरह से लागू करना ज़रूरी है.
• [C-1-4] ऐप्लिकेशन पैकेज की नेटिव लाइब्रेरी डायरेक्ट्री में, libVkLayer*.so नाम की नेटिव लाइब्रेरी में मौजूद लेयर की सूची बनाना ज़रूरी है. इसके लिए, Vulkan नेटिव एपीआई vkEnumerateInstanceLayerProperties() और vkEnumerateDeviceLayerProperties() का इस्तेमाल करें.
• [C-1-5] ऐप्लिकेशन पैकेज के बाहर मौजूद लाइब्रेरी से मिलने वाली लेयर की सूची नहीं दी जानी चाहिए. इसके अलावा, Vulkan API को ट्रैक करने या उसे इंटरसेप्ट करने के अन्य तरीके भी नहीं दिए जाने चाहिए. ऐसा तब तक नहीं किया जाना चाहिए, जब तक ऐप्लिकेशन में android:debuggable एट्रिब्यूट को true के तौर पर सेट न किया गया हो.
• [C-1-6] ऐप्लिकेशन को उन सभी एक्सटेंशन स्ट्रिंग की जानकारी देनी होगी जो Vulkan नेटिव एपीआई के ज़रिए काम करती हैं. इसके अलावा , उन एक्सटेंशन स्ट्रिंग की जानकारी नहीं देनी चाहिए जो सही तरीके से काम नहीं करती हैं.
• [C-1-7] यह VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, और VK_KHR_incremental_present एक्सटेंशन के साथ काम करना चाहिए.
• [C-SR] VK_KHR_driver_properties और VK_GOOGLE_display_timing एक्सटेंशन के साथ काम करने का ज़रूर सुझाव दिया जाता है.

अगर डिवाइस में Vulkan 1.0 का इस्तेमाल नहीं किया जा सकता, तो:

• [C-2-1] Vulkan के किसी भी फ़ीचर फ़्लैग (जैसे, android.hardware.vulkan.level, android.hardware.vulkan.version) का एलान नहीं किया जाना चाहिए.
• [C-2-2] Vulkan नेटिव एपीआई vkEnumeratePhysicalDevices() के लिए, किसी भी VkPhysicalDevice को एनोटेट नहीं किया जाना चाहिए.

अगर डिवाइस में Vulkan 1.1 का इस्तेमाल किया जा रहा है और Vulkan की किसी सुविधा के फ़्लैग का एलान किया गया है, तो:

• [C-3-1] SYNC_FD एक्सटर्नल सिग्नल और हैंडल टाइप और VK_ANDROID_external_memory_android_hardware_buffer एक्सटेंशन के लिए, सहायता उपलब्ध कराना ज़रूरी है.

7.1.4.3 RenderScript

• [C-0-1] डिवाइस पर Android RenderScript काम करना चाहिए. इस बारे में Android SDK के दस्तावेज़ में बताया गया है.

7.1.4.4 2D ग्राफ़िक एक्सेलरेशन

Android में एक ऐसा तरीका शामिल है जिससे ऐप्लिकेशन यह बता सकते हैं कि उन्हें ऐप्लिकेशन, गतिविधि, विंडो या व्यू लेवल पर, 2D ग्राफ़िक्स के लिए हार्डवेयर ऐक्सेलरेशन की सुविधा चालू करनी है. इसके लिए, उन्हें मेनिफ़ेस्ट टैग android:hardwareAccelerated या सीधे तौर पर एपीआई कॉल का इस्तेमाल करना होगा.

डिवाइस पर लागू करने के तरीके:

• [C-0-1] हार्डवेयर से तेज़ी लाने की सुविधा को डिफ़ॉल्ट रूप से चालू करना ज़रूरी है. अगर डेवलपर ने android:hardwareAccelerated="false” को सेट करके या सीधे Android View API के ज़रिए हार्डवेयर से तेज़ी लाने की सुविधा को बंद करने का अनुरोध किया है, तो उसे बंद करना ज़रूरी है.
• [C-0-2] हार्डवेयर से तेज़ी लाने की सुविधा के लिए, Android SDK टूल के दस्तावेज़ में बताए गए तरीके के मुताबिक काम करना चाहिए.

Android में TextureView ऑब्जेक्ट शामिल होता है. इसकी मदद से, डेवलपर सीधे तौर पर हार्डवेयर से तेज़ किए गए OpenGL ES टेक्स्चर को यूज़र इंटरफ़ेस (यूआई) के लेआउट में रेंडरिंग टारगेट के तौर पर इंटिग्रेट कर सकते हैं.

डिवाइस पर लागू करने के तरीके:

• [C-0-3] यह ज़रूरी है कि यह TextureView API के साथ काम करे. साथ ही, यह Android के अपस्ट्रीम वर्शन के साथ एक जैसा व्यवहार करे.

7.1.4.5 वाइड-गैमेट डिसप्ले

अगर डिवाइस में Configuration.isScreenWideColorGamut() की मदद से वाइड-गैमेट डिसप्ले के साथ काम करने की सुविधा का दावा किया जाता है , तो:

• [C-1-1] डिसप्ले का कलर कैलिब्रेट किया गया होना चाहिए.
• [C-1-2] डिसप्ले का गैमट, CIE 1931 xyY स्पेस में sRGB कलर गैमट को पूरी तरह कवर करता हो.
• [C-1-3] डिसप्ले का गैमट, CIE 1931 xyY स्पेस में DCI-P3 के कम से कम 90% हिस्से के बराबर होना चाहिए.
• [C-1-4] यह ज़रूरी है कि ऐप्लिकेशन, OpenGL ES 3.1 या 3.2 के साथ काम करे और इसकी सही तरीके से शिकायत करे.
• [C-1-5] EGL_KHR_no_config_context, EGL_EXT_pixel_format_float, EGL_KHR_gl_colorspace, EGL_EXT_gl_colorspace_scrgb, EGL_EXT_gl_colorspace_scrgb_linear, EGL_EXT_gl_colorspace_display_p3, EGL_EXT_gl_colorspace_display_p3_linear, और EGL_EXT_gl_colorspace_display_p3_passthrough एक्सटेंशन के लिए सहायता का विज्ञापन दिखाना ज़रूरी है.
• [C-SR] GL_EXT_sRGB के साथ काम करने का ज़रूर सुझाव दिया जाता है.

इसके उलट, अगर डिवाइस पर लागू किए गए एलिमेंट, वाइड-गैमेट डिसप्ले के साथ काम नहीं करते, तो:

• [C-2-1] CIE 1931 xyY स्पेस में sRGB का 100% या उससे ज़्यादा हिस्सा कवर करना चाहिए. हालांकि, स्क्रीन का कलर गैमट तय नहीं है.

7.1.5. लेगसी ऐप्लिकेशन के साथ काम करने वाला मोड

Android में “कंपैटिबिलिटी मोड” की सुविधा होती है. इसमें फ़्रेमवर्क, स्क्रीन साइज़ के हिसाब से 'सामान्य' (320dp चौड़ाई) मोड में काम करता है. इससे उन लेगसी ऐप्लिकेशन को फ़ायदा मिलता है जिन्हें Android के पुराने वर्शन के लिए डेवलप नहीं किया गया था. ये ऐसे वर्शन हैं जो स्क्रीन साइज़ के हिसाब से काम करने की सुविधा से पहले के हैं.

7.1.6. स्क्रीन की टेक्नोलॉजी

Android प्लैटफ़ॉर्म में ऐसे एपीआई शामिल हैं जिनकी मदद से ऐप्लिकेशन, Android के साथ काम करने वाले डिसप्ले पर बेहतरीन ग्राफ़िक रेंडर कर सकते हैं. डिवाइसों में, Android SDK टूल में बताए गए इन सभी एपीआई का काम करना ज़रूरी है. ऐसा तब तक करना होगा, जब तक इस दस्तावेज़ में खास तौर पर अनुमति न दी गई हो.

किसी डिवाइस पर लागू किए गए Android के साथ काम करने वाले सभी डिसप्ले:

• [C-0-1] यह 16-बिट कलर ग्राफ़िक रेंडर करने में सक्षम होना चाहिए.
• यह 24-बिट कलर ग्राफ़िक्स वाले डिसप्ले के साथ काम करना चाहिए.
• [C-0-2] ऐनिमेशन रेंडर करने की सुविधा होनी चाहिए.
• [C-0-3] पिक्सल आसपेक्ट रेशियो (PAR) 0.9 से 1.15 के बीच होना चाहिए. इसका मतलब है कि पिक्सल का आसपेक्ट रेशियो, स्क्वेयर (1.0) के आस-पास होना चाहिए. इसमें 10 से 15% तक का अंतर हो सकता है.

7.1.7. दूसरे डिसप्ले

Android में, Android के साथ काम करने वाले सेकंडरी डिसप्ले के लिए सहायता शामिल है. इससे, मीडिया शेयर करने की सुविधाएं चालू की जा सकती हैं. साथ ही, बाहरी डिसप्ले को ऐक्सेस करने के लिए, डेवलपर एपीआई का इस्तेमाल किया जा सकता है.

अगर डिवाइस में वायर, वायरलेस या एम्बेड किए गए अतिरिक्त डिसप्ले कनेक्शन के ज़रिए, बाहरी डिसप्ले से कनेक्ट करने की सुविधा है, तो:

• [C-1-1] Android SDK टूल के दस्तावेज़ में बताए गए तरीके के मुताबिक, DisplayManager सिस्टम सेवा और एपीआई को लागू करना ज़रूरी है.

7.2. इनपुट डिवाइस

डिवाइस पर लागू करने के तरीके:

• [C-0-1] यूज़र इंटरफ़ेस (यूआई) एलिमेंट के बीच नेविगेट करने के लिए, इसमें इनपुट मैकेनिज्म होना चाहिए. जैसे, टचस्क्रीन या नॉन-टच नेविगेशन.

7.2.1. कीबोर्ड

अगर डिवाइस में तीसरे पक्ष के इनपुट के तरीके के संपादक (आईएमई) वाले ऐप्लिकेशन के लिए सहायता शामिल है, तो:

• [C-1-1] android.software.input_methods फ़ीचर फ़्लैग का एलान करना ज़रूरी है.
• [C-1-2] इसे पूरी तरह से लागू करना ज़रूरी है Input Management Framework
• [C-1-3] डिवाइस में पहले से इंस्टॉल किया गया सॉफ़्टवेयर कीबोर्ड होना चाहिए.

डिवाइस पर लागू करने के लिए: * [C-0-1] डिवाइस में ऐसा हार्डवेयर कीबोर्ड नहीं होना चाहिए जो android.content.res.Configuration.keyboard में बताए गए फ़ॉर्मैट (QWERTY या 12-key) से मेल न खाता हो. * इसमें अन्य सॉफ़्ट कीबोर्ड लागू करने की जानकारी शामिल होनी चाहिए. * इसमें हार्डवेयर कीबोर्ड शामिल हो सकता है.

7.2.2. बिना छुए नेविगेट करने की सुविधा

Android में टच किए बिना नेविगेट करने के लिए, डी-पैड, ट्रैकबॉल, और व्हील की सुविधा शामिल है.

डिवाइस पर लागू करने के तरीके:

• [C-0-1] android.content.res.Configuration.navigation के लिए सही वैल्यू रिपोर्ट करना ज़रूरी है.

अगर डिवाइस में बिना छुए नेविगेट करने की सुविधा नहीं है, तो:

• [C-1-1] टेक्स्ट चुनने और उसमें बदलाव करने के लिए, यूज़र इंटरफ़ेस का कोई ऐसा विकल्प देना ज़रूरी है जो इनपुट मैनेजमेंट इंजन के साथ काम करता हो. Android के ओपन सोर्स को अपस्ट्रीम करने के तरीके में, डिवाइसों के लिए चुनने का एक तरीका शामिल है. यह तरीका उन डिवाइसों के साथ इस्तेमाल करने के लिए सही है जिनमें टच-पैनल के अलावा नेविगेशन इनपुट की सुविधा नहीं होती.

7.2.3. मार्गदर्शक कुंजियां

होम, हाल ही के, और वापस जाएं फ़ंक्शन, आम तौर पर किसी खास बटन या टच स्क्रीन के किसी खास हिस्से के इंटरैक्शन से मिलते हैं. ये फ़ंक्शन, Android नेविगेशन पैराडाइम और इसलिए, डिवाइस पर लागू करने के लिए ज़रूरी हैं:

• [C-0-1] आपको उपयोगकर्ताओं को ऐसे इंस्टॉल किए गए ऐप्लिकेशन लॉन्च करने की सुविधा देनी होगी जिनमें <intent-filter> गतिविधि, ACTION=MAIN और CATEGORY=LAUNCHER या CATEGORY=LEANBACK_LAUNCHER के साथ सेट हो. यह सुविधा, टेलिविज़न डिवाइस पर लागू की जानी चाहिए. होम फ़ंक्शन, इस उपयोगकर्ता के लिए उपलब्ध सुविधा के तौर पर काम करना चाहिए.
• हाल ही में इस्तेमाल किए गए आइटम और 'वापस जाएं' फ़ंक्शन के लिए बटन होने चाहिए.

अगर होम, हाल ही में इस्तेमाल किए गए आइटम या वापस जाने के फ़ंक्शन उपलब्ध हैं, तो:

• [C-1-1] जब इनमें से कोई भी ऐक्सेस किया जा सकता है, तो उसे एक ही कार्रवाई (जैसे, टैप, डबल-क्लिक या जेस्चर) से ऐक्सेस किया जा सकता है.
• [C-1-2] यह साफ़ तौर पर बताया जाना चाहिए कि हर फ़ंक्शन को कौनसी एक कार्रवाई ट्रिगर करेगी. बटन पर कोई आइकॉन दिखना, स्क्रीन के नेविगेशन बार पर कोई सॉफ़्टवेयर आइकॉन दिखना या डिवाइस के साथ मिलने वाले सेटअप के दौरान, उपयोगकर्ता को सिलसिलेवार निर्देशों के साथ डेमो फ़्लो दिखाना, ऐसे संकेत के उदाहरण हैं.

डिवाइस पर लागू करने के तरीके:

• [SR] को मेन्यू फ़ंक्शन के लिए इनपुट मैकेनिज्म न देने का सुझाव दिया जाता है, क्योंकि Android 4.0 के बाद से इसे ऐक्शन बार के पक्ष में बंद कर दिया गया है.

अगर डिवाइस में मेन्यू फ़ंक्शन उपलब्ध है, तो:

• [C-2-1] जब ऐक्शन ओवरफ़्लो मेन्यू पॉप-अप खाली न हो और ऐक्शन बार दिख रहा हो, तब ऐक्शन ओवरफ़्लो बटन दिखाना ज़रूरी है.
• [C-2-2] ऐक्शन बार में मौजूद ओवरफ़्लो बटन को चुनकर दिखाए गए ऐक्शन ओवरफ़्लो पॉप-अप की पोज़िशन में बदलाव नहीं किया जाना चाहिए. हालांकि, मेन्यू फ़ंक्शन को चुनकर दिखाए जाने पर, ऐक्शन ओवरफ़्लो पॉप-अप को स्क्रीन पर बदली गई पोज़िशन पर रेंडर किया जा सकता है.

अगर डिवाइस में मेन्यू फ़ंक्शन उपलब्ध नहीं है, तो पुराने वर्शन के साथ काम करने के लिए: * [C-SR] हमारा सुझाव है कि targetSdkVersion के 10 से कम होने पर, ऐप्लिकेशन के लिए मेन्यू फ़ंक्शन उपलब्ध कराएं. इसके लिए, किसी फ़िज़िकल बटन, सॉफ़्टवेयर बटन या जेस्चर का इस्तेमाल करें. इस मेन्यू फ़ंक्शन को तब तक ऐक्सेस किया जा सकता है, जब तक इसे नेविगेशन के अन्य फ़ंक्शन के साथ छिपाया नहीं जाता.

अगर डिवाइस में Assist फ़ंक्शन उपलब्ध है, तो:

• [C-4-1] अन्य नेविगेशन बटन ऐक्सेस किए जा सकने पर, यह ज़रूरी है कि Assist फ़ंक्शन को सिर्फ़ एक ऐक्शन (जैसे, टैप, डबल-क्लिक या जेस्चर) से ऐक्सेस किया जा सके.
• [SR] हमारा सुझाव है कि इस इंटरैक्शन के लिए, होम बटन को दबाकर रखने की सुविधा का इस्तेमाल करें.

अगर डिवाइस में नेविगेशन बटन दिखाने के लिए, स्क्रीन के किसी खास हिस्से का इस्तेमाल किया जाता है, तो:

• [C-5-1] नेविगेशन बटन, स्क्रीन के किसी ऐसे हिस्से पर होने चाहिए जो ऐप्लिकेशन के लिए उपलब्ध न हो. साथ ही, यह ज़रूरी है कि वे ऐप्लिकेशन के लिए उपलब्ध स्क्रीन के हिस्से को छिपाएं या उसमें रुकावट न डालें.
• [C-5-2] डिसप्ले का एक हिस्सा, उन ऐप्लिकेशन के लिए उपलब्ध कराना ज़रूरी है जो सेक्शन 7.1.1 में बताई गई ज़रूरी शर्तों को पूरा करते हैं.
• [C-5-3] ऐप्लिकेशन को View.setSystemUiVisibility() एपीआई के ज़रिए सेट किए गए फ़्लैग का पालन करना चाहिए, ताकि स्क्रीन का यह खास हिस्सा (जिसे नेविगेशन बार भी कहा जाता है) SDK टूल में बताए गए तरीके से सही तरीके से छिपा रहे.

अगर नेविगेशन फ़ंक्शन, स्क्रीन पर जेस्चर के आधार पर ऐक्शन के तौर पर दिया गया है, तो:

• [C-6-1] WindowInsets#getMandatorySystemGestureInsets() का इस्तेमाल सिर्फ़ होम जेस्चर की पहचान करने वाले एरिया की रिपोर्टिंग के लिए किया जाना चाहिए.
• [C-6-2] फ़ोरग्राउंड ऐप्लिकेशन के View#setSystemGestureExclusionRects() से दिए गए एक्सक्लूज़न रेक्ट में शुरू होने वाले, लेकिन WindowInsets#getMandatorySystemGestureInsets() से बाहर के जेस्चर को नेविगेशन फ़ंक्शन के लिए इंटरसेप्ट नहीं किया जाना चाहिए. ऐसा तब तक नहीं किया जाना चाहिए, जब तक एक्सक्लूज़न रेक्ट को View#setSystemGestureExclusionRects() के दस्तावेज़ में बताई गई एक्सक्लूज़न की ज़्यादा से ज़्यादा सीमा के अंदर रखा जाता है.
• [C-6-3] अगर फ़ोरग्राउंड ऐप्लिकेशन को पहले MotionEvent.ACTION_DOWN इवेंट भेजा गया था, तो सिस्टम जेस्चर के लिए टच को इंटरसेप्ट करने के बाद, फ़ोरग्राउंड ऐप्लिकेशन को MotionEvent.ACTION_CANCEL इवेंट भेजना ज़रूरी है.
• [C-6-4] उपयोगकर्ता को ऑन-स्क्रीन, बटन पर आधारित नेविगेशन (उदाहरण के लिए, सेटिंग में) पर स्विच करने के लिए, उपयोगकर्ता के लिए सुविधा देना ज़रूरी है.
• होम फ़ंक्शन को स्क्रीन के मौजूदा ओरिएंटेशन के सबसे निचले हिस्से से ऊपर की ओर स्वाइप करके उपलब्ध कराया जाना चाहिए.
• हाल ही में इस्तेमाल किए गए ऐप्लिकेशन देखने की सुविधा, होम जेस्चर वाले सेक्शन में, ऊपर की ओर स्वाइप करके रिलीज़ करने से पहले होल्ड करने के तौर पर उपलब्ध होनी चाहिए.
• WindowInsets#getMandatorySystemGestureInsets() के अंदर शुरू होने वाले जेस्चर पर, View#setSystemGestureExclusionRects() के ज़रिए फ़ोरग्राउंड ऐप्लिकेशन से मिले एक्सक्लूज़न रेक्ट का असर नहीं पड़ना चाहिए.

अगर स्क्रीन के मौजूदा ओरिएंटेशन के बाएं और दाएं किनारों पर कहीं भी नेविगेशन फ़ंक्शन दिया गया है, तो:

• [C-7-1] नेविगेशन फ़ंक्शन, 'वापस जाएं' होना चाहिए. साथ ही, इसे स्क्रीन के मौजूदा ओरिएंटेशन के बाएं और दाएं किनारों से स्वाइप करके उपलब्ध कराया जाना चाहिए.
• [C-7-2] अगर बाईं या दाईं ओर स्वाइप किए जा सकने वाले कस्टम सिस्टम पैनल दिए गए हैं, तो उन्हें स्क्रीन के सबसे ऊपर 1/3 हिस्से में रखा जाना चाहिए. साथ ही, यह साफ़ तौर पर और लगातार दिखना चाहिए कि इन पैनल को खींचकर लाने के लिए, 'वापस जाएं' बटन का इस्तेमाल नहीं किया जा सकता. उपयोगकर्ता, सिस्टम पैनल को इस तरह कॉन्फ़िगर कर सकता है कि वह स्क्रीन के किनारे के एक तिहाई हिस्से के नीचे दिखे. हालांकि, सिस्टम पैनल के लिए किनारे के एक तिहाई हिस्से से ज़्यादा जगह का इस्तेमाल नहीं किया जाना चाहिए.
• [C-7-3] जब फ़ोरग्राउंड ऐप्लिकेशन में View.SYSTEM_UI_FLAG_IMMERSIVE या View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY फ़्लैग सेट हों, तो किनारों से स्वाइप करने पर, AOSP में लागू किए गए तरीके के मुताबिक काम करना चाहिए. इस तरीके के बारे में SDK टूल में बताया गया है.
• [C-7-4] जब फ़ोरग्राउंड ऐप्लिकेशन में View.SYSTEM_UI_FLAG_IMMERSIVE या View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY फ़्लैग सेट हों, तो स्वाइप किए जा सकने वाले कस्टम सिस्टम पैनल तब तक छिपे होने चाहिए, जब तक उपयोगकर्ता AOSP में लागू किए गए सिस्टम बार (जिसे नेविगेशन और स्टेटस बार भी कहा जाता है) को नहीं दिखाता.

7.2.4. टचस्क्रीन इनपुट

Android में कई तरह के पॉइंटर इनपुट सिस्टम काम करते हैं. जैसे, टचस्क्रीन, टच पैड, और फ़ेक टच इनपुट डिवाइस. टचस्क्रीन वाले डिवाइसों पर लागू होने वाले एक्सटेंशन, डिसप्ले से जुड़े होते हैं. इससे उपयोगकर्ता को ऐसा लगता है कि वह स्क्रीन पर मौजूद आइटम को सीधे तौर पर मैनेज कर रहा है. उपयोगकर्ता सीधे तौर पर स्क्रीन को छू रहा है. इसलिए, सिस्टम को उन ऑब्जेक्ट के बारे में बताने के लिए, किसी अन्य सुविधा की ज़रूरत नहीं होती जिनमें बदलाव किया जा रहा है.

डिवाइस पर लागू करने के तरीके:

• इसमें किसी तरह का पॉइंटर इनपुट सिस्टम (माउस जैसा या टच) होना चाहिए.
• यह पूरी तरह से स्वतंत्र रूप से ट्रैक किए गए पॉइंटर के साथ काम करना चाहिए.

अगर डिवाइस में टचस्क्रीन (सिंगल-टच या बेहतर) है, तो:

• [C-1-1] Configuration.touchscreen एपीआई फ़ील्ड के लिए, TOUCHSCREEN_FINGER की रिपोर्ट देना ज़रूरी है.
• [C-1-2] android.hardware.touchscreen और android.hardware.faketouch सुविधा फ़्लैग की रिपोर्ट करना ज़रूरी है.

अगर डिवाइस में एक से ज़्यादा टच को ट्रैक करने वाली टचस्क्रीन है, तो:

• [C-2-1] डिवाइस पर मौजूद टचस्क्रीन के टाइप के हिसाब से, फ़ीचर फ़्लैग android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct, android.hardware.touchscreen.multitouch.jazzhand की सही जानकारी देना ज़रूरी है.

अगर डिवाइस में टचस्क्रीन नहीं है और सिर्फ़ पॉइंटर डिवाइस का इस्तेमाल किया जाता है, तो सेक्शन 7.2.5 में बताई गई नकली टच की ज़रूरी शर्तें पूरी करने पर, ये डिवाइस:

• [C-3-1] android.hardware.touchscreen से शुरू होने वाले किसी भी फ़ीचर फ़्लैग को रिपोर्ट नहीं करना चाहिए. साथ ही, सिर्फ़ android.hardware.faketouch को रिपोर्ट करना चाहिए.

7.2.5. नकली टच इनपुट

नकली टच वाला इंटरफ़ेस, उपयोगकर्ता इनपुट सिस्टम उपलब्ध कराता है. यह टचस्क्रीन की सुविधाओं के सबसेट के बराबर होता है. उदाहरण के लिए, ऑन-स्क्रीन कर्सर को चलाने वाला माउस या रिमोट कंट्रोल, टच की सुविधा के करीब होता है. हालांकि, इसके लिए उपयोगकर्ता को पहले कर्सर को पॉइंट या फ़ोकस करना होता है और फिर क्लिक करना होता है. माउस, ट्रैकपैड, गायरो-आधारित एयर माउस, गायरो-पॉइंटर, जॉयस्टिक, और मल्टी-टच ट्रैकपैड जैसे कई इनपुट डिवाइसों पर, फ़ेक टच इंटरैक्शन की सुविधा काम कर सकती है. Android में, फ़ीचर कॉन्स्टेंट android.hardware.faketouch शामिल होता है. यह कॉन्स्टेंट, हाई-फ़िडेलिटी वाले ऐसे इनपुट डिवाइस से जुड़ा होता है जो टच (पॉइंटर पर आधारित) नहीं होता. जैसे, माउस या ट्रैकपैड. यह डिवाइस, टच पर आधारित इनपुट (जिसमें बुनियादी जेस्चर की सुविधा भी शामिल है) को सही तरीके से एमुलेट कर सकता है. साथ ही, यह बताता है कि डिवाइस, टचस्क्रीन की सुविधा के एमुलेट किए गए सबसेट के साथ काम करता है.

अगर डिवाइस में टचस्क्रीन नहीं है, लेकिन कोई ऐसा पॉइंटर इनपुट सिस्टम है जिसे उपलब्ध कराना है, तो:

• android.hardware.faketouch फ़ीचर फ़्लैग के साथ काम करने की जानकारी देनी चाहिए.

अगर डिवाइस पर android.hardware.faketouch की सुविधा काम करती है, तो:

• [C-1-1] पॉइंटर की जगह की स्क्रीन पर पूरी X और Y पोज़िशन की जानकारी देनी चाहिए. साथ ही, स्क्रीन पर विज़ुअल पॉइंटर दिखाना चाहिए.
• [C-1-2] टच इवेंट को उस ऐक्शन कोड के साथ रिपोर्ट करना ज़रूरी है जो पॉइंटर के स्क्रीन पर नीचे या ऊपर जाने पर होने वाले स्टेटस में बदलाव की जानकारी देता है.
• [C-1-3] यह ज़रूरी है कि स्क्रीन पर मौजूद किसी ऑब्जेक्ट पर कर्सर को नीचे और ऊपर ले जाने की सुविधा काम करे. इससे उपयोगकर्ता, स्क्रीन पर मौजूद किसी ऑब्जेक्ट पर टैप कर सकते हैं.
• [C-1-4] यह ज़रूरी है कि स्क्रीन पर किसी ऑब्जेक्ट पर, एक तय समयसीमा के अंदर पॉइंटर को नीचे, ऊपर, फिर नीचे और फिर ऊपर ले जाया जा सके. इससे उपयोगकर्ता, स्क्रीन पर किसी ऑब्जेक्ट पर डबल टैप करने की सुविधा का इस्तेमाल कर सकते हैं.
• [C-1-5] यह ज़रूरी है कि स्क्रीन पर किसी भी बिंदु पर कर्सर को दबाने के बाद, कर्सर को किसी भी अन्य बिंदु पर ले जाया जा सके. इसके बाद, कर्सर को ऊपर उठाया जा सके, ताकि उपयोगकर्ता टच ड्रैग की सुविधा का इस्तेमाल कर सकें.
• [C-1-6] ऐप्लिकेशन में पॉइंटर डाउन की सुविधा होनी चाहिए. इसके बाद, उपयोगकर्ताओं को स्क्रीन पर किसी ऑब्जेक्ट को तुरंत किसी दूसरी जगह ले जाने की अनुमति होनी चाहिए. इसके बाद, स्क्रीन पर पॉइंटर अप की सुविधा होनी चाहिए, ताकि उपयोगकर्ता स्क्रीन पर किसी ऑब्जेक्ट को फ़्लिंग कर सकें.
• [C-1-7] Configuration.touchscreen एपीआई फ़ील्ड के लिए, TOUCHSCREEN_NOTOUCH की रिपोर्ट देना ज़रूरी है.

अगर डिवाइस पर android.hardware.faketouch.multitouch.distinct की सुविधा काम करती है, तो:

• [C-2-1] android.hardware.faketouch के लिए सहायता उपलब्ध कराने का एलान करना ज़रूरी है.
• [C-2-2] यह ज़रूरी है कि यह दो या उससे ज़्यादा इंडिपेंडेंट पॉइंटर इनपुट की अलग-अलग ट्रैकिंग की सुविधा दे.

अगर डिवाइस पर android.hardware.faketouch.multitouch.jazzhand की सुविधा काम करती है, तो:

• [C-3-1] android.hardware.faketouch के लिए सहायता उपलब्ध कराने का एलान करना ज़रूरी है.
• [C-3-2] यह ज़रूरी है कि डिवाइस, पांच या उससे ज़्यादा पॉइंटर इनपुट को अलग-अलग ट्रैक कर सके.

7.2.6. गेम कंट्रोलर के लिए सहायता

7.2.6.1. बटन मैपिंग

अगर डिवाइस में android.hardware.gamepad सुविधा फ़्लैग का एलान किया जाता है, तो:

• [C-1-1] डिवाइस में कंट्रोलर को एम्बेड करना ज़रूरी है या बॉक्स में अलग से कंट्रोलर देना ज़रूरी है. इससे, नीचे दी गई टेबल में दिए गए सभी इवेंट को इनपुट करने का तरीका मिलता है.
• [C-1-2] यह ज़रूरी है कि HID इवेंट को, उनसे जुड़े Android view.InputEvent कॉन्स्टेंट से मैप किया जा सके, जैसा कि नीचे दी गई टेबल में बताया गया है. Android के अपस्ट्रीम वर्शन में, इस ज़रूरी शर्त को पूरा करने वाले गेम कंट्रोलर के लिए भी यह सुविधा लागू की गई है.

1 KeyEvent

2 ऊपर बताए गए एचआईडी के इस्तेमाल की जानकारी, गेम पैड सीए (0x01 0x0005) में ज़रूर दी जानी चाहिए.

3 इस इस्तेमाल में, लॉजिकल तौर पर कम से कम 0 और ज़्यादा से ज़्यादा 7, फ़िज़िकल तौर पर कम से कम 0 और ज़्यादा से ज़्यादा 315, यूनिट डिग्री में, और रिपोर्ट का साइज़ 4 होना चाहिए. लॉजिकल वैल्यू को वर्टिकल ऐक्सिस से दूर, घड़ी की सुई के घूमने की दिशा में रोटेशन के तौर पर तय किया जाता है. उदाहरण के लिए, लॉजिकल वैल्यू 0 का मतलब है कि कोई रोटेशन नहीं हुआ है और अप बटन दबाया गया है. वहीं, लॉजिकल वैल्यू 1 का मतलब है कि 45 डिग्री का रोटेशन हुआ है और अप और लेफ़्ट बटन, दोनों दबाए गए हैं.

4 MotionEvent

एक MotionEvent

7.2.7. रिमोट कंट्रोल

डिवाइस के हिसाब से ज़रूरी शर्तों के बारे में जानने के लिए, सेक्शन 2.3.1 देखें.

7.3. सेंसर

अगर डिवाइस में किसी खास तरह का सेंसर लागू किया गया है, जिसके लिए तीसरे पक्ष के डेवलपर के पास एपीआई है, तो डिवाइस में उस एपीआई को लागू करना ज़रूरी है. इसके लिए, Android SDK टूल के दस्तावेज़ और सेंसर के बारे में Android के ओपन सोर्स दस्तावेज़ में दिया गया तरीका अपनाएं.

डिवाइस पर लागू करने के तरीके:

• [C-0-1] android.content.pm.PackageManager क्लास के हिसाब से, सेंसर की मौजूदगी या अनुपस्थिति की सटीक जानकारी देनी चाहिए.
• [C-0-2] SensorManager.getSensorList() और मिलते-जुलते तरीकों की मदद से, काम करने वाले सेंसर की सटीक सूची दिखानी ज़रूरी है.
• [C-0-3] अन्य सभी सेंसर एपीआई के लिए, यह एपीआई सही तरीके से काम करना चाहिए. उदाहरण के लिए, जब ऐप्लिकेशन, लिसनर रजिस्टर करने की कोशिश करते हैं, तो true या false को सही तरीके से दिखाना चाहिए. साथ ही, जब संबंधित सेंसर मौजूद न हों, तो सेंसर लिसनर को कॉल नहीं करना चाहिए.

अगर डिवाइस में किसी खास तरह का सेंसर शामिल है, जिसके लिए तीसरे पक्ष के डेवलपर के पास एपीआई है, तो वे:

• [C-1-1] Android SDK टूल के दस्तावेज़ में बताए गए हर सेंसर टाइप के लिए, सभी सेंसर मेज़रमेंट की रिपोर्ट देनी ज़रूरी है. इसके लिए, इंटरनैशनल सिस्टम ऑफ़ यूनिट (मेट्रिक) की सही वैल्यू का इस्तेमाल करना होगा.
• [C-1-2] सेंसर डेटा को 100 मिलीसेकंड + 2 * sample_time के ज़्यादा से ज़्यादा इंतज़ार के साथ रिपोर्ट करना ज़रूरी है. ऐसा तब करना होगा, जब ऐप्लिकेशन प्रोसेसर चालू हो और सेंसर स्ट्रीम के लिए 0 मिलीसेकंड का अनुरोध किया गया हो. इस समय में, फ़िल्टर करने में लगने वाला समय शामिल नहीं है.
• [C-1-3] सेंसर के चालू होने के 400 मिलीसेकंड + 2 * sample_time के अंदर, सेंसर के पहले सैंपल की रिपोर्ट देनी ज़रूरी है. इस सैंपल के लिए, सटीक होने की वैल्यू 0 हो सकती है.

• [SR] Android SDK के दस्तावेज़ में बताए गए तरीके के मुताबिक, इवेंट के समय की रिपोर्ट, नैनोसेकंड में होनी चाहिए. इससे, इवेंट के होने का समय पता चलता है और यह SystemClock.elapsedRealtimeNano() घड़ी के साथ सिंक होता है. हमारा सुझाव है कि मौजूदा और नए Android डिवाइसों को इन ज़रूरी शर्तों को पूरा करना चाहिए, ताकि वे आने वाले समय में प्लैटफ़ॉर्म के नए वर्शन पर अपग्रेड कर सकें. इन वर्शन में, यह एक ज़रूरी कॉम्पोनेंट हो सकता है. सिंक करने में हुई गड़बड़ी 100 मिलीसेकंड से कम होनी चाहिए.

• [C-1-4] Android SDK दस्तावेज़ में बताए गए किसी भी एपीआई को कंटिन्यूअस सेंसर के तौर पर इस्तेमाल करने के लिए, डिवाइस में समय-समय पर डेटा सैंपल देने की सुविधा होनी चाहिए. साथ ही, इन सैंपल में 3% से कम जटर होना चाहिए. जटर का मतलब, लगातार होने वाले इवेंट के बीच रिपोर्ट किए गए टाइमस्टैंप की वैल्यू के अंतर का स्टैंडर्ड डिविएशन होता है.

• [C-1-5] यह पक्का करना ज़रूरी है कि सेंसर इवेंट स्ट्रीम, डिवाइस के सीपीयू को निलंबित होने या निलंबित होने के बाद फिर से चालू होने से न रोके.

• जब कई सेंसर चालू होते हैं, तो बिजली की खपत, अलग-अलग सेंसर की रिपोर्ट की गई बिजली की खपत के कुल योग से ज़्यादा नहीं होनी चाहिए.

ऊपर दी गई सूची पूरी नहीं है. सेंसर के लिए, Android SDK टूल और Android के ओपन सोर्स दस्तावेज़ों के व्यवहार को आधिकारिक माना जाना चाहिए.

कुछ सेंसर टाइप कंपोजिट होते हैं. इसका मतलब है कि उन्हें एक या एक से ज़्यादा अन्य सेंसर से मिले डेटा से लिया जा सकता है. उदाहरण के लिए, ओरिएंटेशन सेंसर और लीनियर एक्सेलेरेशन सेंसर.

डिवाइस पर लागू करने के तरीके:

• सेंसर टाइप में बताए गए ज़रूरी फ़िज़िकल सेंसर शामिल होने पर, इन सेंसर टाइप को लागू करना चाहिए.

अगर डिवाइस में कॉम्पोज़िट सेंसर शामिल है, तो:

• [C-2-1] कंपोज़िट सेंसर के लिए, Android के ओपन सोर्स दस्तावेज़ में बताए गए तरीके के मुताबिक सेंसर लागू करना ज़रूरी है.

7.3.1. एक्सलरोमीटर

डिवाइस पर लागू करने के तरीके:

• [C-SR] हमारा सुझाव है कि आप 3-ऐक्सिस एक्सलरोमीटर शामिल करें.

अगर डिवाइस में 3-ऐक्सिस एक्सलरोमीटर शामिल है, तो:

• [C-1-1] यह ज़रूरी है कि डिवाइस कम से कम 50 हर्ट्ज़ तक की फ़्रीक्वेंसी वाले इवेंट की रिपोर्ट कर सके.
• [C-1-2] TYPE_ACCELEROMETER सेंसर को लागू करना और उसकी रिपोर्ट देना ज़रूरी है.
• [C-1-3] Android API में बताए गए तरीके के मुताबिक, Android सेंसर कोऑर्डिनेट सिस्टम का इस्तेमाल करना ज़रूरी है.
• [C-1-4] यह ज़रूरी है कि यह किसी भी अक्ष पर, फ़्रीफ़ॉल से लेकर गुरुत्वाकर्षण के चार गुने(4g) या उससे ज़्यादा तक के एक्सेलेरेशन को मेज़र कर सके.
• [C-1-5] का रिज़ॉल्यूशन कम से कम 12-बिट होना चाहिए.
• [C-1-6] का स्टैंडर्ड डेविएशन 0.05 मीटर/सेकंड^ से ज़्यादा नहीं होना चाहिए. स्टैंडर्ड डेविएशन का हिसाब, हर अक्ष के आधार पर लगाया जाना चाहिए. इसके लिए, कम से कम तीन सेकंड के दौरान इकट्ठा किए गए सैंपल का इस्तेमाल करना चाहिए. सैंपल इकट्ठा करने की दर सबसे तेज़ होनी चाहिए.
• [SR] को TYPE_SIGNIFICANT_MOTION कंपोजिट सेंसर लागू करने का ज़रूर सुझाव दिया जाता है.
• [SR] को TYPE_ACCELEROMETER_UNCALIBRATED सेंसर को लागू करने और उसकी रिपोर्ट करने का ज़रूर सुझाव दिया जाता है. हमारा सुझाव है कि Android डिवाइसों को इस ज़रूरी शर्त को पूरा करना चाहिए, ताकि वे आने वाले समय में प्लैटफ़ॉर्म के उस रिलीज़ पर अपग्रेड कर सकें जहां यह ज़रूरी हो सकता है.
• Android SDK दस्तावेज़ में बताए गए तरीके के मुताबिक, TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER कंपोजिट सेंसर लागू करने चाहिए.
• कम से कम 200 हर्ट्ज़ तक के इवेंट की रिपोर्ट करनी चाहिए.
• इसका रिज़ॉल्यूशन कम से कम 16-बिट होना चाहिए.
• अगर लाइफ़साइकल के दौरान कैरेक्टरिस्टिक में बदलाव होता है और उन्हें बदला जाता है, तो इस्तेमाल के दौरान कैलिब्रेट किया जाना चाहिए. साथ ही, डिवाइस के रीबूट होने के बीच, बदलाव के पैरामीटर को बनाए रखना चाहिए.
• तापमान के हिसाब से अडजस्ट होना चाहिए.

अगर डिवाइस में तीन ऐक्सिस वाला ऐक्सीलरॉमीटर और TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER में से कोई एक कंपोजिट सेंसर लागू किया गया है, तो:

• [C-2-1] इनकी कुल बिजली खपत हमेशा 4 एमडब्ल्यू से कम होनी चाहिए.
• डिवाइस के डाइनैमिक या स्टैटिक मोड में, हर एक का मान 2 mW और 0.5 mW से कम होना चाहिए.

अगर डिवाइस में 3-एक्सिस एक्सलरोमीटर और 3-एक्सिस जाइरोस्कोप सेंसर शामिल हैं, तो:

• [C-3-1] TYPE_GRAVITY और TYPE_LINEAR_ACCELERATION कंपोजिट सेंसर लागू करना ज़रूरी है.
• [C-SR] हमारा सुझाव है कि आप TYPE_GAME_ROTATION_VECTOR कंपोजिट सेंसर लागू करें.

अगर डिवाइस में 3-एक्सिस एक्सलरोमीटर, 3-एक्सिस जाइरोस्कोप सेंसर, और मैग्नेटोमीटर सेंसर शामिल हैं, तो:

• [C-4-1] TYPE_ROTATION_VECTOR कंपोजिट सेंसर लागू करना ज़रूरी है.

7.3.2. मैग्नेटोमीटर

डिवाइस पर लागू करने के तरीके:

• [C-SR] हमारा सुझाव है कि आप 3-ऐक्सिस मैग्नेटोमीटर (कम्पास) शामिल करें.

अगर डिवाइस में तीन ऐक्सिस वाला मैग्नेटोमीटर शामिल है, तो:

• [C-1-1] TYPE_MAGNETIC_FIELD सेंसर को लागू करना ज़रूरी है.
• [C-1-2] यह कम से कम 10 हर्ट्ज़ तक की फ़्रीक्वेंसी वाले इवेंट को रिपोर्ट कर सकता है. साथ ही, कम से कम 50 हर्ट्ज़ तक की फ़्रीक्वेंसी वाले इवेंट को रिपोर्ट करना चाहिए.
• [C-1-3] Android API में बताए गए तरीके के मुताबिक, Android सेंसर कोऑर्डिनेट सिस्टम का इस्तेमाल करना ज़रूरी है.
• [C-1-4] यह ज़रूरी है कि सैचुरेट होने से पहले, हर अक्ष पर -900 µT से +900 µT के बीच मेज़रमेंट किया जा सके.
• [C-1-5] मैग्नेटोमीटर को डाइनैमिक (इंजन से निकलने वाले करंट से) और स्टैटिक (मैग्नेट से) मैग्नेटिक फ़ील्ड से दूर रखकर, हार्ड आयरन ऑफ़सेट की वैल्यू 700 µT से कम होनी चाहिए. साथ ही, यह वैल्यू 200 µT से कम होनी चाहिए.
• [C-1-6] का रिज़ॉल्यूशन 0.6 µT के बराबर या उससे ज़्यादा होना चाहिए.
• [C-1-7] यह ज़रूरी है कि डिवाइस, हार्ड आयरन बायस के ऑनलाइन कैलिब्रेशन और कॉम्पेंसेशन की सुविधा दे. साथ ही, डिवाइस के रीबूट होने के बीच कॉम्पेंसेशन पैरामीटर को सेव रखे.
• [C-1-8] डिवाइस में सॉफ़्ट आयरन कम्पेंसेशन की सुविधा होनी चाहिए. यह कैलिब्रेशन, डिवाइस के इस्तेमाल के दौरान या उसके प्रोडक्शन के दौरान किया जा सकता है.
• [C-1-9] स्टैंडर्ड डेविएशन होना चाहिए. इसे हर अक्ष के आधार पर, सबसे तेज़ सैंपलिंग रेट पर कम से कम तीन सेकंड के दौरान इकट्ठा किए गए सैंपल के हिसाब से कैलकुलेट किया जाता है. यह 1.5 µT से ज़्यादा नहीं होना चाहिए. स्टैंडर्ड डेविएशन 0.5 µT से ज़्यादा नहीं होना चाहिए.
• TYPE_MAGNETIC_FIELD_UNCALIBRATED सेंसर लागू करना चाहिए.
• [SR] मौजूदा और नए Android डिवाइसों के लिए, TYPE_MAGNETIC_FIELD_UNCALIBRATED सेंसर को लागू करने का ज़रूर सुझाव दिया जाता है.

अगर डिवाइस में 3-ऐक्सिस मैग्नेटोमीटर, एक्सलरोमीटर सेंसर, और 3-ऐक्सिस जाइरोस्कोप सेंसर शामिल हैं, तो:

• [C-2-1] TYPE_ROTATION_VECTOR कंपोजिट सेंसर लागू करना ज़रूरी है.

अगर डिवाइस में 3-ऐक्सिस मैग्नेटोमीटर और एक्सलरोमीटर शामिल हैं, तो:

• TYPE_GEOMAGNETIC_ROTATION_VECTOR सेंसर लागू किया जा सकता है.

अगर डिवाइस में 3-ऐक्सिस मैग्नेटोमीटर, एक्सलरोमीटर, और TYPE_GEOMAGNETIC_ROTATION_VECTOR सेंसर शामिल हैं, तो:

• [C-3-1] यह 10 mW से कम ऊर्जा का इस्तेमाल करता हो.
• जब सेंसर को 10 हर्ट्ज़ पर बैच मोड के लिए रजिस्टर किया जाता है, तो यह 3 एमडब्ल्यू से कम ऊर्जा का इस्तेमाल करता है.

7.3.3. जीपीएस

डिवाइस पर लागू करने के तरीके:

• [C-SR] हमारा सुझाव है कि आप जीपीएस/जीएनएसएस रिसीवर शामिल करें.

अगर डिवाइस में GPS/GNSS रिसीवर शामिल है और android.hardware.location.gps सुविधा फ़्लैग की मदद से, ऐप्लिकेशन को इसकी क्षमता की जानकारी दी जाती है, तो:

• [C-1-1] LocationManager#requestLocationUpdate के ज़रिए अनुरोध किए जाने पर, जगह की जानकारी के आउटपुट की दर कम से कम 1 हर्ट्ज़ होनी चाहिए.
• [C-1-2] यह ज़रूरी है कि डिवाइस, 0.5 एमबीपीएस या इससे ज़्यादा डेटा स्पीड वाले इंटरनेट कनेक्शन से कनेक्ट होने पर, खुले आसमान वाली जगहों (जहां सिग्नल बेहतर हों, मल्टीपाथ की समस्या न हो, और एचडीओपी < 2 हो) पर 10 सेकंड (पहले फ़िक्स में लगने वाला कम समय) में जगह की जानकारी दे सके. आम तौर पर, इस ज़रूरी शर्त को पूरा करने के लिए, असिस्टेड या अनुमानित जीपीएस/जीएनएसएस तकनीक का इस्तेमाल किया जाता है. इससे जीपीएस/जीएनएसएस लॉक-ऑन समय कम हो जाता है. असिस्टेंस डेटा में, रेफ़रंस टाइम, रेफ़रंस लोकेशन, और सैटलाइट एफ़ेमेरिस/क्लॉक शामिल होते हैं.
  • [C-1-6] जगह की जानकारी का हिसाब लगाने के बाद, डिवाइस को जगह की जानकारी का अनुरोध फिर से शुरू होने पर, खुले आसमान में पांच सेकंड के अंदर अपनी जगह की जानकारी तय करनी होगी. यह जानकारी, जगह की जानकारी का हिसाब लगाने के एक घंटे बाद तक तय की जानी चाहिए. भले ही, इसके बाद का अनुरोध, डेटा कनेक्शन के बिना और/या पावर साइकल के बाद किया गया हो.

• खुले आसमान में जगह की जानकारी तय करने के बाद, जब विमान एक जगह पर हो या 1 मीटर प्रति सेकंड स्क्वेयर से कम की रफ़्तार से आगे बढ़ रहा हो, तो:

  • [C-1-3] यह ज़रूरी है कि डिवाइस, कम से कम 95% समय तक, जगह की जानकारी 20 मीटर के अंदर और गति की जानकारी 0.5 मीटर प्रति सेकंड के अंदर दे सके.
  • [C-1-4] एक ही कॉन्स्टेलेशन के कम से कम आठ सैटलाइट को GnssStatus.Callback के ज़रिए एक साथ ट्रैक और रिपोर्ट करना ज़रूरी है.
  • एक साथ कम से कम 24 सैटलाइट को ट्रैक करने की सुविधा होनी चाहिए. ये सैटलाइट, अलग-अलग कॉन्स्टेलेशन (जैसे, जीपीएस + कम से कम एक Glonass, Beidou, Galileo) से होने चाहिए.
  • [C-SR] हमारा सुझाव है कि आपातकालीन फ़ोन कॉल के दौरान, GNSS Location Provider APIs की मदद से सामान्य जीपीएस/जीएनएसएस लोकेशन आउटपुट डिलीवर करना जारी रखें.
  • [C-SR] हमारा सुझाव है कि ट्रैक किए गए सभी कॉन्स्टलेशन (जैसा कि GnssStatus मैसेज में बताया गया है) से जीएनएसएस मेज़रमेंट की रिपोर्ट करें. हालांकि, एसबीएएस को छोड़ दें.
  • [C-SR] जीएनएसएस मेज़रमेंट की फ़्रीक्वेंसी और एजीसी की रिपोर्ट करने का ज़रूर सुझाव दिया जाता है.
  • [C-SR] हमारा सुझाव है कि हर जीपीएस/जीएनएसएस लोकेशन के हिस्से के तौर पर, सटीक जानकारी के सभी अनुमान (इनमें दिशा, स्पीड, और वर्टिकल शामिल हैं) की रिपोर्ट करें.
  • [C-SR] हमारा सुझाव है कि जीएनएसएस से मिले मेज़रमेंट को तुरंत रिपोर्ट करें. भले ही, जीपीएस/जीएनएसएस से कैलकुलेट की गई जगह की जानकारी अब तक रिपोर्ट न की गई हो.
  • [C-SR] हमारा सुझाव है कि जीएनएसएस स्यूडोरेंज और स्यूडोरेंज रेट की रिपोर्ट करें. ये ऐसे रेंज होते हैं जो खुले आसमान में जगह की जानकारी तय करने के बाद, जगह पर स्थिर रहने या 0.2 मीटर प्रति सेकंड स्क्वेयर से कम की रफ़्तार से चलने पर, कम से कम 95% समय में जगह की जानकारी 20 मीटर के अंदर और रफ़्तार 0.2 मीटर प्रति सेकंड के अंदर का हिसाब लगाने के लिए काफ़ी होते हैं.

7.3.4. जाइरोस्कोप

डिवाइस पर लागू करने के तरीके:

• [C-SR] हमारा सुझाव है कि जब तक 3-ऐक्सिस एक्सलरोमीटर शामिल नहीं किया जाता, तब तक जाइरोस्कोप सेंसर शामिल करें.

अगर डिवाइस में 3-ऐक्सिस जाइरोस्कोप शामिल है, तो:

• [C-1-1] यह ज़रूरी है कि डिवाइस कम से कम 50 हर्ट्ज़ तक की फ़्रीक्वेंसी वाले इवेंट की रिपोर्ट कर सके.
• [C-1-2] TYPE_GYROSCOPE सेंसर को लागू करना ज़रूरी है. साथ ही, TYPE_GYROSCOPE_UNCALIBRATED सेंसर को भी लागू करने का सुझाव दिया जाता है.
• [C-1-4] का रिज़ॉल्यूशन 12 बिट या उससे ज़्यादा होना चाहिए. हालांकि, यह 16 बिट या उससे ज़्यादा होना चाहिए.
• [C-1-5] तापमान के हिसाब से अडजस्ट होने वाला होना चाहिए.
• [C-1-6] इस्तेमाल के दौरान, कैलिब्रेट और कंपेसेशन किया जाना चाहिए. साथ ही, डिवाइस के रीबूट होने के बीच कंपेसेशन पैरामीटर को बनाए रखा जाना चाहिए.
• [C-1-7] हर हर्ट्ज़ (हर हर्ट्ज़ में वैरिएंस या rad^2 / s) के लिए, वैरिएंस 1e-7 rad^2 / s^2 से ज़्यादा नहीं होना चाहिए. वैरिएंस को सैंपलिंग रेट के हिसाब से बदलने की अनुमति है, लेकिन यह वैल्यू से ज़्यादा नहीं होना चाहिए. दूसरे शब्दों में, अगर 1 हर्ट्ज़ सैंपलिंग रेट पर, जायरो के वैरिएंस को मेज़र किया जाता है, तो यह 1e-7 rad^2/s^2 से ज़्यादा नहीं होना चाहिए.
• [SR] हमारा सुझाव है कि जब डिवाइस कमरे के तापमान पर स्थिर हो, तो कैलिब्रेशन में होने वाली गड़बड़ी 0.01 रेडियन/सेकंड से कम होनी चाहिए.
• कम से कम 200 हर्ट्ज़ तक के इवेंट की रिपोर्ट करनी चाहिए.

अगर डिवाइस में 3-एक्सिस जाइरोस्कोप, एक्सलरोमीटर सेंसर, और मैग्नेटोमीटर सेंसर शामिल हैं, तो:

• [C-2-1] TYPE_ROTATION_VECTOR कंपोजिट सेंसर लागू करना ज़रूरी है.

अगर डिवाइस में 3-एक्सिस एक्सलरोमीटर और 3-एक्सिस जाइरोस्कोप सेंसर शामिल हैं, तो:

• [C-3-1] TYPE_GRAVITY और TYPE_LINEAR_ACCELERATION कंपोजिट सेंसर लागू करना ज़रूरी है.
• [C-SR] हमारा सुझाव है कि आप TYPE_GAME_ROTATION_VECTOR कंपोजिट सेंसर लागू करें.

7.3.5. बैरोमीटर

डिवाइस पर लागू करने के तरीके:

• [C-SR] हमारा सुझाव है कि आप बैरोमीटर (एंबियंट एयर प्रेशर सेंसर) शामिल करें.

अगर डिवाइस में बैरोमीटर शामिल है, तो:

• [C-1-1] TYPE_PRESSURE सेंसर को लागू करना और उसकी रिपोर्ट देना ज़रूरी है.
• [C-1-2] इवेंट को 5 हर्ट्ज़ या उससे ज़्यादा फ़्रीक्वेंसी पर डिलीवर करना चाहिए.
• [C-1-3] तापमान के हिसाब से अडजस्ट होना चाहिए.
• [SR] हमारा सुझाव है कि आप 300hPa से 1100hPa की सीमा में, दबाव के मेज़रमेंट की रिपोर्ट करें.
• यह 1hPa तक सटीक होना चाहिए.
• 20hPa की रेंज में, 0.12hPa की रिलेटिव सटीक जानकारी होनी चाहिए. यह समुद्र तल पर ~200 मीटर के बदलाव में ~1 मीटर की सटीक जानकारी के बराबर है.

7.3.6. Thermometer

डिवाइस पर लागू करने के तरीके:

• इसमें आस-पास के तापमान को मापने वाला थर्मामीटर (तापमान सेंसर) शामिल हो सकता है.
• इसमें सीपीयू के तापमान का सेंसर शामिल किया जा सकता है, लेकिन ऐसा नहीं करना चाहिए.

अगर डिवाइस में आस-पास के तापमान को मापने वाला थर्मामीटर (तापमान सेंसर) शामिल है, तो:

• [C-1-1] को SENSOR_TYPE_AMBIENT_TEMPERATURE के तौर पर तय किया जाना चाहिए. साथ ही, यह डिवाइस के आस-पास के (कमरे/वाहन के केबिन) तापमान को सेल्सियस डिग्री में मेज़र करना चाहिए.
• [C-1-2] को SENSOR_TYPE_TEMPERATURE के तौर पर तय किया जाना चाहिए.
• [C-1-3] डिवाइस के सीपीयू का तापमान मेज़र करना ज़रूरी है.
• [C-1-4] किसी अन्य तापमान को नहीं मापना चाहिए.

ध्यान दें कि SENSOR_TYPE_TEMPERATURE सेंसर टाइप को Android 4.0 में बंद कर दिया गया था.

7.3.7. फ़ोटोमीटर

• डिवाइस में फ़ोटोमीटर (स्क्रीन की रोशनी को अपने-आप घटाने-बढ़ाने वाला सेंसर) शामिल हो सकता है.

7.3.8. निकटता सेंसर

• डिवाइस में लागू करने के लिए, प्रॉक्सिमिटी सेंसर का इस्तेमाल किया जा सकता है.

अगर डिवाइस में प्रॉक्सिमिटी सेंसर शामिल है, तो:

• [C-1-1] किसी ऑब्जेक्ट की प्रॉक्सिमिटी को उसी दिशा में मेज़र करना चाहिए जिस दिशा में स्क्रीन है. इसका मतलब है कि प्रॉक्सिमिटी सेंसर को स्क्रीन के आस-पास मौजूद ऑब्जेक्ट का पता लगाने के लिए ऑर्डर किया जाना चाहिए. इस तरह के सेंसर का मुख्य मकसद, उपयोगकर्ता के इस्तेमाल में मौजूद फ़ोन का पता लगाना होता है. अगर डिवाइस में किसी अन्य ओरिएंटेशन के साथ प्रॉक्सिमिटी सेंसर शामिल है, तो उसे इस एपीआई से ऐक्सेस नहीं किया जा सकता.
• [C-1-2] सटीक जानकारी देने के लिए, 1 बिट या उससे ज़्यादा की जानकारी होनी चाहिए.

7.3.9. हाई फ़िडेलिटी सेंसर

अगर डिवाइस में, इस सेक्शन में बताई गई क्वालिटी वाले सेंसर शामिल हैं और उन्हें तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराया जाता है, तो:

• [C-1-1] android.hardware.sensor.hifi_sensors फ़ीचर फ़्लैग की मदद से, इस सुविधा की पहचान करना ज़रूरी है.

अगर डिवाइस पर android.hardware.sensor.hifi_sensors लागू किया जाता है, तो:

• [C-2-1] इसमें TYPE_ACCELEROMETER सेंसर होना चाहिए, जो:

  • मेज़रमेंट की रेंज कम से कम -8g से +8g के बीच होनी चाहिए. हालांकि, यह रेंज कम से कम -16g से +16g के बीच होनी चाहिए.
  • मेज़रमेंट का रिज़ॉल्यूशन कम से कम 2048 LSB/g होना चाहिए.
  • मेज़रमेंट फ़्रीक्वेंसी कम से कम 12.5 हर्ट्ज़ या उससे कम होनी चाहिए.
  • मेज़रमेंट की फ़्रीक्वेंसी 400 हर्ट्ज़ या उससे ज़्यादा होनी चाहिए. साथ ही, SensorDirectChannel RATE_VERY_FAST के साथ काम करना चाहिए.
  • मेज़रमेंट नॉइज़ 400 μg/√Hz से ज़्यादा नहीं होना चाहिए.
  • इस सेंसर के लिए, बिना 'जागने' वाले फ़ॉर्म को लागू करना ज़रूरी है. साथ ही, यह फ़ॉर्म कम से कम 3,000 सेंसर इवेंट को बफ़र करने की सुविधा के साथ होना चाहिए.
  • बैचिंग के दौरान, डिवाइस की बिजली की खपत 3 mW से ज़्यादा नहीं होनी चाहिए.
  • [C-SR] हमारा सुझाव है कि 3dB मेज़रमेंट बैंडविड्थ, न्योक्विस्ट फ़्रीक्वेंसी के कम से कम 80% के बराबर होनी चाहिए. साथ ही, इस बैंडविड्थ में व्हाइट नॉइज़ स्पेक्ट्रम होना चाहिए.
  • कमरे के तापमान पर जांचे गए एक्सेलेरेशन रैंडम वॉक की वैल्यू 30 μg √Hz से कम होनी चाहिए.
  • तापमान के हिसाब से, बायस में बदलाव ≤ +/- 1 mg/°C होना चाहिए.
  • सबसे अच्छी फ़िट लाइन की गैर-लीनियरिटी ≤ 0.5% होनी चाहिए. साथ ही, तापमान के हिसाब से सेंसिटिविटी में बदलाव ≤ 0.03%/C° होना चाहिए.
  • क्रॉस-ऐक्सिस सेंसिटिविटी 2.5 % से कम होनी चाहिए. साथ ही, डिवाइस के ऑपरेशन के तापमान की रेंज में क्रॉस-ऐक्सिस सेंसिटिविटी में 0.2% से कम का अंतर होना चाहिए.

• [C-2-2] TYPE_ACCELEROMETER_UNCALIBRATED में TYPE_ACCELEROMETER जैसी ही क्वालिटी की ज़रूरी शर्तें होनी चाहिए.

• [C-2-3] इसमें TYPE_GYROSCOPE सेंसर होना चाहिए, जो:

  • मेज़रमेंट की रेंज कम से कम -1,000 से +1,000 डीपीएस के बीच होनी चाहिए.
  • मेज़रमेंट रिज़ॉल्यूशन कम से कम 16 LSB/dps होना चाहिए.
  • मेज़रमेंट फ़्रीक्वेंसी कम से कम 12.5 हर्ट्ज़ या उससे कम होनी चाहिए.
  • मेज़रमेंट की फ़्रीक्वेंसी 400 हर्ट्ज़ या उससे ज़्यादा होनी चाहिए. साथ ही, SensorDirectChannel RATE_VERY_FAST के साथ काम करना चाहिए.
  • मेज़रमेंट नॉइज़ 0.014°/s/√Hz से ज़्यादा नहीं होना चाहिए.
  • [C-SR] हमारा सुझाव है कि 3dB मेज़रमेंट बैंडविड्थ, न्योक्विस्ट फ़्रीक्वेंसी के कम से कम 80% के बराबर होनी चाहिए. साथ ही, इस बैंडविड्थ में व्हाइट नॉइज़ स्पेक्ट्रम होना चाहिए.
  • कमरे के तापमान पर जांचे गए रैंडम वॉक की दर 0.001 °/s √Hz से कम होनी चाहिए.
  • तापमान के हिसाब से, बायस में बदलाव ≤ +/- 0.05 °/ s / °C होना चाहिए.
  • तापमान के हिसाब से सेंसिटिविटी में बदलाव ≤ 0.02% / °C होना चाहिए.
  • सबसे अच्छी फ़िट लाइन की नॉन-लीनियरिटी 0.2% से कम होनी चाहिए.
  • शोर की डेंसिटी 0.007 °/s/√Hz से कम होनी चाहिए.
  • डिवाइस के स्थिर होने पर, तापमान की रेंज 10 ~ 40 ℃ में कैलिब्रेशन की गड़बड़ी 0.002 रेडियन/सेकंड से कम होनी चाहिए.
  • जी-सेंसिटिविटी 0.1°/s/g से कम होनी चाहिए.
  • डिवाइस के ऑपरेशन के तापमान की रेंज में, क्रॉस-ऐक्सिस सेंसिटिविटी 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 LSB/hPa होना चाहिए.
  • मेज़रमेंट फ़्रीक्वेंसी कम से कम 1 हर्ट्ज़ या उससे कम होनी चाहिए.
  • मेज़रमेंट की फ़्रीक्वेंसी 10 हर्ट्ज़ या इससे ज़्यादा होनी चाहिए.
  • मेज़रमेंट नॉइज़ 2 Pa/√Hz से ज़्यादा नहीं होना चाहिए.
  • इस सेंसर के लिए, बिना डिवाइस को जगाने वाले फ़ॉर्म को लागू करना ज़रूरी है. साथ ही, यह फ़ॉर्म कम से कम 300 सेंसर इवेंट को बफ़र करने की सुविधा के साथ होना चाहिए.
  • बैचिंग के दौरान बिजली की खपत 2 mW से ज़्यादा नहीं होनी चाहिए.
• [C-2-8] इसमें TYPE_GAME_ROTATION_VECTOR सेंसर होना चाहिए.
• [C-2-9] इसमें TYPE_SIGNIFICANT_MOTION सेंसर होना चाहिए, जो:
  • डिवाइस के स्टैटिक होने पर, बिजली की खपत 0.5 mW से ज़्यादा नहीं होनी चाहिए. साथ ही, डिवाइस के मूव होने पर, बिजली की खपत 1.5 mW से ज़्यादा नहीं होनी चाहिए.
• [C-2-10] इसमें TYPE_STEP_DETECTOR सेंसर होना चाहिए, जो:
  • इस सेंसर के लिए, बिना 'जागने' वाले फ़ॉर्म को लागू करना ज़रूरी है. साथ ही, यह फ़ॉर्म कम से कम 100 सेंसर इवेंट को बफ़र करने की सुविधा के साथ होना चाहिए.
  • डिवाइस के स्टैटिक होने पर, बिजली की खपत 0.5 mW से ज़्यादा नहीं होनी चाहिए. साथ ही, डिवाइस के मूव होने पर, बिजली की खपत 1.5 mW से ज़्यादा नहीं होनी चाहिए.
  • बैचिंग के दौरान, डिवाइस की बिजली की खपत 4 mW से ज़्यादा नहीं होनी चाहिए.
• [C-2-11] ऐप्लिकेशन में TYPE_STEP_COUNTER सेंसर होना चाहिए, जो:
  • डिवाइस के स्टैटिक होने पर, बिजली की खपत 0.5 mW से ज़्यादा नहीं होनी चाहिए. साथ ही, डिवाइस के मूव होने पर, बिजली की खपत 1.5 mW से ज़्यादा नहीं होनी चाहिए.
• [C-2-12] इसमें TILT_DETECTOR सेंसर होना चाहिए, जो:
  • डिवाइस के स्टैटिक होने पर, बिजली की खपत 0.5 mW से ज़्यादा नहीं होनी चाहिए. साथ ही, डिवाइस के मूव होने पर, बिजली की खपत 1.5 mW से ज़्यादा नहीं होनी चाहिए.
• [C-2-13] एक ही फ़िज़िकल इवेंट के लिए, एक्सेलेरोमीटर, जायरोस्कोप, और मैग्नेटोमीटर से रिपोर्ट किए गए इवेंट के टाइमस्टैंप में 2.5 मिलीसेकंड से ज़्यादा का अंतर नहीं होना चाहिए. एक ही फ़िज़िकल इवेंट के लिए, एक्सेलेरोमीटर और जायरोस्कोप से रिपोर्ट किए गए इवेंट के टाइमस्टैंप में 0.25 मिलीसेकंड से ज़्यादा का अंतर नहीं होना चाहिए.
• [C-2-14] यह ज़रूरी है कि जियोस्कोप सेंसर इवेंट के टाइमस्टैंप, कैमरा सबसिस्टम के टाइम बेस के साथ-साथ हों और गड़बड़ी 1 मिलीसेकंड के अंदर हो.
• [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 एपीआई की मदद से, डायरेक्ट चैनल टाइप और डायरेक्ट रिपोर्ट रेट लेवल के साथ काम करने की जानकारी सही तरीके से देनी होगी.
• [C-3-2] सेंसर डायरेक्ट चैनल के साथ काम करने वाले सभी सेंसर के लिए, सेंसर डायरेक्ट चैनल के दो टाइप में से कम से कम एक के साथ काम करना ज़रूरी है.
  • TYPE_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE
• यह इन टाइप के प्राइमरी सेंसर (नॉन-वॉकअप वैरिएंट) के लिए, सेंसर डायरेक्ट चैनल के ज़रिए इवेंट रिपोर्टिंग की सुविधा देनी चाहिए:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. बायोमेट्रिक सेंसर

बायोमेट्रिक अनलॉक की सुरक्षा को मेज़र करने के बारे में ज़्यादा जानकारी के लिए, कृपया बायोमेट्रिक सुरक्षा को मेज़र करने से जुड़ा दस्तावेज़ देखें.

अगर डिवाइस में सुरक्षित लॉक स्क्रीन की सुविधा शामिल है, तो:

• इसमें बायोमेट्रिक सेंसर होना चाहिए

बायोमेट्रिक सेंसर को बेहतर, खराब या आसान के तौर पर बांटा जा सकता है. यह बांटने का आधार, स्पूफ़ और झूठी पहचान की दर के साथ-साथ बायोमेट्रिक पाइपलाइन की सुरक्षा है. इस कैटगरी से यह तय होता है कि बायोमेट्रिक सेंसर, प्लैटफ़ॉर्म और तीसरे पक्ष के ऐप्लिकेशन के साथ किस तरह इंटरफ़ेस कर सकता है. सेंसर को डिफ़ॉल्ट रूप से सुविधा के तौर पर बांटा जाता है. अगर उन्हें कम या ज़्यादा के तौर पर बांटना है, तो उन्हें यहां बताई गई अन्य ज़रूरी शर्तें पूरी करनी होंगी. कम और ज़्यादा सुरक्षा वाली बायोमेट्रिक्स, दोनों को अतिरिक्त सुविधाएं मिलती हैं. इन सुविधाओं के बारे में यहां बताया गया है.

तीसरे पक्ष के ऐप्लिकेशन और डिवाइस पर बायोमेट्रिक सेंसर उपलब्ध कराने के लिए:

• [C-0-1] इस दस्तावेज़ में बताई गई बेहतर या कम सुरक्षा वाली बायोमेट्रिक सुविधा की ज़रूरी शर्तें पूरी करनी चाहिए.

तीसरे पक्ष के ऐप्लिकेशन और डिवाइस के लिए, पासकोड की कुंजियों का ऐक्सेस देने के लिए:

• [C-0-2] इस दस्तावेज़ में बताई गई स्ट्रॉन्ग तौर पर पुष्टि करने की ज़रूरी शर्तें पूरी करनी चाहिए.

इनके अलावा:

• [C-0-3] अगर बेहतर बायोमेट्रिक सुविधा पैसिव है, तो उसे पुष्टि करने के लिए किसी साफ़ तौर पर की गई कार्रवाई (जैसे, बटन दबाना) के साथ जोड़ा जाना चाहिए. उदाहरण के लिए, चेहरे या आईरिस की पहचान करने वाली सुविधा, जिसमें उपयोगकर्ता के इंटेंट का कोई साफ़ सिग्नल मौजूद नहीं होता.
  • [C-SR] हमारा सुझाव है कि पैसिव बायोमेट्रिक्स की पुष्टि करने की कार्रवाई को इस तरह से सुरक्षित किया जाए कि ऑपरेटिंग सिस्टम या कर्नेल में छेड़छाड़ करके, इस कार्रवाई को न बदला जा सके. उदाहरण के लिए, इसका मतलब है कि किसी फ़िज़िकल बटन पर क्लिक करने पर होने वाली पुष्टि की कार्रवाई, सिक्योर एलिमेंट (एसई) के सिर्फ़ इनपुट के लिए बने सामान्य-इस्तेमाल वाले इनपुट/आउटपुट (जीपीआईओ) पिन से रूट की जाती है. इस कार्रवाई को फ़िज़िकल बटन को दबाने के अलावा किसी अन्य तरीके से नहीं चलाया जा सकता.

अगर डिवाइस में बायोमेट्रिक सेंसर को सुविधा के तौर पर इस्तेमाल करना है, तो:

• [C-1-1] गलत स्वीकार किए जाने की दर 0.002% से कम होनी चाहिए.
• [C-1-2] यह ज़रूरी है कि यह जानकारी दी जाए कि यह मोड, किसी मुश्किल पिन, पैटर्न या पासवर्ड के मुकाबले कम सुरक्षित हो सकता है. साथ ही, अगर स्पूफ़ और इंपोस्टर स्वीकार करने की दर 7% से ज़्यादा है, तो इसे चालू करने के जोखिमों के बारे में साफ़ तौर पर बताया जाना चाहिए.
• [C-1-3] बायोमेट्रिक पुष्टि के लिए, पांच बार गलत तरीके से कोशिश करने के बाद, कम से कम 30 सेकंड के लिए कोशिश करने की दर को सीमित करना ज़रूरी है. गलत तरीके से कोशिश करने का मतलब है, कैप्चर की गई क्वालिटी (BIOMETRIC_ACQUIRED_GOOD) अच्छी होने के बावजूद, वह रजिस्टर की गई बायोमेट्रिक जानकारी से मेल न खाना.
• [C-1-4] उपयोगकर्ता को मौजूदा बायोमेट्रिक की पुष्टि करने या TEE से सुरक्षित डिवाइस क्रेडेंशियल (पिन/पैटर्न/पासवर्ड) जोड़ने के लिए कहे बिना, नए बायोमेट्रिक जोड़ने से रोकना ज़रूरी है. Android Open Source Project के लागू होने से, ऐसा करने के लिए फ़्रेमवर्क में एक तरीका मिलता है.
• [C-1-5] उपयोगकर्ता का खाता हटाने पर, उसकी पहचान ज़ाहिर करने वाला बायोमेट्रिक डेटा पूरी तरह से मिटाना ज़रूरी है. इसमें फ़ैक्ट्री रीसेट करने पर भी ऐसा करना ज़रूरी है.
• [C-1-6] उस बायोमेट्रिक के लिए, अलग-अलग फ़्लैग का इस्तेमाल करना ज़रूरी है. जैसे, DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE या DevicePolicymanager.KEYGUARD_DISABLE_IRIS.
• [C-1-7] Android 10 वर्शन के साथ लॉन्च होने वाले नए डिवाइसों के लिए, हर 24 घंटे या उससे कम समय में उपयोगकर्ता से पुष्टि करने के लिए कहा जाना चाहिए.यह पुष्टि, Android के पुराने वर्शन से अपग्रेड किए गए डिवाइसों के लिए, हर 72 घंटे या उससे कम समय में की जानी चाहिए. पुष्टि करने के लिए, पिन, पैटर्न, पासवर्ड जैसी मुख्य पुष्टि करने की सुविधा का सुझाव दिया जाता है.

• [C-1-8] इनमें से किसी एक स्थिति के बाद, उपयोगकर्ता को सुझाए गए मुख्य पुष्टि करने के तरीके (जैसे, पिन, पैटर्न, पासवर्ड) के लिए ज़रूर चुनौती देनी चाहिए:

  • कोई गतिविधि न होने पर चार घंटे का टाइम आउट या
  • बायोमेट्रिक ऑथेंटिकेशन की तीन बार कोशिश करने के बाद भी पुष्टि नहीं हो सकी.
  • डिवाइस के क्रेडेंशियल की पुष्टि होने के बाद, डिवाइस के इस्तेमाल में न होने पर टाइम आउट होने की अवधि और पुष्टि न होने की संख्या रीसेट हो जाती है.

  Android के पुराने वर्शन से डिवाइसों को अपग्रेड करने पर, C-1-8 से छूट मिल सकती है.

• [C-SR] हमारा सुझाव है कि डिवाइस पर मेज़र किए गए फ़ॉल्स रिजेक्शन रेट (गलत तरीके से अस्वीकार किए जाने की दर) को 10% से कम रखा जाए.

• [C-SR] हमारा सुझाव है कि रजिस्टर की गई हर बायोमेट्रिक सुविधा के लिए, इंतज़ार का समय एक सेकंड से कम होना चाहिए. यह समय, बायोमेट्रिक की पहचान होने से लेकर स्क्रीन अनलॉक होने तक का होता है.

अगर डिवाइस में बायोमेट्रिक सेंसर को कम सुरक्षित के तौर पर इस्तेमाल करना है, तो:

• [C-2-1] को [C-1-2] को छोड़कर, ऊपर दी गई सुविधा से जुड़ी सभी ज़रूरी शर्तें पूरी करनी होंगी.
• [C-2-2] स्पैम और धोखाधड़ी वाले ईमेल स्वीकार करने की दर 20% से ज़्यादा नहीं होनी चाहिए.
• [C-2-3] ऐप्लिकेशन में, हार्डवेयर के साथ काम करने वाला पासकोड स्टोर होना चाहिए. साथ ही, Android उपयोगकर्ता या कर्नेल स्पेस के बाहर, अलग से बनाए गए एक्ज़ीक्यूशन एनवायरमेंट में बायोमेट्रिक मैचिंग की सुविधा होनी चाहिए. जैसे, ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट (टीईई) या अलग से बनाए गए एक्ज़ीक्यूशन एनवायरमेंट के लिए सुरक्षित चैनल वाली चिप पर.
• [C-2-4] पहचाने जा सकने वाले सभी डेटा को एन्क्रिप्ट (सुरक्षित) किया जाना चाहिए और क्रिप्टोग्राफ़ी (सुरक्षा से जुड़ी तकनीक) की मदद से उसकी पुष्टि की जानी चाहिए. इससे, डेटा को अलग से चलाए जाने वाले एनवायरमेंट या अलग से चलाए जाने वाले एनवायरमेंट के लिए सुरक्षित चैनल वाले चिप के बाहर हासिल नहीं किया जा सकता, न ही उसे पढ़ा जा सकता है या उसमें बदलाव किया जा सकता है. इस बारे में, Android Open Source Project की साइट पर लागू करने के दिशा-निर्देशों में बताया गया है.
• [C-2-5] कैमरे पर आधारित बायोमेट्रिक्स के लिए, बायोमेट्रिक ऑथेंटिकेशन या रजिस्टर करने के दौरान:
  • कैमरे को ऐसे मोड में चलाना चाहिए जिससे कैमरे के फ़्रेम को आइसोलेटेड एक्सीक्यूशन एनवायरमेंट के बाहर न पढ़ा जा सके या उनमें बदलाव न किया जा सके. इसके अलावा, कैमरे में ऐसा चिप होना चाहिए जो आइसोलेटेड एक्सीक्यूशन एनवायरमेंट के लिए सुरक्षित चैनल उपलब्ध कराता हो.
  • आरजीबी सिंगल-कैमरा सलूशन के लिए, कैमरे के फ़्रेम को अलग से चलाए जाने वाले एनवायरमेंट के बाहर पढ़ा जा सकता है. इससे, रजिस्टर करने के लिए झलक देखने जैसे कामों में मदद मिलती है. हालांकि, इन फ़्रेम में बदलाव नहीं किया जा सकता.
• [C-2-6] तीसरे पक्ष के ऐप्लिकेशन को, अलग-अलग बायोमेट्रिक डेटा के बीच अंतर करने की अनुमति नहीं दी जानी चाहिए.
• [C-2-7] यह ज़रूरी है कि टीईई के बाहर, ऐप्लिकेशन प्रोसेसर को पहचान से जुड़े बायोमेट्रिक डेटा या उससे मिले किसी भी डेटा (जैसे, एम्बेडिंग) को अनक्रिप्ट (सुरक्षित) किए बिना ऐक्सेस करने की अनुमति न दी जाए.

• [C-2-8] प्रोसेसिंग की सुरक्षित पाइपलाइन होनी चाहिए, ताकि ऑपरेटिंग सिस्टम या कर्नेल में छेड़छाड़ करके, डेटा को सीधे तौर पर इंजेक्ट करके, उपयोगकर्ता के तौर पर गलत तरीके से पुष्टि न की जा सके.

  अगर डिवाइस पर पहले से ही Android के किसी पुराने वर्शन पर, C-2-8 की ज़रूरी शर्तें पूरी करने वाले सिस्टम सॉफ़्टवेयर अपडेट लॉन्च किए जा चुके हैं, तो हो सकता है कि उन्हें इस शर्त से छूट दी जाए.

अगर डिवाइस में बायोमेट्रिक सेंसर को मज़बूत के तौर पर इस्तेमाल करना है, तो:

• [C-3-1] यह ज़रूरी है कि यह ऊपर बताई गई कम रेटिंग की सभी ज़रूरी शर्तें पूरी करता हो. डिवाइसों को Android के पुराने वर्शन से अपग्रेड करने पर, C-2-7 का पालन करना ज़रूरी है.
• [C-3-2] स्पैम और झूठी पहचान वाले ईमेल स्वीकार करने की दर 7% से ज़्यादा नहीं होनी चाहिए.
• [C-3-3] हर 72 घंटे या उससे कम समय में, उपयोगकर्ता को सुझाई गई प्राइमरी पुष्टि करने के लिए ज़रूर कहा जाना चाहिए. जैसे, पिन, पैटर्न, पासवर्ड.

7.3.12. आसन का पता लगाने वाला सेंसर

डिवाइस पर लागू करने के तरीके:

• हो सकता है कि यह 6 डिग्री ऑफ़ फ़्रीडम वाले पोज़ सेंसर के साथ काम करे.

अगर डिवाइस पर, पोज़ सेंसर की सुविधा 6 डिग्री ऑफ़ फ़्रीडम के साथ काम करती है, तो:

• [C-1-1] TYPE_POSE_6DOF सेंसर को लागू करना और उसकी रिपोर्ट देना ज़रूरी है.
• [C-1-2] यह सिर्फ़ रोटेशन वेक्टर के मुकाबले ज़्यादा सटीक होना चाहिए.

7.4. डेटा कनेक्टिविटी

7.4.1. टेलीफ़ोनी

Android API और इस दस्तावेज़ में, “टेलीफ़ोन” का इस्तेमाल खास तौर पर, GSM या CDMA नेटवर्क के ज़रिए वॉइस कॉल करने और एसएमएस भेजने से जुड़े हार्डवेयर के लिए किया गया है. ये वॉइस कॉल, पैकेट-स्विच किए जा सकते हैं या नहीं, लेकिन Android के लिए इन्हें उसी नेटवर्क का इस्तेमाल करके लागू की जाने वाली किसी भी डेटा कनेक्टिविटी से अलग माना जाता है. दूसरे शब्दों में, Android की “टेलीफ़ोन” सुविधा और एपीआई, खास तौर पर वॉइस कॉल और एसएमएस के बारे में बताते हैं. उदाहरण के लिए, ऐसे डिवाइसों को टेलीफ़ोन डिवाइस नहीं माना जाता जिनसे कॉल नहीं किए जा सकते या एसएमएस नहीं भेजे और पाए जा सकते. भले ही, वे डेटा कनेक्टिविटी के लिए सेल्युलर नेटवर्क का इस्तेमाल करते हों.

• Android का इस्तेमाल उन डिवाइसों पर किया जा सकता है जिनमें टेलीफ़ोन हार्डवेयर शामिल नहीं है. इसका मतलब है कि Android, फ़ोन के अलावा दूसरे डिवाइसों पर भी काम करता है.

अगर डिवाइस में जीएसएम या सीडीएमए टेलीफ़ोनी शामिल है, तो:

• [C-1-1] तकनीक के हिसाब से, android.hardware.telephony फ़ीचर फ़्लैग और अन्य सब-फ़ीचर फ़्लैग का एलान करना ज़रूरी है.
• [C-1-2] उस टेक्नोलॉजी के लिए, एपीआई की पूरी सहायता लागू करना ज़रूरी है.

अगर डिवाइस में टेलीफ़ोन हार्डवेयर शामिल नहीं है, तो:

• [C-2-1] सभी एपीआई को नो-ऑप के तौर पर लागू करना ज़रूरी है.

अगर डिवाइस में eUICC या eSIM/एम्बेडेड सिम की सुविधा काम करती है और तीसरे पक्ष के डेवलपर के लिए eSIM की सुविधा उपलब्ध कराने के लिए, मालिकाना हक वाला कोई तरीका शामिल है, तो:

• [C-3-1] EuiccManager API को पूरी तरह से लागू करना ज़रूरी है.

7.4.1.1. नंबर ब्लॉक करने की सुविधा के साथ काम करने वाले डिवाइस

अगर डिवाइस पर लागू किए गए बदलावों की रिपोर्ट में android.hardware.telephony feature दिखता है, तो:

• [C-1-1] इसमें नंबर ब्लॉक करने की सुविधा शामिल होनी चाहिए
• [C-1-2] SDK टूल के दस्तावेज़ में बताए गए तरीके से, BlockedNumberContract और उससे जुड़े एपीआई को पूरी तरह से लागू करना ज़रूरी है.
• [C-1-3] 'BlockedNumberProvider' में मौजूद किसी फ़ोन नंबर से आने वाले सभी कॉल और मैसेज को ब्लॉक करना ज़रूरी है. इसके लिए, ऐप्लिकेशन के साथ कोई इंटरैक्शन नहीं करना चाहिए. हालांकि, SDK टूल के दस्तावेज़ में बताए गए तरीके से, नंबर ब्लॉक करने की सुविधा को कुछ समय के लिए हटाने पर, यह शर्त लागू नहीं होती.
• [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] SDK में बताए गए ConnectionService एपीआई के साथ काम करना चाहिए.
• [C-1-2] जब उपयोगकर्ता किसी तीसरे पक्ष के ऐसे ऐप्लिकेशन से कॉल पर हो जो CAPABILITY_SUPPORT_HOLD के ज़रिए बताई गई, कॉल को होल्ड करने की सुविधा के साथ काम नहीं करता, तो ऐप्लिकेशन को नया इनकमिंग कॉल दिखाना चाहिए. साथ ही, उपयोगकर्ता को इनकमिंग कॉल को स्वीकार या अस्वीकार करने का विकल्प देना चाहिए.
• [C-1-3] इसमें ऐसा ऐप्लिकेशन होना चाहिए जो InCallService को लागू करता हो.

• [C-SR] हमारा सुझाव है कि उपयोगकर्ता को यह सूचना दी जाए कि इनकमिंग कॉल का जवाब देने पर, चल रही कॉल बंद हो जाएगी.

  AOSP में, हेड्स-अप सूचना की मदद से इन ज़रूरी शर्तों को पूरा किया जाता है. इससे उपयोगकर्ता को यह पता चलता है कि किसी इनकमिंग कॉल का जवाब देने पर, मौजूदा कॉल बंद हो जाएगा.

• [C-SR] हमारा सुझाव है कि डिफ़ॉल्ट डायलर ऐप्लिकेशन को पहले से लोड करें. यह ऐप्लिकेशन, कॉल लॉग में कॉल की जानकारी और तीसरे पक्ष के ऐप्लिकेशन का नाम दिखाता है. ऐसा तब होता है, जब तीसरे पक्ष का ऐप्लिकेशन अपने EXTRA_LOG_SELF_MANAGED_CALLS एक्सट्रा बटन को PhoneAccount से 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] SDK के दस्तावेज़ में बताए गए तरीके से, मल्टीकास्ट एपीआई को लागू करना ज़रूरी है.
• [C-1-4] मल्टीकास्ट डीएनएस (mDNS) के साथ काम करना चाहिए. साथ ही, ऑपरेशन के किसी भी समय mDNS पैकेट (224.0.0.251) को फ़िल्टर नहीं करना चाहिए. इनमें ये भी शामिल हैं:
  • भले ही, स्क्रीन चालू न हो.
  • Android Television डिवाइसों के लिए, स्टैंडबाय मोड में भी.
• [C-1-5] WifiManager.enableNetwork() एपीआई के तरीके के कॉल को, फ़िलहाल चालू Network को स्विच करने के लिए ज़रूरी संकेत के तौर पर नहीं माना जाना चाहिए. Network का इस्तेमाल, ऐप्लिकेशन ट्रैफ़िक के लिए डिफ़ॉल्ट रूप से किया जाता है और इसे ConnectivityManager एपीआई के तरीकों से दिखाया जाता है, जैसे कि getActiveNetwork और registerDefaultNetworkCallback. दूसरे शब्दों में, अगर यह पुष्टि हो जाती है कि वाई-फ़ाई नेटवर्क से इंटरनेट ऐक्सेस किया जा रहा है, तो हो सकता है कि डिवाइस पर किसी अन्य नेटवर्क सेवा देने वाली कंपनी (जैसे, मोबाइल डेटा) से मिलने वाले इंटरनेट ऐक्सेस को बंद कर दिया जाए.
• [C-1-6] हमारा सुझाव है कि ConnectivityManager.reportNetworkConnectivity() एपीआई का तरीका इस्तेमाल करने पर, Network पर इंटरनेट ऐक्सेस की फिर से जांच करें. जांच के बाद, अगर पता चलता है कि मौजूदा Network से इंटरनेट ऐक्सेस नहीं हो पा रहा है, तो इंटरनेट ऐक्सेस करने वाले किसी दूसरे नेटवर्क (जैसे, मोबाइल डेटा) पर स्विच करें.
• [C-SR] हमारा सुझाव है कि STA के डिसकनेक्ट होने पर, हर स्कैन की शुरुआत में सोर्स मैक पते और प्रोब अनुरोध फ़्रेम के क्रम संख्या को रैंडम बनाएं.
  • एक स्कैन वाले प्रोब अनुरोध फ़्रेम के हर ग्रुप को एक ही मैक पते का इस्तेमाल करना चाहिए. स्कैन के बीच में मैक पते को रैंडम नहीं किया जाना चाहिए.
  • किसी स्कैन में, प्रोब अनुरोधों के बीच प्रोब अनुरोध का क्रम सामान्य (क्रम से) होना चाहिए.
  • किसी स्कैन के आखिरी प्रोब अनुरोध और अगले स्कैन के पहले प्रोब अनुरोध के बीच, प्रोब अनुरोध का क्रम संख्या अपने-आप बदल जाना चाहिए.
• [C-SR] हमारा सुझाव है कि जब STA डिसकनेक्ट हो, तब प्रोब अनुरोध फ़्रेम में सिर्फ़ इन एलिमेंट को अनुमति दें:
  • SSID पैरामीटर सेट (0)
  • डीएस पैरामीटर सेट (तीन)

अगर डिवाइस में IEEE 802.11 स्टैंडर्ड के मुताबिक, वाई-फ़ाई पावर सेव मोड की सुविधा शामिल है, तो:

• [C-3-1] जब भी कोई ऐप्लिकेशन WifiManager.createWifiLock() और WifiManager.WifiLock.acquire() एपीआई के ज़रिए WIFI_MODE_FULL_HIGH_PERF लॉक या WIFI_MODE_FULL_LOW_LATENCY लॉक को ऐक्सेस करता है और लॉक चालू होता है, तो वाई-फ़ाई पावर सेव मोड को बंद करना ज़रूरी है.
• [C-3-2] डिवाइस के वाई-फ़ाई कम इंतज़ार वाला लॉक (WIFI_MODE_FULL_LOW_LATENCY) मोड चालू होने पर, डिवाइस और ऐक्सेस पॉइंट के बीच औसत राउंड ट्रिप इंतज़ार का समय, वाई-फ़ाई बेहतर परफ़ॉर्मेंस वाला लॉक (WIFI_MODE_FULL_HIGH_PERF) मोड चालू होने पर, डिवाइस और ऐक्सेस पॉइंट के बीच औसत राउंड ट्रिप इंतज़ार के समय से कम होना चाहिए.
• [C-SR] हमारा सुझाव है कि जब भी कम इंतज़ार वाला लॉक (WIFI_MODE_FULL_LOW_LATENCY) हासिल किया जाए और लागू हो जाए, तो वाई-फ़ाई राउंड ट्रिप के इंतज़ार को कम करें.

अगर डिवाइस पर वाई-फ़ाई काम करता है और जगह की जानकारी स्कैन करने के लिए वाई-फ़ाई का इस्तेमाल किया जाता है, तो:

• [C-2-1] WifiManager.isScanAlwaysAvailable एपीआई के तरीके से पढ़ी गई वैल्यू को चालू/बंद करने के लिए, उपयोगकर्ता को कोई सुविधा देना ज़रूरी है.

7.4.2.1. Wi-Fi Direct

डिवाइस पर लागू करने के तरीके:

• इसमें वाई-फ़ाई डायरेक्ट (वाई-फ़ाई पीयर-टू-पीयर) की सुविधा शामिल होनी चाहिए.

अगर डिवाइस में वाई-फ़ाई डायरेक्ट की सुविधा काम करती है, तो:

• [C-1-1] एसडीके दस्तावेज़ में बताए गए तरीके से, उससे जुड़ा Android API लागू करना ज़रूरी है.
• [C-1-2] हार्डवेयर की सुविधा android.hardware.wifi.direct की जानकारी ज़रूर दें.
• [C-1-3] डिवाइस पर वाई-फ़ाई की सुविधा काम करनी चाहिए.
• [C-1-4] यह ज़रूरी है कि डिवाइस पर वाई-फ़ाई और वाई-फ़ाई डायरेक्ट, दोनों एक साथ काम करते हों.

7.4.2.2. वाई-फ़ाई टनल वाला डायरेक्ट लिंक सेटअप करना

डिवाइस पर लागू करने के तरीके:

• इसमें Wi-Fi टनल किए गए डायरेक्ट लिंक सेटअप (TDLS) के लिए सहायता शामिल होनी चाहिए, जैसा कि Android SDK टूल के दस्तावेज़ में बताया गया है.

अगर डिवाइस में TDLS की सुविधा काम करती है और WiFiManager API ने TDLS को चालू किया है, तो:

• [C-1-1] WifiManager.isTdlsSupported के ज़रिए, यह ज़रूर बताना चाहिए कि टीडीएलएस की सुविधा काम करती है.
• TDLS का इस्तेमाल सिर्फ़ तब करना चाहिए, जब यह मुमकिन हो और फ़ायदेमंद हो.
• इसमें कुछ ह्यूरिस्टिक होने चाहिए और जब इसकी परफ़ॉर्मेंस, वाई-फ़ाई ऐक्सेस पॉइंट से कनेक्ट होने की तुलना में खराब हो, तब TDLS का इस्तेमाल नहीं किया जाना चाहिए.

7.4.2.3. वाई-फ़ाई अवेयर

डिवाइस पर लागू करने के तरीके:

• इसमें Wi-Fi Aware के लिए सहायता शामिल होनी चाहिए.

अगर डिवाइस में Wi-Fi Aware की सुविधा काम करती है और तीसरे पक्ष के ऐप्लिकेशन के लिए इस सुविधा का ऐक्सेस दिया जाता है, तो:

• [C-1-1] SDK टूल के दस्तावेज़ में बताए गए तरीके से, WifiAwareManager एपीआई लागू करना ज़रूरी है.
• [C-1-2] android.hardware.wifi.aware फ़ीचर फ़्लैग का एलान करना ज़रूरी है.
• [C-1-3] यह ज़रूरी है कि डिवाइस पर वाई-फ़ाई और वाई-फ़ाई अवेयर, दोनों एक साथ काम करते हों.
• [C-1-4] वाई-फ़ाई अवेयर मैनेजमेंट इंटरफ़ेस का पता, 30 मिनट से ज़्यादा के अंतराल पर और वाई-फ़ाई अवेयर की सुविधा चालू होने पर, रैंडम होना चाहिए.

अगर डिवाइस में सेक्शन 7.4.2.5 में बताए गए तरीके से, वाई-फ़ाई अवेयर और वाई-फ़ाई लोकेशन की सुविधाएं काम करती हैं और तीसरे पक्ष के ऐप्लिकेशन के लिए ये सुविधाएं उपलब्ध कराई जाती हैं, तो:

• [C-2-1] जगह की जानकारी देने वाले डिस्कवरी एपीआई लागू करना ज़रूरी है: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm , और onServiceDiscoveredWithinRange.

7.4.2.4. वाई-फ़ाई पासपॉइंट

डिवाइस पर लागू करने के तरीके:

• इसमें Wi-Fi Passpoint के लिए सहायता शामिल होनी चाहिए.

अगर डिवाइस में वाई-फ़ाई पासपॉइंट की सुविधा काम करती है, तो:

• [C-1-1] SDK टूल के दस्तावेज़ में बताए गए तरीके से, Passpoint से जुड़े WifiManager एपीआई लागू करना ज़रूरी है.
• [C-1-2] यह ज़रूरी है कि डिवाइस, IEEE 802.11u स्टैंडर्ड के साथ काम करे. यह स्टैंडर्ड, खास तौर पर नेटवर्क डिस्कवरी और चुनने से जुड़ा है. जैसे, जनरल विज्ञापन सेवा (जीएएस) और ऐक्सेस नेटवर्क क्वेरी प्रोटोकॉल (एएनक्यूपी).

इसके उलट, अगर डिवाइस में Wi-Fi Passpoint की सुविधा काम नहीं करती है, तो:

• [C-2-1] Passpoint से जुड़े WifiManager एपीआई को लागू करने पर, UnsupportedOperationException दिखना चाहिए.

7.4.2.5. वाई-फ़ाई की जगह की जानकारी (वाई-फ़ाई का राउंड ट्रिप टाइम - आरटीटी)

डिवाइस पर लागू करने के तरीके:

• इसमें वाई-फ़ाई लोकेशन की सुविधा शामिल होनी चाहिए.

अगर डिवाइस में वाई-फ़ाई लोकेशन की सुविधा काम करती है और तीसरे पक्ष के ऐप्लिकेशन के लिए यह सुविधा उपलब्ध है, तो:

• [C-1-1] SDK टूल के दस्तावेज़ में बताए गए तरीके से, WifiRttManager एपीआई लागू करना ज़रूरी है.
• [C-1-2] android.hardware.wifi.rtt फ़ीचर फ़्लैग का एलान करना ज़रूरी है.
• [C-1-3] हर उस आरटीटी बर्स्ट के लिए सोर्स एमएसी पते को रैंडमाइज़ करना ज़रूरी है जो उस वाई-फ़ाई इंटरफ़ेस पर किया जाता है जिस पर आरटीटी किया जा रहा है और जो किसी ऐक्सेस पॉइंट से जुड़ा नहीं है.

7.4.2.6. वाई-फ़ाई Keepalive Offload

डिवाइस पर लागू करने के तरीके:

• इसमें वाई-फ़ाई की मदद से, डिवाइस को चालू रखने की सुविधा के लिए ऑफ़लोड की सुविधा शामिल होनी चाहिए.

अगर डिवाइस में वाई-फ़ाई की गतिविधि को बनाए रखने की सुविधा को ऑफ़लोड करने की सुविधा शामिल है और तीसरे पक्ष के ऐप्लिकेशन के लिए इस सुविधा को उपलब्ध कराया गया है, तो:

• [C-1-1] SocketKeepAlive एपीआई के साथ काम करना चाहिए.

• [C-1-2] यह ज़रूरी है कि डिवाइस, वाई-फ़ाई पर कम से कम तीन और मोबाइल इंटरनेट पर कम से कम एक 'काइलाइव' स्लॉट के साथ काम करे.

अगर डिवाइस में वाई-फ़ाई की मदद से, कनेक्टेड रहने की सुविधा को ऑफ़लोड करने की सुविधा शामिल नहीं है, तो:

• [C-2-1] को ERROR_UNSUPPORTED दिखाना चाहिए.

7.4.2.7. वाई-फ़ाई ईज़ी कनेक्ट (डिवाइस प्रोवाइज़निंग प्रोटोकॉल)

डिवाइस पर लागू करने के तरीके:

• इसमें Wi-Fi Easy Connect (DPP) के लिए सहायता शामिल होनी चाहिए.

अगर डिवाइस में वाई-फ़ाई आसानी से कनेक्ट करने की सुविधा शामिल है और तीसरे पक्ष के ऐप्लिकेशन के लिए इस सुविधा का इस्तेमाल किया जा सकता है, तो:

• [C-1-1] SDK टूल के दस्तावेज़ में बताए गए तरीके से, Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI इंटेंट एपीआई लागू करना ज़रूरी है.
• [C-1-2] WifiManager#isEasyConnectSupported() तरीके से true दिखना चाहिए.

7.4.3. ब्लूटूथ

अगर डिवाइस पर ब्लूटूथ ऑडियो प्रोफ़ाइल काम करती है, तो:

• यह एडवांस ऑडियो कोडेक और ब्लूटूथ ऑडियो कोडेक (जैसे, LDAC) के साथ काम करना चाहिए.

अगर डिवाइस पर HFP, A2DP, और AVRCP काम करते हैं, तो:

• यह कम से कम पांच कनेक्ट किए गए डिवाइसों के साथ काम करना चाहिए.

अगर डिवाइस में android.hardware.vr.high_performance सुविधा का एलान किया जाता है, तो:

• [C-1-1] यह ज़रूरी है कि डिवाइस, ब्लूटूथ 4.2 और ब्लूटूथ ले डेटा लेंथ एक्सटेंशन के साथ काम करता हो.

Android में ब्लूटूथ और ब्लूटूथ लो एनर्जी की सुविधा शामिल है.

अगर डिवाइस में ब्लूटूथ और ब्लूटूथ लो एनर्जी (LE) की सुविधाएं शामिल हैं, तो:

• [C-2-1] प्लैटफ़ॉर्म की काम की सुविधाओं (क्रमशः android.hardware.bluetooth और android.hardware.bluetooth_le) के बारे में एलान करना और प्लैटफ़ॉर्म के एपीआई लागू करना ज़रूरी है.
• डिवाइस के हिसाब से, A2DP, AVRCP, OBEX, HFP वगैरह जैसी ज़रूरी ब्लूटूथ प्रोफ़ाइलें लागू करनी चाहिए.

अगर डिवाइस में ब्लूटूथ लो एनर्जी (LE) की सुविधा काम करती है, तो:

• [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() के ज़रिए पढ़ी गई वैल्यू को चालू/बंद करने के लिए, उपयोगकर्ता को कोई सुविधा देना ज़रूरी है.

अगर डिवाइस में ब्लूटूथ LE और Hearing Aids Profile की सुविधाएं शामिल हैं, जैसा कि ब्लूटूथ LE का इस्तेमाल करके कान की मशीन के ऑडियो के लिए सहायता में बताया गया है, तो:

• [C-5-1] BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID) के लिए, true दिखाना ज़रूरी है.

7.4.4. नियर फ़ील्ड कम्यूनिकेशन

डिवाइस पर लागू करने के तरीके:

• इसमें नियर-फ़ील्ड कम्यूनिकेशन (एनएफ़सी) के लिए, ट्रांसीवर और उससे जुड़ा हार्डवेयर शामिल होना चाहिए.
• [C-0-1] android.nfc.NdefMessage और android.nfc.NdefRecord एपीआई को लागू करना ज़रूरी है. भले ही, इनमें एनएफ़सी के लिए सहायता शामिल न हो या android.hardware.nfc सुविधा का एलान न किया गया हो. ऐसा इसलिए, क्योंकि क्लास, प्रोटोकॉल से स्वतंत्र डेटा दिखाने के फ़ॉर्मैट को दिखाते हैं.

अगर डिवाइस में NFC हार्डवेयर शामिल है और उसे तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराने का प्लान है, तो:

• [C-1-1] android.hardware.nfc सुविधा की रिपोर्ट, android.content.pm.PackageManager.hasSystemFeature() तरीके से देनी ज़रूरी है.
• यह ज़रूरी है कि डिवाइस, नीचे दिए गए एनएफ़सी स्टैंडर्ड की मदद से, एनडीएफ़ मैसेज को पढ़ और लिख सके:
• [C-1-2] यह ज़रूरी है कि यह डिवाइस, एनएफ़सी फ़ोरम के रीडर/राइटर्स के तौर पर काम कर सके.इसके लिए, यह डिवाइस इन एनएफ़सी स्टैंडर्ड का इस्तेमाल करता हो:
  • NfcA (ISO14443-3A)
  • NfcB (ISO14443-3B)
  • NfcF (JIS X 6319-4)
  • IsoDep (ISO 14443-4)
  • एनएफ़सी फ़ोरम टैग टाइप 1, 2, 3, 4, 5 (एनएफ़सी फ़ोरम के मुताबिक)

• [SR] हमारा सुझाव है कि आपके ऐप्लिकेशन में, एनएफ़सी के इन स्टैंडर्ड का इस्तेमाल करके, एनडीएफ़ मैसेज के साथ-साथ रॉ डेटा को पढ़ने और लिखने की सुविधा हो. ध्यान दें कि एनएफ़सी स्टैंडर्ड के लिए, 'इसका सुझाव दिया जाता है' के तौर पर बताया गया है. हालांकि, आने वाले समय में रिलीज़ होने वाले वर्शन के लिए, 'ज़रूरी है' के तौर पर बदलने का प्लान है. इस वर्शन में ये स्टैंडर्ड इस्तेमाल करना ज़रूरी नहीं है. हालांकि, आने वाले वर्शन में इनका इस्तेमाल करना ज़रूरी होगा. Android के इस वर्शन पर काम करने वाले मौजूदा और नए डिवाइसों को, इन ज़रूरी शर्तों को पूरा करने का सुझाव दिया जाता है. इससे, उन्हें आने वाले समय में प्लैटफ़ॉर्म के रिलीज़ किए जाने वाले नए वर्शन पर अपग्रेड करने में मदद मिलेगी.

• [C-1-13] एनएफ़सी डिस्कवरी मोड में, काम करने वाली सभी टेक्नोलॉजी के लिए पोल करना ज़रूरी है.

• डिवाइस के चालू होने पर, स्क्रीन चालू और लॉक-स्क्रीन अनलॉक होने पर, डिवाइस को एनएफ़सी डिस्कवरी मोड में होना चाहिए.
• थिनफ़िल्म एनएफ़सी बारकोड वाले प्रॉडक्ट के बारकोड और यूआरएल (अगर कोड में बदला गया है) को पढ़ने में सक्षम होना चाहिए.

ध्यान दें कि ऊपर बताए गए JIS, ISO, और NFC फ़ोरम के स्पेसिफ़िकेशन के लिए, सार्वजनिक तौर पर उपलब्ध लिंक उपलब्ध नहीं हैं.

Android में, एनएफ़सी होस्ट कार्ड एम्युलेशन (एचसीई) मोड के साथ काम करने की सुविधा शामिल है.

अगर डिवाइस में एनएफ़सी कंट्रोलर चिपसेट शामिल है, जो एचसीई (एनएफ़सीए और/या एनएफ़सीबी के लिए) की सुविधा देता है और ऐप्लिकेशन आईडी (एआईडी) को रूट करने की सुविधा देता है, तो:

• [C-2-1] android.hardware.nfc.hce सुविधा के कॉन्स्टेंट की जानकारी देना ज़रूरी है.
• [C-2-2] Android SDK टूल में बताए गए तरीके के मुताबिक, एनएफ़सी एचसीई एपीआई के साथ काम करना चाहिए.

अगर डिवाइस में NfcF के लिए एचसीई की सुविधा वाला एनएफ़सी कंट्रोलर चिपसेट शामिल है और तीसरे पक्ष के ऐप्लिकेशन के लिए यह सुविधा लागू की गई है, तो:

• [C-3-1] android.hardware.nfc.hcef सुविधा के कॉन्स्टेंट की जानकारी देना ज़रूरी है.
• [C-3-2] Android SDK में बताए गए तरीके से, NfcF कार्ड इम्यूलेशन एपीआई लागू करना ज़रूरी है.

अगर डिवाइस में, इस सेक्शन में बताए गए सामान्य एनएफ़सी सपोर्ट के साथ-साथ रीडर/राइटर्स की भूमिका में MIFARE टेक्नोलॉजी (MIFARE Classic, MIFARE Ultralight, MIFARE Classic पर NDEF) काम करती हैं, तो:

• [C-4-1] Android SDK टूल में बताए गए तरीके के मुताबिक, काम के Android एपीआई लागू करना ज़रूरी है.
• [C-4-2] android.content.pm.PackageManager.hasSystemFeature() तरीके से, com.nxp.mifare सुविधा की रिपोर्ट करना ज़रूरी है. ध्यान दें कि यह Android की स्टैंडर्ड सुविधा नहीं है. इसलिए, यह android.content.pm.PackageManager क्लास में एक कॉन्स्टेंट के तौर पर नहीं दिखती.

7.4.5. नेटवर्क की कम से कम क्षमता

डिवाइस पर लागू करने के तरीके:

• [C-0-1] इसमें डेटा नेटवर्किंग के एक या एक से ज़्यादा फ़ॉर्म के लिए सहायता शामिल होनी चाहिए. खास तौर पर, डिवाइस में कम से कम एक ऐसा डेटा स्टैंडर्ड होना चाहिए जो 200 केबीआईटी/सेकंड या उससे ज़्यादा की स्पीड पर काम कर सके. इस ज़रूरी शर्त को पूरा करने वाली टेक्नोलॉजी के उदाहरणों में, EDGE, HSPA, EV-DO, 802.11g, ईथरनेट, और ब्लूटूथ 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 जैसे मैनेज किए जा रहे एपीआई और getsockname() या IPV6_PKTINFO जैसे एनडीके एपीआई, दोनों को वह आईपी पता और पोर्ट दिखाना चाहिए जिसका इस्तेमाल नेटवर्क पर पैकेट भेजने और पाने के लिए किया जाता है.

आईपीवी6 के साथ काम करने की ज़रूरी शर्तें, नेटवर्क टाइप के हिसाब से तय होती हैं. इन शर्तों के बारे में यहां बताया गया है.

अगर डिवाइस में वाई-फ़ाई काम करता है, तो:

• [C-1-1] यह ज़रूरी है कि डिवाइस, वाई-फ़ाई पर ड्यूअल-स्टैक और सिर्फ़ IPv6 मोड में काम करे.

अगर डिवाइस में ईथरनेट काम करता है, तो:

• [C-2-1] यह ज़रूरी है कि ईथरनेट पर ड्यूअल-स्टैक ऑपरेशन की सुविधा काम करे.

अगर डिवाइस में सेल्युलर डेटा की सुविधा काम करती है, तो:

• मोबाइल इंटरनेट पर IPv6 (सिर्फ़ IPv6 और शायद ड्यूअल-स्टैक) के साथ काम करना चाहिए.

अगर डिवाइस पर एक से ज़्यादा तरह के नेटवर्क काम करते हैं, तो वाई-फ़ाई और मोबाइल डेटा) का इस्तेमाल करते हैं, तो:

• [C-3-1] जब डिवाइस एक से ज़्यादा तरह के नेटवर्क से कनेक्ट हो, तो उसे हर नेटवर्क पर ऊपर बताई गई ज़रूरी शर्तों को एक साथ पूरा करना होगा.

7.4.6. समन्वयन सेटिंग

डिवाइस पर लागू करने के तरीके:

• [C-0-1] अपने-आप सिंक होने की मुख्य सेटिंग डिफ़ॉल्ट रूप से चालू होनी चाहिए, ताकि getMasterSyncAutomatically() का तरीका “सही” दिखाए.

7.4.7. डेटा बचाने की सेटिंग

अगर डिवाइस पर लागू किए गए कनेक्शन में मेज़र किया गया कनेक्शन शामिल है, तो वे ये हैं:

• [SR] हमारा सुझाव है कि आप डेटा बचाने वाला मोड उपलब्ध कराएं.

अगर डिवाइस में डेटा बचाने वाला मोड उपलब्ध है, तो:

• [C-1-1] SDK दस्तावेज़ में बताए गए तरीके के मुताबिक, ConnectivityManager क्लास के सभी एपीआई के साथ काम करना चाहिए
• [C-1-2] सेटिंग में ऐसा यूज़र इंटरफ़ेस होना चाहिए जो Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS इंटेंट को मैनेज करता हो. इससे उपयोगकर्ता, अनुमति वाली सूची में ऐप्लिकेशन जोड़ सकते हैं या उससे ऐप्लिकेशन हटा सकते हैं.

अगर डिवाइस में डेटा बचाने वाला मोड उपलब्ध नहीं है, तो:

• [C-2-1] ConnectivityManager.getRestrictBackgroundStatus() के लिए, RESTRICT_BACKGROUND_STATUS_DISABLED वैल्यू दिखानी चाहिए
• [C-2-2] ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED को ब्रॉडकास्ट नहीं किया जाना चाहिए.
• [C-2-3] ऐप्लिकेशन में ऐसी गतिविधि होनी चाहिए जो Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS इंटेंट को मैनेज करती हो. हालांकि, इसे कोई कार्रवाई न करने वाले तौर पर लागू किया जा सकता है.

7.4.8. सुरक्षित एलिमेंट

अगर डिवाइस पर Open Mobile API के साथ काम करने वाले सुरक्षित एलिमेंट लागू किए गए हैं और उन्हें तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराया गया है, तो:

• [C-1-1] android.se.omapi.SEService.getReaders() तरीके को कॉल करने पर, उपलब्ध Secure Elements रीडर की सूची बनाना ज़रूरी है.

7.5. कैमरे

अगर डिवाइस में कम से कम एक कैमरा है, तो:

• [C-1-1] android.hardware.camera.any फ़ीचर फ़्लैग का एलान करना ज़रूरी है.
• [C-1-2] ऐप्लिकेशन के लिए, डिवाइस पर सबसे ज़्यादा रिज़ॉल्यूशन वाले कैमरा सेंसर से जनरेट हुई इमेज के साइज़ के बराबर, तीन RGBA_8888 बिटमैप को एक साथ असाइन करना ज़रूरी है. ऐसा तब करना चाहिए, जब कैमरा बुनियादी झलक और स्टिल कैप्चर के लिए चालू हो.
• [C-1-3] यह पक्का करना ज़रूरी है कि पहले से इंस्टॉल किया गया डिफ़ॉल्ट कैमरा ऐप्लिकेशन, इंटेंट MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE या MediaStore.ACTION_VIDEO_CAPTURE को मैनेज करता हो. साथ ही, यह भी पक्का करना ज़रूरी है कि जब डेटा पाने वाले ऐप्लिकेशन में ACCESS_FINE_LOCATION न हो, तो डेटा पाने वाले ऐप्लिकेशन को भेजने से पहले, इमेज के मेटाडेटा में उपयोगकर्ता की जगह की जानकारी हटाने की ज़िम्मेदारी, डिफ़ॉल्ट कैमरा ऐप्लिकेशन की हो.

7.5.1. पीछे वाला कैमरा

पीछे की तरफ़ वाला कैमरा, डिवाइस के डिसप्ले के सामने की तरफ़ होता है. इसका मतलब है कि यह किसी सामान्य कैमरे की तरह, डिवाइस के दूसरी तरफ़ मौजूद ऑब्जेक्ट की तस्वीरें लेता है.

डिवाइस पर लागू करने के तरीके:

• इसमें पीछे वाला कैमरा होना चाहिए.

अगर डिवाइस में कम से कम एक पीछे वाला कैमरा है, तो:

• [C-1-1] सुविधा फ़्लैग android.hardware.camera और android.hardware.camera.any की शिकायत करना ज़रूरी है.
• [C-1-2] का रिज़ॉल्यूशन कम से कम 2 मेगापिक्सल होना चाहिए.
• कैमरा ड्राइवर में, हार्डवेयर ऑटो-फ़ोकस या सॉफ़्टवेयर ऑटो-फ़ोकस की सुविधा होनी चाहिए. यह सुविधा, ऐप्लिकेशन सॉफ़्टवेयर के लिए पारदर्शी होनी चाहिए.
• इसमें फ़िक्स्ड-फ़ोकस या EDOF (एक्सटेंडेड डेप्थ ऑफ़ फ़ील्ड) हार्डवेयर हो सकता है.
• इसमें फ़्लैश शामिल हो सकता है.

अगर कैमरे में फ़्लैश है, तो:

• [C-2-1] कैमरे की झलक दिखाने वाले प्लैटफ़ॉर्म पर android.hardware.Camera.PreviewCallback इंस्टेंस के रजिस्टर होने के दौरान, फ़्लैश लैंप नहीं जलना चाहिए. ऐसा तब तक नहीं होना चाहिए, जब तक कि ऐप्लिकेशन ने Camera.Parameters ऑब्जेक्ट के FLASH_MODE_AUTO या FLASH_MODE_ON एट्रिब्यूट को चालू करके, फ़्लैश को साफ़ तौर पर चालू न किया हो. ध्यान दें कि यह पाबंदी, डिवाइस के पहले से मौजूद सिस्टम कैमरा ऐप्लिकेशन पर लागू नहीं होती. यह सिर्फ़ Camera.PreviewCallback का इस्तेमाल करने वाले तीसरे पक्ष के ऐप्लिकेशन पर लागू होती है.

7.5.2. सामने वाला कैमरा

सामने वाला कैमरा, डिवाइस के उसी हिस्से में होता है जहां डिसप्ले होता है. इसका इस्तेमाल आम तौर पर, उपयोगकर्ता की इमेज लेने के लिए किया जाता है. जैसे, वीडियो कॉन्फ़्रेंसिंग और इससे मिलते-जुलते ऐप्लिकेशन के लिए.

डिवाइस पर लागू करने के तरीके:

• इसमें सामने वाला कैमरा शामिल हो सकता है.

अगर डिवाइस में कम से कम एक सामने वाला कैमरा है, तो:

• [C-1-1] सुविधा फ़्लैग android.hardware.camera.any और android.hardware.camera.front की शिकायत करना ज़रूरी है.
• [C-1-2] इसका रिज़ॉल्यूशन कम से कम VGA (640x480 पिक्सल) होना चाहिए.
• [C-1-3] Camera API के लिए, सामने वाले कैमरे को डिफ़ॉल्ट तौर पर इस्तेमाल नहीं किया जाना चाहिए. साथ ही, एपीआई को इस तरह कॉन्फ़िगर नहीं किया जाना चाहिए कि वह सामने वाले कैमरे को पीछे वाले कैमरे के तौर पर इस्तेमाल करे. भले ही, डिवाइस में सिर्फ़ यही कैमरा हो.
• [C-1-4] जब मौजूदा ऐप्लिकेशन ने साफ़ तौर पर अनुरोध किया हो कि android.hardware.Camera.setDisplayOrientation() तरीके का इस्तेमाल करके, कैमरे के डिसप्ले को घुमाया जाए, तो कैमरे की झलक को ऐप्लिकेशन के तय किए गए ओरिएंटेशन के हिसाब से, हॉरिज़ॉन्टल तौर पर मिरर किया जाना चाहिए. इसके उलट, अगर मौजूदा ऐप्लिकेशन साफ़ तौर पर यह अनुरोध नहीं करता कि android.hardware.Camera.setDisplayOrientation() तरीके का इस्तेमाल करके, कैमरे के डिसप्ले को घुमाया जाए, तो झलक को डिवाइस के डिफ़ॉल्ट हॉरिज़ॉन्टल ऐक्सिस के साथ मिरर किया जाना चाहिए.
• [C-1-5] कैप्चर की गई फ़ाइनल इमेज या वीडियो स्ट्रीम को ऐप्लिकेशन कॉलबैक में वापस नहीं भेजना चाहिए या मीडिया स्टोरेज में सेव नहीं करना चाहिए.
• [C-1-6] पोस्टव्यू में दिखाई गई इमेज को उसी तरह से दिखाना चाहिए जिस तरह से कैमरे की झलक वाली इमेज स्ट्रीम दिखाई जाती है.
• इसमें सेक्शन 7.5.1 में बताई गई, पीछे की ओर लगे कैमरों के लिए उपलब्ध सुविधाएं (जैसे, ऑटो-फ़ोकस, फ़्लैश वगैरह) शामिल हो सकती हैं.

अगर डिवाइस को उपयोगकर्ता घुमा सकता है, जैसे कि एक्सीलरॉमीटर की मदद से अपने-आप घूमना या उपयोगकर्ता के इनपुट से मैन्युअल तरीके से घूमना:

• [C-2-1] कैमरे की झलक, डिवाइस के मौजूदा ओरिएंटेशन के हिसाब से हॉरिज़ॉन्टल तौर पर मिरर की जानी चाहिए.

7.5.3. बाहरी कैमरा

डिवाइस पर लागू करने के तरीके:

• इसमें किसी ऐसे बाहरी कैमरे के लिए सहायता शामिल हो सकती है जो ज़रूरी नहीं है कि हमेशा कनेक्ट रहे.

अगर डिवाइस में बाहरी कैमरे के साथ काम करने की सुविधा शामिल है, तो:

• [C-1-1] प्लैटफ़ॉर्म की सुविधा के फ़्लैग android.hardware.camera.external और android.hardware camera.any के बारे में ज़रूर बताएं.
• [C-1-2] अगर बाहरी कैमरा यूएसबी होस्ट पोर्ट से कनेक्ट होता है, तो यह ज़रूरी है कि डिवाइस में यूएसबी वीडियो क्लास (यूवीसी 1.0 या उसके बाद का वर्शन) की सुविधा हो.
• [C-1-3] कैमरे के लिए सीटीएस टेस्ट पास करना ज़रूरी है. इसके लिए, बाहरी कैमरे के डिवाइस को कनेक्ट करना ज़रूरी है. कैमरे की सीटीएस जांच की जानकारी source.android.com पर उपलब्ध है.
• अच्छी क्वालिटी वाली बिना कोड वाली स्ट्रीम (जैसे, रॉ या अलग से कंप्रेस की गई पिक्चर स्ट्रीम) को ट्रांसफ़र करने के लिए, MJPEG जैसे वीडियो कंप्रेस करने की सुविधा होनी चाहिए.
• एक से ज़्यादा कैमरे इस्तेमाल करने की सुविधा हो सकती है.
• कैमरे से वीडियो एन्कोड करने की सुविधा मिल सकती है.

अगर कैमरे से वीडियो एन्कोड करने की सुविधा काम करती है, तो:

• [C-2-1] डिवाइस पर एक साथ, बिना कोड वाली / एमजेपीईजी स्ट्रीम (QVGA या उससे ज़्यादा रिज़ॉल्यूशन) को ऐक्सेस किया जा सकता है.

7.5.4. Camera API का व्यवहार

Android में कैमरे को ऐक्सेस करने के लिए दो एपीआई पैकेज शामिल हैं. नया android.hardware.camera2 API, ऐप्लिकेशन को कैमरे के लोअर-लेवल कंट्रोल को एक्सपोज़ करता है. इसमें, ज़ीरो-कॉपी बर्स्ट/स्ट्रीमिंग फ़्लो और एक्सपोज़र, गेन, व्हाइट बैलेंस गेन, कलर कन्वर्ज़न, डेनॉइज़िंग, शार्पनिंग वगैरह के हर फ़्रेम कंट्रोल शामिल हैं.

पुराने एपीआई पैकेज,android.hardware.Camera को Android 5.0 में 'अब काम नहीं करता' के तौर पर मार्क किया गया है. हालांकि, ऐप्लिकेशन के इस्तेमाल के लिए यह अब भी उपलब्ध होना चाहिए. Android डिवाइस पर एपीआई लागू करने के लिए, यह ज़रूरी है कि एपीआई के साथ काम करने की सुविधा लगातार उपलब्ध रहे. इस बारे में इस सेक्शन और Android SDK टूल में बताया गया है.

बंद हो चुकी android.hardware.Camera क्लास और नए android.hardware.camera2 पैकेज में मौजूद सभी सुविधाओं की परफ़ॉर्मेंस और क्वालिटी, दोनों एपीआई में एक जैसी होनी चाहिए. उदाहरण के लिए, एक जैसी सेटिंग के साथ, ऑटोफ़ोकस की स्पीड और सटीक होने की ज़रूरत है. साथ ही, कैप्चर की गई इमेज की क्वालिटी भी एक जैसी होनी चाहिए. दो एपीआई के अलग-अलग सेमेटिक्स पर निर्भर करने वाली सुविधाओं के लिए, तेज़ी या क्वालिटी का मेल खाना ज़रूरी नहीं है. हालांकि, इन सुविधाओं की क्वालिटी और तेज़ी जितनी हो सके उतनी मेल खानी चाहिए.

डिवाइस में कैमरे से जुड़े एपीआई लागू करने के लिए, सभी उपलब्ध कैमरों के लिए नीचे बताए गए तरीके का इस्तेमाल करना ज़रूरी है. डिवाइस पर लागू करने के तरीके:

• [C-0-1] अगर किसी ऐप्लिकेशन ने कभी android.hardware.Camera.Parameters.setPreviewFormat(int) को कॉल नहीं किया है, तो ऐप्लिकेशन कॉलबैक को दिए गए डेटा की झलक के लिए, android.hardware.PixelFormat.YCbCr_420_SP का इस्तेमाल करना ज़रूरी है.
• [C-0-2] जब कोई ऐप्लिकेशन android.hardware.Camera.PreviewCallback इंस्टेंस रजिस्टर करता है और सिस्टम onPreviewFrame() तरीके को कॉल करता है और झलक का फ़ॉर्मैट YCbCr_420_SP होता है, तो डेटा को byte[] में onPreviewFrame() में पास किया जाना चाहिए. साथ ही, यह डेटा NV21 एन्कोडिंग फ़ॉर्मैट में होना चाहिए. इसका मतलब है कि NV21, डिफ़ॉल्ट तौर पर होना चाहिए.
• [C-0-3] android.hardware.Camera के लिए, सामने और पीछे के दोनों कैमरों की झलक दिखाने के लिए, YV12 फ़ॉर्मैट (जैसा कि android.graphics.ImageFormat.YV12 कॉन्स्टेंट से पता चलता है) का इस्तेमाल करना ज़रूरी है. (हार्डवेयर वीडियो एन्कोडर और कैमरा, किसी भी नेटिव पिक्सल फ़ॉर्मैट का इस्तेमाल कर सकते हैं. हालांकि, डिवाइस में YV12 में बदलाव करने की सुविधा होनी चाहिए.)
• [C-0-4] android.media.ImageReader एपीआई की मदद से, android.hardware.camera2 डिवाइसों के लिए android.hardware.ImageFormat.YUV_420_888 और android.hardware.ImageFormat.JPEG फ़ॉर्मैट को आउटपुट के तौर पर इस्तेमाल किया जाना चाहिए. ये ऐसे डिवाइस होते हैं जो android.request.availableCapabilities में REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE की सुविधा का विज्ञापन करते हैं.
• [C-0-5] Android SDK टूल के दस्तावेज़ में शामिल Camera API को पूरी तरह से लागू करना ज़रूरी है. भले ही, डिवाइस में ऑटोफ़ोकस करने वाला हार्डवेयर या अन्य सुविधाएं हों. उदाहरण के लिए, जिन कैमरों में ऑटोफ़ोकस की सुविधा नहीं होती है उन्हें भी रजिस्टर किए गए किसी भी android.hardware.Camera.AutoFocusCallback इंस्टेंस को कॉल करना होगा. भले ही, ऑटोफ़ोकस की सुविधा न होने वाले कैमरे के लिए इसका कोई मतलब न हो. ध्यान दें कि यह फ़्रंट-फ़ेसिंग कैमरों पर भी लागू होता है. उदाहरण के लिए, ज़्यादातर फ़्रंट-फ़ेसिंग कैमरे ऑटोफ़ोकस की सुविधा के साथ काम नहीं करते. इसके बावजूद, एपीआई कॉलबैक को ऊपर बताए गए तरीके से “फ़ेक” किया जाना चाहिए.
• [C-0-6] android.hardware.Camera.Parameters क्लास और android.hardware.camera2.CaptureRequest क्लास में, हर पैरामीटर के नाम को कॉन्स्टेंट के तौर पर तय किया जाना चाहिए. इसके उलट, डिवाइस के लागू होने पर, android.hardware.Camera.setParameters() तरीके में पास की गई स्ट्रिंग कॉन्स्टेंट को स्वीकार नहीं किया जाना चाहिए. हालांकि, android.hardware.Camera.Parameters पर कॉन्स्टेंट के तौर पर दस्तावेज़ में दर्ज की गई स्ट्रिंग कॉन्स्टेंट को स्वीकार किया जा सकता है. इसका मतलब है कि अगर हार्डवेयर की अनुमति है, तो डिवाइस पर सभी स्टैंडर्ड कैमरा पैरामीटर काम करने चाहिए. साथ ही, कस्टम कैमरा पैरामीटर टाइप काम नहीं करने चाहिए. उदाहरण के लिए, हाई डाइनैमिक रेंज (एचडीआर) इमेजिंग तकनीकों का इस्तेमाल करके इमेज कैप्चर करने की सुविधा वाले डिवाइसों में, कैमरा पैरामीटर Camera.SCENE_MODE_HDR का इस्तेमाल किया जाना चाहिए.
• [C-0-7] Android SDK में बताए गए तरीके के मुताबिक, android.info.supportedHardwareLevel प्रॉपर्टी की मदद से, सहायता के सही लेवल की जानकारी देना ज़रूरी है. साथ ही, फ़्रेमवर्क की सुविधा के फ़्लैग की सही जानकारी देना ज़रूरी है.
• [C-0-8] android.request.availableCapabilities प्रॉपर्टी की मदद से, android.hardware.camera2 के कैमरे की अलग-अलग सुविधाओं के बारे में भी एलान करना ज़रूरी है. साथ ही, सुविधा के फ़्लैग के बारे में भी एलान करना ज़रूरी है. अगर डिवाइस से जुड़ा कोई कैमरा डिवाइस इस सुविधा के साथ काम करता है, तो सुविधा के फ़्लैग के बारे में बताना ज़रूरी है.
• [C-0-9] जब भी कैमरे से कोई नई फ़ोटो ली जाती है और फ़ोटो की एंट्री को मीडिया स्टोर में जोड़ दिया जाता है, तब Camera.ACTION_NEW_PICTURE इंटेंट को ब्रॉडकास्ट करना ज़रूरी है.
• [C-0-10] जब भी कैमरे से कोई नया वीडियो रिकॉर्ड किया जाता है और मीडिया स्टोर में फ़ोटो की एंट्री जोड़ी जाती है, तब Camera.ACTION_NEW_VIDEO इंटेंट को ब्रॉडकास्ट करना ज़रूरी है.
• [C-0-11] यह ज़रूरी है कि सभी कैमरों को, इस्तेमाल में न होने वाले android.hardware.Camera एपीआई के ज़रिए ऐक्सेस किया जा सके. साथ ही, उन्हें android.hardware.camera2 एपीआई के ज़रिए भी ऐक्सेस किया जा सके.
• [C-SR] एक ही दिशा में फ़ोकस करने वाले कई आरजीबी कैमरों वाले डिवाइसों के लिए, हमारा सुझाव है कि आप ऐसे लॉजिकल कैमरा डिवाइस का इस्तेमाल करें जिसमें CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA की सुविधा मौजूद हो. इसमें उस दिशा में फ़ोकस करने वाले सभी आरजीबी कैमरे, फ़िज़िकल सब-डिवाइस के तौर पर शामिल होने चाहिए.

अगर डिवाइस में, तीसरे पक्ष के ऐप्लिकेशन के लिए मालिकाना हक वाला कैमरा एपीआई उपलब्ध कराया जाता है, तो:

• [C-1-1] android.hardware.camera2 एपीआई का इस्तेमाल करके, ऐसा कैमरा एपीआई लागू करना ज़रूरी है.
• android.hardware.camera2 एपीआई को वेंडर टैग और/या एक्सटेंशन दे सकता है.

7.5.5. कैमरे का ओरिएंटेशन

अगर डिवाइस में सामने या पीछे वाला कैमरा है, तो ऐसे कैमरे:

• [C-1-1] यह ज़रूरी है कि कैमरे का लंबा डाइमेंशन, स्क्रीन के लंबे डाइमेंशन के साथ अलाइन हो. इसका मतलब है कि जब डिवाइस को लैंडस्केप ओरिएंटेशन में रखा जाता है, तो कैमरों को लैंडस्केप ओरिएंटेशन में इमेज कैप्चर करनी चाहिए. यह डिवाइस के नेचुरल ओरिएंटेशन के बावजूद लागू होता है. इसका मतलब है कि यह लैंडस्केप-प्राइमरी डिवाइसों के साथ-साथ, पोर्ट्रेट-प्राइमरी डिवाइसों पर भी लागू होता है.

7.6. डिवाइस की मेमोरी और स्टोरेज

7.6.1. डिवाइस की कम से कम मेमोरी और स्टोरेज

डिवाइस पर लागू करने के तरीके:

• [C-0-1] ऐप्लिकेशन में डाउनलोड मैनेजर होना चाहिए. ऐप्लिकेशन, डेटा फ़ाइलों को डाउनलोड करने के लिए इसका इस्तेमाल कर सकते हैं. साथ ही, यह ज़रूरी है कि वे डिफ़ॉल्ट “कैश मेमोरी” लोकेशन में, कम से कम 100 एमबी साइज़ की अलग-अलग फ़ाइलें डाउनलोड कर सकें.

7.6.2. ऐप्लिकेशन का शेयर किया गया स्टोरेज

डिवाइस पर लागू करने के तरीके:

• [C-0-1] ऐप्लिकेशन के लिए स्टोरेज उपलब्ध कराना ज़रूरी है. इसे अक्सर “शेयर किया गया बाहरी स्टोरेज”, “ऐप्लिकेशन के लिए शेयर किया गया स्टोरेज” या उस पर माउंट किए गए Linux पाथ "/sdcard" के तौर पर भी जाना जाता है.
• [C-0-2] को डिफ़ॉल्ट रूप से माउंट किए गए शेयर किए गए स्टोरेज के साथ कॉन्फ़िगर किया जाना चाहिए.दूसरे शब्दों में, “बाहर से” कॉन्फ़िगर किया जाना चाहिए. भले ही, स्टोरेज को किसी इंटरनल स्टोरेज कॉम्पोनेंट या हटाए जा सकने वाले स्टोरेज मीडियम (जैसे, सिक्योर डिजिटल कार्ड स्लॉट) पर लागू किया गया हो.
• [C-0-3] ऐप्लिकेशन के शेयर किए गए स्टोरेज को सीधे Linux पाथ sdcard पर माउंट करना ज़रूरी है. इसके अलावा, sdcard से असल माउंट पॉइंट तक Linux सिंबल लिंक शामिल करना भी ज़रूरी है.
• [C-0-4] SDK टूल में बताए गए तरीके के मुताबिक, इस शेयर किए गए स्टोरेज पर android.permission.WRITE_EXTERNAL_STORAGE अनुमति लागू करना ज़रूरी है.
• [C-0-5] एपीआई लेवल 29 या उसके बाद के वर्शन को टारगेट करने वाले सभी ऐप्लिकेशन के लिए, स्कोप वाला स्टोरेज डिफ़ॉल्ट रूप से चालू होना चाहिए. हालांकि, इन स्थितियों में ऐसा नहीं करना चाहिए:
  • जब ऐप्लिकेशन को डिवाइस के एपीआई लेवल 29 पर अपग्रेड होने से पहले इंस्टॉल किया गया था, तो इस बात से कोई फ़र्क़ नहीं पड़ता कि ऐप्लिकेशन को किस एपीआई के लिए टारगेट किया गया है.
  • जब ऐप्लिकेशन ने अपने मेनिफ़ेस्ट में android:requestLegacyExternalStorage="true" का अनुरोध किया हो.
  • जब ऐप्लिकेशन को android.permission.WRITE_MEDIA_STORAGE अनुमति दी जाती है.
• [C-0-6] यह ज़रूरी है कि जिन ऐप्लिकेशन में स्कोप वाला स्टोरेज चालू है उनके पास, अपने ऐप्लिकेशन के लिए बनी डायरेक्ट्री के बाहर की फ़ाइलों का सीधा फ़ाइल सिस्टम ऐक्सेस न हो. यह ऐक्सेस, Context एपीआई के तरीकों से मिलता है, जैसे कि Context.getExternalFilesDirs(), Context.getExternalCacheDirs(), Context.getExternalMediaDirs(), और Context.getObbDirs().
• [C-0-7] मीडिया फ़ाइलों में सेव की गई जगह की जानकारी वाले मेटाडेटा को छिपाना ज़रूरी है. जैसे, जीपीएस Exif टैग. ऐसा तब किया जाना चाहिए, जब उन फ़ाइलों को MediaStore से ऐक्सेस किया जा रहा हो. हालांकि, अगर कॉल करने वाले ऐप्लिकेशन के पास ACCESS_MEDIA_LOCATION की अनुमति है, तो ऐसा नहीं करना चाहिए.

डिवाइस पर इनमें से किसी एक तरीके का इस्तेमाल करके, ऊपर दी गई ज़रूरी शर्तें पूरी की जा सकती हैं:

• उपयोगकर्ता के पास, रिमूवेबल स्टोरेज का ऐक्सेस होना चाहिए. जैसे, सिक्योर डिजिटल (एसडी) कार्ड स्लॉट.
• Android Open Source Project (AOSP) में लागू किए गए इंटरनल (हटाए नहीं जा सकने वाले) स्टोरेज का एक हिस्सा.

अगर डिवाइस में ऊपर बताई गई ज़रूरी शर्तों को पूरा करने के लिए, डिवाइस में मौजूद स्टोरेज का इस्तेमाल किया जाता है, तो:

• [C-1-1] स्लॉट में स्टोरेज का कोई माध्यम न होने पर, उपयोगकर्ता को चेतावनी देने के लिए, टॉस्ट या पॉप-अप यूज़र इंटरफ़ेस लागू करना ज़रूरी है.
• [C-1-2] इसमें FAT फ़ॉर्मैट वाला स्टोरेज मीडियम (जैसे, एसडी कार्ड) शामिल होना चाहिए. इसके अलावा, खरीदारी के समय बॉक्स और अन्य उपलब्ध कॉन्टेंट पर यह भी दिखना चाहिए कि स्टोरेज मीडियम को अलग से खरीदना होगा.

अगर डिवाइस में ऊपर बताई गई ज़रूरी शर्तों को पूरा करने के लिए, डिवाइस में पहले से मौजूद स्टोरेज का इस्तेमाल किया जाता है, तो:

• संगठन में काम करने वालों के साथ ऐप्लिकेशन शेयर करने की सुविधा के लिए, AOSP के स्टोरेज का इस्तेमाल करना चाहिए.
• ऐप्लिकेशन के निजी डेटा के साथ स्टोरेज शेयर कर सकता है.

अगर डिवाइस में शेयर किए गए स्टोरेज के कई पाथ शामिल हैं, जैसे कि एसडी कार्ड स्लॉट और शेयर किया गया इंटरनल स्टोरेज, तो:

• [C-2-1] सिर्फ़ पहले से इंस्टॉल किए गए और खास सुविधाओं वाले Android ऐप्लिकेशन को सेकंडरी बाहरी स्टोरेज में डेटा लिखने की WRITE_MEDIA_STORAGE अनुमति देनी चाहिए. हालांकि, अपने पैकेज से जुड़ी डायरेक्ट्री में या ACTION_OPEN_DOCUMENT_TREE इंटेंट को ट्रिगर करके वापस मिले URI में डेटा लिखने पर, यह ज़रूरी नहीं है.
• [C-2-2] यह ज़रूरी है कि android.permission.WRITE_MEDIA_STORAGE अनुमति से जुड़ा डायरेक्ट ऐक्सेस, सिर्फ़ उन ऐप्लिकेशन को दिया जाए जो उपयोगकर्ता को दिखते हैं. ऐसा तब किया जाना चाहिए, जब android.permission.WRITE_EXTERNAL_STORAGE अनुमति भी दी गई हो.
• [SR] हमारा सुझाव है कि पहले से इंस्टॉल किए गए और खास सुविधाओं वाले Android ऐप्लिकेशन, android.permission.WRITE_MEDIA_STORAGE से मिले सीधे ऐक्सेस के बजाय, स्टोरेज डिवाइसों के साथ इंटरैक्ट करने के लिए, MediaStore जैसे सार्वजनिक एपीआई का इस्तेमाल करें.

अगर डिवाइस में यूएसबी पोर्ट है और वह यूएसबी पीरियफ़रल मोड के साथ काम करता है, तो:

• [C-3-1] ऐप्लिकेशन के शेयर किए गए स्टोरेज में मौजूद डेटा को होस्ट कंप्यूटर से ऐक्सेस करने का तरीका ज़रूर उपलब्ध कराएं.
• Android की मीडिया स्कैनर सेवा और android.provider.MediaStore की मदद से, दोनों स्टोरेज पाथ से कॉन्टेंट को साफ़ तौर पर दिखाना चाहिए.
• यूएसबी स्टोरेज का इस्तेमाल किया जा सकता है. हालांकि, इस ज़रूरी शर्त को पूरा करने के लिए, मीडिया ट्रांसफ़र प्रोटोकॉल का इस्तेमाल करना चाहिए.

अगर डिवाइस में यूएसबी पेरिफ़रल मोड वाला यूएसबी पोर्ट है और वह मीडिया ट्रांसफ़र प्रोटोकॉल के साथ काम करता है, तो:

• यह Android File Transfer, Android MTP होस्ट के साथ काम करना चाहिए.
• यूएसबी डिवाइस क्लास 0x00 की रिपोर्ट करनी चाहिए.
• यूएसबी इंटरफ़ेस का नाम 'MTP' होना चाहिए.

7.6.3. एडॉप्टेबल स्टोरेज

अगर डिवाइस, टीवी के बजाय मोबाइल है, तो डिवाइस को लागू करने के लिए:

• [SR] हमारा सुझाव है कि आप अपनाने लायक स्टोरेज को ऐसी जगह पर सेट अप करें जहां यह लंबे समय तक काम करता रहे. ऐसा इसलिए, क्योंकि गलती से डिसकनेक्ट होने पर डेटा मिट सकता है या खराब हो सकता है.

अगर डिवाइस में, स्टोरेज डिवाइस का पोर्ट ऐसी जगह पर है जहां वह लंबे समय तक स्थिर रहता है, जैसे कि बैटरी कम्पार्टमेंट या सुरक्षा कवर के अंदर, तो डिवाइस को लागू करने के लिए ये तरीके अपनाए जा सकते हैं:

• [SR] हमारा सुझाव है कि आप एडॉप्टेबल स्टोरेज को लागू करें.

7.7. यूएसबी

अगर डिवाइस में यूएसबी पोर्ट है, तो:

• यह यूएसबी पेरिफ़रल मोड और यूएसबी होस्ट मोड के साथ काम करना चाहिए.

7.7.1. यूएसबी पेरिफ़रल मोड

अगर डिवाइस में, यूएसबी पोर्ट के साथ-साथ, पेरिफ़रल मोड की सुविधा भी है, तो:

• [C-1-1] पोर्ट को ऐसे यूएसबी होस्ट से कनेक्ट किया जा सकता है जिसमें स्टैंडर्ड टाइप-A या टाइप-C यूएसबी पोर्ट हो.
• [C-1-2] android.os.Build.SERIAL की मदद से, USB स्टैंडर्ड डिवाइस डिस्क्रिप्टर में iSerialNumber की सही वैल्यू की जानकारी देनी ज़रूरी है.
• [C-1-3] टाइप-C रेज़िस्टर स्टैंडर्ड के मुताबिक, 1.5A और 3.0A चार्जर का पता लगाना ज़रूरी है. साथ ही, अगर विज्ञापन में टाइप-C यूएसबी की सुविधा का इस्तेमाल किया गया है, तो विज्ञापन में हुए बदलावों का पता लगाना ज़रूरी है.
• [SR] पोर्ट में माइक्रो-बी, माइक्रो-एबी या टाइप-सी यूएसबी फ़ॉर्म फ़ैक्टर का इस्तेमाल किया जाना चाहिए. हमारा सुझाव है कि मौजूदा और नए Android डिवाइसों को इन ज़रूरी शर्तों को पूरा करना चाहिए, ताकि वे आने वाले समय में प्लैटफ़ॉर्म के रिलीज़ किए जाने वाले नए वर्शन पर अपग्रेड कर सकें.
• [SR] पोर्ट, डिवाइस के सबसे नीचे होना चाहिए (डिवाइस के सामान्य ओरिएंटेशन के हिसाब से). इसके अलावा, सभी ऐप्लिकेशन (होम स्क्रीन भी शामिल है) के लिए, सॉफ़्टवेयर स्क्रीन रोटेशन की सुविधा चालू की जा सकती है, ताकि डिवाइस को सबसे नीचे पोर्ट के साथ ओरिएंट करने पर, डिसप्ले सही तरीके से दिखे. हमारा सुझाव है कि मौजूदा और नए Android डिवाइसों को इन ज़रूरी शर्तों को पूरा करना चाहिए, ताकि वे आने वाले समय में प्लैटफ़ॉर्म के रिलीज़ किए जाने वाले वर्शन पर अपग्रेड कर सकें.
• [SR] यूएसबी बैटरी चार्जिंग स्पेसिफ़िकेशन, रिविज़न 1.2 में बताए गए तरीके के मुताबिक, एचएस चिर्प और ट्रैफ़िक के दौरान 1.5 ए करंट खींचने के लिए, सपोर्ट लागू करना चाहिए. हमारा सुझाव है कि मौजूदा और नए Android डिवाइसों को इन ज़रूरी शर्तों को पूरा करना चाहिए, ताकि वे आने वाले समय में प्लैटफ़ॉर्म के रिलीज़ किए जाने वाले नए वर्शन पर अपग्रेड कर सकें.
• [SR] हमारा सुझाव है कि चार्जिंग के ऐसे मालिकाना तरीकों का इस्तेमाल न करें जो Vbus वोल्टेज को डिफ़ॉल्ट लेवल से ज़्यादा कर दें या सिंक/सोर्स की भूमिकाओं में बदलाव कर दें. ऐसा करने पर, USB Power Delivery के स्टैंडर्ड तरीकों के साथ काम करने वाले चार्जर या डिवाइसों के साथ इंटरऑपरेबिलिटी से जुड़ी समस्याएं आ सकती हैं. हालांकि, इसे "ज़रूर इस्तेमाल करें" के तौर पर दिखाया गया है, लेकिन आने वाले समय में Android के नए वर्शन में, हो सकता है कि हम सभी टाइप-C डिवाइसों के लिए, स्टैंडर्ड टाइप-C चार्जर के साथ पूरी तरह काम करने की ज़रूरी शर्त लागू करें.
• [SR] अगर डिवाइस में टाइप-सी यूएसबी और यूएसबी होस्ट मोड की सुविधा है, तो डेटा और पावर की भूमिका बदलने के लिए, पावर डिलीवरी की सुविधा का इस्तेमाल करने का सुझाव दिया जाता है.
• यह ज़रूरी है कि यह डिवाइस, हाई-वोल्टेज चार्जिंग के लिए पावर डिलीवरी की सुविधा के साथ-साथ, डिसप्ले आउट जैसे अन्य मोड के साथ काम करे.
• Android SDK टूल के दस्तावेज़ में बताए गए तरीके से, Android Open Accessory (AOA) API और स्पेसिफ़िकेशन को लागू करना चाहिए.

अगर डिवाइस में यूएसबी पोर्ट और AOA स्पेसिफ़िकेशन लागू किया गया है, तो:

• [C-2-1] यह ज़रूरी है कि आपने हार्डवेयर की सुविधा android.hardware.usb.accessory के साथ काम करने की जानकारी दी हो.
• [C-2-2] यूएसबी स्टोरेज क्लास में, यूएसबी स्टोरेज के इंटरफ़ेस की जानकारी iInterface स्ट्रिंग के आखिर में "android" स्ट्रिंग शामिल होनी चाहिए

7.7.2. यूएसबी होस्ट मोड

अगर डिवाइस में होस्ट मोड के साथ काम करने वाला यूएसबी पोर्ट शामिल है, तो:

• [C-1-1] Android SDK में बताए गए तरीके से, Android USB होस्ट API को लागू करना ज़रूरी है. साथ ही, यह भी ज़रूरी है कि हार्डवेयर की सुविधा android.hardware.usb.host के साथ काम करने की जानकारी दी जाए.
• [C-1-2] स्टैंडर्ड यूएसबी डिवाइसों को कनेक्ट करने के लिए, डिवाइसों में यह सुविधा होनी चाहिए. इसका मतलब है कि इनमें से कोई एक काम करना चाहिए:
  • डिवाइस में टाइप-सी पोर्ट होना चाहिए या डिवाइस में मौजूद मालिकाना पोर्ट को स्टैंडर्ड यूएसबी टाइप-सी पोर्ट (यूएसबी टाइप-सी डिवाइस) में बदलने वाली केबल के साथ शिप किया जाना चाहिए.
  • डिवाइस में टाइप-A पोर्ट होना चाहिए या डिवाइस में मौजूद मालिकाना पोर्ट को स्टैंडर्ड यूएसबी टाइप-A पोर्ट में बदलने वाली केबल के साथ शिप किया जाना चाहिए.
  • डिवाइस में माइक्रो-AB पोर्ट होना चाहिए. साथ ही, डिवाइस के साथ एक ऐसी केबल भी होनी चाहिए जो स्टैंडर्ड टाइप-A पोर्ट के साथ काम करती हो.
• [C-1-3] डिवाइस को यूएसबी टाइप-ए या माइक्रो-एबी पोर्ट को टाइप-सी पोर्ट (जगह) में बदलने वाले अडैप्टर के साथ शिप नहीं किया जाना चाहिए.
• [C-SR] हमारा सुझाव है कि आप Android SDK के दस्तावेज़ में बताए गए तरीके से, यूएसबी ऑडियो क्लास को लागू करें.
• होस्ट मोड में, कनेक्ट किए गए यूएसबी डिवाइस को चार्ज करने की सुविधा होनी चाहिए. साथ ही, यूएसबी टाइप-सी कनेक्टर के लिए यूएसबी टाइप-सी केबल और कनेक्टर स्पेसिफ़िकेशन रिविज़न 1.2 के टर्मिनेशन पैरामीटर सेक्शन में बताए गए मुताबिक, सोर्स करंट कम से कम 1.5 ऐंपियर होना चाहिए. इसके अलावा, माइक्रो-एबी कनेक्टर के लिए यूएसबी बैटरी चार्जिंग स्पेसिफ़िकेशन, रिविज़न 1.2 में बताए गए मुताबिक, चार्जिंग डाउनस्ट्रीम पोर्ट(सीडीपी) आउटपुट करंट की रेंज का इस्तेमाल किया जाना चाहिए.
• यूएसबी टाइप-सी स्टैंडर्ड को लागू और इस्तेमाल करना चाहिए.

अगर डिवाइस में होस्ट मोड और यूएसबी ऑडियो क्लास के साथ काम करने वाला यूएसबी पोर्ट शामिल है, तो:

• [C-2-1] यह यूएसबी एचआईडी क्लास के साथ काम करना चाहिए.
• [C-2-2] यह ज़रूरी है कि डिवाइस, यूएसबी एचआईडी के इस्तेमाल की टेबल में बताए गए एचआईडी डेटा फ़ील्ड का पता लगा सके और उन्हें मैप कर सके. साथ ही, वॉइस कमांड के इस्तेमाल के अनुरोध को KeyEvent के कॉन्स्टेंट के साथ मैप कर सके. इसके लिए, यह ज़रूरी है कि डिवाइस में ये फ़ंक्शन मौजूद हों:
  • इस्तेमाल का पेज (0xC) इस्तेमाल का आईडी (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
  • इस्तेमाल का पेज (0xC) इस्तेमाल का आईडी (0x0E9): KEYCODE_VOLUME_UP
  • इस्तेमाल का पेज (0xC) इस्तेमाल का आईडी (0x0EA): KEYCODE_VOLUME_DOWN
  • इस्तेमाल का पेज (0xC) इस्तेमाल का आईडी (0x0CF): KEYCODE_VOICE_ASSIST

अगर डिवाइस में होस्ट मोड और स्टोरेज ऐक्सेस फ़्रेमवर्क (SAF) के साथ काम करने वाला यूएसबी पोर्ट शामिल है, तो:

• [C-3-1] यह ज़रूरी है कि ऐप्लिकेशन, किसी भी ऐसे MTP (मीडिया ट्रांसफ़र प्रोटोकॉल) डिवाइस को पहचाने जो रिमोट तौर पर कनेक्ट हो. साथ ही, ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, और ACTION_CREATE_DOCUMENT इंटेंट की मदद से, उस डिवाइस के कॉन्टेंट को ऐक्सेस करने की सुविधा दे.

अगर डिवाइस में होस्ट मोड और यूएसबी टाइप-सी के साथ काम करने वाला यूएसबी पोर्ट शामिल है, तो:

• [C-4-1] यूएसबी टाइप-सी स्पेसिफ़िकेशन (सेक्शन 4.5.1.3.3) के मुताबिक, ड्यूअल रोल पोर्ट की सुविधा लागू करना ज़रूरी है.
• [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 में दी गई, ऑडियो के इंतज़ार के समय से जुड़ी ज़रूरी शर्तों को पूरा करना ज़रूरी है.
• [SR] हमारा सुझाव है कि आप सेक्शन 7.8.3 में बताए गए तरीके से, नियर-अल्ट्रासाउंड रिकॉर्डिंग की सुविधा दें.

अगर डिवाइस में माइक्रोफ़ोन नहीं है, तो:

• [C-2-1] android.hardware.microphone फ़ीचर कॉन्स्टेंट की रिपोर्ट नहीं करनी चाहिए.
• [C-2-2] सेक्शन 7 के मुताबिक, ऑडियो रिकॉर्डिंग एपीआई को कम से कम नो-ऑप के तौर पर लागू करना ज़रूरी है.

7.8.2. ऑडियो आउटपुट

अगर डिवाइस में ऑडियो आउटपुट वाले किसी पेरिफ़रल के लिए स्पीकर या ऑडियो/मल्टीमीडिया आउटपुट पोर्ट शामिल है, तो:

• [C-1-1] android.hardware.audio.output फ़ीचर कॉन्सटेंट की रिपोर्ट करना ज़रूरी है.
• [C-1-2] सेक्शन 5.5 में बताई गई, ऑडियो चलाने से जुड़ी ज़रूरी शर्तों को पूरा करना ज़रूरी है.
• [C-1-3] सेक्शन 5.6 में दी गई, ऑडियो के इंतज़ार के समय से जुड़ी ज़रूरी शर्तों को पूरा करना ज़रूरी है.
• [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 पिन-आउट ऑर्डर के साथ TRRS ऑडियो प्लग काम करने चाहिए.
• [C-1-3] ऑडियो प्लग पर माइक्रोफ़ोन और ग्राउंड कंडक्टर के बीच, इवैलेंट इंपेडेन्स की इन तीन रेंज के लिए, कीकोड का पता लगाने और उन्हें मैप करने की सुविधा होनी चाहिए:
  • 70 ओम या उससे कम: KEYCODE_HEADSETHOOK
  • 210-290 ओम: KEYCODE_VOLUME_UP
  • 360-680 ओम: KEYCODE_VOLUME_DOWN
• [C-1-4] प्लग डालने पर, ACTION_HEADSET_PLUG को ट्रिगर करना चाहिए. हालांकि, ऐसा सिर्फ़ तब करना चाहिए, जब प्लग के सभी संपर्क, जैक पर उनके काम के सेगमेंट को छू रहे हों.
• [C-1-5] यह ज़रूरी है कि यह 32 ओम स्पीकर इंपेडेन्स पर, कम से कम 150mV ± 10% आउटपुट वोल्टेज दे सके.
• [C-1-6] माइक्रोफ़ोन का बायस वोल्टेज 1.8V से 2.9V के बीच होना चाहिए.
• [C-1-7] ऑडियो प्लग पर माइक्रोफ़ोन और ग्राउंड कंडक्टर के बीच, इवैलेंट इंपेडेन्स की इस रेंज के लिए, कीकोड का पता लगाना और उसे मैप करना ज़रूरी है:
  • 110-180 ओम: KEYCODE_VOICE_ASSIST
• [C-SR] हमारा सुझाव है कि आप OMTP पिन-आउट ऑर्डर वाले ऑडियो प्लग का इस्तेमाल करें.
• [C-SR] हमारा सुझाव है कि माइक्रोफ़ोन वाले स्टीरियो हेडसेट से ऑडियो रिकॉर्डिंग की सुविधा उपलब्ध कराएं.

अगर डिवाइस में चार कंडक्टर वाला 3.5 मि॰मी॰ का ऑडियो जैक है और माइक्रोफ़ोन काम करता है, तो android.intent.action.HEADSET_PLUG को माइक्रोफ़ोन की वैल्यू 1 के तौर पर सेट करके ब्रॉडकास्ट किया जा सकता है. ऐसा करने पर:

• [C-2-1] प्लग-इन की गई ऑडियो एक्सेसरी के माइक्रोफ़ोन का पता लगाने की सुविधा होनी चाहिए.

7.8.2.2. डिजिटल ऑडियो पोर्ट

यूएसबी-सी कनेक्टर का इस्तेमाल करने वाले हेडसेट और अन्य ऑडियो ऐक्सेसरी के साथ काम करने के लिए, Android यूएसबी हेडसेट स्पेसिफ़िकेशन में बताए गए तरीके से, Android के सभी प्लैटफ़ॉर्म पर (यूएसबी ऑडियो क्लास) लागू करना.

डिवाइस से जुड़ी ज़रूरी शर्तों के बारे में जानने के लिए, सेक्शन 2.2.1 देखें.

7.8.3. नियर-अल्ट्रासाउंड

नियर-अल्ट्रासोनिक ऑडियो, 18.5 किलोहर्ट्ज़ से 20 किलोहर्ट्ज़ बैंड में होता है.

डिवाइस पर लागू करने के तरीके:

• AudioManager.getProperty API की मदद से, यह सही तरीके से रिपोर्ट करना ज़रूरी है कि आपके ऐप्लिकेशन में नियर-अल्ट्रासाउंड ऑडियो की सुविधा काम करती है या नहीं. इसके लिए, यह तरीका अपनाएं:

अगर PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND "सही" है, तो VOICE_RECOGNITION और UNPROCESSED ऑडियो सोर्स को इन ज़रूरी शर्तों को पूरा करना होगा:

• [C-1-1] माइक्रोफ़ोन की औसत पावर रिस्पॉन्स, 18.5 किलोहर्ट्ज़ से 20 किलोहर्ट्ज़ बैंड में, 2 किलोहर्ट्ज़ पर रिस्पॉन्स से 15 डीबी से ज़्यादा नहीं होनी चाहिए.
• [C-1-2] माइक्रोफ़ोन का बिना वेट किए गए सिग्नल-टू-नॉइज़ रेशियो, 18.5 केएचज़ से 20 केएचज़ तक होना चाहिए. साथ ही, -26 डीबीएफ़एस पर 19 केएचज़ टोन के लिए, यह रेशियो 50 डीबी से कम नहीं होना चाहिए.

अगर PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND "सही" है, तो:

• [C-2-1] स्पीकर का औसत रिस्पॉन्स 18.5 kHz से 20 kHz के बीच, 2 kHz के रिस्पॉन्स से कम से कम 40 dB कम होना चाहिए.

7.8.4. सिग्नल इंटिग्रिटी

डिवाइस पर लागू करने के तरीके:

• यह हैंडहेल्ड डिवाइसों पर, इनपुट और आउटपुट, दोनों स्ट्रीम के लिए गड़बड़ी-मुक्त ऑडियो सिग्नल पाथ उपलब्ध कराता है. इसका मतलब है कि हर पाथ के लिए एक मिनट के टेस्ट के दौरान, कोई गड़बड़ी नहीं हुई. [OboeTester] (https://github.com/google/oboe/tree/master/apps/OboeTester) “गड़बड़ी का अपने-आप होने वाला टेस्ट” का इस्तेमाल करके जांच करें.

जांच के लिए, ऑडियो लूपबैक डोंगल की ज़रूरत होती है. इसे सीधे 3.5 मि॰मी॰ जैक में और/या यूएसबी-सी से 3.5 मि॰मी॰ अडैप्टर के साथ इस्तेमाल किया जाता है. सभी ऑडियो आउटपुट पोर्ट की जांच की जानी चाहिए.

फ़िलहाल, OboeTester में AAudio पाथ का इस्तेमाल किया जा सकता है. इसलिए, AAudio का इस्तेमाल करके, इन कॉम्बिनेशन की जांच की जानी चाहिए:

किसी भरोसेमंद स्ट्रीम को 2000 हर्ट्ज़ साइन के लिए, सिग्नल-टू-नॉइज़ रेशियो (एसएनआर) और कुल हार्मोनिक डिस्टॉर्शन (टीएचडी) से जुड़ी इन शर्तों को पूरा करना चाहिए.

7.9. आभासी वास्तविकता

Android में "वर्चुअल रिएलिटी" (वीआर) ऐप्लिकेशन बनाने के लिए एपीआई और सुविधाएं शामिल हैं. इनमें मोबाइल पर वीआर का बेहतरीन अनुभव भी शामिल है. डिवाइस में इन एपीआई और व्यवहारों को ठीक से लागू करना ज़रूरी है. इस बारे में इस सेक्शन में बताया गया है.

7.9.1. वर्चुअल रिएलिटी मोड

Android में वीआर मोड की सुविधा शामिल है. यह सुविधा, सूचनाओं को स्टीरियोस्कोपिक रेंडरिंग के साथ दिखाती है. साथ ही, वीआर ऐप्लिकेशन पर फ़ोकस होने पर, मोनोस्कोपिक सिस्टम यूज़र इंटरफ़ेस (यूआई) कॉम्पोनेंट को बंद कर देती है.

7.9.2. वर्चुअल रिएलिटी मोड - बेहतर परफ़ॉर्मेंस

अगर डिवाइस पर वीआर मोड काम करता है, तो:

• [C-1-1] कम से कम दो फ़िज़िकल कोर होने चाहिए.
• [C-1-2] android.hardware.vr.high_performance सुविधा का एलान करना ज़रूरी है.
• [C-1-3] यह ज़रूरी है कि डिवाइस में बेहतर परफ़ॉर्मेंस मोड की सुविधा काम करती हो.
• [C-1-4] यह ज़रूरी है कि ऐप्लिकेशन, OpenGL ES 3.2 के साथ काम करे.
• [C-1-5] android.hardware.vulkan.level 0 के साथ काम करना चाहिए.
• यह android.hardware.vulkan.level 1 या इसके बाद के वर्शन के साथ काम करना चाहिए.
• [C-1-6] EGL_KHR_mutable_render_buffer, EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_get_native_client_buffer, EGL_KHR_fence_sync, EGL_KHR_wait_sync, EGL_IMG_context_priority, EGL_EXT_protected_content, EGL_EXT_image_gl_colorspace को लागू करना ज़रूरी है. साथ ही, उपलब्ध ईजीएल एक्सटेंशन की सूची में एक्सटेंशन दिखाना ज़रूरी है.
• [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 की संख्या कम से कम दो होनी चाहिए.
• [C-1-7] जीपीयू और डिसप्ले, शेयर किए गए फ़्रंट बफ़र को सिंक कर पाएं. इससे, दो रेंडर कॉन्टेक्स्ट के साथ 60fps पर, वैकल्पिक आंखों से रेंडर किए गए वीआर कॉन्टेंट को बिना किसी टियरिंग आर्टफ़ैक्ट के दिखाया जा सकेगा.
• [C-1-9] NDK में बताए गए तरीके के मुताबिक, AHardwareBuffer फ़्लैग AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA, और AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT के लिए सहायता लागू करना ज़रूरी है.
• [C-1-10] कम से कम इन फ़ॉर्मैट के लिए, इस्तेमाल के फ़्लैग AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT के किसी भी कॉम्बिनेशन के साथ AHardwareBuffers के लिए सहायता लागू करना ज़रूरी है: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
• [C-SR] हमारा सुझाव है कि C-1-10 में बताई गई एक से ज़्यादा लेयर, फ़्लैग, और फ़ॉर्मैट के साथ AHardwareBuffers को असाइन करने की सुविधा जोड़ी जाए.
• [C-1-11] यह ज़रूरी है कि डिवाइस, H.264 को कम से कम 3840 x 2160 रिज़ॉल्यूशन पर 30 एफ़पीएस (फ़्रेम प्रति सेकंड) में डिकोड कर सके. साथ ही, यह भी ज़रूरी है कि डिवाइस, वीडियो को औसतन 40 एमबीपीएस तक कंप्रेस कर सके. यह 30 एफ़पीएस-10 एमबीपीएस पर 1920 x1080 के चार इंस्टेंस या 60 एफ़पीएस-20 एमबीपीएस पर 1920 x 1080 के दो इंस्टेंस के बराबर है.
• [C-1-12] यह एचईवीसी और VP9 के साथ काम करना चाहिए. साथ ही, यह कम से कम 1920 x 1080 रिज़ॉल्यूशन वाले वीडियो को 30 एफ़पीएस (फ़्रेम प्रति सेकंड) पर, औसतन 10 एमबीपीएस तक कंप्रेस करके डिकोड कर सकता है. साथ ही, यह 3840 x 2160 रिज़ॉल्यूशन वाले वीडियो को 30 एफ़पीएस-20 एमबीपीएस पर डिकोड कर सकता है. यह 30 एफ़पीएस-5 एमबीपीएस पर, 1920 x 1080 रिज़ॉल्यूशन वाले चार वीडियो के बराबर है.
• [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] मोशन से फ़ोटोन तक पहुंचने में लगने वाला कुल समय 28 मिलीसेकंड से ज़्यादा नहीं होना चाहिए.
• [C-SR] हमारा सुझाव है कि एंड-टू-एंड मोशन से फ़ोटोन के बीच लगने वाला समय 20 मिलीसेकंड से ज़्यादा न हो.
• [C-1-23] फ़र्स्ट-फ़्रेम रेशियो होना चाहिए. यह रेशियो, ब्लैक से व्हाइट में ट्रांज़िशन के बाद पहले फ़्रेम के पिक्सल की चमक और स्टेडी स्टेटस में व्हाइट पिक्सल की चमक के बीच का अनुपात होता है. यह रेशियो कम से कम 85% होना चाहिए.
• [C-SR] हमारा सुझाव है कि पहले फ़्रेम का आसपेक्ट रेशियो कम से कम 90% हो.
• फ़ोरग्राउंड ऐप्लिकेशन के लिए खास कोर उपलब्ध करा सकता है. साथ ही, Process.getExclusiveCores एपीआई के साथ काम करके, फ़ोरग्राउंड में चल रहे मुख्य ऐप्लिकेशन के लिए उपलब्ध सीपीयू कोर की संख्या दिखा सकता है.

अगर एक्सक्लूज़िव कोर काम करता है, तो कोर:

• [C-2-1] ऐप्लिकेशन के इस्तेमाल किए गए डिवाइस ड्राइवर को छोड़कर, किसी भी अन्य यूज़रस्पेस प्रोसेस को उस पर चलने की अनुमति नहीं देनी चाहिए. हालांकि, ज़रूरत के हिसाब से कुछ कर्नेल प्रोसेस को चलने की अनुमति दी जा सकती है.

8. परफ़ॉर्मेंस और पावर

परफ़ॉर्मेंस और पावर से जुड़ी कुछ बुनियादी शर्तें, उपयोगकर्ता अनुभव के लिए ज़रूरी हैं. साथ ही, इनसे डेवलपर को ऐप्लिकेशन बनाते समय, बुनियादी बातों के बारे में अनुमान लगाने में मदद मिलती है.

8.1. उपयोगकर्ता अनुभव में एकरूपता

असली उपयोगकर्ता को बेहतर यूज़र इंटरफ़ेस दिया जा सकता है. इसके लिए, ऐप्लिकेशन और गेम के लिए फ़्रेम रेट और रिस्पॉन्स टाइम को एक जैसा बनाए रखने के लिए, कुछ ज़रूरी शर्तें पूरी करनी होंगी. डिवाइस के टाइप के आधार पर, डिवाइस लागू करने के लिए, यूज़र इंटरफ़ेस के इंतज़ार के समय और टास्क स्विच करने के लिए, मेज़र की जा सकने वाली ज़रूरी शर्तें हो सकती हैं. इनके बारे में सेक्शन 2 में बताया गया है.

8.2. फ़ाइल I/O ऐक्सेस की परफ़ॉर्मेंस

ऐप्लिकेशन के निजी डेटा स्टोरेज (/data पार्टीशन) पर फ़ाइल ऐक्सेस करने की परफ़ॉर्मेंस को एक जैसा रखने के लिए, एक सामान्य बेसलाइन उपलब्ध कराने से, ऐप्लिकेशन डेवलपर को सही उम्मीद सेट करने में मदद मिलती है. इससे, उन्हें अपने सॉफ़्टवेयर के डिज़ाइन में मदद मिलती है. डिवाइस के टाइप के हिसाब से, डिवाइस में लागू करने के लिए, यहां दिए गए पढ़ने और लिखने के ऑपरेशन के लिए, सेक्शन 2 में बताई गई कुछ ज़रूरी शर्तें हो सकती हैं:

• सीक्वेंशियल राइटिंग की परफ़ॉर्मेंस. इसे मेज़र करने के लिए, 10 एमबी के राइट बफ़र का इस्तेमाल करके 256 एमबी की फ़ाइल लिखी जाती है.
• रैंडम राइटिंग की परफ़ॉर्मेंस. इसे मेज़र करने के लिए, 4 केबी के राइट बफ़र का इस्तेमाल करके 256 एमबी की फ़ाइल लिखी जाती है.
• सीक्वेंशियल रीड परफ़ॉर्मेंस. इसे 10 एमबी के राइट बफ़र का इस्तेमाल करके, 256 एमबी की फ़ाइल को पढ़कर मेज़र किया जाता है.
• रैंडम रीड परफ़ॉर्मेंस. इसे मेज़र करने के लिए, 4 केबी के राइट बफ़र का इस्तेमाल करके 256 एमबी की फ़ाइल को पढ़ा जाता है.

8.3. बैटरी सेव करने वाले मोड

अगर डिवाइस में AOSP में शामिल, डिवाइस की पावर मैनेजमेंट को बेहतर बनाने वाली सुविधाएं शामिल की गई हैं या AOSP में शामिल सुविधाओं को बढ़ाया गया है, तो:

• [C-1-1] ऐप्लिकेशन के स्टैंडबाय और Doze मोड की ग्लोबल सिस्टम सेटिंग के इस्तेमाल, ट्रिगर करने, रखरखाव, और स्मार्टवॉच को चालू करने के एल्गोरिदम के लिए, AOSP के तरीके से काम करना चाहिए.
• [C-1-2] ऐप्लिकेशन के स्टैंडबाय मोड के लिए, हर बकेट में ऐप्लिकेशन के लिए जॉब, अलार्म, और नेटवर्क को कम करने की सुविधा को मैनेज करने के लिए, ग्लोबल सेटिंग का इस्तेमाल करने के लिए, AOSP के तरीके से अलग नहीं होना चाहिए.
• [C-1-3] ऐप्लिकेशन स्टैंडबाय के लिए इस्तेमाल की जाने वाली ऐप्लिकेशन स्टैंडबाय बकेट की संख्या के लिए, AOSP के लागू होने से अलग नहीं होना चाहिए.
• [C-1-4] पावर मैनेजमेंट में बताए गए तरीके से, ऐप्लिकेशन स्टैंडबाय बकेट और Doze मोड को लागू करना ज़रूरी है.
• [C-1-5] डिवाइस के पावर सेव मोड में होने पर, PowerManager.isPowerSaveMode() के लिए true दिखाना ज़रूरी है.
• [C-SR] हमारा सुझाव है कि आप बैटरी सेवर मोड को चालू और बंद करने के लिए, उपयोगकर्ता को आसानी से ऐक्सेस करने की सुविधा दें.
• [C-SR] हमारा सुझाव है कि आप उपयोगकर्ता को उन सभी ऐप्लिकेशन को दिखाने की सुविधा दें जिन्हें ऐप्लिकेशन स्टैंडबाय और Doze मोड (बैटरी बचाने वाले मोड) से छूट मिली है.

Android डिवाइस में, बिजली बचाने वाले मोड के अलावा, बेहतर कॉन्फ़िगरेशन और पावर इंटरफ़ेस (ACPI) के मुताबिक, डिवाइस को स्लीप मोड में भेजने की चार स्थितियों में से किसी एक या सभी को लागू किया जा सकता है.

अगर डिवाइस में एसीपीआई के मुताबिक S4 पावर स्टेटस लागू किए जाते हैं, तो:

• [C-1-1] यह ज़रूरी है कि डिवाइस को इस स्थिति में सिर्फ़ तब लाया जाए, जब उपयोगकर्ता ने डिवाइस को बंद करने के लिए कोई साफ़ तौर पर कार्रवाई की हो. जैसे, डिवाइस का कवर बंद करना या वाहन या टीवी बंद करना. साथ ही, डिवाइस को इस स्थिति में तब लाया जाए, जब उपयोगकर्ता ने डिवाइस को फिर से चालू करने के लिए कोई साफ़ तौर पर कार्रवाई न की हो. जैसे, कवर खोलना या वाहन या टीवी को फिर से चालू करना.

अगर डिवाइस में एस3 पावर स्टेटस को लागू करने के लिए, ACPI के मुताबिक किया जाता है, तो:

• [C-2-1] ऊपर बताई गई C-1-1 शर्त को पूरा करना ज़रूरी है या तीसरे पक्ष के ऐप्लिकेशन को सिस्टम के रिसॉर्स (जैसे, स्क्रीन, सीपीयू) की ज़रूरत न होने पर ही S3 स्टेटस में जाना ज़रूरी है.

  इसके उलट, जब तीसरे पक्ष के ऐप्लिकेशन को सिस्टम संसाधनों की ज़रूरत होती है, तो उन्हें S3 स्टेटस से बाहर निकलना होगा. इस बारे में इस SDK टूल पर बताया गया है.

  उदाहरण के लिए, जब तीसरे पक्ष के ऐप्लिकेशन FLAG_KEEP_SCREEN_ON के ज़रिए स्क्रीन चालू रखने या PARTIAL_WAKE_LOCK के ज़रिए सीपीयू चालू रखने का अनुरोध करते हैं, तब डिवाइस को S3 स्टेटस में तब तक नहीं जाना चाहिए, जब तक कि C-1-1 में बताए गए तरीके से, उपयोगकर्ता ने डिवाइस को इनऐक्टिव स्टेटस में डालने के लिए साफ़ तौर पर कार्रवाई न की हो. इसके उलट, जब तीसरे पक्ष के ऐप्लिकेशन, JobScheduler की मदद से कोई टास्क ट्रिगर करते हैं या तीसरे पक्ष के ऐप्लिकेशन को Firebase Cloud Messaging डिलीवर किया जाता है, तो डिवाइस को S3 स्टेटस से बाहर निकलना होगा. ऐसा तब तक करना होगा, जब तक उपयोगकर्ता ने डिवाइस को इनऐक्टिव स्टेटस में नहीं डाल दिया है. ये उदाहरण पूरी जानकारी नहीं देते. AOSP, डिवाइस को इस स्थिति से जगाने के लिए, कई तरह के वेक अप सिग्नल लागू करता है.

8.4. बिजली की खपत का हिसाब लगाना

ऊर्जा की खपत की ज़्यादा सटीक जानकारी और रिपोर्टिंग से, ऐप्लिकेशन डेवलपर को ऐप्लिकेशन के लिए ऊर्जा के इस्तेमाल के पैटर्न को ऑप्टिमाइज़ करने के लिए, इंसेंटिव और टूल, दोनों मिलते हैं.

डिवाइस पर लागू करने के तरीके:

• [SR] हमारा सुझाव है कि हर कॉम्पोनेंट के लिए पावर प्रोफ़ाइल दें. इससे हर हार्डवेयर कॉम्पोनेंट के लिए बिजली की खपत की मौजूदा वैल्यू और समय के साथ कॉम्पोनेंट की वजह से बैटरी की खपत का अनुमानित डेटा पता चलता है. इस बारे में Android Open Source Project की साइट पर जानकारी दी गई है.
• [SR] हमारा सुझाव है कि बिजली की खपत की सभी वैल्यू को मिलीऐंपियर घंटे (mAh) में रिपोर्ट करें.
• [SR] हमारा सुझाव है कि हर प्रोसेस के यूआईडी के हिसाब से, सीपीयू की खपत की जानकारी दें. Android ओपन सोर्स प्रोजेक्ट, uid_cputime कर्नेल मॉड्यूल लागू करने की ज़रूरी शर्तें पूरी करता है.
• [SR] हमारा सुझाव है कि ऐप्लिकेशन डेवलपर को, adb shell dumpsys batterystats शेल कमांड के ज़रिए, डिवाइस के चार्ज होने में लगने वाले समय की जानकारी उपलब्ध कराएं.
• अगर किसी ऐप्लिकेशन के लिए, हार्डवेयर कॉम्पोनेंट के पावर खर्च का एट्रिब्यूट नहीं दिया जा सकता, तो उसे हार्डवेयर कॉम्पोनेंट के लिए एट्रिब्यूट किया जाना चाहिए.

8.5. लगातार अच्छी परफ़ॉर्मेंस

लंबे समय तक चलने वाले और बेहतर परफ़ॉर्म करने वाले ऐप्लिकेशन की परफ़ॉर्मेंस में काफ़ी उतार-चढ़ाव हो सकता है. ऐसा, बैकग्राउंड में चल रहे दूसरे ऐप्लिकेशन या तापमान की सीमाओं की वजह से सीपीयू की स्पीड कम होने की वजह से हो सकता है. Android में प्रोग्राम के हिसाब से इंटरफ़ेस शामिल होते हैं, ताकि डिवाइस के काम करने की क्षमता के हिसाब से, फ़ोरग्राउंड में चल रहे मुख्य ऐप्लिकेशन यह अनुरोध कर सके कि सिस्टम ऐसे उतार-चढ़ावों को ठीक करने के लिए, संसाधनों के बंटवारे को ऑप्टिमाइज़ करे.

डिवाइस पर लागू करने के तरीके:

• [C-0-1] PowerManager.isSustainedPerformanceModeSupported() एपीआई के तरीके से, यह सटीक तौर पर बताया जाना चाहिए कि ऐप्लिकेशन में बेहतर परफ़ॉर्मेंस मोड की सुविधा काम करती है या नहीं.

• यह बेहतर परफ़ॉर्मेंस वाले मोड के साथ काम करना चाहिए.

अगर डिवाइस पर, बेहतर परफ़ॉर्मेंस मोड की सुविधा काम करती है, तो:

• [C-1-1] जब कोई ऐप्लिकेशन अनुरोध करता है, तो फ़ोरग्राउंड में चल रहे सबसे लोकप्रिय ऐप्लिकेशन को कम से कम 30 मिनट तक एक जैसी परफ़ॉर्मेंस देनी चाहिए.
• [C-1-2] Window.setSustainedPerformanceMode() एपीआई और उससे जुड़े अन्य एपीआई का पालन करना ज़रूरी है.

अगर डिवाइस में दो या उससे ज़्यादा सीपीयू कोर शामिल हैं, तो:

• इसमें कम से कम एक खास कोर होना चाहिए, जिसे फ़ोरग्राउंड में चल रहे मुख्य ऐप्लिकेशन के लिए रिज़र्व किया जा सकता है.

अगर डिवाइस पर, टॉप फ़ोरग्राउंड ऐप्लिकेशन के लिए एक खास कोर को रिज़र्व करने की सुविधा काम करती है, तो:

• [C-2-1] Process.getExclusiveCores() एपीआई के तरीके से, खास कोर के आईडी नंबर की रिपोर्ट देनी होगी. इन कोर को फ़ोरग्राउंड में चल रहे टॉप ऐप्लिकेशन के लिए रिज़र्व किया जा सकता है.
• [C-2-2] ऐप्लिकेशन के इस्तेमाल किए गए डिवाइस ड्राइवर के अलावा, किसी भी उपयोगकर्ता स्पेस प्रोसेस को खास कोर पर चलने की अनुमति नहीं देनी चाहिए. हालांकि, ज़रूरत के हिसाब से कुछ कर्नेल प्रोसेस को चलने की अनुमति दी जा सकती है.

अगर डिवाइस पर लागू किए गए टूल, किसी खास कोर के साथ काम नहीं करते, तो वे:

• [C-3-1] Process.getExclusiveCores() एपीआई के तरीके से, खाली सूची दिखानी चाहिए.

9. सुरक्षा मॉडल के साथ काम करने की सुविधा

डिवाइस पर लागू करने के तरीके:

• [C-0-1] Android डेवलपर दस्तावेज़ में एपीआई के सुरक्षा और अनुमतियों के रेफ़रंस दस्तावेज़ में बताए गए तरीके के मुताबिक, Android प्लैटफ़ॉर्म के सुरक्षा मॉडल के मुताबिक सुरक्षा मॉडल लागू करना ज़रूरी है.

• [C-0-2] यह ज़रूरी है कि डिवाइस पर, खुद के हस्ताक्षर वाले ऐप्लिकेशन इंस्टॉल किए जा सकें. इसके लिए, किसी तीसरे पक्ष/अधिकारियों से अतिरिक्त अनुमतियों/सर्टिफ़िकेट की ज़रूरत नहीं होनी चाहिए. खास तौर पर, काम करने वाले डिवाइसों में, नीचे दिए गए सब-सेक्शन में बताए गए सुरक्षा तरीके काम करने चाहिए.

9.1. अनुमतियां

डिवाइस पर लागू करने के तरीके:

• [C-0-1] यह Android अनुमतियों के मॉडल के साथ काम करना चाहिए, जैसा कि Android डेवलपर के दस्तावेज़ में बताया गया है. खास तौर पर, उन्हें SDK टूल के दस्तावेज़ में बताई गई हर अनुमति को लागू करना होगा. किसी भी अनुमति को हटाया, बदला या अनदेखा नहीं किया जा सकता.

• ज़्यादा अनुमतियां जोड़ी जा सकती हैं. हालांकि, इसके लिए ज़रूरी है कि अनुमति की नई आईडी स्ट्रिंग, android.\* नेमस्पेस में न हों.

• [C-0-2] PROTECTION_FLAG_PRIVILEGED के protectionLevel वाली अनुमतियां, सिर्फ़ सिस्टम इमेज के खास पाथ में पहले से इंस्टॉल किए गए ऐप्लिकेशन को दी जानी चाहिए. साथ ही, ये अनुमतियां हर ऐप्लिकेशन के लिए, साफ़ तौर पर अनुमति वाली सूची के सबसेट में होनी चाहिए. AOSP, etc/permissions/ पाथ में मौजूद फ़ाइलों से हर ऐप्लिकेशन के लिए, अनुमति वाली सूची को पढ़कर और उसे लागू करके इस ज़रूरी शर्त को पूरा करता है. साथ ही, system/priv-app पाथ को खास पाथ के तौर पर इस्तेमाल करता है.

सुरक्षा के लेवल के हिसाब से, खतरनाक अनुमतियां रनटाइम अनुमतियां होती हैं. जिन ऐप्लिकेशन में targetSdkVersion > 22 है वे रनटाइम के दौरान इनका अनुरोध करते हैं.

डिवाइस पर लागू करने के तरीके:

• [C-0-3] उपयोगकर्ता को एक खास इंटरफ़ेस दिखाना ज़रूरी है, ताकि वह यह तय कर सके कि अनुरोध की गई रनटाइम अनुमतियां देनी हैं या नहीं. साथ ही, उपयोगकर्ता को रनटाइम अनुमतियां मैनेज करने के लिए भी एक इंटरफ़ेस देना ज़रूरी है.
• [C-0-4] दोनों यूज़र इंटरफ़ेस को सिर्फ़ एक बार लागू किया जाना चाहिए.
• [C-0-5] पहले से इंस्टॉल किए गए ऐप्लिकेशन को रनटाइम की कोई भी अनुमति तब तक नहीं देनी चाहिए, जब तक कि:
  • ऐप्लिकेशन का इस्तेमाल करने से पहले, उपयोगकर्ता की सहमति ली जा सकती है.
  • रनटाइम की अनुमतियां, किसी इंटेंट पैटर्न से जुड़ी होती हैं. इसके लिए, पहले से इंस्टॉल किया गया ऐप्लिकेशन डिफ़ॉल्ट हैंडलर के तौर पर सेट होता है.
• [C-0-6] android.permission.RECOVER_KEYSTORE अनुमति सिर्फ़ उन सिस्टम ऐप्लिकेशन को देनी चाहिए जो ठीक से सुरक्षित किए गए रिकवरी एजेंट को रजिस्टर करते हैं. सही तरीके से सुरक्षित किए गए रिकवरी एजेंट को, डिवाइस पर मौजूद सॉफ़्टवेयर एजेंट के तौर पर परिभाषित किया जाता है. यह एजेंट, डिवाइस से बाहर के रिमोट स्टोरेज के साथ सिंक होता है. यह रिमोट स्टोरेज, सुरक्षित हार्डवेयर से लैस होता है. इस हार्डवेयर की सुरक्षा, Google Cloud Key Vault Service में बताई गई सुरक्षा के बराबर या उससे ज़्यादा होती है. इससे लॉकस्क्रीन पर मौजूद, उपयोगकर्ता की पहचान से जुड़े फ़ैक्टर पर ब्रूट-फ़ोर्स अटैक को रोका जा सकता है.

डिवाइस पर लागू करने के तरीके:

• [C-0-7] जब कोई ऐप्लिकेशन, स्टैंडर्ड Android API या मालिकाना मशीनरी की मदद से जगह की जानकारी या शारीरिक गतिविधि के डेटा का अनुरोध करता है, तो उसे Android की जगह की जानकारी की अनुमति की प्रॉपर्टी का पालन करना होगा. इस तरह के डेटा में ये चीज़ें शामिल हैं. हालांकि, इसमें और भी चीज़ें शामिल हो सकती हैं:

  • डिवाइस की जगह की जानकारी (उदाहरण के लिए, अक्षांश और देशांतर).
  • ऐसी जानकारी जिसका इस्तेमाल डिवाइस की जगह की जानकारी का पता लगाने या उसका अनुमान लगाने के लिए किया जा सकता है. जैसे, SSID, BSSID, सेल आईडी, ब्लूटूथ स्कैन या उस नेटवर्क की जगह की जानकारी जिससे डिवाइस कनेक्ट है.
  • उपयोगकर्ता की शारीरिक गतिविधि या शारीरिक गतिविधि की कैटगरी.

खास तौर पर, डिवाइस पर लागू करने के लिए:

• [C-0-8] किसी ऐप्लिकेशन को जगह की जानकारी या शारीरिक गतिविधि का डेटा ऐक्सेस करने की अनुमति देने के लिए, उपयोगकर्ता की सहमति लेना ज़रूरी है.
• [C-0-9] रनटाइम की अनुमति सिर्फ़ उस ऐप्लिकेशन को देनी चाहिए जिसके पास SDK टूल में बताई गई ज़रूरी अनुमतियां हों. उदाहरण के लिए, TelephonyManager#getServiceState के लिए android.permission.ACCESS_FINE_LOCATION की ज़रूरत होती है).

अनुमतियों के व्यवहार में बदलाव करके, उन्हें 'पाबंदी वाला' के तौर पर मार्क किया जा सकता है.

• [C-0-10] hardRestricted फ़्लैग के साथ मार्क की गई अनुमतियां, किसी ऐप्लिकेशन को तब तक नहीं दी जानी चाहिए, जब तक:

  • ऐप्लिकेशन की APK फ़ाइल, सिस्टम पार्टीशन में है.
  • उपयोगकर्ता, किसी ऐप्लिकेशन को hardRestricted अनुमतियों से जुड़ी भूमिका असाइन करता है.
  • इंस्टॉलर, किसी ऐप्लिकेशन को hardRestricted देता है.
  • किसी ऐप्लिकेशन को Android के पुराने वर्शन पर hardRestricted दिया गया हो.

• [C-0-11] softRestricted अनुमति वाले ऐप्लिकेशन को सिर्फ़ सीमित ऐक्सेस मिलना चाहिए. साथ ही, जब तक उन्हें अनुमति वाली सूची में नहीं जोड़ा जाता, तब तक उन्हें पूरा ऐक्सेस नहीं मिलना चाहिए. इस बारे में SDK टूल में बताया गया है. यहां हर softRestricted अनुमति (उदाहरण के लिए, WRITE_EXTERNAL_STORAGE और READ_EXTERNAL_STORAGE) के लिए, पूरा और सीमित ऐक्सेस तय किया गया है.

अगर डिवाइस में पहले से इंस्टॉल किया गया कोई ऐप्लिकेशन है या तीसरे पक्ष के ऐप्लिकेशन को इस्तेमाल के आंकड़े ऐक्सेस करने की अनुमति देनी है, तो:

• [SR] ऐप्लिकेशन के इस्तेमाल के आंकड़े ऐक्सेस करने की अनुमति देने या वापस लेने के लिए, उपयोगकर्ता के लिए ऐक्सेस करने की सुविधा उपलब्ध कराने का सुझाव दिया जाता है. यह सुविधा, android.permission.PACKAGE_USAGE_STATS अनुमति का एलान करने वाले ऐप्लिकेशन के लिए, android.settings.ACTION_USAGE_ACCESS_SETTINGS इंटेंट के जवाब में उपलब्ध कराई जानी चाहिए.

अगर डिवाइस पर पहले से मौजूद ऐप्लिकेशन के साथ-साथ किसी भी ऐप्लिकेशन को, इस्तेमाल के आंकड़े ऐक्सेस करने से रोकना है, तो:

• [C-1-1] ऐप्लिकेशन में अब भी ऐसी गतिविधि होनी चाहिए जो android.settings.ACTION_USAGE_ACCESS_SETTINGS इंटेंट पैटर्न को मैनेज करती हो. हालांकि, इसे बिना किसी कार्रवाई के लागू करना ज़रूरी है. इसका मतलब है कि उपयोगकर्ता को ऐक्सेस देने से मना किए जाने पर भी, ऐप्लिकेशन का व्यवहार वैसा ही होना चाहिए.

9.2. यूआईडी और प्रोसेस अलग करना

डिवाइस पर लागू करने के तरीके:

• [C-0-1] यह Android ऐप्लिकेशन सैंडबॉक्स मॉडल के साथ काम करना चाहिए. इसमें हर ऐप्लिकेशन, यूनिक्स स्टाइल के यूआईडी के तौर पर और अलग प्रोसेस में चलता है.
• [C-0-2] एक ही Linux यूज़र आईडी के तौर पर कई ऐप्लिकेशन चलाने की सुविधा होनी चाहिए. हालांकि, इसके लिए ज़रूरी है कि ऐप्लिकेशन को सही तरीके से साइन किया गया हो और उन्हें सुरक्षा और अनुमतियों के रेफ़रंस में बताए गए तरीके से बनाया गया हो.

9.3. फ़ाइल सिस्टम की अनुमतियां

डिवाइस पर लागू करने के तरीके:

• [C-0-1] ऐप्लिकेशन को Android फ़ाइल ऐक्सेस करने की अनुमतियों के मॉडल के साथ काम करना चाहिए, जैसा कि सुरक्षा और अनुमतियों के रेफ़रंस में बताया गया है.

9.4. एक्ज़ीक्यूशन के अन्य एनवायरमेंट

डिवाइस में लागू किए गए सिस्टम में, Android की सुरक्षा और अनुमति मॉडल की सुविधाएं एक जैसी होनी चाहिए. भले ही, उनमें ऐसे रनटाइम एनवायरमेंट शामिल हों जो Dalvik Executable Format या नेटिव कोड के अलावा किसी अन्य सॉफ़्टवेयर या टेक्नोलॉजी का इस्तेमाल करके ऐप्लिकेशन चलाते हों. दूसरे शब्दों में:

• [C-0-1] वैकल्पिक रनटाइम, Android ऐप्लिकेशन होने चाहिए. साथ ही, वे सेक्शन 9 में बताए गए स्टैंडर्ड Android सुरक्षा मॉडल का पालन करने चाहिए.

• [C-0-2] अन्य रनटाइम को उन संसाधनों का ऐक्सेस नहीं दिया जाना चाहिए जिन्हें <uses-permission> तरीके से, रनटाइम की AndroidManifest.xml फ़ाइल में अनुरोध नहीं किया गया है.

• [C-0-3] अन्य रनटाइम को ऐप्लिकेशन को उन सुविधाओं का इस्तेमाल करने की अनुमति नहीं देनी चाहिए जिन्हें Android की अनुमतियों से सुरक्षित किया गया है और जिनका इस्तेमाल सिर्फ़ सिस्टम ऐप्लिकेशन कर सकते हैं.

• [C-0-4] किसी अन्य रनटाइम का इस्तेमाल करने वाले ऐप्लिकेशन को, Android सैंडबॉक्स मॉडल का पालन करना ज़रूरी है. साथ ही, डिवाइस पर इंस्टॉल किए गए किसी भी अन्य ऐप्लिकेशन के सैंडबॉक्स का दोबारा इस्तेमाल नहीं किया जाना चाहिए. हालांकि, शेयर किए गए उपयोगकर्ता आईडी और साइनिंग सर्टिफ़िकेट के स्टैंडर्ड Android तरीके का इस्तेमाल करके, ऐसा किया जा सकता है.

• [C-0-5] अन्य रनटाइम, Android के अन्य ऐप्लिकेशन के सैंडबॉक्स के साथ लॉन्च नहीं होने चाहिए, उन्हें सैंडबॉक्स का ऐक्सेस नहीं देना चाहिए, और न ही उन्हें सैंडबॉक्स का ऐक्सेस दिया जाना चाहिए.

• [C-0-6] अन्य रनटाइम को सुपर उपयोगकर्ता (रूट) या किसी अन्य उपयोगकर्ता आईडी की अनुमतियों के साथ लॉन्च नहीं किया जाना चाहिए. साथ ही, उन्हें अन्य ऐप्लिकेशन को भी ये अनुमतियां नहीं देनी चाहिए.

• [C-0-7] जब डिवाइस पर लागू किए गए सिस्टम की इमेज में, अन्य रनटाइम की .apk फ़ाइलें शामिल की जाती हैं, तो उस पर ऐसी कुंजी से हस्ताक्षर करना ज़रूरी है जो डिवाइस पर लागू किए गए अन्य ऐप्लिकेशन पर हस्ताक्षर करने के लिए इस्तेमाल की गई कुंजी से अलग हो.

• [C-0-8] ऐप्लिकेशन इंस्टॉल करते समय, अन्य रनटाइम को ऐप्लिकेशन के लिए इस्तेमाल की जाने वाली Android अनुमतियों के लिए, उपयोगकर्ता की सहमति लेनी होगी.

• [C-0-9] जब किसी ऐप्लिकेशन को किसी ऐसे डिवाइस संसाधन का इस्तेमाल करना हो जिसके लिए Android की अनुमति (जैसे, कैमरा, जीपीएस वगैरह) हो, तो वैकल्पिक रनटाइम को उपयोगकर्ता को यह बताना होगा कि ऐप्लिकेशन उस संसाधन को ऐक्सेस कर पाएगा.

• [C-0-10] अगर रनटाइम एनवायरमेंट, ऐप्लिकेशन की क्षमताओं को इस तरीके से रिकॉर्ड नहीं करता है, तो रनटाइम एनवायरमेंट को उस रनटाइम का इस्तेमाल करके किसी भी ऐप्लिकेशन को इंस्टॉल करते समय, रनटाइम के पास मौजूद सभी अनुमतियों की सूची बनानी होगी.

• अन्य रनटाइम को PackageManager के ज़रिए, अलग-अलग Android सैंडबॉक्स (Linux उपयोगकर्ता आईडी वगैरह) में ऐप्लिकेशन इंस्टॉल करने चाहिए.

• वैकल्पिक रनटाइम, एक ही Android सैंडबॉक्स उपलब्ध करा सकते हैं. इसे वैकल्पिक रनटाइम का इस्तेमाल करने वाले सभी ऐप्लिकेशन शेयर करते हैं.

9.5. एक डिवाइस पर कई लोगों के काम करने की सुविधा

Android में एक से ज़्यादा उपयोगकर्ताओं के लिए सहायता शामिल है. साथ ही, यह उपयोगकर्ता को पूरी तरह से अलग करने की सुविधा भी देता है.

• अगर डिवाइस में प्राइमरी बाहरी स्टोरेज के लिए रिमूवेबल मीडिया का इस्तेमाल किया जाता है, तो हो सकता है कि डिवाइस में एक से ज़्यादा उपयोगकर्ताओं के लिए फ़ाइल शेयर करने की सुविधा चालू हो. हालांकि, ऐसा नहीं होना चाहिए.

अगर डिवाइस पर एक से ज़्यादा उपयोगकर्ताओं को लागू किया जाता है, तो:

• [C-1-1] एक से ज़्यादा उपयोगकर्ताओं के लिए सहायता से जुड़ी इन ज़रूरी शर्तों को पूरा करना ज़रूरी है.
• [C-1-2] हर उपयोगकर्ता के लिए, एपीआई में सुरक्षा और अनुमतियों के रेफ़रंस दस्तावेज़ में बताए गए Android प्लैटफ़ॉर्म के सुरक्षा मॉडल के मुताबिक सुरक्षा मॉडल लागू करना ज़रूरी है.
• [C-1-3] हर उपयोगकर्ता इंस्टेंस के लिए, अलग-अलग और अलग-अलग ऐप्लिकेशन स्टोरेज (/sdcard) डायरेक्ट्री होनी चाहिए.
• [C-1-4] यह पक्का करना ज़रूरी है कि किसी उपयोगकर्ता के मालिकाना हक वाली और उसकी ओर से चलने वाली फ़ाइलें, किसी दूसरे उपयोगकर्ता की फ़ाइलों को न तो देख सकें, न ही उनमें बदलाव कर सकें और न ही उनका इस्तेमाल कर सकें. भले ही, दोनों उपयोगकर्ताओं का डेटा एक ही वॉल्यूम या फ़ाइल सिस्टम में सेव हो.
• [C-1-5] अगर डिवाइस में बाहरी स्टोरेज के एपीआई के लिए, हटाया जा सकने वाले मीडिया का इस्तेमाल किया जाता है, तो कई उपयोगकर्ताओं के लिए चालू होने पर, एसडी कार्ड के कॉन्टेंट को एन्क्रिप्ट करना ज़रूरी है. इसके लिए, ऐसी कुंजी का इस्तेमाल करना चाहिए जो सिर्फ़ न हटाया जा सकने वाले मीडिया में सेव हो और जिसे सिर्फ़ सिस्टम ऐक्सेस कर सके. इससे होस्ट पीसी, मीडिया को नहीं पढ़ पाएगा. इसलिए, डिवाइस को MTP या मिलते-जुलते सिस्टम पर स्विच करना होगा, ताकि होस्ट पीसी को मौजूदा उपयोगकर्ता के डेटा का ऐक्सेस दिया जा सके.

9.6. प्रीमियम एसएमएस की चेतावनी

Android में, उपयोगकर्ताओं को भेजे जाने वाले किसी भी प्रीमियम मैसेज के बारे में चेतावनी देने की सुविधा शामिल है. प्रीमियम मैसेज, ऐसे टेक्स्ट मैसेज होते हैं जिन्हें मोबाइल और इंटरनेट सेवा देने वाली कंपनी के साथ रजिस्टर की गई किसी सेवा पर भेजा जाता है. इन मैसेज के लिए, उपयोगकर्ता से शुल्क लिया जा सकता है.

अगर डिवाइस पर android.hardware.telephony की सुविधा काम करती है, तो:

• [C-1-1] डिवाइस में /data/misc/sms/codes.xml फ़ाइल में बताई गई रेगुलर एक्सप्रेशन से पहचाने गए नंबरों पर एसएमएस भेजने से पहले, उपयोगकर्ताओं को चेतावनी देनी ज़रूरी है. अपस्ट्रीम Android Open Source Project, इस ज़रूरी शर्त को पूरा करने वाला तरीका उपलब्ध कराता है.

9.7. सुरक्षा से जुड़ी सुविधाएं

डिवाइस में लागू करने के लिए, यह ज़रूरी है कि कर्नेल और प्लैटफ़ॉर्म, दोनों में सुरक्षा से जुड़ी सुविधाओं का पालन किया जाए. इन सुविधाओं के बारे में यहां बताया गया है.

Android सैंडबॉक्स में ऐसी सुविधाएं शामिल हैं जो Linux kernel में, सुरक्षा के लिए बेहतर बनाए गए Linux (SELinux) के ज़रूरी ऐक्सेस कंट्रोल (MAC) सिस्टम, seccomp सैंडबॉक्सिंग, और सुरक्षा से जुड़ी अन्य सुविधाओं का इस्तेमाल करती हैं. डिवाइस पर लागू करने के तरीके:

• [C-0-1] यह ज़रूरी है कि मौजूदा ऐप्लिकेशन के साथ काम करने की सुविधा बनी रहे. भले ही, Android फ़्रेमवर्क के नीचे SELinux या सुरक्षा से जुड़ी कोई अन्य सुविधा लागू की गई हो.
• [C-0-2] सुरक्षा से जुड़ा उल्लंघन होने पर, यूज़र इंटरफ़ेस (यूआई) नहीं दिखना चाहिए. यह तब दिख सकता है, जब Android फ़्रेमवर्क के नीचे लागू की गई सुरक्षा सुविधा से उल्लंघन को ब्लॉक नहीं किया जा सके और इसका फ़ायदा उठाया जा सके.
• [C-0-3] Android फ़्रेमवर्क के नीचे लागू की गई SELinux या सुरक्षा से जुड़ी अन्य सुविधाओं को, उपयोगकर्ता या ऐप्लिकेशन डेवलपर के लिए कॉन्फ़िगर नहीं किया जाना चाहिए.
• [C-0-4] किसी ऐसे ऐप्लिकेशन को नीति कॉन्फ़िगर करने की अनुमति नहीं देनी चाहिए जो किसी एपीआई (जैसे, डिवाइस एडमिनिस्ट्रेशन एपीआई) के ज़रिए किसी दूसरे ऐप्लिकेशन पर असर डाल सकता है. ऐसा करने से, ऐप्लिकेशन के साथ काम करने की सुविधा बंद हो सकती है.
• [C-0-5] मीडिया फ़्रेमवर्क को कई प्रोसेस में बांटना ज़रूरी है, ताकि Android Open Source Project की साइट पर बताए गए तरीके से, हर प्रोसेस के लिए ऐक्सेस को ज़्यादा सटीक तरीके से दिया जा सके.
• [C-0-6] यह ज़रूरी है कि कर्नेल ऐप्लिकेशन सैंडबॉक्सिंग का ऐसा तरीका लागू किया जाए जिससे मल्टी-थ्रेड वाले प्रोग्राम से, कॉन्फ़िगर की जा सकने वाली नीति का इस्तेमाल करके सिस्टम कॉल को फ़िल्टर किया जा सके. अपस्ट्रीम Android Open Source Project, source.android.com के कर्नेल कॉन्फ़िगरेशन सेक्शन में बताए गए तरीके से, थ्रेडग्रुप सिंक्रोनाइज़ेशन (TSYNC) के साथ seccomp-BPF को चालू करके इस ज़रूरी शर्त को पूरा करता है.

Android की सुरक्षा के लिए, कर्नेल इंटिग्रिटी और खुद को सुरक्षित रखने की सुविधाएं ज़रूरी हैं. डिवाइस पर लागू करने के तरीके:

• [C-0-7] कर्नल स्टैक बफ़र ओवरफ़्लो से सुरक्षा देने वाले तरीकों को लागू करना ज़रूरी है. इस तरह के तरीकों के उदाहरण CC_STACKPROTECTOR_REGULAR और CONFIG_CC_STACKPROTECTOR_STRONG हैं.
• [C-0-8] जहां सिर्फ़ पढ़ने के लिए उपलब्ध कोड, सिर्फ़ पढ़ने के लिए उपलब्ध डेटा, और लिखने के लिए उपलब्ध डेटा, सभी को एक साथ इस्तेमाल नहीं किया जा सकता, वहां कर्नेल मेमोरी की सुरक्षा के सख्त उपाय लागू करने होंगे. जैसे, CONFIG_DEBUG_RODATA या CONFIG_STRICT_KERNEL_RWX.
• [C-0-9] एपीआई लेवल 28 या उसके बाद के वर्शन के साथ शिप होने वाले डिवाइसों पर, उपयोगकर्ता-स्पेस और कर्नेल-स्पेस (उदाहरण के लिए, CONFIG_HARDENED_USERCOPY) के बीच कॉपी के स्टैटिक और डाइनैमिक ऑब्जेक्ट साइज़ की जांच करना ज़रूरी है.
• [C-0-10] एपीआई लेवल 28 या उसके बाद के वर्शन वाले डिवाइसों पर, उपयोगकर्ता-स्पेस मेमोरी को कर्नेल मोड (जैसे, हार्डवेयर PXN या CONFIG_CPU_SW_DOMAIN_PAN या CONFIG_ARM64_SW_TTBR0_PAN के ज़रिए एमुलेट किया गया) में लागू नहीं किया जाना चाहिए.
• [C-0-11] एपीआई लेवल 28 या इसके बाद के वर्शन वाले डिवाइसों पर, सामान्य usercopy ऐक्सेस एपीआई (जैसे, हार्डवेयर पैन या CONFIG_CPU_SW_DOMAIN_PAN या CONFIG_ARM64_SW_TTBR0_PAN के ज़रिए एमुलेट किया गया) के अलावा, कर्नेल में उपयोगकर्ता-स्पेस मेमोरी को न तो पढ़ा जाना चाहिए और न ही उसमें बदलाव किया जाना चाहिए.
• [C-0-12] अगर एपीआई लेवल 28 या उसके बाद के वर्शन (जैसे, CONFIG_PAGE_TABLE_ISOLATION या CONFIG_UNMAP_KERNEL_AT_EL0) वाले सभी डिवाइसों पर, हार्डवेयर CVE-2017-5754 से सुरक्षित नहीं है, तो आपको कर्नेल पेज टेबल आइसोलेशन लागू करना होगा.
• [C-0-13] अगर एपीआई लेवल 28 या उसके बाद के वर्शन (उदाहरण के लिए, CONFIG_HARDEN_BRANCH_PREDICTOR) के साथ शिप होने वाले सभी डिवाइसों पर, हार्डवेयर CVE-2017-5715 से असुरक्षित है, तो ब्रैंच प्रिडिक्शन को बेहतर बनाने की सुविधा लागू करना ज़रूरी है.
• [SR] हमारा सुझाव है कि सिर्फ़ शुरुआती सेटअप के दौरान लिखे गए कर्नेल डेटा को, सेटअप के बाद रीड-ओनली के तौर पर मार्क करें. जैसे, __ro_after_init.

• [C-SR] हमारा सुझाव है कि आप कर्नेल कोड और मेमोरी के लेआउट को रैंडमाइज़ करें.साथ ही, ऐसे एक्सपोज़र से बचें जिनसे रैंडमाइज़ेशन की सुविधा को नुकसान पहुंच सकता है. जैसे, /chosen/kaslr-seed Device Tree node या EFI_RNG_PROTOCOL के ज़रिए बूटलोडर एन्ट्रोपी के साथ CONFIG_RANDOMIZE_BASE.

• [C-SR] हमारा सुझाव है कि कोड के फिर से इस्तेमाल से जुड़े हमलों (जैसे, CONFIG_CFI_CLANG और CONFIG_SHADOW_CALL_STACK) से अतिरिक्त सुरक्षा पाने के लिए, कर्नेल में कंट्रोल फ़्लो इंटिग्रिटी (CFI) को चालू करें.

• [C-SR] हमारा सुझाव है कि जिन कॉम्पोनेंट में कंट्रोल-फ़्लो इंटिग्रिटी (CFI), शैडो कॉल स्टैक (SCS) या इंटिजर ओवरफ़्लो सैनिटाइज़ेशन (IntSan) की सुविधा चालू है उन्हें बंद न करें.
• [C-SR] हमारा सुझाव है कि सुरक्षा से जुड़े संवेदनशील यूज़रस्पेस कॉम्पोनेंट के लिए, CFI, SCS, और IntSan को चालू करें. इनके बारे में CFI और IntSan में बताया गया है.

अगर डिवाइस में Linux kernel का इस्तेमाल किया जाता है, तो:

• [C-1-1] SELinux को लागू करना ज़रूरी है.
• [C-1-2] SELinux को ग्लोबल लागू करने वाले मोड पर सेट करना ज़रूरी है.
• [C-1-3] सभी डोमेन को लागू करने के मोड में कॉन्फ़िगर करना ज़रूरी है. अनुमति वाले मोड के डोमेन इस्तेमाल करने की अनुमति नहीं है. इनमें किसी डिवाइस/वेंडर के लिए खास तौर पर बनाए गए डोमेन भी शामिल हैं.
• [C-1-4] अपस्ट्रीम Android Open Source Project (AOSP) में दिए गए system/sepolicy फ़ोल्डर में मौजूद, 'कभी भी अनुमति न दें' नियमों में बदलाव नहीं किया जाना चाहिए, उन्हें हटाया नहीं जाना चाहिए या उन्हें बदला नहीं जाना चाहिए. साथ ही, नीति को AOSP SELinux डोमेन के साथ-साथ डिवाइस/वेंडर के हिसाब से बनाए गए डोमेन, दोनों के लिए मौजूद 'कभी भी अनुमति न दें' नियमों के साथ कंपाइल किया जाना चाहिए.
• [C-1-5] तीसरे पक्ष के ऐसे ऐप्लिकेशन चलाने चाहिए जो हर ऐप्लिकेशन के लिए SELinux सैंडबॉक्स में, एपीआई लेवल 28 या उसके बाद के वर्शन को टारगेट करते हों. साथ ही, हर ऐप्लिकेशन की निजी डेटा डायरेक्ट्री पर, हर ऐप्लिकेशन के लिए SELinux की पाबंदियां भी होनी चाहिए.
• Android Open Source Project के system/sepolicy फ़ोल्डर में दी गई डिफ़ॉल्ट SELinux नीति को बनाए रखना चाहिए. साथ ही, इस नीति में सिर्फ़ अपने डिवाइस के हिसाब से कॉन्फ़िगरेशन के लिए बदलाव करना चाहिए.

अगर डिवाइस पर पहले से ही Android के किसी पुराने वर्शन पर, नीति के उल्लंघन को ठीक करने के लिए ये बदलाव लागू किए जा चुके हैं और सिस्टम सॉफ़्टवेयर के अपडेट की मदद से, [C-1-1] और [C-1-5] शर्तों को पूरा नहीं किया जा सकता, तो हो सकता है कि उन्हें इन शर्तों से छूट दी जाए.

अगर डिवाइस में Linux के अलावा किसी दूसरे कर्नेल का इस्तेमाल किया जाता है, तो:

• [C-2-1] ज़रूरी ऐक्सेस कंट्रोल सिस्टम का इस्तेमाल करना चाहिए, जो SELinux के बराबर हो.

Android में, डिवाइस की सुरक्षा के लिए कई लेयर की सुरक्षा की सुविधाएं मौजूद हैं.

9.8. निजता

9.8.1. इस्तेमाल का इतिहास

Android, उपयोगकर्ता की पसंद का इतिहास सेव करता है और UsageStatsManager की मदद से इस इतिहास को मैनेज करता है.

डिवाइस पर लागू करने के तरीके:

• [C-0-1] उपयोगकर्ता के इस इतिहास को तय समय तक सेव रखना ज़रूरी है.
• [SR] हमारा सुझाव है कि AOSP को लागू करते समय, डेटा को 14 दिनों तक सेव रखने की अवधि को डिफ़ॉल्ट रूप से कॉन्फ़िगर किया गया हो.

Android, StatsLog आइडेंटिफ़ायर का इस्तेमाल करके सिस्टम इवेंट सेव करता है. साथ ही, StatsManager और IncidentManager सिस्टम एपीआई की मदद से इस तरह के इतिहास को मैनेज करता है.

डिवाइस पर लागू करने के तरीके:

• [C-0-2] System API क्लास IncidentManager से बनाई गई समस्या की रिपोर्ट में, सिर्फ़ DEST_AUTOMATIC के निशान वाले फ़ील्ड शामिल होने चाहिए.
• [C-0-3] StatsLog SDK टूल के दस्तावेज़ों में बताए गए इवेंट के अलावा, किसी दूसरे इवेंट को लॉग करने के लिए, सिस्टम इवेंट आइडेंटिफ़ायर का इस्तेमाल नहीं करना चाहिए. अगर अतिरिक्त सिस्टम इवेंट लॉग किए जाते हैं, तो वे 1,00,000 से 2,00,000 के बीच की रेंज में किसी दूसरे ऐटम आइडेंटिफ़ायर का इस्तेमाल कर सकते हैं.

9.8.2. रिकॉर्डिंग

डिवाइस पर लागू करने के तरीके:

• [C-0-1] डिवाइस में पहले से मौजूद ऐसे सॉफ़्टवेयर कॉम्पोनेंट को प्री-लोड या डिस्ट्रिब्यूट नहीं किया जाना चाहिए जो उपयोगकर्ता की सहमति के बिना या चल रही सूचनाओं को हटाकर, उसकी निजी जानकारी (जैसे, कीस्ट्रोक, स्क्रीन पर दिखने वाला टेक्स्ट, गड़बड़ी की रिपोर्ट) को डिवाइस से भेजते हैं.

• [C-0-2] MediaProjection या मालिकाना एपीआई की मदद से स्क्रीन कास्टिंग या स्क्रीन रिकॉर्डिंग की सुविधा चालू करने पर, उपयोगकर्ता की साफ़ तौर पर सहमति लेनी होगी. इसमें AOSP जैसा ही मैसेज शामिल होना चाहिए. उपयोगकर्ताओं को, आने वाले समय में सहमति देने के लिए फिर से अनुरोध न दिखाने का विकल्प नहीं देना चाहिए.

• [C-0-3] स्क्रीन कास्टिंग या स्क्रीन रिकॉर्डिंग की सुविधा चालू होने पर, उपयोगकर्ता को इसकी सूचना दी जानी चाहिए. AOSP, स्टेटस बार में चल रही सूचना का आइकॉन दिखाकर इस ज़रूरी शर्त को पूरा करता है.

अगर डिवाइस में लागू किए गए सिस्टम में, स्क्रीन पर दिखने वाले कॉन्टेंट को कैप्चर करने और/या डिवाइस पर चलने वाली ऑडियो स्ट्रीम को रिकॉर्ड करने की सुविधा शामिल है, तो:ContentCaptureService

• [C-1-1] जब भी यह सुविधा चालू हो और कैप्चर/रिकॉर्डिंग की जा रही हो, तो उपयोगकर्ता को इसकी सूचना दी जानी चाहिए.

अगर डिवाइस में पहले से चालू कोई ऐसा कॉम्पोनेंट शामिल है जो आस-पास के आवाज़ों को रिकॉर्ड कर सकता है और/या डिवाइस पर चल रहे ऑडियो को रिकॉर्ड करके, उपयोगकर्ता के संदर्भ के बारे में काम की जानकारी दे सकता है, तो:

• [C-2-1] रिकॉर्ड किए गए रॉ ऑडियो या किसी ऐसे फ़ॉर्मैट को डिवाइस के स्टोरेज में सेव नहीं किया जाना चाहिए जिसे मूल ऑडियो या मिलते-जुलते ऑडियो में बदला जा सकता है. ऐसा, उपयोगकर्ता की साफ़ तौर पर सहमति के बिना नहीं किया जाना चाहिए. इसके अलावा, डिवाइस से ऑडियो को कहीं भी ट्रांसमिट नहीं किया जाना चाहिए.

9.8.3. कनेक्टिविटी

अगर डिवाइस में यूएसबी पोर्ट है और वह यूएसबी पीरियफ़रल मोड के साथ काम करता है, तो:

• [C-1-1] यूएसबी पोर्ट से शेयर किए गए स्टोरेज के कॉन्टेंट का ऐक्सेस देने से पहले, उपयोगकर्ता से सहमति मांगने के लिए यूज़र इंटरफ़ेस (यूआई) दिखाना ज़रूरी है.

9.8.4. नेटवर्क ट्रैफ़िक

डिवाइस पर लागू करने के तरीके:

• [C-0-1] सिस्टम के भरोसेमंद सर्टिफ़िकेट देने वाली संस्था (सीए) के स्टोर के लिए, वे ही रूट सर्टिफ़िकेट पहले से इंस्टॉल होने चाहिए जो Android Open Source Project में उपलब्ध हैं.
• [C-0-2] यह ज़रूरी है कि उपयोगकर्ता के रूट सीए स्टोर में कोई डेटा न हो.
• [C-0-3] उपयोगकर्ता के रूट सीए को जोड़ने पर, उपयोगकर्ता को चेतावनी दिखानी चाहिए. इसमें यह जानकारी होनी चाहिए कि नेटवर्क ट्रैफ़िक की निगरानी की जा सकती है.

अगर डिवाइस का ट्रैफ़िक वीपीएन के ज़रिए रूट किया जाता है, तो डिवाइस पर ये लागू होते हैं:

• [C-1-1] उपयोगकर्ता को चेतावनी दिखानी ज़रूरी है. इसमें इनमें से कोई एक जानकारी होनी चाहिए:
  • उस नेटवर्क ट्रैफ़िक को मॉनिटर किया जा सकता है.
  • वह नेटवर्क ट्रैफ़िक, वीपीएन की सुविधा देने वाले खास वीपीएन ऐप्लिकेशन से होकर गुज़र रहा है.

अगर डिवाइस में ऐसा कोई तरीका है जो डिफ़ॉल्ट रूप से चालू होता है और नेटवर्क डेटा ट्रैफ़िक को प्रॉक्सी सर्वर या वीपीएन गेटवे के ज़रिए रूट करता है, तो:android.permission.CONTROL_VPN

• [C-2-1] इस सुविधा को चालू करने से पहले, उपयोगकर्ता की सहमति लेना ज़रूरी है. हालांकि, अगर डिवाइस नीति नियंत्रक ने DevicePolicyManager.setAlwaysOnVpnPackage() के ज़रिए वीपीएन को चालू किया है, तो उपयोगकर्ता को अलग से सहमति देने की ज़रूरत नहीं है. हालांकि, उसे इसकी सूचना देना ज़रूरी है.

अगर डिवाइस में, तीसरे पक्ष के वीपीएन ऐप्लिकेशन के "हमेशा चालू वीपीएन" फ़ंक्शन को टॉगल करने के लिए, उपयोगकर्ता के लिए कोई सुविधा लागू की जाती है, तो:

• [C-3-1] AndroidManifest.xml फ़ाइल में, हमेशा चालू रहने वाली वीपीएन सेवा के साथ काम न करने वाले ऐप्लिकेशन के लिए, इस सुविधा को बंद करना ज़रूरी है. इसके लिए, SERVICE_META_DATA_SUPPORTS_ALWAYS_ON एट्रिब्यूट को false पर सेट करें.

9.8.5. डिवाइस पहचानकर्ता

डिवाइस पर लागू करने के तरीके:

• [C-0-1] ऐप्लिकेशन को डिवाइस के सीरियल नंबर और जहां लागू हो वहां IMEI/MEID, सिम का सीरियल नंबर, और इंटरनैशनल मोबाइल सब्सक्राइबर आइडेंटिटी (IMSI) को ऐक्सेस करने से रोकना चाहिए. ऐसा तब तक करना चाहिए, जब तक कि ऐप्लिकेशन इनमें से किसी एक ज़रूरी शर्त को पूरा न कर दे:
  • यह एक ऐसा कैरियर ऐप्लिकेशन है जिसकी पुष्टि डिवाइस बनाने वाली कंपनियों ने की है.
  • को READ_PRIVILEGED_PHONE_STATE अनुमति दी गई है.
  • यूआईसीसी के लिए कैरियर के खास अधिकार में बताए गए, कैरियर के खास अधिकार हों.
  • डिवाइस का मालिक या प्रोफ़ाइल का मालिक हो और उसे READ_PHONE_STATE अनुमति मिली हो.
  • (सिर्फ़ सिम के सीरियल नंबर/आईसीसीआईडी के लिए) स्थानीय कानूनों के मुताबिक, ऐप्लिकेशन को यह पता लगाना होगा कि सदस्य की पहचान में कोई बदलाव हुआ है या नहीं.

9.8.6. सामग्री कैप्चर

Android, System API ContentCaptureService या अन्य मालिकाना तरीकों की मदद से, डिवाइस पर लागू होने वाले एक तरीके का इस्तेमाल करता है. इससे ऐप्लिकेशन और उपयोगकर्ता के बीच होने वाले इन इंटरैक्शन को कैप्चर किया जा सकता है.

• स्क्रीन पर रेंडर किया गया टेक्स्ट और ग्राफ़िक्स. इसमें AssistStructure एपीआई की मदद से सूचनाएं और सहायता डेटा शामिल है. हालांकि, इसमें और भी चीज़ें शामिल हो सकती हैं.
• डिवाइस पर रिकॉर्ड किया गया या चलाया गया मीडिया डेटा, जैसे कि ऑडियो या वीडियो.
• इनपुट इवेंट (जैसे, की, माउस, जेस्चर, आवाज़, वीडियो, और सुलभता).
• ऐसे अन्य इवेंट जो कोई ऐप्लिकेशन, Content Capture एपीआई या मिलते-जुलते प्रॉपराइटरी एपीआई की मदद से सिस्टम को उपलब्ध कराता है.

अगर डिवाइस पर ऊपर दिया गया डेटा कैप्चर किया जाता है, तो:

• [C-1-1] डिवाइस में सेव किए जाने पर, इस तरह के सभी डेटा को एन्क्रिप्ट करना ज़रूरी है. यह एन्क्रिप्शन, Android फ़ाइल पर आधारित एन्क्रिप्शन का इस्तेमाल करके किया जा सकता है. इसके अलावा, Cipher SDK में बताए गए एपीआई वर्शन 26 और उसके बाद के वर्शन के तौर पर सूची में शामिल किसी भी सिफर का इस्तेमाल करके भी यह एन्क्रिप्शन किया जा सकता है.
• [C-1-2] Android के बैकअप लेने के तरीकों या किसी अन्य तरीके का इस्तेमाल करके, रॉ या एन्क्रिप्ट (सुरक्षित) किए गए डेटा का बैक अप नहीं लेना चाहिए.
• [C-1-3] निजता की सुरक्षा करने वाले तरीके का इस्तेमाल करके, सिर्फ़ इस तरह का डेटा और डिवाइस का लॉग भेजना ज़रूरी है. निजता बनाए रखने वाले तरीके को इस तरह से परिभाषित किया गया है, “ये सिर्फ़ एग्रीगेट में विश्लेषण की अनुमति देते हैं और अलग-अलग उपयोगकर्ताओं के लिए, लॉग किए गए इवेंट या डेटा से मिले नतीजों को मैच करने से रोकते हैं”. ऐसा इसलिए किया जाता है, ताकि हर उपयोगकर्ता के डेटा को इंट्रोस्पेक्शन (उदाहरण के लिए, RAPPOR जैसी अलग-अलग निजता टेक्नोलॉजी का इस्तेमाल करके लागू किया गया) से बचाया जा सके.
• [C-1-4] इस तरह के डेटा को डिवाइस पर मौजूद किसी भी उपयोगकर्ता की पहचान (जैसे, Account) से नहीं जोड़ना चाहिए. हालांकि, डेटा को जोड़ने के लिए हर बार उपयोगकर्ता की साफ़ तौर पर सहमति लेनी होगी.
• [C-1-5] इस तरह के डेटा को अन्य ऐप्लिकेशन के साथ शेयर नहीं किया जाना चाहिए. हालांकि, हर बार डेटा शेयर करने के लिए, उपयोगकर्ता की साफ़ तौर पर सहमति लेनी होगी.
• [C-1-6] उपयोगकर्ता को ऐसा विकल्प देना ज़रूरी है जिससे वह ContentCaptureService या मालिकाना हक वाले तरीकों से इकट्ठा किए गए डेटा को मिटा सके. ऐसा तब करना होगा, जब डिवाइस पर डेटा किसी भी फ़ॉर्मैट में सेव हो.

अगर डिवाइस में ऐसी सेवा शामिल है जो System API ContentCaptureService को लागू करती है या ऊपर बताई गई तरह से डेटा कैप्चर करने वाली कोई मालिकाना सेवा है, तो:

• [C-2-1] उपयोगकर्ताओं को कॉन्टेंट कैप्चर करने वाली सेवा को, उपयोगकर्ता के इंस्टॉल किए जा सकने वाले ऐप्लिकेशन या सेवा से बदलने की अनुमति नहीं देनी चाहिए. साथ ही, सिर्फ़ पहले से इंस्टॉल की गई सेवा को ऐसा डेटा कैप्चर करने की अनुमति देनी चाहिए.
• [C-2-2] पहले से इंस्टॉल की गई कॉन्टेंट कैप्चर करने की सेवा के अलावा, किसी भी ऐप्लिकेशन को ऐसा डेटा कैप्चर करने की अनुमति नहीं दी जानी चाहिए.
• [C-2-3] कॉन्टेंट कैप्चर करने की सेवा को बंद करने के लिए, उपयोगकर्ता को सुविधा देना ज़रूरी है.
• [C-2-4] कॉन्टेंट कैप्चर करने वाली सेवा के पास मौजूद Android की अनुमतियों को मैनेज करने के लिए, उपयोगकर्ता को आसानी से ऐक्सेस करने की सुविधा देनी होगी. साथ ही, सेक्शन 9.1 में बताए गए Android की अनुमतियों के मॉडल का पालन करना होगा. अनुमति.

• [C-SR] कॉन्टेंट कैप्चर करने वाली सेवा के कॉम्पोनेंट को अलग रखने का ज़रूर सुझाव दिया जाता है. उदाहरण के लिए, सेवा को बांधना या प्रोसेस आईडी को अन्य सिस्टम कॉम्पोनेंट के साथ शेयर करना. हालांकि, इनके लिए ऐसा नहीं करना चाहिए:

  • टेलीफ़ोनी, संपर्क, सिस्टम यूज़र इंटरफ़ेस (यूआई), और मीडिया

9.8.7. क्लिपबोर्ड का ऐक्सेस

डिवाइस पर लागू करने के तरीके:

• [C-0-1] ऐप्लिकेशन को क्लिपबोर्ड पर मौजूद डेटा को तब तक नहीं दिखाना चाहिए, जब तक कि वह डिफ़ॉल्ट IME या फ़िलहाल फ़ोकस में न हो. जैसे, ClipboardManager API के ज़रिए.

9.8.8. जगह की जानकारी

डिवाइस पर लागू करने के तरीके:

• [C-0-1] उपयोगकर्ता की सहमति लिए बिना या उपयोगकर्ता के निर्देश के बिना, डिवाइस की जगह की जानकारी की सेटिंग और वाई-फ़ाई/ब्लूटूथ स्कैनिंग की सेटिंग को चालू/बंद नहीं किया जाना चाहिए.
• [C-0-2] ऐप्लिकेशन में, जगह की जानकारी से जुड़ी जानकारी ऐक्सेस करने के लिए, उपयोगकर्ता को विकल्प देना ज़रूरी है. इसमें, जगह की जानकारी के हाल ही के अनुरोध, ऐप्लिकेशन लेवल की अनुमतियां, और जगह की जानकारी का पता लगाने के लिए वाई-फ़ाई/ब्लूटूथ स्कैनिंग का इस्तेमाल शामिल है.
• [C-0-3] यह पक्का करना ज़रूरी है कि आपातकालीन जगह की जानकारी देने वाली सेवा को बायपास करने वाले एपीआई [LocationRequest.setLocationSettingsIgnored()] का इस्तेमाल करने वाला ऐप्लिकेशन, उपयोगकर्ता के शुरू किए गए आपातकालीन सेशन के लिए हो. जैसे, 911 पर कॉल करना या 911 पर मैसेज भेजना.
• [C-0-4] इमरजेंसी लोकेशन बायपास एपीआई की, डिवाइस की जगह की जानकारी की सेटिंग में बदलाव किए बिना, उन्हें बायपास करने की सुविधा को बनाए रखना ज़रूरी है.
• [C-0-5] ऐप्लिकेशन को ऐसी सूचना शेड्यूल करनी चाहिए जो उपयोगकर्ता को [ACCESS_BACKGROUND_LOCATION] अनुमति का इस्तेमाल करके, बैकग्राउंड में उसकी जगह की जानकारी ऐक्सेस करने के बाद, उसकी याद दिलाए.

9.9. डेटा स्टोरेज एन्क्रिप्शन

सभी डिवाइसों को सेक्शन 9.9.1 की ज़रूरी शर्तें पूरी करनी होंगी. इस दस्तावेज़ में बताए गए एपीआई लेवल से पहले लॉन्च किए गए डिवाइसों को सेक्शन 9.9.2 और 9.9.3 की ज़रूरी शर्तों से छूट मिली है. इसके बजाय, उन्हें उस एपीआई लेवल के हिसाब से, Android के साथ काम करने की जानकारी वाले दस्तावेज़ के सेक्शन 9.9 में बताई गई ज़रूरी शर्तों को पूरा करना होगा जिस पर डिवाइस लॉन्च किया गया था.

9.9.1. डायरेक्ट बूट

डिवाइस पर लागू करने के तरीके:

• [C-0-1] डायरेक्ट बूट मोड एपीआई लागू करना ज़रूरी है. भले ही, वे स्टोरेज एन्क्रिप्शन के साथ काम न करते हों.

• [C-0-2] ACTION_LOCKED_BOOT_COMPLETED और ACTION_USER_UNLOCKED इंटेंट को अब भी ब्रॉडकास्ट किया जाना चाहिए, ताकि डायरेक्ट बूट की सुविधा वाले ऐप्लिकेशन को यह सिग्नल दिया जा सके कि डिवाइस एन्क्रिप्ट (DE) और क्रेडेंशियल एन्क्रिप्ट (CE) स्टोरेज की जगहें, उपयोगकर्ता के लिए उपलब्ध हैं.

9.9.2. एन्क्रिप्शन से जुड़ी ज़रूरी शर्तें

डिवाइस पर लागू करने के तरीके:

• [C-0-1] ऐप्लिकेशन के निजी डेटा (/data पार्टीशन) के साथ-साथ, ऐप्लिकेशन के शेयर किए गए स्टोरेज के पार्टीशन (/sdcard पार्टीशन) को एन्क्रिप्ट करना ज़रूरी है. हालांकि, ऐसा तब ही करना होगा, जब यह पार्टीशन डिवाइस का हमेशा मौजूद रहने वाला और हटाया नहीं जा सकने वाला हिस्सा हो.
• [C-0-2] उपयोगकर्ता के आउट-ऑफ़-बॉक्स सेटअप पूरा करने के बाद, डेटा स्टोरेज को डिफ़ॉल्ट रूप से एन्क्रिप्ट (सुरक्षित) करना ज़रूरी है.
• [C-0-3] फ़ाइल के आधार पर एन्क्रिप्शन (एफ़बीई) लागू करके, डेटा स्टोरेज को एन्क्रिप्ट करने से जुड़ी ऊपर दी गई ज़रूरी शर्त को पूरा करना ज़रूरी है.

9.9.3. फ़ाइल के आधार पर एन्क्रिप्ट (सुरक्षित) करने का तरीका

एन्क्रिप्ट (सुरक्षित) किए गए डिवाइस:

• [C-1-1] डिवाइस को उपयोगकर्ता से क्रेडेंशियल मांगे बिना, तुरंत चालू होना चाहिए. साथ ही, ACTION_LOCKED_BOOT_COMPLETED मैसेज ब्रॉडकास्ट होने के बाद, डिवाइस को सीधे चालू करने की सुविधा वाले ऐप्लिकेशन को डिवाइस के एन्क्रिप्ट किए गए (DE) स्टोरेज को ऐक्सेस करने की अनुमति देनी चाहिए.
• [C-1-2] उपयोगकर्ता के डिवाइस को अनलॉक करने के बाद ही, क्रेडेंशियल एन्क्रिप्ट (सीई) स्टोरेज को ऐक्सेस करने की अनुमति दी जानी चाहिए. इसके लिए, उपयोगकर्ता को अपने क्रेडेंशियल (जैसे, पासकोड, पिन, पैटर्न या फ़िंगरप्रिंट) डालने होंगे और ACTION_USER_UNLOCKED मैसेज ब्रॉडकास्ट किया जाना चाहिए.
• [C-1-3] उपयोगकर्ता से मिले क्रेडेंशियल या रजिस्टर की गई एस्क्रो कुंजी के बिना, सीई से सुरक्षित स्टोरेज को अनलॉक करने का कोई तरीका नहीं दिया जाना चाहिए.
• [C-1-4] यह ज़रूरी है कि वेरिफ़ाइड बूट का इस्तेमाल किया जाए. साथ ही, यह पक्का किया जाए कि डीई कुंजियां, डिवाइस के हार्डवेयर रूट ऑफ़ ट्रस्ट से क्रिप्टोग्राफ़िक तरीके से जुड़ी हों.
• [C-1-5] फ़ाइल के कॉन्टेंट को एईएस-256-XTS या Adiantum का इस्तेमाल करके एन्क्रिप्ट करना ज़रूरी है. AES-256-XTS, 256-बिट साइफ़र कुंजी की लंबाई वाले ऐडवांस एन्क्रिप्शन स्टैंडर्ड को दिखाता है. यह XTS मोड में काम करता है. कुंजी की पूरी लंबाई 512 बिट होती है. Adiantum का मतलब Adiantum-XChaCha12-AES से है, जैसा कि https://github.com/google/adiantum पर बताया गया है.
• [C-1-6] फ़ाइल के नामों को AES-256-CBC-CTS या Adiantum का इस्तेमाल करके एन्क्रिप्ट करना ज़रूरी है.

• [C-1-12] अगर डिवाइस में बेहतर एन्क्रिप्शन स्टैंडर्ड (AES) के निर्देश हैं, तो फ़ाइल के कॉन्टेंट के लिए AES-256-XTS और फ़ाइल के नामों के लिए Adiantum के बजाय AES-256-CBC-CTS का इस्तेमाल करना ज़रूरी है. AES निर्देश, ARM-आधारित डिवाइसों पर ARMv8 क्रिप्टोग्राफ़ी एक्सटेंशन या x86-आधारित डिवाइसों पर AES-NI होते हैं. अगर डिवाइस में AES निर्देश नहीं हैं, तो हो सकता है कि डिवाइस Adiantum का इस्तेमाल करे.

• सीई और डीई स्टोरेज एरिया को सुरक्षित रखने वाली कुंजियां:

• [C-1-7] यह ज़रूरी है कि इसे क्रिप्टोग्राफ़िक तरीके से, हार्डवेयर के साथ काम करने वाले पासकोड स्टोर से जोड़ा गया हो.

• [C-1-8] सीई पासकोड, उपयोगकर्ता की लॉक स्क्रीन के क्रेडेंशियल से बंधे होने चाहिए.
• [C-1-9] अगर उपयोगकर्ता ने लॉक स्क्रीन के क्रेडेंशियल नहीं दिए हैं, तो सीई कुंजियों को डिफ़ॉल्ट पासवर्ड से बंधा होना चाहिए.
• [C-1-10] यह यूनीक और अलग-अलग होनी चाहिए. दूसरे शब्दों में, किसी भी उपयोगकर्ता की सीई या डीई कुंजी, किसी दूसरे उपयोगकर्ता की सीई या डीई कुंजी से मेल नहीं खाती.
• [C-1-11] ज़रूरी सिफर, कुंजी की लंबाई, और मोड का इस्तेमाल करना ज़रूरी है.

• [C-SR] हमारा सुझाव है कि फ़ाइल सिस्टम के मेटाडेटा को एन्क्रिप्ट करें. जैसे, फ़ाइल का साइज़, मालिकाना हक, मोड, और एक्सटेंडेड एट्रिब्यूट (xattrs). इसके लिए, डिवाइस के हार्डवेयर रूट ऑफ़ ट्रस्ट से जुड़ी कुंजी का इस्तेमाल करें.

• पहले से इंस्टॉल किए गए ज़रूरी ऐप्लिकेशन (जैसे, अलार्म, फ़ोन, मैसेंजर) को डायरेक्ट बूट के बारे में जानकारी देनी चाहिए.

अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट, Linux kernel "fscrypt" एन्क्रिप्शन सुविधा के आधार पर, इस सुविधा को लागू करने का सबसे सही तरीका उपलब्ध कराता है.

9.10. डिवाइस इंटिग्रिटी

नीचे दी गई ज़रूरी शर्तों से यह पक्का होता है कि डिवाइस के इंटिग्रिटी स्टेटस की जानकारी साफ़ तौर पर दी गई हो. डिवाइस पर लागू करने के तरीके:

• [C-0-1] सिस्टम एपीआई के तरीके PersistentDataBlockManager.getFlashLockState() की मदद से, यह सही तरीके से रिपोर्ट करना ज़रूरी है कि उनके बूटलोडर की स्थिति, सिस्टम इमेज को फ़्लैश करने की अनुमति देती है या नहीं. FLASH_LOCK_UNKNOWN स्थिति, Android के पुराने वर्शन से अपग्रेड किए गए डिवाइसों के लिए रिज़र्व है. इस वर्शन में, सिस्टम एपीआई का यह नया तरीका मौजूद नहीं था.

• [C-0-2] डिवाइस की सुरक्षा के लिए, यह ज़रूरी है कि डिवाइस पर वेरिफ़ाइड बूट की सुविधा काम करती हो.

अगर डिवाइस, Android के पुराने वर्शन पर पुष्टि किए गए बूट की सुविधा के बिना लॉन्च किए जा चुके हैं और सिस्टम सॉफ़्टवेयर अपडेट के साथ इस सुविधा को जोड़ा नहीं जा सकता, तो उन्हें इस ज़रूरी शर्त से छूट मिल सकती है.

वेरिफ़ाइड बूट एक ऐसी सुविधा है जो डिवाइस के सॉफ़्टवेयर की सुरक्षा की गारंटी देती है. अगर डिवाइस पर यह सुविधा काम करती है, तो:

• [C-1-1] प्लैटफ़ॉर्म की सुविधा के फ़्लैग android.software.verified_boot के बारे में एलान करना ज़रूरी है.
• [C-1-2] हर बूट सीक्वेंस पर पुष्टि करना ज़रूरी है.
• [C-1-3] पुष्टि की प्रोसेस, बदलाव न की जा सकने वाली हार्डवेयर कुंजी से शुरू होनी चाहिए. यह कुंजी, भरोसे का रूट होती है और सिस्टम के पार्टीशन तक जाती है.
• [C-1-4] अगले चरण में कोड को लागू करने से पहले, सभी बाइट की पुष्टि करना ज़रूरी है. इससे, अगले चरण में बाइट की पूरी सुरक्षा और पुष्टि की जा सकेगी.
• [C-1-5] पुष्टि करने के लिए, ऐसे एल्गोरिदम का इस्तेमाल करना ज़रूरी है जो हैशिंग एल्गोरिदम (SHA-256) और सार्वजनिक कुंजी के साइज़ (RSA-2048) के लिए, एनआईएसटी के मौजूदा सुझावों के मुताबिक हों.
• [C-1-6] सिस्टम की पुष्टि न होने पर, डिवाइस को बूट होने की अनुमति नहीं दी जानी चाहिए. हालांकि, अगर उपयोगकर्ता बूट करने की कोशिश करने की सहमति देता है, तो ऐसे में पुष्टि नहीं किए गए स्टोरेज ब्लॉक के डेटा का इस्तेमाल नहीं किया जाना चाहिए.
• [C-1-7] डिवाइस पर पुष्टि किए गए पार्टीशन में तब तक बदलाव नहीं किया जाना चाहिए, जब तक उपयोगकर्ता ने साफ़ तौर पर बूटलोडर को अनलॉक नहीं किया है.
• [C-SR] अगर डिवाइस में एक से ज़्यादा अलग-अलग चिप (जैसे, रेडियो, खास इमेज प्रोसेसर) हैं, तो हमारा सुझाव है कि बूट करने के दौरान हर चरण की पुष्टि की जाए.
• [C-1-8] बदलाव किए जाने की जानकारी देने वाले स्टोरेज का इस्तेमाल करना ज़रूरी है: यह जानकारी सेव करने के लिए कि बूटलोडर अनलॉक है या नहीं. टेंपर-एविडेंस स्टोरेज का मतलब है कि बूटलोडर यह पता लगा सकता है कि Android में स्टोरेज में छेड़छाड़ की गई है या नहीं.
• [C-1-9] डिवाइस का इस्तेमाल करते समय, उपयोगकर्ता को सूचना देना ज़रूरी है. साथ ही, बूटलोडर लॉक मोड से बूटलोडर अनलॉक मोड पर स्विच करने से पहले, उपयोगकर्ता से पुष्टि करना ज़रूरी है.
• [C-1-10] Android के इस्तेमाल किए जाने वाले पार्टीशन (जैसे, बूट, सिस्टम पार्टीशन) के लिए, रोलबैक सुरक्षा लागू करना ज़रूरी है. साथ ही, इस्तेमाल किए जा सकने वाले कम से कम ओएस वर्शन का पता लगाने के लिए इस्तेमाल किए जाने वाले मेटाडेटा को सेव करने के लिए, बदलाव होने से बचाने वाले स्टोरेज का इस्तेमाल करना ज़रूरी है.
• [C-SR] हमारा सुझाव है कि आप वेरिफ़ाइड बूट की प्रोसेस से सुरक्षित किए गए पार्टीशन में, भरोसे की चेन की मदद से, ऐक्सेस लेवल की सुविधा वाले सभी ऐप्लिकेशन की APK फ़ाइलों की पुष्टि करें.
• [C-SR] हमारा सुझाव है कि किसी भी एक्ज़ीक्यूटेबल आर्टफ़ैक्ट को चलाने से पहले उसकी पुष्टि करें. ये ऐसे आर्टफ़ैक्ट होते हैं जिन्हें ऐक्सेस करने की अनुमति वाले ऐप्लिकेशन ने अपनी APK फ़ाइल के बाहर से लोड किया है. जैसे, डाइनैमिक तौर पर लोड किया गया कोड या कंपाइल किया गया कोड. हमारा सुझाव है कि इन आर्टफ़ैक्ट को बिलकुल भी न चलाएं.
• ऐसे किसी भी कॉम्पोनेंट के लिए रोलबैक सुरक्षा लागू की जानी चाहिए जिसमें पर्सिस्टेंट फ़र्मवेयर (जैसे, मॉडेम, कैमरा) हो. साथ ही, इस्तेमाल किए जा सकने वाले कम से कम वर्शन का पता लगाने के लिए इस्तेमाल किए जाने वाले मेटाडेटा को सेव करने के लिए, टेंपर-एविडेंट स्टोरेज का इस्तेमाल किया जाना चाहिए.

अगर डिवाइस को Android के पुराने वर्शन पर, C-1-8 से C-1-10 तक की ज़रूरी शर्तों के बिना लॉन्च किया जा चुका है और सिस्टम सॉफ़्टवेयर अपडेट की मदद से इन ज़रूरी शर्तों को पूरा नहीं किया जा सकता, तो हो सकता है कि उन्हें इन शर्तों से छूट मिल जाए.

अपस्ट्रीम Android Open Source Project, external/avb/ रिपॉज़िटरी में इस सुविधा को लागू करने का सुझाव देता है. इसे Android को लोड करने के लिए इस्तेमाल किए जाने वाले बूटलोडर में इंटिग्रेट किया जा सकता है.

डिवाइस पर लागू करने के तरीके:

• [C-R] Android Protected Confirmation API के साथ काम करने का सुझाव दिया जाता है.

अगर डिवाइस पर Android Protected Confirmation API काम करता है, तो:

• [C-3-1] ConfirmationPrompt.isSupported() एपीआई के लिए, true की रिपोर्ट करना ज़रूरी है.

• [C-3-2] यह पक्का करना ज़रूरी है कि Android OS में चलने वाला कोड, उपयोगकर्ता के इंटरैक्शन के बिना कोई रिस्पॉन्स जनरेट न कर सके. भले ही, वह कोड नुकसान पहुंचाने वाला हो या कोई और. इसमें, Android OS का कर्नेल भी शामिल है.

• [C-3-3] यह पक्का करना ज़रूरी है कि उपयोगकर्ता ने प्रॉम्प्ट किए गए मैसेज की समीक्षा करके उसे स्वीकार किया हो. भले ही, Android OS और उसके कर्नेल को हैक कर लिया गया हो.

9.11. कुंजियां और क्रेडेंशियल

Android Keystore System की मदद से, ऐप्लिकेशन डेवलपर किसी कंटेनर में क्रिप्टोग्राफ़िक पासकोड सेव कर सकते हैं. साथ ही, KeyChain API या Keystore API की मदद से, क्रिप्टोग्राफ़िक ऑपरेशन में उनका इस्तेमाल कर सकते हैं. डिवाइस पर लागू करने के तरीके:

• [C-0-1] कम से कम 8,192 कुंजियों को इंपोर्ट या जनरेट करने की अनुमति होनी चाहिए.
• [C-0-2] लॉक स्क्रीन की पुष्टि करने की सुविधा, कोशिशों की दर को सीमित करनी चाहिए. साथ ही, इसमें एक्सपोनेंशियल बैकऑफ़ एल्गोरिदम होना चाहिए. 150 बार कोशिश करने के बाद, हर बार कम से कम 24 घंटे इंतज़ार करना ज़रूरी है.
• जनरेट की जा सकने वाली कुंजियों की संख्या को सीमित नहीं करना चाहिए

जब डिवाइस पर सुरक्षित लॉक स्क्रीन की सुविधा काम करती है, तो:

• [C-1-1] अलग से चलाए जाने वाले एनवायरमेंट में, पासकोड को लागू करने के लिए बैक अप लेना ज़रूरी है.
• [C-1-2] Android Keystore सिस्टम के साथ काम करने वाले एल्गोरिदम को सही तरीके से काम करने के लिए, RSA, AES, ECDSA, और HMAC क्रिप्टोग्राफ़िक एल्गोरिदम और MD5, SHA1, और SHA-2 फ़ैमिली हैश फ़ंक्शन लागू होने चाहिए. ये एल्गोरिदम और फ़ंक्शन, कर्नेल और उसके बाद के लेवल पर चलने वाले कोड से सुरक्षित तौर पर अलग होने चाहिए. सुरक्षित आइसोलेशन, उन सभी संभावित तरीकों को ब्लॉक करना चाहिए जिनसे कर्नेल या यूज़रस्पेस कोड, डीएमए के साथ-साथ आइसोलेट किए गए एनवायरमेंट की इंटरनल स्टेटस को ऐक्सेस कर सकता है. अपस्ट्रीम Android Open Source Project (AOSP), Trusty को लागू करके इस ज़रूरी शर्त को पूरा करता है. हालांकि, ARM TrustZone पर आधारित कोई अन्य समाधान या तीसरे पक्ष की समीक्षा के बाद, हाइपरवाइजर पर आधारित सही आइसोलेशन को सुरक्षित तरीके से लागू करना, इसके अन्य विकल्प हैं.
• [C-1-3] लॉक स्क्रीन की पुष्टि, अलग से चलाए जाने वाले एनवायरमेंट में करनी चाहिए. पुष्टि होने के बाद ही, पुष्टि करने के लिए इस्तेमाल की जाने वाली कुंजियों का इस्तेमाल करने की अनुमति दें. लॉक स्क्रीन के क्रेडेंशियल इस तरह से सेव किए जाने चाहिए कि सिर्फ़ अलग-अलग तरीके से चलाए जाने वाले एनवायरमेंट में लॉक स्क्रीन की पुष्टि की जा सके. अपस्ट्रीम Android Open Source Project, Gatekeeper Hardware Abstraction Layer (HAL) और Trusty उपलब्ध कराता है. इनका इस्तेमाल, इस ज़रूरी शर्त को पूरा करने के लिए किया जा सकता है.
• [C-1-4] यह ज़रूरी है कि कुंजी की पुष्टि करने की सुविधा काम करे. इसमें, पुष्टि करने के लिए इस्तेमाल होने वाली साइनिंग कुंजी को सुरक्षित हार्डवेयर से सुरक्षित किया गया हो और साइनिंग की प्रोसेस, सुरक्षित हार्डवेयर में की गई हो. पुष्टि करने के लिए इस्तेमाल होने वाली साइनिंग पासकोड को ज़रूर ज़्यादा से ज़्यादा डिवाइसों पर शेयर किया जाना चाहिए, ताकि इनका इस्तेमाल डिवाइस आइडेंटिफ़ायर के तौर पर न किया जा सके. इस शर्त को पूरा करने का एक तरीका यह है कि जब तक किसी SKU की कम से कम 1,00,000 यूनिट तैयार न हो जाएं, तब तक एक ही पुष्टि करने वाली कुंजी शेयर करें. अगर किसी SKU की 1,00,000 से ज़्यादा यूनिट बनाई जाती हैं, तो हर 1,00,000 यूनिट के लिए अलग-अलग कुंजी का इस्तेमाल किया जा सकता है.

ध्यान दें कि अगर किसी डिवाइस पर, Android के किसी पुराने वर्शन में पहले से ही एन्क्रिप्शन लागू है, तो उस डिवाइस को अलग से एक सुरक्षित प्रोसेसिंग एनवायरमेंट में काम करने वाला पासकोड स्टोर करने की ज़रूरत नहीं होती. साथ ही, उस डिवाइस पर पासकोड की पुष्टि करने की सुविधा भी काम नहीं करती. हालांकि, अगर डिवाइस पर android.hardware.fingerprint सुविधा का इस्तेमाल किया जा रहा है, तो उसे अलग से एक सुरक्षित प्रोसेसिंग एनवायरमेंट में काम करने वाला पासकोड स्टोर करना होगा.

• [C-1-5] डिवाइस को अनलॉक से लॉक होने में लगने वाले समय को उपयोगकर्ता के हिसाब से सेट किया जा सकता है. यह समय कम से कम 15 सेकंड होना चाहिए.

9.11.1. सुरक्षित लॉक स्क्रीन और पुष्टि

AOSP में, पुष्टि करने के लिए अलग-अलग लेवल का मॉडल अपनाया जाता है. इसमें, नॉलेज फ़ैक्ट्री पर आधारित मुख्य पुष्टि के साथ, सेकंडरी के तौर पर मज़बूत बायोमेट्रिक या तीसरे लेवल के तौर पर कम मज़बूत मोडैलिटी का इस्तेमाल किया जा सकता है.

डिवाइस पर लागू करने के तरीके:

• [C-SR] हमारा सुझाव है कि पुष्टि करने के मुख्य तरीके के तौर पर, इनमें से सिर्फ़ एक को सेट करें:
  • अंकों वाला पिन
  • अक्षर और अंकों वाला पासवर्ड
  • 3x3 बिंदुओं के ग्रिड पर स्वाइप पैटर्न

ध्यान दें कि पुष्टि करने के ऊपर बताए गए तरीकों को, इस दस्तावेज़ में पुष्टि करने के मुख्य तरीकों के तौर पर सुझाया गया है.

अगर डिवाइस में पुष्टि करने के सुझाए गए मुख्य तरीकों को जोड़ा जाता है या उनमें बदलाव किया जाता है और स्क्रीन लॉक करने के सुरक्षित तरीके के तौर पर पुष्टि करने के किसी नए तरीके का इस्तेमाल किया जाता है, तो पुष्टि करने का नया तरीका:

• [C-2-1] यह उपयोगकर्ता की पुष्टि करने का ऐसा तरीका होना चाहिए जैसा कि कुंजी के इस्तेमाल के लिए उपयोगकर्ता की पुष्टि करना ज़रूरी है में बताया गया है.
• [C-2-2] उपयोगकर्ता के सुरक्षित लॉक स्क्रीन को अनलॉक करने पर, तीसरे पक्ष के डेवलपर ऐप्लिकेशन के लिए सभी कुंजियों को अनलॉक करना ज़रूरी है. उदाहरण के लिए, तीसरे पक्ष के डेवलपर ऐप्लिकेशन के लिए, सभी कुंजियां createConfirmDeviceCredentialIntent और setUserAuthenticationRequired जैसे काम के एपीआई के ज़रिए उपलब्ध होनी चाहिए.

अगर डिवाइस में लॉक स्क्रीन को अनलॉक करने के लिए, पुष्टि करने के तरीकों को जोड़ा जाता है या उनमें बदलाव किया जाता है, तो यह ज़रूरी है कि वे किसी ऐसे गुप्त कोड पर आधारित हों जिसकी जानकारी पहले से हो. साथ ही, पुष्टि करने के नए तरीके का इस्तेमाल, स्क्रीन को लॉक करने के सुरक्षित तरीके के तौर पर किया जाना चाहिए:

• [C-3-1] इनपुट की कम से कम अनुमति वाली लंबाई का एन्ट्रापी 10 बिट से ज़्यादा होना चाहिए.
• [C-3-2] सभी संभावित इनपुट की मैक्सिमम एन्ट्रापी 18 बिट से ज़्यादा होनी चाहिए.
• [C-3-3] पुष्टि करने का नया तरीका, AOSP में लागू और दिए गए पुष्टि करने के सुझाए गए मुख्य तरीकों (जैसे, पिन, पैटर्न, पासवर्ड) की जगह नहीं ले सकता.
• [C-3-4] जब डिवाइस नीति नियंत्रक (डीपीसी) ऐप्लिकेशन ने DevicePolicyManager.setPasswordQuality() तरीके से पासवर्ड की क्वालिटी से जुड़ी नीति को सेट किया हो, तो पुष्टि करने का नया तरीका बंद करना ज़रूरी है. साथ ही, PASSWORD_QUALITY_SOMETHING से ज़्यादा पाबंदी वाला क्वालिटी कॉन्स्टेंट इस्तेमाल करना चाहिए.
• [C-3-5] पुष्टि करने के नए तरीके, हर 72 घंटे या उससे कम समय में, पुष्टि करने के सुझाए गए मुख्य तरीकों (जैसे, पिन, पैटर्न, पासवर्ड) पर वापस आ जाने चाहिए. इसके अलावा, उपयोगकर्ता को साफ़ तौर पर यह भी बताया जाना चाहिए कि उनके डेटा की निजता बनाए रखने के लिए, कुछ डेटा का बैक अप नहीं लिया जाएगा.

अगर डिवाइस में लॉक स्क्रीन को अनलॉक करने के लिए, पुष्टि करने के सुझाए गए मुख्य तरीकों में बदलाव किया जाता है या उन्हें जोड़ा जाता है और स्क्रीन को लॉक करने के सुरक्षित तरीके के तौर पर, बायोमेट्रिक्स पर आधारित पुष्टि करने के नए तरीके का इस्तेमाल किया जाता है, तो नए तरीके के लिए ये शर्तें लागू होती हैं:

• [C-4-1] सुविधा के लिए, सेक्शन 7.3.10 में बताई गई सभी ज़रूरी शर्तें पूरी करनी होंगी.
• [C-4-2] पुष्टि करने के लिए सुझाए गए किसी मुख्य तरीके का इस्तेमाल करने के लिए, फ़ॉल-बैक मैकेनिज्म होना चाहिए. यह तरीका, किसी ऐसे गुप्त कोड पर आधारित होना चाहिए जिसकी जानकारी पहले से हो.
• [C-4-3] इसे बंद करना ज़रूरी है. साथ ही, स्क्रीन को अनलॉक करने के लिए, सिर्फ़ सुझाई गई मुख्य पुष्टि की अनुमति दें. ऐसा तब किया जा सकता है, जब डिवाइस नीति नियंत्रक (डीपीसी) ऐप्लिकेशन ने DevicePolicyManager.setKeyguardDisabledFeatures() तरीके को कॉल करके, कीगार्ड की सुविधा की नीति सेट की हो. साथ ही, उसने इससे जुड़े किसी भी बायोमेट्रिक फ़्लैग (जैसे, KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE या KEYGUARD_DISABLE_IRIS) का इस्तेमाल किया हो.

अगर बायोमेट्रिक ऑथेंटिकेशन के तरीके, सेक्शन 7.3.10 में बताई गई मज़बूत पुष्टि करने की ज़रूरी शर्तों को पूरा नहीं करते हैं, तो:

• [C-5-1] अगर डिवाइस नीति नियंत्रक (डीपीसी) ऐप्लिकेशन ने DevicePolicyManager.setPasswordQuality() तरीके से पासवर्ड की क्वालिटी से जुड़ी नीति को सेट किया है और PASSWORD_QUALITY_BIOMETRIC_WEAK से ज़्यादा पाबंदी वाला क्वालिटी कॉन्स्टेंट इस्तेमाल किया है, तो इन तरीकों को बंद करना ज़रूरी है.
• [C-5-2] चार घंटे तक डिवाइस इस्तेमाल न करने पर, उपयोगकर्ता को पुष्टि करने के लिए कहा जाना चाहिए. पुष्टि करने के लिए, प्राइमरी तरीके के तौर पर पिन, पैटर्न या पासवर्ड का इस्तेमाल किया जा सकता है. डिवाइस के क्रेडेंशियल की पुष्टि होने के बाद, डिवाइस के इस्तेमाल में न होने पर टाइम आउट की अवधि रीसेट हो जाती है.
• [C-5-3] इन तरीकों को सुरक्षित लॉक स्क्रीन के तौर पर इस्तेमाल नहीं किया जाना चाहिए. साथ ही, इनमें नीचे दिए गए सेक्शन में C-8 से शुरू होने वाली ज़रूरी शर्तें पूरी होनी चाहिए.

अगर डिवाइस में लॉक स्क्रीन को अनलॉक करने के लिए, पुष्टि करने के तरीकों को जोड़ा जाता है या उनमें बदलाव किया जाता है और पुष्टि करने का नया तरीका, किसी फ़िज़िकल टोकन या जगह की जानकारी पर आधारित है, तो:

• [C-6-1] पुष्टि करने के लिए सुझाए गए किसी मुख्य तरीके का इस्तेमाल करने के लिए, उनके पास फ़ॉल-बैक मैकेनिज्म होना चाहिए. यह तरीका, किसी ऐसे गुप्त पासवर्ड पर आधारित होना चाहिए जिसकी जानकारी सभी के पास हो. साथ ही, यह सुरक्षित लॉक स्क्रीन के तौर पर इस्तेमाल किए जाने की ज़रूरी शर्तें पूरी करता हो.
• [C-6-2] डिवाइस नीति नियंत्रक (डीपीसी) ऐप्लिकेशन ने DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) या DevicePolicyManager.setPasswordQuality() तरीके से नीति सेट की है, तो स्क्रीन अनलॉक करने के लिए, पुष्टि करने के सुझाए गए मुख्य तरीकों में से सिर्फ़ एक को अनुमति दी जानी चाहिए. हालांकि, PASSWORD_QUALITY_UNSPECIFIED से ज़्यादा पाबंदी वाले क्वालिटी कॉन्स्टेंट का इस्तेमाल किया जाना चाहिए.
• [C-6-3] उपयोगकर्ता को पुष्टि करने के लिए, सुझाए गए मुख्य तरीकों (जैसे, पिन, पैटर्न, पासवर्ड) में से किसी एक का इस्तेमाल करना होगा. ऐसा कम से कम हर चार घंटे या उससे कम समय में करना होगा.
• [C-6-4] नए तरीके को सुरक्षित लॉक स्क्रीन के तौर पर इस्तेमाल नहीं किया जाना चाहिए. साथ ही, इसे नीचे C-8 में बताई गई शर्तों का पालन करना होगा.

अगर डिवाइस में सुरक्षित लॉक स्क्रीन है और एक या उससे ज़्यादा भरोसेमंद एजेंट हैं, जो TrustAgentService सिस्टम एपीआई को लागू करते हैं, तो:

• [C-7-1] जब डिवाइस लॉक को कुछ समय के लिए रोका जाता है या भरोसेमंद एजेंट(एजेंटों) के पास उसे अनलॉक रखने का विकल्प होता है, तो सेटिंग मेन्यू और लॉक स्क्रीन पर इसकी साफ़ तौर पर जानकारी होनी चाहिए. उदाहरण के लिए, AOSP इस ज़रूरी शर्त को पूरा करता है. इसके लिए, सेटिंग मेन्यू में "स्क्रीन अपने-आप लॉक होने की सेटिंग" और "पावर बटन से तुरंत लॉक हो जाता है" के लिए टेक्स्ट की जानकारी दिखाता है. साथ ही, लॉक स्क्रीन पर एक अलग आइकॉन दिखाता है.
• [C-7-2] DevicePolicyManager क्लास में मौजूद सभी ट्रस्ट एजेंट एपीआई का सम्मान करना और उन्हें पूरी तरह से लागू करना ज़रूरी है. जैसे, KEYGUARD_DISABLE_TRUST_AGENTS कॉन्स्टेंट.
• [C-7-3] TrustAgentService.addEscrowToken() फ़ंक्शन को किसी ऐसे डिवाइस पर पूरी तरह से लागू नहीं किया जाना चाहिए जिसका इस्तेमाल मुख्य निजी डिवाइस (उदाहरण के लिए, हैंडहेल्ड) के तौर पर किया जाता है. हालांकि, इस फ़ंक्शन को आम तौर पर शेयर किए जाने वाले डिवाइसों (उदाहरण के लिए, Android Television या वाहन से जुड़े डिवाइस) पर पूरी तरह से लागू किया जा सकता है.
• [C-7-4] TrustAgentService.addEscrowToken() ने जो सेव किए गए टोकन जोड़े हैं उन्हें एन्क्रिप्ट करना ज़रूरी है.
• [C-7-5] एन्क्रिप्शन पासकोड या एस्क्रो टोकन को उसी डिवाइस पर सेव नहीं करना चाहिए जिस पर पासकोड का इस्तेमाल किया जाता है. उदाहरण के लिए, फ़ोन पर सेव की गई कुंजी से, टीवी पर उपयोगकर्ता खाता अनलॉक किया जा सकता है.
• [C-7-6] डेटा स्टोरेज को डिक्रिप्ट करने के लिए, एस्क्रो टोकन को चालू करने से पहले, उपयोगकर्ता को सुरक्षा से जुड़े असर के बारे में ज़रूर बताना चाहिए.
• [C-7-7] पुष्टि करने के लिए सुझाए गए मुख्य तरीकों में से किसी एक का इस्तेमाल करने के लिए, फ़ॉल-बैक मैकेनिज्म होना चाहिए.
• [C-7-8] उपयोगकर्ता को पुष्टि करने के लिए, सुझाए गए मुख्य तरीकों (जैसे: पिन, पैटर्न, पासवर्ड) में से किसी एक का इस्तेमाल करने के लिए, कम से कम हर 72 घंटे या उससे कम समय में एक बार ज़रूर कहा जाना चाहिए. ऐसा तब तक करना चाहिए, जब तक उपयोगकर्ता की सुरक्षा (जैसे, ड्राइवर का ध्यान भटकना) को लेकर कोई समस्या न हो.
• [C-7-9] चार घंटे तक डिवाइस के इस्तेमाल में न होने पर, उपयोगकर्ता को पुष्टि करने के लिए कहा जाना चाहिए.पुष्टि करने के लिए, प्राइमरी तरीके के तौर पर सुझाए गए पिन, पैटर्न, पासवर्ड वगैरह में से किसी एक तरीके का इस्तेमाल किया जाना चाहिए. हालांकि, अगर उपयोगकर्ता की सुरक्षा को लेकर कोई समस्या है, तो ऐसा नहीं किया जाना चाहिए. जैसे, ड्राइवर का ध्यान भटकना. डिवाइस के क्रेडेंशियल की पुष्टि होने के बाद, डिवाइस के इस्तेमाल में न होने पर टाइम आउट की अवधि रीसेट हो जाती है.
• [C-7-10] को सुरक्षित लॉक स्क्रीन के तौर पर इस्तेमाल नहीं किया जाना चाहिए. साथ ही, इसे नीचे C-8 में बताई गई पाबंदियों का पालन करना होगा.
• [C-7-11] मुख्य निजी डिवाइसों (जैसे: हैंडहेल्ड) पर, TrustAgents को डिवाइस अनलॉक करने की अनुमति नहीं दी जानी चाहिए.साथ ही, इनका इस्तेमाल सिर्फ़ पहले से अनलॉक किए गए डिवाइस को अनलॉक की स्थिति में, ज़्यादा से ज़्यादा चार घंटे तक रखने के लिए किया जा सकता है. AOSP में TrustManagerService को डिफ़ॉल्ट रूप से लागू करने से, यह ज़रूरी शर्त पूरी हो जाती है.
• [C-7-12] एस्क्रो टोकन को स्टोरेज डिवाइस से टारगेट डिवाइस पर भेजने के लिए, क्रिप्टोग्राफ़िक तरीके से सुरक्षित (उदाहरण के लिए, UKEY2) कम्यूनिकेशन चैनल का इस्तेमाल करना ज़रूरी है.

अगर डिवाइस में, ऊपर बताई गई सुरक्षित लॉक स्क्रीन को अनलॉक करने के लिए, पुष्टि करने के तरीकों को जोड़ा जाता है या उनमें बदलाव किया जाता है और कीगार्ड को अनलॉक करने के लिए, पुष्टि करने के नए तरीके का इस्तेमाल किया जाता है, तो:

• [C-8-1] जब डिवाइस नीति नियंत्रक (डीपीसी) ऐप्लिकेशन ने DevicePolicyManager.setPasswordQuality() तरीके से पासवर्ड की क्वालिटी से जुड़ी नीति को सेट किया हो, तो नया तरीका बंद करना ज़रूरी है. साथ ही, PASSWORD_QUALITY_UNSPECIFIED से ज़्यादा पाबंदी वाला क्वालिटी कॉन्स्टेंट इस्तेमाल करना चाहिए.
• [C-8-2] उन्हें DevicePolicyManager.setPasswordExpirationTimeout() से सेट किए गए, पासवर्ड की समयसीमा खत्म होने के टाइमर को रीसेट नहीं करना चाहिए.
• [C-8-3] उन्हें लॉक की स्थिति बदलने के लिए, तीसरे पक्ष के ऐप्लिकेशन के इस्तेमाल के लिए एपीआई को एक्सपोज़ नहीं करना चाहिए.

9.11.2. StrongBox

Android Keystore System की मदद से, ऐप्लिकेशन डेवलपर क्रिप्टोग्राफ़िक पासकोड को एक खास सुरक्षित प्रोसेसर में सेव कर सकते हैं. साथ ही, ऊपर बताए गए अलग से मौजूद प्रोसेसिंग एनवायरमेंट में भी सेव कर सकते हैं. इस तरह के खास सुरक्षित प्रोसेसर को "स्ट्रॉन्गबॉक्स" कहा जाता है. C-1-3 से C-1-11 तक की ज़रूरी शर्तों में बताया गया है कि किसी डिवाइस को StrongBox के तौर पर मंज़ूरी पाने के लिए, उसे कौनसी शर्तें पूरी करनी होंगी.

डिवाइस में लागू किए गए ऐसे टूल जिनमें खास तौर पर सुरक्षित प्रोसेसर होता है:

• [C-SR] StrongBox के साथ काम करने का सुझाव दिया जाता है. आने वाले समय में, StrongBox का इस्तेमाल करना ज़रूरी हो सकता है.

अगर डिवाइस पर StrongBox की सुविधा काम करती है, तो:

• [C-1-1] FEATURE_STRONGBOX_KEYSTORE का एलान करना ज़रूरी है.

• [C-1-2] खास तौर पर सुरक्षित हार्डवेयर उपलब्ध कराना ज़रूरी है. इसका इस्तेमाल, पासकोड को सुरक्षित रखने और उपयोगकर्ता की पहचान की पुष्टि करने के लिए किया जाता है. खास तौर पर सुरक्षित हार्डवेयर का इस्तेमाल, अन्य कामों के लिए भी किया जा सकता है.

• [C-1-3] इसमें अलग सीपीयू होना चाहिए, जो ऐप्लिकेशन प्रोसेसर (एपी) के साथ कोई कैश, डीआरएएम, कोप्रोसेसर या अन्य मुख्य संसाधन शेयर नहीं करता.

• [C-1-4] यह पक्का करना ज़रूरी है कि एपी के साथ शेयर किए गए किसी भी डिवाइस से, StrongBox में प्रोसेसिंग में किसी भी तरह का बदलाव न किया जा सके या StrongBox से कोई जानकारी न ली जा सके. एपी, StrongBox को ऐक्सेस करने की सुविधा को बंद या ब्लॉक कर सकता है.

• [C-1-5] डिवाइस में एक ऐसी इंटरनल क्लॉक होनी चाहिए जो सटीक समय दिखाती हो (+-10%) और एपी के मैनिपुलेशन से सुरक्षित हो.

• [C-1-6] इसमें एक ऐसा ट्रू रैंडम नंबर जनरेटर होना चाहिए जो एक जैसा और अनुमान न लगाए जा सकने वाला आउटपुट जनरेट करता हो.

• [C-1-7] डिवाइस में, छेड़छाड़ से बचाने की सुविधा होनी चाहिए. इसमें, डिवाइस में किसी तरह का बदलाव करने और गड़बड़ी करने से रोकने की सुविधा भी शामिल है.

• [C-1-8] इसमें साइड-चैनल रेज़िस्टेंस होना चाहिए. इसमें पावर, टाइमिंग, इलेक्ट्रोमैग्नेटिक रेडिएशन, और थर्मल रेडिएशन साइड चैनलों से जानकारी लीक होने से रोकने की सुविधा भी शामिल है.

• [C-1-9] आपके पास सुरक्षित स्टोरेज होना चाहिए, ताकि कॉन्टेंट की गोपनीयता, सुरक्षा, और प्रामाणिकता बनी रहे. साथ ही, कॉन्टेंट में बदलाव न हो और वह अप-टू-डेट रहे. StrongBox API की अनुमति के अलावा, स्टोरेज को पढ़ा या उसमें बदलाव नहीं किया जा सकता.

• [C-1-3] से [C-1-9] तक के नियमों का पालन करने की पुष्टि करने के लिए, डिवाइस पर लागू होने वाले नियम:

  • [C-1-10] इसमें ऐसा हार्डवेयर शामिल होना चाहिए जिसे सुरक्षित आईसी प्रोटेक्शन प्रोफ़ाइल BSI-CC-PP-0084-2014 के तहत सर्टिफ़ाइड किया गया हो या जिसकी जांच, राष्ट्रीय स्तर पर मान्यता वाली किसी टेस्टिंग लैबोरेटरी ने की हो. इस लैबोरेटरी ने स्मार्ट कार्ड पर हमले की संभावना के लिए सामान्य मानदंडों के आवेदन के मुताबिक, हमले की संभावना वाली कमज़ोरियों का आकलन किया हो.
  • [C-1-11] इसमें ऐसा फ़र्मवेयर शामिल होना चाहिए जिसका आकलन, राष्ट्रीय स्तर पर मान्यता वाली टेस्टिंग लैबोरेटरी ने किया हो. साथ ही, स्मार्ट कार्ड पर हमले की संभावना के लिए सामान्य मानदंड के मुताबिक, इसमें हमले की ज़्यादा संभावना वाली जोखिम का आकलन शामिल होना चाहिए.
  • [C-SR] हमारा सुझाव है कि आप ऐसे हार्डवेयर को शामिल करें जिसका आकलन, सुरक्षा टारगेट, इवैल्यूएशन एश्योरेंस लेवल (ईएएल) 5 का इस्तेमाल करके किया गया हो. साथ ही, AVA_VAN.5 की मदद से इसकी सुरक्षा को बेहतर बनाया गया हो. आने वाले समय में रिलीज़ होने वाले वर्शन के लिए, EAL 5 सर्टिफ़िकेशन की ज़रूरत होगी.

• [C-SR] को अंदरूनी हमले से सुरक्षा (आईएआर) देने का सुझाव दिया जाता है. इसका मतलब है कि फ़र्मवेयर साइनिंग पासकोड का ऐक्सेस रखने वाला कोई भी व्यक्ति, ऐसा फ़र्मवेयर नहीं बना सकता जिससे StrongBox से गोपनीय जानकारी लीक हो. साथ ही, वह सुरक्षा से जुड़ी ज़रूरी शर्तों को बायपास नहीं कर सकता या उपयोगकर्ता के संवेदनशील डेटा को ऐक्सेस नहीं कर सकता. आईएआर को लागू करने का सुझाया गया तरीका यह है कि फ़र्मवेयर अपडेट करने की अनुमति सिर्फ़ तब दें, जब IAuthSecret HAL के ज़रिए प्राइमरी उपयोगकर्ता का पासवर्ड दिया गया हो.

9.12. डेटा हटाना

सभी डिवाइसों पर लागू होने वाले टूल और फ़ॉर्मैट:

• [C-0-1] उपयोगकर्ताओं को "फ़ैक्ट्री डेटा रीसेट" करने का तरीका देना ज़रूरी है.
• [C-0-2] userdata फ़ाइल सिस्टम पर मौजूद सारा डेटा मिटाना ज़रूरी है.
• [C-0-3] डेटा को इस तरह मिटाएं कि वह NIST SP800-88 जैसे इंडस्ट्री स्टैंडर्ड के मुताबिक हो.
• [C-0-4] जब मुख्य उपयोगकर्ता के डिवाइस नीति नियंत्रक ऐप्लिकेशन से DevicePolicyManager.wipeData() एपीआई को कॉल किया जाता है, तो ऊपर दी गई "फ़ैक्ट्री डेटा रीसेट" प्रोसेस को ट्रिगर करना ज़रूरी है.
• डेटा को तुरंत मिटाने का विकल्प दे सकता है. हालांकि, यह विकल्प सिर्फ़ उस डेटा को मिटाता है जो काम का नहीं है.

9.13. सेफ़ बूट मोड

Android में सेफ़ बूट मोड की सुविधा होती है. इसकी मदद से, उपयोगकर्ता अपने डिवाइस को ऐसे मोड में बूट कर सकते हैं जिसमें सिर्फ़ पहले से इंस्टॉल किए गए सिस्टम ऐप्लिकेशन चल सकते हैं. साथ ही, तीसरे पक्ष के सभी ऐप्लिकेशन बंद हो जाते हैं. इस मोड को "सेफ़ बूट मोड" कहा जाता है. इससे, उपयोगकर्ता को तीसरे पक्ष के ऐसे ऐप्लिकेशन अनइंस्टॉल करने की सुविधा मिलती है जो नुकसान पहुंचा सकते हैं.

डिवाइस पर लागू करने के तरीके:

• [SR] हमारा सुझाव है कि आप सुरक्षित बूट मोड लागू करें.

अगर डिवाइस में सुरक्षित बूट मोड लागू किया जाता है, तो:

• [C-1-1] डिवाइस पर इंस्टॉल किए गए तीसरे पक्ष के ऐप्लिकेशन, सेफ़ बूट मोड में जाने की प्रक्रिया को बीच में न रोक सकें. हालांकि, अगर तीसरे पक्ष का ऐप्लिकेशन, डिवाइस नीति कंट्रोल करने वाला ऐप्लिकेशन है और उसने UserManager.DISALLOW_SAFE_BOOT फ़्लैग को 'सही' के तौर पर सेट किया है, तो यह शर्त लागू नहीं होगी.

• [C-1-2] उपयोगकर्ता को सुरक्षित मोड में, तीसरे पक्ष के किसी भी ऐप्लिकेशन को अनइंस्टॉल करने की सुविधा देनी चाहिए.

• उपयोगकर्ता को, बूट मेन्यू से सुरक्षित मोड में जाने का विकल्प देना चाहिए. इसके लिए, सामान्य बूट से अलग वर्कफ़्लो का इस्तेमाल किया जाना चाहिए.

9.14. वाहन के सिस्टम को आइसोलेट करना

Android Automotive डिवाइसों को वाहन के एचएएल का इस्तेमाल करके, वाहन के अहम सबसिस्टम के साथ डेटा शेयर करना चाहिए. इससे, CAN बस जैसे वाहन नेटवर्क पर मैसेज भेजने और पाने में मदद मिलती है.

Android फ़्रेमवर्क लेयर के नीचे सुरक्षा सुविधाएं लागू करके, डेटा एक्सचेंज को सुरक्षित किया जा सकता है. इससे, इन सबसिस्टम के साथ नुकसान पहुंचाने वाले या अनजाने में होने वाले इंटरैक्शन को रोका जा सकता है.

9.15. सदस्यता प्लान

"सदस्यता प्लान" से, मोबाइल और इंटरनेट सेवा देने वाली कंपनी की ओर से SubscriptionManager.setSubscriptionPlans() के ज़रिए दिए गए बिलिंग रिलेशनशिप प्लान की जानकारी का पता चलता है.

सभी डिवाइसों पर लागू होने वाले टूल और फ़ॉर्मैट:

• [C-0-1] सदस्यता के प्लान, सिर्फ़ उस मोबाइल और इंटरनेट सेवा देने वाली कंपनी के ऐप्लिकेशन पर वापस किए जाने चाहिए जिसने उन्हें मूल रूप से उपलब्ध कराया है.
• [C-0-2] सदस्यता के प्लान का रिमोट तौर पर बैक अप नहीं लेना चाहिए या उन्हें अपलोड नहीं करना चाहिए.
• [C-0-3] सिर्फ़ उस मोबाइल कैरियर ऐप्लिकेशन से बदलाव करने की अनुमति होनी चाहिए जो फ़िलहाल मान्य सदस्यता प्लान उपलब्ध करा रहा है. जैसे, SubscriptionManager.setSubscriptionOverrideCongested().

10. सॉफ़्टवेयर की कंपैटबिलिटी टेस्टिंग

डिवाइस लागू करने के लिए, इस सेक्शन में बताए गए सभी टेस्ट पास करने ज़रूरी हैं. हालांकि, ध्यान रखें कि कोई भी सॉफ़्टवेयर टेस्ट पैकेज पूरी तरह से काम का नहीं होता. इस वजह से, डिवाइस में Android लागू करने वाले लोगों को हमारा सुझाव है कि वे Android Open Source Project से, Android के रेफ़रंस और पसंदीदा वर्शन में कम से कम बदलाव करें. इससे, गड़बड़ियों का जोखिम कम हो जाएगा. इन गड़बड़ियों की वजह से, डिवाइसों के साथ काम करने में समस्याएं आती हैं. इन गड़बड़ियों को ठीक करने के लिए, डिवाइसों को फिर से अपडेट करना पड़ता है.

10.1. Compatibility Test Suite

डिवाइस पर लागू करने के तरीके:

• [C-0-1] डिवाइस पर शिपिंग के लिए इस्तेमाल किए जाने वाले फ़ाइनल सॉफ़्टवेयर का इस्तेमाल करके, Android Open Source Project से उपलब्ध Android Compatibility Test Suite (CTS) को पास करना ज़रूरी है.

• [C-0-2] यह ज़रूरी है कि सीटीएस में किसी तरह की गड़बड़ी होने पर और रेफ़रंस सोर्स कोड के कुछ हिस्सों को फिर से लागू करने पर, कम्पैटबिलिटी की पुष्टि की जाए.

सीटीएस को किसी असली डिवाइस पर चलाने के लिए डिज़ाइन किया गया है. किसी भी सॉफ़्टवेयर की तरह, सीटीएस में भी गड़बड़ियां हो सकती हैं. CTS का वर्शन, इस 'काम करने की शर्तों' से अलग होगा. साथ ही, Android 10 के लिए CTS के कई रिविज़न रिलीज़ किए जा सकते हैं.

डिवाइस पर लागू करने के तरीके:

• [C-0-3] डिवाइस का सॉफ़्टवेयर पूरा होने के समय, CTS के सबसे नए वर्शन को पास करना ज़रूरी है.

• Android Open Source Tree में, रेफ़रंस के तौर पर लागू किए गए उदाहरण का ज़्यादा से ज़्यादा इस्तेमाल करना चाहिए.

10.2. सीटीएस की पुष्टि करने वाला टूल

CTS Verifier, Compatibility Test Suite में शामिल है. इसे कोई व्यक्ति चलाता है, ताकि उन सुविधाओं की जांच की जा सके जिनकी जांच ऑटोमेटेड सिस्टम से नहीं की जा सकती. जैसे, कैमरे और सेंसर की सही तरीके से काम करना.

डिवाइस पर लागू करने के तरीके:

• [C-0-1] सीटीएस की पुष्टि करने वाले टूल में, लागू होने वाले सभी केस सही तरीके से लागू होने चाहिए.

CTS Verifier में कई तरह के हार्डवेयर के लिए टेस्ट होते हैं. इनमें कुछ हार्डवेयर ऐसे भी होते हैं जो ज़रूरी नहीं होते.

डिवाइस पर लागू करने के तरीके:

• [C-0-2] डिवाइस में मौजूद सभी हार्डवेयर के लिए, सभी टेस्ट पास करने होंगे. उदाहरण के लिए, अगर किसी डिवाइस में ऐक्सेलेरोमीटर है, तो उसे CTS Verifier में ऐक्सेलेरोमीटर टेस्ट केस को सही तरीके से पूरा करना होगा.

कंपैटबिलिटी डेफ़िनिशन डॉक्यूमेंट में, जिन सुविधाओं को ज़रूरी नहीं बताया गया है उनके लिए टेस्ट केस को छोड़ा या हटाया जा सकता है.

• [C-0-2] ऊपर बताए गए तरीके से, हर डिवाइस और हर बिल्ड में CTS Verifier सही तरीके से काम करना चाहिए. हालांकि, कई बिल्ड काफ़ी मिलते-जुलते होते हैं. इसलिए, डिवाइस लागू करने वाले लोगों को उन बिल्ड पर सीटीएस की पुष्टि करने वाले टूल को साफ़ तौर पर चलाने की ज़रूरत नहीं है जो सिर्फ़ मामूली अंतरों में अलग होते हैं. खास तौर पर, डिवाइस के ऐसे वर्शन जो सिर्फ़ शामिल की गई स्थानीय भाषाओं, ब्रैंडिंग वगैरह के सेट की वजह से, CTS की पुष्टि करने वाले टूल से पास हुए वर्शन से अलग हैं, उन्हें CTS की पुष्टि करने वाले टूल से टेस्ट करने की ज़रूरत नहीं है.

11. अपडेट किया जा सकने वाला सॉफ़्टवेयर

• [C-0-1] डिवाइस को लागू करने के लिए, सिस्टम के पूरे सॉफ़्टवेयर को बदलने का तरीका ज़रूर होना चाहिए. इस प्रोसेस में, “लाइव” अपग्रेड करने की ज़रूरत नहीं होती. इसका मतलब है कि डिवाइस को रीस्टार्ट करना पड़ सकता है. किसी भी तरीके का इस्तेमाल किया जा सकता है. हालांकि, यह ज़रूरी है कि वह डिवाइस पर पहले से इंस्टॉल किए गए पूरे सॉफ़्टवेयर को बदल सके. उदाहरण के लिए, इनमें से कोई भी तरीका अपनाने पर, यह ज़रूरी शर्त पूरी हो जाएगी:

  • रीबूट करके ऑफ़लाइन अपडेट के साथ “ओवर-द-एयर (ओटीए)” डाउनलोड.
  • होस्ट पीसी से यूएसबी के ज़रिए “टैथर्ड” अपडेट.
  • रीबूट करने पर “ऑफ़लाइन” अपडेट और हटाने लायक स्टोरेज में मौजूद फ़ाइल से अपडेट.

• [C-0-2] अपडेट करने के लिए इस्तेमाल किए गए तरीके से, उपयोगकर्ता का डेटा मिटाए बिना अपडेट किए जाने चाहिए. इसका मतलब है कि अपडेट करने के तरीके से, ऐप्लिकेशन का निजी डेटा और ऐप्लिकेशन का शेयर किया गया डेटा सुरक्षित रहना चाहिए. ध्यान दें कि Android सॉफ़्टवेयर में अपडेट करने का एक तरीका शामिल है, जो इस ज़रूरी शर्त को पूरा करता है.

• [C-0-3] पूरे अपडेट पर हस्ताक्षर होना चाहिए. साथ ही, डिवाइस पर अपडेट करने की सुविधा, अपडेट और हस्ताक्षर की पुष्टि डिवाइस पर सेव किए गए सार्वजनिक पासकोड से करनी चाहिए.

• [C-SR] हमारा सुझाव है कि साइन करने के तरीके का इस्तेमाल करके, अपडेट को SHA-256 से हैश करें. साथ ही, ECDSA NIST P-256 का इस्तेमाल करके, हैश की पुष्टि सार्वजनिक कुंजी से करें.

अगर डिवाइस में 802.11 या ब्लूटूथ पीएएन (पर्सनल एरिया नेटवर्क) प्रोफ़ाइल जैसे बिना मीटर वाले डेटा कनेक्शन के लिए सहायता शामिल है, तो:

• [C-1-1] डिवाइस को रीबूट करके, ऑफ़लाइन अपडेट के साथ ओटीए डाउनलोड की सुविधा होनी चाहिए.

Android 6.0 और उसके बाद के वर्शन के साथ लॉन्च होने वाले डिवाइसों के लिए, अपडेट करने की सुविधा से यह पुष्टि होनी चाहिए कि सिस्टम इमेज, ओटीए के बाद मिलने वाले नतीजे से मेल खाती है. Android 5.1 के बाद से, अपस्ट्रीम Android Open Source Project में ब्लॉक के आधार पर ओटीए लागू करने की सुविधा जोड़ी गई है. यह सुविधा इस ज़रूरी शर्त को पूरा करती है.

साथ ही, डिवाइस पर A/B सिस्टम अपडेट की सुविधा काम करनी चाहिए. AOSP, बूट कंट्रोल एचएएल का इस्तेमाल करके इस सुविधा को लागू करता है.

अगर डिवाइस रिलीज़ होने के बाद, उसे लागू करने में कोई गड़बड़ी मिलती है, लेकिन वह डिवाइस के तय लाइफ़टाइम के अंदर है, तो तीसरे पक्ष के ऐप्लिकेशन के साथ काम करने की सुविधा पर असर पड़ सकता है. इस लाइफ़टाइम का पता लगाने के लिए, Android के साथ काम करने की सुविधा देने वाली टीम से सलाह ली जाती है. ऐसे में:

• [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. बदलावों का लॉग देखने के बारे में सलाह

बदलावों को इस तरह मार्क किया जाता है:

• सीडीडी
  साथ काम करने से जुड़ी ज़रूरी शर्तों में बड़े बदलाव.

• Docs
  कॉस्मेटिक या बिल्ड से जुड़े बदलाव.

बेहतर तरीके से देखने के लिए, अपने बदलावों की जानकारी वाले यूआरएल में pretty=full और no-merges यूआरएल पैरामीटर जोड़ें.

13. हमसे संपर्क करें

Android के साथ काम करने वाले डिवाइसों के बारे में जानकारी देने वाले फ़ोरम में शामिल होकर, इस बारे में ज़्यादा जानकारी मांगी जा सकती है. इसके अलावा, अगर आपको लगता है कि दस्तावेज़ में किसी समस्या के बारे में नहीं बताया गया है, तो उसके बारे में भी बताया जा सकता है.