1. परिचय

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.2. Soft API Compatibility

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

3.2.1. अनुमतियां

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.2. विजेट

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

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

3.8.3. सूचनाएं

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

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

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

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

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

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

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

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

साथ ही, हैंडहेल्ड डिवाइस के लिए, ये चीज़ें ज़रूर होनी चाहिए:

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

SDK दस्तावेज़ों में बताए गए तरीके से, Notification.Style class के सभी छह डायरेक्ट सबक्लास काम करने चाहिए .

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

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

3.8.4. खोजें

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

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

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

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

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

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

  • हॉटवर्ड का इस्तेमाल करके बोलकर निर्देश देना
  • ASSIST नेविगेशन बटन/बटन/जेस्चर का इनपुट

• डिवाइस पर, सूचना चालू करने के लिए ऐसा तरीका होना चाहिए जिससे सेक्शन 3.2.3.5 (डिफ़ॉल्ट वॉइस इनपुट और Assistant ऐप्लिकेशन की सेटिंग मेन्यू) से दो नेविगेशन से भी कम समय में सूचना चालू की जा सके .

3.8.5. टोस्ट

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

3.8.6. थीम

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.10. सुलभता

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.12.1.2. नेविगेशन

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.1.2. इमेज कोडेक

फ़ॉर्मैट/कोडेक	एन्कोडर	डिकोडर	जानकारी	इस्तेमाल किए जा सकने वाले फ़ाइल टाइप/कंटेनर फ़ॉर्मैट
JPEG	ज़रूरी है	ज़रूरी है	बेस+प्रोग्रेसिव	JPEG (.jpg)
GIF		ज़रूरी है		GIF (.gif)
PNG	ज़रूरी है	ज़रूरी है		PNG (.png)
BMP		ज़रूरी है		BMP (.bmp)
WebP	ज़रूरी है	ज़रूरी है		WebP (.webp)
Raw		ज़रूरी है		ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.2.1. H.263

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

5.2.2. H-264

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

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

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

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

5.2.3. VP8

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

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

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

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

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

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

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

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

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

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

5.3.1. MPEG-2

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

5.3.2. H.263

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

5.3.3. MPEG-4

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

5.3.4. H.264

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

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

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

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

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

5.3.5. H.265 (HEVC)

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

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

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

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

5.3.6. VP8

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

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

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

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

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

5.3.7. VP9

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• STREAM_RING
• STREAM_ALARM
• STREAM_NOTIFICATION

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.8. Secure Media

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6.1. डेवलपर टूल

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

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

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

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

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

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

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

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

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

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

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