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

1. परिचय

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

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

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

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

अगर सेक्शन 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 डिवाइस को हैंडहेल्ड के तौर पर तब ही माना जाता है, जब वह इन सभी शर्तों को पूरा करता हो:

• इसमें बैटरी जैसा कोई पावर सोर्स होना चाहिए.
• फ़ोन की डायगनल स्क्रीन का साइज़ 4 इंच से 8 इंच के बीच हो.
• टचस्क्रीन इनपुट इंटरफ़ेस हो.

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

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

2.2.1. हार्डवेयर

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

• [7.1.1.1/H-0-1] डिवाइस में कम से कम एक ऐसा डिसप्ले होना चाहिए जो Android के साथ काम करता हो. साथ ही, इसके छोटे किनारे की लंबाई कम से कम 2.2" और लंबे किनारे की लंबाई कम से कम 3.4" होनी चाहिए.

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

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

• [7.1.1.1/H-0-3]* तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराए गए हर UI_MODE_NORMAL डिसप्ले को, बिना किसी रुकावट के दिखने वाले डिसप्ले के उस हिस्से पर मैप करना ज़रूरी है जो कम से कम 2.2" इंच के छोटे किनारे और 3.4" इंच के लंबे किनारे पर हो.

• [7.1.1.3/H-0-1]* DENSITY_DEVICE_STABLE की वैल्यू को, डिसप्ले के असल, फ़िज़िकल डेंसिटी से 92% या उससे ज़्यादा पर सेट करना ज़रूरी है.

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

• [7.1.4.2/H-1-1] Android Baseline 2021 प्रोफ़ाइल में बताई गई ज़रूरी शर्तों को पूरा करना ज़रूरी है.

अगर हैंडहेल्ड डिवाइस पर 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] जीएनएसएस स्यूडोरेंज और स्यूडोरेंज रेट की जानकारी देना ज़रूरी है. यह जानकारी, खुले आसमान में जगह की जानकारी तय करने के बाद, स्थिर रहने या 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] हमारा सुझाव है कि आप ऐसे पोज़ेस सेंसर का इस्तेमाल करें जिसमें छह डिग्री ऑफ़ फ़्रीडम हों.

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

• [7.4.3/H] इसमें ब्लूटूथ और ब्लूटूथ एलई के लिए सहायता शामिल होनी चाहिए.

ऐसे हैंडहेल्ड डिवाइस जिनमें ब्लूटूथ LE की सुविधा काम करती है:

• [7.4.3/H-SR-1] हमारा सुझाव है कि आप डिवाइस में, Bluetooth LE डेटा पैकेट की लंबाई बढ़ाने की सुविधा का इस्तेमाल करें.

  ध्यान दें: Android के आने वाले वर्शन में, यह ज़रूरी शर्त [7.4.3/H-SR-1] लागू हो जाएगी.

नई ज़रूरी शर्तों की समयसीमा खत्म होना

अगर डिवाइसों में 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 सेंटीमीटर की दूरी पर WifiRttManager#startRanging Android API की मदद से, 90वें प्रतिशताइल में 160 मेगाहर्ट्ज़ बैंडविड्थ पर +/-1 मीटर, 80 मेगाहर्ट्ज़ बैंडविड्थ पर +/-2 मीटर, 40 मेगाहर्ट्ज़ बैंडविड्थ पर +/-4 मीटर, और 20 मेगाहर्ट्ज़ बैंडविड्थ पर +/-8 मीटर की रेंज दें.

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

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

• [7.4.3/H-1-3] Rx ऑफ़सेट को मेज़र करना और उसका समाधान करना ज़रूरी है, ताकि यह पक्का किया जा सके कि ADVERTISE_TX_POWER_HIGH पर ट्रांसमिशन करने वाले रेफ़रंस डिवाइस से 1 मीटर की दूरी पर, मीडियन बीएलई आरएसएसआई -50dBm +/-15 dB हो.
• [7.4.3/H-1-4] Tx ऑफ़सेट को मेज़र करना और उसका समाधान करना ज़रूरी है, ताकि यह पक्का किया जा सके कि 1 मीटर की दूरी पर मौजूद रेफ़रंस डिवाइस से स्कैन करते समय और ADVERTISE_TX_POWER_HIGH पर ट्रांसमिट करते समय, मीडियन बीएलई आरएसएसआई -50dBm +/-15 dB हो.

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

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

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

• [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] इसमें पेरिफ़रल मोड के साथ काम करने वाला यूएसबी पोर्ट होना चाहिए.

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

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

• [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] एचआईडी कोड के लिए, यहां दी गई सॉफ़्टवेयर मैपिंग ज़रूर उपलब्ध कराएं:

फ़ंक्शन	मैपिंग	संदर्भ	व्यवहार
A	एचआईडी के इस्तेमाल का पेज: 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] अगर USB ऑडियो टर्मिनल टाइप फ़ील्ड 0x0302 है, तो AudioDeviceInfo.TYPE_USB_HEADSET टाइप के डिवाइस और भूमिका isSink() की सूची ज़रूर होनी चाहिए.

• [7.8.2.2/H-4-2] अगर यूएसबी ऑडियो टर्मिनल टाइप फ़ील्ड 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] अगर USB ऑडियो टर्मिनल टाइप फ़ील्ड 0x603 है, तो AudioDeviceInfo.TYPE_USB_DEVICE टाइप और भूमिका isSink() वाले डिवाइस की सूची ज़रूर होनी चाहिए.

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

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

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

अगर ऐसे हाथ में पकड़े जाने वाले डिवाइसों के लिए, जिनमें android.hardware.audio.output और android.hardware.microphone की जानकारी दी गई है, तो: सेक्शन में RTL और TTL की ज़रूरी शर्तें देखें 5.6.

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

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

नई ज़रूरी शर्तों की समयसीमा खत्म होना

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

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

• [7.10/H] ऐक्चुएटर को उस जगह के आस-पास रखना चाहिए जहां डिवाइस को आम तौर पर हाथों से पकड़ा जाता है या छुआ जाता है.

• [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.2/H-0-3] AV1

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

• [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
• [5.3/H-0-6] AV1

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 को दिए गए रूट) के बीच स्विच कर सकें.

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

• [3.8.3/H-1-1] ऐप्लिकेशन में स्क्रीन पिन करने की सुविधा को लागू करना ज़रूरी है. साथ ही, उपयोगकर्ता को सेटिंग मेन्यू उपलब्ध कराना होगा, ताकि वह इस सुविधा को टॉगल कर सके.

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

• [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-1-6] डिवाइस पर लागू करने के लिए, उपयोगकर्ता के लिए उपलब्ध सुविधाओं को इस तरह सटीक तरीके से रेंडर करना ज़रूरी है:

  • अगर डिवाइस पर config_supportsMultiWindow=true सेट है और ऐप्लिकेशन ने ControlsProviderService एलान में, मेटाडेटा META_DATA_PANEL_ACTIVITY एलान किया है, जिसमें मान्य गतिविधि का ComponentName (जैसा कि एपीआई ने बताया है) शामिल है, तो ऐप्लिकेशन को इस उपयोगकर्ता के लिए उपलब्ध सुविधा में बताई गई गतिविधि को एम्बेड करना होगा.
  • अगर ऐप्लिकेशन में मेटाडेटा META_DATA_PANEL_ACTIVITY का एलान नहीं किया गया है, तो उसे ControlsProviderService एपीआई के ज़रिए बताए गए फ़ील्ड के साथ-साथ, Control एपीआई के ज़रिए बताए गए फ़ील्ड भी रेंडर करने होंगे.

• [3.8.16/H-1-7] अगर ऐप्लिकेशन में मेटाडेटा META_DATA_PANEL_ACTIVITY का एलान किया गया है, तो एम्बेड की गई गतिविधि को लॉन्च करते समय, उसे [3.8.16/H-1-5] में बताई गई सेटिंग की वैल्यू EXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS का इस्तेमाल करके पास करना ज़रूरी है.

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

• [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 से पार्स किए गए इंटेंट की गतिविधि शुरू करनी चाहिए.

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

• [7.4.1.2/H-0-1] फ़ीचर फ़्लैग android.software.telecom का एलान करना ज़रूरी है.
• [7.4.1.2/H-0-2] टेलीकॉम फ़्रेमवर्क लागू करना ज़रूरी है.

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 टूल के दस्तावेज़ में बताए गए तरीके के मुताबिक, इनमें से हर सेवा के शुरू होने से लेकर अब तक की अवधि भी दिखनी चाहिए.

• [8.5/H-0-2]ऐसे ऐप्लिकेशन को रोकने के लिए, उपयोगकर्ता को कोई सुविधा देनी ज़रूरी है जो फ़ोरग्राउंड सेवा या उपयोगकर्ता की ओर से शुरू की गई कोई कार्रवाई कर रहा हो.

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

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

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

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

डिवाइस पर लागू किए गए टूल के लिए, android.software.credentials के साथ काम करने की जानकारी ज़रूर होनी चाहिए. साथ ही, यह भी ज़रूरी है कि:

• [9/H-0-2] क्रेडेंशियल मैनेजर के लिए, सेवा देने वाली पसंदीदा कंपनी को चुनने की अनुमति देने के लिए, android.settings.CREDENTIAL_PROVIDER के मकसद का पालन करना ज़रूरी है. यह सेवा देने वाली कंपनी, जानकारी अपने-आप भरने की सुविधा के लिए चालू हो जाएगी. साथ ही, Credential Manager की मदद से डाले गए नए क्रेडेंशियल को सेव करने के लिए, यह डिफ़ॉल्ट जगह भी होगी.

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

नई ज़रूरी शर्तों की समयसीमा खत्म होना

अगर डिवाइस पर android.hardware.telephony की सुविधा काम करती है, तो:

• [9.5/H-1-1] UserManager.isHeadlessSystemUserMode को true पर सेट नहीं किया जाना चाहिए.

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

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

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

• [9.11/H-0-5] यह ज़रूरी है कि कुंजी की पुष्टि करने की सुविधा काम करे. इसमें, पुष्टि करने के लिए इस्तेमाल होने वाली साइनिंग कुंजी को सुरक्षित हार्डवेयर से सुरक्षित किया गया हो और साइनिंग की प्रोसेस को सुरक्षित हार्डवेयर में किया गया हो. पुष्टि करने के लिए इस्तेमाल होने वाली साइनिंग कुंजियों को ज़रूर ज़्यादा से ज़्यादा डिवाइसों के साथ शेयर किया जाना चाहिए, ताकि डिवाइस के पहचानकर्ता के तौर पर हमेशा इस्तेमाल किए जाने से रोका जा सके. इस शर्त को पूरा करने का एक तरीका यह है कि जब तक किसी SKU की कम से कम 1,00,000 यूनिट का प्रॉडक्शन न हो जाए, तब तक एक ही पुष्टि करने वाली कुंजी शेयर की जाए. अगर किसी SKU की 1,00,000 से ज़्यादा यूनिट बनाई जाती हैं, तो हर 1,00,000 यूनिट के लिए अलग-अलग बटन का इस्तेमाल किया जा सकता है.

  ध्यान दें: इस शर्त को पूरा करने के लिए, आपको किसी SKU के लिए एक ही पुष्टि करने वाली कुंजी तब तक शेयर करनी होगी, जब तक उस SKU की कम से कम 1,00,000 यूनिट का प्रॉडक्शन न हो जाए. अगर उस SKU की 1,00,000 से ज़्यादा यूनिट बनाई जाती हैं, तो इसके बाद 1,00,000 यूनिट के हर ग्रुप के लिए, अलग-अलग कुंजी का इस्तेमाल किया जा सकता है. इसके अलावा, डिवाइस पर कुछ समय के लिए मान्य पुष्टि करने वाली कुंजियों को उपलब्ध कराने के लिए, रिमोट पासकोड प्रोविज़निंग सलूशन का इस्तेमाल किया जा सकता है.

नई ज़रूरी शर्तों की समयसीमा खत्म होना

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

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

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

अगर डिवाइस में सुरक्षित लॉक स्क्रीन है और एक या उससे ज़्यादा भरोसेमंद एजेंट हैं, जो TrustAgentService सिस्टम एपीआई को लागू करते हैं, तो:

• [9.11.1/H-1-1] पुष्टि करने के लिए सुझाए गए मुख्य तरीकों (जैसे, पिन, पैटर्न, पासवर्ड) में से किसी एक का इस्तेमाल करने के लिए, उपयोगकर्ता को हर 72 घंटे से ज़्यादा बार चुनौती देनी होगी.

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

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

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

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

अगर हैंडहेल्ड डिवाइस के लागू होने पर UserManager.isHeadlessSystemUserMode को true पर सेट किया जाता है, तो

• [9.5/H-4-1] में, eUICC और कॉल करने की सुविधा वाले ई-सिम के लिए सहायता शामिल नहीं होनी चाहिए.
• [9.5/H-4-2] ऐप्लिकेशन में android.hardware.telephony के साथ काम करने की सुविधा का एलान नहीं किया जाना चाहिए.

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

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

पाबंदी वाली सेटिंग

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

• किसी "ऐप स्टोर" ऐप्लिकेशन (PackageManager के तौर पर PACKAGE_DOWNLOADED_FILE के तौर पर पहचाने गए) के बजाय, किसी दूसरे ऐप्लिकेशन (उदाहरण के लिए, मैसेजिंग ऐप्लिकेशन या ब्राउज़र) से डाउनलोड करने के बाद इंस्टॉल किया गया हो.
• किसी लोकल फ़ाइल से इंस्टॉल किया गया हो. उदाहरण के लिए, ऐप्लिकेशन को साइडलोड किया गया हो. PackageManager की पहचान, PACKAGE_SOURCE_LOCAL_FILE के तौर पर की गई हो.

यहां [9.8/H-0-5] में दी गई, लागू की गई अनुमतियों और उनसे जुड़े आइडेंटिफ़ायर में से किसी के लिए.

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

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

• [9.8/H-0-1] ऊपर बताई गई पाबंदी वाली सेटिंग को इनके लिए लागू करना ज़रूरी है:

  • खास अनुमतियां
    • सुलभता (AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE)
    • सूचना को सुनने की सुविधा (AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS)
    • डिवाइस के एडमिन ऐप्लिकेशन (Manifest.permission.BIND_DEVICE_ADMIN)
    • दूसरे ऐप्लिकेशन के ऊपर दिखाना (AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW)
    • इस्तेमाल का ऐक्सेस (AppOpsManager.OPSTR_GET_USAGE_STATS)
  • भूमिकाएं (डिफ़ॉल्ट ऐप्लिकेशन)
    • डायलर (RoleManager.ROLE_DIALER)
    • एसएमएस (RoleManager.ROLE_SMS)
  • रनटाइम की अनुमतियां
    • एसएमएस का रनटाइम (Manifest.permission_group.SMS)

• [9.8/H-0-2] पाबंदी वाली सेटिंग को डिफ़ॉल्ट रूप से चालू करना ज़रूरी है. साथ ही, हमारा सुझाव है कि आप कोई ऐसा विकल्प न दें जिससे उपयोगकर्ता सभी ऐप्लिकेशन के लिए पाबंदी वाली सेटिंग को बंद कर सके.

• [9.8/H-0-3] यह ज़रूरी है कि नीति के उल्लंघन की वजह से ऐप्लिकेशन पर लागू की गई किसी भी अनुमति को देने से पहले, उपयोगकर्ता की पुष्टि की जाए.

• [9.8/H-0-4] यह ज़रूरी है कि उपयोगकर्ता की पुष्टि के बाद ही, पाबंदी वाली सेटिंग चालू की जा सकें. इसके लिए, कवर किए गए ऐप्लिकेशन के AppInfo पेज पर, EnhancedConfirmationManager API का इस्तेमाल किया जाना चाहिए.

• [9.8/H-0-5] हमारा सुझाव है कि सभी खास अनुमतियों के लिए, EnhancedConfirmationManager के साथ इंटिग्रेट करें और उसे कॉल करें. इससे यह डाइनैमिक तौर पर तय किया जा सकेगा कि वे पाबंदी वाली सेटिंग हैं या नहीं.

  • अलार्म और रिमाइंडर: AppOpsManager.OPSTR_SCHEDULE_EXACT_ALARM
  • सभी फ़ाइलों का ऐक्सेस: AppOpsManager.OPSTR_MANAGE_EXTERNAL_STORAGE
  • अन्य ऐप्लिकेशन के ऊपर दिखाएं: AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW
  • अनजान ऐप्लिकेशन इंस्टॉल करने की अनुमति: AppOpsManager.OPSTR_REQUEST_INSTALL_PACKAGES
  • मीडिया मैनेज करना: AppOpsManager.OPSTR_MANAGE_MEDIA
  • सिस्टम की सेटिंग में बदलाव करने की अनुमति: AppOpsManager.OPSTR_WRITE_SETTINGS
  • पिक्चर में पिक्चर: AppOpsManager.OPSTR_PICTURE_IN_PICTURE
  • स्क्रीन चालू करें: AppOpsManager.OPSTR_TURN_SCREEN_ON
  • पूरी स्क्रीन पर सूचनाएं दिखाने की अनुमति: AppOpsManager.OPSTR_USE_FULL_SCREEN_INTENT
  • वाई-फ़ाई कंट्रोल: AppOpsManager.OPSTR_CHANGE_WIFI_STATE
  • सुलभता: AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE
  • सूचना को सुनने की सुविधा: AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS
  • इस्तेमाल का ऐक्सेस: AppOpsManager.OPSTR_GET_USAGE_STATS
  • डिवाइस का एडमिन: Manifest.permission.BIND_DEVICE_ADMIN
  • परेशान न करें: Manifest.permission.MANAGE_NOTIFICATIONS

ध्यान दें: अपस्ट्रीम Android Open Source Project (AOSP) इस ज़रूरी शर्त को पूरा करता है. इसके लिए, वह कॉन्फ़िगरेशन फ़ाइल में config_enhancedConfirmationModeEnabled को true पर सेट करता है और EnhancedConfirmationManager एपीआई के साथ इंटिग्रेट करता है.

नई ज़रूरी शर्तों की समयसीमा खत्म होना

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

• [9.8/H-1-1] यह पक्का करना ज़रूरी है कि हॉटवर्ड का पता लगाने वाली सेवा, सिर्फ़ सिस्टम, ContentCaptureService या SpeechRecognizer#createOnDeviceSpeechRecognizer() की बनाई गई, डिवाइस पर बोली पहचानने की सेवा को डेटा भेज सके.
• [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-1-15] यह पक्का करना ज़रूरी है कि हॉटवर्ड के सही नतीजों पर दी गई ऑडियो स्ट्रीम, हॉटवर्ड डिटेक्शन सेवा से वॉइस इंटरैक्शन सेवा पर एकतरफ़ा भेजी जाए.

• [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 या डिवाइस पर बोली पहचानने की सेवा को छोड़कर, किसी और को नहीं भेजना चाहिए.

अगर हैंडहेल्ड डिवाइस पर, सिस्टम एपीआईVisualQueryDetectionService या क्वेरी का पता लगाने के लिए, माइक और/या कैमरे के ऐक्सेस के संकेत के बिना कोई अन्य तरीका काम करता है, तो:

• [9.8/H-3-1] यह पक्का करना ज़रूरी है कि क्वेरी का पता लगाने वाली सेवा, सिर्फ़ सिस्टम या ContentCaptureService या डिवाइस पर बोली पहचानने की सेवा (SpeechRecognizer#createOnDeviceSpeechRecognizer() ने बनाई है) को डेटा भेज सके.
• [9.8/H-3-2] VisualQueryDetectionService के अलावा, किसी भी ऑडियो या वीडियो जानकारी को ContentCaptureService या डिवाइस पर बोली को लेख में बदलने वाली सेवा के अलावा, किसी और को भेजने की अनुमति नहीं दी जानी चाहिए.
• [9.8/H-3-3] जब डिवाइस को उपयोगकर्ता के डिजिटल असिस्टेंट ऐप्लिकेशन से इंटरैक्ट करने का पता चलता है, तो उसे सिस्टम यूज़र इंटरफ़ेस (यूआई) में उपयोगकर्ता को सूचना दिखानी चाहिए.उदाहरण के लिए, कैमरे की मदद से उपयोगकर्ता की मौजूदगी का पता लगाकर.
• [9.8/H-3-4] उपयोगकर्ता की क्वेरी का पता चलने के तुरंत बाद, माइक्रोफ़ोन का इंडिकेटर दिखाना ज़रूरी है. साथ ही, यूज़र इंटरफ़ेस में उपयोगकर्ता की क्वेरी को दिखाना ज़रूरी है.
• [9.8/H-3-5] उपयोगकर्ता के इंस्टॉल किए जा सकने वाले ऐप्लिकेशन को, विज़ुअल क्वेरी का पता लगाने की सेवा देने की अनुमति नहीं दी जानी चाहिए.

अगर हैंडहेल्ड डिवाइस पर 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() से मिली जानकारी के हिसाब से होनी चाहिए. साथ ही, उन ऐप्लिकेशन से जुड़े एट्रिब्यूशन मैसेज भी दिखाए जाने चाहिए.
• [9.8.2/H-4-3] सिस्टम के ऐसे ऐप्लिकेशन के लिए माइक्रोफ़ोन इंडिकेटर को नहीं छिपाना चाहिए जिनमें यूज़र इंटरफ़ेस दिखते हैं या उपयोगकर्ता सीधे तौर पर इंटरैक्ट करते हैं.
• [9.8.2/H-4-4] माइक्रोफ़ोन का इस्तेमाल करके, 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() से मिले कैमरे के इस्तेमाल से, हाल ही में इस्तेमाल किए गए और ऐक्टिव ऐप्लिकेशन के साथ-साथ उनसे जुड़े एट्रिब्यूशन मैसेज भी दिखाए जाने चाहिए.
• [9.8.2/H-5-3] सिस्टम के उन ऐप्लिकेशन के लिए कैमरे के इंडिकेटर को नहीं छिपाना चाहिए जिनमें यूज़र इंटरफ़ेस दिखते हैं या जिनमें उपयोगकर्ता सीधे तौर पर इंटरैक्ट करता है.

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

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

• [9.10/H-1-1] Android के बूट क्रम के दौरान माउंट किए गए सभी रीड-ओनली पार्टिशन की पुष्टि करना ज़रूरी है. साथ ही, VBMeta डाइजेस्ट की गिनती में, पुष्टि किए गए इन सभी पार्टिशन को शामिल करना ज़रूरी है.

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

नई ज़रूरी शर्तों की समयसीमा खत्म होना

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

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

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

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

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

• Perfetto
  • [6.1/H-0-2]* शेल उपयोगकर्ता को /system/bin/perfetto बाइनरी दिखानी चाहिए, जो cmdline के साथ काम करती हो और perfetto दस्तावेज़ के मुताबिक हो.
  • [6.1/H-0-3]* perfetto बाइनरी को इनपुट के तौर पर, ऐसा प्रोटोबस कॉन्फ़िगरेशन स्वीकार करना चाहिए जो perfetto दस्तावेज़ में बताए गए स्कीमा का पालन करता हो.
  • [6.1/H-0-4]* perfetto बाइनरी को आउटपुट के तौर पर, ऐसा प्रोटोबुक ट्रेस लिखना चाहिए जो perfetto दस्तावेज़ में बताए गए स्कीमा के मुताबिक हो.
  • [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.U दिखता है, तो:

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

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

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

नई ज़रूरी शर्तों की समयसीमा खत्म होना

• [5.1/H-1-1] CodecCapabilities.getMaxSupportedInstances() और VideoCapabilities.getSupportedPerformancePoints() तरीकों की मदद से, किसी भी कोडेक कॉम्बिनेशन में एक साथ चलाए जा सकने वाले, ज़्यादा से ज़्यादा हार्डवेयर वीडियो डिकोडर सेशन का विज्ञापन करना ज़रूरी है.

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

• [5.1/H-1-2] यह ज़रूरी है कि डिवाइस पर 8-बिट (एसडीआर) हार्डवेयर वीडियो डिकोडर सेशन (AVC, HEVC, VP9, AV1 या इसके बाद के वर्शन) के छह इंस्टेंस काम करते हों. साथ ही, ये किसी भी कोडेक कॉम्बिनेशन में, 1080 पिक्सल रिज़ॉल्यूशन पर 30 फ़्रेम प्रति सेकंड और 4K रिज़ॉल्यूशन पर 30 फ़्रेम प्रति सेकंड के तीन सेशन के साथ काम करते हों. सभी सेशन के लिए, हर सेकंड में एक से ज़्यादा फ़्रेम नहीं छोड़े जाने चाहिए. AV1 कोडेक को सिर्फ़ 1080 पिक्सल रिज़ॉल्यूशन के साथ काम करना चाहिए. हालांकि, उन्हें 1080 पिक्सल और 30 एफ़पीएस पर छह इंस्टेंस के साथ काम करना चाहिए.

नई ज़रूरी शर्तों की समयसीमा खत्म होना

• [5.1/H-1-3] CodecCapabilities.getMaxSupportedInstances() और VideoCapabilities.getSupportedPerformancePoints() तरीकों की मदद से, किसी भी कोडेक कॉम्बिनेशन में एक साथ चलाए जा सकने वाले, ज़्यादा से ज़्यादा हार्डवेयर वीडियो एन्कोडर सेशन का विज्ञापन करना ज़रूरी है.

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

• [5.1/H-1-4] यह ज़रूरी है कि डिवाइस पर 8-बिट (एसडीआर) हार्डवेयर वीडियो एन्कोडर सेशन (AVC, HEVC, VP9, AV1 या उसके बाद के वर्शन) के छह इंस्टेंस काम करते हों. साथ ही, ये इंस्टेंस किसी भी कोडेक कॉम्बिनेशन में, 1080p रिज़ॉल्यूशन पर 30 fps और 4K रिज़ॉल्यूशन पर 30 fps के चार सेशन के साथ काम करते हों. सभी सेशन के लिए, हर सेकंड में एक से ज़्यादा फ़्रेम नहीं छोड़े जाने चाहिए. AV1 कोडेक को सिर्फ़ 1080p रिज़ॉल्यूशन के साथ काम करना चाहिए. हालांकि, इसके लिए 1080p30fps पर छह इंस्टेंस के साथ काम करना ज़रूरी है.

नई ज़रूरी शर्तों की समयसीमा खत्म होना

• [5.1/H-1-5] CodecCapabilities.getMaxSupportedInstances() और VideoCapabilities.getSupportedPerformancePoints() तरीकों की मदद से, किसी भी कोडेक कॉम्बिनेशन में एक साथ चलाए जा सकने वाले, ज़्यादा से ज़्यादा हार्डवेयर वीडियो एन्कोडर और डिकोडर सेशन का विज्ञापन करना ज़रूरी है.

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

• [5.1/H-1-6] यह ज़रूरी है कि डिवाइस में 8-बिट (एसडीआर) हार्डवेयर वीडियो डिकोडर और हार्डवेयर वीडियो एन्कोडर सेशन (एवीसी, एचईवीसी, VP9, AV1 या इसके बाद के वर्शन) के छह इंस्टेंस काम करते हों. साथ ही, ये किसी भी कोडेक कॉम्बिनेशन में, 4K@30fps रिज़ॉल्यूशन पर तीन सेशन के साथ काम करते हों. इनमें से ज़्यादा से ज़्यादा दो सेशन एन्कोडर सेशन और तीन सेशन 1080p रिज़ॉल्यूशन पर काम करते हों. सभी सेशन के लिए, हर सेकंड में एक से ज़्यादा फ़्रेम नहीं छोड़े जाने चाहिए. AV1 कोडेक को सिर्फ़ 1080p रिज़ॉल्यूशन के साथ काम करना चाहिए. हालांकि, इसके लिए 1080p30fps पर छह इंस्टेंस के साथ काम करना ज़रूरी है.

नई ज़रूरी शर्तों की समयसीमा खत्म होना

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

• [5.1/H-1-19] यह ज़रूरी है कि यह डिवाइस, 4K@30fps रिज़ॉल्यूशन पर एक साथ चलने वाले किसी भी कोडेक कॉम्बिनेशन में, 10-बिट (एचडीआर) हार्डवेयर वीडियो डिकोडर और हार्डवेयर वीडियो एन्कोडर सेशन (AVC, HEVC, VP9, AV1 या उसके बाद के वर्शन) के तीन इंस्टेंस के साथ काम करे. इनमें से ज़्यादा से ज़्यादा एक एन्कोडर सेशन हो सकता है, जिसे GL सरफ़ेस की मदद से RGBA_1010102 इनपुट फ़ॉर्मैट में कॉन्फ़िगर किया जा सकता है. सभी सेशन के लिए, हर सेकंड में एक से ज़्यादा फ़्रेम नहीं छोड़े जाने चाहिए. GL प्लैटफ़ॉर्म से एन्कोड करने पर, एनकोडर के ज़रिए HDR मेटाडेटा जनरेट करने की ज़रूरत नहीं होती. AV1 कोडेक सेशन के लिए, सिर्फ़ 1080p रिज़ॉल्यूशन का इस्तेमाल करना ज़रूरी है. भले ही, 4K रिज़ॉल्यूशन की ज़रूरत हो.

नई ज़रूरी शर्तों की समयसीमा खत्म होना

• [5.1/H-1-7] लोड होने पर, सभी हार्डवेयर वीडियो एन्कोडर के लिए, 1080 पिक्सल या उससे कम वीडियो को एन्कोड करने वाले सेशन के लिए, कोडेक शुरू करने में लगने वाला समय 40 मिलीसेकंड या उससे कम होना चाहिए. यहां लोड को, 1080 पिक्सल से 720 पिक्सल वाले वीडियो को एक साथ ट्रांसकोड करने वाले सेशन के तौर पर परिभाषित किया गया है. इस सेशन में, हार्डवेयर वीडियो कोडेक का इस्तेमाल किया जाता है. साथ ही, 1080 पिक्सल वाली ऑडियो-वीडियो रिकॉर्डिंग को शुरू किया जाता है. Dolby vision कोडेक के लिए, कोडेक शुरू होने में लगने वाला समय 50 मिलीसेकंड या उससे कम होना चाहिए.
• [5.1/H-1-8] लोड होने पर, सभी ऑडियो एन्कोडर के लिए 128 केबीपीएस या उससे कम बिटरेट वाले ऑडियो एन्कोडिंग सेशन के लिए, कोडेक शुरू होने में लगने वाला समय 30 एमएस या उससे कम होना चाहिए. यहां लोड को, 1080 पिक्सल से 720 पिक्सल वाले वीडियो को एक साथ ट्रांसकोड करने वाले सेशन के तौर पर परिभाषित किया गया है. इस सेशन में, हार्डवेयर वीडियो कोडेक का इस्तेमाल किया जाता है. साथ ही, 1080 पिक्सल वाली ऑडियो-वीडियो रिकॉर्डिंग को शुरू किया जाता है.

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

• [5.1/H-1-9] यह ज़रूरी है कि डिवाइस में, सुरक्षित हार्डवेयर वीडियो डिकोडर सेशन (AVC, HEVC, VP9, AV1 या उसके बाद के वर्शन) के दो इंस्टेंस काम करते हों. साथ ही, ये इंस्टेंस किसी भी कोडेक कॉम्बिनेशन में, 1080 पिक्सल रिज़ॉल्यूशन पर 30 fps के साथ, 8-बिट (एसडीआर) और 10-बिट एचडीआर, दोनों तरह के कॉन्टेंट के लिए काम करते हों. सभी सेशन के लिए, हर सेकंड में एक से ज़्यादा फ़्रेम नहीं छोड़े जाने चाहिए.

नई ज़रूरी शर्तों की समयसीमा खत्म होना

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

• [5.1/H-1-10] यह ज़रूरी है कि यह डिवाइस, किसी भी कोडेक कॉम्बिनेशन में 4K रिज़ॉल्यूशन@30fps पर तीन सेशन के साथ-साथ, सुरक्षित हार्डवेयर वीडियो डिकोडर सेशन के एक इंस्टेंस के साथ-साथ, सुरक्षित हार्डवेयर वीडियो डिकोडर सेशन के एक इंस्टेंस (कुल चार इंस्टेंस) (AVC, HEVC, VP9, AV1 या इसके बाद के वर्शन) के साथ काम करे. इनमें से एक सेशन सुरक्षित डिकोडर सेशन और एक सेशन 1080p रिज़ॉल्यूशन@30fps पर नॉन-सिक्योर सेशन होना चाहिए. साथ ही, ज़्यादा से ज़्यादा दो सेशन 10-बिट एचडीआर में हो सकते हैं. सभी सेशन के लिए, हर सेकंड में एक से ज़्यादा फ़्रेम नहीं छोड़े जाने चाहिए. AV1 कोडेक सेशन में सिर्फ़ 1080p रिज़ॉल्यूशन का इस्तेमाल किया जा सकता है. भले ही, ज़रूरत पड़ने पर 4K रिज़ॉल्यूशन का इस्तेमाल किया जा सकता है.

नई ज़रूरी शर्तों की समयसीमा खत्म होना

• [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 पिक्सल वाले ऑडियो-वीडियो को प्लेबैक करने की प्रोसेस शुरू की जाती है.

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

• [5.1/H-1-14] यह ज़रूरी है कि डिवाइस में AV1 हार्डवेयर डिकोडर Main 10, लेवल 4.1 के साथ-साथ और फ़िल्म ग्रेन का इस्तेमाल किया जा सके. साथ ही, जीपीयू कॉम्पोज़िशन पर फ़िल्म ग्रेन इफ़ेक्ट का इस्तेमाल किया जा सके.

नई ज़रूरी शर्तों की समयसीमा खत्म होना

• [5.1/H-1-15] इसमें कम से कम एक हार्डवेयर वीडियो डिकोडर होना चाहिए, जो 4K60 को सपोर्ट करता हो.
• [5.1/H-1-16] इसमें कम से कम एक हार्डवेयर वीडियो एन्कोडर होना चाहिए, जो 4K60 को सपोर्ट करता हो.

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

• [5.1/H-1-21] सभी हार्डवेयर वीडियो डिकोडर (AVC, HEVC, VP9, AV1 या इसके बाद के वर्शन) के लिए, FEATURE_DynamicColorAspect के साथ काम करना ज़रूरी है. ध्यान दें: इसका मतलब है कि डिकोडिंग सेशन के दौरान, ऐप्लिकेशन वीडियो कॉन्टेंट के कलर से जुड़े पहलुओं को अपडेट कर सकते हैं. 10-बिट और 8-बिट कॉन्टेंट के साथ काम करने वाले डिकोडर, Surface मोड में 8-बिट और 10-बिट कॉन्टेंट के बीच डाइनैमिक तौर पर स्विच करने की सुविधा देते हैं. एचडीआर ट्रांसफ़र फ़ंक्शन के साथ काम करने वाले डिकोडर, एसडीआर और एचडीआर कॉन्टेंट के बीच डाइनैमिक तौर पर स्विच करने की सुविधा देते हैं.

नई ज़रूरी शर्तों की समयसीमा खत्म होना

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

• [5.1/H-1-22] यह ज़रूरी है कि यह एन्कोडिंग, डिकोडिंग, GPU-एडिटिंग, और वीडियो कॉन्टेंट को पोर्ट्रेट आसपेक्ट रेशियो में दिखाने की सुविधा देता हो. भले ही, कैमरे के सबसे बड़े रिज़ॉल्यूशन या 4K में से जो भी कम हो उसके लिए, रोटेशन मेटाडेटा कोई भी हो. ध्यान दें: अगर कोडेक में एचडीआर की सुविधा है, तो इसमें एचडीआर प्रोफ़ाइलें शामिल होती हैं. AV1 कोडेक के लिए, सिर्फ़ 1080 पिक्सल के रिज़ॉल्यूशन की ज़रूरत होती है. यह ज़रूरी शर्त सिर्फ़ हार्डवेयर कोडेक, जीपीयू, और डीपीयू के लिए है.

नई ज़रूरी शर्तों की समयसीमा खत्म होना

• [5.3/H-1-1] लोड के दौरान, 4K 60 fps वीडियो सेशन के लिए, 10 सेकंड में एक से ज़्यादा फ़्रेम नहीं छोड़े जाने चाहिए. इसका मतलब है कि फ़्रेम ड्रॉप 0.167 प्रतिशत से कम होना चाहिए.
• [5.3/H-1-2] 4K सेशन के लिए लोड के दौरान, 60 एफ़पीएस वाले वीडियो सेशन में वीडियो रिज़ॉल्यूशन बदलने के दौरान, 10 सेकंड में एक से ज़्यादा फ़्रेम नहीं छोड़े जाने चाहिए.
• [5.6/H-1-1] CTS पुष्टि करने वाले टैप-टू-टोन टेस्ट का इस्तेमाल करके, टैप-टू-टोन की देरी 80 मिलीसेकंड या उससे कम होनी चाहिए.
• [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 में से कोई एक स्वीकार करना चाहिए.

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

• [5.6/H-1-4] यह ज़रूरी है कि डिवाइस में चार चैनल वाले यूएसबी ऑडियो डिवाइसों के साथ काम करने की सुविधा हो. (डीजे कंट्रोलर इसका इस्तेमाल, गानों की झलक सुनने के लिए करते हैं.)

नई ज़रूरी शर्तों की समयसीमा खत्म होना

• [5.6/H-1-5] यह ज़रूरी है कि ऐप्लिकेशन, क्लास के मुताबिक काम करने वाले MIDI डिवाइसों के साथ काम करे और MIDI सुविधा के फ़्लैग का एलान करे.
• [5.6/H-1-9] यह कम से कम 12 चैनल मिक्सिंग के साथ काम करना चाहिए. इसका मतलब है कि 7.1.4 चैनल मास्क के साथ ऑडियो ट्रैक खोला जा सकता है और सभी चैनलों को सही तरीके से स्पेसलाइज़ या स्टीरियो में डाउनमिक्स किया जा सकता है.
• [5.6/H-SR] हमारा सुझाव है कि आप 24 चैनल मिक्सिंग की सुविधा का इस्तेमाल करें. इसके लिए, कम से कम 9.1.6 और 22.2 चैनल मास्क की सुविधा का इस्तेमाल करें.
• [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 (फ़्रेम प्रति सेकंड)

• [5.1/H-1-17] डिवाइस में कम से कम एक ऐसा हार्डवेयर इमेज डिकोडर होना चाहिए जो AVIF के आधारभूत प्रोफ़ाइल के साथ काम करता हो.
• [5.1/H-1-18] यह AV1 एन्कोडर के साथ काम करना चाहिए, जो 30fps और 1 एमबीपीएस पर 480 पिक्सल तक के रिज़ॉल्यूशन को एन्कोड कर सकता है.

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

• [5.1/H-1-20] डिवाइस में मौजूद सभी हार्डवेयर AV1 और एचईवीसी एन्कोडर के लिए, Feature_HdrEditing सुविधा काम करनी चाहिए. यह सुविधा, डिवाइस पर 4K रिज़ॉल्यूशन या कैमरे के साथ काम करने वाले सबसे बड़े रिज़ॉल्यूशन पर काम करनी चाहिए.

नई ज़रूरी शर्तों की समयसीमा खत्म होना

• [5.12/H-SR] डिवाइस पर मौजूद सभी हार्डवेयर AV1 और HEVC एन्कोडर के लिए, Feature_HdrEditing सुविधा के साथ काम करने का सुझाव दिया जाता है.
• [5.12/H-1-2] डिवाइस पर मौजूद सभी हार्डवेयर AV1 और HEVC एन्कोडर के लिए, RGBA_1010102 कलर फ़ॉर्मैट के साथ काम करना ज़रूरी है.
• [5.12/H-1-3] 8 और 10-बिट, दोनों YUV टेक्सचर से सैंपल लेने के लिए, EXT_YUV_target एक्सटेंशन के साथ काम करने की जानकारी देना ज़रूरी है.
• [7.1.4/H-1-1] डिसप्ले प्रोसेसिंग यूनिट (डीपीयू) में कम से कम छह हार्डवेयर ओवरले होने चाहिए. इनमें से कम से कम दो ओवरले, 10-बिट वीडियो कॉन्टेंट दिखाने में सक्षम होने चाहिए.

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

अगर हैंडहेल्ड डिवाइस पर android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS के लिए, android.os.Build.VERSION_CODES.V दिखता है और इसमें हार्डवेयर AVC या HEVC एन्कोडर के लिए सहायता शामिल है, तो:

नई ज़रूरी शर्तों की समयसीमा खत्म होना

• [5.2/H-2-1] यह ज़रूरी है कि हार्डवेयर AVC और HEVC कोडेक के लिए, वीडियो एन्कोडर रेट-डिस्टॉर्शन कर्व के हिसाब से तय की गई क्वालिटी के टारगेट को पूरा किया जाए. इस बारे में रन परफ़ॉर्मेंस क्लास 14 (PC14)-वीडियो एन्कोडिंग क्वालिटी (वीईक्यू) टेस्ट में बताया गया है.

2.2.7.2. कैमरा

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

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

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

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

नई ज़रूरी शर्तों की समयसीमा खत्म होना

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

• [7.5/H-1-1] डिवाइस में पीछे की तरफ़ एक मुख्य कैमरा होना चाहिए. इसका रिज़ॉल्यूशन कम से कम 12 मेगापिक्सल होना चाहिए. साथ ही, यह 4K@30fps, 1080p@60fps, और 720p@60fps में वीडियो कैप्चर करने की सुविधा देना चाहिए. पीछे वाला मुख्य कैमरा, सबसे कम कैमरा आईडी वाला पीछे वाला कैमरा होता है.

नई ज़रूरी शर्तों की समयसीमा खत्म होना

• [7.5/H-1-2] डिवाइस में, कम से कम 6 मेगापिक्सल का मुख्य फ़्रंट कैमरा होना चाहिए. साथ ही, यह 1080 पिक्सल@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] डिवाइस में पीछे की ओर वाला मुख्य कैमरा होना चाहिए, जो 240 FPS पर 720 पिक्सल या 1080 पिक्सल के साथ काम करता हो.
• [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 सुविधा काम करती होनी चाहिए.
• [7.5/H-1-15] मुख्य कैमरों के लिए, CameraX और Camera2 एक्सटेंशन, दोनों के ज़रिए, रात मोड एक्सटेंशन के साथ काम करना चाहिए.
• [7.5/H-1-16] प्राइमरी कैमरों के लिए, DYNAMIC_RANGE_TEN_BIT की सुविधा काम करती हो.
• [7.5/H-1-17] मुख्य कैमरों के लिए, CONTROL_SCENE_MODE_FACE_PRIORITY और चेहरे का पता लगाने की सुविधा (STATISTICS_FACE_DETECT_MODE_SIMPLE या STATISTICS_FACE_DETECT_MODE_FULL) का इस्तेमाल करना ज़रूरी है.

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

• [7.5/H-1-18] मुख्य रियर और मुख्य फ़्रंट कैमरे के लिए, JPEG_R के साथ काम करना ज़रूरी है.
• [7.5/H-1-19] यह ज़रूरी है कि डिवाइस में CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION1080 पिक्सल HLG10 के लिए, ज़्यादा से ज़्यादा 16:9 आसपेक्ट रेशियो वाले JPEG फ़ॉर्मैट में झलक दिखाने की सुविधा हो. साथ ही, यह भी ज़रूरी है कि डिवाइस में मुख्य रियर कैमरे के लिए, 720 पिक्सल HLG10 के लिए, ज़्यादा से ज़्यादा 16:9 आसपेक्ट रेशियो वाले JPEG फ़ॉर्मैट में झलक दिखाने की सुविधा हो.
• [7.5/H-1-20] डिफ़ॉल्ट रूप से, नेटिव कैमरा ऐप्लिकेशन में मुख्य पीछे और मुख्य सामने वाले कैमरों के लिए JPEG_R दिखाना ज़रूरी है.

नई ज़रूरी शर्तों की समयसीमा खत्म होना

2.2.7.3. हार्डवेयर

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

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

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

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

नई ज़रूरी शर्तों की समयसीमा खत्म होना

• [7.1.1.1/H-2-1] स्क्रीन का रिज़ॉल्यूशन कम से कम 1080p होना चाहिए.

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

• [7.1.1.3/H-2-1] अगर डिवाइस की स्क्रीन की चौड़ाई 600 dp से कम है, तो स्क्रीन की डेंसिटी कम से कम 400 डीपीआई होनी चाहिए.

नई ज़रूरी शर्तों की समयसीमा खत्म होना

• [7.1.1.3/H-3-1] डिवाइस में एचडीआर डिसप्ले होना चाहिए, जो कम से कम 1,000 निट के औसत पर काम करता हो.

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

• [7.6.1/H-2-1] डिवाइस में कम से कम 8 जीबी फ़िज़िकल मेमोरी होनी चाहिए. साथ ही, android.app.ActivityManager.MemoryInfo.totalMem के मुताबिक, कम से कम 6.64 जीबी मेमोरी, कर्नेल के लिए उपलब्ध होनी चाहिए.

नई ज़रूरी शर्तों की समयसीमा खत्म होना

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

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

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

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

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

नई ज़रूरी शर्तों की समयसीमा खत्म होना

• [8.2/H-1-1] यह पक्का करना ज़रूरी है कि सीक्वेंशियल राइटिंग की परफ़ॉर्मेंस कम से कम 150 एमबी/सेकंड हो.
• [8.2/H-1-2] यह पक्का करना ज़रूरी है कि रैंडम राइटिंग की परफ़ॉर्मेंस कम से कम 10 एमबी/सेकंड हो.
• [8.2/H-1-3] यह पक्का करना ज़रूरी है कि सीक्वेंशियल रीड परफ़ॉर्मेंस कम से कम 250 MB/s हो.
• [8.2/H-1-4] यह पक्का करना ज़रूरी है कि रैंडम रीड परफ़ॉर्मेंस कम से कम 100 एमबी/सेकंड हो.
• [8.2/H-1-5] यह ज़रूरी है कि एक साथ कई फ़ाइलों को पढ़ने और लिखने की परफ़ॉर्मेंस बेहतर हो. साथ ही, पढ़ने की परफ़ॉर्मेंस, लिखने की परफ़ॉर्मेंस से दो गुनी हो और कम से कम 50 एमबी/सेकंड हो.

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

2.2.7.5. ग्राफ़िक्स

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

• [7.1.4.1/H-1-2] यह ज़रूरी है कि यह EGL_IMG_context_priority और EGL_EXT_protected_content एक्सटेंशन के साथ काम करे.
• [7.1.4.1/H-1-3] इसमें VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory और VK_KHR_global_priority का इस्तेमाल करना ज़रूरी है.

नई ज़रूरी शर्तों की समयसीमा खत्म होना

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] अगर इनमें से किसी भी डेंसिटी का इस्तेमाल किया जाता है, तो kernel और userspace के लिए उपलब्ध मेमोरी कम से कम 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/T-0-3] AV1

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

• [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
• [5.3.2/T-0-7] AV1

टेलिविज़न डिवाइस में, 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] एचडी 1080 पिक्सल, 60 फ़्रेम प्रति सेकंड पर, मुख्य प्रोफ़ाइल लेवल 4.1 के साथ

अगर 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] HDMI आउटपुट मोड को, चुने गए पिक्सल फ़ॉर्मैट के लिए सबसे ज़्यादा रिज़ॉल्यूशन पर सेट करना ज़रूरी है. यह फ़ॉर्मैट, बाहरी डिसप्ले के लिए 50Hz या 60Hz रिफ़्रेश रेट के साथ काम करता है. यह रिफ़्रेश रेट, डिवाइस को बेचे जाने वाले इलाके के हिसाब से तय होता है.
• [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] ऐप्लिकेशन में, मीडिया सूचना टेंप्लेट के साथ-साथ लॉक स्क्रीन पर सूचनाएं दिखनी चाहिए.

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

• [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] तीसरे पक्ष के टीटीएस इंजन को इंस्टॉल करने की सुविधा होनी चाहिए.

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

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

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

नई ज़रूरी शर्तों की समयसीमा खत्म होना

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

Android Television Input Framework (TIF), Android Television डिवाइसों पर लाइव कॉन्टेंट को डिलीवर करना आसान बनाता है. TIF, Android Television डिवाइसों को कंट्रोल करने वाले इनपुट मॉड्यूल बनाने के लिए, एक स्टैंडर्ड एपीआई उपलब्ध कराता है.

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

• [3/T-0-2] प्लैटफ़ॉर्म की सुविधा के बारे में ज़रूर बताएं android.software.live_tv.
• [3/T-0-3] यह ज़रूरी है कि यह सभी TIF API के साथ काम करे, ताकि इन एपीआई और तीसरे पक्ष के TIF-आधारित इनपुट की सेवा का इस्तेमाल करने वाले ऐप्लिकेशन को डिवाइस पर इंस्टॉल और इस्तेमाल किया जा सके.

Android Television ट्यूनर फ़्रेमवर्क (TF), Android Television डिवाइसों पर ट्यूनर से लाइव कॉन्टेंट को मैनेज करने के साथ-साथ, आईपी से स्ट्रीम किए जा रहे कॉन्टेंट को भी मैनेज करता है. ट्यूनर फ़्रेमवर्क, Android Television ट्यूनर का इस्तेमाल करने वाली इनपुट सेवाएं बनाने के लिए, एक स्टैंडर्ड एपीआई उपलब्ध कराता है.

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

• [3/T-1-1] यह ज़रूरी है कि यह Tuner Framework के सभी एपीआई के साथ काम करे, ताकि इन एपीआई का इस्तेमाल करने वाले ऐप्लिकेशन को डिवाइस पर इंस्टॉल और इस्तेमाल किया जा सके.

नई ज़रूरी शर्तों की समयसीमा खत्म होना

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

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

• [9.11/T-0-4] यह ज़रूरी है कि कुंजी की पुष्टि करने की सुविधा काम करे. इसमें, पुष्टि करने के लिए इस्तेमाल होने वाली साइनिंग कुंजी को सुरक्षित हार्डवेयर से सुरक्षित किया गया हो और साइनिंग की प्रोसेस को सुरक्षित हार्डवेयर में किया गया हो. पुष्टि करने के लिए इस्तेमाल होने वाली साइनिंग कुंजियों को ज़रूर ज़्यादा से ज़्यादा डिवाइसों के साथ शेयर किया जाना चाहिए, ताकि डिवाइस के पहचानकर्ता के तौर पर हमेशा इस्तेमाल किए जाने से रोका जा सके. इस शर्त को पूरा करने का एक तरीका यह है कि जब तक किसी SKU की कम से कम 1,00,000 यूनिट का प्रॉडक्शन न हो जाए, तब तक एक ही पुष्टि करने वाली कुंजी शेयर की जाए. अगर किसी SKU की 1,00,000 से ज़्यादा यूनिट बनाई जाती हैं, तो हर 1,00,000 यूनिट के लिए अलग-अलग बटन का इस्तेमाल किया जा सकता है.

  ध्यान दें: इस शर्त को पूरा करने के लिए, आपको किसी SKU के लिए एक ही पुष्टि करने वाली कुंजी तब तक शेयर करनी होगी, जब तक उस SKU की कम से कम 1,00,000 यूनिट का प्रॉडक्शन न हो जाए. अगर उस SKU की 1,00,000 से ज़्यादा यूनिट बनाई जाती हैं, तो इसके बाद 1,00,000 यूनिट के हर ग्रुप के लिए, अलग-अलग कुंजी का इस्तेमाल किया जा सकता है. इसके अलावा, डिवाइस पर कुछ समय के लिए मान्य पुष्टि करने वाली कुंजियों को उपलब्ध कराने के लिए, रिमोट पासकोड प्रोविज़निंग सलूशन का इस्तेमाल किया जा सकता है.

नई ज़रूरी शर्तों की समयसीमा खत्म होना

ध्यान दें कि अगर किसी डिवाइस पर, 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. डेवलपर टूल और विकल्पों के साथ काम करने की सुविधा

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

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

• 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' बाइनरी के ज़रिए उपलब्ध कराए हों.
  • [6.1/T-0-5] persist.traced.enable सिस्टम प्रॉपर्टी के तौर पर, डिफ़ॉल्ट रूप से, 'perfetto traced daemon' चालू होना चाहिए.

नई ज़रूरी शर्तों की समयसीमा खत्म होना

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 के कंट्रोल के साथ काम करना चाहिए, ताकि अन्य उपयोगकर्ताओं को वॉइस कॉल और एसएमएस ऐक्सेस करने की अनुमति दी या बंद की जा सके.

अगर डिवाइस में सुरक्षित लॉक स्क्रीन है और एक या उससे ज़्यादा भरोसेमंद एजेंट हैं, जो TrustAgentService सिस्टम एपीआई को लागू करते हैं, तो:

• [9.11.1/W-1-1] यह ज़रूरी है कि उपयोगकर्ता को हर 72 घंटे से ज़्यादा बार, पुष्टि करने के सुझाए गए मुख्य तरीकों (जैसे, पिन, पैटर्न, पासवर्ड) में से किसी एक का इस्तेमाल करने के लिए कहा जाए.

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 होना चाहिए.

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

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

• [7.1.1.1/A-1-1] मुख्य डिसप्ले के लिए, हर ऑक्युपेंट ज़ोन के लिए, कम से कम 6 इंच डायगनल साइज़ की अलग स्क्रीन होनी चाहिए. इसे हर ऑक्युपेंट ज़ोन के लिए, CarOccupantZoneManager.DISPLAY_TYPE_MAIN के तौर पर टैग किया जाना चाहिए.
• [7.1.1.1/A-1-2] हर मुख्य डिसप्ले के लिए, स्क्रीन साइज़ का लेआउट कम से कम 750 dp x 480 dp होना चाहिए.

नई ज़रूरी शर्तों की समयसीमा खत्म होना

अगर वाहन से जुड़े डिवाइसों में 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 लोडर को शामिल करना ज़रूरी है और सभी सिंबल एक्सपोर्ट करने होंगे.

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

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

• [7.1.7/A-0-1] ड्राइवर की नज़र के दायरे में, सेकंडरी डिसप्ले को FLAG_PRIVATE के तौर पर कॉन्फ़िगर करना ज़रूरी है.

नई ज़रूरी शर्तों की समयसीमा खत्म होना

• [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.

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

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

• [7.3/A-1-1] NIGHT_MODE फ़्लैग की वैल्यू को, सभी डिसप्ले पर डैशबोर्ड के डे/नाइट मोड के हिसाब से एक जैसा सेट करना ज़रूरी है. इनमें पीछे की सीट के डिसप्ले भी शामिल हैं.

नई ज़रूरी शर्तों की समयसीमा खत्म होना

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

• [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) की मदद से मीडिया चलाना.
  • रिमोट कंट्रोल प्रोफ़ाइल (एवीआरसीपी) की मदद से, मीडिया प्लेबैक को कंट्रोल करना.
  • फ़ोन बुक ऐक्सेस करने वाली प्रोफ़ाइल (पीबीएपी) का इस्तेमाल करके संपर्क शेयर करना.

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

• [7.4.3/A-SR-1] हमारा सुझाव है कि अगर डिवाइस में ड्राइवर के लिए ऑक्युपेंट ज़ोन है, तो Message Access Profile (MAP) का इस्तेमाल करें.

नई ज़रूरी शर्तों की समयसीमा खत्म होना

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

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

• [7.4.3/A-1-1] यह ज़रूरी है कि यह ऐप्लिकेशन, अन्य उपयोगकर्ताओं के बीटी अनुभव में कोई रुकावट न डाले.

नई ज़रूरी शर्तों की समयसीमा खत्म होना

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

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

अगर डिवाइस में AM/FM ब्रॉडकास्ट रेडियो की सुविधा शामिल है और किसी ऐप्लिकेशन को यह सुविधा दी गई है, तो:

• [7.4/A-1-1] FEATURE_BROADCAST_RADIO के लिए सहायता देने का एलान करना ज़रूरी है.

पीछे वाला कैमरा, वाहन के बाहर की तरफ़ होता है. इसे वाहन के किसी भी हिस्से में लगाया जा सकता है. यह वाहन के केबिन के बाहर की तरफ़ होता है. इसका मतलब है कि यह पीछे की तरफ़ दिखने वाले दृश्यों को रिकॉर्ड करता है, जैसे कि रियर-व्यू कैमरा.

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

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

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

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

• [7.5/A-1-1] कैमरे को इस तरह से ओरिएंट करना ज़रूरी है कि कैमरे का लंबा डाइमेंशन, Android वाहन सेंसर के अक्षों के X-Y प्लेन के साथ अलाइन हो.
• [7.5/A-SR-3] हमारा सुझाव है कि आपके पास फ़िक्स्ड-फ़ोकस या EDOF (एक्सटेंडेड डेप्थ ऑफ़ फ़ील्ड) हार्डवेयर हो.
• [7.5/A-1-2] मुख्य व्यू के तौर पर इस्तेमाल होने वाले कैमरे का आईडी, सबसे कम होना चाहिए.

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

• [7.5/A-2-1] उपयोगकर्ता के सामने वाला मुख्य कैमरा, सबसे कम कैमरा आईडी वाला कैमरा होना चाहिए.
• कैमरे को इस तरह से ऑर्डर किया जा सकता है कि उसका लंबा डाइमेंशन, Android Automotive सेंसर ऐक्सिस के X-Y प्लैन के साथ अलाइन हो जाए.

अगर वाहन से जुड़े डिवाइस में ऐसा कैमरा शामिल है जिसे android.hardware.Camera या android.hardware.camera2 एपीआई के ज़रिए ऐक्सेस किया जा सकता है, तो:

• [7.5/A-3-1] यह ज़रूरी है कि ऐप्लिकेशन, सेक्शन 7.5 में बताई गई कैमरे से जुड़ी बुनियादी ज़रूरी शर्तों को पूरा करता हो.

अगर वाहन से जुड़े डिवाइस में ऐसा कैमरा शामिल है जिसे android.hardware.Camera या android.hardware.camera2 एपीआई के ज़रिए ऐक्सेस नहीं किया जा सकता, तो:

• [7.5/A-4-1] इसे एक्सटेंडेड व्यू सिस्टम सेवा के ज़रिए ऐक्सेस किया जा सकता है.

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

• [7.5/A-5-1] कैमरे की झलक को घुमाया या हॉरिज़ॉन्टल तौर पर मिरर नहीं किया जाना चाहिए.
• [7.5/A-SR-4] हमारा सुझाव है कि इमेज का रिज़ॉल्यूशन कम से कम 1.3 मेगापिक्सल हो.

अगर वाहन में एक या उससे ज़्यादा कैमरे इस्तेमाल किए जा रहे हैं, जिन्हें एक्सटेंडेड व्यू सिस्टम सेवा और android.hardware.Camera या android.hardware.Camera2 एपीआई, दोनों के ज़रिए ऐक्सेस किया जा सकता है, तो ऐसे कैमरे के लिए:

• [7.5/A-6-1] एक ही कैमरा आईडी की जानकारी देनी होगी.

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

• [7.5/A-7-1] android.hardware.camera2 एपीआई या एक्सटेंडेड व्यू सिस्टम एपीआई का इस्तेमाल करके, ऐसा कैमरा एपीआई लागू करना ज़रूरी है.

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

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

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

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

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

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

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

• [7.6.1/A-1-1] एक ही AAOS इंस्टेंस पर, ऐप्लिकेशन के निजी डेटा (/data पार्टीशन) के लिए, एक साथ इस्तेमाल करने वाले हर Android उपयोगकर्ता के लिए, कम से कम 4 जीबी स्टोरेज होना चाहिए. यह स्टोरेज, नॉन-वॉल्व्यूलेट स्टोरेज होना चाहिए.

नई ज़रूरी शर्तों की समयसीमा खत्म होना

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

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

• [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] अगर इनमें से किसी भी डेंसिटी का इस्तेमाल किया जाता है, तो कर्नेल और यूज़रस्पेस के लिए उपलब्ध मेमोरी, प्राइमरी डिसप्ले के हिसाब से कम से कम 1824 एमबी होनी चाहिए:

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

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

नई ज़रूरी शर्तों की समयसीमा खत्म होना

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

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

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

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

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

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

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

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

• [7.8.2/A-1-1] एक साथ कई उपयोगकर्ताओं के सिस्टम के लिए, हर मुख्य डिसप्ले के लिए ऑडियो आउटपुट डिवाइस होना चाहिए.
• [7.8.2/A-1-2] इसमें ड्राइवर के लिए ऑडियो ज़ोन होना चाहिए, जिसमें कैबिन के सभी स्पीकर शामिल हों. सामने की सीट पर बैठे यात्री के लिए, ड्राइवर के ऑडियो ज़ोन का इस्तेमाल किया जा सकता है. इसके अलावा, उसके लिए अलग से ऑडियो आउटपुट भी सेट किया जा सकता है.

नई ज़रूरी शर्तों की समयसीमा खत्म होना

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

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

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

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

नई ज़रूरी शर्तों की समयसीमा खत्म होना

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 एपीआई को पूरी तरह से लागू करना ज़रूरी है.

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

• [3.8/A-0-1] फ़ोरग्राउंड में मौजूद मौजूदा उपयोगकर्ता के अलावा, दूसरे सभी उपयोगकर्ताओं को गतिविधियां लॉन्च करने और किसी भी डिसप्ले पर यूज़र इंटरफ़ेस (यूआई) को ऐक्सेस करने की अनुमति नहीं होनी चाहिए.

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

• [3.8/A-1-1] ऐसे सभी सेकंडरी उपयोगकर्ताओं के लिए, UserRestrictions की पहले से तय की गई सूची को लागू करना ज़रूरी है जो फ़ोरग्राउंड में मौजूद मौजूदा उपयोगकर्ता नहीं हैं. हालांकि, उनके पास डिसप्ले के लिए असाइन किए गए यूज़र इंटरफ़ेस (यूआई) का ऐक्सेस है. UserRestrictions की सूची में ये शामिल हैं DISALLOW_CONFIG_LOCALE, DISALLOW_CONFIG_BLUETOOTH, DISALLOW_BLUETOOTH, DISALLOW_CAMERA_TOGGLE, और DISALLOW_MICROPHONE_TOGGLE.

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

नई ज़रूरी शर्तों की समयसीमा खत्म होना

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

• [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 APIandroid.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.microphone का एलान किया जाता है, तो:

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

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

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

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

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

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

• [9.11/A-0-4] यह ज़रूरी है कि कुंजी की पुष्टि करने की सुविधा काम करे. इसमें, पुष्टि करने के लिए इस्तेमाल होने वाली साइनिंग कुंजी को सुरक्षित हार्डवेयर से सुरक्षित किया गया हो और साइनिंग की प्रोसेस को सुरक्षित हार्डवेयर में किया गया हो. पुष्टि करने के लिए इस्तेमाल होने वाली साइनिंग कुंजियों को ज़रूर ज़्यादा से ज़्यादा डिवाइसों के साथ शेयर किया जाना चाहिए, ताकि डिवाइस के पहचानकर्ता के तौर पर हमेशा इस्तेमाल किए जाने से रोका जा सके. इस शर्त को पूरा करने का एक तरीका यह है कि जब तक किसी SKU की कम से कम 1,00,000 यूनिट का प्रॉडक्शन न हो जाए, तब तक एक ही पुष्टि करने वाली कुंजी शेयर की जाए. अगर किसी SKU की 1,00,000 से ज़्यादा यूनिट बनाई जाती हैं, तो हर 1,00,000 यूनिट के लिए अलग-अलग बटन का इस्तेमाल किया जा सकता है.

  ध्यान दें: इस शर्त को पूरा करने के लिए, आपको किसी SKU के लिए एक ही पुष्टि करने वाली कुंजी तब तक शेयर करनी होगी, जब तक उस SKU की कम से कम 1,00,000 यूनिट का प्रॉडक्शन न हो जाए. अगर उस SKU की 1,00,000 से ज़्यादा यूनिट बनाई जाती हैं, तो इसके बाद 1,00,000 यूनिट के हर ग्रुप के लिए, अलग-अलग कुंजी का इस्तेमाल किया जा सकता है. इसके अलावा, डिवाइस पर कुछ समय के लिए मान्य पुष्टि करने वाली कुंजियों को उपलब्ध कराने के लिए, रिमोट पासकोड प्रोविज़निंग सलूशन का इस्तेमाल किया जा सकता है.

नई ज़रूरी शर्तों की समयसीमा खत्म होना

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

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

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

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

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

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

• 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 बाइनरी के ज़रिए उपलब्ध कराने होंगे.
  • [6.1/A-0-5] Perfetto ट्रैस किए गए डेमन को डिफ़ॉल्ट रूप से चालू होना चाहिए (सिस्टम प्रॉपर्टी persist.traced.enable).

नई ज़रूरी शर्तों की समयसीमा खत्म होना

2.6. टैबलेट से जुड़ी ज़रूरी शर्तें

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

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

• इसमें बैटरी जैसा कोई पावर सोर्स हो, जिससे इसे कहीं भी ले जाया जा सके.

• स्क्रीन का डाइमेंशन 7" से ज़्यादा और 18" से कम होना चाहिए.

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

2.6.1. हार्डवेयर

जाइरोस्कोप

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

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

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

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

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

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

  हालांकि, ये:

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

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

• [C-0-8] यह ज़रूरी है कि ऐप्लिकेशन, 23 24 से कम एपीआई लेवल को टारगेट करने वाले ऐप्लिकेशन इंस्टॉल करने की सुविधा न दे.

नई ज़रूरी शर्तों की समयसीमा खत्म होना

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 15 के लिए अनुमति वाली वर्शन स्ट्रिंग में बताई गई स्ट्रिंग वैल्यू में से कोई एक वैल्यू होनी चाहिए.
VERSION.SDK	फ़िलहाल चल रहे Android सिस्टम का वर्शन, तीसरे पक्ष के ऐप्लिकेशन कोड के ऐक्सेस किए जा सकने वाले फ़ॉर्मैट में. Android 15 के लिए, इस फ़ील्ड में पूर्णांक की वैल्यू 15_INT होनी चाहिए.
VERSION.SDK_INT	फ़िलहाल चल रहे Android सिस्टम का वर्शन, तीसरे पक्ष के ऐप्लिकेशन कोड के ऐक्सेस किए जा सकने वाले फ़ॉर्मैट में. Android 15 के लिए, इस फ़ील्ड में पूर्णांक की वैल्यू 15_INT होनी चाहिए.
VERSION.INCREMENTAL	डिवाइस इंप्लीमेंटर की चुनी गई वैल्यू, जो फ़िलहाल चल रहे Android सिस्टम के खास बिल्ड को, इंसान के पढ़ने लायक फ़ॉर्मैट में दिखाती है. इस वैल्यू का इस्तेमाल, असली उपयोगकर्ताओं के लिए उपलब्ध कराए गए अलग-अलग बिल्ड के लिए दोबारा नहीं किया जाना चाहिए. इस फ़ील्ड का आम तौर पर इस्तेमाल, यह बताने के लिए किया जाता है कि बिल्ड जनरेट करने के लिए, किस बिल्ड नंबर या सोर्स-कंट्रोल बदलाव आइडेंटिफ़ायर का इस्तेमाल किया गया था. इस फ़ील्ड की वैल्यू, प्रिंट किए जा सकने वाले सात बिट वाले ASCII के तौर पर कोड की जानी चाहिए. साथ ही, यह वैल्यू रेगुलर एक्सप्रेशन ^[^ :\/~]+$ से मैच करनी चाहिए.
बोर्ड	डिवाइस लागू करने वाले व्यक्ति की चुनी गई वैल्यू, जिसमें डिवाइस के इस्तेमाल किए गए खास इंटरनल हार्डवेयर की पहचान होती है. यह वैल्यू, इंसान के पढ़ने लायक फ़ॉर्मैट में होती है. इस फ़ील्ड का इस्तेमाल, डिवाइस को पावर देने वाले बोर्ड के खास वर्शन की जानकारी देने के लिए किया जा सकता है. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है और यह रेगुलर एक्सप्रेशन ^[a-zA-Z0-9_-]+$ से मैच करनी चाहिए.
ब्रैंड	यह वैल्यू, डिवाइस से जुड़े ब्रैंड के नाम को दिखाती है. यह नाम, असली उपयोगकर्ताओं को पता होता है. यह एट्रिब्यूट, लोगों के पढ़ने लायक फ़ॉर्मैट में होना चाहिए. साथ ही, इसमें डिवाइस के मैन्युफ़ैक्चरर या उस कंपनी के ब्रैंड का नाम होना चाहिए जिसका नाम डिवाइस के लिए मार्केटिंग में इस्तेमाल किया जाता है. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है और यह रेगुलर एक्सप्रेशन ^[a-zA-Z0-9_-]+$ से मैच करनी चाहिए.
इस्तेमाल किए जा सकने वाले_एबीआई	नेटिव कोड के निर्देश सेट (सीपीयू टाइप + एबीआई कॉन्वेंशन) का नाम. सेक्शन 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:15/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 ._/+-]+)$ से मैच करनी चाहिए. यह वैल्यू, व्हाइटस्पेस से शुरू या आखिर में नहीं होनी चाहिए. साथ ही, यह "जानकारी नहीं है" से मेल नहीं खानी चाहिए. प्रॉडक्ट के लाइफ़टाइम के दौरान, इस फ़ील्ड में बदलाव नहीं किया जाना चाहिए.
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()	यह हार्डवेयर का सीरियल नंबर होना चाहिए. यह एक ही मॉडल और मैन्युफ़ैक्चरर के सभी डिवाइसों के लिए उपलब्ध और यूनीक होना चाहिए. इस फ़ील्ड की वैल्यू को 7-बिट 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 का पालन करना ज़रूरी है.

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

• [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.blue.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] यह ज़रूरी है कि इंस्टॉल की गई सभी ऑटोमैटिक भरने की सेवाओं के लिए, ऐसे लिंक दिखाए जाएं.

अगर डिवाइस पर 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 इंटेंट के जवाब में, स्क्रीन सेवर को कॉन्फ़िगर करने के लिए सेटिंग का विकल्प भी देना चाहिए.

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

• [C-19-1] NfcAdapter.ACTION_TRANSACTION_DETECTED Intent API को लागू करना ज़रूरी है. इसे GSM Association के तकनीकी स्पेसिफ़िकेशन TS.26 - NFC हैंडसेट की ज़रूरी शर्तों में "EVT_TRANSACTION" के तौर पर बताया गया है.

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

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

• [C-0-6] ऊपर दिए गए पैरामीटर की मदद से, एबीआई की इस सूची के सबसेट की रिपोर्ट देना ज़रूरी है. साथ ही, सूची में शामिल नहीं किए गए किसी भी एबीआई की रिपोर्ट नहीं देनी चाहिए.
  • armeabi (NDK अब इसे टारगेट के तौर पर इस्तेमाल नहीं करता)
  • armeabi-v7a
  • arm64-v8a
  • x86
  • x86-64
  • riscv64

नई ज़रूरी शर्तों की समयसीमा खत्म होना

• [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.1 फ़ंक्शन सिंबल के लिए फ़ंक्शन सिंबल एक्सपोर्ट करना ज़रूरी है. साथ ही, 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 15 ब्रैंच पर अपस्ट्रीम 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 dpi (mdpi)
	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 dpi (mdpi)
	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 dpi (mdpi)
	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 dpi (mdpi)
	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 फ़्लैग में से कोई एक सेट किया है, तो उसे उपयोगकर्ता को यह बताना चाहिए कि 'परेशान न करें' सेटिंग मेन्यू में विज़ुअल इफ़ेक्ट बंद हैं.

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

3.8.3.4. संवेदनशील सूचना की सुरक्षा

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

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

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

  • सिस्टम से साइन किए गए ऐसे ऐप्लिकेशन जिनका uid 10,000 से कम है
  • सिस्टम यूज़र इंटरफ़ेस (यूआई)
  • शेल
  • कंपैनियन डिवाइस के लिए तय किया गया ऐप्लिकेशन (CompanionDeviceManager से तय किया गया)
  • SYSTEM_AUTOMOTIVE_PROJECTION की भूमिका
  • SYSTEM_NOTIFICATION_INTELLIGENCE की भूमिका
  • होम की भूमिका

NotificationAssistantServices को AOSP में लागू करने से, इन ज़रूरी शर्तों के बारे में पता चलता है और ये शर्तें पूरी की जाती हैं. उदाहरण के लिए, android.ext.services.notification देखें.

नई ज़रूरी शर्तों की समयसीमा खत्म होना

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, औरMONOCHROMATIC.

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

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

• [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 डीपी की चौड़ाई और 135 डीपी की ऊंचाई तय करना ज़रूरी है.

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

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

• [C-4-1] यह मल्टी-विंडो मोड के साथ काम करना चाहिए.

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

• [C-5-1] WindowManager एक्सटेंशन में बताए गए तरीके के मुताबिक, Window Manager एक्सटेंशन एपीआई लेवल का सही वर्शन लागू करना ज़रूरी है.

नई ज़रूरी शर्तों की समयसीमा खत्म होना

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 15 के लिए नई ज़रूरी शर्तें लागू होना

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] अब किसी भी डीपीसी ऐप्लिकेशन को डिवाइस के मालिक के ऐप्लिकेशन के तौर पर रजिस्टर नहीं करना चाहिए.

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

• [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] एपीआई लागू करने ज़रूरी हैं, ताकि डिवाइस नीति नियंत्रक (डीपीसी) ऐप्लिकेशन, मैनेज की जा रही नई प्रोफ़ाइल का मालिक बन सके.

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

• [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 इंटेंट से ट्रिगर होती है, तो ऐसा करना ज़रूरी नहीं है. जब तक प्रोफ़ाइल के मालिक का ऐप्लिकेशन इंस्टॉल नहीं हो जाता, तब तक उपयोगकर्ता को सेटअप विज़र्ड में आगे बढ़ने की अनुमति नहीं मिलनी चाहिए.

• [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 देखें). भले ही, मैनेज की जा रही प्रोफ़ाइल को मुख्य उपयोगकर्ता के अलावा किसी दूसरे उपयोगकर्ता के तौर पर नहीं गिना जाता.
• [C-1-10] यह पक्का करना ज़रूरी है कि स्क्रीनशॉट का डेटा, वर्क प्रोफ़ाइल के स्टोरेज में सेव हो. ऐसा तब होगा, जब स्क्रीनशॉट किसी ऐसी topActivity विंडो से लिया गया हो जिस पर फ़ोकस हो (जिस पर उपयोगकर्ता ने सभी गतिविधियों में से आखिरी बार इंटरैक्ट किया हो) और वह वर्क प्रोफ़ाइल ऐप्लिकेशन से जुड़ी हो.
• [C-1-11] वर्क प्रोफ़ाइल में स्क्रीनशॉट सेव करते समय, वर्क प्रोफ़ाइल ऐप्लिकेशन की विंडो/विंडो के अलावा, स्क्रीन का कोई अन्य कॉन्टेंट (सिस्टम बार, सूचनाएं या निजी प्रोफ़ाइल का कोई कॉन्टेंट) कैप्चर नहीं किया जाना चाहिए. इससे यह पक्का किया जा सकेगा कि निजी प्रोफ़ाइल का डेटा, वर्क प्रोफ़ाइल में सेव न हो.

अगर डिवाइस पर 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.9.5. डिवाइस नीति से जुड़ी समस्या हल करने का फ़्रेमवर्क

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

• [C-1-1] डिवाइस नीति से जुड़ी समस्याओं को हल करने के फ़्रेमवर्क में बताए गए तरीके के मुताबिक, डिवाइस नीति से जुड़ी समस्याओं को हल करना ज़रूरी है.

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 इंजन इंस्टॉल किए जा सकते हैं, तो:

• [C-2-1] सिस्टम लेवल पर इस्तेमाल करने के लिए, उपयोगकर्ता को TTS इंजन चुनने की अनुमति देने के लिए, उपयोगकर्ता के लिए सुविधाएं उपलब्ध कराएं.

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

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 पैकेज में मौजूद एपीआई पूरी तरह से लागू हों.

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

• [C-1-3] उपयोगकर्ता को यह चुनने/पुष्टि करने के लिए, उपयोगकर्ता के लिए ज़रूरी सुविधाएं उपलब्ध कराएं कि साथी डिवाइस मौजूद है और काम कर रहा है. इसके लिए, AOSP में लागू किए गए मैसेज का ही इस्तेमाल किया जाना चाहिए. इसमें कोई बदलाव नहीं किया जाना चाहिए.

नई ज़रूरी शर्तों की समयसीमा खत्म होना

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 पैरामीटर को 'गलत' पर सेट किया गया हो या उसकी जानकारी न दी गई हो.

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

3.19. भाषा की सेटिंग

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

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

नई ज़रूरी शर्तों की समयसीमा खत्म होना

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 फ़ाइलों की पुष्टि करने की सुविधा होनी चाहिए.

ध्यान दें: Android 10 या उससे पहले के वर्शन पर शिप किए गए डिवाइसों के लिए, सिस्टम सॉफ़्टवेयर के अपडेट की मदद से [C-0-8] और [C-0-9] की ज़रूरी शर्तें पूरी नहीं की जा सकतीं. ऐसे डिवाइसों को इन ज़रूरी शर्तों से छूट मिल सकती है.

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 एपीआई में डिफ़ॉल्ट 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 प्रोफ़ाइल (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
• [C-0-4] AVIF
  • डिवाइसों पर BITRATE_MODE_CQ और बेसलाइन प्रोफ़ाइल काम करनी चाहिए.

अगर डिवाइस पर, मीडिया टाइप MIMETYPE_IMAGE_ANDROID_HEIC के लिए android.media.MediaCodec के ज़रिए HEIC एन्कोडिंग की सुविधा काम करती है, तो:

• [C-1-1] हार्डवेयर की मदद से तेज़ी से काम करने वाला HEVC एन्कोडर कोडेक उपलब्ध कराना ज़रूरी है. यह कोडेक, बिटरेट कंट्रोल मोड, BITRATE_MODE_CQ प्रोफ़ाइल, और 512 x 512 पिक्सल के फ़्रेम साइज़ के साथ काम करना चाहिए.HEVCProfileMainStill

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] रॉ
• [C-0-7] AVIF (बेसलाइन प्रोफ़ाइल)

अगर डिवाइस पर 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)
AVIF (बेसलाइन प्रोफ़ाइल)	इमेज, इमेज कलेक्शन, इमेज सीक्वेंस की बेसलाइन प्रोफ़ाइल	HEIF कंटेनर (.avif)

MediaCodec API के ज़रिए एक्सपोज़ की गई इमेज एन्कोडर और डीकोडर

• [C-1-1] CodecCapabilities की मदद से, YUV420 8:8:8 फ़्लेक्सिबल कलर फ़ॉर्मैट (COLOR_FormatYUV420Flexible) के साथ काम करना चाहिए.

• [C-SR-1] इनपुट के लिए, सतह के मोड में 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)
AV1	ज़्यादा जानकारी के लिए, सेक्शन 5.2 और सेक्शन 5.3 देखें	MPEG-4 (.mp4) 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 पिक्सल (अन्य, AV1)	1408 x 1152 पिक्सल (H263) 1280 x 720 पिक्सल (अन्य, AV1)	1920 x 1080 पिक्सल (MPEG4, AV1 के अलावा)	3840 x 2160 पिक्सल (एचईवीसी, VP9, AV1)

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

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

अगर डिवाइस पर किसी भी वीडियो एन्कोडर का इस्तेमाल किया जा सकता है और उसे तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराया जाता है, तो
MediaFormat.KEY_BITRATE_MODE को BITRATE_MODE_VBR पर सेट करें, ताकि एन्कोडर वैरिएबल बिटरेट मोड में काम कर सके. जब तक इससे कम से कम क्वालिटी पर असर नहीं पड़ता, तब तक एन्कोड किया गया बिटरेट :

• एक स्लाइडिंग विंडो में, इंटरफ़्रेम (आई-फ़्रेम) इंटरवल के बीच बिटरेट से 15% ज़्यादा नहीं होना चाहिए.
• यह वैल्यू, 1 सेकंड की स्लाइडिंग विंडो में बिटरेट से 100% ज़्यादा नहीं होनी चाहिए.

अगर डिवाइस पर किसी भी वीडियो एन्कोडर का इस्तेमाल किया जा सकता है और उसे तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराया जाता है, तो एन्कोडर को लगातार बिटरेट मोड में काम करने के लिए, MediaFormat.KEY_BITRATE_MODE को BITRATE_MODE_CBR पर सेट किया जाता है. ऐसे में, एन्कोडेड बिटरेट:

• [C-SR-2] हमारा सुझाव है कि एक सेकंड की स्लाइडिंग विंडो में, टारगेट बिटरेट से 15% से ज़्यादा का फ़र्क़ न हो.

अगर डिवाइस में एम्बेड की गई स्क्रीन डिसप्ले की डायगनल लंबाई कम से कम 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 का इस्तेमाल करके, QCIF रिज़ॉल्यूशन (176 x 144) के साथ काम करे. SQCIF रिज़ॉल्यूशन का इस्तेमाल करना ज़रूरी नहीं है.

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 के साथ काम करना चाहिए. साथ ही, इसका रिज़ॉल्यूशन 512 x 512 तक होना चाहिए.
• [C-SR-1] हमारा सुझाव है कि अगर हार्डवेयर एन्कोडर है, तो 720 x 480 एसडी प्रोफ़ाइल और एचडी एन्कोडिंग प्रोफ़ाइल का इस्तेमाल करें. इन प्रोफ़ाइल के बारे में नीचे दी गई टेबल में बताया गया है.

	एसडी	एचडी 720 पिक्सल	एचडी 1080 पिक्सल	यूएचडी
वीडियो रिज़ॉल्यूशन	720 x 480 पिक्सल	1280 x 720 पिक्सल	1920 x 1080 पिक्सल	3840 x 2160 पिक्सल
वीडियो फ़्रेम रेट	30 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड
वीडियो बिटरेट	1.6 एमबीपीएस	4 एमबीपीएस	5 एमबीपीएस	20 एमबीपीएस

5.2.6. AV1

अगर डिवाइस में AV1 कोडेक काम करता है, तो:

• [C-1-1] यह ज़रूरी है कि डिवाइस, 8-बिट और 10-बिट वाले कॉन्टेंट के साथ-साथ, मुख्य प्रोफ़ाइल के साथ काम करे.

• [C-1-2] परफ़ॉर्मेंस डेटा पब्लिश करना ज़रूरी है. इसका मतलब है कि नीचे दी गई टेबल में दिए गए रिज़ॉल्यूशन के लिए, getSupportedFrameRatesFor() या getSupportedPerformancePoints() एपीआई के ज़रिए परफ़ॉर्मेंस डेटा को रिपोर्ट करना ज़रूरी है.

• [C-1-3] एचडीआर मेटाडेटा को स्वीकार करना और उसे बिटरस्ट्रीम में आउटपुट करना ज़रूरी है

अगर AV1 एन्कोडर को हार्डवेयर से तेज़ किया जाता है, तो:

• [C-2-1] यह ज़रूरी है कि डिवाइस, नीचे दी गई टेबल में दी गई एचडी1080 पिक्सल वाली एन्कोडिंग प्रोफ़ाइल के साथ काम करे:

	एसडी	एचडी 720 पिक्सल	एचडी 1080 पिक्सल	यूएचडी
वीडियो रिज़ॉल्यूशन	720 x 480 पिक्सल	1280 x 720 पिक्सल	1920 x 1080 पिक्सल	3840 x 2160 पिक्सल
वीडियो फ़्रेम रेट	30 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड	30 फ़्रेम प्रति सेकंड
वीडियो बिटरेट	5 एमबीपीएस	8 एमबीपीएस	16 एमबीपीएस	50 एमबीपीएस

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 (30fps 384 केबीपीएस पर सीआईएफ़, क्यूसीआईएफ़, और एसक्यूसीआईएफ़ रिज़ॉल्यूशन) और लेवल 45 (30fps 128 केबीपीएस पर क्यूसीआईएफ़ और एसक्यूसीआईएफ़ रिज़ॉल्यूशन) के साथ काम करना चाहिए.

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 की सुविधा वाला एक्सट्रैक्टर देना होगा.

Android 15 के लिए नई ज़रूरी शर्तें लागू होना

• [C-1-2] डिवाइस की स्क्रीन पर या किसी स्टैंडर्ड वीडियो आउटपुट पोर्ट (उदाहरण के लिए, एचडीएमआई).

नई ज़रूरी शर्तों की समयसीमा खत्म होना

• [C-1-3] अगर पिछली वर्शन के साथ काम करने वाली बेस लेयर मौजूद हैं, तो उनका ट्रैक आईडी, एक साथ काम करने वाली Dolby Vision लेयर के ट्रैक आईडी जैसा होना चाहिए.

5.3.9. AV1

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

• [C-1-1] यह ज़रूरी है कि डिवाइस, 8-बिट और 10-बिट वाले कॉन्टेंट के साथ-साथ, मुख्य प्रोफ़ाइल के साथ काम करे.

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

• [C-2-1] अगर Display.getSupportedModes() के तरीके से रिपोर्ट की गई ऊंचाई 720 पिक्सल या उससे ज़्यादा है, तो यह ज़रूरी है कि डिवाइस, नीचे दी गई टेबल में दी गई कम से कम एचडी 720 पिक्सल वीडियो डिकोडिंग प्रोफ़ाइलों को डिकोड कर सके.
• [C-2-2] अगर Display.getSupportedModes() के �