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

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

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

1. परिचय

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

“MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, और “OPTIONAL” का इस्तेमाल, RFC2119 में बताए गए IETF स्टैंडर्ड के मुताबिक किया जाता है.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2. हाथ से इस्तेमाल करने की ज़रूरी शर्तें

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

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] इसमें तीसरे पक्ष के इनपुट के तरीके के संपादक (आईएमई) ऐप्लिकेशन के लिए सहायता शामिल होनी चाहिए.

नेविगेशन बटन (सेक्शन 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] ऐप्लिकेशन में डेटा बचाने वाला मोड होना चाहिए.

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

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

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

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

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

ऐप्लिकेशन का शेयर किया गया स्टोरेज (सेक्शन 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)

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

[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 Profile (AAC+)
[H-0-5] AAC ELD (बेहतर कम देरी वाला AAC)

ऑडियो को डिकोड करना (सेक्शन 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 AVC.
[H-0-2] H.265 HEVC.
[H-0-3] MPEG-4 SP.
[H-0-4] VP8.
[H-0-5] VP9.

2.2.3. सॉफ़्टवेयर

WebView के साथ काम करना (सेक्शन 3.4.1)

हैंडहेल्ड डिवाइस पर लागू करने के लिए:

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

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

हैंडहेल्ड डिवाइस पर लागू करने के लिए:

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

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

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

हैंडहेल्ड डिवाइस पर लागू करने के लिए:

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

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

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

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

डिवाइस का एडमिन ऐक्सेस (सेक्शन 3.9)

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

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

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

हैंडहेल्ड डिवाइस पर लागू करने के लिए:

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

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

हैंडहेल्ड डिवाइस पर लागू करने के लिए:

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

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

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

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

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

2.3.1. हार्डवेयर

टच न करने वाला नेविगेशन (सेक्शन 7.2.2)

टीवी डिवाइस पर लागू करने के लिए:

[T-0-1] D-pad काम करना चाहिए.

नेविगेशन बटन (सेक्शन 7.2.3)

टीवी डिवाइस पर लागू करने के लिए:

[T-0-1] होम और बैक बटन की सुविधाएं उपलब्ध कराना ज़रूरी है.
[T-0-2] फ़ोरग्राउंड ऐप्लिकेशन को, Back फ़ंक्शन (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() के लिए “सही” दिखाना ज़रूरी है.

माइक्रोफ़ोन (सेक्शन 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 Profile (AAC+)
[T-0-3] AAC ELD (बेहतर कम देरी वाला AAC)

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

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

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

H-264 (सेक्शन 5.2.2)

टीवी डिवाइस पर लागू करने के तरीके:

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

वीडियो को डिकोड करना (सेक्शन 5.3)

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

[T-0-1] H.264 AVC
[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 (सेक्शन 5.3.4)

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

[T-1-1] यह ज़रूरी है कि डिवाइस, हाई प्रोफ़ाइल लेवल 4.2 और एचडी 1080 पिक्सल (60 FPS पर) डिकोडिंग प्रोफ़ाइल के साथ काम करे.
[T-1-2] यह ज़रूरी है कि यह एचडी प्रोफ़ाइलों, दोनों के साथ वीडियो को डिकोड कर सके. इन प्रोफ़ाइलों के बारे में नीचे दी गई टेबल में बताया गया है. साथ ही, यह भी ज़रूरी है कि यह एचडीआर वीडियो को Baseline Profile, Main Profile या High Profile Level 4.2 में एन्कोड कर सके

H.265 (एचईवीसी) (सेक्शन 5.3.5)

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

[T-1-1] यह मुख्य प्रोफ़ाइल लेवल 4.1 के मुख्य टीयर के साथ काम करना चाहिए.
[T-SR] हमारा सुझाव है कि आप एचडी 1080 पिक्सल के लिए, 60 एफ़पीएस (फ़्रेम प्रति सेकंड) वाले वीडियो फ़्रेम रेट का इस्तेमाल करें.

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

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

VP8 (सेक्शन 5.3.6)

अगर टीवी डिवाइस पर VP8 कोडेक काम करता है, तो:

[T-1-1] यह एचडी 1080p60 डिकोडिंग प्रोफ़ाइल के साथ काम करना चाहिए.

अगर टीवी डिवाइस पर VP8 कोडेक और 720p काम करता है, तो:

[T-2-1] यह एचडी 720p60 डिकोडिंग प्रोफ़ाइल के साथ काम करना चाहिए.

VP9 (सेक्शन 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 के साथ काम करना (सेक्शन 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] ऐप्लिकेशन में तीसरे पक्ष की सुलभता सेवाओं का इस्तेमाल किया जा सकता है.
[T-SR] Android Television डिवाइसों पर सुलभता सेवाओं को पहले से लोड करने का सुझाव दिया जाता है. ये सेवाएं, TalkBack के ओपन सोर्स प्रोजेक्ट में बताई गई, Switch Access और TalkBack (पहले से लोड किए गए Text-to-speech इंजन के साथ काम करने वाली भाषाओं के लिए) जैसी सुलभता सेवाओं के बराबर या उनसे बेहतर होनी चाहिए.

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

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

[T-SR] हमारा सुझाव है कि आप डिवाइस पर उपलब्ध भाषाओं के साथ काम करने वाला TTS इंजन शामिल करें.
[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] ऐप्लिकेशन के स्टैंडबाय और बिजली बचाने वाले मोड से छूट पाने वाले सभी ऐप्लिकेशन, असली उपयोगकर्ता को दिखने चाहिए.
[T-0-2] ऐप्लिकेशन स्टैंडबाय और Doze पावर-सेविंग मोड की ग्लोबल सिस्टम सेटिंग के ट्रिगर करने, रखरखाव, और 'जागने' वाले एल्गोरिदम में, 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)

डिवाइस पर लागू होने की जानकारी देखें:

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

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

android.hardware.audio.output सुविधा फ़्लैग का एलान करने वाले डिवाइस इंप्लीमेंटेशन देखें:

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

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

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

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

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

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

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

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

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

2.5.1. हार्डवेयर

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

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

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

नेविगेशन बटन (सेक्शन 7.2.3)

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

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

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

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

[A-SR] हमारा सुझाव है कि आप 3-ऐक्सिस एक्सलरोमीटर शामिल करें.

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

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

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

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

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

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

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

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

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

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

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

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

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

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

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

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

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

व्हील स्पीड (सेक्शन 7.3.11.4)

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

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

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

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

[A-0-1] डिवाइस में ब्लूटूथ की सुविधा होनी चाहिए. साथ ही, यह ब्लूटूथ ले की सुविधा के साथ काम करना चाहिए.
[A-0-2] Android Automotive के लागू होने के लिए, इन ब्लूटूथ प्रोफ़ाइलों के साथ काम करना ज़रूरी है:
- Hands-Free Profile (एचएफ़पी) की मदद से फ़ोन कॉल करना.
- ऑडियो डिस्ट्रिब्यूशन प्रोफ़ाइल (A2DP) की मदद से मीडिया चलाना.
- रिमोट कंट्रोल प्रोफ़ाइल (एवीआरसीपी) की मदद से, मीडिया प्लेबैक कंट्रोल करने की सुविधा.
- फ़ोन बुक ऐक्सेस करने वाली प्रोफ़ाइल (पीबीएपी) का इस्तेमाल करके संपर्क शेयर करना.
यह Message Access Profile (एमएपी) के साथ काम करना चाहिए.

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

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

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

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

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

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

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

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

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

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

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

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

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

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

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

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

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

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

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

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

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

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

वीडियो को डिकोड करना (सेक्शन 5.3)

वाहन से जुड़े डिवाइसों पर, वीडियो को डिकोड करने की ये सुविधाएं काम करनी चाहिए:

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

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

[A-SR] H.265 HEVC

2.5.3. सॉफ़्टवेयर

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

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

WebView के साथ काम करना (सेक्शन 3.4.1)

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

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

सूचनाएं (सेक्शन 3.8.3)

Android Automotive डिवाइस को लागू करने के तरीके:

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

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

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

[A-0-1] Assist ऐक्शन को मैनेज करने के लिए, डिवाइस पर किसी असिस्टेंट को लागू करना ज़रूरी है.

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

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

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

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

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

वाहन से जुड़े डिवाइसों के लिए:

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

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

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

[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)

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

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

वाहन के सिस्टम को अलग करना (सेक्शन 9.14)

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

[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. मैनेज किए जा रहे एपीआई के साथ काम करने की सुविधा

मैनेज किया गया 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. Soft API Compatibility

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

3.2.1. अनुमतियां

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

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

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

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

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

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

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

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

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

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

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

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

डिवाइस पर लागू करने के तरीके:

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

3.2.3.5. ऐप्लिकेशन की डिफ़ॉल्ट सेटिंग

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

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

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

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

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

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

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

[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 गतिविधियां लॉन्च करने की सुविधा है और प्राइमरी और सेकंडरी डिसप्ले के android.util.DisplayMetrics अलग-अलग हैं, तो:

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

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

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

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

डिवाइस लागू करने वाले लोग ये हैं:

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

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

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

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

डिवाइस पर लागू करने के तरीके:

[C-0-1] यह एक या उससे ज़्यादा तय किए गए एबीआई के साथ काम करना चाहिए. साथ ही, Android NDK के साथ काम करने की सुविधा को लागू करना चाहिए.
[C-0-2] इसमें, स्टैंडर्ड Java नेटिव इंटरफ़ेस (JNI) सेमेंटेक्स का इस्तेमाल करके, नेटिव कोड में कॉल करने के लिए, मैनेज किए जा रहे एनवायरमेंट में चल रहे कोड के लिए सहायता शामिल होनी चाहिए.
[C-0-3] यह ज़रूरी है कि यह लाइब्रेरी, नीचे दी गई सूची में मौजूद हर ज़रूरी लाइब्रेरी के साथ सोर्स-कंपैटिबल (यानी हेडर-कंपैटिबल) और बाइनरी-कंपैटिबल (एबीआई के लिए) हो.
[C-0-4] अगर 64-बिट एबीआई काम करता है, तो 32-बिट एबीआई भी काम करना चाहिए.
[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 एबीआई मैनेजमेंट दस्तावेज़ के नए वर्शन में बताया गया है. साथ ही, इसमें 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] एपीआई लेवल 24 या उसके बाद के वर्शन को टारगेट करने वाले तीसरे पक्ष के ऐप्लिकेशन के लिए, AOSP में सिस्टम लाइब्रेरी के तौर पर लागू और उपलब्ध कराई गई किसी भी अन्य नेटिव लाइब्रेरी को एक्सपोज़ नहीं किया जाना चाहिए, क्योंकि ये लाइब्रेरी रिज़र्व हैं.
[C-0-11] libGLESv3.so लाइब्रेरी की मदद से, NDK में बताए गए सभी OpenGL ES 3.1 और Android एक्सटेंशन पैकेज फ़ंक्शन के सिंबल एक्सपोर्ट करना ज़रूरी है. ध्यान दें कि सभी सिंबल मौजूद होने चाहिए. हालांकि, सेक्शन 7.1.4.1 में, इस बारे में ज़्यादा जानकारी दी गई है कि हर फ़ंक्शन को पूरी तरह से लागू करने के लिए, क्या ज़रूरी है.
[C-0-12] आपको Vulkan 1.0 के मुख्य फ़ंक्शन सिंबल के साथ-साथ, libvulkan.so लाइब्रेरी की मदद से VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1, और VK_KHR_get_physical_device_properties2 एक्सटेंशन के लिए फ़ंक्शन सिंबल एक्सपोर्ट करने होंगे. ध्यान दें कि सभी सिंबल मौजूद होने चाहिए. हालांकि, सेक्शन 7.1.4.2 में, इस बारे में ज़्यादा जानकारी दी गई है कि हर फ़ंक्शन को कब पूरी तरह से लागू किया जाना चाहिए.
इसे अपस्ट्रीम Android Open Source Project में मौजूद सोर्स कोड और हेडर फ़ाइलों का इस्तेमाल करके बनाया जाना चाहिए

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

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

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

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

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

[C-2-1] /proc/cpuinfo में ये लाइनें शामिल करनी ज़रूरी हैं, ताकि 32-बिट ARM ऐप्लिकेशन इसे पढ़ सकें. इससे यह पक्का किया जा सकेगा कि Android NDK के लेगसी वर्शन का इस्तेमाल करके बनाए गए ऐप्लिकेशन के साथ यह काम करता है.
- Features:, इसके बाद डिवाइस पर काम करने वाली ARMv7 सीपीयू की वैकल्पिक सुविधाओं की सूची दी गई है.
- CPU architecture: के बाद, एक पूर्णांक होता है. इससे पता चलता है कि डिवाइस पर ARM का कौनसा आर्किटेक्चर काम करता है (उदाहरण के लिए, "8" के लिए ARMv8 डिवाइसों).
64-बिट ARM या नॉन-ARM ऐप्लिकेशन से पढ़े जाने पर, /proc/cpuinfo में बदलाव नहीं होना चाहिए.

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

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

अगर डिवाइस पर 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] वेबव्यू की रिपोर्ट की गई यूज़र एजेंट स्ट्रिंग इस फ़ॉर्मैट में होनी चाहिए:

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

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

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

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

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

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

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

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

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

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

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

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

3.7. रनटाइम के साथ काम करने की सुविधा

डिवाइस पर लागू करने के तरीके:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.2. विजेट

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

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

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

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

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

3.8.3. सूचनाएं

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

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

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

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

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

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

3.8.4. खोजें

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

अगर डिवाइस में लागू किए गए IME में कोई 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() API के ज़रिए, मौजूदा पीआईपी ऐक्टिविटी के मुताबिक, अपने SystemUI में कार्रवाइयों को दिखाना ज़रूरी है.
[C-3-3] आसपेक्ट रेशियो 1:2.39 से ज़्यादा या उसके बराबर और 2.39:1 से कम या उसके बराबर होना चाहिए. इसकी जानकारी, setAspectRatio() एपीआई की मदद से, पीआईपी गतिविधि से मिलती है.
[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 डिवाइस एडमिनिस्ट्रेशन एपीआई की मदद से, पासवर्ड की नीतियों को लागू करना या डिवाइस का डेटा रिमोट तौर पर मिटाना.

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

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

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

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

अगर डिवाइस पर android.software.managed_users लागू किया जाता है, तो:

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

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

अगर डिवाइस पर android.software.managed_users लागू किया जाता है, तो:

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

3.10. सुलभता

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

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

[C-1-1] accessibility APIs SDK के दस्तावेज़ में बताए गए तरीके के मुताबिक, 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-1-1] यह Android TTS फ़्रेमवर्क के एपीआई के साथ काम करना चाहिए.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.12.1.2. नेविगेशन

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

[C-1-1] Android Television डिवाइस के इनपुट डिवाइस (जैसे, रिमोट कंट्रोल, रिमोट कंट्रोल ऐप्लिकेशन या गेम कंट्रोलर) पर D-पैड, बैक, और होम बटन की मदद से, इन फ़ंक्शन के लिए नेविगेशन की अनुमति होनी चाहिए:
- टीवी चैनल बदलना
- ईपीजी खोलना
- तीसरे पक्ष के TIF-आधारित इनपुट को कॉन्फ़िगर और ट्यून करना (अगर वे इनपुट काम करते हैं)
- सेटिंग मेन्यू खोलना
CEC की मदद से, मुख्य इवेंट को HDMI इनपुट पर भेजना चाहिए.

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

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

3.12.1.4. टाइम शिफ़्ट करना

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

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

3.12.1.5. टीवी रिकॉर्डिंग

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

[SR] हमारा सुझाव है कि आप टीवी रिकॉर्डिंग की सुविधा जोड़ें.
अगर टीवी इनपुट रिकॉर्डिंग की सुविधा देता है और किसी प्रोग्राम को रिकॉर्ड करने पर पाबंदी नहीं है, तो ईपीजी में किसी प्रोग्राम को रिकॉर्ड करने का तरीका बताया जा सकता है.

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

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

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

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

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

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

[C-1-1] MediaItem आइकॉन और सूचना के आइकॉन बिना किसी बदलाव के दिखाए जाने चाहिए.
[C-1-2] MediaSession में बताए गए आइटम को उसी तरह दिखाना चाहिए. जैसे, मेटाडेटा, आइकॉन, इमेज.
[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 बाइटकोड या RenderScript बाइटकोड फ़ॉर्मैट को इस तरह से एक्सटेंड़ नहीं किया जाना चाहिए कि वे फ़ाइलें, काम करने वाले अन्य डिवाइसों पर सही तरीके से इंस्टॉल और काम न कर पाएं.
[C-0-4] पैकेज के लिए, मौजूदा "इंस्टॉलर ऑफ़ रिकॉर्ड" के अलावा किसी दूसरे ऐप्लिकेशन को, बिना किसी सूचना के ऐप्लिकेशन को अनइंस्टॉल करने की अनुमति नहीं देनी चाहिए. इस बारे में DELETE_PACKAGE अनुमति के लिए SDK टूल में बताया गया है. हालांकि, 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 में रिपोर्ट की गई प्रोफ़ाइलें शामिल हैं.

डिवाइस पर लागू करने के तरीके:

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

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

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

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

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

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

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

[C-1-1] PCM/WAVE

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

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

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

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

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

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

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

फ़ॉर्मैट/कोडेक	जानकारी	इस्तेमाल किए जा सकने वाले फ़ाइल टाइप/कंटेनर फ़ॉर्मैट
MPEG-4 AAC प्रोफ़ाइल (AAC LC)	8 से 48 किलोहर्ट्ज़ के स्टैंडर्ड सैंपलिंग रेट वाले मोनो/स्टीरियो/5.0/5.1 कॉन्टेंट के साथ काम करता है.	3GPP (.3gp) MPEG-4 (.mp4, .m4a) ADTS रॉ AAC (.aac, ADIF काम नहीं करता) एमपीईजी-टीएस (.ts, इसमें आगे-पीछे नहीं जाया जा सकता)
MPEG-4 HE AAC Profile (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	16 किलोहर्ट्ज़ पर सैंपल किए गए 6.60 केबीपीएस से 23.85 केबीपीएस तक के नौ रेट
FLAC	मोनो/स्टीरियो (मल्टीचैनल नहीं). सैंपल रेट 48 किलोहर्ट्ज़ तक (हालांकि, 44.1 किलोहर्ट्ज़ आउटपुट वाले डिवाइसों पर 44.1 किलोहर्ट्ज़ तक का सैंपल रेट इस्तेमाल करने का सुझाव दिया जाता है, क्योंकि 48 से 44.1 किलोहर्ट्ज़ के डाउनसैंपलर में लो-पास फ़िल्टर शामिल नहीं होता). 16-बिट का सुझाव दिया जाता है; 24-बिट के लिए कोई डिटर इस्तेमाल नहीं किया जाता.	सिर्फ़ FLAC (.flac)
MP3	मोनो/स्टीरियो 8-320 केबीपीएस कॉन्स्टेंट (सीबीआर) या वैरिएबल बिटरेट (वीबीआर)	MP3 (.mp3)
MIDI	एमआईडीआई टाइप 0 और 1. डीएलएस का वर्शन 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-बिट लीनियर पीसीएम (हार्डवेयर की सीमा तक रेट). डिवाइसों में, रॉ PCM रिकॉर्डिंग के लिए 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] BMP
[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 AVC	ज़्यादा जानकारी के लिए, सेक्शन 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 देखें	WebM (.webm) Matroska (.mkv)
VP9	ज़्यादा जानकारी के लिए, सेक्शन 5.3 देखें	WebM (.webm) Matroska (.mkv)

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

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

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

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

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

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

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

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

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

5.2.1. H.263

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

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

5.2.2. H-264

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

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

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

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

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

5.2.3. VP8

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

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

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

अगर डिवाइस में 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] मुख्य प्रोफ़ाइल के हाई लेवल के साथ काम करना चाहिए.

5.3.2. H.263

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

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

5.3.3. MPEG-4

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

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

5.3.4. H.264

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

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

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

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

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

5.3.5. H.265 (HEVC)

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

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

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

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

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

5.3.6. VP8

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

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

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

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

5.3.7. VP9

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

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

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

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

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

5.4.1. रॉ ऑडियो कैप्चर

अगर डिवाइस पर android.hardware.microphone लागू किया जाता है, तो:

[C-1-1] यह ज़रूरी है कि ऐप्लिकेशन, रॉ ऑडियो कॉन्टेंट को इन विशेषताओं के साथ कैप्चर कर सके:
फ़ॉर्मैट: लीनियर पीसीएम, 16-बिट
सैंपलिंग रेट: 8000, 11025, 16000, 44100 हर्ट्ज़
चैनल: मोनो
[C-1-2] अप-सैंपलिंग के बिना, ऊपर दिए गए सैंपल रेट पर कैप्चर करना ज़रूरी है.
[C-1-3] ऊपर दी गई सैंपल रेट को डाउन-सैंपलिंग की मदद से कैप्चर करने पर, इसमें सही ऐंटी-ऐलिऐसिंग फ़िल्टर शामिल होना चाहिए.
यह एएम रेडियो और डीवीडी क्वालिटी में रॉ ऑडियो कॉन्टेंट को कैप्चर करने की अनुमति देता है. इसका मतलब है कि यह इन सुविधाओं के साथ काम करता है:
फ़ॉर्मैट: लीनियर पीसीएम, 16-बिट
सैंपलिंग रेट: 22050, 48000 हर्ट्ज़
चैनल: स्टीरियो

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

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

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

अगर डिवाइस पर android.hardware.microphone लागू किया जाता है, तो:

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

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

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

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

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

अगर डिवाइस पर लागू किए गए एपीआई, android.hardware.audio.output और android.hardware.microphone, दोनों का एलान करते हैं, तो:

[C-1-1] REMOTE_SUBMIX ऑडियो सोर्स को सही तरीके से लागू करना ज़रूरी है, ताकि जब कोई ऐप्लिकेशन इस ऑडियो सोर्स से रिकॉर्ड करने के लिए android.media.AudioRecord 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. ऑडियो आउटपुट का वॉल्यूम

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

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

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

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

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

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

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

[SR] कोल्ड आउटपुट में लगने वाला समय 100 मिलीसेकंड या उससे कम
[SR] आउटपुट में लगने वाला समय 45 मिलीसेकंड या उससे कम हो
[SR] कूल आउटपुट जटर को कम करना

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

[SR] हमारा सुझाव है कि android.hardware.audio.low_latency सुविधा फ़्लैग का एलान करके, कम इंतज़ार वाले ऑडियो की शिकायत करें.
[SR] हमारा सुझाव है कि आप AAudio API की मदद से, कम इंतज़ार वाले ऑडियो की ज़रूरी शर्तें भी पूरी करें.

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

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

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

[SR] इनपुट के लिए, कोल्ड स्टार्ट में लगने वाला समय 100 मिलीसेकंड या उससे कम हो
[SR] इनपुट में लगातार 30 मिलीसेकंड या उससे कम की देरी
[SR] लगातार 50 मिलीसेकंड या उससे कम का राउंड-ट्रिप लेटेंसी
[SR] कोल्ड इनपुट जटर को कम करना

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

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

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

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

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

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

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

रेफ़रंस

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

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

ISO 13818

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

H264 AVC
MPEG-4 SP
MPEG-2

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

ऑडियो कोडेक:

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

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

ISO 13818-7

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

WebVTT

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

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

5.8. Secure Media

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

[C-1-1] Display.FLAG_SECURE के लिए सहायता देने का एलान करना ज़रूरी है.

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

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

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

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

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

अगर डिवाइस पर android.content.pm.PackageManager क्लास की मदद से android.software.midi सुविधा काम करती है, तो:

[C-1-1] एमआईडीआई की सुविधा वाले सभी हार्डवेयर ट्रांसपोर्ट पर एमआईडीआई की सुविधा काम करनी चाहिए. इसके लिए, वे सामान्य गैर-एमआईडीआई कनेक्टिविटी उपलब्ध कराते हैं. ये ट्रांसपोर्ट ये हैं:
- यूएसबी होस्ट मोड, सेक्शन 7.7
- यूएसबी पेरिफ़रल मोड, सेक्शन 7.7
- ब्लूटूथ LE पर MIDI, मुख्य भूमिका में काम कर रहा है, सेक्शन 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 PCM बफ़र क्यू एपीआई का इस्तेमाल करके, इंतज़ार के समय और यूएसबी ऑडियो की ज़रूरी शर्तों को पूरा करना ज़रूरी है.
[SR] हमारा सुझाव है कि ऑडियो चालू होने और सीपीयू लोड में बदलाव होने के दौरान, सीपीयू की परफ़ॉर्मेंस को एक जैसा बनाए रखें. इसकी जांच, SimpleSynth के कमिट 1bd6391 का इस्तेमाल करके की जानी चाहिए. SimpleSynth ऐप्लिकेशन को इन पैरामीटर के साथ चलाया जाना चाहिए और 10 मिनट के बाद, ऐप्लिकेशन को बिना किसी रुकावट के चलाया जाना चाहिए:
- वर्क साइकल: 2,00,000
- वैरिएबल लोड: चालू (यह हर दो सेकंड में, वर्क साइकल की वैल्यू के 100% और 10% के बीच स्विच करेगा. इसे सीपीयू गवर्नर के व्यवहार की जांच करने के लिए डिज़ाइन किया गया है)
- स्टेबलाइज़ किया गया लोड: बंद
ऑडियो क्लॉक की गड़बड़ी और स्टैंडर्ड टाइम के मुकाबले ड्रिफ़्ट को कम करना चाहिए.
जब दोनों चालू हों, तो सीपीयू CLOCK_MONOTONIC के मुकाबले ऑडियो क्लॉक ड्रिफ़्ट को कम करना चाहिए.
डिवाइस पर मौजूद ट्रांसड्यूसर की मदद से, ऑडियो के इंतज़ार का समय कम होना चाहिए.
यूएसबी डिजिटल ऑडियो पर ऑडियो के इंतज़ार का समय कम होना चाहिए.
सभी पाथ पर ऑडियो के इंतज़ार का समय मेज़र करना चाहिए.
ऑडियो बफ़र पूरा होने के कॉलबैक एंट्री के समय में जिटर को कम करना चाहिए, क्योंकि इससे कॉलबैक के ज़रिए सीपीयू की पूरी बैंडविड्थ के इस्तेमाल किए जा सकने वाले प्रतिशत पर असर पड़ता है.
सामान्य इस्तेमाल के दौरान, रिपोर्ट किए गए इंतज़ार के समय में, ऑडियो के आउटपुट या इनपुट में कोई कमी नहीं होनी चाहिए.
अलग-अलग चैनलों के बीच इंतज़ार का समय एक जैसा होना चाहिए.
सभी ट्रांसपोर्ट पर, एमआईडीआई के इंतज़ार का औसत समय कम होना चाहिए.
सभी ट्रांसपोर्ट पर लोड (जटर) के दौरान, एमआईडीआई के इंतज़ार का समय कम से कम होना चाहिए.
सभी ट्रांसपोर्ट के लिए, सटीक एमआईडीआई टाइमस्टैंप देने चाहिए.
डिवाइस पर मौजूद ट्रांसड्यूसर के लिए, ऑडियो सिग्नल के नॉइज़ को कम करना चाहिए. इसमें कोल्ड स्टार्ट के तुरंत बाद की अवधि भी शामिल है.
जब दोनों एंड-पॉइंट चालू हों, तो इनके इनपुट और आउटपुट साइड के बीच ऑडियो क्लॉक में कोई अंतर नहीं होना चाहिए. मिलते-जुलते एंड-पॉइंट के उदाहरणों में, डिवाइस पर मौजूद माइक्रोफ़ोन और स्पीकर या ऑडियो जैक इनपुट और आउटपुट शामिल हैं.
जब दोनों एंड-पॉइंट चालू हों, तब एक ही थ्रेड पर इनपुट और आउटपुट साइड के लिए, ऑडियो बफ़र पूरा होने के कॉलबैक को मैनेज करना चाहिए. साथ ही, इनपुट कॉलबैक से वापस आने के तुरंत बाद आउटपुट कॉलबैक डालना चाहिए. अगर एक ही थ्रेड पर कॉलबैक मैनेज नहीं किए जा सकते, तो इनपुट कॉलबैक डालने के कुछ समय बाद आउटपुट कॉलबैक डालें. इससे ऐप्लिकेशन को इनपुट और आउटपुट साइड के लिए एक जैसा समय तय करने में मदद मिलेगी.
यह एंड-पॉइंट के इनपुट और आउटपुट साइड के लिए, एचएएल ऑडियो बफ़रिंग के बीच फ़ेज़ के अंतर को कम करेगा.
टच में लगने वाले समय को कम करना चाहिए.
लोड (जटर) के दौरान, टच रिस्पॉन्स में लगने वाले समय में होने वाले बदलाव को कम करना चाहिए.

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

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

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

[SR] हमारा सुझाव है कि AAudio API की मदद से भी, इन ज़रूरी शर्तों को पूरा करें.

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

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

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

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

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

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

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

6.1. डेवलपर टूल

डिवाइस पर लागू करने के तरीके:

[C-0-1] यह ज़रूरी है कि यह Android SDK में दिए गए Android डेवलपर टूल के साथ काम करे.
Android डीबग ब्रिज (adb)
- [C-0-2] यह ज़रूरी है कि यह Android SDK में बताए गए सभी adb फ़ंक्शन के साथ काम करे. इनमें dumpsys भी शामिल है.
- [C-0-3] dumpsys की मदद से लॉग किए गए डिवाइस के सिस्टम इवेंट (batterystats , diskstats, fingerprint, graphicsstats, netstats, notification, procstats) के फ़ॉर्मैट या कॉन्टेंट में बदलाव नहीं किया जाना चाहिए.
- [C-0-4] डिवाइस पर adb डेमन, डिफ़ॉल्ट रूप से बंद होना चाहिए. साथ ही, Android Debug Bridge को चालू करने के लिए, उपयोगकर्ता के पास कोई ऐसा तरीका होना चाहिए जिसका इस्तेमाल किया जा सके.
- [C-0-5] यह ज़रूरी है कि यह सुरक्षित adb के साथ काम करे. Android में सुरक्षित adb के लिए सहायता शामिल है. Secure adb, पुष्टि किए गए होस्ट पर adb को चालू करता है.
- [C-0-6] होस्ट मशीन से adb को कनेक्ट करने की सुविधा देने वाला कोई तरीका ज़रूर उपलब्ध कराएं. उदाहरण के लिए:
  - जिन डिवाइसों में यूएसबी पोर्ट नहीं है और जो पेरिफ़रल मोड के साथ काम करते हैं उन्हें लोकल-एरिया नेटवर्क (जैसे, ईथरनेट या वाई-फ़ाई) के ज़रिए adb लागू करना होगा.
  - Windows 7, 9, और 10 के लिए ड्राइवर उपलब्ध कराना ज़रूरी है, ताकि डेवलपर adb प्रोटोकॉल का इस्तेमाल करके डिवाइस से कनेक्ट कर सकें.
Dalvik डीबग मॉनिटर सेवा (ddms)
- [C-0-7] Android SDK टूल में बताई गई सभी ddms सुविधाओं के साथ काम करना चाहिए. ddms, adb का इस्तेमाल करता है. इसलिए, ddms के लिए सहायता डिफ़ॉल्ट रूप से बंद होनी चाहिए. हालांकि, जब भी उपयोगकर्ता ऊपर बताए गए तरीके से Android Debug Bridge को चालू करता है, तब ddms के लिए सहायता चालू होनी चाहिए.
Monkey
- [C-0-8] Monkey फ़्रेमवर्क को शामिल करना ज़रूरी है और इसे ऐप्लिकेशन के इस्तेमाल के लिए उपलब्ध कराना होगा.
SysTrace
- [C-0-9] Android SDK में बताए गए तरीके से, systrace टूल के साथ काम करना चाहिए. Systrace की सुविधा डिफ़ॉल्ट रूप से बंद होनी चाहिए. साथ ही, Systrace को चालू करने के लिए, उपयोगकर्ता के पास कोई ऐसा तरीका होना चाहिए जिसका इस्तेमाल किया जा सके.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[C-0-1] डिवाइस पर लागू किए गए Configuration.screenLayout के लिए, Android SDK टूल के दस्तावेज़ में बताए गए सही लेआउट साइज़ की जानकारी देनी ज़रूरी है. खास तौर पर, डिवाइस के लागू होने पर, डेंसिटी-इंडिपेंडेंट पिक्सल (dp) के सही लॉजिकल स्क्रीन डाइमेंशन की जानकारी देनी होगी. ये डाइमेंशन नीचे दिए गए हैं:
- जिन डिवाइसों में 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 एपीआई और कॉन्फ़िगरेशन एपीआई के ज़रिए दी गई ऊंचाई और चौड़ाई की वैल्यू से ली जा सकती है. यह वैल्यू इन ज़रूरी शर्तों को पूरा करनी चाहिए:

[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 डीपीआई (tvdpi)
- 240 डीपीआई (एचडीपीआई)
- 260 डीपीआई (260dpi)
- 280 डीपीआई (280dpi)
- 300 डीपीआई (300dpi)
- 320 डीपीआई (xhdpi)
- 340 डीपीआई (340dpi)
- 360 डीपीआई (360dpi)
- 400 डीपीआई (400dpi)
- 420 डीपीआई (420dpi)
- 480 डीपीआई (xxhdpi)
- 560 डीपीआई (560dpi)
- 640 डीपीआई (xxxhdpi)
डिवाइस के लागू होने पर, Android फ़्रेमवर्क की स्टैंडर्ड डेंसिटी तय की जानी चाहिए, जो संख्या के हिसाब से स्क्रीन की फ़िज़िकल डेंसिटी के सबसे करीब हो. हालांकि, ऐसा तब तक नहीं किया जाना चाहिए, जब तक कि लॉजिकल डेंसिटी, रिपोर्ट की गई स्क्रीन के साइज़ को काम करने वाले सबसे छोटे साइज़ से कम न कर दे. अगर Android फ़्रेमवर्क की स्टैंडर्ड सघनता, स्क्रीन के फ़िज़िकल सघनता के सबसे करीब होती है, तो उस स्क्रीन का साइज़, स्क्रीन के सबसे छोटे साइज़ (320 dp की चौड़ाई) से कम होता है. ऐसे में, Android फ़्रेमवर्क की डेंसिटी के हिसाब से, डिवाइस को लागू करने की प्रोसेस के अगले सबसे कम स्टैंडर्ड Android फ़्रेमवर्क की सघनता रिपोर्ट की जानी चाहिए.

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

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

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

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

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

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

[C-2-1] एमुलेट किए गए डिफ़ॉल्ट view.Display के लिए, android.util.DisplayMetrics API में तय की गई सभी डिसप्ले मेट्रिक के लिए सही वैल्यू रिपोर्ट करनी चाहिए.

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 एक्सटेंशन पैक के सभी वर्शन के साथ काम करे.

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

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

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

[C-6-1] यह EGL_ANDROID_front_buffer_auto_refresh एक्सटेंशन के साथ भी काम करना चाहिए.

7.1.4.2 Vulkan

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

अगर डिवाइस पर OpenGL ES 3.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] ऐप्लिकेशन पैकेज की नेटिव लाइब्रेरी डायरेक्ट्री में, libVkLayer*.so नाम की नेटिव लाइब्रेरी में मौजूद लेयर की सूची बनाना ज़रूरी है. इसके लिए, Vulkan नेटिव एपीआई vkEnumerateInstanceLayerProperties() और 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 में “कंपैटिबिलिटी मोड” की सुविधा होती है. इसमें फ़्रेमवर्क, स्क्रीन साइज़ के हिसाब से 'सामान्य' (320dp चौड़ाई) मोड में काम करता है. इससे उन लेगसी ऐप्लिकेशन को फ़ायदा मिलता है जिन्हें Android के पुराने वर्शन के लिए डेवलप नहीं किया गया था. ये ऐसे वर्शन हैं जो स्क्रीन साइज़ के हिसाब से काम करने की सुविधा से पहले के हैं.

7.1.6. स्क्रीन की टेक्नोलॉजी

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

डिवाइस पर लागू करने के तरीके:

[C-0-1] यह ज़रूरी है कि डिसप्ले, 16-बिट कलर ग्राफ़िक को रेंडर कर सके.
यह 24-बिट कलर ग्राफ़िक्स वाले डिसप्ले के साथ काम करना चाहिए.
[C-0-2] ऐनिमेशन रेंडर करने वाले डिसप्ले के साथ काम करना चाहिए.
[C-0-3] डिसप्ले टेक्नोलॉजी का इस्तेमाल करना ज़रूरी है, जिसका पिक्सल आसपेक्ट रेशियो (PAR) 0.9 से 1.15 के बीच हो. इसका मतलब है कि पिक्सल का आसपेक्ट रेशियो, स्क्वेयर (1.0) के आस-पास होना चाहिए. इसमें 10 से 15% तक का अंतर हो सकता है.

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

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

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

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

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

डिवाइस पर लागू करने के तरीके:

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

7.2.1. कीबोर्ड

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

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

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

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

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

डिवाइस पर लागू करने के तरीके:

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

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

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

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

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

[C-0-1] आपको उपयोगकर्ताओं को ऐसे इंस्टॉल किए गए ऐप्लिकेशन लॉन्च करने की सुविधा देनी होगी जिनमें <intent-filter> गतिविधि, ACTION=MAIN और CATEGORY=LAUNCHER या CATEGORY=LEANBACK_LAUNCHER के साथ सेट हो. यह सुविधा, टेलिविज़न डिवाइस पर लागू की जानी चाहिए. होम फ़ंक्शन, इस उपयोगकर्ता के लिए उपलब्ध सुविधा के तौर पर काम करना चाहिए.
हाल ही में इस्तेमाल किए गए आइटम और 'वापस जाएं' फ़ंक्शन के लिए बटन होने चाहिए.

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

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

डिवाइस पर लागू करने के तरीके:

[SR] को मेन्यू फ़ंक्शन के लिए इनपुट मैकेनिज्म न देने का सुझाव दिया जाता है, क्योंकि Android 4.0 के बाद से इसे ऐक्शन बार के पक्ष में बंद कर दिया गया है.

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

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

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

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

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

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

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

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

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

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

1 KeyEvent

2 ऊपर बताए गए एचआईडी के इस्तेमाल की जानकारी, गेम पैड सीए (0x01 0x0005) में दी जानी चाहिए.

3 इस इस्तेमाल के लिए, लॉजिकल मिनिमम 0, लॉजिकल मैक्सिमम 7, फ़िज़िकल मिनिमम 0, फ़िज़िकल मैक्सिमम 315, यूनिट डिग्री में, और रिपोर्ट साइज़ 4 होना चाहिए. लॉजिकल वैल्यू को वर्टिकल ऐक्सिस से दूर, घड़ी की सुई के घूमने की दिशा में रोटेशन के तौर पर तय किया जाता है. उदाहरण के लिए, लॉजिकल वैल्यू 0 का मतलब है कि कोई रोटेशन नहीं हुआ है और अप बटन दबाया गया है. वहीं, लॉजिकल वैल्यू 1 का मतलब है कि 45 डिग्री का रोटेशन हुआ है और अप और लेफ़्ट बटन, दोनों दबाए गए हैं.

4 MotionEvent

ऐनलॉग कंट्रोल¹	एचआईडी का इस्तेमाल	Android बटन
लेफ़्ट ट्रिगर	0x02 0x00C5	AXIS_LTRIGGER
राइट ट्रिगर	0x02 0x00C4	AXIS_RTRIGGER
लेफ़्ट जॉयस्टिक	0x01 0x0030 0x01 0x0031	AXIS_X AXIS_Y
राइट जॉयस्टिक	0x01 0x0032 0x01 0x0035	AXIS_Z AXIS_RZ

एक MotionEvent

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

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

7.3. सेंसर

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

डिवाइस पर लागू करने के तरीके:

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

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

[C-1-1] Android SDK टूल के दस्तावेज़ में बताए गए हर सेंसर टाइप के लिए, सभी सेंसर मेज़रमेंट की रिपोर्ट देनी ज़रूरी है. इसके लिए, इंटरनैशनल सिस्टम ऑफ़ यूनिट (मेट्रिक) की सही वैल्यू का इस्तेमाल करना होगा.
[C-1-2] सेंसर डेटा को 100 मिलीसेकंड से ज़्यादा के इंतज़ार के साथ रिपोर्ट करना ज़रूरी है
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 के ओपन सोर्स दस्तावेज़ों के व्यवहार को आधिकारिक माना जाना चाहिए.

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

डिवाइस पर लागू करने के तरीके:

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

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

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

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

अगर डिवाइस में तीन ऐक्सिस वाला ऐक्सीलरॉमीटर और 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-ऐक्सिस मैग्नेटोमीटर (कंपास) शामिल होना चाहिए.

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

[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 एमडब्ल्यू से कम ऊर्जा का इस्तेमाल करता है.

7.3.3. जीपीएस

डिवाइस पर लागू करने के तरीके:

इसमें जीपीएस/जीएनएसएस रिसीवर शामिल होना चाहिए.

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

[C-1-1] LocationManager#requestLocationUpdate के ज़रिए अनुरोध किए जाने पर, जगह की जानकारी के आउटपुट की दर कम से कम 1 हर्ट्ज़ होनी चाहिए.
[C-1-2] यह ज़रूरी है कि डिवाइस, 0.5 एमबीपीएस या इससे ज़्यादा डेटा स्पीड वाले इंटरनेट कनेक्शन से कनेक्ट होने पर, खुले आसमान वाली जगहों (जहां सिग्नल बेहतर हों, मल्टीपाथ की समस्या न हो, और एचडीओपी < 2 हो) पर 10 सेकंड (पहले फ़िक्स में लगने वाला कम समय) में जगह की जानकारी दे सके. आम तौर पर, इस ज़रूरी शर्त को पूरा करने के लिए, असिस्टेड या अनुमानित जीपीएस/जीएनएसएस तकनीक का इस्तेमाल किया जाता है. इससे जीपीएस/जीएनएसएस लॉक-ऑन समय कम हो जाता है. असिस्टेंस डेटा में, रेफ़रंस टाइम, रेफ़रंस लोकेशन, और सैटलाइट एफ़ेमेरिस/क्लॉक शामिल होते हैं.
- [SR] जगह की जानकारी का हिसाब लगाने के बाद, हमारा सुझाव है कि डिवाइस खुले आसमान में, जगह की जानकारी के अनुरोधों को फिर से शुरू करने के 10 सेकंड के अंदर, जगह की जानकारी का पता लगा ले. यह सुझाव, जगह की जानकारी का हिसाब लगाने के एक घंटे बाद तक दिया जाता है. भले ही, इसके बाद का अनुरोध, डेटा कनेक्शन के बिना और/या पावर साइकल के बाद किया गया हो.
खुले आसमान में जगह की जानकारी तय करने के बाद, जब विमान एक जगह पर हो या 1 मीटर प्रति सेकंड स्क्वेयर से कम की रफ़्तार से आगे बढ़ रहा हो, तो:
- [C-1-3] यह ज़रूरी है कि डिवाइस, कम से कम 95% समय तक, जगह की जानकारी 20 मीटर के अंदर और गति की जानकारी 0.5 मीटर प्रति सेकंड के अंदर दे सके.
- [C-1-4] एक ही कॉन्स्टेलेशन के कम से कम आठ सैटलाइट को GnssStatus.Callback के ज़रिए एक साथ ट्रैक और रिपोर्ट करना ज़रूरी है.
- एक साथ कम से कम 24 सैटलाइट को ट्रैक करने की सुविधा होनी चाहिए. ये सैटलाइट, अलग-अलग कॉन्स्टेलेशन (जैसे, जीपीएस + कम से कम एक Glonass, Beidou, Galileo) से होने चाहिए.
- [C-1-5] टेस्ट एपीआई ‘getGnssYearOfHardware’ की मदद से, जीएनएसएस टेक्नोलॉजी जनरेशन की जानकारी देना ज़रूरी है.
- [SR] आपातकालीन फ़ोन कॉल के दौरान, सामान्य जीपीएस/जीएनएसएस जगह की जानकारी के आउटपुट डिलीवर करना जारी रखें.
- [SR] ट्रैक किए गए सभी कॉन्स्टलेशन (जैसा कि GnssStatus मैसेज में बताया गया है) से मिले जीएनएसएस मेज़रमेंट की रिपोर्ट करें. हालांकि, एसबीएएस को इसमें शामिल न करें.
- [SR] रिपोर्ट में एजीसी और जीएनएसएस मेज़रमेंट की फ़्रीक्वेंसी शामिल करें.
- [SR] हर जीपीएस लोकेशन के हिस्से के तौर पर, सटीक जानकारी के सभी अनुमान (इनमें दिशा, स्पीड, और वर्टिकल शामिल हैं) की रिपोर्ट करें.
- [SR] को Test API LocationManager.getGnssYearOfHardware() की मदद से, "2016" या "2017" साल की रिपोर्टिंग करने वाले डिवाइसों के लिए, ज़रूरी शर्तों को पूरा करने का ज़रूर सुझाव दिया जाता है.

अगर डिवाइस में GPS/GNSS रिसीवर शामिल है और android.hardware.location.gps सुविधा फ़्लैग के ज़रिए ऐप्लिकेशन को इसकी क्षमता की जानकारी दी जाती है और LocationManager.getGnssYearOfHardware() टेस्ट एपीआई, साल "2016" या उसके बाद का वर्शन रिपोर्ट करता है, तो:

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

अगर डिवाइस में GPS/GNSS रिसीवर शामिल है और android.hardware.location.gps सुविधा फ़्लैग के ज़रिए ऐप्लिकेशन को इसकी जानकारी दी जाती है और LocationManager.getGnssYearOfHardware() टेस्ट एपीआई, साल "2017" या उसके बाद का वर्शन दिखाता है, तो:

[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] हर हर्ट्ज़ (हर हर्ट्ज़ में वैरिएंस या rad^2 / s) के लिए, वैरिएंस 1e-7 rad^2 / s^2 से ज़्यादा नहीं होना चाहिए. वैरिएंस को सैंपलिंग रेट के हिसाब से बदलने की अनुमति है, लेकिन यह वैल्यू से ज़्यादा नहीं होना चाहिए. दूसरे शब्दों में, अगर 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] सटीक जानकारी देने के लिए, 1 बिट या उससे ज़्यादा की जानकारी होनी चाहिए.

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

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

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

अगर डिवाइस पर android.hardware.sensor.hifi_sensors लागू किया जाता है, तो:

[C-2-1] इसमें TYPE_ACCELEROMETER सेंसर होना चाहिए, जो:
- मेज़रमेंट की सीमा कम से कम -8g और +8g के बीच होनी चाहिए.
- इसका मेज़रमेंट रिज़ॉल्यूशन कम से कम 1024 LSB/G होना चाहिए.
- मेज़रमेंट फ़्रीक्वेंसी कम से कम 12.5 हर्ट्ज़ या उससे कम होनी चाहिए.
- मेज़रमेंट की फ़्रीक्वेंसी 400 हर्ट्ज़ या इससे ज़्यादा होनी चाहिए.
- मेज़रमेंट नॉइज़ 400 uG/√Hz से ज़्यादा नहीं होना चाहिए.
- इस सेंसर के लिए, बिना 'जागने' वाले फ़ॉर्म को लागू करना ज़रूरी है. साथ ही, यह फ़ॉर्म कम से कम 3,000 सेंसर इवेंट को बफ़र करने की सुविधा के साथ होना चाहिए.
- बैचिंग के दौरान, डिवाइस की बिजली की खपत 3 mW से ज़्यादा नहीं होनी चाहिए.
- 24 घंटे के स्टैटिक डेटासेट से, स्टेशनरी नॉइज़ बायस की स्थिरता 15 μg √Hz से कम होनी चाहिए.
- तापमान के हिसाब से, बायस में बदलाव ≤ +/- 1mg / °C होना चाहिए.
- सबसे अच्छी फ़िट लाइन की गैर-लीनियरिटी ≤ 0.5% होनी चाहिए. साथ ही, तापमान के हिसाब से सेंसिटिविटी में बदलाव ≤ 0.03%/C° होना चाहिए.
- सेंसर के नॉइज़ इंटिग्रिटी की ज़रूरी शर्तों को पूरा करने के लिए, इसमें व्हाइट नॉइज़ स्पेक्ट्रम होना चाहिए.
[C-2-2] TYPE_ACCELEROMETER_UNCALIBRATED में TYPE_ACCELEROMETER जैसी ही क्वालिटी की ज़रूरी शर्तें होनी चाहिए.
[C-2-3] इसमें TYPE_GYROSCOPE सेंसर होना चाहिए, जो:
- मेज़रमेंट की रेंज कम से कम -1,000 से +1,000 डीपीएस के बीच होनी चाहिए.
- मेज़रमेंट रिज़ॉल्यूशन कम से कम 16 LSB/dps होना चाहिए.
- मेज़रमेंट फ़्रीक्वेंसी कम से कम 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 LSB/hPa होना चाहिए.
- मेज़रमेंट फ़्रीक्वेंसी कम से कम 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 mW से ज़्यादा नहीं होनी चाहिए. साथ ही, डिवाइस के मूव होने पर, बिजली की खपत 1.5 mW से ज़्यादा नहीं होनी चाहिए.
[C-2-10] इसमें TYPE_STEP_DETECTOR सेंसर होना चाहिए, जो:
- इस सेंसर के लिए, बिना 'जागने' वाले फ़ॉर्म को लागू करना ज़रूरी है. साथ ही, यह फ़ॉर्म कम से कम 100 सेंसर इवेंट को बफ़र करने की सुविधा के साथ होना चाहिए.
- डिवाइस के स्टैटिक होने पर, बिजली की खपत 0.5 mW से ज़्यादा नहीं होनी चाहिए. साथ ही, डिवाइस के मूव होने पर, बिजली की खपत 1.5 mW से ज़्यादा नहीं होनी चाहिए.
- बैचिंग के दौरान, डिवाइस की बिजली की खपत 4 mW से ज़्यादा नहीं होनी चाहिए.
[C-2-11] ऐप्लिकेशन में TYPE_STEP_COUNTER सेंसर होना चाहिए, जो:
- डिवाइस के स्टैटिक होने पर, बिजली की खपत 0.5 mW से ज़्यादा नहीं होनी चाहिए. साथ ही, डिवाइस के मूव होने पर, बिजली की खपत 1.5 mW से ज़्यादा नहीं होनी चाहिए.
[C-2-12] इसमें TILT_DETECTOR सेंसर होना चाहिए, जो:
- डिवाइस के स्टैटिक होने पर, बिजली की खपत 0.5 mW से ज़्यादा नहीं होनी चाहिए. साथ ही, डिवाइस के मूव होने पर, बिजली की खपत 1.5 mW से ज़्यादा नहीं होनी चाहिए.
[C-2-13] एक ही फ़िज़िकल इवेंट के लिए, एक्सेलेरोमीटर, जायरोस्कोप सेंसर, और मैग्नेटोमीटर से रिपोर्ट किए गए इवेंट के टाइमस्टैंप में 2.5 मिलीसेकंड से ज़्यादा का अंतर नहीं होना चाहिए.
[C-2-14] यह ज़रूरी है कि जियोस्कोप सेंसर इवेंट के टाइमस्टैंप, कैमरा सबसिस्टम के टाइम बेस के साथ-साथ हों और गड़बड़ी 1 मिलीसेकंड के अंदर हो.
[C-2-15] ऊपर दिए गए किसी भी फ़िज़िकल सेंसर पर डेटा उपलब्ध होने के पांच मिलीसेकंड के अंदर, ऐप्लिकेशन को सैंपल डिलीवर करना ज़रूरी है.
[C-2-16] जब डिवाइस स्टैटिक हो, तो उसकी पावर खपत 0.5 mW से ज़्यादा नहीं होनी चाहिए. साथ ही, जब डिवाइस चल रहा हो, तो उसकी पावर खपत 2.0 mW से ज़्यादा नहीं होनी चाहिए. ऐसा तब होगा, जब इन सेंसर में से किसी भी कॉम्बिनेशन को चालू किया गया हो:
- SENSOR_TYPE_SIGNIFICANT_MOTION
- SENSOR_TYPE_STEP_DETECTOR
- SENSOR_TYPE_STEP_COUNTER
- SENSOR_TILT_DETECTORS
[C-2-17] इसमें TYPE_PROXIMITY सेंसर हो सकता है. हालांकि, अगर सेंसर मौजूद है, तो कम से कम 100 सेंसर इवेंट का बफ़र होना चाहिए.

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

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

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

7.3.10. फ़िंगरप्रिंट सेंसर

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

इसमें फ़िंगरप्रिंट सेंसर होना चाहिए.

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

[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] उपयोगकर्ता को मौजूदा डिवाइस क्रेडेंशियल (PIN/पैटर्न/पासवर्ड) की पुष्टि करने या TEE से सुरक्षित नया डिवाइस क्रेडेंशियल जोड़ने के लिए कहकर, भरोसे की चेन सेट अप किए बिना फ़िंगरप्रिंट जोड़ने से रोकना ज़रूरी है. Android Open Source Project के लागू होने से, ऐसा करने के लिए फ़्रेमवर्क में एक तरीका मिलता है.
[C-1-9] तीसरे पक्ष के ऐप्लिकेशन को अलग-अलग फ़िंगरप्रिंट के बीच अंतर करने की अनुमति नहीं दी जानी चाहिए.
[C-1-10] ऐप्लिकेशन को DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT फ़्लैग का पालन करना चाहिए.
[C-1-11] Android 6.0 से पहले के वर्शन से अपग्रेड करने पर, ऊपर दी गई ज़रूरी शर्तों को पूरा करने के लिए, फ़िंगरप्रिंट डेटा को सुरक्षित तरीके से माइग्रेट करना ज़रूरी है या उसे हटाना होगा.
[SR] हमारा सुझाव है कि डिवाइस पर मेज़र किए गए फ़ॉल्स रिजेक्शन रेट (गलत तरीके से अस्वीकार किए जाने की दर) को 10% से कम रखा जाए.
[SR] हमारा सुझाव है कि फ़िंगरप्रिंट अनलॉक करने में एक सेकंड से कम समय लगे. यह समय, फ़िंगरप्रिंट सेंसर को छूने से लेकर, स्क्रीन अनलॉक होने तक का होता है. यह समय, रजिस्टर की गई एक उंगली के लिए होता है.
Android Open Source Project में दिए गए 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] इसमें नंबर ब्लॉक करने की सुविधा शामिल होनी चाहिए
[C-1-2] SDK टूल के दस्तावेज़ में बताए गए तरीके से, BlockedNumberContract और उससे जुड़े एपीआई को पूरी तरह से लागू करना ज़रूरी है.
[C-1-3] 'BlockedNumberProvider' में मौजूद किसी फ़ोन नंबर से आने वाले सभी कॉल और मैसेज को ब्लॉक करना ज़रूरी है. इसके लिए, ऐप्लिकेशन के साथ कोई इंटरैक्शन नहीं करना चाहिए. हालांकि, SDK टूल के दस्तावेज़ में बताए गए तरीके से, नंबर ब्लॉक करने की सुविधा को कुछ समय के लिए हटाने पर, यह शर्त लागू नहीं होती.
[C-1-4] ब्लॉक किए गए कॉल के लिए, कॉल लॉग की सेवा देने वाली कंपनी को डेटा नहीं भेजना चाहिए.
[C-1-5] ब्लॉक किए गए मैसेज के लिए, टेलीफ़ोनी सेवा देने वाली कंपनी को नहीं लिखना चाहिए.
[C-1-6] ब्लॉक किए गए नंबरों को मैनेज करने के लिए यूज़र इंटरफ़ेस (यूआई) लागू करना ज़रूरी है. यह यूआई, TelecomManager.createManageBlockedNumbersIntent() तरीके से मिले इंटेंट से खुलता है.
[C-1-7] डिवाइस पर ब्लॉक किए गए नंबर देखने या उनमें बदलाव करने की अनुमति, दूसरे उपयोगकर्ताओं को नहीं दी जानी चाहिए. ऐसा इसलिए, क्योंकि Android प्लैटफ़ॉर्म यह मानता है कि डिवाइस पर टेलीफ़ोन सेवाओं का पूरा कंट्रोल, मुख्य उपयोगकर्ता के पास होता है. सेकंडरी उपयोगकर्ताओं के लिए, ब्लॉक करने से जुड़ा पूरा यूज़र इंटरफ़ेस (यूआई) छिपाया जाना चाहिए. साथ ही, ब्लॉक की गई सूची को भी लागू किया जाना चाहिए.
जब कोई डिवाइस Android 7.0 पर अपडेट होता है, तो ब्लॉक किए गए नंबरों को मोबाइल और इंटरनेट सेवा देने वाली कंपनी के पास माइग्रेट करना चाहिए.

7.4.1.2. Telecom API

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

[C-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] SDK के दस्तावेज़ में बताए गए तरीके से, मल्टीकास्ट एपीआई को लागू करना ज़रूरी है.
[C-1-4] मल्टीकास्ट डीएनएस (mDNS) के साथ काम करना चाहिए. साथ ही, ऑपरेशन के किसी भी समय mDNS पैकेट (224.0.0.251) को फ़िल्टर नहीं करना चाहिए. इनमें ये भी शामिल हैं:
- भले ही, स्क्रीन चालू न हो.
- Android Television डिवाइसों के लिए, स्टैंडबाय मोड में भी.
जब STA डिसकनेक्ट हो, तब हर स्कैन की शुरुआत में, सोर्स मैक पते और प्रोब रिक्वेस्ट फ़्रेम के क्रम संख्या को रैंडम कर देना चाहिए.
- एक स्कैन वाले प्रोब अनुरोध फ़्रेम के हर ग्रुप को एक ही मैक पते का इस्तेमाल करना चाहिए. स्कैन के आधे हिस्से में मैक पते को रैंडम नहीं किया जाना चाहिए.
- किसी स्कैन में, प्रोब अनुरोधों के बीच प्रोब अनुरोध का क्रम सामान्य (क्रम से) होना चाहिए
- किसी स्कैन के आखिरी प्रोब अनुरोध और अगले स्कैन के पहले प्रोब अनुरोध के बीच, प्रोब अनुरोध का क्रम संख्या रैंडम होना चाहिए
जब STA डिसकनेक्ट हो, तब प्रोब अनुरोध फ़्रेम में सिर्फ़ इन जानकारी एलिमेंट को अनुमति दी जानी चाहिए:
- SSID पैरामीटर सेट (0)
- डीएस पैरामीटर सेट (तीन)

7.4.2.1. Wi-Fi Direct

डिवाइस पर लागू करने के तरीके:

इसमें वाई-फ़ाई डायरेक्ट (वाई-फ़ाई पीयर-टू-पीयर) की सुविधा शामिल होनी चाहिए.

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

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

7.4.2.2. वाई-फ़ाई टनल वाला डायरेक्ट लिंक सेटअप करना

डिवाइस पर लागू करने के तरीके:

इसमें Wi-Fi टनल किए गए डायरेक्ट लिंक सेटअप (TDLS) के लिए सहायता शामिल होनी चाहिए, जैसा कि Android SDK टूल के दस्तावेज़ में बताया गया है.

अगर डिवाइस में TDLS की सुविधा काम करती है और WiFiManager API ने TDLS को चालू किया है, तो:

[C-1-1] WifiManager.isTdlsSupported के ज़रिए, यह ज़रूर बताना चाहिए कि टीडीएलएस की सुविधा काम करती है.
TDLS का इस्तेमाल सिर्फ़ तब करना चाहिए, जब यह मुमकिन हो और फ़ायदेमंद हो.
इसमें कुछ ह्यूरिस्टिक होने चाहिए और जब इसकी परफ़ॉर्मेंस, वाई-फ़ाई ऐक्सेस पॉइंट से कनेक्ट होने की तुलना में खराब हो, तब TDLS का इस्तेमाल नहीं किया जाना चाहिए.

7.4.2.3. वाई-फ़ाई अवेयर

डिवाइस पर लागू करने के तरीके:

इसमें Wi-Fi Aware के लिए सहायता शामिल होनी चाहिए.

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

[C-1-1] SDK टूल के दस्तावेज़ में बताए गए तरीके से, WifiAwareManager एपीआई लागू करना ज़रूरी है.
[C-1-2] android.hardware.wifi.aware फ़ीचर फ़्लैग का एलान करना ज़रूरी है.
[C-1-3] यह ज़रूरी है कि डिवाइस पर वाई-फ़ाई और वाई-फ़ाई अवेयर, दोनों एक साथ काम करते हों.
[C-1-4] वाई-फ़ाई अवेयर मैनेजमेंट इंटरफ़ेस के पते को 30 मिनट से ज़्यादा के अंतराल पर और वाई-फ़ाई अवेयर की सुविधा चालू होने पर, रैंडम तरीके से बदलना ज़रूरी है.

7.4.2.4. वाई-फ़ाई पासपॉइंट

डिवाइस पर लागू करने के तरीके:

इसमें Wi-Fi Passpoint के लिए सहायता शामिल होनी चाहिए.

अगर डिवाइस में वाई-फ़ाई पासपॉइंट की सुविधा काम करती है, तो:

[C-1-1] SDK टूल के दस्तावेज़ में बताए गए तरीके से, Passpoint से जुड़े WifiManager एपीआई लागू करना ज़रूरी है.
[C-1-2] यह ज़रूरी है कि डिवाइस, IEEE 802.11u स्टैंडर्ड के साथ काम करे. यह स्टैंडर्ड, खास तौर पर नेटवर्क डिस्कवरी और चुनने से जुड़ा है. जैसे, जनरल विज्ञापन सेवा (जीएएस) और ऐक्सेस नेटवर्क क्वेरी प्रोटोकॉल (एएनक्यूपी).

इसके उलट, अगर डिवाइस में Wi-Fi Passpoint की सुविधा काम नहीं करती है, तो:

[C-2-1] Passpoint से जुड़े WifiManager एपीआई को लागू करने पर, UnsupportedOperationException दिखना चाहिए.

7.4.3. ब्लूटूथ

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

यह एडवांस ऑडियो कोडेक और ब्लूटूथ ऑडियो कोडेक (जैसे, LDAC) के साथ काम करना चाहिए.

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

[C-1-1] यह ज़रूरी है कि डिवाइस, ब्लूटूथ 4.2 और ब्लूटूथ ले डेटा लेंथ एक्सटेंशन के साथ काम करता हो.

Android में ब्लूटूथ और ब्लूटूथ लो एनर्जी की सुविधा शामिल है.

अगर डिवाइस में ब्लूटूथ और ब्लूटूथ लो एनर्जी (LE) की सुविधाएं शामिल हैं, तो:

[C-2-1] प्लैटफ़ॉर्म की काम की सुविधाओं (क्रमशः android.hardware.bluetooth और android.hardware.bluetooth_le) के बारे में एलान करना और प्लैटफ़ॉर्म के एपीआई लागू करना ज़रूरी है.
डिवाइस के हिसाब से, A2DP, AVCP, OBEX वगैरह जैसी काम की ब्लूटूथ प्रोफ़ाइलें लागू करनी चाहिए.

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

[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.hardware.nfc सुविधा की रिपोर्ट, android.content.pm.PackageManager.hasSystemFeature() तरीके से देनी ज़रूरी है.
यह ज़रूरी है कि डिवाइस, नीचे दिए गए एनएफ़सी स्टैंडर्ड की मदद से, एनडीएफ़ मैसेज को पढ़ और लिख सके:
[C-1-2] यह ज़रूरी है कि यह एनएफ़सी फ़ोरम रीडर/राइटर्स के तौर पर काम कर सके.इसके लिए, यह एनएफ़सी के इन स्टैंडर्ड का पालन करता हो:
NfcA (ISO14443-3A)
NfcB (ISO14443-3B)
NfcF (JIS X 6319-4)
IsoDep (ISO 14443-4)
एनएफ़सी फ़ोरम टैग टाइप 1, 2, 3, 4, 5 (एनएफ़सी फ़ोरम के मुताबिक)
[SR] हमारा सुझाव है कि आपके ऐप्लिकेशन में, एनएफ़सी के इन स्टैंडर्ड का इस्तेमाल करके, एनडीएफ़ मैसेज के साथ-साथ रॉ डेटा को पढ़ने और लिखने की सुविधा हो. ध्यान दें कि एनएफ़सी स्टैंडर्ड के लिए, 'इसका सुझाव दिया जाता है' के तौर पर बताया गया है. हालांकि, आने वाले समय में रिलीज़ होने वाले वर्शन के लिए, 'ज़रूरी है' के तौर पर बदलने का प्लान है. इस वर्शन में ये स्टैंडर्ड इस्तेमाल करना ज़रूरी नहीं है. हालांकि, आने वाले वर्शन में इनका इस्तेमाल करना ज़रूरी होगा. Android के इस वर्शन पर काम करने वाले मौजूदा और नए डिवाइसों को, इन ज़रूरी शर्तों को पूरा करने का सुझाव दिया जाता है. इससे, आने वाले समय में प्लैटफ़ॉर्म के रिलीज़ किए जाने वाले नए वर्शन पर अपग्रेड किया जा सकेगा.
[C-1-3] यह ज़रूरी है कि यह टूल, नीचे दिए गए पीयर-टू-पीयर स्टैंडर्ड और प्रोटोकॉल के ज़रिए डेटा भेज और पा सके:
ISO 18092
LLCP 1.2 (NFC फ़ोरम के मुताबिक)
SDP 1.0 (एनएफ़सी फ़ोरम ने तय किया है)
एनडीएफ़ पुश प्रोटोकॉल
SNEP 1.0 (NFC फ़ोरम के मुताबिक)
[C-1-4] ऐप्लिकेशन में Android Beam की सुविधा शामिल होनी चाहिए. साथ ही, यह सुविधा डिफ़ॉल्ट रूप से चालू होनी चाहिए.
[C-1-5] Android Beam की सुविधा चालू होने पर या कोई अन्य मालिकाना एनएफ़सी पी2पी मोड चालू होने पर, Android Beam का इस्तेमाल करके फ़ाइलें भेजी और ली जा सकें.
[C-1-6] SNEP डिफ़ॉल्ट सर्वर को लागू करना ज़रूरी है. डिफ़ॉल्ट SNEP सर्वर से मिले मान्य NDEF मैसेज को 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 भेजने की कोशिश करनी होगी. अगर कोई डिफ़ॉल्ट SNEP सर्वर नहीं मिलता है, तो क्लाइंट को एनपीपी सर्वर पर भेजने की कोशिश करनी होगी.
[C-1-10] फ़ोरग्राउंड गतिविधियों को android.nfc.NfcAdapter.setNdefPushMessage, android.nfc.NfcAdapter.setNdefPushMessageCallback, और android.nfc.NfcAdapter.enableForegroundNdefPush का इस्तेमाल करके, आउटबाउंड P2P NDEF मैसेज सेट करने की अनुमति देनी चाहिए.
आउटबाउंड पी2पी एनडीएफ़ मैसेज भेजने से पहले, 'टच करके बीम करें' जैसे जेस्चर या स्क्रीन पर पुष्टि करने की सुविधा का इस्तेमाल करना चाहिए.
[C-1-11] अगर डिवाइस पर ब्लूटूथ ऑब्जेक्ट पुश प्रोफ़ाइल काम करती है, तो डिवाइस को एनएफ़सी कनेक्शन को ब्लूटूथ पर ट्रांसफ़र करने की सुविधा देनी होगी.
[C-1-12] android.nfc.NfcAdapter.setBeamPushUris का इस्तेमाल करते समय, ब्लूटूथ पर कनेक्शन को हैंडओवर करने की सुविधा होनी चाहिए. इसके लिए, NFC फ़ोरम के “कनेक्शन हैंडओवर वर्शन 1.2” और “एनएफ़सी वर्शन 1.0 का इस्तेमाल करके, ब्लूटूथ से सुरक्षित तरीके से आसानी से जोड़ने” के स्पेसिफ़िकेशन लागू करें. इस तरह के लागू होने के लिए, एनएफ़सी पर हैंडओवर अनुरोध/चुने गए रिकॉर्ड को एक्सचेंज करने के लिए, सेवा के नाम “urn:nfc:sn:handover” के साथ हैंडओवर एलएलसीपी सेवा को लागू करना ज़रूरी है. साथ ही, ब्लूटूथ डेटा ट्रांसफ़र के लिए, ब्लूटूथ ऑब्जेक्ट पुश प्रोफ़ाइल का इस्तेमाल करना ज़रूरी है. लेगसी वजहों (Android 4.1 डिवाइसों के साथ काम करने के लिए) से, एनएफ़सी के ज़रिए रिकॉर्ड को चुनने/हैंडलओवर का अनुरोध करने के लिए, SNEP GET अनुरोध अब भी स्वीकार किए जाने चाहिए. हालांकि, कनेक्शन हैंडओवर करने के लिए, लागू करने वाले को खुद SNEP GET अनुरोध नहीं भेजने चाहिए.
[C-1-13] एनएफ़सी डिस्कवरी मोड में, काम करने वाली सभी टेक्नोलॉजी के लिए पोल करना ज़रूरी है.
डिवाइस के चालू होने पर, स्क्रीन चालू और लॉक-स्क्रीन अनलॉक होने पर, डिवाइस को एनएफ़सी डिस्कवरी मोड में होना चाहिए.
थिनफ़िल्म एनएफ़सी बारकोड वाले प्रॉडक्ट के बारकोड और यूआरएल (अगर कोड में बदला गया है) को पढ़ने में सक्षम होना चाहिए.

ध्यान दें कि ऊपर बताए गए JIS, ISO, और NFC फ़ोरम के स्पेसिफ़िकेशन के लिए, सार्वजनिक तौर पर उपलब्ध लिंक उपलब्ध नहीं हैं.

Android में, एनएफ़सी होस्ट कार्ड एम्युलेशन (एचसीई) मोड के साथ काम करने की सुविधा शामिल है.

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

[C-2-1] android.hardware.nfc.hce सुविधा के कॉन्स्टेंट की जानकारी देना ज़रूरी है.
[C-2-2] Android SDK टूल में बताए गए तरीके के मुताबिक, एनएफ़सी एचसीई एपीआई के साथ काम करना चाहिए.

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

[C-3-1] android.hardware.nfc.hcef सुविधा के कॉन्स्टेंट की जानकारी देना ज़रूरी है.
[C-3-2] Android SDK में बताए गए तरीके से, NfcF कार्ड इम्यूलेशन एपीआई लागू करना ज़रूरी है.

अगर डिवाइस में, इस सेक्शन में बताए गए सामान्य एनएफ़सी सपोर्ट के साथ-साथ रीडर/राइटर्स की भूमिका में MIFARE टेक्नोलॉजी (MIFARE Classic, MIFARE Ultralight, MIFARE Classic पर NDEF) काम करती हैं, तो:

[C-4-1] Android SDK टूल में बताए गए तरीके के मुताबिक, काम के Android एपीआई लागू करना ज़रूरी है.
[C-4-2] android.content.pm.PackageManager.hasSystemFeature() तरीके से, com.nxp.mifare सुविधा की रिपोर्ट करना ज़रूरी है. ध्यान दें कि यह Android की स्टैंडर्ड सुविधा नहीं है. इसलिए, यह android.content.pm.PackageManager क्लास में एक कॉन्स्टेंट के तौर पर नहीं दिखती.

7.4.5. नेटवर्क की कम से कम क्षमता

डिवाइस पर लागू करने के तरीके:

[C-0-1] इसमें डेटा नेटवर्किंग के एक या एक से ज़्यादा फ़ॉर्म के लिए सहायता शामिल होनी चाहिए. खास तौर पर, डिवाइस में कम से कम एक ऐसा डेटा स्टैंडर्ड होना चाहिए जो 200 केबीआईटी/सेकंड या उससे ज़्यादा की स्पीड पर काम कर सके. इस ज़रूरी शर्त को पूरा करने वाली टेक्नोलॉजी के उदाहरणों में, EDGE, HSPA, EV-DO, 802.11g, ईथरनेट, ब्लूटूथ पैन वगैरह शामिल हैं.
[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 (वाई-फ़ाई)) के लिए भी सहायता शामिल होनी चाहिए
डेटा कनेक्टिविटी के एक से ज़्यादा तरीके लागू किए जा सकते हैं.

आईपीवी6 के लिए ज़रूरी सहायता का लेवल, नेटवर्क टाइप पर निर्भर करता है. यह लेवल इस तरह से तय होता है:

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

[C-1-1] यह ज़रूरी है कि डिवाइस, वाई-फ़ाई पर ड्यूअल-स्टैक और सिर्फ़ IPv6 मोड में काम करे.

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

[C-2-1] यह ज़रूरी है कि ईथरनेट पर ड्यूअल-स्टैक ऑपरेशन की सुविधा काम करे.

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

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

7.4.6. समन्वयन सेटिंग

डिवाइस पर लागू करने के तरीके:

[C-0-1] अपने-आप सिंक होने की मुख्य सेटिंग डिफ़ॉल्ट रूप से चालू होनी चाहिए, ताकि getMasterSyncAutomatically() का तरीका “सही” दिखाए.

7.4.7. डेटा बचाने की सेटिंग

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

[SR] हमारा सुझाव है कि आप डेटा बचाने वाला मोड उपलब्ध कराएं.

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

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

अगर कैमरे में फ़्लैश है, तो:

[C-2-1] कैमरे की झलक दिखाने वाले प्लैटफ़ॉर्म पर android.hardware.Camera.PreviewCallback इंस्टेंस के रजिस्टर होने के दौरान, फ़्लैश लैंप नहीं जलना चाहिए. ऐसा तब तक नहीं होना चाहिए, जब तक कि ऐप्लिकेशन ने Camera.Parameters ऑब्जेक्ट के FLASH_MODE_AUTO या FLASH_MODE_ON एट्रिब्यूट को चालू करके, फ़्लैश को साफ़ तौर पर चालू न किया हो. ध्यान दें कि यह पाबंदी, डिवाइस के पहले से मौजूद सिस्टम कैमरा ऐप्लिकेशन पर लागू नहीं होती. यह सिर्फ़ Camera.PreviewCallback का इस्तेमाल करने वाले तीसरे पक्ष के ऐप्लिकेशन पर लागू होती है.

7.5.2. सामने वाला कैमरा

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

डिवाइस पर लागू करने के तरीके:

इसमें सामने वाला कैमरा हो सकता है

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

[C-1-1] सुविधा फ़्लैग android.hardware.camera.any और android.hardware.camera.front की शिकायत करना ज़रूरी है.
[C-1-2] इसका रिज़ॉल्यूशन कम से कम VGA (640x480 पिक्सल) होना चाहिए.
[C-1-3] Camera API के लिए, सामने वाले कैमरे को डिफ़ॉल्ट तौर पर इस्तेमाल नहीं किया जाना चाहिए. साथ ही, एपीआई को इस तरह कॉन्फ़िगर नहीं किया जाना चाहिए कि वह सामने वाले कैमरे को पीछे वाले कैमरे के तौर पर इस्तेमाल करे. भले ही, डिवाइस में सिर्फ़ यही कैमरा हो.
[C-1-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 जैसे वीडियो कंप्रेस करने की सुविधा होनी चाहिए.
एक से ज़्यादा कैमरे इस्तेमाल करने की सुविधा हो सकती है.
कैमरे से वीडियो एन्कोड करने की सुविधा मिल सकती है. अगर डिवाइस पर यह सुविधा काम करती है, तो डिवाइस पर एक साथ अनकोड की गई / एमजेपीईजी स्ट्रीम (QVGA या इससे ज़्यादा रिज़ॉल्यूशन) को ऐक्सेस किया जा सकता है.

7.5.4. Camera API का व्यवहार

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

पुराने एपीआई पैकेज, android.hardware.Camera को Android 5.0 में 'इस्तेमाल नहीं किया जा सकता' के तौर पर मार्क किया गया है. हालांकि, यह ऐप्लिकेशन के इस्तेमाल के लिए अब भी उपलब्ध होना चाहिए. 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 होता है, तो डेटा को byte[] में onPreviewFrame() में पास किया जाना चाहिए. साथ ही, यह डेटा NV21 एन्कोडिंग फ़ॉर्मैट में होना चाहिए. इसका मतलब है कि NV21, डिफ़ॉल्ट तौर पर होना चाहिए.
[C-0-3] android.hardware.Camera के लिए, सामने और पीछे के दोनों कैमरों की झलक दिखाने के लिए, YV12 फ़ॉर्मैट (जैसा कि android.graphics.ImageFormat.YV12 कॉन्स्टेंट से पता चलता है) का इस्तेमाल करना ज़रूरी है. (हार्डवेयर वीडियो एन्कोडर और कैमरा, किसी भी नेटिव पिक्सल फ़ॉर्मैट का इस्तेमाल कर सकते हैं. हालांकि, डिवाइस में YV12 में बदलाव करने की सुविधा होनी चाहिए.)
[C-0-4] android.media.ImageReader एपीआई की मदद से, android.hardware.camera2 डिवाइसों के लिए android.hardware.ImageFormat.YUV_420_888 और android.hardware.ImageFormat.JPEG फ़ॉर्मैट को आउटपुट के तौर पर इस्तेमाल किया जाना चाहिए. ये ऐसे डिवाइस होते हैं जो android.request.availableCapabilities में REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE की सुविधा का विज्ञापन करते हैं.
[C-0-5] Android SDK टूल के दस्तावेज़ में शामिल Camera API को पूरी तरह से लागू करना ज़रूरी है. भले ही, डिवाइस में ऑटोफ़ोकस करने वाला हार्डवेयर या अन्य सुविधाएं हों. उदाहरण के लिए, जिन कैमरों में ऑटोफ़ोकस की सुविधा नहीं होती है उन्हें भी रजिस्टर किए गए किसी भी android.hardware.Camera.AutoFocusCallback इंस्टेंस को कॉल करना होगा. भले ही, ऑटोफ़ोकस की सुविधा न होने वाले कैमरे के लिए इसका कोई मतलब न हो. ध्यान दें कि यह फ़्रंट-फ़ेसिंग कैमरों पर भी लागू होता है. उदाहरण के लिए, ज़्यादातर फ़्रंट-फ़ेसिंग कैमरे ऑटोफ़ोकस की सुविधा के साथ काम नहीं करते. इसके बावजूद, एपीआई कॉलबैक को ऊपर बताए गए तरीके से “फ़ेक” किया जाना चाहिए.
[C-0-6] android.hardware.Camera.Parameters क्लास में, हर पैरामीटर के नाम को कॉन्स्टेंट के तौर पर तय किया जाना चाहिए. इसके उलट, डिवाइस के लागू होने पर, android.hardware.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 File Transfer, Android MTP होस्ट के साथ काम करना चाहिए.
यूएसबी डिवाइस क्लास 0x00 की रिपोर्ट करनी चाहिए.
यूएसबी इंटरफ़ेस का नाम 'MTP' होना चाहिए.

7.6.3. एडॉप्टेबल स्टोरेज

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

[SR] हमारा सुझाव है कि आप अपनाने लायक स्टोरेज को ऐसी जगह पर सेट अप करें जहां यह लंबे समय तक काम करता रहे. ऐसा इसलिए, क्योंकि गलती से डिसकनेक्ट होने पर डेटा मिट सकता है या खराब हो सकता है.

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

[SR] हमारा सुझाव है कि आप एडॉप्टेबल स्टोरेज को लागू करें.

7.7. यूएसबी

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

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

7.7.1. यूएसबी पेरिफ़रल मोड

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

[C-1-1] पोर्ट को ऐसे यूएसबी होस्ट से कनेक्ट किया जा सकता है जिसमें स्टैंडर्ड टाइप-A या टाइप-C यूएसबी पोर्ट हो.
[C-1-2] android.os.Build.SERIAL की मदद से, USB स्टैंडर्ड डिवाइस डिस्क्रिप्टर में iSerialNumber की सही वैल्यू की जानकारी देनी ज़रूरी है.
[C-1-3] टाइप-C रेज़िस्टर स्टैंडर्ड के मुताबिक, 1.5A और 3.0A चार्जर का पता लगाना ज़रूरी है. साथ ही, अगर विज्ञापन में टाइप-C यूएसबी की सुविधा का इस्तेमाल किया गया है, तो विज्ञापन में हुए बदलावों का पता लगाना ज़रूरी है.
[SR] पोर्ट में माइक्रो-बी, माइक्रो-एबी या टाइप-सी यूएसबी फ़ॉर्म फ़ैक्टर का इस्तेमाल किया जाना चाहिए. मौजूदा और नए Android डिवाइसों के लिए, इन ज़रूरी शर्तों को पूरा करने का सुझाव दिया जाता है, ताकि वे आने वाले समय में प्लैटफ़ॉर्म के रिलीज़ किए जाने वाले वर्शन पर अपग्रेड कर सकें.
[SR] पोर्ट, डिवाइस के सबसे नीचे होना चाहिए (डिवाइस के सामान्य ओरिएंटेशन के हिसाब से). इसके अलावा, सभी ऐप्लिकेशन (होम स्क्रीन भी शामिल है) के लिए, सॉफ़्टवेयर स्क्रीन रोटेशन की सुविधा चालू की जा सकती है, ताकि डिवाइस को सबसे नीचे पोर्ट के साथ ओरिएंट करने पर, डिसप्ले सही तरीके से दिखे. मौजूदा और नए Android डिवाइसों के लिए, इन ज़रूरी शर्तों को पूरा करने का सुझाव दिया जाता है, ताकि वे आने वाले समय में प्लैटफ़ॉर्म के रिलीज़ किए जाने वाले वर्शन पर अपग्रेड कर सकें.
[SR] यूएसबी बैटरी चार्जिंग स्पेसिफ़िकेशन, रिविज़न 1.2 में बताए गए तरीके के मुताबिक, एचएस चिर्प और ट्रैफ़िक के दौरान 1.5 ए करंट खींचने के लिए, सपोर्ट लागू करना चाहिए. मौजूदा और नए Android डिवाइसों के लिए, इन ज़रूरी शर्तों को पूरा करने का सुझाव दिया जाता है, ताकि वे आने वाले समय में प्लैटफ़ॉर्म के रिलीज़ किए जाने वाले वर्शन पर अपग्रेड कर सकें.
[SR] हमारा सुझाव है कि चार्जिंग के ऐसे मालिकाना तरीकों का इस्तेमाल न करें जो Vbus वोल्टेज को डिफ़ॉल्ट लेवल से ज़्यादा कर दें या सिंक/सोर्स की भूमिकाओं में बदलाव कर दें. ऐसा करने पर, USB Power Delivery के स्टैंडर्ड तरीकों के साथ काम करने वाले चार्जर या डिवाइसों के साथ इंटरऑपरेबिलिटी से जुड़ी समस्याएं आ सकती हैं. हालांकि, इसे "ज़रूर इस्तेमाल करें" के तौर पर दिखाया गया है, लेकिन आने वाले समय में Android के नए वर्शन में, हो सकता है कि हम सभी टाइप-C डिवाइसों के लिए, स्टैंडर्ड टाइप-C चार्जर के साथ पूरी तरह काम करने की ज़रूरी शर्त लागू करें.
[SR] अगर डिवाइस में टाइप-सी यूएसबी और यूएसबी होस्ट मोड की सुविधा है, तो डेटा और पावर की भूमिका बदलने के लिए, पावर डिलीवरी की सुविधा का इस्तेमाल करने का सुझाव दिया जाता है.
यह ज़रूरी है कि यह डिवाइस, हाई-वोल्टेज चार्जिंग के लिए पावर डिलीवरी की सुविधा के साथ-साथ, डिसप्ले आउट जैसे अन्य मोड के साथ काम करे.
Android SDK टूल के दस्तावेज़ में बताए गए तरीके से, Android Open Accessory (AOA) API और स्पेसिफ़िकेशन को लागू करना चाहिए.

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

[C-2-1] यह ज़रूरी है कि आपने हार्डवेयर की सुविधा android.hardware.usb.accessory के साथ काम करने की जानकारी दी हो.
[C-2-2] यूएसबी स्टोरेज क्लास में, यूएसबी स्टोरेज के इंटरफ़ेस की जानकारी iInterface स्ट्रिंग के आखिर में "android" स्ट्रिंग शामिल होनी चाहिए

7.7.2. यूएसबी होस्ट मोड

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

[C-1-1] Android SDK में बताए गए तरीके से, Android USB होस्ट API को लागू करना ज़रूरी है. साथ ही, यह भी ज़रूरी है कि हार्डवेयर की सुविधा android.hardware.usb.host के साथ काम करने की जानकारी दी जाए.
[C-1-2] स्टैंडर्ड यूएसबी डिवाइसों को कनेक्ट करने के लिए, डिवाइसों में यह सुविधा होनी चाहिए. इसका मतलब है कि इनमें से कोई एक काम करना चाहिए:
- डिवाइस में टाइप-सी पोर्ट होना चाहिए या डिवाइस में मौजूद मालिकाना पोर्ट को स्टैंडर्ड यूएसबी टाइप-सी पोर्ट (यूएसबी टाइप-सी डिवाइस) में बदलने वाली केबल के साथ शिप किया जाना चाहिए.
- डिवाइस में टाइप-A पोर्ट होना चाहिए या डिवाइस में मौजूद मालिकाना पोर्ट को स्टैंडर्ड यूएसबी टाइप-A पोर्ट में बदलने वाली केबल के साथ शिप किया जाना चाहिए.
- डिवाइस में माइक्रो-AB पोर्ट होना चाहिए. साथ ही, डिवाइस के साथ एक ऐसी केबल भी होनी चाहिए जो स्टैंडर्ड टाइप-A पोर्ट के साथ काम करती हो.
[C-1-3] डिवाइस को यूएसबी टाइप-ए या माइक्रो-एबी पोर्ट को टाइप-सी पोर्ट (जगह) में बदलने वाले अडैप्टर के साथ शिप नहीं किया जाना चाहिए.
[SR] हमारा सुझाव है कि आप Android SDK के दस्तावेज़ में बताए गए तरीके से, यूएसबी ऑडियो क्लास को लागू करें.
होस्ट मोड में, कनेक्ट किए गए यूएसबी डिवाइस को चार्ज करने की सुविधा होनी चाहिए. साथ ही, यूएसबी टाइप-सी कनेक्टर के लिए यूएसबी टाइप-सी केबल और कनेक्टर स्पेसिफ़िकेशन रिविज़न 1.2 के टर्मिनेशन पैरामीटर सेक्शन में बताए गए मुताबिक, सोर्स करंट कम से कम 1.5 ऐंपियर होना चाहिए. इसके अलावा, माइक्रो-एबी कनेक्टर के लिए यूएसबी बैटरी चार्जिंग स्पेसिफ़िकेशन, रिविज़न 1.2 में बताए गए मुताबिक, चार्जिंग डाउनस्ट्रीम पोर्ट(सीडीपी) आउटपुट करंट की रेंज का इस्तेमाल किया जाना चाहिए.
यूएसबी टाइप-सी स्टैंडर्ड को लागू और इस्तेमाल करना चाहिए.

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

[C-2-1] यह यूएसबी एचआईडी क्लास के साथ काम करना चाहिए
[C-2-2] यह ज़रूरी है कि डिवाइस, यूएसबी एचआईडी के इस्तेमाल की टेबल में बताए गए एचआईडी डेटा फ़ील्ड का पता लगा सके और उन्हें मैप कर सके. साथ ही, वॉइस कमांड के इस्तेमाल के अनुरोध को KeyEvent के कॉन्स्टेंट के साथ मैप कर सके. इसके लिए, यह ज़रूरी है कि डिवाइस में ये फ़ंक्शन मौजूद हों:
- इस्तेमाल का पेज (0xC) इस्तेमाल का आईडी (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
- इस्तेमाल का पेज (0xC) इस्तेमाल का आईडी (0x0E9): KEYCODE_VOLUME_UP
- इस्तेमाल का पेज (0xC) इस्तेमाल का आईडी (0x0EA): KEYCODE_VOLUME_DOWN
- इस्तेमाल का पेज (0xC) इस्तेमाल का आईडी (0x0CF): KEYCODE_VOICE_ASSIST

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

[C-3-1] यह ज़रूरी है कि ऐप्लिकेशन, किसी भी ऐसे MTP (मीडिया ट्रांसफ़र प्रोटोकॉल) डिवाइस को पहचाने जो रिमोट तौर पर कनेक्ट हो. साथ ही, ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, और ACTION_CREATE_DOCUMENT इंटेंट की मदद से, उस डिवाइस के कॉन्टेंट को ऐक्सेस करने की सुविधा दे. .

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

[C-4-1] यूएसबी टाइप-सी स्पेसिफ़िकेशन (सेक्शन 4.5.1.3.3) के मुताबिक, ड्यूअल रोल पोर्ट की सुविधा लागू करना ज़रूरी है.
[SR] DisplayPort के साथ काम करने का सुझाव दिया जाता है. साथ ही, यह भी ज़रूरी है कि यह यूएसबी सुपरस्पीड डेटा रेट के साथ काम करे. साथ ही, डेटा और पावर की भूमिका बदलने के लिए, पावर डिलीवरी की सुविधा के साथ काम करने का सुझाव दिया जाता है.
[SR] हमारा सुझाव है कि आप यूएसबी टाइप-सी केबल और कनेक्टर स्पेसिफ़िकेशन रिविज़न 1.2 के ऐपेंडिक्स A में बताए गए तरीके के मुताबिक, ऑडियो अडैप्टर ऐक्सेसरी मोड का इस्तेमाल न करें.
डिवाइस के फ़ॉर्म फ़ैक्टर के हिसाब से, Try.* मॉडल को लागू करना चाहिए. उदाहरण के लिए, हैंडहेल्ड डिवाइस पर Try.SNK मॉडल लागू किया जाना चाहिए.

7.8. ऑडियो

7.8.1. माइक्रोफ़ोन

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

[C-1-1] android.hardware.microphone फ़ीचर कॉन्सटेंट की रिपोर्ट करना ज़रूरी है.
[C-1-2] यह सेक्शन 5.4 में बताई गई ऑडियो रिकॉर्डिंग की ज़रूरी शर्तों को पूरा करती हो.
[C-1-3] सेक्शन 5.6 में दी गई, ऑडियो के इंतज़ार के समय से जुड़ी ज़रूरी शर्तों को पूरा करना ज़रूरी है.
[SR] हमारा सुझाव है कि आप सेक्शन 7.8.3 में बताए गए तरीके से, नियर-अल्ट्रासाउंड रिकॉर्डिंग की सुविधा दें.

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

[C-2-1] android.hardware.microphone फ़ीचर कॉन्स्टेंट की रिपोर्ट नहीं करनी चाहिए.
[C-2-2] सेक्शन 7 के मुताबिक, ऑडियो रिकॉर्डिंग एपीआई को कम से कम नो-ऑप के तौर पर लागू करना ज़रूरी है.

7.8.2. ऑडियो आउटपुट

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

[C-1-1] android.hardware.audio.output फ़ीचर कॉन्सटेंट की रिपोर्ट करना ज़रूरी है.
[C-1-2] सेक्शन 5.5 में बताई गई, ऑडियो चलाने से जुड़ी ज़रूरी शर्तों को पूरा करना ज़रूरी है.
[C-1-3] सेक्शन 5.6 में दी गई, ऑडियो के इंतज़ार के समय से जुड़ी ज़रूरी शर्तों को पूरा करना ज़रूरी है.
[SR] हमारा सुझाव है कि आप सेक्शन 7.8.3 में बताए गए तरीके से, नियर-अल्ट्रासाउंड प्लेलबैक की सुविधा जोड़ें.

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

[C-2-1] android.hardware.audio.output सुविधा की शिकायत नहीं की जानी चाहिए.
[C-2-2] ऑडियो आउटपुट से जुड़े एपीआई को कम से कम नो-ऑप के तौर पर लागू करना ज़रूरी है.

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

7.8.2.1. ऐनालॉग ऑडियो पोर्ट

Android के सभी डिवाइसों पर 3.5 मि॰मी॰ के ऑडियो प्लग का इस्तेमाल करके, हेडसेट और अन्य ऑडियो ऐक्सेसरी के साथ काम करने के लिए, अगर किसी डिवाइस में एक या उससे ज़्यादा एनालॉग ऑडियो पोर्ट शामिल हैं, तो कम से कम एक ऑडियो पोर्ट, चार कंडक्टर वाला 3.5 मि॰मी॰ का ऑडियो जैक होना चाहिए.

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

[C-1-1] माइक्रोफ़ोन वाले स्टीरियो हेडफ़ोन और स्टीरियो हेडसेट पर ऑडियो चलाने की सुविधा होनी चाहिए.
[C-1-2] CTIA पिन-आउट ऑर्डर के साथ TRRS ऑडियो प्लग काम करने चाहिए.
[C-1-3] ऑडियो प्लग पर माइक्रोफ़ोन और ग्राउंड कंडक्टर के बीच, इवैलेंट इंपेडेन्स की इन तीन रेंज के लिए, कीकोड का पता लगाने और उन्हें मैप करने की सुविधा होनी चाहिए:
- 70 ओम या उससे कम: KEYCODE_HEADSETHOOK
- 210-290 ओम: KEYCODE_VOLUME_UP
- 360-680 ओम: KEYCODE_VOLUME_DOWN
[C-1-4] प्लग डालने पर, ACTION_HEADSET_PLUG को ट्रिगर करना चाहिए. हालांकि, ऐसा सिर्फ़ तब करना चाहिए, जब प्लग के सभी संपर्क, जैक पर उनके काम के सेगमेंट को छू रहे हों.
[C-1-5] यह ज़रूरी है कि यह 32 ओम स्पीकर इंपेडेन्स पर, कम से कम 150mV ± 10% आउटपुट वोल्टेज दे सके.
[C-1-6] माइक्रोफ़ोन का बायस वोल्टेज 1.8V से 2.9V के बीच होना चाहिए.
[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 API की मदद से, यह सही तरीके से रिपोर्ट करना ज़रूरी है कि आपके ऐप्लिकेशन में नियर-अल्ट्रासाउंड ऑडियो की सुविधा काम करती है या नहीं. इसके लिए, यह तरीका अपनाएं:

अगर PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND "सही" है, तो VOICE_RECOGNITION और UNPROCESSED ऑडियो सोर्स को इन ज़रूरी शर्तों को पूरा करना होगा:

[C-1-1] माइक्रोफ़ोन की औसत पावर रिस्पॉन्स, 18.5 किलोहर्ट्ज़ से 20 किलोहर्ट्ज़ बैंड में, 2 किलोहर्ट्ज़ पर रिस्पॉन्स से 15 डीबी से ज़्यादा नहीं होनी चाहिए.
[C-1-2] माइक्रोफ़ोन का बिना वेट किए गए सिग्नल-टू-नॉइज़ रेशियो, 18.5 केएचज़ से 20 केएचज़ तक होना चाहिए. साथ ही, -26 डीबीएफ़एस पर 19 केएचज़ टोन के लिए, यह रेशियो 50 डीबी से कम नहीं होना चाहिए.

अगर PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND "सही" है, तो:

[C-2-1] स्पीकर का औसत रिस्पॉन्स 18.5 kHz से 20 kHz के बीच, 2 kHz के रिस्पॉन्स से कम से कम 40 dB कम होना चाहिए.

7.9. आभासी वास्तविकता

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

7.9.1. वर्चुअल रिएलिटी मोड

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

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

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

[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 हार्डवेयर लेवल 0 के साथ काम करना चाहिए. साथ ही, Vulkan हार्डवेयर लेवल 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 को लागू करना ज़रूरी है. साथ ही, उपलब्ध ईजीएल एक्सटेंशन की सूची में एक्सटेंशन दिखाना ज़रूरी है.
[C-1-7] जीपीयू और डिसप्ले, शेयर किए गए फ़्रंट बफ़र को सिंक कर पाएं. इससे, दो रेंडर कॉन्टेक्स्ट के साथ 60fps पर, वैकल्पिक आंखों से रेंडर किए गए वीआर कॉन्टेंट को बिना किसी टियरिंग आर्टफ़ैक्ट के दिखाया जा सकेगा.
[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-40 एमबीपीएस (1920x1080@30fps-10 एमबीपीएस के चार इंस्टेंस या 1920x1080@60fps-20 एमबीपीएस के दो इंस्टेंस के बराबर) पर H.264 डिकोडिंग की सुविधा दे.
[C-1-12] यह एचईवीसी और VP9 के साथ काम करना चाहिए. साथ ही, यह कम से कम 1920x1080@30fps-10 एमबीपीएस को डिकोड करने में सक्षम होना चाहिए. साथ ही, यह 3840x2160@30fps-20 एमबीपीएस (1920x1080@30fps-5 एमबीपीएस के चार इंस्टेंस के बराबर) को डिकोड करने में सक्षम होना चाहिए.
[C-1-13] यह HardwarePropertiesManager.getDeviceTemperatures एपीआई के साथ काम करना चाहिए और त्वचा के तापमान की सटीक वैल्यू दिखाना चाहिए.
[C-1-14] इसमें एम्बेड की गई स्क्रीन होनी चाहिए. साथ ही, इसका रिज़ॉल्यूशन कम से कम फ़ुल एचडी(1080 पिक्सल) होना चाहिए. हमारा सुझाव है कि इसका रिज़ॉल्यूशन क्वाड एचडी (1440 पिक्सल) या उससे ज़्यादा होना चाहिए.
[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 पार्टीशन) पर फ़ाइल ऐक्सेस करने की परफ़ॉर्मेंस को एक जैसा रखने के लिए, एक सामान्य बेसलाइन उपलब्ध कराने से, ऐप्लिकेशन डेवलपर को सही उम्मीद सेट करने में मदद मिलती है. इससे, उन्हें अपने सॉफ़्टवेयर के डिज़ाइन में मदद मिलती है. डिवाइस के टाइप के हिसाब से, डिवाइस में लागू करने के लिए, यहां दिए गए पढ़ने और लिखने के ऑपरेशन के लिए, सेक्शन 2 में बताई गई कुछ ज़रूरी शर्तें हो सकती हैं:

सीक्वेंशियल राइटिंग की परफ़ॉर्मेंस. इसे मेज़र करने के लिए, 10 एमबी के राइट बफ़र का इस्तेमाल करके 256 एमबी की फ़ाइल लिखी जाती है.
रैंडम राइटिंग की परफ़ॉर्मेंस. इसे मेज़र करने के लिए, 4 केबी के राइट बफ़र का इस्तेमाल करके 256 एमबी की फ़ाइल लिखी जाती है.
सीक्वेंशियल रीड परफ़ॉर्मेंस. इसे 10 एमबी के राइट बफ़र का इस्तेमाल करके, 256 एमबी की फ़ाइल को पढ़कर मेज़र किया जाता है.
रैंडम रीड परफ़ॉर्मेंस. इसे मेज़र करने के लिए, 4 केबी के राइट बफ़र का इस्तेमाल करके 256 एमबी की फ़ाइल को पढ़ा जाता है.

8.3. बैटरी सेव करने वाले मोड

Android में, बैटरी के इस्तेमाल को ऑप्टिमाइज़ करने के लिए, ऐप्लिकेशन स्टैंडबाय और Doze मोड शामिल हैं. [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() एपीआई के तरीके से, यह सटीक तौर पर बताया जाना चाहिए कि ऐप्लिकेशन में बेहतर परफ़ॉर्मेंस मोड की सुविधा काम करती है या नहीं.
यह बेहतर परफ़ॉर्मेंस वाले मोड के साथ काम करना चाहिए.

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

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

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

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

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

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

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

[C-3-1] Process.getExclusiveCores() एपीआई के तरीके से, खाली सूची दिखानी चाहिए.

9. सुरक्षा मॉडल के साथ काम करने की सुविधा

डिवाइस पर लागू करने के तरीके:

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

9.1. अनुमतियां

डिवाइस पर लागू करने के तरीके:

[C-0-1] यह Android अनुमतियों के मॉडल के साथ काम करना चाहिए, जैसा कि Android डेवलपर के दस्तावेज़ में बताया गया है. खास तौर पर, उन्हें SDK टूल के दस्तावेज़ में बताई गई हर अनुमति को लागू करना होगा. किसी भी अनुमति को हटाया, बदला या अनदेखा नहीं किया जा सकता.
ज़्यादा अनुमतियां जोड़ी जा सकती हैं. हालांकि, इसके लिए ज़रूरी है कि अनुमति की नई आईडी स्ट्रिंग, android.\* नेमस्पेस में न हों.
[C-0-2] PROTECTION_FLAG_PRIVILEGED के protectionLevel वाली अनुमतियां, सिर्फ़ उन ऐप्लिकेशन को दी जानी चाहिए जिन्हें सिस्टम इमेज के खास पाथ में पहले से लोड किया गया है. साथ ही, ये अनुमतियां हर ऐप्लिकेशन के लिए, साफ़ तौर पर अनुमति वाली सूची के सबसेट में होनी चाहिए. AOSP, etc/permissions/ पाथ में मौजूद फ़ाइलों से हर ऐप्लिकेशन के लिए, अनुमति वाली सूची को पढ़कर और उसे लागू करके इस ज़रूरी शर्त को पूरा करता है. साथ ही, system/priv-app पाथ को खास पाथ के तौर पर इस्तेमाल करता है.

सुरक्षा के लेवल के हिसाब से, खतरनाक अनुमतियां रनटाइम अनुमतियां होती हैं. जिन ऐप्लिकेशन में targetSdkVersion > 22 है वे रनटाइम के दौरान इनका अनुरोध करते हैं.

डिवाइस पर लागू करने के तरीके:

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

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

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

9.3. फ़ाइल सिस्टम की अनुमतियां

डिवाइस पर लागू करने के तरीके:

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

9.4. एक्ज़ीक्यूशन के अन्य एनवायरमेंट

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

[C-0-1] वैकल्पिक रनटाइम, Android ऐप्लिकेशन होने चाहिए. साथ ही, वे सेक्शन 9 में बताए गए स्टैंडर्ड Android सुरक्षा मॉडल का पालन करने चाहिए.
[C-0-2] अन्य रनटाइम को उन संसाधनों का ऐक्सेस नहीं दिया जाना चाहिए जिन्हें <uses-permission> तरीके से, रनटाइम की AndroidManifest.xml फ़ाइल में अनुरोध नहीं किया गया है.
[C-0-3] अन्य रनटाइम को ऐप्लिकेशन को उन सुविधाओं का इस्तेमाल करने की अनुमति नहीं देनी चाहिए जिन्हें Android की अनुमतियों से सुरक्षित किया गया है और जिनका इस्तेमाल सिर्फ़ सिस्टम ऐप्लिकेशन कर सकते हैं.
[C-0-4] किसी अन्य रनटाइम का इस्तेमाल करने वाले ऐप्लिकेशन को, Android सैंडबॉक्स मॉडल का पालन करना ज़रूरी है. साथ ही, डिवाइस पर इंस्टॉल किए गए किसी भी अन्य ऐप्लिकेशन के सैंडबॉक्स का दोबारा इस्तेमाल नहीं किया जाना चाहिए. हालांकि, शेयर किए गए उपयोगकर्ता आईडी और साइनिंग सर्टिफ़िकेट के स्टैंडर्ड Android तरीके का इस्तेमाल करके, ऐसा किया जा सकता है.
[C-0-5] अन्य रनटाइम, Android के अन्य ऐप्लिकेशन के सैंडबॉक्स के साथ लॉन्च नहीं होने चाहिए, उन्हें सैंडबॉक्स का ऐक्सेस नहीं देना चाहिए, और न ही उन्हें सैंडबॉक्स का ऐक्सेस दिया जाना चाहिए.
[C-0-6] अन्य रनटाइम को सुपर उपयोगकर्ता (रूट) या किसी अन्य उपयोगकर्ता आईडी की अनुमतियों के साथ लॉन्च नहीं किया जाना चाहिए. साथ ही, उन्हें अन्य ऐप्लिकेशन को भी ये अनुमतियां नहीं देनी चाहिए.
[C-0-7] जब डिवाइस पर लागू किए गए सिस्टम की इमेज में, अन्य रनटाइम की .apk फ़ाइलें शामिल की जाती हैं, तो उस पर ऐसी कुंजी से हस्ताक्षर करना ज़रूरी है जो डिवाइस पर लागू किए गए अन्य ऐप्लिकेशन पर हस्ताक्षर करने के लिए इस्तेमाल की गई कुंजी से अलग हो.
[C-0-8] ऐप्लिकेशन इंस्टॉल करते समय, अन्य रनटाइम को ऐप्लिकेशन के लिए इस्तेमाल की जाने वाली Android अनुमतियों के लिए, उपयोगकर्ता की सहमति लेनी होगी.
[C-0-9] जब किसी ऐप्लिकेशन को किसी ऐसे डिवाइस संसाधन का इस्तेमाल करना हो जिसके लिए Android की अनुमति (जैसे, कैमरा, जीपीएस वगैरह) हो, तो वैकल्पिक रनटाइम को उपयोगकर्ता को यह बताना होगा कि ऐप्लिकेशन उस संसाधन को ऐक्सेस कर पाएगा.
[C-0-10] अगर रनटाइम एनवायरमेंट, ऐप्लिकेशन की क्षमताओं को इस तरीके से रिकॉर्ड नहीं करता है, तो रनटाइम एनवायरमेंट को उस रनटाइम का इस्तेमाल करके किसी भी ऐप्लिकेशन को इंस्टॉल करते समय, रनटाइम के पास मौजूद सभी अनुमतियों की सूची बनानी होगी.
अन्य रनटाइम को PackageManager के ज़रिए, अलग-अलग Android सैंडबॉक्स (Linux उपयोगकर्ता आईडी वगैरह) में ऐप्लिकेशन इंस्टॉल करने चाहिए.
वैकल्पिक रनटाइम, एक ही Android सैंडबॉक्स उपलब्ध करा सकते हैं. इसे वैकल्पिक रनटाइम का इस्तेमाल करने वाले सभी ऐप्लिकेशन शेयर करते हैं.

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

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

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

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

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

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

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

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

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

9.6. प्रीमियम एसएमएस की चेतावनी

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

अगर डिवाइस पर android.hardware.telephony की सुविधा काम करती है, तो:

[C-1-1] डिवाइस में /data/misc/sms/codes.xml फ़ाइल में बताई गई रेगुलर एक्सप्रेशन से पहचाने गए नंबरों पर एसएमएस भेजने से पहले, उपयोगकर्ताओं को चेतावनी देनी ज़रूरी है. अपस्ट्रीम Android Open Source Project, इस ज़रूरी शर्त को पूरा करने वाला तरीका उपलब्ध कराता है.

9.7. कर्नेल की सुरक्षा से जुड़ी सुविधाएं

Android सैंडबॉक्स में ऐसी सुविधाएं शामिल हैं जो Linux kernel में, सुरक्षा के लिए बेहतर बनाए गए Linux (SELinux) के ज़रूरी ऐक्सेस कंट्रोल (MAC) सिस्टम, seccomp सैंडबॉक्सिंग, और सुरक्षा से जुड़ी अन्य सुविधाओं का इस्तेमाल करती हैं. डिवाइस पर लागू करने के तरीके:

[C-0-1] यह ज़रूरी है कि मौजूदा ऐप्लिकेशन के साथ काम करने की सुविधा बनी रहे. भले ही, Android फ़्रेमवर्क के नीचे SELinux या सुरक्षा से जुड़ी कोई अन्य सुविधा लागू की गई हो.
[C-0-2] सुरक्षा से जुड़ा उल्लंघन होने पर, यूज़र इंटरफ़ेस (यूआई) नहीं दिखना चाहिए. यह तब दिख सकता है, जब Android फ़्रेमवर्क के नीचे लागू की गई सुरक्षा सुविधा से उल्लंघन को ब्लॉक नहीं किया जा सके और इसका फ़ायदा उठाया जा सके.
[C-0-3] Android फ़्रेमवर्क के नीचे लागू की गई SELinux या सुरक्षा से जुड़ी अन्य सुविधाओं को, उपयोगकर्ता या ऐप्लिकेशन डेवलपर के लिए कॉन्फ़िगर नहीं किया जाना चाहिए.
[C-0-4] किसी ऐसे ऐप्लिकेशन को नीति कॉन्फ़िगर करने की अनुमति नहीं देनी चाहिए जो किसी एपीआई (जैसे, डिवाइस एडमिनिस्ट्रेशन एपीआई) के ज़रिए किसी दूसरे ऐप्लिकेशन पर असर डाल सकता है. ऐसा करने से, ऐप्लिकेशन के साथ काम करने की सुविधा बंद हो सकती है.
[C-0-5] मीडिया फ़्रेमवर्क को कई प्रोसेस में बांटना ज़रूरी है, ताकि Android Open Source Project की साइट पर बताए गए तरीके से, हर प्रोसेस के लिए ऐक्सेस को ज़्यादा सटीक तरीके से दिया जा सके.
[C-0-6] यह ज़रूरी है कि कर्नेल ऐप्लिकेशन सैंडबॉक्सिंग का ऐसा तरीका लागू किया जाए जिससे मल्टी-थ्रेड वाले प्रोग्राम से, कॉन्फ़िगर की जा सकने वाली नीति का इस्तेमाल करके सिस्टम कॉल को फ़िल्टर किया जा सके. अपस्ट्रीम Android Open Source Project, source.android.com के कर्नेल कॉन्फ़िगरेशन सेक्शन में बताए गए तरीके से, थ्रेडग्रुप सिंक्रोनाइज़ेशन (TSYNC) के साथ seccomp-BPF को चालू करके इस ज़रूरी शर्त को पूरा करता है.

Android की सुरक्षा के लिए, कर्नेल इंटिग्रिटी और खुद को सुरक्षित रखने की सुविधाएं ज़रूरी हैं. डिवाइस पर लागू करने के तरीके:

[C-0-7] कर्नल स्टैक बफ़र ओवरफ़्लो की सुरक्षा लागू करना ज़रूरी है. जैसे, CONFIG_CC_STACKPROTECTOR_STRONG.
[C-0-8] जहां सिर्फ़ पढ़ने के लिए उपलब्ध कोड, सिर्फ़ पढ़ने के लिए उपलब्ध डेटा, और लिखने के लिए उपलब्ध डेटा, सभी को एक साथ इस्तेमाल नहीं किया जा सकता, वहां कर्नेल मेमोरी की सुरक्षा के सख्त उपाय लागू करने होंगे. जैसे, CONFIG_DEBUG_RODATA या CONFIG_STRICT_KERNEL_RWX.
[SR] हमारा सुझाव है कि सिर्फ़ शुरुआती सेटअप के दौरान लिखे गए कर्नेल डेटा को, सेटअप के बाद रीड-ओनली के तौर पर मार्क करें. जैसे, __ro_after_init.
[SR} हमारा सुझाव है कि यूज़र-स्पेस और कर्नेल-स्पेस (उदाहरण के लिए, CONFIG_HARDENED_USERCOPY) के बीच कॉपी के स्टैटिक और डाइनैमिक ऑब्जेक्ट साइज़ की जांच लागू करें.
[SR] हमारा सुझाव है कि उपयोगकर्ता-स्पेस मेमोरी को कभी भी कर्नेल में चलाने से बचें. जैसे, हार्डवेयर PXN या CONFIG_CPU_SW_DOMAIN_PAN या CONFIG_ARM64_SW_TTBR0_PAN के ज़रिए एमुलेट किया गया.
[SR] हमारा सुझाव है कि यूज़र-कॉपी ऐक्सेस एपीआई (जैसे, हार्डवेयर पैन या CONFIG_CPU_SW_DOMAIN_PAN या CONFIG_ARM64_SW_TTBR0_PAN के ज़रिए एमुलेट किया गया) के अलावा, कर्नेल में यूज़र-स्पेस मेमोरी को कभी न पढ़ें या उसमें न लिखें.
[SR] हमारा सुझाव है कि आप कर्नेल कोड और मेमोरी के लेआउट को रैंडमाइज़ करें.साथ ही, ऐसे एक्सपोज़र से बचें जिनसे रैंडमाइज़ेशन की सुविधा को नुकसान पहुंच सकता है. उदाहरण के लिए, /chosen/kaslr-seed Device Tree node या EFI_RNG_PROTOCOL की मदद से, बूटलोडर एन्ट्रोपी के साथ CONFIG_RANDOMIZE_BASE.

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

[C-1-1] SELinux को लागू करना ज़रूरी है.
[C-1-2] SELinux को ग्लोबल लागू करने वाले मोड पर सेट करना ज़रूरी है.
[C-1-3] सभी डोमेन को लागू करने के मोड में कॉन्फ़िगर करना ज़रूरी है. अनुमति वाले मोड के डोमेन इस्तेमाल करने की अनुमति नहीं है. इनमें किसी डिवाइस/वेंडर के लिए खास तौर पर बनाए गए डोमेन भी शामिल हैं.
[C-1-4] अपस्ट्रीम Android Open Source Project (AOSP) में दिए गए system/sepolicy फ़ोल्डर में मौजूद, 'कभी भी अनुमति न दें' नियमों में बदलाव नहीं किया जाना चाहिए, उन्हें हटाया नहीं जाना चाहिए या उन्हें बदला नहीं जाना चाहिए. साथ ही, नीति को AOSP SELinux डोमेन के साथ-साथ डिवाइस/वेंडर के हिसाब से बनाए गए डोमेन, दोनों के लिए मौजूद 'कभी भी अनुमति न दें' नियमों के साथ कंपाइल किया जाना चाहिए.
Android Open Source Project के system/sepolicy फ़ोल्डर में दी गई डिफ़ॉल्ट SELinux नीति को बनाए रखना चाहिए. साथ ही, इस नीति में सिर्फ़ अपने डिवाइस के हिसाब से कॉन्फ़िगरेशन के लिए बदलाव करना चाहिए.

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

[C-2-1] ज़रूरी ऐक्सेस कंट्रोल सिस्टम का इस्तेमाल करना चाहिए, जो SELinux के बराबर हो.

9.8. निजता

9.8.1. इस्तेमाल का इतिहास

Android, उपयोगकर्ता की पसंद का इतिहास सेव करता है और UsageStatsManager की मदद से इस इतिहास को मैनेज करता है.

डिवाइस पर लागू करने के तरीके:

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

9.8.2. रिकॉर्डिंग

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

[C-1-1] जब भी यह सुविधा चालू हो और कैप्चर/रिकॉर्डिंग की जा रही हो, तो उपयोगकर्ता को इसकी सूचना दी जानी चाहिए.

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

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

9.8.3. कनेक्टिविटी

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

9.8.4. नेटवर्क ट्रैफ़िक

डिवाइस पर लागू करने के तरीके:

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

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

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

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

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

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

[C-3-1] AndroidManifest.xml फ़ाइल में, हमेशा चालू रहने वाली वीपीएन सेवा के साथ काम न करने वाले ऐप्लिकेशन के लिए, इस सुविधा को बंद करना ज़रूरी है. इसके लिए, SERVICE_META_DATA_SUPPORTS_ALWAYS_ON एट्रिब्यूट को false पर सेट करें.

9.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 इंटेंट को अब भी ब्रॉडकास्ट किया जाना चाहिए, ताकि डायरेक्ट बूट की सुविधा वाले ऐप्लिकेशन को यह सिग्नल दिया जा सके कि डिवाइस एन्क्रिप्ट (DE) और क्रेडेंशियल एन्क्रिप्ट (CE) स्टोरेज की जगहें, उपयोगकर्ता के लिए उपलब्ध हैं.

9.9.2. फ़ाइल के आधार पर एन्क्रिप्ट (सुरक्षित) करने का तरीका

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

[C-1-1] डिवाइस को उपयोगकर्ता से क्रेडेंशियल मांगे बिना, तुरंत चालू होना चाहिए. साथ ही, ACTION_LOCKED_BOOT_COMPLETED मैसेज ब्रॉडकास्ट होने के बाद, डिवाइस को सीधे चालू करने की सुविधा वाले ऐप्लिकेशन को डिवाइस के एन्क्रिप्ट किए गए (DE) स्टोरेज को ऐक्सेस करने की अनुमति देनी चाहिए.
[C-1-2] उपयोगकर्ता के डिवाइस को अनलॉक करने के बाद ही, क्रेडेंशियल एन्क्रिप्ट (सीई) स्टोरेज को ऐक्सेस करने की अनुमति दी जानी चाहिए. इसके लिए, उपयोगकर्ता को अपने क्रेडेंशियल (जैसे, पासकोड, पिन, पैटर्न या फ़िंगरप्रिंट) डालने होंगे और ACTION_USER_UNLOCKED मैसेज ब्रॉडकास्ट किया जाना चाहिए.
[C-1-3] उपयोगकर्ता से मिले क्रेडेंशियल के बिना, सीई से सुरक्षित स्टोरेज को अनलॉक करने का कोई तरीका नहीं दिया जाना चाहिए.
[C-1-4] यह ज़रूरी है कि डिवाइस में, पुष्टि किए गए बूट मोड की सुविधा काम करती हो. साथ ही, यह भी पक्का करना होगा कि डीई कुंजियां, क्रिप्टोग्राफ़िक तरीके से डिवाइस के हार्डवेयर रूट ऑफ़ ट्रस्ट से जुड़ी हों.
[C-1-5] यह ज़रूरी है कि XTS मोड में, 256-बिट की कुंजी का इस्तेमाल करके, फ़ाइल के कॉन्टेंट को एईएस से एन्क्रिप्ट किया जा सके.
[C-1-6] यह ज़रूरी है कि एईएस का इस्तेमाल करके, फ़ाइल के नाम को एन्क्रिप्ट करने की सुविधा हो. इसके लिए, सीबीसी-सीटीएस मोड में 256-बिट की कुंजी का इस्तेमाल किया जाना चाहिए.
सीई और डीई स्टोरेज एरिया को सुरक्षित रखने वाली कुंजियां:
[C-1-7] यह ज़रूरी है कि इसे क्रिप्टोग्राफ़िक तरीके से, हार्डवेयर के साथ काम करने वाले पासकोड स्टोर से जोड़ा गया हो.
[C-1-8] सीई पासकोड, उपयोगकर्ता की लॉक स्क्रीन के क्रेडेंशियल से बंधे होने चाहिए.
[C-1-9] अगर उपयोगकर्ता ने लॉक स्क्रीन के क्रेडेंशियल नहीं दिए हैं, तो सीई कुंजियों को डिफ़ॉल्ट पासवर्ड से बंधा होना चाहिए.
[C-1-10] यह यूनीक और अलग-अलग होनी चाहिए. दूसरे शब्दों में, किसी भी उपयोगकर्ता की सीई या डीई कुंजी, किसी दूसरे उपयोगकर्ता की सीई या डीई कुंजी से मेल नहीं खाती.
पहले से लोड किए गए ज़रूरी ऐप्लिकेशन (जैसे, अलार्म, फ़ोन, मैसेंजर) को डायरेक्ट बूट के बारे में जानकारी देनी चाहिए.
फ़ाइल के कॉन्टेंट और फ़ाइल के नाम को एन्क्रिप्ट (सुरक्षित) करने के लिए, अन्य सिफर, कुंजी की लंबाई, और मोड का इस्तेमाल किया जा सकता है. हालांकि, डिफ़ॉल्ट रूप से उन सिफर, कुंजी की लंबाई, और मोड का इस्तेमाल करना ज़रूरी है जिनका इस्तेमाल किया जा सकता है.

अपस्ट्रीम Android Open Source प्रोजेक्ट, Linux kernel ext4 एन्क्रिप्शन की सुविधा के आधार पर, इस सुविधा को लागू करने का सबसे सही तरीका उपलब्ध कराता है.

9.9.3. पूरी ड्राइव को एन्क्रिप्ट (सुरक्षित) करना

अगर डिवाइस पर पूरी ड्राइव को सुरक्षित रखने की सुविधा (एफ़डीई) काम करती है, तो:

[C-1-1] एईएस का इस्तेमाल 128-बिट (या उससे ज़्यादा) की कुंजी और स्टोरेज के लिए डिज़ाइन किए गए मोड (उदाहरण के लिए, AES-XTS, AES-CBC-ESSIV) के साथ करना ज़रूरी है.
[C-1-2] एन्क्रिप्शन पासकोड को रैप करने के लिए, डिफ़ॉल्ट पासकोड का इस्तेमाल करना ज़रूरी है. साथ ही, एन्क्रिप्ट किए बिना, एन्क्रिप्शन पासकोड को कभी भी स्टोरेज में नहीं लिखना चाहिए.
[C-1-3] एन्क्रिप्शन पासकोड को डिफ़ॉल्ट रूप से एईएस एन्क्रिप्ट (सुरक्षित) करना चाहिए. ऐसा तब तक करना चाहिए, जब तक उपयोगकर्ता साफ़ तौर पर ऑप्ट आउट न कर दे. हालांकि, जब लॉक स्क्रीन के क्रेडेंशियल का इस्तेमाल किया जा रहा हो, तब ऐसा नहीं करना चाहिए. इसके लिए, लॉक स्क्रीन के क्रेडेंशियल को धीमी गति से स्ट्रेच करने वाले एल्गोरिदम (जैसे, PBKDF2 या स्क्रिप्ट) का इस्तेमाल किया जाना चाहिए.
[C-1-4] जब उपयोगकर्ता ने लॉक स्क्रीन के क्रेडेंशियल नहीं दिए हों या एन्क्रिप्शन के लिए पासवर्ड का इस्तेमाल बंद कर दिया हो और डिवाइस पर हार्डवेयर की मदद से काम करने वाला पासकोड उपलब्ध हो, तो पासवर्ड को बड़ा करने वाला ऊपर दिया गया डिफ़ॉल्ट एल्गोरिदम, उस पासकोड से क्रिप्टोग्राफ़िक तरीके से जुड़ा होना चाहिए.
[C-1-5] एन्क्रिप्शन पासकोड को डिवाइस से बाहर नहीं भेजना चाहिए. भले ही, उसे उपयोगकर्ता के पासवर्ड और/या हार्डवेयर बाउंड पासकोड से रैप किया गया हो.

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

अपस्ट्रीम Android Open Source Project, external/avb/ रिपॉज़िटरी में इस सुविधा को लागू करने का सुझाव देता है. इसे Android को लोड करने के लिए इस्तेमाल किए जाने वाले बूट लोडर में इंटिग्रेट किया जा सकता है.

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

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

9.11.1. सुरक्षित लॉक स्क्रीन

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

[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-2-1] यह उपयोगकर्ता की पुष्टि करने का ऐसा तरीका होना चाहिए जैसा कि कुंजी के इस्तेमाल के लिए उपयोगकर्ता की पुष्टि करना ज़रूरी है में बताया गया है.
[C-2-2] उपयोगकर्ता के सुरक्षित लॉक स्क्रीन को अनलॉक करने पर, तीसरे पक्ष के डेवलपर ऐप्लिकेशन के लिए सभी कुंजियों को अनलॉक करना ज़रूरी है. उदाहरण के लिए, तीसरे पक्ष के डेवलपर ऐप्लिकेशन के लिए, सभी कुंजियां createConfirmDeviceCredentialIntent और setUserAuthenticationRequired जैसे काम के एपीआई के ज़रिए उपलब्ध होनी चाहिए.

[C-3-1] इनपुट की कम से कम अनुमति वाली लंबाई का एन्ट्रापी 10 बिट से ज़्यादा होना चाहिए.
[C-3-2] सभी संभावित इनपुट की मैक्सिमम एन्ट्रापी 18 बिट से ज़्यादा होनी चाहिए.
[C-3-3] यह ज़रूरी है कि पुष्टि करने के लिए, AOSP में लागू और दिए गए किसी भी मौजूदा तरीके (पिन, पैटर्न, पासवर्ड) की जगह न दिया जाए.
[C-3-4] जब डिवाइस नीति नियंत्रक (डीपीसी) ऐप्लिकेशन ने पासवर्ड की क्वालिटी से जुड़ी नीति को DevicePolicyManager.setPasswordQuality() तरीके से सेट किया हो, तो इसे बंद करना ज़रूरी है. साथ ही, PASSWORD_QUALITY_SOMETHING से ज़्यादा पाबंदी वाले क्वालिटी कॉन्स्टेंट का इस्तेमाल किया जाना चाहिए.

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

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

अगर सेक्शन 7.3.10 में बताए गए फ़िंगरप्रिंट सेंसर के लिए, स्पूफ़ और इंपोस्टर स्वीकार करने की दरें बराबर या उससे ज़्यादा नहीं हैं और डिवाइस नीति नियंत्रक (डीपीसी) ऐप्लिकेशन ने PASSWORD_QUALITY_BIOMETRIC_WEAK से ज़्यादा पाबंदी वाले क्वालिटी कॉन्स्टेंट के साथ, DevicePolicyManager.setPasswordQuality() तरीके से पासवर्ड की क्वालिटी से जुड़ी नीति सेट की है, तो:

[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 लागू करने वाले लोगों को इसका सुझाव दिया जाता है कि वे Android Open Source Project से, Android के रेफ़रंस और पसंदीदा वर्शन में कम से कम बदलाव करें. इससे, गड़बड़ियों का जोखिम कम हो जाएगा. इन गड़बड़ियों की वजह से, डिवाइसों के साथ काम करने में समस्याएं आती हैं. इन गड़बड़ियों को ठीक करने के लिए, डिवाइसों को फिर से अपडेट करना पड़ता है.

10.1. Compatibility Test Suite

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

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

10.2. सीटीएस की पुष्टि करने वाला टूल

डिवाइस को लागू करने के लिए, CTS की पुष्टि करने वाले टूल में लागू होने वाले सभी केस सही तरीके से लागू होने चाहिए. CTS Verifier, Compatibility Test Suite में शामिल है. इसे कोई व्यक्ति चलाता है, ताकि उन सुविधाओं की जांच की जा सके जिनकी जांच ऑटोमेटेड सिस्टम से नहीं की जा सकती. जैसे, कैमरे और सेंसर की सही तरीके से काम करना.

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

जैसा कि ऊपर बताया गया है, हर डिवाइस और हर बिल्ड में CTS Verifier सही तरीके से चलना चाहिए. हालांकि, कई बिल्ड काफ़ी मिलते-जुलते होते हैं. इसलिए, डिवाइस लागू करने वाले लोगों को उन बिल्ड पर सीटीएस की पुष्टि करने वाले टूल को साफ़ तौर पर चलाने की ज़रूरत नहीं है जो सिर्फ़ मामूली अंतरों में अलग होते हैं. खास तौर पर, डिवाइस के ऐसे वर्शन जो सिर्फ़ शामिल की गई स्थानीय भाषाओं, ब्रैंडिंग वगैरह के सेट की वजह से, CTS की पुष्टि करने वाले टूल से पास हुए वर्शन से अलग हैं, उन्हें CTS की पुष्टि करने वाले टूल से टेस्ट करने की ज़रूरत नहीं है.

11. अपडेट किया जा सकने वाला सॉफ़्टवेयर

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

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

रीबूट करके ऑफ़लाइन अपडेट के साथ “ओवर-द-एयर (ओटीए)” डाउनलोड.
होस्ट पीसी से यूएसबी के ज़रिए “टैथर्ड” अपडेट.
रीबूट करने पर “ऑफ़लाइन” अपडेट और हटाने लायक स्टोरेज में मौजूद फ़ाइल से अपडेट.

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

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

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

साथ ही, डिवाइस पर A/B सिस्टम अपडेट की सुविधा काम करनी चाहिए. AOSP, बूट कंट्रोल एचएएल का इस्तेमाल करके इस सुविधा को लागू करता है.

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

Android में ऐसी सुविधाएं शामिल हैं जिनकी मदद से, डिवाइस के मालिक के ऐप्लिकेशन (अगर मौजूद हो) से सिस्टम अपडेट को कंट्रोल किया जा सकता है. इस सुविधा को आसान बनाने के लिए, android.software.device_admin की रिपोर्ट करने वाले डिवाइसों के लिए, सिस्टम अपडेट सबसिस्टम को SystemUpdatePolicy क्लास में बताए गए तरीके को लागू करना होगा.

12. दस्तावेज़ में बदलाव का लॉग

इस रिलीज़ में, कंपैटबिलिटी डेफ़िनिशन में किए गए बदलावों की खास जानकारी के लिए:

बदलावों की जानकारी देने वाला दस्तावेज़

निजी सेक्शन में हुए बदलावों की खास जानकारी के लिए:

12.1. बदलावों का लॉग देखने के बारे में सलाह

बदलावों को इस तरह मार्क किया जाता है:

सीडीडी
साथ काम करने से जुड़ी ज़रूरी शर्तों में बड़े बदलाव.
Docs
कॉस्मेटिक या बिल्ड से जुड़े बदलाव.

बेहतर तरीके से देखने के लिए, अपने बदलावों की जानकारी वाले यूआरएल में pretty=full और no-merges यूआरएल पैरामीटर जोड़ें.

13. हमसे संपर्क करें

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