Android 4.0 के साथ काम करने की जानकारी देने वाला दस्तावेज़

चौथा बदलाव
पिछले अपडेट की तारीख: 21 अप्रैल, 2013

कॉपीराइट © 2012, 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. यूज़र इंटरफ़ेस के साथ काम करना
3.9 डिवाइस मैनेजमेंट
3.10 सुलभता सेटिंग
3.11 लिखे गए शब्दों को सुनने की सुविधा
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 4.0 के साथ काम करने लायक बनाया जा सकता है.

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

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

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

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

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

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 4.0 के साथ काम करने वाली वर्शन स्ट्रिंग: http://source.android.com/docs/compatibility/4.0/versions.html
  8. Renderscript: http://developer.android.com/guide/topics/graphics/renderscript.html
  9. हार्डवेयर की मदद से वीडियो की रफ़्तार बढ़ाने की सुविधा: http://developer.android.com/guide/topics/graphics/hardware-accel.html
  10. android.webkit.WebView क्लास: http://developer.android.com/reference/android/webkit/WebView.html
  11. HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/
  12. HTML5 की ऑफ़लाइन सुविधाएं: http://dev.w3.org/html5/spec/Overview.html#offline
  13. HTML5 वीडियो टैग: http://dev.w3.org/html5/spec/Overview.html#video
  14. HTML5/W3C जियोलोकेशन एपीआई: http://www.w3.org/TR/geolocation-API/
  15. HTML5/W3C वेबडेटाबेस एपीआई: http://www.w3.org/TR/webdatabase/
  16. HTML5/W3C IndexedDB API: http://www.w3.org/TR/IndexedDB/
  17. Dalvik वर्चुअल मशीन की खास जानकारी: यह Android के सोर्स कोड में, dalvik/docs पर उपलब्ध है
  18. ऐप्लिकेशन विजेट: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
  19. सूचनाएं: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
  20. ऐप्लिकेशन के लिए संसाधन: http://code.google.com/android/reference/available-resources.html
  21. स्टेटस बार के आइकॉन की स्टाइल गाइड: http://developer.android.com/guide/practices/ui_guideline /icon_design.html#statusbarstructure
  22. Search Manager: http://developer.android.com/reference/android/app/SearchManager.html
  23. टॉस्ट: http://developer.android.com/reference/android/widget/Toast.html
  24. थीम: http://developer.android.com/guide/topics/ui/themes.html
  25. R.style क्लास: http://developer.android.com/reference/android/R.style.html
  26. लाइव वॉलपेपर: https://android-developers.googleblog.com/2010/02/live-wallpapers.html
  27. Android डिवाइस एडमिन: http://developer.android.com/guide/topics/admin/device-admin.html
  28. android.app.admin.DevicePolicyManager क्लास: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html
  29. Android Accessibility Service के एपीआई: http://developer.android.com/reference/android/accessibilityservice/package-summary.html
  30. Android Accessibility API: http://developer.android.com/reference/android/view/accessibility/package-summary.html
  31. Eyes Free प्रोजेक्ट: http://code.google.com/p/eyes-free
  32. टेक्स्ट-टू-स्पीच एपीआई: http://developer.android.com/reference/android/speech/tts/package-summary.html
  33. टूल से जुड़ा रेफ़रंस दस्तावेज़ (adb, aapt, ddms के लिए): http://developer.android.com/guide/developing/tools/index.html
  34. Android APK फ़ाइल के बारे में जानकारी: http://developer.android.com/guide/topics/fundamentals.html
  35. मेनिफ़ेस्ट फ़ाइलें: http://developer.android.com/guide/topics/manifest/manifest-intro.html
  36. Monkey टेस्टिंग टूल: https://developer.android.com/studio/test/other-testing-tools/monkey
  37. Android android.content.pm.PackageManager क्लास और हार्डवेयर की सुविधाओं की सूची: http://developer.android.com/reference/android/content/pm/PackageManager.html
  38. एक से ज़्यादा स्क्रीन के साथ काम करना: http://developer.android.com/guide/practices/screens_support.html
  39. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
  40. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html
  41. android.hardware.SensorEvent: http://developer.android.com/reference/android/hardware/SensorEvent.html
  42. ब्लूटूथ एपीआई: http://developer.android.com/reference/android/bluetooth/package-summary.html
  43. NDEF पुश प्रोटोकॉल: http://source.android.com/docs/compatibility/ndef-push-protocol.pdf
  44. MIFARE MF1S503X: http://www.nxp.com/documents/data_sheet/MF1S503x.pdf
  45. MIFARE MF1S703X: http://www.nxp.com/documents/data_sheet/MF1S703x.pdf
  46. MIFARE MF0ICU1: http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf
  47. MIFARE MF0ICU2: http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf
  48. MIFARE AN130511: http://www.nxp.com/documents/application_note/AN130511.pdf
  49. MIFARE AN130411: http://www.nxp.com/documents/application_note/AN130411.pdf
  50. कैमरे के ओरिएंटेशन का एपीआई: http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)
  51. android.hardware.Camera: http://developer.android.com/reference/android/hardware/Camera.html
  52. Android Open Accessories: http://developer.android.com/guide/topics/usb/accessory.html
  53. यूएसबी होस्ट एपीआई: http://developer.android.com/guide/topics/usb/host.html
  54. Android की सुरक्षा और अनुमतियों के बारे में जानकारी: http://developer.android.com/guide/topics/security/security.html
  55. Android के लिए ऐप्लिकेशन: http://code.google.com/p/apps-for-android
  56. android.app.DownloadManager क्लास: http://developer.android.com/reference/android/app/DownloadManager.html
  57. Android फ़ाइल ट्रांसफ़र: http://www.android.com/filetransfer
  58. Android के मीडिया फ़ॉर्मैट: http://developer.android.com/guide/appendix/media-formats.html
  59. एचटीटीपी लाइव स्ट्रीमिंग ड्राफ़्ट प्रोटोकॉल: http://tools.ietf.org/html/draft-pantos-http-live-streaming-03
  60. Motion Event API: http://developer.android.com/reference/android/view/MotionEvent.html
  61. टच इनपुट कॉन्फ़िगरेशन: http://source.android.com/tech/input/touch-devices.html

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

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

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

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

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

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

3.2. Soft API Compatibility

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

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 4.0.1 - 4.0.2 के लिए, इस फ़ील्ड में पूर्णांक की वैल्यू 14 होनी चाहिए. Android 4.0.3 या इसके बाद के वर्शन के लिए, इस फ़ील्ड में पूर्णांक की वैल्यू 15 होनी चाहिए.
android.os.Build.VERSION.SDK_INT फ़िलहाल चल रहे Android सिस्टम का वर्शन, तीसरे पक्ष के ऐप्लिकेशन कोड के लिए ऐक्सेस किए जा सकने वाले फ़ॉर्मैट में. Android 4.0.1 - 4.0.2 के लिए, इस फ़ील्ड में पूर्णांक की वैल्यू 14 होनी चाहिए. Android 4.0.3 या इसके बाद के वर्शन के लिए, इस फ़ील्ड में पूर्णांक की वैल्यू 15 होनी चाहिए.
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.CPU_ABI नेटिव कोड के निर्देश सेट (सीपीयू टाइप + एबीआई कन्वेंशन) का नाम. सेक्शन 3.3: नेटिव एपीआई के साथ काम करना देखें.
android.os.Build.CPU_ABI2 नेटिव कोड के दूसरे निर्देश सेट (सीपीयू टाइप + एबीआई कन्वेंशन) का नाम. सेक्शन 3.3: नेटिव एपीआई के साथ काम करना देखें.
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:4.0/IRK77/3359:userdebug/test-keys
फ़िंगरप्रिंट में खाली जगह वाले वर्ण नहीं होने चाहिए. अगर ऊपर दिए गए टेंप्लेट में शामिल अन्य फ़ील्ड में खाली जगह वाले वर्ण हैं, तो उन्हें बिल्ड फ़िंगरप्रिंट में किसी दूसरे वर्ण से बदलना ज़रूरी है. जैसे, अंडरस्कोर ("_") वर्ण. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है.
android.os.Build.HARDWARE हार्डवेयर का नाम (कर्नल कमांड लाइन या /proc से). इसे किसी व्यक्ति के लिए आसानी से पढ़ा जा सकने वाला होना चाहिए. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है. साथ ही, यह वैल्यू रेगुलर एक्सप्रेशन "^[a-zA-Z0-9.,_-]+$" से मैच करनी चाहिए.
android.os.Build.HOST यह एक स्ट्रिंग होती है, जो उस होस्ट की खास पहचान करती है जिस पर बिल्ड बनाया गया था. यह स्ट्रिंग, मनुष्य के पढ़ने लायक फ़ॉर्मैट में होती है. इस फ़ील्ड के फ़ॉर्मैट के लिए कोई ज़रूरी शर्त नहीं है. हालांकि, यह शर्त ज़रूरी है कि यह शून्य या खाली स्ट्रिंग ("") न हो.
android.os.Build.ID डिवाइस लागू करने वाला व्यक्ति, किसी रिलीज़ को रेफ़र करने के लिए, यह आइडेंटिफ़ायर चुनता है. यह आइडेंटिफ़ायर, लोगों के पढ़ने लायक फ़ॉर्मैट में होता है. यह फ़ील्ड, android.os.Build.VERSION.INCREMENTAL जैसा हो सकता है. हालांकि, यह ज़रूरी है कि यह वैल्यू, उपयोगकर्ताओं के लिए सॉफ़्टवेयर के बिल्ड के बीच अंतर करने के लिए काम की हो. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है. साथ ही, यह वैल्यू रेगुलर एक्सप्रेशन "^[a-zA-Z0-9.,_-]+$" से मैच करनी चाहिए.
android.os.Build.MANUFACTURER प्रॉडक्ट के ओरिजनल इक्विपमेंट मैन्युफ़ैक्चरर (OEM) का ट्रेड नेम. इस फ़ील्ड के फ़ॉर्मैट के लिए कोई ज़रूरी शर्त नहीं है. हालांकि, यह ज़रूरी है कि यह शून्य या खाली स्ट्रिंग ("") न हो.
android.os.Build.MODEL डिवाइस लागू करने वाले व्यक्ति की चुनी गई वैल्यू, जिसमें डिवाइस का नाम होता है, जैसा कि असली उपयोगकर्ता को पता होता है. यह वही नाम होना चाहिए जिससे डिवाइस को मार्केट में लाया जाता है और असली उपयोगकर्ताओं को बेचा जाता है. इस फ़ील्ड के फ़ॉर्मैट के लिए कोई ज़रूरी शर्त नहीं है. हालांकि, यह शर्त ज़रूरी है कि यह शून्य या खाली स्ट्रिंग ("") न हो.
android.os.Build.PRODUCT डिवाइस लागू करने वाले व्यक्ति की चुनी गई वैल्यू, जिसमें प्रॉडक्ट (SKU) का डेवलपमेंट नेम या कोड नेम शामिल होता है. यह ऐसा होना चाहिए जिसे कोई भी व्यक्ति पढ़ सके. हालांकि, यह ज़रूरी नहीं है कि इसे असली उपयोगकर्ता देखें. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है. साथ ही, यह वैल्यू रेगुलर एक्सप्रेशन "^[a-zA-Z0-9.,_-]+$" से मैच करनी चाहिए.
android.os.Build.SERIAL हार्डवेयर का सीरियल नंबर, अगर उपलब्ध हो. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर कोड किया जा सकता है. साथ ही, यह वैल्यू रेगुलर एक्सप्रेशन "^([a-zA-Z0-9]{0,20})$" से मैच करनी चाहिए.
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.2 में दिए गए हर इंटेंट पैटर्न को तीसरे पक्ष के ऐप्लिकेशन बदल सकें. Android के ओपन सोर्स वर्शन में, डिफ़ॉल्ट रूप से ऐसा करने की अनुमति होती है. डिवाइस पर इसे लागू करने वाले लोगों को, सिस्टम ऐप्लिकेशन के इन इंटेंट पैटर्न के इस्तेमाल के लिए खास अधिकार नहीं देने चाहिए. इसके अलावा, तीसरे पक्ष के ऐप्लिकेशन को इन पैटर्न से बाइंड करने और उनका कंट्रोल लेने से भी नहीं रोकना चाहिए. इस पाबंदी में, "चुने गए" यूज़र इंटरफ़ेस को बंद करना शामिल है. हालांकि, इसमें और भी चीज़ें शामिल हो सकती हैं. इस यूज़र इंटरफ़ेस की मदद से, उपयोगकर्ता एक से ज़्यादा ऐप्लिकेशन में से किसी एक को चुन सकता है. ये सभी ऐप्लिकेशन, एक ही इंटेंट पैटर्न को हैंडल करते हैं.

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

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

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

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

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

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

3.3.1 ऐप्लिकेशन बाइनरी इंटरफ़ेस

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 (OpenSL ES 1.0.1 ऑडियो की सुविधा)
  • libOpenMAXAL.so (OpenMAX AL 1.0.1 के साथ काम करता है)
  • libandroid.so (नेटिव Android गतिविधि के लिए सहायता)
  • OpenGL के लिए सहायता, जैसा कि नीचे बताया गया है

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

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

3.4. वेब के साथ काम करना

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

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

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

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

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

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

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

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

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

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

इसके अलावा, डिवाइस में लागू किए गए एपीआई, HTML5/W3C वेबस्टोरेज एपीआई [संसाधन, 15] के साथ काम करने चाहिए. साथ ही, इनमें HTML5/W3C IndexedDB API [संसाधन, 16] के साथ काम करने की सुविधा होनी चाहिए. ध्यान दें कि वेब डेवलपमेंट स्टैंडर्ड से जुड़ी संस्थाएं, वेबस्टोरेज के बजाय 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 वर्चुअल मशीन के सेमेटिक्स [संसाधन, 17] का इस्तेमाल किया जाना चाहिए.

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

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

स्क्रीन का साइज़ स्क्रीन की डेंसिटी ऐप्लिकेशन मेमोरी
छोटा / सामान्य / बड़ा ldpi / mdpi 16 एमबी
छोटा / सामान्य / बड़ा tvdpi / hdpi 32 एमबी
छोटा / सामान्य / बड़ा xhdpi 64 एमबी
xlarge mdpi 32 एमबी
xlarge tvdpi / hdpi 64 एमबी
xlarge xhdpi 128 एमबी

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

3.8.1. विजेट

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

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

डिवाइस पर लागू होने वाले टूल, स्टैंडर्ड ग्रिड साइज़ में 4 x 4 वाले विजेट को रेंडर कर सकते हों. ज़्यादा जानकारी के लिए, Android SDK टूल के दस्तावेज़ [संसाधन, 18] में ऐप्लिकेशन विजेट के डिज़ाइन से जुड़े दिशा-निर्देश देखें.

3.8.2. सूचनाएं

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

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

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

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

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

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

3.8.4. टोस्ट

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

3.8.5. थीम

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

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

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

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

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

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

3.8.7. हाल ही में इस्तेमाल किए गए ऐप्लिकेशन का डिसप्ले

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

3.8.8. इनपुट मैनेजमेंट सेटिंग

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

3.9 डिवाइस का एडमिन ऐक्सेस

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

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

3.10 सुलभता

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

  • डिवाइस पर, android.accessibilityservice एपीआई [संसाधन, 30] के ज़रिए, तीसरे पक्ष की सुलभता सेवा के लागू होने की सुविधा होनी चाहिए.
  • डिवाइस पर लागू होने वाले टूल को AccessibilityEvent जनरेट करना ज़रूरी है और इन इवेंट को रजिस्टर किए गए सभी AccessibilityService पर डिफ़ॉल्ट Android के मुताबिक डिलीवर करना होगा.
  • डिवाइस में सुलभता सेवाओं को चालू और बंद करने के लिए, उपयोगकर्ता के ऐक्सेस करने लायक तरीका होना चाहिए. साथ ही, android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS के इंटेंट के जवाब में, यह इंटरफ़ेस दिखाना ज़रूरी है.

इसके अलावा, डिवाइस पर सुलभता सेवा को लागू करना ज़रूरी है. साथ ही, डिवाइस के सेटअप के दौरान, उपयोगकर्ताओं को सुलभता सेवा को चालू करने का तरीका भी देना चाहिए. सुलभता सेवा को ओपन सोर्स के तौर पर लागू करने के लिए, EyesFree प्रोजेक्ट [संसाधन, 31] उपलब्ध है.

3.11 लिखाई को बोली में बदलने की सुविधा

Android 4.0 में ऐसे एपीआई शामिल हैं जिनकी मदद से, ऐप्लिकेशन लिखाई को बोली में बदलने की सुविधा (टीटीएस) का इस्तेमाल कर सकते हैं. साथ ही, सेवा देने वाली कंपनियां, टीटीएस सेवाओं को लागू कर सकती हैं [संसाधन, 32]. डिवाइस पर लागू किए गए एआई को Android के टीटीएस फ़्रेमवर्क से जुड़ी इन ज़रूरी शर्तों को पूरा करना होगा:

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

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

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

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

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

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

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

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

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

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

टाइप फ़ॉर्मैट / कोडेक एन्कोडर डिकोडर जानकारी फ़ाइल टाइप / कंटेनर फ़ॉर्मैट
ऑडियो AAC LC/LTP ज़रूरी है
माइक्रोफ़ोन हार्डवेयर वाले डिवाइसों के लागू होने के लिए ज़रूरी है और android.hardware.microphone तय करता है.		 ज़रूरी है स्टैंडर्ड बिटरेट के किसी भी कॉम्बिनेशन में मोनो/स्टीरियो कॉन्टेंट, 160 केबीपीएस तक और सैंपलिंग रेट 8 से 48 केएचज़ तक
  • 3GPP (.3gp)
  • MPEG-4 (.mp4, .m4a)
  • ADTS रॉ AAC (.aac, Android 3.1 और उसके बाद के वर्शन में डिकोड करें, Android 4.0 और उसके बाद के वर्शन में एन्कोड करें, ADIF काम नहीं करता)
  • एमपीईजी-टीएस (.ts, इसमें वीडियो पर आगे-पीछे नहीं जाया जा सकता, Android 3.0 और उसके बाद के वर्शन)
HE-AACv1 (AAC+)   ज़रूरी है
HE-AACv2 (बेहतर AAC+)   ज़रूरी है
AMR-NB ज़रूरी है
माइक्रोफ़ोन हार्डवेयर वाले डिवाइसों के लागू होने के लिए ज़रूरी है और android.hardware.microphone तय करता है.		 ज़रूरी है 8 केएचज़ पर सैंपल किए गए 4.75 से 12.2 केबीपीएस 3GPP (.3gp)
AMR-WB ज़रूरी है
माइक्रोफ़ोन हार्डवेयर वाले डिवाइसों के लागू होने के लिए ज़रूरी है और android.hardware.microphone तय करता है.		 ज़रूरी है 16 किलोहर्ट्ज़ पर सैंपल किए गए 6.60 केबीपीएस से 23.85 केबीपीएस तक के नौ रेट 3GPP (.3gp)
FLAC   ज़रूरी है
(Android 3.1+)		 मोनो/स्टीरियो (मल्टीचैनल नहीं). सैंपल रेट 48 किलोहर्ट्ज़ तक (हालांकि, 44.1 किलोहर्ट्ज़ आउटपुट वाले डिवाइसों पर 44.1 किलोहर्ट्ज़ तक का सुझाव दिया जाता है, क्योंकि 48 से 44.1 किलोहर्ट्ज़ के डाउनसैंपलर में लो-पास फ़िल्टर शामिल नहीं होता). 16-बिट का सुझाव दिया जाता है; 24-बिट के लिए कोई डिटर लागू नहीं किया जाता. सिर्फ़ FLAC (.flac)
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)
  • iMelody (.imy)
Vorbis   ज़रूरी है  
  • Ogg (.ogg)
  • Matroska (.mkv)
PCM/WAVE   ज़रूरी है 8- और 16-बिट लीनियर PCM (हार्डवेयर की सीमा तक रेट) WAVE (.wav)
इमेज JPEG ज़रूरी है ज़रूरी है बेस+प्रोग्रेसिव JPEG (.jpg)
GIF   ज़रूरी है   GIF (.gif)
PNG ज़रूरी है ज़रूरी है   PNG (.png)
BMP   ज़रूरी है   BMP (.bmp)
WebP ज़रूरी है ज़रूरी है   WebP (.webp)
वीडियो H.263 ज़रूरी है
ऐसे डिवाइसों के लिए ज़रूरी है जिनमें कैमरा हार्डवेयर शामिल है और android.hardware.camera या android.hardware.camera.front तय किया गया है.		 ज़रूरी है  
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
H.264 AVC ज़रूरी है
ऐसे डिवाइसों के लिए ज़रूरी है जिनमें कैमरा हार्डवेयर शामिल है और android.hardware.camera या android.hardware.camera.front तय किया गया है.		 ज़रूरी है बेसलाइन प्रोफ़ाइल (बीपी)
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
  • MPEG-TS (.ts, सिर्फ़ AAC ऑडियो, आगे-पीछे नहीं किया जा सकता, Android 3.0 और इसके बाद के वर्शन)
MPEG-4 SP   ज़रूरी है   3GPP (.3gp)
VP8   ज़रूरी है
(Android 2.3.3+)		   WebM (.webm) और Matroska (.mkv, Android 4.0+)

5.2 वीडियो एन्कोडिंग

Android डिवाइस में पीछे की ओर वाला कैमरा होना चाहिए और यह एलान किया गया हो कि android.hardware.camera, वीडियो को एन्कोड करने के लिए इन प्रोफ़ाइलों का इस्तेमाल किया जा सकता है.

  एसडी (कम क्वालिटी) एसडी (अच्छी क्वालिटी) एचडी (जब हार्डवेयर काम करता हो)
वीडियो कोडेक H.264 बेसलाइन प्रोफ़ाइल H.264 बेसलाइन प्रोफ़ाइल H.264 बेसलाइन प्रोफ़ाइल
वीडियो रिज़ॉल्यूशन 176 x 144 पिक्सल 480 x 360 पिक्सल 1280 x 720 पिक्सल
वीडियो फ़्रेम रेट 12 फ़्रेम प्रति सेकंड 30 फ़्रेम प्रति सेकंड 30 फ़्रेम प्रति सेकंड
वीडियो बिटरेट 56 केबीपीएस 500 केबीपीएस या उससे ज़्यादा 2 एमबीपीएस या उससे ज़्यादा
ऑडियो कोडेक AAC-LC AAC-LC AAC-LC
ऑडियो चैनल 1 (मोनो) 2 (स्टीरियो) 2 (स्टीरियो)
ऑडियो बिटरेट 24 केबीपीएस 128 केबीपीएस 192 केबीपीएस

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

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

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

रिकॉर्डिंग से जुड़ी ऊपर दी गई शर्तों के अलावा, जब कोई ऐप्लिकेशन android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION ऑडियो सोर्स का इस्तेमाल करके ऑडियो स्ट्रीम रिकॉर्ड करना शुरू करता है, तो:

  • अगर शोर कम करने की सुविधा मौजूद है, तो उसे बंद करना ज़रूरी है.
  • अगर ऑटोमैटिक गेन कंट्रोल की सुविधा मौजूद है, तो उसे बंद करना ज़रूरी है.

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

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

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

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

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

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

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

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

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

5.5. नेटवर्क प्रोटोकॉल

डिवाइसों में ऑडियो और वीडियो चलाने के लिए, मीडिया नेटवर्क प्रोटोकॉल का इस्तेमाल करना ज़रूरी है. इस बारे में Android SDK टूल के दस्तावेज़ [संसाधन, 58] में बताया गया है. खास तौर पर, डिवाइसों में इन मीडिया नेटवर्क प्रोटोकॉल का इस्तेमाल करना ज़रूरी है:

  • आरटीएसपी (आरटीपी, एसडीपी)
  • एचटीटीपी या एचटीटीपीएस प्रोग्रेसिव स्ट्रीमिंग
  • एचटीटीपी या एचटीटीपीएस लाइव स्ट्रीमिंग ड्राफ़्ट प्रोटोकॉल, वर्शन 3 [संसाधन, 59]

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

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

  • Android डीबग ब्रिज (जिसे adb कहा जाता है) [संसाधन, 33]
    डिवाइस पर लागू किए गए टूल, Android SDK में बताए गए सभी adb फ़ंक्शन के साथ काम करने चाहिए. डिवाइस-साइड adb डेमन को डिफ़ॉल्ट रूप से बंद होना चाहिए. साथ ही, Android Debug Bridge को चालू करने के लिए, उपयोगकर्ता के पास कोई ऐसा तरीका होना चाहिए जिसका इस्तेमाल किया जा सके.
  • Dalvik Debug Monitor Service (इसे ddms कहा जाता है) [संसाधन, 33]
    डिवाइस में लागू किए गए सिस्टम में, Android SDK में बताई गई सभी ddms सुविधाएं काम करनी चाहिए. ddms, adb का इस्तेमाल करता है. इसलिए, ddms के लिए सहायता डिफ़ॉल्ट रूप से बंद होनी चाहिए. हालांकि, जब भी उपयोगकर्ता ने ऊपर बताए गए तरीके से Android Debug Bridge चालू किया हो, तब यह सहायता चालू होनी चाहिए.
  • Monkey [संसाधन, 36]
    डिवाइस पर लागू करने के लिए, 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 SDK टूल के दस्तावेज़ में बताया गया है. अगर SDK टूल में मौजूद कोई एपीआई, ऐसे हार्डवेयर कॉम्पोनेंट के साथ इंटरैक्ट करता है जिसे ज़रूरी नहीं बताया गया है और डिवाइस में वह कॉम्पोनेंट मौजूद नहीं है, तो:

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

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

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

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

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

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

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

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

स्क्रीन का साइज़

Android यूज़र इंटरफ़ेस (यूआई) फ़्रेमवर्क, अलग-अलग स्क्रीन साइज़ के साथ काम करता है. साथ ही, ऐप्लिकेशन को डिवाइस की स्क्रीन साइज़ (जिसे "स्क्रीन लेआउट" भी कहा जाता है) के बारे में जानकारी पाने की अनुमति देता है. इसके लिए, ऐप्लिकेशन को android.content.res.Configuration.screenLayout के ज़रिए SCREENLAYOUT_SIZE_MASK का इस्तेमाल करना होता है. डिवाइस पर लागू किए गए ऐप्लिकेशन में, स्क्रीन का सही साइज़ दिखना चाहिए. यह साइज़, Android SDK के दस्तावेज़ [रिसॉर्स, 38] में बताया गया है और इसे अपस्ट्रीम Android प्लैटफ़ॉर्म तय करता है. खास तौर पर, डिवाइस के लागू होने पर, स्क्रीन के सही साइज़ की जानकारी दी जानी चाहिए. यह जानकारी, डेंसिटी-इंडिपेंडेंट पिक्सल (dp) के हिसाब से, स्क्रीन के नीचे दिए गए डाइमेंशन के हिसाब से दी जानी चाहिए.

  • डिवाइसों की स्क्रीन का साइज़ कम से कम 426 डीपी x 320 डीपी ('छोटा') होना चाहिए
  • जिन डिवाइसों की स्क्रीन का साइज़ 'सामान्य' के तौर पर रिपोर्ट किया जाता है उनकी स्क्रीन का साइज़ कम से कम 470 dp x 320 dp होना चाहिए
  • जिन डिवाइसों की स्क्रीन का साइज़ 'बड़ी' के तौर पर रिपोर्ट किया गया है उनकी स्क्रीन का साइज़ कम से कम 640 डीपी x 480 डीपी होना चाहिए
  • जिन डिवाइसों की स्क्रीन का साइज़ 'बहुत बड़ी' है उनकी स्क्रीन का साइज़ कम से कम 960 डीपी x 720 डीपी होना चाहिए

इसके अलावा, डिवाइसों की स्क्रीन का डायगनल साइज़ कम से कम 2.5 इंच होना चाहिए.

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

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

स्क्रीन का आसपेक्ट रेशियो

आसपेक्ट रेशियो 1.3333 (4:3) और 1.85 (16:9) के बीच होना चाहिए.

स्क्रीन की सघनता

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

  • 120 डीपीआई, जिसे 'ldpi' कहा जाता है
  • 160 डीपीआई, जिसे 'mdpi' कहा जाता है
  • 213 डीपीआई, जिसे 'tvdpi' कहा जाता है
  • 240 डीपीआई, जिसे 'hdpi' कहा जाता है
  • 320 डीपीआई, जिसे 'xhdpi' कहा जाता है
डिवाइस पर लागू होने वाले Android फ़्रेमवर्क की डेंसिटी, डिवाइस की स्क्रीन की डेंसिटी के हिसाब से होनी चाहिए. हालांकि, अगर डिवाइस की डेंसिटी की वजह से स्क्रीन का साइज़, काम करने के लिए तय किए गए कम से कम साइज़ से कम हो जाता है, तो डिवाइस की डेंसिटी को कम किया जा सकता है. अगर Android फ़्रेमवर्क की स्टैंडर्ड सघनता, संख्या के हिसाब से फ़िज़िकल सघनता के सबसे करीब होती है, तो उस स्क्रीन साइज़ की स्क्रीन का साइज़, स्क्रीन के सबसे छोटे साइज़ (320 dp चौड़ाई) से कम हो सकता है. ऐसे में, डिवाइस को लागू करने के लिए, Android फ़्रेमवर्क की अगली डेंसिटी के बारे में बताना चाहिए.

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

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

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

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

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

डिवाइसों को ओरिएंटेशन बदलते समय, स्क्रीन का साइज़ या डेंसिटी नहीं बदलनी चाहिए.

डिवाइसों को यह बताना ज़रूरी है कि वे किन स्क्रीन ओरिएंटेशन (android.hardware.screen.portrait और/याandroid.hardware.screen.landscape) के साथ काम करते हैं. साथ ही, यह भी बताना ज़रूरी है कि वे कम से कम एक ओरिएंटेशन के साथ काम करते हैं. उदाहरण के लिए, टेलिविज़न या लैपटॉप जैसे ऐसे डिवाइसों के लिए, सिर्फ़ android.hardware.screen.landscape की जानकारी देना ज़रूरी है जिनकी स्क्रीन का ओरिएंटेशन एक जैसा रहता है.

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

डिवाइस में लागू किए गए वर्शन, OpenGL ES 1.0 और 2.0, दोनों के साथ काम करने चाहिए. इस बारे में Android SDK के दस्तावेज़ों में बताया गया है. डिवाइस पर लागू किए गए एपीआई को Android Renderscript के साथ भी काम करना चाहिए. इस बारे में Android SDK के दस्तावेज़ [संसाधन, 8] में बताया गया है.

डिवाइस के लागू होने के बाद, यह भी ज़रूरी है कि वह खुद को OpenGL ES 1.0 और 2.0 के साथ काम करने वाला डिवाइस के तौर पर सही तरीके से पहचाने. इसका मतलब है कि:

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

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

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

Android 3.0 में, ऐप्लिकेशन के लिए एक सुविधा शुरू की गई थी. इसकी मदद से, ऐप्लिकेशन यह बता सकते थे कि उन्हें ऐप्लिकेशन, गतिविधि, विंडो या व्यू लेवल पर, 2D ग्राफ़िक के लिए हार्डवेयर ऐक्सेलरेशन चालू करना है. इसके लिए, उन्हें मेनिफ़ेस्ट टैग android:hardwareAccelerated या सीधे एपीआई कॉल का इस्तेमाल करना होता था [संसाधन, 9].

Android 4.0 में, डिवाइस पर लागू होने वाले ऐप्लिकेशन के लिए, डिफ़ॉल्ट रूप से हार्डवेयर से तेज़ी लाएं सुविधा चालू होनी चाहिए. अगर डेवलपर android:hardwareAccelerated="false" को सेट करके या सीधे Android View API की मदद से हार्डवेयर से तेज़ी लाएं सुविधा को बंद करके ऐसा अनुरोध करता है, तो डिवाइस पर लागू होने वाले ऐप्लिकेशन के लिए, हार्डवेयर से तेज़ी लाएं सुविधा बंद होनी चाहिए.

इसके अलावा, डिवाइस पर लागू किए गए एपीआई का व्यवहार, हार्डवेयर से तेज़ी लाने की सुविधा के लिए, Android SDK के दस्तावेज़ [संसाधन, 9] में बताए गए व्यवहार के मुताबिक होना चाहिए.

Android 4.0 में एक TextureView ऑब्जेक्ट शामिल है. इसकी मदद से, डेवलपर यूज़र इंटरफ़ेस (यूआई) की हैरारकी में, हार्डवेयर से तेज़ किए गए OpenGL ES टेक्स्चर को रेंडरिंग टारगेट के तौर पर सीधे तौर पर इंटिग्रेट कर सकते हैं. डिवाइस पर लागू किए गए एपीआई, TextureView एपीआई के साथ काम करने चाहिए. साथ ही, वे अपस्ट्रीम Android के लागू किए गए एपीआई के साथ एक जैसा व्यवहार दिखाने चाहिए.

7.1.5. लेगसी ऐप्लिकेशन के साथ काम करने वाला मोड

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

7.1.6. स्क्रीन टाइप

डिवाइस लागू करने की स्क्रीन को इनमें से किसी एक कैटगरी में रखा जाता है:

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

फ़िक्स्ड-पिक्सल डिवाइस पर लागू करना

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

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

  • डिवाइस को स्क्रीन कॉन्फ़िगरेशन और डिसप्ले मेट्रिक की वही जानकारी देनी चाहिए जो सेक्शन 7.1.1 और 7.1.2 में फ़िक्स्ड-पिक्सल डिसप्ले के लिए दी गई है.
  • डिवाइस को फ़िक्स्ड-पिक्सल डिसप्ले के हिसाब से ही लॉजिकल डेंसिटी दिखानी चाहिए.
  • डिवाइस के स्क्रीन डाइमेंशन, फ़िक्स्ड-पिक्सल डिसप्ले के डाइमेंशन के जैसे या काफ़ी हद तक मिलते-जुलते होने चाहिए.

उदाहरण के लिए, 7" डायगनल साइज़ और 1024x600 पिक्सल रिज़ॉल्यूशन वाले टैबलेट को, फ़िक्स्ड-पिक्सल वाले बड़े एमडीपीआई डिसप्ले के तौर पर माना जाता है. अगर इसमें 720p या 1080p पर दिखने वाला वीडियो आउटपुट पोर्ट है, तो डिवाइस पर लागू करने के लिए आउटपुट को स्केल करना ज़रूरी है, ताकि ऐप्लिकेशन सिर्फ़ बड़ी एमडीपीआई विंडो में चलें. भले ही, फ़िक्स्ड-पिक्सल डिसप्ले या वीडियो आउटपुट पोर्ट का इस्तेमाल किया जा रहा हो.

अलग-अलग पिक्सल वाले डिवाइसों पर लागू करना

वैरिएबल-पिक्सल डिवाइस के लागू होने के लिए, 1280x720 या 1920x1080 (यानी, 720 पिक्सल या 1080 पिक्सल) में से किसी एक या दोनों रिज़ॉल्यूशन का इस्तेमाल करना ज़रूरी है. वैरिएबल-पिक्सल डिसप्ले वाले डिवाइसों के लिए, किसी दूसरे स्क्रीन कॉन्फ़िगरेशन या मोड का इस्तेमाल नहीं किया जा सकता. वैरिएबल-पिक्सल स्क्रीन वाले डिवाइसों के लागू होने पर, रनटाइम या बूट-टाइम पर स्क्रीन कॉन्फ़िगरेशन या मोड बदल सकता है. उदाहरण के लिए, सेट-टॉप बॉक्स का कोई उपयोगकर्ता, 720 पिक्सल वाले डिसप्ले को 1080 पिक्सल वाले डिसप्ले से बदल सकता है. साथ ही, डिवाइस के लागू होने की प्रक्रिया में भी उसी हिसाब से बदलाव हो सकता है.

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

  • 1280x720 (इसे 720p भी कहा जाता है): स्क्रीन का 'बड़ा' साइज़, 'tvdpi' (213 डीपीआई) घनत्व
  • 1920x1080 (इसे 1080p भी कहा जाता है): स्क्रीन का 'बड़ा' साइज़, 'xhdpi' (320 dpi) स्क्रीन की सघनता

साफ़ तौर पर बताने के लिए, Android 4.0 में डिवाइस पर अलग-अलग पिक्सल डाइमेंशन के साथ लागू करने की सुविधा, सिर्फ़ 720p या 1080p तक सीमित है. साथ ही, डिवाइस को स्क्रीन साइज़ और डेंसिटी बकेट की जानकारी देने के लिए कॉन्फ़िगर करना ज़रूरी है, जैसा कि ऊपर बताया गया है.

7.1.7. स्क्रीन की टेक्नोलॉजी

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

  • डिवाइसों पर 16-बिट कलर ग्राफ़िक्स रेंडर करने वाले डिसप्ले काम करने चाहिए. साथ ही, डिवाइसों पर 24-बिट कलर ग्राफ़िक्स रेंडर करने वाले डिसप्ले काम करने चाहिए.
  • डिवाइसों पर ऐसे डिसप्ले होने चाहिए जिन पर ऐनिमेशन रेंडर किए जा सकें.
  • इस्तेमाल की गई डिसप्ले टेक्नोलॉजी का पिक्सल आसपेक्ट रेशियो (PAR) 0.9 से 1.1 के बीच होना चाहिए. इसका मतलब है कि पिक्सल का आसपेक्ट रेशियो, स्क्वेयर (1.0) के आस-पास होना चाहिए. साथ ही, इसमें 10% तक की गड़बड़ी हो सकती है.

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

7.2.1. कीबोर्ड

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

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

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

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

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

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

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

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

  • डिवाइस पर नेविगेशन बटनों को स्क्रीन के किसी ऐसे हिस्से पर इस्तेमाल करना चाहिए जो ऐप्लिकेशन के लिए उपलब्ध न हो. साथ ही, यह ज़रूरी है कि ये बटन, ऐप्लिकेशन के लिए उपलब्ध स्क्रीन के हिस्से को छिपाएं या उसमें किसी तरह का रुकावट न डालें.
  • डिवाइस में लागू किए गए एपीआई, डिसप्ले का एक हिस्सा उन ऐप्लिकेशन के लिए उपलब्ध कराना चाहिए जो सेक्शन 7.1.1 में बताई गई ज़रूरी शर्तों को पूरा करते हैं.
  • जब ऐप्लिकेशन, सिस्टम यूज़र इंटरफ़ेस (यूआई) मोड की जानकारी न दें या SYSTEM_UI_FLAG_VISIBLE की जानकारी दें, तो डिवाइस पर नेविगेशन बटन दिखने चाहिए.
  • जब ऐप्लिकेशन SYSTEM_UI_FLAG_LOW_PROFILE की जानकारी देते हैं, तो डिवाइस पर नेविगेशन बटनों को "कम प्रोफ़ाइल" (जैसे, धुंधला) मोड में दिखाना ज़रूरी है, ताकि वे ध्यान न भटाएं.
  • जब ऐप्लिकेशन SYSTEM_UI_FLAG_HIDE_NAVIGATION तय करते हैं, तो डिवाइस पर नेविगेशन बटन छिपाने होंगे.
  • जब targetSdkVersion <= 10 हो, तो डिवाइस पर ऐप्लिकेशन के लिए मेन्यू बटन होना चाहिए. वहीं, जब targetSdkVersion > 10 हो, तो डिवाइस पर ऐप्लिकेशन के लिए मेन्यू बटन नहीं होना चाहिए.

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

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

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

Android 4.0 में कई तरह की टच स्क्रीन, टच पैड, और फ़ेक टच इनपुट डिवाइसों के साथ काम करने की सुविधा शामिल है. टच स्क्रीन वाले डिवाइसों पर लागू होने वाले इंटरफ़ेस, डिसप्ले [संसाधन, 61] से जुड़े होते हैं. इससे उपयोगकर्ता को ऐसा लगता है कि वह स्क्रीन पर मौजूद आइटम को सीधे तौर पर मैनेज कर रहा है. उपयोगकर्ता सीधे तौर पर स्क्रीन को छू रहा है, इसलिए सिस्टम को उन ऑब्जेक्ट के बारे में बताने के लिए, किसी अन्य सुविधा की ज़रूरत नहीं होती जिनमें बदलाव किया जा रहा है. इसके उलट, नकली टच इंटरफ़ेस, उपयोगकर्ता इनपुट सिस्टम उपलब्ध कराता है, जो टचस्क्रीन की सुविधाओं के सबसेट के बराबर होता है. उदाहरण के लिए, ऑन-स्क्रीन कर्सर को चलाने वाला माउस या रिमोट कंट्रोल, टच की सुविधा के करीब होता है. हालांकि, इसके लिए उपयोगकर्ता को पहले बिंदु या फ़ोकस चुनना होता है और फिर क्लिक करना होता है. माउस, ट्रैकपैड, ज्यरो-आधारित एयर माउस, ज्यरो-पॉइंटर, जॉयस्टिक, और मल्टी-टच ट्रैकपैड जैसे कई इनपुट डिवाइसों पर, फ़ेक टच इंटरैक्शन की सुविधा काम कर सकती है. Android 4.0 में सुविधा के लिए एक कॉन्स्टेंट android.hardware.faketouch शामिल है. यह कॉन्स्टेंट, हाई-फ़िडेलिटी वाले ऐसे इनपुट डिवाइस से जुड़ा है जो टच (यानी पॉइंटर पर आधारित) नहीं है. जैसे, माउस या ट्रैकपैड. यह डिवाइस, टच पर आधारित इनपुट (जिसमें बुनियादी जेस्चर का इस्तेमाल शामिल है) को ठीक से एमुलेट कर सकता है. साथ ही, यह भी बताता है कि डिवाइस, टचस्क्रीन की सुविधा के एमुलेट किए गए सबसेट के साथ काम करता है. जिन डिवाइसों में फ़ेक टच की सुविधा लागू की गई है उन्हें सेक्शन 7.2.5 में बताई गई ज़रूरी शर्तों को पूरा करना होगा.

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

7.2.5. नकली टच इनपुट

डिवाइस के ऐसे वर्शन जिनमें android.hardware.faketouch के साथ काम करने की सुविधा है

  • पॉइंटर की जगह की स्क्रीन पर मौजूद X और Y की सटीक पोज़िशन की जानकारी देनी चाहिए. साथ ही, स्क्रीन पर विज़ुअल पॉइंटर दिखाना चाहिए[संसाधन, 60]
  • टच इवेंट को ऐक्शन कोड [संसाधन, 60] के साथ रिपोर्ट करना ज़रूरी है. यह कोड, स्क्रीन [संसाधन, 60] पर पॉइंटर के down या up पर जाने पर होने वाले स्टेटस में बदलाव के बारे में बताता है
  • यह ज़रूरी है कि स्क्रीन पर मौजूद किसी ऑब्जेक्ट पर कर्सर down और up काम करते हों. इससे, उपयोगकर्ता स्क्रीन पर मौजूद किसी ऑब्जेक्ट पर टैप कर सकते हैं
  • यह ज़रूरी है कि स्क्रीन पर किसी ऑब्जेक्ट पर एक ही जगह पर, एक तय समयसीमा के अंदर पॉइंटर down, पॉइंटर up, पॉइंटर down, फिर पॉइंटर up का इस्तेमाल किया जा सके. इससे उपयोगकर्ता, स्क्रीन पर किसी ऑब्जेक्ट पर दो बार टैप करने की सुविधा का इस्तेमाल कर सकते हैं [संसाधन, 60]
  • स्क्रीन पर किसी भी बिंदु पर पॉइंटर down का इस्तेमाल किया जा सकता है. इसके बाद, पॉइंटर को स्क्रीन पर किसी भी बिंदु पर ले जाया जा सकता है. इसके बाद, पॉइंटर up का इस्तेमाल किया जा सकता है, जिससे उपयोगकर्ता टच ड्रैग की सुविधा का इस्तेमाल कर सकते हैं
  • इसमें पॉइंटर down की सुविधा होनी चाहिए, ताकि उपयोगकर्ता किसी ऑब्जेक्ट को स्क्रीन पर तुरंत किसी दूसरी जगह पर ले जा सकें. इसके बाद, स्क्रीन पर पॉइंटर up की सुविधा होनी चाहिए, ताकि उपयोगकर्ता किसी ऑब्जेक्ट को स्क्रीन पर फ़्लिंग कर सकें

जिन डिवाइसों पर android.hardware.faketouch.multitouch.distinct की सुविधा काम करती है उन्हें ऊपर बताई गई, नकली टच की सुविधा से जुड़ी ज़रूरी शर्तें पूरी करनी होंगी. साथ ही, उन्हें दो या उससे ज़्यादा इंडिपेंडेंट पॉइंटर इनपुट की अलग-अलग ट्रैकिंग की सुविधा भी देनी होगी.

7.2.6. माइक्रोफ़ोन

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

  • android.hardware.microphone सुविधा के लिए, ज़रूरी है कि आप इसके लिए एक स्थिर वैल्यू दें
  • सेक्शन 5.3 में बताई गई ऑडियो क्वालिटी की ज़रूरी शर्तों को पूरा करना चाहिए
  • सेक्शन 5.4 में बताई गई, ऑडियो के इंतज़ार के समय से जुड़ी ज़रूरी शर्तों को पूरा करना चाहिए

7.3. सेंसर

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

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

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

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

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

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

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

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

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

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

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

7.3.3. जीपीएस

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

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

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

  • तापमान के हिसाब से अडजस्ट होना चाहिए
  • यह 5.5*पाई रेडियन/सेकंड (यानी, हर सेकंड करीब 1,000 डिग्री) तक ऑरिएंटेशन में होने वाले बदलावों को मेज़र कर सकता हो
  • 100 हर्ट्ज़ या उससे ज़्यादा पर इवेंट डिलीवर करने की ज़रूरी शर्त
  • सटीक जानकारी देने के लिए, 12 बिट या उससे ज़्यादा की ज़रूरत होती है
  • हर हर्ट्ज (हर हर्ट्ज में वैरिएंस या rad^2 / s) के लिए, वैरिएंस 1e-7 rad^2 / s^2 से ज़्यादा नहीं होना चाहिए. वैरिएंस को सैंपलिंग रेट के हिसाब से बदलने की अनुमति है, लेकिन इसे इस वैल्यू के हिसाब से सीमित रखना चाहिए. दूसरे शब्दों में, अगर 1 हर्ट्ज़ सैंपलिंग रेट पर, घुमाव की दर का मेज़रमेंट किया जाता है, तो यह 1e-7 rad^2/s^2 से ज़्यादा नहीं होना चाहिए.
  • टाइमस्टैंप, हार्डवेयर इवेंट के होने के समय के जितना हो सके उतना करीब होने चाहिए. लगातार होने वाली देरी को हटाना ज़रूरी है.

7.3.5. बैरोमीटर

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

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

7.3.7. Thermometer

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

7.3.7. फ़ोटोमीटर

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

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

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

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

7.4.1. टेलीफ़ोनी

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

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

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

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

7.4.3. ब्लूटूथ

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

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

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

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

  • android.content.pm.PackageManager.hasSystemFeature() तरीके से, android.hardware.nfc सुविधा की जानकारी देना ज़रूरी है. [संसाधन, 37]
  • यह ज़रूरी है कि यह एनएफ़सी के इन स्टैंडर्ड के ज़रिए, एनडीएफ़ मैसेज को पढ़ और लिख सके:
    • यह एनएफ़सी फ़ोरम के रीडर/राइटर्स के तौर पर काम कर सकता हो (जैसा कि एनएफ़सी फ़ोरम के तकनीकी स्पेसिफ़िकेशन के मुताबिक बताया गया है, NFCForum-TS-DigitalProtocol-1.0), जो इन एनएफ़सी स्टैंडर्ड के मुताबिक हो:
      • NfcA (ISO14443-3A)
      • NfcB (ISO14443-3B)
      • NfcF (JIS 6319-4)
      • IsoDep (ISO 14443-4)
      • एनएफ़सी फ़ोरम टैग टाइप 1, 2, 3, 4 (एनएफ़सी फ़ोरम के मुताबिक)
  • यह डिवाइस, नीचे दिए गए एनएफ़सी स्टैंडर्ड के ज़रिए, एनडीएफ़ मैसेज पढ़ और लिख सकता है. ध्यान दें कि Android 4.0 के लिए, यहां दिए गए एनएफ़सी स्टैंडर्ड को "इसका इस्तेमाल करना चाहिए" के तौर पर बताया गया है. हालांकि, आने वाले वर्शन के लिए, इन स्टैंडर्ड को "इसका इस्तेमाल करना ज़रूरी है" के तौर पर बदला जाएगा. इसका मतलब है कि Android 4.0 में ये स्टैंडर्ड इस्तेमाल करना ज़रूरी नहीं है. हालांकि, आने वाले वर्शन में इनका इस्तेमाल करना ज़रूरी होगा. Android 4.0 पर काम करने वाले मौजूदा और नए डिवाइसों को Android 4.0 में इन ज़रूरी शर्तों को पूरा करने का सुझाव दिया जाता है, ताकि वे आने वाले समय में प्लैटफ़ॉर्म के रिलीज़ किए जाने वाले नए वर्शन पर अपग्रेड कर सकें.
    • NfcV (ISO 15693)
  • यह ज़रूरी है कि यह डिवाइस, यहां दिए गए पीयर-टू-पीयर स्टैंडर्ड और प्रोटोकॉल के ज़रिए डेटा भेज और पा सके:
    • ISO 18092
    • LLCP 1.0 (NFC फ़ोरम ने तय किया है)
    • SDP 1.0 (एनएफ़सी फ़ोरम ने तय किया है)
    • एनडीएफ़ई पुश प्रोटोकॉल [संसाधन, 43]
    • SNEP 1.0 (NFC फ़ोरम के मुताबिक)
  • इसमें Android Beam की सुविधा शामिल होनी चाहिए:
    • SNEP डिफ़ॉल्ट सर्वर को लागू करना ज़रूरी है. डिफ़ॉल्ट SNEP सर्वर से मिले मान्य एनडीएफ़ मैसेज, android.nfc.ACTION_NDEF_DISCOVERED इंटेंट का इस्तेमाल करके, ऐप्लिकेशन को भेजे जाने चाहिए. सेटिंग में जाकर Android Beam को बंद करने पर, इनकमिंग एनडीएफ़ई मैसेज भेजने की सुविधा बंद नहीं होनी चाहिए.
    • एनपीपी सर्वर को लागू करना ज़रूरी है. एनपीपी सर्वर को मिले मैसेज को, एसएनईपी डिफ़ॉल्ट सर्वर की तरह ही प्रोसेस किया जाना चाहिए.
    • Android Beam चालू होने पर, SNEP क्लाइंट को लागू करना ज़रूरी है. साथ ही, डिफ़ॉल्ट SNEP सर्वर पर आउटबाउंड P2P NDEF भेजने की कोशिश करनी चाहिए. अगर कोई डिफ़ॉल्ट एसएनईपी सर्वर नहीं मिलता है, तो क्लाइंट को किसी एनपीपी सर्वर पर भेजने की कोशिश करनी चाहिए.
    • फ़ोरग्राउंड गतिविधियों को आउटबाउंड P2P NDEF मैसेज सेट करने की अनुमति देनी चाहिए. इसके लिए, ये फ़ंक्शन इस्तेमाल करें: android.nfc.NfcAdapter.setNdefPushMessage, android.nfc.NfcAdapter.setNdefPushMessageCallback, और android.nfc.NfcAdapter.enableForegroundNdefPush.
    • आउटबाउंड पी2पी एनडीएफ़ मैसेज भेजने से पहले, 'टच करके बीम करें' जैसे जेस्चर या स्क्रीन पर पुष्टि करने की सुविधा का इस्तेमाल करना चाहिए.
    • Android Beam की सुविधा डिफ़ॉल्ट रूप से चालू होनी चाहिए
  • एनएफ़सी डिस्कवरी मोड में, काम करने वाली सभी टेक्नोलॉजी के लिए पोल करना ज़रूरी है.
  • डिवाइस के चालू होने पर, स्क्रीन चालू और लॉक-स्क्रीन अनलॉक होने पर, डिवाइस को एनएफ़सी डिस्कवरी मोड में होना चाहिए.

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

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

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

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

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

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 4.0 में मौजूद कैमरा एपीआई, सामने वाले कैमरे के लिए खास तौर पर काम करता है. साथ ही, डिवाइस में एपीआई को कॉन्फ़िगर नहीं किया जाना चाहिए, ताकि सामने वाले कैमरे को डिफ़ॉल्ट रूप से पीछे वाले कैमरे के तौर पर इस्तेमाल किया जा सके. भले ही, डिवाइस में सिर्फ़ यही कैमरा हो.
  • इसमें सेक्शन 7.5.1 में बताई गई, पीछे की ओर फ़ोकस करने वाले कैमरों के लिए उपलब्ध सुविधाएं (जैसे, ऑटो-फ़ोकस, फ़्लैश वगैरह) शामिल हो सकती हैं.
  • CameraPreview में, ऐप्लिकेशन की स्ट्रीम को हॉरिज़ॉन्टल तौर पर दिखाना ज़रूरी है. इसका तरीका यहां बताया गया है:
    • अगर डिवाइस को उपयोगकर्ता घुमा सकता है (जैसे कि ऐक्सीलेरोमीटर की मदद से अपने-आप या उपयोगकर्ता के इनपुट से मैन्युअल तरीके से), तो कैमरे की झलक को डिवाइस के मौजूदा ओरिएंटेशन के हिसाब से हॉरिज़ॉन्टल तौर पर दिखाना ज़रूरी है.
    • अगर मौजूदा ऐप्लिकेशन ने साफ़ तौर पर अनुरोध किया है कि android.hardware.Camera.setDisplayOrientation() [संसाधन, 50] तरीके को कॉल करके, कैमरे के डिसप्ले को घुमाया जाए, तो ऐप्लिकेशन के तय किए गए ओरिएंटेशन के हिसाब से, कैमरे की झलक को हॉरिज़ॉन्टल तौर पर मिरर किया जाना चाहिए.
    • अगर ऐसा नहीं है, तो झलक को डिवाइस के डिफ़ॉल्ट हॉरिज़ॉन्टल ऐक्सिस के साथ मिरर किया जाना चाहिए.
  • पोस्टव्यू में दिखाई गई इमेज को उसी तरह से दिखाना चाहिए जिस तरह से कैमरे की झलक वाली इमेज स्ट्रीम दिखती है. (अगर डिवाइस पर लागू किए गए टूल में पोस्टव्यू की सुविधा काम नहीं करती है, तो यह ज़रूरी शर्त लागू नहीं होगी.)
  • कैप्चर की गई फ़ाइनल इमेज या वीडियो स्ट्रीम को ऐप्लिकेशन कॉलबैक में वापस नहीं भेजना चाहिए या मीडिया स्टोरेज में सेव नहीं करना चाहिए

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 कॉन्स्टेंट से पता चलता है) का इस्तेमाल किया जाना चाहिए. यह फ़ॉर्मैट, सामने और पीछे के कैमरे, दोनों के लिए इस्तेमाल किया जाना चाहिए. (हार्डवेयर वीडियो डिकोडर और कैमरे में किसी भी नेटिव पिक्सल फ़ॉर्मैट का इस्तेमाल किया जा सकता है. हालांकि, डिवाइस में YV12 में बदलाव करने की सुविधा होनी चाहिए.)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • डिवाइस में लागू किए गए MTP प्रोटोकॉल को, Android के रेफ़रंस एमटीपी होस्ट, Android File Transfer [संसाधन, 57] के साथ काम करना चाहिए.
  • डिवाइस को लागू करने पर, 0x00 की यूएसबी डिवाइस क्लास की रिपोर्ट होनी चाहिए.
  • डिवाइस के लागू होने पर, यूएसबी इंटरफ़ेस का नाम 'MTP' होना चाहिए.

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

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

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

7.7. यूएसबी

डिवाइस में यूएसबी क्लाइंट पोर्ट और यूएसबी होस्ट पोर्ट शामिल होने चाहिए.

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

  • पोर्ट को स्टैंडर्ड यूएसबी-ए पोर्ट वाले यूएसबी होस्ट से कनेक्ट किया जा सकता हो
  • पोर्ट में, डिवाइस के साइड में माइक्रो यूएसबी फ़ॉर्म फ़ैक्टर का इस्तेमाल किया जाना चाहिए
  • यह ज़रूरी है कि डिवाइस से कनेक्ट किए गए होस्ट को, यूएसबी मास स्टोरेज या मीडिया ट्रांसफ़र प्रोटोकॉल का इस्तेमाल करके, शेयर किए गए स्टोरेज वॉल्यूम का कॉन्टेंट ऐक्सेस करने की अनुमति दी जाए
  • इसमें Android Open Accessory API और स्पेसिफ़िकेशन को लागू करना ज़रूरी है, जैसा कि Android SDK टूल के दस्तावेज़ में बताया गया है. साथ ही, इसमें हार्डवेयर की सुविधा android.hardware.usb.accessory के साथ काम करने की जानकारी देना ज़रूरी है [संसाधन, 51]

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

  • इसमें किसी गैर-स्टैंडर्ड पोर्ट फ़ॉर्म फ़ैक्टर का इस्तेमाल किया जा सकता है. हालांकि, अगर ऐसा है, तो पोर्ट को स्टैंडर्ड यूएसबी-ए में बदलने वाली केबल या केबल के साथ शिप करना ज़रूरी है
  • यह ज़रूरी है कि ऐप्लिकेशन में Android USB होस्ट एपीआई को लागू किया गया हो, जैसा कि Android SDK टूल में बताया गया है. साथ ही, यह भी ज़रूरी है कि ऐप्लिकेशन में हार्डवेयर की सुविधा के साथ काम करने की जानकारी दी गई होandroid.hardware.usb.host [संसाधन, 52]

डिवाइस पर लागू करने के लिए, Android डीबग ब्रिज को लागू करना ज़रूरी है. अगर किसी डिवाइस में यूएसबी क्लाइंट पोर्ट नहीं है, तो उसे लोकल-एरिया नेटवर्क (जैसे, ईथरनेट या 802.11) के ज़रिए Android Debug Bridge को लागू करना होगा

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

डिवाइस को लागू करने के लिए, यह ज़रूरी है कि वह यहां दी गई टेबल में बताई गई, Android 4.0 के साथ काम करने वाले डिवाइस की मुख्य परफ़ॉर्मेंस मेट्रिक को पूरा करता हो:

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

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

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

9.1. अनुमतियां

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

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

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

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

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

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 4.0 को लागू करने वाले लोगों को हमारा सुझाव है कि वे Android Open Source Project से मिले रेफ़रंस और Android 4.0 के लागू करने के सुझाए गए तरीके में कम से कम बदलाव करें. इससे, गड़बड़ियों की संभावना कम हो जाएगी. इन गड़बड़ियों की वजह से, डिवाइस के साथ काम करने में समस्याएं आ सकती हैं. इन गड़बड़ियों को ठीक करने के लिए, आपको फिर से काम करना पड़ सकता है. साथ ही, डिवाइस के लिए अपडेट भी करना पड़ सकता है.

10.1. Compatibility Test Suite

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

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

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

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

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

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

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

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

  • "Android के लिए ऐप्लिकेशन" ऐप्लिकेशन [संसाधन, 55].
  • Replica Island (Android Market में उपलब्ध है)

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

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