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

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

Android 12 के साथ काम करने की परिभाषा
संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2.1. हार्डवेयर

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

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

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

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

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

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

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

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

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

[7.1.4.6/H-0-1] यह बताना ज़रूरी है कि डिवाइस, सिस्टम प्रॉपर्टी graphics.gpu.profiler.support की मदद से जीपीयू प्रोफ़ाइलिंग की सुविधा के साथ काम करता है या नहीं.

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

[7.1.4.6/H-1-1] आउटपुट के तौर पर, ऐसा प्रोटोबस ट्रैक दिखाना ज़रूरी है जो Perfetto दस्तावेज़ में बताए गए जीपीयू काउंटर और जीपीयू रेंडरस्टेज के स्कीमा के मुताबिक हो.
[7.1.4.6/H-1-2] डिवाइस के जीपीयू काउंटर के लिए, gpu 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-1] उपयोगकर्ता के चुने गए सहायता ऐप्लिकेशन को लॉन्च करने का सुझाव दिया जाता है. दूसरे शब्दों में, वह ऐप्लिकेशन जो VoiceInteractionService को लागू करता है या अगर फ़ोरग्राउंड गतिविधि उन लॉन्ग-प्रेस इवेंट को मैनेज नहीं करती है, तो KEYCODE_MEDIA_PLAY_PAUSE या KEYCODE_HEADSETHOOK को दबाकर ACTION_ASSIST को मैनेज करने वाली गतिविधि.
[7.3.1/H-SR-1] 3-ऐक्सिस एक्सलरोमीटर शामिल करने का सुझाव दिया जाता है.

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

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

अगर हैंडहेल्ड डिवाइस में जीपीएस/जीएनएसएस रिसीवर शामिल है और 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-1] हमारा सुझाव है कि आप ऐसे पोज़ सेंसर का इस्तेमाल करें जिसमें छह डिग्री ऑफ़ फ़्रीडम हों.
[7.4.3/H] डिवाइस में ब्लूटूथ और ब्लूटूथ स्मार्ट की सुविधा होनी चाहिए.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2.3. सॉफ़्टवेयर

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Perfetto
- [6.1/H-0-2]* शेल उपयोगकर्ता को /system/bin/perfetto बिनेरी दिखाना ज़रूरी है. यह बिनेरी, 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 traced daemon' को डिफ़ॉल्ट रूप से चालू होना चाहिए (सिस्टम प्रॉपर्टी persist.traced.enable).

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

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

2.2.7.1. मीडिया

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

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

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

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

2.2.7.2. कैमरा

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

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

2.2.7.3. हार्डवेयर

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

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

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

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

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

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

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

2.3. टीवी के लिए ज़रूरी शर्तें

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

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

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

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

2.3.1. हार्डवेयर

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

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

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

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

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

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

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

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

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

[7.6.1/T-1-1] अगर इनमें से किसी भी डेंसिटी का इस्तेमाल किया जाता है, तो कर्नेल और यूज़रस्पेस के लिए कम से कम 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-1] हमारा सुझाव है कि आप 720 पिक्सल और 1080 पिक्सल रिज़ॉल्यूशन वाले वीडियो को 30 फ़्रेम प्रति सेकंड पर H.264 एन्कोडिंग के साथ इस्तेमाल करें.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.3.3. सॉफ़्टवेयर

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.4.1. हार्डवेयर

स्मार्टवॉच पर सेट किए जाने वाले सिस्टम के लिए:

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

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

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

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

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

स्मार्टवॉच पर सेट किए जाने वाले सिस्टम के लिए:

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

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

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

2.4.3. सॉफ़्टवेयर

स्मार्टवॉच पर सेट किए जाने वाले सिस्टम के लिए:

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

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

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

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

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

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

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

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

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

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

स्मार्टवॉच पर सेट किए जाने वाले सिस्टम के लिए:

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

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

स्मार्टवॉच पर सेट किए जाने वाले सिस्टम के लिए:

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

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

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

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

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

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

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

Android डिवाइस में सेट किए गए सिस्टम को 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 डिवाइस में सेट किए गए सिस्टम, OpenGL ES 3.1 के साथ काम करते हैं, तो:

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

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

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

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

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

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

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

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

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

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

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

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

[7.6.1/A-SR-1] बाहरी स्टोरेज पर किए जाने वाले ऑपरेशन के लिए, आई/ओ ओवरहेड को कम करने का सुझाव दिया जाता है. उदाहरण के लिए, 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-1] 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-1] 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 डिवाइस में सेट किए गए सिस्टम में, User HAL प्रॉपर्टी काम करती हैं, तो:

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

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] हर प्रोसेस के यूआईडी के हिसाब से, नॉन-वोलिटाइल स्टोरेज में पढ़े और लिखे गए बाइट की संख्या की जानकारी देना ज़रूरी है. इससे डेवलपर को सिस्टम एपीआई 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 ओपन सोर्स प्रोजेक्ट, Gatekeeper Hardware Abstraction Layer (HAL) और Trusty उपलब्ध कराता है. इनका इस्तेमाल, इस ज़रूरी शर्त को पूरा करने के लिए किया जा सकता है.
[9.11/A-0-4] यह ज़रूरी है कि कुंजी की पुष्टि करने की सुविधा काम करती हो. इसमें, पुष्टि करने के लिए इस्तेमाल होने वाली साइनिंग कुंजी को सुरक्षित हार्डवेयर से सुरक्षित किया गया हो और साइनिंग की प्रोसेस, सुरक्षित हार्डवेयर में की गई हो. पुष्टि करने के लिए इस्तेमाल होने वाली साइनिंग पासकोड को, ज़रूरत के मुताबिक ज़्यादा से ज़्यादा डिवाइसों पर शेयर करना ज़रूरी है. इससे, इन पासकोड का इस्तेमाल डिवाइस आइडेंटिफ़ायर के तौर पर नहीं किया जा सकेगा. इस ज़रूरी शर्त को पूरा करने का एक तरीका यह है कि एक ही पुष्टि करने वाली कुंजी तब तक शेयर की जाए, जब तक किसी दिए गए SKU की कम से कम 1,00,000 यूनिट का प्रॉडक्शन न हो जाए. अगर किसी SKU की 1,00,000 से ज़्यादा यूनिट बनाई जाती हैं, तो हर 1,00,000 यूनिट के लिए, अलग-अलग कुंजी का इस्तेमाल किया जा सकता है.
[9/A-0-1] ‘android.hardware.security.model.compatible’ सुविधा का एलान करना ज़रूरी है.

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

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

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

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

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

2.6.1. हार्डवेयर

जाइरोस्कोप

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.6.2. सॉफ़्टवेयर

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

3. सॉफ़्टवेयर

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

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

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

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

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

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

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

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

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

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

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

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

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

3.2. Soft API Compatibility

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

3.2.1. अनुमतियां

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[C-1-1] यह यहां बताए गए तरीके के मुताबिक, NDK लाइब्रेरी या किसी दूसरे संगठन के मालिकाना हक वाली लाइब्रेरी में नहीं होना चाहिए.

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

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

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

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

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

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

स्क्रीन लेआउट	स्क्रीन की सघनता	ऐप्लिकेशन के लिए कम से कम मेमोरी
Android Watch	120 डीपीआई (ldpi)	32 एमबी
	140 डीपीआई (140dpi)
	160 डीपीआई (एमडीपीआई)
	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() API के ज़रिए, ऐप्लिकेशन के अनुरोध किए गए शॉर्टकट को जोड़ने से पहले, उपयोगकर्ता से अनुमति लेना ज़रूरी है.
[C-2-3] ऐप्लिकेशन के शॉर्टकट पेज पर बताए गए तरीके के मुताबिक, पिन किए गए शॉर्टकट, डाइनैमिक, और स्टैटिक शॉर्टकट के साथ काम करना चाहिए.

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

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

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

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

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

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

3.8.2. विजेट

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

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

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

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

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

3.8.3. सूचनाएं

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.4. Assist API

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

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

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

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

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

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

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

3.8.6. थीम

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[C-3-1] ऐप्लिकेशन के इन स्थितियों में होने पर, गतिविधियों को पिक्चर में पिक्चर मल्टी-विंडो मोड में लॉन्च करना ज़रूरी है:
- एपीआई लेवल 26 या उसके बाद के वर्शन को टारगेट करता हो और android:supportsPictureInPicture का एलान करता हो
- एपीआई लेवल 25 या उससे पहले के वर्शन को टारगेट करता हो और android:resizeableActivity और android:supportsPictureInPicture, दोनों का एलान करता हो.
[C-3-2] setActions() एपीआई के ज़रिए, मौजूदा पीआईपी गतिविधि के मुताबिक, 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 dp चौड़ाई और 135 dp ऊंचाई का फ़्रेम तय करना ज़रूरी है.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.10. सुलभता

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.15. Instant Apps

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[C-1-1] ज़रूरी है कि HEIF (HEIC) इमेज को डिकोड करने की सुविधा काम करती हो.

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

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

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

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

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

[C-1-1] CodecCapabilities की मदद से, YUV420 8:8:8 फ़्लेक्सिबल कलर फ़ॉर्मैट (COLOR_FormatYUV420Flexible) के साथ काम करना ज़रूरी है.
[SR-1] इनपुट के लिए, Surface मोड में RGB888 कलर फ़ॉर्मैट का इस्तेमाल करने का सुझाव दिया जाता है.
[C-1-3] यह ज़रूरी है कि यह प्लैनर या सेमी-प्लानर YUV420 8:8:8 कलर फ़ॉर्मैट में से कम से कम एक में काम करे: COLOR_FormatYUV420PackedPlanar (COLOR_FormatYUV420Planar के बराबर) या COLOR_FormatYUV420PackedSemiPlanar (COLOR_FormatYUV420SemiPlanar के बराबर). हमारा सुझाव है कि यह दोनों में काम करे.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

खास तौर पर:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.2.1. H.263

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

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

5.2.2. H.264

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

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

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

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

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

5.2.3. VP8

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

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

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

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

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

5.2.4. VP9

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

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

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

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

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

[C-2-1] यहां दी गई टेबल में बताई गई एचडी 720p वीडियो डिकोडिंग प्रोफ़ाइल के साथ काम करना ज़रूरी है.
[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 API के ज़रिए एचडीआर प्रोफ़ाइल काम करने का दावा किया जाता है, तो:

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

5.3.6. VP8

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

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

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

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

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

5.3.7. VP9

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

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

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

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

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

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

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

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

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

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

5.3.8. Dolby Vision

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

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

5.3.9. AV1

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

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

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

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

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

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

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

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

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

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

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

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

5.4.3. वीडियो चलाने की जगह बदलने के लिए कैप्चर करना

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.5.4. ऑडियो ऑफ़लोड करना

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

[C-SR-1] AudioTrack gapless API और MediaPlayer के मीडिया कंटेनर के मुताबिक, बिना किसी रुकावट के चलने वाले ऑडियो कॉन्टेंट को ट्रिम करने का सुझाव दिया जाता है.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[C-SR-12] हमारा सुझाव है कि पांच मेज़रमेंट में, लगातार राउंड-ट्रिप के लिए औसत इंतज़ार का समय 50 मिलीसेकंड या उससे कम हो. साथ ही, कम से कम एक काम करने वाले पाथ पर, औसत एब्सोल्यूट डेविएशन 10 मिलीसेकंड से कम हो.

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

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

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

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

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

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

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

रेफ़रंस

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

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

ISO 13818

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

H264 AVC
MPEG-4 SP
MPEG-2

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

ऑडियो कोडेक:

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

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

ISO 13818-7

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

WebVTT

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

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

5.8. Secure Media

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

[C-1-1] Display.FLAG_SECURE के साथ काम करने की जानकारी देना ज़रूरी है.

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

[C-2-1] Miracast जैसे वायरलेस प्रोटोकॉल से कनेक्ट किए गए डिसप्ले के लिए, लिंक को एन्क्रिप्शन के बेहतर तरीके से सुरक्षित करना ज़रूरी है. जैसे, 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 सपोर्ट) शामिल होना चाहिए
यूएसबी की मदद से कनेक्ट किए गए सहायक डिवाइस मोड में, एमआईडीआई की सुविधा काम करनी चाहिए, सेक्शन 7.7

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

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

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

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

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

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

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

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

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

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

[C-3-1] USB ऑडियो क्लास को लागू करना ज़रूरी है.
[C-3-2] यूएसबी ऑडियो क्लास का इस्तेमाल करने वाले यूएसबी होस्ट मोड पोर्ट पर, लगातार पांच बार किए गए मेज़रमेंट में, ऑडियो के लिए राउंड-ट्रिप लेटेंसी का औसत 25 मिलीसेकंड या उससे कम होना चाहिए. साथ ही, औसत का एब्सोल्यूट डिविएशन पांच मिलीसेकंड से कम होना चाहिए. (इसे यूएसबी-3.5 मि॰मी॰ अडैप्टर और ऑडियो लूपबैक डोंगल का इस्तेमाल करके मेज़र किया जा सकता है. इसके अलावा, इनपुट को आउटपुट से कनेक्ट करने वाली पैच केबल के साथ यूएसबी ऑडियो इंटरफ़ेस का इस्तेमाल करके भी मेज़र किया जा सकता है).
[C-SR-6] हमारा सुझाव है कि इनका इस्तेमाल, USB ऑडियो डिवाइसों के साथ किया जाए. इन डिवाइसों में, हर डायरेक्शन में ज़्यादा से ज़्यादा आठ चैनल, 96 किलोहर्ट्ज़ सैंपल रेट, और 24-बिट या 32-बिट डेप्थ के साथ एक साथ I/O की सुविधा होनी चाहिए.
[C-SR-7] हमारा सुझाव है कि आप एमएमएपी पाथ पर AAudio के नेटिव ऑडियो एपीआई का इस्तेमाल करके, ज़रूरी शर्तों के इस ग्रुप को पूरा करें.

अगर डिवाइस में एचडीएमआई पोर्ट शामिल है, तो:

कम से कम एक कॉन्फ़िगरेशन में, 20-बिट या 24-बिट डेप्थ और 192 केएचज़ पर, स्टीरियो और आठ चैनलों में आउटपुट की सुविधा होनी चाहिए. साथ ही, बिट-डेप्थ में कोई कमी या फिर रीसैंपलिंग नहीं होनी चाहिए.

5.11. प्रोसेस नहीं हुए डेटा के लिए कैप्चर

Android में, android.media.MediaRecorder.AudioSource.UNPROCESSED ऑडियो सोर्स की मदद से, बिना प्रोसेस किए गए ऑडियो को रिकॉर्ड करने की सुविधा शामिल है. OpenSL ES में, इसे रिकॉर्ड करने के लिए पहले से सेट किए गए पैरामीटर SL_ANDROID_RECORDING_PRESET_UNPROCESSED का इस्तेमाल करके ऐक्सेस किया जा सकता है.

अगर डिवाइस में सेट किए गए सिस्टम का मकसद, बिना प्रोसेस किए गए ऑडियो सोर्स के साथ काम करना और उसे तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराना है, तो वे:

[C-1-1] android.media.AudioManager प्रॉपर्टी PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED के ज़रिए, सहायता की जानकारी देना ज़रूरी है.
[C-1-2] माइक्रोफ़ोन की परफ़ॉर्मेंस, मध्य फ़्रीक्वेंसी रेंज में, ऐम्प्ल्यट्यूड-बनाम-फ़्रीक्वेंसी के हिसाब से लगभग फ़्लैट होनी चाहिए. खास तौर पर, बिना प्रोसेस किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन के लिए, 100 Hz से 7,000 Hz तक ±10 dB होना चाहिए.
[C-1-3] कम फ़्रीक्वेंसी वाली रेंज में, ऐम्प्ल्यट्यूड लेवल दिखाना ज़रूरी है: खास तौर पर, बिना प्रोसेस किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन के लिए, मीडियम फ़्रीक्वेंसी रेंज की तुलना में 5 z से 100 Hz तक ±20 dB.
[C-1-4] ऐम्प्ल्यट्यूड लेवल, हाई फ़्रीक्वेंसी रेंज में होना चाहिए: खास तौर पर, बिना प्रोसेस किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन के लिए, मिड-फ़्रीक्वेंसी रेंज की तुलना में, 7,000 Hz से 22 KHz तक ±30 dB.
[C-1-5] ऑडियो इनपुट की संवेदनशीलता को इस तरह से सेट करना ज़रूरी है कि 94 dB साउंड प्रेशर लेवल (एसपीएल) पर चलाया गया 1000 Hz साइनसोइडल टोन सोर्स, 16 बिट-सैंपल के लिए 520 आरएमएस (या फ़्लोटिंग पॉइंट/डबल सटीक सैंपल के लिए -36 dB फ़ुल स्केल) के साथ रिस्पॉन्स दे. ऐसा हर उस माइक्रोफ़ोन के लिए करना ज़रूरी है जिसका इस्तेमाल बिना प्रोसेस किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए किया जाता है.
[C-1-6] बिना प्रोसेस किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन का सिग्नल-टू-नॉइज़ रेशियो (एसएनआर) 60 dB या उससे ज़्यादा होना चाहिए. (जबकि एसएनआर को 94 dB SPL और A-वज़्ड, सेल्फ़ नॉइज़ के बराबर SPL के बीच के अंतर के तौर पर मेज़र किया जाता है).
[C-1-7] प्रोसेस न किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन में, 90 dB SPL इनपुट लेवल पर 1 kHz के लिए, कुल हार्मोनिक डिस्टॉर्शन (THD) 1% से कम होना चाहिए.
[C-1-8] लेवल को सही रेंज में लाने के लिए, पाथ में लेवल मल्टीप्लायर के अलावा कोई अन्य सिग्नल प्रोसेसिंग (जैसे, ऑटोमैटिक गेन कंट्रोल, हाई पास फ़िल्टर या गूंज खत्म करने की सुविधा) नहीं होनी चाहिए. दूसरे शब्दों में:
- [C-1-9] अगर किसी वजह से आर्किटेक्चर में कोई सिग्नल प्रोसेसिंग मौजूद है, तो उसे बंद कर दिया जाना चाहिए. साथ ही, सिग्नल पाथ में शून्य देरी या अतिरिक्त इंतज़ार का समय जोड़ा जाना चाहिए.
- [C-1-10] लेवल मल्टीप्लायर को पाथ में शामिल करने की अनुमति है. हालांकि, यह सिग्नल पाथ में देरी या लैटेंसी नहीं ला सकता.

सभी एसपीएल मेज़रमेंट, टेस्ट किए जा रहे माइक्रोफ़ोन के बगल में किए जाते हैं. एक से ज़्यादा माइक्रोफ़ोन कॉन्फ़िगरेशन के लिए, ये ज़रूरी शर्तें हर माइक्रोफ़ोन पर लागू होती हैं.

अगर डिवाइस में android.hardware.microphone का इस्तेमाल किया गया है, लेकिन बिना प्रोसेस किए गए ऑडियो सोर्स का इस्तेमाल नहीं किया जा सकता, तो:

[C-2-1] AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) एपीआई तरीके के लिए, null दिखाना ज़रूरी है, ताकि यह साफ़ तौर पर पता चल सके कि यह तरीका काम नहीं करता.
[C-SR-1] हमारा सुझाव है कि अब भी रिकॉर्डिंग के सोर्स के सिग्नल पाथ के लिए, ज़्यादा से ज़्यादा ज़रूरी शर्तें पूरी करें.

6. डेवलपर टूल और विकल्पों के साथ काम करने की सुविधा

6.1. डेवलपर टूल

डिवाइस में लागू करने के लिए:

[C-0-1] Android SDK में दिए गए Android डेवलपर टूल के साथ काम करना चाहिए.
Android डीबग ब्रिज (adb)
- [C-0-2] Android SDK और AOSP में दिए गए शेल कमांड के मुताबिक, 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 सुविधाओं के साथ काम करे. ddms, adb का इस्तेमाल करता है. इसलिए, ddms के लिए सहायता डिफ़ॉल्ट रूप से बंद होनी चाहिए. हालांकि, जब भी उपयोगकर्ता ऊपर बताए गए तरीके से Android Debug Bridge को चालू करता है, तब ddms के लिए सहायता चालू होनी चाहिए.
Monkey
- [C-0-8] Monkey फ़्रेमवर्क को शामिल करना ज़रूरी है और ऐप्लिकेशन के इस्तेमाल के लिए इसे उपलब्ध कराना ज़रूरी है.
SysTrace
- [C-0-9] यह ज़रूरी है कि Android SDK में बताए गए तरीके से, systrace टूल काम करता हो. Systrace की सुविधा डिफ़ॉल्ट रूप से बंद होनी चाहिए. साथ ही, Systrace को चालू करने के लिए, उपयोगकर्ता के पास कोई ऐसा तरीका होना चाहिए जिसका इस्तेमाल किया जा सके.
Perfetto
- [C-SR-1] शेल उपयोगकर्ता को /system/bin/perfetto बिनेरी दिखाने का सुझाव दिया जाता है. यह बिनेरी, perfetto दस्तावेज़ के मुताबिक cmdline के साथ काम करती है.
- [C-SR-2] यह सुझाव दिया जाता है कि perfetto बाइनरी, इनपुट के तौर पर ऐसा प्रोटोबस कॉन्फ़िगरेशन स्वीकार करे जो perfetto दस्तावेज़ में बताए गए स्कीमा के मुताबिक हो.
- [C-SR-3] यह सुझाव दिया जाता है कि perfetto दस्तावेज़ में बताए गए स्कीमा के मुताबिक, protobuf ट्रैक को आउटपुट के तौर पर लिखने के लिए, बेहतरीन तरीके से काम करने वाली बाइनरी का इस्तेमाल करें.
- [C-SR-4] हमारा सुझाव है कि आप perfetto दस्तावेज़ में बताए गए डेटा सोर्स के साथ-साथ, कम से कम perfetto बाइनरी भी उपलब्ध कराएं.
Low Memory Killer
- [C-0-10] जब किसी ऐप्लिकेशन को लो मेमोरी किलर की वजह से बंद किया जाता है, तो LMK_KILL_OCCURRED_FIELD_NUMBER ऐटम को statsd लॉग में लिखना ज़रूरी है.
टेस्ट हार्नेस मोड अगर डिवाइस में शेल कमांड cmd testharness काम करता है और cmd testharness enable को चलाया जा सकता है, तो:
- [C-2-1] ActivityManager.isRunningInUserTestHarness() के लिए, true दिखाना ज़रूरी है
- [C-2-2] टेस्ट हार्नेस मोड के दस्तावेज़ में बताए गए तरीके के मुताबिक, टेस्ट हार्नेस मोड लागू करना ज़रूरी है.

अगर डिवाइस में लागू किए गए सिस्टम, android.hardware.vulkan.version सुविधा फ़्लैग के ज़रिए Vulkan 1.0 या इसके बाद के वर्शन के साथ काम करने की जानकारी देते हैं, तो:

[C-1-1] ऐप्लिकेशन डेवलपर को जीपीयू डीबग लेयर को चालू/बंद करने का विकल्प देना ज़रूरी है.
[C-1-2] अगर GPU डीबग लेयर चालू हैं, तो vkEnumerateInstanceLayerProperties() और vkCreateInstance() एपीआई तरीकों के साथ काम करने के लिए, डीबग किए जा सकने वाले ऐप्लिकेशन की बेस डायरेक्ट्री में, बाहरी टूल (यानी प्लैटफ़ॉर्म या ऐप्लिकेशन पैकेज का हिस्सा नहीं) से दी गई लाइब्रेरी में लेयर की गिनती करना ज़रूरी है.

6.2. डेवलपर के लिए सेटिंग और टूल

Android में डेवलपर के लिए, ऐप्लिकेशन के डेवलपमेंट से जुड़ी सेटिंग कॉन्फ़िगर करने की सुविधा शामिल है.

डिवाइस पर लागू किए गए डेवलपर के विकल्पों के लिए, एक जैसा अनुभव देना ज़रूरी है. इसके लिए, ये चीज़ें ज़रूरी हैं:

[C-0-1] ऐप्लिकेशन डेवलपमेंट से जुड़ी सेटिंग दिखाने के लिए, android.settings.APPLICATION_DEVELOPMENT_SETTINGS इंटेंट का इस्तेमाल करना ज़रूरी है. Android के अपस्ट्रीम वर्शन में, डिफ़ॉल्ट रूप से डेवलपर के विकल्प मेन्यू को छिपा दिया जाता है. साथ ही, उपयोगकर्ताओं को सेटिंग > डिवाइस के बारे में जानकारी > बिल्ड नंबर मेन्यू आइटम पर सात (7) बार दबाने के बाद, डेवलपर के विकल्प मेन्यू को लॉन्च करने की सुविधा मिलती है.
[C-0-2] ऐप्लिकेशन में, 'डेवलपर के लिए सेटिंग और टूल' को डिफ़ॉल्ट रूप से छिपाना ज़रूरी है.
[C-0-3] डेवलपर के विकल्प चालू करने के लिए, ऐसा सिस्टम उपलब्ध कराना ज़रूरी है जो तीसरे पक्ष के एक ऐप्लिकेशन को दूसरे ऐप्लिकेशन के मुकाबले प्राथमिकता न देता हो. सार्वजनिक तौर पर दिखने वाला ऐसा दस्तावेज़ या वेबसाइट देना ज़रूरी है जिसमें डेवलपर के विकल्प चालू करने का तरीका बताया गया हो. यह दस्तावेज़ या वेबसाइट, Android SDK टूल के दस्तावेज़ों से लिंक की जा सकती हो.
जब डेवलपर के विकल्प चालू हों और उपयोगकर्ता की सुरक्षा को लेकर कोई समस्या हो, तो उपयोगकर्ता को लगातार विज़ुअल सूचना मिलनी चाहिए.
उपयोगकर्ता की सुरक्षा को ध्यान में रखते हुए, मेन्यू को अस्थायी रूप से छिपाकर या बंद करके, डेवलपर के लिए सेटिंग और टूल के मेन्यू के ऐक्सेस पर पाबंदी लगाई जा सकती है.

7. हार्डवेयर के साथ काम करना

अगर किसी डिवाइस में कोई ऐसा हार्डवेयर कॉम्पोनेंट शामिल है जिसके लिए तीसरे पक्ष के डेवलपर के पास एपीआई है, तो:

[C-0-1] डिवाइस में सेट किए गए सिस्टम को, Android SDK टूल के दस्तावेज़ में बताए गए तरीके से एपीआई लागू करना ज़रूरी है.

अगर SDK टूल में मौजूद कोई एपीआई, ऐसे हार्डवेयर कॉम्पोनेंट के साथ इंटरैक्ट करता है जिसे ज़रूरी नहीं बताया गया है और डिवाइस में वह कॉम्पोनेंट मौजूद नहीं है, तो:

[C-0-2] कॉम्पोनेंट एपीआई के लिए, अब भी पूरी क्लास डेफ़िनिशन (SDK टूल के दस्तावेज़ के मुताबिक) ज़रूर दी जानी चाहिए.
[C-0-3] एपीआई के व्यवहार को किसी सही तरीके से, नो-ऑप के तौर पर लागू करना ज़रूरी है.
[C-0-4] SDK दस्तावेज़ में अनुमति होने पर, एपीआई के तरीके को शून्य वैल्यू दिखानी चाहिए.
[C-0-5] एपीआई के तरीके, उन क्लास के लिए कोई कार्रवाई नहीं कर सकते जहां SDK टूल के दस्तावेज़ में, शून्य वैल्यू इस्तेमाल करने की अनुमति नहीं है.
[C-0-6] एपीआई के तरीकों से ऐसे अपवाद नहीं होने चाहिए जिनके बारे में SDK टूल के दस्तावेज़ में नहीं बताया गया है.
[C-0-7] डिवाइस के लागू होने पर, एक ही बिल्ड फ़िंगरप्रिंट के लिए, android.content.pm.PackageManager क्लास पर getSystemAvailableFeatures() और hasSystemFeature(String) तरीकों से, हार्डवेयर कॉन्फ़िगरेशन की सटीक जानकारी लगातार रिपोर्ट की जानी चाहिए.

इन शर्तों के लागू होने की स्थिति का एक उदाहरण, टेलीफ़ोन एपीआई है: फ़ोन के अलावा दूसरे डिवाइसों पर भी, इन एपीआई को बिना किसी काम के लागू किया जाना चाहिए.

7.1. डिसप्ले और ग्राफ़िक

Android में ऐसी सुविधाएं शामिल हैं जो डिवाइस के हिसाब से, ऐप्लिकेशन एसेट और यूज़र इंटरफ़ेस (यूआई) लेआउट को अपने-आप अडजस्ट करती हैं. इससे यह पक्का होता है कि तीसरे पक्ष के ऐप्लिकेशन, अलग-अलग हार्डवेयर कॉन्फ़िगरेशन पर अच्छी तरह से काम करें. Android के साथ काम करने वाले डिसप्ले पर, तीसरे पक्ष के सभी Android ऐप्लिकेशन काम कर सकते हैं. इसलिए, डिवाइस पर इन एपीआई और उनके काम करने के तरीके को ठीक से लागू करना ज़रूरी है. इस बारे में इस सेक्शन में बताया गया है.

इस सेक्शन में दी गई ज़रूरी शर्तों में बताई गई इकाइयों की परिभाषा इस तरह दी गई है:

डायगनल साइज़. डिसप्ले के रोशन हिस्से के दो विपरीत कोनों के बीच की दूरी, इंच में.
डॉट्स पर इंच (डीपीआई). एक इंच के लीनियर हॉरिज़ॉन्टल या वर्टिकल स्पैन में मौजूद पिक्सल की संख्या. जहां डीपीआई वैल्यू दी गई हैं वहां हॉरिज़ॉन्टल और वर्टिकल, दोनों डीपीआई की वैल्यू इस रेंज में होनी चाहिए.
आसपेक्ट रेशियो. स्क्रीन के लंबे डाइमेंशन के पिक्सल का, स्क्रीन के छोटे डाइमेंशन के पिक्सल से अनुपात. उदाहरण के लिए, 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 dp x 320 dp का साइज़ होना ज़रूरी है.
- Configuration.screenLayout के लिए large साइज़ की जानकारी देने वाले डिवाइसों का रिज़ॉल्यूशन कम से कम 640 dp x 480 dp होना चाहिए.
- Configuration.screenLayout के लिए xlarge साइज़ की जानकारी देने वाले डिवाइसों का डाइमेंशन, कम से कम 960 dp x 720 dp होना चाहिए.
[C-0-2] Android SDK के दस्तावेज़ में बताए गए तरीके के मुताबिक, AndroidManifest.xml में <supports-screens> एट्रिब्यूट की मदद से, ऐप्लिकेशन के लिए बताए गए स्क्रीन साइज़ के साथ सही तरीके से काम करना ज़रूरी है.
इसमें Android के साथ काम करने वाले डिसप्ले हो सकते हैं. इनके कोने गोल हो सकते हैं.

अगर डिवाइस में सेट किए गए सिस्टम में UI_MODE_TYPE_NORMAL का इस्तेमाल किया जाता है और उनमें राउंड किए गए कोनों वाला Android डिसप्ले शामिल है, तो:

[C-1-1] यह ज़रूरी है कि इनमें से कम से कम एक ज़रूरी शर्त पूरी की गई हो:
- गोल किए गए कोनों की त्रिज्या 38 डीपी से कम या उसके बराबर हो.
- जब लॉजिकल डिसप्ले के हर कोने पर 15 डीपी x 15 डीपी का बॉक्स ऐंकर किया जाता है, तो स्क्रीन पर हर बॉक्स का कम से कम एक पिक्सल दिखता है.
इसमें उपयोगकर्ता के लिए, रेक्टैंगल आकार के कोनों वाले डिसप्ले मोड पर स्विच करने की सुविधा शामिल होनी चाहिए.

अगर डिवाइस में Android के साथ काम करने वाला ऐसा डिसप्ले शामिल है जो फ़ोल्ड किया जा सकता है या एक से ज़्यादा डिसप्ले पैनल के बीच फ़ोल्डिंग हिंज है और तीसरे पक्ष के ऐप्लिकेशन को रेंडर करने के लिए ऐसा डिसप्ले उपलब्ध कराया जाता है, तो:

[C-2-1] Window Manager Jetpack लाइब्रेरी का इस्तेमाल करने के लिए, extensions API का सबसे नया वर्शन या sidecar API का स्टैबल वर्शन लागू करना ज़रूरी है.

अगर डिवाइस में Android के साथ काम करने वाला ऐसा डिसप्ले शामिल है जो फ़ोल्ड किया जा सकता है या एक से ज़्यादा डिसप्ले पैनल के बीच फ़ोल्डिंग हिंज है और अगर हिंज या फ़ोल्ड, फ़ुलस्क्रीन ऐप्लिकेशन विंडो को पार करता है, तो:

[C-3-1] ऐप्लिकेशन में, एक्सटेंशन या साइडकार एपीआई के ज़रिए, हिंज या फ़ोल्ड की स्थिति, सीमाएं, और स्थिति की जानकारी देना ज़रूरी है.

साइडकार या एक्सटेंशन एपीआई को सही तरीके से लागू करने के बारे में जानने के लिए, Window Manager Jetpack के सार्वजनिक दस्तावेज़ देखें.

7.1.1.2. स्क्रीन का आसपेक्ट रेशियो

Android के साथ काम करने वाले डिसप्ले के लिए, फ़िज़िकल डिसप्ले के आसपेक्ट रेशियो पर कोई पाबंदी नहीं है. हालांकि, तीसरे पक्ष के ऐप्लिकेशन रेंडर किए जाने वाले लॉजिकल डिसप्ले के आसपेक्ट रेशियो को इन ज़रूरी शर्तों को पूरा करना होगा. इस आसपेक्ट रेशियो का पता, view.Display एपीआई और कॉन्फ़िगरेशन एपीआई के ज़रिए दी गई ऊंचाई और चौड़ाई की वैल्यू से लगाया जा सकता है:

[C-0-1] Configuration.uiMode को UI_MODE_TYPE_NORMAL पर सेट करने वाले डिवाइस के लिए, आसपेक्ट रेशियो की वैल्यू 1.86 (लगभग 16:9) से कम या उसके बराबर होनी चाहिए. ऐसा तब तक ज़रूरी है, जब तक ऐप्लिकेशन इनमें से किसी एक शर्त को पूरा न करता हो:
- ऐप्लिकेशन ने android.max_aspect मेटाडेटा वैल्यू के ज़रिए, यह एलान किया है कि यह बड़ी स्क्रीन के आसपेक्ट रेशियो के साथ काम करता है.
- ऐप्लिकेशन, android:resizeableActivity एट्रिब्यूट की मदद से यह एलान करता है कि उसका साइज़ बदला जा सकता है.
- ऐप्लिकेशन, एपीआई लेवल 24 या उसके बाद के वर्शन को टारगेट करता हो और उसमें ऐसा android:maxAspectRatio न दिया गया हो जिससे ऐस्पेक्ट रेशियो पर पाबंदी लगे.
[C-0-3] Configuration.uiMode को UI_MODE_TYPE_WATCH के तौर पर सेट करने वाले डिवाइसों के लिए, आसपेक्ट रेशियो की वैल्यू 1.0 (1:1) पर सेट होनी चाहिए.

7.1.1.3. स्क्रीन की सघनता

Android यूज़र इंटरफ़ेस (यूआई) फ़्रेमवर्क, स्टैंडर्ड लॉजिकल डेंसिटी का एक सेट तय करता है. इससे ऐप्लिकेशन डेवलपर को ऐप्लिकेशन के संसाधनों को टारगेट करने में मदद मिलती है.

[C-0-1] डिफ़ॉल्ट रूप से, डिवाइस के लागू होने पर, DENSITY_DEVICE_STABLE API के ज़रिए DisplayMetrics पर दी गई सूची में मौजूद, Android फ़्रेमवर्क के सिर्फ़ एक डेंसिटी की जानकारी दी जानी चाहिए. यह वैल्यू कभी नहीं बदलनी चाहिए. हालांकि, डिवाइस, डिसप्ले कॉन्फ़िगरेशन में उपयोगकर्ता के किए गए बदलावों (उदाहरण के लिए, डिसप्ले साइज़) के हिसाब से, डिसप्ले के डेंसिटी की जानकारी अलग-अलग दे सकता है. ये बदलाव, डिवाइस के शुरू में बूट होने के बाद किए जाते हैं.
डिवाइस पर लागू होने वाले Android फ़्रेमवर्क की डेंसिटी, डिवाइस की स्क्रीन की डेंसिटी के हिसाब से तय की जानी चाहिए. हालांकि, ऐसा तब तक नहीं किया जाना चाहिए, जब तक कि तय की गई डेंसिटी की वजह से, स्क्रीन का साइज़, काम करने वाले सबसे छोटे साइज़ से कम न हो जाए. अगर डिवाइस पर काम करने वाली सबसे छोटी स्क्रीन के साइज़ (320 dp चौड़ाई) से कम साइज़ वाली स्क्रीन का इस्तेमाल किया जा रहा है, तो डिवाइस पर काम करने वाले Android फ़्रेमवर्क के लिए, डिवाइस पर काम करने वाले सबसे छोटे स्टैंडर्ड 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-1] OpenGL ES 3.1 का इस्तेमाल करने का सुझाव दिया जाता है.
यह ज़रूरी है कि डिवाइस पर OpenGL ES 3.2 वर्शन काम करता हो.

OpenGL ES dEQP टेस्ट को कई टेस्ट सूचियों में बांटा गया है. इनमें से हर सूची में, टेस्ट की तारीख/वर्शन नंबर शामिल होता है. ये external/deqp/android/cts/main/glesXX-master-YYYY-MM-DD.txt पर Android सोर्स ट्री में मौजूद हैं. अगर कोई डिवाइस, खुद से बताए गए लेवल पर OpenGL ES के साथ काम करता है, तो इसका मतलब है कि वह इस लेवल और उससे पहले के सभी टेस्ट की सूचियों में dEQP टेस्ट पास कर सकता है.

अगर डिवाइस में सेट किए गए सिस्टम में OpenGL ES के किसी वर्शन का इस्तेमाल किया जाता है, तो:

[C-2-1] ऐप्लिकेशन में लागू किए गए किसी भी अन्य OpenGL ES एक्सटेंशन की जानकारी, OpenGL ES मैनेज किए जाने वाले एपीआई और नेटिव एपीआई के ज़रिए दी जानी चाहिए. इसके अलावा, उन एक्सटेंशन स्ट्रिंग की जानकारी नहीं दी जानी चाहिए जिन पर ऐप्लिकेशन काम नहीं करता.
[C-2-2] EGL_KHR_image, EGL_KHR_image_base, EGL_ANDROID_image_native_buffer, EGL_ANDROID_get_native_client_buffer, EGL_KHR_wait_sync, EGL_KHR_get_all_proc_addresses, EGL_ANDROID_presentation_time, EGL_KHR_swap_buffers_with_damage, EGL_ANDROID_recordable, और EGL_ANDROID_GLES_layers एक्सटेंशन के साथ काम करना ज़रूरी है.
[C-2-3] android.software.opengles.deqp.level फ़ीचर फ़्लैग के ज़रिए, OpenGL ES dEQP टेस्ट के ज़्यादा से ज़्यादा वर्शन की जानकारी देना ज़रूरी है.
[C-2-4] android.software.opengles.deqp.level फ़ीचर फ़्लैग में बताए गए वर्शन 132383489 (1 मार्च, 2020 से) के साथ काम करना चाहिए.
[C-2-5] टेस्ट की सूचियों में, OpenGL ES के सभी dEQP टेस्ट पास करने होंगे. ये टेस्ट, 132383489 वर्शन से लेकर android.software.opengles.deqp.level फ़ीचर फ़्लैग में बताए गए वर्शन के बीच के सभी वर्शन के लिए होने चाहिए.
[C-SR-2] EGL_KHR_partial_update और OES_EGL_image_external एक्सटेंशन के साथ काम करने का सुझाव दिया जाता है.
getString() तरीके से, टेक्सचर को कम करने वाले किसी भी ऐसे फ़ॉर्मैट की सटीक जानकारी देनी चाहिए जिसका इस्तेमाल किया जा सकता है. आम तौर पर, यह जानकारी वेंडर के हिसाब से अलग-अलग होती है.

अगर डिवाइस में OpenGL ES 3.0, 3.1 या 3.2 का इस्तेमाल किया जा सकता है, तो:

[C-3-1] libGLESv2.so लाइब्रेरी में मौजूद OpenGL ES 2.0 फ़ंक्शन सिंबल के अलावा, इन वर्शन के लिए भी संबंधित फ़ंक्शन सिंबल एक्सपोर्ट करने होंगे.
[C-SR-3] OES_EGL_image_external_essl3 एक्सटेंशन के साथ काम करने का सुझाव दिया जाता है.

अगर डिवाइस में लागू किए गए सिस्टम में OpenGL ES 3.2 का इस्तेमाल किया जा सकता है, तो:

[C-4-1] यह ज़रूरी है कि डिवाइस, OpenGL ES Android एक्सटेंशन पैक के सभी वर्शन के साथ काम करे.

अगर डिवाइस में सेट किए गए सिस्टम में, OpenGL ES Android एक्सटेंशन पैक के सभी वर्शन काम करते हैं, तो:

[C-5-1] android.hardware.opengles.aep फ़ीचर फ़्लैग के ज़रिए, सहायता की पहचान करना ज़रूरी है.

अगर डिवाइस में EGL_KHR_mutable_render_buffer एक्सटेंशन के साथ काम करने की सुविधा मौजूद है, तो:

[C-6-1] EGL_ANDROID_front_buffer_auto_refresh एक्सटेंशन के साथ भी काम करना ज़रूरी है.

7.1.4.2 Vulkan

Android में Vulkan के साथ काम करने की सुविधा शामिल है. यह कम ओवरहेड वाला क्रॉस-प्लैटफ़ॉर्म एपीआई है, जो बेहतर परफ़ॉर्मेंस वाले 3D ग्राफ़िक के लिए इस्तेमाल किया जाता है.

अगर डिवाइस में लागू किए गए सिस्टम, OpenGL ES 3.1 के साथ काम करते हैं, तो:

[C-SR-1] हमारा सुझाव है कि आप Vulkan 1.1 के साथ काम करने की सुविधा शामिल करें.

अगर डिवाइस में स्क्रीन या वीडियो आउटपुट शामिल है, तो:

इसमें Vulkan 1.1 के साथ काम करने की सुविधा शामिल होनी चाहिए.

Vulkan dEQP टेस्ट को कई टेस्ट सूचियों में बांटा गया है. इनमें से हर सूची में, टेस्ट की तारीख/वर्शन शामिल होता है. ये external/deqp/android/cts/main/vk-master-YYYY-MM-DD.txt पर Android सोर्स ट्री में मौजूद हैं. अगर किसी डिवाइस पर, डिवाइस के मालिक ने खुद से बताया है कि Vulkan वर्शन काम करता है, तो इसका मतलब है कि वह डिवाइस इस लेवल और उससे पहले के सभी टेस्ट की सूचियों में dEQP टेस्ट पास कर सकता है.

अगर डिवाइस में Vulkan 1.0 या इसके बाद के वर्शन का इस्तेमाल किया जा रहा है, तो:

[C-1-1] android.hardware.vulkan.level और android.hardware.vulkan.version फ़ीचर फ़्लैग के साथ, सही पूर्णांक वैल्यू की जानकारी देना ज़रूरी है.
[C-1-2] Vulkan नेटिव एपीआई vkEnumeratePhysicalDevices() के लिए, कम से कम एक VkPhysicalDevice एट्रिब्यूट की वैल्यू देना ज़रूरी है.
[C-1-3] सूची में शामिल हर VkPhysicalDevice के लिए, Vulkan 1.0 एपीआई को पूरी तरह से लागू करना ज़रूरी है.
[C-1-4] ऐप्लिकेशन पैकेज की नेटिव लाइब्रेरी डायरेक्ट्री में, libVkLayer*.so नाम वाली नेटिव लाइब्रेरी में मौजूद लेयर की सूची बनाना ज़रूरी है. इसके लिए, Vulkan नेटिव एपीआई vkEnumerateInstanceLayerProperties() और vkEnumerateDeviceLayerProperties() का इस्तेमाल करें.
[C-1-5] ऐप्लिकेशन पैकेज के बाहर की लाइब्रेरी से मिलने वाली लेयर की सूची नहीं दी जानी चाहिए. इसके अलावा, Vulkan API को ट्रैक करने या उसे इंटरसेप्ट करने के अन्य तरीके भी नहीं दिए जाने चाहिए. ऐसा तब तक नहीं किया जाना चाहिए, जब तक ऐप्लिकेशन में android:debuggable एट्रिब्यूट को true के तौर पर सेट न किया गया हो.
[C-1-6] ऐप्लिकेशन को उन सभी एक्सटेंशन स्ट्रिंग की जानकारी देनी चाहिए जिनके साथ Vulkan नेटिव एपीआई काम करते हैं. इसके अलावा , उन एक्सटेंशन स्ट्रिंग की जानकारी नहीं देनी चाहिए जिनके साथ Vulkan नेटिव एपीआई काम नहीं करते.
[C-1-7] VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, और VK_KHR_incremental_present एक्सटेंशन के साथ काम करना ज़रूरी है.
[C-1-8] android.software.vulkan.deqp.level फ़ीचर फ़्लैग के ज़रिए, Vulkan dEQP टेस्ट के ज़्यादा से ज़्यादा वर्शन के बारे में बताना ज़रूरी है.
[C-1-9] android.software.vulkan.deqp.level फ़ीचर फ़्लैग में बताए गए वर्शन के मुताबिक, कम से कम 132317953 वर्शन (1 मार्च, 2019 से) के साथ काम करना चाहिए.
[C-1-10] 132317953 वर्शन और android.software.vulkan.deqp.level फ़ीचर फ़्लैग में बताए गए वर्शन के बीच, टेस्ट की सूचियों में मौजूद सभी Vulkan dEQP टेस्ट पास करने होंगे.
[C-1-11] VK_KHR_video_queue, VK_KHR_video_decode_queue या VK_KHR_video_encode_queue एक्सटेंशन के लिए, काम करने की जानकारी नहीं दी जानी चाहिए.
[C-SR-2] VK_KHR_driver_properties और VK_GOOGLE_display_timing एक्सटेंशन का इस्तेमाल करने का सुझाव दिया जाता है.

अगर डिवाइस में Vulkan 1.0 के साथ काम करने की सुविधा शामिल नहीं है, तो:

[C-2-1] Vulkan के किसी भी फ़ीचर फ़्लैग (उदाहरण के लिए, android.hardware.vulkan.level, android.hardware.vulkan.version) का एलान नहीं किया जाना चाहिए.
[C-2-2] Vulkan नेटिव एपीआई के लिए, किसी भी VkPhysicalDevice को एनोटेट नहीं किया जाना चाहिएvkEnumeratePhysicalDevices().

अगर डिवाइस में Vulkan 1.1 के साथ काम करने की सुविधा शामिल है और Vulkan की किसी भी सुविधा के फ़्लैग का एलान किया गया है, तो:

[C-3-1] SYNC_FD एक्सटर्नल सिग्नल और हैंडल टाइप के साथ-साथ VK_ANDROID_external_memory_android_hardware_buffer एक्सटेंशन के लिए, काम करने की जानकारी देना ज़रूरी है.

7.1.4.3 RenderScript

[C-0-1] डिवाइस में लागू किए गए सिस्टम के लिए, Android RenderScript के साथ काम करना ज़रूरी है. इस बारे में ज़्यादा जानकारी, Android SDK के दस्तावेज़ में दी गई है.

7.1.4.4 2D ग्राफ़िक एक्सेलरेशन

Android में एक ऐसा तरीका शामिल है जिससे ऐप्लिकेशन यह एलान कर सकते हैं कि उन्हें ऐप्लिकेशन, गतिविधि, विंडो या व्यू लेवल पर, 2D ग्राफ़िक के लिए हार्डवेयर ऐक्सेलरेशन की सुविधा चालू करनी है. इसके लिए, उन्हें मेनिफ़ेस्ट टैग android:hardwareAccelerated का इस्तेमाल करना होगा या सीधे तौर पर एपीआई कॉल करने होंगे.

डिवाइस में लागू करने के लिए:

[C-0-1] डिफ़ॉल्ट रूप से, 'हार्डवेयर से तेज़ी लाएं' सुविधा चालू होनी चाहिए. अगर डेवलपर ने android:hardwareAccelerated="false” को सेट करके या सीधे Android View API की मदद से 'हार्डवेयर से तेज़ी लाएं' सुविधा बंद करने का अनुरोध किया है, तो उसे बंद करना ज़रूरी है.
[C-0-2] हार्डवेयर एक्सेलेरेशन के लिए, Android SDK टूल के दस्तावेज़ में बताए गए तरीके के मुताबिक काम करना ज़रूरी है.

Android में TextureView ऑब्जेक्ट शामिल होता है. इसकी मदद से, डेवलपर सीधे तौर पर हार्डवेयर से तेज़ किए गए OpenGL ES टेक्स्चर को, यूज़र इंटरफ़ेस (यूआई) के लेआउट में रेंडरिंग टारगेट के तौर पर इंटिग्रेट कर सकते हैं.

डिवाइस में लागू करने के लिए:

[C-0-3] TextureView API के साथ काम करना ज़रूरी है. साथ ही, यह Android के अपस्ट्रीम वर्शन के साथ एक जैसा व्यवहार करना चाहिए.

7.1.4.5 वाइड-गैमेट डिसप्ले

अगर डिवाइस में सेट किए गए सिस्टम में, Configuration.isScreenWideColorGamut() के ज़रिए वाइड-गैमेट डिसप्ले के साथ काम करने का दावा किया जाता है, तो:

[C-1-1] डिसप्ले का कलर कैलिब्रेट किया गया होना चाहिए.
[C-1-2] डिसप्ले का गैमट, CIE 1931 xyY स्पेस में sRGB कलर गैमट को पूरी तरह कवर करता हो.
[C-1-3] डिसप्ले का गैमट, CIE 1931 xyY स्पेस में कम से कम 90% DCI-P3 होना चाहिए.
[C-1-4] यह ज़रूरी है कि ऐप्लिकेशन, OpenGL ES 3.1 या 3.2 के साथ काम करे और इसकी सही तरीके से शिकायत करे.
[C-1-5] EGL_KHR_no_config_context, EGL_EXT_pixel_format_float, EGL_KHR_gl_colorspace, EGL_EXT_gl_colorspace_scrgb, EGL_EXT_gl_colorspace_scrgb_linear, EGL_EXT_gl_colorspace_display_p3, EGL_EXT_gl_colorspace_display_p3_linear, और EGL_EXT_gl_colorspace_display_p3_passthrough एक्सटेंशन के लिए सहायता उपलब्ध कराने का विज्ञापन दिखाना ज़रूरी है.
[C-SR-1] GL_EXT_sRGB का इस्तेमाल करने का सुझाव दिया जाता है.

इसके उलट, अगर डिवाइस पर लागू किए गए एलिमेंट, वाइड-गैमेट डिसप्ले के साथ काम नहीं करते, तो:

[C-2-1] CIE 1931 xyY स्पेस में sRGB का 100% या उससे ज़्यादा हिस्सा कवर करना चाहिए. हालांकि, स्क्रीन का कलर गैमट तय नहीं है.

7.1.5. लेगसी ऐप्लिकेशन के साथ काम करने वाला मोड

Android में “कंपैटिबिलिटी मोड” की सुविधा होती है. इस मोड में फ़्रेमवर्क, स्क्रीन के 'सामान्य' साइज़ (320dp चौड़ाई) के बराबर के मोड में काम करता है. ऐसा इसलिए किया जाता है, ताकि लेगसी ऐप्लिकेशन को फ़ायदा मिल सके. ये ऐप्लिकेशन, Android के पुराने वर्शन के लिए डिज़ाइन नहीं किए गए हैं. ये वर्शन, स्क्रीन के साइज़ के हिसाब से ऐप्लिकेशन के काम करने की सुविधा से पहले के हैं.

7.1.6. स्क्रीन की टेक्नोलॉजी

Android प्लैटफ़ॉर्म में ऐसे एपीआई शामिल होते हैं जिनकी मदद से ऐप्लिकेशन, Android के साथ काम करने वाले डिसप्ले पर बेहतर ग्राफ़िक रेंडर कर सकते हैं. डिवाइसों में, Android SDK टूल में बताए गए सभी एपीआई काम करने चाहिए. ऐसा तब तक ज़रूरी है, जब तक इस दस्तावेज़ में खास तौर पर अनुमति न दी गई हो.

किसी डिवाइस में सेट किए गए सिस्टम के Android के साथ काम करने वाले सभी डिसप्ले:

[C-0-1] 16-बिट कलर ग्राफ़िक्स को रेंडर करने की क्षमता होनी चाहिए.
यह 24-बिट कलर ग्राफ़िक्स वाले डिसप्ले के साथ काम करना चाहिए.
[C-0-2] ऐनिमेशन रेंडर करने की सुविधा होनी चाहिए.
[C-0-3] पिक्सल आसपेक्ट रेशियो (PAR) 0.9 से 1.15 के बीच होना चाहिए. इसका मतलब है कि पिक्सल का आसपेक्ट रेशियो, स्क्वेयर (1.0) के आस-पास होना चाहिए. इसमें 10 से 15% तक की गड़बड़ी हो सकती है.

7.1.7. दूसरे डिसप्ले

Android में, Android के साथ काम करने वाले सेकंडरी डिसप्ले के लिए सहायता शामिल है. इससे, मीडिया शेयर करने की सुविधाएं चालू की जा सकती हैं. साथ ही, बाहरी डिसप्ले को ऐक्सेस करने के लिए, डेवलपर एपीआई का इस्तेमाल किया जा सकता है.

अगर डिवाइस में वायर, वायरलेस या डिसप्ले के लिए अतिरिक्त कनेक्शन की सुविधा है, तो:

[C-1-1] Android SDK के दस्तावेज़ में बताए गए तरीके के मुताबिक, DisplayManager सिस्टम सेवा और एपीआई को लागू करना ज़रूरी है.

7.2. इनपुट डिवाइस

डिवाइस में लागू करने के लिए:

[C-0-1] यूज़र इंटरफ़ेस (यूआई) एलिमेंट के बीच नेविगेट करने के लिए, इसमें इनपुट का कोई तरीका होना चाहिए. जैसे, टचस्क्रीन या नॉन-टच नेविगेशन.

7.2.1. कीबोर्ड

अगर डिवाइस में तीसरे पक्ष के इनपुट के तरीके के संपादक (आईएमई) वाले ऐप्लिकेशन के लिए सहायता शामिल है, तो:

[C-1-1] android.software.input_methods फ़ीचर फ़्लैग के बारे में बताना ज़रूरी है.
[C-1-2] पूरी तरह से लागू करना ज़रूरी है Input Management Framework
[C-1-3] डिवाइस में पहले से इंस्टॉल किया गया सॉफ़्टवेयर कीबोर्ड होना चाहिए.

डिवाइस में लागू करने के लिए:

[C-0-1] डिवाइस में ऐसा हार्डवेयर कीबोर्ड नहीं होना चाहिए जो android.content.res.Configuration.keyboard में बताए गए किसी एक फ़ॉर्मैट (QWERTY या 12-key) से मेल न खाता हो.
इसमें अन्य सॉफ़्ट कीबोर्ड लागू करने की सुविधा शामिल होनी चाहिए.
इसमें हार्डवेयर कीबोर्ड शामिल हो सकता है.

7.2.2. बिना छुए नेविगेट करने की सुविधा

Android में, टच किए बिना नेविगेट करने के लिए, डी-पैड, ट्रैकबॉल, और व्हील की सुविधा शामिल है.

डिवाइस में लागू करने के लिए:

[C-0-1] android.content.res.Configuration.navigation के लिए सही वैल्यू देना ज़रूरी है.

अगर डिवाइस में बिना छुए नेविगेट करने की सुविधा नहीं है, तो:

[C-1-1] टेक्स्ट चुनने और उसमें बदलाव करने के लिए, यूज़र इंटरफ़ेस का एक ऐसा विकल्प उपलब्ध कराना ज़रूरी है जो इनपुट मैनेजमेंट इंजन के साथ काम करता हो. Android के ओपन सोर्स को लागू करने के लिए, एक चुनने का तरीका शामिल किया गया है. यह तरीका उन डिवाइसों के साथ इस्तेमाल करने के लिए सही है जिनमें नॉन-टच नेविगेशन इनपुट नहीं होते.

7.2.3. मार्गदर्शक कुंजियां

होम, हाल ही के, और वापस जाएं फ़ंक्शन, आम तौर पर किसी खास बटन या टच स्क्रीन के किसी खास हिस्से के साथ इंटरैक्शन करके उपलब्ध कराए जाते हैं. ये फ़ंक्शन, Android नेविगेशन पैराडाइम और इसलिए, डिवाइस पर लागू करने के लिए ज़रूरी हैं:

[C-0-1] आपको उपयोगकर्ताओं को, इंस्टॉल किए गए ऐसे ऐप्लिकेशन को लॉन्च करने का विकल्प देना होगा जिनमें <intent-filter> गतिविधि के साथ ACTION=MAIN और CATEGORY=LAUNCHER या CATEGORY=LEANBACK_LAUNCHER सेट किया गया हो. ऐसा, टेलिविज़न डिवाइस पर ऐप्लिकेशन इस्तेमाल करने के लिए ज़रूरी है. होम फ़ंक्शन, इस उपयोगकर्ता के लिए उपलब्ध सुविधा के तौर पर काम करना चाहिए.
हाल ही में इस्तेमाल किए गए आइटम और 'वापस जाएं' फ़ंक्शन के लिए बटन होने चाहिए.

अगर होम, हाल ही में इस्तेमाल किए गए आइटम या वापस जाने के फ़ंक्शन उपलब्ध हैं, तो:

[C-1-1] अगर इनमें से किसी भी विकल्प को ऐक्सेस किया जा सकता है, तो उसे एक ही कार्रवाई (जैसे, टैप, दो बार क्लिक करना या जेस्चर) से ऐक्सेस किया जा सकता है.
[C-1-2] यह साफ़ तौर पर बताया जाना चाहिए कि कौनसी एक कार्रवाई से हर फ़ंक्शन ट्रिगर होगा. बटन पर दिखने वाला आइकॉन, स्क्रीन के नेविगेशन बार पर सॉफ़्टवेयर आइकॉन दिखाना या डिवाइस के साथ मिलने वाले सेटअप के दौरान, उपयोगकर्ता को सिलसिलेवार निर्देशों के साथ डेमो फ़्लो दिखाना, इस तरह के संकेत के उदाहरण हैं.

डिवाइस में लागू करने के लिए:

[C-SR-1] मेन्यू फ़ंक्शन के लिए इनपुट मैकेनिज़्म न देने का सुझाव दिया जाता है, क्योंकि Android 4.0 के बाद से इसे ऐक्शन बार के लिए इस्तेमाल नहीं किया जाता.

अगर डिवाइस में मेन्यू फ़ंक्शन उपलब्ध कराया जाता है, तो:

[C-2-1] जब ऐक्शन ओवरफ़्लो मेन्यू पॉप-अप खाली न हो और ऐक्शन बार दिख रहा हो, तब ऐक्शन ओवरफ़्लो बटन दिखना चाहिए.
[C-2-2] ऐक्शन बार में ओवरफ़्लो बटन चुनकर दिखाए गए ऐक्शन ओवरफ़्लो पॉप-अप की पोज़िशन में बदलाव नहीं किया जाना चाहिए. हालांकि, मेन्यू फ़ंक्शन चुनकर दिखाए जाने पर, ऐक्शन ओवरफ़्लो पॉप-अप को स्क्रीन पर बदली गई पोज़िशन पर रेंडर किया जा सकता है.

अगर डिवाइस में मेन्यू फ़ंक्शन उपलब्ध नहीं है, तो पुराने वर्शन के साथ काम करने के लिए, ये काम किए जाते हैं:

[C-3-1] targetSdkVersion के 10 से कम होने पर, ऐप्लिकेशन के लिए मेन्यू फ़ंक्शन उपलब्ध कराना ज़रूरी है. यह फ़ंक्शन, किसी फ़िज़िकल बटन, सॉफ़्टवेयर बटन या जेस्चर की मदद से उपलब्ध कराया जा सकता है. इस मेन्यू फ़ंक्शन को तब तक ऐक्सेस किया जा सकता है, जब तक इसे अन्य नेविगेशन फ़ंक्शन के साथ छिपाया नहीं जाता.

अगर डिवाइस में Assist फ़ंक्शन उपलब्ध है, तो:

[C-4-1] अन्य नेविगेशन बटन ऐक्सेस किए जा सकने पर, Assist फ़ंक्शन को सिर्फ़ एक ऐक्शन (जैसे, टैप, डबल-क्लिक या जेस्चर) से ऐक्सेस किया जा सकता है.
[C-SR-2] हमारा सुझाव है कि होम बटन को दबाकर रखने की सुविधा का इस्तेमाल करें, क्योंकि यह इंटरैक्शन के लिए तय किया गया है.

अगर डिवाइस में नेविगेशन बटन दिखाने के लिए, स्क्रीन के किसी अलग हिस्से का इस्तेमाल किया जाता है, तो:

[C-5-1] नेविगेशन बटन, स्क्रीन के उस हिस्से पर होने चाहिए जो ऐप्लिकेशन के लिए उपलब्ध नहीं है. साथ ही, ये बटन ऐप्लिकेशन के लिए उपलब्ध स्क्रीन के हिस्से को छिपाने या उसमें रुकावट पैदा करने वाले नहीं होने चाहिए.
[C-5-2] डिसप्ले का एक हिस्सा, उन ऐप्लिकेशन के लिए उपलब्ध कराना ज़रूरी है जो सेक्शन 7.1.1 में बताई गई ज़रूरी शर्तों को पूरा करते हैं.
[C-5-3] ऐप्लिकेशन को View.setSystemUiVisibility() एपीआई के तरीके से सेट किए गए फ़्लैग का पालन करना चाहिए, ताकि स्क्रीन के इस खास हिस्से (जिसे नेविगेशन बार भी कहा जाता है) को SDK टूल में बताए गए तरीके से सही तरीके से छिपाया जा सके.

[C-6-1] WindowInsets#getMandatorySystemGestureInsets() इसका इस्तेमाल सिर्फ़ होम जेस्चर की पहचान करने वाले एरिया की रिपोर्टिंग के लिए किया जाना चाहिए.
[C-6-2] View#setSystemGestureExclusionRects() के ज़रिए फ़ोरग्राउंड ऐप्लिकेशन से मिले एक्सक्लूज़न रेक्ट में शुरू होने वाले, लेकिन WindowInsets#getMandatorySystemGestureInsets() के बाहर के जेस्चर को नेविगेशन फ़ंक्शन के लिए इंटरसेप्ट नहीं किया जाना चाहिए. ऐसा तब तक नहीं किया जाना चाहिए, जब तक एक्सक्लूज़न रेक्ट को एक्सक्लूज़न की तय सीमा के अंदर रखा जाता है. इस सीमा के बारे में View#setSystemGestureExclusionRects() के दस्तावेज़ में बताया गया है.
[C-6-3] अगर फ़ोरग्राउंड ऐप्लिकेशन को पहले कोई MotionEvent.ACTION_DOWN इवेंट भेजा गया था, तो सिस्टम जेस्चर के लिए टच को इंटरसेप्ट करने के बाद, फ़ोरग्राउंड ऐप्लिकेशन को MotionEvent.ACTION_CANCEL इवेंट भेजना ज़रूरी है.
[C-6-4] उपयोगकर्ता को स्क्रीन पर बटन के आधार पर नेविगेट करने की सुविधा देनी चाहिए. उदाहरण के लिए, सेटिंग में.
होम फ़ंक्शन को स्क्रीन के मौजूदा ओरिएंटेशन के सबसे नीचे से ऊपर की ओर स्वाइप करके उपलब्ध कराया जाना चाहिए.
हाल ही में इस्तेमाल किए गए ऐप्लिकेशन देखने की सुविधा, होम जेस्चर वाले हिस्से से ऊपर की ओर स्वाइप करके और रिलीज़ करने से पहले दबाकर चालू की जानी चाहिए.
WindowInsets#getMandatorySystemGestureInsets() में शुरू होने वाले जेस्चर पर, फ़ोरग्राउंड ऐप्लिकेशन के View#setSystemGestureExclusionRects() के ज़रिए दिए गए एक्सक्लूज़न रीक्ट का असर नहीं पड़ना चाहिए.

अगर स्क्रीन के मौजूदा ओरिएंटेशन के बाएं और दाएं किनारों पर, कहीं भी नेविगेशन फ़ंक्शन दिया गया है, तो:

[C-7-1] नेविगेशन फ़ंक्शन 'वापस जाएं' होना चाहिए. साथ ही, इसे स्क्रीन के मौजूदा ओरिएंटेशन के बाएं और दाएं, दोनों किनारों से स्वाइप करके उपलब्ध कराया जाना चाहिए.
[C-7-2] अगर बाईं या दाईं ओर, स्वाइप किए जा सकने वाले कस्टम सिस्टम पैनल दिए गए हैं, तो उन्हें स्क्रीन के सबसे ऊपर 1/3 हिस्से में रखा जाना चाहिए. साथ ही, यह साफ़ तौर पर और लगातार दिखना चाहिए कि पैनल को खींचकर लाने पर, ऊपर बताए गए पैनल खुलेंगे, न कि 'वापस जाएं' बटन. उपयोगकर्ता, सिस्टम पैनल को इस तरह कॉन्फ़िगर कर सकता है कि वह स्क्रीन के सबसे ऊपरी एक तिहाई हिस्से के नीचे दिखे. हालांकि, सिस्टम पैनल के लिए एक तिहाई से ज़्यादा हिस्से का इस्तेमाल नहीं किया जाना चाहिए.
[C-7-3] जब फ़ोरग्राउंड ऐप्लिकेशन में, View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT या WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE फ़्लैग सेट हों, तो किनारों से स्वाइप करने पर, AOSP में लागू किए गए तरीके के मुताबिक काम करना चाहिए. इस बारे में SDK में जानकारी दी गई है.
[C-7-4] जब फ़ोरग्राउंड ऐप्लिकेशन में, View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT या WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE फ़्लैग सेट हों, तो स्वाइप किए जा सकने वाले कस्टम सिस्टम पैनल तब तक छिपे होने चाहिए, जब तक उपयोगकर्ता AOSP में लागू किए गए सिस्टम बार (जिसे नेविगेशन और स्टेटस बार भी कहा जाता है) को नहीं दिखाता या उनका कलर ज़्यादा नहीं करता.

7.2.4. टचस्क्रीन इनपुट

Android में कई तरह के पॉइंटर इनपुट सिस्टम के साथ काम करने की सुविधा शामिल है. जैसे, टचस्क्रीन, टच पैड, और फ़ेक टच इनपुट डिवाइस. टचस्क्रीन पर काम करने वाले डिवाइसों पर लागू होने वाले एक्सटेंशन, डिसप्ले से जुड़े होते हैं. इससे उपयोगकर्ता को ऐसा लगता है कि वह स्क्रीन पर मौजूद आइटम को सीधे तौर पर मैनेज कर रहा है. उपयोगकर्ता सीधे तौर पर स्क्रीन को छू रहा है, इसलिए सिस्टम को उन ऑब्जेक्ट के बारे में बताने के लिए, किसी और सुविधा की ज़रूरत नहीं होती जिनमें बदलाव किया जा रहा है.

डिवाइस में लागू करने के लिए:

इसमें किसी तरह का पॉइंटर इनपुट सिस्टम होना चाहिए (माउस जैसा या टच).
यह पूरी तरह से स्वतंत्र रूप से ट्रैक किए गए पॉइंटर के साथ काम करना चाहिए.

अगर डिवाइस में, Android के साथ काम करने वाले मुख्य डिसप्ले पर टचस्क्रीन (सिंगल-टच या बेहतर) शामिल है, तो:

[C-1-1] Configuration.touchscreen एपीआई फ़ील्ड के लिए, TOUCHSCREEN_FINGER की जानकारी देना ज़रूरी है.
[C-1-2] android.hardware.touchscreen और android.hardware.faketouch फ़ीचर फ़्लैग के बारे में बताना ज़रूरी है.

अगर डिवाइस में ऐसी टचस्क्रीन है जो Android के साथ काम करने वाले मुख्य डिसप्ले पर, एक से ज़्यादा टच को ट्रैक कर सकती है, तो:

[C-2-1] डिवाइस पर मौजूद टचस्क्रीन के टाइप के हिसाब से, सही फ़ीचर फ़्लैग android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct, android.hardware.touchscreen.multitouch.jazzhand की जानकारी देना ज़रूरी है.

अगर डिवाइस के लागू होने की प्रोसेस में, 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)
डी-पैड अप¹ डी-पैड डाउन¹	0x01 0x0039³	AXIS_HAT_Y⁴
डी-पैड बाईं ओर1 डी-पैड दाईं ओर¹	0x01 0x0039³	AXIS_HAT_X⁴
लेफ़्ट शोल्डर बटन¹	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
राइट शोल्डर बटन¹	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
लेफ़्ट स्टिक क्लिक¹	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
राइट स्टिक क्लिक¹	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
वापस जाएं¹	0x0c 0x0224	KEYCODE_BACK (4)

1 KeyEvent

2 ऊपर बताए गए एचआईडी के इस्तेमाल की जानकारी, गेमपैड सीए (0x01 0x0005) में दी जानी चाहिए.

3 इस इस्तेमाल के लिए, लॉजिकल तौर पर कम से कम 0 और ज़्यादा से ज़्यादा 7, फ़िज़िकल तौर पर कम से कम 0 और ज़्यादा से ज़्यादा 315, डिग्री में यूनिट, और रिपोर्ट का साइज़ 4 होना चाहिए. लॉजिकल वैल्यू को वर्टिकल ऐक्सिस से, घड़ी की सुई के घूमने की दिशा में घुमाने के तौर पर तय किया गया है. उदाहरण के लिए, लॉजिकल वैल्यू 0 का मतलब है कि कोई घुमाव नहीं हुआ है और अप बटन दबाया गया है. वहीं, लॉजिकल वैल्यू 1 का मतलब है कि 45 डिग्री का घुमाव हुआ है और अप और लेफ़्ट बटन, दोनों दबाए गए हैं.

4 MotionEvent

ऐनलॉग कंट्रोल¹	एचआईडी का इस्तेमाल	Android बटन
लेफ़्ट ट्रिगर	0x02 0x00C5	AXIS_LTRIGGER
राइट ट्रिगर	0x02 0x00C4	AXIS_RTRIGGER
लेफ़्ट जॉयस्टिक	0x01 0x0030 0x01 0x0031	AXIS_X AXIS_Y
राइट जॉयस्टिक	0x01 0x0032 0x01 0x0035	AXIS_Z AXIS_RZ

एक MotionEvent

7.2.7. रिमोट कंट्रोल

डिवाइस के हिसाब से ज़रूरी शर्तों के बारे में जानने के लिए, सेक्शन 2.3.1 देखें.

7.3. सेंसर

अगर डिवाइस में किसी खास तरह का सेंसर शामिल है, जिसके लिए तीसरे पक्ष के डेवलपर के पास एपीआई है, तो डिवाइस में उस एपीआई को लागू करना ज़रूरी है. इसके लिए, Android SDK टूल के दस्तावेज़ और सेंसर के बारे में Android के ओपन सोर्स दस्तावेज़ में दिया गया तरीका अपनाएं.

डिवाइस में लागू करने के लिए:

[C-0-1] android.content.pm.PackageManager क्लास के हिसाब से, सेंसर की मौजूदगी या अनुपस्थिति के बारे में सटीक जानकारी देना ज़रूरी है.
[C-0-2] SensorManager.getSensorList() और मिलते-जुलते तरीकों की मदद से, काम करने वाले सेंसर की सटीक सूची दिखानी चाहिए.
[C-0-3] अन्य सभी सेंसर एपीआई के लिए, सही तरीके से काम करना चाहिए. उदाहरण के लिए, जब ऐप्लिकेशन, सुनने वालों को रजिस्टर करने की कोशिश करते हैं, तो true या false को ज़रूरत के हिसाब से दिखाना. साथ ही, जब संबंधित सेंसर मौजूद न हों, तो सेंसर सुनने वालों को कॉल न करना वगैरह.

अगर डिवाइस में किसी खास तरह का सेंसर शामिल है, जिसके लिए तीसरे पक्ष के डेवलपर के पास एपीआई है, तो:

[C-1-1] Android SDK टूल के दस्तावेज़ में बताए गए हर सेंसर टाइप के लिए, सभी सेंसर मेज़रमेंट की रिपोर्ट भेजना ज़रूरी है. इसके लिए, इंटरनैशनल सिस्टम ऑफ़ यूनिट (मेट्रिक) की सही वैल्यू का इस्तेमाल करना होगा.
[C-1-2] सेंसर डेटा को 100 मिलीसेकंड + 2 * sample_time से ज़्यादा इंतज़ार के साथ रिपोर्ट करना ज़रूरी है. ऐसा तब करना होगा, जब ऐप्लिकेशन प्रोसेसर चालू हो और सेंसर स्ट्रीम के लिए, ज़्यादा से ज़्यादा इंतज़ार का अनुरोध 0 मिलीसेकंड हो. इस समय में, फ़िल्टर करने में लगने वाला समय शामिल नहीं है.
[C-1-3] सेंसर चालू होने के 400 मिलीसेकंड + 2 * sample_time के अंदर, सेंसर के पहले सैंपल की जानकारी देना ज़रूरी है. इस सैंपल के लिए, सटीक होने की वैल्यू 0 हो सकती है.
[C-1-4] Android SDK दस्तावेज़ में बताए गए किसी भी एपीआई को कंटिन्यूअस सेंसर के तौर पर इस्तेमाल करने के लिए, डिवाइस में लागू किए गए एपीआई को समय-समय पर डेटा सैंपल उपलब्ध कराने होंगे. इन सैंपल में, जितटर 3% से कम होना चाहिए. जितटर को, लगातार होने वाले इवेंट के बीच, रिपोर्ट किए गए टाइमस्टैंप की वैल्यू के अंतर के स्टैंडर्ड डेविएशन के तौर पर परिभाषित किया जाता है.
[C-1-5] यह पक्का करना ज़रूरी है कि सेंसर इवेंट स्ट्रीम, डिवाइस के सीपीयू को निलंबित होने या निलंबित होने के बाद फिर से चालू होने से न रोके.
[C-1-6] Android SDK टूल के दस्तावेज़ में बताए गए मुताबिक, इवेंट के समय की जानकारी, नैनोसेकंड में देनी ज़रूरी है. इससे, इवेंट के होने का समय पता चलता है. साथ ही, यह जानकारी SystemClock.elapsedRealtimeNano() घड़ी के साथ सिंक होती है.
[C-SR-1] टाइमस्टैंप सिंक करने में होने वाली गड़बड़ी 100 मिलीसेकंड से कम होनी चाहिए. साथ ही, यह गड़बड़ी एक मिलीसेकंड से कम होनी चाहिए.
जब कई सेंसर चालू होते हैं, तो बिजली की खपत, अलग-अलग सेंसर की बिजली की खपत के कुल योग से ज़्यादा नहीं होनी चाहिए.

ऊपर दी गई सूची पूरी नहीं है. सेंसर के लिए, 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-2] हमारा सुझाव है कि आप यह पक्का करें कि ऐक्सीलेरोमीटर, गायरोस्कोप, और मैग्नेटोमीटर की रिलेटिव पोज़िशन एक जैसी हो. इससे, अगर डिवाइस को बदला जा सकता है, जैसे कि फ़ोल्ड किया जा सकता है, तो सेंसर ऐक्सिस, डिवाइस के सभी संभावित बदलावों के दौरान, सेंसर कोऑर्डिनेट सिस्टम के साथ अलाइन और एक जैसा बना रहता है.

7.3.1. एक्सलरोमीटर

डिवाइस में लागू करने के लिए:

[C-SR-1] 3-ऐक्सिस एक्सलरोमीटर शामिल करने का सुझाव दिया जाता है.

अगर डिवाइस में 3-ऐक्सिस एक्सलरोमीटर शामिल है, तो:

[C-1-1] कम से कम 50 हर्ट्ज़ तक की फ़्रीक्वेंसी वाले इवेंट की रिपोर्टिंग करनी चाहिए.
[C-1-2] TYPE_ACCELEROMETER सेंसर को लागू करना और उसके बारे में जानकारी देना ज़रूरी है.
[C-1-3] Android API में बताए गए Android सेंसर कोऑर्डिनेट सिस्टम के मुताबिक काम करना ज़रूरी है.
[C-1-4] यह ज़रूरी है कि यह किसी भी अक्ष पर, गुरुत्वाकर्षण के चार गुना(4g) या उससे ज़्यादा तक के फ़्रीफ़ॉल को मेज़र कर सके.
[C-1-5] का रिज़ॉल्यूशन कम से कम 12-बिट होना चाहिए.
[C-1-6] का स्टैंडर्ड डेविएशन 0.05 मीटर/सेकंड^ से ज़्यादा नहीं होना चाहिए. यहां स्टैंडर्ड डेविएशन का हिसाब, हर अक्ष के आधार पर लगाया जाना चाहिए. इसके लिए, कम से कम तीन सेकंड के दौरान इकट्ठा किए गए सैंपल का इस्तेमाल करना चाहिए. सैंपल इकट्ठा करने की दर सबसे तेज़ होनी चाहिए.
[C-SR-2] TYPE_SIGNIFICANT_MOTION कंपोज़िट सेंसर को लागू करने का सुझाव दिया जाता है.
[C-SR-3] TYPE_ACCELEROMETER_UNCALIBRATED सेंसर को लागू करने और उसकी जानकारी देने का सुझाव दिया जाता है. हमारा सुझाव है कि Android डिवाइसों को इस ज़रूरी शर्त को पूरा करना चाहिए, ताकि वे आने वाले समय में प्लैटफ़ॉर्म के उस रिलीज़ पर अपग्रेड कर सकें जहां यह ज़रूरी हो सकता है.
Android SDK टूल के दस्तावेज़ में बताए गए तरीके के मुताबिक, TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER कंपोजिट सेंसर लागू करने चाहिए.
कम से कम 200 हर्ट्ज़ तक के इवेंट की रिपोर्ट करनी चाहिए.
इसका रिज़ॉल्यूशन कम से कम 16-बिट होना चाहिए.
अगर लाइफ़ साइकल के दौरान प्रॉपर्टी में बदलाव होता है और उन्हें कैलिब्रेट किया जाता है, तो डिवाइस के रीबूट होने के बीच, कैलिब्रेशन पैरामीटर को बनाए रखा जाना चाहिए.
तापमान के हिसाब से अडजस्ट होना चाहिए.

अगर डिवाइस में 3-ऐक्सिस एक्सलरोमीटर और TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER में से कोई एक कंपोजिट सेंसर लागू किया गया है, तो:

[C-2-1] इनकी कुल बिजली खपत हमेशा 4 एमडब्ल्यू से कम होनी चाहिए.
डिवाइस के डाइनैमिक या स्टैटिक होने पर, हर एक काफ़ी कम होना चाहिए. जैसे, 2 mW और 0.5 mW से कम.

अगर डिवाइस में 3-ऐक्सिस एक्सलरोमीटर और 3-ऐक्सिस जाइरोस्कोप सेंसर शामिल है, तो:

[C-3-1] TYPE_GRAVITY और TYPE_LINEAR_ACCELERATION कंपोज़िट सेंसर का होना ज़रूरी है.
[C-SR-4] TYPE_GAME_ROTATION_VECTOR कंपोज़िट सेंसर को लागू करने का सुझाव दिया जाता है.

अगर डिवाइस में 3-ऐक्सिस एक्सलरोमीटर, 3-ऐक्सिस जाइरोस्कोप सेंसर, और मैग्नेटोमीटर सेंसर शामिल हैं, तो:

[C-4-1] TYPE_ROTATION_VECTOR कंपोज़िट सेंसर का होना ज़रूरी है.

7.3.2. मैग्नेटोमीटर

डिवाइस में लागू करने के लिए:

[C-SR-1] 3-ऐक्सिस मैग्नेटोमीटर (कंपास) शामिल करने का सुझाव दिया जाता है.

अगर डिवाइस में 3-ऐक्सिस मैग्नेटोमीटर शामिल है, तो:

[C-1-1] TYPE_MAGNETIC_FIELD सेंसर का होना ज़रूरी है.
[C-1-2] यह ज़रूरी है कि डिवाइस कम से कम 10 हर्ट्ज की फ़्रीक्वेंसी तक इवेंट रिपोर्ट कर सके और कम से कम 50 हर्ट्ज तक इवेंट रिपोर्ट करे.
[C-1-3] Android API में बताए गए Android सेंसर कोऑर्डिनेट सिस्टम का पालन करना ज़रूरी है.
[C-1-4] यह ज़रूरी है कि सैचुरेट होने से पहले, हर अक्ष पर -900 µT से +900 µT के बीच मेज़रमेंट किया जा सके.
[C-1-5] मैग्नेटोमीटर को डाइनैमिक (इंजन से जनरेट होने वाले चुंबकीय क्षेत्र) और स्टैटिक (चुंबक से जनरेट होने वाले चुंबकीय क्षेत्र) चुंबकीय क्षेत्रों से दूर रखकर, हार्ड आयरन ऑफ़सेट की वैल्यू 700 µT से कम होनी चाहिए. साथ ही, यह वैल्यू 200 µT से कम होनी चाहिए.
[C-1-6] का रिज़ॉल्यूशन 0.6 µT के बराबर या उससे ज़्यादा होना चाहिए.
[C-1-7] यह ज़रूरी है कि डिवाइस में हार्ड आयरन बायस के लिए, ऑनलाइन कैलिब्रेशन और कंपेसेशन की सुविधा काम करती हो. साथ ही, डिवाइस के रीबूट होने के बीच कंपेसेशन पैरामीटर को सेव रखता हो.
[C-1-8] डिवाइस में सॉफ़्ट आयरन कम्पेंसेशन की सुविधा होनी चाहिए. डिवाइस के इस्तेमाल के दौरान या उसके प्रोडक्शन के दौरान, कैलिब्रेशन किया जा सकता है.
[C-1-9] स्टैंडर्ड डेविएशन होना चाहिए. इसका हिसाब, हर अक्ष के आधार पर, कम से कम तीन सेकंड की अवधि में इकट्ठा किए गए सैंपल के हिसाब से लगाया जाता है. सैंपलिंग की सबसे तेज़ दर 1.5 µT से ज़्यादा नहीं होनी चाहिए. स्टैंडर्ड डेविएशन 0.5 µT से ज़्यादा नहीं होना चाहिए.
[C-1-10] TYPE_MAGNETIC_FIELD_UNCALIBRATED सेंसर को लागू करना ज़रूरी है.

अगर डिवाइस में 3-ऐक्सिस मैग्नेटोमीटर, एक्सलरोमीटर सेंसर, और 3-ऐक्सिस जाइरोस्कोप सेंसर शामिल हैं, तो:

[C-2-1] TYPE_ROTATION_VECTOR कंपोज़िट सेंसर का होना ज़रूरी है.

अगर डिवाइस में 3-ऐक्सिस मैग्नेटोमीटर और एक्सलरोमीटर शामिल हैं, तो:

TYPE_GEOMAGNETIC_ROTATION_VECTOR सेंसर का इस्तेमाल किया जा सकता है.

अगर डिवाइस में 3-ऐक्सिस मैग्नेटोमीटर, एक्सलरोमीटर, और TYPE_GEOMAGNETIC_ROTATION_VECTOR सेंसर शामिल हैं, तो:

[C-3-1] यह 10 mW से कम ऊर्जा का इस्तेमाल करता हो.
जब सेंसर को 10 हर्ट्ज़ पर बैच मोड के लिए रजिस्टर किया गया हो, तो यह 3 एमडब्ल्यू से कम ऊर्जा का इस्तेमाल करना चाहिए.

7.3.3. जीपीएस

डिवाइस में लागू करने के लिए:

[C-SR-1] जीपीएस/जीएनएसएस रिसीवर शामिल करने का सुझाव दिया जाता है.

अगर डिवाइस में जीपीएस/जीएनएसएस रिसीवर शामिल है और android.hardware.location.gps फ़ीचर फ़्लैग के ज़रिए, ऐप्लिकेशन को इसकी सुविधा के बारे में बताया गया है, तो:

[C-1-1] LocationManager#requestLocationUpdate के ज़रिए अनुरोध किए जाने पर, जगह की जानकारी के आउटपुट कम से कम 1 हर्ट्ज़ की दर से मिलने चाहिए.
[C-1-2] 0.5 एमबीपीएस या इससे तेज़ डेटा स्पीड वाले इंटरनेट कनेक्शन से कनेक्ट होने पर, खुले आसमान वाली जगहों पर (ज़्यादा सिग्नल, कम मल्टीपाथ, एचडीओपी < 2) 10 सेकंड (पहले फ़िक्स में लगने वाला कम समय) में जगह की जानकारी तय करनी चाहिए. आम तौर पर, इस ज़रूरी शर्त को पूरा करने के लिए, जीपीएस/जीएनएसएस लॉक-ऑन समय को कम करने के लिए, असिस्टेड या अनुमानित जीपीएस/जीएनएसएस तकनीक का इस्तेमाल किया जाता है. असिस्टेंस डेटा में, रेफ़रंस टाइम, रेफ़रंस लोकेशन, और सैटलाइट एफ़ेमेरिस/क्लॉक शामिल होते हैं.
- [C-1-6] जगह की जानकारी का हिसाब लगाने के बाद, डिवाइस को खुले आसमान में अपनी जगह की जानकारी 5 सेकंड के अंदर पता करनी चाहिए. ऐसा तब भी करना होगा, जब जगह की जानकारी का अनुरोध फिर से शुरू किया जाए. यह अनुरोध, जगह की जानकारी का पहला अनुरोध करने के एक घंटे बाद तक किया जा सकता है. भले ही, इसके बाद का अनुरोध, डेटा कनेक्शन के बिना और/या पावर साइकल के बाद किया गया हो.
खुले आसमान में जगह की जानकारी तय करने के बाद, अगर गाड़ी एक जगह पर खड़ी है या एक मीटर प्रति सेकंड स्क्वेयर से कम की रफ़्तार से चल रही है, तो:
- [C-1-3] यह ज़रूरी है कि डिवाइस, कम से कम 95% समय तक, जगह की जानकारी 20 मीटर के अंदर और गति को 0.5 मीटर प्रति सेकंड के अंदर बता सके.
- [C-1-4] एक ही कॉन्स्टेलेशन के कम से कम आठ उपग्रहों को एक साथ ट्रैक और GnssStatus.Callback के ज़रिए रिपोर्ट करना ज़रूरी है.
- एक साथ कम से कम 24 सैटलाइट ट्रैक करने चाहिए. ये सैटलाइट, कई कॉन्स्टेलेशन (जैसे, जीपीएस + कम से कम एक Glonass, Beidou, Galileo) से होने चाहिए.
[C-SR-2] आपातकालीन फ़ोन कॉल के दौरान, GNSS Location Provider API के ज़रिए सामान्य जीपीएस/जीएनएसएस जगह की जानकारी के आउटपुट डिलीवर करने का सुझाव दिया जाता है.
[C-SR-3] हमारा सुझाव है कि ट्रैक किए गए सभी कॉन्स्टेलेशन (जैसा कि GnssStatus मैसेज में बताया गया है) से मिले जीएनएसएस रिसीवर के मेज़रमेंट की रिपोर्ट दी जाए. हालांकि, एसबीएएस को छोड़कर.
[C-SR-4] एजीसी और जीएनएसएस मेज़रमेंट की फ़्रीक्वेंसी की जानकारी देने का सुझाव दिया जाता है.
[C-SR-5] हमारा सुझाव है कि हर जीपीएस/जीएनएसएस की जगह की जानकारी के हिस्से के तौर पर, सटीक अनुमानों के बारे में बताएं. इनमें बियरिंग, स्पीड, और वर्टिकल शामिल हैं.
[C-SR-6] जीएनएसएस रिसीवर के मेज़रमेंट मिलने के तुरंत बाद, उन्हें रिपोर्ट करने का सुझाव दिया जाता है. भले ही, जीपीएस/जीएनएसएस से कैलकुलेट की गई जगह की जानकारी अब तक रिपोर्ट न की गई हो.
[C-SR-7] हमारा सुझाव है कि जीएनएसएस के स्यूडोरेंज और स्यूडोरेंज रेट की जानकारी दें. ये ऐसे रेंज होते हैं जो जगह की जानकारी तय करने के बाद, खुले आसमान में, स्थिर रहने या 0.2 मीटर प्रति सेकंड स्क्वेयर से कम की रफ़्तार से चलने पर, कम से कम 95% समय में जगह की जानकारी 20 मीटर के अंदर और रफ़्तार 0.2 मीटर प्रति सेकंड के अंदर का हिसाब लगाने के लिए काफ़ी होते हैं.

7.3.4. जाइरोस्कोप

डिवाइस में लागू करने के लिए:

[C-SR-1] जाइरोस्कोप सेंसर शामिल करने का सुझाव दिया जाता है.

अगर डिवाइस में 3-ऐक्सिस जाइरोस्कोप शामिल है, तो:

[C-1-1] कम से कम 50 हर्ट्ज़ तक की फ़्रीक्वेंसी वाले इवेंट की रिपोर्टिंग करनी चाहिए.
[C-1-2] TYPE_GYROSCOPE सेंसर को लागू करना ज़रूरी है.
[C-1-4] का रिज़ॉल्यूशन 12 बिट या उससे ज़्यादा होना चाहिए.
[C-1-5] तापमान के हिसाब से अडजस्ट होना चाहिए.
[C-1-6] इस्तेमाल के दौरान, इसे कैलिब्रेट और कंपेसेशन करना ज़रूरी है. साथ ही, डिवाइस के रीबूट होने के बीच कंपेसेशन पैरामीटर को बनाए रखना ज़रूरी है.
[C-1-7] हर हर्ट्ज़ के लिए, वैरिएंस 1e-7 rad^2 / s^2 से ज़्यादा नहीं होना चाहिए (हर हर्ट्ज़ के लिए वैरिएंस या rad^2 / s). वैरिएंस को सैंपलिंग रेट के हिसाब से बदलने की अनुमति है, लेकिन यह वैल्यू से ज़्यादा नहीं होना चाहिए. दूसरे शब्दों में, अगर 1 हर्ट्ज़ के सैंपलिंग रेट पर, घुमाव की दर का अंतर मापा जाता है, तो यह 1e-7 rad^2/s^2 से ज़्यादा नहीं होना चाहिए.
[C-SR-2] हमारा सुझाव है कि जब डिवाइस कमरे के तापमान पर स्थिर हो, तो कैलिब्रेशन में होने वाली गड़बड़ी 0.01 रेडियन/सेकंड से कम हो.
[C-SR-3] TYPE_GYROSCOPE_UNCALIBRATED सेंसर को लागू करने का सुझाव दिया जाता है.
[C-SR-4] 16-बिट या इससे ज़्यादा रिज़ॉल्यूशन का सुझाव दिया जाता है.
कम से कम 200 हर्ट्ज़ तक के इवेंट की रिपोर्ट करनी चाहिए.

अगर डिवाइस में 3-ऐक्सिस जाइरोस्कोप, एक्सलरोमीटर सेंसर, और मैग्नेटोमीटर सेंसर शामिल हैं, तो:

[C-2-1] TYPE_ROTATION_VECTOR कंपोज़िट सेंसर का होना ज़रूरी है.

अगर डिवाइस में 3-ऐक्सिस एक्सलरोमीटर और 3-ऐक्सिस जाइरोस्कोप सेंसर शामिल है, तो:

[C-3-1] TYPE_GRAVITY और TYPE_LINEAR_ACCELERATION कंपोज़िट सेंसर का होना ज़रूरी है.
[C-SR-5] TYPE_GAME_ROTATION_VECTOR कंपोज़िट सेंसर का इस्तेमाल करने का सुझाव दिया जाता है.

7.3.5. बैरोमीटर

डिवाइस में लागू करने के लिए:

[C-SR-1] बैरोमीटर (एंबियंट एयर प्रेशर सेंसर) शामिल करने का सुझाव दिया जाता है.

अगर डिवाइस में बैरोमीटर शामिल है, तो:

[C-1-1] TYPE_PRESSURE सेंसर को लागू करना और उसके बारे में जानकारी देना ज़रूरी है.
[C-1-2] यह ज़रूरी है कि डिवाइस 5 हर्ट्ज़ या उससे ज़्यादा फ़्रीक्वेंसी पर इवेंट डिलीवर कर सके.
[C-1-3] तापमान के हिसाब से अडजस्ट होना चाहिए.
[C-SR-2] यह सुझाव दिया जाता है कि आपके डिवाइस में, 300hPa से 1100hPa के बीच के दबाव के मेज़रमेंट की जानकारी दी जा सके.
यह 1hPa तक सटीक होना चाहिए.
20hPa की रेंज में, 0.12hPa की रिलेटिव सटीक जानकारी होनी चाहिए (समुद्र तल पर ~200 मीटर के बदलाव में ~1 मीटर की सटीक जानकारी के बराबर).

7.3.6. Thermometer

अगर डिवाइस में एंबियंट थर्मामीटर (तापमान सेंसर) शामिल है, तो:

[C-1-1] एंबियंट तापमान सेंसर के लिए SENSOR_TYPE_AMBIENT_TEMPERATURE को ज़रूर तय करना चाहिए. साथ ही, सेंसर को उस जगह के एंबियंट (कमरे/वाहन के केबिन) तापमान को सेल्सियस डिग्री में मेज़र करना चाहिए जहां उपयोगकर्ता डिवाइस से इंटरैक्ट कर रहा है.

अगर डिवाइस में थर्मामीटर सेंसर शामिल है, जो आस-पास के तापमान के अलावा किसी और तापमान को मापता है, जैसे कि सीपीयू का तापमान, तो:

[C-2-1] तापमान मापने वाले सेंसर के लिए, SENSOR_TYPE_AMBIENT_TEMPERATURE को तय नहीं किया जाना चाहिए.

अगर डिवाइस में त्वचा के तापमान को मॉनिटर करने के लिए सेंसर शामिल है, तो:

[C-SR-1] PowerManager.getThermalHeadroom एपीआई का इस्तेमाल करने का सुझाव दिया जाता है.

7.3.7. फ़ोटोमीटर

डिवाइस में फ़ोटोमीटर (स्क्रीन की रोशनी को अपने-आप घटाने-बढ़ाने वाला सेंसर) शामिल हो सकता है.

7.3.8. निकटता सेंसर

डिवाइस में सेट किए गए सिस्टम में प्रॉक्सिमिटी सेंसर शामिल हो सकता है.

अगर डिवाइस में प्रॉक्सिमिटी सेंसर शामिल है और वह सिर्फ़ “पास” या “दूर” के तौर पर जानकारी देता है, तो:

[C-1-1] किसी ऑब्जेक्ट की निकटता को उसी दिशा में मेज़र करना चाहिए जिस दिशा में स्क्रीन है. इसका मतलब है कि प्रॉक्सिमिटी सेंसर को स्क्रीन के आस-पास मौजूद ऑब्जेक्ट का पता लगाने के लिए ऑर्डर करना ज़रूरी है. इस तरह के सेंसर का मुख्य मकसद, उपयोगकर्ता के इस्तेमाल में मौजूद फ़ोन का पता लगाना होता है. अगर डिवाइस में किसी अन्य ओरिएंटेशन के साथ प्रोक्सिमिटी सेंसर शामिल है, तो उसे इस एपीआई के ज़रिए ऐक्सेस नहीं किया जा सकता.
[C-1-2] सटीक जानकारी देने के लिए, 1 बिट या उससे ज़्यादा की जानकारी होनी चाहिए.
[C-1-3] नियर रीडिंग के तौर पर 0 सेंटीमीटर और फ़ार रीडिंग के तौर पर 5 सेंटीमीटर का इस्तेमाल करना ज़रूरी है.
[C-1-4] ज़्यादा से ज़्यादा पांच रेंज और रिज़ॉल्यूशन की जानकारी देना ज़रूरी है.

7.3.9. हाई फ़िडेलिटी सेंसर

अगर डिवाइस में, इस सेक्शन में बताए गए तौर पर बेहतर क्वालिटी वाले सेंसर शामिल हैं और उन्हें तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराया जाता है, तो:

[C-1-1] android.hardware.sensor.hifi_sensors फ़ीचर फ़्लैग के ज़रिए, सुविधा की पहचान करना ज़रूरी है.

अगर डिवाइस में लागू किए गए सिस्टम में android.hardware.sensor.hifi_sensors का एलान किया जाता है, तो:

[C-2-1] TYPE_ACCELEROMETER सेंसर का होना ज़रूरी है, जो:
- मेज़रमेंट की रेंज कम से कम -8g से +8g के बीच होनी चाहिए. साथ ही, कम से कम -16g से +16g के बीच मेज़रमेंट रेंज रखने का सुझाव दिया जाता है.
- इसका मेज़रमेंट रिज़ॉल्यूशन कम से कम 2048 LSB/g होना चाहिए.
- मेज़रमेंट फ़्रीक्वेंसी कम से कम 12.5 हर्ट्ज़ या उससे कम होनी चाहिए.
- मेज़रमेंट फ़्रीक्वेंसी 400 हर्ट्ज़ या इससे ज़्यादा होनी चाहिए. साथ ही, SensorDirectChannel RATE_VERY_FAST के साथ काम करना चाहिए.
- मेज़रमेंट नॉइज़ 400 μg/√Hz से ज़्यादा नहीं होना चाहिए.
- इस सेंसर के लिए, बिना 'जागने' वाले फ़ॉर्म को लागू करना ज़रूरी है. साथ ही, यह फ़ॉर्म कम से कम 3,000 सेंसर इवेंट को बफ़र करने की सुविधा के साथ होना चाहिए.
- बैचिंग के दौरान, डिवाइस की बिजली की खपत 3 mW से ज़्यादा नहीं होनी चाहिए.
- [C-SR-1] हमारा सुझाव है कि 3dB मेज़रमेंट बैंडविड्थ, कम से कम 80% नक्विस्ट फ़्रीक्वेंसी हो. साथ ही, इस बैंडविड्थ में व्हाइट नॉइज़ स्पेक्ट्रम हो.
- कमरे के तापमान पर जांचे गए एक्सेलरेशन रैंडम वॉक की वैल्यू 30 μg √Hz से कम होनी चाहिए.
- तापमान के हिसाब से, बायस में बदलाव ≤ +/- 1 mg/°C होना चाहिए.
- सबसे अच्छी फ़िट लाइन की गैर-लीनियरिटी 0.5% से कम होनी चाहिए. साथ ही, तापमान के हिसाब से सेंसिटिविटी में होने वाला बदलाव 0.03%/C° से कम होना चाहिए.
- क्रॉस-ऐक्सिस सेंसिटिविटी 2.5 % से कम होनी चाहिए. साथ ही, डिवाइस के ऑपरेशन के तापमान की रेंज में क्रॉस-ऐक्सिस सेंसिटिविटी में 0.2% से कम का अंतर होना चाहिए.
[C-2-2] TYPE_ACCELEROMETER की तरह ही क्वालिटी की ज़रूरी शर्तों वाला TYPE_ACCELEROMETER_UNCALIBRATED होना चाहिए.
[C-2-3] TYPE_GYROSCOPE सेंसर होना चाहिए, जो:
- मेज़रमेंट की रेंज कम से कम -1,000 से +1,000 डीपीएस के बीच होनी चाहिए.
- मेज़रमेंट रिज़ॉल्यूशन कम से कम 16 LSB/dps होना चाहिए.
- मेज़रमेंट फ़्रीक्वेंसी कम से कम 12.5 हर्ट्ज़ या उससे कम होनी चाहिए.
- मेज़रमेंट फ़्रीक्वेंसी 400 हर्ट्ज़ या इससे ज़्यादा होनी चाहिए. साथ ही, SensorDirectChannel RATE_VERY_FAST के साथ काम करना चाहिए.
- मेज़रमेंट नॉइज़ 0.014°/s/√Hz से ज़्यादा नहीं होना चाहिए.
- [C-SR-2] हमारा सुझाव है कि 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 से कम होनी चाहिए.
- डिवाइस के ऑपरेशन के तापमान की रेंज में, क्रॉस-ऐक्सिस संवेदनशीलता का वैरिएशन 0.3 % से कम और क्रॉस-ऐक्सिस संवेदनशीलता 4.0% से कम होनी चाहिए.
[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_GEOMAGNETIC_FIELD की तरह ही क्वालिटी की ज़रूरी शर्तों वाला TYPE_MAGNETIC_FIELD_UNCALIBRATED होना चाहिए. इसके अलावा:
- इस सेंसर के लिए, बिना डिवाइस को जगाने वाले फ़ॉर्म को लागू करना ज़रूरी है. साथ ही, यह फ़ॉर्म कम से कम 600 सेंसर इवेंट को बफ़र करने की सुविधा के साथ होना चाहिए.
- [C-SR-3] हमारा सुझाव है कि रिपोर्ट रेट 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] एक ही फ़िज़िकल इवेंट के लिए, Accelerometer, Gyroscope, और Magnetometer से मिले इवेंट के टाइमस्टैंप में 2.5 मिलीसेकंड से ज़्यादा का अंतर नहीं होना चाहिए. एक ही फ़िज़िकल इवेंट के लिए, Accelerometer और Gyroscope से मिले टाइमस्टैंप में 0.25 मिलीसेकंड से ज़्यादा का अंतर नहीं होना चाहिए.
[C-2-14] जाइरोस्कोप सेंसर इवेंट के टाइमस्टैंप, कैमरा सबसिस्टम के टाइमबेस के मुताबिक होने चाहिए. साथ ही, इनमें 1 मिलीसेकंड से ज़्यादा की गड़बड़ी नहीं होनी चाहिए.
[C-2-15] ऊपर दिए गए किसी भी फ़िज़िकल सेंसर पर डेटा उपलब्ध होने के बाद, ऐप्लिकेशन को सैंपल 5 मिलीसेकंड के अंदर डिलीवर करने होंगे.
[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 कार्रवाई लागू करना ज़रूरी है. इस कार्रवाई में, सिर्फ़ क्लास 3 या क्लास 2 बायोमेट्रिक्स के लिए, रजिस्टर करने के एंट्री पॉइंट दिखाए जाने चाहिए.

अगर डिवाइस में पैसिव बायोमेट्रिक्स की सुविधा काम करती है, तो:

[C-5-1] डिफ़ॉल्ट रूप से, पुष्टि करने के लिए एक और चरण ज़रूर होना चाहिए. जैसे, बटन दबाना.
[C-SR-1] हमारा सुझाव है कि आपके ऐप्लिकेशन में ऐसी सेटिंग होनी चाहिए जिससे उपयोगकर्ता, ऐप्लिकेशन की प्राथमिकता को बदल सकें. साथ ही, पुष्टि करने के लिए, उपयोगकर्ताओं को हमेशा पुष्टि करने के लिए कहा जाना चाहिए.
[C-SR-2] हमारा सुझाव है कि पुष्टि करने की कार्रवाई को इस तरह से सुरक्षित किया जाए कि कोई ऑपरेटिंग सिस्टम या कर्नेल, इसे न तो बदल सके और न ही उसका गलत इस्तेमाल कर सके. उदाहरण के लिए, इसका मतलब है कि किसी बटन को दबाकर पुष्टि करने की कार्रवाई, सुरक्षित एलिमेंट (एसई) के सिर्फ़ इनपुट के लिए बने सामान्य-इस्तेमाल वाले इनपुट/आउटपुट (जीपीआईओ) पिन से रूट की जाती है. इस कार्रवाई को बटन को दबाने के अलावा किसी और तरीके से नहीं किया जा सकता.
[C-5-2] इसके अलावा, setConfirmationRequired(boolean) के हिसाब से, पुष्टि के चरण के बिना, पुष्टि करने का फ़्लो लागू करना ज़रूरी है. ऐप्लिकेशन, साइन इन फ़्लो के लिए इसका इस्तेमाल कर सकते हैं.

अगर डिवाइस में एक से ज़्यादा बायोमेट्रिक सेंसर हैं, तो:

[C-SR-3] हमारा सुझाव है कि हर ऑथेंटिकेशन के लिए, सिर्फ़ एक बायोमेट्रिक डेटा की पुष्टि की जाए. उदाहरण के लिए, अगर डिवाइस पर फ़िंगरप्रिंट और चेहरे के सेंसर, दोनों उपलब्ध हैं, तो इनमें से किसी एक की पुष्टि होने के बाद, onAuthenticationSucceeded को भेजा जाना चाहिए.

डिवाइस में सेट किए गए सिस्टम में, तीसरे पक्ष के ऐप्लिकेशन को पासकोड की कुंजियों का ऐक्सेस देने के लिए, ये ज़रूरी हैं:

[C-6-1] इसे नीचे दिए गए सेक्शन में बताई गई तीसरी कैटगरी की ज़रूरी शर्तों को पूरा करना होगा.
[C-6-2] अगर पुष्टि के लिए BIOMETRIC_STRONG की ज़रूरत है या पुष्टि करने के लिए CryptoObject का इस्तेमाल किया जाता है, तो सिर्फ़ तीसरे क्लास का बायोमेट्रिक डेटा सबमिट करना ज़रूरी है.

अगर डिवाइस में सेट किए गए सिस्टम को किसी बायोमेट्रिक सेंसर को क्लास 1 (पहले इसे सुविधा कहा जाता था) के तौर पर इस्तेमाल करना है, तो उन्हें:

[C-1-1] गलत स्वीकार करने की दर 0.002% से कम होनी चाहिए.
[C-1-2] यह ज़रूरी है कि यह बताया जाए कि यह मोड, किसी मुश्किल पिन, पैटर्न या पासवर्ड के मुकाबले कम सुरक्षित हो सकता है. साथ ही, अगर Android बायोमेट्रिक्स टेस्ट प्रोटोकॉल के हिसाब से, किसी दूसरे व्यक्ति के डिवाइस पर फ़ेस अनलॉक की सुविधा इस्तेमाल करने की दर 7% से ज़्यादा है, तो इस मोड को चालू करने से जुड़े जोखिमों के बारे में साफ़ तौर पर बताया जाना चाहिए.
[C-1-9] उपयोगकर्ता को 20 से ज़्यादा बार गलत तरीके से कोशिश करने के बाद, सुझाए गए मुख्य पुष्टि करने के तरीके (जैसे, पिन, पैटर्न, पासवर्ड) के लिए ज़रूर चुनौती देनी चाहिए.साथ ही, बायोमेट्रिक पुष्टि के लिए, 90 सेकंड से कम का बैकऑफ़ समय होना चाहिए. गलत तरीके से कोशिश करने का मतलब है कि कैप्चर की गई क्वालिटी (BIOMETRIC_ACQUIRED_GOOD) अच्छी है, लेकिन वह रजिस्टर की गई बायोमेट्रिक जानकारी से मेल नहीं खाती.
[C-SR-4] अगर Android बायोमेट्रिक्स टेस्ट प्रोटोकॉल के हिसाब से, स्पूफ़ और इंपोज़र स्वीकार करने की दर 7% से ज़्यादा है, तो [C-1-9] में बताई गई बायोमेट्रिक पुष्टि के लिए, गलत कोशिशों की कुल संख्या कम करने का सुझाव दिया जाता है.
[C-1-3] बायोमेट्रिक पुष्टि के लिए, कोशिशों की दर को सीमित करना ज़रूरी है - जहां गलत कोशिश का मतलब है कि कैप्चर की गई क्वालिटी (BIOMETRIC_ACQUIRED_GOOD) ठीक है, लेकिन वह रजिस्टर की गई बायोमेट्रिक जानकारी से मेल नहीं खाती.
[C-SR-5] हमारा सुझाव है कि बायोमेट्रिक वेरिफ़िकेशन के लिए, पांच बार गलत तरीके से कोशिश करने के बाद, कम से कम 30 सेकंड के लिए कोशिश करने की दर को सीमित कर दें. ऐसा [C-1-9] में बताई गई, गलत तरीके से कोशिश करने की ज़्यादा से ज़्यादा संख्या के लिए किया जाना चाहिए. गलत तरीके से कोशिश करने का मतलब है, कैप्चर की गई अच्छी क्वालिटी (BIOMETRIC_ACQUIRED_GOOD) वाली ऐसी कोशिश जो रजिस्टर की गई बायोमेट्रिक जानकारी से मेल नहीं खाती.
[C-SR-6] हमारा सुझाव है कि टीईई में, दर को सीमित करने का पूरा लॉजिक शामिल करें.
[C-1-10] प्राइमरी ऑथेंटिकेशन बैकऑफ़ ट्रिगर होने के बाद, बायोमेट्रिक ऑथेंटिकेशन की सुविधा बंद करनी ज़रूरी है. इस बारे में, सेक्शन 9.11 के [C-0-2] में बताया गया है.
[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] उपयोगकर्ता को पुष्टि करने के लिए, सुझाई गई मुख्य पुष्टि करने की सुविधा (जैसे, पिन, पैटर्न, पासवर्ड) का इस्तेमाल करना ज़रूरी है: a) Android 9 या इसके बाद के वर्शन वाले डिवाइसों के लिए, हर 24 घंटे या उससे कम समय में एक बार या b) Android 8 या उससे पहले के वर्शन से अपग्रेड किए गए डिवाइसों के लिए, हर 72 घंटे या उससे कम समय में एक बार.
[C-1-8] उपयोगकर्ता को पुष्टि करने के लिए, सुझाए गए प्राइमरी तरीके (जैसे: पिन, पैटर्न, पासवर्ड) या क्लास 3 (बेहतर) बायोमेट्रिक्स का इस्तेमाल करने के लिए कहा जाना चाहिए. ऐसा इनमें से किसी एक स्थिति के बाद करना ज़रूरी है:
- चार घंटे तक कोई गतिविधि न होने पर टाइम आउट हो जाएगा या
- बायोमेट्रिक ऑथेंटिकेशन की तीन कोशिशें पूरी न हो पाना.
  - डिवाइस के क्रेडेंशियल की पुष्टि होने के बाद, डिवाइस के इस्तेमाल में न रहने की समयसीमा और पुष्टि न होने की संख्या को रीसेट किया जाना चाहिए.
  - Android 8 या इससे पहले के वर्शन पर डिवाइस में सेट किए गए सिस्टम को C-1-8 से छूट दी जा सकती है.
[C-SR-7] नए डिवाइसों के लिए, [C-1-7] और [C-1-8] में बताई गई पाबंदियों को लागू करने के लिए, Android Open Source Project के फ़्रेमवर्क में दिए गए लॉजिक का इस्तेमाल करने का सुझाव दिया जाता है.
[C-SR-8] हमारा सुझाव है कि डिवाइस पर मेज़र किए गए फ़ॉल्स रिजेक्शन रेट (गलत तरीके से अस्वीकार किए जाने की दर) 10% से कम हो.
[C-SR-9] रजिस्टर की गई हर बायोमेट्रिक जानकारी के लिए, बायोमेट्रिक डेटा का पता चलने से लेकर स्क्रीन अनलॉक होने तक के समय को एक सेकंड से कम रखने का सुझाव दिया जाता है.

अगर डिवाइस में सेट किए गए सिस्टम को किसी बायोमेट्रिक सेंसर को क्लास 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 के कॉन्टेक्स्ट के बाहर, ऐप्लिकेशन प्रोसेसर को पहचान ज़ाहिर करने वाले बायोमेट्रिक डेटा या उससे मिले किसी भी डेटा (जैसे, एम्बेडिंग) को अनक्रिप्ट किए बिना ऐक्सेस करने की अनुमति नहीं दी जानी चाहिए. Android 9 या इससे पहले के वर्शन पर लॉन्च किए गए डिवाइसों को अपग्रेड करने पर, C-2-7 से छूट नहीं मिलती.
[C-2-8] प्रोसेसिंग की सुरक्षित पाइपलाइन होनी चाहिए, ताकि ऑपरेटिंग सिस्टम या कोर में हुए बदलाव से, डेटा को सीधे तौर पर इंजेक्ट करके, उपयोगकर्ता के तौर पर झूठी पुष्टि न की जा सके.

ध्यान दें: एपीआई लेवल 27 पर शिप किए गए डिवाइसों को, सिस्टम सॉफ़्टवेयर अपडेट की मदद से C-2-8 की ज़रूरी शर्त को पूरा करने की ज़रूरत नहीं हो सकती.
[C-SR-10] सभी बायोमेट्रिक मोड के लिए, 'लाइव होने की पुष्टि' की सुविधा और चेहरे की पहचान करने की सुविधा के लिए, 'ध्यान देने की पुष्टि' की सुविधा शामिल करने का सुझाव दिया जाता है.
[C-2-9] बायोमेट्रिक सेंसर को तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराना ज़रूरी है.

अगर डिवाइस में सेट किए गए सिस्टम में, किसी बायोमेट्रिक सेंसर को तीसरे क्लास (पहले इसे बेहतर कहा जाता था) के तौर पर इस्तेमाल करना है, तो:

[C-3-1] को ऊपर बताई गई क्लास 2 की सभी ज़रूरी शर्तें पूरी करनी होंगी. हालांकि, [C-1-7] और [C-1-8] को छोड़कर.
[C-3-2] इसमें हार्डवेयर के साथ काम करने वाला पासकोड स्टोर होना चाहिए.
[C-3-3] Android बायोमेट्रिक्स टेस्ट प्रोटोकॉल के हिसाब से, स्पूफ़ और इंपोस्टर स्वीकार करने की दर 7% से ज़्यादा नहीं होनी चाहिए.
[C-3-4] उपयोगकर्ता को हर 72 घंटे या उससे कम समय में, सुझाई गई मुख्य पुष्टि करने की सुविधा (जैसे, पिन, पैटर्न, पासवर्ड) के लिए ज़रूर चुनौती देनी चाहिए.
[C-3-5] अगर डिवाइस पर तीसरे क्लास के किसी बायोमेट्रिक को फिर से रजिस्टर किया जाता है, तो डिवाइस पर काम करने वाले सभी तीसरे क्लास के बायोमेट्रिक के लिए, Authenticator आईडी को फिर से जनरेट करना ज़रूरी है.
[C-3-6] तीसरे पक्ष के ऐप्लिकेशन के लिए, बायोमेट्रिक तरीके से सुरक्षित की गई पासकोड वाली कुंजियों को चालू करना ज़रूरी है.

अगर डिवाइस में डिसप्ले में मौजूद फ़िंगरप्रिंट सेंसर (UDFPS) है, तो:

[C-SR-11] हमारा सुझाव है कि यूडीएफ़पीएस के टच किए जा सकने वाले हिस्से को, तीन बटन वाले नेविगेशन में रुकावट डालने से रोका जाए. ऐसा इसलिए, क्योंकि कुछ उपयोगकर्ताओं को ऐक्सेस के मकसद से इसकी ज़रूरत पड़ सकती है.

7.3.12. पोज़ सेंसर

डिवाइस में लागू करने के लिए:

हो सकता है कि यह 6 डिग्री ऑफ़ फ़्रीडम वाले पोज़ सेंसर के साथ काम करे.

अगर डिवाइस में सेट किए गए सिस्टम में, पोज़ सेंसर के साथ छह डिग्री ऑफ़ फ़्रीडम का इस्तेमाल किया जाता है, तो:

[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 और इस दस्तावेज़ में, “टेलीफ़ोन” का इस्तेमाल खास तौर पर, जीएसएम या सीडीएमए नेटवर्क के ज़रिए वॉइस कॉल करने और मैसेज भेजने से जुड़े हार्डवेयर के लिए किया गया है. ये वॉइस कॉल, पैकेट-स्विच किए जा सकते हैं या नहीं, लेकिन Android के लिए इन्हें किसी भी डेटा कनेक्टिविटी से अलग माना जाता है. डेटा कनेक्टिविटी को उसी नेटवर्क का इस्तेमाल करके लागू किया जा सकता है. दूसरे शब्दों में, Android की “टेलीफ़ोन” सुविधा और एपीआई, खास तौर पर वॉइस कॉल और एसएमएस के बारे में बताते हैं. उदाहरण के लिए, ऐसे डिवाइस जिन्हें कॉल करने या मैसेज भेजने/पाने की सुविधा नहीं होती उन्हें टेलीफ़ोन डिवाइस नहीं माना जाता. भले ही, वे डेटा कनेक्टिविटी के लिए सेल्युलर नेटवर्क का इस्तेमाल करते हों.

Android का इस्तेमाल उन डिवाइसों पर किया जा सकता है जिनमें टेलीफ़ोन हार्डवेयर शामिल नहीं है. इसका मतलब है कि Android, फ़ोन के अलावा दूसरे डिवाइसों पर भी काम करता है.

अगर डिवाइस में जीएसएम या सीडीएमए टेलीफ़ोनी शामिल है, तो:

[C-1-1] तकनीक के हिसाब से, android.hardware.telephony फ़ीचर फ़्लैग और अन्य सब-फ़ीचर फ़्लैग का एलान करना ज़रूरी है.
[C-1-2] उस टेक्नोलॉजी के लिए, एपीआई की पूरी सहायता लागू करना ज़रूरी है.
आपातकालीन कॉल के दौरान, सभी उपलब्ध मोबाइल सेवाओं (2G, 3G, 4G, 5G वगैरह) का इस्तेमाल किया जा सकता है. भले ही, SetAllowedNetworkTypeBitmap() ने नेटवर्क के टाइप तय किए हों.

अगर डिवाइस में टेलीफ़ोन हार्डवेयर शामिल नहीं है, तो:

[C-2-1] सभी एपीआई को नो-ऑप के तौर पर लागू करना ज़रूरी है.

अगर डिवाइस में eUICC या ई-सिम/एम्बेड किए गए सिम का इस्तेमाल किया जा सकता है और तीसरे पक्ष के डेवलपर के लिए ई-सिम की सुविधा उपलब्ध कराने के लिए, मालिकाना हक वाला कोई तरीका शामिल है, तो:

[C-3-1] EuiccManager API को पूरी तरह से लागू करना ज़रूरी है.

अगर डिवाइस में लागू करने की प्रोसेस, सिस्टम प्रॉपर्टी ro.telephony.iwlan\_operation\_mode को 'लेगसी' पर सेट नहीं करती है, तो:

[C-4-1] जब एक ही NetworkRegistrationInfo इंस्टेंस के लिए, NetworkRegistrationInfo#getTransportType() को 'TRANSPORT_TYPE_WWAN' के तौर पर रिपोर्ट किया जाता है, तो NetworkRegistrationInfo#getAccessNetworkTechnology() के ज़रिए 'NETWORK_TYPE_IWLAN' को रिपोर्ट नहीं किया जाना चाहिए.

अगर डिवाइस में मल्टीमीडिया टेलीफ़ोन सेवा (MMTEL) और रिच कम्यूनिकेशन सेवा (आरसीएस) दोनों सुविधाओं के लिए, एक ही आईपी मल्टीमीडिया सबसिस्टम (आईएमएस) रजिस्ट्रेशन का इस्तेमाल किया जा सकता है और सभी आईएमएस सिग्नल ट्रैफ़िक के लिए, एक ही आईएमएस रजिस्ट्रेशन का इस्तेमाल करने से जुड़ी मोबाइल और इंटरनेट सेवा देने वाली कंपनी की ज़रूरी शर्तों का पालन किया जा सकता है, तो:

[C-5-1] android.hardware.telephony.ims फ़ीचर फ़्लैग के बारे में एलान करना ज़रूरी है. साथ ही, MMTEL और आरसीएस User Capability Exchange API, दोनों के लिए ImsService API को पूरी तरह से लागू करना ज़रूरी है.
[C-5-2] android.hardware.telephony.ims.singlereg सुविधा फ़्लैग का एलान करना ज़रूरी है. साथ ही, SipTransport API, GbaService API, और IRadio 1.6 HAL का इस्तेमाल करके, डिवाइस के लिए खास तौर पर बने बियरर इंंडिकेशन के साथ-साथ, ऑटो कॉन्फ़िगरेशन सर्वर (एसीएस) या IMS कॉन्फ़िगरेशन एपीआई का इस्तेमाल करके, अन्य मालिकाना कॉन्फ़िगरेशन वाले तरीके से प्रोवाइड करने की सुविधा को पूरी तरह से लागू करना ज़रूरी है.

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-1] हमारा सुझाव है कि उपयोगकर्ता को सूचना दी जाए कि किसी इनकमिंग कॉल का जवाब देने पर, चल रहे कॉल को बंद कर दिया जाएगा.

AOSP में, हेड्स-अप सूचना की मदद से इन ज़रूरी शर्तों को पूरा किया जाता है. इससे उपयोगकर्ता को यह पता चलता है कि किसी इनकमिंग कॉल का जवाब देने पर, दूसरा कॉल बंद हो जाएगा.
[C-SR-1] हमारा सुझाव है कि डिफ़ॉल्ट डायलर ऐप्लिकेशन को पहले से लोड करें. यह ऐप्लिकेशन, कॉल लॉग में कॉल लॉग की एंट्री और तीसरे पक्ष के ऐप्लिकेशन का नाम दिखाता है. ऐसा तब होता है, जब तीसरे पक्ष का ऐप्लिकेशन EXTRA_LOG_SELF_MANAGED_CALLS के एक्सट्रा बटन को PhoneAccount से true पर सेट करता है.
[C-SR-2] android.telecom एपीआई के लिए, ऑडियो हेडसेट के KEYCODE_MEDIA_PLAY_PAUSE और KEYCODE_HEADSETHOOK इवेंट को नीचे बताए गए तरीके से मैनेज करने का सुझाव दिया जाता है:
- कॉल के दौरान, मुख्य इवेंट को कुछ समय के लिए दबाने पर, Connection.onDisconnect() कॉल करें.
- आने वाले कॉल के दौरान, मुख्य इवेंट को कुछ समय के लिए दबाने पर, Connection.onAnswer() कॉल करें.
- आने वाले कॉल के दौरान, मुख्य इवेंट को दबाकर रखने पर, Connection.onReject() को कॉल करें.
- CallAudioState को म्यूट करने की स्थिति को टॉगल करें.

7.4.2. आईईईई 802.11 (वाई-फ़ाई)

डिवाइस में लागू करने के लिए:

इसमें 802.11 के एक या उससे ज़्यादा फ़ॉर्मैट के लिए सहायता शामिल होनी चाहिए.

अगर डिवाइस में 802.11 का इस्तेमाल किया जा रहा है और तीसरे पक्ष के ऐप्लिकेशन को इस सुविधा का ऐक्सेस दिया गया है, तो:

[C-1-1] इसके लिए, आपको उससे जुड़ा Android API लागू करना होगा.
[C-1-2] हार्डवेयर फ़ीचर फ़्लैग android.hardware.wifi की जानकारी देना ज़रूरी है.
[C-1-3] SDK के दस्तावेज़ में बताए गए तरीके के मुताबिक, मल्टीकास्ट एपीआई को लागू करना ज़रूरी है.
[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-1-7] जब एसटीए डिसकनेक्ट हो, तब हर स्कैन की शुरुआत में प्रोब रिक्वेस्ट के एमएसी पते और क्रम संख्या को बदलना ज़रूरी है.
[C-1-8] एक ही मैक पते का इस्तेमाल करना ज़रूरी है. स्कैन के बीच में मैक पते को बदलना नहीं चाहिए.
[C-1-9] स्कैन में, प्रोब अनुरोधों के बीच, प्रोब अनुरोध के क्रम की संख्या को सामान्य (क्रम से) के तौर पर दोहराना ज़रूरी है.
[C-1-10] किसी स्कैन की आखिरी प्रोब रिक्वेस्ट और अगले स्कैन की पहली प्रोब रिक्वेस्ट के बीच में, प्रोब रिक्वेस्ट की क्रम संख्या को बदलना ज़रूरी है.
[C-SR-1] हमारा सुझाव है कि एसटीए के ऐक्सेस पॉइंट (एपी) से जुड़ने और जुड़े रहने के दौरान, सभी एसटीए कम्यूनिकेशन के लिए इस्तेमाल किए गए सोर्स एमएसी पते को बदलें.
- डिवाइस को हर उस एसएसआईडी (Passpoint के लिए FQDN) के लिए, अलग-अलग क्रम में लगाए गए मैक पते का इस्तेमाल करना चाहिए जिससे वह संपर्क करता है.
- डिवाइस में उपयोगकर्ता को हर SSID (Passpoint के लिए FQDN) के लिए एमएसी पता बदलने या न बदलने का विकल्प दिया जाना चाहिए. साथ ही, नए वाई-फ़ाई कॉन्फ़िगरेशन के लिए डिफ़ॉल्ट मोड को बदला हुआ होना चाहिए.
[C-SR-2] हमारा सुझाव है कि वे अपने बनाए गए किसी भी एपी के लिए, रैंडम बीएसएसआईडी का इस्तेमाल करें.
- एपी के इस्तेमाल किए गए हर SSID के लिए, एमएसी पता बदला गया होना चाहिए और वही बना रहना चाहिए.
- डिवाइस, उपयोगकर्ता को इस सुविधा को बंद करने का विकल्प दे सकता है. अगर ऐसा विकल्प दिया जाता है, तो रैंडमाइज़ेशन की सुविधा डिफ़ॉल्ट रूप से चालू होनी चाहिए.

अगर डिवाइस में, IEEE 802.11 स्टैंडर्ड के मुताबिक वाई-फ़ाई पावर सेव मोड की सुविधा शामिल है, तो:

जब भी कोई ऐप्लिकेशन 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-3] हमारा सुझाव है कि जब भी कम इंतज़ार वाला लॉक (WIFI_MODE_FULL_LOW_LATENCY) हासिल किया जाए और लागू हो जाए, तो वाई-फ़ाई के राउंड ट्रिप के इंतज़ार को कम करें.

अगर डिवाइस पर वाई-फ़ाई काम करता है और जगह की जानकारी स्कैन करने के लिए वाई-फ़ाई का इस्तेमाल किया जाता है, तो:

[C-2-1] WifiManager.isScanAlwaysAvailable एपीआई के तरीके से, वैल्यू पढ़ने की सुविधा को चालू/बंद करने के लिए, उपयोगकर्ता को एक सुविधा देना ज़रूरी है.

7.4.2.1. Wi-Fi Direct

डिवाइस में लागू करने के लिए:

इसमें वाई-फ़ाई डायरेक्ट (वाई-फ़ाई पीयर-टू-पीयर) की सुविधा शामिल होनी चाहिए.

अगर डिवाइस में वाई-फ़ाई डायरेक्ट की सुविधा काम करती है, तो:

[C-1-1] SDK के दस्तावेज़ में बताए गए तरीके के मुताबिक, उससे जुड़ा Android API लागू करना ज़रूरी है.
[C-1-2] हार्डवेयर की सुविधा android.hardware.wifi.direct के बारे में बताना ज़रूरी है.
[C-1-3] डिवाइस पर वाई-फ़ाई की सुविधा काम करनी चाहिए.
[C-1-4] यह ज़रूरी है कि डिवाइस पर वाई-फ़ाई और वाई-फ़ाई डायरेक्ट, दोनों एक साथ काम करते हों.
[C-SR-1] हमारा सुझाव है कि नए वाई-फ़ाई डायरेक्ट कनेक्शन के लिए, सोर्स एमएसी पते को बदला जाए.

7.4.2.2. वाई-फ़ाई टनल वाला डायरेक्ट लिंक सेटअप करना

डिवाइस में लागू करने के लिए:

इसमें Wi-Fi टनल किए गए डायरेक्ट लिंक सेटअप (TDLS) के लिए सहायता शामिल होनी चाहिए, जैसा कि Android SDK टूल के दस्तावेज़ में बताया गया है.

अगर डिवाइस में TDLS की सुविधा शामिल है और WiFiManager API ने TDLS को चालू किया है, तो:

[C-1-1] WifiManager.isTdlsSupported के ज़रिए, यह ज़रूर बताना होगा कि डिवाइस में टीडीएलएस की सुविधा काम करती है.
TDLS का इस्तेमाल सिर्फ़ तब करना चाहिए, जब यह मुमकिन हो और फ़ायदेमंद हो.
इसमें कुछ हेयुरिस्टिक्स होने चाहिए और जब TDLS की परफ़ॉर्मेंस, वाई-फ़ाई ऐक्सेस पॉइंट से कनेक्ट होने की परफ़ॉर्मेंस से खराब हो, तब इसका इस्तेमाल नहीं किया जाना चाहिए.

7.4.2.3. वाई-फ़ाई अवेयर

डिवाइस में लागू करने के लिए:

इसमें Wi-Fi Aware के लिए सहायता शामिल होनी चाहिए.

अगर डिवाइस में वाई-फ़ाई अवेयर की सुविधा शामिल है और तीसरे पक्ष के ऐप्लिकेशन के लिए इस सुविधा का ऐक्सेस दिया गया है, तो:

[C-1-1] WifiAwareManager एपीआई को SDK टूल के दस्तावेज़ में बताए गए तरीके से लागू करना ज़रूरी है.
[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 स्टैंडर्ड के साथ काम करे. यह स्टैंडर्ड, नेटवर्क डिस्कवरी और नेटवर्क चुनने से जुड़ा है. जैसे, जेनरिक विज्ञापन सेवा (जीएएस) और ऐक्सेस नेटवर्क क्वेरी प्रोटोकॉल (एएनक्यूपी).
[C-1-4] android.hardware.wifi.passpoint फ़ीचर फ़्लैग के बारे में बताना ज़रूरी है.
[C-1-5] पासपॉइंट नेटवर्क ढूंढने, मैच करने, और उनसे जुड़ने के लिए, AOSP के लागू होने का पालन करना ज़रूरी है.
[C-1-6] यह ज़रूरी है कि डिवाइस को कॉन्फ़िगर करने के लिए, कम से कम इन प्रोटोकॉल का इस्तेमाल किया जा सके, जैसा कि Wi-Fi Alliance Passpoint R2 में बताया गया है: EAP-TTLS पुष्टि करने की सुविधा और SOAP-XML.
[C-1-7] Hotspot 2.0 R3 स्पेसिफ़िकेशन में बताए गए तरीके के मुताबिक, एएए सर्वर सर्टिफ़िकेट को प्रोसेस करना ज़रूरी है.
[C-1-8] वाई-फ़ाई पिकर की मदद से, उपयोगकर्ता को प्रावधान करने की सुविधा को कंट्रोल करने की सुविधा होनी चाहिए.
[C-1-9] रीबूट करने के बाद भी, Passpoint कॉन्फ़िगरेशन को सेव रखना ज़रूरी है.
[C-SR-1] नियम और शर्तों को स्वीकार करने की सुविधा काम करती हो, इसका सुझाव दिया जाता है.
[C-SR-2] जगह की जानकारी की सुविधा काम करनी चाहिए.

इसके उलट, अगर डिवाइस में Wi-Fi Passpoint की सुविधा काम नहीं करती है, तो:

[C-2-1] Passpoint से जुड़े WifiManager एपीआई को लागू करने पर, UnsupportedOperationException दिखना चाहिए.

अगर Passpoint को बंद करने के लिए, उपयोगकर्ता के कंट्रोल वाला ग्लोबल स्विच उपलब्ध कराया जाता है, तो इसे लागू करने के लिए:

[C-3-1] Passpoint को डिफ़ॉल्ट रूप से चालू करना ज़रूरी है.

7.4.2.5. वाई-फ़ाई की जगह की जानकारी (वाई-फ़ाई का राउंड ट्रिप टाइम - आरटीटी)

डिवाइस में लागू करने के लिए:

इसमें वाई-फ़ाई लोकेशन की सुविधा शामिल होनी चाहिए.

अगर डिवाइस में वाई-फ़ाई लोकेशन की सुविधा काम करती है और तीसरे पक्ष के ऐप्लिकेशन के लिए इस सुविधा का ऐक्सेस उपलब्ध कराया जाता है, तो:

[C-1-1] WifiRttManager एपीआई को SDK टूल के दस्तावेज़ में बताए गए तरीके से लागू करना ज़रूरी है.
[C-1-2] android.hardware.wifi.rtt फ़ीचर फ़्लैग के बारे में एलान करना ज़रूरी है.
[C-1-3] आरटीटी के हर बर्स्ट के लिए, सोर्स एमएसी पता बदलना ज़रूरी है. ऐसा तब किया जाना चाहिए, जब आरटीटी को चलाने वाले वाई-फ़ाई इंटरफ़ेस को किसी ऐक्सेस पॉइंट से कनेक्ट न किया गया हो.
[C-1-4] 68वें प्रतिशत में, 80 मेगाहर्ट्ज़ की बैंडविड्थ पर, 2 मीटर के अंदर सटीक होना चाहिए. यह वैल्यू, क्युम्युलटिव डिस्ट्रिब्यूशन फ़ंक्शन से कैलकुलेट की जाती है.

7.4.2.6. वाई-फ़ाई Keepalive Offload

डिवाइस में लागू करने के लिए:

इसमें वाई-फ़ाई कीपअलाइव ऑफ़लोड की सुविधा शामिल होनी चाहिए.

अगर डिवाइस में वाई-फ़ाई की keepalive सुविधा के साथ-साथ, तीसरे पक्ष के ऐप्लिकेशन के लिए इस सुविधा का ऐक्सेस भी दिया गया है, तो:

[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() method को true दिखाना चाहिए.

7.4.2.8. एंटरप्राइज़ वाई-फ़ाई सर्वर सर्टिफ़िकेट की पुष्टि करना

अगर वाई-फ़ाई सर्वर सर्टिफ़िकेट की पुष्टि नहीं की गई है या वाई-फ़ाई सर्वर का डोमेन नेम सेट नहीं किया गया है, तो डिवाइस पर ये कार्रवाइयां की जाती हैं:

[C-SR-1] हमारा सुझाव है कि आप उपयोगकर्ता को सेटिंग ऐप्लिकेशन में, Enterprise वाई-फ़ाई नेटवर्क को मैन्युअल तरीके से जोड़ने का विकल्प न दें.

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] SDK टूल के दस्तावेज़ और 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 का इस्तेमाल करके, कान की मशीन के ऑडियो को चलाने की सुविधा के बारे में बताए गए तरीके के मुताबिक, ब्लूटूथ LE और कान की मशीन की प्रोफ़ाइल के साथ काम करने की सुविधा शामिल है, तो:

[C-5-1] BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID) के लिए, true दिखाना ज़रूरी है.

अगर डिवाइस में ब्लूटूथ या ब्लूटूथ लो एनर्जी (LE) की सुविधा शामिल है, तो:

[C-6-1] ब्लूटूथ के ऐसे किसी भी मेटाडेटा (जैसे, स्कैन के नतीजे) के ऐक्सेस पर पाबंदी लगानी चाहिए जिसका इस्तेमाल डिवाइस की जगह की जानकारी पाने के लिए किया जा सकता है. ऐसा तब तक करना चाहिए, जब तक अनुरोध करने वाला ऐप्लिकेशन, फ़ोरग्राउंड/बैकग्राउंड की मौजूदा स्थिति के आधार पर, android.permission.ACCESS_FINE_LOCATION अनुमति की जांच में पास नहीं हो जाता.

अगर डिवाइस में ब्लूटूथ या ब्लूटूथ स्मार्टवॉच के लिए काम करने वाला सिस्टम शामिल है और ऐप्लिकेशन के मेनिफ़ेस्ट में डेवलपर का यह एलान नहीं है कि वे ब्लूटूथ से जगह की जानकारी नहीं ले रहे हैं, तो:

[C-6-2] ब्लूटूथ ऐक्सेस को android.permission.ACCESS_FINE_LOCATION के पीछे रखना ज़रूरी है.

7.4.4. नियर फ़ील्ड कम्यूनिकेशन

डिवाइस में लागू करने के लिए:

इसमें नियर-फ़ील्ड कम्यूनिकेशन (एनएफ़सी) के लिए, ट्रांसीवर और उससे जुड़ा हार्डवेयर शामिल होना चाहिए.
[C-0-1] android.nfc.NdefMessage और android.nfc.NdefRecord एपीआई को लागू करना ज़रूरी है. भले ही, इनमें एनएफ़सी के लिए सहायता शामिल न हो या android.hardware.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 (एनएफ़सी फ़ोरम के मुताबिक)
[C-SR-1] हमारा सुझाव है कि आपके डिवाइस में, एनएफ़सी के इन स्टैंडर्ड का इस्तेमाल करके, एनडीएफ़ई मैसेज के साथ-साथ रॉ डेटा को पढ़ने और लिखने की सुविधा हो. ध्यान दें कि एनएफ़सी स्टैंडर्ड के लिए, 'इसका सुझाव ज़रूर दिया जाता है' के तौर पर बताया गया है. हालांकि, आने वाले समय में रिलीज़ होने वाले वर्शन के लिए, 'इसका इस्तेमाल करना ज़रूरी है' के तौर पर बदलाव किया जाएगा. इस वर्शन में ये स्टैंडर्ड ज़रूरी नहीं हैं. हालांकि, आने वाले वर्शन में इनका पालन करना ज़रूरी होगा. Android के इस वर्शन पर काम करने वाले मौजूदा और नए डिवाइसों को, इन ज़रूरी शर्तों को अभी पूरा करने का सुझाव दिया जाता है, ताकि वे आने वाले समय में प्लैटफ़ॉर्म के रिलीज़ पर अपग्रेड कर सकें.
[C-1-13] एनएफ़सी डिस्कवरी मोड में, काम करने वाली सभी टेक्नोलॉजी के लिए पोल करना ज़रूरी है.
डिवाइस के चालू होने पर, स्क्रीन चालू और लॉक-स्क्रीन अनलॉक होने पर, डिवाइस को एनएफ़सी डिस्कवरी मोड में होना चाहिए.
थिनफ़िल्म एनएफ़सी बारकोड वाले प्रॉडक्ट के बारकोड और यूआरएल (अगर कोड में बदला गया हो) को पढ़ने की सुविधा होनी चाहिए.

ध्यान दें कि ऊपर बताए गए JIS, ISO, और NFC Forum के स्पेसिफ़िकेशन के लिए, सार्वजनिक तौर पर उपलब्ध लिंक उपलब्ध नहीं हैं.

Android में, एनएफ़सी होस्ट कार्ड एम्युलेशन (एचसीई) मोड के साथ काम करने की सुविधा शामिल है.

अगर डिवाइस में एनएफ़सी कंट्रोलर चिपसेट शामिल है, जो एचसीई (NfcA और/या NfcB के लिए) की सुविधा देता है और ऐप्लिकेशन आईडी (एआईडी) को रूट करने की सुविधा देता है, तो:

[C-2-1] android.hardware.nfc.hce सुविधा के कॉन्स्टेंट की जानकारी देना ज़रूरी है.
[C-2-2] Android SDK टूल में बताए गए तरीके के मुताबिक, एनएफ़सी एचसीई एपीआई के साथ काम करना चाहिए.

अगर डिवाइस में NfcF के लिए HCE की सुविधा वाला एनएफ़सी कंट्रोलर चिपसेट शामिल है और तीसरे पक्ष के ऐप्लिकेशन के लिए इस सुविधा को लागू किया गया है, तो:

[C-3-1] android.hardware.nfc.hcef सुविधा के कॉन्स्टेंट की जानकारी देना ज़रूरी है.
[C-3-2] Android SDK में बताए गए NfcF कार्ड इम्यूलेशन एपीआई को लागू करना ज़रूरी है.

अगर डिवाइस में, इस सेक्शन में बताए गए सामान्य एनएफ़सी सपोर्ट के साथ-साथ, रीडर/राइटर्स की भूमिका में MIFARE टेक्नोलॉजी (MIFARE Classic, MIFARE Ultralight, MIFARE Classic पर NDEF) काम करती हैं, तो:

[C-4-1] Android SDK टूल के दस्तावेज़ में बताए गए तरीके के मुताबिक, काम के Android एपीआई लागू करना ज़रूरी है.
[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, ईथरनेट, और ब्लूटूथ पैन शामिल हैं.
अगर प्राइमरी डेटा कनेक्शन के तौर पर कोई फ़िज़िकल नेटवर्किंग स्टैंडर्ड (जैसे, इथरनेट) इस्तेमाल किया जा रहा है, तो इसमें कम से कम एक सामान्य वायरलेस डेटा स्टैंडर्ड (जैसे, 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] दर को सीमित करने की वजह से, डिवाइस को IPv6 के मुताबिक काम करने वाले किसी भी नेटवर्क से IPv6 कनेक्शन नहीं खोना चाहिए. यह ज़रूरी है कि नेटवर्क, कम से कम 180 सेकंड के आरए लाइफ़टाइम का इस्तेमाल करता हो.
[C-0-6] तीसरे पक्ष के ऐप्लिकेशन को, आईपीवी6 नेटवर्क से कनेक्ट होने पर, नेटवर्क से सीधे आईपीवी6 कनेक्टिविटी देनी चाहिए. इसके लिए, डिवाइस पर कोई भी पता या पोर्ट ट्रांसलेशन नहीं होना चाहिए. मैनेज किए जा रहे एपीआई, जैसे कि Socket#getLocalAddress या Socket#getLocalPort और एनडीके एपीआई, जैसे कि getsockname() या IPV6_PKTINFO, दोनों को वह आईपी पता और पोर्ट दिखाना चाहिए जिसका इस्तेमाल नेटवर्क पर पैकेट भेजने और पाने के लिए किया जाता है. यह इंटरनेट (वेब) सर्वर के लिए सोर्स आईपी और पोर्ट के तौर पर दिखता है.

IPv6 के साथ काम करने की ज़रूरी शर्तें, नेटवर्क के टाइप पर निर्भर करती हैं. इन शर्तों के बारे में यहां बताया गया है.

अगर डिवाइस में वाई-फ़ाई काम करता है, तो:

[C-1-1] यह ज़रूरी है कि वाई-फ़ाई पर, ड्यूअल-स्टैक और सिर्फ़ IPv6 मोड काम करे.

अगर डिवाइस में ईथरनेट काम करता है, तो:

[C-2-1] यह ज़रूरी है कि एथरनेट पर, ड्यूअल-स्टैक और सिर्फ़ IPv6 मोड काम करे.

अगर डिवाइस में सेट किए गए सिस्टम में सेल्युलर डेटा की सुविधा काम करती है, तो:

[C-3-1] यह ज़रूरी है कि डिवाइस, मोबाइल इंटरनेट पर IPv6 (सिर्फ़ IPv6 और शायद ड्यूअल-स्टैक) के साथ काम करे.

अगर डिवाइस में एक से ज़्यादा तरह के नेटवर्क काम करते हैं (उदाहरण के लिए, वाई-फ़ाई और मोबाइल डेटा का इस्तेमाल करने पर, ये काम किए जा सकते हैं:

[C-4-1] जब डिवाइस एक से ज़्यादा तरह के नेटवर्क से कनेक्ट हो, तो हर नेटवर्क पर ऊपर दी गई ज़रूरी शर्तें एक साथ पूरी करनी होंगी.

7.4.5.3. कैप्टिव पोर्टल

कैप्टिव पोर्टल, ऐसे नेटवर्क को कहते हैं जिससे इंटरनेट का ऐक्सेस पाने के लिए, साइन इन करना ज़रूरी होता है.

अगर डिवाइस में सेट किए गए सिस्टम में android.webkit.Webview API को पूरी तरह से लागू किया गया है, तो:

[C-1-1] इंटेंट को मैनेज करने के लिए, कैप्टिव पोर्टल ऐप्लिकेशन उपलब्ध कराना ज़रूरी है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. डेटा बचाने की सेटिंग

अगर डिवाइस में लागू किए गए सिस्टम में मीटर वाला कनेक्शन शामिल है, तो:

[C-SR-1] डेटा बचाने वाला मोड उपलब्ध कराने का सुझाव दिया जाता है.

अगर डिवाइस में डेटा बचाने वाला मोड उपलब्ध है, तो:

[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 5.0 में, पुराने एपीआई पैकेज,android.hardware.Camera को 'इस्तेमाल नहीं किया जा सकता' के तौर पर मार्क किया गया है. हालांकि, यह ऐप्लिकेशन के इस्तेमाल के लिए अब भी उपलब्ध होना चाहिए. Android डिवाइस पर एपीआई लागू करने के लिए, यह ज़रूरी है कि एपीआई के साथ काम करने की सुविधा लगातार उपलब्ध रहे. इस बारे में इस सेक्शन और Android SDK टूल में बताया गया है.

बंद किए गए android.hardware.Camera क्लास और नए android.hardware.camera2 पैकेज के बीच मौजूद सभी सुविधाओं की परफ़ॉर्मेंस और क्वालिटी, दोनों एपीआई में एक जैसी होनी चाहिए. उदाहरण के लिए, एक जैसी सेटिंग के साथ, ऑटोफ़ोकस की स्पीड और सटीक होने की दर एक जैसी होनी चाहिए. साथ ही, कैप्चर की गई इमेज की क्वालिटी भी एक जैसी होनी चाहिए. दो एपीआई के अलग-अलग सेमेटिक्स पर निर्भर करने वाली सुविधाओं के लिए, स्पीड या क्वालिटी का मेल खाना ज़रूरी नहीं है. हालांकि, इन सुविधाओं के मेल खाने की कोशिश ज़रूर की जानी चाहिए.

डिवाइस में कैमरे से जुड़े एपीआई लागू करने के लिए, सभी उपलब्ध कैमरों के लिए, कैमरे के काम करने का यह तरीका लागू करना ज़रूरी है. डिवाइस में लागू करने के लिए:

[C-0-1] ऐप्लिकेशन कॉलबैक के लिए दिए गए डेटा की झलक के तौर पर, android.hardware.PixelFormat.YCbCr_420_SP का इस्तेमाल करना ज़रूरी है. ऐसा तब करना होगा, जब किसी ऐप्लिकेशन ने कभी android.hardware.Camera.Parameters.setPreviewFormat(int) को कॉल न किया हो.
[C-0-2] जब कोई ऐप्लिकेशन android.hardware.Camera.PreviewCallback इंस्टेंस रजिस्टर करता है और सिस्टम onPreviewFrame() तरीके को कॉल करता है और झलक का फ़ॉर्मैट YCbCr_420_SP होता है, तो byte[] में मौजूद डेटा को onPreviewFrame() में पास किया जाना चाहिए. साथ ही, यह डेटा NV21 एन्कोडिंग फ़ॉर्मैट में होना चाहिए. इसका मतलब है कि NV21, डिफ़ॉल्ट तौर पर होना चाहिए.
[C-0-3] android.hardware.Camera के लिए, सामने और पीछे के दोनों कैमरों की झलक दिखाने के लिए, YV12 फ़ॉर्मैट (जैसा कि android.graphics.ImageFormat.YV12 कॉन्स्टेंट से पता चलता है) का इस्तेमाल करना ज़रूरी है. (हार्डवेयर वीडियो एन्कोडर और कैमरा, किसी भी नेटिव पिक्सल फ़ॉर्मैट का इस्तेमाल कर सकते हैं. हालांकि, डिवाइस में YV12 में बदलाव करने की सुविधा होनी चाहिए.)
[C-0-4] android.media.ImageReader एपीआई की मदद से, android.hardware.camera2 डिवाइसों के लिए android.hardware.ImageFormat.YUV_420_888 और android.hardware.ImageFormat.JPEG फ़ॉर्मैट को आउटपुट के तौर पर इस्तेमाल करना ज़रूरी है. ये ऐसे डिवाइस होते हैं जो android.request.availableCapabilities में REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE की सुविधा का विज्ञापन करते हैं.
[C-0-5] Android SDK टूल के दस्तावेज़ में शामिल Camera API को पूरी तरह से लागू करना ज़रूरी है. भले ही, डिवाइस में हार्डवेयर ऑटोफ़ोकस या अन्य सुविधाएं हों या नहीं. उदाहरण के लिए, जिन कैमरों में ऑटोफ़ोकस की सुविधा नहीं होती है उन्हें भी रजिस्टर किए गए किसी भी android.hardware.Camera.AutoFocusCallback इंस्टेंस को कॉल करना होगा. भले ही, ऑटोफ़ोकस की सुविधा न होने वाले कैमरे के लिए, यह ज़रूरी नहीं है. ध्यान दें कि यह फ़्रंट-फ़ेसिंग कैमरों पर भी लागू होता है. उदाहरण के लिए, ज़्यादातर फ़्रंट-फ़ेसिंग कैमरे ऑटोफ़ोकस की सुविधा के साथ काम नहीं करते. इसके बावजूद, एपीआई कॉलबैक को ऊपर बताए गए तरीके से “फ़ेक” किया जाना चाहिए.
[C-0-6] android.hardware.Camera.Parameters क्लास और android.hardware.camera2.CaptureRequest क्लास में, हर पैरामीटर के नाम को एक कॉन्स्टेंट के तौर पर तय किया गया है. इसे पहचानना और इस्तेमाल करना ज़रूरी है. इसके उलट, डिवाइस पर लागू करने के लिए, android.hardware.Camera.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-1] एक ही दिशा में फ़ोकस करने वाले कई RGB कैमरों वाले डिवाइसों के लिए, हमारा सुझाव है कि आप ऐसे लॉजिकल कैमरा डिवाइस का इस्तेमाल करें जिसमें कैमरे की सुविधा CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA की जानकारी दी गई हो. इसमें, उस दिशा में फ़ोकस करने वाले सभी RGB कैमरे, फ़िज़िकल सब-डिवाइस के तौर पर शामिल होने चाहिए.

अगर डिवाइस में, तीसरे पक्ष के ऐप्लिकेशन के लिए मालिकाना हक वाला कैमरा एपीआई उपलब्ध कराया जाता है, तो:

[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] ऐप्लिकेशन के लिए स्टोरेज उपलब्ध कराना ज़रूरी है. इसे अक्सर "शेयर किया गया बाहरी स्टोरेज", "ऐप्लिकेशन के लिए शेयर किया गया स्टोरेज" या लिनक्स पाथ "/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. एडॉप्टेबल स्टोरेज

अगर डिवाइस, टीवी के बजाय मोबाइल है, तो डिवाइस को लागू करने के लिए:

[C-SR-1] हमारा सुझाव है कि डिवाइस के साथ इस्तेमाल किए जा सकने वाले स्टोरेज को ऐसी जगह पर सेट अप करें जहां वह लंबे समय तक काम करता रहे. ऐसा इसलिए, क्योंकि गलती से डिवाइस से डिसकनेक्ट होने पर, डेटा मिट सकता है या खराब हो सकता है.

अगर डिवाइस में, स्टोरेज डिवाइस का पोर्ट ऐसी जगह पर है जहां वह लंबे समय तक ठीक से काम करता है, जैसे कि बैटरी कम्पार्टमेंट या सुरक्षा कवर के अंदर, तो डिवाइस को लागू करने के लिए ये तरीके अपनाए जा सकते हैं:

[C-SR-2] अडॉप्टेबल स्टोरेज को लागू करने का सुझाव दिया जाता है.

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 यूएसबी की सुविधा का इस्तेमाल किया गया है, तो विज्ञापन में हुए बदलावों का पता लगाना ज़रूरी है.
[C-SR-1] पोर्ट में माइक्रो-बी, माइक्रो-एबी या टाइप-सी यूएसबी फ़ॉर्म फ़ैक्टर का इस्तेमाल किया जाना चाहिए. मौजूदा और नए Android डिवाइसों के लिए, इन ज़रूरी शर्तों को पूरा करने का सुझाव दिया जाता है, ताकि वे आने वाले समय में प्लैटफ़ॉर्म के रिलीज़ किए जाने वाले वर्शन पर अपग्रेड कर सकें.
[C-SR-2] पोर्ट, डिवाइस के सबसे नीचे (सामान्य ओरिएंटेशन के हिसाब से) होना चाहिए या सभी ऐप्लिकेशन (होम स्क्रीन के साथ) के लिए, स्क्रीन रोटेशन की सुविधा चालू होनी चाहिए. इससे डिवाइस को सबसे नीचे पोर्ट के साथ ओरिएंट करने पर, डिसप्ले सही तरीके से दिखेगा. मौजूदा और नए Android डिवाइसों के लिए, इन ज़रूरी शर्तों को पूरा करने का सुझाव दिया जाता है, ताकि वे आने वाले समय में प्लैटफ़ॉर्म के रिलीज़ किए जाने वाले वर्शन पर अपग्रेड किए जा सकें.
[C-SR-3] को यूएसबी बैटरी चार्जिंग स्पेसिफ़िकेशन, रिविज़न 1.2 में बताए गए तरीके के मुताबिक, एचएस चिर्प और ट्रैफ़िक के दौरान 1.5 ए करंट खींचने की सुविधा लागू करनी चाहिए. मौजूदा और नए Android डिवाइसों के लिए, इन ज़रूरी शर्तों को पूरा करने का सुझाव दिया जाता है, ताकि वे आने वाले समय में प्लैटफ़ॉर्म के रिलीज़ किए जाने वाले वर्शन पर अपग्रेड कर सकें.
[C-SR-4] हमारा सुझाव है कि चार्ज करने के ऐसे मालिकाना तरीकों का इस्तेमाल न करें जो Vbus वोल्टेज को डिफ़ॉल्ट लेवल से ज़्यादा कर दें या सिंक/सोर्स की भूमिकाओं में बदलाव कर दें. ऐसा करने पर, यूएसबी पावर डिलीवरी के स्टैंडर्ड तरीकों के साथ काम करने वाले चार्जर या डिवाइसों के साथ इंटरऑपरेबिलिटी से जुड़ी समस्याएं हो सकती हैं. हालांकि, इसे "इसका सुझाव दिया जाता है" के तौर पर बताया गया है, लेकिन आने वाले समय में Android के वर्शन में, हम सभी टाइप-C डिवाइसों के लिए, स्टैंडर्ड टाइप-C चार्जर के साथ पूरी तरह से काम करने की ज़रूरी शर्त जोड़ सकते हैं.
[C-SR-5] हमारा सुझाव है कि अगर डिवाइस में टाइप-सी यूएसबी और यूएसबी होस्ट मोड की सुविधा है, तो डेटा के लिए पावर डिलीवरी की सुविधा और पावर रोल स्वैपिंग की सुविधा का इस्तेमाल करें.
यह डिवाइस, ज़्यादा वोल्टेज चार्जिंग के लिए पावर डिलीवरी की सुविधा के साथ-साथ, डिसप्ले आउट जैसे अन्य मोड के साथ काम करना चाहिए.
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 यूएसबी होस्ट एपीआई को लागू करना ज़रूरी है. साथ ही, हार्डवेयर की सुविधा android.hardware.usb.host के साथ काम करने की जानकारी देना ज़रूरी है.
[C-1-2] ज़रूरी है कि डिवाइस पर, यूएसबी के ज़रिए कनेक्ट किए जाने वाले स्टैंडर्ड डिवाइसों को कनेक्ट करने की सुविधा काम करती हो. इसका मतलब है कि डिवाइस पर इनमें से कोई एक सुविधा काम करती हो:
- डिवाइस में टाइप-सी पोर्ट होना चाहिए या डिवाइस में मौजूद मालिकाना पोर्ट को स्टैंडर्ड यूएसबी टाइप-सी पोर्ट (यूएसबी टाइप-सी डिवाइस) में बदलने वाली केबल के साथ शिप किया जाना चाहिए.
- डिवाइस में यूएसबी टाइप-A पोर्ट होना चाहिए या डिवाइस में मौजूद मालिकाना पोर्ट को स्टैंडर्ड यूएसबी टाइप-A पोर्ट में बदलने वाली केबल के साथ डिवाइस को शिप किया जाना चाहिए.
- डिवाइस में माइक्रो-AB पोर्ट होना चाहिए. साथ ही, डिवाइस के साथ एक केबल भी होनी चाहिए, जो स्टैंडर्ड टाइप-A पोर्ट के साथ काम करती हो.
[C-1-3] डिवाइस को यूएसबी टाइप A या माइक्रो-AB पोर्ट से टाइप-C पोर्ट (जगह) में बदलने वाले अडैप्टर के साथ शिप नहीं किया जाना चाहिए.
[C-SR-1] 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] USB Type-C स्पेसिफ़िकेशन (सेक्शन 4.5.1.3.3) में बताए गए ड्यूअल रोल पोर्ट की सुविधा को लागू करना ज़रूरी है.
[C-SR-2] DisplayPort के साथ काम करने का सुझाव दिया जाता है. साथ ही, यह ज़रूरी है कि यह यूएसबी सुपरस्पीड डेटा रेट के साथ काम करे. साथ ही, डेटा और पावर की भूमिका बदलने के लिए, पावर डिलीवरी की सुविधा के साथ काम करने का सुझाव दिया जाता है.
[C-SR-3] हमारा सुझाव है कि आपके डिवाइस में ऑडियो अडैप्टर ऐक्सेसरी मोड काम न करे. इस मोड के बारे में, यूएसबी टाइप-सी केबल और कनेक्टर स्पेसिफ़िकेशन रिविज़न 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 में बताई गई, ऑडियो के इंतज़ार से जुड़ी ज़रूरी शर्तों को पूरा करना होगा.
[C-SR-1] सेक्शन 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 में बताई गई, ऑडियो के इंतज़ार से जुड़ी ज़रूरी शर्तों को पूरा करना होगा.
[C-SR-1] सेक्शन 7.8.3 में बताए गए तरीके के मुताबिक, नियर-अल्ट्रासाउंड प्लेलबैक की सुविधा उपलब्ध कराने का सुझाव दिया जाता है.

अगर डिवाइस में स्पीकर या ऑडियो आउटपुट पोर्ट शामिल नहीं है, तो:

[C-2-1] android.hardware.audio.output सुविधा के बारे में नहीं बताया जाना चाहिए.
[C-2-2] ऑडियो आउटपुट से जुड़े एपीआई को कम से कम नो-ऑप के तौर पर लागू करना ज़रूरी है.

इस सेक्शन के लिए, "आउटपुट पोर्ट" एक ऐसा फ़िज़िकल इंटरफ़ेस है जैसे कि 3.5 मि॰मी॰ ऑडियो जैक, एचडीएमआई या यूएसबी ऑडियो क्लास वाला यूएसबी होस्ट मोड पोर्ट. ब्लूटूथ, वाई-फ़ाई या मोबाइल नेटवर्क जैसे रेडियो-आधारित प्रोटोकॉल पर ऑडियो आउटपुट की सुविधा, "आउटपुट पोर्ट" के तौर पर शामिल नहीं की जा सकती.

7.8.2.1. ऐनालॉग ऑडियो पोर्ट

Android के सभी प्लैटफ़ॉर्म पर 3.5 मि॰मी॰ के ऑडियो प्लग का इस्तेमाल करने वाले हेडसेट और अन्य ऑडियो ऐक्सेसरी के साथ काम करने के लिए, अगर डिवाइस में एक या उससे ज़्यादा एनालॉग ऑडियो पोर्ट शामिल हैं, तो:

[C-SR-1] हमारा सुझाव है कि कम से कम एक ऑडियो पोर्ट, चार कंडक्टर वाला 3.5mm ऑडियो जैक हो.

अगर डिवाइस में चार कंडक्टर वाला 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-2] हमारा सुझाव है कि आप OMTP पिन-आउट क्रम वाले ऑडियो प्लग का इस्तेमाल करें.
[C-SR-3] माइक्रोफ़ोन वाले स्टीरियो हेडसेट से ऑडियो रिकॉर्ड करने की सुविधा देने का सुझाव दिया जाता है.

अगर डिवाइस में चार कंडक्टर वाला 3.5 मि॰मी॰ का ऑडियो जैक है और वह माइक्रोफ़ोन के साथ काम करता है, तो android.intent.action.HEADSET_PLUG को माइक्रोफ़ोन की वैल्यू 1 के तौर पर सेट करके ब्रॉडकास्ट किया जा सकता है. ऐसा करने पर:

[C-2-1] प्लग-इन की गई ऑडियो ऐक्सेसरी के माइक्रोफ़ोन का पता लगाने की सुविधा होनी चाहिए.

7.8.2.2. डिजिटल ऑडियो पोर्ट

यूएसबी-सी कनेक्टर का इस्तेमाल करने वाले हेडसेट और अन्य ऑडियो एक्सेसरी के साथ काम करने के लिए, Android यूएसबी हेडसेट स्पेसिफ़िकेशन में बताए गए तरीके के हिसाब से, Android के सभी प्लैटफ़ॉर्म पर यूएसबी ऑडियो क्लास लागू करना.

डिवाइस से जुड़ी ज़रूरी शर्तों के बारे में जानने के लिए, सेक्शन 2.2.1 देखें.

7.8.3. नियर-अल्ट्रासाउंड

नियर-अल्ट्रासोनिक ऑडियो, 18.5 किलोहर्ट्ज़ से 20 किलोहर्ट्ज़ बैंड में होता है.

डिवाइस में लागू करने के लिए:

AudioManager.getProperty एपीआई की मदद से, यह सही तरीके से बताना ज़रूरी है कि डिवाइस पर नियर-अल्ट्रासाउंड ऑडियो की सुविधा काम करती है या नहीं. इसके लिए, यह तरीका अपनाएं:

अगर PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND "सही" है, तो VOICE_RECOGNITION और UNPROCESSED ऑडियो सोर्स को इन ज़रूरी शर्तों को पूरा करना होगा:

[C-1-1] माइक्रोफ़ोन की औसत पावर रिस्पॉन्स, 18.5 किलोहर्ट्ज़ से 20 किलोहर्ट्ज़ के बैंड में, 2 किलोहर्ट्ज़ के रिस्पॉन्स से 15 dB से ज़्यादा नहीं होनी चाहिए.
[C-1-2] माइक्रोफ़ोन का बिना वेट किया गया सिग्नल-टू-नॉइज़ रेशियो, 18.5 किलोहर्ट्ज़ से 20 किलोहर्ट्ज़ के बीच होना चाहिए. साथ ही, -26 डीबीएफ़एस पर 19 किलोहर्ट्ज़ के टोन के लिए, यह रेशियो 50 डीबी से कम नहीं होना चाहिए.

अगर PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND "सही" है, तो:

[C-2-1] स्पीकर का औसत रिस्पॉन्स, 18.5 kHz से 20 kHz के बीच, 2 kHz के रिस्पॉन्स से 40 dB कम होना चाहिए.

7.8.4. सिग्नल इंटिग्रिटी

डिवाइस में लागू करने के लिए:

यह हैंडहेल्ड डिवाइसों पर, इनपुट और आउटपुट, दोनों स्ट्रीम के लिए गड़बड़ी-रहित ऑडियो सिग्नल पाथ उपलब्ध कराएगा. इसका मतलब है कि हर पाथ के लिए एक मिनट के टेस्ट के दौरान, कोई गड़बड़ी नहीं हुई. 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-1] GL_EXT_external_buffer, GL_EXT_EGL_image_array, GL_OVR_multiview_multisampled_render_to_texture को लागू करने का सुझाव दिया जाता है. साथ ही, उपलब्ध GL एक्सटेंशन की सूची में एक्सटेंशन दिखाने का सुझाव दिया जाता है.
[C-SR-2] हमारा सुझाव है कि आप Vulkan 1.1 का इस्तेमाल करें.
[C-SR-3] VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing, VK_KHR_shared_presentable_image को लागू करने का सुझाव दिया जाता है. साथ ही, इसे उपलब्ध Vulkan एक्सटेंशन की सूची में शामिल करें.
[C-SR-4] हमारा सुझाव है कि कम से कम एक 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-5] C-1-10 में बताए गए फ़्लैग और फ़ॉर्मैट के साथ, एक से ज़्यादा लेयर वाली AHardwareBuffers को असाइन करने की सुविधा देने का सुझाव दिया जाता है.
[C-1-11] यह ज़रूरी है कि डिवाइस, कम से कम 3840 x 2160 रिज़ॉल्यूशन और 30 एफ़पीएस (फ़्रेम प्रति सेकंड) पर H.264 डिकोडिंग की सुविधा देता हो. साथ ही, वीडियो को औसतन 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-6] हमारा सुझाव है कि डिसप्ले का रिज़ॉल्यूशन कम से कम 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-7] हमारा सुझाव है कि आप ऊपर दिए गए सभी डायरेक्ट चैनल टाइप के लिए, TYPE_HARDWARE_BUFFER डायरेक्ट चैनल टाइप का इस्तेमाल करें.
[C-1-21] android.hardware.hifi_sensors के लिए, जाइरोस्कोप, एक्सलरोमीटर, और मैग्नेटोमीटर से जुड़ी ज़रूरी शर्तों को पूरा करना ज़रूरी है. इन शर्तों के बारे में सेक्शन 7.3.9 में बताया गया है.
[C-SR-8] android.hardware.sensor.hifi_sensors सुविधा काम करनी चाहिए.
[C-1-22] एंड-टू-एंड मोशन से फ़ोटोन के बीच लगने वाला समय 28 मिलीसेकंड से ज़्यादा नहीं होना चाहिए.
[C-SR-9] हमारा सुझाव है कि एंड-टू-एंड मोशन से फ़ोटोन में लगने वाला समय 20 मिलीसेकंड से ज़्यादा न हो.
[C-1-23] फ़र्स्ट-फ़्रेम रेशियो होना चाहिए. यह रेशियो, काले से सफ़ेद में ट्रांज़िशन के बाद पहले फ़्रेम के पिक्सल की चमक और स्थिर स्थिति में सफ़ेद पिक्सल की चमक के बीच का अनुपात होता है. यह रेशियो कम से कम 85% होना चाहिए.
[C-SR-10] हमारा सुझाव है कि पहले फ़्रेम का अनुपात कम से कम 90% हो.
फ़ोरग्राउंड ऐप्लिकेशन के लिए खास कोर उपलब्ध करा सकता है. साथ ही, Process.getExclusiveCores एपीआई के साथ काम करके, फ़ोरग्राउंड में चल रहे मुख्य ऐप्लिकेशन के लिए, सीपीयू कोर की संख्या दिखा सकता है.

अगर एक्सक्लूज़िव कोर काम करता है, तो कोर:

[C-2-1] ऐप्लिकेशन के इस्तेमाल किए गए डिवाइस ड्राइवर के अलावा, किसी भी अन्य यूज़रस्पेस प्रोसेस को उस पर चलने की अनुमति नहीं देनी चाहिए. हालांकि, ज़रूरत पड़ने पर कुछ कर्नेल प्रोसेस को चलने की अनुमति दी जा सकती है.

7.10. हैप्टिक

डिवाइस से जुड़ी ज़रूरी शर्तों के बारे में जानने के लिए, सेक्शन 2.2.1 देखें.

7.11. मीडिया की परफ़ॉर्मेंस क्लास

डिवाइस पर लागू किए गए मीडिया की परफ़ॉर्मेंस क्लास, android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS से देखी जा सकती है. मीडिया परफ़ॉर्मेंस क्लास की ज़रूरी शर्तें, R (वर्शन 30) से शुरू होने वाले हर Android वर्शन के लिए तय की गई हैं. 0 की खास वैल्यू से पता चलता है कि डिवाइस, मीडिया परफ़ॉर्मेंस क्लास का नहीं है.

अगर डिवाइस पर लागू किए गए बदलावों की वजह से, android.os.Build.VERSION.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 पावर-सेविंग मोड के ट्रिगर करने, मैनेज करने, 'जागने' की सुविधा के एल्गोरिदम, और ग्लोबल सिस्टम सेटिंग या DeviceConfig का इस्तेमाल करने के लिए, AOSP के तरीके से काम करना चाहिए.
[C-1-2] ऐप्लिकेशन के स्टैंडबाय मोड के लिए, हर बकेट में ऐप्लिकेशन के लिए टास्क, अलार्म, और नेटवर्क को कम करने की सुविधा को मैनेज करने के लिए, ग्लोबल सेटिंग या DeviceConfig का इस्तेमाल करने के लिए, AOSP के लागू होने से अलग नहीं होना चाहिए.
[C-1-3] ऐप्लिकेशन के स्टैंडबाय मोड के लिए इस्तेमाल की जाने वाली ऐप्लिकेशन स्टैंडबाय बकेट की संख्या के लिए, AOSP के तरीके से अलग नहीं होना चाहिए.
[C-1-4] पावर मैनेजमेंट में बताए गए तरीके के मुताबिक, ऐप्लिकेशन स्टैंडबाय बकेट और 'बैटरी बचाएं (डोज़)' मोड को लागू करना ज़रूरी है.
[C-1-5] जब डिवाइस पर पावर सेव मोड चालू हो, तो PowerManager.isPowerSaveMode() के लिए true दिखाना ज़रूरी है.
[C-1-6] ऐप्लिकेशन स्टैंडबाय और Doze पावर-सेविंग मोड या बैटरी ऑप्टिमाइज़ेशन से छूट पाने वाले सभी ऐप्लिकेशन दिखाने के लिए, उपयोगकर्ता को सुविधा देनी ज़रूरी है. साथ ही, उपयोगकर्ता से किसी ऐप्लिकेशन को बैटरी ऑप्टिमाइज़ेशन को अनदेखा करने की अनुमति देने के लिए, ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS इंटेंट लागू करना ज़रूरी है.
[C-SR-1] बैटरी सेवर मोड को चालू और बंद करने के लिए, उपयोगकर्ता को आसानी से ऐक्सेस करने की सुविधा देने का सुझाव दिया जाता है.
[C-SR-2] हमारा सुझाव है कि आप उपयोगकर्ता को उन सभी ऐप्लिकेशन को दिखाने की सुविधा दें जिन्हें ऐप्लिकेशन स्टैंडबाय और Doze पावर-सेविंग मोड से छूट मिली है.

अगर डिवाइस में, AOSP में शामिल पावर मैनेजमेंट की सुविधाएं जोड़ी गई हैं और वह एक्सटेंशन, ऐसे ऐप्लिकेशन के लिए स्टैंडबाय बकेट से ज़्यादा सख्त पाबंदियां लागू करता है, तो सेक्शन 3.5.1 देखें.

Android डिवाइस में, बिजली बचाने वाले मोड के अलावा, ऐडवांस कॉन्फ़िगरेशन और पावर इंटरफ़ेस (एसीपीआई) के मुताबिक, डिवाइस को स्लीप मोड में भेजने की चार स्थितियों में से किसी एक या सभी को लागू किया जा सकता है.

अगर डिवाइस में S4 पावर स्टेटस लागू किए जाते हैं, जैसा कि ACPI के मुताबिक बताया गया है, तो:

[C-1-1] डिवाइस को इस स्थिति में सिर्फ़ तब डाला जाना चाहिए, जब उपयोगकर्ता ने डिवाइस को बंद करने के लिए कोई कार्रवाई की हो. जैसे, डिवाइस के किसी हिस्से को बंद करना या वाहन या टीवी को बंद करना. साथ ही, डिवाइस को इस स्थिति में तब तक रखना चाहिए, जब तक उपयोगकर्ता उसे फिर से चालू न कर दे. जैसे, डिवाइस के किसी हिस्से को खोलना या वाहन या टीवी को फिर से चालू करना.

अगर डिवाइस में S3 पावर स्टेटस लागू किए जाते हैं, जैसा कि ACPI के मुताबिक बताया गया है, तो:

[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. बिजली की खपत का हिसाब लगाना

ऐप्लिकेशन के डेवलपर को, बिजली की खपत के बारे में ज़्यादा सटीक जानकारी और रिपोर्ट मिलती है. इससे, ऐप्लिकेशन के बिजली के इस्तेमाल के पैटर्न को ऑप्टिमाइज़ करने के लिए, उन्हें इंसेंटिव और टूल, दोनों मिलते हैं.

डिवाइस में लागू करने के लिए:

[C-SR-1] हमारा सुझाव है कि हर कॉम्पोनेंट के लिए पावर प्रोफ़ाइल दें. इससे हर हार्डवेयर कॉम्पोनेंट के लिए ऊर्जा की मौजूदा खपत की वैल्यू और समय के साथ कॉम्पोनेंट की वजह से बैटरी की खपत का अनुमानित डेटा पता चलता है. इस बारे में Android Open Source Project की साइट पर जानकारी दी गई है.
[C-SR-2] बिजली की खपत की सभी वैल्यू को मिलीऐंपीर घंटे (mAh) में रिपोर्ट करने का सुझाव दिया जाता है.
[C-SR-3] हमारा सुझाव है कि हर प्रोसेस के यूआईडी के हिसाब से, सीपीयू की खपत की रिपोर्ट दें. Android ओपन सोर्स प्रोजेक्ट, uid_cputime कर्नेल मॉड्यूल लागू करने की ज़रूरी शर्तें पूरी करता है.
[C-SR-4] हमारा सुझाव है कि ऐप्लिकेशन डेवलपर को, बिजली की खपत की जानकारी 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] यह ज़रूरी है कि डिवाइस पर, खुद के हस्ताक्षर वाले ऐप्लिकेशन इंस्टॉल किए जा सकें. इसके लिए, किसी तीसरे पक्ष/अधिकारियों से अनुमति या सर्टिफ़िकेट लेने की ज़रूरत नहीं होनी चाहिए.

अगर डिवाइस में android.hardware.security.model.compatible सुविधा का एलान किया जाता है, तो:

[C-1-1] यह ज़रूरी है कि यह टूल, नीचे दिए गए सब-सेक्शन में बताई गई ज़रूरी शर्तों को पूरा करता हो.

9.1. अनुमतियां

डिवाइस में लागू करने के लिए:

[C-0-1] यह ज़रूरी है कि यह Android डेवलपर दस्तावेज़ में बताए गए 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 की जगह की जानकारी की अनुमति की प्रॉपर्टी का पालन करना होगा. इस डेटा में ये चीज़ें शामिल हैं. हालांकि, इसमें और भी चीज़ें शामिल हो सकती हैं:
- डिवाइस की जगह की जानकारी (उदाहरण के लिए, अक्षांश और देशांतर), जैसा कि सेक्शन 9.8.8 में बताया गया है.
- ऐसी जानकारी जिसका इस्तेमाल डिवाइस की जगह का पता लगाने या उसका अनुमान लगाने के लिए किया जा सकता है. जैसे, SSID, BSSID, सेल आईडी या उस नेटवर्क की जगह जिससे डिवाइस कनेक्ट है.
- उपयोगकर्ता की शारीरिक गतिविधि या शारीरिक गतिविधि की कैटगरी.

खास तौर पर, डिवाइस पर लागू करने के लिए:

[C-0-8] किसी ऐप्लिकेशन को जगह की जानकारी या शारीरिक गतिविधि का डेटा ऐक्सेस करने की अनुमति देने के लिए, उपयोगकर्ता की सहमति लेना ज़रूरी है.
[C-0-9] रनटाइम की अनुमति सिर्फ़ उस ऐप्लिकेशन को देनी चाहिए जिसके पास SDK टूल में बताई गई ज़रूरी अनुमतियां हों. उदाहरण के लिए, TelephonyManager#getServiceState के लिए android.permission.ACCESS_FINE_LOCATION की ज़रूरत होती है.

ऊपर बताई गई Android की जगह की जानकारी की अनुमति वाली प्रॉपर्टी के लिए, सिर्फ़ ऐसे ऐप्लिकेशन अपवाद हैं जो उपयोगकर्ता की जगह की जानकारी का पता लगाने या उसकी पहचान करने के लिए, जगह की जानकारी को ऐक्सेस नहीं करते. खास तौर पर:

जब ऐप्लिकेशन के पास RADIO_SCAN_WITHOUT_LOCATION अनुमति हो.
डिवाइस के कॉन्फ़िगरेशन और सेटअप के लिए, जहां सिस्टम ऐप्लिकेशन के पास NETWORK_SETTINGS या NETWORK_SETUP_WIZARD अनुमति हो.

अनुमतियों के व्यवहार में बदलाव करके, उन्हें 'पाबंदी वाला' के तौर पर मार्क किया जा सकता है.

[C-0-10] hardRestricted फ़्लैग के साथ मार्क की गई अनुमतियां, किसी ऐप्लिकेशन को तब तक नहीं दी जानी चाहिए, जब तक:
- ऐप्लिकेशन की APK फ़ाइल, सिस्टम पार्टीशन में है.
- उपयोगकर्ता, किसी ऐप्लिकेशन को hardRestricted अनुमतियों से जुड़ी भूमिका असाइन करता है.
- इंस्टॉलर, किसी ऐप्लिकेशन को hardRestricted देता है.
- किसी ऐप्लिकेशन को Android के पुराने वर्शन पर hardRestricted दिया गया हो.
[C-0-11] softRestricted अनुमति वाले ऐप्लिकेशन को सिर्फ़ सीमित ऐक्सेस मिलना चाहिए. साथ ही, जब तक अनुमति वाली सूची में शामिल नहीं किया जाता, तब तक उसे पूरा ऐक्सेस नहीं मिलना चाहिए. अनुमति वाली सूची में, हर softRestricted अनुमति (उदाहरण के लिए, READ_EXTERNAL_STORAGE) के लिए पूरा और सीमित ऐक्सेस तय किया जाता है.
[C-0-12] setPermissionPolicy और setPermissionGrantState एपीआई में बताई गई अनुमति से जुड़ी पाबंदियों को बायपास करने के लिए, कोई कस्टम फ़ंक्शन या एपीआई नहीं दिया जाना चाहिए.
[C-0-13] Android गतिविधियों और सेवाओं से, नुकसान पहुंचाने वाली अनुमतियों से सुरक्षित डेटा के हर प्रोग्राम के ऐक्सेस को रिकॉर्ड और ट्रैक करने के लिए, AppOpsManager API का इस्तेमाल करना ज़रूरी है.
[C-0-14] सिर्फ़ उन ऐप्लिकेशन को भूमिकाएं असाइन करें जिनके फ़ंक्शन, भूमिका से जुड़ी ज़रूरी शर्तों को पूरा करते हों.
[C-0-15] ऐसी भूमिकाएं तय नहीं की जानी चाहिए जो प्लैटफ़ॉर्म की तय की गई भूमिकाओं की डुप्लीकेट हों या जिनमें उन भूमिकाओं के फ़ंक्शन शामिल हों.

अगर डिवाइसों की रिपोर्ट में android.software.managed_users दिखता है, तो:

[C-1-1] यह ज़रूरी है कि एडमिन ने इन अनुमतियों को चुपचाप न दिया हो:
- जगह की जानकारी (ACCESS_BACKGROUND_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION).
- कैमरा (CAMERA)
- माइक्रोफ़ोन (RECORD_AUDIO)
- बॉडी सेंसर (BODY_SENSORS)
- शारीरिक गतिविधि (ACTIVITY_RECOGNITION)

अगर डिवाइस पर उपयोगकर्ता को यह चुनने का विकल्प मिलता है कि कौनसे ऐप्लिकेशन, ACTION_MANAGE_OVERLAY_PERMISSION इंटेंट को मैनेज करने वाली गतिविधि के साथ, दूसरे ऐप्लिकेशन के ऊपर दिख सकते हैं, तो:

[C-2-1] यह पक्का करना ज़रूरी है कि ACTION_MANAGE_OVERLAY_PERMISSION इंटेंट के लिए इंटेंट फ़िल्टर वाली सभी गतिविधियों में एक ही यूज़र इंटरफ़ेस (यूआई) स्क्रीन हो. भले ही, गतिविधि शुरू करने वाला ऐप्लिकेशन या उससे मिलने वाली जानकारी कुछ भी हो.

अगर डिवाइस पर लागू किए गए ऐप्लिकेशन में android.software.device_admin की जानकारी दी गई है, तो:

[C-3-1] पूरी तरह से मैनेज किए जाने वाले डिवाइस के सेटअप (डिवाइस के मालिक का सेटअप) के दौरान, डिसक्लेमर दिखाना ज़रूरी है. इसमें यह जानकारी होनी चाहिए कि आईटी एडमिन के पास ऐप्लिकेशन को फ़ोन की सेटिंग कंट्रोल करने की अनुमति देने का विकल्प होगा. इन सेटिंग में माइक्रोफ़ोन, कैमरा, और जगह की जानकारी शामिल है. साथ ही, उपयोगकर्ता के पास सेटअप जारी रखने या सेटअप से बाहर निकलने का विकल्प होगा. हालांकि, ऐसा तब तक होगा, जब तक एडमिन ने डिवाइस पर अनुमतियों को कंट्रोल करने की सुविधा से ऑप्ट आउट न कर दिया हो.

अगर डिवाइस में पहले से ऐसे पैकेज इंस्टॉल हैं जिनमें System UI Intelligence, System Ambient Audio Intelligence, System Audio Intelligence, System Notification Intelligence, System Text Intelligence या System Visual Intelligence में से कोई भी भूमिका है, तो ये पैकेज:

[C-4-1] "9.8.6 कॉन्टेंट कैप्चर" सेक्शन में, डिवाइस को लागू करने के लिए बताई गई सभी ज़रूरी शर्तों को पूरा करना ज़रूरी है.
[C-4-2] ऐप्लिकेशन में android.permission.INTERNET की अनुमति नहीं होनी चाहिए. यह शर्त, सेक्शन 9.8.6 में बताई गई 'बहुत ज़रूरी' शर्त से ज़्यादा सख्त है.
[C-4-3] यह ज़रूरी है कि यह इन सिस्टम ऐप्लिकेशन को छोड़कर, अन्य ऐप्लिकेशन से बाइंड न हो: ब्लूटूथ, संपर्क, मीडिया, टेलीफ़ोन, SystemUI, और इंटरनेट एपीआई देने वाले कॉम्पोनेंट.यह शर्त, सेक्शन 9.8.6 में बताई गई 'इसका सुझाव दिया जाता है' शर्त से ज़्यादा सख्त है.

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 सैंडबॉक्स मॉडल का पालन करना ज़रूरी है. साथ ही, किसी अन्य रनटाइम का इस्तेमाल करके इंस्टॉल किए गए ऐप्लिकेशन को, डिवाइस पर इंस्टॉल किए गए किसी भी अन्य ऐप्लिकेशन के सैंडबॉक्स का फिर से इस्तेमाल नहीं करना चाहिए. हालांकि, शेयर किए गए User-ID और साइनिंग सर्टिफ़िकेट के स्टैंडर्ड 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 में एक से ज़्यादा उपयोगकर्ताओं के लिए सहायता शामिल है.साथ ही, यह उपयोगकर्ता को पूरी तरह से अलग करने और कुछ हद तक अलग करने के साथ-साथ उपयोगकर्ता प्रोफ़ाइलों को क्लोन करने की सुविधा भी देता है. उदाहरण के लिए, android.os.usertype.profile.CLONE टाइप की एक अतिरिक्त उपयोगकर्ता प्रोफ़ाइल.

अगर डिवाइस में प्राइमरी बाहरी स्टोरेज के लिए, रिमूवेबल मीडिया का इस्तेमाल किया जाता है, तो डिवाइस में एक से ज़्यादा उपयोगकर्ताओं के लिए फ़ाइल शेयर करने की सुविधा चालू की जा सकती है. हालांकि, ऐसा नहीं करना चाहिए.

अगर डिवाइस में एक से ज़्यादा उपयोगकर्ताओं के लिए सहायता शामिल है, तो:

[C-1-2] हर उपयोगकर्ता के लिए, Android प्लैटफ़ॉर्म के सुरक्षा मॉडल के मुताबिक सुरक्षा मॉडल लागू करना ज़रूरी है. इस मॉडल के बारे में एपीआई में सुरक्षा और अनुमतियों के रेफ़रंस दस्तावेज़ में बताया गया है.
[C-1-3] हर उपयोगकर्ता इंस्टेंस के लिए, अलग और अलग-अलग शेयर किए गए ऐप्लिकेशन स्टोरेज (/sdcard) डायरेक्ट्री होनी चाहिए.
[C-1-4] यह पक्का करना ज़रूरी है कि किसी उपयोगकर्ता के मालिकाना हक वाली और उसकी ओर से चलने वाली ऐप्लिकेशन, किसी दूसरे उपयोगकर्ता के मालिकाना हक वाली फ़ाइलों को न तो देख सकें, न ही उनमें बदलाव कर सकें और न ही उन्हें पढ़ सकें. भले ही, दोनों उपयोगकर्ताओं का डेटा एक ही वॉल्यूम या फ़ाइल सिस्टम में सेव हो.
[C-1-5] अगर डिवाइस में एक से ज़्यादा उपयोगकर्ताओं के लिए सुविधा चालू है, तो एसडी कार्ड के कॉन्टेंट को एन्क्रिप्ट करना ज़रूरी है. इसके लिए, ऐसी कुंजी का इस्तेमाल करना चाहिए जो सिर्फ़ ऐसे मीडिया पर सेव हो जिसे डिवाइस से हटाया न जा सके. साथ ही, यह कुंजी सिर्फ़ सिस्टम ऐक्सेस कर सकता है. ऐसा तब ज़रूरी है, जब डिवाइस में बाहरी स्टोरेज के एपीआई के लिए, हटाया जा सकने वाले मीडिया का इस्तेमाल किया जाता हो. इससे होस्ट पीसी, मीडिया को पढ़ नहीं पाएगा. इसलिए, डिवाइस को MTP या मिलते-जुलते सिस्टम पर स्विच करना होगा, ताकि होस्ट पीसी को मौजूदा उपयोगकर्ता के डेटा का ऐक्सेस मिल सके.

अगर डिवाइस पर एक से ज़्यादा उपयोगकर्ताओं के लिए सहायता उपलब्ध है, तो एक ही ऐप्लिकेशन के दो इंस्टेंस चलाने के लिए खास तौर पर बनाए गए उपयोगकर्ताओं को छोड़कर, सभी उपयोगकर्ताओं के लिए:

[C-2-1] हर उपयोगकर्ता इंस्टेंस के लिए, ऐप्लिकेशन के शेयर किए गए स्टोरेज (जिसे /sdcard भी कहा जाता है) की अलग और अलग-अलग डायरेक्ट्री होनी चाहिए.
[C-2-2] यह पक्का करना ज़रूरी है कि किसी उपयोगकर्ता के मालिकाना हक वाली और उसकी ओर से चलने वाली फ़ाइलें, किसी दूसरे उपयोगकर्ता की फ़ाइलों को न देख सकें, न पढ़ सकें, और न ही उनमें बदलाव कर सकें. भले ही, दोनों उपयोगकर्ताओं का डेटा एक ही वॉल्यूम या फ़ाइल सिस्टम में सेव हो.

डिवाइस पर लागू होने पर, एक ही ऐप्लिकेशन के दो इंस्टेंस चलाने के लिए, मुख्य उपयोगकर्ता के लिए android.os.usertype.profile.CLONE टाइप की एक अतिरिक्त उपयोगकर्ता प्रोफ़ाइल बनाई जा सकती है. यह प्रोफ़ाइल सिर्फ़ मुख्य उपयोगकर्ता के लिए बनाई जाती है. ये दो इंस्टेंस, कुछ हद तक अलग-अलग स्टोरेज शेयर करते हैं. साथ ही, ये लॉन्चर में एक ही समय पर असली उपयोगकर्ता को दिखाए जाते हैं और हाल ही में इस्तेमाल किए गए ऐप्लिकेशन के एक ही व्यू में दिखते हैं. उदाहरण के लिए, इसका इस्तेमाल करके उपयोगकर्ता को ड्यूअल-सिम डिवाइस पर, किसी एक ऐप्लिकेशन के दो अलग-अलग इंस्टेंस इंस्टॉल करने में मदद की जा सकती है.

अगर डिवाइस पर लागू करने से, ऊपर बताई गई अतिरिक्त उपयोगकर्ता प्रोफ़ाइल बनती है, तो:

[C-3-1] ऐप्लिकेशन को सिर्फ़ उस स्टोरेज या डेटा का ऐक्सेस देना चाहिए जो पहले से ही पैरंट उपयोगकर्ता प्रोफ़ाइल के पास हो या जिसका मालिकाना हक सीधे तौर पर इस अतिरिक्त उपयोगकर्ता प्रोफ़ाइल के पास हो.
[C-3-2] यह ज़रूरी है कि यह वर्क प्रोफ़ाइल के तौर पर न हो.
[C-3-3] ऐप्लिकेशन के निजी डेटा की डायरेक्ट्री, माता-पिता के उपयोगकर्ता खाते से अलग होनी चाहिए.
[C-3-4] अगर डिवाइस के लिए कोई मालिक तय किया गया है (सेक्शन 3.9.1 देखें), तो अतिरिक्त उपयोगकर्ता प्रोफ़ाइल बनाने की अनुमति नहीं दी जानी चाहिए. इसके अलावा, अतिरिक्त उपयोगकर्ता प्रोफ़ाइल को हटाए बिना, डिवाइस के मालिक को तय करने की अनुमति भी नहीं दी जानी चाहिए.

9.6. प्रीमियम एसएमएस से जुड़ी चेतावनी

Android में, उपयोगकर्ताओं को किसी भी तरह के प्रीमियम एसएमएस मैसेज भेजने से पहले चेतावनी देने की सुविधा शामिल है. प्रीमियम मैसेज, ऐसे टेक्स्ट मैसेज होते हैं जिन्हें मोबाइल और इंटरनेट सेवा देने वाली कंपनी के साथ रजिस्टर की गई किसी सेवा पर भेजा जाता है. इन मैसेज के लिए, उपयोगकर्ता से शुल्क लिया जा सकता है.

अगर डिवाइस में सेट किए गए सिस्टम में android.hardware.telephony का इस्तेमाल किया जाता है, तो:

[C-1-1] डिवाइस में मौजूद /data/misc/sms/codes.xml फ़ाइल में बताई गई रेगुलर एक्सप्रेशन से पहचाने गए नंबरों पर एसएमएस मैसेज भेजने से पहले, उपयोगकर्ताओं को चेतावनी देनी ज़रूरी है. अपस्ट्रीम Android Open Source Project, इस ज़रूरी शर्त को पूरा करने वाला एक तरीका उपलब्ध कराता है.

9.7. सुरक्षा से जुड़ी सुविधाएं

डिवाइस में लागू करने के लिए, यह ज़रूरी है कि वह नीचे बताए गए तरीके से, कर्नेल और प्लैटफ़ॉर्म, दोनों में सुरक्षा सुविधाओं का पालन करता हो.

Android सैंडबॉक्स में ऐसी सुविधाएं शामिल हैं जो बेहतर सुरक्षा वाले Linux (SELinux) के ज़रूरी ऐक्सेस कंट्रोल (MAC) सिस्टम, seccomp सैंडबॉक्सिंग, और Linux कर्नेल की अन्य सुरक्षा सुविधाओं का इस्तेमाल करती हैं. डिवाइस में लागू करने के लिए:

[C-0-1] यह ज़रूरी है कि मौजूदा ऐप्लिकेशन के साथ काम करने की सुविधा बनी रहे. भले ही, Android फ़्रेमवर्क के नीचे SELinux या सुरक्षा से जुड़ी कोई अन्य सुविधा लागू की गई हो.
[C-0-2] जब सुरक्षा से जुड़ा कोई उल्लंघन पता चलता है और Android फ़्रेमवर्क के नीचे लागू की गई सुरक्षा सुविधा से उसे ब्लॉक कर दिया जाता है, तो यूज़र इंटरफ़ेस नहीं दिखना चाहिए. हालांकि, जब सुरक्षा से जुड़ा कोई उल्लंघन ब्लॉक नहीं किया जाता है और उसका फ़ायदा उठाया जाता है, तो यूज़र इंटरफ़ेस दिख सकता है.
[C-0-3] Android फ़्रेमवर्क के नीचे लागू की गई SELinux या सुरक्षा से जुड़ी अन्य सुविधाओं को, उपयोगकर्ता या ऐप्लिकेशन डेवलपर के लिए कॉन्फ़िगर नहीं किया जा सकता.
[C-0-4] किसी ऐसे ऐप्लिकेशन को नीति कॉन्फ़िगर करने की अनुमति नहीं दी जानी चाहिए जो किसी एपीआई (जैसे, डिवाइस एडमिनिस्ट्रेशन एपीआई) के ज़रिए किसी दूसरे ऐप्लिकेशन पर असर डाल सकता है. ऐसा करने से, ऐप्लिकेशन के साथ काम करने की सुविधा बंद हो सकती है.
[C-0-5] मीडिया फ़्रेमवर्क को कई प्रोसेस में बांटना ज़रूरी है, ताकि Android Open Source Project की साइट पर बताए गए तरीके से, हर प्रोसेस के लिए ऐक्सेस को ज़्यादा सटीक तरीके से दिया जा सके.
[C-0-6] कर्नेल ऐप्लिकेशन सैंडबॉक्सिंग का ऐसा तरीका लागू करना ज़रूरी है जिससे कई थ्रेड वाले प्रोग्राम से, कॉन्फ़िगर की जा सकने वाली नीति का इस्तेमाल करके सिस्टम कॉल को फ़िल्टर किया जा सके. अपस्ट्रीम Android Open Source Project, source.android.com के कर्नेल कॉन्फ़िगरेशन सेक्शन में बताए गए तरीके के मुताबिक, थ्रेडग्रुप सिंक्रोनाइज़ेशन (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 या इसके बाद के वर्शन वाले डिवाइसों पर, उपयोगकर्ता के पास सामान्य यूज़र-कॉपी ऐक्सेस एपीआई (जैसे, हार्डवेयर पैन या CONFIG_CPU_SW_DOMAIN_PAN या CONFIG_ARM64_SW_TTBR0_PAN के ज़रिए एमुलेट किया गया) के अलावा, कर्नेल में उपयोगकर्ता-स्पेस मेमोरी को पढ़ने या उसमें बदलाव करने की अनुमति नहीं होनी चाहिए.
[C-0-12] अगर एपीआई लेवल 28 या उसके बाद के वर्शन (जैसे, CONFIG_PAGE_TABLE_ISOLATION या CONFIG_UNMAP_KERNEL_AT_EL0) के साथ शिप किए गए सभी डिवाइसों पर, हार्डवेयर CVE-2017-5754 के शिकार होने की आशंका है, तो कर्नेल पेज टेबल को अलग करना ज़रूरी है.
[C-0-13] अगर एपीआई लेवल 28 या इसके बाद के वर्शन (उदाहरण के लिए, CONFIG_HARDEN_BRANCH_PREDICTOR) के साथ शिप किए गए सभी डिवाइसों पर, हार्डवेयर CVE-2017-5715 के ज़रिए हैक होने की आशंका है, तो ब्रैंच प्रिडिक्शन को बेहतर बनाने की सुविधा लागू करना ज़रूरी है.
[C-SR-1] हमारा सुझाव है कि कर्नेल के उस डेटा को सिर्फ़ पढ़ने के लिए उपलब्ध कराएं जिसे सिर्फ़ डिवाइस को शुरू करने के दौरान लिखा जाता है. जैसे, __ro_after_init.
[C-SR-2] कर्नेल कोड और स्मृति के लेआउट को रैंडम तरीके से व्यवस्थित करने का सुझाव दिया जाता है.साथ ही, ऐसे एक्सपोज़र से बचने का सुझाव दिया जाता है जिनसे रैंडमाइज़ेशन की सुविधा को नुकसान पहुंच सकता है. उदाहरण के लिए, /chosen/kaslr-seed Device Tree node या EFI_RNG_PROTOCOL के ज़रिए बूटलोडर एन्ट्रोपी के साथ CONFIG_RANDOMIZE_BASE.
[C-SR-3] हमारा सुझाव है कि कोड के फिर से इस्तेमाल से जुड़े हमलों (जैसे, CONFIG_CFI_CLANG और CONFIG_SHADOW_CALL_STACK) से अतिरिक्त सुरक्षा पाने के लिए, कोर में कंट्रोल फ़्लो इंटिग्रिटी (CFI) को चालू करें.
[C-SR-4] हमारा सुझाव है कि जिन कॉम्पोनेंट में कंट्रोल-फ़्लो इंटिग्रिटी (CFI), स्‍हेड कॉल स्टैक (SCS) या पूर्णांक ओवरफ़्लो सैनिटाइज़ेशन (IntSan) की सुविधा चालू है उन्हें बंद न करें.
[C-SR-5] हमारा सुझाव है कि सुरक्षा से जुड़े किसी भी अन्य यूज़रस्पेस कॉम्पोनेंट के लिए, CFI, SCS, और IntSan को चालू करें. इस बारे में CFI और IntSan में बताया गया है.
[C-SR-6] हमारा सुझाव है कि कर्नेल में स्टैक को शुरू करने की सुविधा चालू करें, ताकि बिना शुरू किए गए लोकल वैरिएबल (CONFIG_INIT_STACK_ALL या CONFIG_INIT_STACK_ALL_ZERO) का इस्तेमाल न किया जा सके. साथ ही, डिवाइस के लागू होने पर, लोकल वैरिएबल को शुरू करने के लिए, कंपाइलर की इस्तेमाल की गई वैल्यू का इस्तेमाल नहीं किया जाना चाहिए.
[C-SR-7] हमारा सुझाव है कि हेप को शुरू करने की सुविधा को कर्नेल में चालू करें, ताकि हेप के लिए बिना शुरू किए गए ऐलोकेशन (CONFIG_INIT_ON_ALLOC_DEFAULT_ON) का इस्तेमाल न किया जा सके. साथ ही, उन्हें उन ऐलोकेशन को शुरू करने के लिए, कर्नेल की इस्तेमाल की गई वैल्यू का इस्तेमाल नहीं करना चाहिए.

अगर डिवाइस में ऐसे Linux kernel का इस्तेमाल किया जाता है जो SELinux के साथ काम करता है, तो:

[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 नीति को बनाए रखना चाहिए. साथ ही, अपने डिवाइस के हिसाब से कॉन्फ़िगरेशन के लिए, सिर्फ़ इस नीति में बदलाव करना चाहिए.

अगर डिवाइस में लागू किए गए सिस्टम में, Linux के अलावा किसी दूसरे कर्नेल या SELinux के बिना Linux का इस्तेमाल किया जाता है, तो:

[C-2-1] ज़रूरी है कि SELinux के बराबर के ऐक्सेस कंट्रोल सिस्टम का इस्तेमाल किया जाए.

अगर डिवाइस में डीएमए की सुविधा वाले I/O डिवाइसों का इस्तेमाल किया जाता है, तो:

[C-SR-8] हमारा सुझाव है कि डीएमए की सुविधा वाले हर आई/ओ डिवाइस को अलग रखें. इसके लिए, आईओएमएमयू (जैसे, ARM SMMU) का इस्तेमाल करें.

Android में कई ऐसी सुविधाएं हैं जो डिवाइस की सुरक्षा के लिए ज़रूरी हैं. इसके अलावा, Android उन सामान्य गड़बड़ियों की मुख्य कैटगरी को कम करने पर फ़ोकस करता है जिनकी वजह से ऐप्लिकेशन की क्वालिटी खराब होती है और सुरक्षा से जुड़ी समस्याएं आती हैं.

मेमोरी से जुड़ी गड़बड़ियों को कम करने के लिए, डिवाइस में ये बदलाव करें:

[C-SR-9] हमारा सुझाव है कि इनका टेस्ट, यूज़रस्पेस मेमोरी में गड़बड़ी का पता लगाने वाले टूल का इस्तेमाल करके किया जाए. जैसे, ARMv9 डिवाइसों के लिए MTE, ARMv8+ डिवाइसों के लिए HWASan या अन्य तरह के डिवाइसों के लिए ASan.
[C-SR-10] हमारा सुझाव है कि कर्नेल मेमोरी में गड़बड़ी का पता लगाने वाले टूल का इस्तेमाल करके, इनकी जांच की जाए. जैसे, KASAN (CONFIG_KASAN, ARMv9 डिवाइसों के लिए CONFIG_KASAN_HW_TAGS, ARMv8 डिवाइसों के लिए CONFIG_KASAN_SW_TAGS या अन्य डिवाइस टाइप के लिए CONFIG_KASAN_GENERIC).
[C-SR-11] हमारा सुझाव है कि प्रोडक्शन में, मेमोरी की गड़बड़ी का पता लगाने वाले टूल का इस्तेमाल करें. जैसे, MTE, GWP-ASan, और KFENCE.

अगर डिवाइस में Arm TrustZone पर आधारित टीईई का इस्तेमाल किया जाता है, तो:

[C-SR-12] Android और टीईई के बीच मेमोरी शेयर करने के लिए, स्टैंडर्ड प्रोटोकॉल का इस्तेमाल करने का सुझाव दिया जाता है. जैसे, Armv8-A (FF-A) के लिए Arm फ़र्मवेयर फ़्रेमवर्क.
[C-SR-13] हमारा सुझाव है कि भरोसेमंद ऐप्लिकेशन को सिर्फ़ उस मेमोरी को ऐक्सेस करने की अनुमति दें जिसे ऊपर दिए गए प्रोटोकॉल के ज़रिए उनके साथ साफ़ तौर पर शेयर किया गया हो. अगर डिवाइस में Arm S-EL2 के एक्सेप्शन लेवल की सुविधा है, तो इसे सुरक्षित पार्टिशन मैनेजर के ज़रिए लागू किया जाना चाहिए. ऐसा न होने पर, TEE OS को इसे लागू करना चाहिए.

9.8. निजता

9.8.1. इस्तेमाल का इतिहास

Android, उपयोगकर्ता की पसंद का इतिहास सेव करता है और UsageStatsManager की मदद से इस इतिहास को मैनेज करता है.

डिवाइस में लागू करने के लिए:

[C-0-1] उपयोगकर्ता के इस इतिहास को तय समय तक सेव रखना ज़रूरी है.
[C-SR-1] हमारा सुझाव है कि आप 14 दिनों के लिए डेटा सेव रखने की अवधि को, AOSP में डिफ़ॉल्ट रूप से कॉन्फ़िगर किए गए तौर पर ही रखें.

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, स्टेटस बार में चल रही सूचना का आइकॉन दिखाकर, इस ज़रूरी शर्त को पूरा करता है.

अगर डिवाइस में लागू किए गए सिस्टम में कोई ऐसा फ़ंक्शन शामिल है जो स्क्रीन पर दिखने वाले कॉन्टेंट को कैप्चर करता है और/या डिवाइस पर चलने वाली ऑडियो स्ट्रीम को रिकॉर्ड करता है, तो वह सिस्टम API ContentCaptureService या सेक्शन 9.8.6 कॉन्टेंट कैप्चर में बताए गए मालिकाना हक वाले अन्य तरीकों के अलावा किसी और तरीके से काम नहीं करेगा.

[C-1-1] जब भी यह सुविधा चालू हो और वीडियो रिकॉर्ड किया जा रहा हो, तो उपयोगकर्ता को इसकी सूचना दी जानी चाहिए.

अगर डिवाइस में पहले से चालू कोई ऐसा कॉम्पोनेंट शामिल है जो आस-पास के ऑडियो को रिकॉर्ड कर सकता है और/या उपयोगकर्ता के संदर्भ के बारे में काम की जानकारी पाने के लिए, डिवाइस पर चल रहे ऑडियो को रिकॉर्ड कर सकता है, तो:

[C-2-1] रिकॉर्ड किए गए रॉ ऑडियो या किसी ऐसे फ़ॉर्मैट को डिवाइस के स्टोरेज में सेव नहीं किया जाना चाहिए जिसे उपयोगकर्ता की साफ़ तौर पर सहमति के बिना, मूल ऑडियो या मिलते-जुलते ऑडियो में बदला जा सकता हो. इसके अलावा, डिवाइस से ऑडियो को कहीं और भेजा भी नहीं जाना चाहिए.

“माइक्रोफ़ोन इंडिकेटर” का मतलब स्क्रीन पर दिखने वाले ऐसे व्यू से है जो उपयोगकर्ता को लगातार दिखता है और जिसे छिपाया नहीं जा सकता. इससे उपयोगकर्ताओं को पता चलता है कि माइक्रोफ़ोन का इस्तेमाल किया जा रहा है. यह जानकारी, यूनीक टेक्स्ट, रंग, आइकॉन या इनमें से किसी कॉम्बिनेशन के ज़रिए दी जाती है.

“कैमरा इंडिकेटर” का मतलब स्क्रीन पर दिखने वाले ऐसे व्यू से है जो उपयोगकर्ता को हमेशा दिखता है और जिसे छिपाया नहीं जा सकता. इससे उपयोगकर्ताओं को पता चलता है कि कैमरा इस्तेमाल में है. यह जानकारी, यूनीक टेक्स्ट, रंग, आइकॉन या इनमें से किसी कॉम्बिनेशन के ज़रिए दी जाती है.

एक सेकंड के बाद, इंडिकेटर का विज़ुअल बदल सकता है. जैसे, वह छोटा हो सकता है. साथ ही, उसे उसी तरह दिखाने की ज़रूरत नहीं है जिस तरह उसे मूल रूप से दिखाया गया था और समझा गया था.

माइक्रोफ़ोन इंडिकेटर को, चालू कैमरे के इंडिकेटर के साथ मर्ज किया जा सकता है. हालांकि, इसके लिए ज़रूरी है कि टेक्स्ट, आइकॉन या रंगों से उपयोगकर्ता को यह पता चलता हो कि माइक्रोफ़ोन का इस्तेमाल शुरू हो गया है.

कैमरे के इंडिकेटर को, माइक्रोफ़ोन के इंडिकेटर के साथ मर्ज किया जा सकता है. हालांकि, इसके लिए ज़रूरी है कि टेक्स्ट, आइकॉन या रंगों से उपयोगकर्ता को यह पता चलता हो कि कैमरे का इस्तेमाल शुरू हो गया है.

अगर डिवाइस में लागू किए गए सिस्टम में android.hardware.microphone का एलान किया जाता है, तो:

[C-SR-1] जब कोई ऐप्लिकेशन माइक्रोफ़ोन से ऑडियो डेटा ऐक्सेस कर रहा हो, तो माइक्रोफ़ोन इंडिकेटर दिखाने का सुझाव दिया जाता है. हालांकि, जब माइक्रोफ़ोन को सिर्फ़ HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService या सीडीडी आइडेंटिफ़ायर [C-3-X] वाले सेक्शन 9.1 में बताई गई भूमिकाओं वाले ऐप्लिकेशन ऐक्सेस करते हैं, तो ऐसा नहीं करना चाहिए. .
[C-SR-2] हमारा सुझाव है कि आप माइक्रोफ़ोन का इस्तेमाल करने वाले हाल ही में इस्तेमाल किए गए और चालू ऐप्लिकेशन की सूची दिखाएं. यह सूची, PermissionManager.getIndicatorAppOpUsageData() से मिली जानकारी के आधार पर बनाई जानी चाहिए. साथ ही, उन ऐप्लिकेशन से जुड़े एट्रिब्यूशन मैसेज भी दिखाए जाने चाहिए.
[C-SR-3] हमारा सुझाव है कि सिस्टम के उन ऐप्लिकेशन के लिए माइक्रोफ़ोन इंडिकेटर को न छिपाएं जिनमें यूज़र इंटरफ़ेस दिखते हैं या जिनमें सीधे तौर पर उपयोगकर्ता इंटरैक्ट करते हैं.

अगर डिवाइस में लागू किए गए सिस्टम में android.hardware.camera.any का एलान किया जाता है, तो:

[C-SR-4] जब कोई ऐप्लिकेशन कैमरे का लाइव डेटा ऐक्सेस कर रहा हो, तो कैमरा इंडिकेटर दिखाने का सुझाव दिया जाता है. हालांकि, जब कैमरे को सिर्फ़ ऐसे ऐप्लिकेशन ऐक्सेस कर रहे हों जिनके पास सीडीडी आइडेंटिफ़ायर [C-3-X] वाले सेक्शन 9.1 की अनुमतियां हों, तो ऐसा नहीं करना चाहिए.
[C-SR-5] हमारा सुझाव है कि PermissionManager.getIndicatorAppOpUsageData() से मिले कैमरे के डेटा का इस्तेमाल करके, हाल ही में इस्तेमाल किए गए और चालू ऐप्लिकेशन दिखाएं. साथ ही, उनसे जुड़े एट्रिब्यूशन मैसेज भी दिखाएं.
[C-SR-6] हमारा सुझाव है कि ऐसे सिस्टम ऐप्लिकेशन के लिए कैमरा इंडिकेटर को न छिपाएं जिनमें यूज़र इंटरफ़ेस दिखते हैं या जिनमें उपयोगकर्ता सीधे तौर पर इंटरैक्ट करता है.

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, AugmentedAutofillService, AppSearchGlobalManager.query या अन्य मालिकाना तरीकों से काम करता है. इसकी मदद से, ऐप्लिकेशन और उपयोगकर्ता के बीच हुए ऐप्लिकेशन डेटा इंटरैक्शन को कैप्चर किया जाता है:

स्क्रीन पर रेंडर किया गया टेक्स्ट और ग्राफ़िक्स. इसमें AssistStructure एपीआई के ज़रिए सूचनाएं और सहायता डेटा के अलावा, और भी चीज़ें शामिल हो सकती हैं.
डिवाइस पर रिकॉर्ड किया गया या चलाया गया मीडिया डेटा, जैसे कि ऑडियो या वीडियो.
इनपुट इवेंट (जैसे, की, माउस, जेस्चर, आवाज़, वीडियो, और सुलभता).
ऐसे अन्य इवेंट जो कोई ऐप्लिकेशन, Content Capture एपीआई या AppSearchManager एपीआई के ज़रिए सिस्टम को उपलब्ध कराता है. ये एपीआई, Android और मालिकाना एपीआई के तौर पर काम करते हैं.
टेक्स्ट का मतलब समझने के लिए, TextClassifier API के ज़रिए सिस्टम टेक्स्ट क्लासिफ़ायर यानी सिस्टम सेवा को भेजा गया कोई भी टेक्स्ट या अन्य डेटा. साथ ही, टेक्स्ट के आधार पर अगली कार्रवाइयों का अनुमान भी लगाया जाता है.
प्लैटफ़ॉर्म पर AppSearch लागू करने से इंडेक्स किया गया डेटा. इसमें टेक्स्ट, ग्राफ़िक्स, मीडिया डेटा या मिलता-जुलता अन्य डेटा शामिल है.

अगर डिवाइस पर ऊपर दिया गया डेटा कैप्चर किया जाता है, तो:

[C-1-1] डिवाइस में सेव किए जाने पर, इस तरह के सभी डेटा को एन्क्रिप्ट करना ज़रूरी है. यह एन्क्रिप्शन, Android फ़ाइल के आधार पर एन्क्रिप्शन या Cipher SDK में बताए गए एपीआई वर्शन 26 और उसके बाद के वर्शन के तौर पर सूची में शामिल किसी भी सिफर का इस्तेमाल करके किया जा सकता है.
[C-1-2] Android के बैकअप लेने के तरीकों या किसी भी दूसरे बैकअप लेने के तरीके का इस्तेमाल करके, रॉ या एन्क्रिप्ट (सुरक्षित) किए गए डेटा का बैक अप नहीं लेना चाहिए.
[C-1-3] सिर्फ़ निजता बनाए रखने वाले तरीके का इस्तेमाल करके, डिवाइस का लॉग और इस तरह का डेटा भेजना ज़रूरी है. निजता बनाए रखने वाले तरीके को “ऐसा तरीका कहा जाता है जो सिर्फ़ एग्रीगेट में विश्लेषण की अनुमति देता है और अलग-अलग उपयोगकर्ताओं के लिए, लॉग किए गए इवेंट या डेटा से मिले नतीजों को मैच करने से रोकता है”. ऐसा इसलिए किया जाता है, ताकि हर उपयोगकर्ता के डेटा को इंट्रोस्पेक्शन (डेटा का विश्लेषण) न किया जा सके. उदाहरण के लिए, RAPPOR जैसी अलग-अलग निजता टेक्नोलॉजी का इस्तेमाल करके लागू किया जाता है.
[C-1-4] इस तरह के डेटा को डिवाइस पर मौजूद किसी भी उपयोगकर्ता की पहचान (जैसे, Account) से नहीं जोड़ा जाना चाहिए. हालांकि, डेटा को हर बार जोड़ने के लिए, उपयोगकर्ता की साफ़ तौर पर सहमति लेना ज़रूरी है.
[C-1-5] इस तरह के डेटा को ऐसे ओएस कॉम्पोनेंट के साथ शेयर नहीं किया जाना चाहिए जो मौजूदा सेक्शन (9.8.6 कॉन्टेंट कैप्चर) में बताई गई ज़रूरी शर्तों का पालन नहीं करते. हालांकि, हर बार डेटा शेयर करने के लिए, उपयोगकर्ता की साफ़ तौर पर सहमति लेना ज़रूरी है.
[C-1-6] अगर डिवाइस पर डेटा किसी भी फ़ॉर्मैट में सेव किया गया है, तो उपयोगकर्ता को ऐसा डेटा मिटाने का विकल्प देना ज़रूरी है जिसे ContentCaptureService या मालिकाना हक वाले तरीके से इकट्ठा किया गया है.
[C-1-7] उपयोगकर्ता को, AppSearch या मालिकाना हक वाले तरीकों से इकट्ठा किए गए डेटा को Android प्लैटफ़ॉर्म पर दिखाए जाने से ऑप्ट-आउट करने का विकल्प देना ज़रूरी है. जैसे, लॉन्चर.
[C-SR-1] इंटरनेट की अनुमति का अनुरोध न करने का सुझाव दिया जाता है.
[C-SR-2] हमारा सुझाव है कि इंटरनेट को सिर्फ़ स्ट्रक्चर्ड एपीआई के ज़रिए ऐक्सेस करें. ये एपीआई, सार्वजनिक तौर पर उपलब्ध ओपन-सोर्स के ज़रिए काम करते हैं.

अगर डिवाइस में ऐसी सेवा शामिल है जो System APIContentCaptureService, AppSearchManager.index या ऐसी मालिकाना सेवा को लागू करती है जो ऊपर बताए गए तरीके से डेटा कैप्चर करती है, तो:

[C-2-1] उपयोगकर्ताओं को सेवाओं को, उपयोगकर्ता के इंस्टॉल किए जा सकने वाले ऐप्लिकेशन या सेवा से बदलने की अनुमति नहीं देनी चाहिए. साथ ही, सिर्फ़ पहले से इंस्टॉल की गई सेवाओं को ऐसा डेटा कैप्चर करने की अनुमति देनी चाहिए.
[C-2-2] पहले से इंस्टॉल की गई सेवाओं के अलावा, किसी भी ऐप्लिकेशन को ऐसा डेटा कैप्चर करने की अनुमति नहीं दी जानी चाहिए.
[C-2-3] सेवाओं को बंद करने के लिए, उपयोगकर्ता को आसानी से ऐक्सेस करने की सुविधा देना ज़रूरी है.
[C-2-4] सेवाओं के पास मौजूद Android अनुमतियों को मैनेज करने के लिए, उपयोगकर्ता को अनुमति देने की सुविधा देना ज़रूरी है. साथ ही, सेक्शन 9.1 में बताए गए Android अनुमतियों के मॉडल का पालन करना ज़रूरी है. अनुमति.
[C-SR-3] हमारा सुझाव है कि सेवाओं को सिस्टम के अन्य कॉम्पोनेंट से अलग रखें.उदाहरण के लिए, सेवा को बाइंड न करना या प्रोसेस आईडी शेयर न करना. हालांकि, इन मामलों में ऐसा नहीं करना चाहिए:
- टेलीफ़ोन, संपर्क, सिस्टम यूज़र इंटरफ़ेस (यूआई), और मीडिया

Android, SpeechRecognizer#onDeviceSpeechRecognizer() की मदद से, डिवाइस पर बोली पहचानने की सुविधा देता है. इसके लिए, इंटरनेट की ज़रूरत नहीं होती. डिवाइस पर SpeechRecognizer को लागू करने के लिए, इस सेक्शन में बताई गई नीतियों का पालन करना ज़रूरी है.

9.8.7. क्लिपबोर्ड का ऐक्सेस

डिवाइस में लागू करने के लिए:

[C-0-1] क्लिपबोर्ड पर मौजूद डेटा को तब तक नहीं दिखाना चाहिए, जब तक कि ऐप्लिकेशन डिफ़ॉल्ट IME न हो या फ़िलहाल उस पर फ़ोकस न हो. उदाहरण के लिए, ClipboardManager API के ज़रिए.

9.8.8. जगह की जानकारी

जगह की जानकारी में, Android Location क्लास की जानकारी शामिल होती है. जैसे, अक्षांश, रेखांश, और ऊंचाई. साथ ही, इसमें ऐसे आइडेंटिफ़ायर भी शामिल होते हैं जिन्हें जगह की जानकारी में बदला जा सकता है. जगह की जानकारी, डीजीपीएस (डफ़रेंशियल ग्लोबल पोज़िशनिंग सिस्टम) के ज़रिए ज़्यादा सटीक या देश के लेवल पर ज़्यादा कम सटीक हो सकती है. जैसे, देश कोड वाली जगह की जानकारी - एमसीसी - मोबाइल देश कोड.

यहां जगह की जानकारी के उन टाइप की सूची दी गई है जो सीधे तौर पर उपयोगकर्ता की जगह की जानकारी देते हैं या जिन्हें उपयोगकर्ता की जगह की जानकारी में बदला जा सकता है. यह पूरी सूची नहीं है. हालांकि, इसका इस्तेमाल इस उदाहरण के तौर पर किया जाना चाहिए कि जगह की जानकारी को सीधे या किसी अन्य तरीके से कहां से हासिल किया जा सकता है:

GPS/GNSS/DGPS/PPP
- ग्लोबल पोज़िशनिंग सिस्टम या ग्लोबल नेविगेशन सैटलाइट सिस्टम या डाइफ़रेंशियल ग्लोबल पोज़िशनिंग सिस्टम
- इसमें जीएनएसएस के मेज़रमेंट से जुड़ा रॉ डेटा और जीएनएसएस का स्टेटस भी शामिल है
  - जीएनएसएस रिसीवर के रॉ मेज़रमेंट से, सटीक जगह की जानकारी मिल सकती है
यूनीक आइडेंटिफ़ायर वाली वायरलेस टेक्नोलॉजी, जैसे:
- वाई-फ़ाई ऐक्सेस पॉइंट (MAC, BSSID, नाम या SSID)
- ब्लूटूथ/BLE (MAC, BSSID, नाम या SSID)
- UWB (MAC, BSSID, नाम या SSID)
- सेल टावर आईडी (3G, 4G, 5G… इसमें आने वाले समय में इस्तेमाल होने वाली सभी सेल्युलर मॉडेम टेक्नोलॉजी शामिल हैं जिनमें यूनीक आइडेंटिफ़ायर होते हैं)

मुख्य संदर्भ के तौर पर, उन Android API को देखें जिनके लिए ACCESS_FINE_Location या ACCESS_COARSE_Location अनुमतियां ज़रूरी हैं.

डिवाइस में लागू करने के लिए:

[C-0-1] उपयोगकर्ता की अनुमति लिए बिना या उपयोगकर्ता के शुरू किए बिना, डिवाइस की जगह की जानकारी की सेटिंग और वाई-फ़ाई/ब्लूटूथ स्कैनिंग की सेटिंग को चालू/बंद नहीं किया जाना चाहिए.
[C-0-2] ऐप्लिकेशन को उपयोगकर्ता को जगह की जानकारी ऐक्सेस करने की सुविधा देनी चाहिए. इसमें जगह की जानकारी के लिए किए गए हाल ही के अनुरोध, ऐप्लिकेशन के लेवल की अनुमतियां, और वाई-फ़ाई/ब्लूटूथ स्कैनिंग का इस्तेमाल शामिल है.
[C-0-3] यह पक्का करना ज़रूरी है कि आपातकालीन जगह की जानकारी को बायपास करने वाले एपीआई [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 या उसके बाद के वर्शन को टारगेट करने वाले किसी भी ऐप्लिकेशन को, डिवाइस पर इंस्टॉल किए गए किसी भी अन्य ऐप्लिकेशन की जानकारी नहीं दिखनी चाहिए. हालांकि, अगर ऐप्लिकेशन पहले से ही मैनेज किए जा रहे एपीआई की मदद से, डिवाइस पर इंस्टॉल किए गए अन्य ऐप्लिकेशन की जानकारी देख सकता है, तो उसे यह जानकारी दिख सकती है. इसमें, डिवाइस को लागू करने वाले व्यक्ति के जोड़े गए कस्टम एपीआई से ज़ाहिर की गई जानकारी या फ़ाइल सिस्टम के ज़रिए ऐक्सेस की जा सकने वाली जानकारी शामिल है. हालांकि, इसमें और भी चीज़ें शामिल हो सकती हैं.
[C-0-2] किसी भी ऐप्लिकेशन को, बाहरी स्टोरेज में मौजूद किसी भी दूसरे ऐप्लिकेशन की खास तौर पर बनाई गई डायरेक्ट्री में मौजूद फ़ाइलों को पढ़ने या उनमें बदलाव करने का ऐक्सेस नहीं देना चाहिए. हालांकि, इन मामलों में यह शर्त लागू नहीं होती:
- बाहरी स्टोरेज की सेवा देने वाली कंपनी (जैसे, DocumentsUI जैसे ऐप्लिकेशन).
- डाउनलोड करने की सुविधा देने वाली सेवा, जो ऐप्लिकेशन के स्टोरेज में फ़ाइलें डाउनलोड करने के लिए, “डाउनलोड” की सुविधा देने वाली सेवा की अनुमति का इस्तेमाल करती है.
- प्लैटफ़ॉर्म से साइन किए गए मीडिया ट्रांसफ़र प्रोटोकॉल (एमटीपी) वाले ऐप्लिकेशन, जो किसी दूसरे डिवाइस पर फ़ाइलें ट्रांसफ़र करने की सुविधा चालू करने के लिए, खास अनुमति ACCESS_MTP का इस्तेमाल करते हैं.
- जिन ऐप्लिकेशन के पास INSTALL_PACKAGES अनुमति है और जो अन्य ऐप्लिकेशन इंस्टॉल करते हैं वे सिर्फ़ “obb” डायरेक्ट्री को ऐक्सेस कर सकते हैं. ऐसा, APK एक्सपैंशन फ़ाइलों को मैनेज करने के लिए किया जाता है.

9.8.10. कनेक्टिविटी से जुड़ी गड़बड़ी की शिकायत

अगर डिवाइस में android.hardware.telephony सुविधा फ़्लैग का एलान किया जाता है, तो:

[C-1-1] BUGREPORT_MODE_TELEPHONY के साथ BugreportManager का इस्तेमाल करके, कनेक्टिविटी से जुड़ी गड़बड़ी की रिपोर्ट जनरेट करने की सुविधा होनी चाहिए.
[C-1-2] रिपोर्ट जनरेट करने के लिए, हर बार BUGREPORT_MODE_TELEPHONY का इस्तेमाल करने पर, उपयोगकर्ता की सहमति लेना ज़रूरी है. साथ ही, उपयोगकर्ता को ऐप्लिकेशन के आने वाले समय में किए जाने वाले सभी अनुरोधों के लिए सहमति देने के लिए नहीं कहना चाहिए.
[C-1-3] उपयोगकर्ता की साफ़ तौर पर सहमति के बिना, जनरेट की गई रिपोर्ट को अनुरोध करने वाले ऐप्लिकेशन को नहीं दिखाना चाहिए.
[C-1-4] BUGREPORT_MODE_TELEPHONY का इस्तेमाल करके जनरेट की गई रिपोर्ट में, कम से कम यह जानकारी ज़रूर होनी चाहिए:
- TelephonyDebugService डंप
- TelephonyRegistry डंप
- WifiService डंप
- ConnectivityService डंप
- कॉल करने वाले पैकेज के CarrierService इंस्टेंस का डंप (अगर बंधा हुआ हो)
- रेडियो लॉग बफ़र
[C-1-5] जनरेट की गई रिपोर्ट में ये शामिल नहीं होने चाहिए:
- ऐसी कोई भी जानकारी जो सीधे तौर पर कनेक्टिविटी की गड़बड़ी को डीबग करने से जुड़ी न हो.
- उपयोगकर्ता के इंस्टॉल किए गए ऐप्लिकेशन के ट्रैफ़िक लॉग या उपयोगकर्ता के इंस्टॉल किए गए ऐप्लिकेशन/पैकेज की पूरी जानकारी वाली प्रोफ़ाइलें (यूआईडी ठीक हैं, पैकेज के नाम नहीं).
इसमें ऐसी अतिरिक्त जानकारी शामिल हो सकती है जो किसी उपयोगकर्ता की पहचान से जुड़ी न हो. (उदाहरण के लिए, वेंडर लॉग).

अगर डिवाइस में गड़बड़ी की जानकारी वाली रिपोर्ट में अतिरिक्त जानकारी (जैसे, वेंडर लॉग) शामिल की जाती है और उस जानकारी से निजता/सुरक्षा/बैटरी/स्टोरेज/मेमोरी पर असर पड़ता है, तो:

[C-SR-1] हमारा सुझाव है कि डेवलपर सेटिंग को डिफ़ॉल्ट रूप से बंद रखें. 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.8.12. संगीत की पहचान

Android, System API MusicRecognitionManager की मदद से, डिवाइस पर संगीत की पहचान करने का अनुरोध करने के लिए एक सुविधा देता है. इसके लिए, ऑडियो रिकॉर्ड की ज़रूरत होती है. साथ ही, MusicRecognitionService API को लागू करने वाले किसी ऐप्लिकेशन को संगीत की पहचान करने का काम सौंपा जाता है.

अगर डिवाइस में ऐसी सेवा शामिल है जो System API MusicRecognitionManager को लागू करती है या ऊपर बताई गई तरह से ऑडियो डेटा स्ट्रीम करने वाली कोई मालिकाना सेवा है, तो:

[C-1-1] यह ज़रूरी है कि MusicRecognitionManager को कॉल करने वाले के पास MANAGE_MUSIC_RECOGNITION की अनुमति हो
[C-1-2] यह ज़रूरी है कि पहले से इंस्टॉल किया गया, संगीत की पहचान करने वाला कोई एक ऐप्लिकेशन, MusicRecognitionService को लागू करता हो.
[C-1-3] उपयोगकर्ताओं को MusicRecognitionManagerService या MusicRecognitionService को, उपयोगकर्ता के इंस्टॉल किए जा सकने वाले ऐप्लिकेशन या सेवा से बदलने की अनुमति नहीं देनी चाहिए.
[C-1-4] यह पक्का करना ज़रूरी है कि जब MusicRecognitionManagerService, ऑडियो रिकॉर्ड को ऐक्सेस करके उसे MusicRecognitionService को लागू करने वाले ऐप्लिकेशन को फ़ॉरवर्ड करे, तो ऑडियो ऐक्सेस को AppOpsManager.noteOp / startOp के इनवोकेशन के ज़रिए ट्रैक किया जाए.

अगर MusicRecognitionManagerService या MusicRecognitionService के डिवाइस के लागू होने पर, कैप्चर किया गया कोई भी ऑडियो डेटा सेव किया जाता है, तो:

[C-2-1] डिस्क पर किसी भी रॉ ऑडियो या ऑडियो फ़िंगरप्रिंट को सेव नहीं करना चाहिए. इसके अलावा, 14 दिनों से ज़्यादा समय तक मेमोरी में भी सेव नहीं करना चाहिए.
[C-2-2] इस तरह के डेटा को MusicRecognitionService के अलावा किसी और के साथ शेयर नहीं किया जाना चाहिए. हालांकि, हर बार डेटा शेयर करने के लिए, उपयोगकर्ता की साफ़ तौर पर सहमति लेना ज़रूरी है.

9.8.13. SensorPrivacyManager

अगर डिवाइस के लागू होने के लिए, उपयोगकर्ता को कैमरे और/या माइक्रोफ़ोन इनपुट को बंद करने का सॉफ़्टवेयर अवसर मिलता है, तो:

[C-1-1] supportsSensorToggle() एपीआई के काम के तरीके के लिए, 'सही' को सटीक तौर पर दिखाना ज़रूरी है.
[C-1-2] जब कोई ऐप्लिकेशन ब्लॉक किए गए माइक्रोफ़ोन या कैमरे को ऐक्सेस करने की कोशिश करता है, तो उपयोगकर्ता को ऐसा यूज़र अवफ़र्डेंस दिखाना ज़रूरी है जिसे खारिज नहीं किया जा सकता. इससे साफ़ तौर पर पता चलता है कि सेंसर ब्लॉक है और उसे ब्लॉक करना जारी रखने या अनब्लॉक करने का विकल्प दिया जाता है. यह विकल्प, AOSP के लागू होने के हिसाब से दिया जाना चाहिए.
[C-1-3] ऐप्लिकेशन को सिर्फ़ खाली (या नकली) कैमरा और ऑडियो डेटा भेजना चाहिए. साथ ही, ऊपर [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 इंटेंट अब भी ब्रॉडकास्ट किए जाने चाहिए कि डिवाइस को एन्क्रिप्ट (डीई) और क्रेडेंशियल को एन्क्रिप्ट (सीई) करने के लिए, स्टोरेज की जगहें उपयोगकर्ता के लिए उपलब्ध हैं.

9.9.2. एन्क्रिप्शन से जुड़ी ज़रूरी शर्तें

डिवाइस में लागू करने के लिए:

[C-0-1] ऐप्लिकेशन के निजी डेटा (/data पार्टिशन) के साथ-साथ, ऐप्लिकेशन के शेयर किए गए स्टोरेज पार्टिशन (/sdcard पार्टिशन) को एन्क्रिप्ट करना ज़रूरी है. हालांकि, ऐसा तब ही करना होगा, जब यह पार्टिशन डिवाइस का हमेशा मौजूद रहने वाला और हटाया नहीं जा सकने वाला हिस्सा हो.
[C-0-2] उपयोगकर्ता के डिवाइस पर ऐप्लिकेशन के पहले सेटअप होने के बाद, डेटा स्टोरेज को एन्क्रिप्ट (सुरक्षित) करने की सुविधा को डिफ़ॉल्ट रूप से चालू करना ज़रूरी है.
[C-0-3] डेटा स्टोरेज को एन्क्रिप्ट करने से जुड़ी ऊपर दी गई ज़रूरी शर्त को पूरा करना ज़रूरी है. इसके लिए, एन्क्रिप्ट करने के इन दोनों तरीकों में से किसी एक को लागू करें:
- अलग-अलग फ़ाइलों को अलग-अलग तरीकों से एन्क्रिप्ट करने का तरीका (एफ़बीई) और मेटाडेटा एन्क्रिप्शन, जैसा कि सेक्शन 9.9.3.1 में बताया गया है.
- हर उपयोगकर्ता के लिए ब्लॉक-लेवल एन्क्रिप्शन, जैसा कि सेक्शन 9.9.3.2 में बताया गया है.

9.9.3. एन्क्रिप्ट (सुरक्षित) करने के तरीके

अगर डिवाइस पर एन्क्रिप्शन लागू किया गया है, तो:

[C-1-1] यह ज़रूरी है कि डिवाइस, उपयोगकर्ता से क्रेडेंशियल मांगे बिना ही बूट हो जाए. साथ ही, ACTION_LOCKED_BOOT_COMPLETED मैसेज ब्रॉडकास्ट होने के बाद, सीधे बूट की सुविधा वाले ऐप्लिकेशन को डिवाइस के एन्क्रिप्ट किए गए (डीई) स्टोरेज को ऐक्सेस करने की अनुमति दे.
[C-1-2] उपयोगकर्ता के डिवाइस को अनलॉक करने के बाद ही, क्रेडेंशियल एन्क्रिप्ट (सीई) स्टोरेज को ऐक्सेस करने की अनुमति दी जानी चाहिए. इसके लिए, उपयोगकर्ता को अपने क्रेडेंशियल (जैसे, पासवर्ड, पिन, पैटर्न या फ़िंगरप्रिंट) डालने होंगे. साथ ही, ACTION_USER_UNLOCKED मैसेज ब्रॉडकास्ट किया जाना चाहिए.
[C-1-13] उपयोगकर्ता से मिले क्रेडेंशियल, रजिस्टर की गई एस्क्रो पासकोड या सेक्शन 9.9.4 में बताई गई ज़रूरी शर्तों के मुताबिक, रीबूट करने पर फिर से शुरू होने की सुविधा के बिना, सीई से सुरक्षित स्टोरेज को अनलॉक करने का कोई तरीका नहीं दिया जाना चाहिए.
[C-1-4] वेरिफ़ाइड बूट मोड का इस्तेमाल करना ज़रूरी है.

9.9.3.1. मेटाडेटा एन्क्रिप्शन के साथ फ़ाइल के आधार पर एन्क्रिप्शन

अगर डिवाइस पर, मेटाडेटा एन्क्रिप्शन के साथ अलग-अलग फ़ाइलों को अलग-अलग तरीकों से एन्क्रिप्ट करने का तरीका इस्तेमाल किया जाता है, तो:

[C-1-5] फ़ाइल के कॉन्टेंट और फ़ाइल सिस्टम के मेटाडेटा को एईएस-256-एक्सटीएस या एडिअंटम का इस्तेमाल करके एन्क्रिप्ट करना ज़रूरी है. 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-15] यह पक्का करना ज़रूरी है कि हमेशा सेव रहने वाले स्टोरेज में, एन्क्रिप्ट (सुरक्षित) की गई फ़ाइल के कॉन्टेंट के उन ब्लॉक को मिटाया न गया हो जिन्हें एन्क्रिप्ट करने के लिए, एन्क्रिप्शन कुंजी और शुरू करने वाले वेक्टर (IV) के कॉम्बिनेशन का इस्तेमाल किया गया था. ये कॉम्बिनेशन, फ़ाइल और फ़ाइल में मौजूद ऑफ़सेट, दोनों पर निर्भर करते हैं. इसके अलावा, ऐसे सभी कॉम्बिनेशन अलग-अलग होने चाहिए. हालांकि, इनमें से कुछ कॉम्बिनेशन ऐसे भी हो सकते हैं जिनमें एन्क्रिप्शन, इनलाइन एन्क्रिप्शन हार्डवेयर का इस्तेमाल करके किया गया हो. यह हार्डवेयर सिर्फ़ 32 बिट के आईवी का इस्तेमाल करता है.
[C-1-16] यह पक्का करना ज़रूरी है कि अलग-अलग डायरेक्ट्री में मौजूद, हमेशा सेव रहने वाले स्टोरेज में मौजूद, एन्क्रिप्ट की गई सभी फ़ाइलों के नाम, एन्क्रिप्शन कुंजी और इनिशलाइज़ेशन वेक्टर (IV) के अलग-अलग कॉम्बिनेशन का इस्तेमाल करके एन्क्रिप्ट किए गए हों.
[C-1-17] यह पक्का करना ज़रूरी है कि स्टोरेज में मौजूद फ़ाइल सिस्टम के सभी एन्क्रिप्ट किए गए मेटाडेटा ब्लॉक, एन्क्रिप्शन पासकोड और इनिशलाइज़ेशन वेक्टर (IV) के अलग-अलग कॉम्बिनेशन का इस्तेमाल करके एन्क्रिप्ट किए गए हों.
सीई और डीई स्टोरेज एरिया और फ़ाइल सिस्टम मेटाडेटा को सुरक्षित रखने वाली कुंजियां:
- [C-1-7] यह ज़रूरी है कि इसे क्रिप्टोग्राफ़िक तरीके से, हार्डवेयर में सेव किए गए कीस्टोर से जोड़ा गया हो. यह कीस्टोर, पुष्टि किए गए बूट और डिवाइस के हार्डवेयर के ट्रस्ट रूट से बंधा होना चाहिए.
- [C-1-8] सीई पासकोड, उपयोगकर्ता की लॉक स्क्रीन के क्रेडेंशियल से बंधे होने चाहिए.
- [C-1-9] अगर उपयोगकर्ता ने लॉक स्क्रीन के क्रेडेंशियल नहीं दिए हैं, तो सीई कुंजियों को डिफ़ॉल्ट पासवर्ड से बंधा होना चाहिए.
- [C-1-10] यह यूनीक और अलग-अलग होना चाहिए. दूसरे शब्दों में, किसी भी उपयोगकर्ता की सीई या डीई कुंजी, किसी दूसरे उपयोगकर्ता की सीई या डीई कुंजी से मेल नहीं खाती.
- [C-1-11] ज़रूरी सिफर, कुंजी की लंबाई, और तरीकों का इस्तेमाल करना ज़रूरी है.
- [C-1-12] बूटलोडर को अनलॉक और लॉक करने के दौरान, इसे सुरक्षित तरीके से मिटाना ज़रूरी है. इसके लिए, यहां दिया गया तरीका अपनाएं.
पहले से इंस्टॉल किए गए ज़रूरी ऐप्लिकेशन (जैसे, अलार्म, फ़ोन, Messenger) को डायरेक्ट बूट के बारे में जानकारी देनी चाहिए.

अपस्ट्रीम Android Open Source प्रोजेक्ट, Linux kernel "fscrypt" एन्क्रिप्शन की सुविधा के आधार पर, अलग-अलग फ़ाइलों को अलग-अलग तरीकों से एन्क्रिप्ट करने का तरीका इस्तेमाल करता है. साथ ही, Linux kernel "dm-default-key" सुविधा के आधार पर, मेटाडेटा को एन्क्रिप्ट करने का तरीका इस्तेमाल करता है.

ध्यान दें: एपीआई लेवल 28 या उससे पहले के वर्शन पर शिप किए गए डिवाइसों को, सिस्टम सॉफ़्टवेयर अपडेट की मदद से 9.9.3 में बताई गई ज़रूरी शर्तें पूरी करनी होंगी. इसके लिए, डिवाइस को उस एपीआई लेवल के हिसाब से Android कंपैटबिलिटी डेफ़िनिशन डॉक्यूमेंट के सेक्शन 9.9 में बताई गई ज़रूरी शर्तें पूरी करनी होंगी जिस पर डिवाइस शिप किया गया था.

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] सीई स्टोरेज को हमलावर के लिए भी पढ़ा नहीं जा सकता. भले ही, उसके पास डिवाइस का फ़िज़िकल ऐक्सेस हो. साथ ही, उसके पास ये सुविधाएं और सीमाएं होनी चाहिए:
- किसी भी वेंडर या कंपनी की साइनिंग पासकोड का इस्तेमाल करके, मनमुताबिक मैसेज साइन किए जा सकते हैं.
- इससे डिवाइस पर ओटीए (Over-The-Air) अपडेट मिल सकता है.
- नीचे दी गई जानकारी के अलावा, किसी भी हार्डवेयर (एपी, फ़्लैश वगैरह) के काम करने के तरीके में बदलाव किया जा सकता है. हालांकि, ऐसा करने में कम से कम एक घंटे की देरी होती है. साथ ही, पावर साइकल की वजह से रैम का कॉन्टेंट खत्म हो जाता है.
- छेड़छाड़ से सुरक्षित हार्डवेयर (जैसे, Titan M) के काम करने के तरीके में बदलाव नहीं किया जा सकता.
- लाइव डिवाइस की रैम को पढ़ा नहीं जा सका.
- उपयोगकर्ता का क्रेडेंशियल (पिन, पैटर्न, पासवर्ड) हासिल नहीं किया जा सकता या उसे डालने के लिए कहा जा सकता है.

उदाहरण के लिए, यहां दी गई सभी जानकारी को लागू करने वाला डिवाइस, [C-0-1] का पालन करेगा.

9.10. डिवाइस इंटिग्रिटी

यहां दी गई ज़रूरी शर्तों से यह पक्का होता है कि डिवाइस के पूरी तरह से सुरक्षित होने की स्थिति के बारे में साफ़ तौर पर जानकारी दी गई हो. डिवाइस में लागू करने के लिए:

[C-0-1] System API के तरीके PersistentDataBlockManager.getFlashLockState() के ज़रिए यह सही तरीके से रिपोर्ट करना ज़रूरी है कि उनके बूटलोडर की स्थिति, सिस्टम इमेज को फ़्लैश करने की अनुमति देती है या नहीं.
[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) और सार्वजनिक कुंजी के साइज़ (आरएसए-2048) के लिए, एनआईएसटी के मौजूदा सुझावों के मुताबिक हों.
[C-1-6] सिस्टम की पुष्टि न होने पर, डिवाइस को बूट होने की अनुमति नहीं दी जानी चाहिए. ऐसा तब तक नहीं किया जाना चाहिए, जब तक कि उपयोगकर्ता बूट करने की कोशिश करने की सहमति न दे. ऐसे में, पुष्टि न किए गए किसी भी स्टोरेज ब्लॉक के डेटा का इस्तेमाल नहीं किया जाना चाहिए.
[C-1-7] डिवाइस पर पुष्टि किए गए पार्टीशन में बदलाव करने की अनुमति नहीं दी जानी चाहिए, जब तक कि उपयोगकर्ता ने साफ़ तौर पर बूटलोडर को अनलॉक न किया हो.
[C-SR-1] अगर डिवाइस में एक से ज़्यादा अलग-अलग चिप (जैसे, रेडियो, विशेष इमेज प्रोसेसर) हैं, तो हमारा सुझाव है कि बूट करने के दौरान हर चरण की पुष्टि की जाए.
[C-1-8] टेंपर-एविडेंस स्टोरेज का इस्तेमाल करना ज़रूरी है: यह सेव करने के लिए कि bootloader अनलॉक है या नहीं. टेंपर-एविडेंस स्टोरेज का मतलब है कि बूटलोडर यह पता लगा सकता है कि Android में स्टोरेज में छेड़छाड़ की गई है या नहीं.
[C-1-9] डिवाइस का इस्तेमाल करते समय, उपयोगकर्ता को प्रॉम्प्ट करना ज़रूरी है. साथ ही, बूटलोडर के लॉक मोड से अनलॉक मोड पर स्विच करने से पहले, उपयोगकर्ता से पुष्टि करना ज़रूरी है.
[C-1-10] Android के इस्तेमाल किए जाने वाले पार्टिशन (जैसे, बूट, सिस्टम पार्टिशन) के लिए, रोलबैक की सुरक्षा लागू करना ज़रूरी है. साथ ही, इस्तेमाल किए जा सकने वाले कम से कम OS वर्शन का पता लगाने के लिए इस्तेमाल किए जाने वाले मेटाडेटा को सेव करने के लिए, टेंपर-एविडेंट स्टोरेज का इस्तेमाल करना ज़रूरी है.
[C-1-11] '9.12' के मुताबिक, बूटलोडर को अनलॉक और लॉक करने के दौरान, उपयोगकर्ता का सारा डेटा सुरक्षित तरीके से मिटाना ज़रूरी है. डेटा मिटाने की सुविधा' (इसमें उपयोगकर्ता डेटा का पार्टीशन और कोई भी एनवीआरएएम स्पेस शामिल है).
[C-SR-2] हमारा सुझाव है कि आप 'खास सुविधाओं वाले ऐप्लिकेशन' की सभी APK फ़ाइलों की पुष्टि, ट्रस्ट चेन की मदद से करें. यह चेन, पुष्टि किए गए बूट की सुविधा से सुरक्षित पार्टिशन पर आधारित होनी चाहिए.
[C-SR-3] हमारा सुझाव है कि किसी भी एक्ज़ीक्यूटेबल आर्टफ़ैक्ट को चलाने से पहले, उसकी पुष्टि करें. ये आर्टफ़ैक्ट, ऐक्सेस लेवल की सुविधाओं वाले ऐप्लिकेशन ने अपनी APK फ़ाइल के बाहर से लोड किए हैं. जैसे, डाइनैमिक तौर पर लोड किया गया कोड या संकलित कोड. हमारा सुझाव है कि इन आर्टफ़ैक्ट को बिलकुल भी न चलाएं.
ऐसे किसी भी कॉम्पोनेंट के लिए रोलबैक सुरक्षा लागू की जानी चाहिए जिसमें हमेशा चालू रहने वाला फ़र्मवेयर (जैसे, मॉडेम, कैमरा) हो. साथ ही, अनुमति वाले कम से कम वर्शन का पता लगाने के लिए इस्तेमाल किए जाने वाले मेटाडेटा को सेव करने के लिए, ऐसे स्टोरेज का इस्तेमाल किया जाना चाहिए जिससे बदलाव होने का पता चलता हो.

अगर डिवाइस को Android के पुराने वर्शन पर, C-1-8 से C-1-11 तक की शर्तों के बिना पहले ही लॉन्च किया जा चुका है और सिस्टम सॉफ़्टवेयर अपडेट की मदद से, इन शर्तों के लिए सहायता नहीं जोड़ी जा सकती, तो हो सकता है कि उन्हें इन शर्तों से छूट दी जाए.

अपस्ट्रीम Android Open Source Project, external/avb/ रिपॉज़िटरी में इस सुविधा को लागू करने का सुझाव देता है. इसे Android को लोड करने के लिए इस्तेमाल किए जाने वाले बूटलोडर में इंटिग्रेट किया जा सकता है.

डिवाइस में लागू करने के लिए:

[C-0-3] यह ज़रूरी है कि यह पूरी फ़ाइल को पढ़े बिना, किसी भरोसेमंद कुंजी के आधार पर फ़ाइल के कॉन्टेंट की क्रिप्टोग्राफ़िक तरीके से पुष्टि कर सके.
[C-0-4] अगर पढ़े गए कॉन्टेंट की पुष्टि किसी भरोसेमंद कुंजी से नहीं की जाती है, तो सुरक्षित फ़ाइल को पढ़ने के अनुरोधों को पूरा करने की अनुमति नहीं दी जानी चाहिए.

अगर डिवाइस में पहले से ही, Android के पुराने वर्शन पर किसी भरोसेमंद कुंजी की मदद से फ़ाइल के कॉन्टेंट की पुष्टि करने की सुविधा उपलब्ध नहीं है और सिस्टम सॉफ़्टवेयर के अपडेट की मदद से, इस सुविधा को जोड़ा नहीं जा सकता, तो हो सकता है कि डिवाइस को इस ज़रूरी शर्त से छूट दी जाए. अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट, Linux kernel fs-verity सुविधा के आधार पर, इस सुविधा को लागू करने का सुझाव देता है.

डिवाइस में लागू करने के लिए:

[C-SR-4] Android Protected Confirmation API का इस्तेमाल करने का सुझाव दिया जाता है.

अगर डिवाइस में सेट किए गए सिस्टम में Android Protected Confirmation API का इस्तेमाल किया जाता है, तो:

[C-3-1] ConfirmationPrompt.isSupported() एपीआई के लिए true की जानकारी देना ज़रूरी है.
[C-3-2] यह पक्का करना ज़रूरी है कि Android OS में चलने वाला कोड, उपयोगकर्ता के इंटरैक्शन के बिना कोई रिस्पॉन्स न जनरेट कर सके. इसमें, कोड का कर्नेल भी शामिल है, चाहे वह नुकसान पहुंचाने वाला हो या कोई और.
[C-3-3] यह पक्का करना ज़रूरी है कि उपयोगकर्ता ने मैसेज की समीक्षा करके उसे अनुमति दी हो. भले ही, Android OS और उसके कर्नेल को हैक कर लिया गया हो.

9.11. कुंजियां और क्रेडेंशियल

Android Keystore System की मदद से, ऐप्लिकेशन डेवलपर किसी कंटेनर में क्रिप्टोग्राफ़िक पासकोड सेव कर सकते हैं. साथ ही, KeyChain API या Keystore API की मदद से, क्रिप्टोग्राफ़िक ऑपरेशन में उनका इस्तेमाल कर सकते हैं. डिवाइस में लागू करने के लिए:

[C-0-1] कम से कम 8,192 कुंजियों को इंपोर्ट या जनरेट करने की अनुमति होनी चाहिए.
[C-0-2] लॉक स्क्रीन की पुष्टि करने की सुविधा में, गलत पासवर्ड डालने की कोशिशों के बीच समय अंतराल होना चाहिए. अगर n को असफल कोशिशों की संख्या माना जाए, तो 9 < n < 30 के लिए, समय अंतराल कम से कम 30 सेकंड होना चाहिए. अगर n > 29 है, तो समय अंतराल की वैल्यू कम से कम 30*2^floor((n-30)/10)) सेकंड या कम से कम 24 घंटे होनी चाहिए.
जनरेट की जा सकने वाली कुंजियों की संख्या को सीमित नहीं करना चाहिए

जब डिवाइस पर सुरक्षित लॉक स्क्रीन की सुविधा काम करती है, तो:

[C-1-1] ज़रूरी है कि अलग सेट अप किए गए प्रोग्राम के ज़रिए, पासकोड को सुरक्षित रखने वाले स्टोर का बैक अप लिया जाए.
[C-1-2] इसमें RSA, AES, ECDSA, और HMAC क्रिप्टोग्राफ़िक एल्गोरिदम और MD5, SHA1, और SHA-2 फ़ैमिली हैश फ़ंक्शन लागू होने चाहिए. इससे, Android Keystore सिस्टम के काम करने वाले एल्गोरिदम को सही तरीके से इस्तेमाल किया जा सकता है. यह एल्गोरिदम, कोर और उसके बाद के वर्शन पर चलने वाले कोड से सुरक्षित तरीके से अलग होता है. सुरक्षित आइसोलेशन, डीएमए के साथ-साथ आइसोलेट किए गए एनवायरमेंट की इंटरनल स्टेटस को ऐक्सेस करने के लिए, कर्नेल या यूज़रस्पेस कोड के सभी संभावित तरीकों को ब्लॉक करना चाहिए. अपस्ट्रीम 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 सेकंड होना चाहिए. वाहन से जुड़े ऐसे डिवाइसों में स्लीप टाइम आउट कॉन्फ़िगरेशन नहीं हो सकता जो हेड यूनिट बंद होने या उपयोगकर्ता के स्विच होने पर स्क्रीन लॉक कर देते हैं.
[C-1-6] यह ज़रूरी है कि यह इनमें से किसी एक के साथ काम करे:
- IKeymasterDevice 3.0,
- IKeymasterDevice 4.0,
- IKeymasterDevice 4.1 या
- IKeyMintDevice का वर्शन 1.
[C-SR-1] IKeyMintDevice के वर्शन 1 के साथ काम करने का सुझाव दिया जाता है.

9.11.1. सुरक्षित लॉक स्क्रीन और पुष्टि

AOSP को लागू करने के लिए, अलग-अलग लेवल वाले ऑथेंटिकेशन मॉडल का इस्तेमाल किया जाता है. इसमें, नॉलेज फ़ैक्ट्री पर आधारित मुख्य ऑथेंटिकेशन को, सेकंडरी लेवल के किसी बेहतर बायोमेट्रिक या तीसरे लेवल के किसी कम बेहतर मोडैलिटी से पुष्टि की जा सकती है.

डिवाइस में लागू करने के लिए:

[C-SR-1] पुष्टि करने के मुख्य तरीके के तौर पर, इनमें से सिर्फ़ एक को सेट करने का सुझाव दिया जाता है:
- अंकों वाला पिन
- अक्षर और अंकों वाला पासवर्ड
- 3x3 बिंदुओं के ग्रिड पर स्वाइप पैटर्न

ध्यान दें कि पुष्टि करने के ऊपर बताए गए तरीकों को, इस दस्तावेज़ में पुष्टि करने के मुख्य तरीकों के तौर पर सुझाया गया है.

अगर डिवाइस में पुष्टि करने के सुझाए गए मुख्य तरीकों को जोड़ा जाता है या उनमें बदलाव किया जाता है और स्क्रीन को लॉक करने के सुरक्षित तरीके के तौर पर पुष्टि करने के किसी नए तरीके का इस्तेमाल किया जाता है, तो पुष्टि करने का नया तरीका:

[C-2-1] यह पुष्टि करने का ऐसा तरीका होना चाहिए जैसा कि कुंजी के इस्तेमाल के लिए उपयोगकर्ता की पुष्टि करना ज़रूरी है में बताया गया है.

अगर डिवाइस में लॉक स्क्रीन को अनलॉक करने के लिए, पुष्टि करने के तरीकों को जोड़ा जाता है या उनमें बदलाव किया जाता है, तो यह ज़रूरी है कि वे किसी ऐसे गुप्त पासवर्ड पर आधारित हों जिसकी जानकारी पहले से हो. साथ ही, पुष्टि करने के नए तरीके का इस्तेमाल, स्क्रीन को लॉक करने के सुरक्षित तरीके के तौर पर किया जाना चाहिए:

[C-3-1] इनपुट की कम से कम अनुमति वाली लंबाई का एन्ट्रापी, 10 बिट से ज़्यादा होना चाहिए.
[C-3-2] सभी संभावित इनपुट की ज़्यादा से ज़्यादा एन्ट्रापी, 18 बिट से ज़्यादा होनी चाहिए.
[C-3-3] पुष्टि करने का नया तरीका, AOSP में लागू और दिए गए, पुष्टि करने के सुझाए गए मुख्य तरीकों (जैसे, पिन, पैटर्न, पासवर्ड) को बदलना चाहिए.
[C-3-4] अगर डिवाइस नीति कंट्रोलर (डीपीसी) ऐप्लिकेशन ने DevicePolicyManager.setRequiredPasswordComplexity() के ज़रिए, पासवर्ड की ज़रूरी शर्तों की नीति को PASSWORD_COMPLEXITY_NONE से ज़्यादा पाबंदी वाले कॉन्स्टेंट के साथ सेट किया है या DevicePolicyManager.setPasswordQuality() के ज़रिए, PASSWORD_QUALITY_BIOMETRIC_WEAK से ज़्यादा पाबंदी वाले कॉन्स्टेंट के साथ सेट किया है, तो पुष्टि करने का नया तरीका बंद होना चाहिए.
[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] अगर डिवाइस नीति कंट्रोलर (डीपीसी) ऐप्लिकेशन ने PASSWORD_COMPLEXITY_LOW से ज़्यादा पाबंदी वाली जटिलता वाली बकेट के साथ DevicePolicyManager.setRequiredPasswordComplexity() के ज़रिए पासवर्ड की ज़रूरी शर्तों की क्वालिटी नीति सेट की है या PASSWORD_QUALITY_BIOMETRIC_WEAK से ज़्यादा पाबंदी वाली क्वालिटी कॉन्स्टेंट के साथ DevicePolicyManager.setPasswordQuality() का इस्तेमाल किया है, तो इन तरीकों को बंद करना ज़रूरी है.
[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) वाला तरीका
- PASSWORD_QUALITY_NONE के मुकाबले, क्वालिटी के लिए ज़्यादा पाबंदी वाला DevicePolicyManager.setPasswordQuality() तरीका.
- PASSWORD_COMPLEXITY_NONE के मुकाबले, ज़्यादा पाबंदी वाली जटिलता वाली बकेट वाला DevicePolicyManager.setRequiredPasswordComplexity() तरीका.
[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_NONE से ज़्यादा पाबंदी वाला क्वालिटी कॉन्स्टेंट या DevicePolicyManager.setRequiredPasswordComplexity() के ज़रिए सेट किया गया हो, तो भी नया तरीका बंद करना ज़रूरी है. साथ ही, 'PASSWORD_COMPLEXITY_NONE' से ज़्यादा पाबंदी वाला कॉन्स्टेंट इस्तेमाल किया गया हो, तो भी नया तरीका बंद करना ज़रूरी है.
[C-8-2] उन्हें DevicePolicyManager.setPasswordExpirationTimeout() से सेट किए गए, पासवर्ड की समयसीमा खत्म होने के टाइमर को रीसेट नहीं करना चाहिए.
[C-8-3] उन्हें तीसरे पक्ष के ऐप्लिकेशन के इस्तेमाल के लिए, एपीआई को ज़ाहिर नहीं करना चाहिए, ताकि वे लॉक की स्थिति बदल सकें.

अगर डिवाइस में DeviceStateManager के ज़रिए डिसप्ले की अलग-अलग पावर स्टेटस और KeyguardDisplayManager के ज़रिए डिसप्ले की अलग-अलग लॉक स्टेटस की सुविधा काम करती है, तो:

[C-SR-2] डिफ़ॉल्ट डिवाइस डिसप्ले से डिवाइस को अनलॉक करने की सुविधा देने के लिए, हमारा सुझाव है कि आप सेक्शन 9.11.1 में बताई गई क्रेडेंशियल की ज़रूरी शर्तों को पूरा करने वाले क्रेडेंशियल या सेक्शन 7.3.10 में बताई गई कम से कम क्लास 1 की शर्तों को पूरा करने वाले बायोमेट्रिक तरीके का इस्तेमाल करें.
[C-SR-3] डिसप्ले के लिए तय किए गए टाइम आउट की मदद से, डिसप्ले को अलग से अनलॉक करने की सुविधा को सीमित करने का सुझाव दिया जाता है.
[C-SR-4] हमारा सुझाव है कि उपयोगकर्ता को मुख्य हैंडहेल्ड डिवाइस से लॉकडाउन की सुविधा का इस्तेमाल करके, दुनिया भर में सभी डिसप्ले को लॉक करने की अनुमति दें.

9.11.2. StrongBox

Android Keystore System की मदद से, ऐप्लिकेशन डेवलपर, क्रिप्टोग्राफ़िक पासकोड को एक खास सुरक्षित प्रोसेसर में सेव कर सकते हैं. साथ ही, ऊपर बताए गए अलग-अलग प्रोसेसिंग एनवायरमेंट में भी सेव कर सकते हैं. इस तरह के खास सिक्योर प्रोसेसर को "स्ट्रॉन्गबॉक्स" कहा जाता है. यहां C-1-3 से C-1-11 तक की ज़रूरी शर्तों के बारे में बताया गया है. इन शर्तों को पूरा करने पर ही किसी डिवाइस को StrongBox के तौर पर मंज़ूरी दी जाती है.

डिवाइस में सेट किए हुए ऐसे सिस्टम जिनमें खास तौर पर सुरक्षित प्रोसेसर होता है:

[C-SR-1] 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-2] हमारा सुझाव है कि आप ऐसा हार्डवेयर शामिल करें जिसका आकलन, सुरक्षा टारगेट, आकलन के लिए भरोसेमंद लेवल (EAL) 5 का इस्तेमाल करके किया गया हो. साथ ही, AVA_VAN.5 की मदद से इसकी सुरक्षा को बेहतर बनाया गया हो. आने वाले समय में रिलीज़ किए जाने वाले वर्शन के लिए, EAL 5 सर्टिफ़िकेशन होना ज़रूरी हो सकता है.
[C-SR-3] का सुझाव, अंदरूनी हमले से सुरक्षा (आईएआर) देने के लिए ज़रूर दिया जाता है. इसका मतलब है कि फ़र्मवेयर साइनिंग पासकोड का ऐक्सेस रखने वाला कोई भी व्यक्ति, ऐसा फ़र्मवेयर नहीं बना सकता जिससे StrongBox से गोपनीय जानकारी लीक हो. साथ ही, वह फ़ंक्शनल सुरक्षा से जुड़ी ज़रूरी शर्तों को बायपास नहीं कर सकता या उपयोगकर्ता के संवेदनशील डेटा को ऐक्सेस नहीं कर सकता. आईएआर को लागू करने का सुझाया गया तरीका यह है कि फ़र्मवेयर अपडेट करने की अनुमति सिर्फ़ तब दें, जब उपयोगकर्ता का मुख्य पासवर्ड IAuthSecret HAL के ज़रिए दिया गया हो.

9.11.3. आइडेंटिटी क्रेडेंशियल

android.security.identity.* पैकेज में सभी एपीआई लागू करके, आइडेंटिटी क्रेडेंशियल सिस्टम को तय किया जाता है और उसे हासिल किया जाता है. इन एपीआई की मदद से, ऐप्लिकेशन डेवलपर उपयोगकर्ता की पहचान से जुड़े दस्तावेज़ों को सेव और वापस पा सकते हैं. डिवाइस में लागू करने के लिए:

[C-SR-1] आइडेंटिटी क्रेडेंशियल सिस्टम को लागू करने का सुझाव दिया जाता है.

अगर डिवाइस में पहचान की पुष्टि करने के लिए क्रेडेंशियल सिस्टम लागू किया जाता है, तो:

[C-1-1] IdentityCredentialStore#getInstance() तरीके के लिए, नॉल की वैल्यू नॉल नहीं होनी चाहिए.
[C-1-2] पहचान की पुष्टि करने वाले सिस्टम (उदाहरण के लिए, android.security.identity.* एपीआई) को लागू करना ज़रूरी है.इसके लिए, कोड को किसी ऐसे ऐप्लिकेशन के साथ काम करना चाहिए जिस पर भरोसा किया जा सकता हो. साथ ही, यह कोड, कोर और उसके बाद के लेवल पर चलने वाले कोड से सुरक्षित तौर पर अलग होना चाहिए. सुरक्षित आइसोलेशन की सुविधा, उन सभी संभावित तरीकों को ब्लॉक करनी चाहिए जिनकी मदद से कर्नेल या यूज़रस्पेस कोड, डीएमए के साथ-साथ आइसोलेट किए गए एनवायरमेंट की इंटरनल स्टेटस को ऐक्सेस कर सकता है.
[C-1-3] पहचान की पुष्टि करने वाले क्रेडेंशियल सिस्टम (जैसे, android.security.identity.* एपीआई) को लागू करने के लिए, क्रिप्टोग्राफ़िक ऑपरेशन पूरी तरह से भरोसेमंद ऐप्लिकेशन में किए जाने चाहिए. साथ ही, निजी कुंजी का कॉन्टेंट, अलग से चलाए जाने वाले एनवायरमेंट से कभी बाहर नहीं निकलना चाहिए. ऐसा तब तक नहीं होना चाहिए, जब तक कि उच्च लेवल के एपीआई (जैसे, createEphemeralKeyPair() तरीका) के लिए ज़रूरी न हो.
[C-1-4] भरोसेमंद ऐप्लिकेशन को इस तरह से लागू किया जाना चाहिए कि उसकी सुरक्षा से जुड़ी प्रॉपर्टी पर कोई असर न पड़े. उदाहरण के लिए, ऐक्सेस कंट्रोल की शर्तें पूरी होने तक क्रेडेंशियल का डेटा रिलीज़ नहीं किया जाता. साथ ही, मनमुताबिक डेटा के लिए एमएसी नहीं बनाए जा सकते. भले ही, Android ठीक से काम न कर रहा हो या उसमें कोई गड़बड़ी हो.

9.12. डेटा हटाना

सभी डिवाइसों पर लागू होने वाले सिस्टम के लिए:

[C-0-1] उपयोगकर्ताओं को "फ़ैक्ट्री डेटा रीसेट" करने का तरीका देना ज़रूरी है.
[C-0-2] "फ़ैक्ट्री डेटा रीसेट" करने के दौरान, उपयोगकर्ता डेटा फ़ाइल सिस्टम पर मौजूद सारा डेटा मिटाना ज़रूरी है.
[C-0-3] डेटा को इस तरह मिटाएं कि "फ़ैक्ट्री डेटा रीसेट" करते समय, उद्योग के मानकों को पूरा किया जा सके. जैसे, NIST SP800-88.
[C-0-4] जब मुख्य उपयोगकर्ता के डिवाइस नीति नियंत्रक ऐप्लिकेशन से DevicePolicyManager.wipeData() एपीआई को कॉल किया जाता है, तो ऊपर दी गई "फ़ैक्ट्री डेटा रीसेट" प्रोसेस को ट्रिगर करना ज़रूरी है.
डेटा को तुरंत मिटाने का विकल्प दे सकता है. हालांकि, यह विकल्प सिर्फ़ उस डेटा को मिटाता है जो काम का नहीं है.

9.13. सेफ़ बूट मोड

Android में सेफ़ बूट मोड की सुविधा उपलब्ध है. इस मोड में, डिवाइस को सिर्फ़ पहले से इंस्टॉल किए गए सिस्टम ऐप्लिकेशन चलाने की अनुमति होती है. साथ ही, तीसरे पक्ष के सभी ऐप्लिकेशन बंद हो जाते हैं. इस मोड को "सेफ़ बूट मोड" कहा जाता है. इससे उपयोगकर्ता को, तीसरे पक्ष के ऐसे ऐप्लिकेशन अनइंस्टॉल करने की सुविधा मिलती है जो नुकसान पहुंचा सकते हैं.

डिवाइस में सेट किए जाने वाले सिस्टम के लिए:

[C-SR-1] सेफ़ बूट मोड लागू करने का सुझाव दिया जाता है.

अगर डिवाइस में सेट किए गए सिस्टम में सेफ़ बूट मोड लागू किया जाता है, तो:

[C-1-1] डिवाइस पर इंस्टॉल किए गए तीसरे पक्ष के ऐप्लिकेशन, डिवाइस के सेफ़ बूट मोड में जाने की प्रक्रिया को बीच में न रोक सकें. हालांकि, अगर तीसरे पक्ष का ऐप्लिकेशन डिवाइस नीति कंट्रोल करने वाला ऐप्लिकेशन है और उसने UserManager.DISALLOW_SAFE_BOOT फ़्लैग को 'सही' के तौर पर सेट किया है, तो यह ज़रूरी नहीं है.
[C-1-2] उपयोगकर्ता को सुरक्षित मोड में, तीसरे पक्ष के किसी भी ऐप्लिकेशन को अनइंस्टॉल करने की सुविधा देनी चाहिए.
उपयोगकर्ता को, बूट मेन्यू से सुरक्षित मोड में जाने का विकल्प देना चाहिए. इसके लिए, सामान्य बूट से अलग वर्कफ़्लो का इस्तेमाल किया जाना चाहिए.

9.14. वाहन के सिस्टम को आइसोलेट करना

Android Automotive डिवाइसों को, वाहन के अहम सबसिस्टम के साथ डेटा शेयर करना चाहिए. इसके लिए, उन्हें वाहन के HAL का इस्तेमाल करना होगा. इससे, 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 12 के लिए CTS के कई वर्शन रिलीज़ किए जा सकते हैं.

डिवाइस में लागू करने के लिए:

[C-0-3] डिवाइस के सॉफ़्टवेयर के पूरा होने के समय, CTS के सबसे नए वर्शन को पास करना ज़रूरी है.
ज़्यादा से ज़्यादा, Android Open Source tree में रेफ़रंस के तौर पर लागू किए गए तरीके का इस्तेमाल करना चाहिए.

10.2. सीटीएस की पुष्टि करने वाला टूल

CTS Verifier, Compatibility Test Suite में शामिल है. इसे किसी व्यक्ति को चलाना होता है, ताकि ऐसी सुविधाओं की जांच की जा सके जिनकी जांच ऑटोमेटेड सिस्टम से नहीं की जा सकती. जैसे, कैमरे और सेंसर की सही तरीके से काम करना.

डिवाइस में लागू करने के लिए:

[C-0-1] सीटीएस की पुष्टि करने वाले टूल में, लागू होने वाले सभी केस सही तरीके से लागू होने चाहिए.

सीटीएस की पुष्टि करने वाले टूल में कई तरह के हार्डवेयर के लिए टेस्ट होते हैं. इनमें कुछ ऐसे हार्डवेयर भी शामिल हैं जिनका इस्तेमाल करना ज़रूरी नहीं है.

डिवाइस में लागू करने के लिए:

[C-0-2] यह ज़रूरी है कि डिवाइस में मौजूद हर हार्डवेयर के लिए, सभी टेस्ट पास किए जाएं. उदाहरण के लिए, अगर डिवाइस में एक्सलरोमीटर है, तो उसे CTS Verifier में एक्सलरोमीटर टेस्ट केस को सही तरीके से पूरा करना होगा.

इस दस्तावेज़ में, जिन सुविधाओं को ज़रूरी नहीं बताया गया है उनके लिए टेस्ट केस को छोड़ा जा सकता है या हटाया जा सकता है.

[C-0-2] ऊपर बताए गए मुताबिक, हर डिवाइस और हर बिल्ड में CTS Verifier सही तरीके से काम करना चाहिए. हालांकि, कई बिल्ड काफ़ी मिलते-जुलते होते हैं. इसलिए, डिवाइस को लागू करने वाले लोगों को उन बिल्ड पर सीटीएस की पुष्टि करने वाले टूल को साफ़ तौर पर चलाने की ज़रूरत नहीं होती जो सिर्फ़ मामूली अंतरों में अलग होते हैं. खास तौर पर, डिवाइस में लागू किए गए ऐसे सिस्टम के लिए, CTS Verifier टेस्ट की ज़रूरत नहीं होती है जो सिर्फ़ शामिल की गई भाषाओं, ब्रैंडिंग वगैरह के सेट के हिसाब से, CTS Verifier की मंज़ूरी पा चुके सिस्टम से अलग होते हैं.

11. अपडेट किया जा सकने वाला सॉफ़्टवेयर

[C-0-1] डिवाइस में लागू किए गए सिस्टम में, पूरे सिस्टम सॉफ़्टवेयर को बदलने का तरीका शामिल होना चाहिए. इस प्रोसेस में, "लाइव" अपडेट करने की ज़रूरत नहीं होती. इसका मतलब है कि डिवाइस को रीस्टार्ट करना पड़ सकता है. किसी भी तरीके का इस्तेमाल किया जा सकता है. हालांकि, यह ज़रूरी है कि वह डिवाइस में पहले से इंस्टॉल किए गए सभी सॉफ़्टवेयर को बदल सके. उदाहरण के लिए, इनमें से कोई भी तरीका अपनाने पर, यह ज़रूरी शर्त पूरी हो जाएगी:
- रीबूट करने के बाद, ऑफ़लाइन अपडेट के साथ "ओवर-द-एयर (ओटीए)" डाउनलोड.
- होस्ट पीसी से यूएसबी के ज़रिए "टethered" अपडेट.
- रीबूट करने और हटाने लायक स्टोरेज में मौजूद फ़ाइल से अपडेट करने के ज़रिए, "ऑफ़लाइन" अपडेट.
[C-0-2] अपडेट करने के लिए इस्तेमाल किए गए तरीके से, उपयोगकर्ता का डेटा मिटाए बिना अपडेट किए जाने चाहिए. इसका मतलब है कि अपडेट करने की प्रोसेस में, ऐप्लिकेशन का निजी डेटा और ऐप्लिकेशन का शेयर किया गया डेटा सुरक्षित रखना ज़रूरी है. ध्यान दें कि अपस्ट्रीम Android सॉफ़्टवेयर में, अपडेट करने का एक ऐसा तरीका शामिल होता है जो इस ज़रूरी शर्त को पूरा करता है.
[C-0-3] पूरे अपडेट पर हस्ताक्षर होना चाहिए. साथ ही, डिवाइस पर अपडेट करने की सुविधा, डिवाइस पर सेव किए गए सार्वजनिक पासकोड के आधार पर, अपडेट और हस्ताक्षर की पुष्टि करनी चाहिए.
[C-SR-1] साइन करने के तरीके के लिए, अपडेट को SHA-256 के साथ हैश करने का सुझाव दिया जाता है. साथ ही, ECDSA NIST P-256 का इस्तेमाल करके, हैश की पुष्टि सार्वजनिक कुंजी के साथ की जानी चाहिए.

अगर डिवाइस में 802.11 या ब्लूटूथ पैन (निजी एरिया नेटवर्क) प्रोफ़ाइल जैसे बिना मीटर वाले डेटा कनेक्शन के लिए सहायता शामिल है, तो:

[C-1-1] डिवाइस को रीबूट करके, ऑफ़लाइन अपडेट के साथ ओटीए डाउनलोड की सुविधा होनी चाहिए.

डिवाइस में लागू करने के दौरान, यह पुष्टि की जानी चाहिए कि ओटीए के बाद, सिस्टम इमेज और उम्मीद के मुताबिक नतीजे की बाइनरी एक जैसी हो. Android Open Source Project में, ब्लॉक के आधार पर ओटीए अपडेट करने की सुविधा को Android 5.1 के बाद जोड़ा गया था. यह सुविधा इस ज़रूरी शर्त को पूरा करती है.

साथ ही, डिवाइस में सेट किए गए सिस्टम में 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 के साथ काम करने वाले डिवाइसों के बारे में जानकारी देने वाले फ़ोरम में शामिल होकर, इस बारे में ज़्यादा जानकारी मांगी जा सकती है. इसके अलावा, अगर आपको लगता है कि दस्तावेज़ में किसी समस्या के बारे में नहीं बताया गया है, तो उसके बारे में भी बताया जा सकता है.