Android 2.1 के साथ काम करने की जानकारी

कॉपीराइट © 2010, Google Inc. सभी अधिकार सुरक्षित हैं.
[email protected]

1. परिचय

इस दस्तावेज़ में उन ज़रूरी शर्तों के बारे में बताया गया है जिन्हें पूरा करने पर, मोबाइल फ़ोन पर Android 2.1 काम करेगा.

RFC2119 [संसाधन, 1] में बताए गए IETF स्टैंडर्ड के मुताबिक, "ज़रूरी है", "ज़रूरी नहीं है", "ज़रूरी है", "होगा", "नहीं होगा", "चाहिए", "नहीं चाहिए", "सुझाया गया", "हो सकता है", और "ज़रूरी नहीं" का इस्तेमाल किया जाता है.

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

Android 2.1 के साथ काम करने के लिए, डिवाइस में ये चीज़ें होनी चाहिए:

  • इस कंपैटबिलिटी डेफ़िनिशन में बताई गई ज़रूरी शर्तों को पूरा करना ज़रूरी है. इनमें रेफ़रंस के ज़रिए शामिल किए गए दस्तावेज़ भी शामिल हैं.
  • डिवाइस में सॉफ़्टवेयर लागू करने की प्रोसेस पूरी होने के समय, डिवाइस को Android Compatibility Test Suite (CTS) के सबसे नए वर्शन से पास होना ज़रूरी है. (CTS, Android ओपन सोर्स प्रोजेक्ट [संसाधन, 2] के हिस्से के तौर पर उपलब्ध है.) सीटीएस, इस दस्तावेज़ में बताए गए कई कॉम्पोनेंट की जांच करता है, लेकिन सभी की नहीं.

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

2. संसाधन

  1. IETF RFC2119 की ज़रूरी शर्तों के लेवल: http://www.ietf.org/rfc/rfc2119.txt
  2. Android कम्पैटिबिलिटी प्रोग्राम के बारे में खास जानकारी: http://source.android.com/compatibility/index.html
  3. Android ओपन सोर्स प्रोजेक्ट: 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/docs/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. ऐप्लिकेशन विजेट: 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. Search Manager: http://developer.android.com/reference/android/app/SearchManager.html
  16. टोस्ट: http://developer.android.com/reference/android/widget/Toast.html
  17. लाइव वॉलपेपर: https://android-developers.googleblog.com/2010/02/live-wallpapers.html
  18. Android के लिए ऐप्लिकेशन: http://code.google.com/p/apps-for-android
  19. टूल का रेफ़रंस दस्तावेज़ (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. मंकी टेस्टिंग टूल: https://developer.android.com/studio/test/other-testing-tools/monkey
  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. Bluetooth API: http://developer.android.com/reference/android/bluetooth/package-summary.html

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

3. सॉफ़्टवेयर

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

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

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

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

3.2. Soft API Compatibility

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

3.2.1. अनुमतियां

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

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

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

पैरामीटर टिप्पणियां
android.os.Build.VERSION.RELEASE फ़िलहाल चल रहे Android सिस्टम का वर्शन, इंसान के पढ़ने लायक फ़ॉर्मैट में. इस फ़ील्ड में, [संसाधन, 7] में दी गई स्ट्रिंग वैल्यू में से कोई एक वैल्यू होनी चाहिए.
android.os.Build.VERSION.SDK फ़िलहाल चल रहे Android सिस्टम का वर्शन, तीसरे पक्ष के ऐप्लिकेशन कोड के लिए ऐक्सेस किए जा सकने वाले फ़ॉर्मैट में. 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 डिवाइस लागू करने वाले व्यक्ति के चुने गए टैग की सूची, जिन्हें कॉमा लगाकर अलग किया गया है. इससे, बिल्ड को और बेहतर तरीके से अलग किया जा सकता है. उदाहरण के लिए, "unsigned,debug". यह फ़ील्ड, ज़रूर से ज़रूरी है कि वह शून्य या खाली स्ट्रिंग ("") न हो. हालांकि, इसमें एक टैग (जैसे, "रिलीज़") होना ठीक है.
android.os.Build.TIME यह वैल्यू, बिल्ड होने के समय का टाइमस्टैंप दिखाती है.
android.os.Build.TYPE डिवाइस इंप्लीमेंटर की चुनी गई वैल्यू, जो बिल्ड के रनटाइम कॉन्फ़िगरेशन के बारे में बताती है. इस फ़ील्ड में, Android के तीन सामान्य रनटाइम कॉन्फ़िगरेशन में से किसी एक की वैल्यू होनी चाहिए: "user", "userdebug" या "eng".
android.os.Build.USER उस उपयोगकर्ता (या ऑटोमेटेड उपयोगकर्ता) का नाम या यूज़र आईडी जिसने बिल्ड जनरेट किया. इस फ़ील्ड के फ़ॉर्मैट के लिए कोई ज़रूरी शर्त नहीं है. हालांकि, यह ज़रूरी है कि यह शून्य या खाली स्ट्रिंग ("") न हो.

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

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

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

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

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

इन ऐप्लिकेशन को Android सिस्टम के मुख्य ऐप्लिकेशन माना जाता है:

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

Android के मुख्य सिस्टम ऐप्लिकेशन में कई ऐसी गतिविधियां या सेवाएं शामिल होती हैं जिन्हें "सार्वजनिक" माना जाता है. इसका मतलब है कि "android:exported" एट्रिब्यूट मौजूद न हो या उसकी वैल्यू "सही" हो.

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

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

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

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

ध्यान दें: इस सेक्शन में Erratum EX6580 के ज़रिए बदलाव किया गया था.

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

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

यह पाबंदी, सेक्शन 3.6 में बताई गई Java भाषा की क्लास के लिए तय की गई पाबंदी से मिलती-जुलती है.

3.2.3.4. ब्रॉडकास्ट इंटेंट

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

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

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

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

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

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

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

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

3.4. वेब एपीआई के साथ काम करना

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

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

  • Android 2.1 के लिए, वेबव्यू को Android के अपस्ट्रीम ओपन सोर्स ट्री से 530.17 WebKit बिल्ड का इस्तेमाल करना ज़रूरी है. इस बिल्ड में, वेबव्यू के लिए काम करने की सुविधाओं का एक खास सेट और सुरक्षा से जुड़ी गड़बड़ियों को ठीक करने के तरीके शामिल हैं.
  • वेबव्यू की रिपोर्ट की गई उपयोगकर्ता एजेंट स्ट्रिंग इस फ़ॉर्मैट में होनी चाहिए:
    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 की वैल्यू के बराबर होनी चाहिए

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

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

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

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

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

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

Compatibility Test Suite (CTS), प्लैटफ़ॉर्म के अहम हिस्सों की जांच करता है, ताकि यह पता चल सके कि प्लैटफ़ॉर्म पर ऐप्लिकेशन सही तरीके से काम कर रहा है या नहीं. हालांकि, यह सभी हिस्सों की जांच नहीं करता. इसे लागू करने वाले व्यक्ति या कंपनी की ज़िम्मेदारी है कि वह Android Open Source Project के साथ काम करने की सुविधा को पक्का करे.

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

Android, पैकेज और क्लास नेमस्पेस के उन नियमों का पालन करता है जिन्हें Java प्रोग्रामिंग लैंग्वेज ने तय किया है. तीसरे पक्ष के ऐप्लिकेशन के साथ काम करने की सुविधा देने के लिए, डिवाइस इंप्लीमेंटर को इन पैकेज नेमस्पेस में, पाबंदी वाले बदलाव (नीचे देखें) नहीं करने चाहिए:

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

इन बदलावों पर पाबंदी है:

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

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

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

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

ध्यान दें कि ऊपर बताई गई पाबंदियां, Java प्रोग्रामिंग भाषा में एपीआई के नाम रखने के लिए तय किए गए स्टैंडर्ड नियमों के मुताबिक हैं. इस सेक्शन का मकसद, उन नियमों को और बेहतर बनाना है. साथ ही, इस काम के लिए, इस सेक्शन को काम करने के तरीके की परिभाषा में शामिल किया गया है.

3.7. वर्चुअल मशीन के साथ काम करने की सुविधा

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

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

3.8. यूज़र इंटरफ़ेस किस-किस के साथ काम करता है

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

3.8.1. विजेट

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

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

3.8.2. सूचनाएं

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

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

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

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

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

3.8.4. टोस्ट

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

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

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

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

ऊपर बताए गए तरीके से लाइव वॉलपेपर चलाने वाले डिवाइसों को, लाइव वॉलपेपर की सुविधा लागू करनी चाहिए. जिन डिवाइसों पर ऊपर बताए गए तरीके से लाइव वॉलपेपर ठीक से काम नहीं करते उन्हें लाइव वॉलपेपर की सुविधा नहीं देनी चाहिए.

4. सॉफ़्टवेयर के साथ काम करने की जानकारी

डिवाइस पर लागू करने वाले लोगों को, इन ओपन-सोर्स ऐप्लिकेशन का इस्तेमाल करके, लागू करने की सुविधा के साथ काम करने की जांच करनी होगी:

  • कैलकुलेटर (SDK टूल में शामिल है)
  • लूनर लैंडर (SDK टूल में शामिल है)
  • "Android के लिए ऐप्लिकेशन" ऐप्लिकेशन [संसाधन, 18].

ऊपर दिए गए हर ऐप्लिकेशन को लागू करने के बाद, उसे सही तरीके से लॉन्च होना चाहिए और सही तरीके से काम करना चाहिए. ऐसा करने पर ही, इसे लागू करने की सुविधा के साथ काम करने वाला माना जाएगा.

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

  • ApiDemos (SDK टूल में शामिल है)
  • ManualSmokeTests (CTS में शामिल है)

ऊपर दिए गए ऐप्लिकेशन में मौजूद हर टेस्ट केस, डिवाइस पर सही तरीके से चलना चाहिए.

5. ऐप्लिकेशन को पैकेज करने की सुविधा के साथ काम करने की क्षमता

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

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

6. मल्टीमीडिया के साथ काम करना

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

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

ऑडियो
नाम एन्कोडर डिकोडर जानकारी फ़ाइल/कंटेनर फ़ॉर्मैट
AAC LC/LTP   X स्टैंडर्ड बिटरेट के किसी भी कॉम्बिनेशन में मोनो/स्टीरियो कॉन्टेंट, जो 160 केबीपीएस तक हो और सैंपलिंग रेट 8 से 48 किलोहर्ट्ज़ के बीच हो 3GPP (.3gp) और MPEG-4 (.mp4, .m4a). रॉ AAC (.aac) का इस्तेमाल नहीं किया जा सकता
HE-AACv1 (AAC+)   X
HE-AACv2 (बेहतर AAC+)   X
AMR-NB X X 8 केएचज़ पर सैंपल किए गए 4.75 से 12.2 केबीपीएस 3GPP (.3gp)
AMR-WB   X 16 किलोहर्ट्ज़ पर सैंपल किए गए 6.60 केबीपीएस से 23.85 केबीपीएस तक के नौ रेट 3GPP (.3gp)
MP3   X मोनो/स्टीरियो 8-320 केबीपीएस कॉन्स्टेंट (सीबीआर) या वैरिएबल बिटरेट (वीबीआर) MP3 (.mp3)
MIDI   X एमआईडीआई टाइप 0 और 1. डीएलएस का वर्शन 1 और 2. XMF और Mobile XMF. रिंगटोन के लिए RTTTL/RTX, OTA, और iMelody फ़ॉर्मैट का इस्तेमाल किया जा सकता है टाइप 0 और 1 (.mid, .xmf, .mxmf). RTTTL/RTX (.rtttl, .rtx), OTA (.ota), और iMelody (.imy) भी
Ogg Vorbis   X   Ogg (.ogg)
पीसीएम   X 8- और 16-बिट लीनियर PCM (हार्डवेयर की सीमा तक रेट) WAVE (.wav)
इमेज
JPEG X X base+progressive  
GIF   X    
PNG X X    
BMP   X    
वीडियो
H.263 X X   3GPP (.3gp) फ़ाइलें
H.264   X   3GPP (.3gp) और MPEG-4 (.mp4) फ़ाइलें
MPEG4 सिंपल प्रोफ़ाइल   X   3GPP (.3gp) फ़ाइल

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

7. डेवलपर टूल के साथ काम करने वाले डिवाइस

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

  • Android डीबग ब्रिज (जिसे adb कहा जाता है) [संसाधन, 19]
    डिवाइस पर लागू किए गए SDK टूल में, Android SDK में बताए गए सभी adb फ़ंक्शन काम करने चाहिए. डिवाइस-साइड adb डेमन को डिफ़ॉल्ट रूप से बंद होना चाहिए. हालांकि, Android Debug Bridge को चालू करने के लिए, उपयोगकर्ता के पास कोई ऐसा तरीका होना चाहिए जिसका इस्तेमाल किया जा सके.
  • Dalvik Debug Monitor Service (इसे ddms कहा जाता है) [संसाधन, 19]
    डिवाइस में लागू किए गए सिस्टम को, Android SDK में बताई गई सभी ddms सुविधाओं के साथ काम करना चाहिए. ddms, adb का इस्तेमाल करता है. इसलिए, ddms के लिए सहायता डिफ़ॉल्ट रूप से बंद होनी चाहिए. हालांकि, जब भी उपयोगकर्ता ने ऊपर बताए गए तरीके से Android Debug Bridge चालू किया हो, तब यह सहायता चालू होनी चाहिए.
  • Monkey [संसाधन, 22]
    डिवाइस पर लागू करने के लिए, Monkey फ़्रेमवर्क को शामिल करना ज़रूरी है. साथ ही, इसे ऐप्लिकेशन के इस्तेमाल के लिए उपलब्ध कराना होगा.

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

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

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

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

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

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

8.1. डिसप्ले

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

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

स्‍क्रीन का प्रकार चौड़ाई (पिक्सल) ऊंचाई (पिक्सल) डायगनल की लंबाई की रेंज (इंच) स्क्रीन साइज़ ग्रुप स्क्रीन की डेंसिटी का ग्रुप
QVGA 240 320 2.6 - 3.0 छोटा कम
WQVGA 240 400 3.2 - 3.5 सामान्य कम
FWQVGA 240 432 3.5 - 3.8 सामान्य कम
एचवीजीए 320 480 3.0 - 3.5 सामान्य सामान्य जगह पर
WVGA 480 800 3.3 - 4.0 सामान्य ज़्यादा
FWVGA 480 854 3.5 - 4.0 सामान्य ज़्यादा
WVGA 480 800 4.8 - 5.5 बड़ा सामान्य जगह पर
FWVGA 480 854 5.0 - 5.8 बड़ा सामान्य जगह पर

ऊपर दिए गए किसी स्टैंडर्ड कॉन्फ़िगरेशन के हिसाब से डिवाइस को लागू करने के लिए, android.content.res.Configuration [Resources, 24] क्लास की मदद से, ऐप्लिकेशन को स्क्रीन के साइज़ की जानकारी देने के लिए कॉन्फ़िगर करना ज़रूरी है.

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

  • डिवाइस पर लागू करने के लिए, .apk में मौजूद ऐसे संसाधनों को डिकोड करना ज़रूरी है जिनमें डिसप्ले के घनत्व की जानकारी देने वाला एलिमेंट मौजूद न हो. डिफ़ॉल्ट रूप से, ऐसे संसाधनों को "मीडियम" (SDK दस्तावेज़ में इसे "mdpi" कहा जाता है) के तौर पर डिकोड किया जाता है.
  • "कम" डेंसिटी वाली स्क्रीन पर काम करते समय, डिवाइस पर लागू करने के लिए, मीडियम/mdpi एसेट को 0.75 के फ़ैक्टर से छोटा करना ज़रूरी है.
  • "हाई" डेंसिटी वाली स्क्रीन पर काम करते समय, डिवाइस पर लागू करने के लिए, मीडियम/mdpi एसेट को 1.5 गुना बढ़ाना ज़रूरी है.
  • डिवाइस पर लागू करने के लिए, ऐसेट को डेंसिटी रेंज के अंदर स्केल नहीं किया जाना चाहिए. साथ ही, ऐसेट को डेंसिटी रेंज के बीच इन फ़ैक्टर के हिसाब से स्केल किया जाना चाहिए.

8.1.2. स्टैंडर्ड डिसप्ले कॉन्फ़िगरेशन के अलावा अन्य कॉन्फ़िगरेशन

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

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

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

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

8.2. कीबोर्ड

डिवाइस पर लागू करने के तरीके:

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

8.3. बिना छुए नेविगेट करने की सुविधा

डिवाइस पर लागू करने के तरीके:

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

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

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

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

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

डिवाइस पर लागू करने के तरीके:

  • डिवाइस में टचस्क्रीन होना ज़रूरी है
  • इसमें कैपेसिटिव या रेसिस्टिव टचस्क्रीन हो सकती है
  • डिवाइस पर मौजूद टचस्क्रीन के टाइप के हिसाब से, android.content.res.Configuration [संसाधन, 24] की वैल्यू को ज़रूर दिखाना चाहिए

8.6. यूएसबी

डिवाइस पर लागू करने के तरीके:

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

8.7. नेविगेशन बटन

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

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

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

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

अगर किसी डिवाइस में लागू करने के लिए कोई ऐसा मोड शामिल है जिसके लिए Android SDK में कोई एपीआई (जैसे, वाई-फ़ाई, GSM या सीडीएमए) शामिल है, तो लागू करने के लिए उस एपीआई के साथ काम करना ज़रूरी है.

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

8.9. कैमरा

डिवाइस में कैमरा होना ज़रूरी है. इसमें शामिल कैमरा:

  • इसका रिज़ॉल्यूशन कम से कम दो मेगापिक्सल होना चाहिए
  • कैमरा ड्राइवर में, हार्डवेयर ऑटो-फ़ोकस या सॉफ़्टवेयर ऑटो-फ़ोकस की सुविधा होनी चाहिए (ऐप्लिकेशन सॉफ़्टवेयर के लिए पारदर्शी)
  • इसमें फ़िक्स्ड-फ़ोकस या EDOF (एक्सटेंडेड डेप्थ ऑफ़ फ़ील्ड) हार्डवेयर हो सकता है
  • इसमें फ़्लैश शामिल हो सकता है. अगर कैमरे में फ़्लैश है, तो कैमरे की झलक दिखाने वाले प्लैटफ़ॉर्म पर android.hardware.Camera.PreviewCallback का उदाहरण रजिस्टर होने के दौरान, फ़्लैश लैंप नहीं जलना चाहिए. ऐसा तब तक नहीं होगा, जब तक ऐप्लिकेशन ने Camera.Parameters ऑब्जेक्ट के FLASH_MODE_AUTO या FLASH_MODE_ON एट्रिब्यूट को चालू करके, फ़्लैश को साफ़ तौर पर चालू न कर दिया हो. ध्यान दें कि यह पाबंदी, डिवाइस में पहले से मौजूद सिस्टम कैमरे के ऐप्लिकेशन पर लागू नहीं होती. यह सिर्फ़ 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() में पास किए गए byte[] में मौजूद डेटा, NV21 एन्कोडिंग फ़ॉर्मैट में होना चाहिए. (यह वह फ़ॉर्मैट है जिसका इस्तेमाल 7k हार्डवेयर फ़ैमिली नेटिव रूप से करती है.) इसका मतलब है कि NV21, डिफ़ॉल्ट तौर पर होना चाहिए.

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

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

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

डिवाइस में 3-ऐक्सिस ऐक्सीलरॉमीटर होना ज़रूरी है. साथ ही, यह 50 हर्ट्ज़ या इससे ज़्यादा पर इवेंट डिलीवर कर सकता हो. ऐक्सीलेरोमीटर के इस्तेमाल किए गए कोऑर्डिनेट सिस्टम को, Android एपीआई में बताए गए Android सेंसर कोऑर्डिनेट सिस्टम के मुताबिक होना चाहिए. ज़्यादा जानकारी के लिए, [संसाधन, 27] देखें.

8.11. कंपास

डिवाइस में 3-ऐक्सिस वाला कंपास होना चाहिए. साथ ही, यह 10 हर्ट्ज़ या इससे ज़्यादा फ़्रीक्वेंसी पर इवेंट डिलीवर कर सकता हो. कंपास के लिए इस्तेमाल किया जाने वाला निर्देशांक सिस्टम, Android API में बताए गए Android सेंसर निर्देशांक सिस्टम के मुताबिक होना चाहिए. [संसाधन, 27] देखें.

8.12. जीपीएस

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

8.13. टेलीफ़ोनी

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

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

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

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

डिवाइस में उपयोगकर्ता के डेटा के लिए, कम से कम 150 एमबी का नॉन-वॉल्व्यूस्ट स्टोरेज होना चाहिए. इसका मतलब है कि /data पार्टीशन का साइज़ कम से कम 150 एमबी होना चाहिए.

ध्यान दें: इस सेक्शन में Erratum EX6580 के ज़रिए बदलाव किया गया था.

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

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

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

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

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

शेयर किए गए स्टोरेज के तौर पर किसी भी तरह का स्टोरेज इस्तेमाल किया जा सकता है. हालांकि, शेयर किए गए स्टोरेज में ज़रूर USB मेमोरी का इस्तेमाल किया जाना चाहिए, जैसा कि सेक्शन 8.6 में बताया गया है. डिवाइस के साथ मिलने वाले स्टोरेज को FAT फ़ाइल सिस्टम के साथ माउंट करना ज़रूरी है.

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

ध्यान दें: इस सेक्शन को Erratum EX6580 ने जोड़ा था.

8.16. ब्लूटूथ

डिवाइस में ब्लूटूथ ट्रांसीवर होना ज़रूरी है. डिवाइस के लागू होने के लिए, SDK टूल के दस्तावेज़ [संसाधन, 29] में बताए गए तरीके से, RFCOMM पर आधारित ब्लूटूथ एपीआई को चालू करना ज़रूरी है. डिवाइस के लिए, ज़रूरी ब्लूटूथ प्रोफ़ाइलों को लागू करना चाहिए. जैसे, A2DP, एवीआरसीपी, ओबीईएक्स वगैरह.

ध्यान दें: इस सेक्शन को Erratum EX6580 ने जोड़ा था.

9. परफ़ॉर्मेंस के हिसाब से काम करने की सुविधा

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

मेट्रिक परफ़ॉर्मेंस थ्रेशोल्ड टिप्पणियां
ऐप्लिकेशन लॉन्च होने का समय यहां दिए गए ऐप्लिकेशन, तय समय के अंदर लॉन्च होने चाहिए.
  • ब्राउज़र: 1300 मिलीसेकंड से कम
  • एमएमएस/एसएमएस: 700 मि.से. से कम
  • AlarmClock: 650 मि.से. से कम
 ऐप्लिकेशन को लॉन्च होने में लगने वाला समय, ऐप्लिकेशन के लिए डिफ़ॉल्ट गतिविधि को लोड होने में लगने वाले कुल समय के तौर पर मेज़र किया जाता है. इसमें, Linux प्रोसेस शुरू करने, Android पैकेज को Dalvik VM में लोड करने, और onCreate को कॉल करने में लगने वाला समय भी शामिल है.
एक साथ कई आवेदन करना जब एक से ज़्यादा ऐप्लिकेशन लॉन्च किए जाते हैं, तो पहले से चल रहे ऐप्लिकेशन को फिर से लॉन्च करने में, लॉन्च करने के मूल समय से कम समय लगना चाहिए.  

10. सुरक्षा मॉडल के साथ काम करने की सुविधा

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

10.1. अनुमतियां

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

10.2. यूआईडी और प्रोसेस अलग करना

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

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

डिवाइस में, सुरक्षा और अनुमतियों के रेफ़रंस [संसाधन, 28] में बताए गए Android फ़ाइल ऐक्सेस की अनुमतियों के मॉडल का इस्तेमाल किया जाना चाहिए.

11. Compatibility Test Suite

डिवाइस पर लागू किए गए बदलावों को, Android Open Source Project से उपलब्ध Android Compatibility Test Suite (CTS) [संसाधन, 2] की जांच में पास होना चाहिए. इसके लिए, डिवाइस पर शिपिंग के लिए तैयार सॉफ़्टवेयर का इस्तेमाल करें. इसके अलावा, डिवाइस को लागू करने वाले लोगों को, Android ओपन सोर्स ट्री में मौजूद रेफ़रंस को लागू करने के तरीके का ज़्यादा से ज़्यादा इस्तेमाल करना चाहिए. साथ ही, उन्हें यह पक्का करना होगा कि CTS में किसी तरह की गड़बड़ी होने पर और रेफ़रंस सोर्स कोड के कुछ हिस्सों को फिर से लागू करने पर, डिवाइस काम करता रहे.

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

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

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

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

  • रीबूट करके ऑफ़लाइन अपडेट करने के साथ-साथ, ओवर-द-एयर (ओटीए) डाउनलोड
  • होस्ट पीसी से यूएसबी के ज़रिए "टethered" अपडेट
  • रीबूट करने के बाद "ऑफ़लाइन" अपडेट और हटाने लायक स्टोरेज में मौजूद फ़ाइल से अपडेट

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

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

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

अगर आपको इस बारे में ज़्यादा जानकारी चाहिए या आपको लगता है कि दस्तावेज़ में किसी समस्या के बारे में नहीं बताया गया है, तो [email protected] पर दस्तावेज़ के लेखकों से संपर्क करें.