हमारा सुझाव है कि 27 मार्च, 2025 से AOSP को बनाने और उसमें योगदान देने के लिए, aosp-main के बजाय android-latest-release का इस्तेमाल करें. ज़्यादा जानकारी के लिए, AOSP में हुए बदलाव लेख पढ़ें.

इस पेज का अनुवाद Cloud Translation API से किया गया है.

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

7.3.1. ऐक्सेलेरोमीटर
7.3.2. मैग्नेटोमीटर
7.3.3. GPS
7.3.4. जाइरोस्कोप
7.3.5. Barometer
7.3.6. Thermometer
7.3.7. फ़ोटोमीटर
7.3.8. प्रॉक्सिमिटी सेंसर
7.4. डेटा कनेक्टिविटी
7.4.1. टेलीफ़ोनी
7.4.2. आईईईई 802.11 (वाई-फ़ाई)
7.4.2.1. Wi-Fi Direct
7.4.3. ब्लूटूथ
7.4.4. नियर फ़ील्ड कम्यूनिकेशन
7.4.5. नेटवर्क की कम से कम क्षमता
7.5. Cameras
7.5.1. पीछे-फ़ेसिंग कैमरा
7.5.2. सामने वाला कैमरा
7.5.3. Camera API Behavior
7.5.4. कैमरे का ओरिएंटेशन
7.6. मेमोरी और स्टोरेज
7.6.1. कम से कम मेमोरी और स्टोरेज
7.6.2. ऐप्लिकेशन का शेयर किया गया स्टोरेज
7.7. USB
8. परफ़ॉर्मेंस के हिसाब से काम करने की सुविधा
9. सिक्योरिटी मॉडल के साथ काम करना
9.1. अनुमतियां
9.2. यूआईडी और प्रोसेस अलगाव
9.3. फ़ाइल सिस्टम की अनुमतियां
9.4. ऐप्लिकेशन चलाने के लिए अन्य एनवायरमेंट
10. सॉफ़्टवेयर के साथ काम करने की जांच
10.1. Compatibility Test Suite
10.2. CTS पुष्टि करने वाला
10.3. रेफ़रंस ऐप्लिकेशन
11. अपडेट किया जा सकने वाला सॉफ़्टवेयर
12. हमसे संपर्क करें
अनुबंध A - ब्लूटूथ की जांच का तरीका

1. जानकारी
इस दस्तावेज़ में उन ज़रूरी शर्तों के बारे में बताया गया है जिन्हें पूरा करने पर, डिवाइसों को
Android 4.1 के साथ काम करने लायक बनाया जा सकता है.
"ज़रूरी है", "ज़रूरी नहीं है", "ज़रूरी है", "होना चाहिए ", "नहीं होना चाहिए", "चाहिए", "नहीं चाहिए",
"सुझाया गया", "हो सकता है", और "ज़रूरी नहीं" का इस्तेमाल, RFC2119
[संसाधन, 1] में बताए गए IETF स्टैंडर्ड के मुताबिक किया जाता है.
इस दस्तावेज़ में, "डिवाइस लागू करने वाला" या "लागू करने वाला" का मतलब किसी व्यक्ति या
संगठन से है, जो Android 4.1 पर चलने वाला हार्डवेयर/सॉफ़्टवेयर सलूशन डेवलप कर रहा है. "डिवाइस
इंप्लिकेशन" या "इंप्लिकेशन", हार्डवेयर/सॉफ़्टवेयर का ऐसा समाधान है जिसे डेवलप किया गया है.
Android 4.1 के साथ काम करने के लिए, डिवाइस में ये शर्तें पूरी होनी चाहिए:
इसमें, डिवाइस के साथ काम करने की शर्तों के बारे में बताने वाले दस्तावेज़ों के साथ-साथ, रेफ़रंस के ज़रिए शामिल किए गए दस्तावेज़ भी शामिल हैं.

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

इस वजह से, Android Open Source Project [संसाधन, 3] को Android के लिए रेफ़रंस और इसे लागू करने का सबसे सही तरीका माना जाता है.
डिवाइस में लागू करने वाले लोगों को
Android Open Source Project से उपलब्ध
"अपस्ट्रीम" सोर्स कोड का ज़्यादा से ज़्यादा इस्तेमाल करने का सुझाव दिया जाता है. कुछ
कॉम्पोनेंट को ऐसे बदला जा सकता है जैसे कि वे असल में नहीं हैं. हालांकि,
ऐसा करने का सुझाव बिल्कुल नहीं दिया जाता, क्योंकि सॉफ़्टवेयर की जांच पास करना
काफ़ी ज़्यादा मुश्किल हो जाएगा. यह पक्का करना, लागू करने वाले की ज़िम्मेदारी है कि
Compatibility Test Suite के साथ-साथ, Android के स्टैंडर्ड वर्शन के साथ भी, डिवाइस के काम करने का तरीका पूरी तरह से
काम करता हो. आखिर में, ध्यान दें कि इस दस्तावेज़ में, कुछ कॉम्पोनेंट के बदले दूसरे कॉम्पोनेंट इस्तेमाल करने और
बदलाव करने पर साफ़ तौर पर पाबंदी लगाई गई है.
2. संसाधन
1.  आईईटीएफ RFC2119 की ज़रूरी शर्तों के लेवल: http://www.ietf.org/rfc/rfc2119.txt
2.  Android Compatibility Program के बारे में खास जानकारी:
http://source.android.com/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.1 के लिए इस्तेमाल की जा सकने वाली वर्शन स्ट्रिंग:
http://source.android.com/compatibility/4.1/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 class:
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 geolocation API: http://www.w3.org/TR/geolocation-API/
15.  HTML5/W3C वेबडेटाबेस Aपीआई: 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 class: http://developer.android.com/reference/android/R.style.html
26.  लाइव वॉलपेपर: http://developer.android.com/resources/articles/live-
wal papers.html
27.  Android डिवाइस एडमिन:
http://developer.android.com/guide/topics/admin/device-admin.html
28.  android.app.admin.DevicePolicyManager class:
http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html
29.  Android Accessibility Service API:
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 project: http://code.google.com/p/eyes-free
32.  टेक्स्ट-टू-स्पीच एपीआई:
http://developer.android.com/reference/android/speech/tts/package-
summary.html
33.  टूल के बारे में रेफ़रंस दस्तावेज़ (adb, aapt, ddms के लिए):
http://developer.android.com/guide/developing/tools/index.html
34.  Android APK फ़ाइल की जानकारी:
http://developer.android.com/guide/topics/fundamentals.html
35.  मेनिफ़ेस्ट फ़ाइलें: http://developer.android.com/guide/topics/manifest/manifest-
intro.html
36.  मंकी टेस्टिंग टूल:
https://developer.android.com/studio/test/other-testing-tools/monkey
37.  Android android.content.pm.PackageManager class and Hardware Features
List:
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.  Bluetooth API:
http://developer.android.com/reference/android/bluetooth/package-summary.html
43.  NDEF पुश प्रोटोकॉल: http://source.android.com/compatibility/ndef-push-
protocol.pdf
44.  MIFARE MF1S503X: http://www.nxp.com/documents/data_sheet/MF1S503x.pdf
45.  MIFARE MF1S703X: http://www.nxp.com/documents/data_sheet/MF1S703x.pdf
46.  MIFARE MF0ICU1: http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf
47.  MIFARE MF0ICU2:
http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf
48.  MIFARE AN130511:
http://www.nxp.com/documents/application_note/AN130511.pdf
49.  MIFARE AN130411:
http://www.nxp.com/documents/application_note/AN130411.pdf
50.  कैमरे के ओरिएंटेशन का एपीआई:
http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)
51.  android.hardware.Camera:
http://developer.android.com/reference/android/hardware/Camera.html
52.  Android Open Accessories:
http://developer.android.com/guide/topics/usb/accessory.html
53.  USB Host API: http://developer.android.com/guide/topics/usb/host.html
54.  Android की सुरक्षा और अनुमतियों के बारे में जानकारी:
http://developer.android.com/guide/topics/security/security.html
55.  Android के लिए ऐप्लिकेशन: http://code.google.com/p/apps-for-android
56.  android.app.DownloadManager class:
http://developer.android.com/reference/android/app/DownloadManager.html
57.  Android File Transfer: 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.  Wifi मल्टीकास्ट एपीआई:
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 Sharing Settings:
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.  Media Remote Control Client:
http://developer.android.com/reference/android/media/RemoteControlClient.html
70.  Motion Event API:
http://developer.android.com/reference/android/view/MotionEvent.html
71.  टच इनपुट कॉन्फ़िगरेशन: http://source.android.com/tech/input/touch-
devices.html
इनमें से कई संसाधन, Android 4.1 SDK से सीधे या किसी दूसरे तरीके से लिए गए हैं.
साथ ही, ये SDK के दस्तावेज़ में दी गई जानकारी के मुताबिक काम करेंगे. अगर
इस संगतता की परिभाषा या संगतता की जांच के सुइट में, SDK टूल के दस्तावेज़ से मतभेद होता है, तो SDK टूल के दस्तावेज़ को आधिकारिक माना जाता है.

ऊपर दिए गए रेफ़रंस में दी गई तकनीकी जानकारी को,
इस काम करने के तरीके की परिभाषा का हिस्सा माना जाता है.
3. सॉफ़्टवेयर
3.1. मैनेज किया गया एपीआई काम करता है या नहीं
Android
ऐप्लिकेशन के लिए, मैनेज किया गया (Dalvik पर आधारित) एक्सीक्यूशन एनवायरमेंट मुख्य साधन है. Android ऐप्लिकेशन प्रोग्रामिंग इंटरफ़ेस (एपीआई),
मैनेज किए जा रहे वीएम
एनवायरमेंट में चल रहे ऐप्लिकेशन के लिए,
Android प्लैटफ़ॉर्म इंटरफ़ेस का सेट होता है. डिवाइस पर लागू किए गए एपीआई को पूरी तरह से लागू किया जाना चाहिए. इसमें,
Android
4.1 SDK [संसाधन, 4] से एक्सपोज़ किए गए, दस्तावेज़ में शामिल किसी भी एपीआई के सभी व्यवहार शामिल होने चाहिए.
डिवाइस पर एपीआई लागू करने के लिए, मैनेज किए जा रहे किसी भी एपीआई को शामिल करना ज़रूरी है. साथ ही, एपीआई इंटरफ़ेस या
हस्ताक्षर में बदलाव नहीं किया जा सकता. इसके अलावा, एपीआई के काम करने के तरीके में बदलाव नहीं किया जा सकता या कोई ऐसा एपीआई शामिल नहीं किया जा सकता जो काम न करता हो. हालांकि,
इस शर्त को तब लागू नहीं किया जाता, जब यह 'काम करने के तरीके' की इस परिभाषा में खास तौर पर बताया गया हो.
हार्डवेयर के साथ काम करने की इस परिभाषा में, कुछ तरह के हार्डवेयर के लिए अनुमति दी गई है. इनके लिए, Android
में ऐसे एपीआई शामिल हैं जिन्हें डिवाइस में लागू करने की ज़रूरत नहीं है. ऐसे मामलों में, एपीआई
को अब भी मौजूद होना चाहिए और सही तरीके से काम करना चाहिए. इस स्थिति के लिए
ज़रूरी शर्तों के बारे में जानने के लिए, सातवां सेक्शन देखें.
3.2. सॉफ़्ट एपीआई के साथ काम करने की सुविधा
सेक्शन 3.1 में बताए गए मैनेज किए जा सकने वाले एपीआई के अलावा, Android में एक अहम
सिर्फ़ रनटाइम वाला "सॉफ़्ट" एपीआई भी शामिल है. यह एपीआई, इंटेंट, अनुमतियों, और
Android ऐप्लिकेशन के ऐसे मिलते-जुलते पहलुओं के तौर पर काम करता है जिन्हें ऐप्लिकेशन को कंपाइल करने
के समय लागू नहीं किया जा सकता.
3.2.1. अनुमतियां
डिवाइस पर लागू करने वाले लोगों को, अनुमति के रेफ़रंस पेज [संसाधन, 5] में बताए गए सभी अनुमति कॉन्स्टेंट का इस्तेमाल करना होगा और उन्हें लागू करना होगा.
ध्यान दें कि सेक्शन 10
में, Android के सुरक्षा मॉडल से जुड़ी अन्य ज़रूरी शर्तों की सूची दी गई है.
3.2.2. बिल्ड पैरामीटर
Android एपीआई में, android.os.Build क्लास
[Resources, 6] पर कई कॉन्स्टेंट शामिल होते हैं. इनका मकसद, मौजूदा डिवाइस के बारे में बताना होता है.यहां दी गई टेबल में,इन वैल्यू के फ़ॉर्मैट से जुड़ी अतिरिक्त
पाबंदियां शामिल हैं. डिवाइस पर लागू होने वाले टूल को इन
पाबंदियों का पालन करना ज़रूरी है, ताकि सभी डिवाइसों पर एक जैसी और
काम की वैल्यू दी जा सकें.
पैरामीटर
टिप्पणियां
फ़िलहाल चल रहे Android सिस्टम का वर्शन, जिसे कोई भी व्यक्ति पढ़ सकता है. इस फ़ील्ड में, [Resources, 7] में बताई गई स्ट्रिंग वैल्यू में से कोई एक
android.os.Build.VERSION.RELEASE
होना ज़रूरी है.
इस फ़ील्ड में, फ़िलहाल चल रहे Android सिस्टम का वर्शन होता है. यह वर्शन, तीसरे पक्ष के ऐप्लिकेशन कोड के लिए ऐक्सेस किए जा सकने वाले फ़ॉर्मैट में होता है.
android.os.Build.VERSION.SDK
Android 4.1 के लिए, इस फ़ील्ड में पूर्णांक की वैल्यू 16 होनी चाहिए.

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

इस बारे में यहां दिए गए सेक्शन में बताया गया है. "इस्तेमाल किया गया" का मतलब है कि डिवाइस पर इसे लागू करने वाले व्यक्ति को
ऐसी Android गतिविधि या सेवा देनी होगी जो मैच करने वाले इंटेंट फ़िल्टर की जानकारी देती हो. साथ ही,
हर तय किए गए इंटेंट पैटर्न के लिए सही तरीके से काम करती हो और उसे लागू करती हो.
3.2.3.1. कोर ऐप्लिकेशन इंटेंट
Android अपस्ट्रीम प्रोजेक्ट में, कई कोर ऐप्लिकेशन के बारे में बताया गया है. जैसे,संपर्क,
कैलेंडर, फ़ोटो गैलरी, संगीत प्लेयर वगैरह. डिवाइस पर लागू करने वाले लोग,
इन ऐप्लिकेशन को अन्य वर्शन से बदल सकते हैं.
हालांकि, ऐसे किसी भी विकल्प के वर्शन में, अपस्ट्रीम प्रोजेक्ट
के ज़रिए उपलब्ध इंटेंट पैटर्न का इस्तेमाल करना ज़रूरी है. उदाहरण के लिए, अगर किसी डिवाइस में कोई अन्य संगीत प्लेयर है, तो
गाने चुनने के लिए, उसे तीसरे पक्ष के ऐप्लिकेशन से जारी किए गए इंटेंट पैटर्न का पालन करना होगा.
इन ऐप्लिकेशन को Android के मुख्य सिस्टम ऐप्लिकेशन माना जाता है:
डेस्क क्लॉक
ब्राउज़र
कैलेंडर
संपर्क
गैलरी
ग्लोबल सर्च
लॉन्चर
संगीत
सेटिंग
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 फ़ाइल पढ़ें. अगर डिवाइस पर, एक या उससे ज़्यादा
तय किए गए ABI काम करते हैं, तो Android NDK के साथ काम करने की सुविधा को इस तरह लागू किया जाना चाहिए.
अगर किसी डिवाइस में Android के किसी एबीआई के लिए सहायता शामिल है, तो:
उसमें, मैनेज किए जा रहे एनवायरमेंट में चलने वाले कोड के लिए सहायता शामिल होनी चाहिए, ताकि उसे
नेटिव कोड में बदला जा सके. इसके लिए, स्टैंडर्ड Java नेटिव इंटरफ़ेस (JNI) के सेमेटिक का इस्तेमाल किया जाना चाहिए.
वह सोर्स के साथ काम करने वाला (यानी हेडर के साथ काम करने वाला) और बाइनरी के साथ काम करने वाला (
एबीआई के लिए) होना चाहिए. साथ ही, यह नीचे दी गई सूची में मौजूद हर ज़रूरी लाइब्रेरी के साथ काम करना चाहिए
वह android.os.Build.CPU_ABI API के ज़रिए, डिवाइस पर काम करने वाले नेटिव ऐप्लिकेशन बाइनरी इंटरफ़ेस (एबीआई) के बारे में सटीक जानकारी देना चाहिए
वह सिर्फ़ उन एबीआई के बारे में जानकारी देना चाहिए जिनके बारे में Android
NDK के नए वर्शन में बताया गया है. यह जानकारी, docs/CPU-ARCH-ABIS.txt फ़ाइल में दी गई है
इसे,
अपस्ट्रीम 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 ओपन सोर्स को लागू करने के लिए, WebKit रेंडरिंग इंजन का इस्तेमाल किया जाता है, ताकि
android.webkit.WebView को लागू किया जा सके. वेब रेंडरिंग सिस्टम के लिए,
पूरी तरह से टेस्ट करने वाला सुइट डेवलप करना मुमकिन नहीं है. इसलिए, डिवाइस में वेबव्यू लागू करने वाले लोगों को,
वेबव्यू लागू करने के लिए, WebKit के खास अपस्ट्रीम बिल्ड का इस्तेमाल करना होगा. खास तौर पर:
डिवाइस पर लागू किए गए android.webkit.WebView को
Android 4.1 के लिए, अपस्ट्रीम Android ओपन सोर्स ट्री से 534.30 WebKit बिल्ड पर आधारित होना चाहिए
. इस बिल्ड में, वेबव्यू के लिए फ़ंक्शन और सुरक्षा
से जुड़े सुधारों का एक खास सेट शामिल है. डिवाइस में लागू करने वाले लोग,
WebKit को लागू करने के तरीके में पसंद के मुताबिक बदलाव कर सकते हैं.हालांकि, ऐसे किसी भी बदलाव से,
WebView के व्यवहार में बदलाव नहीं होना चाहिए.इसमें रेंडरिंग के व्यवहार में भी बदलाव नहीं होना चाहिए.
WebView के ज़रिए रिपोर्ट की गई उपयोगकर्ता एजेंट स्ट्रिंग, इस फ़ॉर्मैट में होनी चाहिए:
Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL)
Build/$(BUILD)) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.1
Mobile Safari/534.30
$(VERSION) स्ट्रिंग की वैल्यू,

$(VERSION) स्ट्रिंग की वैल्यू के बराबर होनी चाहिए
android.os.Build.VERSION.RELEASE
$(LOCALE) स्ट्रिंग की वैल्यू,
देश कोड और भाषा के लिए ISO कन्वेंशंस के मुताबिक होनी चाहिए.साथ ही, यह डिवाइस की कॉन्फ़िगर की गई मौजूदा
locale के बारे में बतानी चाहिए
$(MODEL) स्ट्रिंग की वैल्यू,
android.os.Build.MODEL
$(BUILD) स्ट्रिंग की वैल्यू के बराबर होनी चाहिए
डिवाइस में लागू करने वाले लोग, उपयोगकर्ता एजेंट स्ट्रिंग में Mobile को हटा सकते हैं
WebView कॉम्पोनेंट में, ज़्यादा से ज़्यादा HTML5
[Resources, 11] के लिए सहायता शामिल होनी चाहिए.
कम से कम, डिवाइस पर लागू किए गए वर्शन में, वेबव्यू में HTML5 से जुड़े इन सभी एपीआई का इस्तेमाल किया जाना चाहिए:
ऐप्लिकेशन कैश मेमोरी/ऑफ़लाइन ऑपरेशन [संसाधन, 12]
<video> टैग [संसाधन, 13]
जियोलोकेशन [संसाधन, 14]
इसके अलावा, डिवाइस पर लागू किए गए वर्शन में, HTML5/W3C वेबस्टोरेज एपीआई
[संसाधन, 15] का इस्तेमाल किया जाना चाहिए. साथ ही, HTML5/W3C IndexedDB एपीआई
16] का इस्तेमाल किया जाना चाहिए.
ध्यान दें कि वेब डेवलपमेंट स्टैंडर्ड बॉडी, वेबस्टोरेज के बजाय
IndexedDB को फ़ायदा देने के लिए ट्रांज़िशन कर रहे हैं. इसलिए, IndexedDB को Android के आने वाले वर्शन में
कॉम्पोनेंट के तौर पर ज़रूरी बनाने की उम्मीद है.
JavaScript एपीआई की तरह, HTML5 एपीआई को भी वेबव्यू में डिफ़ॉल्ट रूप से बंद रखना ज़रूरी है.
ऐसा तब तक करना होगा, जब तक डेवलपर उन्हें सामान्य Android एपीआई की मदद से साफ़ तौर पर चालू न कर दे.
3.4.2. ब्राउज़र किस-किस के साथ काम करता है
डिवाइस में, सामान्य
उपयोगकर्ता के वेब ब्राउज़ करने के लिए, स्टैंडअलोन ब्राउज़र ऐप्लिकेशन होना चाहिए. स्टैंडअलोन ब्राउज़र,
WebKit के अलावा किसी अन्य ब्राउज़र टेक्नोलॉजी पर आधारित हो सकता है. हालांकि, अगर किसी अन्य ब्राउज़र ऐप्लिकेशन का इस्तेमाल किया जाता है, तो तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध
android.webkit.WebView कॉम्पोनेंट
WebKit पर आधारित होना चाहिए, जैसा कि सेक्शन 3.4.1 में बताया गया है.
इंप्लिकेशन, स्टैंडअलोन ब्राउज़र
ऐप्लिकेशन में कस्टम उपयोगकर्ता एजेंट स्ट्रिंग भेज सकते हैं.
स्टैंडअलोन ब्राउज़र ऐप्लिकेशन (चाहे वह अपस्ट्रीम WebKit ब्राउज़र
ऐप्लिकेशन पर आधारित हो या तीसरे पक्ष के किसी ब्राउज़र पर आधारित हो) में, ज़्यादा से ज़्यादा
HTML5 [संसाधन, 11] के लिए सहायता शामिल होनी चाहिए. कम से कम, डिवाइस पर लागू किए गए वर्शन में,
HTML5 से जुड़े इन सभी एपीआई का इस्तेमाल किया जाना चाहिए:
ऐप्लिकेशन कैश/ऑफ़लाइन ऑपरेशन [संसाधन, 12]
<video> टैग [संसाधन, 13]
जियोलोकेशन [संसाधन, 14]
इसके अलावा, डिवाइस पर लागू किए गए वर्शन में, HTML5/W3C वेबस्टोरेज एपीआई
[संसाधन, 15] का इस्तेमाल किया जाना चाहिए. साथ ही, HTML5/W3C IndexedDB एपीआई
[संसाधन, 16] का इस्तेमाल किया जाना चाहिए. ध्यान दें कि वेब डेवलपमेंट के स्टैंडर्ड बनाने वाली संस्थाएं, वेबस्टोरेज के बजाय
IndexedDB का इस्तेमाल करने की ओर बढ़ रही हैं. इसलिए, आने वाले समय में Android के नए वर्शन में IndexedDB एक ज़रूरी
कॉम्पोनेंट बन सकता है.
3.5. एपीआई के काम करने का तरीका
एपीआई के हर टाइप (मैनेज किया गया, सॉफ़्ट, नेटिव, और वेब) के काम करने का तरीका,
अपस्ट्रीम Android ओपन सोर्स
प्रोजेक्ट के काम करने के तरीके से मेल खाना चाहिए [संसाधन, 3]. काम करने के तरीके से जुड़ी कुछ खास बातें:
डिवाइसों को स्टैंडर्ड इंटेंट के व्यवहार या सेमेटिक्स में बदलाव नहीं करना चाहिए
डिवाइसों को किसी खास तरह के सिस्टम कॉम्पोनेंट (जैसे, सेवा, गतिविधि, ContentProvider वगैरह) के लाइफ़साइकल या लाइफ़साइकल सेमेटिक्स में बदलाव नहीं करना चाहिए
डिवाइसों को स्टैंडर्ड अनुमति के सेमेटिक्स में बदलाव नहीं करना चाहिए
ऊपर दी गई सूची में सभी बातें शामिल नहीं हैं.
Compatibility Test Suite (CTS)
, प्लैटफ़ॉर्म के काम करने के तरीके की जांच करता है. हालांकि, यह सभी चीज़ों की जांच नहीं करता .
ओपन सोर्स प्रोजेक्ट के साथ काम करने की ज़िम्मेदारी, इसे लागू करने वाले व्यक्ति या कंपनी की है.
इस वजह से, डिवाइस में इस सुविधा को लागू करने वाले लोगों को, सिस्टम के अहम हिस्सों को फिर से लागू करने के बजाय, जहां भी हो सके वहां 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 एमबी
बड़ा
mdpi
32 एमबी
बड़ा
tvdpi / hdpi
64 एमबी
बड़ा
xhdpi
128 एमबी
3.8. यूज़र इंटरफ़ेस के साथ काम करना
3.8.1. विजेट
Android, कॉम्पोनेंट टाइप और उससे जुड़े एपीआई और लाइफ़साइकल तय करता है. इससे

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

डिवाइस पर लागू किए गए वर्शन में,
स्टैंडर्ड ग्रिड साइज़ में 4 x 4 वाले विजेट रेंडर करने की सुविधा होनी चाहिए. ज़्यादा जानकारी के लिए, Android SDK
दस्तावेज़ [संसाधन, 18] में ऐप्लिकेशन विजेट के डिज़ाइन से जुड़े दिशा-निर्देश देखें.
3.8.2. सूचनाएं
Android में ऐसे एपीआई शामिल हैं जिनकी मदद से डेवलपर, डिवाइस के हार्डवेयर और सॉफ़्टवेयर की सुविधाओं का इस्तेमाल करके, उपयोगकर्ताओं को अहम इवेंट की सूचना दे सकते हैं
[संसाधन, 19].
कुछ एपीआई, ऐप्लिकेशन को सूचनाएं देने या ध्यान खींचने की अनुमति देते हैं. इसके लिए, वे
हार्डवेयर, खास तौर पर आवाज़, वाइब्रेशन, और लाइट का इस्तेमाल करते हैं. डिवाइस में सूचनाएं भेजने की सुविधा,
हार्डवेयर की सुविधाओं का इस्तेमाल करने वाली सूचनाओं के साथ काम करनी चाहिए.
इस बारे में SDK टूल के दस्तावेज़ में बताया गया है. साथ ही, यह सुविधा डिवाइस में मौजूद हार्डवेयर के साथ काम करनी चाहिए.
उदाहरण के लिए, अगर डिवाइस में वाइब्रेटर है, तो डिवाइस में सूचनाएं भेजने की सुविधा,
वाइब्रेशन एपीआई को सही तरीके से लागू करनी चाहिए. अगर किसी डिवाइस पर एपीआई लागू करने के लिए ज़रूरी हार्डवेयर मौजूद नहीं है, तो
उससे जुड़े एपीआई को नो-ऑप के तौर पर लागू करना ज़रूरी है. ध्यान दें कि इस व्यवहार के बारे में ज़्यादा जानकारी
सेक्शन 7 में दी गई है.
इसके अलावा, लागू करने के लिए, एपीआई [रिसॉर्स, 20] या स्टेटस/सिस्टम बार आइकॉन
स्टाइल गाइड [रिसॉर्स, 21] में दिए गए सभी रिसॉर्स (आइकॉन, साउंड
फ़ाइलें वगैरह) को सही तरीके से रेंडर करना ज़रूरी है.डिवाइस इंटिग्रेटर, सूचनाओं के लिए Android के ओपन सोर्स
इंटिग्रेशन में दिए गए विकल्प के बजाय, उपयोगकर्ताओं को कोई दूसरा विकल्प दे सकते हैं. हालांकि, ऊपर बताए गए विकल्प के तौर पर, सूचनाओं के लिए मौजूदा
संसाधनों के साथ काम करने वाले अन्य सूचना सिस्टम का इस्तेमाल करना ज़रूरी है.

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

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

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

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

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

3.8.8. इनपुट मैनेजमेंट सेटिंग
Android 4.1 में, इनपुट मैनेजमेंट इंजन के लिए सहायता शामिल है. Android 4.1 एपीआई
, उपयोगकर्ता के हिसाब से सेट की जा सकने वाली सेटिंग तय करने के लिए, कस्टम ऐप्लिकेशन आईएमई को अनुमति देते हैं. डिवाइस पर लागू करने के लिए,
यह ज़रूरी है कि उपयोगकर्ता, IME की सेटिंग को किसी भी समय ऐक्सेस कर सके. ऐसा तब किया जा सकता है, जब डिवाइस पर कोई ऐसा IME डिसप्ले किया गया हो जो
उपयोगकर्ता को सेटिंग ऐक्सेस करने की सुविधा देता हो.
3.8.9. लॉक स्क्रीन पर रिमोट कंट्रोल
Android 4.0 में, रिमोट कंट्रोल एपीआई के लिए सहायता शुरू की गई थी. इससे मीडिया ऐप्लिकेशन,
डिवाइस की लॉक स्क्रीन
जैसे रिमोट व्यू में दिखाए जाने वाले प्लेबैक कंट्रोल के साथ इंटिग्रेट हो सकते हैं [संसाधन, 69]. डिवाइस पर लागू करने के लिए,
डिवाइस की लॉक स्क्रीन में रिमोट कंट्रोल जोड़ने की सुविधा होनी चाहिए.
3.9 डिवाइस एडमिनिस्ट्रेशन
Android 4.1 में ऐसी सुविधाएं शामिल हैं जिनकी मदद से, सुरक्षा के बारे में जानकारी रखने वाले ऐप्लिकेशन, सिस्टम लेवल पर डिवाइस
एडमिनिस्ट्रेशन फ़ंक्शन कर सकते हैं. जैसे, पासवर्ड की नीतियों को लागू करना या
Android डिवाइस एडमिनिस्ट्रेशन एपीआई [संसाधन,
27] की मदद से, डिवाइस को रिमोट तौर पर मिटाना. डिवाइस पर लागू किए जाने वाले ऐप्लिकेशन में,
DevicePolicyManager क्लास [संसाधन, 28] को लागू करना ज़रूरी है. साथ ही, यह
Android SDK दस्तावेज़ [संसाधन,
27] में बताई गई डिवाइस एडमिनिस्ट्रेशन की नीतियों की पूरी रेंज के साथ काम करना चाहिए.
ध्यान दें:
Android 4.1 के लिए, ऊपर बताई गई कुछ ज़रूरी शर्तों को "चाहिए" के तौर पर बताया गया है. हालांकि, आने वाले वर्शन के लिए, इन शर्तों को "ज़रूरी है" में बदलने का प्लान है
. इसका मतलब है कि Android 4.1 में ये ज़रूरी शर्तें लागू नहीं होतीं. हालांकि, आने वाले वर्शन में इनका पालन करना
ज़रूरी होगा. Android 4.1 पर काम करने वाले मौजूदा और नए डिवाइसों को
Android 4.1 में इन ज़रूरी शर्तों को पूरा करने का सुझाव दिया जाता है. ऐसा न करने पर, आने वाले समय में डिवाइसों को Android के नए वर्शन पर अपग्रेड नहीं किया जा सकेगा.

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

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

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

स्पेसिफ़िकेशन में तय की गई सीमाओं तक होनी चाहिए.

फ़ाइल टाइप /
फ़ॉर्मैट /
टाइप
एन्कोडर
डिकोडर
जानकारी
कंटेनर
कोडेक
फ़ॉर्मैट
इन फ़ॉर्मैट के साथ काम करता है
ज़रूरी है
मोनो/स्टीरियो/5.0/5.1*
MPEG-4
डिवाइस पर लागू करने के लिए ज़रूरी है

AAC प्रोफ़ाइल
वाला कॉन्टेंट, जिसमें माइक्रोफ़ोन हार्डवेयर शामिल है
ज़रूरी है
स्टैंडर्ड सैंपलिंग
(AAC LC)
और 3GPP
की दरें 8 से 48
android.hardware.microphone तय करें.

(.3gp)
kHz.
MPEG-4

(.mp4,
MPEG-4
मोनो/स्टीरियो/5.0/5.1*
.m4a)
HE AAC
कॉन्टेंट के साथ
ADTS रॉ

ज़रूरी
प्रोफ़ाइल
स्टैंडर्ड सैंपलिंग
AAC (.aac,
(AAC+)
16 से 48
kHz में डिकोड
करें.
Android
3.1+,

MPEG-4
के साथ काम करने की सुविधा
डिवाइस में
मोनो/स्टीरियो/5.0/5.1*
HE AAC v2
इंप्लिकेशन में
Android
कॉन्टेंट को
Profile
माइक्रोफ़ोन हार्डवेयर के साथ

4.0+, ADIF
स्टैंडर्ड
सैंपलिंग
(बेहतर
परफ़ॉर्मेंस
के लिए
16 से 48
AAC+)
android.hardware.microphone
के साथ काम करने वाला)
kHz.
MPEG-TS
MPEG-4
(.ts, not
Audio
REQUIRED for device
Support for
seekable,
Object Type
implementations that include
mono/stereo content
Android
ER AAC
microphone hardware and
REQUIRED
with standard
3.0+)
ELD
define
sampling rates from
(Enhanced
android.hardware.microphone
16 to 48 kHz.
कम देरी
AAC)
ज़रूरी है
डिवाइस पर लागू करने के लिए ज़रूरी है
4.75 से 12.2 केबीपीएस
AMR-NB
जिसमें माइक्रोफ़ोन हार्डवेयर शामिल है
ज़रूरी है
3GPP (.3gp)
8 केएचज़ पर सैंपल किया गया
और
android.hardware.microphone तय करें.
ज़रूरी है
डिवाइस पर लागू करने के लिए ज़रूरी है
6.60 से 23.85 केबीटी/सेकंड
AMR-WB
में से 9 रेट
माइक्रोफ़ोन हार्डवेयर
ज़रूरी है
3GPP (.3gp)
और
16 केएचज़ पर सैंपल किए गए
android.hardware.microphone को तय करें.
मोनो/स्टीरियो (
मल्टीचैनल नहीं).
ऑडियो
सैंपल रेट,
48 kHz
तक (हालांकि,
44.1 kHz
तक
का सुझाव
दिया जाता है
ऐसे डिवाइसों पर
जिनमें 44.1

केवल FLAC

किलोहर्ट्ज़

डाऊनसैंपलर

में,

लो-पास

फ़िल्टर शामिल नहीं होता). 16-बिट
का सुझाव दिया जाता है; 24-
बिट के लिए,
डिटहर लागू नहीं किया जाता.
मोनो/स्टीरियो 8-
320 केबीपीएस कंसटेंट
एमपी3

ज़रूरी है
एमपी3 (.mp3)
(सीबीआर) या वैरिएबल
बिट-रेट (वीबीआर)
टाइप 0 और
एमआईडीआई टाइप 0 और 1.
1 (.mid,
DLS Version 1 and
.xmf, .mxmf)
2. XMF और मोबाइल
RTTTL/RTX
MIDI

ज़रूरी है
XMF.
(.rtttl, .rtx)
रिंगटोन फ़ॉर्मैट
OTA (.ota)
RTTTL/RTX, OTA,
iMelody
और iMelody
(.imy)

Ogg (.ogg)
Vorbis

ज़रूरी है

Matroska
(.mkv)
8-बिट और 16-बिट
लीनियर PCM** (
हार्डवेयर की सीमा तक रेट).डिवाइसों में
PCM/WAVE
का इस्तेमाल करना ज़रूरी है
ज़रूरी है
ज़रूरी है
WAVE (.wav)

रॉ PCM रिकॉर्डिंग के लिए सैंपलिंग रेट
8000,16000 और
44100 Hz
फ़्रीक्वेंसी पर
JPEG
ज़रूरी है
ज़रूरी है
Base+progressive
JPEG (.jpg)
GIF

ज़रूरी है

GIF (.gif)
इमेज
PNG
ज़रूरी है
ज़रूरी है

PNG (.png)
BMP

ज़रूरी है

BMP (.bmp)
WEBP
ज़रूरी है
ज़रूरी है

WebP (.webp)
ज़रूरी है
डिवाइस में
3GPP
को लागू करने के लिए ज़रूरी है
इसमें कैमरा हार्डवेयर और
(.3gp)
H.263
ज़रूरी है

android.hardware.camera
MPEG-4
या
(.mp4)
android.hardware.camera.front तय करें.
3GPP
(.3gp)
ज़रूरी है
MPEG-4
(.mp4)
डिवाइस पर लागू करने के लिए ज़रूरी है
ऐसा MPEG-TS

जिसमें कैमरा हार्डवेयर और
बेसलाइन प्रोफ़ाइल
वीडियो
H.264 AVC
ज़रूरी है
(.ts, AAC
define android.hardware.camera
(BP)
सिर्फ़ ऑडियो,
या
नहीं
android.hardware.camera.front.
seekable,
Android
3.0+)
MPEG-4

ज़रूरी है

3GPP (.3gp)
SP
WebM (.webm)
ज़रूरी है
और Matroska
VP8

(Android

(.mkv, Android
2.3.3+)
4.0+)
*ध्यान दें: सिर्फ़ 5.0/5.1 कॉन्टेंट का डाउनमिक्स ज़रूरी है; दो से ज़्यादा
चैनलों को रिकॉर्ड या रेंडर करना ज़रूरी नहीं है. **ध्यान दें: 16-बिट लीनियर पीसीएम कैप्चर ज़रूरी है. 8-बिट लीनियर PCM
कैप्चर करना ज़रूरी नहीं है.
5.2 वीडियो एन्कोडिंग
Android डिवाइस पर काम करने वाले ऐप्लिकेशन में रियर-फ़ेसिंग कैमरा होना चाहिए. साथ ही, यह भी ज़रूरी है कि
android.hardware.camera में, वीडियो एन्कोडिंग की इन प्रोफ़ाइलों के साथ काम करने की सुविधा होनी चाहिए.
एचडी (जब हार्डवेयर

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

ऑडियो
1 (मोनो)
2 (स्टीरियो)
2 (स्टीरियो)
चैनल
ऑडियो बिटरेट 24 केबीपीएस
128 केबीपीएस
192 केबीपीएस
5.3. ऑडियो रिकॉर्डिंग
जब कोई ऐप्लिकेशन
ऑडियो स्ट्रीम रिकॉर्ड करने के लिए, android.media.AudioRecord API का इस्तेमाल करता है, तो डिवाइस में माइक्रोफ़ोन हार्डवेयर और
android.hardware.microphone का इस्तेमाल करने वाले डिवाइसों को, इन सभी
कार्रवाइयों के साथ ऑडियो सैंपल और रिकॉर्ड करना चाहिए:
डिवाइस में फ़्रीक्वेंसी के मुकाबले ऐम्प्ल्यफ़िकेशन में ज़्यादा बदलाव नहीं होना चाहिए
. खास तौर पर, 100 हर्ट्ज़ से 4,000 हर्ट्ज़ के बीच, ±3 डीबी
. ऑडियो इनपुट की संवेदनशीलता को इस तरह सेट किया जाना चाहिए कि 1,000 हर्ट्ज़ पर 90 डीबी साउंड पावर लेवल(एसपीएल) वाले सोर्स से, 16-बिट सैंपल के लिए आरएमएस 2,500 मिलता हो.
पीसीएम ऐम्प्ल्यफ़िकेशन लेवल को, इनपुट एसपीएल में होने वाले बदलावों को कम से कम 30 डीबी की रेंज में, रेखीय तरीके से ट्रैक करना चाहिए.
माइक्रोफ़ोन पर 90 डीबी एसपीएल इनपुट लेवल पर, 1 किलोहर्ट्ज़ के लिए कुल हार्मोनिक डिस्टॉर्शन 1% से कम होना चाहिए.

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

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

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

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

लेकिन आने वाले वर्शन के लिए, इन ज़रूरी शर्तों को "ज़रूरी है" के तौर पर बदला जाएगा.
इसका मतलब है कि Android 4.1 में ये ज़रूरी शर्तें लागू नहीं होंगी, लेकिन आने वाले
वर्शन में ये लागू होंगी.
Android 4.1 पर काम करने वाले मौजूदा और नए डिवाइसों को, Android 4.1 में इन ज़रूरी शर्तों को पूरा करने का
बहुत ज़्यादा
सुझाव दिया जाता है. ऐसा न करने पर, आने वाले समय में डिवाइसों को Android के नए वर्शन पर अपग्रेड करने पर, वे
Android के साथ काम नहीं करेंगे.
अगर किसी डिवाइस पर इस सेक्शन की ज़रूरी शर्तें पूरी की जाती हैं, तो हो सकता है कि वह डिवाइस, android.content.pm.PackageManager क्लास के ज़रिए "android.hardware.audio.low-
latency" सुविधा की जानकारी देकर,
कम इंतज़ार वाले ऑडियो की सुविधा के साथ काम करने की जानकारी दे. [सोर्स, 37]
इसके उलट, अगर डिवाइस में इन ज़रूरी शर्तों को पूरा नहीं किया जाता है, तो यह ज़रूरी है कि
डिवाइस में कम इंतज़ार वाले ऑडियो की सुविधा काम न करे.
5.5. नेटवर्क प्रोटोकॉल
डिवाइसों में ऑडियो और वीडियो चलाने के लिए, मीडिया नेटवर्क प्रोटोकॉल की सुविधा होनी चाहिए. इस बारे में ज़्यादा जानकारी के लिए, Android SDK टूल के दस्तावेज़ [संसाधन, 58] देखें.
खास तौर पर, डिवाइसों में
इन मीडिया नेटवर्क प्रोटोकॉल के साथ काम करने की सुविधा होनी चाहिए:
आरटीएसपी (आरटीपी, एसडीपी)
एचटीटीपी(एस) प्रोग्रेसिव स्ट्रीमिंग
एचटीटीपी(एस) लाइव स्ट्रीमिंग ड्राफ़्ट प्रोटोकॉल, वर्शन 3 [संसाधन, 59]
6. डेवलपर टूल के साथ काम करना
डिवाइस पर लागू किए गए टूल,
Android SDK में दिए गए Android डेवलपर टूल के साथ काम करने चाहिए. खास तौर पर, Android के साथ काम करने वाले डिवाइसों को इनके साथ काम करना चाहिए:
Android डीबग ब्रिज (जिसे adb कहा जाता है) [संसाधन, 33]
डिवाइस के लागू होने के लिए, यह ज़रूरी है कि वे
Android SDK में दिए गए सभी adb फ़ंक्शन के साथ काम करें. डिवाइस-साइड adb डेमन, डिफ़ॉल्ट रूप से बंद होना चाहिए. साथ ही,
Android Debug
Bridge को चालू करने के लिए, उपयोगकर्ता के पास कोई ऐसा तरीका होना चाहिए जिसका इस्तेमाल किया जा सके.
Dalvik Debug Monitor Service (जिसे ddms कहा जाता है) [संसाधन, 33]
डिवाइस पर लागू किए गए सिस्टम में, ddms की सभी सुविधाएं काम करनी चाहिए, जैसा कि
Android SDK में बताया गया है. ddms, adb का इस्तेमाल करता है. इसलिए,
डिफ़ॉल्ट रूप से, ddms के लिए सहायता चालू नहीं होनी चाहिए. हालांकि, जब भी उपयोगकर्ता ने ऊपर बताए गए तरीके से Android
Debug Bridge को चालू किया हो, तब ddms के लिए सहायता चालू होनी चाहिए.
Monkey [संसाधन, 36]
डिवाइस पर Monkey फ़्रेमवर्क को लागू करना ज़रूरी है. साथ ही, इसे
ऐप्लिकेशन के इस्तेमाल के लिए उपलब्ध कराना ज़रूरी है.
ज़्यादातर Linux-आधारित सिस्टम और Apple Macintosh सिस्टम, Android डिवाइसों को पहचानते हैं. इसके लिए, उन्हें किसी और सहायता की ज़रूरत नहीं होती. हालांकि, Microsoft
Windows सिस्टम को आम तौर पर नए Android डिवाइसों के लिए ड्राइवर की ज़रूरत होती है.
उदाहरण के लिए,
नए वेंडर आईडी और कभी-कभी नए डिवाइस आईडी के लिए,
Windows सिस्टम के लिए कस्टम यूएसबी ड्राइवर की ज़रूरत होती है.) अगर डिवाइस को ऐसे इंस्टॉल किया गया है कि
स्टैंडर्ड Android SDK में उपलब्ध adb टूल उससे पहचान न कर पाए, तो डिवाइस इंस्टॉल करने वाले लोगों को Windows
ड्राइवर देने ज़रूरी हैं, ताकि डेवलपर adb प्रोटोकॉल का इस्तेमाल करके डिवाइस से कनेक्ट कर सकें.
Windows XP, Windows Vista, और Windows 7 के लिए,
32-बिट और 64-बिट, दोनों वर्शन में ये ड्राइवर देना ज़रूरी है.
7. हार्डवेयर के साथ काम करना
अगर किसी डिवाइस में ऐसा कोई हार्डवेयर कॉम्पोनेंट शामिल है जिसके लिए
तीसरे पक्ष के डेवलपर के पास काम करने वाला एपीआई है, तो डिवाइस में उस एपीआई को Android SDK के दस्तावेज़ में बताए गए तरीके से लागू करना ज़रूरी है.
अगर SDK टूल में मौजूद कोई एपीआई,
ऐसे हार्डवेयर कॉम्पोनेंट के साथ इंटरैक्ट करता है जिसे वैकल्पिक बताया गया है और डिवाइस में
वह कॉम्पोनेंट मौजूद नहीं है, तो:
कॉम्पोनेंट के एपीआई के लिए, पूरी क्लास की परिभाषाएं (SDK टूल के दस्तावेज़ के मुताबिक)
अब भी मौजूद होनी चाहिए
एपीआई के काम करने के तरीके को किसी सही
फ़ैशन में, कोई काम न करने वाले एपीआई के तौर पर लागू किया जाना चाहिए
SDK टूल के दस्तावेज़ में बताई गई जगहों पर, एपीआई के तरीके को कोई काम न करने वाले एपीआई के तौर पर लागू किया जाना चाहिए
एपीआई के तरीके को कोई काम न करने वाले एपीआई के तौर पर लागू करने के लिए, एपीआई के तरीकों में कोई बदलाव नहीं किया जाना चाहिए

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

डिवाइस पर लागू किए गए बदलावों में, android.content.pm.PackageManager क्लास के getSystemAvailableFeatures() और hasSystemFeature(String)
तरीकों की मदद से, हार्डवेयर कॉन्फ़िगरेशन
की सटीक जानकारी दी जानी चाहिए. [Resources, 37]
7.1. डिसप्ले और ग्राफ़िक
Android 4.1 में ऐसी सुविधाएं शामिल हैं जो डिवाइस के हिसाब से, ऐप्लिकेशन एसेट और यूआई
लेआउट को अपने-आप अडजस्ट करती हैं. इससे यह पक्का होता है कि तीसरे पक्ष के ऐप्लिकेशन,
अलग-अलग हार्डवेयर कॉन्फ़िगरेशन [संसाधन, 38] पर अच्छी तरह से काम करते हैं. डिवाइसों को
इन एपीआई और व्यवहारों को सही तरीके से लागू करना होगा, जैसा कि इस सेक्शन में बताया गया है.
इस सेक्शन में दी गई ज़रूरी शर्तों में बताई गई इकाइयों को इस तरह से तय किया गया है:
"डायगनल साइज़", डिसप्ले के रोशन किए गए हिस्से के दो विपरीत कोनों के बीच की दूरी होती है.
यह दूरी इंच में होती है.
"डीपीआई" (जिसका मतलब है "डॉट प्रति इंच"), एक लीनियर
हॉरिज़ॉन्टल या वर्टिकल स्पैन के 1" में मौजूद पिक्सल की संख्या होती है. डीपीआई की वैल्यू की सूची में, हॉरिज़ॉन्टल और
वर्टिकल डीपीआई, दोनों की वैल्यू इस रेंज में होनी चाहिए.
"आस्पेक्ट रेशियो", स्क्रीन के लंबे डाइमेंशन और छोटे डाइमेंशन के बीच का अनुपात होता है.
उदाहरण के लिए, 480x854 पिक्सल के डिसप्ले का अनुपात 854 / 480 =
1.779 या करीब-करीब "16:9" होगा.
"डेंसिटी-इंडिपेंडेंट पिक्सल" या ("dp") एक वर्चुअल पिक्सल यूनिट है, जिसे 160
डीपीआई स्क्रीन के हिसाब से नॉर्मलाइज़ किया जाता है. इसका हिसाब इस तरह लगाया जाता है: पिक्सल = डीपीएस * (डेंसिटी / 160).
7.1.1. स्क्रीन कॉन्फ़िगरेशन
स्क्रीन साइज़
Android यूज़र इंटरफ़ेस (यूआई) फ़्रेमवर्क, अलग-अलग तरह के स्क्रीन साइज़ के साथ काम करता है. साथ ही, यह
ऐप्लिकेशन को डिवाइस के स्क्रीन साइज़ (जिसे "स्क्रीन लेआउट" भी कहा जाता है) के बारे में क्वेरी करने की अनुमति देता है. इसके लिए,
ऐप्लिकेशन को
android.content.res.Configuration.screenLayout के ज़रिए
SCREENLAYOUT_SIZE_MASK का इस्तेमाल करना होगा. डिवाइस पर लागू किए गए ऐप्लिकेशन में, स्क्रीन का सही
साइज़ रिपोर्ट किया जाना चाहिए. यह साइज़, Android SDK टूल के दस्तावेज़ [संसाधन, 38] में बताया गया है और इसे
अपस्ट्रीम Android प्लैटफ़ॉर्म तय करता है. खास तौर पर, डिवाइस पर लागू होने वाले वर्शन में,
स्क्रीन के सही साइज़ की जानकारी देनी चाहिए. यह जानकारी, यहां दिए गए लॉजिकलडेंसिटी-इंडिपेंडेंट पिक्सल (dp)
स्क्रीन डाइमेंशन के हिसाब से होनी चाहिए.
डिवाइसों की स्क्रीन का साइज़ कम से कम 426 dp x 320 dp ('छोटा ') होना चाहिए
डिवाइसों की स्क्रीन का साइज़ कम से कम 480
dp x 320 dp होना चाहिए, जो 'सामान्य' स्क्रीन साइज़ के तौर पर रिपोर्ट की जाती है
डिवाइसों की स्क्रीन का साइज़ कम से कम 640
dp x 480 dp होना चाहिए, जो 'बड़ी' स्क्रीन साइज़ के तौर पर रिपोर्ट की जाती है
डिवाइसों की स्क्रीन का साइज़ कम से कम 960
dp x 720 dp होना चाहिए, जो 'बहुत बड़ी' स्क्रीन साइज़ के तौर पर रिपोर्ट की जाती है
इसके अलावा, डिवाइसों की स्क्रीन का डायगनल साइज़ कम से कम 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 डीपी चौड़ाई) से कम होना चाहिए.
डिवाइस पर काम करने वाले Android फ़्रेमवर्क को, इससे कम की डेंसिटी को रिपोर्ट करना चाहिए.

7.1.2. डिसप्ले मेट्रिक
डिवाइस पर लागू होने वाले सिस्टम को,
android.util.DisplayMetrics [Resources, 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 एपीआई (यानी,
libGLES_v1CM.so, libGLES_v2.so या libEGL.so के ज़रिए ऐप्लिकेशन के लिए उपलब्ध एपीआई) को
OpenGL ES 1.0 और 2.0 के साथ काम करने की जानकारी देनी होगी.
डिवाइस पर लागू किए गए वर्शन में, अपनी पसंद के OpenGL ES एक्सटेंशन लागू किए जा सकते हैं.
हालांकि, डिवाइस पर लागू किए गए वर्शन में, उन सभी एक्सटेंशन स्ट्रिंग की जानकारी ज़रूर देनी चाहिए जो OpenGL ES मैनेज किए गए और
नेटिव एपीआई के साथ काम करती हैं. इसके अलावा, उन सभी एक्सटेंशन स्ट्रिंग की जानकारी नहीं देनी चाहिए जो डिवाइस पर काम नहीं करती हैं.

ध्यान दें कि Android 4.1 में, ऐप्लिकेशन के लिए यह बताने की सुविधा शामिल है कि उन्हें
OpenGL टेक्सचर कंप्रेस करने के खास फ़ॉर्मैट की ज़रूरत है या नहीं. ये फ़ॉर्मैट, आम तौर पर
वेंडर के हिसाब से होते हैं.
किसी खास टेक्सचर कंप्रेस करने के फ़ॉर्मैट को लागू करने के लिए, Android 4.1 में डिवाइस पर लागू करने की ज़रूरत नहीं होती. हालांकि,
OpenGL API में getString() मेथड का इस्तेमाल करके, उनको
टेक्सचर कंप्रेस करने के उन सभी फ़ॉर्मैट की सटीक जानकारी देनी चाहिए जो उनके डिवाइस पर काम करते हैं.
Android 4.1 में, ऐप्लिकेशन के लिए एक मेकेनिज्म शामिल है, जिससे वे यह एलान कर सकते हैं कि वे
ऐप्लिकेशन, गतिविधि, विंडो या
व्यू लेवल पर 2D ग्राफ़िक्स के लिए, हार्डवेयर ऐक्सेलरेशन को चालू करना चाहते हैं. इसके लिए, ऐप्लिकेशन को manifest टैग android:hardwareAccelerated या सीधे
API cal s [Resources, 9] का इस्तेमाल करना होगा.
Android 4.1 में, डिवाइस पर हार्डवेयर से तेज़ी लाने की सुविधा को डिफ़ॉल्ट रूप से चालू करना ज़रूरी है. अगर डेवलपर ने
android:hardwareAccelerated="false" को सेट करके या सीधे Android View API की मदद से हार्डवेयर से तेज़ी लाने की सुविधा को बंद करके
अनुरोध किया है, तो डिवाइस पर हार्डवेयर से तेज़ी लाने की सुविधा को बंद करना ज़रूरी है.

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

Android के अपस्ट्रीम वर्शन के साथ एक जैसा काम करना चाहिए.
7.1.5. लेगसी ऐप्लिकेशन के साथ काम करने वाला मोड
Android 4.1 में "साथ काम करने वाला मोड" होता है. इसमें फ़्रेमवर्क,
स्क्रीन के साइज़ के हिसाब से'सामान्य' (320dp चौड़ाई) मोड में काम करता है. ऐसा इसलिए किया जाता है, ताकि लेगसी
ऐप्लिकेशन को फ़ायदा मिल सके. ये ऐप्लिकेशन, 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 dpi) डेंसिटी
1920x1080 (इसे 1080p भी कहा जाता है): 'बड़ी' स्क्रीन का साइज़, 'xhdpi' (320 dpi) डेंसिटी
साफ़ तौर पर बताने के लिए, अलग-अलग पिक्सल डाइमेंशन वाले डिवाइसों के लिए, Android 4.1 में
720p या 1080p तक ही सीमित हैं. साथ ही, उन्हें स्क्रीन साइज़ और
डेंसिटी बकेट की जानकारी देने के लिए कॉन्फ़िगर किया जाना चाहिए, जैसा कि ऊपर बताया गया है.
7.1.7. स्क्रीन टेक्नोलॉजी
Android प्लैटफ़ॉर्म में ऐसे एपीआई शामिल हैं जो ऐप्लिकेशन को
डिसप्ले पर रिच ग्राफ़िक रेंडर करने की अनुमति देते हैं. डिवाइसों पर Android SDK में बताए गए सभी एपीआई काम करने चाहिए
. हालांकि, अगर इस दस्तावेज़ में खास तौर पर इसके बारे में नहीं कहा गया है, तो ऐसा ज़रूरी नहीं है. खास तौर पर:
डिवाइसों में ऐसे डिसप्ले होने चाहिए जो 16-बिट कलर ग्राफ़िक्स को रेंडर कर सकें. साथ ही,
डिवाइसों में ऐसे डिसप्ले होने चाहिए जो 24-बिट कलर ग्राफ़िक्स को रेंडर कर सकें.
डिवाइसों में ऐसे डिसप्ले होने चाहिए जो ऐनिमेशन को रेंडर कर सकें.
इस्तेमाल की जाने वाली डिसप्ले टेक्नोलॉजी का पिक्सल आसपेक्ट रेशियो (पीएआर) 0.9

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

बिना छूए नेविगेट करने की सुविधा
डिवाइस पर लागू करने के लिए:
बिना छूए नेविगेट करने की सुविधा का विकल्प नहीं दिया जा सकता. इसका मतलब है कि ट्रैकबॉल, डी-पैड या
व्हील को नहीं हटाया जा सकता

android.content.res.Configuration.navigation [Resources, 40]के लिए सही वैल्यू दी जानी चाहिए

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

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

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

डिवाइस पर मौजूद खास टचस्क्रीन के टाइप के हिसाब से, android.content.res.Configuration.touchscreen
[Resources, 40] c की वैल्यू की जानकारी देनी चाहिए
Android 4.0 में, अलग-अलग तरह की टचस्क्रीन, टच पैड, और नकली टच
इनपुट डिवाइसों के साथ काम करने की सुविधा शामिल है. टच स्क्रीन वाले डिवाइसों पर लागू किए गए
डिसप्ले [संसाधन, 71] ऐसे होते हैं कि उपयोगकर्ता को लगे कि वह सीधे तौर पर
स्क्रीन पर मौजूद आइटम में बदलाव कर रहा है. उपयोगकर्ता सीधे तौर पर स्क्रीन को छू रहा है, इसलिए सिस्टम को
उन ऑब्जेक्ट के बारे में बताने के लिए, किसी अन्य सुविधा की ज़रूरत नहीं होती जिनमें बदलाव किया जा रहा है. इसके
बनिबस्था में, नकली टच इंटरफ़ेस एक यूज़र इनपुट सिस्टम उपलब्ध कराता है, जो टचस्क्रीन की सुविधाओं के
सबसेट के बराबर होता है. उदाहरण के लिए,
ऑन-स्क्रीन कर्सर को चलाने वाला माउस या रिमोट कंट्रोल, टच की सुविधा के करीब होता है. हालांकि, इसके लिए उपयोगकर्ता को पहले कर्सर को पॉइंट या फ़ोकस करना होता है
और फिर क्लिक करना होता है. माउस, ट्रैकपैड, घुमाव वाले एयर माउस,
घुमाव वाले पॉइंटर, जॉयस्टिक, और मल्टी-टच ट्रैकपैड जैसे कई इनपुट डिवाइसों पर, फ़ेक टच इंटरैक्शन की सुविधा काम करती है.
Android 4.0 में, फ़ीचर कॉन्स्टेंट android.hardware.faketouch शामिल है. यह
, हाई-फ़िडेलिटी वाले नॉन-टच (यानी पॉइंटर पर आधारित) इनपुट डिवाइस से जुड़ा होता है. जैसे,
माउस या ट्रैकपैड, जो टच-आधारित इनपुट (इसमें बुनियादी
जेस्चर की सुविधा भी शामिल है) को सही तरीके से एमुलेट कर सकता है. साथ ही, यह बताता है कि डिवाइस,
टचस्क्रीन की सुविधा के एमुलेट किए गए सबसेट के साथ काम करता है. डिवाइस में फ़ेक टच की सुविधा लागू करने के लिए,
सेक्शन 7.2.5 में बताई गई ज़रूरी शर्तों को पूरा करना ज़रूरी है.
डिवाइस पर लागू किए गए टूल, इस्तेमाल किए गए
इनपुट के टाइप के हिसाब से सही सुविधा की जानकारी देने चाहिए. जिन डिवाइसों में टचस्क्रीन (सिंगल-टच या बेहतर) है
उन्हें प्लैटफ़ॉर्म की सुविधा के लिए, android.hardware.touchscreen का इस्तेमाल करना होगा.
डिवाइस पर
android.hardware.touchscreen की सुविधा लागू करने पर,
android.hardware.faketouch की सुविधा भी लागू होनी चाहिए. जिन डिवाइसों में
टचस्क्रीन नहीं है और जो सिर्फ़ पॉइंटर डिवाइस पर काम करते हैं उन्हें किसी भी टचस्क्रीन
सुविधा की जानकारी नहीं देनी चाहिए. साथ ही, अगर वे सेक्शन 7.2.5 में बताई गई नकली
टच की ज़रूरी शर्तों को पूरा करते हैं, तो उन्हें सिर्फ़ android.hardware.faketouch की जानकारी देनी चाहिए.
7.2.5.नकली टच इनप ट
जिन डिवाइसों में android.hardware.faketouch
के साथ काम करने की सुविधा है
उनमें, पॉइंटर की जगह की सटीक X और Y स्क्रीन पोज़िशन की जानकारी देनी ज़रूरी है. साथ ही,
स्क्रीन पर विज़ुअल पॉइंटर दिखाना ज़रूरी है[Resources, 70]
ऐक्शन कोड के साथ टच इवेंट की जानकारी देनी ज़रूरी है[Resources, 70] यह कोड,
स्क्रीन पर पॉइंटर के gनीचे या ऊपर जाने पर होने वाले स्टेटस में बदलाव की जानकारी देता है
[Resources, 70]
स्क्रीन पर किसी ऑब्जेक्ट पर पॉइंटर को नीचे और ऊपर ले जाने की सुविधा होनी चाहिए. इससे
उपयोगकर्ता,
स्क्रीन पर किसी ऑब्जेक्ट पर टैप करने की सुविधा का इस्तेमाल कर सकते हैं
स्क्रीन पर किसी ऑब्जेक्ट पर पॉइंटर को नीचे, ऊपर, फिर नीचे और ऊपर ले जाने की सुविधा होनी चाहिए. यह सुविधा,
उपयोगकर्ताओं को
स्क्रीन पर किसी ऑब्जेक्ट पर दो बार टैप करने की सुविधा का इस्तेमाल करने में मदद करती है [Resources, 70]
स्क्रीन पर किसी भी जगह पर पॉइंटर को नीचे ले जाने की सुविधा होनी चाहिए. इसके बाद, पॉइंटर को
स्क्रीन पर किसी भी दूसरी जगह पर ले जाने के बाद, अप ले जाने की सुविधा होनी चाहिए. इससे
उपयोगकर्ता,
स्क्रीन पर किसी ऑब्जेक्ट को खींचकर छोड़ने की सुविधा का इस्तेमाल कर सकते हैं
पॉइंटर को नीचे ले जाने के बाद, उपयोगकर्ताओं को
स्क्रीन पर किसी ऑब्जेक्ट को तुरंत किसी दूसरी जगह पर ले जाने की सुविधा होनी चाहिए. इसके बाद, पॉइंटर को
स्क्रीन पर ऊपर ले जाने की सुविधा होनी चाहिए. इससे
उपयोगकर्ता,
स्क्रीन पर किसी ऑब्जेक्ट को फ़्लिंग करने की सुविधा का इस्तेमाल कर सकते हैं
जिन डिवाइसों में android.hardware.faketouch.multitouch.distinct
के साथ काम करने की सुविधा है
उनमें, ऊपर बताई गई नकली टच की ज़रूरी शर्तें पूरी होनी चाहिए. साथ ही, उनमें दो या उससे ज़्यादा अलग-अलग पॉइंटर इनपुट को अलग-अलग
ट्रैक करने की सुविधा भी होनी चाहिए.
7.2.6. माइक्रोफ़ोन
डिवाइस में माइक्रोफ़ोन न हो. हालांकि, अगर किसी डिवाइस में
माइक्रोफ़ोन न हो, तो उसमें android.hardware.microphone feature
constant की जानकारी नहीं दी जानी चाहिए. साथ ही, उसमें ऑडियो रिकॉर्डिंग एपीआई को सेक्शन 7 के मुताबिक, no-ops के तौर पर इंस्टॉल किया जाना चाहिए.
इसके उलट, अगर किसी डिवाइस में माइक्रोफ़ोन है, तो:
उसमें android.hardware.microphone feature constant की जानकारी दी जानी चाहिए
उसमें सेक्शन 5.4 में बताई गई, ऑडियो क्वालिटी से जुड़ी ज़रूरी शर्तें पूरी की जानी चाहिए
उसमें सेक्शन 5.5 में बताई गई, ऑडियो देर से आने से जुड़ी ज़रूरी शर्तें पूरी की जानी चाहिए
7.3. सेंसर

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

android.content.pm.PackageManager क्लास के हिसाब से, सेंसर की मौजूदगी या अनुपस्थिति की सटीक जानकारी देनी चाहिए. [सोर्स, 37]
SensorManager.getSensorList() और इसी तरह के अन्य तरीकों के ज़रिए, काम करने वाले सेंसर की सटीक सूची दिखानी चाहिए

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

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

Android एपीआई ([संसाधन, 41] देखें) में बताए गए तरीके के हिसाब से, Android सेंसर कोऑर्डिनेट सिस्टम का पालन करना ज़रूरी है

किसी भी तीन-आयामवाले वेक्टर
पर, फ़्रीफ़ॉल से लेकर दोगुनी गुरुत्वाकर्षण (2g) या उससे ज़्यादा तक की गति को मेज़र करना ज़रूरी है

8-बिट या उससे ज़्यादा सटीक होना ज़रूरी है

स्टैंडर्ड डेविएशन 0.05 m/s^2 से ज़्यादा नहीं होना चाहिए
7.3.2. मैग्नेटोमीटर
डिवाइस में, तीन ऐक्सिस वाला मैग्नेटोमीटर (जैसे, कंपास) होना चाहिए. अगर
डिवाइस में तीन ऐक्सिस वाला मैग्नेटोमीटर है, तो:
यह 10 हर्ट्ज़ या उससे ज़्यादा पर इवेंट डिलीवर कर सकता है
यह
Android एपीआई में बताए गए तरीके के हिसाब से, Android सेंसर कोऑर्डिनेट सिस्टम का पालन करता है ([संसाधन, 41] देखें).
यह
जियोमैग्नेटिक फ़ील्ड को कवर करने के लिए, फ़ील्ड स्ट्रेंथ की ऐसी रेंज को सैंपल कर सकता है जो ज़रूरत के हिसाब से हो
इसकी सटीकनेस आठ बिट या उससे ज़्यादा होनी चाहिए
इसका स्टैंडर्ड डेविएशन 0.5 µT से ज़्यादा नहीं होना चाहिए
7.3.3. जीपीएस
डिवाइस में जीपीएस रिसीवर होना चाहिए. अगर किसी डिवाइस में जीपीएस रिसीवर
शामिल है, तो उसमें "असिस्टेड जीपीएस"
तकनीक का कोई रूप शामिल होना चाहिए, ताकि जीपीएस लॉक-ऑन के समय को कम किया जा सके.
7.3.4. जाइरोस्कोप
डिवाइस में, जायरोस्कोप (यानी ऐंगल में बदलाव का सेंसर) होना चाहिए.
डिवाइस में तब तक जायरोस्कोप सेंसर नहीं होना चाहिए, जब तक कि उसमें तीन ऐक्सिस वाला ऐक्सीलेरोमीटर भी शामिल न हो.
अगर किसी डिवाइस में घुमाव-घुमाव वाला उपकरण शामिल है, तो:

उसे तापमान के हिसाब से अडजस्ट किया जाना चाहिए
उसे 5.5*Pi
रेडियन/सेकंड (यानी, हर सेकंड में करीब 1,000 डिग्री) तक ओरिएंटेशन में होने वाले बदलावों को मेज़र करने में सक्षम होना चाहिए
इवेंट को 200 हर्ट्ज़ या उससे ज़्यादा पर डिलीवर करना चाहिए. ध्यान दें कि Android 4.1 के लिए,
जाइरोस्कोप की फ़्रीक्वेंसी को "चाहिए" के तौर पर बताया गया है. हालांकि, आने वाले वर्शन के लिए,
काम करने की शर्तों में इन फ़्रीक्वेंसी को"ज़रूरी" के तौर पर बदलने का प्लान है.
इसका मतलब है कि Android 4.1 में ये स्टैंडर्ड इस्तेमाल करना ज़रूरी नहीं है. हालांकि, आने वाले वर्शन में इनका इस्तेमाल करना
ज़रूरी होगा. Android 4.1 पर काम करने वाले मौजूदा और नए डिवाइसों के लिए
Android 4.1 में इन ज़रूरी शर्तों को पूरा करने का सुझाव दिया जाता है , ताकि
वे आने वाले समय में प्लैटफ़ॉर्म के रिलीज़ किए जाने वाले नए वर्शन पर अपग्रेड कर सकें
ज़रूरी है कि उनके पास 12-बिट या उससे ज़्यादा सटीक डेटा हो
ज़रूरी है कि उनके डेटा में हर हर्ट्ज़ (हर हर्ट्ज़ में डेटा में बदलाव,
या rad^2 / s) में 1e-7 rad^2 / s^2 से ज़्यादा का बदलाव न हो. वैरिएंस, सैंपलिंग रेट के हिसाब से अलग-अलग हो सकता है. हालांकि, यह
इस वैल्यू से ज़्यादा नहीं होना चाहिए. दूसरे शब्दों में, अगर आपने
1 हर्ट्ज़ सैंपलिंग रेट पर, जायरो के वैरिएंस को मेज़र किया है, तो यह 1e-7 rad^2/s^2 से ज़्यादा नहीं होना चाहिए.
टाइमस्टैंप, हार्डवेयर इवेंट के होने के समय के जितने करीब हो सके उतने करीब होने चाहिए
. लगातार होने वाली देरी को हटाना ज़रूरी है.
7.3.5. बैरोमीटर
डिवाइस में बैरोमीटर (यानी, एंबियंट एयर प्रेशर सेंसर) शामिल हो सकता है. अगर
डिवाइस में बैरोमीटर शामिल है, तो:
इवेंट को 5 हर्ट्ज़ या उससे ज़्यादा पर डिलीवर करना ज़रूरी है
ऊंचाई का अनुमान लगाने के लिए, सटीक जानकारी देना ज़रूरी है
तापमान के हिसाब से बदलाव करना ज़रूरी है
7.3.7. थर्मामीटर
डिवाइस में थर्मामीटर (यानी
तापमान मापने वाला सेंसर) शामिल किया जा सकता है, लेकिन ऐसा करना ज़रूरी नहीं है. अगर किसी डिवाइस में थर्मामीटर शामिल है, तो उसे
डिवाइस के सीपीयू का तापमान मेज़र करना चाहिए. यह किसी अन्य
तापमान को नहीं मापना चाहिए. (ध्यान दें कि Android 4.1 एपीआई में, इस तरह के सेंसर का इस्तेमाल नहीं किया जा सकता.)
7.3.7. फ़ोटोमीटर
डिवाइस में फ़ोटोमीटर (जैसे, स्क्रीन की रोशनी को अपने-आप घटाने-बढ़ाने वाला सेंसर) शामिल हो सकता है.
7.3.8. प्रॉक्सिमिटी सेंसर
डिवाइस में प्रॉक्सिमिटी सेंसर शामिल हो सकता है. अगर किसी डिवाइस में
प्रॉक्सिमिटी सेंसर शामिल है, तो यह ज़रूरी है कि वह ऑब्जेक्ट की निकटता को
स्क्रीन की उसी दिशा में मेज़र करे. इसका मतलब है कि प्रॉक्सिमिटी सेंसर को
स्क्रीन के आस-पास मौजूद ऑब्जेक्ट का पता लगाने के लिए ओरिएंट किया जाना चाहिए, क्योंकि इस तरह के सेंसर का मुख्य मकसद,
उपयोगकर्ता के इस्तेमाल में रहे फ़ोन का पता लगाना है. अगर किसी डिवाइस में,
किसी अन्य ओरिएंटेशन के साथ प्रॉक्सिमिटी सेंसर शामिल है, तो उसे इस एपीआई से ऐक्सेस नहीं किया जा सकता. अगर किसी डिवाइस
में प्रॉक्सिमिटी सेंसर इस्तेमाल किया जाता है, तो उसकी सटीक ता 1-बिट या इससे ज़्यादा होनी चाहिए.
7.4. डेटा कनेक्टिविटी
7.4.1. टेलीफ़ोन सेवा
Android 4.1 एपीआई में इस्तेमाल किए गए "टेलीफ़ोन सेवा" के बारे में जानकारी देने वाला दस्तावेज़. इसमें खास तौर पर,
जीएसएम या
सीडीएमए नेटवर्क की मदद से,
वॉइस कॉल करने और एसएमएस भेजने से जुड़े हार्डवेयर के बारे में बताया गया है. यह मुमकिन है कि ये वॉइस कॉल, पैकेट स्विच किए गए हों या न किए गए हों. हालांकि,
Android 4.1 के लिए, इन्हें किसी भी डेटा कनेक्टिविटी से अलग माना जाता है.
ऐसा इसलिए है, क्योंकि इन्हें उसी नेटवर्क का इस्तेमाल करके लागू किया जा सकता है. दूसरे शब्दों में, Android "टेलीफ़ोन"
फ़ंक्शन और एपीआई, खास तौर पर वॉइस कॉल और एसएमएस के बारे में बताते हैं. उदाहरण के लिए, ऐसे डिवाइस
इंप्लिकेशन जो कॉल नहीं कर सकते या एसएमएस भेज/पा सकते हैं उन्हें
"android.hardware.telephony" सुविधा या किसी भी सब-सुविधा की जानकारी नहीं देनी चाहिए. भले ही,
वे डेटा कनेक्टिविटी के लिए मोबाइल नेटवर्क का इस्तेमाल करते हों.
Android 4.1 का इस्तेमाल, उन डिवाइसों पर किया जा सकता है जिनमें टेलीफ़ोन हार्डवेयर शामिल नहीं है. इसका मतलब है कि
Android 4.1,फ़ोन के अलावा दूसरे डिवाइसों पर काम करता है. हालांकि, अगर किसी डिवाइस
में GSM या CDMA टेलीफ़ोन इंटिग्रेशन शामिल है, तो उस डिवाइस में उस टेक्नोलॉजी के एपीआई के लिए पूरी सहायता
इंटिग्रेट होनी चाहिए. जिन डिवाइसों में टेलीफ़ोन
हार्डवेयर शामिल नहीं है उन्हें सभी एपीआई को नो-ऑप के तौर पर लागू करना होगा.
7.4.2. IEEE 802.11 (वाई-फ़ाई)
Android 4.1 डिवाइस इंप्लिकेशन में, 802.11 (b/g/a/n वगैरह)
के एक या उससे ज़्यादा फ़ॉर्म के लिए, सपोर्ट शामिल होना चाहिए अगर किसी डिवाइस में 802.11 की सुविधा काम करती है, तो उसमें
उससे जुड़ा Android API इस्तेमाल किया जाना चाहिए.

डिवाइस में, मल्टीकास्ट एपीआई को SDK
दस्तावेज़ [संसाधन, 62] में बताए गए तरीके से लागू करना ज़रूरी है.जिन डिवाइसों में वाई-फ़ाई की सुविधा शामिल है
उन्हें मल्टीकास्ट डीएनएस (mDNS) के साथ काम करना चाहिए. डिवाइस पर mDNS
पैकेट (224.0.0.251) को कभी भी फ़िल्टर नहीं किया जाना चाहिए. भले ही, डिवाइस की स्क्रीन
चालू न हो.
7.4.2.1. वाई-फ़ाई डायरेक्ट
डिवाइस में वाई-फ़ाई डायरेक्ट (वाई-फ़ाई पीयर-टू-पीयर) की सुविधा होनी चाहिए. अगर
डिवाइस में वाई-फ़ाई डायरेक्ट की सुविधा काम करती है, तो उसे
SDK टूल के दस्तावेज़ [संसाधन, 68] में बताए गए तरीके के हिसाब से, उससे जुड़ा Android एपीआई लागू करना ज़रूरी है. अगर
किसी डिवाइस में वाई-फ़ाई डायरेक्ट की सुविधा काम करती है, तो:
उसमें सामान्य वाई-फ़ाई की सुविधा काम करनी चाहिए
उसमें एक साथ वाई-फ़ाई और वाई-फ़ाई डायरेक्ट की सुविधा काम करनी चाहिए
7.4.3. ब्लूटूथ
डिवाइस में ब्लूटूथ ट्रांसीवर होना चाहिए. डिवाइस में ब्लूटूथ ट्रांसीवर शामिल होने पर, SDK दस्तावेज़ [संसाधन, 42] में बताए गए तरीके से, RFCOMM-
पर आधारित ब्लूटूथ एपीआई को चालू करना ज़रूरी है.
डिवाइस के
लागू होने पर, डिवाइस के हिसाब से काम की ब्लूटूथ प्रोफ़ाइलें लागू होनी चाहिए. जैसे,A2DP,
AVRCP, OBEX वगैरह.
काम करने की जांच के लिए बने सुइट में ऐसे मामले शामिल होते हैं जिनमें Android
RFCOMM ब्लूटूथ एपीआई के बुनियादी काम को कवर किया जाता है. हालांकि, ब्लूटूथ एक डिवाइस से दूसरे डिवाइस के बीच कम्यूनिकेशन प्रोटोकॉल
है. इसलिए, इसे किसी एक डिवाइस पर चलने वाली यूनिट टेस्ट से पूरी तरह टेस्ट नहीं किया जा सकता.
इसलिए, डिवाइस को लागू करने के लिए, अनुबंध 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.1 के लिए
"चाहिए" के तौर पर बताए गए हैं. हालांकि, आने वाले वर्शन के लिए,
इन स्टैंडर्ड को "ज़रूरी है" में बदलने का प्लान है. इसका मतलब है कि
Android 4.1 में, ये स्टैंडर्ड ज़रूरी नहीं हैं, लेकिन आने वाले वर्शन में इनका पालन करना ज़रूरी होगा.
Android 4.1 पर चलने वाले मौजूदा और नए डिवाइसों को, Android 4.1 में इन
ज़रूरी शर्तों को पूरा करने का सुझाव दिया जाता है, ताकि वे आने वाले समय में
प्लैटफ़ॉर्म के रिलीज़ पर अपग्रेड कर सकें.
NfcV (ISO 15693)
को, इन पीयर-टू-
पीयर स्टैंडर्ड और प्रोटोकॉल की मदद से डेटा ट्रांसफ़र और रिसीव करने की सुविधा होनी चाहिए:
ISO 18092
LLCP 1.0 (NFC Forum ने तय किया है)
SDP 1.0 (NFC Forum ने तय किया है)
NDEF Push Protocol [Resources, 43]
SNEP 1.0 (NFC Forum ने तय किया है)
इसमें Android Beam [Resources, 65] के लिए सहायता शामिल होनी चाहिए:
SNEP डिफ़ॉल्ट सर्वर को लागू करना ज़रूरी है. डिफ़ॉल्ट SNEP सर्वर से मिले मान्य NDEF मैसेज,
android.nfc.ACTION_NDEF_DISCOVERED इंटेंट का इस्तेमाल करके,
ऐप्लिकेशन को भेजे जाने चाहिए.
सेटिंग में जाकर,
Android Beam को बंद करने पर, आने वाले NDEF
मैसेज को डिस्पैच करने की सुविधा बंद नहीं होनी चाहिए.
डिवाइस में,
android.settings.NFCSHARING_SETTINGS इंटेंट को लागू करना ज़रूरी है, ताकि

सेटिंगसंसाधन, 67] दिखें.
एनपीपी सर्वर को लागू करना ज़रूरी है. एनपीपी सर्वर को मिले मैसेज को
, SNEP के डिफ़ॉल्ट सर्वर की तरह ही प्रोसेस किया जाना चाहिए.
Android Beam चालू होने पर, डिफ़ॉल्ट SNEP सर्वर पर आउटबाउंड P2P NDEF
भेजने की कोशिश की जानी चाहिए. इसके लिए, SNEP क्लाइंट को लागू करना ज़रूरी है. अगर कोई डिफ़ॉल्ट
SNEP सर्वर नहीं मिलता है, तो क्लाइंट को किसी NPP
सर्वर पर भेजने की कोशिश करनी चाहिए.

Android.nfc.NfcAdapter.setNdefPushMessage, और
android.nfc.NfcAdapter.setNdefPushMessageCal back, और
android.nfc.NfcAdapter.enableForegroundNdefPush का इस्तेमाल करके, फ़ोरग्राउंड गतिविधियों को आउटबाउंड P2P NDEF मैसेज सेट करने की अनुमति दें.
आउटबाउंड P2P NDEF मैसेज भेजने से पहले, '
Beam करने के लिए टच करें' जैसे जेस्चर या स्क्रीन पर पुष्टि करने की सुविधा का इस्तेमाल करना चाहिए.
Android Beam को डिफ़ॉल्ट रूप से चालू करना चाहिए
जब डिवाइस
Bluetooth Object Push Profile के साथ काम करता है, तो NFC कनेक्शन को ब्लूटूथ पर ट्रांसफ़र करने की सुविधा का इस्तेमाल करना चाहिए.
android.nfc.NfcAdapter.setBeamPushUris का इस्तेमाल करते समय, डिवाइस के लागू होने की प्रक्रिया में
ब्लूटूथ से कनेक्शन हैंडओवर की सुविधा काम करनी चाहिए. इसके लिए,
एनएफ़सी फ़ोरम के"कनेक्शन हैंडओवर वर्शन 1.2" [संसाधन, 60] और "एनएफ़सी वर्शन 1.0 का इस्तेमाल करके, ब्लूटूथ से सुरक्षित तरीके से आसानी से जोड़ने की सुविधा" [संसाधन, 61] के स्पेसिफ़िकेशन लागू करें.

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

एनएफ़सी डिस्कवरी मोड में, काम करने वाली सभी टेक्नोलॉजी के लिए ज़रूर पोल करें.
डिवाइस के चालू होने पर, स्क्रीन
चालू होने और लॉक-स्क्रीन अनलॉक होने पर, एनएफ़सी डिस्कवरी मोड में होना चाहिए.
ध्यान दें कि ऊपर बताए गए JIS, ISO, और NFC फ़ोरम
के लिए, सार्वजनिक तौर पर उपलब्ध लिंक उपलब्ध नहीं हैं.
इसके अलावा, डिवाइस में इन MIFARE टेक्नोलॉजी के लिए, रीडर/राइटर्स की सुविधा शामिल की जा सकती है.

MIFARE Classic (NXP MF1S503x [Resources, 44], MF1S703x [Resources, 44])
MIFARE Ultralight (NXP MF0ICU1 [Resources, 46], MF0ICU2 [Resources, 46])
MIFARE Classic पर NDEF (NXP AN130511 [Resources, 48], AN130411
[Resources, 49])
ध्यान दें किAndroid 4.1 में इन MIFARE टाइप के लिए एपीआई शामिल हैं. अगर किसी डिवाइस पर
, रीडर/राइटर्स की भूमिका में MIFARE का इस्तेमाल किया जा सकता है, तो:

Android SDK में बताए गए तरीके के हिसाब से, उससे जुड़े Android API लागू करने होंगे

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

android.content.pm.PackageManager.hasSystemFeature() method [Resources, 37] से

android.hardware.nfc feature की जानकारी नहीं देनी चाहिए
और Android 4.1 NFC API को बिना किसी काम के लागू करना चाहिए.
android.nfc.NdefMessage और android.nfc.NdefRecord क्लास,
प्रोटोकॉल से स्वतंत्र डेटा दिखाने के फ़ॉर्मैट को दिखाती हैं. इसलिए, डिवाइस में इनका इस्तेमाल करने के लिए,
इन API को लागू करना ज़रूरी है. भले ही, इनमें NFC के लिए सहायता शामिल न हो या
android.hardware.nfc feature की जानकारी न दी गई हो.
7.4.5. नेटवर्क की कम से कम सुविधा
डिवाइस में डेटा नेटवर्किंग के एक या उससे ज़्यादा फ़ॉर्म के लिए, सहायता शामिल होनी चाहिए
. खास तौर पर, डिवाइस में कम से कम एक
डेटा स्टैंडर्ड के लिए, 200 केबीआईटी/सेकंड या उससे ज़्यादा की स्पीड का इस्तेमाल करना ज़रूरी है.
इस ज़रूरी शर्त को पूरा करने वाली टेक्नोलॉजी के उदाहरणों में, EDGE, HSPA, EV-DO, 802.11g, ईथरनेट वगैरह शामिल हैं.
जिस डिवाइस में फ़िज़िकल नेटवर्किंग स्टैंडर्ड (जैसे, ईथरनेट)
प्राइमरी डेटा कनेक्शन है उसमें कम से कम एक सामान्य
वायरलेस डेटा स्टैंडर्ड (जैसे, 802.11 (वाई-फ़ाई) के लिए भी सहायता होनी चाहिए.
डिवाइसों में, डेटा कनेक्टिविटी के एक से ज़्यादा तरीके लागू किए जा सकते हैं.

7.5. कैमरे
डिवाइस में, पीछे वाला कैमरा होना चाहिए. साथ ही, इसमें
सामने वाला कैमरा भी हो सकता है. पीछे वाला कैमरा,
डिसप्ले के सामने वाली तरफ़
के बजाय, डिवाइस की दूसरी तरफ़ होता है. इसका मतलब है कि यह
सामान्य कैमरे की तरह
, डिवाइस के दूसरी तरफ़ मौजूद ऑब्जेक्ट की फ़ोटो लेता है. सामने वाला कैमरा,
डिवाइस के डिसप्ले की ओर मौजूद होता है. इसका इस्तेमाल आम तौर पर, उपयोगकर्ता की फ़ोटो लेने के लिए किया जाता है. जैसे,
वीडियो कॉन्फ़्रेंसिंग और इससे मिलते-जुलते ऐप्लिकेशन के लिए.
7.5.1. पीछे वाला कैमरा
डिवाइस में पीछे वाला कैमरा होना चाहिए. अगर किसी डिवाइस में
पीछे की ओर फ़ोकस करने वाला कैमरा है, तो:
उसका रिज़ॉल्यूशन कम से कम दो मेगापिक्सल होना चाहिए
उसमें हार्डवेयर ऑटो-फ़ोकस या सॉफ़्टवेयर ऑटो-फ़ोकस की सुविधा होनी चाहिए
कैमरा ड्राइवर (ऐप्लिकेशन सॉफ़्टवेयर के लिए पारदर्शी) में यह सुविधा होनी चाहिए
उसमें फ़िक्स्ड-फ़ोकस या ईडीओएफ़ (एक्सटेंडेड डेप्थ ऑफ़ फ़ील्ड) हार्डवेयर हो सकता है
उसमें फ़्लैश हो सकता है. अगर कैमरे में फ़्लैश है, तो फ़्लैश लैंप
नहीं बल्कि
जब android.hardware.Camera.PreviewCal बैक इंस्टेंस को कैमरे की झलक वाले सर्फ़ेस पर रजिस्टर किया गया हो, तब ऐसा होना चाहिए. ऐसा तब तक नहीं होगा, जब तक ऐप्लिकेशन ने Camera.Parameters ऑब्जेक्ट के FLASH_MODE_AUTO या FLASH_MODE_ON एट्रिब्यूट को चालू करके,
फ़्लैश को साफ़ तौर पर चालू न किया हो.
ध्यान दें कि यह पाबंदी,
डिवाइस के पहले से मौजूद सिस्टम कैमरा ऐप्लिकेशन पर लागू नहीं होती. यह सिर्फ़ उन तीसरे पक्ष के ऐप्लिकेशन पर लागू होती है जो Camera.PreviewCallback का इस्तेमाल करते हैं.

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

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

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

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

android.graphics.ImageFormat.YV12 कंसटेंट से पता चलता है कि डिवाइस में YV12 फ़ॉर्मैट का इस्तेमाल किया जा सकता है. यह फ़ॉर्मैट,
फ़्रंट और रीयर, दोनों कैमरों की झलक दिखाने के लिए इस्तेमाल किया जा सकता है. (हार्डवेयर वीडियो डिकोडर और कैमरा,
किसी भी नेटिव पिक्सल फ़ॉर्मैट का इस्तेमाल कर सकते हैं. हालांकि, डिवाइस में YV12 में बदलाव करने की सुविधा होनी चाहिए.)

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

डिवाइस में लागू होने पर, Camera.ACTION_NEW_VIDEO इंटेंट को ब्रॉडकास्ट करना ज़रूरी है
. ऐसा तब किया जाना चाहिए, जब कैमरे से कोई नया वीडियो रिकॉर्ड किया गया हो और फ़ोटो की एंट्री को
मीडिया स्टोर में जोड़ा गया हो.
7.5.4. कैमरे का ओरिएंटेशन
अगर डिवाइस में सामने और पीछे वाला कैमरा मौजूद है, तो दोनों कैमरों का ओरिएंटेशन ऐसा होना चाहिए कि कैमरे का लंबा
डाइमेंशन, स्क्रीन के लंबे डाइमेंशन के साथ अलाइन हो. इसका मतलब है कि जब
डिवाइस को लैंडस्केप ओरिएंटेशन में रखा जाता है, तो कैमरों को
लैंडस्केप ओरिएंटेशन में इमेज कैप्चर करनी चाहिए. यह डिवाइस के नैचुरल ओरिएंटेशन के बावजूद लागू होता है; यानी
, यह लैंडस्केप-प्राइमरी डिवाइसों के साथ-साथ पोर्ट्रेट-प्राइमरी डिवाइसों पर भी लागू होता है.
7.6. मेमोरी और स्टोरेज
7.6.1. ज़रूरी मेमोरी और स्टोरेज
डिवाइस में, कम से कम 340 एमबी मेमोरी, कर्नेल
और यूज़रस्पेस के लिए उपलब्ध होनी चाहिए. 340 एमबी,
हार्डवेयर कॉम्पोनेंट के लिए तय की गई किसी भी मेमोरी के अलावा होना चाहिए. जैसे, रेडियो, वीडियो वगैरह. ये कॉम्पोनेंट,
कर्नल के कंट्रोल में नहीं होते.
डिवाइस में, ऐप्लिकेशन के निजी डेटा के लिए कम से कम 350 एमबी का नॉन-वॉल्व्यूस्ट स्टोरेज उपलब्ध होना चाहिए
. इसका मतलब है कि /data partition कम से कम 350 एमबी होना चाहिए.
Android API में एक डाउनलोड मैनेजर शामिल होता है. ऐप्लिकेशन,
डेटा फ़ाइलें डाउनलोड करने के लिए इसका इस्तेमाल कर सकते हैं [संसाधन, 56]. Download Manager को डिवाइस पर लागू करने के लिए, यह ज़रूरी है कि वह
डिफ़ॉल्ट "कैश" लोकेशन पर, कम से कम 100 एमबी साइज़ की अलग-अलग फ़ाइलें डाउनलोड कर सके.

7.6.2. ऐप्लिकेशन के लिए शेयर किया गया स्टोरेज
डिवाइस में, ऐप्लिकेशन के लिए शेयर किया गया स्टोरेज होना चाहिए. शेयर किए गए
स्टोरेज का साइज़ कम से कम 1 जीबी होना चाहिए.
डिवाइस पर,शेयर किए गए स्टोरेज को डिफ़ॉल्ट रूप से माउंट किया जाना चाहिए.
"डिवाइस पर पहले से मौजूद". अगर शेयर किया गया स्टोरेज, Linux पाथ /sdcard पर माउंट नहीं किया गया है, तो
डिवाइस में /sdcard से असल माउंट पॉइंट तक का Linux सिंबल लिंक होना चाहिए.
डिवाइस पर, शेयर किए गए इस स्टोरेज में
android.permission.WRITE_EXTERNAL_STORAGE अनुमति को, दस्तावेज़ में बताए गए तरीके से लागू करना ज़रूरी है.
अगर ऐसा नहीं है, तो शेयर किए गए स्टोरेज में कोई भी ऐप्लिकेशन, उसमें डेटा लिख सकता है जिसे
अनुमति मिली है.
डिवाइस में, उपयोगकर्ता के ऐक्सेस के लिए, हटाने लायक स्टोरेज का हार्डवेयर हो सकता है.
जैसे, Secure Digital कार्ड. इसके अलावा, डिवाइस में लागू किए गए बदलावों से,
डिवाइस का वह स्टोरेज जो हटाया नहीं जा सकता उसे ऐप्लिकेशन के लिए शेयर किया गया स्टोरेज माना जा सकता है.

डिवाइस में शेयर किए गए स्टोरेज का इस्तेमाल करने के तरीके से कोई फ़र्क़ नहीं पड़ता. डिवाइस में शेयर किए गए स्टोरेज को होस्ट
कंप्यूटर से ऐक्सेस करने के लिए, डिवाइस में कोई तरीका उपलब्ध कराना ज़रूरी है. जैसे, यूएसबी मास स्टोरेज (यूएमएस) या मीडिया ट्रांसफ़र प्रोटोकॉल (एमटीपी).
डिवाइस में शेयर किए गए स्टोरेज को ऐक्सेस करने के लिए, यूएसबी मास स्टोरेज का इस्तेमाल किया जा सकता है. हालांकि, डिवाइस में मीडिया
ट्रांसफ़र प्रोटोकॉल का इस्तेमाल करना चाहिए.
अगर डिवाइस में Media Transfer Protocol काम करता है, तो:
डिवाइस में यह सुविधा, Android
MTP होस्ट, Android फ़ाइल ट्रांसफ़र [Rसोर्स, 57] के रेफ़रंस के साथ काम करनी चाहिए.
डिवाइस में यह सुविधा, 0x00 के यूएसबी डिवाइस क्लास की जानकारी देनी चाहिए.
डिवाइस में यह सुविधा, 'MTP' के यूएसबी इंटरफ़ेस का नाम देनी चाहिए.
अगर डिवाइस में यूएसबी पोर्ट नहीं हैं, तो होस्ट कंप्यूटर को
शेयर किए गए स्टोरेज के कॉन्टेंट का ऐक्सेस, किसी दूसरे तरीके से दिया जाना चाहिए. जैसे, नेटवर्क फ़ाइल
सिस्टम.
यहां दो सामान्य उदाहरण दिए गए हैं. अगर किसी डिवाइस में,
शेयर किए गए स्टोरेज की ज़रूरी शर्तों को पूरा करने के लिए एसडी कार्ड स्लॉट शामिल किया गया है, तो डिवाइस में
1 जीबी या उससे ज़्यादा स्टोरेज वाला एफ़एटी फ़ॉर्मैट वाला एसडी कार्ड शामिल होना चाहिए. यह कार्ड, डिवाइस के साथ उपयोगकर्ताओं को बेचा जाना चाहिए और डिफ़ॉल्ट रूप से माउंट होना चाहिए.
इसके अलावा, अगर किसी डिवाइस में इस ज़रूरी शर्त को पूरा करने के लिए, डिवाइस में पहले से मौजूद
स्टोरेज का इस्तेमाल किया जाता है, तो यह स्टोरेज 1 जीबी या उससे ज़्यादा होना चाहिए. साथ ही, यह
/sdcard पर माउंट होना चाहिए. अगर इसे
किसी और जगह पर माउंट किया गया है, तो /sdcard, फ़िज़िकल लोकेशन का सिंबल लिंक होना चाहिए.
डिवाइस में एक से ज़्यादा शेयर किए गए स्टोरेज पाथ (जैसे,
एसडी कार्ड स्लॉट और शेयर किया गया इंटरनल स्टोरेज, दोनों) शामिल होने पर, मुख्य ऐप्लिकेशन में बदलाव करना चाहिए. जैसे,
मीडिया स्कैनर और ContentProvider, ताकि दोनों
जगहों पर मौजूद फ़ाइलों को साफ़ तौर पर ऐक्सेस किया जा सके.
7.7. यूएसबी
डिवाइस में यूएसबी क्लाइंट पोर्ट और
यूएसबी होस्ट पोर्ट शामिल होने चाहिए.
अगर किसी डिवाइस में यूएसबी क्लाइंट पोर्ट शामिल है, तो:
पोर्ट को स्टैंडर्ड यूएसबी-ए पोर्ट वाले यूएसबी होस्ट से कनेक्ट किया जा सकता है
डिवाइस के साइड में पोर्ट को माइक्रो यूएसबी फ़ॉर्म फ़ैक्टर का इस्तेमाल करना चाहिए. Android 4.1 पर काम करने वाले
मौजूदा और नए डिवाइसों को
Android 4.1 में इन ज़रूरी शर्तों को पूरा करने का सुझाव दिया जाता है, ताकि वे आने वाले समय में
प्लैटफ़ॉर्म के रिलीज़ पर अपग्रेड कर सकें. पोर्ट, किनारे के बीच में होना चाहिए.
डिवाइस में पोर्ट को लागू करने के लिए,
डिवाइस के सबसे नीचे (डिवाइस के
ओरिएंटेशन के हिसाब से) पोर्ट को रखा जाना चाहिए या सभी ऐप्लिकेशन (होम
स्क्रीन को भी) के लिए, सॉफ़्टवेयर स्क्रीन रोटेशन की सुविधा चालू की जानी चाहिए, ताकि डिवाइस को
पोर्ट के सबसे नीचे होने पर, डिसप्ले सही तरीके से दिखे.Android 4.1 पर काम करने वाले मौजूदा और नए डिवाइसों को बहुत
ज़ोरदार इस बात के लिए बढ़ावा दिया जाता है कि वे Android 4.1 में इन ज़रूरी शर्तों को पूरा करें, ताकि वे आने वाले समय में प्लैटफ़ॉर्म के नए वर्शन पर अपग्रेड कर सकें.
अगर डिवाइस में कोई दूसरा पोर्ट (जैसे, यूएसबी चार्जिंग पोर्ट) है, तो वह
माइक्रो-यूएसबी पोर्ट के उसी किनारे पर होना चाहिए
. यह ज़रूरी है कि डिवाइस से कनेक्ट किए गए होस्ट को,
शेयर किए गए स्टोरेज वॉल्यूम का कॉन्टेंट ऐक्सेस करने की अनुमति दी जाए. इसके लिए, यूएसबी मास स्टोरेज या मीडिया ट्रांसफ़र
प्रोटोकॉल का इस्तेमाल किया जा सकता है
. यह ज़रूरी है कि डिवाइस में Android Open Accessory API और स्पेसिफ़िकेशन को,
Android SDK के दस्तावेज़ में बताए गए तरीके के मुताबिक लागू किया जाए. साथ ही, यह भी ज़रूरी है कि डिवाइस में
हार्डवेयर की सुविधा android.hardware.usb.accessory [संसाधन, 52]के लिए सहायता का एलान किया जाए
. यह ज़रूरी है कि डिवाइस में यूएसबी ऑडियो क्लास को,
Android SDK के दस्तावेज़ में बताए गए तरीके के मुताबिक लागू किया जाए
[संसाधन, 66]. साथ ही, यह ज़रूरी है कि डिवाइस में
यूएसबी बैटरी चार्जिंग स्पेसिफ़िकेशन
[संसाधन, 64] के लिए सहायता का एलान किया जाए
. Android 4.1 पर काम करने वाले मौजूदा और नए डिवाइसों को बहुत
ज़ोरदार इस बात के लिए बढ़ावा दिया जाता है कि वे Android 4.1 में इन ज़रूरी शर्तों को पूरा करें, ताकि वे आने वाले समय में प्लैटफ़ॉर्म के नए वर्शन पर अपग्रेड कर सकें
. अगर डिवाइस में कोई यूएसबी होस्ट पोर्ट है, तो:
यह किसी ऐसे पोर्ट का इस्तेमाल कर सकता है जो स्टैंडर्ड न हो. हालांकि, अगर ऐसा है, तो डिवाइस को किसी केबल या
केबलों के साथ शिप करना ज़रूरी है, ताकि पोर्ट को स्टैंडर्ड यूएसबी-A में बदला जा सके
. यह ज़रूरी है कि डिवाइस में Android यूएसबी होस्ट एपीआई को,
Android SDK के दस्तावेज़ में बताए गए तरीके के मुताबिक लागू किया जाए. साथ ही, यह भी ज़रूरी है कि डिवाइस में
हार्डवेयर की सुविधा android.hardware.usb.host [संसाधन, 53]के लिए सहायता का एलान किया जाए
. डिवाइस में Android Debug Bridge को लागू करना ज़रूरी है. अगर किसी डिवाइस में
यूएसबी क्लाइंट पोर्ट को लागू नहीं किया गया है, तो उसे लोकल-एरिया नेटवर्क (जैसे, एथरनेट या 802.11)
के ज़रिए Android Debug Bridge
को लागू करना होगा

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

ऐप्लिकेशन
लॉन्च होने में लगने वाले समय से कम समय
लगना चाहिए.

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

9.4. ऐप्लिकेशन चलाने के लिए दूसरे एनवायरमेंट
डिवाइस में, ऐसे रनटाइम एनवायरमेंट शामिल हो सकते हैं जो Dalvik वर्चुअल मशीन या नेटिव
कोड के बजाय, किसी अन्य सॉफ़्टवेयर या टेक्नोलॉजी का इस्तेमाल करके ऐप्लिकेशन चलाते हैं.
हालांकि, ऐसे विकल्पों को ऐसे इंस्टॉल किया जाना चाहिए कि
Android सुरक्षा मॉडल या इंस्टॉल किए गए Android ऐप्लिकेशन की सुरक्षा पर कोई प्रभाव न पड़े.
इसके बारे में इस सेक्शन में बताया गया है.
वैकल्पिक रनटाइम, Android ऐप्लिकेशन होने चाहिए. साथ ही, वे
स्टैंडर्ड Android सुरक्षा मॉडल का पालन करते होने चाहिए, जैसा कि सेक्शन 9 में कहीं और बताया गया है.
अन्य रनटाइम को उन संसाधनों का ऐक्सेस नहीं दिया जाना चाहिए जिन्हें
ऐसी अनुमतियों से सुरक्षित किया गया है जिनका अनुरोध, रनटाइम की AndroidManifest.xml फ़ाइल में <uses-
permission> तंत्र की मदद से नहीं किया गया है.

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

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

CTS को किसी असली डिवाइस पर चलाने के लिए डिज़ाइन किया गया है. किसी भी सॉफ़्टवेयर की तरह, 'सीटीएस' में भी
गड़बड़ियां हो सकती हैं. CTS का वर्शन, इस 'काम करने के तरीके'
की परिभाषा से अलग होगा. साथ ही, Android 4.1 के लिए CTS के कई रिविज़न रिलीज़ किए जा सकते हैं. डिवाइस
सॉफ़्टवेयर के पूरा होने के समय, डिवाइस
को लागू करने के लिए, CTS के सबसे नए वर्शन को पास करना ज़रूरी है.
10.2. CTS पुष्टि करने वाला टूल
डिवाइस के लागू होने से, CTS
पुष्टि करने वाले टूल में सभी लागू मामलों को सही तरीके से लागू करना ज़रूरी है. CTS Verifier, Compatibility Test Suite में शामिल है. इसे
मैन्युअल ऑपरेटर चलाता है, ताकि उन सुविधाओं की जांच की जा सके जिनकी जांच
ऑटोमेटेड सिस्टम से नहीं की जा सकती. जैसे, कैमरे और सेंसर की सही तरीके से काम करना.
CTS की पुष्टि करने वाले टूल में, कई तरह के हार्डवेयर के लिए टेस्ट मौजूद हैं. इनमें कुछ ऐसे हार्डवेयर भी शामिल हैं जो
ज़रूरी नहीं हैं. डिवाइस में मौजूद हर हार्डवेयर के लिए, टेस्ट पास करना ज़रूरी है. उदाहरण के लिए, अगर किसी डिवाइस में ऐक्सेलेरोमीटर है, तो उसे सीटीएस की पुष्टि करने वाले टूल में ऐक्सेलेरोमीटर टेस्ट केस को सही तरीके से चलाना होगा.

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

Verfier टेस्ट को छोड़ा जा सकता है.
10.3. रेफ़रंस ऐप्लिकेशन
डिवाइस पर लागू करने वाले लोगों को, यहां दिए गए ओपन
सोर्स ऐप्लिकेशन का इस्तेमाल करके, यह जांच करनी होगी कि डिवाइस पर लागू करने की सुविधा काम करती है या नहीं:
"Android के लिए ऐप्लिकेशन" ऐप्लिकेशन [Resources, 55]
Replica Island (Android Market में उपलब्ध)
डिवाइस पर लागू करने की सुविधा को काम करने वाला माना जा सके, इसके लिए ऊपर दिए गए हर ऐप्लिकेशन को लॉन्च करना ज़रूरी है और यह भी ज़रूरी है कि वह डिवाइस पर सही तरीके से काम करे.

11. अपडेट किया जा सकने वाला सॉफ़्टवेयर
डिवाइस में,
सिस्टम सॉफ़्टवेयर को पूरी तरह से बदलने का तरीका शामिल होना चाहिए. इस मेकेनिज्म को "लाइव" अपग्रेड नहीं करना पड़ता - यानी, डिवाइस
को रीस्टार्ट करना पड़ सकता है.
किसी भी तरीके का इस्तेमाल किया जा सकता है. हालांकि, यह ज़रूरी है कि वह डिवाइस पर पहले से इंस्टॉल किए गए
सभी सॉफ़्टवेयर को बदल सके. उदाहरण के लिए, इनमें से कोई भी तरीका
इस ज़रूरी शर्त को पूरा करेगा:
रिबूट करने के ज़रिए ऑफ़लाइन अपडेट के साथ, ओवर-द-एयर (ओटीए) डाउनलोड
होस्ट पीसी से यूएसबी के ज़रिए"टैथर्ड" अपडेट
रिबूट करने के ज़रिए"ऑफ़लाइन" अपडेट और हटाने लायक स्टोरेज पर मौजूद फ़ाइल से अपडेट
इस्तेमाल किए गए अपडेट मैकेनिज्म में, उपयोगकर्ता के डेटा को मिटाए बिना अपडेट करने की सुविधा होनी चाहिए. इसका मतलब है कि
अपडेट करने के तरीके से,ऐप्लिकेशन का निजी डेटा और ऐप्लिकेशन का
शेयर किया गया डेटा सुरक्षित रहना चाहिए. ध्यान दें कि अपस्ट्रीम Android सॉफ़्टवेयर में अपडेट करने का एक तरीका शामिल होता है
, जो इस ज़रूरी शर्त को पूरा करता है.
अगर डिवाइस रिलीज़ होने के बाद, डिवाइस को लागू करने में कोई गड़बड़ी मिलती है, लेकिन वह
डिवाइस के उचित लाइफ़टाइम के दायरे में होती है, जो Android
के साथ काम करने वाली टीम से सलाह करने के बाद तय किया जाता है, ताकि तीसरे पक्ष के ऐप्लिकेशन के साथ काम करने की सुविधा पर असर न पड़े, तो डिवाइस को
लागू करने वाले को, उपलब्ध सॉफ़्टवेयर अपडेट की मदद से गड़बड़ी को ठीक करना ज़रूरी है. यह अपडेट, ऊपर बताए गए तरीके के हिसाब से
लागू किया जा सकता है.
12. हमसे संपर्क करें
अगर आपको इस दस्तावेज़ के बारे में ज़्यादा जानकारी चाहिए, तो compatibility@android.com पर दस्तावेज़ के लेखकों से संपर्क करें
. इसके अलावा, अगर आपको लगता है कि इस दस्तावेज़ में कोई समस्या शामिल नहीं है, तो उसके बारे में भी बताएं.

अनुबंध A - ब्लूटूथ टेस्ट प्रोसेस
काम करने की जांच करने वाले सुइट में ऐसे मामले शामिल हैं जिनमें Android
RFCOMM ब्लूटूथ एपीआई के बुनियादी काम को कवर किया गया है. हालांकि, ब्लूटूथ एक डिवाइस से दूसरे डिवाइस के बीच कम्यूनिकेशन प्रोटोकॉल
है. इसलिए, यह एक डिवाइस पर चलने वाली यूनिट टेस्ट से पूरी तरह से जांचा नहीं जा सकता.
इसलिए, डिवाइस को लागू करने के लिए, यह ज़रूरी है कि वह नीचे बताए गए, मैन्युअल तरीके से किए जाने वाले ब्लूटूथ
टेस्ट के तरीके से भी पास हो.
टेस्ट करने का तरीका, 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 ऐप्लिकेशन बंद करें. इसके लिए, होम
बटन को छह बार दबाएं.  डिवाइस के सेटिंग ऐप्लिकेशन का इस्तेमाल करके, हर डिवाइस को एक-दूसरे से अनपेयर करें
दूसरे डिवाइस से कनेक्ट करने और उससे डेटा शेयर करने की सुविधा की जांच करें
इसके लिए
1.  दोनों डिवाइसों पर, Bluetooth Chat ऐप्लिकेशन खोलें.
2.
मेन्यू का इस्तेमाल करके, BluetoothChat में जाकर, टारगेट डिवाइस को डिस्कवर किया जा सकता है.
3.  काम करने वाले डिवाइस पर, BluetoothChat
(मेन्यू का इस्तेमाल करके) में जाकर, ब्लूटूथ डिवाइसों को स्कैन करें और उस डिवाइस से जोड़ें जिसे टेस्ट करना है.
4.  हर डिवाइस से 10 या उससे ज़्यादा मैसेज भेजें और पुष्टि करें कि दूसरे डिवाइस
पर वे मैसेज सही तरीके से मिल रहे हैं.
5.  दोनों डिवाइसों पर, ब्लूटूथ चैट ऐप्लिकेशन बंद करें. इसके लिए,
लॉन्चर पर जाने के लिए, बार-बार 'वापस जाएं' बटन दबाएं.
फिर से लॉन्च करने की सुविधा को टेस्ट करना
1.  दोनों डिवाइसों पर, Bluetooth Chat ऐप्लिकेशन को फिर से लॉन्च करें.
2.  हर डिवाइस से 10 या उससे ज़्यादा मैसेज भेजें और पुष्टि करें कि दूसरे डिवाइस
पर वे मैसेज सही तरीके से मिल रहे हैं.
ध्यान दें: ऊपर दिए गए कुछ टेस्ट में, होम का इस्तेमाल करके टेस्ट सेक्शन को खत्म किया जाता है और
कुछ में, बैक का इस्तेमाल करके. ये टेस्ट ज़रूरी हैं और इन्हें करना ज़रूरी है: इनका मकसद
यह पुष्टि करना है कि गतिविधियां
साफ़ तौर पर बंद होने पर (उपयोगकर्ता के बैक बटन को दबाने पर, जो 'पूरी हो गई' के तौर पर सेट हो जाती है) और चुपचाप बैकग्राउंड में भेजे जाने पर (उपयोगकर्ता के होम बटन को दबाने पर), Bluetooth API और स्टैक सही तरीके से काम करते हैं.
हर टेस्ट सीक्वेंस
जैसा बताया गया है वैसा ही करना ज़रूरी है.