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

फ़ंक्शन	मैपिंग	संदर्भ	व्यवहार
जवाब	एचआईडी के इस्तेमाल की जानकारी देने वाला पेज: 0x0C एचआईडी का इस्तेमाल: 0x0CD Kernel बटन: KEY_PLAYPAUSE Android पासकोड: KEYCODE_MEDIA_PLAY_PAUSE	मीडिया प्लेबैक	इनपुट: थोड़ी देर दबाएं आउटपुट: चलाएं या रोकें
			इनपुट: दबाकर रखें आउटपुट: बोला गया निर्देश लॉन्च करें भेजता है: android.speech.action.VOICE_SEARCH_HANDS_FREE, अगर डिवाइस लॉक है या इसकी स्क्रीन बंद है. अगर यह नहीं है, तो android.speech.RecognizerIntent.ACTION_WEB_SEARCH भेजें
		आने वाला (इनकमिंग) कॉल	इनपुट: थोड़ी देर को दबाना आउटपुट: कॉल स्वीकार करें
			इनपुट: दबाकर रखें आउटपुट: कॉल अस्वीकार करें
		पहले से चल रहा कॉल	इनपुट: थोड़ी देर दबाएं आउटपुट: कॉल खत्म करें
			इनपुट: दबाकर रखें आउटपुट: माइक्रोफ़ोन को म्यूट या अनम्यूट करें
अरब	एचआईडी के इस्तेमाल की जानकारी देने वाला पेज: 0x0C एचआईडी का इस्तेमाल: 0x0E9 Kernel बटन: KEY_VOLUMEUP Android पासकोड: VOLUME_UP	मीडिया प्लेबैक, जारी कॉल	इनपुट: थोड़ी देर या देर तक दबाए रखना आउटपुट: सिस्टम या हेडसेट की आवाज़ बढ़ाता है
C	एचआईडी के इस्तेमाल की जानकारी देने वाला पेज: 0x0C एचआईडी का इस्तेमाल: 0x0EA Kernel बटन: KEY_VOLUMEDOWN Android पासकोड: VOLUME_DOWN	मीडिया प्लेबैक, जारी कॉल	इनपुट: थोड़ी देर या देर तक दबाए रखना आउटपुट: सिस्टम या हेडसेट की आवाज़ कम करता है
D	एचआईडी के इस्तेमाल की जानकारी देने वाला पेज: 0x0C एचआईडी का इस्तेमाल: 0x0CF Kernel बटन: 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] ज़रूरी है कि यह ब्लूटूथ के साथ काम करता हो और यह ब्लूटूथ 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 या com.android. नेमस्पेस में ACTION, CATEGORY या अन्य मुख्य स्ट्रिंग का इस्तेमाल करके, किसी भी नए इंटेंट या ब्रॉडकास्ट इंटेंट पैटर्न के मुताबिक काम करता हो.
• [C-0-2] डिवाइस लागू करने वाले लोगों को Android के ऐसे कॉम्पोनेंट शामिल नहीं करने चाहिए जो दूसरे संगठन से जुड़े पैकेज स्पेस में ACTION, CATEGORY या अन्य मुख्य स्ट्रिंग का इस्तेमाल करके नए इंटेंट या ब्रॉडकास्ट इंटेंट पैटर्न के हिसाब से काम करते हों.
• [C-0-3] डिवाइस लागू करने वाले लोगों को सेक्शन 3.2.3.1 में दिए गए मुख्य ऐप्लिकेशन में इस्तेमाल किए गए किसी भी इंटेंट पैटर्न में बदलाव नहीं करना चाहिए और न ही उसे बढ़ाना चाहिए.
• डिवाइस को लागू करने में, नेमस्पेस का इस्तेमाल करके इंटेंट पैटर्न शामिल किए जा सकते हैं. ये पैटर्न, साफ़ तौर पर और साफ़ तौर पर उनके संगठन से जुड़े होते हैं. यह पाबंदी, सेक्शन 3.6 में Java लैंग्वेज क्लास के लिए बताए गए नियमों के मुताबिक है.

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

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

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

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

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

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

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

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

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

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

• [C-2-1] आपको एक सेटिंग मेन्यू देना होगा, जो RoleManager.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 डिवाइसों के लिए, "8").

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

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

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

3.5. एपीआई के व्यवहार के साथ काम करने की सुविधा

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

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

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

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

• [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] डिवाइस पॉलिसी कंट्रोलर (DPC) की ओर से किसी खास सिस्टम फ़ंक्शन को बंद किए जाने पर, उपयोगकर्ता को इसकी जानकारी देने के लिए, सेटिंग में जाकर उपयोगकर्ता के लिए ये अनुमतियां देनी होंगी:

  • डिवाइस एडमिन ने किसी खास सेटिंग पर पाबंदी कब लगाई है, यह दिखाने के लिए एक जैसा आइकॉन या अन्य उपयोगकर्ता की कीमत (उदाहरण के लिए, अपस्ट्रीम एओएसपी की जानकारी का आइकॉन).
  • एक छोटा सा मैसेज, जो डिवाइस के एडमिन ने 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] डाइनैमिक रेंज मेटाडेटा के बारे में ISO/IEC 14496-3 के "डाइनैमिक रेंज कंट्रोल (डीआरसी)" सेक्शन में बताया जाना चाहिए. साथ ही, ऑडियो डिकोडर के डाइनैमिक रेंज से जुड़े व्यवहार को कॉन्फ़िगर करने के लिए, android.media.MediaFormat डीआरसी कुंजियों के बारे में बताना ज़रूरी है. AAC DRC कुंजियां, एपीआई 21 में पेश की गई थीं. ये कुंजियां हैं: KEY_AAC_DRC_ATTENUATION_FACTOR, KEY_AAC_DRC_BOOST_FACTOR, KEY_AAC_DRC_HEAVY_COMPRESSION, KEY_AAC_DRC_TARGET_REFERENCE_LEVEL, और KEY_AAC_ENCODED_TARGET_LEVEL.
• [SR] इस बात पर ज़ोर दिया जाता है कि ऊपर दिए गए C-2-1 और C-2-2 की ज़रूरी शर्तें, 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 LC)	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, सिर्फ़ डिकोड करना)
एमआईडीआई	एमआईडीआई टाइप 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 एपीआई इस्तेमाल किए जाएं. साथ ही, ऐसे नाम होने चाहिए जो 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] इनपुट के टाइमस्टैंप में गड़बड़ी को AudioRecord.gettimestamp या AAudioStream_getTimestamp से मिलने वाले नतीजे को +/- 2 मि॰से॰ तक सीमित करें. यहां "गड़बड़ी" का मतलब है, सही वैल्यू में अंतर.
• [C-3-2] 500 मिलीसेकंड या उससे कम कोल्ड इनपुट इंतज़ार का समय.

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

• [C-SR] 100 मिलीसेकंड या उससे कम की कोल्ड इनपुट इंतज़ार का समय. हमारा सुझाव है कि Android के इस वर्शन पर काम करने वाले मौजूदा और नए डिवाइस, इन ज़रूरी शर्तों को अभी पूरा करें. आने वाले समय में, 2021 में प्लैटफ़ॉर्म रिलीज़ होने वाले इस वर्शन में, यह ज़रूरी होगा कि कोल्ड इनपुट इंतज़ार के समय 200 मि॰से॰ या उससे कम हो. यह ज़रूरी है कि
• [C-SR] इनपुट में 30 मिलीसेकंड या उससे कम का लगातार इंतज़ार का समय.
• [C-SR] 50 मिलीसेकंड या उससे कम की लगातार दोतरफ़ा यात्रा के इंतज़ार का समय.
• [सी-एसआर] कोल्ड इनपुट सिग्नल की गड़बड़ी को कम करें.
• [C-SR] इनपुट के टाइमस्टैंप में गड़बड़ी को सीमित करें, जैसा कि 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, और MPEG-2 के बारे में ज़्यादा जानकारी के लिए, सेक्शन 5.1.3 देखें. ऑडियो कोडेक: 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] दोतरफ़ा यात्रा के दौरान, ऑडियो के लिए इंतज़ार का समय कम से कम 20 मिलीसेकंड या उससे कम का होना चाहिए. इसके बारे में, सेक्शन 5.6 में ऑडियो के इंतज़ार में लगने वाला समय में बताया गया है. साथ ही, कम से कम एक पाथ पर, 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] ज़रूरी है, जब जीपीयू डीबग लेयर चालू हों, तो डीबग करने लायक ऐप्लिकेशन की बेस डायरेक्ट्री में मिलने वाले बाहरी टूल (जो प्लैटफ़ॉर्म या ऐप्लिकेशन पैकेज का हिस्सा नहीं है) से मिली लाइब्रेरी में लेयर की गिनती करें. इससे, vkEnumratelayerProperties() और vkCreateInstance() एपीआई तरीकों का इस्तेमाल किया जा सकता है.

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

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

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

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

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

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

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

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

• [C-0-2] कॉम्पोनेंट एपीआई के लिए, क्लास की पूरी परिभाषाएं (जैसा कि SDK टूल के दस्तावेज़ में बताया गया है) अब भी दिखाई जानी चाहिए.
• [C-0-3] इस एपीआई के व्यवहार को कुछ सही तरीके से, नो-ऑपरेशन के तौर पर लागू किया जाना चाहिए.
• [C-0-4] एपीआई के तरीकों के लिए ज़रूरी है कि वे शून्य वैल्यू दिखाएं. ऐसा SDK टूल के दस्तावेज़ के मुताबिक होना चाहिए.
• [C-0-5] एपीआई के तरीकों के लिए, उन क्लास का नो-ऑप लागू करना ज़रूरी है जहां SDK दस्तावेज़ में शून्य वैल्यू की अनुमति नहीं है.
• [C-0-6] एपीआई के तरीकों में ऐसे अपवाद नहीं डालने चाहिए जो 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] डिफ़ॉल्ट रूप से, डिवाइस लागू करने के लिए DENSITY_DEVICE_STABLE एपीआई के ज़रिए DisplayMetrics पर दी गई Android फ़्रेमवर्क की डेंसिटी में से सिर्फ़ एक को रिपोर्ट करना ज़रूरी है. इस वैल्यू को किसी भी समय नहीं बदलना चाहिए. हालांकि, डिवाइस इस्तेमाल करने के बाद शुरू किए गए डिसप्ले कॉन्फ़िगरेशन में किए गए बदलावों (उदाहरण के लिए, डिसप्ले साइज़) के आधार पर, डिवाइस में अलग-अलग डेंसिटी को रिपोर्ट किया जा सकता है.

• डिवाइस को लागू करने के लिए, 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 एक्सटेंशन के साथ काम करते हों.
• EGL_KHR_partial_update और OES_EGL_image_external एक्सटेंशन के साथ काम करने के लिए, [C-SR] का सुझाव दिया जाता है.
• 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 डीपी चौड़ाई) वाले मोड के बराबर काम करता है. ऐसा लेगसी ऐप्लिकेशन के लिए किया जाता है, जो Android के पुराने वर्शन के लिए डेवलप नहीं किए गए हैं और जो स्क्रीन के साइज़ की इंडिपेंडेंट तौर पर पहले से तारीख तैयार करते हैं.

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 AXIS_RZ

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

  • माप की रेंज कम से कम -1000 और +1000 dps के बीच होनी चाहिए.
  • रिज़ॉल्यूशन कम से कम 16 LSB/dps होना चाहिए.
  • तापमान मापने की फ़्रीक्वेंसी कम से कम 12.5 हर्ट्ज़ या इससे कम होनी चाहिए.
  • इसे ज़्यादा से ज़्यादा 400 हर्ट्ज़ या इससे ज़्यादा मेज़रमेंट फ़्रीक्वेंसी का होना चाहिए; यह SensorDirectChannel RATE_VERY_FAST पर काम करना चाहिए.
  • तापमान मापने के लिए ज़रूरी नॉइज़ 0.014°/s/प्रभावित हर्ट्ज़ से ज़्यादा नहीं होनी चाहिए.
  • [C-SR] इस बात का बहुत ज़्यादा सुझाव दिया जाता है कि इस बैंडविड्थ में कम से कम 80% की 3dB मेज़रमेंट बैंडविड्थ और व्हाइट नॉइज़ स्पेक्ट्रम हो.
  • कमरे के तापमान पर, रैंडम वॉक की दर 0.001 °/s 7Hz से कम होनी चाहिए.
  • तापमान में बदलाव होना चाहिए और तापमान ≤ +/- 0.05 °/ s / °C होना चाहिए.
  • 0.02% / °C के तापमान के मुकाबले संवेदनशीलता में बदलाव होना चाहिए.
  • सबसे सही लाइन वाली लाइन होनी चाहिए, जो 0.2% या इससे कम हो.
  • शोर की सघनता ≤ 0.007 °/s/होस्ट हर्ट्ज़ होनी चाहिए.
  • डिवाइस के स्थिर होने पर, उसका कैलिब्रेशन गड़बड़ी 0.002 रेड/से॰ से कम होना चाहिए 10 ~ 40 °C.
  • g-सेंसिटिविटी, 0.1°/s/g से कम होनी चाहिए.
  • डिवाइस के इस्तेमाल के लिए सेट किए गए तापमान की रेंज में, क्रॉस-ऐक्सिस की संवेदनशीलता < 4.0 % और क्रॉस-ऐक्सिस की संवेदनशीलता के बदलाव 0.3% से कम होनी चाहिए.

• [C-2-4] ज़रूरी है कि TYPE_GYROSCOPE_UNCALIBRATED में, TYPE_GYROSCOPE जैसी क्वालिटी की शर्तें हों.

• [C-2-5] ऐसा TYPE_GEOMAGNETIC_FIELD सेंसर होना चाहिए जो:

  • तापमान मापने की रेंज कम से कम -900 और +900 μT के बीच होनी चाहिए.
  • रिज़ॉल्यूशन कम से कम 5 LSB/uT होना चाहिए.
  • तापमान मापने की फ़्रीक्वेंसी कम से कम 5 हर्ट्ज़ या इससे कम होनी चाहिए.
  • तापमान मापने की फ़्रीक्वेंसी ज़्यादा से ज़्यादा 50 हर्ट्ज़ या इससे ज़्यादा होनी चाहिए.
  • तापमान मापने वाला नॉइज़ 0.5 uT से ज़्यादा नहीं होना चाहिए.

• [C-2-6] TYPE_MAGNETIC_FIELD_UNCALIBRATED में, TYPE_GEOMAGNETIC_FIELD जैसी क्वालिटी ज़रूरी शर्तें पूरी होनी चाहिए. इसके अलावा:

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

• [C-2-7] ऐसा TYPE_PRESSURE सेंसर होना चाहिए जो:

  • इसकी मेज़रमेंट रेंज कम से कम 300 से 1100 hPa के बीच होनी चाहिए.
  • रिज़ॉल्यूशन कम से कम 80 LSB/hPa होना चाहिए.
  • तापमान मापने की फ़्रीक्वेंसी कम से कम 1 हर्ट्ज़ या इससे कम होनी चाहिए.
  • तापमान मापने की फ़्रीक्वेंसी ज़्यादा से ज़्यादा 10 हर्ट्ज़ या इससे ज़्यादा होनी चाहिए.
  • तापमान मापने के लिए नॉइज़, 2 Pa/withHz से ज़्यादा नहीं होनी चाहिए.
  • इस सेंसर को चालू न करने की सुविधा का इस्तेमाल करना ज़रूरी है. इसमें कम से कम 300 सेंसर इवेंट की बफ़रिंग की सुविधा होनी चाहिए.
  • बैच में ऊर्जा की खपत दो मिलीवाट से कम नहीं होनी चाहिए.
• [C-2-8] TYPE_GAME_ROTATION_VECTOR सेंसर होना चाहिए.
• [C-2-9] ऐसा TYPE_SIGNIFICANT_MOTION सेंसर होना चाहिए जो:
  • अगर डिवाइस स्टैटिक हो, तो उसमें ऊर्जा की खपत 0.5 मिलीवाट से ज़्यादा न हो. साथ ही, जब डिवाइस को हिलाया जा रहा हो, तो उसमें ऊर्जा की खपत 1.5 मिलीवाट से ज़्यादा न हो.
• [C-2-10] ऐसा TYPE_STEP_DETECTOR सेंसर होना चाहिए जो:
  • इस सेंसर को चालू न करने की सुविधा का इस्तेमाल करना ज़रूरी है. इसमें कम से कम 100 सेंसर इवेंट की बफ़रिंग की सुविधा होनी चाहिए.
  • अगर डिवाइस स्टैटिक हो, तो उसमें ऊर्जा की खपत 0.5 मिलीवाट से ज़्यादा न हो. साथ ही, जब डिवाइस को हिलाया जा रहा हो, तो उसमें ऊर्जा की खपत 1.5 मिलीवाट से ज़्यादा न हो.
  • बैच में ऊर्जा की खपत 4 मिलीवाट से कम नहीं होनी चाहिए.
• [C-2-11] ऐसा TYPE_STEP_COUNTER सेंसर होना चाहिए जो:
  • अगर डिवाइस स्टैटिक हो, तो उसमें ऊर्जा की खपत 0.5 मिलीवाट से ज़्यादा न हो. साथ ही, जब डिवाइस को हिलाया जा रहा हो, तो उसमें ऊर्जा की खपत 1.5 मिलीवाट से ज़्यादा न हो.
• [C-2-12] ऐसा TILT_DETECTOR सेंसर होना चाहिए जो:
  • अगर डिवाइस स्टैटिक हो, तो उसमें ऊर्जा की खपत 0.5 मिलीवाट से ज़्यादा न हो. साथ ही, जब डिवाइस को हिलाया जा रहा हो, तो उसमें ऊर्जा की खपत 1.5 मिलीवाट से ज़्यादा न हो.
• [C-2-13] एक्सलरोमीटर, जाइरोस्कोप, और मैग्नेटोमीटर की ओर से रिपोर्ट की गई एक ही शारीरिक घटना के इवेंट का टाइमस्टैंप, एक-दूसरे से 2.5 मिलीसेकंड के अंदर होना चाहिए. एक्सलरोमीटर और जाइरोस्कोप से रिपोर्ट किए गए, एक ही असल इवेंट का इवेंट टाइमस्टैंप एक-दूसरे से 0.25 मिलीसेकंड के अंदर होना चाहिए.
• [C-2-14] जाइरोस्कोप सेंसर, इवेंट टाइमस्टैंप और कैमरा सबसिस्टम एक ही समय पर होने चाहिए. साथ ही, गड़बड़ी होने पर 1 मिलीसेकंड के अंदर होने चाहिए.
• [C-2-15] ऊपर दिए गए किसी भी फ़िज़िकल सेंसर पर ऐप्लिकेशन के डेटा उपलब्ध होने पर, 5 मिलीसेकंड के अंदर ऐप्लिकेशन को सैंपल डिलीवर करना ज़रूरी है.
• [C-2-16] डिवाइस के स्टैटिक होने पर 0.5 मिलीवाट से ज़्यादा बिजली की खपत नहीं होनी चाहिए. साथ ही, इन सेंसर का कोई भी कॉम्बिनेशन चालू होने पर 2.0 मिलीवाट से ज़्यादा बिजली की खपत नहीं होनी चाहिए:
  • SENSOR_TYPE_SIGNIFICANT_MOTION
  • SENSOR_TYPE_STEP_DETECTOR
  • SENSOR_TYPE_STEP_COUNTER
  • SENSOR_TILT_DETECTORS
• [C-2-17] इसमें TYPE_PROXIMITY सेंसर हो सकता है. हालांकि, अगर मौजूद है, तो कम से कम 100 सेंसर इवेंट की बफ़र क्षमता होना ज़रूरी है.

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

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

• [C-3-1] isDirectChannelTypeSupported और getHighestDirectReportRateLevel एपीआई का इस्तेमाल करके, डायरेक्ट चैनल टाइप और डायरेक्ट रिपोर्ट की दरों के साथ काम करने की सही जानकारी देना ज़रूरी है.
• [C-3-2] सेंसर डायरेक्ट चैनल के साथ काम करने वाले सभी सेंसर के लिए, दो सेंसर टाइप में से कम से कम एक को काम करना ज़रूरी है.
  • TYPE_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE
• इस तरह के प्राइमरी सेंसर (नॉन-वेकअप वैरिएंट) के लिए, सेंसर डायरेक्ट चैनल से इवेंट की रिपोर्टिंग की सुविधा काम करनी चाहिए:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. बायोमेट्रिक सेंसर

बायोमेट्रिक अनलॉक की सुरक्षा को मापने के बारे में ज़्यादा जानने के लिए, कृपया बायोमेट्रिक सुरक्षा को मेज़र करने से जुड़ा दस्तावेज़ देखें.

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

• इसमें बायोमेट्रिक सेंसर शामिल होना चाहिए

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

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

• [C-0-1] इस दस्तावेज़ में दी गई मज़बूत या कमज़ोर बायोमेट्रिक की ज़रूरी शर्तों को पूरा करना ज़रूरी है.

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

• [C-0-2] इस दस्तावेज़ में बताई गई Strong की ज़रूरी शर्तों को पूरा करना ज़रूरी है.

इनके अलावा:

• [C-0-3] अगर मज़बूत बायोमेट्रिक पैसिव है, तो पुष्टि करने की किसी कार्रवाई (जैसे, बटन दबाना) के साथ उसे जोड़ना ज़रूरी है. उदाहरण के लिए, ऐसा चेहरा या आइरिस, जहां उपयोगकर्ता के सवाल का साफ़ तौर पर कोई सिग्नल मौजूद न हो.
  • [C-SR] पैसिव बायोमेट्रिक्स के लिए, पुष्टि करने की कार्रवाई को इस तरह सुरक्षित करने का बहुत ज़्यादा सुझाव दिया जाता है कि कोई ऑपरेटिंग सिस्टम या कर्नेल से छेड़छाड़ न की जा सके. उदाहरण के लिए, इसका मतलब है कि फ़िज़िकल बटन पर आधारित 'पुष्टि करने की कार्रवाई' को सुरक्षित एलिमेंट (एसई) के इनपुट-ओनली इनपुट/आउटपुट (GPIO) पिन से रूट किया जाता है. यह पिन, बटन दबाने के बजाय किसी और तरीके से नहीं चलाया जा सकता.

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

• [C-1-1] गलतफ़हमी की दर 0.002% से कम होनी चाहिए.
• [C-1-2] यह बताना ज़रूरी है कि यह मोड, किसी मुश्किल पिन, पैटर्न या पासवर्ड के मुकाबले कम सुरक्षित हो सकता है. साथ ही, अगर झूठे नाम से मेल भेजने और दूसरों को गुमराह करने वाले विज्ञापनों को स्वीकार करने की दर 7% से ज़्यादा है, तो इसे चालू करने के जोखिमों के बारे में साफ़ तौर पर बताना ज़रूरी है.
• [C-1-3] बायोमेट्रिक वेरिफ़िकेशन के लिए, गलत तरीके से पांच बार जांच करने के बाद, कम से कम 30 सेकंड के लिए रेट लिमिट को बढ़ा देना ज़रूरी है. गलत जांच का मतलब है कि सही कैप्चर क्वालिटी (BIOMETRIC_ACQUIRED_GOOD) की गई हो, जो रजिस्टर किए गए बायोमेट्रिक्स से मैच न करती हो.
• [C-1-4] उपयोगकर्ता से मौजूदा पुष्टि की पुष्टि कराए बिना या टीईई के सुरक्षित किए गए नए डिवाइस क्रेडेंशियल (पिन/पैटर्न/पासवर्ड) को जोड़कर, नए बायोमेट्रिक्स जोड़ने से बचना चाहिए. ऐसा करने के लिए, Android ओपन सोर्स प्रोजेक्ट को लागू करने का तरीका फ़्रेमवर्क में बताया गया है.
• [C-1-5] उपयोगकर्ता का खाता हटाए जाने पर, उसकी पहचान ज़ाहिर करने वाले बायोमेट्रिक डेटा को पूरी तरह से हटा देना चाहिए. इसमें फ़ैक्ट्री रीसेट करना भी शामिल है.
• [C-1-6] उस बायोमेट्रिक के लिए, अलग-अलग फ़्लैग का पालन करना ज़रूरी है (जैसे, DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE या DevicePolicymanager.KEYGUARD_DISABLE_IRIS ).
• [C-1-7] Android 10 के साथ लॉन्च होने वाले नए डिवाइसों के लिए, हर 24 घंटे या इससे कम समय में, उपयोगकर्ता को पुष्टि करने के लिए सुझाए गए तरीके (जैसे कि पिन, पैटर्न, पासवर्ड) के लिए चुनौती देनी होगी. यह समस्या, Android के पुराने वर्शन से अपग्रेड किए जाने वाले डिवाइसों पर, हर 72 घंटे में एक बार या इससे कम की होनी चाहिए.

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

  • चार घंटे तक इस्तेमाल न होने पर टाइम आउट की अवधि, या
  • बायोमेट्रिक तरीके से पुष्टि करने की तीन कोशिशें सफल नहीं रहीं.
  • डिवाइस के क्रेडेंशियल की पुष्टि होने के बाद, कुछ समय तक इस्तेमाल में न होने की समयसीमा और पुष्टि न हो पाने की संख्या को रीसेट कर दिया जाता है.

  Android के पुराने वर्शन वाले डिवाइसों को अपग्रेड करने पर, उन्हें C-1-8 से छूट दी जा सकती है.

• [सी-एसआर] का सुझाव दिया जाता है कि अस्वीकार किए जाने की दर 10% से कम हो, जैसा कि डिवाइस पर मापा गया है.

• [सी-एसआर] इस बात पर काफ़ी ध्यान दिया जाता है कि हर बायोमेट्रिक के लिए, यह इंतज़ार का समय एक सेकंड से कम रखें. बायोमेट्रिक की पहचान होने से लेकर स्क्रीन अनलॉक होने तक, इस अवधि को मापा जाता है.

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

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

• [C-2-8] ज़रूरी है कि आपके पास एक सुरक्षित प्रोसेसिंग पाइपलाइन हो, जैसे कि ऑपरेटिंग सिस्टम या कर्नेल छेड़छाड़ से उपयोगकर्ता के तौर पर गलत तरीके से पुष्टि करने के लिए डेटा सीधे इंजेक्ट न किया जा सके.

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

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

• [C-3-1] ऊपर बताई गई कमज़ोर शर्तों को पूरा करना ज़रूरी है. Android के पुराने वर्शन से अपग्रेड किए गए डिवाइसों को C-2-7 पर छूट नहीं दी जाती.
• [C-3-2] स्पूफ़ और इंपोस्टर के ज़रिए पेमेंट स्वीकार करने की दर 7% से ज़्यादा नहीं होनी चाहिए.
• [C-3-3] हर 72 घंटे में एक बार, उपयोगकर्ता को पुष्टि करने के लिए सुझाए गए मुख्य तरीके (जैसे, पिन, पैटर्न, पासवर्ड) के लिए चुनौती देनी होगी.

7.3.12. पोज़ सेंसर

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

• इसमें 6 डिग्री फ़्रीडम सेंसर हो सकता है.

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

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

7.4. डेटा कनेक्टिविटी

7.4.1. टेलीफ़ोनी

Android API में इस्तेमाल की जाने वाली “Telephony की” और इस दस्तावेज़ में खास तौर पर, वॉइस कॉल करने और GSM या CDMA नेटवर्क के ज़रिए मैसेज (एसएमएस) भेजने से जुड़े हार्डवेयर के बारे में बताया गया है. भले ही ये वॉइस कॉल पैकेट-स्विच किए गए हों या नहीं, ये Android के लिए हैं, जिन्हें एक ही नेटवर्क का इस्तेमाल करके लागू किया जा सकने वाला किसी भी डेटा कनेक्टिविटी से अलग माना जाता है. दूसरे शब्दों में कहें, तो Android की “टेलीफ़ोनी” सुविधा और एपीआई, खास तौर पर वॉइस कॉल और मैसेज (एसएमएस) के लिए हैं. उदाहरण के लिए, ऐसे डिवाइस जिन पर कॉल करने या मैसेज (एसएमएस) भेजने/पाने की सुविधा काम नहीं करती है, उन्हें टेलीफ़ोनी डिवाइस नहीं माना जाता है. भले ही, वे डेटा कनेक्टिविटी के लिए मोबाइल नेटवर्क का इस्तेमाल करते हों या नहीं.

• Android का इस्तेमाल उन डिवाइसों पर किया जा सकता है जिनमें टेलीफ़ोनी हार्डवेयर शामिल नहीं है. इसका मतलब है कि Android उन डिवाइसों पर काम करता है जो फ़ोन नहीं हैं.

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

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

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

• [C-2-1] सभी एपीआई को नो-ऑपरेशन के तौर पर लागू करना ज़रूरी है.

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

• [C-3-1] EuiccManager API को पूरी तरह लागू करना ज़रूरी है.

7.4.1.1. नंबर ब्लॉक करने की सुविधा के साथ काम करना

अगर लागू किए गए डिवाइस पर android.hardware.telephony feature की रिपोर्ट मिलती है, तो:

• [C-1-1] नंबर ब्लॉक करने की सुविधा शामिल होनी चाहिए
• [C-1-2] BlockedNumberContract और इससे जुड़े एपीआई को पूरी तरह से लागू करना ज़रूरी है, जैसा कि SDK टूल के दस्तावेज़ में बताया गया है.
• [C-1-3] आपको 'BlockNumberProvider' पर मौजूद फ़ोन नंबर से आने वाले सभी कॉल और मैसेज को ब्लॉक करना होगा. इसके लिए, ऐप्लिकेशन से कोई इंटरैक्शन नहीं करना होगा. इसमें सिर्फ़ तब अपवाद हो सकता है, जब नंबर ब्लॉक करने की सुविधा को कुछ समय के लिए हटा दिया जाए, जैसा कि SDK टूल के दस्तावेज़ में बताया गया है.
• [C-1-4] ब्लॉक किए गए कॉल के लिए, प्लैटफ़ॉर्म कॉल लॉग की सेवा देने वाली कंपनी को जवाब नहीं देना चाहिए.
• [C-1-5] ब्लॉक किए गए मैसेज के लिए, Telephony की सेवाएं देने वाली कंपनी को जवाब नहीं देना चाहिए.
• [C-1-6] ब्लॉक किए गए नंबर मैनेजमेंट यूज़र इंटरफ़ेस (यूआई) को लागू करना ज़रूरी है, जिसे TelecomManager.createManageBlockedNumbersIntent() तरीके से दिखाए गए इंटेंट के साथ खोला जाता है.
• [C-1-7] सेकंडरी उपयोगकर्ताओं को डिवाइस पर ब्लॉक किए गए नंबर देखने या उनमें बदलाव करने की अनुमति नहीं देनी चाहिए, क्योंकि Android प्लैटफ़ॉर्म यह मानता है कि मुख्य उपयोगकर्ता के पास डिवाइस पर टेलीफ़ोनी सेवाओं का पूरा कंट्रोल होगा. ब्लॉक करने से जुड़े सभी यूज़र इंटरफ़ेस (यूआई) को सेकंडरी उपयोगकर्ताओं के लिए छिपाया जाना चाहिए. साथ ही, ब्लॉक की गई सूची को अब भी ध्यान में रखा जाना चाहिए.
• जब कोई डिवाइस Android 7.0 पर अपडेट होता है, तो ब्लॉक किए गए नंबरों को सेवा देने वाली कंपनी में माइग्रेट करना चाहिए.

7.4.1.2. टेलीकॉम एपीआई

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

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

• [सी-एसआर] का सुझाव दिया जाता है, ताकि उपयोगकर्ता को यह सूचना दी जा सके कि इनकमिंग कॉल का जवाब देने से मौजूदा कॉल छूट जाएगा.

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

• [C-SR] का इस बात पर बहुत ध्यान दिया जाता है कि उस डिफ़ॉल्ट डायलर ऐप्लिकेशन को पहले से लोड किया जाए जो अपने कॉल लॉग में कॉल लॉग एंट्री और तीसरे पक्ष के ऐप्लिकेशन का नाम दिखाता है. ऐसा तब होता है, जब तीसरे पक्ष का ऐप्लिकेशन अपने PhoneAccount पर, EXTRA_LOG_SELF_MANAGED_CALLS की अतिरिक्त कुंजी को true पर सेट करता है.

• [सी-एसआर] हमारा सुझाव है कि android.telecom एपीआई के लिए, ऑडियो हेडसेट के KEYCODE_MEDIA_PLAY_PAUSE और KEYCODE_HEADSETHOOK इवेंट को मैनेज करने के लिए, यहां दिया गया तरीका अपनाएं:
  • किसी चल रहे कॉल के दौरान, मुख्य इवेंट को थोड़ी देर दबाकर रखने पर Connection.onDisconnect() को कॉल करें.
  • जब किसी इनकमिंग कॉल के दौरान मुख्य इवेंट को थोड़ी देर दबाए रखने का पता चलता है, तो Connection.onAnswer() को कॉल करें.
  • जब किसी इनकमिंग कॉल के दौरान मुख्य इवेंट को दबाकर रखने का पता चलता है, तब Connection.onReject() को कॉल करें.
  • CallAudioState की म्यूट स्थिति को टॉगल करें.

7.4.2. आईईईई 802.11 (वाई-फ़ाई)

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

• इसमें 802.11 के एक या उससे ज़्यादा फ़ॉर्म के लिए सहायता शामिल होनी चाहिए.

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

• [C-1-1] संबंधित Android API को लागू करना ज़रूरी है.
• [C-1-2] हार्डवेयर फ़ीचर फ़्लैग android.hardware.wifi की रिपोर्ट करना ज़रूरी है.
• [C-1-3] SDK टूल के दस्तावेज़ में बताया गया तरीका अपनाकर, multicast API को लागू करना ज़रूरी है.
• [C-1-4] इस्तेमाल करते समय, मल्टीकास्ट डीएनएस (एमडीएनएस) के साथ काम करना ज़रूरी है. साथ ही, इसे किसी भी समय mडीएनएस पैकेट (224.0.0.251) को फ़िल्टर नहीं करना चाहिए. इसमें ये चीज़ें भी शामिल हैं:
  • भले ही, स्क्रीन ऐक्टिव न हो.
  • स्टैंडबाय पावर की स्थिति में होने पर भी, Android Television डिवाइस पर लागू करने के लिए.
• [C-1-5] WifiManager.enableNetwork() एपीआई तरीके से किए गए कॉल को, मौजूदा चालू Network को स्विच करने के लिए ज़रूरी संकेत के तौर पर नहीं मानना चाहिए. इसे ऐप्लिकेशन ट्रैफ़िक के लिए, डिफ़ॉल्ट रूप से इस्तेमाल किया जाता है और ConnectivityManager एपीआई के तरीकों, जैसे getActiveNetwork और registerDefaultNetworkCallback से दिखाया जाता है. दूसरे शब्दों में, अगर वे यह पुष्टि कर लेते हैं कि वाई-फ़ाई नेटवर्क इंटरनेट ऐक्सेस दे रहा है, तो वे नेटवर्क की सेवा देने वाली किसी अन्य कंपनी (जैसे, मोबाइल डेटा) से मिली इंटरनेट ऐक्सेस को सिर्फ़ बंद कर सकते हैं.
• [C-1-6] ConnectivityManager.reportNetworkConnectivity() एपीआई को कॉल करने पर, Network पर इंटरनेट के ऐक्सेस का फिर से आकलन करने का सुझाव दिया जाता है. जब जांच से यह पता चल जाए कि मौजूदा Network अब इंटरनेट का ऐक्सेस नहीं देता है, तो ऐसे किसी भी अन्य उपलब्ध नेटवर्क (जैसे कि मोबाइल डेटा) का इस्तेमाल करें जो इंटरनेट का ऐक्सेस देता हो.
• [C-SR] का सुझाव दिया जाता है कि एसटीए के डिसकनेक्ट होने पर, सोर्स मैक पते और जांच अनुरोध फ़्रेम की क्रम संख्या को किसी भी क्रम में लगाएं.
  • जांच के अनुरोध वाले फ़्रेम के हर ग्रुप में एक स्कैन होना चाहिए. एक जैसे MAC पते का इस्तेमाल करना चाहिए (स्कैन के बीच में MAC पते को किसी भी क्रम में नहीं बदला जाना चाहिए).
  • जांच के अनुरोध का क्रम संख्या, स्कैन में जांच के अनुरोधों के बीच सामान्य (एक क्रम में) बार-बार होनी चाहिए.
  • जांच के अनुरोध का क्रम संख्या, स्कैन के आखिरी जांच अनुरोध और अगले स्कैन के पहले जांच अनुरोध के बीच किसी भी क्रम में होनी चाहिए.
• [C-SR] का बहुत ज़्यादा सुझाव दिया जाता है, जबकि STA को डिसकनेक्ट किया जाता है. ऐसा इसलिए किया जाता है, ताकि जांच के अनुरोध के फ़्रेम में सिर्फ़ नीचे दिए गए एलिमेंट को अनुमति दी जा सके:
  • SSID पैरामीटर सेट (0)
  • DS पैरामीटर सेट (3)

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

• [C-3-1] जब भी किसी ऐप्लिकेशन को WifiManager.createWifiLock() और WifiManager.WifiLock.acquire() एपीआई के ज़रिए WIFI_MODE_FULL_HIGH_PERF लॉक या WIFI_MODE_FULL_LOW_LATENCY लॉक मिलता है और लॉक चालू होता है, तो वाई-फ़ाई पावर सेव मोड को बंद करना ज़रूरी है.
• [C-3-2] अगर वाई-फ़ाई लो-लेटेंसी लॉक (WIFI_MODE_FULL_LOW_LATENCY) मोड में है, तो डिवाइस और ऐक्सेस पॉइंट के बीच दोतरफ़ा यात्रा का औसत समय, वाई-फ़ाई हाई परफ़ेक्ट लॉक (WIFI_MODE_FULL_HIGH_PERF) मोड में लगने वाले इंतज़ार के समय से कम होना चाहिए.
• [C-SR] का खास तौर पर सुझाव दिया जाता है, ताकि जब लो-लेटेंसी लॉक (WIFI_MODE_FULL_LOW_LATENCY) हासिल हो जाए और वह लागू हो जाए, तो वाई-फ़ाई की दोतरफ़ा यात्रा में लगने वाला समय कम किया जा सके.

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

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

7.4.2.1. Wi-Fi Direct

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

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

अगर लागू किए गए डिवाइस में Wi-Fi Direct के साथ काम करने की सुविधा शामिल है, तो ये काम किए जा सकते हैं:

• [C-1-1] SDK टूल के दस्तावेज़ में बताए गए तरीके के मुताबिक, मिलते-जुलते Android API को लागू करना ज़रूरी है.
• [C-1-2] हार्डवेयर की सुविधा android.hardware.wifi.direct की रिपोर्ट करना ज़रूरी है.
• [C-1-3] ज़रूरी है कि सामान्य वाई-फ़ाई काम किया जा सके.
• [C-1-4] ज़रूरी है कि एक ही समय में वाई-फ़ाई और वाई-फ़ाई डायरेक्ट की सुविधाएं काम करें.

7.4.2.2. वाई-फ़ाई टनल किया गया डायरेक्ट लिंक सेटअप

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

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

अगर डिवाइसों को लागू करने के लिए, WiFiManager API की मदद से TDLS और TDLS के साथ काम करना शामिल है, तो ये:

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

7.4.2.3. वाई-फ़ाई अवेयर

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

• वाई-फ़ाई अवेयर के लिए सहायता शामिल होनी चाहिए.

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

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

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

• [C-2-1] जगह की जानकारी का पता लगाने वाले एपीआई को लागू करना ज़रूरी है: setRangingEnabled, setMin FitbitMm, setMax बावजूदMm , और onServiceDiscoveredWithRange.

7.4.2.4. वाई-फ़ाई पासपॉइंट

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

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

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

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

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

• [C-2-1] पासपॉइंट से जुड़े WifiManager एपीआई को लागू करने पर, UnsupportedOperationException देना ज़रूरी है.

7.4.2.5. वाई-फ़ाई की जगह की जानकारी (वाई-फ़ाई से यात्रा का समय - आरटीटी)

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

• इसमें वाई-फ़ाई की जगह की जानकारी के लिए सहायता शामिल होनी चाहिए.

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

• [C-1-1] SDK टूल के दस्तावेज़ में बताया गया तरीका अपनाकर, WifiRttManager एपीआई को लागू करना ज़रूरी है.
• [C-1-2] android.hardware.wifi.rtt फ़ीचर फ़्लैग का एलान करना ज़रूरी है.
• [C-1-3] हर उस आरटीटी बर्स्ट के लिए सोर्स MAC पते को किसी भी क्रम में लगाना ज़रूरी है जिसे तब एक्ज़ीक्यूट किया जाता है, जब आरटीटी जिस वाई-फ़ाई इंटरफ़ेस पर चलाया जाता है वह किसी ऐक्सेस पॉइंट से जुड़ा न हो.

7.4.2.6. वाई-फ़ाई कीपअलाइव ऑफ़लोड

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

• वाई-फ़ाई कीपअलाइव ऑफ़लोड के लिए समर्थन शामिल होना चाहिए.

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

• [C-1-1] SocketKeepAlive एपीआई के साथ काम करना ज़रूरी है.

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

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

• [C-2-1] ERROR_UNSUPPORTED को वापस करना होगा.

7.4.2.7. वाई-फ़ाई ईज़ी कनेक्ट (डिवाइस प्रॉविज़निंग प्रोटोकॉल)

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

• इसमें वाई-फ़ाई ईज़ी कनेक्ट (डीपीपी) के लिए सहायता शामिल होनी चाहिए.

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

• [C-1-1] SDK टूल के दस्तावेज़ में बताए गए तरीके के मुताबिक, Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI इंटेंट एपीआई को लागू करना ज़रूरी है.
• [C-1-2] WifiManager#isEasyConnectSupported() तरीके से true को रिटर्न करना ज़रूरी है.

7.4.3. ब्लूटूथ

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

• यह बेहतर ऑडियो कोडेक और ब्लूटूथ ऑडियो कोडेक (जैसे, LDAC) के साथ काम करना चाहिए.

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

• कनेक्ट किए गए कम से कम पांच डिवाइसों पर काम करना चाहिए.

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

• [C-1-1] ब्लूटूथ 4.2 और ब्लूटूथ LE डेटा लेंट एक्सटेंशन के साथ काम करना ज़रूरी है.

Android में ब्लूटूथ और ब्लूटूथ स्मार्ट की सुविधा शामिल है.

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

• [C-2-1] प्लैटफ़ॉर्म के लिए काम की सुविधाओं (क्रम के हिसाब से android.hardware.bluetooth और android.hardware.bluetooth_le) का एलान करना और प्लैटफ़ॉर्म एपीआई लागू करना ज़रूरी है.
• डिवाइस के लिए ज़रूरी ब्लूटूथ प्रोफ़ाइल, जैसे कि A2DP, AVRCP, OBEX, HFP वगैरह का इस्तेमाल करना चाहिए.

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

• [C-3-1] हार्डवेयर की सुविधा android.hardware.bluetooth_le के बारे में बताना ज़रूरी है.
• [C-3-2] SDK टूल के दस्तावेज़ और android.ब्लूटूथ में दी गई जानकारी के मुताबिक, GATT (जेनरिक एट्रिब्यूट प्रोफ़ाइल) आधारित ब्लूटूथ एपीआई चालू करना ज़रूरी है.
• [C-3-3] BluetoothAdapter.isOffloadedFilteringSupported() की सही वैल्यू रिपोर्ट करनी होगी. इससे यह पता चलेगा कि ScanFilter एपीआई क्लास के लिए, फ़िल्टर करने का लॉजिक लागू किया गया है या नहीं.
• [C-3-4] BluetoothAdapter.isMultipleAdvertisementSupported() के लिए सही वैल्यू की रिपोर्ट करना ज़रूरी है. इससे यह पता चलेगा कि कम ऊर्जा से चलने वाले विज्ञापन दिखाए जा सकते हैं या नहीं.
• ScanFilter API को लागू करते समय, फ़िल्टर करने वाले लॉजिक को ब्लूटूथ चिपसेट पर ऑफ़लोड करने की सुविधा दी जानी चाहिए.
• बैच में स्कैन करने की सुविधा को ब्लूटूथ चिपसेट पर ऑफ़लोड करने की सुविधा दी जानी चाहिए.

• इसमें कम से कम चार स्लॉट वाले एक से ज़्यादा विज्ञापन दिखाए जा सकते हैं.

• [SR] रिज़ॉल्व किए जा सकने वाले निजी पते (आरपीए) का टाइम आउट 15 मिनट से ज़्यादा न लागू करने का सुझाव दिया जाता है. साथ ही, उपयोगकर्ता की निजता को सुरक्षित रखने के लिए, टाइम आउट पर पते को रोटेट करें.

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

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

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

• [C-5-1] BluetoothAdapter.getProfileProxy(context, Listener, BluetoothProfile.HEARING_AID) के लिए true वापस करना ज़रूरी है.

7.4.4. नियर-फ़ील्ड कम्यूनिकेशंस

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

• नियर-फ़ील्ड कम्यूनिकेशंस (एनएफ़सी) के लिए, ट्रांससीवर और उससे जुड़ा हार्डवेयर होना चाहिए.
• [C-0-1] android.nfc.NdefMessage और android.nfc.NdefRecord एपीआई को लागू करना ज़रूरी है. भले ही, उनमें एनएफ़सी की सुविधा शामिल न हो या android.hardware.nfc सुविधा का एलान न किया गया हो, क्योंकि क्लास, प्रोटोकॉल-इंडिपेंडेंट डेटा प्रज़ेंटेशन फ़ॉर्मैट को दिखाती हैं.

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

• [C-1-1] android.content.pm.PackageManager.hasSystemFeature() तरीके का इस्तेमाल करके, android.hardware.nfc सुविधा की शिकायत करना ज़रूरी है.
• ज़रूरी है कि वह इन एनएफ़सी स्टैंडर्ड का इस्तेमाल करके, एनडीईएफ़ मैसेज पढ़ और लिख सके:
• [C-1-2] ज़रूरी है कि आपके पास एनएफ़सी फ़ोरम में पढ़ने वाले/लेखक के तौर पर काम करने की अनुमति हो. यह जानकारी, एनएफ़सी फ़ोरम की तकनीकी जानकारी एनएफ़सीफ़ोरम-टीएस-डिजिटलप्रोटोकॉल-1.0 के मुताबिक, इन एनएफ़सी मानकों के मुताबिक होनी चाहिए:
  • एनएफ़सीए (ISO14443-3A)
  • एनएफ़सीबी (आईएसओ14443-3बी)
  • एनएफ़सीएफ़ (जेआईएस X 6319-4)
  • IsoDep (आईएसओ 14443-4)
  • एनएफ़सी फ़ोरम टैग टाइप 1, 2, 3, 4, 5 (एनएफ़सी फ़ोरम की ओर से तय किया गया है)

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

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

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

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

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

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

• [C-2-1] android.hardware.nfc.hce सुविधा के कॉन्स्टेंट की जानकारी देना ज़रूरी है.
• [C-2-2] Android SDK में बताए गए तरीके के मुताबिक, एनएफ़सी एचसीई एपीआई के साथ काम करना ज़रूरी है.

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

• [C-3-1] android.hardware.nfc.hcef सुविधा के कॉन्स्टेंट की रिपोर्ट करना ज़रूरी है.
• [C-3-2] Android SDK में बताए गए तरीके के मुताबिक, NfcF Card Emulation API को लागू करना ज़रूरी है.

अगर इस सेक्शन में बताए गए, डिवाइस इस्तेमाल करने के तरीके में सामान्य एनएफ़सी की सुविधा शामिल है और वे MIFARE टेक्नोलॉजी (MIFARE क्लासिक, MIFARE Ultralight, MIFARE क्लासिक पर NDEF) की भूमिका को रीडर/राइटर की भूमिका में इस्तेमाल करते हैं, तो वे:

• [C-4-1] Android SDK के बताए गए दस्तावेज़ के मुताबिक, इनसे जुड़े Android APIs को लागू करना ज़रूरी है.
• [C-4-2] android.content.pm.PackageManager.hasSystemFeature() तरीके का इस्तेमाल करके, com.nxp.mifare सुविधा की शिकायत करना ज़रूरी है. ध्यान दें कि यह Android का स्टैंडर्ड फ़ीचर नहीं है. इसलिए, यह android.content.pm.PackageManager क्लास में कॉन्सटेंट के तौर पर नहीं दिखता.

7.4.5. नेटवर्क की कम से कम क्षमता

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

• [C-0-1] डेटा नेटवर्किंग के एक या इससे ज़्यादा तरीकों के लिए सहायता शामिल करना ज़रूरी है. खास तौर पर, डिवाइस लागू करने के लिए 200 केबिट/सेकंड या इससे ज़्यादा वाले कम से कम एक स्टैंडर्ड डेटा के लिए सहायता शामिल होनी चाहिए. इस ज़रूरी शर्त को पूरा करने वाली टेक्नोलॉजी के उदाहरणों में EDGE, HSPA, EV-DO, 802.11g, ईथरनेट और ब्लूटूथ पैन शामिल हैं.
• जब एक भौतिक नेटवर्किंग मानक (जैसे ईथरनेट) प्राथमिक डेटा कनेक्शन होता है, तो कम से कम एक सामान्य वायरलेस डेटा मानक, जैसे 802.11 (वाई-फ़ाई) के लिए समर्थन भी शामिल होना चाहिए.
• इसमें एक से ज़्यादा तरह की डेटा कनेक्टिविटी लागू की जा सकती है.
• [C-0-2] ज़रूरी है कि इसमें IPv6 नेटवर्किंग स्टैक शामिल हो. साथ ही, java.net.Socket और java.net.URLConnection जैसे मैनेज किए जा रहे एपीआई का इस्तेमाल करके, आईपीवी6 कम्यूनिकेशन की सुविधा के साथ-साथ AF_INET6 सॉकेट जैसे नेटिव एपीआई का इस्तेमाल करना ज़रूरी हो.
• [C-0-3] डिफ़ॉल्ट रूप से IPv6 चालू होना चाहिए.
• यह पक्का करना ज़रूरी है कि आईपीवी6 कम्यूनिकेशन, आईपीवी4 जितना ही भरोसेमंद हो. उदाहरण के लिए:
  • [C-0-4] बैटरी सेवर मोड में भी आईपीवी6 कनेक्टिविटी को बनाए रखना ज़रूरी है.
  • [C-0-5] रेट सीमित करने से आईपीवी6 के साथ काम करने वाले ऐसे नेटवर्क पर आईपीवी6 कनेक्टिविटी नहीं रहेगी जो कम से कम 180 सेकंड तक आरए लाइफ़टाइम का इस्तेमाल करता हो.
• [C-0-6] आईपीवी6 नेटवर्क से कनेक्ट होने पर, तीसरे पक्ष के ऐप्लिकेशन को नेटवर्क से सीधे आईपीवी6 कनेक्टिविटी की सुविधा देनी होगी. इसके लिए, डिवाइस पर स्थानीय रूप से किसी भी तरह का पता या पोर्ट ट्रांसलेशन नहीं करना होगा. मैनेज किए जा रहे दोनों एपीआई, जैसे कि Socket#getLocalAddress या Socket#getLocalPort) और getsockname() या IPV6_PKTINFO जैसे एनडीके एपीआई को वह आईपी पता और पोर्ट देना होगा जिसका इस्तेमाल नेटवर्क पर पैकेट भेजने और पाने के लिए किया जाता है.

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

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

• [C-1-1] वाई-फ़ाई पर ड्यूअल-स्टैक और IPv6-सिर्फ़ काम करने की सुविधा होनी चाहिए.

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

• [C-2-1] ईथरनेट पर ड्यूअल-स्टैक ऑपरेशन की सुविधा ज़रूरी है.

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

• मोबाइल नेटवर्क पर आईपीवी6 ऑपरेशन (सिर्फ़ IPv6 और ड्यूअल-स्टैक) पर काम करना चाहिए.

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

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

7.4.6. समन्वयन सेटिंग

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

• [C-0-1] मास्टर ऑटो-सिंक सेटिंग डिफ़ॉल्ट रूप से चालू होनी चाहिए, ताकि getMasterSyncAutomatically() तरीका “सही” दिखे.

7.4.7. डेटा बचाने वाला विकल्प

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

• डेटा बचाने की सेटिंग वाला मोड उपलब्ध कराने के लिए, [SR] का खास तौर पर सुझाव दिया जाता है.

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

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

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

• [C-2-1] ConnectivityManager.getRestrictBackgroundStatus() के लिए RESTRICT_BACKGROUND_STATUS_DISABLED वैल्यू देनी होगी
• [C-2-2] ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED को ब्रॉडकास्ट नहीं करना चाहिए.
• [C-2-3] ज़रूरी है कि आपके पास कोई ऐसी गतिविधि हो जो Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS इंटेंट को हैंडल करती हो, लेकिन उसे नो-ऑप के तौर पर लागू किया जा सकता हो.

7.4.8. सुरक्षा तत्व

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

• [C-1-1] android.se.omapi.SEService.getReaders() तरीके को कॉल करने पर, उपलब्ध सुरक्षा एलिमेंट रीडर की गिनती करना ज़रूरी है.

7.5. कैमरे

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

• [C-1-1] android.hardware.camera.any फ़ीचर फ़्लैग का एलान करना ज़रूरी है.
• [C-1-2] किसी ऐप्लिकेशन के लिए इस बात का ध्यान रखा जाना चाहिए कि वह डिवाइस में सबसे बड़े रिज़ॉल्यूशन वाले कैमरा सेंसर से तैयार की गई इमेज के साइज़ के बराबर तीन RGBA_8888 बिटमैप एक साथ तय कर सके, जबकि बुनियादी झलक के लिए कैमरा खुला हो और अभी भी कैप्चर किया जा रहा हो.
• [C-1-3] यह पक्का करना ज़रूरी है कि पहले से इंस्टॉल किए गए डिफ़ॉल्ट कैमरा ऐप्लिकेशन हैंडलिंग इंटेंट MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE या MediaStore.ACTION_VIDEO_CAPTURE की ज़िम्मेदारी इमेज के मेटाडेटा से उपयोगकर्ता की जगह की जानकारी हटाने की है. इसके बाद ही, उसे पाने वाले ऐप्लिकेशन में ACCESS_FINE_LOCATION भेजा जा सकता है.

7.5.1. पीछे वाला कैमरा

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

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

• इसमें पीछे वाला कैमरा होना चाहिए.

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

• [C-1-1] फ़ीचर फ़्लैग android.hardware.camera और android.hardware.camera.any की शिकायत करना ज़रूरी है.
• [C-1-2] इसका रिज़ॉल्यूशन कम से कम 2 मेगापिक्सल होना चाहिए.
• कैमरा ड्राइवर में या तो हार्डवेयर ऑटो-फ़ोकस लागू होना चाहिए या सॉफ़्टवेयर ऑटो-फ़ोकस होना चाहिए (ऐप्लिकेशन सॉफ़्टवेयर से पारदर्शी).
• इसमें फ़िक्स्ड-फ़ोकस या EDOF (फ़ील्ड की बढ़ाई गई डेप्थ) हार्डवेयर हो सकता है.
• इसमें फ़्लैश शामिल हो सकता है.

अगर कैमरे में फ़्लैश चालू है, तो:

• [C-2-1] कैमरे की झलक दिखाने वाली जगह पर, android.hardware.Camera.PreviewCallback के रजिस्टर होने के दौरान फ़्लैश लैंप की रोशनी नहीं होनी चाहिए, जब तक कि ऐप्लिकेशन ने Camera.Parameters ऑब्जेक्ट के FLASH_MODE_AUTO या FLASH_MODE_ON एट्रिब्यूट को चालू करके फ़्लैश को चालू न किया हो. ध्यान दें कि यह सीमा, डिवाइस में पहले से मौजूद सिस्टम के कैमरा ऐप्लिकेशन पर नहीं, बल्कि Camera.PreviewCallback का इस्तेमाल करने वाले सिर्फ़ तीसरे पक्ष के ऐप्लिकेशन पर लागू होती है.

7.5.2. सामने वाला कैमरा

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

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

• इसमें सामने वाला कैमरा हो सकता है.

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

• [C-1-1] फ़ीचर फ़्लैग android.hardware.camera.any और android.hardware.camera.front की शिकायत करना ज़रूरी है.
• [C-1-2] इसका रिज़ॉल्यूशन कम से कम VGA (640x480 पिक्सल) होना चाहिए.
• [C-1-3] Camera API के लिए, सामने वाले कैमरे को डिफ़ॉल्ट के तौर पर इस्तेमाल नहीं करना चाहिए. साथ ही, सामने वाले कैमरे को पीछे वाले डिफ़ॉल्ट कैमरे के तौर पर इस्तेमाल करने के लिए, एपीआई को कॉन्फ़िगर भी नहीं करना चाहिए. भले ही, डिवाइस में सिर्फ़ यही कैमरा हो.
• [C-1-4] जब मौजूदा ऐप्लिकेशन में साफ़ तौर पर अनुरोध किया गया हो कि कैमरा डिसप्ले को android.hardware.Camera.setDisplayOrientation() तरीके से घुमाने के लिए अनुरोध किया गया है, तो कैमरे की झलक, ऐप्लिकेशन में बताए गए ओरिएंटेशन के हिसाब से हॉरिज़ॉन्टल तौर पर मिरर की जानी चाहिए. इसके उलट, अगर मौजूदा ऐप्लिकेशन में साफ़ तौर पर यह अनुरोध नहीं किया गया है कि android.hardware.Camera.setDisplayOrientation() तरीके का इस्तेमाल करके कैमरे के डिसप्ले को बदलने का अनुरोध किया जाए, तो डिवाइस के डिफ़ॉल्ट हॉरिज़ॉन्टल ऐक्सिस पर झलक दिखेगी.
• [C-1-5] ऐप्लिकेशन के कॉलबैक में लौटाए गए या मीडिया स्टोरेज के लिए सेट की गई फ़ाइनल कैप्चर की गई स्टिल इमेज या वीडियो स्ट्रीम को मिरर नहीं करना चाहिए.
• [C-1-6] पोस्टव्यू में दिखाई गई इमेज की डुप्लीकेट इमेज का भी डुप्लीकेट वर्शन बनाना ज़रूरी है. इसके लिए, कैमरे की झलक वाली इमेज स्ट्रीम का इस्तेमाल किया जाता है.
• इसमें पीछे वाले कैमरों के लिए उपलब्ध सुविधाएं (जैसे कि ऑटो-फ़ोकस, फ़्लैश वगैरह) शामिल हो सकती हैं. इनके बारे में सेक्शन 7.5.1 में बताया गया है.

अगर डिवाइस लागू करने के तरीके को उपयोगकर्ता घुमा सकता है (जैसे कि एक्सलरोमीटर से अपने-आप या उपयोगकर्ता के इनपुट का इस्तेमाल करके, मैन्युअल तरीके से):

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

7.5.3. बाहरी कैमरा

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

• इसमें बाहरी कैमरे के साथ काम करने की सुविधा हो सकती है, जो ज़रूरी नहीं है कि हमेशा कनेक्ट हो.

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

• [C-1-1] प्लैटफ़ॉर्म की सुविधाओं के बारे में बताने वाले फ़्लैग android.hardware.camera.external और android.hardware camera.any के बारे में बताना ज़रूरी है.
• [C-1-2] अगर बाहरी कैमरा को यूएसबी होस्ट पोर्ट से कनेक्ट किया जाता है, तो यूएसबी वीडियो क्लास (यूवीसी 1.0 या उसके बाद के वर्शन) पर काम करना ज़रूरी है.
• [C-1-3] कैमरे के सीटीएस टेस्ट को पास करने के लिए, ज़रूरी है कि बाहरी कैमरा डिवाइस को कनेक्ट किया गया हो. कैमरे के सीटीएस टेस्टिंग के बारे में जानकारी source.android.com पर उपलब्ध है.
• अच्छी क्वालिटी वाली, बिना कोड वाली स्ट्रीम (जैसे, रॉ या अलग से कंप्रेस की गई इमेज स्ट्रीम) का ट्रांसफ़र चालू करने के लिए, MJPEG जैसे वीडियो कंप्रेस करने की सुविधा काम करनी चाहिए.
• शायद इसमें कई कैमरे काम कर सकते हैं.
• शायद इनमें कैमरा-आधारित वीडियो एन्कोडिंग की सुविधा काम करती है.

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

• [C-2-1] डिवाइस पर चलने वाले ऐप्लिकेशन के लिए, बिना एन्कोड वाली / MJPEG स्ट्रीम (QVGA या ज़्यादा रिज़ॉल्यूशन) को एक साथ ऐक्सेस करना ज़रूरी है.

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

कैमरा ऐक्सेस करने के लिए, Android में दो एपीआई पैकेज शामिल हैं. नया android.hardware.camera2 एपीआई, ऐप्लिकेशन में लो-लेवल कैमरा कंट्रोल दिखाता है. इसमें ज़ीरो-कॉपी बर्स्ट/स्ट्रीमिंग फ़्लो के साथ-साथ हर फ़्रेम के एक्सपोज़र, गेन, व्हाइट बैलेंस गेन, कलर कन्वर्ज़न, डिनॉइज़िंग, शार्पन वगैरह को कंट्रोल किया जाता है.

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

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

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

• [C-0-1] अगर किसी ऐप्लिकेशन ने कभी भी android.hardware.Camera.Parameters.setPreviewFormat(int) को कॉल नहीं किया है, तो ऐप्लिकेशन कॉलबैक को दिए गए प्रीव्यू डेटा के लिए android.hardware.PixelFormat.YCbCr_420_SP का इस्तेमाल करना ज़रूरी है.
• [C-0-2] जब कोई ऐप्लिकेशन किसी android.hardware.Camera.PreviewCallback इंस्टेंस को रजिस्टर करता है और सिस्टम, onPreviewFrame() तरीके को कॉल करता है, तो [C-0-2] को NV21 एन्कोडिंग फ़ॉर्मैट में होना चाहिए. झलक का फ़ॉर्मैट YCbCr_420_SP है, जो बाइट[] में मौजूद डेटा onPreviewFrame() में पास किया जाता है. इसका मतलब है कि NV21 को डिफ़ॉल्ट तौर पर सेट करना ज़रूरी है.
• [C-0-3] android.hardware.Camera के लिए, सामने और पीछे वाले, दोनों कैमरों में झलक देखने के लिए YV12 फ़ॉर्मैट (जैसा कि android.graphics.ImageFormat.YV12 कॉन्सटेंट में बताया गया है) पर काम करना ज़रूरी है. (हार्डवेयर वीडियो एन्कोडर और कैमरा किसी भी नेटिव पिक्सल फ़ॉर्मैट का इस्तेमाल कर सकता है, लेकिन डिवाइस को लागू करने के लिए YV12 फ़ॉर्मैट में काम करना ज़रूरी है.)
• [C-0-4] android.media.ImageReader एपीआई की मदद से, उन android.hardware.camera2 डिवाइसों के लिए आउटपुट के तौर पर android.hardware.ImageFormat.YUV_420_888 और android.hardware.ImageFormat.JPEG फ़ॉर्मैट के साथ काम करना ज़रूरी है जो android.request.availableCapabilities में REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE सुविधा का विज्ञापन करते हैं.
• [C-0-5] Android SDK के दस्तावेज़ में दिए गए, पूरे Camera API को लागू करना ज़रूरी है. भले ही, डिवाइस में हार्डवेयर ऑटोफ़ोकस या अन्य सुविधाएं मौजूद हों. उदाहरण के लिए, जिन कैमरों में ऑटोफ़ोकस नहीं है उन्हें रजिस्टर किए गए android.hardware.Camera.AutoFocusCallback इंस्टेंस को कॉल करना ज़रूरी है. हालांकि, यह उन कैमरे के लिए काम का नहीं है जो ऑटोफ़ोकस नहीं हैं. ध्यान दें कि यह, सामने वाले कैमरे के लिए लागू होता है. उदाहरण के लिए, भले ही सामने वाले ज़्यादातर कैमरे, ऑटोफ़ोकस के साथ काम नहीं करते, लेकिन एपीआई कॉलबैक, बताए गए तरीके से "फ़ेक" होने चाहिए.
• [C-0-6] android.hardware.Camera.Parameters क्लास और android.hardware.camera2.CaptureRequest क्लास में कॉन्स्टेंट (कॉन्सटेंट) के तौर पर बताए गए हर पैरामीटर के नाम को पहचानना और उसके हिसाब से काम करना ज़रूरी है. इसके उलट, डिवाइस लागू करने के तरीके को android.hardware.Camera.Parameters पर कॉन्सटेंट के तौर पर बताए गए तरीके के अलावा, android.hardware.Camera.setParameters() तरीके में पास किए गए स्ट्रिंग कॉन्सटेंट के मुताबिक नहीं होना चाहिए और न ही उनकी पहचान करनी चाहिए. इसका मतलब है कि अगर हार्डवेयर अनुमति देता है, तो डिवाइस को लागू करने के लिए सभी स्टैंडर्ड कैमरा पैरामीटर के साथ काम करना ज़रूरी है. साथ ही, इसमें कस्टम कैमरा पैरामीटर के टाइप भी काम नहीं करने चाहिए. उदाहरण के लिए, कुछ डिवाइसों पर हाई डाइनैमिक रेंज (एचडीआर) इमेजिंग तकनीकों का इस्तेमाल करके इमेज कैप्चर करने की सुविधा देने वाले डिवाइसों पर, कैमरा पैरामीटर Camera.SCENE_MODE_HDR काम करना ज़रूरी है.
• [C-0-7] Android SDK में बताए गए तरीके के मुताबिक, android.info.supportedHardwareLevel प्रॉपर्टी को सही लेवल पर रिपोर्ट करना ज़रूरी है. साथ ही, फ़्रेमवर्क फ़ीचर फ़्लैग की शिकायत भी करनी होगी.
• [C-0-8] android.request.availableCapabilities प्रॉपर्टी की मदद से, android.hardware.camera2 की अलग-अलग कैमरे की क्षमताओं के बारे में बताना ज़रूरी है. साथ ही, सही फ़ीचर फ़्लैग भी बताना ज़रूरी है. अगर अटैच किया गया कोई कैमरा डिवाइस इस सुविधा के साथ काम करता है, तो फ़ीचर फ़्लैग तय करना ज़रूरी है.
• [C-0-9] जब भी कैमरा कोई नई तस्वीर लेता है और मीडिया स्टोर में तस्वीर की एंट्री जोड़ी जाती है, तब Camera.ACTION_NEW_PICTURE इंटेंट को ब्रॉडकास्ट करना ज़रूरी है.
• [C-0-10] जब भी कैमरा कोई नया वीडियो रिकॉर्ड करता है और मीडिया स्टोर में तस्वीर की एंट्री जोड़ी जाती है, तब Camera.ACTION_NEW_VIDEO इंटेंट को ब्रॉडकास्ट करना ज़रूरी है.
• [C-0-11] सभी कैमरों को ऐसे android.hardware.Camera एपीआई की मदद से ऐक्सेस किया जाना चाहिए जो अब काम नहीं करता. इसे android.hardware.camera2 एपीआई से भी ऐक्सेस किया जा सकता है.
• [C-SR] एक ही दिशा में कई आरजीबी कैमरे वाले डिवाइसों के लिए, इस बात का बहुत ज़्यादा सुझाव दिया जाता है कि वे लॉजिकल कैमरा डिवाइस के साथ काम करें. इस डिवाइस में क्षमता CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA होनी चाहिए. इसमें वे सभी आरजीबी कैमरे शामिल हैं जो उस दिशा में लगे फ़िज़िकल सब-डिवाइसों की तरह हैं.

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

• [C-1-1] android.hardware.camera2 एपीआई का इस्तेमाल करके, इस तरह के Camera API को लागू करना ज़रूरी है.
• android.hardware.camera2 एपीआई के लिए, वेंडर टैग और/या एक्सटेंशन उपलब्ध कराए जा सकते हैं.

7.5.5. कैमरा ओरिएंटेशन

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

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

7.6. डिवाइस की मेमोरी और स्टोरेज

7.6.1. कम से कम मेमोरी और स्टोरेज

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

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

7.6.2. ऐप्लिकेशन का शेयर किया गया स्टोरेज

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

• [C-0-1] ऐप्लिकेशन में शेयर किया जाने वाला स्टोरेज ज़रूर ऑफ़र करना चाहिए. इसे अक्सर "शेयर किया गया एक्सटर्नल स्टोरेज", "ऐप्लिकेशन का शेयर किया गया स्टोरेज" या उस Linux पाथ "/sdcard" से भी कहा जाता है जिस पर यह माउंट किया गया है.
• [C-0-2] शेयर किए गए ऐसे स्टोरेज को कॉन्फ़िगर करना ज़रूरी है जो डिफ़ॉल्ट रूप से माउंट किया गया हो.इसे दूसरे शब्दों में "अलग-अलग तरह से" भी बताया जाना चाहिए. भले ही, स्टोरेज को डिवाइस के स्टोरेज कॉम्पोनेंट में इस्तेमाल किया गया हो या हटाए जा सकने वाले स्टोरेज मीडियम (जैसे, सुरक्षित डिजिटल कार्ड स्लॉट).
• [C-0-3] ऐप्लिकेशन के शेयर किए गए स्टोरेज को सीधे Linux पाथ sdcard पर माउंट करना ज़रूरी है या sdcard से लेकर असल माउंट पॉइंट तक, Linux सिंबल वाला लिंक शामिल करना होगा.
• [C-0-4] SDK टूल में बताए गए, शेयर किए गए इस स्टोरेज के लिए, android.permission.WRITE_EXTERNAL_STORAGE की अनुमति को लागू करना ज़रूरी है.
• [C-0-5] नीचे दी गई स्थितियों को छोड़कर, एपीआई लेवल 29 या उसके बाद के वर्शन को टारगेट करने वाले सभी ऐप्लिकेशन के लिए, स्कोप वाले स्टोरेज को डिफ़ॉल्ट रूप से चालू करना ज़रूरी है:
  • जब ऐप्लिकेशन के टारगेट एपीआई पर ध्यान दिए बिना, डिवाइस को एपीआई लेवल 29 पर अपग्रेड होने से पहले इंस्टॉल किया गया था.
  • जब ऐप्लिकेशन ने अपने मेनिफ़ेस्ट में android:requestLegacyExternalStorage="true" का अनुरोध किया है.
  • जब ऐप्लिकेशन को android.permission.WRITE_MEDIA_STORAGE की अनुमति मिली हो.
• [C-0-6] यह लागू करना ज़रूरी है कि जिन ऐप्लिकेशन के दायरे में स्टोरेज की सुविधा चालू हो उनके ऐप्लिकेशन के लिए खास डायरेक्ट्री के बाहर की फ़ाइलों के लिए फ़ाइल सिस्टम का ऐक्सेस न हो, जैसा कि Context एपीआई तरीकों जैसे Context.getExternalFilesDirs(), Context.getExternalCacheDirs(), Context.getExternalMediaDirs(), और Context.getObbDirs() से किया जाता है.
• [C-0-7] मीडिया फ़ाइलों में MediaStore के ज़रिए सेव किए गए जीपीएस Exif टैग जैसे जगह के मेटाडेटा को छिपाने के लिए उसमें बदलाव करना ज़रूरी है. ऐसा सिर्फ़ तब होना चाहिए, जब कॉलिंग ऐप्लिकेशन के पास ACCESS_MEDIA_LOCATION की अनुमति हो.

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

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

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

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

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

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

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

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

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

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

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

• यह बताए गए Android MTP होस्ट, Android File Transfer के साथ काम करना चाहिए.
• 0x00 की यूएसबी डिवाइस क्लास की रिपोर्ट करनी चाहिए.
• 'MTP' के USB इंटरफ़ेस का नाम रिपोर्ट करना चाहिए.

7.6.3. डिवाइस का स्टोरेज

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

• [SR] लंबे समय तक स्थिर जगह में रखने का सुझाव दिया जाता है. ऐसा इसलिए, क्योंकि गलती से इन्हें डिसकनेक्ट करने से डेटा मिट सकता है या खराब हो सकता है.

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

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

7.7. यूएसबी

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

• यूएसबी सहायक डिवाइस (जैसे, कीबोर्ड, माउस, मॉनिटर, वेबकैम वगैरह) पर काम करना चाहिए. साथ ही, यूएसबी होस्ट मोड भी काम करना चाहिए.

7.7.1. यूएसबी सहायक डिवाइस (जैसे, कीबोर्ड, माउस, मॉनिटर, वेबकैम वगैरह) मोड

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

• [C-1-1] पोर्ट को ऐसे यूएसबी होस्ट से कनेक्ट करना ज़रूरी है जिसमें स्टैंडर्ड टाइप-ए या टाइप-सी यूएसबी पोर्ट हो.
• [C-1-2] आपको android.os.Build.SERIAL की मदद से, यूएसबी के स्टैंडर्ड डिवाइस डिस्क्रिप्टर में iSerialNumber की सही वैल्यू की रिपोर्ट देनी होगी.
• [C-1-3] टाइप-सी रेज़िस्टर स्टैंडर्ड के हिसाब से, 1.5A और 3.0A चार्जर का पता लगाना ज़रूरी है. साथ ही, अगर विज्ञापन टाइप-सी यूएसबी के साथ काम करते हैं, तो उन्हें विज्ञापन में होने वाले बदलावों का पता लगाना चाहिए.
• [SR] पोर्ट को माइक्रो-B, माइक्रो एबी या टाइप-सी यूएसबी नाप या आकार का इस्तेमाल करना चाहिए. मौजूदा और नए Android डिवाइसों को इन ज़रूरी शर्तों को पूरा करने का सुझाव दिया जाता है, ताकि उन्हें आने वाले प्लैटफ़ॉर्म की रिलीज़ पर अपग्रेड किया जा सके.
• [SR] पोर्ट को डिवाइस के नीचे की ओर होना चाहिए (प्राकृतिक ओरिएंटेशन के मुताबिक) या सभी ऐप्लिकेशन (होम स्क्रीन सहित) के लिए सॉफ़्टवेयर स्क्रीन घुमाने की सुविधा चालू करनी चाहिए, ताकि डिवाइस के नीचे मौजूद पोर्ट के हिसाब से डिसप्ले सही तरीके से दिखे. मौजूदा और नए Android डिवाइसों को इन ज़रूरी शर्तों को पूरा करने का सुझाव दिया जाता है, ताकि उन्हें आने वाले प्लैटफ़ॉर्म की रिलीज़ पर अपग्रेड किया जा सके.
• [SR] एचएस चिरप और ट्रैफ़िक के दौरान 1.5 ए करंट निकालने के लिए सहायता लागू करनी चाहिए, जैसा कि यूएसबी बैटरी चार्जिंग की खास बातों, बदलाव 1.2 में बताया गया है. मौजूदा और नए Android डिवाइसों को इन ज़रूरी शर्तों को पूरा करने का सुझाव दिया जाता है, ताकि उन्हें आने वाले प्लैटफ़ॉर्म की रिलीज़ पर अपग्रेड किया जा सके.
• [SR] इस बात का खास तौर पर सुझाव दिया जाता है कि चार्ज करने के लिए मालिकाना हक के ऐसे तरीके काम न करें जो डिफ़ॉल्ट लेवल से आगे जाकर VBS वोल्टेज में बदलाव करते हैं. इसके अलावा, सिंक/सोर्स की भूमिकाओं में बदलाव करने पर, यूएसबी पावर डिलीवरी के स्टैंडर्ड तरीकों का इस्तेमाल करने वाले चार्जर या डिवाइसों में इंटरऑपरेबिलिटी (दूसरे सिस्टम के साथ काम करने के लिए) की समस्याएं आ सकती हैं. इस सुविधा को "बहुत ज़्यादा सुझाया गया" कहा जाता है. आने वाले समय में Android के आने वाले वर्शन में, हमें सभी टाइप-सी डिवाइसों की ज़रूरत पड़ सकती है, ताकि वे स्टैंडर्ड टाइप-सी चार्जर के साथ पूरी तरह से इंटरऑपरेबिलिटी (दूसरे सिस्टम के साथ काम करना) की सुविधा का इस्तेमाल कर सकें.
• [SR] टाइप-सी यूएसबी और यूएसबी होस्ट मोड के साथ काम करने पर डेटा और पावर रोल बदलने के लिए, पावर डिलीवरी के इस्तेमाल का सुझाव दिया जाता है.
• इसे हाई-वोल्टेज चार्जिंग के लिए पावर डिलीवरी की सुविधा होनी चाहिए. साथ ही, डिसप्ले आउट जैसे दूसरे मोड के साथ भी काम किया जा सकता है.
• Android SDK के दस्तावेज़ में बताए गए, Android Open Accessory (AOA) एपीआई और उससे जुड़ी खास बातों को लागू करना चाहिए.

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

• [C-2-1] हार्डवेयर की सुविधा android.hardware.usb.accessory के साथ काम करने का एलान करना ज़रूरी है.
• [C-2-2] यूएसबी मास स्टोरेज क्लास के इंटरफ़ेस के ब्यौरे के आखिर में "Android" स्ट्रिंग शामिल होनी चाहिए. यूएसबी मास स्टोरेज के iInterface स्ट्रिंग में

7.7.2. यूएसबी होस्ट मोड

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

• [C-1-1] Android SDK टूल में बताए गए दस्तावेज़ के मुताबिक, Android यूएसबी होस्ट एपीआई को लागू करना ज़रूरी है. साथ ही, यह एलान करना ज़रूरी है कि यह हार्डवेयर सुविधा android.hardware.usb.host पर काम करता है.
• [C-1-2] स्टैंडर्ड यूएसबी सहायक डिवाइसों को कनेक्ट करने के लिए, सहायता का इस्तेमाल करना होगा. दूसरे शब्दों में कहें, तो:
  • उपयोगकर्ता के डिवाइस पर, टाइप सी पोर्ट का इस्तेमाल करें. इसके अलावा, आपके पास केबल की मदद से, डिवाइस में मौजूद मालिकाना पोर्ट को स्टैंडर्ड यूएसबी टाइप-सी पोर्ट (यूएसबी टाइप-सी डिवाइस) में बदलने की सुविधा भी होनी चाहिए.
  • डिवाइस में टाइप A का इस्तेमाल करें या केबल के साथ शिप करें. इससे डिवाइस के मालिकाना हक वाले पोर्ट को स्टैंडर्ड यूएसबी टाइप-ए पोर्ट में बदलने में मदद मिलती है.
  • डिवाइस में मौजूद माइक्रो-एबी पोर्ट की मदद से ऐसा किया जा सकता है. स्टैंडर्ड टाइप-ए पोर्ट के हिसाब से केबल का इस्तेमाल किया जाना चाहिए.
• [C-1-3] इसे ऐसे अडैप्टर से नहीं भेजा जाना चाहिए जो यूएसबी टाइप A या माइक्रो-एबी पोर्ट से टाइप-सी पोर्ट (रिसेप्टेकल) में बदलता हो.
• [C-SR] हमारा सुझाव है कि यूएसबी ऑडियो क्लास को लागू करें, जैसा कि Android SDK के दस्तावेज़ में बताया गया है.
• होस्ट मोड में, कनेक्ट किए गए यूएसबी सहायक डिवाइस को चार्ज करना ज़रूरी है. यूएसबी टाइप-सी कनेक्टर के लिए यूएसबी टाइप-सी केबल और कनेक्टर स्पेसिफ़िकेशन रिवीज़न 1.2 के खत्म होने के पैरामीटर सेक्शन में बताए गए, कम से कम 1.5A के सोर्स का विज्ञापन करना चाहिए. इसके अलावा, यूएसबी बैटरी चार्जिंग से जुड़ी जानकारी, रीविज़न 1.2 के लिए, चार्जिंग डाउनस्ट्रीम माइक्रो पोर्ट कनेक्टर(सीडीपी) आउटपुट की मौजूदा रेंज का इस्तेमाल करना चाहिए.
• यूएसबी टाइप-सी स्टैंडर्ड लागू करना चाहिए और उनका इस्तेमाल करना चाहिए.

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

• [C-2-1] यूएसबी एचआईडी क्लास के साथ काम करना ज़रूरी है.
• [C-2-2] यूएसबी एचआईडी के इस्तेमाल की टेबल और वॉइस कमांड के इस्तेमाल से जुड़े अनुरोध में बताए गए इन एचआईडी डेटा फ़ील्ड की पहचान करने और उन्हें मैप करने के लिए ज़रूरी है. इनके बारे में यहां बताया गया है:
  KeyEvent
  • इस्तेमाल पेज (0xC) इस्तेमाल आईडी (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
  • इस्तेमाल पेज (0xC) इस्तेमाल आईडी (0x0E9): KEYCODE_VOLUME_UP
  • इस्तेमाल पेज (0xC) इस्तेमाल आईडी (0x0EA): KEYCODE_VOLUME_DOWN
  • इस्तेमाल पेज (0xC) इस्तेमाल आईडी (0x0CF): KEYCODE_VOICE_ASSIST

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

• [C-3-1] के लिए, रिमोट तरीके से कनेक्ट किए गए किसी भी MTP (मीडिया ट्रांसफ़र प्रोटोकॉल) डिवाइस की पहचान करना और उसके कॉन्टेंट को ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, और ACTION_CREATE_DOCUMENT इंटेंट के ज़रिए ऐक्सेस करना ज़रूरी है.

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

• [C-4-1] यूएसबी टाइप-सी स्पेसिफ़िकेशन (सेक्शन 4.5.1.3.3) के मुताबिक ड्यूअल रोल पोर्ट फ़ंक्शन को लागू करना ज़रूरी है.
• [SR] DisplayPort के साथ काम करने का सुझाव दिया जाता है. यह यूएसबी सुपरस्पीड डेटा रेट के हिसाब से काम करना चाहिए. साथ ही, डेटा और पावर की भूमिका बदलने के लिए, पावर डिलीवरी के इस्तेमाल का भी खास तौर पर सुझाव दिया जाता है.
• [SR] इस बात पर खास तौर पर ध्यान दिया जाता है कि ऑडियो अडैप्टर ऐक्सेसरी मोड के साथ काम न किया जाए, जैसा कि यूएसबी टाइप-सी केबल और कनेक्टर स्पेसिफ़िकेशन रिवीज़न 1.2 के अपेंडिक्स A में बताया गया है.
• आज़माएं.* मॉडल लागू करना चाहिए, जो डिवाइस के नाप या आकार के लिए सबसे सही हो. उदाहरण के लिए, हैंडहेल्ड डिवाइस में Tri.SNK मॉडल लागू करना चाहिए.

7.8. ऑडियो

7.8.1. माइक्रोफ़ोन

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

• [C-1-1] android.hardware.microphone सुविधा के कॉन्स्टेंट की जानकारी देना ज़रूरी है.
• [C-1-2] सेक्शन 5.4 में, ऑडियो रिकॉर्ड करने की ज़रूरी शर्तों को पूरा करना ज़रूरी है.
• [C-1-3] सेक्शन 5.6 में, ऑडियो के इंतज़ार का समय तय करने से जुड़ी ज़रूरी शर्तों को पूरा करना ज़रूरी है.
• नियर-अल्ट्रासाउंड रिकॉर्डिंग के लिए [SR] का खास तौर पर सुझाव दिया जाता है. इसके बारे में सेक्शन 7.8.3 में बताया गया है.

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

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

7.8.2. ऑडियो आउटपुट

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

• [C-1-1] android.hardware.audio.output सुविधा के कॉन्स्टेंट की जानकारी देना ज़रूरी है.
• [C-1-2] सेक्शन 5.5 में, ऑडियो चलाने से जुड़ी ज़रूरी शर्तों को पूरा करना ज़रूरी है.
• [C-1-3] सेक्शन 5.6 में, ऑडियो के इंतज़ार का समय तय करने से जुड़ी ज़रूरी शर्तों को पूरा करना ज़रूरी है.
• [SR] करीब-करीब अल्ट्रासाउंड वीडियो चलाने का सुझाव दिया जाता है. इसके बारे में सेक्शन 7.8.3 में बताया गया है.

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

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

इस सेक्शन में, "आउटपुट पोर्ट" एक फ़िज़िकल इंटरफ़ेस है. जैसे, 3.5 मि॰मी॰ का ऑडियो जैक, एचडीएमआई या यूएसबी ऑडियो क्लास वाला यूएसबी होस्ट मोड पोर्ट. ब्लूटूथ, वाई-फ़ाई या मोबाइल नेटवर्क जैसे रेडियो-आधारित प्रोटोकॉल पर ऑडियो आउटपुट के लिए, "आउटपुट पोर्ट" शामिल नहीं किया जा सकता.

7.8.2.1. ऐनालॉग ऑडियो पोर्ट

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

• [C-SR] 4 कंडक्टर 3.5 मि॰मी॰ का ऑडियो जैक बनाने के लिए, कम से कम एक ऑडियो पोर्ट को शामिल करने का सुझाव दिया जाता है.

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

• [C-1-1] माइक्रोफ़ोन वाले स्टीरियो हेडफ़ोन और स्टीरियो हेडसेट पर ऑडियो चलाया जा सकता है.
• [C-1-2] सीटीआईए पिन-आउट ऑर्डर के साथ, टीआरआरएस के ऑडियो प्लग के साथ काम करना ज़रूरी है.
• [C-1-3] ऑडियो प्लग पर दिए गए माइक्रोफ़ोन और ग्राउंड कंडक्टर के बीच, नीचे दी गई तीन रेंज के, कीकोड की पहचान करने और उन्हें मैप करने की सुविधा दी जानी चाहिए:
  • 70 ओम या उससे कम: KEYCODE_HEADSETHOOK
  • 210-290 ओम: KEYCODE_VOLUME_UP
  • 360-680 ओम: KEYCODE_VOLUME_DOWN
• [C-1-4] प्लग इन्स डालने पर, ACTION_HEADSET_PLUG को ट्रिगर करना ज़रूरी है. हालांकि, यह ज़रूरी है कि प्लग पर लगे सभी संपर्क, जैक पर अपने ज़रूरी सेगमेंट को छू रहे हों.
• [C-1-5] 32 ओम वाले स्पीकर प्रतिरोध पर कम से कम 150mV ± 10% आउटपुट वोल्टेज तक चलाने में सक्षम होना चाहिए.
• [C-1-6] माइक्रोफ़ोन बायस वोल्टेज 1.8V ~ 2.9V के बीच होना चाहिए.
• [C-1-7] ऑडियो प्लग पर माइक्रोफ़ोन और ग्राउंड कंडक्टर के बीच, नीचे दिए गए उदाहरण के हिसाब से, कीकोड का पता लगाकर उसे मैप करना ज़रूरी है:
  • 110-180 ओम: KEYCODE_VOICE_ASSIST
• [C-SR] ओएमटीपी पिन-आउट ऑर्डर के साथ ऑडियो प्लग के साथ काम करने के लिए, इस बात का खास तौर पर सुझाव दिया जाता है.
• [C-SR] का खास तौर पर सुझाव दिया जाता है, ताकि माइक्रोफ़ोन वाले स्टीरियो हेडसेट से ऑडियो रिकॉर्डिंग की जा सके.

अगर लागू होने वाले डिवाइस में 4 कंडक्टर 3.5 मि॰मी॰ का ऑडियो जैक है और उसमें माइक्रोफ़ोन काम करता है, तो वह android.intent.action.HEADSET_PLUG को ब्रॉडकास्ट करता है कि अतिरिक्त वैल्यू वाले माइक्रोफ़ोन को 1 पर सेट किया गया हो, तो:

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

7.8.2.2. डिजिटल ऑडियो पोर्ट

यह सुविधा, यूएसबी-सी कनेक्टर का इस्तेमाल करके हेडसेट और दूसरी ऑडियो ऐक्सेसरी के साथ काम कर सकती है. साथ ही, Android यूएसबी हेडसेट की खास बातों के हिसाब से, पूरे Android नेटवर्क में यूएसबी ऑडियो क्लास लागू करती है.

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

7.8.3. नियर-अल्ट्रासाउंड

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

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

• नियर-अल्ट्रासाउंड ऑडियो की क्षमता के बारे में सही तरीके से रिपोर्ट करना ज़रूरी है. इसके लिए, AudioManager.getproperty एपीआई का इस्तेमाल करें. इसके लिए, यह तरीका अपनाएं:

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

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

अगर PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND का मान "सही" है, तो:

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

7.8.4. सिग्नल की सुरक्षा

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

• हैंडहेल्ड डिवाइसों पर इनपुट और आउटपुट स्ट्रीम, दोनों के लिए ऐसा ऑडियो सिग्नल पाथ देना चाहिए जिसमें कोई ग्लिच न हो. इसका मतलब है कि हर पाथ के लिए एक मिनट की जांच के दौरान कोई ग्लिच नहीं होना चाहिए. [OboeTester] (https://github.com/google/oboe/tree/Master/apps/OboeTester) “Automated Glitch Test” का इस्तेमाल करके टेस्ट करें.

इस जांच के लिए, ऑडियो लूपबैक डोंगल की ज़रूरत होती है. इसे सीधे 3.5 मि॰मी॰ जैक में इस्तेमाल किया जाता है और/या इसे यूएसबी-सी से 3.5 मि॰मी॰ अडैप्टर के साथ इस्तेमाल किया जाता है. सभी ऑडियो आउटपुट पोर्ट की जांच की जानी चाहिए.

फ़िलहाल, OboeTester ऑडियो पाथ के साथ काम करता है. इसलिए, AAudio का इस्तेमाल करके, ग्लिच के लिए इन कॉम्बिनेशन की जांच की जानी चाहिए:

परफ़ॉर्मेंस मोड	शेयर करें	आउट सैंपल रेट	इन चांस	आउट चांस
LOW_LATENCY	खास	जानकारी उपलब्ध नहीं है	1	2
LOW_LATENCY	खास	जानकारी उपलब्ध नहीं है	2	1
LOW_LATENCY	शेयर किया गया	जानकारी उपलब्ध नहीं है	1	2
LOW_LATENCY	शेयर किया गया	जानकारी उपलब्ध नहीं है	2	1
कोई नहीं	शेयर किया गया	48000	1	2
कोई नहीं	शेयर किया गया	48000	2	1
कोई नहीं	शेयर किया गया	44100	1	2
कोई नहीं	शेयर किया गया	44100	2	1
कोई नहीं	शेयर किया गया	16000	1	2
कोई नहीं	शेयर किया गया	16000	2	1

एक भरोसेमंद स्ट्रीम को 2000 हर्ट्ज़ साइन के लिए सिग्नल से शोर के अनुपात (एसएनआर) और टोटल हार्मोनिक डिस्टॉर्शन (टीएचडी) के लिए, इन शर्तों को पूरा करना चाहिए.

ट्रांसड्यूसर	बात	एसएनआर
पहले से मौजूद प्राइमरी स्पीकर, जिसे बाहरी रेफ़रंस माइक्रोफ़ोन की मदद से मापा गया है	3.0% से कम	>= 50 डीबी
प्राइमरी बिल्ट-इन माइक्रोफ़ोन, जिसे बाहरी रेफ़रंस स्पीकर की मदद से मापा जाता है	3.0% से कम	>= 50 डीबी
पहले से मौजूद ऐनालॉग 3.5 मि॰मी॰ जैक, जिन्हें लूपबैक अडैप्टर का इस्तेमाल करके टेस्ट किया गया	< 1%	60 डीबी से ज़्यादा
फ़ोन के साथ दिए गए यूएसबी अडैप्टर, जिन्हें लूपबैक अडैप्टर का इस्तेमाल करके टेस्ट किया गया है	1.0% से कम	60 डीबी से ज़्यादा

7.9. आभासी वास्तविकता

Android में "वर्चुअल रिएलिटी" (वीआर) ऐप्लिकेशन बनाने के लिए एपीआई और सुविधाएं शामिल हैं. इनमें अच्छी क्वालिटी वाले मोबाइल वीआर अनुभव भी शामिल हैं. डिवाइस पर इन एपीआई और सुविधाओं को सही तरीके से लागू करना ज़रूरी है. इसके बारे में इस सेक्शन में बताया गया है.

7.9.1. वर्चुअल रिएलिटी मोड

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

7.9.2. वर्चुअल रिएलिटी मोड - बेहतर परफ़ॉर्मेंस

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

• [C-1-1] कम से कम दो फ़िज़िकल कोर होने चाहिए.
• [C-1-2] android.hardware.vr.high_performance सुविधा के बारे में एलान करना ज़रूरी है.
• [C-1-3] स्थायी परफ़ॉर्मेंस मोड के साथ काम करना ज़रूरी है.
• [C-1-4] OpenGL ES 3.2 के साथ काम करना ज़रूरी है.
• [C-1-5] android.hardware.vulkan.level 0 के साथ काम करना ज़रूरी है.
• android.hardware.vulkan.level 1 या इसके बाद के वर्शन के साथ काम करना चाहिए.
• [C-1-6] EGL_KHR_mutable_render_buffer, EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_get_native_client_buffer, EGL_KHR_fence_sync, EGL_KHR_wait_sync, EGL_IMG_context_priority, EGL_EXT_protected_content, EGL_EXT_image_gl_colorspace को लागू करना ज़रूरी है. साथ ही, एक्सटेंशन को उपलब्ध EGL एक्सटेंशन की सूची में दिखाना ज़रूरी है.
• [C-1-8] GL_EXT_multisampled_render_to_texture2, GL_OVR_multiview, GL_OVR_multiview2, GL_OVR_multiview_multisampled_render_to_texture, GL_EXT_protected_textures को लागू करना ज़रूरी है. साथ ही, एक्सटेंशन को उपलब्ध GL एक्सटेंशन की सूची में दिखाना ज़रूरी है.
• [C-SR] का खास तौर पर सुझाव दिया जाता है कि GL_EXT_external_buffer, GL_EXT_EGL_image_array को लागू किया जाए, और एक्सटेंशन को उपलब्ध जीएल एक्सटेंशन की सूची में दिखाया जाए.
• [C-SR] का सुझाव दिया जाता है, ताकि Vulkan 1.1 के साथ काम किया जा सके.
• [C-SR] VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing, VK_KHR_shared_presentable_image को लागू करने का सुझाव दिया जाता है. साथ ही, इन्हें Vulkan एक्सटेंशन की सूची में शामिल करके दिखाया जाता है.
• [सी-एसआर] इस बात का सुझाव दिया जाता है कि कम से कम एक वुल्कन सूची में परिवार के सभी सदस्यों को दिखाया जाए. इसमें flags में VK_QUEUE_GRAPHICS_BIT और VK_QUEUE_COMPUTE_BIT, और queueCount, दोनों की संख्या कम से कम दो होनी चाहिए.
• [C-1-7] जीपीयू और डिसप्ले के लिए, शेयर किए गए फ़्रंट बफ़र का ऐक्सेस इस तरह सिंक होना चाहिए कि 60fps पर वीआर कॉन्टेंट की बारी-बारी से रेंडर होने की सुविधा के साथ दो रेंडर करने के तरीके दिखाए जाएंगे.
• [C-1-9] एनडीके में बताए गए तरीके के मुताबिक, AHardwareBuffer AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA, और AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT फ़्लैग के लिए काम करना ज़रूरी है.
• [C-1-10] कम से कम इन फ़ॉर्मैट के लिए, AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT जैसे इस्तेमाल फ़्लैग के साथ AHardwareBuffer के लिए काम करना ज़रूरी है: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
• [C-SR] का सुझाव खास तौर पर दिया जाता है, ताकि C-1-10 में एक से ज़्यादा लेयर और फ़्लैग और फ़ॉर्मैट वाली AHardwareBuffer फ़ाइलें असाइन की जा सकें.
• [C-1-11] 30fps पर कम से कम 3840 x 2160 H.264 को डिकोड करने की सुविधा होनी चाहिए, जो औसतन 40 एमबीपीएस (30 FPS-10 एमबीपीएस पर 1920 x1080 के चार इंस्टेंस के बराबर या 1920 x 20 एमबीपीएस-1920 x 20 एमबीपीएस के 2 इंस्टेंस पर) हो.
• [C-1-12] HEVC और VP9 की सुविधा होनी चाहिए. साथ ही, 10 एमबीपीएस के औसत कंप्रेस किए हुए 30 FPS (फ़्रेम प्रति सेकंड) पर, कम से कम 1920 x 1080 को डिकोड करने की सुविधा होनी चाहिए. साथ ही, 30 x 2160 FPS (फ़्रेम प्रति सेकंड) के बराबर या 10 एमबीपीएस के 10 एमबीपीएस के बराबर, 3840 x 2160 को डिकोड करना ज़रूरी है.
• [C-1-13] HardwarePropertiesManager.getDeviceTemperatures एपीआई के साथ काम करना ज़रूरी है और त्वचा के तापमान की सटीक वैल्यू दिखाना.
• [C-1-14] इसमें एम्बेड की गई स्क्रीन होनी चाहिए और इसका रिज़ॉल्यूशन कम से कम 1920 x 1080 होना चाहिए.
• [C-SR] का खास तौर पर सुझाव दिया जाता है कि डिसप्ले रिज़ॉल्यूशन कम से कम 2560 x 1440 हो.
• [C-1-15] VR मोड में होने पर, डिसप्ले को कम से कम 60 हर्ट्ज़ पर अपडेट करना ज़रूरी है.
• [C-1-17] डिसप्ले को लो-परसिस्टेंस मोड के साथ काम करना चाहिए और उसे 5 मिलीसेकंड तक बनाए रखना चाहिए. परसिस्टेंस को इससे पता चलता है कि किसी पिक्सल से कितनी देर तक रोशनी निकल रही है.
• [C-1-18] ब्लूटूथ 4.2 और ब्लूटूथ LE डेटा लेंथ एक्सटेंशन सेक्शन 7.4.3 के साथ काम करना ज़रूरी है.
• [C-1-19] यहां दिए गए सभी डिफ़ॉल्ट सेंसर टाइप के लिए, डायरेक्ट चैनल टाइप के साथ काम करना और उसके बारे में सही तरीके से रिपोर्ट करना ज़रूरी है:
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED
• [C-SR] का सुझाव दिया जाता है कि ऊपर दिए गए सभी डायरेक्ट चैनल टाइप के लिए, TYPE_HARDWARE_BUFFER डायरेक्ट चैनल टाइप के साथ काम किया जा सके.
• [C-1-21] android.hardware.hifi_sensors के लिए जाइरोस्कोप, एक्सलरोमीटर, और मैग्नेटोमीटर से जुड़ी ज़रूरी शर्तों को पूरा करना ज़रूरी है. इसके बारे में सेक्शन 7.3.9 में बताया गया है.
• [सी-एसआर] का सुझाव दिया जाता है, ताकि android.hardware.sensor.hifi_sensors सुविधा के साथ काम किया जा सके.
• [C-1-22] फ़ोटॉन के इंतज़ार का समय 28 मिलीसेकंड से ज़्यादा नहीं होना चाहिए.
• [C-SR] इस बात पर ज़ोर दिया जाता है कि फ़ोटॉन की इंतज़ार के समय पर एंड-टू-एंड मोशन हो, जो 20 मिलीसेकंड से ज़्यादा न हो.
• [C-1-23] पहले फ़्रेम का अनुपात होना ज़रूरी है. यह काले से सफ़ेद रंग में ट्रांज़िशन के बाद, पहले फ़्रेम पर पिक्सल की चमक और स्थिर स्थिति में सफ़ेद पिक्सल की चमक के बीच का अनुपात होता है. यह कम से कम 85% होता है.
• [सी-एसआर] का सुझाव दिया जाता है कि पहले फ़्रेम का अनुपात कम से कम 90% रखें.
• इसमें फ़ोरग्राउंड ऐप्लिकेशन के लिए एक खास कोर उपलब्ध कराया जा सकता है. साथ ही, Process.getExclusiveCores API की सुविधा दी जा सकती है, ताकि सबसे ज़्यादा इस्तेमाल किए जाने वाले फ़ोरग्राउंड ऐप्लिकेशन के लिए खास तौर पर उपलब्ध सीपीयू कोर की संख्या दी जा सके.

अगर खास कोर काम करता है, तो कोर:

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

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

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

8.1. उपयोगकर्ता अनुभव को लगातार बनाए रखना

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

8.2. फ़ाइल I/O ऐक्सेस की परफ़ॉर्मेंस

ऐप्लिकेशन के निजी डेटा स्टोरेज (/data पार्टिशन) पर, फ़ाइल के ऐक्सेस से जुड़ी एक जैसी परफ़ॉर्मेंस के लिए एक समान बेसलाइन उपलब्ध कराना, ऐप्लिकेशन डेवलपर को उनके सॉफ़्टवेयर डिज़ाइन में मदद करने के लिए सही उम्मीदें करने में मदद करता है. डिवाइस टाइप के आधार पर, डिवाइस पर कुछ ज़रूरी शर्तें लागू हो सकती हैं. इन शर्तों के बारे में सेक्शन 2 में बताया गया है. इन शर्तों के बारे में यहां दिए गए 'पढ़ने और लिखने' से जुड़ी कार्रवाईयां की जा सकती हैं:

• क्रम से लिखने के लिए परफ़ॉर्मेंस. 10 एमबी राइट बफ़र का इस्तेमाल करके, 256 एमबी की फ़ाइल लिखकर मेज़र की गई.
• रैंडम तरीके से लिखने की परफ़ॉर्मेंस. इसे मापने के लिए, 4 केबी राइट बफ़र का इस्तेमाल करके 256 एमबी की फ़ाइल लिखी गई.
• क्रम से पढ़ने की परफ़ॉर्मेंस. 10 एमबी राइट बफ़र का इस्तेमाल करके, 256 एमबी की फ़ाइल को पढ़कर इसका आकलन किया जाता है.
• किसी भी क्रम में पढ़ने की परफ़ॉर्मेंस. 4 केबी राइट बफ़र का इस्तेमाल करके, 256 एमबी की फ़ाइल को पढ़कर मापा जाता है.

8.3. पावर सेविंग मोड

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

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

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

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

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

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

• [C-2-1] ऊपर दिए गए C-1-1 के मुताबिक होना ज़रूरी है या S3 स्टेटस सिर्फ़ तब डालना होगा, जब तीसरे पक्ष के ऐप्लिकेशन को सिस्टम के संसाधनों (जैसे कि स्क्रीन, सीपीयू) की ज़रूरत न हो.

  इसके उलट, इस SDK टूल में बताए गए तरीके के मुताबिक, तीसरे पक्ष के ऐप्लिकेशन को सिस्टम संसाधनों की ज़रूरत पड़ने पर, S3 वाले स्टेटस से बाहर निकलना होगा.

  उदाहरण के लिए, तीसरे पक्ष के ऐप्लिकेशन, FLAG_KEEP_SCREEN_ON से स्क्रीन को चालू रखने या PARTIAL_WAKE_LOCK तक सीपीयू को चालू रखने का अनुरोध करते हैं. हालांकि, डिवाइस को S3 की स्थिति में तब तक नहीं डालना चाहिए, जब तक C-1-1 में दी गई जानकारी के मुताबिक, उपयोगकर्ता ने डिवाइस को इनऐक्टिव स्थिति में रखने के लिए साफ़ तौर पर कोई कार्रवाई न की हो. इसके उलट, जब JobScheduler की मदद से तीसरे पक्ष के ऐप्लिकेशन से कोई टास्क ट्रिगर होता है या Firebase क्लाउड से मैसेज सेवा, तीसरे पक्ष के ऐप्लिकेशन को डिलीवर की जाती है, तो डिवाइस को S3 स्थिति से बाहर निकलना होगा. ऐसा तब करना होगा, जब उपयोगकर्ता ने डिवाइस को इनऐक्टिव स्थिति में न रखा हो. ये ऐसे उदाहरण नहीं हैं जिनमें दी गई जानकारी पूरी नहीं होती. एओएसपी, स्क्रीन चालू करने के ऐसे बड़े सिग्नल लागू करता है जो इस स्थिति से स्क्रीन चालू करते हैं.

8.4. पावर कंज़म्पशन अकाउंटिंग

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

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

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

8.5. एक ही तरह की परफ़ॉर्मेंस

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

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

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

• इसमें लगातार परफ़ॉर्मेंस को बनाए रखने वाला मोड भी काम करना चाहिए.

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

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

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

• कम से कम एक ऐसा खास कोर होना चाहिए जिसे सबसे ऊपर वाले फ़ोरग्राउंड ऐप्लिकेशन से रिज़र्व किया जा सके.

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

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

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

• [C-3-1] Process.getExclusiveCores() एपीआई वाले तरीके का इस्तेमाल करके, आपको एक खाली सूची देनी होगी.

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

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

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

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

9.1. अनुमतियां

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

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

• अतिरिक्त अनुमतियां जोड़ी जा सकती हैं, बशर्ते अनुमति आईडी की नई स्ट्रिंग android.\* नेमस्पेस में न हों.

• [C-0-2] PROTECTION_FLAG_PRIVILEGED के protectionLevel वाली अनुमतियां, सिर्फ़ उन ऐप्लिकेशन को दी जानी चाहिए जो सिस्टम इमेज के खास पाथ(पाथों) में पहले से इंस्टॉल किए गए हों. साथ ही, यह हर ऐप्लिकेशन के लिए साफ़ तौर पर अनुमति वाली अनुमतियों के सबसेट में शामिल हों. एओएसपी को लागू करने के लिए, यह ज़रूरी शर्त पूरी की जाती है. इसके लिए, etc/permissions/ पाथ में मौजूद फ़ाइलों से हर ऐप्लिकेशन के लिए, अनुमति वाली अनुमतियों को पढ़ें और उनके हिसाब से अनुमतियां दें. इसके अलावा, system/priv-app पाथ को खास पाथ के तौर पर इस्तेमाल करें.

रनटाइम में उपयोगकर्ताओं को मिलने वाली अनुमतियां वे होती हैं जिनमें सुरक्षा के लेवल खतरनाक के तौर पर मार्क किया गया हो. targetSdkVersion > 22 वाले ऐप्लिकेशन, रनटाइम के दौरान इनका अनुरोध करते हैं.

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

• [C-0-3] उपयोगकर्ता को एक खास इंटरफ़ेस दिखाना होगा, ताकि यह तय किया जा सके कि अनुरोध की गई रनटाइम की अनुमतियां देनी हैं या नहीं. साथ ही, उपयोगकर्ता को रनटाइम की अनुमतियां मैनेज करने के लिए इंटरफ़ेस भी देना है.
• [C-0-4] दोनों यूज़र इंटरफ़ेस को एक ही बार लागू करना ज़रूरी है.
• [C-0-5] पहले से इंस्टॉल किए गए ऐप्लिकेशन को रनटाइम की अनुमति तब तक नहीं देनी चाहिए, जब तक:
  • ऐप्लिकेशन का इस्तेमाल करने से पहले, उपयोगकर्ता की सहमति ली जा सकती है.
  • रनटाइम की अनुमतियां ऐसे इंटेंट पैटर्न से जुड़ी होती हैं जिसके लिए पहले से इंस्टॉल किया गया ऐप्लिकेशन, डिफ़ॉल्ट हैंडलर के तौर पर सेट होता है.
• [C-0-6] सिर्फ़ उन सिस्टम ऐप्लिकेशन को android.permission.RECOVER_KEYSTORE की अनुमति देनी होगी जिन्होंने ठीक से सुरक्षित रिकवरी एजेंट रजिस्टर किया है. सही तरीके से सुरक्षित रिकवरी एजेंट को डिवाइस में मौजूद ऐसा सॉफ़्टवेयर एजेंट कहा जाता है जो डिवाइस के रिमोट स्टोरेज के साथ सिंक होता है. इसमें, Google Cloud Key Vault सेवा में बताई गई सुरक्षा के बराबर या उससे ज़्यादा मज़बूत सुरक्षा वाले हार्डवेयर होते हैं. ऐसा इसलिए होता है, ताकि लॉकस्क्रीन नॉलेज फ़ैक्टर पर ज़बरदस्ती हमले को रोका जा सके.

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

• [C-0-7] जब कोई ऐप्लिकेशन, स्टैंडर्ड Android API या मालिकाना हक के तरीके से जगह की जानकारी या शारीरिक गतिविधि के डेटा का अनुरोध करता है, तो Android पर जगह की जानकारी की अनुमति वाली प्रॉपर्टी का पालन करना ज़रूरी है. ऐसे डेटा में ये शामिल हैं, लेकिन इनके अलावा और भी चीज़ें शामिल हो सकती हैं:

  • डिवाइस की जगह (जैसे कि अक्षांश और देशांतर).
  • ऐसी जानकारी जिसका इस्तेमाल डिवाइस की जगह की जानकारी का पता लगाने या उसका अनुमान लगाने के लिए किया जा सकता है. उदाहरण के लिए, SSID, BSSID, सेल आईडी, ब्लूटूथ स्कैन या डिवाइस से कनेक्ट किए गए नेटवर्क की जगह की जानकारी.
  • उपयोगकर्ता की शारीरिक गतिविधि या उसे किस तरह की गतिविधि में शामिल किया गया है.

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

• [C-0-8] किसी ऐप्लिकेशन को जगह की जानकारी या शारीरिक गतिविधि से जुड़े डेटा को ऐक्सेस करने की अनुमति देने के लिए, उपयोगकर्ता की सहमति लेना ज़रूरी है.
• [C-0-9] सिर्फ़ ऐसे ऐप्लिकेशन को रनटाइम की अनुमति देनी होगी जिसके पास SDK टूल में बताई गई ज़रूरी अनुमति हो. उदाहरण के लिए, TelephonyManager#getServiceState के लिए android.permission.ACCESS_FINE_LOCATION की ज़रूरत है).

अनुमतियों को 'प्रतिबंधित' के तौर पर मार्क किया जा सकता है. इससे उनके काम करने के तरीके में बदलाव होता है.

• [C-0-10] किसी ऐप्लिकेशन को hardRestricted फ़्लैग के साथ मार्क की गई अनुमतियां तब तक नहीं दी जानी चाहिए, जब तक:

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

• [C-0-11] जिन ऐप्लिकेशन के पास softRestricted की अनुमति है उन्हें सिर्फ़ सीमित ऐक्सेस देना चाहिए. साथ ही, उनका पूरा ऐक्सेस तब तक नहीं मिलेगा, जब तक कि उन्हें SDK टूल के तहत अनुमति वाली सूची में नहीं जोड़ा जाता. यहां softRestricted की हर अनुमति (उदाहरण के लिए, WRITE_EXTERNAL_STORAGE और READ_EXTERNAL_STORAGE) के लिए पूरा और सीमित ऐक्सेस दिया जाता है.

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

• [SR] का खास तौर पर सुझाव दिया जाता है. हम android.permission.PACKAGE_USAGE_STATS की अनुमति का एलान करने वाले ऐप्लिकेशन के लिए, android.settings.ACTION_USAGE_ACCESS_SETTINGS इंटेंट के हिसाब से, इस्तेमाल के आंकड़ों का ऐक्सेस देने या रद्द करने का तरीका, उपयोगकर्ता को आसानी से ऐक्सेस करने की सुविधा देते हैं.

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

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

9.2. यूआईडी और प्रोसेस आइसोलेशन

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

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

9.3. फ़ाइल सिस्टम अनुमतियां

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

• [C-0-1] Android फ़ाइल को ऐक्सेस करने की अनुमतियों के मॉडल के साथ काम करना ज़रूरी है. इसके बारे में सुरक्षा और अनुमतियों के रेफ़रंस में बताया गया है.

9.4. वैकल्पिक एक्ज़ीक्यूशन एनवायरमेंट

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

• [C-0-1] वैकल्पिक रनटाइम खुद ही Android ऐप्लिकेशन होने चाहिए. साथ ही, इन्हें सेक्शन 9 में बताए गए स्टैंडर्ड Android सुरक्षा मॉडल का पालन करना चाहिए.

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

• [C-0-3] वैकल्पिक रनटाइम में ऐप्लिकेशन को ऐसी सुविधाओं का इस्तेमाल करने की अनुमति नहीं दी जानी चाहिए जिन्हें सिस्टम ऐप्लिकेशन के लिए प्रतिबंधित Android अनुमतियों की मदद से सुरक्षित किया गया है.

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

• [C-0-5] वैकल्पिक रनटाइम को अन्य Android ऐप्लिकेशन के सैंडबॉक्स के साथ लॉन्च नहीं किया जाना चाहिए, न देना चाहिए या न ही उन्हें ऐक्सेस दिया जाना चाहिए.

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

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

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

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

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

• वैकल्पिक रनटाइम में, PackageManager के ज़रिए ऐप्लिकेशन को अलग-अलग Android सैंडबॉक्स (Linux यूज़र आईडी वगैरह) में इंस्टॉल करना चाहिए.

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

9.5. बहु-उपयोगकर्ता सहायता

Android में एक से ज़्यादा उपयोगकर्ताओं के लिए सहायता दी गई है. साथ ही, Android पर सभी उपयोगकर्ताओं को अलग-अलग कॉल करने की सुविधा भी मिलती है.

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

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

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

9.6. प्रीमियम एसएमएस से जुड़ी चेतावनी

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

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

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

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

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

Android सैंडबॉक्स में ऐसी सुविधाएं शामिल हैं जो Linux कर्नेल के लिए, सुरक्षा के बेहतर बनाए गए Linux (SELinux) के ज़रूरी ऐक्सेस कंट्रोल (MAC) सिस्टम, seccomp सैंडबॉक्सिंग, और अन्य सुरक्षा सुविधाओं का इस्तेमाल करती हैं. डिवाइस पर यह सुविधा लागू करना:

• [C-0-1] मौजूदा ऐप्लिकेशन के साथ काम करना जारी रखना ज़रूरी है, भले ही SELinux या कोई अन्य सुरक्षा सुविधा Android फ़्रेमवर्क के नीचे लागू की गई हो.
• [C-0-2] Android फ़्रेमवर्क के नीचे लागू की गई सुरक्षा सुविधा की मदद से, सुरक्षा से जुड़े किसी उल्लंघन का पता चलने और उसे ब्लॉक करने पर, यूज़र इंटरफ़ेस नहीं दिखना चाहिए. हालांकि, सुरक्षा से जुड़ी किसी नीति का उल्लंघन होने पर, इसका यूज़र इंटरफ़ेस दिख सकता है.
• [C-0-3] SELinux या Android फ़्रेमवर्क के नीचे लागू की गई किसी भी दूसरी सुरक्षा सुविधा को उपयोगकर्ता या ऐप्लिकेशन डेवलपर के लिए कॉन्फ़िगर नहीं करना चाहिए.
• [C-0-4] ऐसे ऐप्लिकेशन को अनुमति नहीं देनी चाहिए जो काम करने के तरीके में गड़बड़ी करने वाली नीति को कॉन्फ़िगर करने के लिए, एपीआई (जैसे कि Device Administration API) के ज़रिए दूसरे ऐप्लिकेशन पर असर डाल सकता है.
• [C-0-5] मीडिया फ़्रेमवर्क को एक से ज़्यादा प्रोसेस में बांटना ज़रूरी है, ताकि Android ओपन सोर्स प्रोजेक्ट की साइट में दी गई जानकारी के हिसाब से, हर प्रोसेस को बारीकी से ऐक्सेस दिया जा सके.
• [C-0-6] कर्नेल ऐप्लिकेशन सैंडबॉक्सिंग तकनीक लागू करनी ज़रूरी है. इससे मल्टीथ्रेड प्रोग्राम की कॉन्फ़िगर की जा सकने वाली नीति का इस्तेमाल करके, सिस्टम कॉल को फ़िल्टर किया जा सकता है. अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट इस ज़रूरत को पूरा करता है. इसके लिए, source.android.com के Kernel कॉन्फ़िगरेशन सेक्शन में बताए गए तरीके के मुताबिक, Threadgroup सिंक करने की सुविधा के साथ seccomp-BPF को चालू किया जाता है.

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

• [C-0-7] कर्नेल स्टैक बफ़र ओवरफ़्लो से सुरक्षा देने के तरीके लागू करना ज़रूरी है. CC_STACKPROTECTOR_REGULAR और CONFIG_CC_STACKPROTECTOR_STRONG ऐसे तरीकों के उदाहरण हैं.
• [C-0-8] कर्नेल मेमोरी सुरक्षा के लिए सख्त नियम लागू करना ज़रूरी है.इनमें एक्ज़ीक्यूटेबल कोड रीड-ओनली होता है, रीड-ओनली डेटा होता है और उसे एक्ज़ीक्यूट नहीं किया जा सकता. साथ ही, लिखा गया डेटा एक्ज़ीक्यूट नहीं किया जा सकता (जैसे, CONFIG_DEBUG_RODATA या CONFIG_STRICT_KERNEL_RWX).
• [C-0-9] एपीआई लेवल 28 या उससे बाद के वर्शन की शिपिंग वाले डिवाइसों पर, यूज़र-स्पेस और कर्नेल-स्पेस (जैसे, CONFIG_HARDENED_USERCOPY) के बीच कॉपी की जांच करने के लिए, स्टैटिक और डाइनैमिक ऑब्जेक्ट साइज़ की सीमा लागू करनी होगी.
• [C-0-10] एपीआई लेवल 28 या उसके बाद के वर्शन वाले डिवाइसों पर, कर्नेल मोड (जैसे कि हार्डवेयर PXN के ज़रिए या CONFIG_CPU_SW_DOMAIN_PAN या CONFIG_ARM64_SW_TTBR0_PAN की मदद से एम्युलेट किए गए) में, यूज़र-स्पेस मेमोरी एक्ज़ीक्यूट नहीं करनी चाहिए.
• [C-0-11] एपीआई लेवल 28 या उसके बाद के वर्शन वाले डिवाइसों पर, कर्नेल में यूज़र कॉपी ऐक्सेस एपीआई (जैसे, हार्डवेयर पैन या CONFIG_CPU_SW_DOMAIN_PAN या CONFIG_ARM64_SW_TTBR0_PAN की मदद से एम्युलेट किए गए) के बाहर, यूज़र-स्पेस मेमोरी को पढ़ना या लिखना नहीं चाहिए.
• [C-0-12] एपीआई लेवल 28 या उससे बाद के लेवल (जैसे कि CONFIG_PAGE_TABLE_ISOLATION या CONFIG_UNMAP_KERNEL_AT_EL0) की शिपिंग वाले सभी डिवाइसों पर, अगर हार्डवेयर में CVE-2017-5754 का जोखिम है, तो कर्नेल पेज टेबल आइसोलेशन को लागू करना ज़रूरी है.
• [C-0-13] जिन डिवाइसों को मूल रूप से एपीआई लेवल 28 या उससे बाद के लेवल (जैसे CONFIG_HARDEN_BRANCH_PREDICTOR) के साथ शिप किया जा रहा है उन सभी पर, हार्डवेयर CVE-2017-5715 के जोखिम की स्थिति में, ब्रांच के अनुमान को सख्ती से लागू करना ज़रूरी है.
• [SR] कर्नेल डेटा को बनाए रखने के लिए इसका बहुत ज़्यादा सुझाव दिया जाता है, जो कि शुरू करने के बाद सिर्फ़ रीड-ओनली के तौर पर मार्क किया गया है (जैसे, __ro_after_init).

• [C-SR] कर्नेल कोड और मेमोरी के लेआउट को रैंडमाइज़ करने और ऐसे एक्सपोज़र से बचने के लिए खास तौर पर सुझाव दिया जाता है जिनसे रैंडमाइज़ेशन की समस्या को हल किया जा सके (उदाहरण के लिए, /chosen/kaslr-seed Device Tree node या EFI_RNG_PROTOCOL के ज़रिए बूटलोडर एंट्रॉपी के साथ CONFIG_RANDOMIZE_BASE).

• [C-SR] का बहुत ज़्यादा सुझाव दिया जाता है, ताकि कर्नेल में कंट्रोल फ़्लो इंटेग्रिटी (सीएफ़आई) को चालू किया जा सके. इससे कोड का दोबारा इस्तेमाल करने के हमलों से अतिरिक्त सुरक्षा मिलती है, जैसे कि CONFIG_CFI_CLANG और CONFIG_SHADOW_CALL_STACK.

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

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

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

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

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

• [C-2-1] ज़रूरी ऐक्सेस कंट्रोल सिस्टम का इस्तेमाल करना ज़रूरी है, जो SELinux के जैसा होता है.

Android में सुरक्षा का दायरा बढ़ाने वाली कई सुविधाएं शामिल हैं, जो डिवाइस की सुरक्षा के लिए बहुत ज़रूरी हैं.

9.8. निजता

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

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

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

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

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

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

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

9.8.2. रिकॉर्ड किया जा रहा है

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

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

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

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

अगर डिवाइस पर लागू होने वाले ऐसे फ़ंक्शन शामिल हैं जो या तो स्क्रीन पर दिखाए गए कॉन्टेंट को कैप्चर करते हैं और/या सिस्टम एपीआई ContentCaptureService या सेक्शन 9.8.6 कॉन्टेंट कैप्चर में बताए गए मालिकाना हक के दूसरे तरीकों को छोड़कर, डिवाइस पर चल रहे ऑडियो स्ट्रीम को रिकॉर्ड करते हैं, तो:

• [C-1-1] इस सुविधा के चालू होने और कैप्चर/रिकॉर्ड किए जाने पर, उपयोगकर्ता को इसकी सूचना दी जानी चाहिए.

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

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

9.8.3. कनेक्टिविटी

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

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

9.8.4. नेटवर्क ट्रैफ़िक

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

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

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

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

अगर डिवाइस पर लागू करने का कोई ऐसा तरीका है जो डिफ़ॉल्ट रूप से आउट-ऑफ़-बॉक्स चालू होता है, तो नेटवर्क डेटा ट्रैफ़िक को प्रॉक्सी सर्वर या वीपीएन गेटवे के ज़रिए रूट किया जाता है. उदाहरण के लिए, android.permission.CONTROL_VPN की अनुमति वाली वीपीएन सेवा को पहले से लोड करना, तो:

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

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

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

9.8.5. डिवाइस आइडेंटिफ़ायर

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

• [C-0-1] को किसी ऐप्लिकेशन के सीरियल नंबर और जहां लागू हो वहां IMEI/MEID, सिम के सीरियल नंबर, और इंटरनैशनल मोबाइल सब्सक्राइबर आइडेंटिटी (IMSI) को ऐक्सेस करने से रोकना चाहिए. अगर आपका ऐप्लिकेशन इनमें से किसी एक शर्त को पूरा करता है, तो:
  • मोबाइल और इंटरनेट सेवा देने वाली कंपनी का हस्ताक्षर किया हुआ ऐप्लिकेशन है. इसकी पुष्टि डिवाइस बनाने वाली कंपनियां कर रही हैं.
  • को READ_PRIVILEGED_PHONE_STATE की अनुमति दे दी गई है.
  • के पास, मोबाइल और इंटरनेट सेवा देने वाली कंपनी के अधिकार हैं, जैसा कि यूआईसीसी के मोबाइल और इंटरनेट सेवा देने वाली कंपनी के खास अधिकार में बताया गया है.
  • डिवाइस का मालिक या प्रोफ़ाइल का मालिक है, जिसे READ_PHONE_STATE की अनुमति दी गई है.
  • सिर्फ़ सिम के सीरियल नंबर/आईसीसीआईडी के लिए, स्थानीय कानूनों से जुड़ी वह शर्त है जिसके मुताबिक ऐप्लिकेशन, सदस्य की पहचान में हुए बदलावों के बारे में पता लगाए.

9.8.6. सामग्री कैप्चर

Android, System API ContentCaptureService या किसी अन्य मालिकाना हक वाले तरीके से, डिवाइस पर यह सुविधा लागू करता है, ताकि ऐप्लिकेशन और उपयोगकर्ता के बीच होने वाले इन इंटरैक्शन को कैप्चर किया जा सके.

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

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

• [C-1-1] डिवाइस में सेव किए जाने पर, ऐसे सभी डेटा को एन्क्रिप्ट (सुरक्षित) करना ज़रूरी है. एन्क्रिप्ट (सुरक्षित) करने का यह तरीका, Android फ़ाइल पर आधारित एन्क्रिप्ट (सुरक्षित) करने के तरीके या Cipher SDK टूल में बताए गए, एपीआई वर्शन 26+ के तौर पर लिस्ट किए गए किसी भी साइफ़र का इस्तेमाल करके इस्तेमाल किया जा सकता है.
• [C-1-2] Android पर बैक अप के तरीकों या बैक अप के किसी दूसरे तरीके का इस्तेमाल करके, रॉ या एन्क्रिप्ट किए गए डेटा का बैक अप नहीं लेना चाहिए.
• [C-1-3] ऐसा सभी डेटा और डिवाइस के लॉग को सिर्फ़ निजता बनाए रखने के तरीके का इस्तेमाल करके भेजना ज़रूरी है. निजता बनाए रखने वाले तरीके को "ऐसे उपयोगकर्ता होते हैं जो सिर्फ़ एग्रीगेट डेटा का विश्लेषण करने की अनुमति देते हैं और लॉग किए गए इवेंट या लॉग किए गए इवेंट के डेटा को अलग-अलग उपयोगकर्ताओं से मैच करने से रोकते हैं." इसका मकसद, हर उपयोगकर्ता के डेटा को आत्मविश्वास के साथ अनुभव करने से रोकना है. जैसे, RAPPOR जैसी डिफ़रेंशियल प्राइवसी टेक्नोलॉजी का इस्तेमाल करके लागू किया गया डेटा.
• [C-1-4] इस तरह के डेटा को डिवाइस पर किसी उपयोगकर्ता की पहचान (जैसे कि Account) के साथ नहीं जोड़ना चाहिए. हालांकि, ऐसा करने के लिए हर बार उपयोगकर्ता की सहमति लेना ज़रूरी है.
• [C-1-5] ऐसा डेटा किसी भी दूसरे ऐप्लिकेशन के साथ शेयर नहीं किया जाना चाहिए. हालांकि, हर बार इसे शेयर करने पर, उपयोगकर्ता की सहमति साफ़ तौर पर दी जानी चाहिए.
• [C-1-6] अगर डेटा को डिवाइस पर किसी भी रूप में सेव किया जाता है, तो ContentCaptureService या मालिकाना हक से इकट्ठा किए गए डेटा को मिटाने के लिए, लोगों को ज़रूरी अधिकार देना ज़रूरी है.

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

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

• [सी-एसआर] इस बात का बहुत ज़्यादा सुझाव दिया जाता है कि कॉन्टेंट कैप्चर करने वाले सेवा के कॉम्पोनेंट को अलग रखा जा सके. उदाहरण के लिए, सेवा या शेयर करने की प्रोसेस के आईडी को सिस्टम के अन्य कॉम्पोनेंट से बाइंड न करना. हालांकि, यहां दिए गए कॉम्पोनेंट को छोड़कर:

  • Telephony, संपर्क, सिस्टम यूज़र इंटरफ़ेस (यूआई), और मीडिया

9.8.7. क्लिपबोर्ड का ऐक्सेस

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

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

9.8.8. जगह

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

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

9.9. डेटा स्टोरेज सुरक्षित करने का तरीका

सभी डिवाइसों को सेक्शन 9.9.1 की ज़रूरी शर्तों को पूरा करना होगा. सेक्शन 9.9.2 और 9.9.3 से पहले, एपीआई लेवल पर लॉन्च किए गए डिवाइसों पर, सेक्शन 9.9.2 और 9.9.3 में बताई गई ज़रूरी शर्तें लागू नहीं होंगी. इसके बजाय, उन्हें Android के साथ काम करने की परिभाषा वाले दस्तावेज़ के सेक्शन 9.9 में दी गई ज़रूरी शर्तों को पूरा करना होगा. ये शर्तें, उस एपीआई लेवल से जुड़ी शर्तों को पूरा करती हैं जिस पर डिवाइस लॉन्च किया गया था.

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

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

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

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

9.9.2. एन्क्रिप्ट (सुरक्षित) करने के तरीके की ज़रूरी शर्तें

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

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

9.9.3. फ़ाइल आधारित एन्क्रिप्शन

एन्क्रिप्ट (सुरक्षित) किए गए डिवाइस:

• [C-1-1] उपयोगकर्ता को क्रेडेंशियल के लिए चुनौती दिए बिना चालू होना चाहिए और ACTION_LOCKED_BOOT_COMPLETED मैसेज ब्रॉडकास्ट होने के बाद, डायरेक्ट बूट की जानकारी वाले ऐप्लिकेशन को डिवाइस के एन्क्रिप्ट किए गए (DE) स्टोरेज को ऐक्सेस करने की अनुमति दें.
• [C-1-2] उपयोगकर्ता को क्रेडेंशियल एन्क्रिप्ट किए गए (सीई) स्टोरेज का ऐक्सेस तब ही देना चाहिए, जब उपयोगकर्ता अपने क्रेडेंशियल (जैसे कि पासवर्ड, पिन, पैटर्न या फ़िंगरप्रिंट) देकर डिवाइस को अनलॉक करे और ACTION_USER_UNLOCKED मैसेज ब्रॉडकास्ट हो.
• [C-1-3] उपयोगकर्ता के दिए गए क्रेडेंशियल या रजिस्टर की गई एस्क्रो कुंजी के बिना, CE की मदद से सुरक्षित किए गए स्टोरेज को अनलॉक करने का कोई तरीका ऑफ़र नहीं करना चाहिए.
• [C-1-4] वेरिफ़ाइड बूट का इस्तेमाल करना ज़रूरी है. साथ ही, यह पक्का करें कि डीई कुंजियां, डिवाइस के हार्डवेयर रूट के साथ क्रिप्टोग्राफ़िक तरीके से जुड़ी हों.
• [C-1-5] फ़ाइल के कॉन्टेंट को AES-256-XTS या Adiantum का इस्तेमाल करके एन्क्रिप्ट (सुरक्षित) करना ज़रूरी है. AES-256-XTS का मतलब ऐडवांस्ड एन्क्रिप्शन स्टैंडर्ड है, जिसकी साइफ़र कुंजी 256-बिट की है. इसे XTS मोड में ऑपरेट किया जाता है. इस कुंजी की पूरी लंबाई 512 बिट होती है. Adiantum का मतलब Adiantum-XChaCha12-AES है, जैसा कि https://github.com/google/aiantum पर बताया गया है.
• [C-1-6] फ़ाइलों के नाम को AES-256-CBC-CTS या Adiantum का इस्तेमाल करके एन्क्रिप्ट (सुरक्षित) करना ज़रूरी है.

• [C-1-12] अगर डिवाइस में ऐडवांस्ड एन्क्रिप्शन स्टैंडर्ड (AES) के निर्देश हैं, तो फ़ाइल के कॉन्टेंट के लिए AES-256-XTS और फ़ाइल के नामों के लिए AES-256-CBC-CTS का (Adiantum के बजाय) इस्तेमाल करना ज़रूरी है. एईएस के निर्देश, ARM पर आधारित डिवाइसों पर ARMv8 क्रिप्टोग्राफ़ी एक्सटेंशन या x86 पर आधारित डिवाइसों पर AES-NI के तौर पर इस्तेमाल किए जाते हैं. अगर डिवाइस में एईएस से जुड़े निर्देश नहीं दिए गए हैं, तो डिवाइस Adiantum का इस्तेमाल कर सकता है.

• CE और DE स्टोरेज एरिया की सुरक्षा करने वाली कुंजियां:

• [C-1-7] हार्डवेयर-बैक्ड कीस्टोर से क्रिप्टोग्राफ़िक तौर पर जुड़ा होना ज़रूरी है.

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

• [C-SR] का खास तौर पर सुझाव दिया जाता है कि फ़ाइल सिस्टम के मेटाडेटा, जैसे कि फ़ाइल का साइज़, मालिकाना हक, मोड, और एक्सटेंडेड एट्रिब्यूट (xattrs) को एन्क्रिप्ट (सुरक्षित) किया जाए. इसके लिए, क्रिप्टोग्राफ़िक तरीके से डिवाइस के हार्डवेयर रूट को सुरक्षित रखा जाता है.

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

अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट, Linux कर्नेल "fscrypt" एन्क्रिप्शन सुविधा के आधार पर इस सुविधा को पसंदीदा तरीके से लागू करने की सुविधा देता है.

9.10. डिवाइस इंटिग्रिटी

इन ज़रूरी शर्तों से यह पक्का होता है कि डिवाइस इंटिग्रिटी की स्थिति की जानकारी साफ़ तौर पर दी गई हो. डिवाइस पर यह सुविधा लागू करना:

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

• [C-0-2] डिवाइस इंटिग्रिटी के लिए, वेरिफ़ाइड बूट की सुविधा दी जानी चाहिए.

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

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

• [C-1-1] प्लैटफ़ॉर्म के फ़ीचर फ़्लैग android.software.verified_boot के बारे में बताना ज़रूरी है.
• [C-1-2] ज़रूरी है कि हर बूट क्रम पर पुष्टि करनी हो.
• [C-1-3] ज़रूरी है कि नहीं बदले जा सकने वाले हार्डवेयर कुंजी से, पुष्टि की प्रोसेस शुरू की जाए. यह कुंजी, भरोसे की मूल वजह है और इसे सिस्टम पार्टिशन के लिए इस्तेमाल किया गया है.
• [C-1-4] कोड को अगले चरण में लागू करने से पहले, अगले चरण में सभी बाइट के भरोसेमंद और सही होने की जांच करने के लिए, पुष्टि करने के हर चरण को लागू करना ज़रूरी है.
• [C-1-5] हैशिंग एल्गोरिदम (SHA-256) और सार्वजनिक पासकोड साइज़ (RSA-2048) के लिए, पुष्टि करने वाले एल्गोरिदम का इस्तेमाल, एनआईएसटी से मिले मौजूदा सुझावों जितना ही होना चाहिए.
• [C-1-6] सिस्टम की पुष्टि न हो पाने पर, डिवाइस को बूट करने की अनुमति नहीं देनी चाहिए. ऐसा तब तक नहीं होना चाहिए, जब तक उपयोगकर्ता डिवाइस को फिर से चालू करने की सहमति न दे. ऐसा होने पर, ऐसे स्टोरेज ब्लॉक के डेटा का इस्तेमाल नहीं किया जाएगा जिसकी पुष्टि नहीं हुई है.
• [C-1-7] डिवाइस के ऐसे हिस्सों में बदलाव करने की अनुमति नहीं देनी चाहिए जिनकी पुष्टि हो चुकी है. ऐसा तब तक नहीं होना चाहिए, जब तक उपयोगकर्ता ने साफ़ तौर पर बूटलोडर को अनलॉक न कर दिया हो.
• [C-SR] अगर डिवाइस में कई अलग-अलग चिप हैं (जैसे कि रेडियो, खास इमेज प्रोसेसर), तो बूट करने के हर चरण की पुष्टि करने के लिए उनमें से हर चिप को चालू करने का सुझाव दिया जाता है.
• [C-1-8] छेड़छाड़ करके साफ़ तौर पर दिखने वाले स्टोरेज का इस्तेमाल करना ज़रूरी है: इससे यह स्टोर किया जा सकेगा कि बूटलोडर अनलॉक है या नहीं. डिवाइस में छेड़छाड़ होने का पता चलने पर, बूटलोडर यह पता लगा सकता है कि Android में स्टोरेज के साथ छेड़छाड़ की गई है या नहीं.
• [C-1-9] डिवाइस इस्तेमाल करते समय, उपयोगकर्ता को निर्देश देना होगा. साथ ही, बूटलोडर को लॉक किए गए मोड से बूटलोडर को अनलॉक किए गए मोड में बदलने से पहले, व्यक्ति से उसकी पुष्टि करना ज़रूरी है.
• [C-1-10] Android की ओर से इस्तेमाल किए जाने वाले हिस्सों (जैसे कि बूट, सिस्टम पार्टिशन) के लिए रोलबैक सुरक्षा लागू करना ज़रूरी है. साथ ही, ओएस के सबसे कम वर्शन का पता लगाने के लिए इस्तेमाल किए गए मेटाडेटा को सेव करने के लिए, ऐसे स्टोरेज का इस्तेमाल करें जिससे छेड़छाड़ होती है.
• [C-SR] खास अधिकारों वाले ऐप्लिकेशन APK की सभी फ़ाइलों की पुष्टि करने का सुझाव दिया जाता है. ये ऐसी फ़ाइलें होती हैं जिन्हें पुष्टि करने की प्रक्रिया के दौरान, सेगमेंट में शामिल भरोसेमंद नेटवर्क की चेन का इस्तेमाल किया जाता है.
• [सी-एसआर] का सुझाव इस तरह दिया जाता है कि किसी खास ऐप्लिकेशन के ज़रिए लोड किए गए ऐसे आर्टफ़ैक्ट की पुष्टि की जाए जिसे उसकी APK फ़ाइल के बाहर से लोड किया गया हो. जैसे, डाइनैमिक तरीके से लोड किया गया कोड या कंपाइल किया गया कोड. इसके अलावा, इस बात की बहुत ज़्यादा सलाह दी जाती है कि उन आर्टफ़ैक्ट को एक्ज़ीक्यूट न किया जाए.
• स्थायी फ़र्मवेयर (जैसे मॉडम, कैमरा) वाले किसी भी कॉम्पोनेंट के लिए रोलबैक सुरक्षा लागू करनी चाहिए. साथ ही, सबसे कम अनुमति वाले वर्शन का पता लगाने के लिए इस्तेमाल किए गए मेटाडेटा को सेव करने के लिए, ऐसे स्टोरेज का इस्तेमाल करना चाहिए जिससे छेड़छाड़ न की जा सके.

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

अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट, external/avb/ डेटा स्टोर करने की जगह में इस सुविधा को प्राथमिकता देता है. इसे Android लोड करने के लिए इस्तेमाल किए जाने वाले बूटलोडर में इंटिग्रेट किया जा सकता है.

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

• [C-R] हमारा सुझाव है कि Android Protected Safety API के साथ काम किया जा सके.

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

• [C-3-1] ConfirmationPrompt.isSupported() एपीआई के लिए, true को रिपोर्ट करना ज़रूरी है.

• [C-3-2] यह पक्का करना ज़रूरी है कि Android OS में चलने वाले कोड, जैसे कि उसके कर्नेल, नुकसान पहुंचाने वाले या किसी और तरीके से, उपयोगकर्ता के इंटरैक्शन के बिना सही रिस्पॉन्स जनरेट न कर सके.

• [C-3-3] यह पक्का करना ज़रूरी है कि उपयोगकर्ता, दिखाए गए मैसेज को पढ़कर उसे स्वीकार कर पाए. ऐसा तब भी होता है, जब Android OS और उसके कर्नेल के साथ छेड़छाड़ की गई हो.

9.11. कुंजियां और क्रेडेंशियल

Android कीस्टोर सिस्टम, ऐप्लिकेशन डेवलपर को किसी कंटेनर में क्रिप्टोग्राफ़िक कुंजियों को सेव करने की अनुमति देता है. साथ ही, वे KeyChain API या Keystore API के ज़रिए, क्रिप्टोग्राफ़िक ऑपरेशन में उनका इस्तेमाल कर सकते हैं. डिवाइस पर यह सुविधा लागू करना:

• [C-0-1] कम से कम 8,192 कुंजियों को इंपोर्ट या जनरेट करने की अनुमति देनी होगी.
• [C-0-2] लॉक स्क्रीन से पुष्टि करने की प्रक्रिया के लिए, रेट-सीमा तय करना और एक्सपोनेन्शियल बैकऑफ़ एल्गोरिदम होना ज़रूरी है. हर कोशिश में कम से कम 24 घंटे की देरी होनी चाहिए. 150 बार गलत पिन डालने के बाद भी ऐसा नहीं किया जा सकता.
• जनरेट की जा सकने वाली कुंजियों की संख्या को सीमित नहीं किया जाना चाहिए

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

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

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

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

9.11.1. सुरक्षित लॉक स्क्रीन और पुष्टि करने की सुविधा

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

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

• [सी-एसआर] का सुझाव दिया जाता है कि पुष्टि करने के मुख्य तरीके के तौर पर, इनमें से किसी एक को ही सेट करें:
  • अंकों वाला पिन
  • अक्षरों और अंकों से बना पासवर्ड
  • 3x3 बिंदुओं के ग्रिड पर स्वाइप पैटर्न

ध्यान दें कि ऊपर दिए गए पुष्टि करने के तरीकों को, इस दस्तावेज़ में पुष्टि करने के मुख्य तरीकों के तौर पर दिखाया गया है.

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

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

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

• [C-3-1] इनपुट की सबसे छोटी लंबाई की एंट्रॉपी 10 बिट से ज़्यादा होनी चाहिए.
• [C-3-2] सभी संभावित इनपुट की ज़्यादा से ज़्यादा एंट्रॉपी 18 बिट से ज़्यादा होनी चाहिए.
• [C-3-3] पुष्टि करने के नए तरीके को एओएसपी में लागू और उपलब्ध कराए गए, पुष्टि करने के किसी भी मुख्य तरीके (जैसे, पिन, पैटर्न, पासवर्ड) की जगह इस्तेमाल नहीं करना चाहिए.
• [C-3-4] जब डिवाइस पॉलिसी कंट्रोलर (DPC) ऐप्लिकेशन ने DevicePolicyManager.setPasswordQuality() तरीके का इस्तेमाल करके, पासवर्ड की क्वालिटी से जुड़ी नीति को PASSWORD_QUALITY_SOMETHING से ज़्यादा सीमित क्वालिटी वाली और सेट की हो, तब पुष्टि करने का नया तरीका बंद करना ज़रूरी है.
• [C-3-5] पुष्टि करने के नए तरीकों के लिए, हर 72 घंटे या उससे कम समय में एक बार, सुझाए गए मुख्य तरीकों (जैसे, पिन, पैटर्न, पासवर्ड) का इस्तेमाल करना ज़रूरी है. इसके अलावा, उपयोगकर्ता को साफ़ तौर पर यह भी बताया जाना चाहिए कि उनके डेटा की निजता को बनाए रखने के लिए, उनके कुछ डेटा का बैक अप नहीं लिया जाएगा.

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

• [C-4-1] सुविधा के लिए, सेक्शन 7.3.10 में बताई गई सभी ज़रूरी शर्तों को पूरा करना ज़रूरी है.
• [C-4-2] पुष्टि करने के लिए सुझाए गए मुख्य तरीकों में से किसी एक का इस्तेमाल करने के लिए, फ़ॉल-बैक तरीका (फ़ॉल-बैक तरीका) होना चाहिए. यह तरीका, जानी-पहचानी किसी सीक्रेट जानकारी पर आधारित होना चाहिए.
• [C-4-3] आपको बंद करना होगा और स्क्रीन को अनलॉक करने के लिए, सिर्फ़ सुझाए गए मुख्य तरीके को अनुमति देनी होगी. ऐसा तब ही होगा, जब डिवाइस नीति नियंत्रक (DPC) ऐप्लिकेशन ने किसी भी संबंधित बायोमेट्रिक फ़्लैग (जैसे कि KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE या KEYGUARD_DISABLE_IRIS) का इस्तेमाल करके, DevicePolicyManager.setKeyguardDisabledFeatures() तरीके को कॉल करके कीगार्ड सुविधा की नीति सेट कर दी हो.

अगर बायोमेट्रिक तरीके से पुष्टि करने के तरीके, मज़बूत सेक्शन की ज़रूरी शर्तें पूरी नहीं करते हैं, जैसा कि सेक्शन 7.3.10 में बताया गया है, तो:

• [C-5-1] अगर डिवाइस पॉलिसी कंट्रोलर (DPC) ऐप्लिकेशन ने DevicePolicyManager.setPasswordQuality() तरीके का इस्तेमाल करके, पासवर्ड की क्वालिटी से जुड़ी नीति को PASSWORD_QUALITY_BIOMETRIC_WEAK से ज़्यादा सीमित क्वालिटी वाली और एक जैसी क्वालिटी में सेट किया है, तो इन तरीकों को बंद करना ज़रूरी है.
• [C-5-2] चार घंटे तक काम न करने पर टाइम आउट होने के बाद, उपयोगकर्ता को पुष्टि करने के लिए सुझाए गए मुख्य तरीके (जैसे: पिन, पैटर्न, पासवर्ड) के लिए चुनौती देनी होगी. डिवाइस के क्रेडेंशियल की पुष्टि होने के बाद, इस्तेमाल में न होने की टाइम आउट अवधि को रीसेट कर दिया जाता है.
• [C-5-3] इन तरीकों को सुरक्षित लॉक स्क्रीन नहीं माना जाना चाहिए. साथ ही, इन्हें नीचे दिए गए सेक्शन में C-8 से शुरू होने वाली शर्तों को पूरा करना होगा.

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

• [C-6-1] उनके पास पुष्टि करने के सुझाए गए मुख्य तरीकों में से किसी एक का इस्तेमाल करने के लिए, फ़ॉल-बैक तरीका (फ़ॉल-बैक तरीका) होना चाहिए. यह तरीका, जानी-पहचानी सीक्रेट जानकारी पर आधारित होता है और सुरक्षित लॉक स्क्रीन के तौर पर इस्तेमाल होने से जुड़ी ज़रूरी शर्तों को पूरा करता है.
• [C-6-2] आपको नया तरीका इस्तेमाल करना होगा और पुष्टि करने के सुझाए गए मुख्य तरीकों में से किसी एक को ही स्क्रीन अनलॉक करने की अनुमति देनी होगी. ऐसा तब होगा, जब डिवाइस पॉलिसी कंट्रोलर (DPC) ऐप्लिकेशन ने DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) तरीके से या DevicePolicyManager.setPasswordQuality() तरीके से नीति को PASSWORD_QUALITY_UNSPECIFIED से ज़्यादा सीमित क्वालिटी वाली पर सेट किया हो.
• [C-6-3] उपयोगकर्ता को हर चार घंटे में कम से कम एक बार, पुष्टि करने के लिए सुझाए गए मुख्य तरीकों (जैसे, पिन, पैटर्न, पासवर्ड) में से किसी एक को अपनाना होगा.
• [C-6-4] इस नए तरीके को सुरक्षित लॉक स्क्रीन नहीं माना जाना चाहिए. साथ ही, इसे नीचे C-8 में बताई गई शर्तों का पालन करना होगा.

अगर लागू किए जाने वाले डिवाइस में एक सुरक्षित लॉक स्क्रीन है और उसमें एक या एक से ज़्यादा ऐसे भरोसेमंद एजेंट शामिल हैं जो TrustAgentService System API को लागू करते हैं, तो वे:

• [C-7-1] डिवाइस के लॉक में देरी होने या उसे भरोसेमंद एजेंट के अनलॉक रखने पर, सेटिंग मेन्यू और लॉक स्क्रीन पर साफ़ तौर पर इसकी सूचना दी जानी चाहिए. उदाहरण के लिए, एओएसपी इस ज़रूरी शर्त को पूरा करने के लिए, सेटिंग मेन्यू में "अपने-आप लॉक होने की सेटिंग" और "पावर बटन से तुरंत लॉक हो जाता है" के बारे में टेक्स्ट की जानकारी दिखाता है. साथ ही, लॉक स्क्रीन पर एक अलग आइकॉन भी दिखाता है.
• [C-7-2] DevicePolicyManager क्लास में सभी ट्रस्ट एजेंट एपीआई का पालन करना चाहिए और उन्हें पूरी तरह से लागू करना चाहिए. जैसे, KEYGUARD_DISABLE_TRUST_AGENTS कॉन्सटेंट.
• [C-7-3] ऐसे डिवाइस पर TrustAgentService.addEscrowToken() फ़ंक्शन को पूरी तरह लागू नहीं करना चाहिए जिसे मुख्य निजी डिवाइस (जैसे कि हैंडहेल्ड) के तौर पर इस्तेमाल किया जाता हो. हालांकि, इसे आम तौर पर शेयर किए जाने वाले डिवाइस (जैसे कि Android टेलीविज़न या Automotive डिवाइस) पर लागू करने की सुविधा को पूरी तरह लागू किया जा सकता है.
• [C-7-4] TrustAgentService.addEscrowToken() के जोड़े गए सभी स्टोर किए गए टोकन को एन्क्रिप्ट (सुरक्षित) करना ज़रूरी है.
• [C-7-5] एन्क्रिप्शन कुंजी या एस्क्रो टोकन को उस डिवाइस पर सेव नहीं किया जाना चाहिए जिस पर कुंजी का इस्तेमाल किया गया है. उदाहरण के लिए, फ़ोन पर सेव की गई कुंजी के ज़रिए, टीवी पर उपयोगकर्ता खाते को अनलॉक किया जा सकता है.
• [C-7-6] डेटा स्टोरेज को डिक्रिप्ट करने के लिए, एस्क्रो टोकन चालू करने से पहले, उपयोगकर्ता को सुरक्षा से जुड़ी समस्याओं के बारे में बताना ज़रूरी है.
• [C-7-7] पुष्टि करने के लिए सुझाए गए मुख्य तरीकों में से किसी एक का इस्तेमाल करने के लिए, फ़ॉल-बैक तरीका होना ज़रूरी है.
• [C-7-8] उपयोगकर्ता को हर 72 घंटे में कम से कम एक बार, पुष्टि करने के लिए सुझाए गए मुख्य तरीकों (जैसे: पिन, पैटर्न, पासवर्ड) में से किसी एक को अपनाना होगा. ऐसा सिर्फ़ तब किया जा सकता है, जब उपयोगकर्ता की सुरक्षा को लेकर कोई समस्या (जैसे कि ड्राइवर का ध्यान भटकना) न हो.
• [C-7-9] अगर उपयोगकर्ता की सुरक्षा को लेकर कोई समस्या नहीं है, तो उसे चार घंटे के लिए बंद होने के बाद, पुष्टि करने के लिए सुझाए गए मुख्य तरीकों (जैसे: पिन, पैटर्न, पासवर्ड) में से किसी एक को अपनाना होगा. उदाहरण के लिए, ड्राइवर का ध्यान भटकना. डिवाइस के क्रेडेंशियल की पुष्टि होने के बाद, इस्तेमाल में न होने की टाइम आउट अवधि को रीसेट कर दिया जाता है.
• [C-7-10] को सुरक्षित लॉक स्क्रीन नहीं माना जाना चाहिए और नीचे C-8 में बताई गई शर्तों का पालन करना चाहिए.
• [C-7-11] प्राइमरी निजी डिवाइसों (जैसे कि हैंडहेल्ड) पर TrustAgents को डिवाइस अनलॉक करने की अनुमति नहीं देनी चाहिए.उनका इस्तेमाल सिर्फ़ पहले से अनलॉक किए गए डिवाइस को ज़्यादा से ज़्यादा चार घंटे तक अनलॉक रखने के लिए किया जा सकता है. एओएसपी में TrustManagerService को डिफ़ॉल्ट रूप से लागू करने की सुविधा इस ज़रूरी शर्त को पूरा करती है.
• [C-7-12] स्टोरेज डिवाइस से टारगेट किए गए डिवाइस में एस्क्रो टोकन भेजने के लिए, क्रिप्टोग्राफ़िक तौर पर सुरक्षित (जैसे, UKEY2) कम्यूनिकेशन चैनल का इस्तेमाल करना ज़रूरी है.

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

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

9.11.2. स्ट्रॉन्गबॉक्स

Android कीस्टोर सिस्टम, ऐप्लिकेशन डेवलपर को क्रिप्टोग्राफ़िक कुंजियों को किसी सुरक्षित प्रोसेसर में सेव करने देता है. साथ ही, वे इसे इस्तेमाल किए जाने के लिए, ऊपर बताए गए अलग-अलग एनवायरमेंट में भी सेव कर सकते हैं. ऐसे ही एक सुरक्षित प्रोसेसर को "StrongBox" कहा जाता है. यहां C-1-3 से लेकर C-1-11 तक की उन शर्तों के बारे में बताया गया है जो StrongBox के लिए ज़रूरी शर्तें पूरी करती हैं.

लागू किए गए डिवाइस जिनमें एक खास सुरक्षित प्रोसेसर होता है:

• StrongBox के साथ काम करने के लिए [C-SR] का खास तौर पर सुझाव दिया जाता है. आने वाली रिलीज़ में StrongBox की ज़रूरत बन सकती है.

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

• [C-1-1] FEATURE_STRONGBOX_KEYSTORE का एलान करना ज़रूरी है.

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

• [C-1-3] ज़रूरी है कि आपके पास एक अलग सीपीयू हो, जो ऐप्लिकेशन प्रोसेसर (AP) के साथ कैश, डीरैम, को-प्रोसेसर या दूसरे मुख्य संसाधनों को शेयर नहीं करता हो.

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

• [C-1-5] ज़रूरी सटीक (+-10%) वाली एक इंटरनल घड़ी होनी चाहिए. इसमें AP की ओर से बदलाव किए जाने का कोई असर नहीं होता.

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

• [C-1-7] शरीर को छेड़ने से रोकने की क्षमता का होना ज़रूरी है. इसमें, शरीर के किसी हिस्से में जाने और ग्लिच से बचाव भी शामिल है.

• [C-1-8] साइड चैनल के लिए रेज़िस्टेंस होना ज़रूरी है. इसमें पावर, टाइमिंग, इलेक्ट्रोमैग्नेटिक रेडिएशन, और थर्मल रेडिएशन वाले साइड चैनलों से जानकारी लीक होने से रोकने की क्षमता भी शामिल है.

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

• इस बात की पुष्टि करने के लिए कि [C-1-3] से [C-1-9] तक का पालन किया गया है या नहीं, डिवाइस पर ये सुविधाएं लागू की जाती हैं:

  • [C-1-10] ऐसा हार्डवेयर शामिल करना ज़रूरी है जो सुरक्षित आईसी प्रोटेक्शन प्रोफ़ाइल BSI-CC-PP-0084-2014 से सर्टिफ़ाइड है या जिसका आकलन राष्ट्रीय स्तर की किसी टेस्टिंग लैबोरेट्री से किया गया है. इसमें जोखिम की संभावना का आकलन करने के लिए, स्मार्टकार्ड पर हमले की संभावना का सामान्य मानदंड के तहत आकलन किया गया है.
  • [C-1-11] फ़र्मवेयर को शामिल करना ज़रूरी है. इसका आकलन, राष्ट्रीय स्तर पर मान्यता पा चुकी टेस्टिंग लैबोरेट्री से किया गया है. इसमें अटैक पोटेंशियल ऐप्लिकेशन ऑफ़ स्मार्टकार्ड्स के मुताबिक, जोखिम की संभावना का ज़्यादा से ज़्यादा आकलन किया गया है.
  • [सी-एसआर] हमारा सुझाव है कि इसमें वह हार्डवेयर शामिल किया जाए जिसका आकलन AVA_VAN.5 की मदद से, सुरक्षा टारगेट, इवैलुएशन अश्योरेंस लेवल (ईएएल) 5 का इस्तेमाल करके किया जाता है. आने वाले समय में, EAL 5 सर्टिफ़िकेशन ज़रूरी हो सकता है.

• [C-SR] का इनसाइडर अटैक रेज़िस्टेंस (IAR) देने के लिए बहुत ज़्यादा सुझाव दिया जाता है. इसका मतलब है कि फ़र्मवेयर साइनिंग कुंजियों का ऐक्सेस रखने वाला इनसाइडर ऐसा फ़र्मवेयर नहीं बना सकता जिसकी वजह से StrongBox, सुरक्षा से जुड़ी ज़रूरी शर्तों को बायपास कर सके या उपयोगकर्ता के संवेदनशील डेटा का ऐक्सेस चालू कर सके. IAR लागू करने का सुझाया गया तरीका, फ़र्मवेयर अपडेट की अनुमति सिर्फ़ तब देना है, जब IAuthSecret HAL के ज़रिए मुख्य उपयोगकर्ता पासवर्ड दिया गया हो.

9.12. डेटा हटाना

लागू किए गए सभी डिवाइस:

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

9.13. सुरक्षित बूट मोड

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

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

• [SR] सुरक्षित बूट मोड लागू करने के लिए खास तौर पर सुझाव दिया जाता है.

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

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

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

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

9.14. ऑटोमोटिव व्हीकल सिस्टम आइसोलेशन

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

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

9.15. सदस्यता प्लान

"सदस्यता प्लान" का मतलब है, बिलिंग के लिए तय किए गए उस प्लान की जानकारी जिसे मोबाइल और इंटरनेट सेवा देने वाली कंपनी, SubscriptionManager.setSubscriptionPlans() को मुहैया कराती है.

लागू किए गए सभी डिवाइस:

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

10. सॉफ़्टवेयर के साथ काम करने से जुड़ी जांच

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

10.1. कंपैटबिलिटी टेस्ट सुइट

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

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

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

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

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

• [C-0-3] डिवाइस का सॉफ़्टवेयर पूरा होने के बाद, सीटीएस का सबसे नया वर्शन पास करना ज़रूरी है.

• Android ओपन सोर्स ट्री में जहां तक संभव हो, रेफ़रंस इंप्लिमेंटेशन का इस्तेमाल करना चाहिए.

10.2. सीटीएस वेरिफ़ायर

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

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

• [C-0-1] सीटीएस की पुष्टि करने वाले टूल में, लागू होने वाले सभी मामलों का सही तरीके से पालन करना ज़रूरी है.

CTS Verifier में कई तरह के हार्डवेयर की जांच की जा सकती है. इनमें कुछ ऐसे हार्डवेयर भी शामिल हैं जो ज़रूरी नहीं होते.

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

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

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

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

11. अपडेट किया जा सकने वाला सॉफ़्टवेयर

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

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

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

• [C-0-3] पूरे अपडेट पर हस्ताक्षर करना ज़रूरी है. साथ ही, डिवाइस पर मौजूद अपडेट के तरीके से, डिवाइस पर सेव किए गए सार्वजनिक पासकोड से अपडेट और हस्ताक्षर की पुष्टि करनी होगी.

• [C-SR] अपडेट को SHA-256 के साथ हैश करने और ECDSA NIST P-256 का इस्तेमाल करके हैश की पुष्टि सार्वजनिक पासकोड से करने के लिए, हस्ताक्षर करने के तरीके पर बहुत ज़्यादा ध्यान दिया जाता है.

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

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

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

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

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

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

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

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

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

इस रिलीज़ में 'कंपैटबिलिटी डेफ़िनिशन' में हुए बदलावों की खास जानकारी के लिए:

• दस्तावेज़ में बदलाव का लॉग

अलग-अलग सेक्शन में हुए बदलावों की खास जानकारी के लिए:

1. शुरुआती जानकारी
2. डिवाइस के टाइप
3. सॉफ़्टवेयर
4. ऐप्लिकेशन पैकेजिंग
5. मल्टीमीडिया
6. डेवलपर टूल और विकल्प
7. हार्डवेयर पर काम करता है
8. परफ़ॉर्मेंस और पावर
9. सुरक्षा मॉडल
10. सॉफ़्टवेयर के साथ काम करने से जुड़ी जांच
11. अपडेट किया जा सकने वाला सॉफ़्टवेयर
12. दस्तावेज़ में बदलावों का लॉग
13. हमसे संपर्क करें

12.1. बदलावों का लॉग देखने से जुड़ी सलाह

बदलावों को इस तरह मार्क किया गया है:

• सीडीडी
  इसके साथ काम करने की ज़रूरी शर्तों में किए गए बड़े बदलाव.

• Docs
  कॉस्मेटिक का इस्तेमाल करें या उससे जुड़े बदलाव करें.

बेहतर तरीके से देखने के लिए, अपने चेंजलॉग यूआरएल में pretty=full और no-merges यूआरएल पैरामीटर जोड़ें.

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

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