Android 13 के साथ काम करने की परिभाषा

1. परिचय

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

RFC2119 में बताए गए IETF स्टैंडर्ड के मुताबिक, "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", और "OPTIONAL" का इस्तेमाल किया जाता है.

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

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

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

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

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

1.1 दस्तावेज़ का स्ट्रक्चर

1.1.1. डिवाइस के टाइप के हिसाब से ज़रूरी शर्तें

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

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

1.1.2. ज़रूरी शर्त का आईडी

ज़रूरी शर्तों के लिए, ज़रूरी शर्त आईडी असाइन किया जाता है.

• यह आईडी सिर्फ़ ज़रूरी शर्तों के लिए असाइन किया जाता है.
• ज़रूरी शर्तों को [SR] के तौर पर मार्क किया जाता है, लेकिन कोई आईडी असाइन नहीं किया जाता.
• आईडी में ये चीज़ें शामिल होती हैं : डिवाइस टाइप आईडी - स्थिति आईडी - ज़रूरी शर्त आईडी (उदाहरण के लिए, C-0-1).

हर आईडी को यहां बताया गया है:

• डिवाइस टाइप आईडी (ज़्यादा जानकारी के लिए, 2. डिवाइस टाइप)
  • C: मुख्य (Android डिवाइस पर लागू होने वाली ज़रूरी शर्तें)
  • H: Android हैंडहेल्ड डिवाइस
  • T: Android टेलीविज़न डिवाइस
  • जवाब: Android Automotive को लागू करना
  • W: Android Watch पर लागू करना
  • टैब: Android टैबलेट पर लागू करना
• शर्त का आईडी
  • अगर शर्त बिना किसी शर्त के लागू होती है, तो यह आईडी 0 पर सेट होता है.
  • जब शर्तें लागू होती हैं, तो पहली शर्त के लिए 1 असाइन किया जाता है. साथ ही, एक ही सेक्शन और एक ही डिवाइस टाइप में संख्या 1 बढ़ जाती है.
• ज़रूरी शर्त का आईडी
  • यह आईडी 1 से शुरू होता है और एक ही सेक्शन और एक ही शर्त में, एक से बढ़कर एक होता जाता है.

1.1.3. सेक्शन 2 में ज़रूरी शर्त का आईडी

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

सेक्शन आईडी के बाद, ऊपर बताए गए ज़रूरी शर्तों का आईडी होता है.

• सेक्शन 2 में मौजूद आईडी में ये चीज़ें शामिल होती हैं: सेक्शन आईडी / डिवाइस टाइप आईडी - स्थिति आईडी - ज़रूरी शर्त आईडी (उदाहरण के लिए, 7.4.3/A-0-1).

2. डिवाइस टाइप

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

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

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

2.1 डिवाइस कॉन्फ़िगरेशन

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

2.2. हाथ से इस्तेमाल करने की ज़रूरी शर्तें

Android हैंडहेल्ड डिवाइस से, ऐसे Android डिवाइस का मतलब है जिसका इस्तेमाल आम तौर पर हाथ में रखकर किया जाता है. जैसे, एमपी3 प्लेयर, फ़ोन या टैबलेट.

Android डिवाइस को हैंडहेल्ड के तौर पर तब ही माना जाता है, जब वह इन सभी शर्तों को पूरा करता हो:

• इसमें बैटरी जैसा कोई पावर सोर्स होना चाहिए.
• डिवाइस की डायगनल स्क्रीन का साइज़ 3.3 इंच (या एपीआई लेवल 29 या उससे पहले के वर्शन पर शिप किए गए डिवाइसों के लिए 2.5 इंच) से 8 इंच के बीच होना चाहिए.

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

2.2.1. हार्डवेयर

हैंडहेल्ड डिवाइस पर लागू करने के लिए:

• [7.1.1.1/H-0-1] इसमें कम से कम एक ऐसा डिसप्ले होना चाहिए जो Android के साथ काम करता हो और इस दस्तावेज़ में बताई गई सभी ज़रूरी शर्तों को पूरा करता हो.

• [7.1.1.3/H-SR-1] उपयोगकर्ताओं को डिसप्ले साइज़ (स्क्रीन डेंसिटी) बदलने की सुविधा देने का ज़रूर सुझाव दिया जाता है.

• [7.1.1.1/H-0-2] यह ज़रूरी है कि डिवाइस में, कम से कम डिवाइस में पहले से मौजूद किसी भी डिसप्ले के सबसे ज़्यादा रिज़ॉल्यूशन के बराबर के ग्राफ़िक बफ़र के लिए, जीपीयू कॉम्पोज़िशन की सुविधा काम करती हो.

अगर हैंडहेल्ड डिवाइस पर, सॉफ़्टवेयर की मदद से स्क्रीन को घुमाने की सुविधा काम करती है, तो:

• [7.1.1.1/H-1-1]* तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराई गई लॉजिकल स्क्रीन के छोटे किनारों की लंबाई कम से कम दो इंच और लंबे किनारों की लंबाई कम से कम 2.7 इंच होनी चाहिए. Android के एपीआई लेवल 29 या उससे पहले के वर्शन पर शिप किए गए डिवाइसों को, इस ज़रूरी शर्त से छूट मिल सकती है.

अगर हैंडहेल्ड डिवाइस पर, सॉफ़्टवेयर की मदद से स्क्रीन घुमाने की सुविधा काम नहीं करती है, तो:

• [7.1.1.1/H-2-1]* तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराई गई लॉजिकल स्क्रीन के छोटे किनारे की लंबाई कम से कम 2.7 इंच होनी चाहिए. Android के एपीआई लेवल 29 या उससे पहले के वर्शन पर शिप किए गए डिवाइसों को, इस ज़रूरी शर्त से छूट मिल सकती है.

अगर हैंडहेल्ड डिवाइस पर Configuration.isScreenHdr() के ज़रिए, हाई डाइनैमिक रेंज डिसप्ले के साथ काम करने का दावा किया जाता है, तो:

• [7.1.4.5/H-1-1] EGL_EXT_gl_colorspace_bt2020_pq, EGL_EXT_surface_SMPTE2086_metadata, EGL_EXT_surface_CTA861_3_metadata, VK_EXT_swapchain_colorspace, और VK_EXT_hdr_metadata एक्सटेंशन के लिए सहायता का विज्ञापन दिखाना ज़रूरी है.

हैंडहेल्ड डिवाइस पर लागू करने के लिए:

• [7.1.4.6/H-0-1] यह ज़रूरी है कि डिवाइस, सिस्टम प्रॉपर्टी graphics.gpu.profiler.support की मदद से, जीपीयू की प्रोफ़ाइलिंग की सुविधा के साथ काम करता है या नहीं, इसकी जानकारी दे.

अगर हैंडहेल्ड डिवाइस के लागू होने की जानकारी, सिस्टम प्रॉपर्टी के ज़रिए दी जाती है graphics.gpu.profiler.support, तो:

• [7.1.4.6/H-1-1] आउटपुट के तौर पर, ऐसा प्रोटोबस ट्रैक दिखाना ज़रूरी है जो Perfetto दस्तावेज़ में बताए गए जीपीयू काउंटर और जीपीयू रेंडरस्टेज के स्कीमा के मुताबिक हो.
• [7.1.4.6/H-1-2] डिवाइस के GPU काउंटर के लिए, gpu काउंटर ट्रेस पैकेट प्रोटो के मुताबिक, मानकों के मुताबिक वैल्यू रिपोर्ट करना ज़रूरी है.
• [7.1.4.6/H-1-3] डिवाइस के GPU रेंडर स्टेज के लिए, रेंडर स्टेज ट्रेस पैकेट प्रोटो के मुताबिक, सही वैल्यू की जानकारी देनी ज़रूरी है.
• [7.1.4.6/H-1-4] जीपीयू फ़्रीक्वेंसी ट्रैसपॉइंट की रिपोर्ट ज़रूर देनी चाहिए. यह रिपोर्ट, power/gpu_frequency फ़ॉर्मैट में दी जानी चाहिए.

हैंडहेल्ड डिवाइस पर लागू करने के लिए:

• [7.1.5/H-0-1] इसमें, लेगसी ऐप्लिकेशन के साथ काम करने वाले मोड के लिए सहायता शामिल होनी चाहिए. इसे Android के अपस्ट्रीम ओपन सोर्स कोड के ज़रिए लागू किया गया है. इसका मतलब है कि डिवाइस में लागू करने से, उन ट्रिगर या थ्रेशोल्ड में बदलाव नहीं होना चाहिए जिन पर कम्पैटबिलिटी मोड चालू होता है. साथ ही, कम्पैटबिलिटी मोड के व्यवहार में भी बदलाव नहीं होना चाहिए.
• [7.2.1/H-0-1] इसमें तीसरे पक्ष के इनपुट के तरीके के संपादक (आईएमई) ऐप्लिकेशन के लिए सहायता शामिल होनी चाहिए.
• [7.2.3/H-0-2] फ़ोरग्राउंड ऐप्लिकेशन को, बैक फ़ंक्शन (KEYCODE_BACK) के सामान्य और ज़्यादा देर तक दबाने के इवेंट, दोनों को भेजना ज़रूरी है. ये इवेंट, सिस्टम के ज़रिए इस्तेमाल नहीं किए जाने चाहिए.साथ ही, इन्हें Android डिवाइस के बाहर से ट्रिगर किया जा सकता है. जैसे, Android डिवाइस से कनेक्ट किया गया बाहरी हार्डवेयर कीबोर्ड.
• [7.2.3/H-0-3] Android के साथ काम करने वाले उन सभी डिसप्ले पर होम फ़ंक्शन होना चाहिए जिन पर होम स्क्रीन उपलब्ध होती है.
• [7.2.3/H-0-4] Android के साथ काम करने वाले सभी डिसप्ले पर, 'वापस जाएं' फ़ंक्शन और Android के साथ काम करने वाले कम से कम एक डिसप्ले पर, 'हाल ही में खोले गए' फ़ंक्शन होना ज़रूरी है.
• [7.2.4/H-0-1] टचस्क्रीन इनपुट की सुविधा होनी चाहिए.
• [7.2.4/H-SR-1] हमारा सुझाव है कि आप उपयोगकर्ता के चुने गए असिस्ट ऐप्लिकेशन को लॉन्च करें. दूसरे शब्दों में, वह ऐप्लिकेशन जो VoiceInteractionService को लागू करता है या अगर फ़ोरग्राउंड गतिविधि उन लॉन्ग-प्रेस इवेंट को मैनेज नहीं करती है, तो KEYCODE_MEDIA_PLAY_PAUSE या KEYCODE_HEADSETHOOK को दबाकर ACTION_ASSIST को मैनेज करने वाली गतिविधि.
• [7.3.1/H-SR-1] हमारा सुझाव है कि आप 3-ऐक्सिस एक्सलरोमीटर शामिल करें.

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

• [7.3.1/H-1-1] यह ज़रूरी है कि डिवाइस कम से कम 100 हर्ट्ज़ तक की फ़्रीक्वेंसी वाले इवेंट की रिपोर्ट कर सके.

अगर हैंडहेल्ड डिवाइस में GPS/GNSS रिसीवर शामिल है और android.hardware.location.gps सुविधा के फ़्लैग के ज़रिए ऐप्लिकेशन को इसकी जानकारी दी जाती है, तो:

• [7.3.3/H-2-1] जीएनएसएस मेज़रमेंट मिलने के तुरंत बाद, उन्हें रिपोर्ट करना ज़रूरी है. भले ही, जीपीएस/जीएनएसएस से कैलकुलेट की गई जगह की जानकारी अब तक रिपोर्ट न की गई हो.
• [7.3.3/H-2-2] GNSS स्यूडोरेंज और स्यूडोरेंज रेट की जानकारी देना ज़रूरी है. ये ऐसे होते हैं जो जगह की जानकारी तय करने के बाद, खुले आसमान में, स्थिर रहने या 0.2 मीटर प्रति सेकंड स्क्वेयर से कम की रफ़्तार से चलने पर, कम से कम 95% समय तक, जगह की जानकारी 20 मीटर के अंदर और रफ़्तार 0.2 मीटर प्रति सेकंड के अंदर कैलकुलेट करने के लिए काफ़ी होते हैं.

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

• [7.3.4/H-3-1] यह ज़रूरी है कि डिवाइस कम से कम 100 हर्ट्ज़ तक की फ़्रीक्वेंसी वाले इवेंट की रिपोर्ट कर सके.
• [7.3.4/H-3-2] यह ज़रूरी है कि यह हर सेकंड में 1,000 डिग्री तक ओरिएंटेशन में हुए बदलावों को मेज़र कर सके.

ऐसे हैंडहेल्ड डिवाइस जिन पर वॉइस कॉल करने की सुविधा है और जो getPhoneType में PHONE_TYPE_NONE के अलावा कोई भी वैल्यू दिखा सकते हैं:

• [7.3.8/H] इसमें प्रॉक्सिमिटी सेंसर शामिल होना चाहिए.

हैंडहेल्ड डिवाइस पर लागू करने के लिए:

• [7.3.11/H-SR-1] हमारा सुझाव है कि आप ऐसे पोज़ सेंसर का इस्तेमाल करें जिसमें छह डिग्री की फ़्रीडम हो.
• [7.4.3/H] इसमें ब्लूटूथ और ब्लूटूथ एलई के लिए सहायता शामिल होनी चाहिए.

अगर डिवाइसों में PackageManager.FEATURE_WIFI_AWARE का एलान करके, वाई-फ़ाई नेबर अवेयरनेस नेटवर्किंग (एनएएन) प्रोटोकॉल और PackageManager.FEATURE_WIFI_RTT का एलान करके, वाई-फ़ाई लोकेशन (वाई-फ़ाई राउंड ट्रिप टाइम — आरटीटी) की सुविधा काम करती है, तो वे:

• [7.4.2.5/H-1-1] WifiRttManager#startRanging Android API के ज़रिए पता चला है कि 10 सेंटीमीटर, 1 मीटर, 3 मीटर, और 5 मीटर की दूरियों पर, 160 मेगाहर्ट्ज़ बैंडविड्थ के लिए 68वें पर्सेंटाइल (कुल डिस्ट्रिब्यूशन फ़ंक्शन के हिसाब से कैलकुलेट किया गया) में, +/-1 मीटर, 80 मेगाहर्ट्ज़ बैंडविड्थ के लिए 68वें पर्सेंटाइल में, +/-2 मीटर, 40 मेगाहर्ट्ज़ बैंडविड्थ के लिए 68वें पर्सेंटाइल में, +/-4 मीटर, और 20 मेगाहर्ट्ज़ बैंडविड्थ के लिए 68वें पर्सेंटाइल में, +/-8 मीटर तक की रेंज सटीक तौर पर रिपोर्ट की जानी चाहिए.

• [7.4.2.5/H-SR-1] हमारा सुझाव है कि रेंज की सटीक जानकारी दें. इसके लिए, 10 सेंटीमीटर की दूरी पर, 90वें प्रतिशत में 160 मेगाहर्ट्ज़ बैंडविड्थ पर +/-1 मीटर, 90वें प्रतिशत में 80 मेगाहर्ट्ज़ बैंडविड्थ पर +/-2 मीटर, 90वें प्रतिशत में 40 मेगाहर्ट्ज़ बैंडविड्थ पर +/-4 मीटर, और 90वें प्रतिशत में 20 मेगाहर्ट्ज़ बैंडविड्थ पर +/-8 मीटर की जानकारी दें. यह जानकारी, WifiRttManager#startRanging Android API से मिली है.

हमारा सुझाव है कि आप मौजूदगी को कैलिब्रेट करने में बताए गए मेज़रमेंट सेटअप के चरणों का पालन करें.

अगर हाथ में पकड़े जा सकने वाले डिवाइस के लागू होने में, एक लॉजिकल कैमरा डिवाइस शामिल है, जो CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA का इस्तेमाल करके सुविधाओं की सूची बनाता है, तो:

• [7.5.4/H-1-1] डिफ़ॉल्ट रूप से, फ़ील्ड ऑफ़ व्यू (एफ़ओवी) सामान्य होना चाहिए और यह 50 से 95 डिग्री के बीच होना चाहिए.

हैंडहेल्ड डिवाइस पर लागू करने के लिए:

• [7.6.1/H-0-1] ऐप्लिकेशन के निजी डेटा (जिसे "/data" पार्टीशन भी कहा जाता है) के लिए, कम से कम 4 जीबी का नॉन-वॉल्व्यूलेट स्टोरेज होना चाहिए.
• [7.6.1/H-0-2] जब कर्नेल और यूज़रस्पेस के लिए 1 जीबी से कम मेमोरी उपलब्ध हो, तो ActivityManager.isLowRamDevice() के लिए “सही” दिखाना ज़रूरी है.

अगर हैंडहेल्ड डिवाइस के लिए, सिर्फ़ 32-बिट एबीआई के साथ काम करने की जानकारी दी गई है, तो:

• [7.6.1/H-1-1] अगर डिफ़ॉल्ट डिसप्ले में qHD (जैसे, FWVGA) तक के फ़्रेमबफ़र रिज़ॉल्यूशन का इस्तेमाल किया जाता है, तो कर्नेल और यूज़रस्पेस के लिए कम से कम 416 एमबी मेमोरी होनी चाहिए.

• [7.6.1/H-2-1] अगर डिफ़ॉल्ट डिसप्ले में एचडी+ (जैसे, एचडी, WSVGA) तक के फ़्रेमबफ़र रिज़ॉल्यूशन का इस्तेमाल किया जाता है, तो कर्नेल और यूज़रस्पेस के लिए कम से कम 592 एमबी मेमोरी होनी चाहिए.

• [7.6.1/H-3-1] अगर डिफ़ॉल्ट डिसप्ले, एफ़एचडी (उदाहरण के लिए, WSXGA+) तक के फ़्रेमबफ़र रिज़ॉल्यूशन का इस्तेमाल करता है, तो कर्नेल और यूज़रस्पेस के लिए कम से कम 896 एमबी मेमोरी होनी चाहिए.

• [7.6.1/H-4-1] अगर डिफ़ॉल्ट डिसप्ले में क्वाड हाई डेफ़िनिशन (जैसे, QWXGA) तक के फ़्रेमबफ़र रिज़ॉल्यूशन का इस्तेमाल किया जाता है, तो कर्नेल और यूज़रस्पेस के लिए कम से कम 1344 एमबी मेमोरी उपलब्ध होनी चाहिए.

अगर हैंडहेल्ड डिवाइस पर, 32-बिट एबीआई के साथ या उसके बिना, किसी 64-बिट एबीआई के साथ काम करने की सुविधा उपलब्ध है, तो:

• [7.6.1/H-5-1] अगर डिफ़ॉल्ट डिसप्ले में qHD (उदाहरण के लिए, FWVGA) तक के फ़्रेमबफ़र रिज़ॉल्यूशन का इस्तेमाल किया जाता है, तो कर्नेल और यूज़रस्पेस के लिए कम से कम 816 एमबी मेमोरी उपलब्ध होनी चाहिए.

• [7.6.1/H-6-1] अगर डिफ़ॉल्ट डिसप्ले में एचडी+ (जैसे, एचडी, WSVGA) तक के फ़्रेमबफ़र रिज़ॉल्यूशन का इस्तेमाल किया जाता है, तो कर्नेल और यूज़रस्पेस के लिए कम से कम 944 एमबी मेमोरी होनी चाहिए.

• [7.6.1/H-7-1] अगर डिफ़ॉल्ट डिसप्ले, एफ़एचडी (उदाहरण के लिए, WSXGA+) तक के फ़्रेमबफ़र रिज़ॉल्यूशन का इस्तेमाल करता है, तो कर्नेल और यूज़रस्पेस के लिए उपलब्ध मेमोरी कम से कम 1280 एमबी होनी चाहिए.

• [7.6.1/H-8-1] अगर डिफ़ॉल्ट डिसप्ले में क्यूएचडी (उदाहरण के लिए, QWXGA) तक के फ़्रेमबफ़र रिज़ॉल्यूशन का इस्तेमाल किया जाता है, तो कर्नेल और यूज़रस्पेस के लिए कम से कम 1824 एमबी मेमोरी उपलब्ध होनी चाहिए.

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

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

• [7.6.1/H-9-1] फ़ीचर फ़्लैग के बारे में जानकारी देना ज़रूरी है android.hardware.ram.low.
• [7.6.1/H-9-2] ऐप्लिकेशन के निजी डेटा (जिसे "/data" पार्टीशन भी कहा जाता है) के लिए, कम से कम 1.1 जीबी का नॉन-वॉल्व्यूस्ट स्टोरेज होना चाहिए.

अगर हैंडहेल्ड डिवाइस में, कर्नेल और यूज़रस्पेस के लिए 1 जीबी से ज़्यादा मेमोरी उपलब्ध है, तो:

• [7.6.1/H-10-1] ऐप्लिकेशन के निजी डेटा (जिसे "/data" पार्टीशन भी कहा जाता है) के लिए, कम से कम 4 जीबी का नॉन-वॉल्व्यूस्ट स्टोरेज होना चाहिए.
• फ़ीचर फ़्लैग android.hardware.ram.normal का एलान करना चाहिए.

अगर हैंडहेल्ड डिवाइस में, कर्नेल और यूज़रस्पेस के लिए 2 जीबी या उससे ज़्यादा और 4 जीबी से कम मेमोरी उपलब्ध है, तो:

• [7.6.1/H-SR-1] हमारा सुझाव है कि आप सिर्फ़ 32-बिट यूज़रस्पेस (ऐप्लिकेशन और सिस्टम कोड, दोनों) के साथ काम करें

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

• [7.6.1/H-1-1] यह ज़रूरी है कि यह सिर्फ़ एक एबीआई (सिर्फ़ 64-बिट या सिर्फ़ 32-बिट) के साथ काम करे.

हैंडहेल्ड डिवाइस पर लागू करने के लिए:

• [7.6.2/H-0-1] ऐप्लिकेशन के लिए, 1 जीबी से कम का शेयर किया गया स्टोरेज नहीं दिया जाना चाहिए.
• [7.7.1/H] इसमें पेरिफ़रल मोड के साथ काम करने वाला यूएसबी पोर्ट होना चाहिए.

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

• [7.7.1/H-1-1] Android Open Accessory (AOA) API को लागू करना ज़रूरी है.

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

• [7.7.2/H-1-1] Android SDK टूल के दस्तावेज़ में बताए गए तरीके के मुताबिक, यूएसबी ऑडियो क्लास को लागू करना ज़रूरी है.

हैंडहेल्ड डिवाइस पर लागू करने के लिए:

• [7.8.1/H-0-1] इसमें माइक्रोफ़ोन होना ज़रूरी है.
• [7.8.2/H-0-1] इसमें ऑडियो आउटपुट होना चाहिए और इसकी जानकारी दी गई होandroid.hardware.audio.output.

अगर हैंडहेल्ड डिवाइस पर, VR मोड के साथ काम करने के लिए परफ़ॉर्मेंस से जुड़ी सभी ज़रूरी शर्तें पूरी की जा सकती हैं और उसमें VR मोड के साथ काम करने की सुविधा शामिल है, तो:

• [7.9.1/H-1-1] android.hardware.vr.high_performance फ़ीचर फ़्लैग के बारे में ज़रूर बताएं.
• [7.9.1/H-1-2] इसमें ऐसा ऐप्लिकेशन होना चाहिए जिसमें android.service.vr.VrListenerService लागू किया गया हो. साथ ही, android.app.Activity#setVrModeEnabled की मदद से वीआर ऐप्लिकेशन इसे चालू कर सकें.

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

• [7.8.2.2/H-1-1] एचआईडी कोड के लिए, यहां दी गई सॉफ़्टवेयर मैपिंग ज़रूर उपलब्ध कराएं:

फ़ंक्शन	मैपिंग	संदर्भ	व्यवहार
ए	एचआईडी के इस्तेमाल का पेज: 0x0C एचआईडी के इस्तेमाल की जानकारी: 0x0CD कर्नल पासकोड: KEY_PLAYPAUSE Android पासकोड: KEYCODE_MEDIA_PLAY_PAUSE	मीडिया प्लेबैक	इनपुट: थोड़ी देर के लिए दबाएं आउटपुट: चलाएं या रोकें
			इनपुट: लंबे समय तक दबाएं आउटपुट: बोलकर निर्देश देने की सुविधा चालू करें भेजता है: android.speech.action.VOICE_SEARCH_HANDS_FREE अगर डिवाइस लॉक है या उसकी स्क्रीन बंद है. इसके अलावा, android.speech.RecognizerIntent.ACTION_WEB_SEARCH भेजता है
		आने वाला (इनकमिंग) कॉल	इनपुट: थोड़ी देर के लिए दबाएं आउटपुट: कॉल स्वीकार करना
			इनपुट: दबाकर रखें आउटपुट: कॉल को अस्वीकार करना
		पहले से जारी कॉल	इनपुट: थोड़ी देर के लिए दबाएं आउटपुट: कॉल खत्म करें
			इनपुट: दबाकर रखें आउटपुट: माइक्रोफ़ोन को म्यूट या अनम्यूट करना
B	एचआईडी के इस्तेमाल का पेज: 0x0C एचआईडी के इस्तेमाल की जानकारी: 0x0E9 कर्नल पासकोड: KEY_VOLUMEUP Android पासकोड: VOLUME_UP	मीडिया प्लेबैक, कॉल जारी है	इनपुट: थोड़ी देर या ज़्यादा देर तक दबाएं आउटपुट: सिस्टम या हेडसेट की आवाज़ बढ़ाता है
C	एचआईडी के इस्तेमाल से जुड़ा पेज: 0x0C एचआईडी के इस्तेमाल से जुड़ी जानकारी: 0x0EA कर्नल पासकोड: KEY_VOLUMEDOWN Android पासकोड: VOLUME_DOWN	मीडिया प्लेबैक, कॉल जारी है	इनपुट: थोड़ी देर या ज़्यादा देर तक दबाएं आउटपुट: सिस्टम या हेडसेट की आवाज़ कम हो जाती है
D	एचआईडी के इस्तेमाल से जुड़ा पेज: 0x0C एचआईडी के इस्तेमाल से जुड़ी जानकारी: 0x0CF कर्नल पासकोड: KEY_VOICECOMMAND Android पासकोड: KEYCODE_VOICE_ASSIST	सभी थ्रेड के लिए. किसी भी इंस्टेंस में ट्रिगर किया जा सकता है.	इनपुट: थोड़ी देर या ज़्यादा देर तक दबाएं आउटपुट: बोलकर निर्देश देने की सुविधा चालू करें

• [7.8.2.2/H-1-2] प्लग डालने पर, ACTION_HEADSET_PLUG को ट्रिगर करना ज़रूरी है. हालांकि, ऐसा सिर्फ़ तब किया जाना चाहिए, जब यूएसबी ऑडियो इंटरफ़ेस और एंडपॉइंट को सही तरीके से एनोटेट किया गया हो, ताकि कनेक्ट किए गए टर्मिनल के टाइप की पहचान की जा सके.

जब यूएसबी ऑडियो टर्मिनल टाइप 0x0302 का पता चलता है, तो:

• [7.8.2.2/H-2-1] "माइक्रोफ़ोन" एक्सट्रा को 0 पर सेट करके, ACTION_HEADSET_PLUG इंटेंट को ब्रॉडकास्ट करना ज़रूरी है.

जब यूएसबी ऑडियो टर्मिनल टाइप 0x0402 का पता चलता है, तो:

• [7.8.2.2/H-3-1] "माइक्रोफ़ोन" को 1 पर सेट करके, ज़रूर से 'इंटेंट ACTION_HEADSET_PLUG' ब्रॉडकास्ट करें.

जब यूएसबी डिवाइस कनेक्ट होने के दौरान, API AudioManager.getDevices() को कॉल किया जाता है, तो:

• [7.8.2.2/H-4-1] अगर यूएसबी ऑडियो टर्मिनल टाइप फ़ील्ड 0x0302 है, तो AudioDeviceInfo.TYPE_USB_HEADSET टाइप का डिवाइस और भूमिका isSink() की सूची ज़रूर होनी चाहिए.

• [7.8.2.2/H-4-2] अगर USB ऑडियो टर्मिनल टाइप फ़ील्ड 0x0402 है, तो डिवाइस के टाइप के तौर पर AudioDeviceInfo.TYPE_USB_HEADSET और भूमिका के तौर पर isSink() की जानकारी देना ज़रूरी है.

• [7.8.2.2/H-4-3] अगर यूएसबी ऑडियो टर्मिनल टाइप फ़ील्ड 0x0402 है, तो टाइप के तौर पर AudioDeviceInfo.TYPE_USB_HEADSET और भूमिका isSource() वाला डिवाइस ज़रूर शामिल करना चाहिए.

• [7.8.2.2/H-4-4] AudioDeviceInfo.TYPE_USB_DEVICE टाइप का डिवाइस और भूमिका isSink() की सूची ज़रूर होनी चाहिए. ऐसा तब करना होगा, जब यूएसबी ऑडियो टर्मिनल टाइप फ़ील्ड 0x603 हो.

• [7.8.2.2/H-4-5] अगर यूएसबी ऑडियो टर्मिनल टाइप फ़ील्ड 0x604 है, तो डिवाइस के टाइप के तौर पर AudioDeviceInfo.TYPE_USB_DEVICE और भूमिका के तौर पर isSource() की जानकारी देना ज़रूरी है.

• [7.8.2.2/H-4-6] अगर USB ऑडियो टर्मिनल टाइप फ़ील्ड 0x400 है, तो टाइप के तौर पर AudioDeviceInfo.TYPE_USB_DEVICE और भूमिका के तौर पर isSink() वाला डिवाइस ज़रूर शामिल करना चाहिए.

• [7.8.2.2/H-4-7] अगर यूएसबी ऑडियो टर्मिनल टाइप फ़ील्ड 0x400 है, तो डिवाइस के टाइप के तौर पर AudioDeviceInfo.TYPE_USB_DEVICE और भूमिका के तौर पर isSource() की जानकारी देना ज़रूरी है.

• [7.8.2.2/H-SR-1] USB-C ऑडियो डिवाइस को कनेक्ट करने पर, इनका इस्तेमाल करने का ज़रूर सुझाव दिया जाता है. इससे, USB डिस्क्रिप्टर की गिनती की जा सकती है, टर्मिनल टाइप की पहचान की जा सकती है, और 1,000 मिलीसेकंड से भी कम समय में Intent ACTION_HEADSET_PLUG ब्रॉडकास्ट किया जा सकता है.

अगर हैंडहेल्ड डिवाइस पर android.hardware.audio.output और android.hardware.microphone का एलान किया जाता है, तो:

• [5.6/H-1-1] पांच मेज़रमेंट में, औसत राउंड-ट्रिप विलंब 500 मिलीसेकंड या उससे कम होना चाहिए. साथ ही, औसत एब्सोल्यूट डेविएशन 50 मिलीसेकंड से कम होना चाहिए. यह शर्त, इन डेटा पाथ पर लागू होती है: "स्पीकर से माइक्रोफ़ोन", 3.5 मि॰मी॰ का लूपबैक अडैप्टर (अगर काम करता है), यूएसबी लूपबैक (अगर काम करता है).

• [5.6/H-1-2] स्पीकर से माइक्रोफ़ोन के डेटा पाथ पर, कम से कम पांच मेज़रमेंट में टैप-टू-टोन के औसत इंतज़ार का समय 500 मिलीसेकंड या उससे कम होना चाहिए.

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

• [7.10/H]* इसमें एक्ससेंट्रिक रोटेटेड मैस (ईआरएम) वाले हैप्टिक ऐक्चुएटर (वाइब्रेटर) का इस्तेमाल नहीं किया जाना चाहिए.
• [7.10/H]* ऐक्चुएटर को उस जगह के आस-पास रखना चाहिए जहां आम तौर पर डिवाइस को हाथ से पकड़ा जाता है या छुआ जाता है.
• [7.10/H]* android.view.HapticFeedbackConstants में, साफ़ तौर पर महसूस होने वाले वाइब्रेशन के लिए सभी सार्वजनिक कॉन्स्टेंट लागू करने चाहिए. जैसे, CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY, VIRTUAL_KEY_RELEASE, CONFIRM, REJECT, GESTURE_START, और GESTURE_END.
• [7.10/H]* android.os.VibrationEffect में, साफ़-साफ़ महसूस होने वाले वाइब्रेशन के लिए सभी सार्वजनिक कॉन्स्टेंट लागू करने चाहिए. जैसे, (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK, और EFFECT_DOUBLE_CLICK). साथ ही, android.os.VibrationEffect.Composition में, ज़्यादा महसूस होने वाले वाइब्रेशन के लिए सभी संभावित सार्वजनिक PRIMITIVE_* कॉन्स्टेंट लागू करने चाहिए. जैसे, (CLICK, TICK, LOW_TICK, QUICK_FALL, QUICK_RISE, SLOW_RISE, SPIN, THUD). इनमें से कुछ प्राइमिटिव, जैसे कि LOW_TICK और SPIN सिर्फ़ तब काम कर सकते हैं, जब वाइब्रेटर कम फ़्रीक्वेंसी पर काम कर सकता हो.

• [7.10/H]* को android.view.HapticFeedbackConstants में सार्वजनिक कॉन्स्टेंट को मैप करने के लिए दिशा-निर्देशों का पालन करना चाहिए. साथ ही, सुझाई गई android.os.VibrationEffect कॉन्स्टेंट के साथ, अम्प्ल्यट्यूड के संबंधों का पालन करना चाहिए.

• [7.10/H]* को createOneShot() और createWaveform() एपीआई के लिए, क्वालिटी की जांच की प्रक्रिया का पालन करना चाहिए.

• [7.10/H]* यह पुष्टि करनी चाहिए कि सार्वजनिक android.os.Vibrator.hasAmplitudeControl() एपीआई का नतीजा, उनके वाइब्रेटर की क्षमताओं को सही तरीके से दिखाता है.

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

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

• [7.10/H]* पोर्ट्रेट ओरिएंटेशन में, X-ऐक्सिस (बाएं-दाएं) में हैप्टिक ऐक्चुएटर को मूव करना चाहिए.

अगर हैंडहेल्ड डिवाइस में X-ऐक्सिस वाला लिनियर रेज़ॉनैंट ऐक्चुएटर (एलआरए) हैप्टिक ऐक्चुएटर है, तो:

• [7.10/H]* में, X-ऐक्सिस के LRA की अनुनाद फ़्रीक्वेंसी 200 हर्ट्ज़ से कम होनी चाहिए.

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

• [7.10/H]* को android.os.Vibrator.areAllEffectsSupported() और android.os.Vibrator.arePrimitivesSupported() एपीआई को चलाकर, लागू होने की स्थिति की पुष्टि करनी चाहिए.

• [7.10/घंटा]* को वाइब्रेशन के लिए, क्वालिटी का आकलन करना चाहिए.

• [7.10/H]* कॉन्स्टेंट के लिए लागू करने के दिशा-निर्देश में बताए गए तरीके के मुताबिक, काम न करने वाले प्राइमिटिव के लिए फ़ॉलबैक कॉन्फ़िगरेशन की पुष्टि करनी चाहिए और ज़रूरत पड़ने पर उसे अपडेट करना चाहिए.

2.2.2. मल्टीमीडिया

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

• [5.1/H-0-1] AMR-NB
• [5.1/H-0-2] AMR-WB
• [5.1/H-0-3] MPEG-4 AAC प्रोफ़ाइल (AAC LC)
• [5.1/H-0-4] MPEG-4 HE AAC Profile (AAC+)
• [5.1/H-0-5] AAC ELD (कम देरी वाला बेहतर AAC)

हैंडहेल्ड डिवाइस पर, वीडियो को इन फ़ॉर्मैट में एन्कोड किया जा सकता है. साथ ही, इन्हें तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराया जा सकता है:

• [5.2/H-0-1] H.264 AVC
• [5.2/H-0-2] VP8

हैंडहेल्ड डिवाइस पर, वीडियो को डिकोड करने के लिए इन फ़ॉर्मैट का इस्तेमाल किया जाना चाहिए. साथ ही, इन्हें तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराया जाना चाहिए:

• [5.3/H-0-1] H.264 AVC
• [5.3/H-0-2] H.265 HEVC
• [5.3/H-0-3] MPEG-4 SP
• [5.3/H-0-4] VP8
• [5.3/H-0-5] VP9

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

हैंडहेल्ड डिवाइस पर लागू करने के लिए:

• [3.2.3.1/H-0-1] ऐप्लिकेशन में, SDK टूल के दस्तावेज़ों में बताए गए ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE, और ACTION_CREATE_DOCUMENT के ज़रिए, इंटेंट मैनेज करने की सुविधा होनी चाहिए. साथ ही, DocumentsProvider एपीआई का इस्तेमाल करके, दस्तावेज़ उपलब्ध कराने वाली कंपनी का डेटा ऐक्सेस करने के लिए, उपयोगकर्ता को सुविधा देनी चाहिए.
• [3.2.3.1/H-0-2]* यहां दिए गए ऐप्लिकेशन इंटेंट के मुताबिक तय किए गए सभी सार्वजनिक इंटेंट फ़िल्टर पैटर्न के लिए, एक या उससे ज़्यादा ऐप्लिकेशन या सेवा कॉम्पोनेंट को इंटेंट हैंडलर के साथ पहले से लोड करना ज़रूरी है.
• [3.2.3.1/H-SR-1] हमारा सुझाव है कि आप ईमेल भेजने के लिए, ACTION_SENDTO या ACTION_SEND या ACTION_SEND_MULTIPLE इंटेंट को मैनेज करने वाला ईमेल ऐप्लिकेशन पहले से लोड करें.
• [3.4.1/H-0-1] android.webkit.Webview एपीआई को पूरी तरह से लागू करना ज़रूरी है.
• [3.4.2/H-0-1] इसमें, सामान्य उपयोगकर्ता के वेब ब्राउज़ करने के लिए, अलग से उपलब्ध ब्राउज़र ऐप्लिकेशन होना चाहिए.
• [3.8.1/H-SR-1] हमारा सुझाव है कि आप डिफ़ॉल्ट लॉन्चर लागू करें. यह लॉन्चर, शॉर्टकट, विजेट, और widgetFeatures को ऐप्लिकेशन में पिन करने की सुविधा देता है.
• [3.8.1/H-SR-2] हमारा सुझाव है कि आप डिफ़ॉल्ट लॉन्चर लागू करें. इससे, ShortcutManager एपीआई की मदद से, तीसरे पक्ष के ऐप्लिकेशन के अतिरिक्त शॉर्टकट को तुरंत ऐक्सेस किया जा सकता है.
• [3.8.1/H-SR-3] हमारा सुझाव है कि आप डिफ़ॉल्ट लॉन्चर ऐप्लिकेशन शामिल करें. यह ऐप्लिकेशन, ऐप्लिकेशन के आइकॉन के लिए बैज दिखाता है.
• [3.8.2/H-SR-1] तीसरे पक्ष के ऐप्लिकेशन के विजेट के साथ काम करने के लिए, ऐसा करने का ज़रूर सुझाव दिया जाता है.
• [3.8.3/H-0-1] तीसरे पक्ष के ऐप्लिकेशन को Notification और NotificationManager एपीआई क्लास की मदद से, उपयोगकर्ताओं को अहम इवेंट की सूचना देने की अनुमति देनी चाहिए.
• [3.8.3/H-0-2] रिच सूचनाओं के साथ काम करना चाहिए.
• [3.8.3/H-0-3] ऐप्लिकेशन में हेड्स-अप सूचनाओं की सुविधा होनी चाहिए.
• [3.8.3/H-0-4] ऐप्लिकेशन में सूचना शेड होना ज़रूरी है. इससे उपयोगकर्ता, सूचनाओं को सीधे तौर पर कंट्रोल कर सकता है. जैसे, जवाब देना, स्नूज़ करना, खारिज करना, ब्लॉक करना. इसके लिए, उपयोगकर्ता को AOSP में लागू किए गए ऐक्शन बटन या कंट्रोल पैनल जैसे यूज़र अफ़र्डेंस की ज़रूरत होती है.
• [3.8.3/H-0-5] नोटिफ़िकेशन शेड में, RemoteInput.Builder setChoices() के ज़रिए दिए गए विकल्प दिखाने ज़रूरी हैं.
• [3.8.3/H-SR-1] हमारा सुझाव है कि आप सूचना शेड में, RemoteInput.Builder setChoices() के ज़रिए दिया गया पहला विकल्प दिखाएं. इसके लिए, उपयोगकर्ता से कोई और इंटरैक्शन ज़रूरी नहीं है.
• [3.8.3/H-SR-2] हमारा सुझाव है कि जब उपयोगकर्ता, नोटिफ़िकेशन शेड में सभी सूचनाओं को बड़ा करे, तो नोटिफ़िकेशन शेड में RemoteInput.Builder setChoices() के ज़रिए दिए गए सभी विकल्प दिखाए जाएं.
• [3.8.3.1/H-SR-1] हमारा सुझाव है कि आप उन कार्रवाइयों को दिखाएं जिनके लिए Notification.Action.Builder.setContextual को true के तौर पर सेट किया गया है. ये कार्रवाइयां, Notification.Remoteinput.Builder.setChoices से दिखाए गए जवाबों के साथ-साथ दिखेंगी.
• [3.8.4/H-SR-1] Assist ऐक्शन को मैनेज करने के लिए, डिवाइस पर किसी असिस्टेंट को लागू करने का ज़रूर सुझाव दिया जाता है.

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

• [3.8.3.1/H-SR-2] हमारा सुझाव है कि आप अपने ऐप्लिकेशन में, उपयोगकर्ताओं को सिस्टम यूज़र इंटरफ़ेस (यूआई) से ऐक्सेस किया जा सकने वाला आउटपुट स्विचर जैसा कोई ऐसा फ़ंक्शन दें जिससे वे MediaSession टोकन के साथ MediaStyle सूचना पोस्ट करने पर, उपलब्ध मीडिया रूट (उदाहरण के लिए, ब्लूटूथ डिवाइस और MediaRouter2Manager को दिए गए रूट) के बीच स्विच कर सकें.

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

• [3.8.4/H-SR-2] हमारा सुझाव है कि आप HOME बटन को दबाकर रखें, ताकि सहायता ऐप्लिकेशन को लॉन्च किया जा सके. इस बारे में सेक्शन 7.2.3 में बताया गया है. उपयोगकर्ता के चुने गए असिस्ट ऐप्लिकेशन को लॉन्च करना ज़रूरी है. दूसरे शब्दों में, वह ऐप्लिकेशन जो VoiceInteractionService को लागू करता है या ACTION_ASSIST इंटेंट को मैनेज करने वाली गतिविधि.

अगर हैंडहेल्ड डिवाइस पर conversation notifications की सुविधा काम करती है और सूचनाओं को सूचना देने वाली और साइलेंट मोड में मिलने वाली सूचनाओं से अलग सेक्शन में रखा जाता है, तो:

• [3.8.4/H-1-1]* बातचीत से जुड़ी सूचनाओं को, बातचीत से जुड़ी सूचनाओं के अलावा अन्य सूचनाओं से पहले दिखाना ज़रूरी है. हालांकि, फ़ोरग्राउंड सेवा की चल रही सूचनाओं और ज़रूरत:ज़्यादा वाली सूचनाओं को छोड़कर.

अगर Android डिवाइस पर लॉक स्क्रीन की सुविधा काम करती है, तो:

• [3.8.10/H-1-1] ऐप्लिकेशन को Lock screen पर सूचनाएं दिखानी चाहिए. इनमें मीडिया सूचना टेंप्लेट भी शामिल है.

अगर हैंडहेल्ड डिवाइस पर सुरक्षित लॉक स्क्रीन की सुविधा काम करती है, तो:

• [3.9/H-1-1] Android SDK के दस्तावेज़ में बताई गई, डिवाइस मैनेजमेंट से जुड़ी सभी नीतियों को लागू करना ज़रूरी है.

अगर हैंडहेल्ड डिवाइस के लागू होने में, ControlsProviderService और Control एपीआई के साथ-साथ तीसरे पक्ष के ऐप्लिकेशन को डिवाइस कंट्रोल पब्लिश करने की अनुमति शामिल है, तो:

• [3.8.16/H-1-1] सुविधा के लिए, फ़्लैग android.software.controls का एलान करना ज़रूरी है और इसे true पर सेट करना ज़रूरी है.
• [3.8.16/H-1-2] ऐप्लिकेशन में, उपयोगकर्ता को ControlsProviderService और Control एपीआई की मदद से, तीसरे पक्ष के ऐप्लिकेशन के रजिस्टर किए गए कंट्रोल में से, अपने डिवाइस के पसंदीदा कंट्रोल जोड़ने, उनमें बदलाव करने, उन्हें चुनने, और इस्तेमाल करने की सुविधा देनी ज़रूरी है.
• [3.8.16/H-1-3] डिफ़ॉल्ट लॉन्चर से तीन इंटरैक्शन के अंदर, उपयोगकर्ता को इस सुविधा का ऐक्सेस देना ज़रूरी है.

• [3.8.16/H-1-4] इस यूज़र अवर्डेंस में, तीसरे पक्ष के हर उस ऐप्लिकेशन का नाम और आइकॉन सटीक तरीके से रेंडर करना ज़रूरी है जो ControlsProviderService एपीआई के ज़रिए कंट्रोल उपलब्ध कराता है. साथ ही, Control एपीआई से मिले किसी भी खास फ़ील्ड को भी रेंडर करना ज़रूरी है.

• [3.8.16/H-1-5] ऐप्लिकेशन के लिए तय किए गए, डिवाइस के ऐसे कंट्रोल से ऑप्ट आउट करने के लिए, उपयोगकर्ता को अवसर देना ज़रूरी है जो तीसरे पक्ष के ऐप्लिकेशन ने ControlsProviderService और Control Control.isAuthRequired एपीआई की मदद से रजिस्टर किए हैं.

इसके उलट, अगर हैंडहेल्ड डिवाइस पर ऐसे कंट्रोल लागू नहीं किए जाते हैं, तो:

• [3.8.16/H-2-1] ControlsProviderService और Control एपीआई के लिए, null की जानकारी देना ज़रूरी है.
• [3.8.16/H-2-2] सुविधा के लिए, फ़्लैग android.software.controls का एलान करना ज़रूरी है और इसे false पर सेट करना ज़रूरी है.

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

• [3.8.17/H-1-1] उपयोगकर्ता को यह पुष्टि करनी चाहिए कि डेटा को क्लिपबोर्ड पर कॉपी कर लिया गया है. उदाहरण के लिए, “कॉन्टेंट कॉपी हो गया है” का थंबनेल या सूचना. इसके अलावा, यहां यह जानकारी भी शामिल करें कि क्लिपबोर्ड का डेटा सभी डिवाइसों पर सिंक किया जाएगा या नहीं.

हैंडहेल्ड डिवाइस पर लागू करने के लिए:

• [3.10/H-0-1] ऐप्लिकेशन में, तीसरे पक्ष की सुलभता सेवाओं के साथ काम करने की सुविधा होनी चाहिए.
• [3.10/H-SR-1] हमारा सुझाव है कि डिवाइस पर सुलभता सेवाओं को पहले से लोड करें. ये सेवाएं, TalkBack के ओपन सोर्स प्रोजेक्ट में बताई गई, Switch Access और TalkBack (पहले से इंस्टॉल किए गए टेक्स्ट-टू-स्पीच इंजन के साथ काम करने वाली भाषाओं के लिए) की सुलभता सेवाओं के बराबर या उनसे बेहतर होनी चाहिए.
• [3.11/H-0-1] तीसरे पक्ष के टीटीएस इंजन को इंस्टॉल करने की सुविधा होनी चाहिए.
• [3.11/H-SR-1] हमारा सुझाव है कि आप डिवाइस पर उपलब्ध भाषाओं के साथ काम करने वाला TTS इंजन शामिल करें.
• [3.13/H-SR-1] हमारा सुझाव है कि आप क्विक सेटिंग यूज़र इंटरफ़ेस (यूआई) कॉम्पोनेंट शामिल करें.

अगर Android हैंडहेल्ड डिवाइस पर FEATURE_BLUETOOTH या FEATURE_WIFI की सुविधा काम करती है, तो:

• [3.16/H-1-1] यह ऐप्लिकेशन, साथ में इस्तेमाल किए जाने वाले डिवाइस को जोड़ने की सुविधा के साथ काम करना चाहिए.

अगर नेविगेशन फ़ंक्शन, स्क्रीन पर जेस्चर के आधार पर कार्रवाई करने के तौर पर दिया गया है, तो:

• [7.2.3/H] होम फ़ंक्शन के लिए, जेस्चर की पहचान करने वाला ज़ोन, स्क्रीन के सबसे नीचे से 32 डीपी से ज़्यादा नहीं होना चाहिए.

अगर हैंडहेल्ड डिवाइस पर, स्क्रीन के बाएं और दाएं किनारों पर कहीं से भी जेस्चर के तौर पर नेविगेशन फ़ंक्शन उपलब्ध कराया जाता है, तो:

• [7.2.3/H-0-1] नेविगेशन फ़ंक्शन के जेस्चर एरिया की चौड़ाई, हर तरफ़ 40 डीपी से कम होनी चाहिए. जेस्चर एरिया की चौड़ाई, डिफ़ॉल्ट रूप से 24 dp होनी चाहिए.

अगर हैंडहेल्ड डिवाइस पर सुरक्षित लॉक स्क्रीन की सुविधा काम करती है और उसके कर्नेल और यूज़रस्पेस में 2 जीबी या उससे ज़्यादा मेमोरी उपलब्ध है, तो:

• [3.9/H-1-2] android.software.managed_users सुविधा फ़्लैग की मदद से, मैनेज की जा रही प्रोफ़ाइलों के साथ काम करने की सुविधा के बारे में ज़रूर बताएं.

अगर Android वाले हैंडहेल्ड डिवाइस में, android.hardware.camera.any के ज़रिए कैमरे के काम करने की जानकारी दी गई है, तो:

• [7.5.4/H-1-1] SDK टूल में बताए गए तरीके के मुताबिक, android.media.action.STILL_IMAGE_CAMERA और android.media.action.STILL_IMAGE_CAMERA_SECURE इंटेंट को पूरा करना ज़रूरी है. साथ ही, कैमरे को स्टिल इमेज मोड में लॉन्च करना ज़रूरी है.
• [7.5.4/H-1-2] SDK टूल में बताए गए तरीके के मुताबिक, कैमरे को वीडियो मोड में लॉन्च करने के लिए, android.media.action.VIDEO_CAMERA के इरादे का सम्मान करना ज़रूरी है.

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

• [3.2.3.1/ H-1-1] इसमें ऐसी गतिविधि होनी चाहिए जो स्प्लिट फ़ंक्शन चालू होने पर, Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY इंटेंट को मैनेज करे. गतिविधि को android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK से सुरक्षित किया जाना चाहिए. साथ ही, यह Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI से पार्स किए गए इंटेंट की गतिविधि शुरू करनी चाहिए.

2.2.4. परफ़ॉर्मेंस और पावर

• [8.1/H-0-1] फ़्रेम के लोड होने में लगने वाला समय एक जैसा होना. फ़्रेम रेट में उतार-चढ़ाव या फ़्रेम रेंडर होने में लगने वाला समय, एक सेकंड में पांच फ़्रेम से ज़्यादा नहीं होना चाहिए. साथ ही, यह एक सेकंड में एक फ़्रेम से कम होना चाहिए.
• [8.1/H-0-2] यूज़र इंटरफ़ेस में लगने वाला समय. डिवाइस में लागू करने के लिए, यह ज़रूरी है कि उपयोगकर्ता को कम इंतज़ार का अनुभव मिले. इसके लिए, Android Compatibility Test Suite (CTS) के मुताबिक, 10 हज़ार सूची वाली एंट्री को 36 सेकंड से कम समय में स्क्रोल किया जाना चाहिए.
• [8.1/H-0-3] टास्क स्विच करना. जब कई ऐप्लिकेशन लॉन्च किए जाते हैं, तो पहले से चल रहे ऐप्लिकेशन को फिर से लॉन्च करने में एक सेकंड से कम समय लगना चाहिए.

हैंडहेल्ड डिवाइस पर लागू करने के लिए:

• [8.2/H-0-1] यह पक्का करना ज़रूरी है कि क्रम से लिखने की परफ़ॉर्मेंस कम से कम 5 एमबी/सेकंड हो.
• [8.2/H-0-2] यह पक्का करना ज़रूरी है कि रैंडम राइटिंग की परफ़ॉर्मेंस कम से कम 0.5 एमबी/सेकंड हो.
• [8.2/H-0-3] यह पक्का करना ज़रूरी है कि क्रम से पढ़ने की परफ़ॉर्मेंस कम से कम 15 एमबी/सेकंड हो.
• [8.2/H-0-4] यह पक्का करना ज़रूरी है कि रैंडम रीड की परफ़ॉर्मेंस कम से कम 3.5 एमबी/सेकंड हो.

अगर हाथ में पकड़े जा सकने वाले डिवाइसों में, डिवाइस के पावर मैनेजमेंट को बेहतर बनाने के लिए AOSP में शामिल सुविधाएं शामिल की जाती हैं या AOSP में शामिल सुविधाओं को बढ़ाया जाता है, तो:

• [8.3/H-1-1] बैटरी सेवर मोड को चालू और बंद करने के लिए, उपयोगकर्ता को आसानी से ऐक्सेस करने की सुविधा देना ज़रूरी है.
• [8.3/H-1-2] ऐप्लिकेशन स्टैंडबाय और Doze पावर-सेविंग मोड से छूट पाने वाले सभी ऐप्लिकेशन दिखाने के लिए, उपयोगकर्ता को सुविधा देना ज़रूरी है.

हैंडहेल्ड डिवाइस पर लागू करने के लिए:

• [8.4/H-0-1] हर कॉम्पोनेंट के लिए, बिजली की खपत की प्रोफ़ाइल देना ज़रूरी है. इससे हर हार्डवेयर कॉम्पोनेंट के लिए, बिजली की खपत की वैल्यू और समय के साथ कॉम्पोनेंट की वजह से बैटरी की खपत का अनुमानित डेटा पता चलता है. इस डेटा की जानकारी, Android Open Source Project की साइट पर दी गई है.
• [8.4/H-0-2] बिजली की खपत की सभी वैल्यू को मिलीऐंपियर घंटे (mAh) में रिपोर्ट करना ज़रूरी है.
• [8.4/H-0-3] हर प्रोसेस के यूआईडी के हिसाब से, सीपीयू की बिजली की खपत की जानकारी देना ज़रूरी है. Android ओपन सोर्स प्रोजेक्ट, uid_cputime कर्नेल मॉड्यूल लागू करने की ज़रूरी शर्तें पूरी करता है.
• [8.4/H-0-4] ऐप्लिकेशन डेवलपर को, बिजली की खपत की जानकारी adb shell dumpsys batterystats शेल कमांड के ज़रिए उपलब्ध कराना ज़रूरी है.
• [8.4/H] अगर हार्डवेयर कॉम्पोनेंट के पावर इस्तेमाल को किसी ऐप्लिकेशन के लिए एट्रिब्यूट नहीं किया जा सकता, तो इसे हार्डवेयर कॉम्पोनेंट के लिए एट्रिब्यूट किया जाना चाहिए.

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

• [8.4/H-1-1] ऐप्लिकेशन को android.intent.action.POWER_USAGE_SUMMARY के इंटेंट का सम्मान करना चाहिए और एक सेटिंग मेन्यू दिखाना चाहिए, जिसमें बिजली के इस्तेमाल की जानकारी दिखे.

हैंडहेल्ड डिवाइस पर लागू करने के लिए:

• [8.5/H-0-1] सेटिंग मेन्यू में, उपयोगकर्ता को ऐसा विकल्प देना ज़रूरी है जिससे वह फ़ोरग्राउंड सेवा चला रहे किसी ऐप्लिकेशन को रोक सके. साथ ही, उन सभी ऐप्लिकेशन को दिखा सके जिनमें फ़ोरग्राउंड सेवाएं चालू हैं. साथ ही, SDK टूल के दस्तावेज़ में बताए गए तरीके के मुताबिक, इनमें से हर सेवा के चालू होने की अवधि भी दिखा सके.
  • SDK टूल के दस्तावेज़ में बताए गए उपयोगकर्ता के ऐसे ऐफ़र्डेंस में, कुछ ऐप्लिकेशन को रोकने या सूची में शामिल करने से छूट मिल सकती है.

2.2.5. सुरक्षा मॉडल

हैंडहेल्ड डिवाइस पर लागू करने के लिए:

• [9.1/H-0-1] ऐप्लिकेशन को android.permission.PACKAGE_USAGE_STATS अनुमति की मदद से, तीसरे पक्ष के ऐप्लिकेशन के इस्तेमाल के आंकड़ों को ऐक्सेस करने की अनुमति देनी चाहिए. साथ ही, android.settings.ACTION_USAGE_ACCESS_SETTINGS इंटेंट के जवाब में, ऐसे ऐप्लिकेशन को ऐक्सेस देने या ऐक्सेस वापस लेने के लिए, उपयोगकर्ता के लिए ऐक्सेस करने का तरीका उपलब्ध कराना चाहिए.

हैंडहेल्ड डिवाइस पर लागू करने के लिए:

• [9.11/H-0-2] अलग से एक्ज़ीक्यूशन एनवायरमेंट का इस्तेमाल करके, पासकोड को लागू करने के लिए, पासकोड का बैक अप लेना ज़रूरी है.
• [9.11/H-0-3] इसमें RSA, AES, ECDSA, और HMAC क्रिप्टोग्राफ़िक एल्गोरिदम और MD5, SHA1, और SHA-2 फ़ैमिली के हैश फ़ंक्शन लागू होने चाहिए. इससे, Android Keystore सिस्टम के काम करने वाले एल्गोरिदम को सही तरीके से इस्तेमाल किया जा सकता है. यह एल्गोरिदम, कोर और उसके बाद के लेवल पर चलने वाले कोड से सुरक्षित तरीके से अलग होता है. सुरक्षित आइसोलेशन की सुविधा, उन सभी संभावित तरीकों को ब्लॉक करनी चाहिए जिनकी मदद से कर्नेल या यूज़रस्पेस कोड, डीएमए के साथ-साथ आइसोलेट किए गए एनवायरमेंट की इंटरनल स्टेटस को ऐक्सेस कर सकता है. अपस्ट्रीम Android Open Source Project (AOSP), Trusty को लागू करके इस ज़रूरी शर्त को पूरा करता है. हालांकि, ARM TrustZone पर आधारित कोई दूसरा समाधान या तीसरे पक्ष की समीक्षा के बाद, हाइपरवाइजर पर आधारित सही आइसोलेशन को सुरक्षित तरीके से लागू करना, इसके विकल्प हैं.
• [9.11/H-0-4] लॉक स्क्रीन की पुष्टि, अलग से चलाए जाने वाले प्रोग्राम में करनी चाहिए. पुष्टि होने के बाद ही, पुष्टि करने के लिए इस्तेमाल की जाने वाली कुंजियों का इस्तेमाल करने की अनुमति दें. लॉक स्क्रीन के क्रेडेंशियल को इस तरह से सेव करना ज़रूरी है कि सिर्फ़ अलग-अलग इकोसिस्टम में काम करने वाले प्रोग्राम के लिए, लॉक स्क्रीन की पुष्टि की जा सके. अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट, Gatekeeper Hardware Abstraction Layer (HAL) और Trusty उपलब्ध कराता है. इनका इस्तेमाल, इस ज़रूरी शर्त को पूरा करने के लिए किया जा सकता है.
• [9.11/H-0-5] यह ज़रूरी है कि कुंजी की पुष्टि करने की सुविधा काम करे. इसमें, पुष्टि करने के लिए इस्तेमाल होने वाली साइनिंग कुंजी को सुरक्षित हार्डवेयर से सुरक्षित किया गया हो और साइनिंग की प्रोसेस को सुरक्षित हार्डवेयर में किया गया हो. पुष्टि करने के लिए इस्तेमाल होने वाली साइनिंग पासकोड को ज़रूर ज़्यादा से ज़्यादा डिवाइसों के साथ शेयर किया जाना चाहिए. इससे, इन पासकोड का इस्तेमाल डिवाइस आइडेंटिफ़ायर के तौर पर नहीं किया जा सकेगा. इस शर्त को पूरा करने का एक तरीका यह है कि जब तक किसी SKU की कम से कम 1,00,000 यूनिट का प्रॉडक्शन न हो जाए, तब तक एक ही पुष्टि करने वाली कुंजी शेयर की जाए. अगर किसी SKU की 1,00,000 से ज़्यादा यूनिट बनाई जाती हैं, तो हर 1,00,000 यूनिट के लिए, अलग-अलग कुंजी का इस्तेमाल किया जा सकता है.
• [9/H-0-1] ‘android.hardware.security.model.compatible’ सुविधा का एलान करना ज़रूरी है.

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

जब हैंडहेल्ड डिवाइस पर सुरक्षित लॉक स्क्रीन की सुविधा काम करती है, तो:

• [9.11/H-1-1] डिवाइस के लिए, उपयोगकर्ता को स्लीप मोड का सबसे कम टाइम आउट चुनने की अनुमति होनी चाहिए. इसका मतलब है कि डिवाइस को अनलॉक से लॉक होने में 15 सेकंड या उससे कम समय लगना चाहिए.
• [9.11/H-1-2] उपयोगकर्ता को सूचनाएं छिपाने और पुष्टि करने के सभी तरीकों को बंद करने की सुविधा देनी चाहिए. हालांकि, 9.11.1 सुरक्षित लॉक स्क्रीन में बताए गए मुख्य तरीके को बंद नहीं किया जा सकता. AOSP, लॉकडाउन मोड के तौर पर ज़रूरी शर्तें पूरी करता है.

अगर हैंडहेल्ड डिवाइस पर एक से ज़्यादा उपयोगकर्ताओं को अनुमति दी गई है और android.hardware.telephony सुविधा फ़्लैग का एलान नहीं किया गया है, तो:

• [9.5/H-2-1] डिवाइस पर प्रतिबंधित प्रोफ़ाइलों की सुविधा काम करती हो. इस सुविधा की मदद से, डिवाइस के मालिक अन्य उपयोगकर्ताओं और उनके ऐक्सेस को मैनेज कर सकते हैं. पाबंदी वाली प्रोफ़ाइलों की मदद से, डिवाइस के मालिक, दूसरे उपयोगकर्ताओं के लिए अलग-अलग एनवायरमेंट तुरंत सेट अप कर सकते हैं. साथ ही, उन एनवायरमेंट में उपलब्ध ऐप्लिकेशन पर ज़्यादा सटीक पाबंदियां भी लगा सकते हैं.

अगर हैंडहेल्ड डिवाइस के लागू होने में कई उपयोगकर्ता शामिल हैं और android.hardware.telephony सुविधा फ़्लैग का एलान किया जाता है, तो:

• [9.5/H-3-1] यह ज़रूरी है कि यह ऐप्लिकेशन, पाबंदी वाली प्रोफ़ाइलों के साथ काम न करे. हालांकि, यह AOSP के कंट्रोल के साथ काम करना चाहिए, ताकि अन्य उपयोगकर्ताओं को वॉइस कॉल और एसएमएस ऐक्सेस करने की अनुमति दी या बंद की जा सके.

Android, System API VoiceInteractionService की मदद से, माइक्रोफ़ोन ऐक्सेस करने के बारे में सूचना दिए बिना, हमेशा चालू रहने वाले हॉटवर्ड की पहचान करने की सुविधा देता है

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

• [9.8/H-1-1] यह पक्का करना ज़रूरी है कि हॉटवर्ड की पहचान करने वाली सेवा, सिर्फ़ सिस्टम या ContentCaptureService को डेटा भेज सके
• [9.8/H-1-2] यह पक्का करना ज़रूरी है कि बोले गए शब्दों का पता लगाने वाली सेवा, माइक से रिकॉर्ड किए गए ऑडियो डेटा या उससे मिला डेटा, सिर्फ़ HotwordDetectionService एपीआई की मदद से सिस्टम सर्वर पर भेजे. इसके अलावा, ContentCaptureService पर भेजने के लिए, ContentCaptureManager एपीआई का इस्तेमाल किया जाना चाहिए.
• [9.8/H-1-3] हार्डवेयर से ट्रिगर किए गए किसी अनुरोध के लिए, माइक से रिकॉर्ड किया गया ऑडियो 30 सेकंड से ज़्यादा का नहीं होना चाहिए. यह अनुरोध, बोले गए शब्दों का पता लगाने वाली सेवा के लिए किया जाता है.
• [9.8/H-1-4] हॉटवर्ड की पहचान करने वाली सेवा के लिए, किसी व्यक्ति के अनुरोध पर, बफ़र किए गए माइक ऑडियो को 8 सेकंड से ज़्यादा पुराना नहीं होना चाहिए.
• [9.8/H-1-5] वॉइस इंटरैक्शन सेवा या इसी तरह की इकाई को, बफ़र किया गया ऐसा माइक ऑडियो नहीं देना चाहिए जो 30 सेकंड से ज़्यादा पुराना हो.
• [9.8/H-1-6] हॉटवर्ड डिटेक्शन की सेवा से, हर हॉटवर्ड के नतीजे के लिए, 100 बाइट से ज़्यादा नॉन-ऑडियो डेटा को ट्रांसमिट करने की अनुमति नहीं दी जानी चाहिए.
• [9.8/H-1-7] हर नेगेटिव हॉटवर्ड के नतीजे पर, हॉटवर्ड का पता लगाने वाली सेवा से ज़्यादा से ज़्यादा पांच बिट का डेटा भेजने की अनुमति नहीं दी जानी चाहिए.
• [9.8/H-1-8] सिस्टम सर्वर से, हॉटवर्ड की पुष्टि करने के अनुरोध पर ही, हॉटवर्ड का पता लगाने वाली सेवा से डेटा ट्रांसफ़र करने की अनुमति होनी चाहिए.
• [9.8/H-1-9] उपयोगकर्ता के इंस्टॉल किए जा सकने वाले ऐप्लिकेशन को, हॉटवर्ड का पता लगाने की सेवा देने की अनुमति नहीं दी जानी चाहिए.
• [9.8/H-1-10] हॉटवर्ड की पहचान करने वाली सेवा के ज़रिए माइक के इस्तेमाल के बारे में, यूज़र इंटरफ़ेस (यूआई) में संख्या के हिसाब से डेटा नहीं दिखना चाहिए.
• [9.8/H-1-11] सुरक्षा से जुड़े शोधकर्ताओं को जांच करने की अनुमति देने के लिए, हॉटवर्ड की पहचान करने वाली सेवा से हर ट्रांसमिशन में शामिल बाइट की संख्या को लॉग करना ज़रूरी है.
• [9.8/H-1-12] यह ज़रूरी है कि डिवाइस में डीबग मोड की सुविधा हो. इससे, हॉटवर्ड डिटेक्शन सेवा से हर ट्रांसमिशन के रॉ कॉन्टेंट को लॉग किया जा सकता है. इससे, सुरक्षा से जुड़े शोधकर्ताओं को जांच करने में मदद मिलती है.
• [9.8/H-1-14] जब बोलकर निर्देश देने की सुविधा या मिलती-जुलती इकाई को, बोलकर दिए गए निर्देश का नतीजा भेजा जाता है, तो माइक्रोफ़ोन इंडिकेटर को दिखाना ज़रूरी है. इस बारे में 9.8.2 सेक्शन में बताया गया है.
• [9.8/H-SR-1] हमारा सुझाव है कि किसी ऐप्लिकेशन को, बोले गए शब्दों को पहचानने की सेवा देने वाली कंपनी के तौर पर सेट करने से पहले, उपयोगकर्ताओं को इसकी सूचना दें.
• [9.8/H-SR-2] हमारा सुझाव है कि आप हॉटवर्ड की पहचान करने वाली सेवा से, बिना स्ट्रक्चर वाले डेटा को ट्रांसफ़र करने की अनुमति न दें.
• [9.8/H-SR-3] हमारा सुझाव है कि आप कम से कम हर घंटे या हर 30 हार्डवेयर-ट्रिगर इवेंट में से जो भी पहले हो, उसमें हॉटवर्ड की पहचान करने वाली सेवा को होस्ट करने की प्रोसेस को रीस्टार्ट करें.

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

• [9.8/H-2-1] इस्तेमाल किए जा सकने वाले हर हॉटवर्ड वाक्यांश के लिए, उपयोगकर्ता को साफ़ तौर पर सूचना देना ज़रूरी है.
• [9.8/H-2-2] हॉटवर्ड की पहचान करने वाली सेवा की मदद से, रॉ ऑडियो डेटा या उससे मिला डेटा सेव नहीं किया जाना चाहिए.
• [9.8/H-2-3] हॉटवर्ड का पता लगाने वाली सेवा से, ऑडियो डेटा, ऐसा डेटा नहीं भेजना चाहिए जिसका इस्तेमाल ऑडियो को पूरी तरह या कुछ हद तक फिर से बनाने के लिए किया जा सकता है. इसके अलावा, हॉटवर्ड से जुड़े ऑडियो कॉन्टेंट को छोड़कर, किसी और कॉन्टेंट को भी नहीं भेजना चाहिए. हालांकि, ContentCaptureService को यह डेटा भेजा जा सकता है.

अगर हैंडहेल्ड डिवाइस पर android.hardware.microphone का इस्तेमाल किया जाता है, तो:

• [9.8.2/H-4-1] जब कोई ऐप्लिकेशन माइक्रोफ़ोन से ऑडियो डेटा ऐक्सेस कर रहा हो, तो माइक्रोफ़ोन इंडिकेटर दिखाना ज़रूरी है. हालांकि, जब माइक्रोफ़ोन को सिर्फ़ HotwordDetectionService, SOURCE_HOTWORD,ContentCaptureService या सेक्शन 9.1 में बताई गई भूमिकाओं वाले ऐप्लिकेशन ऐक्सेस करते हैं, तब ऐसा नहीं करना चाहिए. इन भूमिकाओं के लिए, सीडीडी आइडेंटिफ़ायर [C-4-X] का इस्तेमाल किया जाता है.
• [9.8.2/H-4-2] माइक्रोफ़ोन का इस्तेमाल करके, हाल ही में इस्तेमाल किए गए और चालू ऐप्लिकेशन की सूची दिखानी ज़रूरी है. यह सूची, PermissionManager.getIndicatorAppOpUsageData() से मिली जानकारी के हिसाब से होनी चाहिए. साथ ही, उन ऐप्लिकेशन से जुड़े एट्रिब्यूशन मैसेज भी दिखाए जाने चाहिए.

अगर हैंडहेल्ड डिवाइस पर android.hardware.camera.any का इस्तेमाल किया जाता है, तो:

• [9.8.2/H-5-1] जब कोई ऐप्लिकेशन कैमरे का लाइव डेटा ऐक्सेस कर रहा हो, तो कैमरा इंडिकेटर दिखाना ज़रूरी है. हालांकि, जब कैमरे को सिर्फ़ ऐसे ऐप्लिकेशन ऐक्सेस कर रहे हों जिनके पास सेक्शन 9.1 में बताई गई भूमिकाएं हैं और जिनमें सीडीडी आइडेंटिफ़ायर [C-4-X] है, तब कैमरा इंडिकेटर नहीं दिखाना चाहिए.
• [9.8.2/H-5-2] PermissionManager.getIndicatorAppOpUsageData() से मिले कैमरे के इस्तेमाल से, हाल ही में इस्तेमाल किए गए और ऐक्टिव ऐप्लिकेशन के साथ-साथ उनसे जुड़े एट्रिब्यूशन मैसेज भी दिखाने चाहिए.

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

हैंडहेल्ड डिवाइस पर लागू होने वाले तरीके (* टैबलेट पर लागू नहीं):

• [6.1/H-0-1]* शेल कमांड के साथ काम करना चाहिए cmd testharness.

हैंडहेल्ड डिवाइस पर लागू होने वाले तरीके (* टैबलेट पर लागू नहीं):

• Perfetto
  • [6.1/H-0-2]* शेल उपयोगकर्ता को /system/bin/perfetto बाइनरी दिखानी चाहिए, जो cmdline के साथ काम करती हो और perfetto दस्तावेज़ के मुताबिक हो.
  • [6.1/H-0-3]* perfetto दस्तावेज़ में बताए गए स्कीमा के मुताबिक, protobuf कॉन्फ़िगरेशन को इनपुट के तौर पर स्वीकार करना, ज़रूरी है.
  • [6.1/H-0-4]* perfetto दस्तावेज़ में बताए गए स्कीमा के मुताबिक, 'perfetto' बाइनरी को आउटपुट के तौर पर protobuf ट्रेस लिखना चाहिए.
  • [6.1/H-0-5]* आपको perfetto दस्तावेज़ में बताए गए डेटा सोर्स के साथ-साथ, कम से कम एक और डेटा सोर्स, perfetto बाइनरी के ज़रिए उपलब्ध कराना होगा.
  • [6.1/H-0-6]* Perfetto ट्रैक किया गया डेमन, डिफ़ॉल्ट रूप से चालू होना चाहिए (सिस्टम प्रॉपर्टी persist.traced.enable).

2.2.7. मोबाइल डिवाइस पर वीडियो की परफ़ॉर्मेंस की क्लास

मीडिया परफ़ॉर्मेंस क्लास की परिभाषा के लिए, सेक्शन 7.11 देखें.

2.2.7.1. मीडिया

अगर android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS के लिए, हैंडहेल्ड डिवाइस के लागू होने की जानकारी android.os.Build.VERSION_CODES.S के तौर पर दिखती है, तो:

• यह ज़रूरी है कि यह Android 12 के सीडीडी के सेक्शन 2.2.7.1 में बताई गई मीडिया से जुड़ी ज़रूरी शर्तों को पूरा करता हो.

अगर android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS के लिए, हैंडहेल्ड डिवाइस के लागू होने की जानकारी android.os.Build.VERSION_CODES.T के तौर पर दिखती है, तो:

• [5.1/H-1-1] CodecCapabilities.getMaxSupportedInstances() और VideoCapabilities.getSupportedPerformancePoints() तरीकों की मदद से, किसी भी कोडेक कॉम्बिनेशन में एक साथ चलाए जा सकने वाले, हार्डवेयर वीडियो डिकोडर सेशन की ज़्यादा से ज़्यादा संख्या का विज्ञापन करना ज़रूरी है.
• [5.1/H-1-2] डिवाइस में, 1080p रिज़ॉल्यूशन@30 fps पर एक साथ चलने वाले किसी भी कोडेक कॉम्बिनेशन में, हार्डवेयर वीडियो डिकोडर सेशन (AVC, HEVC, VP9, AV1 या इसके बाद के वर्शन) के छह इंस्टेंस काम करने चाहिए.
• [5.1/H-1-3] CodecCapabilities.getMaxSupportedInstances() और VideoCapabilities.getSupportedPerformancePoints() तरीकों की मदद से, किसी भी कोडेक कॉम्बिनेशन में एक साथ चलाए जा सकने वाले, ज़्यादा से ज़्यादा हार्डवेयर वीडियो एन्कोडर सेशन का विज्ञापन करना ज़रूरी है.
• [5.1/H-1-4] यह ज़रूरी है कि डिवाइस पर, किसी भी कोडेक कॉम्बिनेशन में 1080 पिक्सल रिज़ॉल्यूशन@30fps पर एक साथ चलने वाले हार्डवेयर वीडियो एन्कोडर सेशन (AVC, HEVC, VP9, AV1 या इसके बाद के वर्शन) के छह इंस्टेंस काम करते हों.
• [5.1/H-1-5] CodecCapabilities.getMaxSupportedInstances() और VideoCapabilities.getSupportedPerformancePoints() तरीकों की मदद से, किसी भी कोडेक कॉम्बिनेशन में एक साथ चलाए जा सकने वाले, ज़्यादा से ज़्यादा हार्डवेयर वीडियो एन्कोडर और डिकोडर सेशन का विज्ञापन करना ज़रूरी है.
• [5.1/H-1-6] यह ज़रूरी है कि डिवाइस में, हार्डवेयर वीडियो डिकोडर और हार्डवेयर वीडियो एन्कोडर सेशन (AVC, HEVC, VP9, AV1 या इसके बाद के वर्शन) के छह इंस्टेंस काम करते हों. साथ ही, ये सभी इंस्टेंस किसी भी कोडेक कॉम्बिनेशन में, 1080p@30fps रिज़ॉल्यूशन पर एक साथ काम करते हों.
• [5.1/H-1-7] लोड होने पर, सभी हार्डवेयर वीडियो एन्कोडर के लिए, 1080 पिक्सल या उससे कम रिज़ॉल्यूशन वाले वीडियो को एन्कोड करने के सेशन के लिए, कोडेक शुरू होने में लगने वाला समय 40 मिलीसेकंड या उससे कम होना चाहिए. यहां लोड को 1080 पिक्सल से 720 पिक्सल वाले वीडियो को एक साथ ट्रांसकोड करने के सेशन के तौर पर परिभाषित किया गया है. इसमें हार्डवेयर वीडियो कोडेक का इस्तेमाल किया जाता है. साथ ही, 1080 पिक्सल वाली ऑडियो-वीडियो रिकॉर्डिंग को शुरू किया जाता है. Dolby vision कोडेक के लिए, कोडेक शुरू होने में लगने वाला समय 50 मिलीसेकंड या उससे कम होना चाहिए.
• [5.1/H-1-8] लोड होने पर, सभी ऑडियो एन्कोडर के लिए 128 केबीपीएस या उससे कम बिटरेट वाले ऑडियो कोडिंग सेशन के लिए, कोडेक शुरू करने में लगने वाला समय 30 एमएस या उससे कम होना चाहिए. यहां लोड को, 1080 पिक्सल से 720 पिक्सल वाले वीडियो को एक साथ ट्रांसकोड करने वाले सेशन के तौर पर परिभाषित किया गया है. इस सेशन में, हार्डवेयर वीडियो कोडेक का इस्तेमाल किया जाता है. साथ ही, 1080 पिक्सल वाली ऑडियो-वीडियो रिकॉर्डिंग को शुरू किया जाता है.
• [5.1/H-1-9] यह ज़रूरी है कि डिवाइस में, सुरक्षित हार्डवेयर वीडियो डिकोडर सेशन (AVC, HEVC, VP9, AV1 या इसके बाद के वर्शन) के दो इंस्टेंस काम करते हों. ये इंस्टेंस, किसी भी कोडेक कॉम्बिनेशन में 1080 पिक्सल रिज़ॉल्यूशन पर 30 fps पर एक साथ काम करते हों.
• [5.1/H-1-10] यह ज़रूरी है कि डिवाइस में, एक सुरक्षित हार्डवेयर वीडियो डिकोडर सेशन के साथ-साथ, तीन ऐसे हार्डवेयर वीडियो डिकोडर सेशन काम करते हों जो सुरक्षित न हों. साथ ही, ये सभी सेशन एक साथ 1080 पिक्सल रिज़ॉल्यूशन@30fps पर चलने वाले किसी भी कोडेक कॉम्बिनेशन में काम करते हों.
• [5.1/ H-1-11] डिवाइस पर मौजूद हर हार्डवेयर AVC, HEVC, VP9 या AV1 डिकोडर के लिए, सुरक्षित डिकोडर की सुविधा काम करनी चाहिए.
• [5.1/H-1-12] सभी हार्डवेयर वीडियो डिकोडर के लिए, 1080 पिक्सल या उससे कम रिज़ॉल्यूशन वाले वीडियो को डिकोड करने के दौरान, कोडेक को शुरू करने में लगने वाला समय 40 मिलीसेकंड या उससे कम होना चाहिए. यहां लोड को, 1080 पिक्सल से 720 पिक्सल वाले वीडियो को एक साथ ट्रांसकोड करने वाले सेशन के तौर पर परिभाषित किया गया है. इस सेशन में, हार्डवेयर वीडियो कोडेक का इस्तेमाल किया जाता है. साथ ही, 1080 पिक्सल वाले ऑडियो-वीडियो को प्लेबैक करने की प्रोसेस शुरू की जाती है. Dolby vision कोडेक के लिए, कोडेक शुरू होने में लगने वाला समय 50 मिलीसेकंड या उससे कम होना चाहिए.
• [5.1/H-1-13] लोड होने पर, सभी ऑडियो डिकोडर के लिए 128 केबीपीएस या उससे कम बिटरेट वाले ऑडियो डिकोडिंग सेशन के लिए, कोडेक को शुरू करने में लगने वाला समय 30 मिलीसेकंड या उससे कम होना चाहिए. यहां लोड को, 1080 पिक्सल से 720 पिक्सल वाले वीडियो के लिए, एक साथ ट्रांसकोड करने वाले सेशन के तौर पर परिभाषित किया गया है. इस सेशन में, हार्डवेयर वीडियो कोडेक का इस्तेमाल किया जाता है. साथ ही, 1080 पिक्सल वाले ऑडियो-वीडियो को प्लेबैक करने की प्रोसेस शुरू की जाती है.
• [5.1/H-1-14] यह ज़रूरी है कि डिवाइस में AV1 हार्डवेयर डिकोडर Main 10, लेवल 4.1 काम करता हो.
• [5.1/H-SR-1] हमारा सुझाव है कि AV1 हार्डवेयर डिकोडर के लिए, फ़िल्म ग्रेन की सुविधा का इस्तेमाल करें.
• [5.1/H-1-15] इसमें कम से कम एक हार्डवेयर वीडियो डिकोडर होना चाहिए, जो 4K60 को सपोर्ट करता हो.
• [5.1/H-1-16] इसमें कम से कम एक ऐसा हार्डवेयर वीडियो एन्कोडर होना चाहिए जो 4K60 को सपोर्ट करता हो.
• [5.3/H-1-1] लोड के दौरान, 1080 पिक्सल और 60 एफ़पीएस वाले वीडियो सेशन के लिए, 10 सेकंड में एक से ज़्यादा फ़्रेम नहीं छोड़े जाने चाहिए.इसका मतलब है कि फ़्रेम ड्रॉप 0.167 प्रतिशत से कम होना चाहिए. लोड का मतलब है, हार्डवेयर वीडियो कोडेक का इस्तेमाल करके, 1080 पिक्सल से 720 पिक्सल में वीडियो को एक साथ ट्रांसकोड करने के साथ-साथ 128 केबीपीएस AAC ऑडियो चलाने का सेशन.
• [5.3/H-1-2] 60 fps वीडियो सेशन के दौरान, वीडियो रिज़ॉल्यूशन में बदलाव होने पर, 10 सेकंड में एक से ज़्यादा फ़्रेम नहीं छोड़े जाने चाहिए. लोड का मतलब है, हार्डवेयर वीडियो कोडेक का इस्तेमाल करके, 1080 पिक्सल से 720 पिक्सल में वीडियो को एक साथ ट्रांसकोड करने के साथ-साथ 128 केबीपीएस AAC ऑडियो चलाने का सेशन.
• [5.6/H-1-1] टैप-टू-टोन की देरी 80 मिलीसेकंड या इससे कम होनी चाहिए. इसके लिए, OboeTester टैप-टू-टोन टेस्ट या CTS Verifier टैप-टू-टोन टेस्ट का इस्तेमाल करें.
• [5.6/H-1-2] कम से कम एक काम करने वाले डेटा पाथ पर, ऑडियो के राउंड-ट्रिप में लगने वाला समय 80 मिलीसेकंड या उससे कम होना चाहिए.
• [5.6/H-1-3] अगर 3.5 मिमी ऑडियो जैक मौजूद हैं, तो स्टीरियो आउटपुट के लिए 24-बिट ऑडियो की सुविधा होनी चाहिए. साथ ही, अगर यूएसबी ऑडियो की सुविधा है, तो कम इंतज़ार और स्ट्रीमिंग कॉन्फ़िगरेशन के लिए पूरे डेटा पाथ में यह सुविधा काम करनी चाहिए. कम लेटेंसी वाले कॉन्फ़िगरेशन के लिए, ऐप्लिकेशन को AAudio का इस्तेमाल कम लेटेंसी वाले कॉलबैक मोड में करना चाहिए. स्ट्रीमिंग कॉन्फ़िगरेशन के लिए, ऐप्लिकेशन को Java AudioTrack का इस्तेमाल करना चाहिए. कम इंतज़ार और स्ट्रीमिंग, दोनों कॉन्फ़िगरेशन में, एचएएल आउटपुट सिंक को अपने टारगेट आउटपुट फ़ॉर्मैट के लिए, AUDIO_FORMAT_PCM_24_BIT, AUDIO_FORMAT_PCM_24_BIT_PACKED, AUDIO_FORMAT_PCM_32_BIT या AUDIO_FORMAT_PCM_FLOAT में से किसी एक को स्वीकार करना चाहिए.
• [5.6/H-1-4] यह ज़रूरी है कि डिवाइस में चार चैनल वाले यूएसबी ऑडियो डिवाइसों के साथ काम करने की सुविधा हो. डीजे कंट्रोलर, गाने की झलक दिखाने के लिए इसका इस्तेमाल करते हैं.
• [5.6/H-1-5] ऐप्लिकेशन, क्लास के मुताबिक काम करने वाले एमआईडीआई डिवाइसों के साथ काम करना चाहिए. साथ ही, एमआईडीआई की सुविधा के फ़्लैग के बारे में बताना चाहिए.
• [5.7/H-1-2] MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL के साथ, कॉन्टेंट को डिक्रिप्ट करने की इन सुविधाओं का इस्तेमाल करना ज़रूरी है.

सैंपल का कम से कम साइज़	4 एमबी
सबसैंपल की कम से कम संख्या - H264 या HEVC	32
सब-सैंपल की कम से कम संख्या - VP9	9
सब-सैंपल की कम से कम संख्या - AV1	288
सबसैंपल बफ़र का कम से कम साइज़	1 एमबी
सामान्य क्रिप्टो बफ़र का कम से कम साइज़	500 केआईबी
एक साथ चल रहे सेशन की कम से कम संख्या	30
हर सेशन के लिए कुंजियों की कम से कम संख्या	20
सभी सेशन के लिए, कुंजियों की कम से कम कुल संख्या	80
डीआरएम कुंजियों की कम से कम कुल संख्या (सभी सेशन)	6
मैसेज का साइज़	16 केआईबी
हर सेकंड डिक्रिप्ट किए गए फ़्रेम	60 FPS (फ़्रेम प्रति सेकंड)

2.2.7.2. कैमरा

अगर android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS के लिए, हैंडहेल्ड डिवाइस के लागू होने की जानकारी android.os.Build.VERSION_CODES.S के तौर पर दिखती है, तो:

• यह ज़रूरी है कि ऐप्लिकेशन, Android 12 के सीडीडी के सेक्शन 2.2.7.2 में बताई गई कैमरे की ज़रूरी शर्तों को पूरा करता हो.

अगर android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS के लिए, हैंडहेल्ड डिवाइस के लागू होने की जानकारी android.os.Build.VERSION_CODES.T के तौर पर दिखती है, तो:

• [7.5/H-1-1] डिवाइस में पीछे की ओर वाला मुख्य कैमरा होना चाहिए. इसका रिज़ॉल्यूशन कम से कम 12 मेगापिक्सल होना चाहिए. साथ ही, यह 4K@30fps पर वीडियो कैप्चर करने की सुविधा देना चाहिए. मुख्य पीछे वाला कैमरा, सबसे कम कैमरा आईडी वाला पीछे वाला कैमरा होता है.
• [7.5/H-1-2] डिवाइस में कम से कम 5 मेगापिक्सल का मुख्य फ़्रंट कैमरा होना चाहिए. साथ ही, यह 1080p@30fps पर वीडियो कैप्चर करने की सुविधा भी देना चाहिए. मुख्य सामने वाला कैमरा, सबसे कम कैमरा आईडी वाला सामने वाला कैमरा होता है.
• [7.5/H-1-3] android.info.supportedHardwareLevel प्रॉपर्टी के साथ काम करना चाहिए. यह प्रॉपर्टी, पीछे के प्राइमरी कैमरे के लिए FULL या इससे बेहतर और सामने के प्राइमरी कैमरे के लिए LIMITED या इससे बेहतर होनी चाहिए.
• [7.5/H-1-4] दोनों प्राइमरी कैमरों के लिए, CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME की सुविधा का होना ज़रूरी है.
• [7.5/H-1-5] 1080p रिज़ॉल्यूशन के लिए, camera2 JPEG कैप्चर में लगने वाला समय 1000 मिलीसेकंड से कम होना चाहिए. यह समय, दोनों प्राइमरी कैमरों के लिए, CTS कैमरा की परफ़ॉर्मेंस की जांच के दौरान, रोशनी की आईटीएस स्थितियों (3000K) के तहत मेज़र किया जाता है.
• [7.5/H-1-6] कैमरा चालू होने में लगने वाला समय (कैमरा खोलने से लेकर, पहले झलक फ़्रेम तक) 500 मिलीसेकंड से कम होना चाहिए. यह समय, दोनों प्राइमरी कैमरों के लिए, CTS कैमरा परफ़ॉर्मेंस टेस्ट के तहत, लाइटिंग की आईटीएस स्थितियों (3000K) में मेज़र किया जाता है.
• [7.5/H-1-8] प्राइमरी रियर कैमरे के लिए, CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW और android.graphics.ImageFormat.RAW_SENSOR के साथ काम करना चाहिए.
• [7.5/H-1-9] डिवाइस में पीछे की ओर वाला मुख्य कैमरा होना चाहिए, जो 720 पिक्सल या 1080 पिक्सल @ 240fps पर काम करता हो.
• [7.5/H-1-10] अगर एक ही दिशा में देखने वाला अल्ट्रा-वाइड आरजीबी कैमरा मौजूद है, तो प्राइमरी कैमरों के लिए ZOOM_RATIO कम से कम 1.0 से कम होना चाहिए.
• [7.5/H-1-11] मुख्य कैमरों पर, एक साथ सामने और पीछे की स्ट्रीमिंग की सुविधा लागू करना ज़रूरी है.
• [7.5/H-1-12] प्राइमरी बैक कैमरे के लिए, CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION के साथ काम करना ज़रूरी है.
• [7.5/H-1-13] अगर पीछे की तरफ़ एक से ज़्यादा आरजीबी कैमरे हैं, तो मुख्य पीछे की तरफ़ मौजूद कैमरे के लिए LOGICAL_MULTI_CAMERA की सुविधा काम करती होनी चाहिए.
• [7.5/H-1-14] डिवाइस के मुख्य सामने वाले और मुख्य पीछे वाले कैमरे, दोनों के लिए STREAM_USE_CASE की सुविधा काम करती होनी चाहिए.

2.2.7.3. हार्डवेयर

अगर हाथ में पकड़े जाने वाले डिवाइस के लागू होने पर, android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS के लिए android.os.Build.VERSION_CODES.S दिखता है, तो:

• यह Android 12 CDD के सेक्शन 2.2.7.3 में दी गई, हार्डवेयर से जुड़ी ज़रूरी शर्तों के मुताबिक होना चाहिए.

अगर हाथ में पकड़े जाने वाले डिवाइस के लागू होने पर, android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS के लिए android.os.Build.VERSION_CODES.T दिखता है, तो:

• [7.1.1.1/H-2-1] स्क्रीन का रिज़ॉल्यूशन कम से कम 1080p होना चाहिए.
• [7.1.1.3/H-2-1] स्क्रीन का डीपीआई कम से कम 400 डीपीआई होना चाहिए.
• [7.6.1/H-2-1] डिवाइस में कम से कम 8 जीबी फ़िज़िकल मेमोरी होनी चाहिए.

2.2.7.4. परफ़ॉर्मेंस

अगर हाथ में पकड़े जाने वाले डिवाइस के लागू होने पर, android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS के लिए android.os.Build.VERSION_CODES.S दिखता है, तो:

• यह Android 12 CDD के सेक्शन 2.2.7.4 में बताई गई परफ़ॉर्मेंस से जुड़ी ज़रूरी शर्तों को पूरा करता हो.

अगर हाथ में पकड़े जाने वाले डिवाइस के लागू होने पर, android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS के लिए android.os.Build.VERSION_CODES.T दिखता है, तो:

• [8.2/H-1-1] यह पक्का करना ज़रूरी है कि सीक्वेंशियल राइटिंग की परफ़ॉर्मेंस कम से कम 125 एमबी/सेकंड हो.
• [8.2/H-1-2] यह पक्का करना ज़रूरी है कि रैंडम राइटिंग की परफ़ॉर्मेंस कम से कम 10 एमबी/सेकंड हो.
• [8.2/H-1-3] यह पक्का करना ज़रूरी है कि सीक्वेंशियल रीड परफ़ॉर्मेंस कम से कम 250 एमबी/सेकंड हो.
• [8.2/H-1-4] यह पक्का करना ज़रूरी है कि रैंडम रीड परफ़ॉर्मेंस कम से कम 40 एमबी/सेकंड हो.

2.3. टेलिविज़न से जुड़ी ज़रूरी शर्तें

Android Television डिवाइस से, Android डिवाइस के उस वर्शन का मतलब है जो मनोरंजन के लिए इंटरफ़ेस के तौर पर काम करता है. इस डिवाइस पर, डिजिटल मीडिया, फ़िल्में, गेम, ऐप्लिकेशन, और/या लाइव टीवी देखने के लिए, उपयोगकर्ताओं को करीब 10 फ़ीट की दूरी पर बैठना पड़ता है. इसे “लेन बैक” या “10 फ़ीट यूज़र इंटरफ़ेस” भी कहा जाता है.

Android डिवाइस को टीवी के तौर पर तब ही माना जाता है, जब वह इन सभी शर्तों को पूरा करता हो:

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

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

2.3.1. हार्डवेयर

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

• [7.2.2/T-0-1] D-pad के साथ काम करना चाहिए.
• [7.2.3/T-0-1] होम और बैक बटन की सुविधाएं उपलब्ध कराना ज़रूरी है.
• [7.2.3/T-0-2] फ़ोरग्राउंड ऐप्लिकेशन को, बैक फ़ंक्शन (KEYCODE_BACK) के सामान्य और लंबे समय तक दबाए जाने के इवेंट, दोनों को भेजना ज़रूरी है.
• [7.2.6.1/T-0-1] गेम कंट्रोलर के लिए सहायता शामिल करना ज़रूरी है. साथ ही, android.hardware.gamepad सुविधा फ़्लैग का एलान करना ज़रूरी है.
• [7.2.7/T] डिवाइस में रिमोट कंट्रोल होना चाहिए, जिससे उपयोगकर्ता टच न करने वाले नेविगेशन और मुख्य नेविगेशन बटन के इनपुट को ऐक्सेस कर सकें.

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

• [7.3.4/T-1-1] यह ज़रूरी है कि यह कम से कम 100 हर्ट्ज़ की फ़्रीक्वेंसी तक इवेंट की रिपोर्ट कर सके.
• [7.3.4/T-1-2] यह ज़रूरी है कि यह हर सेकंड 1,000 डिग्री तक ओरिएंटेशन में हुए बदलावों को मेज़र कर सके.

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

• [7.4.3/T-0-1] डिवाइस में ब्लूटूथ और ब्लूटूथ LE की सुविधा होनी चाहिए.
• [7.6.1/T-0-1] ऐप्लिकेशन के निजी डेटा (जिसे "/data" पार्टीशन भी कहा जाता है) के लिए, कम से कम 4 जीबी का नॉन-वॉल्व्यूलेट स्टोरेज होना चाहिए.

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

• [7.5.3/T-1-1] इसमें, ऐसे बाहरी कैमरे के लिए सहायता शामिल होनी चाहिए जो इस यूएसबी पोर्ट से कनेक्ट होता है. हालांकि, यह ज़रूरी नहीं है कि वह हमेशा कनेक्ट रहे.

अगर टीवी डिवाइस पर 32-बिट प्रोसेसर का इस्तेमाल किया जा रहा है, तो:

• [7.6.1/T-1-1] अगर इनमें से किसी भी डेंसिटी का इस्तेमाल किया जाता है, तो kernel और userspace के लिए कम से कम 896 एमबी मेमोरी उपलब्ध होनी चाहिए:

  • छोटी/सामान्य स्क्रीन पर 400 डीपीआई या उससे ज़्यादा
  • बड़ी स्क्रीन पर xhdpi या उससे ज़्यादा
  • बहुत बड़ी स्क्रीन पर tvdpi या उससे ज़्यादा

अगर टीवी डिवाइस पर 64-बिट प्रोसेसर का इस्तेमाल किया जा रहा है, तो:

• [7.6.1/T-2-1] अगर इनमें से किसी भी डेंसिटी का इस्तेमाल किया जाता है, तो कर्नेल और यूज़रस्पेस के लिए उपलब्ध मेमोरी कम से कम 1280 एमबी होनी चाहिए:

  • छोटी/सामान्य स्क्रीन पर 400 डीपीआई या उससे ज़्यादा
  • बड़ी स्क्रीन पर xhdpi या उससे ज़्यादा
  • बहुत बड़ी स्क्रीन पर tvdpi या उससे ज़्यादा

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

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

• [7.8.1/T] इसमें माइक्रोफ़ोन होना चाहिए.
• [7.8.2/T-0-1] इसमें ऑडियो आउटपुट होना चाहिए और इसकी जानकारी दी गई हो android.hardware.audio.output.

2.3.2. मल्टीमीडिया

टीवी डिवाइस पर, ऑडियो को एन्कोड करने और डिकोड करने के लिए, इन फ़ॉर्मैट का इस्तेमाल किया जाना चाहिए. साथ ही, इन्हें तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराया जाना चाहिए:

• [5.1/T-0-1] MPEG-4 AAC प्रोफ़ाइल (AAC LC)
• [5.1/T-0-2] MPEG-4 HE AAC Profile (AAC+)
• [5.1/T-0-3] AAC ELD (बेहतर कम देरी वाला AAC)

टीवी डिवाइस पर, वीडियो को इन फ़ॉर्मैट में एन्कोड किया जा सकता है. साथ ही, इन्हें तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराया जा सकता है:

• [5.2/T-0-1] H.264
• [5.2/T-0-2] VP8

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

• [5.2.2/T-SR-1] हमारा सुझाव है कि आप 720 पिक्सल और 1080 पिक्सल रिज़ॉल्यूशन वाले वीडियो को 30 फ़्रेम प्रति सेकंड पर H.264 एन्कोडिंग के साथ इस्तेमाल करें.

टेलिविज़न डिवाइस में, वीडियो को डिकोड करने के लिए इन फ़ॉर्मैट का इस्तेमाल किया जाना चाहिए. साथ ही, इन्हें तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराना चाहिए:

• [5.3.3/T-0-1] MPEG-4 SP
• [5.3.4/T-0-2] H.264 AVC
• [5.3.5/T-0-3] H.265 HEVC
• [5.3.6/T-0-4] VP8
• [5.3.7/T-0-5] VP9
• [5.3.1/T-0-6] MPEG-2

टेलिविज़न डिवाइस में, MPEG-2 को डिकोड करने की सुविधा होनी चाहिए. इस बारे में, सेक्शन 5.3.1 में बताया गया है. साथ ही, यह ज़रूरी है कि डिवाइस में स्टैंडर्ड वीडियो फ़्रेम रेट और रिज़ॉल्यूशन की सुविधा हो. इनमें ये शामिल हैं:

• [5.3.1/T-1-1] एचडी 1080 पिक्सल, 29.97 फ़्रेम प्रति सेकंड पर, मुख्य प्रोफ़ाइल के हाई लेवल के साथ.
• [5.3.1/T-1-2] एचडी 1080i, 59.94 फ़्रेम प्रति सेकंड पर, मुख्य प्रोफ़ाइल के हाई लेवल के साथ. उन्हें इंटरलेस किए गए MPEG-2 वीडियो को डिइंटरलेस करना होगा और उसे तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराना होगा.

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

• [5.3.4/T-1-1] बेसलाइन प्रोफ़ाइल के साथ, 60 फ़्रेम प्रति सेकंड पर एचडी 1080p
• [5.3.4/T-1-2] मुख्य प्रोफ़ाइल के साथ 60 फ़्रेम प्रति सेकंड पर एचडी 1080p
• [5.3.4/T-1-3] हाई प्रोफ़ाइल लेवल 4.2 के साथ, 60 फ़्रेम प्रति सेकंड पर एचडी 1080 पिक्सल

H.265 हार्डवेयर डीकोडर वाले टेलिविज़न डिवाइसों में, H.265 डिकोडिंग की सुविधा काम करनी चाहिए. इस बारे में, सेक्शन 5.3.5 में बताया गया है. साथ ही, यह सुविधा स्टैंडर्ड वीडियो फ़्रेम रेट और रिज़ॉल्यूशन पर काम करनी चाहिए. इनमें ये शामिल हैं:

• [5.3.5/T-1-1] मुख्य प्रोफ़ाइल लेवल 4.1 के साथ, 60 फ़्रेम प्रति सेकंड पर एचडी 1080p

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

• [5.3.5/T-2-1] यह ज़रूरी है कि डिवाइस, Main10 लेवल 5 के मुख्य टीयर की प्रोफ़ाइल के साथ, 60 फ़्रेम प्रति सेकंड पर यूएचडी डिकोडिंग प्रोफ़ाइल के साथ काम करे

टीवी डिवाइस पर VP8 डिकोडिंग की सुविधा काम करनी चाहिए. इस बारे में ज़्यादा जानकारी, सेक्शन 5.3.6 में दी गई है. साथ ही, यह सुविधा इन स्टैंडर्ड वीडियो फ़्रेम रेट और रिज़ॉल्यूशन पर काम करनी चाहिए:

• [5.3.6/T-1-1] 60 फ़्रेम प्रति सेकंड पर एचडी 1080 पिक्सल की डिकोडिंग प्रोफ़ाइल

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

• [5.3.7/T-1-1] प्रोफ़ाइल 0 (8 बिट कलर डेप्थ) के साथ, 60 फ़्रेम प्रति सेकंड पर एचडी 1080 पिक्सल

अगर टीवी डिवाइस में VP9 हार्डवेयर डिकोडर का इस्तेमाल किया गया है और वे VP9 डिकोडिंग और यूएचडी डिकोडिंग प्रोफ़ाइल के साथ काम करते हैं, तो:

• [5.3.7/T-2-1] यह ज़रूरी है कि डिवाइस, प्रोफ़ाइल 0 (8 बिट कलर डेप्थ) के साथ 60 फ़्रेम प्रति सेकंड पर, यूएचडी डिकोडिंग प्रोफ़ाइल के साथ काम करे.
• [5.3.7/T-SR1] हमारा सुझाव है कि आप प्रोफ़ाइल 2 (10 बिट कलर डेप्थ) के साथ, 60 फ़्रेम प्रति सेकंड पर यूएचडी डिकोडिंग प्रोफ़ाइल का इस्तेमाल करें.

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

• [5.5/T-0-1] इसमें सिस्टम के मुख्य वॉल्यूम और काम करने वाले आउटपुट पर डिजिटल ऑडियो आउटपुट वॉल्यूम कम करने की सुविधा शामिल होनी चाहिए. हालांकि, यह सुविधा कंप्रेस किए गए ऑडियो पासथ्रू आउटपुट के लिए नहीं होनी चाहिए. कंप्रेस किए गए ऑडियो पासथ्रू आउटपुट में, डिवाइस पर ऑडियो को डिकोड नहीं किया जाता.

अगर टीवी डिवाइस में डिसप्ले पहले से मौजूद नहीं है, लेकिन एचडीएमआई के ज़रिए कनेक्ट किए गए किसी बाहरी डिसप्ले के साथ काम करता है, तो:

• [5.8/T-0-1] एचडीएमआई आउटपुट मोड को सेट करना ज़रूरी है, ताकि 50 हर्ट्ज़ या 60 हर्ट्ज़ रिफ़्रेश रेट के साथ काम करने वाला ज़्यादा से ज़्यादा रिज़ॉल्यूशन चुना जा सके.
• [5.8/T-SR-1] हमारा सुझाव है कि उपयोगकर्ता के लिए, एचडीएमआई रीफ़्रेश रेट चुनने का विकल्प उपलब्ध कराएं.
• [5.8] डिवाइस को जिस देश/इलाके में बेचा जाता है वहां के वीडियो रीफ़्रेश रेट के हिसाब से, HDMI आउटपुट मोड के रीफ़्रेश रेट को 50Hz या 60Hz पर सेट करना चाहिए.

अगर टीवी डिवाइस में डिसप्ले पहले से मौजूद नहीं है, लेकिन एचडीएमआई के ज़रिए कनेक्ट किए गए किसी बाहरी डिसप्ले के साथ काम करता है, तो:

• [5.8/T-1-1] यह HDCP 2.2 के साथ काम करना चाहिए.

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

• [5.8/T-2-1] यह HDCP 1.4 के साथ काम करना चाहिए

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

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

• [3/T-0-1] android.software.leanback और android.hardware.type.television सुविधाओं के बारे में ज़रूर बताएं.
• [3.2.3.1/T-0-1] यहां दिए गए ऐप्लिकेशन इंटेंट के मुताबिक तय किए गए सभी सार्वजनिक इंटेंट फ़िल्टर पैटर्न के लिए, इंटेंट हैंडलर के साथ एक या एक से ज़्यादा ऐप्लिकेशन या सेवा कॉम्पोनेंट को पहले से लोड करना ज़रूरी है.
• [3.4.1/T-0-1] android.webkit.Webview एपीआई को पूरी तरह से लागू करना ज़रूरी है.

अगर Android Television डिवाइस पर लॉक स्क्रीन की सुविधा काम करती है,तो:

• [3.8.10/T-1-1] ऐप्लिकेशन को Lock screen पर सूचनाएं दिखानी चाहिए. इनमें मीडिया सूचना टेंप्लेट भी शामिल है.

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

• [3.8.14/T-SR-1] हमारा सुझाव है कि आप मल्टी-विंडो में पिक्चर में पिक्चर (पीआईपी) मोड का इस्तेमाल करें.
• [3.10/T-0-1] ऐप्लिकेशन में, तीसरे पक्ष की सुलभता सेवाओं के साथ काम करने की सुविधा होनी चाहिए.
• [3.10/T-SR-1] हमारा सुझाव है कि डिवाइस पर सुलभता सेवाओं को पहले से लोड करें. ये सेवाएं, TalkBack के ओपन सोर्स प्रोजेक्ट में बताई गई, Switch Access और TalkBack (पहले से इंस्टॉल किए गए टेक्स्ट-टू-स्पीच इंजन के साथ काम करने वाली भाषाओं के लिए) जैसी सुलभता सेवाओं के बराबर या उनसे बेहतर होनी चाहिए.

अगर टेलिविज़न डिवाइस पर लागू की गई सुविधा के बारे में android.hardware.audio.output की शिकायत की जाती है, तो:

• [3.11/T-SR-1] हमारा सुझाव है कि आप डिवाइस पर उपलब्ध भाषाओं के साथ काम करने वाला TTS इंजन शामिल करें.
• [3.11/T-1-1] तीसरे पक्ष के टीटीएस इंजन को इंस्टॉल करने की सुविधा होनी चाहिए.

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

• [3.12/T-0-1] यह ज़रूरी है कि यह टीवी इनपुट फ़्रेमवर्क के साथ काम करे.

2.3.4. परफ़ॉर्मेंस और पावर

• [8.1/T-0-1] फ़्रेम के इंतज़ार का समय एक जैसा होना. फ़्रेम रेट में उतार-चढ़ाव या फ़्रेम रेंडर होने में लगने वाला समय, एक सेकंड में पांच फ़्रेम से ज़्यादा नहीं होना चाहिए. साथ ही, यह एक सेकंड में एक फ़्रेम से कम होना चाहिए.
• [8.2/T-0-1] यह पक्का करना ज़रूरी है कि क्रम से लिखने की परफ़ॉर्मेंस कम से कम 5 एमबी/सेकंड हो.
• [8.2/T-0-2] यह पक्का करना ज़रूरी है कि रैंडम राइटिंग की परफ़ॉर्मेंस कम से कम 0.5 एमबी/सेकंड हो.
• [8.2/T-0-3] यह पक्का करना ज़रूरी है कि क्रम से पढ़ने की परफ़ॉर्मेंस कम से कम 15 एमबी/सेकंड हो.
• [8.2/T-0-4] यह पक्का करना ज़रूरी है कि रैंडम रीड की परफ़ॉर्मेंस कम से कम 3.5 एमबी/सेकंड हो.

अगर टीवी डिवाइस में, AOSP में शामिल डिवाइस की पावर मैनेजमेंट को बेहतर बनाने वाली सुविधाएं शामिल हैं या AOSP में शामिल सुविधाओं को बढ़ाया गया है, तो:

• [8.3/T-1-1] बैटरी सेवर मोड को चालू और बंद करने के लिए, उपयोगकर्ता को आसानी से ऐक्सेस करने की सुविधा देना ज़रूरी है.

अगर टीवी डिवाइस में बैटरी नहीं है, तो:

• [8.3/T-1-2] डिवाइस को बैटरी रहित डिवाइस के तौर पर रजिस्टर करना ज़रूरी है, जैसा कि बैटरी रहित डिवाइसों के साथ काम करने की सुविधा में बताया गया है.

अगर टीवी डिवाइस में बैटरी है, तो:

• [8.3/T-1-3] ऐप्लिकेशन स्टैंडबाय और Doze पावर-सेविंग मोड से छूट पाने वाले सभी ऐप्लिकेशन दिखाने के लिए, उपयोगकर्ता को सुविधा देना ज़रूरी है.

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

• [8.4/T-0-1] हर कॉम्पोनेंट के लिए, बिजली की खपत की प्रोफ़ाइल देना ज़रूरी है. इससे हर हार्डवेयर कॉम्पोनेंट के लिए, बिजली की खपत की वैल्यू और समय के साथ कॉम्पोनेंट की वजह से बैटरी की खपत के अनुमान के बारे में पता चलता है. इस बारे में Android Open Source Project की साइट पर जानकारी दी गई है.
• [8.4/T-0-2] बिजली की खपत की सभी वैल्यू को मिलीऐंपियर घंटे (mAh) में रिपोर्ट करना ज़रूरी है.
• [8.4/T-0-3] हर प्रोसेस के यूआईडी के हिसाब से, सीपीयू की बिजली की खपत की जानकारी देना ज़रूरी है. Android ओपन सोर्स प्रोजेक्ट, uid_cputime कर्नेल मॉड्यूल लागू करने की ज़रूरी शर्तें पूरी करता है.
• [8.4/T] अगर किसी ऐप्लिकेशन के लिए, हार्डवेयर कॉम्पोनेंट के पावर इस्तेमाल को एट्रिब्यूट नहीं किया जा सकता, तो इसे हार्डवेयर कॉम्पोनेंट को एट्रिब्यूट किया जाना चाहिए.
• [8.4/T-0-4] ऐप्लिकेशन डेवलपर को, बिजली की खपत की जानकारी adb shell dumpsys batterystats शेल कमांड के ज़रिए उपलब्ध कराना ज़रूरी है.

2.3.5. सुरक्षा मॉडल

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

• [9.11/T-0-1] अलग से एक्ज़ीक्यूशन एनवायरमेंट का इस्तेमाल करके, पासकोड को लागू करने के लिए बैक अप लेना ज़रूरी है.
• [9.11/T-0-2] इसमें आरएसए, एईएस, ईसीडीएसए, और एचएमएससी क्रिप्टोग्राफ़िक एल्गोरिदम और MD5, SHA1, और SHA-2 फ़ैमिली के हैश फ़ंक्शन लागू होने चाहिए. इससे, Android Keystore सिस्टम के काम करने वाले एल्गोरिदम को सही तरीके से काम करने में मदद मिलती है. यह एल्गोरिदम, कोर और उसके बाद के लेवल पर चलने वाले कोड से सुरक्षित तरीके से अलग होता है. सुरक्षित आइसोलेशन की सुविधा, उन सभी संभावित तरीकों को ब्लॉक करनी चाहिए जिनकी मदद से कर्नेल या यूज़रस्पेस कोड, डीएमए के साथ-साथ आइसोलेट किए गए एनवायरमेंट की इंटरनल स्टेटस को ऐक्सेस कर सकता है. अपस्ट्रीम Android Open Source Project (AOSP), Trusty को लागू करके इस ज़रूरी शर्त को पूरा करता है. हालांकि, ARM TrustZone पर आधारित कोई दूसरा समाधान या तीसरे पक्ष की समीक्षा के बाद, हाइपरवाइजर पर आधारित सही आइसोलेशन को सुरक्षित तरीके से लागू करना, इसके विकल्प हैं.
• [9.11/T-0-3] लॉक स्क्रीन की पुष्टि, अलग से चलाए जाने वाले प्रोग्राम में करनी चाहिए. पुष्टि होने के बाद ही, पुष्टि करने के लिए इस्तेमाल की जाने वाली कुंजियों का इस्तेमाल किया जा सकता है. लॉक स्क्रीन के क्रेडेंशियल को इस तरह से सेव करना ज़रूरी है कि सिर्फ़ अलग-अलग इकोसिस्टम में काम करने वाले प्रोग्राम के लिए, लॉक स्क्रीन की पुष्टि की जा सके. अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट, Gatekeeper Hardware Abstraction Layer (HAL) और Trusty उपलब्ध कराता है. इनका इस्तेमाल, इस ज़रूरी शर्त को पूरा करने के लिए किया जा सकता है.
• [9.11/T-0-4] यह ज़रूरी है कि कुंजी की पुष्टि करने की सुविधा काम करे. इसमें, पुष्टि करने के लिए इस्तेमाल होने वाली साइनिंग कुंजी को सुरक्षित हार्डवेयर से सुरक्षित किया गया हो और साइनिंग की प्रोसेस को सुरक्षित हार्डवेयर में किया गया हो. पुष्टि करने के लिए इस्तेमाल होने वाली साइनिंग पासकोड को ज़रूर ज़्यादा से ज़्यादा डिवाइसों के साथ शेयर किया जाना चाहिए. इससे, इन पासकोड का इस्तेमाल डिवाइस आइडेंटिफ़ायर के तौर पर नहीं किया जा सकेगा. इस शर्त को पूरा करने का एक तरीका यह है कि जब तक किसी SKU की कम से कम 1,00,000 यूनिट का प्रॉडक्शन न हो जाए, तब तक एक ही पुष्टि करने वाली कुंजी शेयर की जाए. अगर किसी SKU की 1,00,000 से ज़्यादा यूनिट बनाई जाती हैं, तो हर 1,00,000 यूनिट के लिए, अलग-अलग कुंजी का इस्तेमाल किया जा सकता है.
• [9/T-0-1] ‘android.hardware.security.model.compatible’ सुविधा का एलान करना ज़रूरी है.

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

अगर टीवी डिवाइस पर सुरक्षित लॉक स्क्रीन की सुविधा काम करती है, तो:

• [9.11/T-1-1] डिवाइस को अनलॉक से लॉक होने में लगने वाले समय के लिए, उपयोगकर्ता को स्लीप मोड का टाइम आउट चुनने की अनुमति होनी चाहिए. यह टाइम आउट 15 सेकंड या उससे कम होना चाहिए.

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

• [9.5/T-2-1] डिवाइस पर प्रतिबंधित प्रोफ़ाइलों का इस्तेमाल किया जा सकता हो. इस सुविधा की मदद से, डिवाइस के मालिक अतिरिक्त उपयोगकर्ताओं और उनके ऐक्सेस को मैनेज कर सकते हैं. पाबंदी वाली प्रोफ़ाइलों की मदद से, डिवाइस के मालिक, दूसरे उपयोगकर्ताओं के लिए अलग-अलग एनवायरमेंट तुरंत सेट अप कर सकते हैं. साथ ही, उन एनवायरमेंट में उपलब्ध ऐप्लिकेशन पर ज़्यादा सटीक पाबंदियां भी लगा सकते हैं.

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

• [9.5/T-3-1] यह ज़रूरी है कि यह ऐप्लिकेशन, पाबंदी वाली प्रोफ़ाइलों के साथ काम न करे. हालांकि, यह AOSP के कंट्रोल के साथ काम करना चाहिए, ताकि अन्य उपयोगकर्ताओं को वॉइस कॉल और एसएमएस ऐक्सेस करने की अनुमति दी या बंद की जा सके.

अगर टेलिविज़न डिवाइस के लागू होने की जानकारी में android.hardware.microphone का एलान किया जाता है, तो:

• [9.8.2/T-4-1] जब कोई ऐप्लिकेशन माइक्रोफ़ोन से ऑडियो डेटा ऐक्सेस कर रहा हो, तो माइक्रोफ़ोन इंडिकेटर दिखाना ज़रूरी है.हालांकि, जब माइक्रोफ़ोन को सिर्फ़ HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService या सीडीडी आइडेंटिफ़ायर C-3-X वाली अनुमतियों वाले ऐप्लिकेशन ऐक्सेस करते हैं, तब ऐसा नहीं करना चाहिए.
• [9.8.2/T-4-2] सिस्टम के उन ऐप्लिकेशन के लिए माइक्रोफ़ोन इंडिकेटर को नहीं छिपाना चाहिए जिनमें यूज़र इंटरफ़ेस दिखते हैं या उपयोगकर्ता सीधे तौर पर इंटरैक्ट करते हैं.

अगर टेलिविज़न डिवाइस पर android.hardware.camera.any लागू किया जाता है, तो:

• [9.8.2/T-5-1] जब कोई ऐप्लिकेशन कैमरे का लाइव डेटा ऐक्सेस कर रहा हो, तो कैमरा इंडिकेटर दिखाना ज़रूरी है.हालांकि, जब कैमरे को सिर्फ़ उन ऐप्लिकेशन के ज़रिए ऐक्सेस किया जा रहा हो जिनके पास सीडीडी आइडेंटिफ़ायर [C-3-X] वाली अनुमतियां हैं, तो कैमरा इंडिकेटर नहीं दिखाना चाहिए.
• [9.8.2/T-5-2] सिस्टम ऐप्लिकेशन के लिए, कैमरे के इंडिकेटर को नहीं छिपाना चाहिए. ऐसा उन ऐप्लिकेशन के लिए करना ज़रूरी है जिनमें उपयोगकर्ता इंटरफ़ेस दिखते हैं या उपयोगकर्ता सीधे तौर पर इंटरैक्ट करते हैं.

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

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

• Perfetto
  • [6.1/T-0-1] शेल उपयोगकर्ता को /system/bin/perfetto बाइनरी दिखानी चाहिए, जो cmdline के साथ काम करती हो और perfetto दस्तावेज़ के मुताबिक हो.
  • [6.1/T-0-2] perfetto दस्तावेज़ में बताए गए स्कीमा के मुताबिक, protobuf कॉन्फ़िगरेशन को इनपुट के तौर पर स्वीकार करना ज़रूरी है.
  • [6.1/T-0-3] perfetto दस्तावेज़ में बताए गए स्कीमा के मुताबिक, protobuf ट्रैक को आउटपुट के तौर पर लिखने के लिए, यह ज़रूरी है कि perfetto बाइनरी का इस्तेमाल किया जाए.
  • [6.1/T-0-4] perfetto दस्तावेज़ में बताए गए कम से कम डेटा सोर्स, perfetto बाइनरी के ज़रिए उपलब्ध कराने होंगे.

2.4. स्मार्टवॉच से जुड़ी ज़रूरी शर्तें

Android Watch डिवाइस से, ऐसे Android डिवाइस का मतलब है जिसे पहना जा सकता है. जैसे, कलाई पर पहना जाने वाला स्मार्टवॉच.

Android डिवाइस को स्मार्टवॉच के तौर पर तब ही माना जाता है, जब वह इन सभी शर्तों को पूरा करता हो:

• स्क्रीन का डायगनल 1.1 से 2.5 इंच के बीच होना चाहिए.
• शरीर पर पहने जाने के लिए डिवाइस में कोई सुविधा हो.

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

2.4.1. हार्डवेयर

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

• [7.1.1.1/W-0-1] डिवाइस की स्क्रीन का डायगनल साइज़ 1.1 से 2.5 इंच के बीच होना चाहिए.

• [7.2.3/W-0-1] उपयोगकर्ता के लिए होम फ़ंक्शन और UI_MODE_TYPE_WATCH में होने पर, बैक फ़ंक्शन उपलब्ध होना चाहिए.

• [7.2.4/W-0-1] टचस्क्रीन इनपुट की सुविधा होनी चाहिए.

• [7.3.1/W-SR-1] हमारा सुझाव है कि आप तीन ऐक्सिस वाला ऐक्सीलेरोमीटर शामिल करें.

अगर स्मार्टवॉच डिवाइस में GPS/GNSS रिसीवर शामिल है और android.hardware.location.gps सुविधा के फ़्लैग के ज़रिए ऐप्लिकेशन को इसकी जानकारी दी जाती है, तो:

• [7.3.3/W-1-1] जीएनएसएस से मिली जानकारी मिलने के तुरंत बाद, उसे रिपोर्ट करना ज़रूरी है. भले ही, जीपीएस/जीएनएसएस से कैलकुलेट की गई जगह की जानकारी अब तक रिपोर्ट न की गई हो.
• [7.3.3/W-1-2] GNSS स्यूडोरेंज और स्यूडोरेंज रेट की रिपोर्ट देना ज़रूरी है. ये रेट, खुले आसमान में जगह की जानकारी तय करने के बाद, स्थिर रहने या 0.2 मीटर प्रति सेकंड स्क्वेयर से कम की रफ़्तार से चलने पर, कम से कम 95% समय तक जगह की जानकारी और रफ़्तार का हिसाब लगाने के लिए 20 मीटर और 0.2 मीटर प्रति सेकंड के अंदर होती है.

अगर स्मार्टवॉच में 3-ऐक्सिस जाइरोस्कोप शामिल है, तो:

• [7.3.4/W-2-1] यह ज़रूरी है कि डिवाइस, हर सेकंड में 1,000 डिग्री तक के ओरिएंटेशन में हुए बदलावों को मेज़र कर सके.

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

• [7.4.3/W-0-1] डिवाइस में ब्लूटूथ की सुविधा होनी चाहिए.

• [7.6.1/W-0-1] ऐप्लिकेशन के निजी डेटा (जिसे "/data" पार्टीशन भी कहा जाता है) के लिए, कम से कम 1 जीबी का नॉन-वॉल्व्यूस्ट स्टोरेज होना चाहिए.

• [7.6.1/W-0-2] कम से कम 416 एमबी मेमोरी, कर्नेल और यूज़रस्पेस के लिए उपलब्ध होनी चाहिए.

• [7.8.1/W-0-1] इसमें माइक्रोफ़ोन होना ज़रूरी है.

• [7.8.2/W] में ऑडियो आउटपुट हो सकता है.

2.4.2. मल्टीमीडिया

कोई अन्य ज़रूरी शर्त नहीं.

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

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

• [3/W-0-1] इस सुविधा के बारे में ज़रूर बताएं android.hardware.type.watch.
• [3/W-0-2] uiMode = UI_MODE_TYPE_WATCH के साथ काम करना चाहिए.
• [3.2.3.1/W-0-1] यहां दिए गए ऐप्लिकेशन इंटेंट के हिसाब से तय किए गए सभी सार्वजनिक इंटेंट फ़िल्टर पैटर्न के लिए, इंटेंट हैंडलर के साथ एक या उससे ज़्यादा ऐप्लिकेशन या सेवा कॉम्पोनेंट को पहले से लोड करना ज़रूरी है.

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

• [3.8.4/W-SR-1] हमारा सुझाव है कि Assist ऐक्शन को मैनेज करने के लिए, डिवाइस पर कोई सहायक लागू करें.

android.hardware.audio.output सुविधा फ़्लैग का एलान करने वाले डिवाइस इंप्लीमेंटेशन देखें:

• [3.10/W-1-1] ऐप्लिकेशन में, तीसरे पक्ष की सुलभता सेवाओं के साथ काम करने की सुविधा होनी चाहिए.
• [3.10/W-SR-1] हमारा सुझाव है कि डिवाइस पर सुलभता सेवाओं को पहले से लोड करें. ये सेवाएं, TalkBack के ओपन सोर्स प्रोजेक्ट में बताई गई, Switch Access और TalkBack (पहले से इंस्टॉल किए गए टेक्स्ट-टू-स्पीच इंजन के साथ काम करने वाली भाषाओं के लिए) की सुलभता सेवाओं के बराबर या उनसे बेहतर होनी चाहिए.

अगर स्मार्टवॉच डिवाइस में android.hardware.audio.output सुविधा लागू की गई है, तो:

• [3.11/W-SR-1] हमारा सुझाव है कि आप डिवाइस पर उपलब्ध भाषाओं के साथ काम करने वाला TTS इंजन शामिल करें.

• [3.11/W-0-1] तीसरे पक्ष के टीटीएस इंजन को इंस्टॉल करने की सुविधा होनी चाहिए.

2.4.4. परफ़ॉर्मेंस और पावर

अगर स्मार्टवॉच डिवाइस में, डिवाइस की बैटरी मैनेजमेंट को बेहतर बनाने के लिए AOSP में शामिल सुविधाएं शामिल की गई हैं या AOSP में शामिल सुविधाओं को बढ़ाया गया है, तो:

• [8.3/W-SR-1] हमारा सुझाव है कि आप उपयोगकर्ता को उन सभी ऐप्लिकेशन को दिखाने की सुविधा दें जिन्हें ऐप्लिकेशन स्टैंडबाय और बिजली बचाने वाले डोज़ मोड से छूट मिली है.
• [8.3/W-SR-2] हमारा सुझाव है कि आप उपयोगकर्ता को बैटरी सेवर की सुविधा चालू और बंद करने का विकल्प दें.

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

• [8.4/W-0-1] हर कॉम्पोनेंट के लिए, बिजली की खपत की प्रोफ़ाइल देना ज़रूरी है. इससे हर हार्डवेयर कॉम्पोनेंट के लिए, बिजली की खपत की वैल्यू और समय के साथ कॉम्पोनेंट की वजह से बैटरी की खपत के अनुमान की जानकारी मिलती है. इस बारे में Android Open Source Project की साइट पर जानकारी दी गई है.
• [8.4/W-0-2] बिजली की खपत की सभी वैल्यू को मिलीऐंपियर घंटे (mAh) में रिपोर्ट करना ज़रूरी है.
• [8.4/W-0-3] हर प्रोसेस के यूआईडी के हिसाब से, सीपीयू की बिजली की खपत की जानकारी देना ज़रूरी है. Android ओपन सोर्स प्रोजेक्ट, uid_cputime कर्नेल मॉड्यूल लागू करने की ज़रूरी शर्तें पूरी करता है.
• [8.4/W-0-4] ऐप्लिकेशन डेवलपर को, बिजली की खपत की जानकारी adb shell dumpsys batterystats शेल कमांड के ज़रिए उपलब्ध कराना ज़रूरी है.
• अगर हार्डवेयर कॉम्पोनेंट के बिजली के इस्तेमाल को किसी ऐप्लिकेशन के लिए एट्रिब्यूट नहीं किया जा सकता, तो [8.4/W] को हार्डवेयर कॉम्पोनेंट के लिए एट्रिब्यूट किया जाना चाहिए.

2.4.5. सुरक्षा मॉडल

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

• [9/W-0-1] android.hardware.security.model.compatible सुविधा के बारे में एलान करना ज़रूरी है.

अगर Watch डिवाइस पर एक से ज़्यादा उपयोगकर्ताओं को ऐक्सेस दिया गया है और android.hardware.telephony सुविधा फ़्लैग का एलान नहीं किया गया है, तो:

• [9.5/W-1-1] डिवाइस पर प्रतिबंधित प्रोफ़ाइलों की सुविधा काम करती हो. इस सुविधा की मदद से, डिवाइस के मालिक अन्य उपयोगकर्ताओं और उनके ऐक्सेस को मैनेज कर सकते हैं. पाबंदी वाली प्रोफ़ाइलों की मदद से, डिवाइस के मालिक, दूसरे उपयोगकर्ताओं के लिए अलग-अलग एनवायरमेंट तुरंत सेट अप कर सकते हैं. साथ ही, उन एनवायरमेंट में उपलब्ध ऐप्लिकेशन पर ज़्यादा सटीक पाबंदियां भी लगा सकते हैं.

अगर Watch डिवाइस पर एक से ज़्यादा उपयोगकर्ताओं को ऐप्लिकेशन इस्तेमाल करने की अनुमति दी गई है और android.hardware.telephony सुविधा फ़्लैग का एलान किया गया है, तो:

• [9.5/W-2-1] यह ज़रूरी है कि यह ऐप्लिकेशन, पाबंदी वाली प्रोफ़ाइलों के साथ काम न करे. हालांकि, यह AOSP के कंट्रोल के साथ काम करना चाहिए, ताकि अन्य उपयोगकर्ताओं को वॉइस कॉल और एसएमएस ऐक्सेस करने की अनुमति दी या बंद की जा सके.

2.5. वाहन से जुड़ी ज़रूरी शर्तें

Android Automotive को लागू करना का मतलब है कि वाहन की हेड यूनिट, सिस्टम और/या मनोरंजक तरीके से पेश की जाने वाली सूचना (इंफ़ोटेनमेंट) की सुविधा के कुछ हिस्से या पूरे हिस्से के लिए, ऑपरेटिंग सिस्टम के तौर पर Android का इस्तेमाल कर रही हो.

Android डिवाइस को Automotive के तौर पर तब ही माना जाता है, जब वे android.hardware.type.automotive सुविधा का एलान करते हों या यहां दी गई सभी शर्तों को पूरा करते हों.

• वाहन में एम्बेड किए गए हों या वाहन में प्लग किए जा सकते हों.
• ड्राइवर की सीट की पंक्ति में मौजूद स्क्रीन को मुख्य डिसप्ले के तौर पर इस्तेमाल किया जा रहा हो.

इस सेक्शन के बाकी हिस्से में दी गई अतिरिक्त शर्तें, Android Auto के साथ काम करने वाले डिवाइसों के लिए खास तौर पर बनाई गई हैं.

2.5.1. हार्डवेयर

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

• [7.1.1.1/A-0-1] डिवाइस की स्क्रीन का डायगनल साइज़ कम से कम 6 इंच होना चाहिए.

• [7.1.1.1/A-0-2] स्क्रीन साइज़ का लेआउट कम से कम 750 dp x 480 dp होना चाहिए.

• [7.2.3/A-0-1] होम बटन की सुविधा ज़रूर होनी चाहिए. साथ ही, हो सकता है कि बैक और हाल ही के ऐप्लिकेशन बटन की सुविधा भी हो.

• [7.2.3/A-0-2] फ़ोरग्राउंड ऐप्लिकेशन को, बैक फ़ंक्शन (KEYCODE_BACK) के सामान्य और ज़्यादा देर दबाने के इवेंट, दोनों को भेजना ज़रूरी है.

• [7.3/A-0-1] GEAR_SELECTION, NIGHT_MODE, PERF_VEHICLE_SPEED, और PARKING_BRAKE_ON को लागू करना और उनकी रिपोर्ट करना ज़रूरी है.

• [7.3/A-0-2] NIGHT_MODE फ़्लैग की वैल्यू, डैशबोर्ड के दिन/रात मोड के हिसाब से होनी चाहिए. साथ ही, यह वैल्यू, ऐंबियंट लाइट सेंसर के इनपुट पर आधारित होनी चाहिए. हो सकता है कि स्क्रीन की रोशनी को अपने-आप घटाने-बढ़ाने वाला सेंसर, फ़ोटोमीटर जैसा ही हो.

• [7.3/A-0-3] दिए गए हर सेंसर के लिए, SensorAdditionalInfo के हिस्से के तौर पर, सेंसर की अतिरिक्त जानकारी वाला फ़ील्ड TYPE_SENSOR_PLACEMENT होना चाहिए.

• [7.3/A-SR1] जीपीएस/जीएनएसएस को अन्य सेंसर के साथ फ़्यूज़ करके, जगह की जानकारी का अनुमान लगाया जा सकता है. अगर जगह की जानकारी का अनुमान लगाया गया है, तो हमारा सुझाव है कि आप उससे जुड़े सेंसर टाइप और/या इस्तेमाल किए गए वाहन प्रॉपर्टी आईडी को लागू करें और उनकी रिपोर्ट दें.

• [7.3/A-0-4] LocationManager#requestLocationUpdates() के ज़रिए मांगी गई जगह की जानकारी, मैप से मैच नहीं होनी चाहिए.

• [7.3.1/A-0-4] ऐप्लिकेशन को Android के कार सेंसर कोऑर्डिनेट सिस्टम का पालन करना चाहिए.

• [7.3/A-SR-1] हमारा सुझाव है कि आप 3-ऐक्सिस एक्सलरोमीटर और 3-ऐक्सिस जाइरोस्कोप शामिल करें.

• [7.3/A-SR-2] TYPE_HEADING सेंसर को लागू करने और उसकी रिपोर्ट करने का STRONGLY_RECOMMENDED.

अगर वाहन से जुड़े डिवाइसों में OpenGL ES 3.1 का इस्तेमाल किया जा रहा है, तो:

• [7.1.4.1/A-0-1] OpenGL ES 3.1 या इसके बाद के वर्शन का एलान करना ज़रूरी है.
• [7.1.4.1/A-0-2] यह Vulkan 1.1 के साथ काम करना चाहिए.
• [7.1.4.1/A-0-3] इसमें Vulkan लोडर को शामिल करना ज़रूरी है और सभी सिंबल एक्सपोर्ट करने होंगे.

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

• [7.3.1/A-1-1] यह ज़रूरी है कि डिवाइस कम से कम 100 हर्ट्ज़ तक की फ़्रीक्वेंसी वाले इवेंट की रिपोर्ट कर सके.

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

• [7.3.1/A-SR-1] हमारा सुझाव है कि सीमित ऐक्सिस वाले एक्सलरोमीटर के लिए, कॉम्पोज़िट सेंसर लागू करें.

अगर वाहन से जुड़े डिवाइस में, तीन ऐक्सिस से कम वाला एक्सलरोमीटर शामिल है, तो:

• [7.3.1/A-1-3] TYPE_ACCELEROMETER_LIMITED_AXES सेंसर को लागू करना और उसकी रिपोर्ट करना ज़रूरी है.
• [7.3.1/A-1-4] TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED सेंसर को लागू करना और उसकी रिपोर्ट करना ज़रूरी है.

अगर वाहन से जुड़े डिवाइस में एक जियोस्कोप शामिल है, तो:

• [7.3.4/A-2-1] कम से कम 100 हर्ट्ज़ की फ़्रीक्वेंसी तक इवेंट की रिपोर्ट करनी चाहिए.
• [7.3.4/A-2-3] यह ज़रूरी है कि डिवाइस, हर सेकंड में 250 डिग्री तक के ओरिएंटेशन में होने वाले बदलावों को मेज़र कर सके.
• [7.3.4/A-SR-1] हमारा सुझाव है कि जियोस्कोप की मेज़रमेंट रेंज को +/-250dps पर कॉन्फ़िगर करें, ताकि रिज़ॉल्यूशन को ज़्यादा से ज़्यादा बढ़ाया जा सके.

अगर वाहन से जुड़े डिवाइस में 3-ऐक्सिस जाइरोस्कोप शामिल है, तो:

• [7.3.4/A-SR-2] हमारा सुझाव है कि सीमित अक्ष वाले gyroscope के लिए, कॉम्पोज़िट सेंसर लागू करें.

अगर वाहन से जुड़े डिवाइस में तीन से कम ऐक्सिस वाला गायरोस्कोप शामिल है, तो:

• [7.3.4/A-4-1] TYPE_GYROSCOPE_LIMITED_AXES सेंसर को लागू करना और उसकी रिपोर्ट करना ज़रूरी है.
• [7.3.4/A-4-2] TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED सेंसर को लागू करना और उसकी रिपोर्ट करना ज़रूरी है.

अगर वाहन में इस्तेमाल होने वाले डिवाइस में जीपीएस/जीएनएसएस रिसीवर शामिल है, लेकिन सेल्युलर नेटवर्क पर आधारित डेटा कनेक्टिविटी शामिल नहीं है, तो:

• [7.3.3/A-3-1] जीपीएस/जीएनएसएस रिसीवर के चालू होने पर या चार दिन से ज़्यादा समय के बाद, जगह की जानकारी 60 सेकंड के अंदर मिलनी चाहिए.
• [7.3.3/A-3-2] जगह की जानकारी के लिए किए गए सभी अनुरोधों के लिए, 7.3.3/C-1-2 और 7.3.3/C-1-6 में बताए गए, समस्या को ठीक करने में लगने वाले समय की शर्तें पूरी करनी ज़रूरी हैं.जैसे, ऐसे अनुरोध जो पहली बार या चार दिन से ज़्यादा समय बाद किए गए हों. 7.3.3/C-1-2 की ज़रूरी शर्तें, आम तौर पर उन वाहनों में पूरी की जाती हैं जिनमें मोबाइल नेटवर्क पर आधारित डेटा कनेक्टिविटी नहीं होती. इसके लिए, रिसीवर पर कैलकुलेट किए गए जीएनएसएस ऑर्बिट के अनुमान का इस्तेमाल किया जाता है. इसके अलावा, वाहन की पिछली लोकेशन का इस्तेमाल करके, कम से कम 60 सेकंड तक डेड रेकनिंग की सुविधा का इस्तेमाल किया जाता है. साथ ही, 7.3.3/C-1-3 की शर्तों के मुताबिक, जगह की सटीक जानकारी भी दी जाती है. इसके अलावा, दोनों का इस्तेमाल भी किया जा सकता है.

अगर वाहन से जुड़े डिवाइस में TYPE_HEADING सेंसर शामिल है, तो:

• [7.3.4/A-4-3] यह ज़रूरी है कि यह कम से कम 1 हर्ट्ज़ तक की फ़्रीक्वेंसी वाले इवेंट की रिपोर्ट कर सके.
• [7.3.4/A-SR-3] कम से कम 10 हर्ट्ज़ की फ़्रीक्वेंसी तक के इवेंट की रिपोर्ट करने का STRONGLY_RECOMMENDED.
• यह सही उत्तर दिशा के हिसाब से होना चाहिए.
• यह सुविधा, गाड़ी के रुकने पर भी उपलब्ध होनी चाहिए.
• इसका रिज़ॉल्यूशन कम से कम एक डिग्री होना चाहिए.

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

• [7.4.3/A-0-1] डिवाइस में ब्लूटूथ की सुविधा होनी चाहिए. साथ ही, डिवाइस में ब्लूटूथ LE की सुविधा होनी चाहिए.
• [7.4.3/A-0-2] Android Automotive के लागू होने के लिए, इन ब्लूटूथ प्रोफ़ाइलों के साथ काम करना ज़रूरी है:
  • Hands-Free Profile (एचएफ़पी) की मदद से फ़ोन कॉल करना.
  • ऑडियो डिस्ट्रिब्यूशन प्रोफ़ाइल (A2DP) पर मीडिया चलाना.
  • रिमोट कंट्रोल प्रोफ़ाइल (एवीआरसीपी) की मदद से, मीडिया प्लेबैक को कंट्रोल करना.
  • फ़ोन बुक ऐक्सेस करने वाली प्रोफ़ाइल (पीबीएपी) का इस्तेमाल करके संपर्क शेयर करना.

• [7.4.3/A-SR-1] मैसेज ऐक्सेस प्रोफ़ाइल (एमएपी) के साथ काम करने का सुझाव दिया जाता है.

• [7.4.5/A] इसमें मोबाइल नेटवर्क पर आधारित डेटा कनेक्टिविटी की सुविधा शामिल होनी चाहिए.

• [7.4.5/A] सिस्टम एपीआई के NetworkCapabilities#NET_CAPABILITY_OEM_PAID कॉन्स्टेंट का इस्तेमाल उन नेटवर्क के लिए किया जा सकता है जो सिस्टम ऐप्लिकेशन के लिए उपलब्ध होने चाहिए.

बाहरी व्यू कैमरा, ऐसा कैमरा होता है जो डिवाइस के बाहर की चीज़ों की इमेज लेता है. जैसे, पीछे की तरफ़ दिखने वाली चीज़ों की इमेज लेने वाला कैमरा.

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

• इसमें एक या उससे ज़्यादा बाहरी व्यू कैमरे होने चाहिए.

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

• [7.5/A-1-1] बाहरी कैमरों को Android Camera API के ज़रिए ऐक्सेस नहीं किया जा सकता. ऐसा तब तक नहीं किया जा सकता, जब तक वे कैमरे मुख्य ज़रूरी शर्तों के मुताबिक न हों.

• [7.5/A-SR-1] हमारा सुझाव है कि कैमरे की झलक को घुमाएं या तिरछा न करें.

• [7.5/A-SR-2] हमारा सुझाव है कि इमेज का रिज़ॉल्यूशन कम से कम 1.3 मेगापिक्सल हो.

• इसमें फ़िक्स्ड-फ़ोकस या ईडीओएफ़ (एक्सटेंडेड डेप्थ ऑफ़ फ़ील्ड) हार्डवेयर होना चाहिए.

• कैमरा ड्राइवर में, हार्डवेयर ऑटो-फ़ोकस या सॉफ़्टवेयर ऑटो-फ़ोकस की सुविधा हो सकती है.

अगर वाहन में एक या उससे ज़्यादा एक्सटीरियर व्यू कैमरे लगाए गए हैं और एक्सटीरियर व्यू सिस्टम (ईवीएस) सेवा लोड की गई है, तो ऐसे कैमरे के लिए:

• [7.5/A-2-1] कैमरे की झलक को घुमाया या हॉरिज़ॉन्टल तौर पर उलटा नहीं दिखाया जाना चाहिए.

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

• इसमें एक या उससे ज़्यादा ऐसे कैमरे शामिल हो सकते हैं जो तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध हैं.

अगर वाहन में कम से कम एक कैमरा है और उसे तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराया गया है, तो:

• [7.5/A-3-1] फ़ीचर फ़्लैग की जानकारी देना ज़रूरी है android.hardware.camera.any.
• [7.5/A-3-2] कैमरे को सिस्टम कैमरा के तौर पर एलान नहीं किया जाना चाहिए.
• सेक्शन 7.5.3 में बताए गए बाहरी कैमरों के साथ काम कर सकता है.
• इसमें सेक्शन 7.5.1 में बताई गई, पीछे की ओर वाले कैमरों के लिए उपलब्ध सुविधाएं (जैसे, ऑटो-फ़ोकस वगैरह) शामिल हो सकती हैं.

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

• [7.6.1/A-0-1] ऐप्लिकेशन के निजी डेटा (जिसे "/data" पार्टीशन भी कहा जाता है) के लिए, कम से कम 4 जीबी का नॉन-वॉल्व्यूलेट स्टोरेज होना चाहिए.

• [7.6.1/A] फ़्लैश स्टोरेज पर बेहतर परफ़ॉर्मेंस और लंबी लाइफ़ देने के लिए, डेटा पार्टीशन को फ़ॉर्मैट करना चाहिए. उदाहरण के लिए, f2fs फ़ाइल-सिस्टम का इस्तेमाल करना.

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

• [7.6.1/A-SR-1] हमारा सुझाव है कि बाहरी स्टोरेज पर किए जाने वाले ऑपरेशन के लिए, I/O ओवरहेड को कम करें. उदाहरण के लिए, SDCardFS का इस्तेमाल करके.

अगर वाहन से जुड़े डिवाइसों पर 64-बिट प्रोसेसिंग की सुविधा है, तो:

• [7.6.1/A-2-1] अगर इनमें से किसी भी डेंसिटी का इस्तेमाल किया जाता है, तो कर्नेल और यूज़रस्पेस के लिए कम से कम 816 एमबी मेमोरी उपलब्ध होनी चाहिए:

  • छोटी/सामान्य स्क्रीन पर 280 डीपीआई या उससे कम
  • बहुत बड़ी स्क्रीन पर ldpi या उससे कम
  • बड़ी स्क्रीन पर mdpi या उससे कम

• [7.6.1/A-2-2] अगर इनमें से किसी भी डेंसिटी का इस्तेमाल किया जाता है, तो कर्नेल और यूज़रस्पेस के लिए उपलब्ध मेमोरी कम से कम 944 एमबी होनी चाहिए:

  • छोटी/सामान्य स्क्रीन पर xhdpi या उससे ज़्यादा
  • बड़ी स्क्रीन पर hdpi या उससे ज़्यादा
  • ज़्यादा बड़ी स्क्रीन पर mdpi या उससे ज़्यादा

• [7.6.1/A-2-3] अगर इनमें से किसी भी डेंसिटी का इस्तेमाल किया जाता है, तो कर्नेल और यूज़रस्पेस के लिए उपलब्ध मेमोरी कम से कम 1280 एमबी होनी चाहिए:

  • छोटी/सामान्य स्क्रीन पर 400 डीपीआई या उससे ज़्यादा
  • बड़ी स्क्रीन पर xhdpi या उससे ज़्यादा
  • बहुत बड़ी स्क्रीन पर tvdpi या उससे ज़्यादा

• [7.6.1/A-2-4] अगर इनमें से किसी भी डेंसिटी का इस्तेमाल किया जाता है, तो kernel और userspace के लिए उपलब्ध मेमोरी कम से कम 1824 एमबी होनी चाहिए:

  • छोटी/सामान्य स्क्रीन पर 560 डीपीआई या उससे ज़्यादा
  • बड़ी स्क्रीन पर 400 डीपीआई या उससे ज़्यादा
  • बहुत बड़ी स्क्रीन पर xhdpi या उससे ज़्यादा

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

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

• [7.7.1/A] इसमें पेरिफ़ेरल मोड के साथ काम करने वाला यूएसबी पोर्ट शामिल होना चाहिए.

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

• [7.8.1/A-0-1] इसमें माइक्रोफ़ोन होना ज़रूरी है.

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

• [7.8.2/A-0-1] इसमें ऑडियो आउटपुट होना चाहिए और इसकी जानकारी ज़ाहिर की जानी चाहिए android.hardware.audio.output.

2.5.2. मल्टीमीडिया

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

• [5.1/A-0-1] MPEG-4 AAC प्रोफ़ाइल (AAC LC)
• [5.1/A-0-2] MPEG-4 HE AAC Profile (AAC+)
• [5.1/A-0-3] AAC ELD (बेहतर कम देरी वाला AAC)

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

• [5.2/A-0-1] H.264 AVC
• [5.2/A-0-2] VP8

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

• [5.3/A-0-1] H.264 AVC
• [5.3/A-0-2] MPEG-4 SP
• [5.3/A-0-3] VP8
• [5.3/A-0-4] VP9

हमारा सुझाव है कि वाहन से जुड़े डिवाइसों पर, वीडियो को डिकोड करने के लिए इन फ़ॉर्मैट का इस्तेमाल करें:

• [5.3/A-SR-1] H.265 HEVC

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

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

• [3/A-0-1] इस सुविधा के बारे में ज़रूर बताएं android.hardware.type.automotive.

• [3/A-0-2] uiMode = UI_MODE_TYPE_CAR के साथ काम करना चाहिए.

• [3/A-0-3] android.car.* नेमस्पेस में मौजूद सभी सार्वजनिक एपीआई के साथ काम करना चाहिए.

अगर वाहन के लिए बने डिवाइस में, android.car.VehiclePropertyIds के साथ android.car.CarPropertyManager का इस्तेमाल करके मालिकाना एपीआई उपलब्ध कराया जाता है, तो:

• [3/A-1-1] सिस्टम ऐप्लिकेशन को इन प्रॉपर्टी के इस्तेमाल के लिए खास सुविधाएं नहीं देनी चाहिए. इसके अलावा, तीसरे पक्ष के ऐप्लिकेशन को इन प्रॉपर्टी का इस्तेमाल करने से नहीं रोकना चाहिए.
• [3/A-1-2] SDK में पहले से मौजूद वाहन की ऐसी प्रॉपर्टी का डुप्लीकेट नहीं बनाया जाना चाहिए.

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

• [3.2.1/A-0-1] वाहन संबंधित अनुमति के रेफ़रंस पेज में बताए गए सभी अनुमतियों के लिए, अनुमतियों के सभी कॉन्स्टेंट काम करने चाहिए और उन्हें लागू करना चाहिए.

• [3.2.3.1/A-0-1] यहां दिए गए ऐप्लिकेशन इंटेंट के हिसाब से तय किए गए सभी सार्वजनिक इंटेंट फ़िल्टर पैटर्न के लिए, इंटेंट हैंडलर के साथ एक या उससे ज़्यादा ऐप्लिकेशन या सेवा कॉम्पोनेंट को पहले से लोड करना ज़रूरी है.

• [3.4.1/A-0-1] android.webkit.Webview एपीआई को पूरी तरह से लागू करना ज़रूरी है.

• [3.8.3/A-0-1] तीसरे पक्ष के ऐप्लिकेशन के अनुरोध करने पर, Notification.CarExtender एपीआई का इस्तेमाल करने वाली सूचनाएं दिखानी ज़रूरी हैं.

• [3.8.4/A-SR-1] हमारा सुझाव है कि Assist ऐक्शन को मैनेज करने के लिए, डिवाइस पर कोई सहायक लागू करें.

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

• [3.8.4/A-1-1] उपयोगकर्ता के चुने गए सहायता ऐप्लिकेशन को लॉन्च करने के लिए, डिवाइस पर बने पुश-टू-टॉक बटन को हल्का-सा दबाकर, इंटरैक्शन करना ज़रूरी है. दूसरे शब्दों में, VoiceInteractionService को लागू करने वाले ऐप्लिकेशन को लॉन्च करने के लिए, डिवाइस पर बने पुश-टू-टॉक बटन को हल्का-सा दबाकर, इंटरैक्शन करना ज़रूरी है.

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

• [3.8.3.1/A-0-1] Notifications on Automotive OS SDK टूल के दस्तावेज़ में बताए गए तरीके से, संसाधनों को सही तरीके से रेंडर करना ज़रूरी है.
• [3.8.3.1/A-0-2] सूचना से जुड़ी कार्रवाइयों के लिए, Notification.Builder.addAction() के ज़रिए दी गई कार्रवाइयों के बजाय, 'चलाएं' और 'म्यूट करें' को दिखाना ज़रूरी है
• [3.8.3.1/A] को बेहतर मैनेजमेंट टास्क के इस्तेमाल पर पाबंदी लगानी चाहिए. जैसे, हर सूचना चैनल के लिए कंट्रोल. कंट्रोल को कम करने के लिए, हर ऐप्लिकेशन के लिए यूज़र इंटरफ़ेस (यूआई) के फ़ायदे का इस्तेमाल किया जा सकता है.

अगर वाहन से जुड़े डिवाइसों के लागू होने पर, उपयोगकर्ता HAL प्रॉपर्टी काम करती हैं, तो:

• [3.9.3/A-1-1] सभी उपयोगकर्ता लाइफ़साइकल प्रॉपर्टी को लागू करना ज़रूरी है
  • INITIAL_USER_INFO, SWITCH_USER, CREATE_USER, REMOVE_USER.

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

• [3.14/A-0-1] इसमें यूज़र इंटरफ़ेस (यूआई) फ़्रेमवर्क होना चाहिए, ताकि मीडिया एपीआई का इस्तेमाल करने वाले तीसरे पक्ष के ऐप्लिकेशन काम कर सकें. इस बारे में 3.14 सेक्शन में बताया गया है.
• [3.14/A-0-2] यह ज़रूरी है कि ऐप्लिकेशन, ड्राइविंग के दौरान उपयोगकर्ता को मीडिया ऐप्लिकेशन के साथ सुरक्षित तरीके से इंटरैक्ट करने की अनुमति दे.
• [3.14/A-0-3] ऐप्लिकेशन में, CAR_INTENT_ACTION_MEDIA_TEMPLATE के साथ काम करने वाले, CAR_EXTRA_MEDIA_PACKAGE के साथ काम करने वाले, और इंप्लिसिट इंटेंट ऐक्शन के लिए ज़रूरी है.
• [3.14/A-0-4] किसी मीडिया ऐप्लिकेशन की प्राथमिकता गतिविधि पर नेविगेट करने के लिए, ऐप्लिकेशन में एक सुविधा उपलब्ध कराई जानी चाहिए. हालांकि, यह सुविधा सिर्फ़ तब चालू की जानी चाहिए, जब कार के यूज़र एक्सपीरियंस से जुड़ी पाबंदियां लागू न हों.
• [3.14/A-0-5] मीडिया ऐप्लिकेशन से सेट किए गए गड़बड़ी के मैसेज दिखाने चाहिए. साथ ही, इसमें वैकल्पिक अतिरिक्त सुविधाओं ERROR_RESOLUTION_ACTION_LABEL और ERROR_RESOLUTION_ACTION_INTENT का इस्तेमाल किया जा सकता है.
• [3.14/A-0-6] खोजने की सुविधा वाले ऐप्लिकेशन के लिए, इन-ऐप्लिकेशन सर्च अवर्डेंस की सुविधा ज़रूर होनी चाहिए.
• [3.14/A-0-7] MediaBrowser के लेआउट को दिखाते समय, CONTENT_STYLE_BROWSABLE_HINT और CONTENT_STYLE_PLAYABLE_HINT की परिभाषाओं का पालन करना ज़रूरी है.

अगर वाहन से जुड़े डिवाइसों में डिफ़ॉल्ट लॉन्चर ऐप्लिकेशन शामिल है, तो:

• [3.14/A-1-1] इसमें मीडिया सेवाएं शामिल होनी चाहिए और उन्हें CAR_INTENT_ACTION_MEDIA_TEMPLATE के इंटेंट से खोलना चाहिए.

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

• [3.8/A] immersive documentation में बताए गए तरीके से, फ़ुल स्क्रीन मोड में जाने के लिए किए गए ऐप्लिकेशन के अनुरोधों पर पाबंदी लगा सकता है.
• [3.8/A] ऐप्लिकेशन में, स्टेटस बार और नेविगेशन बार को हमेशा दिखने की अनुमति दी जा सकती है.
• [3.8/A] सिस्टम यूज़र इंटरफ़ेस (यूआई) एलिमेंट के पीछे के रंगों को बदलने के लिए, ऐप्लिकेशन के अनुरोधों पर पाबंदी लगाई जा सकती है. इससे यह पक्का किया जा सकेगा कि वे एलिमेंट हर समय साफ़ तौर पर दिखें.

2.5.4. परफ़ॉर्मेंस और पावर

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

• [8.2/A-0-1] हर प्रोसेस के यूआईडी के हिसाब से, नॉन-वोलिटाइल स्टोरेज में पढ़े और लिखे गए बाइट की संख्या की जानकारी देना ज़रूरी है, ताकि डेवलपर को System API android.car.storagemonitoring.CarStorageMonitoringManager के ज़रिए आंकड़े उपलब्ध कराए जा सकें. Android ओपन सोर्स प्रोजेक्ट, uid_sys_stats कर्नेल मॉड्यूल की मदद से ज़रूरी शर्तें पूरी करता है.
• [8.3/A-1-3] यह गैरेज मोड के साथ काम करना चाहिए.
• [8.3/A] हर ड्राइव के बाद, कम से कम 15 मिनट तक गैराज मोड में होना चाहिए. ऐसा तब तक करना चाहिए, जब तक:
  • बैटरी खत्म हो गई है.
  • कोई भी ऐसा जॉब शेड्यूल नहीं किया गया है जो काम नहीं कर रहा है.
  • ड्राइवर, गैराज मोड से बाहर निकलता है.
• [8.4/A-0-1] हर कॉम्पोनेंट के लिए, बिजली की खपत की प्रोफ़ाइल देना ज़रूरी है. इससे हर हार्डवेयर कॉम्पोनेंट के लिए, बिजली की खपत की वैल्यू और समय के साथ कॉम्पोनेंट की वजह से बैटरी की खपत के अनुमान की जानकारी मिलती है. इस बारे में Android Open Source Project की साइट पर जानकारी दी गई है.
• [8.4/A-0-2] बिजली की खपत की सभी वैल्यू को मिलीऐंपियर घंटे (mAh) में रिपोर्ट करना ज़रूरी है.
• [8.4/A-0-3] हर प्रोसेस के यूआईडी के हिसाब से, सीपीयू की बिजली की खपत की जानकारी देना ज़रूरी है. Android ओपन सोर्स प्रोजेक्ट, uid_cputime कर्नेल मॉड्यूल लागू करने की ज़रूरी शर्तें पूरी करता है.
• [8.4/A] अगर किसी ऐप्लिकेशन के लिए, हार्डवेयर कॉम्पोनेंट के पावर इस्तेमाल को एट्रिब्यूट नहीं किया जा सकता, तो उसे हार्डवेयर कॉम्पोनेंट को एट्रिब्यूट किया जाना चाहिए.
• [8.4/A-0-4] ऐप्लिकेशन डेवलपर को, बिजली की खपत की जानकारी adb shell dumpsys batterystats शेल कमांड के ज़रिए उपलब्ध कराना ज़रूरी है.

2.5.5. सुरक्षा मॉडल

अगर वाहन से जुड़े डिवाइसों के लागू होने की सुविधा, कई उपयोगकर्ताओं के लिए काम करती है, तो:

• [9.5/A-1-1] उपयोगकर्ताओं को डिवाइस की प्रोवाइज़िंग के अलावा, हेडलेस सिस्टम उपयोगकर्ता के साथ इंटरैक्ट करने या उसमें स्विच करने की अनुमति नहीं देनी चाहिए.
• [9.5/A-1-2] BOOT_COMPLETED से पहले, सेकंडरी उपयोगकर्ता पर स्विच करना ज़रूरी है.
• [9.5/A-1-3] डिवाइस पर उपयोगकर्ताओं की तय सीमा पूरी होने के बाद भी, मेहमान उपयोगकर्ता बनाने की सुविधा होनी चाहिए.

अगर वाहन से जुड़े डिवाइस के लागू होने की जानकारी में android.hardware.camera.any का एलान किया जाता है, तो:

• [9.8.2/A-2-1] जब कोई ऐप्लिकेशन कैमरे का लाइव डेटा ऐक्सेस कर रहा हो, तो कैमरा इंडिकेटर दिखाना ज़रूरी है. हालांकि, जब कैमरे को सिर्फ़ ऐसे ऐप्लिकेशन ऐक्सेस कर रहे हों जिनके पास सीडीडी आइडेंटिफ़ायर [C-3-X] के साथ सेक्शन 9.1 अनुमतियां में बताई गई भूमिकाएं हों, तब कैमरा इंडिकेटर नहीं दिखाना चाहिए.
• [9.8.2/A-2-2] सिस्टम के उन ऐप्लिकेशन के लिए कैमरे के इंडिकेटर को नहीं छिपाना चाहिए जिनमें यूज़र इंटरफ़ेस दिखते हैं या जिनमें उपयोगकर्ता सीधे तौर पर इंटरैक्ट करता है.

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

• [9.11/A-0-1] अलग से एक्ज़ीक्यूशन एनवायरमेंट का इस्तेमाल करके, पासकोड लागू करने के तरीके का बैक अप लेना ज़रूरी है.
• [9.11/A-0-2] इसमें आरएसए, एईएस, ईसीडीएसए, और एचएमएससी क्रिप्टोग्राफ़िक एल्गोरिदम और MD5, SHA1, और SHA-2 फ़ैमिली के हैश फ़ंक्शन लागू होने चाहिए. इससे, Android Keystore सिस्टम के काम करने वाले एल्गोरिदम को सही तरीके से काम करने में मदद मिलती है. यह एल्गोरिदम, कोर और उसके बाद के लेवल पर चलने वाले कोड से सुरक्षित तरीके से अलग होता है. सुरक्षित आइसोलेशन की सुविधा, उन सभी संभावित तरीकों को ब्लॉक करनी चाहिए जिनकी मदद से कर्नेल या यूज़रस्पेस कोड, डीएमए के साथ-साथ आइसोलेट किए गए एनवायरमेंट की इंटरनल स्टेटस को ऐक्सेस कर सकता है. अपस्ट्रीम Android Open Source Project (AOSP), Trusty को लागू करके इस ज़रूरी शर्त को पूरा करता है. हालांकि, ARM TrustZone पर आधारित कोई दूसरा समाधान या तीसरे पक्ष की समीक्षा के बाद, हाइपरवाइजर पर आधारित सही आइसोलेशन को सुरक्षित तरीके से लागू करना, इसके विकल्प हैं.
• [9.11/A-0-3] लॉक स्क्रीन पर पुष्टि करने की प्रोसेस, अलग से चलाए जाने वाले प्रोग्राम में पूरी की जानी चाहिए. पुष्टि होने के बाद ही, पुष्टि करने के लिए इस्तेमाल की जाने वाली कुंजियों का इस्तेमाल किया जा सकता है. लॉक स्क्रीन के क्रेडेंशियल को इस तरह से सेव करना ज़रूरी है कि सिर्फ़ अलग-अलग इकोसिस्टम में काम करने वाले प्रोग्राम के लिए, लॉक स्क्रीन की पुष्टि की जा सके. अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट, Gatekeeper Hardware Abstraction Layer (HAL) और Trusty उपलब्ध कराता है. इनका इस्तेमाल, इस ज़रूरी शर्त को पूरा करने के लिए किया जा सकता है.
• [9.11/A-0-4] यह ज़रूरी है कि कुंजी की पुष्टि करने की सुविधा काम करे. इसमें, पुष्टि करने के लिए इस्तेमाल होने वाली साइनिंग कुंजी को सुरक्षित हार्डवेयर से सुरक्षित किया गया हो और साइनिंग की प्रोसेस, सुरक्षित हार्डवेयर में की गई हो. पुष्टि करने के लिए इस्तेमाल होने वाली साइनिंग पासकोड को ज़रूर ज़्यादा से ज़्यादा डिवाइसों के साथ शेयर किया जाना चाहिए. इससे, इन पासकोड का इस्तेमाल डिवाइस आइडेंटिफ़ायर के तौर पर नहीं किया जा सकेगा. इस शर्त को पूरा करने का एक तरीका यह है कि जब तक किसी SKU की कम से कम 1,00,000 यूनिट का प्रॉडक्शन न हो जाए, तब तक एक ही पुष्टि करने वाली कुंजी शेयर की जाए. अगर किसी SKU की 1,00,000 से ज़्यादा यूनिट बनाई जाती हैं, तो हर 1,00,000 यूनिट के लिए, अलग-अलग कुंजी का इस्तेमाल किया जा सकता है.
• [9/A-0-1] ‘android.hardware.security.model.compatible’ सुविधा का एलान करना ज़रूरी है.

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

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

• [9.14/A-0-1] Android फ़्रेमवर्क के वाहन के सबसिस्टम से मैसेज को कंट्रोल करना ज़रूरी है. उदाहरण के लिए, अनुमति वाले मैसेज टाइप और मैसेज के सोर्स की अनुमति देना.
• [9.14/A-0-2] Android फ़्रेमवर्क या तीसरे पक्ष के ऐप्लिकेशन से, सेवा के अस्वीकार होने से जुड़े हमलों से बचने के लिए, निगरानी करना ज़रूरी है. इससे, नुकसान पहुंचाने वाले सॉफ़्टवेयर को वाहन के नेटवर्क पर ट्रैफ़िक भेजने से रोका जा सकता है. इससे वाहन के सबसिस्टम के काम करने में रुकावट आ सकती है.

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

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

• Perfetto
  • [6.1/A-0-1] शेल उपयोगकर्ता को /system/bin/perfetto बाइनरी दिखानी चाहिए, जो cmdline के साथ काम करती हो और perfetto दस्तावेज़ के मुताबिक हो.
  • [6.1/A-0-2] perfetto दस्तावेज़ में बताए गए स्कीमा के मुताबिक, protobuf कॉन्फ़िगरेशन को इनपुट के तौर पर स्वीकार करना ज़रूरी है.
  • [6.1/A-0-3] perfetto दस्तावेज़ में बताए गए स्कीमा के मुताबिक, protobuf ट्रेस को आउटपुट के तौर पर लिखने के लिए, यह ज़रूरी है कि perfetto बाइनरी का इस्तेमाल किया जाए.
  • [6.1/A-0-4] perfetto दस्तावेज़ में बताए गए कम से कम डेटा सोर्स, perfetto बाइनरी के ज़रिए उपलब्ध कराए जाने चाहिए.

2.6. टैबलेट के लिए ज़रूरी शर्तें

Android टैबलेट डिवाइस से, ऐसे Android डिवाइस का मतलब है जो आम तौर पर इन सभी शर्तों को पूरा करता है:

• इसे दोनों हाथों से पकड़कर इस्तेमाल किया जाता है.
• इसमें क्लैमशेल या कन्वर्टिबल कॉन्फ़िगरेशन नहीं है.
• डिवाइस के साथ इस्तेमाल किए जाने वाले फ़िज़िकल कीबोर्ड, स्टैंडर्ड कनेक्शन (जैसे, यूएसबी, ब्लूटूथ) के ज़रिए कनेक्ट होते हैं.
• इसमें बैटरी जैसा पावर सोर्स हो, जिससे इसे कहीं भी ले जाया जा सके.
• स्क्रीन का डाइमेंशन 7" से ज़्यादा और 18" से कम होना चाहिए.

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

2.6.1. हार्डवेयर

जाइरोस्कोप

अगर टैबलेट डिवाइस में 3-ऐक्सिस जाइरोस्कोप शामिल है, तो:

• [7.3.4/Tab-1-1] यह ज़रूरी है कि यह हर सेकंड 1,000 डिग्री तक ओरिएंटेशन में होने वाले बदलावों को मेज़र कर सके.

ज़रूरी मेमोरी और स्टोरेज (सेक्शन 7.6.1)

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

यूएसबी पेरिफ़रल मोड (सेक्शन 7.7.1)

अगर टैबलेट डिवाइस में, यूएसबी पोर्ट के साथ-साथ, पेरिफ़रल मोड की सुविधा भी है, तो:

• [7.7.1/Tab] Android Open Accessory (AOA) API लागू किया जा सकता है.

वर्चुअल रिएलिटी मोड (सेक्शन 7.9.1)

वर्चुअल रिएलिटी की बेहतर परफ़ॉर्मेंस (सेक्शन 7.9.2)

वर्चुअल रिएलिटी की ज़रूरी शर्तें, टैबलेट पर लागू नहीं होतीं.

2.6.2. सुरक्षा मॉडल

कुंजियां और क्रेडेंशियल (सेक्शन 9.11)

सेक्शन [9.11] देखें.

अगर टैबलेट डिवाइस पर एक से ज़्यादा उपयोगकर्ताओं को अनुमति दी गई है और android.hardware.telephony सुविधा फ़्लैग का एलान नहीं किया गया है, तो:

• [9.5/T-1-1] डिवाइस पर प्रतिबंधित प्रोफ़ाइलों की सुविधा काम करती हो. इस सुविधा की मदद से, डिवाइस के मालिक अन्य उपयोगकर्ताओं और उनके ऐक्सेस को मैनेज कर सकते हैं. पाबंदी वाली प्रोफ़ाइलों की मदद से, डिवाइस के मालिक, दूसरे उपयोगकर्ताओं के लिए अलग-अलग एनवायरमेंट तुरंत सेट अप कर सकते हैं. साथ ही, उन एनवायरमेंट में उपलब्ध ऐप्लिकेशन पर ज़्यादा सटीक पाबंदियां भी लगा सकते हैं.

अगर टैबलेट डिवाइस पर एक से ज़्यादा उपयोगकर्ताओं को ऐक्सेस दिया गया है और android.hardware.telephony सुविधा फ़्लैग का एलान किया गया है, तो:

• [9.5/T-2-1] यह ज़रूरी है कि यह ऐप्लिकेशन, पाबंदी वाली प्रोफ़ाइलों के साथ काम न करे. हालांकि, यह AOSP के कंट्रोल के साथ काम करना चाहिए, ताकि अन्य उपयोगकर्ताओं को वॉइस कॉल और एसएमएस ऐक्सेस करने की अनुमति दी या बंद की जा सके.

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

• [3.2.3.1/Tab-0-1] यहां दिए गए ऐप्लिकेशन इंटेंट के हिसाब से तय किए गए सभी सार्वजनिक इंटेंट फ़िल्टर पैटर्न के लिए, इंटेंट हैंडलर के साथ एक या उससे ज़्यादा ऐप्लिकेशन या सेवा कॉम्पोनेंट को पहले से लोड करना ज़रूरी है.

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

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

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

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

• [C-0-1] Android SDK के ज़रिए एक्सपोज़ किए गए किसी भी दस्तावेज़ वाले एपीआई या अपस्ट्रीम Android सोर्स कोड में “@SystemApi” मार्कर के साथ सजाए गए किसी भी एपीआई के सभी दस्तावेज़ किए गए व्यवहारों के साथ-साथ, एपीआई को पूरी तरह से लागू करना ज़रूरी है.

• [C-0-2] TestApi एनोटेशन (@TestApi) से मार्क की गई सभी क्लास, मेथड, और उनसे जुड़े एलिमेंट के साथ काम करना चाहिए/उनका रखरखाव करना चाहिए.

• [C-0-3] मैनेज किए जा रहे किसी भी एपीआई को नहीं छोड़ना चाहिए, एपीआई इंटरफ़ेस या हस्ताक्षर में बदलाव नहीं करना चाहिए, दस्तावेज़ में बताए गए तरीके से काम नहीं करना चाहिए या कोई काम न करने वाला एपीआई शामिल नहीं करना चाहिए. हालांकि, अगर इस सुविधा के साथ काम करने की शर्तों में ऐसा करने की अनुमति दी गई है, तो ऐसा किया जा सकता है.

• [C-0-4] एपीआई को अब भी मौजूद रखना चाहिए और सही तरीके से काम करना चाहिए. भले ही, Android में एपीआई शामिल करने वाली कुछ हार्डवेयर सुविधाओं को हटा दिया गया हो. इस स्थिति के लिए ज़रूरी शर्तों के बारे में जानने के लिए, सेक्शन 7 देखें.

• [C-0-5] तीसरे पक्ष के ऐप्लिकेशन को ऐसे इंटरफ़ेस इस्तेमाल करने की अनुमति नहीं देनी चाहिए जिनमें SDK टूल नहीं है. ये इंटरफ़ेस, Java भाषा के पैकेज में मौजूद तरीकों और फ़ील्ड के तौर पर तय किए जाते हैं. ये पैकेज, AOSP के बूट क्लासपाथ में होते हैं और सार्वजनिक SDK टूल का हिस्सा नहीं होते. इसमें ऐसे एपीआई शामिल हैं जिन्हें @hide एनोटेशन से सजाया गया है, लेकिन @SystemAPI से नहीं, जैसा कि एसडीके दस्तावेज़ों में बताया गया है. साथ ही, इसमें निजी और पैकेज-निजी क्लास के सदस्य भी शामिल हैं.

• [C-0-6] यह ज़रूरी है कि हर ऐसे इंटरफ़ेस को, पाबंदी वाली उन ही सूचियों में शामिल किया जाए जिनमें AOSP में सही एपीआई लेवल की शाखा के लिए, prebuilts/runtime/appcompat/hiddenapi-flags.csv पाथ में मौजूद, 'पाबंदी' और 'पाबंदी वाली सूची' फ़्लैग की मदद से जानकारी दी गई है.

• [C-0-7] साइन किए गए कॉन्फ़िगरेशन के डाइनैमिक अपडेट मैकेनिज्म के साथ काम करना चाहिए, ताकि AOSP में मौजूद मौजूदा सार्वजनिक कुंजियों का इस्तेमाल करके, किसी भी APK में साइन किए गए कॉन्फ़िगरेशन को जोड़कर, SDK टूल के बाहर के इंटरफ़ेस को पाबंदी वाली सूची से हटाया जा सके.

  हालांकि, ये:

  • अगर कोई छिपा हुआ एपीआई मौजूद नहीं है या डिवाइस पर अलग तरीके से लागू किया गया है, तो छिपे हुए एपीआई को पाबंदी वाली सूची में डालें या उसे पाबंदी वाली सभी सूचियों से हटाएं.
  • अगर AOSP में पहले से कोई छिपा हुआ एपीआई मौजूद नहीं है, तो छिपे हुए एपीआई को पाबंदी वाली किसी भी सूची में जोड़ा जा सकता है.

3.1.1. Android एक्सटेंशन

Android, किसी खास एपीआई लेवल के मैनेज किए जा रहे एपीआई के प्लैटफ़ॉर्म को बड़ा करने की सुविधा देता है. इसके लिए, उस एपीआई लेवल के लिए एक्सटेंशन वर्शन को अपडेट किया जाता है. अगर उस एपीआई लेवल के लिए एक्सटेंशन मौजूद हैं, तो android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) एपीआई, दिए गए apiLevel का एक्सटेंशन वर्शन दिखाता है.

Android डिवाइस पर लागू करने के लिए:

• [C-0-1] ऐप्लिकेशन को, शेयर की गई लाइब्रेरी ExtShared और सेवाओं ExtServices, दोनों के AOSP वर्शन को पहले से लोड करना चाहिए. ये वर्शन, हर एपीआई लेवल के लिए तय किए गए कम से कम वर्शन से ज़्यादा या उसके बराबर होने चाहिए. उदाहरण के लिए, Android 7.0 पर काम करने वाले डिवाइसों में, एपीआई लेवल 24 के कम से कम वर्शन 1 का इस्तेमाल करना ज़रूरी है.

• [C-0-2] यह फ़ंक्शन सिर्फ़ उस एक्सटेंशन वर्शन का नंबर दिखाए जो AOSP ने तय किया है.

• [C-0-3] यह ज़रूरी है कि एक्सटेंशन के उन सभी वर्शन के लिए एपीआई काम करें जो android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) के ज़रिए दिखाए जाते हैं. साथ ही, यह भी ज़रूरी है कि एपीआई ठीक उसी तरह काम करें जिस तरह मैनेज किए जा रहे अन्य एपीआई काम करते हैं. इसके लिए, सेक्शन 3.1 में दी गई ज़रूरी शर्तों का पालन करना होगा.

3.1.2. Android लाइब्रेरी

Apache HTTP क्लाइंट के बंद होने की वजह से, डिवाइस पर लागू होने वाले ये बदलाव होंगे:

• [C-0-1] org.apache.http.legacy लाइब्रेरी को बूटक्लॉसपैथ में नहीं डालना चाहिए.
• [C-0-2] ऐप्लिकेशन के क्लासपाथ में org.apache.http.legacy लाइब्रेरी को सिर्फ़ तब जोड़ना ज़रूरी है, जब ऐप्लिकेशन इनमें से किसी एक शर्त को पूरा करता हो:
  • एपीआई लेवल 28 या इससे पहले के वर्शन को टारगेट करता हो.
  • अपने मेनिफ़ेस्ट में यह एलान करता है कि उसे लाइब्रेरी की ज़रूरत है. इसके लिए, <uses-library> के android:name एट्रिब्यूट को org.apache.http.legacy पर सेट किया जाता है.

AOSP को लागू करने से ये ज़रूरी शर्तें पूरी होती हैं.

3.2. Soft API Compatibility

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

3.2.1. अनुमतियां

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

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

Android API में, android.os.Build क्लास पर कई कॉन्स्टेंट शामिल होते हैं. इनका मकसद, मौजूदा डिवाइस के बारे में बताना होता है.

• [C-0-1] डिवाइस पर लागू करने के लिए, एक जैसी और काम की वैल्यू देने के लिए, नीचे दी गई टेबल में इन वैल्यू के फ़ॉर्मैट पर अतिरिक्त पाबंदियां शामिल हैं. डिवाइस पर लागू करने के लिए, इनका पालन करना ज़रूरी है.

पैरामीटर	जानकारी
VERSION.RELEASE	फ़िलहाल चल रहे Android सिस्टम का वर्शन, ऐसे फ़ॉर्मैट में जिसे कोई भी व्यक्ति आसानी से पढ़ सकता है. इस फ़ील्ड में, Android 13 के लिए अनुमति वाली वर्शन स्ट्रिंग में बताई गई स्ट्रिंग वैल्यू में से कोई एक वैल्यू होनी चाहिए.
VERSION.SDK	फ़िलहाल चल रहे Android सिस्टम का वर्शन, तीसरे पक्ष के ऐप्लिकेशन कोड के ऐक्सेस किए जा सकने वाले फ़ॉर्मैट में. Android 13 के लिए, इस फ़ील्ड में पूर्णांक की वैल्यू 13_INT होनी चाहिए.
VERSION.SDK_INT	फ़िलहाल चल रहे Android सिस्टम का वर्शन, तीसरे पक्ष के ऐप्लिकेशन कोड के ऐक्सेस किए जा सकने वाले फ़ॉर्मैट में. Android 13 के लिए, इस फ़ील्ड में पूर्णांक की वैल्यू 13_INT होनी चाहिए.
VERSION.INCREMENTAL	डिवाइस लागू करने वाले व्यक्ति की चुनी गई वैल्यू, जो फ़िलहाल चल रहे Android सिस्टम के खास बिल्ड को, इंसान के पढ़ने लायक फ़ॉर्मैट में दिखाती है. इस वैल्यू का इस्तेमाल, असली उपयोगकर्ताओं के लिए उपलब्ध कराए गए अलग-अलग बिल्ड के लिए दोबारा नहीं किया जाना चाहिए. इस फ़ील्ड का आम तौर पर इस्तेमाल, यह बताने के लिए किया जाता है कि बिल्ड जनरेट करने के लिए, किस बिल्ड नंबर या सोर्स-कंट्रोल बदलाव आइडेंटिफ़ायर का इस्तेमाल किया गया था. इस फ़ील्ड की वैल्यू, प्रिंट किए जा सकने वाले सात बिट वाले ASCII के तौर पर कोड की जानी चाहिए. साथ ही, यह वैल्यू रेगुलर एक्सप्रेशन “^[^ :\/~]+$” से मेल खानी चाहिए.
बोर्ड	डिवाइस लागू करने वाले व्यक्ति की चुनी गई वैल्यू, जिसमें डिवाइस के इस्तेमाल किए गए खास इंटरनल हार्डवेयर की जानकारी होती है. यह जानकारी, इंसान के पढ़ने लायक फ़ॉर्मैट में होती है. इस फ़ील्ड का इस्तेमाल, डिवाइस को पावर देने वाले बोर्ड के खास वर्शन की जानकारी देने के लिए किया जा सकता है. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है. साथ ही, यह वैल्यू रेगुलर एक्सप्रेशन “^[a-zA-Z0-9_-]+$” से मेल खानी चाहिए.
ब्रैंड	यह वैल्यू, डिवाइस से जुड़े ब्रैंड के नाम को दिखाती है. यह नाम, असली उपयोगकर्ताओं को पता होता है. यह एट्रिब्यूट, लोगों के पढ़ने लायक फ़ॉर्मैट में होना चाहिए. साथ ही, इसमें डिवाइस के मैन्युफ़ैक्चरर या उस कंपनी के ब्रैंड का नाम होना चाहिए जिसका नाम डिवाइस के लिए मार्केटिंग में इस्तेमाल किया जाता है. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है. साथ ही, यह वैल्यू रेगुलर एक्सप्रेशन “^[a-zA-Z0-9_-]+$” से मैच करनी चाहिए.
SUPPORTED_ABIS	नेटिव कोड के निर्देश सेट (सीपीयू टाइप + एबीआई कॉन्वेंशन) का नाम. सेक्शन 3.3 देखें. नेटिव एपीआई के साथ काम करना.
SUPPORTED_32_BIT_ABIS	नेटिव कोड के निर्देश सेट (सीपीयू टाइप + एबीआई कॉन्वेंशन) का नाम. सेक्शन 3.3 देखें. नेटिव एपीआई के साथ काम करना.
SUPPORTED_64_BIT_ABIS	नेटिव कोड के दूसरे निर्देश सेट (सीपीयू टाइप + एबीआई कन्वेंशन) का नाम. सेक्शन 3.3 देखें. नेटिव एपीआई के साथ काम करना.
CPU_ABI	नेटिव कोड के निर्देश सेट (सीपीयू टाइप + एबीआई कॉन्वेंशन) का नाम. सेक्शन 3.3 देखें. नेटिव एपीआई के साथ काम करना.
CPU_ABI2	नेटिव कोड के दूसरे निर्देश सेट (सीपीयू टाइप + एबीआई कन्वेंशन) का नाम. सेक्शन 3.3 देखें. नेटिव एपीआई के साथ काम करना.
डिवाइस	डिवाइस लागू करने वाले व्यक्ति या कंपनी की चुनी गई वैल्यू. इसमें डिवाइस के हार्डवेयर की सुविधाओं और डिवाइस के इंडस्ट्रियल डिज़ाइन के कॉन्फ़िगरेशन की पहचान करने वाला डेवलपमेंट का नाम या कोड नेम होता है. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है. साथ ही, यह वैल्यू रेगुलर एक्सप्रेशन “^[a-zA-Z0-9_-]+$” से मेल खानी चाहिए. प्रॉडक्ट के लाइफ़टाइम के दौरान, डिवाइस का यह नाम नहीं बदलना चाहिए.
फ़िंगरप्रिंट	इस स्ट्रिंग से, इस बिल्ड की खास तौर पर पहचान की जाती है. यह किसी व्यक्ति के लिए आसानी से पढ़ा जा सकने वाला होना चाहिए. यह इस टेंप्लेट के मुताबिक होना चाहिए: $(BRAND)/$(PRODUCT)/     $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) उदाहरण के लिए: acme/myproduct/     mydevice:13/LMYXX/3359:userdebug/test-keys फ़िंगरप्रिंट में खाली सफ़ेद जगह वाले वर्ण नहीं होने चाहिए. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है.
हार्डवेयर	हार्डवेयर का नाम (कर्नल कमांड लाइन या /proc से). यह किसी व्यक्ति के लिए आसानी से पढ़ा जा सकने वाला होना चाहिए. इस फ़ील्ड की वैल्यू, 7-बिट ASCII के तौर पर कोड की जानी चाहिए. साथ ही, यह रेगुलर एक्सप्रेशन “^[a-zA-Z0-9_-]+$” से मेल खानी चाहिए.
होस्ट	यह एक ऐसी स्ट्रिंग होती है जो उस होस्ट की खास तौर पर पहचान करती है जिस पर बिल्ड बनाया गया था. यह स्ट्रिंग, आम तौर पर पढ़े जा सकने वाले फ़ॉर्मैट में होती है. इस फ़ील्ड के फ़ॉर्मैट के लिए कोई ज़रूरी शर्त नहीं है. हालांकि, यह शर्त ज़रूरी है कि यह शून्य या खाली स्ट्रिंग ("") न हो.
आईडी	डिवाइस लागू करने वाला व्यक्ति, किसी रिलीज़ के बारे में बताने के लिए, यह आइडेंटिफ़ायर चुनता है. यह आइडेंटिफ़ायर, आम तौर पर पढ़े जा सकने वाले फ़ॉर्मैट में होता है. यह फ़ील्ड, android.os.Build.VERSION.INCREMENTAL जैसा हो सकता है. हालांकि, यह ज़रूरी है कि इसकी वैल्यू, असली उपयोगकर्ताओं के लिए सॉफ़्टवेयर के बिल्ड के बीच अंतर करने के लिहाज़ से काम की हो. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है. साथ ही, यह वैल्यू रेगुलर एक्सप्रेशन “^[a-zA-Z0-9._-]+$” से मेल खानी चाहिए.
मैन्युफ़ैक्चरर	प्रॉडक्ट के ओरिजनल इक्विपमेंट मैन्युफ़ैक्चरर (OEM) का ट्रेड नेम. इस फ़ील्ड के फ़ॉर्मैट के लिए कोई ज़रूरी शर्त नहीं है. हालांकि, यह शर्त ज़रूरी है कि यह शून्य या खाली स्ट्रिंग ("") न हो. साथ ही, प्रॉडक्ट के लाइफ़टाइम के दौरान इस फ़ील्ड में बदलाव नहीं किया जाना चाहिए.
SOC_MANUFACTURER	प्रॉडक्ट में इस्तेमाल किए गए प्राइमरी सिस्टम ऑन चिप (एसओसी) के मैन्युफ़ैक्चरर का ट्रेड नेम. एक ही SoC मैन्युफ़ैक्चरर वाले डिवाइसों के लिए, एक ही कॉन्स्टेंट वैल्यू का इस्तेमाल किया जाना चाहिए. कृपया एसओसी मैन्युफ़ैक्चरर से पूछें कि इस्तेमाल करने के लिए कौनसा सही कॉन्स्टेंट है. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है. यह वैल्यू, रेगुलर एक्सप्रेशन “^([0-9A-Za-z ]+)” से मैच करनी चाहिए. साथ ही, यह वैल्यू व्हाइटस्पेस से शुरू या खत्म नहीं होनी चाहिए. यह वैल्यू “unknown” के बराबर नहीं होनी चाहिए. प्रॉडक्ट के लाइफ़टाइम के दौरान, इस फ़ील्ड में बदलाव नहीं किया जाना चाहिए.
SOC_MODEL	प्रॉडक्ट में इस्तेमाल किए गए चिप पर सिस्टम (SoC) के प्राइमरी मॉडल का नाम. एक ही एसओसी मॉडल वाले डिवाइसों को एक ही कॉन्स्टेंट वैल्यू का इस्तेमाल करना चाहिए. कृपया एसओसी मैन्युफ़ैक्चरर से पूछें कि इस्तेमाल करने के लिए सही कॉन्स्टेंट क्या है. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है. साथ ही, यह रेगुलर एक्सप्रेशन “^([0-9A-Za-z ._/+-]+)$” से मैच करनी चाहिए. यह वैल्यू, व्हाइटस्पेस से शुरू या खत्म नहीं होनी चाहिए. साथ ही, यह “unknown” के बराबर नहीं होनी चाहिए. प्रॉडक्ट के लाइफ़टाइम के दौरान, इस फ़ील्ड की वैल्यू में बदलाव नहीं किया जाना चाहिए.
MODEL	डिवाइस लागू करने वाले व्यक्ति की चुनी गई वैल्यू, जिसमें डिवाइस का नाम होता है, जैसा कि आखिरी उपयोगकर्ता को पता होता है. यह वही नाम होना चाहिए जिससे डिवाइस को मार्केट में लाया जाता है और असल उपयोगकर्ताओं को बेचा जाता है. इस फ़ील्ड के लिए, किसी खास फ़ॉर्मैट की ज़रूरत नहीं है. हालांकि, यह शर्त ज़रूरी है कि यह शून्य या खाली स्ट्रिंग ("") न हो. साथ ही, प्रॉडक्ट के लाइफ़टाइम के दौरान इस फ़ील्ड में कोई बदलाव नहीं होना चाहिए.
प्रॉडक्ट	डिवाइस लागू करने वाले व्यक्ति या कंपनी की चुनी गई वैल्यू. इसमें किसी खास प्रॉडक्ट (SKU) का डेवलपमेंट नाम या कोड नाम शामिल होता है. यह वैल्यू, एक ही ब्रैंड के लिए यूनीक होनी चाहिए. यह कोड, लोगों के लिए पढ़ने लायक होना चाहिए. हालांकि, यह ज़रूरी नहीं है कि इसे असली उपयोगकर्ता देखें. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है. साथ ही, यह वैल्यू रेगुलर एक्सप्रेशन “^[a-zA-Z0-9_-]+$” से मेल खानी चाहिए. प्रॉडक्ट के लाइफ़टाइम के दौरान, इस प्रॉडक्ट के नाम में बदलाव नहीं किया जाना चाहिए.
ODM_SKU	डिवाइस लागू करने वाला व्यक्ति, वैकल्पिक वैल्यू चुन सकता है. इसमें डिवाइस के खास कॉन्फ़िगरेशन को ट्रैक करने के लिए इस्तेमाल किया जाने वाला SKU (स्टॉक रखने की यूनिट) शामिल होता है. उदाहरण के लिए, डिवाइस बेचते समय उसमें शामिल किए गए किसी भी पेरिफ़रल. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है. साथ ही, यह वैल्यू रेगुलर एक्सप्रेशन ^([0-9A-Za-z.,_-]+)$ से मैच करनी चाहिए.
SERIAL	"UNKNOWN" दिखाना ज़रूरी है.
टैग	डिवाइस लागू करने वाले व्यक्ति के चुने गए टैग की सूची, जिसे कॉमा लगाकर अलग किया गया है. इससे, बिल्ड को और भी अलग किया जा सकता है. टैग को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है और यह रेगुलर एक्सप्रेशन “^[a-zA-Z0-9._-]+” से मैच करता है. साथ ही, इसमें Android प्लैटफ़ॉर्म के तीन सामान्य साइनिंग कॉन्फ़िगरेशन: रिलीज़-की, डेवलपर-की, और टेस्ट-की से जुड़ी कोई एक वैल्यू होनी चाहिए.
समय	यह वैल्यू, बिल्ड होने के समय का टाइमस्टैंप दिखाती है.
वाई-फ़ाई के टाइप के बारे में जानकारी	डिवाइस इंप्लीमेंटर की चुनी गई वैल्यू, जो बिल्ड के रनटाइम कॉन्फ़िगरेशन के बारे में बताती है. इस फ़ील्ड में, Android के तीन सामान्य रनटाइम कॉन्फ़िगरेशन में से किसी एक की वैल्यू होनी चाहिए: user, userdebug या eng.
उपयोगकर्ता	उस उपयोगकर्ता (या ऑटोमेटेड उपयोगकर्ता) का नाम या यूज़र आईडी जिसने बिल्ड जनरेट किया है. इस फ़ील्ड के फ़ॉर्मैट के लिए कोई ज़रूरी शर्त नहीं है. हालांकि, यह शर्त ज़रूरी है कि यह शून्य या खाली स्ट्रिंग ("") न हो.
SECURITY_PATCH	यह वैल्यू, किसी बिल्ड के सुरक्षा पैच के लेवल को दिखाती है. इससे यह पता चलना चाहिए कि बाइल्ड, Android के सार्वजनिक सुरक्षा बुलेटिन में बताई गई किसी भी समस्या से किसी भी तरह से सुरक्षित है. यह [YYYY-MM-DD] फ़ॉर्मैट में होना चाहिए. यह Android के सार्वजनिक सुरक्षा बुलेटिन या Android की सुरक्षा से जुड़ी सलाह में दी गई स्ट्रिंग से मेल खानी चाहिए. उदाहरण के लिए, "2015-11-01".
BASE_OS	इस वैल्यू से, बिल्ड के FINGERPRINT पैरामीटर की जानकारी मिलती है. यह वैल्यू, Android के सार्वजनिक सुरक्षा बुलेटिन में दिए गए पैच को छोड़कर, इस बिल्ड से पूरी तरह मेल खाती है. यह सही वैल्यू दिखानी चाहिए. अगर ऐसा कोई बिल्ड मौजूद नहीं है, तो खाली स्ट्रिंग ("") दिखाएं.
BOOTLOADER	डिवाइस लागू करने वाले व्यक्ति की चुनी गई वैल्यू, जो डिवाइस में इस्तेमाल किए गए खास इंटरनल बूटलोडर वर्शन की पहचान करती है. यह वैल्यू, इंसान के पढ़ने लायक फ़ॉर्मैट में होती है. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है. साथ ही, यह वैल्यू रेगुलर एक्सप्रेशन “^[a-zA-Z0-9._-]+$” से मेल खानी चाहिए.
getRadioVersion()	डिवाइस लागू करने वाले व्यक्ति की चुनी गई वैल्यू होनी चाहिए या वह वैल्यू दिखानी चाहिए. यह वैल्यू, डिवाइस में इस्तेमाल किए गए खास इंटरनल रेडियो/मॉडेम वर्शन की पहचान करती है. साथ ही, यह वैल्यू, इंसान के पढ़ने लायक फ़ॉर्मैट में होनी चाहिए. अगर किसी डिवाइस में कोई इंटरनल रेडियो/मॉडेम नहीं है, तो यह फ़ंक्शन NULL दिखाना चाहिए. इस फ़ील्ड की वैल्यू, 7-बिट ASCII के तौर पर कोड की जानी चाहिए. साथ ही, यह रेगुलर एक्सप्रेशन “^[a-zA-Z0-9._-,]+$” से मेल खानी चाहिए.
getSerial()	यह हार्डवेयर का सीरियल नंबर होना चाहिए. यह एक ही मॉडल और मैन्युफ़ैक्चरर के सभी डिवाइसों के लिए उपलब्ध और यूनीक होना चाहिए. इस फ़ील्ड की वैल्यू, सात बिट के ASCII कोड में बदली जा सकती हो और यह रेगुलर एक्सप्रेशन “^[a-zA-Z0-9]+$” से मेल खाती हो.

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

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

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

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

• [C-SR-1] हमारा सुझाव है कि आप यहां दिए गए ऐप्लिकेशन इंटेंट के हिसाब से तय किए गए सभी सार्वजनिक इंटेंट फ़िल्टर पैटर्न के लिए, एक या उससे ज़्यादा ऐप्लिकेशन या सेवा कॉम्पोनेंट को इंटेंट हैंडलर के साथ पहले से लोड करें. साथ ही, एसडीके में बताए गए इन सामान्य ऐप्लिकेशन इंटेंट के लिए, डेवलपर की उम्मीदों के मुताबिक काम करें.

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

3.2.3.2. इंटेंट रिज़ॉल्यूशन

• [C-0-1] Android एक एक्सटेंसिबल प्लैटफ़ॉर्म है. इसलिए, डिवाइस पर लागू होने वाले सिस्टम को, सेक्शन 3.2.3.1 में बताए गए हर इंटेंट पैटर्न को तीसरे पक्ष के ऐप्लिकेशन से बदलने की अनुमति देनी चाहिए. हालांकि, सेटिंग को बदलने की अनुमति नहीं दी जानी चाहिए. Android के ओपन सोर्स वर्शन में, डिफ़ॉल्ट रूप से इसकी अनुमति होती है.

• [C-0-2] डिवाइस लागू करने वाले लोगों को, सिस्टम ऐप्लिकेशन के इन इंटेंट पैटर्न के इस्तेमाल के लिए खास विशेषाधिकार नहीं देने चाहिए. इसके अलावा, तीसरे पक्ष के ऐप्लिकेशन को इन पैटर्न से बाइंड करने और उनका कंट्रोल लेने से भी नहीं रोकना चाहिए. इस पाबंदी में, “चुने गए” उपयोगकर्ता इंटरफ़ेस को बंद करना शामिल है. हालांकि, इसमें और भी चीज़ें शामिल हो सकती हैं. इस इंटरफ़ेस की मदद से, उपयोगकर्ता एक ही इंटेंट पैटर्न को मैनेज करने वाले कई ऐप्लिकेशन में से किसी एक को चुन सकता है.

• [C-0-3] डिवाइस पर लागू करने के लिए, उपयोगकर्ताओं को यूज़र इंटरफ़ेस देना ज़रूरी है, ताकि वे इंटेंट के लिए डिफ़ॉल्ट गतिविधि में बदलाव कर सकें.

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

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

• [C-0-4] डिजिटल एसेट लिंक की खास जानकारी में बताए गए पुष्टि करने के चरणों को पूरा करके, किसी भी इंटेंट फ़िल्टर की पुष्टि करना ज़रूरी है. ये चरण, अपस्ट्रीम Android Open Source Project में पैकेज मैनेजर ने लागू किए हैं.
• [C-0-5] ऐप्लिकेशन के इंस्टॉल होने के दौरान, इंटेंट फ़िल्टर की पुष्टि की कोशिश करनी चाहिए. साथ ही, पुष्टि हो चुके सभी यूआरआई इंटेंट फ़िल्टर को उनके यूआरआई के लिए डिफ़ॉल्ट ऐप्लिकेशन हैंडलर के तौर पर सेट करना चाहिए.
• अगर यूआरआई की पुष्टि हो जाती है, लेकिन अन्य यूआरआई फ़िल्टर की पुष्टि नहीं हो पाती है, तो यूआरआई के लिए डिफ़ॉल्ट ऐप्लिकेशन हैंडलर के तौर पर, यूआरआई इंटेंट फ़िल्टर सेट किए जा सकते हैं. अगर किसी डिवाइस पर ऐसा किया जाता है, तो उसे सेटिंग मेन्यू में, उपयोगकर्ता के लिए हर यूआरआई पैटर्न के हिसाब से बदलाव करना होगा.
• उपयोगकर्ता को सेटिंग में, हर ऐप्लिकेशन के लिए ऐप्लिकेशन लिंक के कंट्रोल देने होंगे. ये कंट्रोल इस तरह होने चाहिए:
  • [C-0-6] उपयोगकर्ता को किसी ऐप्लिकेशन के लिए, डिफ़ॉल्ट रूप से लिंक खुलने के व्यवहार को पूरी तरह से बदलने की अनुमति होनी चाहिए. जैसे: हमेशा खोलें, हमेशा पूछें या कभी न खोलें. यह सभी संभावित यूआरआई इंटेंट फ़िल्टर पर समान रूप से लागू होना चाहिए.
  • [C-0-7] उपयोगकर्ता को संभावित यूआरआई इंटेंट फ़िल्टर की सूची दिखनी चाहिए.
  • डिवाइस पर लागू करने पर, उपयोगकर्ता को हर इंटेंट फ़िल्टर के आधार पर, पुष्टि किए गए खास उम्मीदवार यूआरआई इंटेंट फ़िल्टर को बदलने की सुविधा मिल सकती है.
  • [C-0-8] डिवाइस पर लागू करने की सुविधा, उपयोगकर्ताओं को कुछ खास यूआरआई इंटेंट फ़िल्टर देखने और उन्हें बदलने की अनुमति देनी चाहिए. ऐसा तब ज़रूरी है, जब डिवाइस पर लागू करने की सुविधा से कुछ खास यूआरआई इंटेंट फ़िल्टर की पुष्टि हो जाए, जबकि कुछ अन्य फ़िल्टर की पुष्टि न हो पाए.

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

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

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

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

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

• [C-0-1] SDK टूल के दस्तावेज़ में बताए गए सिस्टम इवेंट के जवाब में, यहां दी गई सूची में शामिल सार्वजनिक ब्रॉडकास्ट इंटेंट को ब्रॉडकास्ट करना ज़रूरी है. ध्यान दें कि यह शर्त, सेक्शन 3.5 के मुताबिक है. ऐसा इसलिए है, क्योंकि बैकग्राउंड में काम करने वाले ऐप्लिकेशन से जुड़ी सीमा के बारे में एसडीके दस्तावेज़ में भी बताया गया है. साथ ही, कुछ ब्रॉडकास्ट इंटेंट, हार्डवेयर के साथ काम करने की शर्त पर निर्भर होते हैं. अगर डिवाइस में ज़रूरी हार्डवेयर मौजूद है, तो उसे इंटेंट ब्रॉडकास्ट करने होंगे और SDK टूल के दस्तावेज़ के मुताबिक काम करना होगा.

3.2.3.5. शर्तों के हिसाब से ऐप्लिकेशन इंटेंट

Android में ऐसी सेटिंग शामिल हैं जिनकी मदद से, उपयोगकर्ता आसानी से डिफ़ॉल्ट ऐप्लिकेशन चुन सकते हैं. जैसे, होम स्क्रीन या एसएमएस के लिए.

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

अगर डिवाइस पर लागू करने की रिपोर्ट में android.software.home_screen दिखता है, तो:

• [C-1-1] होम स्क्रीन पर ऐप्लिकेशन का डिफ़ॉल्ट सेटिंग मेन्यू दिखाने के लिए, android.settings.HOME_SETTINGS के इंटेंट का पालन करना ज़रूरी है.

अगर डिवाइस में android.hardware.telephony.calling की सुविधा लागू की गई है, तो:

• [C-2-1] डिफ़ॉल्ट एसएमएस ऐप्लिकेशन बदलने के लिए डायलॉग दिखाने के लिए, android.provider.Telephony.ACTION_CHANGE_DEFAULT इंटेंट को कॉल करने वाला सेटिंग मेन्यू ज़रूर उपलब्ध कराएं.

• [C-2-2] उपयोगकर्ता को डिफ़ॉल्ट फ़ोन ऐप्लिकेशन बदलने की अनुमति देने के लिए, डायलॉग दिखाने के android.telecom.action.CHANGE_DEFAULT_DIALER Intent का पालन करना ज़रूरी है.

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

• [C-2-3] android.telecom.action.CHANGE_PHONE_ACCOUNTS के मकसद को पूरा करना ज़रूरी है, ताकि उपयोगकर्ता PhoneAccounts से जुड़े ConnectionServices को कॉन्फ़िगर कर सके. साथ ही, वह डिफ़ॉल्ट PhoneAccount को भी कॉन्फ़िगर कर सके. टेलीकम्यूनिकेशन सेवा देने वाली कंपनी, आउटगोइंग कॉल करने के लिए इस डिफ़ॉल्ट PhoneAccount का इस्तेमाल करेगी. AOSP में इस ज़रूरी शर्त को पूरा करने के लिए, "कॉल" सेटिंग मेन्यू में "कॉल करने के लिए इस्तेमाल किए जाने वाले खाते का विकल्प" मेन्यू शामिल किया गया है.

• [C-2-4] android.app.role.CALL_REDIRECTION भूमिका वाले ऐप्लिकेशन के लिए, android.telecom.CallRedirectionService की अनुमति ज़रूर होनी चाहिए.

• [C-2-5] उपयोगकर्ता को ऐसा ऐप्लिकेशन चुनने की सुविधा देनी चाहिए जिसमें android.app.role.CALL_REDIRECTION की भूमिका हो.

• [C-2-6] ऐप्लिकेशन को android.intent.action.SENDTO और android.intent.action.VIEW इंटेंट का पालन करना चाहिए. साथ ही, एसएमएस भेजने/दिखाने के लिए कोई गतिविधि उपलब्ध करानी चाहिए.

• [C-SR-1] हमारा सुझाव है कि आप पहले से लोड किए गए डायलर ऐप्लिकेशन के साथ, android.intent.action.ANSWER, android.intent.action.CALL, android.intent.action.CALL_BUTTON, android.intent.action.VIEW & android.intent.action.DIAL इंटेंट का इस्तेमाल करें. यह ऐप्लिकेशन इन इंटेंट को मैनेज कर सकता है और SDK टूल में बताए गए तरीके से इनका जवाब दे सकता है.

अगर डिवाइस पर लागू करने की रिपोर्ट में android.hardware.nfc.hce दिखता है, तो:

• [C-3-1] टच किए बिना पेमेंट करने के लिए, डिफ़ॉल्ट ऐप्लिकेशन सेटिंग मेन्यू दिखाने के लिए, android.settings.NFC_PAYMENT_SETTINGS के इंटेंट का पालन करना ज़रूरी है.
• [C-3-2] android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT के इंटेंट का पालन करना ज़रूरी है, ताकि एक ऐसी ऐक्टिविटी दिखाई जा सके जो उपयोगकर्ता से किसी कैटगरी के लिए डिफ़ॉल्ट कार्ड इम्यूलेशन सेवा बदलने के लिए कहे. इस बारे में SDK टूल में बताया गया है.

अगर डिवाइस पर लागू करने की रिपोर्ट में android.hardware.nfc दिखता है, तो:

• [C-4-1] SDK में बताए गए इन इंटेंट के लिए डेवलपर की उम्मीदों को पूरा करने वाली गतिविधि दिखाने के लिए, इन इंटेंट android.nfc.action.NDEF_DISCOVERED, android.nfc.action.TAG_DISCOVERED & android.nfc.action.TECH_DISCOVERED का पालन करना ज़रूरी है.

अगर डिवाइस पर लागू करने की रिपोर्ट में android.hardware.bluetooth दिखता है, तो:

• [C-5-1] ‘android.bluetooth.adapter.action.REQUEST_ENABLE’ के ज़रिए भेजे गए इंटेंट का पालन करना ज़रूरी है. साथ ही, उपयोगकर्ता को ब्लूटूथ चालू करने की अनुमति देने के लिए, सिस्टम गतिविधि दिखानी होगी.
• [C-5-2] ऐप्लिकेशन को ‘android.bluetooth.adapter.action.REQUEST_DISCOVERABLE’ इंटेंट का पालन करना चाहिए. साथ ही, वह सिस्टम गतिविधि दिखाए जो डिस्कवर किए जा सकने वाले मोड का अनुरोध करती है.

अगर डिवाइस पर डीएनडी मोड की सुविधा काम करती है, तो:

• [C-6-1] ऐसी ऐक्टिविटी लागू करना ज़रूरी है जो इंटेंट ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS का जवाब दे. UI_MODE_TYPE_NORMAL के साथ लागू करने के लिए, यह ज़रूरी है कि यह ऐसी ऐक्टिविटी हो जिसमें उपयोगकर्ता, ऐप्लिकेशन को डीएनडी नीति के कॉन्फ़िगरेशन का ऐक्सेस दे या न दे.

अगर डिवाइस पर, उपयोगकर्ताओं को तीसरे पक्ष के इनपुट तरीकों का इस्तेमाल करने की अनुमति है, तो वे:

• [C-7-1] android.settings.INPUT_METHOD_SETTINGS के इंटेंट के जवाब में, तीसरे पक्ष के इनपुट तरीकों को जोड़ने और कॉन्फ़िगर करने के लिए, उपयोगकर्ता के ऐक्सेस की सुविधा देने वाली सुविधा देना ज़रूरी है.

अगर डिवाइस पर तीसरे पक्ष की सुलभता सेवाएं काम करती हैं, तो:

• [C-8-1] ऐप्लिकेशन में, पहले से लोड की गई सुलभता सेवाओं के साथ-साथ तीसरे पक्ष की सुलभता सेवाओं को चालू और बंद करने के लिए, उपयोगकर्ता के लिए ऐक्सेस करने लायक तरीका उपलब्ध कराना android.settings.ACCESSIBILITY_SETTINGS ज़रूरी है.

अगर डिवाइस में वाई-फ़ाई आसानी से कनेक्ट करने की सुविधा शामिल है और तीसरे पक्ष के ऐप्लिकेशन के लिए इस सुविधा का ऐक्सेस दिया गया है, तो:

• [C-9-1] SDK के दस्तावेज़ में बताए गए तरीके के मुताबिक, Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI Intent API लागू करना ज़रूरी है.

अगर डिवाइस में डेटा बचाने वाला मोड उपलब्ध है, तो:

• [C-10-1] सेटिंग में ऐसा यूज़र इंटरफ़ेस होना चाहिए जो Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS के इंटेंट को मैनेज करता हो. इससे उपयोगकर्ता, अनुमति वाली सूची में ऐप्लिकेशन जोड़ सकते हैं या उससे ऐप्लिकेशन हटा सकते हैं.

अगर डिवाइस में डेटा बचाने वाला मोड उपलब्ध नहीं है, तो:

• [C-11-1] ऐप्लिकेशन में ऐसी गतिविधि होनी चाहिए जो Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS इंटेंट को मैनेज करती हो. हालांकि, इसे कोई काम न करने वाले इंटेंट के तौर पर लागू किया जा सकता है.

अगर डिवाइस में android.hardware.camera.any के ज़रिए कैमरे के साथ काम करने की सुविधा का एलान किया गया है, तो:

• [C-12-3] SDK दस्तावेज़ में बताए गए इनटेंट MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE, और MediaStore.ACTION_VIDEO_CAPTURE को मैनेज करना ज़रूरी है. साथ ही, पहले से इंस्टॉल किए गए Android ऐप्लिकेशन को सिर्फ़ इन इनटेंट को मैनेज करने की अनुमति देनी होगी.

अगर डिवाइस पर लागू करने की रिपोर्ट में android.software.device_admin दिखता है, तो:

• [C-13-1] उपयोगकर्ता को सिस्टम में डिवाइस एडमिन जोड़ने (या उसे अस्वीकार करने की अनुमति देने) के लिए, यूज़र इंटरफ़ेस (यूआई) को शुरू करने के लिए, इंटेंट android.app.action.ADD_DEVICE_ADMIN का पालन करना ज़रूरी है.

• [C-13-2] ऐप्लिकेशन को इन इंटेंट का पालन करना होगा: android.app.action.PROVISION_MANAGED_PROFILE, android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD, android.app.action.SET_NEW_PASSWORD & android.app.action.START_ENCRYPTION. साथ ही, इसमें ऐसी गतिविधि होनी चाहिए जो इन इंटेंट को पूरा करती हो. इस बारे में यहां SDK में बताया गया है.

अगर डिवाइस पर लागू किए गए ऐप्लिकेशन में android.software.autofill फ़ीचर फ़्लैग का एलान किया जाता है, तो:

• [C-14-1] AutofillService और AutofillManager एपीआई को पूरी तरह से लागू करना ज़रूरी है. साथ ही, android.settings.REQUEST_SET_AUTOFILL_SERVICE इंटेंट का पालन करना ज़रूरी है, ताकि उपयोगकर्ता को जानकारी अपने-आप भरने की सुविधा चालू और बंद करने के लिए, ऐप्लिकेशन की डिफ़ॉल्ट सेटिंग मेन्यू दिखाया जा सके. साथ ही, उपयोगकर्ता के लिए जानकारी अपने-आप भरने की डिफ़ॉल्ट सेवा बदली जा सके.

अगर डिवाइस में पहले से इंस्टॉल किया गया कोई ऐप्लिकेशन है या तीसरे पक्ष के ऐप्लिकेशन को इस्तेमाल के आंकड़े ऐक्सेस करने की अनुमति देनी है, तो:

• [C-SR-2] ऐप्लिकेशन के लिए, android.permission.PACKAGE_USAGE_STATS अनुमति का एलान करने वाले ऐप्लिकेशन के लिए, android.settings.ACTION_USAGE_ACCESS_SETTINGS इंटेंट के जवाब में, इस्तेमाल के आंकड़ों का ऐक्सेस देने या रद्द करने के लिए, उपयोगकर्ता के ऐक्सेस करने की सुविधा देने का सुझाव दिया जाता है.

अगर डिवाइस पर लागू किए गए तरीकों से, पहले से इंस्टॉल किए गए ऐप्लिकेशन के साथ-साथ किसी भी ऐप्लिकेशन को इस्तेमाल के आंकड़े ऐक्सेस करने से रोकना है, तो:

• [C-15-1] ऐप्लिकेशन में अब भी ऐसी ऐक्टिविटी होनी चाहिए जो android.settings.ACTION_USAGE_ACCESS_SETTINGS इंटेंट पैटर्न को मैनेज करती हो. हालांकि, इसे बिना किसी कार्रवाई के लागू करना ज़रूरी है. इसका मतलब है कि ऐप्लिकेशन में ऐसा व्यवहार होना चाहिए जो उपयोगकर्ता को ऐक्सेस देने से अस्वीकार करने पर होता है.

अगर डिवाइस पर, सेटिंग में AutofillService_passwordsActivity से तय की गई गतिविधियों के लिंक या इसी तरह के किसी तरीके से उपयोगकर्ता के पासवर्ड के लिंक दिखाए जाते हैं, तो:

• [C-16-1] यह ज़रूरी है कि इंस्टॉल की गई सभी ऑटोमैटिक भरने की सेवाओं के लिए, ऐसे लिंक दिखाए जाएं.

• [C-17-1] [2.2.3 में ले जाया गया]

अगर डिवाइस पर VoiceInteractionService काम करता है और एक से ज़्यादा ऐप्लिकेशन इस एपीआई का इस्तेमाल करते हैं, तो:

• [C-18-1] वॉइस इनपुट और असिस्ट के लिए, डिफ़ॉल्ट ऐप्लिकेशन सेटिंग मेन्यू दिखाने के android.settings.ACTION_VOICE_INPUT_SETTINGS के इंटेंट का पालन करना ज़रूरी है.

अगर डिवाइस पर लागू की गई सुविधाओं में android.hardware.audio.output की जानकारी दी गई है, तो:

• [C-SR-3] हमारा सुझाव है कि आप android.intent.action.TTS_SERVICE, android.speech.tts.engine.INSTALL_TTS_DATA & android.speech.tts.engine.GET_SAMPLE_TEXT इंटेंट का इस्तेमाल करें. इन इंटेंट के लिए, SDK में यहां बताई गई गतिविधि की मदद से इन इंटेंट को पूरा किया जा सकता है.

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

• इसमें स्क्रीन सेवर की सुविधा शामिल होनी चाहिए. साथ ही, उपयोगकर्ताओं को android.settings.DREAM_SETTINGS इंटेंट के जवाब में, स्क्रीन सेवर को कॉन्फ़िगर करने के लिए सेटिंग का विकल्प भी देना चाहिए.

3.2.4. सेकंडरी/एक से ज़्यादा डिसप्ले पर की गई गतिविधियां

अगर डिवाइस पर एक से ज़्यादा डिसप्ले पर सामान्य Android गतिविधियां लॉन्च करने की अनुमति है, तो:

• [C-1-1] android.software.activities_on_secondary_displays फ़ीचर फ़्लैग को सेट करना ज़रूरी है.
• [C-1-2] यह ज़रूरी है कि ऐप्लिकेशन, मुख्य डिसप्ले पर चल रही ऐक्टिविटी की तरह ही एपीआई के साथ काम करता हो.
• [C-1-3] अगर नई गतिविधि को ActivityOptions.setLaunchDisplayId() एपीआई के ज़रिए टारगेट डिसप्ले तय किए बिना लॉन्च किया जाता है, तो नई गतिविधि को उसी डिसप्ले पर ले जाना चाहिए जिस पर गतिविधि शुरू की गई थी.
• [C-1-4] Display.FLAG_PRIVATE फ़्लैग वाले डिसप्ले को हटाने पर, सभी गतिविधियों को मिटाना ज़रूरी है.
• [C-1-5] जब डिवाइस को सुरक्षित लॉक स्क्रीन से लॉक किया गया हो, तब सभी स्क्रीन पर कॉन्टेंट को सुरक्षित तरीके से छिपाना ज़रूरी है. ऐसा तब तक करना होगा, जब तक कि ऐप्लिकेशन Activity#setShowWhenLocked() एपीआई का इस्तेमाल करके, लॉक स्क्रीन पर सबसे ऊपर दिखने के लिए ऑप्ट इन न कर दे.
• उसमें android.content.res.Configuration होना चाहिए, जो उस डिसप्ले से जुड़ा हो, ताकि उसे दिखाया जा सके, सही तरीके से काम किया जा सके, और अगर कोई गतिविधि सेकंडरी डिसप्ले पर लॉन्च की जाती है, तो उस डिसप्ले के साथ काम किया जा सके.

अगर डिवाइस पर सेकंडरी डिसप्ले पर सामान्य Android गतिविधियां शुरू करने की अनुमति है और सेकंडरी डिसप्ले पर android.view.Display.FLAG_PRIVATE फ़्लैग है, तो:

• [C-3-1] सिर्फ़ उस डिसप्ले, सिस्टम, और गतिविधियों का मालिक ही उसे लॉन्च कर सकता है जो पहले से उस डिसप्ले पर मौजूद हैं. कोई भी व्यक्ति उस डिसप्ले पर ऐप्लिकेशन लॉन्च कर सकता है जिसमें android.view.Display.FLAG_PUBLIC फ़्लैग मौजूद हो.

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

नेटिव कोड के साथ काम करना मुश्किल है. इस वजह से, डिवाइस लागू करने वाले लोग:

• [C-SR-1] हमारा सुझाव है कि आप ऊपर दी गई सूची में मौजूद लाइब्रेरी का इस्तेमाल करें. ये लाइब्रेरी, Android Open Source Project से ली गई हैं.

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

मैनेज किया गया Dalvik बाइटकोड, ऐप्लिकेशन .apk फ़ाइल में दिए गए नेटिव कोड को कॉल कर सकता है. यह कोड, डिवाइस के हार्डवेयर आर्किटेक्चर के हिसाब से, ELF .so फ़ाइल के तौर पर कंपाइल किया जाता है. नेटिव कोड, प्रोसेसर की टेक्नोलॉजी पर काफ़ी निर्भर करता है. इसलिए, Android NDK में Android कई ऐप्लिकेशन बाइनरी इंटरफ़ेस (एबीआई) तय करता है.

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

• [C-0-1] यह एक या उससे ज़्यादा तय किए गए Android NDK ABIs के साथ काम करना चाहिए.
• [C-0-2] इसमें, मैनेज किए जा रहे एनवायरमेंट में चल रहे कोड के लिए, नेटिव कोड को कॉल करने की सुविधा शामिल होनी चाहिए. इसके लिए, स्टैंडर्ड Java नेटिव इंटरफ़ेस (JNI) के सेमेटिक्स का इस्तेमाल किया जाना चाहिए.
• [C-0-3] यह ज़रूरी है कि यह नीचे दी गई सूची में मौजूद हर ज़रूरी लाइब्रेरी के साथ, सोर्स के साथ काम करे (यानी हेडर के साथ काम करे) और एबीआई के लिए बाइनरी के साथ काम करे.
• [C-0-5] android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS, और android.os.Build.SUPPORTED_64_BIT_ABIS पैरामीटर की मदद से, डिवाइस पर काम करने वाले नेटिव ऐप्लिकेशन बाइनरी इंटरफ़ेस (एबीआई) की सटीक जानकारी देनी चाहिए. हर पैरामीटर में, एबीआई की सूची को कॉमा लगाकर अलग-अलग किया गया है. यह सूची, सबसे ज़्यादा से लेकर सबसे कम प्राथमिकता वाले एबीआई के क्रम में होती है.

• [C-0-6] ऊपर दिए गए पैरामीटर की मदद से, एबीआई की इस सूची के सबसेट की रिपोर्ट देना ज़रूरी है. साथ ही, सूची में शामिल नहीं किए गए किसी भी एबीआई की रिपोर्ट नहीं देनी चाहिए.

  • armeabi (NDK अब इसे टारगेट के तौर पर इस्तेमाल नहीं करता)
  • armeabi-v7a
  • arm64-v8a
  • x86
  • x86-64

• [C-0-7] नेटिव एपीआई उपलब्ध कराने वाली इन सभी लाइब्रेरी को, नेटिव कोड वाले ऐप्लिकेशन के लिए उपलब्ध कराना ज़रूरी है:

  • libaaudio.so (AAudio नेटिव ऑडियो सपोर्ट)
  • libamidi.so (नेटिव MIDI की सुविधा, अगर सेक्शन 5.9 में बताए गए तरीके के मुताबिक android.software.midi की सुविधा का दावा किया गया है)
  • libandroid.so (नेटिव Android गतिविधि के लिए सहायता)
  • libc (C लाइब्रेरी)
  • libcamera2ndk.so
  • libdl (डाइनैमिक लिंकर)
  • libEGL.so (नेटिव OpenGL सरफ़ेस मैनेजमेंट)
  • libGLESv1_CM.so (OpenGL ES 1.x)
  • libGLESv2.so (OpenGL ES 2.0)
  • libGLESv3.so (OpenGL ES 3.x)
  • libicui18n.so
  • libicuuc.so
  • libjnigraphics.so
  • liblog (Android लॉगिंग)
  • libmediandk.so (नेटिव मीडिया एपीआई के लिए सहायता)
  • libm (गणित लाइब्रेरी)
  • libneuralnetworks.so (Neural Networks API)
  • libOpenMAXAL.so (OpenMAX AL 1.0.1 के साथ काम करता है)
  • libOpenSLES.so (OpenSL ES 1.0.1 ऑडियो की सुविधा)
  • libRS.so
  • libstdc++ (C++ के लिए कम से कम सहायता)
  • libvulkan.so (Vulkan)
  • libz (Zlib कंप्रेसन)
  • JNI इंटरफ़ेस

• [C-0-8] ऊपर दी गई नेटिव लाइब्रेरी के लिए, सार्वजनिक फ़ंक्शन को जोड़ना या हटाना ज़रूरी नहीं है.

• [C-0-9] /vendor/etc/public.libraries.txt में, सीधे तौर पर तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराई गई, AOSP लाइब्रेरी के अलावा अन्य लाइब्रेरी की सूची देना ज़रूरी है.

• [C-0-10] एपीआई लेवल 24 या इसके बाद के वर्शन को टारगेट करने वाले तीसरे पक्ष के ऐप्लिकेशन के लिए, AOSP में सिस्टम लाइब्रेरी के तौर पर लागू और उपलब्ध कराई गई किसी भी अन्य नेटिव लाइब्रेरी को एक्सपोज़ नहीं किया जाना चाहिए, क्योंकि ये लाइब्रेरी रिज़र्व हैं.

• [C-0-11] libGLESv3.so लाइब्रेरी की मदद से, NDK में बताए गए सभी OpenGL ES 3.1 और Android एक्सटेंशन पैकेज फ़ंक्शन के सिंबल एक्सपोर्ट करना ज़रूरी है. ध्यान दें कि सभी सिंबल मौजूद होने चाहिए. हालांकि, सेक्शन 7.1.4.1 में, इससे जुड़ी ज़रूरी शर्तों के बारे में ज़्यादा जानकारी दी गई है.

• [C-0-12] Vulkan 1.0 के मुख्य फ़ंक्शन सिंबल के साथ-साथ, libvulkan.so लाइब्रेरी के ज़रिए VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1, और VK_KHR_get_physical_device_properties2 एक्सटेंशन के लिए, फ़ंक्शन सिंबल एक्सपोर्ट करना ज़रूरी है. ध्यान दें कि सभी सिंबल मौजूद होने चाहिए. हालांकि, सेक्शन 7.1.4.2 में इस बारे में ज़्यादा जानकारी दी गई है कि हर फ़ंक्शन को कब पूरी तरह से लागू किया जाना चाहिए.

• इसे, अपस्ट्रीम Android Open Source Project में मौजूद सोर्स कोड और हेडर फ़ाइलों का इस्तेमाल करके बनाया जाना चाहिए

ध्यान दें कि आने वाले समय में, Android के रिलीज़ में अन्य एबीआई के लिए सहायता उपलब्ध कराई जा सकती है.

3.3.2. 32-बिट ARM नेटिव कोड के साथ काम करना

अगर डिवाइस पर armeabi ABI काम करता है, तो:

• [C-3-1] armeabi-v7a के साथ भी काम करना चाहिए और इसकी जानकारी देनी चाहिए, क्योंकि armeabi सिर्फ़ पुराने ऐप्लिकेशन के साथ काम करने के लिए है.

अगर डिवाइस पर armeabi-v7a एबीआई का इस्तेमाल करने वाले ऐप्लिकेशन के लिए, एबीआई के काम करने की जानकारी मिलती है, तो:

• [C-2-1] /proc/cpuinfo में ये लाइनें शामिल होनी चाहिए. साथ ही, एक ही डिवाइस पर वैल्यू में बदलाव नहीं किया जाना चाहिए. भले ही, उन्हें अन्य एबीआई ने पढ़ा हो.

  • Features:, इसके बाद डिवाइस पर काम करने वाली ARMv7 सीपीयू की वैकल्पिक सुविधाओं की सूची दी गई है.
  • CPU architecture: के बाद, एक पूर्णांक होता है. इससे डिवाइस पर काम करने वाले सबसे बेहतर ARM आर्किटेक्चर के बारे में पता चलता है (उदाहरण के लिए, "8" के लिए ARMv8 डिवाइसों).

• [C-2-2] यहां दिए गए ऑपरेशन हमेशा उपलब्ध होने चाहिए. भले ही, एबीआई को ARMv8 आर्किटेक्चर पर लागू किया गया हो. ऐसा, नेटिव सीपीयू के साथ काम करने की सुविधा या सॉफ़्टवेयर इम्यूलेशन की मदद से किया जा सकता है:

  • SWP और SWPB के लिए निर्देश.
  • CP15ISB, CP15DSB, और CP15DMB बैरियर ऑपरेशंस.

• [C-2-3] इसमें Advanced SIMD (जिसे NEON भी कहा जाता है) एक्सटेंशन के लिए सहायता शामिल होनी चाहिए.

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

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

अगर डिवाइस पर android.webkit.Webview एपीआई को पूरी तरह से लागू किया गया है, तो:

• [C-1-1] android.software.webview की रिपोर्ट करना ज़रूरी है.
• [C-1-2] android.webkit.WebView एपीआई को लागू करने के लिए, Android 13 ब्रैंच पर, अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट से Chromium प्रोजेक्ट के बिल्ड का इस्तेमाल करना ज़रूरी है.

• [C-1-3] वेबव्यू की रिपोर्ट की गई यूज़र एजेंट स्ट्रिंग इस फ़ॉर्मैट में होनी चाहिए:

  Mozilla/5.0 (Linux; Android $(VERSION); [$(MODEL)] [Build/$(BUILD)]; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36

  • $(VERSION) स्ट्रिंग की वैल्यू, android.os.Build.VERSION.RELEASE की वैल्यू के बराबर होनी चाहिए.
  • $(MODEL) स्ट्रिंग खाली हो सकती है. हालांकि, अगर यह खाली नहीं है, तो इसकी वैल्यू, android.os.Build.MODEL की वैल्यू के बराबर होनी चाहिए.
  • "Build/$(BUILD)" को छोड़ा जा सकता है. हालांकि, अगर यह मौजूद है, तो $(BUILD) स्ट्रिंग, android.os.Build.ID की वैल्यू के बराबर होनी चाहिए.
  • $(CHROMIUM_VER) स्ट्रिंग की वैल्यू, अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट में मौजूद Chromium का वर्शन होनी चाहिए.
  • डिवाइस लागू करने पर, हो सकता है कि उपयोगकर्ता एजेंट स्ट्रिंग में मोबाइल को शामिल न किया जाए.

• वेबव्यू कॉम्पोनेंट में, ज़्यादा से ज़्यादा HTML5 सुविधाओं के साथ काम करने की सुविधा होनी चाहिए. अगर यह सुविधा काम करती है, तो यह HTML5 स्पेसिफ़िकेशन के मुताबिक होनी चाहिए.

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

ध्यान दें कि अगर डिवाइस पर 32-बिट प्रोसेसर का इस्तेमाल किया जा रहा है या सुविधा फ़्लैग android.hardware.ram.low का एलान किया गया है, तो उन्हें C-1-3 से छूट मिलती है.

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

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

• [C-1-1] एपीआई को HTML5 से जुड़े इन सभी एपीआई के साथ काम करना चाहिए:
  • ऐप्लिकेशन की कैश मेमोरी/ऑफ़लाइन काम करना
  • <video> टैग
  • जगह की जानकारी
• [C-1-2] यह ज़रूरी है कि यह HTML5/W3C के webstorage API के साथ काम करे. साथ ही, यह HTML5/W3C के IndexedDB API के साथ काम करे. ध्यान दें कि वेब डेवलपमेंट के स्टैंडर्ड से जुड़ी संस्थाएं, वेबस्टोरेज के बजाय IndexedDB का इस्तेमाल करने की ओर बढ़ रही हैं. इसलिए, आने वाले समय में Android के वर्शन में IndexedDB एक ज़रूरी कॉम्पोनेंट बन सकता है.
• स्टैंडअलोन ब्राउज़र ऐप्लिकेशन में, कस्टम उपयोगकर्ता एजेंट स्ट्रिंग भेजी जा सकती है.
• स्टैंडअलोन ब्राउज़र ऐप्लिकेशन पर, ज़्यादा से ज़्यादा HTML5 के लिए सहायता लागू की जानी चाहिए. भले ही, यह अपस्ट्रीम WebKit ब्राउज़र ऐप्लिकेशन पर आधारित हो या तीसरे पक्ष के किसी ब्राउज़र पर.

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

• [C-2-1] अब भी सेक्शन 3.2.3.1 में बताए गए पब्लिक इंटेंट पैटर्न के साथ काम करना चाहिए.

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

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

• [C-0-9] यह पक्का करना ज़रूरी है कि इंस्टॉल किए गए सभी ऐप्लिकेशन के लिए, एपीआई के साथ काम करने की सुविधा लागू हो. हालांकि, अगर उन पर सेक्शन 3.5.1 में बताई गई पाबंदी लगी है, तो यह ज़रूरी नहीं है.
• [C-0-10] अनुमति वाली सूची के उस तरीके को लागू नहीं करना चाहिए जिससे यह पक्का हो सके कि एपीआई, सिर्फ़ उन ऐप्लिकेशन के साथ काम करता है जिन्हें डिवाइस लागू करने वाले लोगों ने चुना है.

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

• [C-0-1] डिवाइसों को स्टैंडर्ड इंटेंट के व्यवहार या सेमेटिक्स में बदलाव नहीं करना चाहिए.
• [C-0-2] डिवाइसों को किसी खास तरह के सिस्टम कॉम्पोनेंट (जैसे, सेवा, गतिविधि, ContentProvider वगैरह) के लाइफ़साइकल या लाइफ़साइकल सेमेटिक्स में बदलाव नहीं करना चाहिए.
• [C-0-3] डिवाइसों को स्टैंडर्ड अनुमति के सेमेटिक्स में बदलाव नहीं करना चाहिए.
• डिवाइसों को बैकग्राउंड ऐप्लिकेशन पर लागू की गई सीमाओं में बदलाव नहीं करना चाहिए. खास तौर पर, बैकग्राउंड में काम करने वाले ऐप्लिकेशन के लिए:
  • [C-0-4] GnssMeasurement और GnssNavigationMessage से आउटपुट पाने के लिए, ऐप्लिकेशन के रजिस्टर किए गए कॉलबैक को चलाना बंद करना होगा.
  • [C-0-5] उन्हें LocationManager एपीआई क्लास या WifiManager.startScan() तरीके से, ऐप्लिकेशन को मिलने वाले अपडेट की फ़्रीक्वेंसी को रेट-सीमा में रखना होगा.
  • [C-0-6] अगर ऐप्लिकेशन, एपीआई लेवल 25 या उसके बाद के वर्शन को टारगेट कर रहा है, तो उसे ऐप्लिकेशन के मेनिफ़ेस्ट में, स्टैंडर्ड Android इंटेंट के लिए, अपने-आप होने वाले ब्रॉडकास्ट के लिए ब्रॉडकास्ट रिसीवर रजिस्टर करने की अनुमति नहीं देनी चाहिए. ऐसा तब तक नहीं किया जाना चाहिए, जब तक कि ब्रॉडकास्ट इंटेंट के लिए "signature" या "signatureOrSystem" protectionLevel अनुमति की ज़रूरत न हो या वे छूट वाली सूची में शामिल न हों.
  • [C-0-7] अगर ऐप्लिकेशन, एपीआई लेवल 25 या उसके बाद के वर्शन को टारगेट कर रहा है, तो उसे ऐप्लिकेशन की बैकग्राउंड सेवाओं को बंद करना होगा. ऐसा ठीक वैसे ही करना होगा जैसे ऐप्लिकेशन ने सेवाओं के stopSelf() तरीके को कॉल किया हो. ऐसा तब तक करना होगा, जब तक ऐप्लिकेशन को किसी ऐसे टास्क को मैनेज करने के लिए, कुछ समय के लिए अनुमति वाली सूची में नहीं रखा जाता जो उपयोगकर्ता को दिखता है.
  • [C-0-8] अगर ऐप्लिकेशन, एपीआई लेवल 25 या उसके बाद के वर्शन को टारगेट कर रहा है, तो उसे वेक लॉक रिलीज़ करने होंगे.
• [C-0-11] डिवाइसों को Security.getProviders() वाले तरीके से, यहां दिए गए सुरक्षा प्रोवाइडर को, पहले सात ऐरे वैल्यू के तौर पर दिखाना चाहिए. साथ ही, इनका नाम और क्लास भी यहां दिए गए क्रम में और नाम (Provider.getName() से मिली वैल्यू के तौर पर) के साथ होना चाहिए. ऐसा तब तक करना होगा, जब तक ऐप्लिकेशन ने insertProviderAt() या removeProvider() के ज़रिए सूची में बदलाव न कर दिया हो. डिवाइसों पर, यहां दी गई सेवा देने वाली कंपनियों की सूची के बाद, अन्य सेवा देने वाली कंपनियों की जानकारी भी दिख सकती है.
  1. AndroidNSSP - android.security.net.config.NetworkSecurityConfigProvider
  2. AndroidOpenSSL - com.android.org.conscrypt.OpenSSLProvider
  3. CertPathProvider - sun.security.provider.CertPathProvider
  4. AndroidKeyStoreBCWorkaround - android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
  5. BC - com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
  6. HarmonyJSSE - com.android.org.conscrypt.JSSEProvider
  7. AndroidKeyStore - android.security.keystore.AndroidKeyStoreProvider

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

3.5.1. ऐप्लिकेशन पर पाबंदी

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

• [C-1-1] उपयोगकर्ता को पाबंदी वाले ऐप्लिकेशन की सूची देखने की अनुमति देनी चाहिए.
• [C-1-2] हर ऐप्लिकेशन पर, मालिकाना हक से जुड़ी इन सभी पाबंदियों को चालू या बंद करने के लिए, उपयोगकर्ता को सुविधा देना ज़रूरी है.

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

• [C-1-4] जब कोई उपयोगकर्ता ऐप्लिकेशन की पाबंदियों को मैन्युअल तरीके से बंद कर देता है, तो ऐप्लिकेशन के लिए ये मालिकाना पाबंदियां अपने-आप लागू नहीं होनी चाहिए. हालांकि, उपयोगकर्ता को इन मालिकाना पाबंदियों को लागू करने का सुझाव दिया जा सकता है.

• [C-1-5] अगर किसी ऐप्लिकेशन पर मालिकाना हक से जुड़ी ये पाबंदियां अपने-आप लागू होती हैं, तो उपयोगकर्ताओं को इसकी जानकारी देना ज़रूरी है. यह जानकारी, मालिकाना हक से जुड़ी इन पाबंदियों के लागू होने से पहले के 24 घंटे के अंदर दी जानी चाहिए.

• [C-1-6] किसी ऐप्लिकेशन से किए गए किसी भी एपीआई कॉल के लिए, ActivityManager.isBackgroundRestricted() मैथड के लिए 'सही' दिखाना ज़रूरी है.

• [C-1-7] फ़ोरग्राउंड में मौजूद उस ऐप्लिकेशन पर पाबंदी नहीं लगानी चाहिए जिसका इस्तेमाल उपयोगकर्ता साफ़ तौर पर करता है.

• [C-1-8] जब भी कोई उपयोगकर्ता ऐप्लिकेशन का साफ़ तौर पर इस्तेमाल करना शुरू करता है, तो ऐप्लिकेशन पर मालिकाना हक से जुड़ी ये पाबंदियां निलंबित करनी चाहिए. इससे ऐप्लिकेशन, फ़ोरग्राउंड में सबसे ऊपर दिखने वाला ऐप्लिकेशन बन जाता है.

• [C-1-10] सार्वजनिक और साफ़ तौर पर जानकारी देने वाला दस्तावेज़ या वेबसाइट देना ज़रूरी है. इसमें यह जानकारी होनी चाहिए कि मालिकाना हक से जुड़ी पाबंदियां कैसे लागू की जाती हैं. यह दस्तावेज़ या वेबसाइट, Android SDK के दस्तावेज़ों से लिंक की जानी चाहिए. साथ ही, इसमें ये चीज़ें शामिल होनी चाहिए:

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

अगर कोई ऐप्लिकेशन डिवाइस पर पहले से इंस्टॉल है और किसी उपयोगकर्ता ने 30 दिनों से ज़्यादा समय तक उसका इस्तेमाल नहीं किया है, तो [C-1-3] [C-1-5] से छूट मिलती है.

अगर डिवाइस में, AOSP में लागू की गई ऐप्लिकेशन पाबंदियों को बढ़ाया जाता है, तो:

• [C-2-1]इस दस्तावेज़ में बताए गए तरीके का पालन करना ज़रूरी है.

3.5.2. ऐप्लिकेशन का हाइबरनेशन मोड

अगर डिवाइस में, AOSP में शामिल ऐप्लिकेशन हाइबरनेट करने की सुविधा या AOSP में शामिल सुविधा को बेहतर बनाने की सुविधा शामिल है, तो:

• [C-1-1] को [C-1-6] और [C-1-3] को छोड़कर, सेक्शन 3.5.1 की सभी ज़रूरी शर्तें पूरी करनी होंगी.
• [C-1-2] किसी उपयोगकर्ता के लिए ऐप्लिकेशन पर पाबंदी सिर्फ़ तब लगानी चाहिए, जब इस बात का सबूत हो कि उपयोगकर्ता ने कुछ समय से ऐप्लिकेशन का इस्तेमाल नहीं किया है. हमारा सुझाव है कि आप इस अवधि को एक महीने या उससे ज़्यादा रखें. इस्तेमाल की जानकारी, UsageStats#getLastTimeVisible() एपीआई के ज़रिए उपयोगकर्ता के साफ़ तौर पर इंटरैक्ट करने या किसी ऐसे कॉम्पोनेंट के इस्तेमाल से मिलनी चाहिए जिसकी वजह से ऐप्लिकेशन को 'जबर्दस्ती बंद किया गया' स्टेटस से बाहर निकाला गया हो. इन कॉम्पोनेंट में, सेवा बाइंडिंग, कॉन्टेंट देने वाली कंपनी की बाइंडिंग, साफ़ तौर पर दिखाए जाने वाले ब्रॉडकास्ट वगैरह शामिल हैं. इनकी जानकारी, नए एपीआई UsageStats#getLastTimeAnyComponentUsed से ट्रैक की जाएगी.
• [C-1-3] डिवाइस के सभी उपयोगकर्ताओं पर असर डालने वाली पाबंदियां सिर्फ़ तब लागू की जानी चाहिए, जब इस बात का सबूत हो कि किसी उपयोगकर्ता ने कुछ समय तक पैकेज का इस्तेमाल नहीं किया है. हमारा सुझाव है कि यह अवधि एक महीने या उससे ज़्यादा होनी चाहिए.
• [C-1-4] ऐप्लिकेशन को गतिविधि के इंटेंट, सेवा बाइंडिंग, कॉन्टेंट देने वाले के अनुरोधों या साफ़ तौर पर ब्रॉडकास्ट किए जाने वाले कॉन्टेंट का जवाब देने में असमर्थ नहीं होना चाहिए.

AOSP में ऐप्लिकेशन हाइबरनेट करने की सुविधा, ऊपर दी गई ज़रूरी शर्तों को पूरा करती है.

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

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

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

इसका मतलब है कि वे:

• [C-0-1] Android प्लैटफ़ॉर्म पर सार्वजनिक तौर पर उपलब्ध एपीआई में बदलाव नहीं किया जाना चाहिए. इसके लिए, किसी भी मेथड या क्लास के हस्ताक्षर में बदलाव करना या क्लास या क्लास फ़ील्ड को हटाना ज़रूरी नहीं है.
• [C-0-2] ऊपर दिए गए नेमस्पेस में मौजूद एपीआई में, सार्वजनिक तौर पर दिखाए जाने वाले एलिमेंट (जैसे, क्लास या इंटरफ़ेस या मौजूदा क्लास या इंटरफ़ेस के फ़ील्ड या तरीके) या टेस्ट या सिस्टम एपीआई नहीं जोड़ने चाहिए. "सार्वजनिक तौर पर दिखाया गया एलिमेंट", ऐसा कोई भी कॉन्स्ट्रक्ट होता है जिसे "@hide" मार्कर से नहीं सजाया गया है. इस मार्कर का इस्तेमाल, अपस्ट्रीम Android सोर्स कोड में किया जाता है.

डिवाइस पर एपीआई लागू करने वाले लोग, एपीआई के लागू होने के तरीके में बदलाव कर सकते हैं. हालांकि, ऐसे बदलाव:

• [C-0-3] सार्वजनिक तौर पर उपलब्ध किसी भी एपीआई के बताए गए व्यवहार और Java-language के हस्ताक्षर पर असर नहीं डालना चाहिए.
• [C-0-4] इसका विज्ञापन नहीं किया जाना चाहिए या डेवलपर को किसी भी तरह से इसका ऐक्सेस नहीं दिया जाना चाहिए.

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

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

डिवाइस लागू करने वाले लोग, नेटिव भाषाओं में कस्टम एपीआई जोड़ सकते हैं. ये एपीआई, एनडीके एपीआई के बाहर के होते हैं. हालांकि, कस्टम एपीआई:

• [C-1-1] यह ज़रूरी है कि यह NDK लाइब्रेरी या किसी ऐसे संगठन की लाइब्रेरी में न हो जिसके बारे में यहां बताया गया है.

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

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

3.7. रनटाइम के साथ काम करने की सुविधा

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

• [C-0-1] यह पूरी तरह से Dalvik Executable (DEX) फ़ॉर्मैट और Dalvik बाइटकोड स्पेसिफ़िकेशन और सेमेंटेक्स के साथ काम करना चाहिए.

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

• Android RunTime (ART), Dalvik Executable Format के रेफ़रंस अपस्ट्रीम लागू करने के तरीके, और रेफ़रंस लागू करने के तरीके के पैकेज मैनेजमेंट सिस्टम का इस्तेमाल करना चाहिए.

• रनटाइम के स्थिर होने की पुष्टि करने के लिए, फ़ज़ टेस्ट को अलग-अलग तरीके से चलाना चाहिए और टारगेट किए गए आर्किटेक्चर का इस्तेमाल करना चाहिए. Android Open Source Project की वेबसाइट पर, JFuzz और DexFuzz के बारे में जानें.

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

स्क्रीन लेआउट	स्क्रीन की सघनता	ऐप्लिकेशन के लिए ज़रूरी मेमोरी
Android Watch	120 डीपीआई (ldpi)	32 एमबी
	140 डीपीआई (140dpi)
	160 डीपीआई (एमडीपीआई)
	180 डीपीआई (180dpi)
	200 डीपीआई (200dpi)
	213 डीपीआई (tvdpi)
	220 डीपीआई (220dpi)	36 एमबी
	240 डीपीआई (एचडीपीआई)
	280 डीपीआई (280dpi)
	320 डीपीआई (xhdpi)	48 एमबी
	360 डीपीआई (360dpi)
	400 डीपीआई (400dpi)	56 एमबी
	420 डीपीआई (420dpi)	64 एमबी
	480 डीपीआई (xxhdpi)	88 एमबी
	560 डीपीआई (560dpi)	112 एमबी
	640 डीपीआई (xxxhdpi)	154 एमबी
छोटा/सामान्य	120 डीपीआई (ldpi)	32 एमबी
	140 डीपीआई (140dpi)
	160 डीपीआई (एमडीपीआई)
	180 डीपीआई (180dpi)	48 एमबी
	200 डीपीआई (200dpi)
	213 डीपीआई (tvdpi)
	220 डीपीआई (220dpi)
	240 डीपीआई (एचडीपीआई)
	280 डीपीआई (280dpi)
	320 डीपीआई (xhdpi)	80 एमबी
	360 डीपीआई (360dpi)
	400 डीपीआई (400dpi)	96 एमबी
	420 डीपीआई (420dpi)	112 एमबी
	480 डीपीआई (xxhdpi)	128 एमबी
	560 डीपीआई (560dpi)	192 एमबी
	640 डीपीआई (xxxhdpi)	256 एमबी
बड़ा	120 डीपीआई (ldpi)	32 एमबी
	140 डीपीआई (140dpi)	48 एमबी
	160 डीपीआई (एमडीपीआई)
	180 डीपीआई (180dpi)	80 एमबी
	200 डीपीआई (200dpi)
	213 डीपीआई (tvdpi)
	220 डीपीआई (220dpi)
	240 डीपीआई (एचडीपीआई)
	280 डीपीआई (280dpi)	96 एमबी
	320 डीपीआई (xhdpi)	128 एमबी
	360 डीपीआई (360dpi)	160 एमबी
	400 डीपीआई (400dpi)	192 एमबी
	420 डीपीआई (420dpi)	228 एमबी
	480 डीपीआई (xxhdpi)	256 एमबी
	560 डीपीआई (560dpi)	384 एमबी
	640 डीपीआई (xxxhdpi)	512 एमबी
xlarge	120 डीपीआई (ldpi)	48 एमबी
	140 डीपीआई (140dpi)	80 एमबी
	160 डीपीआई (एमडीपीआई)
	180 डीपीआई (180dpi)	96 एमबी
	200 डीपीआई (200dpi)
	213 डीपीआई (tvdpi)
	220 डीपीआई (220dpi)
	240 डीपीआई (एचडीपीआई)
	280 डीपीआई (280dpi)	144 एमबी
	320 डीपीआई (xhdpi)	192 एमबी
	360 डीपीआई (360dpi)	240 एमबी
	400 डीपीआई (400dpi)	288 एमबी
	420 डीपीआई (420dpi)	336 एमबी
	480 डीपीआई (xxhdpi)	384 एमबी
	560 डीपीआई (560dpi)	576 एमबी
	640 डीपीआई (xxxhdpi)	768 एमबी

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

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

Android में एक लॉन्चर ऐप्लिकेशन (होम स्क्रीन) होता है. साथ ही, डिवाइस के लॉन्चर (होम स्क्रीन) की जगह लेने के लिए, तीसरे पक्ष के ऐप्लिकेशन इस्तेमाल किए जा सकते हैं.

अगर डिवाइस में तीसरे पक्ष के ऐप्लिकेशन को डिवाइस की होम स्क्रीन बदलने की अनुमति है, तो वे:

• [C-1-1] प्लैटफ़ॉर्म की सुविधा android.software.home_screen के बारे में एलान करना ज़रूरी है.
• [C-1-2] जब तीसरे पक्ष का ऐप्लिकेशन अपना आइकॉन देने के लिए <adaptive-icon> टैग का इस्तेमाल करता है और आइकॉन वापस पाने के लिए PackageManager तरीकों को कॉल किया जाता है, तो AdaptiveIconDrawable ऑब्जेक्ट को दिखाना ज़रूरी है.

अगर डिवाइस में कोई ऐसा डिफ़ॉल्ट लॉन्चर है जो ऐप्लिकेशन में शॉर्टकट पिन करने की सुविधा देता है, तो:

• [C-2-1] ShortcutManager.isRequestPinShortcutSupported() के लिए, true की रिपोर्ट करना ज़रूरी है.
• [C-2-2] ShortcutManager.requestPinShortcut() API के ज़रिए, ऐप्लिकेशन के अनुरोध किए गए शॉर्टकट को जोड़ने से पहले, उपयोगकर्ता से पूछने के लिए यूज़र अफ़र्डेंस होना चाहिए.
• [C-2-3] ऐप्लिकेशन के शॉर्टकट पेज पर बताए गए तरीके के मुताबिक, पिन किए गए शॉर्टकट, डाइनैमिक, और स्टैटिक शॉर्टकट के साथ काम करना चाहिए.

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

• [C-3-1] ShortcutManager.isRequestPinShortcutSupported() के लिए, false की रिपोर्ट करना ज़रूरी है.

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

• [C-4-1] यह ज़रूरी है कि ऐप्लिकेशन में, दस्तावेज़ में बताई गई शॉर्टकट की सभी सुविधाएं काम करती हों.जैसे, स्टैटिक और डाइनैमिक शॉर्टकट, पिन किए गए शॉर्टकट वगैरह. साथ ही, यह ज़रूरी है कि ऐप्लिकेशन में ShortcutManager एपीआई क्लास के एपीआई पूरी तरह से लागू हों.

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

• [C-5-1] NotificationChannel.setShowBadge() के एपीआई तरीके का पालन करना ज़रूरी है. दूसरे शब्दों में, अगर वैल्यू true के तौर पर सेट है, तो ऐप्लिकेशन आइकॉन से जुड़ा विज़ुअल अवफ़र्डेंस दिखाएं. साथ ही, जब ऐप्लिकेशन के सभी सूचना चैनलों ने वैल्यू को false के तौर पर सेट किया हो, तो ऐप्लिकेशन आइकॉन की बैजिंग स्कीम न दिखाएं.
• जब तीसरे पक्ष के ऐप्लिकेशन, मालिकाना हक वाले एपीआई का इस्तेमाल करके, मालिकाना हक वाले बैजिंग स्कीम के साथ काम करने की जानकारी देते हैं, तो ऐप्लिकेशन आइकॉन के बैज को अपने मालिकाना हक वाले बैजिंग स्कीम से बदला जा सकता है. हालांकि, SDK टूल में बताए गए सूचना बैज एपीआई के ज़रिए दिए गए संसाधनों और वैल्यू का इस्तेमाल करना चाहिए. जैसे, Notification.Builder.setNumber() और Notification.Builder.setBadgeIconType() एपीआई.

अगर डिवाइस पर मोनोक्रोम आइकॉन इस्तेमाल किए जा सकते हैं, तो ये आइकॉन:

• [C-6-1] का इस्तेमाल सिर्फ़ तब किया जाना चाहिए, जब कोई उपयोगकर्ता साफ़ तौर पर उन्हें चालू करता है. उदाहरण के लिए, सेटिंग या वॉलपेपर पिकर मेन्यू के ज़रिए.

3.8.2. विजेट

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

अगर डिवाइस पर तीसरे पक्ष के ऐप्लिकेशन के विजेट काम करते हैं, तो:

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

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

• [C-2-1] AppWidgetManager.html.isRequestPinAppWidgetSupported() के लिए, true की रिपोर्ट करना ज़रूरी है.
• [C-2-2] AppWidgetManager.requestPinAppWidget() API के ज़रिए, ऐप्लिकेशन के अनुरोध किए गए शॉर्टकट को जोड़ने से पहले, उपयोगकर्ता से पूछने के लिए यूज़र अफ़र्डेंस होना चाहिए.

3.8.3. सूचनाएं

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

3.8.3.1. सूचनाओं का प्रज़ेंटेशन

अगर डिवाइस पर लागू किए गए तरीकों से, तीसरे पक्ष के ऐप्लिकेशन को उल्लेखनीय इवेंट के बारे में उपयोगकर्ताओं को सूचना देने की अनुमति मिलती है, तो वे:

• [C-1-1] SDK टूल के दस्तावेज़ में बताए गए तरीके के मुताबिक, हार्डवेयर की सुविधाओं का इस्तेमाल करने वाली सूचनाओं के साथ काम करना चाहिए. साथ ही, यह डिवाइस में लागू किए गए हार्डवेयर के साथ भी काम करना चाहिए. उदाहरण के लिए, अगर किसी डिवाइस में वाइब्रेटर शामिल है, तो उसे वाइब्रेशन एपीआई को सही तरीके से लागू करना होगा. अगर किसी डिवाइस पर एपीआई लागू करने के लिए ज़रूरी हार्डवेयर मौजूद नहीं है, तो उससे जुड़े एपीआई को नो-ऑप के तौर पर लागू करना ज़रूरी है. इस व्यवहार के बारे में ज़्यादा जानकारी सेक्शन 7 में दी गई है.
• [C-1-2] एपीआई या स्टेटस/सिस्टम बार के आइकॉन स्टाइल गाइड में दिए गए सभी रिसॉर्स (आइकॉन, ऐनिमेशन फ़ाइलें वगैरह) को सही तरीके से रेंडर करना ज़रूरी है. हालांकि, हो सकता है कि वे सूचनाओं के लिए, रेफ़रंस के तौर पर दिए गए Android Open Source के मुकाबले, उपयोगकर्ता को अलग अनुभव दें.
• [C-1-3] सूचनाओं को अपडेट करने, हटाने, और ग्रुप करने के लिए, एपीआई के लिए बताए गए व्यवहारों को सही तरीके से लागू करना ज़रूरी है.
• [C-1-4] SDK टूल में दिए गए NotificationChannel एपीआई के पूरे व्यवहार की जानकारी देना ज़रूरी है.
• [C-1-5] उपयोगकर्ता को यह सुविधा देनी चाहिए कि वह हर चैनल और ऐप्लिकेशन पैकेज के लेवल पर, तीसरे पक्ष के किसी ऐप्लिकेशन की सूचना को ब्लॉक कर सके और उसमें बदलाव कर सके.
• [C-1-6] मिटाए गए सूचना चैनलों को दिखाने के लिए, उपयोगकर्ता को सुविधा भी देनी होगी.
• [C-1-7] Notification.MessagingStyle के ज़रिए दिए गए सभी संसाधनों (इमेज, स्टिकर, आइकॉन वगैरह) को सही तरीके से रेंडर करना चाहिए.साथ ही, सूचना के टेक्स्ट के साथ-साथ, उपयोगकर्ता को कोई और इंटरैक्शन किए बिना रेंडर करना चाहिए. उदाहरण के लिए, setGroupConversation के ज़रिए सेट की गई ग्रुप बातचीत में, android.app.Person के ज़रिए दिए गए आइकॉन के साथ-साथ सभी रिसॉर्स दिखाना ज़रूरी है.
• [C-SR-1] हमारा सुझाव है कि उपयोगकर्ता को सूचना सुनने की अनुमति वाले ऐप्लिकेशन को भेजी जाने वाली सूचनाओं को कंट्रोल करने की सुविधा दें. यह ज़रूरी है कि उपयोगकर्ता, हर सूचना सुनने वाले के लिए यह कंट्रोल कर सके कि इस सुनने वाले को किस तरह की सूचनाएं भेजी जाएं. इनमें "बातचीत", "सूचनाएं", "साइलेंट", और "मौजूदा ज़रूरी" सूचनाएं शामिल होनी चाहिए.
• [C-SR-2] हमारा सुझाव है कि उपयोगकर्ताओं को यह तय करने का विकल्प दें कि किन ऐप्लिकेशन को सूचना सुनने वाले किसी खास ऐप्लिकेशन को सूचना देने से बाहर रखना है.
• [C-SR-3] हमारा सुझाव है कि जब उपयोगकर्ता किसी सूचना को कई बार खारिज कर दे, तो हर चैनल और ऐप्लिकेशन पैकेज के लेवल पर, तीसरे पक्ष के किसी ऐप्लिकेशन की सूचना को ब्लॉक करने के लिए, उपयोगकर्ता को अपने-आप एक विकल्प दिखे.
• रिच सूचनाओं के साथ काम करना चाहिए.
• ज़्यादा प्राथमिकता वाली कुछ सूचनाओं को स्क्रीन पर सबसे ऊपर सूचना देने वाले कार्ड के तौर पर दिखाना चाहिए.
• सूचनाओं को स्नूज़ करने के लिए, उपयोगकर्ता के पास विकल्प होना चाहिए.
• तीसरे पक्ष के ऐप्लिकेशन, उपयोगकर्ताओं को अहम इवेंट की सूचना कब दे सकते हैं, यह मैनेज किया जा सकता है. इससे ड्राइवर का ध्यान भटकने जैसी सुरक्षा से जुड़ी समस्याओं को कम करने में मदद मिलती है.

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

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

• [C-SR-4] हमारा सुझाव है कि आप conversation notifications को ग्रुप में डालें और उसे बातचीत से जुड़ी सूचनाओं के बजाय पहले दिखाएं. हालांकि, फ़ोरग्राउंड सेवा की सूचनाओं और importance:high की सूचनाओं को छोड़कर.

अगर डिवाइस पर conversation notifications को लागू करने की सुविधा उपलब्ध है और ऐप्लिकेशन, bubbles के लिए ज़रूरी डेटा उपलब्ध कराता है, तो:

• [C-SR-5] हमारा सुझाव है कि इस बातचीत को बबल के तौर पर दिखाया जाए. AOSP के लागू होने से, डिफ़ॉल्ट सिस्टम यूज़र इंटरफ़ेस, सेटिंग, और लॉन्चर की मदद से ये ज़रूरी शर्तें पूरी होती हैं.

अगर डिवाइस पर रिच नोटिफ़िकेशन की सुविधा काम करती है, तो:

• [C-2-1] Notification.Style एपीआई क्लास और उसके सबक्लास के ज़रिए दिए गए संसाधनों का इस्तेमाल करना ज़रूरी है.
• Notification.Style एपीआई क्लास और उसकी सबक्लास में बताए गए हर संसाधन एलिमेंट (जैसे, आइकॉन, टाइटल, और खास जानकारी वाला टेक्स्ट) को दिखाना चाहिए.

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

• [C-3-1] हेड-अप सूचनाएं दिखाने के लिए, Notification.Builder एपीआई क्लास में बताए गए हेड-अप सूचना व्यू और संसाधनों का इस्तेमाल करना ज़रूरी है.
• [C-3-2] SDK टूल में बताए गए तरीके के मुताबिक, सूचना के कॉन्टेंट के साथ-साथ, Notification.Builder.addAction() के ज़रिए दी गई कार्रवाइयां भी दिखनी चाहिए. इसके लिए, उपयोगकर्ता को कोई और इंटरैक्शन नहीं करना चाहिए.

3.8.3.2. सूचना सुनने की सुविधा

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

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

• [C-0-1] ऐप्लिकेशन को, इंस्टॉल की गई और उपयोगकर्ता की ओर से चालू की गई सभी लिसनर सेवाओं के लिए, सूचनाओं को सही तरीके से और तुरंत अपडेट करना ज़रूरी है. इसमें, सूचना ऑब्जेक्ट से जुड़ा कोई भी और पूरा मेटाडेटा शामिल है.
• [C-0-2] snoozeNotification() एपीआई कॉल का पालन करना चाहिए. साथ ही, सूचना को खारिज करना चाहिए और एपीआई कॉल में सेट की गई स्नूज़ अवधि के बाद कॉलबैक करना चाहिए.

अगर डिवाइस पर सूचनाएं स्नूज़ करने की सुविधा उपलब्ध है, तो:

• [C-1-1] NotificationListenerService.getSnoozedNotifications() जैसे स्टैंडर्ड एपीआई के ज़रिए, स्नूज़ की गई सूचना की स्थिति को सही तरीके से दिखाना ज़रूरी है.
• [C-1-2] तीसरे पक्ष के हर इंस्टॉल किए गए ऐप्लिकेशन की सूचनाओं को स्नूज़ करने के लिए, यह सुविधा उपलब्ध कराना ज़रूरी है. हालांकि, यह ज़रूरी नहीं है कि यह सुविधा, हमेशा चालू रहने वाली/फ़ोरग्राउंड सेवाओं के लिए उपलब्ध हो.

3.8.3.3. परेशान न करें (डीएनडी)/ प्राथमिकता मोड

अगर डिवाइस पर डीएनडी मोड (इसे प्राथमिकता मोड भी कहा जाता है) की सुविधा काम करती है, तो:

• [C-1-1] डिवाइस में, उपयोगकर्ता को 'परेशान न करें' नीति के कॉन्फ़िगरेशन को ऐक्सेस करने के लिए, तीसरे पक्ष के ऐप्लिकेशन को अनुमति देने या अनुमति न देने का विकल्प दिया गया हो. ऐसे में, उपयोगकर्ता के बनाए गए और पहले से तय नियमों के साथ-साथ, ऐप्लिकेशन के बनाए गए परेशान न करें मोड के अपने-आप लागू होने वाले नियम दिखाना ज़रूरी है.
• [C-1-3] NotificationManager.Policy के साथ भेजी गई suppressedVisualEffects वैल्यू का पालन करना ज़रूरी है. अगर किसी ऐप्लिकेशन ने SUPPRESSED_EFFECT_SCREEN_OFF या SUPPRESSED_EFFECT_SCREEN_ON फ़्लैग में से कोई एक सेट किया है, तो उसे उपयोगकर्ता को यह बताना चाहिए कि 'परेशान न करें' सेटिंग मेन्यू में विज़ुअल इफ़ेक्ट बंद हैं.

3.8.4. Assist API

Android में Assist API शामिल हैं, ताकि ऐप्लिकेशन यह चुन सकें कि डिवाइस पर Assistant के साथ मौजूदा कॉन्टेक्स्ट की कितनी जानकारी शेयर की जाए.

अगर डिवाइस पर Assist ऐक्शन की सुविधा काम करती है, तो:

• [C-2-1] असली उपयोगकर्ता को साफ़ तौर पर यह बताना ज़रूरी है कि कॉन्टेक्स्ट कब शेयर किया गया है. इसके लिए, इनमें से कोई एक तरीका अपनाएं:
  • जब भी सहायक ऐप्लिकेशन कॉन्टेक्स्ट को ऐक्सेस करता है, तो स्क्रीन के किनारों के आस-पास एक सफ़ेद रोशनी दिखती है. यह रोशनी, Android Open Source Project के लागू होने की अवधि और चमक के बराबर या उससे ज़्यादा होती है.
  • पहले से इंस्टॉल किए गए असिस्ट ऐप्लिकेशन के लिए, उपयोगकर्ता को डिफ़ॉल्ट वॉइस इनपुट और असिस्ट ऐप्लिकेशन के सेटिंग मेन्यू से दो नेविगेशन से कम की दूरी पर, उपयोगकर्ता के लिए आसानी से ऐक्सेस करने की सुविधा उपलब्ध कराना. साथ ही, सिर्फ़ तब संदर्भ शेयर करना, जब उपयोगकर्ता ने हॉटवर्ड या असिस्ट नेविगेशन बटन के इनपुट की मदद से, असिस्ट ऐप्लिकेशन को साफ़ तौर पर चालू किया हो.
• [C-2-2] सेक्शन 7.2.3 में बताए गए तरीके से, असिस्ट ऐप्लिकेशन को लॉन्च करने के लिए तय किया गया इंटरैक्शन, उपयोगकर्ता के चुने गए असिस्ट ऐप्लिकेशन को लॉन्च करना चाहिए. दूसरे शब्दों में, वह ऐप्लिकेशन जो VoiceInteractionService को लागू करता है या ACTION_ASSIST इंटेंट को मैनेज करने वाली गतिविधि.

3.8.5. सूचनाएं और टॉस्ट

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

अगर डिवाइस में स्क्रीन या वीडियो आउटपुट शामिल है, तो:

• [C-1-1] ऐप्लिकेशन को TYPE_APPLICATION_OVERLAY का इस्तेमाल करके सूचना वाली विंडो दिखाने से रोकने के लिए, उपयोगकर्ता को कोई सुविधा देनी होगी. AOSP के तहत, सूचना शेड में कंट्रोल होने की वजह से यह ज़रूरी शर्त पूरी हो जाती है.

• [C-1-2] ऐप्लिकेशन को Toast API का इस्तेमाल करना चाहिए. साथ ही, ऐप्लिकेशन से असली उपयोगकर्ताओं को, साफ़ तौर पर दिखने वाले तरीके से सूचनाएं दिखानी चाहिए.

3.8.6. थीम

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

Android में “Holo” और "Material" थीम फ़ैमिली शामिल है. यह, तय की गई स्टाइल के सेट के तौर पर होती है. ऐप्लिकेशन डेवलपर इसका इस्तेमाल तब कर सकते हैं, जब उन्हें Android SDK टूल में बताई गई Holo थीम के लुक और स्टाइल से मैच करना हो.

अगर डिवाइस में स्क्रीन या वीडियो आउटपुट शामिल है, तो:

• [C-1-1] ऐप्लिकेशन के लिए उपलब्ध Holo थीम एट्रिब्यूट में बदलाव नहीं किया जाना चाहिए.
• [C-1-2] यह “Material” थीम फ़ैमिली के साथ काम करना चाहिए. साथ ही, Material थीम एट्रिब्यूट या ऐप्लिकेशन के लिए उपलब्ध कराई गई उनकी ऐसेट में कोई बदलाव नहीं करना चाहिए.

• [C-1-3] "sans-serif" फ़ॉन्ट फ़ैमिली को, Roboto के साथ काम करने वाली भाषाओं के लिए, Roboto वर्शन 2.x पर सेट करना ज़रूरी है. इसके अलावा, उपयोगकर्ता को "sans-serif" फ़ॉन्ट फ़ैमिली के लिए इस्तेमाल किए गए फ़ॉन्ट को, Roboto के साथ काम करने वाली भाषाओं के लिए, Roboto वर्शन 2.x पर बदलने का विकल्प देना ज़रूरी है.

• [C-1-4] Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES के AOSP दस्तावेज़ में बताए गए तरीके के मुताबिक, डाइनैमिक कलर टोन वाले पैलेट जनरेट करने चाहिए (android.theme.customization.system_palette और android.theme.customization.theme_style देखें).

• [C-1-5] Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGESदस्तावेज़ (android.theme.customization.theme_styles देखें) में बताई गई कलर थीम स्टाइल का इस्तेमाल करके, डाइनैमिक कलर टनल पैलेट जनरेट करने चाहिए. जैसे, TONAL_SPOT, VIBRANT, EXPRESSIVE, SPRITZ, RAINBOW, FRUIT_SALAD.

  "सोर्स कलर" का इस्तेमाल, डाइनैमिक कलर टोन वाले पैलेट जनरेट करने के लिए किया जाता है. ऐसा तब किया जाता है, जब इसे android.theme.customization.system_palette के साथ भेजा जाता है (जैसा कि Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES में बताया गया है).

• [C-1-6] CAM16 की क्रोमा वैल्यू 5 या उससे ज़्यादा होनी चाहिए.

  • com.android.systemui.monet.ColorScheme#getSeedColors के ज़रिए वॉलपेपर से लिया जाना चाहिए. इससे, एक को चुनने के लिए कई मान्य सोर्स कलर मिलते हैं.

  • अगर दिए गए रंगों में से कोई भी रंग, सोर्स के रंग से जुड़ी ऊपर दी गई ज़रूरी शर्त को पूरा नहीं करता है, तो 0xFF1B6EF3 वैल्यू का इस्तेमाल करना चाहिए.

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

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

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

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

• [C-2-1] सिस्टम के स्टेटस आइकॉन (जैसे, सिग्नल की क्षमता और बैटरी लेवल) और सिस्टम से मिलने वाली सूचनाओं के लिए, सफ़ेद रंग का इस्तेमाल करना ज़रूरी है. हालांकि, ऐसा तब तक नहीं किया जाना चाहिए, जब तक आइकॉन से किसी समस्या का पता न चल रहा हो या कोई ऐप्लिकेशन, WindowInsetsController#APPEARANCE_LIGHT_STATUS_BARS फ़्लैग का इस्तेमाल करके, लाइट स्टेटस बार का अनुरोध न कर रहा हो.
• [C-2-2] जब कोई ऐप्लिकेशन हल्के रंग के स्टेटस बार का अनुरोध करता है, तो Android डिवाइस के लागू होने पर, सिस्टम के स्टेटस आइकॉन का रंग काला होना चाहिए. ज़्यादा जानकारी के लिए, R.style देखें.

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

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

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

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

अगर डिवाइस पर लाइव वॉलपेपर लागू किए जाते हैं, तो:

• [C-1-1] प्लैटफ़ॉर्म की सुविधा के फ़्लैग android.software.live_wallpaper की जानकारी देना ज़रूरी है.

3.8.8. गतिविधि स्विच करना

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

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

अगर डिवाइस में हाल ही के ऐप्लिकेशन के नेविगेशन बटन के साथ-साथ, सेक्शन 7.2.3 में बताई गई अन्य सुविधाएं लागू करने पर इंटरफ़ेस में बदलाव होता है, तो:

• [C-1-1] कम से कम सात गतिविधियां दिखाई जानी चाहिए.
• इसमें कम से कम चार गतिविधियों का टाइटल एक साथ दिखना चाहिए.
• [C-1-2] स्क्रीन पिन करने की सुविधा को लागू करना ज़रूरी है. साथ ही, उपयोगकर्ता को इस सुविधा को टॉगल करने के लिए, सेटिंग मेन्यू उपलब्ध कराना ज़रूरी है.
• हाल ही में इस्तेमाल किए गए आइटम में, हाइलाइट का रंग, आइकॉन, और स्क्रीन का टाइटल दिखना चाहिए.
• इसमें बंद करने का विकल्प ("x") दिखना चाहिए. हालांकि, उपयोगकर्ता के स्क्रीन से इंटरैक्ट करने तक इसे दिखाने में देरी की जा सकती है.
• पिछली गतिविधि पर आसानी से स्विच करने के लिए, शॉर्टकट लागू करना चाहिए.
• हाल ही में इस्तेमाल किए गए फ़ंक्शन बटन पर दो बार टैप करने पर, हाल ही में इस्तेमाल किए गए दो ऐप्लिकेशन के बीच तुरंत स्विच करने की सुविधा चालू होनी चाहिए.
• अगर डिवाइस में स्प्लिट-स्क्रीन मल्टीविंडो मोड की सुविधा काम करती है, तो हाल ही के फ़ंक्शन की बटन को दबाकर रखने पर, यह मोड चालू हो जाना चाहिए.
• हाल ही में देखे गए ऐसे वीडियो को एक ग्रुप के तौर पर दिखाया जा सकता है जो एक साथ चलते हैं.
• [C-SR-1] हमारा सुझाव है कि खास जानकारी वाली स्क्रीन के लिए, अपस्ट्रीम Android यूज़र इंटरफ़ेस (या थंबनेल पर आधारित मिलते-जुलते इंटरफ़ेस) का इस्तेमाल करें.

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

Android में, इनपुट मैनेजमेंट और तीसरे पक्ष के इनपुट के तरीके के एडिटर के लिए सहायता शामिल है.

अगर डिवाइस पर, उपयोगकर्ताओं को तीसरे पक्ष के इनपुट तरीकों का इस्तेमाल करने की अनुमति है, तो वे:

• [C-1-1] Android SDK के दस्तावेज़ में बताए गए मुताबिक, प्लैटफ़ॉर्म की सुविधा android.software.input_methods का एलान करना ज़रूरी है. साथ ही, IME API के साथ काम करना ज़रूरी है.

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

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

3.8.11. स्क्रीन सेवर (पहले इन्हें ड्रीम्स कहा जाता था)

स्क्रीन सेवर को कॉन्फ़िगर करने के लिए, सेटिंग के इंटेंट के बारे में जानने के लिए सेक्शन 3.2.3.5 देखें.

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

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

• [C-1-2] सेटिंग में मौजूद जगह की जानकारी वाले मेन्यू में, जगह की जानकारी का मौजूदा स्टेटस दिखाना ज़रूरी है.
• [C-1-3] सेटिंग में जगह की जानकारी वाले मेन्यू में, जगह की जानकारी के मोड नहीं दिखाए जाने चाहिए.

3.8.13. यूनिकोड और फ़ॉन्ट

Android में, यूनिकोड 10.0 में बताए गए इमोजी वर्णों के इस्तेमाल की सुविधा शामिल है.

अगर डिवाइस में स्क्रीन या वीडियो आउटपुट शामिल है, तो:

• [C-1-1] इन इमोजी वर्ण को कलर ग्लिफ़ में रेंडर करने की सुविधा होनी चाहिए.
• [C-1-2] इसमें इनके लिए सहायता शामिल होनी चाहिए:
  • डिवाइस पर उपलब्ध भाषाओं के लिए, अलग-अलग वेट वाला Roboto 2 फ़ॉन्ट—sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed, sans-serif-condensed-light.
  • यूनिकोड 7.0 में, लैटिन, ग्रीक, और सिरिलिक भाषाओं के लिए पूरी कवरेज. इसमें लैटिन एक्सटेंडेड A, B, C, और D रेंज के साथ-साथ, यूनिकोड 7.0 के मुद्रा के चिह्नों वाले ब्लॉक में मौजूद सभी ग्लिफ़ शामिल हैं.
• [C-1-3] सिस्टम इमेज में NotoColorEmoji.tff को न तो हटाएं और न ही उसमें बदलाव करें. (NotoColorEmoji.tff में मौजूद इमोजी को बदलने के लिए, नया इमोजी फ़ॉन्ट जोड़ा जा सकता है)
• यूनिकोड तकनीकी रिपोर्ट #51 में बताए गए मुताबिक, स्किन टोन और अलग-अलग फ़ैमिली इमोजी के साथ काम करना चाहिए.

अगर डिवाइस में लागू किए गए IME में कोई IME शामिल है, तो:

• इन इमोजी वर्ण के लिए, उपयोगकर्ता को इनपुट का तरीका उपलब्ध कराना चाहिए.

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

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

• [C-2-1] टेक्स्ट को डिफ़ॉल्ट रूप से यूनिकोड फ़ॉन्ट में रेंडर करना चाहिए. ऐसा तब तक नहीं किया जाना चाहिए, जब तक कि उपयोगकर्ता भाषा चुनने वाले टूल में किसी दूसरे फ़ॉन्ट को न चुन ले.
• [C-2-2] डिवाइस पर यूनिकोड फ़ॉन्ट के साथ-साथ, ऐसे फ़ॉन्ट का भी इस्तेमाल किया जा सकता है जो यूनिकोड के साथ काम नहीं करता. यूनिकोड के मुताबिक न बने फ़ॉन्ट को, यूनिकोड फ़ॉन्ट को न तो हटाना चाहिए और न ही उस पर ओवरराइट करना चाहिए.
• [C-2-3] टेक्स्ट को ऐसे फ़ॉन्ट में रेंडर करना ज़रूरी है जो यूनिकोड के मुताबिक न हो. ऐसा सिर्फ़ तब करना चाहिए, जब स्क्रिप्ट कोड Qaag वाला भाषा कोड (उदाहरण के लिए, my-Qaag) दिया गया हो. म्यांमार के लिए, यूनिकोड के मुताबिक न होने वाले फ़ॉन्ट का रेफ़रंस देने के लिए, किसी भी अन्य ISO भाषा या इलाके के कोड (चाहे असाइन किए गए हों, असाइन नहीं किए गए हों या रिज़र्व किए गए हों) का इस्तेमाल नहीं किया जा सकता. ऐप्लिकेशन डेवलपर और वेब पेज के लेखक, my-Qaag को भाषा के लिए तय किए गए कोड के तौर पर बता सकते हैं, जैसे कि वे किसी दूसरी भाषा के लिए बताते हैं.

3.8.14. मल्टी-विंडो (एक से ज़्यादा ऐप्लिकेशन, एक साथ)

अगर डिवाइस पर एक साथ कई गतिविधियां दिख सकती हैं, तो:

• [C-1-1] Android SDK के मल्टी-विंडो मोड के लिए सहायता दस्तावेज़ में बताए गए ऐप्लिकेशन के व्यवहार और एपीआई के मुताबिक, ऐसे मल्टी-विंडो मोड लागू करना ज़रूरी है. साथ ही, इन ज़रूरी शर्तों को पूरा करना ज़रूरी है:
• [C-1-2] इस SDK टूल में बताए गए तरीके के मुताबिक, AndroidManifest.xml फ़ाइल में ऐप्लिकेशन से सेट की गई android:resizeableActivity का पालन करना ज़रूरी है.
• [C-1-3] अगर स्क्रीन की ऊंचाई 440 dp और चौड़ाई 440 dp से कम है, तो स्प्लिट-स्क्रीन या फ़्रीफ़ॉर्म मोड की सुविधा नहीं दी जानी चाहिए.
• [C-1-4] किसी गतिविधि का साइज़, पिक्चर में पिक्चर मोड के अलावा, कई विंडो वाले मोड में 220dp से कम नहीं होना चाहिए.
• स्क्रीन साइज़ xlarge वाले डिवाइसों पर, फ़्रीफ़ॉर्म मोड काम करना चाहिए.

अगर डिवाइस पर मल्टी-विंडो मोड और स्प्लिट स्क्रीन मोड काम करते हैं, तो:

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

अगर डिवाइस पर मल्टी-विंडो मोड और पिक्चर में पिक्चर वाले मल्टी-विंडो मोड काम करते हैं, तो:

• [C-3-1] ऐप्लिकेशन के इन स्थितियों में, गतिविधियों को पिक्चर में पिक्चर वाले मल्टी-विंडो मोड में लॉन्च करना ज़रूरी है: * ऐप्लिकेशन, एपीआई लेवल 26 या उसके बाद के वर्शन को टारगेट करता हो और android:supportsPictureInPicture का एलान करता हो * ऐप्लिकेशन, एपीआई लेवल 25 या उससे पहले के वर्शन को टारगेट करता हो और android:resizeableActivity और android:supportsPictureInPicture, दोनों का एलान करता हो.
• [C-3-2] setActions() API के ज़रिए, मौजूदा पीआईपी गतिविधि के मुताबिक, अपने SystemUI में ऐक्शन दिखाना ज़रूरी है.
• [C-3-3] आसपेक्ट रेशियो 1:2.39 से ज़्यादा या उसके बराबर और 2.39:1 से कम या उसके बराबर होना चाहिए. जैसा कि setAspectRatio() एपीआई के ज़रिए पीआईपी गतिविधि में बताया गया है.
• [C-3-4] पीआईपी विंडो को कंट्रोल करने के लिए, KeyEvent.KEYCODE_WINDOW का इस्तेमाल करना ज़रूरी है. अगर पीआईपी मोड लागू नहीं किया गया है, तो फ़ोरग्राउंड गतिविधि के लिए बटन उपलब्ध होना चाहिए.
• [C-3-5] उपयोगकर्ता को यह सुविधा देनी चाहिए कि वह किसी ऐप्लिकेशन को पीआईपी मोड में दिखने से रोक सके. AOSP में, सूचना शेड में कंट्रोल होने की वजह से यह ज़रूरी शर्त पूरी हो जाती है.

• [C-3-6] अगर कोई ऐप्लिकेशन AndroidManifestLayout_minWidth और AndroidManifestLayout_minHeight के लिए कोई वैल्यू नहीं तय करता है, तो पीआईपी विंडो के लिए कम से कम यह चौड़ाई और ऊंचाई तय करना ज़रूरी है:

  • जिन डिवाइसों में Configuration.uiMode की वैल्यू, UI_MODE_TYPE_TELEVISION के अलावा किसी दूसरी वैल्यू पर सेट है उनके लिए, कम से कम 108 डीपी की चौड़ाई और ऊंचाई तय करना ज़रूरी है.
  • जिन डिवाइसों में Configuration.uiMode को UI_MODE_TYPE_TELEVISION पर सेट किया गया है उनके लिए, कम से कम 240 dp चौड़ाई और 135 dp ऊंचाई का फ़्रेम तय करना ज़रूरी है.

3.8.15. डिसप्ले कटआउट

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

अगर डिवाइस में डिसप्ले कटआउट शामिल हैं, तो:

• [C-1-5] अगर डिवाइस का आसपेक्ट रेशियो 1.0(1:1) है, तो उसमें कोई कटआउट नहीं होना चाहिए.
• [C-1-2] हर किनारे पर एक से ज़्यादा कट्सआउट नहीं होने चाहिए.
• [C-1-3] ऐप्लिकेशन को, डिसप्ले में काट-छांट करने के लिए, WindowManager.LayoutParams एपीआई के ज़रिए सेट किए गए फ़्लैग का पालन करना चाहिए. इस बारे में एसडीके में बताया गया है.
• [C-1-4] DisplayCutout एपीआई में तय की गई सभी कटआउट मेट्रिक के लिए, सही वैल्यू रिपोर्ट करना ज़रूरी है.

3.8.16. डिवाइस कंट्रोल

Android में ControlsProviderService और Control एपीआई शामिल हैं. इनकी मदद से, तीसरे पक्ष के ऐप्लिकेशन, डिवाइस के कंट्रोल पब्लिश कर सकते हैं, ताकि उपयोगकर्ताओं को डिवाइस की स्थिति और कार्रवाई के बारे में तुरंत जानकारी मिल सके.

डिवाइस से जुड़ी ज़रूरी शर्तों के बारे में जानने के लिए, सेक्शन 2_2_3 देखें.

3.8.17. क्लिपबोर्ड

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

• [C-0-1] क्लिपबोर्ड का डेटा, किसी भी कॉम्पोनेंट, गतिविधि, सेवा या किसी भी नेटवर्क कनेक्शन पर, उपयोगकर्ता की साफ़ तौर पर की गई कार्रवाई (उदाहरण के लिए, ओवरले पर बटन दबाना) या भेजे जा रहे कॉन्टेंट के संकेत के बिना नहीं भेजा जाना चाहिए. हालांकि, 9.8.6 कॉन्टेंट कैप्चर और ऐप्लिकेशन सर्च में बताई गई सेवाओं के लिए ऐसा किया जा सकता है.

अगर डिवाइस पर कॉन्टेंट को क्लिपबोर्ड पर कॉपी करने पर, उपयोगकर्ता को दिखने वाली झलक जनरेट होती है, तो:ClipDataClipData.getDescription().getExtras()android.content.extra.IS_SENSITIVE

• [C-1-1] उपयोगकर्ता को दिखने वाली झलक में, संवेदनशील जानकारी को छिपाना ज़रूरी है

AOSP के रेफ़रंस के तौर पर लागू किया गया तरीका, क्लिपबोर्ड से जुड़ी इन ज़रूरी शर्तों को पूरा करता है.

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

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

अगर डिवाइस पर, Android SDK टूल के दस्तावेज़ में बताई गई डिवाइस मैनेजमेंट की सभी नीतियों को लागू किया जाता है, तो:

• [C-1-1] android.software.device_admin का एलान करना ज़रूरी है.
• [C-1-2] डिवाइस के मालिक को डिवाइस सेट अप करने की सुविधा देनी चाहिए, जैसा कि सेक्शन 3.9.1 और सेक्शन 3.9.1.1 में बताया गया है.

3.9.1 डिवाइस प्रॉविज़निंग

3.9.1.1 डिवाइस के मालिक के लिए प्रॉविज़निंग

अगर डिवाइस पर android.software.device_admin लागू किया जाता है, तो:

• [C-1-1] डिवाइस नीति क्लाइंट (डीपीसी) को डिवाइस के मालिक के ऐप्लिकेशन के तौर पर रजिस्टर करने की सुविधा होनी चाहिए. इसके लिए, यह ज़रूरी है कि:
  • जब डिवाइस पर लागू किए गए नीति के लिए, उपयोगकर्ताओं और उपयोगकर्ता के डेटा, दोनों को कॉन्फ़िगर नहीं किया गया है, तो:
    • [C-1-5] अगर डिवाइस, सुविधा फ़्लैग android.hardware.nfc के ज़रिए नियर-फ़ील्ड कम्यूनिकेशन (एनएफ़सी) के साथ काम करने की जानकारी देता है और उसे एनएफ़सी मैसेज मिलता है, जिसमें MIME टाइप MIME_TYPE_PROVISIONING_NFC वाला रिकॉर्ड होता है, तो DPC ऐप्लिकेशन को डिवाइस के मालिक के ऐप्लिकेशन के तौर पर रजिस्टर करना ज़रूरी है या DPC ऐप्लिकेशन को यह चुनने की अनुमति देनी होगी कि वह डिवाइस का मालिक बनेगा या प्रोफ़ाइल का मालिक.
    • [C-1-8] डिवाइस के मालिक के लिए डिवाइस सेट अप करने की सुविधा ट्रिगर होने के बाद, ACTION_GET_PROVISIONING_MODE इंटेंट भेजना ज़रूरी है, ताकि डीपीसी ऐप्लिकेशन यह चुन सके कि उसे डिवाइस का मालिक बनाना है या प्रोफ़ाइल का मालिक. यह विकल्प, android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES की वैल्यू के आधार पर तय किया जाता है. ऐसा तब तक करना होगा, जब तक कॉन्टेक्स्ट से यह पता नहीं चल जाता कि सिर्फ़ एक मान्य विकल्प है.
    • [C-1-9] डिवाइस के मालिक के ऐप्लिकेशन को ACTION_ADMIN_POLICY_COMPLIANCE इंटेंट भेजना ज़रूरी है. ऐसा तब करना होगा, जब डिवाइस के मालिक की जानकारी, डिवाइस को कॉन्फ़िगर करने के दौरान डाली गई हो. भले ही, डिवाइस को कॉन्फ़िगर करने के लिए किसी भी तरीके का इस्तेमाल किया गया हो. डिवाइस के मालिक का ऐप्लिकेशन पूरा होने तक, उपयोगकर्ता को सेटअप विज़र्ड में आगे बढ़ने की अनुमति नहीं मिलनी चाहिए.
  • जब डिवाइस पर लागू किए गए ऐप्लिकेशन में उपयोगकर्ता या उपयोगकर्ता का डेटा मौजूद हो, तो:
    • [C-1-7] अब किसी भी डीपीसी ऐप्लिकेशन को डिवाइस के मालिक के ऐप्लिकेशन के तौर पर रजिस्टर नहीं करना चाहिए.
• [C-1-2] ऐप्लिकेशन को डिवाइस के मालिक के तौर पर सेट करने से पहले, ज़ाहिर की जाने वाली सही सूचना दिखाना ज़रूरी है. जैसे, AOSP में बताई गई सूचना. साथ ही, असली उपयोगकर्ता से सहमति लेना ज़रूरी है. हालांकि, अगर डिवाइस को स्क्रीन पर असली उपयोगकर्ता के इंटरैक्शन से पहले, प्रोग्राम के हिसाब से रीटेल डेमो मोड के लिए कॉन्फ़िगर किया गया है, तो ऐसा करना ज़रूरी नहीं है.

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

• [C-2-1] यह ज़रूरी है कि आपके पास यह पुष्टि करने की प्रोसेस हो कि जिस ऐप्लिकेशन का प्रमोशन किया जा रहा है वह किसी मान्य एंटरप्राइज़ डिवाइस मैनेजमेंट सलूशन से जुड़ा हो. साथ ही, उसे मालिकाना हक वाले सलूशन में कॉन्फ़िगर किया गया हो, ताकि उसके पास "डिवाइस के मालिक" के बराबर अधिकार हों.
• [C-2-2] DPC ऐप्लिकेशन को "डिवाइस के मालिक" के तौर पर रजिस्टर करने से पहले, डिवाइस के मालिक के तौर पर सहमति देने के लिए, AOSP में बताई गई वही जानकारी ज़ाहिर करनी होगी जो android.app.action.PROVISION_MANAGED_DEVICE ने शुरू की थी.
• [C-2-3] ऐप्लिकेशन को सहमति को हार्ड कोड नहीं करना चाहिए या डिवाइस के मालिक के दूसरे ऐप्लिकेशन के इस्तेमाल को रोकना चाहिए.

3.9.1.2 मैनेज की जा रही प्रोफ़ाइल को डिवाइस पर सेट अप करना

अगर डिवाइस पर android.software.managed_users लागू किया जाता है, तो:

• [C-1-1] एपीआई लागू करने ज़रूरी हैं, ताकि डिवाइस नीति नियंत्रक (डीपीसी) ऐप्लिकेशन, मैनेज की जा रही नई प्रोफ़ाइल का मालिक बन सके.

• [C-1-2] मैनेज की जा रही प्रोफ़ाइल को उपलब्ध कराने की प्रोसेस (android.app.action.PROVISION_MANAGED_PROFILE का इस्तेमाल करके डीपीसी से शुरू किया गया फ़्लो) या प्लैटफ़ॉर्म से, सहमति स्क्रीन और उपयोगकर्ता अनुभव को एओएसपी के लागू होने के साथ अलाइन करना ज़रूरी है.

• [C-1-3] डिवाइस नीति कंट्रोलर (डीपीसी) की ओर से किसी खास सिस्टम फ़ंक्शन को बंद किए जाने पर, उपयोगकर्ता को इसकी जानकारी देने के लिए, सेटिंग में ये सुविधाएं उपलब्ध कराई जानी चाहिए:

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

• [C-1-4] अगर android.app.action.PROVISION_MANAGED_PROFILE इंटेंट से प्रोवाइज़निंग शुरू करने पर, प्रोफ़ाइल का मालिक तय हो जाता है और डीपीसी ने हैंडलर लागू कर दिया है, तो वर्क प्रोफ़ाइल में ACTION_PROVISIONING_SUCCESSFUL इंटेंट के लिए हैंडलर लॉन्च करना ज़रूरी है.

• [C-1-5] android.app.action.PROVISION_MANAGED_PROFILE के ज़रिए प्रोविज़न करने की प्रोसेस शुरू होने पर, वर्क प्रोफ़ाइल के डीपीसी को ACTION_PROFILE_PROVISIONING_COMPLETE ब्रॉडकास्ट भेजना ज़रूरी है.

• [C-1-6] प्रोफ़ाइल के मालिक के लिए डिवाइस को प्रोवाइड करने की सुविधा ट्रिगर होने के बाद, ACTION_GET_PROVISIONING_MODE इंटेंट भेजना ज़रूरी है. इससे डीपीसी ऐप्लिकेशन यह चुन सकता है कि उसे डिवाइस का मालिक बनाना है या प्रोफ़ाइल का. हालांकि, अगर इंटेंट android.app.action.PROVISION_MANAGED_PROFILE से प्रोवाइड करने की सुविधा ट्रिगर होती है, तो ऐसा नहीं करना होगा.

• [C-1-7] प्रोवाइज़न करने के दौरान, अगर प्रोफ़ाइल का मालिक तय किया जाता है, तो वर्क प्रोफ़ाइल को ACTION_ADMIN_POLICY_COMPLIANCE इंटेंट भेजना ज़रूरी है. इससे कोई फ़र्क़ नहीं पड़ता कि प्रोवाइज़न करने के लिए किस तरीके का इस्तेमाल किया जा रहा है. हालांकि, अगर प्रोवाइज़न करने की प्रोसेस, android.app.action.PROVISION_MANAGED_PROFILE इंटेंट से ट्रिगर होती है, तो ऐसा करना ज़रूरी नहीं है. जब तक Profile Owner ऐप्लिकेशन इंस्टॉल नहीं हो जाता, तब तक उपयोगकर्ता को सेटअप विज़र्ड में आगे बढ़ने की अनुमति नहीं मिलनी चाहिए.

• [C-1-8] प्रोफ़ाइल का मालिक तय होने पर, निजी प्रोफ़ाइल के डीपीसी को ACTION_MANAGED_PROFILE_PROVISIONED ब्रॉडकास्ट भेजना ज़रूरी है. भले ही, प्रोफ़ाइल को उपलब्ध कराने का तरीका कुछ भी हो.

3.9.2 मैनेज की जा रही प्रोफ़ाइल के लिए सहायता

अगर डिवाइस पर android.software.managed_users लागू किया जाता है, तो:

• [C-1-1] android.app.admin.DevicePolicyManager एपीआई की मदद से, मैनेज की जा रही प्रोफ़ाइलों को इस्तेमाल करने की सुविधा होनी चाहिए.
• [C-1-2] सिर्फ़ एक मैनेज की जा रही प्रोफ़ाइल बनाने की अनुमति होनी चाहिए.
• [C-1-3] मैनेज किए जा रहे ऐप्लिकेशन और विजेट के साथ-साथ, बैज वाले अन्य यूज़र इंटरफ़ेस (यूआई) एलिमेंट को दिखाने के लिए, आइकॉन बैज का इस्तेमाल करना ज़रूरी है. जैसे, हाल ही में इस्तेमाल किए गए ऐप्लिकेशन और सूचनाएं. यह बैज, AOSP अपस्ट्रीम वर्क बैज जैसा होना चाहिए.
• [C-1-4] यह ज़रूरी है कि जब उपयोगकर्ता मैनेज की जा रही प्रोफ़ाइल वाले ऐप्लिकेशन का इस्तेमाल कर रहा हो, तब सूचना आइकॉन दिखे. यह आइकॉन, AOSP अपस्ट्रीम वर्क बैज जैसा होना चाहिए.
• [C-1-5] डिवाइस के चालू होने (ACTION_USER_PRESENT) और फ़ोरग्राउंड ऐप्लिकेशन के मैनेज की गई प्रोफ़ाइल में होने पर, उपयोगकर्ता को एक टॉस्ट दिखाना ज़रूरी है. इस टॉस्ट से यह पता चलना चाहिए कि उपयोगकर्ता मैनेज की गई प्रोफ़ाइल में है.
• [C-1-6] अगर कोई मैनेज की जा रही प्रोफ़ाइल मौजूद है, तो इंटेंट 'चुने जाने वाले' में विज़ुअल अवफ़र्डेंस दिखाना ज़रूरी है. इससे उपयोगकर्ता, मैनेज की जा रही प्रोफ़ाइल से प्राइमरी उपयोगकर्ता को इंटेंट फ़ॉरवर्ड कर सकता है. इसके अलावा, अगर डिवाइस नीति कंट्रोलर की ओर से चालू किया गया है, तो प्राइमरी उपयोगकर्ता से मैनेज की जा रही प्रोफ़ाइल को इंटेंट फ़ॉरवर्ड किया जा सकता है.
• [C-1-7] अगर कोई मैनेज की जा रही प्रोफ़ाइल मौजूद है, तो प्राइमरी उपयोगकर्ता और मैनेज की जा रही प्रोफ़ाइल, दोनों के लिए ये सुविधाएं ज़रूर उपलब्ध कराएं:
  • प्राइमरी उपयोगकर्ता और मैनेज की जा रही प्रोफ़ाइल के लिए, बैटरी, जगह की जानकारी, मोबाइल डेटा, और स्टोरेज के इस्तेमाल का अलग-अलग हिसाब.
  • मुख्य उपयोगकर्ता या मैनेज की जा रही प्रोफ़ाइल में इंस्टॉल किए गए वीपीएन ऐप्लिकेशन को अलग से मैनेज किया जा सकता है.
  • मुख्य उपयोगकर्ता या मैनेज की जा रही प्रोफ़ाइल में इंस्टॉल किए गए ऐप्लिकेशन को अलग से मैनेज किया जा सकता है.
  • मुख्य उपयोगकर्ता या मैनेज की जा रही प्रोफ़ाइल में मौजूद खातों को अलग से मैनेज करना.
• [C-1-8] यह पक्का करना ज़रूरी है कि पहले से इंस्टॉल किए गए डायलर, संपर्क, और मैसेजिंग ऐप्लिकेशन, डिवाइस नीति कंट्रोलर की अनुमति मिलने पर, प्राइमरी प्रोफ़ाइल के साथ-साथ मैनेज की जा रही प्रोफ़ाइल (अगर कोई मौजूद है) से भी कॉलर की जानकारी खोज और देख सकें.
• [C-1-9] यह पक्का करना ज़रूरी है कि यह उन सभी सुरक्षा ज़रूरी शर्तों को पूरा करता हो जो एक से ज़्यादा उपयोगकर्ताओं के लिए चालू किए गए डिवाइस पर लागू होती हैं (सेक्शन 9.5 देखें). भले ही, मैनेज की जा रही प्रोफ़ाइल को मुख्य उपयोगकर्ता के अलावा किसी दूसरे उपयोगकर्ता के तौर पर नहीं गिना जाता.

अगर डिवाइस पर android.software.managed_users और android.software.secure_lock_screen का एलान किया जाता है, तो:

• [C-2-1] यह ज़रूरी है कि डिवाइस पर, अलग लॉक स्क्रीन सेट की जा सके. साथ ही, यह भी ज़रूरी है कि सिर्फ़ मैनेज की जा रही प्रोफ़ाइल में चल रहे ऐप्लिकेशन को ऐक्सेस करने के लिए, लॉक स्क्रीन सेट करने की इन ज़रूरी शर्तों को पूरा किया जा सके.
  • डिवाइस पर लागू करने के लिए, DevicePolicyManager.ACTION_SET_NEW_PASSWORD के इंटेंट का पालन करना ज़रूरी है. साथ ही, मैनेज की जा रही प्रोफ़ाइल के लिए, लॉक स्क्रीन का अलग क्रेडेंशियल कॉन्फ़िगर करने के लिए इंटरफ़ेस दिखाना ज़रूरी है.
  • मैनेज की जा रही प्रोफ़ाइल की लॉक स्क्रीन के क्रेडेंशियल के लिए, वही क्रेडेंशियल स्टोरेज और मैनेजमेंट का तरीका इस्तेमाल करना ज़रूरी है जो पैरंट प्रोफ़ाइल के लिए इस्तेमाल किया जाता है. इस बारे में Android Open Source Project की साइट पर जानकारी दी गई है.
  • डीपीसी की पासवर्ड नीतियां, सिर्फ़ मैनेज की जा रही प्रोफ़ाइल की लॉक स्क्रीन के क्रेडेंशियल पर लागू होनी चाहिए. ऐसा तब तक करना ज़रूरी है, जब तक getParentProfileInstance से मिले DevicePolicyManager इंस्टेंस पर कॉल नहीं किया जाता.
• जब मैनेज की जा रही प्रोफ़ाइल के संपर्क, पहले से इंस्टॉल किए गए कॉल लॉग, कॉल के दौरान दिखने वाले यूज़र इंटरफ़ेस, कॉल के दौरान और छूटे हुए कॉल की सूचनाओं, संपर्कों, और मैसेजिंग ऐप्लिकेशन में दिखते हैं, तो उन्हें उसी बैज के साथ दिखाया जाना चाहिए जिसका इस्तेमाल मैनेज की जा रही प्रोफ़ाइल के ऐप्लिकेशन के लिए किया जाता है.

3.9.3 मैनेज किए जा रहे उपयोगकर्ता के लिए सहायता

अगर डिवाइस पर android.software.managed_users लागू किया जाता है, तो:

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

अगर डिवाइस पर android.software.device_admin का एलान किया जाता है और सेकंडरी उपयोगकर्ता जोड़ने के लिए, डिवाइस पर उपयोगकर्ता के लिए कोई सुविधा उपलब्ध कराई जाती है, तो:

• [C-SR-1] हमारा सुझाव है कि डिवाइस के मालिक की सहमति से जुड़ी जानकारी ज़ाहिर करने के लिए, AOSP के उसी फ़ॉर्म का इस्तेमाल करें जो android.app.action.PROVISION_MANAGED_DEVICE से शुरू होने वाले फ़्लो में दिखाया गया था. ऐसा इसलिए, ताकि उपयोगकर्ता यह समझ सकें कि डिवाइस मैनेज किया जा रहा है. साथ ही, नए सेकंडरी उपयोगकर्ता के खाते जोड़ने की अनुमति देने से पहले, ऐसा करना ज़रूरी है.

3.9.4 डिवाइस नीति मैनेजमेंट की भूमिका से जुड़ी ज़रूरी शर्तें

अगर डिवाइस पर लागू करने की रिपोर्ट में android.software.device_admin या android.software.managed_users दिखता है, तो इसका मतलब है कि:

• [C-1-1] यह ज़रूरी है कि यह सेक्शन 9.1 में बताई गई डिवाइस नीति मैनेजमेंट भूमिका के साथ काम करे. डिवाइस नीति मैनेजमेंट की भूमिका वाले ऐप्लिकेशन को, पैकेज के नाम के तौर पर config_devicePolicyManagement सेट करके तय किया जा सकता है. अगर ऐप्लिकेशन पहले से लोड नहीं किया गया है, तो पैकेज के नाम के बाद : और हस्ताक्षर करने के सर्टिफ़िकेट का होना ज़रूरी है.

अगर ऊपर बताए गए तरीके से, config_devicePolicyManagement के लिए पैकेज का नाम तय नहीं किया गया है, तो:

• [C-2-1] डिवाइस पर लागू किए गए वर्शन में, डिवाइस नीति मैनेजमेंट की भूमिका रखने वाले ऐप्लिकेशन के बिना भी डिवाइस को डिवाइस के तौर पर इस्तेमाल करने की सुविधा चालू करने की सुविधा होनी चाहिए (AOSP, डिवाइस को डिवाइस के तौर पर इस्तेमाल करने की सुविधा चालू करने का रेफ़रंस देता है).

अगर ऊपर बताए गए तरीके से config_devicePolicyManagement के लिए पैकेज का नाम तय किया गया है, तो:

• [C-3-1] उपयोगकर्ता के लिए, ऐप्लिकेशन को सभी प्रोफ़ाइलों पर इंस्टॉल करना ज़रूरी है.
• [C-3-2] डिवाइस पर लागू होने वाले वर्शन में, ऐसा ऐप्लिकेशन तय किया जा सकता है जो डिवाइस की नीति मैनेज करने की भूमिका रखने वाले व्यक्ति को अपडेट करता है. ऐसा, config_devicePolicyManagementUpdater सेट करके किया जाता है.

अगर config_devicePolicyManagementUpdater के लिए, ऊपर बताए गए तरीके से पैकेज का नाम तय किया गया है, तो:

• [C-4-1] ऐप्लिकेशन, डिवाइस पर पहले से इंस्टॉल होना चाहिए.
• [C-4-2] ऐप्लिकेशन में ऐसा इंटेंट फ़िल्टर लागू करना ज़रूरी है जो android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER को हल करता हो.

3.10. सुलभता

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

अगर डिवाइस पर तीसरे पक्ष की सुलभता सेवाएं काम करती हैं, तो:

• [C-1-1] ऐप्लिकेशन में, Android के सुलभता फ़्रेमवर्क को लागू करना ज़रूरी है. इसके बारे में, Accessibility API के SDK दस्तावेज़ में बताया गया है.
• [C-1-2] SDK टूल में बताए गए तरीके के मुताबिक, सुलभता इवेंट जनरेट करने चाहिए और रजिस्टर किए गए सभी AccessibilityService लागू करने के लिए सही AccessibilityEvent डिलीवर करने चाहिए.
• [C-1-4] ऐक्सेसibiliti सेवाओं को कंट्रोल करने के लिए, उपयोगकर्ता को एक सुविधा देनी ज़रूरी है. ये सेवाएं, AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON का एलान करती हैं. ध्यान दें कि सिस्टम नेविगेशन बार वाले डिवाइसों के लिए, उपयोगकर्ता को सिस्टम के नेविगेशन बार में एक बटन का विकल्प देना चाहिए, ताकि वह इन सेवाओं को कंट्रोल कर सके.

अगर डिवाइस में पहले से इंस्टॉल की गई सुलभता सेवाएं शामिल हैं, तो:

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

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

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

अगर डिवाइस में android.hardware.audio.output सुविधा लागू की गई है, तो:

• [C-1-1] ऐप्लिकेशन को Android TTS फ़्रेमवर्क के एपीआई के साथ काम करना चाहिए.

अगर डिवाइस पर तीसरे पक्ष के TTS इंजन इंस्टॉल किए जा सकते हैं, तो:

• [C-2-1] सिस्टम लेवल पर इस्तेमाल करने के लिए, उपयोगकर्ता को TTS इंजन चुनने की अनुमति देने के लिए, उपयोगकर्ता के लिए सुविधाएं उपलब्ध कराएं.

3.12. टीवी इनपुट फ़्रेमवर्क

Android Television Input Framework (TIF) की मदद से, Android Television डिवाइसों पर लाइव कॉन्टेंट को आसानी से डिलीवर किया जा सकता है. TIF, Android Television डिवाइसों को कंट्रोल करने वाले इनपुट मॉड्यूल बनाने के लिए, एक स्टैंडर्ड एपीआई उपलब्ध कराता है.

अगर डिवाइस पर TIF फ़ाइलें इस्तेमाल की जा सकती हैं, तो:

• [C-1-1] प्लैटफ़ॉर्म की सुविधा android.software.live_tv के बारे में एलान करना ज़रूरी है.
• [C-1-2] यह सभी TIF एपीआई के साथ काम करना चाहिए, ताकि इन एपीआई और तीसरे पक्ष के TIF-आधारित इनपुट की सेवा का इस्तेमाल करने वाले ऐप्लिकेशन को डिवाइस पर इंस्टॉल और इस्तेमाल किया जा सके.

3.13. क्विक सेटिंग

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

अगर डिवाइस में क्विक सेटिंग का यूज़र इंटरफ़ेस (यूआई) कॉम्पोनेंट शामिल है और तीसरे पक्ष की क्विक सेटिंग काम करती है, तो:

• [C-1-1] उपयोगकर्ता को तीसरे पक्ष के ऐप्लिकेशन से, quicksettings एपीआई के ज़रिए दी गई टाइल जोड़ने या हटाने की अनुमति देनी चाहिए.
• [C-1-2] किसी तीसरे पक्ष के ऐप्लिकेशन की टाइल को सीधे क्विक सेटिंग में अपने-आप नहीं जोड़ना चाहिए.
• [C-1-3] सिस्टम की ओर से दी गई क्विक सेटिंग टाइल के साथ-साथ, तीसरे पक्ष के ऐप्लिकेशन से उपयोगकर्ता की जोड़ी गई सभी टाइल भी दिखनी चाहिए.

3.14. मीडिया का यूज़र इंटरफ़ेस (यूआई)

अगर डिवाइस में ऐसे ऐप्लिकेशन (ऐप्लिकेशन) शामिल हैं जो बोलकर दिए गए निर्देशों पर काम नहीं करते और MediaBrowser या MediaSession के ज़रिए तीसरे पक्ष के ऐप्लिकेशन के साथ इंटरैक्ट करते हैं, तो ऐप्लिकेशन:

• [C-1-2] MediaDescription में बताए गए तरीके से, getIconBitmap() या getIconUri() से मिले आइकॉन और getTitle() से मिले टाइटल साफ़ तौर पर दिखने चाहिए. सुरक्षा से जुड़े नियमों का पालन करने के लिए, वीडियो के टाइटल छोटे किए जा सकते हैं. जैसे, ड्राइवर का ध्यान भटकाना.

• [C-1-3] तीसरे पक्ष के इस ऐप्लिकेशन से मिलने वाला कॉन्टेंट दिखाते समय, तीसरे पक्ष के ऐप्लिकेशन का आइकॉन दिखाना ज़रूरी है.

• [C-1-4] उपयोगकर्ता को पूरी MediaBrowser के साथ इंटरैक्ट करने की अनुमति देनी चाहिए. सुरक्षा से जुड़े नियमों (जैसे, ड्राइवर का ध्यान भटकना) का पालन करने के लिए, हैरारकी के कुछ हिस्से के ऐक्सेस पर पाबंदी लगाई जा सकती है. हालांकि, कॉन्टेंट या कॉन्टेंट उपलब्ध कराने वाले के आधार पर, किसी को भी प्राथमिकता नहीं दी जानी चाहिए.

• [C-1-5] MediaSession.Callback#onMediaButtonEvent के लिए, KEYCODE_HEADSETHOOK या KEYCODE_MEDIA_PLAY_PAUSE पर दो बार टैप करने को KEYCODE_MEDIA_NEXT के तौर पर स्वीकार करना ज़रूरी है.

3.15. Instant Apps

अगर डिवाइस पर इंस्टैंट ऐप्लिकेशन काम करते हैं, तो उन्हें इन ज़रूरी शर्तों को पूरा करना होगा:

• [C-1-1] Instant Apps को सिर्फ़ ऐसी अनुमतियां दी जानी चाहिए जिनके लिए android:protectionLevel को "instant" पर सेट किया गया हो.
• [C-1-2] 'झटपट ऐप्लिकेशन' को अहम इंटेंट के ज़रिए, इंस्टॉल किए गए ऐप्लिकेशन के साथ इंटरैक्ट नहीं करना चाहिए. ऐसा तब तक नहीं किया जाना चाहिए, जब तक इनमें से कोई एक बात सही न हो:
  • कॉम्पोनेंट का इंटेंट पैटर्न फ़िल्टर एक्सपोज़ किया गया है और उसमें CATEGORY_BROWSABLE है
  • यह कार्रवाई, ACTION_SEND, ACTION_SENDTO, ACTION_SEND_MULTIPLE में से कोई एक होनी चाहिए
  • टारगेट को android:visibleToInstantApps के साथ साफ़ तौर पर दिखाया गया हो
• [C-1-3] इंस्टैंट ऐप्लिकेशन को इंस्टॉल किए गए ऐप्लिकेशन के साथ तब तक इंटरैक्ट नहीं करना चाहिए, जब तक कि कॉम्पोनेंट को android:visibleToInstantApps के ज़रिए एक्सपोज़ नहीं किया जाता.
• [C-1-4] इंस्टॉल किए गए ऐप्लिकेशन को डिवाइस पर इंस्टैंट ऐप्लिकेशन की जानकारी तब तक नहीं दिखनी चाहिए, जब तक इंस्टैंट ऐप्लिकेशन, इंस्टॉल किए गए ऐप्लिकेशन से साफ़ तौर पर कनेक्ट न हो.

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

  • [C-1-5] उपयोगकर्ता को यह सुविधा देनी चाहिए कि वह हर ऐप्लिकेशन पैकेज के लिए, कैश मेमोरी में सेव किए गए Instant Apps को देख सके और मिटा सके.
  • [C-1-6] उपयोगकर्ता को लगातार सूचना देनी चाहिए. यह सूचना, फ़ोरग्राउंड में इंस्टैंट ऐप्लिकेशन के चलने के दौरान छोटी की जा सकती है. उपयोगकर्ता को मिलने वाली इस सूचना में यह ज़रूर शामिल होना चाहिए कि Instant Apps को इंस्टॉल करने की ज़रूरत नहीं होती. साथ ही, इसमें उपयोगकर्ता को सेटिंग में जाकर, ऐप्लिकेशन की जानकारी वाली स्क्रीन पर ले जाने वाला यूज़र अफ़र्डेंस भी होना चाहिए. वेब इंटेंट की मदद से लॉन्च किए गए इंस्टैंट ऐप्लिकेशन के लिए, उपयोगकर्ता को एक और विकल्प दिया जाना चाहिए. इससे, उपयोगकर्ता को इंस्टैंट ऐप्लिकेशन लॉन्च करने के बजाय, कॉन्फ़िगर किए गए वेब ब्राउज़र में लिंक को लॉन्च करने का विकल्प मिलता है. हालांकि, ऐसा तब ही किया जा सकता है, जब डिवाइस पर कोई ब्राउज़र उपलब्ध हो. ऐसा करने के लिए, Intent.ACTION_VIEW पर सेट किए गए ऐक्शन और "http" या "https" स्कीम वाले इंटेंट का इस्तेमाल किया जाना चाहिए.
  • [C-1-7] अगर डिवाइस पर 'हाल ही में इस्तेमाल किए गए' फ़ंक्शन उपलब्ध है, तो ऐप्लिकेशन को इस फ़ंक्शन से ऐक्सेस करने की अनुमति देनी चाहिए.

• [C-1-8] एसडीके टूल में यहां बताए गए इंटेंट के लिए, एक या एक से ज़्यादा ऐप्लिकेशन या सेवा कॉम्पोनेंट को इंटेंट हैंडलर के साथ पहले से लोड करना ज़रूरी है. साथ ही, इंस्टैंट ऐप्लिकेशन के लिए इंटेंट दिखाना ज़रूरी है.

3.16. कंपैनियन डिवाइस को जोड़ना

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

अगर डिवाइस में, साथ में इस्तेमाल किए जाने वाले डिवाइस को जोड़ने की सुविधा काम करती है, तो:

• [C-1-1] FEATURE_COMPANION_DEVICE_SETUP फ़ीचर फ़्लैग का एलान करना ज़रूरी है.
• [C-1-2] यह पक्का करना ज़रूरी है कि android.companion पैकेज में मौजूद एपीआई पूरी तरह से लागू हों.
• [C-1-3] उपयोगकर्ता को यह चुनने/पुष्टि करने के लिए, उपयोगकर्ता के लिए ज़रूरी है कि वह साथी डिवाइस मौजूद है और काम कर रहा है.

3.17. ज़्यादा मेमोरी इस्तेमाल करने वाले ऐप्लिकेशन

अगर डिवाइस में सुविधा FEATURE_CANT_SAVE_STATE का एलान किया जाता है, तो:

• [C-1-1] डिवाइस में सिर्फ़ एक ऐसा ऐप्लिकेशन इंस्टॉल होना चाहिए जो यह बताता हो कि सिस्टम में एक बार में cantSaveState कौनसा ऐप्लिकेशन चल रहा है. अगर उपयोगकर्ता किसी ऐप्लिकेशन से साफ़ तौर पर बाहर निकले बिना उसे छोड़ देता है, तो डिवाइस के लागू होने पर, उस ऐप्लिकेशन को रैम में प्राथमिकता दी जानी चाहिए. ठीक उसी तरह जैसे फ़ोरग्राउंड सेवाओं जैसी अन्य चीज़ों को प्राथमिकता दी जाती है. उदाहरण के लिए, सिस्टम में कोई चालू गतिविधि न होने पर, बैक बटन दबाने के बजाय होम बटन दबाकर ऐप्लिकेशन से बाहर निकलना. जब कोई ऐप्लिकेशन बैकग्राउंड में चल रहा होता है, तब भी सिस्टम उस पर पावर मैनेजमेंट की सुविधाएं लागू कर सकता है. जैसे, सीपीयू और नेटवर्क ऐक्सेस को सीमित करना.
• [C-1-2] उपयोगकर्ता के cantSaveState एट्रिब्यूट के साथ बताए गए दूसरे ऐप्लिकेशन को लॉन्च करने के बाद, सामान्य स्थिति को सेव/बहाल करने वाले मैकेनिज़्म में हिस्सा न लेने वाले ऐप्लिकेशन को चुनने के लिए, यूज़र इंटरफ़ेस (यूआई) की सुविधा देना ज़रूरी है.
• [C-1-3] नीति में किए गए अन्य बदलावों को उन ऐप्लिकेशन पर लागू नहीं किया जाना चाहिए जिनमें cantSaveState के बारे में बताया गया है. जैसे, सीपीयू की परफ़ॉर्मेंस में बदलाव करना या शेड्यूल करने के लिए प्राथमिकता में बदलाव करना.

अगर डिवाइस में लागू करने की सुविधा के लिए, FEATURE_CANT_SAVE_STATE सुविधा का एलान नहीं किया जाता है, तो:

• [C-1-1] ऐप्लिकेशन से सेट किए गए cantSaveState एट्रिब्यूट को अनदेखा करना ज़रूरी है. साथ ही, उस एट्रिब्यूट के आधार पर ऐप्लिकेशन के व्यवहार में बदलाव नहीं करना चाहिए.

3.18. संपर्क

Android में Contacts Provider एपीआई शामिल हैं, ताकि ऐप्लिकेशन डिवाइस पर सेव की गई संपर्क जानकारी को मैनेज कर सकें. सीधे डिवाइस में डाले गए संपर्क डेटा को आम तौर पर किसी वेब सेवा के साथ सिंक किया जाता है. हालांकि, हो सकता है कि डेटा सिर्फ़ डिवाइस पर सेव हो. सिर्फ़ डिवाइस में सेव किए गए संपर्कों को लोकल संपर्क कहा जाता है.

RawContacts, किसी खाते से "जुड़े हुए" या "उसमें सेव किए गए" होते हैं, जब रॉ संपर्कों के लिए ACCOUNT_NAME और ACCOUNT_TYPE कॉलम, खाते के Account.name और Account.type फ़ील्ड से मेल खाते हैं.

डिफ़ॉल्ट लोकल खाता: यह उन रॉ संपर्कों के लिए खाता है जिन्हें सिर्फ़ डिवाइस पर सेव किया जाता है. यह AccountManager में मौजूद किसी खाते से नहीं जुड़ा होता. इन संपर्कों को ACCOUNT_NAME और ACCOUNT_TYPE कॉलम के लिए शून्य वैल्यू के साथ बनाया जाता है.

कस्टम लोकल खाता: यह उन रॉ संपर्कों के लिए खाता है जिन्हें सिर्फ़ डिवाइस पर सेव किया जाता है. यह खाता, AccountManager में मौजूद किसी खाते से नहीं जुड़ा होता. इसे ACCOUNT_NAME और ACCOUNT_TYPE कॉलम के लिए, कम से कम एक ऐसी वैल्यू के साथ बनाया जाता है जो शून्य न हो.

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

• [C-SR-1] हमारा सुझाव है कि कस्टम लोकल खाते न बनाएं.

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

• [C-1-1] कस्टम लोकल खाते का ACCOUNT_NAME, ContactsContract.RawContacts.getLocalAccountName से वापस लौटाया जाना चाहिए
• [C-1-2] कस्टम लोकल खाते का ACCOUNT_TYPE, ContactsContract.RawContacts.getLocalAccountType से वापस लाया जाना चाहिए
• [C-1-3] तीसरे पक्ष के ऐप्लिकेशन, डिफ़ॉल्ट लोकल खाते के साथ रॉ संपर्क डालते हैं.जैसे, ACCOUNT_NAME और ACCOUNT_TYPE के लिए शून्य वैल्यू सेट करके. ऐसे रॉ संपर्क, कस्टम लोकल खाते में डाले जाने चाहिए.
• [C-1-4] खाते जोड़ने या हटाने पर, कस्टम लोकल खाते में डाले गए रॉ संपर्कों को हटाया नहीं जाना चाहिए.
• [C-1-5] कस्टम लोकल खाते के लिए किए गए मिटाएं ऑपरेशन के बाद, रॉ संपर्क तुरंत मिटा दिए जाने चाहिए (जैसे कि CALLER_IS_SYNCADAPTER पैरामीटर को 'सही' पर सेट किया गया हो), भले ही CALLER\_IS\_SYNCADAPTER पैरामीटर को 'गलत' पर सेट किया गया हो या उसकी जानकारी न दी गई हो.

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

डिवाइसों पर लागू करने के लिए:

• [C-0-1] यह ज़रूरी है कि यह टूल, आधिकारिक Android SDK में शामिल “aapt” टूल से जनरेट की गई Android “.apk” फ़ाइलों को इंस्टॉल और चला सके.

  • ऊपर बताई गई शर्त को पूरा करना मुश्किल हो सकता है. इसलिए, डिवाइस में इसे लागू करने के लिए, हमारा सुझाव है कि आप AOSP के रेफ़रंस के तौर पर लागू किए गए पैकेज मैनेजमेंट सिस्टम का इस्तेमाल करें.

• [C-0-2] यह ज़रूरी है कि APK सिग्नेचर स्कीम v3.1, APK सिग्नेचर स्कीम v3, APK सिग्नेचर स्कीम v2 और JAR साइनिंग का इस्तेमाल करके, “.apk” फ़ाइलों की पुष्टि की जा सके.

• [C-0-3] .apk, Android मेनिफ़ेस्ट, Dalvik बाइटकोड या रेंडरस्क्रिप्ट बाइटकोड फ़ॉर्मैट को इस तरह से एक्सटेंड़ नहीं किया जाना चाहिए कि उन फ़ाइलों को काम करने वाले अन्य डिवाइसों पर सही तरीके से इंस्टॉल और चलाने में समस्या आएं.

• [C-0-4] पैकेज के लिए, मौजूदा "इंस्टॉलर ऑफ़ रिकॉर्ड" के अलावा किसी दूसरे ऐप्लिकेशन को, उपयोगकर्ता की पुष्टि के बिना ऐप्लिकेशन को चुपचाप अनइंस्टॉल करने की अनुमति नहीं देनी चाहिए. इस बारे में DELETE_PACKAGE अनुमति के लिए SDK टूल में जानकारी दी गई है. हालांकि, PACKAGE_NEEDS_VERIFICATION इंटेंट को मैनेज करने वाले सिस्टम पैकेज की पुष्टि करने वाले ऐप्लिकेशन और ACTION_MANAGE_STORAGE इंटेंट को मैनेज करने वाले स्टोरेज मैनेजर ऐप्लिकेशन पर यह शर्त लागू नहीं होती.

• [C-0-5] इसमें ऐसी गतिविधि होनी चाहिए जो android.settings.MANAGE_UNKNOWN_APP_SOURCES इंटेंट को मैनेज करती हो.

• [C-0-6] ऐप्लिकेशन के पैकेज, अज्ञात स्रोतों से इंस्टॉल नहीं किए जाने चाहिए. ऐसा तब तक नहीं किया जाना चाहिए, जब तक इंस्टॉल करने का अनुरोध करने वाला ऐप्लिकेशन इन सभी ज़रूरी शर्तों को पूरा न करता हो:

  • इसमें REQUEST_INSTALL_PACKAGES अनुमति का एलान करना ज़रूरी है या android:targetSdkVersion को 24 या उससे कम पर सेट करना होगा.
  • उपयोगकर्ता ने अज्ञात सोर्स से ऐप्लिकेशन इंस्टॉल करने की अनुमति दी हो.

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

• [C-0-7] किसी ऐप्लिकेशन में कोई गतिविधि शुरू करने से पहले, उपयोगकर्ता को चेतावनी वाली स्ट्रिंग के साथ चेतावनी वाला डायलॉग दिखाना ज़रूरी है. यह स्ट्रिंग, सिस्टम एपीआई PackageManager.setHarmfulAppWarning के ज़रिए दी जाती है. साथ ही, यह गतिविधि उसी सिस्टम एपीआई PackageManager.setHarmfulAppWarning के ज़रिए संभावित रूप से नुकसान पहुंचाने वाली के तौर पर मार्क की गई हो.

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

• [C-0-8] यहां बताए गए तरीके के मुताबिक, इंक्रीमेंटल फ़ाइल सिस्टम के लिए सहायता लागू करना ज़रूरी है.

• [C-0-9] APK सिग्नेचर स्कीम v4 और APK सिग्नेचर स्कीम v4 .1 का इस्तेमाल करके, .apk फ़ाइलों की पुष्टि करने की सुविधा होनी चाहिए.

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

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

• [C-0-1] MediaCodecList के ज़रिए बताए गए हर कोडेक के लिए, सेक्शन 5.1 में बताए गए मीडिया फ़ॉर्मैट, एन्कोडर, डिकोडर, फ़ाइल टाइप, और कंटेनर फ़ॉर्मैट के साथ काम करना चाहिए.
• [C-0-2] MediaCodecList के ज़रिए, तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध एन्कोडर और डिकोडर के साथ काम करने की जानकारी देनी होगी और उनकी शिकायत करनी होगी.
• [C-0-3] यह ज़रूरी है कि यह सभी फ़ॉर्मैट को सही तरीके से डिकोड कर सके और तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कर सके. इसमें, एन्कोडर से जनरेट होने वाली सभी बिटस्ट्रीम और CamcorderProfile में रिपोर्ट की गई प्रोफ़ाइलें शामिल हैं.

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

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

यहां दिए गए सेक्शन में बताए गए सभी कोडेक, Android Open Source Project के पसंदीदा Android वर्शन में, सॉफ़्टवेयर के तौर पर लागू किए जाते हैं.

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

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

5.1.1. ऑडियो एन्कोडिंग

ज़्यादा जानकारी के लिए, 5.1.3 देखें. ऑडियो कोडेक की जानकारी.

अगर डिवाइस में android.hardware.microphone का एलान किया गया है, तो उसे इन ऑडियो फ़ॉर्मैट को एन्कोड करने की सुविधा देनी होगी और उन्हें तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराना होगा:

• [C-1-1] PCM/WAVE
• [C-1-2] FLAC
• [C-1-3] Opus

सभी ऑडियो एन्कोडर में ये सुविधाएं होनी चाहिए:

• [C-3-1] android.media.MediaCodec एपीआई के ज़रिए, PCM 16-बिट नेटिव बाइट ऑर्डर ऑडियो फ़्रेम.

5.1.2. ऑडियो को डिकोड करना

ज़्यादा जानकारी के लिए, 5.1.3 देखें. ऑडियो कोडेक की जानकारी.

अगर डिवाइस में android.hardware.audio.output सुविधा काम करती है, तो उस पर इन ऑडियो फ़ॉर्मैट को डिकोड करने की सुविधा होनी चाहिए:

• [C-1-1] MPEG-4 AAC प्रोफ़ाइल (AAC LC)
• [C-1-2] MPEG-4 HE AAC Profile (AAC+)
• [C-1-3] MPEG-4 HE AACv2 प्रोफ़ाइल (बेहतर AAC+)
• [C-1-4] AAC ELD (कम देरी वाला बेहतर एएसी)
• [C-1-11] xHE-AAC (ISO/IEC 23003-3 एक्सटेंडेड HE AAC प्रोफ़ाइल, जिसमें USAC बेसलाइन प्रोफ़ाइल और ISO/IEC 23003-4 डाइनैमिक रेंज कंट्रोल प्रोफ़ाइल शामिल है)
• [C-1-5] FLAC
• [C-1-6] MP3
• [C-1-7] एमआईडीआई
• [C-1-8] Vorbis
• [C-1-9] PCM/WAVE, जिसमें 24 बिट तक के हाई रिज़ॉल्यूशन वाले ऑडियो फ़ॉर्मैट, 192 किलोहर्ट्ज़ का सैंपलिंग रेट, और आठ चैनल शामिल हैं. ध्यान दें कि यह शर्त सिर्फ़ डिकोड करने के लिए है. साथ ही, डिवाइस को वीडियो चलाने के दौरान, उसे डाउनसैंपल और डाउनमिक्स करने की अनुमति है.
• [C-1-10] Opus

अगर डिवाइस पर, android.media.MediaCodec API में डिफ़ॉल्ट AAC ऑडियो डिकोडर की मदद से, कई चैनलों वाली स्ट्रीम (यानी दो से ज़्यादा चैनलों वाली) के AAC इनपुट बफ़र को PCM में डिकोड करने की सुविधा काम करती है, तो इनके काम करने की ज़रूरत है:

• [C-2-1] डिकोडिंग, डाउनमिक्स किए बिना की जानी चाहिए.उदाहरण के लिए, 5. 0 AAC स्ट्रीम को PCM के पांच चैनलों में डिकोड किया जाना चाहिए.5.1 AAC स्ट्रीम को PCM के छह चैनलों में डिकोड किया जाना चाहिए.
• [C-2-2] डाइनैमिक रेंज का मेटाडेटा, ISO/IEC 14496-3 में "डाइनैमिक रेंज कंट्रोल (डीआरसी)" में बताए गए तरीके के मुताबिक होना चाहिए. साथ ही, ऑडियो डिकोडर के डाइनैमिक रेंज से जुड़े व्यवहार को कॉन्फ़िगर करने के लिए, android.media.MediaFormat डीआरसी बटन का इस्तेमाल किया जाना चाहिए. एएसी डीआरसी पासकोड, एपीआई 21 में जोड़े गए थे. ये पासकोड ये हैं: KEY_AAC_DRC_ATTENUATION_FACTOR, KEY_AAC_DRC_BOOST_FACTOR, KEY_AAC_DRC_HEAVY_COMPRESSION, KEY_AAC_DRC_TARGET_REFERENCE_LEVEL, और KEY_AAC_ENCODED_TARGET_LEVEL.
• [C-SR-1] हमारा सुझाव है कि सभी AAC ऑडियो डिकोडर, ऊपर बताई गई ज़रूरी शर्तें C-2-1 और C-2-2 पूरी करें.

USAC ऑडियो को डिकोड करते समय, MPEG-D (ISO/IEC 23003-4):

• [C-3-1] लाउडनेस और डीआरसी मेटाडेटा को MPEG-D डीआरसी डाइनैमिक रेंज कंट्रोल प्रोफ़ाइल लेवल 1 के मुताबिक समझा और लागू किया जाना चाहिए.
• [C-3-2] डिकोडर को इन android.media.MediaFormat कुंजियों के साथ सेट किए गए कॉन्फ़िगरेशन के हिसाब से काम करना चाहिए: KEY_AAC_DRC_TARGET_REFERENCE_LEVEL और KEY_AAC_DRC_EFFECT_TYPE.

MPEG-4 AAC, HE AAC, और HE AACv2 प्रोफ़ाइल डीकोडर:

• ISO/IEC 23003-4 डाइनैमिक रेंज कंट्रोल प्रोफ़ाइल का इस्तेमाल करके, आवाज़ की लाउडनेस और डाइनैमिक रेंज को कंट्रोल किया जा सकता है.

अगर ISO/IEC 23003-4 काम करता है और डिकोड किए गए बिटस्ट्रीम में ISO/IEC 23003-4 और ISO/IEC 14496-3, दोनों मेटाडेटा मौजूद हैं, तो:

• ISO/IEC 23003-4 मेटाडेटा को प्राथमिकता दी जाएगी.

सभी ऑडियो डिकोडर में, इन फ़ॉर्मैट में आउटपुट देने की सुविधा होनी चाहिए:

• [C-6-1] android.media.MediaCodec एपीआई के ज़रिए, PCM 16-बिट नेटिव बाइट ऑर्डर ऑडियो फ़्रेम.

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

• [C-7-1] ऐप्लिकेशन को डिकोडिंग का इस्तेमाल करके, कुंजी KEY_MAX_OUTPUT_CHANNEL_COUNT के साथ कॉन्फ़िगर किया जा सकता है. इससे यह कंट्रोल किया जा सकता है कि कॉन्टेंट को स्टीरियो में डाउनमिक्स किया जाए (2 की वैल्यू का इस्तेमाल करने पर) या चैनलों की नेटिव संख्या का इस्तेमाल करके आउटपुट किया जाए (उस संख्या के बराबर या उससे ज़्यादा की वैल्यू का इस्तेमाल करने पर). उदाहरण के लिए, 6 या उससे ज़्यादा की वैल्यू से, 5.1 कॉन्टेंट फ़ीड करने पर, डिकोडर को छह चैनल आउटपुट करने के लिए कॉन्फ़िगर किया जाएगा.
• [C-7-2] डिकोड करते समय, डिकोडर को android.media.AudioFormat कॉन्स्टेंट (उदाहरण के लिए: CHANNEL_OUT_5POINT1) का इस्तेमाल करके, आउटपुट फ़ॉर्मैट पर इस्तेमाल किए जा रहे चैनल मास्क का विज्ञापन करना होगा.KEY_CHANNEL_MASK

अगर डिवाइस में डिफ़ॉल्ट AAC ऑडियो डिकोडर के अलावा अन्य ऑडियो डिकोडर काम करते हैं और कंप्रेस किए गए मल्टी-चैनल कॉन्टेंट को चलाने पर, मल्टी-चैनल ऑडियो (यानी दो से ज़्यादा चैनल) आउटपुट करने की सुविधा होती है, तो:

• [C-SR-2] हमारा सुझाव है कि डिकोडर को ऐप्लिकेशन के ज़रिए कॉन्फ़िगर किया जाए. इसके लिए, डिकोडिंग के लिए कुंजी KEY_MAX_OUTPUT_CHANNEL_COUNT का इस्तेमाल करें. इससे यह कंट्रोल किया जा सकता है कि कॉन्टेंट को स्टीरियो में डाउनमिक्स किया जाए (2 की वैल्यू का इस्तेमाल करने पर) या चैनलों की नेटिव संख्या का इस्तेमाल करके आउटपुट किया जाए (उस संख्या के बराबर या उससे ज़्यादा की वैल्यू का इस्तेमाल करने पर). उदाहरण के लिए, 6 या उससे ज़्यादा की वैल्यू से, 5.1 कॉन्टेंट फ़ीड करने पर, डिकोडर को छह चैनल आउटपुट करने के लिए कॉन्फ़िगर किया जाएगा.
• [C-SR-3] डिकोड करते समय, डिकोडर को KEY_CHANNEL_MASK बटन की मदद से, आउटपुट फ़ॉर्मैट में इस्तेमाल किए जा रहे चैनल मास्क का विज्ञापन करने का सुझाव दिया जाता है. इसके लिए, android.media.AudioFormat के कॉन्स्टेंट का इस्तेमाल करें. उदाहरण के लिए: CHANNEL_OUT_5POINT1.

5.1.3. ऑडियो कोडेक के बारे में जानकारी

फ़ॉर्मैट/कोडेक	जानकारी	इस्तेमाल किए जा सकने वाले फ़ाइल टाइप/कंटेनर फ़ॉर्मैट
MPEG-4 AAC प्रोफ़ाइल (AAC LC)	स्टैंडर्ड सैंपलिंग रेट (8 से 48 किलोहर्ट्ज़) के साथ, मोनो/स्टीरियो/5.0/5.1 कॉन्टेंट के लिए काम करता है.	3GPP (.3gp) MPEG-4 (.mp4, .m4a) ADTS रॉ AAC (.aac, ADIF काम नहीं करता) एमपीईजी-टीएस (.ts, आगे-पीछे नहीं किया जा सकता, सिर्फ़ डीकोड किया जा सकता है) Matroska (.mkv, सिर्फ़ डिकोड करने के लिए)
MPEG-4 HE AAC Profile (AAC+)	मोनो/स्टीरियो/5.0/5.1 ऑडियो वाले कॉन्टेंट के लिए, 16 से 48 किलोहर्ट्ज़ के स्टैंडर्ड सैंपलिंग रेट की सुविधा.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
MPEG-4 HE AACv2 प्रोफ़ाइल (बेहतर AAC+)	मोनो/स्टीरियो/5.0/5.1 ऑडियो वाले कॉन्टेंट के लिए, 16 से 48 किलोहर्ट्ज़ के स्टैंडर्ड सैंपलिंग रेट की सुविधा.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
AAC ELD (बेहतर कम इंतज़ार वाला AAC)	मोनो/स्टीरियो कॉन्टेंट के लिए, 16 से लेकर 48 किलोहर्ट्ज़ तक के स्टैंडर्ड सैंपलिंग रेट का इस्तेमाल किया जा सकता है.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
USAC	मोनो/स्टीरियो कॉन्टेंट के लिए, 7.35 से 48 kHz तक के स्टैंडर्ड सैंपलिंग रेट का इस्तेमाल किया जा सकता है.	MPEG-4 (.mp4, .m4a)
AMR-NB	8 केएचज़ पर सैंपल किए गए 4.75 से 12.2 केबीपीएस	3GPP (.3gp)
AMR-WB	AMR-WB, Adaptive Multi-Rate - Wideband Speech Codec के मुताबिक, 16 किलोहर्ट्ज़ पर सैंपल किए गए 6.60 केबीटी/सेकंड से 23.85 केबीटी/सेकंड तक के नौ रेट	3GPP (.3gp)
FLAC	एन्कोडर और डिकोडर, दोनों के लिए: कम से कम मोनो और स्टीरियो मोड काम करने चाहिए. 192 किलोहर्ट्ज़ तक के सैंपल रेट काम करने चाहिए. साथ ही, 16-बिट और 24-बिट रिज़ॉल्यूशन काम करने चाहिए. फ़्लोटिंग पॉइंट ऑडियो कॉन्फ़िगरेशन के साथ, FLAC 24-बिट ऑडियो डेटा मैनेजमेंट की सुविधा ज़रूर होनी चाहिए.	FLAC (.flac) MPEG-4 (.mp4, .m4a, सिर्फ़ डिकोड करने के लिए) Matroska (.mkv, सिर्फ़ डिकोड करने के लिए)
MP3	मोनो/स्टीरियो 8-320 केबीपीएस कॉन्स्टेंट (सीबीआर) या वैरिएबल बिटरेट (वीबीआर)	MP3 (.mp3) MPEG-4 (.mp4, .m4a, सिर्फ़ डिकोड करने के लिए) Matroska (.mkv, सिर्फ़ डिकोड करने के लिए)
MIDI	एमआईडीआई टाइप 0 और 1. डीएलएस का वर्शन 1 और 2. XMF और Mobile XMF. रिंगटोन के लिए RTTTL/RTX, OTA, और iMelody फ़ॉर्मैट का इस्तेमाल किया जा सकता है	टाइप 0 और 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) iMelody (.imy)
Vorbis	डिकोडिंग: 8000, 12000, 16000, 24000, और 48000 हर्ट्ज़ की सैंपलिंग रेट वाले मोनो, स्टीरियो, 5.0, और 5.1 कॉन्टेंट के लिए काम करता है. एंकोडिंग: 8000, 12000, 16000, 24000, और 48000 हर्ट्ज़ की सैंपलिंग रेट वाले मोनो और स्टीरियो कॉन्टेंट के लिए काम करता है.	Ogg (.ogg) MPEG-4 (.mp4, .m4a, सिर्फ़ डिकोड करने के लिए) Matroska (.mkv) Webm (.webm)
PCM/WAVE	PCM कोडेक, 16-बिट लीनियर PCM और 16-बिट फ़्लोट के साथ काम करना चाहिए. WAVE एक्सट्रैक्टर में 16-बिट, 24-बिट, 32-बिट लीनियर PCM, और 32-बिट फ़्लोट (हार्डवेयर की सीमा तक रेट) का इस्तेमाल किया जा सकता है. सैंपलिंग रेट, 8 किलोहर्ट्ज़ से लेकर 192 किलोहर्ट्ज़ के बीच होने चाहिए.	WAVE (.wav)
Opus	डिकोडिंग: 8000, 12000, 16000, 24000, और 48000 हर्ट्ज़ की सैंपलिंग रेट के साथ, मोनो, स्टीरियो, 5.0, और 5.1 कॉन्टेंट के लिए काम करता है. कोडिंग: 8000, 12000, 16000, 24000, और 48000 हर्ट्ज़ की सैंपलिंग रेट के साथ, मोनो और स्टीरियो कॉन्टेंट के लिए काम करता है.	Ogg (.ogg) MPEG-4 (.mp4, .m4a, सिर्फ़ डिकोड करने के लिए) Matroska (.mkv) Webm (.webm)

5.1.4. इमेज को कोड में बदलना

ज़्यादा जानकारी के लिए, 5.1.6 देखें. इमेज कोडेक की जानकारी.

डिवाइस पर इमेज एन्कोड करने की सुविधा, इन फ़ॉर्मैट में काम करनी चाहिए:

• [C-0-1] JPEG
• [C-0-2] PNG
• [C-0-3] WebP

अगर डिवाइस पर, मीडिया टाइप MIMETYPE_IMAGE_ANDROID_HEIC के लिए android.media.MediaCodec के ज़रिए HEIC एन्कोडिंग की सुविधा काम करती है, तो:

• [C-1-1] हार्डवेयर से तेज़ किया गया HEVC एन्कोडर कोडेक उपलब्ध कराना ज़रूरी है. यह कोडेक, BITRATE_MODE_CQ बिटरेट कंट्रोल मोड, HEVCProfileMainStill प्रोफ़ाइल, और 512 x 512 पिक्सल के फ़्रेम साइज़ के साथ काम करना चाहिए.

5.1.5. इमेज डिकोड करना

ज़्यादा जानकारी के लिए, 5.1.6 देखें. इमेज कोडेक की जानकारी.

डिवाइस पर इमेज एन्कोडिंग को डिकोड करने की सुविधा होनी चाहिए:

• [C-0-1] JPEG
• [C-0-2] GIF
• [C-0-3] PNG
• [C-0-4] BMP
• [C-0-5] WebP
• [C-0-6] रॉ

अगर डिवाइस में HEVC वीडियो को डिकोड करने की सुविधा काम करती है, तो: * [C-1-1] डिवाइस में HEIF (HEIC) इमेज को डिकोड करने की सुविधा काम करनी चाहिए.

ज़्यादा बिट-डेप्थ फ़ॉर्मैट (हर चैनल के लिए 9 से ज़्यादा बिट) के साथ काम करने वाले इमेज डिकोडर:

• [C-2-1] अगर ऐप्लिकेशन से अनुरोध किया जाता है, तो 8-बिट वाले मिलते-जुलते फ़ॉर्मैट को आउटपुट करने की सुविधा होनी चाहिए. उदाहरण के लिए, android.graphics.Bitmap के ARGB_8888 कॉन्फ़िगरेशन के ज़रिए.

5.1.6. इमेज कोडेक की जानकारी

फ़ॉर्मैट/कोडेक	जानकारी	इस्तेमाल किए जा सकने वाले फ़ाइल टाइप/कंटेनर फ़ॉर्मैट
JPEG	बेस+प्रोग्रेसिव	JPEG (.jpg)
GIF		GIF (.gif)
PNG		PNG (.png)
BMP		BMP (.bmp)
WebP		WebP (.webp)
Raw		ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw)
HEIF	इमेज, इमेज कलेक्शन, इमेज का क्रम	HEIF (.heif), HEIC (.heic)

MediaCodec API के ज़रिए एक्सपोज़ की गई इमेज एन्कोडर और डीकोडर

• [C-1-1] CodecCapabilities की मदद से, YUV420 8:8:8 फ़्लेक्सिबल कलर फ़ॉर्मैट (COLOR_FormatYUV420Flexible) के साथ काम करना चाहिए.

• [C-SR-1] इनपुट के लिए, Surface mode में RGB888 कलर फ़ॉर्मैट का इस्तेमाल करने का सुझाव दिया जाता है.

• [C-1-3] यह ज़रूरी है कि यह प्लैनर या सेमी-प्लानर YUV420 8:8:8 कलर फ़ॉर्मैट में से कम से कम एक फ़ॉर्मैट के साथ काम करे: COLOR_FormatYUV420PackedPlanar (COLOR_FormatYUV420Planar के बराबर) या COLOR_FormatYUV420PackedSemiPlanar (COLOR_FormatYUV420SemiPlanar के बराबर). हमारा सुझाव है कि यह दोनों फ़ॉर्मैट के साथ काम करे.

5.1.7. वीडियो कोडेक

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

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

• [C-1-1] वीडियो कोडेक में, आउटपुट और इनपुट बाइटबफ़र के ऐसे साइज़ का इस्तेमाल करना ज़रूरी है जिनमें स्टैंडर्ड और कॉन्फ़िगरेशन के मुताबिक, सबसे बड़े संपीड़ित और अनकंप्रेस किए गए फ़्रेम को शामिल किया जा सके. साथ ही, इनका साइज़ ज़रूरत से ज़्यादा न हो.

• [C-1-2] वीडियो एन्कोडर और डिकोडर को CodecCapabilities की मदद से, YUV420 8:8:8 फ़्लेक्सिबल कलर फ़ॉर्मैट (COLOR_FormatYUV420Flexible) के साथ काम करना चाहिए.

• [C-1-3] वीडियो एन्कोडर और डिकोडर, प्लैनर या सेमीप्लेनर YUV420 8:8:8 कलर फ़ॉर्मैट में से कम से कम एक के साथ काम करने चाहिए: COLOR_FormatYUV420PackedPlanar (COLOR_FormatYUV420Planar के बराबर) या COLOR_FormatYUV420PackedSemiPlanar (COLOR_FormatYUV420SemiPlanar के बराबर). दोनों फ़ॉर्मैट के साथ काम करने का सुझाव दिया जाता है.

• [C-SR-1] हमारा सुझाव है कि वीडियो एन्कोडर और डिकोडर, कम से कम एक हार्डवेयर ऑप्टिमाइज़्ड प्लैनर या सेमी-प्लानर YUV420 8:8:8 कलर फ़ॉर्मैट (YV12, NV12, NV21 या वेंडर के ऑप्टिमाइज़ किए गए मिलते-जुलते फ़ॉर्मैट) के साथ काम करें.

• [C-1-5] ज़्यादा बिट-डेप्थ फ़ॉर्मैट (हर चैनल के लिए 9 से ज़्यादा बिट) के साथ काम करने वाले वीडियो डिकोडर को, 8-बिट वाले मिलते-जुलते फ़ॉर्मैट को आउटपुट करने की सुविधा देनी चाहिए. ऐसा तब करना होगा, जब ऐप्लिकेशन से अनुरोध किया जाए. यह android.media.MediaCodecInfo के ज़रिए YUV420 8:8:8 कलर फ़ॉर्मैट के साथ काम करने की सुविधा के तौर पर दिखना चाहिए.

अगर डिवाइस में एचडीआर प्रोफ़ाइल के साथ काम करने की सुविधा का विज्ञापन, Display.HdrCapabilities के ज़रिए किया जाता है, तो:

• [C-2-1] एचडीआर स्टैटिक मेटाडेटा को पार्स और मैनेज करने की सुविधा होनी चाहिए.

अगर डिवाइस के लागू होने की जानकारी, MediaCodecInfo.CodecCapabilities क्लास में FEATURE_IntraRefresh के ज़रिए, इंटरा रीफ़्रेश की सुविधा के साथ दी जाती है, तो:

• [C-3-1] यह ज़रूरी है कि डिवाइस, 10 से 60 फ़्रेम की रेंज में रीफ़्रेश पीरियड के साथ काम करे. साथ ही, कॉन्फ़िगर किए गए रीफ़्रेश पीरियड के 20% के अंदर सटीक तरीके से काम करे.

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

• [C-4-1] अगर Surface आउटपुट का इस्तेमाल करके कॉन्फ़िगर किया गया है, तो डिफ़ॉल्ट रूप से हार्डवेयर डिसप्ले के लिए ऑप्टिमाइज़ किए गए कलर फ़ॉर्मैट का इस्तेमाल करना चाहिए.
• [C-4-2] अगर Surface आउटपुट का इस्तेमाल न करने के लिए कॉन्फ़िगर किया गया है, तो डिफ़ॉल्ट रूप से YUV420 8:8:8 कलर फ़ॉर्मैट का इस्तेमाल करना चाहिए. यह फ़ॉर्मैट, सीपीयू के लिए ऑप्टिमाइज़ किया गया है.

5.1.8. वीडियो कोडेक की सूची

फ़ॉर्मैट/कोडेक	जानकारी	इस्तेमाल किए जा सकने वाले फ़ाइल टाइप/कंटेनर फ़ॉर्मैट
H.263		3GPP (.3gp) MPEG-4 (.mp4) Matroska (.mkv, सिर्फ़ डिकोड करने के लिए)
H.264 AVC	ज़्यादा जानकारी के लिए, सेक्शन 5.2 और 5.3 देखें	3GPP (.3gp) MPEG-4 (.mp4) MPEG-2 टीएस (.ts, इसमें आगे-पीछे नहीं जाया जा सकता) Matroska (.mkv, सिर्फ़ डिकोड करने के लिए)
H.265 HEVC	ज़्यादा जानकारी के लिए, सेक्शन 5.3 देखें	MPEG-4 (.mp4) Matroska (.mkv, सिर्फ़ डिकोड करने के लिए)
MPEG-2	मुख्य प्रोफ़ाइल	MPEG2-TS (.ts, इसमें आगे-पीछे नहीं जाया जा सकता) MPEG-4 (.mp4, सिर्फ़ डिकोड करने के लिए) Matroska (.mkv, सिर्फ़ डिकोड करने के लिए)
MPEG-4 SP		3GPP (.3gp) MPEG-4 (.mp4) Matroska (.mkv, सिर्फ़ डिकोड करने के लिए)
VP8	ज़्यादा जानकारी के लिए, सेक्शन 5.2 और 5.3 देखें	WebM (.webm) Matroska (.mkv)
VP9	ज़्यादा जानकारी के लिए, सेक्शन 5.3 देखें	WebM (.webm) Matroska (.mkv)

5.1.9. मीडिया कोडेक की सुरक्षा

डिवाइस में लागू करने के लिए, यह ज़रूरी है कि मीडिया कोडेक की सुरक्षा से जुड़ी सुविधाओं का पालन किया जाए, जैसा कि यहां बताया गया है.

Android में OMX, एक क्रॉस-प्लैटफ़ॉर्म मल्टीमीडिया ऐक्सेलरेशन एपीआई के साथ-साथ, Codec 2.0, एक कम ओवरहेड मल्टीमीडिया ऐक्सेलरेशन एपीआई की सुविधा शामिल है.

अगर डिवाइस पर मल्टीमीडिया की सुविधा काम करती है, तो:

• [C-1-1] Android Open Source Project की तरह, OMX या Codec 2.0 एपीआई (या दोनों) के ज़रिए मीडिया कोडेक के लिए सहायता देना ज़रूरी है. साथ ही, सुरक्षा उपायों को बंद या गच्चा नहीं देना चाहिए. इसका मतलब यह नहीं है कि हर कोडेक को OMX या Codec 2.0 API में से किसी एक का इस्तेमाल करना ज़रूरी है. इसका मतलब सिर्फ़ यह है कि इनमें से कम से कम एक एपीआई के लिए सहायता उपलब्ध होनी चाहिए. साथ ही, उपलब्ध एपीआई के लिए, सुरक्षा से जुड़ी मौजूदा सुविधाएं भी शामिल होनी चाहिए.
• [C-SR-1] हमारा सुझाव है कि आप Codec 2.0 API के लिए सहायता शामिल करें.

अगर डिवाइस में Codec 2.0 API काम नहीं करता है, तो:

• [C-2-1] डिवाइस पर काम करने वाले हर मीडिया फ़ॉर्मैट और टाइप (एन्कोडर या डिकोडर) के लिए, Android Open Source Project से मिलता-जुलता OMX सॉफ़्टवेयर कोडेक शामिल करना ज़रूरी है. हालांकि, ऐसा तब ही करें, जब यह उपलब्ध हो.
• [C-2-2] ऐसे कोडेक जिनके नाम "OMX.google" से शुरू होते हैं. यह ज़रूरी है कि वे Android ओपन सोर्स प्रोजेक्ट के सोर्स कोड पर आधारित हों.
• [C-SR-2] हमारा सुझाव है कि OMX सॉफ़्टवेयर कोडेक, ऐसी कोडेक प्रोसेस में चलाए जाएं जिसके पास मेमोरी मैपर्स के अलावा, हार्डवेयर ड्राइवर का ऐक्सेस न हो.

अगर डिवाइस पर Codec 2.0 API काम करता है, तो:

• [C-3-1] डिवाइस पर काम करने वाले हर मीडिया फ़ॉर्मैट और टाइप (एन्कोडर या डिकोडर) के लिए, Android Open Source Project (अगर उपलब्ध हो) से मिलते-जुलते Codec 2.0 सॉफ़्टवेयर कोडेक को शामिल करना ज़रूरी है.
• [C-3-2] सॉफ़्टवेयर कोडेक की प्रोसेस में, Codec 2.0 सॉफ़्टवेयर कोडेक को शामिल करना ज़रूरी है. ऐसा Android Open Source Project में बताए गए तरीके के मुताबिक करना होगा, ताकि सॉफ़्टवेयर कोडेक का ऐक्सेस ज़्यादा सटीक तरीके से दिया जा सके.
• [C-3-3] ऐसे कोडेक जिनके नाम "c2.android" से शुरू होते हैं. यह ज़रूरी है कि वे Android ओपन सोर्स प्रोजेक्ट के सोर्स कोड पर आधारित हों.

5.1.10. मीडिया कोडेक की जानकारी

अगर डिवाइस पर मीडिया कोडेक काम करते हैं, तो:

• [C-1-1] एपीआई के ज़रिए, मीडिया कोडेक की विशेषताओं की सही वैल्यू दिखानी चाहिए.MediaCodecInfo

खास तौर पर:

• [C-1-2] "OMX" से शुरू होने वाले नाम वाले कोडेक. OMX API का इस्तेमाल करना ज़रूरी है और नाम, OMX IL के नाम तय करने के दिशा-निर्देशों के मुताबिक होने चाहिए.
• [C-1-3] ऐसे कोडेक जिनके नाम "c2" से शुरू होते हैं. Codec 2.0 API का इस्तेमाल करना ज़रूरी है. साथ ही, इनके नाम, Android के लिए Codec 2.0 के नाम रखने के दिशा-निर्देशों के मुताबिक होने चाहिए.
• [C-1-4] ऐसे कोडेक जिनके नाम "OMX.google" या "c2.android" से शुरू होते हैं. इसे वेंडर या हार्डवेयर-ऐक्सेलरेटेड के तौर पर नहीं दिखाया जाना चाहिए.
• [C-1-5] ऐसे कोडेक जिन्हें कोडेक प्रोसेस (वेंडर या सिस्टम) में चलाया जाता है और जिनके पास मेमोरी ऐलोकेटर और मैपर के अलावा हार्डवेयर ड्राइवर का ऐक्सेस होता है, उन्हें सिर्फ़ सॉफ़्टवेयर के तौर पर नहीं दिखाया जाना चाहिए.
• [C-1-6] Android Open Source Project में मौजूद कोडेक या उस प्रोजेक्ट के सोर्स कोड पर आधारित नहीं होने वाले कोडेक को वेंडर के तौर पर दिखाना ज़रूरी है.
• [C-1-7] हार्डवेयर से तेज़ी लाने की सुविधा का इस्तेमाल करने वाले कोडेक को, हार्डवेयर से तेज़ी लाने की सुविधा के तौर पर दिखाना ज़रूरी है.
• [C-1-8] कोडेक के नाम गुमराह करने वाले नहीं होने चाहिए. उदाहरण के लिए, "डीकोडर" नाम वाले कोडेक में डीकोडिंग की सुविधा होनी चाहिए. साथ ही, "एन्कोडर" नाम वाले कोडेक में एन्कोडिंग की सुविधा होनी चाहिए. जिन कोडेक के नाम में मीडिया फ़ॉर्मैट शामिल हैं वे उन फ़ॉर्मैट के साथ काम करने चाहिए.

अगर डिवाइस पर वीडियो कोडेक काम करते हैं, तो:

• [C-2-1] अगर कोडेक इन साइज़ के साथ काम करता है, तो सभी वीडियो कोडेक को इन साइज़ के लिए, फ़्रेम रेट का डेटा पब्लिश करना होगा:

	एसडी (कम क्वालिटी)	एसडी (अच्छी क्वालिटी)	एचडी 720 पिक्सल	एचडी 1080 पिक्सल	यूएचडी
वीडियो रिज़ॉल्यूशन	176 x 144 पिक्सल (H263, MPEG2, MPEG4) 352 x 288 पिक्सल (MPEG4 एन्कोडर, H263, MPEG2) 320 x 180 पिक्सल (VP8, VP8) 320 x 240 पिक्सल (अन्य)	704 x 576 पिक्सल (H263) 640 x 360 पिक्सल (VP8, VP9) 640 x 480 पिक्सल (MPEG4 एन्कोडर) 720 x 480 पिक्सल (अन्य)	1408 x 1152 पिक्सल (H263) 1280 x 720 पिक्सल (अन्य)	1920 x 1080 पिक्सल (MPEG4 के अलावा)	3840 x 2160 पिक्सल (एचईवीसी, VP9)

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

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

अगर डिवाइस पर किसी वीडियो एन्कोडर को लागू किया गया है और उसे तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराया गया है, तो:

• दो स्लाइडिंग विंडो में, इंटरफ़्रेम (आई-फ़्रेम) इंटरवल के बीच बिटरेट से 15% ज़्यादा नहीं होना चाहिए.
• यह बिटरेट, 1 सेकंड की स्लाइडिंग विंडो में, बिटरेट से 100% से ज़्यादा नहीं होना चाहिए.

अगर डिवाइस में एम्बेड की गई स्क्रीन डिसप्ले की डायगनल लंबाई कम से कम 2.5 इंच है या उसमें वीडियो आउटपुट पोर्ट है या android.hardware.camera.any सुविधा फ़्लैग की मदद से कैमरे के काम करने की जानकारी दी गई है, तो:

• [C-1-1] इसमें कम से कम एक VP8 या H.264 वीडियो एन्कोडर का इस्तेमाल करना ज़रूरी है. साथ ही, इसे तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराना होगा.
• यह VP8 और H.264, दोनों वीडियो एन्कोडर के साथ काम करना चाहिए. साथ ही, इसे तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराना चाहिए.

अगर डिवाइस में H.264, VP8, VP9 या HEVC वीडियो एन्कोडर का इस्तेमाल किया जा सकता है और उसे तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराया जाता है, तो:

• [C-2-1] डाइनैमिक तौर पर कॉन्फ़िगर किए जा सकने वाले बिटरेट के साथ काम करना चाहिए.
• यह अलग-अलग फ़्रेम रेट के साथ काम करना चाहिए. इसमें वीडियो एन्कोडर को इनपुट बफ़र के टाइमस्टैंप के आधार पर, फ़्रेम की तय अवधि तय करनी चाहिए. साथ ही, उस फ़्रेम की अवधि के आधार पर बिटरेट तय करना चाहिए.

अगर डिवाइस में MPEG-4 SP वीडियो एन्कोडर की सुविधा काम करती है और इसे तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराया जाता है, तो:

• यह ज़रूरी है कि काम करने वाले एन्कोडर के लिए, डाइनैमिक तौर पर कॉन्फ़िगर की जा सकने वाली बिटरेट की सुविधा काम करे.

अगर डिवाइस में हार्डवेयर की मदद से तेज़ी से वीडियो या इमेज एन्कोड करने की सुविधा उपलब्ध है और एक या एक से ज़्यादा अटैच किए गए या प्लग किए जा सकने वाले हार्डवेयर कैमरे काम करते हैं, तो android.camera एपीआई के ज़रिए उन्हें दिखाया जा सकता है:

• [C-4-1] हार्डवेयर से तेज़ की गई वीडियो और इमेज एन्कोडर के लिए, हार्डवेयर कैमरे से फ़्रेम को एन्कोड करने की सुविधा ज़रूरी है.
• सभी वीडियो या इमेज एन्कोडर की मदद से, हार्डवेयर कैमरे से फ़्रेम को एन्कोड करने की सुविधा होनी चाहिए.

अगर डिवाइस पर एचडीआर कोडिंग की सुविधा उपलब्ध है, तो:

• [C-SR-1] हमारा सुझाव है कि आप एचडीआर फ़ॉर्मैट को एसडीआर फ़ॉर्मैट में बदलने के लिए, आसानी से ट्रांसकोड करने वाले एपीआई के लिए प्लग इन उपलब्ध कराएं.

5.2.1. H.263

अगर डिवाइस में H.263 एन्कोडर काम करते हैं और तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध होते हैं, तो:

• [C-1-1] यह ज़रूरी है कि यह बेसलाइन प्रोफ़ाइल लेवल 45 के साथ काम करे.
• यह ज़रूरी है कि काम करने वाले एन्कोडर के लिए, डाइनैमिक तौर पर कॉन्फ़िगर की जा सकने वाली बिटरेट की सुविधा काम करे.

5.2.2. H.264

अगर डिवाइस में H.264 कोडेक काम करता है, तो:

• [C-1-1] यह ज़रूरी है कि यह बेसलाइन प्रोफ़ाइल लेवल 3 के साथ काम करे. हालांकि, ASO (स्लाइस का मनमुताबिक क्रम), FMO (फ़्लेक्सिबल मैक्रोब्लॉक ऑर्डरिंग) और RS (ज़रूरत से ज़्यादा स्लाइस) के लिए सहायता देना ज़रूरी नहीं है. इसके अलावा, अन्य Android डिवाइसों के साथ काम करने के लिए, हमारा सुझाव है कि एन्कोडर, बेसलाइन प्रोफ़ाइल के लिए ASO, FMO, और RS का इस्तेमाल न करें.
• [C-1-2] यह ज़रूरी है कि यह नीचे दी गई टेबल में बताई गई एसडी (स्टैंडर्ड डेफ़िनिशन) वीडियो एन्कोडिंग प्रोफ़ाइलों के साथ काम करे.
• मुख्य प्रोफ़ाइल के लेवल 4 के साथ काम करना चाहिए.
• यह एचडी (हाई डेफ़िनिशन) वीडियो एन्कोडिंग प्रोफ़ाइलों के साथ काम करना चाहिए, जैसा कि नीचे दी गई टेबल में बताया गया है.

अगर डिवाइस में मीडिया एपीआई की मदद से, 720p या 1080p रिज़ॉल्यूशन वाले वीडियो के लिए H.264 एन्कोडिंग की सुविधा काम करती है, तो:

• [C-2-1] यह ज़रूरी है कि यह टूल, नीचे दी गई टेबल में मौजूद एन्कोडिंग प्रोफ़ाइलों के साथ काम करे.

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

5.2.3. VP8

अगर डिवाइस में VP8 कोडेक काम करता है, तो:

• [C-1-1] यह ज़रूरी है कि यह एसडी वीडियो एन्कोडिंग प्रोफ़ाइलों के साथ काम करे.
• यह एचडी (हाई डेफ़िनिशन) वीडियो एन्कोडिंग प्रोफ़ाइलों के साथ काम करना चाहिए.
• [C-1-2] Matroska WebM फ़ाइलें लिखने की सुविधा होनी चाहिए.
• ऐसा हार्डवेयर VP8 कोडेक उपलब्ध कराना चाहिए जो WebM प्रोजेक्ट आरटीसी हार्डवेयर कोडिंग की ज़रूरी शर्तों को पूरा करता हो. इससे, वेब वीडियो स्ट्रीमिंग और वीडियो कॉन्फ़्रेंस की सेवाओं की अच्छी क्वालिटी को पक्का किया जा सकेगा.

अगर डिवाइस में लागू किए गए मीडिया एपीआई के ज़रिए, 720p या 1080p रिज़ॉल्यूशन वाले वीडियो के लिए VP8 एन्कोडिंग की सुविधा काम करती है, तो:

• [C-2-1] यह ज़रूरी है कि यह नीचे दी गई टेबल में मौजूद एन्कोडिंग प्रोफ़ाइलों के साथ काम करे.

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

5.2.4. VP9

अगर डिवाइस में VP9 कोडेक काम करता है, तो:

• [C-1-2] यह प्रोफ़ाइल 0 लेवल 3 के साथ काम करना चाहिए.
• [C-1-1] Matroska WebM फ़ाइलें लिखने की सुविधा होनी चाहिए.
• [C-1-3] CodecPrivate डेटा जनरेट करना ज़रूरी है.
• इस टेबल में बताई गई एचडी डिकोडिंग प्रोफ़ाइलों के साथ काम करना चाहिए.
• [C-SR-1] हमारा सुझाव है कि अगर हार्डवेयर एन्कोडर है, तो एचडी डिकोडिंग प्रोफ़ाइलों का इस्तेमाल करें. इन प्रोफ़ाइलों के बारे में यहां दी गई टेबल में बताया गया है.

	एसडी	एचडी 720 पिक्सल	एचडी 1080 पिक्सल	यूएचडी
वीडियो रिज़ॉल्यूशन	720 x 480 पिक्सल	1280 x 720 पिक्सल	1920 x 1080 पिक्सल	3840 x 2160 पिक्सल
वीडियो फ़्रेम रेट	30 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड
वीडियो बिटरेट	1.6 एमबीपीएस	4 एमबीपीएस	5 एमबीपीएस	20 एमबीपीएस

अगर डिवाइस में Media APIs की मदद से, प्रोफ़ाइल 2 या प्रोफ़ाइल 3 के साथ काम करने का दावा किया जाता है, तो:

• 12-बिट फ़ॉर्मैट का इस्तेमाल करना ज़रूरी नहीं है.

5.2.5. H.265

अगर डिवाइस में H.265 कोडेक काम करता है, तो:

• [C-1-1] मुख्य प्रोफ़ाइल के लेवल 3 के साथ काम करना चाहिए.
• यह एचडी एन्कोडिंग प्रोफ़ाइलों के साथ काम करना चाहिए, जैसा कि नीचे दी गई टेबल में बताया गया है.
• [C-SR-1] हमारा सुझाव है कि अगर आपके पास हार्डवेयर एन्कोडर है, तो एचडी एन्कोडिंग प्रोफ़ाइलों का इस्तेमाल करें. इन प्रोफ़ाइलों के बारे में यहां दी गई टेबल में बताया गया है.

	एसडी	एचडी 720 पिक्सल	एचडी 1080 पिक्सल	यूएचडी
वीडियो रिज़ॉल्यूशन	720 x 480 पिक्सल	1280 x 720 पिक्सल	1920 x 1080 पिक्सल	3840 x 2160 पिक्सल
वीडियो फ़्रेम रेट	30 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड
वीडियो बिटरेट	1.6 एमबीपीएस	4 एमबीपीएस	5 एमबीपीएस	20 एमबीपीएस

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

अगर डिवाइस पर VP8, VP9, H.264 या H.265 कोडेक काम करते हैं, तो:

• [C-1-1] यह ज़रूरी है कि डिवाइस पर सभी VP8, VP9, H.264, और H.265 कोडेक के लिए, एक ही स्ट्रीम में स्टैंडर्ड Android API की मदद से, रियल टाइम में डाइनैमिक वीडियो रिज़ॉल्यूशन और फ़्रेम रेट स्विच करने की सुविधा काम करे. साथ ही, यह सुविधा डिवाइस पर हर कोडेक के लिए, सबसे ज़्यादा रिज़ॉल्यूशन तक काम करे.

5.3.1. MPEG-2

अगर डिवाइस में MPEG-2 डिकोडर काम करते हैं, तो:

• [C-1-1] मुख्य प्रोफ़ाइल के हाई लेवल के साथ काम करना चाहिए.

5.3.2. H.263

अगर डिवाइस में H.263 डीकोडर काम करते हैं, तो:

• [C-1-1] यह ज़रूरी है कि यह बेसलाइन प्रोफ़ाइल के लेवल 30 और लेवल 45 के साथ काम करे.

5.3.3. MPEG-4

अगर डिवाइस में MPEG-4 डिकोडर लागू किए गए हैं, तो:

• [C-1-1] यह ज़रूरी है कि ऐप्लिकेशन, सिंपल प्रोफ़ाइल के लेवल 3 के साथ काम करे.

5.3.4. H.264

अगर डिवाइस में H.264 डीकोडर काम करते हैं, तो:

• [C-1-1] मुख्य प्रोफ़ाइल लेवल 3.1 और बेसलाइन प्रोफ़ाइल के साथ काम करना चाहिए. ASO (स्लाइस का मनमुताबिक क्रम), FMO (फ़्लेक्सिबल मैक्रोब्लॉक ऑर्डरिंग), और RS (रिडंडेंट स्लाइस) के लिए, सहायता देना ज़रूरी नहीं है.
• [C-1-2] यह ज़रूरी है कि डिवाइस, नीचे दी गई टेबल में दी गई एसडी (स्टैंडर्ड डेफ़िनिशन) प्रोफ़ाइल वाले वीडियो को डिकोड कर सके. साथ ही, यह भी ज़रूरी है कि डिवाइस, बेसलाइन प्रोफ़ाइल और मुख्य प्रोफ़ाइल लेवल 3.1 (इसमें 720p30 भी शामिल है) के साथ एन्कोड किए गए वीडियो को डिकोड कर सके.
• यह एचडी (हाई डेफ़िनिशन) प्रोफ़ाइलों वाले वीडियो को डिकोड कर सकता है, जैसा कि नीचे दी गई टेबल में बताया गया है.

अगर Display.getSupportedModes() तरीके से रिपोर्ट की गई ऊंचाई, वीडियो रिज़ॉल्यूशन के बराबर या उससे ज़्यादा है, तो डिवाइस पर लागू होने वाले ये नियम:

• [C-2-1] यह ज़रूरी है कि डिवाइस, नीचे दी गई टेबल में बताई गई एचडी 720p वीडियो डिकोडिंग प्रोफ़ाइल के साथ काम करे.
• [C-2-2] यह ज़रूरी है कि डिवाइस, नीचे दी गई टेबल में दी गई एचडी 1080p वीडियो डिकोडिंग प्रोफ़ाइल के साथ काम करे.

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

5.3.5. H.265 (HEVC)

अगर डिवाइस में H.265 कोडेक काम करता है, तो:

• [C-1-1] यह ज़रूरी है कि यह मेन प्रोफ़ाइल लेवल 3 के मुख्य टीयर और एसडी वीडियो डिकोड करने वाली प्रोफ़ाइलों के साथ काम करे, जैसा कि नीचे दी गई टेबल में बताया गया है.
• यह एचडी डिकोडिंग प्रोफ़ाइलों के साथ काम करना चाहिए, जैसा कि नीचे दी गई टेबल में बताया गया है.
• [C-1-2] अगर डिवाइस में हार्डवेयर डिकोडर है, तो यह ज़रूरी है कि वह एचडी डिकोडिंग प्रोफ़ाइल के साथ काम करे. इन प्रोफ़ाइलों के बारे में नीचे दी गई टेबल में बताया गया है.

अगर Display.getSupportedModes() तरीके से रिपोर्ट की गई ऊंचाई, वीडियो रिज़ॉल्यूशन के बराबर या उससे ज़्यादा है, तो:

• [C-2-1] डिवाइस पर, 720, 1080, और यूएचडी प्रोफ़ाइलों को डिकोड करने के लिए, H.265 या VP9 में से कम से कम एक कोडिंग का इस्तेमाल किया जाना चाहिए.

	एसडी (कम क्वालिटी)	एसडी (अच्छी क्वालिटी)	एचडी 720 पिक्सल	एचडी 1080 पिक्सल	यूएचडी
वीडियो रिज़ॉल्यूशन	352 x 288 पिक्सल	720 x 480 पिक्सल	1280 x 720 पिक्सल	1920 x 1080 पिक्सल	3840 x 2160 पिक्सल
वीडियो फ़्रेम रेट	30 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड	30/60 एफ़पीएस (60 एफ़पीएसH.265 हार्डवेयर डिकोडिंग की सुविधा वाला टीवी)	60 एफ़पीएस (फ़्रेम प्रति सेकंड)
वीडियो बिटरेट	600 केबीपीएस	1.6 एमबीपीएस	4 एमबीपीएस	5 एमबीपीएस	20 एमबीपीएस

अगर डिवाइस पर Media API के ज़रिए एचडीआर प्रोफ़ाइल काम करने का दावा किया जाता है, तो:

• [C-3-1] डिवाइस में एचडीआर की सुविधा लागू करने के लिए, यह ज़रूरी है कि वह ऐप्लिकेशन से ज़रूरी एचडीआर मेटाडेटा स्वीकार करे. साथ ही, बिटरस्ट्रीम और/या कंटेनर से ज़रूरी एचडीआर मेटाडेटा को निकालने और उसे आउटपुट करने की सुविधा भी दे.
• [C-3-2] डिवाइस पर एचडीआर कॉन्टेंट को डिवाइस की स्क्रीन या स्टैंडर्ड वीडियो आउटपुट पोर्ट (उदाहरण के लिए, एचडीएमआई).

5.3.6. VP8

अगर डिवाइस में VP8 कोडेक काम करता है, तो:

• [C-1-1] यह ज़रूरी है कि डिवाइस, नीचे दी गई टेबल में मौजूद एसडी डिकोडिंग प्रोफ़ाइलों के साथ काम करे.
• ऐसे हार्डवेयर VP8 कोडेक का इस्तेमाल करना चाहिए जो ज़रूरी शर्तों को पूरा करता हो.
• यह टेबल में दी गई एचडी डिकोडिंग प्रोफ़ाइलों के साथ काम करनी चाहिए.

अगर Display.getSupportedModes() तरीके से मिली ऊंचाई, वीडियो रिज़ॉल्यूशन के बराबर या उससे ज़्यादा है, तो:

• [C-2-1] डिवाइस पर, नीचे दी गई टेबल में बताई गई 720p प्रोफ़ाइलें काम करनी चाहिए.
• [C-2-2] डिवाइस पर, नीचे दी गई टेबल में बताई गई 1080p प्रोफ़ाइलों का इस्तेमाल किया जा सकता है.

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

5.3.7. VP9

अगर डिवाइस में VP9 कोडेक काम करता है, तो:

• [C-1-1] यह ज़रूरी है कि डिवाइस, एसडी वीडियो को डिकोड करने वाली प्रोफ़ाइलों के साथ काम करे. इन प्रोफ़ाइलों के बारे में यहां दी गई टेबल में बताया गया है.
• यह एचडी डिकोडिंग प्रोफ़ाइलों के साथ काम करना चाहिए, जैसा कि नीचे दी गई टेबल में बताया गया है.

अगर डिवाइस पर VP9 कोडेक और हार्डवेयर डिकोडर काम करते हैं, तो:

• [C-2-1] एचडी डिकोडिंग प्रोफ़ाइलों के साथ काम करना चाहिए, जैसा कि नीचे दी गई टेबल में बताया गया है.

अगर Display.getSupportedModes() तरीके से रिपोर्ट की गई ऊंचाई, वीडियो रिज़ॉल्यूशन के बराबर या उससे ज़्यादा है, तो:

• [C-3-1] डिवाइस पर, 720, 1080, और यूएचडी प्रोफ़ाइलों को डिकोड करने के लिए, VP9 या H.265 में से कम से कम एक कोडिंग सिस्टम का इस्तेमाल किया जाना चाहिए.

	एसडी (कम क्वालिटी)	एसडी (अच्छी क्वालिटी)	एचडी 720 पिक्सल	एचडी 1080 पिक्सल	यूएचडी
वीडियो रिज़ॉल्यूशन	320 x 180 पिक्सल	640 x 360 पिक्सल	1280 x 720 पिक्सल	1920 x 1080 पिक्सल	3840 x 2160 पिक्सल
वीडियो फ़्रेम रेट	30 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड	30 एफ़पीएस (60 एफ़पीएसटीवी पर VP9 हार्डवेयर डिकोडिंग)	60 एफ़पीएस (फ़्रेम प्रति सेकंड)
वीडियो बिटरेट	600 केबीपीएस	1.6 एमबीपीएस	4 एमबीपीएस	5 एमबीपीएस	20 एमबीपीएस

अगर डिवाइस में 'CodecProfileLevel' मीडिया एपीआई की मदद से, VP9Profile2 या VP9Profile3 के साथ काम करने का दावा किया जाता है, तो:

• 12-बिट फ़ॉर्मैट का इस्तेमाल करना ज़रूरी नहीं है.

अगर डिवाइस में, मीडिया एपीआई के ज़रिए एचडीआर प्रोफ़ाइल (VP9Profile2HDR, VP9Profile2HDR10Plus, VP9Profile3HDR, VP9Profile3HDR10Plus) के साथ काम करने का दावा किया जाता है, तो:

• [C-4-1] डिवाइस पर लागू होने वाले एप्लिकेशन में, एचडीआर मेटाडेटा की ज़रूरी शर्तें पूरी होनी चाहिए. जैसे, सभी एचडीआर प्रोफ़ाइलों के लिए KEY_HDR_STATIC_INFO और एचडीआर10 प्लस प्रोफ़ाइलों के लिए 'KEY_HDR10_PLUS_INFO'. साथ ही, इनमें बिटरस्ट्रीम और/या कंटेनर से ज़रूरी एचडीआर मेटाडेटा को निकालने और उसे आउटपुट करने की सुविधा भी होनी चाहिए.
• [C-4-2] डिवाइस पर एचडीआर वीडियो को डिवाइस की स्क्रीन या स्टैंडर्ड वीडियो आउटपुट पोर्ट (उदाहरण के लिए, एचडीएमआई).

5.3.8. Dolby Vision

अगर डिवाइस में, HDR_TYPE_DOLBY_VISION के ज़रिए Dolby Vision डिकोडर के साथ काम करने की सुविधा का एलान किया गया है, तो:

• [C-1-1] आपको Dolby Vision की सुविधा वाला एक्सट्रैक्टर देना होगा.
• [C-1-2] डिवाइस की स्क्रीन या स्टैंडर्ड वीडियो आउटपुट पोर्ट (उदाहरण के लिए, एचडीएमआई).
• [C-1-3] अगर पिछली वर्शन के साथ काम करने वाली बेस लेयर मौजूद हैं, तो उनका ट्रैक आईडी, एक साथ काम करने वाली Dolby Vision लेयर के ट्रैक आईडी जैसा होना चाहिए.

5.3.9. AV1

अगर डिवाइस पर AV1 कोडेक काम करता है, तो:

• [C-1-1] यह ज़रूरी है कि डिवाइस, 10-बिट वाले कॉन्टेंट के साथ-साथ प्रोफ़ाइल 0 के साथ काम करे.

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

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

5.4.1. रॉ ऑडियो कैप्चर और माइक्रोफ़ोन की जानकारी

अगर डिवाइस पर android.hardware.microphone लागू किया जाता है, तो:

• [C-1-1] किसी भी AudioRecord या AAudio इनपुट स्ट्रीम के लिए, रॉ ऑडियो कॉन्टेंट को कैप्चर करने की अनुमति होनी चाहिए. कम से कम, इन सुविधाओं के साथ काम करना ज़रूरी है:

  • फ़ॉर्मैट: लीनियर पीसीएम, 16-बिट
  • सैंपलिंग रेट: 8000, 11025, 16000, 44100, 48000 हर्ट्ज़
  • चैनल: मोनो
  • ऑडियो के सोर्स: DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED, या VOICE_PERFORMANCE. यह AAudio में मौजूद, इनपुट प्रीसेट के बराबर पर भी लागू होता है. उदाहरण के लिए, AAUDIO_INPUT_PRESET_CAMCORDER.

• इसकी मदद से, रॉ ऑडियो कॉन्टेंट को कैप्चर करने की अनुमति होनी चाहिए. यह कॉन्टेंट इन विशेषताओं वाला होना चाहिए:

  • फ़ॉर्मैट: लीनियर PCM, 16-बिट, और 24-बिट
  • सैंपलिंग रेट: 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 हर्ट्ज़
  • चैनल: डिवाइस पर मौजूद माइक्रोफ़ोन की संख्या के बराबर चैनल

• [C-1-2] अप-सैंपलिंग के बिना, ऊपर दी गई सैंपल दरों पर रिकॉर्ड करना ज़रूरी है.

• [C-1-3] ऊपर दी गई सैंपल रेट, डाउन-सैंपलिंग की मदद से कैप्चर किए जाने पर, इसमें सही ऐंटी-ऐलिऐसिंग फ़िल्टर ज़रूर शामिल होना चाहिए.

• रॉ ऑडियो कॉन्टेंट को AM रेडियो और डीवीडी क्वालिटी में कैप्चर करने की अनुमति होनी चाहिए. इसका मतलब है कि:

  • फ़ॉर्मैट: लीनियर पीसीएम, 16-बिट
  • सैंपलिंग रेट: 22050, 48000 हर्ट्ज़
  • चैनल: स्टीरियो

• [C-1-4] MicrophoneInfo एपीआई का पालन करना ज़रूरी है. साथ ही, डिवाइस पर उपलब्ध माइक्रोफ़ोन की जानकारी सही तरीके से भरनी होगी, ताकि तीसरे पक्ष के ऐप्लिकेशन AudioManager.getMicrophones() एपीआई की मदद से उनका इस्तेमाल कर सकें. यह जानकारी, MediaRecorder.AudioSources DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED या VOICE_PERFORMANCE का इस्तेमाल करके, ऑडियो रिकॉर्ड करने की सुविधा चालू करने के लिए भरी जानी चाहिए.

अगर डिवाइस में AM रेडियो और डीवीडी क्वालिटी में रॉ ऑडियो कॉन्टेंट कैप्चर करने की सुविधा है, तो:

• [C-2-1] 16000:22050 या 44100:48000 से ज़्यादा के आसपेक्ट रेशियो में, अप-सैंपलिंग के बिना रिकॉर्ड करना ज़रूरी है.
• [C-2-2] अप-सैंपलिंग या डाउन-सैंपलिंग के लिए, सही ऐंटी-ऐलिऐसिंग फ़िल्टर शामिल करना ज़रूरी है.

5.4.2. आवाज़ पहचानने की सुविधा के लिए रिकॉर्ड करना

अगर डिवाइस पर android.hardware.microphone लागू किया जाता है, तो:

• [C-1-1] android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION ऑडियो सोर्स को 44100 और 48000 में से किसी एक सैंपलिंग रेट पर कैप्चर करना ज़रूरी है.
• [C-1-2] AudioSource.VOICE_RECOGNITION ऑडियो सोर्स से ऑडियो स्ट्रीम रिकॉर्ड करते समय, शोर कम करने वाली ऑडियो प्रोसेसिंग को डिफ़ॉल्ट रूप से बंद करना ज़रूरी है.

• [C-1-3] AudioSource.VOICE_RECOGNITION ऑडियो सोर्स से ऑडियो स्ट्रीम रिकॉर्ड करते समय, डिफ़ॉल्ट रूप से ऑटोमैटिक गेन कंट्रोल की सुविधा बंद होनी चाहिए.

• यह माइक्रोफ़ोन, मध्य-फ़्रीक्वेंसी रेंज में, ऐम्प्ल्यट्यूड-बनाम-फ़्रीक्वेंसी की सुविधाओं को लगभग फ़्लैट दिखाता है. खास तौर पर, आवाज़ पहचानने वाले ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन के लिए, 100 हर्ट्ज़ से 4,000 हर्ट्ज़ तक ±3dB.

• [C-SR-1] हमारा सुझाव है कि कम फ़्रीक्वेंसी रेंज में, ऐम्प्ल्यट्यूड लेवल दिखाएं: खास तौर पर, वॉइस पहचानने वाले ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन के लिए, मध्य फ़्रीक्वेंसी रेंज की तुलना में 30 हर्ट्ज़ से 100 हर्ट्ज़ तक ±20 डीबी.

• [C-SR-2] हमारा सुझाव है कि आप आवाज़ पहचानने वाले ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए जाने वाले हर माइक्रोफ़ोन के लिए, हाई फ़्रीक्वेंसी रेंज में ऐम्प्ल्यट्यूड लेवल दिखाएं. खास तौर पर, 4,000 हर्ट्ज़ से 22 केएचज़ तक ±30 डीबी की रेंज में.

• ऑडियो इनपुट की संवेदनशीलता को इस तरह से सेट करना चाहिए कि 90 dB साउंड प्रेशर लेवल (एसपीएल) (माइक्रोफ़ोन के बगल में मेज़र किया गया) पर चलाया गया 1000 हर्ट्ज़ का साइनसोइडल टोन सोर्स, 16 बिट-सैंपल के लिए 1770 और 3530 की रेंज में आरएमएस 2500 का आदर्श रिस्पॉन्स दे. इसके अलावा, यह भी ज़रूरी है कि वॉइस रिकॉग्निशन ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन के लिए, यह रेंज पूरी हो. इसके अलावा, फ़्लोटिंग पॉइंट/डबल प्रिसीज़न सैंपल के लिए, यह रेंज -22.35 db ±3dB फ़ुल स्केल होनी चाहिए.

• वॉइस रिकॉग्निशन ऑडियो स्ट्रीम को रिकॉर्ड करना चाहिए, ताकि पीसीएम ऐम्प्लिटीड लेवल, इनपुट एसपीएल में हुए बदलावों को कम से कम 30 डीबी की रेंज में, माइक्रोफ़ोन पर -18 डीबी से +12 डीबी तक के एसपीएल में लीनियर तरीके से ट्रैक कर सकें.

• माइक्रोफ़ोन पर 90 dB SPL इनपुट लेवल पर, 1 kHz के लिए कुल हार्मोनिक डिस्टॉर्शन (THD) 1% से कम होना चाहिए.

अगर डिवाइस में android.hardware.microphone और शोर कम करने की टेक्नोलॉजी का इस्तेमाल किया गया है, तो:

• [C-2-1] इस ऑडियो इफ़ेक्ट को android.media.audiofx.NoiseSuppressor API की मदद से कंट्रोल करने की अनुमति होनी चाहिए.
• [C-2-2] AudioEffect.Descriptor.uuid फ़ील्ड की मदद से, हर ग़ैर-ज़रूरी आवाज़ को कम करने वाली टेक्नोलॉजी के लागू होने की खास तौर पर पहचान की जानी चाहिए.

5.4.3. वीडियो चलाने की जगह बदलने के लिए कैप्चर करना

android.media.MediaRecorder.AudioSource क्लास में REMOTE_SUBMIX ऑडियो सोर्स शामिल होता है.

अगर डिवाइस पर लागू किए गए एपीआई में android.hardware.audio.output और android.hardware.microphone, दोनों का एलान किया गया है, तो:

• [C-1-1] REMOTE_SUBMIX ऑडियो सोर्स को सही तरीके से लागू करना ज़रूरी है, ताकि जब कोई ऐप्लिकेशन इस ऑडियो सोर्स से रिकॉर्ड करने के लिए android.media.AudioRecord एपीआई का इस्तेमाल करे, तो वह इनके अलावा सभी ऑडियो स्ट्रीम को रिकॉर्ड करे:

  • AudioManager.STREAM_RING
  • AudioManager.STREAM_ALARM
  • AudioManager.STREAM_NOTIFICATION

5.4.4. अकूस्टिक इको कैंसलर

अगर डिवाइस पर android.hardware.microphone लागू किया जाता है, तो:

• AudioSource.VOICE_COMMUNICATION का इस्तेमाल करके कैप्चर करते समय, अकूस्टिक इको रद्द करने वाली (एईसी) टेक्नोलॉजी को लागू करना चाहिए. यह टेक्नोलॉजी, वॉइस कम्यूनिकेशन के लिए बनाई गई है और कैप्चर पाथ पर लागू की जाती है.

अगर डिवाइस में इको को खत्म करने की सुविधा है, तो AudioSource.VOICE_COMMUNICATION को चुनने पर, इसे कैप्चर किए गए ऑडियो के पाथ में जोड़ दिया जाता है. ऐसा करने पर:

• [C-SR-1] हमारा सुझाव है कि आप AcousticEchoCanceler एपीआई के AcousticEchoCanceler.isAvailable() तरीके से, इसकी जानकारी दें
• [C-SR-2] हमारा सुझाव है कि इस ऑडियो इफ़ेक्ट को AcousticEchoCanceler एपीआई की मदद से कंट्रोल किया जा सकता है.
• [C-SR-3] हमारा सुझाव है कि AudioEffect.Descriptor.uuid फ़ील्ड का इस्तेमाल करके, एईसी टेक्नोलॉजी के हर लागू होने की खास तौर पर पहचान करें.

5.4.5. एक साथ कई स्क्रीन कैप्चर करना

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

• [C-1-1] ऐक्सेस करने की अनुमति देने वाली किसी सुलभता सेवा को AudioSource.VOICE_RECOGNITION और कम से कम एक ऐप्लिकेशन को एक साथ माइक्रोफ़ोन का ऐक्सेस देना चाहिए.AudioSource
• [C-1-2] डिवाइस में पहले से इंस्टॉल किए गए ऐसे ऐप्लिकेशन को माइक्रोफ़ोन का ऐक्सेस देना ज़रूरी है जो Assistant की भूमिका निभाता हो. साथ ही, कम से कम एक ऐसा ऐप्लिकेशन भी होना चाहिए जो AudioSource.VOICE_COMMUNICATION या AudioSource.CAMCORDER के अलावा किसी भी AudioSource की मदद से ऑडियो रिकॉर्ड करता हो.
• [C-1-3] ऐक्सेसibiliti सेवा को छोड़कर, किसी भी दूसरे ऐप्लिकेशन के लिए ऑडियो कैप्चर को बंद करना ज़रूरी है. ऐसा तब करना होगा, जब कोई ऐप्लिकेशन AudioSource.VOICE_COMMUNICATION या AudioSource.CAMCORDER का इस्तेमाल करके कैप्चर कर रहा हो. हालांकि, जब कोई ऐप्लिकेशन AudioSource.VOICE_COMMUNICATION के ज़रिए कॉल रिकॉर्ड कर रहा हो, तो कोई दूसरा ऐप्लिकेशन भी कॉल रिकॉर्ड कर सकता है. इसके लिए ज़रूरी है कि वह ऐप्लिकेशन, पहले से इंस्टॉल किया गया ऐप्लिकेशन हो और उसके पास CAPTURE_AUDIO_OUTPUT अनुमति हो.
• [C-1-4] अगर एक साथ दो या उससे ज़्यादा ऐप्लिकेशन कैप्चर कर रहे हैं और अगर किसी भी ऐप्लिकेशन के सबसे ऊपर यूज़र इंटरफ़ेस (यूआई) नहीं है, तो सबसे हाल ही में कैप्चर शुरू करने वाले ऐप्लिकेशन को ऑडियो मिलता है.

5.4.6. माइक्रोफ़ोन गेन लेवल [5.4.2 में ले जाया गया]

5.5. ऑडियो प्लेबैक

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

5.5.1. रॉ ऑडियो चलाना

अगर डिवाइस पर android.hardware.audio.output लागू किया जाता है, तो:

• [C-1-1] ऐप्लिकेशन में रॉ ऑडियो कॉन्टेंट को चलाने की अनुमति होनी चाहिए. साथ ही, यह कॉन्टेंट इनके मुताबिक होना चाहिए:

  • सोर्स फ़ॉर्मैट: लीनियर पीसीएम, 16-बिट, 8-बिट, फ़्लोट
  • चैनल: मोनो, स्टीरियो, और ज़्यादा से ज़्यादा आठ चैनलों वाले मान्य मल्टीचैनल कॉन्फ़िगरेशन
  • सैंपलिंग रेट (हर्ट्ज़ में):
    • ऊपर दिए गए चैनल कॉन्फ़िगरेशन में, 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000
    • मोनो और स्टीरियो में 96,000

5.5.2. ऑडियो इफ़ेक्ट

डिवाइस पर लागू करने के लिए, Android ऑडियो इफ़ेक्ट के लिए एपीआई उपलब्ध कराता है.

अगर डिवाइस में android.hardware.audio.output सुविधा का एलान किया गया है, तो:

• [C-1-1] EFFECT_TYPE_EQUALIZER और EFFECT_TYPE_LOUDNESS_ENHANCER को लागू करने की सुविधा होनी चाहिए. इन्हें, AudioEffect के सबक्लास Equalizer और LoudnessEnhancer की मदद से कंट्रोल किया जा सकता है.
• [C-1-2] विज़ुअलाइज़र एपीआई को लागू करने की सुविधा होनी चाहिए. इसे Visualizer क्लास की मदद से कंट्रोल किया जा सकता है.
• [C-1-3] EFFECT_TYPE_DYNAMICS_PROCESSING को लागू करने की सुविधा के साथ काम करना चाहिए, जिसे AudioEffect सबक्लास DynamicsProcessing की मदद से कंट्रोल किया जा सकता है.
• EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB, और EFFECT_TYPE_VIRTUALIZER को लागू करने के लिए, AudioEffect सब-क्लास BassBoost, EnvironmentalReverb, PresetReverb, और Virtualizer के ज़रिए कंट्रोल किया जा सकता है.
• [C-SR-1] हमारा सुझाव है कि फ़्लोटिंग-पॉइंट और कई चैनलों में इफ़ेक्ट का इस्तेमाल किया जाए.

5.5.3. ऑडियो आउटपुट का वॉल्यूम

वाहन से जुड़े डिवाइसों पर लागू करने के लिए:

• हर ऑडियो स्ट्रीम के लिए, ऑडियो वॉल्यूम को अलग से अडजस्ट करने की अनुमति होनी चाहिए. इसके लिए, AudioAttributes में बताए गए कॉन्टेंट टाइप या इस्तेमाल के तरीके और android.car.CarAudioManager में सार्वजनिक तौर पर बताए गए कार के ऑडियो के इस्तेमाल का इस्तेमाल किया जाना चाहिए.

5.5.4. ऑडियो ऑफ़लोड करना

अगर डिवाइस पर ऑडियो ऑफ़लोड करके चलाने की सुविधा काम करती है, तो:

• [C-SR-1] हमारा सुझाव है कि AudioTrack gapless API और MediaPlayer के मीडिया कंटेनर के मुताबिक, एक ही फ़ॉर्मैट वाली दो क्लिप के बीच में, बिना किसी गैप के चलने वाले ऑडियो कॉन्टेंट को ट्रिम करें.

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

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

इस सेक्शन के लिए, इन परिभाषाओं का इस्तेमाल करें:

• आउटपुट में लगने वाला समय. जब कोई ऐप्लिकेशन, पीसीएम कोड वाले डेटा का फ़्रेम लिखता है और जब उससे जुड़ी आवाज़, डिवाइस पर मौजूद ट्रांसड्यूसर की मदद से, आस-पास के माहौल में सुनाई देती है या सिग्नल किसी पोर्ट से डिवाइस से बाहर निकलता है और उसे बाहर से देखा जा सकता है, तो उस बीच का समय.
• कोल्ड आउटपुट में लगने वाला समय. टाइमस्टैंप के आधार पर, आउटपुट स्ट्रीम शुरू होने और पहले फ़्रेम के प्रज़ेंटेशन के समय के बीच का समय. ऐसा तब होता है, जब अनुरोध से पहले ऑडियो आउटपुट सिस्टम बंद हो और काम न कर रहा हो.
• आउटपुट में लगने वाला लगातार समय. डिवाइस पर ऑडियो चलने के बाद, अगले फ़्रेम के लिए आउटपुट में लगने वाला समय.
• इनपुट में लगने वाला समय. यह समय अंतराल होता है, जब किसी ऑब्जेक्ट से आने वाली आवाज़, डिवाइस पर मौजूद ट्रांसड्यूसर पर पहुंचती है या सिग्नल किसी पोर्ट से डिवाइस में आता है और जब कोई ऐप्लिकेशन, PCM कोड वाले डेटा के उस फ़्रेम को पढ़ता है.
• इनपुट नहीं मिला. इनपुट सिग्नल का वह शुरुआती हिस्सा जो इस्तेमाल नहीं किया जा सकता या उपलब्ध नहीं है.
• कोल्ड इनपुट लैटेंसी. स्ट्रीम शुरू करने से लेकर, पहला मान्य फ़्रेम मिलने तक का समय. ऐसा तब होता है, जब अनुरोध करने से पहले ऑडियो इनपुट सिस्टम बंद हो और काम न कर रहा हो.
• इनपुट में लगातार होने वाली देरी. डिवाइस के ऑडियो कैप्चर करने के दौरान, अगले फ़्रेम के लिए इनपुट में लगने वाला समय.
• कंटेंट के लोड होने में लगने वाला कुल समय. लगातार इनपुट में लगने वाले समय, लगातार आउटपुट में लगने वाले समय, और बफ़र पीरियड को जोड़ने पर मिलने वाला समय. बफ़र पीरियड की मदद से, ऐप्लिकेशन को सिग्नल को प्रोसेस करने और इनपुट और आउटपुट स्ट्रीम के बीच फ़ेज़ के अंतर को कम करने का समय मिलता है.
• OpenSL ES PCM बफ़र क्यू एपीआई. Android NDK में, PCM से जुड़े OpenSL ES एपीआई का सेट.
• AAudio नेटिव ऑडियो एपीआई. Android एनडीके में, AAudio एपीआई का सेट.
• टाइमस्टैंप. यह एक पेयर होता है, जिसमें स्ट्रीम में फ़्रेम की रिलेटिव पोज़िशन और उस फ़्रेम के एंडपॉइंट पर ऑडियो प्रोसेसिंग पाइपलाइन में शामिल होने या उससे बाहर निकलने का अनुमानित समय शामिल होता है. AudioTimestamp देखें.
• glitch. ऑडियो सिग्नल में कुछ समय के लिए रुकावट आना या सैंपल की गलत वैल्यू दिखना. आम तौर पर, ऐसा आउटपुट के लिए बफ़र में डेटा कम होना, इनपुट के लिए बफ़र में डेटा ज़्यादा होना या डिजिटल या एनालॉग नॉइज़ के किसी अन्य सोर्स की वजह से होता है.
• कुल डेविएशन का माध्य. वैल्यू के किसी सेट के लिए, औसत से होने वाले बदलावों की कुल वैल्यू का औसत.
• टैप-टू-टोन के इंतज़ार का समय. स्क्रीन पर टैप करने और उस टैप की वजह से जनरेट हुई टोन के स्पीकर पर सुनाई देने के बीच का समय.

अगर डिवाइस में android.hardware.audio.output का एलान किया जाता है, तो उसे इन ज़रूरी शर्तों को पूरा करना होगा या उनसे बेहतर होना चाहिए:

• [C-1-1] AudioTrack.getTimestamp और AAudioStream_getTimestamp से मिला आउटपुट टाइमस्टैंप, +/- 2 मिलीसेकंड तक सटीक होता है.

• [C-1-2] कोल्ड आउटपुट में लगने वाला समय 500 मिलीसेकंड या उससे कम होना चाहिए.

• [C-1-3] AAudioStreamBuilder_openStream() का इस्तेमाल करके आउटपुट स्ट्रीम खोलने में 1,000 मिलीसेकंड से कम समय लगना चाहिए.

अगर डिवाइस पर android.hardware.audio.output का एलान किया जाता है, तो हमारा सुझाव है कि वे इन ज़रूरी शर्तों को पूरा करें या उनसे बेहतर बनाएं:

• [C-SR-1] स्पीकर के डेटा पाथ पर, 100 मिलीसेकंड या उससे कम का आउटपुट इंतज़ार का समय.

• [C-SR-2] टैप-टू-टोन में लगने वाला समय 80 मिलीसेकंड या उससे कम होना चाहिए.

• [C-SR-4] AudioTrack.getTimestamp और AAudioStream_getTimestamp से मिला आउटपुट टाइमस्टैंप, +/- 1 मिलीसेकंड तक सटीक होता है.

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

• [C-SR-5] हमारा सुझाव है कि आप android.hardware.audio.low_latency सुविधा फ़्लैग का एलान करके, कम इंतज़ार वाले ऑडियो की शिकायत करें.
• [C-SR-6] हमारा सुझाव है कि आप AAudio API की मदद से, कम इंतज़ार वाले ऑडियो की ज़रूरी शर्तें पूरी करें.
• [C-SR-7] हमारा सुझाव है कि AAudioStream_getPerformanceMode() से AAUDIO_PERFORMANCE_MODE_LOW_LATENCY दिखाने वाली स्ट्रीम के लिए, AAudioStream_getFramesPerBurst() से मिली वैल्यू, प्रॉपर्टी कुंजी AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER के लिए android.media.AudioManager.getProperty(String) से मिली वैल्यू से कम या उसके बराबर हो.

अगर डिवाइस पर लागू किए गए तरीके, AAudio नेटिव ऑडियो एपीआई की मदद से कम इंतज़ार वाले ऑडियो की ज़रूरी शर्तों को पूरा नहीं करते, तो:

• [C-2-1] कम इंतज़ार वाले ऑडियो की सुविधा के काम करने की जानकारी नहीं दी जानी चाहिए.

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

• [C-3-1] AudioRecord.getTimestamp या AAudioStream_getTimestamp से मिले इनपुट टाइमस्टैंप में, +/- 2 मिलीसेकंड तक की गड़बड़ी की सीमा तय करें. यहां "गड़बड़ी" का मतलब सही वैल्यू से अलग होने से है.

• [C-3-2] कोल्ड इनपुट में लगने वाला समय 500 मिलीसेकंड या उससे कम होना चाहिए.

• [C-3-3] AAudioStreamBuilder_openStream() का इस्तेमाल करके इनपुट स्ट्रीम खोलने में 1,000 मिलीसेकंड से कम समय लगना चाहिए.

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

• [C-SR-8] माइक्रोफ़ोन के डेटा पाथ पर, इनपुट के शुरू होने में 100 मिलीसेकंड या उससे कम समय लगना चाहिए.

• [C-SR-11] AudioRecord.getTimestamp या AAudioStream_getTimestamp से मिले इनपुट टाइमस्टैंप में, गड़बड़ी की सीमा को +/- 1 मिलीसेकंड तक सीमित करें.

अगर डिवाइस पर android.hardware.audio.output और android.hardware.microphone का एलान किया जाता है, तो:

• [C-SR-12] हमारा सुझाव है कि पांच मेज़रमेंट में, लगातार राउंड-ट्रिप के लिए औसत इंतज़ार का समय 50 मिलीसेकंड या उससे कम हो. साथ ही, कम से कम एक काम करने वाले पाथ पर, औसत एब्सोल्यूट डेविएशन 10 मिलीसेकंड से कम हो.

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

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

हर उस कोडेक और कंटेनर फ़ॉर्मैट के लिए जिसे डिवाइस पर लागू करने की ज़रूरत है, डिवाइस पर लागू करने के लिए:

• [C-1-1] यह ज़रूरी है कि एचटीटीपी और एचटीटीपीएस पर, उस कोडेक या कंटेनर का इस्तेमाल किया जा सके.

• [C-1-2] एचटीटीपी लाइव स्ट्रीमिंग ड्राफ़्ट प्रोटोकॉल, वर्शन 7 के साथ, मीडिया सेगमेंट फ़ॉर्मैट की टेबल में दिखाए गए मीडिया सेगमेंट फ़ॉर्मैट के साथ काम करना चाहिए.

• [C-1-3] यह ज़रूरी है कि यह उसी RTSP पेलोड फ़ॉर्मैट के साथ काम करे जो नीचे दी गई टेबल में दिखाए गए हैं. अपवादों के बारे में जानने के लिए, कृपया सेक्शन 5.1 में टेबल के फ़ुटनोट देखें.

मीडिया सेगमेंट के फ़ॉर्मैट

सेगमेंट फ़ॉर्मैट	रेफ़रंस	ज़रूरी कोडेक के साथ काम करना
MPEG-2 ट्रांसपोर्ट स्ट्रीम	ISO 13818	वीडियो कोडेक: H264 AVC MPEG-4 SP MPEG-2 H264 AVC, MPEG2-4 SP, और MPEG-2 के बारे में जानकारी के लिए, सेक्शन 5.1.8 देखें. ऑडियो कोडेक: AAC AAC और इसके वैरिएंट के बारे में जानकारी के लिए, सेक्शन 5.1.3 देखें.
ADTS फ़्रेमिंग और ID3 टैग के साथ AAC	ISO 13818-7	AAC और इसके वैरिएंट के बारे में जानकारी के लिए, सेक्शन 5.1.1 देखें
WebVTT	WebVTT

आरटीएसपी (आरटीपी, एसडीपी)

प्रोफ़ाइल का नाम	रेफ़रंस	ज़रूरी कोडेक के साथ काम करना
H264 AVC	RFC 6184	H264 AVC के बारे में जानकारी के लिए, सेक्शन 5.1.8 देखें
MP4A-LATM	RFC 6416	AAC और इसके वैरिएंट के बारे में जानकारी के लिए, सेक्शन 5.1.3 देखें
H263-1998	RFC 3551 RFC 4629 RFC 2190	H263 के बारे में जानकारी के लिए, सेक्शन 5.1.8 देखें
H263-2000	RFC 4629	H263 के बारे में जानकारी के लिए, सेक्शन 5.1.8 देखें
एएमआर	RFC 4867	AMR-NB के बारे में जानकारी के लिए, सेक्शन 5.1.3 देखें
AMR-WB	RFC 4867	AMR-WB के बारे में जानकारी के लिए, सेक्शन 5.1.3 देखें
MP4V-ES	RFC 6416	MPEG-4 SP के बारे में जानकारी के लिए, सेक्शन 5.1.8 देखें
mpeg4-generic	RFC 3640	AAC और इसके वैरिएंट के बारे में जानकारी के लिए, सेक्शन 5.1.3 देखें
MP2T	RFC 2250	ज़्यादा जानकारी के लिए, एचटीटीपी लाइव स्ट्रीमिंग के नीचे एमपीईजी-2 ट्रांसपोर्ट स्ट्रीम देखें

5.8. Secure Media

अगर डिवाइस पर सुरक्षित वीडियो आउटपुट की सुविधा काम करती है और डिवाइस पर सुरक्षित प्लैटफ़ॉर्म का इस्तेमाल किया जा सकता है, तो:

• [C-1-1] Display.FLAG_SECURE के लिए सहायता उपलब्ध कराने का एलान करना ज़रूरी है.

अगर डिवाइस में Display.FLAG_SECURE और वाई-फ़ाई डिसप्ले प्रोटोकॉल के साथ काम करने की सुविधा है, तो:

• [C-2-1] Miracast जैसे वायरलेस प्रोटोकॉल से कनेक्ट किए गए डिसप्ले के लिए, लिंक को एन्क्रिप्ट करने के लिए, एचडीसीपी 2.x या उसके बाद के वर्शन जैसे किसी मज़बूत तरीके का इस्तेमाल करना ज़रूरी है.

अगर डिवाइस में Display.FLAG_SECURE की सुविधा काम करती है और तार से कनेक्ट किए गए बाहरी डिसप्ले की सुविधा काम करती है, तो:

• [C-3-1] उपयोगकर्ता के ऐक्सेस वाले वायर्ड पोर्ट से कनेक्ट किए गए सभी बाहरी डिसप्ले के लिए, HDCP 1.2 या इसके बाद के वर्शन का इस्तेमाल करना ज़रूरी है.

5.9. म्यूज़िकल इंस्ट्रुमेंट डिजिटल इंटरफ़ेस (एमआईडीआई)

अगर डिवाइस पर लागू की गई सुविधाओं की जानकारी देने वाली रिपोर्ट में, android.content.pm.PackageManager क्लास के ज़रिए android.software.midi सुविधा के काम करने की जानकारी दी गई है, तो:

• [C-1-1] एमआईडीआई की सुविधा वाले सभी हार्डवेयर ट्रांसपोर्ट के लिए, एमआईडीआई की सुविधा काम करनी चाहिए. इसके लिए, वे सामान्य गैर-एमआईडीआई कनेक्टिविटी उपलब्ध कराते हैं. ये ट्रांसपोर्ट ये हैं:

  • यूएसबी होस्ट मोड, सेक्शन 7.7
  • ब्लूटूथ LE पर MIDI, मुख्य भूमिका में काम कर रहा है, सेक्शन 7.4.3

• [C-1-2] ऐप्लिकेशन के बीच एमआईडीआई सॉफ़्टवेयर ट्रांसपोर्ट (वर्चुअल एमआईडीआई डिवाइस) के साथ काम करना चाहिए

• [C-1-3] इसमें libamidi.so (नेटिव MIDI सपोर्ट) शामिल होना चाहिए

• यूएसबी की मदद से कनेक्ट किए गए सहायक डिवाइस मोड में, एमआईडीआई की सुविधा काम करनी चाहिए, सेक्शन 7.7

5.10. प्रोफ़ेशनल ऑडियो

अगर डिवाइस में android.content.pm.PackageManager क्लास की मदद से, android.hardware.audio.pro सुविधा के काम करने की जानकारी दी गई है, तो:

• [C-1-1] android.hardware.audio.low_latency सुविधा के लिए सहायता की जानकारी देना ज़रूरी है.
• [C-1-2] ऑडियो के लिए, 5.6 ऑडियो के लिए इंतज़ार का समय सेक्शन में बताए गए, कम से कम एक काम करने वाले पाथ पर, ऑडियो के लिए लगातार राउंड-ट्रिप इंतज़ार का समय 25 मिलीसेकंड या उससे कम होना चाहिए.
• [C-1-3] इसमें यूएसबी होस्ट मोड और यूएसबी डिवाइस मोड के साथ काम करने वाला यूएसबी पोर्ट होना चाहिए.
• [C-1-4] android.software.midi सुविधा के लिए सहायता की जानकारी देना ज़रूरी है.
• [C-1-5] AAudio नेटिव ऑडियो एपीआई और AAUDIO_PERFORMANCE_MODE_LOW_LATENCY का इस्तेमाल करके, इंतज़ार के समय और यूएसबी ऑडियो की ज़रूरी शर्तों को पूरा करना ज़रूरी है.
• [C-1-6] कोल्ड आउटपुट में लगने वाला समय 200 मिलीसेकंड या उससे कम होना चाहिए.
• [C-1-7] कोल्ड इनपुट में लगने वाला समय 200 मिलीसेकंड या उससे कम होना चाहिए.
• [C-1-8] टैप-टू-टोन के औसत इंतज़ार का समय 80 मिलीसेकंड या उससे कम होना चाहिए. यह समय, स्पीकर से माइक्रोफ़ोन के डेटा पाथ के कम से कम पांच मेज़रमेंट पर आधारित होना चाहिए.
• [C-SR-1] हमारा सुझाव है कि आप 5.6 ऑडियो लैटेंसी सेक्शन में बताए गए लैटेंसी को पूरा करें. यह लैटेंसी, स्पीकर से माइक्रोफ़ोन तक के पाथ में 20 मिलीसेकंड या इससे कम होनी चाहिए. साथ ही, पांच मेज़रमेंट में, औसत एब्सोल्यूट डिविएशन पांच मिलीसेकंड से कम होना चाहिए.
• [C-SR-2] हमारा सुझाव है कि आप एमएमएपी पाथ पर AAudio नेटिव ऑडियो एपीआई का इस्तेमाल करके, ऑडियो के लगातार राउंड-ट्रिप के इंतज़ार का समय, कोल्ड इनपुट के इंतज़ार का समय, और कोल्ड आउटपुट के इंतज़ार का समय कम करने के लिए, Pro Audio की ज़रूरी शर्तें पूरी करें. साथ ही, यूएसबी ऑडियो की ज़रूरी शर्तें भी पूरी करें.

• [C-SR-3] हमारा सुझाव है कि ऑडियो चालू होने और सीपीयू लोड में बदलाव होने के दौरान, सीपीयू की परफ़ॉर्मेंस को एक जैसा बनाए रखें. इसकी जांच, Android ऐप्लिकेशन SynthMark का इस्तेमाल करके की जानी चाहिए. SynthMark, सिस्टम की परफ़ॉर्मेंस का आकलन करने के लिए, सिम्युलेट किए गए ऑडियो फ़्रेमवर्क पर चलने वाले सॉफ़्टवेयर सिंथेसाइज़र का इस्तेमाल करता है. मानदंडों के बारे में जानने के लिए, SynthMark दस्तावेज़ देखें. SynthMark ऐप्लिकेशन को “ऑटोमेटेड टेस्ट” विकल्प का इस्तेमाल करके चलाया जाना चाहिए. इससे आपको ये नतीजे मिलेंगे:

  • voicemark.90 >= 32 voices
  • latencymark.fixed.little <= 15 msec
  • latencymark.dynamic.little <= 50 msec

• ऑडियो क्लॉक की गड़बड़ी और स्टैंडर्ड टाइम के मुकाबले ड्रिफ़्ट को कम करना चाहिए.

• जब दोनों चालू हों, तो सीपीयू CLOCK_MONOTONIC के मुकाबले ऑडियो क्लॉक ड्रिफ़्ट को कम करना चाहिए.

• डिवाइस पर मौजूद ट्रांसड्यूसर की मदद से, ऑडियो के इंतज़ार का समय कम होना चाहिए.

• यूएसबी डिजिटल ऑडियो पर ऑडियो के इंतज़ार का समय कम होना चाहिए.

• सभी पाथ पर ऑडियो के इंतज़ार का समय मेज़र करना चाहिए.

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

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

• अलग-अलग चैनलों के बीच इंतज़ार का समय एक जैसा होना चाहिए.

• सभी ट्रांसपोर्ट पर एमआईडीआई के इंतज़ार का औसत समय कम होना चाहिए.

• सभी ट्रांसपोर्ट पर लोड (जटर) के दौरान, एमआईडीआई के इंतज़ार का समय कम से कम होना चाहिए.

• सभी ट्रांसपोर्ट के लिए, सटीक एमआईडीआई टाइमस्टैंप देने चाहिए.

• डिवाइस पर मौजूद ट्रांसड्यूसर पर ऑडियो सिग्नल के शोर को कम करना चाहिए. इसमें कोल्ड स्टार्ट के तुरंत बाद का समय भी शामिल है.

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

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

• इससे, एंड-पॉइंट के इनपुट और आउटपुट साइड के लिए, एचएएल ऑडियो बफ़रिंग के बीच फ़ेज़ के अंतर को कम किया जा सकता है.

• टच में लगने वाले समय को कम करना चाहिए.

• लोड (जटर) के दौरान, टच रिस्पॉन्स में लगने वाले समय में होने वाले बदलाव को कम करना चाहिए.

अगर डिवाइस में ऊपर दी गई सभी ज़रूरी शर्तें पूरी की जाती हैं, तो:

• [C-SR-4] हमारा सुझाव है कि android.content.pm.PackageManager क्लास की मदद से, android.hardware.audio.pro सुविधा के लिए सहायता पाने का अनुरोध करें.

अगर डिवाइस में चार कंडक्टर वाला 3.5 मि॰मी॰ ऑडियो जैक शामिल है, तो:

• [C-2-1] 5.6 ऑडियो लैटेंसी सेक्शन में बताए गए तरीके के हिसाब से, ऑडियो जैक पाथ पर ऑडियो लूपबैक डोंगल का इस्तेमाल करके, लगातार पांच बार मापी गई ऑडियो लैटेंसी का औसत 20 मिलीसेकंड या उससे कम होना चाहिए. साथ ही, मापी गई ऑडियो लैटेंसी में औसत अंतर 5 मिलीसेकंड से कम होना चाहिए.
• [C-SR-5] हमारा सुझाव है कि आप वायर वाले ऑडियो हेडसेट के लिए स्पेसिफ़िकेशन (v1.1) के मोबाइल डिवाइस (जैक) के स्पेसिफ़िकेशन सेक्शन का पालन करें.

अगर डिवाइस में चार कंडक्टर वाला 3.5 मि॰मी॰ ऑडियो जैक नहीं है और यूएसबी होस्ट मोड के साथ काम करने वाले यूएसबी पोर्ट शामिल हैं, तो:

• [C-3-1] यूएसबी ऑडियो क्लास को लागू करना ज़रूरी है.
• [C-3-2] यूएसबी ऑडियो क्लास का इस्तेमाल करने वाले यूएसबी होस्ट मोड पोर्ट पर, लगातार पांच बार मापने पर, ऑडियो के लिए राउंड-ट्रिप लेटेंसी का औसत 25 मिलीसेकंड या उससे कम होना चाहिए. साथ ही, औसत का एब्सोल्यूट डिविएशन पांच मिलीसेकंड से कम होना चाहिए. (इसे यूएसबी-3.5 मि॰मी॰ अडैप्टर और ऑडियो लूपबैक डोंगल का इस्तेमाल करके मेज़र किया जा सकता है. इसके अलावा, इनपुट को आउटपुट से जोड़ने वाली पैच केबल के साथ यूएसबी ऑडियो इंटरफ़ेस का इस्तेमाल करके भी मेज़र किया जा सकता है).
• [C-SR-6] हमारा सुझाव है कि इनका इस्तेमाल, USB ऑडियो डिवाइसों के साथ किया जाए. इन डिवाइसों में, हर डायरेक्शन में ज़्यादा से ज़्यादा आठ चैनल, 96 किलोहर्ट्ज़ सैंपल रेट, और 24-बिट या 32-बिट डेप्थ के साथ एक साथ I/O की सुविधा होनी चाहिए.
• [C-SR-7] हमारा सुझाव है कि आप एमएमएपी पाथ पर AAudio के नेटिव ऑडियो एपीआई का इस्तेमाल करके, ज़रूरी शर्तों के इस ग्रुप को पूरा करें.

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

• कम से कम एक कॉन्फ़िगरेशन में, 20-बिट या 24-बिट डेप्थ और 192 केएचज़ पर, स्टीरियो और आठ चैनलों में आउटपुट की सुविधा होनी चाहिए. साथ ही, बिट-डेप्थ में कोई कमी या फिर रीसैंपलिंग नहीं होनी चाहिए.

5.11. प्रोसेस नहीं हुए डेटा के लिए कैप्चर

Android में, android.media.MediaRecorder.AudioSource.UNPROCESSED ऑडियो सोर्स की मदद से, बिना प्रोसेस किए गए ऑडियो को रिकॉर्ड करने की सुविधा शामिल है. OpenSL ES में, इसे रिकॉर्ड करने के लिए पहले से सेट किए गए पैरामीटर SL_ANDROID_RECORDING_PRESET_UNPROCESSED का इस्तेमाल करके ऐक्सेस किया जा सकता है.

अगर डिवाइस में बिना प्रोसेस किए गए ऑडियो सोर्स का इस्तेमाल करने और उसे तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराने का मकसद है, तो:

• [C-1-1] android.media.AudioManager प्रॉपर्टी PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED के ज़रिए, सहायता की जानकारी देना ज़रूरी है.

• [C-1-2] माइक्रोफ़ोन की परफ़ॉर्मेंस, मध्य फ़्रीक्वेंसी रेंज में, ऐम्प्ल्यट्यूड-बनाम-फ़्रीक्वेंसी के हिसाब से, ज़्यादा-से-ज़्यादा 10 dB तक होनी चाहिए. खास तौर पर, बिना प्रोसेस किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन के लिए, 100 Hz से 7,000 Hz तक की फ़्रीक्वेंसी रेंज में यह 10 dB तक होनी चाहिए.

• [C-1-3] कम फ़्रीक्वेंसी वाली रेंज में, ऐम्प्ल्यट्यूड लेवल दिखाना ज़रूरी है: खास तौर पर, बिना प्रोसेस किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन के लिए, मध्य फ़्रीक्वेंसी रेंज की तुलना में 5 z से 100 Hz तक ±20 dB.

• [C-1-4] यह ज़रूरी है कि अम्प्ल्यट्यूड लेवल, हाई फ़्रीक्वेंसी रेंज में हो: खास तौर पर, बिना प्रोसेस किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन के लिए, मीडियम फ़्रीक्वेंसी रेंज की तुलना में, 7,000 हर्ट्ज़ से 22 केएचज़ तक ±30 डीबी.

• [C-1-5] ऑडियो इनपुट की संवेदनशीलता को इस तरह से सेट करना ज़रूरी है कि 94 dB साउंड प्रेशर लेवल (एसपीएल) पर चलाया गया 1000 Hz साइनसोइडल टोन सोर्स, 16 बिट-सैंपल के लिए 520 आरएमएस (या फ़्लोटिंग पॉइंट/डबल सटीक सैंपल के लिए -36 dB फ़ुल स्केल) का रिस्पॉन्स दे. ऐसा हर उस माइक्रोफ़ोन के लिए करना ज़रूरी है जिसका इस्तेमाल, बिना प्रोसेस किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए किया जाता है.

• [C-1-6] बिना प्रोसेस किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन का सिग्नल-टू-नॉइज़ रेशियो (एसएनआर) 60 dB या उससे ज़्यादा होना चाहिए. (जबकि एसएनआर को 94 dB SPL और सेल्फ़ नॉइज़ के बराबर एसपीएल, A-वज़्ड के बीच के अंतर के तौर पर मेज़र किया जाता है).

• [C-1-7] प्रोसेस न किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन में, 90 dB SPL इनपुट लेवल पर 1 kHz के लिए, कुल हार्मोनिक डिस्टॉर्शन (THD) 1% से कम होना चाहिए.

• [C-1-8] लेवल को सही रेंज में लाने के लिए, पाथ में लेवल मल्टीप्लायर के अलावा कोई अन्य सिग्नल प्रोसेसिंग (जैसे, ऑटोमैटिक गेन कंट्रोल, हाई पास फ़िल्टर या गूंज खत्म करने की सुविधा) नहीं होनी चाहिए. दूसरे शब्दों में:

  • [C-1-9] अगर किसी वजह से आर्किटेक्चर में कोई सिग्नल प्रोसेसिंग मौजूद है, तो उसे बंद करना ज़रूरी है. साथ ही, सिग्नल पाथ में शून्य देरी या अतिरिक्त इंतज़ार का समय शामिल करना चाहिए.
  • [C-1-10] लेवल मल्टीप्लायर को पाथ में शामिल करने की अनुमति है. हालांकि, यह सिग्नल पाथ में देरी या लैटेंसी नहीं ला सकता.

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

अगर डिवाइस पर android.hardware.microphone का एलान किया गया है, लेकिन बिना प्रोसेस किए गए ऑडियो सोर्स के साथ काम नहीं करता है, तो:

• [C-2-1] AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) एपीआई तरीके के लिए, null दिखाना ज़रूरी है, ताकि यह साफ़ तौर पर पता चल सके कि यह तरीका काम नहीं करता.
• [C-SR-1] हमारा सुझाव है कि प्रोसेस नहीं किए गए रिकॉर्डिंग सोर्स के सिग्नल पाथ के लिए, ज़्यादा से ज़्यादा ज़रूरी शर्तें पूरी करें.

5.12. एचडीआर वीडियो

Android 13 में एचडीआर टेक्नोलॉजी काम करती हैं. इनके बारे में आने वाले समय में एक दस्तावेज़ में बताया जाएगा.

पिक्सल फ़ॉर्मैट

अगर कोई वीडियो डिकोडर, COLOR_FormatYUVP010 के साथ काम करने का दावा करता है, तो:

• [C-1-1] सीपीयू से पढ़ने के लिए, P010 फ़ॉर्मैट के साथ काम करना चाहिए (ImageReader, MediaImage, ByteBuffer). Android 13 में, Y और UV प्लैन के लिए मनमुताबिक स्ट्राइड की अनुमति देने के लिए, P010 को आसान बनाया गया है.

• [C-1-2] GPU_SAMPLING के इस्तेमाल के साथ असाइन किए जाने पर, P010 आउटपुट बफ़र का सैंपलिंग होना ज़रूरी है. इससे ऐप्लिकेशन, जीपीयू कंपज़िशन और कस्टम टोन मैपिंग का इस्तेमाल कर सकते हैं.

अगर कोई वीडियो डिकोडर, COLOR_Format32bitABGR2101010 के साथ काम करने का दावा करता है, तो इसका मतलब है कि:

• [C-2-1] आउटपुट प्लैटफ़ॉर्म के लिए RGBA_1010102 फ़ॉर्मैट और सीपीयू के लिए पढ़ने लायक (ByteBuffer आउटपुट) फ़ॉर्मैट का इस्तेमाल करना ज़रूरी है.

अगर कोई वीडियो एन्कोडर, COLOR_FormatYUVP010 के साथ काम करने का दावा करता है, तो इसका मतलब है कि:

• [C-3-1] इनपुट प्लैटफ़ॉर्म और सीपीयू में लिखे जा सकने वाले (ImageWriter, MediaImage, ByteBuffer) इनपुट के लिए, P010 फ़ॉर्मैट का इस्तेमाल किया जाना चाहिए.

अगर कोई वीडियो एन्कोडर, COLOR_Format32bitABGR2101010 के साथ काम करने का दावा करता है, तो इसका मतलब है कि:

• [C-4-1] इनपुट प्लैटफ़ॉर्म और सीपीयू में लिखे जा सकने वाले (ImageWriter, ByteBuffer) इनपुट के लिए, RGBA_1010102 फ़ॉर्मैट का इस्तेमाल करना ज़रूरी है. ध्यान दें: एन्कोडर के लिए, अलग-अलग ट्रांसफ़र कर्व के बीच बदलाव करना ज़रूरी नहीं है.

एचडीआर कैप्चर करने से जुड़ी ज़रूरी शर्तें

एचडीआर प्रोफ़ाइल और डिवाइस पर लागू होने वाली सुविधाओं के साथ काम करने वाले सभी वीडियो एन्कोडर के लिए:

• [C-5-1] यह नहीं मानना चाहिए कि HDR मेटाडेटा सटीक है. उदाहरण के लिए, एन्कोड किए गए फ़्रेम में, चमक के पीक लेवल से ज़्यादा पिक्सल हो सकते हैं या हो सकता है कि हिस्टोग्राम, फ़्रेम को सही तरीके से न दिखा रहा हो.

• एन्कोड की गई स्ट्रीम के लिए सही एचडीआर स्टैटिक मेटाडेटा जनरेट करने के लिए, एचडीआर डाइनैमिक मेटाडेटा को इकट्ठा करना चाहिए. साथ ही, उन्हें हर एन्कोडिंग सेशन के आखिर में इसे आउटपुट करना चाहिए.

अगर डिवाइस पर CamcorderProfile API का इस्तेमाल करके एचडीआर कैप्चर की सुविधा काम करती है, तो:

• [C-6-1] यह ज़रूरी है कि Camera2 API की मदद से भी एचडीआर कैप्चर की सुविधा काम करे.

• [C-6-2] यह ज़रूरी है कि एचडीआर क्वालिटी के साथ काम करने वाली हर टेक्नोलॉजी के लिए, कम से कम एक हार्डवेयर-ऐक्सेलेरेटेड वीडियो एन्कोडर काम करता हो.

• [C-6-3] यह कम से कम एचएलजी कैप्चर को सपोर्ट करना चाहिए.

• [C-6-4] कैप्चर की गई वीडियो फ़ाइल में एचडीआर मेटाडेटा (अगर एचडीआर टेक्नोलॉजी पर लागू हो) को लिखने की सुविधा होनी चाहिए. AV1, HEVC, और DolbyVision के लिए, इसका मतलब है कि एन्कोड किए गए बिटस्ट्रीम में मेटाडेटा शामिल करना.

• [C-6-5] P010 और COLOR_FormatYUVP010 के साथ काम करना चाहिए.

• [C-6-6] कैप्चर की गई प्रोफ़ाइल के लिए, डिफ़ॉल्ट रूप से हार्डवेयर से तेज़ किए गए डिकोडर में, एचडीआर से एसडीआर टोन मैपिंग की सुविधा होनी चाहिए. दूसरे शब्दों में, अगर कोई डिवाइस HDR10+ HEVC कैप्चर कर सकता है, तो डिफ़ॉल्ट HEVC डिकोडर को कैप्चर की गई स्ट्रीम को एसडीआर में डिकोड करना चाहिए.

एचडीआर वीडियो में बदलाव करने से जुड़ी ज़रूरी शर्तें

अगर डिवाइस में एचडीआर एडिटिंग की सुविधा वाले वीडियो एन्कोडर शामिल हैं, तो:

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

अगर डिवाइस में ऐसे कोडेक शामिल हैं जो FEATURE_HdrEditing के साथ काम करते हैं, तो वे कोडेक:

• [C-7-1] कम से कम एक एचडीआर प्रोफ़ाइल के साथ काम करना चाहिए.

• [C-7-2] कोडेक के विज्ञापन में बताई गई सभी एचडीआर प्रोफ़ाइलों के लिए, FEATURE_HdrEditing की सुविधा काम करनी चाहिए. दूसरे शब्दों में, अगर एचडीआर मेटाडेटा का इस्तेमाल करने वाली सभी एचडीआर प्रोफ़ाइलों के लिए यह सुविधा मौजूद नहीं है, तो एचडीआर मेटाडेटा जनरेट करने की सुविधा काम करनी चाहिए.

• [C-7-3] वीडियो एन्कोडर के इन इनपुट फ़ॉर्मैट के साथ काम करना चाहिए, ताकि एचडीआर वीडियो को डिकोड करने के बाद, उसके सिग्नल को पूरी तरह से सुरक्षित रखा जा सके:

  • इनपुट स्क्रीन और ByteBuffer, दोनों के लिए RGBA_1010102 (पहले से ही टारगेट ट्रांसफ़र कर्व में है). साथ ही, COLOR_Format32bitABGR2101010 के साथ काम करने की जानकारी देना ज़रूरी है.

अगर डिवाइस में ऐसे कोडेक शामिल हैं जो FEATURE_HdrEditing के साथ काम करते हैं, तो डिवाइस:

• [C-7-4] EXT_YUV_target OpenGL एक्सटेंशन के साथ काम करने की जानकारी देना ज़रूरी है.

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

6.1. डेवलपर टूल

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

• [C-0-1] यह ज़रूरी है कि यह Android SDK में दिए गए Android डेवलपर टूल के साथ काम करे.

• Android डीबग ब्रिज (adb)

  • [C-0-2] यह ज़रूरी है कि यह Android SDK टूल और AOSP में दिए गए शेल कमांड के साथ काम करे. इनका इस्तेमाल ऐप्लिकेशन डेवलपर कर सकते हैं. इनमें dumpsys cmd stats भी शामिल है
  • [C-0-11] यह ज़रूरी है कि शेल कमांड cmd testharness काम करे. डिवाइस पर पहले से मौजूद Android वर्शन को, बिना किसी डेटा ब्लॉक के नए वर्शन पर अपग्रेड करने पर, C-0-11 से छूट मिल सकती है.
  • [C-0-3] डिवाइस के सिस्टम इवेंट (batterystats , diskstats, fingerprint, graphicsstats, netstats, notification, procstats) के फ़ॉर्मैट या कॉन्टेंट में बदलाव नहीं किया जाना चाहिए. ये इवेंट, dumpsys कमांड की मदद से लॉग किए जाते हैं.
  • [C-0-10] इन इवेंट को रिकॉर्ड करना ज़रूरी है. साथ ही, इन्हें cmd stats शेल कमांड और StatsManager सिस्टम एपीआई क्लास के लिए ऐक्सेस और उपलब्ध कराना ज़रूरी है.
    • ActivityForegroundStateChanged
    • AnomalyDetected
    • AppBreadcrumbReported
    • AppCrashOccurred
    • AppStartOccurred
    • BatteryLevelChanged
    • BatterySaverModeStateChanged
    • BleScanResultReceived
    • BleScanStateChanged
    • ChargingStateChanged
    • DeviceIdleModeStateChanged
    • ForegroundServiceStateChanged
    • GpsScanStateChanged
    • JobStateChanged
    • PluggedStateChanged
    • ScheduledJobStateChanged
    • ScreenStateChanged
    • SyncStateChanged
    • SystemElapsedRealtime
    • UidProcessStateChanged
    • WakelockStateChanged
    • WakeupAlarmOccurred
    • WifiLockStateChanged
    • WifiMulticastLockStateChanged
    • WifiScanStateChanged
  • [C-0-4] डिवाइस पर adb डेमन, डिफ़ॉल्ट रूप से बंद होना चाहिए. साथ ही, Android Debug Bridge को चालू करने के लिए, उपयोगकर्ता के पास कोई ऐसा तरीका होना चाहिए जिसका इस्तेमाल किया जा सके.
  • [C-0-5] यह ज़रूरी है कि यह सुरक्षित adb के साथ काम करे. Android में सुरक्षितADB की सुविधा शामिल है. Secure adb, पुष्टि किए गए होस्ट पर adb को चालू करता है.
  • [C-0-6] होस्ट मशीन से adb को कनेक्ट करने की सुविधा देनी ज़रूरी है. खास तौर से:

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

  • [C-3-1] लोकल-एरिया नेटवर्क (जैसे, ईथरनेट या वाई-फ़ाई) के ज़रिए adb को लागू करना ज़रूरी है.
  • [C-3-2] Windows 7, 8, और 10 के लिए ड्राइवर उपलब्ध कराना ज़रूरी है, ताकि डेवलपर adb प्रोटोकॉल का इस्तेमाल करके डिवाइस से कनेक्ट कर सकें.

  अगर डिवाइस में वाई-फ़ाई या ईथरनेट के ज़रिए होस्ट मशीन से adb कनेक्शन बनाने की सुविधा है, तो:

  • [C-4-1] AdbManager#isAdbWifiSupported() का तरीका, true को दिखाना चाहिए.

  अगर डिवाइस में वाई-फ़ाई या ईथरनेट के ज़रिए होस्ट मशीन से adb कनेक्शन की सुविधा काम करती है और उसमें कम से कम एक कैमरा है, तो:

  • [C-5-1] AdbManager#isAdbWifiQrSupported() का तरीका, true को ज़रूर दिखाना चाहिए.

• Dalvik डीबग मॉनिटर सेवा (ddms)

  • [C-0-7] Android SDK टूल में बताई गई सभी ddms सुविधाओं के साथ काम करना चाहिए. ddms, adb का इस्तेमाल करता है. इसलिए, ddms के लिए सहायता डिफ़ॉल्ट रूप से बंद होनी चाहिए. हालांकि, जब भी उपयोगकर्ता ने ऊपर बताए गए तरीके से Android Debug Bridge चालू किया हो, तब ddms के लिए सहायता चालू होनी चाहिए.

• SysTrace

  • [C-0-9] Android SDK में बताए गए तरीके से, systrace टूल के साथ काम करना चाहिए. Systrace की सुविधा डिफ़ॉल्ट रूप से बंद होनी चाहिए. साथ ही, Systrace को चालू करने के लिए, उपयोगकर्ता के पास कोई ऐसा तरीका होना चाहिए जिसका इस्तेमाल किया जा सके.

• Perfetto

  • [C-SR-1] हमारा सुझाव है कि शेल उपयोगकर्ता को /system/bin/perfetto बाइनरी उपलब्ध कराएं, जिसका cmdline, perfetto दस्तावेज़ के मुताबिक हो.
  • [C-SR-2] हमारा सुझाव है कि आप perfetto दस्तावेज़ में बताए गए स्कीमा के मुताबिक, protobuf कॉन्फ़िगरेशन को इनपुट के तौर पर स्वीकार करने के लिए, perfetto बाइनरी का इस्तेमाल करें.
  • [C-SR-3] हमारा सुझाव है कि आप perfetto दस्तावेज़ में बताए गए स्कीमा के मुताबिक, protobuf ट्रैक को आउटपुट के तौर पर लिखें.
  • [C-SR-4] हमारा सुझाव है कि आप perfetto दस्तावेज़ में बताए गए डेटा सोर्स के साथ-साथ, कम से कम perfetto बाइनरी भी उपलब्ध कराएं.

• Low Memory Killer

  • [C-0-12] जब किसी ऐप्लिकेशन को कम मेमोरी किलर की वजह से बंद किया जाता है, तो LMK_KILL_OCCURRED_FIELD_NUMBER ऐटम को statsd लॉग में लिखना ज़रूरी है.

• टेस्ट हार्नेस मोड अगर डिवाइस पर, शेल कमांड cmd testharness और cmd testharness enable काम करते हैं, तो:

  • [C-2-1] ActivityManager.isRunningInUserTestHarness() के लिए true दिखाना ज़रूरी है
  • [C-2-2] टेस्ट हार्नेस मोड के दस्तावेज़ में बताए गए तरीके के मुताबिक, टेस्ट हार्नेस मोड को लागू करना ज़रूरी है.

• जीपीयू के काम करने की जानकारी

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

  • [C-0-13] power/gpu_work_period कर्नेल ट्रैसपॉइंट से मिले, इकट्ठा किए गए GPU के काम के डेटा को दिखाने के लिए, शेल कमांड dumpsys gpu --gpuwork को लागू करना ज़रूरी है. अगर ट्रैसपॉइंट काम नहीं करता है, तो कोई डेटा न दिखाएं. AOSP का लागू किया गया वर्शन frameworks/native/services/gpuservice/gpuwork/ है.

अगर डिवाइस में android.hardware.vulkan.version सुविधा फ़्लैग की मदद से, Vulkan 1.0 या इसके बाद के वर्शन के साथ काम करने की सुविधा मौजूद है, तो:

• [C-1-1] ऐप्लिकेशन डेवलपर को जीपीयू डीबग लेयर को चालू/बंद करने की सुविधा देनी ज़रूरी है.
• [C-1-2] GPU डीबग लेयर चालू होने पर, vkEnumerateInstanceLayerProperties() और vkCreateInstance() एपीआई तरीकों के साथ काम करने के लिए, डीबग किए जा सकने वाले ऐप्लिकेशन की बेस डायरेक्ट्री में, बाहरी टूल (यानी प्लैटफ़ॉर्म या ऐप्लिकेशन पैकेज का हिस्सा नहीं) से मिलने वाली लाइब्रेरी में लेयर की गिनती करना ज़रूरी है.

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

Android में डेवलपर के लिए, ऐप्लिकेशन के डेवलपमेंट से जुड़ी सेटिंग कॉन्फ़िगर करने की सुविधा शामिल है.

डिवाइस में लागू किए गए 'डेवलपर के विकल्प', एक जैसा अनुभव देने चाहिए. इसके लिए, ये ज़रूरी हैं:

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

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

अगर किसी डिवाइस में कोई ऐसा हार्डवेयर कॉम्पोनेंट शामिल है जिसके लिए तीसरे पक्ष के डेवलपर के पास एपीआई है, तो:

• [C-0-1] डिवाइस में लागू किए गए एपीआई को, Android SDK के दस्तावेज़ में बताए गए तरीके से लागू करना ज़रूरी है.

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

• [C-0-2] कॉम्पोनेंट एपीआई के लिए, अब भी पूरी क्लास की परिभाषाएं (SDK टूल के दस्तावेज़ के मुताबिक) ज़रूर दी जानी चाहिए.
• [C-0-3] एपीआई के व्यवहार को किसी सही तरीके से, नो-ऑप के तौर पर लागू करना ज़रूरी है.
• [C-0-4] SDK दस्तावेज़ में अनुमति होने पर, एपीआई के तरीके को शून्य वैल्यू दिखानी चाहिए.
• [C-0-5] एपीआई के तरीके, उन क्लास के लिए कोई कार्रवाई नहीं करने वाले लागू होने चाहिए जहां SDK टूल के दस्तावेज़ में, शून्य वैल्यू की अनुमति नहीं है.
• [C-0-6] एपीआई के तरीकों से ऐसे अपवाद नहीं होने चाहिए जिनके बारे में SDK टूल के दस्तावेज़ में नहीं बताया गया है.
• [C-0-7] डिवाइस के लागू होने पर, एक ही बिल्ड फ़िंगरप्रिंट के लिए, android.content.pm.PackageManager क्लास पर getSystemAvailableFeatures() और hasSystemFeature(String) तरीकों से, हार्डवेयर कॉन्फ़िगरेशन की सटीक जानकारी लगातार रिपोर्ट की जानी चाहिए.

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

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

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

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

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

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

7.1.1.1. स्क्रीन का साइज़ और आकार

Android यूज़र इंटरफ़ेस (यूआई) फ़्रेमवर्क, अलग-अलग लॉजिकल स्क्रीन लेआउट साइज़ के साथ काम करता है. साथ ही, ऐप्लिकेशन को SCREENLAYOUT_SIZE_MASK और Configuration.smallestScreenWidthDp के साथ Configuration.screenLayout के ज़रिए, मौजूदा कॉन्फ़िगरेशन के स्क्रीन लेआउट साइज़ के बारे में क्वेरी करने की अनुमति देता है.

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

• [C-0-1] Android SDK टूल के दस्तावेज़ में बताए गए तरीके के मुताबिक, Configuration.screenLayout के लिए सही लेआउट साइज़ की जानकारी देना ज़रूरी है. खास तौर पर, डिवाइस के लागू होने पर, डेंसिटी-इंडिपेंडेंट पिक्सल (डीपी) के हिसाब से स्क्रीन के डाइमेंशन सही होने चाहिए. इन डाइमेंशन की जानकारी यहां दी गई है:

  • जिन डिवाइसों पर Configuration.uiMode को UI_MODE_TYPE_WATCH के अलावा किसी और वैल्यू पर सेट किया गया है और Configuration.screenLayout के लिए small साइज़ की जानकारी दी गई है उनके लिए, डिवाइस का डाइमेंशन कम से कम 426 dp x 320 dp होना चाहिए.
  • जिन डिवाइसों के लिए Configuration.screenLayout का साइज़ normal बताया गया है उनके लिए, कम से कम 480 डीपी x 320 डीपी का साइज़ ज़रूरी है.
  • Configuration.screenLayout के लिए large साइज़ की जानकारी देने वाले डिवाइसों का स्क्रीन साइज़, कम से कम 640 dp x 480 dp होना चाहिए.
  • Configuration.screenLayout के लिए xlarge साइज़ की जानकारी देने वाले डिवाइसों का डाइमेंशन, कम से कम 960 dp x 720 dp होना चाहिए.

• [C-0-2] Android SDK के दस्तावेज़ में बताए गए तरीके के मुताबिक, AndroidManifest.xml में <supports-screens> एट्रिब्यूट की मदद से, ऐप्लिकेशन के लिए बताई गई स्क्रीन साइज़ के साथ सही तरीके से काम करना चाहिए.

• इसमें Android के साथ काम करने वाले ऐसे डिसप्ले हो सकते हैं जिनके कोने गोल हों.

अगर डिवाइस पर UI_MODE_TYPE_NORMAL की सुविधा काम करती है और इसमें राउंड किए गए कोनों वाले, Android के साथ काम करने वाले डिसप्ले शामिल हैं, तो:

• [C-1-1] यह पक्का करना ज़रूरी है कि इनमें से कम से कम एक ज़रूरी शर्त पूरी की गई हो:

  • गोल किए गए कोनों की त्रिज्या 38 डीपी से कम या उसके बराबर हो.
  • जब लॉजिकल डिसप्ले के हर कोने पर 15 डीपी x 15 डीपी का बॉक्स ऐंकर किया जाता है, तो स्क्रीन पर हर बॉक्स का कम से कम एक पिक्सल दिखता है.

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

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

• [C-2-1] Window Manager Jetpack लाइब्रेरी का इस्तेमाल करने के लिए, extensions API का सबसे नया वर्शन या sidecar API का स्टैबल वर्शन लागू करना ज़रूरी है.

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

• [C-3-1] ऐप्लिकेशन में, एक्सटेंशन या साइडकार एपीआई के ज़रिए, हिंज या फ़ोल्ड की स्थिति, सीमाएं, और स्थिति की जानकारी देना ज़रूरी है.

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

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

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

• [C-0-1] Configuration.uiMode को UI_MODE_TYPE_NORMAL पर सेट करने वाले डिवाइस के लिए, आसपेक्ट रेशियो की वैल्यू 1.86 (लगभग 16:9) से कम या उसके बराबर होनी चाहिए. ऐसा तब तक ज़रूरी है, जब तक ऐप्लिकेशन इनमें से किसी एक शर्त को पूरा न करता हो:

  • ऐप्लिकेशन ने android.max_aspect मेटाडेटा वैल्यू के ज़रिए, यह एलान किया है कि यह बड़ी स्क्रीन के आसपेक्ट रेशियो के साथ काम करता है.
  • ऐप्लिकेशन, android:resizeableActivity एट्रिब्यूट की मदद से यह एलान करता है कि उसका साइज़ बदला जा सकता है.
  • ऐप्लिकेशन, एपीआई लेवल 24 या उसके बाद के वर्शन को टारगेट करता हो और उसमें ऐसा android:maxAspectRatio न दिया गया हो जिससे ऐस्पेक्ट रेशियो पर पाबंदी लगे.

• [C-0-3] Configuration.uiMode को UI_MODE_TYPE_WATCH के तौर पर सेट करने वाले डिवाइसों के लिए, आसपेक्ट रेशियो की वैल्यू 1.0 (1:1) पर सेट होनी चाहिए.

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

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

• [C-0-1] डिफ़ॉल्ट रूप से, डिवाइस के लागू होने पर, DENSITY_DEVICE_STABLE API के ज़रिए DisplayMetrics पर दी गई सूची में मौजूद, Android फ़्रेमवर्क के सिर्फ़ एक डेंसिटी की जानकारी दी जानी चाहिए. यह वैल्यू कभी नहीं बदलनी चाहिए. हालांकि, डिवाइस, डिसप्ले कॉन्फ़िगरेशन में उपयोगकर्ता के किए गए बदलावों (उदाहरण के लिए, डिसप्ले साइज़) के हिसाब से, डिसप्ले के डेंसिटी की जानकारी अलग-अलग दे सकता है. ये बदलाव, डिवाइस के शुरू में बूट होने के बाद किए जाते हैं.

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

अगर डिवाइस के डिसप्ले साइज़ को बदलने का विकल्प है, तो:

• [C-1-1] डिसप्ले का साइज़, नेटिव डेंसिटी के 1.5 गुना से ज़्यादा नहीं होना चाहिए. इसके अलावा, स्क्रीन का कम से कम असरदार डाइमेंशन 320dp (रिसॉर्स क्वालीफ़ायर sw320dp के बराबर) से कम नहीं होना चाहिए.
• [C-1-2] डिसप्ले साइज़ को नेटिव डेंसिटी के 0.85 गुने से कम नहीं किया जाना चाहिए.
• बेहतर इस्तेमाल और फ़ॉन्ट के साइज़ में एक जैसी जानकारी देने के लिए, हमारा सुझाव है कि नेटिव डिसप्ले विकल्पों के लिए, ऊपर बताई गई सीमाओं का पालन करते हुए, यहां बताई गई स्केलिंग का इस्तेमाल करें
  • छोटा: 0.85x
  • डिफ़ॉल्ट: 1x (नेटिव डिसप्ले स्केल)
  • बड़ा: 1.15x
  • बड़ा: 1.3x
  • सबसे बड़ा 1.45x

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

अगर डिवाइस में Android के साथ काम करने वाले डिसप्ले या Android के साथ काम करने वाली डिसप्ले स्क्रीन पर वीडियो आउटपुट शामिल है, तो:

• [C-1-1] android.util.DisplayMetrics API में बताई गई, Android डिवाइसों के साथ काम करने वाली सभी डिसप्ले मेट्रिक के लिए, सही वैल्यू रिपोर्ट करना ज़रूरी है.

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

• [C-2-1] एमुलेट किए गए डिफ़ॉल्ट view.Display के लिए, android.util.DisplayMetrics एपीआई में बताई गई, Android के साथ काम करने वाले डिसप्ले की सही वैल्यू दिखानी चाहिए.

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

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

• [C-0-1] यह बताना ज़रूरी है कि ऐप्लिकेशन किन स्क्रीन ओरिएंटेशन (android.hardware.screen.portrait और/या android.hardware.screen.landscape) के साथ काम करता है. साथ ही, यह भी बताना ज़रूरी है कि ऐप्लिकेशन कम से कम एक ओरिएंटेशन के साथ काम करता है. उदाहरण के लिए, टेलिविज़न या लैपटॉप जैसे ऐसे डिवाइसों के लिए, सिर्फ़ android.hardware.screen.landscape को रिपोर्ट किया जाना चाहिए जिनकी स्क्रीन का ओरिएंटेशन लैंडस्केप में फ़िक्स होता है.
• [C-0-2] जब भी android.content.res.Configuration.orientation, android.view.Display.getOrientation() या अन्य एपीआई के ज़रिए डिवाइस के मौजूदा ओरिएंटेशन के बारे में क्वेरी की जाती है, तो डिवाइस के ओरिएंटेशन की सही वैल्यू दिखानी चाहिए.

अगर डिवाइस पर स्क्रीन के दोनों ओरिएंटेशन काम करते हैं, तो:

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

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

7.1.4.1 OpenGL ES

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

• [C-0-1] मैनेज किए जा रहे एपीआई (जैसे, GLES10.getString() तरीके से) और नेटिव एपीआई के ज़रिए, काम करने वाले OpenGL ES वर्शन (1.1, 2.0, 3.0, 3.1, 3.2) की सही पहचान करनी चाहिए.
• [C-0-2] इसमें, उन सभी मैनेज किए जा रहे एपीआई और नेटिव एपीआई के लिए सहायता शामिल होनी चाहिए जिनके लिए उन्होंने OpenGL ES के हर उस वर्शन की पहचान की है जिस पर ये काम करते हैं.

अगर डिवाइस में स्क्रीन या वीडियो आउटपुट शामिल है, तो:

• [C-1-1] Android SDK के दस्तावेज़ में बताए गए तरीके से, OpenGL ES 1.1 और 2.0, दोनों के साथ काम करना चाहिए.
• [C-SR-1] हमारा सुझाव है कि आप OpenGL ES 3.1 का इस्तेमाल करें.
• यह OpenGL ES 3.2 के साथ काम करना चाहिए.

OpenGL ES dEQP टेस्ट को कई टेस्ट सूचियों में बांटा गया है. इनमें से हर सूची में, टेस्ट की तारीख/वर्शन नंबर शामिल होता है. ये external/deqp/android/cts/main/glesXX-main-YYYY-MM-DD.txt पर Android सोर्स ट्री में मौजूद हैं. अगर कोई डिवाइस, खुद से बताए गए लेवल पर OpenGL ES के साथ काम करता है, तो इसका मतलब है कि वह इस लेवल और उससे पहले के सभी टेस्ट की सूचियों में dEQP टेस्ट पास कर सकता है.

अगर डिवाइस पर लागू किए गए वर्शन, OpenGL ES के किसी वर्शन के साथ काम करते हैं, तो:

• [C-2-1] ऐप्लिकेशन में लागू किए गए किसी भी अन्य OpenGL ES एक्सटेंशन की जानकारी, OpenGL ES मैनेज किए जाने वाले एपीआई और नेटिव एपीआई के ज़रिए दी जानी चाहिए. इसके अलावा, उन एक्सटेंशन स्ट्रिंग की जानकारी नहीं दी जानी चाहिए जिन पर ऐप्लिकेशन काम नहीं करता.
• [C-2-2] यह EGL_KHR_image, EGL_KHR_image_base, EGL_ANDROID_image_native_buffer, EGL_ANDROID_get_native_client_buffer, EGL_KHR_wait_sync, EGL_KHR_get_all_proc_addresses, EGL_ANDROID_presentation_time, EGL_KHR_swap_buffers_with_damage, EGL_ANDROID_recordable, और EGL_ANDROID_GLES_layers एक्सटेंशन के साथ काम करना चाहिए.
• [C-2-3] android.software.opengles.deqp.level सुविधा फ़्लैग की मदद से काम करने वाले OpenGL ES dEQP टेस्ट के ज़्यादा से ज़्यादा वर्शन की रिपोर्ट करना ज़रूरी है.
• [C-2-4] android.software.opengles.deqp.level सुविधा फ़्लैग में बताए गए मुताबिक, कम से कम 132383489 वर्शन (1 मार्च, 2020 से) के साथ काम करना चाहिए.
• [C-2-5] यह ज़रूरी है कि ऐप्लिकेशन, 132383489 वर्शन और android.software.opengles.deqp.level सुविधा फ़्लैग में बताए गए वर्शन के बीच, टेस्ट की सूचियों में मौजूद सभी OpenGL ES dEQP टेस्ट पास करे. ऐसा, काम करने वाले हर OpenGL ES वर्शन के लिए करना होगा.
• [C-SR-2] हमारा सुझाव है कि आप EGL_KHR_partial_update और OES_EGL_image_external एक्सटेंशन का इस्तेमाल करें.
• getString() तरीके से, उन सभी टेक्सचर को सही तरीके से रिपोर्ट करना चाहिए जिनका इस्तेमाल वे कर सकते हैं. आम तौर पर, ये टेक्सचर वेंडर के हिसाब से होते हैं.
• EGL_IMG_context_priority और EGL_EXT_protected_content एक्सटेंशन के साथ काम करना चाहिए.

अगर डिवाइस में OpenGL ES 3.0, 3.1 या 3.2 का इस्तेमाल किया जा रहा है, तो:

• [C-3-1] libGLESv2.so लाइब्रेरी में मौजूद OpenGL ES 2.0 फ़ंक्शन सिंबल के अलावा, इन वर्शन के लिए भी संबंधित फ़ंक्शन सिंबल एक्सपोर्ट करने होंगे.
• [C-SR-3] OES_EGL_image_external_essl3 एक्सटेंशन के साथ काम करने का सुझाव दिया जाता है.

�