"आवश्यक", "नहीं होना चाहिए", "आवश्यक", "होगा", "नहीं होगा", "चाहिए", "नहीं होना चाहिए", "अनुशंसित", "हो सकता है" और "वैकल्पिक" का उपयोग IETF मानक के अनुसार है RFC2119 [ संसाधन, 1 ] में परिभाषित।

जैसा कि इस दस्तावेज़ में उपयोग किया गया है, "डिवाइस कार्यान्वयनकर्ता" या "कार्यान्वयनकर्ता" एक व्यक्ति या संगठन है जो एंड्रॉइड 4.2 पर चलने वाला हार्डवेयर/सॉफ़्टवेयर समाधान विकसित कर रहा है। "डिवाइस कार्यान्वयन" या "कार्यान्वयन" इस प्रकार विकसित हार्डवेयर/सॉफ़्टवेयर समाधान है।

एंड्रॉइड 4.2 के साथ संगत माने जाने के लिए, डिवाइस कार्यान्वयन को इस संगतता परिभाषा में प्रस्तुत आवश्यकताओं को पूरा करना होगा, जिसमें संदर्भ के माध्यम से शामिल कोई भी दस्तावेज़ शामिल है।

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

इस कारण से, एंड्रॉइड ओपन सोर्स प्रोजेक्ट [ संसाधन, 3 ] एंड्रॉइड का संदर्भ और पसंदीदा कार्यान्वयन दोनों है। डिवाइस कार्यान्वयनकर्ताओं को अपने कार्यान्वयन को एंड्रॉइड ओपन सोर्स प्रोजेक्ट से उपलब्ध "अपस्ट्रीम" स्रोत कोड पर यथासंभव अधिकतम सीमा तक आधारित करने के लिए दृढ़ता से प्रोत्साहित किया जाता है। जबकि कुछ घटकों को काल्पनिक रूप से वैकल्पिक कार्यान्वयन के साथ प्रतिस्थापित किया जा सकता है, इस अभ्यास को दृढ़ता से हतोत्साहित किया जाता है, क्योंकि सॉफ्टवेयर परीक्षण पास करना काफी अधिक कठिन हो जाएगा। यह कार्यान्वयनकर्ता की जिम्मेदारी है कि वह संगतता परीक्षण सूट सहित और उससे परे मानक एंड्रॉइड कार्यान्वयन के साथ पूर्ण व्यवहारिक अनुकूलता सुनिश्चित करे। अंत में, ध्यान दें कि कुछ घटक प्रतिस्थापन और संशोधन इस दस्तावेज़ द्वारा स्पष्ट रूप से निषिद्ध हैं।

2. संसाधन

IETF RFC2119 आवश्यकता स्तर: http://www.ietf.org/rfc/rfc2119.txt

एंड्रॉइड संगतता कार्यक्रम अवलोकन: http://source.android.com/docs/compatibility/index.html

एंड्रॉइड ओपन सोर्स प्रोजेक्ट: http://source.android.com/

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

Android अनुमतियाँ संदर्भ: http://developer.android.com/reference/android/Manifest.permission.html

android.os.Build संदर्भ: http://developer.android.com/reference/android/os/Build.html

Android 4.2 अनुमत संस्करण स्ट्रिंग: http://source.android.com/docs/compatibility/4.2/versions.html

रेंडरस्क्रिप्ट: http://developer.android.com/guide/topics/graphics/renderscript.html

हार्डवेयर त्वरण: http://developer.android.com/guide/topics/graphics/hardware-accel.html

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

HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/

HTML5 ऑफ़लाइन क्षमताएं: http://dev.w3.org/html5/spec/Overview.html#offline

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

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

HTML5/W3C वेबडेटाबेस API: http://www.w3.org/TR/webdatabase/

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

डाल्विक वर्चुअल मशीन विशिष्टता: एंड्रॉइड स्रोत कोड में दल्विक/डॉक्स पर उपलब्ध है

ऐपविजेट्स: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html

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

एप्लिकेशन संसाधन: http://code.google.com/android/reference/available-resources.html

स्टेटस बार आइकन स्टाइल गाइड: http://developer.android.com/guide/practices/ui_guidelines/icon_design_status_bar.html

खोज प्रबंधक: http://developer.android.com/reference/android/app/SearchManager.html

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

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

आर.स्टाइल क्लास: http://developer.android.com/reference/android/R.style.html

लाइव वॉलपेपर: https://android-developers.googleblog.com/2010/02/live-wallpapers.html

Android डिवाइस प्रशासन: http://developer.android.com/guide/topics/admin/device-admin.html

डिवाइसपॉलिसीमैनेजर संदर्भ: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html

एंड्रॉइड एक्सेसिबिलिटी सर्विस एपीआई: http://developer.android.com/reference/android/accessibilityservice/package-summary.html

एंड्रॉइड एक्सेसिबिलिटी एपीआई: http://developer.android.com/reference/android/view/accessibility/package-summary.html

आंखें निःशुल्क परियोजना: http://code.google.com/p/eyes-free

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

संदर्भ उपकरण दस्तावेज़ीकरण (एडीबी, एएपीटी, डीडीएमएस, सिस्ट्रेस के लिए): http://developer.android.com/guide/developing/tools/index.html

एंड्रॉइड एपीके फ़ाइल विवरण: http://developer.android.com/guide/topics/fundamentals.html

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

बंदर परीक्षण उपकरण: https://developer.android.com/studio/test/other-testing-tools/monkey

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

एकाधिक स्क्रीन का समर्थन: http://developer.android.com/guide/practices/screens_support.html

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

android.content.res.कॉन्फ़िगरेशन: http://developer.android.com/reference/android/content/res/Configuration.html

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

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

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

मिफेयर MF1S503X: http://www.nxp.com/documents/data_ शीट/MF1S503x.pdf

मिफेयर MF1S703X: http://www.nxp.com/documents/data_ शीट/MF1S703x.pdf

मिफेयर MF0ICU1: http://www.nxp.com/documents/data_ शीट/MF0ICU1.pdf

मिफेयर MF0ICU2: http://www.nxp.com/documents/short_data_ शीट/MF0ICU2_SDS.pdf

मिफेयर AN130511: http://www.nxp.com/documents/application_note/AN130511.pdf

मिफेयर AN130411: http://www.nxp.com/documents/application_note/AN130411.pdf

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

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

एंड्रॉइड ओपन एक्सेसरीज: http://developer.android.com/guide/topics/usb/accessory.html

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

Android सुरक्षा और अनुमतियाँ संदर्भ: http://developer.android.com/guide/topics/security/security.html

Android के लिए ऐप्स: http://code.google.com/p/apps-for-android

एंड्रॉइड डाउनलोडमैनेजर: http://developer.android.com/reference/android/app/DownloadManager.html

Android फ़ाइल स्थानांतरण: http://www.android.com/filetransfer

एंड्रॉइड मीडिया प्रारूप: http://developer.android.com/guide/appendix/media-formats.html

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

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

एनएफसी का उपयोग करके ब्लूटूथ सुरक्षित सरल युग्मन: http://www.nfc-forum.org/resources/AppDocs/NFCForum_AD_BTSSP_1_0.pdf

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

कार्रवाई सहायता: http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST

यूएसबी चार्जिंग विशिष्टता: http://www.usb.org/developers/devclass_docs/USB_Battery_Charging_1.2.pdf

एंड्रॉइड बीम: http://developer.android.com/guide/topics/nfc/nfc.html

Android USB ऑडियो: http://developer.android.com/reference/android/hardware/usb/UsbConstents.html#USB_CLASS_AUDIO

एंड्रॉइड एनएफसी शेयरिंग सेटिंग्स: http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS

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

लॉक और होम स्क्रीन विजेट: http://developer.android.com/reference/android/appwidget/AppWidgetProviderInfo.html

उपयोगकर्ता प्रबंधक संदर्भ: http://developer.android.com/reference/android/os/UserManager.html

बाहरी संग्रहण संदर्भ: https://source.android.com/docs/core/storage

बाहरी संग्रहण एपीआई: http://developer.android.com/reference/android/os/Environment.html

एसएमएस शॉर्ट कोड: http://en.wikipedia.org/wiki/Short_code

मीडिया रिमोट कंट्रोल क्लाइंट: http://developer.android.com/reference/android/media/RemoteControlClient.html

प्रदर्शन प्रबंधक: http://developer.android.com/reference/android/hardware/display/DisplayManager.html

सपने: http://developer.android.com/reference/android/service/dreams/DreamService.html

एंड्रॉइड एप्लिकेशन डेवलपमेंट-संबंधित सेटिंग्स: http://developer.android.com/reference/android/provider/Settings.html#ACTION_APPLICATION_DEVELOPMENT_SETTINGS

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

इनमें से कई संसाधन प्रत्यक्ष या अप्रत्यक्ष रूप से एंड्रॉइड 4.2 एसडीके से प्राप्त किए गए हैं, और कार्यात्मक रूप से उस एसडीके के दस्तावेज़ में दी गई जानकारी के समान होंगे। किसी भी मामले में जहां यह संगतता परिभाषा या संगतता परीक्षण सूट एसडीके दस्तावेज़ीकरण से असहमत है, एसडीके दस्तावेज़ीकरण को आधिकारिक माना जाता है। ऊपर शामिल संदर्भों में प्रदान किए गए किसी भी तकनीकी विवरण को इस संगतता परिभाषा का हिस्सा माना जाता है।

3. सॉफ्टवेयर

3.1. प्रबंधित एपीआई संगतता

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

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

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

3.2. सॉफ्ट एपीआई संगतता

धारा 3.1 से प्रबंधित एपीआई के अलावा, एंड्रॉइड में एक महत्वपूर्ण रनटाइम-केवल "सॉफ्ट" एपीआई भी शामिल है, जैसे कि इरादे, अनुमतियां और एंड्रॉइड अनुप्रयोगों के समान पहलू जिन्हें एप्लिकेशन संकलन समय पर लागू नहीं किया जा सकता है।

3.2.1. अनुमतियां

डिवाइस कार्यान्वयनकर्ताओं को अनुमति संदर्भ पृष्ठ [ संसाधन, 5 ] द्वारा प्रलेखित सभी अनुमति स्थिरांकों का समर्थन और कार्यान्वयन करना चाहिए। ध्यान दें कि धारा 10 एंड्रॉइड सुरक्षा मॉडल से संबंधित अतिरिक्त आवश्यकताओं को सूचीबद्ध करती है।

3.2.2. पैरामीटर बनाएं

एंड्रॉइड एपीआई में android.os.Build क्लास [ संसाधन, 6 ] पर कई स्थिरांक शामिल हैं जिनका उद्देश्य वर्तमान डिवाइस का वर्णन करना है। सभी डिवाइस कार्यान्वयनों में सुसंगत, सार्थक मान प्रदान करने के लिए, नीचे दी गई तालिका में इन मूल्यों के प्रारूपों पर अतिरिक्त प्रतिबंध शामिल हैं जिनके लिए डिवाइस कार्यान्वयन को अनुरूप होना चाहिए।

पैरामीटर	टिप्पणियाँ
android.os.Build.VERSION.रिलीज़	मानव-पठनीय प्रारूप में वर्तमान में क्रियान्वित एंड्रॉइड सिस्टम का संस्करण। इस फ़ील्ड में [ संसाधन, 7 ] में परिभाषित स्ट्रिंग मानों में से एक होना चाहिए।
android.os.Build.VERSION.SDK	वर्तमान में क्रियान्वित एंड्रॉइड सिस्टम का संस्करण, तीसरे पक्ष के एप्लिकेशन कोड के लिए सुलभ प्रारूप में। एंड्रॉइड 4.2 के लिए, इस फ़ील्ड का पूर्णांक मान 17 होना चाहिए।
android.os.Build.VERSION.SDK_INT	वर्तमान में क्रियान्वित एंड्रॉइड सिस्टम का संस्करण, तीसरे पक्ष के एप्लिकेशन कोड के लिए सुलभ प्रारूप में। एंड्रॉइड 4.2 के लिए, इस फ़ील्ड का पूर्णांक मान 17 होना चाहिए।
android.os.Build.version.incremental	मानव-पठनीय प्रारूप में वर्तमान में निष्पादित एंड्रॉइड सिस्टम के विशिष्ट निर्माण को निर्दिष्ट करने वाले डिवाइस कार्यान्वयनकर्ता द्वारा चुना गया मान। अंतिम उपयोगकर्ताओं को उपलब्ध कराए गए विभिन्न बिल्डों के लिए इस मान का पुन: उपयोग नहीं किया जाना चाहिए। इस फ़ील्ड का एक विशिष्ट उपयोग यह इंगित करना है कि बिल्ड उत्पन्न करने के लिए किस बिल्ड नंबर या स्रोत-नियंत्रण परिवर्तन पहचानकर्ता का उपयोग किया गया था। इस फ़ील्ड के विशिष्ट प्रारूप पर कोई आवश्यकता नहीं है, सिवाय इसके कि यह शून्य या खाली स्ट्रिंग ("") नहीं होना चाहिए।
android.os.Build.BOARD	मानव-पठनीय प्रारूप में डिवाइस द्वारा उपयोग किए जाने वाले विशिष्ट आंतरिक हार्डवेयर की पहचान करने वाले डिवाइस कार्यान्वयनकर्ता द्वारा चुना गया मान। इस फ़ील्ड का संभावित उपयोग डिवाइस को पावर देने वाले बोर्ड के विशिष्ट संशोधन को इंगित करना है। इस फ़ील्ड का मान 7-बिट ASCII के रूप में एन्कोड करने योग्य होना चाहिए और नियमित अभिव्यक्ति `"^[a-zA-Z0-9.,_-]+$"` मेल खाना चाहिए।
android.os.Build.ब्रांड	डिवाइस कार्यान्वयनकर्ता द्वारा मानव-पठनीय प्रारूप में डिवाइस का उत्पादन करने वाली कंपनी, संगठन, व्यक्ति आदि के नाम की पहचान करते हुए चुना गया मूल्य। इस फ़ील्ड का संभावित उपयोग डिवाइस बेचने वाले OEM और/या वाहक को इंगित करना है। इस फ़ील्ड का मान 7-बिट ASCII के रूप में एन्कोड करने योग्य होना चाहिए और नियमित अभिव्यक्ति `"^[a-zA-Z0-9.,_-]+$"` मेल खाना चाहिए।
android.os.Build.CPU_ABI	मूल कोड के निर्देश सेट का नाम (सीपीयू प्रकार + एबीआई कन्वेंशन)। धारा 3.3 देखें: मूल एपीआई संगतता ।
android.os.Build.CPU_ABI2	मूल कोड के दूसरे निर्देश सेट (सीपीयू प्रकार + एबीआई कन्वेंशन) का नाम। धारा 3.3 देखें: मूल एपीआई संगतता ।
android.os.Build.DEVICE	डिवाइस कार्यान्वयनकर्ता द्वारा डिवाइस के विशिष्ट कॉन्फ़िगरेशन या बॉडी के संशोधन (कभी-कभी "औद्योगिक डिज़ाइन" कहा जाता है) की पहचान करने के लिए चुना गया मान। इस फ़ील्ड का मान 7-बिट ASCII के रूप में एन्कोड करने योग्य होना चाहिए और नियमित अभिव्यक्ति `"^[a-zA-Z0-9.,_-]+$"` मेल खाना चाहिए।
android.os.Build.FINGERPRINT	एक स्ट्रिंग जो विशिष्ट रूप से इस निर्माण की पहचान करती है। यह यथोचित रूप से मानव-पठनीय होना चाहिए। इसे इस टेम्पलेट का पालन करना होगा: `$(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)` उदाहरण के लिए: `acme/mydevice/generic:4.2/JRN53/3359:userdebug/test-keys` फिंगरप्रिंट में रिक्त स्थान वाले अक्षर शामिल नहीं होने चाहिए। यदि ऊपर दिए गए टेम्प्लेट में शामिल अन्य फ़ील्ड में व्हाइटस्पेस वर्ण हैं, तो उन्हें बिल्ड फ़िंगरप्रिंट में किसी अन्य वर्ण, जैसे अंडरस्कोर ("_") वर्ण से प्रतिस्थापित किया जाना चाहिए। इस फ़ील्ड का मान 7-बिट ASCII के रूप में एन्कोड करने योग्य होना चाहिए।
android.os.Build.हार्डवेयर	हार्डवेयर का नाम (कर्नेल कमांड लाइन या /proc से)। यह यथोचित रूप से मानव-पठनीय होना चाहिए। इस फ़ील्ड का मान 7-बिट ASCII के रूप में एन्कोड करने योग्य होना चाहिए और नियमित अभिव्यक्ति `"^[a-zA-Z0-9.,_-]+$"` मेल खाना चाहिए।
android.os.Build.HOST	एक स्ट्रिंग जो विशिष्ट रूप से मानव पठनीय प्रारूप में उस होस्ट की पहचान करती है जिस पर निर्माण किया गया था। इस फ़ील्ड के विशिष्ट प्रारूप पर कोई आवश्यकता नहीं है, सिवाय इसके कि यह शून्य या खाली स्ट्रिंग ("") नहीं होना चाहिए।
android.os.Build.ID	मानव पठनीय प्रारूप में एक विशिष्ट रिलीज़ को संदर्भित करने के लिए डिवाइस कार्यान्वयनकर्ता द्वारा चुना गया एक पहचानकर्ता। यह फ़ील्ड android.os.Build.VERSION.INCREMENTAL के समान हो सकती है, लेकिन अंतिम उपयोगकर्ताओं के लिए सॉफ़्टवेयर बिल्ड के बीच अंतर करने के लिए पर्याप्त रूप से सार्थक मूल्य होना चाहिए। इस फ़ील्ड का मान 7-बिट ASCII के रूप में एन्कोड करने योग्य होना चाहिए और नियमित अभिव्यक्ति `"^[a-zA-Z0-9.,_-]+$"` मेल खाना चाहिए।
android.os.Build.निर्माता	उत्पाद के मूल उपकरण निर्माता (ओईएम) का व्यापार नाम। इस फ़ील्ड के विशिष्ट प्रारूप पर कोई आवश्यकता नहीं है, सिवाय इसके कि यह शून्य या खाली स्ट्रिंग ("") नहीं होना चाहिए।
android.os.Build.MODEL	डिवाइस कार्यान्वयनकर्ता द्वारा चुना गया एक मान जिसमें अंतिम उपयोगकर्ता को ज्ञात डिवाइस का नाम शामिल होता है। यह वही नाम होना चाहिए जिसके तहत डिवाइस का विपणन किया जाता है और अंतिम उपयोगकर्ताओं को बेचा जाता है। इस फ़ील्ड के विशिष्ट प्रारूप पर कोई आवश्यकता नहीं है, सिवाय इसके कि यह शून्य या खाली स्ट्रिंग ("") नहीं होना चाहिए।
android.os.Build.PRODUCT	डिवाइस कार्यान्वयनकर्ता द्वारा चुना गया एक मान जिसमें उत्पाद का विकास नाम या कोड नाम (SKU) होता है। मानव-पठनीय होना चाहिए, लेकिन अंतिम उपयोगकर्ताओं द्वारा देखने के लिए आवश्यक नहीं है। इस फ़ील्ड का मान 7-बिट ASCII के रूप में एन्कोड करने योग्य होना चाहिए और नियमित अभिव्यक्ति `"^[a-zA-Z0-9.,_-]+$"` मेल खाना चाहिए।
android.os.Build.SERIAL	एक हार्डवेयर सीरियल नंबर, यदि उपलब्ध हो। इस फ़ील्ड का मान 7-बिट ASCII के रूप में एन्कोड करने योग्य होना चाहिए और नियमित अभिव्यक्ति `"^([a-zA-Z0-9]{0,20})$"` मेल खाना चाहिए।
android.os.Build.TAGS	डिवाइस कार्यान्वयनकर्ता द्वारा चुने गए टैग की अल्पविराम से अलग की गई सूची जो बिल्ड को और अलग करती है। उदाहरण के लिए, "अहस्ताक्षरित, डीबग"। इस फ़ील्ड का मान 7-बिट ASCII के रूप में एन्कोड करने योग्य होना चाहिए और नियमित अभिव्यक्ति `"^[a-zA-Z0-9.,_-]+$"` मेल खाना चाहिए।
android.os.Build.TIME	निर्माण कब हुआ, इसके टाइमस्टैम्प को दर्शाने वाला मान।
android.os.Build.TYPE	बिल्ड के रनटाइम कॉन्फ़िगरेशन को निर्दिष्ट करने वाले डिवाइस कार्यान्वयनकर्ता द्वारा चुना गया मान। इस फ़ील्ड में तीन विशिष्ट एंड्रॉइड रनटाइम कॉन्फ़िगरेशन के अनुरूप मानों में से एक होना चाहिए: "उपयोगकर्ता", "उपयोगकर्ताडेबग", या "इंग्लैंड"। इस फ़ील्ड का मान 7-बिट ASCII के रूप में एन्कोड करने योग्य होना चाहिए और नियमित अभिव्यक्ति `"^[a-zA-Z0-9.,_-]+$"` मेल खाना चाहिए।
android.os.Build.USER	उपयोगकर्ता (या स्वचालित उपयोगकर्ता) का नाम या उपयोगकर्ता आईडी जिसने बिल्ड तैयार किया। इस फ़ील्ड के विशिष्ट प्रारूप पर कोई आवश्यकता नहीं है, सिवाय इसके कि यह शून्य या खाली स्ट्रिंग ("") नहीं होना चाहिए।

3.2.3. आशय अनुकूलता

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

3.2.3.1. मुख्य अनुप्रयोग उद्देश्य

एंड्रॉइड अपस्ट्रीम प्रोजेक्ट कई मुख्य अनुप्रयोगों को परिभाषित करता है, जैसे संपर्क, कैलेंडर, फोटो गैलरी, म्यूजिक प्लेयर इत्यादि। डिवाइस कार्यान्वयनकर्ता इन अनुप्रयोगों को वैकल्पिक संस्करणों से बदल सकते हैं।

हालाँकि, ऐसे किसी भी वैकल्पिक संस्करण को अपस्ट्रीम प्रोजेक्ट द्वारा प्रदान किए गए समान इंटेंट पैटर्न का सम्मान करना चाहिए। उदाहरण के लिए, यदि किसी डिवाइस में वैकल्पिक म्यूजिक प्लेयर है, तो उसे गाना चुनने के लिए तीसरे पक्ष के एप्लिकेशन द्वारा जारी किए गए इंटेंट पैटर्न का पालन करना होगा।

निम्नलिखित एप्लिकेशन को मुख्य एंड्रॉइड सिस्टम एप्लिकेशन माना जाता है:

मेज घड़ी
ब्राउज़र
पंचांग
संपर्क
गैलरी
वैश्विक खोज
लांचर
संगीत
समायोजन

मुख्य एंड्रॉइड सिस्टम अनुप्रयोगों में विभिन्न गतिविधि, या सेवा घटक शामिल होते हैं जिन्हें "सार्वजनिक" माना जाता है। अर्थात्, विशेषता "एंड्रॉइड:एक्सपोर्टेड" अनुपस्थित हो सकती है, या उसका मान "सही" हो सकता है।

कोर एंड्रॉइड सिस्टम ऐप्स में से एक में परिभाषित प्रत्येक गतिविधि या सेवा के लिए जिसे एंड्रॉइड के माध्यम से गैर-सार्वजनिक के रूप में चिह्नित नहीं किया गया है: "गलत" मान के साथ निर्यातित विशेषता, डिवाइस कार्यान्वयन में समान इरादे फ़िल्टर को लागू करने वाले समान प्रकार का एक घटक शामिल होना चाहिए कोर एंड्रॉइड सिस्टम ऐप के रूप में पैटर्न।

दूसरे शब्दों में, एक डिवाइस कार्यान्वयन कोर एंड्रॉइड सिस्टम ऐप्स को प्रतिस्थापित कर सकता है; हालाँकि, यदि ऐसा होता है, तो डिवाइस कार्यान्वयन को प्रतिस्थापित किए जा रहे प्रत्येक कोर एंड्रॉइड सिस्टम ऐप द्वारा परिभाषित सभी इंटेंट पैटर्न का समर्थन करना होगा।

3.2.3.2. इरादा ओवरराइड करता है

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

हालाँकि, यदि डिफ़ॉल्ट गतिविधि डेटा यूआरआई के लिए अधिक विशिष्ट फ़िल्टर प्रदान करती है, तो डिवाइस कार्यान्वयन विशिष्ट यूआरआई पैटर्न (उदाहरण के लिए http://play.google.com) के लिए डिफ़ॉल्ट गतिविधियाँ प्रदान कर सकता है। उदाहरण के लिए, डेटा यूआरआई "http://www.android.com" निर्दिष्ट करने वाला एक इरादा फ़िल्टर "http://" के लिए ब्राउज़र फ़िल्टर से अधिक विशिष्ट है। डिवाइस कार्यान्वयन को उपयोगकर्ताओं को इरादों के लिए डिफ़ॉल्ट गतिविधि को संशोधित करने के लिए एक उपयोगकर्ता इंटरफ़ेस प्रदान करना होगा।

3.2.3.3. आशय नामस्थान

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

यह निषेध धारा 3.6 में जावा भाषा कक्षाओं के लिए निर्दिष्ट निषेध के अनुरूप है।

3.2.3.4. प्रसारण के इरादे

तृतीय-पक्ष एप्लिकेशन हार्डवेयर या सॉफ़्टवेयर वातावरण में परिवर्तनों के बारे में सूचित करने के लिए कुछ उद्देश्यों को प्रसारित करने के लिए प्लेटफ़ॉर्म पर भरोसा करते हैं। एंड्रॉइड-संगत उपकरणों को उचित सिस्टम घटनाओं के जवाब में सार्वजनिक प्रसारण इरादों को प्रसारित करना होगा। प्रसारण इरादे एसडीके दस्तावेज़ में वर्णित हैं।

3.3. मूल एपीआई संगतता

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

डाल्विक में चल रहा प्रबंधित कोड उपयुक्त डिवाइस हार्डवेयर आर्किटेक्चर के लिए संकलित ईएलएफ .so फ़ाइल के रूप में एप्लिकेशन .apk फ़ाइल में प्रदान किए गए मूल कोड में कॉल कर सकता है। चूंकि मूल कोड अंतर्निहित प्रोसेसर तकनीक पर अत्यधिक निर्भर है, एंड्रॉइड docs/CPU-ARCH-ABIS.html फ़ाइल में एंड्रॉइड NDK में कई एप्लिकेशन बाइनरी इंटरफेस (एबीआई) को परिभाषित करता है। यदि कोई उपकरण कार्यान्वयन एक या अधिक परिभाषित एबीआई के साथ संगत है, तो उसे नीचे दिए अनुसार एंड्रॉइड एनडीके के साथ संगतता लागू करनी चाहिए।

यदि किसी डिवाइस कार्यान्वयन में एंड्रॉइड एबीआई के लिए समर्थन शामिल है, तो यह:

मानक जावा नेटिव इंटरफ़ेस (जेएनआई) शब्दार्थ का उपयोग करके मूल कोड में कॉल करने के लिए प्रबंधित वातावरण में चल रहे कोड के लिए समर्थन शामिल होना चाहिए।
नीचे दी गई सूची में प्रत्येक आवश्यक लाइब्रेरी के साथ स्रोत-संगत (यानी हेडर संगत) और बाइनरी-संगत (एबीआई के लिए) होना चाहिए
android.os.Build.CPU_ABI API के माध्यम से डिवाइस द्वारा समर्थित मूल एप्लिकेशन बाइनरी इंटरफ़ेस (ABI) की सटीक रिपोर्ट अवश्य करें
केवल उन ABI की रिपोर्ट अवश्य करें जो Android NDK के नवीनतम संस्करण में दस्तावेज़ित हैं, फ़ाइल docs/CPU-ARCH-ABIS.txt में
अपस्ट्रीम एंड्रॉइड ओपन सोर्स प्रोजेक्ट में उपलब्ध सोर्स कोड और हेडर फ़ाइलों का उपयोग करके बनाया जाना चाहिए

निम्नलिखित मूल कोड एपीआई उन ऐप्स के लिए उपलब्ध होने चाहिए जिनमें मूल कोड शामिल है:

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

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

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

3.4. वेब अनुकूलता

3.4.1. वेबव्यू संगतता

एंड्रॉइड ओपन सोर्स कार्यान्वयन android.webkit.WebView को लागू करने के लिए WebKit रेंडरिंग इंजन का उपयोग करता है। क्योंकि वेब रेंडरिंग सिस्टम के लिए एक व्यापक परीक्षण सूट विकसित करना संभव नहीं है, डिवाइस कार्यान्वयनकर्ताओं को वेबव्यू कार्यान्वयन में वेबकिट के विशिष्ट अपस्ट्रीम बिल्ड का उपयोग करना होगा। विशेष रूप से:

डिवाइस कार्यान्वयन ' android.webkit.WebView कार्यान्वयन एंड्रॉइड 4.2 के लिए अपस्ट्रीम एंड्रॉइड ओपन सोर्स ट्री से 534.30 वेबकिट बिल्ड पर आधारित होना चाहिए। इस बिल्ड में WebView के लिए कार्यक्षमता और सुरक्षा सुधारों का एक विशिष्ट सेट शामिल है। डिवाइस कार्यान्वयनकर्ता वेबकिट कार्यान्वयन में अनुकूलन शामिल कर सकते हैं; हालाँकि, ऐसे किसी भी अनुकूलन से वेबव्यू के व्यवहार में बदलाव नहीं होना चाहिए, जिसमें रेंडरिंग व्यवहार भी शामिल है।
WebView द्वारा रिपोर्ट की गई उपयोगकर्ता एजेंट स्ट्रिंग इस प्रारूप में होनी चाहिए:
Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL) Build/$(BUILD)) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.2 Mobile Safari/534.30
- $(VERSION) स्ट्रिंग का मान android.os.Build.VERSION.RELEASE के मान के समान होना चाहिए
- $(LOCALE) स्ट्रिंग का मान देश कोड और भाषा के लिए आईएसओ सम्मेलनों का पालन करना चाहिए, और डिवाइस के वर्तमान कॉन्फ़िगर किए गए स्थान को संदर्भित करना चाहिए
- $(MODEL) स्ट्रिंग का मान android.os.Build.MODEL के मान के समान होना चाहिए
- $(BUILD) स्ट्रिंग का मान android.os.Build.ID के मान के समान होना चाहिए
- डिवाइस कार्यान्वयन उपयोगकर्ता एजेंट स्ट्रिंग में Mobile छोड़ सकता है

WebView घटक में यथासंभव HTML5 [ संसाधन, 11 ] के लिए समर्थन शामिल होना चाहिए। न्यूनतम रूप से, डिवाइस कार्यान्वयन को WebView में HTML5 से जुड़े प्रत्येक एपीआई का समर्थन करना चाहिए:

एप्लिकेशन कैश/ऑफ़लाइन ऑपरेशन [ संसाधन, 12 ]
<वीडियो> टैग [ संसाधन, 13 ]
जियोलोकेशन [ संसाधन, 14 ]

इसके अतिरिक्त, डिवाइस कार्यान्वयन को HTML5/W3C वेबस्टोरेज API [ संसाधन, 15 ] का समर्थन करना चाहिए, और HTML5/W3C IndexedDB API [ संसाधन, 16 ] का समर्थन करना चाहिए। ध्यान दें कि जैसे-जैसे वेब विकास मानक निकाय वेबस्टोरेज पर IndexedDB के पक्ष में बदलाव कर रहे हैं, IndexedDB को एंड्रॉइड के भविष्य के संस्करण में एक आवश्यक घटक बनने की उम्मीद है।

HTML5 एपीआई, सभी जावास्क्रिप्ट एपीआई की तरह, वेबव्यू में डिफ़ॉल्ट रूप से अक्षम होना चाहिए, जब तक कि डेवलपर उन्हें सामान्य एंड्रॉइड एपीआई के माध्यम से स्पष्ट रूप से सक्षम न कर दे।

3.4.2. ब्राउज़र संगतता

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

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

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

एप्लिकेशन कैश/ऑफ़लाइन ऑपरेशन [ संसाधन, 12 ]
<वीडियो> टैग [ संसाधन, 13 ]
जियोलोकेशन [ संसाधन, 14 ]

3.5. एपीआई व्यवहार संगतता

प्रत्येक एपीआई प्रकार (प्रबंधित, सॉफ्ट, देशी और वेब) का व्यवहार अपस्ट्रीम एंड्रॉइड ओपन सोर्स प्रोजेक्ट के पसंदीदा कार्यान्वयन के अनुरूप होना चाहिए [ संसाधन, 3 ]। अनुकूलता के कुछ विशिष्ट क्षेत्र हैं:

उपकरणों को मानक इरादे के व्यवहार या शब्दार्थ को नहीं बदलना चाहिए
उपकरणों को किसी विशेष प्रकार के सिस्टम घटक (जैसे सेवा, गतिविधि, सामग्री प्रदाता, आदि) के जीवनचक्र या जीवनचक्र शब्दार्थ में परिवर्तन नहीं करना चाहिए।
उपकरणों को मानक अनुमति के शब्दार्थ को नहीं बदलना चाहिए

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

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

एंड्रॉइड जावा प्रोग्रामिंग भाषा द्वारा परिभाषित पैकेज और क्लास नेमस्पेस सम्मेलनों का पालन करता है। तृतीय-पक्ष अनुप्रयोगों के साथ अनुकूलता सुनिश्चित करने के लिए, डिवाइस कार्यान्वयनकर्ताओं को इन पैकेज नामस्थानों में कोई निषिद्ध संशोधन (नीचे देखें) नहीं करना चाहिए:

जावा।*
जावैक्स.*
सूरज।*
एंड्रॉयड।*
com.android.*

निषिद्ध संशोधनों में शामिल हैं:

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

"सार्वजनिक रूप से उजागर तत्व" कोई भी निर्माण है जो अपस्ट्रीम एंड्रॉइड स्रोत कोड में उपयोग किए गए "@hide" मार्कर से सजाया नहीं गया है। दूसरे शब्दों में, डिवाइस कार्यान्वयनकर्ताओं को ऊपर बताए गए नामस्थानों में नए एपीआई प्रदर्शित नहीं करने चाहिए या मौजूदा एपीआई में बदलाव नहीं करना चाहिए। डिवाइस कार्यान्वयनकर्ता केवल आंतरिक संशोधन कर सकते हैं, लेकिन उन संशोधनों का विज्ञापन नहीं किया जाना चाहिए या अन्यथा डेवलपर्स के सामने उजागर नहीं किया जाना चाहिए।

डिवाइस कार्यान्वयनकर्ता कस्टम एपीआई जोड़ सकते हैं, लेकिन ऐसे किसी भी एपीआई को किसी अन्य संगठन के स्वामित्व वाले या संदर्भित नामस्थान में नहीं होना चाहिए। उदाहरण के लिए, डिवाइस कार्यान्वयनकर्ताओं को com.google.* या समान नेमस्पेस में API नहीं जोड़ना चाहिए; केवल Google ही ऐसा कर सकता है. इसी प्रकार, Google को अन्य कंपनियों के नामस्थानों में API नहीं जोड़ना चाहिए। इसके अतिरिक्त, यदि किसी डिवाइस कार्यान्वयन में मानक एंड्रॉइड नेमस्पेस के बाहर कस्टम एपीआई शामिल हैं, तो उन एपीआई को एंड्रॉइड साझा लाइब्रेरी में पैक किया जाना चाहिए ताकि केवल वे ऐप्स जो स्पष्ट रूप से उनका उपयोग करते हैं ( <uses-library> तंत्र के माध्यम से) बढ़ी हुई मेमोरी उपयोग से प्रभावित होते हैं ऐसे एपीआई की.

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

ध्यान दें कि उपरोक्त प्रतिबंध जावा प्रोग्रामिंग भाषा में एपीआई के नामकरण के लिए मानक परंपराओं के अनुरूप हैं; इस खंड का उद्देश्य केवल उन परंपराओं को सुदृढ़ करना और इस अनुकूलता परिभाषा में शामिल करके उन्हें बाध्यकारी बनाना है।

3.7. वर्चुअल मशीन संगतता

डिवाइस कार्यान्वयन को पूर्ण डेल्विक एक्ज़ीक्यूटेबल (DEX) बाइटकोड विनिर्देश और डेल्विक वर्चुअल मशीन शब्दार्थ का समर्थन करना चाहिए [ संसाधन, 17 ]।

डिवाइस कार्यान्वयन को अपस्ट्रीम एंड्रॉइड प्लेटफ़ॉर्म के अनुसार और निम्न तालिका द्वारा निर्दिष्ट अनुसार मेमोरी आवंटित करने के लिए डाल्विक को कॉन्फ़िगर करना होगा। (स्क्रीन आकार और स्क्रीन घनत्व परिभाषाओं के लिए धारा 7.1.1 देखें।)

ध्यान दें कि नीचे निर्दिष्ट मेमोरी मानों को न्यूनतम मान माना जाता है, और डिवाइस कार्यान्वयन प्रति एप्लिकेशन अधिक मेमोरी आवंटित कर सकता है।

स्क्रीन का साईज़	स्क्रीन घनत्व	अनुप्रयोग मेमोरी
छोटा/सामान्य/बड़ा	एलडीपीआई/एमडीपीआई	16एमबी
छोटा/सामान्य/बड़ा	टीवीडीपीआई/एचडीपीआई	32एमबी
छोटा/सामान्य/बड़ा	xhdpi	64एमबी
एक्स बड़े	एमडीपीआई	32एमबी
एक्स बड़े	टीवीडीपीआई/एचडीपीआई	64एमबी
एक्स बड़े	xhdpi	128एमबी

3.8. उपयोगकर्ता इंटरफ़ेस अनुकूलता

3.8.1. विजेट

एंड्रॉइड एक घटक प्रकार और संबंधित एपीआई और जीवनचक्र को परिभाषित करता है जो एप्लिकेशन को अंतिम उपयोगकर्ता के लिए "ऐपविजेट" प्रदर्शित करने की अनुमति देता है [ संसाधन, 18 ]। एंड्रॉइड ओपन सोर्स संदर्भ रिलीज़ में एक लॉन्चर एप्लिकेशन शामिल है जिसमें उपयोगकर्ता इंटरफ़ेस सुविधाएं शामिल हैं जो उपयोगकर्ता को होम स्क्रीन से ऐपविजेट्स जोड़ने, देखने और हटाने की अनुमति देती हैं।

डिवाइस कार्यान्वयन संदर्भ लॉन्चर (यानी होम स्क्रीन) के विकल्प को प्रतिस्थापित कर सकता है। वैकल्पिक लॉन्चर्स में AppWidgets के लिए अंतर्निहित समर्थन शामिल होना चाहिए, और सीधे लॉन्चर के भीतर AppWidgets को जोड़ने, कॉन्फ़िगर करने, देखने और हटाने के लिए उपयोगकर्ता इंटरफ़ेस सामर्थ्य को उजागर करना चाहिए। वैकल्पिक लॉन्चर इन उपयोगकर्ता इंटरफ़ेस तत्वों को छोड़ सकते हैं; हालाँकि, यदि उन्हें छोड़ दिया जाता है, तो डिवाइस कार्यान्वयन को लॉन्चर से सुलभ एक अलग एप्लिकेशन प्रदान करना होगा जो उपयोगकर्ताओं को ऐपविजेट्स को जोड़ने, कॉन्फ़िगर करने, देखने और हटाने की अनुमति देता है।

डिवाइस कार्यान्वयन को मानक ग्रिड आकार में 4 x 4 विजेट प्रस्तुत करने में सक्षम होना चाहिए। (विवरण के लिए एंड्रॉइड एसडीके दस्तावेज़ [ संसाधन, 18 ] में ऐप विजेट डिज़ाइन दिशानिर्देश देखें।

3.8.2. सूचनाएं

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

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

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

एंड्रॉइड 4.2 में रिच नोटिफिकेशन के लिए समर्थन शामिल है, जैसे चालू नोटिफिकेशन के लिए इंटरैक्टिव व्यू। डिवाइस कार्यान्वयन को समृद्ध सूचनाओं को ठीक से प्रदर्शित और निष्पादित करना होगा, जैसा कि एंड्रॉइड एपीआई में दर्ज किया गया है।

3.8.3. खोज

एंड्रॉइड में एपीआई [ संसाधन, 22 ] शामिल हैं जो डेवलपर्स को अपने एप्लिकेशन में खोज को शामिल करने और अपने एप्लिकेशन के डेटा को वैश्विक सिस्टम खोज में उजागर करने की अनुमति देते हैं। सामान्यतया, इस कार्यक्षमता में एक एकल, सिस्टम-व्यापी उपयोगकर्ता इंटरफ़ेस शामिल होता है जो उपयोगकर्ताओं को क्वेरी दर्ज करने की अनुमति देता है, उपयोगकर्ताओं द्वारा टाइप किए जाने पर सुझाव प्रदर्शित करता है और परिणाम प्रदर्शित करता है। एंड्रॉइड एपीआई डेवलपर्स को अपने स्वयं के ऐप्स के भीतर खोज प्रदान करने के लिए इस इंटरफ़ेस का पुन: उपयोग करने की अनुमति देता है, और डेवलपर्स को सामान्य वैश्विक खोज उपयोगकर्ता इंटरफ़ेस पर परिणाम प्रदान करने की अनुमति देता है।

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

3.8.4. टोस्ट

एप्लिकेशन अंतिम उपयोगकर्ता को छोटी गैर-मोडल स्ट्रिंग प्रदर्शित करने के लिए "टोस्ट" एपीआई ([ संसाधन, 23 ] में परिभाषित) का उपयोग कर सकते हैं, जो थोड़े समय के बाद गायब हो जाते हैं। डिवाइस कार्यान्वयन को कुछ उच्च-दृश्यता तरीके से अंतिम उपयोगकर्ताओं के लिए अनुप्रयोगों से टोस्ट प्रदर्शित करना होगा।

3.8.5. विषय-वस्तु

एंड्रॉइड संपूर्ण गतिविधि या एप्लिकेशन में शैलियों को लागू करने के लिए एप्लिकेशन को एक तंत्र के रूप में "थीम" प्रदान करता है। एंड्रॉइड 4.2 में एप्लिकेशन डेवलपर्स के लिए परिभाषित शैलियों के एक सेट के रूप में "होलो" या "होलोग्राफिक" थीम शामिल है, यदि वे एंड्रॉइड एसडीके [ संसाधन, 24 ] द्वारा परिभाषित होलो थीम लुक और फील से मेल खाना चाहते हैं। डिवाइस कार्यान्वयन को अनुप्रयोगों के संपर्क में आने वाली होलो थीम की किसी भी विशेषता में बदलाव नहीं करना चाहिए [ संसाधन, 25 ]।

एंड्रॉइड 4.2 में एप्लिकेशन डेवलपर्स के लिए परिभाषित शैलियों के एक सेट के रूप में एक नया "डिवाइस डिफॉल्ट" थीम शामिल है, यदि वे डिवाइस कार्यान्वयनकर्ता द्वारा परिभाषित डिवाइस थीम के स्वरूप और अनुभव से मेल खाना चाहते हैं। डिवाइस कार्यान्वयन अनुप्रयोगों के संपर्क में आने वाली डिवाइस डिफॉल्ट थीम विशेषताओं को संशोधित कर सकता है [ संसाधन, 25 ]।

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

एंड्रॉइड एक घटक प्रकार और संबंधित एपीआई और जीवनचक्र को परिभाषित करता है जो एप्लिकेशन को अंतिम उपयोगकर्ता के लिए एक या अधिक "लाइव वॉलपेपर" प्रदर्शित करने की अनुमति देता है [ संसाधन, 26 ]। लाइव वॉलपेपर सीमित इनपुट क्षमताओं वाले एनिमेशन, पैटर्न या समान छवियां हैं जो अन्य अनुप्रयोगों के पीछे वॉलपेपर के रूप में प्रदर्शित होती हैं।

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

जैसा कि ऊपर वर्णित है, लाइव वॉलपेपर को विश्वसनीय रूप से चलाने में सक्षम डिवाइस कार्यान्वयन को लाइव वॉलपेपर लागू करना चाहिए। जैसा कि ऊपर वर्णित है, डिवाइस कार्यान्वयन लाइव वॉलपेपर को विश्वसनीय रूप से चलाने के लिए निर्धारित नहीं है, लाइव वॉलपेपर लागू नहीं करना चाहिए।

3.8.7. हालिया एप्लिकेशन प्रदर्शन

अपस्ट्रीम एंड्रॉइड 4.2 सोर्स कोड में हाल के एप्लिकेशन को प्रदर्शित करने के लिए एक उपयोगकर्ता इंटरफ़ेस शामिल है, जो उस समय एप्लिकेशन की ग्राफिकल स्थिति की थंबनेल छवि का उपयोग करता है जब उपयोगकर्ता ने आखिरी बार एप्लिकेशन छोड़ा था। डिवाइस कार्यान्वयन इस उपयोगकर्ता इंटरफ़ेस को बदल या समाप्त कर सकता है; हालाँकि, इस कार्यक्षमता का अधिक व्यापक उपयोग करने के लिए एंड्रॉइड के भविष्य के संस्करण की योजना बनाई गई है। डिवाइस कार्यान्वयन को हाल के अनुप्रयोगों के लिए अपस्ट्रीम एंड्रॉइड 4.2 उपयोगकर्ता इंटरफ़ेस (या एक समान थंबनेल-आधारित इंटरफ़ेस) का उपयोग करने के लिए दृढ़ता से प्रोत्साहित किया जाता है, अन्यथा वे एंड्रॉइड के भविष्य के संस्करण के साथ संगत नहीं हो सकते हैं।

3.8.8. इनपुट प्रबंधन सेटिंग्स

एंड्रॉइड 4.2 में इनपुट प्रबंधन इंजन के लिए समर्थन शामिल है। एंड्रॉइड 4.2 एपीआई कस्टम ऐप आईएमई को उपयोगकर्ता-ट्यून करने योग्य सेटिंग्स निर्दिष्ट करने की अनुमति देता है। डिवाइस कार्यान्वयन में उपयोगकर्ता के लिए हर समय IME सेटिंग्स तक पहुंचने का एक तरीका शामिल होना चाहिए जब ऐसी उपयोगकर्ता सेटिंग्स प्रदान करने वाला IME प्रदर्शित होता है।

3.8.9. लॉक और होम स्क्रीन विजेट

एंड्रॉइड 4.2 में एप्लिकेशन विजेट के लिए समर्थन शामिल है जिसे उपयोगकर्ता होम स्क्रीन या लॉक स्क्रीन में एम्बेड कर सकते हैं (विवरण के लिए एंड्रॉइड एसडीके दस्तावेज़ [ संसाधन, 69 ] में ऐप विजेट डिज़ाइन दिशानिर्देश देखें)। एप्लिकेशन विजेट नई गतिविधि लॉन्च किए बिना एप्लिकेशन डेटा और सेवाओं तक त्वरित पहुंच की अनुमति देते हैं। विजेट android:widgetCategory मेनिफेस्ट टैग की घोषणा करके होम स्क्रीन या लॉक स्क्रीन पर उपयोग के लिए समर्थन की घोषणा करते हैं जो सिस्टम को बताता है कि विजेट को कहां रखा जा सकता है। विशेष रूप से, डिवाइस कार्यान्वयन को निम्नलिखित आवश्यकताओं को पूरा करना होगा।

डिवाइस कार्यान्वयन को होम स्क्रीन पर एप्लिकेशन विजेट का समर्थन करना चाहिए।
डिवाइस कार्यान्वयन को लॉक स्क्रीन का समर्थन करना चाहिए। यदि डिवाइस कार्यान्वयन में लॉक स्क्रीन के लिए समर्थन शामिल है तो डिवाइस कार्यान्वयन को लॉक स्क्रीन पर एप्लिकेशन विजेट का समर्थन करना होगा।

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

एंड्रॉइड 4.2 में रिमोट कंट्रोल एपीआई के लिए समर्थन शामिल है जो मीडिया अनुप्रयोगों को प्लेबैक नियंत्रणों के साथ एकीकृत करने देता है जो डिवाइस लॉक स्क्रीन जैसे दूरस्थ दृश्य में प्रदर्शित होते हैं [ संसाधन, 74 ]। डिवाइस कार्यान्वयन में डिवाइस लॉक स्क्रीन में रिमोट कंट्रोल एम्बेड करने के लिए समर्थन शामिल होना चाहिए।

3.8.11. सपने

एंड्रॉइड 4.2 में ड्रीम्स नामक इंटरैक्टिव स्क्रीनसेवर के लिए समर्थन शामिल है [ संसाधन, 76 ]। ड्रीम्स उपयोगकर्ताओं को तब एप्लिकेशन के साथ इंटरैक्ट करने की अनुमति देता है जब कोई चार्जिंग डिवाइस निष्क्रिय हो, या डेस्क डॉक में डॉक किया गया हो। डिवाइस कार्यान्वयन में ड्रीम्स के लिए समर्थन शामिल होना चाहिए और उपयोगकर्ताओं को ड्रीम्स को कॉन्फ़िगर करने के लिए एक सेटिंग विकल्प प्रदान करना चाहिए।

3.9 डिवाइस प्रशासन

एंड्रॉइड 4.2 में ऐसी विशेषताएं शामिल हैं जो सुरक्षा-जागरूक अनुप्रयोगों को सिस्टम स्तर पर डिवाइस प्रशासन कार्य करने की अनुमति देती हैं, जैसे कि एंड्रॉइड डिवाइस एडमिनिस्ट्रेशन एपीआई [ संसाधन, 27 ] के माध्यम से पासवर्ड नीतियों को लागू करना या रिमोट वाइप करना। डिवाइस कार्यान्वयन को DevicePolicyManager वर्ग [ संसाधन, 28 ] का कार्यान्वयन प्रदान करना चाहिए, और एंड्रॉइड एसडीके दस्तावेज़ [ संसाधन, 27 ] में परिभाषित डिवाइस प्रशासन नीतियों की पूरी श्रृंखला का समर्थन करना चाहिए।

ध्यान दें: जबकि ऊपर उल्लिखित कुछ आवश्यकताओं को एंड्रॉइड 4.2 के लिए "चाहिए" के रूप में बताया गया है, लॉक स्क्रीन का समर्थन करने वाले डिवाइस कार्यान्वयन को लॉक स्क्रीन पर विजेट प्रबंधित करने के लिए डिवाइस नीतियों का समर्थन करना चाहिए जैसा कि एंड्रॉइड एसडीके दस्तावेज [ संसाधन, 27 ] में परिभाषित किया गया है।

ध्यान दें: जबकि ऊपर उल्लिखित कुछ आवश्यकताओं को एंड्रॉइड 4.2 के लिए "चाहिए" के रूप में बताया गया है, भविष्य के संस्करण के लिए संगतता परिभाषा को इन्हें "जरूरी" में बदलने की योजना है। यानी, एंड्रॉइड 4.2 में ये आवश्यकताएं वैकल्पिक हैं लेकिन भविष्य के संस्करण के लिए इनकी आवश्यकता होगी । एंड्रॉइड 4.2 चलाने वाले मौजूदा और नए उपकरणों को एंड्रॉइड 4.2 में इन आवश्यकताओं को पूरा करने के लिए बहुत दृढ़ता से प्रोत्साहित किया जाता है, अन्यथा वे भविष्य के संस्करण में अपग्रेड होने पर एंड्रॉइड संगतता प्राप्त करने में सक्षम नहीं होंगे।

3.10 अभिगम्यता

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

डिवाइस कार्यान्वयन को android.accessibilityservice API [ संसाधन, 30 ] के माध्यम से तीसरे पक्ष की पहुंच-योग्यता सेवा कार्यान्वयन का समर्थन करना चाहिए।
डिवाइस कार्यान्वयन को AccessibilityEvents उत्पन्न करना होगा और इन घटनाओं को डिफ़ॉल्ट एंड्रॉइड कार्यान्वयन के अनुरूप तरीके से सभी पंजीकृत AccessibilityService कार्यान्वयन तक वितरित करना होगा।
डिवाइस कार्यान्वयन को एक्सेसिबिलिटी सेवाओं को सक्षम और अक्षम करने के लिए एक उपयोगकर्ता-सुलभ तंत्र प्रदान करना होगा, और android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS इरादे के जवाब में इस इंटरफ़ेस को प्रदर्शित करना होगा।

इसके अतिरिक्त, डिवाइस कार्यान्वयन को डिवाइस पर एक एक्सेसिबिलिटी सेवा का कार्यान्वयन प्रदान करना चाहिए, और उपयोगकर्ताओं को डिवाइस सेटअप के दौरान एक्सेसिबिलिटी सेवा को सक्षम करने के लिए एक तंत्र प्रदान करना चाहिए। एक्सेसिबिलिटी सेवा का एक खुला स्रोत कार्यान्वयन आईज़ फ्री प्रोजेक्ट [ संसाधन, 31 ] से उपलब्ध है।

3.11 टेक्स्ट-टू-स्पीच

एंड्रॉइड 4.2 में एपीआई शामिल है जो एप्लिकेशन को टेक्स्ट-टू-स्पीच (टीटीएस) सेवाओं का उपयोग करने की अनुमति देता है, और सेवा प्रदाताओं को टीटीएस सेवाओं के कार्यान्वयन प्रदान करने की अनुमति देता है [ संसाधन, 32 ]। डिवाइस कार्यान्वयन को एंड्रॉइड टीटीएस ढांचे से संबंधित इन आवश्यकताओं को पूरा करना होगा:

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

4. अनुप्रयोग पैकेजिंग संगतता

डिवाइस कार्यान्वयन को आधिकारिक एंड्रॉइड एसडीके [ संसाधन, 33 ] में शामिल "aapt" टूल द्वारा उत्पन्न एंड्रॉइड ".apk" फ़ाइलों को स्थापित और चलाना होगा।

डिवाइस कार्यान्वयन को .apk [ संसाधन, 34 ], एंड्रॉइड मेनिफेस्ट [ संसाधन, 35 ], डाल्विक बाइटकोड [ संसाधन, 17 ], या रेंडरस्क्रिप्ट बाइटकोड प्रारूपों का इस तरह से विस्तार नहीं करना चाहिए जो उन फ़ाइलों को स्थापित करने और सही ढंग से चलने से रोकें। अन्य संगत डिवाइस। डिवाइस कार्यान्वयनकर्ताओं को डाल्विक के संदर्भ अपस्ट्रीम कार्यान्वयन और संदर्भ कार्यान्वयन के पैकेज प्रबंधन प्रणाली का उपयोग करना चाहिए।

5. मल्टीमीडिया संगतता

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

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

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

कृपया ध्यान दें कि न तो Google और न ही ओपन हैंडसेट अलायंस कोई प्रतिनिधित्व करता है कि ये कोडेक्स तीसरे पक्ष के पेटेंट से मुक्त हैं। हार्डवेयर या सॉफ़्टवेयर उत्पादों में इस स्रोत कोड का उपयोग करने के इच्छुक लोगों को सलाह दी जाती है कि ओपन सोर्स सॉफ़्टवेयर या शेयरवेयर सहित इस कोड के कार्यान्वयन के लिए संबंधित पेटेंट धारकों से पेटेंट लाइसेंस की आवश्यकता हो सकती है।

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

प्रकार	प्रारूप/कोडेक	एनकोडर	डिकोडर	विवरण	फ़ाइल प्रकार/कंटेनर प्रारूप
ऑडियो	एमपीईजी-4 एएसी प्रोफाइल (एएसी एलसी)	आवश्यक डिवाइस कार्यान्वयन के लिए आवश्यक है जिसमें माइक्रोफ़ोन हार्डवेयर शामिल है और `android.hardware.microphone` परिभाषित है।	आवश्यक	8 से 48 किलोहर्ट्ज़ तक मानक नमूना दरों के साथ मोनो/स्टीरियो/5.0/5.1* सामग्री के लिए समर्थन।	3जीपीपी (.3जीपी) एमपीईजी-4 (.mp4, .m4a) ADTS कच्चा AAC (.aac, Android 3.1+ में डिकोड, Android 4.0+ में एनकोड, ADIF समर्थित नहीं) MPEG-TS (.ts, खोजने योग्य नहीं, Android 3.0+)
	एमपीईजी-4 एचई एएसी प्रोफाइल (एएसी+)	डिवाइस कार्यान्वयन के लिए आवश्यक है जिसमें माइक्रोफ़ोन हार्डवेयर शामिल है और android.hardware.microphone को परिभाषित किया गया है	आवश्यक	16 से 48 किलोहर्ट्ज़ तक मानक नमूना दरों के साथ मोनो/स्टीरियो/5.0/5.1* सामग्री के लिए समर्थन।
	MPEG-4 HE AAC v2 प्रोफ़ाइल (उन्नत AAC+)		आवश्यक	16 से 48 किलोहर्ट्ज़ तक मानक नमूना दरों के साथ मोनो/स्टीरियो/5.0/5.1* सामग्री के लिए समर्थन।
	एमपीईजी-4 ऑडियो ऑब्जेक्ट प्रकार ईआर एएसी ईएलडी (उन्नत कम विलंब एएसी)	डिवाइस कार्यान्वयन के लिए आवश्यक है जिसमें माइक्रोफ़ोन हार्डवेयर शामिल है और android.hardware.microphone को परिभाषित किया गया है	आवश्यक	16 से 48 किलोहर्ट्ज़ तक मानक नमूना दरों के साथ मोनो/स्टीरियो सामग्री के लिए समर्थन।
	एएमआर-एनबी	आवश्यक डिवाइस कार्यान्वयन के लिए आवश्यक है जिसमें माइक्रोफ़ोन हार्डवेयर शामिल है और `android.hardware.microphone` परिभाषित है।	आवश्यक	4.75 से 12.2 केबीपीएस का नमूना 8kHz पर	3जीपीपी (.3जीपी)
	एएमआर-पश्चिम बंगाल	आवश्यक डिवाइस कार्यान्वयन के लिए आवश्यक है जिसमें माइक्रोफ़ोन हार्डवेयर शामिल है और `android.hardware.microphone` परिभाषित है।	आवश्यक	16kHz पर 6.60 kbit/s से 23.85 kbit/s तक 9 दरें नमूनाकृत	3जीपीपी (.3जीपी)
	एफएलएसी		आवश्यक (एंड्रॉइड 3.1+)	मोनो/स्टीरियो (कोई मल्टीचैनल नहीं)। 48 किलोहर्ट्ज़ तक नमूना दरें (लेकिन 44.1 किलोहर्ट्ज़ आउटपुट वाले उपकरणों पर 44.1 किलोहर्ट्ज़ तक की सिफारिश की जाती है, क्योंकि 48 से 44.1 किलोहर्ट्ज़ डाउनसैंपलर में कम-पास फ़िल्टर शामिल नहीं होता है)। 16-बिट अनुशंसित; 24-बिट के लिए कोई आवेदन नहीं किया गया।	केवल FLAC (.flac)।
	एमपी 3		आवश्यक	मोनो/स्टीरियो 8-320Kbps स्थिरांक (CBR) या परिवर्तनीय बिट-दर (VBR)	एमपी3 (.mp3)
	मिडी		आवश्यक	MIDI प्रकार 0 और 1. DLS संस्करण 1 और 2. XMF और मोबाइल XMF। रिंगटोन प्रारूपों RTTTL/RTX, OTA और iMelody के लिए समर्थन	टाइप 0 और 1 (.मिड, .xmf, .mxmf) आरटीटीटीएल/आरटीएक्स (.rtttl, .rtx) ओटीए (.ota) आईमेलोडी (.imy)
	वॉर्बिस		आवश्यक		ओग (.ogg) मैट्रोस्का (.mkv)
	पीसीएम/वेव	आवश्यक	आवश्यक	8-बिट और 16-बिट रैखिक पीसीएम** (हार्डवेयर की सीमा तक दरें)। उपकरणों को 8000,16000 और 44100 हर्ट्ज आवृत्तियों पर कच्चे पीसीएम रिकॉर्डिंग के लिए नमूना दरों का समर्थन करना चाहिए।	लहर (.wav)
छवि	जेपीईजी	आवश्यक	आवश्यक	आधार+प्रगतिशील	जेपीईजी (.jpg)
	GIF		आवश्यक		जीआईएफ (.gif)
	पीएनजी	आवश्यक	आवश्यक		पीएनजी (.png)
	बीएमपी		आवश्यक		बीएमपी (.बीएमपी)
	वेबपी	आवश्यक	आवश्यक		वेबपी (.वेबपी)
वीडियो	एच .263	आवश्यक डिवाइस कार्यान्वयन के लिए आवश्यक है जिसमें कैमरा हार्डवेयर शामिल है और `android.hardware.camera` या `android.hardware.camera.front` को परिभाषित किया गया है।	आवश्यक		3जीपीपी (.3जीपी) एमपीईजी-4 (.mp4)
	एच.264 एवीसी	आवश्यक डिवाइस कार्यान्वयन के लिए आवश्यक है जिसमें कैमरा हार्डवेयर शामिल है और `android.hardware.camera` या `android.hardware.camera.front` को परिभाषित किया गया है।	आवश्यक	बेसलाइन प्रोफ़ाइल (बीपी)	3जीपीपी (.3जीपी) एमपीईजी-4 (.mp4) MPEG-TS (.ts, केवल AAC ऑडियो, खोजने योग्य नहीं, Android 3.0+)
	एमपीईजी-4 एसपी		आवश्यक		3जीपीपी (.3जीपी)
	वीपी8		आवश्यक (एंड्रॉइड 2.3.3+)		WebM (.webm) और Matroska (.mkv, Android 4.0+)

*नोट: केवल 5.0/5.1 सामग्री के डाउनमिक्स की आवश्यकता है; 2 से अधिक चैनलों को रिकॉर्ड करना या प्रस्तुत करना वैकल्पिक है। **ध्यान दें: 16-बिट लीनियर पीसीएम कैप्चर अनिवार्य है। 8-बिट रैखिक पीसीएम कैप्चर अनिवार्य नहीं है।

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

एंड्रॉइड डिवाइस कार्यान्वयन जिसमें एक रियर-फेसिंग कैमरा शामिल है और घोषित android.hardware.camera को निम्नलिखित वीडियो एन्कोडिंग प्रोफाइल का समर्थन करना चाहिए।

	एसडी (निम्न गुणवत्ता)	एसडी (उच्च गुणवत्ता)	एचडी (हार्डवेयर द्वारा समर्थित होने पर)
वीडियो कोडेक	एच.264 बेसलाइन प्रोफाइल	एच.264 बेसलाइन प्रोफाइल	एच.264 बेसलाइन प्रोफाइल
वीडियो संकल्प	176 x 144 पीएक्स	480 x 360 पिक्सल	1280 x 720 पिक्सेल
वीडियो फ्रेम दर	12 एफपीएस	30 एफपीएस	30 एफपीएस
वीडियो बिटरेट	56 केबीपीएस	500 केबीपीएस या इससे अधिक	2 एमबीपीएस या उच्चतर
ऑडियो कोडेक	एएसी-नियंत्रण रेखा	एएसी-नियंत्रण रेखा	एएसी-नियंत्रण रेखा
ऑडियो चैनल	1 (मोनो)	2 (स्टीरियो)	2 (स्टीरियो)
ऑडियो बिटरेट	24 केबीपीएस	128 केबीपीएस	192 केबीपीएस

5.3 वीडियो डिकोडिंग

एंड्रॉइड डिवाइस कार्यान्वयन को निम्नलिखित VP8 वीडियो डिकोडिंग प्रोफाइल का समर्थन करना चाहिए।

	एसडी (निम्न गुणवत्ता)	एसडी (उच्च गुणवत्ता)	एचडी 720पी (हार्डवेयर द्वारा समर्थित होने पर)	एचडी 1080पी (हार्डवेयर द्वारा समर्थित होने पर)
वीडियो संकल्प	320 x 180 पिक्सल	640 x 360 पिक्सेल	1280 x 720 पिक्सेल	1920 x 1080 पिक्सल
वीडियो फ्रेम दर	30 एफपीएस	30 एफपीएस	30 एफपीएस	30 एफपीएस
वीडियो बिटरेट	800 केबीपीएस	2 एमबीपीएस	8 एमबीपीएस	20 एमबीपीएस

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

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

डिवाइस को आवृत्ति विशेषताओं बनाम लगभग सपाट आयाम प्रदर्शित करना चाहिए; विशेष रूप से, ±3 डीबी, 100 हर्ट्ज से 4000 हर्ट्ज तक
ऑडियो इनपुट संवेदनशीलता को ऐसे सेट किया जाना चाहिए कि 1000 हर्ट्ज पर 90 डीबी ध्वनि शक्ति स्तर (एसपीएल) स्रोत 16-बिट नमूनों के लिए 2500 का आरएमएस उत्पन्न करता है।
पीसीएम आयाम स्तर को माइक्रोफ़ोन पर -18 डीबी से +12 डीबी और 90 डीबी एसपीएल तक कम से कम 30 डीबी रेंज में इनपुट एसपीएल परिवर्तनों को रैखिक रूप से ट्रैक करना चाहिए।
90 डीबी एसपीएल इनपुट स्तर पर 1 किलोहर्ट्ज़ के लिए कुल हार्मोनिक विरूपण 1% से कम होना चाहिए।

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

शोर कम करने की प्रक्रिया, यदि मौजूद है, तो अक्षम होनी चाहिए।
स्वचालित लाभ नियंत्रण, यदि मौजूद है, तो अक्षम होना चाहिए।

5.5. ऑडियो विलंबता

ऑडियो विलंबता वह समय विलंब है जब एक ऑडियो सिग्नल एक सिस्टम से गुजरता है। ध्वनि प्रभाव या वीओआइपी संचार जैसे वास्तविक समय के प्रभावों को प्राप्त करने के लिए अनुप्रयोगों के कई वर्ग छोटी विलंबता पर निर्भर करते हैं।

इस अनुभाग के प्रयोजनों के लिए:

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

धारा 5 के अनुसार, सभी संगत डिवाइस कार्यान्वयन में कम से कम एक प्रकार का ऑडियो आउटपुट शामिल होना चाहिए। डिवाइस कार्यान्वयन को इन आउटपुट विलंबता आवश्यकताओं को पूरा करना चाहिए या उससे अधिक होना चाहिए:

100 मिलीसेकंड या उससे कम की शीत आउटपुट विलंबता
45 मिलीसेकंड या उससे कम की निरंतर आउटपुट विलंबता

यदि कोई डिवाइस कार्यान्वयन कम से कम एक समर्थित ऑडियो आउटपुट डिवाइस पर निरंतर आउटपुट विलंबता और कोल्ड आउटपुट विलंबता के लिए ओपनएसएल ईएस पीसीएम बफर कतार एपीआई का उपयोग करते समय किसी भी प्रारंभिक अंशांकन के बाद इस अनुभाग की आवश्यकताओं को पूरा करता है, तो यह कम-विलंबता ऑडियो के लिए समर्थन की रिपोर्ट कर सकता है , android.content.pm.PackageManager वर्ग के माध्यम से "android.hardware.audio.low-latency" सुविधा की रिपोर्ट करके। [ संसाधन, 37 ] इसके विपरीत, यदि डिवाइस कार्यान्वयन इन आवश्यकताओं को पूरा नहीं करता है तो उसे कम-विलंबता ऑडियो के लिए समर्थन की रिपोर्ट नहीं करनी चाहिए।

धारा 7.2.5 के अनुसार, डिवाइस कार्यान्वयन द्वारा माइक्रोफ़ोन हार्डवेयर को छोड़ा जा सकता है।

डिवाइस कार्यान्वयन जिसमें माइक्रोफ़ोन हार्डवेयर और घोषित android.hardware.microphone शामिल हैं, इन इनपुट ऑडियो विलंबता आवश्यकताओं को पूरा करना चाहिए:

100 मिलीसेकंड या उससे कम की कोल्ड इनपुट विलंबता
50 मिलीसेकंड या उससे कम की निरंतर इनपुट विलंबता

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

डिवाइस को ऑडियो और वीडियो प्लेबैक के लिए मीडिया नेटवर्क प्रोटोकॉल का समर्थन करना चाहिए जैसा कि एंड्रॉइड एसडीके दस्तावेज़ [ संसाधन, 58 ] में निर्दिष्ट है। विशेष रूप से, उपकरणों को निम्नलिखित मीडिया नेटवर्क प्रोटोकॉल का समर्थन करना चाहिए:

आरटीएसपी (आरटीपी, एसडीपी)
HTTP(S) प्रगतिशील स्ट्रीमिंग
HTTP(S) लाइव स्ट्रीमिंग ड्राफ्ट प्रोटोकॉल, संस्करण 3 [ संसाधन, 59 ]

6. डेवलपर उपकरण और विकल्प संगतता

6.1 डेवलपर उपकरण

डिवाइस कार्यान्वयन को एंड्रॉइड एसडीके में दिए गए एंड्रॉइड डेवलपर टूल्स का समर्थन करना चाहिए। विशेष रूप से, एंड्रॉइड-संगत उपकरणों को इसके साथ संगत होना चाहिए:

एंड्रॉइड डीबग ब्रिज (एडीबी के रूप में जाना जाता है) [ संसाधन, 33 ]
डिवाइस कार्यान्वयन को एंड्रॉइड एसडीके में प्रलेखित सभी adb फ़ंक्शंस का समर्थन करना चाहिए। डिवाइस-साइड adb डेमॉन डिफ़ॉल्ट रूप से निष्क्रिय होना चाहिए, और एंड्रॉइड डिबग ब्रिज को चालू करने के लिए एक उपयोगकर्ता-पहुंच योग्य तंत्र होना चाहिए।

एंड्रॉइड 4.2.2 में सुरक्षित एडीबी के लिए समर्थन शामिल है। सुरक्षित एडीबी ज्ञात प्रमाणित होस्ट पर एडीबी को सक्षम बनाता है। एंड्रॉइड 4.2.2 पर चलने वाले मौजूदा और नए उपकरणों को एंड्रॉइड 4.2 में इस आवश्यकता को पूरा करने के लिए बहुत दृढ़ता से प्रोत्साहित किया जाता है, अन्यथा भविष्य के संस्करण में अपग्रेड होने पर वे एंड्रॉइड संगतता प्राप्त नहीं कर पाएंगे।

डाल्विक डिबग मॉनिटर सेवा (डीडीएमएस के रूप में जाना जाता है) [ संसाधन, 33 ]
डिवाइस कार्यान्वयन को एंड्रॉइड एसडीके में प्रलेखित सभी ddms सुविधाओं का समर्थन करना चाहिए। चूँकि ddms adb का उपयोग करता है, ddms के लिए समर्थन डिफ़ॉल्ट रूप से निष्क्रिय होना चाहिए, लेकिन जब भी उपयोगकर्ता ने ऊपर बताए अनुसार Android डीबग ब्रिज को सक्रिय किया है, तो उसे समर्थित होना चाहिए।
बंदर [ संसाधन, 36 ]
डिवाइस कार्यान्वयन में मंकी फ्रेमवर्क शामिल होना चाहिए, और इसे अनुप्रयोगों के उपयोग के लिए उपलब्ध कराया जाना चाहिए।
SysTrace [ संसाधन, 33 ]
डिवाइस कार्यान्वयन को एंड्रॉइड एसडीके में प्रलेखित सिस्ट्रेस टूल का समर्थन करना चाहिए। सिस्ट्रेस डिफ़ॉल्ट रूप से निष्क्रिय होना चाहिए, और सिस्ट्रेस को चालू करने के लिए एक उपयोगकर्ता-पहुंच योग्य तंत्र होना चाहिए।

अधिकांश लिनक्स-आधारित सिस्टम और ऐप्पल मैकिंटोश सिस्टम अतिरिक्त समर्थन के बिना, मानक एंड्रॉइड एसडीके टूल का उपयोग करके एंड्रॉइड डिवाइस को पहचानते हैं; हालाँकि Microsoft Windows सिस्टम को आमतौर पर नए Android उपकरणों के लिए ड्राइवर की आवश्यकता होती है। (उदाहरण के लिए, नए विक्रेता आईडी और कभी-कभी नए डिवाइस आईडी के लिए विंडोज सिस्टम के लिए कस्टम यूएसबी ड्राइवरों की आवश्यकता होती है।) यदि मानक एंड्रॉइड एसडीके में प्रदान किए गए adb टूल द्वारा डिवाइस कार्यान्वयन को पहचाना नहीं जाता है, तो डिवाइस कार्यान्वयनकर्ताओं को डेवलपर्स को कनेक्ट करने की अनुमति देने वाले विंडोज ड्राइवर प्रदान करने होंगे। adb प्रोटोकॉल का उपयोग करने वाला उपकरण। ये ड्राइवर Windows XP, Windows Vista, Windows 7 और Windows 8 के लिए 32-बिट और 64-बिट दोनों संस्करणों में उपलब्ध कराए जाने चाहिए।

6.2 डेवलपर विकल्प

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

7. हार्डवेयर अनुकूलता

यदि किसी डिवाइस में एक विशेष हार्डवेयर घटक शामिल है जिसमें तृतीय-पक्ष डेवलपर्स के लिए संबंधित एपीआई है, तो डिवाइस कार्यान्वयन को उस एपीआई को एंड्रॉइड एसडीके दस्तावेज़ में वर्णित अनुसार लागू करना होगा। यदि एसडीके में एक एपीआई एक हार्डवेयर घटक के साथ इंटरैक्ट करता है जिसे वैकल्पिक बताया गया है और डिवाइस कार्यान्वयन में वह घटक नहीं है:

घटक के एपीआई के लिए पूर्ण वर्ग परिभाषाएँ (एसडीके द्वारा प्रलेखित) अभी भी मौजूद होनी चाहिए
एपीआई के व्यवहार को कुछ उचित तरीके से नो-ऑप्स के रूप में लागू किया जाना चाहिए
जहां एसडीके दस्तावेज़ द्वारा अनुमति दी गई है वहां एपीआई विधियों को शून्य मान लौटाना होगा
एपीआई विधियों को उन कक्षाओं के नो-ऑप कार्यान्वयन को वापस करना होगा जहां एसडीके दस्तावेज़ द्वारा शून्य मान की अनुमति नहीं है
एपीआई विधियों को ऐसे अपवाद नहीं फेंकने चाहिए जो एसडीके दस्तावेज़ में दर्ज न किए गए हों

ऐसे परिदृश्य का एक विशिष्ट उदाहरण जहां ये आवश्यकताएं लागू होती हैं वह टेलीफोनी एपीआई है: यहां तक कि गैर-फोन उपकरणों पर भी, इन एपीआई को उचित नो-ऑप्स के रूप में लागू किया जाना चाहिए।

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

7.1. प्रदर्शन और ग्राफ़िक्स

एंड्रॉइड 4.2 में ऐसी सुविधाएं शामिल हैं जो डिवाइस के लिए एप्लिकेशन संपत्तियों और यूआई लेआउट को स्वचालित रूप से समायोजित करती हैं, ताकि यह सुनिश्चित किया जा सके कि तृतीय-पक्ष एप्लिकेशन विभिन्न हार्डवेयर कॉन्फ़िगरेशन पर अच्छी तरह से चलते हैं [ संसाधन, 38 ]। उपकरणों को इन एपीआई और व्यवहारों को ठीक से लागू करना होगा, जैसा कि इस अनुभाग में बताया गया है।

इस अनुभाग में आवश्यकताओं द्वारा संदर्भित इकाइयों को निम्नानुसार परिभाषित किया गया है:

"भौतिक विकर्ण आकार" डिस्प्ले के प्रबुद्ध भाग के दो विपरीत कोनों के बीच इंच की दूरी है।
"डीपीआई" (जिसका अर्थ है "डॉट्स प्रति इंच") 1 के रैखिक क्षैतिज या ऊर्ध्वाधर विस्तार से घिरे पिक्सेल की संख्या है। जहां डीपीआई मान सूचीबद्ध हैं, क्षैतिज और ऊर्ध्वाधर दोनों डीपीआई को सीमा के भीतर आना चाहिए।
"पहलू अनुपात" स्क्रीन के लंबे आयाम और छोटे आयाम का अनुपात है। उदाहरण के लिए, 480x854 पिक्सेल का डिस्प्ले 854/480 = 1.779, या मोटे तौर पर "16:9" होगा।
एक "घनत्व-स्वतंत्र पिक्सेल" या ("डीपी") 160 डीपीआई स्क्रीन के लिए सामान्यीकृत आभासी पिक्सेल इकाई है, जिसकी गणना इस प्रकार की जाती है: pixels = dps * (density / 160)

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

स्क्रीन का साईज़

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

उपकरणों का स्क्रीन आकार कम से कम 426 डीपी x 320 डीपी ('छोटा') होना चाहिए
जो उपकरण स्क्रीन आकार को 'सामान्य' बताते हैं, उनका स्क्रीन आकार कम से कम 480 डीपी x 320 डीपी होना चाहिए।
जो उपकरण स्क्रीन आकार 'बड़ा' बताते हैं, उनका स्क्रीन आकार कम से कम 640 डीपी x 480 डीपी होना चाहिए।
जो डिवाइस स्क्रीन आकार 'एक्सलार्ज' बताते हैं, उनका स्क्रीन आकार कम से कम 960 डीपी x 720 डीपी होना चाहिए।

इसके अलावा, उपकरणों का स्क्रीन आकार भौतिक विकर्ण आकार में कम से कम 2.5 इंच होना चाहिए।

उपकरणों को किसी भी समय अपना रिपोर्ट किया गया स्क्रीन आकार नहीं बदलना चाहिए।

एप्लिकेशन वैकल्पिक रूप से AndroidManifest.xml फ़ाइल में <supports-screens> विशेषता के माध्यम से इंगित करते हैं कि वे किस स्क्रीन आकार का समर्थन करते हैं। डिवाइस कार्यान्वयन को छोटे, सामान्य, बड़े और बड़े स्क्रीन के लिए अनुप्रयोगों के घोषित समर्थन का सही ढंग से सम्मान करना चाहिए, जैसा कि एंड्रॉइड एसडीके दस्तावेज़ में वर्णित है।

स्क्रीन पहलू अनुपात

पहलू अनुपात 1.3333 (4:3) और 1.85 (16:9) के बीच होना चाहिए।

स्क्रीन घनत्व

एंड्रॉइड यूआई फ्रेमवर्क एप्लिकेशन डेवलपर्स को एप्लिकेशन संसाधनों को लक्षित करने में मदद करने के लिए मानक तार्किक घनत्व के एक सेट को परिभाषित करता है। डिवाइस कार्यान्वयन को android.util.DisplayMetrics API के माध्यम से निम्नलिखित तार्किक एंड्रॉइड फ्रेमवर्क घनत्वों में से एक की रिपोर्ट करनी होगी, और इस मानक घनत्व पर अनुप्रयोगों को निष्पादित करना होगा।

120 डीपीआई, जिसे 'एलडीपीआई' के नाम से जाना जाता है
160 डीपीआई, जिसे 'एमडीपीआई' के नाम से जाना जाता है
213 डीपीआई, जिसे 'टीवीडीपीआई' के नाम से जाना जाता है
240 डीपीआई, जिसे 'एचडीपीआई' के नाम से जाना जाता है
320 डीपीआई, जिसे 'एक्सएचडीपीआई' के नाम से जाना जाता है
480 डीपीआई, जिसे 'xxhdpi' के नाम से जाना जाता है

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

7.1.2. प्रदर्शन मेट्रिक्स

डिवाइस कार्यान्वयन को android.util.DisplayMetrics [ संसाधन, 39 ] में परिभाषित सभी डिस्प्ले मेट्रिक्स के लिए सही मान रिपोर्ट करना होगा।

7.1.3. स्क्रीन अनुकूलन

डिवाइस को पोर्ट्रेट या लैंडस्केप स्क्रीन ओरिएंटेशन के लिए एप्लिकेशन द्वारा डायनेमिक ओरिएंटेशन का समर्थन करना चाहिए। अर्थात्, डिवाइस को विशिष्ट स्क्रीन ओरिएंटेशन के लिए एप्लिकेशन के अनुरोध का सम्मान करना चाहिए। डिवाइस कार्यान्वयन डिफ़ॉल्ट के रूप में पोर्ट्रेट या लैंडस्केप ओरिएंटेशन का चयन कर सकता है।

जब भी android.content.res.Configuration.orientation, android.view.Display.getOrientation(), या अन्य API के माध्यम से पूछताछ की जाए, तो डिवाइस को डिवाइस के वर्तमान ओरिएंटेशन के लिए सही मान रिपोर्ट करना होगा।

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

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

7.1.4. 2 डी और 3 डी ग्राफिक्स त्वरण

डिवाइस कार्यान्वयन को OpenGL ES 1.0 और 2.0 दोनों का समर्थन करना चाहिए, जैसा कि Android SDK दस्तावेज़ों में सन्निहित और विस्तृत है। डिवाइस कार्यान्वयन को एंड्रॉइड रेंडरस्क्रिप्ट का भी समर्थन करना चाहिए, जैसा कि एंड्रॉइड एसडीके प्रलेखन [ संसाधन, 8 ] में विस्तृत है।

डिवाइस कार्यान्वयन भी ओपनजीएल ईएस 1.0 और 2.0 का समर्थन करने के रूप में खुद को सही ढंग से पहचानना चाहिए। वह है:

प्रबंधित एपीआई (जैसे कि GLES10.getString() विधि के माध्यम से) को OpenGL ES 1.0 और 2.0 के लिए समर्थन की रिपोर्ट करनी चाहिए
देशी C/C ++ OpenGL API (अर्थात, जो libgles_v1cm.so, libgles_v2.so, या libegl.so के माध्यम से ऐप्स के लिए उपलब्ध है, ओपनजीएल ईएस 1.0 और 2.0 के लिए समर्थन की रिपोर्ट करनी चाहिए।

डिवाइस कार्यान्वयन किसी भी वांछित OpenGL ES एक्सटेंशन को लागू कर सकते हैं। हालाँकि, डिवाइस कार्यान्वयन को OpenGL ES प्रबंधित और देशी API के माध्यम से रिपोर्ट करना होगा कि वे समर्थन करते हैं, और इसके विपरीत विस्तार स्ट्रिंग्स की रिपोर्ट नहीं करनी चाहिए जो वे समर्थन नहीं करते हैं।

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

Android 4.2 में अनुप्रयोगों के लिए एक तंत्र शामिल है कि वे यह घोषित करने के लिए कि वे एक प्रकट टैग android:hardwareAccelerated या डायरेक्ट एपीआई कॉल [ संसाधन, 9 ]।

Android 4.2 में, डिवाइस कार्यान्वयन को डिफ़ॉल्ट रूप से हार्डवेयर त्वरण को सक्षम करना होगा, और हार्डवेयर त्वरण को अक्षम करना होगा यदि डेवलपर ने android:hardwareAccelerated="false" या हार्डवेयर त्वरण को सीधे एंड्रॉइड व्यू एपीआई के माध्यम से अक्षम करना।

इसके अलावा, डिवाइस कार्यान्वयन को हार्डवेयर त्वरण [ संसाधन, 9 ] पर एंड्रॉइड एसडीके प्रलेखन के अनुरूप व्यवहार का प्रदर्शन करना चाहिए।

Android 4.2 में एक TextureView ऑब्जेक्ट शामिल है जो डेवलपर्स को सीधे हार्डवेयर-त्वरित OpenGL ES बनावट को एक UI पदानुक्रम में लक्ष्य प्रदान करने के रूप में एकीकृत करने देता है। डिवाइस कार्यान्वयन को TextureView एपीआई का समर्थन करना चाहिए, और अपस्ट्रीम एंड्रॉइड कार्यान्वयन के साथ लगातार व्यवहार का प्रदर्शन करना चाहिए।

7.1.5. लीगेसी एप्लिकेशन संगतता मोड

Android 4.2 एक "संगतता मोड" निर्दिष्ट करता है जिसमें फ्रेमवर्क एक 'सामान्य' स्क्रीन आकार के बराबर (320dp की चौड़ाई) मोड में संचालित होता है, जो कि Android के पुराने संस्करणों के लिए विकसित नहीं किए गए विरासत अनुप्रयोगों के लाभ के लिए है, जो कि पूर्व-तारीख स्क्रीन-आकार की स्वतंत्रता है। डिवाइस कार्यान्वयन में अपस्ट्रीम एंड्रॉइड ओपन सोर्स कोड द्वारा कार्यान्वित के रूप में विरासत एप्लिकेशन संगतता मोड के लिए समर्थन शामिल होना चाहिए। अर्थात्, डिवाइस कार्यान्वयन को उन ट्रिगर्स या थ्रेसहोल्ड को नहीं बदलना चाहिए जिन पर संगतता मोड सक्रिय है, और संगतता मोड के व्यवहार को भी नहीं बदलना चाहिए।

7.1.6. स्क्रीन के प्रकार

डिवाइस कार्यान्वयन स्क्रीन को दो प्रकारों में से एक के रूप में वर्गीकृत किया गया है:

फिक्स्ड-पिक्सेल डिस्प्ले कार्यान्वयन: स्क्रीन एक एकल पैनल है जो केवल एक पिक्सेल चौड़ाई और ऊंचाई का समर्थन करता है। आमतौर पर स्क्रीन को डिवाइस के साथ शारीरिक रूप से एकीकृत किया जाता है। उदाहरणों में मोबाइल फोन, टैबलेट और इतने पर शामिल हैं।
वैरिएबल-पिक्सेल डिस्प्ले कार्यान्वयन: डिवाइस कार्यान्वयन में या तो कोई एम्बेडेड स्क्रीन नहीं है और इसमें वीडियो आउटपुट पोर्ट जैसे वीजीए, एचडीएमआई या डिस्प्ले के लिए वायरलेस पोर्ट शामिल है, या इसमें एक एम्बेडेड स्क्रीन है जो पिक्सेल आयामों को बदल सकती है। उदाहरणों में टीवी, सेट-टॉप बॉक्स, और इतने पर शामिल हैं।

नियत-पिक्सेल डिवाइस कार्यान्वयन

फिक्स्ड-पिक्सेल डिवाइस कार्यान्वयन किसी भी पिक्सेल आयामों की स्क्रीन का उपयोग कर सकते हैं, बशर्ते कि वे इस संगतता परिभाषा को परिभाषित आवश्यकताओं को पूरा करें।

फिक्स्ड-पिक्सेल कार्यान्वयन में बाहरी प्रदर्शन के साथ उपयोग के लिए एक वीडियो आउटपुट पोर्ट शामिल हो सकता है। हालाँकि, यदि उस डिस्प्ले का उपयोग कभी भी ऐप्स चलाने के लिए किया जाता है, तो डिवाइस को निम्न आवश्यकताओं को पूरा करना होगा:

डिवाइस को एक ही स्क्रीन कॉन्फ़िगरेशन की रिपोर्ट करनी चाहिए और मेट्रिक्स प्रदर्शित करनी चाहिए, जैसा कि तय-पिक्सेल डिस्प्ले के रूप में धारा 7.1.1 और 7.1.2 में विस्तृत है।
डिवाइस को फिक्स्ड-पिक्सेल डिस्प्ले के समान तार्किक घनत्व की रिपोर्ट करनी चाहिए।
डिवाइस को स्क्रीन आयामों की रिपोर्ट करनी चाहिए जो कि निश्चित-पिक्सेल डिस्प्ले के समान या बहुत करीब हैं।

For example, a tablet that is 7" diagonal size with a 1024x600 pixel resolution is considered a fixed-pixel large mdpi display implementation. If it contains a video output port that displays at 720p or 1080p, the device implementation MUST scale the output so that एप्लिकेशन केवल एक बड़ी एमडीपीआई विंडो में निष्पादित किए जाते हैं, भले ही फिक्स्ड-पिक्सेल डिस्प्ले या वीडियो आउटपुट पोर्ट उपयोग में हो।

परिवर्तनीय-पिक्सेल डिवाइस कार्यान्वयन

वैरिएबल-पिक्सेल डिवाइस कार्यान्वयन को 1280x720, या 1920x1080 (यानी, 720p या 1080p) में से एक या दोनों का समर्थन करना चाहिए। चर-पिक्सेल डिस्प्ले के साथ डिवाइस कार्यान्वयन किसी अन्य स्क्रीन कॉन्फ़िगरेशन या मोड का समर्थन नहीं करना चाहिए। चर-पिक्सेल स्क्रीन के साथ डिवाइस कार्यान्वयन रनटाइम या बूट-समय पर स्क्रीन कॉन्फ़िगरेशन या मोड बदल सकते हैं। उदाहरण के लिए, सेट-टॉप बॉक्स का उपयोगकर्ता 720p डिस्प्ले को 1080p डिस्प्ले के साथ बदल सकता है, और डिवाइस कार्यान्वयन तदनुसार समायोजित कर सकता है।

इसके अतिरिक्त, वैरिएबल-पिक्सेल डिवाइस कार्यान्वयन को इन पिक्सेल आयामों के लिए निम्नलिखित कॉन्फ़िगरेशन बकेट की रिपोर्ट करनी चाहिए:

1280x720 (जिसे 720p के रूप में भी जाना जाता है): 'बड़े' स्क्रीन आकार, 'TVDPI' (213 dpi) घनत्व
1920x1080 (1080p के रूप में भी जाना जाता है): 'बड़े' स्क्रीन आकार, 'XHDPI' (320 dpi) घनत्व

स्पष्टता के लिए, वैरिएबल पिक्सेल आयामों के साथ डिवाइस कार्यान्वयन एंड्रॉइड 4.2 में 720p या 1080p तक सीमित हैं, और ऊपर उल्लेखित के रूप में स्क्रीन आकार और घनत्व बाल्टी की रिपोर्ट करने के लिए कॉन्फ़िगर किया जाना चाहिए।

7.1.7. स्क्रीन प्रौद्योगिकी

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

उपकरणों को 16-बिट रंग ग्राफिक्स प्रदान करने में सक्षम डिस्प्ले का समर्थन करना चाहिए और 24-बिट रंग ग्राफिक्स में सक्षम प्रदर्शनों का समर्थन करना चाहिए।
डिवाइस को एनिमेशन प्रदान करने में सक्षम डिस्प्ले का समर्थन करना चाहिए।
उपयोग की जाने वाली डिस्प्ले तकनीक में 0.9 और 1.1 के बीच पिक्सेल पहलू अनुपात (PAR) होना चाहिए। यही है, पिक्सेल पहलू अनुपात 10% सहिष्णुता के साथ वर्ग (1.0) के पास होना चाहिए।

7.1.8. बाहरी प्रदर्शन

एंड्रॉइड 4.2 में बाहरी डिस्प्ले तक पहुंचने के लिए मीडिया साझा करने की क्षमताओं और डेवलपर एपीआई को सक्षम करने के लिए द्वितीयक प्रदर्शन के लिए समर्थन शामिल है। यदि कोई डिवाइस किसी बाहरी प्रदर्शन को एक वायर्ड, वायरलेस या एम्बेडेड अतिरिक्त डिस्प्ले कनेक्शन के माध्यम से समर्थन करता है, तो डिवाइस कार्यान्वयन को एंड्रॉइड एसडीके प्रलेखन [ संसाधन, 75 ] में वर्णित के रूप में डिस्प्ले मैनेजर एपीआई को लागू करना होगा। डिवाइस कार्यान्वयन जो सुरक्षित वीडियो आउटपुट का समर्थन करते हैं और सुरक्षित सतहों का समर्थन करने में सक्षम हैं, उन्हें Display.SECURE_FLAG के लिए समर्थन घोषित करना होगा। विशेष रूप से, डिवाइस कार्यान्वयन जो प्रदर्शन के लिए समर्थन की घोषणा करते हैं Display.SECURE_FLAG , Miracast वायरलेस डिस्प्ले या HDCP 1.2 या वायर्ड डिस्प्ले के लिए HDCP 1.2 या उच्चतर के लिए HDCP 2.x या उच्चतर का समर्थन करना चाहिए। अपस्ट्रीम एंड्रॉइड ओपन सोर्स कार्यान्वयन में वायरलेस (मिराकास्ट) के लिए समर्थन शामिल है और वायर्ड (एचडीएमआई) प्रदर्शित करता है जो इस आवश्यकता को पूरा करता है।

7.2. आगत यंत्र

7.2.1. कीबोर्ड

डिवाइस कार्यान्वयन:

इनपुट प्रबंधन ढांचे के लिए समर्थन शामिल होना चाहिए (जो तीसरे पक्ष के डेवलपर्स को इनपुट प्रबंधन इंजन बनाने की अनुमति देता है - यानी सॉफ्ट कीबोर्ड) के रूप में http://developer.android.com पर विस्तृत
कम से कम एक नरम कीबोर्ड कार्यान्वयन प्रदान करना चाहिए (चाहे एक हार्ड कीबोर्ड मौजूद हो)
अतिरिक्त सॉफ्ट कीबोर्ड कार्यान्वयन शामिल हो सकते हैं
एक हार्डवेयर कीबोर्ड शामिल हो सकता है
एक हार्डवेयर कीबोर्ड को शामिल नहीं करना चाहिए जो android.content.res.Configuration.keyboard में निर्दिष्ट प्रारूपों में से एक से मेल नहीं खाता है

डिवाइस कार्यान्वयन:

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

Android नेविगेशन प्रतिमान के लिए घर, मेनू और बैक फ़ंक्शन आवश्यक हैं। डिवाइस कार्यान्वयन को एप्लिकेशन चलाने के दौरान हर समय इन कार्यों को उपयोगकर्ता को उपलब्ध कराना चाहिए। इन कार्यों को समर्पित भौतिक बटन (जैसे यांत्रिक या कैपेसिटिव टच बटन) के माध्यम से लागू किया जा सकता है, या समर्पित सॉफ्टवेयर कुंजियों, इशारों, टच पैनल, आदि का उपयोग करके लागू किया जा सकता है। एंड्रॉइड 4.2 दोनों कार्यान्वयन का समर्थन करता है।

Android 4.2 में सहायता कार्रवाई के लिए समर्थन शामिल है [ संसाधन, 63 ]। डिवाइस कार्यान्वयन को अनुप्रयोगों को चलाने के दौरान हर समय उपयोगकर्ता को सहायता कार्रवाई उपलब्ध कराना चाहिए। यह फ़ंक्शन हार्डवेयर या सॉफ्टवेयर कुंजियों के माध्यम से लागू किया जा सकता है।

डिवाइस कार्यान्वयन नेविगेशन कुंजियों को प्रदर्शित करने के लिए स्क्रीन के एक अलग हिस्से का उपयोग कर सकते हैं, लेकिन यदि हां, तो इन आवश्यकताओं को पूरा करना चाहिए:

डिवाइस कार्यान्वयन नेविगेशन कुंजियों को स्क्रीन के एक अलग हिस्से का उपयोग करना चाहिए, अनुप्रयोगों के लिए उपलब्ध नहीं है, और अनुप्रयोगों के लिए उपलब्ध स्क्रीन के हिस्से के साथ अस्पष्ट या अन्यथा हस्तक्षेप नहीं करना चाहिए।
डिवाइस कार्यान्वयन को उन अनुप्रयोगों के लिए प्रदर्शन का एक हिस्सा उपलब्ध कराना चाहिए जो धारा 7.1.1 में परिभाषित आवश्यकताओं को पूरा करता है।
डिवाइस कार्यान्वयन को नेविगेशन कुंजियों को प्रदर्शित करना होगा जब एप्लिकेशन एक सिस्टम UI मोड निर्दिष्ट नहीं करते हैं, या SYSTEM_UI_FLAG_VISIBLE निर्दिष्ट करते हैं।
डिवाइस कार्यान्वयन को एक विनीत "कम प्रोफ़ाइल" (जैसे। मंद) मोड में नेविगेशन कुंजियों को प्रस्तुत करना होगा जब एप्लिकेशन SYSTEM_UI_FLAG_LOW_PROFILE निर्दिष्ट करते हैं।
डिवाइस कार्यान्वयन को नेविगेशन कुंजियों को छिपाना चाहिए जब एप्लिकेशन SYSTEM_UI_FLAG_HIDE_NAVIGATION निर्दिष्ट करते हैं।
डिवाइस कार्यान्वयन को ApplicationsDkversion <= 10 के लिए एप्लिकेशन के लिए एक मेनू कुंजी प्रस्तुत करनी चाहिए और जब TraffyDkversion> 10 को एक मेनू कुंजी पेश नहीं करना चाहिए।

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

डिवाइस कार्यान्वयन:

किसी तरह का पॉइंटर इनपुट सिस्टम होना चाहिए (या तो माउस-जैसे, या टच)
किसी भी तौर -तरीकों का टचस्क्रीन हो सकता है (जैसे कि कैपेसिटिव या प्रतिरोधक)
यदि टचस्क्रीन कई पॉइंटर्स का समर्थन करता है, तो पूरी तरह से स्वतंत्र रूप से ट्रैक किए गए पॉइंटर्स का समर्थन करना चाहिए
android.content.res.Configuration [ संसाधन, 39 ] के मूल्य की रिपोर्ट करना चाहिए

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

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

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

android.hardware.microphone फ़ीचर निरंतर रिपोर्ट करना चाहिए
धारा 5.4 में ऑडियो गुणवत्ता आवश्यकताओं को पूरा करना चाहिए
धारा 5.5 में ऑडियो विलंबता आवश्यकताओं को पूरा करना चाहिए

7.3. सेंसर

Android 4.2 में विभिन्न प्रकार के सेंसर प्रकारों तक पहुँचने के लिए API शामिल हैं। डिवाइस कार्यान्वयन आम तौर पर इन सेंसर को छोड़ सकते हैं, जैसा कि निम्नलिखित उपखंडों में प्रदान किया गया है। यदि किसी डिवाइस में एक विशेष सेंसर प्रकार शामिल होता है जिसमें तृतीय-पक्ष डेवलपर्स के लिए एक एपीआई होता है, तो डिवाइस कार्यान्वयन को उस एपीआई को लागू करना होगा जैसा कि एंड्रॉइड एसडीके प्रलेखन में वर्णित है। उदाहरण के लिए, डिवाइस कार्यान्वयन:

android.content.pm.PackageManager वर्ग के अनुसार सेंसर की उपस्थिति या अनुपस्थिति की सटीक रूप से रिपोर्ट करना चाहिए। [ संसाधन, 37 ]
SensorManager.getSensorList() और इसी तरह के तरीकों के माध्यम से समर्थित सेंसर की एक सटीक सूची वापस करनी चाहिए
अन्य सभी सेंसर एपीआई के लिए यथोचित व्यवहार करना चाहिए (उदाहरण के लिए, जब अनुप्रयोग श्रोताओं को पंजीकृत करने का प्रयास करते हैं, तो सही के रूप में सही या गलत लौटकर, सेंसर श्रोताओं को नहीं बुलाते हैं जब संबंधित सेंसर मौजूद नहीं होते हैं; आदि)
Android SDK प्रलेखन [ संसाधन, 41 ] में परिभाषित प्रत्येक सेंसर प्रकार के लिए प्रासंगिक अंतर्राष्ट्रीय प्रणाली (यानी मीट्रिक) मूल्यों का उपयोग करके सभी सेंसर माप की रिपोर्ट करनी चाहिए।

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

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

Android 4.2 में एक "स्ट्रीमिंग" सेंसर की एक धारणा शामिल है, जो कि डेटा बदले जाने के बजाय केवल डेटा को लगातार लौटाता है। डिवाइस कार्यान्वयन को स्ट्रीमिंग सेंसर होने के लिए एंड्रॉइड 4.2 एसडीके प्रलेखन द्वारा इंगित किसी भी एपीआई के लिए आवधिक डेटा नमूने प्रदान करना चाहिए। ध्यान दें कि डिवाइस कार्यान्वयन को यह सुनिश्चित करना चाहिए कि सेंसर स्ट्रीम को डिवाइस सीपीयू को निलंबित स्थिति में प्रवेश करने या निलंबित स्थिति से जागने से नहीं रोकना चाहिए।

7.3.1. accelerometer

डिवाइस कार्यान्वयन में 3-अक्ष एक्सेलेरोमीटर शामिल होना चाहिए। यदि डिवाइस कार्यान्वयन में 3-अक्ष एक्सेलेरोमीटर शामिल होता है, तो यह:

120 हर्ट्ज या उससे अधिक पर घटनाओं को वितरित करने में सक्षम होना चाहिए। ध्यान दें कि जबकि ऊपर की एक्सेलेरोमीटर आवृत्ति को एंड्रॉइड 4.2 के लिए "चाहिए" के रूप में कहा गया है, भविष्य के संस्करण के लिए संगतता परिभाषा को इन्हें "चाहिए" में बदलने की योजना है। यही है, ये मानक एंड्रॉइड 4.2 में वैकल्पिक हैं, लेकिन भविष्य के संस्करणों में आवश्यक होंगे । एंड्रॉइड 4.2 को चलाने वाले मौजूदा और नए उपकरणों को एंड्रॉइड 4.2 में इन आवश्यकताओं को पूरा करने के लिए बहुत दृढ़ता से प्रोत्साहित किया जाता है, इसलिए वे भविष्य के मंच रिलीज़ में अपग्रेड करने में सक्षम होंगे
Android API में विस्तृत के रूप में Android सेंसर समन्वय प्रणाली का पालन करना चाहिए (देखें [ संसाधन, 41 ])
किसी भी तीन-आयामी वेक्टर पर दो बार गुरुत्व (2 जी) या उससे अधिक तक फ्रीफॉल से मापने में सक्षम होना चाहिए
सटीकता या अधिक के 8-बिट्स होना चाहिए
एक मानक विचलन होना चाहिए 0.05 m/s^2 से अधिक नहीं

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

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

10 हर्ट्ज या उससे अधिक पर घटनाओं को वितरित करने में सक्षम होना चाहिए
एंड्रॉइड एपीआई में विस्तृत के रूप में एंड्रॉइड सेंसर समन्वय प्रणाली का पालन करना चाहिए (देखें [ संसाधन, 41 ])।
जियोमैग्नेटिक क्षेत्र को कवर करने के लिए पर्याप्त क्षेत्र की ताकत की एक श्रृंखला का नमूना लेने में सक्षम होना चाहिए
सटीकता या अधिक के 8-बिट्स होना चाहिए
एक मानक विचलन 0.5 μt से अधिक नहीं होना चाहिए

7.3.3. GPS

डिवाइस कार्यान्वयन में एक जीपीएस रिसीवर शामिल होना चाहिए। यदि डिवाइस कार्यान्वयन में जीपीएस रिसीवर शामिल होता है, तो इसमें जीपीएस लॉक-ऑन समय को कम करने के लिए "असिस्टेड जीपीएस" तकनीक के कुछ रूप शामिल होने चाहिए।

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

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

तापमान मुआवजा होना चाहिए
5.5*पाई रेडियन/सेकंड तक अभिविन्यास परिवर्तन को मापने में सक्षम होना चाहिए (यानी, लगभग 1,000 डिग्री प्रति सेकंड)
200 हर्ट्ज या उससे अधिक पर घटनाओं को वितरित करने में सक्षम होना चाहिए। ध्यान दें कि जबकि ऊपर की जाइरोस्कोप आवृत्ति को एंड्रॉइड 4.2 के लिए "चाहिए" के रूप में कहा गया है, भविष्य के संस्करण के लिए संगतता परिभाषा को इन्हें "चाहिए" में बदलने की योजना है। यही है, ये मानक एंड्रॉइड 4.2 में वैकल्पिक हैं, लेकिन भविष्य के संस्करणों में आवश्यक होंगे । एंड्रॉइड 4.2 को चलाने वाले मौजूदा और नए उपकरणों को एंड्रॉइड 4.2 में इन आवश्यकताओं को पूरा करने के लिए बहुत दृढ़ता से प्रोत्साहित किया जाता है, इसलिए वे भविष्य के मंच रिलीज़ में अपग्रेड करने में सक्षम होंगे
सटीकता या अधिक के 12-बिट्स होना चाहिए
1E-7 RAD^2 / S^2 प्रति हर्ट्ज (प्रति हर्ट्ज, या रेड^2 / एस) से अधिक एक विचरण नहीं होना चाहिए। विचरण को नमूना दर के साथ भिन्न होने की अनुमति है, लेकिन इस मूल्य से विवश होना चाहिए। दूसरे शब्दों में, यदि आप 1 हर्ट्ज नमूने की दर पर Gyro के विचरण को मापते हैं तो यह 1E-7 RAD^2/S^2 से अधिक नहीं होना चाहिए।
हार्डवेयर इवेंट के रूप में संभव होने पर टाइमस्टैम्प्स के करीब होना चाहिए। निरंतर विलंबता को हटा दिया जाना चाहिए।

7.3.5. बैरोमीटर

डिवाइस कार्यान्वयन में एक बैरोमीटर (यानी परिवेशी वायु दबाव सेंसर शामिल हो सकता है।) यदि किसी डिवाइस कार्यान्वयन में बैरोमीटर शामिल है, तो आईटी:

5 हर्ट्ज या उससे अधिक पर घटनाओं को वितरित करने में सक्षम होना चाहिए
ऊंचाई का आकलन करने में सक्षम करने के लिए पर्याप्त सटीकता होनी चाहिए
तापमान मुआवजा होना चाहिए

7.3.7. थर्मामीटर

डिवाइस कार्यान्वयन हो सकता है, लेकिन इसमें थर्मामीटर (यानी तापमान सेंसर) शामिल नहीं होना चाहिए। यदि डिवाइस कार्यान्वयन में थर्मामीटर शामिल होता है, तो उसे डिवाइस सीपीयू के तापमान को मापना होगा। इसे किसी अन्य तापमान को मापना नहीं चाहिए। (ध्यान दें कि इस सेंसर प्रकार को एंड्रॉइड 4.2 एपीआई में हटा दिया गया है।)

7.3.7. दीप्तिमापी

डिवाइस कार्यान्वयन में एक फोटोमीटर (यानी परिवेश प्रकाश सेंसर) शामिल हो सकते हैं।

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

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

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

7.4.1. टेलीफ़ोनी

"टेलीफोनी" जैसा कि एंड्रॉइड 4.2 एपीआई द्वारा उपयोग किया जाता है और यह दस्तावेज़ विशेष रूप से वॉयस कॉल रखने और जीएसएम या सीडीएमए नेटवर्क के माध्यम से एसएमएस संदेश भेजने से संबंधित हार्डवेयर को संदर्भित करता है। हालांकि इन वॉयस कॉल को पैकेट-स्विच किया जा सकता है या नहीं, वे एंड्रॉइड 4.2 के प्रयोजनों के लिए हैं जो किसी भी डेटा कनेक्टिविटी से स्वतंत्र माना जाता है जिसे उसी नेटवर्क का उपयोग करके लागू किया जा सकता है। दूसरे शब्दों में, एंड्रॉइड "टेलीफोनी" कार्यक्षमता और एपीआई विशेष रूप से वॉयस कॉल और एसएमएस को संदर्भित करते हैं; उदाहरण के लिए, डिवाइस कार्यान्वयन जो कॉल नहीं कर सकते हैं या एसएमएस संदेश भेज सकते हैं, उन्हें "Android.hardware.telephony" सुविधा या किसी भी उप-सुविधाओं की रिपोर्ट नहीं करनी चाहिए, भले ही वे डेटा कनेक्टिविटी के लिए एक सेलुलर नेटवर्क का उपयोग करें।

Android 4.2 का उपयोग उन उपकरणों पर किया जा सकता है जिनमें टेलीफोनी हार्डवेयर शामिल नहीं है। यही है, Android 4.2 उन उपकरणों के साथ संगत है जो फोन नहीं हैं। हालांकि, यदि डिवाइस कार्यान्वयन में जीएसएम या सीडीएमए टेलीफोनी शामिल है, तो उसे उस तकनीक के लिए एपीआई के लिए पूर्ण समर्थन लागू करना होगा। डिवाइस कार्यान्वयन जिसमें टेलीफोनी हार्डवेयर शामिल नहीं है, को पूर्ण एपीआई को एन-ऑप्स के रूप में लागू करना होगा।

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

एंड्रॉइड 4.2 डिवाइस कार्यान्वयन में 802.11 (बी/जी/ए/एन, आदि) के एक या एक से अधिक रूपों के लिए समर्थन शामिल होना चाहिए। यदि डिवाइस कार्यान्वयन में 802.11 के लिए समर्थन शामिल है, तो इसे संबंधित एंड्रॉइड एपीआई को लागू करना होगा।

डिवाइस कार्यान्वयन को एसडीके प्रलेखन [ संसाधन, 62 ] में वर्णित मल्टीकास्ट एपीआई को लागू करना होगा। डिवाइस कार्यान्वयन जिसमें WIFI समर्थन शामिल है, मल्टीकास्ट DNS (MDNS) का समर्थन करना चाहिए। डिवाइस कार्यान्वयन को ऑपरेशन के किसी भी समय एमडीएनएस पैकेट (224.0.0.251) को फ़िल्टर नहीं करना चाहिए, जिसमें स्क्रीन सक्रिय स्थिति में नहीं होती है।

7.4.2.1. Wi-Fi डायरेक्ट

डिवाइस कार्यान्वयन में वाईफाई डायरेक्ट (वाईफाई पीयर-टू-पीयर) के लिए समर्थन शामिल होना चाहिए। यदि डिवाइस कार्यान्वयन में वाईफाई डायरेक्ट के लिए समर्थन शामिल है, तो उसे एसडीके प्रलेखन [ संसाधन, 68 ] में वर्णित के रूप में संबंधित एंड्रॉइड एपीआई को लागू करना होगा। यदि डिवाइस कार्यान्वयन में वाईफाई डायरेक्ट के लिए समर्थन शामिल है, तो यह:

नियमित वाईफाई ऑपरेशन का समर्थन करना चाहिए
समवर्ती वाईफाई और वाईफाई डायरेक्ट ऑपरेशन का समर्थन करना चाहिए

7.4.3. ब्लूटूथ

डिवाइस कार्यान्वयन में एक ब्लूटूथ ट्रांसीवर शामिल होना चाहिए। डिवाइस कार्यान्वयन जिसमें एक ब्लूटूथ ट्रांसीवर शामिल है, को RFCOMM- आधारित ब्लूटूथ एपीआई को सक्षम करना चाहिए जैसा कि एसडीके प्रलेखन [ संसाधन, 42 ] में वर्णित है। डिवाइस कार्यान्वयन को प्रासंगिक ब्लूटूथ प्रोफाइल, जैसे कि A2DP, AVRCP, OBEX, आदि को डिवाइस के लिए उपयुक्त माना जाना चाहिए।

संगतता परीक्षण सूट में ऐसे मामले शामिल हैं जो एंड्रॉइड RFCOMM ब्लूटूथ एपीआई के बुनियादी संचालन को कवर करते हैं। हालाँकि, चूंकि ब्लूटूथ उपकरणों के बीच एक संचार प्रोटोकॉल है, इसलिए इसे एक ही डिवाइस पर चलने वाले यूनिट परीक्षणों द्वारा पूरी तरह से परीक्षण नहीं किया जा सकता है। नतीजतन, डिवाइस कार्यान्वयन को परिशिष्ट ए में वर्णित मानव-चालित ब्लूटूथ परीक्षण प्रक्रिया को भी पास करना होगा।

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

डिवाइस कार्यान्वयन में निकट-क्षेत्र संचार (NFC) के लिए एक ट्रांसीवर और संबंधित हार्डवेयर शामिल होना चाहिए। यदि डिवाइस कार्यान्वयन में एनएफसी हार्डवेयर शामिल है, तो यह:

Android.hardware.nfc फ़ीचर को android.content.pm.PackageManager.hasSystemFeature() विधि से रिपोर्ट करना होगा। [ संसाधन, 37 ]
निम्नलिखित NFC मानकों के माध्यम से NDEF संदेश पढ़ने और लिखने में सक्षम होना चाहिए:
- एनएफसी फोरम रीडर/राइटर (जैसा कि एनएफसी फोरम तकनीकी विनिर्देश NFCFORUM-TIGITALPROTOCOL-1.0 द्वारा परिभाषित किया गया है) के रूप में निम्नलिखित NFC मानकों के माध्यम से अभिनय करने में सक्षम होना चाहिए:
  - NFCA (ISO14443-3A)
  - NFCB (ISO14443-3B)
  - NFCF (JIS 6319-4)
  - ISODEP (ISO 14443-4)
  - एनएफसी फोरम टैग प्रकार 1, 2, 3, 4 (एनएफसी फोरम द्वारा परिभाषित)
निम्नलिखित NFC मानकों के माध्यम से NDEF संदेश पढ़ने और लिखने में सक्षम होना चाहिए। ध्यान दें कि जबकि एनएफसी मानकों को एंड्रॉइड 4.2 के लिए "चाहिए" के रूप में कहा गया है, भविष्य के संस्करण के लिए संगतता परिभाषा को इन्हें "मस्ट" में बदलने की योजना है। यही है, ये मानक एंड्रॉइड 4.2 में वैकल्पिक हैं, लेकिन भविष्य के संस्करणों में आवश्यक होंगे । एंड्रॉइड 4.2 को चलाने वाले मौजूदा और नए उपकरणों को एंड्रॉइड 4.2 में इन आवश्यकताओं को पूरा करने के लिए बहुत दृढ़ता से प्रोत्साहित किया जाता है ताकि वे भविष्य के प्लेटफ़ॉर्म रिलीज में अपग्रेड कर सकें।
- एनएफसीवी (आईएसओ 15693)
निम्नलिखित सहकर्मी से सहकर्मी मानकों और प्रोटोकॉल के माध्यम से डेटा प्रसारित करने और प्राप्त करने में सक्षम होना चाहिए:
- आईएसओ 18092
- एलएलसीपी 1.0 (एनएफसी फोरम द्वारा परिभाषित)
- एसडीपी 1.0 (एनएफसी फोरम द्वारा परिभाषित)
- NDEF पुश प्रोटोकॉल [ संसाधन, 43 ]
- एसएनईपी 1.0 (एनएफसी फोरम द्वारा परिभाषित)
एंड्रॉइड बीम के लिए समर्थन शामिल होना चाहिए [ संसाधन, 65 ]:
- SNEP डिफ़ॉल्ट सर्वर को लागू करना होगा। डिफ़ॉल्ट SNEP सर्वर द्वारा प्राप्त मान्य NDEF संदेशों को Android.nfc.action_ndef_discovered इरादे का उपयोग करके अनुप्रयोगों के लिए भेजा जाना चाहिए। सेटिंग्स में एंड्रॉइड बीम को अक्षम करना आने वाले एनडीईएफ संदेश के प्रेषण को अक्षम नहीं करना चाहिए।
- डिवाइस कार्यान्वयन को Android.settings.nfcsharing_settings को NFC शेयरिंग सेटिंग्स [ संसाधन, 67 ] दिखाने के इरादे से सम्मानित करना चाहिए।
- एनपीपी सर्वर को लागू करना होगा। NPP सर्वर द्वारा प्राप्त संदेशों को SNEP डिफ़ॉल्ट सर्वर की तरह ही संसाधित किया जाना चाहिए।
- Android Beam सक्षम होने पर एक SNEP क्लाइंट को लागू करना चाहिए और डिफ़ॉल्ट SNEP सर्वर पर आउटबाउंड P2P NDEF भेजने का प्रयास करना चाहिए। यदि कोई डिफ़ॉल्ट SNEP सर्वर नहीं मिला है, तो क्लाइंट को NPP सर्वर पर भेजने का प्रयास करना होगा।
- Android.nfc.nfcadapter.setndefpushmessage, और android.nfc.nfcadapter.setndefpushmessagecallback, और android.nfc.nfcadapter.enableforgroundndefpush का उपयोग करके आउटबाउंड P2P NDEF संदेश को सेट करने की अनुमति देनी चाहिए।
- आउटबाउंड P2P NDEF संदेश भेजने से पहले, एक इशारे या ऑन-स्क्रीन पुष्टि का उपयोग करना चाहिए, जैसे 'टच टू बीम'।
- डिफ़ॉल्ट रूप से एंड्रॉइड बीम को सक्षम करना चाहिए
- जब डिवाइस ब्लूटूथ ऑब्जेक्ट पुश प्रोफाइल का समर्थन करता है तो ब्लूटूथ को NFC कनेक्शन हैंडओवर का समर्थन करना चाहिए। डिवाइस कार्यान्वयन को Android.nfc.nfcadapter.setbeampushuris का उपयोग करते समय ब्लूटूथ को कनेक्शन हैंडओवर का समर्थन करना चाहिए, "कनेक्शन हैंडओवर संस्करण 1.2" [ संसाधन, 60 ] और "ब्लूटूथ सिक्योर सिंपल पेयरिंग एनएफसी संस्करण 1.0" [ संसाधन, 61 ] से चश्मा द्वारा " एनएफसी फोरम। इस तरह के कार्यान्वयन को NFC पर हैंडओवर अनुरोध / चयन रिकॉर्ड का आदान -प्रदान करने के लिए SNEP GET अनुरोधों का उपयोग करना चाहिए, और इसे वास्तविक ब्लूटूथ डेटा ट्रांसफर के लिए ब्लूटूथ ऑब्जेक्ट पुश प्रोफाइल का उपयोग करना चाहिए।
NFC डिस्कवरी मोड में रहते हुए सभी समर्थित प्रौद्योगिकियों के लिए मतदान करना चाहिए।
एनएफसी डिस्कवरी मोड में होना चाहिए जबकि डिवाइस स्क्रीन के सक्रिय और लॉक-स्क्रीन के साथ जागृत हो।

(ध्यान दें कि सार्वजनिक रूप से उपलब्ध लिंक JIS, ISO, और NFC फोरम विनिर्देशों के लिए उपलब्ध नहीं हैं।)

इसके अतिरिक्त, डिवाइस कार्यान्वयन में निम्नलिखित MIFARE प्रौद्योगिकियों के लिए पाठक/लेखक का समर्थन शामिल हो सकता है।

Mifare क्लासिक (NXP MF1S503X [ संसाधन, 44 ], MF1S703X [ संसाधन, 44 ])
MIFARE ULTRALIGHT (NXP MF0ICU1 [ संसाधन, 46 ], MF0ICU2 [ संसाधन, 46 ])
Mifare क्लासिक पर NDEF (NXP AN130511 [ संसाधन, 48 ], AN130411 [ संसाधन, 49 ])

ध्यान दें कि Android 4.2 में इन Mifare प्रकारों के लिए API शामिल हैं। यदि कोई डिवाइस कार्यान्वयन पाठक/लेखक की भूमिका में MIFARE का समर्थन करता है, तो IT:

Android SDK द्वारा प्रलेखित के रूप में संबंधित Android API को लागू करना चाहिए
android.content.pm.PackageManager.hasSystemFeature() विधि से feature com.nxp.mifare की रिपोर्ट करनी चाहिए। ] PackageManager
जब तक यह इस खंड में वर्णित सामान्य NFC समर्थन को लागू नहीं करता है, तब तक इसी Android API को लागू नहीं करना चाहिए और न ही com.nxp.mifare सुविधा की रिपोर्ट करें

यदि एक डिवाइस कार्यान्वयन में NFC हार्डवेयर शामिल नहीं है, तो इसे Android.hardware.nfc फ़ीचर को android.content.pm.PackageManager.hasSystemFeature() विधि [ संसाधन, 37 ] से घोषित नहीं करना चाहिए, और Android 4.2 NFC API को लागू करना होगा एक नो-ऑप।

कक्षाओं के रूप में android.nfc.NdefMessage और android.nfc.NdefRecord एक प्रोटोकॉल-स्वतंत्र डेटा प्रतिनिधित्व प्रारूप का प्रतिनिधित्व करते हैं, डिवाइस कार्यान्वयन को इन API को लागू करना होगा, भले ही वे NFC के लिए समर्थन शामिल न करें या Android.hardware.nfc सुविधा की घोषणा करें।

7.4.5. न्यूनतम नेटवर्क क्षमता

डिवाइस कार्यान्वयन में डेटा नेटवर्किंग के एक या अधिक रूपों के लिए समर्थन शामिल होना चाहिए। विशेष रूप से, डिवाइस कार्यान्वयन में 200kbit/सेकंड या उससे अधिक के लिए कम से कम एक डेटा मानक के लिए समर्थन शामिल होना चाहिए। इस आवश्यकता को पूरा करने वाली प्रौद्योगिकियों के उदाहरणों में एज, एचएसपीए, ईवी-डो, 802.11 जी, ईथरनेट, आदि शामिल हैं।

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

डिवाइस डेटा कनेक्टिविटी के एक से अधिक रूपों को लागू कर सकते हैं।

7.5. कैमरा

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

7.5.1. रियर-फेसिंग कैमरा

डिवाइस कार्यान्वयन में एक रियर-फेसिंग कैमरा शामिल होना चाहिए। यदि डिवाइस कार्यान्वयन में एक रियर-फेसिंग कैमरा शामिल है, तो यह:

कम से कम 2 मेगापिक्सल का संकल्प होना चाहिए
या तो हार्डवेयर ऑटो-फोकस, या सॉफ्टवेयर ऑटो-फोकस को कैमरा ड्राइवर में लागू किया जाना चाहिए (एप्लिकेशन सॉफ़्टवेयर के लिए पारदर्शी)
फिक्स्ड-फोकस या EDOF (फ़ील्ड की विस्तारित गहराई) हार्डवेयर हो सकता है
एक फ्लैश शामिल हो सकता है। यदि कैमरे में एक फ्लैश शामिल है, तो फ्लैश लैंप को नहीं जलाया जाना चाहिए जबकि Android.hardware.camera.previewcallback इंस्टेंस को कैमरा प्रीव्यू सतह पर पंजीकृत किया गया है, जब तक कि एप्लिकेशन ने FLASH_MODE_AUTO या FLASH_MODE_ON विशेषताओं को स्पष्ट रूप से सक्षम नहीं किया है। Camera.Parameters ऑब्जेक्ट। ध्यान दें कि यह बाधा डिवाइस के अंतर्निहित सिस्टम कैमरा एप्लिकेशन पर लागू नहीं होती है, लेकिन केवल Camera.PreviewCallback उपयोग करके तृतीय-पक्ष एप्लिकेशन के लिए।

7.5.2. सामने की ओर मुख किया हुआ कैमरा

डिवाइस कार्यान्वयन में फ्रंट-फेसिंग कैमरा शामिल हो सकता है। यदि डिवाइस कार्यान्वयन में फ्रंट-फेसिंग कैमरा शामिल है, तो यह:

कम से कम VGA (यानी, 640x480 पिक्सल) का संकल्प होना चाहिए
कैमरा एपीआई के लिए डिफ़ॉल्ट के रूप में फ्रंट-फेसिंग कैमरे का उपयोग नहीं करना चाहिए। अर्थात्, एंड्रॉइड 4.2 में कैमरा एपीआई को फ्रंट-फेसिंग कैमरों के लिए विशिष्ट समर्थन है, और डिवाइस कार्यान्वयन को एपीआई को कॉन्फ़िगर नहीं करना चाहिए ताकि फ्रंट-फेसिंग कैमरे को डिफ़ॉल्ट रियर-फेसिंग कैमरा के रूप में इलाज किया जा सके, भले ही यह एकमात्र कैमरा हो युक्ति।
धारा 7.5.1 में वर्णित के रूप में रियर-फेसिंग कैमरों के लिए उपलब्ध सुविधाओं (जैसे ऑटो-फोकस, फ्लैश, आदि) शामिल हो सकते हैं।
क्षैतिज रूप से प्रतिबिंबित करना चाहिए (यानी दर्पण) एक कैमरेप्रेव्यू में एक ऐप द्वारा प्रदर्शित स्ट्रीम, निम्नानुसार है:

यदि डिवाइस कार्यान्वयन उपयोगकर्ता द्वारा घुमाए जाने में सक्षम है (जैसे कि स्वचालित रूप से एक्सेलेरोमीटर के माध्यम से या मैन्युअल रूप से उपयोगकर्ता इनपुट के माध्यम से), तो कैमरा पूर्वावलोकन को डिवाइस के वर्तमान अभिविन्यास के सापेक्ष क्षैतिज रूप से प्रतिबिंबित किया जाना चाहिए।
यदि वर्तमान एप्लिकेशन ने स्पष्ट रूप से अनुरोध किया है कि कैमरा डिस्प्ले को android.hardware.Camera.setDisplayOrientation() [ संसाधन, 50 ] विधि के लिए कॉल के माध्यम से घुमाया जाए, तो कैमरा पूर्वावलोकन को एप्लिकेशन द्वारा निर्दिष्ट अभिविन्यास के सापेक्ष क्षैतिज रूप से प्रतिबिंबित किया जाना चाहिए।
अन्यथा, पूर्वावलोकन को डिवाइस के डिफ़ॉल्ट क्षैतिज अक्ष के साथ प्रतिबिंबित किया जाना चाहिए।

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

7.5.3. कैमरा एपीआई व्यवहार

डिवाइस कार्यान्वयन को कैमरे से संबंधित एपीआई के लिए निम्नलिखित व्यवहारों को लागू करना होगा, दोनों के लिए फ्रंट और रियर-फेसिंग कैमरों के लिए:

यदि किसी एप्लिकेशन ने कभी भी android.hardware.Camera.Parameters.setPreviewFormat(int) नहीं कहा है, तो डिवाइस को android.hardware.PixelFormat.YCbCr_420_SP का उपयोग करना चाहिए, जो एप्लिकेशन कॉलबैक को प्रदान किए गए पूर्वावलोकन डेटा के लिए है।
यदि कोई एप्लिकेशन android.hardware.Camera.PreviewCallback इंस्टेंस को पंजीकृत करता है और सिस्टम onPreviewFrame() विधि को कॉल करता है जब पूर्वावलोकन प्रारूप YCBCR_420_SP होता है, तो byte[] onPreviewFrame() NV21 एन्कोडिंग प्रारूप में आगे होना चाहिए। अर्थात्, NV21 डिफ़ॉल्ट होना चाहिए।
डिवाइस कार्यान्वयन को YV12 प्रारूप का समर्थन करना चाहिए (जैसा कि android.graphics.ImageFormat.YV12 निरंतर) दोनों के लिए फ्रंट और रियर-फेसिंग कैमरों के लिए कैमरा प्रीव्यू के लिए। (हार्डवेयर वीडियो एनकोडर और कैमरा किसी भी देशी पिक्सेल प्रारूप का उपयोग कर सकते हैं, लेकिन डिवाइस कार्यान्वयन को YV12 में रूपांतरण का समर्थन करना चाहिए।)

डिवाइस कार्यान्वयन को एंड्रॉइड 4.2 एसडीके प्रलेखन [ संसाधन, 51 ]) में शामिल पूर्ण कैमरा एपीआई को लागू करना होगा, भले ही डिवाइस में हार्डवेयर ऑटोफोकस या अन्य क्षमताएं शामिल हों। उदाहरण के लिए, ऑटोफोकस की कमी वाले कैमरों को अभी भी किसी भी पंजीकृत android.hardware.Camera.AutoFocusCallback उदाहरणों को कॉल करना चाहिए (भले ही यह गैर-ऑटोफोकस कैमरा के लिए कोई प्रासंगिकता नहीं है।) ध्यान दें कि यह फ्रंट-फेसिंग कैमरों पर लागू होता है; उदाहरण के लिए, भले ही अधिकांश फ्रंट-फेसिंग कैमरे ऑटोफोकस का समर्थन नहीं करते हैं, लेकिन एपीआई कॉलबैक को अभी भी "फेक" होना चाहिए जैसा कि वर्णित है।

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

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

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

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

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

7.6. मेमोरी और स्टोरेज

7.6.1. न्यूनतम मेमोरी और स्टोरेज

डिवाइस कार्यान्वयन में कर्नेल और उपयोगकर्ताओं के लिए कम से कम 340MB मेमोरी उपलब्ध होनी चाहिए। 340MB को रेडियो, वीडियो, और इसी तरह हार्डवेयर घटकों के लिए समर्पित किसी भी मेमोरी के अलावा कर्नेल के नियंत्रण में नहीं होना चाहिए।

डिवाइस कार्यान्वयन में कम से कम 350MB गैर-वाष्पशील भंडारण हो सकता है जो एप्लिकेशन निजी डेटा के लिए उपलब्ध है। अर्थात्, /data विभाजन कम से कम 350MB होना चाहिए।

Android API में एक डाउनलोड प्रबंधक शामिल है जो एप्लिकेशन डेटा फ़ाइलों को डाउनलोड करने के लिए उपयोग कर सकते हैं [ संसाधन, 56 ]। डाउनलोड प्रबंधक का डिवाइस कार्यान्वयन डिफ़ॉल्ट "कैश" स्थान पर कम से कम 100mb आकार की व्यक्तिगत फ़ाइलों को डाउनलोड करने में सक्षम होना चाहिए।

7.6.2. अनुप्रयोग साझा संग्रहण

डिवाइस कार्यान्वयन को अनुप्रयोगों के लिए साझा भंडारण की पेशकश करनी चाहिए। प्रदान किया गया साझा भंडारण आकार में कम से कम 1GB होना चाहिए।

डिवाइस कार्यान्वयन को साझा संग्रहण के साथ डिफ़ॉल्ट रूप से, "बॉक्स से बाहर" के साथ कॉन्फ़िगर किया जाना चाहिए। यदि साझा भंडारण लिनक्स पथ /sdcard पर नहीं लगाया जाता है, तो डिवाइस को वास्तविक माउंट पॉइंट तक /sdcard से एक लिनक्स प्रतीकात्मक लिंक शामिल होना चाहिए।

डिवाइस कार्यान्वयन को इस साझा संग्रहण पर android.permission.WRITE_EXTERNAL_STORAGE अनुमति के रूप में प्रलेखित किया जाना चाहिए। साझा भंडारण अन्यथा किसी भी एप्लिकेशन द्वारा लिखित होना चाहिए जो उस अनुमति को प्राप्त करता है।

डिवाइस कार्यान्वयन में उपयोगकर्ता-सुलभ हटाने योग्य भंडारण के लिए हार्डवेयर हो सकता है, जैसे कि एक सुरक्षित डिजिटल कार्ड। वैकल्पिक रूप से, डिवाइस कार्यान्वयन एप्लिकेशन के लिए साझा संग्रहण के रूप में आंतरिक (गैर-पुनर्जीवित) भंडारण को आवंटित कर सकते हैं।

उपयोग किए गए साझा भंडारण के रूप के बावजूद, डिवाइस कार्यान्वयन को एक मेजबान कंप्यूटर से साझा संग्रहण की सामग्री तक पहुंचने के लिए कुछ तंत्र प्रदान करना चाहिए, जैसे कि यूएसबी मास स्टोरेज (यूएमएस) या मीडिया ट्रांसफर प्रोटोकॉल (एमटीपी)। डिवाइस कार्यान्वयन USB मास स्टोरेज का उपयोग कर सकते हैं, लेकिन मीडिया ट्रांसफर प्रोटोकॉल का उपयोग करना चाहिए। यदि डिवाइस कार्यान्वयन मीडिया हस्तांतरण प्रोटोकॉल का समर्थन करता है:

डिवाइस कार्यान्वयन संदर्भ एंड्रॉइड एमटीपी होस्ट, एंड्रॉइड फ़ाइल ट्रांसफर [ संसाधन, 57 ] के साथ संगत होना चाहिए।
डिवाइस कार्यान्वयन को 0x00 के USB डिवाइस क्लास की रिपोर्ट करनी चाहिए।
डिवाइस कार्यान्वयन को 'MTP' के USB इंटरफ़ेस नाम की रिपोर्ट करनी चाहिए।

यदि डिवाइस कार्यान्वयन में USB पोर्ट का अभाव है, तो उसे किसी अन्य माध्यम से साझा संग्रहण की सामग्री तक पहुंच के साथ एक होस्ट कंप्यूटर प्रदान करना होगा, जैसे कि नेटवर्क फ़ाइल सिस्टम।

यह दो सामान्य उदाहरणों पर विचार करना है। यदि एक डिवाइस कार्यान्वयन में साझा संग्रहण आवश्यकता को पूरा करने के लिए एक एसडी कार्ड स्लॉट शामिल है, तो एक वसा-स्वरूपित एसडी कार्ड 1 जीबी आकार में या उससे अधिक को डिवाइस के साथ शामिल किया जाना चाहिए जैसा कि उपयोगकर्ताओं को बेचा जाता है, और डिफ़ॉल्ट रूप से माउंट किया जाना चाहिए। वैकल्पिक रूप से, यदि कोई डिवाइस कार्यान्वयन इस आवश्यकता को पूरा करने के लिए आंतरिक निश्चित भंडारण का उपयोग करता है, तो उस भंडारण को आकार में 1GB या बड़ा होना चाहिए और /sdcard (या /sdcard भौतिक स्थान के लिए एक प्रतीकात्मक लिंक होना चाहिए यदि यह कहीं और घुड़सवार है।)

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

7.7. USB

डिवाइस कार्यान्वयन में एक USB क्लाइंट पोर्ट शामिल होना चाहिए, और इसमें USB होस्ट पोर्ट शामिल होना चाहिए।

यदि डिवाइस कार्यान्वयन में USB क्लाइंट पोर्ट शामिल है:

पोर्ट को एक मानक USB-A पोर्ट के साथ USB होस्ट से कनेक्ट करने योग्य होना चाहिए
पोर्ट को डिवाइस साइड पर माइक्रो यूएसबी फॉर्म फैक्टर का उपयोग करना चाहिए। एंड्रॉइड 4.2 को चलाने वाले मौजूदा और नए उपकरणों को एंड्रॉइड 4.2 में इन आवश्यकताओं को पूरा करने के लिए बहुत दृढ़ता से प्रोत्साहित किया जाता है, इसलिए वे भविष्य के मंच रिलीज़ में अपग्रेड करने में सक्षम होंगे
बंदरगाह को एक किनारे के बीच में केंद्रित किया जाना चाहिए। डिवाइस कार्यान्वयन या तो डिवाइस के तल पर पोर्ट का पता लगाना चाहिए (प्राकृतिक अभिविन्यास के अनुसार) या सभी ऐप्स (होम स्क्रीन सहित) के लिए सॉफ़्टवेयर स्क्रीन रोटेशन को सक्षम करें, ताकि डिवाइस नीचे पोर्ट के साथ उन्मुख होने पर डिस्प्ले सही ढंग से ड्रॉ हो जाए। एंड्रॉइड 4.2 को चलाने वाले मौजूदा और नए उपकरणों को एंड्रॉइड 4.2 में इन आवश्यकताओं को पूरा करने के लिए बहुत दृढ़ता से प्रोत्साहित किया जाता है ताकि वे भविष्य के प्लेटफ़ॉर्म रिलीज में अपग्रेड कर सकें।
यदि डिवाइस में अन्य पोर्ट हैं (जैसे कि गैर-यूएसबी चार्जिंग पोर्ट) यह माइक्रो-यूएसबी पोर्ट के समान किनारे पर होना चाहिए
यह डिवाइस से जुड़े होस्ट को USB मास स्टोरेज या मीडिया ट्रांसफर प्रोटोकॉल का उपयोग करके साझा स्टोरेज वॉल्यूम की सामग्री तक पहुंचने की अनुमति देनी चाहिए
इसे एंड्रॉइड ओपन एक्सेसरी एपीआई और स्पेसिफिकेशन को एंड्रॉइड एसडीके डॉक्यूमेंटेशन में प्रलेखित के रूप में लागू करना होगा, और हार्डवेयर फ़ीचर android.hardware.usb.accessory [ संसाधन, 52 ] के लिए समर्थन घोषित करना होगा।
यह Android SDK प्रलेखन [ संसाधन, 66 ] में प्रलेखित के रूप में USB ऑडियो वर्ग को लागू करना होगा
it SHOULD implement support for USB battery charging specification [ Resources, 64 ] Existing and new devices that run Android 4.2 are very strongly encouraged to meet these requirements in Android 4.2 so they will be able to upgrade to the future platform releases

If a device implementation includes a USB host port:

it MAY use a non-standard port form factor, but if so MUST ship with a cable or cables adapting the port to standard USB-A
it MUST implement the Android USB host API as documented in the Android SDK, and MUST declare support for the hardware feature android.hardware.usb.host [ Resources, 53 ]

Device implementations MUST implement the Android Debug Bridge. If a device implementation omits a USB client port, it MUST implement the Android Debug Bridge via local-area network (such as Ethernet or 802.11)

8. प्रदर्शन अनुकूलता

Device implementations MUST meet the key performance metrics of an Android 4.2 compatible device defined in the table below:

मीट्रिक	प्रदर्शन सीमा	टिप्पणियाँ
Application Launch Time	The following applications should launch within the specified time. ब्राउज़र: 1300ms से कम Contacts: less than 700ms Settings: less than 700ms	The launch time is measured as the total time to complete loading the default activity for the application, including the time it takes to start the Linux process, load the Android package into the Dalvik VM, and call onCreate.
Simultaneous Applications	When multiple applications have been launched, re-launching an already-running application after it has been launched must take less than the original launch time.

9. सुरक्षा मॉडल संगतता

Device implementations MUST implement a security model consistent with the Android platform security model as defined in Security and Permissions reference document in the APIs [ Resources, 54 ] in the Android developer documentation. Device implementations MUST support installation of self-signed applications without requiring any additional permissions/certificates from any third parties/authorities. Specifically, compatible devices MUST support the security mechanisms described in the follow sub-sections.

9.1. अनुमतियां

Device implementations MUST support the Android permissions model as defined in the Android developer documentation [ Resources, 54 ]. Specifically, implementations MUST enforce each permission defined as described in the SDK documentation; किसी भी अनुमति को छोड़ा, बदल दिया जा सकता है या अनदेखा नहीं किया जा सकता है। Implementations MAY add additional permissions, provided the new permission ID strings are not in the android.* namespace.

9.2. यूआईडी और प्रक्रिया अलगाव

Device implementations MUST support the Android application sandbox model, in which each application runs as a unique Unix-style UID and in a separate process. Device implementations MUST support running multiple applications as the same Linux user ID, provided that the applications are properly signed and constructed, as defined in the Security and Permissions reference [ Resources, 54 ].

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

Device implementations MUST support the Android file access permissions model as defined in as defined in the Security and Permissions reference [ Resources, 54 ].

9.4. वैकल्पिक निष्पादन वातावरण

Device implementations MAY include runtime environments that execute applications using some other software or technology than the Dalvik virtual machine or native code. However, such alternate execution environments MUST NOT compromise the Android security model or the security of installed Android applications, as described in this section.

Alternate runtimes MUST themselves be Android applications, and abide by the standard Android security model, as described elsewhere in Section 9.

Alternate runtimes MUST NOT be granted access to resources protected by permissions not requested in the runtime's AndroidManifest.xml file via the <uses-permission> mechanism.

Alternate runtimes MUST NOT permit applications to make use of features protected by Android permissions restricted to system applications.

Alternate runtimes MUST abide by the Android sandbox model. विशेष रूप से:

Alternate runtimes SHOULD install apps via the PackageManager into separate Android sandboxes (that is, Linux user IDs, etc.)
Alternate runtimes MAY provide a single Android sandbox shared by all applications using the alternate runtime
Alternate runtimes and installed applications using an alternate runtime MUST NOT reuse the sandbox of any other app installed on the device, except through the standard Android mechanisms of shared user ID and signing certificate
Alternate runtimes MUST NOT launch with, grant, or be granted access to the sandboxes corresponding to other Android applications

Alternate runtimes MUST NOT be launched with, be granted, or grant to other applications any privileges of the superuser (root), or of any other user ID.

The .apk files of alternate runtimes MAY be included in the system image of a device implementation, but MUST be signed with a key distinct from the key used to sign other applications included with the device implementation.

When installing applications, alternate runtimes MUST obtain user consent for the Android permissions used by the application. That is, if an application needs to make use of a device resource for which there is a corresponding Android permission (such as Camera, GPS, etc.), the alternate runtime MUST inform the user that the application will be able to access that resource . If the runtime environment does not record application capabilities in this manner, the runtime environment MUST list all permissions held by the runtime itself when installing any application using that runtime.

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

Android 4.2 includes support for multiple users and provides support for full user isolation [ Resources, 70 ].

Device implementations MUST meet these requirements related to multi-user support[ Resources, 71 ]:

As the behavior of the telephony APIs on devices with multiple users is currently undefined, device implementations that declare android.hardware.telephony MUST NOT enable multi-user support.
Device implementations MUST, for each user, implement a security model consistent with the Android platform security model as defined in Security and Permissions reference document in the APIs [Resources, 54]

Each user instance on an Android device MUST have separate and isolated external storage directories. Device implementations MAY store multiple users' data on the same volume or filesystem. However, the device implementation MUST ensure that applications owned by and running on behalf a given user cannot list, read, or write to data owned by any other user. Note that removable media, such as SD card slots, can allow one user to access another's data by means of a host PC. For this reason, device implementations that use removable media for the external storage APIs MUST encrypt the contents of the SD card if multi-user is enabled using a key stored only on non-removable media accessible only to the system. As this will make the media unreadable by a host PC, device implementations will be required to switch to MTP or a similar system to provide host PCs with access to the current user's data. Accordingly, device implementations MAY but SHOULD NOT enable multi-user if they use removable media [ Resources, 72 ] for primary external storage. The upstream Android open-source project includes an implementation that uses internal device storage for application external storage APIs; device implementations SHOULD use this configuration and software implementation. Device implementations that include multiple external storage paths MUST NOT allow Android applications to write to the secondary external storage

9.6. Premium SMS Warning

Android 4.2 includes support for warning users for any outgoing premium SMS message. Premium SMS messages are text messages sent to a service registered with a carrier that may incur a charge to the user. Device implementations that declare support for android.hardware.telephony MUST warn users before sending a SMS message to numbers identified by regular expressions defined in /data/misc/sms/codes.xml file in the device. The upstream Android open-source project provides an implementation that satisfies this requirement.

10. सॉफ्टवेयर संगतता परीक्षण

Device implementations MUST pass all tests described in this section.

However, note that no software test package is fully comprehensive. For this reason, device implementers are very strongly encouraged to make the minimum number of changes as possible to the reference and preferred implementation of Android 4.2 available from the Android Open Source Project. This will minimize the risk of introducing bugs that create incompatibilities requiring rework and potential device updates.

10.1. संगतता परीक्षण सुइट

Device implementations MUST pass the Android Compatibility Test Suite (CTS) [ Resources, 2 ] available from the Android Open Source Project, using the final shipping software on the device. Additionally, device implementers SHOULD use the reference implementation in the Android Open Source tree as much as possible, and MUST ensure compatibility in cases of ambiguity in CTS and for any reimplementations of parts of the reference source code.

CTS को एक वास्तविक डिवाइस पर चलाने के लिए डिज़ाइन किया गया है। किसी भी सॉफ्टवेयर की तरह, CTS में ही बग हो सकते हैं। The CTS will be versioned independently of this Compatibility Definition, and multiple revisions of the CTS may be released for Android 4.2. Device implementations MUST pass the latest CTS version available at the time the device software is completed.

10.2. सीटीएस सत्यापनकर्ता

Device implementations MUST correctly execute all applicable cases in the CTS Verifier. The CTS Verifier is included with the Compatibility Test Suite, and is intended to be run by a human operator to test functionality that cannot be tested by an automated system, such as correct functioning of a camera and sensors.

The CTS Verifier has tests for many kinds of hardware, including some hardware that is optional. Device implementations MUST pass all tests for hardware which they possess; for instance, if a device possesses an accelerometer, it MUST correctly execute the Accelerometer test case in the CTS Verifier. Test cases for features noted as optional by this Compatibility Definition Document MAY be skipped or omitted.

Every device and every build MUST correctly run the CTS Verifier, as noted above. However, since many builds are very similar, device implementers are not expected to explicitly run the CTS Verifier on builds that differ only in trivial ways. Specifically, device implementations that differ from an implementation that has passed the CTS Verfier only by the set of included locales, branding, etc. MAY omit the CTS Verifier test.

10.3. संदर्भ अनुप्रयोग

Device implementers MUST test implementation compatibility using the following open source applications:

The "Apps for Android" applications [ Resources, 55 ]
Replica Island (available in Android Market)

Each app above MUST launch and behave correctly on the implementation, for the implementation to be considered compatible.

11. अद्यतन करने योग्य सॉफ्टवेयर

Device implementations MUST include a mechanism to replace the entirety of the system software. The mechanism need not perform "live" upgrades - that is, a device restart MAY be required.

Any method can be used, provided that it can replace the entirety of the software preinstalled on the device. For instance, any of the following approaches will satisfy this requirement:

Over-the-air (OTA) downloads with offline update via reboot
"Tethered" updates over USB from a host PC
"Offline" updates via a reboot and update from a file on removable storage

The update mechanism used MUST support updates without wiping user data. That is, the update mechanism MUST preserve application private data and application shared data. Note that the upstream Android software includes an update mechanism that satisfies this requirement.

If an error is found in a device implementation after it has been released but within its reasonable product lifetime that is determined in consultation with the Android Compatibility Team to affect the compatibility of third-party applications, the device implementer MUST correct the error via a software update available that can be applied per the mechanism just described.

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

You can contact the document authors at compatibility@android.com for clarifications and to bring up any issues that you think the document does not cover.

परिशिष्ट ए - ब्लूटूथ परीक्षण प्रक्रिया

The Compatibility Test Suite includes cases that cover basic operation of the Android RFCOMM Bluetooth API. However, since Bluetooth is a communications protocol between devices, it cannot be fully tested by unit tests running on a single device. Consequently, device implementations MUST also pass the human-operated Bluetooth test procedure described below.

The test procedure is based on the BluetoothChat sample app included in the Android open source project tree. The procedure requires two devices:

a candidate device implementation running the software build to be tested
a separate device implementation already known to be compatible, and of a model from the device implementation being tested - that is, a "known good" device implementation

The test procedure below refers to these devices as the "candidate" and "known good" devices, respectively.

सेटअप और इंस्टालेशन

Build BluetoothChat.apk via 'make samples' from an Android source code tree
Install BluetoothChat.apk on the known-good device
Install BluetoothChat.apk on the candidate device

Test Bluetooth Control by Apps

Launch BluetoothChat on the candidate device, while Bluetooth is disabled
Verify that the candidate device either turns on Bluetooth, or prompts the user with a dialog to turn on Bluetooth

Test Pairing and Communication

Launch the Bluetooth Chat app on both devices
Make the known-good device discoverable from within BluetoothChat (using the Menu)
On the candidate device, scan for Bluetooth devices from within BluetoothChat (using the Menu) and pair with the known-good device
Send 10 or more messages from each device, and verify that the other device receives them correctly
Close the BluetoothChat app on both devices by pressing Home
Unpair each device from the other, using the device Settings app

Test Pairing and Communication in the Reverse Direction

Launch the Bluetooth Chat app on both devices.
Make the candidate device discoverable from within BluetoothChat (using the Menu).
On the known-good device, scan for Bluetooth devices from within BluetoothChat (using the Menu) and pair with the candidate device.
Send 10 or messages from each device, and verify that the other device receives them correctly.
Close the Bluetooth Chat app on both devices by pressing Back repeatedly to get to the Launcher.

Test Re-Launches

Re-launch the Bluetooth Chat app on both devices.
Send 10 or messages from each device, and verify that the other device receives them correctly.

Note: the above tests have some cases which end a test section by using Home, and some using Back. These tests are not redundant and are not optional: the objective is to verify that the Bluetooth API and stack works correctly both when Activities are explicitly terminated (via the user pressing Back, which calls finish()), and implicitly sent to background (via the user pressing Home.) Each test sequence MUST be performed as described.