एंड्रॉइड 2.2 संगतता परिभाषा

कॉपीराइट © 2010, गूगल इंक. सर्वाधिकार सुरक्षित।
अनुकूलता@android.com

विषयसूची

1 परिचय

यह दस्तावेज़ उन आवश्यकताओं को सूचीबद्ध करता है जिन्हें मोबाइल फ़ोन को Android 2.2 के साथ संगत बनाने के लिए पूरा किया जाना चाहिए।

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

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

एंड्रॉइड 2.2 के साथ संगत माने जाने के लिए, डिवाइस कार्यान्वयन:

• संदर्भ के माध्यम से शामिल किसी भी दस्तावेज़ सहित, इस संगतता परिभाषा में प्रस्तुत आवश्यकताओं को पूरा करना होगा।
• डिवाइस के सॉफ़्टवेयर कार्यान्वयन के पूरा होने के समय उपलब्ध एंड्रॉइड संगतता परीक्षण सूट (सीटीएस) के नवीनतम संस्करण को पास करना होगा। (सीटीएस एंड्रॉइड ओपन सोर्स प्रोजेक्ट [ संसाधन, 2 ] के हिस्से के रूप में उपलब्ध है।) सीटीएस इस दस्तावेज़ में उल्लिखित सभी नहीं बल्कि कई घटकों का परीक्षण करता है।

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

2. संसाधन

1. IETF RFC2119 आवश्यकता स्तर: http://www.ietf.org/rfc/rfc2119.txt
2. एंड्रॉइड संगतता कार्यक्रम अवलोकन: http://source.android.com/docs/compatibility/index.html
3. एंड्रॉइड ओपन सोर्स प्रोजेक्ट: http://source.android.com/
4. एपीआई परिभाषाएँ और दस्तावेज़ीकरण: http://developer.android.com/reference/packages.html
5. Android अनुमतियाँ संदर्भ: http://developer.android.com/reference/android/Manifest.permission.html
6. android.os.Build संदर्भ: http://developer.android.com/reference/android/os/Build.html
7. Android 2.2 अनुमत संस्करण स्ट्रिंग: http://source.android.com/docs/compatibility/2.2/versions.html
8. android.webkit.WebView क्लास: http://developer.android.com/reference/android/webkit/WebView.html
9. HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/
10. डाल्विक वर्चुअल मशीन विशिष्टता: एंड्रॉइड स्रोत कोड में दल्विक/डॉक्स पर उपलब्ध है
11. ऐपविजेट्स: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
12. सूचनाएं: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
13. एप्लिकेशन संसाधन: http://code.google.com/android/reference/available-resources.html
14. स्टेटस बार आइकन स्टाइल गाइड: http://developer.android.com/guide/practices/ui_guideline /icon_design.html#statusbarstructure
15. खोज प्रबंधक: http://developer.android.com/reference/android/app/SearchManager.html
16. टोस्ट: http://developer.android.com/reference/android/widget/Toast.html
17. लाइव वॉलपेपर: https://android-developers.googleblog.com/2010/02/live-wallpapers.html
18. Android के लिए ऐप्स: http://code.google.com/p/apps-for-android
19. संदर्भ उपकरण दस्तावेज़ीकरण (एडीबी, एएपीटी, डीडीएमएस के लिए): http://developer.android.com/guide/developing/tools/index.html
20. एंड्रॉइड एपीके फ़ाइल विवरण: http://developer.android.com/guide/topics/fundamentals.html
21. मैनिफ़ेस्ट फ़ाइलें: http://developer.android.com/guide/topics/manifest/manifest-intro.html
22. बंदर परीक्षण उपकरण: https://developer.android.com/studio/test/other-testing-tools/monkey
23. एंड्रॉइड हार्डवेयर सुविधाओं की सूची: http://developer.android.com/reference/android/content/pm/PackageManager.html
24. एकाधिक स्क्रीन का समर्थन: http://developer.android.com/guide/practices/screens_support.html
25. android.content.res.कॉन्फ़िगरेशन: http://developer.android.com/reference/android/content/res/Configuration.html
26. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
27. android.hardware.Camera: http://developer.android.com/reference/android/hardware/Camera.html
28. सेंसर समन्वय स्थान: http://developer.android.com/reference/android/hardware/SensorEvent.html
29. Android सुरक्षा और अनुमतियाँ संदर्भ: http://developer.android.com/guide/topics/security/security.html
30. ब्लूटूथ एपीआई: http://developer.android.com/reference/android/bluetooth/package-summary.html

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

3. सॉफ्टवेयर

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

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

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

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

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

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

3.2.1. अनुमतियां

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

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

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

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

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

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

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

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

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

• मेज घड़ी
• ब्राउज़र
• पंचांग
• कैलकुलेटर
• कैमरा
• संपर्क
• ईमेल
• गैलरी
• वैश्विक खोज
• लांचर
• लाइवपिकर (अर्थात, लाइव वॉलपेपर पिकर एप्लिकेशन; यदि डिवाइस धारा 3.8.5 के अनुसार लाइव वॉलपेपर का समर्थन नहीं करता है, तो छोड़ा जा सकता है।)
• मैसेजिंग (उर्फ "एमएमएस")
• संगीत
• फ़ोन
• समायोजन
• ध्वनि रिकार्डर

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

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

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

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

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

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

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

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

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

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

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

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

• libc (सी लाइब्रेरी)
• libm (गणित पुस्तकालय)
• जेएनआई इंटरफ़ेस
• libz (ज़्लिब संपीड़न)
• लिबलॉग (एंड्रॉइड लॉगिंग)
• C++ के लिए न्यूनतम समर्थन
• ओपनजीएल के लिए समर्थन, जैसा कि नीचे बताया गया है

डिवाइस कार्यान्वयन को OpenGL ES 1.0 का समर्थन करना चाहिए। जिन उपकरणों में हार्डवेयर त्वरण की कमी है, उन्हें सॉफ़्टवेयर रेंडरर का उपयोग करके OpenGL ES 1.0 लागू करना होगा। डिवाइस कार्यान्वयन को उतना ही OpenGL ES 1.1 लागू करना चाहिए जितना डिवाइस हार्डवेयर समर्थन करता है। यदि हार्डवेयर उन एपीआई पर उचित प्रदर्शन करने में सक्षम है, तो डिवाइस कार्यान्वयन को ओपनजीएल ईएस 2.0 के लिए कार्यान्वयन प्रदान करना चाहिए।

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

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

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

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

कई डेवलपर्स और एप्लिकेशन अपने यूजर इंटरफेस के लिए android.webkit.WebView क्लास [ संसाधन, 8 ] के व्यवहार पर भरोसा करते हैं, इसलिए WebView कार्यान्वयन सभी एंड्रॉइड कार्यान्वयनों के अनुकूल होना चाहिए। इसी तरह, एक पूर्ण वेब अनुभव एंड्रॉइड उपयोगकर्ता अनुभव के लिए केंद्रीय है। डिवाइस कार्यान्वयन में अपस्ट्रीम एंड्रॉइड सॉफ़्टवेयर के अनुरूप android.webkit.WebView का एक संस्करण शामिल होना चाहिए, और एक आधुनिक HTML5-सक्षम ब्राउज़र शामिल होना चाहिए, जैसा कि नीचे बताया गया है।

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

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

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

वेबव्यू कॉन्फ़िगरेशन में HTML5 डेटाबेस, एप्लिकेशन कैश और जियोलोकेशन एपीआई [ संसाधन, 9 ] के लिए समर्थन शामिल होना चाहिए। वेबव्यू में HTML5 <video> टैग के लिए समर्थन शामिल होना चाहिए। HTML5 एपीआई, सभी जावास्क्रिप्ट एपीआई की तरह, वेबव्यू में डिफ़ॉल्ट रूप से अक्षम होना चाहिए, जब तक कि डेवलपर उन्हें सामान्य एंड्रॉइड एपीआई के माध्यम से स्पष्ट रूप से सक्षम न कर दे।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

डिवाइस कार्यान्वयनकर्ता कस्टम एपीआई जोड़ सकते हैं, लेकिन ऐसे किसी भी एपीआई को किसी अन्य संगठन के स्वामित्व वाले या संदर्भित नामस्थान में नहीं होना चाहिए। उदाहरण के लिए, डिवाइस कार्यान्वयनकर्ताओं को com.google.* या समान नेमस्पेस में API नहीं जोड़ना चाहिए; केवल Google ही ऐसा कर सकता है. इसी प्रकार, Google को अन्य कंपनियों के नामस्थानों में API नहीं जोड़ना चाहिए।

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

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

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

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

मध्यम या निम्न-घनत्व के रूप में वर्गीकृत स्क्रीन वाले डिवाइस कार्यान्वयन को प्रत्येक एप्लिकेशन के लिए कम से कम 16 एमबी मेमोरी आवंटित करने के लिए डेल्विक को कॉन्फ़िगर करना होगा। उच्च-घनत्व के रूप में वर्गीकृत स्क्रीन वाले डिवाइस कार्यान्वयन को प्रत्येक एप्लिकेशन के लिए कम से कम 24 एमबी मेमोरी आवंटित करने के लिए डेल्विक को कॉन्फ़िगर करना होगा। ध्यान दें कि डिवाइस कार्यान्वयन इन आंकड़ों से अधिक मेमोरी आवंटित कर सकता है।

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

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

3.8.1. विजेट

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

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

3.8.2. सूचनाएं

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

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

3.8.3. खोज

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

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

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

3.8.4. टोस्ट

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

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

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

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

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

4. संदर्भ सॉफ्टवेयर संगतता

डिवाइस कार्यान्वयनकर्ताओं को निम्नलिखित ओपन-सोर्स अनुप्रयोगों का उपयोग करके कार्यान्वयन अनुकूलता का परीक्षण करना चाहिए:

• कैलकुलेटर (एसडीके में शामिल)
• चंद्र लैंडर (एसडीके में शामिल)
• "एंड्रॉइड के लिए ऐप्स" एप्लिकेशन [ संसाधन, 18 ]।
• रेप्लिका आइलैंड (एंड्रॉइड मार्केट में उपलब्ध; केवल ओपनजीएल ईएस 2.0 का समर्थन करने वाले डिवाइस कार्यान्वयन के लिए आवश्यक)

कार्यान्वयन को संगत माना जाने के लिए उपरोक्त प्रत्येक ऐप को कार्यान्वयन पर सही ढंग से लॉन्च और व्यवहार करना होगा।

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

• एपीडेमोस (एसडीके में शामिल)
• मैनुअलस्मोकटेस्ट (सीटीएस में शामिल)

उपरोक्त अनुप्रयोगों में प्रत्येक परीक्षण केस को डिवाइस कार्यान्वयन पर सही ढंग से चलना चाहिए।

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

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

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

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

डिवाइस कार्यान्वयन को सभी मल्टीमीडिया एपीआई को पूरी तरह से लागू करना होगा। डिवाइस कार्यान्वयन में नीचे वर्णित सभी मल्टीमीडिया कोडेक्स के लिए समर्थन शामिल होना चाहिए, और नीचे वर्णित ध्वनि प्रसंस्करण दिशानिर्देशों को पूरा करना चाहिए।

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

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

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

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

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

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

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

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

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

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

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

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

उपरोक्त परिभाषाओं का उपयोग करते हुए, डिवाइस कार्यान्वयन को इनमें से प्रत्येक गुण को प्रदर्शित करना चाहिए:

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

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

7. डेवलपर उपकरण संगतता

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

• एंड्रॉइड डिबग ब्रिज (एडीबी के रूप में जाना जाता है) [ संसाधन, 19 ]
  डिवाइस कार्यान्वयन को Android SDK में प्रलेखित सभी adb कार्यों का समर्थन करना चाहिए। डिवाइस-साइड adb डेमॉन डिफ़ॉल्ट रूप से निष्क्रिय होना चाहिए, लेकिन एंड्रॉइड डिबग ब्रिज को चालू करने के लिए एक उपयोगकर्ता-सुलभ तंत्र होना चाहिए।
• Dalvik Debug मॉनिटर सेवा (DDMS के रूप में जाना जाता है) [ संसाधन, 19 ]
  डिवाइस कार्यान्वयन को Android SDK में प्रलेखित के रूप में सभी ddms सुविधाओं का समर्थन करना चाहिए। जैसा कि ddms adb का उपयोग करता है, ddms के लिए समर्थन डिफ़ॉल्ट रूप से निष्क्रिय होना चाहिए, लेकिन जब भी उपयोगकर्ता ने Android Debug Bridge को सक्रिय किया है, तो समर्थन किया जाना चाहिए।
• बंदर [ संसाधन, 22 ]
  डिवाइस कार्यान्वयन में बंदर ढांचा शामिल होना चाहिए, और इसे उपयोग करने के लिए अनुप्रयोगों के लिए उपलब्ध कराना चाहिए।

8. हार्डवेयर संगतता

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

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

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

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

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

8.1. प्रदर्शन

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

Android 2.2 के लिए, ये सबसे आम डिस्प्ले कॉन्फ़िगरेशन हैं:

ऊपर दिए गए मानक कॉन्फ़िगरेशन में से एक के अनुरूप डिवाइस कार्यान्वयन को android.content.res.Configuration [ संसाधन, 24 ] वर्ग के माध्यम से अनुप्रयोगों के लिए संकेतित स्क्रीन आकार की रिपोर्ट करने के लिए कॉन्फ़िगर किया जाना चाहिए।

कुछ .APK पैकेज में प्रकट होते हैं जो उन्हें एक विशिष्ट घनत्व सीमा का समर्थन करने के रूप में पहचान नहीं करते हैं। ऐसे एप्लिकेशन चलाते समय, निम्नलिखित बाधाएं लागू होती हैं:

• डिवाइस कार्यान्वयन को एक .APK में संसाधनों की व्याख्या करनी चाहिए, जिसमें "मध्यम" (SDK प्रलेखन में "MDPI" के रूप में जाना जाता है।)
• "कम" घनत्व स्क्रीन पर काम करते समय, डिवाइस कार्यान्वयन को 0.75 के कारक द्वारा मध्यम/एमडीपीआई परिसंपत्तियों को कम करना चाहिए।
• "उच्च" घनत्व स्क्रीन पर काम करते समय, डिवाइस कार्यान्वयन को मध्यम/एमडीपीआई परिसंपत्तियों को 1.5 के कारक द्वारा स्केल करना होगा।
• डिवाइस कार्यान्वयन को घनत्व सीमा के भीतर परिसंपत्तियों को स्केल नहीं करना चाहिए, और घनत्व सीमाओं के बीच इन कारकों द्वारा परिसंपत्तियों को स्केल करना चाहिए।

8.1.2. गैर-मानक प्रदर्शन विन्यास

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

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

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

डिवाइस कार्यान्वयन को सही मानों android.util.DisplayMetrics लिए रिपोर्ट करना चाहिए।

8.1.4. घोषित स्क्रीन समर्थन

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

8.2. कीबोर्ड

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

• इनपुट प्रबंधन ढांचे के लिए समर्थन शामिल होना चाहिए (जो तीसरे पक्ष के डेवलपर्स को इनपुट प्रबंधन इंजन बनाने की अनुमति देता है - यानी सॉफ्ट कीबोर्ड) डेवलपर पर विस्तृत है।
• कम से कम एक नरम कीबोर्ड कार्यान्वयन प्रदान करना चाहिए (चाहे एक हार्ड कीबोर्ड मौजूद हो)
• अतिरिक्त सॉफ्ट कीबोर्ड कार्यान्वयन शामिल हो सकते हैं
• एक हार्डवेयर कीबोर्ड शामिल हो सकता है
• एक हार्डवेयर कीबोर्ड को शामिल नहीं करना चाहिए जो android.content.res.Configuration.keyboard में निर्दिष्ट प्रारूपों में से एक से मेल नहीं खाता है [ संसाधन, 25 ] (अर्थात, qwerty, या 12-कुंजी)

8.3. गैर-स्पर्श नेविगेशन

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

• एक गैर-स्पर्श नेविगेशन विकल्पों को छोड़ सकते हैं (यानी, एक ट्रैकबॉल, डी-पैड, या पहिया को छोड़ सकते हैं)
• android.content.res.Configuration.navigation [ संसाधन, 25 ] के लिए सही मूल्य की रिपोर्ट करनी चाहिए

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

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

डिवाइस को डिवाइस के वर्तमान अभिविन्यास के लिए सही मूल्य की रिपोर्ट करनी चाहिए, जब भी Android.content.res.configuration.orientation, android.view.display.getOrientation (), या अन्य API के माध्यम से Queried।

8.5। टचस्क्रीन इनपुट

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

• एक टचस्क्रीन होना चाहिए
• या तो capacative या प्रतिरोधक टचस्क्रीन हो सकता है
• android.content.res.Configuration [ संसाधन, 25 ] के मूल्य की रिपोर्ट करना चाहिए
• यदि टचस्क्रीन कई पॉइंटर्स का समर्थन करता है, तो पूरी तरह से स्वतंत्र रूप से ट्रैक किए गए पॉइंटर्स का समर्थन करना चाहिए

8.6. USB

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

• एक USB क्लाइंट को लागू करना चाहिए, एक मानक USB-A पोर्ट के साथ USB होस्ट से कनेक्ट करने योग्य
• यूएसबी पर एंड्रॉइड डीबग ब्रिज को लागू करना चाहिए (जैसा कि धारा 7 में वर्णित है)
• USB मास स्टोरेज स्पेसिफिकेशन को लागू करना चाहिए, ताकि डिवाइस से जुड़े होस्ट को /sdcard वॉल्यूम की सामग्री तक पहुंचने की अनुमति मिल सके
• डिवाइस साइड पर माइक्रो यूएसबी फॉर्म फैक्टर का उपयोग करना चाहिए
• डिवाइस साइड पर एक गैर-मानक पोर्ट शामिल हो सकता है, लेकिन यदि ऐसा है तो कस्टम पिनआउट को मानक USB-A पोर्ट से जोड़ने में सक्षम केबल के साथ जहाज करना चाहिए
• यूएसबी मास स्टोरेज स्पेसिफिकेशन के लिए समर्थन लागू करना चाहिए (ताकि डिवाइस पर या तो हटाने योग्य या फिक्स्ड स्टोरेज को होस्ट पीसी से एक्सेस किया जा सके)

8.7. नेविगेशन कुंजियाँ

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

डिवाइस कार्यान्वयनकर्ताओं को एक समर्पित खोज कुंजी भी प्रदान करनी चाहिए। डिवाइस कार्यान्वयनकर्ता फोन कॉल के लिए भेजने और समाप्ति की भी प्रदान कर सकते हैं।

8.8. वायरलेस डेटा नेटवर्किंग

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

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

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

8.9. कैमरा

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

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

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

1. यदि किसी एप्लिकेशन ने कभी भी Android.hardware.camera.parameters.setpreviewformat (int) नहीं कहा है, तो डिवाइस को Android.hardware.pixelformat.ycbcr_420_sp का उपयोग करना चाहिए, जो एप्लिकेशन कॉलबैक को प्रदान किए गए पूर्वावलोकन डेटा के लिए है।
2. यदि कोई एप्लिकेशन Android.hardware.camera.previewcallback इंस्टेंस को पंजीकृत करता है और सिस्टम onPreviewFrame () विधि को कॉल करता है जब पूर्वावलोकन प्रारूप YCBCR_420_SP होता है, तो बाइट में डेटा [] onPreviewFrame () में पारित किया जाता है () NV21 एन्कोडिंग प्रारूप में आगे होना चाहिए। (यह 7K हार्डवेयर परिवार द्वारा मूल रूप से उपयोग किया जाने वाला प्रारूप है।) यानी, NV21 डिफ़ॉल्ट होना चाहिए।

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

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

डिवाइस कार्यान्वयन में फ्रंट-फेसिंग कैमरा शामिल हो सकता है। हालांकि, यदि डिवाइस कार्यान्वयन में फ्रंट-फेसिंग कैमरा शामिल है, तो डिवाइस पर लागू कैमरा एपीआई को डिफ़ॉल्ट रूप से फ्रंट-फेसिंग कैमरे का उपयोग नहीं करना चाहिए। अर्थात्, एंड्रॉइड 2.2 में कैमरा एपीआई केवल रियर-फेसिंग कैमरों के लिए है, और डिवाइस कार्यान्वयन को एपीआई को फ्रंट-फेसिंग कैमरे पर कार्य करने के लिए पुन: उपयोग या अधिभार नहीं करना चाहिए, यदि कोई मौजूद है। ध्यान दें कि फ्रंट-फेसिंग कैमरों का समर्थन करने के लिए डिवाइस कार्यान्वयनकर्ताओं द्वारा जोड़े गए किसी भी कस्टम एपीआई को धारा 3.5 और 3.6 का पालन करना चाहिए; उदाहरण के लिए, यदि एक कस्टम android.hardware.Camera या Camera.Parameters उपवर्ग को फ्रंट-फेसिंग कैमरों का समर्थन करने के लिए प्रदान किया जाता है, तो यह एक मौजूदा नामस्थान में स्थित नहीं होना चाहिए, जैसा कि धारा 3.5 और 3.6 द्वारा वर्णित है। ध्यान दें कि फ्रंट-फेसिंग कैमरे को शामिल करने से उस आवश्यकता को पूरा नहीं किया जाता है जिसमें डिवाइस में रियर-फेसिंग कैमरा शामिल होता है।

8.10. accelerometer

डिवाइस कार्यान्वयन में 3-अक्ष एक्सेलेरोमीटर शामिल होना चाहिए और 50 हर्ट्ज या उससे अधिक पर घटनाओं को वितरित करने में सक्षम होना चाहिए। एक्सेलेरोमीटर द्वारा उपयोग की जाने वाली समन्वय प्रणाली को एंड्रॉइड एपीआई में विस्तृत के रूप में एंड्रॉइड सेंसर समन्वय प्रणाली का पालन करना चाहिए (देखें [ संसाधन, 28 ])।

8.11. दिशा सूचक यंत्र

डिवाइस कार्यान्वयन में 3-अक्ष कम्पास शामिल होना चाहिए और 10 हर्ट्ज या उससे अधिक घटनाओं को वितरित करने में सक्षम होना चाहिए। कम्पास द्वारा उपयोग की जाने वाली समन्वय प्रणाली को एंड्रॉइड एपीआई में परिभाषित एंड्रॉइड सेंसर समन्वय प्रणाली का पालन करना चाहिए (देखें [ संसाधन, 28 ])।

8.12. GPS

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

8.13. टेलीफ़ोनी

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

धारा 8.8, वायरलेस डेटा नेटवर्किंग भी देखें।

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

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

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

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

8.15. अनुप्रयोग साझा भंडारण

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

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

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

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

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

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

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

8.16. ब्लूटूथ

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

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

9. प्रदर्शन संगतता

Android संगतता कार्यक्रम के लक्ष्यों में से एक उपभोक्ताओं के लिए लगातार अनुप्रयोग अनुभव को सक्षम करना है। संगत कार्यान्वयन को न केवल यह सुनिश्चित करना चाहिए कि एप्लिकेशन केवल डिवाइस पर सही तरीके से चलते हैं, बल्कि यह कि वे उचित प्रदर्शन और समग्र अच्छे उपयोगकर्ता अनुभव के साथ ऐसा करते हैं। डिवाइस कार्यान्वयन को नीचे दी गई तालिका में परिभाषित Android 2.2 संगत डिवाइस के प्रमुख प्रदर्शन मेट्रिक्स को पूरा करना होगा:

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

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

10.1. अनुमतियां

डिवाइस कार्यान्वयन को एंड्रॉइड डेवलपर प्रलेखन [ संसाधन, 29 ] में परिभाषित एंड्रॉइड अनुमतियों मॉडल का समर्थन करना चाहिए। विशेष रूप से, कार्यान्वयन को एसडीके प्रलेखन में वर्णित प्रत्येक अनुमति को लागू करना होगा; किसी भी अनुमति को छोड़ा, बदल दिया जा सकता है या अनदेखा नहीं किया जा सकता है। कार्यान्वयन अतिरिक्त अनुमतियाँ जोड़ सकते हैं, बशर्ते कि नई अनुमति आईडी तार Android में न हों।* Namespace।

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

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

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

डिवाइस कार्यान्वयन को Android फ़ाइल एक्सेस अनुमतियाँ मॉडल का समर्थन करना चाहिए जैसा कि सुरक्षा और अनुमतियों के संदर्भ में परिभाषित किया गया है [ संसाधन, 29 ]।

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

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

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

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

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

वैकल्पिक रनटाइम्स को एंड्रॉइड सैंडबॉक्स मॉडल का पालन करना चाहिए। विशेष रूप से:

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

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

वैकल्पिक रनटाइम्स की .APK फ़ाइलों को डिवाइस कार्यान्वयन की सिस्टम छवि में शामिल किया जा सकता है, लेकिन डिवाइस कार्यान्वयन के साथ शामिल अन्य अनुप्रयोगों पर हस्ताक्षर करने के लिए उपयोग की जाने वाली कुंजी से एक महत्वपूर्ण के साथ हस्ताक्षरित किया जाना चाहिए।

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

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

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

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

12. updatable सॉफ्टवेयर

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

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

• रिबूट के माध्यम से ऑफ़लाइन अपडेट के साथ ओवर-द-एयर (ओटीए) डाउनलोड
• एक होस्ट पीसी से USB पर "tethered" अपडेट
• "ऑफ़लाइन" एक रिबूट के माध्यम से अपडेट करता है और हटाने योग्य संग्रहण पर एक फ़ाइल से अपडेट करता है

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

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

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

आप स्पष्टीकरण के लिए संगतता@android.com पर दस्तावेज़ लेखकों से संपर्क कर सकते हैं और किसी भी मुद्दे को लाने के लिए जो आपको लगता है कि दस्तावेज़ कवर नहीं करता है।

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

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

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

• सॉफ्टवेयर बिल्ड को चलाने वाले एक उम्मीदवार डिवाइस कार्यान्वयन का परीक्षण किया जाना
• एक अलग डिवाइस कार्यान्वयन पहले से ही संगत होने के लिए जाना जाता है, और डिवाइस कार्यान्वयन से एक मॉडल का परीक्षण किया जा रहा है - अर्थात, एक "ज्ञात अच्छा" डिवाइस कार्यान्वयन

नीचे दी गई परीक्षण प्रक्रिया इन उपकरणों को क्रमशः "उम्मीदवार" और "ज्ञात अच्छे" उपकरणों के रूप में संदर्भित करती है।

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

1. Android स्रोत कोड ट्री से 'नमूने बनाएं' के माध्यम से BlueToothChat.apk का निर्माण करें।
2. ज्ञात-अच्छे डिवाइस पर BluetoothChat.apk स्थापित करें।
3. उम्मीदवार डिवाइस पर BluetoothChat.apk स्थापित करें।

ऐप्स द्वारा ब्लूटूथ नियंत्रण का परीक्षण करें

1. उम्मीदवार डिवाइस पर ब्लूटूथचैट लॉन्च करें, जबकि ब्लूटूथ अक्षम है।
2. सत्यापित करें कि उम्मीदवार डिवाइस या तो ब्लूटूथ को चालू करता है, या ब्लूटूथ को चालू करने के लिए एक संवाद के साथ उपयोगकर्ता को संकेत देता है।

परीक्षण युग्मन और संचार

1. दोनों उपकरणों पर ब्लूटूथ चैट ऐप लॉन्च करें।
2. ब्लूटूथचैट (मेनू का उपयोग करके) के भीतर से ज्ञात-अच्छे डिवाइस को खोजने योग्य बनाएं।
3. On the candidate device, scan for Bluetooth devices from within BluetoothChat (using the Menu) and pair with the known-good device.
4. Send 10 or more messages from each device, and verify that the other device receives them correctly.
5. Close the BluetoothChat app on both devices by pressing Home .
6. Unpair each device from the other, using the device Settings app.

Test Pairing and Communication in the Reverse Direction

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

Test Re-Launches

1. Re-launch the Bluetooth Chat app on both devices.
2. 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.