1. परिचय

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

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

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

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

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

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

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

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

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

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

• डिवाइस में टचस्क्रीन होनी चाहिए.
• इसमें बैटरी जैसा कोई ऐसा पावर सोर्स होना चाहिए जिससे इसे कहीं भी ले जाया जा सके.

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

• इसमें एम्बेड की गई स्क्रीन होनी चाहिए या वीडियो आउटपुट पोर्ट शामिल होना चाहिए. जैसे, वीजीए, एचडीएमआई या डिसप्ले के लिए वायरलेस पोर्ट.
• android.software.leanback और android.hardware.type.television सुविधाओं का एलान करना ज़रूरी है.

Android स्मार्टवॉच डिवाइस से, ऐसे Android डिवाइस का मतलब है जिसे पहना जा सकता है. जैसे, कलाई पर पहना जाने वाला स्मार्टवॉच. साथ ही, यह भी ज़रूरी है कि:

• डिवाइस की स्क्रीन का डायगनल 1.1 से 2.5 इंच के बीच होना चाहिए.
• android.hardware.type.watch सुविधा का एलान करना ज़रूरी है.
• uiMode = UI_MODE_TYPE_WATCH के साथ काम करना चाहिए.

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

• डिवाइस की स्क्रीन का डायगनल 6 इंच या उससे ज़्यादा होना चाहिए.
• android.hardware.type.automotive सुविधा का एलान करना ज़रूरी है.
• uiMode = UI_MODE_TYPE_CAR के साथ काम करना चाहिए.
• Android Automotive के लागू होने पर, यह ज़रूरी है कि android.car.* नेमस्पेस में मौजूद सभी सार्वजनिक एपीआई काम करते हों.

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

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

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

कैटगरी	सुविधा	सेक्शन	हैंडहेल्ड	टेलीविज़न	देखें	Automotive	अन्य
टेक्स्ट लिखो	डी-पैड	7.2.2. बिना छुए नेविगेट करने की सुविधा		ज़रूरी है
	टचस्क्रीन	7.2.4. टचस्क्रीन इनपुट	ज़रूरी है		ज़रूरी है		चाहिए
	माइक्रोफ़ोन	7.8.1. माइक्रोफ़ोन	ज़रूरी है	चाहिए	ज़रूरी है	ज़रूरी है	चाहिए
सेंसर	एक्सलरोमीटर	7.3.1 ऐक्सेलेरोमीटर	चाहिए		चाहिए		चाहिए
	जीपीएस	7.3.3. जीपीएस	चाहिए			चाहिए
कनेक्टिविटी	वाई-फ़ाई	7.4.2. आईईईई 802.11	चाहिए	चाहिए		चाहिए	चाहिए
	Wi-Fi Direct	7.4.2.1. Wi-Fi Direct	चाहिए	चाहिए			चाहिए
	ब्लूटूथ	7.4.3. ब्लूटूथ	चाहिए	ज़रूरी है	ज़रूरी है	ज़रूरी है	चाहिए
	ब्लूटूथ कम ऊर्जा	7.4.3. ब्लूटूथ	चाहिए	ज़रूरी है	चाहिए	चाहिए	चाहिए
	सेल्युलर रेडियो	7.4.5. नेटवर्क की कम से कम क्षमता				चाहिए
	यूएसबी पेरिफ़रल/होस्ट मोड	7.7. यूएसबी	चाहिए			चाहिए	चाहिए
आउटपुट	स्पीकर और/या ऑडियो आउटपुट पोर्ट	7.8.2. ऑडियो आउटपुट	ज़रूरी है	ज़रूरी है		ज़रूरी है	ज़रूरी है

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

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

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

डिवाइस पर लागू करने के लिए, TestApi एनोटेशन (@TestApi) से मार्क की गई सभी क्लास, तरीकों, और उनसे जुड़े एलिमेंट के साथ काम करना/उनका इस्तेमाल करना ज़रूरी है.

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

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

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

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

3.2. Soft API Compatibility

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

3.2.1. अनुमतियां

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

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

Android API में android.os.Build क्लास में कई कॉन्स्टेंट शामिल होते हैं. इनका मकसद, मौजूदा डिवाइस के बारे में बताना होता है. डिवाइस के सभी इंप्लीमेंटेशन में एक जैसी और काम की वैल्यू देने के लिए, नीचे दी गई टेबल में इन वैल्यू के फ़ॉर्मैट से जुड़ी अतिरिक्त पाबंदियां शामिल हैं. डिवाइस के सभी इंप्लीमेंटेशन को इनका पालन करना ज़रूरी है.

पैरामीटर	जानकारी
VERSION.RELEASE	फ़िलहाल चल रहे Android सिस्टम का वर्शन, जिसे कोई भी व्यक्ति आसानी से पढ़ सकता है. इस फ़ील्ड में, 7.0 में दी गई स्ट्रिंग वैल्यू में से कोई एक वैल्यू होनी चाहिए.
VERSION.SDK	फ़िलहाल चल रहे Android सिस्टम का वर्शन, तीसरे पक्ष के ऐप्लिकेशन कोड के लिए ऐक्सेस किए जा सकने वाले फ़ॉर्मैट में. Android 7.0 के लिए, इस फ़ील्ड में पूरी वैल्यू 7.0_INT होनी चाहिए.
VERSION.SDK_INT	फ़िलहाल चल रहे Android सिस्टम का वर्शन, तीसरे पक्ष के ऐप्लिकेशन कोड के लिए ऐक्सेस किए जा सकने वाले फ़ॉर्मैट में. Android 7.0 के लिए, इस फ़ील्ड में पूरी वैल्यू 7.0_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:7.0/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 के सार्वजनिक सुरक्षा बुलेटिन में दिए गए पैच को छोड़कर, इस बिल्ड से मेल खाती है. यह सही वैल्यू दिखानी चाहिए. अगर ऐसा कोई बिल्ड मौजूद नहीं है, तो खाली स्ट्रिंग ("") दिखाएं.

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

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

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

• डेस्क क्लॉक
• ब्राउज़र
• Calendar
• संपर्क
• गैलरी में देखें
• GlobalSearch
• लॉन्चर
• संगीत
• सेटिंग

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• अगर डिवाइस में android.software.home_screen की सुविधा मौजूद है, तो होम स्क्रीन पर ऐप्लिकेशन की सेटिंग का डिफ़ॉल्ट मेन्यू दिखाने के लिए, android.settings.HOME_SETTINGS इंटेंट का इस्तेमाल करना ज़रूरी है.
• डिफ़ॉल्ट एसएमएस ऐप्लिकेशन बदलने के लिए डायलॉग दिखाने के लिए, android.provider.Telephony.ACTION_CHANGE_DEFAULT इंटेंट को कॉल करने वाला सेटिंग मेन्यू ज़रूर उपलब्ध कराएं. ऐसा तब करना होगा, जब डिवाइस में android.hardware.telephony की सुविधा काम कर रही हो.
• अगर डिवाइस में android.hardware.nfc.hce की सुविधा है, तो टैप करके पैसे चुकाने की सुविधा के लिए, डिफ़ॉल्ट ऐप्लिकेशन सेटिंग मेन्यू दिखाने के लिए, android.settings.NFC_PAYMENT_SETTINGS इंटेंट का इस्तेमाल करना ज़रूरी है.
• अगर डिवाइस पर android.hardware.telephony लागू करने की रिपोर्ट मिलती है, तो उपयोगकर्ता को डिफ़ॉल्ट फ़ोन ऐप्लिकेशन बदलने की अनुमति देने के लिए, डायलॉग दिखाने के लिए android.telecom.action.CHANGE_DEFAULT_DIALER इंटेंट का पालन करना चाहिए .

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

नेटिव कोड के साथ काम करना मुश्किल है. इस वजह से, डिवाइस इंप्लीमेंटर को इसका सुझाव दिया जाता है कि वे ऊपर दी गई सूची में मौजूद, Android Open Source Project से लाइब्रेरी का इस्तेमाल करें.

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

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

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

• इसमें, मैनेज किए जा रहे एनवायरमेंट में चल रहे कोड के लिए, नेटिव कोड को कॉल करने की सुविधा शामिल होनी चाहिए. इसके लिए, स्टैंडर्ड Java नेटिव इंटरफ़ेस (JNI) सेमेटिक्स का इस्तेमाल किया जाना चाहिए.
• यह सोर्स के साथ काम करने वाला (यानी हेडर के साथ काम करने वाला) और बाइनरी के साथ काम करने वाला (एबीआई के लिए) होना चाहिए. यह ज़रूरी है कि यह नीचे दी गई सूची में मौजूद हर ज़रूरी लाइब्रेरी के साथ काम करे.
• अगर 64-बिट एबीआई काम करता है, तो 32-बिट एबीआई भी काम करना चाहिए.
• डिवाइस पर काम करने वाले नेटिव ऐप्लिकेशन बाइनरी इंटरफ़ेस (एबीआई) की सटीक जानकारी देनी चाहिए. इसके लिए, android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS, और android.os.Build.SUPPORTED_64_BIT_ABIS पैरामीटर का इस्तेमाल करें. इनमें से हर पैरामीटर में, एबीआई की सूची को कॉमा लगाकर अलग-अलग किया गया है. साथ ही, इनमें एबीआई को सबसे ज़्यादा से लेकर सबसे कम प्राथमिकता के हिसाब से क्रम में लगाया गया है.
• ऊपर दिए गए पैरामीटर की मदद से, सिर्फ़ उन एबीआई की जानकारी देनी होगी जिनके बारे में Android NDK एबीआई मैनेजमेंट दस्तावेज़ के नए वर्शन में बताया गया है. साथ ही, इसमें बेहतर SIMD (जिसे NEON भी कहा जाता है) एक्सटेंशन के लिए सहायता शामिल होनी चाहिए.
• इसे अपस्ट्रीम Android Open Source Project में मौजूद सोर्स कोड और हेडर फ़ाइलों का इस्तेमाल करके बनाया जाना चाहिए

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

नेटिव कोड वाले ऐप्लिकेशन के लिए, ये नेटिव कोड एपीआई ज़रूर उपलब्ध होने चाहिए:

• 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 इंटरफ़ेस
• OpenGL के लिए सहायता, जैसा कि नीचे बताया गया है

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

ऊपर दी गई सूची में शामिल नहीं होने वाली नेटिव लाइब्रेरी, AOSP में सिस्टम लाइब्रेरी के तौर पर लागू और उपलब्ध कराई गई हैं. इन्हें तीसरे पक्ष के उन ऐप्लिकेशन के लिए उपलब्ध नहीं कराया जाना चाहिए जो एपीआई लेवल 24 या उसके बाद के वर्शन को टारगेट करते हैं.

डिवाइस में लागू करने के दौरान, AOSP लाइब्रेरी के अलावा अन्य लाइब्रेरी जोड़ी जा सकती हैं. साथ ही, उन्हें सीधे तौर पर तीसरे पक्ष के ऐप्लिकेशन के लिए एपीआई के तौर पर दिखाया जा सकता है. हालांकि, अतिरिक्त लाइब्रेरी /vendor/lib या /vendor/lib64 में होनी चाहिए और उन्हें /vendor/etc/public.libraries.txt में शामिल किया जाना चाहिए.

ध्यान दें कि डिवाइस में libGLESv3.so शामिल होना ज़रूरी है. साथ ही, NDK रिलीज़ android-24 में बताए गए सभी OpenGL ES 3.1 और Android एक्सटेंशन पैक फ़ंक्शन सिंबल को एक्सपोर्ट करना ज़रूरी है. सभी सिंबल मौजूद होने चाहिए. हालांकि, डिवाइस पर काम करने वाले OpenGL ES वर्शन और एक्सटेंशन के लिए, सिर्फ़ उन फ़ंक्शन को पूरी तरह से लागू किया जाना चाहिए.

3.3.1.1. ग्राफ़िक लाइब्रेरी

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

• इसमें हमेशा libvulkan.so नाम की नेटिव लाइब्रेरी होनी चाहिए, जो मुख्य Vulkan 1.0 API के साथ-साथ VK_KHR_surface , VK_KHR_android_surface , और VK_KHR_swapchain एक्सटेंशन के लिए फ़ंक्शन सिंबल एक्सपोर्ट करती हो.

डिवाइस पर लागू करने के लिए, Vulkan API के साथ काम करने वाले डिवाइस:

• vkEnumeratePhysicalDevices कॉल के ज़रिए, एक या उससे ज़्यादा VkPhysicalDevices की शिकायत करना ज़रूरी है.
• सूची में शामिल हर VkPhysicalDevices को Vulkan 1.0 एपीआई को पूरी तरह से लागू करना होगा.
• PackageManager#FEATURE_VULKAN_HARDWARE_LEVEL और PackageManager#FEATURE_VULKAN_HARDWARE_VERSION सुविधा फ़्लैग की सही जानकारी देना ज़रूरी है.
• libvulkan.so में vkEnumerateInstanceLayerProperties और vkEnumerateDeviceLayerProperties फ़ंक्शन की मदद से, ऐप्लिकेशन पैकेज की नेटिव लाइब्रेरी डायरेक्ट्री में libVkLayer*.so नाम वाली नेटिव लाइब्रेरी में मौजूद लेयर की सूची बनाना ज़रूरी है
• ऐप्लिकेशन पैकेज के बाहर मौजूद लाइब्रेरी से मिलने वाली लेयर की सूची नहीं बनानी चाहिए. इसके अलावा, जब तक ऐप्लिकेशन में android:debuggable=”true” एट्रिब्यूट मौजूद न हो, तब तक Vulkan API को ट्रैक करने या उसे इंटरसेप्ट करने के दूसरे तरीके भी नहीं देने चाहिए.

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

• vkEnumeratePhysicalDevices कॉल के ज़रिए 0 VkPhysicalDevices की रिपोर्ट करनी होगी.
• Vulkan की सुविधाओं के किसी भी फ़्लैग PackageManager#FEATURE_VULKAN_HARDWARE_LEVEL और PackageManager#FEATURE_VULKAN_HARDWARE_VERSION का एलान नहीं किया जाना चाहिए.

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

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

• एसडब्ल्यूपी और एसडब्ल्यूपीबी के लिए निर्देश
• SETEND निर्देश
• CP15ISB, CP15DSB, और CP15DMB बैरियर ऑपरेशंस

Android NDK के लेगसी वर्शन में, 32-बिट ARM नेटिव कोड से सीपीयू की सुविधाओं का पता लगाने के लिए, /proc/cpuinfo का इस्तेमाल किया जाता था. इस NDK का इस्तेमाल करके बनाए गए ऐप्लिकेशन के साथ काम करने के लिए, डिवाइसों में /proc/cpuinfo में ये लाइनें शामिल होनी चाहिए. ऐसा तब ज़रूरी है, जब 32-बिट ARM ऐप्लिकेशन इसे पढ़ते हैं:

• "सुविधाएं: " इसके बाद, डिवाइस पर काम करने वाली ARMv7 सीपीयू की वैकल्पिक सुविधाओं की सूची दी गई है.
• "सीपीयू आर्किटेक्चर: " इसके बाद, डिवाइस पर काम करने वाले सबसे बेहतर ARM आर्किटेक्चर के बारे में बताने वाला पूर्णांक (उदाहरण के लिए, "8" के लिए ARMv8 डिवाइसों).

ये ज़रूरी शर्तें सिर्फ़ तब लागू होती हैं, जब 32-बिट ARM ऐप्लिकेशन /proc/cpuinfo को पढ़ते हैं. 64-बिट ARM या नॉन-ARM ऐप्लिकेशन से पढ़े जाने पर, डिवाइसों को /proc/cpuinfo में बदलाव नहीं करना चाहिए.

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

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

प्लैटफ़ॉर्म की सुविधा android.software.webview की रिपोर्ट, किसी भी ऐसे डिवाइस पर की जानी चाहिए जो android.webkit.WebView API को पूरी तरह से लागू करता हो. साथ ही, एपीआई को पूरी तरह से लागू न करने वाले डिवाइसों पर इसकी रिपोर्ट नहीं की जानी चाहिए. Android ओपन सोर्स को लागू करने के लिए, android.webkit.WebView को लागू करने के लिए, Chromium प्रोजेक्ट के कोड का इस्तेमाल किया जाता है. वेब रेंडरिंग सिस्टम के लिए, टेस्ट का पूरा सुइट डेवलप करना मुमकिन नहीं है. इसलिए, डिवाइस में वेबव्यू लागू करने वाले लोगों को, Chromium के खास अपस्ट्रीम बिल्ड का इस्तेमाल करना होगा. खास तौर से:

• डिवाइस के android.webkit.WebView को लागू करने के लिए, Android 7.0 के लिए अपस्ट्रीम Android Open Source Project से Chromium के बिल्ड का इस्तेमाल करना ज़रूरी है. इस बिल्ड में, वेबव्यू के लिए फ़ंक्शन और सुरक्षा से जुड़ी गड़बड़ियों को ठीक करने के लिए, कुछ खास सुधार शामिल हैं.

• वेबव्यू की ओर से रिपोर्ट की गई उपयोगकर्ता एजेंट स्ट्रिंग, इस फ़ॉर्मैट में होनी चाहिए:

  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. ब्राउज़र किस-किस के साथ काम करता है

स्टैंडअलोन ब्राउज़र, WebKit के अलावा किसी अन्य ब्राउज़र टेक्नोलॉजी पर आधारित हो सकता है. हालांकि, किसी अन्य ब्राउज़र ऐप्लिकेशन का इस्तेमाल करने पर भी, तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराया गया android.webkit.WebView कॉम्पोनेंट, WebKit पर आधारित होना चाहिए. इस बारे में सेक्शन 3.4.1 में बताया गया है.

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

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

• ऐप्लिकेशन कैश मेमोरी/ऑफ़लाइन ऑपरेशन
• <video> टैग
• जियोलोकेशन

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

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

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

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

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

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

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

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

ऐसे बदलाव करने की अनुमति नहीं है :

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

“सार्वजनिक तौर पर दिखाया गया एलिमेंट” वह कॉन्स्ट्रक्ट होता है जिसे “@hide” मार्कर से नहीं सजाया गया है. इसका इस्तेमाल, अपस्ट्रीम Android सोर्स कोड में किया जाता है. दूसरे शब्दों में, डिवाइस लागू करने वाले लोगों को ऊपर बताए गए नेमस्पेस में नए एपीआई को एक्सपोज़ नहीं करना चाहिए या मौजूदा एपीआई में बदलाव नहीं करना चाहिए. डिवाइस लागू करने वाले लोग, सिर्फ़ अंदरूनी बदलाव कर सकते हैं. हालांकि, उन बदलावों का विज्ञापन नहीं किया जाना चाहिए या डेवलपर को उनका पता नहीं चलना चाहिए.

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

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

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

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

डिवाइस पर लागू किए गए वर्शन में, पूरी तरह से काम करने वाले Dalvik Executable (DEX) फ़ॉर्मैट और Dalvik बाइटकोड स्पेसिफ़िकेशन और सेमेंटेक्स का इस्तेमाल किया जाना चाहिए. डिवाइस में इसे लागू करने वाले लोगों को ART, Dalvik Executable Format के रेफ़रंस अपस्ट्रीम लागू करने के तरीके, और रेफ़रंस लागू करने के पैकेज मैनेजमेंट सिस्टम का इस्तेमाल करना चाहिए.

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

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

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

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

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

3.8.2. विजेट

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

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

3.8.3. सूचनाएं

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

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

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

Android में कई तरह की सूचनाएं पाने की सुविधा शामिल है. जैसे:

• रिच सूचनाएं . चल रही गतिविधियों की सूचनाओं के लिए इंटरैक्टिव व्यू.
• स्क्रीन पर सबसे ऊपर सूचना देने वाला कार्ड . इंटरैक्टिव व्यू में, उपयोगकर्ता मौजूदा ऐप्लिकेशन को छोड़े बिना, उन पर कार्रवाई कर सकते हैं या उन्हें खारिज कर सकते हैं.
• लॉक स्क्रीन पर सूचनाएं . लॉक स्क्रीन पर दिखने वाली सूचनाएं. इनकी सेटिंग को ज़्यादा बेहतर तरीके से कंट्रोल किया जा सकता है.

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

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

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

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

3.8.4. खोजें

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

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

Android डिवाइस पर Assist ऐक्शन को मैनेज करने के लिए, डिवाइस पर किसी असिस्टेंट को लागू करना चाहिए. Android Automotive पर, ऐसा करना ज़रूरी है.

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

3.8.5. टोस्ट

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

3.8.6. थीम

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

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

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

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

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

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

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

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

ऊपर बताए गए तरीके से, लाइव वॉलपेपर को भरोसेमंद तरीके से चलाने वाले डिवाइसों को लाइव वॉलपेपर लागू करने चाहिए. साथ ही, लागू करने के बाद, प्लैटफ़ॉर्म की सुविधा के फ़्लैग android.software.live_wallpaper की जानकारी देनी चाहिए.

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

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

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

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

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

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

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

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

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

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

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

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

अगर किसी डिवाइस में ऐसा हार्डवेयर सेंसर (जैसे, GPS) है जो जगह की जानकारी के निर्देशांक दे सकता है, तो सेटिंग में जगह की जानकारी वाले मेन्यू में जगह की जानकारी के मोड दिखने चाहिए.

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

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

यूनिकोड तकनीकी रिपोर्ट #51 में बताए गए मुताबिक, Android के हैंडहेल्ड डिवाइसों पर, स्किन टोन और अलग-अलग फ़ैमिली इमोजी काम करने चाहिए.

Android में 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 के मुद्रा के चिह्नों वाले ब्लॉक के सभी ग्लिफ़ भी शामिल हैं.

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

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

• ऐप्लिकेशन, AndroidManifest.xml फ़ाइल में यह बता सकते हैं कि वे मल्टी-विंडो मोड में काम कर सकते हैं या नहीं. इसके लिए, वे android:resizeableActivity एट्रिब्यूट का इस्तेमाल करके साफ़ तौर पर या targetSdkVersion की वैल्यू 24 से ज़्यादा होने पर, अपने-आप यह जानकारी दे सकते हैं. जिन ऐप्लिकेशन ने अपने मेनिफ़ेस्ट में इस एट्रिब्यूट को साफ़ तौर पर 'गलत' पर सेट किया है उन्हें मल्टी-विंडो मोड में लॉन्च नहीं किया जाना चाहिए. जिन ऐप्लिकेशन ने अपनी मेनिफ़ेस्ट फ़ाइल में एट्रिब्यूट सेट नहीं किया है (targetSdkVersion < 24) उन्हें मल्टी-विंडो मोड में लॉन्च किया जा सकता है. हालांकि, सिस्टम को यह चेतावनी देनी होगी कि हो सकता है कि ऐप्लिकेशन मल्टी-विंडो मोड में उम्मीद के मुताबिक काम न करे.
• अगर स्क्रीन की ऊंचाई और चौड़ाई, दोनों 440 डीपी से कम है, तो डिवाइस पर स्प्लिट-स्क्रीन या फ़्रीफ़ॉर्म मोड की सुविधा नहीं होनी चाहिए.
• स्क्रीन साइज़ xlarge वाले डिवाइसों पर, फ़्रीफ़ॉर्म मोड काम करना चाहिए.
• Android Television डिवाइसों पर, पिक्चर में पिक्चर (पीआईपी) मोड की मल्टी-विंडो की सुविधा काम करनी चाहिए. साथ ही, पीआईपी मोड चालू होने पर, मल्टी-विंडो को सबसे ऊपर दाएं कोने में दिखाना चाहिए.
• पीआईपी मोड के मल्टी-विंडो मोड की सुविधा वाले डिवाइसों में, पीआईपी विंडो के लिए कम से कम 240x135 डीपी का फ़्रेम तय करना ज़रूरी है.
• अगर पीआईपी मल्टी-विंडो मोड काम करता है, तो पीआईपी विंडो को कंट्रोल करने के लिए KeyEvent.KEYCODE_WINDOW बटन का इस्तेमाल करना ज़रूरी है. ऐसा न होने पर, यह बटन फ़ोरग्राउंड गतिविधि के लिए उपलब्ध होना चाहिए.

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

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

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

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

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

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

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

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

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

मैनेज की जा रही प्रोफ़ाइल को उपलब्ध कराने की प्रोसेस (android.app.action.PROVISION_MANAGED_PROFILE से शुरू होने वाला फ़्लो) का उपयोगकर्ता अनुभव, AOSP के लागू होने के साथ अलाइन होना चाहिए.

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

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

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

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

• android.software.device_admin एलान करें (सेक्शन 3.9 डिवाइस एडमिन देखें).
• कम रैम वाले डिवाइसों पर उपलब्ध नहीं है (सेक्शन 7.6.1 देखें).
• डिवाइस का स्टोरेज, शेयर किया गया स्टोरेज के तौर पर तय करें. यह स्टोरेज, डिवाइस से नहीं हटाया जा सकता (सेक्शन 7.6.2 देखें).

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

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

3.10. सुलभता

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

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

• Android Automotive के लागू होने पर, Android के सुलभता फ़्रेमवर्क को डिफ़ॉल्ट रूप से लागू किया जाना चाहिए.
• डिवाइस पर लागू करने के लिए, Android के डिफ़ॉल्ट तरीके के मुताबिक Android के सुलभता फ़्रेमवर्क को लागू करना ज़रूरी है. हालांकि, Android Automotive पर ऐसा करना ज़रूरी नहीं है.
• डिवाइस पर लागू होने वाली सुविधाओं (Android Automotive को छोड़कर) के लिए, android.accessibilityservice APIs की मदद से, तीसरे पक्ष की सुलभता सेवाओं को लागू करना ज़रूरी है.
• डिवाइस पर लागू होने वाली सुविधाओं (Android Automotive को छोड़कर) को AccessibilityEvents जनरेट करने होंगे. साथ ही, इन इवेंट को रजिस्टर की गई सभी AccessibilityService को डिफ़ॉल्ट Android के तरीके से डिलीवर करना होगा

• डिवाइस पर सुलभता सेवाओं को चालू और बंद करने के लिए, उपयोगकर्ता के लिए कोई ऐसा तरीका उपलब्ध कराना ज़रूरी है जिसका इस्तेमाल किया जा सके. यह तरीका, Android Automotive और Android Watch डिवाइसों पर उपलब्ध होना चाहिए. हालांकि, जिन डिवाइसों पर ऑडियो आउटपुट की सुविधा उपलब्ध नहीं है उन्हें इस शर्त से बाहर रखा गया है. साथ ही, android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS इंटेंट के जवाब में, यह इंटरफ़ेस दिखाना ज़रूरी है.

• हमारा सुझाव है कि Android डिवाइसों पर ऑडियो आउटपुट की सुविधा लागू करें, ताकि डिवाइस पर सुलभता सेवाएं उपलब्ध कराई जा सकें. ये सेवाएं, TalkBack** और Switch Access (https://github.com/google/talkback) जैसी सुलभता सेवाओं के बराबर या उनसे बेहतर होनी चाहिए.

• ऑडियो आउटपुट वाले Android Watch डिवाइसों पर, सुलभता सेवा की ऐसी सुविधाएं होनी चाहिए जो TalkBack सुलभता सेवा (https://github.com/google/talkback) की सुविधाओं के बराबर या उससे बेहतर हों.
• डिवाइस में सुलभता सुविधाओं को लागू करने के लिए, डिवाइस के सेटअप फ़्लो में उपयोगकर्ताओं को एक सुविधा देनी चाहिए. इससे वे सुलभता से जुड़ी ज़रूरी सेवाओं को चालू कर पाएंगे. साथ ही, फ़ॉन्ट का साइज़, डिसप्ले का साइज़, और ज़ूम करने के जेस्चर में बदलाव कर पाएंगे.

** लिखाई को बोली में बदलने की सुविधा के साथ काम करने वाली भाषाओं के लिए.

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

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

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

Android Automotive को लागू करने के तरीके:

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

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

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

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

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

TIF के साथ काम करने वाले डिवाइसों को, प्लैटफ़ॉर्म की सुविधा android.software.live_tv के बारे में बताना होगा.

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

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

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

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

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

Android TV डिवाइस पर लागू होने वाले ऐप्लिकेशन में, जानकारी देने वाला और इंटरैक्टिव ओवरले दिखाना ज़रूरी है. इसमें TvContract.Programs फ़ील्ड की वैल्यू से जनरेट की गई इलेक्ट्रॉनिक प्रोग्राम गाइड (ईपीजी) शामिल होनी चाहिए. ईपीजी को ये ज़रूरी शर्तें पूरी करनी होंगी:

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

3.12.1.2. नेविगेशन

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

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

टीवी ऐप्लिकेशन को सीईसी की मदद से, एचडीएमआई इनपुट पर मुख्य इवेंट भेजने चाहिए.

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

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

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

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

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

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

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

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

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

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

3.14. वाहन के यूज़र इंटरफ़ेस (यूआई) के लिए एपीआई

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

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

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

• MediaItem आइकॉन और सूचना के आइकॉन, बिना किसी बदलाव के दिखाए जाने चाहिए.
• MediaSession में बताए गए आइटम को दिखाना ज़रूरी है. जैसे, मेटाडेटा, आइकॉन, इमेज.
• ऐप्लिकेशन का टाइटल दिखाना ज़रूरी है.
• MediaBrowser की हैरारकी दिखाने के लिए, ड्रॉअर होना ज़रूरी है.

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

डिवाइस पर लागू करने के लिए, Android “.apk” फ़ाइलों को आधिकारिक Android SDK में शामिल “aapt” टूल से जनरेट किया जाना चाहिए. साथ ही, उन्हें इंस्टॉल और चलाया जाना चाहिए. इस वजह से, डिवाइस पर लागू करने के लिए, रेफ़रंस के तौर पर इस्तेमाल किए गए पैकेज मैनेजमेंट सिस्टम का इस्तेमाल किया जाना चाहिए.

पैकेज मैनेजर को APK सिग्नेचर स्कीम v2 और JAR साइनिंग का इस्तेमाल करके, “.apk” फ़ाइलों की पुष्टि करनी चाहिए.

डिवाइसों पर लागू होने वाले वर्शन में, .apk, Android मेनिफ़ेस्ट, Dalvik बाइटकोड या RenderScript बाइटकोड फ़ॉर्मैट को इस तरह से नहीं बढ़ाया जाना चाहिए कि वे फ़ाइलें, काम करने वाले अन्य डिवाइसों पर सही तरीके से इंस्टॉल और काम न कर पाएं.

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

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

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

• Android SDK टूल के दस्तावेज़ में बताए गए मुख्य मीडिया फ़ॉर्मैट के साथ काम करना चाहिए. हालांकि, इस दस्तावेज़ में साफ़ तौर पर अनुमति दिए गए फ़ॉर्मैट के साथ काम करने की ज़रूरत नहीं है.

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

• यह CamcorderProfile में रिपोर्ट की गई सभी प्रोफ़ाइलों को भी डिकोड कर सकता है

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

कोडेक का मकसद, कोडेक के इंतज़ार का समय कम से कम करना होना चाहिए. दूसरे शब्दों में, कोडेक—

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

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

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

5.1.1. ऑडियो कोडेक

फ़ॉर्मैट/कोडेक	एन्कोडर	डिकोडर	जानकारी	इस्तेमाल किए जा सकने वाले फ़ाइल टाइप/कंटेनर फ़ॉर्मैट
MPEG-4 AAC प्रोफ़ाइल (AAC LC)	ज़रूरी है 1	ज़रूरी है	मोनो/स्टीरियो/5.0/5.1 2 ऑडियो वाले कॉन्टेंट के लिए, 8 से 48 किलोहर्ट्ज़ के स्टैंडर्ड सैंपलिंग रेट का इस्तेमाल किया जा सकता है.	3GPP (.3gp) MPEG-4 (.mp4, .m4a) ADTS रॉ AAC (.aac, Android 3.1 और उसके बाद के वर्शन में डिकोड करें, Android 4.0 और उसके बाद के वर्शन में एन्कोड करें, ADIF काम नहीं करता) एमपीईजी-टीएस (.ts, इसमें वीडियो पर आगे-पीछे नहीं जाया जा सकता, Android 3.0 और उसके बाद के वर्शन)
MPEG-4 HE AAC Profile (AAC+)	ज़रूरी 1 (Android 4.1+)	ज़रूरी है	मोनो/स्टीरियो/5.0/5.1 2 कॉन्टेंट के लिए, 16 से 48 किलोहर्ट्ज़ के स्टैंडर्ड सैंपलिंग रेट के साथ काम करता है.
MPEG-4 HE AACv2 प्रोफ़ाइल (बेहतर AAC+)		ज़रूरी है	मोनो/स्टीरियो/5.0/5.1 2 कॉन्टेंट के लिए, 16 से 48 किलोहर्ट्ज़ के स्टैंडर्ड सैंपलिंग रेट के साथ काम करता है.
AAC ELD (बेहतर कम इंतज़ार वाला AAC)	ज़रूरी 1 (Android 4.1+)	ज़रूरी है (Android 4.1+)	मोनो/स्टीरियो कॉन्टेंट के लिए, 16 से 48 किलोहर्ट्ज़ के स्टैंडर्ड सैंपलिंग रेट का इस्तेमाल किया जा सकता है.
AMR-NB	ज़रूरी है 3	ज़रूरी है 3	8 केएचज़ पर सैंपल किए गए 4.75 से 12.2 केबीपीएस	3GPP (.3gp)
AMR-WB	ज़रूरी है 3	ज़रूरी है 3	16 किलोहर्ट्ज़ पर सैंपल किए गए 6.60 केबीपीएस से 23.85 केबीपीएस तक के नौ रेट
FLAC		ज़रूरी है (Android 3.1+)	मोनो/स्टीरियो (मल्टीचैनल नहीं). सैंपल रेट 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	ज़रूरी 4 (Android 4.1+)	ज़रूरी है	16-बिट लीनियर पीसीएम (हार्डवेयर की सीमा तक रेट). डिवाइसों में, रॉ PCM रिकॉर्डिंग के लिए 8000, 11025, 16000, और 44100 हर्ट्ज़ फ़्रीक्वेंसी पर सैंपलिंग रेट की सुविधा होनी चाहिए.	WAVE (.wav)
Opus		ज़रूरी है (Android 5.0 और इसके बाद के वर्शन)		Matroska (.mkv), Ogg(.ogg)

1 यह उन डिवाइसों के लिए ज़रूरी है जिनमें android.hardware.microphone की जानकारी दी गई है. हालांकि, Android Watch डिवाइसों के लिए यह ज़रूरी नहीं है.

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

• डिकोडिंग, डाउनमिक्स किए बिना की जाती है. उदाहरण के लिए, 5.0 AAC स्ट्रीम को PCM के पांच चैनलों में डिकोड किया जाना चाहिए, 5.1 AAC स्ट्रीम को PCM के छह चैनलों में डिकोड किया जाना चाहिए,
• डाइनैमिक रेंज मेटाडेटा, जैसा कि 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

3 Android हैंडहेल्ड डिवाइस पर लागू करने के लिए ज़रूरी है.

4 यह Android Watch डिवाइस के साथ-साथ, android.hardware.microphone को डिफ़ाइन करने वाले डिवाइसों के लिए ज़रूरी है.

5.1.2. इमेज कोडेक

फ़ॉर्मैट/कोडेक	एन्कोडर	डिकोडर	जानकारी	इस्तेमाल किए जा सकने वाले फ़ाइल टाइप/कंटेनर फ़ॉर्मैट
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.3. वीडियो कोडेक

• एचडीआर प्रोफ़ाइल के साथ काम करने वाले कोडेक में, एचडीआर स्टैटिक मेटाडेटा को पार्स और मैनेज करने की सुविधा होनी चाहिए.

• अगर कोई मीडिया कोडेक, इंटरा रीफ़्रेश की सुविधा का विज्ञापन करता है, तो उसे 10 से 60 फ़्रेम की रेंज में रीफ़्रेश पीरियड के साथ काम करना चाहिए. साथ ही, कॉन्फ़िगर किए गए रीफ़्रेश पीरियड के 20% के अंदर सटीक तरीके से काम करना चाहिए.

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

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

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

1 यह उन डिवाइसों के लिए ज़रूरी है जिनमें कैमरा हार्डवेयर शामिल है और जिन्होंने android.hardware.camera या android.hardware.camera.front को तय किया है.

2 Android Watch डिवाइसों को छोड़कर, डिवाइस पर लागू करने के लिए ज़रूरी है.

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

4 डिवाइस पर लागू होने वाले वर्शन में, Matroska WebM फ़ाइलें लिखने की सुविधा होनी चाहिए.

5 Android Automotive के लिए इसका सुझाव ज़रूर दिया जाता है. हालांकि, Android Watch के लिए यह ज़रूरी नहीं है. साथ ही, अन्य सभी तरह के डिवाइसों के लिए यह ज़रूरी है.

6 यह सिर्फ़ Android Television डिवाइसों पर लागू होता है.

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

H.264, VP8, VP9, और HEVC वीडियो एन्कोडर—

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

H.263 और MPEG-4 वीडियो एन्कोडर, डाइनैमिक तौर पर कॉन्फ़िगर की जा सकने वाली बिटरेट के साथ काम करना चाहिए.

सभी वीडियो एन्कोडर को दो स्लाइडिंग विंडो में, नीचे दी गई बिटरेट के टारगेट को पूरा करना चाहिए:

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

5.2.1. H.263

H.263 एन्कोडर वाले Android डिवाइसों में, बेसलाइन प्रोफ़ाइल लेवल 45 की सुविधा काम करनी चाहिए.

5.2.2. H-264

H.264 कोडेक के साथ काम करने वाले Android डिवाइस:

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

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

1 जब हार्डवेयर काम करता हो, लेकिन Android Television डिवाइसों के लिए इसका सुझाव ज़रूर दिया जाता है.

5.2.3. VP8

VP8 कोडेक के साथ काम करने वाले Android डिवाइसों पर, एसडी वीडियो एन्कोडिंग प्रोफ़ाइलों के साथ-साथ, इन एचडी (हाई डेफ़िनिशन) वीडियो एन्कोडिंग प्रोफ़ाइलों के साथ भी काम करना चाहिए.

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

1 जब हार्डवेयर के साथ काम करता हो.

5.3. वीडियो डिकोड करना

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

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

• Dolby Vision डिकोडर के साथ काम करने वाले तरीके—

• Dolby Vision की सुविधा वाला एक्सट्रैक्टर देना ज़रूरी है.

• डिवाइस की स्क्रीन या स्टैंडर्ड वीडियो आउटपुट पोर्ट (उदाहरण के लिए, एचडीएमआई).

• Dolby Vision की सुविधा देने वाले एक्सट्रैक्टर को, पुराने वर्शन के साथ काम करने वाली बेस लेयर (अगर मौजूद हो) के ट्रैक इंडेक्स को, Dolby Vision लेयर के ट्रैक इंडेक्स के तौर पर सेट करना होगा.

5.3.1. MPEG-2

MPEG-2 डिकोडर वाले Android डिवाइसों में, मुख्य प्रोफ़ाइल के हाई लेवल का इस्तेमाल किया जाना चाहिए.

5.3.2. H.263

H.263 डिकोडर वाले Android डिवाइसों को, बेसलाइन प्रोफ़ाइल लेवल 30 और लेवल 45 के साथ काम करना चाहिए.

5.3.3. MPEG-4

MPEG-4 डिकोडर वाले Android डिवाइसों में, सिंपल प्रोफ़ाइल लेवल 3 की सुविधा काम करनी चाहिए.

5.3.4. H.264

H.264 डीकोडर के साथ Android डिवाइस पर लागू होने वाले वर्शन:

• यह मुख्य प्रोफ़ाइल के लेवल 3.1 और बेसलाइन प्रोफ़ाइल के साथ काम करना चाहिए.
  ASO (स्लाइस का मनमुताबिक क्रम), FMO (फ़्लेक्सिबल मैक्रोब्लॉक ऑर्डरिंग), और RS (रिडंडेंट स्लाइस) की सुविधा का इस्तेमाल करना ज़रूरी नहीं है.
• यह ज़रूरी है कि डिवाइस, नीचे दी गई टेबल में दी गई एसडी (स्टैंडर्ड डेफ़िनिशन) प्रोफ़ाइलों वाले वीडियो को डिकोड कर सके. साथ ही, यह भी ज़रूरी है कि डिवाइस, बेसलाइन प्रोफ़ाइल और मुख्य प्रोफ़ाइल लेवल 3.1 (इसमें 720p30 भी शामिल है) के साथ एन्कोड किए गए वीडियो को डिकोड कर सके.
• यह एचडी (हाई डेफ़िनिशन) प्रोफ़ाइल वाले वीडियो को डिकोड कर सके, जैसा कि इस टेबल में बताया गया है.
• इसके अलावा, Android Television डिवाइसों पर—
  • यह हाई प्रोफ़ाइल लेवल 4.2 और एचडी 1080p60 डिकोडिंग प्रोफ़ाइल के साथ काम करना चाहिए.
  • यह ज़रूरी है कि डिवाइस, नीचे दी गई टेबल में बताई गई दोनों एचडी प्रोफ़ाइलों वाले वीडियो को डिकोड कर सके. साथ ही, यह भी ज़रूरी है कि वीडियो को बेसलाइन प्रोफ़ाइल, मुख्य प्रोफ़ाइल या हाई प्रोफ़ाइल लेवल 4.2 में एन्कोड किया गया हो

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

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

2 Android Television डिवाइस पर लागू करने के लिए ज़रूरी है.

5.3.5. H.265 (HEVC)

सेक्शन 5.1.3 में बताए गए तरीके से H.265 कोडेक का इस्तेमाल करने वाले Android डिवाइसों पर:

• यह मेन प्रोफ़ाइल लेवल 3 के मुख्य टीयर और एसडी वीडियो डिकोडिंग प्रोफ़ाइल के साथ काम करना चाहिए, जैसा कि नीचे दी गई टेबल में बताया गया है.
• इस टेबल में बताई गई एचडी डिकोडिंग प्रोफ़ाइलों के साथ काम करना चाहिए.
• अगर हार्डवेयर डिकोडर मौजूद है, तो एचडी डिकोडिंग प्रोफ़ाइलों के साथ काम करना चाहिए. इन प्रोफ़ाइलों के बारे में नीचे दी गई टेबल में बताया गया है.
• इसके अलावा, Android Television डिवाइसों पर:
• यह एचडी 720p डिकोडिंग प्रोफ़ाइल के साथ काम करना चाहिए.
• हमारा सुझाव है कि आप एचडी 1080 पिक्सल डिकोडिंग प्रोफ़ाइल का इस्तेमाल करें. अगर एचडी 1080 पिक्सल डिकोडिंग प्रोफ़ाइल काम करती है, तो यह मेन प्रोफ़ाइल लेवल 4.1 के मुख्य टीयर के साथ काम करनी चाहिए.
• यह यूएचडी डिकोडिंग प्रोफ़ाइल के साथ काम करना चाहिए. अगर यूएचडी डिकोडिंग प्रोफ़ाइल काम करती है, तो कोडेक में Main10 लेवल 5 के मुख्य टीयर की प्रोफ़ाइल काम करनी चाहिए.

	एसडी (कम क्वालिटी)	एसडी (अच्छी क्वालिटी)	एचडी 720 पिक्सल	एचडी 1080 पिक्सल	यूएचडी
वीडियो रिज़ॉल्यूशन	352 x 288 पिक्सल	720 x 480 पिक्सल	1280 x 720 पिक्सल	1920 x 1080 पिक्सल	3840 x 2160 पिक्सल
वीडियो फ़्रेम रेट	30 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड	30 fps (60 fps 1 )	60 एफ़पीएस (फ़्रेम प्रति सेकंड)
वीडियो बिटरेट	600 केबीपीएस	1.6 एमबीपीएस	4 एमबीपीएस	5 एमबीपीएस	20 एमबीपीएस

1 H.265 हार्डवेयर डिकोडिंग के साथ Android Television डिवाइस को लागू करने के लिए ज़रूरी है.

5.3.6. VP8

सेक्शन 5.1.3 में बताए गए VP8 कोडेक के साथ काम करने वाले Android डिवाइसों के लिए:

• यह ज़रूरी है कि यह नीचे दी गई टेबल में मौजूद एसडी डिकोडिंग प्रोफ़ाइलों के साथ काम करे.
• यह टेबल में दी गई एचडी डिकोडिंग प्रोफ़ाइलों के साथ काम करनी चाहिए.
• Android TV डिवाइसों पर, एचडी 1080p60 डिकोडिंग प्रोफ़ाइल काम करनी चाहिए.

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

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

2 Android Television डिवाइस पर लागू करने के लिए ज़रूरी है.

5.3.7. VP9

सेक्शन 5.1.3 में बताए गए VP9 कोडेक के साथ काम करने वाले Android डिवाइसों के लिए:

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

• इसके अलावा, Android Television डिवाइसों पर:

  • यह एचडी 720p डिकोडिंग प्रोफ़ाइल के साथ काम करना चाहिए.
  • हमारा सुझाव है कि आप एचडी 1080 पिक्सल डिकोडिंग प्रोफ़ाइल का इस्तेमाल करें.
  • यह यूएचडी डिकोडिंग प्रोफ़ाइल के साथ काम करना चाहिए. अगर यूएचडी वीडियो डिकोडिंग प्रोफ़ाइल काम करती है, तो यह 8-बिट कलर डेप्थ के साथ काम करनी चाहिए. साथ ही, यह VP9 प्रोफ़ाइल 2 (10-बिट) के साथ भी काम करनी चाहिए.

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

1 VP9 हार्डवेयर डिकोडिंग के साथ Android Television डिवाइस को लागू करने के लिए ज़रूरी है.

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

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

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

जिन डिवाइसों में android.hardware.microphone एट्रिब्यूट का इस्तेमाल किया गया है उन्हें रॉ ऑडियो कॉन्टेंट को कैप्चर करने की अनुमति देनी होगी. यह कॉन्टेंट इन विशेषताओं के साथ कैप्चर किया जाना चाहिए:

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

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

जिन डिवाइसों में android.hardware.microphone एट्रिब्यूट का इस्तेमाल किया गया है उन्हें इन विशेषताओं के साथ रॉ ऑडियो कॉन्टेंट कैप्चर करने की अनुमति देनी चाहिए:

• फ़ॉर्मैट : लीनियर पीसीएम, 16-बिट
• सैंपलिंग रेट : 22050, 48000
• चैनल : स्टीरियो

अगर ऊपर दी गई सैंपल रेट के लिए कैप्चर करने की सुविधा काम करती है, तो कैप्चर को 16,000:22,050 या 44,100:48,000 से ज़्यादा के रेशियो में अप-सैंपलिंग किए बिना कैप्चर करना ज़रूरी है. किसी भी अप-सैंपलिंग या डाउन-सैंपलिंग में, ऐंटी-ऐलिऐसिंग फ़िल्टर ज़रूर शामिल होना चाहिए.

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

android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION ऑडियो सोर्स, 44100 और 48000 में से किसी एक सैंपलिंग रेट पर ऑडियो रिकॉर्ड कर सकता है.

रिकॉर्डिंग से जुड़ी ऊपर दी गई खास बातों के अलावा, जब कोई ऐप्लिकेशन android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION ऑडियो सोर्स का इस्तेमाल करके ऑडियो स्ट्रीम रिकॉर्ड करना शुरू करता है, तो:

• डिवाइस में, फ़्रीक्वेंसी के हिसाब से ऐम्प्ल्यट्यूड में ज़्यादा उतार-चढ़ाव नहीं होना चाहिए. खास तौर पर, 100 हर्ट्ज़ से 4,000 हर्ट्ज़ तक, ±3 डीबी.
• ऑडियो इनपुट की संवेदनशीलता को इस तरह से सेट किया जाना चाहिए कि 1000 हर्ट्ज़ पर 90 डीबी साउंड पावर लेवल (एसपीएल) वाले सोर्स से, 16-बिट सैंपल के लिए आरएमएस 2500 मिल सके.
• माइक्रोफ़ोन पर 90 डीबी एसपीएल के हिसाब से, पीसीएम ऐम्प्ल्यट्यूड लेवल को इनपुट एसपीएल में होने वाले बदलावों को कम से कम 30 डीबी की रेंज में, -18 डीबी से +12 डीबी तक लीनियर तरीके से ट्रैक करना चाहिए.
• माइक्रोफ़ोन पर 90 dB SPL इनपुट लेवल पर, 1 kHz के लिए कुल हार्मोनिक डिस्टॉर्शन 1% से कम होना चाहिए.
• अगर शोर कम करने की सुविधा मौजूद है, तो उसे बंद करना ज़रूरी है.
• अगर ऑटोमैटिक गेन कंट्रोल की सुविधा मौजूद है, तो उसे बंद करना ज़रूरी है.

अगर प्लैटफ़ॉर्म पर, बोली पहचानने के लिए शोर कम करने वाली टेक्नोलॉजी काम करती हैं, तो इस इफ़ेक्ट को android.media.audiofx.NoiseSuppressor API से कंट्रोल किया जा सकता है. इसके अलावा, शोर कम करने की सुविधा के असर के ब्यौरे के लिए यूयूआईडी फ़ील्ड में, शोर कम करने की टेक्नोलॉजी के हर लागू होने की खास तौर पर पहचान होनी चाहिए.

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

android.media.MediaRecorder.AudioSource क्लास में REMOTE_SUBMIX ऑडियो सोर्स शामिल होता है. जिन डिवाइसों में android.hardware.audio.output एट्रिब्यूट की वैल्यू दी गई है उन्हें REMOTE_SUBMIX ऑडियो सोर्स को सही तरीके से लागू करना होगा. इससे, जब कोई ऐप्लिकेशन इस ऑडियो सोर्स से रिकॉर्ड करने के लिए android.media.AudioRecord API का इस्तेमाल करता है, तो वह इनके अलावा सभी ऑडियो स्ट्रीम का मिक्स कैप्चर कर सकता है:

• STREAM_RING
• STREAM_ALARM
• STREAM_NOTIFICATION

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

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

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

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

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

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

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

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

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

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

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

Android Television डिवाइस के लागू होने के लिए, सिस्टम के मुख्य वॉल्यूम और काम करने वाले आउटपुट पर डिजिटल ऑडियो आउटपुट वॉल्यूम कम करने की सुविधा का होना ज़रूरी है. हालांकि, यह सुविधा कंप्रेस किए गए ऑडियो पासथ्रू आउटपुट के लिए नहीं होनी चाहिए. कंप्रेस किए गए ऑडियो पासथ्रू आउटपुट में, डिवाइस पर ऑडियो को डिकोड नहीं किया जाता.

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

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

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

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

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

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

• कोल्ड आउटपुट में लगने वाला समय 100 मिलीसेकंड या उससे कम हो
• आउटपुट में लगातार 45 मिलीसेकंड या उससे कम की देरी
• कोल्ड आउटपुट में होने वाली गड़बड़ी को कम करना

अगर किसी डिवाइस में OpenSL ES PCM बफ़र क्यू एपीआई का इस्तेमाल करते समय, शुरुआती कैलिब्रेशन के बाद भी यह सेक्शन लागू होता है, तो हमारा सुझाव है कि कम इंतज़ार वाले ऑडियो के लिए, android.content.pm.PackageManager क्लास की मदद से, android.hardware.audio.low_latency सुविधा की रिपोर्ट करें. ऐसा करने से, कम इंतज़ार वाले ऑडियो की सुविधा के साथ काम करने वाले कम से कम एक ऑडियो आउटपुट डिवाइस के लिए, आउटपुट में लगने वाले समय की जानकारी मिलती है. इसके उलट, अगर डिवाइस में लागू की गई सुविधा इन ज़रूरी शर्तों को पूरा नहीं करती है, तो उसे कम इंतज़ार वाले ऑडियो के लिए काम करने की जानकारी नहीं देनी चाहिए.

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

• कोल्ड इनपुट इंतज़ार का समय 100 मिलीसेकंड या उससे कम
• इनपुट में लगातार 30 मिलीसेकंड या उससे कम की देरी
• लगातार 50 मिलीसेकंड या उससे कम का राउंड-ट्रिप लेटेंसी
• कोल्ड इनपुट जटर को कम करना

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

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

• एचटीटीपी(एस) प्रोग्रेसिव स्ट्रीमिंग
  सेक्शन 5.1 में बताए गए सभी ज़रूरी कोडेक और कंटेनर फ़ॉर्मैट, एचटीटीपी(एस) पर काम करने चाहिए

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

सेगमेंट फ़ॉर्मैट	रेफ़रंस	ज़रूरी कोडेक के साथ काम करना
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

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

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

प्रोफ़ाइल का नाम	रेफ़रंस	ज़रूरी कोडेक के साथ काम करना
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

डिवाइस में सुरक्षित वीडियो आउटपुट की सुविधा लागू करने के साथ-साथ, सुरक्षित प्लैटफ़ॉर्म पर वीडियो दिखाने की सुविधा देने वाले डिवाइसों को Display.FLAG_SECURE के साथ काम करने की जानकारी देनी होगी. जिन डिवाइसों में Display.FLAG_SECURE का इस्तेमाल किया गया है और जो वायरलेस डिसप्ले प्रोटोकॉल के साथ काम करते हैं उन्हें Miracast वायरलेस डिसप्ले के लिए, एन्क्रिप्शन के बेहतर तरीके से लिंक को सुरक्षित करना होगा. जैसे, HDCP 2.x या उसके बाद के वर्शन. इसी तरह, अगर वे वायर वाले बाहरी डिसप्ले के साथ काम करते हैं, तो डिवाइस में HDCP 1.2 या इसके बाद के वर्शन का इस्तेमाल किया जाना चाहिए. Android TV डिवाइसों पर, 4K रिज़ॉल्यूशन के लिए HDCP 2.2 और कम रिज़ॉल्यूशन के लिए HDCP 1.4 या उसके बाद के वर्शन का इस्तेमाल किया जाना चाहिए. Android के ओपन सोर्स वर्शन में, वायरलेस (Miracast) और वायर्ड (एचडीएमआई) डिसप्ले के लिए, इस ज़रूरी शर्त को पूरा करने वाली सुविधाएं शामिल हैं.

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

अगर किसी डिवाइस में इंटर-ऐप्लिकेशन एमआईडीआई सॉफ़्टवेयर ट्रांसपोर्ट (वर्चुअल एमआईडीआई डिवाइस) काम करता है और यह एमआईडीआई की सुविधा वाले सभी हार्डवेयर ट्रांसपोर्ट पर एमआईडीआई की सुविधा देता है, तो हमारा सुझाव है कि आप android.content.pm.PackageManager क्लास की मदद से, android.software.midi सुविधा के काम करने की जानकारी दें.

एमआईडीआई के साथ काम करने वाले हार्डवेयर ट्रांसपोर्ट ये हैं:

• यूएसबी होस्ट मोड (सेक्शन 7.7 यूएसबी)
• यूएसबी पेरिफ़रल मोड (सेक्शन 7.7 यूएसबी)
• ब्लूटूथ LE पर MIDI, मुख्य भूमिका में काम कर रहा है (सेक्शन 7.4.3 ब्लूटूथ)

इसके उलट, अगर डिवाइस में ऊपर बताए गए किसी MIDI-सक्षम हार्डवेयर ट्रांसपोर्ट के ज़रिए, सामान्य तौर पर MIDI के बिना कनेक्टिविटी मिलती है, लेकिन उस हार्डवेयर ट्रांसपोर्ट पर MIDI काम नहीं करता, तो उसे android.software.midi सुविधा के साथ काम करने की जानकारी नहीं देनी चाहिए.

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

अगर किसी डिवाइस में, नीचे दी गई सभी ज़रूरी शर्तें पूरी की गई हैं, तो हमारा सुझाव है कि आप android.content.pm.PackageManager क्लास की मदद से, android.hardware.audio.pro सुविधा के साथ काम करने की जानकारी दें.

• डिवाइस में इस सुविधा को लागू करने के लिए, यह ज़रूरी है कि डिवाइस में android.hardware.audio.low_latency की सुविधा काम करती हो.
• ऑडियो के लिए, लगातार राउंड-ट्रिप लेटेंसी 20 मिलीसेकंड या उससे कम होनी चाहिए. साथ ही, कम से कम एक काम करने वाले पाथ पर 10 मिलीसेकंड या उससे कम होनी चाहिए. इस बारे में ज़्यादा जानकारी, सेक्शन 5.6 ऑडियो लेटेंसी में दी गई है.
• अगर डिवाइस में चार कंडक्टर वाला 3.5 मि॰मी॰ ऑडियो जैक है, तो ऑडियो जैक पाथ पर ऑडियो का लगातार राउंड-ट्रिप लेटेंसी 20 मिलीसेकंड या उससे कम होना चाहिए. साथ ही, ऑडियो जैक पाथ पर ऑडियो का लेटेंसी 10 मिलीसेकंड या उससे कम होना चाहिए.
• डिवाइस में यूएसबी होस्ट मोड और यूएसबी पेरिफ़रल मोड के साथ काम करने वाला यूएसबी पोर्ट होना चाहिए.
• यूएसबी होस्ट मोड में, यूएसबी ऑडियो क्लास को लागू करना ज़रूरी है.
• अगर डिवाइस में एचडीएमआई पोर्ट है, तो डिवाइस में 20-बिट या 24-बिट डेप्थ और 192 केएचज़ पर स्टीरियो और आठ चैनलों में आउटपुट की सुविधा होनी चाहिए. साथ ही, इसमें बिट-डेप्थ लॉस या फिर से सैंपलिंग की सुविधा नहीं होनी चाहिए.
• डिवाइस में लागू करने के लिए, android.software.midi सुविधा के साथ काम करने की जानकारी देना ज़रूरी है.
• अगर डिवाइस में चार कंडक्टर वाला 3.5 मि॰मी॰ का ऑडियो जैक शामिल है, तो डिवाइस को लागू करने के लिए वायर्ड ऑडियो हेडसेट स्पेसिफ़िकेशन (v1.1) के सेक्शन मोबाइल डिवाइस (जैक) की खास बातें का पालन करने का सुझाव दिया जाता है.

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

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

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

5.11. प्रोसेस नहीं हुए डेटा के लिए कैप्चर

Android 7.0 से, रिकॉर्डिंग का एक नया सोर्स जोड़ा गया है. इसे android.media.MediaRecorder.AudioSource.UNPROCESSED ऑडियो सोर्स का इस्तेमाल करके ऐक्सेस किया जा सकता है. OpenSL ES में, इसे रिकॉर्ड प्रीसेट SL_ANDROID_RECORDING_PRESET_UNPROCESSED की मदद से ऐक्सेस किया जा सकता है .

android.media.AudioManager प्रॉपर्टी PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED की मदद से, बिना प्रोसेस किए गए ऑडियो सोर्स के काम करने की जानकारी देने के लिए, किसी डिवाइस को इन सभी ज़रूरी शर्तों को पूरा करना होगा:

• डिवाइस को मध्य फ़्रीक्वेंसी रेंज में, ऐम्प्ल्यट्यूड-बनाम-फ़्रीक्वेंसी की सुविधाएं दिखानी चाहिए. खास तौर पर, 100 हर्ट्ज़ से 7,000 हर्ट्ज़ तक ±10dB.

• डिवाइस में, कम फ़्रीक्वेंसी रेंज में ऐम्प्ल्यट्यूड लेवल दिखने चाहिए. खास तौर पर, मीडियम फ़्रीक्वेंसी रेंज की तुलना में, 5 हर्ट्ज़ से 100 हर्ट्ज़ तक ±20 डीबी.

• डिवाइस में हाई फ़्रीक्वेंसी रेंज में ऐम्प्ल्यट्यूड लेवल होना चाहिए: खास तौर पर, मिड-फ़्रीक्वेंसी रेंज की तुलना में 7,000 हर्ट्ज़ से 22 किलोहर्ट्ज़ तक ±30 डीबी.

• ऑडियो इनपुट की संवेदनशीलता को इस तरह से सेट करना ज़रूरी है कि 94 डीबी साउंड प्रेशर लेवल (एसपीएल) पर चलाया गया 1,000 हर्ट्ज़ का साइनसोइडल टोन सोर्स, 16 बिट-सैंपल के लिए 520 आरएमएस (या फ़्लोटिंग पॉइंट/डबल प्रिसीज़न सैंपल के लिए -36 डीबी फ़ुल स्केल) का रिस्पॉन्स दे.

• एसएनआर > 60 dB (94 dB SPL और सेल्फ़ नॉइज़ के बराबर SPL के बीच का अंतर, A-वज़न).

• माइक्रोफ़ोन पर 90 dB SPL इनपुट लेवल पर, 1 केएचज़ के लिए कुल हार्मोनिक डिस्टॉर्शन 1% से कम होना चाहिए.

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

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

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

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

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

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

6.1. डेवलपर टूल

डिवाइस के लागू होने के लिए, यह ज़रूरी है कि वे Android SDK में दिए गए Android डेवलपर टूल के साथ काम करते हों. Android के साथ काम करने वाले डिवाइसों में ये सुविधाएं होनी चाहिए:

• Android डीबग ब्रिज (adb)
  • डिवाइस पर, Android SDK टूल में दिए गए सभी adb फ़ंक्शन काम करने चाहिए. इनमें dumpsys भी शामिल है.
  • डिवाइस-साइड adb डेमन, डिफ़ॉल्ट रूप से बंद होना चाहिए. साथ ही, Android Debug Bridge को चालू करने के लिए, उपयोगकर्ता के पास कोई ऐसा तरीका होना चाहिए जिसका इस्तेमाल किया जा सके. अगर किसी डिवाइस में यूएसबी पेरिफ़रल मोड लागू नहीं किया गया है, तो उसे लोकल-एरिया नेटवर्क (जैसे, ईथरनेट या 802.11) के ज़रिए Android Debug Bridge लागू करना होगा.
  • Android में सुरक्षित adb के लिए सहायता शामिल है. Secure adb, पुष्टि किए गए होस्ट पर adb को चालू करता है. डिवाइस पर, सुरक्षित adb की सुविधा काम करनी चाहिए.
• Dalvik Debug Monitor Service (ddms)
  • डिवाइस पर लागू किए गए वर्शन में, Android SDK टूल में बताई गई सभी ddms सुविधाएं काम करनी चाहिए.
  • ddms, adb का इस्तेमाल करता है. इसलिए, ddms के लिए सहायता डिफ़ॉल्ट रूप से बंद होनी चाहिए. हालांकि, जब भी उपयोगकर्ता ऊपर बताए गए तरीके से Android Debug Bridge को चालू करता है, तब ddms के लिए सहायता चालू होनी चाहिए.
• Monkey डिवाइस में Monkey फ़्रेमवर्क को शामिल करना ज़रूरी है. साथ ही, इसे ऐप्लिकेशन के इस्तेमाल के लिए उपलब्ध कराना होगा.
• SysTrace
  • डिवाइस पर लागू किए गए टूल, Android SDK में बताए गए systrace टूल के साथ काम करने चाहिए. Systrace की सुविधा डिफ़ॉल्ट रूप से बंद होनी चाहिए. साथ ही, Systrace को चालू करने के लिए, उपयोगकर्ता के पास कोई ऐसा तरीका होना चाहिए जिसका इस्तेमाल किया जा सके.
  • ज़्यादातर Linux-आधारित सिस्टम और Apple Macintosh सिस्टम, Android SDK टूल का इस्तेमाल करके Android डिवाइसों को पहचानते हैं. इसके लिए, उन्हें किसी और सहायता की ज़रूरत नहीं होती. हालांकि, आम तौर पर Microsoft Windows सिस्टम को नए Android डिवाइसों के लिए ड्राइवर की ज़रूरत होती है. उदाहरण के लिए, नए वेंडर आईडी और कभी-कभी नए डिवाइस आईडी के लिए, Windows सिस्टम के कस्टम यूएसबी ड्राइवर की ज़रूरत होती है.
  • अगर स्टैंडर्ड Android SDK में दिए गए adb टूल से, डिवाइस को लागू करने की सुविधा को पहचाना नहीं जाता है, तो डिवाइस को लागू करने वाले लोगों को Windows ड्राइवर उपलब्ध कराने होंगे. इससे डेवलपर, adb प्रोटोकॉल का इस्तेमाल करके डिवाइस से कनेक्ट कर पाएंगे. ये ड्राइवर, Windows XP, Windows Vista, Windows 7, Windows 8, और Windows 10 के लिए 32-बिट और 64-बिट, दोनों वर्शन में उपलब्ध होने चाहिए.

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

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

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

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

• कॉम्पोनेंट एपीआई के लिए, क्लास की पूरी परिभाषाएं (एसडीके के दस्तावेज़ के मुताबिक) अब भी ज़रूर दी जानी चाहिए.
• एपीआई के व्यवहार को किसी सही तरीके से, नो-ऑप के तौर पर लागू किया जाना चाहिए.
• SDK दस्तावेज़ में अनुमति होने पर, एपीआई के तरीके शून्य वैल्यू दिखाने चाहिए.
• एपीआई के तरीकों को उन क्लास के लिए कोई कार्रवाई नहीं करनी चाहिए जहां SDK दस्तावेज़ में शून्य वैल्यू की अनुमति नहीं है.
• एपीआई के तरीके, ऐसे अपवाद नहीं दिखा सकते जिनके बारे में एसडीके के दस्तावेज़ में नहीं बताया गया है.

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

डिवाइस के लागू होने पर, एक ही बिल्ड फ़िंगरप्रिंट के लिए, 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 के साथ android.content.res.Configuration.screenLayout की मदद से, डिवाइस की स्क्रीन साइज़ (जिसे “स्क्रीन लेआउट” भी कहा जाता है) के बारे में क्वेरी करने की अनुमति देता है. डिवाइस पर लागू किए गए SDK टूल को, Android SDK टूल के दस्तावेज़ में बताए गए सही स्क्रीन साइज़ की जानकारी देनी होगी. यह जानकारी, Android के अपस्ट्रीम प्लैटफ़ॉर्म से तय होती है. खास तौर पर, डिवाइस लागू करने के लिए, स्क्रीन के सही साइज़ की जानकारी देना ज़रूरी है. यह जानकारी, डेंसिटी-इंडिपेंडेंट पिक्सल (डीपी) के हिसाब से तय किए गए स्क्रीन डाइमेंशन के आधार पर दी जानी चाहिए.

• डिवाइसों की स्क्रीन का साइज़ कम से कम 426 डीपी x 320 डीपी (‘छोटा’) होना चाहिए. हालांकि, Android Watch डिवाइसों के लिए ऐसा ज़रूरी नहीं है.
• जिन डिवाइसों की स्क्रीन का साइज़ 'सामान्य' के तौर पर रिपोर्ट किया जाता है उनकी स्क्रीन का साइज़ कम से कम 480 डीपी x 320 डीपी होना चाहिए.
• जिन डिवाइसों की स्क्रीन का साइज़ 'बड़ा' है उनकी स्क्रीन का साइज़ कम से कम 640 डीपी x 480 डीपी होना चाहिए.
• जिन डिवाइसों की स्क्रीन का साइज़ 'बहुत बड़ी' है उनकी स्क्रीन का साइज़ कम से कम 960 डीपी x 720 डीपी होना चाहिए.

साथ ही:

• Android Watch डिवाइसों की स्क्रीन का डायगनल साइज़, 1.1 से 2.5 इंच के बीच होना चाहिए.
• Android Automotive डिवाइसों की स्क्रीन का डायगनल साइज़, 6 इंच या उससे ज़्यादा होना चाहिए.
• Android Automotive डिवाइसों की स्क्रीन का साइज़ कम से कम 750 डीपी x 480 डीपी होना चाहिए.
• फ़िज़िकल तौर पर इंटिग्रेट की गई स्क्रीन वाले अन्य तरह के Android डिवाइसों की स्क्रीन का डायगनल साइज़ कम से कम 2.5 इंच होना चाहिए.

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

ऐप्लिकेशन, AndroidManifest.xml फ़ाइल में <supports-screens> एट्रिब्यूट की मदद से यह बता सकते हैं कि वे किन स्क्रीन साइज़ के साथ काम करते हैं. हालांकि, ऐसा करना ज़रूरी नहीं है. डिवाइस के लागू होने पर, यह ज़रूरी है कि ऐप्लिकेशन में बताई गई छोटी, सामान्य, बड़ी, और बड़ी स्क्रीन के लिए, ऐप्लिकेशन सही तरीके से काम करे. इस बारे में Android SDK के दस्तावेज़ में बताया गया है.

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

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

• अगर uiMode को UI_MODE_TYPE_WATCH के तौर पर कॉन्फ़िगर किया गया है, तो आसपेक्ट रेशियो की वैल्यू 1.0 (1:1) पर सेट की जा सकती है.
• अगर तीसरे पक्ष का ऐप्लिकेशन, android:resizeableActivity एट्रिब्यूट की मदद से यह बताता है कि उसका साइज़ बदला जा सकता है, तो आसपेक्ट रेशियो की वैल्यू पर कोई पाबंदी नहीं होती.
• अन्य सभी मामलों में, आसपेक्ट रेशियो की वैल्यू 1.3333 (4:3) से 1.86 (लगभग 16:9) के बीच होनी चाहिए. ऐसा तब तक ज़रूरी है, जब तक ऐप्लिकेशन ने साफ़ तौर पर यह नहीं बताया है कि वह maxAspectRatio मेटाडेटा वैल्यू की मदद से, स्क्रीन के ज़्यादा आसपेक्ट रेशियो के साथ काम करता है.

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

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

• 120 डीपीआई (ldpi)
• 160 डीपीआई (एमडीपीआई)
• 213 डीपीआई (tvdpi)
• 240 डीपीआई (एचडीपीआई)
• 280 डीपीआई (280dpi)
• 320 डीपीआई (xhdpi)
• 360 डीपीआई (360dpi)
• 400 डीपीआई (400dpi)
• 420 डीपीआई (420dpi)
• 480 डीपीआई (xxhdpi)
• 560 डीपीआई (560dpi)
• 640 डीपीआई (xxxhdpi)

डिवाइस के लागू होने पर, Android फ़्रेमवर्क की स्टैंडर्ड डेंसिटी तय की जानी चाहिए, जो संख्या के हिसाब से स्क्रीन की फ़िज़िकल डेंसिटी के सबसे करीब हो. हालांकि, ऐसा तब तक नहीं किया जाना चाहिए, जब तक कि लॉजिकल डेंसिटी, रिपोर्ट की गई स्क्रीन के साइज़ को काम करने वाले सबसे छोटे साइज़ से कम न कर दे. अगर डिवाइस के फ़िज़िकल डेंसिटी के सबसे करीब के स्टैंडर्ड Android फ़्रेमवर्क डेंसिटी से, स्क्रीन का साइज़, काम करने वाले सबसे छोटे स्क्रीन साइज़ (320 dp चौड़ाई) से छोटा होता है, तो डिवाइस के लागू होने पर, अगले सबसे कम स्टैंडर्ड Android फ़्रेमवर्क डेंसिटी की जानकारी दी जानी चाहिए.

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

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

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

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

7.1.3. स्क्रीन अभिविन्यास

डिवाइसों को यह बताना ज़रूरी है कि वे किस तरह के स्क्रीन ओरिएंटेशन (android.hardware.screen.portrait और/या android.hardware.screen.landscape) के साथ काम करते हैं. साथ ही, यह भी ज़रूरी है कि वे कम से कम एक ओरिएंटेशन के साथ काम करने की जानकारी दें. उदाहरण के लिए, टेलिविज़न या लैपटॉप जैसे ऐसे डिवाइसों के लिए, सिर्फ़ android.hardware.screen.landscape की जानकारी दी जानी चाहिए जिनकी स्क्रीन का ओरिएंटेशन हमेशा लैंडस्केप मोड में रहता है.

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

जब भी android.content.res.Configuration.orientation, android.view.Display.getOrientation() या अन्य एपीआई के ज़रिए क्वेरी की जाती है, तो डिवाइसों को डिवाइस के मौजूदा ओरिएंटेशन की सही वैल्यू बतानी ज़रूरी है.

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

7.1.4. 2D और 3D ग्राफ़िक एक्सेलरेशन

डिवाइस में लागू किए गए वर्शन, OpenGL ES 1.0 और 2.0, दोनों के साथ काम करने चाहिए. इस बारे में Android SDK के दस्तावेज़ों में बताया गया है. डिवाइस पर लागू किए गए वर्शन, उन डिवाइसों पर OpenGL ES 3.0, 3.1 या 3.2 के साथ काम करने चाहिए जिन पर ये वर्शन काम करते हैं. डिवाइस पर लागू करने के लिए, यह ज़रूरी है कि Android RenderScript भी काम करे. इस बारे में Android SDK के दस्तावेज़ में बताया गया है.

डिवाइस के लागू होने के बाद, यह भी सही तरीके से पता चलना चाहिए कि वह OpenGL ES 1.0, OpenGL ES 2.0, OpenGL ES 3.0, OpenGL 3.1 या OpenGL 3.2 के साथ काम करता है. इसका मतलब है कि:

• मैनेज किए जा रहे एपीआई (जैसे, GLES10.getString() तरीके से) को OpenGL ES 1.0 और OpenGL ES 2.0 के साथ काम करने की जानकारी देनी होगी.
• नेटिव C/C++ OpenGL API (libGLES_v1CM.so, libGLES_v2.so या libEGL.so के ज़रिए ऐप्लिकेशन के लिए उपलब्ध एपीआई) को OpenGL ES 1.0 और OpenGL ES 2.0 के साथ काम करने की जानकारी देनी होगी.
• जिन डिवाइसों में OpenGL ES 3.0, 3.1 या 3.2 के साथ काम करने की सुविधा है उनमें मैनेज किए जा सकने वाले एपीआई के साथ-साथ, नेटिव C/C++ एपीआई के साथ काम करने की सुविधा भी होनी चाहिए. डिवाइस पर लागू किए गए ऐसे वर्शन जो OpenGL ES 3.0, 3.1 या 3.2 के साथ काम करने का दावा करते हैं, उनमें libGLESv2.so को OpenGL ES 2.0 फ़ंक्शन सिंबल के साथ-साथ, उससे जुड़े फ़ंक्शन सिंबल भी एक्सपोर्ट करने होंगे.

Android, Java इंटरफ़ेस के साथ OpenGL ES एक्सटेंशन पैक उपलब्ध कराता है. साथ ही, बेहतर ग्राफ़िक्स की सुविधाओं के लिए नेटिव सपोर्ट भी देता है. जैसे, टेसेलेशन और ASTC टेक्सचर कंप्रेस करने का फ़ॉर्मैट. अगर Android डिवाइस पर OpenGL ES 3.2 वर्शन काम करता है, तो उस पर एक्सटेंशन पैक काम करना चाहिए. अगर ऐसा नहीं है, तो हो सकता है कि वह काम करे. अगर एक्सटेंशन पैक पूरी तरह से काम करता है, तो डिवाइस को android.hardware.opengles.aep सुविधा फ़्लैग की मदद से, इसकी पहचान करनी होगी.

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

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

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

डिवाइस पर लागू होने वाले ऐप्लिकेशन में, हार्डवेयर से तेज़ी लाने की सुविधा डिफ़ॉल्ट रूप से चालू होनी चाहिए. अगर डेवलपर ने android:hardwareAccelerated="false” को सेट करके या सीधे Android View API की मदद से हार्डवेयर से तेज़ी लाने की सुविधा बंद करने का अनुरोध किया है, तो डिवाइस पर लागू होने वाले ऐप्लिकेशन में, हार्डवेयर से तेज़ी लाने की सुविधा बंद होनी चाहिए.

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

Android में TextureView ऑब्जेक्ट शामिल होता है. इसकी मदद से, डेवलपर सीधे तौर पर हार्डवेयर से तेज़ किए गए OpenGL ES टेक्स्चर को यूज़र इंटरफ़ेस (यूआई) के लेआउट में रेंडरिंग टारगेट के तौर पर इंटिग्रेट कर सकते हैं. डिवाइस पर लागू किए गए वर्शन में, TextureView API का इस्तेमाल किया जाना चाहिए. साथ ही, यह भी ज़रूरी है कि यह वर्शन, Android के अपस्ट्रीम वर्शन के साथ एक जैसा काम करे.

Android में EGL_ANDROID_RECORDABLE के लिए सहायता शामिल है. यह EGLConfig एट्रिब्यूट है, जो बताता है कि EGLConfig, ANativeWindow में रेंडरिंग की सुविधा देता है या नहीं. ANativeWindow, इमेज को वीडियो में रिकॉर्ड करता है. डिवाइस पर EGL_ANDROID_RECORDABLE एक्सटेंशन काम करना चाहिए.

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

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

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

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

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

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

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

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

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

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

7.2.1. कीबोर्ड

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

• इसमें इनपुट मैनेजमेंट फ़्रेमवर्क के लिए सहायता शामिल होनी चाहिए.इससे तीसरे पक्ष के डेवलपर, इनपुट मेथड एडिटर (जैसे, सॉफ़्ट कीबोर्ड) बना सकते हैं. इस बारे में ज़्यादा जानकारी के लिए, http://developer.android.com पर जाएं.
• Android Watch डिवाइसों को छोड़कर, कम से कम एक सॉफ्ट कीबोर्ड उपलब्ध कराना ज़रूरी है. भले ही, डिवाइस में हार्ड कीबोर्ड मौजूद हो. ऐसा इसलिए, क्योंकि Android Watch डिवाइसों की स्क्रीन का साइज़, सॉफ्ट कीबोर्ड के इस्तेमाल के लिहाज़ से सही नहीं है.
• इसमें अन्य सॉफ़्ट कीबोर्ड लागू करने की सुविधा शामिल हो सकती है.
• इसमें हार्डवेयर कीबोर्ड शामिल हो सकता है.
• इसमें ऐसा हार्डवेयर कीबोर्ड शामिल नहीं होना चाहिए जो android.content.res.Configuration.keyboard (QWERTY या 12-key) में बताए गए फ़ॉर्मैट से मेल न खाता हो.

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

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

• अगर डिवाइस पर Android Television की सुविधा नहीं है, तो हो सकता है कि टच न करने वाले नेविगेशन के विकल्प (ट्रैकबॉल, डी-पैड या व्हील) को शामिल न किया जाए.
• android.content.res.Configuration.navigation के लिए सही वैल्यू रिपोर्ट करना ज़रूरी है.
• टेक्स्ट चुनने और उसमें बदलाव करने के लिए, यूज़र इंटरफ़ेस का ऐसा विकल्प देना चाहिए जो इनपुट मैनेजमेंट इंजन के साथ काम करता हो. Android के ओपन सोर्स को अपस्ट्रीम करने के तरीके में, डिवाइसों के लिए चुनने का एक तरीका शामिल है. यह तरीका उन डिवाइसों के साथ इस्तेमाल करने के लिए सही है जिनमें टच-पैनल के अलावा नेविगेशन इनपुट की सुविधा नहीं होती.

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

होम, हाल ही में इस्तेमाल किए गए ऐप्लिकेशन, और वापस जाने के फ़ंक्शन (क्रमशः KEYCODE_HOME, KEYCODE_APP_SWITCH, और KEYCODE_BACK इवेंट पर मैप किए गए), Android नेविगेशन पैराडाइम के लिए ज़रूरी हैं. इसलिए:

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

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

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

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

Android 4.0 के बाद से, मेन्यू फ़ंक्शन के बजाय ऐक्शन बार का इस्तेमाल किया जा रहा है. इसलिए, Android 7.0 और उसके बाद के वर्शन वाले नए डिवाइसों में, मेन्यू फ़ंक्शन के लिए कोई खास फ़िज़िकल बटन नहीं होना चाहिए. पुराने डिवाइसों में, मेन्यू फ़ंक्शन के लिए कोई खास फ़िज़िकल बटन लागू नहीं किया जाना चाहिए. हालांकि, अगर फ़िज़िकल मेन्यू बटन लागू किया गया है और डिवाइस पर targetSdkVersion > 10 वाले ऐप्लिकेशन चल रहे हैं, तो डिवाइस के लिए:

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

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

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

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

• डिवाइस पर नेविगेशन बटनों को स्क्रीन के किसी ऐसे हिस्से पर इस्तेमाल करना चाहिए जो ऐप्लिकेशन के लिए उपलब्ध न हो. साथ ही, यह ज़रूरी है कि वे ऐप्लिकेशन के लिए उपलब्ध स्क्रीन के हिस्से को छिपाएं या उसमें रुकावट न डालें.
• डिवाइस में लागू किए गए एपीआई, डिसप्ले का एक हिस्सा उन ऐप्लिकेशन के लिए उपलब्ध कराना चाहिए जो सेक्शन 7.1.1 में बताई गई ज़रूरी शर्तों को पूरा करते हैं.
• जब ऐप्लिकेशन में सिस्टम यूज़र इंटरफ़ेस (यूआई) मोड की जानकारी न दी गई हो या SYSTEM_UI_FLAG_VISIBLE की वैल्यू दी गई हो, तो डिवाइस पर नेविगेशन बटन दिखने चाहिए.
• जब ऐप्लिकेशन SYSTEM_UI_FLAG_LOW_PROFILE का इस्तेमाल करते हैं, तो डिवाइस पर नेविगेशन बटनों को “कम प्रोफ़ाइल” (जैसे, धुंधला) मोड में दिखाना ज़रूरी है.
• जब ऐप्लिकेशन SYSTEM_UI_FLAG_HIDE_NAVIGATION तय करते हैं, तो डिवाइस पर नेविगेशन बटन छिपाने होंगे.

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

डिवाइस में किसी तरह का पॉइंटर इनपुट सिस्टम (माउस जैसा या टच) होना चाहिए. हालांकि, अगर किसी डिवाइस पर पॉइंटर इनपुट सिस्टम काम नहीं करता है, तो उसे android.hardware.touchscreen या android.hardware.faketouch सुविधा के कॉन्स्टेंट की रिपोर्ट नहीं करनी चाहिए. ऐसे डिवाइसों पर लागू करने के लिए, जिनमें पॉइंटर इनपुट सिस्टम शामिल है:

• अगर डिवाइस के इनपुट सिस्टम में एक से ज़्यादा पॉइंटर काम करते हैं, तो पूरी तरह से अलग-अलग ट्रैक किए गए पॉइंटर के साथ काम करना चाहिए.
• डिवाइस पर मौजूद टचस्क्रीन के टाइप के हिसाब से, android.content.res.Configuration.touchscreen की वैल्यू रिपोर्ट करनी ज़रूरी है.

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

डिवाइस पर लागू किए गए टूल, इस्तेमाल किए गए इनपुट टाइप के हिसाब से सही सुविधा की जानकारी देने चाहिए. जिन डिवाइसों में टचस्क्रीन (सिंगल-टच या बेहतर) है उन्हें प्लैटफ़ॉर्म की सुविधा के लिए, android.hardware.touchscreen की वैल्यू देनी होगी. जिन डिवाइसों में प्लैटफ़ॉर्म की सुविधा के लिए android.hardware.touchscreen का इस्तेमाल किया गया है उन्हें प्लैटफ़ॉर्म की सुविधा के लिए android.hardware.faketouch का इस्तेमाल भी करना होगा. जिन डिवाइसों में टचस्क्रीन नहीं है और जो सिर्फ़ पॉइंटर डिवाइस पर काम करते हैं उन्हें किसी भी टचस्क्रीन सुविधा की जानकारी नहीं देनी चाहिए. साथ ही, अगर वे सेक्शन 7.2.5 में बताई गई फ़ेक टच की ज़रूरी शर्तों को पूरा करते हैं, तो उन्हें सिर्फ़ android.hardware.faketouch की जानकारी देनी चाहिए.

7.2.5. नकली टच इनपुट

डिवाइस में लागू किए गए ऐसे टूल जो android.hardware.faketouch के साथ काम करते हैं:

• यह पॉइंटर की जगह की स्क्रीन पर पूरी X और Y पोज़िशन की जानकारी देनी चाहिए. साथ ही, स्क्रीन पर विज़ुअल पॉइंटर दिखाना चाहिए.
• टच इवेंट को उस ऐक्शन कोड के साथ रिपोर्ट करना ज़रूरी है जो पॉइंटर के स्क्रीन पर नीचे या ऊपर जाने पर होने वाले स्टेटस में बदलाव की जानकारी देता है.
• यह ज़रूरी है कि स्क्रीन पर मौजूद किसी ऑब्जेक्ट पर कर्सर को नीचे और ऊपर ले जाने की सुविधा हो. इससे उपयोगकर्ता, स्क्रीन पर मौजूद किसी ऑब्जेक्ट पर टैप कर सकते हैं.
• यह ज़रूरी है कि स्क्रीन पर किसी ऑब्जेक्ट पर, एक तय समयसीमा के अंदर पॉइंटर को नीचे, ऊपर, फिर नीचे और फिर ऊपर ले जाया जा सके. इससे उपयोगकर्ता, स्क्रीन पर किसी ऑब्जेक्ट पर दो बार टैप करने की सुविधा का इस्तेमाल कर सकते हैं.
• यह ज़रूरी है कि स्क्रीन पर किसी भी बिंदु पर कर्सर को दबाकर रखें, कर्सर को स्क्रीन पर किसी भी बिंदु पर ले जाएं, और फिर कर्सर को ऊपर उठाएं. इससे उपयोगकर्ता, टच ड्रैग की सुविधा का इस्तेमाल कर सकते हैं.
• इसमें पॉइंटर डाउन की सुविधा होनी चाहिए. इसके बाद, उपयोगकर्ताओं को स्क्रीन पर किसी ऑब्जेक्ट को तुरंत किसी दूसरी जगह ले जाने की अनुमति मिलनी चाहिए. इसके बाद, स्क्रीन पर पॉइंटर अप की सुविधा होनी चाहिए, ताकि उपयोगकर्ता स्क्रीन पर किसी ऑब्जेक्ट को फ़्लिंग कर सकें.

जिन डिवाइसों पर android.hardware.faketouch.multitouch.distinct की सुविधा काम करती है उन्हें ऊपर बताई गई नकली टच की सुविधा की ज़रूरी शर्तें पूरी करनी होंगी. साथ ही, उन्हें दो या उससे ज़्यादा इंडिपेंडेंट पॉइंटर इनपुट की अलग-अलग ट्रैकिंग की सुविधा भी देनी होगी.

7.2.6. गेम कंट्रोलर के लिए सहायता

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

7.2.6.1. बटन मैपिंग

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

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

1 KeyEvent

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

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

4 MotionEvent

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

एक MotionEvent

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

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

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

7.3. सेंसर

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

• android.content.pm.PackageManager क्लास के मुताबिक, सेंसर की मौजूदगी या अनुपस्थिति की सटीक जानकारी देनी चाहिए.
• SensorManager.getSensorList() और मिलते-जुलते तरीकों की मदद से, काम करने वाले सेंसर की सटीक सूची दिखाना ज़रूरी है.
• यह सभी अन्य सेंसर एपीआई के लिए सही तरीके से काम करना चाहिए. उदाहरण के लिए, जब ऐप्लिकेशन, लिसनर रजिस्टर करने की कोशिश करते हैं, तो सही या गलत के तौर पर जवाब देना चाहिए. साथ ही, जब संबंधित सेंसर मौजूद न हों, तो सेंसर लिसनर को कॉल नहीं करना चाहिए.
• Android SDK के दस्तावेज़ में बताए गए हर सेंसर टाइप के लिए, सभी सेंसर मेज़रमेंट की रिपोर्ट करनी ज़रूरी है. इसके लिए, इंटरनैशनल सिस्टम ऑफ़ यूनिट (मेट्रिक) की सही वैल्यू का इस्तेमाल करना होगा.
• Android SDK के दस्तावेज़ में बताए गए तरीके के मुताबिक, इवेंट के समय की रिपोर्ट, नैनोसेकंड में होनी चाहिए. इससे, इवेंट के होने का समय पता चलता है. साथ ही, यह समय SystemClock.elapsedRealtimeNano() घड़ी के साथ सिंक होता है. मौजूदा और नए Android डिवाइसों के लिए, इन ज़रूरी शर्तों को पूरा करने का बहुत ज़्यादा सुझाव दिया जाता है. इससे, आने वाले समय में प्लैटफ़ॉर्म के रिलीज़ किए जाने वाले वर्शन में, डिवाइसों को अपग्रेड किया जा सकेगा. ऐसा तब होगा, जब यह शर्त ज़रूरी कॉम्पोनेंट बन जाए. सिंक करने में हुई गड़बड़ी 100 मिलीसेकंड से कम होनी चाहिए.
• सेंसर डेटा को 100 मिलीसेकंड + 2 * sample_time से ज़्यादा के इंतज़ार के साथ रिपोर्ट करना ज़रूरी है. ऐसा तब करना होगा, जब ऐप्लिकेशन प्रोसेसर चालू होने पर, सेंसर को 5 मिलीसेकंड + 2 * sample_time से ज़्यादा के इंतज़ार के साथ स्ट्रीम किया गया हो. इस समय में, फ़िल्टर करने में लगने वाला समय शामिल नहीं है.
• सेंसर चालू होने के 400 मिलीसेकंड + 2 * sample_time के अंदर, सेंसर के पहले सैंपल की रिपोर्ट देनी ज़रूरी है. इस सैंपल के लिए, सटीक होने की वैल्यू 0 हो सकती है.

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

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

कुछ Android सेंसर, “कंटिन्यूअस” ट्रिगर मोड के साथ काम करते हैं. इससे, लगातार डेटा मिलता रहता है. Android SDK दस्तावेज़ में, किसी भी ऐसे एपीआई के लिए जो लगातार सेंसर के तौर पर काम करता है, डिवाइस में लागू होने के बाद उसे समय-समय पर डेटा सैंपल उपलब्ध कराने होंगे. इन सैंपल में, जितटर 3% से कम होना चाहिए. जितटर को, लगातार होने वाले इवेंट के बीच रिपोर्ट किए गए टाइमस्टैंप की वैल्यू के अंतर के स्टैंडर्ड डेविएशन के तौर पर परिभाषित किया जाता है.

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

आखिर में, जब कई सेंसर चालू होते हैं, तो बिजली की खपत, अलग-अलग सेंसर की रिपोर्ट की गई बिजली की खपत के कुल योग से ज़्यादा नहीं होनी चाहिए.

7.3.1. एक्सलरोमीटर

डिवाइस में 3-ऐक्सिस एक्सलरोमीटर होना चाहिए. हमारा सुझाव है कि Android के हैंडहेल्ड डिवाइसों, Android Automotive के साथ काम करने वाले डिवाइसों, और Android Watch डिवाइसों में यह सेंसर शामिल किया जाए. अगर किसी डिवाइस में 3-ऐक्सिस एक्सलरोमीटर शामिल है, तो:

• TYPE_ACCELEROMETER सेंसर को लागू करना और उसकी रिपोर्ट देना ज़रूरी है.
• Android Watch डिवाइसों के लिए, कम से कम 50 हर्ट्ज़ की फ़्रीक्वेंसी तक इवेंट रिपोर्ट करने की ज़रूरत होती है. ऐसा इसलिए, क्योंकि इन डिवाइसों में बैटरी की कमी होती है. वहीं, अन्य सभी तरह के डिवाइसों के लिए, 100 हर्ट्ज़ की फ़्रीक्वेंसी तक इवेंट रिपोर्ट करने की ज़रूरत होती है.
• कम से कम 200 हर्ट्ज़ तक के इवेंट की रिपोर्ट करनी चाहिए.
• Android API में बताए गए तरीके के मुताबिक, Android सेंसर कोऑर्डिनेट सिस्टम का पालन करना ज़रूरी है. Android Automotive को लागू करने के लिए, Android के कार सेंसर कोऑर्डिनेट सिस्टम का पालन करना ज़रूरी है.
• यह किसी भी अक्ष पर, फ़्रीफ़ॉल से लेकर गुरुत्वाकर्षण के चार गुना (4g) या उससे ज़्यादा तक के एक्सेलेरेशन को मेज़र कर सकता हो.
• इसका रिज़ॉल्यूशन कम से कम 12-बिट होना चाहिए और कम से कम 16-बिट होना चाहिए.
• अगर लाइफ़साइकल के दौरान कैरेक्टरिस्टिक में बदलाव होता है और उन्हें बदला जाता है, तो इस्तेमाल के दौरान कैलिब्रेट किया जाना चाहिए. साथ ही, डिवाइस के रीबूट होने के बीच, बदलाव के पैरामीटर को बनाए रखना चाहिए.
• तापमान के हिसाब से अडजस्ट होना चाहिए.
• इसका स्टैंडर्ड डेविएशन 0.05 m/s^ से ज़्यादा नहीं होना चाहिए. स्टैंडर्ड डेविएशन का हिसाब, हर अक्ष के आधार पर लगाया जाना चाहिए. इसके लिए, सैंपलिंग रेट के सबसे तेज़ लेवल पर कम से कम तीन सेकंड के दौरान इकट्ठा किए गए सैंपल का इस्तेमाल किया जाना चाहिए.
• Android SDK दस्तावेज़ में बताए गए तरीके के मुताबिक, TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER कंपोजिट सेंसर लागू करने चाहिए. मौजूदा और नए Android डिवाइसों के लिए, TYPE_SIGNIFICANT_MOTION कंपोजिट सेंसर को लागू करने का बहुत सुझाव दिया जाता है. अगर इनमें से किसी भी सेंसर को लागू किया जाता है, तो उनकी बिजली की खपत का कुल योग हमेशा 4 एमडब्ल्यू से कम होना चाहिए. साथ ही, डिवाइस के डाइनैमिक या स्टैटिक होने पर, हर सेंसर की बिजली की खपत 2 एमडब्ल्यू और 0.5 एमडब्ल्यू से कम होनी चाहिए.
• अगर कोई गायरोस्कोप सेंसर शामिल है, तो TYPE_GRAVITY और TYPE_LINEAR_ACCELERATION कंपोजिट सेंसर लागू करना ज़रूरी है. साथ ही, TYPE_GAME_ROTATION_VECTOR कंपोजिट सेंसर लागू करना चाहिए. हमारा सुझाव है कि मौजूदा और नए Android डिवाइसों पर TYPE_GAME_ROTATION_VECTOR सेंसर लागू करें.
• अगर आपके डिवाइस में TYPE_ROTATION_VECTOR कंपोजिट सेंसर के साथ-साथ, जायरोस्कोप सेंसर और मैग्नेटोमीटर सेंसर भी शामिल है, तो TYPE_ROTATION_VECTOR कंपोजिट सेंसर को लागू करना ज़रूरी है.

7.3.2. मैग्नेटोमीटर

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

• TYPE_MAGNETIC_FIELD सेंसर को लागू करना ज़रूरी है. साथ ही, TYPE_MAGNETIC_FIELD_UNCALIBRATED सेंसर को भी लागू करना चाहिए. मौजूदा और नए Android डिवाइसों के लिए, TYPE_MAGNETIC_FIELD_UNCALIBRATED सेंसर को लागू करने का सुझाव दिया जाता है.
• यह कम से कम 10 हर्ट्ज तक की फ़्रीक्वेंसी वाले इवेंट की रिपोर्ट कर सकता हो. साथ ही, कम से कम 50 हर्ट्ज तक की फ़्रीक्वेंसी वाले इवेंट की रिपोर्ट कर सकता हो.
• Android API में बताए गए तरीके के मुताबिक, Android सेंसर कोऑर्डिनेट सिस्टम का पालन करना ज़रूरी है.
• यह ज़रूरी है कि सैचुरेट होने से पहले, हर अक्ष पर -900 µT से +900 µT के बीच मेज़रमेंट किया जा सके.
• मैग्नेटोमीटर को डाइनैमिक (इंजन से निकलने वाले करंट से) और स्टैटिक (मैग्नेट से) मैग्नेटिक फ़ील्ड से दूर रखकर, हार्ड आयरन ऑफ़सेट की वैल्यू 700 µT से कम होनी चाहिए. साथ ही, यह वैल्यू 200 µT से कम होनी चाहिए.
• रिज़ॉल्यूशन 0.6 µT के बराबर या उससे ज़्यादा होना चाहिए. साथ ही, रिज़ॉल्यूशन 0.2 µT के बराबर या उससे ज़्यादा होना चाहिए.
• तापमान के हिसाब से अडजस्ट होना चाहिए.
• यह ज़रूरी है कि यह हार्ड आयरन बायस के ऑनलाइन कैलिब्रेशन और कम्पेंसेशन के साथ काम करे. साथ ही, डिवाइस के रीबूट होने के बीच कम्पेंसेशन पैरामीटर को सुरक्षित रखे.
• इसमें सॉफ़्ट आयरन कम्पेंसेशन लागू होना चाहिए—कैलिब्रेशन, डिवाइस के इस्तेमाल के दौरान या उसके प्रोडक्शन के दौरान किया जा सकता है.
• इसका स्टैंडर्ड डेविएशन होना चाहिए. यह डेविएशन, हर अक्ष के आधार पर, सबसे तेज़ सैंपलिंग रेट पर कम से कम तीन सेकंड के दौरान इकट्ठा किए गए सैंपल के आधार पर कैलकुलेट किया जाता है. यह डेविएशन 0.5 µT से ज़्यादा नहीं होना चाहिए.
• अगर ऐक्सीलेरोमीटर सेंसर और जायरोस्कोप सेंसर भी शामिल है, तो TYPE_ROTATION_VECTOR कंपोजिट सेंसर लागू करना ज़रूरी है.
• अगर ऐक्सीलेरोमीटर सेंसर भी लागू किया गया है, तो TYPE_GEOMAGNETIC_ROTATION_VECTOR सेंसर लागू किया जा सकता है. हालांकि, अगर इसे लागू किया जाता है, तो यह 10 mW से कम खर्च करना चाहिए. साथ ही, जब सेंसर को 10 हर्ट्ज़ पर बैच मोड के लिए रजिस्टर किया जाता है, तो यह 3 mW से कम खर्च करना चाहिए.

7.3.3. जीपीएस

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

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

ध्यान दें कि ऊपर दी गई जीपीएस की कुछ ज़रूरी शर्तों के लिए, 'इसका सुझाव दिया जाता है' के तौर पर बताया गया है. हालांकि, अगले मुख्य वर्शन के लिए, 'ज़रूरी है' के तौर पर बदलाव किया जा सकता है.

7.3.4. जाइरोस्कोप

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

• TYPE_GYROSCOPE सेंसर को लागू करना ज़रूरी है. साथ ही, TYPE_GYROSCOPE_UNCALIBRATED सेंसर को भी लागू करना चाहिए. मौजूदा और नए Android डिवाइसों के लिए, SENSOR_TYPE_GYROSCOPE_UNCALIBRATED सेंसर को लागू करने का सुझाव दिया जाता है.
• यह ज़रूरी है कि यह हर सेकंड में 1,000 डिग्री तक के ओरिएंटेशन में होने वाले बदलावों को मेज़र कर सके.
• Android Watch डिवाइसों के लिए, कम से कम 50 हर्ट्ज़ की फ़्रीक्वेंसी तक इवेंट रिपोर्ट करने की ज़रूरत होती है. ऐसा इसलिए, क्योंकि इन डिवाइसों में बैटरी की कमी होती है. वहीं, अन्य सभी तरह के डिवाइसों के लिए, 100 हर्ट्ज़ की फ़्रीक्वेंसी तक इवेंट रिपोर्ट करने की ज़रूरत होती है.
• कम से कम 200 हर्ट्ज़ तक के इवेंट की रिपोर्ट करनी चाहिए.
• इसका रिज़ॉल्यूशन 12 बिट या उससे ज़्यादा होना चाहिए. हालांकि, इसका रिज़ॉल्यूशन 16 बिट या उससे ज़्यादा होना चाहिए.
• तापमान के हिसाब से अडजस्ट होने वाला होना चाहिए.
• इस्तेमाल के दौरान, इसे कैलिब्रेट और कंपेसेशन करना ज़रूरी है. साथ ही, डिवाइस के रीबूट होने के बीच कंपेसेशन पैरामीटर को बनाए रखना ज़रूरी है.
• हर हर्ट्ज (हर हर्ट्ज में वैरिएंस या rad^2 / s) के लिए, वैरिएंस 1e-7 rad^2 / s^2 से ज़्यादा नहीं होना चाहिए. वैरिएंस को सैंपलिंग रेट के हिसाब से बदलने की अनुमति है, लेकिन इसे इस वैल्यू के हिसाब से सीमित रखना चाहिए. दूसरे शब्दों में, अगर 1 हर्ट्ज़ सैंपलिंग रेट पर, घुमाव की दर का अंतर मेज़र किया जाता है, तो यह 1e-7 rad^2/s^2 से ज़्यादा नहीं होना चाहिए.
• अगर ऐक्सीलेरोमीटर सेंसर और मैग्नेटोमीटर सेंसर भी शामिल है, तो TYPE_ROTATION_VECTOR कंपोजिट सेंसर लागू करना ज़रूरी है.
• अगर ऐक्सीलेरोमीटर सेंसर शामिल है, तो TYPE_GRAVITY और TYPE_LINEAR_ACCELERATION कंपोजिट सेंसर लागू करना ज़रूरी है. साथ ही, TYPE_GAME_ROTATION_VECTOR कंपोजिट सेंसर लागू करना चाहिए. हमारा सुझाव है कि मौजूदा और नए Android डिवाइसों पर TYPE_GAME_ROTATION_VECTOR सेंसर लागू करें.

7.3.5. बैरोमीटर

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

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

7.3.6. Thermometer

डिवाइस में, आस-पास के तापमान को मापने वाला थर्मामीटर (तापमान सेंसर) शामिल हो सकता है. अगर यह मौजूद है, तो इसे SENSOR_TYPE_AMBIENT_TEMPERATURE के तौर पर तय किया जाना चाहिए. साथ ही, यह कमरे के तापमान को डिग्री सेल्सियस में मेज़र करना चाहिए.

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

7.3.7. फ़ोटोमीटर

डिवाइस में फ़ोटोमीटर (स्क्रीन की रोशनी को अपने-आप घटाने-बढ़ाने वाला सेंसर) शामिल हो सकता है.

7.3.8. निकटता सेंसर

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

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

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

बेहतर क्वालिटी वाले सेंसर के सेट के साथ काम करने वाले डिवाइसों को, इस सेक्शन में बताई गई सभी ज़रूरी शर्तों को पूरा करना होगा. साथ ही, android.hardware.sensor.hifi_sensors सुविधा फ़्लैग की मदद से, इसकी जानकारी देनी होगी.

android.hardware.sensor.hifi_sensors एट्रिब्यूट का इस्तेमाल करने वाले डिवाइस में, यहां दिए गए सभी सेंसर टाइप होने चाहिए. साथ ही, ये सेंसर क्वालिटी से जुड़ी इन शर्तों को पूरा करते हों:

• SENSOR_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° होना चाहिए.

• SENSOR_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 से कम होनी चाहिए.

• SENSOR_TYPE_GYROSCOPE_UNCALIBRATED, जिसकी क्वालिटी से जुड़ी ज़रूरी शर्तें SENSOR_TYPE_GYROSCOPE जैसी ही हैं.

• SENSOR_TYPE_GEOMAGNETIC_FIELD
  • मेज़रमेंट रेंज कम से कम -900 और +900 uT के बीच होनी चाहिए.
  • मेज़रमेंट का रिज़ॉल्यूशन कम से कम 5 LSB/uT होना चाहिए.
  • मेज़रमेंट फ़्रीक्वेंसी कम से कम 5 हर्ट्ज़ या उससे कम होनी चाहिए.
  • मेज़रमेंट की फ़्रीक्वेंसी 50 हर्ट्ज़ या इससे ज़्यादा होनी चाहिए.
  • मेज़रमेंट नॉइज़ 0.5 uT से ज़्यादा नहीं होना चाहिए.
• SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED, जिसकी क्वालिटी से जुड़ी ज़रूरी शर्तें SENSOR_TYPE_GEOMAGNETIC_FIELD जैसी ही हैं. इसके अलावा:
  • इस सेंसर के लिए, बिना 'जागने' वाले फ़ॉर्म को लागू करना ज़रूरी है. साथ ही, यह फ़ॉर्म कम से कम 600 सेंसर इवेंट को बफ़र करने की सुविधा के साथ होना चाहिए.
• SENSOR_TYPE_PRESSURE
  • मेज़रमेंट की रेंज कम से कम 300 और 1100 hPa के बीच होनी चाहिए.
  • माप का रिज़ॉल्यूशन कम से कम 80 LSB/hPa होना चाहिए.
  • मेज़रमेंट फ़्रीक्वेंसी कम से कम 1 हर्ट्ज़ या उससे कम होनी चाहिए.
  • मेज़रमेंट की फ़्रीक्वेंसी 10 हर्ट्ज़ या इससे ज़्यादा होनी चाहिए.
  • मेज़रमेंट नॉइज़ 2 Pa/√Hz से ज़्यादा नहीं होना चाहिए.
  • इस सेंसर के लिए, बिना डिवाइस को जगाने वाले फ़ॉर्म को लागू करना ज़रूरी है. साथ ही, यह फ़ॉर्म कम से कम 300 सेंसर इवेंट को बफ़र करने की सुविधा के साथ होना चाहिए.
  • बैचिंग के दौरान बिजली की खपत 2 mW से ज़्यादा नहीं होनी चाहिए.
• SENSOR_TYPE_GAME_ROTATION_VECTOR
  • इस सेंसर के लिए, बिना डिवाइस को जगाने वाले फ़ॉर्म को लागू करना ज़रूरी है. साथ ही, यह फ़ॉर्म कम से कम 300 सेंसर इवेंट को बफ़र करने की सुविधा के साथ होना चाहिए.
  • बैचिंग के दौरान, डिवाइस की बिजली की खपत 4 mW से ज़्यादा नहीं होनी चाहिए.
• SENSOR_TYPE_SIGNIFICANT_MOTION
  • डिवाइस के स्टैटिक होने पर, बिजली की खपत 0.5 mW से ज़्यादा नहीं होनी चाहिए. साथ ही, डिवाइस के मूव होने पर, बिजली की खपत 1.5 mW से ज़्यादा नहीं होनी चाहिए.
• SENSOR_TYPE_STEP_DETECTOR
  • इस सेंसर के लिए, बिना 'जागने' वाले फ़ॉर्म को लागू करना ज़रूरी है. साथ ही, यह फ़ॉर्म कम से कम 100 सेंसर इवेंट को बफ़र करने की सुविधा के साथ होना चाहिए.
  • डिवाइस के स्टैटिक होने पर, बिजली की खपत 0.5 mW से ज़्यादा नहीं होनी चाहिए. साथ ही, डिवाइस के मूव होने पर, बिजली की खपत 1.5 mW से ज़्यादा नहीं होनी चाहिए.
  • बैचिंग के दौरान, डिवाइस की बिजली की खपत 4 mW से ज़्यादा नहीं होनी चाहिए.
• SENSOR_TYPE_STEP_COUNTER
  • डिवाइस के स्टैटिक होने पर, बिजली की खपत 0.5 mW से ज़्यादा नहीं होनी चाहिए. साथ ही, डिवाइस के मूव होने पर, बिजली की खपत 1.5 mW से ज़्यादा नहीं होनी चाहिए.
• SENSOR_TILT_DETECTOR
  • डिवाइस के स्टैटिक होने पर, बिजली की खपत 0.5 mW से ज़्यादा नहीं होनी चाहिए. साथ ही, डिवाइस के मूव होने पर, बिजली की खपत 1.5 mW से ज़्यादा नहीं होनी चाहिए.

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

• एक ही फ़िज़िकल इवेंट के लिए, Accelerometer, Gyroscope सेंसर, और Magnetometer से रिपोर्ट किए गए इवेंट के टाइमस्टैंप में 2.5 मिलीसेकंड से ज़्यादा का अंतर नहीं होना चाहिए.
• यह ज़रूरी है कि जियोस्कोप सेंसर इवेंट के टाइमस्टैंप, कैमरा सबसिस्टम के टाइम बेस के हिसाब से हों. साथ ही, इनमें 1 मिलीसेकंड से ज़्यादा की गड़बड़ी नहीं होनी चाहिए.
• हाई फ़िडेलिटी सेंसर को, ऐप्लिकेशन के लिए सैंपल 5 मिलीसेकंड के अंदर डिलीवर करने होंगे. यह समय, सेंसर पर डेटा उपलब्ध होने से लेकर ऐप्लिकेशन तक डेटा पहुंचने में लगने वाला समय होता है.
• जब डिवाइस स्टैटिक हो, तो उसकी बिजली की खपत 0.5 mW से ज़्यादा नहीं होनी चाहिए. साथ ही, जब डिवाइस चल रहा हो, तो उसकी बिजली की खपत 2.0 mW से ज़्यादा नहीं होनी चाहिए. ऐसा तब होगा, जब इन सेंसर में से किसी भी कॉम्बिनेशन को चालू किया गया हो:
  • SENSOR_TYPE_SIGNIFICANT_MOTION
  • SENSOR_TYPE_STEP_DETECTOR
  • SENSOR_TYPE_STEP_COUNTER
  • SENSOR_TILT_DETECTORS

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

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

• SENSOR_TYPE_PROXIMITY: 100 सेंसर इवेंट

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

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

• ऐप्लिकेशन में android.hardware.fingerprint सुविधा के काम करने की जानकारी देना ज़रूरी है.
• Android SDK के दस्तावेज़ में बताए गए तरीके के मुताबिक, उससे जुड़े एपीआई को पूरी तरह से लागू करना ज़रूरी है.
• गलत स्वीकार किए जाने की दर 0.002% से ज़्यादा नहीं होनी चाहिए.
• हमारा सुझाव है कि डिवाइस पर मेज़र किए गए फ़ॉल्स रिजेक्शन रेट (गलत तरीके से अस्वीकार किए जाने की दर) 10% से कम हो
• हमारा सुझाव है कि फ़िंगरप्रिंट अनलॉक करने में एक सेकंड से कम समय लगे. यह समय, फ़िंगरप्रिंट सेंसर को छूने से लेकर, स्क्रीन अनलॉक होने तक का होता है. यह समय, रजिस्टर की गई एक उंगली के लिए होता है.
• फ़िंगरप्रिंट की मदद से पुष्टि करने के लिए, पांच बार गलत तरीके से कोशिश करने के बाद, कम से कम 30 सेकंड के लिए कोशिश करने की दर को सीमित करना ज़रूरी है.
• इसमें हार्डवेयर की मदद से काम करने वाला पासकोड स्टोर होना चाहिए. साथ ही, फ़िंगरप्रिंट मैचिंग की प्रोसेस, ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट (टीईई) या टीईई से सुरक्षित चैनल वाले चिप पर की जानी चाहिए.
• फ़िंगरप्रिंट से जुड़ा सारा डेटा एन्क्रिप्ट (सुरक्षित) होना चाहिए और क्रिप्टोग्राफ़ी की मदद से उसकी पुष्टि की जानी चाहिए. ऐसा इसलिए, ताकि उसे भरोसेमंद एक्सीक्यूशन एनवायरमेंट (टीईई) के बाहर न लिया जा सके, न पढ़ा जा सके और न ही उसमें बदलाव किया जा सके. इस बारे में, Android Open Source Project की साइट पर लागू करने के दिशा-निर्देशों में बताया गया है.
• उपयोगकर्ता को मौजूदा डिवाइस क्रेडेंशियल (पिन/पैटर्न/पासवर्ड) की पुष्टि करने या TEE से सुरक्षित नया डिवाइस क्रेडेंशियल जोड़ने के लिए कहकर, भरोसे की चेन सेट अप किए बिना फ़िंगरप्रिंट जोड़ने से रोकना ज़रूरी है. Android Open Source Project के लागू होने से, फ़्रेमवर्क में ऐसा करने का तरीका मिलता है.
• तीसरे पक्ष के ऐप्लिकेशन को अलग-अलग फ़िंगरप्रिंट के बीच अंतर करने की अनुमति नहीं देनी चाहिए.
• DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT फ़्लैग का पालन करना ज़रूरी है.
• Android 6.0 से पहले के वर्शन से अपग्रेड करने पर, ऊपर दी गई ज़रूरी शर्तों को पूरा करने के लिए, फ़िंगरप्रिंट डेटा को सुरक्षित तरीके से माइग्रेट करना या हटाना ज़रूरी है.
• Android Open Source Project में दिए गए Android फ़िंगरप्रिंट आइकॉन का इस्तेमाल करना चाहिए.

7.3.11. सिर्फ़ Android Automotive के लिए उपलब्ध सेंसर

वाहन से जुड़े सेंसर की जानकारी android.car.CarSensorManager API में दी गई है .

7.3.11.1. मौजूदा गियर

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

7.3.11.2. दिन रात मोड

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

7.3.11.3. ड्राइविंग की स्थिति

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

7.3.11.4. पहिए की रफ़्तार

Android Automotive के लागू होने पर, वाहन की रफ़्तार की जानकारी SENSOR_TYPE_CAR_SPEED के तौर पर दी जानी चाहिए.

7.3.12. आसन का पता लगाने वाला सेंसर

डिवाइस में, छह डिग्री ऑफ़ फ़्रीडम वाले पोज़ सेंसर का इस्तेमाल किया जा सकता है. हमारा सुझाव है कि Android वाले हैंडहेल्ड डिवाइसों पर इस सेंसर का इस्तेमाल किया जाए. अगर किसी डिवाइस में, पोज़ सेंसर की सुविधा 6 डिग्री ऑफ़ फ़्रीडम के साथ काम करती है, तो:

• TYPE_POSE_6DOF सेंसर को लागू करना और उसकी रिपोर्ट देना ज़रूरी है.
• यह सिर्फ़ रोटेशन वेक्टर के मुकाबले ज़्यादा सटीक होना चाहिए.

7.4. डेटा कनेक्टिविटी

7.4.1. टेलीफ़ोनी

Android API और इस दस्तावेज़ में, “टेलीफ़ोन” का इस्तेमाल खास तौर पर, GSM या CDMA नेटवर्क के ज़रिए वॉइस कॉल करने और एसएमएस भेजने से जुड़े हार्डवेयर के लिए किया गया है. ये वॉइस कॉल, पैकेट-स्विच किए जा सकते हैं या नहीं, लेकिन Android के लिए इन्हें उसी नेटवर्क का इस्तेमाल करके लागू की जाने वाली किसी भी डेटा कनेक्टिविटी से अलग माना जाता है. दूसरे शब्दों में, Android की “टेलीफ़ोन” सुविधा और एपीआई, खास तौर पर वॉइस कॉल और एसएमएस के बारे में बताते हैं. उदाहरण के लिए, जिन डिवाइसों पर कॉल नहीं किए जा सकते या एसएमएस मैसेज नहीं भेजे जा सकते या नहीं पाए जा सकते उन्हें android.hardware.telephony सुविधा या किसी भी सब-सुविधा की शिकायत नहीं करनी चाहिए. भले ही, वे डेटा कनेक्टिविटी के लिए मोबाइल नेटवर्क का इस्तेमाल करते हों.

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

7.4.1.1. नंबर ब्लॉक करने की सुविधा के साथ काम करने वाले डिवाइस

Android Telephony डिवाइस के लागू होने में, नंबर ब्लॉक करने की सुविधा और ये चीज़ें शामिल होनी चाहिए:

• SDK टूल के दस्तावेज़ में बताए गए तरीके से, BlockedNumberContract और उससे जुड़े एपीआई को पूरी तरह से लागू करना ज़रूरी है.
• 'BlockedNumberProvider' में मौजूद किसी फ़ोन नंबर से आने वाले सभी कॉल और मैसेज को ब्लॉक करना ज़रूरी है. इसके लिए, ऐप्लिकेशन के साथ कोई इंटरैक्शन नहीं करना चाहिए. हालांकि, SDK टूल के दस्तावेज़ में बताए गए तरीके से, नंबर ब्लॉक करने की सुविधा को कुछ समय के लिए हटाने पर, यह शर्त लागू नहीं होती.
• ब्लॉक किए गए कॉल के लिए, प्लैटफ़ॉर्म कॉल लॉग की सेवा देने वाली कंपनी को नहीं लिखना चाहिए.
• ब्लॉक किए गए मैसेज के लिए, टेलीफ़ोनी सेवा देने वाली कंपनी को नहीं लिखना चाहिए.
• ब्लॉक किए गए नंबरों को मैनेज करने के लिए यूज़र इंटरफ़ेस (यूआई) लागू करना ज़रूरी है. यह यूआई, TelecomManager.createManageBlockedNumbersIntent() तरीके से मिले इंटेंट से खुलता है.
• डिवाइस पर ब्लॉक किए गए नंबरों को देखने या उनमें बदलाव करने की अनुमति, दूसरे उपयोगकर्ताओं को नहीं दी जानी चाहिए. ऐसा इसलिए, क्योंकि Android प्लैटफ़ॉर्म यह मानता है कि डिवाइस पर टेलीफ़ोन सेवाओं का पूरा कंट्रोल, मुख्य उपयोगकर्ता के पास होता है. सेकंडरी उपयोगकर्ताओं के लिए, ब्लॉक करने से जुड़ा पूरा यूज़र इंटरफ़ेस (यूआई) छिपाया जाना चाहिए. साथ ही, ब्लॉक की गई सूची को भी लागू किया जाना चाहिए.
• जब कोई डिवाइस Android 7.0 पर अपडेट होता है, तो ब्लॉक किए गए नंबरों को मोबाइल और इंटरनेट सेवा देने वाली कंपनी के पास माइग्रेट करना चाहिए.

7.4.2. आईईईई 802.11 (वाई-फ़ाई)

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

• हार्डवेयर की सुविधा के फ़्लैग android.hardware.wifi की जानकारी ज़रूर दें.
• SDK टूल के दस्तावेज़ में बताए गए तरीके से, मल्टीकास्ट एपीआई को लागू करना ज़रूरी है.
• मल्टीकास्ट डीएनएस (mDNS) के साथ काम करना चाहिए. साथ ही, ऑपरेशन के किसी भी समय mDNS पैकेट (224.0.0.251) को फ़िल्टर नहीं करना चाहिए. इनमें ये भी शामिल हैं:
  • भले ही, स्क्रीन चालू न हो.
  • Android Television डिवाइसों के लिए, स्टैंडबाय मोड में भी.

7.4.2.1. Wi-Fi Direct

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

• हार्डवेयर की सुविधा android.hardware.wifi.direct की जानकारी देना ज़रूरी है.
• डिवाइस पर वाई-फ़ाई की सुविधा काम करती हो.
• यह वाई-फ़ाई और वाई-फ़ाई डायरेक्ट, दोनों मोड में काम करनी चाहिए.

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

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

• TDLS का इस्तेमाल सिर्फ़ तब करना चाहिए, जब यह मुमकिन हो और फ़ायदेमंद हो.
• इसमें कुछ ह्यूरिस्टिक होने चाहिए और जब इसकी परफ़ॉर्मेंस, वाई-फ़ाई ऐक्सेस पॉइंट से कनेक्ट होने की तुलना में खराब हो, तब TDLS का इस्तेमाल नहीं किया जाना चाहिए.

7.4.3. ब्लूटूथ

android.hardware.vr.high_performance सुविधा के साथ काम करने वाले डिवाइसों में, ब्लूटूथ 4.2 और ब्लूटूथ ले डेटा की लंबाई बढ़ाने की सुविधा का होना ज़रूरी है.

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

Android Automotive के लागू होने पर, मैसेज ऐक्सेस प्रोफ़ाइल (एमएपी) काम करनी चाहिए. Android Automotive के लागू होने के लिए, इन ब्लूटूथ प्रोफ़ाइलों के साथ काम करना ज़रूरी है:

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

ब्लूटूथ स्मार्ट (बीएलई) के साथ काम करने वाले डिवाइस:

• हार्डवेयर की सुविधा android.hardware.bluetooth_le का एलान करना ज़रूरी है.
• एसडीके दस्तावेज़ और android.bluetooth में बताए गए तरीके से, GATT (जनरेटिक एट्रिब्यूट प्रोफ़ाइल) पर आधारित ब्लूटूथ एपीआई चालू करना ज़रूरी है.
• को हमारा सुझाव है कि वे 15 मिनट से ज़्यादा का रिज़ॉल्व किए जा सकने वाले निजी पते (आरपीए) का टाइम आउट लागू करें. साथ ही, उपयोगकर्ता की निजता को सुरक्षित रखने के लिए, टाइम आउट होने पर पता बदलें.
• ScanFilter API को लागू करते समय, फ़िल्टर करने के लॉजिक को ब्लूटूथ चिपसेट पर ऑफ़लोड करने की सुविधा होनी चाहिए. साथ ही, android.bluetooth.BluetoothAdapter.isOffloadedFilteringSupported() तरीके से क्वेरी करने पर, फ़िल्टर करने के लॉजिक को लागू करने की सही वैल्यू की जानकारी देनी चाहिए.
• यह ब्लूटूथ चिपसेट पर, एक साथ कई डिवाइसों को स्कैन करने की सुविधा को ऑफ़लोड करने के साथ काम करना चाहिए. अगर ऐसा नहीं होता है, तो android.bluetooth.BluetoothAdapter.isOffloadedScanBatchingSupported() तरीके से क्वेरी करने पर, ‘गलत’ रिपोर्ट देनी चाहिए.
• यह कम से कम चार स्लॉट के साथ, एक से ज़्यादा विज्ञापन दिखाने की सुविधा के साथ काम करना चाहिए. अगर यह सुविधा काम नहीं करती है, तो android.bluetooth.BluetoothAdapter.isMultipleAdvertisementSupported() मेथड से क्वेरी करने पर, ‘गलत’ रिपोर्ट करनी चाहिए.

7.4.4. नियर फ़ील्ड कम्यूनिकेशन

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

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

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

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

• android.hardware.nfc.hce सुविधा के कॉन्सटेंट की रिपोर्ट करना ज़रूरी है.
• Android SDK में बताए गए तरीके के मुताबिक, एनएफ़सी एचसीई एपीआई के साथ काम करना चाहिए.

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

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

इसके अलावा, डिवाइस में इन MIFARE टेक्नोलॉजी के लिए रीडर/राइटर्स की सुविधा शामिल की जा सकती है.

• MIFARE Classic
• MIFARE Ultralight
• MIFARE Classic पर NDEF

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

• Android SDK टूल में बताए गए Android एपीआई को लागू करना ज़रूरी है.
• android.content.pm.PackageManager.hasSystemFeature() तरीके से, com.nxp.mifare सुविधा की जानकारी देना ज़रूरी है. ध्यान दें कि यह Android की स्टैंडर्ड सुविधा नहीं है. इसलिए, यह android.content.pm.PackageManager क्लास में एक कॉन्स्टेंट के तौर पर नहीं दिखती.
• इस सेक्शन में बताए गए तरीके से सामान्य एनएफ़सी सपोर्ट लागू किए बिना, संबंधित Android API लागू नहीं किए जाने चाहिए और न ही com.nxp.mifare सुविधा की रिपोर्ट की जानी चाहिए.

अगर किसी डिवाइस में NFC हार्डवेयर शामिल नहीं है, तो उसे android.content.pm.PackageManager.hasSystemFeature() तरीके से android.hardware.nfc सुविधा का एलान नहीं करना चाहिए. साथ ही, उसे Android NFC API को बिना किसी काम के लागू करना चाहिए.

android.nfc.NdefMessage और android.nfc.NdefRecord क्लास, प्रोटोकॉल से स्वतंत्र डेटा दिखाने के फ़ॉर्मैट को दिखाते हैं. इसलिए, डिवाइस में इन एपीआई को लागू करना ज़रूरी है. भले ही, इनमें एनएफ़सी के लिए सहायता शामिल न हो या android.hardware.nfc सुविधा का एलान न किया गया हो.

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

डिवाइस को लागू करने के लिए, डेटा नेटवर्किंग के एक या एक से ज़्यादा फ़ॉर्म के लिए सहायता ज़रूर होनी चाहिए. खास तौर पर, डिवाइस में कम से कम एक ऐसा डेटा स्टैंडर्ड होना चाहिए जो 200 केबीआईटी/सेकंड या उससे ज़्यादा की स्पीड पर काम कर सके. इस ज़रूरी शर्त को पूरा करने वाली टेक्नोलॉजी के उदाहरणों में, EDGE, HSPA, EV-DO, 802.11g, ईथरनेट, ब्लूटूथ पैन वगैरह शामिल हैं.

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

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

डिवाइसों में IPv6 नेटवर्किंग स्टैक होना ज़रूरी है. साथ ही, वे java.net.Socket और java.net.URLConnection जैसे मैनेज किए जा सकने वाले एपीआई के साथ-साथ AF_INET6 सॉकेट जैसे नेटिव एपीआई का इस्तेमाल करके, IPv6 कम्यूनिकेशन की सुविधा भी देते हों. आईपीवी6 के लिए ज़रूरी सहायता का लेवल, नेटवर्क टाइप पर निर्भर करता है. यह लेवल इस तरह से तय होता है:

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

IPv6, डिफ़ॉल्ट रूप से चालू होना चाहिए.

यह पक्का करने के लिए कि IPv6 कम्यूनिकेशन, IPv4 के जितने भरोसेमंद हो, डिवाइस पर भेजे गए यूनीकास्ट IPv6 पैकेट को ड्रॉप नहीं किया जाना चाहिए. भले ही, स्क्रीन चालू न हो. अगर बिजली बचाने के लिए ज़रूरी हो, तो हार्डवेयर या फ़र्मवेयर में, ग़ैर-ज़रूरी मल्टीकास्ट आईपीवी6 पैकेट की दर सीमित की जा सकती है. जैसे, एक जैसे राउटर विज्ञापनों को बार-बार भेजना. ऐसे मामलों में, दर को सीमित करने की वजह से, डिवाइस को IPv6 के साथ काम करने वाले किसी भी नेटवर्क पर IPv6 कनेक्टिविटी नहीं खोनी चाहिए. यह ज़रूरी है कि नेटवर्क पर RA लाइफ़टाइम कम से कम 180 सेकंड का हो.

IPv6 कनेक्टिविटी को ज़रूर डोज़ मोड में रखना चाहिए.

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

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

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

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

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

• SDK टूल के दस्तावेज़ में बताए गए तरीके से, ConnectivityManager क्लास के सभी एपीआई के साथ काम करना चाहिए

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

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

• ConnectivityManager.getRestrictBackgroundStatus() के लिए, RESTRICT_BACKGROUND_STATUS_DISABLED वैल्यू दिखानी चाहिए

• ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED को ब्रॉडकास्ट नहीं किया जाना चाहिए

• इसमें ऐसी गतिविधि होनी चाहिए जो Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS इंटेंट को मैनेज करती हो. हालांकि, इसे बिना किसी कार्रवाई के लागू किया जा सकता है.

7.5. कैमरे

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

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

7.5.1. पीछे वाला कैमरा

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

• फ़ीचर फ़्लैग android.hardware.camera और android.hardware.camera.any की रिपोर्ट करना ज़रूरी है.
• इसका रिज़ॉल्यूशन कम से कम 2 मेगापिक्सल होना चाहिए.
• कैमरा ड्राइवर में, हार्डवेयर ऑटो-फ़ोकस या सॉफ़्टवेयर ऑटो-फ़ोकस की सुविधा होनी चाहिए. यह सुविधा, ऐप्लिकेशन सॉफ़्टवेयर के लिए पारदर्शी होनी चाहिए.
• इसमें फ़िक्स्ड-फ़ोकस या EDOF (एक्सटेंडेड डेप्थ ऑफ़ फ़ील्ड) हार्डवेयर हो सकता है.
• इसमें फ़्लैश शामिल हो सकता है. अगर कैमरे में फ़्लैश है, तो कैमरे की झलक दिखाने वाले प्लैटफ़ॉर्म पर android.hardware.Camera.PreviewCallback इंस्टेंस रजिस्टर होने के दौरान, फ़्लैश लैंप नहीं जलना चाहिए. ऐसा तब तक नहीं होना चाहिए, जब तक कि ऐप्लिकेशन ने Camera.Parameters ऑब्जेक्ट के FLASH_MODE_AUTO या FLASH_MODE_ON एट्रिब्यूट को चालू करके, फ़्लैश को साफ़ तौर पर चालू न कर दिया हो. ध्यान दें कि यह पाबंदी, डिवाइस के पहले से मौजूद सिस्टम कैमरा ऐप्लिकेशन पर लागू नहीं होती. यह सिर्फ़ Camera.PreviewCallback का इस्तेमाल करने वाले तीसरे पक्ष के ऐप्लिकेशन पर लागू होती है.

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

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

• फ़ीचर फ़्लैग android.hardware.camera.any और android.hardware.camera.front की जानकारी देना ज़रूरी है.
• इसका रिज़ॉल्यूशन कम से कम VGA (640x480 पिक्सल) होना चाहिए.
• Camera API के लिए, सामने वाले कैमरे का इस्तेमाल डिफ़ॉल्ट तौर पर नहीं किया जाना चाहिए. Android में कैमरा एपीआई, सामने वाले कैमरे के लिए खास तौर पर काम करता है. डिवाइस में एपीआई को इस तरह कॉन्फ़िगर नहीं किया जाना चाहिए कि वह सामने वाले कैमरे को डिफ़ॉल्ट रूप से पीछे वाले कैमरे के तौर पर इस्तेमाल करे. भले ही, डिवाइस में सिर्फ़ यही कैमरा हो.
• इसमें सेक्शन 7.5.1 में बताई गई, पीछे की ओर लगे कैमरों के लिए उपलब्ध सुविधाएं (जैसे, ऑटो-फ़ोकस, फ़्लैश वगैरह) शामिल हो सकती हैं.
• CameraPreview में, किसी ऐप्लिकेशन की स्ट्रीम को हॉरिज़ॉन्टल तौर पर दिखाना ज़रूरी है. इसका तरीका यहां बताया गया है:
  • अगर डिवाइस को उपयोगकर्ता घुमा सकता है, जैसे कि ऐक्सीलेरोमीटर की मदद से अपने-आप या उपयोगकर्ता के इनपुट से मैन्युअल रूप से, तो कैमरे की झलक को डिवाइस के मौजूदा ओरिएंटेशन के हिसाब से हॉरिज़ॉन्टल रूप से मिरर किया जाना चाहिए.
  • अगर मौजूदा ऐप्लिकेशन ने साफ़ तौर पर अनुरोध किया है कि android.hardware.Camera.setDisplayOrientation() तरीके को कॉल करके, कैमरे के डिसप्ले को घुमाया जाए, तो ऐप्लिकेशन के तय किए गए ओरिएंटेशन के हिसाब से, कैमरे की झलक को हॉरिज़ॉन्टल तौर पर मिरर किया जाना चाहिए.
  • अगर ऐसा नहीं है, तो झलक को डिवाइस के डिफ़ॉल्ट हॉरिज़ॉन्टल ऐक्सिस के साथ मिरर किया जाना चाहिए.
• पोस्टव्यू से दिखाई गई इमेज को उसी तरह से दिखाना चाहिए जिस तरह से कैमरे की झलक वाली इमेज स्ट्रीम दिखती है. अगर डिवाइस पर पोस्टव्यू की सुविधा काम नहीं करती है, तो यह ज़रूरी शर्त लागू नहीं होगी.
• यह ज़रूरी है कि कैप्चर की गई फ़ाइनल स्टिल इमेज या वीडियो स्ट्रीम को ऐप्लिकेशन कॉलबैक में वापस न भेजा जाए या मीडिया स्टोरेज में सेव न किया जाए.

7.5.3. बाहरी कैमरा

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

• प्लैटफ़ॉर्म के फ़ीचर फ़्लैग android.hardware.camera.external और android.hardware camera.any के बारे में एलान करना ज़रूरी है .
• एक से ज़्यादा कैमरे इस्तेमाल करने की सुविधा हो सकती है.
• अगर बाहरी कैमरा यूएसबी पोर्ट से कनेक्ट होता है, तो यह ज़रूरी है कि वह यूएसबी वीडियो क्लास (यूवीसी 1.0 या उसके बाद का वर्शन) के साथ काम करता हो.
• अच्छी क्वालिटी वाली बिना कोड वाली स्ट्रीम (जैसे, रॉ या अलग से कंप्रेस की गई पिक्चर स्ट्रीम) को ट्रांसफ़र करने के लिए, MJPEG जैसे वीडियो कंप्रेस करने की सुविधा होनी चाहिए.
• कैमरे से वीडियो एन्कोड करने की सुविधा मिल सकती है. अगर डिवाइस पर यह सुविधा काम करती है, तो डिवाइस पर एक साथ अनकोड की गई / एमजेपीईजी स्ट्रीम (QVGA या इससे ज़्यादा रिज़ॉल्यूशन) को ऐक्सेस किया जा सकता है.

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

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

Android 5.0 में, पुराने एपीआई पैकेज, android.hardware.Camera को 'अब काम नहीं करता' के तौर पर मार्क किया गया है. हालांकि, यह Android डिवाइसों पर काम करने वाले ऐप्लिकेशन के लिए अब भी उपलब्ध होना चाहिए. इसलिए, यह पक्का करना ज़रूरी है कि एपीआई का इस्तेमाल जारी रहे. इस बारे में इस सेक्शन और Android SDK टूल में बताया गया है.

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

• अगर किसी ऐप्लिकेशन ने कभी android.hardware.Camera.Parameters.setPreviewFormat(int) को कॉल नहीं किया है, तो ऐप्लिकेशन कॉलबैक को दिए गए झलक डेटा के लिए, डिवाइस को android.hardware.PixelFormat.YCbCr_420_SP का इस्तेमाल करना होगा.
• अगर कोई ऐप्लिकेशन android.hardware.Camera.PreviewCallback इंस्टेंस रजिस्टर करता है और प्रीव्यू फ़ॉर्मैट YCbCr_420_SP होने पर सिस्टम, onPreviewFrame() मेथड को कॉल करता है, तो onPreviewFrame() में पास किए गए byte[] में मौजूद डेटा, NV21 एन्कोडिंग फ़ॉर्मैट में होना चाहिए. इसका मतलब है कि NV21, डिफ़ॉल्ट तौर पर होना चाहिए.
• android.hardware.Camera के लिए, डिवाइस में YV12 फ़ॉर्मैट (जैसा कि android.graphics.ImageFormat.YV12 कॉन्स्टेंट से पता चलता है) का इस्तेमाल किया जाना चाहिए. ऐसा, सामने और पीछे के कैमरे, दोनों के लिए कैमरे की झलक दिखाने के लिए ज़रूरी है. (हार्डवेयर वीडियो एन्कोडर और कैमरा, किसी भी नेटिव पिक्सल फ़ॉर्मैट का इस्तेमाल कर सकते हैं. हालांकि, डिवाइस में YV12 में बदलाव करने की सुविधा होनी चाहिए.)
• android.hardware.camera2 के लिए, डिवाइस में android.media.ImageReader API की मदद से, आउटपुट के तौर पर android.hardware.ImageFormat.YUV_420_888 और android.hardware.ImageFormat.JPEG फ़ॉर्मैट काम करने चाहिए.

डिवाइस में, Android SDK टूल के दस्तावेज़ में शामिल Camera API को पूरी तरह से लागू करना ज़रूरी है. भले ही, डिवाइस में ऑटोफ़ोकस करने वाला हार्डवेयर या अन्य सुविधाएं हों. उदाहरण के लिए, जिन कैमरों में ऑटोफ़ोकस की सुविधा नहीं होती उन्हें भी रजिस्टर किए गए किसी भी android.hardware.Camera.AutoFocusCallback इंस्टेंस को कॉल करना होगा. भले ही, ऑटोफ़ोकस की सुविधा वाले कैमरे के लिए ऐसा करना ज़रूरी नहीं है. ध्यान दें कि यह फ़्रंट-फ़ेसिंग कैमरों पर भी लागू होता है. उदाहरण के लिए, ज़्यादातर फ़्रंट-फ़ेसिंग कैमरे ऑटोफ़ोकस की सुविधा के साथ काम नहीं करते. इसके बावजूद, एपीआई कॉलबैक को ऊपर बताए गए तरीके से “फ़ेक” किया जाना चाहिए.

अगर डिवाइस का हार्डवेयर इस सुविधा के साथ काम करता है, तो डिवाइस पर लागू होने वाले कैमरे को android.hardware.Camera.Parameters क्लास में, कॉन्स्टेंट के तौर पर तय किए गए हर पैरामीटर के नाम को पहचानना और उनका इस्तेमाल करना ज़रूरी है. अगर डिवाइस का हार्डवेयर किसी सुविधा के साथ काम नहीं करता है, तो एपीआई को उसी तरह काम करना चाहिए जिस तरह से दस्तावेज़ में बताया गया है. इसके उलट, डिवाइस के लागू होने पर, android.hardware.Camera.setParameters() तरीके में पास की गई स्ट्रिंग कॉन्स्टेंट को स्वीकार नहीं किया जाना चाहिए. हालांकि, android.hardware.Camera.Parameters पर कॉन्स्टेंट के तौर पर दस्तावेज़ में दर्ज कॉन्स्टेंट को स्वीकार किया जा सकता है. इसका मतलब है कि अगर हार्डवेयर की अनुमति है, तो डिवाइस पर सभी स्टैंडर्ड कैमरा पैरामीटर काम करने चाहिए. साथ ही, कस्टम कैमरा पैरामीटर टाइप काम नहीं करने चाहिए. उदाहरण के लिए, हाई डाइनैमिक रेंज (एचडीआर) इमेजिंग तकनीकों का इस्तेमाल करके इमेज कैप्चर करने की सुविधा वाले डिवाइसों में, कैमरा पैरामीटर Camera.SCENE_MODE_HDR का इस्तेमाल किया जाना चाहिए.

सभी डिवाइसों पर, android.hardware.camera2 API की सभी सुविधाएं पूरी तरह से काम नहीं करतीं. इसलिए, डिवाइसों पर android.info.supportedHardwareLevel प्रॉपर्टी की मदद से, यह बताना ज़रूरी है कि डिवाइस पर यह API किस लेवल पर काम करता है. इस बारे में Android SDK में बताया गया है. साथ ही, डिवाइस पर फ़्रेमवर्क की सुविधा के फ़्लैग की जानकारी देना भी ज़रूरी है.

डिवाइस में लागू करने के लिए, android.request.availableCapabilities प्रॉपर्टी की मदद से, android.hardware.camera2 के अलग-अलग कैमरे की सुविधाओं का एलान करना ज़रूरी है. साथ ही, सही सुविधा फ़्लैग का एलान करना भी ज़रूरी है. अगर डिवाइस से जुड़ा कोई कैमरा डिवाइस इस सुविधा के साथ काम करता है, तो डिवाइस को सुविधा फ़्लैग तय करना होगा.

जब भी कैमरे से कोई नई फ़ोटो ली जाती है और फ़ोटो की एंट्री को मीडिया स्टोर में जोड़ दिया जाता है, तो डिवाइस को Camera.ACTION_NEW_PICTURE इंटेंट ब्रॉडकास्ट करना ज़रूरी है.

जब भी कैमरे से कोई नया वीडियो रिकॉर्ड किया जाता है और मीडिया स्टोर में फ़ोटो की एंट्री जोड़ी जाती है, तो डिवाइस को Camera.ACTION_NEW_VIDEO इंटेंट ब्रॉडकास्ट करना ज़रूरी है.

7.5.5. कैमरे का ओरिएंटेशन

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

7.6. डिवाइस की मेमोरी और स्टोरेज

7.6.1. डिवाइस की कम से कम मेमोरी और स्टोरेज

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

डेंसिटी और स्क्रीन का साइज़	32-बिट डिवाइस	64-बिट डिवाइस
Android Watch डिवाइस (छोटी स्क्रीन की वजह से)	416 एमबी	लागू नहीं
छोटी/सामान्य स्क्रीन पर 280 डीपीआई या उससे कम बड़ी स्क्रीन पर mdpi या उससे कम एक्स्ट्रा लार्ज स्क्रीन पर ldpi या उससे कम	512 एमबी	816 एमबी
छोटी/सामान्य स्क्रीन पर xhdpi या उससे ज़्यादा बड़ी स्क्रीन पर hdpi या उससे ज़्यादा ज़्यादा बड़ी स्क्रीन पर mdpi या उससे ज़्यादा	608 एमबी	944 एमबी
छोटी/सामान्य स्क्रीन पर 400 डीपीआई या उससे ज़्यादा बड़ी स्क्रीन पर xhdpi या उससे ज़्यादा बहुत बड़ी स्क्रीन पर tvdpi या उससे ज़्यादा	896 एमबी	1280 एमबी
छोटी/सामान्य स्क्रीन पर 560 डीपीआई या उससे ज़्यादा बड़ी स्क्रीन पर 400 डीपीआई या उससे ज़्यादा बहुत बड़ी स्क्रीन पर xhdpi या उससे ज़्यादा	1344 एमबी	1824 एमबी

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

ऐसे डिवाइस जिनमें कम से कम 512 एमबी मेमोरी, कर्नेल और यूज़रस्पेस के लिए उपलब्ध हो. हालांकि, अगर डिवाइस Android Watch है, तो उसे ActivityManager.isLowRamDevice() के लिए "सही" वैल्यू दिखानी होगी.

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

Android API में एक डाउनलोड मैनेजर शामिल होता है. ऐप्लिकेशन, डेटा फ़ाइलें डाउनलोड करने के लिए इसका इस्तेमाल कर सकते हैं. डिवाइस में डाउनलोड मैनेजर की सुविधा, डिफ़ॉल्ट “कैश” लोकेशन में कम से कम 100 एमबी साइज़ की अलग-अलग फ़ाइलें डाउनलोड कर सकता हो.

7.6.2. ऐप्लिकेशन का शेयर किया गया स्टोरेज

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

डिवाइस पर, शेयर किए गए स्टोरेज को डिफ़ॉल्ट रूप से माउंट किया जाना चाहिए. अगर शेयर किया गया स्टोरेज, Linuxpath /sdcard पर माउंट नहीं किया गया है, तो डिवाइस में /sdcard से असल माउंट पॉइंट तक का Linux सिंबल लिंक होना चाहिए.

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

• एसडी कार्ड न होने पर, उपयोगकर्ता को चेतावनी देने के लिए, टॉस्ट या पॉप-अप यूज़र इंटरफ़ेस लागू करना ज़रूरी है.
• इसमें 1 जीबी या उससे ज़्यादा स्टोरेज वाला, FAT फ़ॉर्मैट वाला एसडी कार्ड होना चाहिए. इसके अलावा, खरीदारी के समय बॉक्स और अन्य उपलब्ध कॉन्टेंट पर यह भी दिखना चाहिए कि एसडी कार्ड को अलग से खरीदना होगा.
• डिफ़ॉल्ट रूप से एसडी कार्ड को माउंट करना चाहिए.

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

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

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

हालांकि, डिवाइस में लागू करने के लिए, Android की मीडिया स्कैनर सेवा और android.provider.MediaStore की मदद से, दोनों स्टोरेज पाथ का कॉन्टेंट साफ़ तौर पर दिखाया जाना चाहिए.

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

• यह Android File Transfer, Android MTP होस्ट के साथ काम करना चाहिए.
• यूएसबी डिवाइस क्लास 0x00 की रिपोर्ट करनी चाहिए.
• यूएसबी इंटरफ़ेस का नाम 'MTP' होना चाहिए.

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

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

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

7.7. यूएसबी

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

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

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

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

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

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

• अगर डिवाइस में यूएसबी 3.1 की सुविधा है, तो टाइप-सी यूएसबी पोर्ट का इस्तेमाल करना चाहिए.
• इसमें किसी गैर-स्टैंडर्ड पोर्ट फ़ॉर्म फ़ैक्टर का इस्तेमाल किया जा सकता है. हालांकि, अगर ऐसा किया जाता है, तो पोर्ट को स्टैंडर्ड टाइप-A या टाइप-C यूएसबी पोर्ट में बदलने वाली केबल या केबलों के साथ शिप करना ज़रूरी है.
• माइक्रो-एबी यूएसबी पोर्ट का इस्तेमाल किया जा सकता है. हालांकि, अगर ऐसा है, तो डिवाइस के साथ एक या उससे ज़्यादा केबल भी होनी चाहिए, ताकि पोर्ट को स्टैंडर्ड टाइप-ए या टाइप-सी यूएसबी पोर्ट में बदला जा सके.
• यूएसबी ऑडियो क्लास को लागू करने का ज़ोरदार सुझाव दिया जाता है. इसके लिए, Android SDK के दस्तावेज़ में दिया गया तरीका अपनाएं.
• Android SDK में बताए गए तरीके से, Android USB host API को लागू करना ज़रूरी है. साथ ही, यह भी ज़रूरी है कि आपने हार्डवेयर की सुविधा android.hardware.usb.host के साथ काम करने का एलान किया हो.
• होस्ट मोड में डिवाइस को चार्ज करने की सुविधा होनी चाहिए. साथ ही, यूएसबी टाइप-सी कनेक्टर के लिए, [USB Type-C Cable and Connector Specification Revision 1.2] (http://www.usb.org/developers/docs/usb_31_021517.zip) के टर्मिनेशन पैरामीटर सेक्शन में बताए गए मुताबिक, कम से कम 1.5 ऐंपियर का सोर्स करंट दिखाना चाहिए. इसके अलावा, माइक्रो-एबी कनेक्टर के लिए, USB Battery Charging specifications, revision 1.2 में बताए गए मुताबिक, चार्जिंग डाउनस्ट्रीम पोर्ट(सीडीपी) आउटपुट करंट की रेंज का इस्तेमाल करना चाहिए.
• हमारा सुझाव है कि यूएसबी टाइप-सी डिवाइसों में DisplayPort की सुविधा होनी चाहिए. साथ ही, इनमें यूएसबी सुपरस्पीड डेटा रेट की सुविधा भी होनी चाहिए. साथ ही, हमारा सुझाव है कि इन डिवाइसों में डेटा और पावर रोल स्वैप करने के लिए, पावर डिलीवरी की सुविधा होनी चाहिए.
• टाइप-A या टाइप-AB पोर्ट वाले डिवाइसों को, इस पोर्ट को टाइप-C पोर्ट में बदलने वाले अडैप्टर के साथ शिप नहीं किया जाना चाहिए.
• अगर स्टोरेज ऐक्सेस फ़्रेमवर्क (SAF) काम करता है, तो यह ज़रूरी है कि ऐप्लिकेशन, रिमोट तौर पर कनेक्ट किए गए किसी भी MTP (मीडिया ट्रांसफ़र प्रोटोकॉल) डिवाइस को पहचाने और उसके कॉन्टेंट को ACTION_GET_CONTENT , ACTION_OPEN_DOCUMENT , और ACTION_CREATE_DOCUMENT इंटेंट की मदद से ऐक्सेस करने की सुविधा दे.
• अगर टाइप-सी यूएसबी पोर्ट का इस्तेमाल किया जा रहा है और उसमें पेरिफ़रल मोड की सुविधा शामिल है, तो यूएसबी टाइप-सी के खास निर्देशों (सेक्शन 4.5.1.3.3) के मुताबिक, पोर्ट की दोहरी भूमिका की सुविधा लागू करना ज़रूरी है.
• अगर डिवाइस में ड्यूअल रोल पोर्ट की सुविधा काम करती है, तो डिवाइस के फ़ॉर्म फ़ैक्टर के हिसाब से सबसे सही Try.* मॉडल लागू करें. उदाहरण के लिए, हैंडहेल्ड डिवाइस पर Try.SNK मॉडल लागू किया जाना चाहिए.

7.8. ऑडियो

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

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

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

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

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

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

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

Android Watch डिवाइस के लिए, ऑडियो आउटपुट की सुविधा हो सकती है, लेकिन ऐसा होना ज़रूरी नहीं है. हालांकि, अन्य तरह के Android डिवाइसों के लिए, ऑडियो आउटपुट की सुविधा होना ज़रूरी है. साथ ही, android.hardware.audio.output एट्रिब्यूट का एलान करना भी ज़रूरी है.

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

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

• यह ज़रूरी है कि यह माइक्रोफ़ोन वाले स्टीरियो हेडफ़ोन और स्टीरियो हेडसेट पर ऑडियो चलाने की सुविधा दे. साथ ही, माइक्रोफ़ोन वाले स्टीरियो हेडसेट से ऑडियो रिकॉर्ड करने की सुविधा भी देनी चाहिए.
• यह ज़रूरी है कि यह CTIA पिन-आउट ऑर्डर वाले TRRS ऑडियो प्लग के साथ काम करे. साथ ही, यह OMTP पिन-आउट ऑर्डर वाले ऑडियो प्लग के साथ काम करे.
• अगर डिवाइस में माइक्रोफ़ोन की सुविधा काम करती है, तो प्लग-इन की गई ऑडियो ऐक्सेसरी पर माइक्रोफ़ोन का पता लगाने की सुविधा होनी चाहिए. साथ ही, माइक्रोफ़ोन की अतिरिक्त वैल्यू को 1 पर सेट करके, android.intent.action.HEADSET_PLUG को ब्रॉडकास्ट करना चाहिए.
• ऑडियो प्लग पर माइक्रोफ़ोन और ग्राउंड कंडक्टर के बीच, इवैलेंट इंपेडेन्स की इन तीन रेंज के लिए, कीकोड का पता लगाने और उन्हें मैप करने की सुविधा होनी चाहिए:
  • 70 ओम या उससे कम : KEYCODE_HEADSETHOOK
  • 210-290 ओम : KEYCODE_VOLUME_UP
  • 360-680 ओम : KEYCODE_VOLUME_DOWN
• ऑडियो प्लग पर माइक्रोफ़ोन और ग्राउंड कंडक्टर के बीच, इवैलेंट इंपेडेन्स की इस रेंज का पता लगाने और उसे कोड से मैप करने का ज़रूर सुझाव दिया जाता है:
  • 110-180 ओम: KEYCODE_VOICE_ASSIST
• प्लग डालने पर, ACTION_HEADSET_PLUG को ट्रिगर करना ज़रूरी है. हालांकि, ऐसा सिर्फ़ तब करना चाहिए, जब प्लग के सभी संपर्क, जैक पर उनके काम के सेगमेंट को छू रहे हों.
• यह 32 ओम के स्पीकर इंपेडेन्स पर, कम से कम 150mV ± 10% आउटपुट वोल्टेज को ड्राइव करने में सक्षम होना चाहिए.
• माइक्रोफ़ोन का बायस वोल्टेज 1.8V से 2.9V के बीच होना चाहिए.

7.8.3. नियर-अल्ट्रासाउंड

नियर-अल्ट्रासोनिक ऑडियो, 18.5 किलोहर्ट्ज़ से 20 किलोहर्ट्ज़ बैंड में होता है. डिवाइस में लागू किए गए सिस्टम को, AudioManager.getProperty एपीआई की मदद से, नियर-अल्ट्रासाउंड ऑडियो की सुविधा के काम करने की जानकारी सही तरीके से देनी होगी. इसके लिए, यह तरीका अपनाएं:

• अगर PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND "सही" है, तो VOICE_RECOGNITION और UNPROCESSED ऑडियो सोर्स को इन ज़रूरी शर्तों को पूरा करना होगा:
  • माइक्रोफ़ोन की औसत पावर रिस्पॉन्स, 18.5 किलोहर्ट्ज़ से 20 किलोहर्ट्ज़ बैंड में, 2 किलोहर्ट्ज़ पर रिस्पॉन्स से 15 डीबी से ज़्यादा नहीं होनी चाहिए.
  • माइक्रोफ़ोन का बिना वेट किए गए सिग्नल-टू-नॉइज़ रेशियो, 18.5 केएचज़ से 20 केएचज़ तक होना चाहिए. साथ ही, -26 डीबीएफ़एस पर 19 केएचज़ टोन के लिए, यह रेशियो 50 डीबी से कम नहीं होना चाहिए.
• अगर PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND "सही" है, तो 18.5 किलोहर्ट्ज़ से 20 किलोहर्ट्ज़ के बीच स्पीकर का औसत रिस्पॉन्स, 2 किलोहर्ट्ज़ के रिस्पॉन्स से 40 डीबी कम होना चाहिए.

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

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

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

Android हैंडहेल्ड डिवाइस के ऐसे वर्शन जो वीआर ऐप्लिकेशन के लिए किसी ऐसे मोड के साथ काम करते हैं जो सूचनाओं को स्टीरियोस्कोपिक रेंडरिंग के साथ दिखाता है और वीआर ऐप्लिकेशन के फ़ोकस में होने पर, मोनोस्कोपिक सिस्टम यूज़र इंटरफ़ेस (यूआई) कॉम्पोनेंट को बंद करता है, उन्हें android.software.vr.mode सुविधा के बारे में बताना होगा. इस सुविधा का एलान करने वाले डिवाइसों में, android.service.vr.VrListenerService लागू करने वाला कोई ऐप्लिकेशन होना चाहिए. इसे android.app.Activity#setVrModeEnabled के ज़रिए वीआर ऐप्लिकेशन चालू कर सकते हैं.

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

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

• डिवाइस में कम से कम दो फ़िज़िकल कोर होने चाहिए.
• डिवाइस में इस सुविधा को लागू करने के लिए, android.software.vr.mode सुविधा का एलान करना ज़रूरी है.
• डिवाइस पर लागू होने पर, फ़ोरग्राउंड ऐप्लिकेशन को एक खास कोर दिया जा सकता है. साथ ही, Process.getExclusiveCores API की मदद से, फ़ोरग्राउंड में चल रहे मुख्य ऐप्लिकेशन के लिए उपलब्ध सीपीयू कोर की संख्या देखी जा सकती है. अगर एक्सक्लूज़िव कोर काम करता है, तो कोर को उस पर किसी भी अन्य यूज़रस्पेस प्रोसेस को चलाने की अनुमति नहीं देनी चाहिए. हालांकि, ऐप्लिकेशन के इस्तेमाल किए गए डिवाइस ड्राइवर को चलाने की अनुमति दी जा सकती है. इसके अलावा, ज़रूरत पड़ने पर कुछ कर्नेल प्रोसेस को चलाने की अनुमति भी दी जा सकती है.
• डिवाइस में लागू किए गए ऐप्लिकेशन, बेहतर परफ़ॉर्मेंस मोड के साथ काम करने चाहिए.
• डिवाइस पर लागू किए गए वर्शन में, OpenGL ES 3.2 का इस्तेमाल किया जाना चाहिए.
• डिवाइस पर Vulkan हार्डवेयर लेवल 0 काम करना चाहिए और Vulkan हार्डवेयर लेवल 1 काम करना चाहिए.
• डिवाइस में EGL_KHR_mutable_render_buffer और EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_create_native_client_buffer, EGL_KHR_fence_sync, और EGL_KHR_wait_sync को लागू करना ज़रूरी है, ताकि इनका इस्तेमाल शेयर किए गए बफ़र मोड के लिए किया जा सके. साथ ही, उपलब्ध EGL एक्सटेंशन की सूची में एक्सटेंशन दिखाए जा सकें.
• जीपीयू और डिसप्ले, शेयर किए गए फ़्रंट बफ़र को सिंक कर पाएं. इससे, दो रेंडर कॉन्टेक्स्ट के साथ 60fps पर, वैकल्पिक आंखों से रेंडर किए गए वीआर कॉन्टेंट को बिना किसी टियरिंग आर्टफ़ैक्ट के दिखाया जा सकेगा.
• डिवाइस पर लागू करने के लिए, EGL_IMG_context_priority को लागू करना ज़रूरी है. साथ ही, उपलब्ध EGL एक्सटेंशन की सूची में एक्सटेंशन को दिखाना ज़रूरी है.
• डिवाइस में लागू करने के लिए, GL_EXT_multisampled_render_to_texture, GL_OVR_multiview, GL_OVR_multiview2, और GL_OVR_multiview_multisampled_render_to_texture एक्सटेंशन लागू करना ज़रूरी है. साथ ही, उपलब्ध GL एक्सटेंशन की सूची में एक्सटेंशन दिखाना भी ज़रूरी है.
• डिवाइस में EGL_EXT_protected_content और GL_EXT_protected_textures को लागू करना ज़रूरी है, ताकि इसका इस्तेमाल सुरक्षित टेक्स्चर वीडियो चलाने के लिए किया जा सके. साथ ही, उपलब्ध EGL और GL एक्सटेंशन की सूची में एक्सटेंशन दिखाए जा सकें.
• डिवाइस में H.264 डिकोडिंग की सुविधा कम से कम 3840x2160@30fps-40Mbps (1920x1080@30fps-10Mbps के चार इंस्टेंस या 1920x1080@60fps-20Mbps के दो इंस्टेंस के बराबर) पर काम करनी चाहिए.
• डिवाइस में HEVC और VP9 का इस्तेमाल किया जाना चाहिए. साथ ही, यह कम से कम 1920x1080@30fps-10 एमबीपीएस को डिकोड करने में सक्षम होना चाहिए. साथ ही, यह 3840x2160@30fps-20 एमबीपीएस (1920x1080@30fps-5 एमबीपीएस के चार इंस्टेंस के बराबर) को डिकोड करने में भी सक्षम होना चाहिए.
• डिवाइस में इस सुविधा को लागू करने के लिए, हमारा सुझाव है कि आप android.hardware.sensor.hifi_sensors सुविधा का इस्तेमाल करें. साथ ही, यह ज़रूरी है कि आपके डिवाइस में android.hardware.hifi_sensors के लिए, gyroscope, accelerometer, और magnetometer से जुड़ी ज़रूरी शर्तें पूरी हों.
• डिवाइस में लागू किए गए टूल, HardwarePropertiesManager.getDeviceTemperatures API के साथ काम करने चाहिए. साथ ही, त्वचा के तापमान की सटीक वैल्यू दिखाने चाहिए.
• डिवाइस में एम्बेड की गई स्क्रीन होनी चाहिए. साथ ही, इसका रिज़ॉल्यूशन कम से कम फ़ुल एचडी(1080 पिक्सल) होना चाहिए. हमारा सुझाव है कि यह रिज़ॉल्यूशन क्वाड एचडी (1440 पिक्सल) या इससे ज़्यादा हो.
• डिसप्ले का डायगनल साइज़ 4.7" से 6" के बीच होना चाहिए.
• VR मोड में, डिसप्ले कम से कम 60 हर्ट्ज़ पर अपडेट होना चाहिए.
• ग्रे-टू-ग्रे, व्हाइट-टू-ब्लैक, और ब्लैक-टू-व्हाइट स्विच करने में लगने वाला समय 3 मिलीसेकंड से कम होना चाहिए.
• डिसप्ले में,कम-टिकट मोड की सुविधा होनी चाहिए. इसमें टिकट का मतलब है कि पिक्सल कितनी देर तक रोशनी छोड़ता है. यह समय 5 मिलीसेकंड से कम होना चाहिए.
• डिवाइस में ब्लूटूथ 4.2 और ब्लूटूथ ले डेटा की लंबाई बढ़ाने की सुविधा सेक्शन 7.4.3 का इस्तेमाल किया जाना चाहिए.

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

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

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

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

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

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

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

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

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

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

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

8.4. बिजली की खपत का हिसाब लगाना

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

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

8.5. लगातार अच्छी परफ़ॉर्मेंस

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

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

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

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

अगर किसी डिवाइस पर एक्सक्लूज़िव कोर काम नहीं करता है, तो उसे Process.getExclusiveCores() एपीआई तरीके से खाली सूची दिखानी होगी.

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

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

9.1. अनुमतियां

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

'PROTECTION_FLAG_PRIVILEGED' के protectionLevel वाली अनुमतियां, सिर्फ़ उन ऐप्लिकेशन को दी जानी चाहिए जिन्हें सिस्टम इमेज के अनुमति वाले खास पाथ में पहले से लोड किया गया है. जैसे, AOSP लागू करने में system/priv-app पाथ.

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

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

9.2. यूआईडी और प्रोसेस अलग करना

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

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

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

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

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

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

अन्य रनटाइम को उन संसाधनों का ऐक्सेस नहीं दिया जाना चाहिए जिन्हें <uses-permission> सुविधा की मदद से, रनटाइम की AndroidManifest.xml फ़ाइल में अनुरोध नहीं किया गया है.

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

वैकल्पिक रनटाइम, Android सैंडबॉक्स मॉडल का पालन करते हों. खास तौर पर, वैकल्पिक रनटाइम:

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

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

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

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

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

• Android Automotive डिवाइस में, एक से ज़्यादा उपयोगकर्ताओं के लिए इस्तेमाल की सुविधा चालू होने पर, गेस्ट खाता होना ज़रूरी है. इस खाते से, वाहन के सिस्टम के सभी फ़ंक्शन इस्तेमाल किए जा सकते हैं. इसके लिए, उपयोगकर्ता को लॉग इन करने की ज़रूरत नहीं होती.
• जिन डिवाइसों में android.hardware.telephony सुविधा फ़्लैग का एलान नहीं किया गया है उन्हें पाबंदी वाली प्रोफ़ाइलों के साथ काम करना चाहिए. इस सुविधा की मदद से, डिवाइस के मालिक अन्य उपयोगकर्ताओं और उनके डिवाइस पर उपलब्ध सुविधाओं को मैनेज कर सकते हैं. पाबंदी वाली प्रोफ़ाइलों की मदद से, डिवाइस के मालिक अन्य उपयोगकर्ताओं के लिए अलग-अलग एनवायरमेंट तुरंत सेट अप कर सकते हैं. साथ ही, उन एनवायरमेंट में उपलब्ध ऐप्लिकेशन पर ज़्यादा सटीक पाबंदियां भी लगा सकते हैं.
• इसके उलट, जिन डिवाइसों में android.hardware.telephony सुविधा फ़्लैग का इस्तेमाल किया गया है उन्हें प्रतिबंधित प्रोफ़ाइलों के साथ काम नहीं करना चाहिए. हालांकि, उन्हें AOSP के कंट्रोल के साथ काम करना चाहिए, ताकि अन्य उपयोगकर्ताओं को वॉइस कॉल और एसएमएस ऐक्सेस करने की अनुमति दी या बंद की जा सके.
• डिवाइस के लिए, हर उपयोगकर्ता के लिए ऐसा सुरक्षा मॉडल लागू करना ज़रूरी है जो Android प्लैटफ़ॉर्म के सुरक्षा मॉडल के मुताबिक हो. इसकी जानकारी, एपीआई में सुरक्षा और अनुमतियों के रेफ़रंस दस्तावेज़ में दी गई है.
• Android डिवाइस पर हर उपयोगकर्ता इंस्टेंस के लिए, अलग और अलग-अलग स्टोरेज डायरेक्ट्री होनी चाहिए. डिवाइस पर लागू करने पर, एक ही वॉल्यूम या फ़ाइल सिस्टम में कई उपयोगकर्ताओं का डेटा सेव किया जा सकता है. हालांकि, डिवाइस पर लागू करने के दौरान यह पक्का करना ज़रूरी है कि किसी उपयोगकर्ता के मालिकाना हक वाले और उसकी ओर से चलने वाले ऐप्लिकेशन, किसी दूसरे उपयोगकर्ता के मालिकाना हक वाले डेटा को न तो पढ़ सकें और न ही उसमें बदलाव कर सकें. ध्यान दें कि एसडी कार्ड स्लॉट जैसे हटाए जा सकने वाले मीडिया की मदद से, होस्ट पीसी के ज़रिए एक उपयोगकर्ता दूसरे उपयोगकर्ता का डेटा ऐक्सेस कर सकता है. इस वजह से, बाहरी स्टोरेज एपीआई के लिए, डिवाइस में इस्तेमाल किए जाने वाले हटाए जा सकने वाले मीडिया को एसडी कार्ड के कॉन्टेंट को एन्क्रिप्ट करना ज़रूरी है. ऐसा तब करना होगा, जब मल्टी-यूज़र मोड चालू हो. इसके लिए, ऐसी कुंजी का इस्तेमाल करना होगा जो सिर्फ़ नॉन-रिमूवेबल मीडिया में सेव हो और जिसे सिर्फ़ सिस्टम ऐक्सेस कर सके. इससे होस्ट पीसी, मीडिया को नहीं पढ़ पाएगा. इसलिए, डिवाइस को MTP या मिलते-जुलते सिस्टम पर स्विच करना होगा, ताकि होस्ट पीसी को मौजूदा उपयोगकर्ता के डेटा का ऐक्सेस दिया जा सके. इसलिए, अगर डिवाइस में प्राइमरी बाहरी स्टोरेज के लिए रिमूवेबल मीडिया का इस्तेमाल किया जाता है, तो डिवाइस में एक से ज़्यादा उपयोगकर्ताओं के लिए फ़ाइल शेयर करने की सुविधा चालू की जा सकती है. हालांकि, ऐसा नहीं करना चाहिए.

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

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

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

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

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

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

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

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

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

डिवाइस पर लागू होने वाली SELinux नीति, अपस्ट्रीम Android Open Source Project के system/sepolicy फ़ोल्डर में दी गई डिफ़ॉल्ट नीति के मुताबिक होनी चाहिए. साथ ही, डिवाइस के हिसाब से कॉन्फ़िगरेशन के लिए, इस नीति में सिर्फ़ बदलाव किया जाना चाहिए. डिवाइस में लागू किए गए बदलाव, Android ओपन सोर्स प्रोजेक्ट के साथ काम करने चाहिए.

डिवाइसों में, कर्नेल ऐप्लिकेशन सैंडबॉक्सिंग का तरीका लागू करना ज़रूरी है. इससे मल्टी-थ्रेड वाले प्रोग्राम से, कॉन्फ़िगर की जा सकने वाली नीति का इस्तेमाल करके, सिस्टम कॉल को फ़िल्टर किया जा सकता है. अपस्ट्रीम Android Open Source Project, source.android.com के कर्नेल कॉन्फ़िगरेशन सेक्शन में बताए गए तरीके से, थ्रेडग्रुप सिंक्रोनाइज़ेशन (TSYNC) के साथ seccomp-BPF को चालू करके इस ज़रूरी शर्त को पूरा करता है.

9.8. निजता

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

अगर डिवाइस में कोई ऐसा तरीका लागू किया गया है जो डिफ़ॉल्ट रूप से नेटवर्क डेटा ट्रैफ़िक को किसी प्रॉक्सी सर्वर या वीपीएन गेटवे से रूट करता है (उदाहरण के लिए, android.permission.CONTROL_VPN की अनुमति मिलने पर वीपीएन सेवा को पहले से लोड करना), तो डिवाइस में उस तरीके को चालू करने से पहले, उपयोगकर्ता की सहमति लेना ज़रूरी है. ऐसा तब तक करना होगा, जब तक कि DevicePolicyManager.setAlwaysOnVpnPackage() के ज़रिए डिवाइस नीति नियंत्रक ने वीपीएन को चालू न कर दिया हो. इस मामले में, उपयोगकर्ता को अलग से सहमति देने की ज़रूरत नहीं है. हालांकि, उसे इसकी सूचना देना ज़रूरी है.

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

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

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

9.9. डेटा स्टोरेज एन्क्रिप्शन

अगर डिवाइस पर, सेक्शन 9.11.1 में बताई गई सुरक्षित लॉक स्क्रीन की सुविधा काम करती है, तो डिवाइस में ऐप्लिकेशन के निजी डेटा (/data partition) के साथ-साथ, ऐप्लिकेशन के शेयर किए गए स्टोरेज पार्टिशन (/sdcard partition) का डेटा स्टोरेज एन्क्रिप्ट (सुरक्षित) करने की सुविधा होनी चाहिए. हालांकि, यह ज़रूरी है कि शेयर किया गया स्टोरेज पार्टिशन, डिवाइस का हमेशा मौजूद रहने वाला और हटाया नहीं जा सकने वाला हिस्सा हो.

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

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

9.9.1. डायरेक्ट बूट

सभी डिवाइसों पर डायरेक्ट बूट मोड एपीआई लागू होने चाहिए. भले ही, वे स्टोरेज एन्क्रिप्शन की सुविधा के साथ काम न करते हों. खास तौर पर, LOCKED_BOOT_COMPLETED और ACTION_USER_UNLOCKED इंटेंट को अब भी ब्रॉडकास्ट किया जाना चाहिए, ताकि सीधे बूट की सुविधा वाले ऐप्लिकेशन को यह सिग्नल दिया जा सके कि डिवाइस एन्क्रिप्ट (DE) और क्रेडेंशियल एन्क्रिप्ट (CE) स्टोरेज की जगहें, उपयोगकर्ता के लिए उपलब्ध हैं.

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

एफ़बीई के साथ काम करने वाले डिवाइस:

• उपयोगकर्ता से क्रेडेंशियल मांगे बिना, डिवाइस को तुरंत चालू करना चाहिए. साथ ही, LOCKED_BOOT_COMPLETED मैसेज ब्रॉडकास्ट होने के बाद, Direct Boot की सुविधा वाले ऐप्लिकेशन को डिवाइस के एन्क्रिप्ट किए गए (DE) स्टोरेज को ऐक्सेस करने की अनुमति देनी चाहिए.
• उपयोगकर्ता के डिवाइस को अनलॉक करने के बाद ही, क्रेडेंशियल एन्क्रिप्ट (सीई) स्टोरेज को ऐक्सेस करने की अनुमति दें. इसके लिए, उपयोगकर्ता को अपने क्रेडेंशियल (जैसे, पासकोड, पिन, पैटर्न या फ़िंगरप्रिंट) डालने होंगे. इसके बाद, ACTION_USER_UNLOCKED मैसेज ब्रॉडकास्ट किया जाएगा. डिवाइस में लागू किए गए तरीके से, उपयोगकर्ता के दिए गए क्रेडेंशियल के बिना, सीई से सुरक्षित स्टोरेज को अनलॉक करने का कोई तरीका नहीं दिया जाना चाहिए.
• यह ज़रूरी है कि डिवाइस, वेरिफ़ाइड बूट मोड के साथ काम करे. साथ ही, यह भी पक्का करना ज़रूरी है कि डीई कुंजियां, क्रिप्टोग्राफ़िक तरीके से डिवाइस के हार्डवेयर रूट ऑफ़ ट्रस्ट से जुड़ी हों.
• यह ज़रूरी है कि XTS मोड में, 256-बिट की कुंजी का इस्तेमाल करके, फ़ाइल के कॉन्टेंट को एईएस से एन्क्रिप्ट किया जा सके.
• यह ज़रूरी है कि एईएस का इस्तेमाल करके, फ़ाइल के नाम को एन्क्रिप्ट करने की सुविधा हो. इसके लिए, CBC-CTS मोड में 256-बिट की कुंजी का इस्तेमाल किया जाना चाहिए.
• फ़ाइल के कॉन्टेंट और फ़ाइल के नाम को एन्क्रिप्ट (सुरक्षित) करने के लिए, अन्य सिफर, कुंजी की लंबाई, और मोड का इस्तेमाल किया जा सकता है. हालांकि, डिफ़ॉल्ट रूप से उन सिफर, कुंजी की लंबाई, और मोड का इस्तेमाल करना ज़रूरी है जिनका इस्तेमाल किया जा सकता है.
• पहले से लोड किए गए ज़रूरी ऐप्लिकेशन (जैसे, अलार्म, फ़ोन, मैसेंजर) को डायरेक्ट बूट के बारे में जानकारी देनी चाहिए.

सीई और डीई स्टोरेज एरिया को सुरक्षित रखने वाली कुंजियां:

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

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

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

पूरी ड्राइव को सुरक्षित रखने की सुविधा (FDE) के साथ काम करने वाले डिवाइस. एईएस का इस्तेमाल 128-बिट (या उससे ज़्यादा) की कुंजी के साथ करना चाहिए. साथ ही, स्टोरेज के लिए डिज़ाइन किए गए मोड का इस्तेमाल करना चाहिए. उदाहरण के लिए, AES-XTS, AES-CBC-ESSIV. एन्क्रिप्शन कुंजी को बिना एन्क्रिप्ट किए, कभी भी स्टोरेज में नहीं लिखा जाना चाहिए. एन्क्रिप्शन पासकोड का इस्तेमाल न होने पर, उसे एईएस एन्क्रिप्शन (सुरक्षित करने का तरीका) से एन्क्रिप्ट (सुरक्षित) किया जाना चाहिए. इसके लिए, स्लो स्ट्रेचिंग एल्गोरिदम (जैसे, PBKDF2 या स्क्रिप्ट) का इस्तेमाल करके, लॉक स्क्रीन के क्रेडेंशियल को स्ट्रेच किया जाना चाहिए. अगर उपयोगकर्ता ने लॉक स्क्रीन के क्रेडेंशियल नहीं दिए हैं या एन्क्रिप्शन के लिए पासवर्ड का इस्तेमाल करने की सुविधा बंद की है, तो सिस्टम को एन्क्रिप्शन पासकोड को रैप करने के लिए, डिफ़ॉल्ट पासवर्ड का इस्तेमाल करना चाहिए. अगर डिवाइस में हार्डवेयर की मदद से सुरक्षित कीवर्ड स्टोर करने की सुविधा है, तो पासवर्ड स्ट्रेचिंग एल्गोरिदम को क्रिप्टोग्राफ़िक तरीके से उस कीवर्ड स्टोर से बंधा होना चाहिए. एन्क्रिप्शन पासकोड को डिवाइस से बाहर नहीं भेजा जाना चाहिए. भले ही, उसे उपयोगकर्ता के पासवर्ड और/या हार्डवेयर बाउंड पासकोड से रैप किया गया हो. अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट, Linux कर्नेल की dm-crypt सुविधा के आधार पर, इस सुविधा को लागू करने का सबसे सही तरीका उपलब्ध कराता है.

9.10. डिवाइस इंटिग्रिटी

नीचे दी गई ज़रूरी शर्तों से यह पक्का होता है कि डिवाइस की सुरक्षा की स्थिति साफ़ तौर पर दिखे.

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

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

• प्लैटफ़ॉर्म की सुविधा वाले फ़्लैग android.software.verified_boot का एलान करें.
• हर बूट सीक्वेंस पर पुष्टि करें.
• पुष्टि करने के लिए, सबसे पहले उस हार्डवेयर कुंजी से शुरुआत करें जिस पर भरोसा किया जाता है. इसके बाद, सिस्टम के सभी पार्टीशन की पुष्टि करें.
• अगले चरण में कोड को लागू करने से पहले, पुष्टि के हर चरण को लागू करें, ताकि अगले चरण में सभी बाइट की पूरी सुरक्षा और पुष्टि की जा सके.
• पुष्टि करने के लिए, ऐसे एल्गोरिदम का इस्तेमाल करें जो हैशिंग एल्गोरिदम (SHA-256) और सार्वजनिक कुंजी के साइज़ (RSA-2048) के लिए, एनआईएसटी के मौजूदा सुझावों के मुताबिक हों.
• सिस्टम की पुष्टि न होने पर, डिवाइस को बूट होने की अनुमति नहीं दी जानी चाहिए. हालांकि, अगर उपयोगकर्ता बूट करने की कोशिश करने की सहमति देता है, तो ऐसे में पुष्टि नहीं किए गए स्टोरेज ब्लॉक के डेटा का इस्तेमाल नहीं किया जाना चाहिए.
• डिवाइस पर पुष्टि किए गए पार्टीशन में तब तक बदलाव नहीं किया जाना चाहिए, जब तक उपयोगकर्ता ने साफ़ तौर पर बूट लोडर को अनलॉक नहीं किया है.

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

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

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

9.11. कुंजियां और क्रेडेंशियल

Android Keystore System की मदद से, ऐप्लिकेशन डेवलपर किसी कंटेनर में क्रिप्टोग्राफ़िक पासकोड सेव कर सकते हैं. साथ ही, KeyChain API या Keystore API की मदद से, क्रिप्टोग्राफ़िक ऑपरेशन में उनका इस्तेमाल कर सकते हैं.

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

• जनरेट की जा सकने वाली कुंजियों की संख्या को सीमित नहीं करना चाहिए. साथ ही, कम से कम 8,192 कुंजियों को इंपोर्ट करने की अनुमति होनी चाहिए.
• लॉक स्क्रीन की पुष्टि करने की सुविधा में, कोशिशों की दर को सीमित करना ज़रूरी है. साथ ही, इसमें एक्सपोनेंशियल बैकऑफ़ एल्गोरिदम होना चाहिए. 150 बार कोशिश करने के बाद, हर बार कम से कम 24 घंटे इंतज़ार करना ज़रूरी है.
• अगर डिवाइस पर सुरक्षित लॉक स्क्रीन की सुविधा काम करती है, तो उसे सुरक्षित हार्डवेयर की मदद से पासकी स्टोर का बैक अप लेना होगा. साथ ही, उसे इन ज़रूरी शर्तों को पूरा करना होगा:
  • Android Keystore सिस्टम के साथ काम करने वाले एल्गोरिदम के साथ सही तरीके से काम करने के लिए, इसमें आरएसए, एईएस, ईसीडीएसए, और एचएमएसी क्रिप्टोग्राफ़िक एल्गोरिदम और MD5, SHA1, SHA-2 फ़ैमिली हैश फ़ंक्शन के हार्डवेयर के साथ काम करने वाले वर्शन होने चाहिए.
  • यह ज़रूरी है कि सुरक्षित हार्डवेयर में लॉक स्क्रीन की पुष्टि की जाए. पुष्टि होने के बाद ही, पुष्टि करने के लिए इस्तेमाल की जाने वाली कुंजियों का इस्तेमाल करने की अनुमति दी जानी चाहिए. अपस्ट्रीम Android Open Source Project, Gatekeeper Hardware Abstraction Layer (HAL) उपलब्ध कराता है. इसका इस्तेमाल, इस ज़रूरी शर्त को पूरा करने के लिए किया जा सकता है.

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

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

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

• अगर पुष्टि करने का तरीका किसी ऐसे पासवर्ड पर आधारित है जो पहले से ही किसी को पता है, तो उसे सुरक्षित लॉक स्क्रीन के तौर पर तब तक नहीं माना जाना चाहिए, जब तक वह इन सभी शर्तों को पूरा न करता हो:
  • इनपुट की कम से कम अनुमति वाली लंबाई का एन्ट्रापी, 10 बिट से ज़्यादा होना चाहिए.
  • सभी संभावित इनपुट की मैक्सिमम एन्ट्रापी 18 बिट से ज़्यादा होनी चाहिए.
  • यह पुष्टि करने के उन सभी मौजूदा तरीकों (पिन, पैटर्न, पासवर्ड) की जगह नहीं ले सकता जिन्हें AOSP में लागू और उपलब्ध कराया गया है.
  • जब डिवाइस नीति नियंत्रक (डीपीसी) ऐप्लिकेशन ने DevicePolicyManager.setPasswordQuality() तरीके से पासवर्ड की क्वालिटी से जुड़ी नीति को सेट किया हो, तो इसे बंद करना ज़रूरी है. साथ ही, PASSWORD_QUALITY_SOMETHING से ज़्यादा पाबंदी वाले क्वालिटी कॉन्स्टेंट का इस्तेमाल किया जाना चाहिए.
• अगर पुष्टि करने का तरीका, किसी फ़िज़िकल टोकन या जगह की जानकारी पर आधारित है, तो उसे सुरक्षित लॉक स्क्रीन के तौर पर तब तक नहीं माना जाना चाहिए, जब तक वह इन सभी ज़रूरी शर्तों को पूरा नहीं करता:
  • पुष्टि करने के किसी मुख्य तरीके का इस्तेमाल करने के लिए, इसमें फ़ॉल-बैक मैकेनिज्म होना चाहिए. यह तरीका, किसी ऐसे गुप्त कोड पर आधारित होना चाहिए जिसकी जानकारी सभी के पास हो. साथ ही, यह सुरक्षित लॉक स्क्रीन के तौर पर इस्तेमाल करने की ज़रूरी शर्तों को पूरा करता हो.
  • इसे बंद करना ज़रूरी है. साथ ही, डिवाइस नीति नियंत्रक (डीपीसी) ऐप्लिकेशन ने DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) या DevicePolicyManager.setPasswordQuality() तरीके से नीति सेट की हो, तो ही स्क्रीन अनलॉक करने के लिए मुख्य पुष्टि की अनुमति दें. साथ ही, PASSWORD_QUALITY_UNSPECIFIED से ज़्यादा पाबंदी वाला क्वालिटी कॉन्स्टेंट इस्तेमाल करें.
• अगर पुष्टि करने का तरीका बायोमेट्रिक है, तो उसे सुरक्षित लॉक स्क्रीन के तौर पर तब तक नहीं माना जाना चाहिए, जब तक वह इन सभी ज़रूरी शर्तों को पूरा नहीं करता:
  • पुष्टि करने के किसी मुख्य तरीके का इस्तेमाल करने के लिए, इसमें फ़ॉल-बैक मैकेनिज्म होना चाहिए. यह तरीका, किसी ऐसे गुप्त कोड पर आधारित होना चाहिए जिसकी जानकारी सभी के पास हो. साथ ही, यह सुरक्षित लॉक स्क्रीन के तौर पर इस्तेमाल करने की ज़रूरी शर्तों को पूरा करता हो.
  • यह सुविधा बंद होनी चाहिए. साथ ही, डिवाइस की स्क्रीन को सिर्फ़ मुख्य पुष्टि करने की सुविधा से अनलॉक किया जा सकता है. ऐसा तब ही किया जा सकता है, जब डिवाइस नीति नियंत्रक (डीपीसी) ऐप्लिकेशन ने DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_FINGERPRINT) मैथड को कॉल करके, keguard सुविधा की नीति सेट की हो.
  • यह ज़रूरी है कि फ़ेस अनलॉक की सुविधा के लिए, गलत पहचान की दर उतनी ही हो या उससे ज़्यादा हो जितनी फ़िंगरप्रिंट सेंसर के लिए ज़रूरी है. इस बारे में, सेक्शन 7.3.10 में बताया गया है. अगर ऐसा नहीं है, तो फ़ेस अनलॉक की सुविधा बंद कर दी जानी चाहिए. साथ ही, डिवाइस नीति कंट्रोलर (डीपीसी) ऐप्लिकेशन के DevicePolicyManager.setPasswordQuality() तरीके से पासवर्ड की क्वालिटी से जुड़ी नीति सेट करने पर, स्क्रीन को अनलॉक करने के लिए सिर्फ़ मुख्य पुष्टि की अनुमति दी जानी चाहिए. हालांकि, इस नीति में PASSWORD_QUALITY_BIOMETRIC_WEAK से ज़्यादा पाबंदी वाली क्वालिटी का कॉन्स्टेंट इस्तेमाल किया जाना चाहिए.
• अगर पुष्टि करने के तरीके को सुरक्षित लॉक स्क्रीन के तौर पर नहीं माना जा सकता, तो:
  • KeyguardManager.isKeyguardSecure() और KeyguardManager.isDeviceSecure(), दोनों तरीकों के लिए false दिखाना ज़रूरी है.
  • जब डिवाइस नीति नियंत्रक (डीपीसी) ऐप्लिकेशन ने DevicePolicyManager.setPasswordQuality() तरीके से पासवर्ड की क्वालिटी से जुड़ी नीति को सेट किया हो, तो इसे बंद करना ज़रूरी है. साथ ही, PASSWORD_QUALITY_UNSPECIFIED से ज़्यादा पाबंदी वाले क्वालिटी कॉन्स्टेंट का इस्तेमाल किया जाना चाहिए.
  • DevicePolicyManager.setPasswordExpirationTimeout() से सेट किए गए, पासवर्ड की समयसीमा खत्म होने के टाइमर को रीसेट नहीं करना चाहिए.
  • अगर ऐप्लिकेशन ने KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true) को कॉल किया है, तो पासकोड के ऐक्सेस की पुष्टि नहीं करनी चाहिए).
• अगर पुष्टि करने का तरीका, फ़िज़िकल टोकन, जगह की जानकारी या बायोमेट्रिक्स पर आधारित है और सेक्शन 7.3.10 में बताए गए फ़िंगरप्रिंट सेंसर के लिए ज़रूरी दर से ज़्यादा गलत स्वीकार करने की दर है, तो:
  • DevicePolicyManager.setPasswordExpirationTimeout() से सेट किए गए, पासवर्ड की समयसीमा खत्म होने के टाइमर को रीसेट नहीं करना चाहिए.
  • अगर ऐप्लिकेशन ने KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true) को कॉल किया है, तो पासकोड के ऐक्सेस की पुष्टि नहीं करनी चाहिए.

9.12. डेटा हटाना

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

• सिस्टम इमेज
• सिस्टम इमेज के लिए ज़रूरी ऑपरेटिंग सिस्टम की फ़ाइलें

उपयोगकर्ता का बनाया गया सारा डेटा मिटाना ज़रूरी है. यह डेटा मिटाने के लिए, उद्योग के मानकों के मुताबिक होना चाहिए. जैसे, NIST SP800-88. सेक्शन 3.9 डिवाइस एडमिनिस्ट्रेशन में बताए गए wipeData() एपीआई (Android डिवाइस एडमिनिस्ट्रेशन एपीआई का हिस्सा) को लागू करने के लिए, इसका इस्तेमाल करना ज़रूरी है.

डिवाइसों पर, डेटा को तेज़ी से मिटाने की सुविधा मिल सकती है. इससे डेटा को लॉजिकल तरीके से मिटाया जाता है.

9.13. सेफ़ बूट मोड

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

हमारा सुझाव है कि Android डिवाइसों पर सेफ़ बूट मोड लागू करें और इन ज़रूरी शर्तों को पूरा करें:

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

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

• डिवाइस में सुरक्षित मोड लागू करने पर, उपयोगकर्ता को तीसरे पक्ष के किसी भी ऐप्लिकेशन को अनइंस्टॉल करने की सुविधा मिलनी चाहिए.

9.14. वाहन के सिस्टम को आइसोलेट करना

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

निजी सेक्शन में हुए बदलावों की खास जानकारी के लिए:

1. शुरुआती जानकारी
2. डिवाइस टाइप
3. सॉफ़्टवेयर
4. ऐप्लिकेशन की पैकेजिंग
5. मल्टीमीडिया
6. डेवलपर टूल और विकल्प
7. हार्डवेयर के साथ काम करना
8. परफ़ॉर्मेंस और पावर
9. सुरक्षा मॉडल
10. सॉफ़्टवेयर के साथ काम करने की जांच
11. अपडेट किया जा सकने वाला सॉफ़्टवेयर
12. दस्तावेज़ में हुए बदलावों का लॉग
13. हमसे संपर्क करें

12.1. बदलावों का लॉग देखने के बारे में सलाह

बदलावों को इस तरह मार्क किया जाता है:

• सीडीडी
  काम करने की ज़रूरी शर्तों में बड़े बदलाव.

• Docs
  कॉस्मेटिक या बिल्ड से जुड़े बदलाव.

बेहतर तरीके से देखने के लिए, अपने बदलावों की जानकारी वाले यूआरएल में pretty=full और no-merges यूआरएल पैरामीटर जोड़ें.

13. हमसे संपर्क करें

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