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

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

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

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

अगर सेक्शन 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 को लागू करने के तरीके:

android.hardware.type.automotive सुविधा का एलान करना ज़रूरी है.
uiMode = UI_MODE_TYPE_CAR [संसाधन, 5] के साथ काम करना चाहिए.

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

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

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

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

3. सॉफ़्टवेयर

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

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

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

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

3.2. Soft API Compatibility

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

3.2.1. अनुमतियां

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

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

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

पैरामीटर	जानकारी
VERSION.RELEASE	फ़िलहाल चल रहे Android सिस्टम का वर्शन, इंसान के पढ़ने लायक फ़ॉर्मैट में. इस फ़ील्ड में, [संसाधन, 9] में दी गई स्ट्रिंग वैल्यू में से कोई एक वैल्यू होनी चाहिए.
VERSION.SDK	फ़िलहाल चल रहे Android सिस्टम का वर्शन, तीसरे पक्ष के ऐप्लिकेशन कोड के लिए ऐक्सेस किए जा सकने वाले फ़ॉर्मैट में. Android 6.0 के लिए, इस फ़ील्ड में पूर्णांक की वैल्यू 23 होनी चाहिए.
VERSION.SDK_INT	फ़िलहाल चल रहे Android सिस्टम का वर्शन, तीसरे पक्ष के ऐप्लिकेशन कोड के लिए ऐक्सेस किए जा सकने वाले फ़ॉर्मैट में. Android 6.0 के लिए, इस फ़ील्ड में पूर्णांक की वैल्यू 23 होनी चाहिए.
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:6.0/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.
उपयोगकर्ता	उस उपयोगकर्ता (या ऑटोमेटेड उपयोगकर्ता) का नाम या यूज़र आईडी जिसने बिल्ड जनरेट किया. इस फ़ील्ड के फ़ॉर्मैट के लिए कोई ज़रूरी शर्त नहीं है. हालांकि, यह ज़रूरी है कि यह शून्य या खाली स्ट्रिंग ("") न हो.
SECURITY_PATCH	यह वैल्यू, किसी बिल्ड के लिए सुरक्षा पैच के लेवल की जानकारी देती है. इससे यह पता चलना चाहिए कि बाइल्ड में, Android के आधिकारिक सुरक्षा बुलेटिन के ज़रिए जारी किए गए सभी सुरक्षा पैच शामिल हैं. यह [YYYY-MM-DD] फ़ॉर्मैट में होना चाहिए. यह सार्वजनिक सुरक्षा सूचनाओं में मौजूद, Android सिक्योरिटी पैच लेवल की किसी स्ट्रिंग से मेल खाना चाहिए. उदाहरण के लिए, "2015-11-01".
BASE_OS	यह वैल्यू, बिल्ड के FINGERPRINT पैरामीटर को दिखाती है. यह वैल्यू, Android के सार्वजनिक सुरक्षा बुलेटिन में दिए गए पैच को छोड़कर, इस बिल्ड से पूरी तरह मेल खाती है. यह सही वैल्यू दिखानी चाहिए. अगर ऐसा कोई बिल्ड मौजूद नहीं है, तो खाली स्ट्रिंग ("") दिखाएं.

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://” के लिए ब्राउज़र के कोर इंटेंट पैटर्न से ज़्यादा सटीक होता है.

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

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

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

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

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

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

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

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

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

होम स्क्रीन पर डिफ़ॉल्ट ऐप्लिकेशन सेटिंग मेन्यू दिखाने के लिए, android.settings.HOME_SETTINGS इंटेंट का पालन करना ज़रूरी है. ऐसा तब करना होगा, जब डिवाइस में लागू करने से जुड़ी रिपोर्ट में, android.software.home_screen [संसाधन, 10] दिखे
डिफ़ॉल्ट एसएमएस ऐप्लिकेशन बदलने के लिए डायलॉग दिखाने के लिए, ऐसा सेटिंग मेन्यू उपलब्ध कराना ज़रूरी है जो डिवाइस में लागू होने की जानकारी देने वाली android.hardware.telephony रिपोर्ट के तौर पर, android.provider.Telephony.ACTION_CHANGE_DEFAULT इंटेंट को कॉल करेगा [संसाधन, 11]
टैप करके पैसे चुकाने की सुविधा के लिए, डिफ़ॉल्ट ऐप्लिकेशन सेटिंग मेन्यू दिखाने के लिए, 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 एबीआई मैनेजमेंट दस्तावेज़ [संसाधन, 12] के नए वर्शन में बताया गया है. साथ ही, इसमें बेहतर SIMD (जिसे NEON भी कहा जाता है) [संसाधन, 13] एक्सटेंशन के लिए सहायता शामिल होनी चाहिए
इसे अपस्ट्रीम 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 एक्सटेंशन पैक [संसाधन, 14] फ़ंक्शन सिंबल को एक्सपोर्ट करना ज़रूरी है. सभी सिंबल मौजूद होने चाहिए. हालांकि, डिवाइस पर काम करने वाले OpenGL ES वर्शन और एक्सटेंशन के लिए, सिर्फ़ उनसे जुड़े फ़ंक्शन को पूरी तरह से लागू किया जाना चाहिए.

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

नेटिव कोड के साथ काम करना मुश्किल है. इस वजह से, डिवाइस में लागू करने वाले लोगों को ऊपर दी गई लाइब्रेरी को अपस्ट्रीम 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 Watch डिवाइसों में ऐसा हो सकता है, लेकिन अन्य सभी डिवाइसों में, android.webkit.Webview API को पूरी तरह से लागू करना ज़रूरी है.

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

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

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

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

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

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

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

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

ऐप्लिकेशन कैश मेमोरी/ऑफ़लाइन ऑपरेशन [संसाधन, 18]
<video> टैग [संसाधन, 19]
जगह की जानकारी [संसाधन, 20]

इसके अलावा, डिवाइस में लागू किए गए एपीआई, HTML5/W3C वेबस्टोरेज एपीआई [संसाधन, 21] के साथ काम करने चाहिए. साथ ही, HTML5/W3C IndexedDB API [संसाधन, 22] के साथ काम करने चाहिए. ध्यान दें कि वेब डेवलपमेंट के स्टैंडर्ड से जुड़ी संस्थाएं, वेबस्टोरेज के बजाय 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 की शेयर की गई लाइब्रेरी में पैकेज करना ज़रूरी है. इससे, ऐसे एपीआई के ज़्यादा मेमोरी इस्तेमाल करने से सिर्फ़ उन ऐप्लिकेशन पर असर पड़ेगा जो उनका इस्तेमाल साफ़ तौर पर करते हैं. ऐसा, lt;uses-librarygt; मैकेनिज्म की मदद से किया जाता है.

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

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

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

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

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

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

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

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

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

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

3.8.2. विजेट

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

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

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

3.8.3. सूचनाएं

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

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

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

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

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

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

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

3.8.4. खोजें

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

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

Android डिवाइस पर, सहायता ऐक्शन को मैनेज करने के लिए, डिवाइस पर किसी असिस्टेंट को लागू करना चाहिए [संसाधन, 30].

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

3.8.5. टोस्ट

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

3.8.6. थीम

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

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

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

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

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

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

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

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

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

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

हाल ही के फ़ंक्शन की नेविगेशन बटन का इस्तेमाल करना ज़रूरी नहीं है. इसलिए, Android Television डिवाइसों और Android Watch डिवाइसों के लिए, खास जानकारी वाली स्क्रीन को लागू करने की ज़रूरी शर्तें भी लागू नहीं होतीं.

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

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

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

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

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

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

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

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

3.8.11. स्वप्न

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

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

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

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

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

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 डिवाइस एडमिन एपीआई [संसाधन, 44] की मदद से, पासवर्ड से जुड़ी नीतियों को लागू करना या डिवाइस का डेटा रिमोट तौर पर मिटाना. डिवाइस पर लागू करने के लिए, डिवाइस में DevicePolicyManager क्लास का इस्तेमाल करना ज़रूरी है [संसाधन, 45]. डिवाइस में पिन (अंक) या पासवर्ड (अक्षर और अंक) पर आधारित लॉक स्क्रीन की सुविधा लागू करने के लिए, यह ज़रूरी है कि डिवाइस में डिवाइस मैनेजमेंट की सभी नीतियां काम करती हों. इन नीतियों के बारे में Android SDK के दस्तावेज़ [संसाधन, 44] में बताया गया है. साथ ही, डिवाइस में प्लैटफ़ॉर्म की सुविधा android.software.device_admin की जानकारी होनी चाहिए.

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

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

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

डिवाइस के मालिक के लिए डिवाइस को कॉन्फ़िगर करने की प्रोसेस (android.app.action.PROVISION_MANAGED_DEVICE [ संसाधन, 47] से शुरू होने वाला फ़्लो) का उपयोगकर्ता अनुभव, AOSP के लागू होने के साथ मेल खाना चाहिए

अगर डिवाइस में android.hardware.nfc की सुविधा मौजूद है, तो डिवाइस के मालिकों को एनएफ़सी की सुविधा देने के लिए, डिवाइस के सेटअप के दौरान भी एनएफ़सी की सुविधा चालू होनी चाहिए [संसाधन, 48].

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

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

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

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

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

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

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

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

3.10. सुलभता

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

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

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

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

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

Android में ऐसे एपीआई शामिल हैं जिनकी मदद से, ऐप्लिकेशन टेक्स्ट-टू-स्पीच (टीटीएस) सेवाओं का इस्तेमाल कर सकते हैं. साथ ही, सेवा देने वाली कंपनियां भी टीटीएस सेवाओं को लागू कर सकती हैं [संसाधन, 54]. 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 TV डिवाइस के लागू होने के लिए, यह ज़रूरी है कि वे TV Input Framework के साथ काम करते हों [संसाधन, 55].

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

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

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

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

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

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

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

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

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

3.12.1.2. नेविगेशन

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

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

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

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

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

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

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

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

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

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

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

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

फ़ॉर्मैट/कोडेक	एन्कोडर	डिकोडर	जानकारी	इस्तेमाल किए जा सकने वाले फ़ाइल टाइप/कंटेनर फ़ॉर्मैट
MPEG-4 AAC प्रोफ़ाइल (AAC LC)	ज़रूरी है¹	ज़रूरी है	मोनो/स्टीरियो/5.0/5.1² कॉन्टेंट के लिए, 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+)	ज़रूरी है¹ (Android 4.1+)	ज़रूरी है	मोनो/स्टीरियो/5.0/5.1² कॉन्टेंट के लिए, 16 से 48 किलोहर्ट्ज़ के स्टैंडर्ड सैंपलिंग रेट के साथ काम करता है.
MPEG-4 HE AACv2 प्रोफ़ाइल (बेहतर AAC+)		ज़रूरी है	मोनो/स्टीरियो/5.0/5.1² कॉन्टेंट के लिए, 16 से 48 किलोहर्ट्ज़ के स्टैंडर्ड सैंपलिंग रेट के साथ काम करता है.
AAC ELD (बेहतर कम इंतज़ार वाला AAC)	ज़रूरी है¹ (Android 4.1+)	ज़रूरी है (Android 4.1+)	मोनो/स्टीरियो कॉन्टेंट के लिए, 16 से 48 किलोहर्ट्ज़ के स्टैंडर्ड सैंपलिंग रेट का इस्तेमाल किया जा सकता है.
AMR-NB	ज़रूरी है³	ज़रूरी है³	8 केएचज़ पर सैंपल किए गए 4.75 से 12.2 केबीपीएस	3GPP (.3gp)
AMR-WB	ज़रूरी है³	ज़रूरी है³	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	ज़रूरी है⁴ (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. वीडियो कोडेक

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

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

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

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

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

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

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

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

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

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

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

	एसडी (कम क्वालिटी)	एसडी (अच्छी क्वालिटी)	एचडी 720 पिक्सल¹	एचडी 1080 पिक्सल¹
वीडियो रिज़ॉल्यूशन	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 पिक्सल¹	एचडी 1080 पिक्सल¹
वीडियो रिज़ॉल्यूशन	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.263 डिकोडर के साथ काम करने वाले Android डिवाइसों में, बेसलाइन प्रोफ़ाइल लेवल 30 का इस्तेमाल किया जाना चाहिए.

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

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

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

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

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

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

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

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

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

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

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

2 अगर हार्डवेयर की मदद से, मौजूदा Android Television डिवाइस पर इसे लागू किया जा सकता है, तो इसका सुझाव ज़रूर दिया जाता है.

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

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

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

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

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

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

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

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

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

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

STREAM_RING
STREAM_ALARM
STREAM_NOTIFICATION

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

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

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

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

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

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

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

Android, डिवाइस पर ऑडियो इफ़ेक्ट लागू करने के लिए एपीआई उपलब्ध कराता है [संसाधन, 69]. डिवाइस में लागू की गई सुविधाएं, जिनमें 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 क्लास [संसाधन, 70] के ज़रिए, android.hardware.audio.low_latency सुविधा की जानकारी दें. इसके उलट, अगर डिवाइस में लागू की गई सुविधा इन ज़रूरी शर्तों को पूरा नहीं करती है, तो उसे कम इंतज़ार वाले ऑडियो के साथ काम करने की जानकारी नहीं देनी चाहिए.

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

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

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

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

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

5.8. Secure Media

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

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

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

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

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

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

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

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

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

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

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

6.1. डेवलपर टूल

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

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

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

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

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

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

Monkey [संसाधन, 75]

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

SysTrace [संसाधन, 76]

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

ज़्यादातर Linux-आधारित सिस्टम और Apple Macintosh सिस्टम, Android SDK टूल का इस्तेमाल करके Android डिवाइसों को पहचानते हैं. इसके लिए, उन्हें किसी और सहायता की ज़रूरत नहीं होती. हालांकि, आम तौर पर Microsoft Windows सिस्टम को नए Android डिवाइसों के लिए ड्राइवर की ज़रूरत होती है. उदाहरण के लिए, नए वेंडर आईडी और कभी-कभी नए डिवाइस आईडी के लिए, Windows सिस्टम के कस्टम यूएसबी ड्राइवर ज़रूरी होते हैं. अगर स्टैंडर्ड Android SDK में दिए गए adb टूल से किसी डिवाइस को पहचाना नहीं जा सकता, तो डिवाइस लागू करने वाले लोगों को Windows ड्राइवर उपलब्ध कराने होंगे. इससे डेवलपर, adb प्रोटोकॉल का इस्तेमाल करके डिवाइस से कनेक्ट कर पाएंगे. ये ड्राइवर, Windows XP, Windows Vista, Windows 7, Windows 8, और Windows 10 के लिए 32-बिट और 64-बिट, दोनों वर्शन में उपलब्ध होने चाहिए.

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

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

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

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

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

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

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

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

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

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

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

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

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

इस सेक्शन में बताए गए Android Watch डिवाइसों (सेक्शन 2 में इनके बारे में बताया गया है) की स्क्रीन का साइज़ छोटा हो सकता है.

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

Android Watch डिवाइसों का आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) 1.0 (1:1) हो सकता है.

स्क्रीन का आसपेक्ट रेशियो 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)
360 डीपीआई (360dpi)
400 डीपीआई (400dpi)
420 डीपीआई (420dpi)
480 डीपीआई (xxhdpi)
560 डीपीआई (560dpi)
640 डीपीआई (xxxhdpi)

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

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

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

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 के दस्तावेज़ [संसाधन, 80] में दी गई है.

डिवाइस के लागू होने के बाद, यह भी सही तरीके से पता चलना चाहिए कि वह डिवाइस, 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 इंटरफ़ेस [संसाधन, 81] वाला एक्सटेंशन पैक भी उपलब्ध है. साथ ही, इसमें बेहतर ग्राफ़िक्स फ़ंक्शन के लिए नेटिव सपोर्ट भी मिलता है. जैसे, टेसेलेशन और ASTC टेक्सचर कंप्रेस करने का फ़ॉर्मैट. Android डिवाइस पर इस एक्सटेंशन पैक का इस्तेमाल किया जा सकता है. हालांकि, यह ज़रूरी है कि इसे पूरी तरह से लागू करने के बाद, android.hardware.opengles.aep सुविधा फ़्लैग की मदद से, इसकी पहचान की जाए.

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

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

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

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

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

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

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

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

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

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

7.2.1. कीबोर्ड

Android Watch और Android Automotive के लागू होने पर, हो सकता है कि सॉफ़्ट कीबोर्ड लागू हो जाए. अन्य सभी डिवाइसों पर, सॉफ़्ट कीबोर्ड लागू करना ज़रूरी है. साथ ही, यह भी ज़रूरी है कि:

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

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

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

Android TV डिवाइसों में डी-पैड की सुविधा होनी चाहिए.

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

अगर डिवाइस पर Android Television की सुविधा नहीं है, तो हो सकता है कि टच न करने वाले नेविगेशन के विकल्प (ट्रैकबॉल, डी-पैड या व्हील) को शामिल न किया जाए.
android.content.res.Configuration.navigation [Resources, 85] के लिए सही वैल्यू रिपोर्ट करना ज़रूरी है.
टेक्स्ट चुनने और उसमें बदलाव करने के लिए, यूज़र इंटरफ़ेस का ऐसा विकल्प देना चाहिए जो इनपुट मैनेजमेंट इंजन के साथ काम करता हो. 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 6.0 और उसके बाद के वर्शन वाले नए डिवाइसों में, मेन्यू फ़ंक्शन के लिए कोई खास फ़िज़िकल बटन नहीं होना चाहिए. पुराने डिवाइसों पर, मेन्यू फ़ंक्शन के लिए कोई फ़िज़िकल बटन लागू नहीं किया जाना चाहिए. हालांकि, अगर फ़िज़िकल मेन्यू बटन लागू किया गया है और डिवाइस पर targetSdkVersion > 10 वाले ऐप्लिकेशन चल रहे हैं, तो डिवाइस पर:

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

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

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

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

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

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

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

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

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

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

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

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

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

7.2.6.1. बटन मैपिंग

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

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

1 [संसाधन, 88]

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

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

4 [संसाधन, 87]

ऐनलॉग कंट्रोल¹	एचआईडी का इस्तेमाल	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 [संसाधन, 87]

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

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

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

7.3. सेंसर

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

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

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

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

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

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

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

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

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

TYPE_ACCELEROMETER सेंसर को लागू करना और उसकी रिपोर्ट देना ज़रूरी है [संसाधन, 94].
Android Watch डिवाइसों के लिए, कम से कम 50 हर्ट्ज़ की फ़्रीक्वेंसी तक इवेंट रिपोर्ट करने की ज़रूरत होती है. ऐसा इसलिए, क्योंकि इन डिवाइसों में बैटरी की कमी होती है. इसके अलावा, अन्य सभी तरह के डिवाइसों के लिए, 100 हर्ट्ज़ की फ़्रीक्वेंसी तक इवेंट रिपोर्ट करने की ज़रूरत होती है.
कम से कम 200 हर्ट्ज़ तक के इवेंट की रिपोर्ट करनी चाहिए.
Android APIs [संसाधन, 90] में बताए गए तरीके के मुताबिक, Android सेंसर कोऑर्डिनेट सिस्टम का पालन करना ज़रूरी है.
यह किसी भी अक्ष पर, गुरुत्वाकर्षण के चार गुने (4g) या उससे ज़्यादा तक के फ़्रीफ़ॉल को मापने में सक्षम होना चाहिए.
इसका रिज़ॉल्यूशन कम से कम 12-बिट होना चाहिए और कम से कम 16-बिट होना चाहिए.
अगर लाइफ़साइकल के दौरान कैरेक्टरिस्टिक में बदलाव होता है और उन्हें ठीक किया जाता है, तो डिवाइस के रीबूट होने के बीच, कैलिब्रेशन पैरामीटर को बनाए रखते हुए, इस्तेमाल के दौरान कैलिब्रेट किया जाना चाहिए.
तापमान के हिसाब से अडजस्ट होना चाहिए.
स्टैंडर्ड डेविएशन 0.05 m/s^ से ज़्यादा नहीं होना चाहिए. स्टैंडर्ड डेविएशन का हिसाब, हर अक्ष के आधार पर लगाया जाना चाहिए. इसके लिए, कम से कम तीन सेकंड की अवधि में इकट्ठा किए गए सैंपल का इस्तेमाल करना चाहिए. सैंपल इकट्ठा करने की दर सबसे तेज़ होनी चाहिए.
Android SDK दस्तावेज़ में बताए गए तरीके के मुताबिक, TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER कंपोजिट सेंसर लागू करने चाहिए. मौजूदा और नए Android डिवाइसों के लिए, TYPE_SIGNIFICANT_MOTION कंपोजिट सेंसर को लागू करने का बहुत सुझाव दिया जाता है. अगर इनमें से किसी भी सेंसर को लागू किया जाता है, तो उनकी बिजली की खपत का कुल योग हमेशा 4 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 [संसाधन, 90] में बताए गए तरीके के मुताबिक, 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.3.9. हाई फ़िडेलिटी सेंसर

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

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

SENSOR_TYPE_ACCELEROMETER
- मापने की सीमा कम से कम -8g और +8g के बीच होनी चाहिए
- मेज़रमेंट रिज़ॉल्यूशन कम से कम 1024 LSB/G होना चाहिए
- मेज़रमेंट फ़्रीक्वेंसी कम से कम 12.5 हर्ट्ज़ या उससे कम होनी चाहिए
- मेज़रमेंट की ज़्यादा से ज़्यादा फ़्रीक्वेंसी 200 हर्ट्ज़ या इससे ज़्यादा होनी चाहिए
- मेज़रमेंट नॉइज़ 400uG/√Hz से ज़्यादा नहीं होना चाहिए
- इस सेंसर के लिए, बिना 'जागने' वाले फ़ॉर्म को लागू करना ज़रूरी है. साथ ही, यह फ़ॉर्म कम से कम 3,000 सेंसर इवेंट को बफ़र करने की सुविधा के साथ होना चाहिए
- बैचिंग के दौरान, डिवाइस की बिजली की खपत 3 mW से ज़्यादा नहीं होनी चाहिए
SENSOR_TYPE_GYROSCOPE
- मेज़रमेंट की रेंज कम से कम -1,000 से +1,000 डीपीएस के बीच होनी चाहिए
- मेज़रमेंट रिज़ॉल्यूशन कम से कम 16 LSB/dps होना चाहिए
- मेज़रमेंट फ़्रीक्वेंसी कम से कम 12.5 हर्ट्ज़ या उससे कम होनी चाहिए
- मेज़रमेंट की ज़्यादा से ज़्यादा फ़्रीक्वेंसी 200 हर्ट्ज़ या इससे ज़्यादा होनी चाहिए
- मेज़रमेंट नॉइज़ 0.014°/s/√Hz से ज़्यादा नहीं होना चाहिए
SENSOR_TYPE_GYROSCOPE_UNCALIBRATED, जिसकी क्वालिटी से जुड़ी ज़रूरी शर्तें, SENSOR_TYPE_GYROSCOPE जैसी ही हों
SENSOR_TYPE_GEOMAGNETIC_FIELD
- मेज़रमेंट की रेंज कम से कम -900 और +900 uT के बीच होनी चाहिए
- मेज़रमेंट का रिज़ॉल्यूशन कम से कम 5 LSB/uT होना चाहिए
- मेज़रमेंट फ़्रीक्वेंसी कम से कम 5 हर्ट्ज़ या उससे कम होनी चाहिए
- मेज़रमेंट की ज़्यादा से ज़्यादा फ़्रीक्वेंसी 50 हर्ट्ज़ या इससे ज़्यादा होनी चाहिए
- मेज़रमेंट नॉइज़ 0.5 uT से ज़्यादा नहीं होना चाहिए
SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED, जिसकी क्वालिटी से जुड़ी ज़रूरी शर्तें, SENSOR_TYPE_GEOMAGNETIC_FIELD जैसी ही हों. इसके अलावा:
- इस सेंसर के लिए, बिना 'जागने' वाले फ़ॉर्म को लागू करना ज़रूरी है. साथ ही, यह फ़ॉर्म कम से कम 600 सेंसर इवेंट को बफ़र करने की सुविधा के साथ होना चाहिए
SENSOR_TYPE_PRESSURE
- मेज़रमेंट की रेंज कम से कम 300 और 1100 hPa के बीच होनी चाहिए
- माप का रिज़ॉल्यूशन कम से कम 80 LSB/hPa होना चाहिए
- मेज़रमेंट फ़्रीक्वेंसी कम से कम 1 हर्ट्ज़ या उससे कम होनी चाहिए
- मेज़रमेंट की फ़्रीक्वेंसी 10 हर्ट्ज़ या इससे ज़्यादा होनी चाहिए
- मेज़रमेंट नॉइज़ 2 Pa/√Hz से ज़्यादा नहीं होना चाहिए
- इस सेंसर के लिए, बिना 'जागने' वाले फ़ॉर्म को लागू करना ज़रूरी है. साथ ही, यह फ़ॉर्म कम से कम 300 सेंसर इवेंट को बफ़र करने की सुविधा के साथ होना चाहिए
- बैचिंग के दौरान बिजली की खपत 2 mW से ज़्यादा नहीं होनी चाहिए
TYPE_GAME_ROTATION_VECTOR
- इस सेंसर के लिए, बिना डिवाइस को जगाने वाले फ़ॉर्म को लागू करना ज़रूरी है. साथ ही, यह फ़ॉर्म कम से कम 300 सेंसर इवेंट को बफ़र करने की सुविधा के साथ होना चाहिए.
- बैचिंग के दौरान, डिवाइस की बिजली की खपत 4 mW से ज़्यादा नहीं होनी चाहिए.
SENSOR_TYPE_SIGNIFICANT_MOTION
- डिवाइस के स्टैटिक होने पर, बिजली की खपत 0.5 mW से ज़्यादा नहीं होनी चाहिए और डिवाइस के मूव होने पर, बिजली की खपत 1.5 mW से ज़्यादा नहीं होनी चाहिए
SENSOR_TYPE_STEP_DETECTOR
- इस सेंसर के लिए, बिना 'जागने' वाले फ़ॉर्म को लागू करना ज़रूरी है. साथ ही, यह फ़ॉर्म कम से कम 100 सेंसर इवेंट को बफ़र करने की सुविधा के साथ होना चाहिए
- डिवाइस के स्टैटिक होने पर, बिजली की खपत 0.5 mW से ज़्यादा नहीं होनी चाहिए और डिवाइस के मूव होने पर, बिजली की खपत 1.5 mW से ज़्यादा नहीं होनी चाहिए
- बैचिंग के दौरान बिजली की खपत 4 mW से ज़्यादा नहीं होनी चाहिए
SENSOR_TYPE_STEP_COUNTER
- डिवाइस के स्टैटिक होने पर, बिजली की खपत 0.5 mW से ज़्यादा नहीं होनी चाहिए और डिवाइस के मूव होने पर, बिजली की खपत 1.5 mW से ज़्यादा नहीं होनी चाहिए
SENSOR_TILT_DETECTOR
- डिवाइस के स्टैटिक होने पर, बिजली की खपत 0.5 mW से ज़्यादा नहीं होनी चाहिए और डिवाइस के मूव होने पर, बिजली की खपत 1.5 mW से ज़्यादा नहीं होनी चाहिए

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

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

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

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

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

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

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

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

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

7.4.1. टेलीफ़ोनी

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

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

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

Android TV डिवाइस के लागू होने के लिए, वाई-फ़ाई की सुविधा ज़रूरी है.

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

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

7.4.2.1. Wi-Fi Direct

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

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

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

Android Television डिवाइसों के लिए, वाई-फ़ाई टनल किए गए डायरेक्ट लिंक सेटअप (टीडीएलएस) की सुविधा का होना ज़रूरी है.

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

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

7.4.3. ब्लूटूथ

Android Watch और Automotive के लागू होने के लिए, यह ज़रूरी है कि वे ब्लूटूथ के साथ काम करते हों. Android TV के लिए, यह ज़रूरी है कि ब्लूटूथ और ब्लूटूथ ले की सुविधा काम करती हो.

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

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

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

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

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

android.content.pm.PackageManager.hasSystemFeature() तरीके से, android.hardware.nfc सुविधा की जानकारी देना ज़रूरी है [संसाधन, 70].
यह ज़रूरी है कि डिवाइस, इन एनएफ़सी स्टैंडर्ड के ज़रिए एनडीएफ़ मैसेज पढ़ और लिख सके:
- यह एनएफ़सी फ़ोरम के रीडर/राइटर्स के तौर पर काम कर सके (जैसा कि एनएफ़सी फ़ोरम के तकनीकी स्पेसिफ़िकेशन NFCForum-TS-DigitalProtocol-1.0 में बताया गया है). इसके लिए, यह एनएफ़सी के इन स्टैंडर्ड के मुताबिक होना चाहिए:
  - NfcA (ISO14443-3A)
  - NfcB (ISO14443-3B)
  - NfcF (JIS X 6319-4)
  - IsoDep (ISO 14443-4)
  - एनएफ़सी फ़ोरम टैग टाइप 1, 2, 3, 4 (एनएफ़सी फ़ोरम के मुताबिक)
- हमारा सुझाव है कि आपके डिवाइस में, एनएफ़सी के इन स्टैंडर्ड के ज़रिए, एनडीएफ़ मैसेज और रॉ डेटा को पढ़ने और लिखने की सुविधा हो. ध्यान दें कि यहां दिए गए एनएफ़सी स्टैंडर्ड का इस्तेमाल करने का सुझाव दिया गया है. हालांकि, आने वाले समय में, इन स्टैंडर्ड को ज़रूरी शर्तों के तौर पर शामिल किया जाएगा. इस वर्शन में ये स्टैंडर्ड ज़रूरी नहीं हैं, लेकिन आने वाले वर्शन में ये ज़रूरी होंगे. Android के इस वर्शन पर काम करने वाले मौजूदा और नए डिवाइसों को, इन ज़रूरी शर्तों को पूरा करने का सुझाव दिया जाता है. इससे, आने वाले समय में प्लैटफ़ॉर्म के रिलीज़ किए जाने वाले नए वर्शन पर अपग्रेड किया जा सकेगा.
  - NfcV (ISO 15693)
- यह ऐप्लिकेशन, थिनफ़िल्म एनएफ़सी बारकोड [संसाधन, 102] वाले प्रॉडक्ट के बारकोड और यूआरएल (अगर एन्कोड किया गया हो) को पढ़ सकता है.
- यह ज़रूरी है कि यह डिवाइस, नीचे दिए गए पीयर-टू-पीयर स्टैंडर्ड और प्रोटोकॉल के ज़रिए डेटा भेज और पा सके:
  - ISO 18092
  - LLCP 1.2 (NFC फ़ोरम के मुताबिक)
  - SDP 1.0 (एनएफ़सी फ़ोरम ने तय किया है)
  - एनडीएफ़ पुश प्रोटोकॉल [संसाधन, 103]
  - SNEP 1.0 (NFC फ़ोरम के मुताबिक)
- इसमें Android Beam की सुविधा शामिल होनी चाहिए [संसाधन, 104]:
  - SNEP डिफ़ॉल्ट सर्वर को लागू करना ज़रूरी है. डिफ़ॉल्ट SNEP सर्वर से मिले मान्य एनडीएफ़ मैसेज, ऐप्लिकेशन को भेजे जाने चाहिए. इसके लिए, android.nfc.ACTION_NDEF_DISCOVERED इंटेंट का इस्तेमाल किया जाना चाहिए. सेटिंग में जाकर Android Beam की सुविधा बंद करने पर, इनकमिंग NDEF मैसेज भेजने की सुविधा बंद नहीं होनी चाहिए.
  - एनएफ़सी शेयर करने की सेटिंग दिखाने के लिए, android.settings.NFCSHARING_SETTINGS इंटेंट का पालन करना ज़रूरी है [संसाधन, 105].
  - एनपीपी सर्वर को लागू करना ज़रूरी है. एनपीपी सर्वर को मिले मैसेज को उसी तरह प्रोसेस किया जाना चाहिए जिस तरह एसएनईपी के डिफ़ॉल्ट सर्वर को किया जाता है.
  - 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” [संसाधन, 106] और “एनएफ़सी वर्शन 1.0 का इस्तेमाल करके, ब्लूटूथ से सुरक्षित तरीके से आसानी से जोड़ने की सुविधा” [संसाधन, 107] के स्पेसिफ़िकेशन लागू करें. इस तरह के लागू होने के लिए, एनएफ़सी पर डेटा ट्रांसफ़र करने के अनुरोध/चुने गए रिकॉर्ड को एक्सचेंज करने के लिए, सेवा के नाम “urn:nfc:sn:handover” के साथ, हैंडओवर एलएलसीपी सेवा को लागू करना ज़रूरी है. साथ ही, ब्लूटूथ डेटा ट्रांसफ़र के लिए, ब्लूटूथ ऑब्जेक्ट पुश प्रोफ़ाइल का इस्तेमाल करना ज़रूरी है. लेगसी वजहों से (Android 4.1 डिवाइसों के साथ काम करना जारी रखने के लिए), एनएफ़सी के ज़रिए रिकॉर्ड ट्रांसफ़र करने के अनुरोध/चुने गए रिकॉर्ड को एक्सचेंज करने के लिए, लागू करने की प्रोसेस में अब भी SNEP GET अनुरोध स्वीकार किए जाने चाहिए. हालांकि, कनेक्शन हैंडओवर करने के लिए, लागू करने की प्रोसेस को खुद से SNEP GET अनुरोध नहीं भेजने चाहिए.
- एनएफ़सी डिस्कवरी मोड में, काम करने वाली सभी टेक्नोलॉजी के लिए पोल करना ज़रूरी है.
- डिवाइस के चालू होने पर, स्क्रीन चालू और लॉक-स्क्रीन अनलॉक होने पर, डिवाइस को एनएफ़सी डिस्कवरी मोड में होना चाहिए.

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

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

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

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

MIFARE Classic
MIFARE Ultralight
MIFARE Classic पर NDEF

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 फ़ॉर्मैट काम करने चाहिए.

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

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

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

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

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

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

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

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

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

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

Android Television डिवाइसों में, ऐप्लिकेशन के निजी डेटा के लिए कम से कम 5 जीबी स्टोरेज होना चाहिए.

डिवाइस पर लागू करने के लिए, कर्नेल और यूज़रस्पेस के लिए उपलब्ध मेमोरी, कम से कम यहां दी गई टेबल में बताई गई वैल्यू के बराबर या उससे ज़्यादा होनी चाहिए. (स्क्रीन साइज़ और डेंसिटी की परिभाषाओं के लिए, सेक्शन 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 में एक डाउनलोड मैनेजर शामिल होता है. ऐप्लिकेशन, डेटा फ़ाइलें डाउनलोड करने के लिए इसका इस्तेमाल कर सकते हैं [संसाधन, 115]. डिवाइस में डाउनलोड मैनेजर की सुविधा, डिफ़ॉल्ट “कैश" जगह पर कम से कम 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 के साथ काम करना चाहिए [संसाधन, 116].
यूएसबी डिवाइस क्लास 0x00 की रिपोर्ट करनी चाहिए.
यूएसबी इंटरफ़ेस का नाम 'MTP' होना चाहिए.

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

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

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

7.7. यूएसबी

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

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

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

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

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

7.8. ऑडियो

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

Android डिवाइसों के लिए, हाथ में पकड़े जाने वाले डिवाइस, स्मार्टवॉच, और वाहन में इस्तेमाल करने वाले डिवाइसों में माइक्रोफ़ोन ज़रूर होना चाहिए.

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

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

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

Android Watch डिवाइसों में ऑडियो आउटपुट हो सकता है.

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

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

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

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

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

Android नेटवर्क [संसाधन, 122] पर 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 के बीच होना चाहिए.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

9.1. अनुमतियां

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

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

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

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

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

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

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

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 में एक से ज़्यादा उपयोगकर्ताओं के लिए सहायता उपलब्ध है. साथ ही, इसमें उपयोगकर्ता को पूरी तरह से अलग रखने की सुविधा भी उपलब्ध है [संसाधन, 127]. डिवाइस पर लागू करने पर, एक से ज़्यादा उपयोगकर्ताओं को अनुमति देने की सुविधा चालू हो सकती है. हालांकि, चालू होने पर, एक से ज़्यादा उपयोगकर्ताओं को अनुमति देने की सुविधा [संसाधन, 128] से जुड़ी इन ज़रूरी शर्तों को पूरा करना ज़रूरी है:

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

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

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

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

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

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

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

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

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

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

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

9.8. निजता

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

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

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

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

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

अगर डिवाइस में KeyguardManager.isDeviceSecure() [संसाधन, 131] के लिए, सुरक्षित लॉक स्क्रीन की "true" रिपोर्टिंग की सुविधा काम करती है और यह डिवाइस, ActivityManager.isLowRamDevice() तरीके से बताई गई, सीमित मेमोरी वाला डिवाइस नहीं है, तो डिवाइस में ऐप्लिकेशन के निजी डेटा (/data partition) के साथ-साथ, ऐप्लिकेशन के शेयर किए गए स्टोरेज के partition (/sdcard partition) को फ़ुल-डिस्क एन्क्रिप्शन [संसाधन, 132] की सुविधा होनी चाहिए. हालांकि, यह ज़रूरी है कि /sdcard partition, डिवाइस का ऐसा हिस्सा हो जिसे हटाया न जा सके.

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

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

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

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

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

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

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

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

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

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

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

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

9.12. डेटा हटाना

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

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

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

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

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

10.1. Compatibility Test Suite

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

सेक्शन	परिवर्तनों का सारांश
अलग-अलग	"सुझाया गया" शब्द के इंस्टेंस को "सुझाया गया" से बदला गया
2. डिवाइस टाइप	Android Automotive को लागू करने के बारे में अपडेट
3.2.2. बिल्ड पैरामीटर	हार्डवेयर के सीरियल नंबर और किसी बिल्ड के सुरक्षा पैच लेवल के लिए जोड़े गए एलिमेंट
3.2.3.2. इंटेंट रिज़ॉल्यूशन	सेक्शन का नाम "इंटेंट बदलना" से बदलकर "इंटेंट रिज़ॉल्यूशन" कर दिया गया है. साथ ही, इसमें आधिकारिक डिफ़ॉल्ट ऐप्लिकेशन को लिंक करने से जुड़ी नई ज़रूरी शर्तें जोड़ी गई हैं
3.3.1. ऐप्लिकेशन बाइनरी इंटरफ़ेस	Android ABI के लिए सहायता जोड़ी गई है; Vulkan लाइब्रेरी के नाम से जुड़ा बदलाव
3.4.1. वेबव्यू के साथ काम करना	WebView की रिपोर्ट की गई उपयोगकर्ता एजेंट स्ट्रिंग में बदलाव
3.7. रनटाइम के साथ काम करने की सुविधा	मेमोरी ऐलोकेशन टेबल में अपडेट
3.8.4. खोजें	Assistant की ज़रूरी शर्तों के बारे में अपडेट
3.8.6. थीम	SYSTEM_UI_FLAG_LIGHT_STATUS_BAR फ़्लैग का अनुरोध किए जाने पर, काले रंग के सिस्टम आइकॉन के साथ काम करने की ज़रूरी शर्त जोड़ी गई
3.8.8. गतिविधि स्विच करना	खास जानकारी वाले पेज के टाइटल की संख्या से जुड़ी ज़रूरी शर्तों में ढील दी गई है.
3.8.10. लॉक स्क्रीन पर मीडिया कंट्रोल	Lock Screen Media Control, ताकि 3.8.3 के बारे में पूरी जानकारी मिल सके.
3.9.1. डिवाइस प्रॉविज़निंग	इसमें डिवाइस के मालिक के लिए प्रोवाइड करने और मैनेज की जा रही प्रोफ़ाइल के लिए नए सेक्शन शामिल हैं
3.9.2. मैनेज की जा रही प्रोफ़ाइल से जुड़ी सहायता	मैनेज की जा रही प्रोफ़ाइल की सुविधा के लिए, डिवाइस की ज़रूरी शर्तों वाला नया सेक्शन
3.12.1. टीवी ऐप्लिकेशन	Android Television डिवाइसों के लिए, टीवी ऐप्लिकेशन से जुड़ी ज़रूरी शर्तों के बारे में बताने के लिए सेक्शन जोड़ा गया
3.12.1.1. इलेक्ट्रॉनिक प्रोग्राम गाइड	Android Television डिवाइसों के लिए, ईपीजी से जुड़ी ज़रूरी शर्तों के बारे में बताने के लिए सेक्शन जोड़ा गया
3.12.1.2. नेविगेशन	Android Television डिवाइसों के लिए, टीवी ऐप्लिकेशन के नेविगेशन से जुड़ी ज़रूरी शर्तों के बारे में बताने के लिए सेक्शन जोड़ा गया
3.12.1.3. टीवी इनपुट ऐप्लिकेशन लिंक करना	Android Television डिवाइसों के लिए, टीवी इनपुट ऐप्लिकेशन को लिंक करने से जुड़ी सहायता की ज़रूरी शर्तों के बारे में बताने के लिए सेक्शन जोड़ा गया
5.1. मीडिया कोडेक	मुख्य मीडिया फ़ॉर्मैट और डिकोडिंग के लिए सहायता से जुड़े अपडेट.
5.1.3. वीडियो कोडेक	Android टीवी से जुड़े बदलाव और नई सुविधाएं
5.2. वीडियो एन्कोडिंग	एन्कोडर के लिए बदलाव
5.3. वीडियो डिकोड करना	डिकोडर के लिए बदलाव. इनमें डाइनैमिक वीडियो रिज़ॉल्यूशन, फ़्रेम रेट स्विच करने वगैरह के लिए सहायता शामिल है
5.4. ऑडियो रिकॉर्डिंग	ऑडियो कैप्चर से जुड़े अपडेट
5.6. ऑडियो के इंतज़ार का समय	कम इंतज़ार वाले ऑडियो के लिए सहायता की रिपोर्टिंग के बारे में अपडेट
5.10. प्रोफ़ेशनल ऑडियो	प्रोफ़ेशनल ऑडियो सपोर्ट के लिए सामान्य अपडेट; मोबाइल डिवाइस (जैक) की खास बातों, यूएसबी ऑडियो होस्ट मोड, और अन्य अपडेट के लिए अपडेट
5.9. म्यूज़िकल इंस्ट्रुमेंट डिजिटल इंटरफ़ेस (एमआईडीआई)	म्यूज़िकल इंस्ट्रुमेंट डिजिटल इंटरफ़ेस (एमआईडीआई) के साथ काम करने की सुविधा के बारे में नया सेक्शन जोड़ा गया है. हालांकि, यह सुविधा ज़रूरी नहीं है
6.1. डेवलपर टूल	Windows 10 के साथ काम करने वाले ड्राइवरों के लिए अपडेट
7.1.1.3. स्क्रीन की सघनता	स्क्रीन की डेंसिटी के लिए अपडेट. उदाहरण के लिए, Android स्मार्टवॉच से जुड़े अपडेट
7.2.3. मार्गदर्शक कुंजियां	डिवाइस पर Assist ऐक्शन लागू करने से जुड़ी ज़रूरी शर्तों में बदलाव
7.3. सेंसर (और सब-सेक्शन)	कुछ तरह के सेंसर के लिए नई ज़रूरी शर्तें
7.3.9. हाई फ़िडेलिटी सेंसर	हाई फ़िडेलिटी सेंसर के साथ काम करने वाले डिवाइसों के लिए ज़रूरी शर्तों वाला नया सेक्शन
7.3.10. फ़िंगरप्रिंट सेंसर	फ़िंगरप्रिंट सेंसर से जुड़ी ज़रूरी शर्तों के बारे में नया सेक्शन
7.4.2. आईईईई 802.11 (वाई-फ़ाई)	मल्टीकास्ट डीएनएस (mDNS) के लिए सहायता से जुड़े अपडेट
7.4.3. ब्लूटूथ	ब्लूटूथ स्मार्ट (बीएलई) के लिए, रिज़ॉल्व किए जा सकने वाले निजी पते (आरपीए) से जुड़ा जोड़
7.4.4. नियर फ़ील्ड कम्यूनिकेशन	नियर फ़ील्ड कम्यूनिकेशन (एनएफ़सी) की ज़रूरी शर्तों में बदलाव
7.4.5. नेटवर्क की कम से कम क्षमता	IPv6 के साथ काम करने के लिए ज़रूरी शर्तें जोड़ी गईं
7.6.3. एडॉप्टेबल स्टोरेज	एडॉप्टेबल स्टोरेज को लागू करने के लिए नया सेक्शन
7.7. यूएसबी	AOA स्पेसिफ़िकेशन को लागू करने से जुड़ी ज़रूरी शर्तें
7.8.3. नियर-अल्ट्रासाउंड	नियर-अल्ट्रासाउंड रिकॉर्डिंग, प्लेबैक, और ऑडियो से जुड़े अपडेट	नियर-अल्ट्रासाउंड माइक्रोफ़ोन के लिए, एसएनआर की ज़रूरी शर्तों को कम करना.
8.3. बैटरी सेव करने वाले मोड	ऐप्लिकेशन स्टैंडबाय और 'बैटरी बचाएं (डोज़)' मोड से जुड़ी ज़रूरी शर्तों वाला नया सेक्शन
8.4. बिजली की खपत का हिसाब लगाना	हार्डवेयर कॉम्पोनेंट के लिए बिजली के इस्तेमाल को ट्रैक करने और उस बिजली के इस्तेमाल को खास ऐप्लिकेशन को एट्रिब्यूट करने से जुड़ी ज़रूरी शर्तों वाला नया सेक्शन
9.1. अनुमतियां	अनुमतियों से जुड़ी ज़रूरी शर्तों में बदलाव
9.7. कर्नेल की सुरक्षा से जुड़ी सुविधाएं	SE Linux के अपडेट
9.8. निजता	यूएसबी पोर्ट से शेयर किए गए स्टोरेज को ऐक्सेस करने के लिए, उपयोगकर्ता की सहमति से जुड़ी जानकारी
9.9. पूरी ड्राइव को एन्क्रिप्ट (सुरक्षित) करना	पूरी ड्राइव को सुरक्षित रखने से जुड़ी ज़रूरी शर्तें
9.10. वेरिफ़ाइड बूट	पुष्टि किए गए बूट के लिए अतिरिक्त ज़रूरी शर्त
9.11. कुंजियां और क्रेडेंशियल	पासकोड और क्रेडेंशियल से जुड़ी ज़रूरी शर्तों का नया सेक्शन
9.12. डेटा हटाना	"फ़ैक्ट्री डेटा रीसेट" के लिए नया सेक्शन
11. अपडेट किया जा सकने वाला सॉफ़्टवेयर	डिवाइस के मालिक की ओर से सेट की गई, सिस्टम अपडेट करने की नीति से जुड़ी ज़रूरी शर्त

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

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

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. Android UI_MODE_TYPE_CAR API: http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_CAR

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

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

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

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

10. Android डेवलपर सेटिंग: http://developer.android.com/reference/android/provider/Settings.html

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

12. Android NDK ABI मैनेजमेंट: https://developer.android.com/ndk/guides/abis.html

13. बेहतर SIMD आर्किटेक्चर: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0388f/Beijfcja.html

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

31. Android Assist API: https://developer.android.com/reference/android/app/assist/package-summary.html

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

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

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

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

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

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

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

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

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

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

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

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

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

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

46. डिवाइस के मालिक का ऐप्लिकेशन: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isDeviceOwnerApp(java.lang.String)

47. Android डिवाइस के मालिक के लिए डिवाइस को कॉन्फ़िगर करने का तरीका: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#ACTION_PROVISION_MANAGED_DEVICE

48. एनएफ़सी की मदद से डिवाइस के मालिक के लिए प्रोविज़निंग: /devices/tech/admin/provision.html#device_owner_provisioning_via_nfc

49. Android प्रोफ़ाइल के मालिक का ऐप्लिकेशन:http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isProfileOwnerApp(java.lang.String)

50. Android मैनेज की जाने वाली प्रोफ़ाइल को प्रोवाइड करने का फ़्लो: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#ACTION_PROVISION_MANAGED_PROFILE

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

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

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

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

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

56. टीवी ऐप्लिकेशन के चैनल: http://developer.android.com/reference/android/media/tv/TvContract.Channels.html

57. तीसरे पक्ष के टीवी इनपुट: /devices/tv/index.html#third-party_input_example

58. टीवी इनपुट: /devices/tv/index.html#tv_inputs

59. टीवी चैनल के ईपीजी फ़ील्ड: https://developer.android.com/reference/android/media/tv/TvContract.Programs.html

60. टीवी इनपुट ऐप्लिकेशन को लिंक करना: http://developer.android.com/reference/android/media/tv/TvContract.Channels.html#COLUMN_APP_LINK_INTENT_URI

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

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

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

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

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

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

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

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

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

70. Android android.content.pm.PackageManager क्लास और हार्डवेयर की सुविधाओं की सूची: http://developer.android.com/reference/android/content/pm/PackageManager.html

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

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

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

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

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

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

77. Android ऐप्लिकेशन डेवलपमेंट से जुड़ी सेटिंग: http://developer.android.com/reference/android/provider/Settings.html#ACTION_APPLICATION_DEVELOPMENT_SETTINGS

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

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

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

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

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

83. EGL एक्सटेंशन-EGL_ANDROID_RECORDABLE: http://www.khronos.org/registry/egl/extensions/ANDROID/EGL_ANDROID_recordable.txt

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

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

86. टच इनपुट कॉन्फ़िगरेशन: http://source.android.com/docs/core/interaction/input/touch-devices

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

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

89. Android के ओपन सोर्स सेंसर: http://source.android.com/docs/core/interaction/sensors

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

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

92. Android ओपन सोर्स कॉम्पोज़िट सेंसर: /docs/core/interaction/sensors/sensor-types#composite_sensor_type_summary

93. लगातार ट्रिगर होने की सुविधा वाला मोड: http://developer.android.com/reference/android/hardware/Sensor.html#TYPE_ACCELEROMETER

95. Android Fingerprint API: https://developer.android.com/reference/android/hardware/fingerprint/package-summary.html

96. Android फ़िंगरप्रिंट एचएएल: /devices/tech/security/authentication/fingerprint-hal.html

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

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

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

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

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

102. एनएफ़सी बारकोड: http://developer.android.com/reference/android/nfc/tech/NfcBarcode.html

103. NDEF पुश प्रोटोकॉल: http://source.android.com/docs/compatibility/ndef-push-protocol.pdf

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

105. Android पर NFC की मदद से फ़ाइलें शेयर करने की सेटिंग: http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS

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

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

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

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

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

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

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

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

114. कैमरे के वर्शन के साथ काम करने की सुविधा: http://source.android.com/docs/core/camera/versioning

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

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

117. एडॉप्टेबल स्टोरेज: http://source.android.com/docs/core/storage/adoptable

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

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

120. यूएसबी बैटरी चार्जिंग स्पेसिफ़िकेशन, रिविज़न 1.2: http://www.usb.org/developers/docs/devclass_docs/BCv1.2_070312.zip

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

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

123. पावर प्रोफ़ाइल के कॉम्पोनेंट: http://source.android.com/docs/core/power/values

124. Batterystats: https://developer.android.com/tools/dumpsys#battery

125. बैटरी खर्च की खास जानकारी: http://developer.android.com/reference/android/content/Intent.html#ACTION_POWER_USAGE_SUMMARY

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

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

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

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

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

131. सुरक्षित लॉक स्क्रीन की रिपोर्टिंग: http://developer.android.com/reference/android/app/KeyguardManager.html#isDeviceSecure()

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

133. Android Keystore System: https://developer.android.com/training/articles/keystore.html

134. KeyChain API: https://developer.android.com/reference/android/security/KeyChain.html

135. Keystore API: https://developer.android.com/reference/java/security/KeyStore.html

136. Gatekeeper HAL: http://source.android.com/docs/security/features/authentication/gatekeeper

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

138. SystemUpdatePolicy क्लास: http://developer.android.com/reference/android/app/admin/SystemUpdatePolicy.html

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

140. ऐप्लिकेशन लिंक मैनेज करना: https://developer.android.com/training/app-links/index.html

141. Google Digital Asset Links: https://developers.google.com/digital-asset-links

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