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

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

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

Android पर काम करने की सुविधा की परिभाषा: Android 1.6
Android 1.6 r2
Google Inc.
compatibility@android.com

1. परिचय
इस दस्तावेज़ में उन ज़रूरी शर्तों के बारे में बताया गया है जिन्हें पूरा करने पर, मोबाइल फ़ोन
Android 1.6 के साथ काम कर सकते हैं. इस परिभाषा में, यह माना गया है कि आप Android Compatibility Program
[संसाधन, 1] के बारे में जानते हैं.
"ज़रूरी है", "ज़रूरी नहीं है", "ज़रूरी है", "होगा", "नहीं होगा", "चाहिए", "नहीं चाहिए", "सुझाया गया",
"हो सकता है", और "ज़रूरी नहीं" शब्दों का इस्तेमाल, RFC2119 [संसाधन, 2] में बताए गए IETF स्टैंडर्ड के मुताबिक किया जाता है.
इस दस्तावेज़ में, "डिवाइस इंप्लीमेंटर" या "इंप्लीमेंटर" का मतलब ऐसे व्यक्ति या संगठन से है जो Android 1.6 पर चलने वाला हार्डवेयर/सॉफ़्टवेयर सलूशन डेवलप कर रहा है.
"डिवाइस में लागू करना" या "लागू करना",
हार्डवेयर/सॉफ़्टवेयर का ऐसा समाधान है जिसे इस तरह से बनाया गया है.
Android 1.6 के साथ काम करने के लिए, डिवाइस में ये चीज़ें होनी चाहिए:
1. इस कंपैटबिलिटी डेफ़िनिशन में बताई गई ज़रूरी शर्तों को पूरा करना ज़रूरी है. इनमें रेफ़रंस के ज़रिए शामिल किए गए दस्तावेज़ भी शामिल हैं
.
2. Android ओपन
सोर्स प्रोजेक्ट [संसाधन, 3] के तहत उपलब्ध Android Compatibility Test Suite (CTS) को पास करना ज़रूरी है. CTS, इस
दस्तावेज़ में बताए गए ज़्यादातर कॉम्पोनेंट की जांच करता है. हालांकि, सभी कॉम्पोनेंट की जांच नहीं करता.
अगर इस परिभाषा या सीटीएस में कोई जानकारी नहीं दी गई है, वह अस्पष्ट है या अधूरी है, तो डिवाइस को लागू करने वाले व्यक्ति या कंपनी की यह ज़िम्मेदारी है कि वह मौजूदा सुविधाओं के साथ काम करने की सुविधा को पक्का करे.
इस वजह से, Android ओपन
सोर्स प्रोजेक्ट [संसाधन, 4] को Android के रेफ़रंस के तौर पर इस्तेमाल किया जाता है. साथ ही, इसे Android को लागू करने का सबसे पसंदीदा तरीका भी माना जाता है. डिवाइस
को लागू करने वाले लोगों को हमारा सुझाव है कि वे Android Open Source Project से उपलब्ध "अपस्ट्रीम" सोर्स कोड
का इस्तेमाल करें. कुछ कॉम्पोनेंट को वैकल्पिक तरीके से लागू करने की कल्पना की जा सकती है. हालांकि, ऐसा करने का सुझाव नहीं दिया जाता, क्योंकि इससे सीटीएस टेस्ट पास करना
काफ़ी मुश्किल हो जाएगा.
यह पक्का करना लागू करने वाले की ज़िम्मेदारी है कि
Android के स्टैंडर्ड वर्शन के साथ, ऐप्लिकेशन पूरी तरह से काम करता हो. इसमें Compatibility Test Suite के साथ-साथ, इसके अलावा भी अन्य चीज़ें शामिल हैं.
2. संसाधन
इसमें कई संसाधनों का रेफ़रंस दिया गया है. इन्हें यहां देखा जा सकता है.
1. Android Compatibility Program के बारे में खास जानकारी: https://sites.google.com/a/android.com/compatibility/
how-it-works
2. IETF RFC2119 की ज़रूरी शर्तों के लेवल: http://www.ietf.org/rfc/rfc2119.txt
3. काम करने की जांच करने वाला सुइट: http://sites.google.com/a/android.com/compatibility/compatibility-test-
suite--cts
4. Android Open Source Project: http://source.android.com/
5. एपीआई की परिभाषाएं और दस्तावेज़: http://developer.android.com/reference/packages.html
6. कॉन्टेंट प्रोवाइडर: http://code.google.com/android/reference/android/provider/package-
summary.html
7. उपलब्ध संसाधन: http://code.google.com/android/reference/available-resources.html
8. Android मेनिफ़ेस्ट फ़ाइलें: http://code.google.com/android/devel/bblocks-manifest.html
9. Android की अनुमतियों के बारे में जानकारी: http://developer.android.com/reference/android/
Manifest.permission.html
10. बिल्ड कॉन्स्टेंट: http://developer.android.com/reference/android/os/Build.html
11. वेबव्यू: http://developer.android.com/reference/android/webkit/WebView.html
12. Gears ब्राउज़र एक्सटेंशन: http://code.google.com/apis/gears/

13. Dalvik वर्चुअल मशीन की खास जानकारी, जो सोर्स कोड
चेकआउट की dalvik/docs डायरेक्ट्री में मिलती है. यह जानकारी http://android.git.kernel.org/?p=platform/
dalvik.git;a=tree;f=docs;h=3e2ddbcaf7f370246246f9f03620a7caccbfcb12;hb=HEAD
14 पर भी उपलब्ध है. ऐप्लिकेशन विजेट: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
15. सूचनाएं: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
16. स्टेटस बार के आइकॉन के स्टाइल के लिए गाइड: http://developer.android.com/guide/practices/ui_guideline
/icon_design.html#statusbarstructure
17. Search Manager: http://developer.android.com/reference/android/app/SearchManager.html
18. टोस्ट: http://developer.android.com/reference/android/widget/Toast.html
19. Apps For Android: http://code.google.com/p/apps-for-android
20. Android APK फ़ाइल के बारे में जानकारी: http://developer.android.com/guide/topics/fundamentals.html
21. Android डीबग ब्रिज (adb): http://code.google.com/android/reference/adb.html
22. Dalvik Debug Monitor Service (ddms): http://code.google.com/android/reference/ddms.html
23. Monkey: http://developer.android.com/guide/developing/tools/monkey.html
24. डिसप्ले-इंडिपेंडेंस दस्तावेज़:
25. कॉन्फ़िगरेशन के लिए कॉन्स्टेंट: http://developer.android.com/reference/android/content/res/
Configuration.html
26. डिसप्ले मेट्रिक: http://developer.android.com/reference/android/util/DisplayMetrics.html
27. कैमरा: http://developer.android.com/reference/android/hardware/Camera.html
28. सेंसर कोऑर्डिनेट स्पेस: http://developer.android.com/reference/android/hardware/
SensorEvent.html
29. Android की सुरक्षा और अनुमतियों से जुड़ा रेफ़रंस: http://developer.android.com/guide/topics/security/
security.html
इनमें से ज़्यादातर रिसॉर्स, सीधे तौर पर या किसी और तरीके से Android 1.6 SDK टूल से लिए गए हैं. साथ ही, ये
SDK टूल के दस्तावेज़ में दी गई जानकारी से फ़ंक्शन के हिसाब से मेल खाएंगे. अगर
काम करने के तरीके की परिभाषा, SDK टूल के दस्तावेज़ से मेल नहीं खाती है, तो SDK टूल के दस्तावेज़ को
आधिकारिक माना जाता है. ऊपर दिए गए रेफ़रंस में दी गई तकनीकी जानकारी को,
'काम करने के तरीके की परिभाषा' में शामिल माना जाता है.
3. सॉफ़्टवेयर
Android प्लैटफ़ॉर्म में, मैनेज किए जा सकने वाले ("हार्ड") एपीआई का एक सेट और "सॉफ़्ट" एपीआई का एक ग्रुप शामिल होता है
. जैसे, इंटेंट सिस्टम, नेटिव-कोड एपीआई, और वेब-ऐप्लिकेशन एपीआई. इस सेक्शन में, उन हार्ड और
सॉफ़्ट एपीआई के बारे में बताया गया है जो काम करने के लिहाज़ से ज़रूरी हैं. साथ ही, इसमें कुछ अन्य काम की तकनीकी और यूज़र इंटरफ़ेस
व्यवहारों के बारे में भी बताया गया है. डिवाइस पर लागू करने के लिए, इस सेक्शन में दी गई सभी ज़रूरी शर्तों का पालन करना ज़रूरी है.
3.1. मैनेज किया गया API, डिवाइस के साथ काम करता है
Android ऐप्लिकेशन के लिए, मैनेज किया गया (Dalvik पर आधारित) एनवायरमेंट मुख्य तौर पर इस्तेमाल किया जाता है.
Android ऐप्लिकेशन प्रोग्रामिंग इंटरफ़ेस (एपीआई), Android प्लैटफ़ॉर्म के इंटरफ़ेस का सेट होता है. यह सेट, मैनेज किए जा रहे वर्चुअल मशीन (वीएम) के एनवायरमेंट में चल रहे
ऐप्लिकेशन के लिए उपलब्ध होता है. डिवाइस पर एपीआई लागू करने के लिए, यह ज़रूरी है कि Android
1.6 SDK टूल के ज़रिए एक्सपोज़ किए गए किसी भी एपीआई को पूरी तरह से लागू किया गया हो. इसमें, दस्तावेज़ में बताए गए सभी व्यवहार भी शामिल हैं. जैसे:
1.
Android की मुख्य Java-language APIs [Resources, 5].
2. कॉन्टेंट देने वाली कंपनियां [Resources, 6].
3. संसाधन [संसाधन, 7].
4. AndroidManifest.xml एट्रिब्यूट और एलिमेंट [संसाधन, 8].

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

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

android.os.Build.BOARD
का इस्तेमाल भी इसी काम के लिए किया जा सकता है. इस फ़ील्ड के लिए किसी खास फ़ॉर्मैट की ज़रूरत नहीं है.
हालांकि,यह वैल्यू शून्य या खाली स्ट्रिंग ("") नहीं होनी चाहिए.
डिवाइस लागू करने वाले व्यक्ति ने यह वैल्यू चुनी है. इससे,
android.os.Build.BRAND
कंपनी, संगठन, व्यक्ति वगैरह का नाम पता चलता है. यह नाम,
ऐसे फ़ॉर्मैट में होना चाहिए जिसे कोई भी व्यक्ति पढ़ सके. इस फ़ील्ड का इस्तेमाल, डिवाइस बेचने वाले OEM

और/या मोबाइल और इंटरनेट सेवा देने वाली कंपनी की जानकारी देने के लिए किया जा सकता है. इस फ़ील्ड के
खास फ़ॉर्मैट के लिए कोई ज़रूरी शर्त नहीं है. हालांकि, यह शर्त ज़रूरी है कि यह वैल्यू शून्य या खाली
स्ट्रिंग ("") न हो.
डिवाइस लागू करने वाले व्यक्ति ने यह वैल्यू चुनी है. इससे डिवाइस के बॉडी (इसे कभी-कभी "इंडस्ट्रियल
android.os.Build.DEVICE
डिज़ाइन" कहा जाता है) के खास
कॉन्फ़िगरेशन या रिविज़न की पहचान की जाती है. इस फ़ील्ड के लिए, किसी खास फ़ॉर्मैट
की ज़रूरत नहीं है. हालांकि, यह शून्य या खाली स्ट्रिंग ("") नहीं होनी चाहिए.
यह एक ऐसी स्ट्रिंग है जो इस बिल्ड की खास तौर पर पहचान करती है. यह
किसी व्यक्ति के लिए आसानी से पढ़ा जा सकने वाला होना चाहिए. यह इस टेंप्लेट के मुताबिक होना चाहिए:
$(PRODUCT_BRAND)/$(PRODUCT_NAME)/$(PRODUCT_DEVICE)/
$(TARGET_BOOTLOADER_BOARD_NAME):$(PLATFORM_VERSION)/
$(BUILD_ID)/$(BUILD_NUMBER):$(TARGET_BUILD_VARIANT)/
android.os.Build.FINGERPRINT
$(BUILD_VERSION_TAGS)
उदाहरण के लिए: acme/mydevicel/generic/generic:Donut/ERC77/
3359:userdebug/test-keys
फ़िंगरप्रिंट में स्पेस नहीं होने चाहिए. अगर ऊपर दिए गए
टेंप्लेट में शामिल अन्य फ़ील्ड में स्पेस हैं, तो उन्हें फ़िंगरप्रिंट में ASCII
अंडरस्कोर ("_") वर्ण से बदल दिया जाना चाहिए.
यह एक स्ट्रिंग है, जो उस होस्ट की खास पहचान करती है जिस पर बिल्ड बनाया गया था. यह स्ट्रिंग,
android.os.Build.HOST
के ऐसे फ़ॉर्मैट में होती है जिसे कोई भी व्यक्ति पढ़ सकता है. इस
फ़ील्ड के फ़ॉर्मैट के लिए कोई ज़रूरी शर्त नहीं है. हालांकि, यह शर्त ज़रूरी है कि यह शून्य या खाली स्ट्रिंग ("") न हो.
डिवाइस लागू करने वाले व्यक्ति ने किसी खास
रिलीज़ को रेफ़र करने के लिए, यह आइडेंटिफ़ायर चुना है. यह आइडेंटिफ़ायर, लोगों के पढ़ने लायक फ़ॉर्मैट में होता है. यह फ़ील्ड,
android.os.Build.VERSION.INCREMENTAL
के तौर पर सेट किया जा सकता है. हालांकि, इसकी वैल्यू
android.os.Build.ID
के तौर पर सेट की जानी चाहिए, ताकि यह असली उपयोगकर्ताओं के लिए काम की हो. इस फ़ील्ड के फ़ॉर्मैट के लिए कोई
ज़रूरी शर्त नहीं है. हालांकि, यह
शून्य या खाली स्ट्रिंग ("") नहीं होनी चाहिए.
डिवाइस लागू करने वाले व्यक्ति ने यह वैल्यू चुनी है. इसमें
डिवाइस का वह नाम होता है जो उपयोगकर्ता को पता होता है. यह नाम
android.os.Build.MODEL
वही होना चाहिए जिससे डिवाइस को मार्केट में लाया जाता है और असली उपयोगकर्ताओं को बेचा जाता है. इस फ़ील्ड के फ़ॉर्मैट के लिए कोई
ज़रूरी शर्त नहीं है. हालांकि, यह ज़रूरी है कि यह
शून्य या खाली स्ट्रिंग ("") न हो.
डिवाइस लागू करने वाले व्यक्ति ने यह वैल्यू चुनी है. इसमें डिवाइस का डेवलपमेंट
नाम या कोड नेम शामिल है. यह ज़रूरी है कि इसे कोई भी व्यक्ति पढ़ सके. हालांकि,
android.os.Build.PRODUCT
को ज़रूरी नहीं है कि असली उपयोगकर्ता देखें. इस फ़ील्ड के फ़ॉर्मैट के लिए कोई ज़रूरी शर्त नहीं है. हालांकि, यह
शून्य या
खाली स्ट्रिंग ("") नहीं होना चाहिए.
डिवाइस लागू करने वाले व्यक्ति ने टैग की जो सूची चुनी है उसे कॉमा लगाकर अलग किया गया है. इससे
बिल्ड को और बेहतर तरीके से पहचाना जा सकता है. उदाहरण के लिए, "unsigned,debug". यह फ़ील्ड
android.os.Build.TAGS
शून्य या खाली स्ट्रिंग ("") नहीं होना चाहिए. हालांकि, एक टैग (जैसे कि
"release") होना ठीक है.
android.os.Build.TIME
यह वैल्यू, बिल्ड होने के टाइमस्टैंप को दिखाती है.
डिवाइस इंप्लीमेंटर की चुनी गई वैल्यू, जो बिल्ड के रनटाइम
कॉन्फ़िगरेशन की जानकारी देती है. इस फ़ील्ड में, Android के तीन सामान्य रनटाइम कॉन्फ़िगरेशन से जुड़ी
android.os.Build.TYPE
की कोई एक वैल्यू होनी चाहिए: "user",
"userdebug" या "eng".

android.os.Build.USER
बिल्ड जनरेट करने वाले उपयोगकर्ता (या ऑटोमेटेड उपयोगकर्ता) का नाम या यूज़र आईडी. इस फ़ील्ड के फ़ॉर्मैट के लिए कोई ज़रूरी शर्त नहीं है.
हालांकि,यह शर्त ज़रूरी है कि यह शून्य या खाली स्ट्रिंग ("") न हो.

3.2.3. इंटेंट के साथ काम करने की सुविधा
Android, ऐप्लिकेशन के बीच लॉज़ली-कप्ल किए गए इंटिग्रेशन को हासिल करने के लिए इंटेंट का इस्तेमाल करता है. इस सेक्शन में,
इंटेंट पैटर्न से जुड़ी उन ज़रूरी शर्तों के बारे में बताया गया है जिन्हें डिवाइस पर लागू करने के लिए ज़रूर पूरा करना होगा.
"मान्य" का मतलब है कि डिवाइस इंप्लीमेंटर को कोई ऐसी Android गतिविधि, सेवा या अन्य
कॉम्पोनेंट देना होगा जो मैच करने वाले इंटेंट फ़िल्टर की जानकारी देता हो. साथ ही, यह
तय किए गए हर इंटेंट पैटर्न के लिए सही व्यवहार को बांधता और लागू करता हो.
3.2.3.1. मुख्य ऐप्लिकेशन इंटेंट
Android अपस्ट्रीम प्रोजेक्ट में कई मुख्य ऐप्लिकेशन तय किए गए हैं. जैसे, फ़ोन डायलर, कैलेंडर,
संपर्क सूची, संगीत प्लेयर वगैरह. डिवाइस लागू करने वाले लोग, इन ऐप्लिकेशन को
अन्य वर्शन से बदल सकते हैं.
हालांकि, ऐसे किसी भी वैकल्पिक वर्शन में, अपस्ट्रीम
प्रोजेक्ट के दिए गए इंटेंट पैटर्न का पालन करना ज़रूरी है. (उदाहरण के लिए, अगर किसी डिवाइस में कोई दूसरा संगीत प्लेयर है, तो भी उसे तीसरे पक्ष के ऐप्लिकेशन से जारी किए गए इंटेंट पैटर्न
का पालन करना होगा, ताकि कोई गाना चुना जा सके.) डिवाइस पर लागू किए गए इंटेंट, परिशिष्ट A में दिए गए सभी इंटेंट पैटर्न
के साथ काम करने चाहिए.
3.2.3.2. इंटेंट बदलना
Android एक एक्सटेंसिबल प्लैटफ़ॉर्म है. इसलिए, डिवाइस लागू करने वाले लोगों को,
अनुबंध A में बताए गए हर इंटेंट पैटर्न को तीसरे पक्ष के ऐप्लिकेशन से बदलने की अनुमति देनी होगी. अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट
, डिफ़ॉल्ट रूप से इसकी अनुमति देता है. डिवाइस इंप्लीमेंटर को सिस्टम ऐप्लिकेशन के
इन इंटेंट पैटर्न के इस्तेमाल के लिए खास अधिकार नहीं देने चाहिए. इसके अलावा, तीसरे पक्ष के ऐप्लिकेशन को
इन पैटर्न से बाइंड करने और उनका कंट्रोल लेने से भी नहीं रोकना चाहिए. इस पाबंदी में, "चुने गए" यूज़र इंटरफ़ेस को बंद करना भी शामिल है. इससे
उपयोगकर्ता को एक से ज़्यादा ऐप्लिकेशन में से किसी एक को चुनने की अनुमति मिलती है. ये सभी ऐप्लिकेशन एक ही इंटेंट पैटर्न को हैंडल करते हैं.
3.2.3.3. इंटेंट नेमस्पेस
डिवाइस इंप्लीमेंटर को ऐसा कोई भी Android कॉम्पोनेंट शामिल नहीं करना चाहिए जो किसी नए इंटेंट या
android.* नेमस्पेस में ACTION, CATEGORY या किसी अन्य मुख्य स्ट्रिंग का इस्तेमाल करके,
ब्रॉडकास्ट इंटेंट पैटर्न को लागू करता हो.
डिवाइस इंप्लीमेंटर को ऐसा कोई भी Android कॉम्पोनेंट शामिल नहीं करना चाहिए जो किसी दूसरे संगठन के पैकेज स्पेस में,
ACTION, CATEGORY या किसी अन्य मुख्य स्ट्रिंग का इस्तेमाल करके,
नए इंटेंट या ब्रॉडकास्ट इंटेंट पैटर्न को लागू करता हो. डिवाइस लागू करने वाले लोगों को, ऐपेंडिस A या B में दिए गए किसी भी इंटेंट
पैटर्न में बदलाव नहीं करना चाहिए या उसे एक्सटेंड नहीं करना चाहिए.
यह पाबंदी, सेक्शन 3.6 में बताई गई Java भाषा की क्लास के लिए तय की गई पाबंदी से मिलती-जुलती है.

3.2.3.4. ब्रॉडकास्ट इंटेंट
तीसरे पक्ष के ऐप्लिकेशन, प्लैटफ़ॉर्म पर कुछ इंटेंट ब्रॉडकास्ट करते हैं, ताकि उन्हें
हार्डवेयर या सॉफ़्टवेयर के माहौल में होने वाले बदलावों के बारे में सूचना मिल सके. Android के साथ काम करने वाले डिवाइसों को, सिस्टम के सही इवेंट के जवाब में सार्वजनिक ब्रॉडकास्ट
इंटेंट ब्रॉडकास्ट करने होंगे. ज़रूरी ब्रॉडकास्ट इंटेंट की सूची,
अनुबंध B में दी गई है. हालांकि, ध्यान दें कि SDK टूल में अन्य ब्रॉडकास्ट इंटेंट भी तय किए जा सकते हैं. इनका भी
पालन करना ज़रूरी है.
3.3. नेटिव एपीआई के साथ काम करने की सुविधा
Dalvik में चलने वाला मैनेज किया जा रहा कोड, ऐप्लिकेशन .apk फ़ाइल में दिए गए नेटिव कोड को कॉल कर सकता है. यह कोड, डिवाइस के हार्डवेयर आर्किटेक्चर के हिसाब से ELF
.so फ़ाइल के तौर पर कंपाइल किया जाता है. डिवाइस में लागू करने के लिए,
नेटिव कोड में कॉल करने के लिए, मैनेज किए जा रहे एनवायरमेंट में चल रहे कोड के लिए सहायता
नेटिव इंटरफ़ेस (JNI) सेमेटिक्स का इस्तेमाल करना ज़रूरी है. नेटिव कोड के लिए, ये एपीआई उपलब्ध होने चाहिए:
• libc (C लाइब्रेरी)
• libm (मैथ लाइब्रेरी)
• JNI इंटरफ़ेस
• libz (Zlib कम्प्रेशन)
• liblog (Android लॉगिंग)
• C++ के लिए कम से कम सहायता
• OpenGL ES 1.1
ये लाइब्रेरी, Android Open Source प्रोजेक्ट की ओर से Bionic में दिए गए वर्शन के साथ, सोर्स-कंपैटिबल (यानी हेडर के साथ काम करने वाली) और बाइनरी-कंपैटिबल (किसी दिए गए
प्रोसेसर आर्किटेक्चर के लिए) होनी चाहिए.
Bionic के लागू होने के तरीके, GNU C
लाइब्रेरी जैसे अन्य तरीकों के साथ पूरी तरह काम नहीं करते. इसलिए, डिवाइस में लागू करने वाले लोगों को Android के लागू होने के तरीके का इस्तेमाल करना चाहिए. अगर डिवाइस इंप्लीमेंटर,
इन लाइब्रेरी को लागू करने के लिए किसी दूसरे तरीके का इस्तेमाल करते हैं, तो उन्हें हेडर और बाइनरी के साथ काम करने की क्षमता की पुष्टि करनी होगी.
नेटिव कोड के साथ काम करना मुश्किल है. इसलिए, हम दोबारा कहना चाहते हैं कि डिवाइस इंप्लीमेंटर को
ऊपर दी गई लाइब्रेरी के अपस्ट्रीम इंप्लीमेंटेशन का इस्तेमाल करने का ज़रूर
सुझाव दिया जाता है, ताकि डिवाइस के साथ काम करने की सुविधा को पक्का किया जा सके.
3.4. वेब एपीआई के साथ काम करना
कई डेवलपर और ऐप्लिकेशन, अपने यूज़र इंटरफ़ेस के लिए android.webkit.WebView क्लास [Resources,
11] के व्यवहार पर भरोसा करते हैं. इसलिए, वेबव्यू को लागू करने का तरीका, Android के सभी वर्शन के साथ काम करना चाहिए
. Android ओपन सोर्स को लागू करने के लिए,
वेबव्यू को लागू करने के लिए वेबव्यू के रेंडरिंग इंजन के वर्शन का इस्तेमाल किया जाता है.
वेब ब्राउज़र के लिए, पूरी तरह से टेस्ट किए गए टेस्ट सुइट को डेवलप करना मुमकिन नहीं है. इसलिए, डिवाइस में वेबव्यू लागू करने वाले लोगों को
, वेबव्यू लागू करने के लिए WebKit के खास अपस्ट्रीम बिल्ड का इस्तेमाल करना होगा. खास तौर पर:
• Android 1.6 के लिए, वेबव्यू को अपस्ट्रीम Android Open Source Tree से 528.5+ WebKit बिल्ड का इस्तेमाल करना ज़रूरी है
. इस बिल्ड में, वेबव्यू के लिए फ़ंक्शन और सुरक्षा से जुड़ी गड़बड़ियों को ठीक करने के लिए, कुछ खास सुधार शामिल हैं.
• वेबव्यू की ओर से रिपोर्ट की गई उपयोगकर्ता एजेंट स्ट्रिंग इस फ़ॉर्मैट में होनी चाहिए:
Mozilla/5.0 (Linux; U; Android 1.6; <language>-<country>; <device
name>; Build/<build ID>) AppleWebKit/528.5+ (KHTML, like Gecko)
Version/3.1.2 Mobile Safari/525.20.1

◦ "<device name>" स्ट्रिंग,
android.os.Build.MODEL की वैल्यू जैसी होनी चाहिए
◦ "<build ID>" स्ट्रिंग, android.os.Build.ID की वैल्यू जैसी होनी चाहिए.
◦ "<language>" और "<country>" स्ट्रिंग,
देश कोड और भाषा के लिए सामान्य नियमों का पालन करनी चाहिए. साथ ही, अनुरोध के समय डिवाइस की मौजूदा स्थानीय भाषा का रेफ़रंस देनी चाहिए.

इंप्लिकेशन, स्टैंडअलोन ब्राउज़र ऐप्लिकेशन में कस्टम उपयोगकर्ता एजेंट स्ट्रिंग भेज सकते हैं.
इसके अलावा, स्टैंडअलोन ब्राउज़र किसी दूसरी ब्राउज़र टेक्नोलॉजी (जैसे,Firefox,
Opera वगैरह) पर आधारित हो सकता है हालांकि, अगर कोई अन्य ब्राउज़र ऐप्लिकेशन शिप किया जाता है, तो भी तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराया गया वेबव्यू कॉम्पोनेंट
, ऊपर बताए गए तरीके के मुताबिक WebKit पर आधारित होना चाहिए.
स्टैंडअलोन ब्राउज़र ऐप्लिकेशन में, Gears [रिसॉर्स, 12] के साथ काम करने की सुविधा शामिल होनी चाहिए. साथ ही, इसमें
HTML5 के कुछ या सभी वर्शन के साथ काम करने की सुविधा शामिल हो सकती है.
3.5. एपीआई के काम करने का तरीका
हर तरह के एपीआई (मैनेज किए गए, सॉफ़्ट, नेटिव, और वेब) का काम करने का तरीका, Android Open Source Project से उपलब्ध Android के पसंदीदा तरीके के मुताबिक होना चाहिए.

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

• डिवाइसों को किसी खास अनुमति के सेमेंटेक्स में बदलाव नहीं करना चाहिए
ऊपर दी गई सूची पूरी नहीं है. डिवाइस में अनुमतियों को लागू करने वाले लोगों को यह पक्का करना होगा कि डिवाइसों पर अनुमतियों के इस्तेमाल का तरीका
एक जैसा हो. इस वजह से, डिवाइस लागू करने वाले लोगों को सिस्टम के अहम हिस्सों को फिर से लागू करने के बजाय, जहां भी हो सके वहां
Android Open Source Project के ज़रिए उपलब्ध सोर्स कोड का इस्तेमाल करना चाहिए.
Compatibility Test Suite (CTS), प्लैटफ़ॉर्म के काम करने के तरीके की जांच करता है.
हालांकि, यह सभी चीज़ों की जांच नहीं करता. इसे लागू करने वाले व्यक्ति या कंपनी की ज़िम्मेदारी है कि वह यह पक्का करे कि यह Android
ओपन सोर्स प्रोजेक्ट के साथ काम करता हो.
3.6. एपीआई नेमस्पेस
Android, Java प्रोग्रामिंग लैंग्वेज
के मुताबिक पैकेज और क्लास नेमस्पेस के नियमों का पालन करता है. तीसरे पक्ष के ऐप्लिकेशन के साथ काम करने की सुविधा देने के लिए, डिवाइस इंप्लीमेंट करने वाले लोगों को इन पैकेज नेमस्पेस में
पाबंदी वाले बदलाव नहीं करने चाहिए (नीचे देखें):
• java.*
• javax.*
• sun.*
• android.*
• com.android.*
पाबंदी वाले बदलावों में ये शामिल हैं:
• डिवाइस के लागू होने से, Android प्लैटफ़ॉर्म पर सार्वजनिक तौर पर दिखाए गए एपीआई में बदलाव नहीं होना चाहिए
. इसके लिए, किसी भी मेथड या क्लास के हस्ताक्षर में बदलाव करना या क्लास या क्लास फ़ील्ड को हटाना ज़रूरी है.

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

• डिवाइस लागू करने वाले लोगों को ऊपर दिए गए एपीआई में, सार्वजनिक तौर पर दिखाए जाने वाले एलिमेंट (जैसे कि क्लास या
इंटरफ़ेस या मौजूदा क्लास या इंटरफ़ेस में फ़ील्ड या तरीके) नहीं जोड़ने चाहिए.
"सार्वजनिक तौर पर दिखाया गया एलिमेंट", कोई भी ऐसा कॉन्स्ट्रक्ट होता है जिसे
अपस्ट्रीम Android सोर्स कोड में "@hide" मार्कर से नहीं सजाया गया है. दूसरे शब्दों में, डिवाइस लागू करने वाले लोगों को नए एपीआई को एक्सपोज़ नहीं करना चाहिए या
ऊपर बताए गए नेमस्पेस में मौजूदा एपीआई में बदलाव नहीं करना चाहिए. डिवाइस लागू करने वाले लोग, सिर्फ़ अंदरूनी तौर पर
बदलाव कर सकते हैं. हालांकि, उन बदलावों का विज्ञापन नहीं किया जाना चाहिए या डेवलपर को उनका पता नहीं चलना चाहिए.
डिवाइस लागू करने वाले लोग, कस्टम एपीआई जोड़ सकते हैं. हालांकि, ऐसा कोई भी एपीआई किसी ऐसे नेमस्पेस में नहीं होना चाहिए जिसका मालिकाना हक
किसी दूसरे संगठन के पास हो या जो किसी दूसरे संगठन का रेफ़रंस देता हो. उदाहरण के लिए, डिवाइस लागू करने वाले लोगों को
com.google.* या मिलते-जुलते नेमस्पेस में एपीआई नहीं जोड़ने चाहिए. ऐसा सिर्फ़ Google कर सकता है. इसी तरह, Google को
अन्य कंपनियों के नेमस्पेस में एपीआई नहीं जोड़ने चाहिए.
अगर डिवाइस इंप्लीमेंटर, ऊपर दिए गए पैकेज नेमस्पेस में से किसी एक को बेहतर बनाने का सुझाव देता है, तो उसे
source.android.com पर जाना चाहिए. इसके बाद, उस साइट पर दी गई
जानकारी के मुताबिक, बदलाव और कोड में योगदान देने की प्रोसेस शुरू करनी चाहिए. जैसे,
मौजूदा एपीआई में कोई नई सुविधा जोड़ना या नया एपीआई जोड़ना.
ध्यान दें कि ऊपर बताई गई पाबंदियां, Java
प्रोग्रामिंग भाषा में एपीआई के नाम रखने के लिए तय किए गए स्टैंडर्ड नियमों के मुताबिक हैं. इस सेक्शन का मकसद, उन नियमों को दोबारा लागू करना और उन्हें इस काम करने की सुविधा की परिभाषा में शामिल करके, उन्हें ज़रूरी बनाना है
.
3.7. वर्चुअल मशीन के साथ काम करने की सुविधा
काम करने वाले Android डिवाइस में, Dalvik Executable (DEX) बाइटकोड स्पेसिफ़िकेशन और
Dalvik वर्चुअल मशीन सेमेंटेक्स [संसाधन, 13] की पूरी सुविधा होनी चाहिए.
3.8. यूज़र इंटरफ़ेस के साथ काम करना
Android प्लैटफ़ॉर्म में कुछ डेवलपर एपीआई शामिल होते हैं. इनकी मदद से, डेवलपर सिस्टम के यूज़र इंटरफ़ेस से कनेक्ट कर सकते हैं
. डिवाइस में लागू करने के लिए, डेवलपर को अपने कस्टम यूज़र इंटरफ़ेस
में ये स्टैंडर्ड यूआई एपीआई शामिल करने होंगे. इस बारे में यहां बताया गया है.
3.8.1. विजेट
Android, कॉम्पोनेंट टाइप और उससे जुड़े एपीआई और लाइफ़साइकल तय करता है. इससे ऐप्लिकेशन, असली उपयोगकर्ता को
"ऐप्लिकेशन विजेट" दिखा सकते हैं [Resources, 14]. Android Open Source के रेफ़रंस रिलीज़ में,
लॉन्चर ऐप्लिकेशन शामिल होता है. इसमें यूज़र इंटरफ़ेस एलिमेंट होते हैं, जिनकी मदद से उपयोगकर्ता, होम स्क्रीन पर
ऐप्लिकेशन विजेट जोड़ सकता है, देख सकता है, और हटा सकता है.
डिवाइस पर लागू करने वाले लोग, रेफ़रंस लॉन्चर (जैसे, होम स्क्रीन) के बजाय कोई दूसरा लॉन्चर इस्तेमाल कर सकते हैं.
अन्य लॉन्चर में, ऐप्लिकेशन विजेट के लिए पहले से मौजूद सहायता शामिल होनी चाहिए. साथ ही, लॉन्चर में सीधे तौर पर ऐप्लिकेशन विजेट जोड़ने, देखने, और हटाने के लिए, उपयोगकर्ता इंटरफ़ेस के
एलिमेंट दिखाने चाहिए. अन्य लॉन्चर में,
यह मुमकिन है कि ये यूज़र इंटरफ़ेस एलिमेंट न दिखें. हालांकि, अगर ये एलिमेंट नहीं दिखते हैं, तो डिवाइस इंप्लीमेंटर को
लॉन्चर से ऐक्सेस किया जा सकने वाला एक अलग ऐप्लिकेशन उपलब्ध कराना होगा. इस ऐप्लिकेशन की मदद से, उपयोगकर्ता
ऐप्लिकेशन विजेट जोड़ सकते हैं, देख सकते हैं, और हटा सकते हैं.

3.8.2. सूचनाएं
Android में ऐसे एपीआई शामिल हैं जिनकी मदद से डेवलपर, उपयोगकर्ताओं को अहम इवेंट की सूचना दे सकते हैं [संसाधन, 15]. डिवाइस पर सूचनाएं दिखाने की सुविधा
को लागू करने वाले लोगों को, सूचना की हर क्लास के लिए सहायता देनी होगी. जैसे: आवाज़,
वाइब्रेशन, लाइट, और स्टेटस बार.
इसके अलावा, एपीआई [रिसॉर्स, 7] या स्टेटस बार के आइकॉन के स्टाइल से जुड़े दिशा-निर्देश [रिसॉर्स, 16] में दिए गए सभी रिसॉर्स (आइकॉन, साउंड फ़ाइलें वगैरह) को सही तरीके से रेंडर करना ज़रूरी है.
डिवाइस
को लागू करने वाले, सूचनाओं के लिए
रेफ़रंस के तौर पर दिए गए Android Open Source के मुकाबले, उपयोगकर्ताओं को बेहतर अनुभव दे सकते हैं. हालांकि, सूचनाओं के लिए उपलब्ध अन्य सिस्टम को
ऊपर बताए गए मौजूदा सूचना संसाधनों के साथ काम करना चाहिए.
3.8.3. खोज
Android में एपीआई [संसाधन, 17] शामिल हैं. इनकी मदद से, डेवलपर अपने ऐप्लिकेशन में खोज की सुविधा जोड़ सकते हैं.
साथ ही, अपने ऐप्लिकेशन का डेटा ग्लोबल सिस्टम सर्च में दिखा सकते हैं. आम तौर पर, इस सुविधा में
सिस्टम-वाइड यूज़र इंटरफ़ेस होता है. इसकी मदद से, उपयोगकर्ता क्वेरी डाल सकते हैं. साथ ही, टाइप करते समय उन्हें सुझाव भी मिलते हैं. इसके अलावा, उन्हें नतीजे भी दिखते हैं.
Android API की मदद से, डेवलपर अपने ऐप्लिकेशन में खोज की सुविधा देने के लिए, इस इंटरफ़ेस का फिर से इस्तेमाल कर सकते हैं. साथ ही, वे ग्लोबल सर्च के सामान्य यूज़र इंटरफ़ेस में नतीजे दिखा सकते हैं.

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

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

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

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

कृपया ध्यान दें कि न तो Google और न ही Open Handset Alliance यह दावा करता है कि इन
कोडेक पर तीसरे पक्ष के पेटेंट का कोई असर नहीं है. जिन लोगों को इस सोर्स कोड का इस्तेमाल हार्डवेयर या
सॉफ़्टवेयर प्रॉडक्ट में करना है उन्हें सलाह दी जाती है कि इस कोड को लागू करने के लिए, उन्हें ज़रूरी पेटेंट के मालिकों से पेटेंट लाइसेंस लेने पड़ सकते हैं. इनमें ओपन सोर्स सॉफ़्टवेयर या
शेयरवेयर भी शामिल है.
ऑडियो
नाम
एन्कोडर डिकोडर की जानकारी
काम करने वाली फ़ाइलें
किसी भी
3GPP (.3gp) और
स्टैंडर्ड बिटरेट के कॉम्बिनेशन
MPEG-4 (.mp4, .m4a)
AAC LC/LTP
X
160 केबीपीएस तक और सैंपलिंग रेट वाली फ़ाइलों में मोनो/स्टीरियो कॉन्टेंट.
8 से 48 केएचज़
AAC (.aac)
मोनो/स्टीरियो कॉन्टेंट के लिए,
3GPP (.3gp) और
HE-AACv1
स्टैंडर्ड बिटरेट के कॉम्बिनेशन
MPEG-4 (.mp4, .m4a)
X
(AAC+)
96 केबीपीएस और सैंपलिंग रेट तक की फ़ाइलों के लिए काम नहीं करता.
8 से 48 केएचज़
AAC (.aac)
मोनो/स्टीरियो कॉन्टेंट के लिए,
HE-AACv2
3GPP (.3gp) और
स्टैंडर्ड बिटरेट
(बेहतर
MPEG-4 (.mp4, .m4a)
X
96 केबीपीएस तक और सैंपलिंग रेट
AAC+)
फ़ाइलों के कॉम्बिनेशन का इस्तेमाल नहीं किया जा सकता. रॉ फ़ॉर्मैट में काम नहीं करता
8 से 48 केएचज़
AAC (.aac)
AMR-NB
4.75 से 12.2 केबीपीएस सैंपल @
3GPP (.3gp) फ़ाइलें
X
X
8 केएचज़
AMR-WB
9 दरें 6.60 केबीआईटी/सेकंड से 23.85
-3GPP (.3gp) फ़ाइलें
X
केबीआईटी/सेकंड सैंपल @ 16 केएचज़
MP3
मोनो/स्टीरियो 8-320 केबीपीएस कॉन्स्टेंट MP3 (.mp3) फ़ाइलें
X
(सीबीआर) या वैरिएबल बिट रेट (वीबीआर)
टाइप 0 और 1 (.mid, .xmf,
MIDI टाइप 0 और 1. DLS वर्शन 1
MIDI
X
.mxmf). साथ ही, RTTTL/RTX
और 2. XMF और Mobile XMF.
(.rtttl, .rtx), OTA (.ota),

रिंगटोन फ़ॉर्मैट के लिए काम करता है
और iMelody (.imy)
RTTTL/RTX, OTA, और iMelody
Ogg Vorbis
.ogg
X
8- और 16-बिट लीनियर PCM (हैर्डवेयर की सीमा तक की दरें
PCM
X
WAVE
)
इमेज
फ़ाइलें
नाम
एन्कोडर डिकोडर की जानकारी
इस्तेमाल किए जा सकने वाले फ़ॉर्मैट
JPEG
X
X
base+progressive
GIF
X
PNG
X
X
BMP
X
वीडियो
फ़ाइलें
नाम
एन्कोडर डिकोडर की जानकारी
इस्तेमाल किए जा सकने वाले फ़ॉर्मैट
3GPP (.3gp)
H.263
X
X
फ़ाइलें
3GPP (.3gp)
H.264
X
और MPEG-4
(.mp4) फ़ाइलें
MPEG4
X
3GPP (.3gp) फ़ाइल
SP
7. डेवलपर टूल के साथ काम करना
डिवाइस के लागू होने के लिए, यह ज़रूरी है कि वे Android SDK में दिए गए Android डेवलपर टूल के साथ काम करते हों.
खास तौर पर, Android के साथ काम करने वाले डिवाइसों के लिए यह ज़रूरी है कि वे इनके साथ काम करते हों:
• Android Debug Bridge या adb [संसाधन, 21]
डिवाइस के लागू होने के लिए, यह ज़रूरी है कि वे Android
SDK में दिए गए सभी adb फ़ंक्शन के साथ काम करते हों. डिवाइस-साइड adb डेमन डिफ़ॉल्ट रूप से बंद होना चाहिए. हालांकि, Android Debug Bridge को चालू करने के लिए, उपयोगकर्ता के पास
ऐसा तरीका होना चाहिए जिसका इस्तेमाल किया जा सके.
• Dalvik Debug Monitor Service या ddms [संसाधन, 22]
डिवाइस में, Android SDK में बताई गई ddms की सभी सुविधाएं काम करनी चाहिए.
ddms, adb का इस्तेमाल करता है. इसलिए, ddms के लिए सहायता डिफ़ॉल्ट रूप से बंद होनी चाहिए. हालांकि, जब भी उपयोगकर्ता ने ऊपर बताए गए तरीके से Android Debug Bridge चालू किया हो, तब ddms के लिए सहायता चालू होनी चाहिए.

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

8.1. डिसप्ले
Android 1.6 में कुछ सुविधाएं शामिल हैं, जो
कुछ मामलों में अपने-आप स्केलिंग और ट्रांसफ़ॉर्मेशन की कुछ कार्रवाइयां करती हैं. इससे यह पक्का होता है कि तीसरे पक्ष के ऐप्लिकेशन, उन हार्डवेयर कॉन्फ़िगरेशन पर अच्छी तरह से काम करें जिनके लिए उन्हें खास तौर पर डिज़ाइन नहीं किया गया था [संसाधन, 24].
डिवाइसों को
इस सेक्शन में बताए गए तरीके से, इन व्यवहारों को सही तरीके से लागू करना चाहिए.
8.1.1. डिसप्ले के स्टैंडर्ड कॉन्फ़िगरेशन
इस टेबल में, Android के साथ काम करने वाले स्टैंडर्ड स्क्रीन कॉन्फ़िगरेशन की सूची दी गई है:
डायगनल
स्क्रीन साइज़
स्क्रीन डेंसिटी
स्क्रीन टाइप
चौड़ाई (पिक्सल)
ऊंचाई (पिक्सल)
लंबाई की रेंज
ग्रुप
ग्रुप
(इंच)
QVGA
240
320
2.6 - 3.0
छोटा
कम
WQVGA
240
400
3.2 - 3.5
सामान्य
कम
FWQVGA
240
432
3.5 - 3.8
सामान्य
कम
HVGA
320
480
3.0 - 3.5
सामान्य
मीडियम
WVGA
480
800
3.3 - 4.0
सामान्य
ज़्यादा
FWVGA
480
854
3.5 - 4.0
सामान्य
ज़्यादा
WVGA
480
800
4.8 - 5.5
बड़ा
मीडियम
FWVGA
480
854
5.0 - 5.8
बड़ा
मीडियम
डिवाइस को ऊपर दिए गए किसी एक स्टैंडर्ड कॉन्फ़िगरेशन के हिसाब से लागू करने के लिए, उसे कॉन्फ़िगर करना ज़रूरी है
. ऐसा करने पर, android.content.res.Configuration [Resources,
25] क्लास की मदद से, ऐप्लिकेशन को स्क्रीन का साइज़ बताया जा सकता है.
कुछ .apk पैकेज में ऐसे मेनिफ़ेस्ट होते हैं जिनमें यह जानकारी नहीं होती कि वे किसी खास डेंसिटी रेंज के साथ काम करते हैं.
ऐसे ऐप्लिकेशन चलाते समय, ये पाबंदियां लागू होती हैं:

• डिवाइस पर लागू होने वाले सभी संसाधनों को डिफ़ॉल्ट रूप से
"medium" (SDK दस्तावेज़ में इसे "mdpi" कहा जाता है) के तौर पर समझा जाना चाहिए.
• "कम" डेंसिटी वाली स्क्रीन पर काम करते समय, डिवाइस पर लागू करने के लिए, मीडियम/
mdpi एसेट को 0.75 के फ़ैक्टर से छोटा करना ज़रूरी है.
• "हाई" डेंसिटी वाली स्क्रीन पर काम करते समय, डिवाइस पर लागू करने के लिए, मीडियम/
mdpi एसेट को 1.5 गुना बढ़ाना ज़रूरी है.
• डिवाइस पर लागू करने के लिए, ऐसेट को डेंसिटी रेंज के अंदर स्केल नहीं किया जाना चाहिए. साथ ही, ऐसेट को डेंसिटी रेंज के बीच इन फ़ैक्टर के हिसाब से स्केल किया जाना चाहिए.

8.1.2. स्टैंडर्ड डिसप्ले कॉन्फ़िगरेशन के अलावा अन्य डिसप्ले कॉन्फ़िगरेशन
सेक्शन 8.2.1 में दिए गए स्टैंडर्ड कॉन्फ़िगरेशन से मेल न खाने वाले डिसप्ले कॉन्फ़िगरेशन के लिए,
ज़्यादा ध्यान देने की ज़रूरत होती है. साथ ही, उन्हें काम करने के लिए भी कुछ बदलाव करने पड़ते हैं. डिवाइस लागू करने वाले लोगों को, स्क्रीन साइज़ की बकेट, डेंसिटी,
और स्केलिंग फ़ैक्टर के लिए कैटगरी पाने के लिए, सेक्शन 12 में बताए गए तरीके के हिसाब से Android
की कम्पैटिबिलिटी टीम से संपर्क करना होगा. यह जानकारी मिलने पर, डिवाइस में इसे
तय किए गए तरीके के मुताबिक लागू करना ज़रूरी है.
ध्यान दें कि कुछ डिसप्ले कॉन्फ़िगरेशन (जैसे, बहुत बड़ी या बहुत छोटी स्क्रीन और कुछ आसपेक्ट रेशियो)
, Android 1.6 के साथ काम नहीं करते. इसलिए, डिवाइस लागू करने वाले लोगों को
, डेवलपमेंट की प्रोसेस में जल्द से जल्द Android के साथ काम करने वाली टीम से संपर्क करने का सुझाव दिया जाता है.
8.1.3. डिसप्ले मेट्रिक
डिवाइस के लागू होने पर,
android.util.DisplayMetrics [Resources, 26] में बताई गई सभी डिसप्ले मेट्रिक के लिए सही वैल्यू रिपोर्ट करनी चाहिए.
8.2. कीबोर्ड
डिवाइस में कीबोर्ड की सुविधा:
• इसमें इनपुट मैनेजमेंट फ़्रेमवर्क के लिए सहायता शामिल होनी चाहिए. इससे तीसरे पक्ष के डेवलपर, इनपुट मैनेजमेंट इंजन (जैसे, सॉफ़्ट कीबोर्ड) बना सकते हैं. इस बारे में ज़्यादा जानकारी के लिए,
developer.android.com
पर जाएं
• इसमें कम से कम एक सॉफ़्ट कीबोर्ड की सुविधा होनी चाहिए. भले ही, डिवाइस में हार्ड कीबोर्ड मौजूद हो
• इसमें अन्य सॉफ़्ट कीबोर्ड की सुविधाएं भी शामिल की जा सकती हैं
• इसमें हार्डवेयर कीबोर्ड शामिल नहीं किया जाना चाहिए. यह कीबोर्ड,
android.content.res.Configuration [Resources, 25] में बताए गए फ़ॉर्मैट (जैसे, QWERTY या 12-key)
8.3 में से किसी एक से मेल नहीं खाना चाहिए.

बिना टच वाले नेविगेशन
डिवाइस पर लागू करने के लिए:
• बिना टच वाले नेविगेशन के विकल्पों को छोड़ा जा सकता है. जैसे, ट्रैकबॉल, पांच दिशाओं वाला डायरेक्शनल पैड या
व्हील
• android.content.res.Configuration [Resources, 25] के ज़रिए, डिवाइस के हार्डवेयर की सही वैल्यू की जानकारी देनी होगी

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

android.content.res.Configuration.orientation, android.view.Display.getOrientation() या अन्य एपीआई के ज़रिए क्वेरी करने पर, डिवाइसों को अपने मौजूदा ओरिएंटेशन की सही वैल्यू रिपोर्ट करनी चाहिए.
8.5. टचस्क्रीन इनपुट
डिवाइस पर लागू करने के लिए:
• डिवाइस में टचस्क्रीन होनी चाहिए
• डिवाइस में कैपेसिटिव या रेसिस्टिव टचस्क्रीन हो सकती है
• डिवाइस पर मौजूद टचस्क्रीन के टाइप के हिसाब से, android.content.res.Configuration [Resources, 25] की वैल्यू दिखानी चाहिए
8.6.
यूएसबी
डिवाइस में यूएसबी क्लाइंट लागू करना ज़रूरी है, ताकि उसे स्टैंडर्ड यूएसबी-ए पोर्ट वाले यूएसबी होस्ट से कनेक्ट किया जा सके
• यूएसबी के ज़रिए Android Debug Bridge लागू करना ज़रूरी है (जैसा कि सेक्शन 7 में बताया गया है)
• डिवाइस में मौजूद हटाने लायक/मीडिया स्टोरेज के लिए, यूएसबी का मल्टी स्टोरेज क्लाइंट लागू करना ज़रूरी है
• डिवाइस में माइक्रो यूएसबी फ़ॉर्म फ़ैक्टर का इस्तेमाल किया जाना चाहिए
• यूएसबी मल्टी स्टोरेज स्पेसिफ़िकेशन के लिए सहायता लागू करना ज़रूरी है, ताकि डिवाइस में मौजूद हटाने लायक
या फ़िक्स्ड स्टोरेज को होस्ट पीसी से ऐक्सेस किया जा सके
• डिवाइस में कोई नॉन-स्टैंडर्ड पोर्ट शामिल किया जा सकता है. हालांकि, ऐसा करने पर डिवाइस के साथ ऐसी केबल भेजना ज़रूरी है जो कस्टम पिनआउट को स्टैंडर्ड यूएसबी-ए पोर्ट से कनेक्ट कर सके
8.7.

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

डिवाइस लागू करने वाले लोगों को, खोज के लिए खास बटन भी देना चाहिए. डिवाइस लागू करने वाले लोग या कंपनियां,
फ़ोन कॉल के लिए भेजें और खत्म करें बटन भी उपलब्ध करा सकती हैं.
8.8. वाई-फ़ाई
डिवाइस में 802.11b और 802.11g की सुविधा होनी चाहिए. साथ ही, 802.11a की सुविधा भी हो सकती है.

8.9. कैमरा
डिवाइस में कैमरा होना ज़रूरी है. डिवाइस में शामिल कैमरे के लिए:
• कम से कम 2 मेगापिक्सल का रिज़ॉल्यूशन होना चाहिए
• कैमरे के ड्राइवर में, हार्डवेयर ऑटो-फ़ोकस या सॉफ़्टवेयर ऑटो-फ़ोकस की सुविधा होनी चाहिए (ऐप्लिकेशन सॉफ़्टवेयर के लिए पारदर्शी)
• इसमें फ़िक्स्ड-फ़ोकस या EDOF (एक्सटेंडेड डेप्थ ऑफ़ फ़ील्ड) हार्डवेयर हो सकता है
• इसमें फ़्लैश हो सकता है.
अगर कैमरे में फ़्लैश है, तो कैमरे की झलक दिखाने वाले

सर्फ़ेस पर, android.hardware.Camera.PreviewCallback का कोई इंस्टेंस रजिस्टर होने के दौरान, फ़्लैश लैंप नहीं जलना चाहिए.
डिवाइस में कैमरे से जुड़े एपीआई को लागू करने के लिए, इन तरीकों का इस्तेमाल करना ज़रूरी है
[संसाधन, 27]:
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 एन्कोडिंग फ़ॉर्मैट में होना चाहिए.
(यह वह फ़ॉर्मैट है जिसका इस्तेमाल 7k हार्डवेयर फ़ैमिली नेटिव तौर पर करती है.)
इसका मतलब है कि NV21, डिफ़ॉल्ट तौर पर होना चाहिए.
8.9.1. ऑटोफ़ोकस कैमरे के बिना डिवाइस
अगर किसी डिवाइस में ऑटोफ़ोकस कैमरा नहीं है, तो डिवाइस को लागू करने वाले व्यक्ति को
इस सेक्शन में दी गई अन्य ज़रूरी शर्तें पूरी करनी होंगी. डिवाइस में Camera API को लागू करने के लिए, Android 1.6
SDK दस्तावेज़ में शामिल Camera API को सही तरीके से लागू करना ज़रूरी है. भले ही, कैमरे के हार्डवेयर की क्षमताएं कैसी भी हों.
अगर Android 1.6 वाले डिवाइस में कैमरे में ऑटो-फ़ोकस की सुविधा नहीं है, तो डिवाइस में इसे लागू करने के लिए, इन बातों का ध्यान रखना ज़रूरी है:
1. सिस्टम में, "ro.workaround.noautofocus"
नाम की रीड-ओनली सिस्टम प्रॉपर्टी होनी चाहिए. साथ ही, इसकी वैल्यू "1" होनी चाहिए. इस वैल्यू का इस्तेमाल, Android Market जैसे ऐप्लिकेशन करते हैं. इससे,
डिवाइस की सुविधाओं की चुनिंदा पहचान की जा सकती है. साथ ही, Android के आने वाले वर्शन में इसे
बेहतर एपीआई से बदल दिया जाएगा.
2. अगर कोई ऐप्लिकेशन android.hardware.Camera.autoFocus() को कॉल करता है, तो सिस्टम को रजिस्टर किए गए किसी भी
android.hardware.Camera.AutoFocusCallback इंस्टेंस पर
onAutoFocus() कॉलबैक मेथड को कॉल करना होगा. भले ही, असल में फ़ोकस न हुआ हो
. ऐसा इसलिए किया जाता है, ताकि मौजूदा ऐप्लिकेशन, ऑटोफ़ोकस
कॉलबैक के लिए हमेशा इंतज़ार न करते रहें, जो कभी नहीं आएगा.
3. AutoFocusCallback.onAutoFocus() तरीके को कॉल करने के लिए, ड्राइवर या
फ़्रेमवर्क को मुख्य फ़्रेमवर्क Looper थ्रेड पर नए इवेंट में ट्रिगर करना ज़रूरी है. इसका मतलब है कि Camera.autoFocus()
को सीधे AutoFocusCallback.onAutoFocus() को कॉल नहीं करना चाहिए, क्योंकि इससे Android
फ़्रेमवर्क थ्रेडिंग मॉडल का उल्लंघन होता है और ऐप्लिकेशन काम नहीं करते.
8.10. ऐक्सेलेरोमीटर
डिवाइस में, तीन ऐक्सिस वाला ऐक्सेलेरोमीटर होना चाहिए. साथ ही, यह कम से कम 50 हर्ट्ज़ पर इवेंट डिलीवर कर सकता हो. ऐक्सेलेरोमीटर में इस्तेमाल किया जाने वाला कोऑर्डिनेट सिस्टम, Android सेंसर के कोऑर्डिनेट सिस्टम के मुताबिक होना चाहिए. इस बारे में Android APIs [Resources, 28] में बताया गया है.

8.11. कंपास
डिवाइस में तीन ऐक्सिस वाला कंपास होना चाहिए. साथ ही, यह कम से कम
10 हर्ट्ज़ पर इवेंट डिलीवर कर सकता हो. कंपास में इस्तेमाल किया जाने वाला कोऑर्डिनेट सिस्टम, Android API [Resources, 28] में बताए गए Android सेंसर कोऑर्डिनेट
सिस्टम के मुताबिक होना चाहिए.
8.12. जीपीएस
डिवाइस में जीपीएस होना ज़रूरी है. साथ ही, जीपीएस लॉक-ऑन के समय को कम करने के लिए, "असिस्टेड जीपीएस"
तकनीक का इस्तेमाल किया जाना चाहिए.
8.13. टेलीफ़ोन सेवा
डिवाइस में ये चीज़ें होनी चाहिए:
• डिवाइस में GSM या CDMA टेलीफ़ोन सेवा होनी चाहिए
• डिवाइस में सही एपीआई होने चाहिए. इनके बारे में ज़्यादा जानकारी के लिए,
developer.android.com पर Android SDK दस्तावेज़ देखें
ध्यान दें कि इस ज़रूरी शर्त का मतलब है कि फ़ोन के अलावा दूसरे डिवाइस, Android 1.6 के साथ काम नहीं करते. Android
1.6 वाले डिवाइसों में टेलीफ़ोन सेवा का हार्डवेयर होना चाहिए. फ़ोन के अलावा अन्य
डिवाइसों के बारे में जानकारी के लिए, कृपया परिशिष्ट C देखें.
8.14. आवाज़ कंट्रोल करने की सुविधा
Android के साथ काम करने वाले डिवाइसों में, उपयोगकर्ता को ऑडियो की आवाज़ कम या ज़्यादा करने की सुविधा होनी चाहिए.
डिवाइस पर लागू होने के बाद,ये फ़ंक्शन उपयोगकर्ता के लिए हर समय उपलब्ध होने चाहिए.
इससे कोई फ़र्क़ नहीं पड़ता कि ऐप्लिकेशन की स्थिति क्या है. ये फ़ंक्शन,फ़िज़िकल हार्डवेयर बटन,
सॉफ़्टवेयर, जेस्चर, टच पैनल वगैरह का इस्तेमाल करके लागू किए जा सकते हैं. हालांकि, ये फ़ंक्शन हमेशा ऐक्सेस किए जा सकने चाहिए और ऐप्लिकेशन के डिसप्ले एरिया (ऊपर दिए गए डिसप्ले देखें) को छिपाने या उसमें रुकावट पैदा करने वाले नहीं होने चाहिए.

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

इसकी जांच CTS करता है.
इन ऐप्लिकेशन
लॉन्च होने में लगने वाला समय,
ऐप्लिकेशन के लिए तय किए गए समय
में पूरा हो जाना चाहिए.
ऐप्लिकेशन के लॉन्च होने में लगने वाला समय
ब्राउज़र: 1300 मिलीसेकंड से कम
एमएमएस/एसएमएस: 700 मिलीसेकंड से कम
Dalvik VM में Android पैकेज लोड करने और onCreate को कॉल करने में लगने वाला समय भी शामिल है.

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

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

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

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

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

'काम करने की सुविधा' की इस परिभाषा के बारे में ज़्यादा जानने और इस पर सुझाव/राय देने या शिकायत करने के लिए, Android की काम करने की सुविधा से जुड़ी टीम से compatibility@android.com पर संपर्क करें.

इस्तेमाल किया जाता है
EXTRA_CREATE_DESCRIPTION
SHOW_OR_CREATE_CONTACT
नया संपर्क बनाने के लिए उपयोगकर्ता को

दिखाए जाने वाले
ब्यौरे की सटीक जानकारी देने के लिए.
SHOW_OR_CREATE_CONTACT
के साथ इस्तेमाल किया जाता है
EXTRA_FORCE_CREATE
अगर कोई
मैच करने वाला संपर्क नहीं मिलता है, तो नया संपर्क बनाने के लिए ज़बरदस्ती.
यह इंटेंट तब ट्रिगर होता है, जब
SEARCH_SUGGESTION_CLICKED
खोज के सुझाव पर क्लिक किया जाता है.
यह इंटेंट तब ट्रिगर होता है, जब
SEARCH_SUGGESTION_CREATE_CONTACT_CLICKED संपर्क बनाने के लिए खोज के सुझाव
पर क्लिक किया जाता है.
यह इंटेंट तब ट्रिगर होता है, जब
SEARCH_SUGGESTION_DIAL_NUMBER_CLICKED
किसी नंबर को डायल करने के लिए खोज के सुझाव
पर क्लिक किया जाता है.
इनपुट के तौर पर, mailto:
SHOW_OR_CREATE_CONTACT
या tel: स्कीम के साथ डेटा यूआरआई लेता है.

अनुबंध B: ब्रॉडकास्ट के लिए ज़रूरी इंटेंटध्यान दें: यह सूची अभी तक पूरी नहीं है. इसे
आने वाले समय में अपडेट किया जाएगा.
इंटेंट ऐक्शन
ब्यौरा
ब्रॉडकास्ट ऐक्शन: यह
ACTION_BOOT_COMPLETED
सिस्टम के बूट होने के बाद, एक बार ब्रॉडकास्ट किया जाता है.
ब्रॉडकास्ट ऐक्शन: यह एक बार ब्रॉडकास्ट होता है, जब
ACTION_CALL_BUTTON
कॉल मिलता है.
ब्रॉडकास्ट ऐक्शन: "कैमरा बटन"
ACTION_CAMERA_BUTTON
दबाया गया.
ब्रॉडकास्ट ऐक्शन:
ACTION_CONFIGURATION_CHANGED
डिवाइस का कॉन्फ़िगरेशन (ओरिएंटेशन, स्थानीय भाषा वगैरह)
बदल गया है.
ACTION_DATE_CHANGED
ब्रॉडकास्ट ऐक्शन: तारीख बदल गई है.
ब्रॉडकास्ट ऐक्शन: डिवाइस में कम स्टोरेज होने की जानकारी देता है
ACTION_DEVICE_STORAGE_LOW

ब्रॉडकास्ट ऐक्शन: डिवाइस में कम स्टोरेज होने की जानकारी देता है
ACTION_DEVICE_STORAGE_OK

ब्रॉडकास्ट ऐक्शन: वायर वाला हेडसेट प्लग इन है या
ACTION_HEADSET_PLUG
प्लग आउट है.
ब्रॉडकास्ट ऐक्शन: इनपुट का तरीका बदला गया है
ACTION_INPUT_METHOD_CHANGED
है.
ब्रॉडकास्ट ऐक्शन: एसडी कार्ड स्लॉट से बाहरी मीडिया
ACTION_MEDIA_BAD_REMOVAL
हटाया गया था, लेकिन माउंट पॉइंट को
अनमाउंट नहीं किया गया था.
ब्रॉडकास्ट ऐक्शन: "मीडिया बटन"
ACTION_MEDIA_BUTTON
दबाया गया.
ब्रॉडकास्ट ऐक्शन: बाहरी मीडिया मौजूद है और
डिस्क की जांच की जा रही है
ACTION_MEDIA_CHECKING के लिए माउंट पॉइंट का पाथ
जांच किए जा रहे मीडिया में मौजूद है
Intent.mData फ़ील्ड में.
ब्रॉडकास्ट ऐक्शन: उपयोगकर्ता ने
ACTION_MEDIA_EJECT
बाहरी स्टोरेज मीडिया को हटाने की इच्छा जताई है.
ब्रॉडकास्ट ऐक्शन: बाहरी मीडिया मौजूद है और
ACTION_MEDIA_MOUNTED
अपने माउंट पॉइंट पर माउंट किया गया है.
ब्रॉडकास्ट ऐक्शन: बाहरी मीडिया मौजूद है, लेकिन
वह काम न करने वाले फ़ाइल सिस्टम का इस्तेमाल कर रहा है (या खाली है)
ACTION_MEDIA_NOFS
के लिए पाथ, मीडिया की जांच करने के लिए माउंट पॉइंट है
जो Intent.mData फ़ील्ड में मौजूद है.
ब्रॉडकास्ट ऐक्शन: बाहरी मीडिया को
ACTION_MEDIA_REMOVED
हटाया गया है.
ब्रॉडकास्ट ऐक्शन: मीडिया स्कैनर ने
ACTION_MEDIA_SCANNER_FINISHED
किसी डायरेक्ट्री को स्कैन करना पूरा कर लिया है.
ब्रॉडकास्ट ऐक्शन: मीडिया स्कैनर से
ACTION_MEDIA_SCANNER_SCAN_FILE
किसी फ़ाइल को स्कैन करने और उसे मीडिया डेटाबेस में जोड़ने का अनुरोध करें.

ब्रॉडकास्ट ऐक्शन: मीडिया स्कैनर ने डायरेक्ट्री को
ACTION_MEDIA_SCANNER_STARTED
स्कैन करना शुरू कर दिया है.
ब्रॉडकास्ट ऐक्शन: एक्सटर्नल मीडिया को अनमाउंट किया गया है
ACTION_MEDIA_SHARED
इसकी वजह यह है कि इसे यूएसबी स्टोरेज के ज़रिए शेयर किया जा रहा है.
ब्रॉडकास्ट ऐक्शन: बाहरी मीडिया मौजूद है, लेकिन
ACTION_MEDIA_UNMOUNTABLE
को माउंट नहीं किया जा सकता.
ब्रॉडकास्ट ऐक्शन: बाहरी मीडिया मौजूद है, लेकिन
ACTION_MEDIA_UNMOUNTED
अपने माउंट पॉइंट पर माउंट नहीं है.
ब्रॉडकास्ट ऐक्शन: कोई आउटगोइंग कॉल
ACTION_NEW_OUTGOING_CALL
किया जा रहा है.
ब्रॉडकास्ट ऐक्शन: डिवाइस पर कोई नया ऐप्लिकेशन पैकेज
ACTION_PACKAGE_ADDED
इंस्टॉल किया गया है.
ब्रॉडकास्ट ऐक्शन: किसी मौजूदा ऐप्लिकेशन पैकेज
ACTION_PACKAGE_CHANGED
में बदलाव किया गया है. उदाहरण के लिए, किसी कॉम्पोनेंट को
चालू या बंद किया गया है.
ब्रॉडकास्ट ऐक्शन: उपयोगकर्ता ने
किसी पैकेज का डेटा मिटा दिया है. इसकी शुरुआत
ACTION_PACKAGE_RESTARTED से होनी चाहिए. इसके बाद,
ACTION_PACKAGE_DATA_CLEARED
से, ऐप्लिकेशन का सारा डेटा मिट जाता है और यह
ब्रॉडकास्ट भेजा जाता है. ध्यान दें कि मंज़ूरी पा चुके पैकेज को
यह ब्रॉडकास्ट नहीं मिलता. डेटा में
पैकेज का नाम शामिल होता है.
ब्रॉडकास्ट ऐक्शन: डिवाइस से कोई मौजूदा ऐप्लिकेशन पैकेज
हटाया गया है.
ACTION_PACKAGE_REMOVED
में पैकेज का नाम शामिल होता है. इंस्टॉल किए जा रहे पैकेज
को यह इंटेंट नहीं मिलता.
ब्रॉडकास्ट ऐक्शन: किसी ऐप्लिकेशन का नया वर्शन
ACTION_PACKAGE_REPLACED
पैकेज इंस्टॉल किया गया है. इससे, पहले से इंस्टॉल किए गए
वर्शन की जगह नया वर्शन ले लेता है.
ब्रॉडकास्ट ऐक्शन: उपयोगकर्ता ने कोई
पैकेज रीस्टार्ट किया है और उसकी सभी प्रोसेस बंद कर दी हैं.
इससे जुड़ी सभी रनटाइम स्टेटस (प्रोसेस,
ACTION_PACKAGE_RESTARTED
अलार्म, सूचनाएं वगैरह) हटा दी जानी चाहिए. ध्यान दें कि
फिर से शुरू किए गए पैकेज को यह ब्रॉडकास्ट नहीं मिलता.
डेटा में
पैकेज का नाम होता है.
ब्रॉडकास्ट ऐक्शन: कॉन्टेंट उपलब्ध कराने वाली कुछ कंपनियों के पास अपने नेमस्पेस के ऐसे हिस्से होते हैं जहां वे नए
ACTION_PROVIDER_CHANGED
इवेंट या आइटम पब्लिश करती हैं. इनमें ऐसे आइटम या इवेंट शामिल होते हैं जिनमें उपयोगकर्ता की
खास तौर पर दिलचस्पी हो सकती है.

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

ब्रॉडकास्ट ऐक्शन: डिवाइस, यूएसबी
ACTION_UMS_DISCONNECTED
मास स्टोरेज मोड से बाहर निकल गया है.
ब्रॉडकास्ट ऐक्शन: डिवाइस के चालू होने के बाद, उपयोगकर्ता के मौजूद होने पर
ACTION_USER_PRESENT
(उदाहरण के लिए, जब कीगार्ड
हट जाता है) भेजा जाता है.
ब्रॉडकास्ट ऐक्शन: सिस्टम का मौजूदा वॉलपेपर
ACTION_WALLPAPER_CHANGED
बदल गया है.
ACTION_TIME_CHANGED
ब्रॉडकास्ट ऐक्शन: समय सेट किया गया.
ACTION_TIME_TICK
ब्रॉडकास्ट ऐक्शन: मौजूदा समय बदल गया है.
ACTION_TIMEZONE_CHANGED
ब्रॉडकास्ट ऐक्शन: टाइमज़ोन बदल गया है.
ब्रॉडकास्ट ऐक्शन: बैटरी चार्ज होने की स्थिति या चार्ज
ACTION_BATTERY_CHANGED
लेवल बदल गया है.
ब्रॉडकास्ट ऐक्शन: डिवाइस पर बैटरी कम होने की स्थिति
ACTION_BATTERY_LOW
के बारे में बताता है. यह ब्रॉडकास्ट,
"बैटरी कम होने की चेतावनी" सिस्टम डायलॉग से जुड़ा है.
ब्रॉडकास्ट ऐक्शन: इससे पता चलता है कि बैटरी कम होने के बाद
अब ठीक है. बैटरी
के ठीक होने पर, ACTION_BATTERY_LOW के बाद
ACTION_BATTERY_OKAY
भेजा जाएगा.
नेटवर्क की स्थिति
इंटेंट ऐक्शन
ब्यौरा
ब्रॉडकास्ट इंटेंट ऐक्शन, जो बताता है कि
NETWORK_STATE_CHANGED_ACTION
वाई-फ़ाई कनेक्टिविटी की स्थिति बदल गई है.
ब्रॉडकास्ट इंटेंट ऐक्शन, जो बताता है कि
RSSI_CHANGED_ACTION
आरएसएसआई (सिग्नल की क्षमता) बदल गई है.
ब्रॉडकास्ट इंटेंट ऐक्शन, जो बताता है कि
SUPPLICANT_STATE_CHANGED_ACTION
सुप्लीकेंट से कनेक्शन
बना है या टूट गया है.
ब्रॉडकास्ट इंटेंट ऐक्शन, जिससे पता चलता है कि वाई-फ़ाई
WIFI_STATE_CHANGED_ACTION
चालू, बंद,चालू किया जा रहा है,
बंद किया जा रहा है या इसकी स्थिति पता नहीं है.
कॉन्फ़िगर किए गए नेटवर्क के नेटवर्क आईडी
NETWORK_IDS_CHANGED_ACTION
बदल सकते हैं.
ब्रॉडकास्ट इंटेंट ऐक्शन, जो बताता है कि बैकग्राउंड डेटा के इस्तेमाल के लिए
ACTION_BACKGROUND_DATA_SETTING_CHANGED सेटिंग की वैल्यू
बदल गई हैं.
ब्रॉडकास्ट इंटेंट, जिससे पता चलता है कि
CONNECTIVITY_ACTION
नेटवर्क कनेक्टिविटी में बदलाव हुआ है.
ब्रॉडकास्ट ऐक्शन: उपयोगकर्ता ने फ़ोन को
ACTION_AIRPLANE_MODE_CHANGED
हवाई जहाज़ मोड में या उससे बाहर स्विच किया है.

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

2. ब्लूटूथ के साथ काम करना
Android 1.6 रिलीज़ में ब्लूटूथ एपीआई काम नहीं करते. इसलिए, काम करने के लिहाज़ से
ब्लूटूथ, प्लैटफ़ॉर्म के इस वर्शन के लिए कोई शर्त नहीं लगाता. हालांकि, Android के आने वाले वर्शन में
ब्लूटूथ एपीआई उपलब्ध होंगे. इसके बाद,
काम करने के लिए, ब्लूटूथ की सुविधा होना ज़रूरी हो जाएगा.
इसलिए, हमारा सुझाव है कि Android 1.6 वाले डिवाइसों में ब्लूटूथ की सुविधा हो, ताकि वे
Android के उन वर्शन के साथ काम कर सकें जिनमें ब्लूटूथ की ज़रूरत होती है.
3. ज़रूरी हार्डवेयर कॉम्पोनेंट
सेक्शन 8 में बताए गए सभी हार्डवेयर कॉम्पोनेंट (इनमें वाई-फ़ाई, मैग्नेटोमीटर/कम्पास, ऐक्सीलेरोमीटर वगैरह शामिल हैं)
ज़रूरी हैं और इन्हें हटाया नहीं जा सकता. Android के आने वाले वर्शन में,
इनमें से कुछ कॉम्पोनेंट को ज़रूरी नहीं माना जाएगा. साथ ही, तीसरे पक्ष के डेवलपर के लिए इन बदलावों को मैनेज करने के लिए,
इससे जुड़े टूल भी उपलब्ध कराए जाएंगे.
4. ऐप्लिकेशन के सैंपल
Android के आने वाले वर्शन के लिए, काम करने की शर्तों के बारे में बताने वाले दस्तावेज़ में, ऊपर दिए गए सेक्शन 4 में दी गई सूची के मुकाबले, ऐप्लिकेशन की ज़्यादा और
काम की सूची शामिल होगी. Android 1.6 के लिए,
सेक्शन 4 में दिए गए ऐप्लिकेशन की जांच करना ज़रूरी है.
5. टचस्क्रीन
'संगतता की परिभाषा' के आने वाले वर्शन में, डिवाइसों में टचस्क्रीन की ज़रूरत हो सकती है या नहीं.
हालांकि, फ़िलहाल Android फ़्रेमवर्क के ज़्यादातर वर्शन में,
टचस्क्रीन की मौजूदगी का अनुमान लगाया जाता है. टचस्क्रीन को हटाने से, तीसरे पक्ष के सभी मौजूदा Android ऐप्लिकेशन काम नहीं करेंगे.
इसलिए, Android 1.6 में, डिवाइस के साथ काम करने के लिए टचस्क्रीन ज़रूरी है.

6. परफ़ॉर्मेंस
CTS के आने वाले वर्शन में, किसी सुविधा को लागू करने के लिए, सीपीयू के इस्तेमाल और इन कॉम्पोनेंट की परफ़ॉर्मेंस का भी आकलन किया जाएगा:
• 2D ग्राफ़िक्स
• 3D ग्राफ़िक्स
• वीडियो चलाना
• ऑडियो चलाना
• Bluetooth A2DP चलाना

दस्तावेज़ की आउटलाइन