साल 2026 से, हम अपने ट्रंक स्टेबल डेवलपमेंट मॉडल के साथ अलाइन होने के लिए, दूसरी और चौथी तिमाही में AOSP पर सोर्स कोड पब्लिश करेंगे. इससे यह पक्का किया जा सकेगा कि प्लैटफ़ॉर्म, पूरे सिस्टम के लिए स्थिर बना रहे. हमारा सुझाव है कि AOSP को बनाने और उसमें योगदान देने के लिए, aosp-main के बजाय android-latest-release का इस्तेमाल करें. android-latest-release मेनिफ़ेस्ट ब्रांच, हमेशा AOSP पर पुश की गई सबसे नई रिलीज़ का रेफ़रंस देगी. ज़्यादा जानकारी के लिए, AOSP में हुए बदलाव लेख पढ़ें.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Android 17 के साथ काम करने से जुड़ी परिभाषा [प्रीव्यू]

1. परिचय

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2.1. हार्डवेयर

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

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

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

[7.1.4.2/H-1-1] Android Baseline 2021 प्रोफ़ाइल में बताई गई ज़रूरी शर्तों को पूरा करना ज़रूरी है.

अगर हैंडहेल्ड डिवाइसों पर लागू किए गए किसी 64-बिट एबीआई के साथ काम करने का दावा करते हैं (किसी 32-बिट एबीआई के साथ या उसके बिना) और ActivityManager.isLowRamDevice() के लिए false वैल्यू दिखाते हैं, तो:

[7.1.4.2/H-2-1] Vulkan 1.1 या इसके बाद के वर्शन के साथ काम करना ज़रूरी है.

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

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

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

अगर हाथ में पकड़े जाने वाले डिवाइसों में 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.1/H-1-1] android.hardware.telephony.data फ़ीचर फ़्लैग के बारे में एलान करना ज़रूरी है.

हाथ में पकड़कर इस्तेमाल किए जाने वाले ऐसे डिवाइस जिनमें ब्लूटूथ LE की सुविधा काम करती है:

[7.4.3/H-SR-1] यह सुझाव दिया जाता है कि डिवाइस में, Bluetooth LE Data Packet Length Extension की सुविधा काम करे.

ध्यान दें: Android के आने वाले वर्शन में, इस ज़रूरी शर्त [7.4.3/H-SR-1] को शामिल करना ज़रूरी हो जाएगा.

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

[7.4.2.4/H-1-1] में Wi-Fi Passpoint के लिए सहायता शामिल होनी चाहिए.

अगर डिवाइस, PackageManager.FEATURE_WIFI_AWARE को वाई-फ़ाई नेबर अवेयरनेस नेटवर्किंग (एनएएन) प्रोटोकॉल और PackageManager.FEATURE_WIFI_RTT को वाई-फ़ाई लोकेशन (वाई-फ़ाई राउंड ट्रिप टाइम — आरटीटी) के तौर पर सेट करते हैं, तो:

[7.4.2.5/H-1-1] WifiRttManager#startRanging Android API के ज़रिए, 10 सेंटीमीटर, 1 मीटर, 3 मीटर, और 5 मीटर की दूरी पर, रेंज की सटीक जानकारी देनी होगी. यह जानकारी, 68वें पर्सेंटाइल पर 160 मेगाहर्ट्ज़ बैंडविथ के लिए +/-1 मीटर, 68वें पर्सेंटाइल पर 80 मेगाहर्ट्ज़ बैंडविथ के लिए +/-2 मीटर, 68वें पर्सेंटाइल पर 40 मेगाहर्ट्ज़ बैंडविथ के लिए +/-4 मीटर, और 68वें पर्सेंटाइल पर 20 मेगाहर्ट्ज़ बैंडविथ के लिए +/-8 मीटर के अंतर में होनी चाहिए. पर्सेंटाइल की गणना, कम्युलेटिव डिस्ट्रिब्यूशन फ़ंक्शन के हिसाब से की जाती है.
[7.4.2.5/H-SR-1] यह सुझाव दिया जाता है कि 10 सेंटीमीटर की दूरी पर, 90वें पर्सेंटाइल (संचयी बंटन फ़ंक्शन के हिसाब से कैलकुलेट किया गया) पर 160 मेगाहर्ट्ज़ बैंडविड्थ के लिए +/-1 मीटर, 90वें पर्सेंटाइल पर 80 मेगाहर्ट्ज़ बैंडविड्थ के लिए +/-2 मीटर, 90वें पर्सेंटाइल पर 40 मेगाहर्ट्ज़ बैंडविड्थ के लिए +/-4 मीटर, और 90वें पर्सेंटाइल पर 20 मेगाहर्ट्ज़ बैंडविड्थ के लिए +/-8 मीटर की रेंज को सटीक तौर पर रिपोर्ट किया जाए. यह रेंज, WifiRttManager#startRanging Android API के ज़रिए देखी गई है.

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

अगर हाथ में रखे जाने वाले डिवाइस, PackageManager.FEATURE_WIFI_PD का एलान करके वाई-फ़ाई नज़दीकी डिवाइसों का पता लगाने (पीडी) के प्रोटोकॉल और PackageManager.FEATURE_WIFI_RTT का एलान करके वाई-फ़ाई की जगह की जानकारी (वाई-फ़ाई राउंड ट्रिप टाइम — आरटीटी) का इस्तेमाल करते हैं, तो:

[7.4.2.10/H-1-1] कम से कम 160 मेगाहर्ट्ज़ बैंडविड्थ का इस्तेमाल करना ज़रूरी है.
[7.4.2.10/H-1-2] WifiRttManager#startRanging Android API के ज़रिए, 68वें पर्सेंटाइल पर 160 मेगाहर्ट्ज़ बैंडविड्थ पर +/-0.25 मीटर के अंदर सटीक रेंज की जानकारी देना ज़रूरी है. इसकी गणना, संचयी बंटन फ़ंक्शन के ज़रिए की जाती है.

हमारा सुझाव है कि आप उपयोगकर्ता की मौजूदगी का पता लगाने की सुविधा को कैलिब्रेट करना में दिए गए मेज़रमेंट सेटअप के चरणों का पालन करें.

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

[7.4.3/H-1-3] यह ज़रूरी है कि डिवाइस, Rx ऑफ़सेट को मेज़र करे और उसकी भरपाई करे, ताकि यह पक्का किया जा सके कि बीएलई आरएसएसआई का मीडियन, ADVERTISE_TX_POWER_HIGH पर ट्रांसमिट करने वाले रेफ़रंस डिवाइस से 1 मीटर की दूरी पर -50 dBm +/-15 dB हो.
[7.4.3/H-1-4] Tx ऑफ़सेट को मेज़र करना और उसकी भरपाई करना ज़रूरी है, ताकि यह पक्का किया जा सके कि 1 मीटर की दूरी पर रखे गए रेफ़रंस डिवाइस से स्कैन करने पर, बीएलई आरएसएसआई का मीडियन -50 dBm +/-15 dB हो. साथ ही, यह डिवाइस ADVERTISE_TX_POWER_HIGH पर ट्रांसमिट कर रहा हो.

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

[7.5.1/H-1-1] इसका रिज़ॉल्यूशन कम से कम 2 मेगापिक्सल होना चाहिए.

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

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

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

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

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

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

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

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

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

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

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

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

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

अगर हैंडहेल्ड डिवाइसों में, कर्नल और यूज़रस्पेस के लिए 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 का एलान करना ज़रूरी है.

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

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

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

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

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

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

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

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

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

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

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

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

हैंडहेल्ड डिवाइस में सेट किए हुए सिस्टम के लिए ज़रूरी है कि वे android.hardware.audio.output और android.hardware.microphone का एलान करें. इसके लिए, सेक्शन 5.6 में आरटीएल और टीटीएल की ज़रूरी शर्तें देखें.

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

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

[7.10/H] SHOULD position the placement of the actuator near the location where the device is typically held or touched by hands.
[7.10/H] डिवाइस के नैचुरल ओरिएंटेशन के X-ऐक्सिस (बाएं-दाएं) में हैप्टिक ऐक्चुएटर को मूव करना चाहिए.

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

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

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

[7.10/H]^* को android.os.Vibrator.areAllEffectsSupported() और android.os.Vibrator.arePrimitivesSupported() एपीआई चलाकर, लागू करने की स्थिति की पुष्टि करनी चाहिए.
[7.10/H]^* को हैप्टिक कॉन्स्टेंट के लिए, क्वालिटी असेसमेंट करना चाहिए.
[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 प्रोफ़ाइल (AAC+)
[5.1/H-0-5] AAC ELD (बेहतर लो डिले एएसी)

[5.1/H-0-6] MPEG-D DRC के साथ MPEG-D USAC (Extended High Efficiency AAC)

2.2.3. सॉफ़्टवेयर

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

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

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

[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
[5.3/H-0-6] AV1

2.2.3. सॉफ़्टवेयर

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

[3.2.3.1/H-0-1] ऐप्लिकेशन में, एसडीके के दस्तावेज़ों में बताए गए ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE, और ACTION_CREATE_DOCUMENT इंटेंट को हैंडल करने की सुविधा होनी चाहिए. साथ ही, DocumentsProvider एपीआई का इस्तेमाल करके, दस्तावेज़ उपलब्ध कराने वाली कंपनी के डेटा को ऐक्सेस करने की सुविधा भी होनी चाहिए.

[3.2.3.1/H-0-2]^* को, एक या उससे ज़्यादा ऐप्लिकेशन या सेवा कॉम्पोनेंट को इंटेंट हैंडलर के साथ प्रीलोड करना होगा. ऐसा, यहां दी गई सूची में शामिल ऐप्लिकेशन इंटेंट के लिए तय किए गए सभी सार्वजनिक इंटेंट फ़िल्टर पैटर्न के लिए करना होगा. ध्यान दें: "सामान्य ऐप्लिकेशन इंटेंट" पेज में, ज़रूरी नया इंटेंट "android.settings.VPN_APP_EXCLUSION_SETTINGS" शामिल होगा.

[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-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.2/H-0-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] डिवाइस पर असिस्टेंट को लागू करने का सुझाव दिया जाता है, ताकि असिस्ट ऐक्शन को हैंडल किया जा सके.

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

[3.8.3.1/H-SR-2] सिस्टम यूज़र इंटरफ़ेस (यूआई) से ऐक्सेस की जा सकने वाली, उपयोगकर्ता के लिए उपलब्ध सुविधा (उदाहरण के लिए, आउटपुट स्विचर) उपलब्ध कराने का सुझाव दिया जाता है. इससे उपयोगकर्ता, मीडिया के लिए उपलब्ध सही रास्तों (उदाहरण के लिए, ब्लूटूथ डिवाइस और MediaRouter2Manager को उपलब्ध कराए गए रास्ते) के बीच स्विच कर सकते हैं. ऐसा तब किया जा सकता है, जब कोई ऐप्लिकेशन MediaSession टोकन के साथ MediaStyle सूचना पोस्ट करता है.

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

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

[3.8.3.1/H-0-1] लॉकस्क्रीन पर, लाइव अपडेट की प्रमोशन वाली सूचना को प्रमुखता से दिखाना ज़रूरी है.
[3.8.3.1/H-0-12] सूचनाओं के स्टैक में सबसे ऊपर स्क्रीन पर सबसे ऊपर सूचना देने वाला कार्ड दिखना चाहिए. साथ ही, रंगीन सूचनाओं (जहां setColorized, true है) के ऊपर दिखना चाहिए. ऐसा तब होना चाहिए, जब प्रमोट की गई लाइव अपडेट की सूचना, अन्य सूचनाओं के बीच दिखाई जाती है.
- MAY, सूचना पैनल और लॉक स्क्रीन पर दिखने वाली, प्रमोट की गई लाइव अपडेट की सूचनाओं के क्रम का फ़ैसला कर सकता है. ऐसा तब किया जाता है, जब एक से ज़्यादा ऐप्लिकेशन, प्रमोट की गई लाइव अपडेट की सूचना दिखाने की ज़रूरी शर्तें पूरी करते हों.
[3.8.3.1/H-0-2] प्रमोट की गई लाइव अपडेट सूचना को बड़े किए गए फ़ॉर्मैट में दिखाना ज़रूरी है.
[3.8.3.1/H-0-3] ऊपर दी गई बड़ी की गई सूचना को छोटा करने के लिए, उपयोगकर्ता को कोई सुविधा नहीं देनी चाहिए.
[3.8.3.1/H-0-4] यह ज़रूरी है कि प्रमोट की गई लाइव अपडेट सूचना में, टेक्स्ट कॉन्टेंट के बेसिक स्टाइल (बोल्ड, इटैलिक, और अंडरलाइन) दिखाए जाएं. ये स्टाइल StyleSpan या UnderlineSpan से उपलब्ध कराई जाती हैं.
[3.8.3.1/H-0-5] MUST display only standard action objects (via Notification.Action), and MUST hide non-standard action objects such as input boxes, reply buttons, and contextual actions (via addRemoteInput() and setContextual()) in a Promoted Live Update Notification, even when the notification contains them.
[3.8.3.1/H-0-6] एसडीके के दस्तावेज़ में, प्रमोट की गई लाइव अपडेट सूचना के लिए कॉम्पैक्ट रिप्रेजेंटेशन दिखाना ज़रूरी है. इसे स्टेटस चिप भी कहा जाता है. इसमें Notification.getSmallIcon() शामिल होना ज़रूरी है.
- [3.8.3.1/H-0-7] कॉम्पैक्ट रिप्रेजेंटेशन के लिए, अन्य फ़ील्ड वैकल्पिक होते हैं. हालांकि, जब भी कॉम्पैक्ट रिप्रेजेंटेशन को बड़ा किया जा सकता है, तब Notification.getShortCriticalText() को दिखाना ज़रूरी है. ऐसा तब होता है, जब Notification.getShortCriticalText मौजूद न हो. अगर Notification.getShortCriticalText मौजूद है, तो Notification.when को दिखाना ज़रूरी है.
- [3.8.3.1/H-0-8] जब एक से ज़्यादा लाइव अपडेट की सूचनाएं मौजूद हों, तो स्टेटस बार में कम से कम एक सूचना को कॉम्पैक्ट तरीके से दिखाना ज़रूरी है.
- [3.8.3.1/H-0-9] जब उपयोगकर्ता कॉम्पैक्ट वर्शन पर टैप करता है, तो उसे इससे जुड़ी सूचना (सुझाया गया) दिखनी चाहिए या इससे जुड़ा ऐप्लिकेशन (Notification.contentIntent के ज़रिए) खुलना चाहिए.
- [3.8.3.1/H-0-13] सूचना शेड में उपलब्ध कॉन्टेंट और उससे जुड़ी सूचना में मौजूद कॉन्टेंट एक जैसा होना चाहिए.
[3.8.3.1/H-0-10] उपयोगकर्ता को किसी ऐप्लिकेशन की सूचनाओं को बंद और चालू करने की सुविधा देना ज़रूरी है.
[3.8.3.1/H-0-11] लाइव अपडेट की सभी सूचनाएं सही तरीके से रेंडर होनी चाहिए. इनमें, प्रमोशन वाली लाइव अपडेट की सूचनाएं शामिल हैं. हालांकि, इनमें ऐसी सूचनाएं भी शामिल हैं जिनका प्रमोशन नहीं किया गया है और जो प्रमोशन की शर्तों को पूरा नहीं करती हैं या सिर्फ़ कुछ शर्तों को पूरा करती हैं. प्रमोशन के बिना दिखाई जाने वाली ऐसी सूचनाएं, प्रमोशन के बिना ही दिखनी चाहिए.

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

[3.8.3/H-1-1] स्क्रीन पिन करने की सुविधा को लागू करना ज़रूरी है. साथ ही, उपयोगकर्ता को सेटिंग मेन्यू उपलब्ध कराना ज़रूरी है, ताकि वह इस सुविधा को टॉगल कर सके.

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

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

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

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

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

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

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

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

अगर हैंडहेल्ड डिवाइस में सेट किए गए सिस्टम में 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-1-5] उपयोगकर्ता को, ऐप्लिकेशन के लिए तय किए गए, पुष्टि करने के लिए सामान्य डिवाइस कंट्रोल से ऑप्ट आउट करने का विकल्प देना ज़रूरी है. ये कंट्रोल, तीसरे पक्ष के ऐप्लिकेशन ने ControlsProviderService और Control Control.isAuthRequired API के ज़रिए रजिस्टर किए हैं.
[3.8.16/H-1-6] डिवाइसों पर, उपयोगकर्ता को मिलने वाली सुविधाओं को इस तरह से सटीक तौर पर रेंडर करना ज़रूरी है:
- अगर डिवाइस में config_supportsMultiWindow=true सेट है और ऐप्लिकेशन, ControlsProviderService डिक्लेरेशन में META_DATA_PANEL_ACTIVITY मेटाडेटा का एलान करता है, तो ऐप्लिकेशन को इस उपयोगकर्ता सुविधा में, एपीआई के हिसाब से मान्य गतिविधि का कॉम्पोनेंट नेम शामिल करना होगा.
- अगर ऐप्लिकेशन, मेटाडेटा META_DATA_PANEL_ACTIVITY का एलान नहीं करता है, तो उसे ControlsProviderService एपीआई के साथ-साथ Control एपीआई से मिले सभी फ़ील्ड को रेंडर करना होगा.
[3.8.16/H-1-7] अगर ऐप्लिकेशन, मेटाडेटा META_DATA_PANEL_ACTIVITY के बारे में बताता है, तो उसे [3.8.16/H-1-5] में तय की गई सेटिंग को पास करना होगा. इसके लिए, उसे एम्बेड की गई गतिविधि लॉन्च करते समय EXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS का इस्तेमाल करना होगा.

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

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

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

[3.8.17/H-1-1] उपयोगकर्ता को यह पुष्टि करनी होगी कि डेटा को क्लिपबोर्ड पर कॉपी कर लिया गया है. उदाहरण के लिए, "कॉन्टेंट कॉपी किया गया" का थंबनेल या सूचना. इसके अलावा, यहां यह भी बताएं कि क्या क्लिपबोर्ड का डेटा सभी डिवाइसों पर सिंक होगा.

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

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

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

[3.16/H-1-1] इसमें कंपैनियन डिवाइस को पेयर करने की सुविधा होनी चाहिए.

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

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

[3.20.1/H-0-1] Assistant Audio Stream से जुड़ी सभी ज़रूरी शर्तों को पूरा करना ज़रूरी है.

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

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

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

अगर हैंडहेल्ड डिवाइसों में सुरक्षित लॉक स्क्रीन की सुविधा काम करती है और कर्नल और यूज़रस्पेस के लिए 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 के इंटेंट का पालन करना ज़रूरी है. साथ ही, एसडीके में बताए गए तरीके से, कैमरे को स्टिल इमेज मोड में लॉन्च करना ज़रूरी है.
[7.5.4/H-1-2] एसडीके में बताए गए तरीके के मुताबिक, वीडियो मोड में कैमरा लॉन्च करने के android.media.action.VIDEO_CAMERA इंटेंट का पालन करना ज़रूरी है.

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

[3.2.3.1/ H-1-1] में ऐसी गतिविधि होनी चाहिए जो स्प्लिट फ़ंक्शन चालू होने पर, Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY इंटेंट को हैंडल करती हो. गतिविधि को android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK से सुरक्षित किया जाना चाहिए. साथ ही, इसे Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI से पार्स किए गए Intent की गतिविधि शुरू करनी चाहिए.

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

[7.4.1.2/H-0-1] android.software.telecom फ़ीचर फ़्लैग के बारे में एलान करना ज़रूरी है.

[7.4.1.2/H-0-2] टेलीकॉम फ़्रेमवर्क को लागू करना ज़रूरी है.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[9.1/H-0-2] यह ज़रूरी है कि उस ऐप्लिकेशन के लिए, ACCESS_FINE_LOCATION को डिफ़ॉल्ट के तौर पर अनुमति न दी जाए.

डिवाइस में सेट किए गए सिस्टम के लिए, android.software.credentials के साथ काम करने की सुविधा के बारे में बताना ज़रूरी है. साथ ही:

[9/H-0-2] क्रेडेंशियल मैनेजर के लिए पसंदीदा सेवा देने वाली कंपनी को चुनने की अनुमति देने के लिए, android.settings.CREDENTIAL_PROVIDER इंटेंट का पालन करना ज़रूरी है. यह सेवा देने वाली कंपनी, जानकारी अपने-आप भरने की सुविधा के लिए चालू हो जाएगी. साथ ही, Credential Manager में डाले गए नए क्रेडेंशियल सेव करने के लिए, यह डिफ़ॉल्ट जगह भी होगी.
[9/H-0-3] कम से कम दो क्रेडेंशियल प्रोवाइडर के साथ काम करना चाहिए और सेटिंग ऐप्लिकेशन में उपयोगकर्ताओं को यह सुविधा देनी चाहिए कि वे प्रोवाइडर को चालू या बंद कर सकें.
[9.5/H-1-1] Android 16 में इस ज़रूरी शर्त को हटा दिया गया है.

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

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

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

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

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

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

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

[9.11.1/H-1-1] उपयोगकर्ता को हर 72 घंटे में एक बार से ज़्यादा, पुष्टि करने के सुझाए गए मुख्य तरीकों (जैसे, पिन, पैटर्न या पासवर्ड) में से किसी एक का इस्तेमाल करने के लिए कहना होगा.

अगर हाथ में रखकर इस्तेमाल किए जाने वाले डिवाइसों में सुरक्षित लॉक स्क्रीन की सुविधा लागू की गई है और उनमें एक या उससे ज़्यादा भरोसेमंद एजेंट शामिल हैं, जो TrustAgentService.grantTrust() फ़्लैग के साथ TrustAgentService.grantTrust() सिस्टम एपीआई को कॉल करते हैं, तो:FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE

[9.11.1/H-1-1] इन दोनों में से किसी एक के बाद, TrustManagerService.revokeTrust() को कॉल करना ज़रूरी है:
- भरोसेमंद ऐप्लिकेशन के तौर पर मंज़ूरी मिलने के बाद, ज़्यादा से ज़्यादा 24 घंटे तक.
- आठ घंटे तक कोई गतिविधि नहीं की गई हो.

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

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

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

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

वे सेटिंग जिन पर पाबंदी लगाई गई है

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

किसी ऐसे ऐप्लिकेशन के ज़रिए डाउनलोड किए जाने के बाद इंस्टॉल किया गया हो जो "ऐप्लिकेशन स्टोर" ऐप्लिकेशन के अलावा कोई अन्य ऐप्लिकेशन हो. उदाहरण के लिए, कोई मैसेजिंग ऐप्लिकेशन या ब्राउज़र. "ऐप्लिकेशन स्टोर" ऐप्लिकेशन को PackageManager ने PACKAGE_DOWNLOADED_FILE के तौर पर आइडेंटिफ़ाई किया हो.
लोकल फ़ाइल से इंस्टॉल किया गया हो (उदाहरण के लिए, ऐप्लिकेशन को साइडलोड किया गया हो) PackageManager ने इसकी पहचान PACKAGE_SOURCE_LOCAL_FILE के तौर पर की हो.

नीचे [9.8/H-0-5] में दी गई, लागू की गई अनुमतियों और उनसे जुड़े किसी भी आइडेंटिफ़ायर के लिए.

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

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

[9.8/H-0-1] डेवलपर को ऊपर बताई गई पाबंदियों वाली सेटिंग लागू करनी होंगी. ये सेटिंग इन पर लागू होंगी:
- खास अनुमतियां
  - सुलभता (AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE)
  - सूचना को सुनने की सुविधा (AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS)
  - डिवाइस के एडमिन ऐप्लिकेशन (Manifest.permission.BIND_DEVICE_ADMIN)
  - दूसरे ऐप्लिकेशन के ऊपर दिखाना (AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW)
  - इस्तेमाल का ऐक्सेस (AppOpsManager.OPSTR_GET_USAGE_STATS)
- भूमिकाएं (डिफ़ॉल्ट ऐप्लिकेशन)
  - Dialer (RoleManager.ROLE_DIALER)
  - मैसेज (एसएमएस) (RoleManager.ROLE_SMS)
- रनटाइम अनुमतियां
  - एसएमएस भेजने में लगने वाला समय (Manifest.permission_group.SMS)
[9.8/H-0-2] डिफ़ॉल्ट रूप से, पाबंदी वाली सेटिंग चालू होनी चाहिए. साथ ही, यह सुझाव दिया जाता है कि उपयोगकर्ता को ऐसी कोई सुविधा न दी जाए जिससे वह सभी ऐप्लिकेशन के लिए, पाबंदी वाली सेटिंग बंद कर सके.
[9.8/H-0-3] यह पक्का करना ज़रूरी है कि जिन ऐप्लिकेशन पर नीति लागू होती है उनमें से हर ऐप्लिकेशन के लिए, उपयोगकर्ता की पुष्टि की गई हो. ऐसा तब किया जाना चाहिए, जब नीति के तहत लागू की गई अनुमतियां दी जा सकती हों.
[9.8/H-0-4] EnhancedConfirmationManager API का इस्तेमाल करके, प्रतिबंधित सेटिंग चालू करने के लिए उपयोगकर्ता की पुष्टि सिर्फ़ Covered Application के AppInfo पेज से की जानी चाहिए.
[9.8/H-0-5] सभी खास अनुमतियों के लिए, EnhancedConfirmationManager के साथ इंटिग्रेट करने और इसे कॉल करने का सुझाव दिया जाता है, ताकि यह डाइनैमिक तरीके से तय किया जा सके कि वे प्रतिबंधित सेटिंग हैं या नहीं.
- अलार्म और रिमाइंडर: AppOpsManager.OPSTR_SCHEDULE_EXACT_ALARM
- सभी फ़ाइलों का ऐक्सेस: AppOpsManager.OPSTR_MANAGE_EXTERNAL_STORAGE
- अन्य ऐप्लिकेशन के ऊपर दिखाएं: AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW
- अनजान ऐप्लिकेशन इंस्टॉल करने की अनुमति: AppOpsManager.OPSTR_REQUEST_INSTALL_PACKAGES
- मीडिया मैनेज करें: AppOpsManager.OPSTR_MANAGE_MEDIA
- सिस्टम सेटिंग में बदलाव करने की अनुमति: AppOpsManager.OPSTR_WRITE_SETTINGS
- पिक्चर में पिक्चर: AppOpsManager.OPSTR_PICTURE_IN_PICTURE
- स्क्रीन चालू करें: AppOpsManager.OPSTR_TURN_SCREEN_ON
- फ़ुल-स्क्रीन सूचनाएं: AppOpsManager.OPSTR_USE_FULL_SCREEN_INTENT
- वाई-फ़ाई कंट्रोल: AppOpsManager.OPSTR_CHANGE_WIFI_STATE
- सुलभता: AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE
- सूचना को सुनने की सुविधा: AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS
- इस्तेमाल का ऐक्सेस: AppOpsManager.OPSTR_GET_USAGE_STATS
- डिवाइस एडमिन: Manifest.permission.BIND_DEVICE_ADMIN
- परेशान न करें: Manifest.permission.MANAGE_NOTIFICATIONS

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

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

[9.8/H-1-1] यह पक्का करना ज़रूरी है कि हॉटवर्ड का पता लगाने वाली सेवा, सिर्फ़ सिस्टम, ContentCaptureService या SpeechRecognizer#createOnDeviceSpeechRecognizer() की बनाई गई डिवाइस पर मौजूद स्पीच रिकग्निशन सेवा को डेटा ट्रांसमिट कर सकती हो.
[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-14] जब हॉटवर्ड का पता चलने पर, वॉइस इंटरैक्शन सेवा या मिलती-जुलती इकाई को डेटा भेजा जाता है, तब माइक्रोफ़ोन इंडिकेटर दिखना चाहिए. इसके बारे में सेक्शन 9.8.2 में बताया गया है.
[9.8/H-1-15] यह पक्का करना ज़रूरी है कि हॉटवर्ड का पता लगाने वाली सेवा से, आवाज़ से इंटरैक्ट करने वाली सेवा को ऑडियो स्ट्रीम सिर्फ़ एक बार भेजी जाए. ऐसा तब किया जाना चाहिए, जब हॉटवर्ड का पता लगाने वाली सेवा को हॉटवर्ड मिल जाए.
[9.8/H-SR-1] हॉटवर्ड का पता लगाने की सेवा देने वाले ऐप्लिकेशन के तौर पर किसी ऐप्लिकेशन को सेट करने से पहले, उपयोगकर्ताओं को सूचना देना ज़रूरी है.
[9.8/H-SR-2] हॉटवर्ड का पता लगाने वाली सेवा से बिना स्ट्रक्चर वाले डेटा को ट्रांसमिट करने की अनुमति न देने का सुझाव दिया जाता है.
[9.8/H-SR-3] हमारा सुझाव है कि हॉटवर्ड का पता लगाने वाली सेवा को होस्ट करने वाली प्रोसेस को हर घंटे में कम से कम एक बार या हर 30 हार्डवेयर-ट्रिगर इवेंट में से जो भी पहले हो, उसे रीस्टार्ट करें.

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

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

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

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

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

[9.8.2/H-4-1] जब कोई ऐप्लिकेशन माइक्रोफ़ोन से ऑडियो डेटा ऐक्सेस कर रहा हो, तब माइक्रोफ़ोन इंडिकेटर दिखाना ज़रूरी है. हालांकि, ऐसा तब नहीं होना चाहिए, जब माइक्रोफ़ोन को सिर्फ़ HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService या सेक्शन 9.1 में बताई गई भूमिकाओं वाले ऐप्लिकेशन ऐक्सेस कर रहे हों. इन ऐप्लिकेशन का सीडीडी आइडेंटिफ़ायर [C-4-X] है.
[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] कैमरे के इंडिकेटर को उन सिस्टम ऐप्लिकेशन के लिए नहीं छिपाना चाहिए जिनके यूज़र इंटरफ़ेस दिखते हैं या जो सीधे तौर पर उपयोगकर्ता से इंटरैक्ट करते हैं.

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

[9.8.8/H-6-1] ऐसा इंडिकेटर दिखाना ज़रूरी है जो उपयोगकर्ता को दिखे.

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

[9.10/H-1-1] Android बूट सीक्वेंस के दौरान माउंट किए गए सभी रीड-ओनली पार्टिशन की पुष्टि करना ज़रूरी है. साथ ही, VBMeta डाइजेस्ट में, पुष्टि किए गए इन सभी पार्टिशन को शामिल करना ज़रूरी है.

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

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

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

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

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

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

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

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

2.2.7.1. मीडिया

अगर हैंडहेल्ड डिवाइसों पर लागू किए गए android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS के लिए, शून्य के अलावा कोई अन्य वैल्यू मिलती है, तो:

यह ज़रूरी है कि डिवाइस, Android 17 CDD के सेक्शन 2.2.7.1 में बताई गई मीडिया से जुड़ी सभी ज़रूरी शर्तों को पूरा करता हो. ये शर्तें, डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से तय की जाती हैं.
[5.1/H-1-1] डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, CodecCapabilities.getMaxSupportedInstances() और VideoCapabilities.getSupportedPerformancePoints() तरीकों का इस्तेमाल करके, किसी भी कोडेक कॉम्बिनेशन में एक साथ चलाए जा सकने वाले हार्डवेयर वीडियो डिकोडर सेशन की ज़्यादा से ज़्यादा संख्या का विज्ञापन दिखाना ज़रूरी है.
[5.1/H-1-2] यह ज़रूरी है कि डिवाइस में हार्डवेयर वीडियो डिकोडर सेशन (AVC, HEVC, VP9, AV1 या बाद के वर्शन), एक साथ कई इंस्टेंस, और फ़्रेम ड्रॉप की सुविधा काम करे. यह सुविधा, डिवाइस के लिए तय किए गए मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से काम करनी चाहिए.
[5.1/H-1-3] डिवाइस को, CodecCapabilities.getMaxSupportedInstances() और VideoCapabilities.getSupportedPerformancePoints() तरीकों का इस्तेमाल करके, किसी भी कोडेक कॉम्बिनेशन में एक साथ चलाए जा सकने वाले हार्डवेयर वीडियो एनकोडर सेशन की ज़्यादा से ज़्यादा संख्या का विज्ञापन दिखाना होगा. यह संख्या, डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से तय की जाती है.
[5.1/H-1-4] डिवाइस में हार्डवेयर वीडियो एन्कोडर सेशन (AVC, HEVC, VP9, AV1 या बाद के वर्शन), एक साथ कई इंस्टेंस, और फ़्रेम ड्रॉप की सुविधा होनी चाहिए. यह सुविधा, डिवाइस के लिए तय किए गए मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से होनी चाहिए.
[5.1/H-1-5] डिवाइस को, किसी भी कोडेक कॉम्बिनेशन में एक साथ चलने वाले ज़्यादा से ज़्यादा हार्डवेयर वीडियो एनकोडर और डिकोडर सेशन के बारे में विज्ञापन देना होगा. इसके लिए, डिवाइस के लिए तय की गई मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से CodecCapabilities.getMaxSupportedInstances() और VideoCapabilities.getSupportedPerformancePoints() तरीकों का इस्तेमाल करना होगा.
[5.1/H-1-6] डिवाइस में हार्डवेयर वीडियो डिकोडर और हार्डवेयर वीडियो एन्कोडर सेशन (AVC, HEVC, VP9, AV1 या बाद के वर्शन) के साथ-साथ, एक साथ कई इंस्टेंस और फ़्रेम ड्रॉप की सुविधा होनी चाहिए. यह सुविधा, डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से होनी चाहिए.
[5.1/H-1-7] डिवाइस पर लोड होने पर, सभी हार्डवेयर वीडियो एन्कोडर के लिए, 1080 पिक्सल या इससे कम रिज़ॉल्यूशन वाले वीडियो एन्कोडिंग सेशन के लिए, कोडेक शुरू होने में लगने वाला समय, डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से होना चाहिए.
[5.1/H-1-8] सभी ऑडियो एन्कोडर के लिए, 128 केबीपीएस या उससे कम बिटरेट वाले ऑडियो एन्कोडिंग सेशन के लिए, कोडेक शुरू होने में लगने वाला समय कम होना चाहिए. ऐसा तब होना चाहिए, जब डिवाइस पर मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से लोड हो.
[5.1/H-1-9] यह ज़रूरी है कि डिवाइस में सुरक्षित हार्डवेयर वीडियो डिकोडर के दो सेशन (AVC, HEVC, VP9, AV1 या बाद के वर्शन) काम करें. साथ ही, डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से फ़्रेम ड्रॉप हों.
[5.1/H-1-10] यह ज़रूरी है कि डिवाइस में, असुरक्षित हार्डवेयर वीडियो डिकोडर के तीन सेशन और सुरक्षित हार्डवेयर वीडियो डिकोडर का एक सेशन (कुल चार सेशन) एक साथ काम करें. साथ ही, डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, AVC, HEVC, VP9, AV1 या बाद के वर्शन के रिज़ॉल्यूशन और फ़्रेम ड्रॉप की सुविधा काम करे.
[5.1/H-1-11] यह ज़रूरी है कि डिवाइस में मौजूद हर हार्डवेयर AVC, HEVC, VP9 या AV1 डिकोडर के लिए, उससे जुड़े सुरक्षित डिकोडर का इस्तेमाल किया जाए. यह डिकोडर, डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के मुताबिक होना चाहिए.
[5.1/H-1-12] डिवाइस पर लोड होने पर, सभी हार्डवेयर वीडियो डिकोडर के लिए, 1080 पिक्सल या इससे कम रिज़ॉल्यूशन वाले वीडियो डिकोडिंग सेशन के लिए, कोडेक शुरू होने में लगने वाला समय, डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से होना चाहिए.
[5.1/H-1-13] डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, सभी ऑडियो डिकोडर पर लोड होने पर, 128 केबीपीएस या इससे कम बिटरेट वाले ऑडियो डिकोडिंग सेशन के लिए, कोडेक शुरू होने में लगने वाला समय होना चाहिए.
[5.1/H-1-14] यह ज़रूरी है कि डिवाइस में, AV1 हार्डवेयर डिकोडर प्रोफ़ाइल, सुविधा, और डिसप्ले मेथड काम करता हो. यह डिवाइस के लिए तय किए गए मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से होना चाहिए.
[5.1/H-1-15] डिवाइस में कम से कम एक ऐसा हार्डवेयर वीडियो डिकोडर होना चाहिए जो 4K60 को सपोर्ट करता हो. यह डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से होना चाहिए.
[5.1/H-1-16] डिवाइस में कम से कम एक ऐसा हार्डवेयर वीडियो एनकोडर होना चाहिए जो 4K60 फ़्रेम रेट पर काम करता हो. यह डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के मुताबिक होना चाहिए.
[5.1/H-1-17] डिवाइस में, AVIF Baseline Profile के साथ काम करने वाला कम से कम एक हार्डवेयर इमेज डिकोडर होना चाहिए. यह डिकोडर, डिवाइस के लिए तय किए गए मीडिया परफ़ॉर्मेंस क्लास लेवल के मुताबिक होना चाहिए.
[5.1/H-1-18] इसमें AV1 एन्कोडर होना चाहिए. यह एन्कोडर, डिवाइस के लिए तय की गई मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से बिटरेट, फ़्रेम प्रति सेकंड, और रिज़ॉल्यूशन की ज़रूरी शर्तों को पूरा करता हो.
[5.1/H-1-19] डिवाइस में 10-बिट (एचडीआर) हार्डवेयर वीडियो डिकोडर और हार्डवेयर वीडियो एन्कोडर सेशन (AVC, HEVC, VP9, AV1 या बाद के वर्शन) के तीन इंस्टेंस होने चाहिए. साथ ही, डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से रिज़ॉल्यूशन और फ़्रेम ड्रॉप होने चाहिए.
[5.1/H-1-20] यह ज़रूरी है कि डिवाइस पर मौजूद सभी हार्डवेयर AV1 और HEVC एन्कोडर के लिए, Feature_HdrEditing सुविधा काम करती हो. यह सुविधा, डिवाइस के लिए तय किए गए मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से काम करनी चाहिए.
[5.1/H-1-21] यह ज़रूरी है कि डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, सभी हार्डवेयर वीडियो डिकोडर (AVC, HEVC, VP9, AV1 या बाद के वर्शन) के लिए FEATURE_DynamicColorAspect काम करे.
[5.1/H-1-22] डिवाइस में, पोर्ट्रेट ऐस्पेक्ट रेशियो में वीडियो कॉन्टेंट को एन्कोड, डिकोड, जीपीयू से एडिट, और डिसप्ले करने की सुविधा होनी चाहिए. यह सुविधा, डिवाइस के लिए तय किए गए मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से होनी चाहिए.
[5.2/H-2-1] अगर डिवाइस में हार्डवेयर AVC या HEVC एन्कोडर काम करते हैं, तो उसे उन कोडेक के लिए वीडियो एन्कोडर की रेट-डिस्टॉर्शन कर्व से तय किए गए क्वालिटी के कम से कम टारगेट को पूरा करना होगा. यह टारगेट, डिवाइस के लिए तय किए गए मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से होना चाहिए.

[5.2/H-2-2] डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, स्पीकर पाथ पर MMAP काम करना चाहिए.

[5.3/H-1-1] डिवाइस को, वीडियो सेशन की परफ़ॉर्मेंस और फ़्रेम ड्रॉप से जुड़ी ज़रूरी शर्तों को पूरा करना होगा. ये शर्तें, डिवाइस के लिए तय की गई मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से होनी चाहिए.
[5.3/H-1-2] वीडियो रिज़ॉल्यूशन बदलने की परफ़ॉर्मेंस से जुड़ी ज़रूरी शर्तों को पूरा करना होगा. ये शर्तें, डिवाइस के लिए तय किए गए मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से होनी चाहिए.
[5.6/H-1-1] डिवाइस के लिए तय किए गए मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, टैप-टू-टोन की लेटेन्सी से जुड़ी ज़रूरी शर्तों को पूरा करना ज़रूरी है.
[5.6/H-1-2] डिवाइस के लिए तय की गई मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, राउंड-ट्रिप ऑडियो लेटेंसी की ज़रूरी शर्तें पूरी करना ज़रूरी है.
[5.6/H-1-3] डिवाइस के लिए तय किए गए मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, 24-बिट ऑडियो की ज़रूरी शर्तों को पूरा करना ज़रूरी है.
[5.6/H-1-4] डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, डिवाइस में चार या इससे ज़्यादा चैनल वाले यूएसबी ऑडियो डिवाइस काम करने चाहिए.
[5.6/H-1-5] क्लास के मुताबिक काम करने वाले MIDI डिवाइसों के साथ काम करना ज़रूरी है. साथ ही, डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, MIDI फ़ीचर फ़्लैग का एलान करना ज़रूरी है.
[5.6/H-1-9] डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, कम से कम 12 चैनल मिक्सिंग की सुविधा होनी चाहिए.

[5.6/H-3-1] डिवाइस में, मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से ऑडियो बफ़र में कोई रुकावट न आए, इसके लिए साइन वेव चलाने के बीच स्विच करने की सुविधा होनी चाहिए.
[5.6/H-3-2] यूएसबी ऑडियो डिवाइस के आउटपुट चैनल की ज़रूरी शर्तों को पूरा करना ज़रूरी है. ये शर्तें, डिवाइस के लिए तय किए गए मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से होनी चाहिए.
[5.6/H-3-3] यूएसबी ऑडियो डिवाइस के इनपुट चैनल की ज़रूरी शर्तों को पूरा करना ज़रूरी है. ये शर्तें, डिवाइस के लिए तय किए गए मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से होनी चाहिए.

[5.6/H-SR-1] यह सुझाव दिया जाता है कि डिवाइस, ऑडियो चैनल मिक्सिंग की सुविधा के साथ काम करे. यह सुविधा, डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से काम करती है.
[5.7/H-1-2] MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL के साथ काम करना ज़रूरी है. साथ ही, डिवाइस के लिए डिक्रिप्ट करने की क्षमताएं, मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से होनी चाहिए.
[5.12/H-1-2] डिवाइस के लिए तय किए गए मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, हार्डवेयर AV1 और HEVC एन्कोडर के लिए, कलर फ़ॉर्मैट से जुड़ी ज़रूरी शर्तों को पूरा करना चाहिए.
[5.12/H-1-3] डिवाइस के लिए, EXT_YUV_target एक्सटेंशन के साथ काम करने की जानकारी देना ज़रूरी है. यह जानकारी, डिवाइस के लिए तय किए गए मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से होनी चाहिए.
[7.1.4/H-1-1] डिवाइस को, डिसप्ले प्रोसेसिंग यूनिट (डीपीयू) से जुड़ी ज़रूरी शर्तों को पूरा करना होगा. ये शर्तें, डिवाइस के लिए तय की गई मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से तय की जाती हैं.

2.2.7.2. कैमरा

डिवाइस के लिए तय किए गए मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, Android 17 CDD के सेक्शन 2.2.7.2 में बताई गई कैमरे की ज़रूरी शर्तों को पूरा करना ज़रूरी है.

[7.5/H-1-1] डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, पीछे की ओर लगे मुख्य कैमरे के रिज़ॉल्यूशन और वीडियो कैप्चर करने की ज़रूरी शर्तों को पूरा करना ज़रूरी है.
[7.5/H-1-2] डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, सामने की ओर लगे मुख्य कैमरे के रिज़ॉल्यूशन और वीडियो कैप्चर करने की ज़रूरी शर्तों को पूरा करना ज़रूरी है.
[7.5/H-1-3] डिवाइस के लिए, android.info.supportedHardwareLevel प्रॉपर्टी की ज़रूरी शर्तों को पूरा करना ज़रूरी है. ये शर्तें, डिवाइस के लिए तय किए गए मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से होनी चाहिए.
[7.5/H-1-4] डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, दोनों प्राइमरी कैमरों के लिए CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME की सुविधा उपलब्ध होनी चाहिए.
[7.5/H-1-5] डिवाइस को, Camera2 API के ज़रिए JPEG फ़ोटो कैप्चर करने में लगने वाले समय से जुड़ी ज़रूरी शर्तों को पूरा करना होगा. ये शर्तें, डिवाइस के लिए तय किए गए मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से तय की जाती हैं.
[7.5/H-1-6] डिवाइस के लिए, कैमरा2 के चालू होने में लगने वाले समय से जुड़ी ज़रूरी शर्तों को पूरा करना ज़रूरी है. ये शर्तें, डिवाइस के लिए तय की गई मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से तय की जाती हैं.
[7.5/H-1-8] डिवाइस के लिए, मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, RAW फ़ॉर्मैट में फ़ोटो कैप्चर करने की ज़रूरी शर्तों को पूरा करना ज़रूरी है.
[7.5/H-1-9] डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, पीछे की ओर लगे प्राइमरी कैमरे के लिए, हाई स्पीड वीडियो कैप्चर करने की ज़रूरी शर्तों को पूरा करना ज़रूरी है.
[7.5/H-1-10] डिवाइस के लिए तय किए गए मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, ज़ूम रेशियो से जुड़ी ज़रूरी शर्तों को पूरा करना ज़रूरी है.
[7.5/H-1-11] डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, मुख्य कैमरों पर एक साथ आगे और पीछे के कैमरे से स्ट्रीमिंग करने की सुविधा लागू करना ज़रूरी है.
[7.5/H-1-12] डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, मुख्य बैक कैमरे के लिए वीडियो स्टेबलाइज़ेशन की सुविधा उपलब्ध होनी चाहिए.
[7.5/H-1-13] डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, पीछे की ओर लगे मुख्य कैमरे के लिए LOGICAL_MULTI_CAMERA की सुविधा काम करनी चाहिए.
[7.5/H-1-14] डिवाइस के लिए, मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, मुख्य फ्रंट और मुख्य बैक कैमरे, दोनों के लिए STREAM_USE_CASE सुविधा काम करनी चाहिए.
[7.5/H-1-15] डिवाइस के प्राइमरी कैमरे में, CameraX और Camera2, दोनों एक्सटेंशन के ज़रिए नाइट मोड एक्सटेंशन की सुविधा काम करनी चाहिए. यह सुविधा, डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से काम करनी चाहिए.
[7.5/H-1-16] डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, प्राइमरी कैमरों के लिए DYNAMIC_RANGE_TEN_BIT सुविधा काम करनी चाहिए.
[7.5/H-1-17] यह ज़रूरी है कि डिवाइस के प्राइमरी कैमरे, चेहरे का पता लगाने की सुविधा के साथ काम करते हों. ये कैमरे, डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से होने चाहिए.
[7.5/H-1-18] डिवाइस के लिए, मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, मुख्य रियर और मुख्य फ़्रंट कैमरे के लिए JPEG_R की सुविधा उपलब्ध होनी चाहिए.
[7.5/H-1-19] डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, मुख्य रियर कैमरे के लिए CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION की सुविधा उपलब्ध होनी चाहिए.
[7.5/H-1-20] डिवाइस के नेटिव कैमरा ऐप्लिकेशन में, डिफ़ॉल्ट रूप से JPEG_R आउटपुट होना चाहिए. यह आउटपुट, डिवाइस के मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, प्राइमरी रियर और प्राइमरी फ़्रंट कैमरे के लिए होना चाहिए.

[7.5/H-1-21] डिवाइस में कम से कम एक फ़्रंट फ़ेसिंग कैमरा या रियर फ़ेसिंग कैमरा होना ज़रूरी है. यह कैमरा, डिवाइस के लिए तय किए गए मीडिया परफ़ॉर्मेंस क्लास लेवल के मुताबिक होना चाहिए.

2.2.7.3. हार्डवेयर

डिवाइस के लिए, मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, Android 17 CDD के सेक्शन 2.2.7.3 में बताई गई हार्डवेयर से जुड़ी ज़रूरी शर्तों को पूरा करना ज़रूरी है.

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

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

डिवाइस के लिए तय की गई मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, Android 17 CDD के सेक्शन 2.2.7.4 में बताई गई परफ़ॉर्मेंस की ज़रूरी शर्तों को पूरा करना ज़रूरी है.

[8.2/H-1-1] ज़रूरी है कि डिवाइस में क्रम से लिखने की परफ़ॉर्मेंस, डिवाइस के लिए तय की गई मीडिया परफ़ॉर्मेंस क्लास लेवल के मुताबिक हो.
[8.2/H-1-2] ज़रूरी है कि डिवाइस की रैंडम राइट परफ़ॉर्मेंस, डिवाइस के लिए तय किए गए मीडिया परफ़ॉर्मेंस क्लास लेवल के मुताबिक हो.
[8.2/H-1-3] डिवाइस के लिए तय की गई मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, डिवाइस में डेटा को क्रम से पढ़ने की परफ़ॉर्मेंस अच्छी होनी चाहिए.
[8.2/H-1-4] डिवाइस के लिए तय की गई मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, रैंडम रीड परफ़ॉर्मेंस को पक्का करना ज़रूरी है.
[8.2/H-1-5] डिवाइस के लिए तय किए गए मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, पैरलल सीक्वेंशियल रीड और राइट परफ़ॉर्मेंस को पक्का करना ज़रूरी है.

2.2.7.5. ग्राफ़िक

[7.1.4.1/H-1-2] डिवाइस के लिए तय किए गए मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से, ज़रूरी EGL एक्सटेंशन के साथ काम करना ज़रूरी है.
[7.1.4.1/H-1-3] डिवाइस में, Vulkan की ज़रूरी सुविधाएं होनी चाहिए. ये सुविधाएं, डिवाइस के लिए तय की गई मीडिया परफ़ॉर्मेंस क्लास लेवल के हिसाब से होनी चाहिए.

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

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

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

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

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

2.3.1. हार्डवेयर

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[5.1/T-0-4] MPEG-D DRC के साथ MPEG-D USAC (Extended High Efficiency AAC)

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

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

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

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

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

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

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

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

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

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

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

[5.3.5/T-1-1] 60 फ़्रेम प्रति सेकंड पर एचडी 1080 पिक्सल रिज़ॉल्यूशन के साथ Main Profile Level 4.1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[3/T-1-1] MUST support all Tuner Framework APIs such that an application which uses these APIs can be installed and used on the device.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[9.1/T-0-1] यह ज़रूरी है कि उस ऐप्लिकेशन के लिए, ACCESS_FINE_LOCATION को डिफ़ॉल्ट के तौर पर अनुमति न दी जाए.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 मीटर प्रति सेकंड स्क्वेयर से कम ऐक्सलरेशन के साथ चल रहा हो, तब 20 मीटर के दायरे तक जगह की जानकारी और 0.2 मीटर प्रति सेकंड की स्पीड का पता लगाने के लिए, कम से कम 95% समय में यह जानकारी काफ़ी हो.

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

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

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

[7.4.1/W-1-1] android.hardware.telephony.data सुविधा के बारे में एलान करना ज़रूरी है.

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

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

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

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

2.4.3. सॉफ़्टवेयर

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

[3/W-0-1] android.hardware.type.watch सुविधा का एलान करना ज़रूरी है.
[3/W-0-2] MUST support uiMode = UI_MODE_TYPE_WATCH.
[3.2.3.1/W-0-1] MUST preload one or more applications or service components with an intent handler, for all the public intent filter patterns defined by the following application intents listed here.

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

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

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

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

अगर वॉच डिवाइस में android.hardware.audio.output सुविधा के बारे में बताया गया है, तो:

[3.11/W-SR-1] यह सुझाव दिया जाता है कि डिवाइस पर उपलब्ध भाषाओं के साथ काम करने वाला टीटीएस इंजन शामिल किया जाए.
[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 Open Source Project, 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 सुविधा के बारे में एलान करना ज़रूरी है.

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

[9.1/W-0-1] यह ज़रूरी है कि उस ऐप्लिकेशन के लिए, ACCESS_FINE_LOCATION को डिफ़ॉल्ट के तौर पर अनुमति न दी जाए.

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

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

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

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

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

[9.11.1/W-1-1] उपयोगकर्ता को पुष्टि करने के लिए, सुझाए गए मुख्य तरीकों (जैसे कि पिन, पैटर्न या पासवर्ड) में से किसी एक का इस्तेमाल करने के लिए हर 72 घंटे में एक बार से ज़्यादा कम से कम हर 336 घंटे (14 दिन) में एक बार कहना चाहिए.

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

[9.11.1/W-2-1] उस फ़्लैग के साथ grantTrust() को कॉल करने के लिए, इन शर्तों को पूरा करना ज़रूरी है:
- डिवाइस, किसी ऐसे फ़िज़िकल प्राइमरी हैंडहेल्ड डिवाइस से कनेक्ट हो जिसमें लॉकस्क्रीन की सुविधा हो. साथ ही,
- उपयोगकर्ता ने पिछले 30 सेकंड में, लॉकस्क्रीन या क्लास 3 के बायोमेट्रिक के ज़रिए अपनी पहचान की पुष्टि की हो.
[9.11.1/W-2-2] जब पहनने लायक डिवाइस को हाथ या शरीर से हटा दिया जाता है और TrustAgent ने भरोसेमंद डिवाइस के तौर पर उसकी स्थिति को नहीं बदला है, तो डिवाइस की स्थिति को TrustState.TRUSTABLE पर सेट करना ज़रूरी है.

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

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

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

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

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

2.5.1. हार्डवेयर

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

[7.1.1.1/A-0-1] स्क्रीन का फ़िज़िकल डाइगोनल साइज़ कम से कम 6 इंच होना चाहिए.
[7.1.1.1/A-0-2] स्क्रीन का साइज़ कम से कम 750 dp x 480 dp होना चाहिए.
[7.1.1.1/A-0-3] यह ज़रूरी है कि जीपीयू, ग्राफ़िक बफ़र को कंपोज़ कर सके. ग्राफ़िक बफ़र का साइज़, डिवाइस में मौजूद किसी भी डिसप्ले के सबसे ज़्यादा रिज़ॉल्यूशन के बराबर होना चाहिए.

अगर Automotive डिवाइस में सेट किए गए सिस्टम में, एक साथ कई उपयोगकर्ताओं के साथ काम करने की सुविधा उपलब्ध है (इस सुविधा के तहत, एक साथ कई Android उपयोगकर्ता डिवाइस के साथ इंटरैक्ट कर सकते हैं. इसके लिए, config_multiuserVisibleBackgroundUsers सुविधा चालू होने पर, हर उपयोगकर्ता अपने डिसप्ले का इस्तेमाल करता है), तो:

[7.1.1.1/A-1-1] मुख्य डिसप्ले के लिए, हर ऑक्यूपेंट ज़ोन में कम से कम 6 इंच के फ़िज़िकल डायगोनल साइज़ वाली अलग स्क्रीन होनी चाहिए. इसे हर ऑक्यूपेंट ज़ोन के लिए, CarOccupantZoneManager.DISPLAY_TYPE_MAIN के तौर पर टैग किया जाना चाहिए.
[7.1.1.1/A-1-2] हर मुख्य डिसप्ले के लिए, स्क्रीन का साइज़ कम से कम 750 dp x 480 dp होना चाहिए.

अगर 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 डिवाइस में सेट किए गए सिस्टम में Vulkan का इस्तेमाल किया जाता है, तो:

[7.1.4.2/A-1-1] Android Baseline 2021 प्रोफ़ाइल में बताई गई ज़रूरी शर्तों को पूरा करना ज़रूरी है.

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

[7.1.4.5/A-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 एक्सटेंशन के लिए सहायता का विज्ञापन देना ज़रूरी है.

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

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

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

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

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

[7.1.5/A-0-1] इसमें लेगसी ऐप्लिकेशन के साथ काम करने वाले मोड के लिए सहायता शामिल होनी चाहिए. यह मोड, अपस्ट्रीम Android ओपन सोर्स कोड के ज़रिए लागू किया जाता है. इसका मतलब है कि डिवाइसों में, कंपैटिबिलिटी मोड को चालू करने वाले ट्रिगर या थ्रेशोल्ड में बदलाव नहीं किया जाना चाहिए. साथ ही, कंपैटिबिलिटी मोड के व्यवहार में भी बदलाव नहीं किया जाना चाहिए.

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

[7.1.7/A-0-1] ड्राइवर की नज़र के सामने मौजूद सेकंडरी डिसप्ले को FLAG_PRIVATE के तौर पर कॉन्फ़िगर करना ज़रूरी है.
[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-SR1] जीपीएस/जीएनएसएस को अतिरिक्त सेंसर के साथ मिलाकर, जगह की जानकारी का अनुमान लगाया जा सकता है. अगर जगह की जानकारी की डेड रैकिंग हो जाती है, तो हम आपको इस्तेमाल किए गए सेंसर टाइप और/या वाहन की प्रॉपर्टी के आईडी को लागू करने और उनकी रिपोर्ट करने का सुझाव देते हैं.
[7.3/A-0-4] LocationManager#requestLocationUpdates() के ज़रिए अनुरोध की गई Location को मैप से मैच नहीं किया जाना चाहिए.
[7.3.1/A-0-4] Android के कार सेंसर कोऑर्डिनेट सिस्टम का पालन करना ज़रूरी है.
[7.3/A-SR-1] 3-ऐक्सिस एक्सलरोमीटर और 3-ऐक्सिस जाइरोस्कोप को शामिल करने का सुझाव दिया जाता है.
[7.3/A-SR-2] TYPE_HEADING सेंसर को लागू करने और उसके बारे में जानकारी देने का सुझाव दिया जाता है.

[7.3/A-1-1] सभी डिसप्ले पर, डैशबोर्ड के डे/नाइट मोड के हिसाब से NIGHT_MODE फ़्लैग की वैल्यू सेट करनी होगी. इसमें पीछे की सीट पर लगे डिसप्ले भी शामिल हैं.

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

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

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

[7.3.1/A-SR-1] सीमित ऐक्सिस वाले एक्सलरोमीटर के लिए, कंपोज़िट सेंसर को लागू करने का सुझाव दिया जाता है.

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

[7.3.1/A-1-3] TYPE_ACCELEROMETER_LIMITED_AXES सेंसर को लागू करना और उसके बारे में जानकारी देना ज़रूरी है.
[7.3.1/A-1-4] TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED सेंसर को लागू करना और उसके बारे में जानकारी देना ज़रूरी है.

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

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

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

[7.3.4/A-SR-2] सीमित ऐक्सिस वाले जाइरोस्कोप के लिए, कंपोज़िट सेंसर को लागू करने का सुझाव दिया जाता है.

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

[7.3.4/A-4-1] TYPE_GYROSCOPE_LIMITED_AXES सेंसर को लागू करना और उसके बारे में जानकारी देना ज़रूरी है.
[7.3.4/A-4-2] TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED सेंसर को लागू करना और उसके बारे में जानकारी देना ज़रूरी है.

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

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

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

[7.3.4/A-4-3] इवेंट को कम से कम 1 हर्ट्ज़ की फ़्रीक्वेंसी तक रिपोर्ट किया जा सकता है.
[7.3.4/A-SR-3] इवेंट को कम से कम 10 हर्ट्ज़ की फ़्रीक्वेंसी तक रिपोर्ट करने का सुझाव दिया जाता है.
यह ट्रू नॉर्थ के हिसाब से होना चाहिए.
गाड़ी के रुके होने पर भी यह सुविधा उपलब्ध होनी चाहिए.
इसका रिज़ॉल्यूशन कम से कम 1 डिग्री होना चाहिए.

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

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

[7.4.3/A-1-1] यह ज़रूरी है कि यह सुविधा स्वतंत्र रूप से काम करे और अन्य उपयोगकर्ताओं के बीटी अनुभव में कोई रुकावट न डाले.

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

[7.4.5/A] में मोबाइल नेटवर्क पर डेटा कनेक्टिविटी की सुविधा होनी चाहिए.
[7.4.5/A] सिस्टम ऐप्लिकेशन के लिए उपलब्ध होने वाले नेटवर्क के लिए, System API NetworkCapabilities#NET_CAPABILITY_OEM_PAID कॉन्स्टेंट का इस्तेमाल किया जा सकता है.

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

[7.4/A-1-1] FEATURE_BROADCAST_RADIO के साथ काम करने की सुविधा के बारे में बताना ज़रूरी है.

पीछे की ओर लगे कैमरे का मतलब है कि यह दुनिया की ओर फ़ेस करने वाला कैमरा है. इसे वाहन में किसी भी जगह पर लगाया जा सकता है. यह वाहन के केबिन के बाहर की ओर फ़ेस करता है. इसका मतलब है कि यह वाहन के पीछे के हिस्से के सीन की इमेज लेता है. जैसे, पीछे का कैमरा.

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

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

[7.5/A-SR-1] डिवाइस में एक या उससे ज़्यादा वर्ल्ड-फ़ेसिंग कैमरे शामिल करने का सुझाव दिया जाता है.
इसमें एक या उससे ज़्यादा ऐसे कैमरे शामिल हो सकते हैं जो उपयोगकर्ता की ओर हों.
[7.5/A-SR-2] एक साथ कई कैमरों से स्ट्रीमिंग करने की सुविधा देने का सुझाव दिया जाता है.

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

[7.5/A-1-1] कैमरे को इस तरह से लगाया जाना चाहिए कि कैमरे का लंबा हिस्सा, Android Automotive के सेंसर ऐक्सिस के X-Y प्लेन के साथ अलाइन हो.
[7.5/A-SR-3] में फ़िक्स्ड-फ़ोकस या ईडीओएफ़ (एक्सटेंडेड डेप्थ ऑफ़ फ़ील्ड) हार्डवेयर का इस्तेमाल करने का सुझाव दिया जाता है.
[7.5/A-1-2] डिवाइस में, दुनिया की ओर फ़ेस करने वाला प्राइमरी कैमरा, दुनिया की ओर फ़ेस करने वाला ऐसा कैमरा होना चाहिए जिसका कैमरा आईडी सबसे कम हो.

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

[7.5/A-2-1] उपयोगकर्ता की ओर वाला मुख्य कैमरा, उपयोगकर्ता की ओर वाला ऐसा कैमरा होना चाहिए जिसका कैमरा आईडी सबसे कम हो.
इसे इस तरह से ओरिएंट किया जा सकता है कि कैमरे का लंबा डाइमेंशन, Android Automotive के सेंसर ऐक्सिस के X-Y प्लेन के साथ अलाइन हो.

अगर Automotive डिवाइस में सेट किए हुए सिस्टम में ऐसा कैमरा शामिल है जिसे android.hardware.Camera या android.hardware.camera2 API के ज़रिए ऐक्सेस किया जा सकता है, तो:

[7.5/A-3-1] सेक्शन 7.5 में बताई गई, कैमरे से जुड़ी मुख्य ज़रूरी शर्तों का पालन करना ज़रूरी है.

अगर Automotive डिवाइस में सेट किए हुए सिस्टम में ऐसा कैमरा शामिल है जिसे android.hardware.Camera या android.hardware.camera2 एपीआई के ज़रिए ऐक्सेस नहीं किया जा सकता, तो:

[7.5/A-4-1] इसे एक्सटेंडेड व्यू सिस्टम सर्विस के ज़रिए ऐक्सेस किया जा सकता हो.

अगर ऑटोमोटिव डिवाइसों में एक या उससे ज़्यादा ऐसे कैमरे शामिल हैं जिन्हें Extended View System Service के ज़रिए ऐक्सेस किया जा सकता है, तो ऐसे कैमरे के लिए:

[7.5/A-5-1] कैमरे की झलक को घुमाया या हॉरिज़ॉन्टल तौर पर मिरर नहीं किया जाना चाहिए.
[7.5/A-SR-4] इनका रिज़ॉल्यूशन कम से कम 1.3 मेगापिक्सल होना चाहिए.

अगर Automotive डिवाइस में एक या उससे ज़्यादा ऐसे कैमरे शामिल हैं जिन्हें Extended View System Service और android.hardware.Camera या android.hardware.Camera2 एपीआई, दोनों के ज़रिए ऐक्सेस किया जा सकता है, तो ऐसे कैमरे के लिए:

[7.5/A-6-1] एक ही कैमरा आईडी की जानकारी देनी होगी.

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

[7.5/A-7-1] इस तरह के कैमरा एपीआई को android.hardware.camera2 एपीआई या Extended View System API का इस्तेमाल करके लागू करना ज़रूरी है.

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

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

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

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

[7.6.1/A-1-1] AAOS के एक इंस्टेंस पर, ऐप्लिकेशन के निजी डेटा (/data पार्टीशन) के लिए उपलब्ध नॉन-वोलैटाइल स्टोरेज में, एक साथ Android का इस्तेमाल करने वाले हर व्यक्ति के लिए कम से कम 4 जीबी स्टोरेज होना चाहिए.

अगर 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.7.1/A-1-1] Android Open Accessory (AOA) API को लागू करना ज़रूरी है.

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

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

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

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

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

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

[7.8.2/A-1-1] एक साथ कई उपयोगकर्ताओं के सिस्टम के लिए, हर मुख्य डिसप्ले के लिए एक ऑडियो आउटपुट डिवाइस होना ज़रूरी है.
[7.8.2/A-1-2] इसमें ड्राइवर ऑडियो ज़ोन होना चाहिए, जो ग्लोबल केबिन स्पीकर को कवर करता हो. आगे की सीट पर बैठा व्यक्ति, ड्राइवर के ऑडियो ज़ोन को शेयर कर सकता है या उसके पास अपना ऑडियो आउटपुट हो सकता है.

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

[7.8.2.2/A-1-1] अगर यूएसबी ऑडियो टर्मिनल टाइप फ़ील्ड 0x0302 है, तो AudioDeviceInfo.TYPE_USB_HEADSET टाइप के डिवाइस और isSink() की भूमिका को लिस्ट करना ज़रूरी है.
[7.8.2.2/A-1-2] अगर यूएसबी ऑडियो टर्मिनल टाइप फ़ील्ड 0x0402 है, तो AudioDeviceInfo.TYPE_USB_HEADSET टाइप के डिवाइस और isSink() की भूमिका को सूची में शामिल करना ज़रूरी है.
[7.8.2.2/A-1-3] अगर यूएसबी ऑडियो टर्मिनल टाइप फ़ील्ड 0x0603 है, तो AudioDeviceInfo.TYPE_USB_HEADSET टाइप और isSink() की भूमिका वाले डिवाइस को सूची में शामिल करना ज़रूरी है.
[7.8.2.2/A-1-4] अगर यूएसबी ऑडियो टर्मिनल टाइप फ़ील्ड 0x0400 है, तो AudioDeviceInfo.TYPE_USB_HEADSET टाइप के डिवाइस और isSink() की भूमिका को सूची में शामिल करना ज़रूरी है.

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

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

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

[5.1/A-0-4] MPEG-D DRC के साथ MPEG-D USAC (Extended High Efficiency AAC)

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

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

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

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

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

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

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

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] एसडीके में पहले से मौजूद वाहन की किसी प्रॉपर्टी को दोहराया नहीं जाना चाहिए.

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

[3.2.1/A-0-1] Automotive Permission के रेफ़रंस पेज पर दिए गए सभी अनुमतियों के कॉन्स्टेंट को लागू करना और उनके साथ काम करना ज़रूरी है.
[3.2.3.1/A-0-1] यह ज़रूरी है कि डिवाइस में एक या उससे ज़्यादा ऐप्लिकेशन या सेवा कॉम्पोनेंट को इंटेंट हैंडलर के साथ प्रीलोड किया जाए. ऐसा, यहां दिए गए ऐप्लिकेशन इंटेंट के लिए तय किए गए सभी सार्वजनिक इंटेंट फ़िल्टर पैटर्न के लिए किया जाना चाहिए.
[3.2.3.1/A-0-2] SDK टूल के दस्तावेज़ों में बताए गए तरीके के मुताबिक, ऐप्लिकेशन में ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE, और ACTION_CREATE_DOCUMENT इंटेंट को हैंडल करने की सुविधा होनी चाहिए. साथ ही, DocumentsProvider एपीआई का इस्तेमाल करके, दस्तावेज़ उपलब्ध कराने वाली कंपनी के डेटा को ऐक्सेस करने की सुविधा भी होनी चाहिए.

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

[3.2.3.1/A-1-1] में एक ऐसी ऐक्टिविटी होनी चाहिए जो स्प्लिट फ़ंक्शन चालू होने पर, Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY इंटेंट को हैंडल करती हो. ऐक्टिविटी को android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK से सुरक्षित किया जाना चाहिए. साथ ही, इसे Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI से पार्स किए गए इंटेंट की ऐक्टिविटी शुरू करनी चाहिए.
[3.4.1/A-0-1] android.webkit.Webview एपीआई को पूरी तरह से लागू करना ज़रूरी है.

[3.8/A-1-1] यह ज़रूरी है कि पूरी तरह से सेकंडरी यूज़र के लिए, UserRestrictions की पहले से तय की गई इस सूची को लागू किया जाए. ये ऐसे सेकंडरी यूज़र होते हैं जो फ़िलहाल फ़ोरग्राउंड यूज़र नहीं हैं, लेकिन उन्हें डिसप्ले का यूज़र इंटरफ़ेस (यूआई) ऐक्सेस करने की अनुमति मिली हुई है. UserRestrictions की सूची में ये शामिल हैं: DISALLOW_CONFIG_LOCALE, DISALLOW_CONFIG_BLUETOOTH, DISALLOW_BLUETOOTH, DISALLOW_CAMERA_TOGGLE, और DISALLOW_MICROPHONE_TOGGLE.
[3.8/A-1-2] यह ज़रूरी है कि ऐसे सेकंडरी उपयोगकर्ताओं को दिन/रात मोड, स्थान-भाषा, तारीख, समय, समय क्षेत्र या डिसप्ले के रंग से जुड़ी सुविधाओं (इसमें चमक, नाइट लाइट, डिजिटल वेलबीइंग के लिए ग्रेस्केल, और चटख रंगों को कम करना शामिल है) में बदलाव करने की अनुमति न दी जाए जो फ़िलहाल फ़ोरग्राउंड उपयोगकर्ता नहीं हैं, लेकिन उनके पास डिसप्ले का यूज़र इंटरफ़ेस (यूआई) ऐक्सेस करने की अनुमति है. ऐसा सेटिंग या एपीआई के ज़रिए किसी अन्य उपयोगकर्ता के लिए किया जा सकता है.

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

[3.8.3/A-0-1] तीसरे पक्ष के ऐप्लिकेशन के अनुरोध करने पर, Notification.CarExtender एपीआई का इस्तेमाल करने वाली सूचनाएं दिखाना ज़रूरी है.
[3.8.4/A-SR-1] डिवाइस पर असिस्टेंट को लागू करने का सुझाव दिया जाता है, ताकि असिस्ट करने की कार्रवाई को हैंडल किया जा सके.

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

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

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

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

अगर Automotive डिवाइस में सेट किए गए सिस्टम, उपयोगकर्ता एचएएल प्रॉपर्टी के साथ काम करते हैं, तो:

[3.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] मीडिया ऐप्लिकेशन की preference activity में नेविगेट करने की सुविधा उपलब्ध होनी चाहिए. हालांकि, इसे सिर्फ़ तब चालू किया जाना चाहिए, जब Car UX Restrictions लागू न हों.
[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-0-8] android.software.car.templates_host फ़ीचर फ़्लैग के बारे में एलान करना ज़रूरी है.
[3.14/A-0-9] com.android.car.background_audio_while_driving फ़ीचर फ़्लैग के बारे में एलान करना ज़रूरी है.
[3.14/A-0-10] android.software.car.templates_host.media फ़ीचर फ़्लैग के बारे में एलान करना ज़रूरी है.

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

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

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

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

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

[7.1.1/A-0-1] android.software.car.display_compatibility फ़ीचर फ़्लैग के बारे में एलान करना ज़रूरी है.

android.software.car.display_compatibility सुविधा वाले ऐप्लिकेशन या android.hardware.type.automotive सुविधा के बिना वाले ऐप्लिकेशन को फ़ोरग्राउंड में चलाने के दौरान, Automotive डिवाइस:

[7.1.1/A-1-1] में, 'वापस जाएं' फ़ंक्शन उपलब्ध होना चाहिए.

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

[7.4.1.2/A-1-1] android.software.telecom फ़ीचर फ़्लैग के बारे में एलान करना ज़रूरी है.

[7.4.1.2/A-1-2] टेलीकॉम फ़्रेमवर्क को लागू करना ज़रूरी है.

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

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

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

[8.2/A-0-1] हर प्रोसेस के यूआईडी के हिसाब से, नॉन-वोलेटाइल स्टोरेज में पढ़े और लिखे गए बाइट की संख्या की जानकारी देना ज़रूरी है, ताकि डेवलपर को सिस्टम एपीआई android.car.storagemonitoring.CarStorageMonitoringManager के ज़रिए आंकड़े मिल सकें. Android ओपन सोर्स प्रोजेक्ट, uid_sys_stats कर्नेल मॉड्यूल के ज़रिए इस ज़रूरी शर्त को पूरा करता है.
[8.2/A-0-2] यह ज़रूरी है कि डिवाइस में, क्रम से डेटा लिखने की परफ़ॉर्मेंस कम से कम 5 एमबी/सेकंड हो.
[8.2/A-0-3] यह पक्का करना ज़रूरी है कि रैंडम राइट परफ़ॉर्मेंस कम से कम 0.5 एमबी/सेकंड हो.
[8.2/A-0-4] यह ज़रूरी है कि सीक्वेंशियल रीड की परफ़ॉर्मेंस कम से कम 15 एमबी/सेकंड हो.
[8.2/A-0-5] यह पक्का करना ज़रूरी है कि रैंडम रीड की परफ़ॉर्मेंस कम से कम 3.5 एमबी/सेकंड हो.

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

[8.2/A-1-1] यह पक्का करना ज़रूरी है कि सीक्वेंशियल राइट परफ़ॉर्मेंस कम से कम 150 एमबी/सेकंड हो.
[8.2/A-1-2] यह ज़रूरी है कि रैंडम राइट परफ़ॉर्मेंस कम से कम 10 एमबी/सेकंड हो.
[8.2/A-1-3] यह पक्का करना ज़रूरी है कि सीक्वेंशियल रीड परफ़ॉर्मेंस कम से कम 250 एमबी/सेकंड हो.
[8.2/A-1-4] यह ज़रूरी है कि रैंडम रीड की परफ़ॉर्मेंस कम से कम 100 एमबी/सेकंड हो.
[8.2/A-1-5] ज़रूरी है कि इसमें एक साथ क्रम से पढ़ने और लिखने की सुविधा हो. साथ ही, पढ़ने की स्पीड लिखने की स्पीड से दोगुनी हो और कम से कम 50 एमबी/सेकंड हो.
[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 डिवाइस में सेट किए गए सिस्टम, System API VisualQueryDetectionService या माइक और/या कैमरे के ऐक्सेस की जानकारी दिए बिना क्वेरी का पता लगाने के लिए किसी अन्य तरीके का इस्तेमाल करते हैं, तो:

[9.8/A-1-1] यह पक्का करना ज़रूरी है कि क्वेरी का पता लगाने वाली सेवा, सिर्फ़ सिस्टम, ContentCaptureService या डिवाइस पर मौजूद स्पीच रिकग्निशन सेवा (SpeechRecognizer#createOnDeviceSpeechRecognizer() ने बनाई है) को डेटा ट्रांसमिट कर सकती है.
[9.8/A-1-2] VisualQueryDetectionService से बाहर किसी भी ऑडियो या वीडियो की जानकारी को ट्रांसमिट करने की अनुमति नहीं देनी चाहिए. हालांकि, ContentCaptureService या डिवाइस पर मौजूद स्पीच रिकग्निशन सेवा को इसकी अनुमति दी जा सकती है.
[9.8/A-1-3] जब डिवाइस को पता चलता है कि उपयोगकर्ता, डिजिटल असिस्टेंट ऐप्लिकेशन का इस्तेमाल करना चाहता है, तब सिस्टम यूज़र इंटरफ़ेस (यूआई) में उपयोगकर्ता को सूचना दिखानी होगी. जैसे, कैमरे से उपयोगकर्ता की मौजूदगी का पता चलने पर.
[9.8/A-1-4] उपयोगकर्ता की क्वेरी का पता चलने के तुरंत बाद, यूज़र इंटरफ़ेस (यूआई) में माइक्रोफ़ोन इंडिकेटर और उपयोगकर्ता की क्वेरी दिखनी चाहिए.
[9.8/A-1-5] उपयोगकर्ता के इंस्टॉल किए जा सकने वाले ऐप्लिकेशन को, विज़ुअल क्वेरी का पता लगाने की सेवा देने की अनुमति नहीं होनी चाहिए.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.6.1. हार्डवेयर

Gyroscope

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.6.2. सॉफ़्टवेयर

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

3. सॉफ़्टवेयर

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

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

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

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

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

[C-0-8] ज़रूरी है कि यह, एपीआई लेवल 24 26 से कम लेवल को टारगेट करने वाले ऐप्लिकेशन इंस्टॉल करने की सुविधा न दे.

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. सॉफ़्ट एपीआई कंपैटिबिलिटी

सेक्शन 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 17 के लिए अनुमति वाली वर्शन स्ट्रिंग में दी गई स्ट्रिंग वैल्यू में से कोई एक वैल्यू होनी चाहिए.
VERSION.SDK	यह Android सिस्टम का वह वर्शन है जो फ़िलहाल चल रहा है. यह तीसरे पक्ष के ऐप्लिकेशन कोड के लिए उपलब्ध फ़ॉर्मैट में होता है. Android 17 के लिए, इस फ़ील्ड में पूर्णांक वैल्यू 17_INT होनी चाहिए.
VERSION.SDK&lowbar;INT	यह Android सिस्टम का वह वर्शन है जो फ़िलहाल चल रहा है. यह तीसरे पक्ष के ऐप्लिकेशन कोड के लिए उपलब्ध फ़ॉर्मैट में होता है. Android 17 के लिए, इस फ़ील्ड में पूर्णांक वैल्यू 17&lowbar;INT होनी चाहिए.
VERSION.INCREMENTAL	डिवाइस बनाने वाली कंपनी की ओर से चुनी गई वैल्यू. यह वैल्यू, फ़िलहाल चल रहे Android सिस्टम के खास बिल्ड को इंसानों के पढ़ने लायक फ़ॉर्मैट में दिखाती है. इस वैल्यू का दोबारा इस्तेमाल नहीं किया जाना चाहिए. ऐसा इसलिए, क्योंकि असली उपयोगकर्ताओं के लिए अलग-अलग बिल्ड उपलब्ध कराए जाते हैं. आम तौर पर, इस फ़ील्ड का इस्तेमाल यह बताने के लिए किया जाता है कि बिल्ड जनरेट करने के लिए, किस बिल्ड नंबर या सोर्स-कंट्रोल चेंज आइडेंटिफ़ायर का इस्तेमाल किया गया था. इस फ़ील्ड की वैल्यू को प्रिंट किए जा सकने वाले 7-बिट ASCII के तौर पर कोड में बदला जाना चाहिए. साथ ही, यह रेगुलर एक्सप्रेशन `^[^ :\/~]+$` से मेल खानी चाहिए.
बोर्ड	यह वैल्यू, डिवाइस बनाने वाली कंपनी चुनती है. इससे डिवाइस में इस्तेमाल किए गए इंटरनल हार्डवेयर की पहचान होती है. यह वैल्यू, इंसानों के पढ़ने लायक फ़ॉर्मैट में होती है. इस फ़ील्ड का इस्तेमाल, डिवाइस को पावर देने वाले बोर्ड के खास वर्शन के बारे में बताने के लिए किया जा सकता है. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर कोड में बदला जा सकता है. साथ ही, यह रेगुलर एक्सप्रेशन `^[a-zA-Z0-9_-]+$` से मेल खानी चाहिए.
ब्रैंड	यह वैल्यू, डिवाइस से जुड़े ब्रैंड के नाम को दिखाती है. यह नाम, असली उपयोगकर्ताओं को दिखता है. यह ऐसा होना चाहिए जिसे आसानी से पढ़ा जा सके. साथ ही, इसमें डिवाइस के मैन्युफ़ैक्चरर या उस कंपनी के ब्रैंड का नाम होना चाहिए जिसके तहत डिवाइस की मार्केटिंग की जाती है. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर कोड में बदला जा सकता है. साथ ही, यह रेगुलर एक्सप्रेशन `^[a-zA-Z0-9_-]+$` से मेल खानी चाहिए.
SUPPORTED&lowbar;ABIS	नेटिव कोड के निर्देश सेट (सीपीयू टाइप + एबीआई कन्वेंशन) का नाम. सेक्शन 3.3 देखें. Native API Compatibility.
SUPPORTED&lowbar;32&lowbar;BIT&lowbar;ABIS	नेटिव कोड के निर्देश सेट (सीपीयू टाइप + एबीआई कन्वेंशन) का नाम. सेक्शन 3.3 देखें. Native API Compatibility.
SUPPORTED&lowbar;64&lowbar;BIT&lowbar;ABIS	नेटिव कोड के दूसरे इंस्ट्रक्शन सेट (सीपीयू टाइप + एबीआई कन्वेंशन) का नाम. सेक्शन 3.3 देखें. Native API Compatibility.
CPU&lowbar;ABI	नेटिव कोड के निर्देश सेट (सीपीयू टाइप + एबीआई कन्वेंशन) का नाम. सेक्शन 3.3 देखें. Native API Compatibility.
CPU&lowbar;ABI2	नेटिव कोड के दूसरे इंस्ट्रक्शन सेट (सीपीयू टाइप + एबीआई कन्वेंशन) का नाम. सेक्शन 3.3 देखें. Native API Compatibility.
डिवाइस	यह वैल्यू, डिवाइस को लागू करने वाले व्यक्ति या कंपनी चुनती है. इसमें डेवलपमेंट का नाम या कोड नेम होता है. इससे डिवाइस के हार्डवेयर की सुविधाओं और इंडस्ट्रियल डिज़ाइन के कॉन्फ़िगरेशन की पहचान होती है. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर कोड में बदला जा सकता है. साथ ही, यह रेगुलर एक्सप्रेशन `^[a-zA-Z0-9_-]+$` से मेल खानी चाहिए. प्रॉडक्ट की पूरी लाइफ़साइकल के दौरान, इस डिवाइस का नाम नहीं बदलना चाहिए.
फ़िंगरप्रिंट	यह एक स्ट्रिंग होती है, जो इस बिल्ड की खास तौर पर पहचान करती है. यह आसानी से पढ़ा जा सकने वाला होना चाहिए. यह इस टेंप्लेट के मुताबिक होना चाहिए: $(BRAND)/$(PRODUCT)/ $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) उदाहरण के लिए: acme/myproduct/ mydevice:17/LMYXX/3359:userdebug/test-keys फ़िंगरप्रिंट में खाली सफ़ेद जगह वाले वर्ण शामिल नहीं होने चाहिए. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर कोड में बदला जा सकता है.
हार्डवेयर	हार्डवेयर का नाम (कर्नेल कमांड लाइन या /proc से). यह आसानी से पढ़ा जा सकने वाला होना चाहिए. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर कोड में बदला जा सकता है. साथ ही, यह रेगुलर एक्सप्रेशन `^[a-zA-Z0-9_-]+$` से मेल खानी चाहिए.
HOST	यह एक स्ट्रिंग होती है. यह उस होस्ट की खास तौर पर पहचान करती है जिस पर बिल्ड बनाया गया था. यह स्ट्रिंग, ऐसे फ़ॉर्मैट में होती है जिसे कोई भी व्यक्ति आसानी से पढ़ सकता है. इस फ़ील्ड के लिए, किसी खास फ़ॉर्मैट की ज़रूरत नहीं होती. हालांकि, यह ज़रूरी है कि यह फ़ील्ड शून्य या खाली स्ट्रिंग ("") न हो.
आईडी	यह एक आइडेंटिफ़ायर है. इसे डिवाइस बनाने वाली कंपनी चुनती है. इसका इस्तेमाल किसी खास रिलीज़ को रेफ़र करने के लिए किया जाता है. यह आइडेंटिफ़ायर, इंसानों के पढ़ने लायक फ़ॉर्मैट में होता है. यह फ़ील्ड, android.os.Build.VERSION.INCREMENTAL के जैसा हो सकता है. हालांकि, यह ऐसा मान होना चाहिए जो असली उपयोगकर्ताओं के लिए काफ़ी अहम हो, ताकि वे सॉफ़्टवेयर बिल्ड के बीच अंतर कर सकें. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर कोड में बदला जा सकता है. साथ ही, यह रेगुलर एक्सप्रेशन `^[a-zA-Z0-9._-]+$` से मेल खानी चाहिए.
MANUFACTURER	प्रॉडक्ट के ओरिजनल इक्विपमेंट मैन्युफ़ैक्चरर (ओईएम) का कारोबार का नाम. इस फ़ील्ड के लिए, किसी खास फ़ॉर्मैट की ज़रूरत नहीं होती. हालांकि, यह ज़रूरी है कि यह फ़ील्ड शून्य या खाली स्ट्रिंग ("") न हो. प्रॉडक्ट के लाइफ़टाइम के दौरान, इस फ़ील्ड में बदलाव नहीं किया जाना चाहिए.
SOC&lowbar;MANUFACTURER	प्रॉडक्ट में इस्तेमाल किए गए मुख्य सिस्टम ऑन चिप (एसओसी) के मैन्युफ़ैक्चरर का ट्रेड नेम. एसओसी बनाने वाली एक ही कंपनी के डिवाइसों के लिए, एक जैसी कॉन्स्टेंट वैल्यू का इस्तेमाल किया जाना चाहिए. कृपया एसओसी बनाने वाली कंपनी से, इस्तेमाल करने के लिए सही कॉन्स्टेंट के बारे में पूछें. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर कोड में बदला जा सकता है. साथ ही, यह रेगुलर एक्सप्रेशन `^([0-9A-Za-z ]+)` से मेल खानी चाहिए. इसके अलावा, यह व्हाइटस्पेस से शुरू या खत्म नहीं होनी चाहिए और "unknown" के बराबर नहीं होनी चाहिए. प्रॉडक्ट के लाइफ़टाइम के दौरान, इस फ़ील्ड की वैल्यू में बदलाव नहीं होना चाहिए.
SOC&lowbar;MODEL	प्रॉडक्ट में इस्तेमाल किए गए मुख्य सिस्टम ऑन चिप (एसओसी) का मॉडल नाम. एक ही एसओसी मॉडल वाले डिवाइसों के लिए, एक जैसी कॉन्स्टेंट वैल्यू का इस्तेमाल किया जाना चाहिए. कृपया एसओसी मैन्युफ़ैक्चरर से, इस्तेमाल करने के लिए सही कॉन्स्टेंट के बारे में पूछें. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर कोड में बदला जा सकता है. साथ ही, यह रेगुलर एक्सप्रेशन `^([0-9A-Za-z ._/+-]+)$` से मेल खानी चाहिए. इसके शुरू या आखिर में व्हाइटस्पेस नहीं होना चाहिए. साथ ही, यह "unknown" के बराबर नहीं होनी चाहिए. प्रॉडक्ट के लाइफ़टाइम के दौरान, इस फ़ील्ड की वैल्यू में बदलाव नहीं होना चाहिए.
MODEL	यह वैल्यू, डिवाइस को लागू करने वाले व्यक्ति या कंपनी चुनती है. इसमें डिवाइस का वह नाम होता है जो उपयोगकर्ता को दिखता है. यह वही नाम होना चाहिए जिसके तहत डिवाइस की मार्केटिंग की जाती है और उसे असली उपयोगकर्ताओं को बेचा जाता है. इस फ़ील्ड के लिए, किसी खास फ़ॉर्मैट की ज़रूरत नहीं है. हालांकि, यह ज़रूरी है कि यह फ़ील्ड शून्य या खाली स्ट्रिंग ("") न हो. हमारा सुझाव है कि प्रॉडक्ट के जीवनकाल के दौरान, इस फ़ील्ड में बदलाव न करें.
प्रॉडक्ट	डिवाइस बनाने वाली कंपनी की चुनी गई वैल्यू. इसमें किसी खास प्रॉडक्ट (एसकेयू) का डेवलपमेंट नेम या कोड नेम शामिल होता है. यह वैल्यू, एक ही ब्रैंड के सभी प्रॉडक्ट के लिए यूनीक होनी चाहिए. यह ऐसा होना चाहिए जिसे आसानी से पढ़ा जा सके. हालांकि, यह ज़रूरी नहीं है कि इसे असली उपयोगकर्ता देख पाएं. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर कोड में बदला जा सकता है. साथ ही, यह रेगुलर एक्सप्रेशन `^[a-zA-Z0-9_-]+$` से मेल खानी चाहिए. प्रॉडक्ट के नाम में, प्रॉडक्ट के जीवनकाल के दौरान बदलाव नहीं किया जाना चाहिए.
ODM&lowbar;SKU	यह डिवाइस बनाने वाली कंपनी की चुनी गई एक वैकल्पिक वैल्यू होती है. इसमें डिवाइस के खास कॉन्फ़िगरेशन को ट्रैक करने के लिए इस्तेमाल किया गया एसकेयू (स्टॉक कीपिंग यूनिट) शामिल होता है. उदाहरण के लिए, डिवाइस के साथ बेचे गए किसी भी पेरीफ़ेरल डिवाइस का एसकेयू. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर कोड में बदला जा सकता है. साथ ही, यह रेगुलर एक्सप्रेशन `^([0-9A-Za-z.,_-]+)$` से मेल खानी चाहिए.
SERIAL	"UNKNOWN" वैल्यू दिखाना ज़रूरी है.
टैग	डिवाइस बनाने वाली कंपनी की ओर से चुने गए टैग की कॉमा लगाकर अलग की गई सूची. इससे बिल्ड को और बेहतर तरीके से पहचाना जा सकता है. टैग को 7-बिट ASCII के तौर पर कोड में बदला जा सकता है. साथ ही, यह रेगुलर एक्सप्रेशन `^[a-zA-Z0-9._-]+` से मेल खाना चाहिए. इसमें Android प्लैटफ़ॉर्म के तीन सामान्य साइनिंग कॉन्फ़िगरेशन में से किसी एक की वैल्यू होनी चाहिए: release-keys, dev-keys, और test-keys.
समय	यह वैल्यू, बिल्ड होने के समय के टाइमस्टैंप को दिखाती है.
वाई-फ़ाई के टाइप के बारे में जानकारी	डिवाइस में सेट किए गए सिस्टम के लिए, एपीआई लेवल के तौर पर बिल्ड कॉन्फ़िगरेशन की वैल्यू तय करना ज़रूरी है. इस फ़ील्ड में, Android के तीन सामान्य रनटाइम कॉन्फ़िगरेशन में से किसी एक की वैल्यू होनी चाहिए: उपयोगकर्ता, userdebug या eng.
उपयोगकर्ता	उस उपयोगकर्ता (या अपने-आप काम करने वाले उपयोगकर्ता) का नाम या यूज़र आईडी जिसने बिल्ड जनरेट किया है. इस फ़ील्ड के लिए, किसी खास फ़ॉर्मैट की ज़रूरत नहीं है. हालांकि, यह ज़रूरी है कि यह फ़ील्ड शून्य या खाली स्ट्रिंग ("") न हो.
SECURITY&lowbar;PATCH	यह वैल्यू, किसी बिल्ड के सुरक्षा पैच के लेवल के बारे में बताती है. इससे यह पता चलना चाहिए कि बिल्ड में, Android के सार्वजनिक सुरक्षा बुलेटिन में बताई गई किसी भी समस्या का जोखिम नहीं है. यह [YYYY-MM-DD] फ़ॉर्मैट में होना चाहिए. साथ ही, यह Android Public Security Bulletin या Android Security Advisory में दिए गए स्ट्रिंग से मेल खाना चाहिए. उदाहरण के लिए, "2015-11-01".
BASE&lowbar;OS	यह वैल्यू, बिल्ड के फ़िंगरप्रिंट पैरामीटर को दिखाती है. यह बिल्ड, Android Public Security Bulletin में दिए गए पैच को छोड़कर, इस बिल्ड के जैसा ही होता है. इसे सही वैल्यू रिपोर्ट करनी चाहिए. अगर ऐसा बिल्ड मौजूद नहीं है, तो इसे खाली स्ट्रिंग ("") रिपोर्ट करनी चाहिए.
बूटलोडर	डिवाइस को लागू करने वाले व्यक्ति या कंपनी की चुनी गई वैल्यू. इससे डिवाइस में इस्तेमाल किए गए खास इंटरनल बूटलोडर वर्शन की पहचान होती है. यह वैल्यू, इंसानों के पढ़ने लायक फ़ॉर्मैट में होती है. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर कोड में बदला जा सकता है. साथ ही, यह वैल्यू रेगुलर एक्सप्रेशन `^[a-zA-Z0-9._-]+$` से मेल खानी चाहिए.
getRadioVersion()	यह डिवाइस बनाने वाली कंपनी की चुनी गई वैल्यू होनी चाहिए या यह वैल्यू डिवाइस बनाने वाली कंपनी को वापस मिलनी चाहिए. यह वैल्यू, डिवाइस में इस्तेमाल किए गए किसी खास इंटरनल रेडियो/मॉडम वर्शन की पहचान करती है. यह वैल्यू, इंसानों के पढ़ने लायक फ़ॉर्मैट में होनी चाहिए. अगर किसी डिवाइस में कोई इंटरनल रेडियो/मॉडम नहीं है, तो उसे NULL वैल्यू दिखानी होगी. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर कोड में बदला जा सकता है. साथ ही, यह रेगुलर एक्सप्रेशन `^[a-zA-Z0-9._-,]+$` से मेल खानी चाहिए.
getSerial()	यह हार्डवेयर का सीरियल नंबर होना चाहिए. यह उपलब्ध होना चाहिए. साथ ही, एक ही मॉडल और मैन्युफ़ैक्चरर के सभी डिवाइसों के लिए यूनीक होना चाहिए. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर कोड में बदला जा सकता है. साथ ही, यह रेगुलर एक्सप्रेशन `^[a-zA-Z0-9]+$` से मेल खानी चाहिए.
STRONGBOX&lowbar;MANUFACTURER	प्रॉडक्ट में इस्तेमाल किए गए StrongBox चिप के मैन्युफ़ैक्चरर का ट्रेड नेम. StrongBox सप्लायर, सही कॉन्स्टेंट देता है. StrongBox की सुविधा देने वाली एक ही कंपनी के डिवाइसों के लिए, एक ही कॉन्स्टेंट वैल्यू का इस्तेमाल किया जाना चाहिए. इस फ़ील्ड की वैल्यू, रेगुलर एक्सप्रेशन `^([0-9A-Za-z ]+)` से मेल खानी चाहिए. साथ ही, यह "unsupported" के बराबर नहीं होनी चाहिए. इस फ़ील्ड की वैल्यू, प्रॉडक्ट के लाइफ़टाइम के दौरान नहीं बदलनी चाहिए.
STRONGBOX&lowbar;MODEL	प्रॉडक्ट में इस्तेमाल किए गए StrongBox चिप का मॉडल नाम. StrongBox सप्लायर, सही कॉन्स्टेंट देता है. StrongBox की सुविधा देने वाली एक ही कंपनी के डिवाइसों को एक जैसी कॉन्स्टेंट वैल्यू का इस्तेमाल करना चाहिए. इस फ़ील्ड की वैल्यू, रेगुलर एक्सप्रेशन `^([0-9A-Za-z ._/+-]+)$` से मेल खानी चाहिए. साथ ही, यह "unsupported" के बराबर नहीं होनी चाहिए. इस फ़ील्ड की वैल्यू, प्रॉडक्ट के लाइफ़टाइम में नहीं बदलनी चाहिए.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[C-11-1] MUST have an activity that handles the Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS intent but MAY implement it as a no-op.

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

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

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

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

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

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

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

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

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

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

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

[C-16-1] इंस्टॉल की गई, फ़ॉर्म अपने-आप भरने की सुविधा देने वाली सभी सेवाओं के लिए, ऐसे लिंक दिखाने चाहिए.

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

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

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

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

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

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

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

[C-19-1] NfcAdapter.ACTION_TRANSACTION_DETECTED Intent API को लागू करना ज़रूरी है. इसे GSM Association के तकनीकी स्पेसिफ़िकेशन TS.26 - NFC हैंडसेट की ज़रूरी शर्तों के मुताबिक "EVT_TRANSACTION" के तौर पर तय किया गया है.

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

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

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

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

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

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

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

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

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

मैनेज किया गया Dalvik bytecode, ऐप्लिकेशन की .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
- riscv64
[C-0-7] नेटिव कोड वाले ऐप्लिकेशन के लिए, नेटिव एपीआई उपलब्ध कराने वाली इन सभी लाइब्रेरी को उपलब्ध कराना ज़रूरी है:
- libaaudio.so (AAudio की नेटिव ऑडियो सहायता)
- libamidi.so (अगर सुविधा android.software.midi का दावा सेक्शन 5.9 में बताए गए तरीके से किया गया है, तो नेटिव MIDI सपोर्ट)
- libandroid.so (नेटिव Android ऐक्टिविटी के लिए सहायता)
- libc (C लाइब्रेरी)
- libcamera2ndk.so
- libdl (डाइनैमिक लिंकर)
- libEGL.so (नेटिव OpenGL सरफ़ेस मैनेजमेंट)
- libGLESv1_CM.so (OpenGL ES 1.x)
- libGLESv2.so (OpenGL ES 2.0)
- libGLESv3.so (OpenGL ES 3.x)
- libicui18n.so
- libicuuc.so
- libjnigraphics.so
- liblog (Android लॉगिंग)
- libmediandk.so (नेटिव मीडिया एपीआई के साथ काम करता है)
- libm (गणित लाइब्रेरी)
- libneuralnetworks.so (Neural Networks API)
- libOpenMAXAL.so (OpenMAX AL 1.0.1 के साथ काम करता है)
- libOpenSLES.so (OpenSL ES 1.0.1 ऑडियो सपोर्ट)
- libRS.so
- libstdc++ (C++ के लिए कम से कम ज़रूरी सहायता)
- libvulkan.so (Vulkan)
- libz (Zlib कंप्रेशन)
- JNI इंटरफ़ेस
[C-0-8] ऊपर दी गई नेटिव लाइब्रेरी के लिए, सार्वजनिक फ़ंक्शन जोड़े या हटाए नहीं जाने चाहिए.
[C-0-9] /vendor/etc/public.libraries.txt में, सीधे तौर पर तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराई गई, AOSP के अलावा अन्य लाइब्रेरी की सूची शामिल करना ज़रूरी है.
[C-0-10] सिस्टम लाइब्रेरी के तौर पर AOSP में लागू की गई और उपलब्ध कराई गई किसी भी अन्य नेटिव लाइब्रेरी को, तीसरे पक्ष के उन ऐप्लिकेशन के लिए उपलब्ध नहीं कराया जाना चाहिए जो एपीआई लेवल 24 या इससे ज़्यादा को टारगेट करते हैं. ऐसा इसलिए, क्योंकि ये लाइब्रेरी रिज़र्व होती हैं.
[C-0-11] NDK में तय किए गए OpenGL ES 3.1 और Android Extension Pack के सभी फ़ंक्शन सिंबल को libGLESv3.so लाइब्रेरी के ज़रिए एक्सपोर्ट करना ज़रूरी है. ध्यान दें कि सभी सिंबल मौजूद होने चाहिए. हालांकि, सेक्शन 7.1.4.1 में इस बारे में ज़्यादा जानकारी दी गई है कि हर फ़ंक्शन को पूरी तरह से लागू करने के लिए, कौनसी ज़रूरी शर्तें पूरी करनी होंगी.
[C-0-12] libvulkan.so लाइब्रेरी के ज़रिए, Vulkan 1.1 के मुख्य फ़ंक्शन सिंबल के साथ-साथ 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 ABI के साथ काम करने की सुविधा है, तो इस ABI का इस्तेमाल करने वाले ऐप्लिकेशन के लिए:

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

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

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

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

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

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

[C-1-5] SDK टूल के लेवल 36 और इससे ऊपर के लेवल को टारगेट करने वाले ऐप्लिकेशन के लिए, WebView से रिपोर्ट की गई सिस्टम डिफ़ॉल्ट उपयोगकर्ता एजेंट स्ट्रिंग इस फ़ॉर्मैट में होनी चाहिए:
```
Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) ; wv)
AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0
$(CHROMIUM_MAJOR_VER).0.0.0 Mobile Safari/537.36
```
- $(VERSION) की वैल्यू, स्टैटिक वैल्यू 10 होनी चाहिए.
- $(MODEL), स्टैटिक लेटर K होना चाहिए.
- $(CHROMIUM_MAJOR_VER) यह अपस्ट्रीम Android Open Source Project में Chromium का मेजर वर्शन होना चाहिए.
- डिवाइस लागू करने वाले लोग, उपयोगकर्ता एजेंट स्ट्रिंग में 'मोबाइल' शब्द को शामिल न करें.

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

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

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

[C-1-1] MUST support each of these APIs associated with HTML5:
[C-1-2] MUST support the HTML5/W3C webstorage API and SHOULD support the HTML5/W3C IndexedDB API. ध्यान दें कि वेब डेवलपमेंट के स्टैंडर्ड तय करने वाली संस्थाएं, वेबस्टोरेज के बजाय IndexedDB को प्राथमिकता दे रही हैं. इसलिए, उम्मीद है कि Android के आने वाले वर्शन में IndexedDB को शामिल करना ज़रूरी हो जाएगा.
स्टैंडअलोन ब्राउज़र ऐप्लिकेशन में, कस्टम उपयोगकर्ता एजेंट स्ट्रिंग शिप कर सकता है.
स्टैंडअलोन ब्राउज़र ऐप्लिकेशन पर, ज़्यादा से ज़्यादा HTML5 के साथ काम करना चाहिए. यह अपस्ट्रीम WebKit ब्राउज़र ऐप्लिकेशन या तीसरे पक्ष के ब्राउज़र ऐप्लिकेशन पर आधारित हो सकता है.

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

[C-2-1] को अब भी सार्वजनिक इंटेंट पैटर्न के साथ काम करना होगा. इनके बारे में section 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. बीसी - com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
6. HarmonyJSSE - com.android.org.conscrypt.JSSEProvider
7. AndroidKeyStore - android.security.keystore.AndroidKeyStoreProvider

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

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

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

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

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

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

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

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

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

[C-1-1] को सेक्शन 3.5.1 में दी गई सभी ज़रूरी शर्तों को पूरा करना होगा. हालांकि, [C-1-6] और [C-1-3] को छोड़कर.
[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-भाषा के सिग्नेचर पर कोई असर नहीं पड़ना चाहिए.
[C-0-4] इसका विज्ञापन नहीं किया जाना चाहिए. साथ ही, इसे डेवलपर के साथ शेयर नहीं किया जाना चाहिए.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[C-3-1] ShortcutManager.isRequestPinShortcutSupported() के लिए false एट्रिब्यूट की वैल्यू सबमिट करना ज़रूरी है.

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

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

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

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

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

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

3.8.2. विजेट

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

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

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

[C-1-3] में, स्टैंडर्ड ग्रिड साइज़ में 4 x 4 वाले विजेट रेंडर करने की सुविधा होनी चाहिए. ज़्यादा जानकारी के लिए, Android SDK के दस्तावेज़ में ऐप्लिकेशन विजेट डिज़ाइन करने के दिशा-निर्देश देखें.

[C-1-4] डाइनैमिक तौर पर जनरेट की गई विजेट की झलक दिखाने की सुविधा होनी चाहिए.
[C-1-5] इसमें उपयोगकर्ता को झलक दिखाने की सुविधा होनी चाहिए. साथ ही, AppWidgetManager.requestPinAppWidget() के ज़रिए ऐप्लिकेशन से मिले विजेट जोड़ने के अनुरोध को पूरा करने से पहले, उपयोगकर्ता से अनुमति लेनी चाहिए.
[C-1-6] ज़रूरी है कि ऐप्लिकेशन में, विजेट को पिन करने की सुविधा काम करती हो.
[C-1-7] AppWidgetManager.html.isRequestPinAppWidgetSupported() के लिए true की जानकारी देना ज़रूरी है.

लॉक स्क्रीन पर ऐप्लिकेशन विजेट दिखाने की सुविधा दे सकता है.

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

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

3.8.3. सूचनाएं

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

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

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

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

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

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

[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] suppressedVisualEffects की वैल्यू को NotificationManager.Policy के साथ पास करना ज़रूरी है. साथ ही, अगर किसी ऐप्लिकेशन ने SUPPRESSED_EFFECT_SCREEN_OFF या SUPPRESSED_EFFECT_SCREEN_ON फ़्लैग में से कोई भी फ़्लैग सेट किया है, तो उसे उपयोगकर्ता को यह बताना चाहिए कि 'परेशान न करें' सेटिंग मेन्यू में विज़ुअल इफ़ेक्ट बंद कर दिए गए हैं.

3.8.3.4. संवेदनशील सूचनाओं को सुरक्षित रखने की सुविधा

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

[C-1-1] सूचना सुनने वाली सेवाओं को संवेदनशील सूचना की जानकारी देने से पहले, उसे छिपाना ज़रूरी है. हालांकि, अगर सूचना सुनने वाली सेवा इनमें से कोई एक है, तो ऐसा करना ज़रूरी नहीं है:
- सिस्टम के ज़रिए साइन किए गए ऐसे ऐप्लिकेशन जिनके लिए uid < 10000
- सिस्टम यूज़र इंटरफ़ेस (यूआई)
- शेल
- कंपैनियन डिवाइस के लिए तय किया गया ऐप्लिकेशन (CompanionDeviceManager के हिसाब से तय किया गया)
- SYSTEM_AUTOMOTIVE_PROJECTION भूमिका
- SYSTEM_NOTIFICATION_INTELLIGENCE भूमिका
- HOME role

NotificationAssistantServices को AOSP में लागू करने से, इन ज़रूरी शर्तों के बारे में पता चलता है और ये पूरी होती हैं. उदाहरण के लिए, android.ext.services.notification देखें.

3.8.4. Assist API

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

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

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

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

[C-2-2] सेक्शन 7.2.3 में बताए गए तरीके से, सहायता करने वाले ऐप्लिकेशन को लॉन्च करने के लिए तय की गई इंटरैक्शन सुविधा को, उपयोगकर्ता के चुने गए सहायता करने वाले ऐप्लिकेशन को लॉन्च करना होगा. दूसरे शब्दों में, उस ऐप्लिकेशन को लॉन्च करना होगा जो VoiceInteractionService को लागू करता है या ACTION_ASSIST इंटेंट को हैंडल करने वाली गतिविधि को लॉन्च करना होगा.

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

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

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

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

3.8.6. थीम

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

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

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

[C-1-1] ऐप्लिकेशन के लिए उपलब्ध कराए गए किसी भी Holo थीम एट्रिब्यूट में बदलाव नहीं किया जाना चाहिए.
[C-1-2] "Material" थीम फ़ैमिली के साथ काम करना चाहिए. साथ ही, Material थीम एट्रिब्यूट या ऐप्लिकेशन के लिए उपलब्ध कराई गई उनकी ऐसेट में कोई बदलाव नहीं करना चाहिए.
[C-1-3] Roboto के साथ काम करने वाली भाषाओं के लिए, "sans-serif" फ़ॉन्ट फ़ैमिली को Roboto version 2.x पर सेट करना ज़रूरी है. इसके अलावा, Roboto के साथ काम करने वाली भाषाओं के लिए, "sans-serif" फ़ॉन्ट फ़ैमिली के लिए इस्तेमाल किए गए फ़ॉन्ट को Roboto version 2.x पर बदलने की सुविधा देना ज़रूरी है.
[C-1-4] AOSP के Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES के दस्तावेज़ में बताए गए तरीके से, डाइनैमिक कलर टोनल पैलेट जनरेट करना ज़रूरी है (android.theme.customization.system_palette और android.theme.customization.theme_style देखें).
[C-1-5] Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES दस्तावेज़ में दिए गए कलर थीम स्टाइल का इस्तेमाल करके, डाइनैमिक कलर टोनल पैलेट जनरेट करना ज़रूरी है. android.theme.customization.theme_styles देखें. ये स्टाइल हैं: TONAL_SPOT, VIBRANT, EXPRESSIVE, SPRITZ, RAINBOW, FRUIT_SALAD, और MONOCHROMATIC.

"सोर्स कलर" का इस्तेमाल, डाइनैमिक कलर टोनल पैलेट जनरेट करने के लिए किया जाता है. ऐसा तब होता है, जब इसे android.theme.customization.system_palette के साथ भेजा जाता है. इसके बारे में android.theme.customization.system_palette में बताया गया है.Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
[C-1-6] में CAM16 क्रोमा वैल्यू 5 या इससे ज़्यादा होनी चाहिए.
- इसे com.android.systemui.monet.ColorScheme#getSeedColors के ज़रिए वॉलपेपर से लिया जाना चाहिए. इससे, चुनने के लिए कई मान्य सोर्स कलर मिलते हैं.
- अगर दिए गए किसी भी रंग से, सोर्स कलर की ऊपर दी गई ज़रूरी शर्तें पूरी नहीं होती हैं, तो 0xFF1B6EF3 वैल्यू का इस्तेमाल करना चाहिए.

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

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

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

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

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

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

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

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

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

3.8.12. जगह

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[C-1-5] selfMovable प्रॉपर्टी वाले टास्क को पूरी तरह से ओपेसिटी के साथ दिखाना ज़रूरी है.साथ ही, उन्हें अलग से सजावट (जैसे, कैप्शन बार) के साथ दिखाना ज़रूरी है. इसके अलावा, ऐसे टास्क को उनकी सजावट से हटाने का तरीका भी उपलब्ध कराना ज़रूरी है.

स्क्रीन साइज़ xlarge वाले डिवाइसों में, फ़्रीफ़ॉर्म मोड काम करना चाहिए.

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

[C-2-2] स्प्लिट-स्क्रीन मल्टी-विंडो में डॉक की गई गतिविधि को काटना ज़रूरी है. हालांकि, अगर लॉन्चर ऐप्लिकेशन फ़ोकस की गई विंडो है, तो इसका कुछ कॉन्टेंट दिखाना चाहिए.
[C-2-3] MUST honor the declared AndroidManifestLayout_minWidth and AndroidManifestLayout_minHeight values of the third-party launcher application and not override these values in the course of showing some content of the docked activity.

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

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

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

[C-4-1] मल्टी-विंडो मोड के साथ काम करना ज़रूरी है.

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

[C-5-1] WindowManager एक्सटेंशन में बताए गए तरीके के मुताबिक, Window Manager Extensions API के सही वर्शन को लागू करना ज़रूरी है.

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

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

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

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

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

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

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

3.8.17. क्लिपबोर्ड

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

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

अगर डिवाइसों पर, क्लिपबोर्ड में कॉन्टेंट कॉपी करने पर उपयोगकर्ता को दिखने वाली झलक जनरेट होती है, तो:ClipDataClipData.getDescription().getExtras()android.content.extra.IS_SENSITIVE

[C-1-1] उपयोगकर्ता को दिखने वाली झलक को छिपाना ज़रूरी है

AOSP के रेफ़रंस इंप्लीमेंटेशन में, क्लिपबोर्ड से जुड़ी इन ज़रूरी शर्तों को पूरा किया जाता है.

3.8.18. लोकेशन बटन

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

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

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

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

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

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

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

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

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

3.9.1.2. मैनेज की जा रही प्रोफ़ाइल को उपलब्ध कराना

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

[C-1-1] android.software.device_admin को यह एलान करना होगा कि वह एपीआई लागू करेगा. इससे डिवाइस पॉलिसी कंट्रोलर (डीपीसी) ऐप्लिकेशन, मैनेज की जा रही नई प्रोफ़ाइल का मालिक बन सकेगा.
[C-1-2] Android 16 में इस ज़रूरी शर्त को हटा दिया गया है.
[C-1-3] सेटिंग में उपयोगकर्ता को ये सुविधाएं मिलनी चाहिए, ताकि उसे यह पता चल सके कि डिवाइस नीति कंट्रोलर (डीपीसी) ने किसी सिस्टम फ़ंक्शन को कब बंद किया है:
- किसी सेटिंग पर डिवाइस एडमिन की पाबंदी होने पर, उसे दिखाने के लिए एक जैसा आइकॉन या उपयोगकर्ता के लिए उपलब्ध अन्य सुविधा (उदाहरण के लिए, अपस्ट्रीम एओएसपी की जानकारी देने वाला आइकॉन).
- डिवाइस एडमिन ने setShortSupportMessage के ज़रिए, कम शब्दों में जानकारी देने वाला मैसेज भेजा है.
- डीपीसी ऐप्लिकेशन का आइकॉन.
[C-1-4] अगर android.app.action.PROVISION_MANAGED_PROFILE इंटेंट से प्रोविज़निंग शुरू की जाती है और DPC ने हैंडलर लागू किया है, तो वर्क प्रोफ़ाइल में ACTION_PROVISIONING_SUCCESSFUL इंटेंट के लिए हैंडलर लॉन्च करना ज़रूरी है. ऐसा तब किया जाना चाहिए, जब प्रोफ़ाइल के मालिक को सेट अप किया गया हो.
[C-1-5] ACTION_PROFILE_PROVISIONING_COMPLETE ब्रॉडकास्ट को वर्क प्रोफ़ाइल DPC को भेजना ज़रूरी है. ऐसा तब करना होगा, जब android.app.action.PROVISION_MANAGED_PROFILE इंटेंट के ज़रिए प्रोविज़निंग शुरू की गई हो.
[C-1-6] प्रोफ़ाइल के मालिक के लिए डिवाइस सेट अप करने की प्रोसेस शुरू होने के बाद, DPC ऐप्लिकेशन को ACTION_GET_PROVISIONING_MODE इंटेंट भेजना ज़रूरी है. इससे DPC ऐप्लिकेशन यह तय कर पाएगा कि उसे डिवाइस का मालिक बनना है या प्रोफ़ाइल का मालिक. हालांकि, अगर डिवाइस सेट अप करने की प्रोसेस, 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-5] डिवाइस के चालू होने (ACTION_USER_PRESENT) पर, यह ज़रूरी है कि उपयोगकर्ता को एक सूचना दिखे. इससे पता चले कि वह मैनेज की जा रही प्रोफ़ाइल में है. ऐसा तब होना चाहिए, जब फ़ोरग्राउंड ऐप्लिकेशन, मैनेज की जा रही प्रोफ़ाइल में हो.
[C-1-6] मैनेज की जा रही प्रोफ़ाइल मौजूद होने पर, डिवाइस नीति कंट्रोलर की ओर से चालू किए जाने पर, इंटेंट 'चूज़र' में विज़ुअल अफ़ॉर्डेंस दिखाना ज़रूरी है. इससे उपयोगकर्ता, मैनेज की जा रही प्रोफ़ाइल से प्राइमरी उपयोगकर्ता को या इसके उलट इंटेंट फ़ॉरवर्ड कर सकेगा.
[C-1-7] अगर कोई मैनेज की गई प्रोफ़ाइल मौजूद है, तो प्राइमरी यूज़र और मैनेज की गई प्रोफ़ाइल, दोनों के लिए उपयोगकर्ता को ये सुविधाएं उपलब्ध कराना ज़रूरी है:
- बैटरी, जगह की जानकारी, मोबाइल डेटा, और स्टोरेज के इस्तेमाल के लिए, प्राइमरी उपयोगकर्ता और मैनेज की जा रही प्रोफ़ाइल के लिए अलग-अलग हिसाब रखा जाता है.
- मुख्य उपयोगकर्ता या मैनेज की जा रही प्रोफ़ाइल में इंस्टॉल किए गए वीपीएन ऐप्लिकेशन को अलग से मैनेज किया जा सकता है.
- मुख्य उपयोगकर्ता या मैनेज की जा रही प्रोफ़ाइल में इंस्टॉल किए गए ऐप्लिकेशन को अलग से मैनेज किया जा सकता है.
- मुख्य उपयोगकर्ता या मैनेज की गई प्रोफ़ाइल में मौजूद खातों को अलग-अलग मैनेज करना.
[C-1-8] यह पक्का करना ज़रूरी है कि पहले से इंस्टॉल किए गए डायलर, संपर्क, और मैसेजिंग ऐप्लिकेशन, मैनेज की जा रही प्रोफ़ाइल (अगर मौजूद है) और प्राइमरी प्रोफ़ाइल से कॉल करने वाले की जानकारी खोज सकें और देख सकें. हालांकि, ऐसा सिर्फ़ तब किया जा सकता है, जब डिवाइस नीति कंट्रोलर इसकी अनुमति दे.
[C-1-9] यह पक्का करना ज़रूरी है कि यह सुरक्षा से जुड़ी उन सभी ज़रूरी शर्तों को पूरा करता हो जो एक ऐसे डिवाइस पर लागू होती हैं जिस पर एक से ज़्यादा उपयोगकर्ताओं के लिए सुविधा चालू है (सेक्शन 9.5 देखें). भले ही, मैनेज की जा रही प्रोफ़ाइल को मुख्य उपयोगकर्ता के अलावा किसी अन्य उपयोगकर्ता के तौर पर न गिना जाता हो.
[C-1-10] यह पक्का करना ज़रूरी है कि topActivity विंडो का स्क्रीनशॉट लेने पर, स्क्रीनशॉट का डेटा वर्क प्रोफ़ाइल के स्टोरेज में सेव हो. इस विंडो पर फ़ोकस किया गया हो. इसका मतलब है कि उपयोगकर्ता ने सभी गतिविधियों में से आखिरी बार इसी विंडो के साथ इंटरैक्ट किया हो. साथ ही, यह विंडो वर्क प्रोफ़ाइल के ऐप्लिकेशन से जुड़ी हो.
[C-1-11] वर्क प्रोफ़ाइल में स्क्रीनशॉट सेव करते समय, वर्क प्रोफ़ाइल ऐप्लिकेशन की विंडो/विंडो के अलावा, किसी अन्य स्क्रीन कॉन्टेंट (सिस्टम बार, सूचनाएं या किसी निजी प्रोफ़ाइल का कॉन्टेंट) को कैप्चर नहीं करना चाहिए. इससे यह पक्का किया जा सकेगा कि निजी प्रोफ़ाइल का डेटा, वर्क प्रोफ़ाइल में सेव न हो.

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

3.9.4. डिवाइस की नीति मैनेज करने की भूमिका के लिए ज़रूरी शर्तें

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

[C-1-1] यह ज़रूरी है कि डिवाइस, 9.1 सेक्शन में बताई गई डिवाइस की नीति को मैनेज करने की भूमिका के साथ काम करे. डिवाइस की नीति को मैनेज करने की भूमिका निभाने वाले ऐप्लिकेशन को, पैकेज का नाम सेट करके तय किया जा सकता है. इसके लिए, config_devicePolicyManagement को पैकेज के नाम पर सेट करें. पैकेज के नाम के बाद कोलन (:) और हस्ताक्षर करने का सर्टिफ़िकेट होना ज़रूरी है. हालांकि, अगर ऐप्लिकेशन पहले से लोड किया गया है, तो ऐसा करना ज़रूरी नहीं है.

अगर ऊपर बताए गए तरीके से config_devicePolicyManagement के लिए पैकेज का नाम तय नहीं किया गया है, तो:

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

अगर config_devicePolicyManagement के लिए पैकेज का नाम तय किया गया है, जैसा कि ऊपर बताया गया है, तो:

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

अगर config_devicePolicyManagementUpdater के लिए पैकेज का नाम ऊपर दिए गए तरीके से तय किया गया है, तो:

[C-4-1] ऐप्लिकेशन, डिवाइस पर पहले से इंस्टॉल होना चाहिए.
[C-4-2] ऐप्लिकेशन में एक इंटेंट फ़िल्टर लागू करना ज़रूरी है, जो android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER को हल करता हो.

3.9.5. Device Policy Resolution Framework

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

[C-1-1] Device Policy Resolution Framework में दिए गए निर्देशों के मुताबिक, डिवाइस की नीति से जुड़े विवादों को हल करना ज़रूरी है.

3.10. सुलभता

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

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

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

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

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

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

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

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

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

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

3.12. लागू नहीं

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

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

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

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

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

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

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

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

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

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

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

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

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

3.18. संपर्क

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

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

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

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

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

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

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

[C-1-1] कस्टम लोकल खाते का ACCOUNT_NAME, ContactsContract.RawContacts.getLocalAccountName को वापस करना होगा
[C-1-2] कस्टम लोकल खाते का ACCOUNT_TYPE, ContactsContract.RawContacts.getLocalAccountType को वापस करना होगा
[C-1-3] तीसरे पक्ष के ऐप्लिकेशन से डाले गए ऐसे रॉ कॉन्टैक्ट जिनके लिए खाते की जानकारी नहीं दी गई है उन्हें डिवाइस के डिफ़ॉल्ट कॉन्टैक्ट खाते में डाला जाना चाहिए. अगर संपर्कों का डिफ़ॉल्ट खाता DEFAULT_ACCOUNT_STATE_LOCAL या DEFAULT_ACCOUNT_STATE_NOT_SET है, तो इन रॉ संपर्कों को कस्टम लोकल खाते में सेव करना होगा.
[C-1-4] खातों को जोड़ने या हटाने पर, कस्टम लोकल खाते में डाले गए रॉ कॉन्टैक्ट नहीं हटाए जाने चाहिए.
[C-1-5] कस्टम लोकल खाते से जुड़ी मिटाने की कार्रवाइयों के बाद, रॉ कॉन्टैक्ट तुरंत मिट जाने चाहिए. ऐसा तब होना चाहिए, जब CALLER_IS_SYNCADAPTER पैरामीटर को सही पर सेट किया गया हो. भले ही, CALLER_IS_SYNCADAPTER पैरामीटर को गलत पर सेट किया गया हो या उसे तय न किया गया हो.

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

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

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

[C-1-6] ContactsContract.SimContacts.getSimAccounts को सिम खाते वापस करने होंगे.

3.18.2. सिस्टम कॉन्टैक्ट पिकर

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

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

[C-1-1] एपीआई लेवल 37 या इसके बाद के लेवल को टारगेट करने वाले ऐप्लिकेशन के लिए, सिस्टम कॉन्टैक्ट पिकर (com.android.contactspicker) को लागू करना ज़रूरी है.
[C-1-2] Intent.ACTION_PICK_CONTACTS इंटेंट को लागू करना ज़रूरी है.

3.19. भाषा की सेटिंग

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

[C-0-1] यह ज़रूरी है कि उन भाषाओं के लिए, लैंगिक जानकारी के हिसाब से भाषा चुनने की सुविधा न दी जाए जिनमें लैंगिक जानकारी के हिसाब से अनुवाद करने की सुविधा उपलब्ध नहीं है. ज़्यादा जानकारी के लिए, व्याकरण से जुड़े संसाधन देखें.

3.20. Assistant की मदद से मिलने वाले अनुभव

Android assistant development framework की मदद से, Android ऐप्लिकेशन को आवाज़ से कंट्रोल किया जा सकता है. Assistant का इस्तेमाल करके, उपयोगकर्ता अपनी आवाज़ से ऐप्लिकेशन लॉन्च कर सकते हैं, टास्क पूरे कर सकते हैं, कॉन्टेंट ऐक्सेस कर सकते हैं, और अन्य काम कर सकते हैं.

इस सेक्शन के लिए, खास डिवाइसों पर लागू होने वाले इन क्लासिफ़िकेशन को देखें:

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

3.20.1. Assistant की ऑडियो स्ट्रीम से जुड़ी ज़रूरी शर्तें

MANAGE_ASSISTANT_AUDIO अनुमति रखने वाला ऐप्लिकेशन:

[C-0-1] STREAM_ASSISTANT के वॉल्यूम को प्रोग्राम के हिसाब से बदलने की अनुमति होनी चाहिए.

अगर डिवाइसों में android.hardware.type.watch के बारे में नहीं बताया गया है और उनमें वॉल्यूम को कम-ज़्यादा करने की सुविधा नहीं है, तो:

[C-1-1] STREAM_ASSISTANT को अलग की गई ऑडियो स्ट्रीम के तौर पर लागू करना ज़रूरी है. साथ ही, इसे किसी दूसरी स्ट्रीम के तौर पर नहीं दिखाना चाहिए.
[C-1-2] यह पक्का करना ज़रूरी है कि USAGE_ASSISTANT के साथ AudioAttributes का इस्तेमाल करके ऑडियो चलाने पर, STREAM_ASSISTANT से ऑडियो की आवाज़ को कंट्रोल किया जा सके.
[C-1-3] यह पक्का करना ज़रूरी है कि किसी ब्लूटूथ हेडसेट के लिए, STREAM_ASSISTANT वॉल्यूम इंडेक्स वही रहे, जब हेडसेट A2DP और HFP ऑडियो प्रोफ़ाइलों के बीच स्विच करता है.
[C-1-4] MODE_ASSISTANT_CONVERSATION चालू होने पर, STREAM_ASSISTANT के अलावा किसी अन्य स्ट्रीम को STREAM_ASSISTANT की आवाज़ में बदलाव करने या USAGE_ASSISTANT के प्लेबैक पर लागू किए गए अटेन्युएशन में बदलाव करने से रोकना चाहिए.
[C-1-5] डिवाइस या पेरिफ़ेरल (जैसे कि ब्लूटूथ हेडसेट) के वॉल्यूम बटन से वॉल्यूम कम या ज़्यादा करने पर, STREAM_ASSISTANT स्ट्रीम का वॉल्यूम बदलना ज़रूरी है. साथ ही, किसी अन्य स्ट्रीम का वॉल्यूम नहीं बदलना चाहिए. ऐसा तब होना चाहिए, जब:
- MODE_ASSISTANT_CONVERSATION चालू है, और
- ऐप्लिकेशन के हिसाब से कोई कस्टम सेटिंग नहीं है या रिमोट से वीडियो चलाने की सुविधा चालू नहीं है.
[C-1-6] यूज़र इंटरफ़ेस में, Assistant की आवाज़ में किए गए किसी भी बदलाव को दिखाना ज़रूरी है.

3.21. कंपैनियन डिवाइस सिंक करने की सुविधा के साथ काम करने वाले डिवाइस

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

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

[C-1-1] ContextualModeManager#isModeSyncSupported एपीआई को लागू करना ज़रूरी है.
[C-1-2] यह ज़रूरी है कि CompanionDeviceManager सुरक्षित चैनल के ज़रिए, 'परेशान न करें' मोड के चालू होने की सेटिंग को सिंक किया जाए. इसके लिए, डिफ़ॉल्ट CompanionDeviceManagerService के साथ काम करने वाले डेटा फ़ॉर्मैट का इस्तेमाल किया जाना चाहिए.
[C-1-3] अगर ContextualModeManager#isModeSyncEnabled, true दिखाता है, तो इस सिंक को चालू करना ज़रूरी है.

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

[C-1-4] CompanionDeviceManager सुरक्षित चैनल के ज़रिए, यह सेटिंग सिंक करना ज़रूरी है कि हवाई जहाज़ मोड चालू है. इसके लिए, डिफ़ॉल्ट CompanionDeviceManagerService के साथ काम करने वाले डेटा फ़ॉर्मैट का इस्तेमाल करें.
[C-1-5] अगर Settings.Global.AIRPLANE_MODE_SYNC चालू है, तो सिंक करने की इस सुविधा को चालू करना ज़रूरी है.

3.22. ComputerControls API

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

[C-1-1] अगर डिवाइसों में, ComputerControl की सुविधा के लिए एक्सटेंशन लाइब्रेरी com.android.extensions.computercontrol को पहले से लोड किया जाता है, तो:

android.software.activities_on_secondary_display को चालू करना ज़रूरी है.
यह ज़रूरी है कि सिस्टम की सुविधा com.android.extensions.computercontrol को उपलब्ध के तौर पर दिखाया जाए.
VirtualDeviceManager को चालू करना ज़रूरी है.
PackageManager#getSharedLibraries() से मिली सूची में com.android.extensions.computercontrol को शामिल करना ज़रूरी है.
प्लैटफ़ॉर्म ऐप्लिकेशन com.android.virtualdevicemanager को प्रीलोड करना ज़रूरी है (बिल्ड टारगेट VirtualDeviceManager).

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

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

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

[C-0-2] APK सिग्नेचर स्कीम v3.2, APK सिग्नेचर स्कीम v3.1, APK सिग्नेचर स्कीम v3, APK सिग्नेचर स्कीम v2, और JAR signing का इस्तेमाल करके, ".apk" फ़ाइलों की पुष्टि करने की सुविधा उपलब्ध होनी चाहिए.

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

[C-1-4] MPEG-D DRC (एक्सटेंडेड हाई एफ़िशिएंसी एएसी) के साथ MPEG-D USAC

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

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

MPEG-D DRC (एक्सटेंडेड हाई एफ़िशिएंसी एएसी) ऑडियो के साथ MPEG-D USAC को एन्कोड करते समय:

[C-3-2] सभी बिटस्ट्रीम में, आईएसओ/आईईसी 23003-4 के मुताबिक, MPEG-D लाउडनेस कंट्रोल प्रोफ़ाइल या MPEG-D डाइनैमिक रेंज कंट्रोल प्रोफ़ाइल, लेवल 1 या इससे ज़्यादा के मुताबिक मेटाडेटा सेट शामिल होने चाहिए.

5.1.2. ऑडियो डिकोडिंग

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[C-7-1] ऐप्लिकेशन को डिकोडिंग का इस्तेमाल करके इसे कॉन्फ़िगर करने की अनुमति होनी चाहिए. इसके लिए, कुंजी KEY_MAX_OUTPUT_CHANNEL_COUNT का इस्तेमाल किया जाता है. इससे यह कंट्रोल किया जा सकता है कि कॉन्टेंट को स्टीरियो में डाउनमिक्स किया जाए या नहीं. ऐसा तब किया जाता है, जब वैल्यू 2 का इस्तेमाल किया जा रहा हो. इसके अलावा, यह भी कंट्रोल किया जा सकता है कि कॉन्टेंट को चैनलों की मूल संख्या का इस्तेमाल करके आउटपुट किया जाए या नहीं. ऐसा तब किया जाता है, जब वैल्यू उस संख्या के बराबर या उससे ज़्यादा हो. उदाहरण के लिए, 6 या इससे ज़्यादा वैल्यू होने पर, डिकोडर को 5.1 कॉन्टेंट देने पर, वह 6 चैनल आउटपुट करेगा.
[C-7-2] डिकोड करते समय, डिकोडर को KEY_CHANNEL_MASK कुंजी के साथ आउटपुट फ़ॉर्मैट पर इस्तेमाल किए जा रहे चैनल मास्क का विज्ञापन करना होगा. इसके लिए, android.media.AudioFormat कॉन्स्टेंट का इस्तेमाल करना होगा. उदाहरण के लिए: CHANNEL_OUT_5POINT1.

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

[C-8-1] इसमें IAMF v1.0 को डिकोड करने की सुविधा होनी चाहिए. इसमें AAC, FLAC, Opus या PCM में एन्कोड की गई ऑडियो स्ट्रीम शामिल होती हैं. साथ ही, इसमें android.media.MediaCodec API के ज़रिए IAMF डिकोडर उपलब्ध होना चाहिए.
[C-8-2] IAMF डिकोडर को यह पक्का करना होगा कि वह KEY_CHANNEL_MASK कुंजी के ज़रिए कॉन्फ़िगर किए जा रहे चैनल मास्क का पालन करे. इसके लिए, android.media.AudioFormat कॉन्स्टेंट का इस्तेमाल किया जाता है. जैसे,CHANNEL_OUT_5POINT1.
[C-8-3] IAMF डिकोडर को यह पक्का करना होगा कि वह KEY_CHANNEL_MASK कुंजी के ज़रिए, आउटपुट फ़ॉर्मैट पर चालू चैनल मास्क का विज्ञापन दिखाए. इसके लिए, android.media.AudioFormat कॉन्स्टेंट का इस्तेमाल करना होगा. जैसे, CHANNEL_OUT_5POINT1.

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

[C-SR-2] डिकोडर को ऐप्लिकेशन के ज़रिए कॉन्फ़िगर किया जा सकता है. इसके लिए, डिकोडिंग के साथ KEY_MAX_OUTPUT_CHANNEL_COUNT कुंजी का इस्तेमाल किया जाता है. इससे यह कंट्रोल किया जा सकता है कि कॉन्टेंट को स्टीरियो में डाउनमिक्स किया जाए (जब वैल्यू 2 का इस्तेमाल किया जा रहा हो) या उसे चैनलों की मूल संख्या का इस्तेमाल करके आउटपुट किया जाए (जब वैल्यू उस संख्या के बराबर या उससे ज़्यादा हो). इसलिए, डिकोडर को ऐप्लिकेशन के ज़रिए कॉन्फ़िगर करने का सुझाव दिया जाता है. उदाहरण के लिए, 6 या इससे ज़्यादा वैल्यू होने पर, डिकोडर को 5.1 कॉन्टेंट देने पर, वह 6 चैनल आउटपुट करेगा.
[C-SR-3] डिकोड करते समय, डिकोडर को KEY_CHANNEL_MASK कुंजी के साथ, आउटपुट फ़ॉर्मैट पर इस्तेमाल किए जा रहे चैनल मास्क का विज्ञापन करने का सुझाव दिया जाता है. इसके लिए, android.media.AudioFormat कॉन्स्टेंट का इस्तेमाल करें (उदाहरण: CHANNEL_OUT_5POINT1).

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

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

5.1.4. इमेज एन्कोडिंग

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

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

[C-0-1] JPEG
[C-0-2] PNG
[C-0-3] WebP
[C-0-4] AVIF
- डिवाइसों पर BITRATE_MODE_CQ और बेसलाइन प्रोफ़ाइल की सुविधा काम करनी चाहिए.

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

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

5.1.5. इमेज डिकोडिंग

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

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

[C-0-1] JPEG
[C-0-2] GIF
[C-0-3] PNG
[C-0-4] बीएमपी
[C-0-5] WebP
[C-0-6] रॉ
[C-0-7] AVIF (बेसलाइन प्रोफ़ाइल)

अगर डिवाइस में 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)
AVIF (बेसलाइन प्रोफ़ाइल)	इमेज, इमेज कलेक्शन, इमेज के क्रम वाली बेसलाइन प्रोफ़ाइल	HEIF कंटेनर (.avif)

MediaCodec API के ज़रिए इमेज एन्कोडर और डीकोडर उपलब्ध कराए जाते हैं

[C-1-1] CodecCapabilities के ज़रिए, YUV420 8:8:8 फ़्लेक्सिबल कलर फ़ॉर्मैट (COLOR_FormatYUV420Flexible) को सपोर्ट करना ज़रूरी है.
[C-SR-1] इनपुट सरफेस मोड के लिए, 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 के बराबर). हालांकि, दोनों को सपोर्ट करने का सुझाव दिया जाता है.
[C-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 कलर फ़ॉर्मैट को डिफ़ॉल्ट रूप से इस्तेमाल किया जाना चाहिए.

डिवाइस में वीडियो डीकोडर या एन्कोडर शामिल करने के लिए:

[C-5-1] 2003 या उसके बाद की कोडिंग टेक्नोलॉजी (जैसे, AV1, AVC, HEVC, VP8, VP9 या VVC) का इस्तेमाल करने वाले वीडियो डिकोडर के लिए यह ज़रूरी है कि:
- इमेज का कम से कम साइज़ 144 x 144 पिक्सल हो.
- VideoCapabilities API के ज़रिए, इस सुविधा का विज्ञापन दिखाएं. जैसे, getSupportedWidths() और getSupportedHeightsFor() तरीके.
[C-5-2] 2003 या उसके बाद की कोडिंग टेक्नोलॉजी (जैसे, AV1, AVC, HEVC, VP8, VP9 या VVC) का इस्तेमाल करने वाले वीडियो एन्कोडर के लिए यह ज़रूरी है कि:
- हर एनकोडर के लिए, कम से कम इस साइज़ के सर्फ़ेस इनपुट का इस्तेमाल किया जा सकता है:
  - एवीसी: 160x160 पिक्सल
  - VP8, HEVC, VP9 (अगर एन्कोडर उपलब्ध है): 160x160 पिक्सल
  - AV1 (अगर एन्कोडर उपलब्ध कराया गया है): 256x256 पिक्सल
- ऐसा हो सकता है कि एनकोडर, कम से कम फ़्रेम साइज़ से ज़्यादा साइज़ वाला बिटस्ट्रीम जनरेट करे. हालांकि, इसके लिए ज़रूरी है कि वह फ़ोटो काटने के लिए रेक्टैंगल बॉक्स की जानकारी का इस्तेमाल करके, सही साइज़ को एनकोड करे.

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

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

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

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

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

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

[C-1-1] को Android Open Source Project की तरह, मीडिया कोडेक के लिए OMX या Codec 2.0 एपीआई (या दोनों) की सुविधा देनी होगी. साथ ही, सुरक्षा उपायों को बंद या नाकाम नहीं करना होगा. इसका मतलब यह नहीं है कि हर कोडेक को OMX या Codec 2.0 API का इस्तेमाल करना होगा. इसका मतलब सिर्फ़ यह है कि इनमें से कम से कम एक 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 Open Source Project के सोर्स कोड पर आधारित होना चाहिए.
[C-SR-2] यह सुझाव दिया जाता है कि OMX सॉफ़्टवेयर कोडेक, कोडेक प्रोसेस में काम करें. इस प्रोसेस के पास, मेमोरी मैपर के अलावा अन्य हार्डवेयर ड्राइवर का ऐक्सेस नहीं होना चाहिए.

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

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

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

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

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

खास तौर पर:

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

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

[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 पिक्सल (अन्य, AV1)	1408 x 1152 पिक्सल (H263) 1280 x 720 पिक्सल (अन्य, AV1)	1920 x 1080 पिक्सल (MPEG4, AV1 के अलावा)	3840 x 2160 पिक्सल (HEVC, VP9, AV1)

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

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

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

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

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

[C-SR-2] में, यह सुझाव दिया जाता है कि एक सेकंड की स्लाइडिंग विंडो में, टारगेट बिटरेट से 15% से ज़्यादा न हो.

अगर डिवाइसों में कम से कम 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 का इस्तेमाल करके, QCIF रिज़ॉल्यूशन (176 x 144) के साथ काम करना ज़रूरी है. SQCIF रिज़ॉल्यूशन ज़रूरी नहीं है.

5.2.2. H.264

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

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

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

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

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

5.2.3. VP8

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

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

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

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

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

5.2.4. VP9

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

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

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

अगर डिवाइस में सेट किए गए सिस्टम, मीडिया एपीआई के ज़रिए Profile 2 या Profile 3 के साथ काम करने का दावा करते हैं, तो:

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

5.2.5. H.265

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

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

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

5.2.6. AV1

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

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

अगर AV1 एन्कोडर को हार्डवेयर की मदद से तेज़ी से प्रोसेस किया जाता है, तो:

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

	एसडी	एचडी 720 पिक्सल	एचडी 1080 पिक्सल	यूएचडी
वीडियो का रिज़ॉल्यूशन	720 x 480 पिक्सल	1280 x 720 पिक्सल	1920 x 1080 पिक्सल	3840 x 2160 पिक्सल
वीडियो फ़्रेम रेट	30 एफ़पीएस	30 एफ़पीएस	30 एफ़पीएस	30 एफ़पीएस
वीडियो बिटरेट	5 एमबीपीएस	8 एमबीपीएस	16 एमबीपीएस	50 एमबीपीएस

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

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

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

5.3.1. MPEG-2

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

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

5.3.2. H.263

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

[C-1-1] बेसलाइन प्रोफ़ाइल लेवल 30 (30 एफ़पीएस पर 384 केबीपीएस के साथ सीआईएफ़, क्यूसीआईएफ़, और एसक्यूसीआईएफ़ रिज़ॉल्यूशन) और लेवल 45 (30 एफ़पीएस पर 128 केबीपीएस के साथ क्यूसीआईएफ़ और एसक्यूसीआईएफ़ रिज़ॉल्यूशन) के साथ काम करना ज़रूरी है.

5.3.3. MPEG-4

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

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

5.3.4. H.264

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

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

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

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

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

5.3.5. H.265 (HEVC)

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

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

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

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

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

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

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

5.3.6. VP8

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

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

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

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

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

5.3.7. VP9

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

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

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

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

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

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

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

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

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

[C-4-1] डिवाइसों को, ऐप्लिकेशन से मिले ज़रूरी एचडीआर मेटाडेटा को स्वीकार करना होगा. जैसे, KEY_HDR_STATIC_INFO (सभी एचडीआर प्रोफ़ाइलों के लिए) और 'KEY_HDR10_PLUS_INFO' (HDR10Plus प्रोफ़ाइलों के लिए). साथ ही, यह भी ज़रूरी है कि वे बिटस्ट्रीम और/या कंटेनर से ज़रूरी एचडीआर मेटाडेटा को निकाल सकें और उसे आउटपुट कर सकें.
[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] इसमें Main Profile के साथ-साथ 8-बिट और 10-बिट कॉन्टेंट भी काम करना चाहिए.

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

[C-2-1] जब Display.getSupportedModes() तरीके से रिपोर्ट की गई ऊंचाई 720 पिक्सल के बराबर या उससे ज़्यादा हो, तब डिवाइस में नीचे दी गई टेबल में मौजूद, कम से कम HD 720 पिक्सल की वीडियो डिकोडिंग प्रोफ़ाइल को डिकोड करने की सुविधा होनी चाहिए.
[C-2-2] जब Display.getSupportedModes() तरीके से रिपोर्ट की गई ऊंचाई 1080 पिक्सल के बराबर या उससे ज़्यादा हो, तो नीचे दी गई टेबल से कम से कम HD 1080 पिक्सल वीडियो डिकोडिंग प्रोफ़ाइलें डिकोड की जा सकती हों.

	एसडी	एचडी 720 पिक्सल	एचडी 1080 पिक्सल	यूएचडी
वीडियो का रिज़ॉल्यूशन	720 x 480 पिक्सल	1280 x 720 पिक्सल	1920 x 1080 पिक्सल	3840 x 2160 पिक्सल
वीडियो फ़्रेम रेट	30 एफ़पीएस	30 एफ़पीएस	30 एफ़पीएस	30 एफ़पीएस
वीडियो बिटरेट	5 एमबीपीएस	8 एमबीपीएस	16 एमबीपीएस	50 एमबीपीएस

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

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

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

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

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

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

[C-1-1] डिवाइस को, किसी भी AudioRecord या AAudio इनपुट स्ट्रीम के लिए, रॉ ऑडियो कॉन्टेंट कैप्चर करने की अनुमति देनी होगी. हालांकि, ऐसा सिर्फ़ तब किया जा सकता है, जब स्ट्रीम को सफलतापूर्वक खोला गया हो. कम से कम ये सुविधाएं काम करनी चाहिए:
- फ़ॉर्मैट: लीनियर पीसीएम, 16-बिट
- सैंपलिंग रेट: 8000, 11025, 16000, 44100, 48000 हर्ट्ज़
- चैनल: मोनो
- ऑडियो सोर्स: DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED, या VOICE_PERFORMANCE. यह AAudio में मौजूद, मिलते-जुलते इनपुट प्रीसेट पर भी लागू होता है. उदाहरण के लिए, AAUDIO_INPUT_PRESET_CAMCORDER.
SHOULD allow capture of raw audio content with the following characteristics:
- फ़ॉर्मैट: लीनियर पीसीएम, 16-बिट और 24-बिट
- सैंपलिंग रेट: 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 हर्ट्ज़
- चैनल: डिवाइस पर मौजूद माइक्रोफ़ोन की संख्या के बराबर चैनल
[C-1-2] ज़रूरी है कि वह अप-सैंपलिंग के बिना, ऊपर दिए गए सैंपल रेट पर कैप्चर करे.
[C-1-3] जब ऊपर दी गई सैंपल दरें, डाउन-सैंपलिंग के साथ कैप्चर की जाती हैं, तो एंटी-एलियासिंग फ़िल्टर को शामिल करना ज़रूरी है.
इसमें एएम रेडियो और डीवीडी क्वालिटी में रॉ ऑडियो कॉन्टेंट कैप्चर करने की सुविधा होनी चाहिए. इसका मतलब है कि इसमें ये सुविधाएं होनी चाहिए:
- फ़ॉर्मैट: लीनियर पीसीएम, 16-बिट
- सैंपलिंग रेट: 22050, 48000 हर्ट्ज़
- चैनल: स्टीरियो
[C-1-4] MicrophoneInfo एपीआई का इस्तेमाल करना ज़रूरी है. साथ ही, डिवाइस पर उपलब्ध माइक्रोफ़ोन की जानकारी सही तरीके से भरनी होगी. यह जानकारी, AudioManager.getMicrophones() एपीआई के ज़रिए तीसरे पक्ष के ऐप्लिकेशन को ऐक्सेस की जा सकती है. ऐसा MediaRecorder.AudioSources DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED या VOICE_PERFORMANCE का इस्तेमाल करके, AudioRecord को चालू करने के लिए किया जाता है. अगर डिवाइसों में एएम रेडियो और डीवीडी क्वालिटी में रॉ ऑडियो कॉन्टेंट कैप्चर करने की सुविधा उपलब्ध है, तो:
[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 हर्ट्ज़ तक ±3dB.
[C-SR-1] में, कम फ़्रीक्वेंसी रेंज में ऐम्प्लिट्यूड लेवल दिखाने का सुझाव दिया जाता है. खास तौर पर, आवाज़ पहचानने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन के लिए, मिड-फ़्रीक्वेंसी रेंज की तुलना में 30 हर्ट्ज़ से 100 हर्ट्ज़ तक ±20 डीबी.
[C-SR-2] में, हाई फ़्रीक्वेंसी रेंज में ऐम्प्लिट्यूड लेवल दिखाने का सुझाव दिया जाता है. खास तौर पर, आवाज़ पहचानने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन के लिए, मिड-फ़्रीक्वेंसी रेंज की तुलना में 4000 हर्ट्ज़ से 22 किलोहर्ट्ज़ तक ±30 dB.
ऑडियो इनपुट की सेंसिटिविटी को इस तरह से सेट किया जाना चाहिए कि 90 dB साउंड प्रेशर लेवल (एसपीएल) पर चलाया गया 1000 हर्ट्ज़ का साइनसोडल टोन सोर्स (माइक्रोफ़ोन के बगल में मेज़र किया गया) 16 बिट-सैंपल के लिए, 1770 और 3530 की रेंज में आरएमएस 2500 का आइडियल रिस्पॉन्स दे. इसके अलावा, फ़्लोटिंग पॉइंट/डबल प्रेसिज़न सैंपल के लिए, -22.35 db ±3dB फ़ुल स्केल का आइडियल रिस्पॉन्स दे. ऐसा हर उस माइक्रोफ़ोन के लिए होना चाहिए जिसका इस्तेमाल, आवाज़ की पहचान करने वाले ऑडियो सोर्स को रिकॉर्ड करने के लिए किया जाता है.
आवाज़ पहचानने की सुविधा के लिए ऑडियो स्ट्रीम रिकॉर्ड की जानी चाहिए, ताकि पीसीएम ऐम्प्लिट्यूड लेवल, माइक्रोफ़ोन पर -18 dB से +12 dB re 90 dB एसपीएल तक कम से कम 30 dB की रेंज में, इनपुट एसपीएल में होने वाले बदलावों को लीनियर तरीके से ट्रैक कर सके.
आवाज़ पहचानने की सुविधा के लिए ऑडियो स्ट्रीम को रिकॉर्ड करते समय, माइक्रोफ़ोन पर 90 dB एसपीएल इनपुट लेवल पर 1 kHz के लिए, टोटल हार्मोनिक डिस्टॉर्शन (टीएचडी) 1% से कम होना चाहिए.

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

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

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

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

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

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

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

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

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

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

[C-SR-1] [C-1-1] are STRONGLY_RECOMMENDED MUST declare this via AcousticEchoCanceler API method AcousticEchoCanceler.isAvailable() returning true.

[C-1-2] MUST reflect the enablement of the AEC on the audio path through the AcousticEchoCanceler API method AcousticEchoCanceler.getEnabled(), which must return true when active, false when inactive.

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

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

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

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

5.5. ऑडियो चलाने की सुविधा

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

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

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

[C-1-1] इसमें रॉ ऑडियो कॉन्टेंट को चलाने की सुविधा होनी चाहिए. साथ ही, इसमें ये विशेषताएं होनी चाहिए:
- सोर्स फ़ॉर्मैट: लीनियर पीसीएम, 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 लागू किए गए हों. इन्हें AudioEffect की सबक्लास Equalizer और LoudnessEnhancer के ज़रिए कंट्रोल किया जा सकता है.
[C-1-2] ज़रूरी है कि इसमें विज़ुअलाइज़र एपीआई लागू किया गया हो. इसे Visualizer क्लास से कंट्रोल किया जा सकता है.
[C-1-3] ज़रूरी है कि इसमें EFFECT_TYPE_DYNAMICS_PROCESSING को लागू किया जा सके. इसे AudioEffect सबक्लास DynamicsProcessing के ज़रिए कंट्रोल किया जा सकता है.
[C-1-4] फ़्रेमवर्क ऑडियो पाइपलाइन को इफ़ेक्ट के नतीजे वापस भेजे जाने पर, फ़्लोटिंग-पॉइंट इनपुट और आउटपुट के साथ ऑडियो इफ़ेक्ट की सुविधा काम करनी चाहिए. इससे इक्वलाइज़र जैसे सामान्य इंसर्ट या ऑक्स इफ़ेक्ट का पता चलता है. जब फ़्रेमवर्क ऑडियो पाइपलाइन से इफ़ेक्ट के नतीजे नहीं दिखते हैं, तो उसी तरह का व्यवहार करने का सुझाव दिया जाता है. जैसे, पोस्ट-प्रोसेसिंग या ऑफलोड किए गए इफ़ेक्ट.
[C-1-5] यह पक्का करना ज़रूरी है कि ऑडियो इफ़ेक्ट, मिक्सर चैनल की संख्या (FCC_LIMIT) के हिसाब से कई चैनलों के साथ काम करते हों. ऐसा तब होता है, जब इफ़ेक्ट के नतीजे फ़्रेमवर्क ऑडियो पाइपलाइन को वापस भेजे जाते हैं. इसका मतलब है कि इसमें सामान्य इंसर्ट या ऑक्स इफ़ेक्ट शामिल हैं. हालांकि, इसमें स्पेशल इफ़ेक्ट शामिल नहीं हैं. जैसे, डाउनमिक्स, अपमिक्स या स्पैटियलाइज़ेशन इफ़ेक्ट, जिनसे चैनल की संख्या बदल जाती है. जब फ़्रेमवर्क ऑडियो पाइपलाइन से इफ़ेक्ट नहीं दिखते हैं, तब एक जैसा व्यवहार करने का सुझाव दिया जाता है. जैसे, पोस्ट-प्रोसेसिंग या ऑफ़लोड किए गए इफ़ेक्ट.
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 के मीडिया कंटेनर के ज़रिए बताए जाने पर, एक ही फ़ॉर्मैट की दो क्लिप के बीच बिना रुके चलने वाले ऑडियो कॉन्टेंट को ट्रिम करने का सुझाव दिया जाता है.
[C-SR-2] AAC, MP3, OPUS, और PCM फ़ॉर्मैट के लिए, ऑफ़लोड प्लेबैक की सुविधा लागू करने का सुझाव दिया जाता है.

अगर डिवाइस में लागू किए गए सिस्टम, MMAP PCM ऑफलोडिंग के साथ काम करने का एलान करते हैं (यह एलान, AUDIO_OUTPUT_FLAG_COMPRESS_OFFLOAD और AUDIO_OUTPUT_FLAG_MMAP_NOIRQ फ़्लैग वाले मिक्स पोर्ट से किया जाता है), तो:

[C-1-1] स्टीरियो और मोनो के लिए, कम से कम AUDIO_FORMAT_PCM_16_BIT को 44.1 किलोहर्ट्ज़ और 48 किलोहर्ट्ज़ पर सपोर्ट करना ज़रूरी है.
[C-1-2] ज़रूरी है कि बफ़र का साइज़ इतना हो कि वह 48 किलोहर्ट्ज़ स्टीरियो पीसीएम के हिसाब से, कम से कम पांच सेकंड का ऑडियो सेव कर सके. इसके लिए, हर सैंपल के लिए 16 बिट का इस्तेमाल किया जाता है.

5.5.5. वीडियो चलाने के पैरामीटर

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

[C-1-1] इसमें 0.5 से 2.0 के बीच की स्पीड के साथ-साथ 1.0 की पिच का इस्तेमाल किया जा सकता है.

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

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

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

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

लूपबैक पाथ ये हैं:
- स्पीकर/माइक: पहले से मौजूद स्पीकर से पहले से मौजूद माइक्रोफ़ोन तक.
- ऐनालॉग: 3.5 मि॰मी॰ ऐनालॉग जैक और लूपबैक अडैप्टर.
- यूएसबी: यूएसबी से 3.5 मि॰मी॰ अडैप्टर और लूपबैक अडैप्टर या यूएसबी ऑडियो इंटरफ़ेस और लूपबैक केबल.
FEATURE_AUDIO_LOW_LATENCY. android.hardware.audio.low_latency सुविधा का एलान किया गया हो.
FEATURE_AUDIO_PRO. android.hardware.audio.pro सुविधा का एलान किया गया हो.
MPC. मीडिया परफ़ॉर्मेंस क्लास.
हेड-ट्रैकिंग में लगने वाला समय. यह वह समय होता है जब इनर्शियल मेज़रमेंट यूनिट (आईएमयू) से सिर की हलचल का पता चलता है और हेडफ़ोन ट्रांसड्यूसर को इस हलचल की वजह से आवाज़ में हुए बदलाव का पता चलता है.

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

[C-0-1] यह पक्का करना ज़रूरी है कि जब कोई ऐप्लिकेशन, android.media.AudioManager.setCommunicationDevice() को कॉल करता है, तब device के साथ काम करने वाले ऑडियो डिवाइस (जैसे कि वायर्ड हेडसेट, पहले से मौजूद स्पीकर या ईयर-पीस या यूएसबी हेडसेट) के लिए, setCommunicationDevice() कॉल के true के 1500 मि॰से॰ के अंदर, android.media.AudioManager.OnCommunicationDeviceChangedListener.onCommunicationDeviceChanged() कॉलबैक को उस ऑडियो डिवाइस के साथ शुरू किया जाए.

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

[C-1-1] Android 15 में इस ज़रूरी शर्त को हटा दिया गया है.
[C-1-2] कोल्ड आउटपुट की लेटेन्सी 500 मिलीसेकंड या इससे कम होनी चाहिए.
[C-1-3] AAudioStreamBuilder_openStream() का इस्तेमाल करके आउटपुट स्ट्रीम खोलने में 1,000 मिलीसेकंड से कम समय लगना चाहिए.
[C-1-4] AAudioStream_getTimestamp से मिले इनपुट और आउटपुट टाइमस्टैंप के आधार पर कैलकुलेट की गई राउंड-ट्रिप लेटेंसी, स्पीकर, वायर्ड हेडसेट, और वायरलेस हेडसेट के लिए मेज़र की गई राउंड-ट्रिप लेटेंसी से 200 मि॰से॰ के अंदर होनी चाहिए.AAUDIO_PERFORMANCE_MODE_NONEAAUDIO_PERFORMANCE_MODE_LOW_LATENCY
[C-SR-1] Android 15 में इस ज़रूरी शर्त को हटा दिया गया है.
[C-SR-2] Android 15 में इस ज़रूरी शर्त को हटा दिया गया है.
[C-SR-4] Android 15 में इस ज़रूरी शर्त को हटा दिया गया है.
[C-SR-5] Android 15 में इस ज़रूरी शर्त को हटा दिया गया है.
[C-SR-6] Android 15 में इस ज़रूरी शर्त को हटा दिया गया है.
[C-SR-7] Android 15 में इस ज़रूरी शर्त को हटा दिया गया है.
[C-2-1] Android 15 में इस ज़रूरी शर्त को हटा दिया गया है.

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

[C-3-1] Android 15 में इस ज़रूरी शर्त को हटा दिया गया है.
[C-3-2] कोल्ड इनपुट लेटेन्सी 500 मिलीसेकंड या इससे कम होनी चाहिए.
[C-3-3] AAudioStreamBuilder_openStream() का इस्तेमाल करके इनपुट स्ट्रीम खोलने में 1000 मिलीसेकंड से कम समय लगना चाहिए.
[C-SR-8] Android 15 में इस ज़रूरी शर्त को हटा दिया गया है.
[C-SR-11] Android 15 में इस ज़रूरी शर्त को हटा दिया गया है.
[C-SR-12] Android 15 में इस ज़रूरी शर्त को हटा दिया गया है.

यहां दी गई टेबल में, हैंडहेल्ड डिवाइसों के लिए आरटीएल से जुड़ी ज़रूरी शर्तों के बारे में बताया गया है. ये शर्तें, 2.2.1 में बताई गई शर्तों के मुताबिक हैं. साथ ही, ये android.hardware.audio.output और android.hardware.microphone के बारे में बताती हैं.

डिवाइस और घोषणाएं	आरटीएल (मिलीसेकंड)	एमएडी (मि॰से॰)	लूपबैक पाथ
हैंडहेल्ड	200	25	स्पीकर/माइक, ऐनलॉग 3.5 मि॰मी॰ (अगर काम करता है), यूएसबी (अगर काम करता है)
MPC_C (17) और इसके बाद वाला वर्शन	65	10	सभी डेटा पाथ
>= MPC_T (13) through MPC_B (16)	80	15	कम से कम एक पाथ
FEATURE_AUDIO_LOW_LATENCY	50	10	कम से कम एक पाथ
FEATURE_AUDIO_PRO	25	5	कम से कम एक पाथ
FEATURE_AUDIO_PRO	20	5	analog (if supported)
FEATURE_AUDIO_PRO	25	5	यूएसबी (अगर ऐनलॉग नहीं काम करता है)

इस टेबल में, हैंडहेल्ड डिवाइस पर लागू होने वाले टीटीएल की ज़रूरी शर्तों के बारे में बताया गया है. ये शर्तें, 2.2.1 में बताई गई हैं. साथ ही, android.hardware.audio.output और android.hardware.microphone के बारे में भी बताया गया है.

डिवाइस और घोषणाएं	टीटीएल (मिलीसेकंड)
हैंडहेल्ड	250
MPC_C (17) और इसके बाद वाला वर्शन	65
>= MPC_T (13) through MPC_B (16)	80
MPC_S (12)	100
FEATURE_AUDIO_PRO	80

अगर डिवाइस में हेड ट्रैकिंग के साथ spatial audio की सुविधा शामिल है और PackageManager.FEATURE_AUDIO_SPATIAL_HEADTRACKING_LOW_LATENCY फ़्लैग का एलान किया गया है, तो:

[C-4-1] हेड ट्रैकिंग से ऑडियो अपडेट होने में ज़्यादा से ज़्यादा 300 मि॰से॰ की देरी होनी चाहिए.

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

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

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

[C-1-1] MUST support that codec or container over HTTP and HTTPS.
[C-1-2] एचटीटीपी लाइव स्ट्रीमिंग ड्राफ़्ट प्रोटोकॉल, वर्शन 7 के तहत, मीडिया सेगमेंट के फ़ॉर्मैट की टेबल में दिखाए गए मीडिया सेगमेंट के फ़ॉर्मैट के साथ काम करना ज़रूरी है.
[C-1-3] ज़रूरी है कि यह नीचे दी गई आरटीएसपी टेबल में दिखाए गए, आरटीएसपी के पेलोड फ़ॉर्मैट के साथ काम करे. अपवादों के बारे में जानने के लिए, कृपया सेक्शन 5.1 में टेबल के फ़ुटनोट देखें.

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

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

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

रेफ़रंस

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

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

ISO 13818

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

H264 एवीसी
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

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

WebVTT

RTSP (RTP, SDP)

प्रोफ़ाइल का नाम	रेफ़रंस	कोडेक के साथ काम करने की सुविधा
H264 एवीसी	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	ज़्यादा जानकारी के लिए, एचटीटीपी लाइव स्ट्रीमिंग के नीचे MPEG-2 ट्रांसपोर्ट स्ट्रीम देखें

5.8. Secure Media

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

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

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

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

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

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

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

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

[C-1-1] MIDI-सक्षम हार्डवेयर ट्रांसपोर्ट के सभी ट्रांसपोर्ट पर MIDI काम करना चाहिए. इसके लिए, वे MIDI के अलावा अन्य कनेक्टिविटी उपलब्ध कराते हैं. ये ट्रांसपोर्ट इस तरह के होते हैं:
- यूएसबी होस्ट मोड, section 7.7
- सेंट्रल डिवाइस के तौर पर काम करने वाले ब्लूटूथ LE पर MIDI, सेक्शन 7.4.3
[C-1-2] ऐप्लिकेशन के बीच एमआईडीआई सॉफ़्टवेयर ट्रांसपोर्ट (वर्चुअल एमआईडीआई डिवाइस) की सुविधा काम करनी चाहिए
[C-1-3] libamidi.so (नेटिव MIDI सपोर्ट) को शामिल करना ज़रूरी है
इसमें यूएसबी के ज़रिए MIDI पेरिफ़रल मोड काम करना चाहिए, सेक्शन 7.7

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

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

[C-1-1] android.hardware.audio.low_latency सुविधा के साथ काम करने की जानकारी देना ज़रूरी है.
[C-1-2] FEATURE_AUDIO_PRO के लिए, इंतज़ार के समय से जुड़ी ज़रूरी शर्तों को पूरा करना ज़रूरी है. इन शर्तों के बारे में, सेक्शन 5.6 ऑडियो के इंतज़ार का समय में बताया गया है.
[C-1-3] में यूएसबी पोर्ट शामिल होने चाहिए, जो यूएसबी होस्ट मोड और यूएसबी पेरीफ़ेरल मोड के साथ काम करते हों.
[C-1-4] android.software.midi सुविधा के साथ काम करने की जानकारी देना ज़रूरी है.
[C-1-5] AAudio native audio API और AAUDIO_PERFORMANCE_MODE_LOW_LATENCY का इस्तेमाल करके, यूएसबी ऑडियो के लिए ज़रूरी लेटेन्सी की शर्तों को पूरा करना ज़रूरी है.
[C-1-6] में कोल्ड आउटपुट की लेटेन्सी 200 मिलीसेकंड या इससे कम होनी चाहिए.
[C-1-7] कोल्ड इनपुट लेटेन्सी 200 मिलीसेकंड या इससे कम होनी चाहिए.

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

[C-2-2] Wired Audio Headset Specification (v1.1) के मोबाइल डिवाइस (जैक) की खास बातों वाले सेक्शन का पालन करना ज़रूरी है.

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

[C-3-1] यूएसबी ऑडियो क्लास को लागू करना ज़रूरी है.

5.11. प्रोसेस नहीं किए गए वीडियो के लिए कैप्चर करना

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

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

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

5.12. एचडीआर वीडियो

Android 13, एचडीआर टेक्नोलॉजी के साथ काम करता है. इसके बारे में आने वाले समय में एक दस्तावेज़ में बताया जाएगा.

Pixel Format

अगर कोई वीडियो डिकोडर, COLOR_FormatYUVP010 के साथ काम करने का दावा करता है, तो:

[C-1-1] सीपीयू से पढ़ने के लिए, P010 फ़ॉर्मैट काम करना चाहिए (ImageReader, MediaImage, ByteBuffer). Android 13 में, P010 को आसान बनाया गया है, ताकि Y और UV प्लैन के लिए आर्बिट्रेरी स्ट्राइड की अनुमति दी जा सके.
[C-1-2] P010 आउटपुट बफ़र को GPU से सैंपल किया जा सकता है. हालांकि, ऐसा तब ही किया जा सकता है, जब इसे GPU_SAMPLING के साथ असाइन किया गया हो. इससे ऐप्लिकेशन को जीपीयू कंपोज़िशन और कस्टम टोन मैपिंग की सुविधा मिलती है.

अगर कोई वीडियो डिकोडर COLOR_Format32bitABGR2101010 के साथ काम करने का दावा करता है, तो:

[C-2-1] आउटपुट सर्फ़ेस और सीपीयू के लिए पढ़ने लायक (ByteBuffer आउटपुट) के लिए, RGBA_1010102 फ़ॉर्मैट के साथ काम करना ज़रूरी है.

अगर कोई वीडियो एनकोडर, COLOR_FormatYUVP010 के साथ काम करने का विज्ञापन दिखाता है, तो:

[C-3-1] ज़रूरी है कि इनपुट सरफेस और सीपीयू से लिखे जा सकने वाले (ImageWriter, MediaImage, ByteBuffer) इनपुट के लिए, P010 फ़ॉर्मैट काम करता हो.

अगर कोई वीडियो एनकोडर, COLOR_Format32bitABGR2101010 के साथ काम करने का दावा करता है, तो:

[C-4-1] इनपुट सरफेस और सीपीयू से लिखे जा सकने वाले (ImageWriter, ByteBuffer) इनपुट के लिए, RGBA_1010102 फ़ॉर्मैट के साथ काम करना ज़रूरी है. ध्यान दें: एनकोडर के लिए, अलग-अलग ट्रांसफ़र कर्व के बीच कन्वर्ज़न करना ज़रूरी नहीं है.

एचडीआर कैप्चर करने से जुड़ी ज़रूरी शर्तें

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

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

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

[C-6-1] Camera2 एपीआई के ज़रिए भी एचडीआर कैप्चर की सुविधा काम करनी चाहिए.
[C-6-2] MUST support at least one hardware-accelerated video encoder for each HDR technology supported.
[C-6-3] कम से कम, एचएलजी कैप्चर के साथ काम करना ज़रूरी है.
[C-6-4] कैप्चर की गई वीडियो फ़ाइल में एचडीआर मेटाडेटा (अगर एचडीआर टेक्नोलॉजी पर लागू होता है) को सेव करने की सुविधा होनी चाहिए. AV1, HEVC, और DolbyVision के लिए, इसका मतलब है कि मेटाडेटा को एन्कोड किए गए बिटस्ट्रीम में शामिल करना.
[C-6-5] P010 और COLOR_FormatYUVP010 के साथ काम करना ज़रूरी है.
[C-6-6] कैप्चर की गई प्रोफ़ाइल के लिए, डिफ़ॉल्ट रूप से हार्डवेयर की मदद से काम करने वाले डिकोडर में, एचडीआर से एसडीआर टोन मैपिंग की सुविधा होनी चाहिए. दूसरे शब्दों में कहें, तो अगर कोई डिवाइस HDR10+ HEVC फ़ॉर्मैट में वीडियो कैप्चर कर सकता है, तो डिफ़ॉल्ट HEVC डिकोडर को कैप्चर की गई स्ट्रीम को एसडीआर फ़ॉर्मैट में डिकोड करना होगा.

एचडीआर वीडियो में बदलाव करने से जुड़ी ज़रूरी शर्तें

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

अगर एचडीआर मेटाडेटा मौजूद नहीं है, तो उसे जनरेट करने के लिए कम से कम लेटेन्सी का इस्तेमाल करना चाहिए. साथ ही, ऐसी स्थितियों को आसानी से हैंडल करना चाहिए जहां मेटाडेटा कुछ फ़्रेम के लिए मौजूद हो और कुछ के लिए न हो. यह मेटाडेटा सटीक होना चाहिए. उदाहरण के लिए, फ़्रेम की असल पीक ल्यूमिनेंस और हिस्टोग्राम दिखाना चाहिए.

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

[C-7-1] कम से कम एक एचडीआर प्रोफ़ाइल के साथ काम करना चाहिए.
[C-7-2] कोडेक के ज़रिए विज्ञापन में दिखाई गई सभी एचडीआर प्रोफ़ाइलों के लिए, FEATURE_HdrEditing के साथ काम करना ज़रूरी है. दूसरे शब्दों में, अगर एचडीआर मेटाडेटा का इस्तेमाल करने वाली सभी एचडीआर प्रोफ़ाइलों के लिए, एचडीआर मेटाडेटा मौजूद नहीं है, तो उन्हें एचडीआर मेटाडेटा जनरेट करने की सुविधा देनी होगी.
[C-7-3] यहां दिए गए वीडियो एन्कोडर को ऐसे इनपुट फ़ॉर्मैट में काम करना चाहिए जो डिकोड किए गए एचडीआर सिग्नल पूरी तरह से आगे बढ़ाए:
- RGBA_1010102 (already in the target transfer curve) for both input surface and ByteBuffer and MUST advertise support for COLOR_Format32bitABGR2101010.

अगर डिवाइस में ऐसे कोडेक शामिल हैं जो FEATURE_HdrEditing के साथ काम करते हैं, तो डिवाइस:

[C-7-4] EXT_YUV_target OpenGL एक्सटेंशन के लिए काम की जानकारी देना ज़रूरी है.

एचडीआर डिसप्ले के लिए ज़रूरी शर्तें

अगर डिवाइसों में, ADATASPACE_TRANSFER_HLG का इस्तेमाल करके एन्कोड किया गया बफ़र कॉन्टेंट मिलता है और उस कॉन्टेंट को SurfaceControl.Transaction#setBuffer के ज़रिए डिसप्ले पर भेजा जाता है, तो:

[C-8-1] BT. 2408-7 में दिए गए ग्राफ़िक्स के लिए, सफ़ेद रंग के सुझाव का पालन करना ज़रूरी है. साथ ही, सिर्फ़ ऐसे कॉन्टेंट को दिखाना ज़रूरी है जो एसडीआर कॉन्टेंट के मुकाबले ज़्यादा से ज़्यादा 4.926 गुना ज़्यादा हो.

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

6.1. डेवलपर टूल

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

[C-0-1] Android SDK में दिए गए Android डेवलपर टूल के साथ काम करना ज़रूरी है.
Android Debug Bridge (adb)
[C-0-2] Android SDK और AOSP में दिए गए शेल कमांड में बताए गए तरीके से, adb का इस्तेमाल किया जा सकता है. ऐप्लिकेशन डेवलपर, dumpsys, cmd stats, और Simpleperf का इस्तेमाल करके, adb का इस्तेमाल कर सकते हैं.
[C-0-11] शेल कमांड cmd testharness के साथ काम करना ज़रूरी है. अगर किसी डिवाइस को Android के पुराने वर्शन से अपग्रेड किया जा रहा है और उसमें डेटा ब्लॉक करने की सुविधा मौजूद नहीं है, तो हो सकता है कि उसे C-0-11 से छूट मिल जाए.
[C-0-3] dumpsys कमांड के ज़रिए लॉग किए गए डिवाइस सिस्टम इवेंट (batterystats, diskstats, fingerprint, graphicsstats, netstats, notification, procstats) के फ़ॉर्मैट या कॉन्टेंट में बदलाव नहीं किया जाना चाहिए.
[C-0-10] इन इवेंट को रिकॉर्ड करना ज़रूरी है. साथ ही, इन्हें cmd stats शेल कमांड और StatsManager सिस्टम एपीआई क्लास के लिए उपलब्ध कराना ज़रूरी है.
- ActivityForegroundStateChanged
- AnomalyDetected
- AppBreadcrumbReported
- AppCrashOccurred
- AppStartOccurred
- BatteryLevelChanged
- BatterySaverModeStateChanged
- BleScanResultReceived
- BleScanStateChanged
- ChargingStateChanged
- DeviceIdleModeStateChanged
- ForegroundServiceStateChanged
- GpsScanStateChanged
- InputDeviceUsageReported
- JobStateChanged
- KeyboardConfigured
- KeyboardSystemsEventReported
- PluggedStateChanged
- PressureStallInformation
- ScheduledJobStateChanged
- ScreenStateChanged
- SyncStateChanged
- SystemElapsedRealtime
- TouchpadUsage
- UidProcessStateChanged
- WakelockStateChanged
- WakeupAlarmOccurred
- WifiLockStateChanged
- WifiMulticastLockStateChanged
- WifiScanStateChanged
[C-0-4] डिवाइस-साइड adb डेमॉन डिफ़ॉल्ट रूप से बंद होना चाहिए. साथ ही, Android Debug Bridge को चालू करने के लिए, उपयोगकर्ता के पास एक ऐसा तरीका होना चाहिए जिसका इस्तेमाल वह आसानी से कर सके.
[C-0-5] सुरक्षित ए़डीबी के साथ काम करना ज़रूरी है. Android में सुरक्षित adb की सुविधा उपलब्ध है. Secure adb, पुष्टि किए गए होस्ट पर adb की सुविधा चालू करता है.
[C-0-6] ऐसा तरीका उपलब्ध कराना ज़रूरी है जिससे adb को किसी होस्ट मशीन से कनेक्ट किया जा सके. खास तौर से:

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

[C-3-1] लोकल-एरिया नेटवर्क (जैसे कि ईथरनेट या वाई-फ़ाई) के ज़रिए एडीबी को लागू करना ज़रूरी है.
[C-3-2] Windows 7, 8, और 10 के लिए ड्राइवर उपलब्ध कराने ज़रूरी हैं. इससे डेवलपर, adb प्रोटोकॉल का इस्तेमाल करके डिवाइस से कनेक्ट कर पाएंगे.

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

[C-4-1] AdbManager#isAdbWifiSupported() तरीके से true वैल्यू वापस मिलनी चाहिए.

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

[C-5-1] AdbManager#isAdbWifiQrSupported() तरीके से true वापस मिलना चाहिए.
Dalvik Debug Monitor Service (ddms)
- [C-0-7] यह ज़रूरी है कि डिवाइस, Android SDK में बताई गई सभी ddms सुविधाओं के साथ काम करता हो. डीडीएमएस, एडीबी का इस्तेमाल करता है. इसलिए, डीडीएमएस की सुविधा डिफ़ॉल्ट रूप से बंद होनी चाहिए. हालांकि, जब उपयोगकर्ता ऊपर दिए गए तरीके से Android Debug Bridge को चालू करता है, तब डीडीएमएस की सुविधा चालू होनी चाहिए.
SysTrace
- [C-0-9] यह ज़रूरी है कि डिवाइस, Android SDK में दिए गए दस्तावेज़ के मुताबिक, systrace टूल के साथ काम करे. Systrace डिफ़ॉल्ट रूप से बंद होना चाहिए. साथ ही, Systrace को चालू करने के लिए, उपयोगकर्ता के लिए उपलब्ध एक तरीका होना चाहिए.
Perfetto
- [C-SR-1] Are STRONGLY RECOMMENDED to expose a /system/bin/perfetto binary to the shell user which cmdline complies with the perfetto documentation.
- [C-SR-2] हमारा सुझाव है कि perfetto बाइनरी, इनपुट के तौर पर ऐसे protobuf कॉन्फ़िगरेशन को स्वीकार करे जो परफ़ेक्टो के दस्तावेज़ में तय किए गए स्कीमा के मुताबिक हो.
- [C-SR-3] यह सुझाव दिया जाता है कि perfetto बाइनरी, आउटपुट के तौर पर एक ऐसा प्रोटोबफ़ ट्रेस लिखे जो परफ़ेक्टो के दस्तावेज़ में तय किए गए स्कीमा के मुताबिक हो.
- [C-SR-4] यह सुझाव दिया जाता है कि perfetto बाइनरी के ज़रिए, कम से कम परफ़ेक्टो के दस्तावेज़ में बताए गए डेटा सोर्स उपलब्ध कराएं.
Low Memory Killer
- [C-0-12] जब किसी ऐप्लिकेशन को लो मेमोरी किलर बंद कर देता है, तब statsd लॉग में LMK_KILL_OCCURRED_FIELD_NUMBER ऐटम लिखना ज़रूरी है.
टेस्ट हार्नेस मोड

अगर डिवाइस में सेट किए गए सिस्टम, शेल कमांड cmd testharness के साथ काम करते हैं और cmd testharness enable चलाते हैं, तो:
- [C-2-1] ActivityManager.isRunningInUserTestHarness() के लिए true वैल्यू का दिखना ज़रूरी है
- [C-2-2] टेस्ट हार्नेस मोड के दस्तावेज़ में बताए गए तरीके के मुताबिक, टेस्ट हार्नेस मोड को लागू करना ज़रूरी है.
जीपीयू के काम की जानकारी

डिवाइस में सेट किए गए सिस्टम के लिए:
- [C-0-13] dumpsys gpu --gpuwork शेल कमांड को लागू करना ज़रूरी है, ताकि dumpsys gpu --gpuwork कर्नल ट्रेसपॉइंट से मिले, एग्रीगेट किए गए जीपीयू वर्क डेटा को दिखाया जा सके. अगर ट्रेसपॉइंट काम नहीं करता है, तो कोई डेटा नहीं दिखाया जाना चाहिए.power/gpu_work_period AOSP में लागू करने की सुविधा frameworks/native/services/gpuservice/gpuwork/ है.

अगर डिवाइस में Vulkan 1.0 या इसके बाद के वर्शन के साथ काम करने की सुविधा है, तो android.hardware.vulkan.version फ़ीचर फ़्लैग के ज़रिए इसकी जानकारी दी जाती है. ऐसे में:

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

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

[C-6-1] power.proto में बताए गए फ़ॉर्मैट power/gpu_frequency के मुताबिक, जीपीयू फ़्रीक्वेंसी ट्रेसपॉइंट की जानकारी देना ज़रूरी है.

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

[C-7-1] gpu.counters नाम के डेटा सोर्स के लिए, Perfetto डेटा प्रोड्यूसर उपलब्ध कराना ज़रूरी है. इसे perfetto --query का इस्तेमाल करके क्वेरी किया जा सकता है.
[C-7-2] जीपीयू काउंटर के ब्यौरे, जीपीयू काउंटर ट्रेस पैकेट प्रोटो के मुताबिक होने चाहिए.
[C-7-3] डिवाइस के लिए, जीपीयू काउंटर के लिए सही वैल्यू रिपोर्ट करना ज़रूरी है. इसके लिए, जीपीयू काउंटर ट्रेस पैकेट प्रोटोकॉल का इस्तेमाल करना होगा.
[C-7-4] चालू किए गए सभी जीपीयू काउंटर के लिए, टेक्स्ट के तौर पर जानकारी रिकॉर्ड करनी होगी. इसमें टाइमस्टैंप शामिल नहीं होना चाहिए.
[C-7-6] परफ़ॉर्मेंस को ट्रैक करने के लिए, जीपीयू परफ़ॉर्मेंस काउंटर का डिफ़ॉल्ट सेट उपलब्ध कराना ज़रूरी है. यह सेट खाली नहीं होना चाहिए. इसके बारे में GpuCounterSpec#select_by_default में बताया गया है.
- इन सभी डिफ़ॉल्ट काउंटर को एक साथ चालू किया जा सकता है.
- चालू होने पर, इन सभी को Perfetto को वैल्यू भेजनी होंगी.
[C-7-7] GpuCounterSpec#select_by_default का इस्तेमाल करके, डिफ़ॉल्ट रूप से चुने गए कम से कम एक काउंटर के लिए, जीपीयू के इस्तेमाल की जानकारी दिखानी होगी.

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

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

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

[C-9-1] GpuCounterSpec में बताए गए हर GPU काउंटर ग्रुप में कम से कम एक काउंटर होना चाहिए: COMPUTE, FRAGMENTS, MEMORY, PRIMITIVES, और VERTICES.

अगर डिवाइस में सेट किए गए सिस्टम, graphics.gpu.profiler.support और graphics.gpu.profiler.support.gpu_counters.groups, दोनों सिस्टम प्रॉपर्टी को true पर सेट करते हैं और डिवाइस रे ट्रेसिंग के साथ काम करता है, तो:

[C-10-1] RAY_TRACING ग्रुप में काउंटर होना ज़रूरी है.

अगर डिवाइसों पर, सिस्टम की दोनों प्रॉपर्टी graphics.gpu.profiler.support और graphics.gpu.profiler.support.gpu_counters.zeroes_optimization को true पर सेट किया जाता है, तो:
[C-11-1] एक ही Perfetto ट्रेस सेशन में, GPU काउंटर को सिर्फ़ तब शून्य वैल्यू रिपोर्ट करनी चाहिए, जब पहले या बाद में रिपोर्ट की गई वैल्यू शून्य न हो.

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

[C-12-1] gpu.renderstages नाम के डेटा सोर्स के लिए, Perfetto डेटा प्रोड्यूसर उपलब्ध कराना ज़रूरी है. इस डेटा सोर्स को perfetto --query. का इस्तेमाल करके क्वेरी किया जा सकता है
[C-12-2] जीपीयू रेंडर स्टेज इवेंट प्रोटो के मुताबिक, जीपीयू रेंडर स्टेज के लिए नियमों का पालन करने वाली वैल्यू रिपोर्ट करना ज़रूरी है.

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

[C-13-1] Vulkan के हर कॉल के लिए, Vulkan ड्राइवर को Vulkan API इवेंट मैसेज स्पेसिफ़िकेशन के मुताबिक Perfetto ट्रेस इवेंट जनरेट करना होगा.
- इस इवेंट में एक यूनीक, मोनोटोनिकली बढ़ने वाला submission_id होना चाहिए. यह submission_id, जीपीयू रेंडर स्टेज के इवेंट में मौजूद submission_id से मेल खाना चाहिए.

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

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

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

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

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

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

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

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

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

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

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

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

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

[C-0-1] डिफ़ॉल्ट रूप से, तीसरे पक्ष के ऐप्लिकेशन सिर्फ़ Android के साथ काम करने वाले डिसप्ले पर रेंडर होने चाहिए.

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

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

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

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

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

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

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

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

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

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

[C-4-1] डिसप्ले कटआउट को छोड़कर, लेआउट का साइज़ कम से कम 596 डीपी x 384 डीपी या इससे ज़्यादा होना चाहिए.

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

[C-4-1] Android 15 में इस ज़रूरी शर्त को हटा दिया गया है.

7.1.1.2. स्क्रीन का आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात)

इस सेक्शन को Android 14 में हटा दिया गया है.

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

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

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

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

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

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

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

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

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

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

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

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] Android 16 में इस ज़रूरी शर्त को हटा दिया गया है.
[C-1-2] ओरिएंटेशन बदलने पर, रिपोर्ट किए गए स्क्रीन साइज़ या डेनसिटी में बदलाव नहीं होना चाहिए.
पोर्ट्रेट या लैंडस्केप ओरिएंटेशन को डिफ़ॉल्ट के तौर पर चुना जा सकता है.

7.1.4. 2D और 3D ग्राफ़िक ऐक्सेलरेशन

7.1.4.1. OpenGL ES

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-1] यह ज़रूरी है कि डिवाइस, मैनेज किए गए एपीआई (जैसे कि GLES10.getString() तरीके से) और नेटिव एपीआई के ज़रिए, OpenGL ES के काम करने वाले वर्शन (1.1, 2.0, 3.0, 3.1, 3.2) की सही पहचान करे.
[C-0-2] यह ज़रूरी है कि डिवाइस में, OpenGL ES के हर उस वर्शन के लिए मैनेज किए गए सभी एपीआई और नेटिव एपीआई काम करते हों जिनके साथ डिवाइस काम करता है.

अगर डिवाइस में स्क्रीन या वीडियो आउटपुट शामिल है, तो:

[C-1-1] Android SDK के दस्तावेज़ में बताए गए और दिए गए निर्देशों के मुताबिक, OpenGL ES 1.1, 2.0, 3.0, और 3.1 के साथ काम करना ज़रूरी है.
[C-SR-1] Android 15 में इस ज़रूरी शर्त को हटा दिया गया है.
OpenGL ES 3.2 काम करना चाहिए.

OpenGL ES dEQP टेस्ट को कई टेस्ट लिस्ट में बांटा गया है. हर लिस्ट में, तारीख/वर्शन नंबर शामिल होता है. ये Android सोर्स ट्री में external/deqp/android/cts/main/glesXX-master-YYYY-MM-DD.txt पर मौजूद हैं. अगर कोई डिवाइस, 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 के हर वर्शन के लिए, टेस्ट लिस्ट में मौजूद सभी OpenGL ES dEQP टेस्ट पास करना ज़रूरी है. ये टेस्ट, 132383489 वर्शन और android.software.opengles.deqp.level फ़ीचर फ़्लैग में बताए गए वर्शन के बीच के होने चाहिए.
[C-SR-2] EGL_KHR_partial_update और OES_EGL_image_external एक्सटेंशन के साथ काम करने का सुझाव दिया जाता है.
उन्हें getString() तरीके का इस्तेमाल करके, टेक्सचर कंप्रेस करने वाले किसी भी ऐसे फ़ॉर्मैट की सटीक जानकारी देनी चाहिए जिसका वे इस्तेमाल करते हैं. आम तौर पर, यह जानकारी वेंडर के हिसाब से अलग-अलग होती है.
EGL_IMG_context_priority और EGL_EXT_protected_content एक्सटेंशन सपोर्ट करने चाहिए.

अगर डिवाइस में 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 Extension Pack के साथ पूरी तरह से काम करना ज़रूरी है.

अगर डिवाइस में OpenGL ES Android Extension Pack की सभी सुविधाएं काम करती हैं, तो:

[C-5-1] android.hardware.opengles.aep फ़ीचर फ़्लैग के ज़रिए, सहायता की पहचान करना ज़रूरी है.

अगर डिवाइस में सेट किए गए सिस्टम, EGL_KHR_mutable_render_buffer एक्सटेंशन के साथ काम करते हैं, तो:

[C-6-1] EGL_ANDROID_front_buffer_auto_refresh एक्सटेंशन के साथ काम करना भी ज़रूरी है.

7.1.4.2. Vulkan

Android में Vulkan के साथ काम करने की सुविधा शामिल है. यह ज़्यादा परफ़ॉर्मेंस वाले 3D ग्राफ़िक के लिए, कम ओवरहेड वाला क्रॉस-प्लैटफ़ॉर्म एपीआई है.

अगर डिवाइस में OpenGL ES 3.1 का इस्तेमाल किया जाता है, तो:

[C-SR-1] Vulkan 1.3 के साथ काम करने की सुविधा शामिल करने का सुझाव दिया जाता है.
[C-4-1] Vulkan के वैरिएंट वर्शन के साथ काम नहीं करना चाहिए. इसका मतलब है कि Vulkan के कोर वर्शन का वैरिएंट पार्ट शून्य होना चाहिए.

अगर डिवाइस में स्क्रीन या वीडियो आउटपुट शामिल है, तो:

[C-SR-2] में Vulkan 1.3 के साथ काम करने की सुविधा शामिल करने का सुझाव दिया जाता है.

Vulkan dEQP टेस्ट को कई टेस्ट सूचियों में बांटा गया है. हर सूची में, तारीख/वर्शन की जानकारी दी गई है. ये Android सोर्स ट्री में external/deqp/android/cts/main/vk-master-YYYY-MM-DD.txt पर मौजूद हैं. Vulkan के साथ काम करने वाला कोई डिवाइस, खुद से बताए गए लेवल पर यह दिखाता है कि वह इस लेवल और इससे पहले के सभी लेवल की टेस्ट लिस्ट में dEQP टेस्ट पास कर सकता है.

अगर डिवाइस में Vulkan का इस्तेमाल किया जाता है, तो:

[C-1-1] android.hardware.vulkan.level और android.hardware.vulkan.version फ़ीचर फ़्लैग के साथ सही पूर्णांक वैल्यू रिपोर्ट करना ज़रूरी है.
[C-1-2] Vulkan नेटिव एपीआई vkEnumeratePhysicalDevices() के लिए, कम से कम एक VkPhysicalDevice की गिनती करना ज़रूरी है.
[C-1-3] हर VkPhysicalDevice के लिए, Vulkan 1.1 एपीआई को पूरी तरह से लागू करना ज़रूरी है.
[C-1-4] ऐप्लिकेशन पैकेज की नेटिव लाइब्रेरी डायरेक्ट्री में मौजूद, libVkLayer*.so नाम की नेटिव लाइब्रेरी में शामिल लेयर की गिनती Vulkan नेटिव एपीआई vkEnumerateInstanceLayerProperties() और vkEnumerateDeviceLayerProperties() के ज़रिए की जानी चाहिए.

[C-1-5] ऐप्लिकेशन पैकेज के बाहर की लाइब्रेरी से उपलब्ध कराई गई लेयर को नहीं गिनना चाहिए. इसके अलावा, Vulkan API को ट्रेस या इंटरसेप्ट करने के अन्य तरीके भी उपलब्ध नहीं कराने चाहिए. ऐसा तब तक नहीं करना चाहिए, जब तक ऐप्लिकेशन में android:debuggable एट्रिब्यूट को true के तौर पर सेट न किया गया हो या मेटाडेटा com.android.graphics.injectLayers.enable को true के तौर पर सेट न किया गया हो . हालांकि, Vulkan लागू करें दस्तावेज़ के मुताबिक, ओईएम और प्लैटफ़ॉर्म लेयर को छोड़कर ऐसा करना चाहिए.

[C-1-6] Vulkan नेटिव एपीआई के ज़रिए, उन सभी एक्सटेंशन स्ट्रिंग की रिपोर्ट करना ज़रूरी है जिनके साथ वे काम करते हैं. इसके उलट, उन एक्सटेंशन स्ट्रिंग की रिपोर्ट नहीं करनी चाहिए जिनके साथ वे ठीक से काम नहीं करते.

[C-1-7] इन एक्सटेंशन के साथ काम करना ज़रूरी है:
- VK_EXT_present_mode_fifo_latest_ready
- VK_KHR_present_wait2
- VK_KHR_android_surface
- VK_KHR_incremental_present
- VK_KHR_present_id
- VK_KHR_present_id2
- VK_KHR_surface
- VK_KHR_swapchain

[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-3] यह सुझाव दिया जाता है कि ये एक्सटेंशन काम करें:
- VK_EXT_present_timing
- VK_GOOGLE_display_timing
- VK_KHR_driver_properties

[C-1-12] VK_KHR_performance_query एक्सटेंशन के साथ काम करने की सुविधा के बारे में नहीं बताना चाहिए.
[C-SR-4] Android Baseline 2022 प्रोफ़ाइल में बताई गई ज़रूरी शर्तों को पूरा करने का सुझाव दिया जाता है.
[C-SR-5] यह सुझाव दिया जाता है कि VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory और VK_EXT_global_priority काम करें.
[C-SR-6] एचडब्ल्यूयूआई के साथ SkiaVk का इस्तेमाल करने का सुझाव दिया जाता है.

अगर डिवाइस में Vulkan का इस्तेमाल किया जाता है, तो:

[C-SR-8] यह सुझाव दिया जाता है कि Vulkan लोडर में बदलाव न करें.
[C-1-14] "KHR", "GOOGLE" या "ANDROID" टाइप के Vulkan डिवाइस एक्सटेंशन की गिनती नहीं की जानी चाहिए. ऐसा तब तक नहीं किया जाना चाहिए, जब तक इन एक्सटेंशन को android.software.vulkan.deqp.level फ़ीचर फ़्लैग में शामिल न किया गया हो.

अगर डिवाइसों में Vulkan 1.0 के साथ काम करने की सुविधा शामिल नहीं है, तो:

[C-2-1] यह ज़रूरी है कि Vulkan के किसी भी फ़ीचर फ़्लैग (जैसे, android.hardware.vulkan.level, android.hardware.vulkan.version) का एलान न किया गया हो.
[C-2-2] Vulkan नेटिव एपीआई vkEnumeratePhysicalDevices() के लिए, किसी भी VkPhysicalDevice को शामिल नहीं किया जाना चाहिए.

अगर डिवाइस में Vulkan 1.1 का इस्तेमाल किया जाता है और यहां दिए गए या इसके बाद के वर्शन के Vulkan फ़ीचर फ़्लैग का एलान किया जाता है, तो:

[C-3-1] SYNC_FD बाहरी सेमाफ़ोर और हैंडल टाइप के साथ-साथ VK_ANDROID_external_memory_android_hardware_buffer एक्सटेंशन के लिए सहायता उपलब्ध कराना ज़रूरी है.
[C-SR-7] VK_KHR_external_fence_fd एक्सटेंशन को तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराने का सुझाव दिया जाता है. साथ ही, ऐप्लिकेशन को POSIX फ़ाइल डिस्क्रिप्टर से फ़ेंस पेलोड एक्सपोर्ट करने और फ़ेंस पेलोड इंपोर्ट करने की सुविधा चालू करने का सुझाव दिया जाता है. इसके बारे में यहां बताया गया है.

7.1.4.3. RenderScript

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-1] Android RenderScript के साथ काम करना ज़रूरी है. इसके बारे में Android SDK के दस्तावेज़ में बताया गया है.

7.1.4.4. 2D ग्राफ़िक्स ऐक्सेलरेशन

Android में, ऐप्लिकेशन के लिए एक ऐसा तरीका शामिल है जिससे वे यह एलान कर सकते हैं कि उन्हें ऐप्लिकेशन, गतिविधि, विंडो या व्यू लेवल पर 2D ग्राफ़िक के लिए हार्डवेयर ऐक्सेलरेट की सुविधा चालू करनी है. इसके लिए, उन्हें मेनिफ़ेस्ट टैग android:hardwareAccelerated या सीधे तौर पर एपीआई कॉल का इस्तेमाल करना होगा.

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-1] हार्डवेयर से तेज़ी लाने की सुविधा डिफ़ॉल्ट रूप से चालू होनी चाहिए. साथ ही, अगर डेवलपर android:hardwareAccelerated="false" सेट करके या Android View API के ज़रिए सीधे तौर पर हार्डवेयर से तेज़ी लाने की सुविधा को बंद करने का अनुरोध करता है, तो उसे बंद करना ज़रूरी है.
[C-0-2] हार्डवेयर से तेज़ी लाने की सुविधा के बारे में, Android SDK के दस्तावेज़ में बताए गए तरीके के मुताबिक काम करना ज़रूरी है.

Android में एक TextureView ऑब्जेक्ट शामिल होता है. इसकी मदद से डेवलपर, हार्डवेयर की मदद से तेज़ किए गए OpenGL ES टेक्सचर को सीधे तौर पर यूज़र इंटरफ़ेस (यूआई) के हाइरार्की में रेंडरिंग टारगेट के तौर पर इंटिग्रेट कर सकते हैं.

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-3] TextureView API के साथ काम करना ज़रूरी है. साथ ही, यह भी ज़रूरी है कि यह अपस्ट्रीम Android के साथ काम करने के तरीके के मुताबिक काम करे.

7.1.4.5. वाइड-गैमट डिसप्ले

अगर डिवाइस में सेट किए गए सिस्टम, Configuration.isScreenWideColorGamut() के ज़रिए वाइड-गैमट डिसप्ले के साथ काम करने का दावा करते हैं, तो:

[C-1-1] में कलर-कैलिब्रेटेड डिसप्ले होना ज़रूरी है.
[C-1-2] डिवाइस में ऐसा डिसप्ले होना चाहिए जिसका गैमट, CIE 1931 xyY स्पेस में sRGB कलर गैमट को पूरी तरह से कवर करता हो.
[C-1-3] इसमें ऐसा डिसप्ले होना चाहिए जिसका गैमट, CIE 1931 xyY स्पेस में DCI-P3 के कम से कम 90% हिस्से को कवर करता हो.
[C-1-4] OpenGL ES 3.1 या 3.2 को सपोर्ट करना चाहिए और इसकी जानकारी सही तरीके से देनी चाहिए.
[C-1-5] EGL_KHR_no_config_context, EGL_EXT_pixel_format_float, EGL_KHR_gl_colorspace, EGL_EXT_gl_colorspace_scrgb, EGL_EXT_gl_colorspace_scrgb_linear, EGL_EXT_gl_colorspace_display_p3, EGL_EXT_gl_colorspace_display_p3_linear, और EGL_EXT_gl_colorspace_display_p3_passthrough एक्सटेंशन के लिए सहायता उपलब्ध कराने का विज्ञापन देना ज़रूरी है.
[C-SR-1] GL_EXT_sRGB के साथ काम करने का सुझाव दिया जाता है.

इसके उलट, अगर डिवाइसों पर वाइड-गैमट डिसप्ले की सुविधा काम नहीं करती है, तो:

[C-2-1] CIE 1931 xyY स्पेस में sRGB के 100% या इससे ज़्यादा हिस्से को कवर करना चाहिए. हालांकि, स्क्रीन कलर गैमट तय नहीं किया गया है.

7.1.5. लेगसी ऐप्लिकेशन कंपैटबिलिटी मोड

Android में "कंपैटिबिलिटी मोड" होता है. इसमें फ़्रेमवर्क, "सामान्य" स्क्रीन साइज़ (320 डीपी चौड़ाई) मोड में काम करता है. इससे उन लेगसी ऐप्लिकेशन को फ़ायदा मिलता है जिन्हें Android के पुराने वर्शन के लिए डेवलप नहीं किया गया है. ये वर्शन, स्क्रीन साइज़ के हिसाब से काम करने की सुविधा से पहले के हैं.

7.1.6. स्क्रीन टेक्नोलॉजी

Android प्लैटफ़ॉर्म में ऐसे एपीआई शामिल होते हैं जिनकी मदद से ऐप्लिकेशन, Android के साथ काम करने वाले डिसप्ले पर बेहतर ग्राफ़िक रेंडर कर सकते हैं. डिवाइसों को Android SDK में बताए गए इन सभी एपीआई के साथ काम करना होगा. हालांकि, इस दस्तावेज़ में खास तौर पर अनुमति दी गई हो, तो ऐसा करने की ज़रूरत नहीं है.

डिवाइस में लागू किए गए Android के साथ काम करने वाले सभी डिसप्ले:

[C-0-1] ज़रूरी है कि 16-बिट कलर ग्राफ़िक रेंडर कर सके.
इसमें 24-बिट कलर ग्राफ़िक वाले डिसप्ले काम करने चाहिए.
[C-0-2] ऐनिमेशन रेंडर करने में सक्षम होना चाहिए.
[C-0-3] का पिक्सल आसपेक्ट रेशियो (पीएआर) 0.9 और 1.15 के बीच होना चाहिए. इसका मतलब है कि पिक्सल का आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) स्क्वेयर (1.0) के आस-पास होना चाहिए. इसमें 10 से 15% का अंतर हो सकता है.

7.1.7. दूसरे डिसप्ले

Android में, Android के साथ काम करने वाले सेकंडरी डिसप्ले के लिए सहायता शामिल है. इससे मीडिया शेयर करने की सुविधाओं और बाहरी डिसप्ले को ऐक्सेस करने के लिए डेवलपर एपीआई को चालू किया जा सकता है.

अगर डिवाइसों में, बाहरी डिसप्ले को वायर, वायरलेस या एम्बेड किए गए अतिरिक्त डिसप्ले कनेक्शन के ज़रिए कनेक्ट करने की सुविधा उपलब्ध है, तो:

[C-1-1] Android SDK के दस्तावेज़ में बताए गए तरीके के मुताबिक, DisplayManager सिस्टम सेवा और एपीआई को लागू करना ज़रूरी है.

7.2. इनपुट डिवाइस

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-1] यूज़र इंटरफ़ेस (यूआई) एलिमेंट के बीच नेविगेट करने के लिए, इनपुट मैकेनिज़्म शामिल करना ज़रूरी है. जैसे, टचस्क्रीन या बिना टच किए नेविगेट करने की सुविधा.

7.2.1. कीबोर्ड

अगर डिवाइस में तीसरे पक्ष के इनपुट के तरीके का संपादक (IME) ऐप्लिकेशन इस्तेमाल करने की सुविधा शामिल है, तो:

[C-1-1] android.software.input_methods फ़ीचर फ़्लैग के बारे में एलान करना ज़रूरी है.
[C-1-2] Input Management Framework को पूरी तरह से लागू करना ज़रूरी है
[C-1-3] में सॉफ़्टवेयर कीबोर्ड पहले से इंस्टॉल होना चाहिए.

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-1] इसमें ऐसा हार्डवेयर कीबोर्ड शामिल नहीं होना चाहिए जो android.content.res.Configuration.keyboard में बताए गए फ़ॉर्मैट (QWERTY या 12-की) में से किसी एक से मेल न खाता हो.
इसमें सॉफ़्ट कीबोर्ड के अतिरिक्त तरीके शामिल होने चाहिए.
इसमें हार्डवेयर कीबोर्ड शामिल हो सकता है.

7.2.2. बिना छुए नेविगेट करने की सुविधा

Android में, बिना छुए नेविगेट करने के लिए डी-पैड, ट्रैकबॉल, और व्हील का इस्तेमाल किया जा सकता है.

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-1] android.content.res.Configuration.navigation के लिए सही वैल्यू रिपोर्ट करना ज़रूरी है.

अगर डिवाइसों में बिना छुए नेविगेट करने की सुविधा नहीं है, तो:

[C-1-1] टेक्स्ट को चुनने और उसमें बदलाव करने के लिए, यूज़र इंटरफ़ेस का कोई ऐसा तरीका उपलब्ध कराना ज़रूरी है जो इनपुट मैनेजमेंट इंजन के साथ काम करता हो. Android के ओपन सोर्स वर्शन में, चुनने का एक ऐसा तरीका शामिल है जो उन डिवाइसों के साथ इस्तेमाल किया जा सकता है जिनमें नॉन-टच नेविगेशन इनपुट नहीं होते हैं.

7.2.3. मार्गदर्शक कुंजियां

होम, हाल ही के ऐप्लिकेशन, और वापस जाएं फ़ंक्शन आम तौर पर, किसी बटन या टच स्क्रीन के किसी हिस्से से इंटरैक्ट करके उपलब्ध कराए जाते हैं. ये Android के नेविगेशन पैराडाइम के लिए ज़रूरी हैं. इसलिए, डिवाइसों में इन्हें लागू करना ज़रूरी है:

[C-0-1] MUST provide a user affordance to launch installed applications that have an activity with the <intent-filter> set with ACTION=MAIN and CATEGORY=LAUNCHER or CATEGORY=LEANBACK_LAUNCHER for Television device implementations. उपयोगकर्ता को यह सुविधा देने के लिए, होम फ़ंक्शन का इस्तेमाल किया जाना चाहिए.
इसमें हाल ही के और पिछले फ़ंक्शन के लिए बटन होने चाहिए.

अगर होम, हाल ही के या वापस जाएँ फ़ंक्शन उपलब्ध कराए जाते हैं, तो:

[C-1-1] अगर इनमें से कोई भी सुविधा उपलब्ध है, तो उसे एक ही कार्रवाई (जैसे कि टैप करना, दो बार क्लिक करना या जेस्चर) से ऐक्सेस किया जा सकता हो.
[C-1-2] यह साफ़ तौर पर बताना ज़रूरी है कि कौनसी एक कार्रवाई से हर फ़ंक्शन ट्रिगर होगा. बटन पर दिखने वाला आइकॉन, स्क्रीन के नेविगेशन बार वाले हिस्से पर सॉफ़्टवेयर आइकॉन दिखाना या डिवाइस को पहली बार सेटअप करने के दौरान, उपयोगकर्ता को चरण-दर-चरण निर्देश वाला डेमो फ़्लो दिखाना, इस तरह के संकेत के उदाहरण हैं.

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-SR-1] हमारा सुझाव है कि मेन्यू फ़ंक्शन के लिए इनपुट मैकेनिज़्म उपलब्ध न कराएं, क्योंकि Android 4.0 से इसे ऐक्शन बार के पक्ष में बंद कर दिया गया है.
[C-SR-2] सभी नेविगेशन फ़ंक्शन को रद्द किए जा सकने वाले फ़ंक्शन के तौर पर उपलब्ध कराने का सुझाव दिया जाता है. 'रद्द किया जा सकता है' का मतलब है कि अगर स्वाइप को किसी तय थ्रेशोल्ड से आगे नहीं छोड़ा जाता है, तो उपयोगकर्ता नेविगेशन फ़ंक्शन को लागू होने से रोक सकता है. जैसे, होम स्क्रीन पर जाना, वापस जाना वगैरह.

अगर डिवाइसों में मेन्यू फ़ंक्शन उपलब्ध है, तो:

[C-2-1] जब ऐक्शन ओवरफ़्लो मेन्यू पॉप-अप खाली न हो और ऐक्शन बार दिख रहा हो, तब ऐक्शन ओवरफ़्लो बटन दिखाना ज़रूरी है.
[C-2-2] ऐक्शन बार में मौजूद ओवरफ़्लो बटन को चुनने पर दिखने वाले ऐक्शन ओवरफ़्लो पॉप-अप की जगह में बदलाव नहीं किया जाना चाहिए. हालांकि, मेन्यू फ़ंक्शन को चुनने पर दिखने वाले ऐक्शन ओवरफ़्लो पॉप-अप को स्क्रीन पर बदली गई जगह पर रेंडर किया जा सकता है.

अगर डिवाइसों पर मेन्यू फ़ंक्शन उपलब्ध नहीं है, तो पुराने वर्शन के साथ काम करने के लिए:

[C-3-1] जब targetSdkVersion की वैल्यू 10 से कम हो, तब ऐप्लिकेशन के लिए मेन्यू फ़ंक्शन उपलब्ध कराना ज़रूरी है. इसके लिए, फ़िज़िकल बटन, सॉफ़्टवेयर कुंजी या जेस्चर का इस्तेमाल किया जा सकता है. यह मेन्यू फ़ंक्शन तब तक ऐक्सेस किया जा सकता है, जब तक इसे अन्य नेविगेशन फ़ंक्शन के साथ न छिपाया गया हो.

अगर डिवाइस में सहायता फ़ंक्शन उपलब्ध है, तो:

[C-4-1] जब अन्य नेविगेशन कुंजियां ऐक्सेस की जा सकती हैं, तब एक ही ऐक्शन (जैसे, टैप करना, दो बार क्लिक करना या जेस्चर) से, सहायता फ़ंक्शन को ऐक्सेस किया जा सकता हो.
[C-SR-3] होम फ़ंक्शन पर लंबे समय तक दबाकर रखने की सुविधा का इस्तेमाल करने का सुझाव दिया जाता है.

अगर डिवाइसों में नेविगेशन कुंजियों को दिखाने के लिए, स्क्रीन के अलग हिस्से का इस्तेमाल किया जाता है, तो:

[C-5-1] नेविगेशन कुंजियों को स्क्रीन के अलग हिस्से में इस्तेमाल किया जाना चाहिए. यह हिस्सा ऐप्लिकेशन के लिए उपलब्ध नहीं होना चाहिए. साथ ही, यह हिस्सा ऐप्लिकेशन के लिए उपलब्ध स्क्रीन के हिस्से को न तो छिपाना चाहिए और न ही उसमें किसी तरह की रुकावट डालनी चाहिए.
[C-5-2] डिसप्ले का कुछ हिस्सा, उन ऐप्लिकेशन के लिए उपलब्ध कराना होगा जो सेक्शन 7.1.1 में बताई गई ज़रूरी शर्तें पूरी करते हैं.
[C-5-3] View.setSystemUiVisibility() एपीआई के तरीके से, ऐप्लिकेशन की ओर से सेट किए गए फ़्लैग का पालन करना ज़रूरी है, ताकि स्क्रीन के इस अलग हिस्से (नेविगेशन बार) को एसडीके में बताए गए तरीके से छिपाया जा सके.

[C-6-1] WindowInsets#getMandatorySystemGestureInsets() इसका इस्तेमाल सिर्फ़ होम जेस्चर की पहचान करने वाले एरिया की जानकारी देने के लिए किया जाना चाहिए.
[C-6-2] अगर कोई जेस्चर, फ़ोरग्राउंड ऐप्लिकेशन के दिए गए एक्सक्लूज़न रेक्ट (स्क्रीन का वह हिस्सा जहां जेस्चर काम नहीं करता) के अंदर से शुरू होता है, लेकिन WindowInsets#getMandatorySystemGestureInsets() के बाहर से शुरू होता है, तो उसे नेविगेशन फ़ंक्शन के लिए इंटरसेप्ट नहीं किया जाना चाहिए. ऐसा तब तक किया जाना चाहिए, जब तक एक्सक्लूज़न रेक्ट, View#setSystemGestureExclusionRects() के दस्तावेज़ में बताई गई एक्सक्लूज़न की ज़्यादा से ज़्यादा सीमा के अंदर हो.View#setSystemGestureExclusionRects()
[C-6-3] अगर फ़ोरग्राउंड ऐप्लिकेशन को पहले MotionEvent.ACTION_DOWN इवेंट भेजा गया था, तो सिस्टम के जेस्चर के लिए टच इंटरसेप्ट करना शुरू करने पर, फ़ोरग्राउंड ऐप्लिकेशन को MotionEvent.ACTION_CANCEL इवेंट भेजना ज़रूरी है.
[C-6-4] इसमें उपयोगकर्ताओं को स्क्रीन पर मौजूद बटन के ज़रिए नेविगेशन की सुविधा उपलब्ध होनी चाहिए. उदाहरण के लिए, सेटिंग में.
स्क्रीन के मौजूदा ओरिएंटेशन के हिसाब से, सबसे नीचे के किनारे से ऊपर की ओर स्वाइप करने पर, होम फ़ंक्शन चालू होना चाहिए.
उसे रिलीज़ से पहले, स्वाइप अप करके होल्ड करने पर, हाल ही में इस्तेमाल किए गए ऐप्लिकेशन दिखाने की सुविधा देनी चाहिए. यह सुविधा, होम जेस्चर वाली जगह से ही उपलब्ध होनी चाहिए.
WindowInsets#getMandatorySystemGestureInsets() से शुरू होने वाले जेस्चर पर, फ़ोरग्राउंड ऐप्लिकेशन के View#setSystemGestureExclusionRects() के ज़रिए दिए गए एक्सक्लूज़न रेक्ट का असर नहीं पड़ना चाहिए.

अगर स्क्रीन के मौजूदा ओरिएंटेशन के हिसाब से, बाएं और दाएं किनारों पर कहीं भी नेविगेशन फ़ंक्शन दिया गया है, तो:

[C-7-1] नेविगेशन फ़ंक्शन, 'वापस जाएं' वाला होना चाहिए. साथ ही, इसे स्क्रीन के मौजूदा ओरिएंटेशन के हिसाब से, बाएं और दाएं दोनों किनारों से स्वाइप करके ऐक्सेस किया जा सकता हो.
[C-7-2] अगर बाईं या दाईं ओर स्वाइप किए जा सकने वाले कस्टम सिस्टम पैनल दिए गए हैं, तो उन्हें स्क्रीन के ऊपरी एक-तिहाई हिस्से में रखना होगा. साथ ही, यह साफ़ तौर पर और लगातार दिखना चाहिए कि अंदर की ओर खींचने से ऊपर बताए गए पैनल खुलेंगे. इसलिए, 'वापस जाएं' बटन नहीं दिखेगा. उपयोगकर्ता, सिस्टम पैनल को इस तरह से कॉन्फ़िगर कर सकता है कि वह स्क्रीन के ऊपरी एक-तिहाई हिस्से के नीचे दिखे. हालांकि, सिस्टम पैनल को स्क्रीन के एक-तिहाई हिस्से से ज़्यादा जगह का इस्तेमाल नहीं करना चाहिए.
[C-7-3] जब फ़ोरग्राउंड ऐप्लिकेशन में View.SYSTEM_UI_FLAG_IMMERSIVE, View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT या WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE फ़्लैग सेट हों, तो किनारों से स्वाइप करने पर, AOSP में लागू किए गए तरीके से काम करना चाहिए. इसके बारे में एसडीके में बताया गया है.
[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 में लागू किया गया है.

अगर वापस जाने की सुविधा उपलब्ध है और उपयोगकर्ता, वापस जाने के लिए किए गए जेस्चर को रद्द करता है, तो:

[C-8-1] OnBackInvokedCallback.onBackCancelled() को कॉल करना ज़रूरी है.
[C-8-2] OnBackInvokedCallback.onBackInvoked() को कॉल नहीं किया जाना चाहिए.
[C-8-3] KEYCODE_BACK इवेंट को डिसपैच नहीं किया जाना चाहिए.

अगर वापस जाने की सुविधा उपलब्ध है, लेकिन फ़ोरग्राउंड ऐप्लिकेशन में OnBackInvokedCallback रजिस्टर नहीं है, तो:

सिस्टम को फ़ोरग्राउंड ऐप्लिकेशन के लिए एक ऐनिमेशन दिखाना चाहिए, जिससे यह पता चले कि उपयोगकर्ता वापस जा रहा है. यह ऐनिमेशन, AOSP में दिए गए ऐनिमेशन जैसा होना चाहिए.

अगर डिवाइस में सेट किए गए सिस्टम, सिस्टम एपीआई setNavBarMode के साथ काम करते हैं, ताकि android.permission.STATUS_BAR की अनुमति वाला कोई भी सिस्टम ऐप्लिकेशन, नेविगेशन बार मोड सेट कर सके, तो:

[C-9-1] 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] MUST support distinct tracking of 5 (tracking a hand of fingers) or more pointer inputs fully independently.

7.2.6. गेम कंट्रोलर की सुविधा

7.2.6.1. बटन मैपिंग

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-1-1] में, एचआईडी इवेंट को नीचे दी गई टेबल में दिए गए InputEvent कॉन्स्टेंट से मैप करने की सुविधा होनी चाहिए. अपस्ट्रीम Android के लागू होने से, यह ज़रूरी शर्त पूरी हो जाती है.

अगर डिवाइसों में कंट्रोलर एम्बेड किया गया है या उन्हें बॉक्स में अलग कंट्रोलर के साथ शिप किया जाता है, तो नीचे दी गई टेबल में दिए गए सभी इवेंट को इनपुट करने के लिए, उन्हें:

[C-2-1] android.hardware.gamepad फ़ीचर फ़्लैग के बारे में एलान करना ज़रूरी है

बटन	एचआईडी का इस्तेमाल²	Android बटन
A¹	0x09 0x0001	KEYCODE_BUTTON_A (96)
B¹	0x09 0x0002	KEYCODE_BUTTON_B (97)
X¹	0x09 0x0004	KEYCODE_BUTTON_X (99)
Y¹	0x09 0x0005	KEYCODE_BUTTON_Y (100)
डी-पैड में अप ऐरो वाला बटन¹ डी-पैड में डाउन ऐरो वाला बटन¹	0x01 0x0039³	AXIS_HAT_Y⁴
डी-पैड में लेफ़्ट ऐरो वाला बटन1 डी-पैड में राइट ऐरो वाला बटन¹	0x01 0x0039³	AXIS_HAT_X⁴
लेफ़्ट शोल्डर बटन¹	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
राइट शोल्डर बटन¹	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
लेफ़्ट स्टिक क्लिक करें¹	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
राइट स्टिक क्लिक करें¹	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
वापस जाएं¹	0x0c 0x0224	KEYCODE_BACK (4)

1 KeyEvent

2 ऊपर दिए गए एचआईडी इस्तेमाल, गेमपैड सीए (0x01 0x0005) में बताए जाने चाहिए.

3 इस इस्तेमाल में, लॉजिकल मिनिमम 0, लॉजिकल मैक्सिमम 7, फ़िज़िकल मिनिमम 0, फ़िज़िकल मैक्सिमम 315, यूनिट डिग्री में, और रिपोर्ट का साइज़ 4 होना चाहिए. लॉजिकल वैल्यू को वर्टिकल ऐक्सिस से क्लॉकवाइज़ रोटेशन के तौर पर तय किया जाता है. उदाहरण के लिए, लॉजिकल वैल्यू 0 का मतलब है कि कोई रोटेशन नहीं हुआ है और ऊपर वाले बटन को दबाया गया है. वहीं, लॉजिकल वैल्यू 1 का मतलब है कि 45 डिग्री का रोटेशन हुआ है और ऊपर और बाईं ओर के दोनों बटन दबाए गए हैं.

4 MotionEvent

ऐनलॉग कंट्रोल¹	एचआईडी का इस्तेमाल	Android बटन
लेफ़्ट ट्रिगर	0x02 0x00C5	AXIS_LTRIGGER
राइट ट्रिगर	0x02 0x00C4	AXIS_RTRIGGER
लेफ़्ट जॉयस्टिक	0x01 0x0030 0x01 0x0031	AXIS_X AXIS_Y
राइट जॉयस्टिक	0x01 0x0032 0x01 0x0035	AXIS_Z AXIS_RZ

1 MotionEvent

7.2.7. रिमोट कंट्रोल

डिवाइस से जुड़ी ज़रूरी शर्तों के लिए, सेक्शन 2.3.1 देखें.

7.3. सेंसर

अगर डिवाइस में किसी खास तरह का सेंसर शामिल है और तीसरे पक्ष के डेवलपर के लिए उससे जुड़ा एपीआई उपलब्ध है, तो डिवाइस में उस एपीआई को लागू करना ज़रूरी है. इसे Android SDK के दस्तावेज़ और सेंसर के बारे में Android Open Source के दस्तावेज़ में बताया गया है.

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-1] android.content.pm.PackageManager क्लास के हिसाब से, सेंसर के मौजूद होने या न होने की सटीक जानकारी देना ज़रूरी है.
[C-0-2] यह ज़रूरी है कि डिवाइस, SensorManager.getSensorList() और इसी तरह के अन्य तरीकों से, काम करने वाले सेंसर की सही सूची दिखाए.
[C-0-3] सभी अन्य सेंसर एपीआई के लिए, सही तरीके से काम करना चाहिए. उदाहरण के लिए, जब ऐप्लिकेशन लिसनर रजिस्टर करने की कोशिश करें, तब ज़रूरत के हिसाब से true या false वैल्यू दिखाना, सेंसर मौजूद न होने पर सेंसर लिसनर को कॉल न करना वगैरह.

अगर डिवाइस में किसी खास तरह का सेंसर शामिल है और तीसरे पक्ष के डेवलपर के लिए उससे जुड़ा एपीआई उपलब्ध है, तो:

[C-1-1] Android SDK के दस्तावेज़ में बताए गए हर सेंसर टाइप के लिए, इकाइयों की अंतरराष्ट्रीय प्रणाली (मेट्रिक) की वैल्यू का इस्तेमाल करके, सेंसर से जुड़ी सभी मेज़रमेंट रिपोर्ट करना ज़रूरी है.
[C-1-2] ऐप्लिकेशन प्रोसेसर के चालू होने पर, सेंसर स्ट्रीम के लिए सेंसर डेटा को 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] MUST report the event time in nanoseconds as defined in the Android SDK documentation, representing the time the event happened and synchronized with the SystemClock.elapsedRealtimeNano() clock.
[C-SR-1] टाइमस्टैंप सिंक करने से जुड़ी गड़बड़ी 100 मिलीसेकंड से कम होनी चाहिए. साथ ही, टाइमस्टैंप सिंक करने से जुड़ी गड़बड़ी 1 मिलीसेकंड से कम होनी चाहिए.
कई सेंसर चालू होने पर, बिजली की खपत, हर सेंसर की बताई गई बिजली की खपत के योग से ज़्यादा नहीं होनी चाहिए.

ऊपर दी गई सूची में सभी जानकारी शामिल नहीं है. Android SDK टूल और सेंसर के बारे में Android Open Source Documentations में दी गई जानकारी को आधिकारिक माना जाएगा.

[C-1-6] सभी सेंसर के लिए, शून्य से अलग रिज़ॉल्यूशन सेट करना ज़रूरी है. साथ ही, Sensor.getResolution() एपीआई तरीके से वैल्यू की जानकारी देना ज़रूरी है.

कुछ सेंसर कंपोज़िट होते हैं. इसका मतलब है कि उन्हें एक या एक से ज़्यादा अन्य सेंसर से मिले डेटा से बनाया जा सकता है. (उदाहरण के लिए, ओरिएंटेशन सेंसर और लीनियर ऐक्सलरेशन सेंसर.)

डिवाइस में सेट किए गए सिस्टम के लिए:

इन सेंसर टाइप को लागू करना चाहिए. हालांकि, ऐसा तब ही किया जाना चाहिए, जब इनमें सेंसर टाइप में बताए गए ज़रूरी फ़िज़िकल सेंसर शामिल हों.

अगर डिवाइस में कंपोज़िट सेंसर शामिल है, तो:

[C-2-1] सेंसर को Android Open Source के दस्तावेज़ में बताए गए तरीके से लागू करना ज़रूरी है. यह दस्तावेज़ कंपोज़िट सेंसर के बारे में है.

अगर डिवाइस में किसी खास तरह का सेंसर शामिल है और तीसरे पक्ष के डेवलपर के लिए उससे जुड़ा एपीआई उपलब्ध है. साथ ही, सेंसर सिर्फ़ एक वैल्यू रिपोर्ट करता है, तो डिवाइस में सेंसर को लागू करने के लिए:

[C-3-1] सेंसर के लिए रिज़ॉल्यूशन को 1 पर सेट करना और Sensor.getResolution() एपीआई के तरीके से वैल्यू की जानकारी देना ज़रूरी है.

अगर डिवाइस में किसी खास तरह का सेंसर शामिल है, जो SensorAdditionalInfo#TYPE_VEC3_CALIBRATION के साथ काम करता है और सेंसर को तीसरे पक्ष के डेवलपर के लिए उपलब्ध कराया जाता है, तो:

[C-4-1] दिए गए डेटा में, फ़ैक्ट्री में तय किए गए कैलिब्रेशन के पैरामीटर शामिल नहीं होने चाहिए.

अगर डिवाइस में 3-ऐक्सिस एक्सलरोमीटर, 3-ऐक्सिस जाइरोस्कोप सेंसर या मैग्नेटोमीटर सेंसर का कॉम्बिनेशन शामिल है, तो:

[C-SR-2] यह सुझाव दिया जाता है कि एक्सलरोमीटर, जाइरोस्कोप, और मैग्नेटोमीटर की रिलेटिव पोज़िशन तय हो.इससे यह पक्का किया जा सकेगा कि अगर डिवाइस को बदला जा सकता है (जैसे, फ़ोल्ड किया जा सकने वाला डिवाइस), तो सेंसर के ऐक्सिस अलाइन रहें. साथ ही, डिवाइस की सभी ट्रांसफ़ॉर्मेशन स्टेट में, सेंसर कोऑर्डिनेट सिस्टम के साथ अलाइन रहें.

7.3.1. एक्सलरोमीटर

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-SR-1] 3-ऐक्सिस एक्सलरोमीटर शामिल करने का सुझाव दिया जाता है.

अगर डिवाइस में एक्सलरोमीटर शामिल है, तो:

[C-1-1] कम से कम 50 हर्ट्ज़ की फ़्रीक्वेंसी तक इवेंट रिपोर्ट करने की सुविधा होनी चाहिए.
[C-1-3] Android API में दी गई जानकारी के मुताबिक, Android सेंसर कोऑर्डिनेट सिस्टम का पालन करना ज़रूरी है.
[C-1-4] किसी भी ऐक्सिस पर, gravity(4g) या इससे ज़्यादा के चार गुना तक फ़्रीफ़ॉल को मेज़र करने में सक्षम होना चाहिए.
[C-1-5] इसका रिज़ॉल्यूशन कम से कम 12 बिट का होना चाहिए.
[C-1-6] ज़रूरी है कि स्टैंडर्ड डेविएशन 0.05 मीटर/सेकंड^ से ज़्यादा न हो. स्टैंडर्ड डेविएशन की गिनती, हर ऐक्सिस के हिसाब से की जानी चाहिए. इसके लिए, सबसे तेज़ सैंपलिंग रेट पर कम से कम तीन सेकंड तक इकट्ठा किए गए सैंपल का इस्तेमाल किया जाना चाहिए.
कम से कम 200 हर्ट्ज़ तक के इवेंट रिपोर्ट करने चाहिए.
इसका रिज़ॉल्यूशन कम से कम 16-बिट होना चाहिए.
इस्तेमाल के दौरान इसे कैलिब्रेट किया जाना चाहिए. ऐसा तब करना चाहिए, जब डिवाइस के लाइफ़साइकल के दौरान इसकी विशेषताओं में बदलाव होता है और इसकी भरपाई की जाती है. साथ ही, डिवाइस को रीबूट करने के दौरान, भरपाई करने वाले पैरामीटर को सुरक्षित रखना चाहिए.
तापमान के हिसाब से सही होना चाहिए.

अगर डिवाइस में 3-ऐक्सिस एक्सलरोमीटर शामिल है, तो:

[C-2-1] TYPE_ACCELEROMETER सेंसर को लागू करना और उसके बारे में जानकारी देना ज़रूरी है.
[C-SR-4] TYPE_SIGNIFICANT_MOTION कंपोज़िट सेंसर को लागू करने का सुझाव दिया जाता है.
[C-SR-5] TYPE_ACCELEROMETER_UNCALIBRATED सेंसर को लागू करने और उसके बारे में जानकारी देने का सुझाव दिया जाता है. हमारा सुझाव है कि Android डिवाइसों पर इस ज़रूरी शर्त को पूरा किया जाए, ताकि वे आने वाले समय में रिलीज़ होने वाले प्लैटफ़ॉर्म पर अपग्रेड कर सकें. ऐसा हो सकता है कि आने वाले समय में, इस ज़रूरी शर्त को पूरा करना ज़रूरी हो जाए.
Android SDK के दस्तावेज़ में बताए गए कंपोज़िट सेंसर के तौर पर TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER को लागू करना चाहिए.

अगर डिवाइस में तीन ऐक्सिस से कम वाला एक्सलरोमीटर सेंसर शामिल है, तो:

[C-3-1] TYPE_ACCELEROMETER_LIMITED_AXES सेंसर को लागू करना और उसके बारे में जानकारी देना ज़रूरी है.
[C-SR-6] TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED सेंसर को लागू करने और उसके बारे में जानकारी देने का सुझाव दिया जाता है.

अगर डिवाइस में 3-ऐक्सिस एक्सलरोमीटर और TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER में से कोई एक कंपोज़िट सेंसर लागू किया गया है, तो:

[C-4-1] इनकी बिजली की खपत का कुल योग हमेशा 4 mW से कम होना चाहिए.
डिवाइस के स्थिर या गतिशील होने पर, दोनों की वैल्यू 2 mW और 0.5 mW से कम होनी चाहिए.

अगर डिवाइस में 3-ऐक्सिस एक्सलरोमीटर और 3-ऐक्सिस जाइरोस्कोप सेंसर शामिल हैं, तो:

[C-5-1] TYPE_GRAVITY और TYPE_LINEAR_ACCELERATION कंपोज़िट सेंसर का होना ज़रूरी है.
[C-SR-7] TYPE_GAME_ROTATION_VECTOR कंपोज़िट सेंसर का होना ज़रूरी है.

अगर डिवाइस में 3-ऐक्सिस एक्सलरोमीटर, 3-ऐक्सिस जाइरोस्कोप सेंसर, और मैग्नेटोमीटर सेंसर शामिल हैं, तो:

[C-6-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 mW से कम बिजली खर्च करनी चाहिए.

7.3.3. जीपीएस

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-SR-1] जीपीएस/जीएनएसएस रिसीवर शामिल करने का सुझाव दिया जाता है.

अगर डिवाइसों में जीपीएस/जीएनएसएस रिसीवर शामिल हैं और वे android.hardware.location.gps फ़ीचर फ़्लैग के ज़रिए, ऐप्लिकेशन को इस सुविधा के बारे में जानकारी देते हैं, तो:

[C-1-1] LocationManager#requestLocationUpdate के ज़रिए अनुरोध किए जाने पर, जगह की जानकारी के आउटपुट के साथ, कम से कम 1 हर्ट्ज़ की दर से काम करना चाहिए.
[C-1-2] 0.5 एमबीपीएस या इससे ज़्यादा डेटा स्पीड वाले इंटरनेट कनेक्शन से कनेक्ट होने पर, खुले आसमान वाली जगहों में 10 सेकंड के अंदर जगह की जानकारी का पता लगाना ज़रूरी है. इन जगहों पर, सिग्नल मज़बूत होने चाहिए, मल्टीपाथ न के बराबर होना चाहिए, और एचडीओपी < 2 होना चाहिए. आम तौर पर, इस ज़रूरत को पूरा करने के लिए, असिस्टेड या अनुमानित जीपीएस/जीएनएसएस तकनीक का इस्तेमाल किया जाता है. इससे जीपीएस/जीएनएसएस लॉक-ऑन टाइम को कम किया जा सकता है. सहायता डेटा में रेफ़रंस टाइम, रेफ़रंस लोकेशन, और सैटेलाइट एफ़ेमेरिस/क्लॉक शामिल होती है.
- [C-1-6] जगह की जानकारी का पता लगाने के बाद, डिवाइस को खुले आसमान वाली जगहों में पांच सेकंड के अंदर, जगह की जानकारी का पता लगाना ज़रूरी है. यह जानकारी, पिछली बार जगह की जानकारी मिलने के एक घंटे बाद तक की होगी. भले ही, यह अनुरोध डेटा कनेक्शन के बिना और/या डिवाइस बंद करके फिर चालू करने के बाद भेजा गया हो.
जगह की जानकारी का पता लगाने के बाद, खुले आसमान वाली जगहों में, जब वाहन रुका हुआ हो या उसका ऐक्सलरेशन एक मीटर प्रति सेकंड स्क्वेयर्ड से कम हो, तब:
- [C-1-3] कम से कम 95% समय में, 20 मीटर के दायरे तक जगह की जानकारी और 0.5 मीटर प्रति सेकंड की स्पीड का पता लगाना ज़रूरी है.
- [C-1-4] एक ही कॉन्स्टलेशन के कम से कम आठ सैटलाइट को एक साथ ट्रैक करना और GnssStatus.Callback के ज़रिए रिपोर्ट करना ज़रूरी है.
- अलग-अलग कॉन्स्टलेशन के कम से कम 24 सैटलाइट एक साथ ट्रैक करने चाहिए. जैसे, जीपीएस और Glonass, Beidou, Galileo में से कोई एक.
[C-SR-2] आपातकालीन कॉल के दौरान, GNSS लोकेशन प्रोवाइडर एपीआई के ज़रिए सामान्य जीपीएस/जीएनएसएस की जगह की जानकारी देने का सुझाव दिया जाता है.
[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] इनमें जाइरोस्कोप सेंसर शामिल करने का सुझाव दिया जाता है.

अगर डिवाइस में जाइरोस्कोप शामिल है, तो:

[C-1-1] कम से कम 50 हर्ट्ज़ की फ़्रीक्वेंसी तक इवेंट रिपोर्ट करने की सुविधा होनी चाहिए.
[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] इनका रिज़ॉल्यूशन 16 बिट या इससे ज़्यादा होना चाहिए.
कम से कम 200 हर्ट्ज़ तक के इवेंट रिपोर्ट करने चाहिए.

अगर डिवाइस में 3-ऐक्सिस जाइरोस्कोप शामिल है, तो:

[C-2-1] TYPE_GYROSCOPE सेंसर को लागू करना ज़रूरी है.
[C-SR-4] TYPE_GYROSCOPE_UNCALIBRATED सेंसर को लागू करने का सुझाव दिया जाता है.

अगर डिवाइस में तीन ऐक्सिस से कम का जाइरोस्कोप शामिल है, तो:

[C-3-1] TYPE_GYROSCOPE_LIMITED_AXES सेंसर को लागू करना और उसके बारे में जानकारी देना ज़रूरी है.
[C-SR-5] TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED सेंसर को लागू करने और उसके बारे में जानकारी देने का सुझाव दिया जाता है.

अगर डिवाइस में 3-ऐक्सिस जाइरोस्कोप, एक्सलरोमीटर सेंसर, और मैग्नेटोमीटर सेंसर शामिल हैं, तो:

[C-4-1] TYPE_ROTATION_VECTOR कंपोज़िट सेंसर का होना ज़रूरी है.

[C-5-1] TYPE_GRAVITY और TYPE_LINEAR_ACCELERATION कंपोज़िट सेंसर का होना ज़रूरी है.
[C-SR-6] 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 मीटर की ऐक्युरसी के बराबर है.

ऐसे डिवाइस जिनमें सिस्टम प्रॉपर्टी sensor.barometer.high_quality.implemented का इस्तेमाल किया जाता है:

[C-2-1] डिवाइस को 300 hPa से 1100 hPa के बीच के प्रेशर मेज़रमेंट की जानकारी देनी चाहिए. साथ ही, इसकी सटीक वैल्यू +/- 1 hPa होनी चाहिए.
[C-2-2] इसमें 100 hPa की रेंज में, 0.15 hPa की रिलेटिव एक्यूरेसी होनी चाहिए. यह समुद्र तल पर ~1000 मीटर के बदलाव पर ~1 मीटर की एक्यूरेसी के बराबर है.
[C-2-3] उपयोगकर्ता के डिवाइस को टैप, दबाने या निचोड़ने पर, बैरोमीटर में +/- 0.5 hPa का अंतर होना चाहिए.
[C-2-4] जब उपयोगकर्ता डिवाइस को हाथ में लेकर या जेब में रखकर चलता है, तब बैरोमीटर को +/- 0.15 hPa के अंदर स्थिर रहना चाहिए.
[C-2-5] 5 हर्ट्ज़ से ज़्यादा की फ़्रीक्वेंसी पर, इसे 300 मि॰से॰ से ज़्यादा के टाइम कॉन्स्टेंट के साथ स्मूथ नहीं किया जाना चाहिए. साथ ही, स्मूथिंग को सेंसर ऐक्टिवेशन के बीच में नहीं लीक होना चाहिए.
[C-2-6] रोज़ाना इस्तेमाल होने वाली रोशनी और ब्लूटूथ, मोबाइल कनेक्शन या वाई-फ़ाई जैसे सामान्य सोर्स से मिलने वाली रेडियो फ़्रीक्वेंसी के संपर्क में आने पर, यह +/- 0.15 hPa के अंदर स्थिर होना चाहिए.

7.3.6. Thermometer

अगर डिवाइस में परिवेश का तापमान मापने वाला थर्मामीटर (तापमान सेंसर) शामिल है, तो:

[C-1-1] ऐंबियंट टेंपरेचर सेंसर के लिए, SENSOR_TYPE_AMBIENT_TEMPERATURE को तय करना ज़रूरी है. साथ ही, सेंसर को उस जगह का ऐंबियंट (कमरे/वाहन का केबिन) तापमान मेज़र करना चाहिए जहां से उपयोगकर्ता डिवाइस के साथ इंटरैक्ट कर रहा है. यह तापमान डिग्री सेल्सियस में होना चाहिए.

अगर डिवाइस में ऐसे थर्मामीटर सेंसर शामिल हैं जो आस-पास के तापमान के अलावा, किसी और तापमान को मापते हैं, जैसे कि सीपीयू का तापमान, तो:

[C-2-1] तापमान मापने वाले सेंसर के लिए, SENSOR_TYPE_AMBIENT_TEMPERATURE को तय नहीं किया जाना चाहिए.

अगर डिवाइस में त्वचा का तापमान मापने के लिए सेंसर शामिल है, तो:

[C-SR-1] PowerManager.getThermalHeadroom API का इस्तेमाल करने का सुझाव दिया जाता है.

7.3.7. फ़ोटोमीटर

डिवाइस में फ़ोटोमीटर (स्क्रीन की रोशनी को अपने-आप घटाने-बढ़ाने वाला सेंसर) शामिल हो सकता है.

7.3.8. निकटता सेंसर

डिवाइस में प्रॉक्सिमिटी सेंसर शामिल हो सकता है.

अगर डिवाइसों में प्रॉक्सिमिटी सेंसर शामिल है और वे सिर्फ़ बाइनरी "पास" या "दूर" रीडिंग की जानकारी देते हैं, तो:

[C-1-1] स्क्रीन की दिशा में किसी ऑब्जेक्ट की दूरी को मेज़र करना ज़रूरी है. इसका मतलब है कि प्रॉक्सिमिटी सेंसर को इस तरह से ओरिएंट किया जाना चाहिए कि वह स्क्रीन के आस-पास मौजूद ऑब्जेक्ट का पता लगा सके. ऐसा इसलिए, क्योंकि इस तरह के सेंसर का मुख्य मकसद, उपयोगकर्ता के इस्तेमाल किए जा रहे फ़ोन का पता लगाना होता है. अगर डिवाइस में किसी अन्य ओरिएंटेशन वाला प्रॉक्सिमिटी सेंसर शामिल है, तो उसे इस एपीआई के ज़रिए ऐक्सेस नहीं किया जाना चाहिए.
[C-1-2] में एक बिट या इससे ज़्यादा की सटीक जानकारी होनी चाहिए.
[C-1-3] नज़दीकी रीडिंग के लिए 0 सेंटीमीटर और दूर की रीडिंग के लिए 5 सेंटीमीटर का इस्तेमाल करना ज़रूरी है.
[C-1-4] ज़्यादा से ज़्यादा रेंज और 5 के रिज़ॉल्यूशन की जानकारी देना ज़रूरी है.

7.3.9. हाई फ़िडेलिटी सेंसर

अगर डिवाइसों में, इस सेक्शन में बताए गए अच्छी क्वालिटी वाले सेंसर शामिल हैं और उन्हें तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराया जाता है, तो:

[C-1-1] android.hardware.sensor.hifi_sensors फ़ीचर फ़्लैग के ज़रिए, सुविधा की पहचान करना ज़रूरी है.

अगर डिवाइसों में android.hardware.sensor.hifi_sensors का एलान किया जाता है, तो:

[C-2-1] डिवाइस में TYPE_ACCELEROMETER सेंसर होना ज़रूरी है. साथ ही, यह सेंसर:
- इसमें कम से कम -8g और +8g के बीच मेज़रमेंट रेंज होनी चाहिए. साथ ही, इसमें कम से कम -16g और +16g के बीच मेज़रमेंट रेंज होना बेहद ज़रूरी है.
- इसका मेज़रमेंट रिज़ॉल्यूशन कम से कम 2048 एलएसबी/ग्राम होना चाहिए.
- मेज़रमेंट की फ़्रीक्वेंसी कम से कम 12.5 हर्ट्ज़ या इससे कम होनी चाहिए.
- मेज़रमेंट की फ़्रीक्वेंसी ज़्यादा से ज़्यादा 400 हर्ट्ज़ या इससे ज़्यादा होनी चाहिए; इसमें SensorDirectChannel RATE_VERY_FAST की सुविधा होनी चाहिए.
- मेज़रमेंट नॉइज़ 400 μg/√Hz से ज़्यादा नहीं होना चाहिए.
- इस सेंसर के नॉन-वेक-अप फ़ॉर्म को लागू करना ज़रूरी है. साथ ही, इसमें कम से कम 3,000 सेंसर इवेंट को बफ़र करने की सुविधा होनी चाहिए.
- बैटरी की खपत 3 mW से ज़्यादा नहीं होनी चाहिए.
- [C-SR-1] में, नाइक्विस्ट फ़्रीक्वेंसी के कम से कम 80% के 3 डीबी मेज़रमेंट बैंडविथ का इस्तेमाल करने का सुझाव दिया जाता है. साथ ही, इस बैंडविथ में व्हाइट नॉइज़ स्पेक्ट्रम का इस्तेमाल करने का सुझाव दिया जाता है.
- कमरे के तापमान पर जांच करने पर, ऐक्सलरेशन रैंडम वॉक 30 μg √Hz से कम होना चाहिए.
- तापमान के मुकाबले, इसमें ≤ +/- 1 मिलीग्राम/°C का बदलाव होना चाहिए.
- इसमें सबसे सही फ़िट होने वाली लाइन की नॉन-लीनियरिटी ≤ 0.5% होनी चाहिए. साथ ही, तापमान के हिसाब से संवेदनशीलता में बदलाव ≤ 0.03%/C° होना चाहिए.
- डिवाइस के ऑपरेटिंग तापमान की रेंज में, क्रॉस-ऐक्सिस की संवेदनशीलता 2.5 % से कम होनी चाहिए. साथ ही, क्रॉस-ऐक्सिस की संवेदनशीलता में बदलाव 0.2% से कम होना चाहिए.
[C-2-2] में TYPE_ACCELEROMETER_UNCALIBRATED होना चाहिए. इसकी क्वालिटी से जुड़ी ज़रूरी शर्तें, TYPE_ACCELEROMETER के जैसी ही होनी चाहिए.
[C-2-3] में TYPE_GYROSCOPE सेंसर होना ज़रूरी है. यह सेंसर:
- इसकी मेज़रमेंट रेंज कम से कम -1000 और +1000 dps के बीच होनी चाहिए.
- इसका मेज़रमेंट रिज़ॉल्यूशन कम से कम 16 एलएसबी/डीपीएस होना चाहिए.
- मेज़रमेंट की फ़्रीक्वेंसी कम से कम 12.5 हर्ट्ज़ या इससे कम होनी चाहिए.
- मेज़रमेंट की फ़्रीक्वेंसी ज़्यादा से ज़्यादा 400 हर्ट्ज़ या इससे ज़्यादा होनी चाहिए; इसमें SensorDirectChannel RATE_VERY_FAST की सुविधा होनी चाहिए.
- मेज़रमेंट नॉइज़ 0.014&°/s/√Hz से ज़्यादा नहीं होना चाहिए.
- [C-SR-2] में, नाइक्विस्ट फ़्रीक्वेंसी के कम से कम 80% के 3 डीबी मेज़रमेंट बैंडविड्थ और इस बैंडविड्थ के अंदर व्हाइट नॉइज़ स्पेक्ट्रम का होना ज़रूरी है.
- कमरे के तापमान पर जांच करने पर, रेट रैंडम वॉक 0.001&°/s √Hz से कम होना चाहिए.
- तापमान में ≤ +/- 0.05&°/ s / °C के मुकाबले, इसमें बायस में बदलाव होना चाहिए.
- तापमान में ≤ 0.02% / °C के हिसाब से बदलाव होने पर, सेंसिटिविटी में बदलाव होना चाहिए.
- इसमें सबसे सही फ़िट वाली लाइन की नॉन-लीनियरिटी ≤ 0.2% होनी चाहिए.
- इसमें नॉइज़ डेंसिटी ≤ 0.007&°/s/√Hz होनी चाहिए.
- डिवाइस के स्थिर होने पर, तापमान की सीमा 10 ~ 40 ℃ में कैलिब्रेशन की गड़बड़ी 0.002 रेडियन/सेकंड से कम होनी चाहिए.
- g-सेंसिटिविटी 0.1&°/s/g से कम होनी चाहिए.
- डिवाइस के ऑपरेटिंग तापमान की रेंज में, क्रॉस-ऐक्सिस की संवेदनशीलता 4.0 % से कम होनी चाहिए. साथ ही, क्रॉस-ऐक्सिस की संवेदनशीलता में बदलाव 0.3% से कम होना चाहिए.
[C-2-4] इसमें TYPE_GYROSCOPE की तरह ही क्वालिटी की ज़रूरी शर्तों को पूरा करने वाला TYPE_GYROSCOPE_UNCALIBRATED होना चाहिए.
[C-2-5] डिवाइस में TYPE_GEOMAGNETIC_FIELD सेंसर होना ज़रूरी है. साथ ही, यह ज़रूरी है कि:
- ज़रूरी है कि इसकी मेज़रमेंट रेंज, कम से कम -900 और +900 μT के बीच हो.
- इसका मेज़रमेंट रिज़ॉल्यूशन कम से कम 5 LSB/uT होना चाहिए.
- मेज़रमेंट की फ़्रीक्वेंसी कम से कम 5 हर्ट्ज़ या इससे कम होनी चाहिए.
- मेज़रमेंट की ज़्यादा से ज़्यादा फ़्रीक्वेंसी 50 हर्ट्ज़ या इससे ज़्यादा होनी चाहिए.
- इसमें मेज़रमेंट नॉइज़ 0.5 uT से ज़्यादा नहीं होना चाहिए.
[C-2-6] इसमें TYPE_MAGNETIC_FIELD_UNCALIBRATED एट्रिब्यूट की वैल्यू, TYPE_GEOMAGNETIC_FIELD एट्रिब्यूट की वैल्यू के बराबर होनी चाहिए. साथ ही:
- इस सेंसर के लिए, नॉन-वेक-अप फ़ॉर्म को लागू करना ज़रूरी है. साथ ही, इसमें कम से कम 600 सेंसर इवेंट को बफ़र करने की सुविधा होनी चाहिए.
- [C-SR-3] अगर रिपोर्ट करने की दर 50 हर्ट्ज़ या इससे ज़्यादा है, तो 1 हर्ट्ज़ से कम से कम 10 हर्ट्ज़ तक के फ़्रीक्वेंसी स्पेक्ट्रम में सफ़ेद नॉइज़ होना ज़रूरी है.
[C-2-7] TYPE_PRESSURE सेंसर का होना ज़रूरी है. साथ ही, यह भी ज़रूरी है कि:
- इसका मेज़रमेंट रेंज कम से कम 300 और 1100 hPa के बीच होनी चाहिए.
- इसका मेज़रमेंट रिज़ॉल्यूशन कम से कम 80 एलएसबी/एचपीए होना चाहिए.
- मेज़रमेंट की फ़्रीक्वेंसी कम से कम 1 हर्ट्ज़ या इससे कम होनी चाहिए.
- मेज़रमेंट की फ़्रीक्वेंसी ज़्यादा से ज़्यादा 10 हर्ट्ज़ या इससे ज़्यादा होनी चाहिए.
- मेज़रमेंट नॉइज़ 2 Pa/√Hz से ज़्यादा नहीं होना चाहिए.
- इस सेंसर के नॉन-वेक-अप फ़ॉर्म को लागू करना ज़रूरी है. साथ ही, इसमें कम से कम 300 सेंसर इवेंट को बफ़र करने की सुविधा होनी चाहिए.
- बैटरी की खपत 2 mW से ज़्यादा नहीं होनी चाहिए.
[C-2-8] डिवाइस में TYPE_GAME_ROTATION_VECTOR सेंसर का होना ज़रूरी है.
[C-2-9] डिवाइस में TYPE_SIGNIFICANT_MOTION सेंसर होना ज़रूरी है. यह सेंसर:
- जब डिवाइस स्थिर हो, तब बिजली की खपत 0.5 mW से ज़्यादा नहीं होनी चाहिए. वहीं, जब डिवाइस चल रहा हो, तब बिजली की खपत 1.5 mW से ज़्यादा नहीं होनी चाहिए.
[C-2-10] डिवाइस में TYPE_STEP_DETECTOR सेंसर होना ज़रूरी है. यह सेंसर:
- इस सेंसर के नॉन-वेक-अप फ़ॉर्म को लागू करना ज़रूरी है. साथ ही, इसमें कम से कम 100 सेंसर इवेंट को बफ़र करने की सुविधा होनी चाहिए.
- जब डिवाइस स्थिर हो, तब बिजली की खपत 0.5 mW से ज़्यादा नहीं होनी चाहिए. वहीं, जब डिवाइस चल रहा हो, तब बिजली की खपत 1.5 mW से ज़्यादा नहीं होनी चाहिए.
- बैटरी की खपत 4 mW से ज़्यादा नहीं होनी चाहिए.
[C-2-11] डिवाइस में TYPE_STEP_COUNTER सेंसर होना ज़रूरी है. यह सेंसर:
- जब डिवाइस स्थिर हो, तब बिजली की खपत 0.5 mW से ज़्यादा नहीं होनी चाहिए. वहीं, जब डिवाइस चल रहा हो, तब बिजली की खपत 1.5 mW से ज़्यादा नहीं होनी चाहिए.
[C-2-12] डिवाइस में TILT_DETECTOR सेंसर होना ज़रूरी है. साथ ही, यह भी ज़रूरी है कि:
- जब डिवाइस स्थिर हो, तब बिजली की खपत 0.5 mW से ज़्यादा नहीं होनी चाहिए. वहीं, जब डिवाइस चल रहा हो, तब बिजली की खपत 1.5 mW से ज़्यादा नहीं होनी चाहिए.
[C-2-13] ऐक्सिलरोमीटर, जायरोस्कोप, और मैग्नेटोमीटर से रिपोर्ट किए गए एक ही फ़िज़िकल इवेंट का इवेंट टाइमस्टैंप, एक-दूसरे से 2.5 मिलीसेकंड के अंदर होना चाहिए. ऐक्सिलरोमीटर और जायरोस्कोप से रिपोर्ट किए गए एक ही फ़िज़िकल इवेंट का टाइमस्टैंप, एक-दूसरे से 0.25 मिलीसेकंड के अंदर होना चाहिए.
[C-2-14] जाइरोस्कोप सेंसर इवेंट के टाइमस्टैंप, कैमरा सबसिस्टम के टाइमबेस के बराबर होने चाहिए. साथ ही, इनमें एक मिलीसेकंड से ज़्यादा का अंतर नहीं होना चाहिए.
[C-2-15] ऐप्लिकेशन को सैंपल, ऊपर दिए गए किसी भी फ़िज़िकल सेंसर पर डेटा उपलब्ध होने के पांच मिलीसेकंड के अंदर डिलीवर करने होंगे.
[C-2-16] जब डिवाइस स्थिर हो, तब इसकी पावर की खपत 0.5 mW से ज़्यादा नहीं होनी चाहिए. साथ ही, जब डिवाइस चल रहा हो, तब इसकी पावर की खपत 2.0 mW से ज़्यादा नहीं होनी चाहिए. ऐसा तब होना चाहिए, जब इनमें से किसी भी सेंसर को चालू किया गया हो:
- SENSOR_TYPE_SIGNIFICANT_MOTION
- SENSOR_TYPE_STEP_DETECTOR
- SENSOR_TYPE_STEP_COUNTER
- SENSOR_TILT_DETECTORS
[C-2-17] इसमें TYPE_PROXIMITY सेंसर हो सकता है. हालांकि, अगर यह मौजूद है, तो इसमें कम से कम 100 सेंसर इवेंट को बफ़र करने की सुविधा होनी चाहिए.

ध्यान दें कि इस सेक्शन में बिजली की खपत से जुड़ी सभी ज़रूरी शर्तों में, ऐप्लिकेशन प्रोसेसर की बिजली की खपत शामिल नहीं है. इसमें पूरी सेंसर चेन की पावर शामिल होती है. जैसे, सेंसर, उससे जुड़ी कोई सर्किट्री, सेंसर प्रोसेसिंग सिस्टम वगैरह.

अगर डिवाइस में सेंसर से सीधे तौर पर डेटा पाने की सुविधा शामिल है, तो:

[C-3-1] isDirectChannelTypeSupported और getHighestDirectReportRateLevel एपीआई के ज़रिए, डायरेक्ट चैनल टाइप और डायरेक्ट रिपोर्ट रेट लेवल के बारे में सही जानकारी देना ज़रूरी है.
[C-3-2] सेंसर डायरेक्ट चैनल की सुविधा के साथ काम करने वाले सभी सेंसर के लिए, कम से कम एक सेंसर डायरेक्ट चैनल टाइप के साथ काम करना ज़रूरी है.
- TYPE_HARDWARE_BUFFER
- TYPE_MEMORY_FILE
इन टाइप के प्राइमरी सेंसर (नॉन-वेकअप वैरिएंट) के लिए, सेंसर डायरेक्ट चैनल के ज़रिए इवेंट रिपोर्टिंग की सुविधा काम करनी चाहिए:
- TYPE_ACCELEROMETER
- TYPE_ACCELEROMETER_UNCALIBRATED
- TYPE_GYROSCOPE
- TYPE_GYROSCOPE_UNCALIBRATED
- TYPE_MAGNETIC_FIELD
- TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. बायोमेट्रिक सेंसर

बायोमेट्रिक अनलॉक की सुरक्षा को मेज़र करने के बारे में ज़्यादा जानकारी के लिए, कृपया बायोमेट्रिक सुरक्षा को मेज़र करने से जुड़ा दस्तावेज़ देखें.

अगर डिवाइस में सुरक्षित लॉक स्क्रीन की सुविधा शामिल है, तो:

बायोमेट्रिक सेंसर शामिल होना चाहिए

बायोमेट्रिक सेंसर को क्लास 3 (पहले मज़बूत) के तौर पर क्लासिफ़ाई किया जा सकता है.

क्लास 2 (पहले इसे कमज़ोर कहा जाता था) या क्लास 1 (पहले इसे सुविधाजनक कहा जाता था). यह रेटिंग, स्पूफ़िंग और धोखाधड़ी करने वाले लोगों के लिए, पहचान स्वीकार किए जाने की दर और बायोमेट्रिक पाइपलाइन की सुरक्षा के आधार पर दी जाती है. इस क्लासिफ़िकेशन से यह तय होता है कि बायोमेट्रिक सेंसर में, प्लैटफ़ॉर्म और तीसरे पक्ष के ऐप्लिकेशन के साथ इंटरफ़ेस करने की कौनसी सुविधाएं हैं. अगर सेंसर को क्लास 1, क्लास 2 या क्लास 3 के तौर पर कैटगरी में शामिल करना है, तो उन्हें यहां दी गई अन्य ज़रूरी शर्तें पूरी करनी होंगी. क्लास 2 और क्लास 3, दोनों तरह के बायोमेट्रिक को अतिरिक्त सुविधाएं मिलती हैं. इनके बारे में यहां बताया गया है.

अगर डिवाइस में बायोमेट्रिक सेंसर को तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराया जाता है, तो android.hardware.biometrics.BiometricManager, android.hardware.biometrics.BiometricPrompt, और android.provider.Settings.ACTION_BIOMETRIC_ENROLL के ज़रिए ऐसा किया जाता है. ऐसे में:

[C-4-1] इस दस्तावेज़ में बताई गई क्लास 3 या क्लास 2 बायोमेट्रिक की ज़रूरी शर्तों को पूरा करना ज़रूरी है.
[C-4-2] Authenticators क्लास में कॉन्स्टेंट के तौर पर तय किए गए हर पैरामीटर के नाम और उनके किसी भी कॉम्बिनेशन को पहचानना और उनका पालन करना ज़रूरी है. इसके उलट, canAuthenticate(int) और setAllowedAuthenticators(int) तरीकों को पास किए गए पूर्णांक स्थिरांकों को स्वीकार नहीं करना चाहिए या उन्हें पहचान नहीं देनी चाहिए. हालांकि, Authenticators में सार्वजनिक स्थिरांकों के तौर पर दस्तावेज़ में दिए गए पूर्णांक स्थिरांकों और उनके किसी भी कॉम्बिनेशन को स्वीकार किया जा सकता है.
[C-4-3] क्लास 3 या क्लास 2 बायोमेट्रिक सुविधा वाले डिवाइसों पर, ACTION_BIOMETRIC_ENROLL ऐक्शन लागू करना ज़रूरी है. इस कार्रवाई में, सिर्फ़ क्लास 3 या क्लास 2 के बायोमेट्रिक डेटा के लिए, रजिस्टर करने के एंट्री पॉइंट मौजूद होने चाहिए.
[C-4-4] ऐप्लिकेशन को, BiometricPrompt में कस्टम कॉन्टेंट जोड़ने की अनुमति देनी होगी. इसके लिए, PromptContentView के कॉन्टेंट डिसप्ले फ़ॉर्मैट का इस्तेमाल करना होगा. कॉन्टेंट दिखाने के फ़ॉर्मैट को इस तरह से नहीं बढ़ाया जाना चाहिए कि उसमें इमेज, लिंक, इंटरैक्टिव कॉन्टेंट या मीडिया के अन्य फ़ॉर्म शामिल किए जा सकें. ये फ़ॉर्म, BiometricPrompt API का हिस्सा नहीं हैं. स्टाइल से जुड़े ऐसे बदलाव किए जा सकते हैं जिनसे इस कॉन्टेंट में कोई बदलाव न हो, यह न छिपे या छोटा न हो. जैसे, पोज़िशन, पैडिंग, मार्जिन, और टाइपोग्राफ़ी बदलना.

अगर डिवाइस में सेट किए गए सिस्टम, पैसिव बायोमेट्रिक को सपोर्ट करते हैं, तो:

[C-5-1] डिफ़ॉल्ट रूप से, पुष्टि करने के लिए एक अतिरिक्त चरण ज़रूरी है. जैसे, बटन दबाना.
[C-SR-1] यह सुझाव दिया जाता है कि इनमें एक सेटिंग होनी चाहिए, ताकि लोग ऐप्लिकेशन की सेटिंग को बदल सकें. साथ ही, पुष्टि करने के लिए हमेशा एक अतिरिक्त चरण होना चाहिए.
[C-SR-2] यह सुझाव दिया जाता है कि पुष्टि करने की कार्रवाई को सुरक्षित बनाया जाए, ताकि ऑपरेटिंग सिस्टम या कर्नेल से समझौता करने वाला कोई व्यक्ति इसे स्पूफ़ न कर सके. उदाहरण के लिए, इसका मतलब है कि किसी फ़िज़िकल बटन के आधार पर पुष्टि करने की कार्रवाई को, सिर्फ़ इनपुट के लिए इस्तेमाल होने वाले सामान्य इनपुट/आउटपुट (जीपीआईओ) पिन के ज़रिए रूट किया जाता है. यह पिन, सुरक्षित एलिमेंट (एसई) का होता है. इसे फ़िज़िकल बटन दबाने के अलावा किसी और तरीके से नहीं चलाया जा सकता.
[C-5-2] setConfirmationRequired(boolean) के हिसाब से, पुष्टि करने के चरण के बिना, पुष्टि करने का एक इंप्लिसिट फ़्लो भी लागू करना होगा. ऐप्लिकेशन, साइन इन करने के फ़्लो के लिए इसका इस्तेमाल कर सकते हैं.

अगर डिवाइसों में एक से ज़्यादा बायोमेट्रिक सेंसर हैं, तो:

[C-7-1] अगर बायोमेट्रिक डेटा का इस्तेमाल करके पुष्टि करने की सुविधा लॉकआउट हो गई है (यानी कि जब तक उपयोगकर्ता पुष्टि करने के मुख्य तरीके का इस्तेमाल करके डिवाइस को अनलॉक नहीं करता, तब तक बायोमेट्रिक डेटा का इस्तेमाल करके पुष्टि करने की सुविधा बंद रहती है) या समयसीमा के हिसाब से लॉकआउट हो गई है (यानी कि जब तक उपयोगकर्ता कुछ समय तक इंतज़ार नहीं करता, तब तक बायोमेट्रिक डेटा का इस्तेमाल करके पुष्टि करने की सुविधा कुछ समय के लिए बंद रहती है), तो उसे बायोमेट्रिक डेटा का इस्तेमाल करके पुष्टि करने की कम क्लास वाली अन्य सभी सुविधाओं को भी लॉकआउट करना होगा. अगर कुछ समय के लिए लॉकआउट किया गया है, तो बायोमेट्रिक वेरिफ़िकेशन के लिए बैकऑफ़ का समय, कुछ समय के लिए लॉकआउट किए गए सभी बायोमेट्रिक के लिए बैकऑफ़ के ज़्यादा से ज़्यादा समय के बराबर होना चाहिए.
[C-SR-12] अगर बायोमेट्रिक लॉकआउट में है (यानी कि जब तक उपयोगकर्ता मुख्य पुष्टि करने की सुविधा का इस्तेमाल करके अनलॉक नहीं करता, तब तक बायोमेट्रिक बंद रहती है) या समयसीमा के हिसाब से लॉकआउट में है (यानी कि जब तक उपयोगकर्ता तय समय तक इंतज़ार नहीं करता, तब तक बायोमेट्रिक कुछ समय के लिए बंद रहती है), तो यह सुझाव दिया जाता है कि एक ही बायोमेट्रिक क्लास के सभी बायोमेट्रिक को भी लॉकआउट कर दिया जाए. ऐसा इसलिए, क्योंकि कई बार गलत बायोमेट्रिक का इस्तेमाल किया गया है. अगर कुछ समय के लिए लॉकआउट की सुविधा चालू है, तो बायोमेट्रिक वेरिफ़िकेशन के लिए बैकऑफ़ का समय, कुछ समय के लिए लॉकआउट की सुविधा में इस्तेमाल होने वाले सभी बायोमेट्रिक के लिए बैकऑफ़ के ज़्यादा से ज़्यादा समय के बराबर होना चाहिए.
[C-7-2] बायोमेट्रिक लॉक होने पर, लॉकआउट काउंटर को रीसेट करने के लिए, उपयोगकर्ता को सुझाए गए मुख्य पुष्टि करने के तरीके (जैसे, पिन, पैटर्न या पासवर्ड) का इस्तेमाल करके पुष्टि करनी होगी. क्लास 3 वाले बायोमेट्रिक डेटा का इस्तेमाल करके, उसी या उससे कम क्लास वाले लॉक किए गए बायोमेट्रिक डेटा के लॉकआउट काउंटर को रीसेट किया जा सकता है. क्लास 2 या क्लास 1 वाले बायोमेट्रिक डेटा का इस्तेमाल करके, किसी भी बायोमेट्रिक डेटा के लिए रीसेट लॉकआउट की कार्रवाई पूरी करने की अनुमति नहीं दी जानी चाहिए.
[C-SR-3] यह सुझाव दिया जाता है कि पुष्टि के लिए सिर्फ़ एक बायोमेट्रिक की ज़रूरत हो. उदाहरण के लिए, अगर डिवाइस पर फ़िंगरप्रिंट और फ़ेस सेंसर, दोनों उपलब्ध हैं, तो onAuthenticationSucceeded को तब भेजा जाना चाहिए, जब इनमें से किसी एक की पुष्टि हो जाए.

डिवाइस में सेट किए गए सिस्टम को तीसरे पक्ष के ऐप्लिकेशन को कीस्टोर कुंजियों का ऐक्सेस देने के लिए, यह ज़रूरी है कि:

[C-6-1] इस सेक्शन में बताई गई, क्लास 3 के लिए ज़रूरी शर्तों को पूरा करना ज़रूरी है.
[C-6-2] जब पुष्टि करने के लिए BIOMETRIC_STRONG की ज़रूरत हो या पुष्टि करने की प्रोसेस को CryptoObject के साथ शुरू किया गया हो, तब सिर्फ़ क्लास 3 बायोमेट्रिक्स का इस्तेमाल करना ज़रूरी है.

अगर डिवाइस में सेट किए गए सिस्टम, बायोमेट्रिक सेंसर को क्लास 1 (पहले इसे सुविधा कहा जाता था) के तौर पर इस्तेमाल करना चाहते हैं, तो उन्हें:

[C-1-1] ज़रूरी है कि फ़ॉल्स ऐक्सेप्टेंस रेट 0.002% से कम हो.
[C-1-2] अगर Android Biometrics Test Protocols के मुताबिक, स्पूफ़िंग और धोखाधड़ी से पुष्टि होने की दर 7% से ज़्यादा है, तो यह बताना ज़रूरी है कि यह मोड, किसी मुश्किल पिन, पैटर्न या पासवर्ड के मुकाबले कम सुरक्षित हो सकता है. साथ ही, इसे चालू करने से जुड़े जोखिमों के बारे में साफ़ तौर पर बताना ज़रूरी है.
[C-1-9] बीस बार गलत तरीके से पुष्टि करने की कोशिश करने के बाद, उपयोगकर्ता को पुष्टि करने के सुझाए गए मुख्य तरीके (जैसे, पिन, पैटर्न, पासवर्ड) का इस्तेमाल करने के लिए कहना होगा.साथ ही, बायोमेट्रिक की पुष्टि करने के लिए, कम से कम नब्बे सेकंड का बैकऑफ़ टाइम देना होगा. यहां गलत तरीके से पुष्टि करने की कोशिश का मतलब, ऐसी कोशिश से है जिसमें बायोमेट्रिक की क्वालिटी अच्छी हो (BIOMETRIC_ACQUIRED_GOOD), लेकिन वह रजिस्टर किए गए बायोमेट्रिक से मेल न खाती हो.
[C-SR-4] अगर Android Biometrics Test Protocols के मुताबिक, स्पूफ़िंग और धोखेबाज़ के तौर पर पुष्टि होने की दर 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-11] ज़रूरी है कि स्पूफ़िंग और धोखेबाज़ी से पुष्टि होने की दर 30% से ज़्यादा न हो. साथ ही, (1) लेवल A के प्रज़ेंटेशन अटैक इंस्ट्रूमेंट (पीएआई) के लिए, स्पूफ़िंग और धोखेबाज़ी से पुष्टि होने की दर 30% से ज़्यादा न हो. इसके अलावा, (2) लेवल B के पीएआई के लिए, स्पूफ़िंग और धोखेबाज़ी से पुष्टि होने की दर 40% से ज़्यादा न हो. यह दर, Android Biometrics Test Protocols के हिसाब से तय की जाती है.
[C-1-4] नई बायोमेट्रिक जानकारी जोड़ने से पहले, भरोसे की एक चेन बनाना ज़रूरी है. इसके लिए, उपयोगकर्ता को मौजूदा डिवाइस क्रेडेंशियल (पिन/पैटर्न/पासवर्ड) की पुष्टि करनी होगी या टीईई से सुरक्षित नया डिवाइस क्रेडेंशियल जोड़ना होगा. Android Open Source Project के लागू करने से, फ़्रेमवर्क में ऐसा करने का तरीका मिलता है.
[C-1-5] जब उपयोगकर्ता का खाता हटा दिया जाता है (फ़ैक्ट्री रीसेट करके भी हटाया जा सकता है) या जब पुष्टि करने का सुझाया गया मुख्य तरीका (जैसे, पिन, पैटर्न, पासवर्ड) हटा दिया जाता है, तो डिवाइस को उपयोगकर्ता के ऐसे सभी बायोमेट्रिक डेटा को पूरी तरह से हटाना होगा जिससे उसकी पहचान की जा सकती है.
[C-1-6] उस बायोमेट्रिक के लिए, फ़्लैग किए गए विकल्प का पालन करना ज़रूरी है. जैसे, DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE या DevicePolicymanager.KEYGUARD_DISABLE_IRIS.
[C-1-7] हर 24 घंटे या उससे कम समय में, उपयोगकर्ता को पुष्टि करने के लिए सुझाए गए मुख्य तरीके (जैसे, पिन, पैटर्न, पासवर्ड) का इस्तेमाल करने के लिए कहना ज़रूरी है.
[C-1-8] इनमें से कोई भी कार्रवाई होने के बाद, उपयोगकर्ता को सुझाए गए मुख्य पुष्टि करने के तरीके (जैसे कि पिन, पैटर्न, पासवर्ड) या क्लास 3 (मज़बूत) बायोमेट्रिक का इस्तेमाल करने के लिए कहना ज़रूरी है:
- चार घंटे तक कोई गतिविधि न होने पर, सेशन अपने-आप बंद हो जाता है.
- बायोमेट्रिक ऑथेंटिकेशन की पुष्टि करने के लिए तीन बार कोशिश की गई, लेकिन पुष्टि नहीं हो सकी.
- डिवाइस के क्रेडेंशियल की पुष्टि हो जाने के बाद, निष्क्रियता की समयसीमा और पुष्टि न होने की संख्या रीसेट हो जाती है.
[C-SR-7] नए डिवाइसों के लिए, Android Open Source Project की ओर से उपलब्ध कराए गए फ़्रेमवर्क में मौजूद लॉजिक का इस्तेमाल करने का सुझाव दिया जाता है. इससे, [C-1-7] और [C-1-8] में बताई गई पाबंदियों को लागू किया जा सकेगा.
[C-SR-8] यह सुझाव दिया जाता है कि डिवाइस पर मेज़र किए गए फ़िंगरप्रिंट के लिए, अस्वीकार किए गए फ़िंगरप्रिंट का अनुपात 10% से कम होना चाहिए.
[C-SR-9] यह सुझाव दिया जाता है कि बायोमेट्रिक का पता चलने से लेकर स्क्रीन अनलॉक होने तक, हर बायोमेट्रिक के लिए एक सेकंड से कम समय लगना चाहिए.
[C-1-12] Android Biometrics Test Protocols के मुताबिक, हर तरह के प्रेजेंटेशन अटैक इंस्ट्रूमेंट (पीएआई) के लिए, स्पूफ़िंग और धोखेबाज़ों के लिए स्वीकार्यता दर 40% से ज़्यादा नहीं होनी चाहिए.
[C-SR-13] हर तरह के प्रज़ेंटेशन अटैक इंस्ट्रूमेंट (पीएआई) के लिए, स्पूफ़ और धोखेबाज़ के तौर पर स्वीकार किए जाने की दर 30% से ज़्यादा नहीं होनी चाहिए. यह दर, Android Biometrics Test Protocols के हिसाब से तय की जाती है.
[C-SR-8] यह सुझाव दिया जाता है कि डिवाइस पर मेज़र किए गए फ़िंगरप्रिंट के लिए, अस्वीकार किए गए फ़िंगरप्रिंट का अनुपात 10% से कम होना चाहिए.
[C-1-15] उपयोगकर्ताओं को एक या एक से ज़्यादा बायोमेट्रिक डेटा हटाने की अनुमति देनी होगी.
[C-SR-14] बायोमेट्रिक सेंसर की बायोमेट्रिक क्लास और उसे चालू करने से जुड़े जोखिमों के बारे में जानकारी देने का सुझाव दिया जाता है.
[C-SR-17] नए एआईडीएल इंटरफ़ेस (जैसे, IFace.aidl और IFingerprint.aidl) लागू करने का सुझाव दिया जाता है.

अगर डिवाइस में सेट किए गए सिस्टम, बायोमेट्रिक सेंसर को क्लास 2 (पहले कमज़ोर) के तौर पर इस्तेमाल करना चाहते हैं, तो उन्हें:

[C-2-1] को ऊपर बताई गई क्लास 1 की सभी ज़रूरी शर्तों को पूरा करना होगा.
[C-2-2] यह ज़रूरी है कि स्पूफ़िंग और धोखेबाज़ के तौर पर स्वीकार किए जाने की दर 20% से ज़्यादा न हो. साथ ही, (1) लेवल A के प्रज़ेंटेशन अटैक इंस्ट्रूमेंट (पीएआई) के लिए, स्पूफ़िंग और धोखेबाज़ के तौर पर स्वीकार किए जाने की दर 20% से ज़्यादा न हो और (2) लेवल B के पीएआई के लिए, स्पूफ़िंग और धोखेबाज़ के तौर पर स्वीकार किए जाने की दर 30% से ज़्यादा न हो. यह दर, Android Biometrics Test Protocols के हिसाब से तय की जाती है.
[C-SR-15] Android Biometrics Test Protocols के मुताबिक, हर तरह के प्रेजेंटेशन अटैक इंस्ट्रूमेंट (पीएआई) के लिए, स्पूफ़िंग और धोखेबाज़ों के लिए स्वीकार्यता दर 20% से ज़्यादा नहीं होनी चाहिए.
[C-2-3] बायोमेट्रिक मैचिंग को, Android उपयोगकर्ता या कर्नेल स्पेस से बाहर, अलग एक्ज़ीक्यूशन एनवायरमेंट में करना ज़रूरी है. जैसे, ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट (टीईई). यह काम, अलग एक्ज़ीक्यूशन एनवायरमेंट के साथ सुरक्षित चैनल वाले चिप पर या प्रोटेक्टेड वर्चुअल मशीन पर किया जाना चाहिए. प्रोटेक्टेड वर्चुअल मशीन, सेक्शन 9.17 में दी गई ज़रूरी शर्तों को पूरा करती हो.
[C-2-4] ऐसे सभी डेटा को एन्क्रिप्ट (सुरक्षित) किया जाना चाहिए जिससे पहचान ज़ाहिर होती हो. साथ ही, उसे क्रिप्टोग्राफ़िक तरीके से प्रमाणित किया जाना चाहिए, ताकि उसे अलग किए गए एक्ज़ीक्यूशन एनवायरमेंट या अलग किए गए एक्ज़ीक्यूशन एनवायरमेंट के साथ सुरक्षित चैनल वाले चिप के बाहर से न तो हासिल किया जा सके, न ही पढ़ा जा सके या न ही बदला जा सके. इसकी जानकारी, Android Open Source Project की साइट पर मौजूद लागू करने के दिशा-निर्देशों में दी गई है. इसके अलावा, हाइपरवाइज़र से कंट्रोल की जाने वाली सुरक्षित वर्चुअल मशीन के लिए, सेक्शन 9.17 में दी गई ज़रूरी शर्तों को पूरा करना ज़रूरी है.
[C-2-5] कैमरे पर आधारित बायोमेट्रिक डेटा के लिए, बायोमेट्रिक डेटा पर आधारित पुष्टि या रजिस्ट्रेशन के दौरान:
- कैमरे को ऐसे मोड में चलाना होगा जिससे कैमरे के फ़्रेम को आइसोलेटेड एक्ज़ीक्यूशन एनवायरमेंट के बाहर न तो पढ़ा जा सके और न ही बदला जा सके. इसके अलावा, कैमरे को ऐसे चिप में चलाना होगा जिसमें आइसोलेटेड एक्ज़ीक्यूशन एनवायरमेंट के लिए सुरक्षित चैनल हो या उसे हाइपरवाइज़र से कंट्रोल की जाने वाली सुरक्षित वर्चुअल मशीन में चलाना होगा. साथ ही, उसे सेक्शन 9.17 में दी गई ज़रूरी शर्तों को पूरा करना होगा.
- आरजीबी सिंगल-कैमरा सलूशन के लिए, कैमरा फ़्रेम को अलग किए गए एक्ज़ीक्यूशन एनवायरमेंट के बाहर पढ़ा जा सकता है. इससे, रजिस्ट्रेशन के लिए झलक जैसी कार्रवाइयों में मदद मिलती है. हालांकि, इनमें बदलाव नहीं किया जा सकता.
[C-2-6] तीसरे पक्ष के ऐप्लिकेशन को, अलग-अलग बायोमेट्रिक रजिस्ट्रेशन के बीच अंतर करने की अनुमति नहीं देनी चाहिए.
[C-2-7] पहचान किए जा सकने वाले बायोमेट्रिक डेटा या उससे मिले किसी भी डेटा (जैसे, एम्बेडिंग) को, टीईई या हाइपरवाइज़र के कंट्रोल वाली सुरक्षित वर्चुअल मशीन के बाहर, ऐप्लिकेशन प्रोसेसर को बिना एन्क्रिप्ट (सुरक्षित) किए ऐक्सेस करने की अनुमति नहीं देनी चाहिए. हाइपरवाइज़र को सेक्शन 9.17 में दी गई ज़रूरी शर्तों को पूरा करना चाहिए. Android 9 या इससे पहले के वर्शन पर लॉन्च किए गए डिवाइसों को अपग्रेड करने पर, [C-2-7] से छूट नहीं मिलती.
[C-2-8] इसमें सुरक्षित प्रोसेसिंग पाइपलाइन होनी चाहिए, ताकि ऑपरेटिंग सिस्टम या कर्नल के साथ समझौता करने से, डेटा को सीधे तौर पर उपयोगकर्ता के तौर पर गलत तरीके से पुष्टि करने के लिए इंजेक्ट न किया जा सके.

ध्यान दें: अगर डिवाइसों पर Android 9 या इससे पहले का वर्शन पहले से ही लॉन्च किया जा चुका है और सिस्टम सॉफ़्टवेयर अपडेट के ज़रिए, [C-2-8] की ज़रूरी शर्तें पूरी नहीं की जा सकती हैं, तो हो सकता है कि उन्हें ज़रूरी शर्तों से छूट मिल जाए.
[C-SR-10] सभी बायोमेट्रिक मोड के लिए, लाइवनेस डिटेक्शन और चेहरे के बायोमेट्रिक्स के लिए, ध्यान का पता लगाने की सुविधा शामिल करने का सुझाव दिया जाता है.
[C-2-9] तीसरे पक्ष के ऐप्लिकेशन के लिए, बायोमेट्रिक सेंसर उपलब्ध कराना ज़रूरी है.

अगर डिवाइस में सेट किए गए सिस्टम, बायोमेट्रिक सेंसर को क्लास 3 (पहले मज़बूत) के तौर पर इस्तेमाल करना चाहते हैं, तो उन्हें:

[C-3-1] को ऊपर दी गई क्लास 2 की सभी ज़रूरी शर्तों को पूरा करना होगा. हालांकि, [C-1-7] और [C-1-8] को छोड़कर.
[C-3-2] इसमें हार्डवेयर के समर्थन वाला कीस्टोर लागू होना चाहिए.
[C-3-3] स्पूफ़िंग और धोखेबाज़ी के मामलों में, पुष्टि होने की दर 7% से ज़्यादा नहीं होनी चाहिए. साथ ही, (1) लेवल A के प्रेजेंटेशन अटैक इंस्ट्रूमेंट (पीएआई) के लिए, स्पूफ़िंग और धोखेबाज़ी के मामलों में पुष्टि होने की दर 7% से ज़्यादा नहीं होनी चाहिए. इसके अलावा, (2) लेवल B के पीएआई के लिए, स्पूफ़िंग और धोखेबाज़ी के मामलों में पुष्टि होने की दर 20% से ज़्यादा नहीं होनी चाहिए. यह दर, Android Biometrics Test Protocols के हिसाब से तय की जाती है.
[C-3-4] उपयोगकर्ता को हर 72 घंटे या उससे कम समय में, पुष्टि करने के लिए सुझाए गए मुख्य तरीके (जैसे कि पिन, पैटर्न, पासवर्ड) का इस्तेमाल करने के लिए कहना ज़रूरी है.
[C-3-5] अगर डिवाइस पर क्लास 3 के बायोमेट्रिक सिस्टम में से किसी एक को फिर से रजिस्टर किया जाता है, तो डिवाइस पर काम करने वाले सभी क्लास 3 बायोमेट्रिक सिस्टम के लिए, पुष्टि करने वाले का आईडी फिर से जनरेट करना ज़रूरी है.
[C-3-6] तीसरे पक्ष के ऐप्लिकेशन के लिए, बायोमेट्रिक डेटा की मदद से सुरक्षित की गई कीस्टोर कुंजियां चालू करनी होंगी.
[C-SR-16] यह सुझाव दिया जाता है कि स्पूफ़िंग और धोखाधड़ी करने वाले व्यक्ति की पहचान स्वीकार करने की दर, Android Biometrics Test Protocols के मुताबिक, हर तरह के प्रेजेंटेशन अटैक इंस्ट्रूमेंट (पीएआई) के लिए 7% से ज़्यादा न हो.

अगर डिवाइस में डिसप्ले में मौजूद फ़िंगरप्रिंट सेंसर (यूडीएफ़पीएस) शामिल है, तो:

[C-SR-11] में यह सुझाव दिया गया है कि यूडीएफ़पीएस के टच किए जा सकने वाले हिस्से को तीन बटन वाले नेविगेशन में रुकावट डालने से रोकने के लिए, यह ज़रूरी है कि यूडीएफ़पीएस के टच किए जा सकने वाले हिस्से को तीन बटन वाले नेविगेशन के साथ ओवरलैप न किया जाए. कुछ उपयोगकर्ताओं को ऐक्सेसिबिलिटी के लिए इसकी ज़रूरत पड़ सकती है.

7.3.11. पोज़ सेंसर

डिवाइस में सेट किए गए सिस्टम के लिए:

इसमें 6 डिग्री ऑफ़ फ़्रीडम वाले पोज़ सेंसर की सुविधा हो सकती है.

अगर डिवाइस में 6 डिग्री ऑफ़ फ़्रीडम के साथ पोज़ सेंसर काम करता है, तो:

[C-1-1] TYPE_POSE_6DOF सेंसर को लागू करना और उसके बारे में जानकारी देना ज़रूरी है.
[C-1-2] को सिर्फ़ रोटेशन वेक्टर से ज़्यादा सटीक होना चाहिए.

7.3.12. हिंज ऐंगल सेंसर

अगर डिवाइस में हिंज एंगल सेंसर काम करता है, तो:

[C-1-1] TYPE_HINGE_ANGLE को लागू करना और उसके बारे में जानकारी देना ज़रूरी है.
[C-1-2] 0 से 360 डिग्री के बीच कम से कम दो रीडिंग के साथ काम करना ज़रूरी है. इसमें 0 और 360 डिग्री शामिल हैं.
[C-1-3] getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE) के लिए, wakeup सेंसर की जानकारी देना ज़रूरी है.

7.3.13. आईईईई 802.1.15.4 (यूडब्ल्यूबी)

अगर डिवाइस में 802.1.15.4 के साथ काम करने की सुविधा शामिल है और तीसरे पक्ष के ऐप्लिकेशन के लिए यह सुविधा उपलब्ध है, तो:

[C-1-2] हार्डवेयर फ़ीचर फ़्लैग android.hardware.uwb की जानकारी देना ज़रूरी है.
[C-1-3] AOSP में लागू किए गए, यहां दिए गए सभी कॉन्फ़िगरेशन सेट (FIRA UCI पैरामीटर के पहले से तय किए गए कॉम्बिनेशन) के साथ काम करना ज़रूरी है.
- CONFIG_ID_1: FiRa के हिसाब से यूनीकास्ट STATIC STS DS-TWR रेंजिंग, डिफ़र्ड मोड, रेंजिंग इंटरवल 240 मि॰से॰.
- CONFIG_ID_2: FiRa के हिसाब से, एक से ज़्यादा डिवाइसों के साथ STATIC STS DS-TWR रेंजिंग, डिफ़र्ड मोड, रेंजिंग इंटरवल 200 मि॰से॰. इस्तेमाल का सामान्य उदाहरण: स्मार्ट फ़ोन कई स्मार्ट डिवाइसों के साथ इंटरैक्ट करता है.
- CONFIG_ID_3: यह CONFIG_ID_1 जैसा ही है. हालांकि, इसमें एंगल-ऑफ़-अराइवल (AoA) का डेटा रिपोर्ट नहीं किया जाता.
- CONFIG_ID_4: यह CONFIG_ID_1 जैसा ही है. हालांकि, इसमें पी-एसटीएस सुरक्षा मोड चालू होता है.
- CONFIG_ID_5: यह CONFIG_ID_2 जैसा ही है. हालांकि, इसमें पी-एसटीएस सुरक्षा मोड चालू होता है.
- CONFIG_ID_6: यह CONFIG_ID_3 जैसा ही है. हालांकि, इसमें पी-एसटीएस सुरक्षा मोड चालू होता है.
- CONFIG_ID_7: यह CONFIG_ID_2 की तरह ही है. हालांकि, इसमें P-STS के लिए कंट्रोल किए जाने वाले व्यक्ति का मुख्य मोड चालू होता है.
[C-1-4] डिवाइस में, उपयोगकर्ता को यूडब्ल्यूबी रेडियो को चालू/बंद करने का विकल्प देना ज़रूरी है.
[C-1-5] यह ज़रूरी है कि UWB रेडियो का इस्तेमाल करने वाले ऐप्लिकेशन के पास, UWB_RANGING अनुमति हो. यह अनुमति, NEARBY_DEVICES अनुमति वाले ग्रुप के तहत आती है.

मानक तय करने वाली संस्थाओं के तय किए गए, ज़रूरी स्टैंडर्ड और सर्टिफ़िकेशन टेस्ट पास करने से यह पक्का करने में मदद मिलती है कि 802.1.15.4 ठीक से काम कर रहा है. इनमें FIRA, CCC, और CSA शामिल हैं.

7.3.14. कस्टम सेंसर

अलग-अलग डिवाइसों पर अलग-अलग अनुभव देने के लिए, डिवाइसों में Android या Wear OS के साथ काम न करने वाले सेंसर शामिल किए जा सकते हैं. पहले से लोड किए गए ऐप्लिकेशन, इन सेंसर को ऐक्सेस कर सकते हैं.

ऐसे सेंसर के लिए, सेंसर आईडी:

[C-0-1] 65536 से ज़्यादा होना चाहिए.

अगर कस्टम सेंसर का इस्तेमाल सेहत या फ़िटनेस से जुड़े कामों के लिए किया जाता है, तो:

[C-0-2] को प्लैटफ़ॉर्म की अनुमति या सिस्टम की अनुमति से सुरक्षित किया जाना चाहिए.

7.4. डेटा कनेक्टिविटी

7.4.1. टेलीफ़ोनी

Android API और इस दस्तावेज़ में इस्तेमाल किया गया "टेलीफ़ोनी" शब्द, खास तौर पर वॉइस कॉल करने और एसएमएस भेजने से जुड़े हार्डवेयर के बारे में बताता है. इसके अलावा, यह मोबाइल (जैसे, GSM, CDMA, LTE, NR) GSM या CDMA नेटवर्क के ज़रिए मोबाइल डेटा सेट अप करने के बारे में भी बताता है. "टेलीफ़ोनी" की सुविधा वाले डिवाइस, कॉल, मैसेज, और डेटा सेवाओं में से कुछ या सभी सेवाएं उपलब्ध करा सकते हैं.

Android का इस्तेमाल उन डिवाइसों पर किया जा सकता है जिनमें टेलीफ़ोनी हार्डवेयर शामिल नहीं है. इसका मतलब है कि Android, फ़ोन के अलावा अन्य डिवाइसों के साथ भी काम करता है.

अगर डिवाइसों में जीएसएम या सीडीएमए टेलीफ़ोनी शामिल है, तो:

[C-1-1] टेक्नोलॉजी के हिसाब से, android.hardware.telephony फ़ीचर फ़्लैग और अन्य सब-फ़ीचर फ़्लैग के बारे में एलान करना ज़रूरी है.
[C-1-2] उस टेक्नोलॉजी के लिए, एपीआई की पूरी सुविधा लागू करनी होगी.
आपातकालीन कॉल के दौरान, सभी तरह की मोबाइल सेवा (2G, 3G, 4G, 5G वगैरह) का इस्तेमाल किया जा सकता है. भले ही, SetAllowedNetworkTypeBitmap() ने नेटवर्क के टाइप सेट किए हों या न किए हों.

अगर डिवाइसों में टेलीफ़ोनी हार्डवेयर शामिल नहीं है, तो:

[C-2-1] पूरे एपीआई को नो-ऑप्स के तौर पर लागू करना ज़रूरी है.

अगर डिवाइस में eUICC या eSIM/एम्बेड किए गए सिम कार्ड की सुविधा काम करती है और इसमें तीसरे पक्ष के डेवलपर के लिए eSIM की सुविधा उपलब्ध कराने का मालिकाना हक वाला तरीका शामिल है, तो:

[C-3-1] android.hardware.telephony.euicc फ़ीचर फ़्लैग के बारे में एलान करना ज़रूरी है.

अगर डिवाइसों में सिस्टम प्रॉपर्टी ro.telephony.iwlan_operation_mode को legacy पर सेट नहीं किया जाता है, तो:

[C-4-1] NetworkRegistrationInfo के एक ही इंस्टेंस के लिए, NetworkRegistrationInfo#getTransportType() को TRANSPORT_TYPE_WWAN के तौर पर रिपोर्ट किए जाने पर, NetworkRegistrationInfo#getAccessNetworkTechnology() के ज़रिए NETWORK_TYPE_IWLAN को रिपोर्ट नहीं किया जाना चाहिए.

अगर डिवाइसों में, मल्टीमीडिया टेलीफ़ोनी सेवा (एमएमटीईएल) और रिच कम्यूनिकेशन सेवा (आरसीएस) की सुविधाओं के लिए, एक ही आईपी मल्टीमीडिया सबसिस्टम (आईएमएस) रजिस्ट्रेशन की सुविधा उपलब्ध है और उन्हें सभी आईएमएस सिग्नलिंग ट्रैफ़िक के लिए, एक ही आईएमएस रजिस्ट्रेशन का इस्तेमाल करने से जुड़ी सेल्युलर कैरियर की ज़रूरी शर्तों का पालन करना है, तो:

[C-5-1] android.hardware.telephony.ims फ़ीचर फ़्लैग के बारे में एलान करना ज़रूरी है. साथ ही, MMTEL और आरसीएस, दोनों के लिए ImsService API को पूरी तरह से लागू करना ज़रूरी है. इसके अलावा, User Capability Exchange API को भी पूरी तरह से लागू करना ज़रूरी है.
[C-5-2] android.hardware.telephony.ims.singlereg फ़ीचर फ़्लैग के बारे में बताना ज़रूरी है. साथ ही, SipTransport API, GbaService API, IRadio 1.6 HAL का इस्तेमाल करके डेडिकेटेड बियरर इंडिकेशन, और IMS Configuration API का इस्तेमाल करके, ऑटो कॉन्फ़िगरेशन सर्वर (एसीएस) या मालिकाना हक वाले अन्य प्रोविज़निंग मैकेनिज़्म के ज़रिए प्रोविज़निंग को पूरी तरह से लागू करना ज़रूरी है.

अगर डिवाइसों पर android.hardware.telephony सुविधा उपलब्ध है, तो:

[C-6-1] SmsManager#sendTextMessage और SmsManager#sendMultipartTextMessage को कॉल करने पर, CarrierMessagingService को कॉल करना ज़रूरी है, ताकि टेक्स्ट मैसेज भेजने की सुविधा दी जा सके. SmsManager#sendMultimediaMessage और SmsManager#downloadMultimediaMessage से, मल्टीमीडिया मैसेज भेजने की सुविधा देने के लिए, CarrierMessagingService को कॉल करना ज़रूरी है.
[C-6-2] android.provider.Telephony.Sms#getDefaultSmsPackage से तय किए गए ऐप्लिकेशन को एसएमएस और मल्टीमीडिया मैसेज (एमएमएस) भेजने और पाने के लिए, SmsManager API का इस्तेमाल करना होगा. packages/apps/Messaging में AOSP के रेफ़रंस इंप्लीमेंटेशन से यह ज़रूरी शर्त पूरी होती है.
[C-6-3] Intent#ACTION_DIAL का जवाब देने वाले ऐप्लिकेशन में, *#*#CODE#*#* के तौर पर फ़ॉर्मैट किए गए किसी भी डायलर कोड को डालने की सुविधा होनी चाहिए. साथ ही, इससे जुड़ा TelephonyManager#ACTION_SECRET_CODE ब्रॉडकास्ट ट्रिगर होना चाहिए.
[C-6-4] Intent#ACTION_DIAL का जवाब देने वाले ऐप्लिकेशन को, उपयोगकर्ताओं को विज़ुअल वॉइसमेल ट्रांसक्रिप्शन दिखाने के लिए VoicemailContract.Voicemails#TRANSCRIPTION का इस्तेमाल करना होगा. ऐसा तब करना होगा, जब ऐप्लिकेशन विज़ुअल वॉइसमेल ट्रांसक्रिप्शन की सुविधा के साथ काम करता हो.
[C-6-5] SubscriptionInfo के सभी इंस्टेंस को एक ही सदस्यता के तौर पर दिखाना होगा. साथ ही, group UUIDs को भी एक ही सदस्यता के तौर पर दिखाना होगा. ऐसा उन सभी सुविधाओं में करना होगा जो उपयोगकर्ताओं को दिखती हैं और जिनमें सिम कार्ड की जानकारी दिखती है और उसे कंट्रोल किया जा सकता है. इस तरह की सुविधाओं के उदाहरणों में, Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS या EuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS से मिलते-जुलते सेटिंग इंटरफ़ेस शामिल हैं.
[C-6-6] किसी भी ऐसी सुविधा में, ग्रुप यूयूआईडी और ऑपर्च्यूनिस्टिक बिट के साथ SubscriptionInfo को न तो दिखाया जाना चाहिए और न ही उसे कंट्रोल करने की अनुमति दी जानी चाहिए जो उपयोगकर्ता को दिखती हैं. साथ ही, इनसे सिम कार्ड की सेटिंग को कॉन्फ़िगर या कंट्रोल किया जा सकता है.

अगर डिवाइसों पर android.hardware.telephony सुविधा लागू की गई है और सिस्टम स्टेटस बार उपलब्ध है, तो:

[C-7-1] SIM की स्थिति की जानकारी देने वाली किसी भी सुविधा में उपयोगकर्ता को दिखाने के लिए, दिए गए ग्रुप यूयूआईडी के लिए, सक्रिय सदस्यता का प्रतिनिधि चुनना ज़रूरी है. इस तरह की सुविधाओं के उदाहरणों में, स्टेटस बार में दिखने वाला सेल्युलर सिग्नल आइकॉन या क्विक सेटिंग टाइल शामिल है.
[C-SR-1] हमारा सुझाव है कि डेटा के लिए चालू सदस्यता को प्रतिनिधि सदस्यता के तौर पर चुना जाए. हालांकि, अगर डिवाइस पर वॉइस कॉल चल रहा है, तो हमारा सुझाव है कि वॉइस कॉल के लिए चालू सदस्यता को प्रतिनिधि सदस्यता के तौर पर चुना जाए.

अगर डिवाइसों पर android.hardware.telephony सुविधा उपलब्ध है, तो:

[C-6-7] ETSI TS 102 221 के मुताबिक, हर UICC के लिए ज़्यादा से ज़्यादा लॉजिकल चैनल (कुल 20) खोलने और उनका एक साथ इस्तेमाल करने की सुविधा होनी चाहिए.
[C-6-8] TelephonyManager#getCarrierServicePackageName के तौर पर डेज़िग्नेट किए गए, चालू कैरियर ऐप्लिकेशन पर इनमें से कोई भी व्यवहार अपने-आप या उपयोगकर्ता की साफ़ तौर पर पुष्टि किए बिना लागू नहीं होना चाहिए:
- नेटवर्क ऐक्सेस रद्द करना या उसे सीमित करना
- अनुमतियां वापस लेना
- AOSP में शामिल मौजूदा पावर मैनेजमेंट की सुविधाओं के अलावा, बैकग्राउंड या फ़ोरग्राउंड में ऐप्लिकेशन के चलने पर पाबंदी लगाना
- ऐप्लिकेशन को बंद करना या अनइंस्टॉल करना

अगर डिवाइस पर android.hardware.telephony सुविधा काम करती है और सभी चालू, बिना किसी शर्त वाली सदस्यताएं, और एक ही ग्रुप UUID वाली सदस्यताएं बंद कर दी गई हैं, डिवाइस से हटा दी गई हैं या बिना किसी शर्त वाली सदस्यता के तौर पर मार्क कर दी गई हैं, तो डिवाइस:

[C-8-1] उसी ग्रुप में मौजूद, मौकापरस्त सदस्यताएं अपने-आप बंद होनी चाहिए.

अगर डिवाइसों में जीएसएम टेलीफ़ोनी की सुविधा शामिल है, लेकिन सीडीएमए टेलीफ़ोनी की सुविधा शामिल नहीं है, तो:

[C-9-1] PackageManager#FEATURE_TELEPHONY_CDMA का एलान नहीं किया जाना चाहिए.
[C-9-2] पसंदीदा या अनुमति वाले नेटवर्क टाइप बिटमास्क में किसी भी 3GPP2 नेटवर्क टाइप को सेट करने की कोशिश करने पर, IllegalArgumentException को थ्रो करना ज़रूरी है.
[C-9-3] TelephonyManager#getMeid से खाली स्ट्रिंग मिलना ज़रूरी है.

अगर डिवाइसों पर, एक से ज़्यादा पोर्ट और प्रोफ़ाइल वाले eUICC काम करते हैं, तो:

[C-10-1] android.hardware.telephony.euicc.mep फ़ीचर फ़्लैग के बारे में एलान करना ज़रूरी है.

अगर डिवाइस में सेल्युलर डेटा कनेक्टिविटी की सुविधा काम करती है, तो:

[C-SR-11] android.hardware.telephony.data सुविधा का एलान करने का सुझाव दिया जाता है.

अगर डिवाइसों के लिए लागू की गई सुविधाओं की रिपोर्ट android.hardware.telephony.data है, तो:

[C-12-1] यह ज़रूरी है कि डिवाइस, एक साथ कम से कम दो सेल्यूलर डेटा नेटवर्क कनेक्शन पर काम करता हो. जैसे, पीडीपी कॉन्टेक्स्ट, पीडीएन कनेक्शन, और डीएन कनेक्शन.

7.4.1.1. नंबर ब्लॉक करने की सुविधा के साथ काम करने वाले डिवाइस

अगर डिवाइसों पर android.hardware.telephony.calling सुविधा उपलब्ध है, तो:

[C-1-1] में नंबर ब्लॉक करने की सुविधा होनी चाहिए
[C-1-2] SDK के दस्तावेज़ में बताए गए तरीके के मुताबिक, BlockedNumberContract और इससे जुड़े एपीआई को पूरी तरह से लागू करना ज़रूरी है.
[C-1-3] BlockedNumberProvider में, किसी फ़ोन नंबर से आने वाले सभी कॉल और मैसेज को ब्लॉक करना ज़रूरी है. इसके लिए, ऐप्लिकेशन के साथ किसी भी तरह का इंटरैक्शन नहीं होना चाहिए. हालांकि, एसडीके के दस्तावेज़ में बताए गए तरीके से, कुछ समय के लिए नंबर ब्लॉक करने की सुविधा बंद की जा सकती है.
[C-1-4] ब्लॉक किए गए कॉल की जानकारी, कॉल लॉग की सुविधा देने वाली कंपनी को देना ज़रूरी है. साथ ही, पहले से इंस्टॉल किए गए डायलर ऐप्लिकेशन में, डिफ़ॉल्ट कॉल लॉग व्यू से BLOCKED_TYPE वाले कॉल को फ़िल्टर करना ज़रूरी है.
[C-1-5] ब्लॉक किए गए मैसेज के लिए, टेलीफ़ोनी की सेवा देने वाली कंपनी को नहीं लिखना चाहिए.
[C-1-6] ब्लॉक किए गए नंबर मैनेज करने के लिए यूज़र इंटरफ़ेस (यूआई) लागू करना ज़रूरी है. यह यूज़र इंटरफ़ेस, TelecomManager.createManageBlockedNumbersIntent() तरीके से मिले इंटेंट के साथ खुलता है.
[C-1-7] सेकंडरी यूज़र को डिवाइस पर ब्लॉक किए गए नंबर देखने या उनमें बदलाव करने की अनुमति नहीं होनी चाहिए. ऐसा इसलिए, क्योंकि Android प्लैटफ़ॉर्म यह मानता है कि डिवाइस पर टेलीफ़ोनी सेवाओं का पूरा कंट्रोल, प्राइमरी यूज़र के पास होता है. ब्लॉक करने से जुड़ा पूरा यूज़र इंटरफ़ेस (यूआई), सेकंडरी उपयोगकर्ताओं के लिए छिपा होना चाहिए. साथ ही, ब्लॉक की गई सूची का अब भी पालन किया जाना चाहिए.
डिवाइस को Android 7.0 पर अपडेट करने पर, ब्लॉक किए गए नंबरों को सेवा देने वाली कंपनी के पास माइग्रेट करना चाहिए.
उपयोगकर्ता को पहले से इंस्टॉल किए गए डायलर ऐप्लिकेशन में, ब्लॉक किए गए कॉल दिखाने की सुविधा मिलनी चाहिए.

7.4.1.2. Telecom API

अगर डिवाइसों में android.hardware.microphone और android.hardware.audio.output की जानकारी दी गई है और android.hardware.type.television की जानकारी नहीं दी गई है, तो:

[7.4.1.2/C-0-1] android.software.telecom फ़ीचर फ़्लैग के बारे में एलान करना ज़रूरी है.
[7.4.1.2/C-0-2] टेलीकॉम फ़्रेमवर्क को लागू करना ज़रूरी है.

अगर डिवाइसों के लिए लागू की गई सुविधाओं की रिपोर्ट android.hardware.telephony.calling है, तो:

[C-1-1] एसडीके में बताए गए ConnectionService एपीआई काम करने चाहिए.
[C-1-2] जब उपयोगकर्ता किसी ऐसे कॉल पर हो जिसे तीसरे पक्ष के किसी ऐसे ऐप्लिकेशन से किया गया हो जिसमें कॉल होल्ड करने की सुविधा उपलब्ध न हो, तब डिवाइस को आने वाले नए कॉल की जानकारी दिखानी चाहिए. साथ ही, उपयोगकर्ता को कॉल स्वीकार या अस्वीकार करने का विकल्प देना चाहिए. कॉल होल्ड करने की सुविधा के बारे में CAPABILITY_SUPPORT_HOLD में बताया गया है.
[C-1-3] ज़रूरी है कि डिवाइस में ऐसा ऐप्लिकेशन हो जो InCallService को लागू करता हो.
[C-SR-1] उपयोगकर्ता को यह सूचना देने का सुझाव दिया जाता है कि इनकमिंग कॉल का जवाब देने पर, चालू कॉल बंद हो जाएगा.

AOSP में, इन ज़रूरी शर्तों को पूरा किया जाता है. इसके लिए, एक सूचना दिखाई जाती है. इसमें उपयोगकर्ता को बताया जाता है कि इनकमिंग कॉल का जवाब देने पर, दूसरा कॉल बंद हो जाएगा.
[C-SR-2] यह सुझाव दिया जाता है कि डिफ़ॉल्ट डायलर ऐप्लिकेशन को पहले से लोड किया जाए. यह ऐप्लिकेशन, कॉल लॉग में कॉल लॉग एंट्री और तीसरे पक्ष के ऐप्लिकेशन का नाम दिखाता है. ऐसा तब होता है, जब तीसरे पक्ष का ऐप्लिकेशन अपने PhoneAccount पर EXTRA_LOG_SELF_MANAGED_CALLS एक्स्ट्रा कुंजी को true पर सेट करता है.
[C-SR-3] android.telecom एपीआई के लिए, ऑडियो हेडसेट के KEYCODE_MEDIA_PLAY_PAUSE और KEYCODE_HEADSETHOOK इवेंट को मैनेज करने का सुझाव दिया जाता है. ये इवेंट इस तरह से मैनेज किए जाने चाहिए:
- कॉल Connection.onDisconnect() जब कॉल के दौरान, बटन को कम समय के लिए दबाया जाता है.
- कॉल Connection.onAnswer() जब इनकमिंग कॉल के दौरान, बटन को कम समय के लिए दबाया जाता है.
- कॉल Connection.onReject() जब इनकमिंग कॉल के दौरान, की-इवेंट को लंबे समय तक दबाए रखने का पता चलता है.
- CallAudioState के म्यूट होने की स्थिति को टॉगल करें.

7.4.1.3. सेल्युलर NAT-T कीपअलाइव ऑफ़लोड

डिवाइस में सेट किए गए सिस्टम के लिए:

इसमें मोबाइल डेटा को बंद करने की सुविधा होनी चाहिए.

अगर डिवाइसों में, सेल्युलर कीपअलाइव ऑफ़लोडिंग की सुविधा काम करती है और यह सुविधा तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध है, तो:

[C-1-1] SocketKeepAlive API के साथ काम करना ज़रूरी है.
[C-1-2] सेल्यूलर नेटवर्क पर, कम से कम एक साथ चालू रहने वाले स्लॉट के साथ काम करना ज़रूरी है.
[C-1-3] यह ज़रूरी है कि डिवाइस, सेल्युलर रेडियो एचएएल के साथ काम करने वाले सभी सेल्युलर कीपअलाइव स्लॉट के साथ काम करे.
[C-SR-1] हर रेडियो इंस्टेंस के लिए, कम से कम तीन सेल्यूलर कीपअलाइव स्लॉट इस्तेमाल करने का सुझाव दिया जाता है.

अगर डिवाइस में, मोबाइल डेटा को चालू रखने की सुविधा के लिए, डेटा को ऑफ़लोड करने की सुविधा शामिल नहीं है, तो:

[C-2-1] ERROR_UNSUPPORTED को वापस करना ज़रूरी है.

7.4.2. आईईईई 802.11 (वाई-फ़ाई)

डिवाइस में सेट किए गए सिस्टम के लिए:

इसमें 802.11 के एक या उससे ज़्यादा फ़ॉर्म के लिए सहायता शामिल होनी चाहिए.

अगर डिवाइस में 802.11 के साथ काम करने की सुविधा शामिल है और तीसरे पक्ष के ऐप्लिकेशन के लिए यह सुविधा उपलब्ध है, तो:

[C-1-1] Android API को लागू करना ज़रूरी है.
[C-1-2] हार्डवेयर फ़ीचर फ़्लैग android.hardware.wifi की जानकारी देना ज़रूरी है.
[C-1-3] एसडीके के दस्तावेज़ में बताए गए तरीके से, मल्टीकास्ट एपीआई को लागू करना ज़रूरी है.
[C-1-4] डिवाइस में mDNS की सुविधा काम करनी चाहिए. साथ ही, डिवाइस के चालू रहने के दौरान, mDNS पैकेट (224.0.0.251 या ff02::fb) को फ़िल्टर नहीं किया जाना चाहिए. भले ही, स्क्रीन चालू न हो. हालांकि, अगर मल्टीकास्ट लॉक नहीं है और पैकेट को APF फ़िल्टर करता है, तो ऐसा किया जा सकता है. फ़िलहाल, NsdManager API के ज़रिए ऐप्लिकेशन ने mDNS से जुड़ी जो कार्रवाइयां करने का अनुरोध किया है उन्हें पूरा करने के लिए, इन पैकेट की ज़रूरत नहीं है. हालांकि, अगर टारगेट मार्केट में लागू होने वाली कानूनी शर्तों के मुताबिक, बिजली की खपत की तय सीमा में बने रहने के लिए ऐसा करना ज़रूरी हो, तो डिवाइस mDNS पैकेट को फ़िल्टर कर सकता है.
[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] जब स्टेशन (एसटीए) किसी वाई-फ़ाई ऐक्सेस पॉइंट (एपी) से जुड़ रहा हो या जुड़ चुका हो, तब डिवाइस में इस्तेमाल होने वाला एमएसी पता हर बार बदला हुआ होना चाहिए.
- डिवाइस को हर SSID (पासपॉइंट के लिए FQDN) के साथ कम्यूनिकेट करते समय, बदला हुआ एक अलग एमएसी पता इस्तेमाल करना चाहिए.
- डिवाइस को उपयोगकर्ता को हर SSID (पासपॉइंट के लिए FQDN) के लिए एमएसी पता बदलने या न बदलने का विकल्प देना चाहिए. साथ ही, नए वाई-फ़ाई कॉन्फ़िगरेशन के लिए डिफ़ॉल्ट के तौर पर सेट किया गया मोड बदला हुआ होना चाहिए.
[C-SR-2] किसी भी एपी को बनाते समय एक ऐसे BSSID का इस्तेमाल किया जाना चाहिए जिसे बदला गया है.
- एपी के इस्तेमाल किए गए हर SSID के लिए, एमएसी पता बदला गया होना चाहिए और वही बना रहना चाहिए.
- डिवाइस में उपयोगकर्ता को इस सुविधा को बंद करने का विकल्प दिया जा सकता है. अगर यह विकल्प दिया जाता है, तो एमएसी पता बदलने की सुविधा डिफ़ॉल्ट रूप से चालू होनी चाहिए.

अगर डिवाइस में, आईईईई 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] एसडीके के दस्तावेज़ में बताए गए तरीके के मुताबिक, Android API को लागू करना ज़रूरी है.
[C-1-2] हार्डवेयर की सुविधा android.hardware.wifi.direct के बारे में जानकारी देना ज़रूरी है.
[C-1-3] यह ज़रूरी है कि यह डिवाइस, वाई-फ़ाई की सामान्य सुविधा के साथ काम करता हो.
[C-1-4] यह ज़रूरी है कि यह वाई-फ़ाई और वाई-फ़ाई डायरेक्ट, दोनों के साथ एक ही समय में काम करता हो.
[C-SR-1] सभी नए Wi-Fi Direct कनेक्शन के लिए, डिवाइस का एमएसी पता बदलते रहने का सुझाव दिया जाता है.

7.4.2.2. वाई-फ़ाई टनल वाले डायरेक्ट लिंक का सेटअप

डिवाइस में सेट किए गए सिस्टम के लिए:

इसमें Android SDK के दस्तावेज़ में बताए गए तरीके से, Wi-Fi टनल वाले डायरेक्ट लिंक सेटअप (टीडीएलएस) की सुविधा शामिल होनी चाहिए.

अगर डिवाइस में TDLS की सुविधा काम करती है और WiFiManager API से TDLS चालू है, तो:

[C-1-1] WifiManager.isTdlsSupported के ज़रिए, TDLS के साथ काम करने की जानकारी देना ज़रूरी है.
टीडीएलएस का इस्तेमाल सिर्फ़ तब करना चाहिए, जब ऐसा करना मुमकिन हो और फ़ायदेमंद हो.
इसमें कुछ अनुमानित जानकारी होनी चाहिए और जब इसकी परफ़ॉर्मेंस, वाई-फ़ाई ऐक्सेस पॉइंट से कनेक्ट करने की तुलना में खराब हो सकती है, तब इसे टीडीएलएस का इस्तेमाल नहीं करना चाहिए.

7.4.2.3. Wi-Fi Aware

डिवाइस में सेट किए गए सिस्टम के लिए:

Wi-Fi Aware के साथ काम करना चाहिए.

अगर डिवाइसों में Wi-Fi Aware की सुविधा काम करती है और तीसरे पक्ष के ऐप्लिकेशन के लिए यह सुविधा उपलब्ध है, तो:

[C-1-1] एसडीके के दस्तावेज़ में बताए गए तरीके के मुताबिक, WifiAwareManager एपीआई लागू करना ज़रूरी है.
[C-1-2] android.hardware.wifi.aware फ़ीचर फ़्लैग के बारे में एलान करना ज़रूरी है.
[C-1-3] यह ज़रूरी है कि डिवाइस, वाई-फ़ाई और वाई-फ़ाई अवेयर की सुविधाओं को एक साथ इस्तेमाल करने की अनुमति देता हो.
[C-1-4] Wi-Fi Aware के मैनेजमेंट इंटरफ़ेस के पते को हर 30 मिनट में बदलना ज़रूरी है. साथ ही, जब भी Wi-Fi Aware चालू हो, तब भी इसे बदलना ज़रूरी है. हालांकि, अगर Aware की रेंजिंग की प्रोसेस चल रही है या Aware का डेटा-पाथ चालू है, तो इसे बदलने की ज़रूरत नहीं है. डेटा-पाथ चालू रहने तक, इसे बदलने की ज़रूरत नहीं है.

अगर डिवाइसों में, सेक्शन 7.4.2.5 में बताए गए तरीके से Wi-Fi Aware और वाई-फ़ाई लोकेशन की सुविधा काम करती है और ये सुविधाएं तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध हैं, तो:

[C-2-1] MUST implement the location-aware discovery APIs: setRangingEnabled, setMinDistanceMm, setMaxDistanceMm, and onServiceDiscoveredWithinRange.

7.4.2.4. वाई-फ़ाई पासपॉइंट

अगर डिवाइस में 802.11 (वाई-फ़ाई) का इस्तेमाल किया जाता है, तो:

इसमें Wi-Fi Passpoint की सुविधा काम करनी चाहिए.

अगर डिवाइस में वाई-फ़ाई पासपॉइंट की सुविधा काम करती है, तो:

[C-1-2] एसडीके के दस्तावेज़ में बताए गए तरीके से, 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] को AAA सर्वर के सर्टिफ़िकेट को प्रोसेस करना होगा. इसके बारे में Hotspot 2.0 R3 स्पेसिफ़िकेशन में बताया गया है.
[C-1-8] इसमें वाई-फ़ाई पिकर के ज़रिए, डिवाइस को चालू करने की सुविधा को कंट्रोल करने का विकल्प होना चाहिए.
[C-1-9] यह ज़रूरी है कि रीबूट करने पर भी Passpoint कॉन्फ़िगरेशन बने रहें.
[C-SR-1] यह ज़रूरी है कि नियम और शर्तों को स्वीकार करने की सुविधा काम करती हो.
[C-SR-2] यह सुझाव दिया जाता है कि जगह की जानकारी की सुविधा काम करे.

अगर उपयोगकर्ता को Passpoint की सुविधा बंद करने के लिए ग्लोबल स्विच दिया जाता है, तो:

[C-3-1] Passpoint को डिफ़ॉल्ट रूप से चालू करना ज़रूरी है.

7.4.2.5. वाई-फ़ाई की जगह की जानकारी (वाई-फ़ाई राउंड ट्रिप टाइम - आरटीटी)

डिवाइस में सेट किए गए सिस्टम के लिए:

इसमें वाई-फ़ाई की जगह की जानकारी की सुविधा शामिल होनी चाहिए.

अगर डिवाइसों में वाई-फ़ाई लोकेशन की सुविधा काम करती है और तीसरे पक्ष के ऐप्लिकेशन के लिए यह सुविधा उपलब्ध है, तो:

[C-1-1] एसडीके के दस्तावेज़ में बताए गए तरीके के मुताबिक, WifiRttManager एपीआई लागू करना ज़रूरी है.
[C-1-2] android.hardware.wifi.rtt फ़ीचर फ़्लैग के बारे में एलान करना ज़रूरी है.
[C-1-3] हर आरटीटी बर्स्ट के लिए, डिवाइस का एमएसी पता बदलना ज़रूरी है. ऐसा तब होता है, जब आरटीटी को उस वाई-फ़ाई इंटरफ़ेस पर एक्ज़ीक्यूट किया जा रहा हो जो किसी ऐक्सेस पॉइंट से जुड़ा न हो.
[C-1-4] 68वें पर्सेंटाइल पर 80 मेगाहर्ट्ज़ बैंडविड्थ के साथ, दो मीटर के दायरे में सटीक होना चाहिए. इसकी गणना, संचयी बंटन फ़ंक्शन के साथ की जाती है.
[C-SR-1] यह सुझाव दिया जाता है कि 68वें पर्सेंटाइल पर 80 मेगाहर्ट्ज़ बैंडविथ के साथ, 1.5 मीटर के दायरे में सटीक जानकारी दी जाए. इसकी गणना, संचयी बंटन फ़ंक्शन के हिसाब से की जाती है.

7.4.2.6. वाई-फ़ाई कीपअलाइव ऑफ़लोड

डिवाइस में सेट किए गए सिस्टम के लिए:

इसमें वाई-फ़ाई कीपअलाइव ऑफ़लोड की सुविधा होनी चाहिए.

अगर डिवाइसों में, वाई-फ़ाई कीपअलाइव ऑफ़लोडिंग की सुविधा शामिल है और तीसरे पक्ष के ऐप्लिकेशन के लिए यह सुविधा उपलब्ध है, तो:

[C-1-1] SocketKeepAlive एपीआई के साथ काम करना ज़रूरी है.
[C-1-2] वाई-फ़ाई पर कम से कम तीन कीपअलाइव स्लॉट के साथ काम करना ज़रूरी है

अगर डिवाइसों में वाई-फ़ाई कीपअलाइव ऑफ़लोडिंग की सुविधा काम नहीं करती है, तो:

[C-2-1] ERROR_UNSUPPORTED को वापस करना ज़रूरी है.

7.4.2.7. वाई-फ़ाई ईज़ी कनेक्ट (डिवाइस प्रोविज़निंग प्रोटोकॉल)

डिवाइस में सेट किए गए सिस्टम के लिए:

इसमें वाई-फ़ाई इज़ी कनेक्ट (डीपीपी) की सुविधा होनी चाहिए.

[C-1-1] WifiManager#isEasyConnectSupported() तरीके से true वैल्यू मिलनी चाहिए.

7.4.2.8. एंटरप्राइज़ वाई-फ़ाई सर्वर सर्टिफ़िकेट की पुष्टि करने की सुविधा

अगर वाई-फ़ाई सर्वर के सर्टिफ़िकेट की पुष्टि नहीं की जाती है या वाई-फ़ाई सर्वर का डोमेन नेम सेट नहीं किया जाता है, तो डिवाइसों पर:

[C-SR-1] हमारा सुझाव है कि सेटिंग ऐप्लिकेशन में, उपयोगकर्ता को Enterprise Wi-Fi नेटवर्क को मैन्युअल तरीके से जोड़ने का विकल्प न दिया जाए.

7.4.2.9. ट्रस्ट ऑन फ़र्स्ट यूज़ (टीओएफ़यू)

अगर डिवाइसों पर ट्रस्ट ऑन फ़र्स्ट यूज़ (टीओएफ़यू) की सुविधा काम करती है और उपयोगकर्ता को WPA/WPA2/WPA3-Enterprise कॉन्फ़िगरेशन तय करने की अनुमति मिलती है, तो:

[C-4-1] उपयोगकर्ता को TOFU का इस्तेमाल करने का विकल्प देना ज़रूरी है.

7.4.2.10. वाई-फ़ाई से नज़दीकी डिवाइसों का पता लगाने की सुविधा

अगर डिवाइस में वाई-फ़ाई की मदद से नज़दीकी डिवाइसों का पता लगाने की सुविधा काम करती है, तो:

[C-1-1] में नज़दीकी डिवाइसों का पता लगाने की सुविधा शामिल होनी चाहिए.
[C-1-2] android.hardware.wifi.rtt फ़ीचर फ़्लैग के बारे में एलान करना ज़रूरी है.
[C-1-3] WifiRttManager#getProximityDetectionCharacteristics() तरीके से, शून्य के अलावा कोई और वैल्यू मिलनी चाहिए.
[C-1-4] WifiRttManager लगातार रेंजिंग करने वाले एपीआई लागू करने ज़रूरी हैं.
[C-1-5] यह ज़रूरी है कि डिवाइस, वाई-फ़ाई और वाई-फ़ाई से नज़दीकी डिवाइसों का पता लगाने की सुविधा, दोनों के साथ काम करे.
[C-1-6] 80 मेगाहर्ट्ज़ बैंडविड्थ पर, 68वें पर्सेंटाइल (संचयी बंटन फ़ंक्शन के हिसाब से कैलकुलेट किया गया) पर, 2 मीटर के अंदर सटीक होना चाहिए.
[C-1-7] इसे प्रॉक्सिमिटी डिटेक्शन (पीडी) रेंजिंग की सुविधा को सबसे ज़्यादा उपलब्ध फ़्रीक्वेंसी बैंड (6 गीगाहर्ट्ज़, 5 गीगाहर्ट्ज़ या 2.4 गीगाहर्ट्ज़) में चालू करना होगा. इसके लिए, प्राथमिकता के इस क्रम में ज़्यादा से ज़्यादा बैंडविथ का इस्तेमाल करना होगा: 160 मेगाहर्ट्ज़, 80 मेगाहर्ट्ज़, 40 मेगाहर्ट्ज़, और 20 मेगाहर्ट्ज़.
[C-SR-1] यह सुझाव दिया जाता है कि 68वें पर्सेंटाइल पर 80 मेगाहर्ट्ज़ की बैंडविथ के साथ, 1.5 मीटर के दायरे में सटीक जानकारी दें. इसकी गणना, संचयी बंटन फ़ंक्शन के हिसाब से की जाती है.
[C-SR-2] 802.11az NTB रेंजिंग का इस्तेमाल करने का सुझाव दिया जाता है.

7.4.3. ब्लूटूथ

अगर डिवाइस में ब्लूटूथ ऑडियो प्रोफ़ाइल की सुविधा काम करती है, तो:

इसमें अडवांस ऑडियो कोडेक और ब्लूटूथ ऑडियो कोडेक (जैसे, LDAC) काम करने चाहिए.

अगर डिवाइस में HFP, A2DP, और AVRCP काम करते हैं, तो:

डिवाइस में कम से कम पांच डिवाइसों को कनेक्ट करने की सुविधा होनी चाहिए.

अगर डिवाइसों में android.hardware.vr.high_performance सुविधा का एलान किया जाता है, तो:

[C-1-1] इनमें ब्लूटूथ 4.2 और ब्लूटूथ स्मार्ट डेटा लेंथ एक्सटेंशन काम करना चाहिए.

Android में, ब्लूटूथ और ब्लूटूथ लो एनर्जी की सुविधा काम करती है.

अगर डिवाइस में ब्लूटूथ और ब्लूटूथ लो एनर्जी की सुविधा काम करती है, तो:

[C-2-1] यह ज़रूरी है कि प्लैटफ़ॉर्म की काम की सुविधाओं (android.hardware.bluetooth और android.hardware.bluetooth_le) के बारे में एलान किया जाए और प्लैटफ़ॉर्म के एपीआई लागू किए जाएं.
डिवाइस के हिसाब से, ब्लूटूथ की ज़रूरी प्रोफ़ाइलें लागू करनी चाहिए. जैसे, A2DP, AVRCP, OBEX, HFP वगैरह.

अगर डिवाइस में ब्लूटूथ स्मार्ट (बीएलई) की सुविधा काम करती है, तो:

[C-3-1] हार्डवेयर की सुविधा android.hardware.bluetooth_le के बारे में एलान करना ज़रूरी है.
[C-3-2] एसडीके के दस्तावेज़ और android.bluetooth में बताए गए तरीके से, GATT (जेनेरिक एट्रिब्यूट प्रोफ़ाइल) पर आधारित Bluetooth API चालू करना ज़रूरी है.
[C-3-3] BluetoothAdapter.isOffloadedFilteringSupported() के लिए सही वैल्यू रिपोर्ट करना ज़रूरी है, ताकि यह पता चल सके कि ScanFilter एपीआई क्लास के लिए फ़िल्टर करने का लॉजिक लागू किया गया है या नहीं.
[C-3-4] BluetoothAdapter.isMultipleAdvertisementSupported() एट्रिब्यूट के लिए सही वैल्यू रिपोर्ट करना ज़रूरी है, ताकि यह पता चल सके कि कम ऊर्जा खपत वाले विज्ञापन दिखाने की सुविधा काम करती है या नहीं.
[C-3-5] डिवाइस को, हल किए जा सकने वाले निजी पते (आरपीए) के लिए 15 मिनट से ज़्यादा का टाइमआउट लागू नहीं करना चाहिए. साथ ही, टाइमआउट होने पर पते को रोटेट करना चाहिए, ताकि उपयोगकर्ता की निजता की सुरक्षा की जा सके. ऐसा तब करना चाहिए, जब डिवाइस स्कैनिंग या विज्ञापन के लिए BLE का इस्तेमाल कर रहा हो. टाइमिंग अटैक को रोकने के लिए, टाइम आउट इंटरवल को भी 5 से 15 मिनट के बीच में रैंडमाइज़ किया जाना चाहिए.
ScanFilter API को लागू करते समय, फ़िल्टर करने के लॉजिक को ब्लूटूथ चिपसेट पर ऑफ़लोड करने की सुविधा होनी चाहिए.
बैटरी की खपत कम करने के लिए, ब्लूटूथ चिपसेट पर एक साथ कई स्कैनिंग प्रोसेस को ऑफ़लोड करने की सुविधा होनी चाहिए.
इसमें कम से कम चार स्लॉट के साथ एक से ज़्यादा विज्ञापन दिखाने की सुविधा होनी चाहिए.

अगर डिवाइस में ब्लूटूथ LE की सुविधा काम करती है और लोकेशन स्कैन करने के लिए ब्लूटूथ LE का इस्तेमाल किया जाता है, तो:

[C-4-1] सिस्टम एपीआई BluetoothAdapter.isBleScanAlwaysAvailable() के ज़रिए पढ़ी गई वैल्यू को चालू/बंद करने के लिए, उपयोगकर्ता को सुविधा देनी होगी.

अगर डिवाइस में ब्लूटूथ LE और Hearing Aids Profile के साथ काम करने की सुविधा शामिल है, जैसा कि ब्लूटूथ LE का इस्तेमाल करके कान की मशीन में ऑडियो सुनने की सुविधा में बताया गया है, तो:

[C-5-1] BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID) के लिए, true को वापस लाना ज़रूरी है.

अगर डिवाइस में ब्लूटूथ या ब्लूटूथ लो एनर्जी की सुविधा काम करती है, तो:

[C-6-1] किसी भी ब्लूटूथ मेटाडेटा (जैसे कि स्कैन के नतीजे) का ऐक्सेस सीमित करना होगा. इस मेटाडेटा का इस्तेमाल, डिवाइस की जगह की जानकारी का पता लगाने के लिए किया जा सकता है. हालांकि, ऐसा तब तक किया जाना चाहिए, जब तक अनुरोध करने वाला ऐप्लिकेशन, android.permission.ACCESS_FINE_LOCATION अनुमति की जांच को पास न कर ले. यह जांच, ऐप्लिकेशन की मौजूदा फ़ोरग्राउंड/बैकग्राउंड स्थिति के आधार पर की जाती है.

अगर डिवाइस में ब्लूटूथ या ब्लूटूथ लो एनर्जी की सुविधा काम करती है और ऐप्लिकेशन मेनिफ़ेस्ट में डेवलपर ने यह एलान नहीं किया है कि वे ब्लूटूथ से जगह की जानकारी नहीं ले रहे हैं, तो:

[C-6-2] ब्लूटूथ ऐक्सेस को android.permission.ACCESS_FINE_LOCATION के पीछे छिपाना ज़रूरी है.

अगर डिवाइस में सेट किए हुए सिस्टम, BluetoothAdapter.isLeAudioSupported() एपीआई के लिए true दिखाते हैं, तो:

[C-7-1] यूनिकास्ट क्लाइंट के साथ काम करना ज़रूरी है.
[C-7-2] 2M PHY के साथ काम करना ज़रूरी है.
[C-7-3] LE Extended advertising के साथ काम करना ज़रूरी है.
[C-7-4] ज़रूरी है कि CIG में कम से कम दो सीआईएस कनेक्शन हों.
[C-7-5] BAP यूनिकास्ट क्लाइंट, CSIP सेट कोऑर्डिनेटर, एमसीपी सर्वर, वीसीपी कंट्रोलर, और सीसीपी सर्वर को एक साथ चालू करना ज़रूरी है.
[C-SR-1] एचएपी यूनिकास्ट क्लाइंट को चालू करने का सुझाव दिया जाता है.

अगर डिवाइस में सेट किए हुए सिस्टम, BluetoothAdapter.isLeAudioBroadcastSourceSupported() एपीआई के लिए true दिखाते हैं, तो:

[C-8-1] ज़रूरी है कि बीआईएस में कम से कम दो लिंक शामिल किए जा सकें.
[C-8-2] BAP ब्रॉडकास्ट सोर्स और BAP ब्रॉडकास्ट असिस्टेंट, दोनों को एक साथ चालू करना ज़रूरी है.
[C-8-3] LE Periodic advertising के साथ काम करना ज़रूरी है.

अगर डिवाइस में सेट किए हुए सिस्टम, BluetoothAdapter.isLeAudioBroadcastAssistantSupported() एपीआई के लिए true दिखाते हैं, तो:

[C-9-1] PAST (पीरियोडिक ऐडवर्टाइज़िंग सिंक ट्रांसफ़र) के साथ काम करना ज़रूरी है.
[C-9-2] LE पीरियोडिक विज्ञापन के साथ काम करना ज़रूरी है.

अगर डिवाइसों में FEATURE_BLUETOOTH_LE का एलान किया जाता है, तो:

[C-10-1] रेफ़रंस डिवाइस से एक मीटर की दूरी पर, 95% मेज़रमेंट के लिए आरएसएसआई मेज़रमेंट, +/-9 डीबी के अंदर होना चाहिए. रेफ़रंस डिवाइस, लाइन ऑफ़ साइट एनवायरमेंट में ADVERTISE_TX_POWER_HIGH पर ट्रांसमिट करता है.
[C-10-2] हर चैनल के विचलन को कम करने के लिए, Rx/Tx में सुधार करना ज़रूरी है, ताकि 95% मेज़रमेंट के लिए, तीन में से हर चैनल पर मेज़रमेंट और हर ऐंटेना (अगर एक से ज़्यादा का इस्तेमाल किया जाता है) पर मेज़रमेंट, एक-दूसरे से +/-3 dB के अंतर में हों.

अगर डिवाइसों में FEATURE_BLUETOOTH_LE_CHANNEL_SOUNDING का एलान किया जाता है, तो:

[C-11-1] हार्डवेयर फ़ीचर फ़्लैग android.hardware.bluetooth_le.channel_sounding की जानकारी देना ज़रूरी है.
[C-11-2] 90वें पर्सेंटाइल पर, 1 मीटर की दूरी पर, संचयी बंटन फ़ंक्शन के हिसाब से, रेंज को +/- 0.5 मीटर के अंतर के साथ सटीक तौर पर रिपोर्ट करना ज़रूरी है.

अगर डिवाइसों में FEATURE_BLUETOOTH_LE का एलान किया जाता है, तो:

[C-SR-2] आरएक्स ऑफ़सेट को मेज़र करने और उसकी भरपाई करने का सुझाव दिया जाता है, ताकि यह पक्का किया जा सके कि ADVERTISE_TX_POWER_HIGH पर ट्रांसमिट करने वाले रेफ़रंस डिवाइस से 1 मीटर की दूरी पर, मीडियन बीएलई आरएसएसआई -60 डीबीएम +/-10 डीबी हो. यहां डिवाइसों को इस तरह से रखा जाता है कि वे 'पैरलल प्लेन' पर हों और उनकी स्क्रीन एक ही दिशा में हों.
[C-SR-3] टीएक्स ऑफ़सेट को मेज़र करने और उसकी भरपाई करने के लिए, इन शर्तों को पूरा करना ज़रूरी है, ताकि यह पक्का किया जा सके कि 1 मीटर की दूरी पर रखे गए रेफ़रंस डिवाइस से स्कैन करने पर, बीएलई आरएसएसआई का मीडियन -60 dBm +/-10 dB हो. साथ ही, डिवाइसों को इस तरह से रखा गया हो कि वे ADVERTISE_TX_POWER_HIGH पर ट्रांसमिट कर रहे हों और उनके स्क्रीन एक ही दिशा में हों.

हमारा सुझाव है कि आप उपयोगकर्ता की मौजूदगी का पता लगाने की सुविधा के लिए ज़रूरी शर्तें में दिए गए मेज़रमेंट सेटअप के चरणों का पालन करें.

7.4.4. नियर फ़ील्ड कम्यूनिकेशन

डिवाइस में सेट किए गए सिस्टम के लिए:

इसमें नियर-फ़ील्ड कम्यूनिकेशन (एनएफ़सी) के लिए, ट्रांसीवर और उससे जुड़ा हार्डवेयर शामिल होना चाहिए.
[C-0-1] android.nfc.NdefMessage और android.nfc.NdefRecord एपीआई को लागू करना ज़रूरी है. भले ही, इनमें एनएफ़सी के लिए सहायता शामिल न हो या android.hardware.nfc सुविधा को क्लास के तौर पर एलान न किया गया हो. ऐसा इसलिए, क्योंकि क्लास, प्रोटोकॉल से अलग डेटा प्रज़ेंटेशन फ़ॉर्मैट को दिखाती हैं.

अगर डिवाइसों में एनएफ़सी हार्डवेयर शामिल है और इसे तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराने का प्लान है, तो:

[C-1-1] android.content.pm.PackageManager.hasSystemFeature() तरीके से, android.hardware.nfc सुविधा की जानकारी देना ज़रूरी है.
डिवाइस में, नीचे दिए गए NFC स्टैंडर्ड के ज़रिए NDEF मैसेज पढ़ने और लिखने की सुविधा होनी चाहिए:
[C-1-2] इसमें एनएफ़सी फ़ोरम रीडर/राइटर के तौर पर काम करने की सुविधा होनी चाहिए. इसके लिए, एनएफ़सी फ़ोरम की तकनीकी जानकारी (NFCForum-TS-DigitalProtocol-1.0) में बताए गए इन एनएफ़सी स्टैंडर्ड का इस्तेमाल किया जाना चाहिए:
- NfCA (ISO14443-3A)
- NfCB (ISO14443-3B)
- NfcF (JIS X 6319-4)
- IsoDep (ISO 14443-4)
- NFC फ़ोरम के टैग टाइप 2, 3, 4, 5 (NFC फ़ोरम के हिसाब से तय किए गए)
[C-SR-1] यह सुझाव दिया जाता है कि डिवाइस में, एनएफ़सी के इन स्टैंडर्ड के ज़रिए एनडीईएफ़ मैसेज और रॉ डेटा को पढ़ने और लिखने की सुविधा होनी चाहिए. ध्यान दें कि एनएफ़सी के स्टैंडर्ड को STRONGLY RECOMMENDED के तौर पर बताया गया है. हालांकि, आने वाले समय में Compatibility Definition में इन स्टैंडर्ड को MUST के तौर पर बदलने का प्लान है. इस वर्शन में इन मानकों का पालन करना ज़रूरी नहीं है. हालांकि, आने वाले वर्शन में इनका पालन करना ज़रूरी होगा. Android के इस वर्शन का इस्तेमाल करने वाले मौजूदा और नए डिवाइसों को, इन ज़रूरी शर्तों को अभी पूरा करने का सुझाव दिया जाता है. इससे वे आने वाले समय में, प्लैटफ़ॉर्म के नए वर्शन पर अपग्रेड कर पाएंगे.
[C-1-13] NFC डिस्कवरी मोड में होने पर, डिवाइस को उन सभी टेक्नोलॉजी के लिए पोल करना होगा जिनके साथ वह काम करता है.
डिवाइस के चालू होने पर, एनएफ़सी को डिस्कवरी मोड में होना चाहिए. साथ ही, स्क्रीन चालू होनी चाहिए और लॉक-स्क्रीन अनलॉक होनी चाहिए.
Thinfilm NFC Barcode प्रॉडक्ट के बारकोड और यूआरएल (अगर कोड में बदला गया है) को पढ़ने में सक्षम होना चाहिए.

ध्यान दें कि ऊपर बताए गए JIS, ISO, और NFC फ़ोरम के स्पेसिफ़िकेशन के लिए, सार्वजनिक तौर पर उपलब्ध लिंक मौजूद नहीं हैं.

Android में, एनएफ़सी होस्ट कार्ड एम्युलेशन (एचसीई) मोड की सुविधा काम करती है.

अगर डिवाइस में, एचसीई (NfcA और/या NfcB के लिए) की सुविधा देने वाला एनएफ़सी कंट्रोलर चिपसेट शामिल है और यह ऐप्लिकेशन आईडी (एआईडी) राउटिंग की सुविधा देता है, तो:

[C-2-1] android.hardware.nfc.hce सुविधा के बारे में जानकारी देना ज़रूरी है.
[C-2-2] Android SDK में बताए गए NFC HCE API के साथ काम करना ज़रूरी है.

अगर डिवाइस में NFC कंट्रोलर चिपसेट शामिल है, जो NfcF के लिए HCE की सुविधा देता है और तीसरे पक्ष के ऐप्लिकेशन के लिए इस सुविधा को लागू करता है, तो:

[C-3-1] android.hardware.nfc.hcef सुविधा के कॉन्स्टेंट की जानकारी देना ज़रूरी है.
[C-3-2] Android SDK में बताए गए NfcF Card Emulation APIs को लागू करना ज़रूरी है.

अगर डिवाइस में इस सेक्शन में बताई गई सामान्य एनएफ़सी की सुविधा शामिल है और रीडर/राइटर के तौर पर MIFARE टेक्नोलॉजी (MIFARE Classic, MIFARE Ultralight, MIFARE Classic पर NDEF) के साथ काम करता है, तो:

[C-4-1] Android SDK के दस्तावेज़ में बताए गए Android API को लागू करना ज़रूरी है.
[C-4-2] android.content.pm.PackageManager.hasSystemFeature() तरीके से, com.nxp.mifare सुविधा की रिपोर्ट करना ज़रूरी है. ध्यान दें कि यह Android की स्टैंडर्ड सुविधा नहीं है. इसलिए, यह android.content.pm.PackageManager क्लास में कॉन्स्टेंट के तौर पर नहीं दिखती.

7.4.5. नेटवर्किंग प्रोटोकॉल और एपीआई

7.4.5.1. नेटवर्क की कम से कम क्षमता

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-1] डिवाइस में, एक या उससे ज़्यादा तरह के डेटा नेटवर्किंग की सुविधा होनी चाहिए. खास तौर पर, डिवाइस में कम से कम एक ऐसा डेटा स्टैंडर्ड होना चाहिए जो 200 Kbit/सेकंड या इससे ज़्यादा की स्पीड से डेटा ट्रांसफ़र कर सके. इस ज़रूरी शर्त को पूरा करने वाली टेक्नोलॉजी के उदाहरणों में, EDGE, HSPA, EV-DO, 802.11g, Ethernet, और Bluetooth PAN शामिल हैं.
जब फ़िज़िकल नेटवर्किंग स्टैंडर्ड (जैसे, ईथरनेट) प्राइमरी डेटा कनेक्शन हो, तब कम से कम एक सामान्य वायरलेस डेटा स्टैंडर्ड (जैसे, 802.11 (वाई-फ़ाई)) के लिए भी सहायता शामिल होनी चाहिए.
एक से ज़्यादा तरह के डेटा कनेक्शन का इस्तेमाल कर सकता है.

7.4.5.2. IPv6

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-2] इसमें IPv6 नेटवर्किंग स्टैक शामिल होना चाहिए. साथ ही, मैनेज किए गए एपीआई (जैसे, java.net.Socket और java.net.URLConnection) और नेटिव एपीआई (जैसे, AF_INET6 सॉकेट) का इस्तेमाल करके, IPv6 कम्यूनिकेशन की सुविधा होनी चाहिए.
[C-0-3] IPv6 को डिफ़ॉल्ट रूप से चालू करना ज़रूरी है.
यह पक्का करना ज़रूरी है कि आईपीवी6 से होने वाला कम्यूनिकेशन, आईपीवी4 जितना भरोसेमंद हो. उदाहरण के लिए:
[C-0-4] यह ज़रूरी है कि डिवाइस, डॉज़ मोड में होने पर भी IPv6 कनेक्टिविटी बनाए रखे.
[C-0-5] रेट-लिमिटिंग की वजह से, डिवाइस को IPv6 कनेक्टिविटी नहीं खोनी चाहिए. ऐसा किसी भी IPv6 के साथ काम करने वाले नेटवर्क पर नहीं होना चाहिए. इस नेटवर्क में RA लाइफ़टाइम कम से कम 180 सेकंड का होना चाहिए.
[C-0-6] MUST provide third-party applications with direct IPv6 connectivity to the network when connected to an IPv6 network, without any form of address or port translation happening locally on the device. मैनेज किए गए एपीआई, जैसे कि Socket#getLocalAddress या Socket#getLocalPort और NDK एपीआई, जैसे कि getsockname() या IPV6_PKTINFO, दोनों को आईपी पते और पोर्ट की जानकारी देनी होगी. यह वह आईपी पता और पोर्ट होना चाहिए जिसका इस्तेमाल नेटवर्क पर पैकेट भेजने और पाने के लिए किया जाता है. साथ ही, यह इंटरनेट (वेब) सर्वर को सोर्स आईपी और पोर्ट के तौर पर दिखता है.

IPv6 के लिए ज़रूरी सहायता का लेवल, नेटवर्क टाइप पर निर्भर करता है. इसके बारे में यहां बताया गया है.

अगर डिवाइस में वाई-फ़ाई की सुविधा काम करती है, तो:

[C-1-1] यह ज़रूरी है कि वाई-फ़ाई पर ड्यूअल-स्टैक और सिर्फ़ IPv6 का इस्तेमाल किया जा सके.

अगर डिवाइस में ईथरनेट का इस्तेमाल किया जा सकता है, तो:

[C-2-1] डिवाइस में, ईथरनेट पर ड्यूअल-स्टैक और सिर्फ़ IPv6 का इस्तेमाल करने की सुविधा होनी चाहिए.

अगर डिवाइस में सेल्युलर डेटा का इस्तेमाल किया जा सकता है, तो:

[C-3-1] डिवाइस में, सेल्युलर नेटवर्क पर IPv6 का इस्तेमाल किया जा सकता हो. इसमें IPv6-only और ड्यूअल-स्टैक, दोनों शामिल हैं.

अगर डिवाइस में एक से ज़्यादा नेटवर्क टाइप (जैसे, वाई-फ़ाई और सेल्यूलर डेटा) काम करते हैं, तो:

[C-4-1] जब डिवाइस एक साथ एक से ज़्यादा नेटवर्क टाइप से कनेक्ट होता है, तब हर नेटवर्क पर ऊपर दी गई ज़रूरी शर्तों को एक साथ पूरा करना ज़रूरी है.

7.4.5.3. कैप्टिव पोर्टल

कैप्टिव पोर्टल, ऐसे नेटवर्क को कहते हैं जिसमें इंटरनेट ऐक्सेस करने के लिए साइन इन करना ज़रूरी होता है.

अगर डिवाइस में android.webkit.Webview API को पूरी तरह से लागू किया गया है, तो:

[C-1-1] इसे इंटेंट ACTION_CAPTIVE_PORTAL_SIGN_IN को मैनेज करने के लिए, एक कैप्टिव पोर्टल ऐप्लिकेशन उपलब्ध कराना होगा. साथ ही, System API 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 नेटवर्किंग एपीआई (जैसे, java.net.Socket) और नेटिव एपीआई (जैसे, connect()) डिफ़ॉल्ट रूप से इसी नेटवर्क का इस्तेमाल करें. अगर कोई ऐसा नेटवर्क उपलब्ध है जो इंटरनेट ऐक्सेस देता है, तो उसका इस्तेमाल किया जाना चाहिए.

7.4.6. सिंक करने की सुविधा की सेटिंग

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-1] मास्टर ऑटो-सिंक सेटिंग डिफ़ॉल्ट रूप से चालू होनी चाहिए, ताकि getMasterSyncAutomatically() तरीके से "true" वैल्यू मिले.

7.4.7. डेटा बचाने की सेटिंग

अगर डिवाइस में मीटर वाला कनेक्शन शामिल है, तो ये ज़रूरी हैं:

[C-SR-1] डेटा बचाने की सेटिंग वाला मोड उपलब्ध कराने का सुझाव दिया जाता है.

अगर डिवाइसों में डेटा बचाने वाला मोड उपलब्ध है, तो:

[C-1-1] एसडीके के दस्तावेज़ में बताए गए तरीके के मुताबिक, ConnectivityManager क्लास में मौजूद सभी एपीआई के साथ काम करना ज़रूरी है

अगर डिवाइसों में डेटा सेवर मोड की सुविधा उपलब्ध नहीं है, तो:

[C-2-1] ConnectivityManager.getRestrictBackgroundStatus() के लिए, RESTRICT_BACKGROUND_STATUS_DISABLED वैल्यू रिटर्न होनी चाहिए
[C-2-2] ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED को ब्रॉडकास्ट नहीं करना चाहिए.

7.4.8. सुरक्षा चिप

अगर डिवाइसों में Open Mobile API-capable सुरक्षित एलिमेंट काम करते हैं और उन्हें तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराया जाता है, तो:

[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.4.9. यूडब्ल्यूबी

अगर डिवाइस में 802.1.15.4 के साथ काम करने की सुविधा शामिल है और यह सुविधा तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध है, तो:

[C-1-1] android.uwb में, इससे जुड़ा Android API लागू करना ज़रूरी है.
[C-1-2] हार्डवेयर फ़ीचर फ़्लैग android.hardware.uwb की जानकारी देना ज़रूरी है.
[C-1-3] Android के साथ काम करने वाले सभी ज़रूरी यूडब्ल्यूबी प्रोफ़ाइलों के साथ काम करना ज़रूरी है.
[C-1-4] डिवाइस में, उपयोगकर्ता को यूडब्ल्यूबी रेडियो को चालू/बंद करने का विकल्प देना ज़रूरी है.
[C-1-5] यह ज़रूरी है कि UWB रेडियो का इस्तेमाल करने वाले ऐप्लिकेशन के पास UWB_RANGING अनुमति हो. यह अनुमति, NEARBY_DEVICES अनुमति वाले ग्रुप के तहत मिलती है.
[C-SR-1] हमारा सुझाव है कि ये स्टैंडर्ड ऑर्गनाइज़ेशन के तय किए गए, ज़रूरी शर्तों के मुताबिक काम करने और सर्टिफ़िकेशन से जुड़े टेस्ट पास करें. जैसे, FIRA, CCC, और CSA.
[C-1-6] यह पक्का करना ज़रूरी है कि नॉन-रिफ़्लेक्टिव चेंबर में, एक मीटर की दूरी पर लाइन ऑफ़ साइट एनवायरमेंट में, 95% मेज़रमेंट के लिए दूरी के मेज़रमेंट, +/-15 सेमी के अंदर हों.
[C-1-7] यह पक्का करना ज़रूरी है कि रेफ़रंस डिवाइस से 1 मीटर की दूरी पर, दूरी के मेज़रमेंट का मीडियन [0.75 मीटर, 1.25 मीटर] के बीच हो. इसमें, असल दूरी को DUT के ऊपरी किनारे से मापा जाता है.
[C-SR-2] उपयोगकर्ता की मौजूदगी का पता लगाने की सुविधा के लिए कैलिब्रेशन से जुड़ी ज़रूरी शर्तें में बताए गए मेज़रमेंट सेटअप के चरणों को पूरा करने का सुझाव दिया जाता है.

7.5. कैमरे

अगर डिवाइसों में कम से कम एक कैमरा शामिल है, तो:

[C-1-1] android.hardware.camera.any फ़ीचर फ़्लैग के बारे में एलान करना ज़रूरी है.
[C-1-2] ऐप्लिकेशन को एक साथ 3 RGBA_8888 बिटमैप असाइन करने की सुविधा होनी चाहिए. ये बिटमैप, डिवाइस पर मौजूद सबसे ज़्यादा रिज़ॉल्यूशन वाले कैमरा सेंसर से ली गई इमेज के साइज़ के बराबर होने चाहिए. साथ ही, कैमरा बुनियादी झलक दिखाने और फ़ोटो कैप्चर करने के लिए खुला होना चाहिए.
[C-1-3] यह पक्का करना ज़रूरी है कि पहले से इंस्टॉल किया गया डिफ़ॉल्ट कैमरा ऐप्लिकेशन, इमेज के मेटाडेटा से उपयोगकर्ता की जगह की जानकारी हटा दे. ऐसा तब किया जाना चाहिए, जब ऐप्लिकेशन को MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE या MediaStore.ACTION_VIDEO_CAPTURE इंटेंट हैंडल करने के लिए, इमेज को दूसरे ऐप्लिकेशन को भेजना हो और उस ऐप्लिकेशन के पास ACCESS_FINE_LOCATION न हो.

अगर डिवाइस में कम से कम एक कैमरा मौजूद है और पहले से इंस्टॉल किया गया कैमरा ऐप्लिकेशन, इंटेंट MediaStore.ACTION_MOTION_PHOTO_CAPTURE या MediaStore.ACTION_MOTION_PHOTO_CAPTURE_SECURE को हैंडल करता है, तो:

[C-1-4] यह पक्का करना ज़रूरी है कि इन इंटेंट को हैंडल करते समय, पहले से इंस्टॉल किया गया कैमरा ऐप्लिकेशन, इमेज के मेटाडेटा से उपयोगकर्ता की जगह की जानकारी हटा दे. इसके बाद, इसे उन ऐप्लिकेशन को भेजे जो ACCESS_FINE_LOCATION के साथ काम नहीं करते.
[C-1-5] को यह पक्का करना होगा कि वापस की गई मोशन फ़ोटो, मोशन फ़ोटो फ़ॉर्मैट 1.0 के स्पेसिफ़िकेशन का इस्तेमाल करती हो.

[C-1-6] हर कैमरा डिवाइस टाइप को लेबल करना ज़रूरी है. इसके लिए, CameraCharacteristics.INFO_DEVICE_TYPE फ़ील्ड का इस्तेमाल करके, उसे BUILT_IN, EXTERNAL या VIRTUAL के तौर पर लेबल करें. साथ ही, हर कैमरा आउटपुट फ़्रेम को CaptureResult.INFO_DEVICE_TYPE फ़ील्ड का इस्तेमाल करके लेबल करना होगा.
CaptureResult.INFO_DEVICE_TYPE को सही तरीके से लेबल करना, उन स्थितियों में खास तौर पर ज़रूरी होता है जहां कैमरा आईडी को डाइनैमिक तरीके से किसी दूसरे कैमरा सोर्स पर रीमैप किया जाता है.

अगर डिवाइस में एचडीआर 10-बिट आउटपुट की सुविधा काम करती है, तो:

[C-2-1] यह ज़रूरी है कि 10-बिट आउटपुट की सुविधा देने वाले हर कैमरा डिवाइस के लिए, कम से कम एचएलजी एचडीआर प्रोफ़ाइल काम करे.
[C-2-2] मुख्य रियर या मुख्य फ़्रंट कैमरे के लिए, 10-बिट आउटपुट की सुविधा होनी चाहिए.
[C-SR-1] दोनों प्राइमरी कैमरों के लिए, 10-बिट आउटपुट की सुविधा देने का सुझाव दिया जाता है.
[C-2-3] लॉजिकल कैमरे के सभी BACKWARD_COMPATIBLE-सक्षम फ़िज़िकल सब-कैमरों और लॉजिकल कैमरे के लिए, एक ही तरह की एचडीआर प्रोफ़ाइल इस्तेमाल की जानी चाहिए.

लॉजिकल कैमरा डिवाइसों के लिए, 10-बिट एचडीआर की सुविधा काम करती है. ये डिवाइस android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO एपीआई लागू करते हैं. ये डिवाइस:

[C-3-1] लॉजिकल कैमरे पर मौजूद CONTROL_ZOOM_RATIO कंट्रोल का इस्तेमाल करके, पीछे की ओर मौजूद सभी फ़िज़िकल कैमरों के बीच स्विच करने की सुविधा होनी चाहिए.

7.5.1. पीछे वाला कैमरा

पीछे की ओर मौजूद कैमरा, दुनिया की ओर फ़ेस करने वाला कैमरा होता है. यह डिवाइस के दूसरी ओर मौजूद सीन की इमेज कैप्चर करता है. जैसे, कोई पारंपरिक कैमरा. हैंडहेल्ड डिवाइसों पर, यह कैमरा डिवाइस के डिसप्ले के दूसरी ओर मौजूद होता है.

डिवाइस में सेट किए गए सिस्टम के लिए:

इसमें पीछे की ओर कैमरा होना चाहिए.

अगर डिवाइसों में कम से कम एक रियर-फ़ेसिंग कैमरा शामिल है, तो:

[C-1-1] android.hardware.camera और android.hardware.camera.any फ़ीचर फ़्लैग की जानकारी देना ज़रूरी है.

~~[C-1-2] इसका रिज़ॉल्यूशन कम से कम 2 मेगापिक्सल होना चाहिए.~~

कैमरा ड्राइवर में, हार्डवेयर ऑटो-फ़ोकस या सॉफ़्टवेयर ऑटो-फ़ोकस की सुविधा लागू होनी चाहिए. यह सुविधा, ऐप्लिकेशन सॉफ़्टवेयर के लिए पारदर्शी होनी चाहिए.
इसमें फ़िक्स्ड-फ़ोकस या ईडीओएफ़ (एक्सटेंडेड डेप्थ ऑफ़ फ़ील्ड) हार्डवेयर हो सकता है.
इसमें फ़्लैश शामिल हो सकता है.

अगर कैमरे में फ़्लैश की सुविधा है, तो:

[C-2-1] जब तक ऐप्लिकेशन, Camera.Parameters ऑब्जेक्ट के FLASH_MODE_AUTO या FLASH_MODE_ON एट्रिब्यूट को चालू करके फ़्लैश को साफ़ तौर पर चालू न करे, तब तक कैमरा प्रीव्यू की सुविधा चालू होने पर फ़्लैश लैंप चालू नहीं होना चाहिए.android.hardware.Camera.PreviewCallback ध्यान दें कि यह पाबंदी, डिवाइस में पहले से मौजूद सिस्टम कैमरा ऐप्लिकेशन पर लागू नहीं होती. यह सिर्फ़ Camera.PreviewCallback का इस्तेमाल करने वाले तीसरे पक्ष के ऐप्लिकेशन पर लागू होती है.

7.5.2. सामने वाला कैमरा

सामने की ओर मौजूद कैमरा, उपयोगकर्ता की ओर मौजूद कैमरा होता है. इसका इस्तेमाल आम तौर पर उपयोगकर्ता की इमेज लेने के लिए किया जाता है. जैसे, वीडियो कॉन्फ़्रेंसिंग और इसी तरह के अन्य ऐप्लिकेशन के लिए. हैंडहेल्ड डिवाइसों पर, यह कैमरा डिवाइस की उसी तरफ़ मौजूद होता है जिस तरफ़ डिसप्ले होता है.

डिवाइस में सेट किए गए सिस्टम के लिए:

इसमें सामने की ओर कैमरा हो सकता है.

अगर डिवाइसों में कम से कम एक फ़्रंट-फ़ेसिंग कैमरा शामिल है, तो:

[C-1-1] android.hardware.camera.any और android.hardware.camera.front फ़ीचर फ़्लैग की जानकारी देना ज़रूरी है.
[C-1-2] का रिज़ॉल्यूशन कम से कम वीजीए (640x480 पिक्सल) होना चाहिए.
[C-1-3] Camera API के लिए, सामने वाले कैमरे को डिफ़ॉल्ट कैमरे के तौर पर इस्तेमाल नहीं किया जाना चाहिए. साथ ही, API को इस तरह कॉन्फ़िगर नहीं किया जाना चाहिए कि सामने वाले कैमरे को पीछे वाले डिफ़ॉल्ट कैमरे के तौर पर इस्तेमाल किया जा सके. भले ही, डिवाइस में सिर्फ़ एक कैमरा हो.
[C-1-4] अगर मौजूदा ऐप्लिकेशन ने android.hardware.Camera.setDisplayOrientation() तरीके को कॉल करके, कैमरा डिसप्ले को घुमाने का अनुरोध किया है, तो ऐप्लिकेशन की ओर से तय किए गए ओरिएंटेशन के हिसाब से, कैमरे की झलक को हॉरिज़ॉन्टल तौर पर मिरर किया जाना चाहिए. इसके उलट, अगर मौजूदा ऐप्लिकेशन, android.hardware.Camera.setDisplayOrientation() तरीके को कॉल करके कैमरा डिसप्ले को घुमाने का अनुरोध नहीं करता है, तो डिवाइस के डिफ़ॉल्ट हॉरिज़ॉन्टल ऐक्सिस के साथ झलक को मिरर किया जाना चाहिए.
[C-1-5] कैप्चर की गई फ़ाइनल इमेज या वीडियो स्ट्रीम को, ऐप्लिकेशन के कॉल बैक में वापस नहीं भेजा जाना चाहिए. साथ ही, इसे मीडिया स्टोरेज में सेव नहीं किया जाना चाहिए.
[C-1-6] पोस्टव्यू में दिखने वाली इमेज, कैमरा प्रीव्यू इमेज स्ट्रीम में दिखने वाली इमेज की तरह ही होनी चाहिए.
इसमें पीछे की ओर लगे कैमरे के लिए उपलब्ध सुविधाएं (जैसे, ऑटो-फ़ोकस, फ़्लैश वगैरह) शामिल हो सकती हैं. इनके बारे में सेक्शन 7.5.1 में बताया गया है.

अगर डिवाइसों को उपयोगकर्ता घुमा सकता है (जैसे, ऐक्सिलरोमीटर की मदद से अपने-आप या उपयोगकर्ता के इनपुट से मैन्युअल तरीके से):

[C-2-1] डिवाइस के मौजूदा ओरिएंटेशन के हिसाब से, कैमरे की झलक को हॉरिज़ॉन्टल तौर पर मिरर किया जाना चाहिए.

7.5.3. बाहरी कैमरा

बाहरी कैमरा, ऐसा कैमरा होता है जिसे डिवाइस से किसी भी समय जोड़ा या हटाया जा सकता है. साथ ही, इसे किसी भी दिशा में घुमाया जा सकता है. जैसे, यूएसबी कैमरे.

डिवाइस में सेट किए गए सिस्टम के लिए:

इसमें, किसी ऐसे बाहरी कैमरे के लिए सहायता शामिल हो सकती है जो हमेशा कनेक्ट नहीं होता है.

अगर डिवाइस में बाहरी कैमरे का इस्तेमाल किया जा सकता है, तो:

[C-1-1] प्लैटफ़ॉर्म के फ़ीचर फ़्लैग android.hardware.camera.external और android.hardware camera.any के बारे में एलान करना ज़रूरी है.
[C-1-2] अगर बाहरी कैमरा, यूएसबी होस्ट पोर्ट से कनेक्ट होता है, तो यह ज़रूरी है कि वह यूएसबी वीडियो क्लास (यूवीसी 1.0 या इसके बाद का वर्शन) के साथ काम करता हो.
[C-1-3] यह ज़रूरी है कि डिवाइस, बाहरी कैमरे को कनेक्ट करके, कैमरा सीटीएस टेस्ट पास करे. कैमरे के सीटीएस टेस्ट के बारे में जानकारी, source.android.com पर उपलब्ध है.
इसमें MJPEG जैसे वीडियो कंप्रेस करने के तरीके इस्तेमाल किए जा सकते हैं, ताकि अच्छी क्वालिटी वाली अनकोड की गई स्ट्रीम (यानी कि रॉ या अलग-अलग कंप्रेस की गई पिक्चर स्ट्रीम) को ट्रांसफ़र किया जा सके.
एक से ज़्यादा कैमरे इस्तेमाल किए जा सकते हैं.
कैमरे के आधार पर वीडियो एन्कोडिंग की सुविधा काम कर सकती है.

अगर कैमरे के आधार पर वीडियो एन्कोड करने की सुविधा काम करती है, तो:

[C-2-1] डिवाइस में एक साथ अनकोड की गई / MJPEG स्ट्रीम (QVGA या इससे ज़्यादा रिज़ॉल्यूशन) ऐक्सेस की जा सकती हो.

7.5.4. Camera API का व्यवहार

Android में कैमरे को ऐक्सेस करने के लिए, दो एपीआई पैकेज शामिल हैं. नया android.hardware.camera2 एपीआई, ऐप्लिकेशन को कैमरे का लोअर-लेवल कंट्रोल देता है. इसमें ज़ीरो-कॉपी बर्स्ट/स्ट्रीमिंग फ़्लो और एक्सपोज़र, गेन, व्हाइट बैलेंस गेन, कलर कन्वर्ज़न, नॉइज़ कम करना, इमेज को शार्प करना वगैरह के फ़्रेम-दर-फ़्रेम कंट्रोल शामिल हैं.

Android 5.0 में, पुराने एपीआई पैकेज android.hardware.Camera को 'अब काम नहीं करता' के तौर पर मार्क किया गया है. हालांकि, यह अब भी ऐप्लिकेशन के लिए उपलब्ध होना चाहिए. Android डिवाइसों पर, इस सेक्शन और Android SDK में बताए गए तरीके से, एपीआई का इस्तेमाल जारी रहना चाहिए.

बंद किए गए android.hardware.Camera क्लास और नए android.hardware.camera2 पैकेज में मौजूद सभी सुविधाओं की परफ़ॉर्मेंस और क्वालिटी, दोनों एपीआई में एक जैसी होनी चाहिए. उदाहरण के लिए, एक जैसी सेटिंग के साथ ऑटोफ़ोकस की स्पीड और सटीक होने की क्षमता एक जैसी होनी चाहिए. साथ ही, कैप्चर की गई इमेज की क्वालिटी भी एक जैसी होनी चाहिए. जिन सुविधाओं के लिए, दोनों एपीआई के अलग-अलग सिमैंटिक की ज़रूरत होती है उनके लिए, स्पीड या क्वालिटी का एक जैसा होना ज़रूरी नहीं है. हालांकि, यह ज़रूरी है कि वे ज़्यादा से ज़्यादा एक जैसी हों.

डिवाइसों को, कैमरे से जुड़े एपीआई के लिए यहां बताए गए तरीकों को लागू करना होगा. ऐसा सभी उपलब्ध कैमरों के लिए करना होगा. डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-1] जब किसी ऐप्लिकेशन ने कभी android.hardware.Camera.Parameters.setPreviewFormat(int) को कॉल नहीं किया हो, तब ऐप्लिकेशन कॉलबैक को दिए गए डेटा की झलक दिखाने के लिए, android.hardware.PixelFormat.YCbCr_420_SP का इस्तेमाल करना ज़रूरी है.
[C-0-2] जब कोई ऐप्लिकेशन android.hardware.Camera.PreviewCallback इंस्टेंस रजिस्टर करता है और सिस्टम onPreviewFrame() तरीके को कॉल करता है और प्रीव्यू फ़ॉर्मैट YCbCr_420_SP होता है, तो onPreviewFrame() में पास किया गया byte[] में मौजूद डेटा, NV21 एन्कोडिंग फ़ॉर्मैट में होना चाहिए. इसका मतलब है कि NV21 डिफ़ॉल्ट तौर पर सेट होना चाहिए.
[C-0-3] android.hardware.Camera के लिए, सामने और पीछे वाले, दोनों कैमरों की झलक दिखाने के लिए, YV12 फ़ॉर्मैट (android.graphics.ImageFormat.YV12 कॉन्स्टेंट के तौर पर दिखाया गया है) का इस्तेमाल करना ज़रूरी है. (हार्डवेयर वीडियो एन्कोडर और कैमरा, किसी भी नेटिव पिक्सल फ़ॉर्मैट का इस्तेमाल कर सकते हैं. हालांकि, डिवाइस में YV12 में बदलने की सुविधा होनी चाहिए.)
[C-0-4] यह ज़रूरी है कि android.hardware.camera2 डिवाइसों के लिए, android.media.ImageReader एपीआई के ज़रिए आउटपुट के तौर पर android.hardware.ImageFormat.YUV_420_888 और android.hardware.ImageFormat.JPEG फ़ॉर्मैट काम करें. ये ऐसे डिवाइस होने चाहिए जो android.request.availableCapabilities में REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE की सुविधा का विज्ञापन दिखाते हैं.
[C-0-5] Android SDK के दस्तावेज़ में शामिल पूरा Camera API लागू करना ज़रूरी है. भले ही, डिवाइस में हार्डवेयर ऑटोफ़ोकस या अन्य सुविधाएं शामिल हों या न हों. उदाहरण के लिए, जिन कैमरों में ऑटोफ़ोकस की सुविधा नहीं होती उन्हें भी रजिस्टर किए गए android.hardware.Camera.AutoFocusCallback इंस्टेंस को कॉल करना होगा. भले ही, यह सुविधा ऑटोफ़ोकस न करने वाले कैमरे के लिए काम की न हो. ध्यान दें कि यह सामने की ओर लगे कैमरों पर भी लागू होता है. उदाहरण के लिए, भले ही सामने की ओर लगे ज़्यादातर कैमरे ऑटोफ़ोकस की सुविधा के साथ काम न करते हों, लेकिन एपीआई कॉलबैक को अब भी बताए गए तरीके से "नकली" होना चाहिए.
[C-0-6] android.hardware.Camera.Parameters क्लास और android.hardware.camera2.CaptureRequest क्लास में कॉन्स्टेंट के तौर पर तय किए गए हर पैरामीटर के नाम को पहचानना और उसका पालन करना ज़रूरी है. इसके उलट, डिवाइसों को android.hardware.Camera.setParameters() तरीके से पास किए गए स्ट्रिंग कॉन्स्टेंट को स्वीकार नहीं करना चाहिए या उनकी पहचान नहीं करनी चाहिए. हालांकि, android.hardware.Camera.Parameters पर कॉन्स्टेंट के तौर पर दस्तावेज़ में दिए गए स्ट्रिंग कॉन्स्टेंट को स्वीकार किया जा सकता है. इसका मतलब है कि अगर हार्डवेयर अनुमति देता है, तो डिवाइसों को सभी स्टैंडर्ड कैमरा पैरामीटर के साथ काम करना होगा. साथ ही, उन्हें कस्टम कैमरा पैरामीटर टाइप के साथ काम नहीं करना होगा. उदाहरण के लिए, जिन डिवाइसों में हाई डाइनैमिक रेंज (एचडीआर) इमेजिंग तकनीकों का इस्तेमाल करके इमेज कैप्चर करने की सुविधा काम करती है उनमें कैमरा पैरामीटर Camera.SCENE_MODE_HDR काम करना ज़रूरी है.
[C-0-7] Android SDK में बताए गए तरीके के मुताबिक, android.info.supportedHardwareLevel प्रॉपर्टी के साथ सहायता के सही लेवल की जानकारी देना ज़रूरी है. साथ ही, फ़्रेमवर्क के फ़ीचर फ़्लैग की सही जानकारी देना ज़रूरी है.
[C-0-8] android.request.availableCapabilities प्रॉपर्टी के ज़रिए, android.hardware.camera2 की अलग-अलग कैमरा सुविधाओं के बारे में एलान करना भी ज़रूरी है. साथ ही, सही फ़ीचर फ़्लैग के बारे में एलान करना भी ज़रूरी है. अगर इससे जुड़े किसी भी कैमरे वाले डिवाइस पर यह सुविधा काम करती है, तो फ़ीचर फ़्लैग के बारे में जानकारी देना ज़रूरी है.
[C-0-9] जब भी कैमरे से कोई नई फ़ोटो ली जाती है और उस फ़ोटो की एंट्री मीडिया स्टोर में जोड़ दी जाती है, तब Camera.ACTION_NEW_PICTURE इंटेंट को ब्रॉडकास्ट करना ज़रूरी है.
[C-0-10] जब भी कैमरा कोई नया वीडियो रिकॉर्ड करता है और मीडिया स्टोर में फ़ोटो की एंट्री जोड़ दी जाती है, तब Camera.ACTION_NEW_VIDEO इंटेंट को ब्रॉडकास्ट करना ज़रूरी है.
[C-0-11] android.hardware.Camera एपीआई के ज़रिए ऐक्सेस किए जा सकने वाले सभी कैमरों को android.hardware.camera2 एपीआई के ज़रिए भी ऐक्सेस किया जा सकता हो.
[C-0-12] यह पक्का करना ज़रूरी है कि चेहरे की बनावट में कोई बदलाव न किया गया हो. इसमें चेहरे की बनावट, चेहरे की त्वचा का रंग या चेहरे की त्वचा को मुलायम बनाने के लिए किए गए बदलाव शामिल हैं. हालांकि, इन बदलावों के अलावा और भी बदलाव किए जा सकते हैं. यह बदलाव किसी भी android.hardware.camera2 या android.hardware.Camera एपीआई के लिए किया जा सकता है.
[C-SR-1] अगर किसी डिवाइस में एक-दूसरे के काफ़ी करीब कई RGB कैमरे लगे हैं और वे एक ही दिशा में हैं, तो हमारा सुझाव है कि उस डिवाइस में लॉजिकल कैमरा डिवाइस की सुविधा काम करती हो. इस डिवाइस में CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA सुविधा मौजूद होनी चाहिए. साथ ही, इसमें उस दिशा में लगे सभी RGB कैमरे, फ़िज़िकल सब-डिवाइस के तौर पर शामिल होने चाहिए.

अगर डिवाइस में लागू किए गए सॉफ़्टवेयर, तीसरे पक्ष के ऐप्लिकेशन को मालिकाना हक वाला कैमरा एपीआई उपलब्ध कराते हैं, तो:

[C-1-1] MUST implement such a camera API using android.hardware.camera2 API.
वेंडर, android.hardware.camera2 एपीआई को वेंडर टैग और/या एक्सटेंशन दे सकता है.

अगर डिवाइस बनाने वाली कंपनियां, तीसरे पक्ष के कैमरा पाइपलाइन को अपने डिवाइस में पहले से मौजूद कैमरा पाइपलाइन के बराबर ट्यून करती हैं, तो:

[C-2-1] ro.camera.default_app_social_media_parity_enabled सिस्टम प्रॉपर्टी के बारे में एलान करना ज़रूरी है.

7.5.5. कैमरे का ओरिएंटेशन

अगर डिवाइस में सामने या पीछे की ओर कैमरा लगा है, तो:

[C-1-1] कैमरे को इस तरह से ओरिएंट किया जाना चाहिए कि कैमरे का लंबा डाइमेंशन, स्क्रीन के लंबे डाइमेंशन के साथ अलाइन हो. इसका मतलब है कि जब डिवाइस को लैंडस्केप ओरिएंटेशन में रखा जाता है, तो कैमरों को लैंडस्केप ओरिएंटेशन में इमेज कैप्चर करनी चाहिए. यह डिवाइस के ओरिएंटेशन पर निर्भर नहीं करता. इसका मतलब है कि यह लैंडस्केप-प्राइमरी डिवाइसों के साथ-साथ पोर्ट्रेट-प्राइमरी डिवाइसों पर भी लागू होता है.

इनमें से किसी भी शर्त को पूरा करने वाले डिवाइसों पर, यह ज़रूरी शर्त लागू नहीं होती:
- डिवाइस में फ़ोल्ड की जा सकने वाली या हिंज वाली स्क्रीन जैसे अलग-अलग तरह के डिसप्ले मौजूद हों. साथ ही, डिवाइस को फ़ोल्ड या हिंज करने पर, डिवाइस का ओरिएंटेशन पोर्ट्रेट-प्राइमरी से लैंडस्केप-प्राइमरी (या इसका उल्टा) में बदल जाता हो.
- ऐसे डिवाइस जिनमें स्क्रीन को घुमाने की सुविधा नहीं होती. जैसे, Automotive डिवाइस.

7.6. डिवाइस की मेमोरी और स्टोरेज

7.6.1. कम से कम मेमोरी और स्टोरेज

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-1] इसमें डाउनलोड मैनेजर शामिल होना चाहिए. ऐप्लिकेशन इसका इस्तेमाल, डेटा फ़ाइलें डाउनलोड करने के लिए कर सकते हैं. साथ ही, इनमें कम से कम 100 एमबी की अलग-अलग फ़ाइलें डाउनलोड करने की सुविधा होनी चाहिए. ये फ़ाइलें, डिफ़ॉल्ट "कैश" लोकेशन पर डाउनलोड होनी चाहिए.

7.6.2. ऐप्लिकेशन के लिए शेयर किया गया स्टोरेज

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-1] ऐप्लिकेशन के बीच शेयर किए जाने वाले स्टोरेज की सुविधा उपलब्ध होनी चाहिए. इसे अक्सर "शेयर किया गया बाहरी स्टोरेज", "ऐप्लिकेशन के बीच शेयर किया गया स्टोरेज" या Linux पाथ "/sdcard" के तौर पर भी जाना जाता है.
[C-0-2] इसे डिफ़ॉल्ट रूप से माउंट किए गए शेयर किए गए स्टोरेज के साथ कॉन्फ़िगर किया जाना चाहिए.दूसरे शब्दों में, "आउट ऑफ़ द बॉक्स" होना चाहिए. भले ही, स्टोरेज को इंटरनल स्टोरेज कॉम्पोनेंट या हटाने लायक स्टोरेज मीडियम (जैसे, सिक्योर डिजिटल कार्ड स्लॉट) पर लागू किया गया हो.
[C-0-3] ऐप्लिकेशन को शेयर किए गए स्टोरेज को सीधे तौर पर Linux पाथ sdcard पर माउंट करना होगा. इसके अलावा, sdcard से लेकर माउंट पॉइंट तक Linux सिंबॉलिक लिंक शामिल करना होगा.
[C-0-4] एपीआई लेवल 29 या इसके बाद के वर्शन को टारगेट करने वाले सभी ऐप्लिकेशन के लिए, डिफ़ॉल्ट रूप से स्कोप किए गए स्टोरेज को चालू करना ज़रूरी है. हालांकि, इन स्थितियों में ऐसा नहीं करना होगा:
- जब ऐप्लिकेशन ने अपने मेनिफ़ेस्ट में android:requestLegacyExternalStorage="true" का अनुरोध किया हो.
[C-0-5] MediaStore के ज़रिए ऐक्सेस की गई मीडिया फ़ाइलों में मौजूद जगह की जानकारी वाले मेटाडेटा को छिपाना ज़रूरी है. जैसे, जीपीएस Exif टैग. हालांकि, ऐसा तब नहीं किया जाना चाहिए, जब ऐक्सेस करने वाले ऐप्लिकेशन के पास ACCESS_MEDIA_LOCATION की अनुमति हो.

डिवाइस में सेट किए गए सिस्टम, ऊपर दी गई ज़रूरी शर्तों को पूरा कर सकते हैं. इसके लिए, इनमें से किसी एक तरीके का इस्तेमाल किया जा सकता है:

उपयोगकर्ता के लिए उपलब्ध रिमूवेबल स्टोरेज, जैसे कि सिक्योर डिजिटल (एसडी) कार्ड स्लॉट.
Android ओपन सोर्स प्रोजेक्ट (AOSP) में लागू की गई, इंटरनल (हटाने योग्य नहीं) स्टोरेज का एक हिस्सा.

अगर डिवाइस में ऊपर दी गई ज़रूरी शर्तों को पूरा करने के लिए, हटाए जा सकने वाले स्टोरेज का इस्तेमाल किया जाता है, तो:

[C-1-1] अगर स्लॉट में कोई स्टोरेज मीडियम नहीं डाला गया है, तो ऐप्लिकेशन को उपयोगकर्ता को चेतावनी देने के लिए, टोस्ट या पॉप-अप यूज़र इंटरफ़ेस लागू करना होगा.
[C-1-2] इसमें FAT फ़ॉर्मैट वाला स्टोरेज मीडियम (जैसे, एसडी कार्ड) शामिल होना चाहिए या बॉक्स और खरीदारी के समय उपलब्ध अन्य सामान पर यह जानकारी दिखनी चाहिए कि स्टोरेज मीडियम को अलग से खरीदना होगा.

अगर डिवाइस, ऊपर दी गई ज़रूरी शर्तों को पूरा करने के लिए, न हटाई जा सकने वाली स्टोरेज का कुछ हिस्सा इस्तेमाल करते हैं, तो:

संगठन में काम करने वालों के साथ शेयर किए गए ऐप्लिकेशन के लिए, इंटरनल ऐप्लिकेशन शेयर किए गए स्टोरेज के AOSP वर्शन का इस्तेमाल करना चाहिए.
स्टोरेज स्पेस को ऐप्लिकेशन के निजी डेटा के साथ शेयर कर सकता है.

अगर डिवाइस में यूएसबी पोर्ट है और वह यूएसबी पेरिफ़रल मोड के साथ काम करता है, तो:

[C-3-1] होस्ट कंप्यूटर से, ऐप्लिकेशन के शेयर किए गए स्टोरेज में मौजूद डेटा को ऐक्सेस करने का तरीका उपलब्ध कराना ज़रूरी है.
Android की मीडिया स्कैनर सेवा और android.provider.MediaStore के ज़रिए, दोनों स्टोरेज पाथ से कॉन्टेंट को साफ़ तौर पर दिखाना चाहिए.
यूएसबी मास स्टोरेज का इस्तेमाल किया जा सकता है. हालांकि, इस ज़रूरी शर्त को पूरा करने के लिए, मीडिया ट्रांसफ़र प्रोटोकॉल का इस्तेमाल करना चाहिए.

अगर डिवाइस में यूएसबी पोर्ट है, जिसमें यूएसबी पेरिफ़ेरल मोड की सुविधा है और मीडिया ट्रांसफ़र प्रोटोकॉल काम करता है, तो:

यह रेफ़रंस Android MTP होस्ट, Android File Transfer के साथ काम करना चाहिए.
इसे यूएसबी डिवाइस क्लास 0x00 की रिपोर्ट देनी चाहिए.
'एमटीपी' के यूएसबी इंटरफ़ेस का नाम रिपोर्ट करना चाहिए.

7.6.3. एडॉप्टेबल स्टोरेज

अगर डिवाइस को टीवी की तरह एक जगह पर नहीं रखा जाता है, तो डिवाइसों को इस तरह से लागू किया जाता है:

[C-SR-1] हमारा सुझाव है कि अडॉप्टेबल स्टोरेज को लंबे समय तक इस्तेमाल करने के लिए, किसी ऐसी जगह पर रखें जहां वह सुरक्षित रहे. ऐसा इसलिए, क्योंकि गलती से स्टोरेज को डिस्कनेक्ट करने पर, डेटा मिट सकता है या खराब हो सकता है.

अगर हटाने योग्य स्टोरेज डिवाइस का पोर्ट, लंबे समय तक एक ही जगह पर रहता है, तो डिवाइसों में ये पोर्ट इस तरह से लगाए जाते हैं:

[C-SR-2] एडॉप्टेबल स्टोरेज को लागू करने का सुझाव दिया जाता है.

7.7. यूएसबी

परिभाषाएं

यूएसबी होस्ट मोड तब होता है, जब डिवाइस को यूएसबी होस्ट के तौर पर इस्तेमाल किया जाता है. यह बस को पावर देता है और पेरिफ़ेरल से कम्यूनिकेट करता है.
यूएसबी डिवाइस मोड को यूएसबी पेरिफ़ेरल मोड भी कहा जाता है. इस मोड में, डिवाइस को यूएसबी पेरिफ़ेरल के तौर पर इस्तेमाल किया जाता है. यह अपस्ट्रीम पोर्ट के ज़रिए होस्ट से कनेक्ट होता है और होस्ट से मिले अनुरोधों का जवाब देता है.
यूएसबी पोर्ट को यूएसबी कनेक्टिविटी देने वाले एक तरीके के तौर पर तय किया जाता है. यह एक फ़िज़िकल यूएसबी रिसेप्टेकल या नॉन-स्टैंडर्ड इंटरफ़ेस (उदाहरण के लिए, पोगो पिन) हो सकता है.

अगर डिवाइसों में यूएसबी पोर्ट है, तो:

उसमें यूएसबी डिवाइस मोड की सुविधा होनी चाहिए.
डिवाइस में यूएसबी होस्ट मोड की सुविधा होनी चाहिए.
यूएसबी से डेटा सिग्नल भेजने की प्रोसेस को बंद करने की सुविधा होनी चाहिए.

7.7.1. यूएसबी डिवाइस मोड

अगर डिवाइस में यूएसबी पोर्ट है और वह पेरिफ़रल डिवाइस मोड के साथ काम करता है, तो:

[C-1-1] पोर्ट को ऐसे यूएसबी होस्ट से कनेक्ट किया जा सकता हो जिसमें स्टैंडर्ड टाइप-ए या टाइप-सी यूएसबी पोर्ट हो.
[C-1-2] iSerialNumber के ज़रिए, यूएसबी स्टैंडर्ड डिवाइस डिस्क्रिप्टर में iSerialNumber की सही वैल्यू रिपोर्ट करना ज़रूरी है.android.os.Build.SERIAL
[C-1-3] टाइप-सी रजिस्टर के स्टैंडर्ड के मुताबिक, 1.5A और 3.0A चार्जर का पता लगाना ज़रूरी है. साथ ही, अगर वे टाइप-सी यूएसबी के साथ काम करते हैं, तो विज्ञापन में हुए बदलावों का पता लगाना ज़रूरी है.

[C-SR-1] पोर्ट में माइक्रो-बी, माइक्रो-एबी या टाइप-सी यूएसबी फ़ॉर्म फ़ैक्टर का इस्तेमाल किया जाना चाहिए. मौजूदा और नए Android डिवाइसों के लिए, इन ज़रूरी शर्तों को पूरा करना बेहद ज़रूरी है. इससे वे आने वाले समय में, प्लैटफ़ॉर्म के नए वर्शन पर अपग्रेड कर पाएंगे.

[C-SR-2] पोर्ट को डिवाइस के निचले हिस्से में (नैचुरल ओरिएंटेशन के हिसाब से) होना चाहिए. इसके अलावा, सभी ऐप्लिकेशन (होम स्क्रीन भी शामिल है) के लिए सॉफ़्टवेयर स्क्रीन रोटेशन की सुविधा चालू होनी चाहिए, ताकि डिवाइस को पोर्ट के निचले हिस्से में रखने पर डिसप्ले सही तरीके से काम करे. मौजूदा और नए Android डिवाइसों के लिए, इन ज़रूरी शर्तों को पूरा करना बेहद ज़रूरी है. इससे वे आने वाले समय में प्लैटफ़ॉर्म के नए वर्शन पर अपग्रेड कर पाएंगे.
[C-SR-3] में, यूएसबी बैटरी चार्जिंग स्पेसिफ़िकेशन, रिवीज़न 1.2 में बताए गए HS चिरप और ट्रैफ़िक के दौरान, 1.5 A करंट लेने की सुविधा होनी चाहिए. हमारा सुझाव है कि मौजूदा और नए Android डिवाइसों पर ये ज़रूरी शर्तें पूरी की जाएं, ताकि उन्हें आने वाले समय में प्लैटफ़ॉर्म के नए वर्शन पर अपग्रेड किया जा सके.
[C-SR-4] हमारा सुझाव है कि मालिकाना हक वाले चार्जिंग के ऐसे तरीकों का इस्तेमाल न करें जिनसे Vbus वोल्टेज, डिफ़ॉल्ट लेवल से ज़्यादा हो जाता है या सिंक/सोर्स की भूमिकाएं बदल जाती हैं. ऐसा इसलिए, क्योंकि इससे यूएसबी पावर डिलीवरी के स्टैंडर्ड तरीकों के साथ काम करने वाले चार्जर या डिवाइसों के साथ इंटरऑपरेबिलिटी की समस्याएं हो सकती हैं. हालांकि, इसे "बेहद ज़रूरी" के तौर पर बताया गया है, लेकिन आने वाले समय में Android के वर्शन में, हम सभी टाइप-सी डिवाइसों के लिए यह ज़रूरी कर सकते हैं कि वे स्टैंडर्ड टाइप-सी चार्जर के साथ पूरी तरह से काम करें.
[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 USB होस्ट एपीआई को लागू करे. साथ ही, यह भी ज़रूरी है कि वह हार्डवेयर की सुविधा android.hardware.usb.host के साथ काम करने की जानकारी दे.
[C-1-2] स्टैंडर्ड यूएसबी सहायक डिवाइसों को कनेक्ट करने की सुविधा उपलब्ध होनी चाहिए. इनमें से कोई एक होना ज़रूरी है:
- डिवाइस में यूएसबी टाइप-सी पोर्ट होना चाहिए. इसके अलावा, डिवाइस के साथ ऐसी केबल होनी चाहिए जो डिवाइस के मालिकाना हक वाले पोर्ट को स्टैंडर्ड यूएसबी टाइप-सी पोर्ट (यूएसबी टाइप-सी डिवाइस) से कनेक्ट कर सके.
- डिवाइस में यूएसबी टाइप-ए पोर्ट होना चाहिए या डिवाइस के साथ ऐसी केबल होनी चाहिए जो डिवाइस के मालिकाना हक वाले पोर्ट को स्टैंडर्ड यूएसबी टाइप-ए पोर्ट में बदलती हो.
- डिवाइस पर मौजूद माइक्रो-एबी यूएसबी पोर्ट. इसके साथ एक ऐसी केबल होनी चाहिए जो स्टैंडर्ड यूएसबी टाइप-ए पोर्ट के साथ काम करती हो.
[C-1-3] डिवाइस के साथ, यूएसबी टाइप-ए या माइक्रो-एबी पोर्ट को यूएसबी टाइप-सी पोर्ट (रिसेप्टेकल) में बदलने वाला अडैप्टर शिप नहीं किया जाना चाहिए.
[C-SR-1] Android SDK के दस्तावेज़ में बताए गए तरीके से, यूएसबी ऑडियो क्लास को लागू करने का सुझाव दिया जाता है.
होस्ट मोड में कनेक्ट किए गए यूएसबी पेरिफ़ेरल डिवाइस को चार्ज करने की सुविधा होनी चाहिए. साथ ही, यूएसबी टाइप-सी कनेक्टर के लिए, यूएसबी टाइप-सी केबल और कनेक्टर स्पेसिफ़िकेशन, वर्शन 1.2 के टर्मिनेशन पैरामीटर सेक्शन में बताए गए तरीके के मुताबिक, कम से कम 1.5 ऐंपियर के सोर्स करंट का विज्ञापन करना चाहिए. इसके अलावा, माइक्रो-एबी कनेक्टर के लिए, यूएसबी बैटरी चार्जिंग स्पेसिफ़िकेशन, वर्शन 1.2 में बताए गए तरीके के मुताबिक, चार्जिंग डाउनस्ट्रीम पोर्ट (सीडीपी) के आउटपुट करंट रेंज का इस्तेमाल करना चाहिए.
यूएसबी टाइप-सी स्टैंडर्ड को लागू करना और उसके साथ काम करना चाहिए.

अगर डिवाइस में होस्ट मोड और यूएसबी ऑडियो क्लास के साथ काम करने वाला यूएसबी पोर्ट शामिल है, तो:

[C-2-1] यूएसबी एचआईडी क्लास के साथ काम करना ज़रूरी है.
[C-2-2] यूएसबी एचआईडी यूसेज टेबल और वॉइस कमांड यूसेज रिक्वेस्ट में बताए गए, यहां दिए गए एचआईडी डेटा फ़ील्ड का पता लगाने और उन्हें KeyEvent कॉन्सटेंट के साथ मैप करने की सुविधा होनी चाहिए. ये कॉन्सटेंट यहां दिए गए हैं:
- इस्तेमाल की जानकारी वाला पेज (0xC) इस्तेमाल की जानकारी वाला आईडी (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
- Usage Page (0xC) Usage ID (0x0E9): KEYCODE_VOLUME_UP
- Usage Page (0xC) Usage ID (0x0EA): KEYCODE_VOLUME_DOWN
- इस्तेमाल से जुड़ा पेज (0xC) इस्तेमाल का आईडी (0x0CF): KEYCODE_VOICE_ASSIST

अगर डिवाइस में होस्ट मोड और स्टोरेज ऐक्सेस फ़्रेमवर्क (एसएएफ़) के साथ काम करने वाला यूएसबी पोर्ट शामिल है, तो:

[C-3-1] यह ज़रूरी है कि डिवाइस, रिमोट से कनेक्ट किए गए किसी भी एमटीपी (मीडिया ट्रांसफर प्रोटोकॉल) डिवाइस को पहचान सके. साथ ही, ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, और ACTION_CREATE_DOCUMENT इंटेंट के ज़रिए, डिवाइस के कॉन्टेंट को ऐक्सेस किया जा सके.

अगर डिवाइस में होस्ट मोड और यूएसबी टाइप-सी के साथ काम करने वाला यूएसबी पोर्ट शामिल है, तो:

[C-4-1] यूएसबी टाइप-सी के स्पेसिफ़िकेशन (सेक्शन 4.5.1.3.3) में बताई गई ड्यूअल रोल पावर (डीआरपी) की सुविधा लागू करना ज़रूरी है. डीआरपी पोर्ट वाले ऐसे डिवाइसों पर जिनमें 3.5 मि॰मी॰ का ऑडियो जैक होता है, यूएसबी पावर सिंक का पता लगाने की सुविधा (होस्ट मोड) डिफ़ॉल्ट रूप से बंद हो सकती है. हालांकि, उपयोगकर्ता के पास इसे चालू करने का विकल्प होना चाहिए.
[C-SR-2] DisplayPort का इस्तेमाल करने का सुझाव दिया जाता है.
- यूएसबी सुपरस्पीड डेटा ट्रांसफ़र करने की सुविधा होनी चाहिए.
- यह सुझाव दिया जाता है कि डेटा और पावर रोल स्वैपिंग के लिए, Power Delivery का इस्तेमाल किया जाए.
[C-SR-3] यह सुझाव दिया जाता है कि यूएसबी टाइप-सी केबल और कनेक्टर स्पेसिफ़िकेशन के वर्शन 1.2 के अपेंडिक्स A में बताए गए तरीके के मुताबिक, ऑडियो अडैप्टर ऐक्सेसरी मोड काम न करे.
डिवाइस के फ़ॉर्म फ़ैक्टर के लिए सबसे सही Try.* मॉडल को लागू करना चाहिए. उदाहरण के लिए, हाथ में पकड़कर इस्तेमाल किए जाने वाले डिवाइस में Try.SNK मॉडल लागू होना चाहिए.

7.7.3. यूएसबी पावर डिलीवरी

अगर डिवाइस में यूएसबी टाइप-सी पोर्ट शामिल है, तो:

[C-SR-1] कर्नेल के यूएसबी टाइप-सी कनेक्टर क्लास को लागू करने का सुझाव दिया जाता है. साथ ही, यूएसबी टाइप-सी कनेक्शन, पावर, और डेटा की भूमिकाओं के बारे में बताने वाले ज़रूरी नोड को लागू करने का सुझाव दिया जाता है. इसे लागू करने से जुड़ी जानकारी के लिए, Android USB Type-C का दस्तावेज़ देखें.

अगर डिवाइस में यूएसबी टाइप-सी पोर्ट है और वह पावर डिलीवरी की सुविधा के साथ काम करता है, तो:

[C-SR-2] यूएसबी पावर डिलीवरी के बारे में बताने वाले सभी नोड लागू करने का सुझाव दिया जाता है. लागू करने से जुड़ी जानकारी के लिए, Android USB PD का दस्तावेज़ देखें.

अगर डिवाइस में यूएसबी टाइप-सी पोर्ट है और वह वैकल्पिक मोड के साथ काम करता है, तो:

[C-SR-3] कर्नेल के यूएसबी टाइप-सी कनेक्टर क्लास के वैकल्पिक मोड और पहचान से जुड़ी प्रॉपर्टी लागू करने का सुझाव दिया जाता है. इसे लागू करने से जुड़ी जानकारी के लिए, Android USB Type-C का दस्तावेज़ देखें.

अगर डिवाइस में यूएसबी टाइप-सी पोर्ट है और Thunderbolt 3 के ऑल्टरनेट मोड के साथ काम करता है, तो:

[C-SR-4] टाइप-सी कनेक्टर क्लास के ज़रिए, मौजूदा ऑल्टरनेट मोड को बदलने की सुविधा लागू करने का सुझाव दिया जाता है.

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. ऑडियो आउटपुट

अगर डिवाइसों में स्पीकर या ऑडियो/मल्टीमीडिया आउटपुट पोर्ट शामिल हैं, ताकि ऑडियो आउटपुट पेरिफ़ेरल का इस्तेमाल किया जा सके. जैसे, चार कंडक्टर वाला 3.5 मि॰मी॰ ऑडियो जैक या यूएसबी ऑडियो क्लास का इस्तेमाल करने वाला यूएसबी होस्ट मोड पोर्ट, तो:

[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] कम से कम एक ऑडियो पोर्ट को 4 कंडक्टर वाला 3.5 मि॰मी॰ ऑडियो जैक बनाने का सुझाव दिया जाता है.

अगर डिवाइसों में चार कंडक्टर वाला 3.5 मि॰मी॰ का ऑडियो जैक है, तो:

[C-1-1] ज़रूरी है कि डिवाइस, माइक्रोफ़ोन वाले स्टीरियो हेडसेट और स्टीरियो हेडफ़ोन पर ऑडियो चलाने की सुविधा देता हो.
[C-1-2] ज़रूरी है कि डिवाइस, CTIA पिन-आउट ऑर्डर वाले टीआरआरएस ऑडियो प्लग के साथ काम करता हो.
[C-1-3] ऑडियो प्लग पर माइक्रोफ़ोन और ग्राउंड कंडक्टर के बीच, एक जैसे इंपीडेंस की इन तीन रेंज के लिए, कीकोड का पता लगाना और उन्हें मैप करना ज़रूरी है:
- 70 ओम या उससे कम: KEYCODE_HEADSETHOOK
- 210-290 ओम: KEYCODE_VOLUME_UP
- 360-680 ओम: KEYCODE_VOLUME_DOWN
[C-1-4] प्लग डालने पर, ACTION_HEADSET_PLUG ट्रिगर होना चाहिए. हालांकि, ऐसा तब ही होना चाहिए, जब प्लग के सभी संपर्क, जैक के अपने-अपने सेगमेंट को छू रहे हों.
[C-1-5] 32 ओम के स्पीकर इंपीडेंस पर, कम से कम 150mV ± 10% का आउटपुट वोल्टेज देने में सक्षम होना चाहिए.
[C-1-6] माइक्रोफ़ोन का बायस वोल्टेज 1.8V से 2.9V के बीच होना चाहिए.
[C-1-7] ऑडियो प्लग पर माइक्रोफ़ोन और ग्राउंड कंडक्टर के बीच, इस रेंज के बराबर इंपीडेंस के लिए कीकोड का पता लगाना और उसे मैप करना ज़रूरी है:
- 110-180 ओम: KEYCODE_VOICE_ASSIST
[C-SR-2] ओएमटीपी पिन-आउट ऑर्डर के साथ ऑडियो प्लग इस्तेमाल करने का सुझाव दिया जाता है.
[C-SR-3] यह सुझाव दिया जाता है कि स्टीरियो हेडसेट से ऑडियो रिकॉर्डिंग की सुविधा उपलब्ध कराई जाए.

अगर डिवाइसों में चार कंडक्टर वाला 3.5 मि॰मी॰ का ऑडियो जैक है और वे माइक्रोफ़ोन के साथ काम करते हैं, तो android.intent.action.HEADSET_PLUG को ब्रॉडकास्ट करते समय, माइक्रोफ़ोन की अतिरिक्त वैल्यू को 1 पर सेट किया जाता है. ऐसे में:

[C-2-1] प्लग इन किए गए ऑडियो ऐक्सेसरी पर माइक्रोफ़ोन का पता लगाने की सुविधा काम करनी चाहिए.

7.8.2.2. डिजिटल ऑडियो पोर्ट

डिवाइस से जुड़ी ज़रूरी शर्तों के लिए, सेक्शन 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 डीबी से ज़्यादा कम नहीं होना चाहिए.
[C-1-2] 18.5 किलोहर्ट्ज़ से 20 किलोहर्ट्ज़ की फ़्रीक्वेंसी वाले माइक्रोफ़ोन के लिए, अनवेटेड सिग्नल से नॉइज़ का अनुपात 50 dB से कम नहीं होना चाहिए. यह अनुपात, -26 dBFS पर 19 किलोहर्ट्ज़ टोन के लिए होना चाहिए.

अगर PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND की वैल्यू "true" है, तो:

[C-2-1] स्पीकर का 18.5 किलोहर्ट्ज़ से 20 किलोहर्ट्ज़ के बीच का औसत रिस्पॉन्स, 2 किलोहर्ट्ज़ पर मौजूद रिस्पॉन्स से 40 डेसिबल से ज़्यादा कम नहीं होना चाहिए.

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 को लागू करना ज़रूरी है. साथ ही, उपलब्ध EGL एक्सटेंशन की सूची में एक्सटेंशन दिखाना ज़रूरी है.
[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 कम से कम 2 हो.
[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 के साथ इस्तेमाल के फ़्लैग AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT के किसी भी कॉम्बिनेशन को सपोर्ट करना ज़रूरी है: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
[C-SR-5] यह सुझाव दिया जाता है कि AHardwareBuffers को एक से ज़्यादा लेयर और C-1-10 में बताए गए फ़्लैग और फ़ॉर्मैट के साथ असाइन किया जाए.
[C-1-11] कम से कम 3840 x 2160 पिक्सल के रिज़ॉल्यूशन और 30 एफ़पीएस पर H.264 डिकोडिंग की सुविधा होनी चाहिए. साथ ही, इसे औसतन 40 एमबीपीएस पर कंप्रेस किया जाना चाहिए. यह 30 एफ़पीएस पर 1920 x 1080 पिक्सल के रिज़ॉल्यूशन वाले चार इंस्टेंस (10 एमबीपीएस) या 60 एफ़पीएस पर 1920 x 1080 पिक्सल के रिज़ॉल्यूशन वाले दो इंस्टेंस (20 एमबीपीएस) के बराबर है.
[C-1-12] इसमें HEVC और VP9 को सपोर्ट करने की सुविधा होनी चाहिए. साथ ही, यह 30 एफ़पीएस पर कम से कम 1920 x 1080 पिक्सल के वीडियो को डिकोड कर सके. इस वीडियो को औसतन 10 एमबीपीएस पर कंप्रेस किया गया हो. इसके अलावा, यह 30 एफ़पीएस पर 3840 x 2160 पिक्सल के वीडियो को डिकोड कर सके. इस वीडियो को 20 एमबीपीएस पर कंप्रेस किया गया हो. यह 30 एफ़पीएस पर 1920 x 1080 पिक्सल के चार वीडियो को डिकोड करने के बराबर है. इन वीडियो को 5 एमबीपीएस पर कंप्रेस किया गया हो.
[C-1-13] HardwarePropertiesManager.getDeviceTemperatures एपीआई के साथ काम करना चाहिए और त्वचा के तापमान की सटीक वैल्यू दिखानी चाहिए.
[C-1-14] में एक एम्बेड की गई स्क्रीन होनी चाहिए. साथ ही, इसका रिज़ॉल्यूशन कम से कम 1920 x 1080 होना चाहिए.
[C-SR-6] इनका डिसप्ले रिज़ॉल्यूशन कम से कम 2560 x 1440 होना चाहिए.
[C-1-15] VR मोड में, डिसप्ले कम से कम 60 हर्ट्ज़ पर अपडेट होना चाहिए.
[C-1-17] डिसप्ले में लो-पर्सिस्टेंस मोड काम करना चाहिए. इसमें पिक्सल के बंद होने में लगने वाला समय, पांच मिलीसेकंड से कम होना चाहिए. पिक्सल के बंद होने में लगने वाले समय को पर्सिस्टेंस कहा जाता है.
[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] MUST have end-to-end motion to photon latency not higher than 28 milliseconds.
[C-SR-9] यह सुझाव दिया जाता है कि मोशन से फ़ोटॉन तक की एंड-टू-एंड लेटेन्सी 20 मिलीसेकंड से ज़्यादा न हो.
[C-1-23] इसमें पहले फ़्रेम का रेशियो होना चाहिए. यह रेशियो, काले से सफ़ेद रंग में ट्रांज़िशन होने के बाद पहले फ़्रेम के पिक्सल की चमक और स्थिर स्थिति में सफ़ेद पिक्सल की चमक के बीच का रेशियो होता है. यह रेशियो कम से कम 85% होना चाहिए.
[C-SR-10] यह सुझाव दिया जाता है कि पहले फ़्रेम का अनुपात कम से कम 90% हो.
यह फ़ोरग्राउंड ऐप्लिकेशन को एक खास कोर उपलब्ध करा सकता है. साथ ही, यह Process.getExclusiveCores एपीआई के साथ काम कर सकता है, ताकि टॉप फ़ोरग्राउंड ऐप्लिकेशन के लिए खास तौर पर उपलब्ध सीपीयू कोर की संख्या दिखाई जा सके.

अगर एक्सक्लूसिव कोर की सुविधा काम करती है, तो कोर:

[C-2-1] इस पर किसी भी अन्य यूज़रस्पेस प्रोसेस को चलने की अनुमति नहीं होनी चाहिए (ऐप्लिकेशन के इस्तेमाल किए गए डिवाइस ड्राइवर को छोड़कर). हालांकि, यह ज़रूरी होने पर कुछ कर्नेल प्रोसेस को चलने की अनुमति दे सकता है.

7.10. हैप्टिक

हाथ में पकड़कर या पहनकर इस्तेमाल किए जाने वाले डिवाइसों में, सामान्य मकसद के लिए हैप्टिक ऐक्चुएटर शामिल हो सकता है. यह ऐक्चुएटर, ऐप्लिकेशन के लिए उपलब्ध होता है. इसका इस्तेमाल, रिंगटोन, अलार्म, सूचनाओं के ज़रिए ध्यान खींचने के साथ-साथ सामान्य टच फ़ीडबैक के लिए किया जा सकता है.

अगर डिवाइसों में इस तरह का सामान्य मकसद वाला हैप्टिक ऐक्चुएटर शामिल नहीं है, तो:

[7.10/C] Vibrator.hasVibrator() के लिए, 'गलत' वैल्यू दिखानी चाहिए.

अगर डिवाइसों में कम से कम एक ऐसा हैप्टिक ऐक्चुएटर शामिल है जिसका इस्तेमाल सामान्य तौर पर किया जाता है, तो:

[C-1-1] Vibrator.hasVibrator() के लिए, true वैल्यू रिटर्न होनी चाहिए.
इसमें ईआरएम (एक्सेंट्रिक रोटेटिंग मास) हैप्टिक ऐक्चुएटर (वाइब्रेटर) का इस्तेमाल नहीं किया जाना चाहिए.
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).
क्लियर हैप्टिक के लिए, android.os.VibrationEffect में सभी सार्वजनिक कॉन्स्टेंट लागू किए जाने चाहिए. जैसे, (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK, और EFFECT_DOUBLE_CLICK). साथ ही, रिच हैप्टिक के लिए, android.os.VibrationEffect.Composition में सभी सार्वजनिक PRIMITIVE_* कॉन्स्टेंट लागू किए जाने चाहिए. जैसे, (CLICK, TICK, LOW_TICK, QUICK_FALL, QUICK_RISE, SLOW_RISE, SPIN, THUD). इनमें से कुछ प्रिमिटिव, जैसे कि LOW_TICK और SPIN सिर्फ़ तब लागू किए जा सकते हैं, जब वाइब्रेटर कम फ़्रीक्वेंसी को सपोर्ट कर सकता हो.
android.view.HapticFeedbackConstants में, सार्वजनिक कॉन्स्टेंट को मैप करने के लिए दिए गए दिशा-निर्देशों का पालन करना चाहिए. ऐसा, सुझाए गए android.os.VibrationEffect कॉन्स्टेंट के साथ-साथ, उनसे जुड़े ऐम्प्लिट्यूड के संबंधों के लिए किया जाना चाहिए.
इन लिंक किए गए हैप्टिक कॉन्स्टेंट मैपिंग का इस्तेमाल करना चाहिए.
उसे createOneShot() और createWaveform() एपीआई के लिए, क्वालिटी का आकलन करना चाहिए.
उन्हें यह पुष्टि करनी चाहिए कि सार्वजनिक android.os.Vibrator.hasAmplitudeControl() एपीआई के नतीजे में, उनके वाइब्रेटर की क्षमताओं के बारे में सही जानकारी दी गई हो.
उसे android.os.Vibrator.hasAmplitudeControl() चलाकर, एंप्लीट्यूड स्केलेबिलिटी की क्षमताओं की पुष्टि करनी चाहिए.

अगर डिवाइस में हैप्टिक कॉन्स्टेंट मैपिंग का इस्तेमाल किया जाता है, तो:

android.os.Vibrator.areAllEffectsSupported() और android.os.Vibrator.arePrimitivesSupported() एपीआई चलाकर, लागू करने की स्थिति की पुष्टि करनी चाहिए.
हैप्टिक कॉन्स्टेंट के लिए, क्वालिटी का आकलन करना ज़रूरी है.
उसे कॉन्स्टेंट के लिए लागू करने से जुड़ी गाइडलाइन में बताए गए तरीके के मुताबिक, उन प्रिमिटिव के लिए फ़ॉलबैक कॉन्फ़िगरेशन की पुष्टि करनी चाहिए जो काम नहीं करती हैं. साथ ही, अगर ज़रूरी हो, तो उसे अपडेट करना चाहिए.
उसे फ़ॉलबैक सहायता देनी चाहिए, ताकि यहां बताए गए तरीके से, फ़ेल होने के जोखिम को कम किया जा सके.

7.11. मीडिया परफ़ॉर्मेंस क्लास

डिवाइस पर लागू किए गए मीडिया परफ़ॉर्मेंस क्लास की जानकारी, android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS एपीआई से मिल सकती है. मीडिया परफ़ॉर्मेंस क्लास की ज़रूरी शर्तें, Android के हर वर्शन के लिए तय की गई हैं. ये शर्तें, R (वर्शन 30) से शुरू होने वाले वर्शन के लिए लागू होती हैं. खास वैल्यू 0 से पता चलता है कि डिवाइस, मीडिया परफ़ॉर्मेंस क्लास का नहीं है.

अगर डिवाइसों में लागू किए गए android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS के लिए, शून्य के अलावा कोई और वैल्यू मिलती है, तो:

[C-1-1] कम से कम android.os.Build.VERSION_CODES.R की वैल्यू रिटर्न होनी चाहिए.
[C-1-2] इसे हाथ में पकड़कर इस्तेमाल किए जाने वाले डिवाइस पर लागू किया जाना चाहिए.
[C-1-3] सेक्शन 2.2.7 में बताई गई "मीडिया परफ़ॉर्मेंस क्लास" की सभी ज़रूरी शर्तें पूरी करनी होंगी.

दूसरे शब्दों में कहें, तो Android T में मीडिया परफ़ॉर्मेंस क्लास को सिर्फ़ T, S या R वर्शन वाले हैंडहेल्ड डिवाइसों के लिए तय किया गया है.

डिवाइस के हिसाब से ज़रूरी शर्तें जानने के लिए, सेक्शन 2.2.7 देखें.

8. परफ़ॉर्मेंस और पावर

उपयोगकर्ता अनुभव के लिए, परफ़ॉर्मेंस और पावर से जुड़ी कुछ ज़रूरी शर्तें पूरी करना ज़रूरी है. साथ ही, इससे डेवलपर की उन बुनियादी मान्यताओं पर असर पड़ता है जो वे ऐप्लिकेशन डेवलप करते समय रखते हैं.

8.1. उपयोगकर्ता अनुभव में एकरूपता

अगर ऐप्लिकेशन और गेम के लिए, फ़्रेम रेट और जवाब देने के समय को एक जैसा बनाए रखने के लिए कुछ ज़रूरी शर्तें पूरी की जाती हैं, तो उपयोगकर्ता को बेहतर यूज़र इंटरफ़ेस (यूआई) दिया जा सकता है. डिवाइस के टाइप के आधार पर, डिवाइसों में यूज़र इंटरफ़ेस के इंतज़ार के समय और टास्क स्विच करने के लिए, मेज़र की जा सकने वाली ज़रूरी शर्तें हो सकती हैं. इनके बारे में सेक्शन 2 में बताया गया है.

8.2. फ़ाइल I/O ऐक्सेस की परफ़ॉर्मेंस

ऐप्लिकेशन के निजी डेटा स्टोरेज (/data पार्टीशन) पर फ़ाइल ऐक्सेस करने की परफ़ॉर्मेंस को बेहतर बनाने के लिए, एक सामान्य बेसलाइन उपलब्ध कराई जाती है. इससे ऐप्लिकेशन डेवलपर को सही उम्मीद रखने में मदद मिलती है. इससे उन्हें अपने सॉफ़्टवेयर को डिज़ाइन करने में मदद मिलती है. डिवाइस के टाइप के हिसाब से, डिवाइसों को लागू करने के लिए कुछ ज़रूरी शर्तें हो सकती हैं. इनके बारे में दूसरे सेक्शन में बताया गया है. ये शर्तें, पढ़ने और लिखने से जुड़ी इन कार्रवाइयों के लिए हैं:

सीक्वेंशियल राइट परफ़ॉर्मेंस. इसे 10 एमबी के राइट बफ़र का इस्तेमाल करके, 256 एमबी की फ़ाइल लिखने के आधार पर मापा जाता है.
रैंडम राइट परफ़ॉर्मेंस. इसे 4 केबी के राइट बफ़र का इस्तेमाल करके, 256 एमबी की फ़ाइल लिखने के आधार पर मापा गया है.
सीक्वेंशियल रीड परफ़ॉर्मेंस. इसे 10 एमबी के राइट बफ़र का इस्तेमाल करके, 256 एमबी की फ़ाइल को पढ़ने के आधार पर मापा जाता है.
रैंडम रीड परफ़ॉर्मेंस. इसे 4 केबी के राइट बफ़र का इस्तेमाल करके, 256 एमबी की फ़ाइल को पढ़ने के आधार पर मापा जाता है.

8.3. बैटरी सेव करने वाले मोड

अगर डिवाइस में, बिजली की खपत को बेहतर तरीके से मैनेज करने की सुविधाएं शामिल हैं, तो:

[C-1-1] ऐप्लिकेशन स्टैंडबाय और डोज़ मोड की पावर सेविंग सुविधाओं को ट्रिगर करने, चालू रखने, और वेकअप करने के लिए, एओएसपी के लागू किए गए तरीके से अलग नहीं होना चाहिए. साथ ही, ग्लोबल सिस्टम सेटिंग या DeviceConfig का इस्तेमाल करना चाहिए.
[C-1-2] ऐप्लिकेशन स्टैंडबाय मोड में, हर बकेट में मौजूद ऐप्लिकेशन के लिए, ग्लोबल सेटिंग या DeviceConfig का इस्तेमाल करके, जॉब, अलार्म, और नेटवर्क की थ्रॉटलिंग को मैनेज करने के लिए, AOSP के लागू करने के तरीके से अलग नहीं होना चाहिए.
[C-1-3] ऐप्लिकेशन स्टैंडबाय बकेट की संख्या के लिए, AOSP के लागू किए गए तरीके से अलग नहीं होना चाहिए.
[C-1-4] ऐप्लिकेशन स्टैंडबाय बकेट और डोज़ मोड को लागू करना ज़रूरी है. इसके बारे में पावर मैनेजमेंट में बताया गया है.
[C-1-5] डिवाइस के पावर सेव मोड में होने पर, true को PowerManager.isPowerSaveMode() वापस भेजना ज़रूरी है.
[C-1-6] ऐप्लिकेशन को, उन सभी ऐप्लिकेशन को दिखाने की सुविधा देनी होगी जिन्हें ऐप्लिकेशन स्टैंडबाय और डोज़ मोड में बैटरी बचाने की सुविधा या बैटरी ऑप्टिमाइज़ेशन की किसी भी सुविधा से छूट मिली है. साथ ही, उसे ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS इंटेंट लागू करना होगा, ताकि उपयोगकर्ता से किसी ऐप्लिकेशन को बैटरी ऑप्टिमाइज़ेशन की सुविधाओं को अनदेखा करने की अनुमति मांगी जा सके.
[C-SR-1] उपयोगकर्ताओं को बैटरी सेवर मोड चालू और बंद करने की सुविधा देने का सुझाव दिया जाता है.
[C-SR-2] उपयोगकर्ताओं को उन सभी ऐप्लिकेशन को दिखाने की सुविधा देने का सुझाव दिया जाता है जिन्हें ऐप्लिकेशन स्टैंडबाय और बैटरी बचाने वाले मोड से छूट मिली है.

अगर डिवाइस में, AOSP में शामिल पावर मैनेजमेंट की सुविधाओं को बढ़ाया जाता है और यह एक्सटेंशन, रेयर ऐप्लिकेशन स्टैंडबाय बकेट की तुलना में ज़्यादा सख्त पाबंदियां लागू करता है, तो सेक्शन 3.5.1 देखें.

बैटरी बचाने वाले मोड के अलावा, Android डिवाइस में सेट किए गए सिस्टम, एडवांस्ड कॉन्फ़िगरेशन ऐंड पावर इंटरफ़ेस (एसीपीआई) के हिसाब से, बैटरी की खपत कम करने के लिए उपलब्ध चार में से कोई भी या सभी मोड लागू कर सकते हैं.

अगर डिवाइस में ACPI के हिसाब से S4 पावर स्टेट लागू की जाती है, तो:

[C-1-1] डिवाइस को इस स्थिति में सिर्फ़ तब जाना चाहिए, जब उपयोगकर्ता ने डिवाइस को बंद करने के लिए कोई कार्रवाई की हो. जैसे, डिवाइस के ढक्कन को बंद करना या वाहन या टीवी को बंद करना. साथ ही, डिवाइस को इस स्थिति में तब तक रहना चाहिए, जब तक उपयोगकर्ता उसे फिर से चालू न कर दे. जैसे, ढक्कन खोलना या वाहन या टीवी को फिर से चालू करना.

अगर डिवाइस में ACPI के हिसाब से S3 पावर स्टेट लागू की जाती है, तो:

[C-2-1] ऊपर दी गई C-1-1 की ज़रूरी शर्त पूरी होनी चाहिए. इसके अलावा, S3 मोड में सिर्फ़ तब जाना चाहिए, जब तीसरे पक्ष के ऐप्लिकेशन को सिस्टम रिसॉर्स (जैसे, स्क्रीन, सीपीयू) की ज़रूरत न हो.

इसके उलट, जब तीसरे पक्ष के ऐप्लिकेशन को सिस्टम संसाधनों की ज़रूरत हो, तो S3 मोड से बाहर निकलना ज़रूरी है. इसके बारे में इस एसडीके में बताया गया है.

उदाहरण के लिए, तीसरे पक्ष के ऐप्लिकेशन, 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 Open Source Project, 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() एपीआई के तरीके से, खाली सूची को वापस लाना ज़रूरी है.

8.6. ऐप्लिकेशन के लिए मेमोरी की सीमाएं

MemoryLimiter, ActivityManagerService का एक नया कॉम्पोनेंट है. साथ ही, ऐप्लिकेशन के लिए मेमोरी की डिफ़ॉल्ट सीमाएं, उपलब्ध फ़िज़िकल मेमोरी से तय की जाती हैं. ये दोनों, हर ऐप्लिकेशन प्रोसेस के लिए इस्तेमाल की गई DRAM की मात्रा पर सीमाएं तय करेंगे. यह पाबंदी, ऐप्लिकेशन प्रोसेस में असाइन की गई सभी मेमोरी पर लागू होती है. इससे यह पक्का होता है कि सीमाएं, ऐप्लिकेशन डेवलपर के साथ किए गए कानूनी समझौते के तहत तय किए गए ज़रूरी नियमों के मुताबिक काम करें.

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-1] ऐप्लिकेशन के लिए सेट की गई रनटाइम मेमोरी की सीमाओं को बायपास करने के लिए, किसी भी तरीके, अनुमति वाली सूचियों या नीतियों का इस्तेमाल नहीं करना चाहिए.

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 के भूमिकाओं वाले मॉडल के साथ काम करता हो. खास तौर पर, उन्हें एसडीके के दस्तावेज़ में बताई गई हर अनुमति और भूमिका को लागू करना होगा. किसी भी अनुमति और भूमिका को छोड़ा, बदला या अनदेखा नहीं किया जा सकता.
ज़्यादा अनुमतियां जोड़ सकता है. हालांकि, नई अनुमति के आईडी स्ट्रिंग android.\* नेमस्पेस में नहीं होने चाहिए.
[C-0-2] protectionLevel की PROTECTION_FLAG_PRIVILEGED वाली अनुमतियां, सिर्फ़ उन ऐप्लिकेशन को दी जानी चाहिए जो सिस्टम इमेज के खास पाथ में पहले से इंस्टॉल हैं. साथ ही, ये अनुमतियां APEX फ़ाइलों के लिए भी होनी चाहिए. इसके अलावा, ये अनुमतियां हर ऐप्लिकेशन के लिए, साफ़ तौर पर अनुमति दी गई अनुमतियों के सबसेट में होनी चाहिए. AOSP, इस ज़रूरी शर्त को पूरा करता है. इसके लिए, वह etc/permissions/ पाथ में मौजूद फ़ाइलों से, हर ऐप्लिकेशन के लिए अनुमति दी गई अनुमतियों को पढ़ता है और उनका पालन करता है. साथ ही, system/priv-app पाथ को खास पाथ के तौर पर इस्तेमाल करता है.
[C-SR-1] protectionLevel की PROTECTION_SIGNATURE वाली अनुमतियां, सिर्फ़ इन लोगों को देने का सुझाव दिया जाता है:
- सिस्टम इमेज पर पहले से इंस्टॉल किए गए ऐप्लिकेशन और APEX फ़ाइलें.
- अगर ऐप्लिकेशन को सिस्टम इमेज में शामिल नहीं किया गया है, तो उन्हें अनुमति वाली अनुमतियों के साथ अनुमति वाली सूची में शामिल किया जाता है.
ध्यान दें: AOSP में इस ज़रूरी शर्त को पूरा किया जाता है. इसके लिए, etc/permissions/ पाथ में मौजूद फ़ाइलों से, हर ऐप्लिकेशन के लिए अनुमति वाली सूची में शामिल अनुमतियों को पढ़ा जाता है और उनका पालन किया जाता है.

खतरनाक लेवल की सुरक्षा वाली अनुमतियां, रनटाइम अनुमतियां होती हैं. targetSdkVersion > 22 वाले ऐप्लिकेशन, रनटाइम के दौरान अनुमतियों का अनुरोध करते हैं.

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-3] उपयोगकर्ता को एक खास इंटरफ़ेस दिखाना ज़रूरी है, ताकि वह यह तय कर सके कि रनटाइम के दौरान मांगी गई अनुमतियां देनी हैं या नहीं. साथ ही, उपयोगकर्ता को रनटाइम की अनुमतियां मैनेज करने के लिए भी एक इंटरफ़ेस उपलब्ध कराना ज़रूरी है.
[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] सिर्फ़ उस ऐप्लिकेशन को रनटाइम की अनुमति मिलनी चाहिए जिसके पास एसडीके टूल में बताई गई ज़रूरी अनुमति हो. उदाहरण के लिए, 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] ऐसी भूमिकाएं तय नहीं की जानी चाहिए जो प्लैटफ़ॉर्म की ओर से तय की गई भूमिकाओं की डुप्लीकेट हों या उनके सुपरसेट फ़ंक्शन हों.

अगर डिवाइसों में ऐसे डेटा सेंसर शामिल हैं जो स्वास्थ्य से जुड़े बायोमेट्रिक्स का पता लगाते हैं, जैसे कि हृदय गति या त्वचा का तापमान, तो इन बायोमेट्रिक्स के लिए:

[C-0-16] अगर android.permission-group.HEALTH में इससे जुड़ी कोई अनुमति मौजूद है, तो android.permission-group.HEALTH की प्लैटफ़ॉर्म अनुमतियों से इसकी सुरक्षा करना ज़रूरी है.HealthPermissions
[C-0-17] अगर कोई प्लैटफ़ॉर्म अनुमति, ज़रूरी डेटा टाइप से मेल नहीं खाती है, तो उसे सिस्टम की कस्टम अनुमति से सुरक्षित रखना ज़रूरी है. (उदाहरण के लिए, ELECTROCARDIOGRAM.)

अगर डिवाइसों की रिपोर्ट में android.software.managed_users दिखता है, तो:

[C-1-1] एडमिन को इन अनुमतियों को चुपचाप नहीं देना चाहिए:
- जगह (ACCESS_BACKGROUND_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION).
- कैमरा (CAMERA)
- माइक्रोफ़ोन (RECORD_AUDIO)
- बॉडी सेंसर (BODY_SENSORS)
- स्वास्थ्य (HealthPermissions)
- शारीरिक गतिविधि (ACTIVITY_RECOGNITION)

अगर डिवाइसों की रिपोर्ट में 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. ओएस-लेवल और आस-पास के माहौल का डेटा और 9.8.15. Sandboxed API लागू करने की प्रोसेस.

9.2. यूआईडी और अलग-अलग प्रोसेस के लिए टेक्नोलॉजी

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-1] Android ऐप्लिकेशन के सैंडबॉक्स मॉडल के साथ काम करना ज़रूरी है. इसमें हर ऐप्लिकेशन, यूनीक Unixstyle UID के तौर पर और अलग प्रोसेस में चलता है.
[C-0-2] एक ही Linux यूज़र आईडी के तौर पर कई ऐप्लिकेशन चलाने की सुविधा होनी चाहिए. हालांकि, इसके लिए ज़रूरी है कि ऐप्लिकेशन पर सही तरीके से हस्ताक्षर किए गए हों और उन्हें सही तरीके से बनाया गया हो. इसके बारे में सुरक्षा और अनुमतियों के बारे में जानकारी देने वाले दस्तावेज़ में बताया गया है.

9.3. फ़ाइल सिस्टम से जुड़ी अनुमतियां

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-1] Android के फ़ाइल ऐक्सेस करने की अनुमतियों के मॉडल के साथ काम करना ज़रूरी है. इसके बारे में सुरक्षा और अनुमतियों के बारे में जानकारी में बताया गया है.

9.4. वैकल्पिक एक्ज़ीक्यूशन एनवायरमेंट

डिवाइसों में Android की सुरक्षा और अनुमति मॉडल को एक जैसा रखना ज़रूरी है. भले ही, उनमें ऐसे रनटाइम एनवायरमेंट शामिल हों जो Dalvik Executable Format या नेटिव कोड के अलावा, किसी अन्य सॉफ़्टवेयर या टेक्नोलॉजी का इस्तेमाल करके ऐप्लिकेशन को एक्ज़ीक्यूट करते हों. दूसरे शब्दों में:

[C-0-1] वैकल्पिक रनटाइम, Android ऐप्लिकेशन होने चाहिए. साथ ही, उन्हें Android के स्टैंडर्ड सुरक्षा मॉडल का पालन करना चाहिए. इसके बारे में सेक्शन 9 में बताया गया है.
[C-0-2] <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 देखें), तो अतिरिक्त उपयोगकर्ता प्रोफ़ाइल बनाने की अनुमति नहीं देनी चाहिए. इसके अलावा, अतिरिक्त उपयोगकर्ता प्रोफ़ाइल को पहले हटाए बिना, डिवाइस के मालिक का खाता बनाने की अनुमति नहीं देनी चाहिए.

अगर डिवाइसों पर, ऊपर बताई गई अतिरिक्त उपयोगकर्ता प्रोफ़ाइल बनाई जाती है, तो:

[C-4-1] डिवाइस पर मौजूद मुख्य उपयोगकर्ता के ऐप्लिकेशन को, अतिरिक्त प्रोफ़ाइल से जनरेट होने वाले इन इंटेंट को हैंडल करने की अनुमति देनी होगी:
- Intent.ACTION_VIEW
- Intent.ACTION_SENDTO
- Intent.ACTION_SEND
- Intent.ACTION_EDIT
- Intent.ACTION_INSERT
- Intent.ACTION_INSERT_OR_EDIT
- Intent.ACTION_SEND_MULTIPLE
- Intent.ACTION_PICK
- Intent.ACTION_GET_CONTENT
- MediaStore.ACTION_IMAGE_CAPTURE
- MediaStore.ACTION_VIDEO_CAPTURE
[C-4-2] MUST inherit all device policy user restrictions and selected non-user restrictions(list below) applied on the primary user of the device to this additional user profile.
[C-4-3] इस अतिरिक्त प्रोफ़ाइल से संपर्क लिखने की अनुमति सिर्फ़ इन इंटेंट के ज़रिए दी जानी चाहिए:
[C-4-4] इस अतिरिक्त उपयोगकर्ता प्रोफ़ाइल में चल रहे ऐप्लिकेशन के लिए, संपर्क सिंक करने की सुविधा चालू नहीं होनी चाहिए.
[C-4-5] अतिरिक्त प्रोफ़ाइल में सिर्फ़ उन ऐप्लिकेशन को संपर्क जानकारी ऐक्सेस करने की अनुमति देनी चाहिए जिनमें लॉन्चर ऐक्टिविटी होती है. साथ ही, यह जानकारी पैरंट यूज़र प्रोफ़ाइल के लिए पहले से ही उपलब्ध होनी चाहिए.

अगर डिवाइसों पर, ऊपर बताई गई अतिरिक्त उपयोगकर्ता प्रोफ़ाइलें बनाई जाती हैं, तो उनमें कम से कम एक कैमरा शामिल होना चाहिए. साथ ही, पहले से इंस्टॉल किया गया कैमरा ऐप्लिकेशन, MediaStore.ACTION_MOTION_PHOTO_CAPTURE या MediaStore.ACTION_MOTION_PHOTO_CAPTURE_SECURE इंटेंट को हैंडल करता हो. ऐसे में:

[C-5-1] यह ज़रूरी है कि मुख्य उपयोगकर्ता के ऐप्लिकेशन, अतिरिक्त उपयोगकर्ता प्रोफ़ाइल से जनरेट होने वाले इन इंटेंट को हैंडल कर सकें.

9.6. प्रीमियम एसएमएस की चेतावनी

Android में, लोगों को किसी भी आउटगोइंग प्रीमियम एसएमएस मैसेज के बारे में चेतावनी देने की सुविधा शामिल है. प्रीमियम एसएमएस, मोबाइल और इंटरनेट सेवा देने वाली कंपनी के साथ रजिस्टर की गई किसी सेवा को भेजे जाने वाले टेक्स्ट मैसेज होते हैं. इसके लिए, उपयोगकर्ता से शुल्क लिया जा सकता है.

अगर डिवाइस में android.hardware.telephony के साथ काम करने की सुविधा उपलब्ध है, तो:

[C-1-1] डिवाइस में मौजूद /data/misc/sms/codes.xml फ़ाइल में तय किए गए रेगुलर एक्सप्रेशन से पहचाने गए नंबरों पर एसएमएस भेजने से पहले, उपयोगकर्ताओं को चेतावनी देनी होगी. अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट, इस ज़रूरी शर्त को पूरा करने वाला एक तरीका उपलब्ध कराता है.

9.7. Security Features

डिवाइसों को लागू करने वाले लोगों को यह पक्का करना होगा कि कर्नेल और प्लैटफ़ॉर्म, दोनों में सुरक्षा से जुड़ी सुविधाओं का पालन किया गया हो. इसके बारे में यहां बताया गया है.

Android सैंडबॉक्स में ऐसी सुविधाएं शामिल हैं जो Security-Enhanced Linux (SELinux) के ज़रूरी ऐक्सेस कंट्रोल (एमएसी) सिस्टम, seccomp सैंडबॉक्सिंग, और Linux कर्नल में मौजूद अन्य सुरक्षा सुविधाओं का इस्तेमाल करती हैं. डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-1] मौजूदा ऐप्लिकेशन के साथ काम करना ज़रूरी है. भले ही, Android फ़्रेमवर्क के नीचे SELinux या सुरक्षा से जुड़ी कोई अन्य सुविधा लागू की गई हो.
[C-0-2] सुरक्षा से जुड़े उल्लंघन का पता चलने और Android फ़्रेमवर्क के नीचे लागू की गई सुरक्षा सुविधा से उसे ब्लॉक किए जाने पर, यूज़र इंटरफ़ेस (यूआई) नहीं दिखना चाहिए. हालांकि, सुरक्षा से जुड़े उल्लंघन के ब्लॉक न होने और उसका फ़ायदा उठाए जाने पर, यूज़र इंटरफ़ेस (यूआई) दिख सकता है.
[C-0-3] SELinux या Android फ़्रेमवर्क के नीचे लागू की गई किसी भी अन्य सुरक्षा सुविधा को, उपयोगकर्ता या ऐप्लिकेशन डेवलपर के लिए कॉन्फ़िगर करने की अनुमति नहीं होनी चाहिए.
[C-0-4] किसी ऐसे ऐप्लिकेशन को अनुमति नहीं देनी चाहिए जो एपीआई (जैसे कि डिवाइस एडमिनिस्ट्रेशन एपीआई) के ज़रिए, किसी दूसरे ऐप्लिकेशन पर असर डाल सकता है. साथ ही, उसे ऐसी नीति कॉन्फ़िगर करने की अनुमति नहीं देनी चाहिए जो कंपैटिबिलिटी से जुड़ी शर्तों का उल्लंघन करती हो.
[C-0-5] मीडिया फ़्रेमवर्क को कई प्रोसेस में बांटना ज़रूरी है, ताकि हर प्रोसेस के लिए ऐक्सेस को ज़्यादा सीमित तरीके से दिया जा सके. इसके बारे में Android Open Source Project की साइट पर बताया गया है.
[C-0-6] कर्नेल ऐप्लिकेशन सैंडबॉक्सिंग मैकेनिज़्म लागू करना ज़रूरी है. इससे मल्टीथ्रेड प्रोग्राम से कॉन्फ़िगर की जा सकने वाली नीति का इस्तेमाल करके, सिस्टम कॉल को फ़िल्टर किया जा सकता है. अपस्ट्रीम Android Open Source Project, इस ज़रूरी शर्त को पूरा करता है. इसके लिए, वह थ्रेडग्रुप सिंक्रनाइज़ेशन (टीएसवाईएनसी) के साथ seccomp-BPF को चालू करता है. इसके बारे में source.android.com के कर्नल कॉन्फ़िगरेशन सेक्शन में बताया गया है.

कर्नल की सुरक्षा और खुद की सुरक्षा करने की सुविधाएं, Android की सुरक्षा के लिए ज़रूरी हैं. डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-7] कर्नेल स्टैक बफ़र ओवरफ़्लो से सुरक्षा देने वाले तरीके लागू करना ज़रूरी है. इस तरह के कुछ उदाहरण यहां दिए गए हैं: CC_STACKPROTECTOR_REGULAR और CONFIG_CC_STACKPROTECTOR_STRONG.
[C-0-8] कर्नल मेमोरी के लिए, सुरक्षा से जुड़ी सख्त नीतियां लागू करनी होंगी. जैसे, एक्ज़ीक्यूटेबल कोड सिर्फ़ पढ़ा जा सकता हो, सिर्फ़ पढ़े जा सकने वाले डेटा को एक्ज़ीक्यूट न किया जा सके, और उसे लिखा न जा सके. साथ ही, लिखे जा सकने वाले डेटा को एक्ज़ीक्यूट न किया जा सके. उदाहरण के लिए, rodata और CONFIG_STRICT_KERNEL_RWX, दोनों चालू हों.
[C-0-9] API लेवल 28 या इसके बाद के वर्शन के साथ शिप किए गए डिवाइसों पर, उपयोगकर्ता-स्पेस और कर्नल-स्पेस के बीच कॉपी की गई फ़ाइलों के लिए, स्टैटिक और डाइनैमिक ऑब्जेक्ट के साइज़ की सीमा की जांच लागू करना ज़रूरी है. उदाहरण के लिए, CONFIG_HARDENED_USERCOPY.
[C-0-10] कर्नेल मोड में एक्ज़ीक्यूट करते समय, उपयोगकर्ता-स्पेस मेमोरी को एक्ज़ीक्यूट नहीं किया जाना चाहिए.जैसे, हार्डवेयर पीएक्सएन या CONFIG_CPU_SW_DOMAIN_PAN या CONFIG_ARM64_SW_TTBR0_PAN के ज़रिए एम्युलेट किया गया. ऐसा उन डिवाइसों पर किया जाना चाहिए जो मूल रूप से एपीआई लेवल 28 या इसके बाद के वर्शन के साथ शिप किए गए थे.
[C-0-11] एपीआई लेवल 28 या इसके बाद के वर्शन वाले डिवाइसों पर, कर्नल को सामान्य usercopy ऐक्सेस एपीआई (जैसे, हार्डवेयर पैन या CONFIG_CPU_SW_DOMAIN_PAN या CONFIG_ARM64_SW_TTBR0_PAN के ज़रिए इम्यूलेट किया गया) के बाहर, उपयोगकर्ता-स्पेस मेमोरी को न तो पढ़ना चाहिए और न ही लिखना चाहिए.
[C-0-12] अगर हार्डवेयर, CVE-2017-5754 से जुड़ी समस्या से प्रभावित है, तो कर्नेल पेज टेबल आइसोलेशन को लागू करना ज़रूरी है. यह समस्या उन सभी डिवाइसों पर होती है जो मूल रूप से 28 या इसके बाद के एपीआई लेवल (जैसे, CONFIG_PAGE_TABLE_ISOLATION या CONFIG_UNMAP_KERNEL_AT_EL0) के साथ शिप किए गए थे.
[C-0-13] अगर हार्डवेयर, CVE-2017-5715 से जुड़े जोखिमों से सुरक्षित नहीं है, तो सभी डिवाइसों पर ब्रांच प्रेडिक्शन हार्डनिंग को लागू करना ज़रूरी है. ये ऐसे डिवाइस होने चाहिए जो मूल रूप से एपीआई लेवल 28 या इसके बाद के वर्शन (जैसे, CONFIG_HARDEN_BRANCH_PREDICTOR) के साथ शिप किए गए हों.
[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) से अतिरिक्त सुरक्षा मिलती है.
[C-SR-4] जिन कॉम्पोनेंट पर कंट्रोल-फ़्लो इंटिग्रिटी (सीएफ़आई), शैडो कॉल स्टैक (एससीएस) या पूर्णांक ओवरफ़्लो सैनिटाइज़ेशन (इंटसैन) चालू है उन पर इन्हें बंद न करने का सुझाव दिया जाता है.
[C-SR-5] यह सुझाव दिया जाता है कि सुरक्षा से जुड़े यूज़रस्पेस कॉम्पोनेंट के लिए, सीएफ़आई, एससीए, और IntSan को चालू करें. इस बारे में सीएफ़आई और IntSan में बताया गया है.
[C-SR-6] कर्नेल में स्टैक इनिशियलाइज़ेशन को चालू करने का सुझाव दिया जाता है, ताकि बिना इनिशियलाइज़ किए गए लोकल वैरिएबल (CONFIG_INIT_STACK_ALL या CONFIG_INIT_STACK_ALL_ZERO) का इस्तेमाल न किया जा सके. साथ ही, डिवाइसों को लागू करने वाले लोगों को यह नहीं मानना चाहिए कि कंपाइलर, लोकल वैरिएबल को इनिशियलाइज़ करने के लिए जिस वैल्यू का इस्तेमाल करता है.
[C-SR-7] कर्नेल में हीप इनिशियलाइज़ेशन को चालू करने का सुझाव दिया जाता है, ताकि बिना इनिशियलाइज़ किए गए हीप के लिए मेमोरी के बंटवारे (CONFIG_INIT_ON_ALLOC_DEFAULT_ON) को रोका जा सके. साथ ही, उन्हें यह नहीं मानना चाहिए कि कर्नेल ने उन मेमोरी के बंटवारे को इनिशियलाइज़ करने के लिए किस वैल्यू का इस्तेमाल किया है.

अगर डिवाइस में Linux कर्नेल का इस्तेमाल किया जाता है, जो SELinux के साथ काम कर सकता है, तो:

[C-1-1] SELinux को लागू करना ज़रूरी है.
[C-1-2] SELinux को ग्लोबल एनफ़ोर्सिंग मोड पर सेट करना ज़रूरी है.
[C-1-3] सभी डोमेन को एनफ़ोर्सिंग मोड में कॉन्फ़िगर करना ज़रूरी है. अनुमति वाले मोड के किसी भी डोमेन को अनुमति नहीं है. इनमें डिवाइस/वेंडर से जुड़े डोमेन भी शामिल हैं.

[C-1-4] यह ज़रूरी है कि:
- अपस्ट्रीम Android Open Source Project (AOSP) में दिए गए system/sepolicy फ़ोल्डर में मौजूद neverallow नियमों में बदलाव करना, उन्हें हटाना या बदलना
- AOSP के SELinux लेबल को, AOSP के अलावा अन्य कॉम्पोनेंट में गलत तरीके से जोड़ना
नीति में, AOSP SELinux डोमेन और डिवाइस/वेंडर के हिसाब से बने डोमेन, दोनों के लिए मौजूद सभी neverallow नियमों का पालन करना ज़रूरी है.

[C-1-5] तीसरे पक्ष के ऐप्लिकेशन को, एपीआई लेवल 28 या इसके बाद के वर्शन के हिसाब से डिज़ाइन किया जाना चाहिए. साथ ही, उन्हें हर ऐप्लिकेशन के हिसाब से SELinux सैंडबॉक्स में चलाना ज़रूरी है. इसके अलावा, हर ऐप्लिकेशन के निजी डेटा डायरेक्ट्री पर, हर ऐप्लिकेशन के हिसाब से SELinux की पाबंदियां लागू होनी चाहिए.
उन्हें Android Open Source Project के सिस्टम/sepolicy फ़ोल्डर में दी गई डिफ़ॉल्ट SELinux नीति को बनाए रखना चाहिए. साथ ही, अपने डिवाइस के हिसाब से कॉन्फ़िगरेशन के लिए, इस नीति में सिर्फ़ कुछ और चीज़ें जोड़नी चाहिए.

अगर डिवाइस में Linux या SELinux के बिना Linux के अलावा किसी अन्य कर्नल का इस्तेमाल किया जाता है, तो:

[C-2-1] ज़रूरी है कि डिवाइस में, SELinux के बराबर का मैंडेटरी ऐक्सेस कंट्रोल सिस्टम इस्तेमाल किया जा रहा हो.

अगर डिवाइस में ऐसे I/O डिवाइसों का इस्तेमाल किया जाता है जिनमें डीएमए की सुविधा होती है, तो:

[C-SR-9] डीएमए की सुविधा वाले हर I/O डिवाइस को अलग रखने का सुझाव दिया जाता है. इसके लिए, आईओएमएमयू (जैसे, ARM SMMU) का इस्तेमाल करें.

Android में कई लेयर वाली सुरक्षा की सुविधाएं मौजूद हैं. ये डिवाइस की सुरक्षा के लिए ज़रूरी हैं. इसके अलावा, Android का फ़ोकस, सामान्य बग की मुख्य क्लास को कम करने पर होता है. ये बग, खराब क्वालिटी और सुरक्षा के लिए ज़िम्मेदार होते हैं.

मेमोरी से जुड़ी गड़बड़ियों को कम करने के लिए, डिवाइसों में ये सुविधाएं लागू की जाती हैं:

[C-SR-10] ARMv9 डिवाइसों के लिए MTE, ARMv8+ डिवाइसों के लिए HWASan या अन्य डिवाइस टाइप के लिए ASan जैसे उपयोगकर्ताओं के स्पेस में मेमोरी की गड़बड़ी का पता लगाने वाले टूल का इस्तेमाल करके, इनकी जांच करना ज़रूरी है.
[C-SR-11] कर्नेल मेमोरी से जुड़ी गड़बड़ी का पता लगाने वाले टूल का इस्तेमाल करके, इनकी जांच करने का सुझाव दिया जाता है. जैसे, KASAN (ARMv9 डिवाइसों के लिए CONFIG_KASAN, CONFIG_KASAN_HW_TAGS, ARMv8 डिवाइसों के लिए CONFIG_KASAN_SW_TAGS या अन्य डिवाइस टाइप के लिए CONFIG_KASAN_GENERIC).
[C-SR-12] प्रोडक्शन में मेमोरी की गड़बड़ी का पता लगाने वाले टूल इस्तेमाल करने का सुझाव दिया जाता है. जैसे, MTE, GWP-ASan, और KFENCE.

अगर डिवाइस में Arm TrustZone पर आधारित टीईई का इस्तेमाल किया जाता है, तो:

[C-SR-13] Android और टीईई के बीच मेमोरी शेयर करने के लिए, स्टैंडर्ड प्रोटोकॉल का इस्तेमाल करने का सुझाव दिया जाता है. जैसे, Armv8-A (FF-A) के लिए Arm फ़र्मवेयर फ़्रेमवर्क.
[C-SR-14] भरोसेमंद ऐप्लिकेशन के लिए सिर्फ़ उस मेमोरी के ऐक्सेस को सीमित करने का सुझाव दिया जाता है जिसे उनके साथ ऊपर दिए गए प्रोटोकॉल के ज़रिए, साफ़ तौर पर शेयर किया गया हो. अगर डिवाइस में Arm S-EL2 के एक्सेप्शन लेवल के साथ काम करने की सुविधा है, तो इसे सुरक्षित पार्टिशन मैनेजर के ज़रिए लागू किया जाना चाहिए. अगर ऐसा नहीं है, तो इन्हें टीईई ओएस के ज़रिए लागू किया जाना चाहिए.

मेमोरी सेफ़्टी टेक्नोलॉजी, एक ऐसी टेक्नोलॉजी है जो कम से कम इन तरह के बग को ठीक करती है. साथ ही, android:memtagMode मेनिफ़ेस्ट विकल्प का इस्तेमाल करने वाले ऐप्लिकेशन में, 90% से ज़्यादा संभावना के साथ बग ठीक करती है:

हीप बफ़र ओवरफ़्लो
बिना शुल्क आज़माने की अवधि खत्म होने के बाद इस्तेमाल करना
डबल फ़्री
वाइल्ड फ़्री (नॉन-मैलोक पॉइंटर से फ़्री)

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-SR-15] ro.arm64.memtag.bootctl_supported को सेट करने का सुझाव दिया जाता है.

अगर डिवाइसों में सिस्टम प्रॉपर्टी ro.arm64.memtag.bootctl_supported को सही पर सेट किया जाता है, तो:

[C-3-1] सिस्टम प्रॉपर्टी arm64.memtag.bootctl को, कॉमा लगाकर अलग की गई इन वैल्यू की सूची को स्वीकार करने की अनुमति देना ज़रूरी है. साथ ही, अगले रीबूट पर इन वैल्यू का असर दिखना चाहिए:
- memtag: ऊपर बताई गई मेमोरी सेफ़्टी टेक्नोलॉजी चालू है
- memtag-once: ऊपर बताई गई मेमोरी सेफ़्टी टेक्नोलॉजी को कुछ समय के लिए चालू किया जाता है. इसके बाद, अगली बार रीबूट करने पर यह अपने-आप बंद हो जाती है
- memtag-off: ऊपर बताई गई मेमोरी सेफ़्टी टेक्नोलॉजी बंद है
[C-3-2] शेल उपयोगकर्ता को arm64.memtag.bootctl सेट करने की अनुमति दें.
[C-3-3] किसी भी प्रोसेस को arm64.memtag.bootctl पढ़ने की अनुमति होनी चाहिए.
[C-3-4] बूट होने पर, arm64.memtag.bootctl को मौजूदा अनुरोध की स्थिति पर सेट करना होगा. साथ ही, अगर डिवाइस के इंटिग्रेशन से सिस्टम प्रॉपर्टी में बदलाव किए बिना स्थिति में बदलाव किया जा सकता है, तो इसे प्रॉपर्टी को भी अपडेट करना होगा.
[C-SR-16] डेवलपर सेटिंग दिखाने का सुझाव दिया जाता है. इससे memtag-once सेट होता है और डिवाइस रीबूट होता है. Android Open Source Project, MTE बूटलोडर प्रोटोकॉल के ज़रिए, ऊपर दी गई ज़रूरी शर्तों को पूरा करता है. इसके लिए, बूटलोडर का इस्तेमाल किया जाता है.

अगर कोई डिवाइस android.hardware.telephony का एलान करता है, CAPABILITY_USES_ALLOWED_NETWORK_TYPES_BITMASK रेडियो की सुविधा के साथ काम करता है, और इसमें 2G कनेक्शन के साथ काम करने वाला सेल्युलर मॉडेम शामिल है, तो डिवाइस को इन शर्तों को पूरा करना होगा:

[C-SR-17] उपयोगकर्ता को 2G की सुविधा बंद और चालू करने का विकल्प देने का सुझाव दिया जाता है.
[C-SR-18] यह सुझाव दिया जाता है कि डिवाइस एडमिन के अलावा, कोई अन्य डिवाइस इकाई UserManager.DISALLOW_CELLULAR_2G का इस्तेमाल करके, 2G को बंद और चालू करने की उपयोगकर्ता की सुविधा को ओवरराइड न करे.
[C-SR-19] इस ज़रूरी शर्त को पूरा करने के लिए, TelephonyManager.setAllowedNetworkTypesForReason को ALLOWED_NETWORK_TYPES_REASON_ENABLE_2G वजह के साथ कॉल करने का सुझाव दिया जाता है.
[C-SR-20] TelephonyManager.getSupportedRadioAccessFamily को कॉल करके, 2G के लिए सेल्युलर मॉडम के काम करने की स्थिति का पता लगाने का सुझाव दिया जाता है. ज़्यादा जानकारी के लिए, 2G बंद करना लेख पढ़ें.

9.8. निजता

9.8.1. इस्तेमाल का इतिहास

Android, उपयोगकर्ता की प्राथमिकताओं का इतिहास सेव करता है. साथ ही, UsageStatsManager की मदद से इस इतिहास को मैनेज करता है.

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-1] को उपयोगकर्ता के इस तरह के इतिहास को सेव करने की अवधि तय करनी होगी.
[C-SR-1] यह सुझाव दिया जाता है कि डेटा को सेव करके रखने की अवधि 14 दिन ही रखी जाए. यह अवधि, AOSP में डिफ़ॉल्ट रूप से कॉन्फ़िगर की गई है.

Android, सिस्टम इवेंट को StatsLog आइडेंटिफ़ायर का इस्तेमाल करके सेव करता है. साथ ही, StatsManager और IncidentManager System API की मदद से, इस तरह के इतिहास को मैनेज करता है.

डिवाइस में सेट किए गए सिस्टम के लिए:

[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.createVirtualDisplay() या मालिकाना हक वाले एपीआई के ज़रिए स्क्रीन कास्टिंग या स्क्रीन रिकॉर्डिंग की सुविधा चालू होने पर, उपयोगकर्ता को चेतावनी दिखानी होगी. साथ ही, उपयोगकर्ता की साफ़ तौर पर सहमति लेनी होगी. इससे, उपयोगकर्ता की स्क्रीन पर दिखने वाली किसी भी संवेदनशील जानकारी को हर बार कैप्चर किया जा सकेगा.
[C-0-3] स्क्रीन कास्टिंग या स्क्रीन रिकॉर्डिंग चालू होने पर, उपयोगकर्ता को लगातार सूचना मिलती रहनी चाहिए. AOSP, स्टेटस बार में चल रही सूचना का आइकॉन दिखाकर इस ज़रूरी शर्त को पूरा करता है.
[C-SR-1] हमारा सुझाव है कि उपयोगकर्ता को चेतावनी दिखाने के लिए, AOSP में लागू किए गए मैसेज का इस्तेमाल करें. हालांकि, इसमें बदलाव किया जा सकता है. बशर्ते, मैसेज में उपयोगकर्ता को साफ़ तौर पर यह चेतावनी दी गई हो कि उसकी स्क्रीन पर मौजूद कोई भी संवेदनशील जानकारी कैप्चर की गई है.
[C-0-4] Android 16 में इस ज़रूरी शर्त को हटा दिया गया है.

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-7] संवेदनशील जानकारी को रिकॉर्ड, प्रोजेक्ट या कास्ट नहीं किया जाना चाहिए. जैसे:
- संवेदनशील जानकारी वाली सूचना का कॉन्टेंट, सेक्शन 3.8.3.4 संवेदनशील जानकारी वाली सूचना को सुरक्षित रखना में दिया गया है
- ऐप्लिकेशन में की गई गतिविधि की ऐसी विंडो जिनमें एक बार इस्तेमाल होने वाले पासवर्ड शामिल होते हैं
- संवेदनशील कॉन्टेंट, जैसे कि उपयोगकर्ता नाम, पासवर्ड, और क्रेडिट कार्ड की जानकारी

अगर डिवाइस के सिस्टम में ऐसी सुविधा शामिल है जो स्क्रीन पर दिखने वाले कॉन्टेंट को कैप्चर करती है और/या सिस्टम एपीआई ContentCaptureService के अलावा, डिवाइस पर चलने वाली ऑडियो स्ट्रीम को रिकॉर्ड करती है या सेक्शन 9.8.6 ओएस-लेवल और आस-पास के डेटा में बताए गए अन्य मालिकाना हक वाले तरीकों का इस्तेमाल करती है, तो:

[C-1-1] जब यह सुविधा चालू हो और डेटा कैप्चर/रिकॉर्ड किया जा रहा हो, तब उपयोगकर्ता को लगातार सूचना मिलनी चाहिए.

अगर डिवाइसों में ऐसा कॉम्पोनेंट शामिल है जो बॉक्स से बाहर ही चालू हो जाता है और आस-पास की आवाज़ और/या डिवाइस पर चलने वाले ऑडियो को रिकॉर्ड कर सकता है, ताकि उपयोगकर्ता के कॉन्टेक्स्ट के बारे में काम की जानकारी का अनुमान लगाया जा सके, तो:

[C-2-1] रिकॉर्ड किए गए रॉ ऑडियो या किसी ऐसे फ़ॉर्मैट को डिवाइस के परसिस्टेंट स्टोरेज में सेव नहीं करना चाहिए या डिवाइस से बाहर नहीं भेजना चाहिए जिसे वापस ओरिजनल ऑडियो या उसके जैसा ऑडियो में बदला जा सकता है. हालांकि, उपयोगकर्ता की साफ़ तौर पर सहमति मिलने पर ऐसा किया जा सकता है.

"माइक्रोफ़ोन इंडिकेटर" का मतलब स्क्रीन पर दिखने वाले ऐसे व्यू से है जो उपयोगकर्ता को हमेशा दिखता है और जिसे छिपाया नहीं जा सकता. इससे उपयोगकर्ताओं को पता चलता है कि माइक्रोफ़ोन का इस्तेमाल किया जा रहा है. इसके लिए, यूनीक टेक्स्ट, रंग, आइकॉन या कुछ कॉम्बिनेशन का इस्तेमाल किया जाता है.

"कैमरा इंडिकेटर" का मतलब स्क्रीन पर दिखने वाले ऐसे व्यू से है जो उपयोगकर्ता को लगातार दिखता रहता है और जिसे छिपाया नहीं जा सकता. उपयोगकर्ता इसे इस तरह से समझते हैं कि कैमरे का इस्तेमाल किया जा रहा है. यह जानकारी, यूनीक टेक्स्ट, रंग, आइकॉन या इनके किसी कॉम्बिनेशन के ज़रिए दी जाती है.

एक सेकंड तक दिखने के बाद, इंडिकेटर की विज़ुअल स्टाइल में बदलाव किया जा सकता है. जैसे, छोटा हो जाना. यह ज़रूरी नहीं है कि इंडिकेटर, उसी स्टाइल में दिखे जिसमें उसे मूल रूप से दिखाया गया था और समझा गया था.

माइक्रोफ़ोन इंडिकेटर को, चालू कैमरे के इंडिकेटर के साथ मर्ज किया जा सकता है. हालांकि, यह ज़रूरी है कि टेक्स्ट, आइकॉन या रंगों से उपयोगकर्ता को यह पता चले कि माइक्रोफ़ोन का इस्तेमाल शुरू हो गया है.

कैमरे के इंडिकेटर को, चालू माइक्रोफ़ोन के इंडिकेटर के साथ मर्ज किया जा सकता है. हालांकि, यह ज़रूरी है कि टेक्स्ट, आइकॉन या रंगों से उपयोगकर्ता को यह पता चले कि कैमरे का इस्तेमाल शुरू हो गया है.

अगर डिवाइसों में android.hardware.microphone का एलान किया जाता है, तो:

[C-SR-1] यह सुझाव दिया जाता है कि जब कोई ऐप्लिकेशन माइक्रोफ़ोन से ऑडियो डेटा ऐक्सेस कर रहा हो, तब माइक्रोफ़ोन इंडिकेटर दिखाया जाए. हालांकि, ऐसा तब नहीं होना चाहिए, जब माइक्रोफ़ोन को सिर्फ़ HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService या सेक्शन 9.1 में बताई गई भूमिकाओं वाले ऐप्लिकेशन [C-3-X] ऐक्सेस कर रहे हों.
[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 ओपन सोर्स प्रोजेक्ट में दिए गए हैं.
[C-0-2] डिवाइस में, उपयोगकर्ता के रूट सीए स्टोर में कोई भी सर्टिफ़िकेट नहीं होना चाहिए.
[C-0-3] जब कोई उपयोगकर्ता रूट सीए जोड़ता है, तो उसे एक चेतावनी दिखानी चाहिए. इसमें यह बताया गया हो कि नेटवर्क ट्रैफ़िक की निगरानी की जा सकती है.

अगर डिवाइस का ट्रैफ़िक वीपीएन से होकर जाता है, तो डिवाइस पर लागू होने वाली ये सेटिंग काम नहीं करेंगी:

[C-1-1] उपयोगकर्ता को चेतावनी दिखनी चाहिए, जिसमें इनमें से कोई एक बात बताई गई हो:
- उस नेटवर्क ट्रैफ़िक की निगरानी की जा सकती है.
- यह नेटवर्क ट्रैफ़िक, वीपीएन की सुविधा देने वाले किसी वीपीएन ऐप्लिकेशन से होकर गुज़र रहा है.

अगर डिवाइसों में ऐसा सिस्टम मौजूद है जो डिफ़ॉल्ट रूप से चालू होता है और नेटवर्क डेटा ट्रैफ़िक को प्रॉक्सी सर्वर या वीपीएन गेटवे से होकर गुज़रने देता है (उदाहरण के लिए, android.permission.CONTROL_VPN की अनुमति के साथ वीपीएन सेवा को पहले से लोड करना), तो:

[C-2-1] उस वीपीएन को चालू करने से पहले, उपयोगकर्ता की सहमति लेना ज़रूरी है. हालांकि, अगर डिवाइस नीति कंट्रोलर ने DevicePolicyManager.setAlwaysOnVpnPackage() के ज़रिए वीपीएन चालू किया है, तो उपयोगकर्ता की सहमति लेना ज़रूरी नहीं है. ऐसे में, उपयोगकर्ता को सिर्फ़ सूचना दी जानी चाहिए.

अगर डिवाइसों पर, तीसरे पक्ष के वीपीएन ऐप्लिकेशन की "हमेशा चालू रहने वाला वीपीएन" सुविधा को चालू करने के लिए, उपयोगकर्ता को आसानी से विकल्प मिलता है, तो:

[C-3-1] जिन ऐप्लिकेशन में AndroidManifest.xml फ़ाइल के ज़रिए हमेशा चालू रहने वाली वीपीएन सेवा काम नहीं करती उनके लिए, उपयोगकर्ता को यह सुविधा बंद करनी होगी. इसके लिए, SERVICE_META_DATA_SUPPORTS_ALWAYS_ON एट्रिब्यूट को false पर सेट करें.

9.8.5. डिवाइस आइडेंटिफ़ायर

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-1] ऐप्लिकेशन को डिवाइस के सीरियल नंबर का ऐक्सेस नहीं मिलना चाहिए. साथ ही, जहां लागू हो वहां IMEI/MEID, सिम का सीरियल नंबर, और इंटरनैशनल मोबाइल सब्सक्राइबर आइडेंटिटी (आईएमएसआई) का ऐक्सेस भी नहीं मिलना चाहिए. हालांकि, अगर ऐप्लिकेशन इनमें से कोई एक ज़रूरी शर्त पूरी करता है, तो उसे ऐक्सेस मिल सकता है:
- यह मोबाइल और इंटरनेट सेवा देने वाली कंपनी का ऐसा ऐप्लिकेशन है जिस पर हस्ताक्षर किया गया है. इसकी पुष्टि डिवाइस बनाने वाली कंपनियां करती हैं.
- को READ_PRIVILEGED_PHONE_STATE की अनुमति दी गई हो.
- उसके पास यूआईसीसी कैरियर के खास अधिकार में बताए गए कैरियर के खास अधिकार हों.
- डिवाइस का मालिक या प्रोफ़ाइल का मालिक हो और उसे READ_PHONE_STATE अनुमति दी गई हो.
- (सिर्फ़ सिम सीरियल नंबर/आईसीसीआईडी के लिए) स्थानीय नियमों के मुताबिक, ऐप्लिकेशन को सदस्य की पहचान में हुए बदलावों का पता लगाना होगा.

9.8.6. ओएस-लेवल और आस-पास के डेटा को सुरक्षित रखने वाला

Android, सिस्टम एपीआई के ज़रिए डिवाइसों को इस तरह से लागू करने की सुविधा देता है कि वे इस संवेदनशील डेटा को कैप्चर कर सकें:

स्क्रीन पर रेंडर किया गया टेक्स्ट और ग्राफ़िक. इसमें ये शामिल हैं, लेकिन इन तक सीमित नहीं हैं: AssistStructure API के ज़रिए सूचनाएं और Assistant का डेटा, स्क्रीन-बफ़र कैप्चर करने की गतिविधियां, और डिवाइस की स्क्रीन पर मौजूद कॉन्टेंट को रिकॉर्ड करना.

डिवाइस से रिकॉर्ड किया गया या चलाया गया मीडिया डेटा, जैसे कि ऑडियो या वीडियो.
इनपुट इवेंट (जैसे, कीबोर्ड, माउस, जेस्चर, आवाज़, वीडियो, और ऐक्सेसिबिलिटी).
सिस्टम को AugmentedAutofillService के ज़रिए भेजी गई कोई भी स्क्रीन या अन्य डेटा.
कोई भी स्क्रीन या अन्य डेटा, जिसे Content Capture एपीआई के ज़रिए ऐक्सेस किया जा सकता है.
AppSearchManager एपीआई के ज़रिए सिस्टम को भेजा गया कोई भी ऐप्लिकेशन डेटा. इसे AppSearchGlobalManager.query के ज़रिए ऐक्सेस किया जा सकता है.
सिस्टम TextClassifier को TextClassifier API के ज़रिए भेजा गया कोई भी टेक्स्ट या अन्य डेटा.इसका मतलब है कि सिस्टम सेवा को टेक्स्ट का मतलब समझने के लिए भेजा गया डेटा. साथ ही, टेक्स्ट के आधार पर अनुमानित अगली कार्रवाइयां जनरेट करने के लिए भेजा गया डेटा.
AppSearch को लागू करने वाले प्लैटफ़ॉर्म से इंडेक्स किया गया डेटा. इसमें टेक्स्ट, ग्राफ़िक, मीडिया डेटा या मिलता-जुलता अन्य डेटा शामिल है. हालांकि, इसमें और भी डेटा शामिल हो सकता है.
स्पीच रिकॉग्नाइज़र को लागू करने के लिए, SpeechRecognizer#onDeviceSpeechRecognizer() का इस्तेमाल करने से मिला ऑडियो डेटा.
AudioRecord, SoundTrigger या अन्य ऑडियो एपीआई के ज़रिए बैकग्राउंड में (लगातार) इकट्ठा किया गया ऑडियो डेटा. साथ ही, इस डेटा को इकट्ठा करने के दौरान उपयोगकर्ता को कोई इंडिकेटर नहीं दिखता
CameraManager या अन्य कैमरा एपीआई के ज़रिए बैकग्राउंड में (लगातार) कैमरा डेटा इकट्ठा किया जा रहा है. साथ ही, इससे उपयोगकर्ता को कोई इंडिकेटर नहीं दिख रहा है

DynamicInstrumentationEventService से कैप्चर किया गया कोई भी डेटा

अगर डिवाइसों पर लागू किए गए सिस्टम, ऊपर दिए गए संवेदनशील डेटा को कैप्चर या शेयर करते हैं, तो: उपयोगकर्ता के इरादे या उपयोगकर्ता को दिखने वाले निजता इंडिकेटर के बिना, डेटा को सुरक्षित एक्ज़ीक्यूशन एनवायरमेंट में प्रोसेस किया जाना चाहिए. इस एनवायरमेंट में:

[C-1-1] डिवाइस में सेव किए गए या ट्रांसफ़र किए जा रहे ऐसे सभी डेटा को एन्क्रिप्ट (सुरक्षित) करना ज़रूरी है. इस एन्क्रिप्शन को Android के फ़ाइल आधारित एन्क्रिप्शन या Cipher SDK में बताए गए, एपीआई वर्शन 26+ के तौर पर लिस्ट किए गए किसी भी सिफ़र का इस्तेमाल करके किया जा सकता है.
[C-1-2] ऊपर बताए गए संवेदनशील डेटा का बैक अप लेने के लिए, Android के बैकअप लेने के तरीकों या बैकअप लेने के किसी अन्य तरीके का इस्तेमाल करके, रॉ या एन्क्रिप्ट (सुरक्षित) किए गए डेटा का बैक अप नहीं लेना चाहिए.

[C-1-3] इस तरह का डेटा, डिवाइस से बाहर नहीं भेजा जाना चाहिए. हालांकि, ऐसा इन स्थितियों में किया जा सकता है:
- जब उपयोगकर्ता के मकसद ^* के हिसाब से, डेटा को शेयर करने के लिए साफ़ तौर पर कहा गया हो.
- निजता की सुरक्षा करने वाले किसी तरीके का इस्तेमाल करते समय. जैसे, डिफ़रेंशियल प्राइवसी टेक्नोलॉजी, जैसे कि RAPPOR या कॉन्फ़िडेंशियल फ़ेडरेटेड कंप्यूटेशन.
- जब डेटा को सुरक्षित एक्ज़ीक्यूशन एनवायरमेंट में प्रोसेस किया जाता है, तो यह सेवा देने वाली कंपनी और इन्फ़्रास्ट्रक्चर से सुरक्षित रहता है. जैसे, एडमिन का ऐक्सेस न होना, गोपनीय वीएम, रिमोट अटेस्टेशन, निजी डेटा का बाहर न जाना, लॉगिंग बंद होना, आईपी एड्रेस को छिपाना, और एन्क्रिप्शन.
  - इस तरीके का इस्तेमाल करने वाले सभी ऐप्लिकेशन में, उपयोगकर्ताओं के लिए ऑप्ट-आउट करने का विकल्प होना चाहिए.

[C-1-3] MAY, डेटा को भरोसेमंद कंप्यूटिंग बेस क्लाउड एनवायरमेंट के ज़रिए प्रोसेस कर सकता है.यह एनवायरमेंट, डेटा को सेवा देने वाली कंपनी और इंफ़्रास्ट्रक्चर से सुरक्षित रखता है. उदाहरण के लिए, एडमिन का ऐक्सेस नहीं, गोपनीय वीएम, रिमोट एटेस्टेशन, निजी डेटा का कोई इग्रेस नहीं, लॉगिंग बंद है, आईपी ब्लेंडिंग, और एन्क्रिप्शन. इस तरीके का इस्तेमाल करके लागू किया गया कोई भी कोड:
- उपयोगकर्ताओं को ऑप्ट आउट करने का विकल्प देना ज़रूरी है. साथ ही,
- उपयोगकर्ताओं को ऐसा तरीका उपलब्ध कराना होगा जिससे वे ऐक्सेस किए जा सकने वाले और पूरी जानकारी वाले लॉग जनरेट कर सकें. इनमें एनवायरमेंट में डेटा के आने और जाने की जानकारी शामिल हो.

[C-1-4] इस तरह के डेटा को डिवाइस पर मौजूद किसी भी उपयोगकर्ता की पहचान (जैसे कि Account) से नहीं जोड़ा जाना चाहिए. हालांकि, डेटा को हर बार जोड़ने से पहले, उपयोगकर्ता की साफ़ तौर पर सहमति ली जानी चाहिए.

[C-1-4] MAY show this data on system owned UI surfaces.

[C-1-5] किसी भी उपयोगकर्ता की पहचान (जैसे कि Account) के साथ ऐसे डेटा को जोड़ा नहीं जाना चाहिए. साथ ही, हर बार शेयर करने से पहले उपयोगकर्ता की साफ़ तौर पर सहमति लेनी चाहिए. हर बार डेटा को जोड़ा जाता है या एसोसिएशन, ओएस के उन कॉम्पोनेंट के साथ नहीं जोड़ा जाएगा जो इस सेक्शन (9.8.6 ओएस-लेवल और आस-पास के डेटा) में बताई गई ज़रूरी शर्तों का पालन नहीं करते हैं. हर बार शेयर करने से पहले उपयोगकर्ता की साफ़ तौर पर सहमति लेनी चाहिए. जब तक ऐसी सुविधा को Android SDK API (AmbientContext, HotwordDetectionService) के तौर पर नहीं बनाया जाता.
[C-1-6] उपयोगकर्ता को ऐसा डेटा मिटाने की सुविधा देनी होगी जिसे डिवाइस पर किसी भी फ़ॉर्म में सेव किए जाने पर, लागू करने का तरीका या मालिकाना हक वाला तरीका इकट्ठा करता है. या भरोसेमंद कंप्यूटिंग बेस क्लाउड एनवायरमेंट में. अगर उपयोगकर्ता डेटा मिटाने का विकल्प चुनता है, तो इकट्ठा किया गया सारा पुराना डेटा मिटाना ज़रूरी है.

[C-1-7] उपयोगकर्ता को, AppSearch या मालिकाना हक वाले तरीकों से इकट्ठा किए गए डेटा को Android प्लैटफ़ॉर्म (जैसे, लॉन्चर) में दिखाए जाने से ऑप्ट-आउट करने की सुविधा देनी होगी.

[C-1-8] सुलभ और पूरी जानकारी देने वाले ऐसे लॉग जनरेट करने का तरीका उपलब्ध कराना होगा जिनमें एनवायरमेंट में डेटा के इनग्रैस और इग्रेस की जानकारी दी गई हो.
[C-1-9] इसके पास सीधे तौर पर इंटरनेट का ऐक्सेस नहीं होना चाहिए.
[C-1-10] यूज़र इंटरफ़ेस (यूआई) को रिमोटली दिखाया जा सकता है. हालांकि, यह ज़रूरी है कि यूज़र इंटरफ़ेस (यूआई) दिखाने वाले होस्ट ऐप्लिकेशन को कोई डेटा न दिखे.
[C-1-11] सेवाओं को सिस्टम के अन्य कॉम्पोनेंट से अलग रखना होगा. उदाहरण के लिए, सेवा को सुरक्षित एक्ज़ीक्यूशन एनवायरमेंट में लागू नहीं किया जा सकता या प्रोसेस आईडी शेयर नहीं किए जा सकते.
[C-1-12] संवेदनशील डेटा को सिर्फ़ तब बाहर जाने की अनुमति मिलनी चाहिए, जब:
- डेटा शेयर करने के हर बार, उपयोगकर्ता के मकसद* के हिसाब से साफ़ तौर पर शुरू किया गया हो; या
- निजता बनाए रखने वाले किसी तरीके का इस्तेमाल करना. जैसे, डिफ़रेंशियल प्राइवसी टेक्नोलॉजी, जैसे कि RAPPOR / गोपनीय फ़ेडरेटेड कंप्यूटेशन.
[C-1-13] सिर्फ़ इन तरीकों से संवेदनशील डेटा को बाहर भेजने की अनुमति दी जानी चाहिए:
- सिस्टम की ऐसी सेवा जिसे PCCSandbox सिस्टम सेवा में अनुमति दी गई हो. साथ ही, वह सुरक्षित एक्ज़ीक्यूशन एनवायरमेंट (9.8.6) से जुड़ी ज़रूरी शर्तों का पालन करती हो या
- तय किया गया Private Compute Core (PCC) Gateway APK (9.8.15 में बताया गया है).
[C-1-14] संवेदनशील डेटा से अनुमानित डेटा का क्लाउड बैक-अप नहीं लेना चाहिए.ऐसा तब तक नहीं करना चाहिए, जब तक कि डेटा को एंड-टू-एंड एन्क्रिप्ट (सुरक्षित) न किया गया हो. उदाहरण के लिए, Android Backup Service का इस्तेमाल करके.

[C-SR-1] इंटरनेट की अनुमति का अनुरोध न करने का सुझाव दिया जाता है.
[C-SR-2] सिर्फ़ ऐसे स्ट्रक्चर्ड एपीआई के ज़रिए इंटरनेट ऐक्सेस करने का सुझाव दिया जाता है जो सार्वजनिक तौर पर उपलब्ध ओपन-सोर्स इंप्लीमेंटेशन पर आधारित हों.
[C-SR-4] इन्हें Android SDK API या ओईएम के मालिकाना हक वाली मिलती-जुलती ओपन-सोर्स रिपॉज़िटरी के साथ लागू करने का सुझाव दिया जाता है. इसके अलावा, इन्हें सैंडबॉक्स किए गए तरीके से लागू किया जा सकता है. सैंडबॉक्स किए गए API को लागू करने के तरीके के बारे में जानने के लिए, 9.8.15 देखें.

अगर डिवाइसों में ऐसी सेवा शामिल है जो System API ContentCaptureService, AppSearchManager.index, DynamicInstrumentationEventService, या ऊपर बताई गई किसी मालिकाना हक वाली सेवा को लागू करती है, तो:

[C-2-1] उपयोगकर्ताओं को, सेवाओं को उपयोगकर्ता के इंस्टॉल किए जा सकने वाले ऐप्लिकेशन या सेवा से बदलने की अनुमति नहीं देनी चाहिए. साथ ही, सिर्फ़ पहले से इंस्टॉल की गई सेवाओं को इस तरह का डेटा इकट्ठा करने की अनुमति देनी चाहिए.
[C-2-2] पहले से इंस्टॉल की गई सेवाओं के अलावा, किसी भी अन्य ऐप्लिकेशन को इस तरह का डेटा कैप्चर करने की अनुमति नहीं होनी चाहिए.
[C-2-3] सेवाओं को बंद करने के लिए, उपयोगकर्ता को साफ़ तौर पर और आसानी से ऐक्सेस किया जा सकने वाला विकल्प देना ज़रूरी है.
[C-2-4] उपयोगकर्ता को Android की उन अनुमतियों को मैनेज करने का विकल्प देना ज़रूरी है जो सेवाओं के पास हैं. साथ ही, धारा 9.1 में बताए गए Android की अनुमतियों वाले मॉडल का पालन करना ज़रूरी है. अनुमति.
[C-SR-3] सेवाओं को अन्य सिस्टम कॉम्पोनेंट से अलग रखने का सुझाव दिया जाता है.जैसे, सेवा को बाइंड न करना या प्रोसेस आईडी शेयर न करना. हालांकि, इन मामलों में ऐसा नहीं किया जा सकता:
- टेलीफ़ोनी, संपर्क, सिस्टम यूज़र इंटरफ़ेस (यूआई), और मीडिया

9.8.7. क्लिपबोर्ड का ऐक्सेस

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-1] क्लिपबोर्ड से काटा गया डेटा (जैसे, ClipboardManager एपीआई के ज़रिए) तब तक वापस नहीं भेजा जाना चाहिए, जब तक तीसरे पक्ष का ऐप्लिकेशन डिफ़ॉल्ट आईएमई न हो या वह ऐप्लिकेशन न हो जिस पर फ़िलहाल फ़ोकस किया जा रहा है.
[C-0-2] क्लिपबोर्ड में डेटा सेव होने या क्लिपबोर्ड से डेटा पढ़ने के 60 मिनट के अंदर, क्लिपबोर्ड का डेटा मिट जाना चाहिए.

9.8.8. जगह

जगह की जानकारी में, Android Location क्लास में मौजूद जानकारी शामिल होती है. जैसे, अक्षांश, देशांतर, ऊंचाई. साथ ही, इसमें ऐसे आइडेंटिफ़ायर भी शामिल होते हैं जिन्हें जगह की जानकारी में बदला जा सकता है. लोकेशन की जानकारी, डीजीपीएस (डिफ़रेंशियल ग्लोबल पोज़िशनिंग सिस्टम) जितनी सटीक या देश के लेवल की लोकेशन (जैसे कि देश के कोड की लोकेशन - एमसीसी - मोबाइल कंट्री कोड) जितनी सामान्य हो सकती है.

यहां दी गई सूची में, जगह की जानकारी के ऐसे टाइप दिए गए हैं जिनसे सीधे तौर पर उपयोगकर्ता की जगह की जानकारी मिलती है या जिन्हें उपयोगकर्ता की जगह की जानकारी में बदला जा सकता है. यह पूरी सूची नहीं है. हालांकि, इसका इस्तेमाल इस उदाहरण के तौर पर किया जाना चाहिए कि जगह की जानकारी को सीधे तौर पर या किसी और तरीके से कहां से लिया जा सकता है:

जीपीएस/जीएनएसएस/डीजीपीएस/पीपीपी
- ग्लोबल पोज़िशनिंग सॉल्यूशन या ग्लोबल नेविगेशन सैटलाइट सिस्टम या डिफ़रेंशियल ग्लोबल पोज़िशनिंग सॉल्यूशन
- इसमें जीएनएसएस के मेज़रमेंट से जुड़ा रॉ डेटा और जीएनएसएस स्टेटस भी शामिल है
  - जीएनएसएस के रॉ मेज़रमेंट से सटीक जगह की जानकारी का पता लगाया जा सकता है
यूनीक आइडेंटिफ़ायर वाली वायरलेस टेक्नोलॉजी, जैसे कि:
- वाई-फ़ाई ऐक्सेस पॉइंट (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] यह पक्का करना ज़रूरी है कि Emergency Location Bypass API LocationRequest.setLocationSettingsIgnored() का इस्तेमाल करने वाला ऐप्लिकेशन, उपयोगकर्ता की ओर से शुरू की गई आपातकालीन स्थिति से जुड़ा सेशन हो. जैसे, 911 पर कॉल करना या 911 पर मैसेज भेजना. हालांकि, कार के लिए, क्रैश/दुर्घटना का पता चलने पर, वाहन बिना उपयोगकर्ता की सक्रिय बातचीत के आपातकालीन सेशन शुरू कर सकता है. जैसे, eCall की ज़रूरी शर्तों को पूरा करने के लिए.
[C-0-4] डिवाइस की जगह की जानकारी की सेटिंग में बदलाव किए बिना, इमरजेंसी लोकेशन बाईपास एपीआई को डिवाइस की जगह की जानकारी की सेटिंग को बाईपास करने की सुविधा बनाए रखनी होगी.
[C-0-5] ऐप्लिकेशन को बैकग्राउंड में ACCESS_BACKGROUND_LOCATION अनुमति का इस्तेमाल करके, उपयोगकर्ता की जगह की जानकारी ऐक्सेस करने के बाद, सूचना शेड्यूल करनी होगी. इस सूचना में, उपयोगकर्ता को इस बारे में याद दिलाया जाएगा.

जब सिस्टम से बाहर का कोई ऐप्लिकेशन, डिवाइस की जगह की सटीक जानकारी को ऐक्सेस कर रहा होता है, तब डिवाइस:

[C-SR-1] उपयोगकर्ता को दिखने वाला इंडिकेटर दिखाने का सुझाव दिया जाता है

9.8.9. इंस्टॉल किए गए ऐप्लिकेशन

एपीआई लेवल 30 या इसके बाद के वर्शन को टारगेट करने वाले Android ऐप्लिकेशन, डिफ़ॉल्ट रूप से इंस्टॉल किए गए अन्य ऐप्लिकेशन की जानकारी नहीं देख सकते. इसके बारे में जानने के लिए, Android SDK के दस्तावेज़ में पैकेज की जानकारी दिखने की सुविधा देखें.

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-1] एपीआई लेवल 30 या इससे ऊपर के लेवल को टारगेट करने वाले किसी भी ऐप्लिकेशन को, इंस्टॉल किए गए किसी अन्य ऐप्लिकेशन के बारे में जानकारी नहीं देनी चाहिए. हालांकि, अगर ऐप्लिकेशन मैनेज किए गए एपीआई के ज़रिए, इंस्टॉल किए गए किसी अन्य ऐप्लिकेशन के बारे में जानकारी देख सकता है, तो ऐसा किया जा सकता है. इसमें डिवाइस बनाने वाली कंपनी या फ़ाइल सिस्टम के ज़रिए ऐक्सेस किए जा सकने वाले किसी भी कस्टम एपीआई से मिली जानकारी शामिल है. हालांकि, इसमें और भी चीज़ें शामिल हो सकती हैं.
[C-0-2] बाहरी स्टोरेज में मौजूद किसी अन्य ऐप्लिकेशन की ऐप्लिकेशन के लिए खास तौर पर बनाई गई डायरेक्ट्री में मौजूद फ़ाइलों को पढ़ने या उनमें बदलाव करने का ऐक्सेस किसी भी ऐप्लिकेशन को नहीं देना चाहिए. हालांकि, इन मामलों में ऐसा नहीं होता:
- बाहरी स्टोरेज की सुविधा देने वाली कंपनी (जैसे, DocumentsUI जैसे ऐप्लिकेशन).
- Download Provider, "downloads" provider authority का इस्तेमाल करता है. इससे ऐप्लिकेशन के स्टोरेज में फ़ाइलें डाउनलोड की जा सकती हैं.
- ऐसे मीडिया ट्रांसफ़र प्रोटोकॉल (एमटीपी) ऐप्लिकेशन जिन पर प्लैटफ़ॉर्म के हस्ताक्षर होते हैं. ये ऐप्लिकेशन, फ़ाइलों को किसी दूसरे डिवाइस पर ट्रांसफ़र करने के लिए, खास अनुमति ACCESS_MTP का इस्तेमाल करते हैं.
- अन्य ऐप्लिकेशन इंस्टॉल करने वाले और INSTALL_PACKAGES अनुमति वाले ऐप्लिकेशन, APK एक्सपैंशन फ़ाइलों को मैनेज करने के लिए सिर्फ़ "obb" डायरेक्ट्री ऐक्सेस कर सकते हैं.

9.8.10. कनेक्टिविटी से जुड़ी गड़बड़ी की रिपोर्ट

अगर डिवाइसों में android.hardware.telephony सुविधा फ़्लैग का एलान किया जाता है, तो:

[C-1-1] डिवाइस में, BugreportManager की मदद से BUGREPORT_MODE_TELEPHONY के ज़रिए कनेक्टिविटी से जुड़ी गड़बड़ियों की शिकायत जनरेट करने की सुविधा होनी चाहिए.
[C-1-2] रिपोर्ट जनरेट करने के लिए, BUGREPORT_MODE_TELEPHONY का इस्तेमाल हर बार उपयोगकर्ता की सहमति लेने के बाद ही किया जाना चाहिए. साथ ही, उपयोगकर्ता को ऐप्लिकेशन से मिलने वाले सभी अनुरोधों के लिए सहमति देने के लिए नहीं कहा जाना चाहिए.
[C-1-3] अनुरोध करने वाले ऐप्लिकेशन को जनरेट की गई रिपोर्ट तब तक नहीं भेजनी चाहिए, जब तक उपयोगकर्ता ने साफ़ तौर पर सहमति न दी हो.
[C-1-4] BUGREPORT_MODE_TELEPHONY का इस्तेमाल करके जनरेट की गई रिपोर्ट में, कम से कम यह जानकारी ज़रूर होनी चाहिए:
- TelephonyDebugService डंप
- TelephonyRegistry डंप
- WifiService डंप
- ConnectivityService डंप
- कॉल करने वाले पैकेज के CarrierService इंस्टेंस का डंप (अगर बाइंड किया गया हो)
- रेडियो लॉग बफ़र
- SubscriptionManagerService डंप
[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, सिस्टम एपीआई MusicRecognitionManager के ज़रिए, डिवाइसों पर लागू होने वाले एक ऐसे सिस्टम को सपोर्ट करता है जो ऑडियो रिकॉर्डिंग के आधार पर संगीत की पहचान करने का अनुरोध कर सकता है. साथ ही, संगीत की पहचान करने की सुविधा को ऐसे ऐप्लिकेशन को सौंप सकता है जिसके पास MusicRecognitionService एपीआई को लागू करने का खास अधिकार है.

अगर डिवाइस में ऐसी सेवा शामिल है जो System API MusicRecognitionManager को लागू करती है या कोई ऐसी मालिकाना सेवा है जो ऊपर बताए गए तरीके से ऑडियो डेटा स्ट्रीम करती है, तो:

[C-1-1] MUST enforce that the caller of MusicRecognitionManager holds the MANAGE_MUSIC_RECOGNITION permission
[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] जब कोई ऐप्लिकेशन, ब्लॉक किए गए माइक्रोफ़ोन या कैमरे को ऐक्सेस करने की कोशिश करता है, तो उसे उपयोगकर्ता को एक ऐसा विकल्प दिखाना होगा जिसे खारिज नहीं किया जा सकता. इसमें साफ़ तौर पर यह बताया गया हो कि सेंसर ब्लॉक है और उसे ब्लॉक करना जारी रखने या अनब्लॉक करने के लिए, उपयोगकर्ता को विकल्प चुनना होगा. यह विकल्प, एओएसपी के उस वर्शन के मुताबिक होना चाहिए जो इस ज़रूरी शर्त को पूरा करता है.
[C-1-3] को सिर्फ़ ऐप्लिकेशन को कैमरा और ऑडियो का खाली (या नकली) डेटा पास करना होगा. साथ ही, उपयोगकर्ता के कैमरा चालू न करने की वजह से, गड़बड़ी का कोड रिपोर्ट नहीं करना होगा. इसके अलावा, ऊपर दिए गए [C-1-2] के मुताबिक, उपयोगकर्ता को उपलब्ध कराए गए विकल्प के ज़रिए माइक्रोफ़ोन चालू न करने की वजह से भी गड़बड़ी का कोड रिपोर्ट नहीं करना होगा.

9.8.14. लागू नहीं

9.8.15. Private Compute Core और Gateway Application को लागू करना

Android, डेलिगेट एपीआई के सेट के ज़रिए, ओएस-लेवल और आस-पास के डेटा को सुरक्षित तरीके से प्रोसेस करने का तरीका उपलब्ध कराता है. इस तरह की प्रोसेसिंग को, पहले से इंस्टॉल किए गए ऐसे APK को सौंपा जा सकता है जिसके पास खास अधिकार हों और कम्यूनिकेशन की क्षमताएं कम हों. इसे Sandboxed API Implementation कहा जाता है.

डिवाइसों पर ऐसे ऐप्लिकेशन लागू किए जाते हैं जो सेक्शन 9.8.6 (ओएस-लेवल और आस-पास की जानकारी) में बताए गए संवेदनशील डेटा को डिवाइस पर प्रोसेस करते हैं. ऐसे में, हमारा सुझाव है कि वे नीचे बताए गए Private Compute Core (PCC) फ़्रेमवर्क का इस्तेमाल करें.

सैंडबॉक्स जनरेट करने के एपीआई को लागू करने के लिए, पीसीसी एनवायरमेंट में मौजूद कॉम्पोनेंट:

[C-0-1] यह ज़रूरी है कि INTERNET की अनुमति का अनुरोध न किया जाए.

[C-0-1] मेनिफ़ेस्ट फ़ाइल में, android:isPrivateComputeCoreProcess="true" एट्रिब्यूट के साथ इसका एलान किया जाना चाहिए.

[C-0-2] को सिर्फ़ ऐसे स्ट्रक्चर्ड एपीआई के ज़रिए इंटरनेट ऐक्सेस करना चाहिए जो निजता बनाए रखने के तरीकों का इस्तेमाल करके, सार्वजनिक तौर पर उपलब्ध ओपन-सोर्स इंप्लीमेंटेशन के साथ काम करते हैं. इसके अलावा, इसे Android SDK API के ज़रिए भी इंटरनेट ऐक्सेस करना चाहिए. निजता बनाए रखने वाले मेकेनिज़्म को इस तरह से परिभाषित किया गया है: "ऐसे मेकेनिज़्म जो सिर्फ़ एग्रीगेट किए गए डेटा का विश्लेषण करने की अनुमति देते हैं और लॉग किए गए इवेंट या निकाले गए नतीजों को अलग-अलग उपयोगकर्ताओं से मैच होने से रोकते हैं&quot.ऐसा इसलिए किया जाता है, ताकि किसी भी उपयोगकर्ता के डेटा की जांच न की जा सके. उदाहरण के लिए, इसे RAPPOR जैसी डिफ़रेंशियल प्राइवसी टेक्नोलॉजी का इस्तेमाल करके लागू किया जाता है.

[C-0-2] डिवाइस की सिस्टम इमेज पर पहले से लोड होना चाहिए.

[C-0-3] सेवाओं को अन्य सिस्टम कॉम्पोनेंट से अलग रखना ज़रूरी है. उदाहरण के लिए, सेवा को बाइंड न करना या प्रोसेस आईडी शेयर न करना इनके अलावा:
- टेलीफ़ोनी, संपर्क, सिस्टम यूज़र इंटरफ़ेस (यूआई), और मीडिया के लिए, पीसीसी यूआईडी के तौर पर लागू नहीं किए गए हैं).
[C-0-4] उपयोगकर्ताओं को, सेवाओं को ऐसे ऐप्लिकेशन या सेवा से बदलने की अनुमति नहीं देनी चाहिए जिसे उपयोगकर्ता इंस्टॉल कर सकता है
[C-0-5] MUST only allow the preinstalled services appointed by the OEM (holding an appropriate system role defined in PCC Manager System Service), and with appropriate permissions, to capture such data. जब तक कि AOSP में, किसी सुविधा को बदलने की क्षमता न हो (जैसे, डिजिटल असिस्टेंट ऐप्लिकेशन के लिए) 9.8.6 में बताए गए संवेदनशील आस-पास के डेटा को ऐक्सेस नहीं किया जा सकता.
[C-0-6] पहले से इंस्टॉल की गई सेवाओं के अलावा, किसी भी अन्य ऐप्लिकेशन को इस तरह का डेटा कैप्चर करने की अनुमति नहीं देनी चाहिए. जब तक कि इस तरह की कैप्चर करने की सुविधा, Android SDK API के साथ लागू न की गई हो.
[C-0-7] उपयोगकर्ता को सेवाओं को बंद करने का विकल्प देना ज़रूरी है.
[C-0-8] यह ज़रूरी है कि ऐप्लिकेशन में, उपयोगकर्ताओं को Android की उन अनुमतियों को मैनेज करने का विकल्प दिया गया हो जो सेवाओं के पास हैं. साथ ही, ऐप्लिकेशन में Android की अनुमतियों वाले मॉडल का पालन किया गया हो. इस मॉडल के बारे में सेक्शन 9.1 में बताया गया है. अनुमति.

[C-0-9] इसे एक खास प्रोसेस में चलाना ज़रूरी है. साथ ही, इसे फ़्रेमवर्क से असाइन किया गया एक यूनीक यूआईडी देना होगा. यह मुख्य ऐप्लिकेशन प्रोसेस और सैंडबॉक्स किए गए अन्य कॉम्पोनेंट से अलग होना चाहिए.

पीसीसी एनवायरमेंट के कॉम्पोनेंट को नेटवर्क ऐक्सेस करने के लिए, एक तय किए गए APK के ज़रिए प्रॉक्सी करना ज़रूरी है. यह APK, पीसीसी गेटवे ऐप्लिकेशन के तौर पर काम करता है. चुने गए कॉम्पोनेंट:

[C-1-1] को android.permission.PROVIDE_PRIVATE_COMPUTE_SERVICES की खास अनुमति दी जानी चाहिए. इस अनुमति से, ऐप्लिकेशन को पीसीसी गेटवे ऐप्लिकेशन के तौर पर तय किया जाता है.
[C-1-2] इसका सोर्स कोड सार्वजनिक तौर पर उपलब्ध होना चाहिए, ताकि इसकी पुष्टि की जा सके.
[C-1-3] किसी भी डेटा को बाहर भेजने के लिए, निजता की सुरक्षा करने वाले तरीकों का इस्तेमाल करना ज़रूरी है. इनके बारे में सेक्शन 9.8.6 में बताया गया है
[C-1-4] PCC फ़्रेमवर्क के ऑडिट मोड के साथ काम करना ज़रूरी है. इसमें नेटवर्क अनुरोधों, सर्वर एंडपॉइंट, और अन्य डेटा को लॉग करना शामिल है. यह डेटा, निजता बनाए रखने से जुड़ी सेटिंग चालू होने पर, निजता बनाए रखने से जुड़े व्यवहार की पुष्टि करने के लिए ज़रूरी होता है

9.8.16. ऑडियो और कैमरे का लगातार डेटा

अगर डिवाइसों पर लागू किए गए सिस्टम, सेक्शन 9.8.2 या सेक्शन 9.8.6 में बताए गए किसी भी डेटा को कैप्चर करते हैं और अगर वे AudioRecord, SoundTrigger या अन्य ऑडियो एपीआई के ज़रिए बैकग्राउंड में (लगातार) हासिल किए गए ऑडियो डेटा या CameraManager या अन्य कैमरा एपीआई के ज़रिए बैकग्राउंड में (लगातार) हासिल किए गए कैमरा डेटा का इस्तेमाल करते हैं, तो:

[C-0-1] कैमरे और/या माइक्रोफ़ोन के लिए, सेक्शन 9.8.2 में बताई गई रिकॉर्डिंग के मुताबिक इंडिकेटर दिखाना ज़रूरी है. हालांकि, ऐसा तब तक करना होगा, जब तक:
- यह ऐक्सेस, सैंडबॉक्स किए गए तरीके से लागू किया जाता है. इसके बारे में जानने के लिए, 9.8.15 सैंडबॉक्स किए गए एपीआई को लागू करने का तरीका देखें. यह ऐक्सेस, एक ऐसे पैकेज के ज़रिए किया जाता है जिसमें इनमें से एक या इससे ज़्यादा भूमिकाएँ होती हैं: System UI Intelligence, System Ambient Audio Intelligence, System Audio Intelligence, System Notification Intelligence, System Text Intelligence, या System Visual Intelligence.
- सैंडबॉक्स के ज़रिए ऐक्सेस किया जाता है. इसे AOSP (HotwordDetectionService, WearableSensingService, VisualQueryDetector) में मौजूद तरीकों के ज़रिए लागू किया जाता है और लागू किया जाता है.
- ऑडियो का ऐक्सेस, डिजिटल असिस्टेंट ऐप्लिकेशन को सुलभता से जुड़ी सुविधाओं के लिए दिया जाता है. यह SOURCE_HOTWORD को ऑडियो सोर्स के तौर पर उपलब्ध कराता है.
- सिस्टम, डेटा को ऐक्सेस करता है. साथ ही, इसे ओपन-सोर्स कोड की मदद से लागू किया जाता है.
[C-SR-1] हमारा सुझाव है कि इस तरह के डेटा का इस्तेमाल करने वाली हर सुविधा के लिए, उपयोगकर्ता की सहमति लेना ज़रूरी हो. साथ ही, यह सुविधा डिफ़ॉल्ट रूप से बंद हो.
[C-SR-2] हमारा सुझाव है कि रिमोट वियरेबल डिवाइस से मिलने वाले कैमरे के डेटा पर भी वही शर्तें लागू करें जो 9.8.2 रिकॉर्डिंग, 9.8.6 ओएस-लेवल और आस-पास के डेटा, 9.8.15 सैंडबॉक्स किए गए एपीआई के इस्तेमाल, और 9.8.16 लगातार ऑडियो और कैमरे के डेटा पर लागू होती हैं.

अगर डिवाइसों को रिमोट वियरेबल डिवाइस से कैमरा या माइक्रोफ़ोन का डेटा मिलता है और Android OS के बाहर, बिना एन्क्रिप्ट (सुरक्षित) किए गए फ़ॉर्म में डेटा ऐक्सेस किया जाता है, तो सैंडबॉक्स किए गए ऐप्लिकेशन या WearableSensingManager की बनाई गई सैंडबॉक्स की गई सुविधा को:

[C-1-1] रिमोट वियरेबल डिवाइस को यह जानकारी देनी होगी कि उसे वहां एक और इंडिकेटर दिखाना है.

अगर डिवाइस, असाइन किए गए कीवर्ड के बिना डिजिटल असिस्टेंट ऐप्लिकेशन से इंटरैक्ट करने की सुविधा देते हैं, तो:

[C-2-1] यह पक्का करना ज़रूरी है कि इस तरह के बदलाव, android.app.role.ASSISTANT की भूमिका निभाने वाले पैकेज से किए गए हों.
[C-2-2] यह पक्का करना होगा कि इस तरह के डेटा को लागू करने के लिए, HotwordDetectionService और/या VisualQueryDetectionService Android API का इस्तेमाल किया गया हो.

9.8.17. Telemetry

Android, StatsLog API का इस्तेमाल करके सिस्टम और ऐप्लिकेशन के लॉग सेव करता है. इन लॉग को StatsManager API के ज़रिए मैनेज किया जाता है. इनका इस्तेमाल खास सिस्टम ऐप्लिकेशन कर सकते हैं.

StatsManager, निजता बनाए रखने के तरीके का इस्तेमाल करने वाले डिवाइसों से, निजता के लिहाज़ से संवेदनशील डेटा इकट्ठा करने का तरीका भी उपलब्ध कराता है. खास तौर पर, StatsManager::query API की मदद से, पाबंदी वाली मेट्रिक कैटगरी के बारे में क्वेरी की जा सकती है. इन कैटगरी को StatsLog में तय किया गया है.

StatsManager से प्रतिबंधित मेट्रिक के लिए क्वेरी करने और उन्हें इकट्ठा करने वाला कोई भी तरीका:

[C-0-1] डिवाइस पर सिर्फ़ यही ऐप्लिकेशन/सुविधा लागू होनी चाहिए. साथ ही, इसके पास READ_RESTRICTED_STATS की अनुमति होनी चाहिए.
[C-0-2] डिवाइस को सिर्फ़ टेलीमेट्री डेटा और डिवाइस के लॉग भेजने चाहिए. इसके लिए, निजता बनाए रखने वाले तरीके का इस्तेमाल करना ज़रूरी है. निजता बनाए रखने वाले मेकेनिज़्म को इस तरह से परिभाषित किया गया है: "ऐसे मेकेनिज़्म जो सिर्फ़ एग्रीगेट किए गए डेटा का विश्लेषण करने की अनुमति देते हैं और लॉग किए गए इवेंट या निकाले गए नतीजों को अलग-अलग उपयोगकर्ताओं से मैच होने से रोकते हैं&quot.इससे किसी भी उपयोगकर्ता के डेटा की जांच नहीं की जा सकती. उदाहरण के लिए, इसे RAPPOR जैसी डिफ़रेंशियल प्राइवसी टेक्नोलॉजी का इस्तेमाल करके लागू किया जाता है.
[C-0-3] इस तरह के डेटा को डिवाइस पर मौजूद किसी भी उपयोगकर्ता की पहचान (जैसे कि खाता) से नहीं जोड़ा जाना चाहिए.
[C-0-4] इस तरह के डेटा को ओएस के उन कॉम्पोनेंट के साथ शेयर नहीं किया जाना चाहिए जो इस सेक्शन (9.8.17. टेलीमेट्री) को बंद कर दें.
[C-0-5] उपयोगकर्ता को निजता बनाए रखने वाली टेलीमेट्री के डेटा को इकट्ठा करने, इस्तेमाल करने, और शेयर करने की सुविधा को चालू/बंद करने का विकल्प देना ज़रूरी है.
[C-0-6] अगर डेटा को डिवाइस पर किसी भी फ़ॉर्म में सेव किया जाता है, तो उपयोगकर्ता को ऐसा डेटा मिटाने की सुविधा देनी होगी जिसे ऐप्लिकेशन इकट्ठा करता है. अगर उपयोगकर्ता ने डेटा मिटाने का विकल्प चुना है, तो डिवाइस पर सेव किया गया सारा डेटा मिटाना ज़रूरी है.
[C-0-7] निजता बनाए रखने वाले प्रोटोकॉल को लागू करने के बारे में, ओपन सोर्स रिपॉज़िटरी में जानकारी देना ज़रूरी है.
[C-0-8] इस सेक्शन में, डेटा को बाहर भेजने से जुड़ी नीतियों को लागू करना ज़रूरी है, ताकि StatsLog में तय की गई, प्रतिबंधित मेट्रिक कैटगरी में डेटा इकट्ठा करने पर रोक लगाई जा सके.

9.8.18. एजेंटिक फ़ंक्शन की निजता

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-1] MUST ensure any components executing AppFunctions hold either the EXECUTE_APP_FUNCTIONS or the EXECUTE_APP_FUNCTIONS_SYSTEM permission.
[C-0-2] AppFunction कॉल को सिर्फ़ उपयोगकर्ता की किसी कार्रवाई के नतीजे के तौर पर शुरू किया जाना चाहिए. साथ ही, उपयोगकर्ता को साफ़ तौर पर यह बताया जाना चाहिए कि कौनसे ऐप्लिकेशन को शुरू किया गया है और उस ऐप्लिकेशन में कौनसी मुख्य कार्रवाई की जानी है.
[C-0-3] तीसरे पक्ष के ऐप्लिकेशन की, AppFunctions को खोजने या उन्हें लागू करने के अनुरोध को प्रॉक्सी या उसमें बदलाव नहीं करना चाहिए. हालांकि, ऐसा तब किया जा सकता है, जब [C-0-1] और [C-0-2] की शर्तों को पूरा किया गया हो.
[C-0-4] सिस्टम कॉम्पोनेंट को ओएस-लेवल या आस-पास के माहौल से जुड़े संवेदनशील डेटा (9.8.6 ओएस-लेवल और आस-पास के माहौल से जुड़े डेटा की सुरक्षा में बताए गए अनुसार) या उसके डेरिवेटिव का इस्तेमाल करने की अनुमति नहीं देनी चाहिए. ऐसा तब तक नहीं किया जाना चाहिए, जब तक सिस्टम कॉम्पोनेंट 9.8.6 में बताए गए सुरक्षित एक्ज़ीक्यूशन एनवायरमेंट में काम न कर रहे हों. इस डेटा का इस्तेमाल, नज़ (लोगों का ध्यान खींचने के लिए इस्तेमाल किए जाने वाले तरीके) जनरेट करने या उन्हें पैरामीटर के तौर पर इस्तेमाल करने के लिए किया जाता है.

मुख्य शब्द: "नज" का मतलब है, सिस्टम की सतह से ऐप्लिकेशन में अपने-आप जनरेट होने वाला एंट्री पॉइंट. इसे उपयोगकर्ता की किसी कार्रवाई के बिना शुरू किया जाता है. नज का इस्तेमाल करके, किसी व्यक्ति को उसकी पसंद के हिसाब से कोई कार्रवाई करने के लिए सुझाव दिया जाता है या उसे गाइड किया जाता है.

9.9. डेटा स्टोरेज एन्क्रिप्शन

सभी डिवाइसों को सेक्शन 9.9.1 में दी गई ज़रूरी शर्तों को पूरा करना होगा. जिन डिवाइसों को इस दस्तावेज़ में बताए गए एपीआई लेवल से पहले लॉन्च किया गया था उन्हें सेक्शन 9.9.2 और 9.9.3 में बताई गई ज़रूरी शर्तों से छूट दी गई है. हालांकि, उन्हें Android Compatibility Definition document के सेक्शन 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 में बताए गए तरीके के मुताबिक, हर उपयोगकर्ता के लिए ब्लॉक-लेवल एन्क्रिप्शन.

ध्यान दें: एपीआई लेवल 28 या इससे पहले के वर्शन पर शिप किए गए डिवाइसों के लिए, सिस्टम सॉफ़्टवेयर अपडेट के ज़रिए 9.9.2 में दी गई ज़रूरी शर्तों को पूरा करना ज़रूरी है. साथ ही, Android Compatibility Definition document के सेक्शन 9.9 में दी गई ज़रूरी शर्तों को भी पूरा करना ज़रूरी है. ये ज़रूरी शर्तें, डिवाइस के शिपिंग के समय के एपीआई लेवल के हिसाब से तय की जाती हैं.

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] फ़ाइल के कॉन्टेंट और फ़ाइल सिस्टम के मेटाडेटा को AES-256-XTS या Adiantum का इस्तेमाल करके एन्क्रिप्ट (सुरक्षित) करना ज़रूरी है. AES-256-XTS का मतलब, 256-बिट साइफ़र कुंजी की लंबाई वाला Advanced Encryption Standard है. यह XTS मोड में काम करता है. कुंजी की पूरी लंबाई 512 बिट होती है. Adiantum का मतलब Adiantum-XChaCha12-AES है. इसके बारे में https://github.com/google/adiantum पर बताया गया है. फ़ाइल सिस्टम मेटाडेटा, फ़ाइल के साइज़, मालिकाना हक, मोड, और एक्सटेंडेड एट्रिब्यूट (xattrs) जैसे डेटा को कहते हैं.
[C-1-6] फ़ाइल के नामों को AES-256-CBC-CTS, AES-256-HCTR2 या Adiantum का इस्तेमाल करके एन्क्रिप्ट (सुरक्षित) करना ज़रूरी है.
[C-1-12] अगर डिवाइस में ऐडवांस एन्क्रिप्शन स्टैंडर्ड (एईएस) के निर्देश हैं (जैसे, ARM पर आधारित डिवाइसों पर ARMv8 क्रिप्टोग्राफ़ी एक्सटेंशन या x86 पर आधारित डिवाइसों पर AES-NI), तो फ़ाइल के नाम, फ़ाइल के कॉन्टेंट, और फ़ाइल सिस्टम के मेटाडेटा को एन्क्रिप्ट (सुरक्षित) करने के लिए, ऊपर दिए गए एईएस पर आधारित विकल्पों का इस्तेमाल करना ज़रूरी है. Adiantum का इस्तेमाल नहीं किया जाना चाहिए.
[C-1-13] CE और DE की से ज़रूरी सब-की (जैसे, हर फ़ाइल के लिए अलग-अलग की) पाने के लिए, क्रिप्टोग्राफ़िक तरीके से सुरक्षित और नॉन-रिवर्सिबल की डेरीवेशन फ़ंक्शन (जैसे, HKDF-SHA512) का इस्तेमाल करना ज़रूरी है. "क्रिप्टोग्राफ़िक तौर पर मज़बूत और वापस नहीं बदला जा सकता" का मतलब है कि कुंजी बनाने वाले फ़ंक्शन में कम से कम 256 बिट की सुरक्षा होती है. साथ ही, यह अपने इनपुट पर स्यूडोरैंडम फ़ंक्शन फ़ैमिली के तौर पर काम करता है.
[C-1-14] अलग-अलग क्रिप्टोग्राफ़िक कामों के लिए, एक ही फ़ाइल आधारित एन्क्रिप्शन (एफ़बीई) कुंजियों या सबकुंजियों का इस्तेमाल नहीं करना चाहिए. जैसे, एन्क्रिप्शन और कुंजी डेलिवरी, दोनों के लिए या दो अलग-अलग एन्क्रिप्शन एल्गोरिदम के लिए.
[C-1-15] यह पक्का करना ज़रूरी है कि परसिस्टेंट स्टोरेज पर, एन्क्रिप्ट (सुरक्षित) की गई फ़ाइल के कॉन्टेंट के सभी ब्लॉक को एन्क्रिप्ट (सुरक्षित) करने के लिए, एन्क्रिप्शन की और इनिशियलाइज़ेशन वेक्टर (आईवी) के कॉम्बिनेशन का इस्तेमाल किया गया हो. ये कॉम्बिनेशन, फ़ाइल और फ़ाइल में ऑफ़सेट, दोनों पर निर्भर करते हैं. इसके अलावा, इस तरह के सभी कॉम्बिनेशन अलग-अलग होने चाहिए. हालांकि, अगर एन्क्रिप्शन के लिए इनलाइन एन्क्रिप्शन हार्डवेयर का इस्तेमाल किया जा रहा है, तो ऐसा करना ज़रूरी नहीं है. यह हार्डवेयर सिर्फ़ 32 बिट की आईवी लेंथ के साथ काम करता है.
[C-1-16] यह पक्का करना ज़रूरी है कि अलग-अलग डायरेक्ट्री में मौजूद परसिस्टेंट स्टोरेज में, मिटाई नहीं गई सुरक्षित की गई सभी फ़ाइलों के नाम, एन्क्रिप्शन कुंजी और इनिशलाइज़ेशन वेक्टर (आईवी) के अलग-अलग कॉम्बिनेशन का इस्तेमाल करके सुरक्षित किए गए हों.
[C-1-17] यह पक्का करना ज़रूरी है कि परसिस्टेंट स्टोरेज पर मौजूद, एन्क्रिप्ट (सुरक्षित) किए गए फ़ाइल सिस्टम के सभी मेटाडेटा ब्लॉक को एन्क्रिप्शन की (कुंजी) और इनिशलाइज़ेशन वेक्टर (आईवी) के अलग-अलग कॉम्बिनेशन का इस्तेमाल करके एन्क्रिप्ट (सुरक्षित) किया गया हो.
ये कुंजियां, CE और DE स्टोरेज एरिया और फ़ाइल सिस्टम के मेटाडेटा को सुरक्षित रखती हैं:
- [C-1-7] इसे क्रिप्टोग्राफ़िक तरीके से, हार्डवेयर के समर्थन वाले कीस्टोर से बाइंड किया जाना चाहिए. यह कीस्टोर, वेरिफ़ाइड बूट और डिवाइस के हार्डवेयर रूट ऑफ़ ट्रस्ट से जुड़ा होना चाहिए.
- [C-1-8] CE कुंजियों को उपयोगकर्ता के लॉक स्क्रीन क्रेडेंशियल से बाइंड किया जाना चाहिए.
- [C-1-9] अगर उपयोगकर्ता ने लॉक स्क्रीन के क्रेडेंशियल नहीं दिए हैं, तो सीई कुंजियों को डिफ़ॉल्ट पासवर्ड से बाइंड किया जाना चाहिए.
- [C-1-10] यूनीक और अलग होना चाहिए. दूसरे शब्दों में कहें, तो किसी भी उपयोगकर्ता के CE या DE कुंजी का मिलान, किसी अन्य उपयोगकर्ता के CE या DE कुंजियों से नहीं होना चाहिए.
- [C-1-11] ज़रूरी तौर पर इस्तेमाल किए जाने वाले सिफ़र, कुंजी की लंबाई, और मोड का इस्तेमाल करना ज़रूरी है.
- [C-1-12] बूटलोडर को अनलॉक और लॉक करने के दौरान, यहां बताए गए तरीके से सुरक्षित तरीके से मिटाया जाना चाहिए.
डिवाइस में पहले से इंस्टॉल किए गए ज़रूरी ऐप्लिकेशन (जैसे, अलार्म, फ़ोन, Messenger) को डायरेक्ट बूट के बारे में पता होना चाहिए.

अपस्ट्रीम Android Open Source प्रोजेक्ट, Linux कर्नल की "fscrypt" एन्क्रिप्शन सुविधा के आधार पर, अलग-अलग फ़ाइलों को अलग-अलग तरीकों से एन्क्रिप्ट करने का तरीका उपलब्ध कराता है. साथ ही, Linux कर्नल की "dm-default-key" सुविधा के आधार पर, मेटाडेटा को एन्क्रिप्ट करने का तरीका उपलब्ध कराता है.

ध्यान दें: एपीआई लेवल 28 या इससे पहले के वर्शन पर शिप किए गए डिवाइसों के लिए, सिस्टम सॉफ़्टवेयर अपडेट के ज़रिए 9.9.3 में दी गई ज़रूरी शर्तों को पूरा करना ज़रूरी है. साथ ही, Android Compatibility Definition Document के सेक्शन 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 कर्नल की "dm-crypt" सुविधा का इस्तेमाल किया जा सकता है.

9.9.4. रीबूट करने के बाद फिर से शुरू करें

'रीबूट करने पर फिर से शुरू करें' सुविधा की मदद से, ओटीए अपडेट के बाद रीबूट किए गए डिवाइस पर, उन सभी ऐप्लिकेशन के सीई स्टोरेज को अनलॉक किया जा सकता है जो डायरेक्ट बूट की सुविधा के साथ काम नहीं करते. इस सुविधा की मदद से, रीबूट करने के बाद भी इंस्टॉल किए गए ऐप्लिकेशन से सूचनाएं मिलती हैं.

'फिर से चालू होने पर काम करना जारी रखें' सुविधा को लागू करने के दौरान यह पक्का करना ज़रूरी है कि अगर कोई डिवाइस हमलावर के हाथ लग जाता है, तो उसके लिए उपयोगकर्ता के CE-एन्क्रिप्ट (सुरक्षित) किए गए डेटा को वापस पाना बहुत मुश्किल हो. भले ही, डिवाइस चालू हो, CE स्टोरेज अनलॉक हो, और उपयोगकर्ता ने ओटीए मिलने के बाद डिवाइस को अनलॉक कर दिया हो. हम यह भी मानते हैं कि अंदरूनी व्यक्ति के हमले को रोकने के लिए, हमलावर को ब्रॉडकास्ट क्रिप्टोग्राफ़िक साइनिंग कुंजियों का ऐक्सेस मिल जाता है.

खास तौर से:

[C-0-1] सीई स्टोरेज को कोई भी व्यक्ति नहीं पढ़ सकता. यहां तक कि वह हमलावर भी इसे नहीं पढ़ सकता जिसके पास डिवाइस का ऐक्सेस है. हालांकि, उसके पास ये सुविधाएं और सीमाएं होनी चाहिए:
- आर्बिट्रेरी मैसेज पर हस्ताक्षर करने के लिए, किसी भी वेंडर या कंपनी की साइनिंग पासकोड का इस्तेमाल कर सकता है.
- इससे डिवाइस को ओटीए मिल सकता है.
- नीचे दी गई जानकारी के मुताबिक, किसी भी हार्डवेयर (एपी, फ़्लैश वगैरह) के ऑपरेशन में बदलाव किया जा सकता है. हालांकि, इस तरह के बदलाव में कम से कम एक घंटे की देरी होती है. साथ ही, पावर साइकल की वजह से रैम का कॉन्टेंट मिट जाता है.
- छेड़छाड़ से सुरक्षित हार्डवेयर (जैसे, Titan M) के काम करने के तरीके में बदलाव नहीं किया जा सकता.
- लाइव डिवाइस की रैम को नहीं पढ़ा जा सकता.
- उपयोगकर्ता के क्रेडेंशियल (पिन, पैटर्न, पासवर्ड) हासिल नहीं किए जा सकते या उन्हें किसी और तरीके से नहीं डाला जा सकता.

उदाहरण के लिए, अगर कोई डिवाइस, यहां दी गई सभी शर्तों को पूरा करता है, तो वह [C-0-1] का पालन करता है.

9.10. डिवाइस इंटिग्रिटी

यहां दी गई ज़रूरी शर्तों से, डिवाइस की इंटिग्रिटी की स्थिति के बारे में पारदर्शिता बनी रहती है. डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-1] सिस्टम एपीआई के 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) और सार्वजनिक पासकोड के साइज़ (RSA-2048) के लिए, NIST की मौजूदा सलाह के मुताबिक, पुष्टि करने वाले एल्गोरिदम का इस्तेमाल करना ज़रूरी है.
[C-1-6] सिस्टम की पुष्टि न होने पर, बूटिंग पूरी करने की अनुमति नहीं देनी चाहिए. हालांकि, अगर उपयोगकर्ता बूटिंग जारी रखने की सहमति देता है, तो ऐसा किया जा सकता है. इस मामले में, पुष्टि नहीं किए गए किसी भी स्टोरेज ब्लॉक के डेटा का इस्तेमाल नहीं किया जाना चाहिए.
[C-1-7] डिवाइस पर पुष्टि किए गए पार्टिशन में बदलाव करने की अनुमति नहीं दी जानी चाहिए. ऐसा तब तक नहीं किया जाना चाहिए, जब तक उपयोगकर्ता ने बूटलोडर को साफ़ तौर पर अनलॉक न कर दिया हो.
[C-1-8] छेड़छाड़ से सुरक्षित स्टोरेज का इस्तेमाल करना ज़रूरी है: यह जानकारी सेव करने के लिए कि बूटलोडर अनलॉक है या नहीं. छेड़छाड़ का पता लगाने वाले स्टोरेज का मतलब है कि बूटलोडर यह पता लगा सकता है कि Android के अंदर से स्टोरेज में छेड़छाड़ की गई है या नहीं.
[C-1-9] डिवाइस का इस्तेमाल करते समय, उपयोगकर्ता को यह प्रॉम्प्ट मिलना ज़रूरी है. साथ ही, बूटलोडर लॉक मोड से बूटलोडर अनलॉक मोड पर स्विच करने की अनुमति देने से पहले, उपयोगकर्ता से पुष्टि कराना ज़रूरी है.
[C-1-10] Android के इस्तेमाल किए गए पार्टीशन (जैसे, बूट, सिस्टम पार्टीशन) के लिए, रोलबैक सुरक्षा लागू करना ज़रूरी है. साथ ही, ओएस के कम से कम ज़रूरी वर्शन का पता लगाने के लिए इस्तेमाल किए गए मेटाडेटा को सेव करने के लिए, छेड़छाड़ से सुरक्षित स्टोरेज का इस्तेमाल करना ज़रूरी है.
[C-1-11] बूटलोडर को अनलॉक और लॉक करने के दौरान, उपयोगकर्ता के सभी डेटा को सुरक्षित तरीके से मिटाना ज़रूरी है. ऐसा '9.12 के मुताबिक किया जाना चाहिए. डेटा मिटाना' (इसमें उपयोगकर्ता डेटा का पार्टीशन और NVRAM के सभी स्पेस शामिल हैं).
[C-1-14] सिस्टम कॉन्फ़िगरेशन में require-strict-signature के तौर पर लिस्ट किए गए, अनुमति वाली सूची में शामिल पैकेज के लिए, हर बूट पर कम से कम एक बार हस्ताक्षर की पुष्टि करना ज़रूरी है.
[C-SR-2] सभी विशेषाधिकार वाले ऐप्लिकेशन की APK फ़ाइलों की पुष्टि करने का सुझाव दिया जाता है. इसके लिए, भरोसे की ऐसी चेन का इस्तेमाल करें जो वेरिफ़ाइड बूट से सुरक्षित किए गए पार्टीशन पर आधारित हो.
[C-SR-3] यह बेहद ज़रूरी है कि विशेषाधिकार वाला ऐप्लिकेशन, अपनी APK फ़ाइल के बाहर से लोड किए गए किसी भी एक्ज़ीक्यूटेबल आर्टफ़ैक्ट (जैसे, डाइनैमिक तरीके से लोड किया गया कोड या कंपाइल किया गया कोड) की पुष्टि करने के बाद ही उसे लागू करे. यह भी बेहद ज़रूरी है कि वह उन्हें लागू न करे.
डिवाइस बनाने वाली कंपनी को, लगातार काम करने वाले फ़र्मवेयर (जैसे कि मॉडम, कैमरा) वाले किसी भी कॉम्पोनेंट के लिए, रोलबैक सुरक्षा लागू करनी चाहिए.साथ ही, उसे ऐसे स्टोरेज का इस्तेमाल करना चाहिए जिसमें छेड़छाड़ न की जा सके. इसका इस्तेमाल, कम से कम ज़रूरी वर्शन का पता लगाने के लिए इस्तेमाल किए गए मेटाडेटा को सेव करने के लिए किया जाता है.

अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट, external/avb/ रिपॉज़िटरी में इस सुविधा को लागू करने का सबसे सही तरीका बताता है. इसे Android लोड करने के लिए इस्तेमाल किए जाने वाले बूटलोडर में इंटिग्रेट किया जा सकता है.

अगर डिवाइसों में, हर पेज के हिसाब से फ़ाइल के कॉन्टेंट की पुष्टि करने की सुविधा है, तो:

[C-2-1] पूरी फ़ाइल को पढ़े बिना, फ़ाइल के कॉन्टेंट की क्रिप्टोग्राफ़िक तरीके से पुष्टि करने की सुविधा.
[C-2-2] सुरक्षित की गई फ़ाइल पर पढ़ने के अनुरोधों को तब तक पूरा नहीं किया जाना चाहिए, जब तक पढ़े गए कॉन्टेंट की पुष्टि ऊपर दिए गए [C-2-1] के मुताबिक न हो जाए.
[C-2-4] चालू की गई फ़ाइलों के लिए, फ़ाइल के चेकसम को O(1) में दिखाना ज़रूरी है.

अगर डिवाइसों को पहले ही लॉन्च कर दिया गया है और उनमें Android के पुराने वर्शन पर, भरोसेमंद कुंजी के ज़रिए फ़ाइल के कॉन्टेंट की पुष्टि करने की सुविधा नहीं है. साथ ही, सिस्टम सॉफ़्टवेयर को अपडेट करके इस सुविधा को नहीं जोड़ा जा सकता, तो हो सकता है कि उन्हें इस ज़रूरी शर्त से छूट मिल जाए. अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट, Linux कर्नल की fs-verity सुविधा के आधार पर, इस सुविधा को लागू करने का पसंदीदा तरीका उपलब्ध कराता है.

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, ECDH (अगर IKeyMintDevice काम करता है), 3DES, और HMAC क्रिप्टोग्राफ़िक एल्गोरिदम और MD5, SHA-1, और SHA-2 फ़ैमिली हैश फ़ंक्शन IKeyMintDevice या IKeymasterDevice के जिस वर्शन के साथ काम करता है उसके लिए ज़रूरी क्रिप्टोग्राफ़िक एल्गोरिदम और हैश फ़ंक्शन को लागू करना ज़रूरी है. ऐसा इसलिए, ताकि 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] इसमें कुंजी की पुष्टि करने की सुविधा होनी चाहिए. साथ ही, पुष्टि करने के लिए इस्तेमाल की जाने वाली हस्ताक्षर कुंजी को सुरक्षित हार्डवेयर से सुरक्षित किया जाना चाहिए और हस्ताक्षर करने की प्रोसेस को सुरक्षित हार्डवेयर में पूरा किया जाना चाहिए. अटेस्टेशन साइनिंग कुंजियों को डिवाइस के स्थायी आइडेंटिफ़ायर के तौर पर इस्तेमाल नहीं किया जाना चाहिए.

ध्यान दें: इस ज़रूरी शर्त को पूरा करने के लिए, आपको किसी एसकेयू के लिए एक ही अटेस्टेशन कुंजी शेयर करनी होगी. हालांकि, अगर उस एसकेयू की कम से कम 1,00,000 यूनिट बनाई गई हैं, तो ऐसा करना ज़रूरी नहीं है. अगर उस एसकेयू की 1,00,000 से ज़्यादा यूनिट बनाई जाती हैं, तो इसके बाद हर 1,00,000 यूनिट के ग्रुप के लिए, अलग कुंजी का इस्तेमाल किया जा सकता है. इसके अलावा, डिवाइस को कम समय के लिए पुष्टि करने की कुंजियां उपलब्ध कराने के लिए, रिमोट की प्रोविज़निंग की सुविधा का इस्तेमाल किया जा सकता है.

[C-1-5] उपयोगकर्ता को यह चुनने की अनुमति होनी चाहिए कि डिवाइस के अनलॉक से लॉक होने के बीच, स्लीप मोड में जाने के लिए कितना समय लगे. यह समय कम से कम 15 सेकंड होना चाहिए. ऑटोमोटिव डिवाइसों में, हेड यूनिट बंद होने या उपयोगकर्ता के स्विच होने पर स्क्रीन लॉक हो जाती है. इसलिए, इनमें स्लीप मोड में जाने के लिए टाइम आउट की सेटिंग कॉन्फ़िगर नहीं की जा सकती.
[C-1-6] IKeymasterDevice 3.0 या इसके बाद के वर्शन या IKeyMintDevice 1 या इसके बाद के वर्शन पर काम करना चाहिए.

[C-SR-1] यह सुझाव दिया जाता है कि पुष्टि करने के मुख्य तरीकों (जैसे कि पिन, पैटर्न या पासवर्ड) के लिए, पुष्टि करने के अलग-अलग तरीकों से किए गए फ़ेल अनुरोधों के बीच कम से कम समय का अंतराल तय किया जाए. यह अंतराल, इन बातों के आधार पर तय किया जाना चाहिए:

असफल कोशिशों की संख्या	कम से कम टाइम आउट
0-4	0
5	1 मिनट
6	5 मिनट
7	15 मिनट
8	30 मिनट
9	90 मिनट
10	4 घंटे
11	12 घंटे
12	24 घंटे
13	4 दिन
14	13 दिन
15	41 दिन
16	123 दिन
17	1 साल
18	तीन साल
19	9 साल

9.11.1. सुरक्षित लॉक स्क्रीन, पुष्टि करने की सुविधा, और वर्चुअल डिवाइस

AOSP में, पुष्टि करने के लिए टियर वाला मॉडल इस्तेमाल किया जाता है. इसमें, जानकारी पर आधारित पुष्टि करने के मुख्य तरीके के साथ-साथ, बायोमेट्रिक पुष्टि करने का सेकंडरी तरीका या पुष्टि करने के कमज़ोर टर्शियरी तरीके का इस्तेमाल किया जा सकता है.

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-SR-1] यह सुझाव दिया जाता है कि पुष्टि करने के मुख्य तरीके के तौर पर, इनमें से सिर्फ़ एक को सेट किया जाए:
- अंकों वाला पिन
- अक्षर और अंक वाला पासवर्ड
- ठीक 3x3 बिंदुओं की ग्रिड पर स्वाइप करने का पैटर्न
ध्यान दें कि ऊपर दिए गए पुष्टि करने के तरीकों को इस दस्तावेज़ में, पुष्टि करने के सुझाए गए मुख्य तरीके के तौर पर बताया गया है.
[C-0-1] मुख्य पुष्टि करने की कोशिशों की संख्या सीमित होनी चाहिए.
[C-SR-5] हम यह सुझाव देते हैं कि डिवाइस में, मुख्य पुष्टि के लिए 20 बार से ज़्यादा कोशिशें न की जा सकें. साथ ही, अगर उपयोगकर्ता इस सुविधा के लिए सहमति देते हैं और इसमें ऑप्ट-इन करते हैं, तो मुख्य पुष्टि के लिए तय की गई सीमा से ज़्यादा कोशिशें होने पर, "फ़ैक्ट्री डेटा रीसेट" करें.

अगर डिवाइस में, संख्या वाले पिन को पुष्टि करने के मुख्य तरीके के तौर पर सेट किया गया है, तो:

[C-SR-6] हमारा सुझाव है कि पिन कम से कम छह अंकों का होना चाहिए. इसके अलावा, पिन में 20-बिट एन्ट्रॉपी भी होनी चाहिए.
[C-SR-7] छह से कम अंकों वाले पिन के लिए, यह सुझाव दिया जाता है कि उपयोगकर्ता के इंटरैक्शन के बिना अपने-आप पिन डालने की सुविधा चालू न करें. इससे पिन की लंबाई का पता नहीं चलेगा.

अगर डिवाइस में, पुष्टि करने के सुझाए गए मुख्य तरीकों को जोड़ा या उनमें बदलाव किया जाता है और स्क्रीन को लॉक करने के सुरक्षित तरीके के तौर पर पुष्टि करने के नए तरीके का इस्तेमाल किया जाता है, तो पुष्टि करने का नया तरीका:

[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] MUST have a fall-back mechanism to use one of the recommended primary authentication methods which is based on a known secret.
[C-4-3] इसे बंद किया जाना चाहिए. साथ ही, डिवाइस के स्क्रीन लॉक को अनलॉक करने के लिए, सिर्फ़ सुझाए गए प्राइमरी ऑथेंटिकेशन को अनुमति देनी चाहिए. ऐसा तब होना चाहिए, जब डिवाइस नीति कंट्रोलर (डीपीसी) ऐप्लिकेशन ने DevicePolicyManager.setKeyguardDisabledFeatures() तरीके को कॉल करके, कीगार्ड फ़ीचर की नीति सेट की हो. साथ ही, इससे जुड़े किसी भी बायोमेट्रिक फ़्लैग (जैसे कि KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE या KEYGUARD_DISABLE_IRIS) का इस्तेमाल किया गया हो.

अगर बायोमेट्रिक ऑथेंटिकेशन के तरीके, क्लास 3 (पहले मज़बूत) के लिए ज़रूरी शर्तों को पूरा नहीं करते हैं, जैसा कि सेक्शन 7.3.10 में बताया गया है, तो:

[C-5-1] अगर डिवाइस नीति कंट्रोलर (डीपीसी) ऐप्लिकेशन ने DevicePolicyManager.setRequiredPasswordComplexity() के ज़रिए, पासवर्ड की क्वालिटी से जुड़ी नीति को PASSWORD_COMPLEXITY_LOW से ज़्यादा पाबंदी वाले कॉम्प्लेक्सिटी बकेट पर सेट किया है, तो इन तरीकों को बंद करना होगा. इसके अलावा, अगर डीपीसी ऐप्लिकेशन ने DevicePolicyManager.setPasswordQuality() तरीके का इस्तेमाल करके, पासवर्ड की क्वालिटी से जुड़ी नीति को PASSWORD_QUALITY_BIOMETRIC_WEAK से ज़्यादा पाबंदी वाले क्वालिटी कॉन्स्टेंट पर सेट किया है, तो भी इन तरीकों को बंद करना होगा.
[C-5-2] उपयोगकर्ता को, सुझाए गए मुख्य पुष्टि करने के तरीके (जैसे, पिन, पैटर्न या पासवर्ड) के लिए चुनौती दी जानी चाहिए. इसके बारे में सेक्शन 7.3.10 में [C-1-7] और [C-1-8] में बताया गया है.
[C-5-3] इन तरीकों को सुरक्षित लॉक स्क्रीन के तौर पर नहीं माना जाना चाहिए. साथ ही, इन्हें यहां दिए गए सेक्शन में C-8 से शुरू होने वाली ज़रूरी शर्तों को पूरा करना चाहिए.

अगर डिवाइसों में, लॉक स्क्रीन को अनलॉक करने के लिए पुष्टि करने के तरीके जोड़े या बदले जाते हैं और पुष्टि करने का नया तरीका, फ़िज़िकल टोकन या जगह की जानकारी पर आधारित है, तो:

[C-6-1] उनके पास, पुष्टि करने के सुझाए गए मुख्य तरीकों में से किसी एक का इस्तेमाल करने के लिए, फ़ॉल-बैक मैकेनिज़्म होना चाहिए. यह मैकेनिज़्म, किसी जाने-पहचाने सीक्रेट पर आधारित होता है. साथ ही, यह सुरक्षित लॉक स्क्रीन के तौर पर इस्तेमाल किए जाने की ज़रूरी शर्तों को पूरा करता है.
[C-6-2] नए तरीके को बंद किया जाना चाहिए. साथ ही, डिवाइस नीति कंट्रोलर (डीपीसी) ऐप्लिकेशन के ज़रिए, इनमें से किसी एक तरीके से नीति सेट किए जाने पर, स्क्रीन को अनलॉक करने के लिए सिर्फ़ एक प्राइमरी पुष्टि करने के तरीके का इस्तेमाल किया जाना चाहिए:
- DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) तरीका.
- DevicePolicyManager.setPasswordQuality() तरीका, जिसमें PASSWORD_QUALITY_NONE की तुलना में क्वालिटी कॉन्स्टेंट ज़्यादा पाबंदी वाला होता है.
- PASSWORD_COMPLEXITY_NONE की तुलना में, ज़्यादा पाबंदियों वाले कॉम्प्लेक्सिटी बकेट के साथ DevicePolicyManager.setRequiredPasswordComplexity() तरीका.
[C-6-3] उपयोगकर्ता को कम से कम हर चार घंटे में एक बार, पुष्टि करने के लिए सुझाए गए मुख्य तरीकों (जैसे कि पिन, पैटर्न या पासवर्ड) में से किसी एक का इस्तेमाल करने के लिए कहा जाना चाहिए. जब कोई फ़िज़िकल टोकन, C-X में TrustAgent लागू करने की ज़रूरी शर्तों को पूरा करता है, तो [C-9-5] में तय की गई समयसीमा से जुड़ी पाबंदियां लागू होती हैं.
[C-6-4] नए तरीके को सुरक्षित लॉक स्क्रीन के तौर पर नहीं माना जाना चाहिए. साथ ही, इसे नीचे C-8 में दी गई पाबंदियों का पालन करना चाहिए.

[C-7-1] जब डिवाइस लॉक करने की सुविधा को कुछ समय के लिए बंद किया जाता है या भरोसेमंद एजेंट की मदद से डिवाइस को अनलॉक किया जा सकता है, तो सेटिंग मेन्यू और लॉक स्क्रीन पर इसकी जानकारी साफ़ तौर पर दी जानी चाहिए. उदाहरण के लिए, AOSP इस ज़रूरी शर्त को पूरा करता है. इसके लिए, वह सेटिंग मेन्यू में "अपने-आप लॉक होने की सेटिंग" और "पावर बटन दबाने पर तुरंत लॉक होने की सुविधा" के लिए टेक्स्ट में जानकारी दिखाता है. साथ ही, लॉक स्क्रीन पर एक अलग आइकॉन दिखाता है.
[C-7-2] DevicePolicyManager क्लास में मौजूद सभी ट्रस्ट एजेंट एपीआई का पालन करना होगा और उन्हें पूरी तरह से लागू करना होगा. जैसे, KEYGUARD_DISABLE_TRUST_AGENTS कॉन्स्टेंट.
[C-7-3] TrustAgentService.addEscrowToken() फ़ंक्शन को ऐसे डिवाइस पर पूरी तरह से लागू नहीं किया जाना चाहिए जिसका इस्तेमाल मुख्य तौर पर निजी डिवाइस के तौर पर किया जाता है. जैसे, हैंडहेल्ड डिवाइस. हालाँकि, इस फ़ंक्शन को ऐसे डिवाइस पर पूरी तरह से लागू किया जा सकता है जिनका इस्तेमाल आम तौर पर शेयर किया जाता है. जैसे, Android TV या कार में लगा डिवाइस.
[C-7-4] यह ज़रूरी है कि TrustAgentService.addEscrowToken() से जोड़े गए सभी सेव किए गए टोकन को एन्क्रिप्ट (सुरक्षित) किया जाए.
[C-7-5] एन्क्रिप्शन की या एस्क्रो टोकन को उस डिवाइस पर सेव नहीं किया जाना चाहिए जिस पर कुंजी का इस्तेमाल किया जाता है. उदाहरण के लिए, फ़ोन में सेव की गई किसी कुंजी का इस्तेमाल करके, टीवी पर किसी उपयोगकर्ता खाते को अनलॉक किया जा सकता है. ऑटोमोटिव डिवाइसों के लिए, एस्क्रो टोकन को वाहन के किसी भी हिस्से में सेव करने की अनुमति नहीं है.
[C-7-6] डेटा स्टोरेज को डिक्रिप्ट करने के लिए, एस्क्रो टोकन चालू करने से पहले, उपयोगकर्ता को सुरक्षा से जुड़ी समस्याओं के बारे में सूचना देना ज़रूरी है.
[C-7-7] MUST have a fall-back mechanism to use one of the recommended primary authentication methods.
[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] उन्हें तीसरे पक्ष के ऐप्लिकेशन को लॉक की स्थिति बदलने के लिए, एपीआई का इस्तेमाल करने की अनुमति नहीं देनी चाहिए.

अगर डिवाइस में सेट किए गए सिस्टम, ऐप्लिकेशन को सेकंडरी वर्चुअल डिसप्ले बनाने की अनुमति देते हैं और उनसे जुड़े इनपुट इवेंट को सपोर्ट नहीं करते हैं, जैसे कि VirtualDeviceManager के ज़रिए, तो:

[C-9-1] डिवाइस के डिफ़ॉल्ट डिसप्ले के लॉक होने पर, इन सेकंडरी वर्चुअल डिसप्ले को लॉक करना ज़रूरी है. साथ ही, डिवाइस के डिफ़ॉल्ट डिसप्ले के अनलॉक होने पर, इन सेकंडरी वर्चुअल डिसप्ले को अनलॉक करना ज़रूरी है.

अगर डिवाइस में सेट किए गए सिस्टम, ऐप्लिकेशन को सेकंडरी वर्चुअल डिसप्ले बनाने की अनुमति देते हैं और उनसे जुड़े इनपुट इवेंट को सपोर्ट करते हैं, जैसे कि VirtualDeviceManager के ज़रिए, तो:

[C-10-1] ज़रूरी है कि हर वर्चुअल डिवाइस के लिए, लॉक की अलग-अलग स्थितियां काम करती हों
[C-10-2] Android 16 में इस ज़रूरी शर्त को हटा दिया गया है.
[C-10-3] Android 16 में इस ज़रूरी शर्त को हटा दिया गया है.
[C-10-4] जब उपयोगकर्ता लॉकडाउन शुरू करता है, तब सभी डिसप्ले लॉक होने चाहिए. इनमें, हाथ में पकड़कर इस्तेमाल किए जाने वाले डिवाइसों के लिए ज़रूरी लॉकडाउन की सुविधा के ज़रिए शुरू किया गया लॉकडाउन भी शामिल है. इसके बारे में जानने के लिए, सेक्शन 2.2.5[9.11/H-1-2] देखें
[C-10-5] हर उपयोगकर्ता के लिए, वर्चुअल डिवाइस के अलग-अलग इंस्टेंस होने चाहिए
[C-10-6] DevicePolicyManager.setNearbyAppStreamingPolicy के मुताबिक, ऐप्लिकेशन स्ट्रीमिंग की सुविधा बंद करना ज़रूरी है.
[C-10-7] Android 16 में इस ज़रूरी शर्त को हटा दिया गया है.
[C-10-11] वर्चुअल डिवाइसों पर पुष्टि करने वाले यूज़र इंटरफ़ेस (यूआई) को बंद करना ज़रूरी है. इनमें ये शामिल हैं: जानकारी देने वाले फ़ैक्टर की एंट्री और बायोमेट्रिक प्रॉम्प्ट
[C-10-12] Android 16 में इस ज़रूरी शर्त को हटा दिया गया है.
[C-10-13] Android Keystore System के साथ, उपयोगकर्ता की पुष्टि करने के लिए वर्चुअल डिवाइस लॉक की स्थिति का इस्तेमाल नहीं किया जाना चाहिए. KeyGenParameterSpec.Builder.setUserAuthentication* देखें.
[C-10-14] अगर डिवाइस में शेयर किए गए क्लिपबोर्ड की सुविधा लागू की जा रही है, तो उसे फ़िज़िकल और वर्चुअल डिवाइसों के बीच क्लिपबोर्ड का डेटा शेयर करने से पहले, डिवाइसों के बीच क्लिपबोर्ड शेयर करने की सुविधा चालू करने के लिए उपयोगकर्ता को एक विकल्प देना होगा.
[C-10-15] क्लिपबोर्ड के डेटा को ऐक्सेस करने पर, सूचनाएं दिखानी ज़रूरी हैं. ये सूचनाएं, उस डिवाइस पर भी दिखनी चाहिए जिससे डेटा ऐक्सेस किया गया था और उस डिवाइस पर भी दिखनी चाहिए जिससे क्लिपबोर्ड बनाया गया था.

जब डिवाइसों पर लागू की गई सुविधाओं की मदद से, उपयोगकर्ता किसी सोर्स डिवाइस से टारगेट डिवाइस पर पुष्टि करने के लिए इस्तेमाल किया जाने वाला मुख्य जानकारी-फ़ैक्टर ट्रांसफ़र कर पाता है, तब:

[C-11-1] सोर्स डिवाइस से टारगेट डिवाइस पर नॉलेज फ़ैक्टर ट्रांसफ़र करते समय, उसे एन्क्रिप्ट (सुरक्षित) करना ज़रूरी है. इसके लिए, Google Cloud Key Vault Service की सुरक्षा से जुड़े श्वेत पत्र में बताई गई सुरक्षा सुविधाओं का इस्तेमाल करना होगा. इससे यह पक्का किया जा सकेगा कि नॉलेज फ़ैक्टर को रिमोट तरीके से डिक्रिप्ट न किया जा सके. साथ ही, इसका इस्तेमाल किसी भी डिवाइस को रिमोट तरीके से अनलॉक करने के लिए न किया जा सके.
[C-11-2] सोर्स डिवाइस पर, टारगेट डिवाइस पर नॉलेज फ़ैक्टर ट्रांसफ़र करने से पहले , उपयोगकर्ता से सोर्स डिवाइस के नॉलेज फ़ैक्टर की पुष्टि करने के लिए कहना ज़रूरी है.
[C-11-3] अगर टारगेट डिवाइस पर, पुष्टि करने के लिए कोई मुख्य तरीका सेट नहीं किया गया है, तो उसे यह ज़रूरी है कि वह उपयोगकर्ता से टारगेट डिवाइस पर ट्रांसफ़र किए गए 'जानकर पुष्टि करना' वाले तरीके की पुष्टि करने के लिए कहे. ऐसा तब किया जाना चाहिए, जब टारगेट डिवाइस के लिए 'जानकर पुष्टि करना' वाले तरीके को मुख्य तरीका सेट किया जा रहा हो. साथ ही, ऐसा तब भी किया जाना चाहिए, जब सोर्स डिवाइस से ट्रांसफ़र किया गया कोई डेटा उपलब्ध कराया जा रहा हो.

अगर डिवाइसों में सुरक्षित लॉक स्क्रीन की सुविधा मौजूद है और उनमें एक या उससे ज़्यादा भरोसेमंद एजेंट शामिल हैं, जो TrustAgentService.grantTrust() फ़्लैग के साथ TrustAgentService.grantTrust() सिस्टम एपीआई को कॉल करते हैं, तो:FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE

[C-12-1] grantTrust() को सिर्फ़ तब फ़्लैग के साथ कॉल करना चाहिए, जब यह किसी ऐसे फ़िज़िकल डिवाइस से कनेक्ट हो जिसकी अपनी लॉकस्क्रीन हो. साथ ही, जब उपयोगकर्ता ने उस लॉकस्क्रीन के ज़रिए अपनी पहचान की पुष्टि की हो. उपयोगकर्ता की पुष्टि करने की ज़रूरी शर्त को पूरा करने के लिए, आस-पास मौजूद डिवाइस, उपयोगकर्ता के एक बार डिवाइस अनलॉक करने के बाद, कलाई पर पहने गए या शरीर पर पहने गए डिवाइस का पता लगाने के तरीकों का इस्तेमाल कर सकते हैं.
[C-12-2] डिवाइस को TrustState.TRUSTABLE स्टेट में तब डालना ज़रूरी है, जब स्क्रीन बंद हो (जैसे कि बटन दबाने या डिसप्ले टाइम आउट होने पर) और TrustAgent ने भरोसे की स्थिति को रद्द न किया हो. AOSP इस ज़रूरी शर्त को पूरा करता है.
[C-12-3] डिवाइस को सिर्फ़ तब TrustState.TRUSTABLE से TrustState.TRUSTED स्थिति में ले जाना चाहिए, जब TrustAgent अब भी [C-12-1] में दी गई ज़रूरी शर्तों के आधार पर भरोसा कर रहा हो.

[C-12-4] TrustManagerService.revokeTrust() को कॉल करना ज़रूरी है अगर [C-12-5]में बताए गए तरीके से, क्रिप्टोग्राफ़िक तौर पर सुरक्षित और सटीक रेंजिंग का इस्तेमाल नहीं किया जा रहा है:
- भरोसा करने की अनुमति देने के 24 घंटे बाद या
- आठ घंटे तक कोई गतिविधि न होने पर या
- अगर लागू करने के तरीके, [C-12-5] में बताए गए क्रिप्टोग्राफ़िक तौर पर सुरक्षित और सटीक रेंजिंग का इस्तेमाल नहीं कर रहे हैं, जब आस-पास मौजूद फ़िज़िकल डिवाइस से कनेक्शन टूट जाता है.

[C-12-4] की ज़रूरी शर्तों को पूरा करने के लिए, सुरक्षित और सटीक रेंजिंग पर निर्भर रहने वाले [C-12-5] को इनमें से किसी एक समाधान का इस्तेमाल करना होगा:
- यूडब्ल्यूबी का इस्तेमाल करके लागू किए गए सिस्टम:
  - यूडब्ल्यूबी के लिए, 7.4.9 में बताई गई कैलिब्रेशन की ज़रूरी शर्तों के साथ-साथ, यूडब्ल्यूबी के स्टैंडर्ड के मुताबिक काम करने, सर्टिफ़िकेशन पाने, और सटीक होने की ज़रूरी शर्तें पूरी करनी होंगी.
  - 7.4.9 में दिए गए पी-एसटीएस के सुरक्षा मोड में से किसी एक का इस्तेमाल करना ज़रूरी है.
- वाई-फ़ाई नेबरहुड अवेयरनेस नेटवर्किंग (एनएएन) का इस्तेमाल करके लागू की गई सुविधाएं:
  - 2.2.1 [7.4.2.5/H-SR-1] में बताई गई सटीक होने की ज़रूरी शर्तों को पूरा करना चाहिए. साथ ही, 160 मेगाहर्ट्ज़ (या इससे ज़्यादा) बैंडविड्थ का इस्तेमाल करना चाहिए. इसके अलावा, उपयोगकर्ता की मौजूदगी का पता लगाने की सुविधा को कैलिब्रेट करने में बताए गए मेज़रमेंट सेटअप के चरणों का पालन करना चाहिए.
  - IEEE 802.11az में बताए गए तरीके से, सुरक्षित एलटीएफ़ का इस्तेमाल करना ज़रूरी है.

अगर डिवाइसों पर ऐप्लिकेशन को सेकंडरी वर्चुअल डिसप्ले बनाने की अनुमति मिलती है और वे VirtualDeviceManager जैसे इनपुट इवेंट के साथ काम करते हैं, तो VIRTUAL_DISPLAY_FLAG_SECURE के साथ मार्क न किए गए डिसप्ले:

[C-13-8] वर्चुअल डिवाइस पर, android:canDisplayOnRemoteDevices एट्रिब्यूट या android.activity.can_display_on_remote_devices मेटाडेटा को फ़ॉल्स पर सेट करके, गतिविधियों को शुरू होने से रोकना ज़रूरी है.
[C-13-9] वर्चुअल डिवाइस पर, ऐसी गतिविधियों को शुरू होने से रोकना होगा जिनमें स्ट्रीमिंग की सुविधा साफ़ तौर पर चालू नहीं की गई है. साथ ही, ऐसी गतिविधियां भी शुरू होने से रोकनी होंगी जिनसे संवेदनशील कॉन्टेंट दिखाए जाने का पता चलता है. इनमें SurfaceView#setSecure और FLAG_SECURE के ज़रिए की जाने वाली गतिविधियां भी शामिल हैं.

अगर डिवाइस में, 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 की मदद से, ऐप्लिकेशन डेवलपर क्रिप्टोग्राफ़िक कुंजियों को एक खास सुरक्षित प्रोसेसर में सेव कर सकते हैं. साथ ही, ऊपर बताए गए आइसोलेटेड एक्ज़ीक्यूशन एनवायरमेंट में भी सेव कर सकते हैं. इस तरह के सुरक्षित प्रोसेसर को "StrongBox" कहा जाता है. नीचे दी गई 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] में एक अलग सीपीयू होना चाहिए, जो ऐप्लिकेशन प्रोसेसर (एपी) के साथ कोई कैश, DRAM, कोप्रोसेसर या अन्य कोर संसाधन शेयर न करता हो.
[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] इसमें ऐसा हार्डवेयर शामिल होना चाहिए जिसे Secure IC Protection Profile BSI-CC-PP-0084-2014 या BSI-CC-PP-0117-2022 के तहत सर्टिफ़िकेट मिला हो. इसके अलावा, इसमें ऐसा हार्डवेयर भी शामिल हो सकता है जिसका आकलन, राष्ट्रीय स्तर पर मान्यता प्राप्त टेस्टिंग लैब ने किया हो. इस लैब ने Common Criteria Application of Attack Potential to Smartcards के मुताबिक, हाई अटैक पोटेंशियल वल्नरेबिलिटी असेसमेंट को शामिल किया हो.
[C-1-11] इसमें ऐसा फ़र्मवेयर शामिल होना चाहिए जिसका आकलन, राष्ट्रीय स्तर पर मान्यता प्राप्त टेस्टिंग लैब ने किया हो. साथ ही, इसमें स्मार्ट कार्ड पर हमले की संभावना के लिए सामान्य मानदंड के मुताबिक, हमले की ज़्यादा संभावना वाली कमज़ोरियों का आकलन शामिल होना चाहिए.
[C-SR-2] यह सुझाव दिया जाता है कि ऐसे हार्डवेयर को शामिल किया जाए जिसका आकलन, सिक्योरिटी टारगेट और इवैल्यूएशन अश्योरेंस लेवल (ईएएल) 5 का इस्तेमाल करके किया गया हो. साथ ही, एवीए_वैन.5 का इस्तेमाल करके उसे बेहतर बनाया गया हो. ऐसा हो सकता है कि आने वाले समय में, EAL 5 सर्टिफ़िकेशन ज़रूरी हो जाए.
[C-SR-3] में, इनसाइडर अटैक से सुरक्षा (आईएआर) देने का सुझाव दिया जाता है. इसका मतलब है कि फ़र्मवेयर पर हस्ताक्षर करने वाली कुंजियों का ऐक्सेस रखने वाला कोई इनसाइडर ऐसा फ़र्मवेयर नहीं बना सकता जिससे StrongBox के सीक्रेट लीक हो जाएं, सुरक्षा से जुड़ी ज़रूरी शर्तों को बायपास किया जा सके या किसी अन्य तरीके से लोगों के संवेदनशील डेटा का ऐक्सेस मिल जाए. IAR को लागू करने का सबसे सही तरीका यह है कि फ़र्मवेयर अपडेट की अनुमति सिर्फ़ तब दी जाए, जब मुख्य उपयोगकर्ता का पासवर्ड IAuthSecret HAL के ज़रिए दिया गया हो.

9.11.3. पहचान से जुड़ा क्रेडेंशियल

आइडेंटिटी क्रेडेंशियल सिस्टम को android.security.identity.* पैकेज में मौजूद सभी एपीआई लागू करके तय किया जाता है. इन एपीआई की मदद से, ऐप्लिकेशन डेवलपर को उपयोगकर्ता की पहचान से जुड़े दस्तावेज़ों को सेव करने और उन्हें वापस पाने की अनुमति मिलती है. डिवाइस में सेट किए गए सिस्टम के लिए:

[C-SR-1] यह सुझाव दिया जाता है कि आइडेंटिटी क्रेडेंशियल सिस्टम लागू किया जाए.

अगर डिवाइसों में आइडेंटिटी क्रेडेंशियल सिस्टम लागू किया जाता है, तो:

[C-1-1] IdentityCredentialStore#getInstance() तरीके के लिए, शून्य से अलग वैल्यू दिखाना ज़रूरी है.
[C-1-2] Identity Credential System (जैसे, android.security.identity.* API) को लागू करना ज़रूरी है.इसके लिए, कोड को किसी भरोसेमंद ऐप्लिकेशन के साथ कम्यूनिकेट करना होगा. यह कोड, कर्नल और उससे ऊपर के कोड से सुरक्षित तरीके से अलग किया गया हो. सुरक्षित आइसोलेशन को उन सभी संभावित तरीकों को ब्लॉक करना चाहिए जिनसे कर्नेल या यूज़रस्पेस कोड, आइसोलेट किए गए एनवायरमेंट की इंटरनल स्थिति को ऐक्सेस कर सकता है. इसमें डीएमए भी शामिल है.
[C-1-3] IdentityCredential System (जैसे, android.security.identity.* एपीआई) को लागू करने के लिए ज़रूरी क्रिप्टोग्राफ़िक कार्रवाइयां, पूरी तरह से भरोसेमंद ऐप्लिकेशन में की जानी चाहिए. साथ ही, निजी कुंजी का डेटा कभी भी अलग किए गए एक्ज़ीक्यूशन एनवायरमेंट से बाहर नहीं जाना चाहिए. ऐसा तब तक नहीं होना चाहिए, जब तक कि उच्च-स्तरीय एपीआई (जैसे, createEphemeralKeyPair() तरीका) के लिए इसकी खास तौर पर ज़रूरत न हो.
[C-1-4] भरोसेमंद ऐप्लिकेशन को इस तरह से लागू किया जाना चाहिए कि उसकी सुरक्षा से जुड़ी प्रॉपर्टी पर कोई असर न पड़े. उदाहरण के लिए, क्रेडेंशियल डेटा तब तक रिलीज़ नहीं किया जाता, जब तक कि ऐक्सेस कंट्रोल की शर्तें पूरी न हो जाएं. साथ ही, मनमाने डेटा के लिए MAC जनरेट नहीं किए जा सकते. ऐसा तब भी होना चाहिए, जब Android ठीक से काम न कर रहा हो या उसके साथ छेड़छाड़ की गई हो.

Android Open Source Project का अपस्ट्रीम, भरोसेमंद ऐप्लिकेशन (libeic) का रेफ़रंस इम्प्लीमेंटेशन उपलब्ध कराता है. इसका इस्तेमाल, Identity Credential सिस्टम को लागू करने के लिए किया जा सकता है.

9.12. डेटा हटाना

डिवाइस में सेट किए गए सभी सिस्टम के लिए:

[C-0-1] उपयोगकर्ताओं को "फ़ैक्ट्री डेटा रीसेट" करने का तरीका उपलब्ध कराना ज़रूरी है.
[C-0-2] "फ़ैक्ट्री डेटा रीसेट" करने पर, उपयोगकर्ता के डेटा वाले फ़ाइल सिस्टम से सारा डेटा मिटाना ज़रूरी है.
[C-0-3] "फ़ैक्ट्री डेटा रीसेट" करते समय, डेटा को इस तरह से मिटाना होगा कि वह NIST SP800-88 जैसे इंडस्ट्री के मानकों के मुताबिक हो.
[C-0-4] जब मुख्य उपयोगकर्ता का डिवाइस नीति कंट्रोलर ऐप्लिकेशन, DevicePolicyManager.wipeData() API को कॉल करता है, तब ऊपर दी गई "फ़ैक्ट्री डेटा रीसेट" प्रोसेस को ट्रिगर करना ज़रूरी है.
यह तेज़ी से डेटा मिटाने का विकल्प दे सकता है. इससे सिर्फ़ लॉजिकल डेटा मिटाया जाता है.

9.13. सुरक्षित बूट मोड

Android में सेफ़ बूट मोड की सुविधा मिलती है. इससे लोग ऐसे मोड में बूट अप कर सकते हैं जिसमें सिर्फ़ पहले से इंस्टॉल किए गए सिस्टम ऐप्लिकेशन को चलाने की अनुमति होती है. साथ ही, तीसरे पक्ष के सभी ऐप्लिकेशन बंद हो जाते हैं. इस मोड को "सेफ़ बूट मोड" कहा जाता है. इससे उपयोगकर्ता को तीसरे पक्ष के ऐसे ऐप्लिकेशन अनइंस्टॉल करने की सुविधा मिलती है जो नुकसान पहुंचा सकते हैं.

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-SR-1] सुरक्षित बूट मोड को लागू करने का सुझाव दिया जाता है.

अगर डिवाइस में सेफ़ बूट मोड लागू किया जाता है, तो:

[C-1-1] उपयोगकर्ता को सुरक्षित बूट मोड में जाने का विकल्प देना ज़रूरी है. ऐसा इस तरह से किया जाना चाहिए कि डिवाइस पर इंस्टॉल किए गए तीसरे पक्ष के ऐप्लिकेशन, इसमें रुकावट न डालें. हालांकि, अगर तीसरे पक्ष का ऐप्लिकेशन, डिवाइस नीति कंट्रोलर है और उसने UserManager.DISALLOW_SAFE_BOOT फ़्लैग को 'सही है' के तौर पर सेट किया है, तो वह रुकावट डाल सकता है.
[C-1-2] उपयोगकर्ता को सुरक्षित मोड में, तीसरे पक्ष के किसी भी ऐप्लिकेशन को अनइंस्टॉल करने की सुविधा मिलनी चाहिए.
उपयोगकर्ता को बूट मेन्यू से सुरक्षित बूट मोड में जाने का विकल्प देना चाहिए. इसके लिए, सामान्य बूट से अलग वर्कफ़्लो का इस्तेमाल करना चाहिए.

9.14. ऑटोमोटिव वाहन सिस्टम आइसोलेशन

Android Automotive डिवाइसों से उम्मीद की जाती है कि वे वाहन के एचएएल का इस्तेमाल करके, वाहन के ज़रूरी सबसिस्टम के साथ डेटा शेयर करें. साथ ही, CAN बस जैसे वाहन के नेटवर्क पर मैसेज भेजें और पाएं.

डेटा के आदान-प्रदान को सुरक्षित किया जा सकता है. इसके लिए, Android फ़्रेमवर्क लेयर के नीचे सुरक्षा सुविधाओं को लागू करें. इससे इन सबसिस्टम के साथ नुकसान पहुंचाने वाले या अनजाने में होने वाले इंटरैक्शन को रोका जा सकता है.

9.15. सदस्यता प्लान

"सदस्यता प्लान" से मतलब, बिलिंग रिलेशनशिप प्लान की उस जानकारी से है जो मोबाइल और इंटरनेट सेवा देने वाली कंपनी, SubscriptionManager.setSubscriptionPlans() के ज़रिए उपलब्ध कराती है.

डिवाइस में सेट किए गए सभी सिस्टम के लिए:

[C-0-1] सदस्यता की योजनाओं की जानकारी सिर्फ़ उस मोबाइल और इंटरनेट सेवा देने वाली कंपनी के ऐप्लिकेशन को देनी होगी जिसने उन्हें उपलब्ध कराया है.
[C-0-2] सदस्यता योजनाओं का बैक अप दूर से नहीं लिया जाना चाहिए और न ही उन्हें अपलोड किया जाना चाहिए.
[C-0-3] सिर्फ़ उन मोबाइल कैरियर ऐप्लिकेशन से ओवरराइड करने की अनुमति होनी चाहिए जो फ़िलहाल मान्य सदस्यता प्लान उपलब्ध करा रहे हैं. जैसे, SubscriptionManager.setSubscriptionOverrideCongested().

9.16. ऐप्लिकेशन का डेटा माइग्रेट करना

अगर डिवाइसों में, एक डिवाइस से दूसरे डिवाइस पर डेटा माइग्रेट करने की सुविधा शामिल है और वे ऐप्लिकेशन के डेटा को कॉपी करने के लिए, android:fullBackupContent एट्रिब्यूट के ज़रिए मेनिफ़ेस्ट में ऐप्लिकेशन डेवलपर के कॉन्फ़िगर किए गए डेटा को सीमित नहीं करते हैं, तो:

[C-1-1] MUST NOT initiate transfers of application data from devices on which the user has not set a primary authentication as described in 9.11.1 Secure Lock Screen and Authentication.
[C-1-2] डेटा ट्रांसफ़र करने से पहले, सोर्स डिवाइस पर मुख्य पुष्टि की सुरक्षित तरीके से पुष्टि करना ज़रूरी है. साथ ही, सोर्स डिवाइस पर डेटा कॉपी करने के लिए, उपयोगकर्ता की मंज़ूरी लेना ज़रूरी है.
[C-1-3] डिवाइस से डिवाइस पर डेटा माइग्रेट करने के दौरान, यह पक्का करने के लिए कि सोर्स डिवाइस और टारगेट डिवाइस, दोनों ही Android के असली डिवाइस हैं और उनका बूटलोडर लॉक है, सुरक्षा कुंजी की पुष्टि करने की सुविधा का इस्तेमाल करना ज़रूरी है.
[C-1-4] ऐप्लिकेशन के डेटा को सिर्फ़ टारगेट डिवाइस पर मौजूद उसी ऐप्लिकेशन में माइग्रेट किया जाना चाहिए. साथ ही, यह भी ज़रूरी है कि ऐप्लिकेशन का पैकेज नाम और साइनिंग सर्टिफ़िकेट एक जैसा हो.
[C-1-5] सेटिंग मेन्यू में यह जानकारी दिखनी चाहिए कि सोर्स डिवाइस से डेटा को डिवाइस-टू-डिवाइस डेटा माइग्रेशन की मदद से माइग्रेट किया गया है. किसी उपयोगकर्ता के पास इस सूचना को हटाने का विकल्प नहीं होना चाहिए.

9.17. Android वर्चुअलाइज़ेशन फ़्रेमवर्क

Android वर्चुअलाइज़ेशन फ़्रेमवर्क (एवीएफ़) एपीआई (android.system.virtualmachine.*) की मदद से, ऐप्लिकेशन डिवाइस पर वर्चुअल मशीन (वीएम), सुरक्षित वर्चुअल मशीन (पीवीएम), और गैर-सुरक्षित वर्चुअल मशीन (नॉन-पीवीएम) बना सकते हैं. ये मशीनें, नेटिव बाइनरी को पेलोड के तौर पर लोड और रन करती हैं.

अगर डिवाइसों में सेट किए गए सिस्टम के लिए, FEATURE_VIRTUALIZATION_FRAMEWORK को true पर सेट किया गया है, तो:

[C-1-1] को यह पक्का करना होगा कि android.system.virtualmachine.VirtualMachineManager.getCapabilities() इनमें से कोई एक वैल्यू दिखाता हो:
- CAPABILITY_PROTECTED_VM
- CAPABILITY_NON_PROTECTED_VM
- CAPABILITY_NON_PROTECTED_VM | CAPABILITY_PROTECTED_VM

9.18. डेवलपर सत्यापन

एपीआई लेवल 36.1 या इसके बाद के वर्शन का इस्तेमाल करने वाले डिवाइसों के लिए:

इसमें डेवलपर की पुष्टि करने वाली सेवा के लिए सहायता शामिल हो सकती है, ताकि यह पुष्टि की जा सके कि ऐप्लिकेशन किसी जाने-माने डेवलपर ने बनाए हैं.

एपीआई लेवल 36.1 या इसके बाद के वर्शन का इस्तेमाल करने वाले डिवाइसों के लिए, डेवलपर की पुष्टि करने वाले व्यक्ति को कॉन्फ़िगर करना ज़रूरी है. इसके लिए, config.xml में config_developerVerificationServiceProviderPackageName को तय करें:

[9.18/C-1-1] हर ऐप्लिकेशन पैकेज इंस्टॉलेशन के लिए, कॉन्फ़िगर किए गए android.content.pm.verify.developer.DeveloperVerifierService को लागू करना ज़रूरी है. इसमें नए इंस्टॉलेशन और मौजूदा ऐप्लिकेशन के अपडेट, दोनों शामिल हैं.

एपीआई लेवल 36.1 या इसके बाद के वर्शन का इस्तेमाल करने वाले डिवाइसों के लिए:

config_developerVerificationPolicyDelegatePackageName में config_developerVerificationPolicyDelegatePackageName को तय करके, चालू नीति को सेट करने के लिए किसी प्रतिनिधि को भी कॉन्फ़िगर कर सकता है.config.xml

अगर डेवलपर वेरिफ़ायर कॉन्फ़िगर किया गया है, तो डिवाइसों पर ये काम किए जा सकते हैं:

[9.18/C-2-1] डेवलपर की पुष्टि करने वाले व्यक्ति या उसके कॉन्फ़िगर किए गए डेलिगेट को ही, android.content.pm.PackageInstaller में बताई गई इंस्टॉल करने की नीति सेट करने की अनुमति होनी चाहिए.

अगर पैकेज इंस्टॉलेशन सेशन के दौरान किसी वेरिफ़ायर को शुरू किया जाता है, तो डिवाइस के लिए ये ज़रूरी हैं:

[9.18/C-3-1] अगर ऐसा होता है, तो ऐप्लिकेशन पैकेज को इंस्टॉल होने से रोकना ज़रूरी है:
- डेवलपर की पहचान की पुष्टि नहीं हो पाती.
- इंस्टॉल करने के सेशन के लिए, डेवलपर की पुष्टि करने से जुड़ी नीति को DEVELOPER_VERIFICATION_POLICY_NONE के अलावा किसी अन्य वैल्यू पर सेट किया गया हो.
- जब तक 9.18/C-3-2 या 9.18/C-3-3 लागू न हो.

[9.18/C-3-2] किसी ऐप्लिकेशन पैकेज को इंस्टॉल करने से नहीं रोकना चाहिए. भले ही, नीति या पुष्टि की स्थिति कुछ भी हो. ऐसा तब होना चाहिए, जब:
- यह पैकेज, Android डीबग ब्रिज (एडीबी) के ज़रिए इंस्टॉल किया गया है.
- पैकेज, कॉन्फ़िगर किया गया डेवलपर वेरिफ़ायर या उसका इंस्टॉलर है.

[9.18/C-3-3] अगर ये सभी शर्तें पूरी होती हैं, तो किसी ऐप्लिकेशन पैकेज को इंस्टॉल करने से नहीं रोका जाना चाहिए:
- नीति को DEVELOPER_VERIFICATION_POLICY_BLOCK_FAIL_WARN या DEVELOPER_VERIFICATION_POLICY_BLOCK_FAIL_OPEN पर सेट किया गया हो.
- पुष्टि की प्रक्रिया पूरी नहीं हुई है.
- इंस्टॉलर यह बताता है कि उपयोगकर्ता ने DEVELOPER_VERIFICATION_USER_RESPONSE_INSTALL_ANYWAY की रिपोर्ट करके, साफ़ तौर पर इंस्टॉलेशन जारी रखने का अनुरोध किया है.

नीति या पुष्टि की स्थिति से कोई फ़र्क़ नहीं पड़ता. डिवाइस का मालिक, मैनेज किए जा रहे डिवाइस पर या प्रोफ़ाइल का मालिक, मैनेज की जा रही प्रोफ़ाइल पर ऐप्लिकेशन पैकेज इंस्टॉल कर सकता है. हालांकि, 9.18/C-3-1 में बताए गए तरीके से इंस्टॉल करने से रोकने का सुझाव दिया जाता है.

10. सॉफ़्टवेयर कंपैटिबिलिटी टेस्टिंग

डिवाइस में सेट किए गए सिस्टम के लिए, इस सेक्शन में बताए गए सभी टेस्ट पास करना ज़रूरी है. हालांकि, ध्यान दें कि कोई भी सॉफ़्टवेयर टेस्ट पैकेज पूरी तरह से काम नहीं करता. इस वजह से, डिवाइस बनाने वाली कंपनियों को सख्ती से सलाह दी जाती है कि वे Android Open Source Project से उपलब्ध Android के रेफ़रंस और पसंदीदा वर्शन में कम से कम बदलाव करें. इससे, ऐसी गड़बड़ियां होने का जोखिम कम हो जाएगा जिनकी वजह से, ऐप्लिकेशन ठीक से काम नहीं कर पाएगा. इसके लिए, ऐप्लिकेशन को फिर से बनाना पड़ सकता है और डिवाइस को अपडेट करना पड़ सकता है.

10.1. Compatibility Test Suite

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-1] डिवाइस पर शिपिंग के लिए उपलब्ध फ़ाइनल सॉफ़्टवेयर का इस्तेमाल करके, Android Compatibility Test Suite (CTS) पास करना ज़रूरी है. यह Android Open Source Project से उपलब्ध है.
[C-0-2] यह पक्का करना ज़रूरी है कि सीटीएस में अस्पष्टता होने पर, डिवाइस काम करे. साथ ही, रेफ़रंस सोर्स कोड के किसी भी हिस्से को फिर से लागू करने पर, डिवाइस काम करे.

CTS को किसी असली डिवाइस पर चलाने के लिए डिज़ाइन किया गया है. किसी भी सॉफ़्टवेयर की तरह, सीटीएस में भी गड़बड़ियां हो सकती हैं. सीटीएस का वर्शन, इस कंपैटिबिलिटी डेफ़िनिशन से अलग होगा. साथ ही, Android 17 के लिए सीटीएस के कई वर्शन रिलीज़ किए जा सकते हैं.

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-3] डिवाइस का सॉफ़्टवेयर तैयार होने के समय, CTS का सबसे नया वर्शन पास करना ज़रूरी है.
Android Open Source ट्री में, रेफ़रंस के तौर पर दिए गए कोड का ज़्यादा से ज़्यादा इस्तेमाल करना चाहिए.

10.2. सीटीएस की पुष्टि करने वाला टूल

CTS Verifier, Compatibility Test Suite में शामिल होता है. इसे किसी व्यक्ति को चलाना होता है, ताकि उन सुविधाओं की जांच की जा सके जिनकी जांच ऑटोमेटेड सिस्टम नहीं कर सकता. जैसे, कैमरे और सेंसर का सही तरीके से काम करना.

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-1] CTS verifier में, लागू होने वाले सभी मामलों को सही तरीके से लागू करना ज़रूरी है.

CTS Verifier में कई तरह के हार्डवेयर के लिए टेस्ट मौजूद हैं. इनमें कुछ ऐसे हार्डवेयर भी शामिल हैं जो ज़रूरी नहीं हैं.

डिवाइस में सेट किए गए सिस्टम के लिए:

[C-0-2] यह ज़रूरी है कि डिवाइस में मौजूद हार्डवेयर के लिए, सभी टेस्ट पास किए जाएं. उदाहरण के लिए, अगर किसी डिवाइस में एक्सलरोमीटर है, तो यह ज़रूरी है कि वह CTS Verifier में एक्सलरोमीटर टेस्ट केस को सही तरीके से पूरा करे.

इस कंपैटिबिलिटी डेफ़िनिशन दस्तावेज़ में, जिन सुविधाओं को 'ज़रूरी नहीं' के तौर पर मार्क किया गया है उनके टेस्ट केस छोड़े जा सकते हैं.

[C-0-2] ऊपर बताए गए तरीके से, हर डिवाइस और हर बिल्ड पर CTS Verifier को सही तरीके से चलाना ज़रूरी है. हालांकि, कई बिल्ड एक जैसे होते हैं. इसलिए, डिवाइस बनाने वाली कंपनियों से यह उम्मीद नहीं की जाती कि वे उन बिल्ड पर CTS Verifier को साफ़ तौर पर चलाएं जिनमें सिर्फ़ मामूली अंतर हो. खास तौर पर, डिवाइसों पर लागू किए गए ऐसे वर्शन जिनमें सिर्फ़ शामिल की गई भाषाओं, ब्रैंडिंग वगैरह के सेट के हिसाब से, सीटीएस वेरिफ़ायर पास करने वाले वर्शन से अलग हैं, वे सीटीएस वेरिफ़ायर टेस्ट को छोड़ सकते हैं.

11. अपडेट किया जा सकने वाला सॉफ़्टवेयर

[C-0-1] डिवाइस में, सिस्टम सॉफ़्टवेयर को पूरी तरह से बदलने का तरीका शामिल होना चाहिए. यह ज़रूरी नहीं है कि अपग्रेड "लाइव" हों. इसका मतलब है कि डिवाइस को रीस्टार्ट करना पड़ सकता है. किसी भी तरीके का इस्तेमाल किया जा सकता है. हालांकि, यह ज़रूरी है कि इससे डिवाइस पर पहले से इंस्टॉल किया गया पूरा सॉफ़्टवेयर बदल जाए. उदाहरण के लिए, इनमें से कोई भी तरीका अपनाने पर, यह ज़रूरी शर्त पूरी हो जाएगी:
- "ओवर-द-एयर (ओटीए)" डाउनलोड की सुविधा. इसके तहत, रीबूट करके ऑफ़लाइन अपडेट किया जा सकता है.
- होस्ट पीसी से यूएसबी के ज़रिए "टेथर्ड" अपडेट.
- "ऑफ़लाइन" अपडेट, रीबूट करके और हटाने लायक स्टोरेज डिवाइस पर मौजूद फ़ाइल से अपडेट करके किए जाते हैं.
[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 में ब्लॉक-आधारित OTA लागू करने की सुविधा, Android 5.1 के बाद से जोड़ी गई है. इससे यह ज़रूरी शर्त पूरी होती है.

साथ ही, डिवाइसों में A/B सिस्टम अपडेट की सुविधा होनी चाहिए. AOSP, बूट कंट्रोल HAL का इस्तेमाल करके इस सुविधा को लागू करता है.

अगर किसी डिवाइस के रिलीज़ होने के बाद, उसके लागू करने में कोई गड़बड़ी मिलती है, लेकिन वह गड़बड़ी प्रॉडक्ट के जीवनकाल के दौरान मिलती है. यह जीवनकाल, Android Compatibility Team के साथ सलाह-मशवरा करके तय किया जाता है. इस गड़बड़ी से तीसरे पक्ष के ऐप्लिकेशन की संगतता पर असर पड़ता है. ऐसे में:

[C-2-1] डिवाइस बनाने वाली कंपनी को, सॉफ़्टवेयर अपडेट के ज़रिए गड़बड़ी को ठीक करना होगा. यह अपडेट, ऊपर बताए गए तरीके के मुताबिक लागू किया जा सकता है.

Android में ऐसी सुविधाएं शामिल होती हैं जिनकी मदद से, डिवाइस के मालिक के ऐप्लिकेशन (अगर मौजूद है) को सिस्टम अपडेट इंस्टॉल करने की सुविधा मिलती है. अगर डिवाइसों के लिए सिस्टम अपडेट सबसिस्टम, android.software.device_admin की रिपोर्ट करता है, तो:

[C-3-1] SystemUpdatePolicy क्लास में बताए गए व्यवहार को लागू करना ज़रूरी है.

12. दस्तावेज़ में हुए बदलावों का लॉग

Android 16 से, अलग से कोई बदलाव लॉग नहीं रखा जाता. पिछले वर्शन में किए गए सभी बदलावों को इस दस्तावेज़ में हाइलाइट किया गया है.

13. हमसे संपर्क करें

android-compatibility फ़ोरम में शामिल होकर, ज़्यादा जानकारी माँगी जा सकती है. इसके अलावा, ऐसी समस्याएँ भी बताई जा सकती हैं जिनके बारे में दस्तावेज़ में जानकारी नहीं दी गई है.