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

कॉपीराइट © 2010, Google Inc. सभी अधिकार सुरक्षित हैं.
compatibility@android.com

विषय सूची

1. परिचय

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

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

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

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

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

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

2. संसाधन

1. IETF आरएफ़सी2119 की ज़रूरी शर्तों के लेवल: http://www.ietf.org/rfc/rfc2119.txt
2. Android Compatibility Program के बारे में खास जानकारी: http://source.android.com/docs/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.2 के साथ काम करने वाली वर्शन स्ट्रिंग: http://source.android.com/docs/compatibility/2.2/versions.html
8. android.webkit.WebView क्लास: http://developer.android.com/reference/android/webkit/WebView.html
9. HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/
10. 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. Monkey टेस्टिंग टूल: https://developer.android.com/studio/test/other-testing-tools/monkey
23. Android हार्डवेयर की सुविधाओं की सूची: http://developer.android.com/reference/android/content/pm/PackageManager.html
24. एक से ज़्यादा स्क्रीन के साथ काम करना: http://developer.android.com/guide/practices/screens_support.html
25. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html
26. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
27. android.hardware.Camera: http://developer.android.com/reference/android/hardware/Camera.html
28. सेंसर कोऑर्डिनेट स्पेस: http://developer.android.com/reference/android/hardware/SensorEvent.html
29. Android की सुरक्षा और अनुमतियों के बारे में जानकारी: http://developer.android.com/guide/topics/security/security.html
30. ब्लूटूथ एपीआई: http://developer.android.com/reference/android/bluetooth/package-summary.html

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

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

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

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

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

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

3.2. Soft API Compatibility

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

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.2 के लिए, इस फ़ील्ड में पूरी संख्या के तौर पर 8 वैल्यू होनी चाहिए.
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.2/ERC77/3359:userdebug/test-keys फ़िंगरप्रिंट में खाली जगह वाले वर्ण नहीं होने चाहिए. अगर ऊपर दिए गए टेंप्लेट में शामिल अन्य फ़ील्ड में खाली जगह वाले वर्ण हैं, तो उन्हें बिल्ड फ़िंगरप्रिंट में किसी दूसरे वर्ण से बदलना ज़रूरी है. जैसे, अंडरस्कोर ("_") वर्ण.
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 एक एक्सटेंसिबल प्लैटफ़ॉर्म है. इसलिए, डिवाइस लागू करने वाले लोगों को यह अनुमति देनी होगी कि सेक्शन 3.2.3.1 में दिए गए हर इंटेंट पैटर्न को तीसरे पक्ष के ऐप्लिकेशन बदल सकें. अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट, डिफ़ॉल्ट रूप से इसकी अनुमति देता है. डिवाइस को लागू करने वाले लोगों को, सिस्टम ऐप्लिकेशन के इन इंटेंट पैटर्न के इस्तेमाल के लिए खास अधिकार नहीं देने चाहिए. इसके अलावा, तीसरे पक्ष के ऐप्लिकेशन को इन पैटर्न को बांधने और उनका कंट्रोल लेने से भी नहीं रोकना चाहिए. इस पाबंदी में, "चुने गए" यूज़र इंटरफ़ेस को बंद करना शामिल है. हालांकि, इसमें और भी चीज़ें शामिल हो सकती हैं. इस यूज़र इंटरफ़ेस की मदद से, उपयोगकर्ता एक से ज़्यादा ऐप्लिकेशन में से किसी एक को चुन सकता है. ये सभी ऐप्लिकेशन एक ही इंटेंट पैटर्न को हैंडल करते हैं.

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 के उपयोगकर्ता अनुभव के लिए, वेब पर बेहतर अनुभव देना ज़रूरी है. डिवाइस में लागू किए गए android.webkit.WebView का वर्शन, अपस्ट्रीम Android सॉफ़्टवेयर के हिसाब से होना चाहिए. साथ ही, इसमें ऐसा आधुनिक ब्राउज़र होना चाहिए जो HTML5 के साथ काम करता हो. इस बारे में यहां बताया गया है.

3.4.1. वेबव्यू के साथ काम करना

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

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

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

3.4.2. ब्राउज़र किस-किस के साथ काम करता है

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

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

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

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] का इस्तेमाल किया जाना चाहिए.

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

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

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

3.8.1. विजेट

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

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

3.8.2. सूचनाएं

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

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

3.8.3. खोजें

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].
• Replica Island (Android Market में उपलब्ध है; सिर्फ़ उन डिवाइसों के लिए ज़रूरी है जिन पर OpenGL ES 2.0 काम करता है)

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

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

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

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

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

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

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

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

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

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

डिवाइस में इन मल्टीमीडिया कोडेक का इस्तेमाल किया जाना चाहिए. ये सभी कोडेक, 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) फ़ाइल

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

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

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

• अगर शोर कम करने की सुविधा मौजूद है, तो उसे बंद करना चाहिए.
• अगर ऑटोमैटिक गेन कंट्रोल की सुविधा मौजूद है, तो उसे बंद करना चाहिए.
• डिवाइस में, फ़्रीक्वेंसी के हिसाब से ऐम्प्ल्यट्यूड में ज़्यादा उतार-चढ़ाव नहीं होना चाहिए. खास तौर पर, 100 हर्ट्ज़ से 4,000 हर्ट्ज़ के बीच, ±3 डीबी
• ऑडियो इनपुट की संवेदनशीलता को इस तरह से सेट किया जाना चाहिए कि 1000 हर्ट्ज़ पर 90 डीबी साउंड पावर लेवल (एसपीएल) सोर्स से, 16-बिट सैंपल के लिए आरएमएस 5,000 मिल सके.
• पीसीएम ऐम्प्ल्यट्यूड लेवल को, इनपुट एसपीएल में होने वाले बदलावों को कम से कम 30 डीबी की रेंज में, रेखीय तरीके से ट्रैक करना चाहिए. यह रेंज, माइक्रोफ़ोन पर 90 डीबी एसपीएल से -18 डीबी से लेकर +12 डीबी तक होनी चाहिए.
• 90 dB SPL इनपुट लेवल पर, 100 हर्ट्ज़ से 4,000 हर्ट्ज़ तक कुल हारमोनिक डिस्टॉर्शन 1% से कम होना चाहिए.

ध्यान दें: Android 2.2 के लिए, ऊपर बताई गई ज़रूरी शर्तों को "इसका होना ज़रूरी है" के तौर पर बताया गया है. हालांकि, आने वाले वर्शन के लिए, इन शर्तों को "इसका होना ज़रूरी है" के तौर पर बदलने का प्लान है. इसका मतलब है कि Android 2.2 में ये ज़रूरी शर्तें लागू नहीं होतीं. हालांकि, आने वाले वर्शन में इन शर्तों को पूरा करना ज़रूरी होगा. Android 2.2 पर काम करने वाले मौजूदा और नए डिवाइसों को Android 2.2 में इन ज़रूरी शर्तों को पूरा करने का सुझाव दिया जाता है. ऐसा न करने पर, आने वाले समय में डिवाइसों को Android के नए वर्शन पर अपग्रेड नहीं किया जा सकेगा.

6.3. ऑडियो के इंतज़ार का समय

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

इस सेक्शन के लिए:

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

ऊपर दी गई परिभाषाओं का इस्तेमाल करके, डिवाइस के लागू होने पर इनमें से हर प्रॉपर्टी दिखनी चाहिए:

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

ध्यान दें: Android 2.2 के लिए, ऊपर बताई गई ज़रूरी शर्तों को "इसका होना ज़रूरी है" के तौर पर बताया गया है. हालांकि, आने वाले वर्शन के लिए, इन शर्तों को "इसका होना ज़रूरी है" के तौर पर बदलने का प्लान है. इसका मतलब है कि Android 2.2 में ये ज़रूरी शर्तें लागू नहीं होतीं. हालांकि, आने वाले वर्शन में इन शर्तों को पूरा करना ज़रूरी होगा. Android 2.2 पर काम करने वाले मौजूदा और नए डिवाइसों को Android 2.2 में इन ज़रूरी शर्तों को पूरा करने का सुझाव दिया जाता है. ऐसा न करने पर, आने वाले समय में डिवाइसों को Android के नए वर्शन पर अपग्रेड नहीं किया जा सकेगा.

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.2 के साथ काम करने वाले सभी डिवाइसों में होनी चाहिए.

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

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

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

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

8.1. डिसप्ले

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

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

स्‍क्रीन का प्रकार	चौड़ाई (पिक्सल)	ऊंचाई (पिक्सल)	डायगनल की लंबाई की रेंज (इंच)	स्क्रीन साइज़ ग्रुप	स्क्रीन की डेंसिटी का ग्रुप
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 में दिए गए स्टैंडर्ड कॉन्फ़िगरेशन से मेल न खाने वाले डिसप्ले कॉन्फ़िगरेशन के लिए, ज़्यादा ध्यान देने की ज़रूरत होती है. साथ ही, यह भी ज़रूरी है कि वे काम करते हों. डिवाइस लागू करने वाले लोगों को, स्क्रीन साइज़ की बकेट, घनत्व, और स्केलिंग फ़ैक्टर के लिए कैटगरी पाने के लिए, सेक्शन 13 में बताए गए तरीके के मुताबिक Android के साथ काम करने वाली टीम से संपर्क करना होगा. जब डिवाइस पर इस जानकारी को लागू किया जाता है, तो उसे बताए गए तरीके से लागू करना ज़रूरी है.

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

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

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

8.1.4. डिक्लेयर्ड स्क्रीन सपोर्ट

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

8.2. कीबोर्ड

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

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

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

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

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

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

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

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

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

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

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

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.2 SDK टूल के दस्तावेज़ [संसाधन, 27] में शामिल Camera API को लागू करना ज़रूरी है. भले ही, डिवाइस में हार्डवेयर ऑटोफ़ोकस या अन्य सुविधाएं हों या नहीं. उदाहरण के लिए, जिन कैमरों में ऑटोफ़ोकस की सुविधा नहीं होती है उन्हें भी रजिस्टर किए गए किसी भी android.hardware.Camera.AutoFocusCallback इंस्टेंस को कॉल करना होगा. भले ही, ऑटोफ़ोकस की सुविधा न होने वाले कैमरे के लिए, ऐसा करना ज़रूरी नहीं है.

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

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

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

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

8.11. कंपास

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

8.12. जीपीएस

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

8.13. टेलीफ़ोनी

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8.16. ब्लूटूथ

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

Compatibility Test Suite में ऐसे मामले शामिल होते हैं जिनमें Android RFCOMM Bluetooth API के बुनियादी काम को कवर किया जाता है. हालांकि, ब्लूटूथ एक ऐसा प्रोटोकॉल है जिसका इस्तेमाल डिवाइसों के बीच कम्यूनिकेशन के लिए किया जाता है. इसलिए, किसी एक डिवाइस पर चलने वाली यूनिट टेस्ट से, इसकी पूरी जांच नहीं की जा सकती. इसलिए, डिवाइस को लागू करने के लिए, ऐप्लिकेशन को अध्यांश A में बताए गए, मानव-चालित ब्लूटूथ टेस्ट प्रोसेस से भी गुज़रना होगा.

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

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

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

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

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

10.1. अनुमतियां

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

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

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

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

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

10.4. एक्ज़ीक्यूशन के अन्य एनवायरमेंट

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

वैकल्पिक रनटाइम, Android ऐप्लिकेशन होने चाहिए. साथ ही, ये ऐप्लिकेशन, सेक्शन 10 में बताए गए स्टैंडर्ड Android सुरक्षा मॉडल का पालन करते होने चाहिए.

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

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

वैकल्पिक रनटाइम, Android सैंडबॉक्स मॉडल का पालन करते हों. खास तौर से:

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

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

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

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

11. Compatibility Test Suite

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

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

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

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

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

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

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

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

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

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

परिशिष्ट A - ब्लूटूथ टेस्ट करने का तरीका

Compatibility Test Suite में ऐसे मामले शामिल होते हैं जिनमें Android RFCOMM Bluetooth API के बुनियादी काम को कवर किया जाता है. हालांकि, ब्लूटूथ एक ऐसा प्रोटोकॉल है जिसका इस्तेमाल डिवाइसों के बीच कम्यूनिकेशन के लिए किया जाता है. इसलिए, किसी एक डिवाइस पर चलने वाली यूनिट टेस्ट से, इसकी पूरी जांच नहीं की जा सकती. इसलिए, डिवाइस को लागू करने के लिए, यहां बताए गए मानव-चालित ब्लूटूथ टेस्ट प्रोसेस को भी पास करना ज़रूरी है.

टेस्ट करने का तरीका, Android के ओपन-सोर्स प्रोजेक्ट ट्री में शामिल BluetoothChat सैंपल ऐप्लिकेशन पर आधारित है. इस प्रोसेस के लिए, दो डिवाइसों की ज़रूरत होती है:

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

यहां दी गई जांच की प्रोसेस में, इन डिवाइसों को "कैंडिडेट" और "जानकारी के मुताबिक सही" डिवाइसों के तौर पर दिखाया गया है.

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

1. Android सोर्स कोड ट्री से 'सैंपल बनाएं' विकल्प का इस्तेमाल करके, BluetoothChat.apk बनाएं.
2. जिस डिवाइस पर BluetoothChat.apk काम कर रहा है उस पर इसे इंस्टॉल करें.
3. टेस्ट किए जाने वाले डिवाइस पर BluetoothChat.apk इंस्टॉल करें.

ऐप्लिकेशन से ब्लूटूथ कंट्रोल करने की सुविधा की जांच करना

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

डिवाइसों को जोड़ने और उनके बीच डेटा ट्रांसफ़र करने की जांच करना

1. दोनों डिवाइसों पर Bluetooth Chat ऐप्लिकेशन खोलें.
2. मेन्यू का इस्तेमाल करके, BluetoothChat में जाकर, उस डिवाइस को खोजे जाने लायक बनाएं जिस पर आपका ऐप्लिकेशन काम करता है.
3. जिस डिवाइस को टेस्ट करना है उस पर, मेन्यू का इस्तेमाल करके BluetoothChat में जाकर ब्लूटूथ डिवाइसों को स्कैन करें. इसके बाद, किसी ऐसे डिवाइस से जोड़ें जो पहले से काम कर रहा है.
4. हर डिवाइस से 10 या उससे ज़्यादा मैसेज भेजें और पुष्टि करें कि दूसरे डिवाइस पर वे मैसेज सही तरीके से मिले हैं.
5. होम बटन दबाकर, दोनों डिवाइसों पर BluetoothChat ऐप्लिकेशन बंद करें.
6. डिवाइस के Settings ऐप्लिकेशन का इस्तेमाल करके, हर डिवाइस को एक-दूसरे से अनपेयर करें.

रिवर्स डायरेक्शन में पेयरिंग और कम्यूनिकेशन की जांच करना

1. दोनों डिवाइसों पर Bluetooth Chat ऐप्लिकेशन खोलें.
2. BluetoothChat में जाकर, मेन्यू का इस्तेमाल करके, कनेक्ट करने के लिए चुने गए डिवाइस को खोजे जाने लायक बनाएं.
3. जिस डिवाइस पर समस्या नहीं है उस पर, मेन्यू का इस्तेमाल करके BluetoothChat में जाकर ब्लूटूथ डिवाइसों को स्कैन करें. इसके बाद, उस डिवाइस से जोड़ें जिस पर समस्या है.
4. हर डिवाइस से 10 या उससे ज़्यादा मैसेज भेजें और पुष्टि करें कि दूसरे डिवाइस पर वे मैसेज सही तरीके से मिल रहे हैं.
5. दोनों डिवाइसों पर, ब्लूटूथ चैट ऐप्लिकेशन बंद करें. इसके लिए, लॉन्चर पर जाने के लिए, 'वापस जाएं' बटन को बार-बार दबाएं.

फिर से लॉन्च करने की जांच करना

1. दोनों डिवाइसों पर, Bluetooth Chat ऐप्लिकेशन को फिर से लॉन्च करें.
2. हर डिवाइस से 10 या उससे ज़्यादा मैसेज भेजें और पुष्टि करें कि दूसरे डिवाइस पर वे मैसेज सही तरीके से मिल रहे हैं.

ध्यान दें: ऊपर दिए गए टेस्ट में कुछ ऐसे मामले हैं जिनमें होम का इस्तेमाल करके टेस्ट सेक्शन को खत्म किया जाता है और कुछ में बैक का इस्तेमाल करके. ये टेस्ट ज़रूरी हैं और इन्हें करना ज़रूरी है: इसका मकसद यह पुष्टि करना है कि गतिविधियों को साफ़ तौर पर बंद करने (उपयोगकर्ता के 'वापस जाएं' बटन को दबाने पर, जो 'पूरा हो गया' को कॉल करता है) और बैकग्राउंड में भेजने (उपयोगकर्ता के होम बटन को दबाने पर) के बाद, Bluetooth API और स्टैक सही तरीके से काम करता है या नहीं. हर टेस्ट सीक्वेंस को बताए गए तरीके से ही पूरा करना ज़रूरी है.