आरएफ़सी2119 में दिए गए आईईटीएफ़ स्टैंडर्ड के मुताबिक, “ज़रूरी”, “ज़रूरी नहीं”, “ज़रूरी”, “करना चाहिए”, “नहीं”, “ज़रूरी”, “नहीं”, “सुझाया गया”, “मई”, और “ज़रूरी नहीं” का इस्तेमाल किया गया.

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

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

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

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

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

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

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

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

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

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

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

Android Watch डिवाइस का मतलब ऐसे Android डिवाइस से है जिसे डिवाइस में पहना जाता है. इसे कलाई पर, शायद कलाई पर, और:

फ़ोन की डायगनल लंबाई 1.1 से 2.5 इंच के बीच होनी चाहिए.
android.hardware.type.watch सुविधा के बारे में बताना ज़रूरी है.
uiMode = UI_Mode_TYPE_देखें पर काम करना ज़रूरी है.

Android Automotive लागू करना. इसका मतलब, वाहन की मुख्य यूनिट से है, जो Android को एक ऑपरेटिंग सिस्टम के तौर पर इस्तेमाल करती है. इसमें, पूरे सिस्टम और/या सूचना और मनोरंजन की सुविधा देने वाले कुछ हिस्से या सभी सुविधाएं उपलब्ध होती हैं. Android Automotive लागू करना:

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

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

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

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

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

3. सॉफ़्टवेयर

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

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

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

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

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

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

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

3.2. सॉफ़्ट एपीआई के साथ काम करने की सुविधा

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

3.2.1. अनुमतियां

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

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

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

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

3.2.3. इंटेंट के साथ काम करना

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

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

डेस्क क्लॉक
ब्राउज़र
Calendar
संपर्क
गैलरी में देखें
वैश्विक खोज
लॉन्चर
संगीत
सेटिंग

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

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

डिवाइस में ऐसा कोई Android कॉम्पोनेंट शामिल नहीं होना चाहिए जो Android में ACTION, CATEGORY या अन्य मुख्य स्ट्रिंग का उपयोग करके किसी भी नए इंटेंट या ब्रॉडकास्ट इंटेंट पैटर्न के अनुसार काम करता हो. या com.android. नेमस्पेस. डिवाइस लागू करने वाले लोगों को 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.एनएफ़सी_PAYMENT_SETTINGS इंटेंट का पालन करना ज़रूरी है.
अगर डिवाइस पर ऐप्लिकेशन लागू करता है, तो उपयोगकर्ता को डिफ़ॉल्ट फ़ोन ऐप्लिकेशन बदलने की अनुमति देने वाला डायलॉग दिखाने के लिए, android.telecom.action.CHANGE_DEFAULT_DIALER के इंटेंट का पालन करना ज़रूरी है android.hardware.telephony .

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

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

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

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

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

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

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

उन ऐप्लिकेशन के लिए नीचे दिए गए नेटिव कोड एपीआई उपलब्ध होने चाहिए जिनमें नेटिव कोड शामिल है:

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 कंप्रेशन)
जेएनआई इंटरफ़ेस
OpenGL के लिए समर्थन, जैसा नीचे बताया गया है

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

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

लागू किए गए डिवाइस पर, गैर-एओएसपी लाइब्रेरी जोड़ी जा सकती हैं और उन्हें तीसरे पक्ष के ऐप्लिकेशन के लिए सीधे एपीआई के तौर पर दिखाया जा सकता है. हालांकि, अतिरिक्त लाइब्रेरी /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 के साथ काम न करने वाला कोई डिवाइस लागू हो, लेकिन उसे ये ज़रूरी शर्तें पूरी करनी होंगी:

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

डिवाइस को लागू करना, अगर Vulkan API के साथ काम करना शामिल है:

vkEnumeratePhysicalDevices कॉल के दौरान एक या उससे ज़्यादा VkPhysicalDevices की शिकायत करनी होगी.
गिनती किए गए हर VkPhysicalDevices में, Vulkan 1.0 API को पूरी तरह से लागू करना ज़रूरी है.
सही 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 कोड पर उपलब्ध रहनी चाहिए. ऐसा उन कार्रवाइयों के लिए, नेटिव सीपीयू सपोर्ट या सॉफ़्टवेयर एम्युलेशन के ज़रिए किया जाना चाहिए:

SWP और SWPB के लिए निर्देश
निर्देश सेट करें
CP15ISB, CP15DSB, और CP15DMB बैरियर कार्रवाइयां

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

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

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

3.4. वेब पर काम करता है

3.4.1. वेबव्यू के साथ काम करने की सुविधा

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

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

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

Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) Build/$(BUILD); wv) AppleWebKit/537.36 (KHTML, जैसे Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36
- $(VERSION) स्ट्रिंग की वैल्यू, android.os.Build.VERSION.रिलीज़ की वैल्यू के बराबर होनी चाहिए.
- $(MODEL) स्ट्रिंग का मान android.os.Build.MODEL के मान के समान होना चाहिए.
- $(BUILD) स्ट्रिंग की वैल्यू, android.os.Build.ID की वैल्यू के बराबर होनी चाहिए.
- $(CHROMIUM_VER) स्ट्रिंग का मान अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट में Chromium का वर्शन होना चाहिए.
- डिवाइस पर लागू होने वाली कार्रवाई से, उपयोगकर्ता एजेंट स्ट्रिंग में मोबाइल को हटाया जा सकता है.

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

3.4.2. इन ब्राउज़र पर काम करता है

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

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

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

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

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

3.5. एपीआई के व्यवहार के साथ काम करने की सुविधा

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

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

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

3.6. एपीआई नाम स्थान

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

java.*
Javax.*
सूरज.*
Android.*
com.android.*

पाबंदी वाले बदलावों में ये शामिल हैं :

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

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

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

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

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

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

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

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

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

3.8. यूज़र इंटरफ़ेस के साथ काम करने की सुविधा

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

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

3.8.2. विजेट

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

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

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

3.8.3. सूचनाएं

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

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

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

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

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

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

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

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

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

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

3.8.4. खोजें

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

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

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

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

3.8.5. टोस्ट

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

3.8.6. थीम

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

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

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

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_वॉलपेपर की जानकारी देना ज़रूरी है.

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

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

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

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

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

3.8.9. इनपुट प्रबंधन

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

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

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

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

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

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

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

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

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

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

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

Android में अलग-अलग मोटाई वाले Roboto 2 फ़ॉन्ट का इस्तेमाल किया जा सकता है. जैसे, Cans- Serif-thin, San-ser-light, San-ser-medium, San- Serif-black, San-ser-condensed, San-s-safe-condensed-light. इन सभी को डिवाइस पर उपलब्ध भाषाओं और लैटिन, ग्रीक, और लैटिन यूनिकोड, यूनिकोड, और लैटिन यूनिकोड, सभी यूनिकोड 7.0 की मुद्रा की रेंज के लिए शामिल करना ज़रूरी है.

3.8.14. मल्टी-विंडो

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

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

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

3.9.1.2 मैनेज की जा रही प्रोफ़ाइल का प्रावधान

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

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

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

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

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

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

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

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

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

3.10. सुलभता

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

डिवाइस पर ये शर्तें लागू होंगी:

Android Automotive को लागू करने पर, डिफ़ॉल्ट Android को लागू करने के तरीके के हिसाब से ही Android सुलभता फ़्रेमवर्क को लागू करना चाहिए.
डिवाइस पर लागू किए जाने वाले (Android Automotive शामिल नहीं) में, डिफ़ॉल्ट Android लागू करने के तरीके के हिसाब से ही Android सुलभता फ़्रेमवर्क लागू करना ज़रूरी है.
डिवाइस पर ये सुविधाएं लागू करें (Android Automotive शामिल नहीं है) में, android.accessibilityservice एपीआई की मदद से तीसरे पक्ष की सुलभता सेवाओं को लागू करना ज़रूरी है.
डिवाइस को लागू करना (Android Automotive को शामिल नहीं किया गया है) के लिए Accessibility Events जनरेट करना ज़रूरी है. साथ ही, इन इवेंट को सभी रजिस्टर किए गए AccessibilityService लागू करने वालों पर डिलीवर करना ज़रूरी है. ऐसा डिफ़ॉल्ट Android लागू करने के तरीके के हिसाब से किया जाता है
डिवाइस को लागू करना (Android Automotive और Android Watch के ऐसे डिवाइस जिनमें ऑडियो आउटपुट शामिल नहीं है), सुलभता सेवाओं को चालू और बंद करने के लिए ऐसा तरीका उपलब्ध कराना ज़रूरी है जिसे लोग आसानी से इस्तेमाल कर सकें. साथ ही, android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS इंटेंट के हिसाब से यह इंटरफ़ेस दिखाना ज़रूरी है.
Android डिवाइस पर ऑडियो आउटपुट को लागू करने का सुझाव दिया जाता है. हम इस बात पर काफ़ी ज़ोर देते हैं कि TalkBack** और स्विच ऐक्सेस की सुलभता सेवाओं (https://github.com/google/talkback) के बराबर या उससे ज़्यादा सुविधाएं देने के लिए, डिवाइस पर सुलभता सेवाएं दें.
ऑडियो आउटपुट वाले Android Watch डिवाइसों पर, सुलभता सेवा उपलब्ध करानी चाहिए. साथ ही, उन डिवाइसों पर ऐसी सुलभता सेवा उपलब्ध करानी चाहिए जिनकी तुलना, TalkBack की सुलभता सेवा (https://github.com/google/talkback) से की जा सके या उसके फ़ंक्शन से की जा सके.
डिवाइस को लागू करने के लिए, अलग-अलग तरह के सेटअप फ़्लो में एक तरीका उपलब्ध कराना चाहिए, ताकि उपयोगकर्ता अपने काम की सुलभता सेवाएं चालू कर सकें. साथ ही, डिवाइस पर फ़ॉन्ट साइज़, डिसप्ले साइज़, और ज़ूम करने के जेस्चर में बदलाव करने के विकल्प भी उपलब्ध होने चाहिए.

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

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

3.11. लिखाई को बोली में बदलना

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

Android Automotive लागू करना:

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

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

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

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

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

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

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

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

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

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

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

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

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

3.12.1.2. नेविगेशन

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

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

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

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

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

3.12.1.4. समय बदलना

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

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

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

3.13. फटाफट सेटिंग

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

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

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

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

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

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

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

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

4. ऐप्लिकेशन पैकेजिंग के साथ काम करती है

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

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

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

5. मल्टीमीडिया कॉन्टेंट के साथ काम करने की सुविधा

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

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

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

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

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

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

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

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

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

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

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

डिकोडिंग को डाउनमिक्सिंग के बिना किया जाता है (उदाहरण के लिए, PCM के पांच चैनलों पर 5.0 AAC स्ट्रीम को डिकोड करना ज़रूरी है, 5.1 AAC स्ट्रीम को PCM के छह चैनलों पर डिकोड करना ज़रूरी है),
डाइनैमिक रेंज का मेटाडेटा, जैसा कि "डाइनैमिक रेंज कंट्रोल (डीआरसी)" में बताया गया है साथ ही, ऑडियो डिकोडर के डाइनैमिक रेंज से जुड़े व्यवहार को कॉन्फ़िगर करने के लिए, android.media.MediaFormat DRC कुंजियों को शामिल किया गया है. AAC DRC कुंजियां, एपीआई 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.hardware.माइक्रोफ़ोन के बारे में जानकारी देते हैं. इसमें Android Watch डिवाइस को लागू करना भी शामिल है.

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_FormatYUV420flex) पर काम करना चाहिए.

फ़ॉर्मैट/कोडेक	एन्कोडर	डिकोडर	जानकारी	इस्तेमाल किए जा सकने वाले फ़ाइल टाइप/ कंटेनर के फ़ॉर्मैट
एच.263	मई	मई		3GPP (.3gp) MPEG-4 (.mp4)
एच.264 एवीसी	ज़रूरी ²	ज़रूरी ²	ज़्यादा जानकारी के लिए, सेक्शन 5.2 और 5.3 देखें	3GPP (.3gp) MPEG-4 (.mp4) MPEG-2 टीएस (.ts, सिर्फ़ AAC ऑडियो, खोजने लायक नहीं, Android 3.0 और उसके बाद वाले वर्शन)
एच.265 एचईवीसी		ज़रूरी ⁵	जानकारी के लिए, सेक्शन 5.3 देखें	MPEG-4 (.mp4)
MPEG-2		हमारा सुझाव दिया जाता है कि ⁶	मुख्य प्रोफ़ाइल	एमपीईजी2-टीएस
एमपीईजी-4 एसपी		ज़रूरी ²		3GPP (.3gp)
VP8 ³	ज़रूरी ² (Android 4.3+)	ज़रूरी ² (Android 2.3.3+)	ज़्यादा जानकारी के लिए, सेक्शन 5.2 और 5.3 देखें	WebM (.webm) Matroska (.mkv, Android 4.0 और इसके बाद के वर्शन) ⁴
वीपी9		ज़रूरी ² (Android 4.4+)	जानकारी के लिए, सेक्शन 5.3 देखें	WebM (.webm) Matroska (.mkv, Android 4.0 और इसके बाद के वर्शन) ⁴

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. वीडियो एन्कोडिंग

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

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

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

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

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

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

5.2.1. एच.263

H.263 एन्कोडर वाले Android डिवाइस को लागू करने के लिए, बेसलाइन प्रोफ़ाइल लेवल 45 पर भी काम करना ज़रूरी है.

5.2.2. एच-264

H.264 कोडेक के साथ Android डिवाइस में काम करने की सुविधा:

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

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

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

5.2.3. वीपी8

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

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

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

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

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

ज़रूरी है कि डिवाइस पर सभी VP8, VP9, H.264, और H.265 कोडेक के लिए, एक ही स्ट्रीम में डाइनैमिक वीडियो रिज़ॉल्यूशन और फ़्रेम रेट को एक ही स्ट्रीम में इस्तेमाल किया जा सके. साथ ही, यह सुविधा डिवाइस पर मौजूद हर कोडेक के साथ काम करने वाले ज़्यादा से ज़्यादा रिज़ॉल्यूशन तक काम करती हो.
Dolby Vision डिकोडर के साथ काम करने वाले टूल—
Dolby Vision-सुविधा के लिए डेटा इकट्ठा करने वाला टूल उपलब्ध कराना ज़रूरी है.
डिवाइस की स्क्रीन पर या किसी स्टैंडर्ड वीडियो आउटपुट पोर्ट पर, Dolby Vision का कॉन्टेंट ठीक से दिखाना ज़रूरी है (जैसे, एचडीएमआई).
अगर Dolby Vision की सुविधा वाले एक एक्सट्रैक्टर टूल का इस्तेमाल किया जा रहा है, तो इसके लिए पुराने सिस्टम के साथ काम करने वाले बेस-लेयर (अगर मौजूद हो) के ट्रैक इंडेक्स को Dolby Vision लेयर के ट्रैक इंडेक्स पर सेट करना ज़रूरी है.

5.3.1. MPEG-2

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

5.3.2. एच.263

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

5.3.3. MPEG-4

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

5.3.4. H.264

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

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

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

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

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

5.3.5. H.265 (HEVC)

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

ज़रूरी है कि ये सुविधाएं नीचे दी गई टेबल में बताए गए तरीके से, मुख्य प्रोफ़ाइल लेवल 3 के मुख्य टियर और एसडी वीडियो डिकोड करने वाली प्रोफ़ाइलों के साथ काम करें.
एचडी डिकोडिंग प्रोफ़ाइलों का इस्तेमाल, नीचे दी गई टेबल में बताए गए तरीके से करना चाहिए.
अगर हार्डवेयर डिकोडर मौजूद है, तो नीचे दी गई टेबल में बताए गए तरीके के मुताबिक एचडी डिकोडिंग प्रोफ़ाइल काम करनी चाहिए.
इसके अलावा, Android Television डिवाइसों के लिए:
एचडी 720 पिक्सल डिकोड करने वाली प्रोफ़ाइल पर काम करना ज़रूरी है.
एचडी 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 ¹ )	60 एफ़पीएस (फ़्रेम प्रति सेकंड)
वीडियो बिटरेट	600 केबीपीएस	1.6 एमबीपीएस	4 एमबीपीएस	5 एमबीपीएस	20 एमबीपीएस

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

5.3.6. वीपी8

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

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

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

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

5.3.7. वीपी9

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

ज़रूरी है कि ये एसडी वीडियो डिकोड करने वाली प्रोफ़ाइलों के साथ काम करते हों. इस बारे में नीचे दी गई टेबल में बताया गया है.
एचडी डिकोडिंग प्रोफ़ाइलों का इस्तेमाल, नीचे दी गई टेबल में बताए गए तरीके से करना चाहिए.
अगर हार्डवेयर डिकोडर मौजूद है, तो नीचे दी गई टेबल में बताए गए तरीके के मुताबिक एचडी डिकोडिंग प्रोफ़ाइल काम करनी चाहिए.
इसके अलावा, Android Television डिवाइसों के लिए:
- एचडी 720 पिक्सल डिकोड करने वाली प्रोफ़ाइल पर काम करना ज़रूरी है.
- एचडी 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 ¹ )	60 एफ़पीएस (फ़्रेम प्रति सेकंड)
वीडियो बिटरेट	600 केबीपीएस	1.6 एमबीपीएस	4 एमबीपीएस	5 एमबीपीएस	20 एमबीपीएस

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

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

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

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

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

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

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

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

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

अगर ऊपर दिए गए सैंपल रेट के लिए कैप्चर करने की सुविधा काम करती है, तो कैप्चर करने के लिए, 16000:22050 या 44100:48000 से ज़्यादा अनुपात में अप-सैंपलिंग का इस्तेमाल करना ज़रूरी है. किसी भी अप-सैंपलिंग या डाउन-सैंपलिंग में एक सही एंटी-एलियाज़िंग फ़िल्टर शामिल होना चाहिए.

5.4.2. आवाज़ पहचानने के लिए कैप्चर करें

android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION ऑडियो सोर्स में, सैंपलिंग रेट 44,100 और 48,000 में से किसी एक पर होना ज़रूरी है.

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

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

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

5.4.3. प्लेबैक को फिर से रूट करने के लिए कैप्चर करें

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

स्ट्रीम_रिंग
स्ट्रीम_ALARM
स्ट्रीम_सूचना

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

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

5.5.1. ऑडियो को चलाने की सुविधा

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

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

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

सैंपलिंग रेट : 24,000, 48,000

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

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

ज़रूरी है कि इफ़ेक्ट इफ़_TYPE_EQUALIZER और इफ़_TYPE_LOUDNESS_ENHANCER को लागू करने के साथ-साथ, AudioEffect की सब-क्लास Equalizer, LoudnessEnhancer के ज़रिए कंट्रोल किया जा सकता हो.
विज़ुअलाइज़र एपीआई को लागू करने में मदद करनी चाहिए. इसे विज़ुअलाइज़र क्लास से कंट्रोल किया जा सकता है.
ऑडियो इफ़ेक्ट की सब-क्लास BasesBoost, EnvironmentalReverb, PresetReverb, और Virtualizer की मदद से कंट्रोल किए जा सकने वाले ACTION_TYPE_BASS_BOOST, इफ़_TYPE_ENV_REVERB, म्.

5.5.3. ऑडियो आउटपुट की आवाज़

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

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

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

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

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

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

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

100 मिलीसेकंड या उससे कम की कोल्ड आउटपुट इंतज़ार का समय
आउटपुट में इंतज़ार का समय 45 मिलीसेकंड या इससे कम होना चाहिए
कोल्ड आउटपुट सिग्नल की गड़बड़ी को कम करें

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

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

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

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

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

HTTP(S) प्रोग्रेसिव स्ट्रीमिंग
सेक्शन 5.1 में दिए गए सभी ज़रूरी कोडेक और कंटेनर फ़ॉर्मैट, एचटीटीपी या एचटीटीपीएस पर काम करने चाहिए
एचटीटीपी लाइव स्ट्रीमिंग ड्राफ़्ट प्रोटोकॉल, वर्शन 7
इन मीडिया सेगमेंट फ़ॉर्मैट का इस्तेमाल किया जाना चाहिए:

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

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

संदर्भ

आवश्यक कोडेक समर्थन

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

आईएसओ 13818

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

H264 एवीसी
एमपीईजी-4 एसपी
MPEG-2

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

ऑडियो कोडेक:

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

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

आईएसओ 13818-7

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

WebVTT

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

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

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

5.8. सुरक्षित मीडिया

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

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

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

एमआईडीआई की सुविधा वाले हार्डवेयर के ट्रांसपोर्ट्स:

यूएसबी होस्ट मोड (सेक्शन 7.7 यूएसबी)
यूएसबी सहायक डिवाइस मोड (सेक्शन 7.7 यूएसबी)
ब्लूटूथ LE पर एमआईडीआई मुख्य भूमिका में काम कर रही है (सेक्शन 7.4.3 ब्लूटूथ)

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

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

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

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

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

इसके अलावा, इस सुविधा के लिए काम करने वाले डिवाइस को लागू करने के लिए:

ऑडियो चालू रहने के दौरान, सीपीयू की परफ़ॉर्मेंस को लंबे समय तक बनाए रखें.
ऑडियो क्लॉक की गड़बड़ी और ड्रिफ़्ट को स्टैंडर्ड समय के हिसाब से कम करें.
जब दोनों चालू हों, तो सीपीयू 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_UN सहयोगी के ज़रिए प्रोसेस नहीं किए गए ऑडियो सोर्स की सहायता रिपोर्ट करने के लिए, डिवाइस को नीचे दी गई सभी ज़रूरी शर्तें पूरी करनी होंगी:

इस डिवाइस को, औसत फ़्रीक्वेंसी रेंज में करीब सपाट आयाम और फ़्रीक्वेंसी की तुलना दिखानी चाहिए: खास तौर पर, 100 हर्ट्ज़ से लेकर 7,000 हर्ट्ज़ तक.
इस डिवाइस का आयाम स्तर कम फ़्रीक्वेंसी की रेंज में होना चाहिए: खास तौर पर, औसत फ़्रीक्वेंसी रेंज की तुलना में ±20 dB से लेकर 5 हर्ट्ज़ से लेकर 100 हर्ट्ज़ तक.
इस डिवाइस का आयाम स्तर उच्च फ़्रीक्वेंसी रेंज में प्रदर्शित होना चाहिए: मिड-फ़्रीक्वेंसी रेंज की तुलना में विशेष रूप से ±30 dB से लेकर 7000 हर्ट्ज़ से 22 किलोहर्ट्ज़ तक.
ऑडियो इनपुट की संवेदनशीलता को इस तरह सेट किया जाना चाहिए कि 94 dB के साउंड प्रेशर लेवल (SPL) पर चलाए जाने वाले 1000 हर्ट्ज़ वाले साइनसोइडल टोन सोर्स से 16 बिट-सैंपल (या फ़्लोटिंग पॉइंट/डबल सटीक सैंपल के लिए -36 dB फ़ुल स्केल) के लिए 520 के आरएमएस के साथ रिस्पॉन्स मिलता है.
एसएनआर > 60 dB (94 dB SPL और सेल्फ़ नॉइज़ के बराबर SPL, A-वेट के बीच का अंतर).
माइक्रोफ़ोन पर 90 dB SPL इनपुट लेवल पर, 1 kHZ के लिए कुल हार्मोनिक डिस्टॉर्शन 1% से कम होना चाहिए.
पाथ में सिर्फ़ सिग्नल प्रोसेसिंग की अनुमति, लेवल मल्टीप्लायर है, जो लेवल को अपनी पसंद की रेंज में ले जाता है. इस लेवल के मल्टीप्लायर की मदद से, सिग्नल पाथ में देरी या इंतज़ार का समय नहीं होना चाहिए.
पाथ में किसी और सिग्नल प्रोसेसिंग की अनुमति नहीं है. जैसे, ऑटोमैटिक गेन कंट्रोल, हाई पास फ़िल्टर या इको रद्द करने की सुविधा. अगर किसी भी वजह से आर्किटेक्चर में कोई सिग्नल प्रोसेसिंग मौजूद है, तो उसे बंद करना ज़रूरी है. साथ ही, उसे बंद करना होगा. साथ ही, सिग्नल को सही तरीके से प्रोसेस करने में कोई देरी या अतिरिक्त इंतज़ार का समय नहीं होना चाहिए.

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

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

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

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

6.1. डेवलपर टूल

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

Android डीबग ब्रिज (adb)
- डिवाइस पर लागू किए गए सभी adb फ़ंक्शन, Android SDK में बताए गए काम करने चाहिए. इनमें dumpsys भी शामिल हैं.
- डिवाइस-साइड adb डीमन डिफ़ॉल्ट रूप से बंद होना चाहिए. साथ ही, Android डीबग ब्रिज को चालू करने के लिए ऐसा तरीका होना चाहिए जिसे उपयोगकर्ता आसानी से ऐक्सेस कर सके. अगर लागू किए गए डिवाइस पर यूएसबी सहायक डिवाइस (जैसे, कीबोर्ड, माउस, मॉनिटर, वेबकैम वगैरह) का इस्तेमाल नहीं किया जाता है, तो उसे लोकल-एरिया नेटवर्क (जैसे कि ईथरनेट या 802.11) के ज़रिए, Android डीबग ब्रिज को लागू करना होगा.
- Android में सुरक्षित adb की सुविधा शामिल है. सुरक्षित adb, पुष्टि किए गए जाने-पहचाने होस्ट पर adb चालू करता है. डिवाइस को लागू करने के लिए सुरक्षित adb का इस्तेमाल करना ज़रूरी है.
Dalvik डीबग मॉनिटर सेवा (डीडीएम)
- डिवाइस पर सुविधाएं लागू करने के लिए, Android SDK में बताए गए सभी डीएमएम की सुविधाएं काम करनी चाहिए.
- ddms, adb का इस्तेमाल करता है, इसलिए ddms के लिए सहायता डिफ़ॉल्ट रूप से बंद होनी चाहिए. हालांकि, जब उपयोगकर्ता ऊपर बताए गए तरीके से Android डीबग ब्रिज को चालू करेगा, तो ddms के लिए सहायता बंद होनी चाहिए.
Monkey लागू करने के तरीके में Monkey फ़्रेमवर्क को शामिल करना होगा और ऐप्लिकेशन के लिए इस्तेमाल करने के लिए इसे उपलब्ध कराना होगा.
SysTrace
- डिवाइस पर सिस्टम को लागू करने के लिए, Android SDK में बताए गए सिस्टम के साथ काम करना ज़रूरी है. 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 को लागू करने के तरीके से मेल खाता हो.

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

7. हार्डवेयर के साथ काम करने की सुविधा

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

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

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

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

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

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

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

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

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

7.1.1.1. स्क्रीन का आकार

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

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

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

साथ ही:

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

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

ऐप्लिकेशन वैकल्पिक रूप से यह बताते हैं कि <supports-screen> के ज़रिए वे कौनसे स्क्रीन साइज़ पर काम करते हैं एट्रिब्यूट की वैल्यू सबमिट करें. डिवाइस को लागू करने के लिए ऐप्लिकेशन का सही तरीके से पालन करना ज़रूरी है' यह सुविधा छोटी, सामान्य, बड़ी, और बड़ी स्क्रीन के लिए भी काम करती है. इसके बारे में Android SDK के दस्तावेज़ में बताया गया है.

7.1.1.2. स्क्रीन का आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7.2.1. कीबोर्ड

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

डिवाइस पर यह सुविधा लागू करना:

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

7.2.2. बिना छुए नेविगेशन

Android Television डिवाइसों पर डी-पैड का काम करना ज़रूरी है.

डिवाइस पर यह सुविधा लागू करना:

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

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

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

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

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

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

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

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

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

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

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

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

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

डिवाइस लागू करने वाले नेविगेशन कुंजियों को स्क्रीन के एक खास हिस्से का इस्तेमाल करना चाहिए, जो ऐप्लिकेशन के लिए उपलब्ध नहीं है और ऐप्लिकेशन के लिए उपलब्ध स्क्रीन के हिस्से को धुंधला नहीं करना चाहिए या उसमें किसी तरह की रुकावट नहीं डालनी चाहिए.
डिवाइस को लागू करने के लिए, उन ऐप्लिकेशन के लिए डिसप्ले का कुछ हिस्सा उपलब्ध कराना ज़रूरी है जो सेक्शन 7.1.1 में बताई गई ज़रूरी शर्तों को पूरा करते हों.
जब ऐप्लिकेशन किसी सिस्टम यूज़र इंटरफ़ेस (यूआई) मोड को तय नहीं करते या system_UI_FLAG_VISIBLE को तय नहीं करते, तब डिवाइस पर नेविगेशन कुंजियां ज़रूर दिखानी चाहिए.
जब ऐप्लिकेशन system_UI_FLAG_LOW_PROFILE के बारे में बताते हैं, तो डिवाइस को लागू करने के तरीके को नेविगेट करने वाली कुंजियों को बिना रुकावट वाले "कम प्रोफ़ाइल" (उदाहरण के लिए कम रोशनी वाले) मोड में पेश करना होगा.
जब ऐप्लिकेशन System_UI_FLAG_HIDE_NAVIGATION के बारे में जानकारी दें, तो डिवाइस पर नेविगेशन कुंजियां छिपानी होंगी.

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

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

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

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

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

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

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

डिवाइस को लागू करने के ऐसे तरीके जो android.hardware.fakeTouch के साथ काम करने के बारे में बताते हैं:

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

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

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

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

7.2.6.1. बटन मैपिंग

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

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

1 KeyEvent

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

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

4 MotionEvent

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

1 MotionEvent

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

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

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

7.3. सेंसर

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

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

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

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

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

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

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

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

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

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

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

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

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

7.3.3. जीपीएस

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

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

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

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

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

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

7.3.5. बैरोमीटर

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

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

7.3.6. Thermometer

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

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

Android Automotive लागू करने के लिए, SENSOR_TYPE_AMBIENT_criteria को वाहन के केबिन के अंदर का तापमान मापना होगा.

7.3.7. फ़ोटोमीटर

डिवाइस में फ़ोटोमीटर (ऐंबियंट लाइट सेंसर) लगाया जा सकता है.

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

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

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

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

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

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

SENSOR_TYPE_ACCELEROMETER
- तापमान मापने की रेंज कम से कम -8 ग्राम और + 8 ग्राम के बीच होनी चाहिए.
- रिज़ॉल्यूशन कम से कम 1024 LSB/G होना चाहिए.
- तापमान मापने की फ़्रीक्वेंसी कम से कम 12.5 हर्ट्ज़ या इससे कम होनी चाहिए.
- तापमान मापने की फ़्रीक्वेंसी ज़्यादा से ज़्यादा 400 हर्ट्ज़ या इससे ज़्यादा होनी चाहिए.
- तापमान मापने के लिए नॉइज़, 400 uG/सेवा हर्ट्ज़ से ज़्यादा नहीं होनी चाहिए.
- इस सेंसर को चालू करने के लिए, कम से कम 3,000 सेंसर इवेंट की बफ़रिंग क्षमता का इस्तेमाल करें.
- बैच में ऊर्जा की खपत 3 मिलीवाट से ज़्यादा नहीं होनी चाहिए.
- 24 घंटे के स्टैटिक डेटासेट से, स्टेशनरी नॉइज़ बायस स्टेबिलिटी होनी चाहिए. इसमें \<15 μg secureHz की संख्या होनी चाहिए.
- तापमान में बदलाव होना चाहिए और तापमान ≤ +/- 1mg / °C होना चाहिए.
- सबसे सही लाइन वाली लाइन होनी चाहिए, जो 0.5% या इससे कम हो. साथ ही, तापमान की संवेदनशीलता के मुकाबले 0.03%/C° तापमान का बदलाव होना चाहिए.
SENSOR_TYPE_GYROSCOPE
- माप की रेंज कम से कम -1,000 और +1000 dps के बीच होनी चाहिए.
- रिज़ॉल्यूशन कम से कम 16 LSB/dps होना चाहिए.
- तापमान मापने की फ़्रीक्वेंसी कम से कम 12.5 हर्ट्ज़ या इससे कम होनी चाहिए.
- तापमान मापने की फ़्रीक्वेंसी ज़्यादा से ज़्यादा 400 हर्ट्ज़ या इससे ज़्यादा होनी चाहिए.
- तापमान मापने के लिए ज़रूरी नॉइज़ 0.014°/s/प्रभावित हर्ट्ज़ से ज़्यादा नहीं होनी चाहिए.
- का एक स्थिर बायस स्थिरता होना चाहिए < 24 घंटे के स्टैटिक डेटासेट से 0.0002 °/s ऐडवांस हर्ट्ज़.
- तापमान में बदलाव होना चाहिए और तापमान ≤ +/- 0.05 °/ s / °C होना चाहिए.
- 0.02% / °C के तापमान के मुकाबले संवेदनशीलता में बदलाव होना चाहिए.
- सबसे सही लाइन वाली लाइन होनी चाहिए, जो 0.2% या इससे कम हो.
- शोर की सघनता ≤ 0.007 °/s/होस्ट हर्ट्ज़ होनी चाहिए.
SENSOR_TYPE_GYROSCOPE_UNCALIBरेट का SENSOR_TYPE_GYROSCOPE के समान है.
SENSOR_TYPE_GEOMAGNETIC_FIELD
- माप की रेंज कम से कम -900 और +900 uT के बीच होनी चाहिए.
- रिज़ॉल्यूशन कम से कम 5 LSB/uT होना चाहिए.
- तापमान मापने की फ़्रीक्वेंसी कम से कम 5 हर्ट्ज़ या इससे कम होनी चाहिए.
- तापमान मापने की फ़्रीक्वेंसी ज़्यादा से ज़्यादा 50 हर्ट्ज़ या इससे ज़्यादा होनी चाहिए.
- तापमान मापने वाला नॉइज़ 0.5 uT से ज़्यादा नहीं होना चाहिए.
इसके अलावा:
- इस सेंसर को चालू करने के लिए, कम से कम 600 सेंसर इवेंट की बफ़रिंग सुविधा का इस्तेमाल करना ज़रूरी है.
SENSOR_TYPE_PRESSURE
- इसकी मेज़रमेंट रेंज कम से कम 300 से 1100 hPa के बीच होनी चाहिए.
- रिज़ॉल्यूशन कम से कम 80 LSB/hPa होना चाहिए.
- तापमान मापने की फ़्रीक्वेंसी कम से कम 1 हर्ट्ज़ या इससे कम होनी चाहिए.
- तापमान मापने की फ़्रीक्वेंसी ज़्यादा से ज़्यादा 10 हर्ट्ज़ या इससे ज़्यादा होनी चाहिए.
- तापमान मापने के लिए नॉइज़, 2 Pa/withHz से ज़्यादा नहीं होनी चाहिए.
- इस सेंसर को चालू करने के लिए, कम से कम 300 सेंसर इवेंट की बफ़रिंग की सुविधा का इस्तेमाल करना ज़रूरी है.
- बैच में ऊर्जा की खपत दो मिलीवाट से कम नहीं होनी चाहिए.
SENSOR_TYPE_GAME_ROTATION_VECTOR
- इस सेंसर को चालू न करने की सुविधा का इस्तेमाल करना ज़रूरी है. इसमें कम से कम 300 सेंसर इवेंट की बफ़रिंग की सुविधा होनी चाहिए.
- बैच में ऊर्जा की खपत 4 मिलीवाट से ज़्यादा नहीं होनी चाहिए.
SENSOR_TYPE_SIGNIFICANT_MOTION
- अगर डिवाइस स्टैटिक हो, तो उसमें ऊर्जा की खपत 0.5 मिलीवाट से ज़्यादा न हो. साथ ही, जब डिवाइस को हिलाया जा रहा हो, तो उसमें ऊर्जा की खपत 1.5 मिलीवाट से ज़्यादा न हो.
SENSOR_TYPE_STEP_DETECTOR
- इस सेंसर को चालू न करने की सुविधा का इस्तेमाल करना ज़रूरी है. इसमें कम से कम 100 सेंसर इवेंट की बफ़रिंग की सुविधा होनी चाहिए.
- अगर डिवाइस स्टैटिक हो, तो उसमें ऊर्जा की खपत 0.5 मिलीवाट से ज़्यादा न हो. वहीं, हिलने-डुलने के दौरान यह 1.5 मिलीवाट से ज़्यादा न हो.
- बैच में ऊर्जा की खपत 4 मिलीवाट से ज़्यादा नहीं होनी चाहिए.
SENSOR_TYPE_STEP_COUNTER
- अगर डिवाइस स्टैटिक हो, तो उसमें ऊर्जा की खपत 0.5 मिलीवाट से ज़्यादा न हो. साथ ही, जब डिवाइस को हिलाया जा रहा हो, तो उसमें ऊर्जा की खपत 1.5 मिलीवाट से ज़्यादा न हो.
SENSOR_TILT_DETECTOR
- अगर डिवाइस स्टैटिक हो, तो उसमें ऊर्जा की खपत 0.5 मिलीवाट से ज़्यादा न हो. वहीं, हिलने-डुलने के दौरान यह 1.5 मिलीवाट से ज़्यादा न हो.

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

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

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

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

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

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

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

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

7.3.11. सिर्फ़ Android Automotive के लिए सेंसर

वाहन संबंधित खास सेंसर की जानकारी android.car.CarSensorManager API में दी गई है .

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

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

7.3.11.2. दिन रात मोड

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

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

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

7.3.11.4. व्हील की स्पीड

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

7.3.12. पोज़ सेंसर

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

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

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

7.4.1. टेलीफ़ोनी

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

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

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

Android Telephony की सेवाओं को लागू करने के लिए, इसमें नंबर ब्लॉक करने की सुविधा के साथ-साथ ये काम भी शामिल होने चाहिए:

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

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

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

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

7.4.2.1. Wi-Fi Direct

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

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

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

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

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

7.4.3. ब्लूटूथ

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

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

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

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

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

ब्लूटूथ कम ऊर्जा वाली सुविधा के साथ-साथ डिवाइस को लागू करना:

हार्डवेयर की सुविधा के बारे में जानकारी देना ज़रूरी है android.hardware.Bluetooth_le.
SDK टूल से जुड़े दस्तावेज़ और android.blue में बताए गए तरीके से, GATT (जेनरिक एट्रिब्यूट प्रोफ़ाइल) पर आधारित ब्लूटूथ एपीआई चालू करना ज़रूरी है.
हमारी सलाह है कि रिज़ॉल्व होने वाले निजी पते (आरपीए) का टाइम आउट 15 मिनट से ज़्यादा न रखें. साथ ही, उपयोगकर्ता की निजता को सुरक्षित रखने के लिए, टाइम आउट पर पते को घुमाएं.
ScanFilter API को लागू करते समय, ब्लूटूथ चिपसेट को फ़िल्टर करने वाले लॉजिक को ऑफ़लोड करने में मदद करें. साथ ही, android. Bluetooth.ब्लूटूथ.. BluetoothAdapter.isOffLoadedFiltering यादें() तरीके का इस्तेमाल करके, फ़िल्टर किए जाने वाले लॉजिक की वैल्यू की सही जानकारी दें.
बैच में स्कैन करने की सुविधा को ब्लूटूथ चिपसेट में ऑफ़लोड करने की सुविधा दी जानी चाहिए. हालांकि, अगर यह सुविधा काम नहीं करती है, तो android.BT. BluetoothAdapter.isOffLoadScanOnBatchingSupported() तरीके की मदद से, 'गलत' की शिकायत करें.
एक से ज़्यादा विज्ञापन दिखाने के लिए, कम से कम चार स्लॉट होने चाहिए. हालांकि, अगर यह सुविधा काम नहीं करती है, तो android. Gemini. BluetoothAdapter.isMultiEditmentSupported() विधि के ज़रिए जब भी क्वेरी की जाए, तो 'गलत' की रिपोर्ट ज़रूर करें.

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

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

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

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

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

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

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

android.hardware.nfc.hcef सुविधा स्थिरांक की रिपोर्ट करना ज़रूरी है.
Android SDK में बताए गए तरीके के मुताबिक, NFCF Card Emulation API लागू करना ज़रूरी है.

इसके अलावा, इन डिवाइसों को लागू करने के लिए, MIFARE टेक्नोलॉजी का इस्तेमाल करने वालों को पढ़ने/लिखने में मदद मिल सकती है.

MIFARE क्लासिक
माइफ़ायर अल्ट्रालाइट
MIFARE Classic पर NDEF

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

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

अगर लागू किए गए किसी डिवाइस में एनएफ़सी हार्डवेयर शामिल नहीं है, तो उसे android.content.pm.PackageManager.hasSystemFeature() तरीके से android.hardware.nfc सुविधा के बारे में जानकारी नहीं देनी चाहिए. साथ ही, Android एनएफ़सी एपीआई को नो-ऑप के रूप में लागू करना ज़रूरी है.

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

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

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

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

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

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

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

आईपीवी6 डिफ़ॉल्ट रूप से चालू होना चाहिए.

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

आईपीवी6 कनेक्टिविटी को डोज़ मोड में बनाए रखना ज़रूरी है.

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

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

7.4.7. डेटा बचाने वाला विकल्प

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

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

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

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

ConnectivityManager.getRestrictBackgroundStatus() के लिए RESTRICT_BACKGROUND_STATUS_DISABLED मान देना होगा
ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED को ब्रॉडकास्ट नहीं करना चाहिए
ज़रूरी है कि आपके पास कोई ऐसी गतिविधि हो जो Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS इंटेंट को हैंडल करती हो, लेकिन उसे नो-ऑप के रूप में लागू किया जा सके.

7.5. कैमरे

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7.6.1. कम से कम मेमोरी और स्टोरेज

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

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

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

कम से कम मेमोरी मान, रेडियो, वीडियो जैसे हार्डवेयर घटकों के लिए पहले से ही समर्पित किसी मेमोरी स्थान के अलावा होने चाहिए और ऐसे ही दूसरे मान कर्नेल के नियंत्रण में नहीं होते हैं.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7.6.3. डिवाइस का स्टोरेज

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

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

7.7. यूएसबी

डिवाइस को लागू करने के लिए, यूएसबी सहायक डिवाइस (जैसे, कीबोर्ड, माउस, मॉनिटर, वेबकैम वगैरह) का इस्तेमाल किया जाना चाहिए. साथ ही, यूएसबी होस्ट मोड के साथ भी काम करना चाहिए.

7.7.1. यूएसबी सहायक डिवाइस (जैसे, कीबोर्ड, माउस, मॉनिटर, वेबकैम वगैरह) मोड

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

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

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

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

अगर डिवाइस पर यूएसबी 3.1 काम करता है, तो टाइप-सी यूएसबी पोर्ट का इस्तेमाल करना चाहिए.
इसमें नॉन-स्टैंडर्ड पोर्ट फ़ॉर्म फ़ैक्टर का इस्तेमाल किया जा सकता है. हालांकि, अगर ऐसा करना ज़रूरी है, तो पोर्ट को स्टैंडर्ड टाइप-ए या टाइप-सी यूएसबी पोर्ट के हिसाब से ढालने वाली केबल या केबल का इस्तेमाल करें.
माइक्रो-एबी यूएसबी पोर्ट का इस्तेमाल किया जा सकता है. अगर ऐसा है, तो पोर्ट को स्टैंडर्ड टाइप-ए या टाइप-सी यूएसबी पोर्ट से जुड़ने वाली केबल या केबल की मदद से शिप किया जाना चाहिए.
हमारा सुझाव है कि यूएसबी ऑडियो क्लास को लागू करने के लिए, हमारा सुझाव ज़रूर दिया जाता है. इस प्रक्रिया के बारे में Android SDK के दस्तावेज़ में बताया गया है.
Android SDK में बताए गए तरीके के मुताबिक, Android यूएसबी होस्ट एपीआई को लागू करना ज़रूरी है. साथ ही, हार्डवेयर सुविधा android.hardware.usb.host के साथ काम करने की जानकारी देना भी ज़रूरी है.
होस्ट मोड में होने पर, डिवाइस को चार्ज करने की सुविधा होनी चाहिए; [यूएसबी टाइप-सी केबल और कनेक्टर स्पेसिफ़िकेशन रिविज़न 1.2] (http://www.usb.org/developers/docs/usb_31_021517.zip) के 'खत्म होने के पैरामीटर' सेक्शन में बताए गए, कम से कम 1.5A का सोर्स करते हुए या यूएसबी डाउनस्ट्रीम पोर्ट(सीडीपी) चार्जिंग डाउनस्ट्रीम पोर्ट(सीडीपी) की मौजूदा रेंज का इस्तेमाल करके.
इस बात का खास तौर पर सुझाव दिया जाता है कि DisplayPort के साथ काम करने वाले यूएसबी टाइप-सी डिवाइसों पर, यूएसबी सुपरस्पीड डेटा रेट की सुविधा काम करनी चाहिए. साथ ही, डेटा और पावर रोल बदलने के लिए, पावर डिलीवरी के साथ-साथ इस बात का भी खास तौर पर सुझाव दिया जाता है.
किसी भी टाइप-ए या टाइप-एबी पोर्ट वाले डिवाइसों के लिए, इस पोर्ट को टाइप-सी रिसेप्टेकल में बदलने वाला अडैप्टर इस्तेमाल नहीं करना चाहिए.
अगर स्टोरेज ऐक्सेस फ़्रेमवर्क (SAF) के साथ काम करता है, तो रिमोट तरीके से कनेक्ट किए गए किसी भी एमटीपी (मीडिया ट्रांसफ़र प्रोटोकॉल) डिवाइस की पहचान करनी चाहिए. साथ ही, ACTION_GET_CONTENT , ACTION_OPEN_DOCUMENT , और ACTION_CREATE_DOCUMENT इंटेंट के ज़रिए उनके कॉन्टेंट को ऐक्सेस करना चाहिए.
अगर टाइप-सी यूएसबी पोर्ट और सहायक डिवाइस (जैसे, कीबोर्ड, माउस, मॉनिटर, वेबकैम वगैरह) का इस्तेमाल किया जा रहा है, तो यूएसबी टाइप-सी स्पेसिफ़िकेशन (सेक्शन 4.5.1.3.3) के मुताबिक ड्यूअल रोल पोर्ट फ़ंक्शन को लागू करें.
अगर ड्यूअल रोल पोर्ट की सुविधा काम करती है, तो ऐसे मॉडल को आज़माएं* को लागू करें जो डिवाइस के नाप या आकार के लिए सबसे सही हो. उदाहरण के लिए, हैंडहेल्ड डिवाइस में Tri.SNK मॉडल लागू करना चाहिए.

7.8. ऑडियो

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

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

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

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

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

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

हेडसेट या बाहरी स्पीकर के रूप में किसी ऑडियो आउटपुट सहायक डिवाइस के लिए, स्पीकर या ऑडियो/मल्टीमीडिया आउटपुट पोर्ट के साथ डिवाइस को लागू करना:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8.1. उपयोगकर्ता अनुभव को लगातार बनाए रखना

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

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

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

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

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

8.3. पावर सेविंग मोड

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

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

8.4. पावर कंज़म्पशन अकाउंटिंग

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

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

8.5. एक ही तरह की परफ़ॉर्मेंस

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

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

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

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

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

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

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

9.1. अनुमतियां

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

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

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

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

9.2. यूआईडी और प्रोसेस आइसोलेशन

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

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

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

9.4. वैकल्पिक एक्ज़ीक्यूशन एनवायरमेंट

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

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

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

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

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

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

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

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

9.5. बहु-उपयोगकर्ता सहायता

यह सुविधा, सभी तरह के डिवाइसों के लिए ज़रूरी नहीं है.

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

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

9.6. प्रीमियम एसएमएस से जुड़ी चेतावनी

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

9.7. Kernel सुरक्षा सुविधाएँ

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

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

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

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

डिवाइस पर यह सुविधा लागू करना:

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

डिवाइस को लागू करने के लिए, अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट के System/sepolicy फ़ोल्डर में दी गई SELinux नीति को लागू करना चाहिए. साथ ही, इस नीति में डिवाइस के हिसाब से खास तौर पर बने उनके कॉन्फ़िगरेशन के अलावा कुछ और जोड़ा जाना चाहिए. डिवाइस लागू करने का तरीका, अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट के साथ काम करना चाहिए.

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

9.8. निजता

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

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

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

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

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

9.9. डेटा स्टोरेज सुरक्षित करने का तरीका

यह विकल्प, सुरक्षित लॉक स्क्रीन के बिना Android डिवाइस इस्तेमाल करने के लिए ज़रूरी नहीं है.

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

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

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

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

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

9.9.2. फ़ाइल आधारित एन्क्रिप्शन

एफ़बीई की सुविधा देने वाले डिवाइस को लागू करना:

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

CE और DE स्टोरेज एरिया की सुरक्षा करने वाली कुंजियां:

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

अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट, Linux कर्नेल ext4 एन्क्रिप्शन सुविधा के आधार पर, इस सुविधा को प्राथमिकता देता है.

9.9.3. डिस्क को पूरी तरह सुरक्षित (सुरक्षित) करने का तरीका

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

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

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

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

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

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

अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट, Linux कर्नेल सुविधा dm-verity के आधार पर इस सुविधा को पसंदीदा तरीके से लागू करने की सुविधा देता है.

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

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

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

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

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

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

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

9.11.1. लॉक स्क्रीन को लॉक करें

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

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

9.12. डेटा हटाना

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

सिस्टम की इमेज
ऑपरेटिंग सिस्टम में मौजूद ऐसी फ़ाइलें जिन्हें सिस्टम इमेज के लिए ज़रूरी है

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

डिवाइस तेज़ी से डेटा वाइप कर सकते हैं, जिससे लॉजिकल डेटा हमेशा के लिए मिट जाता है.

9.13. सुरक्षित बूट मोड

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

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

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

9.14. ऑटोमोटिव व्हीकल सिस्टम आइसोलेशन

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

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

10. सॉफ़्टवेयर के साथ काम करने से जुड़ी जांच

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

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

10.1. कंपैटबिलिटी टेस्ट सुइट

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

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

10.2. सीटीएस वेरिफ़ायर

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

12.1. बदलावों का लॉग देखने से जुड़ी सलाह

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

सीडीडी
साथ काम करने की ज़रूरी शर्तों में बड़े बदलाव.
डॉक्स
कॉस्मेटिक या बिल्डिंग से जुड़े बदलाव.

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

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

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