हमारा सुझाव है कि 27 मार्च, 2025 से AOSP को बनाने और उसमें योगदान देने के लिए, aosp-main के बजाय android-latest-release का इस्तेमाल करें. ज़्यादा जानकारी के लिए, AOSP में हुए बदलाव लेख पढ़ें.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2. हाथ में पकड़कर इस्तेमाल किए जाने वाले डिवाइसों के लिए ज़रूरी शर्तें

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

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

इसमें बैटरी जैसा पावर सोर्स होना चाहिए, ताकि इसे आसानी से एक जगह से दूसरी जगह ले जाया जा सके.
स्क्रीन का डाइगनल साइज़ 3.3 इंच से 8 इंच के बीच होना चाहिए. हालांकि, Android 11 से पहले के एपीआई लेवल पर लॉन्च किए गए डिवाइसों के लिए, यह साइज़ 2.5 इंच से 8 इंच के बीच होना चाहिए.

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

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

2.2.1. हार्डवेयर

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

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

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

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

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

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

अगर हैंडहेल्ड डिवाइस में सेट किए गए सिस्टम, 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 counter trace packet proto के मुताबिक वैल्यू रिपोर्ट करना ज़रूरी है.
[7.1.4.6/H-1-3] डिवाइस के GPU RenderStages के लिए, render stage trace packet proto के मुताबिक वैल्यू रिपोर्ट करना ज़रूरी है.
[7.1.4.6/H-1-4] जीपीयू फ़्रीक्वेंसी ट्रेसपॉइंट की जानकारी इस फ़ॉर्मैट में देनी होगी: power/gpu_frequency.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

फ़ंक्शन	मैपिंग	कॉन्टेक्स्ट	व्यवहार
A	एचआईडी यूसेज पेज: 0x0C एचआईडी यूसेज: 0x0CD कर्नल की: `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	HID usage page: 0x0C HID usage: 0x0EA Kernel key: `KEY_VOLUMEDOWN` Android key: `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] डिवाइस को Intent ACTION_HEADSET_PLUG ब्रॉडकास्ट करना होगा. साथ ही, "microphone" एक्स्ट्रा को 0 पर सेट करना होगा.

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

[7.8.2.2/H-3-1] डिवाइस को Intent ACTION_HEADSET_PLUG ब्रॉडकास्ट करना होगा. साथ ही, "microphone" एक्स्ट्रा को 1 पर सेट करना होगा.

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

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

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

[7.10/H-SR]* में, ईआरएम (एक्सेंट्रिक रोटेटिंग मास) हैप्टिक ऐक्चुएटर(वाइब्रेटर) का इस्तेमाल न करने का सुझाव दिया गया है.
[7.10/H]* को ऐक्चुएटर को उस जगह के पास रखना चाहिए जहां डिवाइस को आम तौर पर हाथों से पकड़ा या छुआ जाता है.
[7.10/H-SR]* 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-SR]* android.os.VibrationEffect में क्लियर हैप्टिक के लिए सभी सार्वजनिक कॉन्स्टेंट (जैसे, EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK, और EFFECT_DOUBLE_CLICK) और android.os.VibrationEffect.Composition में रिच हैप्टिक के लिए सभी सार्वजनिक कॉन्स्टेंट (जैसे, PRIMITIVE_CLICK और PRIMITIVE_TICK) लागू करने का सुझाव दिया जाता है.
[7.10/H-SR]* इन लिंक किए गए हैप्टिक कॉन्स्टेंट मैपिंग का इस्तेमाल करने का सुझाव दिया जाता है.
[7.10/H-SR]* createOneShot() और createWaveform() एपीआई के लिए, क्वालिटी असेसमेंट को फ़ॉलो करने का सुझाव दिया जाता है.
[7.10/H-SR]* android.os.Vibrator.hasAmplitudeControl() को चलाकर, वाइब्रेशन की तीव्रता को कम या ज़्यादा करने की सुविधाओं की पुष्टि करने का सुझाव दिया जाता है.

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

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

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

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

[7.10/H-SR]* यह सुझाव दिया जाता है कि X-ऐक्सिस एलआरए की रेज़ोनेंट फ़्रीक्वेंसी 200 हर्ट्ज़ से कम हो.

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

[7.10/H-SR]* हैप्टिक कॉन्स्टेंट के लिए, क्वालिटी असेसमेंट करने का सुझाव दिया जाता है.

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 प्रोफ़ाइल (AAC+)
[5.1/H-0-5] AAC ELD (बेहतर लो डिले एएसी)

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

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

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

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

2.2.3. सॉफ़्टवेयर

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

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

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

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

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

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

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

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

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

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

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

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

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

अगर नेविगेशन की सुविधा, स्क्रीन पर हाथ के जेस्चर (स्पर्श) पर आधारित कार्रवाई के तौर पर दी गई है, तो:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[6.1/H-0-1]* यह ज़रूरी है कि डिवाइस, शेल कमांड cmd testharness के साथ काम करता हो.

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

2.2.7 हैंडहेल्ड डिवाइस के लिए मीडिया परफ़ॉर्मेंस क्लास

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

2.2.7.1. मीडिया

अगर हैंडहेल्ड डिवाइस में सेट किए गए सिस्टम, android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS के लिए android.os.Build.VERSION_CODES.R वैल्यू दिखाते हैं, तो:

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

2.2.7.2. कैमरा

[7.5/H-1-1] डिवाइस में पीछे की ओर लगा मुख्य कैमरा होना ज़रूरी है. इसका रिज़ॉल्यूशन कम से कम 12 मेगापिक्सल होना चाहिए. साथ ही, यह 4K@30fps पर वीडियो रिकॉर्ड करने की सुविधा के साथ काम करता हो. प्राइमरी रियर-फ़ेसिंग कैमरा, सबसे कम कैमरा आईडी वाला रियर-फ़ेसिंग कैमरा होता है.
[7.5/H-1-2] डिवाइस में सामने की ओर एक प्राइमरी कैमरा होना चाहिए. इसका रिज़ॉल्यूशन कम से कम 4 मेगापिक्सल होना चाहिए. साथ ही, यह 1080 पिक्सल रिज़ॉल्यूशन और 30 एफ़पीएस पर वीडियो रिकॉर्ड करने की सुविधा के साथ काम करना चाहिए. प्राइमरी फ़्रंट कैमरा, सबसे कम कैमरा आईडी वाला फ़्रंट कैमरा होता है.
[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] दोनों प्राइमरी कैमरों के लिए, 1080 पिक्सल रिज़ॉल्यूशन पर JPEG फ़ोटो कैप्चर करने में लगने वाला समय 1,000 मि॰से॰ से कम होना चाहिए. यह समय, आईटीएस की रोशनी की स्थितियों (3,000K) में, CTS कैमरा परफ़ॉर्मेंस टेस्ट के तहत मापा जाता है.
[7.5/H-1-6] दोनों प्राइमरी कैमरों के लिए, Camera2 के चालू होने में लगने वाला समय (कैमरा खोलने से लेकर पहले प्रीव्यू फ़्रेम तक) 600 मि॰से॰ से कम होना चाहिए. यह समय, आईटीएस की रोशनी की स्थितियों (3000K) में, CTS की Camera PerformanceTest के तहत मापा जाता है.

2.2.7.3. हार्डवेयर

अगर हैंडहेल्ड डिवाइस में सेट किए गए सिस्टम, android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS के लिए android.os.Build.VERSION_CODES.R दिखाते हैं, तो:

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

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

[8.2/H-1-1] ज़रूरी है कि क्रम से लिखने की स्पीड कम से कम 100 एमबी/सेकंड हो.
[8.2/H-1-2] ज़रूरी है कि रैंडम राइट परफ़ॉर्मेंस कम से कम 10 एमबी/सेकंड हो.
[8.2/H-1-3] ज़रूरी है कि क्रम से पढ़ने की परफ़ॉर्मेंस कम से कम 200 एमबी/सेकंड हो.
[8.2/H-1-4] ज़रूरी है कि रैंडम रीड परफ़ॉर्मेंस कम से कम 25 एमबी/सेकंड हो.

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

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

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

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

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

2.3.1. हार्डवेयर

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[5.8/T-1-1] HDCP 2.2 के साथ काम करना ज़रूरी है.

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

[5.8/T-2-1] HDCP 1.4 के साथ काम करना ज़रूरी है

2.3.3. सॉफ़्टवेयर

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

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

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

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

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

[3.12/T-0-1] TV Input Framework के साथ काम करना ज़रूरी है.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 ट्रेस लिखना होगा. यह ट्रेस, परफ़ेक्टो के दस्तावेज़ में बताए गए स्कीमा के मुताबिक होना चाहिए.
- [6.1/T-0-4] यह ज़रूरी है कि perfetto बाइनरी के ज़रिए, कम से कम वे डेटा सोर्स उपलब्ध कराए जाएं जिनके बारे में परफ़ेक्टो के दस्तावेज़ में बताया गया है.

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

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

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

स्क्रीन की लंबाई 1.1 से 2.5 इंच के बीच होनी चाहिए.
उसे शरीर पर पहनने के लिए बनाया गया हो.

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

2.4.1. हार्डवेयर

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

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

अगर वॉच डिवाइसों में जीपीएस/जीएनएसएस रिसीवर शामिल है और वे 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] MUST support uiMode = UI_MODE_TYPE_WATCH.
[3.2.3.1/W-0-1] यह ज़रूरी है कि डिवाइस में एक या उससे ज़्यादा ऐप्लिकेशन या सेवा कॉम्पोनेंट प्रीलोड किए गए हों. साथ ही, उनमें इंटेंट हैंडलर मौजूद हो. ऐसा यहां दिए गए ऐप्लिकेशन इंटेंट के लिए, सार्वजनिक इंटेंट फ़िल्टर के सभी पैटर्न के लिए किया जाना चाहिए.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.5.1. हार्डवेयर

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

[7.1.1.1/A-0-1] डिवाइस की स्क्रीन का साइज़, कम से कम 6 इंच होना चाहिए.
[7.1.1.1/A-0-2] स्क्रीन का साइज़ कम से कम 750 डीपी x 480 डीपी होना चाहिए.
[7.2.3/A-0-1] इसमें होम फ़ंक्शन होना ज़रूरी है. साथ ही, इसमें बैक और हाल ही के फ़ंक्शन हो सकते हैं.
[7.2.3/A-0-2] बैक फ़ंक्शन (KEYCODE_BACK) के सामान्य और लंबे समय तक दबाए रखने वाले, दोनों इवेंट को फ़ोरग्राउंड ऐप्लिकेशन पर भेजना ज़रूरी है.
[7.3/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() के ज़रिए अनुरोध की गई जगह की जानकारी को मैप से मैच नहीं किया जाना चाहिए.

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

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

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

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

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

[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 की ज़रूरी शर्त पूरी की जाती है. इसके लिए, रिसीवर पर कैलकुलेट की गई GNSS ऑर्बिट की अनुमानित जानकारी का इस्तेमाल किया जाता है. इसके अलावा, वाहन की पिछली ज्ञात जगह की जानकारी का इस्तेमाल किया जाता है. साथ ही, कम से कम 60 सेकंड तक डेड रेकनिंग की सुविधा का इस्तेमाल किया जाता है. इसमें जगह की सटीक जानकारी 7.3.3/C-1-3 के मुताबिक होती है. इसके अलावा, इन दोनों का कॉम्बिनेशन भी इस्तेमाल किया जा सकता है.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[7.8.1/A-0-1] इसमें माइक्रोफ़ोन शामिल होना चाहिए.

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

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

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

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

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

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

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

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

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

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

[5.3/A-SR] H.265 HEVC

2.5.3. सॉफ़्टवेयर

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

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

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

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

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

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

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

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

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

[3.8.3.1/A-0-1] Notifications on Automotive OS एसडीके के दस्तावेज़ में बताए गए तरीके से, संसाधनों को सही तरीके से रेंडर करना ज़रूरी है.
[3.8.3.1/A-0-2] Notification.Builder.addAction() के ज़रिए उपलब्ध कराए गए विकल्पों के बजाय, सूचनाओं से जुड़ी कार्रवाइयों के लिए PLAY और MUTE विकल्प दिखाने चाहिए
[3.8.3.1/A] को सूचना चैनल के हिसाब से कंट्रोल करने जैसी बेहतर मैनेजमेंट सुविधाओं के इस्तेमाल पर पाबंदी लगानी चाहिए. MAY use UI affordance per application to reduce controls.

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

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

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

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

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

[3.8/A] MAY restrict the application requests to enter a full screen mode as described in immersive documentation.
[3.8/A] स्टेटस बार और नेविगेशन बार को हमेशा दिखने की अनुमति है.
[3.8/A] सिस्टम यूआई एलिमेंट के बैकग्राउंड के रंग बदलने के लिए, ऐप्लिकेशन के अनुरोधों को सीमित कर सकता है. इससे यह पक्का किया जा सकेगा कि ये एलिमेंट हर समय साफ़ तौर पर दिखें.

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

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

[8.2/A-0-1] हर प्रोसेस के यूआईडी के हिसाब से, नॉन-वोलेटाइल स्टोरेज में पढ़े और लिखे गए बाइट की संख्या की जानकारी देनी होगी, ताकि डेवलपर को सिस्टम एपीआई android.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. सुरक्षा मॉडल

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

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

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

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

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

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

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

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

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

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

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

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

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

2.6.1. हार्डवेयर

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

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

जायरोस्कोप

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

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

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

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

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

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

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

2.6.2. सॉफ़्टवेयर

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

3. सॉफ़्टवेयर

3.1. Managed API के साथ काम करने की सुविधा

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

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

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

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

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

3.2.1. अनुमतियां

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

3.2.2. पैरामीटर बनाना

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

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

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

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

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

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

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

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

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

3.2.3.2. इंटेंट रिज़ॉल्यूशन

[C-0-1] Android एक एक्सटेंसिबल प्लैटफ़ॉर्म है. इसलिए, डिवाइसों पर Android के वर्शन को लागू करने के लिए , यह ज़रूरी है कि सेक्शन 3.2.3.1 में बताए गए हर इंटेंट पैटर्न को तीसरे पक्ष के ऐप्लिकेशन से बदला जा सके. हालांकि, सेटिंग को बदलने की अनुमति नहीं दी जानी चाहिए. Android के ओपन सोर्स वर्शन में, यह सुविधा डिफ़ॉल्ट रूप से चालू होती है.
[C-0-2] डिवाइस बनाने वाली कंपनियों को, सिस्टम ऐप्लिकेशन के लिए इन इंटेंट पैटर्न के इस्तेमाल पर खास अनुमतियां नहीं देनी चाहिए. साथ ही, उन्हें तीसरे पक्ष के ऐप्लिकेशन को इन पैटर्न से बाइंड होने और इनका कंट्रोल लेने से नहीं रोकना चाहिए. खास तौर पर, इस पाबंदी में “चूज़र” यूज़र इंटरफ़ेस को बंद करना शामिल है. हालांकि, इसमें और भी चीज़ें शामिल हो सकती हैं. इस यूज़र इंटरफ़ेस की मदद से, उपयोगकर्ता एक जैसे इंटेंट पैटर्न को हैंडल करने वाले कई ऐप्लिकेशन में से किसी एक को चुन सकता है.
[C-0-3] डिवाइसों में, उपयोगकर्ताओं को ऐसा यूज़र इंटरफ़ेस देना ज़रूरी है जिसकी मदद से वे इंटेंट के लिए डिफ़ॉल्ट गतिविधि में बदलाव कर सकें.
हालांकि, डिवाइस लागू करने वाले लोग या कंपनियां, खास यूआरआई पैटर्न (जैसे, http://play.google.com) के लिए डिफ़ॉल्ट गतिविधियां उपलब्ध करा सकती हैं. ऐसा तब किया जा सकता है, जब डिफ़ॉल्ट गतिविधि, डेटा यूआरआई के लिए ज़्यादा खास एट्रिब्यूट उपलब्ध कराती हो. उदाहरण के लिए, “http://www.android.com” डेटा यूआरआई के बारे में बताने वाला इंटेंट फ़िल्टर पैटर्न, ब्राउज़र के “http://” के लिए कोर इंटेंट पैटर्न से ज़्यादा सटीक होता है.

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

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

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

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

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

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

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

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

3.2.3.5. शर्तें पूरी होने पर ऐप्लिकेशन इंटेंट

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

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

अगर डिवाइसों के लिए लागू की गई सुविधाओं की रिपोर्ट android.software.home_screen है, तो:

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

अगर डिवाइसों के लिए लागू की गई सुविधाओं की रिपोर्ट android.hardware.telephony है, तो:

[C-2-1] ऐप्लिकेशन में सेटिंग मेन्यू होना चाहिए. इससे android.provider.Telephony.ACTION_CHANGE_DEFAULT इंटेंट को कॉल किया जा सके, ताकि डिफ़ॉल्ट एसएमएस ऐप्लिकेशन बदलने के लिए डायलॉग दिखाया जा सके.
[C-2-2] android.telecom.action.CHANGE_DEFAULT_DIALER के इंटेंट का पालन करना ज़रूरी है, ताकि उपयोगकर्ता को एक डायलॉग दिखाया जा सके. इससे उपयोगकर्ता, डिफ़ॉल्ट फ़ोन ऐप्लिकेशन को बदल पाएगा.
- आने वाले और किए जाने वाले कॉल के लिए, उपयोगकर्ता के चुने गए डिफ़ॉल्ट Phone ऐप्लिकेशन के यूज़र इंटरफ़ेस (यूआई) का इस्तेमाल करना चाहिए. हालांकि, आपातकालीन कॉल के लिए, पहले से इंस्टॉल किए गए Phone ऐप्लिकेशन का इस्तेमाल किया जाएगा.
[C-2-3] android.telecom.action.CHANGE_PHONE_ACCOUNTS इंटेंट का पालन करना ज़रूरी है, ताकि उपयोगकर्ता को PhoneAccounts से जुड़े ConnectionServices को कॉन्फ़िगर करने की सुविधा मिल सके. साथ ही, उसे डिफ़ॉल्ट PhoneAccount को कॉन्फ़िगर करने की सुविधा मिल सके, जिसका इस्तेमाल टेलीकम्यूनिकेशन सेवा देने वाली कंपनी, आउटगोइंग कॉल करने के लिए करेगी. AOSP में इस सुविधा को लागू करने के लिए, "कॉल" सेटिंग मेन्यू में "कॉलिंग खाते का विकल्प" मेन्यू शामिल किया गया है.
[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] यह सुझाव दिया जाता है कि android.intent.action.ANSWER, android.intent.action.CALL, android.intent.action.CALL_BUTTON, android.intent.action.VIEW, और android.intent.action.DIAL इंटेंट को पहले से लोड किए गए डायलर ऐप्लिकेशन के साथ इस्तेमाल किया जाए. यह ऐप्लिकेशन, इन इंटेंट को हैंडल कर सकता है और एसडीके में बताए गए तरीके से अनुरोध पूरा कर सकता है.

अगर डिवाइसों के लिए लागू की गई सुविधाओं की रिपोर्ट android.hardware.nfc.hce है, तो:

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

अगर डिवाइसों के लिए लागू की गई सुविधाओं की रिपोर्ट android.hardware.nfc है, तो:

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

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

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

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

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

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

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

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

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

[C-9-1] एसडीके के दस्तावेज़ में बताए गए तरीके के मुताबिक, 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-1] android.media.action.STILL_IMAGE_CAMERA और android.media.action.STILL_IMAGE_CAMERA_SECURE के इंटेंट का पालन करना ज़रूरी है. साथ ही, एसडीके में बताए गए तरीके के मुताबिक, कैमरे को स्टिल इमेज मोड में लॉन्च करना ज़रूरी है.
[C-12-2] एसडीके में बताए गए तरीके के मुताबिक, वीडियो मोड में कैमरा लॉन्च करने के android.media.action.VIDEO_CAMERA इंटेंट का पालन करना ज़रूरी है.
[C-12-3] सिर्फ़ पहले से इंस्टॉल किए गए Android ऐप्लिकेशन को, एसडीके दस्तावेज़ में बताए गए इन इंटेंट MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE, और MediaStore.ACTION_VIDEO_CAPTURE को हैंडल करने की अनुमति देनी होगी.

अगर डिवाइसों के लिए लागू की गई सुविधाओं की रिपोर्ट android.software.device_admin है, तो:

[C-13-1] सिस्टम में डिवाइस एडमिन जोड़ने के लिए, यूज़र इंटरफ़ेस (यूआई) को चालू करने के android.app.action.ADD_DEVICE_ADMIN इंटेंट का पालन करना ज़रूरी है. इससे उपयोगकर्ता को डिवाइस एडमिन जोड़ने या उसे अस्वीकार करने का विकल्प मिलता है.
[C-13-2] SDK को android.app.action.ADMIN_POLICY_COMPLIANCE, android.app.action.GET_PROVISIONING_MODE, android.app.action.PROVISIONING_SUCCESSFUL, android.app.action.PROVISION_MANAGED_DEVICE, 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 इंटेंट का पालन करना होगा. साथ ही, एसडीके में एक ऐसी गतिविधि होनी चाहिए जो इन इंटेंट को पूरा कर सके. इसके बारे में एसडीके में यहां बताया गया है.

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

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

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

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

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

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

अगर डिवाइसों पर android.hardware.audio.output सुविधा उपलब्ध है, तो:

[C-SR] हमारा सुझाव है कि android.intent.action.TTS_SERVICE, android.speech.tts.engine.INSTALL_TTS_DATA, और android.speech.tts.engine.GET_SAMPLE_TEXT इंटेंट को पूरा करने के लिए, ऐप्लिकेशन में एक गतिविधि होनी चाहिए. इसके बारे में एसडीके में यहां बताया गया है.

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

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

3.2.4. सेकंडरी/एक से ज़्यादा डिसप्ले पर की जाने वाली गतिविधियां

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

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

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

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

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

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

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

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

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

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

[C-0-1] यह एक या उससे ज़्यादा तय किए गए Android NDK ABIs के साथ काम करना चाहिए.
[C-0-2] इसमें मैनेज किए जा रहे एनवायरमेंट में कोड चलाने की सुविधा शामिल होनी चाहिए, ताकि नेटिव कोड को कॉल किया जा सके. इसके लिए, स्टैंडर्ड Java Native Interface (JNI) सिमैंटिक्स का इस्तेमाल किया जाता है.
[C-0-3] यह ज़रूरी है कि नीचे दी गई सूची में मौजूद हर ज़रूरी लाइब्रेरी के साथ, सोर्स-कंपैटिबल (यानी कि हेडर-कंपैटिबल) और बाइनरी-कंपैटिबल (एबीआई के लिए) हो.
[C-0-5] android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS, और android.os.Build.SUPPORTED_64_BIT_ABIS पैरामीटर के ज़रिए, डिवाइस के साथ काम करने वाले नेटिव ऐप्लिकेशन बाइनरी इंटरफ़ेस (एबीआई) की सटीक जानकारी देना ज़रूरी है. हर पैरामीटर, कॉमा लगाकर अलग किए गए एबीआई की सूची होती है. इसमें सबसे ज़्यादा से लेकर सबसे कम पसंद किए जाने वाले एबीआई तक की जानकारी होती है.
[C-0-6] ऊपर दिए गए पैरामीटर के ज़रिए, एबीआई की इस सूची के सबसेट की रिपोर्ट देनी होगी. साथ ही, सूची में शामिल नहीं किए गए किसी भी एबीआई की रिपोर्ट नहीं देनी होगी.
- armeabi (NDK अब इसे टारगेट नहीं करता)
- armeabi-v7a
- arm64-v8a
- x86
- x86-64
[C-0-7] नेटिव एपीआई उपलब्ध कराने वाली इन सभी लाइब्रेरी को, नेटिव कोड वाले ऐप्लिकेशन के लिए उपलब्ध कराना ज़रूरी है:
- libaaudio.so (AAudio की नेटिव ऑडियो सहायता)
- libamidi.so (अगर सुविधा android.software.midi के लिए दावा किया गया है, जैसा कि सेक्शन 5.9 में बताया गया है, तो नेटिव 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] सिस्टम लाइब्रेरी के तौर पर AOSP में लागू की गई और उपलब्ध कराई गई किसी भी अन्य नेटिव लाइब्रेरी को, एपीआई लेवल 24 या उसके बाद के वर्शन को टारगेट करने वाले तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध नहीं कराना चाहिए. ऐसा इसलिए, क्योंकि ये लाइब्रेरी रिज़र्व होती हैं.
[C-0-11] NDK में बताए गए सभी OpenGL ES 3.1 और Android Extension Pack फ़ंक्शन सिंबल को libGLESv3.so लाइब्रेरी के ज़रिए एक्सपोर्ट करना ज़रूरी है. ध्यान दें कि सभी सिंबल मौजूद होने चाहिए. हालांकि, सेक्शन 7.1.4.1 में इस बारे में ज़्यादा जानकारी दी गई है कि हर फ़ंक्शन को पूरी तरह से लागू करने की ज़रूरत कब होती है.
[C-0-12] libvulkan.so लाइब्रेरी के ज़रिए, Vulkan 1.0 के मुख्य फ़ंक्शन सिंबल के साथ-साथ VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1, और VK_KHR_get_physical_device_properties2 एक्सटेंशन के लिए फ़ंक्शन सिंबल एक्सपोर्ट करना ज़रूरी है. ध्यान दें कि सभी सिंबल मौजूद होने चाहिए. हालांकि, सेक्शन 7.1.4.2 में इस बारे में ज़्यादा जानकारी दी गई है कि हर फ़ंक्शन को पूरी तरह से लागू करने की ज़रूरत कब होती है.
इसे Android Open Source Project के अपस्ट्रीम में उपलब्ध सोर्स कोड और हेडर फ़ाइलों का इस्तेमाल करके बनाया जाना चाहिए

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

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

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

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

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

[C-2-1] यह ज़रूरी है कि /proc/cpuinfo में ये लाइनें शामिल हों. साथ ही, यह ज़रूरी है कि एक ही डिवाइस पर वैल्यू में बदलाव न किया जाए. भले ही, उन्हें अन्य एबीआई से पढ़ा गया हो.
- Features:, इसके बाद डिवाइस के साथ काम करने वाली ARMv7 सीपीयू की किसी भी सुविधा की सूची दी गई है.
- CPU architecture:, इसके बाद एक पूर्णांक होता है.यह पूर्णांक, डिवाइस के सबसे ज़्यादा सपोर्ट किए गए एआरएम आर्किटेक्चर के बारे में बताता है. उदाहरण के लिए, "8" for ARMv8 devices).
[C-2-2] ज़रूरी है कि ये ऑपरेशन हमेशा उपलब्ध रहें. भले ही, एबीआई को ARMv8 आर्किटेक्चर पर लागू किया गया हो. ऐसा नेटिव सीपीयू सपोर्ट या सॉफ़्टवेयर इम्यूलेशन के ज़रिए किया जा सकता है:
- SWP और SWPB से जुड़े निर्देश.
- SETEND निर्देश.
- CP15ISB, CP15DSB, और CP15DMB बैरियर ऑपरेशंस.
[C-2-3] में Advanced SIMD (इसे NEON भी कहा जाता है) एक्सटेंशन के लिए सपोर्ट शामिल होना चाहिए.

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

3.4.1. WebView के साथ काम करना

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

[C-1-1] android.software.webview की जानकारी देना ज़रूरी है.
[C-1-2] android.webkit.WebView एपीआई को लागू करने के लिए, Android 11 ब्रांच पर Android Open Source Project से बनाए गए Chromium प्रोजेक्ट का इस्तेमाल करना ज़रूरी है.
[C-1-3] WebView से रिपोर्ट की गई उपयोगकर्ता एजेंट स्ट्रिंग इस फ़ॉर्मैट में होनी चाहिए:

Mozilla/5.0 (Linux; Android $(VERSION); [$(MODEL)] [Build/$(BUILD)]; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36
- $(VERSION) स्ट्रिंग की वैल्यू, android.os.Build.VERSION.RELEASE की वैल्यू के बराबर होनी चाहिए.
- $(MODEL) स्ट्रिंग खाली हो सकती है. हालांकि, अगर यह खाली नहीं है, तो इसकी वैल्यू android.os.Build.MODEL के बराबर होनी चाहिए.
- "Build/$(BUILD)" को हटाया जा सकता है. हालांकि, अगर यह मौजूद है, तो $(BUILD) स्ट्रिंग, android.os.Build.ID की वैल्यू के बराबर होनी चाहिए.
- $(CHROMIUM_VER) स्ट्रिंग की वैल्यू, Android Open Source Project के अपस्ट्रीम में मौजूद Chromium का वर्शन होना चाहिए.
- डिवाइस लागू करने वाले लोग, उपयोगकर्ता एजेंट स्ट्रिंग में मोबाइल को शामिल न करें.
WebView कॉम्पोनेंट में, ज़्यादा से ज़्यादा HTML5 सुविधाओं के लिए सहायता शामिल होनी चाहिए. अगर यह सुविधा के साथ काम करता है, तो इसे HTML5 स्पेसिफ़िकेशन के मुताबिक होना चाहिए.
[C-1-3] दिए गए कॉन्टेंट या रिमोट यूआरएल के कॉन्टेंट को ऐसी प्रोसेस में रेंडर करना ज़रूरी है जो वेबव्यू को इंस्टैंटिएट करने वाले ऐप्लिकेशन से अलग हो. खास तौर पर, अलग रेंडरर प्रोसेस के पास कम विशेषाधिकार होने चाहिए. इसे अलग यूज़र आईडी के तौर पर चलाना चाहिए. इसके पास ऐप्लिकेशन की डेटा डायरेक्ट्री का ऐक्सेस नहीं होना चाहिए. इसके पास सीधे तौर पर नेटवर्क ऐक्सेस नहीं होना चाहिए. साथ ही, इसके पास सिर्फ़ Binder के ज़रिए, सिस्टम की ज़रूरी सेवाओं का ऐक्सेस होना चाहिए. WebView का 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-9] डिवाइसों को, Security.getProviders() तरीके से, सुरक्षा से जुड़ी इन सेवाओं की जानकारी, ऐरे की पहली सात वैल्यू के तौर पर देनी होगी. यह जानकारी, यहां दिए गए क्रम में, दिए गए नामों (Provider.getName() से मिली जानकारी के मुताबिक) और क्लास के साथ देनी होगी. हालांकि, अगर ऐप्लिकेशन ने insertProviderAt() या removeProvider() के ज़रिए सूची में बदलाव किया है, तो ऐसा करने की ज़रूरत नहीं है. डिवाइस, यहां दी गई सूची में शामिल प्रोवाइडर के अलावा अन्य प्रोवाइडर की जानकारी भी दे सकते हैं.
1. AndroidNSSP - android.security.net.config.NetworkSecurityConfigProvider
2. AndroidOpenSSL - com.android.org.conscrypt.OpenSSLProvider
3. CertPathProvider - sun.security.provider.CertPathProvider
4. AndroidKeyStoreBCWorkaround - android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
5. बीसी - com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
6. HarmonyJSSE - com.android.org.conscrypt.JSSEProvider
7. AndroidKeyStore - android.security.keystore.AndroidKeyStoreProvider

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

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

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

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

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

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

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

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

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

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

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

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

[C-0-5] MUST NOT be in a namespace owned by or referring to another organization. उदाहरण के लिए, डिवाइस बनाने वाली कंपनियों को com.google.* या इसी तरह के नेमस्पेस में एपीआई नहीं जोड़ने चाहिए. ऐसा सिर्फ़ Google कर सकता है. इसी तरह, Google को अन्य कंपनियों के नेमस्पेस में एपीआई नहीं जोड़ने चाहिए.
[C-0-6] को Android की शेयर की गई लाइब्रेरी में पैकेज किया जाना चाहिए, ताकि सिर्फ़ वे ऐप्लिकेशन इन एपीआई के ज़्यादा मेमोरी इस्तेमाल करने से प्रभावित हों जो साफ़ तौर पर इनका इस्तेमाल करते हैं. इसके लिए, <uses-library> मेकेनिज़्म का इस्तेमाल किया जाता है.

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

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

3.7. रनटाइम कंपैटबिलिटी

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.2. विजेट

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

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

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

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

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

3.8.3. सूचनाएं

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

3.8.3.1. सूचनाएं दिखाने का तरीका

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

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

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

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

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

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

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

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

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

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

[C-3-1] सूचनाएं दिखाते समय, Notification.Builder एपीआई क्लास में बताए गए तरीके से, हेड्स-अप सूचनाओं के व्यू और संसाधनों का इस्तेमाल करना ज़रूरी है.
[C-3-2] 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. खोजें

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

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

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

[C-1-1] MUST implement the APIs that allow third-party applications to add suggestions to the search box when it is run in global search mode.

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

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

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

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

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

3.8.5. सूचनाएं और सूचनाएं

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

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

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

3.8.6. थीम

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Android में, इनपुट मैनेजमेंट की सुविधा उपलब्ध है. साथ ही, इसमें तीसरे पक्ष के इनपुट मेथड एडिटर का इस्तेमाल किया जा सकता है.

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

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

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

Android 5.0 से, Remote Control Client API का इस्तेमाल बंद कर दिया गया है. इसके बजाय, Media Notification Template का इस्तेमाल किया जाता है. इससे मीडिया ऐप्लिकेशन, लॉक स्क्रीन पर दिखने वाले प्लेबैक कंट्रोल के साथ इंटिग्रेट हो पाते हैं.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Android, एसडीके के दस्तावेज़ में बताए गए तरीके से डिसप्ले कटआउट की सुविधा के साथ काम करता है. 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 Device Administration API के ज़रिए पासवर्ड से जुड़ी नीतियां लागू करना या रिमोट वाइप करना.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.10. सुलभता

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

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

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

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

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

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

अगर डिवाइस में android.hardware.audio.output सुविधा मौजूद है, तो:

[C-1-1] ज़रूरी है कि इसमें Android TTS फ़्रेमवर्क एपीआई काम करते हों.

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

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

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

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

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

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

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

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

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

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

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

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

[C-1-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-0-1] इंस्टेंट ऐप्लिकेशन को सिर्फ़ वे अनुमतियां दी जानी चाहिए जिनके लिए android:protectionLevel को "instant" पर सेट किया गया है.
[C-0-2] झटपट ऐप्लिकेशन को, इंस्टॉल किए गए ऐप्लिकेशन के साथ इंप्लिसिट इंटेंट के ज़रिए इंटरैक्ट नहीं करना चाहिए. हालांकि, ऐसा तब किया जा सकता है, जब इनमें से कोई एक शर्त पूरी होती हो:
- कॉम्पोनेंट का इंटेंट पैटर्न फ़िल्टर चालू है और उसमें CATEGORY_BROWSABLE मौजूद है
- ऐक्शन, ACTION_SEND, ACTION_SENDTO या ACTION_SEND_MULTIPLE में से कोई एक हो
- टारगेट को android:visibleToInstantApps के साथ साफ़ तौर पर दिखाया गया हो
[C-0-3] इंस्टैंट ऐप्लिकेशन को इंस्टॉल किए गए ऐप्लिकेशन के साथ साफ़ तौर पर इंटरैक्ट नहीं करना चाहिए. हालांकि, अगर कॉम्पोनेंट को android:visibleToInstantApps के ज़रिए दिखाया जाता है, तो ऐसा किया जा सकता है.
[C-0-4] इंस्टॉल किए गए ऐप्लिकेशन को डिवाइस पर मौजूद इंस्टैंट ऐप्लिकेशन के बारे में जानकारी नहीं दिखनी चाहिए. ऐसा तब तक नहीं होना चाहिए, जब तक इंस्टैंट ऐप्लिकेशन साफ़ तौर पर इंस्टॉल किए गए ऐप्लिकेशन से कनेक्ट न हो.

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

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

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

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

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

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

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

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

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

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

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

3.18. संपर्क

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

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

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

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

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

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

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

[C-1-1] ContactsContract.RawContacts.getLocalAccountName को कस्टम लोकल खाते का ACCOUNT_NAME वापस करना होगा
[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 signing का इस्तेमाल करके “.apk” फ़ाइलों की पुष्टि करने की सुविधा होनी चाहिए.
[C-0-3] .apk, Android मेनिफ़ेस्ट, Dalvik bytecode या RenderScript bytecode फ़ॉर्मैट को इस तरह से नहीं बढ़ाया जाना चाहिए कि वे फ़ाइलें, ज़रूरी शर्तें पूरी करने वाले अन्य डिवाइसों पर सही तरीके से इंस्टॉल और रन न हो पाएं.
[C-0-4] पैकेज के लिए "इंस्टॉलर ऑफ़ रिकॉर्ड" के तौर पर सेट किए गए ऐप्लिकेशन के अलावा, किसी अन्य ऐप्लिकेशन को उपयोगकर्ता की पुष्टि के बिना ऐप्लिकेशन को साइलेंट तरीके से अनइंस्टॉल करने की अनुमति नहीं देनी चाहिए. इस बारे में, DELETE_PACKAGE अनुमति के लिए एसडीके में बताया गया है. सिर्फ़ दो ऐप्लिकेशन को इस नीति से छूट मिली है. पहला, सिस्टम पैकेज वेरिफ़ायर ऐप्लिकेशन, जो PACKAGE_NEEDS_VERIFICATION इंटेंट को हैंडल करता है. दूसरा, स्टोरेज मैनेजर ऐप्लिकेशन, जो ACTION_MANAGE_STORAGE इंटेंट को हैंडल करता है.
[C-0-5] में ऐसी गतिविधि होनी चाहिए जो android.settings.MANAGE_UNKNOWN_APP_SOURCES इंटेंट को हैंडल करती हो.
[C-0-6] ऐप्लिकेशन को अज्ञात सोर्स से ऐप्लिकेशन पैकेज इंस्टॉल नहीं करने चाहिए. हालांकि, अगर ऐप्लिकेशन इंस्टॉल करने का अनुरोध करने वाला ऐप्लिकेशन, यहां दी गई सभी ज़रूरी शर्तों को पूरा करता है, तो ऐसा किया जा सकता है:
- इसके लिए, REQUEST_INSTALL_PACKAGES अनुमति का एलान करना ज़रूरी है. इसके अलावा, android:targetSdkVersion को 24 या इससे कम पर सेट करना भी ज़रूरी है.
- उपयोगकर्ता ने, अज्ञात स्रोतों से ऐप्लिकेशन इंस्टॉल करने की अनुमति दी हो.
डिवाइस में, उपयोगकर्ता को हर ऐप्लिकेशन के लिए, अज्ञात सोर्स से ऐप्लिकेशन इंस्टॉल करने की अनुमति देने/रद्द करने का विकल्प देना चाहिए. हालांकि, अगर डिवाइस में इस विकल्प को लागू नहीं करना है, तो इसे नो-ऑप के तौर पर लागू किया जा सकता है. साथ ही, startActivityForResult() के लिए RESULT_CANCELED को वापस भेजा जा सकता है. हालांकि, ऐसे मामलों में भी उन्हें उपयोगकर्ता को यह बताना चाहिए कि ऐसा विकल्प क्यों नहीं दिया गया है.
[C-0-7] सिस्टम एपीआई PackageManager.setHarmfulAppWarning के ज़रिए दी गई चेतावनी स्ट्रिंग के साथ, चेतावनी वाला डायलॉग दिखाना ज़रूरी है. यह डायलॉग, उपयोगकर्ता को उस ऐप्लिकेशन में गतिविधि लॉन्च करने से पहले दिखाना होगा जिसे सिस्टम एपीआई PackageManager.setHarmfulAppWarning ने संभावित रूप से नुकसान पहुंचाने वाला ऐप्लिकेशन के तौर पर मार्क किया है.
चेतावनी वाले डायलॉग पर, उपयोगकर्ता को ऐप्लिकेशन अनइंस्टॉल करने या लॉन्च करने का विकल्प देना चाहिए.
[C-0-8] यहां दिए गए दस्तावेज़ के मुताबिक, इंक्रीमेंटल फ़ाइल सिस्टम के लिए सहायता लागू करना ज़रूरी है.
[C-0-9] APK सिग्नेचर स्कीम v4 का इस्तेमाल करके, .apk फ़ाइलों की पुष्टि करने की सुविधा होनी चाहिए.
अगर डिवाइसों को Android के पुराने वर्शन पर पहले ही लॉन्च कर दिया गया है और सिस्टम सॉफ़्टवेयर अपडेट के ज़रिए, वे [C-0-8] और [C-0-9] की ज़रूरी शर्तों को पूरा नहीं कर सकते, तो उन्हें इन ज़रूरी शर्तों से छूट मिल सकती है.

5. मल्टीमीडिया फ़ाइलों के साथ काम करने की सुविधा

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

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

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

SHOULD aim for minimum codec latency, in others words, they
- इनपुट बफ़र का इस्तेमाल नहीं करना चाहिए और उन्हें सेव नहीं करना चाहिए. साथ ही, प्रोसेस होने के बाद सिर्फ़ एक बार इनपुट बफ़र वापस करना चाहिए.
- डिकोड किए गए बफ़र को स्टैंडर्ड (जैसे, एसपीएस) में तय किए गए समय से ज़्यादा समय तक सेव नहीं करना चाहिए.
- GOP स्ट्रक्चर के लिए ज़रूरी समय से ज़्यादा समय तक, एन्कोड किए गए बफ़र को सेव नहीं करना चाहिए.

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

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

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

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

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

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

[C-1-1] पीसीएम/वेव
[C-1-2] FLAC
[C-1-3] Opus

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

[C-3-1] android.media.MediaCodec एपीआई के ज़रिए, पीसीएम 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 प्रोफ़ाइल (AAC+)
[C-1-3] MPEG-4 HE AACv2 प्रोफ़ाइल (बेहतर AAC+)
[C-1-4] एएसी ईएलडी (बेहतर लो डिले एएसी)
[C-1-11] xHE-AAC (ISO/IEC 23003-3 Extended HE AAC Profile, which includes the USAC Baseline Profile, and ISO/IEC 23003-4 Dynamic Range Control Profile)
[C-1-5] FLAC
[C-1-6] MP3
[C-1-7] एमआईडीआई
[C-1-8] Vorbis
[C-1-9] पीसीएम/वेव, जिसमें ज़्यादा रिज़ॉल्यूशन वाले ऑडियो फ़ॉर्मैट शामिल हैं. जैसे, 24 बिट, 192 किलोहर्ट्ज़ का सैंपलिंग रेट, और 8 चैनल. ध्यान दें कि यह ज़रूरी शर्त सिर्फ़ डिकोडिंग के लिए है. साथ ही, डिवाइस को वीडियो चलाने के दौरान डाउनसैंपल और डाउनमिक्स करने की अनुमति है.
[C-1-10] Opus

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

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

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

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

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

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

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

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

सभी ऑडियो डिकोडर में, ये आउटपुट देने की सुविधा होनी चाहिए:

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

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

फ़ॉर्मैट/कोडेक	जानकारी	इस्तेमाल किए जा सकने वाले फ़ाइल टाइप/कंटेनर फ़ॉर्मैट
MPEG-4 AAC प्रोफ़ाइल (AAC LC)	मोनो/स्टीरियो/5.0/5.1 कॉन्टेंट के लिए, 8 से 48 किलोहर्ट्ज़ तक के स्टैंडर्ड सैंपलिंग रेट का इस्तेमाल किया जा सकता है.	3GPP (.3gp) MPEG-4 (.mp4, .m4a) ADTS रॉ एएसी (.aac, ADIF फ़ॉर्मैट काम नहीं करता) MPEG-TS (.ts, इसमें आगे-पीछे जाने की सुविधा नहीं होती, सिर्फ़ डीकोड किया जा सकता है) 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 किलोहर्ट्ज़ तक के स्टैंडर्ड सैंपलिंग रेट का इस्तेमाल किया जा सकता है.	MPEG-4 (.mp4, .m4a)
AMR-NB	8 किलोहर्ट्ज़ पर सैंपल किया गया 4.75 से 12.2 केबीपीएस	3GPP (.3gp)
AMR-WB	AMR-WB, Adaptive Multi-Rate - Wideband Speech Codec में बताए गए अनुसार, 6.60 kbit/s से 23.85 kbit/s तक के नौ रेट, 16 kHz पर सैंपल किए गए	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. DLS के वर्शन 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	पीसीएम कोडेक में, 16-बिट लीनियर पीसीएम और 16-बिट फ़्लोट काम करना चाहिए. WAVE एक्सट्रैक्टर में, 16-बिट, 24-बिट, 32-बिट लीनियर पीसीएम, और 32-बिट फ़्लोट (हार्डवेयर की सीमा तक की दरें) के साथ काम करने की सुविधा होनी चाहिए. सैंपलिंग रेट, 8 किलोहर्ट्ज़ से 192 किलोहर्ट्ज़ के बीच होना चाहिए.	WAVE (.wav)
Opus	डिकोडिंग: मोनो, स्टीरियो, 5.0, और 5.1 कॉन्टेंट के साथ-साथ 8000, 12000, 16000, 24000, और 48000 हर्ट्ज़ की सैंपलिंग दर के लिए सहायता. एनकोडिंग: मोनो और स्टीरियो कॉन्टेंट के साथ-साथ 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] बीएमपी
[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] इनपुट सरफेस मोड के लिए, RGB888 कलर फ़ॉर्मैट का इस्तेमाल करने का सुझाव दिया जाता है.
[C-1-3] प्लानर या सेमीप्लानर YUV420 8:8:8 कलर फ़ॉर्मैट में से कम से कम एक पर काम करना ज़रूरी है: COLOR_FormatYUV420PackedPlanar (COLOR_FormatYUV420Planar के बराबर) या COLOR_FormatYUV420PackedSemiPlanar (COLOR_FormatYUV420SemiPlanar के बराबर). दोनों पर काम करने का सुझाव दिया जाता है.

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

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

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

[C-1-1] वीडियो कोडेक को आउटपुट और इनपुट बाइटबफ़र के ऐसे साइज़ के साथ काम करना चाहिए जो स्टैंडर्ड और कॉन्फ़िगरेशन के हिसाब से, कंप्रेस किए गए और कंप्रेस न किए गए सबसे बड़े फ़्रेम के लिए ज़रूरी हों. हालांकि, उन्हें ज़रूरत से ज़्यादा जगह नहीं लेनी चाहिए.
[C-1-2] वीडियो एन्कोडर और डिकोडर को CodecCapabilities के ज़रिए, YUV420 8:8:8 फ़्लेक्सिबल कलर फ़ॉर्मैट (COLOR_FormatYUV420Flexible) के साथ काम करना चाहिए.
[C-1-3] वीडियो एन्कोडर और डिकोडर को प्लैनर या सेमीप्लैनर YUV420 8:8:8 कलर फ़ॉर्मैट में से कम से कम एक को सपोर्ट करना चाहिए: COLOR_FormatYUV420PackedPlanar (COLOR_FormatYUV420Planar के बराबर) या COLOR_FormatYUV420PackedSemiPlanar (COLOR_FormatYUV420SemiPlanar के बराबर). हालांकि, दोनों को सपोर्ट करने का सुझाव दिया जाता है.
[SR] वीडियो एन्कोडर और डिकोडर में, हार्डवेयर के हिसाब से ऑप्टिमाइज़ किए गए प्लानर या सेमीप्लानर YUV420 8:8:8 कलर फ़ॉर्मैट (YV12, NV12, NV21 या वेंडर के हिसाब से ऑप्टिमाइज़ किया गया कोई अन्य फ़ॉर्मैट) में से कम से कम एक फ़ॉर्मैट इस्तेमाल करने का सुझाव दिया जाता है.
[C-1-5] ज़्यादा बिट डेप्थ वाले फ़ॉर्मैट (हर चैनल के लिए 9 से ज़्यादा बिट) के साथ काम करने वाले वीडियो डिकोडर को, ऐप्लिकेशन के अनुरोध पर 8-बिट वाले फ़ॉर्मैट में आउटपुट देना ज़रूरी है. इसके लिए, android.media.MediaCodecInfo के ज़रिए YUV420 8:8:8 कलर फ़ॉर्मैट का इस्तेमाल करना ज़रूरी है.

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

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

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

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

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

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

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

फ़ॉर्मैट/कोडेक	जानकारी	इस्तेमाल किए जा सकने वाले फ़ाइल टाइप/कंटेनर फ़ॉर्मैट
H.263		3GPP (.3gp) MPEG-4 (.mp4) Matroska (.mkv, सिर्फ़ डिकोड करें)
H.264 एवीसी	ज़्यादा जानकारी के लिए, सेक्शन 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 का इस्तेमाल किया जा सकता है. OMX, अलग-अलग प्लैटफ़ॉर्म पर काम करने वाला मल्टीमीडिया ऐक्सेलरेट करने वाला एपीआई है. वहीं, Codec 2.0, कम ओवरहेड वाला मल्टीमीडिया ऐक्सेलरेट करने वाला एपीआई है.

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

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

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

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

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

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

5.1.10. मीडिया कोडेक की विशेषताएं

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

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

खास तौर पर:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.2.1. H.263

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

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

5.2.2. H.264

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

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

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

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

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

5.2.3. VP8

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

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

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

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

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

5.2.4. VP9

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

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

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

अगर डिवाइस में लागू किए गए सिस्टम, Media API के ज़रिए Profile 2 या Profile 3 के साथ काम करने का दावा करते हैं, तो:

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

5.2.5. H.265

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

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

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

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

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

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

5.3.1. MPEG-2

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

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

5.3.2. H.263

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

[C-1-1] Baseline Profile Level 30 और Level 45 के साथ काम करना ज़रूरी है.

5.3.3. MPEG-4

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

[C-1-1] Simple Profile Level 3 के साथ काम करना ज़रूरी है.

5.3.4. H.264

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

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

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

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

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

5.3.5. H.265 (HEVC)

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

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

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

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

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

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

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

5.3.6. VP8

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

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

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

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

5.3.7. VP9

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

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

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

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

[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 और HDR10Plus प्रोफ़ाइलों के लिए '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 के बाद से, SHOULD के तौर पर लिस्ट किया गया है. हालांकि, आने वाले वर्शन के लिए कंपैटबिलिटी डेफ़िनिशन में, इन्हें MUST के तौर पर बदलने का प्लान है. मौजूदा और नए Android डिवाइसों के लिए, यह बेहद ज़रूरी है कि वे 'ज़रूरी' के तौर पर लिस्ट की गई इन ज़रूरी शर्तों को पूरा करें. ऐसा न करने पर, आने वाले समय में Android के नए वर्शन पर अपग्रेड करने के बाद, वे Android के साथ काम नहीं कर पाएंगे.

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

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

[C-1-1] में, रॉ ऑडियो कॉन्टेंट को कैप्चर करने की अनुमति होनी चाहिए. इसमें ये विशेषताएं होनी चाहिए:
- फ़ॉर्मैट: लीनियर पीसीएम, 16-बिट
- सैंपल रेट: 8000, 11025, 16000, 44100, 48000 हर्ट्ज़
- चैनल: मोनो
इसमें रॉ ऑडियो कॉन्टेंट को कैप्चर करने की सुविधा होनी चाहिए. साथ ही, इसमें ये सुविधाएं होनी चाहिए:
- फ़ॉर्मैट: लीनियर पीसीएम, 16-बिट और 24-बिट
- सैंपलिंग रेट: 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 हर्ट्ज़
- चैनल: डिवाइस पर मौजूद माइक्रोफ़ोन की संख्या के बराबर चैनल
[C-1-2] ज़रूरी है कि वह अप-सैंपलिंग के बिना, ऊपर दिए गए सैंपल रेट पर कैप्चर करे.
[C-1-3] जब ऊपर दी गई सैंपल रेट को डाउन-सैंपलिंग के साथ कैप्चर किया जाता है, तो उसमें एंटी-एलियासिंग फ़िल्टर शामिल होना चाहिए.
इसमें एएम रेडियो और डीवीडी क्वालिटी में रॉ ऑडियो कॉन्टेंट कैप्चर करने की सुविधा होनी चाहिए. इसका मतलब है कि इसमें ये सुविधाएं होनी चाहिए:
- फ़ॉर्मैट: लीनियर पीसीएम, 16-बिट
- सैंपलिंग रेट: 22050, 48000 हर्ट्ज़
- चैनल: स्टीरियो
- [C-1-4] MicrophoneInfo एपीआई का इस्तेमाल करना ज़रूरी है. साथ ही, AudioManager.getMicrophones() एपीआई के ज़रिए तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध डिवाइस पर मौजूद माइक्रोफ़ोन की जानकारी सही तरीके से भरनी होगी. इसके अलावा, AudioRecord.getActiveMicrophones() और MediaRecorder.getActiveMicrophones() एपीआई के ज़रिए तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध, फ़िलहाल चालू माइक्रोफ़ोन की जानकारी भी सही तरीके से भरनी होगी. अगर डिवाइस में एएम रेडियो और डीवीडी क्वालिटी में रॉ ऑडियो कॉन्टेंट कैप्चर करने की सुविधा है, तो:
[C-2-1] किसी भी अनुपात में 16000:22050 या 44100:48000 से ज़्यादा अप-सैंपलिंग किए बिना कैप्चर करना ज़रूरी है.
[C-2-2] अप-सैंपलिंग या डाउन-सैंपलिंग के लिए, एंटी-एलियासिंग फ़िल्टर शामिल करना ज़रूरी है.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.4.5. एक साथ कई वीडियो कैप्चर करने की सुविधा

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

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

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

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

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

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

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

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

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

[C-1-1] डिवाइस में, रॉ ऑडियो कॉन्टेंट को चलाने की सुविधा होनी चाहिए. इसमें ये विशेषताएं होनी चाहिए:
- सोर्स फ़ॉर्मैट: लीनियर पीसीएम, 16-बिट, 8-बिट, फ़्लोट
- चैनल: मोनो, स्टीरियो, ज़्यादा से ज़्यादा आठ चैनलों के साथ मान्य मल्टीचैनल कॉन्फ़िगरेशन
- सैंपलिंग की दर (हर्ट्ज़ में):
  - ऊपर दिए गए चैनल कॉन्फ़िगरेशन के लिए, 8000, 11025, 16000, 22050, 32000, 44100, 48000
  - मोनो और स्टीरियो में 96000
इसमें, रॉ ऑडियो कॉन्टेंट को चलाने की सुविधा होनी चाहिए. साथ ही, इसमें ये विशेषताएं होनी चाहिए:
- सैंपलिंग रेट: 24000, 48000

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[C-2-1] कम समय में ऑडियो ट्रांसफ़र करने की सुविधा के साथ काम करने की जानकारी नहीं देनी चाहिए.

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

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

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

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

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

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

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

[C-1-1] एचटीटीपी(एस) पर, सेक्शन 5.1 में बताए गए सभी ज़रूरी कोडेक और कंटेनर फ़ॉर्मैट काम करने चाहिए.
[C-1-2] एचटीटीपी लाइव स्ट्रीमिंग ड्राफ़्ट प्रोटोकॉल, वर्शन 7 पर, नीचे दी गई मीडिया सेगमेंट फ़ॉर्मैट टेबल में दिखाए गए मीडिया सेगमेंट फ़ॉर्मैट के साथ काम करना ज़रूरी है.
[C-1-3] RTSP टेबल में दिए गए, RTP ऑडियो वीडियो प्रोफ़ाइल और उससे जुड़े कोडेक के साथ काम करना चाहिए. अपवादों के लिए, कृपया सेक्शन 5.1 में टेबल के फ़ुटनोट देखें.

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

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

सेगमेंट के फ़ॉर्मैट

रेफ़रंस

कोडेक के साथ काम करने की सुविधा

MPEG-2 ट्रांसपोर्ट स्ट्रीम

ISO 13818

वीडियो कोडेक:

H264 एवीसी
MPEG-4 SP
MPEG-2

H264 AVC, MPEG2-4 SP,
और MPEG-2 के बारे में ज़्यादा जानने के लिए, सेक्शन 5.1.3 देखें.

ऑडियो कोडेक:

AAC और इसके वैरिएंट के बारे में ज़्यादा जानने के लिए, सेक्शन 5.1.1 देखें.

ADTS फ़्रेमिंग और ID3 टैग के साथ AAC

ISO 13818-7

एएसी और इसके वैरिएंट के बारे में जानकारी के लिए, सेक्शन 5.1.1 देखें

WebVTT

RTSP (RTP, SDP)

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

5.8. Secure Media

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

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

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

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

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

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

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

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

[C-1-1] MIDI-capable हार्डवेयर ट्रांसपोर्ट के सभी वर्शन पर MIDI काम करना चाहिए. इसके लिए, वे MIDI के अलावा अन्य कनेक्टिविटी की सुविधा देते हैं. ये ट्रांसपोर्ट इस तरह के होते हैं:
- यूएसबी होस्ट मोड, section 7.7
- ब्लूटूथ LE पर एमआईडीआई, सेंट्रल डिवाइस के तौर पर काम कर रहा है, सेक्शन 7.4.3
[C-1-2] इसमें इंटर-ऐप्लिकेशन एमआईडीआई सॉफ़्टवेयर ट्रांसपोर्ट (वर्चुअल एमआईडीआई डिवाइस) की सुविधा होनी चाहिए
[C-1-3] libamidi.so (नेटिव एमआईडीआई सपोर्ट) शामिल होना चाहिए
इसमें यूएसबी की मदद से कनेक्ट किए गए सहायक डिवाइस के तौर पर एमआईडीआई की सुविधा काम करनी चाहिए, सेक्शन 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] OpenSL ES PCM बफ़र कतार API और AAudio नेटिव ऑडियो API के कम से कम एक पाथ, दोनों का इस्तेमाल करके, लेटेंसी और यूएसबी ऑडियो की ज़रूरी शर्तों को पूरा करना होगा.
[SR] एमएमएपी पाथ के बजाय AAudio नेटिव ऑडियो एपीआई का इस्तेमाल करके, लेटेंसी और यूएसबी ऑडियो से जुड़ी ज़रूरी शर्तों को पूरा करने का सुझाव दिया जाता है.
[C-1-6] में कोल्ड आउटपुट की लेटेन्सी 200 मिलीसेकंड या इससे कम होनी चाहिए.
[C-1-7] कोल्ड इनपुट लेटेंसी 200 मिलीसेकंड या इससे कम होनी चाहिए.
[SR] ऑडियो चालू होने और सीपीयू लोड में बदलाव होने पर, सीपीयू की परफ़ॉर्मेंस का एक जैसा लेवल बनाए रखने का सुझाव दिया जाता है. इसकी जांच, SynthMark के Android ऐप्लिकेशन वर्शन के कमिट आईडी 09b13c6f49ea089f8c31e5d035f912cc405b7ab8 का इस्तेमाल करके की जानी चाहिए. SynthMark, एक सॉफ़्टवेयर सिंथेसाइज़र का इस्तेमाल करता है. यह सिंथेसाइज़र, ऑडियो फ़्रेमवर्क पर काम करता है. इससे सिस्टम की परफ़ॉर्मेंस का आकलन किया जाता है. SynthMark ऐप्लिकेशन को “ऑटोमेटेड टेस्ट” विकल्प का इस्तेमाल करके चलाना होगा. साथ ही, ये नतीजे पाने होंगे:
- voicemark.90 >= 32 आवाज़ें
- latencymark.fixed.little <= 15 मि॰से॰
- latencymark.dynamic.little <= 50 मि॰से॰

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

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

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

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

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

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

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

[C-3-1] यूएसबी ऑडियो क्लास को लागू करना ज़रूरी है.
[C-3-2] यूएसबी ऑडियो क्लास का इस्तेमाल करके, यूएसबी होस्ट मोड पोर्ट पर ऑडियो की राउंड-ट्रिप लेटेंसी लगातार 20 मिलीसेकंड या इससे कम होनी चाहिए.
यूएसबी ऑडियो क्लास का इस्तेमाल करके, यूएसबी होस्ट मोड पोर्ट पर ऑडियो की राउंड-ट्रिप लेटेंसी लगातार 10 मिलीसेकंड या उससे कम होनी चाहिए.
[C-SR] यूएसबी ऑडियो पेरिफ़ेरल के साथ इस्तेमाल किए जाने पर, एक साथ I/O के लिए, हर दिशा में ज़्यादा से ज़्यादा आठ चैनलों, 96 किलोहर्ट्ज़ के सैंपल रेट, और 24-बिट या 32-बिट डेप्थ का इस्तेमाल करने का सुझाव दिया जाता है. हालांकि, ऐसा तब ही किया जा सकता है, जब यूएसबी ऑडियो पेरिफ़ेरल भी इन ज़रूरी शर्तों को पूरा करते हों.

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

कम से कम एक कॉन्फ़िगरेशन में, स्टीरियो और आठ चैनलों में 20-बिट या 24-बिट डेप्थ और 192 किलोहर्ट्ज़ पर आउटपुट देने की सुविधा होनी चाहिए. साथ ही, बिट-डेप्थ में कमी या रीसैंपलिंग नहीं होनी चाहिए.

5.11. प्रोसेस नहीं हुई इमेज के लिए कैप्चर

Android में, android.media.MediaRecorder.AudioSource.UNPROCESSED ऑडियो सोर्स के ज़रिए बिना प्रोसेस किए गए ऑडियो को रिकॉर्ड करने की सुविधा शामिल है. OpenSL ES में, इसे रिकॉर्ड प्रीसेट SL_ANDROID_RECORDING_PRESET_UNPROCESSED की मदद से ऐक्सेस किया जा सकता है.

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

[C-1-1] android.media.AudioManager प्रॉपर्टी PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED के ज़रिए, इस सुविधा के साथ काम करने की जानकारी देना ज़रूरी है.
[C-1-2] मिड-फ़्रीक्वेंसी रेंज में, ऐम्प्लिट्यूड-वर्सेस-फ़्रीक्वेंसी की विशेषताएं लगभग एक जैसी होनी चाहिए: खास तौर पर, बिना प्रोसेस किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन के लिए, 100 हर्ट्ज़ से 7,000 हर्ट्ज़ तक ±10dB.
[C-1-3] लो फ़्रीक्वेंसी रेंज में ऐम्प्लिट्यूड लेवल दिखाना ज़रूरी है: खास तौर पर, 5 हर्ट्ज़ से 100 हर्ट्ज़ तक ±20 डीबी, बिना प्रोसेस किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन के लिए, मिड-फ़्रीक्वेंसी रेंज की तुलना में.
[C-1-4] इसमें ज़्यादा फ़्रीक्वेंसी रेंज में ऐम्प्लिट्यूड लेवल दिखना चाहिए: खास तौर पर, 7,000 हर्ट्ज़ से 22 किलोहर्ट्ज़ तक, ±30 डीबी की रेंज में. इसकी तुलना, बिना प्रोसेस किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन की मिड-फ़्रीक्वेंसी रेंज से की जाती है.
[C-1-5] ऑडियो इनपुट की सेंसिटिविटी को इस तरह से सेट किया जाना चाहिए कि 94 dB साउंड प्रेशर लेवल (एसपीएल) पर चलाए गए 1000 हर्ट्ज़ के साइनसोडल टोन सोर्स से, 16 बिट-सैंपल के लिए 520 का आरएमएस (या फ़्लोटिंग पॉइंट/डबल प्रिसिशन सैंपल के लिए -36 dB फ़ुल स्केल) वाला रिस्पॉन्स मिले. ऐसा हर उस माइक्रोफ़ोन के लिए होना चाहिए जिसका इस्तेमाल बिना प्रोसेस किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए किया जाता है.
[C-1-6] बिना प्रोसेस किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन के लिए, सिग्नल-टू-नॉइज़ रेशियो (एसएनआर) 60 डीबी या इससे ज़्यादा होना चाहिए. (जबकि एसएनआर को 94 dB एसपीएल और सेल्फ़ नॉइज़ के बराबर एसपीएल के बीच के अंतर के तौर पर मापा जाता है, जिसे A-वेटेड किया जाता है).
[C-1-7] बिना प्रोसेस किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन के लिए, 90 dB एसपीएल इनपुट लेवल पर 1 kHZ के लिए, टोटल हार्मोनिक डिस्टॉर्शन (टीएचडी) 1% से कम होना चाहिए.
पाथ में लेवल मल्टीप्लायर के अलावा, कोई अन्य सिग्नल प्रोसेसिंग (जैसे, ऑटोमैटिक गेन कंट्रोल, हाई पास फ़िल्टर या नॉइज़ कैंसलेशन) नहीं होनी चाहिए, ताकि लेवल को मनचाही रेंज में लाया जा सके. दूसरे शब्दों में:
[C-1-8] अगर किसी वजह से आर्किटेक्चर में कोई सिग्नल प्रोसेसिंग मौजूद है, तो उसे बंद किया जाना चाहिए. साथ ही, सिग्नल पाथ में कोई देरी या अतिरिक्त इंतज़ार का समय नहीं होना चाहिए.
[C-1-9] लेवल मल्टीप्लायर को पाथ पर इस्तेमाल करने की अनुमति है. हालांकि, इससे सिग्नल पाथ में देरी या लेटेन्सी नहीं होनी चाहिए.

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

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

[C-2-1] AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) एपीआई तरीके के लिए null को वापस भेजना ज़रूरी है, ताकि यह सही तरीके से पता चल सके कि यह सुविधा काम नहीं करती.
[SR] अब भी यह सुझाव दिया जाता है कि बिना प्रोसेस किए गए रिकॉर्डिंग सोर्स के सिग्नल पाथ की ज़्यादा से ज़्यादा ज़रूरी शर्तों को पूरा किया जाए.

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

6.1. डेवलपर टूल

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

[C-0-1] Android SDK में दिए गए Android डेवलपर टूल के साथ काम करना ज़रूरी है.
Android Debug Bridge (adb)
- [C-0-2] Android SDK में दिए गए दस्तावेज़ और AOSP में दी गई शेल कमांड के मुताबिक, adb का इस्तेमाल किया जा सकता है. इनका इस्तेमाल ऐप्लिकेशन डेवलपर कर सकते हैं. इनमें dumpsys cmd stats भी शामिल है
- [C-0-11] शेल कमांड cmd testharness के साथ काम करना ज़रूरी है. अगर किसी डिवाइस को Android के पुराने वर्शन से अपग्रेड किया गया है और उसमें डेटा ब्लॉक करने की सुविधा मौजूद नहीं है, तो हो सकता है कि उसे C-0-11 से छूट मिल जाए.
- [C-0-3] dumpsys कमांड के ज़रिए लॉग किए गए डिवाइस सिस्टम इवेंट (batterystats , diskstats, fingerprint, graphicsstats, netstats, notification, procstats) के फ़ॉर्मैट या कॉन्टेंट में बदलाव नहीं किया जाना चाहिए.
- [C-0-10] यह ज़रूरी है कि इन इवेंट को बिना किसी बदलाव के रिकॉर्ड किया जाए. साथ ही, इन्हें cmd stats शेल कमांड और StatsManager सिस्टम एपीआई क्लास के लिए उपलब्ध कराया जाए.
  - ActivityForegroundStateChanged
  - AnomalyDetected
  - AppBreadcrumbReported
  - AppCrashOccurred
  - AppStartOccurred
  - BatteryLevelChanged
  - BatterySaverModeStateChanged
  - BleScanResultReceived
  - BleScanStateChanged
  - ChargingStateChanged
  - DeviceIdleModeStateChanged
  - ForegroundServiceStateChanged
  - GpsScanStateChanged
  - JobStateChanged
  - PluggedStateChanged
  - ScheduledJobStateChanged
  - ScreenStateChanged
  - SyncStateChanged
  - SystemElapsedRealtime
  - UidProcessStateChanged
  - WakelockStateChanged
  - WakeupAlarmOccurred
  - WifiLockStateChanged
  - WifiMulticastLockStateChanged
  - WifiScanStateChanged
- [C-0-4] डिवाइस पर adb डेमॉन डिफ़ॉल्ट रूप से बंद होना चाहिए. साथ ही, Android Debug Bridge को चालू करने के लिए, उपयोगकर्ता के पास ऐक्सेस होना चाहिए.
- [C-0-5] सुरक्षित ए़डीबी के साथ काम करना ज़रूरी है. Android में, सुरक्षित adb की सुविधा काम करती है. Secure adb की मदद से, पुष्टि किए गए होस्ट पर adb की सुविधा चालू की जा सकती है.
- [C-0-6] ऐसा तरीका उपलब्ध कराना ज़रूरी है जिससे होस्ट मशीन से adb को कनेक्ट किया जा सके. खास तौर से:
अगर यूएसबी पोर्ट के बिना डिवाइसों में पेरिफ़ेरल मोड काम करता है, तो:
- [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 Debug Monitor Service (ddms)
- [C-0-7] यह ज़रूरी है कि डिवाइस, Android SDK में बताई गई सभी ddms सुविधाओं के साथ काम करे. डीडीएमएस, एडीबी का इस्तेमाल करता है. इसलिए, डीडीएमएस की सुविधा डिफ़ॉल्ट रूप से बंद होनी चाहिए. हालांकि, जब उपयोगकर्ता ऊपर बताए गए तरीके से Android Debug Bridge को चालू करता है, तब डीडीएमएस की सुविधा चालू होनी चाहिए.
Monkey
- [C-0-8] इसमें Monkey फ़्रेमवर्क शामिल होना चाहिए. साथ ही, इसे ऐप्लिकेशन के इस्तेमाल के लिए उपलब्ध कराना ज़रूरी है.
SysTrace
- [C-0-9] यह ज़रूरी है कि डिवाइस, Android SDK में दिए गए दस्तावेज़ के मुताबिक, systrace टूल के साथ काम करे. Systrace डिफ़ॉल्ट रूप से बंद होना चाहिए. साथ ही, Systrace को चालू करने के लिए, उपयोगकर्ता के लिए उपलब्ध एक तरीका होना चाहिए.
Perfetto
- [C-SR] शेल उपयोगकर्ता को /system/bin/perfetto बाइनरी दिखाने का सुझाव दिया जाता है. यह बाइनरी, Perfetto के दस्तावेज़ में दिए गए cmdline के मुताबिक होनी चाहिए.
- [C-SR] यह सुझाव दिया जाता है कि perfetto बाइनरी, इनपुट के तौर पर ऐसे protobuf कॉन्फ़िगरेशन को स्वीकार करे जो परफ़ेक्टो के दस्तावेज़ में तय किए गए स्कीमा के मुताबिक हो.
- [C-SR] यह सुझाव दिया जाता है कि perfetto बाइनरी, आउटपुट के तौर पर एक प्रोटोबफ़ ट्रेस लिखे. यह प्रोटोबफ़ ट्रेस, परफ़ेक्टो के दस्तावेज़ में तय किए गए स्कीमा के मुताबिक होना चाहिए.
- [C-SR] यह सुझाव दिया जाता है कि वे Perfecto के दस्तावेज़ में बताए गए डेटा सोर्स का डेटा, Perfecto बाइनरी के ज़रिए उपलब्ध कराएं.
Low Memory Killer
- [C-0-10] जब किसी ऐप्लिकेशन को Low Memory Killer बंद कर देता है, तब statsd लॉग में LMK_KILL_OCCURRED_FIELD_NUMBER ऐटम लिखना ज़रूरी है.
टेस्ट हार्नेस मोड अगर डिवाइस में सेट किए गए सिस्टम, शेल कमांड 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 के दस्तावेज़ में बताए गए तरीके से एपीआई लागू करना ज़रूरी है.

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

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

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

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

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

इस सेक्शन में दी गई ज़रूरी शर्तों में इस्तेमाल की गई इकाइयों की परिभाषा यहां दी गई है:

फ़िज़िकल डाइगोनल साइज़. डिसप्ले के उस हिस्से के दो विपरीत कोनों के बीच की दूरी (इंच में), जो रोशनी में है.
डॉट्स पर इंच (डीपीआई). यह 1 इंच की हॉरिज़ॉन्टल या वर्टिकल लाइन में मौजूद पिक्सल की संख्या होती है. जहां डीपीआई की वैल्यू दी गई हैं वहां हॉरिज़ॉन्टल और वर्टिकल, दोनों डीपीआई की वैल्यू इस रेंज में होनी चाहिए.
आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात). स्क्रीन के लंबे डाइमेंशन के पिक्सल और छोटे डाइमेंशन के पिक्सल का अनुपात. उदाहरण के लिए, 480x854 पिक्सल के डिसप्ले का आसपेक्ट रेशियो 854/480 = 1.779 होगा. इसे “16:9” भी कहा जा सकता है.
डेंसिटी-इंडिपेंडेंट पिक्सल (डीपी). वर्चुअल पिक्सल यूनिट को 160 डीपीआई वाली स्क्रीन के हिसाब से नॉर्मलाइज़ किया जाता है. इसे इस तरह से कैलकुलेट किया जाता है: पिक्सल = डीपी * (डेंसिटी/160).

7.1.1. स्क्रीन कॉन्फ़िगरेशन

7.1.1.1. स्क्रीन का साइज़ और शेप

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

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

[C-0-1] Android SDK के दस्तावेज़ में बताए गए तरीके के मुताबिक, Configuration.screenLayout के लिए लेआउट का सही साइज़ बताना ज़रूरी है. खास तौर पर, डिवाइसों पर लागू किए गए लॉजिकल डेंसिटी-इंडिपेंडेंट पिक्सल (डीपी) के स्क्रीन डाइमेंशन की सही जानकारी देनी होगी. जैसे:
- ऐसे डिवाइस जिनमें Configuration.uiMode की वैल्यू UI_MODE_TYPE_WATCH के अलावा कोई और वैल्यू सेट की गई है और जो Configuration.screenLayout के लिए small साइज़ की जानकारी देते हैं उनमें कम से कम 426 dp x 320 dp होना चाहिए.
- Configuration.screenLayout के लिए normal साइज़ की जानकारी देने वाले डिवाइसों में, कम से कम 480 डीपी x 320 डीपी होना चाहिए.
- Configuration.screenLayout के लिए large साइज़ की जानकारी देने वाले डिवाइसों में, कम से कम 640 dp x 480 dp होना ज़रूरी है.
- Configuration.screenLayout के लिए xlarge साइज़ की जानकारी देने वाले डिवाइसों में, कम से कम 960 डीपी x 720 डीपी होना चाहिए.
[C-0-2] Android SDK के दस्तावेज़ में बताए गए तरीके के मुताबिक, AndroidManifest.xml फ़ाइल में मौजूद <supports-screens> एट्रिब्यूट के ज़रिए, ऐप्लिकेशन के लिए स्क्रीन साइज़ के बारे में बताई गई जानकारी का सही तरीके से पालन करना ज़रूरी है.
इनमें Android के साथ काम करने वाले डिसप्ले हो सकते हैं, जिनके कोने गोल होते हैं.

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

[C-1-1] यह पक्का करना ज़रूरी है कि इनमें से कम से कम एक शर्त पूरी की गई हो:
गोल किए गए कोनों का रेडियस, 38 डीपी से कम या इसके बराबर होना चाहिए.
जब लॉजिकल डिसप्ले के हर कोने पर 15 डीपी गुणा 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 एपीआई और Configuration एपीआई के ज़रिए रिपोर्ट की गई ऊंचाई और चौड़ाई की वैल्यू से लगाया जा सकता है:

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

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

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

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

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

[C-2-1] यह ज़रूरी है कि वे OpenGL ES के मैनेज किए गए एपीआई और नेटिव एपीआई के ज़रिए, लागू किए गए किसी भी अन्य OpenGL ES एक्सटेंशन की रिपोर्ट करें. इसके उलट, यह ज़रूरी है कि वे उन एक्सटेंशन स्ट्रिंग की रिपोर्ट न करें जिनके साथ वे काम नहीं करते.
[C-2-2] EGL_KHR_image, EGL_KHR_image_base, EGL_ANDROID_image_native_buffer, EGL_ANDROID_get_native_client_buffer, EGL_KHR_wait_sync, EGL_KHR_get_all_proc_addresses, EGL_ANDROID_presentation_time, EGL_KHR_swap_buffers_with_damage, EGL_ANDROID_recordable, और EGL_ANDROID_GLES_layers एक्सटेंशन के साथ काम करना ज़रूरी है.
[C-SR] EGL_KHR_partial_update और OES_EGL_image_external एक्सटेंशन सपोर्ट करने का सुझाव दिया जाता है.
उन्हें getString() तरीके का इस्तेमाल करके, टेक्सचर कंप्रेस करने के हर उस फ़ॉर्मैट की सटीक जानकारी देनी चाहिए जिसका इस्तेमाल किया जा सकता है. आम तौर पर, यह जानकारी वेंडर के हिसाब से अलग-अलग होती है.

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

[C-3-1] libGLESv2.so लाइब्रेरी में OpenGL ES 2.0 के फ़ंक्शन सिंबल के साथ-साथ, इन वर्शन के लिए भी फ़ंक्शन सिंबल एक्सपोर्ट करने होंगे.
[SR] OES_EGL_image_external_essl3 एक्सटेंशन के साथ काम करने का सुझाव दिया जाता है.

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

[C-4-1] OpenGL ES Android Extension Pack के साथ पूरी तरह से काम करना ज़रूरी है.

अगर डिवाइस में, OpenGL ES Android Extension Pack की सभी सुविधाएं काम करती हैं, तो:

[C-5-1] android.hardware.opengles.aep फ़ीचर फ़्लैग के ज़रिए, सहायता की पहचान करना ज़रूरी है.

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

[C-6-1] EGL_ANDROID_front_buffer_auto_refresh एक्सटेंशन के साथ काम करना भी ज़रूरी है.

7.1.4.2 Vulkan

Android में Vulkan का इस्तेमाल किया जा सकता है. यह कम ओवरहेड वाला , क्रॉस-प्लैटफ़ॉर्म एपीआई है. इसका इस्तेमाल, हाई-परफ़ॉर्मेंस वाले 3D ग्राफ़िक के लिए किया जाता है.

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

[SR] Vulkan 1.1 के साथ काम करने की सुविधा शामिल करने का सुझाव दिया जाता है.

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

Vulkan 1.1 के साथ काम करना चाहिए.

Vulkan dEQP टेस्ट को कई टेस्ट लिस्ट में बांटा गया है. हर लिस्ट से कोई तारीख/वर्शन जुड़ा होता है. ये Android सोर्स ट्री में external/deqp/android/cts/main/vk-master-YYYY-MM-DD.txt पर मौजूद हैं. अगर कोई डिवाइस, 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] MUST enumerate layers, contained in native libraries named as libVkLayer*.so in the application package’s native library directory, through the Vulkan native APIs vkEnumerateInstanceLayerProperties() and vkEnumerateDeviceLayerProperties() .
[C-1-5] ऐप्लिकेशन पैकेज के बाहर की लाइब्रेरी से मिली लेयर की गिनती नहीं करनी चाहिए. इसके अलावा, Vulkan API को ट्रेस करने या इंटरसेप्ट करने के अन्य तरीके भी उपलब्ध नहीं कराने चाहिए. ऐसा तब तक नहीं करना चाहिए, जब तक ऐप्लिकेशन में android:debuggable एट्रिब्यूट को true के तौर पर सेट न किया गया हो.
[C-1-6] Vulkan नेटिव एपीआई के ज़रिए, उन सभी एक्सटेंशन स्ट्रिंग की जानकारी देना ज़रूरी है जिनके साथ काम किया जा सकता है. इसके उलट, उन एक्सटेंशन स्ट्रिंग की जानकारी नहीं देनी चाहिए जिनके साथ काम नहीं किया जा सकता.
[C-1-7] VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, और VK_KHR_incremental_present एक्सटेंशन के साथ काम करना ज़रूरी है.
[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-SR] यह सुझाव दिया जाता है कि VK_KHR_driver_properties और VK_GOOGLE_display_timing एक्सटेंशन काम करें.

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

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

अगर डिवाइस में Vulkan 1.1 के साथ काम करने की सुविधा शामिल है और Vulkan के किसी भी फ़ीचर फ़्लैग का एलान किया गया है, तो:

[C-3-1] SYNC_FD एक्सटर्नल सेमाफ़ोर और हैंडल टाइप के साथ-साथ VK_ANDROID_external_memory_android_hardware_buffer एक्सटेंशन के लिए काम की जानकारी देना ज़रूरी है.

7.1.4.3 RenderScript

[C-0-1] डिवाइसों में Android RenderScript की सुविधा होनी चाहिए. इसके बारे में Android SDK के दस्तावेज़ में बताया गया है.

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

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

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

[C-0-1] हार्डवेयर से तेज़ी लाने की सुविधा डिफ़ॉल्ट रूप से चालू होनी चाहिए. साथ ही, अगर डेवलपर android:hardwareAccelerated="false” को सेट करके या Android View API के ज़रिए हार्डवेयर से तेज़ी लाने की सुविधा को सीधे तौर पर बंद करने का अनुरोध करता है, तो उसे बंद कर देना चाहिए.
[C-0-2] इसका व्यवहार, हार्डवेयर ऐक्सेलरेटेड रेंडरिंग के बारे में Android SDK के दस्तावेज़ में बताए गए व्यवहार के मुताबिक होना चाहिए.

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

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

[C-0-3] इसमें TextureView API काम करना चाहिए. साथ ही, यह अपस्ट्रीम Android के साथ काम करने के तरीके के मुताबिक होना चाहिए.

7.1.4.5 वाइड-गैमट डिसप्ले

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

[C-1-1] में कलर-कैलिब्रेटेड डिसप्ले होना ज़रूरी है.
[C-1-2] डिवाइस में ऐसा डिसप्ले होना चाहिए जिसका गैमट, CIE 1931 xyY स्पेस में sRGB कलर गैमट को पूरी तरह से कवर करता हो.
[C-1-3] इसमें ऐसा डिसप्ले होना चाहिए जिसका गैमट, CIE 1931 xyY स्पेस में DCI-P3 के कम से कम 90% हिस्से को कवर करता हो.
[C-1-4] OpenGL ES 3.1 या 3.2 के साथ काम करना ज़रूरी है. साथ ही, इसकी जानकारी सही तरीके से देनी होगी.
[C-1-5] EGL_KHR_no_config_context, EGL_EXT_pixel_format_float, EGL_KHR_gl_colorspace, EGL_EXT_gl_colorspace_scrgb, EGL_EXT_gl_colorspace_scrgb_linear, EGL_EXT_gl_colorspace_display_p3, EGL_EXT_gl_colorspace_display_p3_linear, और EGL_EXT_gl_colorspace_display_p3_passthrough एक्सटेंशन के लिए सहायता उपलब्ध कराने का विज्ञापन दिखाना ज़रूरी है.
[C-SR] GL_EXT_sRGB का इस्तेमाल करने का सुझाव दिया जाता है.

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

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

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

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

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

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

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

[C-0-1] ज़रूरी है कि 16-बिट कलर ग्राफ़िक रेंडर कर सके.
इसमें 24-बिट कलर ग्राफ़िक्स दिखाने वाले डिसप्ले काम करने चाहिए.
[C-0-2] ऐनिमेशन रेंडर करने में सक्षम होना चाहिए.
[C-0-3] पिक्सल आसपेक्ट रेशियो (पीएआर) 0.9 और 1.15 के बीच होना चाहिए. इसका मतलब है कि पिक्सल का आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) स्क्वेयर (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-की) में से किसी एक से मेल न खाता हो. * इसमें सॉफ़्ट कीबोर्ड को लागू करने की अन्य सुविधाएं शामिल होनी चाहिए. * इसमें हार्डवेयर कीबोर्ड शामिल हो सकता है.

7.2.2. बिना छुए नेविगेट करने की सुविधा

Android में, बिना टच किए नेविगेट करने के लिए डी-पैड, ट्रैकबॉल, और व्हील का इस्तेमाल किया जा सकता है.

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

[C-0-1] android.content.res.Configuration.navigation के लिए सही वैल्यू रिपोर्ट करना ज़रूरी है.

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

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

7.2.3. मार्गदर्शक कुंजियां

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

[C-0-1] टीवी डिवाइसों पर लागू होने वाले ऐप्लिकेशन के लिए, यह ज़रूरी है कि इंस्टॉल किए गए ऐसे ऐप्लिकेशन को लॉन्च करने की सुविधा दी जाए जिनमें <intent-filter> को ACTION=MAIN और CATEGORY=LAUNCHER या CATEGORY=LEANBACK_LAUNCHER के साथ सेट किया गया हो. इस सुविधा को चालू करने के लिए, होम फ़ंक्शन का इस्तेमाल किया जाना चाहिए.
इसमें हाल ही में इस्तेमाल किए गए आइटम और वापस जाने के लिए बटन होने चाहिए.

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

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

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

[SR] हमारा सुझाव है कि मेन्यू फ़ंक्शन के लिए इनपुट मैकेनिज़्म उपलब्ध न कराएं, क्योंकि Android 4.0 से इसे ऐक्शन बार के लिए बंद कर दिया गया है.

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

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

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

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

अगर डिवाइस में 'ठीक है Google' या असिस्टेंट से पूछें सुविधा उपलब्ध है, तो:

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

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

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

[C-6-1] WindowInsets#getMandatorySystemGestureInsets() का इस्तेमाल, सिर्फ़ होम जेस्चर की पहचान करने वाले एरिया की जानकारी देने के लिए किया जाना चाहिए.
[C-6-2] View#setSystemGestureExclusionRects() के ज़रिए फ़ोरग्राउंड ऐप्लिकेशन से मिले एक्सक्लूज़न रेक्ट के अंदर शुरू होने वाले जेस्चर, लेकिन WindowInsets#getMandatorySystemGestureInsets() के बाहर होने वाले जेस्चर को नेविगेशन फ़ंक्शन के लिए इंटरसेप्ट नहीं किया जाना चाहिए. ऐसा तब तक नहीं किया जाना चाहिए, जब तक एक्सक्लूज़न रेक्ट को View#setSystemGestureExclusionRects() के दस्तावेज़ में बताई गई एक्सक्लूज़न की ज़्यादा से ज़्यादा सीमा के अंदर अनुमति मिली हो.
[C-6-3] अगर फ़ोरग्राउंड ऐप्लिकेशन को पहले MotionEvent.ACTION_DOWN इवेंट भेजा गया था, तो सिस्टम के जेस्चर के लिए टच इंटरसेप्ट किए जाने पर, फ़ोरग्राउंड ऐप्लिकेशन को MotionEvent.ACTION_CANCEL इवेंट भेजना ज़रूरी है.
[C-6-4] इसमें, उपयोगकर्ता को स्क्रीन पर मौजूद बटन के ज़रिए नेविगेट करने की सुविधा उपलब्ध होनी चाहिए. उदाहरण के लिए, सेटिंग में.
स्क्रीन के मौजूदा ओरिएंटेशन में, सबसे नीचे के किनारे से ऊपर की ओर स्वाइप करने पर, होम फ़ंक्शन चालू होना चाहिए.
उन्हें होम जेस्चर वाली जगह से, ऊपर की ओर स्वाइप करके रिलीज़ करने से पहले, रीसेंट ऐप्लिकेशन फ़ंक्शन उपलब्ध कराना चाहिए.
WindowInsets#getMandatorySystemGestureInsets() के अंदर शुरू होने वाले जेस्चर पर, फ़ोरग्राउंड ऐप्लिकेशन की ओर से View#setSystemGestureExclusionRects() के ज़रिए दिए गए एक्सक्लूज़न रेक्ट का असर नहीं पड़ना चाहिए.

अगर स्क्रीन के मौजूदा ओरिएंटेशन के हिसाब से, बाएं और दाएं किनारों पर नेविगेशन फ़ंक्शन उपलब्ध है, तो:

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

अगर डिवाइस में, Android के साथ काम करने वाले प्राइमरी डिसप्ले पर इनपुट देने के लिए, माउस या ट्रैकबॉल जैसे बाहरी इनपुट डिवाइस का इस्तेमाल किया जाता है (यानी कि सीधे तौर पर स्क्रीन को नहीं छुआ जाता है) और वे सेक्शन 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] में, एचआईडी इवेंट को नीचे दी गई टेबल में दिए गए 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)
Home¹	0x0c 0x0223	KEYCODE_HOME (3)
वापस जाएं¹	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

1 MotionEvent

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

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

7.3. सेंसर

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

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

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

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

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

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

[C-1-6] सभी सेंसर के लिए, रिज़ॉल्यूशन को शून्य से ज़्यादा पर सेट करना ज़रूरी है. साथ ही, Sensor.getResolution() एपीआई तरीके से वैल्यू रिपोर्ट करना ज़रूरी है.

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

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

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

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

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

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

[C-3-1] सेंसर के लिए रिज़ॉल्यूशन को 1 पर सेट करना ज़रूरी है. साथ ही, Sensor.getResolution() API के तरीके से वैल्यू की जानकारी देना ज़रूरी है.

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

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

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

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

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

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

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

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

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

अगर डिवाइस में 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] TYPE_GAME_ROTATION_VECTOR कंपोज़िट सेंसर को लागू करने का सुझाव दिया जाता है.

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

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

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

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

[C-SR] इनमें 3-ऐक्सिस मैग्नेटोमीटर (कंपास) शामिल करने का सुझाव दिया जाता है.

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

[C-1-1] TYPE_MAGNETIC_FIELD सेंसर का होना ज़रूरी है.
[C-1-2] इवेंट की रिपोर्टिंग कम से कम 10 हर्ट्ज़ की फ़्रीक्वेंसी पर की जानी चाहिए. साथ ही, इवेंट की रिपोर्टिंग कम से कम 50 हर्ट्ज़ की फ़्रीक्वेंसी पर की जानी चाहिए.
[C-1-3] Android API में बताए गए Android सेंसर कोऑर्डिनेट सिस्टम का पालन करना ज़रूरी है.
[C-1-4] हर ऐक्सिस पर, मैग्नेटिक फ़ील्ड के सैचुरेट होने से पहले -900 µT से +900 µT के बीच मेज़रमेंट करने में सक्षम होना चाहिए.
[C-1-5] मैग्नेटोमीटर को डाइनैमिक (करंट की वजह से पैदा होने वाले) और स्टैटिक (मैग्नेट की वजह से पैदा होने वाले) मैग्नेटिक फ़ील्ड से दूर रखकर, हार्ड आयरन ऑफ़सेट वैल्यू को 700 µT से कम रखना ज़रूरी है. साथ ही, इसे 200 µT से कम रखना चाहिए.
[C-1-6] इसका रिज़ॉल्यूशन 0.6 µT के बराबर या इससे ज़्यादा होना चाहिए.
[C-1-7] हार्ड आयरन बायस के ऑनलाइन कैलिब्रेशन और कंपंसेशन की सुविधा होनी चाहिए. साथ ही, डिवाइस रीबूट होने पर भी कंपंसेशन पैरामीटर बने रहने चाहिए.
[C-1-8] इसमें सॉफ़्ट आयरन कंपनसेशन लागू होना चाहिए. डिवाइस के इस्तेमाल के दौरान या उसके प्रोडक्शन के दौरान कैलिब्रेशन किया जा सकता है.
[C-1-9] इसमें स्टैंडर्ड डेविएशन होना चाहिए. इसे हर ऐक्सिस के हिसाब से, सबसे तेज़ सैंपलिंग रेट पर कम से कम तीन सेकंड तक इकट्ठा किए गए सैंपल के आधार पर कैलकुलेट किया जाता है. यह 1.5 µT से ज़्यादा नहीं होना चाहिए. इसमें स्टैंडर्ड डेविएशन 0.5 µT से ज़्यादा नहीं होना चाहिए.
[C-SR] 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 mW से कम बिजली की खपत करनी चाहिए.

7.3.3. जीपीएस

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

[C-SR] इनमें जीपीएस/जीएनएसएस रिसीवर शामिल करने का सुझाव दिया जाता है.

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

[C-1-1] LocationManager#requestLocationUpdate के ज़रिए अनुरोध किए जाने पर, जगह की जानकारी के आउटपुट के साथ, कम से कम 1 हर्ट्ज़ की दर से काम करना चाहिए.
[C-1-2] खुले आसमान वाली जगहों (मज़बूत सिग्नल, न के बराबर मल्टीपाथ, HDOP < 2) में, 0.5 एमबीपीएस या इससे ज़्यादा डेटा स्पीड वाले इंटरनेट कनेक्शन से कनेक्ट होने पर, 10 सेकंड के अंदर जगह की जानकारी का पता लगाना ज़रूरी है (पहली बार जगह की जानकारी का पता लगाने में कम समय लगना). आम तौर पर, इस ज़रूरत को पूरा करने के लिए, किसी तरह की असिस्टेड या अनुमानित जीपीएस/जीएनएसएस तकनीक का इस्तेमाल किया जाता है. इससे जीपीएस/जीएनएसएस लॉक-ऑन टाइम को कम किया जा सकता है. सहायता डेटा में रेफ़रंस टाइम, रेफ़रंस लोकेशन, और सैटेलाइट एफ़ेमेरिस/क्लॉक शामिल होती है.
- [C-1-6] जगह की जानकारी का पता लगाने के बाद, डिवाइसों को खुले आसमान वाली जगहों में पांच सेकंड के अंदर, जगह की जानकारी का पता लगाना ज़रूरी है. यह जानकारी, पिछली बार जगह की जानकारी मिलने के एक घंटे बाद तक की होगी. भले ही, यह अनुरोध डेटा कनेक्शन के बिना और/or डिवाइस बंद करके फिर चालू करने के बाद भेजा गया हो.
जगह की जानकारी का पता लगाने के बाद, खुले आसमान वाली जगहों में, जब वाहन रुका हो या उसका ऐक्सलरेशन एक मीटर प्रति सेकंड स्क्वेयर्ड से कम हो, तब:
- [C-1-3] कम से कम 95% समय में, 20 मीटर के दायरे तक जगह की जानकारी का पता लगाना और 0.5 मीटर प्रति सेकंड की स्पीड का पता लगाना ज़रूरी है.
- [C-1-4] एक ही कॉन्स्टलेशन के कम से कम आठ सैटलाइट को एक साथ ट्रैक करना और GnssStatus.Callback के ज़रिए उनकी जानकारी देना ज़रूरी है.
- अलग-अलग कॉन्स्टलेशन के कम से कम 24 सैटलाइट एक साथ ट्रैक करने चाहिए. जैसे, जीपीएस और Glonass, Beidou, Galileo में से कोई एक.
- [C-SR] आपातकालीन फ़ोन कॉल के दौरान, GNSS Location Provider API के ज़रिए सामान्य GPS/GNSS लोकेशन आउटपुट देने का सुझाव दिया जाता है.
- [C-SR] एसबीएएस को अपवाद मानकर, ट्रैक किए गए सभी कॉन्स्टलेशन (इनके बारे में GnssStatus मैसेज में बताया गया है) से जीएनएसएस के मेज़रमेंट की जानकारी देने का सुझाव दिया जाता है.
- [C-SR] एजीसी और जीएनएसएस मेज़रमेंट की फ़्रीक्वेंसी की जानकारी देने का सुझाव दिया जाता है.
- [C-SR] हर जीपीएस/जीएनएसएस की जगह की जानकारी के हिस्से के तौर पर, सभी सटीक अनुमानों के बारे में बताने का सुझाव दिया जाता है. इनमें बियरिंग, स्पीड, और वर्टिकल शामिल हैं.
- [C-SR] जीएनएसएस मेज़रमेंट की जानकारी मिलते ही उसे रिपोर्ट करने का सुझाव दिया जाता है. भले ही, जीपीएस/जीएनएसएस से कैलकुलेट की गई जगह की जानकारी अब तक न दी गई हो.
- [C-SR] GNSS की स्यूडोरेंज और स्यूडोरेंज रेट की जानकारी देने का सुझाव दिया जाता है. खुले आसमान वाली जगहों में, जगह की जानकारी का पता लगाने के बाद, जब वाहन रुका हुआ हो या 0.2 मीटर प्रति सेकंड स्क्वेयर से कम ऐक्सलरेशन के साथ चल रहा हो, तब कम से कम 95% समय में, 20 मीटर के दायरे तक जगह की जानकारी और 0.2 मीटर प्रति सेकंड की स्पीड का पता लगाया जा सकता है.

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

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

[C-SR] इनमें जाइरोस्कोप सेंसर शामिल करने का सुझाव दिया जाता है.

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

[C-1-1] कम से कम 50 हर्ट्ज़ की फ़्रीक्वेंसी तक इवेंट रिपोर्ट करने की सुविधा होनी चाहिए.
[C-1-2] TYPE_GYROSCOPE सेंसर को लागू करना ज़रूरी है. साथ ही, TYPE_GYROSCOPE_UNCALIBRATED सेंसर को भी लागू करने का सुझाव दिया जाता है.
[C-1-4] इसका रिज़ॉल्यूशन 12 बिट या इससे ज़्यादा होना चाहिए. साथ ही, इसका रिज़ॉल्यूशन 16 बिट या इससे ज़्यादा होना चाहिए.
[C-1-5] तापमान के हिसाब से सही होना चाहिए.
[C-1-6] इसका इस्तेमाल करते समय, इसे कैलिब्रेट और कंपंसेट किया जाना चाहिए. साथ ही, डिवाइस को रीबूट करने पर भी कंपंसेशन पैरामीटर बने रहने चाहिए.
[C-1-7] इसमें हर हर्ट्ज़ के हिसाब से, 1e-7 rad^2 / s^2 से ज़्यादा अंतर नहीं होना चाहिए (हर हर्ट्ज़ के हिसाब से अंतर या rad^2 / s). सैंपलिंग रेट के हिसाब से वैरियंस में बदलाव किया जा सकता है. हालांकि, यह वैल्यू से कम होना चाहिए. दूसरे शब्दों में, अगर 1 हर्ट्ज़ की सैंपलिंग दर पर गायरो के वैरिएंस को मेज़र किया जाता है, तो यह 1e-7 rad^2/s^2 से ज़्यादा नहीं होना चाहिए.
[SR] यह सुझाव दिया जाता है कि जब डिवाइस कमरे के तापमान पर स्थिर हो, तब कैलिब्रेशन की गड़बड़ी 0.01 रेडियन/सेकंड से कम होनी चाहिए.
कम से कम 200 हर्ट्ज़ तक के इवेंट रिपोर्ट करने चाहिए.

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

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

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

7.3.5. बैरोमीटर

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

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

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

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

7.3.6. Thermometer

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

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

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

[C-2-1] तापमान मापने वाले सेंसर के लिए, SENSOR_TYPE_AMBIENT_TEMPERATURE को तय नहीं किया जाना चाहिए.

7.3.7. फ़ोटोमीटर

डिवाइस में फ़ोटोमीटर (स्क्रीन की रोशनी को अपने-आप घटाने-बढ़ाने वाला सेंसर) शामिल हो सकता है.

7.3.8. निकटता सेंसर

डिवाइस में प्रॉक्सिमिटी सेंसर शामिल हो सकता है.

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

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

7.3.9. हाई फ़िडेलिटी सेंसर

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

[C-1-1] android.hardware.sensor.hifi_sensors फ़ीचर फ़्लैग के ज़रिए, सुविधा की पहचान करना ज़रूरी है.

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

[C-2-1] डिवाइस में TYPE_ACCELEROMETER सेंसर होना ज़रूरी है. यह सेंसर:
- यह ज़रूरी है कि ऐक्सिलरोमीटर की मेज़रमेंट रेंज कम से कम -8g और +8g के बीच हो. हालांकि, हमारा सुझाव है कि मेज़रमेंट रेंज कम से कम -16g और +16g के बीच हो.
- इसका मेज़रमेंट रिज़ॉल्यूशन कम से कम 2048 एलएसबी/ग्राम होना चाहिए.
- मेज़रमेंट की फ़्रीक्वेंसी कम से कम 12.5 हर्ट्ज़ या इससे कम होनी चाहिए.
- मेज़रमेंट की फ़्रीक्वेंसी ज़्यादा से ज़्यादा 400 हर्ट्ज़ या इससे ज़्यादा होनी चाहिए; इसमें SensorDirectChannel RATE_VERY_FAST काम करना चाहिए.
- मेज़रमेंट नॉइज़ 400 μg/√Hz से ज़्यादा नहीं होना चाहिए.
- इस सेंसर के लिए, नॉन-वेक-अप फ़ॉर्म को लागू करना ज़रूरी है. साथ ही, इसमें कम से कम 3,000 सेंसर इवेंट को बफ़र करने की सुविधा होनी चाहिए.
- बैटरी की खपत 3 mW से ज़्यादा नहीं होनी चाहिए.
- [C-SR] में, नाइक्विस्ट फ़्रीक्वेंसी के कम से कम 80% के 3dB मेज़रमेंट बैंडविड्थ और इस बैंडविड्थ में व्हाइट नॉइज़ स्पेक्ट्रम का होना ज़रूरी है.
- इसमें कमरे के तापमान पर, 30 μg √Hz से कम ऐक्सलरेशन रैंडम वॉक होना चाहिए.
- तापमान के हिसाब से, इसमें ≤ +/- 1 मि॰ग्रा॰/°C का बदलाव होना चाहिए.
- इसमें सबसे सही फ़िटिंग वाली लाइन की नॉन-लीनियरिटी ≤ 0.5% होनी चाहिए. साथ ही, तापमान के हिसाब से संवेदनशीलता में बदलाव ≤ 0.03%/C° होना चाहिए.
- इसमें क्रॉस-ऐक्सिस सेंसिटिविटी < 2.5 % होनी चाहिए. साथ ही, डिवाइस के ऑपरेटिंग तापमान की रेंज में क्रॉस-ऐक्सिस सेंसिटिविटी में बदलाव < 0.2% होना चाहिए.
[C-2-2] में TYPE_ACCELEROMETER_UNCALIBRATED होना चाहिए. इसकी क्वालिटी से जुड़ी शर्तें, TYPE_ACCELEROMETER के जैसी ही होनी चाहिए.
[C-2-3] डिवाइस में TYPE_GYROSCOPE सेंसर होना ज़रूरी है. यह सेंसर:
- मेज़रमेंट की रेंज कम से कम -1000 और +1000 dps के बीच होनी चाहिए.
- इसका मेज़रमेंट रिज़ॉल्यूशन कम से कम 16 एलएसबी/डीपीएस होना चाहिए.
- मेज़रमेंट की फ़्रीक्वेंसी कम से कम 12.5 हर्ट्ज़ या इससे कम होनी चाहिए.
- मेज़रमेंट की फ़्रीक्वेंसी ज़्यादा से ज़्यादा 400 हर्ट्ज़ या इससे ज़्यादा होनी चाहिए; इसमें SensorDirectChannel RATE_VERY_FAST काम करना चाहिए.
- मेज़रमेंट नॉइज़ 0.014°/s/√Hz से ज़्यादा नहीं होना चाहिए.
- [C-SR] में, नाइक्विस्ट फ़्रीक्वेंसी के कम से कम 80% के 3dB मेज़रमेंट बैंडविड्थ और इस बैंडविड्थ में व्हाइट नॉइज़ स्पेक्ट्रम का होना ज़रूरी है.
- कमरे के तापमान पर जांच करने पर, रेट रैंडम वॉक 0.001 °/s √Hz से कम होना चाहिए.
- तापमान के हिसाब से, बायस में बदलाव ≤ +/- 0.05 °/ s / °C होना चाहिए.
- तापमान में ≤ 0.02% / °C के हिसाब से बदलाव होने पर, संवेदनशीलता में बदलाव होना चाहिए.
- इसमें सबसे सही फ़िट वाली लाइन की नॉन-लीनियरिटी ≤ 0.2% होनी चाहिए.
- इसमें नॉइज़ डेंसिटी ≤ 0.007 °/s/√Hz होनी चाहिए.
- डिवाइस के स्थिर होने पर, तापमान 10 ~ 40 ℃ के बीच कैलिब्रेशन की गड़बड़ी 0.002 रेडियन/सेकंड से कम होनी चाहिए.
- इसमें 0.1°/s/g से कम की g-सेंसिटिविटी होनी चाहिए.
- डिवाइस के ऑपरेटिंग तापमान की रेंज में, क्रॉस-ऐक्सिस की संवेदनशीलता 4.0 % से कम होनी चाहिए और क्रॉस-ऐक्सिस की संवेदनशीलता में बदलाव 0.3% से कम होना चाहिए.
[C-2-4] इसमें TYPE_GYROSCOPE_UNCALIBRATED होना चाहिए. साथ ही, इसकी क्वालिटी से जुड़ी शर्तें TYPE_GYROSCOPE के जैसी होनी चाहिए.
[C-2-5] डिवाइस में TYPE_GEOMAGNETIC_FIELD सेंसर होना ज़रूरी है. साथ ही, यह भी ज़रूरी है कि:
- ज़रूरी है कि इसकी मेज़रमेंट रेंज, कम से कम -900 और +900 μT के बीच हो.
- इसका मेज़रमेंट रिज़ॉल्यूशन कम से कम 5 LSB/uT होना चाहिए.
- मेज़रमेंट की फ़्रीक्वेंसी कम से कम 5 हर्ट्ज़ या इससे कम होनी चाहिए.
- मेज़रमेंट की फ़्रीक्वेंसी ज़्यादा से ज़्यादा 50 हर्ट्ज़ या इससे ज़्यादा होनी चाहिए.
- इसमें मेज़रमेंट नॉइज़ 0.5 uT से ज़्यादा नहीं होना चाहिए.
[C-2-6] में TYPE_MAGNETIC_FIELD_UNCALIBRATED एट्रिब्यूट की वैल्यू, TYPE_GEOMAGNETIC_FIELD एट्रिब्यूट की वैल्यू के लिए तय की गई क्वालिटी की शर्तों के मुताबिक होनी चाहिए. साथ ही:
- इस सेंसर के नॉन-वेक-अप फ़ॉर्म को लागू करना ज़रूरी है. साथ ही, इसमें कम से कम 600 सेंसर इवेंट को बफ़र करने की सुविधा होनी चाहिए.
- [C-SR] अगर रिपोर्टिंग की दर 50 हर्ट्ज़ या इससे ज़्यादा है, तो 1 हर्ट्ज़ से कम से कम 10 हर्ट्ज़ तक के फ़्रीक्वेंसी स्पेक्ट्रम में वाइट नॉइज़ होना ज़रूरी है.
[C-2-7] TYPE_PRESSURE सेंसर का होना ज़रूरी है. साथ ही, यह ज़रूरी है कि:
- इसका मेज़रमेंट रेंज कम से कम 300 और 1100 hPa के बीच होनी चाहिए.
- इसका मेज़रमेंट रिज़ॉल्यूशन कम से कम 80 एलएसबी/एचपीए होना चाहिए.
- मेज़रमेंट की फ़्रीक्वेंसी कम से कम 1 हर्ट्ज़ या इससे कम होनी चाहिए.
- मेज़रमेंट की फ़्रीक्वेंसी ज़्यादा से ज़्यादा 10 हर्ट्ज़ या इससे ज़्यादा होनी चाहिए.
- मेज़रमेंट नॉइज़ 2 Pa/√Hz से ज़्यादा नहीं होना चाहिए.
- इस सेंसर के नॉन-वेक-अप फ़ॉर्म को लागू करना ज़रूरी है. साथ ही, इसमें कम से कम 300 सेंसर इवेंट को बफ़र करने की सुविधा होनी चाहिए.
- इसमें 2 mW से ज़्यादा बिजली की खपत नहीं होनी चाहिए.
[C-2-8] डिवाइस में TYPE_GAME_ROTATION_VECTOR सेंसर होना ज़रूरी है.
[C-2-9] डिवाइस में TYPE_SIGNIFICANT_MOTION सेंसर होना ज़रूरी है. यह सेंसर:
- डिवाइस के स्थिर होने पर, बिजली की खपत 0.5 मि॰वॉ॰ से ज़्यादा नहीं होनी चाहिए. वहीं, डिवाइस के मूव होने पर, बिजली की खपत 1.5 मि॰वॉ॰ से ज़्यादा नहीं होनी चाहिए.
[C-2-10] डिवाइस में TYPE_STEP_DETECTOR सेंसर होना चाहिए. यह सेंसर:
- इस सेंसर के नॉन-वेक-अप फ़ॉर्म को लागू करना ज़रूरी है. साथ ही, इसमें कम से कम 100 सेंसर इवेंट को बफ़र करने की सुविधा होनी चाहिए.
- डिवाइस के स्थिर होने पर, बिजली की खपत 0.5 मि॰वॉ॰ से ज़्यादा नहीं होनी चाहिए. वहीं, डिवाइस के मूव होने पर, बिजली की खपत 1.5 मि॰वॉ॰ से ज़्यादा नहीं होनी चाहिए.
- बैटरी की खपत 4 mW से ज़्यादा नहीं होनी चाहिए.
[C-2-11] डिवाइस में TYPE_STEP_COUNTER सेंसर होना ज़रूरी है. यह सेंसर:
- डिवाइस के स्थिर होने पर, बिजली की खपत 0.5 मि॰वॉ॰ से ज़्यादा नहीं होनी चाहिए. वहीं, डिवाइस के मूव होने पर, बिजली की खपत 1.5 मि॰वॉ॰ से ज़्यादा नहीं होनी चाहिए.
[C-2-12] डिवाइस में TILT_DETECTOR सेंसर होना ज़रूरी है. यह सेंसर:
- डिवाइस के स्थिर होने पर, बिजली की खपत 0.5 मि॰वॉ॰ से ज़्यादा नहीं होनी चाहिए. वहीं, डिवाइस के मूव होने पर, बिजली की खपत 1.5 मि॰वॉ॰ से ज़्यादा नहीं होनी चाहिए.
[C-2-13] ऐक्सिलरोमीटर, जायरोस्कोप, और मैग्नेटोमीटर से रिपोर्ट किए गए एक ही फ़िज़िकल इवेंट के इवेंट टाइमस्टैंप के बीच का अंतर 2.5 मिलीसेकंड से ज़्यादा नहीं होना चाहिए. ऐक्सिलरोमीटर और जायरोस्कोप से रिपोर्ट किए गए एक ही फ़िज़िकल इवेंट का टाइमस्टैंप, एक-दूसरे से 0.25 मिलीसेकंड के अंदर होना चाहिए.
[C-2-14] इसमें जाइरोस्कोप सेंसर इवेंट के टाइमस्टैंप, कैमरा सबसिस्टम के टाइम बेस के बराबर होने चाहिए. साथ ही, इनमें एक मिलीसेकंड से ज़्यादा का अंतर नहीं होना चाहिए.
[C-2-15] ऐप्लिकेशन को सैंपल, पांच मिलीसेकंड के अंदर डिलीवर किए जाने चाहिए. यह समय, ऐप्लिकेशन को ऊपर दिए गए किसी भी फ़िज़िकल सेंसर पर डेटा उपलब्ध होने के समय से गिना जाएगा.
[C-2-16] जब डिवाइस स्थिर हो, तब उसकी बिजली की खपत 0.5 मि॰वॉ॰ से ज़्यादा नहीं होनी चाहिए. साथ ही, जब डिवाइस चल रहा हो, तब उसकी बिजली की खपत 2.0 मि॰वॉ॰ से ज़्यादा नहीं होनी चाहिए. ऐसा तब होना चाहिए, जब इनमें से किसी भी सेंसर का इस्तेमाल किया जा रहा हो:
- SENSOR_TYPE_SIGNIFICANT_MOTION
- SENSOR_TYPE_STEP_DETECTOR
- SENSOR_TYPE_STEP_COUNTER
- SENSOR_TILT_DETECTORS
[C-2-17] इसमें TYPE_PROXIMITY सेंसर हो सकता है. हालांकि, अगर यह मौजूद है, तो इसमें कम से कम 100 सेंसर इवेंट को बफ़र करने की सुविधा होनी चाहिए.

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

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

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

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

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

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

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

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

अगर डिवाइस पर, android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt, और android.provider.Settings.ACTION_BIOMETRIC_ENROLL के ज़रिए तीसरे पक्ष के ऐप्लिकेशन के लिए बायोमेट्रिक सेंसर उपलब्ध कराया जाता है, तो:

[C-4-1] इस दस्तावेज़ में बताई गई क्लास 3 या क्लास 2 की बायोमेट्रिक सुरक्षा से जुड़ी ज़रूरी शर्तों को पूरा करना ज़रूरी है.
[C-4-2] Authenticators क्लास में कॉन्स्टेंट के तौर पर तय किए गए हर पैरामीटर के नाम और उनके किसी भी कॉम्बिनेशन को पहचानना और उनका पालन करना ज़रूरी है. इसके उलट, canAuthenticate(int) और setAllowedAuthenticators(int) तरीकों को पास किए गए पूर्णांक स्थिरांकों को स्वीकार नहीं करना चाहिए. साथ ही, Authenticators में सार्वजनिक स्थिरांकों के तौर पर दस्तावेज़ में दिए गए पूर्णांक स्थिरांकों और उनके किसी भी कॉम्बिनेशन को स्वीकार नहीं करना चाहिए.
[C-4-3] जिन डिवाइसों में क्लास 3 या क्लास 2 बायोमेट्रिक की सुविधा है उन पर ACTION_BIOMETRIC_ENROLL कार्रवाई लागू करना ज़रूरी है. इस कार्रवाई में, सिर्फ़ क्लास 3 या क्लास 2 के बायोमेट्रिक के लिए, रजिस्ट्रेशन के एंट्री पॉइंट दिखाने होंगे.

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

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

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

[C-SR] यह सुझाव दिया जाता है कि हर ऑथेंटिकेशन के लिए, सिर्फ़ एक बायोमेट्रिक की पुष्टि की जाए. उदाहरण के लिए, अगर डिवाइस पर फ़िंगरप्रिंट और फ़ेस सेंसर, दोनों उपलब्ध हैं, तो onAuthenticationSucceeded को इनमें से किसी एक की पुष्टि होने के बाद भेजा जाना चाहिए.

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

[C-6-1] इस सेक्शन में बताई गई, क्लास 3 के लिए ज़रूरी शर्तों को पूरा करना ज़रूरी है.
[C-6-2] जब पुष्टि करने के लिए BIOMETRIC_STRONG की ज़रूरत हो या पुष्टि करने की प्रोसेस को CryptoObject के साथ शुरू किया गया हो, तब सिर्फ़ क्लास 3 बायोमेट्रिक्स का इस्तेमाल करना ज़रूरी है.

अगर डिवाइस में सेट किए गए सिस्टम, बायोमेट्रिक सेंसर को क्लास 1 (पहले सुविधा) के तौर पर इस्तेमाल करना चाहते हैं, तो उन्हें:

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

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

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

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

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

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

7.3.12. पोज़ सेंसर

डिवाइस में सेट किए गए सिस्टम के लिए:

इसमें 6 डिग्री ऑफ़ फ़्रीडम वाले पोज़ सेंसर की सुविधा हो सकती है.

अगर डिवाइस में 6 डिग्री ऑफ़ फ़्रीडम के साथ पोज़ सेंसर काम करता है, तो:

[C-1-1] TYPE_POSE_6DOF सेंसर को लागू करना और उसके बारे में जानकारी देना ज़रूरी है.
[C-1-2] को सिर्फ़ रोटेशन वेक्टर के मुकाबले ज़्यादा सटीक होना चाहिए.

7.3.13. हिंज ऐंगल सेंसर

अगर डिवाइस में हिंज एंगल सेंसर की सुविधा काम करती है, तो:

[C-1-1] TYPE_HINGLE_ANGLE को लागू करना और उसकी जानकारी देना ज़रूरी है.
[C-1-2] 0 से 360 डिग्री के बीच कम से कम दो रीडिंग के साथ काम करना ज़रूरी है. इसमें 0 और 360 डिग्री शामिल हैं.
[C-1-3] getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE) के लिए, wakeup सेंसर को चालू करना ज़रूरी है.

7.4. डेटा कनेक्टिविटी

7.4.1. टेलीफ़ोनी

Android API और इस दस्तावेज़ में इस्तेमाल किया गया “टेलीफ़ोनी” शब्द, खास तौर पर GSM या CDMA नेटवर्क के ज़रिए वॉइस कॉल करने और एसएमएस भेजने से जुड़े हार्डवेयर के लिए इस्तेमाल किया गया है. ये वॉइस कॉल, पैकेट-स्विच किए जा सकते हैं या नहीं भी किए जा सकते. हालांकि, Android के लिए इन्हें किसी भी डेटा कनेक्टिविटी से अलग माना जाता है. इस डेटा कनेक्टिविटी को एक ही नेटवर्क का इस्तेमाल करके लागू किया जा सकता है. दूसरे शब्दों में कहें, तो Android की “टेलीफ़ोनी” सुविधा और एपीआई, खास तौर पर वॉइस कॉल और एसएमएस के लिए होते हैं. उदाहरण के लिए, ऐसे डिवाइसों को टेलीफ़ोनी डिवाइस नहीं माना जाता है जिन पर कॉल नहीं किए जा सकते या एसएमएस नहीं भेजे/पाए जा सकते. भले ही, वे डेटा कनेक्टिविटी के लिए सेल्युलर नेटवर्क का इस्तेमाल करते हों.

Android का इस्तेमाल उन डिवाइसों पर किया जा सकता है जिनमें टेलीफ़ोनी हार्डवेयर शामिल नहीं है. इसका मतलब है कि Android, फ़ोन के अलावा अन्य डिवाइसों के साथ भी काम करता है.

अगर डिवाइसों में जीएसएम या सीडीएमए टेलीफ़ोनी शामिल है, तो:

[C-1-1] टेक्नोलॉजी के हिसाब से, android.hardware.telephony फ़ीचर फ़्लैग और अन्य सब-फ़ीचर फ़्लैग के बारे में एलान करना ज़रूरी है.
[C-1-2] उस टेक्नोलॉजी के लिए, एपीआई की पूरी सुविधा लागू करनी होगी.

अगर डिवाइसों में टेलीफ़ोनी हार्डवेयर शामिल नहीं है, तो:

[C-2-1] पूरे एपीआई को नो-ऑप्स के तौर पर लागू करना ज़रूरी है.

अगर डिवाइसों में eUICC या ई-सिम/एम्बेड किए गए सिम की सुविधा काम करती है और इसमें तीसरे पक्ष के डेवलपर के लिए ई-सिम की सुविधा उपलब्ध कराने का मालिकाना हक वाला तरीका शामिल है, तो:

[C-3-1] EuiccManager API को पूरी तरह से लागू करना ज़रूरी है.

7.4.1.1. नंबर ब्लॉक करने की सुविधा के साथ काम करने वाले डिवाइस

अगर डिवाइस में सेट किए गए सिस्टम, android.hardware.telephony feature की रिपोर्ट करते हैं, तो:

[C-1-1] MUST include number blocking support
[C-1-2] एसडीके के दस्तावेज़ में बताए गए तरीके के मुताबिक, BlockedNumberContract और उससे जुड़े एपीआई को पूरी तरह से लागू करना ज़रूरी है.
[C-1-3] ऐप्लिकेशन के साथ किसी भी तरह की बातचीत किए बिना, 'BlockedNumberProvider' में मौजूद किसी फ़ोन नंबर से आने वाले सभी कॉल और मैसेज ब्लॉक करने चाहिए. हालांकि, एसडीके के दस्तावेज़ में बताए गए तरीके से, नंबर ब्लॉक करने की सुविधा को कुछ समय के लिए बंद किया जा सकता है.
[C-1-4] ब्लॉक किए गए कॉल के लिए, कॉल लॉग की जानकारी देने वाली कंपनी को जानकारी नहीं भेजनी चाहिए.
[C-1-5] ब्लॉक किए गए मैसेज के लिए, टेलीफ़ोनी की सेवा देने वाली कंपनी को नहीं लिखना चाहिए.
[C-1-6] ब्लॉक किए गए नंबर मैनेज करने के लिए यूज़र इंटरफ़ेस (यूआई) लागू करना ज़रूरी है. इसे TelecomManager.createManageBlockedNumbersIntent() तरीके से मिले इंटेंट के साथ खोला जाता है.
[C-1-7] दूसरे क्रम के उपयोगकर्ताओं को, डिवाइस पर ब्लॉक किए गए नंबर देखने या उनमें बदलाव करने की अनुमति नहीं होनी चाहिए. ऐसा इसलिए, क्योंकि Android प्लैटफ़ॉर्म यह मानता है कि डिवाइस पर टेलीफ़ोनी सेवाओं का पूरा कंट्रोल, मुख्य उपयोगकर्ता के पास होता है. सेकंडरी उपयोगकर्ताओं के लिए, ब्लॉक करने से जुड़ा पूरा यूज़र इंटरफ़ेस (यूआई) छिपा होना चाहिए. साथ ही, ब्लॉक की गई सूची का पालन किया जाना चाहिए.
जब कोई डिवाइस Android 7.0 पर अपडेट होता है, तो ब्लॉक किए गए नंबरों को सेवा देने वाली कंपनी के पास माइग्रेट करना चाहिए.

7.4.1.2. Telecom API

अगर डिवाइसों के लिए लागू की गई सुविधाओं की रिपोर्ट android.hardware.telephony है, तो:

[C-1-1] एसडीके में बताए गए ConnectionService एपीआई काम करने चाहिए.
[C-1-2] जब उपयोगकर्ता किसी ऐसे कॉल पर हो जिसे तीसरे पक्ष के किसी ऐसे ऐप्लिकेशन से किया गया हो जो CAPABILITY_SUPPORT_HOLD के ज़रिए बताई गई होल्ड करने की सुविधा के साथ काम नहीं करता है, तो उसे नया इनकमिंग कॉल दिखना चाहिए. साथ ही, उसे इनकमिंग कॉल स्वीकार या अस्वीकार करने का विकल्प मिलना चाहिए.
[C-1-3] ज़रूरी है कि इसमें InCallService को लागू करने वाला ऐप्लिकेशन हो.
[C-SR] उपयोगकर्ता को यह सूचना देना ज़रूरी है कि इनकमिंग कॉल का जवाब देने पर, मौजूदा कॉल बंद हो जाएगी.

AOSP में इन ज़रूरी शर्तों को पूरा किया जाता है. इसके लिए, उपयोगकर्ता को एक सूचना दिखाई जाती है. इसमें बताया जाता है कि आने वाले कॉल का जवाब देने से, मौजूदा कॉल बंद हो जाएगा.
[C-SR] डिफ़ॉल्ट डायलर ऐप्लिकेशन को प्रीलोड करने का सुझाव दिया जाता है. यह ऐप्लिकेशन, कॉल लॉग एंट्री और तीसरे पक्ष के ऐप्लिकेशन का नाम दिखाता है. ऐसा तब होता है, जब तीसरे पक्ष का ऐप्लिकेशन, PhoneAccount पर EXTRA_LOG_SELF_MANAGED_CALLS एक्स्ट्रा कुंजी को true पर सेट करता है.
[C-SR] android.telecom एपीआई के लिए, ऑडियो हेडसेट के KEYCODE_MEDIA_PLAY_PAUSE और KEYCODE_HEADSETHOOK इवेंट को मैनेज करने का सुझाव दिया जाता है. इसके लिए, यहां दिया गया तरीका अपनाएं:
- कॉल चालू होने के दौरान, बटन को कम समय के लिए दबाने पर Connection.onDisconnect() को कॉल करें.
- इनकमिंग कॉल के दौरान, मुख्य इवेंट को कम समय के लिए दबाने का पता चलने पर, Connection.onAnswer() को कॉल करें.
- इनकमिंग कॉल के दौरान, मुख्य इवेंट को दबाकर रखने का पता चलने पर, Connection.onReject() को कॉल करें.
- CallAudioState के म्यूट होने की स्थिति को टॉगल करें.

7.4.2. आईईईई 802.11 (वाई-फ़ाई)

डिवाइस में सेट किए गए सिस्टम के लिए:

इसमें 802.11 के एक या उससे ज़्यादा फ़ॉर्म के लिए सहायता शामिल होनी चाहिए.

अगर डिवाइसों में 802.11 के साथ काम करने की सुविधा शामिल है और तीसरे पक्ष के ऐप्लिकेशन के लिए यह सुविधा उपलब्ध कराई जाती है, तो:

[C-1-1] Android API को लागू करना ज़रूरी है.
[C-1-2] हार्डवेयर फ़ीचर फ़्लैग android.hardware.wifi की जानकारी देना ज़रूरी है.
[C-1-3] एसडीके के दस्तावेज़ में बताए गए तरीके से, मल्टीकास्ट एपीआई को लागू करना ज़रूरी है.
[C-1-4] यह ज़रूरी है कि डिवाइस, मल्टीकास्ट डीएनएस (एमडीएनएस) के साथ काम करता हो. साथ ही, यह भी ज़रूरी है कि डिवाइस, एमडीएनएस पैकेट (224.0.0.251) को किसी भी समय फ़िल्टर न करे. जैसे:
- भले ही, स्क्रीन चालू न हो.
- Android Television डिवाइसों में, स्टैंडबाय पावर स्टेट में होने पर भी ऐसा होता है.
[C-1-5] WifiManager.enableNetwork() एपीआई के तरीके को कॉल करने को, Network को स्विच करने के लिए ज़रूरी शर्त के तौर पर नहीं माना जाना चाहिए. Network का इस्तेमाल, ऐप्लिकेशन के ट्रैफ़िक के लिए डिफ़ॉल्ट रूप से किया जाता है. साथ ही, इसे ConnectivityManager एपीआई के तरीके से वापस लाया जाता है. जैसे, getActiveNetwork और registerDefaultNetworkCallback. दूसरे शब्दों में कहें, तो वे सिर्फ़ तब इंटरनेट ऐक्सेस बंद कर सकते हैं, जब वे यह पुष्टि कर लें कि वाई-फ़ाई नेटवर्क से इंटरनेट ऐक्सेस किया जा रहा है. ऐसा तब किया जा सकता है, जब इंटरनेट सेवा देने वाली कोई अन्य कंपनी (जैसे कि मोबाइल डेटा) इंटरनेट ऐक्सेस दे रही हो.
[C-1-6] ConnectivityManager.reportNetworkConnectivity() एपीआई के तरीके को कॉल करने पर, Network पर इंटरनेट ऐक्सेस का फिर से आकलन करने का सुझाव दिया जाता है. साथ ही, आकलन से यह पता चलने पर कि मौजूदा Network अब इंटरनेट ऐक्सेस नहीं देता है, इंटरनेट ऐक्सेस देने वाले किसी अन्य उपलब्ध नेटवर्क (जैसे, मोबाइल डेटा) पर स्विच करने का सुझाव दिया जाता है.
[C-SR] जब एसटीए डिसकनेक्ट हो, तब हर स्कैन की शुरुआत में प्रोब रिक्वेस्ट के एमएसी पते और क्रम संख्या को बदलना ज़रूरी है.
- एक स्कैन के दौरान भेजे गए प्रोब रिक्वेस्ट फ़्रेम के हर ग्रुप को एक ही एमएसी पते का इस्तेमाल करना चाहिए. स्कैन के बीच में एमएसी पता नहीं बदलना चाहिए.
- प्रोब रिक्वेस्ट फ़्रेम की क्रम संख्या, स्कैन के दौरान सामान्य रूप से क्रम में बढ़ती रहनी चाहिए.
- किसी स्कैन की आखिरी प्रोब रिक्वेस्ट और अगले स्कैन की पहली प्रोब रिक्वेस्ट के बीच में क्रम संख्या को बदलते रहना चाहिए.
[C-SR] STA के डिसकनेक्ट होने पर, प्रोब अनुरोध फ़्रेम में सिर्फ़ इन एलिमेंट को शामिल करने का सुझाव दिया जाता है:
- SSID पैरामीटर सेट (0)
- DS पैरामीटर सेट (3)

अगर डिवाइस में सेट किए गए सिस्टम में, IEEE 802.11 स्टैंडर्ड में बताए गए वाई-फ़ाई पावर सेव मोड का इस्तेमाल किया जाता है, तो:

[C-3-1] जब कोई ऐप्लिकेशन WifiManager.createWifiLock() और WifiManager.WifiLock.acquire() एपीआई के ज़रिए WIFI_MODE_FULL_HIGH_PERF लॉक या WIFI_MODE_FULL_LOW_LATENCY लॉक हासिल करता है और लॉक चालू होता है, तो उसे वाई-फ़ाई के पावर सेव मोड को बंद करना होगा.
[C-3-2] जब डिवाइस वाई-फ़ाई लो लेटेंसी लॉक (WIFI_MODE_FULL_LOW_LATENCY) मोड में हो, तब डिवाइस और ऐक्सेस पॉइंट के बीच राउंड ट्रिप लेटेंसी का औसत, वाई-फ़ाई हाई परफ़ॉर्मेंस लॉक (WIFI_MODE_FULL_HIGH_PERF) मोड के दौरान होने वाली लेटेंसी से कम होना चाहिए.
[C-SR] जब भी कम देरी वाला लॉक (WIFI_MODE_FULL_LOW_LATENCY) हासिल किया जाता है और लागू होता है, तब वाई-फ़ाई राउंड ट्रिप में लगने वाले समय को कम करने के लिए, इनका इस्तेमाल करने का सुझाव दिया जाता है.

अगर डिवाइसों में वाई-फ़ाई की सुविधा काम करती है और वे जगह की जानकारी को स्कैन करने के लिए वाई-फ़ाई का इस्तेमाल करते हैं, तो:

[C-2-1] उपयोगकर्ता को WifiManager.isScanAlwaysAvailable एपीआई तरीके से पढ़ी गई वैल्यू को चालू/बंद करने की सुविधा देनी होगी.

7.4.2.1. Wi-Fi Direct

डिवाइस में सेट किए गए सिस्टम के लिए:

इसमें वाई-फ़ाई डायरेक्ट (वाई-फ़ाई पीयर-टू-पीयर) की सुविधा होनी चाहिए.

अगर डिवाइस में वाई-फ़ाई डायरेक्ट की सुविधा काम करती है, तो:

[C-1-1] एसडीके के दस्तावेज़ में बताए गए तरीके के मुताबिक, Android API को लागू करना ज़रूरी है.
[C-1-2] हार्डवेयर की सुविधा android.hardware.wifi.direct के बारे में जानकारी देना ज़रूरी है.
[C-1-3] यह ज़रूरी है कि यह डिवाइस, वाई-फ़ाई की सामान्य सुविधा के साथ काम करता हो.
[C-1-4] यह ज़रूरी है कि डिवाइस, वाई-फ़ाई और वाई-फ़ाई डायरेक्ट की सुविधाओं को एक साथ इस्तेमाल करने की अनुमति देता हो.

7.4.2.2. वाई-फ़ाई टनल किए गए डायरेक्ट लिंक का सेटअप

डिवाइस में सेट किए गए सिस्टम के लिए:

इसमें Android SDK के दस्तावेज़ में बताए गए तरीके के मुताबिक, Wi-Fi टनल वाले डायरेक्ट लिंक सेटअप (टीडीएलएस) की सुविधा शामिल होनी चाहिए.

अगर डिवाइस में TDLS की सुविधा काम करती है और WiFiManager API के ज़रिए TDLS चालू किया गया है, तो:

[C-1-1] WifiManager.isTdlsSupported के ज़रिए, TDLS के साथ काम करने की जानकारी देना ज़रूरी है.
टीडीएलएस का इस्तेमाल सिर्फ़ तब करना चाहिए, जब यह मुमकिन हो और फ़ायदेमंद हो.
इसमें कुछ अनुमानित जानकारी होनी चाहिए. साथ ही, अगर इसकी परफ़ॉर्मेंस वाई-फ़ाई ऐक्सेस पॉइंट से कनेक्ट करने पर बेहतर हो सकती है, तो इसमें टीडीएलएस का इस्तेमाल नहीं किया जाना चाहिए.

7.4.2.3. Wi-Fi Aware

डिवाइस में सेट किए गए सिस्टम के लिए:

इसमें Wi-Fi Aware की सुविधा होनी चाहिए.

अगर डिवाइसों में Wi-Fi Aware की सुविधा काम करती है और तीसरे पक्ष के ऐप्लिकेशन के लिए यह सुविधा उपलब्ध है, तो:

[C-1-1] एसडीके के दस्तावेज़ में बताए गए तरीके के मुताबिक, WifiAwareManager एपीआई लागू करना ज़रूरी है.
[C-1-2] android.hardware.wifi.aware फ़ीचर फ़्लैग के बारे में एलान करना ज़रूरी है.
[C-1-3] यह ज़रूरी है कि डिवाइस, वाई-फ़ाई और वाई-फ़ाई अवेयर की सुविधाओं को एक साथ इस्तेमाल करने की अनुमति देता हो.
[C-1-4] डिवाइस को हर 30 मिनट में, Wi-Fi Aware के मैनेजमेंट इंटरफ़ेस का पता बदलना होगा. साथ ही, जब भी Wi-Fi Aware चालू हो, तब भी उसे यह काम करना होगा. हालांकि, अगर Aware रेंजिंग ऑपरेशन चल रहा है या Aware डेटा-पाथ चालू है, तो उसे यह काम नहीं करना होगा. डेटा-पाथ चालू रहने तक, पते को बदलने की ज़रूरत नहीं होती.

अगर डिवाइसों में, सेक्शन 7.4.2.5 में बताए गए तरीके से Wi-Fi Aware और वाई-फ़ाई की मदद से जगह की जानकारी पाने की सुविधा शामिल है और ये सुविधाएं तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध हैं, तो:

[C-2-1] MUST implement the location-aware discovery APIs: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm , and onServiceDiscoveredWithinRange.

7.4.2.4. वाई-फ़ाई पासपॉइंट

अगर डिवाइस में 802.11 (वाई-फ़ाई) का इस्तेमाल किया जाता है, तो:

इसमें वाई-फ़ाई पासपॉइंट की सुविधा होनी चाहिए.

अगर डिवाइस में वाई-फ़ाई पासपॉइंट की सुविधा काम करती है, तो:

[C-1-2] एसडीके के दस्तावेज़ में बताए गए तरीके के मुताबिक, Passpoint से जुड़े WifiManager एपीआई लागू करना ज़रूरी है.
[C-1-3] डिवाइस में IEEE 802.11u स्टैंडर्ड का इस्तेमाल किया जाना चाहिए. खास तौर पर, नेटवर्क डिस्कवरी और नेटवर्क चुनने से जुड़े स्टैंडर्ड का इस्तेमाल किया जाना चाहिए. जैसे, जेनेरिक एडवर्टाइज़मेंट सर्विस (जीएएस) और ऐक्सेस नेटवर्क क्वेरी प्रोटोकॉल (एएनक्यूपी).

इसके उलट, अगर डिवाइस में वाई-फ़ाई पासपॉइंट की सुविधा काम नहीं करती है, तो:

[C-2-1] Passpoint से जुड़े WifiManager एपीआई को लागू करने पर, UnsupportedOperationException दिखना चाहिए.

7.4.2.5. वाई-फ़ाई की जगह की जानकारी (वाई-फ़ाई राउंड ट्रिप टाइम - आरटीटी)

डिवाइस में सेट किए गए सिस्टम के लिए:

इसमें वाई-फ़ाई की जगह की जानकारी की सुविधा होनी चाहिए.

अगर डिवाइसों में वाई-फ़ाई लोकेशन की सुविधा काम करती है और तीसरे पक्ष के ऐप्लिकेशन के लिए यह सुविधा उपलब्ध है, तो:

[C-1-1] एसडीके के दस्तावेज़ में बताए गए तरीके के मुताबिक, WifiRttManager एपीआई लागू करना ज़रूरी है.
[C-1-2] android.hardware.wifi.rtt फ़ीचर फ़्लैग के बारे में एलान करना ज़रूरी है.
[C-1-3] हर आरटीटी बर्स्ट के लिए, डिवाइस का एमएसी पता बदलना ज़रूरी है. ऐसा तब होता है, जब आरटीटी को उस वाई-फ़ाई इंटरफ़ेस पर लागू किया जा रहा हो जो किसी ऐक्सेस पॉइंट से नहीं जुड़ा है.

7.4.2.6. वाई-फ़ाई कीपअलाइव ऑफ़लोड

डिवाइस में सेट किए गए सिस्टम के लिए:

इसमें वाई-फ़ाई कीपअलाइव ऑफ़लोड की सुविधा होनी चाहिए.

अगर डिवाइसों में वाई-फ़ाई कीपअलाइव ऑफ़लोडिंग की सुविधा काम करती है और तीसरे पक्ष के ऐप्लिकेशन के लिए यह सुविधा उपलब्ध है, तो:

[C-1-1] SocketKeepAlive एपीआई के साथ काम करना ज़रूरी है.
[C-1-2] यह ज़रूरी है कि डिवाइस, वाई-फ़ाई पर एक साथ कम से कम तीन कीपअलाइव स्लॉट और सेल्युलर पर कम से कम एक कीपअलाइव स्लॉट के साथ काम करे.

अगर डिवाइसों में, वाई-फ़ाई कीपअलाइव ऑफ़लोड की सुविधा काम नहीं करती, तो:

[C-2-1] ERROR_UNSUPPORTED को वापस करना ज़रूरी है.

7.4.2.7. वाई-फ़ाई ईज़ी कनेक्ट (डिवाइस प्रोविज़निंग प्रोटोकॉल)

डिवाइस में सेट किए गए सिस्टम के लिए:

इसमें वाई-फ़ाई ईज़ी कनेक्ट (डीपीपी) की सुविधा होनी चाहिए.

[C-1-1] WifiManager#isEasyConnectSupported() तरीके से true वापस मिलना चाहिए.

7.4.3. ब्लूटूथ

अगर डिवाइस में ब्लूटूथ ऑडियो प्रोफ़ाइल की सुविधा काम करती है, तो:

इसमें अडवांस ऑडियो कोडेक और ब्लूटूथ ऑडियो कोडेक (जैसे, LDAC) काम करने चाहिए.

अगर डिवाइस में HFP, A2DP, और AVRCP काम करते हैं, तो:

डिवाइस में कम से कम पांच कनेक्ट किए गए डिवाइसों के साथ काम करने की सुविधा होनी चाहिए.

अगर डिवाइसों में android.hardware.vr.high_performance सुविधा का एलान किया जाता है, तो:

[C-1-1] इनमें ब्लूटूथ 4.2 और ब्लूटूथ स्मार्ट के डेटा लेंथ एक्सटेंशन की सुविधा काम करनी चाहिए.

Android में, ब्लूटूथ और ब्लूटूथ लो एनर्जी की सुविधा काम करती है.

अगर डिवाइस में ब्लूटूथ और ब्लूटूथ लो एनर्जी की सुविधा काम करती है, तो:

[C-2-1] प्लैटफ़ॉर्म की काम की सुविधाओं (क्रमशः android.hardware.bluetooth और android.hardware.bluetooth_le) के बारे में एलान करना और प्लैटफ़ॉर्म के एपीआई लागू करना ज़रूरी है.
डिवाइस के हिसाब से, काम की ब्लूटूथ प्रोफ़ाइलें लागू करनी चाहिए. जैसे, A2DP, AVRCP, OBEX, HFP वगैरह.

अगर डिवाइस में ब्लूटूथ स्मार्ट (बीएलई) टेक्नोलॉजी काम करती है, तो:

[C-3-1] हार्डवेयर की सुविधा android.hardware.bluetooth_le के बारे में एलान करना ज़रूरी है.
[C-3-2] एसडीके के दस्तावेज़ और android.bluetooth में बताए गए तरीके के मुताबिक, GATT (जेनेरिक एट्रिब्यूट प्रोफ़ाइल) पर आधारित ब्लूटूथ एपीआई को चालू करना ज़रूरी है.
[C-3-3] BluetoothAdapter.isOffloadedFilteringSupported() के लिए सही वैल्यू रिपोर्ट करना ज़रूरी है, ताकि यह पता चल सके कि ScanFilter एपीआई क्लास के लिए फ़िल्टर करने का लॉजिक लागू किया गया है या नहीं.
[C-3-4] BluetoothAdapter.isMultipleAdvertisementSupported() एट्रिब्यूट के लिए सही वैल्यू सबमिट करना ज़रूरी है, ताकि यह पता चल सके कि लो एनर्जी एडवर्टाइज़िंग की सुविधा काम करती है या नहीं.
[C-3-5] डिवाइस के लिए, हल किए जा सकने वाले निजी पते (आरपीए) के टाइमआउट को 15 मिनट से ज़्यादा नहीं रखना चाहिए. साथ ही, टाइमआउट होने पर पते को रोटेट करना चाहिए, ताकि उपयोगकर्ता की निजता की सुरक्षा की जा सके. ऐसा तब करना चाहिए, जब डिवाइस स्कैनिंग या विज्ञापन के लिए बीएलई का इस्तेमाल कर रहा हो. टाइमिंग अटैक को रोकने के लिए, टाइम आउट इंटरवल को भी 5 से 15 मिनट के बीच रैंडमाइज़ किया जाना चाहिए.
ScanFilter API लागू करते समय, फ़िल्टर करने की लॉजिक को ब्लूटूथ चिपसेट पर ऑफ़लोड करने की सुविधा होनी चाहिए.
बैटरी की खपत कम करने के लिए, ब्लूटूथ चिपसेट पर स्कैनिंग की सुविधा चालू होनी चाहिए.
इसमें कम से कम चार स्लॉट के साथ एक से ज़्यादा विज्ञापन दिखाने की सुविधा होनी चाहिए.

अगर डिवाइस में ब्लूटूथ LE की सुविधा काम करती है और जगह की जानकारी को स्कैन करने के लिए ब्लूटूथ LE का इस्तेमाल किया जाता है, तो:

[C-4-1] उपयोगकर्ता को सिस्टम एपीआई BluetoothAdapter.isBleScanAlwaysAvailable() के ज़रिए पढ़ी गई वैल्यू को चालू/बंद करने की सुविधा देनी होगी.

अगर डिवाइस में, ब्लूटूथ LE और Hearing Aids Profile के लिए सहायता शामिल है, जैसा कि ब्लूटूथ LE का इस्तेमाल करके कान की मशीन में ऑडियो की सुविधा में बताया गया है, तो:

[C-5-1] BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID) के लिए, true को वापस भेजना ज़रूरी है.

7.4.4. नियर-फ़ील्ड कम्यूनिकेशन

डिवाइस में सेट किए गए सिस्टम के लिए:

इसमें नियर-फ़ील्ड कम्यूनिकेशन (एनएफ़सी) के लिए, ट्रांसीवर और उससे जुड़ा हार्डवेयर शामिल होना चाहिए.
[C-0-1] android.nfc.NdefMessage और android.nfc.NdefRecord एपीआई को लागू करना ज़रूरी है. भले ही, उनमें एनएफ़सी की सुविधा काम न करती हो या android.hardware.nfc सुविधा का एलान न किया गया हो. ऐसा इसलिए, क्योंकि क्लास, प्रोटोकॉल से अलग डेटा प्रज़ेंटेशन फ़ॉर्मैट को दिखाती हैं.

अगर डिवाइसों में NFC हार्डवेयर शामिल है और उन्हें तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराने का प्लान है, तो:

[C-1-1] android.content.pm.PackageManager.hasSystemFeature() तरीके से, android.hardware.nfc सुविधा के बारे में जानकारी देना ज़रूरी है.
इसमें नीचे दिए गए एनएफ़सी स्टैंडर्ड के ज़रिए, एनडीईएफ़ मैसेज को पढ़ने और लिखने की सुविधा होनी चाहिए:
[C-1-2] यह डिवाइस, NFC फ़ोरम के रीडर/राइटर के तौर पर काम कर सकता हो. इसके लिए, NFC फ़ोरम की तकनीकी जानकारी NFCForum-TS-DigitalProtocol-1.0 में दिए गए इन NFC स्टैंडर्ड का इस्तेमाल किया जाता है:
- NfcA (ISO14443-3A)
- NfcB (ISO14443-3B)
- NfcF (JIS X 6319-4)
- IsoDep (ISO 14443-4)
- NFC फ़ोरम के टैग टाइप 1, 2, 3, 4, 5 (NFC फ़ोरम के हिसाब से तय किए गए)
[SR] यह सुझाव दिया जाता है कि डिवाइस में, एनएफ़सी के इन स्टैंडर्ड का इस्तेमाल करके, एनडीईएफ़ मैसेज और रॉ डेटा को पढ़ने और लिखने की सुविधा होनी चाहिए. ध्यान दें कि हालांकि, एनएफ़सी के मानकों को 'बेहद ज़रूरी' के तौर पर बताया गया है, लेकिन आने वाले समय में, साथ काम करने की परिभाषा में इन मानकों को 'ज़रूरी' के तौर पर बदला जा सकता है. इस वर्शन में इन मानकों का पालन करना ज़रूरी नहीं है. हालांकि, आने वाले वर्शन में इनका पालन करना ज़रूरी होगा. Android के इस वर्शन पर काम करने वाले मौजूदा और नए डिवाइसों को, इन ज़रूरी शर्तों को पूरा करने के लिए कहा गया है. इससे वे आने वाले समय में, प्लैटफ़ॉर्म के नए वर्शन पर अपग्रेड कर पाएंगे.
[C-1-13] NFC डिस्कवरी मोड में, डिवाइस के साथ काम करने वाली सभी टेक्नोलॉजी के लिए पोल करना ज़रूरी है.
डिवाइस के चालू होने पर, एनएफ़सी को डिस्कवरी मोड में होना चाहिए. साथ ही, स्क्रीन चालू होनी चाहिए और लॉक-स्क्रीन अनलॉक होनी चाहिए.
बारकोड और यूआरएल (अगर कोड में बदला गया है) को पढ़ने में सक्षम होना चाहिए. यह Thinfilm NFC Barcode प्रॉडक्ट के लिए ज़रूरी है.

ध्यान दें कि ऊपर बताए गए JIS, ISO, और NFC फ़ोरम के स्पेसिफ़िकेशन के लिए, सार्वजनिक तौर पर उपलब्ध लिंक मौजूद नहीं हैं.

Android में, NFC होस्ट कार्ड एम्युलेशन (एचसीई) मोड के साथ काम करने की सुविधा शामिल है.

अगर डिवाइस में, एचसीई (Nfca और/या NfcB के लिए) की सुविधा वाला एनएफ़सी कंट्रोलर चिपसेट शामिल है और ऐप्लिकेशन आईडी (एआईडी) राउटिंग की सुविधा काम करती है, तो:

[C-2-1] android.hardware.nfc.hce सुविधा के कॉन्स्टेंट की जानकारी देना ज़रूरी है.
[C-2-2] Android SDK में बताए गए NFC HCE API काम करने चाहिए.

अगर डिवाइस में NFC कंट्रोलर चिपसेट शामिल है, जो NfcF के लिए HCE की सुविधा देता है और तीसरे पक्ष के ऐप्लिकेशन के लिए इस सुविधा को लागू करता है, तो:

[C-3-1] android.hardware.nfc.hcef सुविधा के कॉन्स्टेंट की जानकारी देना ज़रूरी है.
[C-3-2] Android SDK में बताए गए NfcF कार्ड इम्यूलेशन एपीआई को लागू करना ज़रूरी है.

अगर डिवाइस में, इस सेक्शन में बताई गई सामान्य एनएफ़सी की सुविधा शामिल है और रीडर/राइटर के तौर पर MIFARE टेक्नोलॉजी (MIFARE Classic, MIFARE Ultralight, MIFARE Classic पर NDEF) काम करती है, तो:

[C-4-1] Android SDK के दस्तावेज़ में बताए गए Android API लागू करने ज़रूरी हैं.
[C-4-2] android.content.pm.PackageManager.hasSystemFeature() तरीके से, com.nxp.mifare सुविधा के बारे में बताना ज़रूरी है. ध्यान दें कि यह Android की स्टैंडर्ड सुविधा नहीं है. इसलिए, यह android.content.pm.PackageManager क्लास में कॉन्स्टेंट के तौर पर नहीं दिखती है.

7.4.5. नेटवर्किंग प्रोटोकॉल और एपीआई

7.4.5.1. नेटवर्क की कम से कम क्षमता

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-1] डिवाइस में, एक या उससे ज़्यादा तरह के डेटा नेटवर्किंग की सुविधा होनी चाहिए. खास तौर पर, डिवाइस में कम से कम एक ऐसा डेटा स्टैंडर्ड होना चाहिए जो 200 Kbit/सेकंड या इससे ज़्यादा की स्पीड से डेटा ट्रांसफ़र कर सके. इस ज़रूरी शर्त को पूरा करने वाली टेक्नोलॉजी के उदाहरणों में EDGE, HSPA, EV-DO, 802.11g, Ethernet, और Bluetooth PAN शामिल हैं.
जब फ़िज़िकल नेटवर्किंग स्टैंडर्ड (जैसे कि ईथरनेट) प्राइमरी डेटा कनेक्शन हो, तब कम से कम एक सामान्य वायरलेस डेटा स्टैंडर्ड, जैसे कि 802.11 (वाई-फ़ाई) के लिए भी सहायता शामिल होनी चाहिए.
डेटा कनेक्टिविटी के एक से ज़्यादा तरीके लागू कर सकता है.

7.4.5.2. IPv6

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-2] इसमें IPv6 नेटवर्किंग स्टैक शामिल होना चाहिए. साथ ही, मैनेज किए गए एपीआई (जैसे, java.net.Socket और java.net.URLConnection) और नेटिव एपीआई (जैसे, AF_INET6 सॉकेट) का इस्तेमाल करके, IPv6 कम्यूनिकेशन की सुविधा होनी चाहिए.
[C-0-3] यह ज़रूरी है कि IPv6 डिफ़ॉल्ट रूप से चालू हो.
यह पक्का करना ज़रूरी है कि IPv6 कम्यूनिकेशन, IPv4 जितना भरोसेमंद हो. उदाहरण के लिए:
- [C-0-4] यह ज़रूरी है कि डिवाइस, डॉज़ मोड में होने पर भी IPv6 से कनेक्ट रहे.
- [C-0-5] रेट-लिमिटिंग की वजह से, डिवाइस को आईपीवी6 के साथ काम करने वाले किसी भी ऐसे नेटवर्क पर आईपीवी6 कनेक्टिविटी नहीं खोनी चाहिए जो आरए लाइफ़टाइम के तौर पर कम से कम 180 सेकंड का इस्तेमाल करता है.
[C-0-6] जब डिवाइस IPv6 नेटवर्क से कनेक्ट हो, तो तीसरे पक्ष के ऐप्लिकेशन को नेटवर्क से सीधे IPv6 कनेक्टिविटी देनी होगी. साथ ही, डिवाइस पर स्थानीय तौर पर किसी भी तरह का पता या पोर्ट ट्रांसलेशन नहीं होना चाहिए. मैनेज किए गए एपीआई (जैसे, Socket#getLocalAddress या Socket#getLocalPort) और NDK एपीआई (जैसे, getsockname() या IPV6_PKTINFO) दोनों को, नेटवर्क पर पैकेट भेजने और पाने के लिए इस्तेमाल किए गए आईपी पते और पोर्ट को दिखाना होगा. साथ ही, इंटरनेट (वेब) सर्वर को सोर्स आईपी और पोर्ट के तौर पर दिखने वाले आईपी पते और पोर्ट को दिखाना होगा.

IPv6 की सुविधा के लिए ज़रूरी शर्तें, नेटवर्क टाइप के हिसाब से अलग-अलग होती हैं. इनके बारे में यहां बताया गया है.

अगर डिवाइस में वाई-फ़ाई की सुविधा काम करती है, तो:

[C-1-1] यह ज़रूरी है कि वाई-फ़ाई पर ड्यूअल-स्टैक और सिर्फ़ IPv6 का इस्तेमाल किया जा सके.

अगर डिवाइस में ईथरनेट का इस्तेमाल किया जा सकता है, तो:

[C-2-1] ईथरनेट पर ड्युअल-स्टैक और सिर्फ़ IPv6 ऑपरेशन काम करना चाहिए.

अगर डिवाइस में सेल्युलर डेटा का इस्तेमाल किया जा सकता है, तो:

[C-3-1] सेल्युलर नेटवर्क पर IPv6 ऑपरेशन (सिर्फ़ IPv6 और डुअल-स्टैक) काम करना चाहिए.

अगर डिवाइस में एक से ज़्यादा तरह के नेटवर्क काम करते हैं (जैसे, वाई-फ़ाई और मोबाइल डेटा), तो:

[C-4-1] जब डिवाइस एक साथ एक से ज़्यादा तरह के नेटवर्क से कनेक्ट हो, तो हर नेटवर्क पर ऊपर दी गई ज़रूरी शर्तों को एक साथ पूरा करना ज़रूरी है.

7.4.5.3. कैप्टिव पोर्टल

कैप्टिव पोर्टल, ऐसे नेटवर्क को कहते हैं जिसे ऐक्सेस करने के लिए साइन इन करना ज़रूरी होता है.

अगर डिवाइस में सेट किए गए सिस्टम में android.webkit.Webview API को पूरी तरह से लागू किया गया है, तो:

[C-1-1] सिस्टम एपीआई ConnectivityManager#startCaptivePortalApp(Network, Bundle) को कॉल करने पर, इंटेंट ACTION_CAPTIVE_PORTAL_SIGN_IN को हैंडल करने और कैप्टिव पोर्टल लॉगिन पेज दिखाने के लिए, कैप्टिव पोर्टल ऐप्लिकेशन उपलब्ध कराना ज़रूरी है. इसके लिए, उस इंटेंट को भेजना होगा.
[C-1-2] जब डिवाइस किसी भी तरह के नेटवर्क से कनेक्ट हो, तब उसे कैप्टिव पोर्टल का पता लगाना चाहिए. साथ ही, कैप्टिव पोर्टल ऐप्लिकेशन के ज़रिए लॉगिन करने की सुविधा देनी चाहिए. डिवाइस, सेल्युलर/मोबाइल नेटवर्क, वाईफ़ाई, ईथरनेट या ब्लूटूथ से कनेक्ट हो सकता है.
[C-1-3] जब डिवाइस को निजी डीएनएस के स्ट्रिक्ट मोड का इस्तेमाल करने के लिए कॉन्फ़िगर किया गया हो, तब उसे क्लियरटेक्स्ट डीएनएस का इस्तेमाल करके कैप्टिव पोर्टल में लॉग इन करने की सुविधा देनी होगी.
[C-1-4] android.net.LinkProperties.getPrivateDnsServerName और android.net.LinkProperties.isPrivateDnsActive के लिए, एसडीके के दस्तावेज़ के मुताबिक एन्क्रिप्ट (सुरक्षित) किए गए डीएनएस का इस्तेमाल करना ज़रूरी है. ऐसा उन सभी नेटवर्क ट्रैफ़िक के लिए करना होगा जो कैपटिव पोर्टल से साफ़ तौर पर कम्यूनिकेट नहीं करता है.
[C-1-5] यह पक्का करना ज़रूरी है कि जब उपयोगकर्ता किसी कैप्टिव पोर्टल में लॉग इन कर रहा हो, तब ऐप्लिकेशन के लिए डिफ़ॉल्ट रूप से इस्तेमाल किया जाने वाला नेटवर्क (ConnectivityManager.getActiveNetwork और ConnectivityManager.registerDefaultNetworkCallback से मिला नेटवर्क) कोई दूसरा उपलब्ध नेटवर्क हो. साथ ही, यह नेटवर्क इंटरनेट ऐक्सेस देता हो. अगर ऐसा कोई नेटवर्क उपलब्ध नहीं है, तो ऐप्लिकेशन के लिए डिफ़ॉल्ट रूप से इस्तेमाल किया जाने वाला नेटवर्क (ConnectivityManager.getActiveNetwork और ConnectivityManager.registerDefaultNetworkCallback से मिला नेटवर्क) वही नेटवर्क होना चाहिए जो Java नेटवर्किंग एपीआई (जैसे, java.net.Socket) और नेटिव एपीआई (जैसे, connect()) डिफ़ॉल्ट रूप से इस्तेमाल करते हैं.

7.4.6. समन्वयन सेटिंग

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-1] मास्टर ऑटो-सिंक सेटिंग डिफ़ॉल्ट रूप से चालू होनी चाहिए, ताकि getMasterSyncAutomatically() तरीके से “true” वैल्यू मिले.

7.4.7. डेटा बचाने की सेटिंग

अगर डिवाइस में मीटर वाला कनेक्शन शामिल है, तो:

[SR] डेटा सेवर मोड उपलब्ध कराने का सुझाव दिया जाता है.

अगर डिवाइसों में डेटा बचाने वाला मोड उपलब्ध है, तो:

[C-1-1] एसडीके के दस्तावेज़ में बताए गए तरीके के मुताबिक, ConnectivityManager क्लास में मौजूद सभी एपीआई के साथ काम करना ज़रूरी है

अगर डिवाइसों में डेटा सेवर मोड की सुविधा उपलब्ध नहीं है, तो:

[C-2-1] ConnectivityManager.getRestrictBackgroundStatus() के लिए, RESTRICT_BACKGROUND_STATUS_DISABLED वैल्यू रिटर्न होनी चाहिए
[C-2-2] ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED को ब्रॉडकास्ट नहीं करना चाहिए.

7.4.8. सुरक्षा चिप

अगर डिवाइस में सेट किए गए सिस्टम, Open Mobile API के साथ काम करने वाले सुरक्षित एलिमेंट का इस्तेमाल करते हैं और उन्हें तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराते हैं, तो:

[C-1-1] android.se.omapi.SEService.getReaders() एपीआई के ज़रिए, उपलब्ध सुरक्षित एलिमेंट रीडर की सूची बनाना ज़रूरी है.
[C-1-2] UICC पर आधारित सुरक्षित एलिमेंट वाले डिवाइस के लिए, android.hardware.se.omapi.uicc के ज़रिए सही फ़ीचर फ़्लैग; eSE पर आधारित सुरक्षित एलिमेंट वाले डिवाइस के लिए, android.hardware.se.omapi.ese के ज़रिए सही फ़ीचर फ़्लैग; और SD पर आधारित सुरक्षित एलिमेंट वाले डिवाइस के लिए, android.hardware.se.omapi.sd के ज़रिए सही फ़ीचर फ़्लैग का एलान करना ज़रूरी है.

7.5. कैमरे

अगर डिवाइसों में कम से कम एक कैमरा शामिल है, तो:

[C-1-1] android.hardware.camera.any फ़ीचर फ़्लैग के बारे में एलान करना ज़रूरी है.
[C-1-2] किसी ऐप्लिकेशन के लिए, डिवाइस पर सबसे ज़्यादा रिज़ॉल्यूशन वाले कैमरा सेंसर से ली गई इमेज के साइज़ के बराबर, तीन RGBA_8888 बिटमैप एक साथ असाइन करना ज़रूरी है. ऐसा तब होना चाहिए, जब कैमरा बुनियादी तौर पर प्रीव्यू करने और फ़ोटो कैप्चर करने के लिए खुला हो.
[C-1-3] यह पक्का करना ज़रूरी है कि पहले से इंस्टॉल किया गया डिफ़ॉल्ट कैमरा ऐप्लिकेशन, MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE या MediaStore.ACTION_VIDEO_CAPTURE इंटेंट को हैंडल करता हो. साथ ही, जब ऐप्लिकेशन को ACCESS_FINE_LOCATION का ऐक्सेस न हो, तब वह इमेज के मेटाडेटा से उपयोगकर्ता की जगह की जानकारी हटाकर, उसे ऐप्लिकेशन को भेजता हो.

7.5.1. पीछे की ओर लगा कैमरा

पीछे की ओर वाला कैमरा, डिवाइस के डिसप्ले के दूसरी तरफ़ होता है. यह पारंपरिक कैमरे की तरह, डिवाइस के दूसरी तरफ़ के सीन की इमेज लेता है.

डिवाइस में सेट किए गए सिस्टम के लिए:

इसमें पीछे की ओर कैमरा होना चाहिए.

अगर डिवाइसों में कम से कम एक रियर-फ़ेसिंग कैमरा शामिल है, तो:

[C-1-1] android.hardware.camera और android.hardware.camera.any फ़ीचर फ़्लैग की जानकारी देना ज़रूरी है.
[C-1-2] इसका रिज़ॉल्यूशन कम से कम 2 मेगापिक्सल होना चाहिए.
कैमरा ड्राइवर में, हार्डवेयर ऑटो-फ़ोकस या सॉफ़्टवेयर ऑटो-फ़ोकस की सुविधा होनी चाहिए. यह सुविधा, ऐप्लिकेशन सॉफ़्टवेयर के लिए पारदर्शी होनी चाहिए.
इसमें फ़िक्स्ड-फ़ोकस या ईडॉफ़ (एक्सटेंडेड डेप्थ ऑफ़ फ़ील्ड) हार्डवेयर हो सकता है.
इसमें फ़्लैश शामिल हो सकता है.

अगर कैमरे में फ़्लैश की सुविधा है, तो:

[C-2-1] जब तक ऐप्लिकेशन, Camera.Parameters ऑब्जेक्ट के FLASH_MODE_AUTO या FLASH_MODE_ON एट्रिब्यूट को चालू करके फ़्लैश को साफ़ तौर पर चालू न करे, तब तक कैमरा प्रीव्यू की सुविधा पर android.hardware.Camera.PreviewCallback इंस्टेंस रजिस्टर होने के दौरान फ़्लैश लैंप चालू नहीं होना चाहिए. ध्यान दें कि यह पाबंदी, डिवाइस में पहले से मौजूद सिस्टम कैमरा ऐप्लिकेशन पर लागू नहीं होती. यह सिर्फ़ Camera.PreviewCallback का इस्तेमाल करने वाले तीसरे पक्ष के ऐप्लिकेशन पर लागू होती है.

7.5.2. सामने वाला कैमरा

सामने की ओर मौजूद कैमरा, डिवाइस की स्क्रीन की तरफ़ होता है. आम तौर पर, इसका इस्तेमाल उपयोगकर्ता की इमेज लेने के लिए किया जाता है. जैसे, वीडियो कॉन्फ़्रेंसिंग और इसी तरह के अन्य ऐप्लिकेशन के लिए.

डिवाइस में सेट किए गए सिस्टम के लिए:

इसमें सामने की ओर कैमरा हो सकता है.

अगर डिवाइसों में कम से कम एक फ़्रंट-फ़ेसिंग कैमरा शामिल है, तो:

[C-1-1] android.hardware.camera.any और android.hardware.camera.front फ़ीचर फ़्लैग की जानकारी देना ज़रूरी है.
[C-1-2] का रिज़ॉल्यूशन कम से कम वीजीए (640x480 पिक्सल) होना चाहिए.
[C-1-3] Camera API के लिए, सामने वाले कैमरे को डिफ़ॉल्ट कैमरे के तौर पर इस्तेमाल नहीं किया जाना चाहिए. साथ ही, एपीआई को इस तरह कॉन्फ़िगर नहीं किया जाना चाहिए कि सामने वाले कैमरे को डिफ़ॉल्ट तौर पर पीछे वाले कैमरे के तौर पर इस्तेमाल किया जा सके. भले ही, डिवाइस में सिर्फ़ एक कैमरा हो.
[C-1-4] जब मौजूदा ऐप्लिकेशन ने android.hardware.Camera.setDisplayOrientation() तरीके का इस्तेमाल करके, कैमरा डिसप्ले को घुमाने का अनुरोध किया हो, तब ऐप्लिकेशन की ओर से तय किए गए ओरिएंटेशन के हिसाब से, कैमरा प्रीव्यू को हॉरिज़ॉन्टली मिरर किया जाना चाहिए. इसके उलट, अगर मौजूदा ऐप्लिकेशन, android.hardware.Camera.setDisplayOrientation() तरीके को कॉल करके, कैमरा डिसप्ले को घुमाने का अनुरोध नहीं करता है, तो डिवाइस के डिफ़ॉल्ट हॉरिज़ॉन्टल ऐक्सिस के साथ झलक को मिरर किया जाना चाहिए.
[C-1-5] फ़ाइनल कैप्चर की गई इमेज या वीडियो स्ट्रीम को, ऐप्लिकेशन के कॉल बैक या मीडिया स्टोरेज में सेव नहीं किया जाना चाहिए.
[C-1-6] पोस्टव्यू में दिखने वाली इमेज, कैमरा प्रीव्यू इमेज स्ट्रीम में दिखने वाली इमेज की तरह ही होनी चाहिए.
इसमें सेक्शन 7.5.1 में बताई गई, पीछे की ओर लगे कैमरे के लिए उपलब्ध सुविधाएं (जैसे, ऑटो-फ़ोकस, फ़्लैश वगैरह) शामिल हो सकती हैं.

अगर डिवाइस को उपयोगकर्ता घुमा सकता है (जैसे, ऐक्सिलरोमीटर की मदद से अपने-आप या उपयोगकर्ता के इनपुट से मैन्युअल तरीके से):

[C-2-1] कैमरे की झलक, डिवाइस के मौजूदा ओरिएंटेशन के हिसाब से हॉरिज़ॉन्टल तौर पर मिरर की जानी चाहिए.

7.5.3. बाहरी कैमरा

डिवाइस में सेट किए गए सिस्टम के लिए:

इसमें, किसी ऐसे बाहरी कैमरे के साथ काम करने की सुविधा शामिल हो सकती है जो हमेशा कनेक्ट न हो.

अगर डिवाइस में बाहरी कैमरे का इस्तेमाल किया जा सकता है, तो:

[C-1-1] प्लैटफ़ॉर्म फ़ीचर फ़्लैग android.hardware.camera.external और android.hardware camera.any के बारे में एलान करना ज़रूरी है.
[C-1-2] अगर बाहरी कैमरा, यूएसबी होस्ट पोर्ट से कनेक्ट होता है, तो यह ज़रूरी है कि वह यूएसबी वीडियो क्लास (यूवीसी 1.0 या इससे ज़्यादा) के साथ काम करता हो.
[C-1-3] यह ज़रूरी है कि डिवाइस, बाहरी कैमरे को कनेक्ट करके, कैमरा सीटीएस टेस्ट पास करे. कैमरे के सीटीएस टेस्ट के बारे में ज़्यादा जानकारी के लिए, source.android.com पर जाएं.
इसमें MJPEG जैसे वीडियो कंप्रेस करने के तरीके काम करने चाहिए, ताकि अच्छी क्वालिटी वाली अनकोड की गई स्ट्रीम (जैसे कि रॉ या अलग से कंप्रेस की गई पिक्चर स्ट्रीम) को ट्रांसफ़र किया जा सके.
एक से ज़्यादा कैमरे इस्तेमाल किए जा सकते हैं.
कैमरे के आधार पर वीडियो एन्कोडिंग की सुविधा काम कर सकती है.

अगर कैमरे के आधार पर वीडियो एन्कोड करने की सुविधा काम करती है, तो:

[C-2-1] डिवाइस पर एक साथ अनकोड की गई / MJPEG स्ट्रीम (QVGA या इससे ज़्यादा रिज़ॉल्यूशन) को ऐक्सेस किया जा सकता है.

7.5.4. Camera API का व्यवहार

Android में, कैमरे को ऐक्सेस करने के लिए दो एपीआई पैकेज शामिल हैं. नया android.hardware.camera2 API, ऐप्लिकेशन को कैमरे का लोअर-लेवल कंट्रोल देता है. इसमें ज़ीरो-कॉपी बर्स्ट/स्ट्रीमिंग फ़्लो और एक्सपोज़र, गेन, व्हाइट बैलेंस गेन, कलर कन्वर्ज़न, नॉइज़ कम करना, शार्पनिंग वगैरह के फ़्रेम-दर-फ़्रेम कंट्रोल शामिल हैं.

Android 5.0 में,पुराने एपीआई पैकेज android.hardware.Camera को 'अब काम नहीं करता' के तौर पर मार्क किया गया है. हालांकि, यह अब भी ऐप्लिकेशन के लिए उपलब्ध होना चाहिए. Android डिवाइसों में, इस सेक्शन और Android SDK में बताए गए तरीके से, एपीआई का इस्तेमाल जारी रहना चाहिए.

android.hardware.Camera क्लास और android.hardware.camera2 पैकेज में मौजूद सभी सुविधाओं की परफ़ॉर्मेंस और क्वालिटी, दोनों एपीआई में एक जैसी होनी चाहिए. उदाहरण के लिए, एक जैसी सेटिंग के साथ ऑटोफ़ोकस की स्पीड और सटीक होने की क्षमता एक जैसी होनी चाहिए. साथ ही, कैप्चर की गई इमेज की क्वालिटी भी एक जैसी होनी चाहिए. जिन सुविधाओं के लिए, दोनों एपीआई के अलग-अलग सिमैंटिक की ज़रूरत होती है उनके लिए, स्पीड या क्वालिटी का एक जैसा होना ज़रूरी नहीं है. हालांकि, यह ज़रूरी है कि वे ज़्यादा से ज़्यादा एक जैसी हों.

डिवाइसों को, कैमरे से जुड़े एपीआई के लिए यहां बताए गए तरीके लागू करने होंगे. ये तरीके, सभी उपलब्ध कैमरों के लिए लागू होने चाहिए. डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-1] जब किसी ऐप्लिकेशन ने कभी android.hardware.Camera.Parameters.setPreviewFormat(int) को कॉल नहीं किया हो, तब ऐप्लिकेशन के कॉलबैक को उपलब्ध कराए गए डेटा की झलक के लिए, android.hardware.PixelFormat.YCbCr_420_SP का इस्तेमाल करना ज़रूरी है.
[C-0-2] जब कोई ऐप्लिकेशन android.hardware.Camera.PreviewCallback इंस्टेंस रजिस्टर करता है और सिस्टम onPreviewFrame() तरीके को कॉल करता है और पूर्वावलोकन फ़ॉर्मैट YCbCr_420_SP होता है, तो onPreviewFrame() में पास किया गया डेटा, NV21 एन्कोडिंग फ़ॉर्मैट में होना चाहिए. इसका मतलब है कि NV21 डिफ़ॉल्ट फ़ॉर्मैट होना चाहिए.
[C-0-3] android.hardware.Camera के लिए, सामने और पीछे वाले दोनों कैमरों की झलक दिखाने के लिए, YV12 फ़ॉर्मैट (android.graphics.ImageFormat.YV12 कॉन्स्टेंट के तौर पर दिखाया गया है) काम करना चाहिए. (हार्डवेयर वीडियो एन्कोडर और कैमरा, किसी भी नेटिव पिक्सल फ़ॉर्मैट का इस्तेमाल कर सकते हैं. हालांकि, डिवाइस पर YV12 में बदलने की सुविधा होनी चाहिए.)
[C-0-4] यह ज़रूरी है कि android.hardware.camera2 डिवाइसों के लिए, android.media.ImageReader API के ज़रिए आउटपुट के तौर पर android.hardware.ImageFormat.YUV_420_888 और android.hardware.ImageFormat.JPEG फ़ॉर्मैट काम करें. ये डिवाइस, android.request.availableCapabilities में REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE सुविधा का विज्ञापन दिखाते हैं.
[C-0-5] डिवाइस में हार्डवेयर ऑटोफ़ोकस या अन्य सुविधाएं शामिल हैं या नहीं, इससे कोई फ़र्क़ नहीं पड़ता. डिवाइस में Android SDK के दस्तावेज़ में शामिल पूरा Camera API लागू करना ज़रूरी है. उदाहरण के लिए, जिन कैमरों में ऑटोफ़ोकस की सुविधा नहीं होती उन्हें भी रजिस्टर किए गए सभी android.hardware.Camera.AutoFocusCallback इंस्टेंस को कॉल करना होगा. भले ही, यह सुविधा ऑटोफ़ोकस की सुविधा के बिना काम करने वाले कैमरे के लिए काम की न हो. ध्यान दें कि यह सुविधा, सामने वाले कैमरों पर भी लागू होती है. उदाहरण के लिए, भले ही सामने वाले ज़्यादातर कैमरे ऑटोफ़ोकस की सुविधा के साथ काम न करते हों, लेकिन एपीआई कॉलबैक को अब भी बताए गए तरीके से “नकली” होना चाहिए.
[C-0-6] android.hardware.Camera.Parameters क्लास और android.hardware.camera2.CaptureRequest क्लास में कॉन्स्टेंट के तौर पर तय किए गए हर पैरामीटर के नाम को पहचानना और उसका पालन करना ज़रूरी है. इसके उलट, डिवाइसों को android.hardware.Camera.setParameters() तरीके से पास किए गए स्ट्रिंग कॉन्स्टेंट को स्वीकार नहीं करना चाहिए या उनकी पहचान नहीं करनी चाहिए. हालांकि, android.hardware.Camera.Parameters पर कॉन्स्टेंट के तौर पर दस्तावेज़ में दिए गए स्ट्रिंग कॉन्स्टेंट को स्वीकार किया जा सकता है. इसका मतलब है कि अगर हार्डवेयर अनुमति देता है, तो डिवाइसों पर लागू किए गए सॉफ़्टवेयर में, कैमरे के सभी स्टैंडर्ड पैरामीटर काम करने चाहिए. साथ ही, उनमें कैमरे के कस्टम पैरामीटर टाइप काम नहीं करने चाहिए. उदाहरण के लिए, जिन डिवाइसों में हाई डाइनैमिक रेंज (एचडीआर) इमेजिंग तकनीकों का इस्तेमाल करके इमेज कैप्चर करने की सुविधा होती है उनमें कैमरा पैरामीटर Camera.SCENE_MODE_HDR का इस्तेमाल किया जाना ज़रूरी है.
[C-0-7] Android SDK में बताए गए तरीके के मुताबिक, android.info.supportedHardwareLevel प्रॉपर्टी के साथ सहायता के सही लेवल की जानकारी देना ज़रूरी है. साथ ही, फ़्रेमवर्क के सही फ़ीचर फ़्लैग की जानकारी देना ज़रूरी है.
[C-0-8] android.request.availableCapabilities प्रॉपर्टी के ज़रिए, android.hardware.camera2 की अलग-अलग कैमरा क्षमताओं के बारे में भी एलान करना ज़रूरी है. साथ ही, सही फ़ीचर फ़्लैग के बारे में एलान करना ज़रूरी है. अगर अटैच किए गए किसी भी कैमरा डिवाइस पर यह सुविधा काम करती है, तो फ़ीचर फ़्लैग को तय करना ज़रूरी है.
[C-0-9] जब भी कैमरा कोई नई फ़ोटो लेता है और उस फ़ोटो को मीडिया स्टोर में जोड़ दिया जाता है, तब Camera.ACTION_NEW_PICTURE इंटेंट को ब्रॉडकास्ट करना ज़रूरी है.
[C-0-10] जब भी कैमरा कोई नया वीडियो रिकॉर्ड करता है और मीडिया स्टोर में फ़ोटो की एंट्री जोड़ दी जाती है, तब Camera.ACTION_NEW_VIDEO इंटेंट को ब्रॉडकास्ट करना ज़रूरी है.
[C-0-11] android.hardware.Camera एपीआई के ज़रिए ऐक्सेस किए जा सकने वाले सभी कैमरे, android.hardware.camera2 एपीआई के ज़रिए भी ऐक्सेस किए जा सकते हों.
[C-0-12] यह पक्का करना ज़रूरी है कि किसी भी android.hardware.camera2 या android.hardware.Camera एपीआई के लिए, चेहरे की बनावट में बदलाव न किया गया हो. इसमें चेहरे की बनावट, चेहरे की त्वचा का रंग या चेहरे की त्वचा को ज़्यादा स्मूद बनाने के लिए किए गए बदलाव शामिल हैं.
[C-SR] एक ही दिशा में फ़ेस करने वाले कई RGB कैमरों वाले डिवाइसों के लिए, यह सुझाव दिया जाता है कि वे एक लॉजिकल कैमरा डिवाइस के साथ काम करें. इस डिवाइस में, उस दिशा में फ़ेस करने वाले सभी RGB कैमरे, फ़िज़िकल सब-डिवाइस के तौर पर शामिल हों. साथ ही, इसमें CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA सुविधा उपलब्ध हो.

अगर डिवाइस बनाने वाली कंपनियां, तीसरे पक्ष के ऐप्लिकेशन को मालिकाना हक वाला कैमरा एपीआई उपलब्ध कराती हैं, तो:

[C-1-1] इस तरह के कैमरा एपीआई को android.hardware.camera2 एपीआई का इस्तेमाल करके लागू करना ज़रूरी है.
android.hardware.camera2 एपीआई को वेंडर टैग और/या एक्सटेंशन दे सकता है.

7.5.5. कैमरे का ओरिएंटेशन

अगर डिवाइस में सामने या पीछे की ओर कैमरा लगा है, तो:

[C-1-1] कैमरे को इस तरह से ओरिएंट किया जाना चाहिए कि कैमरे का लंबा डाइमेंशन, स्क्रीन के लंबे डाइमेंशन के साथ अलाइन हो. इसका मतलब है कि डिवाइस को लैंडस्केप ओरिएंटेशन में रखने पर, कैमरे से ली गई इमेज भी लैंडस्केप ओरिएंटेशन में होनी चाहिए. यह डिवाइस के ओरिएंटेशन पर निर्भर नहीं करता. इसका मतलब है कि यह लैंडस्केप-प्राइमरी डिवाइसों के साथ-साथ पोर्ट्रेट-प्राइमरी डिवाइसों पर भी लागू होता है.

7.6. डिवाइस की मेमोरी और स्टोरेज

7.6.1. कम से कम मेमोरी और स्टोरेज

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-1] इसमें डाउनलोड मैनेजर शामिल होना चाहिए, जिसका इस्तेमाल ऐप्लिकेशन डेटा फ़ाइलें डाउनलोड करने के लिए कर सकते हैं. साथ ही, इनमें कम से कम 100 एमबी साइज़ की अलग-अलग फ़ाइलें, डिफ़ॉल्ट “कैश” लोकेशन पर डाउनलोड करने की सुविधा होनी चाहिए.

7.6.2. ऐप्लिकेशन के लिए शेयर किया गया स्टोरेज

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-1] डिवाइस में ऐसा स्टोरेज होना चाहिए जिसे ऐप्लिकेशन के साथ शेयर किया जा सके. इसे अक्सर “शेयर किया गया बाहरी स्टोरेज”, "ऐप्लिकेशन के साथ शेयर किया गया स्टोरेज" या Linux पाथ "/sdcard" के तौर पर भी जाना जाता है.
[C-0-2] इसे डिफ़ॉल्ट रूप से माउंट किए गए शेयर किए गए स्टोरेज के साथ कॉन्फ़िगर किया जाना चाहिए.दूसरे शब्दों में कहें, तो “आउट ऑफ़ द बॉक्स”. भले ही, स्टोरेज को इंटरनल स्टोरेज कॉम्पोनेंट या हटाने लायक स्टोरेज मीडियम (जैसे कि सिक्योर डिजिटल कार्ड स्लॉट) पर लागू किया गया हो.
[C-0-3] ऐप्लिकेशन को शेयर किए गए स्टोरेज को सीधे तौर पर Linux पाथ sdcard पर माउंट करना होगा. इसके अलावा, sdcard से लेकर माउंट पॉइंट तक Linux सिंबॉलिक लिंक शामिल करना होगा.
[C-0-4] एपीआई लेवल 29 या इससे ऊपर के लेवल को टारगेट करने वाले सभी ऐप्लिकेशन के लिए, स्कोप किए गए स्टोरेज को डिफ़ॉल्ट रूप से चालू करना ज़रूरी है. हालांकि, ऐसा इन स्थितियों में नहीं करना होगा:
- जब ऐप्लिकेशन ने अपने मेनिफ़ेस्ट में android:requestLegacyExternalStorage="true" का अनुरोध किया हो.
[C-0-5] जब MediaStore के ज़रिए मीडिया फ़ाइलों को ऐक्सेस किया जाता है, तो उनमें सेव किए गए लोकेशन मेटाडेटा को छिपाना ज़रूरी है. जैसे, जीपीएस Exif टैग. हालांकि, अगर ऐक्सेस करने वाले ऐप्लिकेशन के पास ACCESS_MEDIA_LOCATION की अनुमति है, तो ऐसा करना ज़रूरी नहीं है.

डिवाइस में सेट किए गए सिस्टम, ऊपर दी गई ज़रूरी शर्तों को इनमें से किसी एक तरीके से पूरा कर सकते हैं:

उपयोगकर्ता के लिए उपलब्ध रिमूवेबल स्टोरेज, जैसे कि सिक्योर डिजिटल (एसडी) कार्ड स्लॉट.
Android ओपन सोर्स प्रोजेक्ट (एओएसपी) में लागू की गई इंटरनल (हटाने योग्य नहीं) स्टोरेज का एक हिस्सा.

अगर डिवाइस, ऊपर दी गई ज़रूरी शर्तों को पूरा करने के लिए, हटाने योग्य स्टोरेज का इस्तेमाल करते हैं, तो:

[C-1-1] अगर स्लॉट में कोई स्टोरेज मीडियम नहीं डाला गया है, तो डिवाइस में एक सूचना दिखनी चाहिए. यह सूचना, उपयोगकर्ता को एक टॉस्ट या पॉप-अप यूज़र इंटरफ़ेस के ज़रिए दिखनी चाहिए.
[C-1-2] इसमें FAT फ़ॉर्मैट वाला स्टोरेज मीडियम (जैसे, एसडी कार्ड) शामिल होना चाहिए. इसके अलावा, बॉक्स और खरीदारी के समय उपलब्ध अन्य सामान पर यह जानकारी दिखनी चाहिए कि स्टोरेज मीडियम को अलग से खरीदना होगा.

अगर डिवाइस, ऊपर दी गई ज़रूरी शर्तों को पूरा करने के लिए, न हटाई जा सकने वाली स्टोरेज का कुछ हिस्सा इस्तेमाल करते हैं, तो:

संगठन में काम करने वालों के साथ ऐप्लिकेशन शेयर करने की सुविधा के लिए, AOSP के लागू किए गए इंटरनल ऐप्लिकेशन शेयर किए गए स्टोरेज का इस्तेमाल करना चाहिए.
स्टोरेज स्पेस को ऐप्लिकेशन के निजी डेटा के साथ शेयर कर सकता है.

अगर डिवाइस में यूएसबी पोर्ट है और वह यूएसबी पेरिफ़ेरल मोड के साथ काम करता है, तो:

[C-3-1] होस्ट कंप्यूटर से, ऐप्लिकेशन के शेयर किए गए स्टोरेज में मौजूद डेटा को ऐक्सेस करने का तरीका उपलब्ध कराना ज़रूरी है.
Android की मीडिया स्कैनर सेवा और android.provider.MediaStore के ज़रिए, दोनों स्टोरेज पाथ से कॉन्टेंट को पारदर्शी तरीके से दिखाना चाहिए.
इस ज़रूरी शर्त को पूरा करने के लिए, यूएसबी मास स्टोरेज का इस्तेमाल किया जा सकता है. हालांकि, मीडिया ट्रांसफ़र प्रोटोकॉल का इस्तेमाल करना चाहिए.

अगर डिवाइस में यूएसबी पोर्ट है, जिसमें यूएसबी पेरिफ़ेरल मोड है और मीडिया ट्रांसफ़र प्रोटोकॉल काम करता है, तो:

यह रेफ़रंस Android MTP होस्ट, Android File Transfer के साथ काम करना चाहिए.
इसे यूएसबी डिवाइस क्लास 0x00 की रिपोर्ट देनी चाहिए.
'एमटीपी' के यूएसबी इंटरफ़ेस का नाम रिपोर्ट करना चाहिए.

7.6.3. एडॉप्टेबल स्टोरेज

अगर डिवाइस को टीवी की तरह एक जगह पर नहीं रखा जाता है, तो डिवाइस को लागू करने के ये तरीके हैं:

[SR] यह सुझाव दिया जाता है कि अडॉप्टेबल स्टोरेज को लंबे समय तक इस्तेमाल करने के लिए, किसी ऐसी जगह पर सेट अप करें जहां इसे बार-बार डिसकनेक्ट न करना पड़े. ऐसा इसलिए, क्योंकि गलती से डिसकनेक्ट करने पर डेटा मिट सकता है या खराब हो सकता है.

अगर हटाने योग्य स्टोरेज डिवाइस का पोर्ट, लंबे समय तक एक ही जगह पर रहता है, जैसे कि बैटरी कंपार्टमेंट या अन्य सुरक्षात्मक कवर के अंदर, तो डिवाइस के लिए ये विकल्प उपलब्ध होते हैं:

[SR] एडॉप्टेबल स्टोरेज लागू करने का सुझाव दिया जाता है.

7.7. यूएसबी

अगर डिवाइस में यूएसबी पोर्ट है, तो:

इसमें यूएसबी पेरिफ़ेरल मोड और यूएसबी होस्ट मोड काम करना चाहिए.

7.7.1. यूएसबी पेरिफ़ेरल मोड

अगर डिवाइस में, पेरिफ़ेरल मोड के साथ काम करने वाला यूएसबी पोर्ट शामिल है, तो:

[C-1-1] पोर्ट को ऐसे यूएसबी होस्ट से कनेक्ट किया जा सकता हो जिसमें स्टैंडर्ड टाइप-ए या टाइप-सी यूएसबी पोर्ट हो.
[C-1-2] android.os.Build.SERIAL के ज़रिए, यूएसबी स्टैंडर्ड डिवाइस डिस्क्रिप्टर में iSerialNumber की सही वैल्यू रिपोर्ट करना ज़रूरी है.
[C-1-3] टाइप-सी रजिस्टर के स्टैंडर्ड के मुताबिक, 1.5A और 3.0A चार्जर का पता लगाना ज़रूरी है. साथ ही, अगर वे टाइप-सी यूएसबी के साथ काम करते हैं, तो विज्ञापन में हुए बदलावों का पता लगाना ज़रूरी है.
[SR] पोर्ट में माइक्रो-बी, माइक्रो-एबी या टाइप-सी यूएसबी फ़ॉर्म फ़ैक्टर का इस्तेमाल किया जाना चाहिए. हमारा सुझाव है कि मौजूदा और नए Android डिवाइसों पर इन ज़रूरी शर्तों को पूरा किया जाए, ताकि उन्हें आने वाले समय में प्लैटफ़ॉर्म के नए वर्शन में अपग्रेड किया जा सके.
[एसआर] पोर्ट को डिवाइस के निचले हिस्से में होना चाहिए (नैचुरल ओरिएंटेशन के हिसाब से) या सभी ऐप्लिकेशन (होम स्क्रीन भी शामिल है) के लिए सॉफ़्टवेयर स्क्रीन रोटेशन की सुविधा चालू होनी चाहिए, ताकि डिवाइस को पोर्ट के साथ नीचे की ओर रखने पर डिसप्ले सही तरीके से दिखे. हमारा सुझाव है कि मौजूदा और नए Android डिवाइसों पर ये ज़रूरी शर्तें पूरी की जाएं, ताकि उन्हें प्लैटफ़ॉर्म के आने वाले वर्शन में अपग्रेड किया जा सके.
[SR] को यूएसबी बैटरी चार्जिंग स्पेसिफ़िकेशन, रिवीज़न 1.2 में बताए गए तरीके के मुताबिक, एचएस चिरप और ट्रैफ़िक के दौरान 1.5 A करंट लेने की सुविधा लागू करनी चाहिए. हमारा सुझाव है कि मौजूदा और नए Android डिवाइसों पर इन ज़रूरी शर्तों को पूरा किया जाए, ताकि उन्हें आने वाले समय में प्लैटफ़ॉर्म के नए वर्शन में अपग्रेड किया जा सके.
[SR] हमारा सुझाव है कि मालिकाना हक वाले ऐसे चार्जिंग तरीकों का इस्तेमाल न करें जिनसे Vbus वोल्टेज, डिफ़ॉल्ट लेवल से ज़्यादा हो जाता है या सिंक/सोर्स की भूमिकाएं बदल जाती हैं. ऐसा इसलिए, क्योंकि इससे उन चार्जर या डिवाइसों के साथ इंटरऑपरेबिलिटी की समस्याएं हो सकती हैं जो यूएसबी पावर डिलीवरी के स्टैंडर्ड तरीकों के साथ काम करते हैं. हालांकि, इसे "बेहद ज़रूरी" बताया गया है, लेकिन आने वाले समय में Android के वर्शन में, हम सभी टाइप-सी डिवाइसों के लिए यह ज़रूरी कर सकते हैं कि वे स्टैंडर्ड टाइप-सी चार्जर के साथ पूरी तरह से काम करें.
[SR] यह सुझाव दिया जाता है कि डिवाइस में डेटा और पावर रोल स्वैपिंग के लिए पावर डिलीवरी की सुविधा हो. ऐसा तब किया जा सकता है, जब डिवाइस में टाइप-सी यूएसबी और यूएसबी होस्ट मोड की सुविधा हो.
इसमें ज़्यादा वोल्टेज पर चार्जिंग के लिए, पावर डिलीवरी की सुविधा होनी चाहिए. साथ ही, डिसप्ले आउट जैसे वैकल्पिक मोड के लिए भी सहायता उपलब्ध होनी चाहिए.
Android Open Accessory (AOA) API और स्पेसिफ़िकेशन को लागू करना चाहिए. इसके बारे में Android SDK के दस्तावेज़ में बताया गया है.

अगर डिवाइस में यूएसबी पोर्ट शामिल है और AOA स्पेसिफ़िकेशन लागू किया गया है, तो:

[C-2-1] यह ज़रूरी है कि हार्डवेयर की सुविधा android.hardware.usb.accessory के साथ काम करने का एलान किया गया हो.
[C-2-2] यूएसबी मास स्टोरेज क्लास में, यूएसबी मास स्टोरेज के इंटरफ़ेस के ब्यौरे iInterface स्ट्रिंग के आखिर में "android" स्ट्रिंग शामिल होनी चाहिए

7.7.2. यूएसबी होस्ट मोड

अगर डिवाइस में होस्ट मोड के साथ काम करने वाला यूएसबी पोर्ट शामिल है, तो:

[C-1-1] Android SDK में दिए गए दस्तावेज़ के मुताबिक, Android USB होस्ट एपीआई को लागू करना ज़रूरी है. साथ ही, हार्डवेयर की सुविधा android.hardware.usb.host के लिए सहायता उपलब्ध कराने का एलान करना ज़रूरी है.
[C-1-2] MUST implement support to connect standard USB peripherals, in other words, they MUST either:
- डिवाइस में टाइप सी पोर्ट होना चाहिए या डिवाइस के साथ ऐसी केबल होनी चाहिए जो डिवाइस के मालिकाना हक वाले पोर्ट को स्टैंडर्ड यूएसबी टाइप-सी पोर्ट (यूएसबी टाइप-सी डिवाइस) में बदलती हो.
- डिवाइस में टाइप ए पोर्ट हो या डिवाइस के साथ ऐसी केबल दी गई हो जो डिवाइस के मालिकाना हक वाले पोर्ट को स्टैंडर्ड यूएसबी टाइप-ए पोर्ट में बदलती हो.
- डिवाइस में माइक्रो-एबी पोर्ट होना चाहिए. साथ ही, डिवाइस के साथ एक केबल भी होनी चाहिए, जो स्टैंडर्ड टाइप-ए पोर्ट के साथ काम करती हो.
[C-1-3] इसे यूएसबी टाइप-ए या माइक्रो-एबी पोर्ट को टाइप-सी पोर्ट (रिसेप्टेकल) में बदलने वाले अडैप्टर के साथ शिप नहीं किया जाना चाहिए.
[C-SR] Android SDK के दस्तावेज़ में बताए गए तरीके से, यूएसबी ऑडियो क्लास को लागू करने का सुझाव दिया जाता है.
होस्ट मोड में कनेक्ट किए गए यूएसबी सहायक डिवाइस को चार्ज करने की सुविधा होनी चाहिए. साथ ही, यूएसबी टाइप-सी कनेक्टर के लिए, यूएसबी टाइप-सी केबल और कनेक्टर स्पेसिफ़िकेशन, वर्शन 1.2 के टर्मिनेशन पैरामीटर सेक्शन में बताए गए कम से कम 1.5 ऐंपियर के सोर्स करंट का विज्ञापन दिखाना चाहिए. इसके अलावा, माइक्रो-एबी कनेक्टर के लिए, यूएसबी बैटरी चार्जिंग स्पेसिफ़िकेशन, वर्शन 1.2 में बताई गई चार्जिंग डाउनस्ट्रीम पोर्ट(सीडीपी) आउटपुट करंट रेंज का इस्तेमाल करना चाहिए.
इसमें यूएसबी टाइप-सी स्टैंडर्ड लागू होने चाहिए और यह उनके साथ काम करना चाहिए.

अगर डिवाइस में होस्ट मोड और यूएसबी ऑडियो क्लास के साथ काम करने वाला यूएसबी पोर्ट शामिल है, तो:

[C-2-1] यूएसबी एचआईडी क्लास के साथ काम करना ज़रूरी है.
[C-2-2] यूएसबी एचआईडी यूसेज टेबल और वॉइस कमांड यूसेज रिक्वेस्ट में बताए गए, एचआईडी के इन डेटा फ़ील्ड का पता लगाने और उन्हें KeyEvent कॉन्स्टेंट से मैप करने की सुविधा होनी चाहिए. ये डेटा फ़ील्ड यहां दिए गए हैं:
- Usage Page (0xC) Usage ID (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
- Usage Page (0xC) Usage ID (0x0E9): KEYCODE_VOLUME_UP
- Usage Page (0xC) Usage ID (0x0EA): KEYCODE_VOLUME_DOWN
- इस्तेमाल से जुड़ा पेज (0xC) इस्तेमाल का आईडी (0x0CF): KEYCODE_VOICE_ASSIST

अगर डिवाइस में होस्ट मोड और स्टोरेज ऐक्सेस फ़्रेमवर्क (एसएएफ़) के साथ काम करने वाला यूएसबी पोर्ट शामिल है, तो:

[C-3-1] इसे रिमोट से कनेक्ट किए गए किसी भी एमटीपी (मीडिया ट्रांसफर प्रोटोकॉल) डिवाइस को पहचानना चाहिए. साथ ही, ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, और ACTION_CREATE_DOCUMENT इंटेंट के ज़रिए, डिवाइस के कॉन्टेंट को ऐक्सेस करने की सुविधा देनी चाहिए. .

अगर डिवाइस में होस्ट मोड और यूएसबी टाइप-सी को सपोर्ट करने वाला यूएसबी पोर्ट शामिल है, तो:

[C-4-1] यूएसबी टाइप-सी के स्पेसिफ़िकेशन (सेक्शन 4.5.1.3.3) में बताई गई, ड्यूअल रोल पोर्ट की सुविधा लागू करना ज़रूरी है.
[SR] यह सुझाव दिया जाता है कि DisplayPort काम करे. साथ ही, यह ज़रूरी है कि यूएसबी सुपरस्पीड डेटा रेट काम करे. इसके अलावा, यह सुझाव दिया जाता है कि डेटा और पावर रोल स्वैपिंग के लिए, पावर डिलीवरी की सुविधा काम करे.
[SR] हमारा सुझाव है कि यूएसबी टाइप-सी केबल और कनेक्टर स्पेसिफ़िकेशन के वर्शन 1.2 के अपेंडिक्स A में बताए गए तरीके से, ऑडियो अडैप्टर ऐक्सेसरी मोड का इस्तेमाल न करें.
डिवाइस के साइज़ और आकार के हिसाब से, Try.* मॉडल लागू करना चाहिए. उदाहरण के लिए, हैंडहेल्ड डिवाइस को Try.SNK मॉडल लागू करना चाहिए.

7.8. ऑडियो

7.8.1. माइक्रोफ़ोन

अगर डिवाइसों में माइक्रोफ़ोन शामिल है, तो:

[C-1-1] android.hardware.microphone सुविधा के कॉन्सटेंट की जानकारी देना ज़रूरी है.
[C-1-2] सेक्शन 5.4 में बताई गई, ऑडियो रिकॉर्डिंग से जुड़ी ज़रूरी शर्तों को पूरा करना ज़रूरी है.
[C-1-3] सेक्शन 5.6 में बताई गई ऑडियो लेटेंसी की ज़रूरी शर्तों को पूरा करना ज़रूरी है.
[एसआर] सेक्शन 7.8.3 में बताए गए तरीके से, नियर-अल्ट्रासाउंड रिकॉर्डिंग की सुविधा देने का सुझाव दिया जाता है.

अगर डिवाइसों में माइक्रोफ़ोन नहीं है, तो:

[C-2-1] android.hardware.microphone सुविधा के कॉन्स्टेंट की जानकारी नहीं देनी चाहिए.
[C-2-2] सेक्शन 7 के मुताबिक, ऑडियो रिकॉर्डिंग वाले एपीआई को कम से कम no-ops के तौर पर लागू करना ज़रूरी है.

7.8.2. ऑडियो आउटपुट

अगर डिवाइसों में स्पीकर या ऑडियो/मल्टीमीडिया आउटपुट पोर्ट शामिल हैं, ताकि ऑडियो आउटपुट पेरिफ़ेरल का इस्तेमाल किया जा सके. जैसे, 4 कंडक्टर वाला 3.5 मि॰मी॰ ऑडियो जैक या यूएसबी ऑडियो क्लास का इस्तेमाल करने वाला यूएसबी होस्ट मोड पोर्ट, तो:

[C-1-1] android.hardware.audio.output सुविधा के कॉन्सटेंट की जानकारी देना ज़रूरी है.
[C-1-2] को 5.5 सेक्शन में बताई गई, ऑडियो चलाने की ज़रूरी शर्तों को पूरा करना होगा.
[C-1-3] सेक्शन 5.6 में बताई गई ऑडियो लेटेंसी की ज़रूरी शर्तों को पूरा करना ज़रूरी है.
[SR] सेक्शन 7.8.3 में बताए गए तरीके से, नियर-अल्ट्रासाउंड चलाने की सुविधा देने का सुझाव दिया जाता है.

अगर डिवाइसों में स्पीकर या ऑडियो आउटपुट पोर्ट शामिल नहीं है, तो:

[C-2-1] android.hardware.audio.output सुविधा की जानकारी नहीं देनी चाहिए.
[C-2-2] ऑडियो आउटपुट से जुड़े एपीआई को कम से कम नो-ऑप के तौर पर लागू करना ज़रूरी है.

इस सेक्शन के लिए, "आउटपुट पोर्ट" एक फ़िज़िकल इंटरफ़ेस होता है. जैसे, 3.5 मि॰मी॰ ऑडियो जैक, एचडीएमआई या यूएसबी ऑडियो क्लास वाला यूएसबी होस्ट मोड पोर्ट. रेडियो पर आधारित प्रोटोकॉल, जैसे कि ब्लूटूथ, वाईफ़ाई या मोबाइल नेटवर्क पर ऑडियो आउटपुट की सुविधा को "आउटपुट पोर्ट" के तौर पर शामिल नहीं किया जाता.

7.8.2.1. ऐनालॉग ऑडियो पोर्ट

Android इकोसिस्टम में 3.5 मि॰मी॰ के ऑडियो प्लग का इस्तेमाल करने वाले हेडसेट और अन्य ऑडियो ऐक्सेसरी के साथ काम करने के लिए, अगर डिवाइसों में एक या उससे ज़्यादा ऐनलॉग ऑडियो पोर्ट शामिल हैं, तो:

[C-SR] कम से कम एक ऑडियो पोर्ट में, चार कंडक्टर वाला 3.5 मि॰मी॰ का ऑडियो जैक शामिल करने का सुझाव दिया जाता है.

अगर डिवाइसों में चार कंडक्टर वाला 3.5 मि॰मी॰ का ऑडियो जैक है, तो:

[C-1-1] इसमें स्टीरियो हेडफ़ोन और माइक्रोफ़ोन वाले स्टीरियो हेडसेट पर ऑडियो चलाने की सुविधा होनी चाहिए.
[C-1-2] ज़रूरी है कि डिवाइस, CTIA पिन-आउट ऑर्डर वाले टीआरआरएस ऑडियो प्लग के साथ काम करता हो.
[C-1-3] ऑडियो प्लग पर माइक्रोफ़ोन और ग्राउंड कंडक्टर के बीच, एक जैसे इंपीडेंस की इन तीन रेंज के लिए, कीकोड का पता लगाने और उन्हें मैप करने की सुविधा होनी चाहिए:
- 70 ओम या उससे कम: KEYCODE_HEADSETHOOK
- 210-290 ओम: KEYCODE_VOLUME_UP
- 360-680 ओम: KEYCODE_VOLUME_DOWN
[C-1-4] प्लग डालने पर, ACTION_HEADSET_PLUG को ट्रिगर करना ज़रूरी है. हालांकि, ऐसा सिर्फ़ तब होना चाहिए, जब प्लग पर मौजूद सभी संपर्क, जैक पर मौजूद अपने-अपने सेगमेंट को छू रहे हों.
[C-1-5] 32 ओम के स्पीकर इंपीडेंस पर, कम से कम 150mV ± 10% का आउटपुट वोल्टेज देने में सक्षम होना चाहिए.
[C-1-6] माइक्रोफ़ोन का बायस वोल्टेज 1.8V से 2.9V के बीच होना चाहिए.
[C-1-7] ऑडियो प्लग पर माइक्रोफ़ोन और ग्राउंड कंडक्टर के बीच, यहां दी गई रेंज के बराबर इंपीडेंस के लिए, कीकोड का पता लगाना और उसे मैप करना ज़रूरी है:
- 110-180 ओम: KEYCODE_VOICE_ASSIST
[C-SR] ओएमटीपी पिन-आउट ऑर्डर के साथ ऑडियो प्लग इस्तेमाल करने का सुझाव दिया जाता है.
[C-SR] यह सुझाव दिया जाता है कि डिवाइस में, माइक्रोफ़ोन वाले स्टीरियो हेडसेट से ऑडियो रिकॉर्ड करने की सुविधा हो.

अगर डिवाइसों में चार कंडक्टर वाला 3.5 मि॰मी॰ का ऑडियो जैक है और वे माइक्रोफ़ोन के साथ काम करते हैं, तो उन्हें android.intent.action.HEADSET_PLUG को ब्रॉडकास्ट करना होगा. इसमें माइक्रोफ़ोन की अतिरिक्त वैल्यू को 1 के तौर पर सेट करना होगा. ऐसा करने पर:

[C-2-1] ज़रूरी है कि प्लग इन की गई ऑडियो ऐक्सेसरी पर माइक्रोफ़ोन का पता लगाने की सुविधा काम करे.

7.8.2.2. डिजिटल ऑडियो पोर्ट

यह Android यूएसबी हेडसेट के स्पेसिफ़िकेशन में बताए गए तरीके से, Android के सभी डिवाइसों पर यूएसबी-सी कनेक्टर का इस्तेमाल करने वाले हेडसेट और अन्य ऑडियो ऐक्सेसरी के साथ काम करता है.

डिवाइस से जुड़ी ज़रूरी शर्तों के लिए, सेक्शन 2.2.1 देखें.

7.8.3. अल्ट्रासाउंड के आस-पास की फ़्रीक्वेंसी

नियर-अल्ट्रासाउंड ऑडियो, 18.5 किलोहर्ट्ज़ से 20 किलोहर्ट्ज़ बैंड होता है.

डिवाइस में सेट किए गए सिस्टम के लिए:

AudioManager.getProperty एपीआई के ज़रिए, नियर-अल्ट्रासाउंड ऑडियो की सुविधा के बारे में सही जानकारी देनी होगी. इसके लिए, यह तरीका अपनाएं:

अगर PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND "सही" है, तो VOICE_RECOGNITION और UNPROCESSED ऑडियो सोर्स को इन ज़रूरी शर्तों को पूरा करना होगा:

[C-1-1] 18.5 किलोहर्ट्ज़ से 20 किलोहर्ट्ज़ बैंड में माइक्रोफ़ोन की औसत पावर रिस्पॉन्स, 2 किलोहर्ट्ज़ पर रिस्पॉन्स से 15 dB से ज़्यादा कम नहीं होना चाहिए.
[C-1-2] 18.5 किलोहर्ट्ज़ से 20 किलोहर्ट्ज़ की फ़्रीक्वेंसी वाले माइक्रोफ़ोन के लिए, 19 किलोहर्ट्ज़ टोन पर -26 dBFS का अनवेटेड सिग्नल-टू-नॉइज़ रेशियो 50 dB से कम नहीं होना चाहिए.

अगर PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND "true" है, तो:

[C-2-1] स्पीकर का 18.5 किलोहर्ट्ज़ से 20 किलोहर्ट्ज़ के बीच का औसत रिस्पॉन्स, 2 किलोहर्ट्ज़ के रिस्पॉन्स से 40 डेसिबल से कम नहीं होना चाहिए.

7.8.4. सिग्नल इंटिग्रिटी

डिवाइसों पर लागू होने वाली शर्तें: * हैंडहेल्ड डिवाइसों पर, इनपुट और आउटपुट, दोनों स्ट्रीम के लिए बिना किसी गड़बड़ी वाला ऑडियो सिग्नल पाथ उपलब्ध कराना चाहिए. गड़बड़ी न होने की यह शर्त, हर पाथ के लिए एक मिनट के टेस्ट के दौरान मापी गई गड़बड़ियों के आधार पर तय की जाती है. [OboeTester] (https://github.com/google/oboe/tree/master/apps/OboeTester) का इस्तेमाल करके, “ऑटोमेटेड ग्लिच टेस्ट” करें.

इस टेस्ट के लिए, ऑडियो लूपबैक डोंगल की ज़रूरत होती है. इसे सीधे तौर पर 3.5 मि॰मी॰ के जैक में इस्तेमाल किया जाता है. इसके अलावा, इसे यूएसबी-सी से 3.5 मि॰मी॰ वाले अडैप्टर के साथ भी इस्तेमाल किया जा सकता है. सभी ऑडियो आउटपुट पोर्ट की जांच की जानी चाहिए.

OboeTester फ़िलहाल AAudio पाथ के साथ काम करता है. इसलिए, AAudio का इस्तेमाल करके गड़बड़ियों की जांच के लिए, इन कॉम्बिनेशन की जांच की जानी चाहिए:

परफ़ मोड	शेयर करें	आउट सैंपल रेट	इन चैनल्स में	आउट चैन
LOW_LATENCY	EXCLUSIVE	जानकारी नहीं दी गई है	1	2
LOW_LATENCY	EXCLUSIVE	जानकारी नहीं दी गई है	2	1
LOW_LATENCY	शेयर किया गया	जानकारी नहीं दी गई है	1	2
LOW_LATENCY	शेयर किया गया	जानकारी नहीं दी गई है	2	1
कोई नहीं	शेयर किया गया	48000	1	2
कोई नहीं	शेयर किया गया	48000	2	1
कोई नहीं	शेयर किया गया	44100	1	2
कोई नहीं	शेयर किया गया	44100	2	1
कोई नहीं	शेयर किया गया	16000	1	2
कोई नहीं	शेयर किया गया	16000	2	1

भरोसेमंद स्ट्रीम के लिए, 2000 हर्ट्ज़ की साइन वेव के लिए सिग्नल टू नॉइज़ रेशियो (एसएनआर) और टोटल हार्मोनिक डिस्टॉर्शन (टीएचडी) इन शर्तों के मुताबिक होना चाहिए.

ट्रांसड्यूसर	THD	SNR
प्राइमरी बिल्ट-इन स्पीकर, जिसे बाहरी रेफ़रंस माइक्रोफ़ोन का इस्तेमाल करके मापा गया है	< 3.0%	>= 50 dB
पहले से मौजूद मुख्य माइक्रोफ़ोन, जिसे बाहरी रेफ़रंस स्पीकर का इस्तेमाल करके मेज़र किया गया है	< 3.0%	>= 50 dB
पहले से मौजूद एनालॉग 3.5 मि॰मी॰ जैक, लूपबैक अडैप्टर का इस्तेमाल करके टेस्ट किए गए	< 1%	>= 60 dB
फ़ोन के साथ मिले यूएसबी अडैप्टर, जिनकी जांच लूपबैक अडैप्टर का इस्तेमाल करके की गई है	< 1.0%	>= 60 dB

7.9. आभासी वास्तविकता

Android में, "वर्चुअल रिएलिटी" (वीआर) ऐप्लिकेशन बनाने के लिए एपीआई और सुविधाएं शामिल हैं. इनमें मोबाइल वीआर के लिए अच्छी क्वालिटी वाले अनुभव भी शामिल हैं. डिवाइसों में इन एपीआई और व्यवहारों को सही तरीके से लागू करना ज़रूरी है. इस बारे में इस सेक्शन में बताया गया है.

7.9.1. वर्चुअल रिएलिटी मोड

Android में वीआर मोड की सुविधा उपलब्ध है. यह सुविधा, सूचनाओं को स्टीरियोस्कोपिक तरीके से रेंडर करती है. साथ ही, जब कोई वीआर ऐप्लिकेशन फ़ोकस में होता है, तब मोनोकुलर सिस्टम यूज़र इंटरफ़ेस (यूआई) कॉम्पोनेंट को बंद कर देती है.

7.9.2. वर्चुअल रिएलिटी मोड - हाई परफ़ॉर्मेंस

अगर डिवाइस में वीआर मोड काम करता है, तो:

[C-1-1] कम से कम दो फ़िज़िकल कोर होने चाहिए.
[C-1-2] android.hardware.vr.high_performance सुविधा के बारे में एलान करना ज़रूरी है.
[C-1-3] इसमें लगातार परफ़ॉर्म करने वाला मोड काम करना चाहिए.
[C-1-4] OpenGL ES 3.2 को सपोर्ट करने का सुझाव दिया जाता है.
[C-1-5] android.hardware.vulkan.level 0 के साथ काम करना ज़रूरी है.
android.hardware.vulkan.level 1 या इसके बाद के वर्शन पर काम करना चाहिए.
[C-1-6] EGL_KHR_mutable_render_buffer, EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_get_native_client_buffer, EGL_KHR_fence_sync, EGL_KHR_wait_sync, EGL_IMG_context_priority, EGL_EXT_protected_content, EGL_EXT_image_gl_colorspace को लागू करना ज़रूरी है. साथ ही, उपलब्ध EGL एक्सटेंशन की सूची में एक्सटेंशन दिखाना ज़रूरी है.
[C-1-8] GL_EXT_multisampled_render_to_texture2, GL_OVR_multiview, GL_OVR_multiview2, GL_EXT_protected_textures को लागू करना ज़रूरी है. साथ ही, उपलब्ध GL एक्सटेंशन की सूची में एक्सटेंशन दिखाना ज़रूरी है.
[C-SR] GL_EXT_external_buffer, GL_EXT_EGL_image_array, GL_OVR_multiview_multisampled_render_to_texture को लागू करने का सुझाव दिया जाता है. साथ ही, उपलब्ध GL एक्सटेंशन की सूची में एक्सटेंशन दिखाने का सुझाव दिया जाता है.
[C-SR] Vulkan 1.1 के साथ काम करने का सुझाव दिया जाता है.
[C-SR] VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing, VK_KHR_shared_presentable_image को लागू करने का सुझाव दिया जाता है. साथ ही, इसे उपलब्ध Vulkan एक्सटेंशन की सूची में शामिल करने का सुझाव दिया जाता है.
[C-SR] कम से कम एक Vulkan क्यू फ़ैमिली को दिखाने का सुझाव दिया जाता है. इसमें flags में VK_QUEUE_GRAPHICS_BIT और VK_QUEUE_COMPUTE_BIT दोनों शामिल हों और queueCount कम से कम 2 हो.
[C-1-7] जीपीयू और डिसप्ले को शेयर किए गए फ़्रंट बफ़र को इस तरह से ऐक्सेस करना चाहिए कि वीआर कॉन्टेंट को 60 फ़्रेम प्रति सेकंड (एफ़पीएस) पर रेंडर करने के लिए, दो रेंडर कॉन्टेक्स्ट के साथ बारी-बारी से आंखों को रेंडर किया जा सके. साथ ही, डिसप्ले में कोई भी विज़िबल टियरिंग आर्टफ़ैक्ट न दिखे.
[C-1-9] NDK में बताए गए तरीके के मुताबिक, AHardwareBuffer फ़्लैग AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA, और AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT के लिए सहायता लागू करना ज़रूरी है.
[C-1-10] यह ज़रूरी है कि डिवाइस, AHardwareBuffer के साथ इस्तेमाल किए जाने वाले फ़्लैग AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT के किसी भी कॉम्बिनेशन को सपोर्ट करता हो. साथ ही, कम से कम इन फ़ॉर्मैट को सपोर्ट करता हो: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
[C-SR] यह सुझाव दिया जाता है कि AHardwareBuffers को एक से ज़्यादा लेयर और C-1-10 में बताए गए फ़्लैग और फ़ॉर्मैट के साथ काम करना चाहिए.
[C-1-11] H.264 डिकोडिंग के साथ काम करना ज़रूरी है. यह कम से कम 3840 x 2160 पिक्सल पर 30 एफ़पीएस पर काम करना चाहिए. इसे औसतन 40 एमबीपीएस पर कंप्रेस किया गया हो. यह 1920 x 1080 पिक्सल पर 30 एफ़पीएस पर 10 एमबीपीएस के चार इंस्टेंस या 1920 x 1080 पिक्सल पर 60 एफ़पीएस पर 20 एमबीपीएस के दो इंस्टेंस के बराबर है.
[C-1-12] इसमें HEVC और VP9 को सपोर्ट करने की सुविधा होनी चाहिए. साथ ही, यह 30 एफ़पीएस पर कम से कम 1920 x 1080 पिक्सल वाले वीडियो को डिकोड कर सके. इस वीडियो को औसतन 10 एमबीपीएस पर कंप्रेस किया गया हो. इसके अलावा, यह 30 एफ़पीएस पर 3840 x 2160 पिक्सल वाले वीडियो को डिकोड कर सके. इस वीडियो को 20 एमबीपीएस पर कंप्रेस किया गया हो. यह 30 एफ़पीएस पर 1920 x 1080 पिक्सल वाले चार वीडियो को डिकोड करने के बराबर है. इन वीडियो को 5 एमबीपीएस पर कंप्रेस किया गया हो.
[C-1-13] HardwarePropertiesManager.getDeviceTemperatures एपीआई के साथ काम करना चाहिए और त्वचा के तापमान की सटीक वैल्यू दिखानी चाहिए.
[C-1-14] में एक एम्बेड की गई स्क्रीन होनी चाहिए. साथ ही, इसका रिज़ॉल्यूशन कम से कम 1920 x 1080 होना चाहिए.
[C-SR] इनका डिसप्ले रिज़ॉल्यूशन कम से कम 2560 x 1440 होना चाहिए.
[C-1-15] VR मोड में, डिसप्ले कम से कम 60 हर्ट्ज़ पर अपडेट होना चाहिए.
[C-1-17] डिसप्ले में लो-पर्सिस्टेंस मोड काम करना चाहिए. साथ ही, पर्सिस्टेंस 5 मिलीसेकंड या इससे कम होना चाहिए. पर्सिस्टेंस का मतलब है कि कोई पिक्सल कितने समय तक रोशनी देता है.
[C-1-18] इनमें ब्लूटूथ 4.2 और ब्लूटूथ स्मार्ट डेटा लेंथ एक्सटेंशन सेक्शन 7.4.3 काम करना चाहिए.
[C-1-19] इन सभी डिफ़ॉल्ट सेंसर टाइप के लिए, डायरेक्ट चैनल टाइप को सपोर्ट करना और उसकी सही जानकारी देना ज़रूरी है:
- TYPE_ACCELEROMETER
- TYPE_ACCELEROMETER_UNCALIBRATED
- TYPE_GYROSCOPE
- TYPE_GYROSCOPE_UNCALIBRATED
- TYPE_MAGNETIC_FIELD
- TYPE_MAGNETIC_FIELD_UNCALIBRATED
[C-SR] यह सुझाव दिया जाता है कि ऊपर दिए गए सभी डायरेक्ट चैनल टाइप के लिए, TYPE_HARDWARE_BUFFER डायरेक्ट चैनल टाइप का इस्तेमाल किया जाए.
[C-1-21] android.hardware.hifi_sensors के लिए, जाइरोस्कोप, एक्सलरोमीटर, और मैग्नेटोमीटर से जुड़ी ज़रूरी शर्तों को पूरा करना ज़रूरी है. इनके बारे में सेक्शन 7.3.9 में बताया गया है.
[C-SR] android.hardware.sensor.hifi_sensors सुविधा को इस्तेमाल करने का सुझाव दिया जाता है.
[C-1-22] MUST have end-to-end motion to photon latency not higher than 28 milliseconds.
[C-SR] यह सुझाव दिया जाता है कि मोशन से फ़ोटॉन तक की एंड-टू-एंड लेटेन्सी 20 मिलीसेकंड से ज़्यादा न हो.
[C-1-23] इसमें पहले फ़्रेम का रेशियो कम से कम 85% होना चाहिए. यह रेशियो, काले से सफ़ेद रंग में ट्रांज़िशन होने के बाद पहले फ़्रेम के पिक्सल की चमक और स्थिर स्थिति में सफ़ेद पिक्सल की चमक के बीच का रेशियो होता है.
[C-SR] हमारा सुझाव है कि पहले फ़्रेम का अनुपात कम से कम 90% होना चाहिए.
स्क्रीन पर दिखने वाले ऐप्लिकेशन को खास तौर पर एक कोर उपलब्ध करा सकता है. साथ ही, Process.getExclusiveCores एपीआई के साथ काम कर सकता है, ताकि स्क्रीन पर दिखने वाले टॉप ऐप्लिकेशन के लिए खास तौर पर उपलब्ध सीपीयू कोर की संख्या दिखाई जा सके.

अगर एक्सक्लूसिव कोर की सुविधा काम करती है, तो कोर:

[C-2-1] इसमें किसी भी अन्य यूज़रस्पेस प्रोसेस को चलने की अनुमति नहीं होनी चाहिए. हालांकि, ऐप्लिकेशन के इस्तेमाल किए गए डिवाइस ड्राइवर को चलने की अनुमति दी जा सकती है. साथ ही, ज़रूरत के मुताबिक कुछ कर्नल प्रोसेस को चलने की अनुमति दी जा सकती है.

7.10. हैप्टिक

डिवाइस से जुड़ी ज़रूरी शर्तों के लिए, सेक्शन 2.2.1 देखें.

7.11. मीडिया परफ़ॉर्मेंस क्लास

डिवाइस पर लागू की गई मीडिया परफ़ॉर्मेंस क्लास की जानकारी, android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS एपीआई से मिल सकती है. मीडिया परफ़ॉर्मेंस क्लास की ज़रूरी शर्तें, Android के हर वर्शन के लिए तय की गई हैं. ये शर्तें, R (वर्शन 30) से शुरू होने वाले वर्शन के लिए तय की गई हैं. खास वैल्यू 0 से पता चलता है कि डिवाइस, मीडिया परफ़ॉर्मेंस क्लास का नहीं है.

अगर डिवाइसों पर लागू किए गए android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS फ़ंक्शन से शून्य के अलावा कोई और वैल्यू मिलती है, तो:

[C-1-1] कम से कम android.os.Build.VERSION_CODES.R की वैल्यू रिटर्न होनी चाहिए.
[C-1-2] इसे हाथ में पकड़कर इस्तेमाल किए जाने वाले डिवाइस पर लागू किया जाना चाहिए.
[C-1-3] सेक्शन 2.2.7 में बताई गई "मीडिया परफ़ॉर्मेंस क्लास" की सभी ज़रूरी शर्तों को पूरा करना होगा.

डिवाइस के हिसाब से ज़रूरी शर्तें जानने के लिए, सेक्शन 2.2.7 देखें.

8. परफ़ॉर्मेंस और पावर

उपयोगकर्ता अनुभव के लिए, परफ़ॉर्मेंस और पावर से जुड़ी कुछ ज़रूरी शर्तें पूरी करना ज़रूरी है. साथ ही, इनसे डेवलपर की उन बुनियादी मान्यताओं पर असर पड़ता है जो वे ऐप्लिकेशन डेवलप करते समय रखते हैं.

8.1. उपयोगकर्ता अनुभव में एकरूपता

अगर ऐप्लिकेशन और गेम के लिए, फ़्रेम रेट और रिस्पॉन्स टाइम को एक जैसा बनाए रखने के लिए कुछ ज़रूरी शर्तें पूरी की जाती हैं, तो असली उपयोगकर्ता को बेहतर यूज़र इंटरफ़ेस दिया जा सकता है. डिवाइस के टाइप के आधार पर, डिवाइस में सेट किए गए सिस्टम के लिए यूज़र इंटरफ़ेस के इंतज़ार के समय और टास्क स्विच करने से जुड़ी ज़रूरी शर्तें हो सकती हैं. इनके बारे में सेक्शन 2 में बताया गया है.

8.2. फ़ाइल I/O ऐक्सेस की परफ़ॉर्मेंस

ऐप्लिकेशन के निजी डेटा स्टोरेज (/data पार्टीशन) पर फ़ाइल ऐक्सेस करने की परफ़ॉर्मेंस के लिए, एक सामान्य बेसलाइन उपलब्ध कराने से ऐप्लिकेशन डेवलपर को सही उम्मीद सेट करने में मदद मिलती है. इससे उन्हें अपने सॉफ़्टवेयर को डिज़ाइन करने में मदद मिलती है. डिवाइस के टाइप के हिसाब से, डिवाइस में सेट किए गए सिस्टम के लिए, दूसरे सेक्शन में बताई गई कुछ ज़रूरी शर्तें हो सकती हैं. ये शर्तें, पढ़ने और लिखने से जुड़ी इन कार्रवाइयों के लिए होती हैं:

सीक्वेंशियल राइट परफ़ॉर्मेंस. इसे 10 एमबी के राइट बफ़र का इस्तेमाल करके, 256 एमबी की फ़ाइल लिखने के आधार पर मापा जाता है.
रैंडम राइट परफ़ॉर्मेंस. इसे 4 केबी के राइट बफ़र का इस्तेमाल करके, 256 एमबी की फ़ाइल लिखने के आधार पर मापा जाता है.
सीक्वेंशियल रीड परफ़ॉर्मेंस. इसे 10 एमबी के राइट बफ़र का इस्तेमाल करके, 256 एमबी की फ़ाइल को पढ़ने के आधार पर मापा जाता है.
रैंडम रीड परफ़ॉर्मेंस. इसकी जांच, 4 केबी के राइट बफ़र का इस्तेमाल करके 256 एमबी की फ़ाइल को पढ़कर की गई है.

8.3. बैटरी सेव करने वाले मोड

अगर डिवाइसों में, डिवाइस की बैटरी को बेहतर तरीके से मैनेज करने की सुविधाएं शामिल हैं, तो उन्हें AOSP में शामिल किया जाता है.जैसे, ऐप्लिकेशन स्टैंडबाय बकेट, डोज़ मोड. इसके अलावा, अगर डिवाइसों में ऐसी सुविधाएं शामिल हैं जिन पर रेयर ऐप्लिकेशन स्टैंडबाय बकेट से ज़्यादा पाबंदियां लागू नहीं होती हैं, तो:

[C-1-1] ऐप्लिकेशन स्टैंडबाय और बैटरी बचाने वाले डोज़ मोड की ग्लोबल सिस्टम सेटिंग के इस्तेमाल के लिए, ट्रिगर करने, रखरखाव करने, और वेकअप एल्गोरिदम के लिए, एओएसपी के लागू करने के तरीके से अलग नहीं होना चाहिए.
[C-1-2] ऐप्लिकेशन स्टैंडबाय मोड में, हर बकेट में मौजूद ऐप्लिकेशन के लिए, ग्लोबल सेटिंग का इस्तेमाल करके जॉब, अलार्म, और नेटवर्क को मैनेज करने के लिए, AOSP के लागू करने के तरीके से अलग नहीं होना चाहिए.
[C-1-3] ऐप्लिकेशन स्टैंडबाय के लिए इस्तेमाल किए जाने वाले ऐप्लिकेशन स्टैंडबाय बकेट की संख्या के लिए, AOSP के लागू करने के तरीके से अलग नहीं होना चाहिए.
[C-1-4] पावर मैनेजमेंट में बताए गए तरीके के मुताबिक, ऐप्लिकेशन स्टैंडबाय बकेट और डोज़ मोड को लागू करना ज़रूरी है.
[C-1-5] डिवाइस के पावर सेव मोड में होने पर, PowerManager.isPowerSaveMode() के लिए true को जवाब देना होगा.
[C-SR] उपयोगकर्ताओं को बैटरी सेवर की सुविधा चालू और बंद करने का विकल्प देने का सुझाव दिया जाता है.
[C-SR] हमारा सुझाव है कि उपयोगकर्ताओं को ऐसे सभी ऐप्लिकेशन दिखाने की सुविधा दें जिन्हें ऐप्लिकेशन स्टैंडबाय और बैटरी बचाने वाले मोड से छूट मिली है.

अगर डिवाइसों में, AOSP में शामिल पावर मैनेजमेंट की सुविधाओं को बढ़ाया जाता है और यह एक्सटेंशन, रेयर ऐप्लिकेशन स्टैंडबाय बकेट की तुलना में ज़्यादा सख्त पाबंदियां लागू करता है, तो सेक्शन 3.5.1 देखें.

पावर सेविंग मोड के अलावा, Android डिवाइस में सेट किए गए सिस्टम, स्लीपिंग पावर स्टेट के चारों मोड में से किसी एक या सभी को लागू कर सकते हैं. इन मोड को ऐडवांस कॉन्फ़िगरेशन ऐंड पावर इंटरफ़ेस (एसीपीआई) के तहत तय किया गया है.

अगर डिवाइस में ACPI के हिसाब से S4 पावर स्टेट लागू की जाती है, तो:

[C-1-1] यह स्थिति तब ही शुरू होनी चाहिए, जब उपयोगकर्ता ने डिवाइस को बंद करने के लिए कोई कार्रवाई की हो. जैसे, डिवाइस का ढक्कन बंद करना या वाहन या टीवी बंद करना. साथ ही, यह स्थिति तब तक जारी रहनी चाहिए, जब तक उपयोगकर्ता डिवाइस को फिर से चालू न कर दे. जैसे, ढक्कन खोलना या वाहन या टीवी को फिर से चालू करना.

अगर डिवाइस में ACPI के हिसाब से S3 पावर स्टेट लागू की जाती है, तो:

[C-2-1] ऊपर दी गई C-1-1 की ज़रूरी शर्तों को पूरा करना होगा. इसके अलावा, S3 मोड में सिर्फ़ तब जाना चाहिए, जब तीसरे पक्ष के ऐप्लिकेशन को सिस्टम रिसॉर्स (जैसे कि स्क्रीन, सीपीयू) की ज़रूरत न हो.

इसके उलट, जब तीसरे पक्ष के ऐप्लिकेशन को सिस्टम संसाधनों की ज़रूरत हो, तो S3 मोड से बाहर निकलना ज़रूरी है. इसके बारे में इस SDK टूल में बताया गया है.

उदाहरण के लिए, तीसरे पक्ष के ऐप्लिकेशन FLAG_KEEP_SCREEN_ON के ज़रिए स्क्रीन चालू रखने या PARTIAL_WAKE_LOCK के ज़रिए सीपीयू चालू रखने का अनुरोध करते हैं. हालांकि, डिवाइस को S3 स्टेट में तब तक नहीं जाना चाहिए, जब तक कि उपयोगकर्ता ने C-1-1 में बताए गए तरीके से, डिवाइस को निष्क्रिय स्थिति में रखने के लिए साफ़ तौर पर कोई कार्रवाई न की हो. इसके उलट, जब JobScheduler के ज़रिए तीसरे पक्ष के ऐप्लिकेशन लागू किए गए किसी टास्क को ट्रिगर किया जाता है या Firebase Cloud Messaging को तीसरे पक्ष के ऐप्लिकेशन पर डिलीवर किया जाता है, तो डिवाइस को S3 मोड से बाहर निकलना होगा. ऐसा तब तक नहीं किया जा सकता, जब तक उपयोगकर्ता ने डिवाइस को निष्क्रिय मोड में न रखा हो. ये पूरी तरह से उदाहरण नहीं हैं. AOSP, इस स्थिति से डिवाइस को चालू करने के लिए कई वेक-अप सिग्नल लागू करता है.

8.4. ऊर्जा की खपत का हिसाब रखने की सुविधा

ऊर्जा की खपत का ज़्यादा सटीक हिसाब और रिपोर्टिंग से, ऐप्लिकेशन डेवलपर को इंसेंटिव और ऐसे टूल मिलते हैं जिनकी मदद से, ऐप्लिकेशन में ऊर्जा के इस्तेमाल के पैटर्न को ऑप्टिमाइज़ किया जा सकता है.

डिवाइस में सेट किए गए सिस्टम के लिए:

[SR] हर कॉम्पोनेंट के लिए पावर प्रोफ़ाइल देने का सुझाव दिया जाता है. इससे हर हार्डवेयर कॉम्पोनेंट के लिए, करंट की खपत की वैल्यू और समय के साथ कॉम्पोनेंट की वजह से बैटरी खत्म होने की अनुमानित जानकारी मिलती है. यह जानकारी, Android Open Source Project की साइट पर मौजूद है.
[SR] बिजली की खपत की सभी वैल्यू को मिलीऐंपियर घंटे (mAh) में रिपोर्ट करने का सुझाव दिया जाता है.
[SR] हर प्रोसेस के यूआईडी के हिसाब से, सीपीयू की पावर खपत की जानकारी देने का सुझाव दिया जाता है. Android ओपन सोर्स प्रोजेक्ट, uid_cputime कर्नेल मॉड्यूल को लागू करके इस ज़रूरी शर्त को पूरा करता है.
[SR] हमारा सुझाव है कि ऐप्लिकेशन डेवलपर को, adb shell dumpsys batterystats शेल कमांड के ज़रिए बैटरी के इस्तेमाल की जानकारी उपलब्ध कराई जाए.
अगर किसी ऐप्लिकेशन को हार्डवेयर कॉम्पोनेंट के पावर इस्तेमाल करने का श्रेय नहीं दिया जा सकता, तो हार्डवेयर कॉम्पोनेंट को ही इसका श्रेय दिया जाना चाहिए.

8.5. लगातार अच्छी परफ़ॉर्मेंस

ज़्यादा परफ़ॉर्मेंस वाले और लंबे समय तक चलने वाले ऐप्लिकेशन की परफ़ॉर्मेंस में काफ़ी उतार-चढ़ाव हो सकता है. ऐसा बैकग्राउंड में चल रहे अन्य ऐप्लिकेशन या तापमान की सीमा की वजह से सीपीयू थ्रॉटलिंग की वजह से हो सकता है. Android में प्रोग्रामैटिक इंटरफ़ेस शामिल होते हैं, ताकि जब डिवाइस में ज़रूरी क्षमता हो, तो टॉप फ़ोरग्राउंड ऐप्लिकेशन, सिस्टम से अनुरोध कर सके कि वह इन उतार-चढ़ावों को ठीक करने के लिए संसाधनों के बंटवारे को ऑप्टिमाइज़ करे.

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-1] PowerManager.isSustainedPerformanceModeSupported() एपीआई तरीके का इस्तेमाल करके, यह सटीक जानकारी देना ज़रूरी है कि डिवाइस में Sustained Performance Mode की सुविधा काम करती है.
सस्टेंड परफ़ॉर्मेंस मोड काम करना चाहिए.

अगर डिवाइसों पर, परफ़ॉर्मेंस मोड को बनाए रखने की सुविधा काम करती है, तो:

[C-1-1] जब ऐप्लिकेशन अनुरोध करता है, तो उसे कम से कम 30 मिनट तक, टॉप फ़ोरग्राउंड ऐप्लिकेशन के लिए एक जैसी परफ़ॉर्मेंस देनी होगी.
[C-1-2] Window.setSustainedPerformanceMode() एपीआई और इससे जुड़े अन्य एपीआई का पालन करना ज़रूरी है.

अगर डिवाइसों में दो या उससे ज़्यादा सीपीयू कोर शामिल हैं, तो:

इसमें कम से कम एक ऐसा कोर होना चाहिए जिसे सबसे ऊपर मौजूद ऐप्लिकेशन के लिए रिज़र्व किया जा सके.

अगर डिवाइस में, सबसे ऊपर दिखने वाले फ़ोरग्राउंड ऐप्लिकेशन के लिए एक कोर रिज़र्व करने की सुविधा काम करती है, तो:

[C-2-1] Process.getExclusiveCores() एपीआई के ज़रिए, एक्सक्लूसिव कोर के आईडी नंबर की जानकारी देनी होगी. इन कोर को टॉप फ़ोरग्राउंड ऐप्लिकेशन के लिए रिज़र्व किया जा सकता है.
[C-2-2] किसी भी यूज़र स्पेस प्रोसेस को अनुमति नहीं देनी चाहिए. हालांकि, ऐप्लिकेशन को एक्सक्लूसिव कोर पर चलाने के लिए इस्तेमाल किए जाने वाले डिवाइस ड्राइवर को अनुमति दी जा सकती है. साथ ही, ज़रूरत के मुताबिक कुछ कर्नल प्रोसेस को चलाने की अनुमति दी जा सकती है.

अगर डिवाइसों में एक्सक्लूसिव कोर की सुविधा काम नहीं करती है, तो:

[C-3-1] Process.getExclusiveCores() एपीआई मेथड के ज़रिए, खाली सूची को नतीजे के तौर पर दिखाना ज़रूरी है.

9. सुरक्षा मॉडल के साथ काम करने की सुविधा

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-1] Android डेवलपर के दस्तावेज़ में मौजूद एपीआई में, Android प्लैटफ़ॉर्म के सिक्योरिटी मॉडल के मुताबिक सिक्योरिटी मॉडल लागू करना ज़रूरी है. इसके बारे में सुरक्षा और अनुमतियों के बारे में जानकारी देने वाले दस्तावेज़ में बताया गया है.
[C-0-2] इसमें, तीसरे पक्ष/अधिकारियों से कोई अतिरिक्त अनुमति/सर्टिफ़िकेट लिए बिना, खुद के हस्ताक्षर वाले ऐप्लिकेशन इंस्टॉल करने की सुविधा होनी चाहिए. खास तौर पर, ज़रूरी है कि जिन डिवाइसों पर यह सुविधा काम करती है वे यहां दिए गए सुरक्षा के तरीकों के साथ काम करें.

9.1. अनुमतियां

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-1] Android डेवलपर के दस्तावेज़ में बताए गए Android के अनुमतियों वाले मॉडल के साथ काम करना ज़रूरी है. खास तौर पर, उन्हें एसडीके के दस्तावेज़ में बताई गई हर अनुमति को लागू करना होगा. किसी भी अनुमति को छोड़ा, बदला या अनदेखा नहीं किया जा सकता.
ज़्यादा अनुमतियां जोड़ सकता है. हालांकि, नई अनुमति आईडी स्ट्रिंग, android.\* नेमस्पेस में नहीं होनी चाहिए.
[C-0-2] PROTECTION_FLAG_PRIVILEGED के protectionLevel वाली अनुमतियां, सिर्फ़ उन ऐप्लिकेशन को दी जानी चाहिए जो सिस्टम इमेज के खास पाथ में पहले से इंस्टॉल हैं. साथ ही, ये अनुमतियां हर ऐप्लिकेशन के लिए, साफ़ तौर पर अनुमति दी गई अनुमतियों के सबसेट में होनी चाहिए. AOSP, इस ज़रूरी शर्त को पूरा करता है. इसके लिए, वह etc/permissions/ पाथ में मौजूद फ़ाइलों से, हर ऐप्लिकेशन के लिए अनुमति दी गई अनुमतियों को पढ़ता है और उनका पालन करता है. साथ ही, system/priv-app पाथ को खास पाथ के तौर पर इस्तेमाल करता है.

खतरनाक लेवल की सुरक्षा वाली अनुमतियां, रनटाइम की अनुमतियां होती हैं. targetSdkVersion > 22 वाले ऐप्लिकेशन, रनटाइम के दौरान अनुमति का अनुरोध करते हैं.

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-3] उपयोगकर्ता को एक खास इंटरफ़ेस दिखाना ज़रूरी है, ताकि वह यह तय कर सके कि रनटाइम की अनुमतियां देनी हैं या नहीं. साथ ही, उपयोगकर्ता को रनटाइम की अनुमतियां मैनेज करने के लिए भी एक इंटरफ़ेस उपलब्ध कराना ज़रूरी है.
[C-0-4] दोनों यूज़र इंटरफ़ेस को लागू करने का सिर्फ़ एक तरीका होना चाहिए.
[C-0-5] पहले से इंस्टॉल किए गए ऐप्लिकेशन को रनटाइम की कोई भी अनुमति तब तक नहीं दी जानी चाहिए, जब तक कि:
- ऐप्लिकेशन के इस डेटा का इस्तेमाल करने से पहले, उपयोगकर्ता की सहमति ली जा सकती है.
- रनटाइम की अनुमतियां, इंटेंट पैटर्न से जुड़ी होती हैं. इसके लिए, पहले से इंस्टॉल किए गए ऐप्लिकेशन को डिफ़ॉल्ट हैंडलर के तौर पर सेट किया जाता है.
[C-0-6] android.permission.RECOVER_KEYSTORE अनुमति सिर्फ़ उन सिस्टम ऐप्लिकेशन को देनी चाहिए जो सुरक्षित तरीके से रजिस्टर किए गए रिकवरी एजेंट हैं. सुरक्षित रिकवरी एजेंट, डिवाइस पर मौजूद एक ऐसा सॉफ़्टवेयर एजेंट होता है जो डिवाइस से बाहर मौजूद रिमोट स्टोरेज के साथ सिंक होता है. इसमें सुरक्षित हार्डवेयर होता है. यह हार्डवेयर, Google Cloud Key Vault Service में बताए गए सुरक्षा उपायों के बराबर या उससे ज़्यादा सुरक्षा देता है. इससे लॉकस्क्रीन के नॉलेज फ़ैक्टर पर ब्रूट-फ़ोर्स अटैक को रोका जा सकता है.

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-7] जब कोई ऐप्लिकेशन, स्टैंडर्ड Android API या मालिकाना हक वाले किसी तरीके से जगह की जानकारी या शारीरिक गतिविधि का डेटा ऐक्सेस करने का अनुरोध करता है, तो उसे Android की जगह की जानकारी ऐक्सेस करने की अनुमति से जुड़ी प्रॉपर्टी का पालन करना होगा. इस तरह के डेटा में ये चीज़ें शामिल हैं. हालांकि, इनके अलावा और भी चीज़ें हो सकती हैं:
- डिवाइस की जगह की जानकारी (जैसे, अक्षांश और देशांतर).
- ऐसी जानकारी जिसका इस्तेमाल डिवाइस की जगह का पता लगाने या उसका अनुमान लगाने के लिए किया जा सकता है. जैसे, एसएसआईडी, बीएसएसआईडी, सेल आईडी या डिवाइस जिस नेटवर्क से कनेक्ट है उसकी जगह की जानकारी.
- उपयोगकर्ता की शारीरिक गतिविधि या शारीरिक गतिविधि का क्लासिफ़िकेशन.

खास तौर पर, डिवाइस में सेट किए गए सिस्टम:

[C-0-8] किसी ऐप्लिकेशन को जगह की जानकारी या शारीरिक गतिविधि का डेटा ऐक्सेस करने की अनुमति देने के लिए, उपयोगकर्ता की सहमति लेना ज़रूरी है.
[C-0-9] सिर्फ़ उस ऐप्लिकेशन को रनटाइम की अनुमति मिलनी चाहिए जिसके पास एसडीके टूल में बताई गई ज़रूरी अनुमति हो. उदाहरण के लिए, TelephonyManager#getServiceState के लिए android.permission.ACCESS_FINE_LOCATION की ज़रूरत होती है.

अनुमतियों को 'पाबंदी लगाई गई' के तौर पर मार्क किया जा सकता है. इससे उनके व्यवहार में बदलाव होता है.

[C-0-10] hardRestricted फ़्लैग के साथ मार्क की गई अनुमतियां, किसी ऐप्लिकेशन को तब तक नहीं दी जानी चाहिए, जब तक कि:
- ऐप्लिकेशन की APK फ़ाइल, सिस्टम पार्टीशन में मौजूद हो.
- उपयोगकर्ता, ऐप्लिकेशन को hardRestricted की अनुमतियों से जुड़ी कोई भूमिका असाइन करता है.
- इंस्टॉलर, किसी ऐप्लिकेशन को hardRestricted की अनुमति देता है.
- किसी ऐप्लिकेशन को Android के पुराने वर्शन पर hardRestricted दिया गया हो.
[C-0-11] softRestricted की अनुमति रखने वाले ऐप्लिकेशन को सिर्फ़ सीमित ऐक्सेस मिलना चाहिए. साथ ही, उन्हें तब तक पूरा ऐक्सेस नहीं मिलना चाहिए, जब तक उन्हें एसडीके में बताए गए तरीके से अनुमति वाली सूची में शामिल न कर लिया जाए. एसडीके में, हर softRestricted की अनुमति के लिए पूरा और सीमित ऐक्सेस तय किया गया है. उदाहरण के लिए, READ_EXTERNAL_STORAGE.

अगर डिवाइसों पर, उपयोगकर्ताओं को यह चुनने की सुविधा मिलती है कि कौनसे ऐप्लिकेशन, ACTION_MANAGE_OVERLAY_PERMISSION इंटेंट को हैंडल करने वाली गतिविधि के साथ, दूसरे ऐप्लिकेशन के ऊपर दिख सकते हैं, तो:

[C-2-1] यह पक्का करना ज़रूरी है कि ACTION_MANAGE_OVERLAY_PERMISSION इंटेंट के लिए इंटेंट फ़िल्टर वाली सभी गतिविधियों में एक ही यूज़र इंटरफ़ेस (यूआई) स्क्रीन हो. भले ही, गतिविधि शुरू करने वाला ऐप्लिकेशन कोई भी हो या वह कोई भी जानकारी दे.

9.2. यूआईडी और प्रोसेस आइसोलेशन

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-1] Android ऐप्लिकेशन सैंडबॉक्स मॉडल के साथ काम करना ज़रूरी है. इसमें हर ऐप्लिकेशन, यूनीक Unixstyle UID के तौर पर और अलग प्रोसेस में चलता है.
[C-0-2] एक ही Linux यूज़र आईडी के तौर पर कई ऐप्लिकेशन चलाने की सुविधा होनी चाहिए. हालांकि, इसके लिए ज़रूरी है कि ऐप्लिकेशन पर सही तरीके से हस्ताक्षर किए गए हों और उन्हें सही तरीके से बनाया गया हो. इसके बारे में सुरक्षा और अनुमतियों के बारे में जानकारी में बताया गया है.

9.3. फ़ाइल सिस्टम से जुड़ी अनुमतियां

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-1] सुरक्षा और अनुमतियों के बारे में जानकारी में बताए गए Android के फ़ाइल ऐक्सेस करने की अनुमतियों वाले मॉडल के साथ काम करना ज़रूरी है.

9.4. वैकल्पिक एक्ज़ीक्यूशन एनवायरमेंट

डिवाइसों को Android के सुरक्षा और अनुमति मॉडल के साथ काम करना होगा. भले ही, उनमें ऐसे रनटाइम एनवायरमेंट शामिल हों जो Dalvik Executable Format या नेटिव कोड के अलावा, किसी अन्य सॉफ़्टवेयर या टेक्नोलॉजी का इस्तेमाल करके ऐप्लिकेशन चलाते हों. दूसरे शब्दों में:

[C-0-1] वैकल्पिक रनटाइम, Android ऐप्लिकेशन होने चाहिए. साथ ही, उन्हें Android के स्टैंडर्ड सुरक्षा मॉडल का पालन करना चाहिए. इसके बारे में सेक्शन 9 में बताया गया है.
[C-0-2] वैकल्पिक रनटाइम को उन संसाधनों का ऐक्सेस नहीं दिया जाना चाहिए जिन्हें उन अनुमतियों से सुरक्षित किया गया है जिनके लिए रनटाइम की AndroidManifest.xml फ़ाइल में <uses-permission> मेकेनिज़्म के ज़रिए अनुरोध नहीं किया गया है.
[C-0-3] अन्य रनटाइम को, ऐप्लिकेशन को ऐसी सुविधाओं का इस्तेमाल करने की अनुमति नहीं देनी चाहिए जिन्हें Android की अनुमतियों से सुरक्षित किया गया है. ये अनुमतियां, सिर्फ़ सिस्टम ऐप्लिकेशन के लिए उपलब्ध होती हैं.
[C-0-4] वैकल्पिक रनटाइम को Android सैंडबॉक्स मॉडल का पालन करना होगा. साथ ही, वैकल्पिक रनटाइम का इस्तेमाल करने वाले इंस्टॉल किए गए ऐप्लिकेशन, डिवाइस पर इंस्टॉल किए गए किसी अन्य ऐप्लिकेशन के सैंडबॉक्स का दोबारा इस्तेमाल नहीं कर सकते. हालांकि, वे शेयर किए गए उपयोगकर्ता आईडी और साइनिंग सर्टिफ़िकेट के स्टैंडर्ड Android तरीकों का इस्तेमाल कर सकते हैं.
[C-0-5] अन्य Android ऐप्लिकेशन से जुड़े सैंडबॉक्स को लॉन्च करने, उन्हें अनुमति देने या उनका ऐक्सेस पाने की अनुमति, अन्य रनटाइम को नहीं होनी चाहिए.
[C-0-6] वैकल्पिक रनटाइम को सुपरयूज़र (रूट) या किसी अन्य उपयोगकर्ता आईडी के किसी भी विशेषाधिकार के साथ लॉन्च नहीं किया जाना चाहिए, न ही उन्हें ये विशेषाधिकार दिए जाने चाहिए और न ही उन्हें अन्य ऐप्लिकेशन को ये विशेषाधिकार देने चाहिए.
[C-0-7] जब डिवाइस के सिस्टम इमेज में, वैकल्पिक रनटाइम की .apk फ़ाइलें शामिल की जाती हैं, तो उन पर ऐसी कुंजी से हस्ताक्षर किया जाना चाहिए जो डिवाइस के साथ शामिल किए गए अन्य ऐप्लिकेशन पर हस्ताक्षर करने के लिए इस्तेमाल की गई कुंजी से अलग हो.
[C-0-8] ऐप्लिकेशन इंस्टॉल करते समय, वैकल्पिक रनटाइम को Android की उन अनुमतियों के लिए उपयोगकर्ता की सहमति लेनी होगी जिनका इस्तेमाल ऐप्लिकेशन करता है.
[C-0-9] जब किसी ऐप्लिकेशन को किसी डिवाइस के ऐसे संसाधन का इस्तेमाल करना होता है जिसके लिए Android की अनुमति ज़रूरी है (जैसे, कैमरा, जीपीएस वगैरह), तो वैकल्पिक रनटाइम को उपयोगकर्ता को यह सूचना देनी होगी कि ऐप्लिकेशन उस संसाधन को ऐक्सेस कर पाएगा.
[C-0-10] जब रनटाइम एनवायरमेंट, ऐप्लिकेशन की क्षमताओं को इस तरह से रिकॉर्ड नहीं करता है, तो रनटाइम एनवायरमेंट को उस रनटाइम का इस्तेमाल करके किसी भी ऐप्लिकेशन को इंस्टॉल करते समय, रनटाइम के पास मौजूद सभी अनुमतियों की सूची बनानी होगी.
वैकल्पिक रनटाइम को, ऐप्लिकेशन को PackageManager के ज़रिए अलग-अलग Android सैंडबॉक्स (Linux उपयोगकर्ता आईडी वगैरह) में इंस्टॉल करना चाहिए.
वैकल्पिक रनटाइम, Android का एक ऐसा सैंडबॉक्स उपलब्ध करा सकते हैं जिसे वैकल्पिक रनटाइम का इस्तेमाल करने वाले सभी ऐप्लिकेशन शेयर करते हैं.

9.5. एक डिवाइस पर कई लोगों के काम करने की सुविधा

Android में कई उपयोगकर्ताओं के लिए सहायता शामिल है. साथ ही, यह उपयोगकर्ताओं को पूरी तरह से अलग रखने की सुविधा देता है.

अगर डिवाइस, प्राइमरी बाहरी स्टोरेज के लिए हटाए जा सकने वाले मीडिया का इस्तेमाल करते हैं, तो वे एक से ज़्यादा उपयोगकर्ताओं की सुविधा चालू कर सकते हैं. हालांकि, उन्हें ऐसा नहीं करना चाहिए.

अगर डिवाइसों पर एक से ज़्यादा उपयोगकर्ता हैं, तो:

[C-1-1] एक से ज़्यादा उपयोगकर्ताओं के लिए सहायता उपलब्ध कराने से जुड़ी इन ज़रूरी शर्तों को पूरा करना ज़रूरी है.
[C-1-2] हर उपयोगकर्ता के लिए, एपीआई में Android प्लैटफ़ॉर्म के सुरक्षा मॉडल के मुताबिक सुरक्षा मॉडल लागू करना ज़रूरी है. इसके बारे में सुरक्षा और अनुमतियों के रेफ़रंस दस्तावेज़ में बताया गया है.
[C-1-3] हर उपयोगकर्ता इंस्टेंस के लिए, अलग और आइसोलेटेड शेयर किया गया ऐप्लिकेशन स्टोरेज (इसे /sdcard भी कहा जाता है) डायरेक्ट्री होनी चाहिए.
[C-1-4] यह पक्का करना ज़रूरी है कि किसी उपयोगकर्ता के मालिकाना हक वाले और उसकी ओर से चलाए जा रहे ऐप्लिकेशन, किसी दूसरे उपयोगकर्ता के मालिकाना हक वाली फ़ाइलों को न तो सूची में शामिल कर सकें, न ही उन्हें पढ़ सकें, और न ही उनमें बदलाव कर सकें. भले ही, दोनों उपयोगकर्ताओं का डेटा एक ही वॉल्यूम या फ़ाइल सिस्टम पर सेव किया गया हो.
[C-1-5] अगर डिवाइस में बाहरी स्टोरेज के एपीआई के लिए, हटाने लायक मीडिया का इस्तेमाल किया जाता है, तो मल्टीयूज़र मोड चालू होने पर एसडी कार्ड के कॉन्टेंट को एन्क्रिप्ट (सुरक्षित) करना ज़रूरी है. इसके लिए, सिर्फ़ ऐसे मीडिया पर सेव की गई कुंजी का इस्तेमाल किया जाना चाहिए जिसे हटाया नहीं जा सकता. साथ ही, उस कुंजी को सिर्फ़ सिस्टम ऐक्सेस कर सकता हो. इससे होस्ट पीसी पर मीडिया को पढ़ा नहीं जा सकेगा. इसलिए, डिवाइसों को एमटीपी या इसी तरह के किसी सिस्टम पर स्विच करना होगा, ताकि होस्ट पीसी को मौजूदा उपयोगकर्ता के डेटा का ऐक्सेस मिल सके.

9.6. प्रीमियम एसएमएस की चेतावनी

Android में, लोगों को किसी भी आउटगोइंग प्रीमियम एसएमएस मैसेज के बारे में चेतावनी देने की सुविधा शामिल है. प्रीमियम मैसेज (एसएमएस), मोबाइल और इंटरनेट सेवा देने वाली कंपनी के साथ रजिस्टर की गई किसी सेवा को भेजे जाने वाले टेक्स्ट मैसेज होते हैं. इसके लिए, उपयोगकर्ता से शुल्क लिया जा सकता है.

अगर डिवाइस में सेट किए गए सिस्टम में android.hardware.telephony का इस्तेमाल किया जाता है, तो:

[C-1-1] डिवाइस में मौजूद /data/misc/sms/codes.xml फ़ाइल में तय किए गए रेगुलर एक्सप्रेशन से पहचाने गए नंबरों पर एसएमएस भेजने से पहले, उपयोगकर्ताओं को चेतावनी देनी होगी. अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट, इस ज़रूरी शर्त को पूरा करने वाला एक तरीका उपलब्ध कराता है.

9.7. सुरक्षा से जुड़ी सुविधाएं

डिवाइसों में, कर्नेल और प्लैटफ़ॉर्म, दोनों में सुरक्षा से जुड़ी सुविधाओं का पालन करना ज़रूरी है. इसके बारे में यहां बताया गया है.

Android सैंडबॉक्स में ऐसी सुविधाएं शामिल होती हैं जो Security-Enhanced Linux (SELinux) के ज़रूरी ऐक्सेस कंट्रोल (एमएसी) सिस्टम, seccomp सैंडबॉक्सिंग, और Linux कर्नल में मौजूद अन्य सुरक्षा सुविधाओं का इस्तेमाल करती हैं. डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-1] मौजूदा ऐप्लिकेशन के साथ काम करने की सुविधा को बनाए रखना ज़रूरी है. भले ही, Android फ़्रेमवर्क के नीचे SELinux या कोई अन्य सुरक्षा सुविधा लागू की गई हो.
[C-0-2] सुरक्षा से जुड़े उल्लंघन का पता चलने पर, यूज़र इंटरफ़ेस (यूआई) नहीं दिखना चाहिए. साथ ही, Android फ़्रेमवर्क के नीचे लागू की गई सुरक्षा सुविधा से, उल्लंघन को ब्लॉक किया जाना चाहिए. हालांकि, सुरक्षा से जुड़े उल्लंघन को ब्लॉक न किए जाने पर, यूज़र इंटरफ़ेस (यूआई) दिख सकता है. इससे, उल्लंघन का फ़ायदा उठाया जा सकता है.
[C-0-3] Android फ़्रेमवर्क के नीचे लागू की गई SELinux या किसी अन्य सुरक्षा सुविधा को, उपयोगकर्ता या ऐप्लिकेशन डेवलपर के लिए कॉन्फ़िगर करने की अनुमति नहीं होनी चाहिए.
[C-0-4] किसी ऐसे ऐप्लिकेशन को अनुमति नहीं देनी चाहिए जो एपीआई (जैसे कि डिवाइस एडमिनिस्ट्रेशन एपीआई) के ज़रिए किसी दूसरे ऐप्लिकेशन पर असर डाल सकता है. साथ ही, उसे ऐसी नीति कॉन्फ़िगर करने की अनुमति नहीं देनी चाहिए जो कंपैटिबिलिटी से जुड़ी समस्या पैदा करती हो.
[C-0-5] मीडिया फ़्रेमवर्क को कई प्रोसेस में बांटना ज़रूरी है, ताकि Android Open Source Project की साइट पर बताए गए तरीके से, हर प्रोसेस के लिए ऐक्सेस दिया जा सके.
[C-0-6] कर्नेल ऐप्लिकेशन सैंडबॉक्सिंग की सुविधा लागू करना ज़रूरी है. इससे मल्टीथ्रेड प्रोग्राम से, कॉन्फ़िगर की जा सकने वाली नीति का इस्तेमाल करके सिस्टम कॉल को फ़िल्टर किया जा सकता है. अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट, इस ज़रूरी शर्त को पूरा करता है. इसके लिए, वह थ्रेडग्रुप सिंक्रनाइज़ेशन (टीएसवाईएनसी) के साथ seccomp-BPF को चालू करता है. इसके बारे में source.android.com के कर्नल कॉन्फ़िगरेशन सेक्शन में बताया गया है.

कर्नल की सुरक्षा और खुद की सुरक्षा करने की सुविधाएं, Android की सुरक्षा के लिए ज़रूरी हैं. डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-7] कर्नेल स्टैक बफ़र ओवरफ़्लो से सुरक्षा देने वाले तरीके लागू करना ज़रूरी है. ऐसे तरीकों के उदाहरण CC_STACKPROTECTOR_REGULAR और CONFIG_CC_STACKPROTECTOR_STRONG हैं.
[C-0-8] कर्नल मेमोरी के लिए, सुरक्षा से जुड़ी सख्त नीतियां लागू करनी होंगी.जैसे, एक्ज़ीक्यूटेबल कोड सिर्फ़ पढ़ा जा सकता है, सिर्फ़ पढ़े जा सकने वाले डेटा को न तो एक्ज़ीक्यूट किया जा सकता है और न ही लिखा जा सकता है. साथ ही, लिखे जा सकने वाले डेटा को एक्ज़ीक्यूट नहीं किया जा सकता (जैसे, CONFIG_DEBUG_RODATA या CONFIG_STRICT_KERNEL_RWX).
[C-0-9] API लेवल 28 या इसके बाद के वर्शन के साथ शिप किए गए डिवाइसों पर, उपयोगकर्ता-स्पेस और कर्नल-स्पेस (जैसे, CONFIG_HARDENED_USERCOPY) के बीच कॉपी किए गए ऑब्जेक्ट के साइज़ की स्टैटिक और डाइनैमिक बाउंड्री की जांच लागू करना ज़रूरी है.
[C-0-10] कर्नेल मोड में एक्ज़ीक्यूट करते समय, उपयोगकर्ता-स्पेस मेमोरी को एक्ज़ीक्यूट नहीं करना चाहिए. जैसे, एपीआई लेवल 28 या इससे ज़्यादा के साथ शिप किए गए डिवाइसों पर, हार्डवेयर पीएक्सएन या CONFIG_CPU_SW_DOMAIN_PAN या CONFIG_ARM64_SW_TTBR0_PAN के ज़रिए इम्यूलेट किया गया.
[C-0-11] एपीआई लेवल 28 या इसके बाद के वर्शन वाले डिवाइसों पर, कर्नल को सामान्य usercopy ऐक्सेस एपीआई (जैसे, हार्डवेयर पैन या CONFIG_CPU_SW_DOMAIN_PAN या CONFIG_ARM64_SW_TTBR0_PAN के ज़रिए इम्यूलेट किया गया) के बाहर, उपयोगकर्ता-स्पेस मेमोरी को न तो पढ़ना चाहिए और न ही उसमें लिखना चाहिए.
[C-0-12] अगर हार्डवेयर, CVE-2017-5754 से जुड़ी समस्या से प्रभावित है, तो कर्नेल पेज टेबल आइसोलेशन को लागू करना ज़रूरी है. यह समस्या, एपीआई लेवल 28 या इसके बाद के वर्शन (जैसे, CONFIG_PAGE_TABLE_ISOLATION या CONFIG_UNMAP_KERNEL_AT_EL0) के साथ शिप किए गए सभी डिवाइसों में हो सकती है.
[C-0-13] अगर हार्डवेयर, एपीआई लेवल 28 या इसके बाद के वर्शन के साथ शिप किए गए सभी डिवाइसों पर CVE-2017-5715 से प्रभावित हो सकता है, तो ब्रांच प्रेडिक्शन हार्डनिंग को लागू करना ज़रूरी है. जैसे, CONFIG_HARDEN_BRANCH_PREDICTOR.
[SR] यह सुझाव दिया जाता है कि कर्नेल डेटा को सिर्फ़ शुरू करने के दौरान लिखा जाए.साथ ही, शुरू करने के बाद उसे सिर्फ़ पढ़ने के लिए मार्क किया जाए. उदाहरण के लिए, __ro_after_init.
[C-SR] कर्नेल कोड और मेमोरी के लेआउट को रैंडमाइज़ करने का सुझाव दिया जाता है.साथ ही, ऐसे एक्सपोज़र से बचने का सुझाव दिया जाता है जिनसे रैंडमाइज़ेशन से समझौता हो सकता है. उदाहरण के लिए, /chosen/kaslr-seed Device Tree node या EFI_RNG_PROTOCOL के ज़रिए बूटलोडर एंट्रॉपी के साथ CONFIG_RANDOMIZE_BASE.
[C-SR] यह सुझाव दिया जाता है कि कर्नल में कंट्रोल फ़्लो इंटिग्रिटी (सीएफ़आई) की सुविधा चालू करें. इससे कोड के दोबारा इस्तेमाल से होने वाले हमलों (जैसे, CONFIG_CFI_CLANG और CONFIG_SHADOW_CALL_STACK) से अतिरिक्त सुरक्षा मिलती है.
[C-SR] जिन कॉम्पोनेंट पर कंट्रोल-फ़्लो इंटिग्रिटी (सीएफ़आई), शैडो कॉल स्टैक (एससीएस) या पूर्णांक ओवरफ़्लो सैनिटाइज़ेशन (इंटसैन) चालू है उन पर इन्हें बंद न करने का सुझाव दिया जाता है.
[C-SR] सुरक्षा के लिहाज़ से संवेदनशील किसी भी अतिरिक्त यूज़रस्पेस कॉम्पोनेंट के लिए, सीएफ़आई, एससीए, और IntSan को चालू करने का सुझाव दिया जाता है. इनके बारे में सीएफ़आई और IntSan में बताया गया है.
[C-SR] कर्नेल में स्टैक इनिशियलाइज़ेशन को चालू करने का सुझाव दिया जाता है, ताकि बिना इनिशियलाइज़ किए गए लोकल वैरिएबल (CONFIG_INIT_STACK_ALL या CONFIG_INIT_STACK_ALL_ZERO) का इस्तेमाल न किया जा सके. साथ ही, डिवाइसों को लागू करने वाले लोगों को यह नहीं मानना चाहिए कि कंपाइलर, लोकल वैरिएबल को इनिशियलाइज़ करने के लिए जिस वैल्यू का इस्तेमाल करता है वह सही है.
[C-SR] कर्नेल में हीप इनिशियलाइज़ेशन को चालू करने का सुझाव दिया जाता है, ताकि बिना इनिशियलाइज़ किए गए हीप एलोकेशन (CONFIG_INIT_ON_ALLOC_DEFAULT_ON) का इस्तेमाल न किया जा सके. साथ ही, उन्हें यह नहीं मानना चाहिए कि कर्नेल ने उन एलोकेशन को इनिशियलाइज़ करने के लिए जिस वैल्यू का इस्तेमाल किया है.

अगर डिवाइस में Linux कर्नल का इस्तेमाल किया जाता है, तो:

[C-1-1] SELinux को लागू करना ज़रूरी है.
[C-1-2] SELinux को ग्लोबल एनफ़ोर्सिंग मोड पर सेट करना ज़रूरी है.
[C-1-3] सभी डोमेन को एनफ़ोर्सिंग मोड में कॉन्फ़िगर करना ज़रूरी है. अनुमति वाले मोड के किसी भी डोमेन को अनुमति नहीं है. इनमें किसी डिवाइस/वेंडर से जुड़े डोमेन भी शामिल हैं.
[C-1-4] यह ज़रूरी है कि सिस्टम/sepolicy फ़ोल्डर में मौजूद neverallow नियमों में बदलाव न किया गया हो, उन्हें हटाया न गया हो या बदला न गया हो. यह फ़ोल्डर, अपस्ट्रीम Android Open Source Project (AOSP) में दिया गया है. साथ ही, यह भी ज़रूरी है कि नीति में मौजूद सभी neverallow नियम, AOSP SELinux डोमेन और डिवाइस/वेंडर के हिसाब से बने डोमेन, दोनों के लिए कंपाइल हों.
[C-1-5] तीसरे पक्ष के ऐप्लिकेशन को, एपीआई लेवल 28 या इसके बाद के वर्शन के हिसाब से डिज़ाइन किया गया हो. साथ ही, उन्हें हर ऐप्लिकेशन के हिसाब से SELinux सैंडबॉक्स में चलाना होगा. इसके अलावा, हर ऐप्लिकेशन के निजी डेटा डायरेक्ट्री पर, हर ऐप्लिकेशन के हिसाब से SELinux की पाबंदियां लागू होनी चाहिए.
उन्हें Android Open Source Project के अपस्ट्रीम के system/sepolicy फ़ोल्डर में दी गई डिफ़ॉल्ट SELinux नीति को बनाए रखना चाहिए. साथ ही, अपने डिवाइस के हिसाब से कॉन्फ़िगरेशन के लिए, सिर्फ़ इस नीति में बदलाव करना चाहिए.

अगर डिवाइसों को Android के पुराने वर्शन पर पहले ही लॉन्च कर दिया गया है और सिस्टम सॉफ़्टवेयर अपडेट के ज़रिए, वे [C-1-1] और [C-1-5] ज़रूरी शर्तों को पूरा नहीं कर सकते, तो उन्हें इन ज़रूरी शर्तों से छूट मिल सकती है.

अगर डिवाइस में Linux के अलावा किसी दूसरे कर्नल का इस्तेमाल किया जाता है, तो:

[C-2-1] ज़रूरी है कि SELinux के बराबर का मैंडेटरी ऐक्सेस कंट्रोल सिस्टम इस्तेमाल किया जाए.

Android में कई लेयर की सुरक्षा से जुड़ी सुविधाएं मौजूद हैं. ये सुविधाएं, डिवाइस की सुरक्षा के लिए ज़रूरी हैं.

9.8. निजता

9.8.1. इस्तेमाल का इतिहास

Android, उपयोगकर्ता की पसंद का इतिहास सेव करता है. साथ ही, UsageStatsManager की मदद से इस इतिहास को मैनेज करता है.

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-1] को उपयोगकर्ता के इस इतिहास को सेव करने की अवधि तय करनी होगी.
[SR] यह सुझाव दिया जाता है कि डेटा को 14 दिनों तक सेव करके रखने की अवधि को, AOSP में डिफ़ॉल्ट रूप से कॉन्फ़िगर किए गए समय के हिसाब से ही सेट किया जाए.

Android, सिस्टम इवेंट को StatsLog आइडेंटिफ़ायर का इस्तेमाल करके सेव करता है. साथ ही, StatsManager और IncidentManager System API की मदद से, इस इतिहास को मैनेज करता है.

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-2] सिस्टम एपीआई क्लास IncidentManager से बनाई गई घटना की रिपोर्ट में, सिर्फ़ DEST_AUTOMATIC के तौर पर मार्क किए गए फ़ील्ड शामिल होने चाहिए.
[C-0-3] StatsLog SDK टूल के दस्तावेज़ों में बताए गए इवेंट के अलावा, किसी अन्य इवेंट को लॉग करने के लिए सिस्टम इवेंट आइडेंटिफ़ायर का इस्तेमाल नहीं किया जाना चाहिए. अगर अतिरिक्त सिस्टम इवेंट लॉग किए जाते हैं, तो वे 1,00,000 से 2,00,000 के बीच की रेंज में मौजूद किसी दूसरे ऐटम आइडेंटिफ़ायर का इस्तेमाल कर सकते हैं.

9.8.2. रिकॉर्डिंग

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-1] डिवाइस में ऐसे सॉफ़्टवेयर कॉम्पोनेंट पहले से लोड नहीं होने चाहिए या उन्हें बॉक्स से बाहर नहीं भेजना चाहिए जो उपयोगकर्ता की निजी जानकारी (जैसे कि कीस्ट्रोक, स्क्रीन पर दिखने वाला टेक्स्ट, गड़बड़ी की रिपोर्ट) को बिना उसकी सहमति या सूचना के डिवाइस से बाहर भेजते हैं.
[C-0-2] उपयोगकर्ता की साफ़ तौर पर सहमति लेनी होगी. साथ ही, उसे यह जानकारी देनी होगी कि जब भी MediaProjection या मालिकाना हक वाले एपीआई के ज़रिए स्क्रीन कास्टिंग या स्क्रीन रिकॉर्डिंग की सुविधा चालू की जाएगी, तब उपयोगकर्ता की स्क्रीन पर दिखने वाली किसी भी संवेदनशील जानकारी को कैप्चर किया जा सकता है. उपयोगकर्ताओं को यह विकल्प नहीं दिया जाना चाहिए कि वे आने वाले समय में, उपयोगकर्ता की सहमति से जुड़ा मैसेज न दिखाएं.
[C-0-3] स्क्रीन कास्टिंग या स्क्रीन रिकॉर्डिंग चालू होने पर, उपयोगकर्ता को लगातार सूचना दिखनी चाहिए. AOSP इस ज़रूरी शर्त को पूरा करता है. इसके लिए, वह स्टेटस बार में जारी गतिविधि की सूचना का आइकॉन दिखाता है.

अगर डिवाइसों में ऐसी सुविधाएं शामिल हैं जो सिस्टम में मौजूद कॉन्टेंट को कैप्चर करती हैं और/या सिस्टम एपीआई ContentCaptureService के अलावा, डिवाइस पर चलाए जा रहे ऑडियो स्ट्रीम को रिकॉर्ड करती हैं या सेक्शन 9.8.6 कॉन्टेंट कैप्चर करना में बताए गए अन्य मालिकाना हक वाले तरीके इस्तेमाल करती हैं, तो:

[C-1-1] जब यह सुविधा चालू हो और डेटा कैप्चर/रिकॉर्ड किया जा रहा हो, तब उपयोगकर्ता को लगातार सूचना मिलनी चाहिए.

अगर डिवाइसों में ऐसा कॉम्पोनेंट शामिल है जो बॉक्स से बाहर निकलने पर चालू हो जाता है और आस-पास की आवाज़ रिकॉर्ड कर सकता है और/या डिवाइस पर चल रहे ऑडियो को रिकॉर्ड कर सकता है, ताकि उपयोगकर्ता के कॉन्टेक्स्ट के बारे में काम की जानकारी मिल सके, तो:

[C-2-1] रिकॉर्ड किए गए रॉ ऑडियो या किसी ऐसे फ़ॉर्मैट को डिवाइस के परसिस्टेंट स्टोरेज में सेव नहीं किया जाना चाहिए या डिवाइस से बाहर नहीं भेजा जाना चाहिए जिसे वापस ओरिजनल ऑडियो या उसके जैसा ऑडियो में बदला जा सकता हो. ऐसा सिर्फ़ उपयोगकर्ता की साफ़ तौर पर दी गई सहमति के साथ किया जा सकता है.

9.8.3. कनेक्टिविटी

[C-1-1] यूएसबी पोर्ट के ज़रिए शेयर किए गए स्टोरेज के कॉन्टेंट को ऐक्सेस करने की अनुमति देने से पहले, उपयोगकर्ता की सहमति मांगने वाला यूज़र इंटरफ़ेस (यूआई) दिखाना ज़रूरी है.

9.8.4. नेटवर्क ट्रैफ़िक

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-1] सिस्टम के भरोसेमंद सर्टिफ़िकेट देने वाली संस्था (सीए) के स्टोर के लिए, उसी रूट सर्टिफ़िकेट को पहले से इंस्टॉल करना होगा जो अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट में दिया गया है.
[C-0-2] डिवाइस को, उपयोगकर्ता के रूट सीए स्टोर में कोई भी सर्टिफ़िकेट मौजूद न होने की स्थिति में शिप किया जाना चाहिए.
[C-0-3] जब कोई उपयोगकर्ता रूट सीए जोड़ता है, तो उसे एक चेतावनी दिखानी चाहिए. इसमें यह बताया जाना चाहिए कि नेटवर्क ट्रैफ़िक की निगरानी की जा सकती है.

अगर डिवाइस का ट्रैफ़िक वीपीएन से होकर जाता है, तो डिवाइस पर लागू होने वाली ये सेटिंग काम नहीं करेंगी:

[C-1-1] उपयोगकर्ता को चेतावनी दिखनी चाहिए, जिसमें इनमें से कोई एक बात बताई गई हो:
- उस नेटवर्क ट्रैफ़िक की निगरानी की जा सकती है.
- वह नेटवर्क ट्रैफ़िक, वीपीएन की सुविधा देने वाले किसी खास वीपीएन ऐप्लिकेशन से होकर गुज़र रहा है.

अगर डिवाइसों में ऐसा सिस्टम मौजूद है जो प्रॉक्सी सर्वर या वीपीएन गेटवे के ज़रिए नेटवर्क डेटा ट्रैफ़िक को रूट करता है और यह सिस्टम डिफ़ॉल्ट रूप से चालू होता है, तो:android.permission.CONTROL_VPN

[C-2-1] उस वीपीएन को चालू करने से पहले, उपयोगकर्ता की सहमति लेना ज़रूरी है. हालांकि, अगर डिवाइस नीति कंट्रोलर ने DevicePolicyManager.setAlwaysOnVpnPackage() के ज़रिए वीपीएन चालू किया है, तो उपयोगकर्ता की सहमति लेना ज़रूरी नहीं है. ऐसे में, उपयोगकर्ता को सिर्फ़ सूचना देनी होगी.

अगर डिवाइस पर, तीसरे पक्ष के वीपीएन ऐप्लिकेशन के "हमेशा-चालू वीपीएन" फ़ंक्शन को टॉगल करने के लिए, उपयोगकर्ता को सुविधा मिलती है, तो:

[C-3-1] जिन ऐप्लिकेशन में हमेशा चालू रहने वाली वीपीएन सेवा काम नहीं करती उनके लिए, उपयोगकर्ता को यह सुविधा बंद करनी होगी. इसके लिए, AndroidManifest.xml फ़ाइल में SERVICE_META_DATA_SUPPORTS_ALWAYS_ON एट्रिब्यूट को false पर सेट करना होगा.

9.8.5. डिवाइस पहचानकर्ता

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-1] किसी ऐप्लिकेशन को डिवाइस के सीरियल नंबर का ऐक्सेस नहीं मिलना चाहिए. साथ ही, अगर लागू हो, तो IMEI/MEID, सिम का सीरियल नंबर, और इंटरनैशनल मोबाइल सब्सक्राइबर आइडेंटिटी (आईएमएसआई) का ऐक्सेस भी नहीं मिलना चाहिए. हालांकि, अगर ऐप्लिकेशन इनमें से कोई एक ज़रूरी शर्त पूरी करता है, तो उसे ऐक्सेस दिया जा सकता है:
- यह मोबाइल और इंटरनेट सेवा देने वाली कंपनी का ऐसा ऐप्लिकेशन है जिस पर हस्ताक्षर किया गया है. इसकी पुष्टि डिवाइस बनाने वाली कंपनियां करती हैं.
- को READ_PRIVILEGED_PHONE_STATE की अनुमति दी गई हो.
- उसके पास यूआईसीसी कैरियर के खास अधिकार में बताए गए कैरियर के खास अधिकार हों.
- डिवाइस का मालिक या प्रोफ़ाइल का मालिक हो और उसे READ_PHONE_STATE अनुमति मिली हो.
- (सिर्फ़ सिम सीरियल नंबर/आईसीसीआईडी के लिए) स्थानीय नियमों के मुताबिक, ऐप्लिकेशन को यह पता लगाना होगा कि सदस्य की पहचान में क्या बदलाव हुए हैं.

9.8.6. सामग्री कैप्चर

Android, सिस्टम एपीआई ContentCaptureService या मालिकाना हक वाले अन्य तरीकों से, डिवाइसों पर लागू होने वाले ऐसे तरीके का इस्तेमाल करता है जिससे ऐप्लिकेशन और उपयोगकर्ता के बीच होने वाले इन इंटरैक्शन को कैप्चर किया जा सके.

स्क्रीन पर रेंडर किया गया टेक्स्ट और ग्राफ़िक. इसमें AssistStructure एपीआई के ज़रिए मिली सूचनाएं और सहायता से जुड़ा डेटा शामिल है. हालांकि, इसमें और भी चीज़ें शामिल हो सकती हैं.
डिवाइस से रिकॉर्ड किया गया या चलाया गया मीडिया डेटा, जैसे कि ऑडियो या वीडियो.
इनपुट इवेंट (जैसे कि कीबोर्ड, माउस, जेस्चर, आवाज़, वीडियो, और ऐक्सेसिबिलिटी).
ऐसे अन्य इवेंट जो कोई ऐप्लिकेशन, Content Capture एपीआई या इसी तरह के मालिकाना हक वाले एपीआई के ज़रिए सिस्टम को उपलब्ध कराता है.
TextClassifier API के ज़रिए System TextClassifier को भेजा गया कोई भी टेक्स्ट या अन्य डेटा. इसका मतलब है कि सिस्टम सेवा को टेक्स्ट का मतलब समझने के लिए भेजा गया डेटा. साथ ही, टेक्स्ट के आधार पर अनुमानित अगली कार्रवाइयां जनरेट करने के लिए भेजा गया डेटा.

अगर डिवाइस के लिए लागू किए गए फ़ंक्शन, ऊपर दिया गया डेटा इकट्ठा करते हैं, तो:

[C-1-1] डिवाइस में सेव किए जाने पर, इस तरह के सभी डेटा को एन्क्रिप्ट (सुरक्षित) करना ज़रूरी है. इस एन्क्रिप्शन को Android के फ़ाइल आधारित एन्क्रिप्शन या Cipher SDK में बताए गए, एपीआई वर्शन 26 या उसके बाद के वर्शन के तौर पर लिस्ट किए गए किसी भी सिफ़र का इस्तेमाल करके किया जा सकता है.
[C-1-2] Android के बैकअप लेने के तरीकों या बैकअप लेने के किसी अन्य तरीके का इस्तेमाल करके, न तो रॉ डेटा और न ही एन्क्रिप्ट (सुरक्षित) किए गए डेटा का बैक अप लिया जाना चाहिए.
[C-1-3] को निजता बनाए रखने वाले तरीके का इस्तेमाल करके, इस तरह का सारा डेटा और डिवाइस का लॉग भेजना होगा. निजता बनाए रखने वाले मेकेनिज़्म को इस तरह से परिभाषित किया गया है: “ये ऐसे मेकेनिज़्म हैं जो सिर्फ़ एग्रीगेट किए गए डेटा का विश्लेषण करने की अनुमति देते हैं. साथ ही, लॉग किए गए इवेंट या निकाले गए नतीजों को अलग-अलग उपयोगकर्ताओं से मैच होने से रोकते हैं.” ऐसा इसलिए किया जाता है, ताकि किसी उपयोगकर्ता के डेटा की जांच न की जा सके. उदाहरण के लिए, RAPPOR जैसी डिफ़रेंशियल प्राइवसी टेक्नोलॉजी का इस्तेमाल करके इसे लागू किया जाता है.
[C-1-4] इस तरह के डेटा को डिवाइस पर मौजूद किसी भी उपयोगकर्ता की पहचान (जैसे कि Account) से नहीं जोड़ा जाना चाहिए. हालांकि, डेटा को हर बार उपयोगकर्ता की साफ़ तौर पर सहमति मिलने के बाद जोड़ा जा सकता है.
[C-1-5] ऐसे डेटा को अन्य ऐप्लिकेशन के साथ शेयर नहीं किया जाना चाहिए. हालांकि, उपयोगकर्ता की सहमति मिलने पर, हर बार शेयर किया जा सकता है.
[C-1-6] अगर डिवाइस पर किसी भी फ़ॉर्म में डेटा सेव किया जाता है, तो ContentCaptureService या मालिकाना हक वाली कंपनी को उपयोगकर्ता को ऐसा डेटा मिटाने की सुविधा देनी होगी.

अगर डिवाइस में ऐसी सेवा शामिल है जो सिस्टम एपीआई ContentCaptureService को लागू करती है या कोई ऐसी मालिकाना सेवा है जो ऊपर बताए गए तरीके से डेटा इकट्ठा करती है, तो:

[C-2-1] उपयोगकर्ताओं को, कॉन्टेंट कैप्चर करने वाली सेवा को उपयोगकर्ता के इंस्टॉल किए जा सकने वाले ऐप्लिकेशन या सेवा से बदलने की अनुमति नहीं देनी चाहिए. साथ ही, सिर्फ़ पहले से इंस्टॉल की गई सेवा को ऐसा डेटा कैप्चर करने की अनुमति देनी चाहिए.
[C-2-2] पहले से इंस्टॉल की गई कॉन्टेंट कैप्चर करने की सेवा के अलावा, किसी भी अन्य ऐप्लिकेशन को इस तरह का डेटा कैप्चर करने की अनुमति नहीं दी जानी चाहिए.
[C-2-3] उपयोगकर्ता को कॉन्टेंट कैप्चर करने की सेवा बंद करने का विकल्प देना ज़रूरी है.
[C-2-4] कॉन्टेंट कैप्चर करने वाली सेवा के पास मौजूद Android की अनुमतियों को मैनेज करने के लिए, उपयोगकर्ता को विकल्प देना ज़रूरी है. साथ ही, सेक्शन 9.1 में बताए गए Android की अनुमतियों वाले मॉडल का पालन करना ज़रूरी है. अनुमति.
[C-SR] कॉन्टेंट कैप्चर करने वाली सेवा के कॉम्पोनेंट को अलग रखने का सुझाव दिया जाता है. उदाहरण के लिए, सेवा को बाइंड न करना या प्रोसेस आईडी शेयर न करना. हालांकि, यहां दिए गए सिस्टम कॉम्पोनेंट के साथ ऐसा नहीं करना चाहिए:
- टेलीफ़ोनी, संपर्क, सिस्टम यूज़र इंटरफ़ेस (यूआई), और मीडिया

9.8.7. क्लिपबोर्ड का ऐक्सेस

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-1] क्लिपबोर्ड पर मौजूद डेटा को काटा नहीं जाना चाहिए (जैसे, ClipboardManager एपीआई के ज़रिए). ऐसा तब तक नहीं किया जाना चाहिए, जब तक कि ऐप्लिकेशन डिफ़ॉल्ट IME न हो या वह ऐप्लिकेशन न हो जिस पर फ़िलहाल फ़ोकस किया जा रहा है.

9.8.8. जगह की जानकारी

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-1] उपयोगकर्ता की साफ़ तौर पर दी गई सहमति या उपयोगकर्ता की कार्रवाई के बिना, डिवाइस की जगह की जानकारी की सेटिंग और वाई-फ़ाई/ब्लूटूथ स्कैनिंग की सेटिंग को चालू/बंद नहीं करना चाहिए.
[C-0-2] ऐप्लिकेशन को उपयोगकर्ता को जगह की जानकारी से जुड़ी जानकारी ऐक्सेस करने की सुविधा देनी होगी. इसमें जगह की जानकारी के लिए हाल ही में किए गए अनुरोध, ऐप्लिकेशन लेवल की अनुमतियां, और जगह की जानकारी का पता लगाने के लिए वाई-फ़ाई/ब्लूटूथ स्कैनिंग का इस्तेमाल शामिल है.
[C-0-3] यह पक्का करना ज़रूरी है कि Emergency Location Bypass API [LocationRequest.setLocationSettingsIgnored()] का इस्तेमाल करने वाला ऐप्लिकेशन, उपयोगकर्ता की ओर से शुरू किया गया आपातकालीन सेशन हो. जैसे, 911 पर कॉल करना या 911 पर मैसेज भेजना. हालांकि, कार के मामले में, अगर क्रैश/दुर्घटना का पता चलता है, तो वाहन, उपयोगकर्ता की गतिविधि के बिना ही आपातकालीन सेशन शुरू कर सकता है. उदाहरण के लिए, eCall की ज़रूरी शर्तों को पूरा करने के लिए.
[C-0-4] इमरजेंसी लोकेशन बाईपास एपीआई को, डिवाइस की जगह की जानकारी की सेटिंग में बदलाव किए बिना, उन्हें बाईपास करने की सुविधा देनी होगी.
[C-0-5] बैकग्राउंड में ऐप्लिकेशन के [ACCESS_BACKGROUND_LOCATION] अनुमति का इस्तेमाल करके, उपयोगकर्ता की जगह की जानकारी ऐक्सेस करने के बाद, सूचना शेड्यूल करनी होगी. इससे उपयोगकर्ता को इस बारे में सूचना मिलेगी.

9.8.9. इंस्टॉल किए गए ऐप्लिकेशन

एपीआई लेवल 30 या उसके बाद के वर्शन को टारगेट करने वाले Android ऐप्लिकेशन, डिफ़ॉल्ट रूप से इंस्टॉल किए गए अन्य ऐप्लिकेशन की जानकारी नहीं देख सकते. Android SDK के दस्तावेज़ में पैकेज की जानकारी देखने की सुविधा देखें.

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-1] एपीआई लेवल 30 या उसके बाद के वर्शन को टारगेट करने वाले किसी भी ऐप्लिकेशन को, इंस्टॉल किए गए किसी अन्य ऐप्लिकेशन के बारे में जानकारी नहीं देनी चाहिए. हालांकि, अगर ऐप्लिकेशन, मैनेज किए गए एपीआई के ज़रिए इंस्टॉल किए गए अन्य ऐप्लिकेशन के बारे में जानकारी पहले से ही देख सकता है, तो ऐसा किया जा सकता है. इसमें डिवाइस बनाने वाली कंपनी के जोड़े गए किसी कस्टम एपीआई से मिली जानकारी या फ़ाइल सिस्टम के ज़रिए ऐक्सेस की जा सकने वाली जानकारी शामिल है. हालांकि, इसमें और भी जानकारी शामिल हो सकती है.

9.8.10. कनेक्टिविटी से जुड़ी गड़बड़ी की रिपोर्ट

अगर डिवाइसों पर, BugreportManager के साथ System API BUGREPORT_MODE_TELEPHONY का इस्तेमाल करके गड़बड़ी की रिपोर्ट जनरेट की जाती हैं, तो:

[C-1-1] सिस्टम एपीआई BUGREPORT_MODE_TELEPHONY को हर बार कॉल करने पर, उपयोगकर्ता की सहमति लेना ज़रूरी है, ताकि रिपोर्ट जनरेट की जा सके. साथ ही, उपयोगकर्ता को ऐप्लिकेशन से मिलने वाले सभी अनुरोधों के लिए सहमति देने का अनुरोध नहीं करना चाहिए.
[C-1-2] रिपोर्ट जनरेट होना शुरू होने पर, ऐप्लिकेशन को उपयोगकर्ता की सहमति लेनी होगी और उसे साफ़ तौर पर यह जानकारी देनी होगी. साथ ही, उपयोगकर्ता की सहमति के बिना, रिपोर्ट जनरेट करने का अनुरोध करने वाले ऐप्लिकेशन को रिपोर्ट नहीं भेजनी होगी.
[C-1-3] अनुरोध की गई रिपोर्ट जनरेट करनी होंगी. इनमें कम से कम यह जानकारी शामिल होनी चाहिए:
- TelephonyDebugService डंप
- TelephonyRegistry डंप
- WifiService डंप
- ConnectivityService डंप
- कॉलिंग पैकेज के CarrierService इंस्टेंस का डंप (अगर बाउंड है)
- रेडियो लॉग बफ़र
[C-1-4] जनरेट की गई रिपोर्ट में यह जानकारी शामिल नहीं होनी चाहिए:
- कनेक्टिविटी डीबग करने से जुड़ी जानकारी के अलावा कोई और जानकारी.
- उपयोगकर्ता के इंस्टॉल किए गए ऐप्लिकेशन के ट्रैफ़िक लॉग या उपयोगकर्ता के इंस्टॉल किए गए ऐप्लिकेशन/पैकेज की ज़्यादा जानकारी वाली प्रोफ़ाइलें (यूआईडी ठीक हैं, पैकेज के नाम नहीं).
इसमें ऐसी अतिरिक्त जानकारी शामिल हो सकती है जो किसी उपयोगकर्ता की पहचान से जुड़ी नहीं है. (जैसे, वेंडर के लॉग).

अगर डिवाइस के लागू करने से जुड़ी गड़बड़ी की रिपोर्ट में अतिरिक्त जानकारी (जैसे, वेंडर लॉग) शामिल है और उस जानकारी से निजता/सुरक्षा/बैटरी/स्टोरेज/मेमोरी पर असर पड़ता है, तो:

[C-SR] यह सुझाव दिया जाता है कि डेवलपर सेटिंग डिफ़ॉल्ट रूप से बंद हो. AOSP, डेवलपर सेटिंग में Enable verbose vendor logging विकल्प उपलब्ध कराकर इस शर्त को पूरा करता है. इससे गड़बड़ी की रिपोर्ट में, डिवाइस से जुड़े अतिरिक्त वेंडर लॉग शामिल किए जा सकते हैं.

9.8.11. डेटा ब्लोब शेयर करना

Android, BlobStoreManager के ज़रिए ऐप्लिकेशन को सिस्टम में डेटा ब्लोब भेजने की अनुमति देता है. इससे, चुने गए ऐप्लिकेशन के साथ डेटा ब्लोब शेयर किए जा सकते हैं.

अगर डिवाइस में सेट किए गए सिस्टम में, एसडीके के दस्तावेज़ में बताए गए तरीके से शेयर किए गए डेटा ब्लोब इस्तेमाल किए जा सकते हैं, तो:

[C-1-1] ऐप्लिकेशन को, उन ऐप्लिकेशन के डेटा ब्लोब शेयर नहीं करने चाहिए जिनके लिए अनुमति नहीं दी गई है.इसका मतलब है कि डिफ़ॉल्ट ऐक्सेस का दायरा और ऐक्सेस के अन्य मोड में बदलाव नहीं किया जाना चाहिए. इन मोड को BlobStoreManager.session#allowPackageAccess(), BlobStoreManager.session#allowSameSignatureAccess() या BlobStoreManager.session#allowPublicAccess() का इस्तेमाल करके तय किया जा सकता है. AOSP के रेफ़रंस इंप्लीमेंटेशन में इन ज़रूरी शर्तों को पूरा किया जाता है.
[C-1-2] डिवाइस से बाहर डेटा नहीं भेजना चाहिए. साथ ही, डेटा के सुरक्षित हैश को अन्य ऐप्लिकेशन के साथ शेयर नहीं करना चाहिए. इनका इस्तेमाल ऐक्सेस को कंट्रोल करने के लिए किया जाता है.

9.9. डेटा स्टोरेज एन्क्रिप्शन

सभी डिवाइसों को सेक्शन 9.9.1 में दी गई ज़रूरी शर्तों को पूरा करना होगा. जिन डिवाइसों को इस दस्तावेज़ में बताए गए एपीआई लेवल से पहले के एपीआई लेवल पर लॉन्च किया गया था उन्हें सेक्शन 9.9.2 और 9.9.3 में बताई गई ज़रूरी शर्तों से छूट मिली हुई है. हालांकि, उन्हें Android Compatibility Definition दस्तावेज़ के सेक्शन 9.9 में बताई गई ज़रूरी शर्तों को पूरा करना होगा. यह दस्तावेज़, उस एपीआई लेवल से जुड़ा होना चाहिए जिस पर डिवाइस लॉन्च किया गया था.

9.9.1. डायरेक्ट बूट

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-1] डायरेक्ट बूट मोड एपीआई को लागू करना ज़रूरी है. भले ही, वे स्टोरेज एन्क्रिप्शन के साथ काम न करते हों.
[C-0-2] ACTION_LOCKED_BOOT_COMPLETED और ACTION_USER_UNLOCKED इंटेंट को अब भी ब्रॉडकास्ट किया जाना चाहिए, ताकि डायरेक्ट बूट की सुविधा वाले ऐप्लिकेशन को यह पता चल सके कि उपयोगकर्ता के लिए, डिवाइस एन्क्रिप्ट (डीई) और क्रेडेंशियल एन्क्रिप्ट (सीई) किए गए स्टोरेज उपलब्ध हैं.

9.9.2. एन्क्रिप्ट करने से जुड़ी ज़रूरी शर्तें

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-1] अगर ऐप्लिकेशन, डिवाइस का स्थायी और हटाया न जा सकने वाला हिस्सा है, तो उसे ऐप्लिकेशन के निजी डेटा (/data पार्टिशन) के साथ-साथ ऐप्लिकेशन के शेयर किए गए स्टोरेज पार्टिशन (/sdcard पार्टिशन) को एन्क्रिप्ट करना होगा.
[C-0-2] जब उपयोगकर्ता डिवाइस को पहली बार सेटअप कर लेता है, तब डेटा स्टोरेज के लिए एन्क्रिप्शन की सुविधा डिफ़ॉल्ट रूप से चालू होनी चाहिए.
[C-0-3] डेटा स्टोरेज को एन्क्रिप्ट (सुरक्षित) करने से जुड़ी ऊपर दी गई ज़रूरी शर्त को पूरा करना होगा. इसके लिए, एन्क्रिप्ट (सुरक्षित) करने के इन दो तरीकों में से किसी एक को लागू करना होगा:
- सेक्शन 9.9.3.1 में बताए गए तरीके से, अलग-अलग फ़ाइलों को अलग-अलग तरीकों से एन्क्रिप्ट करना (एफ़बीई) और मेटाडेटा एन्क्रिप्शन.
- सेक्शन 9.9.3.2 में बताए गए तरीके के मुताबिक, हर उपयोगकर्ता के लिए ब्लॉक-लेवल एन्क्रिप्शन.

9.9.3. एन्क्रिप्ट (सुरक्षित) करने के तरीके

अगर डिवाइस के लागू किए गए तरीके एन्क्रिप्ट (सुरक्षित) किए गए हैं, तो:

[C-1-1] डिवाइस को बूट अप करने के लिए, उपयोगकर्ता से क्रेडेंशियल नहीं मांगे जाने चाहिए. साथ ही, ACTION_LOCKED_BOOT_COMPLETED मैसेज ब्रॉडकास्ट होने के बाद, डायरेक्ट बूट की सुविधा वाले ऐप्लिकेशन को डिवाइस के एन्क्रिप्ट (डीई) किए गए स्टोरेज को ऐक्सेस करने की अनुमति दी जानी चाहिए.
[C-1-2] डिवाइस को अनलॉक करने के लिए, उपयोगकर्ता को अपने क्रेडेंशियल (जैसे, पासकोड, पिन, पैटर्न या फ़िंगरप्रिंट) देने होंगे. इसके बाद, ACTION_USER_UNLOCKED मैसेज ब्रॉडकास्ट होने पर ही, क्रेडेंशियल एन्क्रिप्ट (सीई) किए गए स्टोरेज को ऐक्सेस करने की अनुमति मिलनी चाहिए.
[C-1-13] CE से सुरक्षित स्टोरेज को अनलॉक करने के लिए, कोई भी ऐसा तरीका नहीं दिया जाना चाहिए जिसमें उपयोगकर्ता के दिए गए क्रेडेंशियल, रजिस्टर की गई एस्क्रो कुंजी या रीबूट के बाद फिर से शुरू करने की सुविधा का इस्तेमाल न किया गया हो. साथ ही, यह सुविधा सेक्शन 9.9.4 में दी गई ज़रूरी शर्तों को पूरा करती हो.
[C-1-4] वेरिफ़ाइड बूट का इस्तेमाल करना ज़रूरी है.

9.9.3.1. मेटाडेटा एन्क्रिप्शन के साथ फ़ाइल आधारित एन्क्रिप्शन

अगर डिवाइसों में, मेटाडेटा एन्क्रिप्शन के साथ-साथ फ़ाइल आधारित एन्क्रिप्शन का इस्तेमाल किया जाता है, तो:

[C-1-5] फ़ाइल के कॉन्टेंट और फ़ाइल सिस्टम के मेटाडेटा को AES-256-XTS या Adiantum का इस्तेमाल करके एन्क्रिप्ट (सुरक्षित) करना ज़रूरी है. AES-256-XTS का मतलब है, 256-बिट साइफ़र कुंजी की लंबाई वाला ऐडवांस एन्क्रिप्शन स्टैंडर्ड, जो XTS मोड में काम करता है. कुंजी की पूरी लंबाई 512 बिट होती है. Adiantum का मतलब Adiantum-XChaCha12-AES से है. इसके बारे में https://github.com/google/adiantum पर बताया गया है. फ़ाइल सिस्टम का मेटाडेटा, फ़ाइल के साइज़, मालिकाना हक, मोड, और एक्सटेंडेड एट्रिब्यूट (xattrs) जैसे डेटा को कहते हैं.
[C-1-6] फ़ाइल के नामों को AES-256-CBC-CTS या Adiantum का इस्तेमाल करके एन्क्रिप्ट (सुरक्षित) करना ज़रूरी है.
[C-1-12] अगर डिवाइस में ऐडवांस एन्क्रिप्शन स्टैंडर्ड (एईएस) के निर्देश हैं (जैसे कि एआरएम पर आधारित डिवाइसों पर एआरएमवी8 क्रिप्टोग्राफ़ी एक्सटेंशन या x86 पर आधारित डिवाइसों पर एईएस-एनआई), तो फ़ाइल के नाम, फ़ाइल के कॉन्टेंट, और फ़ाइल सिस्टम के मेटाडेटा को एन्क्रिप्ट (सुरक्षित) करने के लिए, ऊपर दिए गए एईएस पर आधारित विकल्पों का इस्तेमाल किया जाना चाहिए, न कि Adiantum का.
[C-1-13] CE और DE कुंजियों से ज़रूरी सबकुंजियां (जैसे, हर फ़ाइल के लिए कुंजियां) पाने के लिए, क्रिप्टोग्राफ़िक तरीके से सुरक्षित और नॉन-रिवर्सिबल की डेरिवेटिव फ़ंक्शन (जैसे, HKDF-SHA512) का इस्तेमाल करना ज़रूरी है. "क्रिप्टोग्राफ़िक तौर पर मज़बूत और वापस नहीं बदली जा सकने वाली" का मतलब है कि कुंजी बनाने वाले फ़ंक्शन में कम से कम 256 बिट की सुरक्षा होती है. साथ ही, यह अपने इनपुट पर छद्म यादृच्छिक फ़ंक्शन फ़ैमिली के तौर पर काम करता है.
[C-1-14] अलग-अलग क्रिप्टोग्राफ़िक कामों के लिए, एक ही फ़ाइल आधारित एन्क्रिप्शन (एफ़बीई) कुंजियों या सबकुंजियों का इस्तेमाल नहीं करना चाहिए. उदाहरण के लिए, एन्क्रिप्शन और कुंजी जनरेट करने, दोनों के लिए या दो अलग-अलग एन्क्रिप्शन एल्गोरिदम के लिए.
ये कुंजियां, सीई और डीई स्टोरेज एरिया और फ़ाइल सिस्टम के मेटाडेटा की सुरक्षा करती हैं:
[C-1-7] इसे क्रिप्टोग्राफ़िक तरीके से, हार्डवेयर के समर्थन वाले कीस्टोर से बाइंड किया जाना चाहिए. यह कीस्टोर, वेरिफ़ाइड बूट और डिवाइस के हार्डवेयर रूट ऑफ़ ट्रस्ट से जुड़ा होना चाहिए.
[C-1-8] CE कुंजियों को उपयोगकर्ता के लॉक स्क्रीन क्रेडेंशियल से बाइंड किया जाना चाहिए.
[C-1-9] अगर उपयोगकर्ता ने लॉक स्क्रीन के क्रेडेंशियल नहीं दिए हैं, तो सीई कुंजियों को डिफ़ॉल्ट पासकोड से बाइंड किया जाना चाहिए.
[C-1-10] यूनीक और अलग होनी चाहिए. दूसरे शब्दों में, किसी भी उपयोगकर्ता की CE या DE कुंजी, किसी अन्य उपयोगकर्ता की CE या DE कुंजियों से मेल नहीं खानी चाहिए.
[C-1-11] ज़रूरी तौर पर इस्तेमाल किए जाने वाले सिफ़र, कुंजी की लंबाई, और मोड का इस्तेमाल करना ज़रूरी है.
डिवाइस बनाने वाली कंपनी को, पहले से इंस्टॉल किए गए ज़रूरी ऐप्लिकेशन (जैसे, अलार्म, फ़ोन, Messenger) को डायरेक्ट बूट के बारे में जानकारी देनी चाहिए.

अपस्ट्रीम Android Open Source प्रोजेक्ट, Linux कर्नल की "fscrypt" एन्क्रिप्शन सुविधा के आधार पर, फ़ाइल आधारित एन्क्रिप्शन को लागू करने का सबसे अच्छा तरीका उपलब्ध कराता है. साथ ही, Linux कर्नल की "dm-default-key" सुविधा के आधार पर, मेटाडेटा एन्क्रिप्शन को लागू करने का सबसे अच्छा तरीका उपलब्ध कराता है.

9.9.3.2. हर उपयोगकर्ता के लिए ब्लॉक-लेवल एन्क्रिप्शन

अगर डिवाइस पर, हर उपयोगकर्ता के लिए ब्लॉक-लेवल एन्क्रिप्शन का इस्तेमाल किया जाता है, तो:

[C-1-1] सेक्शन 9.5 में बताए गए तरीके से, मल्टी-यूज़र की सुविधा चालू करना ज़रूरी है.
[C-1-2] हर उपयोगकर्ता के लिए अलग-अलग पार्टीशन उपलब्ध कराने होंगे. इसके लिए, रॉ पार्टीशन या लॉजिकल वॉल्यूम का इस्तेमाल किया जा सकता है.
[C-1-3] इसे हर उपयोगकर्ता के लिए, यूनीक और अलग एन्क्रिप्शन कुंजियों का इस्तेमाल करना चाहिए, ताकि ब्लॉक डिवाइसों को एन्क्रिप्ट किया जा सके.
[C-1-4] उपयोगकर्ता के पार्टिशन के ब्लॉक-लेवल एन्क्रिप्शन के लिए, AES-256-XTS का इस्तेमाल करना ज़रूरी है.
उपयोगकर्ता के हिसाब से ब्लॉक-लेवल पर एन्क्रिप्ट किए गए डिवाइसों की सुरक्षा करने वाली कुंजियां:
[C-1-5] इसे क्रिप्टोग्राफ़िक तरीके से, हार्डवेयर में सेव किए गए कीस्टोर से बाइंड किया जाना चाहिए. यह कीस्टोर, वेरिफ़ाइड बूट और डिवाइस के हार्डवेयर रूट ऑफ़ ट्रस्ट से जुड़ा होना चाहिए.
[C-1-6] यह उपयोगकर्ता की लॉक स्क्रीन के क्रेडेंशियल से जुड़ा होना चाहिए.

हर उपयोगकर्ता के लिए ब्लॉक-लेवल एन्क्रिप्शन को लागू करने के लिए, Linux कर्नल की “dm-crypt” सुविधा का इस्तेमाल किया जा सकता है. यह सुविधा, हर उपयोगकर्ता के लिए बनाए गए पार्टीशन पर काम करती है.

9.9.4. रीबूट करने पर फिर से शुरू करें

'रीबूट करने पर फिर से शुरू करें' सुविधा की मदद से, ओटीए के ज़रिए रीबूट करने के बाद, उन सभी ऐप्लिकेशन के सीई स्टोरेज को अनलॉक किया जा सकता है जो डायरेक्ट बूट की सुविधा के साथ काम नहीं करते. इस सुविधा की मदद से, डिवाइस को रीबूट करने के बाद भी इंस्टॉल किए गए ऐप्लिकेशन से सूचनाएं मिलती रहती हैं.

Resume-on-Reboot की सुविधा को लागू करने के बाद भी यह पक्का करना ज़रूरी है कि अगर डिवाइस किसी हमलावर के हाथ लग जाता है, तो उसके लिए उपयोगकर्ता के CE-encrypted डेटा को वापस पाना बहुत मुश्किल हो. भले ही, डिवाइस चालू हो, CE स्टोरेज अनलॉक हो, और उपयोगकर्ता ने ओटीए मिलने के बाद डिवाइस को अनलॉक कर दिया हो. हम यह भी मानते हैं कि अंदरूनी व्यक्ति के हमले को रोकने के लिए, हमलावर को ब्रॉडकास्ट क्रिप्टोग्राफ़िक साइनिंग कुंजियों का ऐक्सेस मिल जाता है.

खास तौर से:

[C-0-1] CE स्टोरेज को कोई भी व्यक्ति नहीं पढ़ सकता. यहां तक कि वह हमलावर भी नहीं जिसके पास डिवाइस का ऐक्सेस है. हालांकि, उसके पास ये सुविधाएं और सीमाएं होनी चाहिए:
- आर्बिट्रेरी मैसेज पर हस्ताक्षर करने के लिए, किसी भी वेंडर या कंपनी की हस्ताक्षर करने वाली कुंजी का इस्तेमाल कर सकता है.
- इससे डिवाइस को ओटीए मिल सकता है.
- नीचे दी गई जानकारी को छोड़कर, किसी भी हार्डवेयर (एपी, फ़्लैश वगैरह) के ऑपरेशन में बदलाव कर सकता है. हालांकि, इस तरह के बदलाव में कम से कम एक घंटे की देरी होती है और पावर साइकल की वजह से रैम का कॉन्टेंट मिट जाता है.
- छेड़छाड़ से सुरक्षित हार्डवेयर (जैसे, Titan M) के ऑपरेशन में बदलाव नहीं किया जा सकता.
- लाइव डिवाइस की रैम को नहीं पढ़ा जा सकता.
- उपयोगकर्ता के क्रेडेंशियल (पिन, पैटर्न, पासवर्ड) को हासिल नहीं किया जा सकता या किसी अन्य तरीके से उसे डाला नहीं जा सकता.

उदाहरण के लिए, अगर कोई डिवाइस, यहां दी गई सभी शर्तों को पूरा करता है, तो वह [C-0-1] का पालन करता है.

9.10. डिवाइस इंटिग्रिटी

यहां दी गई ज़रूरी शर्तों से, डिवाइस की इंटिग्रिटी की स्थिति के बारे में पारदर्शिता बनी रहती है. डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-1] सिस्टम एपीआई के PersistentDataBlockManager.getFlashLockState() तरीके का इस्तेमाल करके, यह सही तरीके से रिपोर्ट करना ज़रूरी है कि बूटलोडर की स्थिति, सिस्टम इमेज को फ़्लैश करने की अनुमति देती है या नहीं. FLASH_LOCK_UNKNOWN स्थिति, डिवाइसों के उन वर्शन के लिए रिज़र्व की गई है जो Android के पुराने वर्शन से अपग्रेड किए जा रहे हैं. इन वर्शन में, सिस्टम एपीआई का यह नया तरीका मौजूद नहीं था.
[C-0-2] डिवाइस इंटिग्रिटी के लिए, वेरिफ़ाइड बूट की सुविधा उपलब्ध होना ज़रूरी है.

अगर डिवाइसों को Android के पुराने वर्शन पर, वेरिफ़ाइड बूट की सुविधा के बिना ही लॉन्च कर दिया गया है और सिस्टम सॉफ़्टवेयर को अपडेट करके इस सुविधा को नहीं जोड़ा जा सकता, तो हो सकता है कि उन्हें इस ज़रूरी शर्त से छूट मिल जाए.

वेरिफ़ाइड बूट एक ऐसी सुविधा है जो डिवाइस के सॉफ़्टवेयर की सुरक्षा की गारंटी देती है. अगर डिवाइस में इस सुविधा का इस्तेमाल किया जा सकता है, तो:

[C-1-1] प्लैटफ़ॉर्म के फ़ीचर फ़्लैग android.software.verified_boot के बारे में एलान करना ज़रूरी है.
[C-1-2] हर बूट सीक्वेंस पर पुष्टि की जानी चाहिए.
[C-1-3] पुष्टि की कार्रवाई, हार्डवेयर की ऐसी कुंजी से शुरू होनी चाहिए जिसे बदला नहीं जा सकता. यह कुंजी, भरोसे का मूल आधार होती है. साथ ही, यह कार्रवाई सिस्टम पार्टीशन तक होनी चाहिए.
[C-1-4] अगले चरण में कोड को लागू करने से पहले, यह ज़रूरी है कि पुष्टि करने वाला हर चरण लागू किया जाए. इससे अगले चरण में मौजूद सभी बाइट की पुष्टि की जा सकेगी और यह पता लगाया जा सकेगा कि वे असली हैं या नहीं.
[C-1-5] हैशिंग एल्गोरिदम (SHA-256) और सार्वजनिक कुंजी के साइज़ (RSA-2048) के लिए, NIST की मौजूदा सलाह के मुताबिक पुष्टि करने वाले एल्गोरिदम का इस्तेमाल करना ज़रूरी है.
[C-1-6] सिस्टम की पुष्टि न होने पर, बूटिंग पूरी करने की अनुमति नहीं देनी चाहिए. हालांकि, अगर उपयोगकर्ता बूटिंग की कोशिश करने के लिए सहमति देता है, तो बूटिंग की अनुमति दी जा सकती है. ऐसे में, पुष्टि न किए गए किसी भी स्टोरेज ब्लॉक के डेटा का इस्तेमाल नहीं किया जाना चाहिए.
[C-1-7] डिवाइस पर पुष्टि किए गए पार्टीशन में बदलाव करने की अनुमति नहीं देनी चाहिए. ऐसा तब तक नहीं किया जाना चाहिए, जब तक उपयोगकर्ता ने बूटलोडर को साफ़ तौर पर अनलॉक न कर दिया हो.
[C-SR] अगर डिवाइस में कई अलग-अलग चिप मौजूद हैं (जैसे, रेडियो, इमेज प्रोसेसर), तो हमारा सुझाव है कि बूट होने पर हर स्टेज की पुष्टि की जाए.
[C-1-8] छेड़छाड़ से सुरक्षित स्टोरेज का इस्तेमाल करना ज़रूरी है: यह जानकारी सेव करने के लिए कि बूटलोडर अनलॉक है या नहीं. टैंपर-एविडेंट स्टोरेज का मतलब है कि बूटलोडर यह पता लगा सकता है कि Android के अंदर से स्टोरेज में छेड़छाड़ की गई है या नहीं.
[C-1-9] डिवाइस का इस्तेमाल करते समय, उपयोगकर्ता को सूचना देनी चाहिए. साथ ही, बूटलोडर लॉक मोड से बूटलोडर अनलॉक मोड पर स्विच करने की अनुमति देने से पहले, पुष्टि करनी चाहिए.
[C-1-10] Android के इस्तेमाल किए गए पार्टीशन (जैसे, बूट, सिस्टम पार्टीशन) के लिए, रोलबैक सुरक्षा लागू करना ज़रूरी है. साथ ही, ओएस के कम से कम मान्य वर्शन का पता लगाने के लिए इस्तेमाल किए गए मेटाडेटा को सेव करने के लिए, छेड़छाड़ से सुरक्षित स्टोरेज का इस्तेमाल करना ज़रूरी है.
[C-SR] सभी विशेषाधिकार वाले ऐप्लिकेशन की APK फ़ाइलों की पुष्टि करने के लिए, भरोसे की चेन का इस्तेमाल करने का सुझाव दिया जाता है. यह चेन, वेरिफ़ाइड बूट से सुरक्षित किए गए पार्टीशन से जुड़ी होती है.
[C-SR] यह ज़ोरदार सुझाव दिया जाता है कि विशेषाधिकार वाला ऐप्लिकेशन, अपनी APK फ़ाइल के बाहर से लोड किए गए किसी भी एक्ज़ीक्यूटेबल आर्टफ़ैक्ट (जैसे, डाइनैमिक तौर पर लोड किया गया कोड या कंपाइल किया गया कोड) की पुष्टि करने के बाद ही उसे एक्ज़ीक्यूट करे. यह भी ज़ोरदार सुझाव दिया जाता है कि वह उन्हें एक्ज़ीक्यूट न करे.
उसे ऐसे किसी भी कॉम्पोनेंट के लिए रोलबैक सुरक्षा लागू करनी चाहिए जिसमें लगातार फ़र्मवेयर (जैसे, मॉडेम, कैमरा) मौजूद रहता है.साथ ही, उसे ऐसे स्टोरेज का इस्तेमाल करना चाहिए जिसमें छेड़छाड़ का पता चल सके. ऐसा इसलिए, ताकि कम से कम अनुमत वर्शन का पता लगाने के लिए इस्तेमाल किए गए मेटाडेटा को सेव किया जा सके.

अगर डिवाइसों को Android के पुराने वर्शन पर C-1-8 से C-1-10 तक की ज़रूरी शर्तों को पूरा किए बिना लॉन्च किया गया है और सिस्टम सॉफ़्टवेयर अपडेट के साथ इन ज़रूरी शर्तों को पूरा नहीं किया जा सकता, तो उन्हें इन ज़रूरी शर्तों से छूट मिल सकती है.

अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट, external/avb/ रिपॉज़िटरी में इस सुविधा को लागू करने का सबसे सही तरीका बताता है. इसे Android लोड करने के लिए इस्तेमाल किए जाने वाले बूटलोडर में इंटिग्रेट किया जा सकता है.

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-3] फ़ाइल के पूरे कॉन्टेंट को पढ़े बिना, भरोसेमंद कुंजी के आधार पर क्रिप्टोग्राफ़िक तरीके से फ़ाइल के कॉन्टेंट की पुष्टि करने की सुविधा होनी चाहिए.
[C-0-4] सुरक्षित की गई फ़ाइल पर पढ़ने के अनुरोधों को तब तक पूरा नहीं किया जाना चाहिए, जब तक कि पढ़े गए कॉन्टेंट की पुष्टि किसी भरोसेमंद कुंजी से न हो जाए.

अगर डिवाइसों पर, Android के पुराने वर्शन पर भरोसेमंद कुंजी के ख़िलाफ़ फ़ाइल के कॉन्टेंट की पुष्टि करने की सुविधा के बिना ही, डिवाइसों को लॉन्च कर दिया गया है और सिस्टम सॉफ़्टवेयर अपडेट के साथ इस सुविधा को नहीं जोड़ा जा सकता, तो हो सकता है कि उन्हें इस ज़रूरी शर्त से छूट मिल जाए. अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट, Linux कर्नल की fs-verity सुविधा के आधार पर, इस सुविधा को लागू करने का पसंदीदा तरीका उपलब्ध कराता है.

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-R] Android Protected Confirmation API के साथ काम करने का सुझाव दिया जाता है.

अगर डिवाइस में Android Protected Confirmation API काम करता है, तो:

[C-3-1] ConfirmationPrompt.isSupported() एपीआई के लिए, true की जानकारी देनी होगी.
[C-3-2] यह पक्का करना ज़रूरी है कि Android OS में चल रहा कोड, उपयोगकर्ता के इंटरैक्शन के बिना पॉज़िटिव रिस्पॉन्स जनरेट न कर सके. इसमें कर्नल, नुकसान पहुंचाने वाला कोड या अन्य कोड शामिल है.
[C-3-3] यह पक्का करना ज़रूरी है कि उपयोगकर्ता, प्रॉम्प्ट किए गए मैसेज की समीक्षा कर सके और उसे स्वीकार कर सके. भले ही, Android ओएस और उसके कर्नल से समझौता किया गया हो.

9.11. कुंजियां और क्रेडेंशियल

Android Keystore System की मदद से, ऐप्लिकेशन डेवलपर क्रिप्टोग्राफ़िक पासकोड को किसी कंटेनर में सेव कर सकते हैं. साथ ही, KeyChain API या Keystore API के ज़रिए, क्रिप्टोग्राफ़िक ऑपरेशनों में उनका इस्तेमाल कर सकते हैं. डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-1] कम से कम 8,192 कुंजियां इंपोर्ट या जनरेट करने की अनुमति होनी चाहिए.
[C-0-2] लॉक स्क्रीन पर पुष्टि करने की कोशिशों पर, दर की सीमा लागू होनी चाहिए. साथ ही, इसमें एक्सपोनेंशियल बैकऑफ़ एल्गोरिदम होना चाहिए. अगर 150 बार से ज़्यादा बार पुष्टि नहीं हो पाती है, तो हर बार पुष्टि करने के लिए कम से कम 24 घंटे का इंतज़ार करना होगा.
जनरेट की जा सकने वाली कुंजियों की संख्या को सीमित नहीं करना चाहिए

अगर डिवाइस में सुरक्षित लॉक स्क्रीन की सुविधा काम करती है, तो:

[C-1-1] ज़रूरी है कि कीस्टोर को लागू करने के लिए, अलग से एक्ज़ीक्यूशन एनवायरमेंट का इस्तेमाल किया जाए.
[C-1-2] इसमें RSA, AES, ECDSA, और HMAC क्रिप्टोग्राफ़िक एल्गोरिदम के साथ-साथ MD5, SHA1, और SHA-2 फ़ैमिली हैश फ़ंक्शन लागू होने चाहिए. ऐसा इसलिए, ताकि Android Keystore सिस्टम के साथ काम करने वाले एल्गोरिदम को सही तरीके से इस्तेमाल किया जा सके. साथ ही, यह भी ज़रूरी है कि यह एल्गोरिदम, कर्नल और उससे ऊपर के कोड से सुरक्षित तरीके से अलग किया गया हो. सुरक्षित आइसोलेशन को उन सभी संभावित तरीकों को ब्लॉक करना होगा जिनसे कर्नेल या यूज़रस्पेस कोड, आइसोलेट किए गए एनवायरमेंट की इंटरनल स्थिति को ऐक्सेस कर सकता है. इसमें डीएमए भी शामिल है. अपस्ट्रीम Android Open Source Project (AOSP), Trusty को लागू करके इस ज़रूरी शर्त को पूरा करता है. हालांकि, एआरएम TrustZone पर आधारित कोई अन्य समाधान या तीसरे पक्ष की ओर से समीक्षा किया गया, हाइपरवाइज़र पर आधारित आइसोलेशन को सुरक्षित तरीके से लागू करने का तरीका भी इस्तेमाल किया जा सकता है.
[C-1-3] लॉक स्क्रीन की पुष्टि, आइसोलेटेड एक्ज़ीक्यूशन एनवायरमेंट में ही की जानी चाहिए. साथ ही, पुष्टि हो जाने के बाद ही, पुष्टि से जुड़ी कुंजियों का इस्तेमाल करने की अनुमति दी जानी चाहिए. लॉक स्क्रीन के क्रेडेंशियल को इस तरह से सेव किया जाना चाहिए कि सिर्फ़ आइसोलेटेड एक्ज़ीक्यूशन एनवायरमेंट ही लॉक स्क्रीन की पुष्टि कर सके. अपस्ट्रीम Android Open Source Project, Gatekeeper Hardware Abstraction Layer (HAL) और Trusty उपलब्ध कराता है. इनका इस्तेमाल इस ज़रूरी शर्त को पूरा करने के लिए किया जा सकता है.
[C-1-4] इसमें कुंजी की पुष्टि करने की सुविधा होनी चाहिए. इसमें पुष्टि करने के लिए इस्तेमाल की जाने वाली हस्ताक्षर कुंजी को सुरक्षित हार्डवेयर से सुरक्षित किया जाता है और हस्ताक्षर करने की प्रोसेस सुरक्षित हार्डवेयर में की जाती है. पुष्टि करने के लिए इस्तेमाल की जाने वाली साइनिंग कुंजियों को ज़्यादा से ज़्यादा डिवाइसों के साथ शेयर किया जाना चाहिए, ताकि इन कुंजियों का इस्तेमाल डिवाइस आइडेंटिफ़ायर के तौर पर न किया जा सके. इस ज़रूरी शर्त को पूरा करने का एक तरीका यह है कि जब तक किसी एसकेयू की कम से कम 1,00,000 यूनिट नहीं बन जातीं, तब तक एक ही पुष्टि करने वाली कुंजी शेयर की जाए. अगर किसी एसकेयू की 1,00,000 से ज़्यादा इकाइयां बनाई जाती हैं, तो हर 1,00,000 इकाइयों के लिए अलग कुंजी का इस्तेमाल किया जा सकता है.

[C-1-5] उपयोगकर्ता को, अनलॉक से लॉक की गई स्थिति में ट्रांज़िशन के लिए, स्लीप टाइमआउट चुनने की अनुमति देनी होगी. इसके लिए, कम से कम 15 सेकंड का टाइमआउट सेट किया जा सकता है. ऑटोमोटिव डिवाइसों में, स्लीप मोड में जाने के लिए तय समय को कॉन्फ़िगर करने की सुविधा नहीं हो सकती. ऐसा तब होता है, जब हेड यूनिट बंद हो जाती है या उपयोगकर्ता स्विच हो जाता है.

9.11.1. सुरक्षित लॉक स्क्रीन और पुष्टि करने की सुविधा

AOSP में, ऑथेंटिकेशन के लिए टियर वाला मॉडल इस्तेमाल किया जाता है. इसमें, जानकारी पर आधारित मुख्य ऑथेंटिकेशन को, मज़बूत सेकंडरी बायोमेट्रिक या कमज़ोर टर्शियरी मोडैलिटी से बैकअप लिया जा सकता है.

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-SR] यह सुझाव दिया जाता है कि पुष्टि करने के मुख्य तरीके के तौर पर, इनमें से सिर्फ़ एक को सेट किया जाए:
- अंकों वाला पिन
- अक्षर और अंक वाला पासवर्ड
- ठीक 3x3 बिंदुओं की ग्रिड पर स्वाइप करने का पैटर्न

ध्यान दें कि पुष्टि करने के ऊपर दिए गए तरीकों को इस दस्तावेज़ में, पुष्टि करने के सुझाए गए मुख्य तरीकों के तौर पर बताया गया है.

अगर डिवाइस पर, पुष्टि करने के सुझाए गए मुख्य तरीकों को जोड़ा या उनमें बदलाव किया जाता है और स्क्रीन लॉक करने के लिए, पुष्टि करने के नए तरीके का इस्तेमाल किया जाता है, तो पुष्टि करने का नया तरीका:

[C-2-1] यह कुंजी के इस्तेमाल के लिए उपयोगकर्ता की पुष्टि करना ज़रूरी है में बताए गए तरीके के मुताबिक, उपयोगकर्ता की पुष्टि करने का तरीका होना चाहिए.

अगर डिवाइस के लागू करने वाले लोग, लॉक स्क्रीन को अनलॉक करने के लिए पुष्टि करने के तरीकों में बदलाव करते हैं या उन्हें जोड़ते हैं. ऐसा तब किया जाता है, जब वे किसी जाने-पहचाने सीक्रेट पर आधारित हों. साथ ही, स्क्रीन को लॉक करने के सुरक्षित तरीके के तौर पर, पुष्टि करने के नए तरीके का इस्तेमाल करते हों, तो:

[C-3-1] इनपुट की सबसे छोटी मान्य लंबाई की एंट्रॉपी, 10 बिट से ज़्यादा होनी चाहिए.
[C-3-2] सभी संभावित इनपुट की ज़्यादा से ज़्यादा एंट्रॉपी 18 बिट से ज़्यादा होनी चाहिए.
[C-3-3] पुष्टि करने के नए तरीके से, AOSP में लागू किए गए और दिए गए, पुष्टि करने के सुझाए गए मुख्य तरीकों (जैसे, पिन, पैटर्न, पासवर्ड) में से किसी को भी नहीं बदला जाना चाहिए.
[C-3-4] अगर डिवाइस नीति कंट्रोलर (डीपीसी) ऐप्लिकेशन ने DevicePolicyManager.setPasswordQuality() तरीके से पासवर्ड की क्वालिटी से जुड़ी नीति सेट की है और क्वालिटी का कॉन्स्टेंट PASSWORD_QUALITY_SOMETHING से ज़्यादा पाबंदी वाला है, तो पुष्टि करने के नए तरीके को बंद कर दिया जाना चाहिए.
[C-3-5] पुष्टि करने के नए तरीकों को हर 72 घंटे या उससे कम समय में, पुष्टि करने के सुझाए गए मुख्य तरीकों (जैसे, पिन, पैटर्न, पासवर्ड) पर वापस आना होगा. इसके अलावा, उन्हें उपयोगकर्ता को साफ़ तौर पर यह बताना होगा कि उनके डेटा की निजता बनाए रखने के लिए, कुछ डेटा का बैक अप नहीं लिया जाएगा.

अगर डिवाइस के लिए उपलब्ध कराए गए सॉफ़्टवेयर में, लॉक स्क्रीन को अनलॉक करने के लिए सुझाए गए पुष्टि करने के मुख्य तरीकों में बदलाव किया जाता है या उन्हें जोड़ा जाता है. साथ ही, बायोमेट्रिक डेटा पर आधारित पुष्टि करने के नए तरीके का इस्तेमाल किया जाता है, ताकि स्क्रीन को सुरक्षित तरीके से लॉक किया जा सके, तो नया तरीका:

[C-4-1] क्लास 1 (पहले सुविधा) के लिए, सेक्शन 7.3.10 में बताई गई सभी ज़रूरी शर्तों को पूरा करना होगा.
[C-4-2] MUST have a fall-back mechanism to use one of the recommended primary authentication methods which is based on a known secret.
[C-4-3] इसे बंद किया जाना चाहिए.साथ ही, डिवाइस नीति कंट्रोलर (डीपीसी) ऐप्लिकेशन के DevicePolicyManager.setKeyguardDisabledFeatures() तरीके को कॉल करके, कीगार्ड सुविधा की नीति सेट करने पर, स्क्रीन को अनलॉक करने के लिए सिर्फ़ पुष्टि करने के सुझाए गए मुख्य तरीके का इस्तेमाल करने की अनुमति दी जानी चाहिए. इसके साथ ही, बायोमेट्रिक से जुड़े किसी भी फ़्लैग (जैसे कि KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE या KEYGUARD_DISABLE_IRIS) का इस्तेमाल किया जाना चाहिए.

अगर बायोमेट्रिक ऑथेंटिकेशन के तरीके, सेक्शन 7.3.10 में बताए गए क्लास 3 (पहले मज़बूत) की ज़रूरी शर्तों को पूरा नहीं करते हैं, तो:

[C-5-1] अगर डिवाइस नीति कंट्रोलर (डीपीसी) ऐप्लिकेशन ने DevicePolicyManager.setPasswordQuality() तरीके से पासवर्ड की क्वालिटी के लिए नीति सेट की है और क्वालिटी के लिए कॉन्स्टेंट PASSWORD_QUALITY_BIOMETRIC_WEAK से ज़्यादा पाबंदी वाला है, तो इन तरीकों को बंद करना होगा.
[C-5-2] उपयोगकर्ता को, सुझाए गए प्राइमरी ऑथेंटिकेशन (जैसे: पिन, पैटर्न, पासवर्ड) के लिए चुनौती दी जानी चाहिए. इसके बारे में सेक्शन 7.3.10 में [C-1-7] और [C-1-8] में बताया गया है.
[C-5-3] इन तरीकों को सुरक्षित लॉक स्क्रीन के तौर पर नहीं माना जाना चाहिए. साथ ही, इन्हें इस सेक्शन में नीचे दी गई C-8 से शुरू होने वाली ज़रूरी शर्तों को पूरा करना चाहिए.

अगर डिवाइस के लागू किए गए तरीके, लॉक स्क्रीन को अनलॉक करने के लिए पुष्टि करने के तरीकों को जोड़ते या उनमें बदलाव करते हैं और पुष्टि करने का नया तरीका, फ़िज़िकल टोकन या जगह की जानकारी पर आधारित है, तो:

[C-6-1] उनके पास, पुष्टि करने के सुझाए गए मुख्य तरीकों में से किसी एक का इस्तेमाल करने के लिए, फ़ॉल-बैक मैकेनिज़्म होना चाहिए. यह मैकेनिज़्म, किसी जाने-पहचाने सीक्रेट पर आधारित होता है. साथ ही, यह सुरक्षित लॉक स्क्रीन के तौर पर इस्तेमाल किए जाने की ज़रूरी शर्तों को पूरा करता है.
[C-6-2] डिवाइस नीति नियंत्रक (डीपीसी) ऐप्लिकेशन ने DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) या DevicePolicyManager.setPasswordQuality() तरीके से नीति सेट की हो और PASSWORD_QUALITY_UNSPECIFIED से ज़्यादा पाबंदियों वाली क्वालिटी कॉन्स्टेंट का इस्तेमाल किया हो, तो नए तरीके को बंद करना होगा. साथ ही, स्क्रीन को अनलॉक करने के लिए, पुष्टि करने के सुझाए गए मुख्य तरीकों में से सिर्फ़ एक तरीके का इस्तेमाल करने की अनुमति देनी होगी.
[C-6-3] उपयोगकर्ता को कम से कम हर चार घंटे में एक बार, पुष्टि करने के लिए सुझाए गए मुख्य तरीकों (जैसे, पिन, पैटर्न, पासवर्ड) में से किसी एक का इस्तेमाल करने के लिए कहा जाना चाहिए.
[C-6-4] नए तरीके को सुरक्षित लॉक स्क्रीन के तौर पर नहीं माना जाना चाहिए. साथ ही, इसे C-8 में बताई गई पाबंदियों का पालन करना चाहिए.

अगर डिवाइस में सुरक्षित लॉक स्क्रीन की सुविधा है और उसमें एक या उससे ज़्यादा भरोसेमंद एजेंट शामिल हैं, जो TrustAgentService System API को लागू करते हैं, तो:

[C-7-1] डिवाइस लॉक होने में देरी होने या भरोसेमंद एजेंट की मदद से अनलॉक किए जा सकने की स्थिति में, सेटिंग मेन्यू और लॉक स्क्रीन पर इसकी जानकारी साफ़ तौर पर दिखनी चाहिए. उदाहरण के लिए, AOSP इस ज़रूरी शर्त को पूरा करता है. इसके लिए, वह सेटिंग मेन्यू में "अपने-आप लॉक होने की सेटिंग" और "पावर बटन से तुरंत लॉक होने की सुविधा" के लिए टेक्स्ट में जानकारी दिखाता है. साथ ही, लॉक स्क्रीन पर अलग से दिखने वाला आइकॉन दिखाता है.
[C-7-2] DevicePolicyManager क्लास में मौजूद, भरोसेमंद एजेंट के सभी एपीआई का पालन करना होगा और उन्हें पूरी तरह से लागू करना होगा. जैसे, KEYGUARD_DISABLE_TRUST_AGENTS कॉन्स्टेंट.
[C-7-3] TrustAgentService.addEscrowToken() फ़ंक्शन को ऐसे डिवाइस पर पूरी तरह से लागू नहीं किया जाना चाहिए जिसका इस्तेमाल मुख्य तौर पर निजी डिवाइस के तौर पर किया जाता है. जैसे, हैंडहेल्ड डिवाइस. हालाँकि, इस फ़ंक्शन को ऐसे डिवाइसों पर पूरी तरह से लागू किया जा सकता है जिन्हें आम तौर पर शेयर किया जाता है. जैसे, Android TV या Automotive डिवाइस.
[C-7-4] यह ज़रूरी है कि TrustAgentService.addEscrowToken() से जोड़े गए सभी सेव किए गए टोकन को एन्क्रिप्ट (सुरक्षित) किया जाए.
[C-7-5] एन्क्रिप्शन कुंजी या एस्क्रो टोकन को उस डिवाइस पर सेव नहीं करना चाहिए जिस पर कुंजी का इस्तेमाल किया जाता है. उदाहरण के लिए, फ़ोन में सेव की गई पासकी का इस्तेमाल करके, टीवी पर उपयोगकर्ता खाते को अनलॉक किया जा सकता है. ऑटोमोटिव डिवाइसों के लिए, एस्क्रो टोकन को वाहन के किसी भी हिस्से में सेव करने की अनुमति नहीं है.
[C-7-6] डेटा स्टोरेज को डिक्रिप्ट करने के लिए एस्क्रो टोकन चालू करने से पहले, उपयोगकर्ता को सुरक्षा से जुड़ी समस्याओं के बारे में बताना ज़रूरी है.
[C-7-7] पुष्टि करने के सुझाए गए मुख्य तरीकों में से किसी एक का इस्तेमाल करने के लिए, फ़ॉल-बैक मैकेनिज़्म होना ज़रूरी है.
[C-7-8] उपयोगकर्ता को हर 72 घंटे में कम से कम एक बार, पुष्टि करने के लिए सुझाए गए मुख्य तरीकों (जैसे: पिन, पैटर्न, पासवर्ड) में से किसी एक का इस्तेमाल करने के लिए कहा जाना चाहिए. हालांकि, अगर उपयोगकर्ता की सुरक्षा (जैसे कि ड्राइवर का ध्यान भटकना) से जुड़ी कोई समस्या है, तो ऐसा नहीं किया जाना चाहिए.
[C-7-9] उपयोगकर्ता को पुष्टि करने के लिए, [C-1-7] और [C-1-8] में बताए गए, पुष्टि करने के सुझाए गए मुख्य तरीकों (जैसे: पिन, पैटर्न, पासवर्ड) में से किसी एक का इस्तेमाल करने के लिए कहा जाना चाहिए.यह बात सेक्शन 7.3.10 में बताई गई है. हालांकि, अगर उपयोगकर्ता की सुरक्षा (जैसे कि ड्राइवर का ध्यान भटकना) से जुड़ी कोई समस्या है, तो ऐसा नहीं किया जाना चाहिए.
[C-7-10] को सुरक्षित लॉक स्क्रीन के तौर पर नहीं माना जाना चाहिए. साथ ही, इसे नीचे दिए गए C-8 में बताई गई पाबंदियों का पालन करना चाहिए.
[C-7-11] मुख्य निजी डिवाइसों (जैसे: हैंडहेल्ड) पर TrustAgents को डिवाइस अनलॉक करने की अनुमति नहीं देनी चाहिए.साथ ही, इनका इस्तेमाल सिर्फ़ पहले से अनलॉक किए गए डिवाइस को ज़्यादा से ज़्यादा चार घंटे तक अनलॉक रखने के लिए किया जा सकता है. AOSP में TrustManagerService का डिफ़ॉल्ट तौर पर लागू किया गया वर्शन, इस ज़रूरी शर्त को पूरा करता है.
[C-7-12] स्टोरेज डिवाइस से टारगेट डिवाइस में एस्क्रो टोकन भेजने के लिए, क्रिप्टोग्राफ़िक तौर पर सुरक्षित (जैसे, UKEY2) कम्यूनिकेशन चैनल का इस्तेमाल करना ज़रूरी है.

अगर डिवाइस बनाने वाली कंपनियां, लॉक स्क्रीन को अनलॉक करने के लिए पुष्टि करने के ऐसे तरीके जोड़ती हैं या उनमें बदलाव करती हैं जो ऊपर बताए गए तरीके की तरह सुरक्षित नहीं हैं. साथ ही, कीगार्ड को अनलॉक करने के लिए पुष्टि करने के नए तरीके का इस्तेमाल करती हैं, तो:

[C-8-1] अगर डिवाइस नीति कंट्रोलर (डीपीसी) ऐप्लिकेशन ने DevicePolicyManager.setPasswordQuality() तरीके से पासवर्ड की क्वालिटी से जुड़ी नीति सेट की है और क्वालिटी कॉन्स्टेंट PASSWORD_QUALITY_UNSPECIFIED से ज़्यादा पाबंदी वाला है, तो नए तरीके को बंद करना होगा.
[C-8-2] उन्हें DevicePolicyManager.setPasswordExpirationTimeout() की ओर से सेट किए गए, पासवर्ड की समयसीमा खत्म होने के टाइमर को रीसेट नहीं करना चाहिए.
[C-8-3] उन्हें तीसरे पक्ष के ऐप्लिकेशन को, लॉक की स्थिति बदलने के लिए एपीआई उपलब्ध नहीं कराना चाहिए.

9.11.2. StrongBox

Android Keystore System की मदद से, ऐप्लिकेशन डेवलपर क्रिप्टोग्राफ़िक कोड को सुरक्षित प्रोसेसर में सेव कर सकते हैं. साथ ही, ऊपर बताए गए अलग एक्ज़ीक्यूशन एनवायरमेंट में भी सेव कर सकते हैं. इस तरह के सुरक्षित प्रोसेसर को "StrongBox" कहा जाता है. नीचे दी गई ज़रूरी शर्तें C-1-3 से C-1-11 तक, उन ज़रूरी शर्तों के बारे में बताती हैं जिन्हें पूरा करने के बाद ही किसी डिवाइस को StrongBox के तौर पर इस्तेमाल किया जा सकता है.

डिवाइस में सेट किए हुए ऐसे सिस्टम जिनमें एक खास सुरक्षित प्रोसेसर होता है. इनके लिए ज़रूरी है कि:

[C-SR] StrongBox का इस्तेमाल करने का सुझाव दिया जाता है. ऐसा हो सकता है कि आने वाले समय में, StrongBox का इस्तेमाल करना ज़रूरी हो जाए.

अगर डिवाइस में StrongBox की सुविधा काम करती है, तो:

[C-1-1] FEATURE_STRONGBOX_KEYSTORE का एलान करना ज़रूरी है.
[C-1-2] MUST provide dedicated secure hardware that is used to back keystore and secure user authentication. सुरक्षित हार्डवेयर का इस्तेमाल अन्य कामों के लिए भी किया जा सकता है.
[C-1-3] इसमें एक अलग सीपीयू होना चाहिए, जो ऐप्लिकेशन प्रोसेसर (एपी) के साथ कोई कैश, DRAM, कोप्रोसेसर या अन्य मुख्य संसाधन शेयर न करता हो.
[C-1-4] यह पक्का करना ज़रूरी है कि एपी के साथ शेयर किए गए किसी भी पेरिफ़ेरल से, StrongBox की प्रोसेसिंग में किसी भी तरह का बदलाव न हो. साथ ही, यह भी ज़रूरी है कि वह StrongBox से कोई जानकारी न ले सके. एपी, StrongBox को बंद कर सकता है या इसके ऐक्सेस को ब्लॉक कर सकता है.
[C-1-5] इसमें सटीक समय (+-10%) दिखाने वाली इंटरनल क्लॉक होनी चाहिए. साथ ही, एपी के ज़रिए इसमें बदलाव नहीं किया जा सकता.
[C-1-6] में एक ऐसा रैंडम नंबर जनरेटर होना चाहिए जो एक जैसा और अनुमान न लगाया जा सकने वाला आउटपुट जनरेट करता हो.
[C-1-7] इसमें छेड़छाड़ नहीं की जा सकती. साथ ही, यह डिवाइस में छेद करने और गड़बड़ी होने से भी सुरक्षित होना चाहिए.
[C-1-8] इसमें साइड-चैनल के हमलों से सुरक्षा देने वाली सुविधा होनी चाहिए. इसमें पावर, टाइमिंग, इलेक्ट्रोमैग्नेटिक रेडिएशन, और थर्मल रेडिएशन साइड चैनलों के ज़रिए जानकारी लीक होने से सुरक्षा देने वाली सुविधा भी शामिल है.
[C-1-9] MUST have secure storage which ensures confidentiality, integrity, authenticity, consistency, and freshness of the contents. स्टोरेज को पढ़ा या बदला नहीं जा सकता. हालांकि, StrongBox API से इसकी अनुमति ली जा सकती है.
[C-1-3] से लेकर [C-1-9] तक की शर्तों का पालन करने के लिए, डिवाइस में सेट किए गए सिस्टम:
- [C-1-10] इसमें ऐसा हार्डवेयर शामिल होना चाहिए जिसे Secure IC Protection Profile BSI-CC-PP-0084-2014 के तहत सर्टिफ़िकेट मिला हो. इसके अलावा, इसका आकलन राष्ट्रीय स्तर पर मान्यता प्राप्त टेस्टिंग लैब ने किया हो. इसमें Common Criteria Application of Attack Potential to Smartcards के मुताबिक, ज़्यादा जोखिम वाले हमलों से जुड़ी कमज़ोरियों का आकलन शामिल हो.
- [C-1-11] इसमें ऐसा फ़र्मवेयर शामिल होना चाहिए जिसका आकलन, राष्ट्रीय स्तर पर मान्यता प्राप्त टेस्टिंग लैब ने किया हो. साथ ही, इसमें स्मार्टकार्ड के लिए, हमले की संभावना का आकलन करने के लिए कॉमन क्राइटेरिया के मुताबिक, हमले की ज़्यादा संभावना वाली कमज़ोरियों का आकलन शामिल होना चाहिए.
- [C-SR] यह सुझाव दिया जाता है कि ऐसे हार्डवेयर को शामिल किया जाए जिसका आकलन, सिक्योरिटी टारगेट, इवैलुएशन अश्योरेंस लेवल (ईएएल) 5, और AVA_VAN.5 का इस्तेमाल करके किया गया हो. ऐसा हो सकता है कि आने वाले समय में, EAL 5 सर्टिफ़िकेशन ज़रूरी हो जाए.
[C-SR] को अंदरूनी हमले से बचाने के लिए, STRONGLY RECOMMENDED किया जाता है. इसका मतलब है कि फ़र्मवेयर पर हस्ताक्षर करने वाली कुंजियों का ऐक्सेस रखने वाला कोई व्यक्ति ऐसा फ़र्मवेयर नहीं बना सकता जिसकी वजह से StrongBox से सीक्रेट लीक हो जाएं, सुरक्षा से जुड़ी ज़रूरी शर्तों को पूरा न किया जा सके या किसी अन्य तरीके से लोगों के संवेदनशील डेटा का ऐक्सेस मिल जाए. IAR को लागू करने का सबसे सही तरीका यह है कि फ़र्मवेयर अपडेट की अनुमति सिर्फ़ तब दी जाए, जब IAuthSecret HAL के ज़रिए मुख्य उपयोगकर्ता का पासवर्ड दिया गया हो.

9.11.3. आइडेंटिटी क्रेडेंशियल

आइडेंटिटी क्रेडेंशियल सिस्टम को android.security.identity.* पैकेज में मौजूद सभी एपीआई को लागू करके तय किया जाता है. इन एपीआई की मदद से, ऐप्लिकेशन डेवलपर उपयोगकर्ता की पहचान से जुड़े दस्तावेज़ों को सेव और वापस पा सकते हैं. डिवाइस में सेट किए गए सिस्टम के लिए:

[C-SR] को आइडेंटिटी क्रेडेंशियल सिस्टम लागू करने का सुझाव दिया जाता है.

अगर डिवाइसों में आइडेंटिटी क्रेडेंशियल सिस्टम लागू किया जाता है, तो:

[C-0-1] IdentityCredentialStore#getInstance() तरीके के लिए, गैर-शून्य वैल्यू दिखानी होगी.
[C-0-2] आइडेंटिटी क्रेडेंशियल सिस्टम (जैसे, android.security.identity.* एपीआई) को लागू करना ज़रूरी है. इसके लिए, कोड को कर्नल और उससे ऊपर चल रहे कोड से सुरक्षित तरीके से अलग किए गए क्षेत्र में, भरोसेमंद ऐप्लिकेशन के साथ कम्यूनिकेट करना होगा. सुरक्षित आइसोलेशन को उन सभी संभावित तरीकों को ब्लॉक करना होगा जिनसे कर्नेल या यूज़रस्पेस कोड, आइसोलेट किए गए एनवायरमेंट की इंटरनल स्थिति को ऐक्सेस कर सकता है. इसमें डीएमए भी शामिल है.
[C-0-3] आइडेंटिटी क्रेडेंशियल सिस्टम को लागू करने के लिए ज़रूरी क्रिप्टोग्राफ़िक कार्रवाइयां (जैसे, android.security.identity.* एपीआई) पूरी तरह से भरोसेमंद ऐप्लिकेशन में की जानी चाहिए. साथ ही, निजी कुंजी के मटीरियल को कभी भी आइसोलेटेड एक्ज़ीक्यूशन एनवायरमेंट से बाहर नहीं ले जाना चाहिए. हालांकि, अगर उच्च-स्तरीय एपीआई (जैसे, createEphemeralKeyPair() तरीका) के लिए इसकी ज़रूरत हो, तो ऐसा किया जा सकता है.
[C-0-4] भरोसेमंद ऐप्लिकेशन को इस तरह से लागू किया जाना चाहिए कि उसकी सुरक्षा से जुड़ी प्रॉपर्टी पर कोई असर न पड़े. उदाहरण के लिए, क्रेडेंशियल डेटा तब तक रिलीज़ नहीं किया जाना चाहिए, जब तक ऐक्सेस कंट्रोल की शर्तें पूरी न हो जाएं. साथ ही, मनमाने डेटा के लिए एमएसी जनरेट नहीं किए जा सकते. ऐसा तब भी होना चाहिए, जब Android ठीक से काम न कर रहा हो या उसके साथ समझौता किया गया हो.

9.12. डेटा हटाना

डिवाइस में सेट किए गए सभी सिस्टम के लिए:

[C-0-1] उपयोगकर्ताओं को "फ़ैक्ट्री डेटा रीसेट" करने का तरीका उपलब्ध कराना ज़रूरी है.
[C-0-2] उसे userdata फ़ाइल सिस्टम पर मौजूद सारा डेटा मिटाना होगा.
[C-0-3] डेटा को इस तरह से मिटाना होगा कि वह NIST SP800-88 जैसे इंडस्ट्री के मानकों के मुताबिक हो.
[C-0-4] जब मुख्य उपयोगकर्ता का डिवाइस नीति नियंत्रक ऐप्लिकेशन, DevicePolicyManager.wipeData() एपीआई को कॉल करता है, तो ऊपर दी गई "फ़ैक्ट्री डेटा रीसेट" प्रोसेस को ट्रिगर करना ज़रूरी है.
यह तेज़ी से डेटा मिटाने का विकल्प दे सकता है. इससे सिर्फ़ लॉजिकल डेटा मिटाया जाता है.

9.13. सुरक्षित बूट मोड

Android में सेफ़ बूट मोड की सुविधा मिलती है. इसकी मदद से उपयोगकर्ता, ऐसे मोड में बूट अप कर सकते हैं जहां सिर्फ़ पहले से इंस्टॉल किए गए सिस्टम ऐप्लिकेशन को चलाने की अनुमति होती है. साथ ही, तीसरे पक्ष के सभी ऐप्लिकेशन बंद हो जाते हैं. इस मोड को "सेफ़ बूट मोड" कहा जाता है. इससे उपयोगकर्ता को तीसरे पक्ष के ऐसे ऐप्लिकेशन अनइंस्टॉल करने की सुविधा मिलती है जो नुकसान पहुंचा सकते हैं.

डिवाइस में सेट किए गए सिस्टम के लिए:

[SR] सुरक्षित बूट मोड लागू करने का सुझाव दिया जाता है.

अगर डिवाइस में सुरक्षित बूट मोड लागू किया जाता है, तो:

[C-1-1] उपयोगकर्ता को सेफ़ बूट मोड में जाने का विकल्प देना ज़रूरी है. ऐसा इस तरह से किया जाना चाहिए कि डिवाइस पर इंस्टॉल किए गए तीसरे पक्ष के ऐप्लिकेशन, इस प्रोसेस में रुकावट न डालें. हालांकि, अगर तीसरे पक्ष का ऐप्लिकेशन, डिवाइस नीति कंट्रोलर है और उसने UserManager.DISALLOW_SAFE_BOOT फ़्लैग को सही के तौर पर सेट किया है, तो रुकावट डाली जा सकती है.
[C-1-2] उपयोगकर्ता को सुरक्षित मोड में, तीसरे पक्ष के किसी भी ऐप्लिकेशन को अनइंस्टॉल करने की सुविधा मिलनी चाहिए.
उपयोगकर्ता को बूट मेन्यू से सुरक्षित बूट मोड में जाने का विकल्प देना चाहिए. इसके लिए, सामान्य बूट से अलग वर्कफ़्लो का इस्तेमाल करना चाहिए.

9.14. ऑटोमोटिव वाहन सिस्टम आइसोलेशन

Android Automotive डिवाइसों से यह उम्मीद की जाती है कि वे वाहन के एचएएल का इस्तेमाल करके, वाहन के ज़रूरी सबसिस्टम के साथ डेटा शेयर करें. साथ ही, CAN बस जैसे वाहन के नेटवर्क पर मैसेज भेजें और पाएं.

डेटा एक्सचेंज को सुरक्षित किया जा सकता है. इसके लिए, Android फ़्रेमवर्क लेयर के नीचे सुरक्षा से जुड़ी सुविधाएं लागू करें. इससे इन सबसिस्टम के साथ नुकसान पहुंचाने वाले या अनजाने में होने वाले इंटरैक्शन को रोका जा सकता है.

9.15. सदस्यता प्लान

"सदस्यता प्लान" से मतलब, मोबाइल और इंटरनेट सेवा देने वाली कंपनी की ओर से SubscriptionManager.setSubscriptionPlans() के ज़रिए दी गई बिलिंग रिलेशनशिप प्लान की जानकारी से है.

डिवाइस में सेट किए गए सभी सिस्टम के लिए:

[C-0-1] सदस्यता प्लान सिर्फ़ उस मोबाइल और इंटरनेट सेवा देने वाली कंपनी के ऐप्लिकेशन को दिखाने चाहिए जिसने उन्हें उपलब्ध कराया है.
[C-0-2] सदस्यता योजनाओं का बैक अप दूर से नहीं लिया जाना चाहिए और न ही उन्हें अपलोड किया जाना चाहिए.
[C-0-3] सिर्फ़ उस मोबाइल कैरियर ऐप्लिकेशन से ओवरराइड करने की अनुमति मिलनी चाहिए जो फ़िलहाल मान्य सदस्यता प्लान उपलब्ध करा रहा है. जैसे, SubscriptionManager.setSubscriptionOverrideCongested().

9.16. ऐप्लिकेशन का डेटा माइग्रेट करना

अगर डिवाइसों में, एक डिवाइस से दूसरे डिवाइस पर डेटा माइग्रेट करने की सुविधा शामिल है और वे ऐप्लिकेशन के उस डेटा को कॉपी करने पर पाबंदी नहीं लगाते जिसे ऐप्लिकेशन डेवलपर ने मेनिफ़ेस्ट में android:fullBackupContent एट्रिब्यूट के ज़रिए कॉन्फ़िगर किया है, तो:

[C-1-1] ऐप्लिकेशन को ऐसे डिवाइसों से ऐप्लिकेशन डेटा ट्रांसफ़र शुरू नहीं करना चाहिए जिन पर उपयोगकर्ता ने 9.11.1 सुरक्षित लॉक स्क्रीन और पुष्टि करने की सुविधा में बताए गए तरीके से, पुष्टि करने का मुख्य तरीका सेट नहीं किया है.
[C-1-2] डेटा ट्रांसफ़र करने से पहले, सोर्स डिवाइस पर प्राइमरी पुष्टि को सुरक्षित तरीके से पूरा करना होगा. साथ ही, उपयोगकर्ता से यह पुष्टि करनी होगी कि वह सोर्स डिवाइस पर डेटा कॉपी करना चाहता है.
[C-1-3] डिवाइस से डिवाइस पर डेटा माइग्रेट करने के दौरान, यह पक्का करने के लिए कि सोर्स डिवाइस और टारगेट डिवाइस, दोनों ही असली Android डिवाइस हैं और उनका बूटलोडर लॉक है, सुरक्षा कुंजी की पुष्टि करने की सुविधा का इस्तेमाल करना ज़रूरी है.
[C-1-4] सिर्फ़ ऐप्लिकेशन के डेटा को टारगेट डिवाइस पर मौजूद उसी ऐप्लिकेशन में माइग्रेट करना होगा. साथ ही, ऐप्लिकेशन का पैकेज नाम और साइनिंग सर्टिफ़िकेट भी एक जैसा होना चाहिए.
[C-1-5] सेटिंग मेन्यू में यह जानकारी दिखनी चाहिए कि सोर्स डिवाइस से डेटा को डिवाइस-टू-डिवाइस डेटा माइग्रेशन की मदद से माइग्रेट किया गया है. उपयोगकर्ता के पास इस इंडिकेटर को हटाने का विकल्प नहीं होना चाहिए.

10. सॉफ़्टवेयर कंपैटिबिलिटी टेस्टिंग

डिवाइस में सेट किए गए सिस्टम के लिए, इस सेक्शन में बताए गए सभी टेस्ट पास करना ज़रूरी है. हालांकि, ध्यान दें कि कोई भी सॉफ़्टवेयर टेस्ट पैकेज पूरी तरह से भरोसेमंद नहीं होता. इस वजह से, डिवाइस बनाने वाली कंपनियों को यह सुझाव दिया जाता है कि वे Android Open Source Project से उपलब्ध Android के रेफ़रंस और पसंदीदा वर्शन में कम से कम बदलाव करें. इससे ऐसे बग आने का जोखिम कम हो जाएगा जो डिवाइसों के साथ काम नहीं करते. इसके लिए, आपको डिवाइसों को फिर से अपडेट करना पड़ सकता है.

10.1. Compatibility Test Suite

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-1] डिवाइस पर शिपिंग के लिए उपलब्ध फ़ाइनल सॉफ़्टवेयर का इस्तेमाल करके, Android Open Source Project से उपलब्ध Android Compatibility Test Suite (CTS) को पास करना ज़रूरी है.
[C-0-2] यह ज़रूरी है कि CTS में अस्पष्टता होने पर, यह कॉम्पोनेंट काम करे. साथ ही, रेफ़रंस सोर्स कोड के कुछ हिस्सों को फिर से लागू करने पर भी यह काम करे.

CTS को किसी असली डिवाइस पर चलाने के लिए डिज़ाइन किया गया है. किसी भी सॉफ़्टवेयर की तरह, सीटीएस में भी बग हो सकते हैं. सीटीएस का वर्शन, इस कंपैटिबिलिटी डेफ़िनिशन से अलग होगा. साथ ही, Android 11 के लिए सीटीएस के कई वर्शन रिलीज़ किए जा सकते हैं.

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-3] डिवाइस का सॉफ़्टवेयर तैयार होने के समय, CTS का सबसे नया वर्शन उपलब्ध होना चाहिए.
Android Open Source प्रोजेक्ट के ट्री में मौजूद रेफ़रंस इंप्लीमेंटेशन का ज़्यादा से ज़्यादा इस्तेमाल करना चाहिए.

10.2. सीटीएस की पुष्टि करने वाला टूल

CTS Verifier, Compatibility Test Suite में शामिल होता है. इसे किसी व्यक्ति को चलाना होता है, ताकि उन सुविधाओं की जांच की जा सके जिनकी जांच ऑटोमेटेड सिस्टम नहीं कर सकता. जैसे, कैमरे और सेंसर का सही तरीके से काम करना.

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-1] CTS verifier में, लागू होने वाले सभी मामलों को सही तरीके से लागू करना ज़रूरी है.

CTS Verifier में कई तरह के हार्डवेयर के लिए टेस्ट मौजूद हैं. इनमें कुछ ऐसे हार्डवेयर भी शामिल हैं जो ज़रूरी नहीं हैं.

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-2] यह ज़रूरी है कि डिवाइस में मौजूद हार्डवेयर के लिए, सभी टेस्ट पास किए जाएं. उदाहरण के लिए, अगर किसी डिवाइस में एक्सलरोमीटर है, तो यह ज़रूरी है कि वह CTS Verifier में एक्सलरोमीटर के टेस्ट केस को सही तरीके से पूरा करे.

इस कंपैटबिलिटी डेफ़िनिशन डॉक्यूमेंट में, जिन सुविधाओं को 'ज़रूरी नहीं' के तौर पर मार्क किया गया है उनके टेस्ट केस छोड़े जा सकते हैं.

[C-0-2] ऊपर बताए गए तरीके से, हर डिवाइस और हर बिल्ड पर CTS Verifier को सही तरीके से चलाना ज़रूरी है. हालांकि, कई बिल्ड एक जैसे होते हैं. इसलिए, डिवाइस बनाने वाली कंपनियों को ऐसे बिल्ड पर CTS Verifier चलाने की ज़रूरत नहीं होती जिनमें मामूली अंतर हो. खास तौर पर, डिवाइस में लागू किए गए ऐसे सिस्टम जिनमें सिर्फ़ शामिल की गई भाषाओं, ब्रैंडिंग वगैरह के आधार पर, CTS Verifier टेस्ट पास करने वाले सिस्टम से अलग हैं वे CTS Verifier टेस्ट को छोड़ सकते हैं.

11. अपडेट किया जा सकने वाला सॉफ़्टवेयर

[C-0-1] डिवाइस में, सिस्टम सॉफ़्टवेयर को पूरी तरह से बदलने का तरीका शामिल होना चाहिए. इस सुविधा के लिए, “लाइव” अपग्रेड करने की ज़रूरत नहीं होती. इसका मतलब है कि डिवाइस को रीस्टार्ट करना पड़ सकता है. कोई भी तरीका इस्तेमाल किया जा सकता है. हालांकि, यह ज़रूरी है कि इससे डिवाइस पर पहले से इंस्टॉल किए गए पूरे सॉफ़्टवेयर को बदला जा सके. उदाहरण के लिए, इनमें से किसी भी तरीके से इस ज़रूरी शर्त को पूरा किया जा सकता है:
- “ओवर-द-एयर (ओटीए)” डाउनलोड की सुविधा, जिसमें रीबूट करके ऑफ़लाइन अपडेट किया जा सकता है.
- होस्ट पीसी से यूएसबी के ज़रिए “टेथर्ड” अपडेट.
- “ऑफ़लाइन” अपडेट, रीबूट करके और हटाने लायक स्टोरेज डिवाइस पर मौजूद फ़ाइल से अपडेट करके किए जाते हैं.
[C-0-2] अपडेट करने के लिए इस्तेमाल किए जाने वाले सिस्टम में, उपयोगकर्ता के डेटा को मिटाए बिना अपडेट करने की सुविधा होनी चाहिए. इसका मतलब है कि अपडेट करने के तरीके से, ऐप्लिकेशन के निजी डेटा और ऐप्लिकेशन के शेयर किए गए डेटा को सुरक्षित रखना ज़रूरी है. ध्यान दें कि अपस्ट्रीम Android सॉफ़्टवेयर में, अपडेट करने का एक ऐसा तरीका शामिल होता है जो इस ज़रूरी शर्त को पूरा करता है.
[C-0-3] पूरे अपडेट पर हस्ताक्षर होना ज़रूरी है. साथ ही, डिवाइस पर अपडेट करने वाले सिस्टम को, डिवाइस पर सेव की गई सार्वजनिक कुंजी के हिसाब से अपडेट और हस्ताक्षर की पुष्टि करनी होगी.
[C-SR] साइन करने के तरीके में, SHA-256 का इस्तेमाल करके अपडेट को हैश करने का सुझाव दिया जाता है. साथ ही, ECDSA NIST P-256 का इस्तेमाल करके, सार्वजनिक पासकोड के हिसाब से हैश की पुष्टि करने का सुझाव दिया जाता है.

अगर डिवाइस में, बिना किसी शुल्क के डेटा कनेक्शन की सुविधा उपलब्ध है, जैसे कि 802.11 या ब्लूटूथ पीएएन (पर्सनल एरिया नेटवर्क) प्रोफ़ाइल, तो:

[C-1-1] डिवाइस में, रीबूट करके ऑफ़लाइन अपडेट करने की सुविधा के साथ-साथ, ओटीए डाउनलोड करने की सुविधा भी होनी चाहिए.

Android 6.0 और इसके बाद के वर्शन के साथ लॉन्च किए गए डिवाइसों के लिए, अपडेट करने के तरीके में यह पुष्टि करने की सुविधा होनी चाहिए कि ओटीए के बाद, सिस्टम इमेज बाइनरी के तौर पर, अनुमानित नतीजे के जैसी है. Android 5.1 से, अपस्ट्रीम Android Open Source Project में ब्लॉक-आधारित OTA लागू करने की सुविधा जोड़ी गई है. इससे इस ज़रूरी शर्त को पूरा किया जा सकता है.

साथ ही, डिवाइसों में A/B सिस्टम अपडेट की सुविधा होनी चाहिए. AOSP, बूट कंट्रोल HAL का इस्तेमाल करके इस सुविधा को लागू करता है.

अगर डिवाइस के रिलीज़ होने के बाद, उसके लागू करने में कोई गड़बड़ी मिलती है, लेकिन वह गड़बड़ी डिवाइस के सामान्य जीवनकाल के दौरान मिलती है. साथ ही, Android Compatibility Team के साथ सलाह-मशविरे के बाद यह तय किया जाता है कि इस गड़बड़ी से तीसरे पक्ष के ऐप्लिकेशन पर असर पड़ेगा, तो:

[C-2-1] डिवाइस बनाने वाली कंपनी को, उपलब्ध सॉफ़्टवेयर अपडेट के ज़रिए गड़बड़ी को ठीक करना होगा. इस अपडेट को, ऊपर बताए गए तरीके के मुताबिक लागू किया जा सकता है.

Android में ऐसी सुविधाएं शामिल होती हैं जिनकी मदद से, डिवाइस के मालिक का ऐप्लिकेशन (अगर मौजूद है) सिस्टम अपडेट के इंस्टॉलेशन को कंट्रोल कर सकता है. अगर डिवाइसों के लिए सिस्टम अपडेट सबसिस्टम, android.software.device_admin की रिपोर्ट करता है, तो:

[C-3-1] SystemUpdatePolicy क्लास में बताए गए व्यवहार को लागू करना ज़रूरी है.

12. दस्तावेज़ में हुए बदलावों का लॉग

इस रिलीज़ में, कंपैटबिलिटी डेफ़िनिशन में किए गए बदलावों की खास जानकारी के लिए:

दस्तावेज़ में किए गए बदलावों की जानकारी

व्यक्तियों से जुड़े सेक्शन में हुए बदलावों की खास जानकारी के लिए:

12.1. बदलावों का लॉग देखने के बारे में सलाह

बदलावों को इस तरह मार्क किया गया है:

सीडीडी
साथ काम करने से जुड़ी ज़रूरी शर्तों में अहम बदलाव.
दस्तावेज़
कॉस्मेटिक या बिल्ड से जुड़े बदलाव.

बेहतर तरीके से देखने के लिए, अपने बदलाव के लॉग वाले यूआरएल में pretty=full और no-merges यूआरएल पैरामीटर जोड़ें.

13. हमसे संपर्क करें

android-compatibility फ़ोरम में शामिल होकर, साफ़ तौर पर जानकारी माँगी जा सकती है. इसके अलावा, ऐसी कोई भी समस्या बताई जा सकती है जिसके बारे में दस्तावेज़ में जानकारी नहीं दी गई है.