हमारा सुझाव है कि 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 टूल के दस्तावेज़ में दी गई जानकारी के हिसाब से काम करेंगे. अगर कंपैटबिलिटी डेफ़िनिशन या कंपैटबिलिटी टेस्ट सुइट, SDK टूल के दस्तावेज़ से मेल नहीं खाता है, तो SDK टूल के दस्तावेज़ को आधिकारिक माना जाता है. इस दस्तावेज़ में लिंक किए गए संसाधनों में दी गई तकनीकी जानकारी को, इस दस्तावेज़ में शामिल किया गया है. इसे, काम करने के तरीके की परिभाषा का हिस्सा माना जाता है.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

इसमें बैटरी जैसा कोई पावर सोर्स होना चाहिए, ताकि इसे कहीं भी ले जाया जा सके.
डिवाइस की स्क्रीन का डायगनल साइज़ 3.3 इंच (या 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.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] आउटपुट के तौर पर, protobuf ट्रेस की रिपोर्ट देनी चाहिए. यह ट्रेस, Perfetto दस्तावेज़ में बताए गए जीपीयू काउंटर और जीपीयू रेंडरस्टेज के स्कीमा के मुताबिक होना चाहिए.
[7.1.4.6/H-1-2] gpu counter trace packet proto के मुताबिक, डिवाइस के जीपीयू काउंटर के लिए, मानकों के मुताबिक वैल्यू रिपोर्ट करनी ज़रूरी है.
[7.1.4.6/H-1-3] रेंडर स्टेज ट्रेस पैकेट प्रोटो के मुताबिक, डिवाइस के GPU रेंडर स्टेज के लिए, सही वैल्यू रिपोर्ट करना ज़रूरी है.
[7.1.4.6/H-1-4] जीपीयू फ़्रीक्वेंसी के ट्रेसपॉइंट की रिपोर्ट, power/gpu_frequency फ़ॉर्मैट में देनी ज़रूरी है.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[7.8.2.2/H-4-1] अगर यूएसबी ऑडियो टर्मिनल टाइप फ़ील्ड 0x0302 है, तो AudioDeviceInfo.TYPE_USB_HEADSET टाइप का डिवाइस और भूमिका isSink() की सूची ज़रूर होनी चाहिए.
[7.8.2.2/H-4-2] अगर USB ऑडियो टर्मिनल टाइप फ़ील्ड 0x0402 है, तो AudioDeviceInfo.TYPE_USB_HEADSET टाइप का डिवाइस और भूमिका isSink() की सूची ज़रूर होनी चाहिए.
[7.8.2.2/H-4-3] अगर USB ऑडियो टर्मिनल टाइप फ़ील्ड 0x0402 है, तो AudioDeviceInfo.TYPE_USB_HEADSET टाइप का डिवाइस और भूमिका isSource() की सूची देना ज़रूरी है.
[7.8.2.2/H-4-4] अगर यूएसबी ऑडियो टर्मिनल टाइप फ़ील्ड 0x603 है, तो AudioDeviceInfo.TYPE_USB_DEVICE टाइप का डिवाइस और भूमिका isSink() की सूची ज़रूर होनी चाहिए.
[7.8.2.2/H-4-5] अगर USB ऑडियो टर्मिनल टाइप फ़ील्ड 0x604 है, तो AudioDeviceInfo.TYPE_USB_DEVICE टाइप के डिवाइस और भूमिका isSource() की सूची देना ज़रूरी है.
[7.8.2.2/H-4-6] अगर USB ऑडियो टर्मिनल टाइप फ़ील्ड 0x400 है, तो AudioDeviceInfo.TYPE_USB_DEVICE टाइप का डिवाइस और भूमिका isSink() की सूची ज़रूर होनी चाहिए.
[7.8.2.2/H-4-7] अगर USB ऑडियो टर्मिनल टाइप फ़ील्ड 0x400 है, तो AudioDeviceInfo.TYPE_USB_DEVICE टाइप के डिवाइस और भूमिका isSource() की सूची बनाना ज़रूरी है.
[7.8.2.2/H-SR] यूएसबी-सी ऑडियो डिवाइस को कनेक्ट करने पर, यूएसबी डिस्क्रिप्टर की गिनती करने, टर्मिनल टाइप की पहचान करने, और 1,000 मिलीसेकंड से भी कम समय में इंटेंट 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() API के लिए, क्वालिटी की जांच करने का सुझाव दिया जाता है.
[7.10/H-SR]* android.os.Vibrator.hasAmplitudeControl() को चलाकर, ऐम्प्ल्यफ़िकेशन को स्केल करने की सुविधाओं की पुष्टि करने का सुझाव दिया जाता है.

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

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

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

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

[7.10/H-SR]* हमारा सुझाव है कि X-ऐक्सिस LRA की अनुनाद फ़्रीक्वेंसी 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 Profile (AAC+)
[5.1/H-0-5] AAC ELD (कम देरी वाला बेहतर AAC)

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

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

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

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

2.2.3. सॉफ़्टवेयर

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

[3.2.3.1/H-0-1] ऐप्लिकेशन में ऐसा इंटेंट मैनेज करने वाला ऐप्लिकेशन होना चाहिए जो SDK टूल के दस्तावेज़ों में बताए गए ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE, और ACTION_CREATE_DOCUMENT इंटेंट को मैनेज करता हो. साथ ही, DocumentsProvider एपीआई का इस्तेमाल करके, दस्तावेज़ उपलब्ध कराने वाली कंपनी का डेटा ऐक्सेस करने के लिए, उपयोगकर्ता को सुविधाएं देता हो.
[3.2.3.1/H-0-2]* यह ज़रूरी है कि यहां दिए गए ऐप्लिकेशन इंटेंट के हिसाब से तय किए गए सभी सार्वजनिक इंटेंट फ़िल्टर पैटर्न के लिए, इंटेंट हैंडलर के साथ एक या उससे ज़्यादा ऐप्लिकेशन या सेवा कॉम्पोनेंट को पहले से लोड किया जाए.
[3.2.3.1/H-SR] हमारा सुझाव है कि आप ईमेल भेजने के लिए, 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.Action.Builder.setContextual को Notification.Remoteinput.Builder.setChoices से दिखाए गए जवाबों के साथ-साथ true के तौर पर सेट किया गया है.
[3.8.4/H-SR] Assist ऐक्शन को मैनेज करने के लिए, डिवाइस पर किसी असिस्टेंट को लागू करने का सुझाव दिया जाता है.

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

[3.8.4/H-SR] सेक्शन 7.2.3 में बताए गए तरीके के मुताबिक, असिस्ट ऐप्लिकेशन को लॉन्च करने के लिए, HOME बटन को दबाकर रखने का सुझाव दिया जाता है. यह ज़रूरी है कि यह उपयोगकर्ता के चुने गए सहायता ऐप्लिकेशन को लॉन्च करे. दूसरे शब्दों में, वह ऐप्लिकेशन जो 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 के ओपन सोर्स प्रोजेक्ट में दी गई, Switch Access और TalkBack (पहले से इंस्टॉल किए गए Text-to-speech इंजन के साथ काम करने वाली भाषाओं के लिए) की सुविधाओं के बराबर या उससे बेहतर होनी चाहिए.
[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] यूज़र इंटरफ़ेस में लगने वाला समय. डिवाइस में लागू किए गए सिस्टम को, 10 हज़ार सूची की एंट्री को 36 सेकंड से कम समय में स्क्रोल करके, उपयोगकर्ता को कम इंतज़ार वाला अनुभव देना चाहिए. यह समय, Android Compatibility Test Suite (CTS) के मुताबिक तय किया गया है.
[8.1/H-0-3] टास्क स्विच करना. एक से ज़्यादा ऐप्लिकेशन लॉन्च होने पर, पहले से चल रहे ऐप्लिकेशन को फिर से लॉन्च करने में एक सेकंड से कम समय लगना चाहिए.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2.7.1. मीडिया

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

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

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 प्रॉपर्टी के लिए, पीछे के मुख्य कैमरे के लिए 'पूरी' या इससे बेहतर और सामने के मुख्य कैमरे के लिए 'सीमित' या इससे बेहतर वैल्यू होनी चाहिए.
[7.5/H-1-4] ज़रूरी है कि दोनों मुख्य कैमरों के लिए, CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME काम करता हो.
[7.5/H-1-5] 1080p रिज़ॉल्यूशन के लिए, कैमरा2 JPEG कैप्चर में लगने वाला समय 1000 मिलीसेकंड से कम होना चाहिए. यह समय, दोनों मुख्य कैमरों के लिए, कैमरे की परफ़ॉर्मेंस की जांच करने वाले CTS टूल की मदद से, रोशनी की आईटीएस स्थितियों (3000K) में मेज़र किया जाता है.
[7.5/H-1-6] कैमरा चालू होने में लगने वाला समय (कैमरा चालू करने से लेकर, पहले झलक फ़्रेम तक) 600 मिलीसेकंड से कम होना चाहिए. यह समय, दोनों मुख्य कैमरों के लिए, CTS कैमरा परफ़ॉर्मेंस टेस्ट के तहत, रोशनी की आईटीएस स्थितियों (3000K) में मेज़र किया जाता है.

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

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

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

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

2.3.1. हार्डवेयर

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.3.3. सॉफ़्टवेयर

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.4.1. हार्डवेयर

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

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

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

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

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

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

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

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

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

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

2.4.3. सॉफ़्टवेयर

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

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

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

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

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. परफ़ॉर्मेंस और पावर

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

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

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

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

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

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

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

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

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

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

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

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

अगर 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 एमबी होनी चाहिए:
- छोटी/सामान्य स्क्रीन पर 560 डीपीआई या इससे ज़्यादा
- बड़ी स्क्रीन पर 400 डीपीआई या उससे ज़्यादा
- बहुत बड़ी स्क्रीन पर xhdpi या उससे ज़्यादा

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

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

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 (बेहतर कम देरी वाला AAC)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.6.1. हार्डवेयर

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

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

जाइरोस्कोप

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.6.2. सॉफ़्टवेयर

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

3. सॉफ़्टवेयर

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

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

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

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

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

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

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

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

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

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

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

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

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

3.2. Soft API Compatibility

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

3.2.1. अनुमतियां

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.2.3.5. शर्तों के हिसाब से ऐप्लिकेशन इंटेंट

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[C-9-1] SDK के दस्तावेज़ में बताए गए तरीके से, Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI इंटेंट एपीआई लागू करना ज़रूरी है.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.7. रनटाइम के साथ काम करना

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

[C-0-1] यह ज़रूरी है कि यह Dalvik Executable (DEX) फ़ॉर्मैट और Dalvik बाइटकोड स्पेसिफ़िकेशन और सेमेंटेक्स के साथ काम करे.
[C-0-2] Android के अपस्ट्रीम प्लैटफ़ॉर्म के हिसाब से मेमोरी को ऐलोकेट करने के लिए, Dalvik रनटाइम को कॉन्फ़िगर करना ज़रूरी है. साथ ही, यह भी ज़रूरी है कि Dalvik रनटाइम को यहां दी गई टेबल के मुताबिक कॉन्फ़िगर किया जाए. (स्क्रीन साइज़ और स्क्रीन डेंसिटी की परिभाषाओं के लिए, सेक्शन 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 डीपीआई (tvdpi)
	220 डीपीआई (220dpi)	36 एमबी
	240 डीपीआई (एचडीपीआई)
	280 डीपीआई (280dpi)
	320 डीपीआई (xhdpi)	48 एमबी
	360 डीपीआई (360dpi)	48 एमबी
	400 डीपीआई (400dpi)	56 एमबी
	420 डीपीआई (420dpi)	64 एमबी
	480 डीपीआई (xxhdpi)	88 एमबी
	560 डीपीआई (560dpi)	112 एमबी
	640 डीपीआई (xxxhdpi)	154 एमबी
छोटा/सामान्य	120 डीपीआई (ldpi)	32 एमबी
	140 डीपीआई (140dpi)
	160 डीपीआई (एमडीपीआई)
	180 डीपीआई (180dpi)	48 एमबी
	200 डीपीआई (200dpi)
	213 डीपीआई (tvdpi)
	220 डीपीआई (220dpi)
	240 डीपीआई (एचडीपीआई)
	280 डीपीआई (280dpi)
	320 डीपीआई (xhdpi)	80 एमबी
	360 डीपीआई (360dpi)	80 एमबी
	400 डीपीआई (400dpi)	96 एमबी
	420 डीपीआई (420dpi)	112 एमबी
	480 डीपीआई (xxhdpi)	128 एमबी
	560 डीपीआई (560dpi)	192 एमबी
	640 डीपीआई (xxxhdpi)	256 एमबी
बड़ा	120 डीपीआई (ldpi)	32 एमबी
	140 डीपीआई (140dpi)	48 एमबी
	160 डीपीआई (एमडीपीआई)	48 एमबी
	180 डीपीआई (180dpi)	80 एमबी
	200 डीपीआई (200dpi)
	213 डीपीआई (tvdpi)
	220 डीपीआई (220dpi)
	240 डीपीआई (एचडीपीआई)
	280 डीपीआई (280dpi)	96 एमबी
	320 डीपीआई (xhdpi)	128 एमबी
	360 डीपीआई (360dpi)	160 एमबी
	400 डीपीआई (400dpi)	192 एमबी
	420 डीपीआई (420dpi)	228 एमबी
	480 डीपीआई (xxhdpi)	256 एमबी
	560 डीपीआई (560dpi)	384 एमबी
	640 डीपीआई (xxxhdpi)	512 एमबी
xlarge	120 डीपीआई (ldpi)	48 एमबी
	140 डीपीआई (140dpi)	80 एमबी
	160 डीपीआई (एमडीपीआई)	80 एमबी
	180 डीपीआई (180dpi)	96 एमबी
	200 डीपीआई (200dpi)
	213 डीपीआई (tvdpi)
	220 डीपीआई (220dpi)
	240 डीपीआई (एचडीपीआई)
	280 डीपीआई (280dpi)	144 एमबी
	320 डीपीआई (xhdpi)	192 एमबी
	360 डीपीआई (360dpi)	240 एमबी
	400 डीपीआई (400dpi)	288 एमबी
	420 डीपीआई (420dpi)	336 एमबी
	480 डीपीआई (xxhdpi)	384 एमबी
	560 डीपीआई (560dpi)	576 एमबी
	640 डीपीआई (xxxhdpi)	768 एमबी

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.2. विजेट

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

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

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

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

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

3.8.3. सूचनाएं

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

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

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

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

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

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

[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] SDK टूल में बताए गए तरीके के मुताबिक, सूचना के कॉन्टेंट के साथ-साथ Notification.Builder.addAction() की मदद से दी गई कार्रवाइयां भी दिखानी चाहिए. इसके लिए, उपयोगकर्ता से कोई और इंटरैक्शन नहीं करना चाहिए.

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

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

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

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

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

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

3.8.3.3. परेशान न करें

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

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

3.8.4. खोजें

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.6. थीम

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

अगर डिवाइस में 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 APIs SDK के दस्तावेज़ में बताए गए तरीके के मुताबिक, 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 फ़्रेमवर्क के एपीआई के साथ काम करना चाहिए.

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

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

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

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

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

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

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

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

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

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

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

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

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

3.15. Instant Apps

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

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

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

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

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

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

3.18. संपर्क

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

अगर डिवाइस में HEVC वीडियो डिकोडिंग की सुविधा काम करती है, तो: * [C-1-1] उन्हें HEIF (HEIC) इमेज डिकोडिंग की सुविधा काम करनी चाहिए.

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

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

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

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

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

[C-1-1] CodecCapabilities की मदद से, YUV420 8:8:8 फ़्लेक्सिबल कलर फ़ॉर्मैट (COLOR_FormatYUV420Flexible) के साथ काम करना ज़रूरी है.
[SR] इनपुट के लिए, Surface मोड में 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 AVC	ज़्यादा जानकारी के लिए, सेक्शन 5.2 और 5.3 देखें	3GPP (.3gp) MPEG-4 (.mp4) MPEG-2 टीएस (.ts, इसमें वीडियो पर आगे-पीछे नहीं जाया जा सकता) Matroska (.mkv, सिर्फ़ डिकोड करने के लिए)
H.265 HEVC	ज़्यादा जानकारी के लिए, सेक्शन 5.3 देखें	MPEG-4 (.mp4) Matroska (.mkv, सिर्फ़ डिकोड करने के लिए)
MPEG-2	मुख्य प्रोफ़ाइल	MPEG2-TS (.ts, इसमें आगे-पीछे नहीं जाया जा सकता) MPEG-4 (.mp4, सिर्फ़ डिकोड करने के लिए) Matroska (.mkv, सिर्फ़ डिकोड करने के लिए)
MPEG-4 SP		3GPP (.3gp) MPEG-4 (.mp4) Matroska (.mkv, सिर्फ़ डिकोड करने के लिए)
VP8	ज़्यादा जानकारी के लिए, सेक्शन 5.2 और 5.3 देखें	WebM (.webm) Matroska (.mkv)
VP9	ज़्यादा जानकारी के लिए, सेक्शन 5.3 देखें	WebM (.webm) Matroska (.mkv)

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

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

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

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

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

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

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

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

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

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

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

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

खास तौर पर:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.2.3. VP8

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

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

अगर डिवाइस में मीडिया एपीआई की मदद से, 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] प्रोफ़ाइल 0 लेवल 3 के साथ काम करना ज़रूरी है.
[C-1-1] Matroska WebM फ़ाइलें लिखने की सुविधा होनी चाहिए.
[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 APIs की मदद से, प्रोफ़ाइल 2 या प्रोफ़ाइल 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] यह ज़रूरी है कि एक ही स्ट्रीम में, स्टैंडर्ड Android API की मदद से, रीयल टाइम में सभी VP8, VP9, H.264, और H.265 कोडेक के लिए, वीडियो रिज़ॉल्यूशन और फ़्रेम रेट को डाइनैमिक तरीके से स्विच किया जा सके. साथ ही, डिवाइस पर हर कोडेक के लिए, ज़्यादा से ज़्यादा रिज़ॉल्यूशन तक स्विच किया जा सके.

5.3.1. MPEG-2

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

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

5.3.2. H.263

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

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

5.3.3. MPEG-4

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

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

5.3.4. H.264

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

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

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

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

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

5.3.5. H.265 (HEVC)

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

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

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

[C-2-1] डिवाइस में, 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 APIs की मदद से एचडीआर प्रोफ़ाइल काम करने का दावा किया जाता है, तो:

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

5.3.6. VP8

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

[C-1-1] यह ज़रूरी है कि डिवाइस, यहां दी गई टेबल में बताई गई एसडी डिकोडिंग प्रोफ़ाइलों के साथ काम करे.
ऐसे हार्डवेयर 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 FPS (60 FPS^{टेलीविज़न})	30 (60 fps^{टेलीविज़न})
वीडियो बिटरेट	800 केबीपीएस	2 एमबीपीएस	8 एमबीपीएस	20 एमबीपीएस

5.3.7. VP9

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

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

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

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

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

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

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

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

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

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

5.3.8. Dolby Vision

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

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

5.3.9. AV1

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

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

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

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

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

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

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

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

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

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

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

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

5.4.3. प्लेबैक को फिर से शुरू करने के लिए कैप्चर करना

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[C-1-1] यह ज़रूरी है कि रॉ ऑडियो कॉन्टेंट को इन सुविधाओं के साथ चलाया जा सके:
- सोर्स फ़ॉर्मैट: लीनियर PCM, 16-बिट, 8-बिट, फ़्लोट
- चैनल: मोनो, स्टीरियो, ज़्यादा से ज़्यादा आठ चैनलों वाले मान्य मल्टीचैनल कॉन्फ़िगरेशन
- सैंपलिंग रेट (हर्ट्ज़ में):
  - ऊपर दिए गए चैनल कॉन्फ़िगरेशन में, 8000, 11025, 16000, 22050, 32000, 44100, 48000
  - मोनो और स्टीरियो में 96,000
रॉ ऑडियो कॉन्टेंट को इन सुविधाओं के साथ चलाने की अनुमति होनी चाहिए:
- सैंपलिंग रेट: 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 में, PCM से जुड़े OpenSL ES एपीआई का सेट.
AAudio नेटिव ऑडियो एपीआई. Android NDK में मौजूद AAudio एपीआई का सेट.
टाइमस्टैंप. यह एक पेयर होता है, जिसमें स्ट्रीम में फ़्रेम की रिलेटिव पोज़िशन और उस फ़्रेम के एंडपॉइंट पर ऑडियो प्रोसेसिंग पाइपलाइन में शामिल होने या उससे बाहर निकलने का अनुमानित समय शामिल होता है. AudioTimestamp भी देखें.
glitch. ऑडियो सिग्नल में कुछ समय के लिए रुकावट आना या सैंपल की गलत वैल्यू दिखना. आम तौर पर, ऐसा आउटपुट के लिए बफ़र में डेटा कम होना, इनपुट के लिए बफ़र में डेटा ज़्यादा होना या डिजिटल या एनालॉग नॉइज़ के किसी अन्य सोर्स की वजह से होता है.

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

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

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

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

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

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

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

[C-2-1] ज़रूरी है कि कम इंतज़ार वाले ऑडियो के लिए, काम करने की जानकारी न दी जाए.

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

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

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

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

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

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

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

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

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

सेगमेंट फ़ॉर्मैट	रेफ़रंस	ज़रूरी कोडेक के साथ काम करना
MPEG-2 ट्रांसपोर्ट स्ट्रीम	ISO 13818	वीडियो कोडेक: H264 AVC 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	AAC और इसके वैरिएंट के बारे में जानकारी के लिए, सेक्शन 5.1.1 देखें
WebVTT	WebVTT

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

रेफ़रंस

ज़रूरी कोडेक के साथ काम करना

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

ISO 13818

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

H264 AVC
MPEG-4 SP
MPEG-2

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

ऑडियो कोडेक:

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

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

ISO 13818-7

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

WebVTT

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

प्रोफ़ाइल नाम	रेफ़रंस	ज़रूरी कोडेक के साथ काम करना
H264 AVC	RFC 6184	H264 AVC के बारे में जानकारी के लिए, सेक्शन 5.1.3 देखें
MP4A-LATM	RFC 6416	AAC और इसके वैरिएंट के बारे में जानकारी के लिए, सेक्शन 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	AMR-NB के बारे में जानकारी के लिए, सेक्शन 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	AAC और इसके वैरिएंट के बारे में जानकारी के लिए, सेक्शन 5.1.1 देखें
MP2T	RFC 2250	ज़्यादा जानकारी के लिए, एचटीटीपी लाइव स्ट्रीमिंग के नीचे एमपीईजी-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] एमआईडीआई की सुविधा वाले सभी हार्डवेयर ट्रांसपोर्ट पर एमआईडीआई की सुविधा काम करनी चाहिए. इसके लिए, वे सामान्य गैर-एमआईडीआई कनेक्टिविटी उपलब्ध कराते हैं. ये ट्रांसपोर्ट ये हैं:
- यूएसबी होस्ट मोड, सेक्शन 7.7
- ब्लूटूथ LE पर MIDI, मुख्य भूमिका में काम कर रहा है, सेक्शन 7.4.3
[C-1-2] ऐप्लिकेशन के बीच एमआईडीआई सॉफ़्टवेयर ट्रांसपोर्ट (वर्चुअल एमआईडीआई डिवाइस) की सुविधा काम करती हो
[C-1-3] इसमें libamidi.so (नेटिव MIDI सपोर्ट) शामिल होना चाहिए
यूएसबी के सहायक डिवाइस मोड पर MIDI काम करना चाहिए, सेक्शन 7.7

5.10. प्रोफ़ेशनल ऑडियो

अगर डिवाइस में android.content.pm.PackageManager क्लास की मदद से, android.hardware.audio.pro सुविधा के काम करने की जानकारी दी गई है, तो:

[C-1-1] android.hardware.audio.low_latency सुविधा के साथ काम करने की जानकारी देना ज़रूरी है.
[C-1-2] सेक्शन 5.6 ऑडियो लेटेंसी में बताए गए तरीके से, ऑडियो के लिए लगातार राउंड-ट्रिप लेटेंसी होना ज़रूरी है. यह 20 मिलीसेकंड या उससे कम होना चाहिए. साथ ही, कम से कम एक काम करने वाले पाथ पर 10 मिलीसेकंड या उससे कम होना चाहिए.
[C-1-3] इसमें यूएसबी होस्ट मोड और यूएसबी पेरिफ़रल मोड के साथ काम करने वाला यूएसबी पोर्ट होना चाहिए.
[C-1-4] android.software.midi सुविधा के साथ काम करने की जानकारी देना ज़रूरी है.
[C-1-5] OpenSL ES PCM बफ़र क्यू एपीआई और AAudio नेटिव ऑडियो एपीआई के कम से कम एक पाथ का इस्तेमाल करके, इंतज़ार के समय और यूएसबी ऑडियो की ज़रूरी शर्तों को पूरा करना ज़रूरी है.
[SR] एमएमएपी पाथ पर AAudio नेटिव ऑडियो एपीआई का इस्तेमाल करके, इंतज़ार के समय और यूएसबी ऑडियो की ज़रूरी शर्तों को पूरा करने का सुझाव दिया जाता है.
[C-1-6] कोल्ड आउटपुट में लगने वाला समय 200 मिलीसेकंड या उससे कम होना चाहिए.
[C-1-7] कोल्ड इनपुट लेटेंसी 200 मिलीसेकंड या उससे कम होनी चाहिए.
[SR] हमारा सुझाव है कि ऑडियो चालू होने और सीपीयू लोड में बदलाव होने के दौरान, सीपीयू की परफ़ॉर्मेंस में कोई बदलाव न हो. इसकी जांच, SynthMark के कमिट आईडी 09b13c6f49ea089f8c31e5d035f912cc405b7ab8 वाले Android ऐप्लिकेशन वर्शन का इस्तेमाल करके की जानी चाहिए. SynthMark, सिस्टम की परफ़ॉर्मेंस का आकलन करने के लिए, सिम्युलेट किए गए ऑडियो फ़्रेमवर्क पर चलने वाले सॉफ़्टवेयर सिंथेसाइज़र का इस्तेमाल करता है. SynthMark ऐप्लिकेशन को “ऑटोमेटेड टेस्ट” विकल्प का इस्तेमाल करके चलाया जाना चाहिए. साथ ही, आपको ये नतीजे मिलेंगे:
- voicemark.90 >= 32 voices
- latencymark.fixed.little <= 15 msec
- latencymark.dynamic.little <= 50 msec

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

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

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

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

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

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

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

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

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

कम से कम एक कॉन्फ़िगरेशन में, 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 dB.
[C-1-4] ऐम्प्ल्यट्यूड लेवल, हाई फ़्रीक्वेंसी रेंज में होने चाहिए: खास तौर पर, प्रोसेस नहीं किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन के लिए, मिड-फ़्रीक्वेंसी रेंज की तुलना में 7,000 हर्ट्ज से 22 किलोहर्ट्ज तक ±30 dB.
[C-1-5] ऑडियो इनपुट सेंसिटिविटी को इस तरह सेट करना ज़रूरी है कि 94 dB साउंड प्रेशर लेवल (एसपीएल) पर चलाया गया 1,000 हर्ट्ज़ का साइनसोइडल टोन सोर्स, 16-बिट सैंपल के लिए 520 आरएमएस (या फ़्लोटिंग पॉइंट/डबल प्रिसीज़न सैंपल के लिए -36 डीबी फ़ुल स्केल) का रिस्पॉन्स दे. यह रिस्पॉन्स, बिना प्रोसेस किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन के लिए होना चाहिए.
[C-1-6] बिना प्रोसेस किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए जाने वाले हर माइक्रोफ़ोन का सिग्नल-टू-नॉइज़ रेशियो (एसएनआर) 60 dB या उससे ज़्यादा होना चाहिए. (जबकि एसएनआर को 94 डीबी एसपीएल और A-वज़्ड के हिसाब से, सेल्फ़ नॉइज़ के बराबर एसपीएल के बीच के अंतर के तौर पर मेज़र किया जाता है).
[C-1-7] बिना प्रोसेस किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन में, 90 dB एसपीएल इनपुट लेवल पर 1 किलोहर्ट्ज के लिए, टोटल हार्मोनिक डिस्टॉर्शन (टीएचडी) 1% से कम होना चाहिए.
लेवल को सही रेंज में लाने के लिए, पाथ में लेवल मल्टीप्लायर के अलावा कोई अन्य सिग्नल प्रोसेसिंग (जैसे, ऑटोमैटिक गेन कंट्रोल, हाई पास फ़िल्टर या गूंज हटाने की सुविधा) नहीं होनी चाहिए. दूसरे शब्दों में:
[C-1-8] अगर किसी वजह से आर्किटेक्चर में कोई सिग्नल प्रोसेसिंग मौजूद है, तो उसे बंद कर देना चाहिए. साथ ही, सिग्नल पाथ में कोई देरी या अतिरिक्त इंतज़ार का समय नहीं होना चाहिए.
[C-1-9] लेवल मल्टीप्लायर को पाथ पर इस्तेमाल करने की अनुमति है. हालांकि, यह सिग्नल पाथ में देरी या लैटेंसी नहीं ला सकता.

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

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

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

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

6.1. डेवलपर टूल

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

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

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

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

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

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

7. हार्डवेयर के साथ काम करना

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

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

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

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

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

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

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

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

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

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

7.1.1.1. स्क्रीन का साइज़ और आकार

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

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

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

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

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

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

[C-2-1] Window Manager Jetpack लाइब्रेरी का इस्तेमाल करने के लिए, extensions API का सबसे नया वर्शन या sidecar API का स्टेबल वर्शन लागू करना ज़रूरी है.

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

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

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

7.1.1.2. स्क्रीन का आसपेक्ट रेशियो

Android के साथ काम करने वाले डिसप्ले के लिए, फ़िज़िकल डिसप्ले के आसपेक्ट रेशियो पर कोई पाबंदी नहीं है. हालांकि, तीसरे पक्ष के ऐप्लिकेशन रेंडर किए जाने वाले लॉजिकल डिसप्ले के आसपेक्ट रेशियो को इन ज़रूरी शर्तों को पूरा करना होगा. यह आसपेक्ट रेशियो, view.Display एपीआई और कॉन्फ़िगरेशन एपीआई के ज़रिए दी गई ऊंचाई और चौड़ाई की वैल्यू से पता चलता है:

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

7.1.1.3. स्क्रीन की सघनता

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

[C-0-1] डिवाइस में डिफ़ॉल्ट रूप से, DENSITY_DEVICE_STABLE एपीआई की मदद से DisplayMetrics पर मौजूद Android फ़्रेमवर्क के डेंसिटी में से सिर्फ़ एक की जानकारी दी जानी चाहिए. यह वैल्यू कभी नहीं बदलनी चाहिए. हालांकि, डिवाइस में डिफ़ॉल्ट रूप से लोड होने के बाद, उपयोगकर्ता के डिसप्ले कॉन्फ़िगरेशन में किए गए बदलावों (उदाहरण के लिए, डिसप्ले साइज़) के हिसाब से, डिवाइस में किसी अन्य डेंसिटी की जानकारी दी जा सकती है.
डिवाइस पर लागू होने वाले Android फ़्रेमवर्क की डेंसिटी, डिवाइस की स्क्रीन की डेंसिटी के हिसाब से होनी चाहिए. हालांकि, ऐसा तब तक नहीं होना चाहिए, जब तक कि लॉजिकल डेंसिटी की वजह से, स्क्रीन का रिपोर्ट किया गया साइज़, काम करने वाले सबसे छोटे साइज़ से कम न हो जाए. अगर Android फ़्रेमवर्क की स्टैंडर्ड सघनता, स्क्रीन के फ़िज़िकल सघनता के सबसे करीब होती है, तो उस स्क्रीन का साइज़, स्क्रीन के सबसे छोटे साइज़ (320 dp की चौड़ाई) से कम होता है. ऐसे में, Android फ़्रेमवर्क की डेंसिटी के हिसाब से, डिवाइस को लागू करने की प्रोसेस के अगले सबसे कम स्टैंडर्ड Android फ़्रेमवर्क की सघनता रिपोर्ट की जानी चाहिए.

अगर डिवाइस के डिसप्ले साइज़ को बदलने का विकल्प है, तो:

[C-1-1] डिसप्ले का साइज़, नेटिव डेंसिटी के 1.5 गुना से ज़्यादा नहीं होना चाहिए. इसके अलावा, स्क्रीन का कम से कम असरदार डाइमेंशन 320dp (रिसॉर्स क्वालीफ़ायर sw320dp के बराबर) से कम नहीं होना चाहिए.
[C-1-2] डिसप्ले साइज़ को नेटिव डेंसिटी के 0.85 गुने से कम नहीं किया जाना चाहिए.
बेहतर इस्तेमाल और फ़ॉन्ट के साइज़ में एक जैसी जानकारी देने के लिए, हमारा सुझाव है कि नेटिव डिसप्ले विकल्पों के लिए, ऊपर बताई गई सीमाओं के मुताबिक स्केलिंग की सुविधा दी जाए
छोटा: 0.85x
डिफ़ॉल्ट: 1x (नेटिव डिसप्ले स्केल)
बड़ा: 1.15x
बड़ा: 1.3x
सबसे बड़ा 1.45x

7.1.2. डिसप्ले मेट्रिक

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

[C-1-1] android.util.DisplayMetrics एपीआई में बताई गई, Android के साथ काम करने वाली सभी डिसप्ले मेट्रिक के लिए सही वैल्यू रिपोर्ट करनी चाहिए.

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

[C-2-1] एमुलेट किए गए डिफ़ॉल्ट 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 एक्सटेंशन पैक के सभी वर्शन के साथ काम करे.

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

[C-5-1] android.hardware.opengles.aep फ़ीचर फ़्लैग के ज़रिए, सहायता की पहचान करना ज़रूरी है.

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

[C-6-1] EGL_ANDROID_front_buffer_auto_refresh एक्सटेंशन के साथ भी काम करना ज़रूरी है.

7.1.4.2 Vulkan

Android में Vulkan का इस्तेमाल किया जा सकता है. यह कम ओवरहेड वाला क्रॉस-प्लैटफ़ॉर्म एपीआई है, जो बेहतर परफ़ॉर्मेंस वाले 3D ग्राफ़िक के लिए इस्तेमाल किया जाता है.

अगर डिवाइस में लागू किए गए सिस्टम, OpenGL ES 3.1 के साथ काम करते हैं, तो:

[SR] हमारा सुझाव है कि आप Vulkan 1.1 के साथ काम करने की सुविधा शामिल करें.

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

इसमें Vulkan 1.1 के साथ काम करने की सुविधा शामिल होनी चाहिए.

Vulkan dEQP टेस्ट को कई टेस्ट सूचियों में बांटा गया है. इनमें से हर सूची में एक तारीख/वर्शन होता है. ये external/deqp/android/cts/main/vk-master-YYYY-MM-DD.txt पर Android सोर्स ट्री में मौजूद हैं. अगर कोई डिवाइस, खुद के बताए गए लेवल पर Vulkan के साथ काम करता है, तो इसका मतलब है कि वह इस लेवल और उससे पहले के सभी टेस्ट की सूचियों में dEQP टेस्ट पास कर सकता है.

अगर डिवाइस में Vulkan 1.0 या इसके बाद के वर्शन का इस्तेमाल किया जा रहा है, तो:

[C-1-1] android.hardware.vulkan.level और android.hardware.vulkan.version फ़ीचर फ़्लैग के साथ, सही पूर्णांक वैल्यू की जानकारी देना ज़रूरी है.
[C-1-2] Vulkan नेटिव एपीआई vkEnumeratePhysicalDevices() के लिए, कम से कम एक VkPhysicalDevice एट्रिब्यूट की वैल्यू देना ज़रूरी है .
[C-1-3] सूची में शामिल हर VkPhysicalDevice के लिए, Vulkan 1.0 एपीआई को पूरी तरह से लागू करना ज़रूरी है.
[C-1-4] ऐप्लिकेशन पैकेज की नेटिव लाइब्रेरी डायरेक्ट्री में, libVkLayer*.so नाम वाली नेटिव लाइब्रेरी में मौजूद लेयर की सूची बनाना ज़रूरी है. इसके लिए, Vulkan नेटिव एपीआई vkEnumerateInstanceLayerProperties() और vkEnumerateDeviceLayerProperties() का इस्तेमाल करें.
[C-1-5] ऐप्लिकेशन पैकेज के बाहर मौजूद लाइब्रेरी से मिलने वाली लेयर की जानकारी नहीं दी जानी चाहिए. इसके अलावा, Vulkan API को ट्रैक करने या उसे इंटरसेप्ट करने के अन्य तरीके भी नहीं दिए जाने चाहिए. ऐसा तब तक नहीं किया जाना चाहिए, जब तक ऐप्लिकेशन में android:debuggable एट्रिब्यूट को true के तौर पर सेट न किया गया हो.
[C-1-6] ऐप्लिकेशन को उन सभी एक्सटेंशन स्ट्रिंग की जानकारी देनी होगी जो Vulkan नेटिव एपीआई के ज़रिए काम करती हैं. इसके अलावा , उन एक्सटेंशन स्ट्रिंग की जानकारी नहीं देनी चाहिए जो सही तरीके से काम नहीं करती हैं.
[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] पिक्सल आसपेक्ट रेशियो (PAR) 0.9 से 1.15 के बीच होना चाहिए. इसका मतलब है कि पिक्सल का आसपेक्ट रेशियो, स्क्वेयर (1.0) के आस-पास होना चाहिए. इसमें 10 से 15% तक की गड़बड़ी हो सकती है.

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

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

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

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

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

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

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

7.2.1. कीबोर्ड

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

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

डिवाइस में लागू करने के लिए: * [C-0-1] डिवाइस में ऐसा हार्डवेयर कीबोर्ड नहीं होना चाहिए जो android.content.res.Configuration.keyboard (QWERTY या 12-key) में बताए गए फ़ॉर्मैट में से किसी एक से मेल न खाता हो. * इसमें अन्य सॉफ़्ट कीबोर्ड लागू करने की जानकारी शामिल होनी चाहिए. * इसमें हार्डवेयर कीबोर्ड शामिल हो सकता है.

7.2.2. बिना छुए नेविगेट करने की सुविधा

Android में टच किए बिना नेविगेट करने के लिए, डी-पैड, ट्रैकबॉल, और व्हील की सुविधा शामिल है.

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

[C-0-1] android.content.res.Configuration.navigation के लिए सही वैल्यू देना ज़रूरी है.

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

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

7.2.3. मार्गदर्शक कुंजियां

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

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

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

[C-4-1] अन्य नेविगेशन बटन ऐक्सेस किए जा सकने पर, Assist फ़ंक्शन को एक ही ऐक्शन (जैसे, टैप, डबल-क्लिक या जेस्चर) से ऐक्सेस किया जा सकता है.
[SR] हमारा सुझाव है कि इस इंटरैक्शन के लिए, होम बटन को दबाकर रखने की सुविधा का इस्तेमाल करें.

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

[C-5-1] नेविगेशन बटन, स्क्रीन के उस हिस्से पर होने चाहिए जो ऐप्लिकेशन के लिए उपलब्ध नहीं है. साथ ही, वे ऐप्लिकेशन के लिए उपलब्ध स्क्रीन के हिस्से को छिपाने या उसमें रुकावट डालने वाले नहीं होने चाहिए.
[C-5-2] डिसप्ले का एक हिस्सा, उन ऐप्लिकेशन के लिए उपलब्ध कराना ज़रूरी है जो सेक्शन 7.1.1 में बताई गई ज़रूरी शर्तों को पूरा करते हैं.
[C-5-3] ऐप्लिकेशन को View.setSystemUiVisibility() एपीआई के ज़रिए सेट किए गए फ़्लैग का पालन करना चाहिए, ताकि स्क्रीन का यह खास हिस्सा (जिसे नेविगेशन बार भी कहा जाता है) SDK टूल में बताए गए तरीके से सही तरीके से छिपा रहे.

[C-6-1] WindowInsets#getMandatorySystemGestureInsets() का इस्तेमाल सिर्फ़ होम जेस्चर की पहचान करने वाले एरिया की रिपोर्ट करने के लिए किया जाना चाहिए.
[C-6-2] फ़ोरग्राउंड ऐप्लिकेशन के View#setSystemGestureExclusionRects() से दिए गए एक्सक्लूज़न रेक्ट में शुरू होने वाले, लेकिन WindowInsets#getMandatorySystemGestureInsets() से बाहर के जेस्चर को नेविगेशन फ़ंक्शन के लिए इंटरसेप्ट नहीं किया जाना चाहिए. ऐसा तब तक नहीं किया जाना चाहिए, जब तक एक्सक्लूज़न रेक्ट को View#setSystemGestureExclusionRects() के दस्तावेज़ में बताई गई एक्सक्लूज़न की ज़्यादा से ज़्यादा सीमा के अंदर रखा जाता है.
[C-6-3] अगर फ़ोरग्राउंड ऐप्लिकेशन को पहले MotionEvent.ACTION_DOWN इवेंट भेजा गया था, तो सिस्टम जेस्चर के लिए टच को इंटरसेप्ट करने के बाद, फ़ोरग्राउंड ऐप्लिकेशन को MotionEvent.ACTION_CANCEL इवेंट भेजना ज़रूरी है.
[C-6-4] ऐप्लिकेशन में, उपयोगकर्ता को ऑन-स्क्रीन बटन पर आधारित नेविगेशन पर स्विच करने की सुविधा देनी चाहिए. उदाहरण के लिए, सेटिंग में.
होम फ़ंक्शन को स्क्रीन के मौजूदा ओरिएंटेशन के सबसे निचले किनारे से ऊपर की ओर स्वाइप करके उपलब्ध कराया जाना चाहिए.
हाल ही में इस्तेमाल किए गए ऐप्लिकेशन देखने की सुविधा, होम जेस्चर वाले सेक्शन में, ऊपर की ओर स्वाइप करके रिलीज़ करने से पहले होल्ड करने के तौर पर उपलब्ध होनी चाहिए.
WindowInsets#getMandatorySystemGestureInsets() के अंदर शुरू होने वाले जेस्चर पर, View#setSystemGestureExclusionRects() के ज़रिए फ़ोरग्राउंड ऐप्लिकेशन से मिले एक्सक्लूज़न रेक्ट का असर नहीं पड़ना चाहिए.

अगर स्क्रीन के मौजूदा ओरिएंटेशन के बाएं और दाएं किनारों पर कहीं भी नेविगेशन फ़ंक्शन दिया गया है, तो:

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

7.2.4. टचस्क्रीन इनपुट

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

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

इसमें किसी तरह का पॉइंटर इनपुट सिस्टम (माउस जैसा या टच) होना चाहिए.
यह पूरी तरह से ट्रैक किए गए पॉइंटर के साथ काम करना चाहिए.

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

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

[C-2-1] android.hardware.gamepad फ़ीचर फ़्लैग के बारे में एलान करना ज़रूरी है

बटन	एचआईडी का इस्तेमाल²	Android बटन
A¹	0x09 0x0001	KEYCODE_BUTTON_A (96)
B¹	0x09 0x0002	KEYCODE_BUTTON_B (97)
X¹	0x09 0x0004	KEYCODE_BUTTON_X (99)
Y¹	0x09 0x0005	KEYCODE_BUTTON_Y (100)
D-पैड अप¹ D-पैड डाउन¹	0x01 0x0039³	AXIS_HAT_Y⁴
डी-पैड बाईं ओर1 डी-पैड दाईं ओर¹	0x01 0x0039³	AXIS_HAT_X⁴
लेफ़्ट शोल्डर बटन¹	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
राइट शोल्डर बटन¹	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
लेफ़्ट स्टिक क्लिक¹	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
राइट स्टिक क्लिक¹	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
होम¹	0x0c 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

एक MotionEvent

7.2.7. रिमोट कंट्रोल

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

7.3. सेंसर

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

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

[C-0-1] android.content.pm.PackageManager क्लास के हिसाब से, सेंसर की मौजूदगी या अनुपस्थिति की सटीक जानकारी देना ज़रूरी है.
[C-0-2] यह ज़रूरी है कि SensorManager.getSensorList() और मिलते-जुलते तरीकों से, काम करने वाले सेंसर की सटीक सूची दी जाए.
[C-0-3] अन्य सभी सेंसर एपीआई के लिए, सही तरीके से काम करना चाहिए. उदाहरण के लिए, जब ऐप्लिकेशन, लिसनर रजिस्टर करने की कोशिश करते हैं, तो true या false को सही तरीके से दिखाना चाहिए. साथ ही, जब संबंधित सेंसर मौजूद न हों, तो सेंसर लिसनर को कॉल नहीं करना चाहिए.

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

[C-1-1] Android SDK टूल के दस्तावेज़ में बताए गए हर सेंसर टाइप के लिए, सभी सेंसर मेज़रमेंट की रिपोर्ट देनी ज़रूरी है. इसके लिए, यूनिट के इंटरनैशनल सिस्टम (मेट्रिक) की सही वैल्यू का इस्तेमाल करना होगा.
[C-1-2] सेंसर डेटा को 100 मिलीसेकंड + 2 * sample_time के ज़्यादा से ज़्यादा इंतज़ार के साथ रिपोर्ट करना ज़रूरी है. ऐसा तब करना होगा, जब ऐप्लिकेशन प्रोसेसर चालू हो और सेंसर स्ट्रीम के लिए 0 मिलीसेकंड का अनुरोध किया गया हो. इस समय में, फ़िल्टर करने में लगने वाला समय शामिल नहीं है.
[C-1-3] सेंसर चालू होने के 400 मिलीसेकंड + 2 * sample_time के अंदर, सेंसर के पहले सैंपल की जानकारी देना ज़रूरी है. इस सैंपल के लिए, सटीक होने की वैल्यू 0 हो सकती है.
[C-1-4] Android SDK दस्तावेज़ में बताए गए किसी भी एपीआई को कंटिन्यूअस सेंसर के तौर पर इस्तेमाल करने के लिए, डिवाइस में समय-समय पर डेटा सैंपल उपलब्ध कराने होंगे. इन सैंपल में, जितटर 3% से कम होना चाहिए. जितटर को, लगातार होने वाले इवेंट के बीच रिपोर्ट किए गए टाइमस्टैंप की वैल्यू के अंतर के स्टैंडर्ड डेविएशन के तौर पर परिभाषित किया जाता है.
[C-1-5] यह पक्का करना ज़रूरी है कि सेंसर इवेंट स्ट्रीम, डिवाइस के सीपीयू को निलंबित होने या निलंबित होने के बाद फिर से चालू होने से न रोके.
[C-1-6] Android SDK टूल के दस्तावेज़ में बताए गए तरीके के मुताबिक, इवेंट के समय की जानकारी नैनोसेकंड में देनी ज़रूरी है. इससे, इवेंट के होने का समय पता चलता है. साथ ही, यह जानकारी SystemClock.elapsedRealtimeNano() क्लॉक के साथ सिंक होती है.
[C-SR] टाइमस्टैंप सिंक करने में होने वाली गड़बड़ी 100 मिलीसेकंड से कम होनी चाहिए. साथ ही, यह गड़बड़ी 1 मिलीसेकंड से कम होनी चाहिए.
जब कई सेंसर चालू होते हैं, तो बिजली की खपत, अलग-अलग सेंसर की रिपोर्ट की गई बिजली की खपत के कुल योग से ज़्यादा नहीं होनी चाहिए.

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

[C-1-6] सभी सेंसर के लिए, शून्य से अलग रिज़ॉल्यूशन सेट करना ज़रूरी है. साथ ही, Sensor.getResolution() एपीआई के तरीके से वैल्यू की रिपोर्ट देना ज़रूरी है.

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

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

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

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

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

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

[C-3-1] सेंसर के लिए रिज़ॉल्यूशन को 1 पर सेट करना ज़रूरी है. साथ ही, Sensor.getResolution() एपीआई के तरीके से वैल्यू की रिपोर्ट देना ज़रूरी है.

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

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

अगर डिवाइस में 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 मीटर/सेकंड^ से ज़्यादा न हो. स्टैंडर्ड डेविएशन का हिसाब, हर अक्ष के आधार पर लगाया जाना चाहिए. इसके लिए, कम से कम तीन सेकंड के दौरान इकट्ठा किए गए सैंपल का इस्तेमाल करना चाहिए. सैंपलिंग रेट, ज़्यादा से ज़्यादा होना चाहिए.
[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 एमडब्ल्यू से कम ऊर्जा का इस्तेमाल करता है.

7.3.3. जीपीएस

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

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

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

[C-1-1] LocationManager#requestLocationUpdate के ज़रिए अनुरोध किए जाने पर, जगह की जानकारी के आउटपुट के साथ, कम से कम 1 हर्ट्ज़ की दर से काम करना चाहिए.
[C-1-2] 0.5 एमबीपीएस या इससे ज़्यादा डेटा स्पीड वाले इंटरनेट कनेक्शन से कनेक्ट होने पर, खुले आसमान वाली जगहों (ज़्यादा सिग्नल, कम मल्टीपाथ, एचडीओपी < 2) में 10 सेकंड के अंदर (पहले फ़िक्स में लगने वाला कम समय) जगह की जानकारी का पता लगाना ज़रूरी है. आम तौर पर, इस ज़रूरी शर्त को पूरा करने के लिए, सहायता वाली या अनुमानित जीपीएस/जीएनएसएस तकनीक का इस्तेमाल किया जाता है. इससे जीपीएस/जीएनएसएस लॉक-ऑन समय कम हो जाता है. सहायता वाले डेटा में, रेफ़रंस टाइम, रेफ़रंस लोकेशन, और सैटलाइट एफ़ेमेरिस/क्लॉक शामिल होते हैं.
- [C-1-6] जगह की जानकारी का अनुरोध फिर से शुरू होने पर, खुले आसमान वाली जगहों में पांच सेकंड के अंदर, जगह की जानकारी का पता लगाना ज़रूरी है. यह जानकारी, पिछली बार जगह की जानकारी मिलने के एक घंटे बाद तक की होगी. भले ही, यह अनुरोध डेटा कनेक्शन के बिना और/या डिवाइस बंद करके फिर चालू करने के बाद भेजा गया हो.
जगह की जानकारी का पता लगाने के बाद, खुले आसमान वाली जगहों में, वाहन के रुकने या 1 मीटर प्रति सेकंड स्क्वेयर से कम की स्पीड से चलने पर:
- [C-1-3] कम से कम 95% समय में, वाहन की जगह की जानकारी 20 मीटर के दायरे तक और स्पीड 0.5 मीटर प्रति सेकंड तक का पता लगाना ज़रूरी है.
- [C-1-4] एक ही कॉन्स्टलेशन के कम से कम आठ सैटलाइट को एक साथ ट्रैक और GnssStatus.Callback के ज़रिए रिपोर्ट करना ज़रूरी है.
- अलग-अलग कॉन्स्टलेशन के कम से कम 24 सैटलाइट एक साथ ट्रैक करने चाहिए. जैसे, जीपीएस और Glonass, Beidou, Galileo में से कोई एक.
- [C-SR] आपातकालीन फ़ोन कॉल के दौरान, GNSS Location Provider API के ज़रिए सामान्य जीपीएस/जीएनएसएस जगह की जानकारी के आउटपुट डिलीवर करने का सुझाव दिया जाता है.
- [C-SR] एसबीएएस को छोड़कर, ट्रैक किए गए सभी कॉन्स्टलेशन (इनके बारे में GnssStatus मैसेज में बताया गया है) से जीएनएसएस के मेज़रमेंट की जानकारी देने का सुझाव दिया जाता है.
- [C-SR] एजीसी और जीएनएसएस मेज़रमेंट की फ़्रीक्वेंसी की जानकारी देने का सुझाव दिया जाता है.
- [C-SR] हर जीपीएस/जीएनएसएस की जगह की जानकारी के हिस्से के तौर पर, सभी सटीक अनुमानों के बारे में बताने का सुझाव दिया जाता है. इनमें बियरिंग, स्पीड, और वर्टिकल शामिल हैं.
- [C-SR] हमारा सुझाव है कि जीएनएसएस मेज़रमेंट मिलने के तुरंत बाद उनकी रिपोर्ट दी जाए. भले ही, जीपीएस/जीएनएसएस से कैलकुलेट की गई जगह की जानकारी अब तक न दी गई हो.
- [C-SR] हमारा सुझाव है कि जीएनएसएस के स्यूडोरेंज और स्यूडोरेंज रेट की जानकारी दें. इनकी मदद से, खुले आसमान वाली जगहों में, जगह की जानकारी का पता लगाने के बाद, कम से कम 95% समय में, वाहन की जगह की जानकारी का पता लगाने के लिए, 20 मीटर के दायरे तक 0.2 मीटर प्रति सेकंड की स्पीड और वाहन की जगह की जानकारी का पता लगाने के लिए, 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] हर हर्ट्ज़ (हर हर्ट्ज़ में बदलाव या rad^2 / s) के लिए, वैरिएंस 1e-7 rad^2 / s^2 से ज़्यादा नहीं होना चाहिए. वैरिएंस को सैंपलिंग रेट के हिसाब से बदलने की अनुमति है, लेकिन यह वैल्यू से ज़्यादा नहीं होना चाहिए. दूसरे शब्दों में, अगर 1 हर्ट्ज़ सैंपलिंग रेट पर, जायरो के वैरिएंस को मेज़र किया जाता है, तो यह 1e-7 rad^2/s^2 से ज़्यादा नहीं होना चाहिए.
[SR] जब डिवाइस कमरे के तापमान पर स्थिर हो, तो कैलिब्रेशन में होने वाली गड़बड़ी 0.01 रेडियन/सेकंड से कम होनी चाहिए.
कम से कम 200 हर्ट्ज़ तक के इवेंट रिपोर्ट करने चाहिए.

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

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

[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 होनी चाहिए. यह समुद्र तल पर ~200m के बदलाव में ~1m की सटीक जानकारी के बराबर है.

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] सटीक जानकारी 1 बिट या उससे ज़्यादा होनी चाहिए.

7.3.9. हाई फ़िडेलिटी सेंसर

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

[C-1-1] android.hardware.sensor.hifi_sensors फ़ीचर फ़्लैग के ज़रिए, सुविधा की पहचान करना ज़रूरी है.

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

[C-2-1] TYPE_ACCELEROMETER सेंसर का होना ज़रूरी है, जो:
- यह ज़रूरी है कि मेज़रमेंट रेंज कम से कम -8g से +8g के बीच हो. साथ ही, हमारा सुझाव है कि मेज़रमेंट रेंज कम से कम -16g से +16g के बीच हो.
- इसका मेज़रमेंट रिज़ॉल्यूशन कम से कम 2048 LSB/g होना चाहिए.
- मेज़रमेंट फ़्रीक्वेंसी कम से कम 12.5 हर्ट्ज़ या उससे कम होनी चाहिए.
- मेज़रमेंट की फ़्रीक्वेंसी 400 हर्ट्ज़ या उससे ज़्यादा होनी चाहिए. साथ ही, SensorDirectChannel RATE_VERY_FAST के साथ काम करना चाहिए.
- मेज़रमेंट नॉइज़ 400 μg/√Hz से ज़्यादा नहीं होना चाहिए.
- इस सेंसर के लिए, बिना 'जागने' वाले फ़ॉर्म को लागू करना ज़रूरी है. साथ ही, यह फ़ॉर्म कम से कम 3,000 सेंसर इवेंट को बफ़र करने की सुविधा के साथ होना चाहिए.
- बैचिंग के दौरान, डिवाइस की बिजली की खपत 3 mW से ज़्यादा नहीं होनी चाहिए.
- [C-SR] हमारा सुझाव है कि 3dB मेज़रमेंट बैंडविड्थ, कम से कम 80% नाइक्विस्ट फ़्रीक्वेंसी होनी चाहिए. साथ ही, इस बैंडविड्थ में व्हाइट नॉइज़ स्पेक्ट्रम होना चाहिए.
- कमरे के तापमान पर जांचे गए एक्सेलेरेशन रैंडम वॉक की वैल्यू 30 μg √Hz से कम होनी चाहिए.
- तापमान के हिसाब से, बायस में बदलाव ≤ +/- 1 mg/°C होना चाहिए.
- सबसे अच्छी फ़िट लाइन की गैर-लीनियरिटी 0.5% से कम होनी चाहिए. साथ ही, तापमान के हिसाब से सेंसिटिविटी में होने वाला बदलाव 0.03%/C° से कम होना चाहिए.
- क्रॉस-ऐक्सिस सेंसिटिविटी 2.5 % से कम होनी चाहिए. साथ ही, डिवाइस के ऑपरेशन के तापमान की रेंज में क्रॉस-ऐक्सिस सेंसिटिविटी में 0.2% से कम का अंतर होना चाहिए.
[C-2-2] TYPE_ACCELEROMETER_UNCALIBRATED की क्वालिटी, TYPE_ACCELEROMETER की क्वालिटी जैसी होनी चाहिए.
[C-2-3] TYPE_GYROSCOPE सेंसर होना चाहिए, जो:
- मेज़रमेंट की रेंज कम से कम -1,000 से +1,000 डीपीएस के बीच होनी चाहिए.
- मेज़रमेंट का रिज़ॉल्यूशन कम से कम 16 एलएसबी/डीपीएस होना चाहिए.
- मेज़रमेंट फ़्रीक्वेंसी कम से कम 12.5 हर्ट्ज़ या उससे कम होनी चाहिए.
- मेज़रमेंट की फ़्रीक्वेंसी 400 हर्ट्ज़ या उससे ज़्यादा होनी चाहिए. साथ ही, SensorDirectChannel RATE_VERY_FAST के साथ काम करना चाहिए.
- मेज़रमेंट नॉइज़ 0.014°/s/√Hz से ज़्यादा नहीं होना चाहिए.
- [C-SR] हमारा सुझाव है कि 3dB मेज़रमेंट बैंडविड्थ, कम से कम 80% नाइक्विस्ट फ़्रीक्वेंसी होनी चाहिए. साथ ही, इस बैंडविड्थ में व्हाइट नॉइज़ स्पेक्ट्रम होना चाहिए.
- कमरे के तापमान पर जांचे गए रैंडम वॉक की दर, 0.001 °/s √Hz से कम होनी चाहिए.
- तापमान के हिसाब से, बायस में बदलाव ≤ +/- 0.05 °/ s / °C होना चाहिए.
- तापमान के हिसाब से सेंसिटिविटी में बदलाव ≤ 0.02% / °C होना चाहिए.
- सबसे अच्छी फ़िट लाइन की नॉन-लीनियरिटी 0.2% से कम होनी चाहिए.
- नॉइज़ डेंसिटी 0.007 °/s/√Hz से कम होनी चाहिए.
- डिवाइस के रुकने पर, तापमान के 10 ~ 40 ℃ के बीच होने पर, कैलिब्रेशन में होने वाली गड़बड़ी 0.002 रेडियन/सेकंड से कम होनी चाहिए.
- जी-सेंसिटिविटी 0.1°/s/g से कम होनी चाहिए.
- डिवाइस के ऑपरेशन के तापमान की रेंज में, क्रॉस-ऐक्सिस सेंसिटिविटी 4.0 % से कम और क्रॉस-ऐक्सिस सेंसिटिविटी में बदलाव 0.3% से कम होना चाहिए.
[C-2-4] TYPE_GYROSCOPE_UNCALIBRATED की क्वालिटी की ज़रूरी शर्तें, TYPE_GYROSCOPE की क्वालिटी की ज़रूरी शर्तों जैसी होनी चाहिए.
[C-2-5] TYPE_GEOMAGNETIC_FIELD सेंसर का होना ज़रूरी है, जो:
- ज़रूरी है कि मेज़रमेंट रेंज कम से कम -900 और +900 μT के बीच हो.
- मेज़रमेंट का रिज़ॉल्यूशन कम से कम 5 LSB/uT होना चाहिए.
- मेज़रमेंट फ़्रीक्वेंसी कम से कम 5 हर्ट्ज़ या उससे कम होनी चाहिए.
- मेज़रमेंट की फ़्रीक्वेंसी 50 हर्ट्ज़ या इससे ज़्यादा होनी चाहिए.
- मेज़रमेंट नॉइज़ 0.5 uT से ज़्यादा नहीं होना चाहिए.
[C-2-6] TYPE_MAGNETIC_FIELD_UNCALIBRATED में TYPE_GEOMAGNETIC_FIELD जैसी ही क्वालिटी की ज़रूरी शर्तें होनी चाहिए. इसके अलावा:
- इस सेंसर के लिए, बिना 'जागने' वाले फ़ॉर्म को लागू करना ज़रूरी है. साथ ही, यह फ़ॉर्म कम से कम 600 सेंसर इवेंट को बफ़र करने की सुविधा के साथ होना चाहिए.
- [C-SR] हमारा सुझाव है कि रिपोर्ट रेट 50 हर्ट्ज़ या उससे ज़्यादा होने पर, व्हाइट नॉइज़ स्पेक्ट्रम 1 हर्ट्ज़ से कम से कम 10 हर्ट्ज़ तक होना चाहिए.
[C-2-7] TYPE_PRESSURE सेंसर का होना ज़रूरी है, जो:
- ज़रूरी है कि मेज़रमेंट की रेंज कम से कम 300 और 1100 hPa के बीच हो.
- इसका रिज़ॉल्यूशन कम से कम 80 LSB/hPa होना चाहिए.
- मेज़रमेंट फ़्रीक्वेंसी कम से कम 1 हर्ट्ज़ या उससे कम होनी चाहिए.
- मेज़रमेंट की फ़्रीक्वेंसी 10 हर्ट्ज़ या इससे ज़्यादा होनी चाहिए.
- मेज़रमेंट नॉइज़ 2 Pa/√Hz से ज़्यादा नहीं होना चाहिए.
- इस सेंसर के लिए, बिना डिवाइस को जगाने वाले फ़ॉर्म को लागू करना ज़रूरी है. साथ ही, यह फ़ॉर्म कम से कम 300 सेंसर इवेंट को बफ़र करने की सुविधा के साथ होना चाहिए.
- बैचिंग के दौरान बिजली की खपत 2 mW से ज़्यादा नहीं होनी चाहिए.
[C-2-8] TYPE_GAME_ROTATION_VECTOR सेंसर होना ज़रूरी है.
[C-2-9] TYPE_SIGNIFICANT_MOTION सेंसर होना ज़रूरी है, जो:
- डिवाइस के स्टैटिक होने पर, बिजली की खपत 0.5 mW से ज़्यादा नहीं होनी चाहिए. साथ ही, डिवाइस के मूव होने पर, बिजली की खपत 1.5 mW से ज़्यादा नहीं होनी चाहिए.
[C-2-10] TYPE_STEP_DETECTOR सेंसर होना चाहिए, जो:
- इस सेंसर के लिए, बिना 'जागने' वाले फ़ॉर्म को लागू करना ज़रूरी है. साथ ही, यह फ़ॉर्म कम से कम 100 सेंसर इवेंट को बफ़र करने की सुविधा के साथ होना चाहिए.
- डिवाइस के स्टैटिक होने पर, बिजली की खपत 0.5 mW से ज़्यादा नहीं होनी चाहिए. साथ ही, डिवाइस के मूव होने पर, बिजली की खपत 1.5 mW से ज़्यादा नहीं होनी चाहिए.
- बैचिंग के दौरान बिजली की खपत 4 mW से ज़्यादा नहीं होनी चाहिए.
[C-2-11] TYPE_STEP_COUNTER सेंसर होना चाहिए, जो:
- डिवाइस के स्टैटिक होने पर, बिजली की खपत 0.5 mW से ज़्यादा नहीं होनी चाहिए. साथ ही, डिवाइस के मूव होने पर, बिजली की खपत 1.5 mW से ज़्यादा नहीं होनी चाहिए.
[C-2-12] इसमें TILT_DETECTOR सेंसर होना चाहिए, जो:
- डिवाइस के स्टैटिक होने पर, बिजली की खपत 0.5 mW से ज़्यादा नहीं होनी चाहिए. साथ ही, डिवाइस के मूव होने पर, बिजली की खपत 1.5 mW से ज़्यादा नहीं होनी चाहिए.
[C-2-13] एक ही फ़िज़िकल इवेंट के लिए, एक्सेलेरोमीटर, जायरोस्कोप, और मैग्नेटोमीटर से रिपोर्ट किए गए इवेंट के टाइमस्टैंप में 2.5 मिलीसेकंड से ज़्यादा का अंतर नहीं होना चाहिए. एक ही फ़िज़िकल इवेंट के लिए, एक्सेलेरोमीटर और जायरोस्कोप से रिपोर्ट किए गए इवेंट के टाइमस्टैंप में 0.25 मिलीसेकंड से ज़्यादा का अंतर नहीं होना चाहिए.
[C-2-14] जाइरोस्कोप सेंसर इवेंट के टाइमस्टैंप, कैमरा सबसिस्टम के टाइम बेस के साथ होने चाहिए. साथ ही, इनमें 1 मिलीसेकंड से ज़्यादा की गड़बड़ी नहीं होनी चाहिए.
[C-2-15] ऊपर दिए गए किसी भी फ़िज़िकल सेंसर पर डेटा उपलब्ध होने के पांच मिलीसेकंड के अंदर, ऐप्लिकेशन को सैंपल डिलीवर करना ज़रूरी है.
[C-2-16] डिवाइस के स्टैटिक होने पर, उसकी पावर खपत 0.5 mW से ज़्यादा नहीं होनी चाहिए. साथ ही, डिवाइस के मूव होने पर, उसकी पावर खपत 2.0 mW से ज़्यादा नहीं होनी चाहिए. ऐसा तब होना चाहिए, जब इन सेंसर में से किसी भी कॉम्बिनेशन को चालू किया गया हो:
- SENSOR_TYPE_SIGNIFICANT_MOTION
- SENSOR_TYPE_STEP_DETECTOR
- SENSOR_TYPE_STEP_COUNTER
- SENSOR_TILT_DETECTORS
[C-2-17] इसमें TYPE_PROXIMITY सेंसर हो सकता है. हालांकि, अगर सेंसर मौजूद है, तो कम से कम 100 सेंसर इवेंट का बफ़र होना ज़रूरी है.

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

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

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

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

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

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

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

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

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

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

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

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

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

[C-6-1] इस सेक्शन में बताई गई तीसरी कैटगरी की ज़रूरी शर्तों को पूरा करना ज़रूरी है.
[C-6-2] अगर पुष्टि करने के लिए BIOMETRIC_STRONG की ज़रूरत है या पुष्टि करने के लिए CryptoObject का इस्तेमाल किया जाता है, तो सिर्फ़ क्लास 3 बायोमेट्रिक डेटा का इस्तेमाल करना ज़रूरी है.

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

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

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

[C-2-1] यह ज़रूरी है कि आपने ऊपर बताई गई क्लास 1 की सभी ज़रूरी शर्तें पूरी की हों.
[C-2-2] Android बायोमेट्रिक्स टेस्ट प्रोटोकॉल के हिसाब से, स्पूफ़ और इंपोस्टर स्वीकार करने की दर 20% से ज़्यादा नहीं होनी चाहिए.
[C-2-3] बायोमेट्रिक मैचिंग की प्रोसेस, Android उपयोगकर्ता या कर्नेल स्पेस से बाहर के किसी अलग सेटअप किए गए एनवायरमेंट में की जानी चाहिए. जैसे, ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट (टीईई) या किसी ऐसी चिप पर जिसका अलग सेटअप किया गया एनवायरमेंट से सुरक्षित चैनल हो.
[C-2-4] पहचाने जा सकने वाले सभी डेटा को एन्क्रिप्ट (सुरक्षित) किया जाना चाहिए और क्रिप्टोग्राफ़ी (सुरक्षा से जुड़ी तकनीक) की मदद से उसकी पुष्टि की जानी चाहिए. ऐसा इसलिए, ताकि उसे अलग से चलाए जाने वाले एनवायरमेंट या अलग से चलाए जाने वाले एनवायरमेंट के लिए सुरक्षित चैनल वाले चिप के बाहर न पाया जा सके, न पढ़ा जा सके और न ही उसमें बदलाव किया जा सके. इस बारे में, Android Open Source Project की साइट पर लागू करने के दिशा-निर्देशों में बताया गया है.
[C-2-5] कैमरे पर आधारित बायोमेट्रिक्स के लिए, बायोमेट्रिक ऑथेंटिकेशन या रजिस्टर करने के दौरान:
- कैमरे को ऐसे मोड में चलाना चाहिए जिससे कैमरे के फ़्रेम को आइसोलेटेड एक्ज़ीक्यूशन एनवायरमेंट के बाहर न पढ़ा जा सके या उनमें बदलाव न किया जा सके. इसके अलावा, कैमरे में ऐसा चिप होना चाहिए जो आइसोलेटेड एक्ज़ीक्यूशन एनवायरमेंट के लिए सुरक्षित चैनल उपलब्ध कराता हो.
- आरजीबी सिंगल-कैमरा सलूशन के लिए, कैमरे के फ़्रेम को अलग से चलाए जाने वाले एनवायरमेंट के बाहर पढ़ा जा सकता है. इससे, रजिस्टर करने के लिए झलक देखने जैसे कामों में मदद मिलती है. हालांकि, इन फ़्रेम में बदलाव नहीं किया जा सकता.
[C-2-6] तीसरे पक्ष के ऐप्लिकेशन को, अलग-अलग बायोमेट्रिक डेटा के बीच अंतर करने की अनुमति नहीं दी जानी चाहिए.
[C-2-7] ऐप्लिकेशन प्रोसेसर को, TEE के बाहर, व्यक्तिगत पहचान से जुड़े बायोमेट्रिक डेटा या उससे मिले किसी भी डेटा (जैसे, एम्बेडिंग) को अनक्रिप्ट (सुरक्षित) किए बिना ऐक्सेस करने की अनुमति नहीं दी जानी चाहिए.
[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 बायोमेट्रिक्स टेस्ट प्रोटोकॉल के हिसाब से, स्पूफ़ और इंपोस्टर स्वीकार करने की दर 7% से ज़्यादा नहीं होनी चाहिए.
[C-3-4] हर 72 घंटे या उससे कम समय में, उपयोगकर्ता को सुझाई गई प्राइमरी पुष्टि करने के लिए ज़रूर कहा जाना चाहिए. जैसे, पिन, पैटर्न, पासवर्ड.

7.3.12. पोज़ सेंसर

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

हो सकता है कि यह छह डिग्री ऑफ़ फ़्रीडम वाले पॉज़ सेंसर के साथ काम करे.

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

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

7.3.13. हिंज ऐंगल सेंसर

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

[C-1-1] TYPE_HINGLE_ANGLE को लागू करना और उसकी जानकारी देना ज़रूरी है.
[C-1-2] यह ज़रूरी है कि डिवाइस, 0 से 360 डिग्री के बीच कम से कम दो रीडिंग दिखा सके.
[C-1-3] getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE) के लिए, वॉकीअप सेंसर की जानकारी देना ज़रूरी है.

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

7.4.1.2. Telecom API

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

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

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

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

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

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

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

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

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

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

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

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

7.4.2.1. Wi-Fi Direct

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

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

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

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

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

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

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

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

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

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

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

Wi-Fi Aware के साथ काम करना चाहिए.

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

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

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

[C-2-1] जगह की जानकारी देने वाले डिस्कवरी एपीआई लागू करने ज़रूरी हैं: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm , और onServiceDiscoveredWithinRange.

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

अगर डिवाइस में 802.11 (वाई-फ़ाई) की सुविधा काम करती है, तो:

इसमें Wi-Fi Passpoint के लिए सहायता शामिल होनी चाहिए.

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

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

इसके उलट, अगर डिवाइस में Wi-Fi Passpoint की सुविधा काम नहीं करती है, तो:

[C-2-1] Passpoint से जुड़े WifiManager एपीआई को लागू करने पर, UnsupportedOperationException दिखना चाहिए.

7.4.2.5. वाई-फ़ाई की जगह की जानकारी (वाई-फ़ाई का राउंड ट्रिप टाइम - आरटीटी)

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

इसमें वाई-फ़ाई लोकेशन की सुविधा शामिल होनी चाहिए.

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

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

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

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

इसमें वाई-फ़ाई कीपअलाइव ऑफ़लोड की सुविधा शामिल होनी चाहिए.

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

[C-1-1] SocketKeepAlive एपीआई के साथ काम करना ज़रूरी है.
[C-1-2] यह ज़रूरी है कि वाई-फ़ाई पर कम से कम तीन कीपअलाइव स्लॉट और मोबाइल इंटरनेट पर कम से कम एक कीपअलाइव स्लॉट काम करे.

अगर डिवाइस में वाई-फ़ाई की मदद से, डेटा को ऑफ़लोड करने की सुविधा काम नहीं करती, तो:

[C-2-1] यह ज़रूरी है कि रिस्पॉन्स के तौर पर ERROR_UNSUPPORTED मिले.

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

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

इसमें Wi-Fi Easy Connect (DPP) के लिए सहायता शामिल होनी चाहिए.

[C-1-1] WifiManager#isEasyConnectSupported() का तरीका, true दिखाना चाहिए.

7.4.3. ब्लूटूथ

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

इसमें एडवांस ऑडियो कोडेक और ब्लूटूथ ऑडियो कोडेक (जैसे, LDAC) की सुविधा होनी चाहिए.

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

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

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

[C-1-1] इनमें ब्लूटूथ 4.2 और ब्लूटूथ स्मार्ट डेटा की लंबाई बढ़ाने की सुविधा काम करनी चाहिए.

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

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

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

अगर डिवाइस में ब्लूटूथ स्मार्ट (बीएलई) की सुविधा काम करती है, तो:

[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] डिवाइस जब स्कैनिंग या विज्ञापन दिखाने के लिए BLE का इस्तेमाल कर रहा हो, तब उपयोगकर्ता की निजता को सुरक्षित रखने के लिए, 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.hardware.nfc सुविधा के बारे में android.content.pm.PackageManager.hasSystemFeature() तरीके से बताना ज़रूरी है.
यह ज़रूरी है कि डिवाइस, नीचे दिए गए एनएफ़सी स्टैंडर्ड के ज़रिए एनडीएफ़ई मैसेज को पढ़ और लिख सके:
[C-1-2] यह एनएफ़सी फ़ोरम रीडर/राइटर्स के तौर पर काम कर सके.इसके लिए, यह एनएफ़सी के इन स्टैंडर्ड के मुताबिक होना चाहिए:
- NfcA (ISO14443-3A)
- NfcB (ISO14443-3B)
- NfcF (JIS X 6319-4)
- IsoDep (ISO 14443-4)
- एनएफ़सी फ़ोरम टैग टाइप 1, 2, 3, 4, 5 (एनएफ़सी फ़ोरम के मुताबिक)
[SR] हमारा सुझाव है कि यह ऐप्लिकेशन, एनएफ़सी के इन स्टैंडर्ड का इस्तेमाल करके, एनडीएफ़ई मैसेज के साथ-साथ रॉ डेटा को पढ़ और लिख सके. ध्यान दें कि एनएफ़सी स्टैंडर्ड के लिए, 'इसका सुझाव दिया जाता है' के तौर पर बताया गया है. हालांकि, आने वाले समय में रिलीज़ होने वाले वर्शन के लिए, 'ज़रूरी है' के तौर पर बदलने का प्लान है. इस वर्शन में ये स्टैंडर्ड इस्तेमाल करना ज़रूरी नहीं है. हालांकि, आने वाले वर्शन में ये ज़रूरी होंगे. Android के इस वर्शन पर काम करने वाले मौजूदा और नए डिवाइसों को, इन ज़रूरी शर्तों को पूरा करने का सुझाव दिया जाता है. इससे, उन्हें आने वाले समय में प्लैटफ़ॉर्म के रिलीज़ किए जाने वाले नए वर्शन पर अपग्रेड करने में मदद मिलेगी.
[C-1-13] एनएफ़सी डिस्कवरी मोड में, काम करने वाली सभी टेक्नोलॉजी के लिए पोल करना ज़रूरी है.
डिवाइस के चालू होने पर, स्क्रीन चालू और लॉक-स्क्रीन अनलॉक होने पर, डिवाइस को एनएफ़सी डिस्कवरी मोड में होना चाहिए.
थिनफ़िल्म एनएफ़सी बारकोड वाले प्रॉडक्ट के बारकोड और यूआरएल (अगर कोड में बदला गया है) को पढ़ने में सक्षम होना चाहिए.

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

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

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

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

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

[C-3-1] android.hardware.nfc.hcef सुविधा के कॉन्स्टेंट की जानकारी देना ज़रूरी है.
[C-3-2] Android SDK में बताए गए तरीके से, NfcF कार्ड इम्यूलेशन एपीआई लागू करना ज़रूरी है.

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

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

7.4.5. नेटवर्किंग प्रोटोकॉल और एपीआई

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

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

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

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

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

[C-1-1] यह ज़रूरी है कि वाई-फ़ाई पर, ड्यूअल-स्टैक और सिर्फ़ IPv6 मोड काम करे.

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

[C-2-1] यह ज़रूरी है कि ईथरनेट पर ड्यूअल-स्टैक और सिर्फ़ IPv6 ऑपरेशन काम करे.

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

[C-3-1] यह ज़रूरी है कि मोबाइल नेटवर्क पर IPv6 (सिर्फ़ IPv6 और शायद ड्यूअल-स्टैक) काम करे.

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

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

7.4.5.3. कैप्टिव पोर्टल

कैप्टिव पोर्टल, ऐसे नेटवर्क को कहते हैं जिससे इंटरनेट का ऐक्सेस पाने के लिए साइन इन करना ज़रूरी होता है.

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

[C-1-1] इंटेंट ACTION_CAPTIVE_PORTAL_SIGN_IN को मैनेज करने और सिस्टम एपीआई ConnectivityManager#startCaptivePortalApp(Network, Bundle) को कॉल करके, कैप्टिव पोर्टल लॉगिन पेज दिखाने के लिए, कैप्टिव पोर्टल ऐप्लिकेशन उपलब्ध कराना ज़रूरी है.
[C-1-2] डिवाइस किसी भी तरह के नेटवर्क से कनेक्ट होने पर, कैप्टिव पोर्टल का पता लगाना और कैप्टिव पोर्टल ऐप्लिकेशन के ज़रिए लॉगिन की सुविधा देना ज़रूरी है. इन नेटवर्क में सेल्युलर/मोबाइल नेटवर्क, वाई-फ़ाई, ईथरनेट या ब्लूटूथ शामिल हैं.
[C-1-3] अगर डिवाइस को निजी डीएनएस के स्ट्रिक्ट मोड का इस्तेमाल करने के लिए कॉन्फ़िगर किया गया है, तो कैप्टिव पोर्टल में सादे टेक्स्ट वाले डीएनएस का इस्तेमाल करके लॉग इन करने की सुविधा होनी चाहिए.
[C-1-4] android.net.LinkProperties.getPrivateDnsServerName और android.net.LinkProperties.isPrivateDnsActive के लिए, एसडीके टूल के दस्तावेज़ के मुताबिक एन्क्रिप्ट किए गए डीएनएस का इस्तेमाल करना ज़रूरी है. ऐसा उन सभी नेटवर्क ट्रैफ़िक के लिए करना होगा जो कैप्टिव पोर्टल के साथ साफ़ तौर पर कम्यूनिकेट नहीं कर रहे हैं.
[C-1-5] यह पक्का करना ज़रूरी है कि जब उपयोगकर्ता कैप्टिव पोर्टल में लॉग इन कर रहा हो, तो ऐप्लिकेशन के लिए इस्तेमाल किया जाने वाला डिफ़ॉल्ट नेटवर्क, इंटरनेट ऐक्सेस देने वाला कोई भी उपलब्ध नेटवर्क हो. यह नेटवर्क, ConnectivityManager.getActiveNetwork, ConnectivityManager.registerDefaultNetworkCallback से मिलता है और java.net.Socket जैसे Java नेटवर्किंग एपीआई और connect() जैसे नेटिव एपीआई, डिफ़ॉल्ट रूप से इसका इस्तेमाल करते हैं.

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

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

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

7.4.7. डेटा बचाने की सेटिंग

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

[SR] डेटा बचाने वाला मोड उपलब्ध कराने का सुझाव दिया जाता है.

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

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

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

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

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

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

डिवाइस में सेट किए जाने वाले सिस्टम:

इसमें सामने वाला कैमरा शामिल हो सकता है.

अगर डिवाइस में कम से कम एक सामने वाला कैमरा है, तो:

[C-1-1] फ़ीचर फ़्लैग android.hardware.camera.any और android.hardware.camera.front की जानकारी देना ज़रूरी है.
[C-1-2] इसका रिज़ॉल्यूशन कम से कम VGA (640x480 पिक्सल) होना चाहिए.
[C-1-3] Camera API के लिए, सामने वाले कैमरे को डिफ़ॉल्ट तौर पर इस्तेमाल नहीं किया जाना चाहिए. साथ ही, एपीआई को इस तरह कॉन्फ़िगर नहीं किया जाना चाहिए कि वह सामने वाले कैमरे को पीछे वाले कैमरे के तौर पर इस्तेमाल करे. भले ही, डिवाइस में सिर्फ़ यही कैमरा हो.
[C-1-4] जब मौजूदा ऐप्लिकेशन ने साफ़ तौर पर अनुरोध किया हो कि android.hardware.Camera.setDisplayOrientation() तरीके का इस्तेमाल करके, कैमरे के डिसप्ले को घुमाया जाए, तो कैमरे की झलक को ऐप्लिकेशन के तय किए गए ओरिएंटेशन के हिसाब से, हॉरिज़ॉन्टल तौर पर मिरर किया जाना चाहिए. इसके उलट, अगर मौजूदा ऐप्लिकेशन साफ़ तौर पर यह अनुरोध नहीं करता कि android.hardware.Camera.setDisplayOrientation() तरीके का इस्तेमाल करके, कैमरे के डिसप्ले को घुमाया जाए, तो झलक को डिवाइस के डिफ़ॉल्ट हॉरिज़ॉन्टल ऐक्सिस के साथ मिरर किया जाना चाहिए.
[C-1-5] ऐप्लिकेशन कॉलबैक में भेजी गई फ़ाइनल स्टिल इमेज या वीडियो स्ट्रीम को मिरर नहीं करना चाहिए. इसके अलावा, मीडिया स्टोरेज में सेव की गई इमेज या वीडियो स्ट्रीम को भी मिरर नहीं करना चाहिए.
[C-1-6] पोस्टव्यू में दिखाई गई इमेज को उसी तरह से दिखाना चाहिए जिस तरह से कैमरे की झलक वाली इमेज स्ट्रीम दिखाई जाती है.
इसमें सेक्शन 7.5.1 में बताई गई, पीछे की ओर लगे कैमरों के लिए उपलब्ध सुविधाएं (जैसे, ऑटो-फ़ोकस, फ़्लैश वगैरह) शामिल हो सकती हैं.

अगर डिवाइस को उपयोगकर्ता घुमाने में सक्षम है, जैसे कि एक्सीलरॉमीटर की मदद से अपने-आप घूमना या उपयोगकर्ता के इनपुट से मैन्युअल तरीके से घूमना:

[C-2-1] कैमरे की झलक, डिवाइस के मौजूदा ओरिएंटेशन के हिसाब से हॉरिज़ॉन्टल तौर पर मिरर की जानी चाहिए.

7.5.3. बाहरी कैमरा

डिवाइस में सेट किए जाने वाले सिस्टम:

इसमें किसी ऐसे बाहरी कैमरे के लिए सहायता शामिल हो सकती है जो ज़रूरी नहीं है कि हमेशा कनेक्ट रहे.

अगर डिवाइस में बाहरी कैमरे के इस्तेमाल की सुविधा शामिल है, तो:

[C-1-1] प्लैटफ़ॉर्म के फ़ीचर फ़्लैग android.hardware.camera.external और android.hardware camera.any के बारे में एलान करना ज़रूरी है.
[C-1-2] अगर बाहरी कैमरा यूएसबी होस्ट पोर्ट से कनेक्ट होता है, तो यह ज़रूरी है कि वह यूएसबी वीडियो क्लास (यूवीसी 1.0 या उससे ज़्यादा) के साथ काम करता हो.
[C-1-3] यह ज़रूरी है कि डिवाइस में बाहरी कैमरा डिवाइस कनेक्ट करके, कैमरे के सीटीएस टेस्ट पास किए जाएं. कैमरे की सीटीएस जांच की जानकारी source.android.com पर उपलब्ध है.
अच्छी क्वालिटी वाली बिना कोड वाली स्ट्रीम (जैसे, रॉ या अलग से कंप्रेस की गई पिक्चर स्ट्रीम) को ट्रांसफ़र करने के लिए, MJPEG जैसे वीडियो कंप्रेस करने की सुविधा होनी चाहिए.
एक से ज़्यादा कैमरे इस्तेमाल करने की सुविधा हो सकती है.
कैमरे से वीडियो एन्कोड करने की सुविधा हो सकती है.

अगर कैमरे से वीडियो एन्कोड करने की सुविधा काम करती है, तो:

[C-2-1] डिवाइस पर एक साथ, बिना कोड वाली / एमजेपीईजी स्ट्रीम (QVGA या उससे ज़्यादा रिज़ॉल्यूशन) को ऐक्सेस किया जा सकता है.

7.5.4. Camera API का व्यवहार

Android में कैमरे को ऐक्सेस करने के लिए दो एपीआई पैकेज शामिल हैं. नया android.hardware.camera2 API, ऐप्लिकेशन को कैमरे के लोअर-लेवल कंट्रोल को एक्सपोज़ करता है. इसमें, ज़ीरो-कॉपी बर्स्ट/स्ट्रीमिंग फ़्लो और एक्सपोज़र, गेन, व्हाइट बैलेंस गेन, कलर कन्वर्ज़न, डेनॉइज़िंग, शार्पनिंग वगैरह के हर फ़्रेम कंट्रोल शामिल हैं.

पुराने एपीआई पैकेज,android.hardware.Camera को Android 5.0 में 'इस्तेमाल नहीं किया जा सकता' के तौर पर मार्क किया गया है. हालांकि, यह ऐप्लिकेशन के इस्तेमाल के लिए अब भी उपलब्ध होना चाहिए. Android डिवाइस में सेट किए गए सिस्टम के लिए, यह पक्का करना ज़रूरी है कि एपीआई का इस्तेमाल किया जा सके. इस बारे में इस सेक्शन और Android SDK टूल में बताया गया है.

बंद किए गए android.hardware.Camera क्लास और नए android.hardware.camera2 पैकेज में मौजूद सभी सुविधाओं की परफ़ॉर्मेंस और क्वालिटी, दोनों एपीआई में एक जैसी होनी चाहिए. उदाहरण के लिए, एक जैसी सेटिंग के साथ, ऑटोफ़ोकस की स्पीड और सटीक होने की दर एक जैसी होनी चाहिए. साथ ही, कैप्चर की गई इमेज की क्वालिटी भी एक जैसी होनी चाहिए. दो एपीआई के अलग-अलग सेमेटिक्स पर निर्भर करने वाली सुविधाओं के लिए, तेज़ी या क्वालिटी का मेल खाना ज़रूरी नहीं है. हालांकि, इन सुविधाओं की क्वालिटी और तेज़ी जितनी हो सके उतनी मेल खानी चाहिए.

डिवाइस में कैमरे से जुड़े एपीआई लागू करने के लिए, सभी उपलब्ध कैमरों के लिए, कैमरे के काम करने का यह तरीका लागू करना ज़रूरी है. डिवाइस में सेट किए जाने वाले सिस्टम:

[C-0-1] जब किसी ऐप्लिकेशन ने कभी android.hardware.Camera.Parameters.setPreviewFormat(int) को कॉल न किया हो, तो ऐप्लिकेशन कॉलबैक को दिए गए डेटा की झलक के लिए, android.hardware.PixelFormat.YCbCr_420_SP का इस्तेमाल करना ज़रूरी है.
[C-0-2] जब कोई ऐप्लिकेशन android.hardware.Camera.PreviewCallback इंस्टेंस रजिस्टर करता है और सिस्टम onPreviewFrame() तरीके को कॉल करता है और झलक का फ़ॉर्मैट YCbCr_420_SP होता है, तो onPreviewFrame() में पास किए गए byte[] में मौजूद डेटा, NV21 एन्कोडिंग फ़ॉर्मैट में होना चाहिए. इसका मतलब है कि NV21, डिफ़ॉल्ट तौर पर होना चाहिए.
[C-0-3] android.hardware.Camera के लिए, सामने और पीछे के दोनों कैमरों की झलक दिखाने के लिए, YV12 फ़ॉर्मैट (जैसा कि android.graphics.ImageFormat.YV12 कॉन्स्टेंट से पता चलता है) का इस्तेमाल करना ज़रूरी है. (हार्डवेयर वीडियो एन्कोडर और कैमरा, किसी भी नेटिव पिक्सल फ़ॉर्मैट का इस्तेमाल कर सकते हैं. हालांकि, डिवाइस में YV12 में बदलाव करने की सुविधा होनी चाहिए.)
[C-0-4] android.hardware.camera2 डिवाइसों के लिए, android.media.ImageReader एपीआई की मदद से 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] एक ही दिशा में फ़ोकस करने वाले कई आरजीबी कैमरों वाले डिवाइसों के लिए, हमारा सुझाव है कि आप लॉजिकल कैमरा डिवाइस का इस्तेमाल करें. इस डिवाइस में, उस दिशा में फ़ोकस करने वाले सभी आरजीबी कैमरे, फ़िज़िकल सब-डिवाइस के तौर पर शामिल होते हैं. साथ ही, इस डिवाइस में 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] मीडिया फ़ाइलों में सेव की गई जगह की जानकारी वाले मेटाडेटा को छिपाना ज़रूरी है. जैसे, जीपीएस Exif टैग. ऐसा तब किया जाना चाहिए, जब उन फ़ाइलों को MediaStore से ऐक्सेस किया जा रहा हो. हालांकि, अगर कॉल करने वाले ऐप्लिकेशन के पास ACCESS_MEDIA_LOCATION अनुमति है, तो ऐसा नहीं करना चाहिए.

डिवाइस में सेट किए गए ऐसे सिस्टम, ऊपर दी गई ज़रूरी शर्तें पूरी कर सकते हैं जिनमें इनमें से कोई एक तरीका इस्तेमाल किया गया हो:

उपयोगकर्ता के पास, सिक्योर डिजिटल (एसडी) कार्ड स्लॉट जैसा कोई ऐसा स्टोरेज होना चाहिए जिसे हटाया जा सके.
Android Open Source Project (AOSP) में लागू किए गए इंटरनल (हटाए नहीं जा सकने वाले) स्टोरेज का एक हिस्सा.

अगर डिवाइस में ऊपर बताई गई ज़रूरी शर्तों को पूरा करने के लिए, डिवाइस में मौजूद स्टोरेज का इस्तेमाल किया जाता है, तो:

[C-1-1] स्लॉट में स्टोरेज का कोई माध्यम न होने पर, उपयोगकर्ता को चेतावनी देने के लिए, टॉस्ट या पॉप-अप यूज़र इंटरफ़ेस लागू करना ज़रूरी है.
[C-1-2] इसमें FAT फ़ॉर्मैट वाला स्टोरेज मीडियम (जैसे, एसडी कार्ड) शामिल होना चाहिए. इसके अलावा, खरीदारी के समय बॉक्स और अन्य उपलब्ध कॉन्टेंट पर यह भी दिखना चाहिए कि स्टोरेज मीडियम को अलग से खरीदना होगा.

अगर डिवाइस में ऊपर बताई गई ज़रूरी शर्तों को पूरा करने के लिए, डिवाइस में पहले से मौजूद स्टोरेज का कुछ हिस्सा इस्तेमाल किया जाता है, तो:

संगठन में काम करने वालों के साथ ऐप्लिकेशन शेयर करने की सुविधा के लिए, AOSP के स्टोरेज का इस्तेमाल करना चाहिए.
ऐप्लिकेशन के निजी डेटा के साथ स्टोरेज शेयर कर सकता है.

अगर डिवाइस में यूएसबी पोर्ट है और उसमें यूएसबी पेरिफ़रल मोड की सुविधा है, तो:

[C-3-1] ऐप्लिकेशन के शेयर किए गए स्टोरेज में मौजूद डेटा को होस्ट कंप्यूटर से ऐक्सेस करने का तरीका ज़रूर उपलब्ध कराएं.
Android की मीडिया स्कैनर सेवा और android.provider.MediaStore की मदद से, दोनों स्टोरेज पाथ से कॉन्टेंट को साफ़ तौर पर दिखाना चाहिए.
यूएसबी स्टोरेज का इस्तेमाल किया जा सकता है. हालांकि, इस ज़रूरी शर्त को पूरा करने के लिए, मीडिया ट्रांसफ़र प्रोटोकॉल का इस्तेमाल करना चाहिए.

अगर डिवाइस में यूएसबी पेरिफ़रल मोड वाला यूएसबी पोर्ट है और वह मीडिया ट्रांसफ़र प्रोटोकॉल के साथ काम करता है, तो:

यह Android File Transfer, Android MTP होस्ट के साथ काम करना चाहिए.
यूएसबी डिवाइस क्लास 0x00 की रिपोर्ट करनी चाहिए.
यूएसबी इंटरफ़ेस का नाम 'MTP' होना चाहिए.

7.6.3. एडॉप्टेबल स्टोरेज

अगर डिवाइस, टीवी के बजाय मोबाइल है, तो डिवाइस को लागू करने के लिए:

[SR] हमारा सुझाव है कि आप अपना स्टोरेज, लंबे समय तक काम करने वाली जगह पर सेट अप करें. ऐसा इसलिए, क्योंकि गलती से डिवाइस को अनलिंक करने पर, डेटा मिट सकता है या खराब हो सकता है.

अगर डिवाइस में स्टोरेज के लिए इस्तेमाल होने वाले हटाए जा सकने वाले डिवाइस का पोर्ट, लंबे समय तक एक ही जगह पर रहता है, जैसे कि बैटरी के डिब्बे या सुरक्षा कवर के अंदर, तो डिवाइस को लागू करने के लिए ये तरीके अपनाए जाते हैं:

[SR] अडॉप्ट किए जा सकने वाले स्टोरेज को लागू करने का सुझाव दिया जाता है.

7.7. यूएसबी

अगर डिवाइस में यूएसबी पोर्ट है, तो:

यह ज़रूरी है कि डिवाइस, यूएसबी पेरिफ़रल मोड और यूएसबी होस्ट मोड के साथ काम करता हो.

7.7.1. यूएसबी पेरिफ़रल मोड

अगर डिवाइस में, यूएसबी पोर्ट के साथ-साथ, पेरिफ़रल मोड की सुविधा भी है, तो:

[C-1-1] पोर्ट को ऐसे यूएसबी होस्ट से कनेक्ट किया जा सकता है जिसमें स्टैंडर्ड टाइप-A या टाइप-C यूएसबी पोर्ट हो.
[C-1-2] android.os.Build.SERIAL की मदद से, USB स्टैंडर्ड डिवाइस डिस्क्रिप्टर में iSerialNumber की सही वैल्यू की जानकारी देनी ज़रूरी है.
[C-1-3] टाइप-C रेज़िस्टर स्टैंडर्ड के मुताबिक, 1.5A और 3.0A चार्जर का पता लगाना ज़रूरी है. साथ ही, अगर वे टाइप-C यूएसबी के साथ काम करते हैं, तो विज्ञापन में हुए बदलावों का पता लगाना ज़रूरी है.
[SR] पोर्ट में माइक्रो-बी, माइक्रो-एबी या टाइप-सी यूएसबी फ़ॉर्म फ़ैक्टर का इस्तेमाल किया जाना चाहिए. मौजूदा और नए Android डिवाइसों के लिए, इन ज़रूरी शर्तों को पूरा करने का सुझाव दिया जाता है, ताकि वे आने वाले समय में प्लैटफ़ॉर्म के रिलीज़ किए जाने वाले वर्शन में अपग्रेड किए जा सकें.
[SR] पोर्ट, डिवाइस के नीचे (सामान्य ओरिएंटेशन के हिसाब से) होना चाहिए या सभी ऐप्लिकेशन (होम स्क्रीन के साथ) के लिए, सॉफ़्टवेयर स्क्रीन रोटेशन की सुविधा चालू होनी चाहिए. इससे, डिवाइस को नीचे की ओर पोर्ट के साथ ओरिएंट करने पर, डिसप्ले सही तरीके से दिखेगा. मौजूदा और नए Android डिवाइसों के लिए, इन ज़रूरी शर्तों को पूरा करने का सुझाव दिया जाता है, ताकि वे आने वाले समय में प्लैटफ़ॉर्म के रिलीज़ किए जाने वाले वर्शन में अपग्रेड किए जा सकें.
[SR] यूएसबी बैटरी चार्जिंग स्पेसिफ़िकेशन, रिविज़न 1.2 में बताए गए तरीके के मुताबिक, एचएस चिर्प और ट्रैफ़िक के दौरान 1.5 ए करंट खींचने की सुविधा लागू करनी चाहिए. मौजूदा और नए Android डिवाइसों के लिए, इन ज़रूरी शर्तों को पूरा करने का सुझाव दिया जाता है, ताकि वे आने वाले समय में प्लैटफ़ॉर्म के रिलीज़ किए जाने वाले वर्शन में अपग्रेड किए जा सकें.
[SR] हमारा सुझाव है कि चार्जिंग के ऐसे मालिकाना तरीकों का इस्तेमाल न करें जो Vbus वोल्टेज को डिफ़ॉल्ट लेवल से ज़्यादा कर दें या सिंक/सोर्स की भूमिकाओं में बदलाव कर दें. ऐसा करने पर, यूएसबी पावर डिलीवरी के स्टैंडर्ड तरीकों के साथ काम करने वाले चार्जर या डिवाइसों में इंटरऑपरेबिलिटी से जुड़ी समस्याएं आ सकती हैं. हालांकि, इसे "इसका सुझाव ज़रूर दिया जाता है" के तौर पर बताया गया है, लेकिन आने वाले समय में Android के नए वर्शन में, हो सकता है कि हम सभी टाइप-C डिवाइसों के लिए, स्टैंडर्ड टाइप-C चार्जर के साथ पूरी तरह से काम करने की ज़रूरी शर्त लागू करें.
[SR] हमारा सुझाव है कि टाइप-सी यूएसबी और यूएसबी होस्ट मोड के साथ काम करने वाले डिवाइसों में, डेटा और पावर की भूमिका बदलने के लिए, पावर डिलीवरी की सुविधा का इस्तेमाल करें.
यह ज़रूरी है कि यह डिवाइस, हाई-वोल्टेज चार्जिंग के लिए पावर डिलीवरी की सुविधा के साथ-साथ, डिसप्ले आउट जैसे अन्य मोड के साथ काम करे.
Android SDK टूल के दस्तावेज़ में बताए गए तरीके से, Android Open Accessory (AOA) API और स्पेसिफ़िकेशन को लागू करना चाहिए.

अगर डिवाइस में यूएसबी पोर्ट और AOA स्पेसिफ़िकेशन लागू किया गया है, तो:

[C-2-1] यह ज़रूरी है कि हार्डवेयर की सुविधा android.hardware.usb.accessory के साथ काम करने की जानकारी दी गई हो.
[C-2-2] यूएसबी स्टोरेज क्लास में, यूएसबी स्टोरेज के इंटरफ़ेस की जानकारी iInterface स्ट्रिंग के आखिर में "android" स्ट्रिंग शामिल होनी चाहिए

7.7.2. यूएसबी होस्ट मोड

अगर डिवाइस में होस्ट मोड के साथ काम करने वाला यूएसबी पोर्ट शामिल है, तो:

[C-1-1] Android SDK में बताए गए तरीके से, Android USB होस्ट API को लागू करना ज़रूरी है. साथ ही, हार्डवेयर की सुविधा android.hardware.usb.host के साथ काम करने की जानकारी देना ज़रूरी है.
[C-1-2] ज़रूरी है कि डिवाइस में, स्टैंडर्ड यूएसबी डिवाइसों को कनेक्ट करने की सुविधा हो. इसका मतलब है कि डिवाइस में इनमें से कोई एक सुविधा होनी चाहिए:
- डिवाइस में टाइप-सी पोर्ट होना चाहिए या डिवाइस में मौजूद मालिकाना पोर्ट को स्टैंडर्ड यूएसबी टाइप-सी पोर्ट (यूएसबी टाइप-सी डिवाइस) में बदलने वाली केबल के साथ शिप किया जाना चाहिए.
- डिवाइस में टाइप-A पोर्ट होना चाहिए या डिवाइस में मौजूद मालिकाना पोर्ट को स्टैंडर्ड यूएसबी टाइप-A पोर्ट में बदलने वाली केबल के साथ शिप किया जाना चाहिए.
- डिवाइस में माइक्रो-AB पोर्ट होना चाहिए. साथ ही, डिवाइस के साथ एक ऐसी केबल भी होनी चाहिए जो स्टैंडर्ड टाइप-A पोर्ट के साथ काम करती हो.
[C-1-3] डिवाइस को यूएसबी टाइप-ए या माइक्रो-एबी पोर्ट को टाइप-सी पोर्ट (जगह) में बदलने वाले अडैप्टर के साथ शिप नहीं किया जाना चाहिए.
[C-SR] Android SDK के दस्तावेज़ में बताए गए तरीके से, यूएसबी ऑडियो क्लास को लागू करने का सुझाव दिया जाता है.
होस्ट मोड में, कनेक्ट किए गए यूएसबी डिवाइस को चार्ज करने की सुविधा होनी चाहिए. साथ ही, यूएसबी टाइप-सी कनेक्टर के लिए, यूएसबी टाइप-सी केबल और कनेक्टर स्पेसिफ़िकेशन रिविज़न 1.2 के टर्मिनेशन पैरामीटर सेक्शन में बताए गए मुताबिक, सोर्स करंट कम से कम 1.5 ऐंपियर होना चाहिए. इसके अलावा, माइक्रो-एबी कनेक्टर के लिए, यूएसबी बैटरी चार्जिंग स्पेसिफ़िकेशन, रिविज़न 1.2 में बताए गए मुताबिक, चार्जिंग डाउनस्ट्रीम पोर्ट(सीडीपी) आउटपुट करंट की रेंज का इस्तेमाल किया जाना चाहिए.
यूएसबी टाइप-सी स्टैंडर्ड को लागू करना चाहिए और उनका इस्तेमाल करना चाहिए.

अगर डिवाइस में होस्ट मोड और यूएसबी ऑडियो क्लास के साथ काम करने वाला यूएसबी पोर्ट शामिल है, तो:

[C-2-1] यूएसबी एचआईडी क्लास के साथ काम करना ज़रूरी है.
[C-2-2] यह ज़रूरी है कि डिवाइस, यूएसबी एचआईडी के इस्तेमाल की टेबल में बताए गए एचआईडी डेटा फ़ील्ड का पता लगा सके और उन्हें KeyEvent के कॉन्स्टेंट से मैप कर सके. साथ ही, वॉइस कमांड के इस्तेमाल के अनुरोध को भी मैप कर सके. इन फ़ील्ड के बारे में यहां बताया गया है:
- इस्तेमाल का पेज (0xC) इस्तेमाल का आईडी (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
- इस्तेमाल का पेज (0xC) इस्तेमाल का आईडी (0x0E9): KEYCODE_VOLUME_UP
- इस्तेमाल का पेज (0xC) इस्तेमाल का आईडी (0x0EA): KEYCODE_VOLUME_DOWN
- इस्तेमाल का पेज (0xC) इस्तेमाल का आईडी (0x0CF): KEYCODE_VOICE_ASSIST

अगर डिवाइस में होस्ट मोड और स्टोरेज ऐक्सेस फ़्रेमवर्क (SAF) के साथ काम करने वाला यूएसबी पोर्ट शामिल है, तो:

[C-3-1] यह ज़रूरी है कि ऐप्लिकेशन, रिमोट तौर पर कनेक्ट किए गए किसी भी MTP (मीडिया ट्रांसफ़र प्रोटोकॉल) डिवाइस को पहचाने और उसके कॉन्टेंट को ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, और ACTION_CREATE_DOCUMENT इंटेंट की मदद से ऐक्सेस करने की सुविधा दे. .

अगर डिवाइस में होस्ट मोड और यूएसबी टाइप-सी के साथ काम करने वाला यूएसबी पोर्ट शामिल है, तो:

[C-4-1] यूएसबी टाइप-सी स्पेसिफ़िकेशन (सेक्शन 4.5.1.3.3) में बताए गए तरीके के मुताबिक, ड्यूअल रोल पोर्ट की सुविधा लागू करना ज़रूरी है.
[SR] यह सुझाव दिया जाता है कि डिवाइस में DisplayPort की सुविधा हो. साथ ही, यह भी ज़रूरी है कि डिवाइस में यूएसबी सुपरस्पीड डेटा रेट की सुविधा हो. साथ ही, यह भी ज़रूरी है कि डिवाइस में डेटा और पावर की भूमिका बदलने के लिए, पावर डिलीवरी की सुविधा हो.
[SR] हमारा सुझाव है कि आप यूएसबी टाइप-सी केबल और कनेक्टर स्पेसिफ़िकेशन रिविज़न 1.2 के ऐपेंडिक्स A में बताए गए तरीके के मुताबिक, ऑडियो अडैप्टर ऐक्सेसरी मोड का इस्तेमाल न करें.
डिवाइस के फ़ॉर्म फ़ैक्टर के हिसाब से, Try.* मॉडल को लागू करना चाहिए. उदाहरण के लिए, हैंडहेल्ड डिवाइस पर Try.SNK मॉडल लागू होना चाहिए.

7.8. ऑडियो

7.8.1. माइक्रोफ़ोन

अगर डिवाइस में माइक्रोफ़ोन शामिल है, तो:

[C-1-1] android.hardware.microphone सुविधा के कॉन्सटेंट की जानकारी देना ज़रूरी है.
[C-1-2] यह सेक्शन 5.4 में बताई गई ऑडियो रिकॉर्डिंग की ज़रूरी शर्तों को पूरा करती हो.
[C-1-3] सेक्शन 5.6 में दी गई, ऑडियो के इंतज़ार से जुड़ी ज़रूरी शर्तों को पूरा करना ज़रूरी है.
[SR] सेक्शन 7.8.3 में बताए गए तरीके से, नियर-अल्ट्रासाउंड रिकॉर्डिंग की सुविधा देने का सुझाव दिया जाता है.

अगर डिवाइस में माइक्रोफ़ोन नहीं है, तो:

[C-2-1] android.hardware.microphone फ़ीचर के कॉन्स्टेंट की जानकारी नहीं दी जानी चाहिए.
[C-2-2] सेक्शन 7 के मुताबिक, ऑडियो रिकॉर्डिंग एपीआई को कम से कम नो-ऑप के तौर पर लागू करना ज़रूरी है.

7.8.2. ऑडियो आउटपुट

अगर डिवाइस में ऑडियो आउटपुट वाले किसी पेरिफ़रल के लिए स्पीकर या ऑडियो/मल्टीमीडिया आउटपुट पोर्ट शामिल है, तो:

[C-1-1] android.hardware.audio.output सुविधा के कॉन्सटेंट की जानकारी देना ज़रूरी है.
[C-1-2] सेक्शन 5.5 में बताई गई, ऑडियो चलाने से जुड़ी ज़रूरी शर्तों को पूरा करना ज़रूरी है.
[C-1-3] सेक्शन 5.6 में दी गई, ऑडियो के इंतज़ार से जुड़ी ज़रूरी शर्तों को पूरा करना ज़रूरी है.
[SR] सेक्शन 7.8.3 में बताए गए तरीके से, नियर-अल्ट्रासाउंड प्लेलबैक की सुविधा देने का सुझाव दिया जाता है.

अगर डिवाइस में स्पीकर या ऑडियो आउटपुट पोर्ट शामिल नहीं है, तो:

[C-2-1] android.hardware.audio.output सुविधा की जानकारी नहीं दी जानी चाहिए.
[C-2-2] ऑडियो आउटपुट से जुड़े एपीआई को कम से कम नो-ऑप के तौर पर लागू करना ज़रूरी है.

इस सेक्शन के लिए, "आउटपुट पोर्ट" एक फ़िज़िकल इंटरफ़ेस है. जैसे, 3.5 मि॰मी॰ ऑडियो जैक, एचडीएमआई या यूएसबी ऑडियो क्लास वाला यूएसबी होस्ट मोड पोर्ट. ब्लूटूथ, वाई-फ़ाई या मोबाइल नेटवर्क जैसे रेडियो-आधारित प्रोटोकॉल पर ऑडियो आउटपुट की सुविधा, "आउटपुट पोर्ट" के तौर पर शामिल नहीं की जा सकती.

7.8.2.1. ऐनालॉग ऑडियो पोर्ट

Android के सभी डिवाइसों पर 3.5 मि॰मी॰ के ऑडियो प्लग का इस्तेमाल करके, हेडसेट और अन्य ऑडियो ऐक्सेसरी के साथ काम करने के लिए, अगर डिवाइस में एक या उससे ज़्यादा एनालॉग ऑडियो पोर्ट शामिल हैं, तो:

[C-SR] हमारा सुझाव है कि कम से कम एक ऑडियो पोर्ट, चार कंडक्टर वाला 3.5 मि॰मी॰ ऑडियो जैक हो.

अगर डिवाइस में चार कंडक्टर वाला 3.5 मि॰मी॰ का ऑडियो जैक है, तो:

[C-1-1] माइक्रोफ़ोन वाले स्टीरियो हेडफ़ोन और स्टीरियो हेडसेट पर ऑडियो चलाने की सुविधा होनी चाहिए.
[C-1-2] ज़रूरी है कि CTIA पिन-आउट ऑर्डर के साथ TRRS ऑडियो प्लग काम करते हों.
[C-1-3] ऑडियो प्लग पर माइक्रोफ़ोन और ग्राउंड कंडक्टर के बीच, इवैलेंट इंपेडेन्स की इन तीन रेंज के लिए, कीकोड का पता लगाना और उन्हें मैप करना ज़रूरी है:
- 70 ओम या उससे कम: KEYCODE_HEADSETHOOK
- 210-290 ओम: KEYCODE_VOLUME_UP
- 360-680 ओम: KEYCODE_VOLUME_DOWN
[C-1-4] प्लग डालने पर, ACTION_HEADSET_PLUG को ट्रिगर करना चाहिए. हालांकि, ऐसा सिर्फ़ तब करना चाहिए, जब प्लग के सभी संपर्क, जैक पर उनके काम के सेगमेंट को छू रहे हों.
[C-1-5] यह 32 ओम स्पीकर इंपेडेन्स पर, कम से कम 150mV ± 10% आउटपुट वोल्टेज को ड्राइव करने में सक्षम होना चाहिए.
[C-1-6] माइक्रोफ़ोन का बायस वोल्टेज 1.8V से 2.9V के बीच होना चाहिए.
[C-1-7] ऑडियो प्लग पर माइक्रोफ़ोन और ग्राउंड कंडक्टर के बीच, इवैलेंट इंपेडेन्स की इस रेंज का पता लगाना और उसे कीकोड से मैप करना ज़रूरी है:
- 110-180 ओम: KEYCODE_VOICE_ASSIST
[C-SR] हमारा सुझाव है कि आप OMTP पिन-आउट ऑर्डर वाले ऑडियो प्लग का इस्तेमाल करें.
[C-SR] माइक्रोफ़ोन वाले स्टीरियो हेडसेट से ऑडियो रिकॉर्ड करने की सुविधा देने का सुझाव दिया जाता है.

अगर डिवाइस में चार कंडक्टर वाला 3.5 मि॰मी॰ का ऑडियो जैक है और माइक्रोफ़ोन काम करता है, तो android.intent.action.HEADSET_PLUG को माइक्रोफ़ोन की वैल्यू 1 के तौर पर सेट करके ब्रॉडकास्ट किया जाता है. ऐसा करने पर:

[C-2-1] यह ज़रूरी है कि प्लग-इन की गई ऑडियो एक्सेसरी पर माइक्रोफ़ोन का पता लगाया जा सके.

7.8.2.2. डिजिटल ऑडियो पोर्ट

यूएसबी-सी कनेक्टर का इस्तेमाल करने वाले हेडसेट और अन्य ऑडियो ऐक्सेसरी के साथ काम करने के लिए, Android यूएसबी हेडसेट स्पेसिफ़िकेशन में बताए गए तरीके के हिसाब से, Android के सभी प्लैटफ़ॉर्म पर (यूएसबी ऑडियो क्लास) लागू करना.

डिवाइस से जुड़ी ज़रूरी शर्तों के बारे में जानने के लिए, सेक्शन 2.2.1 देखें.

7.8.3. नियर-अल्ट्रासाउंड

नियर-अल्ट्रासाउंड ऑडियो, 18.5 किलोहर्ट्ज़ से 20 किलोहर्ट्ज़ बैंड में होता है.

डिवाइस में सेट किए जाने वाले सिस्टम:

AudioManager.getProperty API की मदद से, यह सही तरीके से रिपोर्ट करना ज़रूरी है कि आपके डिवाइस पर नियर-अल्ट्रासाउंड ऑडियो की सुविधा काम करती है या नहीं. इसके लिए, यह तरीका अपनाएं:

अगर PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND "सही" है, तो VOICE_RECOGNITION और UNPROCESSED ऑडियो सोर्स को इन ज़रूरी शर्तों को पूरा करना होगा:

[C-1-1] माइक्रोफ़ोन की औसत पावर रिस्पॉन्स, 18.5 किलोहर्ट्ज़ से 20 किलोहर्ट्ज़ के बैंड में, 2 किलोहर्ट्ज़ के रिस्पॉन्स से 15 dB से ज़्यादा नहीं होनी चाहिए.
[C-1-2] माइक्रोफ़ोन का बिना वेट किया गया सिग्नल-टू-नॉइज़ रेशियो, 18.5 किलोहर्ट्ज़ से 20 किलोहर्ट्ज़ के बीच होना चाहिए. साथ ही, -26 डीबीएफ़एस पर 19 किलोहर्ट्ज़ के टोन के लिए, यह रेशियो 50 डीबी से कम नहीं होना चाहिए.

अगर PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND "सही" है, तो:

[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	खास	जानकारी उपलब्ध नहीं है	1	2
LOW_LATENCY	खास	जानकारी उपलब्ध नहीं है	2	1
LOW_LATENCY	शेयर किया गया	जानकारी उपलब्ध नहीं है	1	2
LOW_LATENCY	शेयर किया गया	जानकारी उपलब्ध नहीं है	2	1
कोई नहीं	शेयर किया गया	48000	1	2
कोई नहीं	शेयर किया गया	48000	2	1
कोई नहीं	शेयर किया गया	44100	1	2
कोई नहीं	शेयर किया गया	44100	2	1
कोई नहीं	शेयर किया गया	16000	1	2
कोई नहीं	शेयर किया गया	16000	2	1

किसी भरोसेमंद स्ट्रीम को 2000 हर्ट्ज साइन के लिए, सिग्नल-टू-नॉइज़ रेशियो (एसएनआर) और टोटल हार्मोनिक डिस्टॉर्शन (टीएचडी) की इन शर्तों को पूरा करना चाहिए.

ट्रांसड्यूसर	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 को लागू करना ज़रूरी है. साथ ही, उपलब्ध ईजीएल एक्सटेंशन की सूची में एक्सटेंशन दिखाना ज़रूरी है.
[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 कम से कम दो हो.
[C-1-7] जीपीयू और डिसप्ले, शेयर किए गए फ़्रंट बफ़र को सिंक कर पाएं. इससे, दो रेंडर कॉन्टेक्स्ट के साथ 60fps पर, वैकल्पिक आंखों से रेंडर किए गए वीआर कॉन्टेंट को बिना किसी फ़ाड़-फाड़ के दिखाया जा सकेगा.
[C-1-9] NDK में बताए गए तरीके के मुताबिक, AHardwareBuffer फ़्लैग AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA, और AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT के लिए सहायता लागू करना ज़रूरी है.
[C-1-10] कम से कम इन फ़ॉर्मैट के लिए, इस्तेमाल के फ़्लैग AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT के किसी भी कॉम्बिनेशन के साथ AHardwareBuffers के लिए सहायता लागू करना ज़रूरी है: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
[C-SR] C-1-10 में बताए गए फ़्लैग और फ़ॉर्मैट के साथ, एक से ज़्यादा लेयर वाले AHardwareBuffers को असाइन करने की सुविधा देने का सुझाव दिया जाता है.
[C-1-11] यह ज़रूरी है कि डिवाइस, H.264 को कम से कम 3840 x 2160 पिक्सल और 30 एफ़पीएस पर डिकोड कर सके. साथ ही, यह भी ज़रूरी है कि डिवाइस, वीडियो को औसतन 40 एमबीपीएस तक कंप्रेस कर सके. यह 30 एफ़पीएस और 10 एमबीपीएस पर 1920 x 1080 पिक्सल के चार इंस्टेंस या 60 एफ़पीएस और 20 एमबीपीएस पर 1920 x 1080 पिक्सल के दो इंस्टेंस के बराबर है.
[C-1-12] यह एचईवीसी और VP9 के साथ काम करना चाहिए. साथ ही, यह कम से कम 1920 x 1080 रिज़ॉल्यूशन वाले वीडियो को 30 एफ़पीएस पर, औसतन 10 एमबीपीएस तक कंप्रेस करके डिकोड कर सकता है. साथ ही, यह 3840 x 2160 रिज़ॉल्यूशन वाले वीडियो को 30 एफ़पीएस-20 एमबीपीएस पर डिकोड कर सकता है. यह 30 एफ़पीएस-5 एमबीपीएस पर, 1920 x 1080 रिज़ॉल्यूशन वाले चार वीडियो के बराबर है.
[C-1-13] यह HardwarePropertiesManager.getDeviceTemperatures एपीआई के साथ काम करना चाहिए और त्वचा के तापमान की सटीक वैल्यू दिखाना चाहिए.
[C-1-14] में एम्बेड की गई स्क्रीन होनी चाहिए और उसका रिज़ॉल्यूशन कम से कम 1920 x 1080 होना चाहिए.
[C-SR] हमारा सुझाव है कि आपके डिसप्ले का रिज़ॉल्यूशन कम से कम 2560 x 1440 हो.
[C-1-15] VR मोड में डिसप्ले कम से कम 60 हर्ट्ज़ पर अपडेट होना चाहिए.
[C-1-17] डिसप्ले में कम-टिकट मोड होना चाहिए, जिसमें टिकट की अवधि 5 मिलीसेकंड से कम हो. टिकट की अवधि का मतलब है कि पिक्सल कितनी देर तक लाइट उत्सर्जित कर रहा है.
[C-1-18] इनमें ब्लूटूथ 4.2 और ब्लूटूथ स्मार्ट डेटा की लंबाई बढ़ाने की सुविधा सेक्शन 7.4.3 काम करना चाहिए.
[C-1-19] यहां दिए गए डिफ़ॉल्ट सेंसर टाइप के लिए, डायरेक्ट चैनल टाइप के साथ काम करना और उसकी सही जानकारी देना ज़रूरी है:
- TYPE_ACCELEROMETER
- TYPE_ACCELEROMETER_UNCALIBRATED
- TYPE_GYROSCOPE
- TYPE_GYROSCOPE_UNCALIBRATED
- TYPE_MAGNETIC_FIELD
- TYPE_MAGNETIC_FIELD_UNCALIBRATED
[C-SR] हमारा सुझाव है कि ऊपर दिए गए सभी डायरेक्ट चैनल टाइप के लिए, TYPE_HARDWARE_BUFFER डायरेक्ट चैनल टाइप का इस्तेमाल करें.
[C-1-21] android.hardware.hifi_sensors के लिए, जाइरोस्कोप, एक्सलरोमीटर, और मैग्नेटोमीटर से जुड़ी ज़रूरी शर्तों को पूरा करना ज़रूरी है. इन शर्तों के बारे में सेक्शन 7.3.9 में बताया गया है.
[C-SR] android.hardware.sensor.hifi_sensors सुविधा काम करनी चाहिए.
[C-1-22] एंड-टू-एंड मोशन से फ़ोटोन के बीच लगने वाला समय 28 मिलीसेकंड से ज़्यादा नहीं होना चाहिए.
[C-SR] हमारा सुझाव है कि एंड-टू-एंड मोशन से फ़ोटोन के बीच लगने वाला समय 20 मिलीसेकंड से ज़्यादा न हो.
[C-1-23] फ़र्स्ट-फ़्रेम रेशियो होना चाहिए. यह रेशियो, ब्लैक से व्हाइट में ट्रांज़िशन के बाद पहले फ़्रेम के पिक्सल की चमक और स्टेडी स्टेटस में व्हाइट पिक्सल की चमक के बीच का अनुपात होता है. यह रेशियो कम से कम 85% होना चाहिए.
[C-SR] हमारा सुझाव है कि पहले फ़्रेम का अनुपात कम से कम 90% हो.
फ़ोरग्राउंड ऐप्लिकेशन के लिए खास कोर उपलब्ध करा सकता है. साथ ही, Process.getExclusiveCores एपीआई के साथ काम करके, टॉप फ़ोरग्राउंड ऐप्लिकेशन के लिए खास तौर पर उपलब्ध सीपीयू कोर की संख्या दिखा सकता है.

अगर एक्सक्लूज़िव कोर काम करता है, तो कोर:

[C-2-1] ऐप्लिकेशन के इस्तेमाल किए गए डिवाइस ड्राइवर को छोड़कर, किसी भी अन्य यूज़रस्पेस प्रोसेस को उस पर चलने की अनुमति नहीं देनी चाहिए. हालांकि, ज़रूरत के हिसाब से कुछ कर्नेल प्रोसेस को चलने की अनुमति दी जा सकती है.

7.10. हैप्टिक

डिवाइस से जुड़ी ज़रूरी शर्तों के बारे में जानने के लिए, सेक्शन 2.2.1 देखें.

7.11. मीडिया की परफ़ॉर्मेंस क्लास

डिवाइस पर लागू किए गए मीडिया की परफ़ॉर्मेंस क्लास, android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS एपीआई से हासिल की जा सकती है. मीडिया परफ़ॉर्मेंस क्लास के लिए ज़रूरी शर्तें, R (वर्शन 30) से शुरू होने वाले हर Android वर्शन के लिए तय की गई हैं. 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 पार्टीशन) पर फ़ाइल ऐक्सेस करने की परफ़ॉर्मेंस को एक जैसा रखने के लिए, एक सामान्य बेसलाइन उपलब्ध कराने से, ऐप्लिकेशन डेवलपर को सही उम्मीद सेट करने में मदद मिलती है. इससे, उन्हें अपने सॉफ़्टवेयर के डिज़ाइन में मदद मिलती है. डिवाइस के टाइप के हिसाब से, डिवाइस में लागू करने के लिए, सेक्शन 2 में बताई गई कुछ ज़रूरी शर्तें पूरी करनी पड़ सकती हैं. ये शर्तें, यहां बताए गए पढ़ने और लिखने के ऑपरेशन के लिए लागू होती हैं:

सीक्वेंशियल राइटिंग की परफ़ॉर्मेंस. इसे मेज़र करने के लिए, 10 एमबी के राइट बफ़र का इस्तेमाल करके 256 एमबी की फ़ाइल लिखी जाती है.
रैंडम राइटिंग की परफ़ॉर्मेंस. इसे मेज़र करने के लिए, 4 केबी के राइट बफ़र का इस्तेमाल करके 256 एमबी की फ़ाइल लिखी जाती है.
सीक्वेंशियल रीड परफ़ॉर्मेंस. इसे 10 एमबी के राइट बफ़र का इस्तेमाल करके, 256 एमबी की फ़ाइल को पढ़कर मेज़र किया जाता है.
रैंडम रीड परफ़ॉर्मेंस. इसे मेज़र करने के लिए, 4 केबी के राइट बफ़र का इस्तेमाल करके 256 एमबी की फ़ाइल को पढ़ा जाता है.

8.3. बैटरी सेव करने वाले मोड

अगर डिवाइस में, AOSP में शामिल डिवाइस की बैटरी मैनेजमेंट को बेहतर बनाने वाली सुविधाएं (जैसे, ऐप्लिकेशन स्टैंडबाय बकेट, Doze) शामिल की गई हैं या ऐसी सुविधाएं जो ऐप्लिकेशन स्टैंडबाय बकेट से ज़्यादा पाबंदियां नहीं लगाती हैं, तो:

[C-1-1] ऐप्लिकेशन के स्टैंडबाय और Doze मोड की ग्लोबल सिस्टम सेटिंग के इस्तेमाल, ट्रिगर करने, रखरखाव, और स्मार्टवॉच को चालू करने के एल्गोरिदम के लिए, AOSP के तरीके से काम करना चाहिए.
[C-1-2] ऐप्लिकेशन के स्टैंडबाय मोड के लिए, हर बकेट में ऐप्लिकेशन के लिए जॉब, अलार्म, और नेटवर्क को कम करने के लिए, ग्लोबल सेटिंग का इस्तेमाल करने के लिए, AOSP के तरीके से अलग नहीं होना चाहिए.
[C-1-3] ऐप्लिकेशन स्टैंडबाय के लिए इस्तेमाल की जाने वाली ऐप्लिकेशन स्टैंडबाय बकेट की संख्या के लिए, AOSP के लागू होने से अलग नहीं होना चाहिए.
[C-1-4] पावर मैनेजमेंट में बताए गए तरीके से, ऐप्लिकेशन की स्टैंडबाय बकेट और Doze मोड को लागू करना ज़रूरी है.
[C-1-5] डिवाइस के पावर सेव मोड में होने पर, PowerManager.isPowerSaveMode() के लिए true दिखाना ज़रूरी है.
[C-SR] हमारा सुझाव है कि आप बैटरी सेवर मोड को चालू और बंद करने के लिए, उपयोगकर्ता को आसानी से ऐक्सेस करने की सुविधा दें.
[C-SR] हमारा सुझाव है कि आप उपयोगकर्ताओं को उन सभी ऐप्लिकेशन को दिखाने की सुविधा दें जिन्हें ऐप्लिकेशन स्टैंडबाय और Doze मोड (बिजली की बचत करने वाला मोड) से छूट मिली है.

अगर डिवाइस में AOSP में शामिल, पावर मैनेजमेंट की सुविधाएं जोड़ी गई हैं और वह एक्सटेंशन, ऐप्लिकेशन के स्टैंडबाय मोड में होने पर उसकी बैटरी खर्च होने की दर से ज़्यादा सख्त पाबंदियां लागू करता है, तो सेक्शन 3.5.1 देखें.

Android डिवाइस में, बिजली बचाने वाले मोड के अलावा, ऐडवांस कॉन्फ़िगरेशन और पावर इंटरफ़ेस (एसीपीआई) के मुताबिक, डिवाइस को स्लीप मोड में भेजने की चार स्थितियों में से किसी एक या सभी को लागू किया जा सकता है.

अगर डिवाइस में S4 पावर स्टेटस को ACPI के मुताबिक लागू किया जाता है, तो:

[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() एपीआई के तरीके से, यह सटीक तौर पर बताना ज़रूरी है कि आपके ऐप्लिकेशन में बेहतर परफ़ॉर्मेंस मोड की सुविधा काम करती है या नहीं.
यह ज़रूरी है कि यह डिवाइस, बेहतर परफ़ॉर्मेंस मोड के साथ काम करता हो.

अगर डिवाइस पर, बेहतर परफ़ॉर्मेंस मोड की सुविधा काम करती है, तो:

[C-1-1] जब ऐप्लिकेशन अनुरोध करता है, तो फ़ोरग्राउंड में मौजूद टॉप ऐप्लिकेशन को कम से कम 30 मिनट तक लगातार अच्छी परफ़ॉर्मेंस देनी चाहिए.
[C-1-2] Window.setSustainedPerformanceMode() एपीआई और उससे जुड़े अन्य एपीआई का पालन करना ज़रूरी है.

अगर डिवाइस में दो या उससे ज़्यादा सीपीयू कोर शामिल हैं, तो:

इसमें कम से कम एक खास कोर होना चाहिए, जिसे फ़ोरग्राउंड में चल रहे मुख्य ऐप्लिकेशन के लिए रिज़र्व किया जा सकता है.

अगर डिवाइस में, सबसे ज़्यादा इस्तेमाल किए जा रहे फ़ोरग्राउंड ऐप्लिकेशन के लिए एक खास कोर को रिज़र्व करने की सुविधा काम करती है, तो:

[C-2-1] Process.getExclusiveCores() एपीआई के तरीके से, खास कोर के आईडी नंबर की जानकारी देनी होगी. इन कोर को टॉप फ़ोरग्राउंड ऐप्लिकेशन रिज़र्व कर सकता है.
[C-2-2] ऐप्लिकेशन के इस्तेमाल किए गए डिवाइस ड्राइवर के अलावा, किसी भी यूज़र स्पेस प्रोसेस को खास कोर पर चलने की अनुमति नहीं देनी चाहिए. हालांकि, ज़रूरत के हिसाब से कुछ कर्नेल प्रोसेस को चलने की अनुमति दी जा सकती है.

अगर डिवाइस पर लागू किए गए वर्शन में किसी खास कोर का इस्तेमाल नहीं किया जा सकता, तो:

[C-3-1] Process.getExclusiveCores() एपीआई के तरीके से, खाली सूची दिखानी ज़रूरी है.

9. सुरक्षा मॉडल के साथ काम करने की सुविधा

डिवाइस में सेट किए जाने वाले सिस्टम:

[C-0-1] Android डेवलपर दस्तावेज़ में एपीआई के सुरक्षा और अनुमतियों के रेफ़रंस दस्तावेज़ में बताए गए तरीके के मुताबिक, Android प्लैटफ़ॉर्म के सुरक्षा मॉडल के हिसाब से सुरक्षा मॉडल लागू करना ज़रूरी है.
[C-0-2] यह ज़रूरी है कि डिवाइस पर, खुद के हस्ताक्षर वाले ऐप्लिकेशन इंस्टॉल किए जा सकें. इसके लिए, किसी तीसरे पक्ष/अधिकारियों से अतिरिक्त अनुमतियों/सर्टिफ़िकेट की ज़रूरत नहीं होनी चाहिए. खास तौर पर, यह ज़रूरी है कि काम करने वाले डिवाइसों में, नीचे दिए गए सब-सेक्शन में बताए गए सुरक्षा तरीके काम करते हों.

9.1. अनुमतियां

डिवाइस में सेट किए जाने वाले सिस्टम:

[C-0-1] यह ज़रूरी है कि यह Android डेवलपर दस्तावेज़ में बताए गए Android अनुमतियों के मॉडल के साथ काम करे. खास तौर पर, उन्हें SDK टूल के दस्तावेज़ में बताई गई हर अनुमति को लागू करना होगा. किसी भी अनुमति को हटाया, बदला या अनदेखा नहीं किया जा सकता.
ज़्यादा अनुमतियां जोड़ी जा सकती हैं. हालांकि, इसके लिए ज़रूरी है कि अनुमति की नई आईडी स्ट्रिंग, android.\* नेमस्पेस में न हों.
[C-0-2] PROTECTION_FLAG_PRIVILEGED के protectionLevel वाली अनुमतियां, सिर्फ़ सिस्टम इमेज के खास पाथ में पहले से इंस्टॉल किए गए ऐप्लिकेशन को दी जानी चाहिए. साथ ही, ये अनुमतियां हर ऐप्लिकेशन के लिए, साफ़ तौर पर अनुमति वाली सूची के सबसेट में होनी चाहिए. AOSP, etc/permissions/ पाथ में मौजूद फ़ाइलों से हर ऐप्लिकेशन के लिए, अनुमति वाली सूची को पढ़कर और उसे लागू करके इस ज़रूरी शर्त को पूरा करता है. साथ ही, system/priv-app पाथ को खास पाथ के तौर पर इस्तेमाल करता है.

सुरक्षा के लेवल के हिसाब से, खतरनाक अनुमतियां रनटाइम अनुमतियां होती हैं. जिन ऐप्लिकेशन में targetSdkVersion > 22 है वे रनटाइम के दौरान इनका अनुरोध करते हैं.

डिवाइस में सेट किए जाने वाले सिस्टम:

[C-0-3] उपयोगकर्ता को एक खास इंटरफ़ेस दिखाना ज़रूरी है, ताकि वह यह तय कर सके कि अनुरोध की गई रनटाइम अनुमतियां देनी हैं या नहीं. साथ ही, उपयोगकर्ता को रनटाइम अनुमतियों को मैनेज करने के लिए भी एक इंटरफ़ेस देना ज़रूरी है.
[C-0-4] दोनों यूज़र इंटरफ़ेस को सिर्फ़ एक बार लागू किया जाना चाहिए.
[C-0-5] पहले से इंस्टॉल किए गए ऐप्लिकेशन को रनटाइम की कोई अनुमति तब तक नहीं देनी चाहिए, जब तक कि:
- ऐप्लिकेशन का इस्तेमाल करने से पहले, उपयोगकर्ता की सहमति ली जा सकती है.
- रनटाइम की अनुमतियां, किसी इंटेंट पैटर्न से जुड़ी होती हैं. इसके लिए, पहले से इंस्टॉल किया गया ऐप्लिकेशन डिफ़ॉल्ट हैंडलर के तौर पर सेट होता है.
[C-0-6] android.permission.RECOVER_KEYSTORE अनुमति सिर्फ़ उन सिस्टम ऐप्लिकेशन को देनी चाहिए जो ठीक से सुरक्षित किए गए रिकवरी एजेंट को रजिस्टर करते हैं. ठीक से सुरक्षित किए गए रिकवरी एजेंट को, डिवाइस पर मौजूद सॉफ़्टवेयर एजेंट के तौर पर परिभाषित किया जाता है. यह डिवाइस से बाहर के रिमोट स्टोरेज के साथ सिंक होता है. यह रिमोट स्टोरेज, Google Cloud Key Vault Service में बताए गए सुरक्षा उपायों के बराबर या उससे ज़्यादा सुरक्षित हार्डवेयर से लैस होता है. इससे लॉकस्क्रीन पर मौजूद, उपयोगकर्ता की पहचान से जुड़े फ़ैक्टर पर ब्रूट-फ़ोर्स अटैक को रोका जा सकता है.

डिवाइस में सेट किए जाने वाले सिस्टम:

[C-0-7] जब कोई ऐप्लिकेशन, स्टैंडर्ड Android API या मालिकाना मशीनरी की मदद से जगह की जानकारी या शारीरिक गतिविधि के डेटा का अनुरोध करता है, तो उसे Android की जगह की जानकारी की अनुमति की प्रॉपर्टी का पालन करना होगा. इस डेटा में ये चीज़ें शामिल हैं. हालांकि, इसमें और भी चीज़ें शामिल हो सकती हैं:
- डिवाइस की जगह की जानकारी (उदाहरण के लिए, अक्षांश और देशांतर).
- ऐसी जानकारी जिसका इस्तेमाल डिवाइस की जगह का पता लगाने या उसका अनुमान लगाने के लिए किया जा सकता है. जैसे, SSID, BSSID, सेल आईडी या उस नेटवर्क की जगह जिससे डिवाइस कनेक्ट है.
- उपयोगकर्ता की शारीरिक गतिविधि या शारीरिक गतिविधि की कैटगरी.

खास तौर पर, डिवाइस में लागू करने के लिए:

[C-0-8] किसी ऐप्लिकेशन को जगह की जानकारी या शारीरिक गतिविधि का डेटा ऐक्सेस करने की अनुमति देने के लिए, उपयोगकर्ता की सहमति लेना ज़रूरी है.
[C-0-9] रनटाइम की अनुमति सिर्फ़ उस ऐप्लिकेशन को देनी चाहिए जिसके पास SDK टूल में बताई गई ज़रूरी अनुमतियां हों. उदाहरण के लिए, TelephonyManager#getServiceState के लिए android.permission.ACCESS_FINE_LOCATION ज़रूरी है.

अनुमतियों के व्यवहार में बदलाव करके, उन्हें 'पाबंदी वाला' के तौर पर मार्क किया जा सकता है.

[C-0-10] hardRestricted फ़्लैग के साथ मार्क की गई अनुमतियां, किसी ऐप्लिकेशन को तब तक नहीं दी जानी चाहिए, जब तक:
- ऐप्लिकेशन की APK फ़ाइल, सिस्टम पार्टीशन में है.
- उपयोगकर्ता, किसी ऐप्लिकेशन को hardRestricted अनुमतियों से जुड़ी भूमिका असाइन करता है.
- इंस्टॉलर, किसी ऐप्लिकेशन को hardRestricted देता है.
- किसी ऐप्लिकेशन को Android के पुराने वर्शन पर hardRestricted दिया गया हो.
[C-0-11] softRestricted अनुमति वाले ऐप्लिकेशन को सिर्फ़ सीमित ऐक्सेस मिलना चाहिए. साथ ही, जब तक SDK टूल में बताए गए तरीके से अनुमति सूची में शामिल नहीं किया जाता, तब तक उसे पूरा ऐक्सेस नहीं मिलना चाहिए. SDK टूल में, हर softRestricted अनुमति (उदाहरण के लिए, READ_EXTERNAL_STORAGE) के लिए, पूरा और सीमित ऐक्सेस तय किया जाता है.

अगर डिवाइस पर, उपयोगकर्ता को यह चुनने का विकल्प मिलता है कि किन ऐप्लिकेशन को ACTION_MANAGE_OVERLAY_PERMISSION इंटेंट को मैनेज करने वाली गतिविधि के साथ, दूसरे ऐप्लिकेशन के ऊपर दिखाया जा सकता है, तो:

[C-2-1] यह पक्का करना ज़रूरी है कि ACTION_MANAGE_OVERLAY_PERMISSION इंटेंट के लिए इंटेंट फ़िल्टर वाली सभी गतिविधियों में एक ही यूज़र इंटरफ़ेस (यूआई) स्क्रीन हो. भले ही, इन गतिविधियों को शुरू करने वाला ऐप्लिकेशन कोई भी हो या वह कोई भी जानकारी उपलब्ध कराता हो.

9.2. यूआईडी और प्रोसेस अलग करना

डिवाइस में सेट किए जाने वाले सिस्टम:

[C-0-1] यह Android ऐप्लिकेशन सैंडबॉक्स मॉडल के साथ काम करना चाहिए. इसमें हर ऐप्लिकेशन, यूनिक्स स्टाइल के यूआईडी के तौर पर और अलग प्रोसेस में चलता है.
[C-0-2] एक ही Linux यूज़र आईडी के तौर पर कई ऐप्लिकेशन चलाने की सुविधा होनी चाहिए. हालांकि, इसके लिए ज़रूरी है कि ऐप्लिकेशन को सही तरीके से साइन किया गया हो और उन्हें सुरक्षा और अनुमतियों के रेफ़रंस में बताए गए तरीके से बनाया गया हो.

9.3. फ़ाइल सिस्टम की अनुमतियां

डिवाइस में सेट किए जाने वाले सिस्टम:

[C-0-1] यह ज़रूरी है कि ऐप्लिकेशन, सुरक्षा और अनुमतियों के रेफ़रंस में बताए गए Android फ़ाइल ऐक्सेस की अनुमतियों वाले मॉडल के साथ काम करता हो.

9.4. एक्ज़ीक्यूशन के लिए अन्य एनवायरमेंट

डिवाइस में लागू किए गए सिस्टम में, Android की सुरक्षा और अनुमति मॉडल की सुविधाएं एक जैसी होनी चाहिए. भले ही, उनमें ऐसे रनटाइम एनवायरमेंट शामिल हों जो Dalvik Executable Format या नेटिव कोड के अलावा किसी अन्य सॉफ़्टवेयर या टेक्नोलॉजी का इस्तेमाल करके ऐप्लिकेशन चलाते हों. दूसरे शब्दों में:

[C-0-1] वैकल्पिक रनटाइम, Android ऐप्लिकेशन होने चाहिए. साथ ही, वे सेक्शन 9 में बताए गए स्टैंडर्ड Android सुरक्षा मॉडल का पालन करने चाहिए.
[C-0-2] अन्य रनटाइम को उन संसाधनों का ऐक्सेस नहीं दिया जाना चाहिए जिन्हें <uses-permission> प्रोसेस के ज़रिए, रनटाइम की AndroidManifest.xml फ़ाइल में अनुरोध नहीं किया गया है.
[C-0-3] अन्य रनटाइम को ऐप्लिकेशन को उन सुविधाओं का इस्तेमाल करने की अनुमति नहीं देनी चाहिए जिन्हें Android की अनुमतियों से सुरक्षित किया गया है और जिनका इस्तेमाल सिर्फ़ सिस्टम ऐप्लिकेशन कर सकते हैं.
[C-0-4] किसी अन्य रनटाइम का इस्तेमाल करने वाले ऐप्लिकेशन को, Android सैंडबॉक्स मॉडल का पालन करना होगा. साथ ही, डिवाइस पर इंस्टॉल किए गए किसी भी अन्य ऐप्लिकेशन के सैंडबॉक्स का दोबारा इस्तेमाल नहीं करना होगा. हालांकि, शेयर किए गए उपयोगकर्ता आईडी और साइनिंग सर्टिफ़िकेट के स्टैंडर्ड Android तरीकों का इस्तेमाल करके, ऐसा किया जा सकता है.
[C-0-5] अन्य रनटाइम, Android के अन्य ऐप्लिकेशन के सैंडबॉक्स के साथ लॉन्च नहीं होने चाहिए, उन्हें सैंडबॉक्स का ऐक्सेस नहीं देना चाहिए, और न ही उन्हें सैंडबॉक्स का ऐक्सेस दिया जाना चाहिए.
[C-0-6] अन्य रनटाइम को सुपरयूज़र (रूट) या किसी अन्य उपयोगकर्ता आईडी की अनुमतियों के साथ लॉन्च नहीं किया जाना चाहिए. साथ ही, उन्हें अन्य ऐप्लिकेशन को भी ये अनुमतियां नहीं देनी चाहिए.
[C-0-7] जब डिवाइस में लागू किए गए सिस्टम की इमेज में, अन्य रनटाइम की .apk फ़ाइलें शामिल की जाती हैं, तो उस पर ऐसी कुंजी से हस्ताक्षर करना ज़रूरी है जो डिवाइस में लागू किए गए अन्य ऐप्लिकेशन पर हस्ताक्षर करने के लिए इस्तेमाल की गई कुंजी से अलग हो.
[C-0-8] ऐप्लिकेशन इंस्टॉल करते समय, अन्य रनटाइम को ऐप्लिकेशन के इस्तेमाल की जाने वाली Android अनुमतियों के लिए, उपयोगकर्ता की सहमति लेनी होगी.
[C-0-9] जब किसी ऐप्लिकेशन को किसी ऐसे डिवाइस संसाधन का इस्तेमाल करना हो जिसके लिए Android की अनुमति (जैसे, कैमरा, जीपीएस वगैरह) हो, तो वैकल्पिक रनटाइम को उपयोगकर्ता को यह बताना ज़रूरी है कि ऐप्लिकेशन उस संसाधन को ऐक्सेस कर पाएगा.
[C-0-10] अगर रनटाइम एनवायरमेंट, ऐप्लिकेशन की क्षमताओं को इस तरीके से रिकॉर्ड नहीं करता है, तो रनटाइम एनवायरमेंट को उस रनटाइम का इस्तेमाल करके किसी भी ऐप्लिकेशन को इंस्टॉल करते समय, रनटाइम के पास मौजूद सभी अनुमतियों की सूची बनानी होगी.
अन्य रनटाइम को PackageManager के ज़रिए, अलग-अलग Android सैंडबॉक्स (Linux उपयोगकर्ता आईडी वगैरह) में ऐप्लिकेशन इंस्टॉल करने चाहिए.
वैकल्पिक रनटाइम, एक ही Android सैंडबॉक्स उपलब्ध करा सकते हैं. इसे वैकल्पिक रनटाइम का इस्तेमाल करने वाले सभी ऐप्लिकेशन शेयर करते हैं.

9.5. एक डिवाइस पर कई लोगों के काम करने की सुविधा

Android में एक से ज़्यादा उपयोगकर्ताओं के लिए सहायता शामिल है. साथ ही, यह उपयोगकर्ता को पूरी तरह से अलग करने की सुविधा भी देता है.

अगर डिवाइस में प्राइमरी बाहरी स्टोरेज के लिए रिमूवेबल मीडिया का इस्तेमाल किया जाता है, तो हो सकता है कि डिवाइस में एक से ज़्यादा उपयोगकर्ताओं के लिए फ़ाइल शेयर करने की सुविधा चालू हो. हालांकि, ऐसा नहीं होना चाहिए.

अगर डिवाइस पर एक से ज़्यादा उपयोगकर्ताओं को लागू किया जाता है, तो:

[C-1-1] एक से ज़्यादा उपयोगकर्ताओं के लिए सहायता से जुड़ी ये ज़रूरी शर्तें पूरी करनी होंगी.
[C-1-2] हर उपयोगकर्ता के लिए, Android प्लैटफ़ॉर्म के सुरक्षा मॉडल के मुताबिक सुरक्षा मॉडल लागू करना ज़रूरी है. इस मॉडल के बारे में एपीआई में सुरक्षा और अनुमतियों के रेफ़रंस दस्तावेज़ में बताया गया है.
[C-1-3] हर उपयोगकर्ता इंस्टेंस के लिए, अलग-अलग और अलग-अलग ऐप्लिकेशन स्टोरेज (/sdcard) डायरेक्ट्री होनी चाहिए.
[C-1-4] यह पक्का करना ज़रूरी है कि किसी उपयोगकर्ता के मालिकाना हक वाली और उसकी ओर से चलने वाली फ़ाइलें, किसी दूसरे उपयोगकर्ता की फ़ाइलों को न तो देख सकें, न ही उनमें बदलाव कर सकें और न ही उन्हें पढ़ सकें. भले ही, दोनों उपयोगकर्ताओं का डेटा एक ही वॉल्यूम या फ़ाइल सिस्टम में सेव हो.
[C-1-5] अगर डिवाइस में बाहरी स्टोरेज के एपीआई के लिए, हटाया जा सकने वाले मीडिया का इस्तेमाल किया जाता है, तो कई उपयोगकर्ताओं के लिए चालू होने पर, एसडी कार्ड के कॉन्टेंट को एन्क्रिप्ट करना ज़रूरी है. इसके लिए, ऐसी कुंजी का इस्तेमाल करना चाहिए जो सिर्फ़ न हटाया जा सकने वाले मीडिया पर सेव हो और जिसे सिर्फ़ सिस्टम ऐक्सेस कर सके. इससे होस्ट पीसी, मीडिया को नहीं पढ़ पाएगा. इसलिए, डिवाइस को MTP या मिलते-जुलते सिस्टम पर स्विच करना होगा, ताकि होस्ट पीसी को मौजूदा उपयोगकर्ता के डेटा का ऐक्सेस दिया जा सके.

9.6. प्रीमियम एसएमएस से जुड़ी चेतावनी

Android में, उपयोगकर्ताओं को किसी भी तरह के प्रीमियम एसएमएस मैसेज भेजने से पहले चेतावनी देने की सुविधा शामिल है. प्रीमियम मैसेज, ऐसे टेक्स्ट मैसेज होते हैं जिन्हें मोबाइल और इंटरनेट सेवा देने वाली कंपनी के साथ रजिस्टर की गई किसी सेवा पर भेजा जाता है. इन मैसेज के लिए, उपयोगकर्ता से शुल्क लिया जा सकता है.

अगर डिवाइस में सेट किए गए सिस्टम में android.hardware.telephony का इस्तेमाल किया जाता है, तो:

[C-1-1] डिवाइस में /data/misc/sms/codes.xml फ़ाइल में बताई गई रेगुलर एक्सप्रेशन से पहचाने गए नंबरों पर एसएमएस भेजने से पहले, उपयोगकर्ताओं को चेतावनी देनी ज़रूरी है. Android ओपन सोर्स प्रोजेक्ट, इस ज़रूरी शर्त को पूरा करने वाला तरीका उपलब्ध कराता है.

9.7. सुरक्षा से जुड़ी सुविधाएं

डिवाइस में सेट किए गए सिस्टम के लिए, यह ज़रूरी है कि वह कर्नेल और प्लैटफ़ॉर्म, दोनों में सुरक्षा से जुड़ी सुविधाओं का पालन करता हो. इन सुविधाओं के बारे में यहां बताया गया है.

Android सैंडबॉक्स में ऐसी सुविधाएं शामिल हैं जो Security-Enhanced Linux (SELinux) के ज़रूरी ऐक्सेस कंट्रोल (एमएसी) सिस्टम, seccomp सैंडबॉक्सिंग, और Linux kernel की अन्य सुरक्षा सुविधाओं का इस्तेमाल करती हैं. डिवाइस में सेट किए जाने वाले सिस्टम:

[C-0-1] यह ज़रूरी है कि मौजूदा ऐप्लिकेशन के साथ काम करने की सुविधा बनी रहे. भले ही, Android फ़्रेमवर्क के नीचे SELinux या सुरक्षा से जुड़ी कोई अन्य सुविधा लागू की गई हो.
[C-0-2] जब सुरक्षा से जुड़ा कोई उल्लंघन पता चलता है और Android फ़्रेमवर्क के नीचे लागू की गई सुरक्षा सुविधा से उसे ब्लॉक कर दिया जाता है, तो यूज़र इंटरफ़ेस (यूआई) नहीं दिखना चाहिए. हालांकि, जब सुरक्षा से जुड़ा कोई उल्लंघन ब्लॉक नहीं किया जाता है और उसका फ़ायदा उठाया जाता है, तो यूज़र इंटरफ़ेस दिख सकता है.
[C-0-3] Android फ़्रेमवर्क के नीचे लागू की गई SELinux या सुरक्षा से जुड़ी अन्य सुविधाओं को, उपयोगकर्ता या ऐप्लिकेशन डेवलपर के लिए कॉन्फ़िगर नहीं किया जा सकता.
[C-0-4] किसी ऐसे ऐप्लिकेशन को नीति कॉन्फ़िगर करने की अनुमति नहीं देनी चाहिए जो किसी एपीआई (जैसे, डिवाइस एडमिनिस्ट्रेशन एपीआई) के ज़रिए किसी दूसरे ऐप्लिकेशन पर असर डाल सकता है. ऐसा करने से, ऐप्लिकेशन के साथ काम करने की सुविधा पर असर पड़ता है.
[C-0-5] मीडिया फ़्रेमवर्क को कई प्रोसेस में बांटना ज़रूरी है, ताकि Android Open Source Project की साइट पर बताए गए तरीके से, हर प्रोसेस के लिए ऐक्सेस को ज़्यादा सटीक तरीके से दिया जा सके.
[C-0-6] कर्नेल ऐप्लिकेशन सैंडबॉक्सिंग का ऐसा तरीका लागू करना ज़रूरी है जिससे मल्टी-थ्रेड वाले प्रोग्राम से, कॉन्फ़िगर की जा सकने वाली नीति का इस्तेमाल करके सिस्टम कॉल को फ़िल्टर किया जा सके. अपस्ट्रीम Android Open Source Project, source.android.com के Kernel Configuration सेक्शन में बताए गए तरीके के मुताबिक, थ्रेडग्रुप सिंक्रोनाइज़ेशन (TSYNC) के साथ seccomp-BPF को चालू करके, इस ज़रूरी शर्त को पूरा करता है.

Android की सुरक्षा के लिए, कर्नेल इंटिग्रिटी और खुद को सुरक्षित रखने की सुविधाएं ज़रूरी हैं. डिवाइस में सेट किए जाने वाले सिस्टम:

[C-0-7] कर्नेल स्टैक बफ़र ओवरफ़्लो से सुरक्षा देने वाले तरीकों को लागू करना ज़रूरी है. इस तरह के तरीकों के उदाहरण CC_STACKPROTECTOR_REGULAR और CONFIG_CC_STACKPROTECTOR_STRONG हैं.
[C-0-8] जहां एक्ज़ीक्यूटेबल कोड सिर्फ़ पढ़ने के लिए उपलब्ध हो, सिर्फ़ पढ़ने के लिए उपलब्ध डेटा को एक्ज़ीक्यूट न किया जा सके और न ही उसमें बदलाव किया जा सके, और लिखने के लिए उपलब्ध डेटा को एक्ज़ीक्यूट न किया जा सके (जैसे, CONFIG_DEBUG_RODATA या CONFIG_STRICT_KERNEL_RWX), वहां कर्नेल मेमोरी की सुरक्षा के सख्त उपाय लागू करने ज़रूरी हैं.
[C-0-9] एपीआई लेवल 28 या इसके बाद के वर्शन के साथ शिप होने वाले डिवाइसों पर, उपयोगकर्ता-स्पेस और कर्नेल-स्पेस (उदाहरण के लिए, CONFIG_HARDENED_USERCOPY) के बीच कॉपी के स्टैटिक और डाइनैमिक ऑब्जेक्ट साइज़ की जांच करना ज़रूरी है.
[C-0-10] एपीआई लेवल 28 या उसके बाद के वर्शन वाले डिवाइसों पर, कर्नेल मोड (उदाहरण के लिए, हार्डवेयर PXN या CONFIG_CPU_SW_DOMAIN_PAN या CONFIG_ARM64_SW_TTBR0_PAN के ज़रिए एमुलेट किया गया) में प्रोग्राम चलाते समय, यूज़र-स्पेस मेमोरी का इस्तेमाल नहीं किया जाना चाहिए.
[C-0-11] एपीआई लेवल 28 या इसके बाद के वर्शन वाले डिवाइसों पर, सामान्य usercopy ऐक्सेस एपीआई (जैसे, हार्डवेयर पैन या CONFIG_CPU_SW_DOMAIN_PAN या CONFIG_ARM64_SW_TTBR0_PAN के ज़रिए एमुलेट किया गया) के अलावा, कर्नेल में उपयोगकर्ता-स्पेस मेमोरी को न तो पढ़ा जाना चाहिए और न ही उसमें बदलाव किया जाना चाहिए.
[C-0-12] अगर हार्डवेयर, CVE-2017-5754 से असुरक्षित है, तो एपीआई लेवल 28 या इसके बाद के वर्शन (जैसे, CONFIG_PAGE_TABLE_ISOLATION या CONFIG_UNMAP_KERNEL_AT_EL0) के साथ शिप होने वाले सभी डिवाइसों पर, कर्नेल पेज टेबल को अलग करना ज़रूरी है.
[C-0-13] अगर एपीआई लेवल 28 या इसके बाद के वर्शन (उदाहरण के लिए, CONFIG_HARDEN_BRANCH_PREDICTOR) के साथ शिप किए गए सभी डिवाइसों पर, हार्डवेयर CVE-2017-5715 से सुरक्षित नहीं है, तो ब्रैंच प्रिडिक्शन को बेहतर बनाने की सुविधा लागू करना ज़रूरी है.
[SR] हमारा सुझाव है कि कर्नेल के उस डेटा को, सिर्फ़ शुरू करने के दौरान लिखा जाए जिसे शुरू करने के बाद, रीड-ओनली के तौर पर मार्क किया जाए. जैसे, __ro_after_init.
[C-SR] कर्नेल कोड और मेमोरी के लेआउट को रैंडमाइज़ करने का सुझाव दिया जाता है.साथ ही, ऐसे एक्सपोज़र से बचने का सुझाव दिया जाता है जिनसे रैंडमाइज़ेशन की सुविधा का गलत इस्तेमाल हो सकता है. जैसे, /chosen/kaslr-seed Device Tree node या EFI_RNG_PROTOCOL के ज़रिए बूटलोडर एन्ट्रोपी के साथ CONFIG_RANDOMIZE_BASE.
[C-SR] हमारा सुझाव है कि कोड के गलत इस्तेमाल से जुड़े हमलों (जैसे, CONFIG_CFI_CLANG और CONFIG_SHADOW_CALL_STACK) से अतिरिक्त सुरक्षा पाने के लिए, कर्नेल में कंट्रोल फ़्लो इंटिग्रिटी (CFI) को चालू करें.
[C-SR] हमारा सुझाव है कि जिन कॉम्पोनेंट में कंट्रोल-फ़्लो इंटिग्रिटी (CFI), शैडो कॉल स्टैक (SCS) या इंटीजर ओवरफ़्लो सैनिटाइज़ेशन (IntSan) की सुविधा चालू है उन्हें बंद न करें.
[C-SR] हमारा सुझाव है कि सुरक्षा से जुड़े संवेदनशील उपयोगकर्ता-स्पेस के किसी भी अन्य कॉम्पोनेंट के लिए, सीएफ़आई, एससीएस, और IntSan को चालू करें. इनके बारे में सीएफ़आई और IntSan में बताया गया है.
[C-SR] हमारा सुझाव है कि कर्नेल में स्टैक को शुरू करने की सुविधा चालू करें, ताकि बिना शुरू किए गए लोकल वैरिएबल (CONFIG_INIT_STACK_ALL या CONFIG_INIT_STACK_ALL_ZERO) का इस्तेमाल न किया जा सके. साथ ही, डिवाइस के लागू होने पर, लोकल वैरिएबल को शुरू करने के लिए कंपाइलर की इस्तेमाल की गई वैल्यू का इस्तेमाल नहीं किया जाना चाहिए.
[C-SR] कर्नेल में ढेर को शुरू करने की सुविधा चालू करने का सुझाव दिया जाता है, ताकि बिना शुरू किए गए ढेर के ऐलोकेशन (CONFIG_INIT_ON_ALLOC_DEFAULT_ON) का इस्तेमाल न किया जा सके. साथ ही, उन्हें उन ऐलोकेशन को शुरू करने के लिए, कर्नेल की इस्तेमाल की गई वैल्यू को नहीं मानना चाहिए.

अगर डिवाइस में Linux kernel का इस्तेमाल किया जाता है, तो:

[C-1-1] SELinux को लागू करना ज़रूरी है.
[C-1-2] SELinux को ग्लोबल लागू करने वाले मोड पर सेट करना ज़रूरी है.
[C-1-3] सभी डोमेन को लागू करने के मोड में कॉन्फ़िगर करना ज़रूरी है. अनुमति वाले मोड के डोमेन इस्तेमाल करने की अनुमति नहीं है. इनमें किसी डिवाइस/वेंडर के लिए खास तौर पर बनाए गए डोमेन भी शामिल हैं.
[C-1-4] अपस्ट्रीम Android Open Source Project (AOSP) में दिए गए system/sepolicy फ़ोल्डर में मौजूद, 'कभी भी अनुमति न दें' नियमों में बदलाव नहीं किया जाना चाहिए, उन्हें हटाया नहीं जाना चाहिए या उन्हें बदला नहीं जाना चाहिए. साथ ही, नीति को AOSP SELinux डोमेन के साथ-साथ डिवाइस/वेंडर के हिसाब से बनाए गए डोमेन, दोनों के लिए मौजूद 'कभी भी अनुमति न दें' नियमों के साथ कंपाइल करना ज़रूरी है.
[C-1-5] तीसरे पक्ष के ऐसे ऐप्लिकेशन चलाने चाहिए जो एपीआई लेवल 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] हमारा सुझाव है कि AOSP में लागू करने के लिए, डेटा को 14 दिनों तक सेव रखने की अवधि को डिफ़ॉल्ट रूप से कॉन्फ़िगर किया गया हो.

Android, StatsLog आइडेंटिफ़ायर का इस्तेमाल करके सिस्टम इवेंट सेव करता है. साथ ही, StatsManager और IncidentManager सिस्टम एपीआई की मदद से इस तरह के इतिहास को मैनेज करता है.

डिवाइस में सेट किए जाने वाले सिस्टम:

[C-0-2] System API क्लास IncidentManager से बनाई गई समस्या की रिपोर्ट में, सिर्फ़ DEST_AUTOMATIC के साथ मार्क किए गए फ़ील्ड शामिल होने चाहिए.
[C-0-3] StatsLog SDK टूल के दस्तावेज़ों में बताए गए इवेंट के अलावा, किसी दूसरे इवेंट को लॉग करने के लिए, सिस्टम इवेंट आइडेंटिफ़ायर का इस्तेमाल नहीं करना चाहिए. अगर अतिरिक्त सिस्टम इवेंट लॉग किए जाते हैं, तो वे 1,00,000 से 2,00,000 के बीच की रेंज में किसी दूसरे ऐटम आइडेंटिफ़ायर का इस्तेमाल कर सकते हैं.

9.8.2. रिकॉर्डिंग

डिवाइस में सेट किए जाने वाले सिस्टम:

[C-0-1] डिवाइस में पहले से मौजूद ऐसे सॉफ़्टवेयर कॉम्पोनेंट को प्री-लोड या डिस्ट्रिब्यूट नहीं किया जाना चाहिए जो उपयोगकर्ता की सहमति के बिना या चल रही सूचनाओं को हटाकर, उसकी निजी जानकारी (जैसे, कीस्ट्रोक, स्क्रीन पर दिखने वाला टेक्स्ट, गड़बड़ी की रिपोर्ट) को डिवाइस से भेजते हैं.
[C-0-2] उपयोगकर्ता की स्क्रीन पर दिखने वाली संवेदनशील जानकारी को कैप्चर करने के लिए, उपयोगकर्ता की सहमति लेना ज़रूरी है. यह सहमति, MediaProjection या मालिकाना एपीआई के ज़रिए स्क्रीन कास्टिंग या स्क्रीन रिकॉर्डिंग चालू करने पर ली जानी चाहिए. उपयोगकर्ताओं को, आने वाले समय में उपयोगकर्ता की सहमति के मैसेज को बंद करने का विकल्प नहीं देना चाहिए.
[C-0-3] स्क्रीन कास्टिंग या स्क्रीन रिकॉर्डिंग की सुविधा चालू होने पर, उपयोगकर्ता को इसकी सूचना दिखनी चाहिए. AOSP, स्टेटस बार में चल रही गतिविधि की सूचना देने वाला आइकॉन दिखाकर, इस ज़रूरी शर्त को पूरा करता है.

अगर डिवाइस पर लागू किए गए सिस्टम में, स्क्रीन पर दिखने वाले कॉन्टेंट को कैप्चर करने और/या डिवाइस पर चलने वाली ऑडियो स्ट्रीम को रिकॉर्ड करने की सुविधा शामिल है, तो:ContentCaptureService

[C-1-1] जब भी यह सुविधा चालू हो और कैप्चर/रिकॉर्डिंग की जा रही हो, तब उपयोगकर्ता को इसकी सूचना दी जानी चाहिए.

अगर डिवाइस में पहले से चालू कोई ऐसा कॉम्पोनेंट शामिल है जो आस-पास के आवाज़ों को रिकॉर्ड कर सकता है और/या उपयोगकर्ता के संदर्भ के बारे में काम की जानकारी का अनुमान लगाने के लिए, डिवाइस पर चल रहे ऑडियो को रिकॉर्ड कर सकता है, तो:

[C-2-1] रिकॉर्ड किए गए रॉ ऑडियो या किसी ऐसे फ़ॉर्मैट को डिवाइस के स्टोरेज में सेव नहीं किया जाना चाहिए जिसे मूल ऑडियो या मिलते-जुलते ऑडियो में बदला जा सकता है. ऐसा करने के लिए, उपयोगकर्ता की साफ़ तौर पर सहमति लेना ज़रूरी है.

9.8.3. कनेक्टिविटी

अगर डिवाइस में यूएसबी पोर्ट है और उसमें यूएसबी पेरिफ़रल मोड की सुविधा है, तो:

[C-1-1] यूएसबी पोर्ट से शेयर किए गए स्टोरेज के कॉन्टेंट का ऐक्सेस देने से पहले, उपयोगकर्ता से सहमति मांगने के लिए यूज़र इंटरफ़ेस (यूआई) दिखाना ज़रूरी है.

9.8.4. नेटवर्क ट्रैफ़िक

डिवाइस में सेट किए जाने वाले सिस्टम:

[C-0-1] सिस्टम के भरोसेमंद सर्टिफ़िकेट देने वाली संस्था (सीए) के स्टोर के लिए, वे ही रूट सर्टिफ़िकेट पहले से इंस्टॉल होने चाहिए जो Android Open Source Project में उपलब्ध हैं.
[C-0-2] यह ज़रूरी है कि डिवाइस, खाली यूज़र रूट सीए स्टोर के साथ शिप किया जाए.
[C-0-3] उपयोगकर्ता के रूट सीए को जोड़ने पर, उपयोगकर्ता को चेतावनी दिखानी चाहिए. इसमें यह जानकारी होनी चाहिए कि नेटवर्क ट्रैफ़िक की निगरानी की जा सकती है.

अगर डिवाइस का ट्रैफ़िक वीपीएन के ज़रिए रूट किया जाता है, तो डिवाइस पर ये लागू होते हैं:

[C-1-1] उपयोगकर्ता को चेतावनी दिखानी चाहिए, जिसमें इनमें से कोई एक जानकारी हो:
- उस नेटवर्क ट्रैफ़िक को मॉनिटर किया जा सकता है.
- वह नेटवर्क ट्रैफ़िक, वीपीएन की सुविधा देने वाले खास वीपीएन ऐप्लिकेशन से होकर गुज़र रहा है.

अगर डिवाइस में कोई ऐसा तरीका है जो डिफ़ॉल्ट रूप से चालू होता है और नेटवर्क डेटा ट्रैफ़िक को प्रॉक्सी सर्वर या वीपीएन गेटवे के ज़रिए रूट करता है, तो:android.permission.CONTROL_VPN

[C-2-1] इस सुविधा को चालू करने से पहले, उपयोगकर्ता की सहमति लेना ज़रूरी है. हालांकि, अगर डिवाइस नीति नियंत्रक ने DevicePolicyManager.setAlwaysOnVpnPackage() के ज़रिए वीपीएन को चालू किया है, तो उपयोगकर्ता को अलग से सहमति देने की ज़रूरत नहीं है. हालांकि, उसे इसकी सूचना देना ज़रूरी है.

अगर डिवाइस में, तीसरे पक्ष के वीपीएन ऐप्लिकेशन के "हमेशा चालू वीपीएन" फ़ंक्शन को टॉगल करने के लिए, उपयोगकर्ता के लिए कोई सुविधा लागू की जाती है, तो:

[C-3-1] AndroidManifest.xml फ़ाइल में, हमेशा चालू रहने वाली वीपीएन सेवा के साथ काम न करने वाले ऐप्लिकेशन के लिए, इस सुविधा को बंद करना ज़रूरी है. इसके लिए, SERVICE_META_DATA_SUPPORTS_ALWAYS_ON एट्रिब्यूट को false पर सेट करें.

9.8.5. डिवाइस पहचानकर्ता

डिवाइस में सेट किए जाने वाले सिस्टम:

[C-0-1] ऐप्लिकेशन को डिवाइस के सीरियल नंबर और जहां लागू हो वहां IMEI/MEID, सिम का सीरियल नंबर, और इंटरनैशनल मोबाइल सब्सक्राइबर आइडेंटिटी (IMSI) को ऐक्सेस करने से रोकना चाहिए. हालांकि, ऐसा तब तक नहीं किया जाना चाहिए, जब तक ऐप्लिकेशन इनमें से किसी एक ज़रूरी शर्त को पूरा न करता हो:
- यह मोबाइल और इंटरनेट सेवा देने वाली कंपनी का ऐसा ऐप्लिकेशन है जिसकी पुष्टि डिवाइस बनाने वाली कंपनियों ने की है.
- को READ_PRIVILEGED_PHONE_STATE अनुमति दी गई है.
- यूआईसीसी के लिए कैरियर के खास अधिकार में बताए गए खास अधिकार हों.
- डिवाइस का मालिक या प्रोफ़ाइल का मालिक हो और उसे READ_PHONE_STATE अनुमति मिली हो.
- (सिर्फ़ सिम के सीरियल नंबर/आईसीसीआईडी के लिए) स्थानीय कानूनों के मुताबिक, ऐप्लिकेशन को यह पता लगाना होगा कि सदस्य की पहचान में कोई बदलाव हुआ है या नहीं.

9.8.6. सामग्री कैप्चर

Android, System API ContentCaptureService या अन्य मालिकाना तरीकों की मदद से, डिवाइस पर लागू होने वाले एक तरीके का इस्तेमाल करता है. इससे, ऐप्लिकेशन और उपयोगकर्ता के बीच होने वाले इन इंटरैक्शन को कैप्चर किया जा सकता है.

स्क्रीन पर रेंडर किया गया टेक्स्ट और ग्राफ़िक्स. इसमें AssistStructure एपीआई की मदद से सूचनाएं और सहायता डेटा शामिल है. हालांकि, इसमें और भी चीज़ें शामिल हो सकती हैं.
डिवाइस पर रिकॉर्ड किया गया या चलाया गया मीडिया डेटा, जैसे कि ऑडियो या वीडियो.
इनपुट इवेंट (जैसे, बटन, माउस, जेस्चर, आवाज़, वीडियो, और सुलभता).
ऐसे अन्य इवेंट जो कोई ऐप्लिकेशन, Content Capture एपीआई या मिलते-जुलते प्रॉपराइटरी एपीआई की मदद से सिस्टम को उपलब्ध कराता है.
TextClassifier API के ज़रिए सिस्टम टेक्स्ट क्लासिफ़ायर यानी सिस्टम की सेवा को भेजा गया कोई भी टेक्स्ट या अन्य डेटा.इससे टेक्स्ट का मतलब समझने के साथ-साथ, टेक्स्ट के आधार पर अनुमानित कार्रवाइयां जनरेट की जाती हैं.

अगर डिवाइस पर ऊपर दिया गया डेटा कैप्चर किया जाता है, तो:

[C-1-1] डिवाइस में सेव किए जाने पर, इस तरह के सभी डेटा को एन्क्रिप्ट करना ज़रूरी है. यह एन्क्रिप्शन, Android फ़ाइल पर आधारित एन्क्रिप्शन का इस्तेमाल करके किया जा सकता है. इसके अलावा, Cipher SDK में बताए गए एपीआई वर्शन 26 और उसके बाद के वर्शन के तौर पर सूची में शामिल किसी भी सिफर का इस्तेमाल करके भी यह एन्क्रिप्शन किया जा सकता है.
[C-1-2] Android के बैकअप लेने के तरीकों या किसी अन्य तरीके का इस्तेमाल करके, रॉ या एन्क्रिप्ट (सुरक्षित) किए गए डेटा का बैक अप नहीं लेना चाहिए.
[C-1-3] निजता बनाए रखने वाले तरीके का इस्तेमाल करके, सिर्फ़ इस तरह का डेटा और डिवाइस का लॉग भेजना ज़रूरी है. निजता बनाए रखने वाले तरीके को इस तरह से परिभाषित किया गया है, “ये सिर्फ़ एग्रीगेट में विश्लेषण की अनुमति देते हैं और अलग-अलग उपयोगकर्ताओं के लिए, लॉग किए गए इवेंट या डेटा से मिले नतीजों को मैच करने से रोकते हैं”. इससे, हर उपयोगकर्ता के डेटा को इंट्रोस्पेक्शन (उदाहरण के लिए, RAPPOR जैसी अलग-अलग निजता टेक्नोलॉजी का इस्तेमाल करके लागू किया गया) से रोका जा सकता है.
[C-1-4] इस तरह के डेटा को डिवाइस पर मौजूद किसी भी उपयोगकर्ता की पहचान (जैसे, Account) से नहीं जोड़ना चाहिए. हालांकि, डेटा को हर बार जोड़ने के लिए, उपयोगकर्ता की साफ़ तौर पर सहमति लेनी होगी.
[C-1-5] इस तरह के डेटा को अन्य ऐप्लिकेशन के साथ शेयर नहीं किया जाना चाहिए. हालांकि, हर बार डेटा शेयर करने के लिए, उपयोगकर्ता की साफ़ तौर पर सहमति लेनी होगी.
[C-1-6] उपयोगकर्ता को ऐसा डेटा मिटाने का विकल्प देना ज़रूरी है जिसे ContentCaptureService या मालिकाना हक वाले तरीके से इकट्ठा किया जाता है. ऐसा तब होता है, जब डेटा को डिवाइस पर किसी भी फ़ॉर्मैट में सेव किया जाता है.

अगर डिवाइस में लागू की गई किसी सेवा में System API ContentCaptureService लागू किया गया है या ऊपर बताई गई तरह से डेटा कैप्चर करने वाली कोई मालिकाना सेवा शामिल है, तो:

[C-2-1] उपयोगकर्ताओं को कॉन्टेंट कैप्चर करने वाली सेवा को, उपयोगकर्ता के इंस्टॉल किए जा सकने वाले ऐप्लिकेशन या सेवा से बदलने की अनुमति नहीं देनी चाहिए. साथ ही, सिर्फ़ पहले से इंस्टॉल की गई सेवा को ऐसा डेटा कैप्चर करने की अनुमति देनी चाहिए.
[C-2-2] पहले से इंस्टॉल की गई कॉन्टेंट कैप्चर करने की सेवा के अलावा, किसी भी ऐप्लिकेशन को ऐसा डेटा कैप्चर करने की अनुमति नहीं दी जानी चाहिए.
[C-2-3] कॉन्टेंट कैप्चर करने की सेवा को बंद करने के लिए, उपयोगकर्ता को आसानी से ऐक्सेस किया जा सकने वाला विकल्प देना ज़रूरी है.
[C-2-4] कॉन्टेंट कैप्चर करने वाली सेवा के पास मौजूद Android की अनुमतियों को मैनेज करने के लिए, उपयोगकर्ता को आसानी से ऐक्सेस करने की सुविधा देनी ज़रूरी है. साथ ही, सेक्शन 9.1 में बताए गए Android की अनुमतियों के मॉडल का पालन करना ज़रूरी है. अनुमति.
[C-SR] कॉन्टेंट कैप्चर करने वाली सेवा के कॉम्पोनेंट को अलग रखने का ज़रूर सुझाव दिया जाता है. उदाहरण के लिए, सेवा को बांधना या प्रोसेस आईडी को सिस्टम के अन्य कॉम्पोनेंट के साथ शेयर न करना. हालांकि, इनके साथ ऐसा करना ज़रूरी है:
- टेलीफ़ोन, संपर्क, सिस्टम यूज़र इंटरफ़ेस (यूआई), और मीडिया

9.8.7. क्लिपबोर्ड का ऐक्सेस

डिवाइस में सेट किए जाने वाले सिस्टम:

[C-0-1] जब तक ऐप्लिकेशन डिफ़ॉल्ट IME या फ़िलहाल फ़ोकस में है, तब तक क्लिपबोर्ड पर क्लिप किया गया डेटा नहीं दिखाना चाहिए. जैसे, ClipboardManager एपीआई के ज़रिए.

9.8.8. जगह की जानकारी

डिवाइस में सेट किए जाने वाले सिस्टम:

[C-0-1] उपयोगकर्ता की सहमति या उपयोगकर्ता के निर्देश के बिना, डिवाइस की जगह की जानकारी की सेटिंग और वाई-फ़ाई/ब्लूटूथ स्कैनिंग की सेटिंग को चालू/बंद नहीं किया जाना चाहिए.
[C-0-2] ऐप्लिकेशन को उपयोगकर्ता को जगह की जानकारी से जुड़ी जानकारी ऐक्सेस करने की सुविधा देनी होगी. इसमें जगह की जानकारी के लिए हाल ही के अनुरोध, ऐप्लिकेशन लेवल की अनुमतियां, और वाई-फ़ाई/ब्लूटूथ स्कैनिंग का इस्तेमाल शामिल है.
[C-0-3] यह पक्का करना ज़रूरी है कि आपातकालीन जगह की जानकारी को बायपास करने वाले 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 की मदद से, ऐप्लिकेशन को सिस्टम में डेटा ब्लॉब जोड़ने की अनुमति देता है. इन ब्लॉब को ऐप्लिकेशन के चुने गए सेट के साथ शेयर किया जा सकता है.

अगर डिवाइस में सेट किए गए सिस्टम, SDK टूल के दस्तावेज़ में बताए गए तरीके से शेयर किए गए डेटा ब्लॉब के साथ काम करते हैं, तो वे:

[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 कंपैटबिलिटी डेफ़िनिशन दस्तावेज़ के सेक्शन 9.9 में बताई गई ज़रूरी शर्तों को पूरा करना होगा जिस पर डिवाइस लॉन्च किया गया था.

9.9.1. डायरेक्ट बूट

डिवाइस में सेट किए जाने वाले सिस्टम:

[C-0-1] डायरेक्ट बूट मोड एपीआई को लागू करना ज़रूरी है. भले ही, वे स्टोरेज एन्क्रिप्शन के साथ काम न करते हों.
[C-0-2] डिवाइस को सीधे चालू करने की सुविधा वाले ऐप्लिकेशन को यह सिग्नल देने के लिए, ACTION_LOCKED_BOOT_COMPLETED और ACTION_USER_UNLOCKED इंटेंट अब भी ब्रॉडकास्ट किए जाने चाहिए कि उपयोगकर्ता के लिए, डिवाइस एन्क्रिप्ट (DE) और क्रेडेंशियल एन्क्रिप्ट (CE) स्टोरेज की जगहें उपलब्ध हैं.

9.9.2. एन्क्रिप्शन से जुड़ी ज़रूरी शर्तें

डिवाइस में सेट किए जाने वाले सिस्टम:

[C-0-1] ऐप्लिकेशन के निजी डेटा (/data पार्टिशन) के साथ-साथ, ऐप्लिकेशन के शेयर किए गए स्टोरेज पार्टिशन (/sdcard पार्टिशन) को एन्क्रिप्ट करना ज़रूरी है. हालांकि, ऐसा तब ही करना होगा, जब यह पार्टिशन डिवाइस का हमेशा मौजूद रहने वाला और हटाया नहीं जा सकने वाला हिस्सा हो.
[C-0-2] उपयोगकर्ता के डिवाइस पर डिफ़ॉल्ट रूप से डेटा स्टोरेज एन्क्रिप्शन की सुविधा चालू होनी चाहिए. यह सुविधा, डिवाइस के पहले सेटअप के दौरान चालू होनी चाहिए.
[C-0-3] डेटा स्टोरेज को एन्क्रिप्ट करने से जुड़ी ऊपर दी गई ज़रूरी शर्त को पूरा करना ज़रूरी है. इसके लिए, एन्क्रिप्ट करने के इन दोनों तरीकों में से किसी एक को लागू करें:
- अलग-अलग फ़ाइलों को अलग-अलग तरीकों से एन्क्रिप्ट करने का तरीका (एफ़बीई) और मेटाडेटा एन्क्रिप्शन, जैसा कि सेक्शन 9.9.3.1 में बताया गया है.
- हर उपयोगकर्ता के लिए ब्लॉक-लेवल एन्क्रिप्शन, जैसा कि सेक्शन 9.9.3.2 में बताया गया है.

9.9.3. एन्क्रिप्ट (सुरक्षित) करने के तरीके

अगर डिवाइस पर एन्क्रिप्शन लागू किया गया है, तो:

[C-1-1] डिवाइस को उपयोगकर्ता से क्रेडेंशियल मांगे बिना बूट होना चाहिए. साथ ही, ACTION_LOCKED_BOOT_COMPLETED मैसेज ब्रॉडकास्ट होने के बाद, डायरेक्ट बूट की सुविधा वाले ऐप्लिकेशन को डिवाइस के एन्क्रिप्ट किए गए (DE) स्टोरेज को ऐक्सेस करने की अनुमति देनी चाहिए.
[C-1-2] उपयोगकर्ता के डिवाइस को अनलॉक करने के बाद ही, क्रेडेंशियल एन्क्रिप्ट (सीई) स्टोरेज को ऐक्सेस करने की अनुमति दी जानी चाहिए. इसके लिए, उपयोगकर्ता को अपने क्रेडेंशियल (जैसे, पासकोड, पिन, पैटर्न या फ़िंगरप्रिंट) डालने होंगे और ACTION_USER_UNLOCKED मैसेज ब्रॉडकास्ट किया जाना चाहिए.
[C-1-13] उपयोगकर्ता के दिए गए क्रेडेंशियल, रजिस्टर की गई एस्क्रो कुंजी या सेक्शन 9.9.4 में बताई गई ज़रूरी शर्तों को पूरा करने वाले रीबूट लागू करने के बाद, सीई से सुरक्षित स्टोरेज को अनलॉक करने का कोई तरीका नहीं दिया जाना चाहिए.
[C-1-4] वेरिफ़ाइड बूट मोड का इस्तेमाल करना ज़रूरी है.

9.9.3.1. मेटाडेटा एन्क्रिप्शन के साथ फ़ाइल के आधार पर एन्क्रिप्शन

अगर डिवाइस पर, मेटाडेटा एन्क्रिप्शन के साथ फ़ाइल को अलग-अलग तरीकों से एन्क्रिप्ट करने का तरीका इस्तेमाल किया जाता है, तो:

[C-1-5] फ़ाइल के कॉन्टेंट और फ़ाइल सिस्टम के मेटाडेटा को एईएस-256-एक्सटीएस या 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] अगर डिवाइस में Advanced Encryption Standard (AES) निर्देश (जैसे, ARM-आधारित डिवाइसों पर ARMv8 क्रिप्टोग्राफ़ी एक्सटेंशन या x86-आधारित डिवाइसों पर AES-NI) हैं, तो फ़ाइल के नाम, फ़ाइल के कॉन्टेंट, और फ़ाइल सिस्टम के मेटाडेटा को एन्क्रिप्ट करने के लिए, ऊपर दिए गए AES-आधारित विकल्पों का इस्तेमाल करना ज़रूरी है, न कि Adiantum का.
[C-1-13] सीई और डीई कुंजियों से, ज़रूरी सब-कुंजियों (जैसे, हर फ़ाइल के लिए कुंजियां) को पाने के लिए, क्रिप्टोग्राफ़िक तरीके से सुरक्षित और रिवर्स नहीं की जा सकने वाली कुंजी बनाने वाले फ़ंक्शन (जैसे, HKDF-SHA512) का इस्तेमाल करना ज़रूरी है. "एन्क्रिप्शन के लिहाज़ से मज़बूत और जिसे वापस नहीं लाया जा सकता" का मतलब है कि कुंजी बनाने वाले फ़ंक्शन की सुरक्षा कम से कम 256 बिट की है और यह अपने इनपुट पर स्यूडोरैंडम फ़ंक्शन फ़ैमिली के तौर पर काम करता है.
[C-1-14] अलग-अलग क्रिप्टोग्राफ़िक कामों के लिए, फ़ाइल पर आधारित एन्क्रिप्शन (एफ़बीई) की एक ही कुंजियों या सब-कुंजियों का इस्तेमाल नहीं किया जाना चाहिए. जैसे, एन्क्रिप्शन और कुंजी बनाने के लिए या दो अलग-अलग एन्क्रिप्शन एल्गोरिदम के लिए.
सीई और डीई स्टोरेज एरिया और फ़ाइल सिस्टम मेटाडेटा को सुरक्षित रखने वाली कुंजियां:
[C-1-7] यह ज़रूरी है कि पासकोड को क्रिप्टोग्राफ़िक तरीके से, हार्डवेयर के साथ काम करने वाले पासकोड स्टोर से जोड़ा गया हो. यह पासकोड स्टोर, वेरिफ़ाइड बूट और डिवाइस के हार्डवेयर रूट ऑफ़ ट्रस्ट से बंधा होना चाहिए.
[C-1-8] सीई पासकोड, उपयोगकर्ता की लॉक स्क्रीन के क्रेडेंशियल से बंधे होने चाहिए.
[C-1-9] अगर उपयोगकर्ता ने लॉक स्क्रीन के क्रेडेंशियल नहीं दिए हैं, तो सीई पासकोड को डिफ़ॉल्ट पासकोड से बंधा होना चाहिए.
[C-1-10] यह यूनीक और अलग-अलग होनी चाहिए. दूसरे शब्दों में, किसी भी उपयोगकर्ता की सीई या डीई कुंजी, किसी दूसरे उपयोगकर्ता की सीई या डीई कुंजी से मेल नहीं खाती.
[C-1-11] ज़रूरी सिफर, कुंजी की लंबाई, और मोड का इस्तेमाल करना ज़रूरी है.
पहले से इंस्टॉल किए गए ज़रूरी ऐप्लिकेशन (जैसे, अलार्म, फ़ोन, मैसेंजर) को डायरेक्ट बूट के बारे में जानकारी देनी चाहिए.

अपस्ट्रीम Android Open Source प्रोजेक्ट, Linux kernel "fscrypt" एन्क्रिप्शन सुविधा के आधार पर, अलग-अलग फ़ाइलों को अलग-अलग तरीकों से एन्क्रिप्ट करने का तरीका इस्तेमाल करता है. साथ ही, Linux kernel "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 kernel की “dm-crypt” सुविधा का इस्तेमाल किया जा सकता है.

9.9.4. रीबूट होने पर फिर से शुरू करना

'रिबूट होने पर फिर से शुरू करें' सुविधा की मदद से, ओटीए से रिबूट करने के बाद, सभी ऐप्लिकेशन के सीई स्टोरेज को अनलॉक किया जा सकता है. इनमें वे ऐप्लिकेशन भी शामिल हैं जो फ़िलहाल डायरेक्ट बूट के साथ काम नहीं करते. इस सुविधा की मदद से, उपयोगकर्ताओं को रीबूट करने के बाद, इंस्टॉल किए गए ऐप्लिकेशन से सूचनाएं मिलती हैं.

'रीबूट होने पर फिर से शुरू करें' सुविधा को लागू करने के बाद भी यह पक्का करना ज़रूरी है कि जब कोई डिवाइस किसी हमलावर के हाथों में पड़ जाए, तो वह उपयोगकर्ता के सीई से एन्क्रिप्ट किए गए डेटा को वापस पाने में काफ़ी मुश्किल हो. भले ही, डिवाइस चालू हो, सीई स्टोरेज अनलॉक हो, और उपयोगकर्ता ने ओटीए मिलने के बाद डिवाइस अनलॉक कर लिया हो. हम यह भी मानते हैं कि अंदरूनी हमले से बचने के लिए, हमलावर के पास ब्रॉडकास्ट क्रिप्टोग्राफ़िक साइनिंग पासकोड का ऐक्सेस है.

खास तौर से:

[C-0-1] सीई स्टोरेज को हमलावर भी न पढ़ पाए. भले ही, उसके पास डिवाइस का फ़िज़िकल ऐक्सेस हो. साथ ही, उसके पास ये सुविधाएं और सीमाएं होनी चाहिए:
- किसी भी वेंडर या कंपनी की साइनिंग पासकोड का इस्तेमाल करके, किसी भी मैसेज को साइन किया जा सकता है.
- इससे डिवाइस पर ओटीए (ओवर-द-एयर) अपडेट मिल सकता है.
- नीचे दी गई जानकारी के अलावा, किसी भी हार्डवेयर (एपी, फ़्लैश वगैरह) के काम करने के तरीके में बदलाव किया जा सकता है. हालांकि, ऐसा करने में कम से कम एक घंटा लग सकता है. साथ ही, इसमें पावर साइकल भी शामिल है, जो रैम के कॉन्टेंट को नष्ट कर देता है.
- छेड़छाड़ से सुरक्षित हार्डवेयर (जैसे, 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 Open Source Project, external/avb/ रिपॉज़िटरी में इस सुविधा को लागू करने का सुझाव देता है. इसे Android को लोड करने के लिए इस्तेमाल किए जाने वाले बूटलोडर में इंटिग्रेट किया जा सकता है.

डिवाइस में सेट किए जाने वाले सिस्टम:

[C-0-3] यह ज़रूरी है कि पूरी फ़ाइल को पढ़े बिना, किसी भरोसेमंद कुंजी के हिसाब से फ़ाइल के कॉन्टेंट की क्रिप्टोग्राफ़ी के ज़रिए पुष्टि की जा सके.
[C-0-4] अगर पढ़े गए कॉन्टेंट की पुष्टि किसी भरोसेमंद कुंजी से नहीं की जाती है, तो सुरक्षित फ़ाइल को पढ़ने के अनुरोधों को पूरा नहीं किया जाना चाहिए.

अगर डिवाइस पर, Android के पुराने वर्शन में किसी भरोसेमंद पासकोड की मदद से फ़ाइल के कॉन्टेंट की पुष्टि करने की सुविधा पहले से ही उपलब्ध है और सिस्टम सॉफ़्टवेयर के अपडेट की मदद से इस सुविधा को जोड़ा नहीं जा सकता, तो हो सकता है कि डिवाइस को इस ज़रूरी शर्त से छूट दी जाए. अपस्ट्रीम Android Open Source प्रोजेक्ट, Linux kernel fs-verity सुविधा के आधार पर, इस सुविधा को लागू करने का सुझाव देता है.

डिवाइस में सेट किए जाने वाले सिस्टम:

[C-R] Android Protected Confirmation API के साथ काम करने का सुझाव दिया जाता है.

अगर डिवाइस में सेट किए गए सिस्टम, Android Protected Confirmation API के साथ काम करते हैं, तो:

[C-3-1] ConfirmationPrompt.isSupported() एपीआई के लिए, true की रिपोर्ट देना ज़रूरी है.
[C-3-2] यह पक्का करना ज़रूरी है कि Android OS में चलने वाला कोड, उपयोगकर्ता के इंटरैक्शन के बिना कोई रिस्पॉन्स जनरेट न कर सके. भले ही, वह कोड नुकसान पहुंचाने वाला हो या कोई और. इसमें, Android OS का कर्नेल भी शामिल है.
[C-3-3] यह पक्का करना ज़रूरी है कि उपयोगकर्ता ने प्रॉम्प्ट किए गए मैसेज की समीक्षा करके उसे स्वीकार किया हो. भले ही, Android OS और उसके कर्नेल को हैक कर लिया गया हो.

9.11. कुंजियां और क्रेडेंशियल

Android Keystore System की मदद से, ऐप्लिकेशन डेवलपर किसी कंटेनर में क्रिप्टोग्राफ़िक पासकोड सेव कर सकते हैं. साथ ही, KeyChain API या Keystore API की मदद से, क्रिप्टोग्राफ़िक ऑपरेशन में उनका इस्तेमाल कर सकते हैं. डिवाइस में सेट किए जाने वाले सिस्टम:

[C-0-1] कम से कम 8,192 कुंजियों को इंपोर्ट या जनरेट करने की अनुमति होनी चाहिए.
[C-0-2] लॉक स्क्रीन की पुष्टि करने की सुविधा में, कोशिशों की दर को सीमित करना ज़रूरी है. साथ ही, इसमें एक्सपोनेंशियल बैकऑफ़ एल्गोरिदम होना चाहिए. 150 बार कोशिश करने के बाद, हर बार कम से कम 24 घंटे इंतज़ार करना ज़रूरी है.
जनरेट की जा सकने वाली कुंजियों की संख्या को सीमित नहीं करना चाहिए

जब डिवाइस पर सुरक्षित लॉक स्क्रीन की सुविधा काम करती है, तो:

[C-1-1] ज़रूरी है कि अलग सेट अप किए गए प्रोसेसिंग एनवायरमेंट में, पासकोड को लागू करने के लिए बैक अप लिया जाए.
[C-1-2] Android Keystore सिस्टम के काम करने वाले एल्गोरिदम को सही तरीके से काम करने के लिए, RSA, AES, ECDSA, और HMAC क्रिप्टोग्राफ़िक एल्गोरिदम और MD5, SHA1, और SHA-2 फ़ैमिली हैश फ़ंक्शन लागू होने चाहिए. ये एल्गोरिदम और फ़ंक्शन, कर्नेल और उसके बाद के लेवल पर चलने वाले कोड से सुरक्षित तरीके से अलग होने चाहिए. सुरक्षित आइसोलेशन, उन सभी संभावित तरीकों को ब्लॉक करना चाहिए जिनसे कर्नेल या यूज़रस्पेस कोड, डीएमए के साथ-साथ आइसोलेट किए गए एनवायरमेंट की इंटरनल स्टेटस को ऐक्सेस कर सकता है. अपस्ट्रीम Android Open Source Project (AOSP), Trusty को लागू करके इस ज़रूरी शर्त को पूरा करता है. हालांकि, ARM TrustZone पर आधारित कोई अन्य समाधान या तीसरे पक्ष की समीक्षा के बाद, हाइपरवाइजर पर आधारित सही आइसोलेशन को सुरक्षित तरीके से लागू करना, इसके अन्य विकल्प हैं.
[C-1-3] लॉक स्क्रीन की पुष्टि, अलग-अलग एक्ज़ीक्यूशन एनवायरमेंट में करनी चाहिए. पुष्टि होने के बाद ही, पुष्टि करने के लिए इस्तेमाल की जाने वाली कुंजियों का इस्तेमाल करने की अनुमति दें. लॉक स्क्रीन के क्रेडेंशियल इस तरह से सेव किए जाने चाहिए कि सिर्फ़ अलग-अलग इकोसिस्टम में काम करने वाले प्रोग्राम, लॉक स्क्रीन की पुष्टि कर सकें. अपस्ट्रीम Android Open Source Project, Gatekeeper Hardware Abstraction Layer (HAL) और Trusty उपलब्ध कराता है. इनका इस्तेमाल, इस ज़रूरी शर्त को पूरा करने के लिए किया जा सकता है.
[C-1-4] यह ज़रूरी है कि डिवाइस में कुंजी की पुष्टि करने की सुविधा काम करती हो. इसमें, पुष्टि करने के लिए इस्तेमाल होने वाली साइनिंग कुंजी को सुरक्षित हार्डवेयर से सुरक्षित किया जाता है और साइनिंग की प्रोसेस को सुरक्षित हार्डवेयर में किया जाता है. पुष्टि करने के लिए इस्तेमाल होने वाली साइनिंग पासकोड, ज़रूरत के मुताबिक ज़्यादा से ज़्यादा डिवाइसों पर शेयर किए जाने चाहिए. इससे, इन पासकोड का इस्तेमाल डिवाइस आइडेंटिफ़ायर के तौर पर नहीं किया जा सकेगा. इस ज़रूरी शर्त को पूरा करने का एक तरीका यह है कि जब तक किसी SKU की कम से कम 1,00,000 यूनिट तैयार न हो जाएं, तब तक एक ही पुष्टि करने वाली कुंजी शेयर करें. अगर किसी SKU की 1,00,000 से ज़्यादा यूनिट बनाई जाती हैं, तो हर 1,00,000 यूनिट के लिए अलग-अलग कुंजी का इस्तेमाल किया जा सकता है.

[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] पुष्टि करने के लिए सुझाए गए मुख्य तरीकों में से किसी एक का इस्तेमाल करने के लिए, फ़ॉल-बैक मैकेनिज्म होना चाहिए. यह तरीका, किसी ऐसे गुप्त पासवर्ड पर आधारित होना चाहिए जिसकी जानकारी सभी के पास हो.
[C-4-3] इसे बंद करना ज़रूरी है. साथ ही, स्क्रीन को अनलॉक करने के लिए, सिर्फ़ सुझाई गई मुख्य पुष्टि की अनुमति दें. ऐसा तब किया जा सकता है, जब डिवाइस नीति नियंत्रक (डीपीसी) ऐप्लिकेशन ने DevicePolicyManager.setKeyguardDisabledFeatures() तरीके को कॉल करके, कीगार्ड की सुविधा की नीति सेट की हो. साथ ही, उसने इससे जुड़े किसी भी बायोमेट्रिक फ़्लैग (जैसे, KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE या KEYGUARD_DISABLE_IRIS) का इस्तेमाल किया हो.

अगर बायोमेट्रिक ऑथेंटिकेशन के तरीके, सेक्शन 7.3.10 में बताई गई तीसरी क्लास (पहले इसे बेहतर कहा जाता था) की ज़रूरी शर्तों को पूरा नहीं करते हैं, तो:

[C-5-1] अगर डिवाइस नीति नियंत्रक (डीपीसी) ऐप्लिकेशन ने DevicePolicyManager.setPasswordQuality() तरीके से पासवर्ड की क्वालिटी से जुड़ी नीति को सेट किया है और PASSWORD_QUALITY_BIOMETRIC_WEAK से ज़्यादा पाबंदी वाला क्वालिटी कॉन्स्टेंट इस्तेमाल किया है, तो इन तरीकों को बंद करना ज़रूरी है.
[C-5-2] उपयोगकर्ता को सुझाई गई मुख्य पुष्टि करने की प्रक्रिया (जैसे: पिन, पैटर्न, पासवर्ड) के लिए ज़रूर चैलेंज करना चाहिए. इस बारे में सेक्शन 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 सिस्टम एपीआई को लागू करते हैं, तो:

[C-7-1] जब डिवाइस लॉक को कुछ समय के लिए रोका जाता है या उसे ट्रस्ट एजेंट अनलॉक कर सकते हैं, तो सेटिंग मेन्यू और लॉक स्क्रीन पर साफ़ तौर पर जानकारी दिखनी चाहिए. उदाहरण के लिए, AOSP इस ज़रूरी शर्त को पूरा करता है. इसके लिए, सेटिंग मेन्यू में "स्क्रीन अपने-आप लॉक होने की सेटिंग" और "पावर बटन से तुरंत लॉक हो जाता है" के लिए टेक्स्ट की जानकारी दिखाता है. साथ ही, लॉक स्क्रीन पर एक अलग आइकॉन दिखाता है.
[C-7-2] DevicePolicyManager क्लास में मौजूद सभी ट्रस्ट एजेंट एपीआई का सम्मान करना और उन्हें पूरी तरह से लागू करना ज़रूरी है. जैसे, KEYGUARD_DISABLE_TRUST_AGENTS कॉन्स्टेंट.
[C-7-3] TrustAgentService.addEscrowToken() फ़ंक्शन को ऐसे डिवाइस पर पूरी तरह से लागू नहीं किया जाना चाहिए जिसका इस्तेमाल मुख्य निजी डिवाइस (जैसे, हैंडहेल्ड) के तौर पर किया जाता है. हालांकि, इस फ़ंक्शन को आम तौर पर शेयर किए जाने वाले डिवाइसों (जैसे, Android Television या वाहन से जुड़े डिवाइस) पर पूरी तरह से लागू किया जा सकता है.
[C-7-4] TrustAgentService.addEscrowToken() से जोड़े गए सभी सेव किए गए टोकन को एन्क्रिप्ट करना ज़रूरी है.
[C-7-5] एन्क्रिप्शन कुंजी या एस्क्रो टोकन को उसी डिवाइस पर सेव नहीं किया जाना चाहिए जिस पर कुंजी का इस्तेमाल किया जाता है. उदाहरण के लिए, फ़ोन पर सेव की गई कुंजी से, टीवी पर उपयोगकर्ता खाता अनलॉक किया जा सकता है. वाहन से जुड़े डिवाइसों के लिए, वाहन के किसी भी हिस्से में एस्क्रो टोकन सेव करने की अनुमति नहीं है.
[C-7-6] डेटा स्टोरेज को डिक्रिप्ट करने के लिए, एस्क्रो टोकन को चालू करने से पहले, उपयोगकर्ता को सुरक्षा से जुड़े असर के बारे में ज़रूर बताना चाहिए.
[C-7-7] पुष्टि करने के लिए सुझाए गए मुख्य तरीकों में से किसी एक का इस्तेमाल करने के लिए, फ़ॉल-बैक मैकेनिज्म होना चाहिए.
[C-7-8] उपयोगकर्ता को पुष्टि करने के लिए, सुझाए गए मुख्य तरीकों (जैसे: पिन, पैटर्न, पासवर्ड) में से किसी एक का इस्तेमाल करने के लिए, कम से कम हर 72 घंटे या उससे कम समय में एक बार ज़रूर कहा जाना चाहिए. ऐसा तब तक करना चाहिए, जब तक उपयोगकर्ता की सुरक्षा (जैसे, ड्राइवर का ध्यान भटकना) को लेकर कोई समस्या न हो.
[C-7-9] उपयोगकर्ता को पुष्टि करने के लिए, सेक्शन 7.3.10 में [C-1-7] और [C-1-8] में बताए गए प्राइमरी तरीके (जैसे: पिन, पैटर्न, पासवर्ड) में से किसी एक का इस्तेमाल करना होगा. ऐसा तब तक करना होगा, जब तक उपयोगकर्ता की सुरक्षा (जैसे, ड्राइवर का ध्यान भटकना) को लेकर कोई समस्या न हो.
[C-7-10] को सुरक्षित लॉक स्क्रीन के तौर पर इस्तेमाल नहीं किया जाना चाहिए. साथ ही, इसे नीचे C-8 में बताई गई पाबंदियों का पालन करना होगा.
[C-7-11] मुख्य निजी डिवाइसों (उदाहरण के लिए, हैंडहेल्ड) पर TrustAgents को डिवाइस अनलॉक करने की अनुमति नहीं दी जानी चाहिए.साथ ही, इनका इस्तेमाल सिर्फ़ पहले से अनलॉक किए गए डिवाइस को अनलॉक की स्थिति में ज़्यादा से ज़्यादा चार घंटे तक रखने के लिए किया जा सकता है. AOSP में TrustManagerService को डिफ़ॉल्ट रूप से लागू करने से, यह ज़रूरी शर्त पूरी हो जाती है.
[C-7-12] स्टोरेज डिवाइस से टारगेट डिवाइस पर एस्क्रो टोकन भेजने के लिए, क्रिप्टोग्राफ़िक तौर पर सुरक्षित (उदाहरण के लिए, UKEY2) कम्यूनिकेशन चैनल का इस्तेमाल करना ज़रूरी है.

अगर डिवाइस में, ऊपर बताई गई सुरक्षित लॉक स्क्रीन को अनलॉक करने के लिए, पुष्टि करने के तरीकों को जोड़ा जाता है या उनमें बदलाव किया जाता है और कीगार्ड को अनलॉक करने के लिए, पुष्टि करने के नए तरीके का इस्तेमाल किया जाता है, तो:

[C-8-1] जब डिवाइस नीति नियंत्रक (डीपीसी) ऐप्लिकेशन ने DevicePolicyManager.setPasswordQuality() तरीके से पासवर्ड की क्वालिटी से जुड़ी नीति को सेट किया हो, तो नया तरीका बंद करना ज़रूरी है. साथ ही, PASSWORD_QUALITY_UNSPECIFIED से ज़्यादा पाबंदी वाला क्वालिटी कॉन्स्टेंट इस्तेमाल करना चाहिए.
[C-8-2] उन्हें DevicePolicyManager.setPasswordExpirationTimeout() से सेट किए गए, पासवर्ड की समयसीमा खत्म होने के टाइमर को रीसेट नहीं करना चाहिए.
[C-8-3] उन्हें लॉक की स्थिति बदलने के लिए, तीसरे पक्ष के ऐप्लिकेशन के इस्तेमाल के लिए एपीआई को एक्सपोज़ नहीं करना चाहिए.

9.11.2. StrongBox

Android Keystore System की मदद से, ऐप्लिकेशन डेवलपर क्रिप्टोग्राफ़िक पासकोड को खास तौर पर बनाए गए सुरक्षित प्रोसेसर में सेव कर सकते हैं. साथ ही, ऊपर बताए गए अलग से बनाए गए एक्ज़ीक्यूशन एनवायरमेंट में भी सेव कर सकते हैं. इस तरह के खास सुरक्षित प्रोसेसर को "स्ट्रॉन्गबॉक्स" कहा जाता है. यहां दी गई C-1-3 से C-1-11 तक की ज़रूरी शर्तों के मुताबिक, किसी डिवाइस को StrongBox के तौर पर मंज़ूरी मिल सकती है.

डिवाइस में सेट किए हुए ऐसे सिस्टम जिनमें खास तौर पर सुरक्षित प्रोसेसर होता है:

[C-SR] StrongBox का इस्तेमाल करने का सुझाव दिया जाता है. आने वाले समय में, StrongBox का इस्तेमाल करना ज़रूरी हो सकता है.

अगर डिवाइस में StrongBox की सुविधा काम करती है, तो:

[C-1-1] FEATURE_STRONGBOX_KEYSTORE का एलान करना ज़रूरी है.
[C-1-2] खास तौर पर सुरक्षित हार्डवेयर उपलब्ध कराना ज़रूरी है. इसका इस्तेमाल, पासकोड को सुरक्षित रखने और उपयोगकर्ता की पहचान की पुष्टि करने के लिए किया जाता है. खास तौर पर सुरक्षित हार्डवेयर का इस्तेमाल, अन्य कामों के लिए भी किया जा सकता है.
[C-1-3] इसमें अलग सीपीयू होना चाहिए, जो ऐप्लिकेशन प्रोसेसर (एपी) के साथ कोई कैश, डीआरएएम, कोप्रोसेसर या अन्य मुख्य संसाधन शेयर न करता हो.
[C-1-4] यह पक्का करना ज़रूरी है कि एपी के साथ शेयर किए गए किसी भी पेरिफ़रल, StrongBox की प्रोसेसिंग में किसी भी तरह का बदलाव न कर सके या StrongBox से कोई जानकारी न हासिल कर सके. एपी, StrongBox को ऐक्सेस करने की सुविधा को बंद या ब्लॉक कर सकता है.
[C-1-5] इसमें एक ऐसी इंटरनल क्लॉक होनी चाहिए जो सटीक (+-10%) हो और एपी के मैनिपुलेशन से सुरक्षित हो.
[C-1-6] इसमें एक ऐसा ट्रू रैंडम नंबर जनरेटर होना चाहिए जो एक जैसा डिस्ट्रिब्यूशन वाला और अनुमान लगाने लायक न होने वाला आउटपुट जनरेट करता हो.
[C-1-7] डिवाइस में, छेड़छाड़ को रोकने की सुविधा होनी चाहिए. इसमें, डिवाइस में किसी तरह का बदलाव करने और गड़बड़ी करने से रोकने की सुविधा भी शामिल है.
[C-1-8] इसमें साइड-चैनल रेज़िस्टेंस होना चाहिए. इसमें पावर, टाइमिंग, इलेक्ट्रोमैग्नेटिक रेडिएशन, और थर्मल रेडिएशन साइड चैनलों से जानकारी लीक होने से रोकने की सुविधा भी शामिल है.
[C-1-9] आपके पास ऐसा सुरक्षित स्टोरेज होना चाहिए जिससे कॉन्टेंट की गोपनीयता, पूरी सुरक्षा, प्रामाणिकता, एक जैसी जानकारी, और अपडेट होने की सुविधा को पक्का किया जा सके. StrongBox API की अनुमति के अलावा, स्टोरेज को पढ़ा या उसमें बदलाव नहीं किया जा सकता.
[C-1-3] से [C-1-9] तक के नियमों का पालन करने की पुष्टि करने के लिए, डिवाइस में सेट किए गए सिस्टम:
- [C-1-10] इसमें ऐसा हार्डवेयर शामिल होना चाहिए जिसे सुरक्षित आईसी प्रोटेक्शन प्रोफ़ाइल BSI-CC-PP-0084-2014 के तहत सर्टिफ़ाइड किया गया हो या जिसकी जांच, राष्ट्रीय स्तर पर मान्यता वाली किसी टेस्टिंग लैबोरेटरी ने की हो. इस लैबोरेटरी ने स्मार्ट कार्ड पर हमले की संभावना के लिए सामान्य मानदंडों के आवेदन के मुताबिक, हमले की संभावना वाली कमज़ोरियों का आकलन किया हो.
- [C-1-11] इसमें ऐसा फ़र्मवेयर शामिल होना चाहिए जिसका आकलन, राष्ट्रीय स्तर पर मान्यता वाली टेस्टिंग लैबोरेटरी ने किया हो. साथ ही, स्मार्ट कार्ड पर हमले की संभावना के लिए सामान्य मानदंड के मुताबिक, इसमें हमले की ज़्यादा संभावना वाली जोखिम का आकलन शामिल होना चाहिए.
- [C-SR] हमारा सुझाव है कि आप ऐसे हार्डवेयर को शामिल करें जिसका आकलन, सुरक्षा टारगेट, मूल्यांकन एश्योरेंस लेवल (ईएएल) 5 का इस्तेमाल करके किया गया हो. साथ ही, AVA_VAN.5 की मदद से इसकी सुरक्षा को बेहतर बनाया गया हो. आने वाले समय में रिलीज़ होने वाले वर्शन के लिए, EAL 5 सर्टिफ़िकेशन की ज़रूरत होगी.
[C-SR] को अंदरूनी हमले से सुरक्षा (आईएआर) देने का सुझाव दिया जाता है. इसका मतलब है कि फ़र्मवेयर साइनिंग पासकोड का ऐक्सेस रखने वाला कोई भी व्यक्ति, ऐसा फ़र्मवेयर नहीं बना सकता जिससे StrongBox से गोपनीय जानकारी लीक हो. साथ ही, वह सुरक्षा से जुड़ी ज़रूरी शर्तों को बायपास नहीं कर सकता या उपयोगकर्ता के संवेदनशील डेटा को ऐक्सेस नहीं कर सकता. आईएआर को लागू करने का सुझाया गया तरीका यह है कि फ़र्मवेयर अपडेट करने की अनुमति सिर्फ़ तब दें, जब IAuthSecret HAL के ज़रिए प्राइमरी उपयोगकर्ता का पासवर्ड दिया गया हो.

9.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 लागू करने वाले लोगों को इसका सुझाव दिया जाता है कि वे 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 के लिए CTS के कई रिविज़न रिलीज़ किए जा सकते हैं.

डिवाइस में सेट किए जाने वाले सिस्टम:

[C-0-3] डिवाइस का सॉफ़्टवेयर पूरा होने के समय, CTS के सबसे नए वर्शन को पास करना ज़रूरी है.
ज़्यादा से ज़्यादा, Android Open Source Tree में रेफ़रंस के तौर पर लागू किए गए कोड का इस्तेमाल करना चाहिए.

10.2. सीटीएस की पुष्टि करने वाला टूल

CTS Verifier, Compatibility Test Suite में शामिल है. इसे कोई व्यक्ति चलाता है, ताकि उन सुविधाओं की जांच की जा सके जिनकी जांच ऑटोमेटेड सिस्टम से नहीं की जा सकती. जैसे, कैमरे और सेंसर की सही तरीके से काम करना.

डिवाइस में सेट किए जाने वाले सिस्टम:

[C-0-1] सीटीएस की पुष्टि करने वाले टूल में, लागू होने वाले सभी केस सही तरीके से लागू होने चाहिए.

CTS की पुष्टि करने वाले टूल में कई तरह के हार्डवेयर के लिए टेस्ट होते हैं. इनमें कुछ हार्डवेयर ऐसे भी होते हैं जो ज़रूरी नहीं होते.

डिवाइस में सेट किए जाने वाले सिस्टम:

[C-0-2] यह ज़रूरी है कि डिवाइस में मौजूद हर हार्डवेयर के लिए, सभी टेस्ट पास किए जाएं. उदाहरण के लिए, अगर किसी डिवाइस में एक्सलरोमीटर है, तो उसे CTS Verifier में एक्सलरोमीटर टेस्ट केस को सही तरीके से पूरा करना होगा.

कंपैटबिलिटी डेफ़िनिशन डॉक्यूमेंट में, जिन सुविधाओं को ज़रूरी नहीं बताया गया है उनके लिए टेस्ट केस को छोड़ा या हटाया जा सकता है.

[C-0-2] ऊपर बताए गए तरीके से, हर डिवाइस और हर बिल्ड के लिए CTS Verifier को सही तरीके से चलाना ज़रूरी है. हालांकि, कई बिल्ड काफ़ी मिलते-जुलते होते हैं. इसलिए, डिवाइस लागू करने वाले लोगों को उन बिल्ड पर सीटीएस की पुष्टि करने वाले टूल को साफ़ तौर पर चलाने की ज़रूरत नहीं है जो सिर्फ़ मामूली अंतरों में अलग होते हैं. खास तौर पर, डिवाइस में लागू किए गए ऐसे सिस्टम जिनमें शामिल स्थानीय भाषाओं, ब्रैंडिंग वगैरह के सेट की वजह से, CTS की पुष्टि करने वाले टूल से पास हुए सिस्टम से अंतर हो सकता है. ऐसे सिस्टम के लिए, CTS की पुष्टि करने वाले टूल से टेस्ट करने की ज़रूरत नहीं पड़ सकती.

11. अपडेट किया जा सकने वाला सॉफ़्टवेयर

[C-0-1] डिवाइस में सिस्टम लागू करने के लिए, सिस्टम के पूरे सॉफ़्टवेयर को बदलने का तरीका शामिल होना चाहिए. इस प्रोसेस में, “लाइव” अपग्रेड करने की ज़रूरत नहीं होती. इसका मतलब है कि डिवाइस को रीस्टार्ट करना पड़ सकता है. किसी भी तरीके का इस्तेमाल किया जा सकता है. हालांकि, यह ज़रूरी है कि वह डिवाइस पर पहले से इंस्टॉल किए गए सभी सॉफ़्टवेयर को बदल सके. उदाहरण के लिए, इनमें से कोई भी तरीका अपनाने पर, यह ज़रूरी शर्त पूरी हो जाएगी:
- रीबूट करके ऑफ़लाइन अपडेट के साथ “ओवर-द-एयर (ओटीए)” डाउनलोड.
- होस्ट पीसी से यूएसबी के ज़रिए “टैथर्ड” अपडेट.
- रीबूट करने पर, “ऑफ़लाइन” अपडेट और हटाने वाले स्टोरेज में मौजूद फ़ाइल से अपडेट.
[C-0-2] अपडेट करने के लिए इस्तेमाल किए गए तरीके से, उपयोगकर्ता का डेटा मिटाए बिना अपडेट किए जाने की सुविधा होनी चाहिए. इसका मतलब है कि अपडेट करने के तरीके से, ऐप्लिकेशन का निजी डेटा और शेयर किया गया डेटा सुरक्षित रहना चाहिए. ध्यान दें कि Android सॉफ़्टवेयर में अपडेट करने का एक तरीका शामिल है, जो इस ज़रूरी शर्त को पूरा करता है.
[C-0-3] पूरे अपडेट पर हस्ताक्षर होना चाहिए. साथ ही, डिवाइस पर अपडेट करने की सुविधा, डिवाइस में सेव किए गए सार्वजनिक पासकोड की मदद से, अपडेट और हस्ताक्षर की पुष्टि करनी चाहिए.
[C-SR] हमारा सुझाव है कि साइन करने के तरीके का इस्तेमाल करके, अपडेट को SHA-256 से हैश करें. साथ ही, ECDSA NIST P-256 का इस्तेमाल करके, हैश की पुष्टि सार्वजनिक कुंजी से करें.

अगर डिवाइस में 802.11 या ब्लूटूथ पीएएन (पर्सनल एरिया नेटवर्क) प्रोफ़ाइल जैसे बिना मीटर वाले डेटा कनेक्शन के लिए सहायता शामिल है, तो:

[C-1-1] डिवाइस को रीबूट करके, ऑफ़लाइन अपडेट के साथ ओटीए डाउनलोड की सुविधा होनी चाहिए.

Android 6.0 और उसके बाद के वर्शन के साथ लॉन्च किए जा रहे डिवाइसों के लिए, अपडेट करने की सुविधा से यह पुष्टि होनी चाहिए कि सिस्टम इमेज, ओटीए के बाद मिलने वाले नतीजे से मेल खाती है. Android 5.1 के बाद से, Android Open Source Project में ब्लॉक के आधार पर ओटीए लागू करने की सुविधा जोड़ी गई है. यह सुविधा इस ज़रूरी शर्त को पूरा करती है.

साथ ही, डिवाइस में सेट किए गए सिस्टम में A/B सिस्टम अपडेट की सुविधा काम करनी चाहिए. AOSP, बूट कंट्रोल एचएएल का इस्तेमाल करके इस सुविधा को लागू करता है.

अगर डिवाइस रिलीज़ होने के बाद, उसमें कोई गड़बड़ी मिलती है, लेकिन वह डिवाइस के तय किए गए लाइफ़टाइम के अंदर है, तो तीसरे पक्ष के ऐप्लिकेशन के साथ काम करने की सुविधा पर असर पड़ सकता है. इस लाइफ़टाइम को तय करने के लिए, Android के साथ काम करने की सुविधा देने वाली टीम से सलाह ली जाती है. ऐसे में:

[C-2-1] डिवाइस लागू करने वाले व्यक्ति को, उपलब्ध सॉफ़्टवेयर अपडेट की मदद से गड़बड़ी को ठीक करना होगा. यह अपडेट, ऊपर बताए गए तरीके के मुताबिक लागू किया जा सकता है.

Android में ऐसी सुविधाएं शामिल हैं जिनकी मदद से, डिवाइस के मालिक के ऐप्लिकेशन (अगर मौजूद हो) से सिस्टम अपडेट को कंट्रोल किया जा सकता है. अगर डिवाइसों के लिए सिस्टम अपडेट सबसिस्टम, android.software.device_admin की रिपोर्ट करता है, तो:

[C-3-1] SystemUpdatePolicy क्लास में बताए गए व्यवहार को लागू करना ज़रूरी है.

12. दस्तावेज़ में बदलाव का लॉग

इस रिलीज़ में, कंपैटबिलिटी डेफ़िनिशन में किए गए बदलावों की खास जानकारी के लिए:

बदलावों की जानकारी देने वाला दस्तावेज़

निजी सेक्शन में हुए बदलावों की खास जानकारी के लिए:

12.1. बदलावों का लॉग देखने के बारे में सलाह

बदलावों को इस तरह मार्क किया जाता है:

सीडीडी
साथ काम करने से जुड़ी ज़रूरी शर्तों में बड़े बदलाव.
Docs
कॉस्मेटिक या बिल्ड से जुड़े बदलाव.

बेहतर तरीके से देखने के लिए, अपने बदलावों की जानकारी वाले यूआरएल में pretty=full और no-merges यूआरएल पैरामीटर जोड़ें.

13. हमसे संपर्क करें

Android के साथ काम करने वाले डिवाइसों के बारे में जानकारी देने वाले फ़ोरम में शामिल होकर, इस बारे में ज़्यादा जानकारी मांगी जा सकती है. इसके अलावा, अगर आपको लगता है कि दस्तावेज़ में किसी समस्या के बारे में नहीं बताया गया है, तो उसके बारे में भी बताया जा सकता है.