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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2.1. हार्डवेयर

स्क्रीन का साइज़ (सेक्शन 7.1.1.1)

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

  • [H-0-1] ज़रूरी है कि डिवाइस में कम से कम 2.5 इंच की स्क्रीन हो.*

स्क्रीन डेंसिटी (सेक्शन 7.1.1.3)

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

  • [H-SR] उपयोगकर्ताओं को डिसप्ले का साइज़ बदलने की सुविधा देने का सुझाव दिया जाता है.

लेगसी ऐप्लिकेशन के साथ काम करने वाला मोड (सेक्शन 7.1.5)

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

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

कीबोर्ड (सेक्शन 7.2.1)

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

  • [H-0-1] इसमें तीसरे पक्ष के इनपुट के तरीके का संपादक (IME) ऐप्लिकेशन के लिए सहायता शामिल होनी चाहिए.

नेविगेशन कुंजियां (सेक्शन 7.2.3)

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

  • [H-0-1] इसमें होम, हाल ही के ऐप्लिकेशन, और वापस जाने की सुविधा होनी चाहिए.

  • [H-0-2] बैक फ़ंक्शन (KEYCODE_BACK) के सामान्य और लंबे समय तक दबाए रखने वाले, दोनों इवेंट को फ़ोरग्राउंड ऐप्लिकेशन पर भेजना ज़रूरी है.

टचस्क्रीन इनपुट (सेक्शन 7.2.4)

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

  • [H-0-1] टचस्क्रीन इनपुट के साथ काम करना ज़रूरी है.

ऐक्सिलरोमीटर (सेक्शन 7.3.1)

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

  • [H-SR] 3-ऐक्सिस एक्सलरोमीटर शामिल करने का सुझाव दिया जाता है.

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

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

जाइरोस्कोप (सेक्शन 7.3.4)

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

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

प्रॉक्सिमिटी सेंसर (सेक्शन 7.3.8 )

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

  • इसमें प्रॉक्सिमिटी सेंसर शामिल होना चाहिए.

पोज़ सेंसर (सेक्शन 7.3.12)

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

  • इनका सुझाव इसलिए दिया जाता है, ताकि ये छह डिग्री की स्वतंत्रता के साथ पोज़ सेंसर की सुविधा को सपोर्ट कर सकें.

ब्लूटूथ (सेक्शन 7.4.3)

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

  • इनमें ब्लूटूथ और ब्लूटूथ LE की सुविधा होनी चाहिए.

डेटा बचाने की सेटिंग (सेक्शन 7.4.7)

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

  • [H-1-1] MUST provide the data saver mode.

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

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

  • [H-1-1] अगर डिफ़ॉल्ट डिसप्ले, qHD (जैसे कि FWVGA) तक के फ़्रेमबफ़र रिज़ॉल्यूशन का इस्तेमाल करता है, तो कर्नल और यूज़रस्पेस के लिए उपलब्ध मेमोरी कम से कम 416 एमबी होनी चाहिए.

  • [H-2-1] अगर डिफ़ॉल्ट डिसप्ले, एचडी+ (जैसे कि एचडी, डब्ल्यूएसवीजीए) तक के फ़्रेमबफ़र रिज़ॉल्यूशन का इस्तेमाल करता है, तो कर्नल और यूज़रस्पेस के लिए उपलब्ध मेमोरी कम से कम 592 एमबी होनी चाहिए.

  • [H-3-1] अगर डिफ़ॉल्ट डिसप्ले, फ़्रेमबफ़र रिज़ॉल्यूशन का इस्तेमाल करता है, तो कर्नल और यूज़रस्पेस के लिए उपलब्ध मेमोरी कम से कम 896 एमबी होनी चाहिए. जैसे, WSXGA+.

  • [H-4-1] अगर डिफ़ॉल्ट डिसप्ले, QHD (जैसे कि QWXGA) तक के फ़्रेमबफ़र रिज़ॉल्यूशन का इस्तेमाल करता है, तो कर्नेल और यूज़रस्पेस के लिए उपलब्ध मेमोरी कम से कम 1344 एमबी होनी चाहिए.

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

  • [H-5-1] अगर डिफ़ॉल्ट डिसप्ले, qHD (जैसे कि FWVGA) तक के फ़्रेमबफ़र रिज़ॉल्यूशन का इस्तेमाल करता है, तो कर्नल और यूज़रस्पेस के लिए उपलब्ध मेमोरी कम से कम 816 एमबी होनी चाहिए.

  • [H-6-1] अगर डिफ़ॉल्ट डिसप्ले, एचडी+ (जैसे कि एचडी, WSVGA) तक के फ़्रेमबफ़र रिज़ॉल्यूशन का इस्तेमाल करता है, तो कर्नल और यूज़रस्पेस के लिए उपलब्ध मेमोरी कम से कम 944 एमबी होनी चाहिए.

  • [H-7-1] अगर डिफ़ॉल्ट डिसप्ले, फ़्रेमबफ़र रिज़ॉल्यूशन का इस्तेमाल करता है, तो कर्नेल और यूज़रस्पेस के लिए उपलब्ध मेमोरी कम से कम 1280 एमबी होनी चाहिए. जैसे, WSXGA+.

  • [H-8-1] अगर डिफ़ॉल्ट डिसप्ले, QHD (जैसे कि QWXGA) तक के फ़्रेमबफ़र रिज़ॉल्यूशन का इस्तेमाल करता है, तो कर्नल और यूज़रस्पेस के लिए उपलब्ध मेमोरी कम से कम 1824 एमबी होनी चाहिए.

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

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

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

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

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

ऐप्लिकेशन के लिए Shared Storage (सेक्शन 7.6.2)

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

  • [H-0-1] ऐप्लिकेशन के लिए, शेयर किया गया स्टोरेज 1 जीबी से कम नहीं होना चाहिए.

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

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

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

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

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

माइक्रोफ़ोन (सेक्शन 7.8.1)

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

  • [H-0-1] माइक्रोफ़ोन शामिल करना ज़रूरी है.

ऑडियो आउटपुट (सेक्शन 7.8.2)

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

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

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

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

  • [H-1-1] android.software.vr.mode सुविधा के बारे में एलान करना ज़रूरी है.*

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

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

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

अगर हैंडहेल्ड डिवाइस पर लागू की गई सुविधाएं, android.hardware.vr.high_performance सुविधा फ़्लैग के लिए सभी ज़रूरी शर्तें पूरी करती हैं, तो:

  • [H-1-1] android.hardware.vr.high_performance फ़ीचर फ़्लैग के बारे में एलान करना ज़रूरी है.*

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

ऑडियो एन्कोडिंग (सेक्शन 5.1.1)

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

  • [H-0-1] AMR-NB
  • [H-0-2] AMR-WB
  • [H-0-3] MPEG-4 AAC प्रोफ़ाइल (AAC LC)
  • [H-0-4] MPEG-4 HE AAC प्रोफ़ाइल (AAC+)
  • [H-0-5] एएसी ईएलडी (बेहतर लो डिले एएसी)

ऑडियो डिकोडिंग (सेक्शन 5.1.2)

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

  • [H-0-1] AMR-NB
  • [H-0-2] AMR-WB

वीडियो एन्कोडिंग (सेक्शन 5.2)

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

  • [H-0-1] H.264 AVC
  • [H-0-2] VP8

वीडियो डिकोडिंग (सेक्शन 5.3)

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

  • [H-0-1] H.264 एवीसी.
  • [H-0-2] H.265 HEVC.
  • [H-0-3] MPEG-4 SP.
  • [H-0-4] VP8.
  • [H-0-5] VP9.

2.2.3. सॉफ़्टवेयर

WebView के साथ काम करने की सुविधा (Section 3.4.1)

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

  • [H-0-1] android.webkit.Webview एपीआई को पूरी तरह से लागू करना ज़रूरी है.

अलग-अलग ब्राउज़र पर साइट की जांच करना (सेक्शन 3.4.2)

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

  • [H-0-1] इसमें सामान्य उपयोगकर्ता के लिए, वेब ब्राउज़िंग के लिए अलग से ब्राउज़र ऐप्लिकेशन शामिल होना चाहिए.

लॉन्चर (Section 3.8.1)

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

  • [H-SR] डिफ़ॉल्ट लॉन्चर को लागू करने का सुझाव दिया जाता है. यह लॉन्चर, ऐप्लिकेशन में शॉर्टकट और विजेट पिन करने की सुविधा के साथ काम करता हो.

  • [H-SR] डिफ़ॉल्ट लॉन्चर को लागू करने का सुझाव दिया जाता है. इससे तीसरे पक्ष के ऐप्लिकेशन से मिले अतिरिक्त शॉर्टकट को ShortcutManager API के ज़रिए तुरंत ऐक्सेस किया जा सकता है.

  • [H-SR] यह सुझाव दिया जाता है कि डिवाइस में डिफ़ॉल्ट लॉन्चर ऐप्लिकेशन शामिल हो, जो ऐप्लिकेशन आइकॉन के लिए बैज दिखाता हो.

विजेट (सेक्शन 3.8.2)

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

  • [H-SR] तीसरे पक्ष के ऐप्लिकेशन के विजेट इस्तेमाल करने की सुविधा देने का सुझाव दिया जाता है.

सूचनाएं (अनुच्छेद 3.8.3)

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

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

खोज (सेक्शन 3.8.4)

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

  • [H-SR] डिवाइस पर Assistant को लागू करने का सुझाव दिया जाता है, ताकि Assistant की कार्रवाई को मैनेज किया जा सके.

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

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

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

डिवाइस का मैनेजमेंट (सेक्शन 3.9)

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

सुलभता (सेक्शन 3.10)

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

  • [H-SR] MUST support third-party accessibility services.

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

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

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

  • [H-0-1] तीसरे पक्ष के टीटीएस इंजन इंस्टॉल करने की सुविधा होनी चाहिए.

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

क्विक सेटिंग (सेक्शन 3.13)

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

  • [H-SR] क्विक सेटिंग यूज़र इंटरफ़ेस (यूआई) कॉम्पोनेंट को शामिल करने का सुझाव दिया जाता है.

कंपैनियन डिवाइस को जोड़ना (सेक्शन 3.15)

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

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

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

उपयोगकर्ता अनुभव में एकरूपता (सेक्शन 8.1)

हाथ में रखकर इस्तेमाल किए जाने वाले डिवाइसों में सेट किए गए सिस्टम के लिए:

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

फ़ाइल I/O ऐक्सेस करने की परफ़ॉर्मेंस (सेक्शन 8.2)

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

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

बैटरी बचाने वाले मोड (सेक्शन 8.3)

हाथ में रखकर इस्तेमाल किए जाने वाले डिवाइसों में सेट किए गए सिस्टम के लिए:

  • [H-0-1] जिन ऐप्लिकेशन को App Standby और Doze के पावर-सेविंग मोड से छूट मिली है उन्हें असली उपयोगकर्ता को दिखना चाहिए.
  • [H-0-2] ऐप्लिकेशन स्टैंडबाय और बैटरी बचाने वाले डोज़ मोड को ट्रिगर करने, चालू रखने, और वेकअप करने वाले एल्गोरिदम के साथ-साथ, इनकी ग्लोबल सिस्टम सेटिंग का इस्तेमाल, Android Open Source Project के मुताबिक होना चाहिए.

बिजली की खपत का हिसाब (सेक्शन 8.4)

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

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

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

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

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

अनुमतियां (सेक्शन 9.1)

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

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

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

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

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

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

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

2.3.1. हार्डवेयर

बिना छुए नेविगेट करना (सेक्शन 7.2.2)

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

  • [T-0-1] डी-पैड के साथ काम करना ज़रूरी है.

नेविगेशन कुंजियां (सेक्शन 7.2.3)

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

  • [T-0-1] इसमें होम और बैक फ़ंक्शन होने चाहिए.
  • [T-0-2] बैक फ़ंक्शन (KEYCODE_BACK) के सामान्य और लंबे समय तक दबाए रखने वाले, दोनों इवेंट को फ़ोरग्राउंड ऐप्लिकेशन पर भेजना ज़रूरी है.

बटन मैपिंग (सेक्शन 7.2.6.1)

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

  • [T-0-1] यह ज़रूरी है कि डिवाइस, गेम कंट्रोलर के साथ काम करता हो. साथ ही, android.hardware.gamepad फ़ीचर फ़्लैग के बारे में एलान करना ज़रूरी है.

रिमोट कंट्रोल (सेक्शन 7.2.7)

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

जाइरोस्कोप (सेक्शन 7.3.4)

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

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

ब्लूटूथ (सेक्शन 7.4.3)

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

  • [T-0-1] इनमें ब्लूटूथ और ब्लूटूथ स्मार्ट काम करना चाहिए.

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

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

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

माइक्रोफ़ोन (सेक्शन 7.8.1)

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

  • इसमें माइक्रोफ़ोन शामिल होना चाहिए.

ऑडियो आउटपुट (सेक्शन 7.8.2)

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

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

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

ऑडियो एन्कोडिंग (सेक्शन 5.1)

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

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

वीडियो एन्कोडिंग (सेक्शन 5.2)

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

  • [T-0-1] H.264 एवीसी
  • [T-0-2] VP8

H-264 (Section 5.2.2)

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

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

वीडियो डिकोडिंग (सेक्शन 5.3)

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

  • [T-0-1] H.264 एवीसी
  • [T-0-2] H.265 HEVC
  • [T-0-3] MPEG-4 SP
  • [T-0-4] VP8
  • [T-0-5] VP9

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

  • [T-SR] MPEG-2

H.264 (Section 5.3.4)

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

  • [T-1-1] हाई प्रोफ़ाइल लेवल 4.2 और एचडी 1080 पिक्सल (60 एफ़पीएस पर) डिकोडिंग प्रोफ़ाइल के साथ काम करना ज़रूरी है.
  • [T-1-2] इसमें, यहां दी गई टेबल में बताई गई दोनों एचडी प्रोफ़ाइलों वाले वीडियो को डिकोड करने की सुविधा होनी चाहिए. साथ ही, वीडियो को बेसलाइन प्रोफ़ाइल, मुख्य प्रोफ़ाइल या हाई प्रोफ़ाइल लेवल 4.2 के साथ एन्कोड किया गया हो

H.265 (HEVC) (Section 5.3.5)

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

  • [T-1-1] Main Profile Level 4.1 Main tier के साथ काम करना ज़रूरी है.
  • [T-SR] एचडी 1080 पिक्सल के लिए, 60 एफ़पीएस के वीडियो फ़्रेम रेट का इस्तेमाल करने का सुझाव दिया जाता है.

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

  • [T-2-1] कोडेक को Main10 Level 5 Main Tier प्रोफ़ाइल के साथ काम करना ज़रूरी है.

VP8 (Section 5.3.6)

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

  • [T-1-1] HD 1080p60 डिकोडिंग प्रोफ़ाइल के साथ काम करना ज़रूरी है.

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

  • [T-2-1] HD 720p60 डिकोडिंग प्रोफ़ाइल के साथ काम करना ज़रूरी है.

VP9 (Section 5.3.7)

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

  • [T-1-1] 8-बिट कलर डेप्थ के साथ काम करना ज़रूरी है. साथ ही, VP9 प्रोफ़ाइल 2 (10-बिट) के साथ काम करना चाहिए.

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

  • [T-2-1] 1080 पिक्सल के लिए 60 एफ़पीएस (फ़्रेम प्रति सेकंड) का इस्तेमाल करना ज़रूरी है.

सुरक्षित मीडिया (सेक्शन 5.8)

अगर डिवाइस Android Television डिवाइस हैं और उनमें 4K रिज़ॉल्यूशन की सुविधा है, तो:

  • [T-1-1] सभी वायर्ड बाहरी डिसप्ले के लिए, HDCP 2.2 काम करना ज़रूरी है.

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

  • [T-2-1] सभी वायर्ड बाहरी डिसप्ले के लिए, HDCP 1.4 का इस्तेमाल किया जाना ज़रूरी है.

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

  • [T-SR] यह सुझाव दिया जाता है कि सुरक्षित स्ट्रीम को एक साथ डिकोड करने की सुविधा काम करे. कम से कम दो स्ट्रीम को एक साथ डिकोड करने की सुविधा होना ज़रूरी है.

ऑडियो आउटपुट का वॉल्यूम (सेक्शन 5.5.3)

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

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

2.3.3. सॉफ़्टवेयर

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

  • [T-0-1] android.software.leanback और android.hardware.type.television सुविधाओं के बारे में एलान करना ज़रूरी है.

WebView के साथ काम करने की सुविधा (Section 3.4.1)

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

  • [T-0-1] android.webkit.Webview एपीआई को पूरी तरह से लागू करना ज़रूरी है.

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

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

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

एक साथ कई विंडो इस्तेमाल करना (सेक्शन 3.8.14)

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

  • [T-SR] डिवाइसों में, पिक्चर में पिक्चर (पीआईपी) मोड वाली मल्टी-विंडो सुविधा काम करनी चाहिए.

सुलभता (सेक्शन 3.10)

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

  • [T-SR] MUST support third-party accessibility services.

  • [T-SR] Android Television डिवाइसों पर, सुलभता सेवाएं पहले से लोड करने का सुझाव दिया जाता है. ये सेवाएं, TalkBack ओपन सोर्स प्रोजेक्ट में दी गई सुलभता सेवाओं की तरह ही काम करती हैं. इनमें ऐक्सेस करने का तरीका बदलने और TalkBack (पहले से लोड किए गए टेक्स्ट-टू-स्पीच इंजन के साथ काम करने वाली भाषाओं के लिए) की सुलभता सेवाएं शामिल हैं.

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

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

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

  • [T-0-1] तीसरे पक्ष के टीटीएस इंजन इंस्टॉल करने की सुविधा होनी चाहिए.

टीवी इनपुट फ़्रेमवर्क (सेक्शन 3.12)

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

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

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

उपयोगकर्ता अनुभव में एकरूपता (सेक्शन 8.1)

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

  • [T-0-1] फ़्रेम के रेंडर होने में लगने वाला समय एक जैसा होना चाहिए. फ़्रेम रेंडर होने में लगने वाले समय में अंतर या फ़्रेम रेंडर होने में देरी, एक सेकंड में पांच फ़्रेम से ज़्यादा बार नहीं होनी चाहिए. साथ ही, यह एक सेकंड में एक फ़्रेम से कम होनी चाहिए.

फ़ाइल I/O ऐक्सेस करने की परफ़ॉर्मेंस (सेक्शन 8.2)

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

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

बैटरी बचाने वाले मोड (सेक्शन 8.3)

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

  • [T-0-1] जिन ऐप्लिकेशन को App Standby और Doze के पावर-सेविंग मोड से छूट मिली है उन्हें असली उपयोगकर्ता को दिखना चाहिए.
  • [T-0-2] ऐप्लिकेशन स्टैंडबाय और बैटरी बचाने वाले डोज़ मोड के ट्रिगर करने, रखरखाव करने, और वेकअप करने के एल्गोरिदम के साथ-साथ ग्लोबल सिस्टम सेटिंग का इस्तेमाल, Android Open Source Project से अलग नहीं होना चाहिए.

बिजली की खपत का हिसाब (सेक्शन 8.4)

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

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

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-2] ज़रूरी है कि इसमें टचस्क्रीन इनपुट की सुविधा हो.

ऐक्सिलरोमीटर (सेक्शन 7.3.1)

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

  • [W-SR] 3-ऐक्सिस एक्सलरोमीटर शामिल करने का सुझाव दिया जाता है.

ब्लूटूथ (सेक्शन 7.4.3)

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

  • [W-0-1] ब्लूटूथ की सुविधा होनी चाहिए.

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

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

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

माइक्रोफ़ोन (सेक्शन 7.8.1)

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

  • [W-0-1] माइक्रोफ़ोन शामिल करना ज़रूरी है.

ऑडियो आउटपुट (सेक्शन 7.8.1)

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

  • ऑडियो आउटपुट हो सकता है, लेकिन नहीं होना चाहिए.

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

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

2.4.3. सॉफ़्टवेयर

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

  • [W-0-1] android.hardware.type.watch सुविधा के बारे में एलान करना ज़रूरी है.
  • [W-0-2] uiMode = UI_MODE_TYPE_WATCH के साथ काम करना ज़रूरी है.

खोज (सेक्शन 3.8.4)

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

सुलभता (सेक्शन 3.10)

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

  • [W-1-1] तीसरे पक्ष की ऐक्सेसिबिलिटी सेवाओं के साथ काम करना ज़रूरी है.

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

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

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

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

  • [W-0-1] तीसरे पक्ष के टीटीएस इंजन इंस्टॉल करने की सुविधा होनी चाहिए.

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

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

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

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

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

2.5.1. हार्डवेयर

स्क्रीन का साइज़ (सेक्शन 7.1.1.1)

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

  • [A-0-1] डिवाइस में कम से कम छह इंच का डिसप्ले होना चाहिए.
  • [A-0-2] स्क्रीन का लेआउट कम से कम 750 dp x 480 dp का होना चाहिए.

नेविगेशन कुंजियां (सेक्शन 7.2.3)

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

  • [A-0-1] होम फ़ंक्शन उपलब्ध कराना ज़रूरी है. हालांकि, बैक और हाल ही के फ़ंक्शन उपलब्ध कराए जा सकते हैं.
  • [A-0-2] बैक फ़ंक्शन (KEYCODE_BACK) के सामान्य और लंबे समय तक दबाकर रखने वाले, दोनों इवेंट को फ़ोरग्राउंड ऐप्लिकेशन पर भेजना ज़रूरी है.

ऐक्सिलरोमीटर (सेक्शन 7.3.1)

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

  • [A-SR] 3-ऐक्सिस एक्सलरोमीटर शामिल करने का सुझाव दिया जाता है.

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

जीपीएस (सेक्शन 7.3.3)

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

  • [A-1-1] जीएनएसएस टेक्नोलॉजी जनरेशन "2017" या उसके बाद का होना चाहिए.

जाइरोस्कोप (सेक्शन 7.3.4)

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

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

सिर्फ़ Android Automotive के लिए सेंसर (सेक्शन 7.3.11) मौजूदा गियर (सेक्शन 7.3.11.1)

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

  • मौजूदा गियर को SENSOR_TYPE_GEAR के तौर पर दिखाना चाहिए.

डे नाइट मोड (सेक्शन 7.3.11.2)

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

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

ड्राइविंग स्टेटस (सेक्शन 7.3.11.3)

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

  • [A-0-1] वाहन के पूरी तरह से रुकने और पार्क होने पर, ड्राइविंग स्टेटस को SENSOR_TYPE_DRIVING_STATUS के तौर पर तय करना ज़रूरी है. साथ ही, इसकी डिफ़ॉल्ट वैल्यू DRIVE_STATUS_UNRESTRICTED होनी चाहिए. डिवाइस बनाने वाली कंपनियों की यह ज़िम्मेदारी है कि वे SENSOR_TYPE_DRIVING_STATUS को उन सभी कानूनों और नियमों के मुताबिक कॉन्फ़िगर करें जो उन देशों पर लागू होते हैं जहां प्रॉडक्ट को शिप किया जा रहा है.

पहिए की स्पीड (सेक्शन 7.3.11.4)

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

  • [A-0-1] वाहन की रफ़्तार की जानकारी देना ज़रूरी है. इसे SENSOR_TYPE_CAR_SPEED के तौर पर तय किया गया है.

ब्लूटूथ (सेक्शन 7.4.3)

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

  • [A-0-1] इनमें ब्लूटूथ काम करना चाहिए. साथ ही, इनमें ब्लूटूथ स्मार्ट भी काम करना चाहिए.

  • [A-0-2] Android Automotive में, ब्लूटूथ की इन प्रोफ़ाइलों का इस्तेमाल किया जा सकता है:

    • हैंड्स-फ़्री प्रोफ़ाइल (एचएफ़पी) के ज़रिए फ़ोन कॉल करने की सुविधा.
    • ऑडियो डिस्ट्रिब्यूशन प्रोफ़ाइल (A2DP) के ज़रिए मीडिया प्लेबैक.
    • रिमोट कंट्रोल प्रोफ़ाइल (एवीआरसीपी) के ज़रिए मीडिया प्लेबैक को कंट्रोल करना.
    • फ़ोन बुक ऐक्सेस प्रोफ़ाइल (पीबीएपी) का इस्तेमाल करके संपर्क शेयर करने की सुविधा.
  • यह ज़रूरी है कि मैसेज ऐक्सेस प्रोफ़ाइल (एमएपी) काम करती हो.

नेटवर्क की कम से कम क्षमता (सेक्शन 7.4.5)

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

  • इसमें मोबाइल नेटवर्क पर डेटा कनेक्टिविटी की सुविधा होनी चाहिए.

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

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

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

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

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

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

माइक्रोफ़ोन (सेक्शन 7.8.1)

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

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

ऑडियो आउटपुट (सेक्शन 7.8.2)

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

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

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

ऑडियो एन्कोडिंग (सेक्शन 5.1)

Automotive डिवाइस में सेट किए गए सिस्टम में, ऑडियो को इस तरह से एन्कोड किया जाना चाहिए:

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

वीडियो एन्कोडिंग (सेक्शन 5.2)

Automotive डिवाइस में सेट किए गए सिस्टम में, यहां दी गई वीडियो एन्कोडिंग का इस्तेमाल किया जाना चाहिए:

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

वीडियो डिकोडिंग (सेक्शन 5.3)

Automotive डिवाइस में सेट किए गए सिस्टम में, वीडियो डिकोडिंग की ये सुविधाएं काम करनी चाहिए:

  • [A-0-1] H.264 एवीसी
  • [A-0-2] MPEG-4 SP
  • [A-0-3] VP8
  • [A-0-4] VP9

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

  • [A-SR] H.265 HEVC

2.5.3. सॉफ़्टवेयर

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

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

WebView के साथ काम करने की सुविधा (Section 3.4.1)

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

  • [A-0-1] android.webkit.Webview API को पूरी तरह से लागू करना ज़रूरी है.

सूचनाएं (अनुच्छेद 3.8.3)

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

  • [A-0-1] तीसरे पक्ष के ऐप्लिकेशन के अनुरोध करने पर, Notification.CarExtender एपीआई का इस्तेमाल करके सूचनाएं दिखानी होंगी.

खोज (सेक्शन 3.8.4)

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

  • [A-0-1] डिवाइस पर, Assistant की कार्रवाई को मैनेज करने के लिए, Assistant की सुविधा लागू करना ज़रूरी है.

मीडिया यूज़र इंटरफ़ेस (सेक्शन 3.14)

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

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

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

बैटरी बचाने वाले मोड (सेक्शन 8.3)

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

  • [A-0-1] जिन ऐप्लिकेशन को App Standby और Doze के पावर-सेविंग मोड से छूट मिली है उन्हें असली उपयोगकर्ता को दिखना चाहिए.
  • [A-0-2] ऐप्लिकेशन स्टैंडबाय और बैटरी बचाने वाले डोज़ मोड को ट्रिगर करने, चालू रखने, और वेकअप करने वाले एल्गोरिदम के साथ-साथ, ग्लोबल सिस्टम सेटिंग का इस्तेमाल Android Open Source Project के मुताबिक होना चाहिए.

बिजली की खपत का हिसाब (सेक्शन 8.4)

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

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

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

एक डिवाइस पर कई लोगों के काम करने की सुविधा (सेक्शन 9.5)

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

  • [A-1-1] इसमें एक गेस्ट खाता शामिल होना चाहिए. इससे उपयोगकर्ता को लॉग इन किए बिना, वाहन के सिस्टम की सभी सुविधाओं का इस्तेमाल करने की अनुमति मिलती है.

ऑटोमोटिव वाहन सिस्टम आइसोलेशन (सेक्शन 9.14)

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

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

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

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

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

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

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

2.4.1. हार्डवेयर

स्क्रीन का साइज़ (सेक्शन 7.1.1.1)

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

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

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

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

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

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

  • Android Open Accessory (AOA) API लागू कर सकता है.

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

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

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

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 देखें.

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

Android में, एपीआई लेवल के वर्शन को बदले बिना मैनेज किए गए एपीआई को बढ़ाने की सुविधा शामिल है.

  • [C-0-1] Android डिवाइसों में, शेयर की गई लाइब्रेरी ExtShared और सेवाओं ExtServices के AOSP वर्शन को पहले से लोड करना ज़रूरी है. इनका वर्शन, हर एपीआई लेवल के लिए अनुमति वाले कम से कम वर्शन से ज़्यादा या उसके बराबर होना चाहिए. उदाहरण के लिए, Android 7.0 डिवाइसों पर एपीआई लेवल 24 का इस्तेमाल करने के लिए, कम से कम वर्शन 1 शामिल होना चाहिए.

3.2. सॉफ़्ट एपीआई कंपैटिबिलिटी

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

3.2.1. अनुमतियां

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

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

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

  • [C-0-1] डिवाइसों पर एक जैसी और काम की वैल्यू देने के लिए, यहां दी गई टेबल में इन वैल्यू के फ़ॉर्मैट पर अतिरिक्त पाबंदियां शामिल हैं. डिवाइसों पर सेट किए जाने वाले सिस्टम को इन पाबंदियों का पालन करना होगा.
पैरामीटर जानकारी
VERSION.RELEASE Android सिस्टम के मौजूदा वर्शन की जानकारी, जिसे कोई भी व्यक्ति आसानी से पढ़ सकता है. इस फ़ील्ड में, 8.1 में दी गई स्ट्रिंग वैल्यू में से कोई एक वैल्यू होना ज़रूरी है.
VERSION.SDK यह Android सिस्टम के उस वर्शन की जानकारी देता है जो फ़िलहाल चल रहा है. यह जानकारी, तीसरे पक्ष के ऐप्लिकेशन कोड के लिए उपलब्ध होती है. Android 8.1 के लिए, इस फ़ील्ड में पूर्णांक वैल्यू 8.1_INT होनी चाहिए.
VERSION.SDK_INT यह Android सिस्टम के उस वर्शन की जानकारी देता है जो फ़िलहाल चल रहा है. यह जानकारी, तीसरे पक्ष के ऐप्लिकेशन कोड के लिए उपलब्ध होती है. Android 8.1 के लिए, इस फ़ील्ड में पूर्णांक वैल्यू 8.1_INT होनी चाहिए.
VERSION.INCREMENTAL यह वैल्यू, डिवाइस बनाने वाली कंपनी चुनती है. इससे, फ़िलहाल चल रहे Android सिस्टम के खास बिल्ड के बारे में पता चलता है. यह वैल्यू, इंसानों के पढ़ने लायक फ़ॉर्मैट में होती है. इस वैल्यू का दोबारा इस्तेमाल, असली उपयोगकर्ताओं के लिए उपलब्ध कराई गई अलग-अलग बिल्ड के लिए नहीं किया जाना चाहिए. इस फ़ील्ड का इस्तेमाल आम तौर पर यह बताने के लिए किया जाता है कि बिल्ड जनरेट करने के लिए, किस बिल्ड नंबर या सोर्स-कंट्रोल चेंज आइडेंटिफ़ायर का इस्तेमाल किया गया था. इस फ़ील्ड के लिए, किसी खास फ़ॉर्मैट की ज़रूरत नहीं है. हालांकि, यह ज़रूरी है कि यह फ़ील्ड शून्य या खाली स्ट्रिंग ("") न हो.
बोर्ड डिवाइस को लागू करने वाले व्यक्ति या कंपनी की चुनी गई वैल्यू, जिससे डिवाइस में इस्तेमाल किए गए इंटरनल हार्डवेयर की पहचान होती है. यह वैल्यू, इंसानों के पढ़ने लायक फ़ॉर्मैट में होती है. इस फ़ील्ड का इस्तेमाल, डिवाइस को पावर देने वाले बोर्ड के खास वर्शन के बारे में बताने के लिए किया जा सकता है. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर कोड में बदला जा सकता है. साथ ही, यह रेगुलर एक्सप्रेशन “^[a-zA-Z0-9_-]+$” से मेल खानी चाहिए.
ब्रैंड यह वैल्यू, डिवाइस से जुड़े ब्रैंड के नाम को दिखाती है. यह नाम, असली उपयोगकर्ताओं को दिखता है. यह ऐसा फ़ॉर्मैट होना चाहिए जिसे आसानी से पढ़ा जा सके. साथ ही, इससे डिवाइस के मैन्युफ़ैक्चरर या उस कंपनी के ब्रैंड का पता चलना चाहिए जिसके नाम पर डिवाइस की मार्केटिंग की जाती है. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर कोड में बदला जा सकता है. साथ ही, यह रेगुलर एक्सप्रेशन “^[a-zA-Z0-9_-]+$” से मेल खानी चाहिए.
SUPPORTED_ABIS नेटिव कोड के निर्देश सेट (सीपीयू टाइप + एबीआई कन्वेंशन) का नाम. सेक्शन 3.3 देखें. Native API Compatibility.
SUPPORTED_32_BIT_ABIS नेटिव कोड के निर्देश सेट (सीपीयू टाइप + एबीआई कन्वेंशन) का नाम. सेक्शन 3.3 देखें. Native API Compatibility.
SUPPORTED_64_BIT_ABIS नेटिव कोड के दूसरे इंस्ट्रक्शन सेट (सीपीयू टाइप + एबीआई कन्वेंशन) का नाम. सेक्शन 3.3 देखें. Native API Compatibility.
CPU_ABI नेटिव कोड के निर्देश सेट (सीपीयू टाइप + एबीआई कन्वेंशन) का नाम. सेक्शन 3.3 देखें. Native API Compatibility.
CPU_ABI2 नेटिव कोड के दूसरे इंस्ट्रक्शन सेट (सीपीयू टाइप + एबीआई कन्वेंशन) का नाम. सेक्शन 3.3 देखें. Native API Compatibility.
डिवाइस यह वैल्यू, डिवाइस को लागू करने वाले व्यक्ति या कंपनी ने चुनी होती है. इसमें डेवलपमेंट का नाम या कोड नेम होता है. इससे डिवाइस के हार्डवेयर की सुविधाओं और इंडस्ट्रियल डिज़ाइन के कॉन्फ़िगरेशन की पहचान होती है. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर कोड में बदला जाना चाहिए. साथ ही, यह रेगुलर एक्सप्रेशन “^[a-zA-Z0-9_-]+$” से मेल खानी चाहिए. प्रॉडक्ट के जीवनकाल के दौरान, डिवाइस का यह नाम नहीं बदलना चाहिए.
FINGERPRINT यह एक स्ट्रिंग होती है, जो इस बिल्ड की खास तौर पर पहचान करती है. यह ऐसा होना चाहिए जिसे आसानी से पढ़ा जा सके. यह इस टेंप्लेट के मुताबिक होना चाहिए:

$(BRAND)/$(PRODUCT)/
    $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)

उदाहरण के लिए:

acme/myproduct/
    mydevice:8.1/LMYXX/3359:userdebug/test-keys

फ़िंगरप्रिंट में खाली सफ़ेद जगह वाले वर्ण शामिल नहीं होने चाहिए. अगर ऊपर दिए गए टेंप्लेट में शामिल अन्य फ़ील्ड में खाली सफ़ेद जगह वाले वर्ण हैं, तो उन्हें बिल्ड फ़िंगरप्रिंट में किसी दूसरे वर्ण से बदलना होगा. जैसे, अंडरस्कोर ("_") वर्ण. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर कोड में बदला जा सकता है.

हार्डवेयर हार्डवेयर का नाम (कर्नेल कमांड लाइन या /proc से). यह ऐसा होना चाहिए जिसे आसानी से पढ़ा जा सके. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर कोड में बदला जा सकता है. साथ ही, यह रेगुलर एक्सप्रेशन “^[a-zA-Z0-9_-]+$” से मेल खानी चाहिए.
HOST यह एक ऐसी स्ट्रिंग होती है जो उस होस्ट की खास तौर पर पहचान करती है जिस पर बिल्ड बनाया गया था. यह स्ट्रिंग, ऐसे फ़ॉर्मैट में होती है जिसे कोई भी व्यक्ति आसानी से पढ़ सकता है. इस फ़ील्ड के लिए, किसी खास फ़ॉर्मैट की ज़रूरत नहीं है. हालांकि, यह ज़रूरी है कि यह फ़ील्ड शून्य या खाली स्ट्रिंग ("") न हो.
ID यह एक आइडेंटिफ़ायर है. इसे डिवाइस बनाने वाली कंपनी चुनती है. इसका इस्तेमाल किसी खास रिलीज़ को रेफ़र करने के लिए किया जाता है. यह आइडेंटिफ़ायर, ऐसा फ़ॉर्मैट होता है जिसे आसानी से पढ़ा जा सकता है. यह फ़ील्ड, android.os.Build.VERSION.INCREMENTAL के जैसा हो सकता है. हालांकि, यह ऐसा होना चाहिए जिससे असली उपयोगकर्ता, सॉफ़्टवेयर बिल्ड के बीच अंतर कर सकें. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर कोड में बदला जा सकता है. साथ ही, यह रेगुलर एक्सप्रेशन “^[a-zA-Z0-9._-]+$” से मेल खानी चाहिए.
निर्माता प्रॉडक्ट के ओरिजनल इक्विपमेंट मैन्युफ़ैक्चरर (ओईएम) का ट्रेड नेम. इस फ़ील्ड के लिए, किसी खास फ़ॉर्मैट की ज़रूरत नहीं होती. हालांकि, यह ज़रूरी है कि यह फ़ील्ड शून्य या खाली स्ट्रिंग ("") न हो. प्रॉडक्ट के लाइफ़टाइम के दौरान, इस फ़ील्ड में बदलाव नहीं किया जाना चाहिए.
MODEL डिवाइस को लागू करने वाले व्यक्ति या कंपनी की चुनी गई वैल्यू. इसमें डिवाइस का वह नाम होता है जो उपयोगकर्ता को दिखता है. यह वही नाम होना चाहिए जिससे डिवाइस को मार्केट में लाया जाता है और असली उपयोगकर्ताओं को बेचा जाता है. इस फ़ील्ड के लिए, किसी खास फ़ॉर्मैट की ज़रूरत नहीं होती. हालांकि, यह ज़रूरी है कि यह फ़ील्ड शून्य या खाली स्ट्रिंग ("") न हो. प्रॉडक्ट के लाइफ़टाइम के दौरान, इस फ़ील्ड में बदलाव नहीं किया जाना चाहिए.
प्रॉडक्ट डिवाइस बनाने वाली कंपनी की चुनी गई वैल्यू. इसमें किसी खास प्रॉडक्ट (एसकेयू) का डेवलपमेंट नेम या कोड नेम होता है. यह एक ही ब्रैंड के लिए यूनीक होना चाहिए. यह ऐसा होना चाहिए जिसे लोग आसानी से पढ़ सकें. हालांकि, यह ज़रूरी नहीं है कि इसे असली उपयोगकर्ता देखें. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर कोड में बदला जाना चाहिए. साथ ही, यह रेगुलर एक्सप्रेशन “^[a-zA-Z0-9_-]+$” से मेल खानी चाहिए. प्रॉडक्ट के जीवनकाल के दौरान, प्रॉडक्ट का नाम नहीं बदलना चाहिए.
सीरियल हार्डवेयर का सीरियल नंबर. यह एक ही मॉडल और मैन्युफ़ैक्चरर के सभी डिवाइसों के लिए उपलब्ध होना चाहिए और यूनीक होना चाहिए. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर कोड में बदला जा सकता है. साथ ही, यह रेगुलर एक्सप्रेशन “^([a-zA-Z0-9]{6,20})$” से मेल खानी चाहिए.
टैग डिवाइस बनाने वाली कंपनी की ओर से चुने गए टैग की कॉमा लगाकर अलग की गई सूची. इससे बिल्ड को और बेहतर तरीके से पहचाना जा सकता है. इस फ़ील्ड में, Android प्लैटफ़ॉर्म के तीन सामान्य साइनिंग कॉन्फ़िगरेशन में से किसी एक से मेल खाने वाली वैल्यू होनी चाहिए: release-keys, dev-keys, test-keys.
समय यह वैल्यू, बिल्ड होने के समय के टाइमस्टैंप को दिखाती है.
वाई-फ़ाई के टाइप के बारे में जानकारी डिवाइस बनाने वाली कंपनी की ओर से चुनी गई वैल्यू, जो बिल्ड के रनटाइम कॉन्फ़िगरेशन के बारे में बताती है. इस फ़ील्ड में, Android के तीन सामान्य रनटाइम कॉन्फ़िगरेशन में से किसी एक की वैल्यू होनी चाहिए: उपयोगकर्ता, उपयोगकर्ता डीबग या इंजीनियरिंग.
उपयोगकर्ता उस उपयोगकर्ता (या अपने-आप काम करने वाले उपयोगकर्ता) का नाम या यूज़र आईडी जिसने बिल्ड जनरेट किया है. इस फ़ील्ड के लिए, किसी खास फ़ॉर्मैट की ज़रूरत नहीं है. हालांकि, यह ज़रूरी है कि यह फ़ील्ड शून्य या खाली स्ट्रिंग ("") न हो.
SECURITY_PATCH यह वैल्यू, किसी बिल्ड के सुरक्षा पैच के लेवल के बारे में बताती है. इससे यह पता चलना चाहिए कि बिल्ड में, Android के सार्वजनिक सुरक्षा बुलेटिन में बताई गई किसी भी समस्या का कोई खतरा नहीं है. यह [YYYY-MM-DD] फ़ॉर्मैट में होना चाहिए. साथ ही, यह Android के सार्वजनिक सुरक्षा बुलेटिन या Android की सुरक्षा से जुड़ी सलाह में दिए गए स्ट्रिंग से मेल खाना चाहिए. उदाहरण के लिए, "2015-11-01".
BASE_OS यह वैल्यू, बिल्ड के FINGERPRINT पैरामीटर को दिखाती है. यह बिल्ड, Android Public Security Bulletin में दिए गए पैच को छोड़कर, इस बिल्ड के जैसा ही होता है. इसे सही वैल्यू रिपोर्ट करनी चाहिए. अगर ऐसा कोई बिल्ड मौजूद नहीं है, तो खाली स्ट्रिंग ("") रिपोर्ट करें.
बूटलोडर डिवाइस में सेट किए गए सिस्टम को लागू करने वाले व्यक्ति या कंपनी की चुनी गई वैल्यू. इससे डिवाइस में इस्तेमाल किए गए इंटरनल बूटलोडर के खास वर्शन की पहचान होती है. यह वैल्यू, इंसानों के पढ़ने लायक फ़ॉर्मैट में होती है. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर कोड में बदला जा सकता है. साथ ही, यह रेगुलर एक्सप्रेशन “^[a-zA-Z0-9._-]+$” से मेल खानी चाहिए.
getRadioVersion() यह डिवाइस बनाने वाली कंपनी की चुनी गई वैल्यू होनी चाहिए. इससे डिवाइस में इस्तेमाल किए गए इंटरनल रेडियो/मॉडम के वर्शन की पहचान होती है. यह वैल्यू, इंसानों के पढ़ने लायक फ़ॉर्मैट में होनी चाहिए. अगर किसी डिवाइस में कोई इंटरनल रेडियो/मॉडेम नहीं है, तो उसे NULL वैल्यू दिखानी होगी. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर कोड में बदला जा सकता है. साथ ही, यह रेगुलर एक्सप्रेशन “^[a-zA-Z0-9._-,]+$” से मेल खानी चाहिए.

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

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

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

  • [C-0-1] डिवाइसों में, एक या उससे ज़्यादा ऐप्लिकेशन या सेवा कॉम्पोनेंट को इंटेंट हैंडलर के साथ प्रीलोड करना ज़रूरी है. ऐसा AOSP में मौजूद इन मुख्य Android ऐप्लिकेशन के ज़रिए तय किए गए सभी सार्वजनिक इंटेंट फ़िल्टर पैटर्न के लिए करना होगा:

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

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

  • [C-0-3] डिवाइसों में, उपयोगकर्ताओं को ऐसा यूज़र इंटरफ़ेस देना ज़रूरी है जिसकी मदद से वे इंटेंट के लिए डिफ़ॉल्ट गतिविधि में बदलाव कर सकें.

  • हालांकि, डिवाइस लागू करने वाले लोग या कंपनियां, खास यूआरआई पैटर्न (जैसे, http://play.google.com) के लिए डिफ़ॉल्ट गतिविधियां उपलब्ध करा सकती हैं. ऐसा तब किया जा सकता है, जब डिफ़ॉल्ट गतिविधि, डेटा यूआरआई के लिए ज़्यादा खास एट्रिब्यूट उपलब्ध कराती हो. उदाहरण के लिए, “http://www.android.com” डेटा यूआरआई के बारे में बताने वाला इंटेंट फ़िल्टर पैटर्न, ब्राउज़र के “http://” के लिए कोर इंटेंट पैटर्न से ज़्यादा सटीक होता है.

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

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

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

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

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

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

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

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

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

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

  • [C-2-1] ऐप्लिकेशन में सेटिंग मेन्यू होना चाहिए. इससे android.provider.Telephony.ACTION_CHANGE_DEFAULT इंटेंट को कॉल किया जा सके, ताकि डिफ़ॉल्ट एसएमएस ऐप्लिकेशन बदलने के लिए डायलॉग दिखाया जा सके.

  • [C-2-2] android.telecom.action.CHANGE_DEFAULT_DIALER के इंटेंट का पालन करना ज़रूरी है, ताकि उपयोगकर्ता को एक डायलॉग दिखाया जा सके. इससे उपयोगकर्ता, डिफ़ॉल्ट फ़ोन ऐप्लिकेशन को बदल पाएगा.

  • [C-2-3] android.telecom.action.CHANGE_PHONE_ACCOUNTS इंटेंट का पालन करना ज़रूरी है, ताकि उपयोगकर्ता को PhoneAccounts से जुड़े ConnectionServices को कॉन्फ़िगर करने की सुविधा मिल सके. साथ ही, उसे डिफ़ॉल्ट PhoneAccount को कॉन्फ़िगर करने की सुविधा मिल सके, जिसका इस्तेमाल टेलीकम्यूनिकेशन सेवा देने वाली कंपनी, आउटगोइंग कॉल करने के लिए करेगी. AOSP में इस सुविधा को लागू करने के लिए, "कॉल" सेटिंग मेन्यू में "कॉलिंग खाते का विकल्प" मेन्यू शामिल किया गया है.

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

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

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

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

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

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

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

अगर डिवाइस में, सेकंडरी डिसप्ले पर सामान्य Android Activities लॉन्च करने की सुविधा है और प्राइमरी और सेकंडरी डिसप्ले में अलग-अलग android.util.DisplayMetrics हैं, तो:

  • [C-2-1] एपीआई लेवल 23 या इससे पहले के लेवल को टारगेट करने वाले ऐप्लिकेशन और ऐसी गतिविधियां जिनका साइज़ नहीं बदला जा सकता (जिनमें resizeableActivity=false में AndroidManifest.xml है) को सेकंडरी डिसप्ले पर अनुमति नहीं दी जानी चाहिए.

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

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

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

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

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

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

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

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

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

  • [C-0-1] को एक या उससे ज़्यादा तय किए गए ABI के साथ काम करना चाहिए. साथ ही, Android NDK के साथ काम करने की सुविधा लागू करनी चाहिए.
  • [C-0-2] इसमें मैनेज किए जा रहे एनवायरमेंट में कोड चलाने की सुविधा शामिल होनी चाहिए, ताकि नेटिव कोड को कॉल किया जा सके. इसके लिए, स्टैंडर्ड Java Native Interface (JNI) सिमैंटिक्स का इस्तेमाल किया जाता है.
  • [C-0-3] यह ज़रूरी है कि नीचे दी गई सूची में मौजूद हर ज़रूरी लाइब्रेरी के साथ, सोर्स-कंपैटिबल (यानी कि हेडर-कंपैटिबल) और बाइनरी-कंपैटिबल (एबीआई के लिए) हो.
  • [C-0-4] अगर कोई 64-बिट ABI काम करता है, तो उसके बराबर का 32-बिट ABI काम करना ज़रूरी है.
  • [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] ऊपर दिए गए पैरामीटर के ज़रिए, सिर्फ़ उन एबीआइ की जानकारी देनी होगी जिनके बारे में Android NDK ABI Management के दस्तावेज़ के नए वर्शन में बताया गया है. साथ ही, इसमें Advanced SIMD (इसे NEON भी कहा जाता है) एक्सटेंशन के लिए सहायता शामिल होनी चाहिए.

  • [C-0-7] नेटिव एपीआई उपलब्ध कराने वाली इन सभी लाइब्रेरी को, नेटिव कोड वाले ऐप्लिकेशन के लिए उपलब्ध कराना ज़रूरी है:

    • libaaudio.so (AAudio की नेटिव ऑडियो सहायता)
    • 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 (गणित लाइब्रेरी)
    • libOpenMAXAL.so (OpenMAX AL 1.0.1 के साथ काम करता है)
    • libOpenSLES.so (OpenSL ES 1.0.1 ऑडियो सपोर्ट)
    • libRS.so
    • libstdc++ (C++ के लिए कम से कम सहायता)
    • libvulkan.so (Vulkan)
    • libz (Zlib कंप्रेशन)
    • JNI इंटरफ़ेस

  • [C-0-8] ऊपर दी गई नेटिव लाइब्रेरी के लिए, सार्वजनिक फ़ंक्शन जोड़े या हटाए नहीं जाने चाहिए.

  • [C-0-9] /vendor/etc/public.libraries.txt में, सीधे तौर पर तीसरे पक्ष के ऐप्लिकेशन को उपलब्ध कराई गई, AOSP के अलावा अन्य लाइब्रेरी की सूची देना ज़रूरी है.
  • [C-0-10] सिस्टम लाइब्रेरी के तौर पर AOSP में लागू की गई और उपलब्ध कराई गई किसी भी अन्य नेटिव लाइब्रेरी को, एपीआई लेवल 24 या उसके बाद के वर्शन को टारगेट करने वाले तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध नहीं कराना चाहिए. ऐसा इसलिए, क्योंकि ये लाइब्रेरी रिज़र्व होती हैं.
  • [C-0-11] NDK में बताए गए सभी OpenGL ES 3.1 और Android Extension Pack फ़ंक्शन सिंबल को libGLESv3.so लाइब्रेरी के ज़रिए एक्सपोर्ट करना ज़रूरी है. ध्यान दें कि सभी सिंबल मौजूद होने चाहिए. हालांकि, सेक्शन 7.1.4.1 में इस बारे में ज़्यादा जानकारी दी गई है कि हर फ़ंक्शन को पूरी तरह से लागू करने की ज़रूरत कब होती है.
  • [C-0-12] libvulkan.so लाइब्रेरी के ज़रिए, Vulkan 1.0 के मुख्य फ़ंक्शन सिंबल के साथ-साथ VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1, और VK_KHR_get_physical_device_properties2 एक्सटेंशन के लिए फ़ंक्शन सिंबल एक्सपोर्ट करना ज़रूरी है. ध्यान दें कि सभी सिंबल मौजूद होने चाहिए. हालांकि, सेक्शन 7.1.4.2 में इस बारे में ज़्यादा जानकारी दी गई है कि हर फ़ंक्शन को पूरी तरह से लागू करने की ज़रूरत कब होती है.
  • इसे Android Open Source Project के अपस्ट्रीम में उपलब्ध सोर्स कोड और हेडर फ़ाइलों का इस्तेमाल करके बनाया जाना चाहिए

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

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

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

  • [C-1-1] ARMv8 आर्किटेक्चर में, सीपीयू की कई कार्रवाइयों को बंद कर दिया गया है. इनमें मौजूदा नेटिव कोड में इस्तेमाल की जाने वाली कुछ कार्रवाइयां भी शामिल हैं. हालांकि, बंद की गई ये कार्रवाइयां, 32-बिट नेटिव ARM कोड के लिए उपलब्ध होनी चाहिए. ऐसा, नेटिव सीपीयू सपोर्ट या सॉफ़्टवेयर इम्यूलेशन के ज़रिए किया जा सकता है:

    • SWP और SWPB के निर्देश
    • SETEND निर्देश
    • CP15ISB, CP15DSB, और CP15DMB बैरियर ऑपरेशंस

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

  • [C-2-1] 32-बिट ARM ऐप्लिकेशन से पढ़े जाने पर, /proc/cpuinfo में ये लाइनें शामिल होनी चाहिए. इससे यह पक्का किया जा सकेगा कि यह Android NDK के लेगसी वर्शन का इस्तेमाल करके बनाए गए ऐप्लिकेशन के साथ काम करता है.

    • Features:, इसके बाद डिवाइस के साथ काम करने वाली ARMv7 सीपीयू की किसी भी सुविधा की सूची दी गई है.
    • CPU architecture:, इसके बाद एक पूर्णांक होता है.यह पूर्णांक, डिवाइस के सबसे ज़्यादा सपोर्ट किए गए एआरएम आर्किटेक्चर के बारे में बताता है. उदाहरण के लिए, "8" for ARMv8 devices).

  • 64-बिट ARM या नॉन-ARM ऐप्लिकेशन से पढ़ने पर, /proc/cpuinfo में बदलाव नहीं होना चाहिए.

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

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

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

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

  • [C-1-3] WebView से रिपोर्ट की गई उपयोगकर्ता एजेंट स्ट्रिंग इस फ़ॉर्मैट में होनी चाहिए:

    Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) Build/$(BUILD); wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36

    • $(VERSION) स्ट्रिंग की वैल्यू, android.os.Build.VERSION.RELEASE की वैल्यू के बराबर होनी चाहिए.
    • $(MODEL) स्ट्रिंग की वैल्यू, android.os.Build.MODEL की वैल्यू के बराबर होनी चाहिए.
    • $(BUILD) स्ट्रिंग की वैल्यू, android.os.Build.ID की वैल्यू के बराबर होनी चाहिए.
    • $(CHROMIUM_VER) स्ट्रिंग की वैल्यू, Android Open Source Project के अपस्ट्रीम में मौजूद Chromium का वर्शन होना चाहिए.
    • डिवाइस लागू करने वाले लोग, उपयोगकर्ता एजेंट स्ट्रिंग में मोबाइल को शामिल न करें.

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

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

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

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

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

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

3.5. एपीआई के व्यवहार से जुड़ी कंपैटिबिलिटी

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

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

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

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

  • java.*
  • javax.*
  • sun.*
  • android.*
  • com.android.*

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

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

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

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

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

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

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

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

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

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

  • [C-0-1] इसमें पूरे Dalvik Executable (DEX) फ़ॉर्मैट और Dalvik bytecode specification and semantics काम करने चाहिए.

  • [C-0-2] Dalvik रनटाइम को कॉन्फ़िगर करना ज़रूरी है, ताकि अपस्ट्रीम Android प्लैटफ़ॉर्म के हिसाब से मेमोरी असाइन की जा सके. साथ ही, यहां दी गई टेबल में बताए गए तरीके से मेमोरी असाइन की जा सके. (स्क्रीन के साइज़ और स्क्रीन डेंसिटी की परिभाषाओं के लिए, सेक्शन 7.1.1 देखें.)

  • Android RunTime (ART) का इस्तेमाल करना चाहिए. यह Dalvik Executable Format का अपस्ट्रीम रेफ़रंस है. साथ ही, रेफ़रंस के तौर पर लागू किए गए पैकेज मैनेजमेंट सिस्टम का इस्तेमाल करना चाहिए.

  • रनटाइम की स्थिरता की पुष्टि करने के लिए, इसे अलग-अलग मोड में एक्ज़ीक्यूट करके और टारगेट आर्किटेक्चर के तहत फ़ज़ टेस्ट करने चाहिए. Android Open Source Project की वेबसाइट पर, JFuzz और DexFuzz के बारे में पढ़ें.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.2. विजेट

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

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

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

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

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

3.8.3. सूचनाएं

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

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

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

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

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

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

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

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

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

अगर डिवाइसों पर लागू की गई सुविधाओं में, android.hardware.ram.normal फ़ीचर फ़्लैग की रिपोर्ट दी जाती है, तो:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • यह एक ग्रुप के तौर पर, हाल ही में देखे गए अफ़िलिएटेड कॉन्टेंट को दिखा सकता है.

  • [SR] ओवरव्यू स्क्रीन के लिए, अपस्ट्रीम Android यूज़र इंटरफ़ेस (या थंबनेल पर आधारित मिलता-जुलता इंटरफ़ेस) इस्तेमाल करने का सुझाव दिया जाता है.

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

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

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

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

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

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

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

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

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

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

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

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

  • [C-1-1] location modes को सेटिंग में मौजूद Location मेन्यू में दिखाया जाना चाहिए.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [C-1-2] मैनेज की जा रही प्रोफ़ाइल को चालू करने की प्रोसेस (android.app.action.PROVISION_MANAGED_PROFILE से शुरू होने वाला फ़्लो) में उपयोगकर्ताओं को मिलने वाला अनुभव, AOSP के साथ काम करने वाला होना चाहिए.

  • [C-1-3] डिवाइस नीति कंट्रोलर (डीपीसी) की वजह से, सिस्टम के किसी फ़ंक्शन के बंद होने की जानकारी देने के लिए, सेटिंग में उपयोगकर्ता को ये सुविधाएं उपलब्ध करानी होंगी:

    • एक जैसा आइकॉन या उपयोगकर्ता के लिए उपलब्ध अन्य सुविधा (उदाहरण के लिए, अपस्ट्रीम एओएसपी की जानकारी देने वाला आइकॉन), ताकि यह पता चल सके कि डिवाइस एडमिन ने किसी सेटिंग पर पाबंदी लगाई है.
    • डिवाइस एडमिन ने setShortSupportMessage के ज़रिए, कम शब्दों में जानकारी देने वाला मैसेज भेजा है.
    • डीपीसी ऐप्लिकेशन का आइकॉन.

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

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

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

3.10. सुलभता

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.12.1. टीवी ऐप्लिकेशन

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

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

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

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

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

3.12.1.1. इलेक्ट्रॉनिक प्रोग्राम गाइड

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

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

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

  • [C-1-1] Android TV डिवाइस के इनपुट डिवाइसों (जैसे कि रिमोट कंट्रोल, रिमोट कंट्रोल ऐप्लिकेशन या गेम कंट्रोलर) पर मौजूद डी-पैड, बैक, और होम बटन का इस्तेमाल करके, इन फ़ंक्शन को नेविगेट किया जा सकता हो:

    • टीवी चैनल बदलना
    • ईपीजी खोला जा रहा है
    • तीसरे पक्ष के टीआईएफ़ पर आधारित इनपुट को कॉन्फ़िगर और ट्यून करना (अगर वे इनपुट काम करते हैं)
    • सेटिंग मेन्यू खोलना

  • CEC के ज़रिए, मुख्य इवेंट को HDMI इनपुट पर पास करना चाहिए.

3.12.1.3. टीवी इनपुट ऐप्लिकेशन लिंकिंग

Android Television डिवाइसों पर टीवी इनपुट ऐप्लिकेशन लिंक करने की सुविधा काम करनी चाहिए.इससे सभी इनपुट, मौजूदा गतिविधि से दूसरी गतिविधि के लिए लिंक उपलब्ध करा सकते हैं. जैसे, लाइव प्रोग्रामिंग से मिलते-जुलते कॉन्टेंट का लिंक. अगर टीवी इनपुट ऐप्लिकेशन को लिंक करने की सुविधा उपलब्ध है, तो टीवी ऐप्लिकेशन को इसे दिखाना चाहिए.

3.12.1.4. टाइम शिफ्टिंग

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

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

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

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

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

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

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

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

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

  • [C-1-1] MediaItem आइकॉन और सूचना के आइकॉन में कोई बदलाव नहीं होना चाहिए.
  • [C-1-2] MUST display those items as described by MediaSession, e.g., metadata, icons, imagery.
  • [C-1-3] ऐप्लिकेशन का टाइटल दिखना ज़रूरी है.
  • [C-1-4] MediaBrowser हैरारकी दिखाने के लिए, इसमें ड्रॉअर होना ज़रूरी है.
  • [C-1-5] MediaSession.Callback#onMediaButtonEvent के लिए, KEYCODE_HEADSETHOOK या KEYCODE_MEDIA_PLAY_PAUSE को दो बार टैप करने को KEYCODE_MEDIA_NEXT के तौर पर माना जाना चाहिए.

3.15. Instant Apps

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

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

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

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

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

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

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

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

  • [C-0-1] आधिकारिक Android SDK में शामिल “aapt” टूल से जनरेट की गई Android “.apk” फ़ाइलों को इंस्टॉल और चलाने की सुविधा होनी चाहिए.
  • ऊपर दी गई ज़रूरी शर्त को पूरा करना मुश्किल हो सकता है. इसलिए, डिवाइसों को AOSP के रेफ़रंस पैकेज मैनेजमेंट सिस्टम का इस्तेमाल करने का सुझाव दिया जाता है.
  • [C-0-2] APK सिग्नेचर स्कीम v2 और JAR साइनिंग का इस्तेमाल करके, “.apk” फ़ाइलों की पुष्टि करने की सुविधा होनी चाहिए.
  • [C-0-3] .apk, Android मेनिफ़ेस्ट, Dalvik bytecode या RenderScript bytecode फ़ॉर्मैट को इस तरह से नहीं बढ़ाया जाना चाहिए कि वे फ़ाइलें, ज़रूरी शर्तें पूरी करने वाले अन्य डिवाइसों पर सही तरीके से इंस्टॉल और रन न हो पाएं.
  • [C-0-4] पैकेज के लिए, "रिकॉर्ड का इंस्टॉलर" के तौर पर सेट किए गए ऐप्लिकेशन के अलावा, किसी दूसरे ऐप्लिकेशन को बिना किसी प्रॉम्प्ट के ऐप्लिकेशन को साइलेंट तरीके से अनइंस्टॉल करने की अनुमति नहीं देनी चाहिए. इस बारे में, DELETE_PACKAGE अनुमति के लिए एसडीके में बताया गया है. सिर्फ़ दो ऐप्लिकेशन को इस नीति से छूट मिली है. पहला, सिस्टम पैकेज वेरिफ़ायर ऐप्लिकेशन, जो PACKAGE_NEEDS_VERIFICATION इंटेंट को हैंडल करता है. दूसरा, स्टोरेज मैनेजर ऐप्लिकेशन, जो ACTION_MANAGE_STORAGE इंटेंट को हैंडल करता है.

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

  • इसके लिए, REQUEST_INSTALL_PACKAGES अनुमति का एलान करना ज़रूरी है. इसके अलावा, android:targetSdkVersion को 24 या इससे कम पर सेट करना भी ज़रूरी है.
  • उपयोगकर्ता ने, अज्ञात स्रोतों से ऐप्लिकेशन इंस्टॉल करने की अनुमति दी हो.

डिवाइसों में, android.settings.MANAGE_UNKNOWN_APP_SOURCES इंटेंट को हैंडल करने वाली गतिविधि होनी चाहिए. उन्हें उपयोगकर्ता को हर ऐप्लिकेशन के लिए, अज्ञात सोर्स से ऐप्लिकेशन इंस्टॉल करने की अनुमति देने/रद्द करने का विकल्प देना चाहिए. हालांकि, अगर डिवाइस में इस विकल्प को लागू नहीं किया जाता है, तो वे इसे नो-ऑप के तौर पर लागू कर सकते हैं और startActivityForResult() के लिए RESULT_CANCELED दिखा सकते हैं. हालांकि, ऐसे मामलों में भी उन्हें उपयोगकर्ता को यह बताना चाहिए कि ऐसा विकल्प क्यों नहीं दिया गया है.

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

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

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

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

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

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

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

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

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

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

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

  • [C-1-1] पीसीएम/वेव

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

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

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

  • [C-1-1] MPEG-4 AAC प्रोफ़ाइल (AAC LC)
  • [C-1-2] MPEG-4 HE AAC प्रोफ़ाइल (AAC+)
  • [C-1-3] MPEG-4 HE AACv2 प्रोफ़ाइल (बेहतर AAC+)
  • [C-1-4] एएसी ईएलडी (बेहतर लो डिले एएसी)
  • [C-1-5] FLAC
  • [C-1-6] MP3
  • [C-1-7] एमआईडीआई
  • [C-1-8] Vorbis
  • [C-1-9] पीसीएम/वेव
  • [C-1-10] Opus

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

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

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

फ़ॉर्मैट/कोडेक जानकारी इस्तेमाल किए जा सकने वाले फ़ाइल टाइप/कंटेनर फ़ॉर्मैट
MPEG-4 AAC प्रोफ़ाइल
(AAC LC) 		मोनो/स्टीरियो/5.0/5.1 कॉन्टेंट के लिए, 8 से 48 किलोहर्ट्ज़ तक के स्टैंडर्ड सैंपलिंग रेट का इस्तेमाल किया जा सकता है.
  • 3GPP (.3gp)
  • MPEG-4 (.mp4, .m4a)
  • ADTS रॉ एएसी (.aac, ADIF फ़ॉर्मैट काम नहीं करता)
  • MPEG-TS (.ts, इसमें खोज नहीं की जा सकती)
MPEG-4 HE AAC प्रोफ़ाइल (AAC+) मोनो/स्टीरियो/5.0/5.1 कॉन्टेंट के साथ काम करता है. इसमें 16 से 48 किलोहर्ट्ज़ तक के स्टैंडर्ड सैंपलिंग रेट इस्तेमाल किए जाते हैं.
MPEG-4 HE AACv2
प्रोफ़ाइल (बेहतर AAC+) 		मोनो/स्टीरियो/5.0/5.1 कॉन्टेंट के साथ काम करता है. इसमें 16 से 48 किलोहर्ट्ज़ तक के स्टैंडर्ड सैंपलिंग रेट इस्तेमाल किए जाते हैं.
AAC ELD (बेहतर लो डिले AAC) मोनो/स्टीरियो कॉन्टेंट के लिए, 16 से 48 किलोहर्ट्ज़ तक के स्टैंडर्ड सैंपलिंग रेट का इस्तेमाल किया जा सकता है.
AMR-NB 8 किलोहर्ट्ज़ पर सैंपल किया गया 4.75 से 12.2 केबीपीएस 3GPP (.3gp)
AMR-WB 6.60 केबिट/सेकंड से 23.85 केबिट/सेकंड तक के नौ रेट, जिन्हें 16 किलोहर्ट्ज़ पर सैंपल किया गया है
FLAC मोनो/स्टीरियो (मल्टीचैनल नहीं). सैंपल रेट 48 किलोहर्ट्ज़ तक (हालांकि, 44.1 किलोहर्ट्ज़ आउटपुट वाले डिवाइसों पर 44.1 किलोहर्ट्ज़ का इस्तेमाल करने का सुझाव दिया जाता है, क्योंकि 48 से 44.1 किलोहर्ट्ज़ डाउनसैंपलर में लो-पास फ़िल्टर शामिल नहीं होता). 16-बिट का इस्तेमाल करने का सुझाव दिया जाता है. 24-बिट के लिए, डिथरिंग लागू नहीं की जाती. सिर्फ़ FLAC (.flac)
MP3 मोनो/स्टीरियो 8-320 केबीपीएस स्थिर (सीबीआर) या वैरिएबल बिटरेट (वीबीआर) MP3 (.mp3)
MIDI एमआईडीआई टाइप 0 और 1. DLS के वर्शन 1 और 2. XMF और Mobile XMF. रिंगटोन के फ़ॉर्मैट RTTTL/RTX, OTA, और iMelody के साथ काम करता है
  • टाइप 0 और 1 (.mid, .xmf, .mxmf)
  • RTTTL/RTX (.rtttl, .rtx)
  • ओटीए (.ota)
  • iMelody (.imy)
Vorbis
  • Ogg (.ogg)
  • Matroska (.mkv, Android 4.0+)
PCM/WAVE 16-बिट लीनियर पीसीएम (हार्डवेयर की सीमा तक की दरें). डिवाइसों पर, रॉ पीसीएम रिकॉर्डिंग के लिए सैंपलिंग रेट की सुविधा होनी चाहिए. यह सुविधा 8000, 11025, 16000, और 44100 हर्ट्ज़ फ़्रीक्वेंसी पर काम करनी चाहिए. WAVE (.wav)
Opus Matroska (.mkv), Ogg(.ogg)

5.1.4. इमेज एन्कोडिंग

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

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

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

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] रॉ

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)

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

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

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

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

  • [C-1-2] वीडियो एन्कोडर और डिकोडर में, YUV420 फ़्लेक्सिबल कलर फ़ॉर्मैट (COLOR_FormatYUV420Flexible) काम करना चाहिए.

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

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

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

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

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

फ़ॉर्मैट/कोडेक जानकारी इस्तेमाल किए जा सकने वाले फ़ाइल टाइप/
कंटेनर फ़ॉर्मैट
H.263
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
H.264 एवीसी ज़्यादा जानकारी के लिए, सेक्शन 5.2 और 5.3 देखें
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
  • MPEG-2 टीएस (.ts, सिर्फ़ AAC ऑडियो, इसमें खोज करने की सुविधा नहीं है, Android 3.0+)
H.265 HEVC ज़्यादा जानकारी के लिए, सेक्शन 5.3 देखें MPEG-4 (.mp4)
MPEG-2 मुख्य प्रोफ़ाइल MPEG2-TS
MPEG-4 SP 3GPP (.3gp)
VP8 ज़्यादा जानकारी के लिए, सेक्शन 5.2 और 5.3 देखें
VP9 ज़्यादा जानकारी के लिए, सेक्शन 5.3 देखें

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

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

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

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

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

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

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

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

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

5.2.1. H.263

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

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

5.2.2. H-264

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

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

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

  • [C-2-1] यहां दी गई टेबल में मौजूद एन्कोडिंग प्रोफ़ाइलों के साथ काम करना ज़रूरी है.
एसडी (खराब क्वालिटी) एसडी (अच्छी क्वालिटी) एचडी 720 पिक्सल एचडी 1080 पिक्सल
वीडियो रिज़ॉल्यूशन 320 x 240 पिक्सल 720 x 480 पिक्सल 1280 x 720 पिक्सल 1920 x 1080 पिक्सल
वीडियो फ़्रेम रेट 20 फ़्रेम प्रति सेकंड 30 फ़्रेम प्रति सेकंड 30 फ़्रेम प्रति सेकंड 30 फ़्रेम प्रति सेकंड
वीडियो बिटरेट 384 केबीपीएस 2 एमबीपीएस 4 एमबीपीएस 10 एमबीपीएस

5.2.3. VP8

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

  • [C-1-1] एसडी वीडियो एन्कोडिंग प्रोफ़ाइलों के साथ काम करना चाहिए.
  • इनमें एचडी (हाई डेफ़िनिशन) वीडियो एन्कोडिंग प्रोफ़ाइलें काम करनी चाहिए.
  • 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 कोडेक का इस्तेमाल किया जा सकता है, तो:

  • Matroska WebM फ़ाइलें लिखने की सुविधा होनी चाहिए.

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

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

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

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

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

5.3.1. MPEG-2

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

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

5.3.2. H.263

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

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

5.3.3. MPEG-4

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

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

5.3.4. H.264

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

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

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

  • [C-2-1] यहां दी गई टेबल में, एचडी 720 पिक्सल वीडियो एन्कोडिंग प्रोफ़ाइलों के साथ काम करना ज़रूरी है.
  • [C-2-2] यहां दी गई टेबल में, एचडी 1080 पिक्सल वीडियो एन्कोडिंग प्रोफ़ाइलों के साथ काम करना ज़रूरी है.
एसडी (खराब क्वालिटी) एसडी (अच्छी क्वालिटी) एचडी 720 पिक्सल एचडी 1080 पिक्सल
वीडियो रिज़ॉल्यूशन 320 x 240 पिक्सल 720 x 480 पिक्सल 1280 x 720 पिक्सल 1920 x 1080 पिक्सल
वीडियो फ़्रेम रेट 30 फ़्रेम प्रति सेकंड 30 फ़्रेम प्रति सेकंड 60 एफ़पीएस 30 फ़्रेम प्रति सेकंड (60 फ़्रेम प्रति सेकंडटेलीविज़न)
वीडियो बिटरेट 800 केबीपीएस 2 एमबीपीएस 8 एमबीपीएस 20 एमबीपीएस

5.3.5. H.265 (HEVC)

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

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

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

  • [C-2-1] डिवाइसों में, 720, 1080, और यूएचडी प्रोफ़ाइलों के लिए, H.265 या VP9 डिकोडिंग में से कम से कम एक को सपोर्ट करना ज़रूरी है.
एसडी (खराब क्वालिटी) एसडी (अच्छी क्वालिटी) एचडी 720 पिक्सल एचडी 1080 पिक्सल यूएचडी
वीडियो रिज़ॉल्यूशन 352 x 288 पिक्सल 720 x 480 पिक्सल 1280 x 720 पिक्सल 1920 x 1080 पिक्सल 3840 x 2160 पिक्सल
वीडियो फ़्रेम रेट 30 फ़्रेम प्रति सेकंड 30 फ़्रेम प्रति सेकंड 30 फ़्रेम प्रति सेकंड 30/60 एफ़पीएस (60 एफ़पीएसH.265 हार्डवेयर डिकोडिंग की सुविधा वाला टेलीविज़न) 60 एफ़पीएस
वीडियो बिटरेट 600 केबीपीएस 1.6 एमबीपीएस 4 एमबीपीएस 5 एमबीपीएस 20 एमबीपीएस

5.3.6. VP8

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

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

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

  • [C-2-1] डिवाइसों में, यहां दी गई टेबल में बताई गई 720p प्रोफ़ाइलें काम करनी चाहिए.
  • [C-2-2] डिवाइसों में, यहां दी गई टेबल में बताई गई 1080 पिक्सल की प्रोफ़ाइलें काम करनी चाहिए.
एसडी (खराब क्वालिटी) एसडी (अच्छी क्वालिटी) एचडी 720 पिक्सल एचडी 1080 पिक्सल
वीडियो रिज़ॉल्यूशन 320 x 180 पिक्सल 640 x 360 पिक्सल 1280 x 720 पिक्सल 1920 x 1080 पिक्सल
वीडियो फ़्रेम रेट 30 फ़्रेम प्रति सेकंड 30 फ़्रेम प्रति सेकंड 30 फ़्रेम प्रति सेकंड (60 फ़्रेम प्रति सेकंडटेलीविज़न) 30 (60 फ़्रेम प्रति सेकंडटेलीविज़न)
वीडियो बिटरेट 800 केबीपीएस 2 एमबीपीएस 8 एमबीपीएस 20 एमबीपीएस

5.3.7. VP9

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

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

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

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

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

  • [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 एमबीपीएस

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

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

5.4.1. Raw Audio Capture

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

  • [C-1-1] में, रॉ ऑडियो कॉन्टेंट को कैप्चर करने की अनुमति होनी चाहिए. इसमें ये विशेषताएं होनी चाहिए:

  • फ़ॉर्मैट: लीनियर पीसीएम, 16-बिट

  • सैंपल रेट: 8000, 11025, 16000, 44100 हर्ट्ज़

  • चैनल: मोनो

  • [C-1-2] ज़रूरी है कि वह अप-सैंपलिंग के बिना, ऊपर दिए गए सैंपल रेट पर कैप्चर करे.

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

  • इसमें एएम रेडियो और डीवीडी क्वालिटी में रॉ ऑडियो कॉन्टेंट कैप्चर करने की सुविधा होनी चाहिए. इसका मतलब है कि इसमें ये सुविधाएं होनी चाहिए:

  • फ़ॉर्मैट: लीनियर पीसीएम, 16-बिट

  • सैंपलिंग रेट: 22050, 48000 हर्ट्ज़
  • चैनल: स्टीरियो

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

  • [C-2-1] किसी भी अनुपात में 16000:22050 या 44100:48000 से ज़्यादा अप-सैंपलिंग किए बिना कैप्चर करना ज़रूरी है.
  • [C-2-2] अप-सैंपलिंग या डाउन-सैंपलिंग के लिए, एंटी-एलियासिंग फ़िल्टर शामिल करना ज़रूरी है.

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

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

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

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

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

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

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

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

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

    • AudioManager.STREAM_RING
    • AudioManager.STREAM_ALARM
    • AudioManager.STREAM_NOTIFICATION

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

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

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

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

  • [C-1-1] डिवाइस में, रॉ ऑडियो कॉन्टेंट को चलाने की सुविधा होनी चाहिए. इसमें ये विशेषताएं होनी चाहिए:

    • फ़ॉर्मैट: लीनियर पीसीएम, 16-बिट
    • सैंपलिंग की दरें: 8000, 11025, 16000, 22050, 32000, 44100
    • चैनल: मोनो, स्टीरियो

  • इसमें, रॉ ऑडियो कॉन्टेंट को चलाने की सुविधा होनी चाहिए. साथ ही, इसमें ये विशेषताएं होनी चाहिए:

    • सैंपलिंग रेट: 24000, 48000

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

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

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

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

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

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

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

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

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

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

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

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

  • [एसआर] कोल्ड आउटपुट की लेटेन्सी 100 मिलीसेकंड या इससे कम हो
  • [एसआर] लगातार आउटपुट मिलने में 45 मिलीसेकंड या उससे कम समय लगता हो
  • [SR] Minimize the cold output jitter

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

  • [SR] android.hardware.audio.low_latency फ़ीचर फ़्लैग के बारे में एलान करके, कम समय में ऑडियो ट्रांसफ़र होने की सुविधा के बारे में जानकारी देने का सुझाव दिया जाता है.
  • [SR] AAudio API के ज़रिए, कम समय में ऑडियो ट्रांसफ़र करने की सुविधा से जुड़ी ज़रूरी शर्तों को पूरा करने का सुझाव दिया जाता है.

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

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

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

  • [एसआर] कोल्ड इनपुट लेटेन्सी 100 मिलीसेकंड या इससे कम हो
  • [एसआर] लगातार इनपुट लेटेन्सी 30 मिलीसेकंड या इससे कम हो
  • [एसआर] लगातार राउंड-ट्रिप में लगने वाला समय 50 मिलीसेकंड या इससे कम हो
  • [SR] Minimize the cold input jitter

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

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

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

  • [C-1-1] एचटीटीपी(एस) पर, सेक्शन 5.1 में बताए गए सभी ज़रूरी कोडेक और कंटेनर फ़ॉर्मैट काम करने चाहिए.

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

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

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

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

ऑडियो कोडेक:

  • AAC
AAC और इसके वैरिएंट के बारे में ज़्यादा जानने के लिए, सेक्शन 5.1.1 देखें.
ADTS फ़्रेमिंग और ID3 टैग के साथ AAC ISO 13818-7 एएसी और इसके वैरिएंट के बारे में जानकारी के लिए, सेक्शन 5.1.1 देखें
WebVTT WebVTT

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

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

5.8. Secure Media

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

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

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

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

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

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

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

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

  • [C-1-1] MIDI-capable हार्डवेयर ट्रांसपोर्ट के सभी वर्शन पर MIDI काम करना चाहिए. इसके लिए, वे MIDI के अलावा अन्य कनेक्टिविटी की सुविधा देते हैं. ये ट्रांसपोर्ट इस तरह के होते हैं:

    • यूएसबी होस्ट मोड, section 7.7
    • यूएसबी पेरिफ़ेरल मोड, section 7.7
    • ब्लूटूथ LE पर एमआईडीआई, सेंट्रल डिवाइस के तौर पर काम कर रहा है, सेक्शन 7.4.3

  • [C-1-2] इसमें इंटर-ऐप्लिकेशन एमआईडीआई सॉफ़्टवेयर ट्रांसपोर्ट (वर्चुअल एमआईडीआई डिवाइस) की सुविधा होनी चाहिए

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

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

  • [C-1-1] android.hardware.audio.low_latency सुविधा के साथ काम करने की जानकारी देना ज़रूरी है.
  • [C-1-2] सेक्शन 5.6 ऑडियो लेटेंसी में बताई गई, लगातार राउंड-ट्रिप ऑडियो लेटेंसी 20 मिलीसेकंड या इससे कम होनी चाहिए. साथ ही, यह कम से कम एक ऐसे पाथ पर 10 मिलीसेकंड या इससे कम होनी चाहिए जिस पर यह सुविधा काम करती है.
  • [C-1-3] में यूएसबी पोर्ट शामिल होने चाहिए, जो यूएसबी होस्ट मोड और यूएसबी पेरीफ़ेरल मोड के साथ काम करते हों.
  • [C-1-4] android.software.midi सुविधा के साथ काम करने की जानकारी देना ज़रूरी है.
  • [C-1-5] OpenSL ES पीसीएम बफ़र क्यू एपीआई का इस्तेमाल करके, लेटेंसी और यूएसबी ऑडियो से जुड़ी ज़रूरी शर्तों को पूरा करना होगा.
  • [SR] ऑडियो चालू होने और सीपीयू लोड में बदलाव होने पर, सीपीयू की परफ़ॉर्मेंस का एक जैसा लेवल बनाए रखने का सुझाव दिया जाता है. इसकी जांच, SimpleSynth कमिट 1bd6391 का इस्तेमाल करके की जानी चाहिए. SimpleSynth ऐप्लिकेशन को नीचे दिए गए पैरामीटर के साथ चलाना होगा. साथ ही, 10 मिनट के बाद इसमें कोई भी अंडररन नहीं होना चाहिए:
    • काम के घंटे: 2,00,000
    • वैरिएबल लोड: चालू है. इससे हर दो सेकंड में, वर्क साइकल की वैल्यू 100% और 10% के बीच स्विच होगी. इसे सीपीयू गवर्नर के व्यवहार की जांच करने के लिए डिज़ाइन किया गया है
    • स्टेबलाइज़ किया गया लोड: बंद है
  • ऑडियो क्लॉक में होने वाली गड़बड़ी और स्टैंडर्ड टाइम के हिसाब से उसमें होने वाले बदलाव को कम करना चाहिए.
  • जब दोनों चालू हों, तो सीपीयू CLOCK_MONOTONIC के मुकाबले ऑडियो क्लॉक ड्रिफ्ट को कम करना चाहिए.
  • डिवाइस पर मौजूद ट्रांसड्यूसर के ज़रिए ऑडियो ट्रांसफ़र करने में कम से कम समय लगना चाहिए.
  • यूएसबी डिजिटल ऑडियो पर ऑडियो लेटेंसी को कम करना चाहिए.
  • सभी पाथ पर ऑडियो लेटेंसी मेज़रमेंट की जानकारी देने वाला दस्तावेज़ होना चाहिए.
  • ऑडियो बफ़र पूरा होने पर कॉलबैक एंट्री के समय में जिटर को कम करना चाहिए. इससे कॉलबैक के ज़रिए इस्तेमाल किए जा सकने वाले सीपीयू बैंडविथ के प्रतिशत पर असर पड़ता है.
  • सामान्य इस्तेमाल के दौरान, रिपोर्ट की गई लेटेन्सी पर, ऑडियो अंडररन (आउटपुट) या ओवररन (इनपुट) नहीं होना चाहिए.
  • SHOULD provide zero inter-channel latency difference.
  • सभी ट्रांसपोर्ट पर एमआईडीआई की औसत लेटेन्सी को कम करना चाहिए.
  • सभी ट्रांसपोर्ट पर, लोड (जिटर) के दौरान एमआईडीआई के रिस्पॉन्स में लगने वाले समय में होने वाले बदलाव को कम से कम करना चाहिए.
  • सभी ट्रांसपोर्ट पर, एमआईडीआई के सटीक टाइमस्टैंप देने चाहिए.
  • डिवाइस पर मौजूद ट्रांसड्यूसर से आने वाले ऑडियो सिग्नल में, कम से कम नॉइज़ होनी चाहिए. इसमें कोल्ड स्टार्ट के तुरंत बाद की अवधि भी शामिल है.
  • जब दोनों एंड-पॉइंट चालू हों, तब इनपुट और आउटपुट के बीच ऑडियो क्लॉक का अंतर शून्य होना चाहिए. इससे जुड़े एंड-पॉइंट के उदाहरणों में, डिवाइस पर मौजूद माइक्रोफ़ोन और स्पीकर या ऑडियो जैक इनपुट और आउटपुट शामिल हैं.
  • जब इनपुट और आउटपुट, दोनों चालू हों, तब इसे एक ही थ्रेड पर, संबंधित एंड-पॉइंट के इनपुट और आउटपुट, दोनों के लिए ऑडियो बफ़र पूरा होने के कॉलबैक को हैंडल करना चाहिए. साथ ही, इनपुट कॉलबैक से वापस आने के तुरंत बाद, आउटपुट कॉलबैक में शामिल होना चाहिए. अगर एक ही थ्रेड पर कॉल बैक को मैनेज करना मुमकिन नहीं है, तो इनपुट कॉल बैक डालने के कुछ समय बाद आउटपुट कॉल बैक डालें. इससे ऐप्लिकेशन को इनपुट और आउटपुट, दोनों के लिए एक जैसा समय तय करने की अनुमति मिलती है.
  • इनपुट और आउटपुट के लिए, HAL ऑडियो बफ़रिंग के बीच फ़ेज़ के अंतर को कम से कम करना चाहिए.
  • स्क्रीन को छूने पर होने वाली देरी को कम करना चाहिए.
  • लोड होने के दौरान, टच के इंतज़ार के समय में होने वाले बदलाव (जिटर) को कम से कम करना चाहिए.

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

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

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

  • [SR] यह सुझाव दिया जाता है कि AAudio API के ज़रिए भी इन्हीं ज़रूरी शर्तों को पूरा किया जाए.

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

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

  • [C-3-1] यूएसबी ऑडियो क्लास को लागू करना ज़रूरी है.
  • [C-3-2] यूएसबी ऑडियो क्लास का इस्तेमाल करके, यूएसबी होस्ट मोड पोर्ट पर ऑडियो की राउंड-ट्रिप लेटेंसी लगातार 20 मिलीसेकंड या इससे कम होनी चाहिए.
  • यूएसबी ऑडियो क्लास का इस्तेमाल करके, यूएसबी होस्ट मोड पोर्ट पर ऑडियो की राउंड-ट्रिप लेटेंसी लगातार 10 मिलीसेकंड या उससे कम होनी चाहिए.

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

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

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

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

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

  • [C-1-1] android.media.AudioManager प्रॉपर्टी PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED के ज़रिए, इस सुविधा के साथ काम करने की जानकारी देना ज़रूरी है.

  • [C-1-2] मिड-फ़्रीक्वेंसी रेंज में, ऐम्प्लिट्यूड-वर्सेस-फ़्रीक्वेंसी की विशेषताएं लगभग एक जैसी होनी चाहिए: खास तौर पर, बिना प्रोसेस किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन के लिए, 100 हर्ट्ज़ से 7,000 हर्ट्ज़ तक ±10dB.

  • [C-1-3] लो फ़्रीक्वेंसी रेंज में ऐम्प्लिट्यूड लेवल दिखाना ज़रूरी है: खास तौर पर, 5 हर्ट्ज़ से 100 हर्ट्ज़ तक ±20 डीबी, बिना प्रोसेस किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन के लिए, मिड-फ़्रीक्वेंसी रेंज की तुलना में.

  • [C-1-4] इसमें ज़्यादा फ़्रीक्वेंसी रेंज में ऐम्प्लिट्यूड लेवल दिखना चाहिए: खास तौर पर, 7,000 हर्ट्ज़ से 22 किलोहर्ट्ज़ तक, ±30 डीबी की रेंज में. इसकी तुलना, बिना प्रोसेस किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन की मिड-फ़्रीक्वेंसी रेंज से की जाती है.

  • [C-1-5] ऑडियो इनपुट की सेंसिटिविटी को इस तरह से सेट किया जाना चाहिए कि 94 dB साउंड प्रेशर लेवल (एसपीएल) पर चलाए गए 1000 हर्ट्ज़ के साइनसोडल टोन सोर्स से, 16 बिट-सैंपल के लिए 520 का आरएमएस (या फ़्लोटिंग पॉइंट/डबल प्रिसिशन सैंपल के लिए -36 dB फ़ुल स्केल) वाला रिस्पॉन्स मिले. ऐसा हर उस माइक्रोफ़ोन के लिए होना चाहिए जिसका इस्तेमाल बिना प्रोसेस किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए किया जाता है.

  • [C-1-6] बिना प्रोसेस किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन के लिए, सिग्नल-टू-नॉइज़ रेशियो (एसएनआर) 60 डीबी या इससे ज़्यादा होना चाहिए. (जबकि एसएनआर को 94 dB एसपीएल और सेल्फ़ नॉइज़ के बराबर एसपीएल के बीच के अंतर के तौर पर मापा जाता है, जिसे A-वेटेड किया जाता है).

  • [C-1-7] बिना प्रोसेस किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन के लिए, 90 dB एसपीएल इनपुट लेवल पर 1 kHZ के लिए, टोटल हार्मोनिक डिस्टॉर्शन (टीएचडी) 1% से कम होना चाहिए.

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

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

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

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

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

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

6.1. डेवलपर टूल

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

  • [C-0-1] Android SDK में दिए गए Android डेवलपर टूल के साथ काम करना ज़रूरी है.

  • Android Debug Bridge (adb)

    • [C-0-2] यह ज़रूरी है कि डिवाइस, Android SDK में बताए गए सभी adb फ़ंक्शन के साथ काम करता हो. इनमें dumpsys भी शामिल है.
    • [C-0-3] dumpsys के ज़रिए लॉग किए गए डिवाइस सिस्टम इवेंट (batterystats , diskstats, fingerprint, graphicsstats, netstats, notification, procstats) के फ़ॉर्मैट या कॉन्टेंट में बदलाव नहीं किया जाना चाहिए.
    • [C-0-4] डिवाइस पर adb डेमॉन डिफ़ॉल्ट रूप से बंद होना चाहिए. साथ ही, Android Debug Bridge को चालू करने के लिए, उपयोगकर्ता के पास ऐक्सेस होना चाहिए.
    • [C-0-5] सुरक्षित ए़डीबी के साथ काम करना ज़रूरी है. Android में, सुरक्षित adb की सुविधा काम करती है. Secure adb की मदद से, पुष्टि किए गए होस्ट पर adb की सुविधा चालू की जा सकती है.

    • [C-0-6] ऐसा तरीका उपलब्ध कराना ज़रूरी है जिससे होस्ट मशीन से adb को कनेक्ट किया जा सके. उदाहरण के लिए:

      • जिन डिवाइसों में यूएसबी पोर्ट नहीं होता है और जो पेरिफ़रल मोड के साथ काम नहीं करते हैं उनमें स्थानीय नेटवर्क (जैसे, इथरनेट या वाई-फ़ाई) के ज़रिए adb को लागू करना ज़रूरी है.
      • Windows 7, 9, और 10 के लिए ड्राइवर उपलब्ध कराने होंगे. इससे डेवलपर, adb प्रोटोकॉल का इस्तेमाल करके डिवाइस से कनेक्ट कर पाएंगे.

  • Dalvik Debug Monitor Service (ddms)

    • [C-0-7] यह ज़रूरी है कि डिवाइस, Android SDK में बताई गई सभी ddms सुविधाओं के साथ काम करे. डीडीएमएस, एडीबी का इस्तेमाल करता है. इसलिए, डीडीएमएस की सुविधा डिफ़ॉल्ट रूप से बंद होनी चाहिए. हालांकि, जब उपयोगकर्ता ऊपर बताए गए तरीके से Android Debug Bridge को चालू करता है, तब डीडीएमएस की सुविधा चालू होनी चाहिए.
  • Monkey
    • [C-0-8] इसमें Monkey फ़्रेमवर्क शामिल होना चाहिए. साथ ही, इसे ऐप्लिकेशन के इस्तेमाल के लिए उपलब्ध कराना ज़रूरी है.
  • SysTrace
    • [C-0-9] यह ज़रूरी है कि डिवाइस, Android SDK में दिए गए दस्तावेज़ के मुताबिक, systrace टूल के साथ काम करे. Systrace डिफ़ॉल्ट रूप से बंद होना चाहिए. साथ ही, Systrace को चालू करने के लिए, उपयोगकर्ता के लिए उपलब्ध एक तरीका होना चाहिए.

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

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

डिवाइस में डेवलपर विकल्पों के लिए, एक जैसा अनुभव होना चाहिए. इसके लिए:

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

7. हार्डवेयर के साथ काम करने की सुविधा

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

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

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

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

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

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

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

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

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

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

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

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

  • [C-0-1] डिवाइस में सेट किए गए सिस्टम के लिए, Android SDK के दस्तावेज़ में बताए गए तरीके से Configuration.screenLayout के लिए लेआउट का सही साइज़ रिपोर्ट करना ज़रूरी है. खास तौर पर, डिवाइसों पर लागू किए गए लॉजिकल डेंसिटी-इंडिपेंडेंट पिक्सल (डीपी) के स्क्रीन डाइमेंशन की सही जानकारी देनी होगी. जैसे:

    • ऐसे डिवाइस जिनमें Configuration.uiMode की वैल्यू UI_MODE_TYPE_WATCH के अलावा कोई और वैल्यू सेट की गई है और जो Configuration.screenLayout के लिए small साइज़ की जानकारी देते हैं उनमें कम से कम 426 dp x 320 dp होना चाहिए.
    • Configuration.screenLayout के लिए normal साइज़ की जानकारी देने वाले डिवाइसों में, कम से कम 480 डीपी x 320 डीपी होना चाहिए.
    • Configuration.screenLayout के लिए large साइज़ की जानकारी देने वाले डिवाइसों में, कम से कम 640 dp x 480 dp होना ज़रूरी है.
    • Configuration.screenLayout के लिए xlarge साइज़ की जानकारी देने वाले डिवाइसों में, कम से कम 960 डीपी x 720 डीपी होना चाहिए.

  • [C-0-2] Android SDK के दस्तावेज़ में बताए गए तरीके के मुताबिक, डिवाइसों में सेट किए गए सिस्टम के लिए यह ज़रूरी है कि वे AndroidManifest.xml में <supports-screens> एट्रिब्यूट के ज़रिए, ऐप्लिकेशन के लिए स्क्रीन साइज़ के बारे में बताई गई जानकारी का सही तरीके से पालन करें.

7.1.1.2. स्क्रीन का आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात)

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

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

    • ऐप्लिकेशन ने android.max_aspect मेटाडेटा वैल्यू के ज़रिए यह एलान किया है कि यह बड़ी स्क्रीन के आसपेक्ट रेशियो के साथ काम करता है.
    • ऐप्लिकेशन, android:resizeableActivity एट्रिब्यूट के ज़रिए यह एलान करता है कि उसका साइज़ बदला जा सकता है.
    • ऐप्लिकेशन, एपीआई लेवल 26 या उसके बाद के लेवल को टारगेट कर रहा हो. साथ ही, इसमें ऐसा android:MaxAspectRatio शामिल न हो जो अनुमति वाले आसपेक्ट रेशियो को सीमित करता हो.

  • [C-0-2] Configuration.uiMode को UI_MODE_TYPE_WATCH के तौर पर सेट करने वाले डिवाइसों में, आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) की वैल्यू 1.0 (1:1) के तौर पर सेट होनी चाहिए.

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

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

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

    • 120 डीपीआई (ldpi)
    • 160 डीपीआई (एमडीपीआई)
    • 213 डीपीआई (टीवीडीपीआई)
    • 240 डीपीआई (hdpi)
    • 260 डीपीआई (260dpi)
    • 280 डीपीआई (280dpi)
    • 300 डीपीआई (300dpi)
    • 320 dpi (xhdpi)
    • 340 डीपीआई (340dpi)
    • 360 डीपीआई (360dpi)
    • 400 डीपीआई (400dpi)
    • 420 डीपीआई (420dpi)
    • 480 dpi (xxhdpi)
    • 560 dpi (560dpi)
    • 640 dpi (xxxhdpi)

  • डिवाइसों को Android फ़्रेमवर्क की स्टैंडर्ड डेंसिटी तय करनी चाहिए. यह डेंसिटी, स्क्रीन की फ़िज़िकल डेंसिटी के सबसे करीब होनी चाहिए. हालांकि, ऐसा तब तक किया जाना चाहिए, जब तक कि लॉजिकल डेंसिटी की वजह से स्क्रीन का साइज़, कम से कम साइज़ से कम न हो जाए. अगर फ़िज़िकल डेंसिटी के सबसे करीब वाली स्टैंडर्ड Android फ़्रेमवर्क डेंसिटी से, स्क्रीन का साइज़, साथ काम करने वाली सबसे छोटी स्क्रीन के साइज़ (320 डीपी चौड़ाई) से छोटा होता है, तो डिवाइसों को स्टैंडर्ड Android फ़्रेमवर्क डेंसिटी की अगली सबसे कम वैल्यू रिपोर्ट करनी चाहिए.

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

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

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

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

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

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

  • [C-2-1] android.util.DisplayMetrics API में तय की गई सभी डिसप्ले मेट्रिक के लिए, इम्यूलेट किए गए डिफ़ॉल्ट 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] ऐप्लिकेशन को पोर्ट्रेट या लैंडस्केप स्क्रीन ओरिएंटेशन के हिसाब से डाइनैमिक ओरिएंटेशन की सुविधा देनी होगी. इसका मतलब है कि डिवाइस को, स्क्रीन के ओरिएंटेशन के लिए ऐप्लिकेशन के अनुरोध का पालन करना होगा.
  • [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.0 और 2.0, दोनों को सपोर्ट करना ज़रूरी है.
  • [SR] OpenGL ES 3.0 सपोर्ट करने का सुझाव दिया जाता है.
  • OpenGL ES 3.1 या 3.2 के साथ काम करना चाहिए.

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

  • [C-2-1] यह ज़रूरी है कि वे OpenGL ES के मैनेज किए गए एपीआई और नेटिव एपीआई के ज़रिए, लागू किए गए किसी भी अन्य OpenGL ES एक्सटेंशन की रिपोर्ट करें. इसके उलट, यह ज़रूरी है कि वे उन एक्सटेंशन स्ट्रिंग की रिपोर्ट न करें जिनके साथ वे काम नहीं करते.
  • [C-2-2] EGL_KHR_image, EGL_KHR_image_base, EGL_ANDROID_image_native_buffer, EGL_ANDROID_get_native_client_buffer, EGL_KHR_wait_sync, EGL_KHR_get_all_proc_addresses, EGL_ANDROID_presentation_time, EGL_KHR_swap_buffers_with_damage, और EGL_ANDROID_recordable एक्सटेंशन के साथ काम करना ज़रूरी है.
  • [SR] EGL_KHR_partial_update का इस्तेमाल करने का सुझाव दिया जाता है.
  • उन्हें getString() तरीके का इस्तेमाल करके, टेक्सचर कंप्रेस करने के हर उस फ़ॉर्मैट की सटीक जानकारी देनी चाहिए जिसका इस्तेमाल किया जा सकता है. आम तौर पर, यह जानकारी वेंडर के हिसाब से अलग-अलग होती है.

अगर डिवाइस में OpenGL ES 3.0, 3.1 या 3.2 के साथ काम करने की सुविधा उपलब्ध है, तो:

  • [C-3-1] libGLESv2.so लाइब्रेरी में OpenGL ES 2.0 के फ़ंक्शन सिंबल के साथ-साथ, इन वर्शन के लिए भी फ़ंक्शन सिंबल एक्सपोर्ट करने होंगे.

अगर डिवाइस में 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.0 या 3.1 काम करता है, तो:

  • [SR] Vulkan 1.0 के साथ काम करने की सुविधा शामिल करने का सुझाव दिया जाता है .

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

  • Vulkan 1.0 के साथ काम करना चाहिए.

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

  • [C-1-1] android.hardware.vulkan.level और android.hardware.vulkan.version फ़ीचर फ़्लैग के साथ सही पूर्णांक वैल्यू की जानकारी देना ज़रूरी है.
  • [C-1-2] Vulkan नेटिव एपीआई vkEnumeratePhysicalDevices() के लिए, कम से कम एक VkPhysicalDevice की गिनती करना ज़रूरी है .
  • [C-1-3] हर VkPhysicalDevice के लिए, Vulkan 1.0 एपीआई को पूरी तरह से लागू करना ज़रूरी है.
  • [C-1-4] MUST enumerate layers, contained in native libraries named as libVkLayer*.so in the application package’s native library directory, through the Vulkan native APIs vkEnumerateInstanceLayerProperties() and vkEnumerateDeviceLayerProperties() .
  • [C-1-5] ऐप्लिकेशन पैकेज के बाहर की लाइब्रेरी से मिली लेयर की गिनती नहीं करनी चाहिए. इसके अलावा, Vulkan API को ट्रेस करने या इंटरसेप्ट करने के अन्य तरीके भी उपलब्ध नहीं कराने चाहिए. ऐसा तब तक नहीं करना चाहिए, जब तक ऐप्लिकेशन में android:debuggable एट्रिब्यूट को true के तौर पर सेट न किया गया हो.
  • [C-1-6] Vulkan नेटिव एपीआई के ज़रिए, उन सभी एक्सटेंशन स्ट्रिंग की जानकारी देना ज़रूरी है जिनके साथ काम किया जा सकता है. इसके उलट, उन एक्सटेंशन स्ट्रिंग की जानकारी नहीं देनी चाहिए जिनके साथ काम नहीं किया जा सकता.

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

  • [C-2-1] यह ज़रूरी है कि Vulkan के किसी भी फ़ीचर फ़्लैग (जैसे, android.hardware.vulkan.level, android.hardware.vulkan.version) का एलान न किया गया हो.
  • [C-2-2] Vulkan नेटिव एपीआई vkEnumeratePhysicalDevices() के लिए, किसी भी VkPhysicalDevice को शामिल नहीं किया जाना चाहिए.
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 वाइड-गैमट डिसप्ले

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

  • [C-1-1] में कलर-कैलिब्रेटेड डिसप्ले होना ज़रूरी है.
  • [C-1-2] डिवाइस में ऐसा डिसप्ले होना चाहिए जिसका गैमट, CIE 1931 xyY स्पेस में sRGB कलर गैमट को पूरी तरह से कवर करता हो.
  • [C-1-3] इसमें ऐसा डिसप्ले होना चाहिए जिसका गैमट, CIE 1931 xyY स्पेस में NTSC 1953 के कम से कम 90% हिस्से को कवर करता हो.
  • [C-1-4] OpenGL ES 3.0, 3.1 या 3.2 को सपोर्ट करना चाहिए और इसकी जानकारी सही तरीके से देनी चाहिए.
  • [C-1-5] यह ज़रूरी है कि डिवाइस, EGL_KHR_no_config_context, EGL_EXT_pixel_format_float, EGL_KHR_gl_colorspace, EGL_EXT_colorspace_scrgb_linear, और EGL_GL_colorspace_display_p3 एक्सटेंशन के साथ काम करने की जानकारी दे.
  • [SR] GL_EXT_sRGB का इस्तेमाल करने का सुझाव दिया जाता है.

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

  • [C-2-1] CIE 1931 xyY स्पेस में, sRGB का 100% या इससे ज़्यादा हिस्सा कवर होना चाहिए. हालांकि, स्क्रीन कलर गैमट तय नहीं किया गया है.

7.1.5. लेगसी ऐप्लिकेशन कंपैटबिलिटी मोड

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

7.1.6. स्क्रीन टेक्नोलॉजी

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

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

  • [C-0-1] डिसप्ले में, 16-बिट कलर ग्राफ़िक रेंडर करने की सुविधा होनी चाहिए.
  • इसमें 24-बिट कलर ग्राफ़िक्स दिखाने वाले डिसप्ले काम करने चाहिए.
  • [C-0-2] ऐसे डिसप्ले के साथ काम करना ज़रूरी है जो ऐनिमेशन रेंडर कर सकते हों.
  • [C-0-3] ऐसी डिसप्ले टेक्नोलॉजी का इस्तेमाल करना ज़रूरी है जिसका पिक्सल आसपेक्ट रेशियो (पीएआर) 0.9 और 1.15 के बीच हो. इसका मतलब है कि पिक्सल का आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) स्क्वेयर (1.0) के आस-पास होना चाहिए. इसमें 10 से 15% तक का अंतर हो सकता है.

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

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

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

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

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

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

7.2.1. कीबोर्ड

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

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

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

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

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

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

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

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

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

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

  • [C-0-1] टीवी डिवाइसों पर लागू होने वाले ऐप्लिकेशन के लिए, यह ज़रूरी है कि इंस्टॉल किए गए ऐसे ऐप्लिकेशन को लॉन्च करने की सुविधा दी जाए जिनमें <intent-filter> को ACTION=MAIN और CATEGORY=LAUNCHER या CATEGORY=LEANBACK_LAUNCHER के साथ सेट किया गया हो. इस सुविधा को चालू करने के लिए, होम फ़ंक्शन का इस्तेमाल किया जाना चाहिए.
  • इसमें हाल ही में इस्तेमाल किए गए आइटम और वापस जाने के लिए बटन होने चाहिए.

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

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

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

  • [SR] हमारा सुझाव है कि मेन्यू फ़ंक्शन के लिए इनपुट मैकेनिज़्म उपलब्ध न कराएं, क्योंकि Android 4.0 से इसे ऐक्शन बार के लिए बंद कर दिया गया है.

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [C-1-1] Configuration.touchscreen एपीआई फ़ील्ड के लिए, TOUCHSCREEN_FINGER की जानकारी देना ज़रूरी है.
  • [C-1-2] android.hardware.touchscreen और android.hardware.faketouch फ़ीचर फ़्लैग की जानकारी देना ज़रूरी है

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

  • [C-2-1] डिवाइस पर मौजूद टचस्क्रीन के टाइप के हिसाब से, सही फ़ीचर फ़्लैग android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct, android.hardware.touchscreen.multitouch.jazzhand रिपोर्ट करना ज़रूरी है.

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

  • [C-3-1] android.hardware.touchscreen से शुरू होने वाले किसी भी फ़ीचर फ़्लैग की जानकारी नहीं देनी चाहिए. साथ ही, सिर्फ़ android.hardware.faketouch की जानकारी देनी चाहिए.

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] इसमें पॉइंटर को नीचे की ओर ले जाने की सुविधा होनी चाहिए. साथ ही, उपयोगकर्ताओं को ऑब्जेक्ट को स्क्रीन पर किसी दूसरी जगह पर ले जाने और फिर पॉइंटर को ऊपर की ओर ले जाने की सुविधा मिलनी चाहिए. इससे उपयोगकर्ता, ऑब्जेक्ट को स्क्रीन पर फ़्लिंग कर पाएंगे.
  • [C-1-7] Configuration.touchscreen एपीआई फ़ील्ड के लिए, TOUCHSCREEN_NOTOUCH की जानकारी देनी होगी.

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

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

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

  • [C-3-1] android.hardware.faketouch के साथ काम करने की जानकारी देना ज़रूरी है.
  • [C-3-2] इसमें पांच (उंगलियों के हाथ को ट्रैक करना) या इससे ज़्यादा पॉइंटर इनपुट को पूरी तरह से अलग-अलग ट्रैक करने की सुविधा होनी चाहिए.

7.2.6. गेम कंट्रोलर की सुविधा

7.2.6.1. बटन मैपिंग

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

  • [C-1-1] MUST have embed a controller or ship with a separate controller in the box, that would provide means to input all the events listed in the below tables.
  • [C-1-2] HID इवेंट को, उससे जुड़े Android view.InputEvent कॉन्स्टेंट पर मैप करने की सुविधा होनी चाहिए. ये कॉन्स्टेंट, नीचे दी गई टेबल में दिए गए हैं. Android के अपस्ट्रीम वर्शन में, गेम कंट्रोलर के लिए इस सुविधा को लागू किया गया है.
बटन एचआईडी डिवाइस का इस्तेमाल2 Android बटन
A1 0x09 0x0001 KEYCODE_BUTTON_A (96)
B1 0x09 0x0002 KEYCODE_BUTTON_B (97)
X1 0x09 0x0004 KEYCODE_BUTTON_X (99)
Y1 0x09 0x0005 KEYCODE_BUTTON_Y (100)
डी-पैड ऊपर की ओर1
डी-पैड नीचे की ओर1 		0x01 0x00393 AXIS_HAT_Y4
डी-पैड बाईं ओर1
डी-पैड दाईं ओर1 		0x01 0x00393 AXIS_HAT_X4
लेफ़्ट शोल्डर बटन1 0x09 0x0007 KEYCODE_BUTTON_L1 (102)
राइट शोल्डर बटन1 0x09 0x0008 KEYCODE_BUTTON_R1 (103)
लेफ़्ट स्टिक क्लिक करें1 0x09 0x000E KEYCODE_BUTTON_THUMBL (106)
राइट स्टिक क्लिक करें1 0x09 0x000F KEYCODE_BUTTON_THUMBR (107)
Home1 0x0c 0x0223 KEYCODE_HOME (3)
वापस जाएं1 0x0c 0x0224 KEYCODE_BACK (4)

1 KeyEvent

2 ऊपर दिए गए एचआईडी इस्तेमाल, गेम पैड सीए (0x01 0x0005) में बताए जाने चाहिए.

3 इस इस्तेमाल में, लॉजिकल मिनिमम 0, लॉजिकल मैक्सिमम 7, फ़िज़िकल मिनिमम 0, फ़िज़िकल मैक्सिमम 315, यूनिट डिग्री में, और रिपोर्ट का साइज़ 4 होना चाहिए. लॉजिकल वैल्यू को वर्टिकल ऐक्सिस से क्लॉकवाइज़ रोटेशन के तौर पर तय किया जाता है. उदाहरण के लिए, लॉजिकल वैल्यू 0 का मतलब है कि कोई रोटेशन नहीं हुआ है और ऊपर वाले बटन को दबाया गया है. वहीं, लॉजिकल वैल्यू 1 का मतलब है कि 45 डिग्री का रोटेशन हुआ है और ऊपर और बाईं ओर के दोनों बटन दबाए गए हैं.

4 MotionEvent

ऐनलॉग कंट्रोल1 एचआईडी का इस्तेमाल 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 मिलीसेकंड की ज़्यादा से ज़्यादा देरी के साथ रिपोर्ट करना ज़रूरी है
  • सेंसर के लिए, कम से कम 5 मि॰से॰ की ज़रूरी लेटेन्सी के साथ स्ट्रीम किए गए सेंसर के लिए 2 * sample_time + ऐप्लिकेशन प्रोसेसर के चालू होने पर 2 * sample_time. इस देरी में, फ़िल्टर करने में लगने वाला समय शामिल नहीं है.
  • [C-1-3] सेंसर के चालू होने के 400 मिलीसेकंड + 2 * sample_time के अंदर, सेंसर के पहले सैंपल की जानकारी देना ज़रूरी है. इस सैंपल के लिए, सटीक होने की दर 0 हो सकती है.

  • [SR] Android SDK के दस्तावेज़ में बताए गए तरीके के मुताबिक, इवेंट के समय की जानकारी को नैनोसेकंड में रिपोर्ट करनी चाहिए. इससे यह पता चलता है कि इवेंट कब हुआ और SystemClock.elapsedRealtimeNano() क्लॉक के साथ कब सिंक हुआ. मौजूदा और नए Android डिवाइसों के लिए, इन ज़रूरी शर्तों को पूरा करना बेहद ज़रूरी है. इससे वे आने वाले समय में प्लैटफ़ॉर्म के नए वर्शन पर अपग्रेड कर पाएंगे. ऐसा हो सकता है कि आने वाले समय में, यह एक ज़रूरी कॉम्पोनेंट बन जाए. सिंक करने में होने वाली गड़बड़ी 100 मिलीसेकंड से कम होनी चाहिए.

  • [C-1-7] Android SDK के दस्तावेज़ में बताए गए किसी भी एपीआई के लिए, यह ज़रूरी है कि डिवाइस, लगातार काम करने वाले सेंसर के तौर पर काम करे. साथ ही, समय-समय पर डेटा सैंपल उपलब्ध कराए. इन सैंपल में जिटर 3% से कम होना चाहिए. जिटर को इस तरह से परिभाषित किया जाता है: लगातार होने वाले इवेंट के बीच, रिपोर्ट किए गए टाइमस्टैंप वैल्यू के अंतर का स्टैंडर्ड डेविएशन.

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

  • कई सेंसर चालू होने पर, बिजली की खपत, हर सेंसर की बताई गई बिजली की खपत के योग से ज़्यादा नहीं होनी चाहिए.

ऊपर दी गई सूची पूरी नहीं है. Android SDK और Android Open Source Documentations में सेंसर के बारे में दी गई जानकारी को आधिकारिक माना जाएगा.

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

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

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

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

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

7.3.1. एक्सलरोमीटर

  • डिवाइस में 3-ऐक्सिस एक्सलरोमीटर शामिल होना चाहिए.

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

  • [C-1-1] कम से कम 50 हर्ट्ज़ की फ़्रीक्वेंसी तक इवेंट रिपोर्ट करने की सुविधा होनी चाहिए.
  • [C-1-2] TYPE_ACCELEROMETER सेंसर को लागू करना और उसके बारे में जानकारी देना ज़रूरी है.
  • [C-1-3] Android API में बताए गए Android सेंसर कोऑर्डिनेट सिस्टम का पालन करना ज़रूरी है.
  • [C-1-4] यह किसी भी ऐक्सिस पर, फ़्रीफ़ॉल से लेकर गुरुत्वाकर्षण(4g) से चार गुना या उससे ज़्यादा तक की गति को मेज़र कर सकता हो.
  • [C-1-5] इसका रिज़ॉल्यूशन कम से कम 12 बिट का होना चाहिए.
  • [C-1-6] ज़रूरी है कि स्टैंडर्ड डेविएशन 0.05 m/s^ से ज़्यादा न हो. स्टैंडर्ड डेविएशन की गिनती, हर ऐक्सिस के हिसाब से की जानी चाहिए. इसके लिए, सबसे तेज़ सैंपलिंग रेट पर कम से कम तीन सेकंड की अवधि में इकट्ठा किए गए सैंपल का इस्तेमाल किया जाना चाहिए.
  • [SR] TYPE_SIGNIFICANT_MOTION कंपोज़िट सेंसर को लागू करने का सुझाव दिया जाता है.
  • [SR] अगर ऑनलाइन ऐक्सिलरोमीटर कैलिब्रेशन की सुविधा उपलब्ध है, तो TYPE_ACCELEROMETER_UNCALIBRATED सेंसर को लागू करने का सुझाव दिया जाता है.
  • Android SDK के दस्तावेज़ में बताए गए तरीके के मुताबिक, TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER कंपोज़िट सेंसर लागू करने चाहिए.
  • कम से कम 200 हर्ट्ज़ तक के इवेंट रिपोर्ट करने चाहिए.
  • इसका रिज़ॉल्यूशन कम से कम 16-बिट होना चाहिए.
  • डिवाइस के इस्तेमाल के दौरान, इसे कैलिब्रेट किया जाना चाहिए. ऐसा तब किया जाना चाहिए, जब डिवाइस के लाइफ़साइकल के दौरान इसकी विशेषताओं में बदलाव होता है. साथ ही, डिवाइस को रीबूट करने के दौरान, कंपनसेशन पैरामीटर को सुरक्षित रखना चाहिए.
  • तापमान के हिसाब से सही होना चाहिए.
  • TYPE_ACCELEROMETER_UNCALIBRATED सेंसर को भी लागू करना चाहिए.

अगर डिवाइस में 3-ऐक्सिस एक्सलरोमीटर और TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER में से कोई भी कंपोज़िट सेंसर लागू किया गया है, तो:

  • [C-2-1] इनकी बिजली की खपत का कुल योग हमेशा 4 मिलीवॉट से कम होना चाहिए.
  • डिवाइस के डाइनैमिक या स्टैटिक मोड में होने पर, दोनों की वैल्यू 2 mW और 0.5 mW से कम होनी चाहिए.

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

  • [C-3-1] TYPE_GRAVITY और TYPE_LINEAR_ACCELERATION कंपोज़िट सेंसर को लागू करना ज़रूरी है.
  • TYPE_GAME_ROTATION_VECTOR कंपोज़िट सेंसर का होना चाहिए.
  • [SR] मौजूदा और नए Android डिवाइसों में TYPE_GAME_ROTATION_VECTOR सेंसर को लागू करने का सुझाव दिया जाता है.

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

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

7.3.2. मैग्नेटोमीटर

  • डिवाइस में 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 से ज़्यादा नहीं होना चाहिए.
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED सेंसर को लागू करना चाहिए.
  • [SR] मौजूदा और नए Android डिवाइसों में TYPE_MAGNETIC_FIELD_UNCALIBRATED सेंसर को लागू करने का सुझाव दिया जाता है.

अगर डिवाइस में 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. जीपीएस

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

  • इसमें जीपीएस/जीएनएसएस रिसीवर शामिल होना चाहिए.

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

  • [C-1-1] LocationManager#requestLocationUpdate के ज़रिए अनुरोध किए जाने पर, जगह की जानकारी के आउटपुट के साथ, कम से कम 1 हर्ट्ज़ की दर से काम करना चाहिए.
  • [C-1-2] खुले आसमान वाली जगहों (मज़बूत सिग्नल, न के बराबर मल्टीपाथ, HDOP < 2) में, 0.5 एमबीपीएस या इससे ज़्यादा डेटा स्पीड वाले इंटरनेट कनेक्शन से कनेक्ट होने पर, 10 सेकंड के अंदर जगह की जानकारी का पता लगाना ज़रूरी है (पहली बार जगह की जानकारी का पता लगाने में कम समय लगना). आम तौर पर, इस ज़रूरत को पूरा करने के लिए, किसी तरह की असिस्टेड या अनुमानित जीपीएस/जीएनएसएस तकनीक का इस्तेमाल किया जाता है. इससे जीपीएस/जीएनएसएस लॉक-ऑन टाइम को कम किया जा सकता है. सहायता डेटा में रेफ़रंस टाइम, रेफ़रंस लोकेशन, और सैटेलाइट एफ़ेमेरिस/क्लॉक शामिल होती है.
    • [SR] जगह की जानकारी का पता लगाने के बाद, डिवाइस को खुले आसमान वाली जगहों में 10 सेकंड के अंदर, जगह की जानकारी का पता लगाने की सुविधा मिलनी चाहिए. यह सुविधा, जगह की जानकारी के अनुरोध फिर से शुरू होने पर, पिछली बार जगह की जानकारी मिलने के एक घंटे बाद तक उपलब्ध होनी चाहिए. भले ही, यह अनुरोध डेटा कनेक्शन के बिना और/या डिवाइस बंद करके फिर चालू करने के बाद भेजा गया हो.

  • जगह की जानकारी का पता लगाने के बाद, खुले आसमान वाली जगहों में, जब वाहन रुका हो या उसका ऐक्सलरेशन एक मीटर प्रति सेकंड स्क्वेयर्ड से कम हो, तब:

    • [C-1-3] कम से कम 95% समय में, 20 मीटर के दायरे तक जगह की जानकारी का पता लगाना और 0.5 मीटर प्रति सेकंड की स्पीड का पता लगाना ज़रूरी है.
    • [C-1-4] एक ही कॉन्स्टलेशन के कम से कम आठ सैटलाइट को एक साथ ट्रैक करना और GnssStatus.Callback के ज़रिए उनकी जानकारी देना ज़रूरी है.
    • अलग-अलग कॉन्स्टलेशन के कम से कम 24 सैटलाइट एक साथ ट्रैक करने चाहिए. जैसे, जीपीएस और Glonass, Beidou, Galileo में से कोई एक.
    • [C-1-5] टेस्ट एपीआई ‘getGnssYearOfHardware’ के ज़रिए, जीएनएसएस टेक्नोलॉजी जनरेशन की जानकारी देना ज़रूरी है.
    • [एसआर] आपातकालीन फ़ोन कॉल के दौरान, सामान्य जीपीएस/जीएनएसएस की जगह की जानकारी देना जारी रखें.
    • [एसआर] एसबीएएस को अपवाद मानकर, ट्रैक किए गए सभी कॉन्स्टलेशन (इनके बारे में GnssStatus मैसेज में बताया गया है) से जीएनएसएस के मेज़रमेंट की जानकारी दें.
    • [SR] एजीसी और जीएनएसएस मेज़रमेंट की फ़्रीक्वेंसी की रिपोर्ट करें.
    • [SR] हर जीपीएस लोकेशन के हिस्से के तौर पर, सभी सटीक अनुमानों के बारे में बताएं. इनमें बियरिंग, स्पीड, और वर्टिकल शामिल हैं.
    • [SR] हमारा सुझाव है कि टेस्ट एपीआई LocationManager.getGnssYearOfHardware() के ज़रिए साल "2016" या "2017" की रिपोर्ट करने वाले डिवाइसों के लिए, अतिरिक्त ज़रूरी शर्तों को पूरा किया जाए.

अगर डिवाइसों में जीपीएस/जीएनएसएस रिसीवर शामिल हैं और वे android.hardware.location.gps फ़ीचर फ़्लैग के ज़रिए ऐप्लिकेशन को इस सुविधा के बारे में जानकारी देते हैं, साथ ही LocationManager.getGnssYearOfHardware() Test API "2016" या उसके बाद का साल दिखाता है, तो:

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

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

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

7.3.4. जाइरोस्कोप

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

  • इसमें जाइरोस्कोप (ऐंगुलर चेंज सेंसर) शामिल होना चाहिए.
  • इसमें जाइरोस्कोप सेंसर शामिल नहीं होना चाहिए, जब तक कि 3-ऐक्सिस एक्सलरोमीटर भी शामिल न हो.

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

  • [C-1-1] कम से कम 50 हर्ट्ज़ की फ़्रीक्वेंसी तक इवेंट रिपोर्ट करने की सुविधा होनी चाहिए.
  • [C-1-2] TYPE_GYROSCOPE सेंसर को लागू करना ज़रूरी है. साथ ही, TYPE_GYROSCOPE_UNCALIBRATED सेंसर को भी लागू करना चाहिए.
  • [C-1-3] में, ओरिएंटेशन में होने वाले बदलावों को हर सेकंड में 1,000 डिग्री तक मेज़र करने की सुविधा होनी चाहिए.
  • [C-1-4] इसका रिज़ॉल्यूशन 12 बिट या इससे ज़्यादा होना चाहिए. साथ ही, इसका रिज़ॉल्यूशन 16 बिट या इससे ज़्यादा होना चाहिए.
  • [C-1-5] तापमान के हिसाब से सही होना चाहिए.
  • [C-1-6] इसका इस्तेमाल करते समय, इसे कैलिब्रेट और कंपंसेट किया जाना चाहिए. साथ ही, डिवाइस को रीबूट करने पर भी कंपंसेशन पैरामीटर बने रहने चाहिए.
  • [C-1-7] इसमें हर हर्ट्ज़ के हिसाब से, 1e-7 rad^2 / s^2 से ज़्यादा अंतर नहीं होना चाहिए (हर हर्ट्ज़ के हिसाब से अंतर या rad^2 / s). सैंपलिंग रेट के हिसाब से वैरियंस में बदलाव किया जा सकता है. हालांकि, यह वैल्यू से कम होना चाहिए. दूसरे शब्दों में, अगर 1 हर्ट्ज़ की सैंपलिंग दर पर गायरो के वैरिएंस को मेज़र किया जाता है, तो यह 1e-7 rad^2/s^2 से ज़्यादा नहीं होना चाहिए.
  • [SR] मौजूदा और नए Android डिवाइसों में SENSOR_TYPE_GYROSCOPE_UNCALIBRATED सेंसर को लागू करने का सुझाव दिया जाता है.
  • [SR] यह सुझाव दिया जाता है कि जब डिवाइस कमरे के तापमान पर स्थिर हो, तब कैलिब्रेशन की गड़बड़ी 0.01 रेडियन/सेकंड से कम होनी चाहिए.
  • कम से कम 200 हर्ट्ज़ तक के इवेंट रिपोर्ट करने चाहिए.

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

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

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

  • [C-3-1] TYPE_GRAVITY और TYPE_LINEAR_ACCELERATION कंपोज़िट सेंसर को लागू करना ज़रूरी है.
  • [SR] मौजूदा और नए Android डिवाइसों में TYPE_GAME_ROTATION_VECTOR सेंसर को लागू करने का सुझाव दिया जाता है.
  • TYPE_GAME_ROTATION_VECTOR कंपोज़िट सेंसर का होना चाहिए.

7.3.5. बैरोमीटर

  • डिवाइस में बैरोमीटर (आस-पास की हवा के दबाव को मापने वाला सेंसर) शामिल होना चाहिए.

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

  • [C-1-1] TYPE_PRESSURE सेंसर को लागू करना और उसके बारे में जानकारी देना ज़रूरी है.
  • [C-1-2] को 5 हर्ट्ज़ या इससे ज़्यादा की फ़्रीक्वेंसी पर इवेंट डिलीवर करने में सक्षम होना चाहिए.
  • [C-1-3] तापमान के हिसाब से सही होना चाहिए.
  • [SR] 300hPa से 1100hPa की रेंज में प्रेशर मेज़रमेंट की जानकारी देने का सुझाव दिया जाता है.
  • इसमें 1hPa की सटीक जानकारी होनी चाहिए.
  • इसकी रिलेटिव ऐक्युरसी, 20hPa रेंज में 0.12hPa होनी चाहिए. यह समुद्र तल पर ~200 मीटर के बदलाव पर ~1 मीटर की ऐक्युरसी के बराबर है.

7.3.6. Thermometer

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

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

  • [C-1-1] इसे SENSOR_TYPE_AMBIENT_TEMPERATURE के तौर पर तय किया जाना चाहिए. साथ ही, इसे उस जगह के तापमान को मेज़र करना चाहिए जहां से उपयोगकर्ता डिवाइस के साथ इंटरैक्ट कर रहा है. तापमान को डिग्री सेल्सियस में मेज़र किया जाना चाहिए.
  • [C-1-2] इसे SENSOR_TYPE_TEMPERATURE के तौर पर तय किया जाना चाहिए.
  • [C-1-3] डिवाइस के सीपीयू का तापमान मापना ज़रूरी है.
  • [C-1-4] किसी और तरह के तापमान को नहीं मापना चाहिए.

ध्यान दें कि SENSOR_TYPE_TEMPERATURE सेंसर टाइप को Android 4.0 में बंद कर दिया गया था.

7.3.7. फ़ोटोमीटर

  • डिवाइस में फ़ोटोमीटर (स्क्रीन की रोशनी को अपने-आप घटाने-बढ़ाने वाला सेंसर) शामिल हो सकता है.

7.3.8. निकटता सेंसर

  • डिवाइस में प्रॉक्सिमिटी सेंसर शामिल हो सकता है.

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

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

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

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

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

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

  • [C-2-1] डिवाइस में TYPE_ACCELEROMETER सेंसर होना ज़रूरी है. यह सेंसर:

    • मेज़रमेंट रेंज, कम से कम -8g और +8g के बीच होनी चाहिए.
    • इसका मेज़रमेंट रिज़ॉल्यूशन कम से कम 1024 एलएसबी/जी होना चाहिए.
    • मेज़रमेंट की फ़्रीक्वेंसी कम से कम 12.5 हर्ट्ज़ या इससे कम होनी चाहिए.
    • मेज़रमेंट की फ़्रीक्वेंसी ज़्यादा से ज़्यादा 400 हर्ट्ज़ या इससे ज़्यादा होनी चाहिए.
    • मेज़रमेंट नॉइज़ 400 uG/√Hz से ज़्यादा नहीं होना चाहिए.
    • इस सेंसर के लिए, नॉन-वेक-अप फ़ॉर्म को लागू करना ज़रूरी है. साथ ही, इसमें कम से कम 3,000 सेंसर इवेंट को बफ़र करने की सुविधा होनी चाहिए.
    • बैटरी की खपत 3 mW से ज़्यादा नहीं होनी चाहिए.
    • इसमें 24 घंटे के स्टैटिक डेटासेट से, स्टेशनरी नॉइज़ बायस स्टेबिलिटी \<15 μg √Hz होनी चाहिए.
    • तापमान के हिसाब से, इसमें ≤ +/- 1 मिलीग्राम / °C का बदलाव होना चाहिए.
    • इसमें सबसे सही फ़िटिंग वाली लाइन की नॉन-लीनियरिटी ≤ 0.5% होनी चाहिए. साथ ही, तापमान के हिसाब से संवेदनशीलता में बदलाव ≤ 0.03%/C° होना चाहिए.
    • इसमें व्हाइट नॉइज़ स्पेक्ट्रम होना चाहिए, ताकि सेंसर के नॉइज़ इंटिग्रिटी की ज़रूरी शर्तों को पूरा किया जा सके.

  • [C-2-2] में TYPE_ACCELEROMETER_UNCALIBRATED होना चाहिए. इसकी क्वालिटी से जुड़ी शर्तें, TYPE_ACCELEROMETER के जैसी ही होनी चाहिए.

  • [C-2-3] डिवाइस में TYPE_GYROSCOPE सेंसर होना ज़रूरी है. यह सेंसर:

    • मेज़रमेंट की रेंज कम से कम -1000 और +1000 dps के बीच होनी चाहिए.
    • इसका मेज़रमेंट रिज़ॉल्यूशन कम से कम 16 एलएसबी/डीपीएस होना चाहिए.
    • मेज़रमेंट की फ़्रीक्वेंसी कम से कम 12.5 हर्ट्ज़ या इससे कम होनी चाहिए.
    • मेज़रमेंट की फ़्रीक्वेंसी ज़्यादा से ज़्यादा 400 हर्ट्ज़ या इससे ज़्यादा होनी चाहिए.
    • मेज़रमेंट नॉइज़ 0.014°/s/√Hz से ज़्यादा नहीं होना चाहिए.
    • इसमें 24 घंटे के स्टैटिक डेटासेट से, स्टेशनरी बायस स्टेबिलिटी < 0.0002 °/s √Hz होनी चाहिए.
    • तापमान के हिसाब से, बायस में बदलाव ≤ +/- 0.05 °/ s / °C होना चाहिए.
    • तापमान में ≤ 0.02% / °C के हिसाब से बदलाव होने पर, संवेदनशीलता में बदलाव होना चाहिए.
    • इसमें सबसे सही फ़िट वाली लाइन की नॉन-लीनियरिटी ≤ 0.2% होनी चाहिए.
    • इसमें नॉइज़ डेंसिटी ≤ 0.007 °/s/√Hz होनी चाहिए.
    • इसमें व्हाइट नॉइज़ स्पेक्ट्रम होना चाहिए, ताकि सेंसर के नॉइज़ इंटिग्रिटी की ज़रूरी शर्तों को पूरा किया जा सके.
    • डिवाइस के स्थिर होने पर, तापमान 10 ~ 40 ℃ के बीच कैलिब्रेशन की गड़बड़ी 0.002 रेडियन/सेकंड से कम होनी चाहिए.

  • [C-2-4] इसमें TYPE_GYROSCOPE_UNCALIBRATED होना चाहिए. साथ ही, इसकी क्वालिटी से जुड़ी शर्तें TYPE_GYROSCOPE के जैसी होनी चाहिए.

  • [C-2-5] डिवाइस में TYPE_GEOMAGNETIC_FIELD सेंसर होना ज़रूरी है. साथ ही, यह ज़रूरी है कि:
    • ज़रूरी है कि इसकी मेज़रमेंट रेंज, कम से कम -900 और +900 uT के बीच हो.
    • इसका मेज़रमेंट रिज़ॉल्यूशन कम से कम 5 LSB/uT होना चाहिए.
    • मेज़रमेंट की फ़्रीक्वेंसी कम से कम 5 हर्ट्ज़ या इससे कम होनी चाहिए.
    • मेज़रमेंट की फ़्रीक्वेंसी ज़्यादा से ज़्यादा 50 हर्ट्ज़ या इससे ज़्यादा होनी चाहिए.
    • इसमें मेज़रमेंट नॉइज़ 0.5 uT से ज़्यादा नहीं होना चाहिए.
  • [C-2-6] इसमें TYPE_MAGNETIC_FIELD_UNCALIBRATED होना चाहिए. इसकी क्वालिटी से जुड़ी शर्तें, TYPE_GEOMAGNETIC_FIELD के जैसी होनी चाहिए. इसके अलावा:
    • इस सेंसर के नॉन-वेक-अप फ़ॉर्म को लागू करना ज़रूरी है. साथ ही, इसमें कम से कम 600 सेंसर इवेंट को बफ़र करने की सुविधा होनी चाहिए.
    • इसमें व्हाइट नॉइज़ स्पेक्ट्रम होना चाहिए, ताकि सेंसर के नॉइज़ इंटिग्रिटी की ज़रूरी शर्तों को पूरा किया जा सके.
  • [C-2-7] डिवाइस में TYPE_PRESSURE सेंसर होना चाहिए. यह सेंसर:
    • इसका मेज़रमेंट रेंज कम से कम 300 और 1100 hPa के बीच होनी चाहिए.
    • इसका मेज़रमेंट रिज़ॉल्यूशन कम से कम 80 एलएसबी/एचपीए होना चाहिए.
    • मेज़रमेंट की फ़्रीक्वेंसी कम से कम 1 हर्ट्ज़ या इससे कम होनी चाहिए.
    • मेज़रमेंट की फ़्रीक्वेंसी ज़्यादा से ज़्यादा 10 हर्ट्ज़ या इससे ज़्यादा होनी चाहिए.
    • मेज़रमेंट नॉइज़ 2 Pa/√Hz से ज़्यादा नहीं होना चाहिए.
    • इस सेंसर के नॉन-वेक-अप फ़ॉर्म को लागू करना ज़रूरी है. साथ ही, इसमें कम से कम 300 सेंसर इवेंट को बफ़र करने की सुविधा होनी चाहिए.
    • इसमें 2 mW से ज़्यादा बिजली की खपत नहीं होनी चाहिए.
  • [C-2-8] डिवाइस में TYPE_GAME_ROTATION_VECTOR सेंसर होना ज़रूरी है. यह सेंसर:
    • इस सेंसर के नॉन-वेक-अप फ़ॉर्म को लागू करना ज़रूरी है. साथ ही, इसमें कम से कम 300 सेंसर इवेंट को बफ़र करने की सुविधा होनी चाहिए.
    • बैटरी की खपत 4 mW से ज़्यादा नहीं होनी चाहिए.
  • [C-2-9] डिवाइस में TYPE_SIGNIFICANT_MOTION सेंसर होना ज़रूरी है. यह सेंसर:
    • डिवाइस के स्थिर होने पर, बिजली की खपत 0.5 मि॰वॉ॰ से ज़्यादा नहीं होनी चाहिए. वहीं, डिवाइस के मूव होने पर, बिजली की खपत 1.5 मि॰वॉ॰ से ज़्यादा नहीं होनी चाहिए.
  • [C-2-10] डिवाइस में TYPE_STEP_DETECTOR सेंसर होना चाहिए. यह सेंसर:
    • इस सेंसर के नॉन-वेक-अप फ़ॉर्म को लागू करना ज़रूरी है. साथ ही, इसमें कम से कम 100 सेंसर इवेंट को बफ़र करने की सुविधा होनी चाहिए.
    • डिवाइस के स्थिर होने पर, बिजली की खपत 0.5 मि॰वॉ॰ से ज़्यादा नहीं होनी चाहिए. वहीं, डिवाइस के मूव होने पर, बिजली की खपत 1.5 मि॰वॉ॰ से ज़्यादा नहीं होनी चाहिए.
    • बैटरी की खपत 4 mW से ज़्यादा नहीं होनी चाहिए.
  • [C-2-11] डिवाइस में TYPE_STEP_COUNTER सेंसर होना ज़रूरी है. यह सेंसर:
    • डिवाइस के स्थिर होने पर, बिजली की खपत 0.5 मि॰वॉ॰ से ज़्यादा नहीं होनी चाहिए. वहीं, डिवाइस के मूव होने पर, बिजली की खपत 1.5 मि॰वॉ॰ से ज़्यादा नहीं होनी चाहिए.
  • [C-2-12] डिवाइस में TILT_DETECTOR सेंसर होना ज़रूरी है. यह सेंसर:
    • डिवाइस के स्थिर होने पर, बिजली की खपत 0.5 मि॰वॉ॰ से ज़्यादा नहीं होनी चाहिए. वहीं, डिवाइस के मूव होने पर, बिजली की खपत 1.5 मि॰वॉ॰ से ज़्यादा नहीं होनी चाहिए.
  • [C-2-13] ऐक्सिलरोमीटर, जायरोस्कोप सेंसर, और मैग्नेटोमीटर से रिपोर्ट किए गए एक ही फ़िज़िकल इवेंट का टाइमस्टैंप, एक-दूसरे से 2.5 मिलीसेकंड के अंदर होना चाहिए.
  • [C-2-14] इसमें जाइरोस्कोप सेंसर इवेंट के टाइमस्टैंप, कैमरा सबसिस्टम के टाइम बेस के बराबर होने चाहिए. साथ ही, इनमें एक मिलीसेकंड से ज़्यादा का अंतर नहीं होना चाहिए.
  • [C-2-15] ऐप्लिकेशन को सैंपल, पांच मिलीसेकंड के अंदर डिलीवर किए जाने चाहिए. यह समय, ऐप्लिकेशन को ऊपर दिए गए किसी भी फ़िज़िकल सेंसर पर डेटा उपलब्ध होने के समय से गिना जाएगा.
  • [C-2-16] जब डिवाइस स्थिर हो, तब उसकी बिजली की खपत 0.5 मि॰वॉ॰ से ज़्यादा नहीं होनी चाहिए. साथ ही, जब डिवाइस चल रहा हो, तब उसकी बिजली की खपत 2.0 मि॰वॉ॰ से ज़्यादा नहीं होनी चाहिए. ऐसा तब होना चाहिए, जब इनमें से किसी भी सेंसर का इस्तेमाल किया जा रहा हो:
    • SENSOR_TYPE_SIGNIFICANT_MOTION
    • SENSOR_TYPE_STEP_DETECTOR
    • SENSOR_TYPE_STEP_COUNTER
    • SENSOR_TILT_DETECTORS
  • [C-2-17] इसमें TYPE_PROXIMITY सेंसर हो सकता है. हालांकि, अगर यह मौजूद है, तो इसमें कम से कम 100 सेंसर इवेंट को बफ़र करने की सुविधा होनी चाहिए.

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

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

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

7.3.10. फ़िंगरप्रिंट सेंसर

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

  • इसमें फ़िंगरप्रिंट सेंसर शामिल होना चाहिए.

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

  • [C-1-1] यह ज़रूरी है कि android.hardware.fingerprint सुविधा के साथ काम करने का एलान किया गया हो.
  • [C-1-2] Android SDK के दस्तावेज़ में बताए गए तरीके से, एपीआई को पूरी तरह से लागू करना ज़रूरी है.
  • [C-1-3] में, गलत तरीके से स्वीकार किए जाने की दर 0.002% से ज़्यादा नहीं होनी चाहिए.
  • [SR] हमारा सुझाव है कि स्पूफ़ और इंपोस्टर के तौर पर पहचान किए गए लोगों के कॉल स्वीकार किए जाने की दर 7% से ज़्यादा नहीं होनी चाहिए.
  • [C-1-4] अगर स्पूफ़िंग और धोखाधड़ी के मामलों में, पहचान स्वीकार किए जाने की दर 7% से ज़्यादा है, तो यह जानकारी देना ज़रूरी है कि यह मोड, किसी मुश्किल पिन, पैटर्न या पासवर्ड के मुकाबले कम सुरक्षित हो सकता है. साथ ही, इसे चालू करने से जुड़े जोखिमों के बारे में साफ़ तौर पर बताना ज़रूरी है.
  • [C-1-5] फ़िंगरप्रिंट की पुष्टि करने के लिए, पांच बार गलत तरीके से कोशिश करने के बाद, कम से कम 30 सेकंड तक कोशिशों को सीमित करना ज़रूरी है.
  • [C-1-6] में हार्डवेयर की मदद से कीस्टोर लागू करने की सुविधा होनी चाहिए. साथ ही, फ़िंगरप्रिंट मैचिंग की प्रोसेस, ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट (टीईई) में या टीईई के साथ सुरक्षित चैनल वाली चिप पर होनी चाहिए.
  • [C-1-7] पहचान ज़ाहिर करने वाले सभी फ़िंगरप्रिंट डेटा को एन्क्रिप्ट (सुरक्षित) किया जाना चाहिए. साथ ही, क्रिप्टोग्राफ़िक तरीके से पुष्टि की जानी चाहिए, ताकि उन्हें Android Open Source Project की साइट पर मौजूद लागू करने के दिशा-निर्देशों में बताए गए ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट (टीईई) के बाहर न तो हासिल किया जा सके, न पढ़ा जा सके, और न ही बदला जा सके.
  • [C-1-8] फ़िंगरप्रिंट जोड़ने से पहले, भरोसे की चेन बनाना ज़रूरी है. इसके लिए, उपयोगकर्ता को मौजूदा डिवाइस क्रेडेंशियल की पुष्टि करनी होगी या नया डिवाइस क्रेडेंशियल (पिन/पैटर्न/पासवर्ड) जोड़ना होगा, जिसे टीईई से सुरक्षित किया गया हो. Android Open Source Project के लागू करने से, फ़्रेमवर्क में ऐसा करने का तरीका मिलता है.
  • [C-1-9] यह ज़रूरी है कि तीसरे पक्ष के ऐप्लिकेशन को, अलग-अलग फ़िंगरप्रिंट के बीच अंतर करने की अनुमति न दी जाए.
  • [C-1-10] DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT फ़्लैग का पालन करना ज़रूरी है.
  • [C-1-11] Android 6.0 से पहले के वर्शन से अपग्रेड करने पर, फ़िंगरप्रिंट के डेटा को सुरक्षित तरीके से माइग्रेट किया जाना चाहिए, ताकि ऊपर दी गई ज़रूरी शर्तों को पूरा किया जा सके. अगर ऐसा नहीं किया जाता है, तो डेटा को हटा दिया जाना चाहिए.
  • [SR] डिवाइस पर मेज़र किए गए फ़ॉल्स रिजेक्शन रेट के लिए, यह सुझाव दिया जाता है कि यह 10% से कम होना चाहिए.
  • [SR] एक उंगली के लिए, फ़िंगरप्रिंट सेंसर को छूने से लेकर स्क्रीन अनलॉक होने तक, एक सेकंड से कम समय लगने का सुझाव दिया जाता है.
  • Android ओपन सोर्स प्रोजेक्ट में दिए गए Android फ़िंगरप्रिंट आइकॉन का इस्तेमाल करना चाहिए.

7.3.11. सिर्फ़ Android Automotive के लिए सेंसर

ऑटोमोटिव से जुड़े सेंसर के बारे में android.car.CarSensorManager API में बताया गया है.

7.3.11.1. मौजूदा गियर

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

7.3.11.2. दिन रात मोड

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

7.3.11.3. ड्राइविंग स्टेटस

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

7.3.11.4. पहिए की रफ़्तार

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

7.3.12. पोज़ सेंसर

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

  • इसमें 6 डिग्री ऑफ़ फ़्रीडम वाले पोज़ सेंसर की सुविधा हो सकती है.

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

  • [C-1-1] TYPE_POSE_6DOF सेंसर को लागू करना और उसके बारे में जानकारी देना ज़रूरी है.
  • [C-1-2] को सिर्फ़ रोटेशन वेक्टर के मुकाबले ज़्यादा सटीक होना चाहिए.

7.4. डेटा कनेक्टिविटी

7.4.1. टेलीफ़ोनी

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

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

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

  • [C-1-1] टेक्नोलॉजी के हिसाब से, android.hardware.telephony फ़ीचर फ़्लैग और अन्य सब-फ़ीचर फ़्लैग के बारे में एलान करना ज़रूरी है.
  • [C-1-2] उस टेक्नोलॉजी के लिए, एपीआई की पूरी सुविधा लागू करनी होगी.

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

  • [C-2-1] पूरे एपीआई को नो-ऑप्स के तौर पर लागू करना ज़रूरी है.
7.4.1.1. नंबर ब्लॉक करने की सुविधा के साथ काम करने वाले डिवाइस

अगर डिवाइस में सेट किए गए सिस्टम, android.hardware.telephony feature की रिपोर्ट करते हैं, तो:

  • [C-1-1] MUST include number blocking support
  • [C-1-2] एसडीके के दस्तावेज़ में बताए गए तरीके के मुताबिक, BlockedNumberContract और उससे जुड़े एपीआई को पूरी तरह से लागू करना ज़रूरी है.
  • [C-1-3] ऐप्लिकेशन के साथ किसी भी तरह की बातचीत किए बिना, 'BlockedNumberProvider' में मौजूद किसी फ़ोन नंबर से आने वाले सभी कॉल और मैसेज ब्लॉक करने चाहिए. हालांकि, एसडीके के दस्तावेज़ में बताए गए तरीके से, नंबर ब्लॉक करने की सुविधा को कुछ समय के लिए बंद किया जा सकता है.
  • [C-1-4] ब्लॉक किए गए कॉल के लिए, कॉल लॉग की जानकारी देने वाली कंपनी को जानकारी नहीं भेजनी चाहिए.
  • [C-1-5] ब्लॉक किए गए मैसेज के लिए, टेलीफ़ोनी की सेवा देने वाली कंपनी को नहीं लिखना चाहिए.
  • [C-1-6] ब्लॉक किए गए नंबर मैनेज करने के लिए यूज़र इंटरफ़ेस (यूआई) लागू करना ज़रूरी है. इसे TelecomManager.createManageBlockedNumbersIntent() तरीके से मिले इंटेंट के साथ खोला जाता है.
  • [C-1-7] दूसरे क्रम के उपयोगकर्ताओं को, डिवाइस पर ब्लॉक किए गए नंबर देखने या उनमें बदलाव करने की अनुमति नहीं होनी चाहिए. ऐसा इसलिए, क्योंकि Android प्लैटफ़ॉर्म यह मानता है कि डिवाइस पर टेलीफ़ोनी सेवाओं का पूरा कंट्रोल, मुख्य उपयोगकर्ता के पास होता है. सेकंडरी उपयोगकर्ताओं के लिए, ब्लॉक करने से जुड़ा पूरा यूज़र इंटरफ़ेस (यूआई) छिपा होना चाहिए. साथ ही, ब्लॉक की गई सूची का पालन किया जाना चाहिए.
  • जब कोई डिवाइस Android 7.0 पर अपडेट होता है, तो ब्लॉक किए गए नंबरों को सेवा देने वाली कंपनी के पास माइग्रेट करना चाहिए.
7.4.1.2. Telecom API

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

  • [C-SR] android.telecom एपीआई के लिए, ऑडियो हेडसेट के KEYCODE_MEDIA_PLAY_PAUSE और KEYCODE_HEADSETHOOK इवेंट को मैनेज करने का सुझाव दिया जाता है. इसके लिए, यहां दिया गया तरीका अपनाएं:
    • कॉल चालू होने के दौरान, बटन को कम समय के लिए दबाने पर Connection.onDisconnect() को कॉल करें.
    • इनकमिंग कॉल के दौरान, मुख्य इवेंट को कम समय के लिए दबाने का पता चलने पर, Connection.onAnswer() को कॉल करें.
    • इनकमिंग कॉल के दौरान, मुख्य इवेंट को दबाकर रखने का पता चलने पर, Connection.onReject() को कॉल करें.
    • CallAudioState के म्यूट होने की स्थिति को टॉगल करें

7.4.2. आईईईई 802.11 (वाई-फ़ाई)

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

  • इसमें 802.11 के एक या उससे ज़्यादा फ़ॉर्म के लिए सहायता शामिल होनी चाहिए.

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

  • [C-1-1] Android API को लागू करना ज़रूरी है.
  • [C-1-2] हार्डवेयर फ़ीचर फ़्लैग android.hardware.wifi की जानकारी देना ज़रूरी है.
  • [C-1-3] एसडीके के दस्तावेज़ में बताए गए तरीके से, मल्टीकास्ट एपीआई को लागू करना ज़रूरी है.
  • [C-1-4] यह ज़रूरी है कि डिवाइस, मल्टीकास्ट डीएनएस (एमडीएनएस) के साथ काम करता हो. साथ ही, यह भी ज़रूरी है कि डिवाइस, एमडीएनएस पैकेट (224.0.0.251) को किसी भी समय फ़िल्टर न करे. जैसे:
    • भले ही, स्क्रीन चालू न हो.
    • Android Television डिवाइसों में, स्टैंडबाय पावर स्टेट में होने पर भी ऐसा होता है.
  • जब एसटीए डिसकनेक्ट हो, तब हर स्कैन की शुरुआत में प्रोब रिक्वेस्ट के एमएसी पते और क्रम संख्या को बदलना ज़रूरी है.
    • एक स्कैन के दौरान भेजे गए प्रोब रिक्वेस्ट फ़्रेम के हर ग्रुप को एक ही एमएसी पते का इस्तेमाल करना चाहिए. स्कैन के बीच में एमएसी पता नहीं बदलना चाहिए.
    • प्रोब रिक्वेस्ट फ़्रेम की क्रम संख्या, स्कैन के दौरान सामान्य रूप से क्रम में बढ़ती रहनी चाहिए
    • किसी स्कैन की आखिरी प्रोब रिक्वेस्ट और अगले स्कैन की पहली प्रोब रिक्वेस्ट के बीच में क्रम संख्या को बदलते रहना चाहिए
  • एसटीए के डिसकनेक्ट होने पर, जांच के अनुरोध वाले फ़्रेम में सिर्फ़ ये जानकारी एलिमेंट शामिल होने चाहिए:
    • SSID पैरामीटर सेट (0)
    • DS पैरामीटर सेट (3)
7.4.2.1. Wi-Fi Direct

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

  • इसमें वाई-फ़ाई डायरेक्ट (वाई-फ़ाई पीयर-टू-पीयर) की सुविधा होनी चाहिए.

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

  • [C-1-1] एसडीके के दस्तावेज़ में बताए गए तरीके के मुताबिक, Android API को लागू करना ज़रूरी है.
  • [C-1-2] हार्डवेयर की सुविधा android.hardware.wifi.direct के बारे में जानकारी देना ज़रूरी है.
  • [C-1-3] यह ज़रूरी है कि यह डिवाइस, वाई-फ़ाई की सामान्य सुविधा के साथ काम करता हो.
  • इसमें वाई-फ़ाई और वाई-फ़ाई डायरेक्ट, दोनों एक साथ काम करने चाहिए.

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

अगर डिवाइस में TDLS की सुविधा काम करती है और WiFiManager API के ज़रिए TDLS चालू किया गया है, तो:

  • [C-1-1] WifiManager.isTdlsSupported के ज़रिए, TDLS के साथ काम करने की जानकारी देना ज़रूरी है.
  • टीडीएलएस का इस्तेमाल सिर्फ़ तब करना चाहिए, जब यह मुमकिन हो और फ़ायदेमंद हो.
  • इसमें कुछ अनुमानित जानकारी होनी चाहिए. साथ ही, अगर इसकी परफ़ॉर्मेंस वाई-फ़ाई ऐक्सेस पॉइंट से कनेक्ट करने पर बेहतर हो सकती है, तो इसमें टीडीएलएस का इस्तेमाल नहीं किया जाना चाहिए.
7.4.2.3. Wi-Fi Aware

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

  • इसमें Wi-Fi Aware की सुविधा होनी चाहिए.

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

  • [C-1-1] एसडीके के दस्तावेज़ में बताए गए तरीके के मुताबिक, WifiAwareManager एपीआई लागू करना ज़रूरी है.
  • [C-1-2] android.hardware.wifi.aware फ़ीचर फ़्लैग के बारे में एलान करना ज़रूरी है.
  • [C-1-3] यह ज़रूरी है कि डिवाइस, वाई-फ़ाई और वाई-फ़ाई अवेयर की सुविधाओं को एक साथ इस्तेमाल करने की अनुमति देता हो.
  • [C-1-4] यह ज़रूरी है कि डिवाइस, वाई-फ़ाई अवेयर मैनेजमेंट इंटरफ़ेस के पते को 30 मिनट से ज़्यादा के अंतराल पर और वाई-फ़ाई अवेयर के चालू होने पर, रैंडमाइज़ करे.
7.4.2.4. वाई-फ़ाई पासपॉइंट

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

अगर डिवाइस में वाई-फ़ाई पासपॉइंट की सुविधा काम करती है, तो:

  • [C-1-1] एसडीके के दस्तावेज़ में बताए गए तरीके के मुताबिक, Passpoint से जुड़े WifiManager एपीआई लागू करना ज़रूरी है.
  • [C-1-2] डिवाइस में IEEE 802.11u स्टैंडर्ड का इस्तेमाल किया जाना चाहिए. यह स्टैंडर्ड, खास तौर पर नेटवर्क डिस्कवरी और नेटवर्क चुनने से जुड़ा है. जैसे, जेनेरिक एडवर्टाइज़मेंट सर्विस (जीएएस) और ऐक्सेस नेटवर्क क्वेरी प्रोटोकॉल (एएनक्यूपी).

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

  • [C-2-1] Passpoint से जुड़े WifiManager एपीआई को लागू करने पर, UnsupportedOperationException दिखना चाहिए.

7.4.3. ब्लूटूथ

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

  • इसमें अडवांस ऑडियो कोडेक और ब्लूटूथ ऑडियो कोडेक (जैसे, LDAC) काम करने चाहिए.

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

  • [C-1-1] इनमें ब्लूटूथ 4.2 और ब्लूटूथ स्मार्ट के डेटा लेंथ एक्सटेंशन की सुविधा काम करनी चाहिए.

Android में, ब्लूटूथ और ब्लूटूथ लो एनर्जी की सुविधा काम करती है.

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

  • [C-2-1] प्लैटफ़ॉर्म की काम की सुविधाओं (क्रमशः android.hardware.bluetooth और android.hardware.bluetooth_le) के बारे में एलान करना और प्लैटफ़ॉर्म के एपीआई लागू करना ज़रूरी है.
  • डिवाइस के लिए सही ब्लूटूथ प्रोफ़ाइलें लागू करनी चाहिए. जैसे, A2DP, AVCP, OBEX वगैरह.

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

  • [C-3-1] हार्डवेयर की सुविधा android.hardware.bluetooth_le के बारे में एलान करना ज़रूरी है.
  • [C-3-2] एसडीके के दस्तावेज़ और android.bluetooth में बताए गए तरीके के मुताबिक, GATT (जेनेरिक एट्रिब्यूट प्रोफ़ाइल) पर आधारित ब्लूटूथ एपीआई को चालू करना ज़रूरी है.
  • [C-3-3] BluetoothAdapter.isOffloadedFilteringSupported() के लिए सही वैल्यू रिपोर्ट करना ज़रूरी है, ताकि यह पता चल सके कि ScanFilter एपीआई क्लास के लिए फ़िल्टर करने का लॉजिक लागू किया गया है या नहीं.
  • [C-3-4] BluetoothAdapter.isMultipleAdvertisementSupported() एट्रिब्यूट के लिए सही वैल्यू सबमिट करना ज़रूरी है, ताकि यह पता चल सके कि लो एनर्जी एडवर्टाइज़िंग की सुविधा काम करती है या नहीं.
  • ScanFilter API लागू करते समय, फ़िल्टर करने की लॉजिक को ब्लूटूथ चिपसेट पर ऑफ़लोड करने की सुविधा होनी चाहिए.
  • बैटरी की खपत कम करने के लिए, ब्लूटूथ चिपसेट पर स्कैनिंग की सुविधा चालू होनी चाहिए.

  • इसमें कम से कम चार स्लॉट के साथ एक से ज़्यादा विज्ञापन दिखाने की सुविधा होनी चाहिए.

  • [SR] उपयोगकर्ता की निजता की सुरक्षा के लिए, यह सुझाव दिया जाता है कि हल किए जा सकने वाले निजी पते (आरपीए) के लिए, 15 मिनट से ज़्यादा का टाइमआउट लागू न करें. साथ ही, टाइमआउट के दौरान पते को रोटेट करें.

7.4.4. नियर-फ़ील्ड कम्यूनिकेशन

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

  • इसमें नियर-फ़ील्ड कम्यूनिकेशन (एनएफ़सी) के लिए, ट्रांसीवर और उससे जुड़ा हार्डवेयर शामिल होना चाहिए.
  • [C-0-1] android.nfc.NdefMessage और android.nfc.NdefRecord एपीआई को लागू करना ज़रूरी है. भले ही, उनमें एनएफ़सी की सुविधा काम न करती हो या android.hardware.nfc सुविधा का एलान न किया गया हो. ऐसा इसलिए, क्योंकि क्लास, प्रोटोकॉल से अलग डेटा प्रज़ेंटेशन फ़ॉर्मैट को दिखाती हैं.

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

  • [C-1-1] android.content.pm.PackageManager.hasSystemFeature() तरीके से, android.hardware.nfc सुविधा के बारे में जानकारी देना ज़रूरी है.
  • इसमें नीचे दिए गए एनएफ़सी स्टैंडर्ड के ज़रिए, एनडीईएफ़ मैसेज को पढ़ने और लिखने की सुविधा होनी चाहिए:
  • [C-1-2] यह डिवाइस, NFC फ़ोरम के रीडर/राइटर के तौर पर काम कर सकता हो. इसके लिए, NFC फ़ोरम की तकनीकी जानकारी NFCForum-TS-DigitalProtocol-1.0 में बताए गए इन NFC स्टैंडर्ड का इस्तेमाल किया जाता है:
  • NfcA (ISO14443-3A)
  • NfcB (ISO14443-3B)
  • NfcF (JIS X 6319-4)
  • IsoDep (ISO 14443-4)
  • NFC फ़ोरम के टैग टाइप 1, 2, 3, 4, 5 (NFC फ़ोरम के हिसाब से तय किए गए)

  • [SR] यह सुझाव दिया जाता है कि डिवाइस में, एनएफ़सी के इन स्टैंडर्ड का इस्तेमाल करके, एनडीईएफ़ मैसेज और रॉ डेटा को पढ़ने और लिखने की सुविधा होनी चाहिए. ध्यान दें कि हालांकि, एनएफ़सी के मानकों को 'बेहद ज़रूरी' के तौर पर बताया गया है, लेकिन आने वाले समय में, साथ काम करने की परिभाषा में इन मानकों को 'ज़रूरी' के तौर पर बदला जा सकता है. इस वर्शन में इन मानकों का पालन करना ज़रूरी नहीं है. हालांकि, आने वाले वर्शन में इनका पालन करना ज़रूरी होगा. Android के इस वर्शन पर काम करने वाले मौजूदा और नए डिवाइसों को, इन ज़रूरी शर्तों को पूरा करने के लिए कहा गया है. इससे वे आने वाले समय में, प्लैटफ़ॉर्म के नए वर्शन पर अपग्रेड कर पाएंगे.

  • [C-1-3] में, पीयर-टू-पीयर के इन स्टैंडर्ड और प्रोटोकॉल के ज़रिए डेटा ट्रांसमिट और रिसीव करने की सुविधा होनी चाहिए:

  • ISO 18092
  • LLCP 1.2 (NFC फ़ोरम के हिसाब से तय किया गया)
  • SDP 1.0 (NFC फ़ोरम के मुताबिक)
  • एनडीईएफ़ पुश प्रोटोकॉल
  • SNEP 1.0 (NFC फ़ोरम के मुताबिक)
  • [C-1-4] इसमें Android बीम की सुविधा होनी चाहिए. साथ ही, Android बीम की सुविधा डिफ़ॉल्ट रूप से चालू होनी चाहिए.
  • [C-1-5] Android Beam चालू होने या NFC P2p मोड चालू होने पर, Android Beam का इस्तेमाल करके डेटा भेजा और पाया जा सकता हो.
  • [C-1-6] SNEP डिफ़ॉल्ट सर्वर को लागू करना ज़रूरी है. डिफ़ॉल्ट एसएनईपी सर्वर को मिले मान्य एनडीईएफ़ मैसेज, android.nfc.ACTION_NDEF_DISCOVERED इंटेंट का इस्तेमाल करके ऐप्लिकेशन को भेजे जाने चाहिए. सेटिंग में जाकर Android Beam की सुविधा बंद करने पर, आने वाले NDEF मैसेज को भेजने की सुविधा बंद नहीं होनी चाहिए.
  • [C-1-7] एनएफ़सी शेयर करने की सेटिंग दिखाने के लिए, android.settings.NFCSHARING_SETTINGS के इंटेंट का पालन करना ज़रूरी है.
  • [C-1-8] एनपीपी सर्वर को लागू करना ज़रूरी है. एनपीपी सर्वर को मिले मैसेज को उसी तरह से प्रोसेस किया जाना चाहिए जिस तरह से एसएनईपी के डिफ़ॉल्ट सर्वर को मिले मैसेज को प्रोसेस किया जाता है.
  • [C-1-9] Android Beam चालू होने पर, SNEP क्लाइंट को लागू करना होगा. साथ ही, डिफ़ॉल्ट SNEP सर्वर को आउटबाउंड P2P NDEF भेजने की कोशिश करनी होगी. अगर कोई डिफ़ॉल्ट एसएनईपी सर्वर नहीं मिलता है, तो क्लाइंट को एनपीपी सर्वर को डेटा भेजने की कोशिश करनी चाहिए.
  • [C-1-10] MUST allow foreground activities to set the outbound P2P NDEF message using android.nfc.NfcAdapter.setNdefPushMessage, and android.nfc.NfcAdapter.setNdefPushMessageCallback, and android.nfc.NfcAdapter.enableForegroundNdefPush.
  • उसे आउटबाउंड पी2पी एनडीईएफ़ मैसेज भेजने से पहले, 'बीम करने के लिए छुएं' जैसे जेस्चर या स्क्रीन पर पुष्टि करने की सुविधा का इस्तेमाल करना चाहिए.
  • [C-1-11] अगर डिवाइस पर ब्लूटूथ ऑब्जेक्ट पुश प्रोफ़ाइल काम करती है, तो उसमें एनएफ़सी कनेक्शन को ब्लूटूथ पर ट्रांसफ़र करने की सुविधा होनी चाहिए.
  • [C-1-12] android.nfc.NfcAdapter.setBeamPushUris का इस्तेमाल करते समय, ब्लूटूथ पर कनेक्शन हैंडओवर करने की सुविधा काम करनी चाहिए. इसके लिए, NFC फ़ोरम के “Connection Handover version 1.2” और “Bluetooth Secure Simple Pairing Using NFC version 1.0” स्पेसिफ़िकेशन लागू करने होंगे. इस तरह के डिवाइसों को, हैंडओवर एलएलसीपी सेवा को लागू करना होगा. इसके लिए, सेवा का नाम “urn:nfc:sn:handover” होना चाहिए, ताकि एनएफ़सी पर हैंडओवर का अनुरोध/चुने गए रिकॉर्ड का आदान-प्रदान किया जा सके. साथ ही, डिवाइसों को ब्लूटूथ ऑब्जेक्ट पुश प्रोफ़ाइल का इस्तेमाल करना होगा, ताकि ब्लूटूथ पर डेटा ट्रांसफ़र किया जा सके. लेगसी की वजहों से (Android 4.1 डिवाइसों के साथ काम करने के लिए), लागू करने वाले को अब भी NFC पर हैंडओवर का अनुरोध/चुनिंदा रिकॉर्ड बदलने के लिए, SNEP GET अनुरोधों को स्वीकार करना चाहिए. हालांकि, कनेक्शन हैंडओवर करने के लिए, किसी भी सुविधा को एसएनईपी के GET अनुरोध नहीं भेजने चाहिए.
  • [C-1-13] NFC डिस्कवरी मोड में, डिवाइस के साथ काम करने वाली सभी टेक्नोलॉजी के लिए पोल करना ज़रूरी है.
  • डिवाइस के चालू होने पर, एनएफ़सी को डिस्कवरी मोड में होना चाहिए. साथ ही, स्क्रीन चालू होनी चाहिए और लॉक-स्क्रीन अनलॉक होनी चाहिए.
  • बारकोड और यूआरएल (अगर कोड में बदला गया है) को पढ़ने में सक्षम होना चाहिए. यह Thinfilm NFC Barcode प्रॉडक्ट के लिए ज़रूरी है.

(ध्यान दें कि ऊपर बताए गए JIS, ISO, और NFC फ़ोरम के स्पेसिफ़िकेशन के लिए, सार्वजनिक तौर पर उपलब्ध लिंक मौजूद नहीं हैं.)

Android में, NFC होस्ट कार्ड एम्युलेशन (एचसीई) मोड के साथ काम करने की सुविधा शामिल है.

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

  • [C-2-1] android.hardware.nfc.hce सुविधा के कॉन्स्टेंट की जानकारी देना ज़रूरी है.
  • [C-2-2] Android SDK में बताए गए NFC HCE API काम करने चाहिए.

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

  • [C-3-1] android.hardware.nfc.hcef सुविधा के कॉन्स्टेंट की जानकारी देना ज़रूरी है.
  • [C-3-2] Android SDK में बताए गए NfcF कार्ड इम्यूलेशन एपीआई को लागू करना ज़रूरी है.

अगर डिवाइस में, इस सेक्शन में बताई गई सामान्य एनएफ़सी की सुविधा शामिल है और रीडर/राइटर के तौर पर MIFARE टेक्नोलॉजी (MIFARE Classic, MIFARE Ultralight, MIFARE Classic पर NDEF) काम करती है, तो:

  • [C-4-1] Android SDK के दस्तावेज़ में बताए गए Android API लागू करने ज़रूरी हैं.
  • [C-4-2] android.content.pm.PackageManager.hasSystemFeature() तरीके से, com.nxp.mifare सुविधा के बारे में बताना ज़रूरी है. ध्यान दें कि यह Android की स्टैंडर्ड सुविधा नहीं है. इसलिए, यह android.content.pm.PackageManager क्लास में कॉन्स्टेंट के तौर पर नहीं दिखती है.

7.4.5. नेटवर्क की कम से कम क्षमता

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

  • [C-0-1] डिवाइस में, एक या उससे ज़्यादा तरह के डेटा नेटवर्किंग की सुविधा होनी चाहिए. खास तौर पर, डिवाइस में कम से कम एक ऐसा डेटा स्टैंडर्ड होना चाहिए जो 200Kbit/sec या इससे ज़्यादा की स्पीड से डेटा ट्रांसफ़र कर सके. इस ज़रूरी शर्त को पूरा करने वाली टेक्नोलॉजी के उदाहरणों में EDGE, HSPA, EV-DO, 802.11g, Ethernet, Bluetooth PAN वगैरह शामिल हैं.
  • [C-0-2] इसमें IPv6 नेटवर्किंग स्टैक शामिल होना चाहिए. साथ ही, मैनेज किए गए एपीआई (जैसे, java.net.Socket और java.net.URLConnection) और नेटिव एपीआई (जैसे, AF_INET6 सॉकेट) का इस्तेमाल करके, IPv6 कम्यूनिकेशन की सुविधा होनी चाहिए.
  • [C-0-3] यह ज़रूरी है कि IPv6 डिफ़ॉल्ट रूप से चालू हो.
  • यह पक्का करना ज़रूरी है कि IPv6 कम्यूनिकेशन, IPv4 जितना ही भरोसेमंद हो. उदाहरण के लिए.
  • [C-0-4] यह ज़रूरी है कि डिवाइस, डॉज़ मोड में होने पर भी IPv6 से कनेक्ट रहे.
  • [C-0-5] रेट-लिमिटिंग की वजह से, डिवाइस को आईपीवी6 के साथ काम करने वाले किसी भी ऐसे नेटवर्क पर आईपीवी6 कनेक्टिविटी नहीं खोनी चाहिए जो आरए लाइफ़टाइम के तौर पर कम से कम 180 सेकंड का इस्तेमाल करता है.
  • जब फ़िज़िकल नेटवर्किंग स्टैंडर्ड (जैसे, ईथरनेट) प्राइमरी डेटा कनेक्शन हो, तब कम से कम एक सामान्य वायरलेस डेटा स्टैंडर्ड (जैसे, 802.11 (वाई-फ़ाई)) के लिए भी सहायता शामिल होनी चाहिए
  • डेटा कनेक्टिविटी के एक से ज़्यादा तरीके लागू कर सकता है.

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

अगर डिवाइस में सेट किए गए सिस्टम, वाई-फ़ाई नेटवर्क के साथ काम करते हैं, तो:

  • [C-1-1] यह ज़रूरी है कि वाई-फ़ाई पर ड्यूअल-स्टैक और सिर्फ़ IPv6 का इस्तेमाल किया जा सके.

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

  • [C-2-1] ज़रूरी है कि यह डिवाइस, इथरनेट पर ड्यूअल-स्टैक ऑपरेशन के साथ काम करता हो.

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

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

7.4.6. समन्वयन सेटिंग

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

  • [C-0-1] मास्टर ऑटो-सिंक सेटिंग डिफ़ॉल्ट रूप से चालू होनी चाहिए, ताकि getMasterSyncAutomatically() तरीके से “true” वैल्यू मिले.

7.4.7. डेटा बचाने की सेटिंग

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

  • [SR] डेटा सेवर मोड उपलब्ध कराने का सुझाव दिया जाता है.

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

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

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

  • [C-2-1] ConnectivityManager.getRestrictBackgroundStatus() के लिए, RESTRICT_BACKGROUND_STATUS_DISABLED वैल्यू रिटर्न होनी चाहिए
  • [C-2-2] ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED को ब्रॉडकास्ट नहीं करना चाहिए.
  • [C-2-3] में ऐसी गतिविधि होनी चाहिए जो Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS इंटेंट को हैंडल करती हो. हालांकि, इसे नो-ऑप के तौर पर लागू किया जा सकता है.

7.5. कैमरे

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

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

7.5.1. पीछे की ओर लगा कैमरा

पीछे की ओर वाला कैमरा, डिवाइस के डिसप्ले के दूसरी तरफ़ होता है. यह पारंपरिक कैमरे की तरह, डिवाइस के दूसरी तरफ़ के सीन की इमेज लेता है.

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

  • इसमें पीछे की ओर कैमरा होना चाहिए.

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

  • [C-1-1] android.hardware.camera और android.hardware.camera.any फ़ीचर फ़्लैग की जानकारी देना ज़रूरी है.
  • [C-1-2] इसका रिज़ॉल्यूशन कम से कम 2 मेगापिक्सल होना चाहिए.
  • कैमरा ड्राइवर में, हार्डवेयर ऑटो-फ़ोकस या सॉफ़्टवेयर ऑटो-फ़ोकस की सुविधा होनी चाहिए. यह सुविधा, ऐप्लिकेशन सॉफ़्टवेयर के लिए पारदर्शी होनी चाहिए.
  • इसमें फ़िक्स्ड-फ़ोकस या ईडॉफ़ (एक्सटेंडेड डेप्थ ऑफ़ फ़ील्ड) हार्डवेयर हो सकता है.
  • इसमें फ़्लैश शामिल हो सकता है.

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

  • [C-2-1] जब तक ऐप्लिकेशन, Camera.Parameters ऑब्जेक्ट के FLASH_MODE_AUTO या FLASH_MODE_ON एट्रिब्यूट को चालू करके फ़्लैश को साफ़ तौर पर चालू न करे, तब तक कैमरा प्रीव्यू की सुविधा पर android.hardware.Camera.PreviewCallback इंस्टेंस रजिस्टर होने के दौरान फ़्लैश लैंप चालू नहीं होना चाहिए. ध्यान दें कि यह पाबंदी, डिवाइस में पहले से मौजूद सिस्टम कैमरा ऐप्लिकेशन पर लागू नहीं होती. यह सिर्फ़ Camera.PreviewCallback का इस्तेमाल करने वाले तीसरे पक्ष के ऐप्लिकेशन पर लागू होती है.

7.5.2. सामने वाला कैमरा

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

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

  • इसमें सामने की ओर कैमरा हो सकता है

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

  • [C-1-1] android.hardware.camera.any और android.hardware.camera.front फ़ीचर फ़्लैग की जानकारी देना ज़रूरी है.
  • [C-1-2] का रिज़ॉल्यूशन कम से कम वीजीए (640x480 पिक्सल) होना चाहिए.
  • [C-1-3] Camera API के लिए, सामने वाले कैमरे को डिफ़ॉल्ट कैमरे के तौर पर इस्तेमाल नहीं किया जाना चाहिए. साथ ही, एपीआई को इस तरह कॉन्फ़िगर नहीं किया जाना चाहिए कि सामने वाले कैमरे को डिफ़ॉल्ट तौर पर पीछे वाले कैमरे के तौर पर इस्तेमाल किया जा सके. भले ही, डिवाइस में सिर्फ़ एक कैमरा हो.
  • [C-1-5] जब मौजूदा ऐप्लिकेशन ने android.hardware.Camera.setDisplayOrientation() तरीके का इस्तेमाल करके, कैमरे के डिसप्ले को घुमाने का अनुरोध किया हो, तब कैमरे की झलक को ऐप्लिकेशन के ओरिएंटेशन के हिसाब से, हॉरिज़ॉन्टल तौर पर मिरर किया जाना चाहिए. इसके उलट, अगर मौजूदा ऐप्लिकेशन, android.hardware.Camera.setDisplayOrientation() तरीके को कॉल करके, कैमरा डिसप्ले को घुमाने का अनुरोध नहीं करता है, तो डिवाइस के डिफ़ॉल्ट हॉरिज़ॉन्टल ऐक्सिस के साथ झलक को मिरर किया जाना चाहिए.
  • [C-1-6] फ़ाइनल कैप्चर की गई इमेज या वीडियो स्ट्रीम, ऐप्लिकेशन के कॉल बैक या मीडिया स्टोरेज में सेव की गई इमेज या वीडियो स्ट्रीम से मिलती-जुलती नहीं होनी चाहिए.
  • [C-1-7] पोस्टव्यू में दिखने वाली इमेज, कैमरा प्रीव्यू इमेज स्ट्रीम में दिखने वाली इमेज की तरह ही होनी चाहिए.
  • इसमें सेक्शन 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 या इससे ज़्यादा) के साथ काम करता हो.
  • इसमें MJPEG जैसे वीडियो कंप्रेस करने के तरीके काम करने चाहिए, ताकि अच्छी क्वालिटी वाली अनकोड की गई स्ट्रीम (जैसे कि रॉ या अलग से कंप्रेस की गई पिक्चर स्ट्रीम) को ट्रांसफ़र किया जा सके.
  • एक से ज़्यादा कैमरे इस्तेमाल किए जा सकते हैं.
  • कैमरे के आधार पर वीडियो एन्कोडिंग की सुविधा काम कर सकती है. अगर यह सुविधा काम करती है, तो डिवाइस में एक साथ अनकोड की गई / MJPEG स्ट्रीम (QVGA या इससे ज़्यादा रिज़ॉल्यूशन) ऐक्सेस की जा सकती है.

7.5.4. Camera API का व्यवहार

Android में, कैमरे को ऐक्सेस करने के लिए दो एपीआई पैकेज शामिल हैं. नया android.hardware.camera2 API, ऐप्लिकेशन को कैमरे का लोअर-लेवल कंट्रोल देता है. इसमें ज़ीरो-कॉपी बर्स्ट/स्ट्रीमिंग फ़्लो और एक्सपोज़र, गेन, व्हाइट बैलेंस गेन, कलर कन्वर्ज़न, नॉइज़ कम करना, शार्पनिंग वगैरह के फ़्रेम-दर-फ़्रेम कंट्रोल शामिल हैं.

Android 5.0 में, पुराने एपीआई पैकेज android.hardware.Camera को बंद कर दिया गया है. हालांकि, यह अब भी ऐप्लिकेशन के इस्तेमाल के लिए उपलब्ध होना चाहिए. Android डिवाइसों में, इस सेक्शन और Android SDK में बताए गए तरीके से, एपीआई का इस्तेमाल जारी रहना चाहिए.

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

  • [C-0-1] जब किसी ऐप्लिकेशन ने कभी android.hardware.Camera.Parameters.setPreviewFormat(int) को कॉल नहीं किया हो, तब ऐप्लिकेशन के कॉलबैक को उपलब्ध कराए गए डेटा की झलक के लिए, android.hardware.PixelFormat.YCbCr_420_SP का इस्तेमाल करना ज़रूरी है.
  • [C-0-2] जब कोई ऐप्लिकेशन android.hardware.Camera.PreviewCallback इंस्टेंस रजिस्टर करता है और सिस्टम onPreviewFrame() तरीके को कॉल करता है और पूर्वावलोकन फ़ॉर्मैट YCbCr_420_SP होता है, तो onPreviewFrame() में पास किया गया डेटा, NV21 एन्कोडिंग फ़ॉर्मैट में होना चाहिए. इसका मतलब है कि NV21 डिफ़ॉल्ट फ़ॉर्मैट होना चाहिए.
  • [C-0-3] android.hardware.Camera के लिए, सामने और पीछे वाले दोनों कैमरों की झलक दिखाने के लिए, YV12 फ़ॉर्मैट (android.graphics.ImageFormat.YV12 कॉन्स्टेंट के तौर पर दिखाया गया है) काम करना चाहिए. (हार्डवेयर वीडियो एन्कोडर और कैमरा, किसी भी नेटिव पिक्सल फ़ॉर्मैट का इस्तेमाल कर सकते हैं. हालांकि, डिवाइस पर YV12 में बदलने की सुविधा होनी चाहिए.)
  • [C-0-4] यह ज़रूरी है कि android.hardware.camera2 डिवाइसों के लिए, android.media.ImageReader API के ज़रिए आउटपुट के तौर पर android.hardware.ImageFormat.YUV_420_888 और android.hardware.ImageFormat.JPEG फ़ॉर्मैट काम करें. ये डिवाइस, android.request.availableCapabilities में REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE सुविधा का विज्ञापन दिखाते हैं.
  • [C-0-5] डिवाइस में हार्डवेयर ऑटोफ़ोकस या अन्य सुविधाएं शामिल हैं या नहीं, इससे कोई फ़र्क़ नहीं पड़ता. डिवाइस में Android SDK के दस्तावेज़ में शामिल पूरा Camera API लागू करना ज़रूरी है. उदाहरण के लिए, जिन कैमरों में ऑटोफ़ोकस की सुविधा नहीं होती उन्हें भी रजिस्टर किए गए सभी android.hardware.Camera.AutoFocusCallback इंस्टेंस को कॉल करना होगा. भले ही, यह सुविधा ऑटोफ़ोकस की सुविधा के बिना काम करने वाले कैमरे के लिए काम की न हो. ध्यान दें कि यह सुविधा, सामने वाले कैमरों पर भी लागू होती है. उदाहरण के लिए, भले ही सामने वाले ज़्यादातर कैमरे ऑटोफ़ोकस की सुविधा के साथ काम न करते हों, लेकिन एपीआई कॉलबैक को अब भी बताए गए तरीके से “नकली” होना चाहिए.
  • [C-0-6] android.hardware.Camera.Parameters क्लास में कॉन्स्टेंट के तौर पर तय किए गए हर पैरामीटर के नाम को पहचानना और उसका पालन करना ज़रूरी है. इसके उलट, डिवाइसों को android.hardware.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 इंटेंट को ब्रॉडकास्ट करना ज़रूरी है.

7.5.5. कैमरे का ओरिएंटेशन

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

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

7.6. डिवाइस की मेमोरी और स्टोरेज

7.6.1. कम से कम मेमोरी और स्टोरेज

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

  • [C-0-1] इसमें डाउनलोड मैनेजर शामिल होना चाहिए, जिसका इस्तेमाल ऐप्लिकेशन डेटा फ़ाइलें डाउनलोड करने के लिए कर सकते हैं. साथ ही, इनमें कम से कम 100 एमबी साइज़ की अलग-अलग फ़ाइलें, डिफ़ॉल्ट “कैश” लोकेशन पर डाउनलोड करने की सुविधा होनी चाहिए.

7.6.2. ऐप्लिकेशन के लिए शेयर किया गया स्टोरेज

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

  • [C-0-1] डिवाइस में ऐसा स्टोरेज होना चाहिए जिसे ऐप्लिकेशन के साथ शेयर किया जा सके. इसे अक्सर “शेयर किया गया बाहरी स्टोरेज”, "ऐप्लिकेशन के साथ शेयर किया गया स्टोरेज" या Linux पाथ "/sdcard" के तौर पर भी जाना जाता है.
  • [C-0-2] इसे डिफ़ॉल्ट रूप से माउंट किए गए शेयर किए गए स्टोरेज के साथ कॉन्फ़िगर किया जाना चाहिए.दूसरे शब्दों में कहें, तो “आउट ऑफ़ द बॉक्स”. भले ही, स्टोरेज को इंटरनल स्टोरेज कॉम्पोनेंट या हटाने लायक स्टोरेज मीडियम (जैसे कि सिक्योर डिजिटल कार्ड स्लॉट) पर लागू किया गया हो.
  • [C-0-3] ऐप्लिकेशन को शेयर किए गए स्टोरेज को सीधे तौर पर Linux पाथ sdcard पर माउंट करना होगा. इसके अलावा, sdcard से लेकर माउंट पॉइंट तक Linux सिंबॉलिक लिंक शामिल करना होगा.
  • [C-0-4] SDK में बताए गए तरीके के मुताबिक, इस शेयर की गई मेमोरी पर android.permission.WRITE_EXTERNAL_STORAGE अनुमति लागू करना ज़रूरी है. अगर ऐसा नहीं होता है, तो शेयर किए गए स्टोरेज में, अनुमति पाने वाले किसी भी ऐप्लिकेशन को लिखने की सुविधा मिलनी चाहिए.

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

  • उपयोगकर्ता के लिए उपलब्ध रिमूवेबल स्टोरेज, जैसे कि सिक्योर डिजिटल (एसडी) कार्ड स्लॉट.
  • Android Open Source Project (AOSP) में लागू किए गए इंटरनल (हटाए नहीं जा सकने वाले) स्टोरेज का एक हिस्सा.

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

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

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

  • संगठन में काम करने वालों के साथ ऐप्लिकेशन शेयर करने की सुविधा के लिए, AOSP के लागू किए गए इंटरनल ऐप्लिकेशन शेयर किए गए स्टोरेज का इस्तेमाल करना चाहिए.
  • स्टोरेज स्पेस को ऐप्लिकेशन के निजी डेटा के साथ शेयर कर सकता है.

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

  • [C-3-1] सिर्फ़ पहले से इंस्टॉल किए गए और खास अधिकारों वाले Android ऐप्लिकेशन को, सेकंडरी बाहरी स्टोरेज में डेटा लिखने की WRITE_EXTERNAL_STORAGE अनुमति देनी होगी. हालांकि, ऐसा तब नहीं करना होगा, जब वे अपने पैकेज से जुड़ी डायरेक्ट्री में डेटा लिख रहे हों या ACTION_OPEN_DOCUMENT_TREE इंटेंट को ट्रिगर करने पर मिले URI में डेटा लिख रहे हों.

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

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

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

  • यह रेफ़रंस Android MTP होस्ट, Android File Transfer के साथ काम करना चाहिए.
  • इसे यूएसबी डिवाइस क्लास 0x00 की रिपोर्ट देनी चाहिए.
  • 'एमटीपी' के यूएसबी इंटरफ़ेस का नाम रिपोर्ट करना चाहिए.

7.6.3. एडॉप्टेबल स्टोरेज

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

  • [SR] यह सुझाव दिया जाता है कि अडॉप्टेबल स्टोरेज को लंबे समय तक इस्तेमाल करने के लिए, किसी ऐसी जगह पर सेट अप करें जहां इसे बार-बार डिसकनेक्ट न करना पड़े. ऐसा इसलिए, क्योंकि गलती से डिसकनेक्ट करने पर डेटा मिट सकता है या खराब हो सकता है.

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

7.7. यूएसबी

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

  • इसमें यूएसबी पेरिफ़ेरल मोड और यूएसबी होस्ट मोड काम करना चाहिए.

7.7.1. यूएसबी पेरिफ़ेरल मोड

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

  • [C-1-1] पोर्ट को ऐसे यूएसबी होस्ट से कनेक्ट किया जा सकता हो जिसमें स्टैंडर्ड टाइप-ए या टाइप-सी यूएसबी पोर्ट हो.
  • [C-1-2] android.os.Build.SERIAL के ज़रिए, यूएसबी स्टैंडर्ड डिवाइस डिस्क्रिप्टर में iSerialNumber की सही वैल्यू रिपोर्ट करना ज़रूरी है.
  • [C-1-3] टाइप-सी रजिस्टर के स्टैंडर्ड के मुताबिक, 1.5A और 3.0A चार्जर का पता लगाना ज़रूरी है. साथ ही, अगर वे टाइप-सी यूएसबी के साथ काम करते हैं, तो विज्ञापन में हुए बदलावों का पता लगाना ज़रूरी है.
  • [SR] पोर्ट में माइक्रो-बी, माइक्रो-एबी या टाइप-सी यूएसबी फ़ॉर्म फ़ैक्टर का इस्तेमाल किया जाना चाहिए. हमारा सुझाव है कि मौजूदा और नए Android डिवाइसों पर इन ज़रूरी शर्तों को पूरा किया जाए, ताकि उन्हें आने वाले समय में प्लैटफ़ॉर्म के नए वर्शन में अपग्रेड किया जा सके.
  • [एसआर] पोर्ट को डिवाइस के निचले हिस्से में होना चाहिए (नैचुरल ओरिएंटेशन के हिसाब से) या सभी ऐप्लिकेशन (होम स्क्रीन भी शामिल है) के लिए सॉफ़्टवेयर स्क्रीन रोटेशन की सुविधा चालू होनी चाहिए, ताकि डिवाइस को पोर्ट के साथ नीचे की ओर रखने पर डिसप्ले सही तरीके से दिखे. हमारा सुझाव है कि मौजूदा और नए Android डिवाइसों पर ये ज़रूरी शर्तें पूरी की जाएं, ताकि उन्हें प्लैटफ़ॉर्म के आने वाले वर्शन में अपग्रेड किया जा सके.
  • [SR] को यूएसबी बैटरी चार्जिंग स्पेसिफ़िकेशन, रिवीज़न 1.2 में बताए गए तरीके के मुताबिक, एचएस चिरप और ट्रैफ़िक के दौरान 1.5 A करंट लेने की सुविधा लागू करनी चाहिए. हमारा सुझाव है कि मौजूदा और नए Android डिवाइसों पर इन ज़रूरी शर्तों को पूरा किया जाए, ताकि उन्हें आने वाले समय में प्लैटफ़ॉर्म के नए वर्शन में अपग्रेड किया जा सके.
  • [SR] हमारा सुझाव है कि मालिकाना हक वाले ऐसे चार्जिंग तरीकों का इस्तेमाल न करें जिनसे Vbus वोल्टेज, डिफ़ॉल्ट लेवल से ज़्यादा हो जाता है या सिंक/सोर्स की भूमिकाएं बदल जाती हैं. ऐसा इसलिए, क्योंकि इससे उन चार्जर या डिवाइसों के साथ इंटरऑपरेबिलिटी की समस्याएं हो सकती हैं जो यूएसबी पावर डिलीवरी के स्टैंडर्ड तरीकों के साथ काम करते हैं. हालांकि, इसे "बेहद ज़रूरी" बताया गया है, लेकिन आने वाले समय में Android के वर्शन में, हम सभी टाइप-सी डिवाइसों के लिए यह ज़रूरी कर सकते हैं कि वे स्टैंडर्ड टाइप-सी चार्जर के साथ पूरी तरह से काम करें.
  • [SR] यह सुझाव दिया जाता है कि डिवाइस में डेटा और पावर रोल स्वैपिंग के लिए पावर डिलीवरी की सुविधा हो. ऐसा तब किया जा सकता है, जब डिवाइस में टाइप-सी यूएसबी और यूएसबी होस्ट मोड की सुविधा हो.
  • इसमें ज़्यादा वोल्टेज पर चार्जिंग के लिए, पावर डिलीवरी की सुविधा होनी चाहिए. साथ ही, डिसप्ले आउट जैसे वैकल्पिक मोड के लिए भी सहायता उपलब्ध होनी चाहिए.
  • Android Open Accessory (AOA) API और स्पेसिफ़िकेशन को लागू करना चाहिए. इसके बारे में Android SDK के दस्तावेज़ में बताया गया है.

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

  • [C-2-1] यह ज़रूरी है कि हार्डवेयर की सुविधा android.hardware.usb.accessory के साथ काम करने का एलान किया गया हो.
  • [C-2-2] यूएसबी मास स्टोरेज क्लास में, यूएसबी मास स्टोरेज के इंटरफ़ेस के ब्यौरे iInterface स्ट्रिंग के आखिर में "android" स्ट्रिंग शामिल होनी चाहिए

7.7.2. यूएसबी होस्ट मोड

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

  • [C-1-1] Android SDK में दिए गए दस्तावेज़ के मुताबिक, Android USB होस्ट एपीआई को लागू करना ज़रूरी है. साथ ही, हार्डवेयर की सुविधा android.hardware.usb.host के लिए सहायता उपलब्ध कराने का एलान करना ज़रूरी है.
  • [C-1-2] MUST implement support to connect standard USB peripherals, in other words, they MUST either:
    • डिवाइस में टाइप सी पोर्ट होना चाहिए या डिवाइस के साथ ऐसी केबल होनी चाहिए जो डिवाइस के मालिकाना हक वाले पोर्ट को स्टैंडर्ड यूएसबी टाइप-सी पोर्ट (यूएसबी टाइप-सी डिवाइस) में बदलती हो.
    • डिवाइस में टाइप ए पोर्ट हो या डिवाइस के साथ ऐसी केबल दी गई हो जो डिवाइस के मालिकाना हक वाले पोर्ट को स्टैंडर्ड यूएसबी टाइप-ए पोर्ट में बदलती हो.
    • डिवाइस में माइक्रो-एबी पोर्ट होना चाहिए. साथ ही, डिवाइस के साथ एक केबल भी होनी चाहिए, जो स्टैंडर्ड टाइप-ए पोर्ट के साथ काम करती हो.
  • [C-1-3] इसे यूएसबी टाइप-ए या माइक्रो-एबी पोर्ट को टाइप-सी पोर्ट (रिसेप्टेकल) में बदलने वाले अडैप्टर के साथ शिप नहीं किया जाना चाहिए.
  • [SR] Android SDK के दस्तावेज़ में बताए गए तरीके से, यूएसबी ऑडियो क्लास को लागू करने का सुझाव दिया जाता है.
  • होस्ट मोड में कनेक्ट किए गए यूएसबी सहायक डिवाइस को चार्ज करने की सुविधा होनी चाहिए. साथ ही, यूएसबी टाइप-सी कनेक्टर के लिए, यूएसबी टाइप-सी केबल और कनेक्टर स्पेसिफ़िकेशन, वर्शन 1.2 के टर्मिनेशन पैरामीटर सेक्शन में बताए गए कम से कम 1.5 ऐंपियर के सोर्स करंट का विज्ञापन दिखाना चाहिए. इसके अलावा, माइक्रो-एबी कनेक्टर के लिए, यूएसबी बैटरी चार्जिंग स्पेसिफ़िकेशन, वर्शन 1.2 में बताई गई चार्जिंग डाउनस्ट्रीम पोर्ट(सीडीपी) आउटपुट करंट रेंज का इस्तेमाल करना चाहिए.
  • इसमें यूएसबी टाइप-सी स्टैंडर्ड लागू होने चाहिए और यह उनके साथ काम करना चाहिए.

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

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

  • [C-3-1] इसे रिमोट से कनेक्ट किए गए किसी भी एमटीपी (मीडिया ट्रांसफर प्रोटोकॉल) डिवाइस को पहचानना चाहिए. साथ ही, ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, और ACTION_CREATE_DOCUMENT इंटेंट के ज़रिए, डिवाइस के कॉन्टेंट को ऐक्सेस करने की सुविधा देनी चाहिए. .

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

  • [C-4-1] यूएसबी टाइप-सी के स्पेसिफ़िकेशन (सेक्शन 4.5.1.3.3) में बताई गई, ड्यूअल रोल पोर्ट की सुविधा लागू करना ज़रूरी है.
  • [SR] यह सुझाव दिया जाता है कि DisplayPort काम करे. साथ ही, यह ज़रूरी है कि यूएसबी सुपरस्पीड डेटा रेट काम करे. इसके अलावा, यह सुझाव दिया जाता है कि डेटा और पावर रोल स्वैपिंग के लिए, पावर डिलीवरी की सुविधा काम करे.
  • [SR] हमारा सुझाव है कि यूएसबी टाइप-सी केबल और कनेक्टर स्पेसिफ़िकेशन के वर्शन 1.2 के अपेंडिक्स A में बताए गए तरीके से, ऑडियो अडैप्टर ऐक्सेसरी मोड का इस्तेमाल न करें.
  • डिवाइस के साइज़ और आकार के हिसाब से, Try.* मॉडल लागू करना चाहिए. उदाहरण के लिए, हैंडहेल्ड डिवाइस को Try.SNK मॉडल लागू करना चाहिए.

7.8. ऑडियो

7.8.1. माइक्रोफ़ोन

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

  • [C-1-1] android.hardware.microphone सुविधा के कॉन्सटेंट की जानकारी देना ज़रूरी है.
  • [C-1-2] सेक्शन 5.4 में बताई गई, ऑडियो रिकॉर्डिंग से जुड़ी ज़रूरी शर्तों को पूरा करना ज़रूरी है.
  • [C-1-3] सेक्शन 5.6 में बताई गई ऑडियो लेटेंसी की ज़रूरी शर्तों को पूरा करना ज़रूरी है.
  • [SR] सेक्शन 7.8.3 में बताए गए तरीके से, नियर-अल्ट्रासाउंड रिकॉर्डिंग की सुविधा देने का सुझाव दिया जाता है.

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

  • [C-2-1] android.hardware.microphone सुविधा के कॉन्स्टेंट की जानकारी नहीं देनी चाहिए.
  • [C-2-2] सेक्शन 7 के मुताबिक, ऑडियो रिकॉर्डिंग वाले एपीआई को कम से कम no-ops के तौर पर लागू करना ज़रूरी है.

7.8.2. ऑडियो आउटपुट

अगर डिवाइसों में स्पीकर या ऑडियो/मल्टीमीडिया आउटपुट पोर्ट शामिल हैं, ताकि ऑडियो आउटपुट पेरिफ़ेरल का इस्तेमाल किया जा सके. जैसे, 4 कंडक्टर वाला 3.5 मि॰मी॰ ऑडियो जैक या यूएसबी ऑडियो क्लास का इस्तेमाल करने वाला यूएसबी होस्ट मोड पोर्ट, तो:

  • [C-1-1] android.hardware.audio.output सुविधा के कॉन्सटेंट की जानकारी देना ज़रूरी है.
  • [C-1-2] को 5.5 सेक्शन में बताई गई, ऑडियो चलाने की ज़रूरी शर्तों को पूरा करना होगा.
  • [C-1-3] सेक्शन 5.6 में बताई गई ऑडियो लेटेंसी की ज़रूरी शर्तों को पूरा करना ज़रूरी है.
  • [SR] सेक्शन 7.8.3 में बताए गए तरीके से, नियर-अल्ट्रासाउंड चलाने की सुविधा देने का सुझाव दिया जाता है.

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

  • [C-2-1] android.hardware.audio.output सुविधा की जानकारी नहीं देनी चाहिए.
  • [C-2-2] ऑडियो आउटपुट से जुड़े एपीआई को कम से कम नो-ऑप के तौर पर लागू करना ज़रूरी है.

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

7.8.2.1. ऐनालॉग ऑडियो पोर्ट

Android के सभी डिवाइसों पर 3.5 मि॰मी॰ के ऑडियो प्लग का इस्तेमाल करके, हेडसेट और अन्य ऑडियो ऐक्सेसरी इस्तेमाल की जा सकें, इसके लिए ज़रूरी है कि अगर किसी डिवाइस में एक या उससे ज़्यादा ऐनलॉग ऑडियो पोर्ट शामिल हैं, तो कम से कम एक ऑडियो पोर्ट, चार कंडक्टर वाला 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 के बीच होना चाहिए.
  • [SR] ऑडियो प्लग पर माइक्रोफ़ोन और ग्राउंड कंडक्टर के बीच, इस रेंज के बराबर इंपीडेंस का पता लगाने और उसे कीकोड पर मैप करने का सुझाव दिया जाता है:
    • 110-180 ओम: KEYCODE_VOICE_ASSIST
  • ऑडियो प्लग के लिए, OMTP पिन-आउट ऑर्डर का इस्तेमाल किया जाना चाहिए.
  • इसमें माइक्रोफ़ोन वाले स्टीरियो हेडसेट से ऑडियो रिकॉर्ड करने की सुविधा होनी चाहिए.

अगर डिवाइसों में चार कंडक्टर वाला 3.5 मि॰मी॰ का ऑडियो जैक है और वे माइक्रोफ़ोन के साथ काम करते हैं, तो उन्हें android.intent.action.HEADSET_PLUG को ब्रॉडकास्ट करना होगा. इसमें माइक्रोफ़ोन की अतिरिक्त वैल्यू को 1 के तौर पर सेट करना होगा. ऐसा करने पर:

  • [C-2-1] ज़रूरी है कि प्लग इन की गई ऑडियो ऐक्सेसरी पर माइक्रोफ़ोन का पता लगाने की सुविधा काम करे.

7.8.3. अल्ट्रासाउंड के आस-पास की फ़्रीक्वेंसी

नियर-अल्ट्रासाउंड ऑडियो, 18.5 किलोहर्ट्ज़ से 20 किलोहर्ट्ज़ बैंड होता है.

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

  • AudioManager.getProperty एपीआई के ज़रिए, नियर-अल्ट्रासाउंड ऑडियो की सुविधा के बारे में सही जानकारी देनी होगी. इसके लिए, यह तरीका अपनाएं:

अगर PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND "सही" है, तो VOICE_RECOGNITION और UNPROCESSED ऑडियो सोर्स को इन ज़रूरी शर्तों को पूरा करना होगा:

  • [C-1-1] 18.5 किलोहर्ट्ज़ से 20 किलोहर्ट्ज़ बैंड में माइक्रोफ़ोन की औसत पावर रिस्पॉन्स, 2 किलोहर्ट्ज़ पर रिस्पॉन्स से 15 dB से ज़्यादा कम नहीं होना चाहिए.
  • [C-1-2] 18.5 किलोहर्ट्ज़ से 20 किलोहर्ट्ज़ की फ़्रीक्वेंसी वाले माइक्रोफ़ोन के लिए, 19 किलोहर्ट्ज़ टोन पर -26 dBFS का अनवेटेड सिग्नल-टू-नॉइज़ रेशियो 50 dB से कम नहीं होना चाहिए.

अगर PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND "true" है, तो:

  • [C-2-1] स्पीकर का 18.5 किलोहर्ट्ज़ से 20 किलोहर्ट्ज़ के बीच का औसत रिस्पॉन्स, 2 किलोहर्ट्ज़ के रिस्पॉन्स से 40 डेसिबल से कम नहीं होना चाहिए.

7.9. आभासी वास्तविकता

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

7.9.1. वर्चुअल रिएलिटी मोड

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

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

अगर डिवाइसों पर android.hardware.vr.high_performance फ़ीचर फ़्लैग की मदद से, यह पता चलता है कि उपयोगकर्ता लंबे समय तक हाई परफ़ॉर्मेंस वाले वीआर का इस्तेमाल कर सकते हैं, तो:

  • [C-1-1] कम से कम दो फ़िज़िकल कोर होने चाहिए.
  • [C-1-2] android.software.vr.mode feature का एलान करना ज़रूरी है.
  • [C-1-3] इसमें लगातार परफ़ॉर्म करने वाला मोड काम करना चाहिए.
  • [C-1-4] OpenGL ES 3.2 के साथ काम करना ज़रूरी है.
  • [C-1-5] Vulkan Hardware Level 0 के साथ काम करना ज़रूरी है. साथ ही, Vulkan Hardware 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 एक्सटेंशन की सूची में एक्सटेंशन दिखाना ज़रूरी है.
  • [C-1-7] जीपीयू और डिसप्ले को शेयर किए गए फ़्रंट बफ़र को इस तरह से ऐक्सेस करना चाहिए कि वीआर कॉन्टेंट को 60 फ़्रेम प्रति सेकंड (एफ़पीएस) पर रेंडर करने के लिए, दो रेंडर कॉन्टेक्स्ट के साथ बारी-बारी से आंखों को रेंडर किया जा सके. साथ ही, डिसप्ले में कोई भी विज़िबल टियरिंग आर्टफ़ैक्ट न दिखे.
  • [C-1-8] GL_EXT_multisampled_render_to_texture, GL_OVR_multiview, GL_OVR_multiview2, GL_OVR_multiview_multisampled_render_to_texture, GL_EXT_protected_textures, GL_EXT_EGL_image_array, GL_EXT_external_buffer को लागू करना ज़रूरी है. साथ ही, उपलब्ध GL एक्सटेंशन की सूची में एक्सटेंशन दिखाना ज़रूरी है.
  • [C-1-9] NDK में बताए गए तरीके के मुताबिक, AHardwareBuffer फ़्लैग AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER और AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA के लिए सहायता लागू करना ज़रूरी है.
  • [C-1-10] एक से ज़्यादा लेयर वाले AHardwareBuffers के लिए, सहायता लागू करना ज़रूरी है.
  • [C-1-11] कम से कम 3840x2160@30fps-40Mbps पर H.264 डिकोडिंग की सुविधा काम करनी चाहिए. यह 1920x1080@30fps-10Mbps के चार इंस्टेंस या 1920x1080@60fps-20Mbps के दो इंस्टेंस के बराबर है.
  • [C-1-12] HEVC और VP9 के साथ काम करना ज़रूरी है. साथ ही, कम से कम 1920x1080@30fps-10Mbps को डिकोड करने की क्षमता होनी चाहिए. इसके अलावा, 3840x2160@30fps-20Mbps (1920x1080@30fps-5Mbps के चार इंस्टेंस के बराबर) को डिकोड करने की क्षमता होनी चाहिए.
  • [C-1-13] HardwarePropertiesManager.getDeviceTemperatures एपीआई के साथ काम करना चाहिए और त्वचा के तापमान की सटीक वैल्यू दिखानी चाहिए.
  • [C-1-14] में एक एम्बेड की गई स्क्रीन होनी चाहिए. इसका रिज़ॉल्यूशन कम से कम FullHD(1080p) होना चाहिए. साथ ही, हमारा सुझाव है कि इसका रिज़ॉल्यूशन QuadHD (1440p) या इससे ज़्यादा हो.
  • [C-1-15] VR मोड में, डिसप्ले कम से कम 60 हर्ट्ज़ पर अपडेट होना चाहिए.
  • [C-1-16] डिसप्ले की लेटेन्सी (ग्रे-टू-ग्रे, व्हाइट-टू-ब्लैक, और ब्लैक-टू-व्हाइट स्विचिंग टाइम के तौर पर मेज़र की गई) 6 मिलीसेकंड से कम या इसके बराबर होनी चाहिए.
  • [C-1-17] डिसप्ले में लो-पर्सिस्टेंस मोड काम करना चाहिए. साथ ही, पर्सिस्टेंस 5 मिलीसेकंड या इससे कम होना चाहिए. पर्सिस्टेंस का मतलब है कि कोई पिक्सल कितने समय तक रोशनी देता है.
  • [C-1-18] इनमें ब्लूटूथ 4.2 और ब्लूटूथ स्मार्ट डेटा लेंथ एक्सटेंशन सेक्शन 7.4.3 काम करना चाहिए.
  • [C-1-19] इन सभी डिफ़ॉल्ट सेंसर टाइप के लिए, डायरेक्ट चैनल टाइप को सपोर्ट करना और उसकी सही जानकारी देना ज़रूरी है:
    • TYPE_ACCELEROMETER
    • TYPE_ACCELEROMETER_UNCALIBRATED
    • TYPE_GYROSCOPE
    • TYPE_GYROSCOPE_UNCALIBRATED
    • TYPE_MAGNETIC_FIELD
    • TYPE_MAGNETIC_FIELD_UNCALIBRATED
  • [C-1-20] ऊपर दिए गए सभी डायरेक्ट चैनल टाइप के लिए, TYPE_HARDWARE_BUFFER डायरेक्ट चैनल टाइप का इस्तेमाल किया जा सकता है.
  • [SR] यह सुझाव दिया जाता है कि डिवाइस में android.hardware.sensor.hifi_sensors सुविधा काम करे. साथ ही, यह ज़रूरी है कि डिवाइस, android.hardware.hifi_sensors के लिए जाइरोस्कोप, एक्सलरोमीटर, और मैग्नेटोमीटर से जुड़ी ज़रूरी शर्तों को पूरा करता हो.
  • स्क्रीन पर दिखने वाले ऐप्लिकेशन को खास तौर पर एक कोर उपलब्ध करा सकता है. साथ ही, Process.getExclusiveCores एपीआई के साथ काम कर सकता है, ताकि स्क्रीन पर दिखने वाले टॉप ऐप्लिकेशन के लिए खास तौर पर उपलब्ध सीपीयू कोर की संख्या दिखाई जा सके. अगर एक्सक्लूसिव कोर की सुविधा काम करती है, तो कोर को किसी भी अन्य यूज़रस्पेस प्रोसेस को उस पर चलने की अनुमति नहीं देनी चाहिए. हालांकि, यह ज़रूरी है कि ऐप्लिकेशन के लिए इस्तेमाल किए जाने वाले डिवाइस ड्राइवर को अनुमति दी जाए. इसके अलावा, कोर कुछ कर्नेल प्रोसेस को ज़रूरत के हिसाब से चलने की अनुमति दे सकती है.

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

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

8.1. उपयोगकर्ता अनुभव में एकरूपता

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

8.2. फ़ाइल I/O ऐक्सेस की परफ़ॉर्मेंस

ऐप्लिकेशन के निजी डेटा स्टोरेज (/data पार्टीशन) पर फ़ाइल ऐक्सेस करने की परफ़ॉर्मेंस के लिए, एक सामान्य बेसलाइन उपलब्ध कराने से ऐप्लिकेशन डेवलपर को सही उम्मीद सेट करने में मदद मिलती है. इससे उन्हें अपने सॉफ़्टवेयर को डिज़ाइन करने में मदद मिलती है. डिवाइस के टाइप के हिसाब से, डिवाइस में सेट किए गए सिस्टम के लिए, दूसरे सेक्शन में बताई गई कुछ ज़रूरी शर्तें हो सकती हैं. ये शर्तें, पढ़ने और लिखने से जुड़ी इन कार्रवाइयों के लिए होती हैं:

  • सीक्वेंशियल राइट परफ़ॉर्मेंस. इसे 10 एमबी के राइट बफ़र का इस्तेमाल करके, 256 एमबी की फ़ाइल लिखने के आधार पर मापा जाता है.
  • रैंडम राइट परफ़ॉर्मेंस. इसे 4 केबी के राइट बफ़र का इस्तेमाल करके, 256 एमबी की फ़ाइल लिखने के आधार पर मापा जाता है.
  • सीक्वेंशियल रीड परफ़ॉर्मेंस. इसे 10 एमबी के राइट बफ़र का इस्तेमाल करके, 256 एमबी की फ़ाइल को पढ़ने के आधार पर मापा जाता है.
  • रैंडम रीड परफ़ॉर्मेंस. इसकी जांच, 4 केबी के राइट बफ़र का इस्तेमाल करके 256 एमबी की फ़ाइल को पढ़कर की गई है.

8.3. बैटरी सेव करने वाले मोड

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

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

अगर डिवाइस सिस्टम, ACPI के हिसाब से S3 और S4 पावर स्टेट लागू करते हैं, तो:

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

8.4. ऊर्जा की खपत का हिसाब रखने की सुविधा

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

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

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

8.5. लगातार अच्छी परफ़ॉर्मेंस

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

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

  • [C-0-1] PowerManager.isSustainedPerformanceModeSupported() एपीआई तरीके का इस्तेमाल करके, यह सटीक जानकारी देना ज़रूरी है कि डिवाइस में Sustained Performance Mode की सुविधा काम करती है.

  • सस्टेंड परफ़ॉर्मेंस मोड काम करना चाहिए.

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

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

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

  • इसमें कम से कम एक ऐसा कोर होना चाहिए जिसे सबसे ऊपर मौजूद ऐप्लिकेशन के लिए रिज़र्व किया जा सके.

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

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

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

  • [C-3-1] Process.getExclusiveCores() एपीआई मेथड के ज़रिए, खाली सूची को नतीजे के तौर पर दिखाना ज़रूरी है.

9. सुरक्षा मॉडल के साथ काम करने की सुविधा

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

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

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

9.1. अनुमतियां

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

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

  • ज़्यादा अनुमतियां जोड़ सकता है. हालांकि, नई अनुमति आईडी स्ट्रिंग, android.\* नेमस्पेस में नहीं होनी चाहिए.

  • [C-0-2] PROTECTION_FLAG_PRIVILEGED के protectionLevel वाली अनुमतियां, सिर्फ़ उन ऐप्लिकेशन को दी जानी चाहिए जो सिस्टम इमेज के खास पाथ में पहले से लोड हैं. साथ ही, ये अनुमतियां हर ऐप्लिकेशन के लिए, साफ़ तौर पर अनुमति दी गई अनुमतियों के सबसेट में होनी चाहिए. AOSP, इस ज़रूरी शर्त को पूरा करता है. इसके लिए, वह etc/permissions/ पाथ में मौजूद फ़ाइलों से, हर ऐप्लिकेशन के लिए अनुमति दी गई अनुमतियों को पढ़ता है और उनका पालन करता है. साथ ही, system/priv-app पाथ को खास पाथ के तौर पर इस्तेमाल करता है.

खतरनाक लेवल की सुरक्षा वाली अनुमतियां, रनटाइम की अनुमतियां होती हैं. targetSdkVersion > 22 वाले ऐप्लिकेशन, रनटाइम के दौरान अनुमति का अनुरोध करते हैं.

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

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

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

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

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

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

9.2. यूआईडी और प्रोसेस आइसोलेशन

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

  • [C-0-1] Android ऐप्लिकेशन सैंडबॉक्स मॉडल के साथ काम करना ज़रूरी है. इसमें हर ऐप्लिकेशन, यूनीक Unixstyle UID के तौर पर और अलग प्रोसेस में चलता है.
  • [C-0-2] एक ही Linux यूज़र आईडी के तौर पर कई ऐप्लिकेशन चलाने की सुविधा होनी चाहिए. हालांकि, इसके लिए ज़रूरी है कि ऐप्लिकेशन पर सही तरीके से हस्ताक्षर किए गए हों और उन्हें सही तरीके से बनाया गया हो. इसके बारे में सुरक्षा और अनुमतियों के बारे में जानकारी में बताया गया है.

9.3. फ़ाइल सिस्टम से जुड़ी अनुमतियां

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

9.4. वैकल्पिक एक्ज़ीक्यूशन एनवायरमेंट

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

  • [C-0-1] वैकल्पिक रनटाइम, Android ऐप्लिकेशन होने चाहिए. साथ ही, उन्हें Android के स्टैंडर्ड सुरक्षा मॉडल का पालन करना चाहिए. इसके बारे में सेक्शन 9 में बताया गया है.

  • [C-0-2] वैकल्पिक रनटाइम को उन संसाधनों का ऐक्सेस नहीं दिया जाना चाहिए जिन्हें उन अनुमतियों से सुरक्षित किया गया है जिनके लिए रनटाइम की AndroidManifest.xml फ़ाइल में <uses-permission> मेकेनिज़्म के ज़रिए अनुरोध नहीं किया गया है.

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

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

  • [C-0-5] अन्य Android ऐप्लिकेशन से जुड़े सैंडबॉक्स को लॉन्च करने, उन्हें अनुमति देने या उनका ऐक्सेस पाने की अनुमति, अन्य रनटाइम को नहीं होनी चाहिए.

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

  • [C-0-7] जब डिवाइस के सिस्टम इमेज में, वैकल्पिक रनटाइम की .apk फ़ाइलें शामिल की जाती हैं, तो उन पर ऐसी कुंजी से हस्ताक्षर किया जाना चाहिए जो डिवाइस के साथ शामिल किए गए अन्य ऐप्लिकेशन पर हस्ताक्षर करने के लिए इस्तेमाल की गई कुंजी से अलग हो.

  • [C-0-8] ऐप्लिकेशन इंस्टॉल करते समय, वैकल्पिक रनटाइम को Android की उन अनुमतियों के लिए उपयोगकर्ता की सहमति लेनी होगी जिनका इस्तेमाल ऐप्लिकेशन करता है.

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

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

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

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

9.5. एक डिवाइस पर कई लोगों के काम करने की सुविधा

Android में कई उपयोगकर्ताओं के लिए सहायता शामिल है. साथ ही, यह उपयोगकर्ताओं को पूरी तरह से अलग रखने की सुविधा देता है.

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

अगर डिवाइसों पर एक से ज़्यादा उपयोगकर्ता हैं, तो:

  • [C-1-1] एक से ज़्यादा उपयोगकर्ताओं के लिए सहायता उपलब्ध कराने से जुड़ी इन ज़रूरी शर्तों को पूरा करना ज़रूरी है.
  • [C-1-2] हर उपयोगकर्ता के लिए, एपीआई में Android प्लैटफ़ॉर्म के सुरक्षा मॉडल के मुताबिक सुरक्षा मॉडल लागू करना ज़रूरी है. इसके बारे में सुरक्षा और अनुमतियों के रेफ़रंस दस्तावेज़ में बताया गया है.
  • [C-1-3] हर उपयोगकर्ता इंस्टेंस के लिए, अलग और आइसोलेटेड शेयर किया गया ऐप्लिकेशन स्टोरेज (इसे /sdcard भी कहा जाता है) डायरेक्ट्री होनी चाहिए.
  • [C-1-4] यह पक्का करना ज़रूरी है कि किसी उपयोगकर्ता के मालिकाना हक वाले और उसकी ओर से चलाए जा रहे ऐप्लिकेशन, किसी दूसरे उपयोगकर्ता के मालिकाना हक वाली फ़ाइलों को न तो सूची में शामिल कर सकें, न ही उन्हें पढ़ सकें, और न ही उनमें बदलाव कर सकें. भले ही, दोनों उपयोगकर्ताओं का डेटा एक ही वॉल्यूम या फ़ाइल सिस्टम पर सेव किया गया हो.
  • [C-1-5] अगर डिवाइस में बाहरी स्टोरेज के एपीआई के लिए, हटाने लायक मीडिया का इस्तेमाल किया जाता है, तो मल्टीयूज़र मोड चालू होने पर एसडी कार्ड के कॉन्टेंट को एन्क्रिप्ट (सुरक्षित) करना ज़रूरी है. इसके लिए, सिर्फ़ ऐसे मीडिया पर सेव की गई कुंजी का इस्तेमाल किया जाना चाहिए जिसे हटाया नहीं जा सकता. साथ ही, उस कुंजी को सिर्फ़ सिस्टम ऐक्सेस कर सकता हो. इससे होस्ट पीसी पर मीडिया को पढ़ा नहीं जा सकेगा. इसलिए, डिवाइसों को एमटीपी या इसी तरह के किसी सिस्टम पर स्विच करना होगा, ताकि होस्ट पीसी को मौजूदा उपयोगकर्ता के डेटा का ऐक्सेस मिल सके.

अगर डिवाइसों पर एक से ज़्यादा उपयोगकर्ता मौजूद हैं और उन्होंने android.hardware.telephony सुविधा फ़्लैग का एलान नहीं किया है, तो:

  • [C-2-1] में प्रतिबंधित प्रोफ़ाइल की सुविधा होनी चाहिए. इस सुविधा की मदद से, डिवाइस के मालिक यह मैनेज कर सकते हैं कि डिवाइस पर अन्य उपयोगकर्ता कौन-कौनसी सुविधाएं इस्तेमाल कर सकते हैं. पाबंदी वाली प्रोफ़ाइल की मदद से, डिवाइस के मालिक अन्य उपयोगकर्ताओं के लिए अलग-अलग एनवायरमेंट तुरंत सेट अप कर सकते हैं. साथ ही, उन एनवायरमेंट में उपलब्ध ऐप्लिकेशन पर ज़्यादा पाबंदियां लगा सकते हैं.

अगर डिवाइसों पर एक से ज़्यादा उपयोगकर्ता हैं और उन्होंने android.hardware.telephony फ़ीचर फ़्लैग का एलान किया है, तो:

  • [C-3-1] इसमें प्रतिबंधित प्रोफ़ाइलों के लिए सहायता उपलब्ध नहीं होनी चाहिए. हालांकि, इसमें एओएसपी के कंट्रोल को लागू करने के तरीके के मुताबिक, अन्य उपयोगकर्ताओं को वॉइस कॉल और एसएमएस ऐक्सेस करने की सुविधा चालू /बंद करने की सुविधा होनी चाहिए.

9.6. प्रीमियम एसएमएस की चेतावनी

Android में, लोगों को किसी भी आउटगोइंग प्रीमियम एसएमएस मैसेज के बारे में चेतावनी देने की सुविधा शामिल है. प्रीमियम मैसेज (एसएमएस), मोबाइल और इंटरनेट सेवा देने वाली कंपनी के साथ रजिस्टर की गई किसी सेवा को भेजे जाने वाले टेक्स्ट मैसेज होते हैं. इसके लिए, उपयोगकर्ता से शुल्क लिया जा सकता है.

अगर डिवाइस में सेट किए गए सिस्टम में android.hardware.telephony का इस्तेमाल किया जाता है, तो:

  • [C-1-1] डिवाइस में मौजूद /data/misc/sms/codes.xml फ़ाइल में तय किए गए रेगुलर एक्सप्रेशन से पहचाने गए नंबरों पर एसएमएस भेजने से पहले, उपयोगकर्ताओं को चेतावनी देनी होगी. अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट, इस ज़रूरी शर्त को पूरा करने वाला एक तरीका उपलब्ध कराता है.

9.7. कर्नेल की सुरक्षा से जुड़ी सुविधाएं

Android सैंडबॉक्स में ऐसी सुविधाएं शामिल होती हैं जो Security-Enhanced Linux (SELinux) के ज़रूरी ऐक्सेस कंट्रोल (एमएसी) सिस्टम, seccomp सैंडबॉक्सिंग, और Linux कर्नल में मौजूद अन्य सुरक्षा सुविधाओं का इस्तेमाल करती हैं. डिवाइस में सेट किए गए सिस्टम के लिए:

  • [C-0-1] मौजूदा ऐप्लिकेशन के साथ काम करने की सुविधा को बनाए रखना ज़रूरी है. भले ही, Android फ़्रेमवर्क के नीचे SELinux या कोई अन्य सुरक्षा सुविधा लागू की गई हो.
  • [C-0-2] सुरक्षा से जुड़े उल्लंघन का पता चलने पर, यूज़र इंटरफ़ेस (यूआई) नहीं दिखना चाहिए. साथ ही, Android फ़्रेमवर्क के नीचे लागू की गई सुरक्षा सुविधा से, उल्लंघन को ब्लॉक किया जाना चाहिए. हालांकि, सुरक्षा से जुड़े उल्लंघन को ब्लॉक न किए जाने पर, यूज़र इंटरफ़ेस (यूआई) दिख सकता है. इससे, उल्लंघन का फ़ायदा उठाया जा सकता है.
  • [C-0-3] Android फ़्रेमवर्क के नीचे लागू की गई SELinux या किसी अन्य सुरक्षा सुविधा को, उपयोगकर्ता या ऐप्लिकेशन डेवलपर के लिए कॉन्फ़िगर करने की अनुमति नहीं होनी चाहिए.
  • [C-0-4] किसी ऐसे ऐप्लिकेशन को अनुमति नहीं देनी चाहिए जो एपीआई (जैसे कि डिवाइस एडमिनिस्ट्रेशन एपीआई) के ज़रिए किसी दूसरे ऐप्लिकेशन पर असर डाल सकता है. साथ ही, उसे ऐसी नीति कॉन्फ़िगर करने की अनुमति नहीं देनी चाहिए जो कंपैटिबिलिटी से जुड़ी समस्या पैदा करती हो.
  • [C-0-5] मीडिया फ़्रेमवर्क को कई प्रोसेस में बांटना ज़रूरी है, ताकि Android Open Source Project की साइट पर बताए गए तरीके से, हर प्रोसेस के लिए ऐक्सेस दिया जा सके.
  • [C-0-6] कर्नेल ऐप्लिकेशन सैंडबॉक्सिंग की सुविधा लागू करना ज़रूरी है. इससे मल्टीथ्रेड प्रोग्राम से, कॉन्फ़िगर की जा सकने वाली नीति का इस्तेमाल करके सिस्टम कॉल को फ़िल्टर किया जा सकता है. अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट, इस ज़रूरी शर्त को पूरा करता है. इसके लिए, वह थ्रेडग्रुप सिंक्रनाइज़ेशन (टीएसवाईएनसी) के साथ seccomp-BPF को चालू करता है. इसके बारे में source.android.com के कर्नल कॉन्फ़िगरेशन सेक्शन में बताया गया है.

कर्नल की सुरक्षा और खुद की सुरक्षा करने की सुविधाएं, Android की सुरक्षा के लिए ज़रूरी हैं. डिवाइस में सेट किए गए सिस्टम के लिए:

  • [C-0-7] कर्नेल स्टैक बफ़र ओवरफ़्लो से सुरक्षा देने वाली सुविधाओं (जैसे कि CONFIG_CC_STACKPROTECTOR_STRONG) को लागू करना ज़रूरी है.
  • [C-0-8] कर्नल मेमोरी के लिए, सुरक्षा से जुड़ी सख्त नीतियां लागू करनी होंगी.जैसे, एक्ज़ीक्यूटेबल कोड सिर्फ़ पढ़ा जा सकता है, सिर्फ़ पढ़े जा सकने वाले डेटा को न तो एक्ज़ीक्यूट किया जा सकता है और न ही लिखा जा सकता है. साथ ही, लिखे जा सकने वाले डेटा को एक्ज़ीक्यूट नहीं किया जा सकता (जैसे, CONFIG_DEBUG_RODATA या CONFIG_STRICT_KERNEL_RWX).
  • [SR] यह सुझाव दिया जाता है कि कर्नेल डेटा को सिर्फ़ शुरू करने के दौरान लिखा जाए.साथ ही, शुरू करने के बाद उसे सिर्फ़ पढ़ने के लिए मार्क किया जाए. उदाहरण के लिए, __ro_after_init.
  • [SR} यूज़र-स्पेस और कर्नल-स्पेस के बीच कॉपी किए गए ऑब्जेक्ट के साइज़ की स्टैटिक और डाइनैमिक बाउंड्री की जांच करने का सुझाव दिया जाता है. जैसे, CONFIG_HARDENED_USERCOPY.
  • [SR] कर्नेल में काम करते समय, उपयोगकर्ता-स्पेस मेमोरी को कभी भी एक्ज़ीक्यूट न करने का सुझाव दिया जाता है. उदाहरण के लिए, हार्डवेयर पीएक्सएन या CONFIG_CPU_SW_DOMAIN_PAN या CONFIG_ARM64_SW_TTBR0_PAN के ज़रिए इम्यूलेट किया गया.
  • [SR] यह सुझाव दिया जाता है कि कर्नल में, यूज़र-स्पेस मेमोरी को कभी भी न पढ़ा जाए या उसमें बदलाव न किया जाए. ऐसा सामान्य usercopy ऐक्सेस एपीआई (जैसे, हार्डवेयर पैन या CONFIG_CPU_SW_DOMAIN_PAN या CONFIG_ARM64_SW_TTBR0_PAN के ज़रिए इम्यूलेट किया गया) के बाहर किया जाता है.
  • [SR] कर्नेल कोड और मेमोरी के लेआउट को रैंडमाइज़ करने का सुझाव दिया जाता है.साथ ही, ऐसे एक्सपोज़र से बचने का सुझाव दिया जाता है जिनसे रैंडमाइज़ेशन से समझौता हो सकता है. जैसे, /chosen/kaslr-seed Device Tree node या EFI_RNG_PROTOCOL के ज़रिए बूटलोडर एंट्रॉपी के साथ CONFIG_RANDOMIZE_BASE.

अगर डिवाइस में Linux कर्नल का इस्तेमाल किया जाता है, तो:

  • [C-1-1] SELinux को लागू करना ज़रूरी है.
  • [C-1-2] SELinux को ग्लोबल एनफ़ोर्सिंग मोड पर सेट करना ज़रूरी है.
  • [C-1-3] सभी डोमेन को एनफ़ोर्सिंग मोड में कॉन्फ़िगर करना ज़रूरी है. अनुमति वाले मोड के किसी भी डोमेन को अनुमति नहीं है. इनमें किसी डिवाइस/वेंडर से जुड़े डोमेन भी शामिल हैं.
  • [C-1-4] यह ज़रूरी है कि सिस्टम/sepolicy फ़ोल्डर में मौजूद neverallow नियमों में बदलाव न किया गया हो, उन्हें हटाया न गया हो या बदला न गया हो. यह फ़ोल्डर, अपस्ट्रीम Android Open Source Project (AOSP) में दिया गया है. साथ ही, यह भी ज़रूरी है कि नीति में मौजूद सभी neverallow नियम, AOSP SELinux डोमेन और डिवाइस/वेंडर के हिसाब से बने डोमेन, दोनों के लिए कंपाइल हों.
  • उन्हें Android Open Source Project के अपस्ट्रीम के system/sepolicy फ़ोल्डर में दी गई डिफ़ॉल्ट SELinux नीति को बनाए रखना चाहिए. साथ ही, अपने डिवाइस के हिसाब से कॉन्फ़िगरेशन के लिए, सिर्फ़ इस नीति में बदलाव करना चाहिए.

अगर डिवाइस में Linux के अलावा किसी दूसरे कर्नल का इस्तेमाल किया जाता है, तो:

  • [C-2-1] ज़रूरी है कि SELinux के बराबर का मैंडेटरी ऐक्सेस कंट्रोल सिस्टम इस्तेमाल किया जाए.

9.8. निजता

9.8.1. इस्तेमाल का इतिहास

Android, उपयोगकर्ता की पसंद का इतिहास सेव करता है. साथ ही, UsageStatsManager की मदद से इस इतिहास को मैनेज करता है.

डिवाइस में सेट किए गए सिस्टम के लिए:

  • [C-1-1] को उपयोगकर्ता के इस इतिहास को सेव करने की अवधि तय करनी होगी.
  • [SR] यह सुझाव दिया जाता है कि डेटा को 14 दिनों तक सेव करके रखने की अवधि को, AOSP में डिफ़ॉल्ट रूप से कॉन्फ़िगर किए गए समय के हिसाब से ही सेट किया जाए.

9.8.2. रिकॉर्डिंग

अगर डिवाइसों में ऐसी सुविधा शामिल है जो स्क्रीन पर दिखने वाले कॉन्टेंट को कैप्चर करती है और/या डिवाइस पर चलने वाली ऑडियो स्ट्रीम को रिकॉर्ड करती है, तो:

  • [C-1-1] जब यह सुविधा चालू हो और डेटा कैप्चर/रिकॉर्ड किया जा रहा हो, तब उपयोगकर्ता को लगातार सूचना मिलनी चाहिए.

अगर डिवाइसों में ऐसा कॉम्पोनेंट शामिल है जो बॉक्स से बाहर निकलने पर चालू हो जाता है और उपयोगकर्ता के कॉन्टेक्स्ट के बारे में काम की जानकारी पाने के लिए, आस-पास की आवाज़ रिकॉर्ड कर सकता है, तो:

  • [C-2-1] रिकॉर्ड किए गए रॉ ऑडियो या किसी ऐसे फ़ॉर्मैट को डिवाइस के परसिस्टेंट स्टोरेज में सेव नहीं किया जाना चाहिए या डिवाइस से बाहर नहीं भेजा जाना चाहिए जिसे वापस ओरिजनल ऑडियो या उसके जैसा ऑडियो में बदला जा सकता हो. ऐसा सिर्फ़ उपयोगकर्ता की साफ़ तौर पर दी गई सहमति के साथ किया जा सकता है.

9.8.3. कनेक्टिविटी

अगर डिवाइस में यूएसबी पोर्ट है और वह यूएसबी पेरिफ़ेरल मोड के साथ काम करता है, तो:

  • [C-1-1] यूएसबी पोर्ट के ज़रिए शेयर किए गए स्टोरेज के कॉन्टेंट को ऐक्सेस करने की अनुमति देने से पहले, उपयोगकर्ता की सहमति मांगने वाला यूज़र इंटरफ़ेस (यूआई) दिखाना ज़रूरी है.

9.8.4. नेटवर्क ट्रैफ़िक

डिवाइस में सेट किए गए सिस्टम के लिए:

  • [C-0-1] सिस्टम के भरोसेमंद सर्टिफ़िकेट देने वाली संस्था (सीए) के स्टोर के लिए, उसी रूट सर्टिफ़िकेट को पहले से इंस्टॉल करना होगा जो अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट में दिया गया है.
  • [C-0-2] डिवाइस को, उपयोगकर्ता के रूट सीए स्टोर में कोई भी सर्टिफ़िकेट मौजूद न होने की स्थिति में शिप किया जाना चाहिए.
  • [C-0-3] जब कोई उपयोगकर्ता रूट सीए जोड़ता है, तो उसे एक चेतावनी दिखानी चाहिए. इसमें यह बताया जाना चाहिए कि नेटवर्क ट्रैफ़िक की निगरानी की जा सकती है.

अगर डिवाइस का ट्रैफ़िक वीपीएन से होकर जाता है, तो डिवाइस पर लागू होने वाली ये सेटिंग काम नहीं करेंगी:

  • [C-1-1] उपयोगकर्ता को चेतावनी दिखनी चाहिए, जिसमें इनमें से कोई एक बात बताई गई हो:
    • उस नेटवर्क ट्रैफ़िक की निगरानी की जा सकती है.
    • वह नेटवर्क ट्रैफ़िक, वीपीएन की सुविधा देने वाले किसी खास वीपीएन ऐप्लिकेशन से होकर गुज़र रहा है.

अगर डिवाइसों में ऐसा सिस्टम मौजूद है जो प्रॉक्सी सर्वर या वीपीएन गेटवे के ज़रिए नेटवर्क डेटा ट्रैफ़िक को रूट करता है और यह सिस्टम डिफ़ॉल्ट रूप से चालू होता है, तो:android.permission.CONTROL_VPN

  • [C-2-1] उस वीपीएन को चालू करने से पहले, उपयोगकर्ता की सहमति लेना ज़रूरी है. हालांकि, अगर डिवाइस नीति कंट्रोलर ने DevicePolicyManager.setAlwaysOnVpnPackage() के ज़रिए वीपीएन चालू किया है, तो उपयोगकर्ता की सहमति लेना ज़रूरी नहीं है. ऐसे में, उपयोगकर्ता को सिर्फ़ सूचना देनी होगी.

अगर डिवाइस पर, तीसरे पक्ष के वीपीएन ऐप्लिकेशन के "हमेशा-चालू वीपीएन" फ़ंक्शन को टॉगल करने के लिए, उपयोगकर्ता को सुविधा मिलती है, तो:

  • [C-3-1] जिन ऐप्लिकेशन में हमेशा चालू रहने वाली वीपीएन सेवा काम नहीं करती उनके लिए, उपयोगकर्ता को यह सुविधा बंद करनी होगी. इसके लिए, AndroidManifest.xml फ़ाइल में SERVICE_META_DATA_SUPPORTS_ALWAYS_ON एट्रिब्यूट को false पर सेट करना होगा.

9.9. डेटा स्टोरेज एन्क्रिप्शन

अगर डिवाइस में, सेक्शन 9.11.1 में बताए गए तरीके से सुरक्षित लॉक स्क्रीन की सुविधा काम करती है, तो:

  • [C-1-1] डिवाइस में ऐप्लिकेशन के निजी डेटा (/data partition) और ऐप्लिकेशन के शेयर किए गए स्टोरेज पार्टिशन (/sdcard partition) के डेटा को एन्क्रिप्ट (सुरक्षित) करने की सुविधा होनी चाहिए. ऐसा तब होना चाहिए, जब ऐप्लिकेशन डिवाइस का स्थायी और हटाया न जा सकने वाला हिस्सा हो.

अगर डिवाइसों पर, सेक्शन 9.11.1 में बताई गई सुरक्षित लॉक स्क्रीन की सुविधा काम करती है और वे 50 एमबी/सेकंड से ज़्यादा की एईएस (ऐडवांस एन्क्रिप्शन स्टैंडर्ड) क्रिप्टो परफ़ॉर्मेंस के साथ डेटा स्टोरेज एन्क्रिप्शन की सुविधा के साथ काम करते हैं, तो:

  • [C-2-1] जब उपयोगकर्ता आउट-ऑफ़-बॉक्स सेटअप पूरा कर लेता है, तब डेटा स्टोरेज के लिए एन्क्रिप्शन की सुविधा डिफ़ॉल्ट रूप से चालू होनी चाहिए. अगर डिवाइसों को पहले ही Android के किसी पुराने वर्शन पर लॉन्च किया जा चुका है और उस वर्शन में एन्क्रिप्शन की सुविधा डिफ़ॉल्ट रूप से बंद है, तो सिस्टम सॉफ़्टवेयर को अपडेट करके, डिवाइस इस ज़रूरी शर्त को पूरा नहीं कर सकता. इसलिए, हो सकता है कि उसे इस ज़रूरी शर्त से छूट मिल जाए.

  • उसे फ़ाइल आधारित एन्क्रिप्शन (एफ़बीई) लागू करके, डेटा स्टोरेज को एन्क्रिप्ट करने की ऊपर दी गई ज़रूरी शर्त को पूरा करना चाहिए.

9.9.1. डायरेक्ट बूट

डिवाइस में सेट किए गए सिस्टम के लिए:

  • [C-0-1] डायरेक्ट बूट मोड एपीआई को लागू करना ज़रूरी है. भले ही, वे स्टोरेज एन्क्रिप्शन के साथ काम न करते हों.

  • [C-0-2] ACTION_LOCKED_BOOT_COMPLETED और ACTION_USER_UNLOCKED इंटेंट को अब भी ब्रॉडकास्ट किया जाना चाहिए, ताकि डायरेक्ट बूट की सुविधा वाले ऐप्लिकेशन को यह पता चल सके कि उपयोगकर्ता के लिए, डिवाइस एन्क्रिप्ट (डीई) और क्रेडेंशियल एन्क्रिप्ट (सीई) किए गए स्टोरेज उपलब्ध हैं.

9.9.2. अलग-अलग फ़ाइलों को अलग-अलग तरीकों से एन्क्रिप्ट करने का तरीका

अगर डिवाइस में FBE की सुविधा काम करती है, तो:

  • [C-1-1] डिवाइस को बूट अप करने के लिए, उपयोगकर्ता से क्रेडेंशियल नहीं मांगे जाने चाहिए. साथ ही, ACTION_LOCKED_BOOT_COMPLETED मैसेज ब्रॉडकास्ट होने के बाद, डायरेक्ट बूट की सुविधा वाले ऐप्लिकेशन को डिवाइस के एन्क्रिप्ट (डीई) किए गए स्टोरेज को ऐक्सेस करने की अनुमति दी जानी चाहिए.
  • [C-1-2] डिवाइस को अनलॉक करने के लिए, उपयोगकर्ता को अपने क्रेडेंशियल (जैसे, पासकोड, पिन, पैटर्न या फ़िंगरप्रिंट) देने होंगे. इसके बाद, ACTION_USER_UNLOCKED मैसेज ब्रॉडकास्ट होने पर ही, क्रेडेंशियल एन्क्रिप्ट (सीई) किए गए स्टोरेज को ऐक्सेस करने की अनुमति मिलनी चाहिए.
  • [C-1-3] उपयोगकर्ता के दिए गए क्रेडेंशियल के बिना, CE से सुरक्षित स्टोरेज को अनलॉक करने का कोई तरीका नहीं देना चाहिए.
  • [C-1-4] वेरिफ़ाइड बूट की सुविधा काम करनी चाहिए. साथ ही, यह पक्का करना चाहिए कि DE कुंजियां, डिवाइस के हार्डवेयर रूट ऑफ़ ट्रस्ट से क्रिप्टोग्राफ़िक तौर पर जुड़ी हों.
  • [C-1-5] XTS मोड में, 256 बिट की कुंजी की लंबाई के साथ AES का इस्तेमाल करके, फ़ाइल के कॉन्टेंट को एन्क्रिप्ट (सुरक्षित) करने की सुविधा होनी चाहिए.

  • [C-1-6] फ़ाइल के नाम को एन्क्रिप्ट करने के लिए, AES का इस्तेमाल करना ज़रूरी है. साथ ही, CBC-CTS मोड में 256-बिट की कुंजी का इस्तेमाल करना ज़रूरी है.

  • सीई और डीई स्टोरेज एरिया को सुरक्षित रखने वाले पासकोड:

  • [C-1-7] इसे क्रिप्टोग्राफ़िक तरीके से, हार्डवेयर के समर्थन वाले कीस्टोर से बाइंड किया जाना चाहिए.

  • [C-1-8] CE कुंजियों को उपयोगकर्ता के लॉक स्क्रीन क्रेडेंशियल से बाइंड किया जाना चाहिए.
  • [C-1-9] अगर उपयोगकर्ता ने लॉक स्क्रीन के क्रेडेंशियल नहीं दिए हैं, तो सीई कुंजियों को डिफ़ॉल्ट पासकोड से बाइंड किया जाना चाहिए.

  • [C-1-10] यूनीक और अलग होनी चाहिए. दूसरे शब्दों में, किसी भी उपयोगकर्ता की CE या DE कुंजी, किसी अन्य उपयोगकर्ता की CE या DE कुंजियों से मेल नहीं खानी चाहिए.

  • प्रीलोड किए गए ज़रूरी ऐप्लिकेशन (जैसे, अलार्म, फ़ोन, Messenger) को डायरेक्ट बूट के बारे में जानकारी होनी चाहिए.

  • यह फ़ाइल के कॉन्टेंट और फ़ाइल के नाम को एन्क्रिप्ट (सुरक्षित) करने के लिए, वैकल्पिक सिफ़र, कुंजी की लंबाई, और मोड का इस्तेमाल कर सकता है. हालांकि, इसे डिफ़ॉल्ट रूप से, ज़रूरी तौर पर इस्तेमाल किए जाने वाले सिफ़र, कुंजी की लंबाई, और मोड का इस्तेमाल करना होगा.

अपस्ट्रीम Android Open Source प्रोजेक्ट, Linux कर्नेल ext4 एन्क्रिप्शन सुविधा के आधार पर, इस सुविधा को लागू करने का पसंदीदा तरीका उपलब्ध कराता है.

9.9.3. पूरी डिस्क को एन्क्रिप्ट (सुरक्षित) करना

अगर डिवाइस में पूरी डिस्क को सुरक्षित रखने (एफ़डीई) की सुविधा काम करती है, तो:

  • [C-1-1] AES का इस्तेमाल 128-बिट (या इससे ज़्यादा) की कुंजी के साथ किया जाना चाहिए. साथ ही, स्टोरेज के लिए डिज़ाइन किए गए मोड का इस्तेमाल किया जाना चाहिए. उदाहरण के लिए, AES-XTS, AES-CBC-ESSIV.
  • [C-1-2] एन्क्रिप्शन की को रैप करने के लिए, डिफ़ॉल्ट पासकोड का इस्तेमाल करना ज़रूरी है. साथ ही, एन्क्रिप्ट (सुरक्षित) किए बिना, एन्क्रिप्शन की को किसी भी समय स्टोरेज में नहीं लिखना चाहिए.
  • [C-1-3] डिफ़ॉल्ट रूप से, एन्क्रिप्शन कुंजी को AES से एन्क्रिप्ट (सुरक्षित) करना ज़रूरी है. हालांकि, अगर उपयोगकर्ता साफ़ तौर पर ऑप्ट आउट करता है, तो ऐसा नहीं किया जाएगा. ऐसा तब भी नहीं किया जाएगा, जब इसका इस्तेमाल किया जा रहा हो. साथ ही, लॉक स्क्रीन के क्रेडेंशियल को धीरे-धीरे स्ट्रेच करने वाले एल्गोरिदम (जैसे, PBKDF2 या scrypt) का इस्तेमाल करके स्ट्रेच किया जाता है.
  • [C-1-4] अगर उपयोगकर्ता ने लॉक स्क्रीन के क्रेडेंशियल नहीं दिए हैं या एन्क्रिप्शन के लिए पासकोड के इस्तेमाल को बंद कर दिया है और डिवाइस में हार्डवेयर की मदद से सुरक्षित किया गया कीस्टोर मौजूद है, तो ऊपर दिया गया डिफ़ॉल्ट पासवर्ड स्ट्रेचिंग एल्गोरिदम, उस कीस्टोर से क्रिप्टोग्राफ़िक रूप से जुड़ा होना चाहिए.
  • [C-1-5] डिवाइस से एन्क्रिप्शन कुंजी को बाहर नहीं भेजना चाहिए. भले ही, इसे उपयोगकर्ता के पासकोड और/या हार्डवेयर से जुड़ी कुंजी के साथ रैप किया गया हो.

अपस्ट्रीम Android Open Source प्रोजेक्ट, इस सुविधा को लागू करने का सबसे अच्छा तरीका बताता है. यह Linux कर्नल की सुविधा dm-crypt पर आधारित है.

9.10. डिवाइस इंटिग्रिटी

यहां दी गई ज़रूरी शर्तों से, डिवाइस की इंटिग्रिटी की स्थिति के बारे में पारदर्शिता बनी रहती है. डिवाइस में सेट किए गए सिस्टम के लिए:

  • [C-0-1] सिस्टम एपीआई के PersistentDataBlockManager.getFlashLockState() तरीके का इस्तेमाल करके, यह सही तरीके से रिपोर्ट करना ज़रूरी है कि बूटलोडर की स्थिति, सिस्टम इमेज को फ़्लैश करने की अनुमति देती है या नहीं. FLASH_LOCK_UNKNOWN स्थिति, डिवाइसों के उन वर्शन के लिए रिज़र्व की गई है जो 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] डिवाइस पर पुष्टि किए गए पार्टीशन में बदलाव करने की अनुमति नहीं देनी चाहिए. ऐसा तब तक नहीं किया जाना चाहिए, जब तक उपयोगकर्ता ने बूट लोडर को साफ़ तौर पर अनलॉक न कर दिया हो.
  • [SR] अगर डिवाइस में कई अलग-अलग चिप मौजूद हैं (जैसे, रेडियो, इमेज प्रोसेसर), तो हमारा सुझाव है कि बूट होने पर हर चिप की बूट प्रोसेस के हर चरण की पुष्टि की जाए.
  • [SR] बूटलोडर के अनलॉक होने पर, छेड़छाड़ से सुरक्षित स्टोरेज का इस्तेमाल करने का सुझाव दिया जाता है. टैंपर-एविडेंट स्टोरेज का मतलब है कि बूट लोडर यह पता लगा सकता है कि एचएलओएस (हाई लेवल ऑपरेटिंग सिस्टम) में स्टोरेज के साथ छेड़छाड़ की गई है या नहीं.
  • [SR] डिवाइस का इस्तेमाल करते समय, उपयोगकर्ता को सूचना देने का सुझाव दिया जाता है. साथ ही, बूट लोडर लॉक मोड से बूट लोडर अनलॉक मोड में ट्रांज़िशन की अनुमति देने से पहले, पुष्टि करना ज़रूरी है.
  • [SR] एचएलओएस (जैसे, बूट, सिस्टम पार्टिशन) के लिए रोलबैक सुरक्षा लागू करने का सुझाव दिया जाता है. साथ ही, ओएस के कम से कम मान्य वर्शन का पता लगाने के लिए इस्तेमाल किए गए मेटाडेटा को सेव करने के लिए, छेड़छाड़ से सुरक्षित स्टोरेज का इस्तेमाल करने का सुझाव दिया जाता है.
  • उसे ऐसे किसी भी कॉम्पोनेंट के लिए रोलबैक सुरक्षा लागू करनी चाहिए जिसमें लगातार फ़र्मवेयर (जैसे, मॉडेम, कैमरा) मौजूद रहता है.साथ ही, उसे ऐसे स्टोरेज का इस्तेमाल करना चाहिए जिसमें छेड़छाड़ का पता चल सके. ऐसा इसलिए, ताकि कम से कम अनुमत वर्शन का पता लगाने के लिए इस्तेमाल किए गए मेटाडेटा को सेव किया जा सके.

अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट, external/avb/ रिपॉज़िटरी में इस सुविधा को लागू करने का सबसे सही तरीका बताता है. इसे Android लोड करने के लिए इस्तेमाल किए जाने वाले बूट लोडर में इंटिग्रेट किया जा सकता है.

अगर डिवाइसों पर लागू की गई सुविधाओं में, android.hardware.ram.normal फ़ीचर फ़्लैग की रिपोर्ट दी जाती है, तो:

  • [C-2-1] डिवाइस इंटिग्रिटी के लिए, वेरिफ़ाइड बूट की सुविधा काम करनी चाहिए.

अगर Android के पुराने वर्शन पर, किसी डिवाइस को पहले ही लॉन्च कर दिया गया है और उसमें वेरिफ़ाइड बूट की सुविधा काम नहीं करती है, तो सिस्टम सॉफ़्टवेयर को अपडेट करके उस डिवाइस में यह सुविधा नहीं जोड़ी जा सकती. इसलिए, ऐसे डिवाइसों को इस ज़रूरी शर्त से छूट दी गई है.

9.11. कुंजियां और क्रेडेंशियल

Android Keystore System की मदद से, ऐप्लिकेशन डेवलपर क्रिप्टोग्राफ़िक पासकोड को किसी कंटेनर में सेव कर सकते हैं. साथ ही, KeyChain API या Keystore API के ज़रिए, क्रिप्टोग्राफ़िक ऑपरेशनों में उनका इस्तेमाल कर सकते हैं. डिवाइस में सेट किए गए सिस्टम के लिए:

  • [C-0-1] कम से कम 8,192 से ज़्यादा कुंजियां इंपोर्ट करने की अनुमति होनी चाहिए.
  • [C-0-2] लॉक स्क्रीन पर पुष्टि करने की कोशिशों पर, दर की सीमा लागू होनी चाहिए. साथ ही, इसमें एक्सपोनेंशियल बैकऑफ़ एल्गोरिदम होना चाहिए. अगर 150 बार से ज़्यादा बार पुष्टि नहीं हो पाती है, तो हर बार पुष्टि करने के लिए कम से कम 24 घंटे का इंतज़ार करना होगा.
  • जनरेट की जा सकने वाली कुंजियों की संख्या को सीमित नहीं करना चाहिए

अगर डिवाइस में सुरक्षित लॉक स्क्रीन की सुविधा काम करती है, तो:

  • [C-1-1] सुरक्षित हार्डवेयर के साथ कीस्टोर लागू करने की सुविधा का बैक अप लेना ज़रूरी है.
  • [C-1-2] इसमें RSA, AES, ECDSA, और HMAC क्रिप्टोग्राफ़िक एल्गोरिदम के साथ-साथ MD5, SHA1, और SHA-2 फ़ैमिली हैश फ़ंक्शन लागू होने चाहिए. ऐसा इसलिए, ताकि Android Keystore सिस्टम के साथ काम करने वाले एल्गोरिदम को सही तरीके से इस्तेमाल किया जा सके. साथ ही, यह भी ज़रूरी है कि यह एल्गोरिदम, कर्नल और उससे ऊपर के कोड से सुरक्षित तरीके से अलग किया गया हो. सुरक्षित आइसोलेशन को उन सभी संभावित तरीकों को ब्लॉक करना होगा जिनसे कर्नेल या यूज़रस्पेस कोड, आइसोलेट किए गए एनवायरमेंट की इंटरनल स्थिति को ऐक्सेस कर सकता है. इसमें डीएमए भी शामिल है. अपस्ट्रीम Android Open Source Project (AOSP), Trusty को लागू करके इस ज़रूरी शर्त को पूरा करता है. हालांकि, एआरएम TrustZone पर आधारित कोई अन्य समाधान या तीसरे पक्ष की ओर से समीक्षा किया गया, हाइपरवाइज़र पर आधारित आइसोलेशन को सुरक्षित तरीके से लागू करने का तरीका भी इस्तेमाल किया जा सकता है.
  • [C-1-3] लॉक स्क्रीन की पुष्टि, आइसोलेटेड एक्ज़ीक्यूशन एनवायरमेंट में ही की जानी चाहिए. साथ ही, पुष्टि हो जाने के बाद ही, पुष्टि से जुड़ी कुंजियों का इस्तेमाल करने की अनुमति दी जानी चाहिए. लॉक स्क्रीन के क्रेडेंशियल को इस तरह से सेव किया जाना चाहिए कि सिर्फ़ आइसोलेटेड एक्ज़ीक्यूशन एनवायरमेंट ही लॉक स्क्रीन की पुष्टि कर सके. अपस्ट्रीम Android Open Source Project, Gatekeeper Hardware Abstraction Layer (HAL) और Trusty उपलब्ध कराता है. इनका इस्तेमाल इस ज़रूरी शर्त को पूरा करने के लिए किया जा सकता है.
  • [C-1-4] इसमें कुंजी की पुष्टि करने की सुविधा होनी चाहिए. इसमें पुष्टि करने के लिए इस्तेमाल की जाने वाली हस्ताक्षर कुंजी को सुरक्षित हार्डवेयर से सुरक्षित किया जाता है और हस्ताक्षर करने की प्रोसेस सुरक्षित हार्डवेयर में की जाती है. पुष्टि करने के लिए इस्तेमाल की जाने वाली साइनिंग कुंजियों को ज़्यादा से ज़्यादा डिवाइसों के साथ शेयर किया जाना चाहिए, ताकि इन कुंजियों का इस्तेमाल डिवाइस आइडेंटिफ़ायर के तौर पर न किया जा सके. इस ज़रूरी शर्त को पूरा करने का एक तरीका यह है कि जब तक किसी एसकेयू की कम से कम 1,00,000 यूनिट नहीं बन जातीं, तब तक एक ही पुष्टि करने वाली कुंजी शेयर की जाए. अगर किसी एसकेयू की 1,00,000 से ज़्यादा इकाइयां बनाई जाती हैं, तो हर 1,00,000 इकाइयों के लिए अलग कुंजी का इस्तेमाल किया जा सकता है.

ध्यान दें कि अगर किसी डिवाइस को Android के पुराने वर्शन पर पहले ही लॉन्च कर दिया गया है, तो ऐसे डिवाइस को हार्डवेयर की मदद से सुरक्षित किए गए कीस्टोर की ज़रूरत नहीं होती. हालांकि, अगर वह android.hardware.fingerprint सुविधा का एलान करता है, तो उसे हार्डवेयर की मदद से सुरक्षित किए गए कीस्टोर की ज़रूरत होगी.

9.11.1. सुरक्षित लॉक स्क्रीन

अगर डिवाइसों में सुरक्षित लॉक स्क्रीन की सुविधा है और उनमें एक या उससे ज़्यादा ट्रस्ट एजेंट शामिल हैं, जो TrustAgentService System API को लागू करते हैं, तो:

  • [C-1-1] सेटिंग और लॉक स्क्रीन के यूज़र इंटरफ़ेस में, उपयोगकर्ता को उन स्थितियों के बारे में बताना ज़रूरी है जिनमें स्क्रीन अपने-आप लॉक होने की सुविधा को कुछ समय के लिए बंद कर दिया जाता है या भरोसेमंद एजेंट की मदद से स्क्रीन को अनलॉक किया जा सकता है. AOSP, "अपने-आप लॉक होने की सेटिंग" और "पावर बटन से तुरंत लॉक होने की सेटिंग" मेन्यू के लिए टेक्स्ट के तौर पर जानकारी दिखाता है. साथ ही, लॉक स्क्रीन पर अलग से दिखने वाला आइकॉन दिखाता है. इससे, ज़रूरी शर्तें पूरी होती हैं.
  • [C-1-2] DevicePolicyManager क्लास में मौजूद सभी ट्रस्ट एजेंट एपीआई का पालन करना होगा और उन्हें पूरी तरह से लागू करना होगा. जैसे, KEYGUARD_DISABLE_TRUST_AGENTS कॉन्स्टेंट.
  • [C-1-3] मुख्य निजी डिवाइस (जैसे, हैंडहेल्ड) के तौर पर इस्तेमाल किए जाने वाले डिवाइस पर, TrustAgentService.addEscrowToken() फ़ंक्शन को पूरी तरह से लागू नहीं किया जाना चाहिए. हालांकि, आम तौर पर शेयर किए जाने वाले डिवाइसों पर इस फ़ंक्शन को पूरी तरह से लागू किया जा सकता है.
  • [C-1-4] TrustAgentService.addEscrowToken() को डिवाइस पर सेव करने से पहले, जोड़े गए टोकन को एन्क्रिप्ट (सुरक्षित) करना होगा.
  • [C-1-5] डिवाइस पर एन्क्रिप्शन कुंजी सेव नहीं की जानी चाहिए.
  • [C-1-6] डेटा स्टोरेज को डिक्रिप्ट करने के लिए, एस्क्रो टोकन को चालू करने से पहले, उपयोगकर्ता को सुरक्षा से जुड़ी समस्याओं के बारे में बताना ज़रूरी है.

अगर डिवाइस बनाने वाली कंपनियां, लॉक स्क्रीन को अनलॉक करने के लिए पुष्टि करने के तरीके जोड़ती हैं या उनमें बदलाव करती हैं, तो पुष्टि करने के ऐसे तरीके को स्क्रीन लॉक करने का सुरक्षित तरीका माना जाएगा. इसके लिए, उन्हें:

अगर डिवाइसों पर, लॉक स्क्रीन को अनलॉक करने के लिए पुष्टि करने के तरीकों को जोड़ा या बदला जाता है, तो ऐसे में यह ज़रूरी है कि पुष्टि करने का यह तरीका, किसी जाने-पहचाने सीक्रेट पर आधारित हो. साथ ही, यह भी ज़रूरी है कि पुष्टि करने के इस तरीके को स्क्रीन लॉक करने का सुरक्षित तरीका माना जाए. इसके लिए, यह ज़रूरी है कि:

  • [C-3-1] इनपुट की सबसे छोटी मान्य लंबाई की एंट्रॉपी, 10 बिट से ज़्यादा होनी चाहिए.
  • [C-3-2] सभी संभावित इनपुट की ज़्यादा से ज़्यादा एंट्रॉपी 18 बिट से ज़्यादा होनी चाहिए.
  • [C-3-3] यह ज़रूरी है कि AOSP में लागू किए गए और दिए गए पुष्टि करने के किसी भी मौजूदा तरीके (पिन,पैटर्न, पासवर्ड) को न बदला जाए.
  • [C-3-4] डिवाइस नीति कंट्रोलर (डीपीसी) ऐप्लिकेशन के DevicePolicyManager.setPasswordQuality() तरीके से, PASSWORD_QUALITY_SOMETHING से ज़्यादा पाबंदी वाले क्वालिटी कॉन्स्टेंट के साथ पासवर्ड की क्वालिटी की नीति सेट करने पर, इसे बंद करना ज़रूरी है.

अगर डिवाइसों में, लॉक स्क्रीन को अनलॉक करने के लिए पुष्टि करने के तरीकों को जोड़ा या उनमें बदलाव किया जाता है, तो पुष्टि करने का यह तरीका किसी फ़िज़िकल टोकन या जगह के हिसाब से होना चाहिए. ऐसे में, पुष्टि करने के इस तरीके को स्क्रीन लॉक करने का सुरक्षित तरीका माना जाएगा. इसके लिए, यह ज़रूरी है कि:

  • [C-4-1] MUST have a fall-back mechanism to use one of the primary authentication methods which is based on a known secret and meets the requirements to be treated as a secure lock screen.
  • [C-4-2] इसे बंद किया जाना चाहिए. साथ ही, डिवाइस नीति कंट्रोलर (डीपीसी) ऐप्लिकेशन के DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) या DevicePolicyManager.setPasswordQuality() तरीके से नीति सेट करने पर, सिर्फ़ मुख्य पुष्टि करने के तरीके से स्क्रीन को अनलॉक करने की अनुमति दी जानी चाहिए. साथ ही, PASSWORD_QUALITY_UNSPECIFIED से ज़्यादा पाबंदी वाला क्वालिटी कॉन्स्टेंट इस्तेमाल किया जाना चाहिए.
  • [C-4-3] उपयोगकर्ता को कम से कम हर 72 घंटे में एक बार, पुष्टि करने के मुख्य तरीके (जैसे कि पिन, पैटर्न, पासवर्ड) का इस्तेमाल करने के लिए कहा जाना चाहिए.

अगर डिवाइसों में, बायोमेट्रिक के आधार पर लॉक स्क्रीन को अनलॉक करने के लिए पुष्टि करने के तरीके जोड़े जाते हैं या उनमें बदलाव किया जाता है, तो पुष्टि करने के ऐसे तरीके को स्क्रीन लॉक करने का सुरक्षित तरीका माना जाएगा. इसके लिए, उन्हें:

  • [C-5-1] डिवाइस में, पुष्टि करने के मुख्य तरीकों में से किसी एक का इस्तेमाल करने के लिए, फ़ॉल-बैक मैकेनिज़्म होना चाहिए. यह मैकेनिज़्म, किसी ऐसे सीक्रेट पर आधारित होना चाहिए जिसके बारे में उपयोगकर्ता को पता हो. साथ ही, यह सुरक्षित लॉक स्क्रीन के तौर पर इस्तेमाल किए जाने की ज़रूरी शर्तों को पूरा करता हो.
  • [C-5-2] इसे बंद किया जाना चाहिए. साथ ही, डिवाइस नीति कंट्रोलर (डीपीसी) ऐप्लिकेशन के DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_FINGERPRINT) तरीके को कॉल करके, कीगार्ड सुविधा की नीति सेट करने पर, स्क्रीन को अनलॉक करने के लिए सिर्फ़ मुख्य पुष्टि करने की अनुमति दी जानी चाहिए.
  • [C-5-3] इसमें फ़िंगरप्रिंट सेंसर के लिए ज़रूरी फ़ॉल्स एक्सेप्टेंस रेट (एफ़एआर) के बराबर या उससे कम एफ़एआर होना चाहिए. इसके बारे में सेक्शन 7.3.10 में बताया गया है. अगर ऐसा नहीं है, तो इसे बंद कर देना चाहिए. साथ ही, डिवाइस पॉलिसी कंट्रोलर (डीपीसी) ऐप्लिकेशन के DevicePolicyManager.setPasswordQuality() तरीके से, PASSWORD_QUALITY_BIOMETRIC_WEAK से ज़्यादा पाबंदी वाले क्वालिटी कॉन्स्टेंट के साथ पासवर्ड क्वालिटी पॉलिसी सेट करने पर, स्क्रीन को अनलॉक करने के लिए सिर्फ़ प्राइमरी ऑथेंटिकेशन की अनुमति देनी चाहिए.
  • [एसआर] में, स्पूफ़ और इंपोस्टर को स्वीकार करने की दरें, फ़िंगरप्रिंट सेंसर के लिए ज़रूरी दरों के बराबर या उनसे ज़्यादा होनी चाहिए. इसके बारे में सेक्शन 7.3.10 में बताया गया है.

अगर स्पूफ़िंग और धोखाधड़ी करने वाले व्यक्ति को स्वीकार करने की दर, फ़िंगरप्रिंट सेंसर के लिए ज़रूरी दर के बराबर या उससे ज़्यादा नहीं है, जैसा कि सेक्शन 7.3.10 में बताया गया है. साथ ही, डिवाइस नीति कंट्रोलर (डीपीसी) ऐप्लिकेशन ने DevicePolicyManager.setPasswordQuality() तरीके से पासवर्ड की क्वालिटी से जुड़ी नीति सेट की है, जिसमें PASSWORD_QUALITY_BIOMETRIC_WEAK की तुलना में क्वालिटी से जुड़ा ज़्यादा पाबंदी वाला कॉन्स्टेंट इस्तेमाल किया गया है, तो:

  • [C-6-1] इन बायोमेट्रिक तरीकों को बंद करना होगा. साथ ही, स्क्रीन को अनलॉक करने के लिए सिर्फ़ पुष्टि करने के मुख्य तरीके का इस्तेमाल करने की अनुमति देनी होगी.
  • [C-6-2] उपयोगकर्ता को कम से कम हर 72 घंटे में एक बार, पुष्टि करने के लिए चुनौती देनी होगी. जैसे, पिन, पैटर्न, पासवर्ड.

अगर डिवाइस के लिए लागू किए गए सॉफ़्टवेयर, लॉक स्क्रीन को अनलॉक करने के लिए पुष्टि करने के तरीके जोड़ते हैं या उनमें बदलाव करते हैं और पुष्टि करने के ऐसे तरीके का इस्तेमाल कीगार्ड को अनलॉक करने के लिए किया जाएगा, लेकिन इसे सुरक्षित लॉक स्क्रीन के तौर पर नहीं माना जाएगा, तो:

  • [C-7-1] KeyguardManager.isKeyguardSecure() और KeyguardManager.isDeviceSecure(), दोनों तरीकों के लिए false को वापस लाना ज़रूरी है.
  • [C-7-2] अगर डिवाइस नीति कंट्रोलर (डीपीसी) ऐप्लिकेशन ने DevicePolicyManager.setPasswordQuality() तरीके से, PASSWORD_QUALITY_UNSPECIFIED से ज़्यादा पाबंदी वाली क्वालिटी कॉन्स्टेंट के साथ पासवर्ड क्वालिटी की नीति सेट की है, तो इसे बंद किया जाना चाहिए.
  • [C-7-3] DevicePolicyManager.setPasswordExpirationTimeout() की ओर से सेट किए गए, पासवर्ड की समयसीमा खत्म होने के टाइमर को रीसेट नहीं करना चाहिए.
  • [C-7-4] अगर ऐप्लिकेशन ने KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true)) को कॉल किया है, तो उसे कीस्टोर के ऐक्सेस की पुष्टि नहीं करनी चाहिए.

9.12. डेटा हटाना

डिवाइस में सेट किए गए सभी सिस्टम के लिए:

  • [C-0-1] उपयोगकर्ताओं को "फ़ैक्ट्री डेटा रीसेट" करने का तरीका उपलब्ध कराना ज़रूरी है.
  • [C-0-2] को उपयोगकर्ता के जनरेट किए गए सभी डेटा को मिटाना होगा. इसका मतलब है कि इन डेटा को छोड़कर, बाकी सभी डेटा:
    • सिस्टम इमेज
    • सिस्टम इमेज के लिए ज़रूरी ऑपरेटिंग सिस्टम की कोई भी फ़ाइल
  • [C-0-3] डेटा को इस तरह से मिटाना होगा कि वह NIST SP800-88 जैसे इंडस्ट्री के मानकों के मुताबिक हो.
  • [C-0-4] जब मुख्य उपयोगकर्ता का डिवाइस नीति नियंत्रक ऐप्लिकेशन, DevicePolicyManager.wipeData() एपीआई को कॉल करता है, तो ऊपर दी गई "फ़ैक्ट्री डेटा रीसेट" प्रोसेस को ट्रिगर करना ज़रूरी है.
  • यह तेज़ी से डेटा मिटाने का विकल्प दे सकता है. इससे सिर्फ़ लॉजिकल डेटा मिटाया जाता है.

9.13. सुरक्षित बूट मोड

Android में सेफ़ बूट मोड की सुविधा मिलती है. इसकी मदद से उपयोगकर्ता, ऐसे मोड में बूट अप कर सकते हैं जहां सिर्फ़ पहले से इंस्टॉल किए गए सिस्टम ऐप्लिकेशन को चलाने की अनुमति होती है. साथ ही, तीसरे पक्ष के सभी ऐप्लिकेशन बंद हो जाते हैं. इस मोड को "सेफ़ बूट मोड" कहा जाता है. इससे उपयोगकर्ता को तीसरे पक्ष के ऐसे ऐप्लिकेशन अनइंस्टॉल करने की सुविधा मिलती है जो नुकसान पहुंचा सकते हैं.

डिवाइस में सेट किए गए सिस्टम के लिए:

  • [SR] सुरक्षित बूट मोड लागू करने का सुझाव दिया जाता है.

अगर डिवाइस में सुरक्षित बूट मोड लागू किया जाता है, तो:

  • [C-1-1] उपयोगकर्ता को सेफ़ बूट मोड में जाने का विकल्प देना ज़रूरी है. ऐसा इस तरह से किया जाना चाहिए कि डिवाइस पर इंस्टॉल किए गए तीसरे पक्ष के ऐप्लिकेशन, इस प्रोसेस में रुकावट न डालें. हालांकि, अगर तीसरे पक्ष का ऐप्लिकेशन, डिवाइस नीति कंट्रोलर है और उसने UserManager.DISALLOW_SAFE_BOOT फ़्लैग को सही के तौर पर सेट किया है, तो रुकावट डाली जा सकती है.

  • [C-1-2] उपयोगकर्ता को सुरक्षित मोड में, तीसरे पक्ष के किसी भी ऐप्लिकेशन को अनइंस्टॉल करने की सुविधा मिलनी चाहिए.

  • उपयोगकर्ता को बूट मेन्यू से सुरक्षित बूट मोड में जाने का विकल्प देना चाहिए. इसके लिए, सामान्य बूट से अलग वर्कफ़्लो का इस्तेमाल करना चाहिए.

9.14. ऑटोमोटिव वाहन सिस्टम आइसोलेशन

Android Automotive डिवाइसों से यह उम्मीद की जाती है कि वे वाहन के एचएएल का इस्तेमाल करके, वाहन के ज़रूरी सबसिस्टम के साथ डेटा शेयर करें. साथ ही, CAN बस जैसे वाहन के नेटवर्क पर मैसेज भेजें और पाएं.

डेटा एक्सचेंज को सुरक्षित किया जा सकता है. इसके लिए, Android फ़्रेमवर्क लेयर के नीचे सुरक्षा से जुड़ी सुविधाएं लागू करें. इससे इन सबसिस्टम के साथ नुकसान पहुंचाने वाले या अनजाने में होने वाले इंटरैक्शन को रोका जा सकता है.

10. सॉफ़्टवेयर कंपैटिबिलिटी टेस्टिंग

डिवाइस में सेट किए गए सिस्टम के लिए, इस सेक्शन में बताए गए सभी टेस्ट पास करना ज़रूरी है.

हालांकि, ध्यान दें कि कोई भी सॉफ़्टवेयर टेस्ट पैकेज पूरी तरह से भरोसेमंद नहीं होता. इस वजह से, डिवाइस बनाने वाली कंपनियों को यह सुझाव दिया जाता है कि वे Android Open Source Project से उपलब्ध Android के रेफ़रंस और पसंदीदा वर्शन में कम से कम बदलाव करें. इससे ऐसे बग आने का जोखिम कम हो जाएगा जो डिवाइसों के साथ काम नहीं करते. इसके लिए, आपको डिवाइसों को फिर से अपडेट करना पड़ सकता है.

10.1. Compatibility Test Suite

डिवाइस में सेट किए गए सिस्टम को, Android Compatibility Test Suite (CTS) पास करना ज़रूरी है. यह Android Open Source Project से उपलब्ध है. इसके लिए, डिवाइस पर शिपिंग के लिए उपलब्ध फ़ाइनल सॉफ़्टवेयर का इस्तेमाल करना होगा. इसके अलावा, डिवाइस बनाने वाली कंपनियों को Android Open Source प्रोजेक्ट के ट्री में मौजूद रेफ़रंस इंप्लीमेंटेशन का ज़्यादा से ज़्यादा इस्तेमाल करना चाहिए. साथ ही, उन्हें यह पक्का करना चाहिए कि सीटीएस में अस्पष्टता होने पर, रेफ़रंस सोर्स कोड के किसी भी हिस्से को फिर से लागू करने पर, डिवाइस काम करता हो.

CTS को किसी असली डिवाइस पर चलाने के लिए डिज़ाइन किया गया है. किसी भी सॉफ़्टवेयर की तरह, सीटीएस में भी बग हो सकते हैं. सीटीएस का वर्शन, इस कंपैटिबिलिटी डेफ़िनिशन से अलग होगा. साथ ही, Android 8.1 के लिए सीटीएस के कई वर्शन रिलीज़ किए जा सकते हैं. डिवाइस के सॉफ़्टवेयर को पूरा करने के समय, डिवाइसों को CTS के सबसे नए वर्शन को पास करना होगा.

10.2. सीटीएस की पुष्टि करने वाला टूल

डिवाइसों पर लागू किए गए CTS Verifier के सभी मामलों को सही तरीके से लागू करना ज़रूरी है. CTS Verifier, Compatibility Test Suite में शामिल होता है. इसे किसी व्यक्ति को चलाना होता है, ताकि उन सुविधाओं की जांच की जा सके जिनकी जांच ऑटोमेटेड सिस्टम नहीं कर सकता. जैसे, कैमरे और सेंसर का सही तरीके से काम करना.

CTS Verifier में कई तरह के हार्डवेयर के लिए टेस्ट मौजूद हैं. इनमें कुछ ऐसे हार्डवेयर भी शामिल हैं जो ज़रूरी नहीं हैं. डिवाइस में मौजूद हार्डवेयर के लिए, सभी टेस्ट पास करना ज़रूरी है. उदाहरण के लिए, अगर किसी डिवाइस में ऐक्सिलरोमीटर है, तो उसे CTS Verifier में ऐक्सिलरोमीटर टेस्ट केस को सही तरीके से पूरा करना होगा. इस कंपैटबिलिटी डेफ़िनिशन डॉक्यूमेंट में, जिन सुविधाओं को 'ज़रूरी नहीं' के तौर पर मार्क किया गया है उनके टेस्ट केस छोड़े जा सकते हैं.

ऊपर बताए गए तरीके से, हर डिवाइस और हर बिल्ड पर CTS Verifier को सही तरीके से चलाना ज़रूरी है. हालांकि, कई बिल्ड एक जैसे होते हैं. इसलिए, डिवाइस बनाने वाली कंपनियों को ऐसे बिल्ड पर CTS Verifier चलाने की ज़रूरत नहीं होती जिनमें मामूली अंतर हो. खास तौर पर, डिवाइस में लागू किए गए ऐसे सिस्टम जिनमें सिर्फ़ शामिल की गई भाषाओं, ब्रैंडिंग वगैरह के आधार पर, CTS Verifier टेस्ट पास करने वाले सिस्टम से अलग हैं वे CTS Verifier टेस्ट को छोड़ सकते हैं.

11. अपडेट किया जा सकने वाला सॉफ़्टवेयर

डिवाइसों में, सिस्टम सॉफ़्टवेयर को पूरी तरह से बदलने का तरीका शामिल होना चाहिए. इस सुविधा के लिए, “लाइव” अपग्रेड करने की ज़रूरत नहीं होती. इसका मतलब है कि डिवाइस को रीस्टार्ट करना पड़ सकता है.

कोई भी तरीका इस्तेमाल किया जा सकता है. हालांकि, यह ज़रूरी है कि इससे डिवाइस पर पहले से इंस्टॉल किए गए पूरे सॉफ़्टवेयर को बदला जा सके. उदाहरण के लिए, इनमें से किसी भी तरीके से इस ज़रूरी शर्त को पूरा किया जा सकता है:

  • “ओवर-द-एयर (ओटीए)” डाउनलोड की सुविधा, जिसमें रीबूट करके ऑफ़लाइन अपडेट किया जा सकता है.
  • होस्ट पीसी से यूएसबी के ज़रिए “टेथर्ड” अपडेट.
  • “ऑफ़लाइन” अपडेट, रीबूट करके और हटाने लायक स्टोरेज डिवाइस पर मौजूद फ़ाइल से अपडेट करके किए जाते हैं.

हालांकि, अगर डिवाइस में बिना किसी शुल्क के डेटा कनेक्शन की सुविधा शामिल है, जैसे कि 802.11 या ब्लूटूथ पीएएन (पर्सनल एरिया नेटवर्क) प्रोफ़ाइल, तो इसमें रीबूट करके ऑफ़लाइन अपडेट के साथ ओटीए डाउनलोड की सुविधा होनी चाहिए.

अपडेट करने के लिए इस्तेमाल किए जाने वाले सिस्टम में, उपयोगकर्ता के डेटा को मिटाए बिना अपडेट करने की सुविधा होनी चाहिए. इसका मतलब है कि अपडेट करने के तरीके से, ऐप्लिकेशन के निजी डेटा और ऐप्लिकेशन के शेयर किए गए डेटा को सुरक्षित रखना ज़रूरी है. ध्यान दें कि अपस्ट्रीम Android सॉफ़्टवेयर में, अपडेट करने का एक ऐसा तरीका शामिल होता है जो इस ज़रूरी शर्त को पूरा करता है.

Android 6.0 और इसके बाद के वर्शन के साथ लॉन्च किए गए डिवाइसों के लिए, अपडेट करने के तरीके में यह पुष्टि करने की सुविधा होनी चाहिए कि ओटीए के बाद, सिस्टम इमेज बाइनरी के तौर पर, अनुमानित नतीजे के जैसी है. Android 5.1 से, अपस्ट्रीम Android Open Source Project में ब्लॉक-आधारित OTA लागू करने की सुविधा जोड़ी गई है. इससे इस ज़रूरी शर्त को पूरा किया जा सकता है.

साथ ही, डिवाइसों में A/B सिस्टम अपडेट की सुविधा होनी चाहिए. AOSP, बूट कंट्रोल HAL का इस्तेमाल करके इस सुविधा को लागू करता है.

अगर डिवाइस को रिलीज़ करने के बाद, उसके लागू करने में कोई गड़बड़ी मिलती है, लेकिन वह गड़बड़ी, प्रॉडक्ट के सामान्य जीवनकाल के दौरान मिलती है. साथ ही, Android Compatibility Team के साथ सलाह-मशवरा करके यह तय किया जाता है कि इस गड़बड़ी से तीसरे पक्ष के ऐप्लिकेशन पर असर पड़ेगा, तो डिवाइस को लागू करने वाले व्यक्ति या कंपनी को उस गड़बड़ी को ठीक करना होगा. इसके लिए, उसे सॉफ़्टवेयर अपडेट उपलब्ध कराना होगा. इस अपडेट को, ऊपर बताए गए तरीके के मुताबिक लागू किया जा सकता है.

Android में ऐसी सुविधाएं शामिल होती हैं जिनकी मदद से, डिवाइस के मालिक का ऐप्लिकेशन (अगर मौजूद है) सिस्टम अपडेट के इंस्टॉलेशन को कंट्रोल कर सकता है. इसे आसान बनाने के लिए, android.software.device_admin की जानकारी देने वाले डिवाइसों के लिए, सिस्टम अपडेट सबसिस्टम को SystemUpdatePolicy क्लास में बताए गए तरीके को लागू करना होगा.

12. दस्तावेज़ में हुए बदलावों का लॉग

इस रिलीज़ में, कंपैटबिलिटी डेफ़िनिशन में किए गए बदलावों की खास जानकारी के लिए:

व्यक्तियों से जुड़े सेक्शन में हुए बदलावों की खास जानकारी के लिए:

  1. शुरुआती जानकारी
  2. डिवाइस टाइप
  3. सॉफ़्टवेयर
  4. ऐप्लिकेशन पैकेजिंग
  5. मल्टीमीडिया
  6. डेवलपर टूल और विकल्प
  7. हार्डवेयर के साथ काम करने से जुड़ी जानकारी
  8. परफ़ॉर्मेंस और पावर
  9. सुरक्षा मॉडल
  10. सॉफ़्टवेयर की कंपैटिबिलिटी की जांच करना
  11. अपडेट किया जा सकने वाला सॉफ़्टवेयर
  12. दस्तावेज़ में हुए बदलावों का लॉग
  13. हमसे संपर्क करें

12.1. बदलावों का लॉग देखने के बारे में सलाह

बदलावों को इस तरह मार्क किया गया है:

  • सीडीडी
    साथ काम करने से जुड़ी ज़रूरी शर्तों में अहम बदलाव.

  • दस्तावेज़
    कॉस्मेटिक या बिल्ड से जुड़े बदलाव.

बेहतर तरीके से देखने के लिए, अपने बदलाव के लॉग वाले यूआरएल में pretty=full और no-merges यूआरएल पैरामीटर जोड़ें.

13. हमसे संपर्क करें

android-compatibility फ़ोरम में शामिल होकर, साफ़ तौर पर जानकारी माँगी जा सकती है. इसके अलावा, ऐसी कोई भी समस्या बताई जा सकती है जिसके बारे में दस्तावेज़ में जानकारी नहीं दी गई है.