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

पहला बदलाव
पिछली बार अपडेट किया गया: 27 नवंबर, 2013

कॉपीराइट © 2013, 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. दस्तावेज़ में बदलावों का लॉग
13. हमसे संपर्क करें

1. परिचय

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

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

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

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

अगर सेक्शन 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.4 के लिए इस्तेमाल की जा सकने वाली वर्शन स्ट्रिंग: http://source.android.com/docs/compatibility/4.4/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/webstorage/
  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_guidelines/icon_design_status_bar.html
  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. 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, systrace के लिए): 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. कैमरा: 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/permissions.html
  55. Android के लिए ऐप्लिकेशन: http://code.google.com/p/apps-for-android
  56. Android 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. एनएफ़सी कनेक्शन हैंडओवर: http://www.nfc-forum.org/specs/spec_list/#conn_handover
  61. एनएफ़सी का इस्तेमाल करके, ब्लूटूथ को सुरक्षित तरीके से आसानी से जोड़ना: http://www.nfc-forum.org/resources/AppDocs/NFCForum_AD_BTSSP_1_0.pdf
  62. वाई-फ़ाई मल्टीकास्ट एपीआई: http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html
  63. ऐक्शन असिस्ट: http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST
  64. यूएसबी चार्जिंग स्पेसिफ़िकेशन: http://www.usb.org/developers/devclass_docs/USB_Battery_Charging_1.2.pdf
  65. Android Beam: http://developer.android.com/guide/topics/nfc/nfc.html
  66. Android यूएसबी ऑडियो: http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO
  67. Android पर NFC की मदद से फ़ाइलें शेयर करने की सेटिंग: http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS
  68. वाई-फ़ाई डायरेक्ट (वाई-फ़ाई पी2पी): http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html
  69. लॉक और होम स्क्रीन विजेट: http://developer.android.com/reference/android/appwidget/AppWidgetProviderInfo.html
  70. UserManager का रेफ़रंस: http://developer.android.com/reference/android/os/UserManager.html
  71. बाहरी स्टोरेज का रेफ़रंस: /docs/core/storage
  72. बाहरी स्टोरेज के लिए एपीआई: http://developer.android.com/reference/android/os/Environment.html
  73. एसएमएस के लिए छोटा कोड: http://en.wikipedia.org/wiki/Short_code
  74. मीडिया रिमोट कंट्रोल क्लाइंट: http://developer.android.com/reference/android/media/RemoteControlClient.html
  75. Display Manager: http://developer.android.com/reference/android/hardware/display/DisplayManager.html
  76. ड्रीम्स: http://developer.android.com/reference/android/service/dreams/DreamService.html
  77. Android ऐप्लिकेशन डेवलपमेंट से जुड़ी सेटिंग: http://developer.android.com/reference/android/provider/Settings.html#ACTION_APPLICATION_DEVELOPMENT_SETTINGS
  78. कैमरा: http://developer.android.com/reference/android/hardware/Camera.Parameters.html
  79. EGL एक्सटेंशन-EGL_ANDROID_RECORDABLE: http://www.khronos.org/registry/egl/extensions/ANDROID/EGL_ANDROID_recordable.txt
  80. Motion Event API: http://developer.android.com/reference/android/view/MotionEvent.html
  81. टच इनपुट कॉन्फ़िगरेशन: http://source.android.com/docs/core/interaction/input/touch-devices.html
  82. यूनिकोड 6.1.0: http://www.unicode.org/versions/Unicode6.1.0/
  83. वेबव्यू के साथ काम करने वाले डिवाइस: http://www.chromium.org/
  84. Android डिवाइस के मालिक का ऐप्लिकेशन: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isDeviceOwnerApp(java.lang.String)
  85. WifiManager API: http://developer.android.com/reference/android/net/wifi/WifiManager.html
  86. आरटीसी हार्डवेयर कोडिंग से जुड़ी ज़रूरी शर्तें: http://www.webmproject.org/hardware/rtc-coding-requirements/
  87. Settings.Secure LOCATION_MODE: http://developer.android.com/reference/android/provider/Settings.Secure.html#LOCATION_MODE
  88. Content Resolver: http://developer.android.com/reference/android/content/ContentResolver.html
  89. SettingInjectorService: http://developer.android.com/reference/android/location/SettingInjectorService.html
  90. होस्ट-आधारित कार्ड एमुलेटर: http://developer.android.com/guide/topics/connectivity/nfc/hce.html
  91. टेलीफ़ोनी सेवा देने वाली कंपनी: http://developer.android.com/reference/android/provider/Telephony.html

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

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

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

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

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

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

3.2. Soft API Compatibility

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

3.2.1. अनुमतियां

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

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

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

पैरामीटर टिप्पणियां
VERSION.RELEASE फ़िलहाल चल रहे Android सिस्टम का वर्शन, इंसान के पढ़ने लायक फ़ॉर्मैट में. इस फ़ील्ड में, [संसाधन, 7] में दी गई स्ट्रिंग वैल्यू में से कोई एक वैल्यू होनी चाहिए.
VERSION.SDK फ़िलहाल चल रहे Android सिस्टम का वर्शन, तीसरे पक्ष के ऐप्लिकेशन कोड के लिए ऐक्सेस किए जा सकने वाले फ़ॉर्मैट में. Android 4.4 के लिए, इस फ़ील्ड की वैल्यू 19 होनी चाहिए.
VERSION.SDK_INT फ़िलहाल चल रहे Android सिस्टम का वर्शन, तीसरे पक्ष के ऐप्लिकेशन कोड के लिए ऐक्सेस किए जा सकने वाले फ़ॉर्मैट में. Android 4.4 के लिए, इस फ़ील्ड की वैल्यू 19 होनी चाहिए.
VERSION.INCREMENTAL डिवाइस इंप्लीमेंटर की चुनी गई वैल्यू, जो फ़िलहाल चल रहे Android सिस्टम के खास बिल्ड को इंसान के पढ़ने लायक फ़ॉर्मैट में दिखाती है. इस वैल्यू का इस्तेमाल, असली उपयोगकर्ताओं के लिए उपलब्ध कराए गए अलग-अलग बिल्ड के लिए फिर से नहीं किया जाना चाहिए. इस फ़ील्ड का आम तौर पर इस्तेमाल, यह बताने के लिए किया जाता है कि बिल्ड जनरेट करने के लिए, किस बिल्ड नंबर या सोर्स-कंट्रोल में बदलाव करने वाले आइडेंटिफ़ायर का इस्तेमाल किया गया था. इस फ़ील्ड के लिए, किसी खास फ़ॉर्मैट की ज़रूरत नहीं होती. हालांकि, यह शर्त ज़रूरी है कि यह शून्य या खाली स्ट्रिंग ("") न हो.
बोर्ड डिवाइस लागू करने वाले व्यक्ति की चुनी गई वैल्यू, जो डिवाइस में इस्तेमाल किए गए खास इंटरनल हार्डवेयर की पहचान करती है. यह वैल्यू, इंसान के पढ़ने लायक फ़ॉर्मैट में होती है. इस फ़ील्ड का इस्तेमाल, डिवाइस को पावर देने वाले बोर्ड के खास वर्शन की जानकारी देने के लिए किया जा सकता है. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है. साथ ही, यह वैल्यू रेगुलर एक्सप्रेशन "^[a-zA-Z0-9.,_-]+$" से मैच करनी चाहिए.
ब्रैंड यह वैल्यू, डिवाइस से जुड़े ब्रैंड के नाम को दिखाती है, जिसे असली उपयोगकर्ता जानते हैं. यह एट्रिब्यूट, लोगों के पढ़ने लायक फ़ॉर्मैट में होना चाहिए. साथ ही, इसमें डिवाइस के मैन्युफ़ैक्चरर या उस कंपनी के ब्रैंड की जानकारी होनी चाहिए जिसका नाम डिवाइस के लिए मार्केटिंग में इस्तेमाल किया जाता है. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है. साथ ही, यह वैल्यू "^[a-zA-Z0-9.,_-]+$" रेगुलर एक्सप्रेशन से मेल खानी चाहिए.
CPU_ABI नेटिव कोड के निर्देश सेट (सीपीयू टाइप + एबीआई कन्वेंशन) का नाम. सेक्शन 3.3: नेटिव एपीआई के साथ काम करना देखें.
CPU_ABI2 नेटिव कोड के दूसरे निर्देश सेट (सीपीयू टाइप + एबीआई कन्वेंशन) का नाम. सेक्शन 3.3: नेटिव एपीआई के साथ काम करना देखें.
डिवाइस डिवाइस लागू करने वाले व्यक्ति या कंपनी की चुनी गई वैल्यू. इसमें डिवाइस के हार्डवेयर की सुविधाओं और इंडस्ट्रियल डिज़ाइन के कॉन्फ़िगरेशन की पहचान करने वाला डेवलपमेंट का नाम या कोड नेम होता है. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है और यह रेगुलर एक्सप्रेशन "^[a-zA-Z0-9.,_-]+$" से मैच करनी चाहिए.
फ़िंगरप्रिंट यह एक स्ट्रिंग है, जो इस बिल्ड की खास तौर पर पहचान करती है. यह पढ़ने में आसान होना चाहिए. यह इस टेंप्लेट के मुताबिक होना चाहिए:
$(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)
उदाहरण के लिए:
acme/myproduct/mydevice:4.4/KRT16/3359:userdebug/test-keys
फ़िंगरप्रिंट में खाली जगह वाले वर्ण नहीं होने चाहिए. अगर ऊपर दिए गए टेंप्लेट में शामिल अन्य फ़ील्ड में खाली जगह वाले वर्ण हैं, तो उन्हें बिल्ड फ़िंगरप्रिंट में किसी दूसरे वर्ण से बदलना ज़रूरी है. जैसे, अंडरस्कोर ("_") वर्ण. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है.
हार्डवेयर हार्डवेयर का नाम (कर्नल कमांड लाइन या /proc से). इसे किसी व्यक्ति के लिए आसानी से पढ़ा जा सकने वाला होना चाहिए. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है. साथ ही, यह वैल्यू रेगुलर एक्सप्रेशन "^[a-zA-Z0-9.,_-]+$" से मैच करनी चाहिए.
होस्ट यह एक स्ट्रिंग होती है, जो उस होस्ट की खास पहचान करती है जिस पर बिल्ड बनाया गया था. यह स्ट्रिंग, मनुष्य के पढ़ने लायक फ़ॉर्मैट में होती है. इस फ़ील्ड के फ़ॉर्मैट के लिए कोई ज़रूरी शर्त नहीं है. हालांकि, यह शर्त ज़रूरी है कि यह शून्य या खाली स्ट्रिंग ("") न हो.
आईडी डिवाइस लागू करने वाला व्यक्ति, किसी रिलीज़ को रेफ़र करने के लिए, यह आइडेंटिफ़ायर चुनता है. यह आइडेंटिफ़ायर, लोगों के पढ़ने लायक फ़ॉर्मैट में होता है. यह फ़ील्ड, android.os.Build.VERSION.INCREMENTAL जैसा हो सकता है. हालांकि, यह ज़रूरी है कि यह वैल्यू, उपयोगकर्ताओं के लिए सॉफ़्टवेयर के बिल्ड के बीच अंतर करने के लिए काम की हो. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है. साथ ही, यह वैल्यू रेगुलर एक्सप्रेशन "^[a-zA-Z0-9.,_-]+$" से मैच करनी चाहिए.
मैन्युफ़ैक्चरर प्रॉडक्ट के ओरिजनल इक्विपमेंट मैन्युफ़ैक्चरर (OEM) का ट्रेड नेम. इस फ़ील्ड के फ़ॉर्मैट के लिए कोई ज़रूरी शर्त नहीं है. हालांकि, यह ज़रूरी है कि यह शून्य या खाली स्ट्रिंग ("") न हो.
MODEL डिवाइस लागू करने वाले व्यक्ति की चुनी गई वैल्यू, जिसमें डिवाइस का नाम होता है, जैसा कि असली उपयोगकर्ता को पता होता है. यह वही नाम होना चाहिए जिससे डिवाइस को मार्केट में लाया जाता है और असली उपयोगकर्ताओं को बेचा जाता है. इस फ़ील्ड के फ़ॉर्मैट के लिए कोई ज़रूरी शर्त नहीं है. हालांकि, यह शर्त ज़रूरी है कि यह शून्य या खाली स्ट्रिंग ("") न हो.
प्रॉडक्ट डिवाइस लागू करने वाले व्यक्ति या कंपनी की चुनी गई वैल्यू. इसमें किसी खास प्रॉडक्ट (SKU) का डेवलपमेंट नेम या कोड नेम शामिल होता है. यह वैल्यू, उसी ब्रैंड में यूनीक होनी चाहिए. यह डेटा, इंसानों के लिए पढ़ने लायक होना चाहिए. हालांकि, यह ज़रूरी नहीं है कि इसे असली उपयोगकर्ता देखें. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है. साथ ही, यह वैल्यू "^[a-zA-Z0-9.,_-]+$" रेगुलर एक्सप्रेशन से मेल खानी चाहिए.
SERIAL हार्डवेयर का सीरियल नंबर, जो उपलब्ध होना चाहिए. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर कोड किया जा सकता है. साथ ही, यह वैल्यू रेगुलर एक्सप्रेशन "^([a-zA-Z0-9]{6,20})$" से मैच करनी चाहिए.
टैग डिवाइस लागू करने वाले व्यक्ति के चुने गए टैग की सूची, जिन्हें कॉमा लगाकर अलग किया गया है. इससे, बिल्ड को और बेहतर तरीके से अलग किया जा सकता है. उदाहरण के लिए, "unsigned,debug". इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है. साथ ही, यह वैल्यू रेगुलर एक्सप्रेशन "^[a-zA-Z0-9.,_-]+$" से मैच करनी चाहिए.
समय यह वैल्यू, बिल्ड होने के समय का टाइमस्टैंप दिखाती है.
वाई-फ़ाई के टाइप के बारे में जानकारी डिवाइस इंप्लीमेंटर की चुनी गई वैल्यू, जो बिल्ड के रनटाइम कॉन्फ़िगरेशन के बारे में बताती है. इस फ़ील्ड में, Android के तीन सामान्य रनटाइम कॉन्फ़िगरेशन में से किसी एक की वैल्यू होनी चाहिए: "user", "userdebug" या "eng". इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है. साथ ही, यह वैल्यू रेगुलर एक्सप्रेशन "^[a-zA-Z0-9.,_-]+$" से मैच करनी चाहिए.
उपयोगकर्ता उस उपयोगकर्ता (या ऑटोमेटेड उपयोगकर्ता) का नाम या यूज़र आईडी जिसने बिल्ड जनरेट किया. इस फ़ील्ड के फ़ॉर्मैट के लिए कोई ज़रूरी शर्त नहीं है. हालांकि, यह ज़रूरी है कि यह शून्य या खाली स्ट्रिंग ("") न हो.

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

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

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

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

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

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

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

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

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

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

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

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

हालांकि, डिवाइस पर लागू होने पर, कुछ यूआरआई पैटर्न (उदाहरण के लिए, http://play. google.com) के लिए डिफ़ॉल्ट गतिविधियां दी जा सकती हैं.ऐसा तब होता है, जब डिफ़ॉल्ट गतिविधि, डेटा यूआरआई के लिए ज़्यादा सटीक फ़िल्टर देती हो. उदाहरण के लिए, डेटा यूआरआई "http://www.android.com" की जानकारी देने वाला इंटेंट फ़िल्टर, "http://" के लिए ब्राउज़र फ़िल्टर से ज़्यादा सटीक होता है. डिवाइस पर लागू करने के लिए, उपयोगकर्ताओं को यूज़र इंटरफ़ेस देना ज़रूरी है, ताकि वे इंटेंट के लिए डिफ़ॉल्ट गतिविधि में बदलाव कर सकें.

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.2.3.5. ऐप्लिकेशन की डिफ़ॉल्ट सेटिंग

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

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

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

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

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

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

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

  • libc (C लाइब्रेरी)
  • libm (मैथ लाइब्रेरी)
  • C++ के लिए कम से कम सहायता
  • JNI इंटरफ़ेस
  • liblog (Android लॉगिंग)
  • libz (Zlib कंप्रेशन)
  • libdl (डाइनैमिक लिंकर)
  • libGLESv1_CM.so (OpenGL ES 1.0)
  • libGLESv2.so (OpenGL ES 2.0)
  • libGLESv3.so (OpenGL ES 3.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 के आने वाले वर्शन में, अन्य एबीआई के लिए सहायता उपलब्ध हो सकती है. अगर किसी डिवाइस पर पहले से तय किए गए किसी मौजूदा एबीआई का इस्तेमाल नहीं किया जा सकता, तो उसे किसी भी एबीआई के साथ काम करने की जानकारी नहीं देनी चाहिए.

ध्यान दें कि डिवाइस में लागू किए गए वर्शन में libGLESv3.so शामिल होना चाहिए. साथ ही, यह libGLESv2.so से लिंक होना चाहिए. डिवाइस में लागू किए गए ऐसे वर्शन जिनमें OpenGL ES 3.0 के साथ काम करने की सुविधा का एलान किया गया है, उनमें libGLESv2.so को OpenGL ES 2.0 फ़ंक्शन सिंबल के साथ-साथ OpenGL ES 3.0 फ़ंक्शन सिंबल भी एक्सपोर्ट करने चाहिए.

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

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

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

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

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

वेबव्यू कॉम्पोनेंट में, ज़्यादा से ज़्यादा HTML5 [रिसॉर्स, 11] के लिए सहायता शामिल होनी चाहिए.

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 एमबी
छोटा / सामान्य / बड़ा 400डीपीआई 96 एमबी
छोटा / सामान्य / बड़ा xxhdpi 128 एमबी
छोटा / सामान्य / बड़ा xxxhdpi 256 एमबी
xlarge mdpi 32 एमबी
xlarge tvdpi / hdpi 64 एमबी
xlarge xhdpi 128 एमबी
xlarge 400डीपीआई 192 एमबी
xlarge xxhdpi 256 एमबी
xlarge xxxhdpi 512 एमबी

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

3.8.1. लॉन्चर (होम स्क्रीन)

Android में एक लॉन्चर ऐप्लिकेशन (होम स्क्रीन) और तीसरे पक्ष के ऐप्लिकेशन शामिल होते हैं. इनकी मदद से, डिवाइस के लॉन्चर (होम स्क्रीन) को बदला जा सकता है. डिवाइस में लागू किए गए ऐसे तरीके जिनकी मदद से तीसरे पक्ष के ऐप्लिकेशन, डिवाइस की होम स्क्रीन को बदल सकते हैं, उन्हें प्लैटफ़ॉर्म की सुविधा android.software.home_screen के बारे में बताना होगा.

3.8.2. विजेट

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

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

3.8.3. सूचनाएं

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

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

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

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

3.8.4. खोजें

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

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

3.8.5. टोस्ट

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

3.8.6. थीम

Android, ऐप्लिकेशन के लिए "थीम" उपलब्ध कराता है, ताकि वे पूरी गतिविधि या ऐप्लिकेशन में स्टाइल लागू कर सकें.

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

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

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

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

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

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

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

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

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

3.8.9. इनपुट मैनेजमेंट

Android में इनपुट मैनेजमेंट और तीसरे पक्ष के इनपुट के तरीके के एडिटर के लिए सहायता शामिल है. डिवाइस पर तीसरे पक्ष के इनपुट तरीकों का इस्तेमाल करने की अनुमति देने वाले डिवाइसों को, प्लैटफ़ॉर्म की सुविधा के बारे में बताना होगाandroid.software.input_methods. साथ ही, Android SDK टूल के दस्तावेज़ में बताए गए IME API के साथ काम करना होगा.

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

3.8.10. लॉक स्क्रीन पर मीडिया को रिमोट कंट्रोल से चलाना

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

3.8.11. स्वप्न

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

3.8.12. जगह की जानकारी

जगह की जानकारी के मोड, सेटिंग में मौजूद जगह की जानकारी वाले मेन्यू में दिखाए जाने चाहिए [रिसॉर्स, 87]. Android 4.4 में पेश किए गए SettingInjectorService के ज़रिए दी जाने वाली जगह की जानकारी की सेवाओं को, जगह की जानकारी वाले उसी मेन्यू [संसाधन, 89] में दिखाया जाना चाहिए.

3.8.13. यूनिकोड

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

3.9. डिवाइस प्रबंधन

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

डिवाइस को लागू करने के लिए, डिवाइस एडमिन के फ़ंक्शन करने वाला कोई ऐप्लिकेशन पहले से इंस्टॉल हो सकता है. हालांकि, यह ज़रूरी है कि डिवाइस के मालिक के डिफ़ॉल्ट ऐप्लिकेशन [संसाधन, 84] के तौर पर, इस ऐप्लिकेशन को डिवाइस में पहले से सेट न किया गया हो.

3.10. सुलभता

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

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

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

3.11. लिखे गए शब्दों को सुनने की सुविधा

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

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

टाइप फ़ॉर्मैट / कोडेक एन्कोडर डिकोडर जानकारी फ़ाइल टाइप / कंटेनर फ़ॉर्मैट
ऑडियो MPEG-4 AAC प्रोफ़ाइल (AAC LC) माइक्रोफ़ोन हार्डवेयर वाले डिवाइसों के लागू होने के लिए ज़रूरी है और android.hardware.microphone तय करता है. ज़रूरी है मोनो/स्टीरियो/5.0/5.1* कॉन्टेंट के लिए, 8 से 48 किलोहर्ट्ज़ के स्टैंडर्ड सैंपलिंग रेट की सुविधा.
  • 3GPP (.3gp)
  • MPEG-4 (.mp4, .m4a)
  • ADTS रॉ AAC (.aac, Android 3.1 और उसके बाद के वर्शन में डिकोड करें, Android 4.0 और उसके बाद के वर्शन में एन्कोड करें, ADIF काम नहीं करता)
  • एमपीईजी-टीएस (.ts, इसमें वीडियो पर आगे-पीछे नहीं जाया जा सकता, Android 3.0 और उसके बाद के वर्शन)
MPEG-4 HE AAC Profile (AAC+) यह उन डिवाइसों के लिए ज़रूरी है जिनमें माइक्रोफ़ोन हार्डवेयर शामिल है और जिन्होंने android.hardware.microphone को तय किया है ज़रूरी है मोनो/स्टीरियो/5.0/5.1* कॉन्टेंट के लिए, 16 से 48 किलोहर्ट्ज़ के स्टैंडर्ड सैंपलिंग रेट के साथ काम करता है.
MPEG-4 HE AAC v2 प्रोफ़ाइल (बेहतर AAC+)   ज़रूरी है मोनो/स्टीरियो/5.0/5.1* कॉन्टेंट के लिए, 16 से 48 किलोहर्ट्ज़ के स्टैंडर्ड सैंपलिंग रेट के साथ काम करता है.
MPEG-4 ऑडियो ऑब्जेक्ट टाइप ER AAC ELD (बेहतर कम देरी वाला AAC) यह उन डिवाइसों के लिए ज़रूरी है जिनमें माइक्रोफ़ोन हार्डवेयर शामिल है और जिन्होंने android.hardware.microphone को तय किया है ज़रूरी है 16 से 48 किलोहर्ट्ज़ की स्टैंडर्ड सैंपलिंग रेट वाले मोनो/स्टीरियो कॉन्टेंट के साथ काम करता है.
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** (हैर्डवेयर की सीमा तक रेट).डिवाइसों में 8000, 16,000, और 44,100 हर्ट्ज़ फ़्रीक्वेंसी पर रॉ 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 4.3+)		 ज़रूरी है
(Android 2.3.3+)		   WebM (.webm) और Matroska (.mkv, Android 4.0+)***
VP9   ज़रूरी है
(Android 4.4+)		   WebM (.webm) और Matroska (.mkv, Android 4.0+)***
  • *ध्यान दें: सिर्फ़ 5.0/5.1 ऑडियो को डाउनमिक्स करना ज़रूरी है. दो से ज़्यादा चैनलों को रिकॉर्ड या रेंडर करना ज़रूरी नहीं है.
  • **ध्यान दें: 16-बिट लीनियर पीसीएम कैप्चर करना ज़रूरी है. 8-बिट लीनियर पीसीएम कैप्चर करना ज़रूरी नहीं है.
  • ***ध्यान दें: डिवाइस पर लागू किए गए एपीआई, Matroska WebM फ़ाइलें लिखने की सुविधा के साथ काम करने चाहिए.
  • ****ध्यान दें: वेब वीडियो स्ट्रीमिंग और वीडियो कॉन्फ़्रेंस की सेवाओं की अच्छी क्वालिटी के लिए, डिवाइस में ऐसे हार्डवेयर VP8 कोडेक का इस्तेमाल किया जाना चाहिए जो [संसाधन, 86] में दी गई ज़रूरी शर्तों को पूरा करता हो.

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

Android डिवाइस में पीछे की ओर वाला कैमरा होने पर और android.hardware.camera का एलान करने पर, डिवाइस में 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 केबीपीएस

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

  एसडी (कम क्वालिटी) एसडी (अच्छी क्वालिटी) एचडी 720 पिक्सल
(जब हार्डवेयर काम करता हो)		 एचडी 1080 पिक्सल
(जब हार्डवेयर काम करता हो)
वीडियो रिज़ॉल्यूशन 320 x 180 पिक्सल 640 x 360 पिक्सल 1280 x 720 पिक्सल 1920 x 1080 पिक्सल
वीडियो फ़्रेम रेट 30 फ़्रेम प्रति सेकंड 30 फ़्रेम प्रति सेकंड 30 फ़्रेम प्रति सेकंड 30 फ़्रेम प्रति सेकंड
वीडियो बिटरेट 800 केबीपीएस 2 एमबीपीएस 4 एमबीपीएस 10 एमबीपीएस

5.3. वीडियो डिकोड करना

Android डिवाइसों पर, VP8, VP9, और H.264 वीडियो डिकोडिंग प्रोफ़ाइलों का इस्तेमाल किया जा सकता है. डिवाइस पर लागू किए गए वर्शन में, VP8, VP9, और H.264 कोडेक के लिए, एक ही स्ट्रीम में वीडियो रिज़ॉल्यूशन को डाइनैमिक तरीके से स्विच करने की सुविधा भी होनी चाहिए.

  एसडी (कम क्वालिटी) एसडी (अच्छी क्वालिटी) एचडी 720 पिक्सल
(जब हार्डवेयर काम करता हो)		 एचडी 1080 पिक्सल
(जब हार्डवेयर काम करता हो)
वीडियो रिज़ॉल्यूशन 320 x 180 पिक्सल 640 x 360 पिक्सल 1280 x 720 पिक्सल 1920 x 1080 पिक्सल
वीडियो फ़्रेम रेट 30 फ़्रेम प्रति सेकंड 30 फ़्रेम प्रति सेकंड 30 फ़्रेम प्रति सेकंड 30 फ़्रेम प्रति सेकंड
वीडियो बिटरेट 800 केबीपीएस 2 एमबीपीएस 8 एमबीपीएस 20 एमबीपीएस

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

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

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

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

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

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

  • STREAM_RING
  • STREAM_ALARM
  • STREAM_NOTIFICATION

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

अगर प्लैटफ़ॉर्म पर, बोली पहचानने के लिए, शोर कम करने वाली तकनीकें काम करती हैं, तो android.media.audiofx.NoiseSuppressor एपीआई से इस असर को कंट्रोल किया जा सकता है. इसके अलावा, शोर कम करने की सुविधा के असर के ब्यौरे के लिए "uuid" फ़ील्ड में, शोर कम करने की टेक्नोलॉजी के हर लागू होने की यूनीक पहचान होनी चाहिए.

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

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

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

  • "आउटपुट में लगने वाला समय", उस समय के अंतर को कहते हैं जो किसी ऐप्लिकेशन के पीसीएम कोड वाले डेटा के फ़्रेम को लिखने और उससे जुड़ी आवाज़ को किसी बाहरी व्यक्ति के सुनने या ट्रांसड्यूसर के ज़रिए सुनने में लगता है
  • "ऑडियो आउटपुट में लगने वाला कुल समय", पहले फ़्रेम के लिए आउटपुट में लगने वाले समय को कहते हैं. ऐसा तब होता है, जब अनुरोध से पहले ऑडियो आउटपुट सिस्टम बंद हो और काम न कर रहा हो
  • "लगातार आउटपुट में लगने वाला समय", डिवाइस पर ऑडियो चलने के बाद, अगले फ़्रेम के लिए आउटपुट में लगने वाले समय को कहते हैं
  • "इनपुट लेटेंसी", डिवाइस पर किसी बाहरी साउंड के दिखने और ऐप्लिकेशन के उससे जुड़े PCM कोड वाले डेटा के फ़्रेम को पढ़ने के बीच का समय होता है
  • "कोल्ड इनपुट लेटेंसी" को, पहले फ़्रेम के लिए इनपुट लेटेंसी और इनपुट के लिए बर्बाद हुए समय के योग के तौर पर परिभाषित किया जाता है. ऐसा तब होता है, जब अनुरोध से पहले ऑडियो इनपुट सिस्टम इस्तेमाल में न हो और बंद हो
  • "लगातार इनपुट में लगने वाला समय", अगले फ़्रेम के लिए इनपुट में लगने वाले समय को कहते हैं. ऐसा तब होता है, जब डिवाइस पहले से ही ऑडियो कैप्चर कर रहा हो
  • "OpenSL ES PCM बफ़र क्यू एपीआई", Android NDK में PCM से जुड़े OpenSL ES एपीआई का सेट है; NDK_root देखें/docs/opensles/index.html

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

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

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

सेक्शन 7.2.5 के मुताबिक, डिवाइस में माइक्रोफ़ोन हार्डवेयर को शामिल नहीं किया जा सकता.

डिवाइस में माइक्रोफ़ोन हार्डवेयर शामिल है और android.hardware.microphone के लिए इनपुट ऑडियो के इंतज़ार की अवधि से जुड़ी इन ज़रूरी शर्तों को पूरा करना चाहिए:

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

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

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

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

6. डेवलपर टूल और विकल्पों के साथ काम करने की सुविधा

6.1. डेवलपर टूल

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

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

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

6.2. डेवलपर के लिए सेटिंग और टूल

Android में, डेवलपर के लिए ऐप्लिकेशन डेवलपमेंट से जुड़ी सेटिंग कॉन्फ़िगर करने की सुविधा शामिल है. ऐप्लिकेशन डेवलपमेंट से जुड़ी सेटिंग दिखाने के लिए, डिवाइस पर लागू किए गए टूल को android.settings.APPLICATION_DEVELOPMENT_SETTINGS इंटेंट का पालन करना होगा [संसाधन, 77]. Android के अपस्ट्रीम वर्शन में, डिफ़ॉल्ट रूप से 'डेवलपर के लिए सेटिंग और टूल' मेन्यू छिपा होता है. उपयोगकर्ता, सेटिंग > डिवाइस के बारे में जानकारी > बिल्ड नंबर मेन्यू आइटम पर सात (7) बार दबाकर, 'डेवलपर के लिए सेटिंग और टूल' मेन्यू को लॉन्च कर सकते हैं. डिवाइस में लागू किए गए बदलावों से, डेवलपर के लिए सेटिंग और टूल का एक जैसा अनुभव मिलना चाहिए. खास तौर पर, डिवाइस में लागू करने के लिए, डिफ़ॉल्ट रूप से डेवलपर के लिए सेटिंग और टूल को छिपाना ज़रूरी है. साथ ही, डेवलपर के लिए सेटिंग और टूल को चालू करने का ऐसा तरीका देना ज़रूरी है जो Android के अपस्ट्रीम वर्शन में लागू करने के तरीके से मेल खाता हो.

6.2.1. एक्सपेरिमेंट वाली सेटिंग

Android 4.4 में ART की सुविधा जोड़ी गई है. यह Android का एक एक्सपेरिमेंटल रनटाइम है. इसकी झलक देखने के लिए, 'डेवलपर के लिए सेटिंग और टूल' मेन्यू में जाएं. डिवाइस में लागू किए गए वर्शन में ART (libart.so) शामिल होना चाहिए. साथ ही, डेवलपर के विकल्पों से ड्यूअल बूट की सुविधा काम करनी चाहिए. हालांकि, डिफ़ॉल्ट रनटाइम के तौर पर Dalvik (libdvm.so) का इस्तेमाल करना ज़रूरी है.

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

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

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

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

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

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

Android में ऐसी सुविधाएं शामिल हैं जो डिवाइस के हिसाब से, ऐप्लिकेशन एसेट और यूज़र इंटरफ़ेस (यूआई) लेआउट को अपने-आप अडजस्ट कर देती हैं. इससे यह पक्का होता है कि तीसरे पक्ष के ऐप्लिकेशन, अलग-अलग हार्डवेयर कॉन्फ़िगरेशन [रिसॉर्स, 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 डीपी ('छोटा') होना चाहिए
  • जिन डिवाइसों की स्क्रीन का साइज़ 'सामान्य' है उनकी स्क्रीन का साइज़ कम से कम 480 dp x 320 dp होना चाहिए
  • जिन डिवाइसों की स्क्रीन का साइज़ 'बड़ी' के तौर पर रिपोर्ट किया गया है उनकी स्क्रीन का साइज़ कम से कम 640 डीपी x 480 डीपी होना चाहिए
  • जिन डिवाइसों की स्क्रीन का साइज़ 'बहुत बड़ी' है उनकी स्क्रीन का साइज़ कम से कम 960 डीपी x 720 डीपी होना चाहिए

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

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

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

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

आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) की वैल्यू 1.3333 (4:3) से 1.86 (लगभग 16:9) के बीच होनी चाहिए

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

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

  • 120 डीपीआई, जिसे 'ldpi' कहा जाता है
  • 160 डीपीआई, जिसे 'mdpi' कहा जाता है
  • 213 डीपीआई, जिसे 'tvdpi' कहा जाता है
  • 240 डीपीआई, जिसे 'hdpi' कहा जाता है
  • 320 डीपीआई, जिसे 'xhdpi' कहा जाता है
  • 400 डीपीआई, जिसे '400 डीपीआई' कहा जाता है
  • 480 डीपीआई, जिसे 'xxhdpi' कहा जाता है
  • 640 डीपीआई, जिसे 'xxxhdpi' कहा जाता है
डिवाइस पर लागू होने वाले 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 के दस्तावेज़ों में बताया गया है. डिवाइस पर लागू किए गए वर्शन में, OpenGL ES 3.0 की सुविधा काम करनी चाहिए. हालांकि, यह ज़रूरी है कि डिवाइस पर OpenGL ES 3.0 काम करता हो. डिवाइस पर लागू किए गए टूल, Android Renderscript के साथ भी काम करने चाहिए. इस बारे में Android SDK के दस्तावेज़ [रिसॉर्स, 8] में बताया गया है.

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

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

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

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

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

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

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

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

Android में EGL_ANDROID_RECORDABLE के लिए सहायता शामिल है. यह एक EGLConfig एट्रिब्यूट है, जो यह बताता है कि EGLConfig, ANativeWindow में रेंडरिंग की सुविधा देता है या नहीं. ANativeWindow, वीडियो में इमेज रिकॉर्ड करता है. डिवाइस पर लागू किए गए टूल, EGL_ANDROID_RECORDABLE एक्सटेंशन के साथ काम करने चाहिए [संसाधन, 79].

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7.1.8. बाहरी डिसप्ले

Android में सेकंडरी डिसप्ले की सुविधा शामिल है, ताकि मीडिया शेयर करने की सुविधाएं चालू की जा सकें. साथ ही, बाहरी डिसप्ले को ऐक्सेस करने के लिए डेवलपर एपीआई भी उपलब्ध हैं. अगर किसी डिवाइस में, वायर, वायरलेस या डिसप्ले के लिए अतिरिक्त कनेक्शन के ज़रिए, बाहरी डिसप्ले से कनेक्ट करने की सुविधा है, तो डिवाइस में डिसप्ले मैनेजर एपीआई को लागू करना ज़रूरी है. इस बारे में Android SDK टूल के दस्तावेज़ [रिसॉर्स, 75] में बताया गया है. सुरक्षित वीडियो आउटपुट और सुरक्षित प्लैटफ़ॉर्म के साथ काम करने वाले डिवाइसों को Display.FLAG_SECURE के साथ काम करने की जानकारी देनी होगी. खास तौर पर, जिन डिवाइसों पर Display.FLAG_SECURE की सुविधा काम करती है उनके लिए, HDCP 2.x या उसके बाद के वर्शन वाले Miracast वायरलेस डिसप्ले या HDCP 1.2 या उसके बाद के वर्शन वाले वायर्ड डिसप्ले का इस्तेमाल करना ज़रूरी है. अपस्ट्रीम Android ओपन सोर्स में, वायरलेस (Miracast) और वायर्ड (एचडीएमआई) डिसप्ले के लिए सहायता शामिल है. ये डिसप्ले, इस ज़रूरी शर्त को पूरा करते हैं.

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

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

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

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

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

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

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

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

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

डिवाइस में किसी तरह का पॉइंटर इनपुट सिस्टम (माउस जैसा या टच) होना चाहिए. हालांकि, अगर किसी डिवाइस पर, पॉइंटर इनपुट सिस्टम काम नहीं करता है, तो उसे android.hardware.touchscreen या android.hardware.faketouch सुविधा के कॉन्स्टेंट की रिपोर्ट नहीं करनी चाहिए. ऐसे डिवाइसों पर लागू करने के लिए, जिनमें पॉइंटर इनपुट सिस्टम शामिल है:

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

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

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

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

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

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

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

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

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

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

7.3. सेंसर

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

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

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

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

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

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

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

  • यह 120 हर्ट्ज़ या इससे ज़्यादा फ़्रेम रेट पर इवेंट डिलीवर कर सकता है. ध्यान दें कि Android 4.4 के लिए, ऊपर बताई गई ऐक्सेलेरोमीटर फ़्रीक्वेंसी को "चाहिए" के तौर पर बताया गया है. हालांकि, आने वाले वर्शन के लिए, 'काम करने की शर्तों' में इन फ़्रीक्वेंसी को "ज़रूरी है" के तौर पर बदलने का प्लान है. इसका मतलब है कि Android में ये स्टैंडर्ड इस्तेमाल करना ज़रूरी नहीं है. हालांकि, आने वाले वर्शन में इनका इस्तेमाल करना ज़रूरी होगा. Android चलाने वाले मौजूदा और नए डिवाइसों को Android में इन ज़रूरी शर्तों को पूरा करने का सुझाव दिया जाता है, ताकि वे आने वाले समय में प्लैटफ़ॉर्म के रिलीज़ किए जाने वाले वर्शन पर अपग्रेड कर सकें
  • 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 डिग्री) तक ऑरिएंटेशन में हुए बदलावों को मेज़र कर सकता हो.
  • 200 हर्ट्ज़ या उससे ज़्यादा पर इवेंट डिलीवर करने में सक्षम होना चाहिए. ध्यान दें कि ऊपर बताई गई, Android 4.4 के लिए जियोस्कोप फ़्रीक्वेंसी को "चाहिए" के तौर पर बताया गया है. हालांकि, आने वाले वर्शन के लिए, काम करने की शर्तों में इन फ़्रीक्वेंसी को "ज़रूरी है" के तौर पर बदलने का प्लान है. इसका मतलब है कि Android में ये स्टैंडर्ड इस्तेमाल करना ज़रूरी नहीं है. हालांकि, आने वाले वर्शन में इनका इस्तेमाल करना ज़रूरी होगा. Android चलाने वाले मौजूदा और नए डिवाइसों को इन ज़रूरी शर्तों को पूरा करने का सुझाव दिया जाता है, ताकि वे आने वाले समय में प्लैटफ़ॉर्म के रिलीज़ किए जाने वाले वर्शन पर अपग्रेड कर सकें.
  • सटीक जानकारी देने के लिए, 12 बिट या उससे ज़्यादा की ज़रूरत होती है
  • हर हर्ट्ज (हर हर्ट्ज में वैरिएंस या rad^2 / s) के लिए, वैरिएंस 1e-7 rad^2 / s^2 से ज़्यादा नहीं होना चाहिए. वैरिएंस को सैंपलिंग रेट के हिसाब से बदलने की अनुमति है, लेकिन इसे इस वैल्यू के हिसाब से सीमित रखना चाहिए. दूसरे शब्दों में, अगर 1 हर्ट्ज़ सैंपलिंग रेट पर, घुमाव की दर का मेज़रमेंट किया जाता है, तो यह 1e-7 rad^2/s^2 से ज़्यादा नहीं होना चाहिए.
  • टाइमस्टैंप, हार्डवेयर इवेंट के होने के समय के जितना हो सके उतना करीब होने चाहिए. लगातार होने वाली देरी को हटाना ज़रूरी है.

7.3.5. बैरोमीटर

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

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

7.3.6. Thermometer

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

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

7.3.7. फ़ोटोमीटर

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

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

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

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

7.4.1. टेलीफ़ोनी

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

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

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

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

डिवाइस में लागू करने के लिए, मल्टीकास्ट एपीआई को SDK टूल के दस्तावेज़ [संसाधन, 62] में बताए गए तरीके से लागू करना ज़रूरी है. डिवाइस में मल्टीकास्ट डीएनएस (mDNS) की सुविधा काम करती हो, इसके लिए ज़रूरी है कि डिवाइस में Wi-Fi की सुविधा काम करती हो. डिवाइस के लागू होने पर, mDNS पैकेट (224.0.0.251) को कभी भी फ़िल्टर नहीं करना चाहिए.

7.4.2.1. Wi-Fi Direct

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

  • डिवाइस पर सामान्य वाई-फ़ाई की सुविधा काम करती हो
  • वाई-फ़ाई और Wi-Fi Direct, दोनों का एक साथ इस्तेमाल किया जा सकता है

7.4.2.2. वाई-फ़ाई टनल वाला डायरेक्ट लिंक सेटअप करना

डिवाइस में लागू किए गए वर्शन में, Wi-Fi टनल किए गए डायरेक्ट लिंक सेटअप (TDLS) के लिए सहायता शामिल होनी चाहिए. इस बारे में Android SDK टूल के दस्तावेज़ [संसाधन, 85] में बताया गया है. अगर किसी डिवाइस में TDLS की सुविधा शामिल है और WiFiManager API की मदद से TDLS चालू है, तो डिवाइस:

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

7.4.3. ब्लूटूथ

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

जिन डिवाइसों में ब्लूटूथ स्मार्ट या स्मार्ट रेडी डिवाइसों के साथ कम्यूनिकेशन की सुविधा चालू करने के लिए, ब्लूटूथ जीएटीटी (जनरल एट्रिब्यूट प्रोफ़ाइल) का इस्तेमाल किया जाता है उन्हें SDK दस्तावेज़ में बताए गए तरीके से, जीएटीटी पर आधारित ब्लूटूथ एपीआई चालू करना होगा. साथ ही, हार्डवेयर की सुविधा के तौर पर android.hardware.bluetooth_le [संसाधन, 42] का एलान करना होगा.

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 के इस वर्शन पर काम करने वाले मौजूदा और नए डिवाइसों को अभी इन ज़रूरी शर्तों को पूरा करने का सुझाव दिया जाता है, ताकि वे आने वाले समय में प्लैटफ़ॉर्म के रिलीज़ किए जाने वाले नए वर्शन पर अपग्रेड कर सकें.
    • NfcV (ISO 15693)
  • यह ज़रूरी है कि यह डिवाइस, यहां दिए गए पीयर-टू-पीयर स्टैंडर्ड और प्रोटोकॉल के ज़रिए डेटा भेज और पा सके:
    • ISO 18092
    • LLCP 1.0 (NFC फ़ोरम ने तय किया है)
    • SDP 1.0 (एनएफ़सी फ़ोरम ने तय किया है)
    • एनडीएफ़ई पुश प्रोटोकॉल [संसाधन, 43]
    • SNEP 1.0 (NFC फ़ोरम के मुताबिक)
  • इसमें Android Beam की सुविधा शामिल होनी चाहिए [संसाधन, 65]:
    • SNEP डिफ़ॉल्ट सर्वर को लागू करना ज़रूरी है. डिफ़ॉल्ट SNEP सर्वर से मिले मान्य एनडीएफ़ मैसेज, android.nfc.ACTION_NDEF_DISCOVERED इंटेंट का इस्तेमाल करके, ऐप्लिकेशन को भेजे जाने चाहिए. सेटिंग में जाकर Android Beam को बंद करने पर, इनकमिंग एनडीएफ़ई मैसेज भेजने की सुविधा बंद नहीं होनी चाहिए.
    • डिवाइस में लागू करने के लिए, android.settings.NFCSHARING_SETTINGS इंटेंट का पालन करना ज़रूरी है, ताकि एनएफ़सी शेयर करने की सेटिंग [संसाधन, 67] दिखाई जा सकें.
    • एनपीपी सर्वर को लागू करना ज़रूरी है. एनपीपी सर्वर को मिले मैसेज को, एसएनईपी डिफ़ॉल्ट सर्वर की तरह ही प्रोसेस किया जाना चाहिए.
    • Android Beam चालू होने पर, SNEP क्लाइंट को लागू करना ज़रूरी है. साथ ही, डिफ़ॉल्ट SNEP सर्वर पर आउटबाउंड P2P NDEF भेजने की कोशिश करनी चाहिए. अगर कोई डिफ़ॉल्ट एसएनईपी सर्वर नहीं मिलता है, तो क्लाइंट को किसी एनपीपी सर्वर पर भेजने की कोशिश करनी चाहिए.
    • फ़ोरग्राउंड गतिविधियों को आउटबाउंड P2P NDEF मैसेज सेट करने की अनुमति देनी चाहिए. इसके लिए, ये फ़ंक्शन इस्तेमाल करें: android.nfc.NfcAdapter.setNdefPushMessage, android.nfc.NfcAdapter.setNdefPushMessageCallback, और android.nfc.NfcAdapter.enableForegroundNdefPush.
    • आउटबाउंड पी2पी एनडीएफ़ मैसेज भेजने से पहले, 'टच करके बीम करें' जैसे जेस्चर या स्क्रीन पर पुष्टि करने की सुविधा का इस्तेमाल करना चाहिए.
    • Android Beam की सुविधा डिफ़ॉल्ट रूप से चालू होनी चाहिए
    • अगर डिवाइस पर ब्लूटूथ ऑब्जेक्ट पुश प्रोफ़ाइल काम करती है, तो यह ज़रूरी है कि डिवाइस पर एनएफ़सी कनेक्शन को ब्लूटूथ पर ट्रांसफ़र करने की सुविधा काम करती हो. डिवाइस में android.nfc.NfcAdapter.setBeamPushUris का इस्तेमाल करते समय, ब्लूटूथ से कनेक्शन को हैंडओवर करने की सुविधा होनी चाहिए. इसके लिए, NFC फ़ोरम के "कनेक्शन हैंडओवर वर्शन 1.2" [संसाधन, 60] और "एनएफ़सी वर्शन 1.0 का इस्तेमाल करके, ब्लूटूथ से सुरक्षित तरीके से आसानी से जोड़ना" [संसाधन, 61] स्पेसिफ़िकेशन लागू करें. इस तरह के लागू करने के लिए, "urn:nfc:sn:handover" सेवा के नाम के साथ, डिवाइस बदलने की LLCP सेवा को लागू करना ज़रूरी है. ऐसा इसलिए, ताकि एनएफ़सी के ज़रिए, डिवाइस बदलने का अनुरोध/चुने गए रिकॉर्ड को एक्सचेंज किया जा सके. साथ ही, ब्लूटूथ डेटा को ट्रांसफ़र करने के लिए, ब्लूटूथ ऑब्जेक्ट पुश प्रोफ़ाइल का इस्तेमाल करना ज़रूरी है. लेगसी वजहों (Android 4.1 डिवाइसों के साथ काम करने के लिए) से, एनएफ़सी के ज़रिए रिकॉर्ड को चुनने/हैंडलओवर के अनुरोध को एक्सचेंज करने के लिए, SNEP GET अनुरोध अब भी स्वीकार किए जाने चाहिए. हालांकि, कनेक्शन को एक से दूसरे डिवाइस पर ट्रांसफ़र करने के लिए, इसे लागू करने वाले डिवाइस को खुद से SNEP GET अनुरोध नहीं भेजने चाहिए.
  • एनएफ़सी डिस्कवरी मोड में, काम करने वाली सभी टेक्नोलॉजी के लिए पोल करना ज़रूरी है.
  • डिवाइस के चालू होने पर, स्क्रीन चालू और लॉक-स्क्रीन अनलॉक होने पर, डिवाइस को एनएफ़सी डिस्कवरी मोड में होना चाहिए.

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

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

  • android.hardware.nfc.hce सुविधा के कॉन्स्टेंट की जानकारी देना ज़रूरी है
  • Android SDK टूल में बताए गए तरीके के मुताबिक, एनएफ़सी एचसीई एपीआई के साथ काम करना चाहिए [संसाधन, 90]

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

ध्यान दें कि Android में इन 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 एनएफ़सी एपीआई को बिना किसी काम के लागू करना चाहिए.

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

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

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

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

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

7.4.6. समन्वयन सेटिंग

डिवाइस पर लागू करने के लिए, डिफ़ॉल्ट रूप से अपने-आप सिंक होने की मुख्य सेटिंग चालू होनी चाहिए, ताकि getMasterSyncAutomatically() तरीका "सही" [संसाधन, 88] दिखाए.

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 में कैमरा एपीआई, सामने वाले कैमरे के लिए खास तौर पर काम करता है. साथ ही, डिवाइस में एपीआई को इस तरह कॉन्फ़िगर नहीं किया जाना चाहिए कि वह सामने वाले कैमरे को डिफ़ॉल्ट रूप से पीछे वाले कैमरे के तौर पर इस्तेमाल करे. भले ही, डिवाइस में सिर्फ़ यही कैमरा हो.
  • इसमें सेक्शन 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 SDK दस्तावेज़ [संसाधन, 51] में शामिल Camera API को पूरी तरह से लागू करना ज़रूरी है. भले ही, डिवाइस में हार्डवेयर ऑटोफ़ोकस या अन्य सुविधाएं हों या नहीं. उदाहरण के लिए, जिन कैमरों में ऑटोफ़ोकस की सुविधा नहीं होती है उन्हें भी रजिस्टर किए गए किसी भी android.hardware.Camera.AutoFocusCallback इंस्टेंस को कॉल करना होगा. भले ही, ऑटोफ़ोकस की सुविधा न होने वाले कैमरे के लिए, ऐसा करना ज़रूरी नहीं है. ध्यान दें कि यह शर्त, सामने वाले कैमरे पर भी लागू होती है. उदाहरण के लिए, ज़्यादातर सामने वाले कैमरे ऑटोफ़ोकस की सुविधा के साथ काम नहीं करते. इसके बावजूद, एपीआई कॉलबैक को ऊपर बताए गए तरीके से "नकली" बनाना ज़रूरी है.

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

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

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

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

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

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

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

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

जिन डिवाइसों में कर्नेल और यूज़रस्पेस के लिए 512 एमबी से कम मेमोरी उपलब्ध है उनके लिए, ActivityManager.isLowRamDevice() के लिए "सही" वैल्यू दिखाना ज़रूरी है.

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

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

7.6.2. शेयर किया गया बाहरी स्टोरेज

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

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

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

डिवाइस में, उपयोगकर्ता के ऐक्सेस के लिए, रिमूवेबल स्टोरेज का हार्डवेयर हो सकता है. जैसे, Secure Digital कार्ड. इसके अलावा, डिवाइस में लागू किए गए ऐप्लिकेशन के लिए, डिवाइस का इंटरनल (हटाया नहीं जा सकने वाला) स्टोरेज, शेयर किया गया स्टोरेज के तौर पर तय किया जा सकता है. अपस्ट्रीम Android Open Source Project में, शेयर किए गए बाहरी स्टोरेज एपीआई के लिए डिवाइस के इंटरनल स्टोरेज का इस्तेमाल करने वाला एक तरीका शामिल है. डिवाइस पर लागू करने के लिए, इस कॉन्फ़िगरेशन और सॉफ़्टवेयर को लागू करने का तरीका इस्तेमाल किया जाना चाहिए.

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

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

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

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

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

7.7. यूएसबी

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

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

  • पोर्ट को स्टैंडर्ड यूएसबी-ए पोर्ट वाले यूएसबी होस्ट से कनेक्ट किया जा सकता हो
  • डिवाइस के साइड में, पोर्ट में माइक्रो यूएसबी फ़ॉर्म फ़ैक्टर का इस्तेमाल किया जाना चाहिए. Android चलाने वाले मौजूदा और नए डिवाइसों को Android में इन ज़रूरी शर्तों को पूरा करने का सुझाव दिया जाता है, ताकि वे आने वाले समय में प्लैटफ़ॉर्म के रिलीज़ किए जाने वाले वर्शन पर अपग्रेड कर सकें
  • पोर्ट, किनारे के बीच में होना चाहिए. डिवाइस में चार्जिंग पोर्ट को, डिवाइस के नीचे (सामान्य ओरिएंटेशन के हिसाब से) या सभी ऐप्लिकेशन (होम स्क्रीन के साथ) के लिए, स्क्रीन रोटेशन की सुविधा चालू करके दिखाया जाना चाहिए. इससे, डिवाइस के नीचे पोर्ट होने पर, डिसप्ले सही तरीके से दिखता है. Android चलाने वाले मौजूदा और नए डिवाइसों को Android में इन ज़रूरी शर्तों को पूरा करने का सुझाव दिया जाता है, ताकि वे आने वाले समय में प्लैटफ़ॉर्म के रिलीज़ किए जाने वाले वर्शन पर अपग्रेड कर सकें.
  • अगर डिवाइस में अन्य पोर्ट (जैसे कि नॉन-यूएसबी चार्जिंग पोर्ट) हैं, तो वे माइक्रो-यूएसबी पोर्ट के उसी किनारे पर होने चाहिए
  • यह ज़रूरी है कि डिवाइस से कनेक्ट किए गए होस्ट को, यूएसबी मास स्टोरेज या मीडिया ट्रांसफ़र प्रोटोकॉल का इस्तेमाल करके, शेयर किए गए स्टोरेज वॉल्यूम का कॉन्टेंट ऐक्सेस करने की अनुमति दी जाए
  • इसमें Android Open Accessory API और स्पेसिफ़िकेशन को लागू करना ज़रूरी है, जैसा कि Android SDK के दस्तावेज़ में बताया गया है. साथ ही, इसमें हार्डवेयर की सुविधा android.hardware.usb.accessory के साथ काम करने की जानकारी देना ज़रूरी है [संसाधन, 52]
  • यह Android SDK टूल के दस्तावेज़ [संसाधन, 66] में बताए गए तरीके से, यूएसबी ऑडियो क्लास को लागू करना चाहिए
  • इसमें यूएसबी बैटरी चार्जिंग स्पेसिफ़िकेशन [संसाधन, 64] के लिए सहायता लागू की जानी चाहिए Android पर काम करने वाले मौजूदा और नए डिवाइसों को इन ज़रूरी शर्तों को पूरा करने का बहुत ज़्यादा सुझाव दिया जाता है ताकि वे आने वाले समय में प्लैटफ़ॉर्म के रिलीज़ पर अपग्रेड कर सकें
  • यूएसबी स्टैंडर्ड डिवाइस डिस्क्रिप्टर में iSerialNumber की वैल्यू, android.os.Build.SERIAL की वैल्यू के बराबर होनी चाहिए.

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

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

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

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

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

मेट्रिक परफ़ॉर्मेंस थ्रेशोल्ड टिप्पणियां
ऐप्लिकेशन लॉन्च होने का समय यहां दिए गए ऐप्लिकेशन, तय समय के अंदर लॉन्च होने चाहिए.
  • ब्राउज़र: 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 की अनुमति (जैसे, कैमरा, जीपीएस वगैरह) की ज़रूरत है, तो वैकल्पिक रनटाइम को उपयोगकर्ता को यह बताना होगा कि ऐप्लिकेशन उस संसाधन को ऐक्सेस कर पाएगा. अगर रनटाइम एनवायरमेंट इस तरीके से ऐप्लिकेशन की सुविधाओं को रिकॉर्ड नहीं करता है, तो रनटाइम एनवायरमेंट को उस रनटाइम का इस्तेमाल करके किसी भी ऐप्लिकेशन को इंस्टॉल करते समय, रनटाइम के पास मौजूद सभी अनुमतियों की सूची बनानी होगी.

9.5. एक डिवाइस पर कई लोगों के काम करने की सुविधा

Android में एक डिवाइस पर कई लोगों के काम करने की सुविधा शामिल है. साथ ही, इसमें उपयोगकर्ता को पूरी तरह से अलग करने की सुविधा भी मिलती है [संसाधन, 70].

डिवाइस पर एक से ज़्यादा उपयोगकर्ताओं के लिए सहायता की सुविधा लागू करने के लिए, ये ज़रूरी शर्तें पूरी करनी होंगी [संसाधन, 71]:

  • फ़िलहाल, एक से ज़्यादा उपयोगकर्ताओं वाले डिवाइसों पर, टेलीफ़ोन एपीआई के काम करने का तरीका तय नहीं है. इसलिए, डिवाइस में android.hardware.telephony एपीआई का इस्तेमाल करने पर, एक से ज़्यादा उपयोगकर्ताओं के लिए इस्तेमाल करने की सुविधा चालू नहीं की जानी चाहिए.
  • डिवाइस के हर उपयोगकर्ता के लिए, सुरक्षा का ऐसा मॉडल लागू करना ज़रूरी है जो Android प्लैटफ़ॉर्म के सुरक्षा मॉडल के मुताबिक हो. इस मॉडल के बारे में, एपीआई में सुरक्षा और अनुमतियों के रेफ़रंस दस्तावेज़ में बताया गया है [संसाधन, 54]
  • Android में, प्रतिबंधित प्रोफ़ाइलों के लिए सहायता शामिल है. इस सुविधा की मदद से, डिवाइस के मालिक अन्य उपयोगकर्ताओं और उनके ऐक्सेस को मैनेज कर सकते हैं. पाबंदी वाली प्रोफ़ाइलों की मदद से, डिवाइस के मालिक अन्य उपयोगकर्ताओं के लिए अलग-अलग एनवायरमेंट तुरंत सेट अप कर सकते हैं. साथ ही, उन एनवायरमेंट में उपलब्ध ऐप्लिकेशन पर ज़्यादा सटीक पाबंदियां भी लगा सकते हैं. डिवाइस पर एक से ज़्यादा उपयोगकर्ताओं के लिए सुविधाएं उपलब्ध कराने के लिए, पाबंदी वाली प्रोफ़ाइलों के लिए भी सुविधाएं उपलब्ध कराना ज़रूरी है. अपस्ट्रीम Android Open Source Project में, इस ज़रूरी शर्त को पूरा करने वाला एक तरीका शामिल है.

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

9.6. प्रीमियम एसएमएस की चेतावनी

Android में, उपयोगकर्ताओं को किसी भी प्रीमियम एसएमएस के भेजे जाने पर चेतावनी देने की सुविधा शामिल है [संसाधन, 73] . प्रीमियम मैसेज, ऐसे टेक्स्ट मैसेज होते हैं जिन्हें मोबाइल और इंटरनेट सेवा देने वाली कंपनी के साथ रजिस्टर की गई किसी सेवा पर भेजा जाता है. इन मैसेज के लिए, उपयोगकर्ता से शुल्क लिया जा सकता है. जिन डिवाइसों पर android.hardware.telephony की सुविधा काम करती है उन्हें डिवाइस में मौजूद /data/misc/sms/codes.xml फ़ाइल में बताई गई रेगुलर एक्सप्रेशन से पहचाने गए नंबरों पर एसएमएस भेजने से पहले, उपयोगकर्ताओं को चेतावनी देनी होगी. अपस्ट्रीम Android Open Source Project, इस ज़रूरी शर्त को पूरा करने वाला तरीका उपलब्ध कराता है.

9.7. कर्नेल की सुरक्षा से जुड़ी सुविधाएं

Android सैंडबॉक्स में ऐसी सुविधाएं शामिल हैं जो बेहतर सुरक्षा वाले Linux (SELinux) के ज़रूरी ऐक्सेस कंट्रोल (MAC) सिस्टम और Linux कर्नेल की अन्य सुरक्षा सुविधाओं का इस्तेमाल कर सकती हैं. SELinux या सुरक्षा से जुड़ी कोई अन्य सुविधा, अगर इसे Android फ़्रेमवर्क के नीचे लागू किया गया है:

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

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

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

  • यह SELinux की ऐसी नीति के साथ काम करना चाहिए जिससे हर डोमेन के लिए, SELinux मोड को इनके साथ सेट किया जा सके:
    • Android Open Source के अपस्ट्रीम में लागू होने वाले डोमेन (जैसे कि installd, netd, और vold), ज़रूर लागू होने वाले मोड में होने चाहिए
    • तीसरे पक्ष के ऐप्लिकेशन के लिए डोमेन, अनुमति वाले मोड में बने रहना चाहिए, ताकि यह पक्का किया जा सके कि वे ऐप्लिकेशन काम करते रहें
  • यह डिवाइस पर /sepolicy फ़ाइल से नीति को लोड करनी चाहिए
  • यह ज़रूरी है कि यह SELinux नीति फ़ाइल के डाइनैमिक अपडेट के साथ काम करे. इसके लिए, सिस्टम इमेज को अपडेट करने की ज़रूरत नहीं होती
  • यह नीति के उल्लंघनों को लॉग करना चाहिए. ऐसा करने से, ऐप्लिकेशन के काम करने के तरीके पर असर नहीं पड़ना चाहिए और सिस्टम के व्यवहार में भी कोई बदलाव नहीं होना चाहिए

डिवाइस में लागू होने के बाद, SELinux की डिफ़ॉल्ट नीति को तब तक बनाए रखा जाना चाहिए, जब तक कि SELinux की नीति में किए गए बदलावों की ऑडिटिंग नहीं हो जाती. डिवाइस में लागू किए गए बदलाव, अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट के साथ काम करने चाहिए.

9.8. निजता

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

9.9. पूरी ड्राइव को एन्क्रिप्ट (सुरक्षित) करना

अगर डिवाइस में लॉकस्क्रीन की सुविधा है, तो डिवाइस में फ़ुल-डिस्क एन्क्रिप्शन की सुविधा काम करती हो.

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

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

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

10.1. Compatibility Test Suite

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

12. दस्तावेज़ में बदलाव का लॉग

इस रिलीज़ में, साथ काम करने की परिभाषा में किए गए बदलावों की खास जानकारी नीचे दी गई टेबल में दी गई है.

सेक्शन बदलाव की खास जानकारी
3.2.2. बिल्ड पैरामीटर ब्रैंड, डिवाइस, और प्रॉडक्ट के लिए अपडेट किए गए ब्यौरे. SERIAL अब ज़रूरी है.
3.2.3.5. ऐप्लिकेशन की डिफ़ॉल्ट सेटिंग नया सेक्शन, जिसमें ऐप्लिकेशन की नई डिफ़ॉल्ट सेटिंग का पालन करने की ज़रूरी शर्त जोड़ी गई है
3.3.1 ऐप्लिकेशन बाइनरी इंटरफ़ेस android.os.Build.CPU_ABI और android.os.Build.CPU_ABI2 पैरामीटर के लिए, इस्तेमाल की जा सकने वाली वैल्यू के बारे में साफ़ तौर पर बताया गया है.
3.4.1. वेबव्यू के साथ काम करना ज़रूरी वेबव्यू लागू करने के लिए, Chromium को जोड़ा गया.
3.7. वर्चुअल मशीन के साथ काम करने की सुविधा xxhdpi और 400dpi स्क्रीन डेंसिटी के लिए ज़रूरी शर्तें जोड़ी गईं.
3.8.6. थीम पारदर्शी सिस्टम बार के इस्तेमाल को दिखाने के लिए अपडेट किया गया.
3.8.12. जगह की जानकारी नया सेक्शन, जिसमें जगह की जानकारी की ज़रूरी सेटिंग को एक ही जगह पर जोड़ा गया है.
3.8.13. यूनिकोड नया सेक्शन, जिसमें इमोजी की सुविधा के लिए ज़रूरी शर्तें जोड़ी गई हैं.
3.9. डिवाइस प्रबंधन पहले से इंस्टॉल किए गए एडमिन ऐप्लिकेशन, डिवाइस के मालिक के डिफ़ॉल्ट ऐप्लिकेशन नहीं हो सकते.
5.1. मीडिया कोडेक VP9 डिकोडर की ज़रूरी शर्त जोड़ी गई. हार्डवेयर VP8 कोडेक के लिए, सुझाई गई स्पेसिफ़िकेशन जोड़ी गई.
5.3. वीडियो डिकोड करना VP9 जोड़ा गया. डाइनैमिक रिज़ॉल्यूशन स्विच करने के लिए सुझाव जोड़ा गया.
5.4. ऑडियो रिकॉर्डिंग REMOTE_SUBMIX को ज़रूरी ऑडियो सोर्स के तौर पर जोड़ा गया है. android.media.audiofx.NoiseSuppressor एपीआई का इस्तेमाल करना ज़रूरी है.
6.2.1 एक्सपेरिमेंटल नया सेक्शन, जिसमें ART रनटाइम के बारे में बताया गया है. साथ ही, इसमें डिफ़ॉल्ट रनटाइम के तौर पर, Dalvik की ज़रूरत होती है.
7.1.1. स्क्रीन कॉन्फ़िगरेशन आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) को 1.85 से 1.86 पर सेट किया गया. 400 डीपीआई की स्क्रीन डेंसिटी जोड़ी गई.
7.1.6. स्क्रीन टाइप 640 डीपीआई (4K) रिज़ॉल्यूशन का कॉन्फ़िगरेशन जोड़ा गया.
7.2.3. नेविगेशन बटन हाल ही में खोले गए आइटम देखने की सुविधा को ज़रूरी के तौर पर जोड़ा गया है. साथ ही, मेन्यू फ़ंक्शन को प्राथमिकता में नीचे रखा गया है.
7.3.6. Thermometer सुझाए गए थर्मामीटर के तौर पर SENSOR_TYPE_AMBIENT_TEMPERATURE जोड़ा गया.
7.4.2.2. वाई-फ़ाई टनल वाला डायरेक्ट लिंक सेटअप करना नया सेक्शन, जिसमें वाई-फ़ाई टनल किए गए डायरेक्ट लिंक सेटअप (टीडीएलएस) के लिए सहायता जोड़ी गई है.
7.4.4. नियर फ़ील्ड कम्यूनिकेशन ज़रूरी शर्त के तौर पर, होस्ट कार्ड एम्युलेशन (एचसीई) जोड़ा गया. SNEP GET को लॉजिकल लिंक कंट्रोल प्रोटोकॉल (एलएलसीपी) से बदल दिया गया है. साथ ही, ज़रूरी शर्त के तौर पर ब्लूटूथ ऑब्जेक्ट पुश प्रोफ़ाइल जोड़ी गई है.
7.4.6. समन्वयन सेटिंग डेटा को अपने-आप सिंक करने की ज़रूरी शर्त जोड़ने वाला नया सेक्शन, डिफ़ॉल्ट रूप से चालू रहेगा.
7.6.1. डिवाइस की कम से कम मेमोरी और स्टोरेज 512 एमबी से कम मेमोरी वाले डिवाइसों के लिए, ActivityManager.isLowRamDevice() सेटिंग की ज़रूरी शर्त जोड़ी गई है. स्टोरेज की ज़रूरी शर्तों को बढ़ाया गया है. अब 512 एमबी और 1 जीबी के बजाय, 1 जीबी और 2 जीबी स्टोरेज की ज़रूरत होगी.
7.6.2. शेयर किया गया "बाहरी" स्टोरेज संपादकीय सुधार, जैसे कि सेक्शन के नाम में बदलाव करना और सेक्शन 9.5 से इस सेक्शन में फ़िट होने वाले टेक्स्ट को ले जाना. नोट किए गए ऐप्लिकेशन, सेकंडरी बाहरी स्टोरेज में, अपने पैकेज से जुड़ी डायरेक्ट्री में लिख सकते हैं.
7.7. यूएसबी सभी डिवाइसों के लिए, यूएसबी सीरियल नंबर की रिपोर्ट करने की ज़रूरी शर्त जोड़ी गई है.
9.5. एक डिवाइस पर कई लोगों के काम करने की सुविधा एक से ज़्यादा उपयोगकर्ताओं के लिए नहीं, बल्कि सिर्फ़ एक उपयोगकर्ता के लिए बने टेक्स्ट को सेक्शन 7.6.2 में ले जाया गया.
9.7. कर्नेल की सुरक्षा से जुड़ी सुविधाएं SELinux को लागू करने वाले मोड और ज़रूरी शर्तों पर स्विच करने के लिए फिर से लिखा गया है SELinux का आउटपुट, यूज़र इंटरफ़ेस में रेंडर नहीं किया जाना चाहिए.
9.8. निजता ऑडियो और वीडियो रिकॉर्डिंग की ज़रूरी शर्त जोड़ने वाले नए सेक्शन में, उपयोगकर्ता को लगातार सूचनाएं भेजनी चाहिए.
9.9. पूरी ड्राइव को एन्क्रिप्ट (सुरक्षित) करना नया सेक्शन, जिसमें लॉकस्क्रीन की सुविधा वाले ऐसे डिवाइसों की ज़रूरी शर्तें जोड़ी गई हैं जिनमें फ़ुल-डिस्क एन्क्रिप्शन की सुविधा काम करती है.
12. दस्तावेज़ में बदलाव का लॉग नया सेक्शन, जिसमें सेक्शन के हिसाब से सीडीडी में हुए बदलावों की खास जानकारी दी गई है.

 

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

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