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

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

दूसरा बदलाव
पिछले अपडेट की तारीख: 17 फ़रवरी, 2013

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

विषय सूची

1. परिचय

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

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

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

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

अगर सेक्शन 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.2 के साथ काम करने वाली वर्शन स्ट्रिंग: http://source.android.com/docs/compatibility/4.2/versions.html
8. Renderscript: http://developer.android.com/guide/topics/graphics/renderscript.html
9. हार्डवेयर की मदद से वीडियो की रफ़्तार बढ़ाने की सुविधा: http://developer.android.com/guide/topics/graphics/hardware-accel.html
10. android.webkit.WebView क्लास: http://developer.android.com/reference/android/webkit/WebView.html
11. HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/
12. HTML5 की ऑफ़लाइन सुविधाएं: http://dev.w3.org/html5/spec/Overview.html#offline
13. HTML5 वीडियो टैग: http://dev.w3.org/html5/spec/Overview.html#video
14. HTML5/W3C जियोलोकेशन एपीआई: http://www.w3.org/TR/geolocation-API/
15. HTML5/W3C वेबडेटाबेस एपीआई: http://www.w3.org/TR/webdatabase/
16. HTML5/W3C IndexedDB API: http://www.w3.org/TR/IndexedDB/
17. Dalvik वर्चुअल मशीन की खास जानकारी: यह Android के सोर्स कोड में, dalvik/docs पर उपलब्ध है
18. ऐप्लिकेशन विजेट: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
19. सूचनाएं: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
20. ऐप्लिकेशन के लिए संसाधन: http://code.google.com/android/reference/available-resources.html
21. स्टेटस बार के आइकॉन की स्टाइल गाइड: http://developer.android.com/guide/practices/ui_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/security.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. बाहरी स्टोरेज का रेफ़रंस: https://source.android.com/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

कैमरा: http://developer.android.com/reference/android/hardware/Camera.Parameters.html

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

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

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

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

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

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

3.2. Soft API Compatibility

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

3.2.1. अनुमतियां

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• ऐप्लिकेशन कैश मेमोरी/ऑफ़लाइन ऑपरेशन [रिसॉर्स, 12]
• <video> टैग [संसाधन, 13]
• जगह की जानकारी [संसाधन, 14]

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

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

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

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

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

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

• ऐप्लिकेशन कैश मेमोरी/ऑफ़लाइन ऑपरेशन [रिसॉर्स, 12]
• <video> टैग [संसाधन, 13]
• जगह की जानकारी [संसाधन, 14]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.1. विजेट

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

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

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

3.8.2. सूचनाएं

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

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

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

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

3.8.3. खोजें

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

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

3.8.4. टोस्ट

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

3.8.5. थीम

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

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

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

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

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

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

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

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

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

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

3.8.9. लॉक और होम स्क्रीन विजेट

Android 4.2 में, ऐप्लिकेशन विजेट की सुविधा शामिल है. उपयोगकर्ता, इन विजेट को होम स्क्रीन या लॉक स्क्रीन में जोड़ सकते हैं. ज़्यादा जानकारी के लिए, Android SDK दस्तावेज़ [संसाधन, 69] में ऐप्लिकेशन विजेट के डिज़ाइन से जुड़े दिशा-निर्देश देखें. ऐप्लिकेशन विजेट की मदद से, नई गतिविधि लॉन्च किए बिना ऐप्लिकेशन के डेटा और सेवाओं को तुरंत ऐक्सेस किया जा सकता है. विजेट, होम स्क्रीन या लॉक स्क्रीन पर इस्तेमाल किए जा सकते हैं. इसके लिए, विजेट में android:widgetCategory मेनिफ़ेस्ट टैग का इस्तेमाल किया जाता है. इससे सिस्टम को पता चलता है कि विजेट को कहां रखा जा सकता है. खास तौर पर, डिवाइस पर लागू किए गए टूल को इन ज़रूरी शर्तों को पूरा करना होगा.

• डिवाइस में, होम स्क्रीन पर ऐप्लिकेशन विजेट काम करने चाहिए.
• डिवाइस पर लॉक स्क्रीन की सुविधा काम करनी चाहिए. अगर डिवाइस में लॉक स्क्रीन की सुविधा काम करती है, तो डिवाइस में लॉक स्क्रीन पर ऐप्लिकेशन विजेट काम करने चाहिए.

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

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

3.8.11. स्वप्न

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

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

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

ध्यान दें: ऊपर बताई गई कुछ ज़रूरी शर्तों को Android 4.2 के लिए "चाहिए" के तौर पर बताया गया है. हालांकि, लॉक स्क्रीन की सुविधा वाले डिवाइसों को लॉक स्क्रीन पर विजेट मैनेज करने के लिए, डिवाइस की नीतियों का पालन करना ज़रूरी है. इस बारे में Android SDK के दस्तावेज़ [संसाधन, 27] में बताया गया है.

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

3.10 सुलभता

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

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

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

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

Android 4.2 में ऐसे एपीआई शामिल हैं जिनकी मदद से, ऐप्लिकेशन लिखाई को बोली में बदलने की सुविधा (टीटीएस) का इस्तेमाल कर सकते हैं. साथ ही, सेवा देने वाली कंपनियां, टीटीएस सेवाओं को लागू कर सकती हैं [संसाधन, 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 2.3.3+)		WebM (.webm) और Matroska (.mkv, Android 4.0+)

*ध्यान दें: सिर्फ़ 5.0/5.1 ऑडियो को डाउनमिक्स करना ज़रूरी है. दो से ज़्यादा चैनलों को रिकॉर्ड या रेंडर करना ज़रूरी नहीं है. **ध्यान दें: 16-बिट लीनियर पीसीएम कैप्चर करना ज़रूरी है. 8-बिट लीनियर पीसीएम कैप्चर करना ज़रूरी नहीं है.

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

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

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

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

Android डिवाइसों पर, VP8 वीडियो डिकोडिंग की इन प्रोफ़ाइलों का इस्तेमाल किया जा सकता है.

	एसडी (कम क्वालिटी)	एसडी (अच्छी क्वालिटी)	एचडी 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.2 के लिए "चाहिए" के तौर पर बताया गया है. हालांकि, आने वाले वर्शन के लिए, इन शर्तों को "ज़रूरी है" के तौर पर बदलने का प्लान है. इसका मतलब है कि Android 4.2 में ये ज़रूरी शर्तें लागू नहीं होतीं. हालांकि, आने वाले वर्शन में इन शर्तों को लागू करना ज़रूरी होगा. Android 4.2 पर काम करने वाले मौजूदा और नए डिवाइसों के लिए, Android 4.2 में इन ज़रूरी शर्तों को पूरा करना ज़रूरी है. ऐसा न करने पर, आने वाले समय में डिवाइसों को Android के नए वर्शन पर अपग्रेड नहीं किया जा सकेगा.

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 4.2.2 में, सुरक्षित adb की सुविधा शामिल है. Secure adb, पुष्टि किए गए होस्ट पर adb को चालू करता है. Android 4.2.2 पर काम करने वाले मौजूदा और नए डिवाइसों को Android 4.2 में इस ज़रूरी शर्त को पूरा करने का सुझाव दिया जाता है. ऐसा न करने पर, आने वाले समय में डिवाइसों को Android के नए वर्शन पर अपग्रेड नहीं किया जा सकेगा.

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

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

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

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

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

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

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

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

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

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

• 120 डीपीआई, जिसे 'ldpi' कहा जाता है
• 160 डीपीआई, जिसे 'mdpi' कहा जाता है
• 213 डीपीआई, जिसे 'tvdpi' कहा जाता है
• 240 डीपीआई, जिसे 'hdpi' कहा जाता है
• 320 डीपीआई, जिसे 'xhdpi' कहा जाता है
• 480 डीपीआई, जिसे 'xxhdpi' कहा जाता है

डिवाइस पर लागू होने वाले Android फ़्रेमवर्क की डेंसिटी, डिवाइस की स्क्रीन की डेंसिटी के हिसाब से होनी चाहिए. हालांकि, अगर डिवाइस की डेंसिटी की वजह से स्क्रीन का साइज़, काम करने के लिए तय किए गए कम से कम साइज़ से कम हो जाता है, तो डिवाइस की डेंसिटी को कम किया जा सकता है. अगर Android फ़्रेमवर्क की स्टैंडर्ड सघनता, संख्या के हिसाब से फ़िज़िकल सघनता के सबसे करीब होती है, तो उस स्क्रीन साइज़ की स्क्रीन का साइज़, स्क्रीन के सबसे छोटे साइज़ (320 dp चौड़ाई) से कम हो सकता है. ऐसे में, डिवाइस को लागू करने के लिए, Android फ़्रेमवर्क की अगली डेंसिटी के बारे में बताना चाहिए.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7.3. सेंसर

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

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

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

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

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

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

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

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

7.3.5. बैरोमीटर

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

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

7.3.7. Thermometer

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

7.3.7. फ़ोटोमीटर

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

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

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

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

7.4.1. टेलीफ़ोनी

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

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

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

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

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

7.4.2.1. Wi-Fi Direct

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

• डिवाइस पर सामान्य वाई-फ़ाई काम करना चाहिए
• वाई-फ़ाई और वाई-फ़ाई डायरेक्ट, दोनों का एक साथ इस्तेमाल किया जा सकता है

7.4.3. ब्लूटूथ

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

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

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

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

• android.content.pm.PackageManager.hasSystemFeature() तरीके से, android.hardware.nfc सुविधा की जानकारी देना ज़रूरी है. [संसाधन, 37]
• यह ज़रूरी है कि यह एनएफ़सी के इन स्टैंडर्ड के ज़रिए, एनडीएफ़ मैसेज को पढ़ और लिख सके:
  • यह एनएफ़सी फ़ोरम के रीडर/राइटर्स के तौर पर काम कर सकता हो (जैसा कि एनएफ़सी फ़ोरम के तकनीकी स्पेसिफ़िकेशन के मुताबिक बताया गया है, NFCForum-TS-DigitalProtocol-1.0), जो इन एनएफ़सी स्टैंडर्ड के मुताबिक हो:
    • NfcA (ISO14443-3A)
    • NfcB (ISO14443-3B)
    • NfcF (JIS 6319-4)
    • IsoDep (ISO 14443-4)
    • एनएफ़सी फ़ोरम टैग टाइप 1, 2, 3, 4 (एनएफ़सी फ़ोरम के मुताबिक)
• यह डिवाइस, नीचे दिए गए एनएफ़सी स्टैंडर्ड के ज़रिए, एनडीएफ़ मैसेज पढ़ और लिख सकता है. ध्यान दें कि Android 4.2 के लिए, यहां दिए गए एनएफ़सी स्टैंडर्ड को "इसका इस्तेमाल करना चाहिए" के तौर पर बताया गया है. हालांकि, आने वाले वर्शन के लिए, इन स्टैंडर्ड को "इसका इस्तेमाल करना ज़रूरी है" के तौर पर बदला जाएगा. इसका मतलब है कि Android 4.2 में ये स्टैंडर्ड इस्तेमाल करना ज़रूरी नहीं है. हालांकि, आने वाले वर्शन में इनका इस्तेमाल करना ज़रूरी होगा. Android 4.2 पर काम करने वाले मौजूदा और नए डिवाइसों को Android 4.2 में इन ज़रूरी शर्तों को पूरा करने का सुझाव दिया जाता है, ताकि वे आने वाले समय में प्लैटफ़ॉर्म के रिलीज़ किए जाने वाले नए वर्शन पर अपग्रेड कर सकें.
  • 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] स्पेसिफ़िकेशन लागू करें. इस तरह के लागू करने के लिए, एनएफ़सी पर डेटा ट्रांसफ़र करने के अनुरोध / चुनिंदा रिकॉर्ड को एक्सचेंज करने के लिए, एसएनईपी जीईटी अनुरोधों का इस्तेमाल करना चाहिए. साथ ही, असल ब्लूटूथ डेटा ट्रांसफ़र के लिए, ब्लूटूथ ऑब्जेक्ट पुश प्रोफ़ाइल का इस्तेमाल करना ज़रूरी है.
• एनएफ़सी डिस्कवरी मोड में, काम करने वाली सभी टेक्नोलॉजी के लिए पोल करना ज़रूरी है.
• डिवाइस के चालू होने पर, स्क्रीन चालू और लॉक-स्क्रीन अनलॉक होने पर, डिवाइस को एनएफ़सी डिस्कवरी मोड में होना चाहिए.

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

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

• MIFARE Classic (NXP MF1S503x [संसाधन, 44], MF1S703x [संसाधन, 44])
• MIFARE Ultralight (NXP MF0ICU1 [संसाधन, 46], MF0ICU2 [संसाधन, 46])
• MIFARE Classic पर NDEF (NXP AN130511 [संसाधन, 48], AN130411 [संसाधन, 49])

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

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

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

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

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

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

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

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

7.5. कैमरे

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

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

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

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

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

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

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

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

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

1. अगर किसी ऐप्लिकेशन ने कभी android.hardware.Camera.Parameters.setPreviewFormat(int) को कॉल नहीं किया है, तो ऐप्लिकेशन कॉलबैक के लिए दिए गए डेटा की झलक के लिए, डिवाइस को android.hardware.PixelFormat.YCbCr_420_SP का इस्तेमाल करना होगा.
2. अगर कोई ऐप्लिकेशन android.hardware.Camera.PreviewCallback इंस्टेंस रजिस्टर करता है और प्रीव्यू फ़ॉर्मैट YCbCr_420_SP होने पर सिस्टम onPreviewFrame() तरीके को कॉल करता है, तो onPreviewFrame() में पास किए गए byte[] में मौजूद डेटा, NV21 एन्कोडिंग फ़ॉर्मैट में होना चाहिए. इसका मतलब है कि NV21, डिफ़ॉल्ट तौर पर होना चाहिए.
3. डिवाइस में, कैमरे की झलक देखने के लिए YV12 फ़ॉर्मैट (जैसा कि android.graphics.ImageFormat.YV12 कॉन्स्टेंट से पता चलता है) का इस्तेमाल किया जाना चाहिए. यह फ़ॉर्मैट, सामने और पीछे के कैमरे, दोनों के लिए इस्तेमाल किया जाना चाहिए. (हार्डवेयर वीडियो एन्कोडर और कैमरे में किसी भी नेटिव पिक्सल फ़ॉर्मैट का इस्तेमाल किया जा सकता है. हालांकि, डिवाइस में YV12 में बदलाव करने की सुविधा होनी चाहिए.)

डिवाइस में, Android 4.2 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 एमबी, रेडियो, वीडियो वगैरह जैसे हार्डवेयर कॉम्पोनेंट के लिए तय की गई मेमोरी के अलावा हो. ये कॉम्पोनेंट, कर्नेल के कंट्रोल में नहीं होते.

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

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

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

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

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

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

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

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

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

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

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

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

7.7. यूएसबी

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

10.1. Compatibility Test Suite

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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