इस पेज का अनुवाद Cloud Translation API से किया गया है.

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

1. परिचय

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2. हैंडहेल्ड डिवाइस से जुड़ी ज़रूरी शर्तें

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

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

इसमें बैटरी जैसा कोई पावर सोर्स होना चाहिए.
डिवाइस की डायगनल स्क्रीन का साइज़ 3.3 इंच (या एपीआई लेवल 29 या उससे पहले के वर्शन पर शिप किए गए डिवाइसों के लिए 2.5 इंच) से 8 इंच के बीच होना चाहिए.

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

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

2.2.1. हार्डवेयर

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

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

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

[7.1.1.1/H-1-1]* तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराई गई लॉजिकल स्क्रीन के छोटे किनारों की लंबाई कम से कम दो इंच और लंबे किनारों की लंबाई कम से कम 2.7 इंच होनी चाहिए. Android के एपीआई लेवल 29 या उससे पहले के वर्शन वाले डिवाइसों को इस ज़रूरी शर्त से छूट मिल सकती है.

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

[7.1.1.1/H-2-1]* तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराई गई लॉजिकल स्क्रीन के छोटे किनारे की लंबाई कम से कम 2.7 इंच होनी चाहिए. Android के एपीआई लेवल 29 या उससे पहले के वर्शन वाले डिवाइसों को इस ज़रूरी शर्त से छूट मिल सकती है.

अगर हैंडहेल्ड डिवाइस पर 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.4.6/H-0-1] यह ज़रूरी है कि डिवाइस, सिस्टम प्रॉपर्टी graphics.gpu.profiler.support की मदद से, जीपीयू की प्रोफ़ाइलिंग की सुविधा के साथ काम करता है या नहीं, इसकी जानकारी दे.

अगर हैंडहेल्ड डिवाइस के लागू होने की जानकारी, सिस्टम प्रॉपर्टी के ज़रिए दी जाती है graphics.gpu.profiler.support, तो:

[7.1.4.6/H-1-1] आउटपुट के तौर पर, ऐसा प्रोटोबस ट्रेस दिखाना ज़रूरी है जो Perfetto दस्तावेज़ में बताए गए जीपीयू काउंटर और जीपीयू रेंडरस्टेज के स्कीमा के मुताबिक हो.
[7.1.4.6/H-1-2] डिवाइस के GPU काउंटर के लिए, gpu काउंटर ट्रेस पैकेट प्रोटो का पालन करके, ज़रूरी है कि सही वैल्यू रिपोर्ट की जाएं.
[7.1.4.6/H-1-3] डिवाइस के GPU रेंडर स्टेज के लिए, रेंडर स्टेज ट्रेस पैकेट प्रोटो के मुताबिक, सही वैल्यू रिपोर्ट करना ज़रूरी है.
[7.1.4.6/H-1-4] जीपीयू फ़्रीक्वेंसी ट्रैसपॉइंट की रिपोर्ट ज़रूर देनी चाहिए. यह रिपोर्ट, power/gpu_frequency फ़ॉर्मैट में दी जानी चाहिए.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[7.6.1/H-1-1] अगर डिफ़ॉल्ट डिसप्ले में qHD (जैसे, FWVGA) तक के फ़्रेमबफ़र रिज़ॉल्यूशन का इस्तेमाल किया जाता है, तो कर्नेल और यूज़रस्पेस के लिए कम से कम 416 एमबी मेमोरी होनी चाहिए.
[7.6.1/H-2-1] अगर डिफ़ॉल्ट डिसप्ले में एचडी+ (जैसे, एचडी, WSVGA) तक के फ़्रेमबफ़र रिज़ॉल्यूशन का इस्तेमाल किया जाता है, तो कर्नेल और यूज़रस्पेस के लिए कम से कम 592 एमबी मेमोरी उपलब्ध होनी चाहिए.
[7.6.1/H-3-1] अगर डिफ़ॉल्ट डिसप्ले, एफ़एचडी (उदाहरण के लिए, WSXGA+) तक के फ़्रेमबफ़र रिज़ॉल्यूशन का इस्तेमाल करता है, तो कर्नेल और यूज़रस्पेस के लिए कम से कम 896 एमबी मेमोरी होनी चाहिए.
[7.6.1/H-4-1] अगर डिफ़ॉल्ट डिसप्ले में क्वाड हाई डेफ़िनिशन (क्यूएचडी) तक के फ़्रेमबफ़र रिज़ॉल्यूशन (जैसे, QWXGA) का इस्तेमाल किया जाता है, तो कर्नेल और यूज़रस्पेस के लिए उपलब्ध मेमोरी कम से कम 1344 एमबी होनी चाहिए.

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

[7.6.1/H-5-1] अगर डिफ़ॉल्ट डिसप्ले में qHD (उदाहरण के लिए, FWVGA) तक के फ़्रेमबफ़र रिज़ॉल्यूशन का इस्तेमाल किया जाता है, तो कर्नेल और यूज़रस्पेस के लिए कम से कम 816 एमबी मेमोरी उपलब्ध होनी चाहिए.
[7.6.1/H-6-1] अगर डिफ़ॉल्ट डिसप्ले में एचडी+ (जैसे, एचडी, WSVGA) तक के फ़्रेमबफ़र रिज़ॉल्यूशन का इस्तेमाल किया जाता है, तो कर्नेल और यूज़रस्पेस के लिए कम से कम 944 एमबी मेमोरी होनी चाहिए.
[7.6.1/H-7-1] अगर डिफ़ॉल्ट डिसप्ले, एफ़एचडी (उदाहरण के लिए, WSXGA+) तक के फ़्रेमबफ़र रिज़ॉल्यूशन का इस्तेमाल करता है, तो कर्नेल और यूज़रस्पेस के लिए उपलब्ध मेमोरी कम से कम 1280 एमबी होनी चाहिए.
[7.6.1/H-8-1] अगर डिफ़ॉल्ट डिसप्ले में क्यूएचडी (उदाहरण के लिए, 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 का एलान करना चाहिए.

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

[7.6.1/H-SR-1] हमारा सुझाव है कि आप सिर्फ़ 32-बिट यूज़रस्पेस (ऐप्लिकेशन और सिस्टम कोड, दोनों) के साथ काम करें

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

[7.6.1/H-1-1] सिर्फ़ एक एबीआई (सिर्फ़ 64-बिट या सिर्फ़ 32-बिट) के साथ काम करना चाहिए.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[7.8.2.2/H-4-1] अगर यूएसबी ऑडियो टर्मिनल टाइप फ़ील्ड 0x0302 है, तो AudioDeviceInfo.TYPE_USB_HEADSET टाइप का डिवाइस और भूमिका isSink() ज़रूर शामिल करें.
[7.8.2.2/H-4-2] अगर USB ऑडियो टर्मिनल टाइप फ़ील्ड 0x0402 है, तो डिवाइस के टाइप के तौर पर AudioDeviceInfo.TYPE_USB_HEADSET और भूमिका के तौर पर isSink() की जानकारी देना ज़रूरी है.
[7.8.2.2/H-4-3] अगर यूएसबी ऑडियो टर्मिनल टाइप फ़ील्ड 0x0402 है, तो टाइप के तौर पर AudioDeviceInfo.TYPE_USB_HEADSET और भूमिका isSource() वाला डिवाइस ज़रूर शामिल करना चाहिए.
[7.8.2.2/H-4-4] AudioDeviceInfo.TYPE_USB_DEVICE टाइप का डिवाइस और भूमिका isSink() की सूची ज़रूर होनी चाहिए. ऐसा तब करना होगा, जब यूएसबी ऑडियो टर्मिनल टाइप फ़ील्ड 0x603 हो.
[7.8.2.2/H-4-5] अगर यूएसबी ऑडियो टर्मिनल टाइप फ़ील्ड 0x604 है, तो डिवाइस के टाइप के तौर पर AudioDeviceInfo.TYPE_USB_DEVICE और भूमिका के तौर पर isSource() की जानकारी देना ज़रूरी है.
[7.8.2.2/H-4-6] अगर USB ऑडियो टर्मिनल टाइप फ़ील्ड 0x400 है, तो टाइप AudioDeviceInfo.TYPE_USB_DEVICE और भूमिका isSink() वाले डिवाइस की सूची ज़रूर होनी चाहिए.
[7.8.2.2/H-4-7] अगर यूएसबी ऑडियो टर्मिनल टाइप फ़ील्ड 0x400 है, तो डिवाइस के टाइप के तौर पर AudioDeviceInfo.TYPE_USB_DEVICE और भूमिका के तौर पर isSource() की जानकारी देना ज़रूरी है.
[7.8.2.2/H-SR-1] USB-C ऑडियो डिवाइस को कनेक्ट करने पर, इनका इस्तेमाल करने का ज़रूर सुझाव दिया जाता है. इससे, USB डिस्क्रिप्टर की गिनती की जा सकती है, टर्मिनल टाइप की पहचान की जा सकती है, और 1,000 मिलीसेकंड से भी कम समय में Intent ACTION_HEADSET_PLUG ब्रॉडकास्ट किया जा सकता है.

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

[5.6(#56_audio-latency)/H-1-1] में, पांच मेज़रमेंट के लिए, लगातार राउंड-ट्रिप के औसत इंतज़ार का समय 800 मिलीसेकंड या उससे कम होना चाहिए. साथ ही, कम से कम एक काम करने वाले पाथ पर, औसत एब्सोल्यूट डिविएशन 100 मिलीसेकंड से कम होना चाहिए.

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

[7.10/H]* इसमें एक्ससेंट्रिक रोटेटेड मैस (ईआरएम) वाले हैप्टिक ऐक्चुएटर (वाइब्रेटर) का इस्तेमाल नहीं किया जाना चाहिए.
[7.10/H]* ऐक्चुएटर को उस जगह के आस-पास रखना चाहिए जहां आम तौर पर डिवाइस को हाथ से पकड़ा जाता है या छुआ जाता है.
[7.10/H]* android.view.HapticFeedbackConstants में, साफ़ हप्टिक्स के लिए सभी सार्वजनिक कॉन्स्टेंट लागू करने चाहिए. जैसे, CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY, VIRTUAL_KEY_RELEASE, CONFIRM, REJECT, GESTURE_START, और GESTURE_END.
[7.10/H]* android.os.VibrationEffect में, साफ़ हप्टिक्स के लिए सभी सार्वजनिक कॉन्स्टेंट लागू करने चाहिए. जैसे, (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK, और EFFECT_DOUBLE_CLICK). साथ ही, android.os.VibrationEffect.Composition में, रिच हप्टिक्स के लिए सभी सार्वजनिक कॉन्स्टेंट लागू करने चाहिए. जैसे, (PRIMITIVE_CLICK और PRIMITIVE_TICK).
[7.10/H]* को इन लिंक किए गए हैप्टिक कॉन्स्टेंट मैपिंग का इस्तेमाल करना चाहिए.
[7.10/घंटा]* को createOneShot() और createWaveform() एपीआई के लिए, क्वालिटी आकलन का पालन करना चाहिए.
[7.10/एच]* को android.os.Vibrator.hasAmplitudeControl() को चलाकर, ऐम्प्लिट्यूड को स्केल करने की क्षमताओं की पुष्टि करनी चाहिए.

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

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

[7.10/H]* हैप्टिक ऐक्चुएटर को पोर्ट्रेट ओरिएंटेशन के X-ऐक्सिस में ले जाना चाहिए.

अगर हैंडहेल्ड डिवाइस में X-ऐक्सिस वाला लिनियर रेज़ॉनैंट ऐक्चुएटर (एलआरए) हैप्टिक ऐक्चुएटर है, तो:

[7.10/H]* में, X-ऐक्सिस के LRA की अनुनाद फ़्रीक्वेंसी 200 हर्ट्ज़ से कम होनी चाहिए.

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

[7.10/H]* android.os.Vibrator.areAllEffectsSupported() और android.os.Vibrator.arePrimitvesSupported() एपीआई को चलाकर, लागू करने की स्थिति की पुष्टि करनी चाहिए.
[7.10/घंटा]* को वाइब्रेशन के लिए, क्वालिटी का आकलन करना चाहिए.
[7.10/H]* को फ़ॉलबैक सहायता देनी चाहिए, ताकि गड़बड़ी के जोखिम को कम किया जा सके. इस बारे में यहां बताया गया है.

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

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

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

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

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

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

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

2.2.3. सॉफ़्टवेयर

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

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

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

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

अगर हैंडहेल्ड डिवाइस पर conversation notifications की सुविधा काम करती है और सूचनाओं को सूचना देने वाली और साइलेंट मोड में मिलने वाली सूचनाओं से अलग सेक्शन में रखा जाता है, तो:

[3.8.4/H-1-1]* बातचीत से जुड़ी सूचनाओं को, बातचीत से जुड़ी सूचनाओं के अलावा अन्य सूचनाओं से पहले दिखाना ज़रूरी है. हालांकि, फ़ोरग्राउंड सेवा की चल रही सूचनाओं और ज़रूरत के हिसाब से:ज़्यादा वाली सूचनाओं को छोड़कर.

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

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

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

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

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

[3.8.16/H-1-1] सुविधा के लिए, फ़्लैग android.software.controls का एलान करना ज़रूरी है और इसे true पर सेट करना ज़रूरी है.
[3.8.16/H-1-2] ऐप्लिकेशन में, उपयोगकर्ता को ControlsProviderService और Control एपीआई की मदद से, तीसरे पक्ष के ऐप्लिकेशन के रजिस्टर किए गए कंट्रोल में से, अपने डिवाइस के पसंदीदा कंट्रोल जोड़ने, उनमें बदलाव करने, उन्हें चुनने, और इस्तेमाल करने की सुविधा देनी ज़रूरी है.
[3.8.16/H-1-3] डिफ़ॉल्ट लॉन्चर से तीन इंटरैक्शन के अंदर, उपयोगकर्ता को इस सुविधा का ऐक्सेस देना ज़रूरी है.
[3.8.16/H-1-4] इस यूज़र अवर्डेंस में, तीसरे पक्ष के हर उस ऐप्लिकेशन का नाम और आइकॉन सटीक तरीके से रेंडर करना ज़रूरी है जो ControlsProviderService एपीआई के ज़रिए कंट्रोल उपलब्ध कराता है. साथ ही, Control एपीआई से मिले किसी भी खास फ़ील्ड को भी रेंडर करना ज़रूरी है.

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

[3.8.16/H-2-1] ControlsProviderService और Control एपीआई के लिए, null की जानकारी देना ज़रूरी है.
[3.8.16/H-2-2] सुविधा के लिए, फ़्लैग android.software.controls का एलान करना ज़रूरी है और इसे false पर सेट करना ज़रूरी है.

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

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

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

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

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

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

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

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

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

[3.9/H-1-2] android.software.managed_users सुविधा फ़्लैग की मदद से, मैनेज की जा रही प्रोफ़ाइलों के साथ काम करने की सुविधा के बारे में ज़रूर बताएं.

अगर Android वाले हैंडहेल्ड डिवाइस में, android.hardware.camera.any के ज़रिए कैमरे के काम करने की जानकारी दी गई है, तो:

[7.5.4/H-1-1] SDK टूल में बताए गए तरीके के मुताबिक, android.media.action.STILL_IMAGE_CAMERA और android.media.action.STILL_IMAGE_CAMERA_SECURE इंटेंट को पूरा करना ज़रूरी है. साथ ही, कैमरे को स्टिल इमेज मोड में लॉन्च करना ज़रूरी है.
[7.5.4/H-1-2] SDK टूल में बताए गए तरीके के मुताबिक, कैमरे को वीडियो मोड में लॉन्च करने के लिए, android.media.action.VIDEO_CAMERA के इरादे का सम्मान करना ज़रूरी है.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Android, System API VoiceInteractionService की मदद से, माइक्रोफ़ोन ऐक्सेस करने के बारे में सूचना दिए बिना, हमेशा चालू रहने वाले हॉटवर्ड की पहचान करने की सुविधा देता है

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

[9.8/H-1-1] यह पक्का करना ज़रूरी है कि हॉटवर्ड की पहचान करने वाली सेवा, सिर्फ़ सिस्टम या ContentCaptureService को डेटा भेज सके
[9.8/H-1-2] यह पक्का करना ज़रूरी है कि बोले गए शब्दों को पहचानने वाली सेवा, माइक से रिकॉर्ड किए गए ऑडियो डेटा या उससे मिला डेटा, सिर्फ़ HotwordDetectionService एपीआई की मदद से सिस्टम सर्वर पर भेजे. इसके अलावा, ContentCaptureService को ContentCaptureManager एपीआई की मदद से डेटा भेजा जा सकता है.
[9.8/H-1-3] हार्डवेयर से ट्रिगर किए गए किसी अनुरोध के लिए, माइक से रिकॉर्ड किया गया ऑडियो 30 सेकंड से ज़्यादा का नहीं होना चाहिए. यह अनुरोध, बोले गए शब्दों का पता लगाने वाली सेवा के लिए किया जाता है.
[9.8/H-1-4] हॉटवर्ड की पहचान करने वाली सेवा के लिए, किसी व्यक्ति के अनुरोध पर, 8 सेकंड से ज़्यादा पुराना बफ़र किया गया माइक्रोफ़ोन ऑडियो नहीं दिया जाना चाहिए.
[9.8/H-1-5] वॉइस इंटरैक्शन सेवा या इसी तरह की इकाई को, बफ़र किया गया ऐसा माइक ऑडियो नहीं देना चाहिए जो 30 सेकंड से ज़्यादा पुराना हो.
[9.8/H-1-6] हॉटवर्ड का पता लगाने वाली सेवा के हर सही नतीजे पर, 100 बाइट से ज़्यादा डेटा को ट्रांसमिट करने की अनुमति नहीं दी जानी चाहिए.
[9.8/H-1-7] हॉटवर्ड का पता लगाने वाली सेवा से, हर नेगेटिव हॉटवर्ड के नतीजे के लिए, ज़्यादा से ज़्यादा पांच बिट का डेटा भेजा जाना चाहिए.
[9.8/H-1-8] सिस्टम सर्वर से, हॉटवर्ड की पुष्टि करने के अनुरोध पर ही, हॉटवर्ड का पता लगाने वाली सेवा से डेटा ट्रांसफ़र करने की अनुमति होनी चाहिए.
[9.8/H-1-9] उपयोगकर्ता के इंस्टॉल किए जा सकने वाले ऐप्लिकेशन को, हॉटवर्ड का पता लगाने की सेवा देने की अनुमति नहीं दी जानी चाहिए.
[9.8/H-1-10] हॉटवर्ड की पहचान करने वाली सेवा के ज़रिए माइक के इस्तेमाल के बारे में, यूज़र इंटरफ़ेस (यूआई) में संख्या के हिसाब से डेटा नहीं दिखना चाहिए.
[9.8/H-1-11] सुरक्षा से जुड़े शोधकर्ताओं को जांच करने की अनुमति देने के लिए, हॉटवर्ड की पहचान करने वाली सेवा से हर ट्रांसमिशन में शामिल बाइट की संख्या को लॉग करना ज़रूरी है.
[9.8/H-1-12] यह ज़रूरी है कि डिवाइस में डीबग मोड की सुविधा हो. इससे, हॉटवर्ड डिटेक्शन सेवा से हर ट्रांसमिशन के रॉ कॉन्टेंट को लॉग किया जा सकता है. इससे, सुरक्षा से जुड़े शोधकर्ताओं को जांच करने में मदद मिलती है.
[9.8/H-1-13] हॉटवर्ड की पहचान करने वाली सेवा को होस्ट करने वाली प्रोसेस को कम से कम हर घंटे या हर 30 हार्डवेयर-ट्रिगर इवेंट में से जो भी पहले आए, तब फिर से शुरू करना ज़रूरी है.
[9.8/H-1-14] जब वॉइस इंटरैक्शन सेवा या मिलती-जुलती इकाई को हॉटवर्ड का सही नतीजा भेजा जाता है, तो माइक्रोफ़ोन इंडिकेटर दिखाना ज़रूरी है. इस बारे में 9.8.2 सेक्शन में बताया गया है.
[9.8/H-SR-1] हमारा सुझाव है कि किसी ऐप्लिकेशन को, बोले गए शब्दों को पहचानने की सेवा देने वाली कंपनी के तौर पर सेट करने से पहले, उपयोगकर्ताओं को इसकी सूचना दें.
[9.8/H-SR-2] हमारा सुझाव है कि आप हॉटवर्ड की पहचान करने वाली सेवा से, बिना स्ट्रक्चर वाले डेटा को ट्रांसफ़र करने की अनुमति न दें.

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

[9.8/H-2-1] इस्तेमाल किए जा सकने वाले हर हॉटवर्ड वाक्यांश के लिए, उपयोगकर्ता को साफ़ तौर पर सूचना देना ज़रूरी है.
[9.8/H-2-2] हॉटवर्ड की पहचान करने वाली सेवा की मदद से, रॉ ऑडियो डेटा या उससे मिला डेटा सेव नहीं किया जाना चाहिए.
[9.8/H-2-3] हॉटवर्ड का पता लगाने वाली सेवा से, ऑडियो डेटा, ऐसा डेटा नहीं भेजना चाहिए जिसका इस्तेमाल ऑडियो को पूरी तरह या कुछ हद तक फिर से बनाने के लिए किया जा सकता है. इसके अलावा, हॉटवर्ड से जुड़े ऑडियो कॉन्टेंट को छोड़कर, किसी और कॉन्टेंट को भी नहीं भेजना चाहिए. हालांकि, ContentCaptureService को यह डेटा भेजा जा सकता है.

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

[9.8.2/H-4-1] जब कोई ऐप्लिकेशन माइक्रोफ़ोन से ऑडियो डेटा ऐक्सेस कर रहा हो, तो माइक्रोफ़ोन इंडिकेटर दिखाना ज़रूरी है. हालांकि, जब माइक्रोफ़ोन को सिर्फ़ HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService या CDD आइडेंटिफ़ायर [C-4-X] के साथ सेक्शन 9.1 में बताई गई भूमिकाओं वाले ऐप्लिकेशन ऐक्सेस करते हैं, तब ऐसा नहीं करना चाहिए. .
[9.8.2/H-4-2] माइक्रोफ़ोन का इस्तेमाल करके, हाल ही में इस्तेमाल किए गए और चालू ऐप्लिकेशन की सूची दिखानी ज़रूरी है. यह सूची, PermissionManager.getIndicatorAppOpUsageData() से मिली जानकारी के हिसाब से होनी चाहिए. साथ ही, उन ऐप्लिकेशन से जुड़े एट्रिब्यूशन मैसेज भी दिखाए जाने चाहिए.
[9.8.2/H-4-3] सिस्टम के ऐसे ऐप्लिकेशन के लिए माइक्रोफ़ोन इंडिकेटर को नहीं छिपाना चाहिए जिनमें यूज़र इंटरफ़ेस दिखते हैं या उपयोगकर्ता सीधे तौर पर इंटरैक्ट करते हैं.
[9.8.2/H-4-4] माइक्रोफ़ोन का इस्तेमाल करके, PermissionManager.getIndicatorAppOpUsageData() से मिली हाल ही में इस्तेमाल किए गए और चालू ऐप्लिकेशन की सूची दिखानी ज़रूरी है. साथ ही, उनसे जुड़े एट्रिब्यूशन मैसेज भी दिखाने चाहिए.

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

[9.8.2/H-5-1] जब कोई ऐप्लिकेशन कैमरे का लाइव डेटा ऐक्सेस कर रहा हो, तो कैमरा इंडिकेटर दिखाना ज़रूरी है. हालांकि, जब कैमरे को सिर्फ़ उन ऐप्लिकेशन के ज़रिए ऐक्सेस किया जा रहा हो जिनके पास सेक्शन 9.1 में बताई गई भूमिकाएं हैं और जिनमें सीडीडी आइडेंटिफ़ायर [C-4-X] है, तो कैमरा इंडिकेटर नहीं दिखाना चाहिए.
[9.8.2/H-5-2] PermissionManager.getIndicatorAppOpUsageData() से मिले कैमरे के इस्तेमाल से, हाल ही में इस्तेमाल किए गए और ऐक्टिव ऐप्लिकेशन के साथ-साथ उनसे जुड़े एट्रिब्यूशन मैसेज भी दिखाए जाने चाहिए.
[9.8.2/H-5-3] सिस्टम के उन ऐप्लिकेशन के लिए कैमरे के इंडिकेटर को नहीं छिपाना चाहिए जिनमें यूज़र इंटरफ़ेस दिखते हैं या जिनमें उपयोगकर्ता सीधे तौर पर इंटरैक्ट करता है.

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

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

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

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

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

2.2.7. मोबाइल डिवाइस पर वीडियो की परफ़ॉर्मेंस की क्लास

मीडिया परफ़ॉर्मेंस क्लास की परिभाषा के लिए, सेक्शन 7.11 देखें.

2.2.7.1. मीडिया

अगर हाथ में पकड़े जाने वाले डिवाइस के लागू होने पर, android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS के लिए android.os.Build.VERSION_CODES.R दिखता है, तो:

Android 11 CDD के सेक्शन 2.2.7.1 में बताई गई मीडिया से जुड़ी ज़रूरी शर्तों को पूरा करना ज़रूरी है

अगर android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS के लिए, हैंडहेल्ड डिवाइस के लागू होने की जानकारी android.os.Build.VERSION_CODES.S के तौर पर दिखती है, तो:

[5.1/H-1-1] CodecCapabilities.getMaxSupportedInstances() और VideoCapabilities.getSupportedPerformancePoints() तरीकों की मदद से, किसी भी कोडेक कॉम्बिनेशन में एक साथ चलाए जा सकने वाले, हार्डवेयर वीडियो डिकोडर सेशन की ज़्यादा से ज़्यादा संख्या का विज्ञापन करना ज़रूरी है.
[5.1/H-1-2] यह ज़रूरी है कि डिवाइस में, किसी भी कोडेक कॉम्बिनेशन में 720 पिक्सल रिज़ॉल्यूशन@30 fps पर एक साथ चलने वाले हार्डवेयर वीडियो डिकोडर सेशन (AVC, HEVC, VP9* या इसके बाद के वर्शन) के छह इंस्टेंस काम करते हों. *VP9 कोडेक मौजूद होने पर, सिर्फ़ दो इंस्टेंस की ज़रूरत होती है.
[5.1/H-1-3] CodecCapabilities.getMaxSupportedInstances() और VideoCapabilities.getSupportedPerformancePoints() तरीकों की मदद से, किसी भी कोडेक कॉम्बिनेशन में एक साथ चलाए जा सकने वाले, ज़्यादा से ज़्यादा हार्डवेयर वीडियो एन्कोडर सेशन का विज्ञापन करना ज़रूरी है.
[5.1/H-1-4] यह ज़रूरी है कि डिवाइस में, 720 पिक्सल रिज़ॉल्यूशन@30fps पर एक साथ चलने वाले किसी भी कोडेक कॉम्बिनेशन में, हार्डवेयर वीडियो एन्कोडर सेशन (AVC, HEVC, VP9* या उसके बाद के वर्शन) के छह इंस्टेंस काम करते हों. *अगर VP9 कोडेक मौजूद है, तो सिर्फ़ दो इंस्टेंस ज़रूरी हैं.
[5.1/H-1-5] CodecCapabilities.getMaxSupportedInstances() और VideoCapabilities.getSupportedPerformancePoints() तरीकों की मदद से, किसी भी कोडेक कॉम्बिनेशन में एक साथ चलाए जा सकने वाले, ज़्यादा से ज़्यादा हार्डवेयर वीडियो एन्कोडर और डिकोडर सेशन का विज्ञापन करना ज़रूरी है.
[5.1/H-1-6] यह ज़रूरी है कि डिवाइस में, हार्डवेयर वीडियो डिकोडर और हार्डवेयर वीडियो एन्कोडर सेशन (AVC, HEVC, VP9* या उसके बाद के वर्शन) के छह इंस्टेंस काम करते हों. साथ ही, ये इंस्टेंस किसी भी कोडेक कॉम्बिनेशन में, 720p@30fps रिज़ॉल्यूशन पर एक साथ काम करते हों. *VP9 कोडेक मौजूद होने पर, सिर्फ़ दो इंस्टेंस ज़रूरी हैं.
[5.1/H-1-7] लोड होने पर, सभी हार्डवेयर वीडियो एन्कोडर (Dolby vision कोडेक के अलावा) के लिए, 1080 पिक्सल या उससे कम रिज़ॉल्यूशन वाले वीडियो कोडिंग सेशन के लिए, कोडेक शुरू करने में लगने वाला समय 50 मिलीसेकंड या उससे कम होना चाहिए. यहां लोड का मतलब, 1080 पिक्सल से 720 पिक्सल वाले वीडियो को एक साथ ट्रांसकोड करने वाले सेशन से है. इसमें हार्डवेयर वीडियो कोडेक का इस्तेमाल किया जाता है. साथ ही, 1080 पिक्सल वाली ऑडियो-वीडियो रिकॉर्डिंग को शुरू किया जाता है.
[5.1/H-1-8] लोड के दौरान, सभी ऑडियो एन्कोडर के लिए 128 केबीपीएस या उससे कम बिटरेट वाले ऑडियो कोडिंग सेशन के लिए, कोडेक को शुरू करने में लगने वाला समय 40 एमएस या उससे कम होना चाहिए. यहां लोड को, 1080 पिक्सल से 720 पिक्सल वाले वीडियो को एक साथ ट्रांसकोड करने वाले सेशन के तौर पर परिभाषित किया गया है. इस सेशन में, हार्डवेयर वीडियो कोडेक का इस्तेमाल किया जाता है. साथ ही, 1080 पिक्सल वाली ऑडियो-वीडियो रिकॉर्डिंग को शुरू किया जाता है.
[5.3/H-1-1] लोड के दौरान, 1080 पिक्सल और 60 एफ़पीएस वाले वीडियो सेशन के लिए, 10 सेकंड में दो फ़्रेम से ज़्यादा नहीं छोड़े जाने चाहिए.इसका मतलब है कि फ़्रेम ड्रॉप 0.333 प्रतिशत से कम होना चाहिए. लोड का मतलब है, हार्डवेयर वीडियो कोडेक का इस्तेमाल करके, 1080 पिक्सल से 720 पिक्सल में वीडियो को एक साथ ट्रांसकोड करने के साथ-साथ 128 केबीपीएस AAC ऑडियो चलाने का सेशन.
[5.3/H-1-2] 60 fps वीडियो सेशन के दौरान, वीडियो रिज़ॉल्यूशन में बदलाव होने पर, 10 सेकंड में दो से ज़्यादा फ़्रेम नहीं छोड़े जाने चाहिए. लोड का मतलब है, हार्डवेयर वीडियो कोडेक का इस्तेमाल करके, 1080 पिक्सल से 720 पिक्सल में वीडियो को एक साथ ट्रांसकोड करने के साथ-साथ 128 केबीपीएस AAC ऑडियो चलाने का सेशन.
[5.6/H-1-1] OboeTester टैप-टू-टोन टेस्ट या CTS Verifier टैप-टू-टोन टेस्ट का इस्तेमाल करके, टैप-टू-टोन में लगने वाला समय 100 मिलीसेकंड से कम होना चाहिए.

2.2.7.2. कैमरा

Android 11 CDD के सेक्शन 2.2.7.2 में बताई गई कैमरे से जुड़ी ज़रूरी शर्तें पूरी करना ज़रूरी है

[7.5/H-1-1] डिवाइस में पीछे की ओर वाला मुख्य कैमरा होना चाहिए. इसका रिज़ॉल्यूशन कम से कम 12 मेगापिक्सल होना चाहिए. साथ ही, यह 4K@30fps पर वीडियो कैप्चर करने की सुविधा देना चाहिए. मुख्य पीछे वाला कैमरा, सबसे कम कैमरा आईडी वाला पीछे वाला कैमरा होता है.
[7.5/H-1-2] डिवाइस में कम से कम 5 मेगापिक्सल का मुख्य फ़्रंट कैमरा होना चाहिए. साथ ही, यह 1080p@30fps पर वीडियो कैप्चर करने की सुविधा भी देना चाहिए. मुख्य सामने वाला कैमरा, सबसे कम कैमरा आईडी वाला सामने वाला कैमरा होता है.
[7.5/H-1-3] android.info.supportedHardwareLevel प्रॉपर्टी के साथ काम करना चाहिए. यह प्रॉपर्टी, पीछे के प्राइमरी कैमरे के लिए FULL या इससे बेहतर और सामने के प्राइमरी कैमरे के लिए LIMITED या इससे बेहतर होनी चाहिए.
[7.5/H-1-4] दोनों प्राइमरी कैमरों के लिए, CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME के साथ काम करना ज़रूरी है.
[7.5/H-1-5] 1080p रिज़ॉल्यूशन के लिए, camera2 JPEG कैप्चर में लगने वाला समय 1000 मिलीसेकंड से कम होना चाहिए. यह समय, दोनों प्राइमरी कैमरों के लिए, CTS कैमरा की परफ़ॉर्मेंस की जांच के दौरान, रोशनी की आईटीएस स्थितियों (3000K) के तहत मेज़र किया जाता है.
[7.5/H-1-6] कैमरा चालू होने में लगने वाला समय (कैमरा चालू करने से लेकर, पहले झलक फ़्रेम तक) 600 मिलीसेकंड से कम होना चाहिए. यह समय, दोनों प्राइमरी कैमरों के लिए, CTS कैमरा परफ़ॉर्मेंस टेस्ट के तहत, लाइटिंग की ITS स्थितियों (3000K) में मेज़र किया जाता है.
[7.5/H-1-8] प्राइमरी रियर कैमरे के लिए, CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW और android.graphics.ImageFormat.RAW_SENSOR का इस्तेमाल किया जा सकता है.

2.2.7.3. हार्डवेयर

अगर android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS के लिए, हैंडहेल्ड डिवाइस के लागू होने की जानकारी android.os.Build.VERSION_CODES.R के तौर पर दिखती है, तो:

Android 11 CDD के सेक्शन 2.2.7.3 में बताई गई, हार्डवेयर से जुड़ी ज़रूरी शर्तें पूरी करना ज़रूरी है

अगर हाथ में पकड़े जाने वाले डिवाइस के लागू होने पर, android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS के लिए android.os.Build.VERSION_CODES.S दिखता है, तो:

[7.1.1.1/H-2-1] स्क्रीन का रिज़ॉल्यूशन कम से कम 1080p होना चाहिए.
[7.1.1.3/H-2-1] स्क्रीन का डीपीआई कम से कम 400 डीपीआई होना चाहिए.
[7.6.1/H-2-1] डिवाइस में कम से कम 6 जीबी फ़िज़िकल मेमोरी होनी चाहिए.

2.2.7.4. परफ़ॉर्मेंस

Android 11 CDD के सेक्शन 2.2.7.4 में बताई गई परफ़ॉर्मेंस से जुड़ी ज़रूरी शर्तों को पूरा करना ज़रूरी है

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

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

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

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

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

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

2.3.1. हार्डवेयर

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

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

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

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

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

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

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

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

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

[7.6.1/T-1-1] अगर इनमें से किसी भी डेंसिटी का इस्तेमाल किया जाता है, तो kernel और userspace के लिए उपलब्ध मेमोरी कम से कम 896 एमबी होनी चाहिए:
- छोटी/सामान्य स्क्रीन पर 400 डीपीआई या उससे ज़्यादा
- बड़ी स्क्रीन पर xhdpi या उससे ज़्यादा
- बहुत बड़ी स्क्रीन पर tvdpi या उससे ज़्यादा

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

[7.6.1/T-2-1] अगर इनमें से किसी भी डेंसिटी का इस्तेमाल किया जाता है, तो kernel और userspace के लिए उपलब्ध मेमोरी कम से कम 1280 एमबी होनी चाहिए:
- छोटी/सामान्य स्क्रीन पर 400 डीपीआई या उससे ज़्यादा
- बड़ी स्क्रीन पर xhdpi या उससे ज़्यादा
- बहुत बड़ी स्क्रीन पर tvdpi या उससे ज़्यादा

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.3.3. सॉफ़्टवेयर

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

[3/T-0-1] android.software.leanback और android.hardware.type.television सुविधाओं के बारे में ज़रूर बताएं.
[3.2.3.1/T-0-1] यहां दिए गए ऐप्लिकेशन इंटेंट के मुताबिक तय किए गए सभी सार्वजनिक इंटेंट फ़िल्टर पैटर्न के लिए, इंटेंट हैंडलर के साथ एक या एक से ज़्यादा ऐप्लिकेशन या सेवा कॉम्पोनेंट को पहले से लोड करना ज़रूरी है.
[3.4.1/T-0-1] android.webkit.Webview एपीआई को पूरी तरह से लागू करना ज़रूरी है.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[9.8.2/T-4-1] जब कोई ऐप्लिकेशन माइक्रोफ़ोन से ऑडियो डेटा ऐक्सेस कर रहा हो, तब माइक्रोफ़ोन इंडिकेटर दिखाना ज़रूरी है.हालांकि, जब माइक्रोफ़ोन को सिर्फ़ HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService या सीडीडी आइडेंटिफ़ायर C-3-X वाली अनुमतियों वाले ऐप्लिकेशन ऐक्सेस करते हैं, तब माइक्रोफ़ोन इंडिकेटर नहीं दिखाना चाहिए.
[9.8.2/T-4-2] सिस्टम के उन ऐप्लिकेशन के लिए माइक्रोफ़ोन इंडिकेटर को नहीं छिपाना चाहिए जिनमें यूज़र इंटरफ़ेस दिखते हैं या उपयोगकर्ता सीधे तौर पर इंटरैक्ट करते हैं.

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

[9.8.2/T-5-1] जब कोई ऐप्लिकेशन कैमरे का लाइव डेटा ऐक्सेस कर रहा हो, तो कैमरा इंडिकेटर दिखाना ज़रूरी है.हालांकि, जब कैमरे को सिर्फ़ ऐसे ऐप्लिकेशन ऐक्सेस कर रहे हों जिनके पास सीडीडी आइडेंटिफ़ायर [C-3-X] वाली अनुमतियां हैं, तो कैमरा इंडिकेटर नहीं दिखाना चाहिए.
[9.8.2/T-5-2] सिस्टम के उन ऐप्लिकेशन के लिए कैमरे के इंडिकेटर को नहीं छिपाना चाहिए जिनमें उपयोगकर्ता इंटरफ़ेस दिखते हैं या उपयोगकर्ता सीधे तौर पर इंटरैक्ट करते हैं.

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

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

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

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

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

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

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

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

2.4.1. हार्डवेयर

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

[7.1.1.1/W-0-1] डिवाइस की स्क्रीन का डायगनल साइज़ 1.1 से 2.5 इंच के बीच होना चाहिए.
[7.2.3/W-0-1] उपयोगकर्ता के लिए होम फ़ंक्शन और UI_MODE_TYPE_WATCH में होने पर, बैक फ़ंक्शन उपलब्ध होना चाहिए.
[7.2.4/W-0-1] टचस्क्रीन इनपुट की सुविधा होनी चाहिए.
[7.3.1/W-SR-1] हमारा सुझाव है कि आप तीन ऐक्सिस वाला ऐक्सेलेरोमीटर शामिल करें.

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

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

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

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

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

[7.4.3/W-0-1] डिवाइस में ब्लूटूथ की सुविधा होनी चाहिए.
[7.6.1/W-0-1] ऐप्लिकेशन के निजी डेटा (जिसे "/data" पार्टीशन भी कहा जाता है) के लिए, कम से कम 1 जीबी का नॉन-वॉल्व्यूस्ट स्टोरेज होना चाहिए.
[7.6.1/W-0-2] कम से कम 416 एमबी मेमोरी, कर्नेल और यूज़रस्पेस के लिए उपलब्ध होनी चाहिए.
[7.8.1/W-0-1] इसमें माइक्रोफ़ोन होना ज़रूरी है.
[7.8.2/W] में ऑडियो आउटपुट हो सकता है.

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

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

2.4.3. सॉफ़्टवेयर

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

[3/W-0-1] इस सुविधा के बारे में ज़रूर बताएं android.hardware.type.watch.
[3/W-0-2] uiMode = UI_MODE_TYPE_WATCH के साथ काम करना चाहिए.
[3.2.3.1/W-0-1] यहां दिए गए ऐप्लिकेशन इंटेंट के हिसाब से तय किए गए सभी सार्वजनिक इंटेंट फ़िल्टर पैटर्न के लिए, इंटेंट हैंडलर के साथ एक या उससे ज़्यादा ऐप्लिकेशन या सेवा कॉम्पोनेंट को पहले से लोड करना ज़रूरी है.

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

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

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

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

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

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

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

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

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

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

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

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

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

[9/W-0-1] android.hardware.security.model.compatible सुविधा के बारे में एलान करना ज़रूरी है.

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

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

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

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

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

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

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

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

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

2.5.1. हार्डवेयर

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

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

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

[7.1.4.1/A-0-1] OpenGL ES 3.1 या इसके बाद के वर्शन का एलान करना ज़रूरी है.
[7.1.4.1/A-0-2] यह Vulkan 1.1 के साथ काम करना चाहिए.
[7.1.4.1/A-0-3] इसमें Vulkan लोडर को शामिल करना ज़रूरी है और सभी सिंबल एक्सपोर्ट करने होंगे.

अगर वाहन में इस्तेमाल होने वाले डिवाइस में 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-3] यह ज़रूरी है कि डिवाइस, हर सेकंड में 250 डिग्री तक के ओरिएंटेशन में होने वाले बदलावों को मेज़र कर सके.
[7.3.4/A-SR-1] हमारा सुझाव है कि जियोस्कोप की मेज़रमेंट रेंज को +/-250dps पर कॉन्फ़िगर करें, ताकि रिज़ॉल्यूशन को ज़्यादा से ज़्यादा बढ़ाया जा सके

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

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

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

[7.4.3/A-0-1] डिवाइस में ब्लूटूथ की सुविधा होनी चाहिए. साथ ही, डिवाइस में ब्लूटूथ LE की सुविधा होनी चाहिए.
[7.4.3/A-0-2] Android Automotive के लागू होने के लिए, इन ब्लूटूथ प्रोफ़ाइलों के साथ काम करना ज़रूरी है:
- Hands-Free Profile (एचएफ़पी) की मदद से फ़ोन कॉल करना.
- ऑडियो डिस्ट्रिब्यूशन प्रोफ़ाइल (A2DP) की मदद से मीडिया चलाना.
- रिमोट कंट्रोल प्रोफ़ाइल (एवीआरसीपी) की मदद से, मीडिया प्लेबैक को कंट्रोल करना.
- फ़ोन बुक ऐक्सेस करने वाली प्रोफ़ाइल (पीबीएपी) का इस्तेमाल करके संपर्क शेयर करना.
[7.4.3/A-SR-1] मैसेज ऐक्सेस प्रोफ़ाइल (एमएपी) के साथ काम करने का सुझाव दिया जाता है.
[7.4.5/A] इसमें मोबाइल नेटवर्क पर आधारित डेटा कनेक्टिविटी की सुविधा शामिल होनी चाहिए.
[7.4.5/A] सिस्टम एपीआई के NetworkCapabilities#NET_CAPABILITY_OEM_PAID कॉन्स्टेंट का इस्तेमाल उन नेटवर्क के लिए किया जा सकता है जो सिस्टम ऐप्लिकेशन के लिए उपलब्ध होने चाहिए.

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

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

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

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

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

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

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

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

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

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

[7.6.1/A-1-1] अगर इनमें से किसी भी डेंसिटी का इस्तेमाल किया जाता है, तो कर्नेल और यूज़रस्पेस के लिए उपलब्ध मेमोरी कम से कम 512 एमबी होनी चाहिए:
- छोटी/सामान्य स्क्रीन पर 280 डीपीआई या उससे कम
- बहुत बड़ी स्क्रीन पर ldpi या उससे कम
- बड़ी स्क्रीन पर mdpi या उससे कम
[7.6.1/A-1-2] अगर इनमें से किसी भी डेंसिटी का इस्तेमाल किया जाता है, तो kernel और userspace के लिए उपलब्ध मेमोरी कम से कम 608 एमबी होनी चाहिए:
- छोटी/सामान्य स्क्रीन पर xhdpi या उससे ज़्यादा
- बड़ी स्क्रीन पर hdpi या उससे ज़्यादा
- ज़्यादा बड़ी स्क्रीन पर mdpi या उससे ज़्यादा
[7.6.1/A-1-3] अगर इनमें से किसी भी डेंसिटी का इस्तेमाल किया जाता है, तो kernel और userspace के लिए उपलब्ध मेमोरी कम से कम 896 एमबी होनी चाहिए:
- छोटी/सामान्य स्क्रीन पर 400 डीपीआई या उससे ज़्यादा
- बड़ी स्क्रीन पर xhdpi या उससे ज़्यादा
- बहुत बड़ी स्क्रीन पर tvdpi या उससे ज़्यादा
[7.6.1/A-1-4] अगर इनमें से किसी भी डेंसिटी का इस्तेमाल किया जाता है, तो kernel और userspace के लिए उपलब्ध मेमोरी कम से कम 1344 एमबी होनी चाहिए:
- छोटी/सामान्य स्क्रीन पर 560 डीपीआई या उससे ज़्यादा
- बड़ी स्क्रीन पर 400 डीपीआई या उससे ज़्यादा
- बहुत बड़ी स्क्रीन पर xhdpi या उससे ज़्यादा

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

[7.6.1/A-2-1] अगर इनमें से किसी भी डेंसिटी का इस्तेमाल किया जाता है, तो कर्नेल और यूज़रस्पेस के लिए कम से कम 816 एमबी मेमोरी उपलब्ध होनी चाहिए:
- छोटी/सामान्य स्क्रीन पर 280 डीपीआई या उससे कम
- बहुत बड़ी स्क्रीन पर ldpi या उससे कम
- बड़ी स्क्रीन पर mdpi या उससे कम
[7.6.1/A-2-2] अगर इनमें से किसी भी डेंसिटी का इस्तेमाल किया जाता है, तो kernel और userspace के लिए उपलब्ध मेमोरी कम से कम 944 एमबी होनी चाहिए:
- छोटी/सामान्य स्क्रीन पर xhdpi या उससे ज़्यादा
- बड़ी स्क्रीन पर hdpi या उससे ज़्यादा
- ज़्यादा बड़ी स्क्रीन पर mdpi या उससे ज़्यादा
[7.6.1/A-2-3] अगर इनमें से किसी भी डेंसिटी का इस्तेमाल किया जाता है, तो कर्नेल और यूज़रस्पेस के लिए उपलब्ध मेमोरी कम से कम 1280 एमबी होनी चाहिए:
- छोटी/सामान्य स्क्रीन पर 400 डीपीआई या उससे ज़्यादा
- बड़ी स्क्रीन पर xhdpi या उससे ज़्यादा
- बहुत बड़ी स्क्रीन पर tvdpi या उससे ज़्यादा
[7.6.1/A-2-4] अगर इनमें से किसी भी डेंसिटी का इस्तेमाल किया जाता है, तो kernel और userspace के लिए उपलब्ध मेमोरी कम से कम 1824 एमबी होनी चाहिए:
- छोटी/सामान्य स्क्रीन पर 560 डीपीआई या उससे ज़्यादा
- बड़ी स्क्रीन पर 400 डीपीआई या उससे ज़्यादा
- बहुत बड़ी स्क्रीन पर xhdpi या उससे ज़्यादा

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.5.3. सॉफ़्टवेयर

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

[3/A-0-1] इस सुविधा के बारे में ज़रूर बताएं android.hardware.type.automotive.
[3/A-0-2] uiMode = UI_MODE_TYPE_CAR के साथ काम करना चाहिए.
[3/A-0-3] android.car.* नेमस्पेस में मौजूद सभी सार्वजनिक एपीआई के साथ काम करना चाहिए.

अगर वाहन के लिए बने डिवाइस में, android.car.VehiclePropertyIds के साथ android.car.CarPropertyManager का इस्तेमाल करके मालिकाना एपीआई उपलब्ध कराया जाता है, तो:

[3/A-1-1] सिस्टम ऐप्लिकेशन को इन प्रॉपर्टी के इस्तेमाल के लिए खास सुविधाएं नहीं देनी चाहिए. इसके अलावा, तीसरे पक्ष के ऐप्लिकेशन को इन प्रॉपर्टी का इस्तेमाल करने से नहीं रोकना चाहिए.
[3/A-1-2] SDK में पहले से मौजूद वाहन की ऐसी प्रॉपर्टी का डुप्लीकेट नहीं बनाया जाना चाहिए.

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

[3.2.1/A-0-1] वाहन संबंधित अनुमति के रेफ़रंस पेज में बताए गए सभी अनुमतियों के लिए, अनुमतियों के सभी कॉन्स्टेंट काम करने चाहिए और उन्हें लागू करना चाहिए.
[3.2.3.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-1] हमारा सुझाव है कि Assist ऐक्शन को मैनेज करने के लिए, डिवाइस पर कोई सहायक लागू करें.

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

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

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

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

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

[3.9.3/A-1-1] सभी उपयोगकर्ता लाइफ़साइकल प्रॉपर्टी को लागू करना ज़रूरी है
- INITIAL_USER_INFO, SWITCH_USER, CREATE_USER, REMOVE_USER.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.6.1. हार्डवेयर

जाइरोस्कोप

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.6.2. सॉफ़्टवेयर

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

3. सॉफ़्टवेयर

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

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

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

[C-0-1] Android SDK के ज़रिए एक्सपोज़ किए गए किसी भी दस्तावेज़ वाले एपीआई या अपस्ट्रीम Android सोर्स कोड में “@SystemApi” मार्कर के साथ सजाए गए किसी भी एपीआई के सभी दस्तावेज़ किए गए व्यवहारों के साथ-साथ, एपीआई को पूरी तरह से लागू करना ज़रूरी है.
[C-0-2] TestApi एनोटेशन (@TestApi) से मार्क की गई सभी क्लास, मेथड, और उनसे जुड़े एलिमेंट के साथ काम करना चाहिए/उनका रखरखाव करना चाहिए.
[C-0-3] मैनेज किए जा रहे किसी भी एपीआई को नहीं छोड़ना चाहिए, एपीआई इंटरफ़ेस या हस्ताक्षर में बदलाव नहीं करना चाहिए, दस्तावेज़ में बताए गए तरीके से काम नहीं करना चाहिए या कोई काम न करने वाला एपीआई शामिल नहीं करना चाहिए. हालांकि, अगर इस सुविधा के साथ काम करने की शर्तों में ऐसा करने की अनुमति दी गई है, तो ऐसा किया जा सकता है.
[C-0-4] एपीआई को अब भी मौजूद रखना चाहिए और सही तरीके से काम करना चाहिए. भले ही, Android में एपीआई शामिल करने वाली कुछ हार्डवेयर सुविधाओं को हटा दिया गया हो. इस स्थिति के लिए ज़रूरी शर्तों के बारे में जानने के लिए, सेक्शन 7 देखें.
[C-0-5] तीसरे पक्ष के ऐप्लिकेशन को ऐसे इंटरफ़ेस इस्तेमाल करने की अनुमति नहीं देनी चाहिए जिनमें SDK टूल नहीं है. ये इंटरफ़ेस, Java भाषा के पैकेज में मौजूद तरीकों और फ़ील्ड के तौर पर तय किए जाते हैं. ये पैकेज, AOSP के बूट क्लासपाथ में होते हैं और सार्वजनिक SDK टूल का हिस्सा नहीं होते. इसमें ऐसे एपीआई शामिल हैं जिन्हें @hide एनोटेशन से सजाया गया है, लेकिन @SystemAPI से नहीं, जैसा कि एसडीके दस्तावेज़ों में बताया गया है. साथ ही, इसमें निजी और पैकेज-निजी क्लास के सदस्य भी शामिल हैं.
[C-0-6] यह ज़रूरी है कि हर ऐसे इंटरफ़ेस को, पाबंदी वाली उन ही सूचियों में शामिल किया जाए जिनमें AOSP में सही एपीआई लेवल की शाखा के लिए, prebuilts/runtime/appcompat/hiddenapi-flags.csv पाथ में मौजूद, पाबंदी वाले और पाबंदी वाली सूची में शामिल करने वाले फ़्लैग के ज़रिए बताया गया है.
[C-0-7] साइन किए गए कॉन्फ़िगरेशन के डाइनैमिक अपडेट मैकेनिज्म के साथ काम करना चाहिए, ताकि SDK टूल के बाहर के इंटरफ़ेस को पाबंदी वाली सूची से हटाया जा सके. इसके लिए, AOSP में मौजूद मौजूदा सार्वजनिक कुंजियों का इस्तेमाल करके, किसी भी APK में साइन किए गए कॉन्फ़िगरेशन को जोड़ना होगा.

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

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

Android, किसी खास एपीआई लेवल के मैनेज किए जा रहे एपीआई के प्लैटफ़ॉर्म को बड़ा करने की सुविधा देता है. इसके लिए, उस एपीआई लेवल के लिए एक्सटेंशन वर्शन को अपडेट किया जाता है. अगर उस एपीआई लेवल के लिए एक्सटेंशन मौजूद हैं, तो android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) एपीआई, दिए गए apiLevel का एक्सटेंशन वर्शन दिखाता है.

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

[C-0-1] ऐप्लिकेशन को, शेयर की गई लाइब्रेरी ExtShared और सेवाओं ExtServices, दोनों के AOSP वर्शन को पहले से लोड करना चाहिए. ये वर्शन, हर एपीआई लेवल के लिए तय किए गए कम से कम वर्शन से ज़्यादा या उसके बराबर होने चाहिए. उदाहरण के लिए, Android 7.0 पर काम करने वाले डिवाइसों में, एपीआई लेवल 24 के कम से कम वर्शन 1 का इस्तेमाल करना ज़रूरी है.
[C-0-2] यह फ़ंक्शन सिर्फ़ उस एक्सटेंशन वर्शन का नंबर दिखाए जो AOSP ने तय किया है.
[C-0-3] यह ज़रूरी है कि एक्सटेंशन के उन सभी वर्शन के लिए एपीआई काम करें जो android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) के ज़रिए दिखाए जाते हैं. साथ ही, यह भी ज़रूरी है कि एपीआई ठीक उसी तरह काम करें जिस तरह मैनेज किए जा रहे अन्य एपीआई काम करते हैं. इसके लिए, सेक्शन 3.1 में दी गई ज़रूरी शर्तों का पालन करना होगा.

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

Apache HTTP क्लाइंट के बंद होने की वजह से, डिवाइस पर लागू होने वाले ये बदलाव होंगे:

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

AOSP को लागू करने से ये ज़रूरी शर्तें पूरी होती हैं.

3.2. Soft API Compatibility

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

3.2.1. अनुमतियां

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

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

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

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

पैरामीटर	जानकारी
VERSION.RELEASE	फ़िलहाल चल रहे Android सिस्टम का वर्शन, ऐसे फ़ॉर्मैट में जिसे कोई भी व्यक्ति आसानी से पढ़ सकता है. इस फ़ील्ड में, Android 12 के लिए अनुमति वाली वर्शन स्ट्रिंग में बताई गई स्ट्रिंग वैल्यू में से कोई एक वैल्यू होनी चाहिए.
VERSION.SDK	फ़िलहाल चल रहे Android सिस्टम का वर्शन, तीसरे पक्ष के ऐप्लिकेशन कोड के ऐक्सेस किए जा सकने वाले फ़ॉर्मैट में. Android 12 के लिए, इस फ़ील्ड में पूर्णांक की वैल्यू 12_INT होनी चाहिए.
VERSION.SDK_INT	फ़िलहाल चल रहे Android सिस्टम का वर्शन, तीसरे पक्ष के ऐप्लिकेशन कोड के ऐक्सेस किए जा सकने वाले फ़ॉर्मैट में. Android 12 के लिए, इस फ़ील्ड में पूर्णांक की वैल्यू 12_INT होनी चाहिए.
VERSION.INCREMENTAL	डिवाइस इंप्लीमेंटर की चुनी गई वैल्यू, जो फ़िलहाल चल रहे Android सिस्टम के खास बिल्ड को, इंसान के पढ़ने लायक फ़ॉर्मैट में दिखाती है. इस वैल्यू का इस्तेमाल, असली उपयोगकर्ताओं के लिए उपलब्ध कराए गए अलग-अलग बिल्ड के लिए दोबारा नहीं किया जाना चाहिए. इस फ़ील्ड का आम तौर पर इस्तेमाल, यह बताने के लिए किया जाता है कि बिल्ड जनरेट करने के लिए, किस बिल्ड नंबर या सोर्स-कंट्रोल बदलाव आइडेंटिफ़ायर का इस्तेमाल किया गया था. इस फ़ील्ड की वैल्यू, प्रिंट किए जा सकने वाले सात बिट वाले 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 देखें. नेटिव एपीआई के साथ काम करना.
CPU_ABI	नेटिव कोड के निर्देश सेट (सीपीयू टाइप + एबीआई कॉन्वेंशन) का नाम. सेक्शन 3.3 देखें. नेटिव एपीआई के साथ काम करना.
CPU_ABI2	नेटिव कोड के दूसरे निर्देश सेट (सीपीयू टाइप + एबीआई कन्वेंशन) का नाम. सेक्शन 3.3 देखें. नेटिव एपीआई के साथ काम करना.
डिवाइस	डिवाइस लागू करने वाले व्यक्ति या कंपनी की चुनी गई वैल्यू. इसमें डिवाइस के हार्डवेयर की सुविधाओं और डिवाइस के इंडस्ट्रियल डिज़ाइन के कॉन्फ़िगरेशन की पहचान करने वाला डेवलपमेंट का नाम या कोड नेम होता है. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है. साथ ही, यह वैल्यू रेगुलर एक्सप्रेशन “^[a-zA-Z0-9_-]+$” से मेल खानी चाहिए. प्रॉडक्ट के लाइफ़टाइम के दौरान, डिवाइस का यह नाम नहीं बदलना चाहिए.
फ़िंगरप्रिंट	यह एक स्ट्रिंग है, जो इस बिल्ड की खास तौर पर पहचान करती है. यह किसी व्यक्ति के लिए आसानी से पढ़ा जा सकने वाला होना चाहिए. यह इस टेंप्लेट के मुताबिक होना चाहिए: $(BRAND)/$(PRODUCT)/ $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) उदाहरण के लिए: acme/myproduct/ mydevice:12/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) का ट्रेड नेम. इस फ़ील्ड के फ़ॉर्मैट के लिए कोई ज़रूरी शर्त नहीं है. हालांकि, यह शर्त ज़रूरी है कि यह शून्य या खाली स्ट्रिंग ("") न हो. साथ ही, प्रॉडक्ट के लाइफ़टाइम के दौरान इस फ़ील्ड में बदलाव नहीं किया जाना चाहिए.
SOC_MANUFACTURER	प्रॉडक्ट में इस्तेमाल किए गए प्राइमरी सिस्टम ऑन चिप (एसओसी) के मैन्युफ़ैक्चरर का ट्रेड नेम. एक ही SoC मैन्युफ़ैक्चरर वाले डिवाइसों के लिए, एक ही कॉन्स्टेंट वैल्यू का इस्तेमाल किया जाना चाहिए. कृपया एसओसी मैन्युफ़ैक्चरर से पूछें कि इस्तेमाल करने के लिए कौनसा सही कॉन्स्टेंट है. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है. यह वैल्यू, रेगुलर एक्सप्रेशन “^([0-9A-Za-z ]+)” से मैच करनी चाहिए. साथ ही, यह वैल्यू व्हाइटस्पेस से शुरू या खत्म नहीं होनी चाहिए. यह वैल्यू “unknown” के बराबर नहीं होनी चाहिए. प्रॉडक्ट के लाइफ़टाइम के दौरान, इस फ़ील्ड में बदलाव नहीं किया जाना चाहिए.
SOC_MODEL	प्रॉडक्ट में इस्तेमाल किए गए चिप पर सिस्टम (SoC) के मुख्य मॉडल का नाम. एक ही एसओसी मॉडल वाले डिवाइसों को एक ही कॉन्स्टेंट वैल्यू का इस्तेमाल करना चाहिए. कृपया एसओसी मैन्युफ़ैक्चरर से पूछें कि इस्तेमाल करने के लिए सही कॉन्स्टेंट क्या है. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है. साथ ही, यह रेगुलर एक्सप्रेशन “^([0-9A-Za-z ._/+-]+)$” से मैच करनी चाहिए. यह वैल्यू, स्पेशल वाइट स्पेस से शुरू या खत्म नहीं होनी चाहिए. साथ ही, यह “unknown” के बराबर नहीं होनी चाहिए. प्रॉडक्ट के लाइफ़टाइम के दौरान, इस फ़ील्ड की वैल्यू में बदलाव नहीं किया जाना चाहिए.
MODEL	डिवाइस लागू करने वाले व्यक्ति की चुनी गई वैल्यू, जिसमें डिवाइस का नाम होता है, जैसा कि आखिरी उपयोगकर्ता को पता होता है. यह वही नाम होना चाहिए जिससे डिवाइस को मार्केट में लाया जाता है और असल उपयोगकर्ताओं को बेचा जाता है. इस फ़ील्ड के लिए, किसी खास फ़ॉर्मैट की ज़रूरत नहीं है. हालांकि, यह शर्त ज़रूरी है कि यह शून्य या खाली स्ट्रिंग ("") न हो. साथ ही, प्रॉडक्ट के लाइफ़टाइम के दौरान इस फ़ील्ड में कोई बदलाव नहीं होना चाहिए.
प्रॉडक्ट	डिवाइस लागू करने वाले व्यक्ति या कंपनी की चुनी गई वैल्यू. इसमें किसी खास प्रॉडक्ट (SKU) का डेवलपमेंट नाम या कोड नाम शामिल होता है. यह वैल्यू, एक ही ब्रैंड के लिए यूनीक होनी चाहिए. यह कोड, लोगों के लिए पढ़ने लायक होना चाहिए. हालांकि, यह ज़रूरी नहीं है कि इसे असली उपयोगकर्ता देखें. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है. साथ ही, यह वैल्यू रेगुलर एक्सप्रेशन “^[a-zA-Z0-9_-]+$” से मेल खानी चाहिए. प्रॉडक्ट के लाइफ़टाइम के दौरान, इस प्रॉडक्ट के नाम में बदलाव नहीं किया जाना चाहिए.
ODM_SKU	डिवाइस लागू करने वाला व्यक्ति, वैकल्पिक वैल्यू चुन सकता है. इसमें SKU (स्टॉक रखने की यूनिट) होता है. इसका इस्तेमाल, डिवाइस के खास कॉन्फ़िगरेशन को ट्रैक करने के लिए किया जाता है. उदाहरण के लिए, डिवाइस बेचते समय उसमें शामिल किए गए किसी भी पेरिफ़रल. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है. साथ ही, यह वैल्यू रेगुलर एक्सप्रेशन `^([0-9A-Za-z.,_-]+)$` से मैच करनी चाहिए.
SERIAL	"UNKNOWN" दिखाना ज़रूरी है.
टैग	डिवाइस लागू करने वाले व्यक्ति के चुने गए टैग की सूची, जिन्हें कॉमा लगाकर अलग किया गया है. इससे, बिल्ड को और भी अलग किया जा सकता है. टैग को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है और यह रेगुलर एक्सप्रेशन “^[a-zA-Z0-9._-]+” से मैच करता है. साथ ही, इसमें Android प्लैटफ़ॉर्म के तीन सामान्य साइनिंग कॉन्फ़िगरेशन: रिलीज़-की, डेवलपर-की, और टेस्ट-की से जुड़ी वैल्यू में से कोई एक वैल्यू होनी चाहिए.
समय	यह वैल्यू, बिल्ड होने के समय का टाइमस्टैंप दिखाती है.
वाई-फ़ाई के टाइप के बारे में जानकारी	डिवाइस इंप्लीमेंटर की चुनी गई वैल्यू, जो बिल्ड के रनटाइम कॉन्फ़िगरेशन के बारे में बताती है. इस फ़ील्ड में, Android के तीन सामान्य रनटाइम कॉन्फ़िगरेशन में से किसी एक की वैल्यू होनी चाहिए: user, userdebug या eng.
उपयोगकर्ता	उस उपयोगकर्ता (या ऑटोमेटेड उपयोगकर्ता) का नाम या यूज़र आईडी जिसने बिल्ड जनरेट किया है. इस फ़ील्ड के फ़ॉर्मैट के लिए कोई ज़रूरी शर्त नहीं है. हालांकि, यह शर्त ज़रूरी है कि यह शून्य या खाली स्ट्रिंग ("") न हो.
SECURITY_PATCH	यह वैल्यू, किसी बिल्ड के सुरक्षा पैच के लेवल को दिखाती है. इससे यह पता चलना चाहिए कि बाइल्ड, Android के सार्वजनिक सुरक्षा बुलेटिन में बताई गई किसी भी समस्या से किसी भी तरह से सुरक्षित है. यह [YYYY-MM-DD] फ़ॉर्मैट में होना चाहिए. यह Android के सार्वजनिक सुरक्षा बुलेटिन या Android की सुरक्षा से जुड़ी सलाह में दी गई स्ट्रिंग से मेल खानी चाहिए. उदाहरण के लिए, "2015-11-01".
BASE_OS	इस वैल्यू से, बिल्ड के FINGERPRINT पैरामीटर की जानकारी मिलती है. यह वैल्यू, Android के सार्वजनिक सुरक्षा बुलेटिन में दिए गए पैच को छोड़कर, इस बिल्ड से पूरी तरह मेल खाती है. यह सही वैल्यू दिखानी चाहिए. अगर ऐसा कोई बिल्ड मौजूद नहीं है, तो खाली स्ट्रिंग ("") दिखाएं.
BOOTLOADER	डिवाइस लागू करने वाले व्यक्ति की चुनी गई वैल्यू, जो डिवाइस में इस्तेमाल किए गए खास इंटरनल बूटलोडर वर्शन की पहचान करती है. यह वैल्यू, इंसान के पढ़ने लायक फ़ॉर्मैट में होती है. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है. साथ ही, यह वैल्यू रेगुलर एक्सप्रेशन “^[a-zA-Z0-9._-]+$” से मैच करनी चाहिए.
getRadioVersion()	डिवाइस लागू करने वाले व्यक्ति की चुनी गई वैल्यू होनी चाहिए या वैल्यू दिखानी चाहिए. यह वैल्यू, डिवाइस में इस्तेमाल किए गए खास इंटरनल रेडियो/मॉडेम वर्शन की पहचान करती है. साथ ही, यह वैल्यू, इंसान के पढ़ने लायक फ़ॉर्मैट में होनी चाहिए. अगर किसी डिवाइस में कोई इंटरनल रेडियो/मॉडेम नहीं है, तो यह फ़ंक्शन NULL दिखाना चाहिए. इस फ़ील्ड की वैल्यू, 7-बिट ASCII के तौर पर कोड की जानी चाहिए. साथ ही, यह रेगुलर एक्सप्रेशन “^[a-zA-Z0-9._-,]+$” से मैच करनी चाहिए.
getSerial()	यह हार्डवेयर का सीरियल नंबर होना चाहिए. यह एक ही मॉडल और मैन्युफ़ैक्चरर के सभी डिवाइसों के लिए उपलब्ध और यूनीक होना चाहिए. इस फ़ील्ड की वैल्यू, 7-बिट ASCII के तौर पर कोड की जानी चाहिए. साथ ही, यह वैल्यू रेगुलर एक्सप्रेशन “^[a-zA-Z0-9._-,]+$” से मैच करनी चाहिए.

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

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

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

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

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

हर तरह के डिवाइस के लिए, ऐप्लिकेशन के ज़रूरी इंटेंट के बारे में जानने के लिए, कृपया सेक्शन 2 देखें.

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 Open Source Project में पैकेज मैनेजर ने लागू किए हैं.
[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 में ऐसी सेटिंग शामिल हैं जिनकी मदद से, उपयोगकर्ता आसानी से डिफ़ॉल्ट ऐप्लिकेशन चुन सकते हैं. जैसे, होम स्क्रीन या एसएमएस के लिए.

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

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

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

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

[C-2-1] डिफ़ॉल्ट एसएमएस ऐप्लिकेशन बदलने के लिए डायलॉग दिखाने के लिए, android.provider.Telephony.ACTION_CHANGE_DEFAULT इंटेंट को कॉल करने वाला सेटिंग मेन्यू ज़रूर उपलब्ध कराएं.
[C-2-2] उपयोगकर्ता को डिफ़ॉल्ट फ़ोन ऐप्लिकेशन बदलने की अनुमति देने के लिए, डायलॉग दिखाने के android.telecom.action.CHANGE_DEFAULT_DIALER Intent का पालन करना ज़रूरी है.
- आने और जाने वाले कॉल के लिए, उपयोगकर्ता के चुने गए डिफ़ॉल्ट फ़ोन ऐप्लिकेशन के यूज़र इंटरफ़ेस (यूआई) का इस्तेमाल करना ज़रूरी है. हालांकि, आपातकालीन कॉल के लिए, डिवाइस में पहले से इंस्टॉल किए गए फ़ोन ऐप्लिकेशन का इस्तेमाल किया जाएगा.
[C-2-3] android.telecom.action.CHANGE_PHONE_ACCOUNTS के मकसद को पूरा करना ज़रूरी है, ताकि उपयोगकर्ता PhoneAccounts से जुड़े ConnectionServices को कॉन्फ़िगर कर सके. साथ ही, वह डिफ़ॉल्ट PhoneAccount को भी कॉन्फ़िगर कर सके. टेलीकम्यूनिकेशन सेवा देने वाली कंपनी, आउटगोइंग कॉल करने के लिए इस डिफ़ॉल्ट PhoneAccount का इस्तेमाल करेगी. AOSP में इस ज़रूरी शर्त को पूरा करने के लिए, "कॉल" सेटिंग मेन्यू में "कॉल करने के लिए इस्तेमाल किए जा सकने वाले खाते का विकल्प" मेन्यू शामिल किया गया है.
[C-2-4] android.app.role.CALL_REDIRECTION भूमिका वाले ऐप्लिकेशन के लिए, android.telecom.CallRedirectionService की अनुमति ज़रूर होनी चाहिए.
[C-2-5] उपयोगकर्ता को ऐसा ऐप्लिकेशन चुनने की सुविधा देनी चाहिए जिसमें android.app.role.CALL_REDIRECTION की भूमिका हो.
[C-2-6] ऐप्लिकेशन को android.intent.action.SENDTO और android.intent.action.VIEW इंटेंट का पालन करना चाहिए. साथ ही, एसएमएस भेजने/दिखाने के लिए कोई गतिविधि उपलब्ध करानी चाहिए.
[C-SR-1] हमारा सुझाव है कि आप पहले से लोड किए गए डायलर ऐप्लिकेशन के साथ, android.intent.action.ANSWER, android.intent.action.CALL, android.intent.action.CALL_BUTTON, android.intent.action.VIEW & android.intent.action.DIAL इंटेंट का इस्तेमाल करें. यह ऐप्लिकेशन इन इंटेंट को मैनेज कर सकता है और SDK टूल में बताए गए तरीके से इनका जवाब दे सकता है.

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

[C-3-1] टच किए बिना पेमेंट करने के लिए, डिफ़ॉल्ट ऐप्लिकेशन की सेटिंग का मेन्यू दिखाने के लिए, android.settings.NFC_PAYMENT_SETTINGS के इंटेंट का पालन करना ज़रूरी है.
[C-3-2] android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT के इंटेंट का पालन करना ज़रूरी है, ताकि ऐसी ऐक्टिविटी दिखाई जा सके जो उपयोगकर्ता से किसी कैटगरी के लिए डिफ़ॉल्ट कार्ड इम्यूलेशन सेवा बदलने के लिए कहे. इसके लिए, SDK टूल में बताए गए तरीके से डायलॉग बॉक्स खोला जाता है.

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

[C-4-1] SDK में बताए गए इन इंटेंट के लिए डेवलपर की उम्मीदों को पूरा करने वाली गतिविधि दिखाने के लिए, इन इंटेंट android.nfc.action.NDEF_DISCOVERED, android.nfc.action.TAG_DISCOVERED & android.nfc.action.TECH_DISCOVERED का पालन करना ज़रूरी है.

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

[C-5-1] ‘android.bluetooth.adapter.action.REQUEST_ENABLE’ के ज़रिए भेजे गए इंटेंट का पालन करना ज़रूरी है. साथ ही, उपयोगकर्ता को ब्लूटूथ चालू करने की अनुमति देने के लिए, सिस्टम गतिविधि दिखानी होगी.
[C-5-2] ऐप्लिकेशन को ‘android.bluetooth.adapter.action.REQUEST_DISCOVERABLE’ इंटेंट का पालन करना चाहिए. साथ ही, वह सिस्टम गतिविधि दिखाए जो डिस्कवर किए जा सकने वाले मोड का अनुरोध करती है.

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

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

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

[C-7-1] android.settings.INPUT_METHOD_SETTINGS के इंटेंट के जवाब में, तीसरे पक्ष के इनपुट तरीकों को जोड़ने और कॉन्फ़िगर करने के लिए, उपयोगकर्ता के ऐक्सेस की सुविधा देने वाली सुविधा ज़रूर होनी चाहिए.

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

[C-8-1] ऐप्लिकेशन में, पहले से लोड की गई सुलभता सेवाओं के साथ-साथ तीसरे पक्ष की सुलभता सेवाओं को चालू और बंद करने के लिए, उपयोगकर्ता के लिए ऐक्सेस करने लायक तरीका उपलब्ध कराना android.settings.ACCESSIBILITY_SETTINGS ज़रूरी है.

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

[C-9-1] SDK के दस्तावेज़ में बताए गए तरीके के मुताबिक, Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI Intent API लागू करना ज़रूरी है.

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

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

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

[C-11-1] ऐप्लिकेशन में ऐसी गतिविधि होनी चाहिए जो Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS इंटेंट को मैनेज करती हो. हालांकि, इसे बिना किसी कार्रवाई के लागू किया जा सकता है.

अगर डिवाइस में कैमरे के इस्तेमाल की सुविधा android.hardware.camera.any के ज़रिए उपलब्ध कराई गई है, तो:

[C-12-3] SDK टूल के दस्तावेज़ में बताए गए इनटेंट MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE, और MediaStore.ACTION_VIDEO_CAPTURE को मैनेज करने की अनुमति, सिर्फ़ पहले से इंस्टॉल किए गए Android ऐप्लिकेशन को ही दी जानी चाहिए.

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

[C-13-1] उपयोगकर्ता को सिस्टम में डिवाइस एडमिन जोड़ने (या उसे अस्वीकार करने की अनुमति देने) के लिए, यूज़र इंटरफ़ेस (यूआई) को शुरू करने के लिए, इंटेंट android.app.action.ADD_DEVICE_ADMIN का पालन करना ज़रूरी है.
[C-13-2] ऐप्लिकेशन को इन इंटेंट का पालन करना होगा: android.app.action.PROVISION_MANAGED_PROFILE, android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD, android.app.action.SET_NEW_PASSWORD & android.app.action.START_ENCRYPTION. साथ ही, इसमें ऐसी गतिविधि होनी चाहिए जो इन इंटेंट को पूरा करती हो. इस बारे में यहां SDK में बताया गया है.

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

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

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

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

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

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

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

[C-16-1] यह ज़रूरी है कि इंस्टॉल की गई सभी ऑटोमैटिक भरने की सेवाओं के लिए, ऐसे लिंक दिखाए जाएं.

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

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

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

[C-SR-3] हमारा सुझाव है कि आप android.intent.action.TTS_SERVICE, android.speech.tts.engine.INSTALL_TTS_DATA & android.speech.tts.engine.GET_SAMPLE_TEXT इंटेंट का इस्तेमाल करें. इन इंटेंट के लिए, SDK में यहां बताई गई गतिविधि की मदद से इन इंटेंट को पूरा किया जा सकता है.

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

इसमें स्क्रीन सेवर की सुविधा शामिल होनी चाहिए. साथ ही, उपयोगकर्ताओं को android.settings.DREAM_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. नेटिव एपीआई के साथ काम करना

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

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

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

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

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

[C-0-1] यह एक या उससे ज़्यादा तय किए गए Android NDK ABIs के साथ काम करना चाहिए.
[C-0-2] इसमें, मैनेज किए जा रहे एनवायरमेंट में चल रहे कोड के लिए, नेटिव कोड को कॉल करने की सुविधा शामिल होनी चाहिए. इसके लिए, स्टैंडर्ड Java नेटिव इंटरफ़ेस (JNI) के सेमेटिक्स का इस्तेमाल किया जाना चाहिए.
[C-0-3] यह ज़रूरी है कि यह नीचे दी गई सूची में मौजूद हर ज़रूरी लाइब्रेरी के साथ, सोर्स के साथ काम करे (यानी हेडर के साथ काम करे) और एबीआई के लिए बाइनरी के साथ काम करे.
[C-0-5] android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS, और android.os.Build.SUPPORTED_64_BIT_ABIS पैरामीटर की मदद से, डिवाइस पर काम करने वाले नेटिव ऐप्लिकेशन बाइनरी इंटरफ़ेस (एबीआई) की सटीक जानकारी देनी चाहिए. हर पैरामीटर में, एबीआई की सूची को कॉमा लगाकर अलग-अलग किया गया है. इस सूची में, सबसे ज़्यादा से लेकर सबसे कम प्राथमिकता वाले एबीआई को क्रम से लगाया गया है.
[C-0-6] ऊपर दिए गए पैरामीटर की मदद से, एबीआई की इस सूची के सबसेट की रिपोर्ट देना ज़रूरी है. साथ ही, सूची में शामिल नहीं किए गए किसी भी एबीआई की रिपोर्ट नहीं देनी चाहिए.
- armeabi (NDK अब इसे टारगेट के तौर पर इस्तेमाल नहीं करता)
- armeabi-v7a
- arm64-v8a
- x86
- x86-64
[C-0-7] नेटिव एपीआई उपलब्ध कराने वाली इन सभी लाइब्रेरी को, नेटिव कोड वाले ऐप्लिकेशन के लिए उपलब्ध कराना ज़रूरी है:
- libaaudio.so (AAudio नेटिव ऑडियो सपोर्ट)
- libamidi.so (नेटिव MIDI की सुविधा, अगर सेक्शन 5.9 में बताए गए तरीके के मुताबिक android.software.midi की सुविधा का दावा किया गया है)
- libandroid.so (नेटिव Android गतिविधि के लिए सहायता)
- libc (C लाइब्रेरी)
- libcamera2ndk.so
- libdl (डाइनैमिक लिंकर)
- libEGL.so (नेटिव OpenGL सरफ़ेस मैनेजमेंट)
- libGLESv1_CM.so (OpenGL ES 1.x)
- libGLESv2.so (OpenGL ES 2.0)
- libGLESv3.so (OpenGL ES 3.x)
- libicui18n.so
- libicuuc.so
- libjnigraphics.so
- liblog (Android लॉगिंग)
- libmediandk.so (नेटिव मीडिया एपीआई के लिए सहायता)
- libm (गणित लाइब्रेरी)
- libneuralnetworks.so (Neural Networks API)
- libOpenMAXAL.so (OpenMAX AL 1.0.1 के साथ काम करता है)
- libOpenSLES.so (OpenSL ES 1.0.1 ऑडियो की सुविधा)
- libRS.so
- libstdc++ (C++ के लिए कम से कम सहायता)
- libvulkan.so (Vulkan)
- libz (Zlib कंप्रेसन)
- JNI इंटरफ़ेस
[C-0-8] ऊपर दी गई नेटिव लाइब्रेरी के लिए, सार्वजनिक फ़ंक्शन को जोड़ना या हटाना ज़रूरी नहीं है.
[C-0-9] /vendor/etc/public.libraries.txt में, तीसरे पक्ष के ऐप्लिकेशन के लिए सीधे तौर पर उपलब्ध कराई गई, AOSP लाइब्रेरी के अलावा अन्य लाइब्रेरी की सूची देना ज़रूरी है.
[C-0-10] एपीआई लेवल 24 या इसके बाद के वर्शन को टारगेट करने वाले तीसरे पक्ष के ऐप्लिकेशन के लिए, AOSP में सिस्टम लाइब्रेरी के तौर पर लागू और उपलब्ध कराई गई किसी भी अन्य नेटिव लाइब्रेरी को एक्सपोज़ नहीं किया जाना चाहिए, क्योंकि ये लाइब्रेरी रिज़र्व हैं.
[C-0-11] libGLESv3.so लाइब्रेरी की मदद से, NDK में बताए गए सभी OpenGL ES 3.1 और Android एक्सटेंशन पैकेज फ़ंक्शन के सिंबल एक्सपोर्ट करना ज़रूरी है. ध्यान दें कि सभी सिंबल मौजूद होने चाहिए. हालांकि, सेक्शन 7.1.4.1 में, इससे जुड़ी ज़रूरी शर्तों के बारे में ज़्यादा जानकारी दी गई है.
[C-0-12] Vulkan 1.0 के मुख्य फ़ंक्शन सिंबल के साथ-साथ, libvulkan.so लाइब्रेरी के ज़रिए VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1, और VK_KHR_get_physical_device_properties2 एक्सटेंशन के लिए, फ़ंक्शन सिंबल एक्सपोर्ट करना ज़रूरी है. ध्यान दें कि सभी सिंबल मौजूद होने चाहिए. हालांकि, सेक्शन 7.1.4.2 में इस बारे में ज़्यादा जानकारी दी गई है कि हर फ़ंक्शन को कब पूरी तरह से लागू किया जाना चाहिए.
इसे अपस्ट्रीम Android Open Source Project में मौजूद सोर्स कोड और हेडर फ़ाइलों का इस्तेमाल करके बनाया जाना चाहिए

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

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

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

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

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

[C-2-1] /proc/cpuinfo में ये लाइनें शामिल होनी चाहिए. साथ ही, एक ही डिवाइस पर वैल्यू में बदलाव नहीं किया जाना चाहिए. भले ही, उन्हें अन्य एबीआई ने पढ़ा हो.
- Features:, इसके बाद डिवाइस पर काम करने वाली ARMv7 सीपीयू की वैकल्पिक सुविधाओं की सूची दी गई है.
- CPU architecture: के बाद, एक पूर्णांक होता है. इससे डिवाइस पर काम करने वाले सबसे बेहतर ARM आर्किटेक्चर के बारे में पता चलता है (उदाहरण के लिए, "8" के लिए ARMv8 डिवाइसों).
[C-2-2] यहां दिए गए ऑपरेशन हमेशा उपलब्ध होने चाहिए. भले ही, एबीआई को ARMv8 आर्किटेक्चर पर लागू किया गया हो. ऐसा, नेटिव सीपीयू के साथ काम करने की सुविधा या सॉफ़्टवेयर इम्यूलेशन की मदद से किया जा सकता है:
- SWP और SWPB के लिए निर्देश.
- 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 12 ब्रैंच पर अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट से Chromium प्रोजेक्ट के बिल्ड का इस्तेमाल करना ज़रूरी है.
[C-1-3] वेबव्यू की रिपोर्ट की गई यूज़र एजेंट स्ट्रिंग इस फ़ॉर्मैट में होनी चाहिए:

Mozilla/5.0 (Linux; Android $(VERSION); [$(MODEL)] [Build/$(BUILD)]; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36
- $(VERSION) स्ट्रिंग की वैल्यू, android.os.Build.VERSION.RELEASE की वैल्यू के बराबर होनी चाहिए.
- $(MODEL) स्ट्रिंग खाली हो सकती है. हालांकि, अगर यह खाली नहीं है, तो इसकी वैल्यू, android.os.Build.MODEL की वैल्यू के बराबर होनी चाहिए.
- "Build/$(BUILD)" को छोड़ा जा सकता है. हालांकि, अगर यह मौजूद है, तो $(BUILD) स्ट्रिंग, android.os.Build.ID की वैल्यू के बराबर होनी चाहिए.
- $(CHROMIUM_VER) स्ट्रिंग की वैल्यू, अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट में मौजूद Chromium का वर्शन होनी चाहिए.
- डिवाइस लागू करने पर, हो सकता है कि उपयोगकर्ता एजेंट स्ट्रिंग में मोबाइल को शामिल न किया जाए.
वेबव्यू कॉम्पोनेंट में, ज़्यादा से ज़्यादा HTML5 सुविधाओं के साथ काम करने की सुविधा होनी चाहिए. अगर यह सुविधा काम करती है, तो यह HTML5 स्पेसिफ़िकेशन के मुताबिक होनी चाहिए.
[C-1-4] दिए गए कॉन्टेंट या रिमोट यूआरएल के कॉन्टेंट को ऐसी प्रोसेस में रेंडर करना चाहिए जो वेबव्यू को इंस्टैंशिएट करने वाले ऐप्लिकेशन से अलग हो. खास तौर पर, अलग रेंडरर प्रोसेस के पास कम से कम अनुमतियां होनी चाहिए. साथ ही, वह अलग यूज़र आईडी के तौर पर चलनी चाहिए. इसके अलावा, उसके पास ऐप्लिकेशन की डेटा डायरेक्ट्री का ऐक्सेस नहीं होना चाहिए. साथ ही, उसके पास नेटवर्क का सीधा ऐक्सेस नहीं होना चाहिए. इसके अलावा, उसके पास Binder के ज़रिए सिर्फ़ ज़रूरी सिस्टम सेवाओं का ऐक्सेस होना चाहिए. AOSP में वेबव्यू लागू करने की सुविधा, इस ज़रूरी शर्त को पूरा करती है.

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

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

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

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

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

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

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

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

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

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

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

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

3.5.1. ऐप्लिकेशन पर पाबंदी

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

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

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

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

3.5.2. ऐप्लिकेशन का हाइबरनेशन मोड

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

[C-1-1] को [C-1-6] और [C-1-3] को छोड़कर, सेक्शन 3.5.1 की सभी ज़रूरी शर्तें पूरी करनी होंगी.
[C-1-2] किसी उपयोगकर्ता के लिए ऐप्लिकेशन पर पाबंदी सिर्फ़ तब लगानी चाहिए, जब इस बात का सबूत हो कि उपयोगकर्ता ने कुछ समय से ऐप्लिकेशन का इस्तेमाल नहीं किया है. हमारा सुझाव है कि आप इस अवधि को एक महीने या उससे ज़्यादा रखें. UsageStats#getLastTimeVisible() एपीआई के ज़रिए, उपयोगकर्ता के साफ़ तौर पर इंटरैक्ट करने या किसी ऐसे ऐप्लिकेशन के इस्तेमाल से, ऐप्लिकेशन के इस्तेमाल की जानकारी मिलनी चाहिए जिसकी वजह से ऐप्लिकेशन को 'जबर्दस्ती बंद किया गया' स्टेटस से बाहर निकाला गया हो. इनमें सेवा बाइंडिंग, कॉन्टेंट देने वाली कंपनी की बाइंडिंग, साफ़ तौर पर दिखाए जाने वाले ब्रॉडकास्ट वगैरह शामिल हैं. इनकी जानकारी, नए एपीआई UsageStats#getLastTimeAnyComponentUsed से ट्रैक की जाएगी.
[C-1-3] डिवाइस के सभी उपयोगकर्ताओं पर असर डालने वाली पाबंदियां सिर्फ़ तब लागू की जानी चाहिए, जब इस बात का सबूत हो कि किसी उपयोगकर्ता ने कुछ समय तक पैकेज का इस्तेमाल नहीं किया है. हमारा सुझाव है कि यह अवधि एक महीने या उससे ज़्यादा हो.
[C-1-4] ऐप्लिकेशन को गतिविधि के इंटेंट, सेवा बाइंडिंग, कॉन्टेंट उपलब्ध कराने वाले के अनुरोधों या साफ़ तौर पर ब्रॉडकास्ट किए जाने वाले कॉन्टेंट का जवाब देने में सक्षम होना चाहिए.

AOSP में ऐप्लिकेशन हाइबरनेट करने की सुविधा, ऊपर दी गई ज़रूरी शर्तों को पूरा करती है.

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

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

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

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

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

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

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

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

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

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

[C-1-1] यह ज़रूरी है कि यह NDK लाइब्रेरी या किसी ऐसे संगठन की लाइब्रेरी में न हो जिसके बारे में यहां बताया गया है.

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

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

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

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

[C-0-1] यह ज़रूरी है कि यह Dalvik Executable (DEX) फ़ॉर्मैट और Dalvik बाइटकोड स्पेसिफ़िकेशन और सेमेंटेक्स के साथ काम करे.
[C-0-2] अपस्ट्रीम Android प्लैटफ़ॉर्म के मुताबिक मेमोरी को बांटने के लिए, Dalvik रनटाइम को कॉन्फ़िगर करना ज़रूरी है. साथ ही, यह भी ज़रूरी है कि मेमोरी को बांटने का तरीका, नीचे दी गई टेबल में बताए गए तरीके के मुताबिक हो. (स्क्रीन साइज़ और स्क्रीन डेंसिटी की परिभाषाओं के लिए, सेक्शन 7.1.1 देखें.)
Android RunTime (ART), Dalvik Executable Format के रेफ़रंस अपस्ट्रीम लागू करने के तरीके, और रेफ़रंस लागू करने के तरीके के पैकेज मैनेजमेंट सिस्टम का इस्तेमाल करना चाहिए.
रनटाइम के स्थिर होने की पुष्टि करने के लिए, फ़ज़ टेस्ट को अलग-अलग तरीके से चलाना चाहिए और टारगेट किए गए आर्किटेक्चर का इस्तेमाल करना चाहिए. Android Open Source Project की वेबसाइट पर, JFuzz और DexFuzz के बारे में जानें.

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

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

3.8. यूज़र इंटरफ़ेस के साथ काम करना

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

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

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

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

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

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

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

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

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

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

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

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

3.8.2. विजेट

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

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

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

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

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

3.8.3. सूचनाएं

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

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

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

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

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

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

[C-SR-4] हमारा सुझाव है कि आप conversation notifications को ग्रुप में डालें और उसे बातचीत से जुड़ी सूचनाओं के बजाय पहले दिखाएं. हालांकि, फ़ोरग्राउंड सेवा की सूचनाओं और importance:high की सूचनाओं को छोड़कर.

अगर डिवाइस पर conversation notifications को लागू करने की सुविधा उपलब्ध है और ऐप्लिकेशन, bubbles के लिए ज़रूरी डेटा उपलब्ध कराता है, तो:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.4. Assist API

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

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

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

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

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

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

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

3.8.6. थीम

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

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

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

[C-1-1] ऐप्लिकेशन के लिए उपलब्ध Holo थीम एट्रिब्यूट में बदलाव नहीं किया जाना चाहिए.
[C-1-2] यह “Material” थीम फ़ैमिली के साथ काम करना चाहिए. साथ ही, Material थीम एट्रिब्यूट या ऐप्लिकेशन के लिए उपलब्ध कराई गई उनकी ऐसेट में कोई बदलाव नहीं करना चाहिए.
[C-1-3] "sans-serif" फ़ॉन्ट फ़ैमिली को, Roboto के साथ काम करने वाली भाषाओं के लिए, Roboto वर्शन 2.x पर सेट करना ज़रूरी है. इसके अलावा, उपयोगकर्ता को "sans-serif" फ़ॉन्ट फ़ैमिली के लिए इस्तेमाल किए गए फ़ॉन्ट को, Roboto के साथ काम करने वाली भाषाओं के लिए, Roboto वर्शन 2.x पर बदलने का विकल्प देना ज़रूरी है.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[C-1-1] Android SDK के दस्तावेज़ में बताए गए मुताबिक, प्लैटफ़ॉर्म की सुविधा android.software.input_methods का एलान करना ज़रूरी है. साथ ही, IME API का इस्तेमाल करना ज़रूरी है.

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

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

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

स्क्रीन सेवर को कॉन्फ़िगर करने के लिए, सेटिंग के इंटेंट के बारे में जानने के लिए सेक्शन 3.2.3.5 देखें.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[C-3-1] ऐप्लिकेशन के इन स्थितियों में होने पर, गतिविधियों को पिक्चर में पिक्चर वाले मल्टी-विंडो मोड में लॉन्च करना ज़रूरी है:
- एपीआई लेवल 26 या उसके बाद के वर्शन को टारगेट करता हो और android:supportsPictureInPicture का एलान करता हो
- एपीआई लेवल 25 या उससे पहले के वर्शन को टारगेट करता हो और android:resizeableActivity और android:supportsPictureInPicture, दोनों का एलान करता हो.
[C-3-2] setActions() API के ज़रिए, मौजूदा पीआईपी गतिविधि के मुताबिक, अपने SystemUI में ऐक्शन दिखाना ज़रूरी है.
[C-3-3] आसपेक्ट रेशियो 1:2.39 से ज़्यादा या उसके बराबर और 2.39:1 से कम या उसके बराबर होना चाहिए. जैसा कि setAspectRatio() एपीआई के ज़रिए पीआईपी गतिविधि में बताया गया है.
[C-3-4] पीआईपी विंडो को कंट्रोल करने के लिए, KeyEvent.KEYCODE_WINDOW का इस्तेमाल करना ज़रूरी है. अगर पीआईपी मोड लागू नहीं किया गया है, तो फ़ोरग्राउंड गतिविधि के लिए बटन उपलब्ध होना चाहिए.
[C-3-5] किसी ऐप्लिकेशन को पीआईपी मोड में दिखने से रोकने के लिए, उपयोगकर्ता को ऐसा तरीका देना ज़रूरी है जिससे वह ऐसा कर सके. AOSP में, सूचना शेड में कंट्रोल होने की वजह से यह ज़रूरी शर्त पूरी हो जाती है.
[C-3-6] अगर कोई ऐप्लिकेशन AndroidManifestLayout_minWidth और AndroidManifestLayout_minHeight के लिए कोई वैल्यू नहीं तय करता है, तो पीआईपी विंडो के लिए कम से कम यह चौड़ाई और ऊंचाई तय करना ज़रूरी है:
- जिन डिवाइसों में Configuration.uiMode की वैल्यू, UI_MODE_TYPE_TELEVISION के अलावा किसी दूसरी वैल्यू पर सेट है उनके लिए, कम से कम 108 डीपी की चौड़ाई और ऊंचाई तय करना ज़रूरी है.
- जिन डिवाइसों में Configuration.uiMode को UI_MODE_TYPE_TELEVISION पर सेट किया गया है उनके लिए, कम से कम 240 डीपी की चौड़ाई और 135 डीपी की ऊंचाई तय करना ज़रूरी है.

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

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

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

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

3.8.16. डिवाइस कंट्रोल

Android में ControlsProviderService और Control एपीआई शामिल हैं. इनकी मदद से, तीसरे पक्ष के ऐप्लिकेशन, डिवाइस के कंट्रोल पब्लिश कर सकते हैं, ताकि उपयोगकर्ताओं को डिवाइस की स्थिति और कार्रवाई के बारे में तुरंत जानकारी मिल सके.

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

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

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

अगर डिवाइस पर, 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-5] अगर डिवाइस में सुविधा फ़्लैग android.hardware.nfc के ज़रिए, नियर फ़ील्ड कम्यूनिकेशन (एनएफ़सी) की सुविधा के काम करने की जानकारी दी गई है और उसे MIME टाइप MIME_TYPE_PROVISIONING_NFC वाला रिकॉर्ड वाला एनएफ़सी मैसेज मिलता है, तो DPC ऐप्लिकेशन को डिवाइस के मालिक के ऐप्लिकेशन के तौर पर रजिस्टर करना ज़रूरी है.
  - [C-1-8] डिवाइस के मालिक के लिए प्रोविज़निंग ट्रिगर होने के बाद, ACTION_GET_PROVISIONING_MODE इंटेंट भेजना ज़रूरी है, ताकि डीपीसी ऐप्लिकेशन यह चुन सके कि वह डिवाइस का मालिक बनेगा या प्रोफ़ाइल का मालिक. ऐसा तब तक करना होगा, जब तक कि कॉन्टेक्स्ट से यह पता न चल जाए कि सिर्फ़ एक मान्य विकल्प है. जैसे, एनएफ़सी पर आधारित प्रोविज़निंग के लिए, जहां प्रोफ़ाइल के मालिक के तौर पर प्रोविज़निंग काम नहीं करती.
  - [C-1-9] डिवाइस के मालिक के ऐप्लिकेशन को ACTION_ADMIN_POLICY_COMPLIANCE इंटेंट भेजना ज़रूरी है. ऐसा तब करना होगा, जब डिवाइस के मालिक की जानकारी, डिवाइस को कॉन्फ़िगर करने के दौरान डाली गई हो. भले ही, डिवाइस को कॉन्फ़िगर करने के लिए किसी भी तरीके का इस्तेमाल किया गया हो. डिवाइस के मालिक का ऐप्लिकेशन पूरा होने तक, उपयोगकर्ता को सेटअप विज़र्ड में आगे बढ़ने की अनुमति नहीं मिलनी चाहिए.
- जब डिवाइस में उपयोगकर्ता का डेटा मौजूद होता है, तो:
  - [C-1-7] अब किसी भी डीपीसी ऐप्लिकेशन को डिवाइस के मालिक के ऐप्लिकेशन के तौर पर रजिस्टर नहीं करना चाहिए.
[C-1-2] डिवाइस के मालिक के तौर पर ऐप्लिकेशन को सेट करने की सहमति देने के लिए, डिवाइस को डिवाइस के मालिक के तौर पर सेट करने की प्रोसेस से पहले या उसके दौरान, उपयोगकर्ता को कुछ कार्रवाई करनी होगी. सहमति, उपयोगकर्ता की कार्रवाई या प्रोग्राम के हिसाब से ली जा सकती है. हालांकि, डिवाइस के मालिक के लिए डिवाइस की जानकारी सेट अप करने की प्रोसेस शुरू करने से पहले, ज़ाहिर की जाने वाली सही सूचना (जैसा कि AOSP में बताया गया है) दिखाना ज़रूरी है. साथ ही, डिवाइस के मालिक की सहमति देने के लिए, एंटरप्राइज़ के इस्तेमाल किए जाने वाले प्रोग्राम के हिसाब से डिवाइस के मालिक की सहमति देने के तरीके से, एंटरप्राइज़ के अलावा अन्य लोगों के लिए, डिवाइस के इस्तेमाल से जुड़े अनुभव पर कोई असर नहीं पड़ना चाहिए.
[C-1-3] ऐप्लिकेशन को सहमति को हार्ड कोड नहीं करना चाहिए या डिवाइस के मालिक के दूसरे ऐप्लिकेशन के इस्तेमाल को रोकना चाहिए.

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

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

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

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

[C-1-1] एपीआई लागू करने ज़रूरी हैं, ताकि डिवाइस नीति नियंत्रक (डीपीसी) ऐप्लिकेशन, मैनेज की जा रही नई प्रोफ़ाइल का मालिक बन सके.
[C-1-2] मैनेज की जा रही प्रोफ़ाइल को उपलब्ध कराने की प्रोसेस (android.app.action.PROVISION_MANAGED_PROFILE का इस्तेमाल करके डीपीसी की ओर से शुरू किया गया फ़्लो) या प्लैटफ़ॉर्म की ओर से, सहमति स्क्रीन और उपयोगकर्ता अनुभव को एओएसपी के लागू होने के साथ अलाइन करना ज़रूरी है.
[C-1-3] डिवाइस नीति कंट्रोलर (डीपीसी) के ज़रिए किसी खास सिस्टम फ़ंक्शन के बंद होने की जानकारी देने के लिए, सेटिंग में ये सुविधाएं उपलब्ध कराई जानी चाहिए:
- डिवाइस एडमिन ने किसी सेटिंग पर पाबंदी लगाई है, तो यह बताने के लिए एक आइकॉन या उपयोगकर्ता के लिए कोई अन्य सुविधा (उदाहरण के लिए, अपस्ट्रीम AOSP का जानकारी वाला आइकॉन).
- setShortSupportMessage के ज़रिए डिवाइस एडमिन की ओर से दिया गया, कम शब्दों में जानकारी देने वाला मैसेज.
- डीपीसी ऐप्लिकेशन का आइकॉन.
[C-1-4] अगर android.app.action.PROVISION_MANAGED_PROFILE इंटेंट से प्रोवाइज़निंग शुरू करने पर, प्रोफ़ाइल का मालिक तय हो जाता है और डीपीसी ने हैंडलर लागू कर दिया है, तो वर्क प्रोफ़ाइल में ACTION_PROVISIONING_SUCCESSFUL इंटेंट के लिए हैंडलर लॉन्च करना ज़रूरी है.
[C-1-5] android.app.action.PROVISION_MANAGED_PROFILE के ज़रिए प्रोविज़न करने की प्रोसेस शुरू होने पर, वर्क प्रोफ़ाइल के डीपीसी को ACTION_PROFILE_PROVISIONING_COMPLETE ब्रॉडकास्ट भेजना ज़रूरी है.
[C-1-6] प्रोफ़ाइल के मालिक के लिए डिवाइस को प्रोवाइड करने की सुविधा ट्रिगर होने के बाद, ACTION_GET_PROVISIONING_MODE इंटेंट भेजना ज़रूरी है, ताकि डीपीसी ऐप्लिकेशन यह चुन सके कि उसे डिवाइस का मालिक बनाना है या प्रोफ़ाइल का मालिक. हालांकि, अगर इंटेंट android.app.action.PROVISION_MANAGED_PROFILE से डिवाइस को प्रोवाइड करने की सुविधा ट्रिगर होती है, तो ऐसा नहीं करना होगा.
[C-1-7] प्रोवाइज़न करने के दौरान, अगर प्रोफ़ाइल का मालिक तय किया जाता है, तो वर्क प्रोफ़ाइल को ACTION_ADMIN_POLICY_COMPLIANCE इंटेंट भेजना ज़रूरी है. भले ही, प्रोवाइज़ करने के लिए किसी भी तरीके का इस्तेमाल किया गया हो. हालांकि, अगर प्रोवाइज़ करने की प्रोसेस, android.app.action.PROVISION_MANAGED_PROFILE इंटेंट से ट्रिगर होती है, तो ऐसा करना ज़रूरी नहीं है. जब तक प्रोफ़ाइल के मालिक का ऐप्लिकेशन इंस्टॉल नहीं हो जाता, तब तक उपयोगकर्ता को सेटअप विज़र्ड में आगे बढ़ने की अनुमति नहीं मिलनी चाहिए.
[C-1-8] प्रोफ़ाइल का मालिक तय होने पर, निजी प्रोफ़ाइल के डीपीसी को ACTION_MANAGED_PROFILE_PROVISIONED ब्रॉडकास्ट भेजना ज़रूरी है. भले ही, प्रोफ़ाइल को उपलब्ध कराने का तरीका कुछ भी हो.

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

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

[C-1-1] android.app.admin.DevicePolicyManager एपीआई की मदद से, मैनेज की जा रही प्रोफ़ाइलों को इस्तेमाल करने की सुविधा होनी चाहिए.
[C-1-2] सिर्फ़ एक मैनेज की जा रही प्रोफ़ाइल बनाने की अनुमति होनी चाहिए.
[C-1-3] मैनेज किए जा रहे ऐप्लिकेशन और विजेट के साथ-साथ, बैज वाले अन्य यूज़र इंटरफ़ेस (यूआई) एलिमेंट को दिखाने के लिए, आइकॉन बैज का इस्तेमाल करना ज़रूरी है. जैसे, हाल ही में इस्तेमाल किए गए ऐप्लिकेशन और सूचनाएं. यह बैज, AOSP अपस्ट्रीम वर्क बैज जैसा होना चाहिए.
[C-1-4] यह ज़रूरी है कि जब उपयोगकर्ता मैनेज की जा रही प्रोफ़ाइल वाले ऐप्लिकेशन का इस्तेमाल कर रहा हो, तब सूचना आइकॉन दिखे. यह आइकॉन, AOSP अपस्ट्रीम वर्क बैज जैसा होना चाहिए.
[C-1-6] अगर कोई मैनेज की जा रही प्रोफ़ाइल मौजूद है, तो इंटेंट 'चुने जाने वाले' में विज़ुअल अवफ़र्डेंस दिखाना ज़रूरी है. इससे उपयोगकर्ता, मैनेज की जा रही प्रोफ़ाइल से प्राइमरी उपयोगकर्ता को इंटेंट फ़ॉरवर्ड कर सकता है. इसके अलावा, अगर डिवाइस नीति कंट्रोलर की ओर से चालू किया गया है, तो प्राइमरी उपयोगकर्ता से मैनेज की जा रही प्रोफ़ाइल को इंटेंट फ़ॉरवर्ड किया जा सकता है.
[C-1-7] अगर कोई मैनेज की जा रही प्रोफ़ाइल मौजूद है, तो प्राइमरी उपयोगकर्ता और मैनेज की जा रही प्रोफ़ाइल, दोनों के लिए ये सुविधाएं ज़रूर उपलब्ध कराएं:
- प्राइमरी उपयोगकर्ता और मैनेज की जा रही प्रोफ़ाइल के लिए, बैटरी, जगह की जानकारी, मोबाइल डेटा, और स्टोरेज के इस्तेमाल का अलग-अलग हिसाब.
- मुख्य उपयोगकर्ता या मैनेज की जा रही प्रोफ़ाइल में इंस्टॉल किए गए वीपीएन ऐप्लिकेशन को अलग से मैनेज किया जा सकता है.
- मुख्य उपयोगकर्ता या मैनेज की जा रही प्रोफ़ाइल में इंस्टॉल किए गए ऐप्लिकेशन को अलग से मैनेज किया जा सकता है.
- मुख्य उपयोगकर्ता या मैनेज की जा रही प्रोफ़ाइल में मौजूद खातों को अलग से मैनेज करना.
[C-1-8] यह पक्का करना ज़रूरी है कि पहले से इंस्टॉल किए गए डायलर, संपर्क, और मैसेजिंग ऐप्लिकेशन, डिवाइस नीति कंट्रोलर की अनुमति मिलने पर, प्राइमरी प्रोफ़ाइल के साथ-साथ मैनेज की जा रही प्रोफ़ाइल (अगर कोई मौजूद है) से भी कॉलर की जानकारी खोज और देख सकें.
[C-1-9] यह पक्का करना ज़रूरी है कि यह उन सभी सुरक्षा ज़रूरी शर्तों को पूरा करता हो जो एक से ज़्यादा उपयोगकर्ताओं के लिए चालू किए गए डिवाइस पर लागू होती हैं (सेक्शन 9.5 देखें). भले ही, मैनेज की जा रही प्रोफ़ाइल को मुख्य उपयोगकर्ता के अलावा किसी दूसरे उपयोगकर्ता के तौर पर नहीं गिना जाता.

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

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

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

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

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

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

[C-SR-1] हमारा सुझाव है कि डिवाइस के मालिक की सहमति से जुड़ी जानकारी ज़ाहिर करने के लिए, AOSP के उसी फ़ॉर्म का इस्तेमाल करें जो android.app.action.PROVISION_MANAGED_DEVICE से शुरू किए गए फ़्लो में दिखाया गया था. ऐसा इसलिए, ताकि उपयोगकर्ता यह समझ सकें कि डिवाइस मैनेज किया जा रहा है. साथ ही, नए सेकंडरी उपयोगकर्ता के खाते जोड़ने की अनुमति देने से पहले, ऐसा करना ज़रूरी है.

3.10. सुलभता

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

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

[C-1-1] ऐप्लिकेशन में, Android के सुलभता फ़्रेमवर्क को लागू करना ज़रूरी है. इसके बारे में, Accessibility API के SDK दस्तावेज़ में बताया गया है.
[C-1-2] SDK टूल में बताए गए तरीके के मुताबिक, सुलभता इवेंट जनरेट करने चाहिए और रजिस्टर किए गए सभी AccessibilityService लागू करने के लिए सही AccessibilityEvent डिलीवर करने चाहिए.
[C-1-4] ऐक्सेसibiliti सेवाओं को कंट्रोल करने के लिए, उपयोगकर्ता को एक सुविधा देनी ज़रूरी है. ये सेवाएं, AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON का एलान करती हैं. ध्यान दें कि सिस्टम नेविगेशन बार वाले डिवाइसों के लिए, उपयोगकर्ता को सिस्टम के नेविगेशन बार में एक बटन का विकल्प देना चाहिए, ताकि वह इन सेवाओं को कंट्रोल कर सके.

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

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

3.11. लिखे गए शब्दों को सुनने की सुविधा

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

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

[C-1-1] ऐप्लिकेशन में, Android टीटीएस फ़्रेमवर्क के एपीआई का इस्तेमाल किया जाना चाहिए.

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

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

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

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

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

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

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

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

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

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

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

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

[C-1-2] MediaDescription में बताए गए तरीके से, getIconBitmap() या getIconUri() से मिले आइकॉन और getTitle() से मिले टाइटल साफ़ तौर पर दिखने चाहिए. सुरक्षा से जुड़े नियमों का पालन करने के लिए, वीडियो के टाइटल छोटे किए जा सकते हैं. जैसे, ड्राइवर का ध्यान भटकाना.
[C-1-3] तीसरे पक्ष के इस ऐप्लिकेशन से मिलने वाला कॉन्टेंट दिखाते समय, तीसरे पक्ष के ऐप्लिकेशन का आइकॉन दिखाना ज़रूरी है.
[C-1-4] उपयोगकर्ता को पूरी MediaBrowser के साथ इंटरैक्ट करने की अनुमति देनी चाहिए. सुरक्षा से जुड़े नियमों (जैसे, ड्राइवर का ध्यान भटकना) का पालन करने के लिए, हैरारकी के कुछ हिस्से के ऐक्सेस पर पाबंदी लगाई जा सकती है. हालांकि, कॉन्टेंट या कॉन्टेंट उपलब्ध कराने वाले के आधार पर, किसी को भी प्राथमिकता नहीं दी जानी चाहिए.
[C-1-5] MediaSession.Callback#onMediaButtonEvent के लिए, KEYCODE_HEADSETHOOK या KEYCODE_MEDIA_PLAY_PAUSE पर दो बार टैप करने को KEYCODE_MEDIA_NEXT के तौर पर स्वीकार करना ज़रूरी है.

3.15. Instant Apps

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

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

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

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

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

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

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

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

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

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

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

3.18. संपर्क

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

RawContacts, किसी खाते से "जुड़े हुए" या "उसमें सेव किए गए" होते हैं, जब रॉ संपर्कों के लिए ACCOUNT_NAME और ACCOUNT_TYPE कॉलम, खाते के Account.name और Account.type फ़ील्ड से मेल खाते हैं.

डिफ़ॉल्ट लोकल खाता: यह उन रॉ संपर्कों के लिए खाता है जिन्हें सिर्फ़ डिवाइस पर सेव किया जाता है. यह AccountManager में मौजूद किसी खाते से नहीं जुड़ा होता. इन संपर्कों को ACCOUNT_NAME और ACCOUNT_TYPE कॉलम के लिए शून्य वैल्यू के साथ बनाया जाता है.

कस्टम लोकल खाता: यह रॉ संपर्कों के लिए एक खाता है. यह सिर्फ़ डिवाइस पर सेव होता है और AccountManager में किसी खाते से नहीं जुड़ा होता. इसे ACCOUNT_NAME और ACCOUNT_TYPE कॉलम के लिए, कम से कम एक ऐसी वैल्यू के साथ बनाया जाता है जो शून्य न हो.

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

[C-SR-1] हमारा सुझाव है कि कस्टम लोकल खाते न बनाएं.

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

[C-1-1] कस्टम लोकल खाते का ACCOUNT_NAME, ContactsContract.RawContacts.getLocalAccountName से वापस लौटाया जाना चाहिए
[C-1-2] कस्टम लोकल खाते का ACCOUNT_TYPE, ContactsContract.RawContacts.getLocalAccountType से वापस लाया जाना चाहिए
[C-1-3] तीसरे पक्ष के ऐप्लिकेशन, डिफ़ॉल्ट लोकल खाते (यानी ACCOUNT_NAME और ACCOUNT_TYPE के लिए शून्य वैल्यू सेट करके) के साथ रॉ संपर्क डालते हैं. इन्हें कस्टम लोकल खाते में डालना ज़रूरी है.
[C-1-4] खाते जोड़ने या हटाने पर, कस्टम लोकल खाते में डाले गए रॉ संपर्कों को हटाया नहीं जाना चाहिए.
[C-1-5] कस्टम लोकल खाते के लिए किए गए मिटाएं ऑपरेशन के बाद, रॉ संपर्क तुरंत मिटा दिए जाने चाहिए (जैसे कि CALLER_IS_SYNCADAPTER पैरामीटर को 'सही' पर सेट किया गया हो), भले ही CALLER\_IS\_SYNCADAPTER पैरामीटर को 'गलत' पर सेट किया गया हो या उसकी जानकारी न दी गई हो.

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

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

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

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

[C-0-2] यह ज़रूरी है कि यह टूल, APK सिग्नेचर स्कीम v3, APK सिग्नेचर स्कीम v2, और JAR साइनिंग का इस्तेमाल करके, “.apk” फ़ाइलों की पुष्टि कर सके.
[C-0-3] .apk, Android मेनिफ़ेस्ट, Dalvik बाइटकोड या रेंडरस्क्रिप्ट बाइटकोड फ़ॉर्मैट को इस तरह से एक्सटेंड़ नहीं किया जाना चाहिए कि उन फ़ाइलों को काम करने वाले अन्य डिवाइसों पर सही तरीके से इंस्टॉल और चलाने में समस्या आए.
[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 के ज़रिए संभावित रूप से नुकसान पहुंचाने वाली के तौर पर मार्क की गई हो.
चेतावनी वाले डायलॉग में, उपयोगकर्ता को ऐप्लिकेशन को अनइंस्टॉल करने या लॉन्च करने का विकल्प देना चाहिए.
[C-0-8] यहां बताए गए तरीके के मुताबिक, इंक्रीमेंटल फ़ाइल सिस्टम के लिए सहायता लागू करना ज़रूरी है.
[C-0-9] APK सिग्नेचर स्कीम v4 का इस्तेमाल करके, .apk फ़ाइलों की पुष्टि करने की सुविधा होनी चाहिए.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

फ़ॉर्मैट/कोडेक	जानकारी	इस्तेमाल किए जा सकने वाले फ़ाइल टाइप/कंटेनर फ़ॉर्मैट
MPEG-4 AAC प्रोफ़ाइल (AAC LC)	स्टैंडर्ड सैंपलिंग रेट (8 से 48 किलोहर्ट्ज़) के साथ, मोनो/स्टीरियो/5.0/5.1 कॉन्टेंट के लिए काम करता है.	3GPP (.3gp) MPEG-4 (.mp4, .m4a) ADTS रॉ AAC (.aac, ADIF काम नहीं करता) एमपीईजी-टीएस (.ts, आगे-पीछे नहीं किया जा सकता, सिर्फ़ डीकोड किया जा सकता है) Matroska (.mkv, सिर्फ़ डिकोड करने के लिए)
MPEG-4 HE AAC प्रोफ़ाइल (AAC+)	मोनो/स्टीरियो/5.0/5.1 ऑडियो वाले कॉन्टेंट के लिए, 16 से 48 किलोहर्ट्ज़ के स्टैंडर्ड सैंपलिंग रेट की सुविधा.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
MPEG-4 HE AACv2 प्रोफ़ाइल (बेहतर AAC+)	मोनो/स्टीरियो/5.0/5.1 ऑडियो वाले कॉन्टेंट के लिए, 16 से 48 किलोहर्ट्ज़ के स्टैंडर्ड सैंपलिंग रेट की सुविधा.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
AAC ELD (बेहतर कम इंतज़ार वाला AAC)	मोनो/स्टीरियो कॉन्टेंट के लिए, 16 से लेकर 48 किलोहर्ट्ज़ तक के स्टैंडर्ड सैंपलिंग रेट का इस्तेमाल किया जा सकता है.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
USAC	मोनो/स्टीरियो कॉन्टेंट के लिए, 7.35 से 48 kHz तक के स्टैंडर्ड सैंपलिंग रेट का इस्तेमाल किया जा सकता है.	MPEG-4 (.mp4, .m4a)
AMR-NB	8 केएचज़ पर सैंपल किए गए 4.75 से 12.2 केबीपीएस	3GPP (.3gp)
AMR-WB	AMR-WB, Adaptive Multi-Rate - Wideband Speech Codec के मुताबिक, 16 किलोहर्ट्ज़ पर सैंपल किए गए 6.60 केबीटी/सेकंड से 23.85 केबीटी/सेकंड तक के नौ रेट	3GPP (.3gp)
FLAC	एन्कोडर और डिकोडर, दोनों के लिए: कम से कम मोनो और स्टीरियो मोड काम करने चाहिए. इसमें 192 किलोहर्ट्ज़ तक के सैंपल रेट का इस्तेमाल किया जा सकता हो. साथ ही, 16-बिट और 24-बिट रिज़ॉल्यूशन का इस्तेमाल किया जा सकता हो. फ़्लोटिंग पॉइंट ऑडियो कॉन्फ़िगरेशन के साथ, FLAC 24-बिट ऑडियो डेटा मैनेजमेंट की सुविधा ज़रूर होनी चाहिए.	FLAC (.flac) MPEG-4 (.mp4, .m4a, सिर्फ़ डिकोड करने के लिए) Matroska (.mkv, सिर्फ़ डिकोड करने के लिए)
MP3	मोनो/स्टीरियो 8-320 केबीपीएस कॉन्स्टेंट (सीबीआर) या वैरिएबल बिटरेट (वीबीआर)	MP3 (.mp3) MPEG-4 (.mp4, .m4a, सिर्फ़ डिकोड करने के लिए) Matroska (.mkv, सिर्फ़ डिकोड करने के लिए)
MIDI	एमआईडीआई टाइप 0 और 1. डीएलएस का वर्शन 1 और 2. XMF और Mobile XMF. रिंगटोन के लिए RTTTL/RTX, OTA, और iMelody फ़ॉर्मैट का इस्तेमाल किया जा सकता है	टाइप 0 और 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) iMelody (.imy)
Vorbis		Ogg (.ogg) MPEG-4 (.mp4, .m4a, सिर्फ़ डिकोड करने के लिए) Matroska (.mkv) Webm (.webm)
PCM/WAVE	PCM कोडेक, 16-बिट लीनियर PCM और 16-बिट फ़्लोट के साथ काम करना चाहिए. WAVE एक्सट्रैक्टर में 16-बिट, 24-बिट, 32-बिट लीनियर PCM, और 32-बिट फ़्लोट (हार्डवेयर की सीमा तक रेट) का इस्तेमाल किया जा सकता है. सैंपलिंग रेट, 8 किलोहर्ट्ज़ से लेकर 192 किलोहर्ट्ज़ के बीच होने चाहिए.	WAVE (.wav)
Opus	डिकोडिंग: 8000, 12000, 16000, 24000, और 48000 हर्ट्ज़ की सैंपलिंग रेट के साथ, मोनो, स्टीरियो, 5.0, और 5.1 कॉन्टेंट के लिए काम करता है. कोडिंग: 8000, 12000, 16000, 24000, और 48000 हर्ट्ज़ की सैंपलिंग रेट के साथ, मोनो और स्टीरियो कॉन्टेंट के लिए काम करता है.	Ogg (.ogg) MPEG-4 (.mp4, .m4a, सिर्फ़ डिकोड करने के लिए) Matroska (.mkv) Webm (.webm)

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

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

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

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

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

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

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

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

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

[C-0-1] JPEG
[C-0-2] GIF
[C-0-3] PNG
[C-0-4] BMP
[C-0-5] WebP
[C-0-6] रॉ

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

[C-1-1] यह ज़रूरी है कि यह HEIF (HEIC) इमेज को डिकोड कर सके.

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

[C-2-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 (.heif), HEIC (.heic)

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

[C-1-1] CodecCapabilities की मदद से, YUV420 8:8:8 फ़्लेक्सिबल कलर फ़ॉर्मैट (COLOR_FormatYUV420Flexible) के साथ काम करना चाहिए.
[SR-1] इनपुट के लिए, Surface mode में 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-1] हमारा सुझाव है कि वीडियो एन्कोडर और डिकोडर, कम से कम एक हार्डवेयर ऑप्टिमाइज़्ड प्लैनर या सेमी-प्लानर YUV420 8:8:8 कलर फ़ॉर्मैट (YV12, NV12, NV21 या वेंडर के ऑप्टिमाइज़ किए गए फ़ॉर्मैट) के साथ काम करें.
[C-1-5] ज़्यादा बिट-डेप्थ फ़ॉर्मैट (हर चैनल के लिए 9 से ज़्यादा बिट) के साथ काम करने वाले वीडियो डिकोडर को, 8-बिट वाले मिलते-जुलते फ़ॉर्मैट को आउटपुट करने की सुविधा देनी चाहिए. ऐसा तब करना होगा, जब ऐप्लिकेशन से अनुरोध किया जाए. यह android.media.MediaCodecInfo के ज़रिए YUV420 8:8:8 कलर फ़ॉर्मैट के साथ काम करने की सुविधा के तौर पर दिखना चाहिए.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

खास तौर पर:

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

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

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

	एसडी (कम क्वालिटी)	एसडी (अच्छी क्वालिटी)	एचडी 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 पिक्सल (एचईवीसी, VP9)

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

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

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

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

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

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

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

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

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

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

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

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

अगर डिवाइस पर एचडीआर कोडिंग की सुविधा उपलब्ध है, तो:

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

5.2.1. H.263

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

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

5.2.2. H.264

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

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

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

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

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

5.2.3. VP8

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

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

अगर डिवाइस में लागू किए गए मीडिया एपीआई के ज़रिए, 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. VP9

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

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

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

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

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

5.2.5. H.265

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

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

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

5.3.1. MPEG-2

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

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

5.3.2. H.263

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

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

5.3.3. MPEG-4

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

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

5.3.4. H.264

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

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

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

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

	एसडी (कम क्वालिटी)	एसडी (अच्छी क्वालिटी)	एचडी 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] डिवाइस पर, 720, 1080, और यूएचडी प्रोफ़ाइलों को डिकोड करने के लिए, H.265 या VP9 में से कम से कम एक को इस्तेमाल किया जाना चाहिए.

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

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

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

5.3.6. VP8

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

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

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

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

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

5.3.7. VP9

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

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

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

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

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

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

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

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

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

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

5.3.8. Dolby Vision

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

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

5.3.9. AV1

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

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

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

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

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

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

[C-1-1] ऐप्लिकेशन में, रॉ ऑडियो कॉन्टेंट को कैप्चर करने की सुविधा होनी चाहिए. साथ ही, यह सुविधा इनके साथ काम करती हो:
- फ़ॉर्मैट: लीनियर पीसीएम, 16-बिट
- सैंपलिंग रेट: 8000, 11025, 16000, 44100, 48000 हर्ट्ज़
- चैनल: मोनो
इसकी मदद से, रॉ ऑडियो कॉन्टेंट को कैप्चर करने की अनुमति होनी चाहिए. यह कॉन्टेंट इन विशेषताओं वाला होना चाहिए:
- फ़ॉर्मैट: लीनियर PCM, 16-बिट, और 24-बिट
- सैंपलिंग रेट: 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 हर्ट्ज़
- चैनल: डिवाइस पर मौजूद माइक्रोफ़ोन की संख्या के बराबर चैनल
[C-1-2] अप-सैंपलिंग के बिना, ऊपर दी गई सैंपल दरों पर रिकॉर्ड करना ज़रूरी है.
[C-1-3] ऊपर दी गई सैंपल रेट, डाउन-सैंपलिंग की मदद से कैप्चर किए जाने पर, इसमें सही ऐंटी-ऐलिऐसिंग फ़िल्टर ज़रूर शामिल होना चाहिए.
रॉ ऑडियो कॉन्टेंट को AM रेडियो और डीवीडी क्वालिटी में कैप्चर करने की अनुमति होनी चाहिए. इसका मतलब है कि इन सुविधाओं का होना ज़रूरी है:
- फ़ॉर्मैट: लीनियर पीसीएम, 16-बिट
- सैंपलिंग रेट: 22050, 48000 हर्ट्ज़
- चैनल: स्टीरियो
[C-1-4] MicrophoneInfo एपीआई का पालन करना ज़रूरी है. साथ ही, डिवाइस पर उपलब्ध माइक्रोफ़ोन की जानकारी सही तरीके से भरनी होगी, ताकि AudioManager.getMicrophones() एपीआई के ज़रिए तीसरे पक्ष के ऐप्लिकेशन उन्हें ऐक्सेस कर सकें. साथ ही, AudioRecord.getActiveMicrophones() और MediaRecorder.getActiveMicrophones() एपीआई के ज़रिए, तीसरे पक्ष के ऐप्लिकेशन उन माइक्रोफ़ोन को ऐक्सेस कर सकें जो फ़िलहाल चालू हैं. अगर डिवाइस में AM रेडियो और डीवीडी क्वालिटी में रॉ ऑडियो कॉन्टेंट कैप्चर करने की सुविधा है, तो:
[C-2-1] 16000:22050 या 44100:48000 से ज़्यादा रेशियो पर, अप-सैंपलिंग के बिना रिकॉर्ड करना ज़रूरी है.
[C-2-2] अप-सैंपलिंग या डाउन-सैंपलिंग के लिए, सही ऐंटी-ऐलिऐसिंग फ़िल्टर शामिल करना ज़रूरी है.

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

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

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

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

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

5.4.3. वीडियो चलाने की जगह बदलने के लिए कैप्चर करना

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[C-1-1] ऐप्लिकेशन में रॉ ऑडियो कॉन्टेंट को चलाने की अनुमति होनी चाहिए. साथ ही, यह कॉन्टेंट इनके मुताबिक होना चाहिए:
- सोर्स फ़ॉर्मैट: लीनियर PCM, 16-बिट, 8-बिट, फ़्लोट
- चैनल: मोनो, स्टीरियो, और ज़्यादा से ज़्यादा आठ चैनलों वाले मान्य मल्टीचैनल कॉन्फ़िगरेशन
- सैंपलिंग रेट (हर्ट्ज़ में):
  - ऊपर दिए गए चैनल कॉन्फ़िगरेशन में, 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000
  - मोनो और स्टीरियो में 96,000

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

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

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

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

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

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

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

5.5.4. ऑडियो ऑफ़लोड करना

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

[C-SR-1] हमारा सुझाव है कि जब AudioTrack gapless API और MediaPlayer के मीडिया कंटेनर से, गैपलेस ऑडियो कॉन्टेंट चलाने के लिए कहा जाए, तो उसे ट्रिम करें.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[C-SR-12] हमारा सुझाव है कि पांच मेज़रमेंट में, लगातार राउंड-ट्रिप के लिए औसत इंतज़ार का समय 50 मिलीसेकंड या उससे कम हो. साथ ही, कम से कम एक काम करने वाले पाथ पर, औसत एब्सोल्यूट डेविएशन 10 मिलीसेकंड से कम हो.

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

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

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

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

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

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

सेगमेंट फ़ॉर्मैट

रेफ़रंस

ज़रूरी कोडेक के साथ काम करना

MPEG-2 ट्रांसपोर्ट स्ट्रीम

ISO 13818

वीडियो कोडेक:

H264 AVC
MPEG-4 SP
MPEG-2

H264 AVC, MPEG2-4 SP,
और MPEG-2 के बारे में जानकारी के लिए, सेक्शन 5.1.8 देखें.

ऑडियो कोडेक:

AAC और इसके वैरिएंट के बारे में जानकारी के लिए, सेक्शन 5.1.3 देखें.

ADTS फ़्रेमिंग और ID3 टैग के साथ AAC

ISO 13818-7

AAC और इसके वैरिएंट के बारे में जानकारी के लिए, सेक्शन 5.1.1 देखें

WebVTT

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

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

5.8. Secure Media

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

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

अगर डिवाइस पर Display.FLAG_SECURE और वाई-फ़ाई डिसप्ले प्रोटोकॉल काम करता है, तो:

[C-2-1] Miracast जैसे वायरलेस प्रोटोकॉल से कनेक्ट किए गए डिसप्ले के लिए, लिंक को एन्क्रिप्ट करने के लिए, एचडीसीपी 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
- ब्लूटूथ LE पर MIDI, मुख्य भूमिका में काम कर रहा है, सेक्शन 7.4.3
[C-1-2] ऐप्लिकेशन के बीच एमआईडीआई सॉफ़्टवेयर ट्रांसपोर्ट (वर्चुअल एमआईडीआई डिवाइस) के साथ काम करना चाहिए
[C-1-3] इसमें libamidi.so (नेटिव MIDI सपोर्ट) शामिल होना चाहिए
यूएसबी की मदद से कनेक्ट किए गए सहायक डिवाइस मोड में, एमआईडीआई की सुविधा काम करनी चाहिए, सेक्शन 7.7

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

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

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

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

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

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

[C-SR-4] हमारा सुझाव है कि android.content.pm.PackageManager क्लास की मदद से, android.hardware.audio.pro सुविधा के लिए सहायता पाने का अनुरोध करें.

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

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

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

[C-3-1] यूएसबी ऑडियो क्लास को लागू करना ज़रूरी है.
[C-3-2] यूएसबी ऑडियो क्लास का इस्तेमाल करने वाले यूएसबी होस्ट मोड पोर्ट पर, लगातार पांच बार मापने पर, ऑडियो के लिए राउंड-ट्रिप लेटेंसी का औसत 25 मिलीसेकंड या उससे कम होना चाहिए. साथ ही, औसत का एब्सोल्यूट डिविएशन पांच मिलीसेकंड से कम होना चाहिए. (इसे यूएसबी-3.5 मि॰मी॰ अडैप्टर और ऑडियो लूपबैक डोंगल का इस्तेमाल करके मेज़र किया जा सकता है. इसके अलावा, इनपुट को आउटपुट से जोड़ने वाली पैच केबल के साथ यूएसबी ऑडियो इंटरफ़ेस का इस्तेमाल करके भी मेज़र किया जा सकता है).
[C-SR-6] हमारा सुझाव है कि इनका इस्तेमाल, USB ऑडियो डिवाइसों के साथ किया जाए. इन डिवाइसों में, हर डायरेक्शन में ज़्यादा से ज़्यादा आठ चैनल, 96 किलोहर्ट्ज़ सैंपल रेट, और 24-बिट या 32-बिट डेप्थ के साथ एक साथ I/O की सुविधा होनी चाहिए.
[C-SR-7] हमारा सुझाव है कि आप एमएमएपी पाथ पर AAudio नेटिव ऑडियो एपीआई का इस्तेमाल करके, ज़रूरी शर्तों के इस ग्रुप को पूरा करें.

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

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

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

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

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

[C-1-1] android.media.AudioManager प्रॉपर्टी PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED के ज़रिए, सहायता की जानकारी देना ज़रूरी है.
[C-1-2] माइक्रोफ़ोन की परफ़ॉर्मेंस, मध्य फ़्रीक्वेंसी रेंज में, ऐम्प्ल्यट्यूड-बनाम-फ़्रीक्वेंसी के हिसाब से लगभग फ़्लैट होनी चाहिए. खास तौर पर, बिना प्रोसेस किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन के लिए, 100 Hz से 7,000 Hz तक ±10 dB होना चाहिए.
[C-1-3] कम फ़्रीक्वेंसी वाली रेंज में, ऐम्प्ल्यट्यूड लेवल दिखाना ज़रूरी है: खास तौर पर, बिना प्रोसेस किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन के लिए, मध्य फ़्रीक्वेंसी रेंज की तुलना में 5 z से 100 Hz तक ±20 dB.
[C-1-4] यह ज़रूरी है कि अम्प्ल्यट्यूड लेवल, हाई फ़्रीक्वेंसी रेंज में हो: खास तौर पर, बिना प्रोसेस किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन के लिए, मीडियम फ़्रीक्वेंसी रेंज की तुलना में, 7,000 हर्ट्ज़ से 22 केएचज़ तक ±30 डीबी.
[C-1-5] ऑडियो इनपुट की संवेदनशीलता को इस तरह से सेट करना ज़रूरी है कि 94 dB साउंड प्रेशर लेवल (एसपीएल) पर चलाया गया 1000 Hz साइनसोइडल टोन सोर्स, 16 बिट-सैंपल के लिए 520 आरएमएस (या फ़्लोटिंग पॉइंट/डबल सटीक सैंपल के लिए -36 dB फ़ुल स्केल) का रिस्पॉन्स दे. ऐसा हर उस माइक्रोफ़ोन के लिए करना ज़रूरी है जिसका इस्तेमाल बिना प्रोसेस किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए किया जाता है.
[C-1-6] बिना प्रोसेस किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन का सिग्नल-टू-नॉइज़ रेशियो (एसएनआर) 60 dB या उससे ज़्यादा होना चाहिए. (जबकि एसएनआर को 94 dB SPL और सेल्फ़ नॉइज़ के बराबर एसपीएल, A-वज़्ड के बीच के अंतर के तौर पर मेज़र किया जाता है).
[C-1-7] प्रोसेस न किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन में, 90 dB SPL इनपुट लेवल पर 1 kHz के लिए, कुल हार्मोनिक डिस्टॉर्शन (THD) 1% से कम होना चाहिए.
[C-1-8] लेवल को सही रेंज में लाने के लिए, पाथ में लेवल मल्टीप्लायर के अलावा कोई अन्य सिग्नल प्रोसेसिंग (जैसे, ऑटोमैटिक गेन कंट्रोल, हाई पास फ़िल्टर या गूंज खत्म करने की सुविधा) नहीं होनी चाहिए. दूसरे शब्दों में:
- [C-1-9] अगर किसी वजह से, आर्किटेक्चर में कोई सिग्नल प्रोसेसिंग मौजूद है, तो उसे बंद करना ज़रूरी है. साथ ही, सिग्नल पाथ में शून्य देरी या अतिरिक्त इंतज़ार का समय जोड़ना चाहिए.
- [C-1-10] लेवल मल्टीप्लायर को पाथ में शामिल करने की अनुमति है. हालांकि, यह सिग्नल पाथ में देरी या लैटेंसी नहीं ला सकता.

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

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

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

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

6.1. डेवलपर टूल

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

[C-0-1] यह ज़रूरी है कि यह Android SDK में दिए गए Android डेवलपर टूल के साथ काम करे.
Android डीबग ब्रिज (adb)
- [C-0-2] यह ज़रूरी है कि यह Android SDK टूल और AOSP में दिए गए शेल कमांड के साथ काम करे. इनका इस्तेमाल ऐप्लिकेशन डेवलपर कर सकते हैं. इनमें dumpsys cmd stats भी शामिल है
- [C-0-11] यह ज़रूरी है कि शेल कमांड cmd testharness काम करे. डिवाइस पर पहले से मौजूद Android वर्शन को, बिना किसी डेटा ब्लॉक के नए वर्शन पर अपग्रेड करने पर, C-0-11 से छूट मिल सकती है.
- [C-0-3] डिवाइस के सिस्टम इवेंट (batterystats , diskstats, fingerprint, graphicsstats, netstats, notification, procstats) के फ़ॉर्मैट या कॉन्टेंट में बदलाव नहीं किया जाना चाहिए. ये इवेंट, dumpsys कमांड की मदद से लॉग किए जाते हैं.
- [C-0-10] इन इवेंट को रिकॉर्ड करना ज़रूरी है. साथ ही, इन्हें cmd stats शेल कमांड और StatsManager सिस्टम एपीआई क्लास के लिए ऐक्सेस और उपलब्ध कराना ज़रूरी है.
  - ActivityForegroundStateChanged
  - AnomalyDetected
  - AppBreadcrumbReported
  - AppCrashOccurred
  - AppStartOccurred
  - BatteryLevelChanged
  - BatterySaverModeStateChanged
  - BleScanResultReceived
  - BleScanStateChanged
  - ChargingStateChanged
  - DeviceIdleModeStateChanged
  - ForegroundServiceStateChanged
  - GpsScanStateChanged
  - JobStateChanged
  - PluggedStateChanged
  - ScheduledJobStateChanged
  - ScreenStateChanged
  - SyncStateChanged
  - SystemElapsedRealtime
  - UidProcessStateChanged
  - WakelockStateChanged
  - WakeupAlarmOccurred
  - WifiLockStateChanged
  - WifiMulticastLockStateChanged
  - WifiScanStateChanged
- [C-0-4] डिवाइस पर adb डेमन, डिफ़ॉल्ट रूप से बंद होना चाहिए. साथ ही, Android Debug Bridge को चालू करने के लिए, उपयोगकर्ता के पास कोई ऐसा तरीका होना चाहिए जिसका इस्तेमाल किया जा सके.
- [C-0-5] यह पक्का करें कि यह सुरक्षित adb के साथ काम करता हो. Android में सुरक्षितADB की सुविधा शामिल है. Secure adb, पुष्टि किए गए होस्ट पर adb को चालू करता है.
- [C-0-6] होस्ट मशीन से adb को कनेक्ट करने की सुविधा देनी ज़रूरी है. खास तौर से:
अगर यूएसबी पोर्ट के बिना डिवाइसों को लागू करने की सुविधा, सहायक डिवाइस मोड के साथ काम करती है, तो:
- [C-3-1] लोकल-एरिया नेटवर्क (जैसे, ईथरनेट या वाई-फ़ाई) के ज़रिए adb को लागू करना ज़रूरी है.
- [C-3-2] Windows 7, 8, और 10 के लिए ड्राइवर उपलब्ध कराना ज़रूरी है, ताकि डेवलपर adb प्रोटोकॉल का इस्तेमाल करके डिवाइस से कनेक्ट कर सकें.
अगर डिवाइस में वाई-फ़ाई के ज़रिए होस्ट मशीन से adb कनेक्शन बनाने की सुविधा काम करती है, तो:
- [C-4-1] AdbManager#isAdbWifiSupported() का तरीका, true को दिखाना चाहिए.
अगर डिवाइस में वाई-फ़ाई के ज़रिए होस्ट मशीन से adb कनेक्शन बनाने की सुविधा है और उसमें कम से कम एक कैमरा है, तो:
- [C-5-1] AdbManager#isAdbWifiQrSupported() का तरीका, true को दिखाना चाहिए.
Dalvik डीबग मॉनिटर सेवा (ddms)
- [C-0-7] Android SDK टूल में बताई गई सभी ddms सुविधाओं के साथ काम करना चाहिए. ddms, adb का इस्तेमाल करता है. इसलिए, ddms के लिए सहायता डिफ़ॉल्ट रूप से बंद होनी चाहिए. हालांकि, जब भी उपयोगकर्ता ने ऊपर बताए गए तरीके से Android Debug Bridge चालू किया हो, तब ddms के लिए सहायता चालू होनी चाहिए.
Monkey
- [C-0-8] इसमें Monkey फ़्रेमवर्क शामिल होना चाहिए और इसे ऐप्लिकेशन के इस्तेमाल के लिए उपलब्ध कराना चाहिए.
SysTrace
- [C-0-9] Android SDK में बताए गए तरीके से, systrace टूल के साथ काम करना चाहिए. Systrace की सुविधा डिफ़ॉल्ट रूप से बंद होनी चाहिए. साथ ही, Systrace को चालू करने के लिए, उपयोगकर्ता के पास कोई ऐसा तरीका होना चाहिए जिसका इस्तेमाल किया जा सके.
Perfetto
- [C-SR-1] हमारा सुझाव है कि शेल उपयोगकर्ता को /system/bin/perfetto बाइनरी उपलब्ध कराएं, जिसका cmdline, perfetto दस्तावेज़ के मुताबिक हो.
- [C-SR-2] हमारा सुझाव है कि आप perfetto दस्तावेज़ में बताए गए स्कीमा के मुताबिक, protobuf कॉन्फ़िगरेशन को इनपुट के तौर पर स्वीकार करने के लिए, perfetto बाइनरी का इस्तेमाल करें.
- [C-SR-3] हमारा सुझाव है कि आप perfetto दस्तावेज़ में बताए गए स्कीमा के मुताबिक, protobuf ट्रैक को आउटपुट के तौर पर लिखें.
- [C-SR-4] हमारा सुझाव है कि आप perfetto दस्तावेज़ में बताए गए डेटा सोर्स के साथ-साथ, कम से कम perfetto बाइनरी भी उपलब्ध कराएं.
Low Memory Killer
- [C-0-10] जब किसी ऐप्लिकेशन को कम मेमोरी किलर की वजह से बंद किया जाता है, तो LMK_KILL_OCCURRED_FIELD_NUMBER ऐटम को statsd लॉग में लिखना ज़रूरी है.
टेस्ट हार्नेस मोड अगर डिवाइस पर, शेल कमांड cmd testharness और cmd testharness enable काम करते हैं, तो:
- [C-2-1] ActivityManager.isRunningInUserTestHarness() के लिए true दिखाना ज़रूरी है
- [C-2-2] टेस्ट हार्नेस मोड के दस्तावेज़ में बताए गए तरीके के मुताबिक, टेस्ट हार्नेस मोड को लागू करना ज़रूरी है.

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

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

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

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

डिवाइस में लागू किए गए 'डेवलपर के विकल्प', एक जैसा अनुभव देने चाहिए. इसके लिए, ये ज़रूरी हैं:

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

7. हार्डवेयर के साथ काम करना

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

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

अगर 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) तरीकों से, हार्डवेयर कॉन्फ़िगरेशन की सटीक जानकारी लगातार रिपोर्ट की जानी चाहिए.

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

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 को UI_MODE_TYPE_WATCH के अलावा किसी और वैल्यू पर सेट किया गया है और Configuration.screenLayout के लिए small साइज़ की जानकारी दी गई है उनके लिए, डिवाइस का डाइमेंशन कम से कम 426 dp x 320 dp होना चाहिए.
- जिन डिवाइसों के लिए Configuration.screenLayout का साइज़ normal बताया गया है उनके लिए, कम से कम 480 डीपी x 320 डीपी का साइज़ ज़रूरी है.
- Configuration.screenLayout के लिए large साइज़ की जानकारी देने वाले डिवाइसों का स्क्रीन साइज़, कम से कम 640 dp x 480 dp होना चाहिए.
- Configuration.screenLayout के लिए xlarge साइज़ की जानकारी देने वाले डिवाइसों का डाइमेंशन, कम से कम 960 dp x 720 dp होना चाहिए.
[C-0-2] Android SDK के दस्तावेज़ में बताए गए तरीके के मुताबिक, AndroidManifest.xml में <supports-screens> एट्रिब्यूट की मदद से, ऐप्लिकेशन के लिए बताई गई स्क्रीन साइज़ के साथ सही तरीके से काम करना चाहिए.
इसमें Android के साथ काम करने वाले ऐसे डिसप्ले हो सकते हैं जिनके कोने गोल हों.

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

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

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

[C-2-1] Window Manager Jetpack लाइब्रेरी का इस्तेमाल करने के लिए, extensions API का सबसे नया वर्शन या sidecar API का स्टैबल वर्शन लागू करना ज़रूरी है.

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

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

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

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-3] Configuration.uiMode को UI_MODE_TYPE_WATCH के तौर पर सेट करने वाले डिवाइसों के लिए, आसपेक्ट रेशियो की वैल्यू 1.0 (1:1) पर सेट होनी चाहिए.

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

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

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

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

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

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

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

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

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

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

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

7.1.4.1 OpenGL ES

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

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

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

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

OpenGL ES dEQP टेस्ट को कई टेस्ट सूचियों में बांटा गया है. इनमें से हर सूची में, टेस्ट की तारीख/वर्शन नंबर शामिल होता है. ये external/deqp/android/cts/main/glesXX-master-YYYY-MM-DD.txt पर Android सोर्स ट्री में मौजूद हैं. अगर कोई डिवाइस, खुद से बताए गए लेवल पर OpenGL ES के साथ काम करता है, तो इसका मतलब है कि वह इस लेवल और उससे पहले के सभी टेस्ट की सूचियों में dEQP टेस्ट पास कर सकता है.

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

[C-2-1] ऐप्लिकेशन में लागू किए गए किसी भी अन्य OpenGL ES एक्सटेंशन की जानकारी, OpenGL ES मैनेज किए जा रहे एपीआई और नेटिव एपीआई के ज़रिए दी जानी चाहिए. इसके अलावा, उन एक्सटेंशन स्ट्रिंग की जानकारी नहीं दी जानी चाहिए जिन पर ऐप्लिकेशन काम नहीं करता.
[C-2-2] यह EGL_KHR_image, EGL_KHR_image_base, EGL_ANDROID_image_native_buffer, EGL_ANDROID_get_native_client_buffer, EGL_KHR_wait_sync, EGL_KHR_get_all_proc_addresses, EGL_ANDROID_presentation_time, EGL_KHR_swap_buffers_with_damage, EGL_ANDROID_recordable, और EGL_ANDROID_GLES_layers एक्सटेंशन के साथ काम करना चाहिए.
[C-2-3] android.software.opengles.deqp.level सुविधा फ़्लैग की मदद से काम करने वाले OpenGL ES dEQP टेस्ट के ज़्यादा से ज़्यादा वर्शन की रिपोर्ट करना ज़रूरी है.
[C-2-4] android.software.opengles.deqp.level सुविधा फ़्लैग में बताए गए मुताबिक, कम से कम 132383489 वर्शन (1 मार्च, 2020 से) के साथ काम करना चाहिए.
[C-2-5] यह ज़रूरी है कि ऐप्लिकेशन, 132383489 वर्शन और android.software.opengles.deqp.level सुविधा फ़्लैग में बताए गए वर्शन के बीच, टेस्ट की सूचियों में मौजूद सभी OpenGL ES dEQP टेस्ट पास करे. ऐसा, काम करने वाले हर OpenGL ES वर्शन के लिए करना होगा.
[C-SR-2] हमारा सुझाव है कि आप EGL_KHR_partial_update और OES_EGL_image_external एक्सटेंशन का इस्तेमाल करें.
getString() तरीके से, उन सभी टेक्सचर को सही तरीके से रिपोर्ट करना चाहिए जिनका इस्तेमाल वे कर सकते हैं. आम तौर पर, ये टेक्सचर वेंडर के हिसाब से होते हैं.

अगर डिवाइस में OpenGL ES 3.0, 3.1 या 3.2 का इस्तेमाल किया जा रहा है, तो:

[C-3-1] libGLESv2.so लाइब्रेरी में मौजूद OpenGL ES 2.0 फ़ंक्शन सिंबल के साथ-साथ, इन वर्शन के लिए भी संबंधित फ़ंक्शन सिंबल एक्सपोर्ट करने होंगे.
[C-SR-3] OES_EGL_image_external_essl3 एक्सटेंशन के साथ काम करने का सुझाव दिया जाता है.

अगर डिवाइस पर OpenGL ES 3.2 वर्शन काम करता है, तो:

[C-4-1] यह ज़रूरी है कि ऐप्लिकेशन, OpenGL ES Android एक्सटेंशन पैक के सभी वर्शन के साथ काम करे.

अगर डिवाइस पर OpenGL ES Android एक्सटेंशन पैक के सभी वर्शन काम करते हैं, तो:

[C-5-1] android.hardware.opengles.aep फ़ीचर फ़्लैग की मदद से, सहायता की पहचान करना ज़रूरी है.

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

[C-6-1] यह EGL_ANDROID_front_buffer_auto_refresh एक्सटेंशन के साथ भी काम करना चाहिए.

7.1.4.2 Vulkan

Android में Vulkan के साथ काम करने की सुविधा शामिल है. यह कम ओवरहेड वाला क्रॉस-प्लैटफ़ॉर्म एपीआई है, जो बेहतर परफ़ॉर्मेंस वाले 3D ग्राफ़िक के लिए इस्तेमाल किया जाता है.

अगर डिवाइस पर OpenGL ES 3.1 काम करता है, तो:

[C-SR-1] हमारा सुझाव है कि आप Vulkan 1.1 के लिए सहायता शामिल करें.

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

इसमें Vulkan 1.1 के लिए सहायता शामिल होनी चाहिए.

Vulkan dEQP टेस्ट को कई टेस्ट की सूचियों में बांटा गया है. इनमें से हर सूची में, टेस्ट की तारीख/वर्शन शामिल होता है. ये external/deqp/android/cts/main/vk-master-YYYY-MM-DD.txt पर Android सोर्स ट्री में मौजूद हैं. अगर किसी डिवाइस पर, खुद से बताए गए लेवल पर Vulkan काम करता है, तो इसका मतलब है कि वह इस लेवल और उससे पहले के सभी टेस्ट की सूचियों में dEQP टेस्ट पास कर सकता है.

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

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

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

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

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

[C-3-1] SYNC_FD एक्सटर्नल सिग्नल और हैंडल टाइप के साथ-साथ VK_ANDROID_external_memory_android_hardware_buffer एक्सटेंशन के लिए, सहायता उपलब्ध कराना ज़रूरी है.

7.1.4.3 RenderScript

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

7.1.4.4 2D ग्राफ़िक एक्सेलरेशन

Android में एक ऐसा तरीका शामिल है जिससे ऐप्लिकेशन यह एलान कर सकते हैं कि उन्हें ऐप्लिकेशन, गतिविधि, विंडो या व्यू लेवल पर, 2D ग्राफ़िक के लिए हार्डवेयर ऐक्सेलरेशन की सुविधा चालू करनी है. इसके लिए, उन्हें मेनिफ़ेस्ट टैग android:hardwareAccelerated का इस्तेमाल करना होगा या सीधे तौर पर एपीआई कॉल करने होंगे.

डिवाइस पर लागू करने के तरीके:

[C-0-1] हार्डवेयर से तेज़ी लाने की सुविधा को डिफ़ॉल्ट रूप से चालू करना ज़रूरी है. साथ ही, अगर डेवलपर ने android:hardwareAccelerated="false” को सेट करके या सीधे Android View API की मदद से हार्डवेयर से तेज़ी लाने की सुविधा को बंद करने का अनुरोध किया है, तो उसे बंद करना ज़रूरी है.
[C-0-2] हार्डवेयर से तेज़ी लाने की सुविधा के लिए, Android SDK टूल के दस्तावेज़ में बताए गए तरीके के मुताबिक काम करना चाहिए.

Android में TextureView ऑब्जेक्ट शामिल होता है. इसकी मदद से, डेवलपर सीधे तौर पर हार्डवेयर से तेज़ किए गए OpenGL ES टेक्स्चर को, यूज़र इंटरफ़ेस (यूआई) के लेआउट में रेंडरिंग टारगेट के तौर पर इंटिग्रेट कर सकते हैं.

डिवाइस पर लागू करने के तरीके:

[C-0-3] यह ज़रूरी है कि यह TextureView API के साथ काम करे. साथ ही, यह Android के अपस्ट्रीम वर्शन के साथ एक जैसा व्यवहार करे.

7.1.4.5 वाइड-गैमेट डिसप्ले

अगर डिवाइस में Configuration.isScreenWideColorGamut() के ज़रिए वाइड-गैमेट डिसप्ले के साथ काम करने का दावा किया जाता है, तो:

[C-1-1] डिसप्ले का कलर कैलिब्रेट किया गया होना चाहिए.
[C-1-2] डिसप्ले का गैमट, CIE 1931 xyY स्पेस में sRGB कलर गैमट को पूरी तरह कवर करता हो.
[C-1-3] डिसप्ले का गैमट, CIE 1931 xyY स्पेस में कम से कम 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 एक्सटेंशन के लिए सहायता का विज्ञापन दिखाना ज़रूरी है.
[C-SR-1] GL_EXT_sRGB के साथ काम करने के लिए, हमारा सुझाव है कि आप ज़रूर इस सुविधा का इस्तेमाल करें.

इसके उलट, अगर डिवाइस पर लागू किए गए एलिमेंट, वाइड-गैमेट डिसप्ले के साथ काम नहीं करते, तो:

[C-2-1] CIE 1931 xyY स्पेस में sRGB का 100% या उससे ज़्यादा हिस्सा कवर करना चाहिए. हालांकि, स्क्रीन का कलर गैमट तय नहीं है.

7.1.5. लेगसी ऐप्लिकेशन के साथ काम करने वाला मोड

Android में “कंपैटिबिलिटी मोड” की सुविधा होती है. इस मोड में फ़्रेमवर्क, स्क्रीन के 'सामान्य' साइज़ (320dp चौड़ाई) के बराबर के मोड में काम करता है. ऐसा इसलिए किया जाता है, ताकि लेगसी ऐप्लिकेशन को फ़ायदा मिल सके. ये ऐप्लिकेशन, Android के पुराने वर्शन के लिए डिज़ाइन नहीं किए गए हैं. ये वर्शन, स्क्रीन के साइज़ के हिसाब से ऐप्लिकेशन के काम करने की सुविधा से पहले के हैं.

7.1.6. स्क्रीन टेक्नोलॉजी

Android प्लैटफ़ॉर्म में ऐसे एपीआई शामिल होते हैं जिनकी मदद से ऐप्लिकेशन, Android के साथ काम करने वाले डिसप्ले पर बेहतर ग्राफिक्स रेंडर कर सकते हैं. डिवाइसों में, Android SDK टूल में बताए गए सभी एपीआई काम करने चाहिए. ऐसा तब तक ज़रूरी है, जब तक इस दस्तावेज़ में खास तौर पर अनुमति न दी गई हो.

किसी डिवाइस पर लागू किए गए Android के साथ काम करने वाले सभी डिसप्ले:

[C-0-1] यह 16-बिट कलर ग्राफ़िक रेंडर करने में सक्षम होना चाहिए.
यह 24-बिट कलर ग्राफ़िक्स वाले डिसप्ले के साथ काम करना चाहिए.
[C-0-2] ऐनिमेशन रेंडर करने की सुविधा होनी चाहिए.
[C-0-3] पिक्सल आसपेक्ट रेशियो (PAR) 0.9 से 1.15 के बीच होना चाहिए. इसका मतलब है कि पिक्सल का आसपेक्ट रेशियो, स्क्वेयर (1.0) के आस-पास होना चाहिए. इसमें 10 से 15% तक की गड़बड़ी हो सकती है.

7.1.7. दूसरे डिसप्ले

Android में, Android के साथ काम करने वाले सेकंडरी डिसप्ले के लिए सहायता शामिल है. इससे, मीडिया शेयर करने की सुविधाएं चालू की जा सकती हैं. साथ ही, बाहरी डिसप्ले को ऐक्सेस करने के लिए, डेवलपर एपीआई का इस्तेमाल किया जा सकता है.

अगर डिवाइस में वायर, वायरलेस या डिवाइस में पहले से मौजूद अतिरिक्त डिसप्ले कनेक्शन के ज़रिए, बाहरी डिसप्ले को कनेक्ट करने की सुविधा है, तो:

[C-1-1] Android SDK टूल के दस्तावेज़ में बताए गए तरीके के मुताबिक, DisplayManager सिस्टम सेवा और एपीआई को लागू करना ज़रूरी है.

7.2. इनपुट डिवाइस

डिवाइस पर लागू करने के तरीके:

[C-0-1] यूज़र इंटरफ़ेस (यूआई) एलिमेंट के बीच नेविगेट करने के लिए, इसमें टचस्क्रीन या नॉन-टच नेविगेशन जैसा कोई इनपुट सिस्टम होना चाहिए.

7.2.1. कीबोर्ड

अगर डिवाइस में तीसरे पक्ष के इनपुट के तरीके के संपादक (आईएमई) वाले ऐप्लिकेशन के लिए सहायता शामिल है, तो:

[C-1-1] android.software.input_methods के फ़ीचर फ़्लैग का एलान करना ज़रूरी है.
[C-1-2] इसे पूरी तरह से लागू करना ज़रूरी है Input Management Framework
[C-1-3] डिवाइस में पहले से इंस्टॉल किया गया सॉफ़्टवेयर कीबोर्ड होना चाहिए.

डिवाइस पर लागू करने के तरीके:

[C-0-1] डिवाइस में ऐसा हार्डवेयर कीबोर्ड शामिल नहीं होना चाहिए जो android.content.res.Configuration.keyboard में बताए गए किसी एक फ़ॉर्मैट (QWERTY या 12-key) से मेल न खाता हो.
इसमें अन्य सॉफ़्ट कीबोर्ड लागू करने की सुविधा शामिल होनी चाहिए.
इसमें हार्डवेयर कीबोर्ड शामिल हो सकता है.

7.2.2. बिना छुए नेविगेट करने की सुविधा

Android में, टच किए बिना नेविगेट करने के लिए, डी-पैड, ट्रैकबॉल, और व्हील की सुविधा शामिल है.

डिवाइस पर लागू करने के तरीके:

[C-0-1] android.content.res.Configuration.navigation के लिए सही वैल्यू की जानकारी देनी ज़रूरी है.

अगर डिवाइस में बिना छुए नेविगेट करने की सुविधा नहीं है, तो:

[C-1-1] टेक्स्ट चुनने और उसमें बदलाव करने के लिए, यूज़र इंटरफ़ेस का ऐसा विकल्प देना ज़रूरी है जो इनपुट मैनेजमेंट इंजन के साथ काम करता हो. Android के ओपन सोर्स को लागू करने के लिए, एक चुनने का तरीका शामिल किया गया है. यह तरीका उन डिवाइसों के साथ इस्तेमाल करने के लिए सही है जिनमें नॉन-टच नेविगेशन इनपुट नहीं होते.

7.2.3. मार्गदर्शक कुंजियां

होम, हाल ही में इस्तेमाल किए गए, और वापस जाएं फ़ंक्शन, आम तौर पर किसी खास बटन या टच स्क्रीन के किसी खास हिस्से के इंटरैक्शन से मिलते हैं. ये फ़ंक्शन, Android नेविगेशन पैराडाइम और इसलिए, डिवाइस पर लागू करने के लिए ज़रूरी हैं:

[C-0-1] आपको उपयोगकर्ताओं को, ऐसे इंस्टॉल किए गए ऐप्लिकेशन को लॉन्च करने के लिए एक सुविधा देनी होगी जिनमें टेलिविज़न डिवाइस पर लागू करने के लिए, <intent-filter> को ACTION=MAIN और CATEGORY=LAUNCHER या CATEGORY=LEANBACK_LAUNCHER के साथ सेट किया गया हो. होम फ़ंक्शन, इस उपयोगकर्ता के लिए उपलब्ध सुविधा के तौर पर काम करना चाहिए.
हाल ही में इस्तेमाल किए गए आइटम और 'वापस जाएं' फ़ंक्शन के लिए बटन होने चाहिए.

अगर होम, हाल ही में इस्तेमाल किए गए आइटम या वापस जाएं फ़ंक्शन उपलब्ध कराए जाते हैं, तो:

[C-1-1] अगर इनमें से किसी भी विकल्प को ऐक्सेस किया जा सकता है, तो उसे एक ही कार्रवाई (जैसे, टैप, दो बार क्लिक करना या जेस्चर) से ऐक्सेस किया जा सकता है.
[C-1-2] यह साफ़ तौर पर बताया जाना चाहिए कि कौनसी एक कार्रवाई से हर फ़ंक्शन ट्रिगर होगा. बटन पर दिखने वाला आइकॉन, स्क्रीन के नेविगेशन बार पर सॉफ़्टवेयर आइकॉन दिखाना या डिवाइस के साथ मिलने वाले सेटअप के दौरान, उपयोगकर्ता को सिलसिलेवार निर्देशों के साथ डेमो फ़्लो दिखाना, इस तरह के संकेत के उदाहरण हैं.

डिवाइस पर लागू करने के तरीके:

[C-SR-1] हमारा सुझाव है कि आप मेन्यू फ़ंक्शन के लिए इनपुट मैकेनिज्म न दें. ऐसा इसलिए, क्योंकि Android 4.0 के बाद से, ऐक्शन बार के पक्ष में इसे बंद कर दिया गया है.

अगर डिवाइस में मेन्यू फ़ंक्शन उपलब्ध है, तो:

[C-2-1] जब भी ऐक्शन ओवरफ़्लो मेन्यू पॉप-अप खाली न हो और ऐक्शन बार दिख रहा हो, तब ऐक्शन ओवरफ़्लो बटन दिखना चाहिए.
[C-2-2] ऐक्शन बार में ओवरफ़्लो बटन चुनकर दिखाए गए ऐक्शन ओवरफ़्लो पॉप-अप की पोज़िशन में बदलाव नहीं किया जाना चाहिए. हालांकि, मेन्यू फ़ंक्शन चुनकर दिखाए जाने पर, ऐक्शन ओवरफ़्लो पॉप-अप को स्क्रीन पर बदली गई पोज़िशन पर रेंडर किया जा सकता है.

अगर डिवाइस में मेन्यू फ़ंक्शन उपलब्ध नहीं है, तो पुराने वर्शन के साथ काम करने के लिए, ये काम किए जाते हैं:

[C-3-1] targetSdkVersion के 10 से कम होने पर, ऐप्लिकेशन के लिए मेन्यू फ़ंक्शन को उपलब्ध कराना ज़रूरी है. इसके लिए, फ़िज़िकल बटन, सॉफ़्टवेयर बटन या जेस्चर का इस्तेमाल किया जा सकता है. इस मेन्यू फ़ंक्शन को तब तक ऐक्सेस किया जा सकता है, जब तक इसे अन्य नेविगेशन फ़ंक्शन के साथ छिपाया नहीं जाता.

अगर डिवाइस में Assist फ़ंक्शन उपलब्ध है, तो:

[C-4-1] अन्य नेविगेशन बटन ऐक्सेस किए जा सकने पर, Assist फ़ंक्शन को सिर्फ़ एक ऐक्शन (जैसे, टैप, डबल-क्लिक या जेस्चर) से ऐक्सेस किया जा सकता है.
[C-SR-2] हमारा सुझाव है कि होम बटन को दबाकर रखें, क्योंकि यह इंटरैक्शन के लिए तय किया गया है.

अगर डिवाइस में नेविगेशन बटन दिखाने के लिए, स्क्रीन के किसी अलग हिस्से का इस्तेमाल किया जाता है, तो:

[C-5-1] नेविगेशन बटन, स्क्रीन के उस हिस्से पर होने चाहिए जो ऐप्लिकेशन के लिए उपलब्ध नहीं है. साथ ही, ये बटन ऐप्लिकेशन के लिए उपलब्ध स्क्रीन के हिस्से को छिपाने या उसमें रुकावट पैदा करने वाले नहीं होने चाहिए.
[C-5-2] डिसप्ले का एक हिस्सा, उन ऐप्लिकेशन के लिए उपलब्ध कराना ज़रूरी है जो सेक्शन 7.1.1 में बताई गई ज़रूरी शर्तों को पूरा करते हैं.
[C-5-3] ऐप्लिकेशन को View.setSystemUiVisibility() एपीआई के तरीके से सेट किए गए फ़्लैग का पालन करना चाहिए, ताकि स्क्रीन के इस खास हिस्से (जिसे नेविगेशन बार भी कहा जाता है) को SDK टूल में बताए गए तरीके से सही तरीके से छिपाया जा सके.

[C-6-1] WindowInsets#getMandatorySystemGestureInsets() इसका इस्तेमाल सिर्फ़ होम जेस्चर की पहचान करने वाले एरिया की रिपोर्टिंग के लिए किया जाना चाहिए.
[C-6-2] View#setSystemGestureExclusionRects() के ज़रिए फ़ोरग्राउंड ऐप्लिकेशन से मिले एक्सक्लूज़न रेक्ट में शुरू होने वाले, लेकिन WindowInsets#getMandatorySystemGestureInsets() के बाहर के जेस्चर को नेविगेशन फ़ंक्शन के लिए इंटरसेप्ट नहीं किया जाना चाहिए. ऐसा तब तक नहीं किया जाना चाहिए, जब तक एक्सक्लूज़न रेक्ट को एक्सक्लूज़न की तय सीमा के अंदर रखा जाता है. इस सीमा के बारे में View#setSystemGestureExclusionRects() के दस्तावेज़ में बताया गया है.
[C-6-3] अगर फ़ोरग्राउंड ऐप्लिकेशन को पहले कोई MotionEvent.ACTION_DOWN इवेंट भेजा गया था, तो सिस्टम जेस्चर के लिए टच को इंटरसेप्ट करने के बाद, फ़ोरग्राउंड ऐप्लिकेशन को MotionEvent.ACTION_CANCEL इवेंट भेजना ज़रूरी है.
[C-6-4] उपयोगकर्ता को स्क्रीन पर बटन के आधार पर नेविगेट करने की सुविधा देनी चाहिए. उदाहरण के लिए, सेटिंग में.
होम फ़ंक्शन को स्क्रीन के मौजूदा ओरिएंटेशन के सबसे नीचे से ऊपर की ओर स्वाइप करके उपलब्ध कराया जाना चाहिए.
हाल ही में इस्तेमाल किए गए आइटम देखने की सुविधा, होम जेस्चर वाले हिस्से से ऊपर की ओर स्वाइप करके और रिलीज़ करने से पहले दबाकर चालू की जानी चाहिए.
WindowInsets#getMandatorySystemGestureInsets() में शुरू होने वाले जेस्चर पर, View#setSystemGestureExclusionRects() के ज़रिए फ़ोरग्राउंड ऐप्लिकेशन से मिले एक्सक्लूज़न रीक्ट का असर नहीं पड़ना चाहिए.

अगर स्क्रीन के मौजूदा ओरिएंटेशन के बाएं और दाएं किनारों पर, कहीं भी नेविगेशन फ़ंक्शन दिया गया है, तो:

[C-7-1] नेविगेशन फ़ंक्शन 'वापस जाएं' होना चाहिए. साथ ही, इसे स्क्रीन के मौजूदा ओरिएंटेशन के बाएं और दाएं, दोनों किनारों से स्वाइप करके उपलब्ध कराया जाना चाहिए.
[C-7-2] अगर बाईं या दाईं ओर, स्वाइप किए जा सकने वाले कस्टम सिस्टम पैनल दिए गए हैं, तो उन्हें स्क्रीन के सबसे ऊपर 1/3 हिस्से में रखा जाना चाहिए. साथ ही, यह साफ़ तौर पर और लगातार दिखना चाहिए कि पैनल को खींचकर लाने पर, ऊपर बताए गए पैनल खुलेंगे, न कि 'वापस जाएं' बटन. उपयोगकर्ता, सिस्टम पैनल को इस तरह कॉन्फ़िगर कर सकता है कि वह स्क्रीन के सबसे ऊपरी एक तिहाई हिस्से के नीचे दिखे. हालांकि, सिस्टम पैनल के लिए एक तिहाई से ज़्यादा हिस्से का इस्तेमाल नहीं किया जाना चाहिए.
[C-7-3] जब फ़ोरग्राउंड ऐप्लिकेशन में, View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT या WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE फ़्लैग सेट हों, तो किनारों से स्वाइप करने पर, AOSP में लागू किए गए तरीके के मुताबिक काम करना चाहिए. इस बारे में SDK में जानकारी दी गई है.
[C-7-4] जब फ़ोरग्राउंड ऐप्लिकेशन में, View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT या WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE फ़्लैग सेट हों, तो स्वाइप किए जा सकने वाले कस्टम सिस्टम पैनल तब तक छिपे होने चाहिए, जब तक उपयोगकर्ता AOSP में लागू किए गए सिस्टम बार (जिसे नेविगेशन और स्टेटस बार भी कहा जाता है) को नहीं दिखाता या उनका कलर ज़्यादा नहीं करता.

7.2.4. टचस्क्रीन इनपुट

Android में कई तरह के पॉइंटर इनपुट सिस्टम के साथ काम करने की सुविधा शामिल है. जैसे, टचस्क्रीन, टच पैड, और फ़ेक टच इनपुट डिवाइस. टचस्क्रीन पर काम करने वाले डिवाइसों पर लागू होने वाले एक्सटेंशन, डिसप्ले से जुड़े होते हैं. इससे उपयोगकर्ता को ऐसा लगता है कि वह स्क्रीन पर मौजूद आइटम को सीधे तौर पर मैनेज कर रहा है. उपयोगकर्ता सीधे तौर पर स्क्रीन को छू रहा है, इसलिए सिस्टम को ऑब्जेक्ट में बदलाव किए जा रहे हैं, यह बताने के लिए किसी और सुविधा की ज़रूरत नहीं है.

डिवाइस पर लागू करने के तरीके:

इसमें किसी तरह का पॉइंटर इनपुट सिस्टम होना चाहिए (माउस जैसा या टच).
यह पूरी तरह से स्वतंत्र रूप से ट्रैक किए गए पॉइंटर के साथ काम करना चाहिए.

अगर डिवाइस में, Android के साथ काम करने वाले मुख्य डिसप्ले पर टचस्क्रीन (सिंगल-टच या बेहतर) शामिल है, तो:

[C-1-1] Configuration.touchscreen एपीआई फ़ील्ड के लिए, TOUCHSCREEN_FINGER की जानकारी देना ज़रूरी है.
[C-1-2] android.hardware.touchscreen और android.hardware.faketouch सुविधा फ़्लैग की रिपोर्ट करना ज़रूरी है.

अगर डिवाइस में ऐसी टचस्क्रीन है जो Android के साथ काम करने वाले मुख्य डिसप्ले पर, एक से ज़्यादा टच को ट्रैक कर सकती है, तो:

[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 से शुरू होने वाले किसी भी सुविधा फ़्लैग की शिकायत नहीं की जानी चाहिए.
[C-3-2] सिर्फ़ android.hardware.faketouch की रिपोर्ट देनी होगी.
[C-3-3] Configuration.touchscreen एपीआई फ़ील्ड के लिए, TOUCHSCREEN_NOTOUCH की जानकारी देना ज़रूरी है.

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] ऐप्लिकेशन में पॉइंटर डाउन की सुविधा होनी चाहिए. इसके बाद, उपयोगकर्ताओं को स्क्रीन पर किसी ऑब्जेक्ट को तेज़ी से एक जगह से दूसरी जगह ले जाने की अनुमति होनी चाहिए. इसके बाद, स्क्रीन पर पॉइंटर अप की सुविधा होनी चाहिए, ताकि उपयोगकर्ता स्क्रीन पर किसी ऑब्जेक्ट को फ़्लिंग कर सकें.

अगर डिवाइस पर android.hardware.faketouch.multitouch.distinct का इस्तेमाल करने की सुविधा उपलब्ध है, तो:

[C-2-1] android.hardware.faketouch के लिए सहायता उपलब्ध कराने का एलान करना ज़रूरी है.
[C-2-2] यह ज़रूरी है कि यह दो या उससे ज़्यादा इंडिपेंडेंट पॉइंटर इनपुट की अलग-अलग ट्रैकिंग की सुविधा देता हो.

अगर डिवाइस पर android.hardware.faketouch.multitouch.jazzhand का इस्तेमाल करने की सुविधा उपलब्ध है, तो:

[C-3-1] android.hardware.faketouch के लिए सहायता देने का एलान करना ज़रूरी है.
[C-3-2] यह ज़रूरी है कि डिवाइस, पांच (हाथ की उंगलियों को ट्रैक करना) या उससे ज़्यादा पॉइंटर इनपुट को अलग-अलग ट्रैक कर सके.

7.2.6. गेम कंट्रोलर के लिए सहायता

7.2.6.1. बटन मैपिंग

डिवाइस पर लागू करने के तरीके:

[C-1-1] यह ज़रूरी है कि HID इवेंट को, नीचे दी गई टेबल में दी गई InputEvent कॉन्स्टेंट से मैप किया जा सके. Android के अपस्ट्रीम वर्शन में, यह ज़रूरी शर्त पूरी की जाती है.

अगर डिवाइस में कोई कंट्रोलर जोड़ा गया है या बॉक्स में एक अलग कंट्रोलर दिया गया है, तो नीचे दी गई टेबल में दिए गए सभी इवेंट को इनपुट करने के लिए:

[C-2-1] फ़ीचर फ़्लैग android.hardware.gamepad का एलान करना ज़रूरी है

बटन	एचआईडी का इस्तेमाल²	Android बटन
A¹	0x09 0x0001	KEYCODE_BUTTON_A (96)
B¹	0x09 0x0002	KEYCODE_BUTTON_B (97)
X¹	0x09 0x0004	KEYCODE_BUTTON_X (99)
Y¹	0x09 0x0005	KEYCODE_BUTTON_Y (100)
डी-पैड अप¹ डी-पैड डाउन¹	0x01 0x0039³	AXIS_HAT_Y⁴
डी-पैड बाईं ओर1 डी-पैड दाईं ओर¹	0x01 0x0039³	AXIS_HAT_X⁴
लेफ़्ट शोल्डर बटन¹	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
राइट शोल्डर बटन¹	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
लेफ़्ट स्टिक क्लिक¹	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
राइट स्टिक क्लिक¹	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
वापस जाएं¹	0x0c 0x0224	KEYCODE_BACK (4)

1 KeyEvent

2 ऊपर बताए गए एचआईडी के इस्तेमाल की जानकारी, गेमपैड सीए (0x01 0x0005) में दी जानी चाहिए.

3 इस इस्तेमाल के लिए, लॉजिकल तौर पर कम से कम 0 और ज़्यादा से ज़्यादा 7, फ़िज़िकल तौर पर कम से कम 0 और ज़्यादा से ज़्यादा 315, डिग्री में यूनिट, और रिपोर्ट का साइज़ 4 होना चाहिए. लॉजिकल वैल्यू को वर्टिकल ऐक्सिस से, घड़ी की सुई के घूमने की दिशा में घुमाने के तौर पर तय किया गया है. उदाहरण के लिए, लॉजिकल वैल्यू 0 का मतलब है कि कोई घुमाव नहीं है और अप बटन दबाया गया है. वहीं, लॉजिकल वैल्यू 1 का मतलब है कि 45 डिग्री का घुमाव है और अप और लेफ़्ट बटन, दोनों दबाए गए हैं.

4 MotionEvent

ऐनलॉग कंट्रोल¹	एचआईडी का इस्तेमाल	Android बटन
लेफ़्ट ट्रिगर	0x02 0x00C5	AXIS_LTRIGGER
राइट ट्रिगर	0x02 0x00C4	AXIS_RTRIGGER
लेफ़्ट जॉयस्टिक	0x01 0x0030 0x01 0x0031	AXIS_X AXIS_Y
राइट जॉयस्टिक	0x01 0x0032 0x01 0x0035	AXIS_Z AXIS_RZ

एक MotionEvent

7.2.7. रिमोट कंट्रोल

डिवाइस के हिसाब से ज़रूरी शर्तों के बारे में जानने के लिए, सेक्शन 2.3.1 देखें.

7.3. सेंसर

अगर डिवाइस में किसी खास तरह का सेंसर शामिल है, जिसके लिए तीसरे पक्ष के डेवलपर के पास एपीआई है, तो डिवाइस में उस एपीआई को लागू करना ज़रूरी है. इसके बारे में, Android SDK टूल के दस्तावेज़ और सेंसर के बारे में Android के ओपन सोर्स दस्तावेज़ में बताया गया है.

डिवाइस पर लागू करने के तरीके:

[C-0-1] android.content.pm.PackageManager क्लास के हिसाब से, सेंसर की मौजूदगी या अनुपस्थिति की सटीक जानकारी देनी चाहिए.
[C-0-2] SensorManager.getSensorList() और मिलते-जुलते तरीकों की मदद से, काम करने वाले सेंसर की सटीक सूची दिखानी ज़रूरी है.
[C-0-3] अन्य सभी सेंसर एपीआई के लिए, सही तरीके से काम करना चाहिए. उदाहरण के लिए, जब ऐप्लिकेशन, सुनने वालों को रजिस्टर करने की कोशिश करते हैं, तो true या false को ज़रूरत के हिसाब से दिखाना. साथ ही, जब संबंधित सेंसर मौजूद न हों, तो सेंसर सुनने वालों को कॉल न करना वगैरह.

अगर डिवाइस में किसी खास तरह का सेंसर शामिल है, जिसके लिए तीसरे पक्ष के डेवलपर के पास एपीआई है, तो:

[C-1-1] Android SDK टूल के दस्तावेज़ में बताए गए हर सेंसर टाइप के लिए, सभी सेंसर मेज़रमेंट की रिपोर्ट भेजना ज़रूरी है. इसके लिए, यूनिट के इंटरनैशनल सिस्टम (मेट्रिक) की सही वैल्यू का इस्तेमाल करना ज़रूरी है.
[C-1-2] सेंसर डेटा को 100 मिलीसेकंड + 2 * sample_time के ज़्यादा से ज़्यादा इंतज़ार के साथ रिपोर्ट करना ज़रूरी है. ऐसा तब करना होगा, जब ऐप्लिकेशन प्रोसेसर चालू हो और सेंसर स्ट्रीम के लिए 0 मिलीसेकंड का अनुरोध किया गया हो. इस समय में, फ़िल्टर करने में लगने वाला समय शामिल नहीं है.
[C-1-3] सेंसर के चालू होने के 400 मिलीसेकंड + 2 * sample_time के अंदर, सेंसर के पहले सैंपल की जानकारी देनी ज़रूरी है. इस सैंपल के लिए, सटीक होने की वैल्यू 0 हो सकती है.
[C-1-4] Android SDK दस्तावेज़ में बताए गए किसी भी एपीआई को कंटिन्यूअस सेंसर के तौर पर इस्तेमाल करने के लिए, डिवाइस में लागू किए गए एपीआई को समय-समय पर डेटा सैंपल उपलब्ध कराने होंगे. इन सैंपल में, जितटर 3% से कम होना चाहिए. जितटर को, लगातार होने वाले इवेंट के बीच रिपोर्ट किए गए टाइमस्टैंप की वैल्यू के अंतर के स्टैंडर्ड डेविएशन के तौर पर परिभाषित किया जाता है.
[C-1-5] यह पक्का करना ज़रूरी है कि सेंसर इवेंट स्ट्रीम, डिवाइस के सीपीयू को निलंबित होने या निलंबित होने के बाद फिर से चालू होने से न रोके.
[C-1-6] Android SDK टूल के दस्तावेज़ में बताए गए मुताबिक, इवेंट के समय की जानकारी, नैनोसेकंड में देनी ज़रूरी है. इससे, इवेंट के होने का समय पता चलता है. साथ ही, यह जानकारी SystemClock.elapsedRealtimeNano() घड़ी के साथ सिंक होती है.
[C-SR-1] हमारा सुझाव है कि टाइमस्टैंप सिंक करने में होने वाली गड़बड़ी 100 मिलीसेकंड से कम होनी चाहिए. साथ ही, टाइमस्टैंप सिंक करने में होने वाली गड़बड़ी 1 मिलीसेकंड से कम होनी चाहिए.
जब कई सेंसर चालू होते हैं, तो बिजली की खपत, अलग-अलग सेंसर की बिजली की खपत के कुल योग से ज़्यादा नहीं होनी चाहिए.

ऊपर दी गई सूची पूरी नहीं है. सेंसर के लिए, Android SDK टूल और Android के ओपन सोर्स दस्तावेज़ों के व्यवहार को आधिकारिक माना जाएगा.

[C-1-6] सभी सेंसर के लिए, शून्य से अलग रिज़ॉल्यूशन सेट करना ज़रूरी है. साथ ही, Sensor.getResolution() एपीआई के तरीके से वैल्यू की रिपोर्ट देना ज़रूरी है.

कुछ सेंसर टाइप कंपोजिट होते हैं. इसका मतलब है कि उन्हें एक या एक से ज़्यादा अन्य सेंसर से मिले डेटा से लिया जा सकता है. उदाहरण के लिए, ओरिएंटेशन सेंसर और ऐक्सेलरेशन सेंसर.

डिवाइस पर लागू करने के तरीके:

सेंसर टाइप में बताए गए ज़रूरी फ़िज़िकल सेंसर शामिल होने पर, इन सेंसर टाइप को लागू करना चाहिए.

अगर डिवाइस में कॉम्पोज़िट सेंसर शामिल है, तो:

[C-2-1] कंपोज़िट सेंसर के लिए, Android के ओपन सोर्स दस्तावेज़ में बताए गए तरीके के मुताबिक सेंसर को लागू करना ज़रूरी है.

अगर डिवाइस में लागू किए गए किसी सेंसर टाइप में, तीसरे पक्ष के डेवलपर के लिए एपीआई है और सेंसर सिर्फ़ एक वैल्यू रिपोर्ट करता है, तो डिवाइस में लागू किए गए:

[C-3-1] सेंसर के लिए रिज़ॉल्यूशन को 1 पर सेट करना ज़रूरी है. साथ ही, Sensor.getResolution() एपीआई के तरीके से वैल्यू की रिपोर्ट करनी होगी.

अगर डिवाइस में लागू किए गए किसी सेंसर टाइप में SensorAdditionalInfo#TYPE_VEC3_CALIBRATION का इस्तेमाल किया जा सकता है और वह सेंसर तीसरे पक्ष के डेवलपर के लिए उपलब्ध है, तो वे:

[C-4-1] दिए गए डेटा में, फ़ैक्ट्री से तय किए गए कैलिब्रेशन पैरामीटर शामिल नहीं होने चाहिए.

अगर डिवाइस में तीन ऐक्सिस वाला एक्सलरोमीटर, तीन ऐक्सिस वाला जाइरोस्कोप सेंसर या मैग्नेटोमीटर सेंसर का इस्तेमाल किया गया है, तो:

[C-SR-2] हमारा सुझाव है कि आप यह पक्का करें कि एक्सलरोमीटर, जाइरोस्कोप, और मैग्नेटोमीटर की रिलेटिव पोज़िशन एक जैसी हो. इससे, अगर डिवाइस को बदला जा सकता है (जैसे, फ़ोल्ड किया जा सकता है), तो सेंसर के अक्ष, डिवाइस के बदलाव की सभी संभावित स्थितियों में सेंसर कोऑर्डिनेट सिस्टम के साथ अलाइन और एक जैसे बने रहेंगे.

7.3.1. एक्सलरोमीटर

डिवाइस पर लागू करने के तरीके:

[C-SR-1] हमारा सुझाव है कि आप 3-ऐक्सिस एक्सलरोमीटर शामिल करें.

अगर डिवाइस में 3-ऐक्सिस एक्सलरोमीटर शामिल है, तो:

[C-1-1] यह ज़रूरी है कि यह कम से कम 50 हर्ट्ज़ तक की फ़्रीक्वेंसी वाले इवेंट की रिपोर्ट कर सके.
[C-1-2] TYPE_ACCELEROMETER सेंसर को लागू करना और उसकी रिपोर्ट देना ज़रूरी है.
[C-1-3] Android API में बताए गए Android सेंसर कोऑर्डिनेट सिस्टम के मुताबिक होना चाहिए.
[C-1-4] यह ज़रूरी है कि यह किसी भी अक्ष पर, गुरुत्वाकर्षण के चार गुना(4g) या उससे ज़्यादा तक के फ़्रीफ़ॉल को मेज़र कर सके.
[C-1-5] का रिज़ॉल्यूशन कम से कम 12-बिट होना चाहिए.
[C-1-6] का स्टैंडर्ड डेविएशन 0.05 मीटर/सेकंड^ से ज़्यादा नहीं होना चाहिए. यहां स्टैंडर्ड डेविएशन का हिसाब, हर अक्ष के आधार पर लगाया जाना चाहिए. इसके लिए, कम से कम तीन सेकंड के दौरान इकट्ठा किए गए सैंपल का इस्तेमाल करना चाहिए. सैंपल इकट्ठा करने के लिए, सबसे तेज़ सैंपलिंग रेट का इस्तेमाल किया जाना चाहिए.
[C-SR-2] TYPE_SIGNIFICANT_MOTION कंपोज़िट सेंसर को लागू करने के लिए, ज़रूर अपनाएं.
[C-SR-3] TYPE_ACCELEROMETER_UNCALIBRATED सेंसर को लागू करने और उसकी रिपोर्ट करने का ज़रूर सुझाव दिया जाता है. हमारा सुझाव है कि Android डिवाइसों को इस ज़रूरी शर्त को पूरा करना चाहिए, ताकि वे आने वाले समय में प्लैटफ़ॉर्म के उस रिलीज़ पर अपग्रेड कर सकें जहां यह ज़रूरी हो सकता है.
Android SDK टूल के दस्तावेज़ में बताए गए तरीके के मुताबिक, TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER कंपोजिट सेंसर लागू करने चाहिए.
कम से कम 200 हर्ट्ज़ तक के इवेंट रिपोर्ट करने चाहिए.
इसका रिज़ॉल्यूशन कम से कम 16-बिट होना चाहिए.
अगर लाइफ़ साइकल के दौरान प्रॉपर्टी में बदलाव होता है और उन्हें कैलिब्रेट किया जाता है, तो डिवाइस के रीबूट होने के बीच, कैलिब्रेशन पैरामीटर को बनाए रखना चाहिए.
तापमान के हिसाब से अडजस्ट होना चाहिए.

अगर डिवाइस में 3-ऐक्सिस ऐक्सीलरॉमीटर और TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER में से कोई एक कंपोजिट सेंसर लागू किया गया है, तो:

[C-2-1] इनकी कुल बिजली खपत हमेशा 4 एमडब्ल्यू से कम होनी चाहिए.
डिवाइस के डाइनैमिक या स्टैटिक होने पर, हर एक काफ़ी कम होना चाहिए. जैसे, 2 mW और 0.5 mW से कम.

अगर डिवाइस में 3-एक्सिस एक्सलरोमीटर और 3-एक्सिस जाइरोस्कोप सेंसर शामिल हैं, तो:

[C-3-1] TYPE_GRAVITY और TYPE_LINEAR_ACCELERATION के कॉम्पोज़िट सेंसर लागू करना ज़रूरी है.
[C-SR-4] हमारा सुझाव है कि आप TYPE_GAME_ROTATION_VECTOR कंपोज़िट सेंसर लागू करें.

अगर डिवाइस में 3-ऐक्सिस एक्सलरोमीटर, 3-ऐक्सिस जाइरोस्कोप सेंसर, और मैग्नेटोमीटर सेंसर शामिल हैं, तो:

[C-4-1] TYPE_ROTATION_VECTOR कंपोजिट सेंसर लागू करना ज़रूरी है.

7.3.2. मैग्नेटोमीटर

डिवाइस पर लागू करने के तरीके:

[C-SR-1] हमारा सुझाव है कि आप 3-ऐक्सिस मैग्नेटोमीटर (कम्पास) शामिल करें.

अगर डिवाइस में तीन ऐक्सिस वाला मैग्नेटोमीटर शामिल है, तो:

[C-1-1] TYPE_MAGNETIC_FIELD सेंसर को लागू करना ज़रूरी है.
[C-1-2] यह ज़रूरी है कि यह कम से कम 10 हर्ट्ज़ की फ़्रीक्वेंसी तक इवेंट रिपोर्ट कर सके और कम से कम 50 हर्ट्ज़ तक इवेंट रिपोर्ट करनी चाहिए.
[C-1-3] Android API में बताए गए Android सेंसर कोऑर्डिनेट सिस्टम के मुताबिक होना चाहिए.
[C-1-4] यह ज़रूरी है कि सैचुरेट होने से पहले, हर अक्ष पर -900 µT से +900 µT के बीच मेज़रमेंट किया जा सके.
[C-1-5] मैग्नेटोमीटर को डाइनैमिक (विद्युत प्रवाह से होने वाले) और स्टैटिक (मैग्नेट से होने वाले) मैग्नेटिक फ़ील्ड से दूर रखकर, हार्ड आयरन ऑफ़सेट की वैल्यू 700 µT से कम होनी चाहिए. साथ ही, यह वैल्यू 200 µT से कम होनी चाहिए.
[C-1-6] का रिज़ॉल्यूशन 0.6 µT के बराबर या उससे ज़्यादा होना चाहिए.
[C-1-7] यह ज़रूरी है कि डिवाइस, ऑनलाइन कैलिब्रेशन और हार्ड आयरन बियस के लिए कॉम्पेंसेशन की सुविधा देता हो. साथ ही, डिवाइस के रीबूट होने के बीच कॉम्पेंसेशन पैरामीटर को सेव रखता हो.
[C-1-8] डिवाइस में सॉफ़्ट आयरन कम्पेंसेशन की सुविधा होनी चाहिए. डिवाइस के इस्तेमाल के दौरान या उसके प्रोडक्शन के दौरान, कैलिब्रेशन किया जा सकता है.
[C-1-9] स्टैंडर्ड डेविएशन होना चाहिए. इसका हिसाब, हर अक्ष के आधार पर, कम से कम तीन सेकंड की अवधि में इकट्ठा किए गए सैंपल के हिसाब से लगाया जाता है. सैंपलिंग की सबसे तेज़ दर 1.5 µT से ज़्यादा नहीं होनी चाहिए. स्टैंडर्ड डेविएशन 0.5 µT से ज़्यादा नहीं होना चाहिए.
[C-1-10] TYPE_MAGNETIC_FIELD_UNCALIBRATED सेंसर को लागू करना ज़रूरी है.

अगर डिवाइस में 3-ऐक्सिस मैग्नेटोमीटर, एक्सलरोमीटर सेंसर, और 3-ऐक्सिस जाइरोस्कोप सेंसर शामिल हैं, तो:

[C-2-1] TYPE_ROTATION_VECTOR कंपोजिट सेंसर को लागू करना ज़रूरी है.

अगर डिवाइस में 3-ऐक्सिस मैग्नेटोमीटर और एक्सलरोमीटर शामिल हैं, तो:

TYPE_GEOMAGNETIC_ROTATION_VECTOR सेंसर लागू किया जा सकता है.

अगर डिवाइस में 3-ऐक्सिस मैग्नेटोमीटर, एक्सलरोमीटर, और TYPE_GEOMAGNETIC_ROTATION_VECTOR सेंसर शामिल हैं, तो:

[C-3-1] यह 10 mW से कम ऊर्जा का इस्तेमाल करता हो.
जब सेंसर को 10 हर्ट्ज़ पर बैच मोड के लिए रजिस्टर किया गया हो, तो यह 3 एमडब्ल्यू से कम ऊर्जा का इस्तेमाल करना चाहिए.

7.3.3. जीपीएस

डिवाइस पर लागू करने के तरीके:

[C-SR-1] हमारा सुझाव है कि आप जीपीएस/जीएनएसएस रिसीवर शामिल करें.

अगर डिवाइस में GPS/GNSS रिसीवर शामिल है और android.hardware.location.gps सुविधा फ़्लैग के ज़रिए ऐप्लिकेशन को इसकी सुविधा की जानकारी दी जाती है, तो:

[C-1-1] LocationManager#requestLocationUpdate के ज़रिए अनुरोध किए जाने पर, जगह की जानकारी के आउटपुट कम से कम 1 हर्ट्ज़ की दर से मिलने चाहिए.
[C-1-2] 0.5 एमबीपीएस या इससे तेज़ डेटा स्पीड वाले इंटरनेट कनेक्शन से कनेक्ट होने पर, खुले आसमान वाली जगहों पर (ज़्यादा सिग्नल, कम मल्टीपाथ, एचडीओपी < 2) 10 सेकंड (पहले फ़िक्स में लगने वाला कम समय) में जगह की जानकारी तय करनी चाहिए. आम तौर पर, इस ज़रूरी शर्त को पूरा करने के लिए, जीपीएस/जीएनएसएस के लॉक-ऑन समय को कम करने के लिए, असिस्टेड या अनुमानित जीपीएस/जीएनएसएस तकनीक का इस्तेमाल किया जाता है. असिस्टेंस डेटा में, रेफ़रंस टाइम, रेफ़रंस लोकेशन, और सैटलाइट एफ़ेमेरिस/क्लॉक शामिल होते हैं.
- [C-1-6] जगह की जानकारी का हिसाब लगाने के बाद, डिवाइस के लागू होने पर, जगह की जानकारी के अनुरोध फिर से शुरू होने पर, डिवाइस को खुले आसमान में, पांच सेकंड के अंदर अपनी जगह की जानकारी तय करनी चाहिए. यह जानकारी, जगह की जानकारी का पहला हिसाब लगाने के एक घंटे बाद तक तय की जानी चाहिए. भले ही, इसके बाद का अनुरोध, डेटा कनेक्शन के बिना और/या पावर साइकल के बाद किया गया हो.
खुले आसमान में जगह का पता लगाने के बाद, एक मीटर प्रति सेकंड स्क्वेयर से कम की रफ़्तार से चलने या एक जगह पर खड़े होने पर:
- [C-1-3] यह ज़रूरी है कि डिवाइस, कम से कम 95% समय तक, जगह की जानकारी 20 मीटर के अंदर और गति को 0.5 मीटर प्रति सेकंड के अंदर बता सके.
- [C-1-4] एक ही कॉन्स्टेलेशन के कम से कम आठ उपग्रहों को एक साथ ट्रैक और GnssStatus.Callback के ज़रिए रिपोर्ट करना ज़रूरी है.
- एक साथ कम से कम 24 सैटलाइट ट्रैक करने की सुविधा होनी चाहिए. ये सैटलाइट, कई कॉन्स्टेलेशन (जैसे, जीपीएस + कम से कम एक Glonass, Beidou, Galileo) से होने चाहिए.
[C-SR-2] हमारा सुझाव है कि आपातकालीन फ़ोन कॉल के दौरान, GNSS Location Provider API के ज़रिए सामान्य जीपीएस/जीएनएसएस जगह की जानकारी के आउटपुट डिलीवर करना जारी रखें.
[C-SR-3] हमारा सुझाव है कि ट्रैक किए गए सभी कॉन्स्टेलेशन (जैसा कि GnssStatus मैसेज में बताया गया है) से GNSS मेज़रमेंट की रिपोर्ट करें. हालांकि, SBAS को छोड़ दें.
[C-SR-4] हमारा सुझाव है कि आप एजीसी और जीएनएसएस से किए गए मेज़रमेंट की फ़्रीक्वेंसी की जानकारी दें.
[C-SR-5] हमारा सुझाव है कि हर जीपीएस/जीएनएसएस लोकेशन के हिस्से के तौर पर, सटीक जानकारी के सभी अनुमान (इनमें दिशा, स्पीड, और वर्टिकल शामिल हैं) की रिपोर्ट करें.
[C-SR-6] हमारा सुझाव है कि जीएनएसएस मेज़रमेंट मिलने के तुरंत बाद, उनकी शिकायत करें. भले ही, जीपीएस/जीएनएसएस से कैलकुलेट की गई जगह की जानकारी अब तक सबमिट न की गई हो.
[C-SR-7] हमारा सुझाव है कि जीएनएसएस स्यूडोरेंज और स्यूडोरेंज रेट की जानकारी दें. ये ऐसे डेटा होते हैं जो खुले आसमान में जगह की जानकारी तय करने के बाद, गतिहीन या 0.2 मीटर प्रति सेकंड स्क्वेयर से कम की गति से चलने पर, कम से कम 95% समय में जगह की जानकारी 20 मीटर के अंदर और गति 0.2 मीटर प्रति सेकंड के अंदर का हिसाब लगाने के लिए काफ़ी होते हैं.

7.3.4. जाइरोस्कोप

डिवाइस पर लागू करने के तरीके:

[C-SR-1] हमारा सुझाव है कि आप जाइरोस्कोप सेंसर शामिल करें.

अगर डिवाइस में 3-ऐक्सिस जाइरोस्कोप शामिल है, तो:

[C-1-1] यह ज़रूरी है कि यह कम से कम 50 हर्ट्ज़ तक की फ़्रीक्वेंसी वाले इवेंट की रिपोर्ट कर सके.
[C-1-2] TYPE_GYROSCOPE सेंसर को लागू करना ज़रूरी है.
[C-1-4] का रिज़ॉल्यूशन 12 बिट या उससे ज़्यादा होना चाहिए.
[C-1-5] तापमान के हिसाब से अडजस्ट होना चाहिए.
[C-1-6] इस्तेमाल के दौरान, इसे कैलिब्रेट और कंपेसेशन करना ज़रूरी है. साथ ही, डिवाइस के रीबूट होने के बीच कंपेसेशन पैरामीटर को बनाए रखना ज़रूरी है.
[C-1-7] हर हर्ट्ज़ के लिए, वैरिएंस 1e-7 rad^2 / s^2 से ज़्यादा नहीं होना चाहिए (हर हर्ट्ज़ के लिए वैरिएंस या rad^2 / s). वैरिएंस को सैंपलिंग रेट के हिसाब से बदलने की अनुमति है, लेकिन यह वैल्यू से ज़्यादा नहीं होना चाहिए. दूसरे शब्दों में, अगर 1 हर्ट्ज़ के सैंपलिंग रेट पर, घुमाव की दर का अंतर मापा जाता है, तो यह 1e-7 rad^2/s^2 से ज़्यादा नहीं होना चाहिए.
[C-SR-2] हमारा सुझाव है कि जब डिवाइस कमरे के तापमान पर स्थिर हो, तो कैलिब्रेशन में होने वाली गड़बड़ी 0.01 रेडियन/सेकंड से कम हो.
[C-SR-3] हमारा सुझाव है कि आप TYPE_GYROSCOPE_UNCALIBRATED सेंसर को लागू करें.
[C-SR-4] हमारा सुझाव है कि आपके पास 16-बिट या इससे ज़्यादा रिज़ॉल्यूशन वाला डिवाइस हो.
कम से कम 200 हर्ट्ज़ तक के इवेंट रिपोर्ट करने चाहिए.

अगर डिवाइस में 3-एक्सिस जाइरोस्कोप, एक्सलरोमीटर सेंसर, और मैग्नेटोमीटर सेंसर शामिल हैं, तो:

[C-2-1] TYPE_ROTATION_VECTOR कंपोजिट सेंसर को लागू करना ज़रूरी है.

अगर डिवाइस में 3-ऐक्सिस एक्सलरोमीटर और 3-ऐक्सिस जाइरोस्कोप सेंसर शामिल हैं, तो:

[C-3-1] TYPE_GRAVITY और TYPE_LINEAR_ACCELERATION कंपोजिट सेंसर लागू करना ज़रूरी है.
[C-SR-5] TYPE_GAME_ROTATION_VECTOR कॉम्पोज़िट सेंसर को लागू करने का ज़रूर सुझाव दिया जाता है.

7.3.5. बैरोमीटर

डिवाइस पर लागू करने के तरीके:

[C-SR-1] हमारा सुझाव है कि आप बैरोमीटर (आस-पास के वातावरण के दबाव का सेंसर) शामिल करें.

अगर डिवाइस में बैरोमीटर शामिल है, तो:

[C-1-1] TYPE_PRESSURE सेंसर को लागू करना और उसकी रिपोर्ट करना ज़रूरी है.
[C-1-2] यह ज़रूरी है कि डिवाइस 5 हर्ट्ज़ या उससे ज़्यादा फ़्रीक्वेंसी पर इवेंट डिलीवर कर सके.
[C-1-3] तापमान के हिसाब से अडजस्ट होना चाहिए.
[C-SR-2] हमारा सुझाव है कि आप 300hPa से 1100hPa की सीमा में, दबाव के मेज़रमेंट की जानकारी दें.
यह 1hPa तक सटीक होना चाहिए.
20hPa की रेंज में, रिलेटिव सटीक 0.12hPa होनी चाहिए (समुद्र तल पर ~200m के बदलाव में ~1m की सटीक जानकारी).

7.3.6. Thermometer

अगर डिवाइस में आस-पास के तापमान का पता लगाने वाला थर्मामीटर (तापमान सेंसर) शामिल है, तो:

[C-1-1] एंबियंट तापमान सेंसर के लिए SENSOR_TYPE_AMBIENT_TEMPERATURE को ज़रूर तय करना चाहिए. साथ ही, सेंसर को उस जगह के एंबियंट (कमरे/वाहन के केबिन) तापमान को सेल्सियस डिग्री में मेज़र करना चाहिए जहां उपयोगकर्ता डिवाइस से इंटरैक्ट कर रहा है.

अगर डिवाइस में थर्मामीटर सेंसर शामिल है, जो आस-पास के तापमान के अलावा किसी और तापमान को मापता है, जैसे कि सीपीयू का तापमान, तो:

[C-2-1] तापमान मापने वाले सेंसर के लिए, SENSOR_TYPE_AMBIENT_TEMPERATURE को तय नहीं किया जाना चाहिए.

अगर डिवाइस में त्वचा के तापमान को मॉनिटर करने के लिए सेंसर शामिल है, तो:

[C-SR-1] हमारा सुझाव है कि आप PowerManager.getThermalHeadroom एपीआई का इस्तेमाल करें.

7.3.7. फ़ोटोमीटर

डिवाइस में फ़ोटोमीटर (स्क्रीन की रोशनी को अपने-आप घटाने-बढ़ाने वाला सेंसर) शामिल हो सकता है.

7.3.8. निकटता सेंसर

डिवाइस में लागू करने के लिए, प्रॉक्सिमिटी सेंसर का इस्तेमाल किया जा सकता है.

अगर डिवाइस में प्रॉक्सिमिटी सेंसर शामिल है और वह सिर्फ़ “पास” या “दूर” के बाइनरी रीडिंग की जानकारी देता है, तो:

[C-1-1] किसी ऑब्जेक्ट की निकटता को उसी दिशा में मेज़र करना चाहिए जिस दिशा में स्क्रीन है. इसका मतलब है कि प्रॉक्सिमिटी सेंसर को स्क्रीन के आस-पास मौजूद ऑब्जेक्ट का पता लगाने के लिए ऑर्डर करना ज़रूरी है. इस तरह के सेंसर का मुख्य मकसद, उपयोगकर्ता के इस्तेमाल में मौजूद फ़ोन का पता लगाना होता है. अगर डिवाइस में किसी अन्य ओरिएंटेशन के साथ प्रोक्सिमिटी सेंसर शामिल है, तो उसे इस एपीआई के ज़रिए ऐक्सेस नहीं किया जा सकता.
[C-1-2] सटीक जानकारी देने के लिए, 1 बिट या उससे ज़्यादा की जानकारी होनी चाहिए.
[C-1-3] नियर रीडिंग के तौर पर 0 सेंटीमीटर और फ़ार रीडिंग के तौर पर 5 सेंटीमीटर का इस्तेमाल करना ज़रूरी है.
[C-1-4] ज़्यादा से ज़्यादा पांच रेंज और रिज़ॉल्यूशन की रिपोर्ट करनी चाहिए.

7.3.9. हाई फ़िडेलिटी सेंसर

अगर डिवाइस में, इस सेक्शन में बताए गए तौर पर बेहतर क्वालिटी वाले सेंसर शामिल हैं और उन्हें तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराया जाता है, तो:

[C-1-1] android.hardware.sensor.hifi_sensors फ़ीचर फ़्लैग के ज़रिए, सुविधा की पहचान करना ज़रूरी है.

अगर डिवाइस पर लागू किए गए एपीआई में android.hardware.sensor.hifi_sensors का एलान किया गया है, तो:

[C-2-1] इसमें TYPE_ACCELEROMETER सेंसर होना चाहिए, जो:
- मेज़रमेंट की रेंज कम से कम -8g से +8g के बीच होनी चाहिए. साथ ही, कम से कम -16g से +16g के बीच मेज़रमेंट रेंज रखने का सुझाव दिया जाता है.
- मेज़रमेंट का रिज़ॉल्यूशन कम से कम 2048 LSB/g होना चाहिए.
- मेज़रमेंट फ़्रीक्वेंसी कम से कम 12.5 हर्ट्ज़ या उससे कम होनी चाहिए.
- मेज़रमेंट फ़्रीक्वेंसी 400 हर्ट्ज़ या इससे ज़्यादा होनी चाहिए. साथ ही, SensorDirectChannel RATE_VERY_FAST के साथ काम करना चाहिए.
- मेज़रमेंट नॉइज़ 400 μg/√Hz से ज़्यादा नहीं होना चाहिए.
- इस सेंसर के लिए, कम से कम 3,000 सेंसर इवेंट को बफ़र करने की सुविधा के साथ, नॉन-वेक-अप फ़ॉर्म लागू करना ज़रूरी है.
- बैचिंग के दौरान, डिवाइस की बिजली की खपत 3 mW से ज़्यादा नहीं होनी चाहिए.
- [C-SR-1] हमारा सुझाव है कि 3dB मेज़रमेंट बैंडविड्थ, कम से कम 80% नक्विस्ट फ़्रीक्वेंसी हो. साथ ही, इ�