Android 10 के साथ काम करने की परिभाषा

1. परिचय

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

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

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

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

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

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

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

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

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

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

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

1.1.2. ज़रूरत आईडी

ज़रूरी आईडी असाइन किया गया है.

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

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

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

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

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

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

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

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

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

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

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

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

2.2. हैंडहेल्ड की ज़रूरतें

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

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

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

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

2.2.1. हार्डवेयर

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [7.3.11/H-SR] का सुझाव दिया जाता है कि 6 डिग्री ऑफ़ फ़्रीडम वाले पोज़ सेंसर के साथ काम करें.
• [7.4.3/H] इसमें Bluetooth और Bluetooth LE के साथ काम करने की सुविधा शामिल होनी चाहिए.

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

• [7.4.7/H-1-1] डेटा बचाने की सेटिंग वाला मोड उपलब्ध कराना ज़रूरी है.

अगर हैंडहेल्ड डिवाइस लागू करने के लिए एक लॉजिकल कैमरा डिवाइस शामिल है, जिसमें CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA का इस्तेमाल करके सुविधाएं दी गई हैं, तो ये:

• [7.5.4/H-1-1] डिफ़ॉल्ट रूप से, फ़ील्ड ऑफ़ व्यू (FOV) सामान्य होना चाहिए और यह 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] अगर डिफ़ॉल्ट डिसप्ले, HD+ (जैसे कि HD, WSVGA) तक के फ़्रेमबफ़र रिज़ॉल्यूशन का इस्तेमाल करता है, तो कर्नेल और यूज़रस्पेस में उपलब्ध मेमोरी कम से कम 592 एमबी होनी चाहिए.

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

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

अगर हैंडहेल्ड डिवाइस पर लागू होने वाले किसी भी 64-बिट एबीआई के साथ काम करने की घोषणा की जाती है (32-बिट एबीआई के साथ या उसके बिना):

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

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

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

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

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

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

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

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

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

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

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

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

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

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

फ़ंक्शन	मैपिंग	संदर्भ	व्यवहार
A	एचआईडी के इस्तेमाल की जानकारी देने वाला पेज: 0x0C एचआईडी का इस्तेमाल: 0x0CD Kernel key: KEY_PLAYPAUSE Android कुंजी: KEYCODE_MEDIA_PLAY_PAUSE	मीडिया प्लेबैक	इनपुट: थोड़ी देर दबाएं आउटपुट: चलाएं या रोकें
			इनपुट: दबाकर रखें आउटपुट: बोलकर निर्देश देने की सुविधा लॉन्च करें भेजता है: अगर डिवाइस लॉक है या उसकी स्क्रीन बंद है, तो android.speech.action.VOICE_SEARCH_HANDS_FREE. अगर android.speech.RecognizerIntent.ACTION_WEB_SEARCH को नहीं भेजा जाता है
		आने वाला (इनकमिंग) कॉल	इनपुट: थोड़ी देर दबाएं आउटपुट: कॉल स्वीकार करें
			इनपुट: दबाकर रखें आउटपुट: कॉल काट दें
		पहले से जारी कॉल	इनपुट: थोड़ी देर दबाएं आउटपुट: कॉल खत्म करें
			इनपुट: दबाकर रखें आउटपुट: माइक्रोफ़ोन म्यूट या अनम्यूट करें
B	एचआईडी के इस्तेमाल की जानकारी देने वाला पेज: 0x0C एचआईडी का इस्तेमाल: 0x0E9 Kernel key: KEY_VOLUMEUP Android कुंजी: VOLUME_UP	मीडिया प्लेबैक, जारी कॉल	इनपुट: छोटा करना या दबाकर रखना आउटपुट: सिस्टम या हेडसेट की आवाज़ बढ़ाता है
C	एचआईडी के इस्तेमाल की जानकारी देने वाला पेज: 0x0C एचआईडी का इस्तेमाल: 0x0EA Kernel key: KEY_VOLUMEDOWN Android कुंजी: VOLUME_DOWN	मीडिया प्लेबैक, जारी कॉल	इनपुट: छोटा करना या दबाकर रखना आउटपुट: सिस्टम या हेडसेट की आवाज़ कम करता है
D	एचआईडी के इस्तेमाल की जानकारी देने वाला पेज: 0x0C एचआईडी का इस्तेमाल: 0x0CF Kernel key: KEY_VOICECOMMAND Android कुंजी: KEYCODE_VOICE_ASSIST	सभी थ्रेड के लिए. किसी भी स्थिति में ट्रिगर किया जा सकता है.	इनपुट: छोटा करना या दबाकर रखना आउटपुट: बोलकर निर्देश देने की सुविधा लॉन्च करें

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [5.1/H-0-1] एएमआर-एनबी
• [5.1/H-0-2] एएमआर-डब्ल्यूबी
• [5.1/H-0-3] MPEG-4 एएसी प्रोफ़ाइल (AAC LC)
• [5.1/H-0-4] MPEG-4 HE AAC प्रोफ़ाइल (AAC+)
• [5.1/H-0-5] AAC ELD (कम देरी वाले AAC)

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

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

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

• [5.3/H-0-1] H.264 एवीसी
• [5.3/H-0-2] H.265 एचईवीसी
• [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] ऐसा डिफ़ॉल्ट लॉन्चर लागू करने का सुझाव दिया जाता है जिसमें शॉर्टकट, विजेट, और विजेट की सुविधाओं को ऐप्लिकेशन में पिन करने की सुविधा काम करती है.
• [3.8.1/H-SR] डिफ़ॉल्ट लॉन्चर लागू करने का सुझाव दिया जाता है. यह लॉन्चर, ShortcutManager एपीआई के ज़रिए तीसरे पक्ष के ऐप्लिकेशन से मिलने वाले दूसरे शॉर्टकट का क्विक ऐक्सेस देता है.
• [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] एक नोटिफ़िकेशन शेड शामिल करना ज़रूरी है, जिससे उपयोगकर्ता को उपयोगकर्ता की सुविधा के ज़रिए, सूचनाओं को सीधे तौर पर कंट्रोल करने (उदाहरण के लिए, जवाब देने, स्नूज़ करने, खारिज करने, ब्लॉक करने) करने की सुविधा मिले. जैसे, ऐक्शन बटन या एओएसपी में लागू किए गए कंट्रोल पैनल.
• [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 को true इन-लाइन के तौर पर सेट किया गया है. साथ ही, Notification.Remoteinput.Builder.setChoices से मिलने वाले जवाबों को भी true में सेट किया गया है.
• [3.8.4/H-SR] सहायक कार्रवाई को मैनेज करने के लिए, डिवाइस पर Assistant को लागू करने का सुझाव दिया जाता है.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [6.1/H-0-1]* शेल कमांड cmd testharness के साथ काम करना ज़रूरी है.

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

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

2.3. टेलीविज़न की आवश्यकताएं

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

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

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

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

2.3.1. हार्डवेयर

टेलीविज़न डिवाइस पर यह सुविधा लागू करना:

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

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

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

टेलीविज़न डिवाइस पर यह सुविधा लागू करना:

• [7.4.3/T-0-1] ब्लूटूथ और ब्लूटूथ 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 LC)
• [5.1/T-0-2] MPEG-4 HE AAC प्रोफ़ाइल (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] खास तौर पर सुझाव दिया जाता है कि 30 फ़्रेम प्रति सेकंड पर 720p और 1080p रिज़ॉल्यूशन वाले वीडियो की H.264 एन्कोडिंग पर काम किया जा सके.

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

• [5.3.3/T-0-1] MPEG-4 एसपी
• [5.3.4/T-0-2] H.264 एवीसी
• [5.3.5/T-0-3] H.265 एचईवीसी
• [5.3.6/T-0-4] VP8
• [5.3.7/T-0-5] VP9
• [5.3.1/T-0-6] MPEG-2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [5.8/T-2-1] एचडीसीपी 1.4 वर्शन के साथ काम करना ज़रूरी है

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

टेलीविज़न डिवाइस पर यह सुविधा लागू करना:

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

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

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

टेलीविज़न डिवाइस पर यह सुविधा लागू करना:

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

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

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

टेलीविज़न डिवाइस पर यह सुविधा लागू करना:

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

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 एमबी/सेकंड का रैंडम रीड परफ़ॉर्मेंस मिले.

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

• [8.3/T-1-1] बैटरी सेवर की सुविधा को चालू और बंद करने के लिए, लोगों को ज़रूरी अधिकार देना ज़रूरी है.

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

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

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

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

टेलीविज़न डिवाइस पर यह सुविधा लागू करना:

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

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

टेलीविज़न डिवाइस पर यह सुविधा लागू करना:

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

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

टेलीविज़न डिवाइस पर यह सुविधा लागू करना:

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

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] उपयोगकर्ता के लिए Home फ़ंक्शन और वापस जाएं वाले फ़ंक्शन का इस्तेमाल करना ज़रूरी है. ऐसा सिर्फ़ तब होना चाहिए, जब वह UI_MODE_TYPE_WATCH में हो.

• [7.2.4/W-0-1] टचस्क्रीन इनपुट पर काम करना ज़रूरी है.

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

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

• [7.3.3/W-1-1] जीएनएसएस मेज़रमेंट के मिलते ही, उन्हें रिपोर्ट करना ज़रूरी है. भले ही, जीपीएस/जीएनएसएस का इस्तेमाल करके कैलकुलेट की गई जगह की जानकारी अभी तक रिपोर्ट न की गई हो.
• [7.3.3/W-1-2] आपको जीएनएसएस स्यूडोरेंज और स्यूडोरेंज रेट की रिपोर्ट देनी होगी. जगह तय करने के बाद खुले आसमान की स्थितियों में, स्थिर या 0.2 मीटर प्रति सेकंड वर्ग की रफ़्तार के साथ मूवमेंट के लिए, 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_देखें के साथ काम करना ज़रूरी है.

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

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

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

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

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

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

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

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

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

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

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

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

2.5. वाहन संबंधित ज़रूरतें

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

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

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

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

2.5.1. हार्डवेयर

वाहन संबंधित डिवाइस पर विज्ञापन लागू करना:

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

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

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

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

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

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

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

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

वाहन संबंधित डिवाइस पर विज्ञापन लागू करना:

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

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

• [7.5/A-1-1] बाहरी कैमरा इस्तेमाल करने की अनुमति नहीं है, जब तक कि वे कैमरे की मुख्य शर्तों का पालन न करते हों. इन कैमरों को Android Camera APIs से ऐक्सेस किया जा सकता है.
• [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 फ़ाइल सिस्टम का इस्तेमाल करना.

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

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

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

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

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

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

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

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

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

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

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

अगर Automotive डिवाइस में 64-बिट लागू होते हैं:

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

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

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

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

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

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

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

  • छोटी/सामान्य स्क्रीन पर 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 LC)
• [5.1/A-0-2] MPEG-4 HE AAC प्रोफ़ाइल (AAC+)
• [5.1/A-0-3] AAC ELD (कम देरी वाले AAC)

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

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

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

• [5.3/A-0-1] H.264 एवीसी
• [5.3/A-0-2] MPEG-4 SP
• [5.3/A-0-3] VP8
• [5.3/A-0-4] VP9

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

• [5.3/A-SR] H.265 एचईवीसी

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

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

• [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_INTENT_ACTION_MEDIA_TEMPLATE इंप्लिसिट इंटेंट ऐक्शन के साथ CAR_EXTRA_MEDIA_PACKAGE का इस्तेमाल किया जा सके.
• [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] हर प्रोसेस के यूआईडी के हिसाब से, डेटा को नॉन-वोलेटाइल स्टोरेज में पढ़े गए और लिखे गए बाइट की संख्या बताना ज़रूरी है. इससे डेवलपर को सिस्टम एपीआई 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 ओपन सोर्स प्रोजेक्ट की साइट पर मौजूद जानकारी के मुताबिक, समय के साथ कॉम्पोनेंट की वजह से बैटरी के तेज़ी से खर्च होने की अनुमानित जानकारी भी देती है.
• [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 कीस्टोर सिस्टम के साथ काम करने वाले एल्गोरिदम के लिए सही तरीके से काम कर सके. यह सुविधा, कर्नेल और ऊपर वाले कोड पर चल रहे कोड से सुरक्षित तरीके से अलग की जा सकती है. सिक्योर आइसोलेशन से उन सभी संभावित मैकेनिज़्म को ब्लॉक कर देना चाहिए जिनकी मदद से कर्नेल या यूज़रस्पेस कोड, डीएमए के साथ-साथ आइसोलेटेड एनवायरमेंट की अंदरूनी स्थिति को ऐक्सेस कर सकते हैं. अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट (एओएसपी), Trusty लागू करने की सुविधा का इस्तेमाल करके इस ज़रूरी शर्त को पूरा करता है. हालांकि, ARM TrustZone पर आधारित कोई दूसरा समाधान या किसी तीसरे पक्ष के समीक्षा किए गए सुरक्षित तरीके से हाइपरवाइज़र पर आधारित आइसोलेशन के विकल्प उपलब्ध हैं.
• [9.11/A-0-3] लॉक स्क्रीन की पुष्टि करने के लिए, अलग-अलग डिवाइसों पर काम करना ज़रूरी है. साथ ही, पुष्टि करने की प्रक्रिया के पूरा होने पर ही, पुष्टि करने वाली कुंजियों का इस्तेमाल करने की अनुमति दें. लॉक स्क्रीन के क्रेडेंशियल को इस तरह से सेव किया जाना चाहिए कि लॉक स्क्रीन की पुष्टि करने के लिए, सिर्फ़ एक सुरक्षित एनवायरमेंट को अनुमति मिले. अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट, गेटकीपर हार्डवेयर ऐब्स्ट्रैक्शन लेयर (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. डेवलपर टूल और विकल्पों के साथ काम करने की सुविधा

वाहन संबंधित डिवाइस पर विज्ञापन लागू करना:

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

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)

यदि टेबलेट उपकरण कार्यान्वयन में सहायक उपकरण मोड का समर्थन करने वाला USB पोर्ट शामिल है, तो वे:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

डिवाइस पर यह सुविधा लागू करना:

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

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

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

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

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

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

  हालांकि, वे:

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

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

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

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

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

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

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

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

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

3.2. सॉफ़्ट एपीआई के साथ काम करने की सुविधा

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

3.2.1. अनुमतियां

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

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

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

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

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

3.2.3. इंटेंट के साथ काम करना

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

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

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

  • डेस्क क्लॉक
  • ब्राउज़र
  • Calendar
  • संपर्क
  • गैलरी में देखें
  • वैश्विक खोज
  • लॉन्चर
  • संगीत
  • सेटिंग

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 में ACTION, CATEGORY या अन्य मुख्य स्ट्रिंग का इस्तेमाल करके किसी भी नए इंटेंट या ब्रॉडकास्ट इंटेंट पैटर्न के मुताबिक काम करता हो. या com.android. नेमस्पेस.
• [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.createRequestRoleIntent(String) इंटेंट को RoleManager.ROLE_SMS के साथ कॉल करेगा. इससे डिफ़ॉल्ट एसएमएस ऐप्लिकेशन को बदलने के लिए एक डायलॉग दिखाया जाएगा.

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

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

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

• [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.एनएफ़सी_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 ओपन सोर्स प्रोजेक्ट से नीचे दी गई लाइब्रेरी के लागू करने के तरीके का खास तौर पर सुझाव दिया जाता है.

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

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

डिवाइस पर यह सुविधा लागू करना:

• [C-0-1] एक या उससे ज़्यादा तय एबीआई के साथ काम करना ज़रूरी है. साथ ही, यह Android एनडीके (NDK) के साथ काम करना चाहिए.
• [C-0-2] स्टैंडर्ड Java नेटिव इंटरफ़ेस (जेएनआई) सिमेंटिक्स का इस्तेमाल करके, नेटिव कोड में कॉल करने के लिए, मैनेज किए जा रहे एनवायरमेंट में कोड के साथ काम करना ज़रूरी है.
• [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 (ऑडियो नेटिव ऑडियो सहायता)

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

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

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

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

3.3.2. 32-बिट ARM नेटिव कोड के साथ काम करता है

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

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

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

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

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

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

  • SWP और SWPB के लिए निर्देश.
  • निर्देश सेट करें.
  • 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)]; wv) AppleWebKit/537.36 (KHTML, जैसे Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36

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

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

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

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

3.4.2. इन ब्राउज़र पर काम करता है

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

• [C-1-1] HTML5 से जुड़े इन एपीआई के साथ काम करना चाहिए:
  • ऐप्लिकेशन की कैश मेमोरी/ऑफ़लाइन कार्रवाई
  • <वीडियो> टैग
  • जियोलोकेशन
• [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 ओपन सोर्स प्रोजेक्ट को लागू करने के पसंदीदा तरीके से मेल खाना चाहिए. साथ काम करने से जुड़ी कुछ खास बातें यहां दी गई हैं:

• [C-0-1] डिवाइस को किसी स्टैंडर्ड इंटेंट के व्यवहार या सिमेंटिक्स में बदलाव नहीं करना चाहिए.
• [C-0-2] डिवाइसों को किसी खास तरह के सिस्टम कॉम्पोनेंट (जैसे कि सेवा, Activity, 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] जब तक ऐप्लिकेशन insertProviderAt() या removeProvider() के ज़रिए सूची में बदलाव न कर दे, तब तक डिवाइसों को Security.getProviders() तरीके से, पहले सात अरे वैल्यू के तौर पर, दिए गए क्रम और दिए गए नामों (जो Provider.getName() के ज़रिए दिया गया है) और क्लास के साथ इन कंपनियों को लौटाना होगा. ये वैल्यू, Provider.getName() के ज़रिए दी जाती हैं. इन कंपनियों की नीचे दी गई सूची के बाद, डिवाइस और कंपनियां भी दिखा सकती हैं.
  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

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

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

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

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

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

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

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

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

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

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

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

डिवाइस पर यह सुविधा लागू करना:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [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] इसमें AppWidgets के लिए पहले से काम करने की सुविधा होनी चाहिए. साथ ही, ऐप्लिकेशन को सीधे लॉन्चर में जोड़ने, कॉन्फ़िगर करने, देखने, और हटाने के लिए यूज़र इंटरफ़ेस की सुविधाओं की जानकारी देनी ज़रूरी है.
• [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 ओपन सोर्स को लागू करने के तरीके से अलग उपयोगकर्ता अनुभव दे सकते हैं.
• [C-1-3] सूचनाओं को अपडेट करने, हटाने, और ग्रुप करने के लिए, एपीआई के लिए बताए गए व्यवहार का पालन करना ज़रूरी है और उसे सही तरीके से लागू करना चाहिए.
• [C-1-4] SDK टूल में मौजूद NotificationChannel एपीआई की पूरी जानकारी देनी ज़रूरी है.
• [C-1-5] लोगों के लिए, हर चैनल और ऐप्लिकेशन पैकेज लेवल के हिसाब से, तीसरे पक्ष के किसी ऐप्लिकेशन की सूचना को ब्लॉक करने और उसमें बदलाव करने का विकल्प देना ज़रूरी है.
• [C-1-6] उपयोगकर्ता को, मिटाए गए सूचना चैनल दिखाने की अनुमति भी देनी होगी.
• [C-1-7] Notification.MessagingStyle के ज़रिए दिए गए सभी संसाधनों (इमेज, स्टिकर, आइकॉन वगैरह) को सूचना टेक्स्ट के साथ सही तरीके से रेंडर करना ज़रूरी है.इसके लिए उपयोगकर्ता से कोई अतिरिक्त इंटरैक्शन नहीं करना होगा. उदाहरण के लिए, सभी संसाधन दिखाए जाने चाहिए. इनमें setGroup Conversation के ज़रिए सेट की गई ग्रुप बातचीत में, android.app.Person के ज़रिए दिए गए आइकॉन भी शामिल हैं.
• [सी-एसआर] इस बात की काफ़ी सलाह दी जाती है कि उपयोगकर्ता के बार-बार खारिज करने के बाद, वह हर चैनल और ऐप्लिकेशन पैकेज के लेवल पर, किसी तीसरे पक्ष के ऐप्लिकेशन की सूचना को ब्लॉक करने का विकल्प, अपने-आप दिखा सके.
• इसमें रिच नोटिफ़िकेशन की सुविधा भी होनी चाहिए.
• कुछ उच्च प्राथमिकता वाले नोटिफ़िकेशन को हेड-अप नोटिफ़िकेशन के रूप में दिखाया जाना चाहिए.
• उपयोगकर्ता के पास, सूचनाएं स्नूज़ करने की सुविधा होनी चाहिए.
• ड्राइवर का ध्यान भटकने जैसी सुरक्षा से जुड़ी समस्याओं को कम करने के लिए, सिर्फ़ तीसरे पक्ष के ऐप्लिकेशन से लोगों को अहम इवेंट की सूचना दी जा सकती है. इस सूचना के दिखने का समय और समय को ही मैनेज किया जा सकता है.

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

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

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

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

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

3.8.4. खोजें

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

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

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

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

अगर वैश्विक खोज का उपयोग करने वाला कोई तृतीय-पक्ष ऐप्लिकेशन इंस्टॉल नहीं है, तो:

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

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

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

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

3.8.5. अलर्ट और टोस्ट

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

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

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

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

3.8.6. थीम

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

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

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

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

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_wallP.

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

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

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

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

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

3.8.9. इनपुट प्रबंधन

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• [C-1-1] डिवाइस के छोटे किनारों पर सिर्फ़ कटआउट होना चाहिए. इसके उलट, अगर डिवाइस की आसपेक्ट रेशियो(लंबाई-चौड़ाई का अनुपात) 1.0(1:1) है, तो उनमें कटआउट नहीं होने चाहिए.
• [C-1-2] हर किनारे के लिए एक से ज़्यादा कटआउट नहीं होने चाहिए.
• [C-1-3] SDK टूल में बताए गए तरीके के मुताबिक, 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 वाला एक रिकॉर्ड वाला एनएफ़सी मैसेज मिलता है, तो उसे DPC ऐप्लिकेशन को डिवाइस के मालिक के ऐप्लिकेशन के रूप में रजिस्टर करना होगा.
  • जब डिवाइस इंप्लिमेंटेशन में उपयोगकर्ता का डेटा होता है, तो यह:
    • [C-1-6] DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE) के लिए, false को रिपोर्ट करना ज़रूरी है.
    • [C-1-7] अब किसी भी DPC ऐप्लिकेशन को डिवाइस के मालिक के ऐप्लिकेशन के तौर पर रजिस्टर नहीं करना होगा.
• [C-1-2] प्रावधान की प्रोसेस के दौरान, ऐप्लिकेशन को डिवाइस के मालिक के तौर पर सेट करने की सहमति देने के लिए, कुछ ज़रूरी कार्रवाई करना ज़रूरी है. प्रावधान करने के दौरान, उपयोगकर्ता की कार्रवाई या प्रोग्राम के हिसाब से अपने-आप होने वाली प्रोसेस के ज़रिए सहमति दी जा सकती है. हालांकि, इसे हार्ड कोड नहीं करना चाहिए और न ही डिवाइस के मालिक वाले अन्य ऐप्लिकेशन के इस्तेमाल से बचना चाहिए.

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

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

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

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

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

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

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

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

3.9.2 मैनेज की जा रही प्रोफ़ाइल के लिए सहायता

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

• [C-1-1] android.app.admin.DevicePolicyManager API का इस्तेमाल करके, मैनेज की जा रही प्रोफ़ाइल के साथ काम करना ज़रूरी है.
• [C-1-2] सिर्फ़ एक या सिर्फ़ मैनेज की जा रही एक प्रोफ़ाइल बनाने की अनुमति होनी चाहिए.
• [C-1-3] मैनेज किए जा रहे ऐप्लिकेशन और विजेट और हाल ही के और सूचनाएं.
• [C-1-4] उपयोगकर्ता को यह बताने के लिए एक सूचना आइकॉन (एओएसपी अपस्ट्रीम वर्क बैज की तरह) दिखाना ज़रूरी है कि वह मैनेज किए जा रहे प्रोफ़ाइल ऐप्लिकेशन का इस्तेमाल कब करता है.
• [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 ओपन सोर्स प्रोजेक्ट साइट पर बताया गया है.
  • डीपीसी की पासवर्ड से जुड़ी नीतियां, सिर्फ़ मैनेज की जा रही प्रोफ़ाइल की लॉक स्क्रीन पर दिखने वाले क्रेडेंशियल पर लागू होनी चाहिए. ऐसा तब तक होना चाहिए, जब तक getParentProfile हटाएँ की मदद से दिए गए DevicePolicyManager इंस्टेंस का इस्तेमाल न किया जाए.
• मैनेज की जा रही प्रोफ़ाइल के संपर्क, पहले से इंस्टॉल किए गए कॉल लॉग, कॉल के दौरान यूज़र इंटरफ़ेस (यूआई), जारी या मिस्ड कॉल की सूचनाओं, संपर्क, और मैसेजिंग ऐप्लिकेशन में दिखने पर, उन्हें उसी बैज के साथ बैज किया जाना चाहिए जो मैनेज किए जा रहे प्रोफ़ाइल ऐप्लिकेशन के लिए इस्तेमाल होता है.

3.9.3 प्रबंधित उपयोगकर्ता सहायता

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

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

3.10. सुलभता

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

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

• [C-1-1] सुलभता एपीआई 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 टीटीएस फ़्रेमवर्क एपीआई के साथ काम करना ज़रूरी है.

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

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

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

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

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

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

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

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

डिवाइस पर यह सुविधा लागू करना:

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

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

डिवाइस पर यह सुविधा लागू करना:

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

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

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

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

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

ज़्यादा जानकारी 5.1.3. ऑडियो कोडेक से जुड़ी जानकारी.

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

• [C-1-1] पीसीएम/वेव
• [C-1-2] एफ़एलएसी
• [C-1-3] ओपस

सभी ऑडियो एन्कोडर को इनके साथ काम करना चाहिए:

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

5.1.2. ऑडियो डिकोडिंग

ज़्यादा जानकारी 5.1.3. ऑडियो कोडेक से जुड़ी जानकारी.

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

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

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

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

यूएसएसी ऑडियो को डिकोड करते समय, 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 प्रोफ़ाइल डिकोडर:

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

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

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

सभी ऑडियो डिकोडर को आउटपुट वाली सुविधा का इस्तेमाल करना चाहिए:

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

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

फ़ॉर्मैट/कोडेक	जानकारी	फ़ाइल टाइप/कंटेनर फ़ॉर्मैट का इस्तेमाल करना
MPEG-4 एएसी प्रोफ़ाइल (AAC एलसी)	8 से 48 किलोहर्ट्ज़ के बीच, मोनो/स्टीरियो/5.0/5.1 कॉन्टेंट के लिए, सैंपलिंग की मानक दरें लागू होती हैं.	3GPP (.3gp) MPEG-4 (.mp4, .m4a) ADTS रॉ AAC (.aac, ADIF काम नहीं करता) MPEG-TS (.ts, सीकेबल नहीं, सिर्फ़ डिकोड) Matroska (.mkv, सिर्फ़ डिकोड करना)
MPEG-4 HE AAC प्रोफ़ाइल (AAC+)	16 से 48 किलोहर्ट्ज़ के बीच स्टैंडर्ड सैंपलिंग रेट वाले मोनो/स्टीरियो/5.0/5.1 कॉन्टेंट के लिए सहायता.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
MPEG-4 HE AACv2 प्रोफ़ाइल (बेहतर AAC+)	16 से 48 किलोहर्ट्ज़ के बीच स्टैंडर्ड सैंपलिंग रेट वाले मोनो/स्टीरियो/5.0/5.1 कॉन्टेंट के लिए सहायता.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
AAC ELD (बेहतर कम देरी AAC)	16 से 48 किलोहर्ट्ज़ के बीच स्टैंडर्ड सैंपलिंग रेट वाले मोनो/स्टीरियो कॉन्टेंट के लिए सहायता.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
यूएसएसी	मोनो/स्टीरियो कॉन्टेंट के लिए, स्टैंडर्ड सैंपलिंग रेट 7.35 से 48 किलोहर्ट्ज़ के बीच होता है.	MPEG-4 (.mp4, .m4a)
एएमआर-एनबी	4.75 से 12.2 केबीपीएस का सैंपल @ 8 किलोहर्ट्ज़ (kHz)	3GPP (.3gp)
एएमआर-डब्ल्यूबी	एएमआर-डब्ल्यूबी, अडैप्टिव मल्टी-रेट - वाइडबैंड स्पीच कोडेक के मुताबिक 6.60 kbit/s से 23.85 kbit/s के सैंपल @ 16 kHz के लिए, 9 दरें तय की गई हैं	3GPP (.3gp)
FLAC	एन्कोडर और डिकोडर, दोनों के लिए: कम से कम मोनो और स्टीरियो मोड काम करना चाहिए. 192 किलोहर्ट्ज़ तक के सैंपल रेट का इस्तेमाल किया जाना ज़रूरी है; 16-बिट और 24-बिट रिज़ॉल्यूशन के साथ काम करना ज़रूरी है. FLAC 24-बिट ऑडियो डेटा हैंडलिंग, फ़्लोटिंग पॉइंट ऑडियो कॉन्फ़िगरेशन के साथ उपलब्ध होनी चाहिए.	FLAC (.flac) MPEG-4 (.mp4, .m4a, सिर्फ़ डिकोड) Matroska (.mkv, सिर्फ़ डिकोड करना)
MP3	मोनो/स्टीरियो 8-320 केबीपीएस कॉन्स्टेंट (सीबीआर) या वैरिएबल बिटरेट (वीबीआर)	एमपी3 (.mp3) MPEG-4 (.mp4, .m4a, सिर्फ़ डिकोड) Matroska (.mkv, सिर्फ़ डिकोड करना)
MIDI	एमआईडीआई टाइप 0 और 1. DLS वर्शन 1 और 2. XMF और Mobile XMF. RTTTL/RTX, OTA, और iMelody फ़ॉर्मैट के साथ रिंगटोन इस्तेमाल करने की सुविधा	टाइप 0 और 1 (.mid, .xmf, .mxmf) आरटीटीटीएल/आरटीएक्स (.rtttl, .rtx) ओटीए (.ota) iMelody (.imy)
वोर्बिस		ऑग (.ogg) MPEG-4 (.mp4, .m4a, सिर्फ़ डिकोड) मैट्रोस्का (.mkv) वेबम (.webm)
PCM/WAVE	PCM कोडेक को 16-बिट लीनियर PCM और 16-बिट फ़्लोट पर काम करना चाहिए. WAVE एक्सट्रैक्टर को 16-बिट, 24-बिट, 32-बिट लीनियर PCM और 32-बिट फ़्लोट (हार्डवेयर की सीमा तक की दर तक) का समर्थन करना चाहिए. सैंपलिंग रेट 8 किलोहर्ट्ज़ से 192 किलोहर्ट्ज़ तक काम करना ज़रूरी है.	WAVE (.wav)
Opus		ऑग (.ogg) MPEG-4 (.mp4, .m4a, सिर्फ़ डिकोड) मैट्रोस्का (.mkv) वेबम (.webm)

5.1.4. चित्र एन्कोडिंग

ज़्यादा जानकारी 5.1.6. इमेज कोडेक से जुड़ी जानकारी.

डिवाइस को लागू करने के लिए, नीचे दी गई इमेज को कोड में बदलने का तरीका काम करना चाहिए:

• [C-0-1] जेपीईजी
• [C-0-2] PNG
• [C-0-3] WebP

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

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

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

ज़्यादा जानकारी 5.1.6. इमेज कोडेक से जुड़ी जानकारी.

लागू करने के लिए डिवाइस को नीचे दिए गए इमेज एन्कोडिंग को डिकोड करना ज़रूरी है:

• [C-0-1] जेपीईजी
• [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. इमेज कोडेक की जानकारी

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

MediaCodec एपीआई की मदद से दिखाए गए इमेज एन्कोडर और डिकोडर

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

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

फ़ॉर्मैट/कोडेक	जानकारी	फ़ाइल टाइप/कंटेनर फ़ॉर्मैट का इस्तेमाल करना
एच.263		3GPP (.3gp) MPEG-4 (.mp4) Matroska (.mkv, सिर्फ़ डिकोड करना)
एच.264 एवीसी	ज़्यादा जानकारी के लिए, सेक्शन 5.2 और 5.3 देखें	3GPP (.3gp) MPEG-4 (.mp4) MPEG-2 टीएस (.ts, सीकेबल नहीं) Matroska (.mkv, सिर्फ़ डिकोड करना)
एच.265 एचईवीसी	जानकारी के लिए, सेक्शन 5.3 देखें	MPEG-4 (.mp4) Matroska (.mkv, सिर्फ़ डिकोड करना)
MPEG-2	मुख्य प्रोफ़ाइल	MPEG2-TS (.ts, सीकेबल नहीं) MPEG-4 (.mp4, सिर्फ़ डिकोड करना) Matroska (.mkv, सिर्फ़ डिकोड करना)
एमपीईजी-4 एसपी		3GPP (.3gp) MPEG-4 (.mp4) Matroska (.mkv, सिर्फ़ डिकोड करना)
वीपी8	ज़्यादा जानकारी के लिए, सेक्शन 5.2 और 5.3 देखें	WebM (.webm) मैट्रोस्का (.mkv)
वीपी9	जानकारी के लिए, सेक्शन 5.3 देखें	WebM (.webm) मैट्रोस्का (.mkv)

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

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

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

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

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

अगर लागू किए गए डिवाइस पर कोडेक 2.0 एपीआई काम नहीं करता, तो वे:

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

अगर लागू किए गए डिवाइस, कोडेक 2.0 API के साथ काम करते हैं, तो ये:

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

5.1.10. मीडिया कोडेक के लिए कैरेक्टर बनाना

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

• [C-1-1] MediaCodecInfo एपीआई की मदद से, मीडिया कोडेक की खासियत के तौर पर सही वैल्यू दिखाना ज़रूरी है.

खास तौर पर:

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

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

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

	एसडी (खराब क्वालिटी)	एसडी (अच्छी क्वालिटी)	एचडी 720 पिक्सल	एचडी 1080 पिक्सल	यूएचडी
वीडियो रिज़ॉल्यूशन	176 x 144 पिक्सल (H263, MPEG2, MPEG4) 352 x 288 पिक्सल (MPEG4 एन्कोडर, H263, MPEG2) 320 x 180 पिक्सल (VP8, VP8) 320 x 240 पिक्सल (अन्य)	704 x 576 पिक्सल (H263) 640 x 360 पिक्सल (VP8, VP9) 640 x 480 पिक्सल (MPEG4 एन्कोडर) 720 x 480 पिक्सल (अन्य)	1408 x 1152 पिक्सल (H263) 1280 x 720 पिक्सल (अन्य)	1920 x 1080 पिक्सल (MPEG4 के अलावा)	3840 x 2160 पिक्सल (HEVC, VP9)

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

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

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

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

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

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

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

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

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

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

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

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

5.2.1. एच.263

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

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

5.2.2. H.264

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

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

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

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

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

5.2.3. वीपी8

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

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

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

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

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

5.2.4. वीपी9

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

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

	एसडी	एचडी 720 पिक्सल	एचडी 1080 पिक्सल	यूएचडी
वीडियो रिज़ॉल्यूशन	720 x 480 पिक्सल	1280 x 720 पिक्सल	1920 x 1080 पिक्सल	3840 x 2160 पिक्सल
वीडियो फ़्रेम रेट	30 एफ़पीएस (फ़्रेम प्रति सेकंड)	30 एफ़पीएस (फ़्रेम प्रति सेकंड)	30 एफ़पीएस (फ़्रेम प्रति सेकंड)	30 एफ़पीएस (फ़्रेम प्रति सेकंड)
वीडियो बिटरेट	1.6 एमबीपीएस	4 एमबीपीएस	5 एमबीपीएस	20 एमबीपीएस

अगर डिवाइस लागू करने की सुविधा का इस्तेमाल करके, मीडिया API के ज़रिए प्रोफ़ाइल 2 या प्रोफ़ाइल 3 को लागू करने का दावा किया जाता है, तो:

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

5.2.5. एच.265

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

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

	एसडी	एचडी 720 पिक्सल	एचडी 1080 पिक्सल	यूएचडी
वीडियो रिज़ॉल्यूशन	720 x 480 पिक्सल	1280 x 720 पिक्सल	1920 x 1080 पिक्सल	3840 x 2160 पिक्सल
वीडियो फ़्रेम रेट	30 एफ़पीएस (फ़्रेम प्रति सेकंड)	30 एफ़पीएस (फ़्रेम प्रति सेकंड)	30 एफ़पीएस (फ़्रेम प्रति सेकंड)	30 एफ़पीएस (फ़्रेम प्रति सेकंड)
वीडियो बिटरेट	1.6 एमबीपीएस	4 एमबीपीएस	5 एमबीपीएस	20 एमबीपीएस

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

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

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

5.3.1. MPEG-2

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

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

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

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

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

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

5.3.5. H.265 (HEVC)

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

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

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

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

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

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

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

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

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

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

5.3.6. वीपी8

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

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

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

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

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

5.3.7. वीपी9

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

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

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

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

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

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

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

अगर डिवाइस लागू करने की सुविधा के तहत, '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 और बिटस्ट्रीम और/या कंटेनर से MediaFormat#KEY_HDR10_PLUS_INFO में ज़रूरी एचडीआर मेटाडेटा एक्सट्रैक्ट करना ज़रूरी है.HDR10Plus इन निर्देशों में, बिटस्ट्रीम और/या कंटेनर से ज़रूरी एचडीआर मेटाडेटा (सभी एचडीआर प्रोफ़ाइलों के लिए MediaFormat#KEY_HDR_STATIC_INFO) का आउटपुट देने की सुविधा भी होनी चाहिए.

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

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

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

5.3.8. Dolby Vision

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

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

5.3.9. AV1

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

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

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

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

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

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

• [C-1-1] इन चीज़ों के आधार पर, रॉ ऑडियो कॉन्टेंट रिकॉर्ड करने की अनुमति होनी चाहिए:

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

• इन चीज़ों को ध्यान में रखते हुए, रॉ ऑडियो कॉन्टेंट कैप्चर किया जाना चाहिए:

  • फ़ॉर्मैट: लीनियर PCM, 16-बिट, और 24-बिट
  • सैंपलिंग रेट: 8000, 11025, 16,000, 22,050, 24,000, 32,000, 44,100, 48,000 हर्ट्ज़
  • चैनल: उतने चैनल. डिवाइस में जितने भी माइक्रोफ़ोन हैं

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

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

• रॉ ऑडियो कॉन्टेंट को एएम रेडियो और डीवीडी क्वालिटी में कैप्चर करने की अनुमति होनी चाहिए, जिसका मतलब है कि ये विशेषताएं यहां दी गई हैं:

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

• [C-1-4] MicrophoneInfo API का पालन करना ज़रूरी है. साथ ही, AudioManager.getMicrophones() API के ज़रिए तीसरे पक्ष के ऐप्लिकेशन से ऐक्सेस किए जा सकने वाले डिवाइस पर उपलब्ध माइक्रोफ़ोन की जानकारी ठीक से भरें. साथ ही, ऐसे चालू माइक्रोफ़ोन भी ज़रूरी हैं जिन्हें तीसरे पक्ष के ऐप्लिकेशन 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 और 48,000 में से किसी एक पर कैप्चर करना ज़रूरी है.
• [C-1-2] AudioSource.VOICE_RECOGNITION के ऑडियो सोर्स से ऑडियो स्ट्रीम रिकॉर्ड करते समय, ग़ैर-ज़रूरी आवाज़ें कम करने वाली किसी भी तरह की ऑडियो प्रोसेसिंग को डिफ़ॉल्ट रूप से बंद करना ज़रूरी है.
• [C-1-3] AudioSource.VOICE_RECOGNITION के ऑडियो सोर्स से ऑडियो स्ट्रीम रिकॉर्ड करते समय, अपने-आप लागू होने वाले गेन कंट्रोल को डिफ़ॉल्ट रूप से बंद करना ज़रूरी है.
• आवाज़ की पहचान करने वाली ऑडियो स्ट्रीम को फ़्रीक्वेंसी की तुलना में बिलकुल सपाट आयाम के साथ रिकॉर्ड किया जाना चाहिए: खास तौर पर, ±3 dB, 100 हर्ट्ज़ से लेकर 4000 हर्ट्ज़ तक.
• इनपुट की संवेदनशीलता को इस तरह सेट करके आवाज़ पहचानने वाली ऑडियो स्ट्रीम को रिकॉर्ड करना चाहिए कि 1,000 हर्ट्ज़ पर साउंड पावर लेवल (एसपीएल) के किसी सोर्स से 16-बिट के सैंपल के लिए 2,500 आरएमएस मिलें.
• आवाज़ की पहचान करने वाली ऑडियो स्ट्रीम को रिकॉर्ड करना चाहिए, ताकि PCM आयाम स्तर इनपुट को रैखिक रूप से ट्रैक कर सकें SPL, माइक्रोफ़ोन पर कम से कम 30 dB की श्रेणी में -18 dB से +12 dB re 90 dB SPL तक बदल जाए.
• आवाज़ की पहचान करने वाली ऑडियो स्ट्रीम को माइक्रोफ़ोन पर 90 dB SPL इनपुट स्तर पर, 1 किलोहर्ट्ज़ के लिए 1% से कम के टोटल हारमोनिक डिस्टॉर्शन (THD) के साथ रिकॉर्ड किया जाना चाहिए.

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

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

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

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

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

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

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

5.4.4. अकूस्टिक इको रद्द करने वाला

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

• वॉइस कम्यूनिकेशन के लिए ट्यून की गई और AudioSource.VOICE_COMMUNICATION का इस्तेमाल करके कैप्चर करते समय कैप्चर पाथ पर लागू की जानी चाहिए Acoustic EchoCanceler (AEC) तकनीक लागू करनी चाहिए

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

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

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 हर्ट्ज़ से लेकर 4000 हर्ट्ज़ तक ±3dB.
• ऑडियो इनपुट की संवेदनशीलता को इस तरह सेट करना चाहिए कि 90 dB के साउंड प्रेशर लेवल (SPL) पर चलाए जाने वाले 1000 हर्ट्ज़ वाले साइनसोइडल टोन सोर्स (एसपीएल) में, 16 बिट-सैंपल (या फ़्लोटिंग पॉइंट/डबल प्रिसिज़न सोर्स के लिए -22.35 dB फ़ुल स्केल) के लिए 2,500 के आरएमएस के साथ रिस्पॉन्स मिलता है.
• [C-SR] का बहुत ज़्यादा सुझाव दिया जाता है, ताकि कम फ़्रीक्वेंसी की सीमा में आयाम का स्तर दिखाया जा सके: खास तौर पर, आवाज़ की पहचान करने वाले ऑडियो स्रोत को रिकॉर्ड करने वाले हर माइक्रोफ़ोन के लिए, मिड-फ़्रीक्वेंसी रेंज की तुलना में ±20 dB से लेकर 5 हर्ट्ज़ से 100 हर्ट्ज़ तक.
• [C-SR] का बहुत ज़्यादा सुझाव दिया जाता है, ताकि हाई फ़्रीक्वेंसी रेंज में आयाम का स्तर दिखाया जा सके: खास तौर पर, आवाज़ की पहचान करने वाले ऑडियो स्रोत को रिकॉर्ड करने वाले हर माइक्रोफ़ोन की मिड-फ़्रीक्वेंसी रेंज की तुलना में ±30 dB से लेकर 4000 हर्ट्ज़ से 22 किलोहर्ट्ज़ तक.

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

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

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

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

• [C-1-1] इन चीज़ों के आधार पर, रॉ ऑडियो कॉन्टेंट चलाने की अनुमति होनी चाहिए:

  • सोर्स फ़ॉर्मैट: लीनियर PCM, 16-बिट, 8-बिट, फ़्लोट
  • चैनल: मोनो, स्टीरियो, ज़्यादा से ज़्यादा आठ चैनलों के साथ मान्य मल्टीचैनल कॉन्फ़िगरेशन
  • सैंपलिंग रेट (हर्ट्ज़ में):
    • ऊपर दिए गए चैनल कॉन्फ़िगरेशन पर 8,000, 11,025, 16,000, 22,050, 32,000, 44,100, 48,000
    • मोनो और स्टीरियो में 96000

• इन चीज़ों को ध्यान में रखकर, रॉ ऑडियो कॉन्टेंट चलाया जा सकता है:

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

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

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

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

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

5.5.3. ऑडियो आउटपुट की आवाज़

वाहन संबंधित डिवाइस पर विज्ञापन लागू करना:

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

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

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

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

• आउटपुट में इंतज़ार का समय. जब कोई ऐप्लिकेशन, PCM-कोड वाले डेटा का फ़्रेम लिखता है और उससे जुड़ी आवाज़ को डिवाइस पर मौजूद ट्रांसड्यूसर या सिग्नल के आस-पास के माहौल में पेश करता है, तो डिवाइस को एक पोर्ट के ज़रिए दिखाया जाता है. इसे बाहर भी देखा जा सकता है.
• कोल्ड आउटपुट में इंतज़ार का समय. पहले फ़्रेम के लिए आउटपुट में लगने वाला समय. जब ऑडियो आउटपुट सिस्टम का इस्तेमाल नहीं किया जा रहा हो और अनुरोध किए जाने से पहले उसे बंद कर दिया गया हो.
• आउटपुट में लगातार इंतज़ार का समय. डिवाइस पर ऑडियो चलने के बाद, बाद के फ़्रेम के लिए आउटपुट इंतज़ार का समय.
• इनपुट के इंतज़ार का समय. डिवाइस में मौजूद ट्रांसड्यूसर या सिग्नल पर किसी डिवाइस के आस-पास कोई आवाज़ होने के बीच का समय. जब कोई ऐप्लिकेशन, पीसीएम-कोड वाले डेटा के फ़्रेम को पढ़ता है, तो यह समय डिवाइस में पोर्ट के ज़रिए आता है.
• इनपुट खो गया है. किसी इनपुट सिग्नल का शुरुआती हिस्सा, जो इस्तेमाल नहीं किया जा सकता या उपलब्ध नहीं है.
• कोल्ड इनपुट लेटेंसी. खोए हुए इनपुट समय और पहले फ़्रेम के लिए इनपुट इंतज़ार के समय का योग, जब ऑडियो इनपुट सिस्टम को अनुरोध से पहले बंद और चालू कर दिया गया हो.
• इनपुट के इंतज़ार का समय लगातार. डिवाइस ऑडियो कैप्चर करने के दौरान, बाद के फ़्रेम के लिए इनपुट इंतज़ार का समय.
• कोल्ड आउटपुट सिग्नल में गड़बड़ी. कोल्ड आउटपुट लेटेंसी वैल्यू के अलग-अलग मेज़रमेंट में फ़र्क़.
• कोल्ड इनपुट सिग्नल में गड़बड़ी. कोल्ड इनपुट लेटेंसी वैल्यू के अलग-अलग मेज़रमेंट में अंतर.
• दोतरफ़ा यात्रा के लिए लगातार इंतज़ार का समय. इनपुट में देरी के साथ-साथ, आउटपुट में इंतज़ार का समय, और एक बफ़र पीरियड, दोनों का कुल योग. बफ़र पीरियड की मदद से ऐप्लिकेशन, सिग्नल और समय को प्रोसेस कर सकता है. इससे, इनपुट और आउटपुट स्ट्रीम के बीच के अंतर को कम किया जा सकता है.
• OpenSL ES PCM बफ़र क्यू एपीआई. Android एनडीके में पीसीएम से जुड़े OpenSL ES एपीआई का सेट.
• ऑडियो नेटिव ऑडियो एपीआई. Android NDK में AAudio एपीआई का सेट.
• timestamp. स्ट्रीम में, फ़्रेम के रिलेटिव पोज़िशन और उससे जुड़े एंडपॉइंट पर फ़्रेम के ऑडियो प्रोसेसिंग पाइपलाइन में पहुंचने और उससे निकलने का अनुमानित समय शामिल होता है. ऑडियो टाइमस्टैंप भी देखें.
• 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] AudioTrack.getTimestamp और AAudioStream_getTimestamp से मिला आउटपुट टाइमस्टैंप, +/- 1 मि॰से॰ के हिसाब से सटीक होता है.

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

• [C-SR] इस बात का सुझाव दिया जाता है कि android.hardware.audio.low_latency फ़ीचर फ़्लैग का एलान करके, इंतज़ार का समय कम करने वाले ऑडियो की शिकायत की जाए.
• [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] इनपुट के टाइमस्टैंप में गड़बड़ी को तब सीमित करें, जब ऑडियो रिकॉर्ड.गेटटाइमस्टैंप या AAudioStream_getTimestamp से मिलने वाली गड़बड़ी को +/- 2 मि॰से॰ किया गया हो. "गड़बड़ी" यहां सही वैल्यू से विचलन का मतलब है.
• [C-3-2] 500 मिलीसेकंड या उससे कम कोल्ड इनपुट इंतज़ार का समय.

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

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

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

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

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

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

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

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

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

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

आरटीएसपी (आरटीपी, एसडीपी)

प्रोफ़ाइल का नाम	संदर्भ	आवश्यक कोडेक समर्थन
H264 एवीसी	आरएफ़सी 6184	H264 एवीसी से जुड़ी जानकारी के लिए, सेक्शन 5.1.3 देखें
MP4A-एलएटीएम	आरएफ़सी 6416	AAC और उसके वैरिएंट के बारे में जानकारी के लिए, सेक्शन 5.1.1 देखें
H263-1998	आरएफ़सी 3551 आरएफ़सी 4629 आरएफ़सी 2190	H263 के बारे में ज़्यादा जानकारी के लिए, सेक्शन 5.1.3 देखें
H263-2000 की उम्र	आरएफ़सी 4629	H263 के बारे में ज़्यादा जानकारी के लिए, सेक्शन 5.1.3 देखें
एएमआर	आरएफ़सी 4867	AMR-NB के बारे में जानकारी के लिए, सेक्शन 5.1.1 देखें
एएमआर-डब्ल्यूबी	आरएफ़सी 4867	AMR-WB के बारे में जानकारी के लिए, सेक्शन 5.1.1 देखें
एमपी4वी-ईएस	आरएफ़सी 6416	MPEG-4 एसपी के बारे में जानकारी के लिए, सेक्शन 5.1.3 देखें
mpeg4-जेनरिक	आरएफ़सी 3640	AAC और उसके वैरिएंट के बारे में जानकारी के लिए, सेक्शन 5.1.1 देखें
एमपी2टी	आरएफ़सी 2250	ज़्यादा जानकारी के लिए, एचटीटीपी लाइव स्ट्रीमिंग के नीचे MPEG-2 ट्रांसपोर्ट स्ट्रीम देखें

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

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

• [C-1-1] Display.FLAG_SECURE के लिए सहायता का एलान करना ज़रूरी है.

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

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

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

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

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

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

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

  • यूएसबी होस्ट मोड, सेक्शन 7.7
  • यूएसबी सहायक डिवाइस (जैसे, कीबोर्ड, माउस, मॉनिटर, वेबकैम वगैरह) मोड, सेक्शन 7.7
  • एमआईडीआई ओवर ब्लूटूथ LE में मुख्य भूमिका में काम कर रहा है, सेक्शन 7.4.3

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

• [C-1-3] इसमें libamidi.so (स्थानीय एमआईडीआई की सुविधा) को शामिल करना ज़रूरी है

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 बफ़र क्यू एपीआई और Aऑडियो नेटिव ऑडियो एपीआई के कम से कम एक पाथ, दोनों का इस्तेमाल करके इंतज़ार के समय और यूएसबी ऑडियो की ज़रूरी शर्तों को पूरा करना होगा.
• इंतज़ार का समय और यूएसबी ऑडियो की ज़रूरी शर्तें पूरी करने के लिए, [SR] का खास तौर पर सुझाव दिया जाता है. इसके लिए, MMAP पाथ पर AAudio नेटिव ऑडियो एपीआई इस्तेमाल किया जाता है.
• [C-1-6] कोल्ड आउटपुट के लिए इंतज़ार का समय 200 मिलीसेकंड या इससे कम होना चाहिए.
• [C-1-7] कोल्ड इनपुट इंतज़ार का समय 200 मिलीसेकंड या इससे कम होना चाहिए.
• [SR] इस्तेमाल करने का सुझाव दिया जाता है, ताकि जब ऑडियो चालू हो और सीपीयू पर लोड अलग-अलग हो, तो सीपीयू की परफ़ॉर्मेंस एक जैसी रहे. इसकी जांच, SynthMark के कमिट आईडी 09b13c6f49ea089f8c31e5d035f912cc405b7ab8 के Android ऐप्लिकेशन वर्शन का इस्तेमाल करके की जानी चाहिए. SynthMark, सिम्युलेटेड ऑडियो फ़्रेमवर्क पर चलने वाले सॉफ़्टवेयर सिंथेसाइज़र का इस्तेमाल करता है. यह सिस्टम की परफ़ॉर्मेंस का आकलन करता है. SynthMark ऐप्लिकेशन को “ऑटोमेटेड टेस्ट” विकल्प का इस्तेमाल करके चलाना चाहिए और इससे ये नतीजे मिलेंगे:
  • Voicemark.90 >= 32 आवाज़ें
  • Latitudemark.fixed.little <= 15 मि॰से॰
  • लेटेंसीमार्क.डाइनैमिक.लिटल <= 50 मि॰से॰

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

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

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

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

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

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

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

• [C-3-1] यूएसबी ऑडियो क्लास लागू करना ज़रूरी है.
• [C-3-2] यूएसबी ऑडियो क्लास का इस्तेमाल करने वाले यूएसबी होस्ट मोड पोर्ट पर, ऑडियो के इंतज़ार का समय 20 मिलीसेकंड या उससे कम होना चाहिए.
• यूएसबी ऑडियो क्लास का इस्तेमाल करने वाले यूएसबी होस्ट मोड पोर्ट पर, दोतरफ़ा यात्रा के ऑडियो के इंतज़ार का समय 10 मिलीसेकंड या उससे कम होना चाहिए.
• [C-SR] इन ज़रूरतों को भी पूरा करने वाले यूएसबी ऑडियो सहायक डिवाइसों के साथ इस्तेमाल किए जाने पर, इस बात का खास तौर पर सुझाव दिया जाता है कि I/O से हर दिशा में आठ चैनल तक काम किया जा सके. साथ ही, सैंपल रेट 96 किलोहर्ट्ज़ (kHz) और 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_UN सहयोगी के ज़रिए सहायता की रिपोर्ट करना ज़रूरी है.

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

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

• [C-1-4] ऐसा होना चाहिए कि ज़्यादा फ़्रीक्वेंसी की रेंज में आयाम का लेवल दिखाया जाए: खास तौर पर, प्रोसेस नहीं किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए जाने वाले हर माइक्रोफ़ोन की मिड फ़्रीक्वेंसी रेंज की तुलना में, खास तौर पर 7,000 हर्ट्ज़ से लेकर 22 किलोहर्ट्ज़ तक, 30 dB से लेकर 22 किलोहर्ट्ज़ तक.

• [C-1-5] ऑडियो इनपुट की संवेदनशीलता को इस तरह सेट करना ज़रूरी है कि 94 dB के साउंड प्रेशर लेवल (SPL) पर चलाए जाने वाले 1000 हर्ट्ज़ वाले साइनोसोइडल टोन सोर्स से 16 बिट-सैंपल (या फ़्लोट करने वाले पॉइंट/डबल प्रोसेस नहीं किए गए सटीक सैंपल के लिए -36 dB फ़ुल स्केल) के लिए 520 के आरएमएस के साथ रिस्पॉन्स मिलता है.

• [C-1-6] प्रोसेस नहीं किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए जाने वाले हर माइक्रोफ़ोन के लिए, 60 dB या इससे ज़्यादा का सिग्नल-टू-नॉइज़ रेशियो (SNR) होना ज़रूरी है. (वहीं एसएनआर को 94 dB SPL और खुद के शोर के बराबर के एसपीएल (A-वेट वाले) के बीच के अंतर के तौर पर मापा जाता है).

• [C-1-7] प्रोसेस न किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए जाने वाले हर माइक्रोफ़ोन में, 90 dB SPL इनपुट लेवल पर 1 किलोहर्ट्ज़ के लिए 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 में बताए गए adb और एओएसपी में दिए गए शेल कमांड के साथ काम करना ज़रूरी है. इसका इस्तेमाल ऐप्लिकेशन डेवलपर कर सकते हैं. इनमें dumpsys cmd stats भी शामिल हैं
  • शेल कमांड cmd testharness के साथ काम करने के लिए, [C-SR] का सुझाव दिया जाता है.
  • [C-0-3] डंपसिस कमांड के ज़रिए लॉग किए गए डिवाइस के सिस्टम इवेंट (बैटरीस्टेट , डिस्कस्टेट, फ़िंगरप्रिंट, ग्राफ़िक्सस्टैट, नेटस्टेट, सूचना, प्रोस्टेट) के फ़ॉर्मैट या कॉन्टेंट में बदलाव नहीं करना चाहिए.
  • [C-0-10] ज़रूरी है कि आप इन्हें रिकॉर्ड करें और इन्हें बिना किसी गलती के रिकॉर्ड करें. साथ ही, इन इवेंट को cmd stats शेल कमांड और StatsManager System API क्लास में ऐक्सेस करने लायक और उपलब्ध कराना चाहिए.
    • ऐक्टिविटी फ़ोरग्राउंडस्टेटस
    • गड़बड़ी की पहचान हुई है
    • ऐप्लिकेशन ब्रेडक्रंब की रिपोर्ट की गई
    • AppCrash हुआ
    • AppStart हुआ
    • बैटरी स्तर में बदलाव
    • बैटरीसेवरमोडस्टेट बदलें
    • BleScanनतीजे मिला
    • BleScanStateChanged
    • ChargeStateChanged
    • DeviceIdleModeStateChanged
    • ForegroundServiceStateChanged
    • GpsScanStateChanged
    • JobStateChanged
    • प्लग की गई स्थिति
    • शेड्यूल किए गए जॉबस्टेट में बदलाव
    • स्क्रीनस्टेट बदला गया
    • SyncStateChanged
    • सिस्टम बीता हुआ रीयलटाइम
    • UidProcessStateChanged
    • वेकलॉक स्टेट चेंज्ड
    • वेकअप अलार्म ट्रिगर हुआ
    • WifiLockStateChanged
    • WifiMulticastLockStateChanged
    • वाई-फ़ाईस्कैनस्टेट बदला गया
  • [C-0-4] डिवाइस-साइड adb डीमन डिफ़ॉल्ट रूप से बंद होना चाहिए. साथ ही, Android डीबग ब्रिज को चालू करने के लिए एक ऐसा तरीका होना चाहिए जिसे उपयोगकर्ता आसानी से ऐक्सेस कर सके.
  • [C-0-5] सुरक्षित adb के साथ काम करना चाहिए. Android में सुरक्षित adb की सुविधा शामिल है. सुरक्षित adb, पुष्टि किए गए जाने-पहचाने होस्ट पर adb चालू करता है.

  • [C-0-6] एक ऐसा तरीका उपलब्ध कराना ज़रूरी है जिससे adb को होस्ट मशीन से कनेक्ट किया जा सके. उदाहरण के लिए:

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

• Dalvik डीबग मॉनिटर सेवा (डीडीएम)

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

• परफ़ेटो

  • [C-SR] इस बात की बहुत ज़्यादा सलाह दी जाती है कि शेल उपयोगकर्ता को /system/bin/perfetto बाइनरी दिखाई दे और cmdline परफ़ेटो के दस्तावेज़ का पालन करता है.
  • [C-SR] परफ़ेटो बाइनरी को इनपुट के रूप में ऐसे प्रोटोबफ़ कॉन्फ़िगरेशन के रूप में स्वीकार करने का बहुत ज़्यादा सुझाव दिया जाता है जो परफ़ेटो दस्तावेज़ में दिए गए स्कीमा का पालन करता है.
  • [C-SR] परफ़ेटो बाइनरी को आउटपुट के तौर पर ऐसे प्रोटोबफ़ ट्रेस में लिखने का सुझाव दिया जाता है जो परफ़ेटो के दस्तावेज़ में दिए गए स्कीमा का पालन करता है.
  • [C-SR] का सुझाव दिया जाता है कि हम परफ़ेटो बाइनरी के ज़रिए, कम से कम परफ़ेटो के दस्तावेज़ में बताए गए डेटा सोर्स उपलब्ध कराएं.

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

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

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

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

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

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

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

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

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

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

• [C-0-2] कॉम्पोनेंट एपीआई के लिए, क्लास की पूरी परिभाषाएं (जैसा कि SDK टूल के दस्तावेज़ में बताया गया है) अब भी दिखाई जानी चाहिए.
• [C-0-3] इस एपीआई के व्यवहार को कुछ सही तरीके से, नो-ऑपरेशन के तौर पर लागू किया जाना चाहिए.
• [C-0-4] एपीआई के तरीकों के लिए ज़रूरी है कि वे शून्य वैल्यू दिखाएं. ऐसा SDK टूल के दस्तावेज़ के मुताबिक होना चाहिए.
• [C-0-5] एपीआई के तरीकों के लिए, उन क्लास का नो-ऑप लागू करना ज़रूरी है जहां SDK दस्तावेज़ में शून्य वैल्यू की अनुमति नहीं है.
• [C-0-6] एपीआई के तरीकों में ऐसे अपवाद नहीं होने चाहिए जिनके बारे में SDK टूल के दस्तावेज़ में बताया नहीं गया है.
• [C-0-7] डिवाइस लागू करने के लिए यह ज़रूरी है कि वह एक ही बिल्ड फ़िंगरप्रिंट के लिए, android.content.pm.PackageManager क्लास पर getSystemAvailableFeatures() और hasSystemFeature(String) तरीकों से, हार्डवेयर कॉन्फ़िगरेशन की सटीक जानकारी लगातार रिपोर्ट करे.

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

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 के लिए, लेआउट के सही साइज़ की जानकारी देना ज़रूरी है. खास तौर पर, लागू करने के लिए डिवाइस के लॉजिकल सघनता-इंडिपेंडेंट पिक्सल (डीपी) स्क्रीन डाइमेंशन की सही रिपोर्ट नीचे दी गई है:

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

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

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

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

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

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] डिफ़ॉल्ट रूप से, डिवाइस पर Android फ़्रेमवर्क की डेंसिटी में से सिर्फ़ एक को रिपोर्ट करना ज़रूरी है, जो DENSITY_DEVICE_STABLE एपीआई के ज़रिए DisplayMetrics पर लिस्ट किए गए हैं. साथ ही, इस वैल्यू को किसी भी समय बदला नहीं जाना चाहिए; हालांकि, डिवाइस पहले से चालू होने के बाद डिसप्ले कॉन्फ़िगरेशन में किए गए बदलावों (उदाहरण के लिए, डिसप्ले साइज़) के हिसाब से अलग-अलग आर्बिट्रेरी डेंसिटी रिपोर्ट कर सकता है.

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

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

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

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

डिवाइस पर यह सुविधा लागू करना:

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

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

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

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

7.1.4.1 OpenGL ES

डिवाइस पर यह सुविधा लागू करना:

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

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

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

अगर डिवाइस, 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] ऐप्लिकेशन पैकेज की नेटिव लाइब्रेरी डायरेक्ट्री में, Vulkan नेटिव एपीआई vkEnumerateInstanceLayerProperties() और vkEnumerateDeviceLayerProperties() की मदद से, libVkLayer*.so नाम की नेटिव लाइब्रेरी में मौजूद लेयर की गिनती की जानी चाहिए .
• [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_property और 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 रेंडरस्क्रिप्ट

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

7.1.4.4 2D ग्राफ़िक ऐक्सेलरेशन

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

डिवाइस पर यह सुविधा लागू करना:

• [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 स्पेस में कम से कम 90% DCI-P3 हो.
• [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 एक्सटेंशन के लिए सहायता का विज्ञापन देना ज़रूरी है.
• GL_EXT_sRGB के साथ काम करने के लिए, [C-SR] का सुझाव दिया जाता है.

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

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

7.1.5. ऐप्लिकेशन के साथ काम करने वाला लेगसी मोड

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

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

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

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

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

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

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

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

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

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

डिवाइस पर यह सुविधा लागू करना:

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

7.2.1. कीबोर्ड

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

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

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

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

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

7.2.6. गेम कंट्रोलर के लिए सहायता

7.2.6.1. बटन मैपिंग

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

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

बटन	एचआईडी का इस्तेमाल2	Android बटन
जवाब1	0x09 0x001	KEYCODE_BUTTON_A (96)
ब1	0x09 0x0002	KEYCODE_BUTTON_B (97)
X1	0x09 0x004	KEYCODE_BUTTON_X (99)
साल1	0x09 0x005	KEYCODE_BUTTON_Y (100)
डी-पैड अप1 डी-पैड डाउन करें1	0x01 0x00393	AXIS_HAT_Y4
बाईं ओर एक डी-पैड1 दाईं ओर डी-पैड की सुविधा1	0x01 0x00393	AXIS_HAT_X4
बाईं ओर का बटन1	0x09 0x007	KEYCODE_BUTTON_L1 (102)
राइट शोल्डर बटन1	0x09 0x008	KEYCODE_BUTTON_R1 (103)
लेफ़्ट स्टिक क्लिक1	0x09 0x000	KEYCODE_BUTTON_THUMBL (106)
राइट स्टिक पर क्लिक करें1	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
होम1	0x0c 0x0223	KEYCODE_HOME (3)
वापस जाएं1	0x0c 0x0224	KEYCODE_BACK (4)

1 KeyEvent

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

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

4 MotionEvent

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

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

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

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

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

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

ऊपर दी गई सूची में पूरी जानकारी नहीं है; सेंसर पर Android SDK टूल और Android ओपन सोर्स दस्तावेज़ों के व्यवहार को आधिकारिक माना जाता है.

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

डिवाइस पर यह सुविधा लागू करना:

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

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

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

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

डिवाइस पर यह सुविधा लागू करना:

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

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

• [C-1-1] कम से कम 50 हर्ट्ज़ की फ़्रीक्वेंसी तक इवेंट की रिपोर्ट उपलब्ध होनी चाहिए.
• [C-1-2] TYPE_ACCELEROMETER सेंसर को लागू करना और उसकी रिपोर्ट करना ज़रूरी है.
• [C-1-3] Android एपीआई में दी गई जानकारी के मुताबिक, Android सेंसर कोऑर्डिनेट सिस्टम का पालन करना ज़रूरी है.
• [C-1-4] ऐसा ज़रूरी है कि किसी भी ऐक्सिस पर गुरुत्वाकर्षण(4g) या इससे ज़्यादा के फ़्रीफ़ॉल को चार गुना तक मापने की क्षमता हो.
• [C-1-5] इसका रिज़ॉल्यूशन कम से कम 12-बिट होना चाहिए.
• [C-1-6] स्टैंडर्ड डेविएशन का स्टैंडर्ड डीविएशन 0.05 m/s^ से ज़्यादा नहीं होना चाहिए. इसमें स्टैंडर्ड डेविएशन का हिसाब, हर ऐक्सिस के आधार पर लगाया जाना चाहिए. यह डेविएशन, सबसे तेज़ सैंपलिंग रेट पर, कम से कम तीन सेकंड तक इकट्ठा किए गए सैंपल के आधार पर हर ऐक्सिस के हिसाब से निकाला जाना चाहिए.
• TYPE_SIGNIFICANT_MOTION कंपोज़िट सेंसर को लागू करने के लिए, [SR] को इस्तेमाल करने का सुझाव दिया जाता है.
• TYPE_ACCELEROMETER_UNCALIBRATED सेंसर को लागू करने और इसकी रिपोर्ट करने के लिए, [SR] को इस्तेमाल करने का सुझाव दिया जाता है. इस ज़रूरी शर्त को पूरा करने के लिए, Android डिवाइसों का बहुत ज़्यादा सुझाव दिया जाता है. इससे उन्हें आने वाले समय में लॉन्च होने वाले प्लैटफ़ॉर्म पर अपग्रेड किया जा सकेगा, जहां ऐसा करना ज़रूरी हो सकता है.
• Android SDK दस्तावेज़ में दी गई जानकारी के हिसाब से, TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER कंपोज़िट सेंसर को लागू करना चाहिए.
• कम से कम 200 हर्ट्ज़ तक इवेंट रिपोर्ट किए जाने चाहिए.
• रिज़ॉल्यूशन कम से कम 16-बिट होना चाहिए.
• अगर लाइफ़ साइकल के दौरान विशेषताएं बदल जाती हैं और पेमेंट हो जाता है, तो इस्तेमाल करते समय इन्हें कैलिब्रेट करना चाहिए. साथ ही, डिवाइस को फिर से चालू करने के दौरान, मुआवज़े के पैरामीटर को सुरक्षित रखना चाहिए.
• हालांकि, तापमान के हिसाब से मुआवज़ा दिया जाना चाहिए.

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

• [C-2-1] उनकी कुल ऊर्जा की खपत हमेशा 4 mW से कम होनी चाहिए.
• डाइनैमिक या स्टैटिक स्थिति में होने पर, हर इकाई का साइज़ 2 mW और 0.5 mW से कम होना चाहिए.

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

• [C-3-1] TYPE_GRAVITY और TYPE_LINEAR_ACCELERATION कंपोज़िट सेंसर को लागू करना ज़रूरी है.
• TYPE_GAME_ROTATION_VECTOR कंपोज़िट सेंसर को लागू करने के लिए, [सी-एसआर] का बहुत ज़्यादा सुझाव दिया जाता है.

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

• [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 एपीआई में दी गई जानकारी के मुताबिक, 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 मिलीवाट से कम बिजली का इस्तेमाल करना चाहिए.
• अगर सेंसर को बैच मोड के लिए 10 हर्ट्ज़ पर रजिस्टर किया गया है, तो इसे 3 mW से कम की खपत होनी चाहिए.

7.3.3. जीपीएस

डिवाइस पर यह सुविधा लागू करना:

• [सी-एसआर] जीपीएस/जीएनएसएस रिसीवर को शामिल करने का सुझाव दिया जाता है.

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

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

• स्थान निर्धारित करने के बाद खुले आसमान की स्थितियों में, जबकि त्वरण के 1 मीटर प्रति सेकंड से कम वर्ग के साथ स्थिर या गति में:

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

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

डिवाइस पर यह सुविधा लागू करना:

• [सी-एसआर] जाइरोस्कोप सेंसर शामिल करने की बहुत ज़्यादा सलाह दी जाती है. ऐसा तब तक किया जाता है, जब तक 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] यह वैरियंस, हर हर हर्ट्ज़ (हर हर्ट्ज़ या रेड^2 / s) से ज़्यादा नहीं होना चाहिए. वैरियंस, सैंपलिंग रेट के हिसाब से अलग-अलग हो सकते हैं, लेकिन इस वैल्यू के लिए सीमित होना चाहिए. दूसरे शब्दों में, अगर जाइरो के वैरियंस को एक हर्ट्ज़ की सैंपलिंग रेट पर मापा जाता है, तो यह 1e-7 रेड^2/s^2 से ज़्यादा नहीं होना चाहिए.
• [SR] जब डिवाइस सामान्य तापमान पर स्थिर रहता है, तो कैलिब्रेशन की गड़बड़ी 0.01 रेड/सेकंड से कम रखने का बहुत ज़्यादा सुझाव दिया जाता है.
• कम से कम 200 हर्ट्ज़ तक इवेंट रिपोर्ट किए जाने चाहिए.

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

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

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

• [C-3-1] TYPE_GRAVITY और TYPE_LINEAR_ACCELERATION कंपोज़िट सेंसर को लागू करना ज़रूरी है.
• TYPE_GAME_ROTATION_VECTOR कंपोज़िट सेंसर को लागू करने के लिए, [सी-एसआर] का बहुत ज़्यादा सुझाव दिया जाता है.

7.3.5. बैरोमीटर

डिवाइस पर यह सुविधा लागू करना:

• [सी-एसआर] खास तौर पर बैरोमीटर (ऐंबियंट एयर प्रेशर सेंसर) शामिल करने का सुझाव दिया जाता है.

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

• [C-1-1] TYPE_PRESSURE सेंसर को लागू करना और उसकी रिपोर्ट करना ज़रूरी है.
• [C-1-2] 5 हर्ट्ज़ या इससे ज़्यादा पर इवेंट डिलीवर करने की अनुमति होनी चाहिए.
• [C-1-3] तापमान के लिए मुआवज़ा देना ज़रूरी है.
• [SR] 300hPa से 1100hPa की रेंज में दबाव के माप की रिपोर्ट पाने के लिए, इसका बहुत ज़्यादा सुझाव दिया जाता है.
• 1hPa की पूरी तरह सटीक होना चाहिए.
• 20hPa की रेंज से ज़्यादा 0.12hPa की सटीक वैल्यू होनी चाहिए (यह समुद्र के स्तर पर ~200 मीटर में बदलाव के लिए ~1 मिनट के बराबर है).

7.3.6. Thermometer

डिवाइस पर यह सुविधा लागू करना:

• इसमें ऐंबियंट थर्मामीटर (तापमान मापने वाला सेंसर) शामिल हो सकता है.
• शायद इसमें सीपीयू तापमान सेंसर शामिल न हो.

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

• [C-1-1] को SENSOR_TYPE_AMBIENT_TEMPERATURE के तौर पर सेट किया जाना चाहिए. साथ ही, इसे उस जगह के आस-पास (कमरे/वाहन के केबिन) का तापमान मापना ज़रूरी है जहां से उपयोगकर्ता, डिवाइस से डिग्री सेल्सियस में इंटरैक्ट कर रहा है.
• [C-1-2] को SENSOR_TYPE_TEMPERATURE के तौर पर परिभाषित करना ज़रूरी है.
• [C-1-3] डिवाइस के सीपीयू का तापमान मापना ज़रूरी है.
• [C-1-4] कोई और तापमान नहीं मापना चाहिए.

ध्यान दें कि Android 4.0 में, SENSOR_TYPE_TEMPERATURE सेंसर टाइप को बंद कर दिया गया है.

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 सेंसर होना चाहिए जो:

  • माप की रेंज कम से कम -8 ग्रा॰ और +8 ग्रा॰ के बीच होनी चाहिए. माप की रेंज कम से कम -16 ग्राम और +16 ग्राम के बीच होनी चाहिए.
  • रिज़ॉल्यूशन कम से कम 2048 LSB/g होना चाहिए.
  • तापमान मापने की फ़्रीक्वेंसी कम से कम 12.5 हर्ट्ज़ या इससे कम होनी चाहिए.
  • तापमान मापने की फ़्रीक्वेंसी ज़्यादा से ज़्यादा 400 हर्ट्ज़ या इससे ज़्यादा होनी चाहिए; यह SensorDirectChannel RATE_VERY_FAST के साथ काम करना चाहिए.
  • तापमान मापने के लिए ज़रूरी नॉइज़ 400 μg/installHz से ज़्यादा नहीं होनी चाहिए.
  • इस सेंसर को चालू करने के लिए, कम से कम 3,000 सेंसर इवेंट की बफ़रिंग क्षमता का इस्तेमाल करें.
  • बैच में ऊर्जा की खपत 3 मिलीवाट से ज़्यादा नहीं होनी चाहिए.
  • [C-SR] इस बात का बहुत ज़्यादा सुझाव दिया जाता है कि इस बैंडविड्थ में कम से कम 80% की 3dB मेज़रमेंट बैंडविड्थ और व्हाइट नॉइज़ स्पेक्ट्रम हो.
  • रैंडम रैंडम वॉक का होना चाहिए, जो 30 μg होस्ट हर्ट्ज़ से कम से कम हो. टेस्ट के लिए कमरे के तापमान को जांचा गया है.
  • तापमान में बदलाव होना चाहिए और ≤ +/- 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 और +1000 dps के बीच होनी चाहिए.
  • रिज़ॉल्यूशन कम से कम 16 LSB/dps होना चाहिए.
  • तापमान मापने की फ़्रीक्वेंसी कम से कम 12.5 हर्ट्ज़ या इससे कम होनी चाहिए.
  • तापमान मापने की फ़्रीक्वेंसी ज़्यादा से ज़्यादा 400 हर्ट्ज़ या इससे ज़्यादा होनी चाहिए; यह SensorDirectChannel RATE_VERY_FAST के साथ काम करना चाहिए.
  • तापमान मापने के लिए ज़रूरी नॉइज़ 0.014°/s/प्रभावित हर्ट्ज़ से ज़्यादा नहीं होनी चाहिए.
  • [C-SR] इस बात क�