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

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

विषय सूची

1. परिचय
2. संसाधन
3. सॉफ़्टवेयर
3.1. मैनेज किए जा रहे एपीआई के साथ काम करने की सुविधा
3.2. Soft API Compatibility
3.3. नेटिव एपीआई के साथ काम करना
3.4. वेब पर काम करना
3.5. एपीआई के काम करने के तरीके से जुड़ी शर्तें
3.6. एपीआई नेमस्पेस
3.7. वर्चुअल मशीन के साथ काम करने की सुविधा
3.8. यूज़र इंटरफ़ेस के साथ काम करना
4. ऐप्लिकेशन पैकेजिंग के साथ काम करने की सुविधा
5. मल्टीमीडिया कॉन्टेंट के साथ काम करना
6. डेवलपर टूल के साथ काम करने की सुविधा
7. हार्डवेयर के साथ काम करना
7.1. डिसप्ले और ग्राफ़िक्स
7.2. इनपुट डिवाइस
7.3. सेंसर
7.4. डेटा कनेक्टिविटी
7.5. कैमरे
7.6. मेमोरी और स्टोरेज
7.7. यूएसबी
8. परफ़ॉर्मेंस के हिसाब से काम करना
9. सुरक्षा मॉडल के साथ काम करने की सुविधा
10. सॉफ़्टवेयर के साथ काम करने की जांच
11. अपडेट किया जा सकने वाला सॉफ़्टवेयर
12. हमसे संपर्क करें
अनुबंध A - ब्लूटूथ टेस्ट करने का तरीका

1. परिचय

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

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

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

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

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

कृपया ध्यान दें कि यह काम करने की शर्त, Android के 2.3.3 वर्शन के साथ काम करने के लिए जारी की गई है. यह वर्शन, एपीआई लेवल 10 है. यह परिभाषा, Android 2.3.3 से पहले के वर्शन के लिए, काम करने की शर्तों की पुरानी परिभाषा को बदल देती है और उसकी जगह ले लेती है. इसका मतलब है कि 2.3.1 और 2.3.2 वर्शन अब काम नहीं करते. आने वाले समय में, Android 2.3 पर काम करने वाले डिवाइसों को 2.3.3 या उसके बाद के वर्शन के साथ शिप करना ज़रूरी है.

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.3 के साथ काम करने वाली वर्शन स्ट्रिंग: http://source.android.com/docs/compatibility/2.3/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. HTML5 की ऑफ़लाइन सुविधाएं: http://dev.w3.org/html5/spec/Overview.html#offline
  11. HTML5 वीडियो टैग: http://dev.w3.org/html5/spec/Overview.html#video
  12. HTML5/W3C जियोलोकेशन एपीआई: http://www.w3.org/TR/geolocation-API/
  13. HTML5/W3C वेबडेटाबेस एपीआई: http://www.w3.org/TR/webdatabase/
  14. HTML5/W3C IndexedDB API: http://www.w3.org/TR/IndexedDB/
  15. Dalvik वर्चुअल मशीन की खास जानकारी: यह Android के सोर्स कोड में, dalvik/docs पर उपलब्ध है
  16. ऐप्लिकेशन विजेट: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
  17. सूचनाएं: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
  18. ऐप्लिकेशन के लिए संसाधन: http://code.google.com/android/reference/available-resources.html
  19. स्टेटस बार के आइकॉन की स्टाइल गाइड: http://developer.android.com/guide/practices/ui_guideline /icon_design.html#statusbarstructure
  20. Search Manager: http://developer.android.com/reference/android/app/SearchManager.html
  21. टॉस्ट: http://developer.android.com/reference/android/widget/Toast.html
  22. लाइव वॉलपेपर: https://android-developers.googleblog.com/2010/02/live-wallpapers.html
  23. टूल से जुड़ा रेफ़रंस दस्तावेज़ (adb, aapt, ddms के लिए): http://developer.android.com/guide/developing/tools/index.html
  24. Android APK फ़ाइल के बारे में जानकारी: http://developer.android.com/guide/topics/fundamentals.html
  25. मेनिफ़ेस्ट फ़ाइलें: http://developer.android.com/guide/topics/manifest/manifest-intro.html
  26. Monkey टेस्टिंग टूल: https://developer.android.com/studio/test/other-testing-tools/monkey
  27. Android हार्डवेयर की सुविधाओं की सूची: http://developer.android.com/reference/android/content/pm/PackageManager.html
  28. एक से ज़्यादा स्क्रीन के साथ काम करना: http://developer.android.com/guide/practices/screens_support.html
  29. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
  30. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html
  31. सेंसर कोऑर्डिनेट स्पेस: http://developer.android.com/reference/android/hardware/SensorEvent.html
  32. ब्लूटूथ एपीआई: http://developer.android.com/reference/android/bluetooth/package-summary.html
  33. NDEF पुश प्रोटोकॉल: http://source.android.com/docs/compatibility/ndef-push-protocol.pdf
  34. MIFARE MF1S503X: http://www.nxp.com/documents/data_sheet/MF1S503x.pdf
  35. MIFARE MF1S703X: http://www.nxp.com/documents/data_sheet/MF1S703x.pdf
  36. MIFARE MF0ICU1: http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf
  37. MIFARE MF0ICU2: http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf
  38. MIFARE AN130511: http://www.nxp.com/documents/application_note/AN130511.pdf
  39. MIFARE AN130411: http://www.nxp.com/documents/application_note/AN130411.pdf
  40. कैमरे के ओरिएंटेशन का एपीआई: http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)
  41. android.hardware.Camera: http://developer.android.com/reference/android/hardware/Camera.html
  42. Android की सुरक्षा और अनुमतियों के बारे में जानकारी: http://developer.android.com/guide/topics/security/security.html
  43. Android के लिए ऐप्लिकेशन: http://code.google.com/p/apps-for-android

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

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

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

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

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

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

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

3.2. Soft API Compatibility

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

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.3 के लिए, इस फ़ील्ड में पूरी संख्या 9 होनी चाहिए.
android.os.Build.VERSION.INCREMENTAL डिवाइस इंप्लीमेंटर की चुनी गई वैल्यू, जो फ़िलहाल चल रहे Android सिस्टम के खास बिल्ड को इंसान के पढ़ने लायक फ़ॉर्मैट में दिखाती है. इस वैल्यू का इस्तेमाल, असली उपयोगकर्ताओं के लिए उपलब्ध कराए गए अलग-अलग बिल्ड के लिए फिर से नहीं किया जाना चाहिए. इस फ़ील्ड का आम तौर पर इस्तेमाल, यह बताने के लिए किया जाता है कि बिल्ड जनरेट करने के लिए, किस बिल्ड नंबर या सोर्स-कंट्रोल में बदलाव करने वाले आइडेंटिफ़ायर का इस्तेमाल किया गया था. इस फ़ील्ड के लिए, किसी खास फ़ॉर्मैट की ज़रूरत नहीं होती. हालांकि, यह शर्त ज़रूरी है कि यह शून्य या खाली स्ट्रिंग ("") न हो.
android.os.Build.BOARD डिवाइस लागू करने वाले व्यक्ति की चुनी गई वैल्यू, जो डिवाइस में इस्तेमाल किए गए खास इंटरनल हार्डवेयर की पहचान करती है. यह वैल्यू, इंसान के पढ़ने लायक फ़ॉर्मैट में होती है. इस फ़ील्ड का इस्तेमाल, डिवाइस को पावर देने वाले बोर्ड के खास वर्शन की जानकारी देने के लिए किया जा सकता है. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है. साथ ही, यह वैल्यू रेगुलर एक्सप्रेशन "^[a-zA-Z0-9.,_-]+$" से मैच करनी चाहिए.
android.os.Build.BRAND डिवाइस लागू करने वाले व्यक्ति या कंपनी की चुनी गई वैल्यू, जिसमें डिवाइस बनाने वाली कंपनी, संगठन, व्यक्ति वगैरह का नाम, आम तौर पर पढ़े जा सकने वाले फ़ॉर्मैट में दिया गया हो. इस फ़ील्ड का इस्तेमाल, डिवाइस बेचने वाले OEM और/या कैरियर की जानकारी देने के लिए किया जा सकता है. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है. साथ ही, यह वैल्यू रेगुलर एक्सप्रेशन "^[a-zA-Z0-9.,_-]+$" से मैच करनी चाहिए.
android.os.Build.DEVICE डिवाइस लागू करने वाले व्यक्ति या कंपनी की चुनी गई वैल्यू, जो डिवाइस के बॉडी (इसे कभी-कभी "इंडस्ट्रियल डिज़ाइन" भी कहा जाता है) के खास कॉन्फ़िगरेशन या बदलाव की पहचान करती है. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है. साथ ही, यह वैल्यू रेगुलर एक्सप्रेशन "^[a-zA-Z0-9.,_-]+$" से मैच करनी चाहिए.
android.os.Build.FINGERPRINT यह एक स्ट्रिंग है, जो इस बिल्ड की खास तौर पर पहचान करती है. यह पढ़ने में आसान होना चाहिए. यह इस टेंप्लेट के मुताबिक होना चाहिए:
$(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)
उदाहरण के लिए:
acme/mydevice/generic/generic:2.3/ERC77/3359:userdebug/test-keys
फ़िंगरप्रिंट में खाली जगह वाले वर्ण नहीं होने चाहिए. अगर ऊपर दिए गए टेंप्लेट में शामिल अन्य फ़ील्ड में खाली जगह वाले वर्ण हैं, तो उन्हें बिल्ड फ़िंगरप्रिंट में किसी दूसरे वर्ण से बदलना ज़रूरी है. जैसे, अंडरस्कोर ("_") वर्ण. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है.
android.os.Build.HOST यह एक स्ट्रिंग होती है, जो उस होस्ट की खास पहचान करती है जिस पर बिल्ड बनाया गया था. यह स्ट्रिंग, मनुष्य के पढ़ने लायक फ़ॉर्मैट में होती है. इस फ़ील्ड के फ़ॉर्मैट के लिए कोई ज़रूरी शर्त नहीं है. हालांकि, यह शर्त ज़रूरी है कि यह शून्य या खाली स्ट्रिंग ("") न हो.
android.os.Build.ID डिवाइस लागू करने वाला व्यक्ति, किसी रिलीज़ को रेफ़र करने के लिए, यह आइडेंटिफ़ायर चुनता है. यह आइडेंटिफ़ायर, लोगों के पढ़ने लायक फ़ॉर्मैट में होता है. यह फ़ील्ड, android.os.Build.VERSION.INCREMENTAL जैसा हो सकता है. हालांकि, यह ज़रूरी है कि यह वैल्यू, उपयोगकर्ताओं के लिए सॉफ़्टवेयर के बिल्ड के बीच अंतर करने के लिए काम की हो. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है. साथ ही, यह वैल्यू रेगुलर एक्सप्रेशन "^[a-zA-Z0-9.,_-]+$" से मैच करनी चाहिए.
android.os.Build.MODEL डिवाइस लागू करने वाले व्यक्ति की चुनी गई वैल्यू, जिसमें डिवाइस का नाम होता है, जैसा कि असली उपयोगकर्ता को पता होता है. यह वही नाम होना चाहिए जिससे डिवाइस को मार्केट में लाया जाता है और असली उपयोगकर्ताओं को बेचा जाता है. इस फ़ील्ड के फ़ॉर्मैट के लिए कोई ज़रूरी शर्त नहीं है. हालांकि, यह शर्त ज़रूरी है कि यह शून्य या खाली स्ट्रिंग ("") न हो.
android.os.Build.PRODUCT डिवाइस लागू करने वाले व्यक्ति की चुनी गई वैल्यू, जिसमें डिवाइस का डेवलपमेंट नेम या कोड नेम शामिल होता है. यह ऐसा होना चाहिए जिसे कोई भी व्यक्ति पढ़ सके. हालांकि, यह ज़रूरी नहीं है कि इसे असली उपयोगकर्ता देखें. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है. साथ ही, यह वैल्यू रेगुलर एक्सप्रेशन "^[a-zA-Z0-9.,_-]+$" से मैच करनी चाहिए.
android.os.Build.TAGS डिवाइस लागू करने वाले व्यक्ति के चुने गए टैग की सूची, जिन्हें कॉमा लगाकर अलग किया गया है. इससे, बिल्ड को और बेहतर तरीके से अलग किया जा सकता है. उदाहरण के लिए, "unsigned,debug". इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है. साथ ही, यह वैल्यू रेगुलर एक्सप्रेशन "^[a-zA-Z0-9.,_-]+$" से मैच करनी चाहिए.
android.os.Build.TIME यह वैल्यू, बिल्ड होने के समय का टाइमस्टैंप दिखाती है.
android.os.Build.TYPE डिवाइस इंप्लीमेंटर की चुनी गई वैल्यू, जो बिल्ड के रनटाइम कॉन्फ़िगरेशन के बारे में बताती है. इस फ़ील्ड में, Android के तीन सामान्य रनटाइम कॉन्फ़िगरेशन में से किसी एक की वैल्यू होनी चाहिए: "user", "userdebug" या "eng". इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है. साथ ही, यह वैल्यू रेगुलर एक्सप्रेशन "^[a-zA-Z0-9.,_-]+$" से मैच करनी चाहिए.
android.os.Build.USER उस उपयोगकर्ता (या ऑटोमेटेड उपयोगकर्ता) का नाम या यूज़र आईडी जिसने बिल्ड जनरेट किया. इस फ़ील्ड के फ़ॉर्मैट के लिए कोई ज़रूरी शर्त नहीं है. हालांकि, यह ज़रूरी है कि यह शून्य या खाली स्ट्रिंग ("") न हो.

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

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

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

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

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

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

  • डेस्क क्लॉक
  • ब्राउज़र
  • Calendar
  • कैल्कुलेटर
  • संपर्क
  • ईमेल
  • गैलरी में देखें
  • GlobalSearch
  • लॉन्चर
  • संगीत
  • सेटिंग

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 फ़ाइल के तौर पर कंपाइल किया जाता है. नेटिव कोड, प्रोसेसर की बुनियादी टेक्नोलॉजी पर काफ़ी निर्भर होता है. इसलिए, Android, Android NDK में कई ऐप्लिकेशन बाइनरी इंटरफ़ेस (एबीआई) तय करता है. ये इंटरफ़ेस, docs/CPU-ARCH-ABIS.txt फ़ाइल में मौजूद होते हैं. अगर किसी डिवाइस पर, तय किए गए एक या एक से ज़्यादा एबीआई काम करते हैं, तो उसे Android NDK के साथ काम करना चाहिए. इसके लिए, नीचे दिया गया तरीका अपनाएं.

अगर किसी डिवाइस में Android एबीआई के लिए सहायता शामिल है, तो:

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

नेटिव कोड वाले ऐप्लिकेशन के लिए, यहां दिए गए नेटिव कोड एपीआई उपलब्ध होने चाहिए:

  • libc (C लाइब्रेरी)
  • libm (मैथ लाइब्रेरी)
  • C++ के लिए कम से कम सहायता
  • JNI इंटरफ़ेस
  • liblog (Android लॉगिंग)
  • libz (Zlib कंप्रेशन)
  • libdl (डाइनैमिक लिंकर)
  • libGLESv1_CM.so (OpenGL ES 1.0)
  • libGLESv2.so (OpenGL ES 2.0)
  • libEGL.so (नेटिव OpenGL सरफ़ेस मैनेजमेंट)
  • libjnigraphics.so
  • libOpenSLES.so (Open Sound Library ऑडियो सपोर्ट)
  • libandroid.so (नेटिव Android गतिविधि के लिए सहायता)
  • OpenGL के लिए सहायता, जैसा कि नीचे बताया गया है

ध्यान दें कि 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.3 के लिए, अपस्ट्रीम Android Open Source ट्री से 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 से जुड़े इन सभी एपीआई का इस्तेमाल किया जा सकता है:

इसके अलावा, डिवाइस में लागू किए गए वर्शन में, HTML5/W3C वेबस्टोरेज एपीआई [संसाधन, 13] के साथ-साथ, HTML5/W3C IndexedDB API [संसाधन, 14] का इस्तेमाल किया जाना चाहिए. ध्यान दें कि वेब डेवलपमेंट स्टैंडर्ड से जुड़ी संस्थाएं, वेबस्टोरेज के बजाय IndexedDB का इस्तेमाल करना शुरू कर रही हैं. इसलिए, आने वाले समय में Android के नए वर्शन में IndexedDB का इस्तेमाल करना ज़रूरी हो सकता है.

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

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

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

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

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

इसके अलावा, डिवाइस में लागू किए गए वर्शन में, HTML5/W3C वेबस्टोरेज एपीआई [संसाधन, 13] के साथ-साथ, HTML5/W3C IndexedDB API [संसाधन, 14] का इस्तेमाल किया जाना चाहिए. ध्यान दें कि वेब डेवलपमेंट स्टैंडर्ड से जुड़ी संस्थाएं, वेबस्टोरेज के बजाय IndexedDB का इस्तेमाल करना शुरू कर रही हैं. इसलिए, आने वाले समय में Android के नए वर्शन में IndexedDB का इस्तेमाल करना ज़रूरी हो सकता है.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.1. विजेट

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

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

3.8.2. सूचनाएं

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

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

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

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

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

3.8.4. टोस्ट

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.1.1. मीडिया डीकोडर

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

ऑडियो
नाम जानकारी फ़ाइल/कंटेनर फ़ॉर्मैट
AAC LC/LTP स्टैंडर्ड बिटरेट के किसी भी कॉम्बिनेशन में मोनो/स्टीरियो कॉन्टेंट, जो 160 केबीपीएस तक हो और सैंपलिंग रेट 8 से 48 किलोहर्ट्ज़ के बीच हो 3GPP (.3gp) और MPEG-4 (.mp4, .m4a). रॉ AAC (.aac) का इस्तेमाल नहीं किया जा सकता
HE-AACv1 (AAC+)
HE-AACv2 (बेहतर AAC+)
AMR-NB 8 केएचज़ पर सैंपल किए गए 4.75 से 12.2 केबीपीएस 3GPP (.3gp)
AMR-WB 16 किलोहर्ट्ज़ पर सैंपल किए गए 6.60 केबीपीएस से 23.85 केबीपीएस तक के नौ रेट 3GPP (.3gp)
MP3 मोनो/स्टीरियो 8-320 केबीपीएस कॉन्स्टेंट (सीबीआर) या वैरिएबल बिटरेट (वीबीआर) MP3 (.mp3)
MIDI एमआईडीआई टाइप 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   Ogg (.ogg)
पीसीएम 8- और 16-बिट लीनियर PCM (हार्डवेयर की सीमा तक रेट) WAVE (.wav)
इमेज
JPEG base+progressive  
GIF    
PNG    
BMP    
वीडियो
H.263   3GPP (.3gp) फ़ाइलें
H.264   3GPP (.3gp) और MPEG-4 (.mp4) फ़ाइलें
MPEG4 सिंपल प्रोफ़ाइल   3GPP (.3gp) फ़ाइल

5.1.2. मीडिया एन्कोडर

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

डिवाइस में लागू करने के दौरान, हार्डवेयर को छोड़े जाने की शर्तों के बारे में जानने के लिए, सेक्शन 7 देखें.

ऑडियो
नाम जानकारी फ़ाइल/कंटेनर फ़ॉर्मैट शर्तें
AMR-NB 8 केएचज़ पर सैंपल किए गए 4.75 से 12.2 केबीपीएस 3GPP (.3gp) डिवाइस में माइक्रोफ़ोन हार्डवेयर शामिल करने और android.hardware.microphone तय करने पर, इन ऑडियो फ़ॉर्मैट के लिए एन्कोडर ज़रूर शामिल होने चाहिए.
AMR-WB 16 किलोहर्ट्ज़ पर सैंपल किए गए 6.60 केबीपीएस से 23.85 केबीपीएस तक के नौ रेट 3GPP (.3gp)
AAC LC/LTP स्टैंडर्ड बिटरेट के किसी भी कॉम्बिनेशन में मोनो/स्टीरियो कॉन्टेंट, जो 160 केबीपीएस तक हो और सैंपलिंग रेट 8 से 48 किलोहर्ट्ज़ के बीच हो 3GPP (.3gp) और MPEG-4 (.mp4, .m4a).
इमेज JPEG base+progressive   सभी डिवाइसों में इन इमेज फ़ॉर्मैट के लिए एन्कोडर शामिल होने चाहिए, क्योंकि Android 2.3 में ऐसे एपीआई शामिल हैं जिनका इस्तेमाल करके ऐप्लिकेशन, प्रोग्राम के हिसाब से इस तरह की फ़ाइलें जनरेट कर सकते हैं.
PNG    
वीडियो H.263   3GPP (.3gp) फ़ाइलें डिवाइस में कैमरा हार्डवेयर शामिल होने और android.hardware.camera या android.hardware.camera.front में से किसी एक को तय करने पर, इन वीडियो फ़ॉर्मैट के लिए एन्कोडर ज़रूर शामिल होने चाहिए.

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

5.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.3 के लिए "इसका होना ज़रूरी है" के तौर पर बताया गया है. हालांकि, आने वाले वर्शन के लिए, इन शर्तों को "इसका होना ज़रूरी है" के तौर पर बदला जाएगा. इसका मतलब है कि Android 2.3 में ये ज़रूरी शर्तें लागू नहीं होतीं. हालांकि, आने वाले वर्शन में इन शर्तों को लागू करना ज़रूरी होगा. Android 2.3 पर काम करने वाले मौजूदा और नए डिवाइसों को Android 2.3 में इन ज़रूरी शर्तों को पूरा करने का सुझाव दिया जाता है. ऐसा न करने पर, आने वाले समय में डिवाइसों को Android के नए वर्शन पर अपग्रेड नहीं किया जा सकेगा.

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

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

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

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

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

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

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

अगर किसी डिवाइस में इस सेक्शन की ज़रूरी शर्तें पूरी की जाती हैं, तो हो सकता है कि वह डिवाइस, android.content.pm.PackageManager क्लास के ज़रिए "android.hardware.audio.low-latency" सुविधा की रिपोर्ट करके, कम इंतज़ार वाले ऑडियो के लिए सहायता की जानकारी दे. [संसाधन, 27] इसके उलट, अगर डिवाइस में लागू किए गए तरीके से इन ज़रूरी शर्तों को पूरा नहीं किया जाता है, तो डिवाइस को कम इंतज़ार वाले ऑडियो के साथ काम करने की जानकारी नहीं देनी चाहिए.

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

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

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

ज़्यादातर Linux-आधारित सिस्टम और Apple Macintosh सिस्टम, Android SDK टूल का इस्तेमाल करके Android डिवाइसों को पहचानते हैं. इसके लिए, उन्हें किसी और सहायता की ज़रूरत नहीं होती. हालांकि, आम तौर पर Microsoft Windows सिस्टम को नए Android डिवाइसों के लिए ड्राइवर की ज़रूरत होती है. उदाहरण के लिए, नए वेंडर आईडी और कभी-कभी नए डिवाइस आईडी के लिए, Windows सिस्टम के लिए कस्टम यूएसबी ड्राइवर की ज़रूरत होती है. अगर किसी डिवाइस को लागू करने के लिए, स्टैंडर्ड Android SDK में दिए गए adb टूल का इस्तेमाल नहीं किया जा सकता, तो डिवाइस लागू करने वाले लोगों को Windows ड्राइवर उपलब्ध कराने होंगे. इससे डेवलपर, adb प्रोटोकॉल का इस्तेमाल करके डिवाइस से कनेक्ट कर पाएंगे. ये ड्राइवर, Windows XP, Windows Vista, और Windows 7 के लिए 32-बिट और 64-बिट, दोनों वर्शन में उपलब्ध होने चाहिए.

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

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

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

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

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

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

7.1. डिसप्ले और ग्राफ़िक

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

7.1.1. स्क्रीन कॉन्फ़िगरेशन

डिवाइस पर लागू करने के लिए, किसी भी पिक्सल डाइमेंशन की स्क्रीन का इस्तेमाल किया जा सकता है. हालांकि, इसके लिए ज़रूरी है कि वे इन ज़रूरी शर्तों को पूरा करती हों:

  • स्क्रीन का डायगनल साइज़ कम से कम 2.5 इंच होना चाहिए
  • डेंसिटी कम से कम 100 डीपीआई होनी चाहिए
  • आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) 1.333 (4:3) और 1.779 (16:9) के बीच होना चाहिए
  • डिसप्ले टेक्नोलॉजी में स्क्वेयर पिक्सल का इस्तेमाल किया गया हो

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

ऊपर दी गई ज़रूरी शर्तों में इस्तेमाल की गई इकाइयों के बारे में यहां बताया गया है:

  • "डायगनल साइज़", डिसप्ले के रोशन हिस्से के दो विपरीत कोनों के बीच की इंच में दूरी होती है.
  • "डीपीआई" (जिसका मतलब "डॉट प्रति इंच" है) वह पिक्सल की संख्या होती है जो 1" के लीनियर हॉरिज़ॉन्टल या वर्टिकल स्पैन में शामिल होती है. अगर डीपीआई की वैल्यू दी गई हैं, तो हॉरिज़ॉन्टल और वर्टिकल डीपीआई, दोनों की वैल्यू इस रेंज में होनी चाहिए.
  • "आस्पेक्ट रेशियो", स्क्रीन के लंबे डाइमेंशन और छोटे डाइमेंशन के बीच का अनुपात होता है. उदाहरण के लिए, 480x854 पिक्सल के डिसप्ले का आस-पास का आसपेक्ट रेशियो 854 / 480 = 1.779 या "16:9" होगा.

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

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

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

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

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

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

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

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

7.1.5. 3D ग्राफ़िक्स एक्सेलरेशन

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

लागू करने के दौरान, Open GL ES 2.0 के साथ काम करने की सुविधा को छोड़ा जा सकता है. हालांकि, अगर इस सुविधा को छोड़ा जाता है, तो डिवाइस के लागू होने की रिपोर्ट में यह नहीं बताया जाना चाहिए कि वह OpenGL ES 2.0 के साथ काम करता है. खास तौर पर, अगर किसी डिवाइस पर OpenGL ES 2.0 काम नहीं करता है, तो:

  • मैनेज किए जा रहे एपीआई (जैसे, GLES10.getString() तरीके से) को, OpenGL ES 2.0 के साथ काम करने की जानकारी नहीं देनी चाहिए
  • नेटिव C/C++ OpenGL API (यानी, वे जो ऐप्लिकेशन के लिए libGLES_v1CM.so, libGLES_v2.so या libEGL.so के ज़रिए उपलब्ध हैं) को, OpenGL ES 2.0 के साथ काम करने की जानकारी नहीं देनी चाहिए.

इसके उलट, अगर किसी डिवाइस पर OpenGL ES 2.0 काम करता है, तो उसे ऊपर दिए गए रास्तों के ज़रिए इसकी सटीक जानकारी देनी होगी.

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

7.2. इनपुट डिवाइस

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

7.2.1. कीबोर्ड

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

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

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

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

  • टच न करने वाले नेविगेशन विकल्प को शामिल न किया जा सकता (यानी, ट्रैकबॉल, डी-पैड या व्हील को शामिल न किया जा सकता)
  • android.content.res.Configuration.navigation [संसाधन, 30] के लिए सही वैल्यू सबमिट करना ज़रूरी है
  • टेक्स्ट चुनने और उसमें बदलाव करने के लिए, यूज़र इंटरफ़ेस का ऐसा विकल्प देना चाहिए जो इनपुट मैनेजमेंट इंजन के साथ काम करता हो. अपस्ट्रीम Android ओपन-सोर्स कोड में, चुनने का एक तरीका शामिल है. यह उन डिवाइसों के साथ इस्तेमाल करने के लिए सही है जिनमें नॉन-टच नेविगेशन इनपुट नहीं होते.

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

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

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

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

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

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

7.3. सेंसर

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

  • android.content.pm.PackageManager क्लास के हिसाब से, सेंसर की मौजूदगी या अनुपस्थिति की सटीक जानकारी देनी चाहिए. [संसाधन, 27]
  • SensorManager.getSensorList() और इससे मिलते-जुलते तरीकों की मदद से, काम करने वाले सेंसर की सटीक सूची दिखाना ज़रूरी है
  • यह ज़रूरी है कि यह अन्य सभी सेंसर एपीआई के लिए सही तरीके से काम करे. उदाहरण के लिए, जब ऐप्लिकेशन, listener को रजिस्टर करने की कोशिश करते हैं, तो सही या गलत के तौर पर वैल्यू दिखाना. साथ ही, जब संबंधित सेंसर मौजूद न हों, तो सेंसर listener को कॉल न करना वगैरह.

ऊपर दी गई सूची में सभी SDK टूल शामिल नहीं हैं. Android SDK टूल के व्यवहार के बारे में दस्तावेज़ में दी गई जानकारी को आधिकारिक माना जाएगा.

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

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

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

डिवाइस में 3-ऐक्सिस एक्सलरोमीटर होना चाहिए. अगर किसी डिवाइस में 3-ऐक्सिस एक्सलरोमीटर शामिल है, तो:

  • इवेंट को 50 हर्ट्ज़ या इससे ज़्यादा फ़्रीक्वेंसी पर डिलीवर करना चाहिए
  • Android एपीआई में बताए गए तरीके के मुताबिक, Android सेंसर कोऑर्डिनेट सिस्टम का पालन करना ज़रूरी है ([संसाधन, 31] देखें)
  • यह ज़रूरी है कि यह किसी भी तीन-आयामी वेक्टर पर, गुरुत्वाकर्षण के दोगुने (2g) या उससे ज़्यादा तक के फ़्रीफ़ॉल को मेज़र कर सके
  • सटीक जानकारी देने के लिए, 8 बिट या उससे ज़्यादा की ज़रूरत होती है
  • स्टैंडर्ड डेविएशन 0.05 m/s^2 से ज़्यादा नहीं होना चाहिए

7.3.2. मैग्नेटोमीटर

डिवाइस में लागू करने के लिए, 3-ऐक्सिस वाला मैग्नेटोमीटर (यानी कंपास) होना चाहिए. अगर किसी डिवाइस में तीन ऐक्सिस वाला मैग्नेटोमीटर है, तो:

  • 10 हर्ट्ज़ या इससे ज़्यादा फ़्रीक्वेंसी पर इवेंट डिलीवर करने की ज़रूरी शर्त
  • Android एपीआई में बताए गए तरीके के मुताबिक, Android सेंसर कोऑर्डिनेट सिस्टम का पालन करना ज़रूरी है ([संसाधन, 31] देखें).
  • यह ज़रूरी है कि यह भू-चुंबकीय क्षेत्र को कवर करने के लिए, फ़ील्ड की ज़रूरत के मुताबिक रेंज में सैंपलिंग कर सके
  • सटीक जानकारी देने के लिए, 8 बिट या उससे ज़्यादा की ज़रूरत होती है
  • स्टैंडर्ड डेविएशन 0.5 µT से ज़्यादा नहीं होना चाहिए

7.3.3. जीपीएस

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

7.3.4. जाइरोस्कोप

डिवाइस में लागू करने के लिए, इसमें एक जियोस्कोप (यानी ऐंगल में बदलाव का सेंसर) होना चाहिए. डिवाइसों में जाइरोस्कोप सेंसर तब तक शामिल नहीं किया जाना चाहिए, जब तक कि तीन ऐक्सिस वाला एक्सलरोमीटर भी शामिल न हो. अगर किसी डिवाइस में घुमाव-गति सेंसर (जाइरोस्कोप) शामिल है, तो:

  • यह 5.5*पाई रेडियन/सेकंड (यानी, हर सेकंड करीब 1,000 डिग्री) तक ऑरिएंटेशन में होने वाले बदलावों को मेज़र कर सकता हो
  • 100 हर्ट्ज़ या उससे ज़्यादा पर इवेंट डिलीवर करने की ज़रूरी शर्त
  • सटीक जानकारी देने के लिए, 8 बिट या उससे ज़्यादा की ज़रूरत होती है

7.3.5. बैरोमीटर

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

  • इवेंट को 5 हर्ट्ज़ या इससे ज़्यादा फ़्रीक्वेंसी पर डिलीवर करना चाहिए
  • ऊंचाई का अनुमान लगाने के लिए, सटीक डेटा होना ज़रूरी है

7.3.7. Thermometer

डिवाइस में थर्मामीटर (यानी तापमान सेंसर) शामिल किया जा सकता है. हालांकि, ऐसा नहीं करना चाहिए. अगर डिवाइस में थर्मामीटर शामिल है, तो डिवाइस के सीपीयू का तापमान मापा जाना चाहिए. यह किसी और तरह का तापमान नहीं मापना चाहिए. (ध्यान दें कि Android 2.3 के एपीआई में, इस तरह के सेंसर का इस्तेमाल नहीं किया जा सकता.)

7.3.7. फ़ोटोमीटर

डिवाइस में लागू करने के लिए, फ़ोटोमीटर (जैसे, आस-पास की रोशनी का सेंसर) शामिल किया जा सकता है.

7.3.8. निकटता सेंसर

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

7.4. डेटा कनेक्टिविटी

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

7.4.1. टेलीफ़ोनी

"टेलीफ़ोन", जिसका इस्तेमाल Android 2.3 एपीआई करते हैं. इस दस्तावेज़ में, खास तौर पर जीएसएम या सीडीएमए नेटवर्क के ज़रिए वॉइस कॉल करने और एसएमएस भेजने से जुड़े हार्डवेयर के बारे में बताया गया है. ये वॉइस कॉल, पैकेट-स्विच किए जा सकते हैं या नहीं, लेकिन Android 2.3 के लिए इन्हें किसी भी डेटा कनेक्टिविटी से अलग माना जाता है. डेटा कनेक्टिविटी को उसी नेटवर्क का इस्तेमाल करके लागू किया जा सकता है. दूसरे शब्दों में, Android "टेलीफ़ोन" की सुविधा और एपीआई, खास तौर पर वॉइस कॉल और एसएमएस के बारे में बताते हैं. उदाहरण के लिए, जिन डिवाइसों पर कॉल नहीं किए जा सकते या एसएमएस नहीं भेजे/पाए जा सकते उन्हें "android.hardware.telephony" सुविधा या किसी भी सब-सुविधा की जानकारी नहीं देनी चाहिए. भले ही, वे डेटा कनेक्टिविटी के लिए मोबाइल नेटवर्क का इस्तेमाल करते हों.

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

7.4.2. आईईईई 802.11 (वाई-फ़ाई)

Android 2.3 वाले डिवाइसों में, 802.11 (b/g/a/n वगैरह) के एक या एक से ज़्यादा फ़ॉर्म के लिए सहायता शामिल होनी चाहिए अगर किसी डिवाइस में 802.11 के लिए सहायता शामिल है, तो उसमें संबंधित Android API को लागू करना ज़रूरी है.

7.4.3. ब्लूटूथ

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

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

7.4.4. नियर फ़ील्ड कम्यूनिकेशन

डिवाइस में नियर फ़ील्ड कम्यूनिकेशन (एनएफ़सी) के लिए, ट्रांसीवर और उससे जुड़ा हार्डवेयर शामिल होना चाहिए. अगर किसी डिवाइस में एनएफ़सी हार्डवेयर शामिल है, तो:

  • android.content.pm.PackageManager.hasSystemFeature() तरीके से android.hardware.nfc सुविधा की जानकारी देना ज़रूरी है. [संसाधन, 27]
  • यह ज़रूरी है कि डिवाइस, इन एनएफ़सी स्टैंडर्ड के ज़रिए एनडीएफ़ मैसेज पढ़ और लिख सके:
    • यह एनएफ़सी फ़ोरम के रीडर/राइटर्स के तौर पर काम कर सकता हो (जैसा कि एनएफ़सी फ़ोरम के तकनीकी स्पेसिफ़िकेशन के मुताबिक, एनएफ़सी फ़ोरम-टीएस-डिजिटल प्रोटोकॉल-1.0 में बताया गया है). इसके लिए, यह एनएफ़सी के इन स्टैंडर्ड का पालन करता हो:
      • NfcA (ISO14443-3A)
      • NfcB (ISO14443-3B)
      • NfcF (JIS 6319-4)
      • NfcV (ISO 15693)
      • IsoDep (ISO 14443-4)
      • एनएफ़सी फ़ोरम टैग टाइप 1, 2, 3, 4 (एनएफ़सी फ़ोरम के मुताबिक)
    • यह ज़रूरी है कि यह ऐप्लिकेशन, नीचे दिए गए पीयर-टू-पीयर स्टैंडर्ड और प्रोटोकॉल के ज़रिए डेटा भेज और पा सके:
      • ISO 18092
      • LLCP 1.0 (NFC फ़ोरम ने तय किया है)
      • SDP 1.0 (एनएफ़सी फ़ोरम ने तय किया है)
      • एनडीएफ़ई पुश प्रोटोकॉल [संसाधन, 33]
    • एनएफ़सी डिस्कवरी मोड में, काम करने वाली सभी टेक्नोलॉजी के लिए स्कैन करना ज़रूरी है.
    • डिवाइस के चालू होने और स्क्रीन चालू होने पर, डिवाइस को एनएफ़सी डिस्कवरी मोड में होना चाहिए.

    ध्यान दें कि ऊपर बताए गए JIS, ISO, और एनएफ़सी फ़ोरम के स्पेसिफ़िकेशन के लिए, सार्वजनिक तौर पर उपलब्ध लिंक उपलब्ध नहीं हैं.

    इसके अलावा, डिवाइस में इनका इस्तेमाल किया जाना चाहिए, जो MIFARE की आम तौर पर इस्तेमाल की जाने वाली टेक्नोलॉजी हैं.

    ध्यान दें कि Android 2.3.3 में, इन MIFARE टाइप के लिए एपीआई शामिल हैं. अगर किसी डिवाइस पर MIFARE का इस्तेमाल किया जा सकता है, तो:

    • Android SDK टूल में बताए गए तरीके के मुताबिक, उनसे जुड़े Android एपीआई लागू करना ज़रूरी है
    • android.content.pm.PackageManager.hasSystemFeature() तरीके से, com.nxp.mifare सुविधा की शिकायत करना ज़रूरी है. [संसाधन, 27] ध्यान दें कि यह Android की स्टैंडर्ड सुविधा नहीं है. इसलिए, यह PackageManager क्लास में एक कॉन्स्टेंट के तौर पर नहीं दिखती.
    • इसके लिए, संबंधित Android API लागू नहीं करने चाहिए और न ही com.nxp.mifare सुविधा की जानकारी देनी चाहिए. ऐसा तब तक नहीं किया जाना चाहिए, जब तक कि इस सेक्शन में बताए गए तरीके से सामान्य एनएफ़सी की सुविधा भी लागू न की गई हो

    अगर किसी डिवाइस में एनएफ़सी हार्डवेयर शामिल नहीं है, तो उसे android.content.pm.PackageManager.hasSystemFeature() तरीके [संसाधन, 27] से android.hardware.nfc सुविधा का एलान नहीं करना चाहिए. साथ ही, उसे Android 2.3 एनएफ़सी एपीआई को बिना किसी काम के लागू करना चाहिए.

    android.nfc.NdefMessage और android.nfc.NdefRecord क्लास, प्रोटोकॉल से स्वतंत्र डेटा के प्रतिनिधित्व के फ़ॉर्मैट को दिखाती हैं. इसलिए, डिवाइस में इन एपीआई को लागू करना ज़रूरी है. भले ही, इनमें एनएफ़सी के लिए सहायता शामिल न हो या android.hardware.nfc की सुविधा का एलान न किया गया हो.

    7.4.5. नेटवर्क की कम से कम क्षमता

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

    जिन डिवाइसों में फ़िज़िकल नेटवर्किंग स्टैंडर्ड (जैसे कि ईथरनेट) मुख्य डेटा कनेक्शन है उनमें कम से कम एक सामान्य वायरलेस डेटा स्टैंडर्ड (जैसे कि 802.11 (वाई-फ़ाई)) के लिए भी सहायता शामिल होनी चाहिए.

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

    7.5. कैमरे

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

    7.5.1. पीछे वाला कैमरा

    डिवाइस में पीछे वाला कैमरा होना चाहिए. अगर किसी डिवाइस में पीछे वाला कैमरा है, तो:

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

    7.5.2. सामने वाला कैमरा

    डिवाइस में फ़्रंट कैमरा भी शामिल हो सकता है. अगर किसी डिवाइस में, सामने वाला कैमरा शामिल है, तो:

    • इसका रिज़ॉल्यूशन कम से कम VGA (यानी, 640x480 पिक्सल) होना चाहिए
    • Camera API के लिए, सामने वाले कैमरे का इस्तेमाल डिफ़ॉल्ट तौर पर नहीं किया जाना चाहिए. इसका मतलब है कि Android 2.3 में मौजूद कैमरा एपीआई, सिर्फ़ सामने वाले कैमरे के साथ काम करता है. साथ ही, डिवाइस में एपीआई को इस तरह कॉन्फ़िगर नहीं किया जाना चाहिए कि वह सामने वाले कैमरे को डिफ़ॉल्ट पीछे वाले कैमरे के तौर पर इस्तेमाल करे. भले ही, डिवाइस में सिर्फ़ यही कैमरा हो.
    • इसमें सेक्शन 7.5.1 में बताई गई, पीछे की ओर फ़ोकस करने वाले कैमरों के लिए उपलब्ध सुविधाएं (जैसे, ऑटो-फ़ोकस, फ़्लैश वगैरह) शामिल हो सकती हैं.
    • CameraPreview में, ऐप्लिकेशन की स्ट्रीम को हॉरिज़ॉन्टल तौर पर दिखाना ज़रूरी है. इसका तरीका यहां बताया गया है:
      • अगर डिवाइस को उपयोगकर्ता घुमा सकता है (जैसे कि ऐक्सीलेरोमीटर की मदद से अपने-आप या उपयोगकर्ता के इनपुट से मैन्युअल तरीके से), तो कैमरे की झलक को डिवाइस के मौजूदा ओरिएंटेशन के हिसाब से हॉरिज़ॉन्टल तौर पर दिखाना ज़रूरी है.
      • अगर मौजूदा ऐप्लिकेशन ने साफ़ तौर पर अनुरोध किया है कि android.hardware.Camera.setDisplayOrientation() [संसाधन, 40] तरीके को कॉल करके, कैमरे के डिसप्ले को घुमाया जाए, तो ऐप्लिकेशन के तय किए गए ओरिएंटेशन के हिसाब से, कैमरे की झलक को हॉरिज़ॉन्टल तौर पर दिखाना ज़रूरी है.
      • अगर ऐसा नहीं है, तो झलक को डिवाइस के डिफ़ॉल्ट हॉरिज़ॉन्टल ऐक्सिस के साथ मिरर किया जाना चाहिए.
    • कैमरे की झलक वाली इमेज स्ट्रीम की तरह ही, किसी भी "पोस्टव्यू" कैमरा कॉलबैक हैंडलर को दिखाए गए इमेज डेटा को भी दिखाना चाहिए. (अगर डिवाइस पर लागू किए गए तरीके में, पोस्टव्यू कॉलबैक की सुविधा काम नहीं करती है, तो यह ज़रूरी शर्त लागू नहीं होगी.)
    • कैप्चर की गई फ़ाइनल इमेज या वीडियो स्ट्रीम को ऐप्लिकेशन कॉलबैक में वापस नहीं भेजना चाहिए या मीडिया स्टोरेज में सेव नहीं करना चाहिए

    7.5.3. Camera API का व्यवहार

    डिवाइस में कैमरे से जुड़े एपीआई को लागू करते समय, सामने और पीछे के कैमरे, दोनों के लिए ये काम करने चाहिए:

    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 एन्कोडिंग फ़ॉर्मैट में होना चाहिए. इसका मतलब है कि NV21, डिफ़ॉल्ट तौर पर होना चाहिए.
    3. डिवाइस में कैमरे की झलक दिखाने के लिए, YV12 फ़ॉर्मैट का इस्तेमाल किया जाना चाहिए. यह फ़ॉर्मैट, android.graphics.ImageFormat.YV12 कॉन्स्टेंट से दिखाया गया है. यह फ़ॉर्मैट, सामने और पीछे के कैमरे, दोनों के लिए इस्तेमाल किया जाना चाहिए. ध्यान दें कि आने वाले वर्शन के लिए, 'काम करने के तरीके की परिभाषा' में इस ज़रूरी शर्त को "ज़रूरी है" में बदलने का प्लान है. इसका मतलब है कि Android 2.3 में YV12 का इस्तेमाल करना ज़रूरी नहीं है. हालांकि, आने वाले वर्शन में इसकी ज़रूरत होगी. Android 2.3 पर काम करने वाले मौजूदा और नए डिवाइसों को Android 2.3 में इस ज़रूरी शर्त को पूरा करने का सुझाव दिया जाता है. ऐसा न करने पर, आने वाले समय में डिवाइसों को Android के नए वर्शन पर अपग्रेड नहीं किया जा सकेगा.

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

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

    7.5.4. कैमरे का ओरिएंटेशन

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    7.7. यूएसबी

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

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

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

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

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

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

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

    9.1. अनुमतियां

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    10. सॉफ़्टवेयर की कंपैटबिलिटी टेस्टिंग

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

    हालांकि, ध्यान रखें कि कोई भी सॉफ़्टवेयर टेस्ट पैकेज पूरी तरह से काम का नहीं होता. इसलिए, डिवाइस में Android 2.3 को लागू करने वाले लोगों को हमारा सुझाव है कि वे Android Open-Source Project से मिले रेफ़रंस और Android 2.3 के लागू करने के सुझाए गए तरीके में कम से कम बदलाव करें. इससे, गड़बड़ियों की संभावना कम हो जाएगी. इन गड़बड़ियों की वजह से, डिवाइस के साथ काम करने में समस्याएं आ सकती हैं. इन गड़बड़ियों को ठीक करने के लिए, आपको फिर से काम करना पड़ सकता है. साथ ही, डिवाइस के लिए अपडेट भी करना पड़ सकता है.

    10.1. Compatibility Test Suite

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

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

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

    10.2. सीटीएस की पुष्टि करने वाला टूल

    डिवाइस लागू करने के लिए, ज़रूरी है कि सीटीएस की पुष्टि करने वाले टूल में, लागू होने वाले सभी उदाहरणों को सही तरीके से लागू किया जाए. CTS Verifier, Compatibility Test Suite में शामिल होता है. इसे किसी ऑपरेटर के ज़रिए चलाया जाता है, ताकि उन फ़ंक्शन की जांच की जा सके जिनकी जांच ऑटोमेटेड सिस्टम से नहीं की जा सकती. जैसे, कैमरे और सेंसर की सही तरीके से काम करना.

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

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

    10.3. रेफ़रंस ऐप्लिकेशन

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

    • "Android के लिए ऐप्लिकेशन" ऐप्लिकेशन [संसाधन, 43].
    • Replica Island (Android Market में उपलब्ध है; सिर्फ़ उन डिवाइसों के लिए ज़रूरी है जिन पर OpenGL ES 2.0 काम करता है)

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

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

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

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

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

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

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

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

    अगर आपको इस बारे में ज़्यादा जानकारी चाहिए या आपको लगता है कि दस्तावेज़ में किसी समस्या के बारे में नहीं बताया गया है, तो 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 और स्टैक सही तरीके से काम करता है या नहीं. हर टेस्ट सीक्वेंस को बताए गए तरीके से ही पूरा करना ज़रूरी है.