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

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

1 परिचय

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

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

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

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

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

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

2. संसाधन
  • IETF RFC2119 आवश्यकता स्तर: http://www.ietf.org/rfc/rfc2119.txt
  • एंड्रॉइड संगतता कार्यक्रम अवलोकन: http://source.android.com/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 2.1 अनुमत संस्करण स्ट्रिंग्स: http://source.android.com/docs/compatibility/2.1/versions .html
  • android.webkit.WebView क्लास: http://developer.android.com/reference/android/webkit/WebView.html
  • HTML5: http://www.whatwg.org/specs/web-apps/current-work/ मल्टीपेज/
  • डालविक वर्चुअल मशीन विशिष्टता: एंड्रॉइड स्रोत कोड में, dalvik/docs
    •
  • AppWidgets पर उपलब्ध: 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/ गाइड/प्रैक्टिस/यूआई_गाइडलाइन /आइकन_डिज़ाइन.html#statusbarstructure
  • सर्च मैनेजर: http://developer.android.com/reference/android/app/SearchManager.html
  • टोस्ट्स: http://developer.android.com/reference/android/widget /Toast.html
  • लाइव वॉलपेपर: https://android-developers.googleblog.com/2010/02/live-wallpapers.html
  • Android के लिए ऐप्स: http://code.google.com/p/apps-for-android
  • संदर्भ टूल दस्तावेज़ीकरण (एडीबी, एएपीटी, डीडीएमएस के लिए): 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/
    • एकाधिक स्क्रीन का समर्थन करने वाला
  • बंदर
  • : http://developer.android.com/guide/practices/screens_support.html
  • android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration। html
  • android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
  • android.hardware.Camera: http://developer.android.com/reference/android/hardware/Camera। html
  • सेंसर समन्वय स्थान: http://developer.android.com/reference/android/hardware/SensorEvent.html
  • Android सुरक्षा और अनुमतियाँ संदर्भ: http://developer.android.com/guide/topics/security/security.html
  • ब्लूटूथ एपीआई: http://developer.android.com/reference/android/bluetooth/package-summary.html

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

    3. सॉफ्टवेयर

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

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

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

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

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

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

    3.2.1. अनुमति

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

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

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

    पैरामीटर टिप्पणियाँ
    android.os.Build.VERSION.RELEASE मानव-पठनीय प्रारूप में वर्तमान में निष्पादित एंड्रॉइड सिस्टम का संस्करण। इस फ़ील्ड में [ संसाधन, 7 ] में परिभाषित स्ट्रिंग मानों में से एक होना चाहिए।
    android.os.Build.VERSION.SDK वर्तमान में निष्पादित एंड्रॉइड सिस्टम का संस्करण, तीसरे पक्ष के एप्लिकेशन कोड के लिए सुलभ प्रारूप में। एंड्रॉइड 2.1 के लिए, इस फ़ील्ड में पूर्णांक मान 7 होना चाहिए।
    android.os.Build.VERSION.INCREMENTAL मानव-पठनीय प्रारूप में वर्तमान में निष्पादित एंड्रॉइड सिस्टम के विशिष्ट निर्माण को निर्दिष्ट करने वाले डिवाइस कार्यान्वयनकर्ता द्वारा चुना गया एक मान। अंतिम उपयोगकर्ताओं को भेजे गए विभिन्न बिल्डों के लिए इस मान का पुन: उपयोग नहीं किया जाना चाहिए। इस फ़ील्ड का एक विशिष्ट उपयोग यह इंगित करना है कि बिल्ड उत्पन्न करने के लिए किस बिल्ड नंबर या स्रोत-नियंत्रण परिवर्तन पहचानकर्ता का उपयोग किया गया था। इस फ़ील्ड के विशिष्ट प्रारूप पर कोई आवश्यकता नहीं है, सिवाय इसके कि यह शून्य या खाली स्ट्रिंग ("") नहीं होना चाहिए।
    android.os.Build.BOARD मानव-पठनीय प्रारूप में डिवाइस द्वारा उपयोग किए जाने वाले विशिष्ट आंतरिक हार्डवेयर की पहचान करने वाले डिवाइस कार्यान्वयनकर्ता द्वारा चुना गया एक मान। इस फ़ील्ड का संभावित उपयोग डिवाइस को पावर देने वाले बोर्ड के विशिष्ट संशोधन को इंगित करना है। इस फ़ील्ड के विशिष्ट प्रारूप पर कोई आवश्यकता नहीं है, सिवाय इसके कि यह शून्य या खाली स्ट्रिंग ("") नहीं होना चाहिए।
    android.os.Build.BRAND डिवाइस कार्यान्वयनकर्ता द्वारा चुना गया एक मान, जो मानव-पठनीय प्रारूप में डिवाइस का उत्पादन करने वाली कंपनी, संगठन, व्यक्ति आदि के नाम की पहचान करता है। इस फ़ील्ड का संभावित उपयोग डिवाइस बेचने वाले OEM और/या वाहक को इंगित करना है। इस फ़ील्ड के विशिष्ट प्रारूप पर कोई आवश्यकता नहीं है, सिवाय इसके कि यह शून्य या खाली स्ट्रिंग ("") नहीं होना चाहिए।
    android.os.Build.DEVICE डिवाइस कार्यान्वयनकर्ता द्वारा चुना गया एक मान जो डिवाइस के विशिष्ट कॉन्फ़िगरेशन या बॉडी के संशोधन (कभी-कभी "औद्योगिक डिज़ाइन" कहा जाता है) की पहचान करता है। इस फ़ील्ड के विशिष्ट प्रारूप पर कोई आवश्यकता नहीं है, सिवाय इसके कि यह शून्य या खाली स्ट्रिंग ("") नहीं होना चाहिए।
    android.os.Build.FINGERPRINT एक स्ट्रिंग जो विशिष्ट रूप से इस बिल्ड की पहचान करती है। यह यथोचित रूप से मानव-पठनीय होना चाहिए। इसे इस टेम्पलेट का पालन करना होगा:
    $(BRAND)/$(PRODUCT)/$(DEVICE)/$(BOARD):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)
    उदाहरण के लिए:
    acme/mydevice/generic/generic:2.1-update1/ERC77/3359:userdebug/test-keys
    फिंगरप्रिंट में रिक्त स्थान शामिल नहीं होना चाहिए। यदि उपरोक्त टेम्पलेट में शामिल अन्य फ़ील्ड में रिक्त स्थान हैं, तो उन्हें फ़िंगरप्रिंट में ASCII अंडरस्कोर ("_") वर्ण से प्रतिस्थापित किया जाना चाहिए।
    android.os.Build.HOST एक स्ट्रिंग जो विशिष्ट रूप से मानव पठनीय प्रारूप में उस होस्ट की पहचान करती है जिस पर निर्माण किया गया था। इस फ़ील्ड के विशिष्ट प्रारूप पर कोई आवश्यकता नहीं है, सिवाय इसके कि यह शून्य या खाली स्ट्रिंग ("") नहीं होना चाहिए।
    android.os.Build.ID मानव पठनीय प्रारूप में एक विशिष्ट रिलीज़ को संदर्भित करने के लिए डिवाइस कार्यान्वयनकर्ता द्वारा चुना गया एक पहचानकर्ता। यह फ़ील्ड android.os.Build.VERSION.INCREMENTAL के समान हो सकती है, लेकिन अंतिम उपयोगकर्ताओं के लिए सॉफ़्टवेयर बिल्ड के बीच अंतर करने के लिए पर्याप्त रूप से सार्थक मूल्य होना चाहिए। इस फ़ील्ड के विशिष्ट प्रारूप पर कोई आवश्यकता नहीं है, सिवाय इसके कि यह शून्य या खाली स्ट्रिंग ("") नहीं होना चाहिए।
    android.os.Build.MODEL डिवाइस कार्यान्वयनकर्ता द्वारा चुना गया एक मान जिसमें अंतिम उपयोगकर्ता को ज्ञात डिवाइस का नाम शामिल होता है। यह वही नाम होना चाहिए जिसके तहत डिवाइस का विपणन किया जाता है और अंतिम उपयोगकर्ताओं को बेचा जाता है। इस फ़ील्ड के विशिष्ट प्रारूप पर कोई आवश्यकता नहीं है, सिवाय इसके कि यह शून्य या खाली स्ट्रिंग ("") नहीं होना चाहिए।
    android.os.Build.PRODUCT डिवाइस कार्यान्वयनकर्ता द्वारा चुना गया एक मान जिसमें डिवाइस का विकास नाम या कोड नाम होता है। मानव-पठनीय होना चाहिए, लेकिन अंतिम उपयोगकर्ताओं द्वारा देखने के लिए आवश्यक नहीं है। इस फ़ील्ड के विशिष्ट प्रारूप पर कोई आवश्यकता नहीं है, सिवाय इसके कि यह शून्य या खाली स्ट्रिंग ("") नहीं होना चाहिए।
    android.os.Build.TAGS डिवाइस कार्यान्वयनकर्ता द्वारा चुने गए टैग की अल्पविराम से अलग की गई सूची जो बिल्ड को और अलग करती है। उदाहरण के लिए, "अहस्ताक्षरित, डीबग"। यह फ़ील्ड शून्य या खाली स्ट्रिंग ("") नहीं होनी चाहिए, लेकिन एक टैग (जैसे "रिलीज़") ठीक है।
    android.os.Build.TIME एक मान जो निर्माण के समय के टाइमस्टैम्प को दर्शाता है।
    android.os.Build.TYPE बिल्ड के रनटाइम कॉन्फ़िगरेशन को निर्दिष्ट करने वाले डिवाइस कार्यान्वयनकर्ता द्वारा चुना गया एक मान। इस फ़ील्ड में तीन विशिष्ट एंड्रॉइड रनटाइम कॉन्फ़िगरेशन के अनुरूप मानों में से एक होना चाहिए: "उपयोगकर्ता", "उपयोगकर्ताडेबग", या "इंग्लैंड"।
    android.os.Build.USER उस उपयोगकर्ता (या स्वचालित उपयोगकर्ता) का नाम या उपयोगकर्ता आईडी जिसने बिल्ड तैयार किया। इस फ़ील्ड के विशिष्ट प्रारूप पर कोई आवश्यकता नहीं है, सिवाय इसके कि यह शून्य या खाली स्ट्रिंग ("") नहीं होना चाहिए।

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

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

    3.2.3.1. कोर एप्लिकेशन इरादे

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

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

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

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

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

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

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

    3.2.3.2. इंटेंट ओवरराइड्स

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

    नोट: इस अनुभाग को इरेटम EX6580 द्वारा संशोधित किया गया था।

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

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

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

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

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

    3.3.

    डाल्विक में चल रहे

    नेटिव एपीआई अनुकूलता

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

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

    डिवाइस कार्यान्वयन को 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 कार्यान्वयन सभी एंड्रॉइड कार्यान्वयनों के साथ संगत होना चाहिए। एंड्रॉइड ओपन सोर्स कार्यान्वयन वेबव्यू को लागू करने के लिए वेबकिट रेंडरिंग इंजन का उपयोग करता है।

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

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

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

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

    3.5. एपीआई व्यवहार अनुकूलता

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    3.8.1. विजेट्स

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

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

    3.8.2. नोटिफिकेशन

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

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

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

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

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

    3.8.4. टोस्ट

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

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

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

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

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

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

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

    • कैलकुलेटर (एसडीके में शामिल)
    • लूनर लैंडर (एसडीके में शामिल)
    • "एंड्रॉइड के लिए ऐप्स" एप्लिकेशन [ संसाधन, 18 ]।

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

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

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

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

    5. एप्लिकेशन पैकेजिंग संगतता

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

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

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

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

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

    बीच नमूना दर के किसी भी संयोजन में मोनो/स्टीरियो सामग्री। के लिए कोई समर्थन नहीं
    ऑडियो
    नाम एनकोडर डिकोडर विवरण फ़ाइल/कंटेनर प्रारूप
    एएसी एलसी/एलटीपी   160 केबीपीएस तक मानक बिट दर और 8 से 48kHz 3GPP (.3gp) और MPEG-4 (.mp4, .m4a) केXकच्चे AAC (.aac)
    HE-AACv1 (AAC+)
      X
    HE-AACv2 (उन्नत AAC+)   X
    AMR
    - NB X _ _
      X 9 दरें 6.60 kbit/s से 23.85 kbit/s तक नमूना @ 16kHz 3GPP (.3gp)
    MP3   एक्स मोनो/स्टीरियो 8-320 केबीपीएस स्थिरांक (सीबीआर) या परिवर्तनीय बिट-रेट (वीबीआर) एमपी3 (.mp3)
    मिडी   एक्स मिडी टाइप 0 और 1. डीएलएस संस्करण 1 और 2. एक्सएमएफ और मोबाइल एक्सएमएफ। रिंगटोन प्रारूप RTTTL/RTX, OTA और iMelody प्रकार 0 और 1 (.mid, .xmf, .mxmf) के लिए समर्थन। इसके अलावा RTTTL/RTX (.rtttl, .rtx), OTA (.ota), और iMelody (.imy)
    ऑग वॉर्बिस   एक्स   ओग (.ogg)
    पीसीएम   X 8- और 16-बिट रैखिक पीसीएम (हार्डवेयर की सीमा तक दरें) वेव (.wav)
    छवि
    जेपीईजी एक्स एक्स बेस + प्रगतिशील  
    GIF   एक्स   
    पीएनजी एक्स एक्स   
    बीएमपी   एक्स   
    वीडियो
    एच.263 एक्स एक्स   3जीपीपी (.3जीपी) फ़ाइलें
    एच.264   एक्स   3GPP (.3gp) और MPEG-4 (.mp4) फ़ाइलें
    MPEG4 सरल प्रोफ़ाइल   एक्स   3GPP (.3gp) फ़ाइल

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

    7. डेवलपर टूल संगतता

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

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

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

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

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

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

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

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

    8.1. डिस्प्ले

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

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

    एफडब्ल्यूवीजीए 480 854 3.5 डिवाइस
    स्क्रीन प्रकार चौड़ाई (पिक्सेल) ऊंचाई (पिक्सेल) विकर्ण लंबाई रेंज (इंच) स्क्रीन आकार समूह स्क्रीन घनत्व समूह
    QVGA 240 320 2.6 - 3.0 छोटा कम
    WQVGA 240 400 3.2 - 3.5 सामान्य कम
    एफडब्ल्यूक्यूवीजीए 240 432 3.5 - 3.8 सामान्य निम्न
    एचवीजीए 320 480 3.0 - 3.5 सामान्य मध्यम
    डब्लूवीजीए 480 800 3.3 - 4.0 सामान्य उच्च
    - 4.0 सामान्य उच्च डब्लूवीजीए 480
    800 4.8 - 5.5 बड़े मध्यम
    एफडब्ल्यूवीजीए 480 854 5.0 - 5.8 बड़े मध्यम

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

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

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

    8.1.2. गैर-मानक प्रदर्शन कॉन्फ़िगरेशन

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

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

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

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

    8.2. कीबोर्ड

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

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

    8.3. नॉन-टच नेविगेशन

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

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

    8.4. स्क्रीन ओरिएंटेशन

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

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

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

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

    • एक टचस्क्रीन होनी चाहिए,
    • इसमें कैपेसिटिव या प्रतिरोधक टचस्क्रीन होनी चाहिए
    • android.content.res.Configuration डिवाइस

    8.6 पर विशिष्ट टचस्क्रीन के प्रकार के अनुरूप android.content.res.Configuration [संसाधन, 24] का मान रिपोर्ट करना होगा। यूएसबी

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

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

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

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

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

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

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

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

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

    8.9. कैमरा

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

    • कम से कम 2 मेगापिक्सेल का रिज़ॉल्यूशन होना चाहिए
    • या तो हार्डवेयर ऑटो-फ़ोकस होना चाहिए, या कैमरा ड्राइवर में सॉफ़्टवेयर ऑटो-फ़ोकस लागू होना चाहिए (एप्लिकेशन सॉफ़्टवेयर के लिए पारदर्शी)
    • फिक्स्ड-फ़ोकस या ईडीओएफ (फ़ील्ड की विस्तारित गहराई) हो सकता है हार्डवेयर में
    • फ़्लैश शामिल हो सकता है। यदि कैमरे में फ्लैश शामिल है, तो कैमरा पूर्वावलोकन सतह पर 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 इंस्टेंस पंजीकृत करता है और पूर्वावलोकन प्रारूप YCbCr_420_SP होने पर सिस्टम onPreviewFrame() विधि को कॉल करता है, तो onPreviewFrame() में पारित बाइट[] में डेटा NV21 एन्कोडिंग प्रारूप में होना चाहिए। (यह 7k हार्डवेयर परिवार द्वारा मूल रूप से उपयोग किया जाने वाला प्रारूप है।) यानी, NV21 डिफ़ॉल्ट होना चाहिए।

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

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

    8.10. एक्सेलेरोमीटर

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

    8.11. कम्पास

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

    8.12. जीपीएस

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

    8.13. टेलीफोनी

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

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

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

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

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

    नोट: इस खंड को Erratum Ex6580 द्वारा संशोधित किया गया था।

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

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

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

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

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

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

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

    नोट। : इस खंड को Erratum Ex6580 द्वारा जोड़ा गया था।

    8.16. ब्लूटूथ

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

    नोट: इस खंड को Erratum Ex6580 द्वारा जोड़ा गया था।

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

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

    मीट्रिक प्रदर्शन थ्रेशोल्ड टिप्पणियाँ
    एप्लिकेशन लॉन्च समय निम्नलिखित एप्लिकेशन निर्दिष्ट समय के भीतर लॉन्च होने चाहिए।
      ब्राउज़र: 1300ms
    • mms/SMS
    • से कम
      • : 700ms से कम
    • अलार्मक्लॉक: 650ms से कम
    		 लॉन्च समय को एप्लिकेशन के लिए डिफ़ॉल्ट गतिविधि को पूरा करने के लिए कुल समय के रूप में मापा जाता है, जिसमें लिनक्स प्रक्रिया शुरू करने में समय लगता है, एंड्रॉइड को लोड करें Dalvik VM में पैकेज, और oncreate को कॉल करें।
    एक साथ अनुप्रयोग जब कई एप्लिकेशन लॉन्च किए गए हैं, तो लॉन्च किए जाने के बाद पहले से ही चलने वाले एप्लिकेशन को फिर से लॉन्च करना मूल लॉन्च समय से कम लेना चाहिए।  

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

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

    10.1. अनुमतियाँ

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

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

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

    10.3. FileSystem अनुमतियाँ

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

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

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

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

    12. Updatable सॉफ़्टवेयर

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

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

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

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

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

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

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