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

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

1. परिचय

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ऊपर बताए गए किसी भी डिवाइस टाइप में न आने वाले सभी Android डिवाइसों को, Android 5.1 के साथ काम करने के लिए, इस दस्तावेज़ में बताई गई सभी ज़रूरी शर्तों को पूरा करना होगा. ऐसा तब तक करना होगा, जब तक कि ज़रूरी शर्तों के बारे में साफ़ तौर पर यह नहीं बताया गया हो कि वे सिर्फ़ ऊपर बताए गए किसी खास 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.7. यूएसबी	चाहिए			चाहिए	चाहिए
आउटपुट	स्पीकर और/या ऑडियो आउटपुट पोर्ट	7.8.2. ऑडियो आउटपुट	ज़रूरी है	ज़रूरी है		ज़रूरी है	ज़रूरी है

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

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

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

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

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

3.2. Soft API Compatibility

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

3.2.1. अनुमतियां

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

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

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

पैरामीटर	जानकारी
VERSION.RELEASE	फ़िलहाल चल रहे Android सिस्टम का वर्शन, इंसान के पढ़ने लायक फ़ॉर्मैट में. इस फ़ील्ड में, [संसाधन, 8] में दी गई स्ट्रिंग वैल्यू में से कोई एक वैल्यू होनी चाहिए.
VERSION.SDK	फ़िलहाल चल रहे Android सिस्टम का वर्शन, तीसरे पक्ष के ऐप्लिकेशन कोड के लिए ऐक्सेस किए जा सकने वाले फ़ॉर्मैट में. Android 5.1 के लिए, इस फ़ील्ड में पूर्णांक की वैल्यू 22 होनी चाहिए.
VERSION.SDK_INT	फ़िलहाल चल रहे Android सिस्टम का वर्शन, तीसरे पक्ष के ऐप्लिकेशन कोड के लिए ऐक्सेस किए जा सकने वाले फ़ॉर्मैट में. Android 5.1 के लिए, इस फ़ील्ड में पूर्णांक की वैल्यू 22 होनी चाहिए.
VERSION.INCREMENTAL	डिवाइस लागू करने वाले व्यक्ति की चुनी गई वैल्यू, जो फ़िलहाल चल रहे Android सिस्टम के खास बिल्ड को, इंसान के पढ़ने लायक फ़ॉर्मैट में दिखाती है. इस वैल्यू का इस्तेमाल, असली उपयोगकर्ताओं के लिए उपलब्ध कराए गए अलग-अलग बिल्ड के लिए दोबारा नहीं किया जाना चाहिए. इस फ़ील्ड का आम तौर पर इस्तेमाल, यह बताने के लिए किया जाता है कि बिल्ड जनरेट करने के लिए, किस बिल्ड नंबर या सोर्स-कंट्रोल में बदलाव करने वाले आइडेंटिफ़ायर का इस्तेमाल किया गया था. इस फ़ील्ड के लिए, किसी खास फ़ॉर्मैट की ज़रूरत नहीं होती. हालांकि, यह शर्त ज़रूरी है कि यह शून्य या खाली स्ट्रिंग ("") न हो.
बोर्ड	डिवाइस लागू करने वाले व्यक्ति की चुनी गई वैल्यू, जो डिवाइस में इस्तेमाल किए गए खास इंटरनल हार्डवेयर की पहचान करती है. यह वैल्यू, इंसान के पढ़ने लायक फ़ॉर्मैट में होती है. इस फ़ील्ड का इस्तेमाल, डिवाइस को पावर देने वाले बोर्ड के खास वर्शन की जानकारी देने के लिए किया जा सकता है. इस फ़ील्ड की वैल्यू को सात बिट के 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 देखें. नेटिव एपीआई के साथ काम करना.
डिवाइस	डिवाइस लागू करने वाले व्यक्ति या कंपनी की चुनी गई वैल्यू. इसमें डिवाइस के हार्डवेयर की सुविधाओं और इंडस्ट्रियल डिज़ाइन के कॉन्फ़िगरेशन की पहचान करने वाला डेवलपमेंट का नाम या कोड नेम होता है. इस फ़ील्ड की वैल्यू को सात बिट के ASCII के तौर पर एन्कोड किया जा सकता है और यह रेगुलर एक्सप्रेशन “^[a-zA-Z0-9_-]+$” से मेल खानी चाहिए.
फ़िंगरप्रिंट	यह एक स्ट्रिंग है, जो इस बिल्ड की खास तौर पर पहचान करती है. यह पढ़ने में आसान होना चाहिए. यह इस टेंप्लेट के मुताबिक होना चाहिए: $(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) उदाहरण के लिए: acme/myproduct/mydevice:5.1/LMYXX/3359:userdebug/test-keys फ़िंगरप्रिंट में खाली सफ़ेद जगह वाले वर्ण नहीं होने चाहिए. अगर ऊपर दिए गए टेंप्लेट में शामिल अन्य फ़ील्ड में खाली जगह वाले वर्ण हैं, तो उन्हें बिल्ड फ़िंगरप्रिंट में किसी दूसरे वर्ण से बदलना ज़रूरी है. जैसे, अंडरस्कोर ("_") वर्ण. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है.
हार्डवेयर	हार्डवेयर का नाम (कर्नल कमांड लाइन या /proc से). इसे किसी व्यक्ति के लिए आसानी से पढ़ा जा सकने वाला होना चाहिए. इस फ़ील्ड की वैल्यू को सात बिट के 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	हार्डवेयर का सीरियल नंबर, जो उपलब्ध होना चाहिए. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है. साथ ही, यह वैल्यू रेगुलर एक्सप्रेशन “^([a-zA-Z0-9]{6,20})$” से मैच करनी चाहिए.
टैग	डिवाइस लागू करने वाले व्यक्ति के चुने गए टैग की सूची, जिसे कॉमा लगाकर अलग किया गया है. इससे, बिल्ड को और बेहतर तरीके से पहचाना जा सकता है. इस फ़ील्ड में, Android प्लैटफ़ॉर्म के साइनिंग कॉन्फ़िगरेशन की तीन सामान्य वैल्यू में से कोई एक वैल्यू होनी चाहिए: रिलीज़-की, डेवलपर-की, और टेस्ट-की.
समय	यह वैल्यू, बिल्ड होने के समय का टाइमस्टैंप दिखाती है.
वाई-फ़ाई के टाइप के बारे में जानकारी	डिवाइस इंप्लीमेंटर की चुनी गई वैल्यू, जो बिल्ड के रनटाइम कॉन्फ़िगरेशन के बारे में बताती है. इस फ़ील्ड में, Android के तीन सामान्य रनटाइम कॉन्फ़िगरेशन में से किसी एक की वैल्यू होनी चाहिए: user, userdebug या eng.
उपयोगकर्ता	उस उपयोगकर्ता (या ऑटोमेटेड उपयोगकर्ता) का नाम या यूज़र आईडी जिसने बिल्ड जनरेट किया. इस फ़ील्ड के फ़ॉर्मैट के लिए कोई ज़रूरी शर्त नहीं है. हालांकि, यह ज़रूरी है कि यह शून्य या खाली स्ट्रिंग ("") न हो.

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

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

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

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 [संसाधन, 10] दिखता है, तो होम स्क्रीन पर डिफ़ॉल्ट ऐप्लिकेशन सेटिंग मेन्यू दिखाने के लिए, android.settings.HOME_SETTINGS इंटेंट का पालन करना ज़रूरी है
• डिफ़ॉल्ट एसएमएस ऐप्लिकेशन बदलने के लिए डायलॉग दिखाने के लिए, ऐसा सेटिंग मेन्यू उपलब्ध कराना ज़रूरी है जो डिवाइस में लागू होने की जानकारी देने वाली सेवा के तौर पर काम करने वाले डिवाइस के लिए, Android.hardware.telephony [संसाधन, 9] की रिपोर्ट के आधार पर, android.provider.Telephony.ACTION_CHANGE_DEFAULT इंटेंट को कॉल करेगा
• टैप करके पैसे चुकाने की सुविधा के लिए, डिफ़ॉल्ट ऐप्लिकेशन सेटिंग मेन्यू दिखाने के लिए, android.settings.NFC_PAYMENT_SETTINGS इंटेंट का पालन करना ज़रूरी है. ऐसा तब करना होगा, जब डिवाइस में इस सुविधा के लागू होने की जानकारी देने वाली रिपोर्ट में, android.hardware.nfc.hce [संसाधन, 10] दिखे

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

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 के सबसे नए वर्शन में मौजूद हैं. इनके बारे में ज़्यादा जानने के लिए, docs/directory में “NDK प्रोग्रामर गाइड | एबीआई मैनेजमेंट” देखें
• इसे अपस्ट्रीम Android Open Source Project में मौजूद सोर्स कोड और हेडर फ़ाइलों का इस्तेमाल करके बनाया जाना चाहिए

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

• libc (C लाइब्रेरी)
• libm (मैथ लाइब्रेरी)
• C++ के लिए कम से कम सहायता
• JNI इंटरफ़ेस
• liblog (Android लॉगिंग)
• libz (Zlib कंप्रेशन)
• libdl (डाइनैमिक लिंकर)
• libGLESv1_CM.so (OpenGL ES 1.x)
• libGLESv2.so (OpenGL ES 2.0)
• libGLESv3.so (OpenGL ES 3.x)
• libEGL.so (नेटिव OpenGL सरफ़ेस मैनेजमेंट)
• libjnigraphics.so
• libOpenSLES.so (OpenSL ES 1.0.1 ऑडियो की सुविधा)
• libOpenMAXAL.so (OpenMAX AL 1.0.1 के साथ काम करता है)
• libandroid.so (नेटिव Android गतिविधि के लिए सहायता)
• libmediandk.so (नेटिव मीडिया एपीआई के लिए सहायता)
• OpenGL के लिए सहायता, जैसा कि नीचे बताया गया है

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

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

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

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 आर्किटेक्चर के बारे में बताता है (उदाहरण के लिए, ARMv8 डिवाइसों के लिए "8")

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

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

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

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

• डिवाइस के android.webkit.WebView को लागू करने के लिए, यह ज़रूरी है कि वे Android 5.1 के लिए, अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट से मिले Chromium के बिल्ड पर आधारित हों. इस बिल्ड में, वेबव्यू [संसाधन, 13] के लिए, फ़ंक्शन और सुरक्षा से जुड़े सुधारों का एक खास सेट शामिल है.
• वेबव्यू की ओर से रिपोर्ट की गई उपयोगकर्ता एजेंट स्ट्रिंग, इस फ़ॉर्मैट में होनी चाहिए:

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

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

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

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

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

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

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

• ऐप्लिकेशन कैश/ऑफ़लाइन ऑपरेशन [रिसॉर्स, 15]
• <video> टैग [संसाधन, 16]
• जगह/जियोलोकेशन [संसाधन, 17]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

स्क्रीन लेआउट	स्क्रीन की सघनता	ऐप्लिकेशन के लिए कम से कम मेमोरी
छोटा/सामान्य	120 डीपीआई (ldpi)	32 एमबी
	160 डीपीआई (एमडीपीआई)
	213 डीपीआई (tvdpi)	48 एमबी
	240 डीपीआई (एचडीपीआई)
	280 डीपीआई (280dpi)
	320 डीपीआई (xhdpi)	80 एमबी
	400 डीपीआई (400dpi)	96 एमबी
	480 डीपीआई (xxhdpi)	128 एमबी
	560 डीपीआई (560dpi)	192 एमबी
	640 डीपीआई (xxxhdpi)	256 एमबी
बड़ा	120 डीपीआई (ldpi)	32 एमबी
	160 डीपीआई (एमडीपीआई)	48 एमबी
	213 डीपीआई (tvdpi)	80 एमबी
	240 डीपीआई (एचडीपीआई)
	280 डीपीआई (280dpi)	96 एमबी
	320 डीपीआई (xhdpi)	128 एमबी
	400 डीपीआई (400dpi)	192 एमबी
	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 एमबी
	400 डीपीआई (400dpi)	288 एमबी
	480 डीपीआई (xxhdpi)	384 एमबी
	560 डीपीआई (560dpi)	576 एमबी
	640 डीपीआई (xxxhdpi)	768 एमबी

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

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

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

3.8.2. विजेट

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

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

3.8.3. सूचनाएं

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

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

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

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

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

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

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

3.8.4. खोजें

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

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

3.8.5. टोस्ट

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

3.8.6. थीम

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.11. स्वप्न

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

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

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

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

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

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.9. डिवाइस प्रबंधन

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

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

3.10. सुलभता

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

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

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

इसके अलावा, डिवाइस पर सुलभता सेवा को लागू करना ज़रूरी है. साथ ही, डिवाइस के सेटअप के दौरान, उपयोगकर्ताओं को सुलभता सेवा को चालू करने का तरीका भी देना चाहिए. Eyes Free प्रोजेक्ट [संसाधन, 44] से, सुलभता सेवा को ओपन सोर्स के तौर पर लागू करने की सुविधा मिलती है.

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

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

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

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

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

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

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

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

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

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

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

डिवाइसों पर लागू होने वाले .apk [संसाधन, 48], Android मेनिफ़ेस्ट [संसाधन, 49], Dalvik बाइटकोड [संसाधन, 20] या RenderScript बाइटकोड फ़ॉर्मैट को इस तरह से बड़ा नहीं किया जाना चाहिए कि उन फ़ाइलों को काम करने वाले अन्य डिवाइसों पर सही तरीके से इंस्टॉल और चलाने में समस्या आए.

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

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

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

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

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

फ़ॉर्मैट/कोडेक	एन्कोडर	डिकोडर	जानकारी	इस्तेमाल किए जा सकने वाले फ़ाइल टाइप/कंटेनर फ़ॉर्मैट
MPEG-4 AAC प्रोफ़ाइल (AAC LC)	ज़रूरी है1	ज़रूरी है	मोनो/स्टीरियो/5.0/5.12 कॉन्टेंट के लिए, 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.12 कॉन्टेंट के लिए, 16 से 48 किलोहर्ट्ज़ के स्टैंडर्ड सैंपलिंग रेट के साथ काम करता है.
MPEG-4 HE AACv2 प्रोफ़ाइल (बेहतर AAC+)		ज़रूरी है	मोनो/स्टीरियो/5.0/5.12 कॉन्टेंट के लिए, 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-बिट लीनियर पीसीएम (हार्डवेयर की सीमा तक रेट). डिवाइसों में, रॉ पीसीएम रिकॉर्डिंग के लिए 8000, 11025, 16000, और 44100 हर्ट्ज़ की फ़्रीक्वेंसी पर सैंपलिंग रेट की सुविधा होनी चाहिए.	WAVE (.wav)
Opus		ज़रूरी है (Android 5.0 और इसके बाद के वर्शन)		Matroska (.mkv)

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

2 सिर्फ़ 5.0/5.1 ऑडियो को डाउनमिक्स करना ज़रूरी है. दो से ज़्यादा चैनलों को रिकॉर्ड या रेंडर करना ज़रूरी नहीं है.

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

4 यह उन डिवाइसों के लिए ज़रूरी है जिनमें android.hardware.microphone की सुविधा लागू की गई है. इनमें Android Watch डिवाइस भी शामिल हैं.

5.1.2. इमेज कोडेक

फ़ॉर्मैट/कोडेक	एन्कोडर	डिकोडर	जानकारी	इस्तेमाल किए जा सकने वाले फ़ाइल टाइप/कंटेनर फ़ॉर्मैट
JPEG	ज़रूरी है	ज़रूरी है	बेस+प्रोग्रेसिव	JPEG (.jpg)
GIF		ज़रूरी है		GIF (.gif)
PNG	ज़रूरी है	ज़रूरी है		PNG (.png)
BMP		ज़रूरी है		BMP (.bmp)
WebP	ज़रूरी है	ज़रूरी है		WebP (.webp)

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

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

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

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

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

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

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

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

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

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

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

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

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

	एसडी (कम क्वालिटी)	एसडी (अच्छी क्वालिटी)	एचडी 720 पिक्सल1	एचडी 1080p1
वीडियो रिज़ॉल्यूशन	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 कोडेक के लिए होनी चाहिए.

H.264 डिकोडर वाले Android डिवाइसों में, बेसलाइन प्रोफ़ाइल लेवल 3 और यहां दी गई एसडी वीडियो डिकोडिंग प्रोफ़ाइलों के साथ काम करना ज़रूरी है. साथ ही, इन डिवाइसों में एचडी डिकोडिंग प्रोफ़ाइलों के साथ काम करना चाहिए. Android Television डिवाइसों में, हाई प्रोफ़ाइल लेवल 4.2 और एचडी 1080 पिक्सल डिकोडिंग प्रोफ़ाइल काम करनी चाहिए.

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

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

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

सेक्शन 5.1.3 में बताए गए तरीके से VP8 कोडेक का इस्तेमाल करने वाले Android डिवाइसों में, एसडी वीडियो को डिकोड करने वाली इन प्रोफ़ाइलों का इस्तेमाल किया जाना चाहिए. साथ ही, इनमें एचडी वीडियो को डिकोड करने वाली प्रोफ़ाइलों का इस्तेमाल किया जा सकता है. Android TV डिवाइसों पर, एचडी 1080p डिकोडिंग प्रोफ़ाइल काम करनी चाहिए.

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

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

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

सेक्शन 5.1.3 में बताए गए VP9 कोडेक के साथ काम करने वाले Android डिवाइसों में, यहां दी गई एसडी वीडियो डिकोडिंग प्रोफ़ाइलों के साथ काम करने की सुविधा होनी चाहिए. साथ ही, इनमें एचडी डिकोडिंग प्रोफ़ाइलों के साथ काम करने की सुविधा भी होनी चाहिए. हमारा सुझाव है कि Android Television डिवाइसों पर, एचडी 1080p डिकोडिंग प्रोफ़ाइल काम करे. साथ ही, इन डिवाइसों पर यूएचडी डिकोडिंग प्रोफ़ाइल भी काम करनी चाहिए. अगर यूएचडी वीडियो डिकोडिंग प्रोफ़ाइल काम करती है, तो यह 8-बिट कलर डेप्थ के साथ काम करनी चाहिए.

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

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

2 Android Television डिवाइस पर लागू करने के लिए, हमारा सुझाव है कि आप इसे तब इस्तेमाल करें, जब हार्डवेयर में इसकी सुविधा उपलब्ध हो.

सेक्शन 5.1.3 में बताए गए तरीके से H.265 कोडेक का इस्तेमाल करने वाले Android डिवाइसों में, मेन प्रोफ़ाइल लेवल 3 के मुख्य टीयर और यहां दी गई एसडी वीडियो डिकोडिंग प्रोफ़ाइलों के साथ-साथ एचडी डिकोडिंग प्रोफ़ाइलों का इस्तेमाल किया जाना चाहिए. Android TV डिवाइसों पर, Main10 लेवल 5 के मुख्य टीयर की प्रोफ़ाइल और यूएचडी डिकोडिंग प्रोफ़ाइल काम करनी चाहिए. हमारा सुझाव है कि Android TV डिवाइसों पर, एचडी 1080 पिक्सल डिकोडिंग प्रोफ़ाइल का इस्तेमाल किया जाए. अगर एचडी 1080 पिक्सल डिकोडिंग प्रोफ़ाइल काम करती है, तो यह ज़रूरी है कि वह मेन प्रोफ़ाइल लेवल 4.1 मेन टीयर के साथ काम करे

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

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

2 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
• चैनल: स्टीरियो

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

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

• डिवाइस में, फ़्रीक्वेंसी के हिसाब से ऐम्प्ल्यट्यूड में ज़्यादा उतार-चढ़ाव नहीं होना चाहिए: खास तौर पर, 100 हर्ट्ज़ से 4,000 हर्ट्ज़ तक, ±3 डीबी.
• ऑडियो इनपुट की संवेदनशीलता इस तरह से सेट की जानी चाहिए कि 1000 हर्ट्ज़ पर 90 डीबी साउंड पावर लेवल (एसपीएल) वाले सोर्स से, 16-बिट सैंपल के लिए आरएमएस 2500 मिल सके.
• पीसीएम ऐम्प्ल्यट्यूड लेवल, इनपुट एसपीएल में होने वाले बदलावों को कम से कम 30 डीबी के रेंज में, रैखिक तरीके से ट्रैक करते हैं. यह रेंज, माइक्रोफ़ोन पर 90 डीबी एसपीएल से -18 डीबी से लेकर +12 डीबी तक होती है.
• माइक्रोफ़ोन पर 90 dB SPL इनपुट लेवल पर, 1KHz के लिए कुल हार्मोनिक डिस्टॉर्शन 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, डिवाइस पर ऑडियो इफ़ेक्ट लागू करने के लिए एपीआई उपलब्ध कराता है [संसाधन, 52]. डिवाइस में लागू की गई सुविधाएं, जिनमें android.hardware.audio.output की सुविधा का एलान किया गया है:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• आरटीएसपी (आरटीपी, एसडीपी)
• एचटीटीपी या एचटीटीपीएस प्रोग्रेसिव स्ट्रीमिंग
• एचटीटीपी या एचटीटीपीएस लाइव स्ट्रीमिंग का ड्राफ़्ट प्रोटोकॉल, वर्शन 3 [संसाधन, 54]

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) और वायर्ड (एचडीएमआई) डिसप्ले के लिए, इस ज़रूरी शर्त को पूरा करने वाली सुविधा शामिल है.

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

6.1. डेवलपर टूल

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

• Android डीबग ब्रिज (adb) [संसाधन, 55]

डिवाइस में, Android SDK में बताए गए सभी adb फ़ंक्शन काम करने चाहिए. इनमें dumpsys [Resources, 56] भी शामिल है. डिवाइस-साइड adb डेमन, डिफ़ॉल्ट रूप से बंद होना चाहिए. साथ ही, Android Debug Bridge को चालू करने के लिए, उपयोगकर्ता के ऐक्सेस वाला कोई तरीका होना चाहिए. अगर किसी डिवाइस में यूएसबी पेरिफ़रल मोड लागू नहीं किया गया है, तो उसे लोकल-एरिया नेटवर्क (जैसे, ईथरनेट या 802.11) के ज़रिए Android Debug Bridge लागू करना होगा.

Android में सुरक्षित adb के लिए सहायता शामिल है. Secure adb, पुष्टि किए गए जाने-पहचाने होस्ट पर adb को चालू करता है. डिवाइस पर, सुरक्षित adb की सुविधा काम करनी चाहिए.

• Dalvik Debug Monitor Service (ddms) [संसाधन, 57]

डिवाइस पर लागू किए गए SDK टूल, Android SDK टूल में बताई गई सभी ddms सुविधाओं के साथ काम करने चाहिए. ddms, adb का इस्तेमाल करता है. इसलिए, ddms के लिए सहायता डिफ़ॉल्ट रूप से बंद होनी चाहिए. हालांकि, जब भी उपयोगकर्ता ऊपर बताए गए तरीके से Android Debug Bridge चालू करता है, तब ddms के लिए सहायता चालू होनी चाहिए.

• Monkey [संसाधन, 58]

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

• SysTrace [संसाधन, 59]

डिवाइस पर लागू किए गए टूल, 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 9 के लिए 32-बिट और 64-बिट, दोनों वर्शन में उपलब्ध होने चाहिए.

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

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

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

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

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

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

डिवाइस के लागू होने पर, एक ही बिल्ड फ़िंगरप्रिंट के लिए, android.content.pm.PackageManager क्लास पर getSystemAvailableFeatures() और hasSystemFeature(String) तरीकों की मदद से, हार्डवेयर कॉन्फ़िगरेशन की सटीक जानकारी लगातार रिपोर्ट की जानी चाहिए. [संसाधन, 53]

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

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

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

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

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

इसके अलावा,

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

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

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

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

स्क्रीन का आसपेक्ट रेशियो 1.3333 (4:3) से 1.86 (लगभग 16:9) के बीच होना चाहिए. हालांकि, Android Watch डिवाइसों का आसपेक्ट रेशियो 1.0 (1:1) हो सकता है, क्योंकि ऐसे डिवाइसों में, android.content.res.Configuration.uiMode के तौर पर UI_MODE_TYPE_WATCH का इस्तेमाल किया जाएगा.

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

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

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

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

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

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

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 का इस्तेमाल किया जाना चाहिए. हालांकि, ऐसा सिर्फ़ उन डिवाइसों पर किया जा सकता है जिन पर ये वर्शन काम करते हैं. डिवाइस पर लागू किए गए एपीआई को Android RenderScript के साथ भी काम करना चाहिए. इस बारे में ज़्यादा जानकारी, Android SDK टूल के दस्तावेज़ [संसाधन, 63] में दी गई है.

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

• मैनेज किए जा रहे एपीआई (जैसे, 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 के साथ काम करने की सुविधा है उनमें, मैनेज किए जा सकने वाले एपीआई के साथ-साथ, नेटिव C/C++ एपीआई के साथ काम करने की सुविधा भी होनी चाहिए. जिन डिवाइसों पर OpenGL ES 3.0 या 3.1 का इस्तेमाल किया जा सकता है उन पर, libGLESv2.so को OpenGL ES 2.0 फ़ंक्शन सिंबल के साथ-साथ, उनसे जुड़े फ़ंक्शन सिंबल भी एक्सपोर्ट करने होंगे.

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

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

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

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

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

इसके अलावा, डिवाइस के लागू होने की प्रोसेस, हार्डवेयर से तेज़ी लाने की सुविधा [संसाधन, 65] के लिए बने Android SDK दस्तावेज़ में बताए गए तरीके के मुताबिक होनी चाहिए.

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

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

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 टूल के दस्तावेज़ [संसाधन, 67] में बताया गया है.

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

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

7.2.1. कीबोर्ड

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Android, Assist action [Resources, 69] के साथ काम करता है. Android Watch डिवाइसों को छोड़कर, Android डिवाइसों पर ऐप्लिकेशन इस्तेमाल करते समय, उपयोगकर्ता के लिए Assist ऐक्शन को हर समय उपलब्ध कराना ज़रूरी है. 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 [Resources, 68] की वैल्यू बताना ज़रूरी है.

Android में कई तरह के टचस्क्रीन, टच पैड, और फ़ेक टच इनपुट डिवाइसों के साथ काम करने की सुविधा शामिल है. टचस्क्रीन वाले डिवाइसों पर लागू किए गए एलिमेंट, डिसप्ले [संसाधन, 70] से जुड़े होते हैं, ताकि उपयोगकर्ता को स्क्रीन पर मौजूद आइटम में सीधे तौर पर बदलाव करने का एहसास हो. उपयोगकर्ता सीधे तौर पर स्क्रीन को छू रहा है, इसलिए सिस्टम को, बदलाव किए जा रहे ऑब्जेक्ट के बारे में बताने के लिए किसी और सुविधा की ज़रूरत नहीं होती. इसके उलट, नकली टच इंटरफ़ेस, उपयोगकर्ता इनपुट सिस्टम उपलब्ध कराता है, जो टचस्क्रीन की सुविधाओं के सबसेट के बराबर होता है. उदाहरण के लिए, ऑन-स्क्रीन कर्सर को चलाने वाला माउस या रिमोट कंट्रोल, टच की सुविधा के करीब होता है. हालांकि, इसके लिए उपयोगकर्ता को पहले कर्सर को पॉइंट या फ़ोकस करना होता है और फिर क्लिक करना होता है. माउस, ट्रैकपैड, ज्यरो-आधारित एयर माउस, ज्यरो-पॉइंटर, जॉयस्टिक, और मल्टी-टच ट्रैकपैड जैसे कई इनपुट डिवाइसों पर, फ़ेक टच इंटरैक्शन की सुविधा काम कर सकती है. 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 की सटीक पोज़िशन की जानकारी देनी चाहिए. साथ ही, स्क्रीन पर विज़ुअल पॉइंटर दिखाना चाहिए [संसाधन, 71].
• टच इवेंट को उस ऐक्शन कोड के साथ रिपोर्ट करना ज़रूरी है जो स्क्रीन पर पॉइंटर के नीचे या ऊपर जाने पर होने वाले स्टेटस में बदलाव के बारे में बताता है [संसाधन, 71].
• यह ज़रूरी है कि स्क्रीन पर मौजूद किसी ऑब्जेक्ट पर कर्सर को नीचे और ऊपर ले जाने की सुविधा काम करती हो. इससे उपयोगकर्ताओं को स्क्रीन पर मौजूद किसी ऑब्जेक्ट पर टैप करने की सुविधा मिलती है.
• यह ज़रूरी है कि स्क्रीन पर किसी ऑब्जेक्ट पर, एक तय समयसीमा के अंदर पॉइंटर को नीचे, ऊपर, फिर नीचे और फिर ऊपर ले जाया जा सके. इससे उपयोगकर्ता, स्क्रीन पर किसी ऑब्जेक्ट पर दो बार टैप करने की सुविधा का इस्तेमाल कर सकते हैं [संसाधन, 71].
• यह ज़रूरी है कि स्क्रीन पर किसी भी जगह पर कर्सर को दबाकर, उसे किसी दूसरी जगह पर ले जाया जा सके. इसके बाद, कर्सर को ऊपर उठाया जा सके. इससे उपयोगकर्ता, टच ड्रैग की सुविधा का इस्तेमाल कर सकते हैं.
• इसमें पॉइंटर डाउन की सुविधा होनी चाहिए, ताकि उपयोगकर्ता ऑब्जेक्ट को स्क्रीन पर तुरंत एक जगह से दूसरी जगह ले जा सकें. इसके बाद, स्क्रीन पर पॉइंटर अप की सुविधा होनी चाहिए, ताकि उपयोगकर्ता ऑब्जेक्ट को स्क्रीन पर फ़्लिंग कर सकें.

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

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

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

7.2.6.1. बटन मैपिंग

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

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

1 [संसाधन, 72]

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

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

4 [संसाधन, 71]

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

1 [संसाधन, 71]

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

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

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

7.3. सेंसर

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

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

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

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

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

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

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

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

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

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

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

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

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

7.3.3. जीपीएस

डिवाइस में जीपीएस रिसीवर शामिल होना चाहिए. अगर किसी डिवाइस में जीपीएस रिसीवर शामिल है, तो उसमें “असिस्टेड जीपीएस” तकनीक का इस्तेमाल किया जाना चाहिए, ताकि जीपीएस लॉक-ऑन में लगने वाला समय कम हो.

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

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

• 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.4. डेटा कनेक्टिविटी

7.4.1. टेलीफ़ोनी

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

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

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

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

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

7.4.2.1. Wi-Fi Direct

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

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

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

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

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

7.4.3. ब्लूटूथ

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

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

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

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

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

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

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

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

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

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

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

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

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

अगर किसी डिवाइस में एनएफ़सी हार्डवेयर शामिल नहीं है, तो उसे Android.content.pm.PackageManager.hasSystemFeature() तरीके [संसाधन, 53] से, 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 (वाई-फ़ाई)) के साथ काम करने की सुविधा भी होनी चाहिए.

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

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

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

7.5. कैमरे

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

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

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

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

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

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

हमारा सुझाव है कि वीडियो कंप्रेस करने की सुविधा (जैसे, MJPEG) का इस्तेमाल करें, ताकि बिना एन्कोड की गई हाई क्वालिटी वाली स्ट्रीम (जैसे, रॉ या अलग से कंप्रेस की गई पिक्चर स्ट्रीम) को ट्रांसफ़र किया जा सके. कैमरे से वीडियो एन्कोड करने की सुविधा काम कर सकती है. अगर ऐसा है, तो डिवाइस पर एक साथ एक ऐसी स्ट्रीम को ऐक्सेस किया जा सकता है जो कोड नहीं की गई हो/ 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 दस्तावेज़ [संसाधन, 91] में शामिल Camera API को पूरा लागू करना ज़रूरी है. भले ही, डिवाइस में हार्डवेयर ऑटोफ़ोकस या अन्य सुविधाएं हों. उदाहरण के लिए, जिन कैमरों में ऑटोफ़ोकस की सुविधा नहीं होती है उन्हें भी रजिस्टर किए गए किसी भी android.hardware.Camera.AutoFocusCallback इंस्टेंस को कॉल करना होगा. भले ही, ऑटोफ़ोकस की सुविधा वाले कैमरे के लिए इसका कोई मतलब न हो. ध्यान दें कि यह नियम, सामने वाले कैमरे पर भी लागू होता है. उदाहरण के लिए, ज़्यादातर सामने वाले कैमरे ऑटोफ़ोकस की सुविधा के साथ काम नहीं करते. इसके बावजूद, एपीआई कॉलबैक को ऊपर बताए गए तरीके से “फ़ेक” किया जाना चाहिए.

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

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

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

जब भी कैमरे से कोई नई फ़ोटो ली जाती है और फ़ोटो की जानकारी को मीडिया स्टोर में जोड़ दिया जाता है, तो डिवाइस के लागू होने पर 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 या उससे कम	424 एमबी	704 एमबी
छोटी/सामान्य स्क्रीन पर xhdpi या उससे ज़्यादा बड़ी स्क्रीन पर hdpi या उससे ज़्यादा ज़्यादा बड़ी स्क्रीन पर mdpi या उससे ज़्यादा	512 एमबी	832 एमबी
छोटी/सामान्य स्क्रीन पर 400 डीपीआई या उससे ज़्यादा बड़ी स्क्रीन पर xhdpi या उससे ज़्यादा बहुत बड़ी स्क्रीन पर tvdpi या उससे ज़्यादा	896 एमबी	1280 एमबी
छोटी/सामान्य स्क्रीन पर 560 डीपीआई या उससे ज़्यादा बड़ी स्क्रीन पर 400 डीपीआई या उससे ज़्यादा बहुत बड़ी स्क्रीन पर xhdpi या उससे ज़्यादा	1344 एमबी	1824 एमबी

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7.7. यूएसबी

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

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

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

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

• अगर डिवाइस में यूएसबी 3.1 की सुविधा है, तो टाइप-सी यूएसबी पोर्ट का इस्तेमाल करना चाहिए.
• इसमें किसी गैर-स्टैंडर्ड पोर्ट फ़ॉर्म फ़ैक्टर का इस्तेमाल किया जा सकता है. हालांकि, अगर ऐसा किया जाता है, तो पोर्ट को स्टैंडर्ड टाइप-A या टाइप-C यूएसबी पोर्ट में बदलने वाली केबल या केबलों के साथ शिप करना ज़रूरी है.
• माइक्रो-एबी यूएसबी पोर्ट का इस्तेमाल किया जा सकता है. हालांकि, अगर ऐसा है, तो डिवाइस के साथ एक या उससे ज़्यादा केबल भी दी जानी चाहिए, ताकि पोर्ट को स्टैंडर्ड टाइप-ए या टाइप-सी यूएसबी पोर्ट में बदला जा सके.
• Android SDK के दस्तावेज़ [संसाधन, 98] में बताए गए तरीके के मुताबिक, यूएसबी ऑडियो क्लास को लागू करने का बहुत ज़्यादा सुझाव दिया जाता है.
• Android SDK में बताए गए तरीके के मुताबिक, Android USB host API को लागू करना ज़रूरी है. साथ ही, हार्डवेयर की सुविधा android.hardware.usb.host [संसाधन, 100] के साथ काम करने की जानकारी देना ज़रूरी है.
• यह ज़रूरी है कि यह चार्जिंग डाउनस्ट्रीम पोर्ट, 1.5 A से 5 A के बीच आउटपुट कर सके. इस बारे में, यूएसबी बैटरी चार्जिंग स्पेसिफ़िकेशन, रिविज़न 1.2 [रिसॉर्स, 99] में बताया गया है.

7.8. ऑडियो

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

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

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

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

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

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

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

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

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

Android नेटवर्क [संसाधन, 101] पर 3.5 मि॰मी॰ के ऑडियो प्लग का इस्तेमाल करने वाले हेडसेट और अन्य ऑडियो ऐक्सेसरी के साथ काम करने के लिए, अगर किसी डिवाइस में एक या उससे ज़्यादा एनालॉग ऑडियो पोर्ट शामिल हैं, तो कम से कम एक ऑडियो पोर्ट, चार कंडक्टर वाला 3.5 मि॰मी॰ का ऑडियो जैक होना चाहिए. अगर किसी डिवाइस में 4 कंडक्टर वाला 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 के बीच होना चाहिए.

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 एमबी/सेकंड हो.

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

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

9.1. अनुमतियां

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

9.8. निजता

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

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

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

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

9.10. वेरिफ़ाइड बूट

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

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

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

10. सॉफ़्टवेयर की कंपैटबिलिटी टेस्टिंग

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

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

10.1. Compatibility Test Suite

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

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

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

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

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

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

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

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

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

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

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

• Android Automotive के लागू होने पर, रीबूट के ज़रिए ऑफ़लाइन अपडेट के साथ ओटीए डाउनलोड की सुविधा काम करनी चाहिए.
• डिवाइस पर OTA अपडेट की सुविधा लागू करने के लिए, यह ज़रूरी है कि डिवाइस को रीबूट करके, ऑफ़लाइन अपडेट किया जा सके.

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

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

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

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

इस रिलीज़ में, काम करने के साथ-साथ,

सेक्शन	बदलाव की खास जानकारी
2. डिवाइस टाइप	Android Automotive को लागू करने के बारे में जानकारी जोड़ी गई.
2.1 डिवाइस कॉन्फ़िगरेशन	Android Automotive को लागू करने के लिए कॉलम जोड़ा गया.
3.3.2. 32-बिट ARM नेटिव कोड के साथ काम करना	नया सेक्शन जोड़ा गया.
3.4.1. वेबव्यू के साथ काम करना	अपस्ट्रीम को लागू करने में हुए बदलाव को ध्यान में रखते हुए, वेबव्यू उपयोगकर्ता एजेंट स्ट्रिंग की ज़रूरी शर्तों को अपडेट किया गया.
3.4.2. अलग-अलग ब्राउज़र पर साइट की जांच करना	Android ऑटोमोटिव के लागू होने के उदाहरण के तौर पर एक और उदाहरण जोड़ा गया है. इसमें ब्राउज़र ऐप्लिकेशन को छोड़ा जा सकता है.
3.7. रनटाइम के साथ काम करने की सुविधा	छोटी स्क्रीन के लिए, रनटाइम के लिए ज़रूरी हेप साइज़ को अपडेट किया गया है. साथ ही, नई डीपीआई बकेट (280 डीपीआई) के लिए ज़रूरी शर्तें जोड़ी गई हैं.
3.8.3. सूचनाएं	Android Watch, टेलिविज़न, और Automotive के लिए, सूचना से जुड़ी ज़रूरी शर्तों के बारे में जानकारी दी गई है.
3.8.8. गतिविधि स्विच करना	खास जानकारी वाले वीडियो के टाइटल की संख्या से जुड़ी ज़रूरी शर्तों को कम करना.
3.8.10. लॉक स्क्रीन पर मीडिया कंट्रोल	Android Watch और Automotive के लिए, ज़रूरी शर्तों के बारे में साफ़ तौर पर बताया गया है.
3.8.13. यूनिकोड और फ़ॉन्ट	इमोजी वर्ण डालने के तरीके से जुड़ी ज़रूरी शर्तों में ढील दी गई है.
3.9. डिवाइस प्रबंधन	डिवाइस एडमिनिस्ट्रेशन की सभी नीतियों के साथ काम करने के लिए, ज़रूरी शर्तें.
3.10. सुलभता	Android Automotive की ज़रूरी शर्तें जोड़ी गईं.
3.11. लेख से बोली	Android Automotive की ज़रूरी शर्तें जोड़ी गईं.
5.1. मीडिया कोडेक	CamcorderProfile की रिपोर्ट में बताए गए कोडेक के लिए, डिकोड करने की सुविधा ज़रूरी है.
5.1.3 वीडियो कोडेक	Android Automotive की ज़रूरी शर्तें जोड़ी गईं.
5.4. ऑडियो रिकॉर्डिंग	सेक्शन की शुरुआत में साफ़ तौर पर बताई गई भाषा, ताकि यह पक्का किया जा सके कि ज़रूरी शर्तों को ज़रूरी के तौर पर पढ़ा जाए.
7.1.1.3. स्क्रीन की सघनता	स्क्रीन की नई डीपीआई (280 डीपीआई) जोड़ी गई.
7.1.5. लेगसी ऐप्लिकेशन के साथ काम करने वाला मोड	Android Automotive की ज़रूरी शर्तें जोड़ी गईं.
7.2 इनपुट डिवाइस	सामान्य जानकारी वाला स्टेटमेंट जोड़ा गया.
7.2.1. कीबोर्ड	Android Automotive से जुड़ी ज़रूरी शर्तें जोड़ी गईं.
7.2.3. मार्गदर्शक कुंजियां	Android Automotive से जुड़ी ज़रूरी शर्तें जोड़ी गईं.
7.3.1. एक्सलरोमीटर	Android Watch पर रिपोर्टिंग की फ़्रीक्वेंसी से जुड़ी ज़रूरी शर्तों में ढील दी गई है.
7.3.4. जाइरोस्कोप	Android Watch पर रिपोर्टिंग की फ़्रीक्वेंसी से जुड़ी ज़रूरी शर्तों में ढील दी गई है.
7.4.3 ब्लूटूथ	Android Automotive से जुड़ी ज़रूरी शर्तें जोड़ी गईं.
7.4.4. नियर फ़ील्ड कम्यूनिकेशन	होस्ट कार्ड एम्युलेशन की ज़रूरत पड़ने की स्थिति के बारे में साफ़ तौर पर बताया गया है.
7.6.1. डिवाइस की कम से कम मेमोरी और स्टोरेज	कम रिज़ॉल्यूशन वाली स्क्रीन वाले डिवाइसों के लिए, रैम की कम से कम ज़रूरी शर्तों को अपडेट किया गया है और isLowRamDevice() की ज़रूरी शर्त को जोड़ा गया है.
7.6.2. ऐप्लिकेशन का शेयर किया गया स्टोरेज	होस्ट मशीन के ऐक्सेस के लिए सहायता ज़रूरी होने पर, अपडेट की गई ज़रूरी शर्तें.
7.7 यूएसबी	यूएसबी सेक्शन में टाइपिंग की गड़बड़ियों को ठीक करना
7.6.2. ऐप्लिकेशन का शेयर किया गया स्टोरेज	पहले से इंस्टॉल किए गए सिस्टम ऐप्लिकेशन, सेकंडरी बाहरी स्टोरेज में डेटा सेव कर सकते हैं. इसके लिए, अपडेट की गई ज़रूरी शर्तें.
7.6.2. ऐप्लिकेशन का शेयर किया गया स्टोरेज	ऐप्लिकेशन, सेकंडरी एक्सटर्नल स्टोरेज में लिखने के लिए ACTION_OPEN_DOCUMENT_TREE का इस्तेमाल कर सकते हैं
7.6.2. ऐप्लिकेशन का शेयर किया गया स्टोरेज	यह साफ़ तौर पर बताएं कि /sdcard, /data के साथ स्टोरेज शेयर कर सकता है
7.7 यूएसबी	7.7 से, UMS/MTP पर ग़ैर-ज़रूरी शर्त हटाना
7.8.1. माइक्रोफ़ोन	Android Automotive से जुड़ी ज़रूरी शर्तें जोड़ी गईं.
8.2. फ़ाइल I/O ऐक्सेस की परफ़ॉर्मेंस	ज़रूरी शर्तों के बारे में पूरी जानकारी दी गई है.
9.5. एक डिवाइस पर कई लोगों के काम करने की सुविधा	मुख्य बाहरी स्टोरेज के लिए, एसडी कार्ड को एन्क्रिप्ट करना ज़रूरी है.
9.8. निजता	पहले से लोड किए गए वीपीएन के लिए, निजता से जुड़ी ज़रूरी शर्त जोड़ी गई है.
9.9. पूरी ड्राइव को एन्क्रिप्ट (सुरक्षित) करना	पूरी ड्राइव को एन्क्रिप्ट (सुरक्षित) करने की सुविधा ज़रूरी होने की शर्त के बारे में साफ़ तौर पर बताया गया है.
9.10. वेरिफ़ाइड बूट	वेरिफ़ाइड बूट की परिभाषा को साफ़ तौर पर बताया गया है.
11. अपडेट किया जा सकने वाला सॉफ़्टवेयर	यह बताया गया है कि ओटीए डाउनलोड की ज़रूरी शर्त को अनुमति दी गई है, लेकिन Android Automotive को लागू करने के लिए यह ज़रूरी नहीं है.

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

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

14. संसाधन

1. IETF आरएफ़सी2119 की ज़रूरी शर्तों के लेवल: http://www.ietf.org/rfc/rfc2119.txt

2. Android ओपन सोर्स प्रोजेक्ट: http://source.android.com/

3. Android Television की सुविधाएं: http://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_LEANBACK

4. Android Watch की सुविधा: http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_WATCH

5. एपीआई की परिभाषाएं और दस्तावेज़: http://developer.android.com/reference/packages.html

6. Android की अनुमतियों के बारे में जानकारी: http://developer.android.com/reference/android/Manifest.permission.html

7. android.os.Build का रेफ़रंस: http://developer.android.com/reference/android/os/Build.html

8. Android 5.1 के साथ काम करने वाली वर्शन स्ट्रिंग: http://source.android.com/compatibility/5.1/versions.html

9. टेलीफ़ोनी सेवा देने वाली कंपनी: http://developer.android.com/reference/android/provider/Telephony.html

10. होस्ट-आधारित कार्ड एमुलेटर: http://developer.android.com/guide/topics/connectivity/nfc/hce.html

11. Android एक्सटेंशन पैक: http://developer.android.com/guide/topics/graphics/opengl.html#aep

12. android.webkit.WebView क्लास: http://developer.android.com/reference/android/webkit/WebView.html

13. वेबव्यू के साथ काम करने वाले डिवाइस: http://www.chromium.org/

14. HTML5: http://html.spec.whatwg.org/multipage/

15. HTML5 की ऑफ़लाइन सुविधाएं: http://dev.w3.org/html5/spec/Overview.html#offline

16. HTML5 वीडियो टैग: http://dev.w3.org/html5/spec/Overview.html#video

17. HTML5/W3C जियोलोकेशन एपीआई: http://www.w3.org/TR/geolocation-API/

18. HTML5/W3C वेबस्टोरेज एपीआई: http://www.w3.org/TR/webstorage/

19. HTML5/W3C IndexedDB API: http://www.w3.org/TR/IndexedDB/

20. Dalvik Executable Format और बाइटकोड स्पेसिफ़िकेशन: ये Android सोर्स कोड में, dalvik/docs पर उपलब्ध हैं

21. ऐप्लिकेशन विजेट: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html

22. सूचनाएं: http://developer.android.com/guide/topics/ui/notifiers/notifications.html

23. ऐप्लिकेशन के लिए संसाधन: https://developer.android.com/guide/topics/resources/available-resources.html

24. स्टेटस बार के आइकॉन के स्टाइल से जुड़ी गाइड: http://developer.android.com/design/style/iconography.html

25. सूचनाओं से जुड़े संसाधन: https://developer.android.com/design/patterns/notifications.html

26. Search Manager: http://developer.android.com/reference/android/app/SearchManager.html

27. टॉस्ट: http://developer.android.com/reference/android/widget/Toast.html

28. थीम: http://developer.android.com/guide/topics/ui/themes.html

29. R.style क्लास: http://developer.android.com/reference/android/R.style.html

30. मटीरियल डिज़ाइन: http://developer.android.com/reference/android/R.style.html#Theme_Material

31. लाइव वॉलपेपर: http://developer.android.com/reference/android/service/wallpaper/WallpaperService.html

32. होम स्क्रीन के बारे में खास जानकारी देने वाले संसाधन: http://developer.android.com/guide/components/recents.html

33. स्क्रीन पिन करना: https://developer.android.com/about/versions/android-5.0.html#ScreenPinning

34. इनपुट के तरीके: http://developer.android.com/guide/topics/text/creating-input-method.html

35. मीडिया सूचना: https://developer.android.com/reference/android/app/Notification.MediaStyle.html

36. ड्रीम्स: http://developer.android.com/reference/android/service/dreams/DreamService.html

37. Settings.Secure LOCATION_MODE:

http://developer.android.com/reference/android/provider/Settings.Secure.html#LOCATION_MODE

38. यूनिकोड 6.1.0: http://www.unicode.org/versions/Unicode6.1.0/

39. Android डिवाइस एडमिन: http://developer.android.com/guide/topics/admin/device-admin.html

40. DevicePolicyManager के बारे में जानकारी: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html

41. Android डिवाइस के मालिक का ऐप्लिकेशन:

http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isDeviceOwnerApp(java.lang.String)

42. Android Accessibility Service API: http://developer.android.com/reference/android/accessibilityservice/AccessibilityService.html

43. Android Accessibility API: http://developer.android.com/reference/android/view/accessibility/package-summary.html

44. Eyes Free प्रोजेक्ट: http://code.google.com/p/eyes-free

45. टेक्स्ट-टू-स्पीच एपीआई: http://developer.android.com/reference/android/speech/tts/package-summary.html

46. टेलिविज़न इनपुट फ़्रेमवर्क: /devices/tv/index.html

47. टूल का रेफ़रंस दस्तावेज़ (adb, aapt, ddms, systrace के लिए): http://developer.android.com/tools/help/index.html

48. Android APK फ़ाइल के बारे में जानकारी: http://developer.android.com/guide/components/fundamentals.html

49. मेनिफ़ेस्ट फ़ाइलें: http://developer.android.com/guide/topics/manifest/manifest-intro.html

50. Android के मीडिया फ़ॉर्मैट: http://developer.android.com/guide/appendix/media-formats.html

51. आरटीसी हार्डवेयर कोडिंग से जुड़ी ज़रूरी शर्तें: http://www.webmproject.org/hardware/rtc-coding-requirements/

52. AudioEffect API: http://developer.android.com/reference/android/media/audiofx/AudioEffect.html

53. Android android.content.pm.PackageManager क्लास और हार्डवेयर की सुविधाओं की सूची:

http://developer.android.com/reference/android/content/pm/PackageManager.html

54. एचटीटीपी लाइव स्ट्रीमिंग ड्राफ़्ट प्रोटोकॉल: http://tools.ietf.org/html/draft-pantos-http-live-streaming-03

55. ADB: http://developer.android.com/tools/help/adb.html

56. Dumpsys: /devices/input/diagnostics.html

57. DDMS: http://developer.android.com/tools/debugging/ddms.html

58. Monkey टेस्टिंग टूल: http://developer.android.com/tools/help/monkey.html

59. SysyTrace टूल: http://developer.android.com/tools/help/systrace.html

60. Android ऐप्लिकेशन डेवलपमेंट से जुड़ी सेटिंग:

http://developer.android.com/reference/android/provider/Settings.html#ACTION_APPLICATION_DEVELOPMENT_SETTINGS

61. एक से ज़्यादा स्क्रीन के साथ काम करना: http://developer.android.com/guide/practices/screens_support.html

62. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html

63. RenderScript: http://developer.android.com/guide/topics/renderscript/

64. OpenGL ES के लिए Android एक्सटेंशन पैक: https://developer.android.com/reference/android/opengl/GLES31Ext.html

65. हार्डवेयर की मदद से वीडियो की रफ़्तार बढ़ाने की सुविधा: http://developer.android.com/guide/topics/graphics/hardware-accel.html

66. EGL एक्सटेंशन-EGL_ANDROID_RECORDABLE:

http://www.khronos.org/registry/egl/extensions/ANDROID/EGL_ANDROID_recordable.txt

67. Display Manager: http://developer.android.com/reference/android/hardware/display/DisplayManager.html

68. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html

69. ऐक्शन असिस्ट: http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST

70. टच इनपुट कॉन्फ़िगरेशन: http://source.android.com/devices/tech/input/touch-devices.html

71. Motion Event API: http://developer.android.com/reference/android/view/MotionEvent.html

72. Key Event API: http://developer.android.com/reference/android/view/KeyEvent.html

73. Android के ओपन सोर्स सेंसर: http://source.android.com/devices/sensors

74. android.hardware.SensorEvent: http://developer.android.com/reference/android/hardware/SensorEvent.html

75. टाइमस्टैंप सेंसर इवेंट: http://developer.android.com/reference/android/hardware/SensorEvent.html#timestamp

76. Android Open Source कॉम्पोनेंट सेंसर: /devices/sensors/sensor-types.html#composite_sensor_type_summary

77. लगातार ट्रिगर होने वाला मोड: /docs/core/interaction/sensors/report-modes#continuous

78. ऐक्सेलेरोमीटर सेंसर: http://developer.android.com/reference/android/hardware/Sensor.html#TYPE_ACCELEROMETER

79. वाई-फ़ाई मल्टीकास्ट एपीआई: http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html

80. वाई-फ़ाई डायरेक्ट (वाई-फ़ाई पी2पी): http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html

81. WifiManager API: http://developer.android.com/reference/android/net/wifi/WifiManager.html

82. ब्लूटूथ एपीआई: http://developer.android.com/reference/android/bluetooth/package-summary.html

83. Bluetooth ScanFilter API: https://developer.android.com/reference/android/bluetooth/le/ScanFilter.html

84. एनडीएफ़ पुश प्रोटोकॉल: http://source.android.com/compatibility/ndef-push-protocol.pdf

85. Android Beam: http://developer.android.com/guide/topics/connectivity/nfc/nfc.html

86. Android पर एनएफ़सी की मदद से फ़ाइलें शेयर करने की सेटिंग:

http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS

87. एनएफ़सी कनेक्शन हैंडओवर: http://members.nfc-forum.org/specs/spec_list/#conn_handover

88. एनएफ़सी का इस्तेमाल करके, ब्लूटूथ को सुरक्षित तरीके से आसानी से जोड़ना: http://members.nfc-forum.org/apps/group_public/download.php/18688/NFCForum-AD-BTSSP_1_1.pdf

89. Content Resolver: http://developer.android.com/reference/android/content/ContentResolver.html

90. कैमरे के ओरिएंटेशन का एपीआई: http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)

91. कैमरा: http://developer.android.com/reference/android/hardware/Camera.html

92. कैमरा: http://developer.android.com/reference/android/hardware/Camera.Parameters.html

93. कैमरे का हार्डवेयर लेवल: https://developer.android.com/reference/android/hardware/camera2/CameraCharacteristics.html#INFO_SUPPORTED_HARDWARE_LEVEL

94. कैमरे के वर्शन के लिए सहायता: http://source.android.com/devices/camera/versioning.html

95. Android DownloadManager: http://developer.android.com/reference/android/app/DownloadManager.html

96. Android फ़ाइल ट्रांसफ़र: http://www.android.com/filetransfer

97. Android Open Accessories: http://developer.android.com/guide/topics/connectivity/usb/accessory.html

98. Android यूएसबी ऑडियो: http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO

99. यूएसबी चार्जिंग स्पेसिफ़िकेशन: http://www.usb.org/developers/docs/devclass_docs/USB_Battery_Charging_1.2.pdf

100. यूएसबी होस्ट एपीआई: http://developer.android.com/guide/topics/connectivity/usb/host.html

101. वायर वाला ऑडियो हेडसेट: http://source.android.com//docs/core/interaction/accessories/headset/plug-headset-spec.html

102. Android की सुरक्षा और अनुमतियों के बारे में जानकारी: http://developer.android.com/guide/topics/security/permissions.html

103. UserManager का रेफ़रंस: http://developer.android.com/reference/android/os/UserManager.html

104. बाहरी स्टोरेज का रेफ़रंस: http://source.android.com/docs/core/storage

105. बाहरी स्टोरेज के लिए एपीआई: http://developer.android.com/reference/android/os/Environment.html

106. एसएमएस के लिए छोटा कोड: http://en.wikipedia.org/wiki/Short_code

107. Android का ओपन सोर्स एन्क्रिप्शन: http://source.android.com/docs/security/features/encryption

108. Android Compatibility Program के बारे में खास जानकारी: http://source.android.com//docs/compatibility

109. Android पर काम करने वाले ऐप्लिकेशन के बारे में जानकारी देने वाला फ़ोरम: https://groups.google.com/forum/#!forum/android-compatibility

110. WebM प्रोजेक्ट: http://www.webmproject.org/

111. Android UI_MODE_TYPE_CAR API: http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_CAR

112. Android MediaCodecList API: http://developer.android.com/reference/android/media/MediaCodecList.html

113. Android CamcorderProfile API: http://developer.android.com/reference/android/media/CamcorderProfile.html

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