Android 2.1 संगतता परिभाषा

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

1 परिचय

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

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

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

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

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

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

2. संसाधन

  1. IETF RFC2119 आवश्यकता स्तर: http://www.ietf.org/rfc/rfc2119.txt
  2. Android संगतता कार्यक्रम अवलोकन: http://source.android.com/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.1 अनुमत संस्करण स्ट्रिंग्स: http://source.android.com/compatibility/2.1/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. Dalvik वर्चुअल मशीन विनिर्देश: Android स्रोत कोड में dalvik/docs पर उपलब्ध है
  11. AppWidgets: 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. लाइव वॉलपेपर: http://developer.android.com/resources/articles/live-wallpapers.html
  18. Android के लिए ऐप्स: http://code.google.com/p/apps-for-android
  19. संदर्भ उपकरण प्रलेखन (adb, aapt, ddms के लिए): http://developer.android.com/guide/developing/tools/index.html
  20. Android APK फ़ाइल विवरण: http://developer.android.com/guide/topics/fundamentals.html
  21. मैनिफ़ेस्ट फ़ाइलें: http://developer.android.com/guide/topics/manifest/manifest-intro.html
  22. बंदर परीक्षण उपकरण: http://developer.android.com/guide/developing/tools/monkey.html
  23. एकाधिक स्क्रीन का समर्थन: http://developer.android.com/guide/practices/screens_support.html
  24. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html
  25. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
  26. android.hardware.Camera: http://developer.android.com/reference/android/hardware/Camera.html
  27. सेंसर समन्वय स्थान: http://developer.android.com/reference/android/hardware/SensorEvent.html
  28. Android सुरक्षा और अनुमतियाँ संदर्भ: http://developer.android.com/guide/topics/security/security.html
  29. ब्लूटूथ एपीआई: http://developer.android.com/reference/android/bluetooth/package-summary.html

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

3. सॉफ्टवेयर

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

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

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

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

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

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

3.2.1. अनुमतियां

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

3.2.2 पैरामीटर बनाएँ

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

पैरामीटर टिप्पणियाँ
android.os.Build.VERSION.RELEASE मानव-पठनीय प्रारूप में वर्तमान में निष्पादित एंड्रॉइड सिस्टम का संस्करण। इस फ़ील्ड में [ संसाधन, 7 ] में परिभाषित स्ट्रिंग मानों में से एक होना चाहिए।
android.os.Build.VERSION.SDK वर्तमान में निष्पादित एंड्रॉइड सिस्टम का संस्करण, तीसरे पक्ष के एप्लिकेशन कोड के लिए सुलभ प्रारूप में। Android 2.1 के लिए, इस फ़ील्ड का पूर्णांक मान 7 होना चाहिए।
android.os.Build.VERSION.INCREMENTAL मानव-पठनीय प्रारूप में, वर्तमान में निष्पादित Android सिस्टम के विशिष्ट निर्माण को निर्दिष्ट करने वाले उपकरण कार्यान्वयनकर्ता द्वारा चुना गया मान। अंतिम उपयोगकर्ताओं को भेजे गए विभिन्न बिल्ड के लिए इस मान का पुन: उपयोग नहीं किया जाना चाहिए। इस फ़ील्ड का एक विशिष्ट उपयोग यह इंगित करना है कि बिल्ड बनाने के लिए कौन सा बिल्ड नंबर या स्रोत-नियंत्रण परिवर्तन पहचानकर्ता का उपयोग किया गया था। इस फ़ील्ड के विशिष्ट प्रारूप पर कोई आवश्यकता नहीं है, सिवाय इसके कि यह शून्य या खाली स्ट्रिंग ("") नहीं होना चाहिए।
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. मुख्य आवेदन इरादे

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

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

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

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

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

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

3.2.3.2. इरादा ओवरराइड

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

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

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

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

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

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

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

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

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

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

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

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

3.4. वेब एपीआई संगतता

कई डेवलपर और एप्लिकेशन अपने यूजर इंटरफेस के लिए android.webkit.WebView वर्ग [ संसाधन, 8 ] के व्यवहार पर भरोसा करते हैं, इसलिए WebView कार्यान्वयन Android कार्यान्वयन के लिए संगत होना चाहिए। Android ओपन सोर्स कार्यान्वयन WebView को लागू करने के लिए WebKit रेंडरिंग इंजन का उपयोग करता है।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8. यूजर इंटरफेस संगतता

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

3.8.1. विजेट

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

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

3.8.2. सूचनाएं

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

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

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

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

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

3.8.4. टोस्ट

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

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

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

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

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

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

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

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

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

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

5. आवेदन पैकेजिंग संगतता

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

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

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

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

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

ऑडियो
नाम एनकोडर डिकोडर विवरण फ़ाइल/कंटेनर प्रारूप
एएसी एलसी / एलटीपी एक्स 160 kbps तक की मानक बिट दरों और 8 से 48kHz के बीच नमूना दरों के किसी भी संयोजन में मोनो/स्टीरियो सामग्री 3GPP (.3gp) और MPEG-4 (.mp4, .m4a)। कच्चे AAC (.aac) के लिए कोई समर्थन नहीं
एचई-एएसीवी1 (एएसी+) एक्स
HE-AACv2 (उन्नत AAC+) एक्स
एएमआर-एनबी एक्स एक्स 4.75 से 12.2 केबीपीएस नमूना @ 8kHz 3जीपीपी (.3जीपी)
एएमआर-पश्चिम बंगाल एक्स 9 दरें 6.60 kbit/s से 23.85 kbit/s नमूना @ 16kHz 3जीपीपी (.3जीपी)
एमपी 3 एक्स मोनो/स्टीरियो 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)
पीसीएम एक्स 8- और 16-बिट रैखिक पीसीएम (हार्डवेयर की सीमा तक दरें) वेव (.wav)
छवि
जेपीईजी एक्स एक्स आधार+प्रगतिशील
जीआईएफ एक्स
पीएनजी एक्स एक्स
बीएमपी एक्स
वीडियो
एच .263 एक्स एक्स 3GPP (.3gp) फ़ाइलें
264 एक्स 3GPP (.3gp) और MPEG-4 (.mp4) फ़ाइलें
MPEG4 सरल प्रोफ़ाइल एक्स 3GPP (.3gp) फ़ाइल

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

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

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

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

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

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

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

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

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

8.1. दिखाना

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

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

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

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

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

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

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

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

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

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

8.2. कीबोर्ड

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

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

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

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

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

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

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

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

8.6. यु एस बी

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

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

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

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

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

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

यदि किसी उपकरण कार्यान्वयन में एक विशेष साधन शामिल है जिसके लिए Android SDK में एक API (अर्थात, WiFi, GSM, या CDMA) शामिल है, तो कार्यान्वयन को API का समर्थन करना चाहिए।

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

8.9. कैमरा

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

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

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

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

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

8.10. accelerometer

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

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

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

8.12. GPS

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

8.13. टेलीफ़ोनी

Android 2.1 का उपयोग उन उपकरणों पर किया जा सकता है जिनमें टेलीफ़ोनी हार्डवेयर शामिल नहीं है। अर्थात्, Android 2.1 उन उपकरणों के साथ संगत है जो फ़ोन नहीं हैं। हालाँकि, यदि किसी उपकरण के कार्यान्वयन में GSM या CDMA टेलीफोनी शामिल है, तो उसे उस तकनीक के लिए API के लिए पूर्ण समर्थन लागू करना होगा। डिवाइस कार्यान्वयन जिनमें टेलीफ़ोनी हार्डवेयर शामिल नहीं है, उन्हें पूर्ण APIs को नो-ऑप्स के रूप में लागू करना होगा।

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

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

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

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

8.15. एप्लिकेशन साझा संग्रहण

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

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

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

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

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

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

8.16. ब्लूटूथ

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

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

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

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

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

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

10.1. अनुमतियां

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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