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

1. शुरुआती जानकारी

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

"करना है", "नहीं करना चाहिए", "ज़रूरी", "करना चाहिए", "नहीं करना चाहिए", "चाहिए", "नहीं करना चाहिए", "सुझाया गया", "शायद", और "ज़रूरी नहीं" का इस्तेमाल, आरएफ़सी2119 में दिए गए आईईटीएफ़ स्टैंडर्ड के मुताबिक किया गया है.

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

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

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

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

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

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

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

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

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

1.1.2. ज़रूरत आईडी

ज़रूरी आईडी असाइन किया गया है.

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

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

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

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

सेक्शन 2 में, ज़रूरी शर्त के आईडी के दो हिस्से होते हैं. पहला चरण, सेक्शन आईडी से मेल खाता है, जैसा कि ऊपर बताया गया है. दूसरा हिस्सा, डिवाइस के नाप या आकार के साथ-साथ डिवाइस के नाप या आकार के लिए ज़रूरी शर्तों के बारे में बताता है.

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

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

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

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

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

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

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

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

2.2. हैंडहेल्ड की ज़रूरतें

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

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

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

नई ज़रूरी शर्तें खत्म करना

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

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

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

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

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

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

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

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

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

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

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

  • [7.1.5/H-0-1] ऐप्लिकेशन के साथ काम करने वाले लेगसी मोड के साथ काम करना ज़रूरी है. इसे अपस्ट्रीम Android ओपन सोर्स कोड के ज़रिए लागू किया गया है. इसका मतलब है कि डिवाइस लागू करने के तरीके में उन ट्रिगर या उसकी सीमा में बदलाव नहीं करना चाहिए जिन पर कंपैटबिलिटी मोड चालू होता है. साथ ही, काम करने वाले मोड के काम करने के तरीके में भी कोई बदलाव नहीं करना चाहिए.
  • [7.2.1/H-0-1] तीसरे पक्ष के इनपुट के तरीके के एडिटर (IME) ऐप्लिकेशन के साथ काम करना ज़रूरी है.
  • [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] उपयोगकर्ता के चुने गए सहायक ऐप्लिकेशन को लॉन्च करने का सुझाव दिया जाता है. दूसरे शब्दों में, वह ऐप्लिकेशन जो Voiceइंटरैक्शनService को लागू करता है या अगर फ़ोरग्राउंड गतिविधि से, KEYCODE_MEDIA_PLAY_PAUSE या KEYCODE_HEADSETHOOK को दबाकर रखने पर ACTION_ASSIST को मैनेज करने वाली कोई गतिविधि होती है, तो यह ज़्यादा देर तक दबाए जाने वाले इवेंट को हैंडल नहीं करती.
  • [7.3.1/H-SR-1] 3-ऐक्सिस एक्सलरोमीटर इस्तेमाल करने का सुझाव दिया जाता है.

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

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

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

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

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

  • [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] 6 डिग्री वाले पोज़ सेंसर के साथ काम करने के लिए बहुत ज़्यादा सुझाव दिया जाता है.
  • [7.4.3/H] इसमें Bluetooth और Bluetooth LE के साथ काम करने की सुविधा शामिल होनी चाहिए.

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

  • [7.4.2.5/H-1-1] आपको 68वें पर्सेंटाइल पर 160 मेगाहर्ट्ज़ बैंडविथ के हिसाब से, 160 मेगाहर्ट्ज़ बैंडविथ पर +/-1 मीटर और 160 मेगाहर्ट्ज़ बैंडविथ के हिसाब से +/-2 मीटर, 68वें पर्सेंटाइल पर +/-2 मीटर, और 40 मेगाहर्ट्ज़/8 सें॰मी॰ की बैंडविथ से 6 मेगाहर्ट्ज़-8 से॰मी॰ की दूरी सटीक तरीके से रिपोर्ट करनी होगी.

  • [7.4.2.5/H-SR-1] 90वें पर्सेंटाइल पर 160 मेगाहर्ट्ज़ +/-1 मीटर के अंदर 160 मेगाहर्ट्ज़ +/-1 मीटर के अंदर, 90वें पर्सेंटाइल पर (कुल डिस्ट्रिब्यूशन फ़ंक्शन के हिसाब से) +/-2 मेगाहर्ट्ज़ की फ़्रीक्वेंसी

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

नई ज़रूरी शर्तें लागू करें

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

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

नई ज़रूरी शर्तें खत्म करना

अगर हैंडहेल्ड डिवाइस लागू करने के लिए एक लॉजिकल कैमरा डिवाइस शामिल है, जिसमें CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA का इस्तेमाल करके क्षमता के बारे में बताया गया है, तो:

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

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

  • [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] अगर डिफ़ॉल्ट डिसप्ले एचडी+ (जैसे कि HD, WSVGA) तक के फ़्रेमबफ़र रिज़ॉल्यूशन का इस्तेमाल करता है, तो कर्नेल और यूज़रस्पेस के लिए उपलब्ध मेमोरी कम से कम 592 एमबी होनी चाहिए.

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

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

अगर हैंडहेल्ड डिवाइस पर लागू होने वाले किसी भी 64-बिट एबीआई के साथ काम करने की घोषणा की जाती है (32-बिट एबीआई के साथ या उसके बिना):

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

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

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

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

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

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

  • [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] सिर्फ़ 32-बिट एबीआई के साथ काम करना ज़रूरी है.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

यूएसबी सहायक डिवाइस के कनेक्ट होने पर, एपीआई AudioManager.getDevices() को कॉल करने पर:

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

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

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

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

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

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

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

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

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

  • [7.10/H]* एक बहुत ज़्यादा रोटेटिंग मास (ईआरएम) हैप्टिक एक्चुएटर (वाइब्रेटर) का इस्तेमाल नहीं करना चाहिए.
  • [7.10/H]* android.view.HapticFeedback Constants में साफ़ हैप्टिक के लिए सभी सार्वजनिक कॉन्सटेंट को लागू करना चाहिए, जैसे कि (CLOCK_TICK, context_ सदस्य, KEY एल्बम_PRESS, KEY एल्बम_ समझा, KEY अगरNAME, VE_KEY,, LONG_PRESS, TEXT_HANDLE,CONFIRM_KEY, GIT_KEY, CONFIRM_KEY_ जगह
  • [7.10/H]* android.os.VibrationEffect में क्लियर हैप्टिक के लिए सभी सार्वजनिक कॉन्सटेंट, जैसे कि (इफ़_टीआईके, इफ़ेक्ट, ACTION_HEAVY_ सदस्य, और इफ़ैक्ट_ स्टोर से पर क्लिक करें.) .QINU.IN.QIN.IN_IN_IN_प्रॉडक्ट और,.,.PRIMITIVE_* इनमें से कुछ प्रिमिटिव, जैसे कि LOW_TICK और Spin सिर्फ़ तब काम करते हैं, जब वाइब्रेटर बहुत कम फ़्रीक्वेंसी के साथ काम कर सकता हो.
  • [7.10/H]* android.view.HapticFeedbackConstants में दिए गए सार्वजनिक कॉन्सटेंट को मैप करने के दिशा-निर्देश का पालन, सुझाए गए android.os.Vibrationimpact कॉन्सटेंट के लिए करें. साथ ही, उससे जुड़े डाइमेंशन के हिसाब से भी ऐसा किया जाना चाहिए.
  • [7.10/H]* createOneShot() और createWaveform() एपीआई के लिए, क्वालिटी की जांच करनी चाहिए.
  • [7.10/H]* इस बात की पुष्टि करनी चाहिए कि सार्वजनिक android.os.Vibrator.hasAmplitudeControl() एपीआई के नतीजे, उसके वाइब्रेटर की क्षमताओं को सही तरीके से दिखाते हैं.
  • [7.10/H]* एक्चुएटर के प्लेसमेंट को उस जगह के पास रखना चाहिए जहां डिवाइस को आम तौर पर हाथों से पकड़ा जाता है या छुआ जाता है.

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

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

नई ज़रूरी शर्तें लागू करें

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

नई ज़रूरी शर्तें खत्म करना

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

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

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

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

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

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

  • [5.1/H-0-1] एएमआर-एनबी
  • [5.1/H-0-2] एएमआर-डब्ल्यूबी
  • [5.1/H-0-3] MPEG-4 एएसी प्रोफ़ाइल (AAC LC)
  • [5.1/H-0-4] MPEG-4 HE AAC प्रोफ़ाइल (AAC+)
  • [5.1/H-0-5] AAC ELD (कम देरी वाले AAC)

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

  • [5.2/H-0-1] H.264 एवीसी
  • [5.2/H-0-2] VP8

नई ज़रूरी शर्तें लागू करें

  • [5.2/H-0-3] एवी1

नई ज़रूरी शर्तें खत्म करना

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

  • [5.3/H-0-1] H.264 एवीसी
  • [5.3/H-0-2] H.265 एचईवीसी
  • [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] एक ऐसा ऐप्लिकेशन होना चाहिए जो ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE, और ACTION_CREATE_DOCUMENT इंटेंट को मैनेज करता हो, जैसा कि SDK दस्तावेज़ों में बताया गया है. साथ ही, 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] डिफ़ॉल्ट लॉन्चर को लागू करने का सुझाव दिया जाता है. इसमें शॉर्टकट, विजेट, और विजेट की सुविधाओं को ऐप्लिकेशन में पिन करने की सुविधा काम करती है.
  • [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] एक नोटिफ़िकेशन शेड शामिल करना ज़रूरी है, जिससे उपयोगकर्ता को उपयोगकर्ता की सुविधा के ज़रिए, सूचनाओं को सीधे तौर पर कंट्रोल करने (जैसे, जवाब देने, स्नूज़ करने, खारिज करने, ब्लॉक करने) करने की सुविधा मिले. जैसे, ऐक्शन बटन या एओएसपी में लागू किए गए कंट्रोल पैनल.
  • [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] सहायक कार्रवाई को मैनेज करने के लिए, डिवाइस पर Assistant को लागू करने का सुझाव दिया जाता है.

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

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

नई ज़रूरी शर्तें लागू करें

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

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

नई ज़रूरी शर्तें खत्म करना

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

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

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

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

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

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

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

  • [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 API से मिले खास फ़ील्ड को रेंडर करना होगा.
  • [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 (पहले से इंस्टॉल किए गए 'लिखाई को बोली में बदलने वाला इंजन' पर काम करने वाली भाषाओं के लिए) की सुलभता सेवाओं के बराबर या उससे ज़्यादा सुविधा उपलब्ध कराती है. जैसा कि टॉकबैक ओपन सोर्स प्रोजेक्ट में दिया गया है.
  • [3.11/H-0-1] तीसरे पक्ष के टीटीएस इंजन को इंस्टॉल करने की सुविधा दी जानी चाहिए.
  • [3.11/H-SR-1] हमारा सुझाव है कि डिवाइस पर उपलब्ध भाषाओं में काम करने वाला टीटीएस इंजन ज़रूर शामिल करें.
  • [3.13/H-SR-1] 'क्विक सेटिंग' यूज़र इंटरफ़ेस (यूआई) कॉम्पोनेंट शामिल करने का सुझाव दिया जाता है.

अगर Android हैंडहेल्ड डिवाइस लागू करने के तरीके के तहत, FEATURE_BLUETOOTH या FEATURE_WIFI के लिए सहायता का एलान किया जाता है, तो ये:

  • [3.16/H-1-1] साथी डिवाइस से जोड़ने की सुविधा के साथ काम करना ज़रूरी है.

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

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

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

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

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

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

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

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

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

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

नई ज़रूरी शर्तें लागू करें

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

नई ज़रूरी शर्तें खत्म करना

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

  • [8.1/H-0-1] फ़्रेम रेंडर होने में लगने वाला समय लगातार. फ़्रेम को रेंडर होने में लगने वाला समय और रेंडर होने में अलग-अलग समय लगने या एक सेकंड में पांच फ़्रेम से ज़्यादा नहीं होना चाहिए. साथ ही, एक सेकंड में एक फ़्रेम से कम होना चाहिए.
  • [8.1/H-0-2] यूज़र इंटरफ़ेस के लिए इंतज़ार का समय. डिवाइस को लागू करने के लिए यह पक्का करना ज़रूरी है कि Android कंपैटबिलिटी टेस्ट सुइट (सीटीएस) की बताई गई 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 एमबी/सेकंड का रैंडम रीड परफ़ॉर्मेंस मिले.

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

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

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

  • [8.4/H-0-1] हर कॉम्पोनेंट के लिए पावर प्रोफ़ाइल देना ज़रूरी है. यह प्रोफ़ाइल हर हार्डवेयर कॉम्पोनेंट के लिए मौजूदा इस्तेमाल की वैल्यू और समय के साथ कॉम्पोनेंट की वजह से बैटरी के तेज़ी से खर्च होने की जानकारी देती है. इस बारे में Android ओपन सोर्स प्रोजेक्ट की साइट में बताया गया है.
  • [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.hardware.telephony के साथ काम करती है, तो:

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

नई ज़रूरी शर्तें खत्म करना

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

  • [9.11/H-0-2] कीस्टोर को लागू करने के तरीके का बैक अप लेना ज़रूरी है. इसके लिए, आपको एक अलग एनवायरमेंट का इस्तेमाल करना होगा.
  • [9.11/H-0-3] आरएसए, एईएस, ईसीडीएसए, और एचएमएसी क्रिप्टोग्राफ़िक एल्गोरिदम और MD5, SHA1, और SHA-2 फ़ैमिली हैश फ़ंक्शन लागू करने ज़रूरी हैं, ताकि Android कीस्टोर सिस्टम के काम करने वाले हैश फ़ंक्शन उस जगह पर सही तरीके से काम कर सकें जिसे कर्नेल और उसके बाद वाले कोड पर चल रहे कोड से सुरक्षित तरीके से अलग किया गया है. सिक्योर आइसोलेशन से उन सभी संभावित मैकेनिज़्म को ब्लॉक कर देना चाहिए जिनकी मदद से कर्नेल या यूज़रस्पेस कोड, डीएमए के साथ-साथ आइसोलेटेड एनवायरमेंट की अंदरूनी स्थिति को ऐक्सेस कर सकते हैं. अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट (एओएसपी), Trusty लागू करने की सुविधा का इस्तेमाल करके इस ज़रूरी शर्त को पूरा करता है. हालांकि, ARM TrustZone पर आधारित कोई दूसरा ARM TrustZone समाधान या किसी तीसरे पक्ष के समीक्षा किए गए सुरक्षित तरीके से लागू करने के विकल्प, अन्य विकल्प हैं.
  • [9.11/H-0-4] लॉक स्क्रीन की पुष्टि करने के लिए, अलग-अलग डिवाइसों पर इस्तेमाल करना ज़रूरी है. साथ ही, पुष्टि करने की प्रक्रिया पूरी होने पर ही, पुष्टि करने वाली कुंजियों का इस्तेमाल करने की अनुमति दें. लॉक स्क्रीन के क्रेडेंशियल को इस तरह से सेव किया जाना चाहिए कि लॉक स्क्रीन पर पुष्टि करने के लिए, सिर्फ़ अलग-अलग एनवायरमेंट को ऐक्सेस किया जा सके. अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट, गेटकीपर हार्डवेयर ऐब्स्ट्रैक्शन लेयर (HAL) और ट्रस्टी उपलब्ध कराता है. इनका इस्तेमाल इस ज़रूरी शर्त को पूरा करने के लिए किया जा सकता है.
  • [9.11/H-0-5] कुंजी को प्रमाणित करने की सुविधा दी जानी चाहिए, जहां पुष्टि करने वाले साइनिंग पासकोड को सुरक्षित हार्डवेयर से सुरक्षित किया गया हो और सुरक्षित हार्डवेयर में हस्ताक्षर किया जाता हो. पुष्टि करने के लिए इस्तेमाल होने वाली कुंजियों को कई डिवाइसों के साथ शेयर करना ज़रूरी है, ताकि इनका इस्तेमाल डिवाइस आइडेंटिफ़ायर के तौर पर न किया जा सके. इस ज़रूरी शर्त को पूरा करने का एक तरीका यह है कि पुष्टि करने वाली एक ही कुंजी शेयर की जाए. ऐसा तब तक किया जा सकता है, जब तक किसी 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 सिक्योर लॉक स्क्रीन में, पुष्टि करने के मुख्य तरीके के बारे में बताया नहीं गया है. एओएसपी, लॉकडाउन मोड की ज़रूरतों को पूरा करता है.

नई ज़रूरी शर्तें लागू करें

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

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

नई ज़रूरी शर्तें खत्म करना

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

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

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

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

नई ज़रूरी शर्तें लागू करें

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

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

नई ज़रूरी शर्तें खत्म करना

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

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

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

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

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

नई ज़रूरी शर्तें लागू करें

अगर हैंडहेल्ड डिवाइस पर माइक्रोफ़ोन और/या कैमरा ऐक्सेस संकेत के बिना, System API VisualQueryDetectionService या क्वेरी का पता लगाने का कोई दूसरा तरीका काम करता है, तो:

  • [9.8/H-3-1] यह पक्का करना ज़रूरी है कि क्वेरी का पता लगाने वाली सेवा सिर्फ़ सिस्टम, ContentCaptureService या डिवाइस पर बोली पहचानने वाली सेवा (SpeechRecognizer#createOnDeviceSpeechRecognizer() की बनाई गई) को डेटा भेज सके.
  • [9.8/H-3-2] ContentCaptureService या उपयोगकर्ता के डिवाइस पर बोली पहचानने वाली सेवा के अलावा, VisualQueryDetectionService से बाहर कोई भी ऑडियो या वीडियो की जानकारी भेजने की अनुमति नहीं होनी चाहिए.
  • [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_HOTWORDContentCaptureService या सीडीडी आइडेंटिफ़ायर [C-4-X] के साथ सेक्शन 9.1 में बताई गई भूमिकाओं वाले ऐप्लिकेशन को ऐक्सेस करने पर नहीं.
  • [9.8.2/H-4-2] माइक्रोफ़ोन का इस्तेमाल करने वाले हाल ही के और चालू ऐप्लिकेशन की सूची दिखाना ज़रूरी है. यह सूची PermissionManager.getIndicatorAppOpUsageData() से लौटाए गए ऐप्लिकेशन के तौर पर दिखनी चाहिए. साथ ही, उनसे जुड़े एट्रिब्यूशन मैसेज की जानकारी भी देनी होगी.

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

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

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

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

  • [6.1/H-0-1]* शेल कमांड के साथ काम करना ज़रूरी है cmd testharness.

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

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

नई ज़रूरी शर्तें लागू करें

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

  • [5.1/H-1-1] CodecCapabilities.getMaxSupportedInstances() और VideoCapabilities.getSupportedPerformancePoints() तरीकों का इस्तेमाल करके, किसी भी कोडेक कॉम्बिनेशन में एक साथ चलाए जा सकने वाले हार्डवेयर वीडियो डिकोडर सेशन की ज़्यादा से ज़्यादा संख्या का विज्ञापन करना ज़रूरी है.
  • [5.1/H-1-2] 8-बिट (एसडीआर) हार्डवेयर वीडियो डिकोडर के छह इंस्टेंस पर काम करना ज़रूरी है. एवीसी, HEVC, VP9, AV1 या उसके बाद के सेशन, 1080p रिज़ॉल्यूशन@30 FPS (फ़्रेम प्रति सेकंड) पर तीन सेशन के साथ काम कर सकते हैं. हालांकि, AV1 में 30 FPS (फ़्रेम प्रति सेकंड) पर तीन सेशन नहीं चलेगा. AV1 कोडेक की ज़रूरत सिर्फ़ 1080 पिक्सल रिज़ॉल्यूशन के साथ काम करती है. हालांकि, 1080p30fps पर 6 इंस्टेंस के साथ काम करने के लिए भी यह ज़रूरी है.
  • [5.1/H-1-3] CodecCapabilities.getMaxSupportedInstances() और VideoCapabilities.getSupportedPerformancePoints() तरीकों का इस्तेमाल करके, किसी भी कोडेक कॉम्बिनेशन में एक साथ चलाए जा सकने वाले हार्डवेयर वीडियो एन्कोडर सेशन की ज़्यादा से ज़्यादा संख्या का विज्ञापन करना ज़रूरी है.
  • [5.1/H-1-4] 8-बिट (SDR) हार्डवेयर वीडियो एन्कोडर सेशन के 6 इंस्टेंस (एवीसी, एचईवीसी, VP9, AV1 या बाद के वर्शन) के साथ काम करना चाहिए. ये सेशन 1080p रिज़ॉल्यूशन@30 FPS पर चार सेशन और 4k रिज़ॉल्यूशन@30 एफ़पीएस (फ़्रेम प्रति सेकंड) पर दो सेशन के साथ चल रहे हैं. AV1 कोडेक की ज़रूरत सिर्फ़ 1080 पिक्सल रिज़ॉल्यूशन के साथ काम करती है. हालांकि, 1080p30fps पर 6 इंस्टेंस के साथ काम करने के लिए भी यह ज़रूरी है.
  • [5.1/H-1-5] हार्डवेयर वीडियो एन्कोडर और डिकोडर सेशन की ज़्यादा से ज़्यादा संख्या का विज्ञापन करना ज़रूरी है जो CodecCapabilities.getMaxSupportedInstances() और VideoCapabilities.getSupportedPerformancePoints() तरीकों का इस्तेमाल करके किसी भी कोडेक कॉम्बिनेशन में एक साथ चलाए जा सकते हैं.
  • [5.1/H-1-6] 4K@30fps रिज़ॉल्यूशन पर तीन सेशन के साथ, किसी भी कोडेक कॉम्बिनेशन में एक साथ चल रहे 8-बिट (एसडीआर) हार्डवेयर वीडियो डिकोडर और हार्डवेयर वीडियो एन्कोडर सेशन (एवीसी, HEVC, VP9, AV1 या उसके बाद के) के 6 इंस्टेंस पर काम करना ज़रूरी है. इनमें से ज़्यादा से ज़्यादा 2 सेशन, 4K@30fps रिज़ॉल्यूशन पर तीन सेशन के साथ काम कर सकते हैं. इनमें से ज़्यादा से ज़्यादा 2 सेशन, एन्कोडर रिज़ॉल्यूशन और 308 सेशन हैं. AV1 कोडेक की ज़रूरत सिर्फ़ 1080 पिक्सल रिज़ॉल्यूशन के साथ काम करती है. हालांकि, 1080p30fps पर 6 इंस्टेंस के साथ काम करने के लिए भी यह ज़रूरी है.
  • [5.1/H-1-19] 4K@30 रिज़ॉल्यूशन (जब तक AV1-19) में किसी भी कोडेक संयोजन में एक साथ चल रहे 10-बिट (एचडीआर) हार्डवेयर वीडियो डीकोडर और हार्डवेयर वीडियो एन्कोडर सेशन (AVC, HEVC, VP9, AV1 या उसके बाद के) के 3 इंस्टेंस पर काम करना ज़रूरी है (जब तक AV1 इनपुट न हो) कि इनमें से किसी भी 1 एफ़पीएस इनपुट से किसी एन्कोडर सेशन1 में ज़्यादा से ज़्यादा 1 1001, अगर जीएल प्लैटफ़ॉर्म से कोड में बदला गया है, तो एन्कोडर से एचडीआर मेटाडेटा जनरेट करने की ज़रूरत नहीं है. AV1 कोडेक सेशन का इस्तेमाल सिर्फ़ 1080 पिक्सल रिज़ॉल्यूशन पर काम करने के लिए किया जाता है. भले ही, 4K रिज़ॉल्यूशन की ज़रूरत हो.
  • [5.1/H-1-7] सभी हार्डवेयर वीडियो एन्कोडर के लिए, 1080 पिक्सल या इससे छोटे वीडियो एन्कोडिंग सेशन के लिए, कोडेक शुरू होने का इंतज़ार 40 मि॰से॰ या इससे कम होना चाहिए. यहां लोड को हार्डवेयर वीडियो कोडेक और 1080 पिक्सल ऑडियो-वीडियो रिकॉर्डिंग शुरू करने के साथ-साथ, एक साथ चलने वाले 1080 पिक्सल से 720 पिक्सल वाले वीडियो की ट्रांसकोडिंग सेशन के तौर पर तय किया गया है. Dolby विज़न कोडेक के लिए, कोडेक के शुरू होने में लगने वाला समय 50 मि॰से॰ या इससे कम होना चाहिए.
  • [5.1/H-1-8] सभी ऑडियो एन्कोडर के लिए, 128 केबीपीएस या इससे कम बिटरेट वाले ऑडियो एन्कोडिंग सेशन के लिए, कोडेक शुरू होने में 30 मि॰से॰ या इससे कम समय का होना ज़रूरी है. यहां लोड को हार्डवेयर वीडियो कोडेक और 1080 पिक्सल ऑडियो-वीडियो रिकॉर्डिंग शुरू करने के साथ-साथ, एक साथ चलने वाले 1080 पिक्सल से 720 पिक्सल वाले वीडियो की ट्रांसकोडिंग सेशन के तौर पर तय किया गया है.
  • [5.1/H-1-9] 8-बिट (एसडीआर) और 10-बिट एचडीआर कॉन्टेंट के लिए, 4k रिज़ॉल्यूशन@30 FPS (फ़्रेम प्रति सेकंड) पर एक साथ काम करने वाले किसी भी कोडेक कॉम्बिनेशन में सुरक्षित हार्डवेयर वीडियो डिकोडर सेशन के दो इंस्टेंस (एवीसी, एचईवीसी, VP9, AV1 या इसके बाद के) पर काम करना ज़रूरी है. AV1 कोडेक सेशन का इस्तेमाल सिर्फ़ 1080 पिक्सल रिज़ॉल्यूशन पर काम करने के लिए किया जाता है. भले ही, 4K रिज़ॉल्यूशन की ज़रूरत हो.
  • अन्य AV1 कोडेक सेशन का इस्तेमाल सिर्फ़ 1080 पिक्सल रिज़ॉल्यूशन पर काम करने के लिए किया जाता है. भले ही, 4K रिज़ॉल्यूशन की ज़रूरत हो.
  • [5.1/H-1-11] डिवाइस पर हर हार्डवेयर एवीसी, एचईवीसी, वीपी9 या एवी1 डिकोडर के लिए सुरक्षित डिकोडर काम करना चाहिए.
  • [5.1/H-1-12] लोड होने पर, सभी हार्डवेयर वीडियो डिकोडर के लिए, 1080 पिक्सल या इससे छोटे वीडियो डिकोड करने वाले सेशन के लिए, कोडेक शुरू होने का इंतज़ार 40 मि॰से॰ या इससे कम होना चाहिए. यहां लोड को, हार्डवेयर वीडियो कोडेक और 1080 पिक्सल के ऑडियो-वीडियो प्लेबैक शुरू करने के तरीके का इस्तेमाल करके, सिर्फ़ 1080 पिक्सल से 720 पिक्सल वाले वीडियो ट्रांसकोडिंग सेशन के तौर पर दिखाया गया है. Dolby विज़न कोडेक के लिए, कोडेक के शुरू होने में लगने वाला समय 50 मि॰से॰ या इससे कम होना चाहिए.
  • [5.1/H-1-13] लोड होने पर, सभी ऑडियो डिकोडर के लिए, 128 केबीपीएस या इससे कम बिटरेट वाले ऑडियो डिकोड करने वाले सेशन के लिए, कोडेक शुरू होने में 30 मि॰से॰ या इससे कम का समय होना चाहिए. यहां लोड को हार्डवेयर वीडियो कोडेक और 1080 पिक्सल ऑडियो-वीडियो प्लेबैक इनिशलाइज़ेशन का इस्तेमाल करके, एक साथ 1080 पिक्सल से 720 पिक्सल वाले वीडियो की ट्रांसकोडिंग करने के तौर पर तय किया जाता है.
  • [5.1/H-1-14] AV1 हार्डवेयर डिकोडर मुख्य 10, लेवल 4.1 और फ़िल्म ग्रेन का समर्थन करना ज़रूरी है.
  • [5.1/H-1-15] 4K60 रिज़ॉल्यूशन के साथ काम करने वाला कम से कम एक हार्डवेयर वीडियो डिकोडर होना चाहिए.
  • [5.1/H-1-16] इसमें 4K60 के साथ काम करने वाला कम से कम एक हार्डवेयर वीडियो एन्कोडर होना चाहिए.
  • [5.3/H-1-1] लोड होने पर 4K 60 FPS (फ़्रेम प्रति सेकंड) वीडियो सेशन के लिए, 10 सेकंड में एक से ज़्यादा फ़्रेम (यानी कि 0.167 प्रतिशत से कम फ़्रेम में) नहीं छोड़ना चाहिए.
  • [5.3/H-1-2] 4K सेशन के लिए लोड किए जा रहे 60 FPS (फ़्रेम प्रति सेकंड) वाले वीडियो सेशन के रिज़ॉल्यूशन में बदलाव के दौरान, 10 सेकंड में एक से ज़्यादा फ़्रेम नहीं छोड़ा जाना चाहिए.
  • [5.6/H-1-1] सीटीएस वेरिफ़ायर के टैप-टू-टोन टेस्ट का इस्तेमाल करते समय, इसमें 80 मिलीसेकंड या इससे कम समय के लिए टैप-टू-टोन होना चाहिए.
  • [5.6/H-1-2] 80 मिलीसेकंड तक या कम से कम एक काम करने वाले डेटा पाथ से, ऑडियो के इंतज़ार का समय कम होना चाहिए.
  • [5.6/H-1-3] स्टीरियो आउटपुट के लिए 3.5 मि॰मी॰ से ज़्यादा के ऑडियो जैक के लिए >=24-बिट ऑडियो काम करना चाहिए. अगर ऐसा है, तो इंतज़ार का समय कम करने और स्ट्रीमिंग कॉन्फ़िगरेशन के पूरे डेटा पाथ के साथ काम करने पर, यूएसबी ऑडियो पर भी काम किया जा सकता है. इंतज़ार का समय कम करने वाले कॉन्फ़िगरेशन के लिए, ऐप्लिकेशन को ऑडियो के इंतज़ार का समय कम करने वाले कॉलबैक मोड में इस्तेमाल किया जाना चाहिए. स्ट्रीमिंग कॉन्फ़िगरेशन के लिए, ऐप्लिकेशन को Java AudioTrack का इस्तेमाल करना चाहिए. इंतज़ार का समय कम होने और स्ट्रीमिंग कॉन्फ़िगरेशन, दोनों में ही HAL आउटपुट सिंक अपने टारगेट आउटपुट फ़ॉर्मैट के लिए AUDIO_FORMAT_PCM_24_BIT, AUDIO_FORMAT_PCM_24_BIT_PACKED, AUDIO_FORMAT_PCM_32_BIT या AUDIO_FORMAT_PCM_FLOAT में से किसी एक को स्वीकार करेगा.
  • [5.6/H-1-4] >=4 चैनल के यूएसबी ऑडियो डिवाइसों पर भी काम करना ज़रूरी है (इसका इस्तेमाल डीजे कंट्रोलर, गानों की झलक देखने के लिए करता है.)
  • [5.6/H-1-5] क्लास का पालन करने वाले एमआईडीआई डिवाइसों के साथ काम करना ज़रूरी है. साथ ही, एमआईडीआई फ़ीचर फ़्लैग का एलान करना ज़रूरी है.
  • [5.6/H-1-9] कम से कम 12 चैनल के साथ काम करना ज़रूरी है. इससे 7.1.4 चैनल मास्क के साथ AudioTrack को खोला जा सकता है. साथ ही, सभी चैनलों को सही तरीके से स्पेशलाइज़ या डाउनमिक्स किया जा सकता है.
  • [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 एन्कोडर के साथ काम करना ज़रूरी है, जो 480p तक के रिज़ॉल्यूशन को 30fps और 1 एमबीपीएस पर एन्कोड कर सकता है.
  • [5.12/H-1-1] ज़रूरी है [5.12/H-SR] को इस बात पर ज़ोर दिया जाता है कि डिवाइस पर मौजूद सभी हार्डवेयर AV1 और HEVC एन्कोडर के लिए, Feature_HdrEditing की सुविधा काम करें.
  • [5.12/H-1-2] डिवाइस पर मौजूद सभी हार्डवेयर AV1 और HEVC एन्कोडर के लिए RGBA_1010102 कलर फ़ॉर्मैट काम करना चाहिए.
  • [5.12/H-1-3] EXT_YUV_target एक्सटेंशन के लिए सहायता देना ज़रूरी है, ताकि 8 और 10-बिट दोनों में YUV टेक्सचर के सैंपल का इस्तेमाल किया जा सके.
  • [7.1.4/H-1-1] डिसप्ले प्रोसेसिंग यूनिट (डीपीयू) में कम से कम छह हार्डवेयर ओवरले होने चाहिए. इनमें से कम से कम दो पर 10-बिट वीडियो कॉन्टेंट दिखाने की सुविधा होनी चाहिए.

अगर हैंडहेल्ड डिवाइस लागू करने के तरीके android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS के लिए android.os.Build.VERSION_CODES.U दिखाते हैं और उनमें हार्डवेयर एवीसी या एचईवीसी एन्कोडर के साथ काम करने की सुविधा शामिल है, तो ये:

नई ज़रूरी शर्तें खत्म करना

2.2.7.2. कैमरा

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

नई ज़रूरी शर्तें लागू करें

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

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

नई ज़रूरी शर्तें खत्म करना

2.2.7.3. हार्डवेयर

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

नई ज़रूरी शर्तें लागू करें

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

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

नई ज़रूरी शर्तें खत्म करना

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

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

नई ज़रूरी शर्तें लागू करें

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

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

नई ज़रूरी शर्तें खत्म करना

2.3. टेलीविज़न की आवश्यकताएं

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

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

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

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

2.3.1. हार्डवेयर

टेलीविज़न डिवाइस पर यह सुविधा लागू करना:

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

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

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

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

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

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

टेलीविज़न डिवाइस पर यह सुविधा लागू करना:

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

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

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

  • [5.1/T-0-1] MPEG-4 एएसी प्रोफ़ाइल (AAC LC)
  • [5.1/T-0-2] MPEG-4 HE AAC प्रोफ़ाइल (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] हमारा सुझाव है कि 30 फ़्रेम प्रति सेकंड पर 720 पिक्सल और 1080 पिक्सल रिज़ॉल्यूशन वाले वीडियो की H.264 एन्कोडिंग पर काम करें.

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

  • [5.3.3/T-0-1] MPEG-4 एसपी
  • [5.3.4/T-0-2] H.264 एवीसी
  • [5.3.5/T-0-3] H.265 एचईवीसी
  • [5.3.6/T-0-4] VP8
  • [5.3.7/T-0-5] VP9
  • [5.3.1/T-0-6] MPEG-2

नई ज़रूरी शर्तें लागू करें

नई ज़रूरी शर्तें खत्म करना

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

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

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

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

H.265 हार्डवेयर डिकोडर के साथ टेलीविज़न डिवाइस को लागू करने के लिए, मानक वीडियो फ़्रेम रेट के हिसाब से H.265 डिकोडिंग का काम करना ज़रूरी है.

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

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

  • [5.3.5/T-2-1] मेन 10 लेवल 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] यूएचडी डिकोडिंग प्रोफ़ाइल 60 फ़्रेम प्रति सेकंड पर काम करनी चाहिए. प्रोफ़ाइल 0 (8 बिट कलर डेप्थ) होनी चाहिए.
  • [5.3.7/T-SR1] प्रोफ़ाइल 2 (10 बिट रंग की गहराई) के साथ 60 फ़्रेम प्रति सेकंड पर, यूएचडी डिकोडिंग प्रोफ़ाइल के लिए, इस बात का खास तौर पर सुझाव दिया जाता है.

टेलीविज़न डिवाइस पर यह सुविधा लागू करना:

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

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

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

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

  • [5.8/T-1-1] एचडीसीपी 2.2 के साथ काम करना ज़रूरी है.

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

  • [5.8/T-2-1] एचडीसीपी 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 (पहले से इंस्टॉल की गई 'टेक्स्ट को बोली में बदलें' इंजन पर काम करने वाली भाषाओं के लिए) की सुलभता सेवाओं के बराबर या उनसे ज़्यादा काम करने वाली सुलभता सेवाओं को पहले से लोड करने का सुझाव देती है.

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

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

टेलीविज़न डिवाइस पर यह सुविधा लागू करना:

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

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

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

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

  • [8.3/T-1-1] बैटरी सेवर की सुविधा को चालू और बंद करने के लिए, लोगों को ज़रूरी अधिकार देना ज़रूरी है.

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

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

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

टेलीविज़न डिवाइस पर यह सुविधा लागू करना:

  • [8.4/T-0-1] हर कॉम्पोनेंट के लिए पावर प्रोफ़ाइल देना ज़रूरी है. यह प्रोफ़ाइल हर हार्डवेयर कॉम्पोनेंट के लिए मौजूदा इस्तेमाल की वैल्यू और समय के साथ कॉम्पोनेंट की वजह से बैटरी के तेज़ी से खर्च होने की जानकारी देती है. इस बारे में Android ओपन सोर्स प्रोजेक्ट की साइट में बताया गया है.
  • [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] आरएसए, एईएस, ईसीडीएसए, एचएमएसी क्रिप्टोग्राफ़िक एल्गोरिदम, और MD5, SHA1, और SHA-2 फ़ैमिली हैश फ़ंक्शन लागू करने ज़रूरी हैं, ताकि Android कीस्टोर सिस्टम के काम करने वाले एल्गोरिदम उस जगह पर सही तरीके से काम कर सकें जिसे कर्नेल और उसके बाद वाले कोड पर चलने वाले कोड से सुरक्षित तरीके से अलग किया गया है. सिक्योर आइसोलेशन से उन सभी संभावित मैकेनिज़्म को ब्लॉक कर देना चाहिए जिनकी मदद से कर्नेल या यूज़रस्पेस कोड, डीएमए के साथ-साथ आइसोलेटेड एनवायरमेंट की अंदरूनी स्थिति को ऐक्सेस कर सकते हैं. अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट (एओएसपी), Trusty लागू करने की सुविधा का इस्तेमाल करके इस ज़रूरी शर्त को पूरा करता है. हालांकि, ARM TrustZone पर आधारित कोई दूसरा ARM TrustZone समाधान या किसी तीसरे पक्ष के समीक्षा किए गए सुरक्षित तरीके से लागू करने के विकल्प, अन्य विकल्प हैं.
  • [9.11/T-0-3] लॉक स्क्रीन की पुष्टि करने की प्रोसेस, एक-दूसरे से अलग ऐक्सेस किए जाने पर करना ज़रूरी है. साथ ही, पुष्टि करने की प्रक्रिया पूरी होने पर ही, पुष्टि करने वाली कुंजियों का इस्तेमाल करने की अनुमति दें. लॉक स्क्रीन के क्रेडेंशियल को इस तरह से सेव किया जाना चाहिए कि लॉक स्क्रीन पर पुष्टि करने के लिए, सिर्फ़ अलग-अलग एनवायरमेंट को ऐक्सेस किया जा सके. अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट, गेटकीपर हार्डवेयर ऐब्स्ट्रैक्शन लेयर (HAL) और ट्रस्टी उपलब्ध कराता है. इनका इस्तेमाल इस ज़रूरी शर्त को पूरा करने के लिए किया जा सकता है.
  • [9.11/T-0-4] कुंजी को प्रमाणित करने की सुविधा दी जानी चाहिए, जहां पुष्टि करने वाले साइनिंग पासकोड को सुरक्षित हार्डवेयर से सुरक्षित किया गया हो और सुरक्षित हार्डवेयर में हस्ताक्षर किया जाता हो. पुष्टि करने के लिए इस्तेमाल होने वाली कुंजियों को कई डिवाइसों के साथ शेयर करना ज़रूरी है, ताकि इनका इस्तेमाल डिवाइस आइडेंटिफ़ायर के तौर पर न किया जा सके. इस ज़रूरी शर्त को पूरा करने का एक तरीका यह है कि पुष्टि करने वाली एक ही कुंजी शेयर की जाए. ऐसा तब तक किया जा सकता है, जब तक किसी 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] प्रतिबंधित प्रोफ़ाइलों का इस्तेमाल नहीं किया जाना चाहिए. हालांकि, अन्य उपयोगकर्ताओं को वॉइस कॉल और एसएमएस ऐक्सेस करने से /बंद करने के लिए, कंट्रोल के लिए एओएसपी को लागू करना ज़रूरी है.

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

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

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

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

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

टेलीविज़न डिवाइस पर यह सुविधा लागू करना:

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

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] उपयोगकर्ता के लिए Home फ़ंक्शन और वापस जाएं वाले फ़ंक्शन का इस्तेमाल करना ज़रूरी है. ऐसा सिर्फ़ तब होना चाहिए, जब वह UI_MODE_TYPE_WATCH में हो.

  • [7.2.4/W-0-1] टचस्क्रीन इनपुट पर काम करना ज़रूरी है.

  • [7.3.1/W-SR-1] 3-ऐक्सिस एक्सलरोमीटर इस्तेमाल करने का सुझाव दिया जाता है.

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

  • [7.3.3/W-1-1] जीएनएसएस मेज़रमेंट के मिलते ही, उसकी रिपोर्ट ज़रूर करें. भले ही, जीपीएस/जीएनएसएस का इस्तेमाल करके कैलकुलेट की गई जगह की जानकारी अभी तक रिपोर्ट न की गई हो.
  • [7.3.3/W-1-2] GNSS pseudoranges और pseudoranges की रिपोर्ट करना ज़रूरी है.जगह तय करने के बाद, खुले आसमान की स्थितियों में, जब कोई स्थिर जगह हो या 0.2 मीटर प्रति सेकंड के वर्ग से कम रफ़्तार पर चलना हो, तो उसकी स्थिति का हिसाब लगाने के लिए, 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_ मोड_TYPE_देखें के साथ काम करना ज़रूरी है.
  • [3.2.3.1/W-0-1] इंटेंट हैंडलर के साथ एक या उससे ज़्यादा ऐप्लिकेशन या सेवा कॉम्पोनेंट को पहले से लोड करना ज़रूरी है. ऐसा यहां दिए गए ऐप्लिकेशन के इन इंटेंट के बताए गए सभी पब्लिक इंटेंट फ़िल्टर पैटर्न के लिए किया जाना चाहिए.

स्मार्टवॉच के लिए लागू किए गए डिवाइस:

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

स्मार्टवॉच के लिए, android.hardware.audio.output फ़ीचर फ़्लैग के बारे में जानकारी देने वाले डिवाइसों को लागू करें:

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

अगर स्मार्टवॉच के लिए सेट किए गए डिवाइस पर, android.hardware.audio.आउट फ़ंक्शन की रिपोर्ट दी जाती है, तो वे:

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

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

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

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

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

स्मार्टवॉच के लिए लागू किए गए डिवाइस:

  • [8.4/W-0-1] हर कॉम्पोनेंट के लिए पावर प्रोफ़ाइल देना ज़रूरी है. यह प्रोफ़ाइल हर हार्डवेयर कॉम्पोनेंट के लिए मौजूदा इस्तेमाल की वैल्यू और समय के साथ कॉम्पोनेंट की वजह से बैटरी के तेज़ी से खर्च होने की जानकारी देती है. इस बारे में Android ओपन सोर्स प्रोजेक्ट की साइट में बताया गया है.
  • [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] प्रतिबंधित प्रोफ़ाइलों का इस्तेमाल नहीं किया जाना चाहिए. हालांकि, अन्य उपयोगकर्ताओं को वॉइस कॉल और एसएमएस ऐक्सेस करने से /बंद करने के लिए, कंट्रोल के लिए एओएसपी को लागू करना ज़रूरी है.

नई ज़रूरी शर्तें लागू करें

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

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

नई ज़रूरी शर्तें खत्म करना

2.5. वाहन संबंधित ज़रूरतें

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

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

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

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

2.5.1. हार्डवेयर

वाहन संबंधित डिवाइस पर विज्ञापन लागू करना:

  • [7.1.1.1/A-0-1] फ़ोन की स्क्रीन, डायगनल साइज़ में कम से कम छह इंच की होनी चाहिए.
  • [7.1.1.1/A-0-2] स्क्रीन साइज़ का लेआउट कम से कम 750 dp x 480 dp होना चाहिए.
  • [7.2.3/A-0-1] होम फ़ंक्शन देना ज़रूरी है. साथ ही, 'वापस जाएं' और 'हाल ही के' फ़ंक्शन उपलब्ध कराए जा सकते हैं.
  • [7.2.3/A-0-2] 'वापस जाएं' फ़ंक्शन (KEYCODE_BACK) के सामान्य और लंबे समय तक दबाए जाने वाले इवेंट, दोनों को फ़ोरग्राउंड ऐप्लिकेशन में भेजना होगा.
  • [7.3/A-0-1] GEAR_SELECTION, NIGHT_MODE, PERF_VEHICLE_SPEED और PARKING_BRAKE_ON को लागू करना और इसकी शिकायत करना ज़रूरी है.
  • [7.3/A-0-2] NIGHT_MODE फ़्लैग की वैल्यू, डैशबोर्ड के 'दिन/रात' मोड के हिसाब से होनी चाहिए. साथ ही, यह आस-पास की लाइट के हिसाब से दिखाए जाने वाले सेंसर इनपुट के हिसाब से होनी चाहिए. स्क्रीन की रोशनी को अपने-आप घटाने-बढ़ाने वाला सेंसर और फ़ोटोमीटर एक जैसा हो सकता है.
  • [7.3/A-0-3] सेंसर से जुड़ी ज़्यादा जानकारी वाला फ़ील्ड TYPE_SENSOR_PLACEMENT उपलब्ध कराए गए हर सेंसर के लिए, SensoradditionalInfo के हिस्से के तौर पर बताना ज़रूरी है.
  • [7.3/A-SR1] जीपीएस/जीएनएसएस को अतिरिक्त सेंसर से जोड़ने पर, जगह की जानकारी का पता लगा सकता है. अगर जगह की जानकारी को बंद माना जाता है, तो इससे जुड़े सेंसर के टाइप और/या इस्तेमाल किए गए वाहन के प्रॉपर्टी आईडी को लागू करने और उनकी शिकायत करने का सुझाव दिया जाता है.
  • [7.3/A-0-4] LocationManager#requestLocation अनोखे() के ज़रिए जिस Location के लिए अनुरोध किया गया है वह मैप से मेल नहीं खाना चाहिए.

  • [7.3.1/A-0-4] ज़रूरी है कि वह Android कार सेंसर कोऑर्डिनेट सिस्टम का पालन करे.

  • [7.3/A-SR-1] 3-ऐक्सिस एक्सलरोमीटर और 3-ऐक्सिस जाइरोस्कोप को शामिल करने के लिए बहुत ज़्यादा ध्यान दिया जाता है.

  • [7.3/A-SR-2] TYPE_HEADING सेंसर को लागू करने और रिपोर्ट करने के लिए STRONGLY_सुझाया गया तरीका इस्तेमाल किया गया.

अगर वाहन संबंधित डिवाइस, OpenGL ES 3.1 के साथ काम करते हैं, तो वे:

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

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

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

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

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

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

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

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

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

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

  • [7.3.4/A-SR-2] सीमित ऐक्सिस जाइरोस्कोप के लिए, कंपोज़िट सेंसर का इस्तेमाल करने का सुझाव दिया जाता है.

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

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

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

  • [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 ज़रूरी शर्तें उन वाहनों में पूरी होती हैं जिनमें मोबाइल नेटवर्क पर डेटा कनेक्टिविटी न हो. यह शर्त, रिसीवर पर कैलकुलेट की गई GNSS ऑर्बिट से जुड़े अनुमान का इस्तेमाल करके या वाहन की आखिरी जगह की जानकारी का इस्तेमाल करके, कम से कम 60 सेकंड के लिए मरे हुए वाहन की लोकेशन का इस्तेमाल करके, 7.3.3/C-1-3 या दोनों को मिलाना हो सकती है.

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

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

वाहन संबंधित डिवाइस पर विज्ञापन लागू करना:

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

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

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

नई ज़रूरी शर्तें लागू करें

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

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

नई ज़रूरी शर्तें खत्म करना

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

वाहन संबंधित डिवाइस पर विज्ञापन लागू करना:

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

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

  • [7.5/A-1-1] यह ज़रूरी नहीं है कि बाहरी व्यू कैमरे को Android Camera APIs से ऐक्सेस किया जा सके. ऐसा तब तक नहीं होना चाहिए, जब तक कैमरे की मुख्य ज़रूरी शर्तें पूरी न हों.
  • [7.5/A-SR-1] इस बात का खास तौर पर सुझाव दिया जाता है कि कैमरे की झलक को घुमाया न जाए या हॉरिज़ॉन्टल रूप से उसका मिरर न किया जाए.

  • [7.5/A-SR-2] का रिज़ॉल्यूशन कम से कम 1.3 मेगापिक्सल के लिए बहुत ज़्यादा रखा जाता है.

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

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

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

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

वाहन संबंधित डिवाइस पर विज्ञापन लागू करना:

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

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

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

नई ज़रूरी शर्तें लागू करें

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

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

वाहन संबंधित डिवाइस पर विज्ञापन लागू करना:

  • [7.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 ऑटोमोटिव सेंसर ऐक्सिस के X-Y प्लेन के साथ अलाइन हो सके.

अगर वाहन संबंधित डिवाइस में कोई ऐसा कैमरा शामिल है जिसे android.hardware.Camera या android.hardware.camera2 API से ऐक्सेस किया जा सकता है, तो ये:

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

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

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

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

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

अगर वाहन संबंधित डिवाइस में एक या उससे ज़्यादा ऐसे कैमरे शामिल हैं जिन्हें Extended View System Service और android.hardware.Camera या android.hardware.Camera2 API, दोनों से ऐक्सेस किया जा सकता है, तो ऐसे कैमरे के लिए:

  • [7.5/A-6-1] आपको एक ही कैमरा आईडी की शिकायत करनी होगी.

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

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

नई ज़रूरी शर्तें खत्म करना

वाहन संबंधित डिवाइस पर विज्ञापन लागू करना:

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

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

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

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

अगर Automotive डिवाइस में 64-बिट लागू होते हैं:

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

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

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

    • छोटी/सामान्य स्क्रीन पर 400 डीपीआई या उससे ज़्यादा
    • बड़ी स्क्रीन पर xhdpi या उससे ज़्यादा
    • ज़्यादा बड़ी स्क्रीन पर tvdpi या उसके बाद का वर्शन
  • [7.6.1/A-2-4] अगर इनमें से किसी भी डेंसिटी का इस्तेमाल किया जाता है, तो कर्नेल और यूज़रस्पेस के लिए उपलब्ध मेमोरी कम से कम 1824 एमबी होनी चाहिए:

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

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

वाहन संबंधित डिवाइस पर विज्ञापन लागू करना:

  • [7.7.1/A] इसमें ऐसा यूएसबी पोर्ट होना चाहिए जो सहायक डिवाइस (जैसे, कीबोर्ड, माउस, मॉनिटर, वेबकैम वगैरह) मोड के साथ काम करता हो.

वाहन संबंधित डिवाइस पर विज्ञापन लागू करना:

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

वाहन संबंधित डिवाइस पर विज्ञापन लागू करना:

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

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

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

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

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

  • [5.2/A-0-1] H.264 एवीसी
  • [5.2/A-0-2] VP8

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

  • [5.3/A-0-1] H.264 एवीसी
  • [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 एचईवीसी

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.* नामस्पेस में सभी सार्वजनिक एपीआई के साथ काम करना ज़रूरी है.

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

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

वाहन संबंधित डिवाइस पर विज्ञापन लागू करना:

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

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

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

नई ज़रूरी शर्तें लागू करें

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

नई ज़रूरी शर्तें खत्म करना

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

  • [3.8.4/A-SR-1] असिस्टेड ऐक्शन को मैनेज करने के लिए, डिवाइस पर Assistant का इस्तेमाल करने का कड़ाई से सुझाव दिया जाता है.

अगर Automotive डिवाइस में पुश-टू-टॉक बटन शामिल है, तो ये:

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

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

वाहन संबंधित डिवाइस पर विज्ञापन लागू करना:

  • [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] हर प्रोसेस के यूआईडी के हिसाब से, डेटा को नॉन-वोलेटाइल स्टोरेज में पढ़े गए और लिखे गए बाइट की संख्या बताना ज़रूरी है. इससे डेवलपर को सिस्टम एपीआई की मदद से आंकड़े उपलब्ध कराए जाते हैंandroid.car.storagemonitoring.CarStorageMonitoringManager. Android OpenSource प्रोजेक्ट ने uid_sys_stats कर्नेल मॉड्यूल की ज़रूरी शर्तें पूरी की हैं.
  • [8.3/A-1-3] गराज मोड की सुविधा काम करनी चाहिए.
  • [8.3/A] हर ड्राइव के बाद, कम से कम 15 मिनट तक गराज मोड में रहना चाहिए, बशर्ते:
    • बैटरी खत्म हो गई है.
    • कुछ समय से इस्तेमाल में न होने पर, कोई जॉब शेड्यूल नहीं किया जाता.
    • ड्राइवर गराज मोड से बाहर निकल जाता है.
  • [8.4/A-0-1] हर कॉम्पोनेंट के लिए पावर प्रोफ़ाइल देना ज़रूरी है. यह प्रोफ़ाइल हर हार्डवेयर कॉम्पोनेंट के लिए मौजूदा इस्तेमाल की वैल्यू के बारे में बताती है. साथ ही, इस बारे में भी जानकारी देती है कि समय के साथ कॉम्पोनेंट की वजह से बैटरी कितनी तेज़ी से खर्च होती है. इस बारे में Android ओपन सोर्स प्रोजेक्ट की साइट में बताया गया है.
  • [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. सुरक्षा मॉडल

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

नई ज़रूरी शर्तें लागू करें

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

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

नई ज़रूरी शर्तें खत्म करना

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

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

नई ज़रूरी शर्तें लागू करें

  • [9.8.2/A-2-3] लोगों को Settings ऐप्लिकेशन में कैमरा टॉगल करने की सुविधा देनी होगी.
  • [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, SHA1, और SHA-2 फ़ैमिली हैश फ़ंक्शन लागू करने ज़रूरी हैं, ताकि Android कीस्टोर सिस्टम के काम करने वाले एल्गोरिदम उस जगह पर सही तरीके से काम कर सकें जिसे कर्नेल और उसके बाद वाले कोड पर चलने वाले कोड से सुरक्षित तरीके से अलग किया गया है. सिक्योर आइसोलेशन से उन सभी संभावित मैकेनिज़्म को ब्लॉक कर देना चाहिए जिनकी मदद से कर्नेल या यूज़रस्पेस कोड, डीएमए के साथ-साथ आइसोलेटेड एनवायरमेंट की अंदरूनी स्थिति को ऐक्सेस कर सकते हैं. अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट (एओएसपी), Trusty लागू करने की सुविधा का इस्तेमाल करके इस ज़रूरी शर्त को पूरा करता है. हालांकि, ARM TrustZone पर आधारित कोई दूसरा ARM TrustZone समाधान या किसी तीसरे पक्ष के समीक्षा किए गए सुरक्षित तरीके से लागू करने के विकल्प, अन्य विकल्प हैं.
  • [9.11/A-0-3] लॉक स्क्रीन की पुष्टि करने की प्रक्रिया, एक-दूसरे से कनेक्ट किए बिना करना ज़रूरी है. साथ ही, पुष्टि करने की प्रक्रिया पूरी होने पर ही, पुष्टि करने वाली कुंजियों का इस्तेमाल करने की अनुमति दें. लॉक स्क्रीन के क्रेडेंशियल को इस तरह से सेव किया जाना चाहिए कि लॉक स्क्रीन पर पुष्टि करने के लिए, सिर्फ़ अलग-अलग एनवायरमेंट को ऐक्सेस किया जा सके. अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट, गेटकीपर हार्डवेयर ऐब्स्ट्रैक्शन लेयर (HAL) और ट्रस्टी उपलब्ध कराता है. इनका इस्तेमाल इस ज़रूरी शर्त को पूरा करने के लिए किया जा सकता है.
  • [9.11/A-0-4] कुंजी को प्रमाणित करने की सुविधा दी जानी चाहिए, जहां पुष्टि करने वाली कुंजी को सुरक्षित हार्डवेयर से सुरक्षित किया गया हो और सुरक्षित हार्डवेयर में हस्ताक्षर किया जाता हो. पुष्टि करने के लिए इस्तेमाल होने वाली कुंजियों को कई डिवाइसों के साथ शेयर करना ज़रूरी है, ताकि इनका इस्तेमाल डिवाइस आइडेंटिफ़ायर के तौर पर न किया जा सके. इस ज़रूरी शर्त को पूरा करने का एक तरीका यह है कि पुष्टि करने वाली एक ही कुंजी शेयर की जाए. ऐसा तब तक किया जा सकता है, जब तक किसी 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. डेवलपर टूल और विकल्पों के साथ काम करने की सुविधा

वाहन संबंधित डिवाइस पर विज्ञापन लागू करना:

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

2.6. टैबलेट की आवश्यकताएं

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

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

  • स्क्रीन डिसप्ले का साइज़ 7” और 18" से कम हो, जिसे डायगनल तरीके से मापा गया हो.

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

2.6.1. हार्डवेयर

जाइरोस्कोप

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

  • [7.3.4/Tab-1-1] स्क्रीन की दिशा को मापने की क्षमता होनी चाहिए. यह 1,000 डिग्री प्रति सेकंड तक बदल सकता है.

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

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

यूएसबी सहायक डिवाइस (जैसे, कीबोर्ड, माउस, मॉनिटर, वेबकैम वगैरह) मोड (सेक्शन 7.7.1)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

डिवाइस पर यह सुविधा लागू करना:

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

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

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

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

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

  • [C-0-6] आपको गैर-SDK टूल के हर इंटरफ़ेस को एक ही प्रतिबंधित सूचियों में शामिल करना होगा, जैसा कि prebuilts/runtime/appcompat/hiddenapi-flags.csv पाथ में अस्थायी और ब्लॉकलिस्ट फ़्लैग के ज़रिए बताया गया है. यह एओएसपी में एपीआई लेवल की सही ब्रांच के लिए, पाथ में होना चाहिए.

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

    हालांकि, वे:

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

नई ज़रूरी शर्तें लागू करें

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

नई ज़रूरी शर्तें खत्म करना

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

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

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

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

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

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

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

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

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

एओएसपी को लागू करने की प्रक्रिया, इन ज़रूरी शर्तों को पूरा करती है.

3.2. सॉफ़्ट एपीआई के साथ काम करने की सुविधा

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

3.2.1. अनुमतियां

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

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

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

  • [C-0-1] डिवाइस पर लागू करने के लिए एक जैसी और सही वैल्यू देने के लिए, नीचे दी गई टेबल में इन वैल्यू के फ़ॉर्मैट पर अतिरिक्त पाबंदियां दी गई हैं. इन वैल्यू के हिसाब से डिवाइस को लागू करना ज़रूरी है.
पैरामीटर जानकारी
वर्शन.रिलीज़ मौजूदा समय में लागू होने वाले Android सिस्टम का वर्शन. यह ऐसे फ़ॉर्मैट में होना चाहिए जिसे कोई भी व्यक्ति आसानी से पढ़ सके. इस फ़ील्ड में, Android 14 के लिए अनुमति वाले वर्शन स्ट्रिंग में बताई गई स्ट्रिंग की वैल्यू में से कोई एक होनी चाहिए.
वर्शन.SDK मौजूदा समय में लागू Android सिस्टम का वर्शन, जो तीसरे पक्ष के ऐप्लिकेशन कोड से ऐक्सेस किए जा सकने वाले फ़ॉर्मैट में हो. Android 14 के लिए, इस फ़ील्ड में पूर्णांक वैल्यू 14_INT होनी चाहिए.
वर्शन.SDK_INT मौजूदा समय में लागू Android सिस्टम का वर्शन, जो तीसरे पक्ष के ऐप्लिकेशन कोड से ऐक्सेस किए जा सकने वाले फ़ॉर्मैट में हो. Android 14 के लिए, इस फ़ील्ड में पूर्णांक वैल्यू 14_INT होनी चाहिए.
वर्शन.इंक्रीमेंटल डिवाइस लागू करने वाले की ओर से चुनी गई वैल्यू, जो फ़िलहाल इस्तेमाल किए जा रहे Android सिस्टम के खास बिल्ड की जानकारी देती है. इस वैल्यू को कोई भी व्यक्ति आसानी से पढ़ सकता है. असली उपयोगकर्ताओं के लिए उपलब्ध कराए गए अलग-अलग बिल्ड के लिए, इस वैल्यू का फिर से इस्तेमाल नहीं किया जाना चाहिए. इस फ़ील्ड का आम तौर पर इस्तेमाल यह बताने के लिए किया जाता है कि बिल्ड जनरेट करने के लिए किस बिल्ड नंबर या सोर्स-कंट्रोल के बदलाव वाले आइडेंटिफ़ायर का इस्तेमाल किया गया था. इस फ़ील्ड की वैल्यू को प्रिंट किए जा सकने वाले 7-बिट ASCII के तौर पर एन्कोड करना होगा और रेगुलर एक्सप्रेशन “^[^ :\/~]+$” से मैच होना चाहिए.
बोर्ड डिवाइस के अंदरूनी हार्डवेयर की पहचान करने के लिए, डिवाइस लागू करने वाले की ओर से चुनी गई वैल्यू. इस तरह की वैल्यू, डिवाइस के उस फ़ॉर्मैट में होती है जिसे कोई भी व्यक्ति आसानी से पढ़ सकता है. इस फ़ील्ड का इस्तेमाल, डिवाइस को चलाने वाले बोर्ड के खास संशोधन के बारे में बताने के लिए किया जा सकता है. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जाना चाहिए और रेगुलर एक्सप्रेशन “^[a-zA-Z0-9_-]+$” से मेल खाना चाहिए.
ब्रैंड डिवाइस से जुड़े ब्रैंड का नाम दिखाने वाली वैल्यू, जो असली उपयोगकर्ता के पास होती है. यह फ़ॉर्मैट, ऐसे फ़ॉर्मैट में होना चाहिए जिसे कोई भी व्यक्ति आसानी से पढ़ सके. साथ ही, यह डिवाइस के मैन्युफ़ैक्चरर या उस कंपनी के ब्रैंड का नाम होना चाहिए जिसके तहत डिवाइस को बेचा जाता है. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जाना चाहिए और रेगुलर एक्सप्रेशन “^[a-zA-Z0-9_-]+$” से मेल खाना चाहिए.
SUPPORTED_ABIS नेटिव कोड के निर्देश सेट (सीपीयू टाइप + एबीआई कन्वेंशन) का नाम. सेक्शन 3.3 देखें. नेटिव एपीआई के साथ काम करने की सुविधा.
SUPPORTED_32_BIT_ABIS नेटिव कोड के निर्देश सेट (सीपीयू टाइप + एबीआई कन्वेंशन) का नाम. सेक्शन 3.3 देखें. नेटिव एपीआई के साथ काम करने की सुविधा.
SUPPORTED_64_BIT_ABIS नेटिव कोड के दूसरे निर्देश सेट (सीपीयू टाइप + एबीआई कन्वेंशन) का नाम. सेक्शन 3.3 देखें. नेटिव एपीआई के साथ काम करने की सुविधा.
सीपीयू_एबीआई नेटिव कोड के निर्देश सेट (सीपीयू टाइप + एबीआई कन्वेंशन) का नाम. सेक्शन 3.3 देखें. नेटिव एपीआई के साथ काम करने की सुविधा.
सीपीयू (CPU_ABI2) नेटिव कोड के दूसरे निर्देश सेट (सीपीयू टाइप + एबीआई कन्वेंशन) का नाम. सेक्शन 3.3 देखें. नेटिव एपीआई के साथ काम करने की सुविधा.
डिवाइस डिवाइस लागू करने वाले की ओर से चुनी गई वैल्यू, जिसमें डेवलपमेंट नाम या कोड नाम शामिल होता है. यह वैल्यू, डिवाइस के हार्डवेयर की सुविधाओं के कॉन्फ़िगरेशन और डिवाइस के इंडस्ट्रियल डिज़ाइन के बारे में बताती है. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है और यह रेगुलर एक्सप्रेशन “^[a-zA-Z0-9_-]+$” से मेल खाना चाहिए. प्रॉडक्ट के लाइफ़टाइम में इस डिवाइस का नाम नहीं बदलना चाहिए.
फ़िंगरप्रिंट प्रिंट इस बिल्ड की खास तौर पर पहचान करने वाली स्ट्रिंग. यह ऐसा होना चाहिए जिसे कोई भी व्यक्ति आसानी से पढ़ सके. यह इस टेंप्लेट के हिसाब से होना चाहिए:

$(BRAND)/$(PRODUCT)/
$(DEVICE):$(VERSION.VERSION)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)

उदाहरण के लिए:

acme/myproduct/
mydevice:14/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) के कारोबार का नाम. इस फ़ील्ड के खास फ़ॉर्मैट के लिए कोई ज़रूरी शर्त नहीं है. हालांकि, यह शून्य या खाली स्ट्रिंग ("") नहीं होनी चाहिए. प्रॉडक्ट के लाइफ़टाइम में इस फ़ील्ड को नहीं बदलना चाहिए.
एसओसी_मैन्युफ़ैक्चरर प्रॉडक्ट में इस्तेमाल किए जाने वाले मुख्य सिस्टम ऑन चिप (एसओसी) के मैन्युफ़ैक्चरर के नाम का कारोबार. एक ही एसओसी मैन्युफ़ैक्चरर वाले डिवाइसों में, एक ही वैल्यू का इस्तेमाल करना चाहिए. कृपया एसओसी मैन्युफ़ैक्चरर से पूछें कि लगातार सही समय का इस्तेमाल कैसे करना है. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर कोड में बदलना चाहिए. साथ ही, इसे रेगुलर एक्सप्रेशन “^([0-9A-Za-z ]+)” से मैच होना चाहिए, इसकी शुरुआत या आखिर में खाली सफ़ेद जगह नहीं होनी चाहिए. यह वैल्यू “जानकारी नहीं है” के बराबर नहीं होनी चाहिए. यह फ़ील्ड, प्रॉडक्ट के लाइफ़टाइम में नहीं बदलना चाहिए.
एसओसी_मॉडल प्रॉडक्ट में इस्तेमाल की गई चिप (एसओसी) पर मौजूद प्राइमरी सिस्टम के मॉडल का नाम. एक जैसे एसओसी मॉडल वाले डिवाइसों में, एक ही कॉन्स्टेंट वैल्यू का इस्तेमाल किया जाना चाहिए. सही कॉन्स्टेंट इस्तेमाल करने के लिए, कृपया एसओसी मैन्युफ़ैक्चरर से पूछें. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है और रेगुलर एक्सप्रेशन “^([0-9A-Za-z ._/+-]+)$” से मेल खाना चाहिए. इसके शुरू या खत्म होने के बाद खाली सफ़ेद जगह नहीं होनी चाहिए. यह वैल्यू "जानकारी नहीं है" के बराबर नहीं होनी चाहिए. प्रॉडक्ट के लाइफ़टाइम में इस फ़ील्ड को नहीं बदलना चाहिए.
MODEL डिवाइस लागू करने वाले की ओर से चुनी गई वैल्यू, जिसमें डिवाइस का वह नाम होता है जो असली उपयोगकर्ता के पास होता है. यह वही नाम होना चाहिए जिसके तहत डिवाइस की मार्केटिंग की जाती है और असली उपयोगकर्ताओं को बेचा जाता है. इस फ़ील्ड के फ़ॉर्मैट के लिए कोई ज़रूरी शर्त नहीं है. हालांकि, यह ज़रूरी नहीं है कि इसमें शून्य या खाली स्ट्रिंग ("") न हो. प्रॉडक्ट के लाइफ़टाइम में इस फ़ील्ड को नहीं बदलना चाहिए.
प्रॉडक्ट डिवाइस लागू करने वाले की ओर से चुनी गई वैल्यू, जिसमें खास प्रॉडक्ट (SKU) के डेवलपमेंट नाम या कोड का नाम शामिल हो और वह उसी ब्रैंड का यूनीक होना चाहिए. वीडियो ऐसे होने चाहिए जिन्हें लोग आसानी से पढ़ सकें. हालांकि, यह ज़रूरी नहीं है कि असली उपयोगकर्ता इसे देख पाएं. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जाना चाहिए और रेगुलर एक्सप्रेशन “^[a-zA-Z0-9_-]+$” से मेल खाना चाहिए. प्रॉडक्ट के लाइफ़टाइम में इस प्रॉडक्ट का नाम नहीं बदलना चाहिए.
ओडीएम_एसकेयू डिवाइस लागू करने वाले की ओर से चुनी गई एक वैकल्पिक वैल्यू, जिसमें SKU (स्टॉक कीपिंग यूनिट) शामिल है. इसका इस्तेमाल, डिवाइस के खास कॉन्फ़िगरेशन को ट्रैक करने के लिए किया जाता है. उदाहरण के लिए, डिवाइस के बेचे जाने के दौरान, उसके साथ काम करने वाले सहायक डिवाइस (जैसे, कीबोर्ड, माउस, मॉनिटर, वेबकैम वगैरह). इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जाना चाहिए और रेगुलर एक्सप्रेशन “[0-9A-Za-z.,_-])" से मेल खाना चाहिए"
सीरियल "UNKNOWN" होना चाहिए.
टैग डिवाइस लागू करने वाले की ओर से चुनी गई टैग की एक कॉमा-सेपरेटेड लिस्ट, जो बिल्ड को और भी अलग करती है. टैग को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है और ये रेगुलर एक्सप्रेशन “^[a-zA-Z0-9._-]+” से मेल खाने चाहिए. साथ ही, इनमें तीन सामान्य Android प्लैटफ़ॉर्म के साइनिंग कॉन्फ़िगरेशन की वैल्यू में से कोई एक होनी चाहिए: रिलीज़-की, डेव-की, और टेस्ट-की.
समय बिल्ड कब हुआ था, इसके टाइमस्टैंप को दिखाने वाली वैल्यू.
वाई-फ़ाई के टाइप के बारे में जानकारी यह वैल्यू, डिवाइस लागू करने वाले की ओर से चुनी गई होती है. इससे बिल्ड के रनटाइम कॉन्फ़िगरेशन के बारे में पता चलता है. इस फ़ील्ड में, Android रनटाइम के तीन सामान्य कॉन्फ़िगरेशन से जुड़ी वैल्यू में से कोई एक वैल्यू होनी चाहिए: user, userdebug या eng.
उपयोगकर्ता उस उपयोगकर्ता (या अपने-आप काम करने वाले उपयोगकर्ता) का नाम या यूज़र आईडी जिससे बिल्ड जनरेट हुआ था. इस फ़ील्ड के खास फ़ॉर्मैट के लिए कोई ज़रूरी शर्त नहीं है, बस यह ज़रूरी है कि यह शून्य या खाली स्ट्रिंग ("") न हो.
सुरक्षा_पैच बिल्ड के सिक्योरिटी पैच लेवल को दिखाने वाली वैल्यू. इसमें यह भी बताया जाना चाहिए कि इस बिल्ड में मौजूद समस्याओं से, किसी भी तरह से ख़तरे में कोई समस्या नहीं है जिसके बारे में Android के पब्लिक सिक्योरिटी बुलेटिन में बताया गया है. यह [YYYY-MM-DD] फ़ॉर्मैट में होना चाहिए. यह बताई गई स्ट्रिंग से मेल खानी चाहिए. यह Android के सार्वजनिक सुरक्षा बुलेटिन या Android सुरक्षा सलाह में बताई गई है, जैसे कि "2015-11-01".
BASE_OS बिल्ड के FINGERprint पैरामीटर को दिखाने वाला मान, जो Android Public Security बुलेटिन में दिए गए पैच को छोड़कर इस बिल्ड के जैसा होता है. इसमें सही वैल्यू की जानकारी होनी चाहिए. अगर ऐसा कोई बिल्ड मौजूद नहीं है, तो खाली स्ट्रिंग ("") की शिकायत करें.
बूटलोडर डिवाइस लागू करने वाले की ओर से चुनी गई वैल्यू, जो डिवाइस में इस्तेमाल किए जा रहे बूटलोडर के खास वर्शन की पहचान करती है. यह वैल्यू ऐसे फ़ॉर्मैट में होती है जिसे कोई भी व्यक्ति आसानी से पढ़ सकता है. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जाना चाहिए और रेगुलर एक्सप्रेशन “^[a-zA-Z0-9._-]+$” से मेल खाना चाहिए.
getRadioVersion() डिवाइस लागू करने वाले की ओर से चुनी गई वैल्यू (होनी या वापस करनी) होनी चाहिए जो डिवाइस में इस्तेमाल किए जा रहे इंटरनल रेडियो/मॉडम के उस वर्शन की पहचान करे जिसे कोई भी व्यक्ति आसानी से पढ़ सके. अगर किसी डिवाइस में कोई इंटरनल रेडियो/मॉडम नहीं है, तो उसे शून्य करना होगा. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर एन्कोड किया जा सकता है और यह रेगुलर एक्सप्रेशन “^[a-zA-Z0-9._-,]+$” से मेल खाना चाहिए.
getSerial() एक हार्डवेयर सीरियल नंबर होना (होना चाहिए या वापस करना) होना चाहिए, जो एक ही MODEL और MANUFACTURER के साथ सभी डिवाइसों पर उपलब्ध और अलग-अलग होना चाहिए. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर कोड में बदला जा सकता है और यह रेगुलर एक्सप्रेशन “^[a-zA-Z0-9]+$” से मेल खाना चाहिए.

3.2.3. इंटेंट के साथ काम करना

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

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

डिवाइस पर यह सुविधा लागू करना:

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

हर डिवाइस टाइप के लिए ज़रूरी ऐप्लिकेशन इंटेंट देखने के लिए, कृपया सेक्शन 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 ओपन सोर्स प्रोजेक्ट में पैकेज मैनेजर लागू करता है.
  • [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 टूल के दस्तावेज़ में बैकग्राउंड ऐप्लिकेशन पर लागू होने वाली सीमा के बारे में भी बताया गया है. इसके अलावा, कुछ ब्रॉडकास्ट इंटेंट, हार्डवेयर के साथ काम करने के हिसाब से तय होते हैं. अगर डिवाइस के लिए ज़रूरी हार्डवेयर है, तो उसे इंटेंट को ब्रॉडकास्ट करना होगा और SDK टूल के दस्तावेज़ के हिसाब से व्यवहार की जानकारी देनी होगी.
3.2.3.5. शर्त के साथ ऐप्लिकेशन इंटेंट

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

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

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

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

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

  • [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.एनएफ़सी_PAYMENT_SETTINGS के इंटेंट का पालन करते हुए, टच किए बिना पैसे चुकाने के लिए डिफ़ॉल्ट ऐप्लिकेशन सेटिंग मेन्यू दिखाना ज़रूरी है.
  • [C-3-2] ऐसी गतिविधि दिखाने के लिए android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT के इंटेंट का पालन करना ज़रूरी है, जिससे एक डायलॉग बॉक्स खुलता है. इस डायलॉग में उपयोगकर्ता से किसी खास कैटगरी के लिए डिफ़ॉल्ट कार्ड एम्युलेशन सेवा को बदलने का अनुरोध किया जाता है, जैसा कि SDK में बताया गया है.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

अगर लागू किए गए डिवाइस ने android.software.autofill सुविधा फ़्लैग का एलान किया है, तो वे:

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

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

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

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

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

अगर डिवाइस लागू करने की प्रोसेस में, सेटिंग में AutoService_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 में इंटरैक्टिव स्क्रीनसेवर की सुविधा शामिल है, जिन्हें पहले Dreams कहा जाता था. जब पावर सोर्स से जुड़ा कोई डिवाइस इस्तेमाल में न हो या डेस्क डॉक में डॉक हो, तब स्क्रीन सेवर की मदद से उपयोगकर्ता, ऐप्लिकेशन से इंटरैक्ट कर सकते हैं. डिवाइस पर लागू करना:

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

नई ज़रूरी शर्तें लागू करें

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

नई ज़रूरी शर्तें खत्म करना

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 ओपन सोर्स प्रोजेक्ट से नीचे दी गई लाइब्रेरी लागू करने का सुझाव दिया जाता है.

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

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

डिवाइस पर यह सुविधा लागू करना:

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

    • armeabi (अब एनडीके से टारगेट के तौर पर काम नहीं करता)
    • armeabi-v7a
    • arm64-v8a
    • x86
    • x86-64
  • [C-0-7] नेटिव कोड वाले ऐप्लिकेशन के लिए, नेटिव एपीआई उपलब्ध कराते हुए इन सभी लाइब्रेरी को बनाना ज़रूरी है:

    • libaaudio.so (ऑडियो नेटिव ऑडियो सहायता)
    • libamidi.so (अगर सुविधा android.software.midi का दावा, सेक्शन 5.9 में बताए गए तरीके के मुताबिक किया जाता है, तो नेटिव एमआईडीआई की सुविधा)
    • 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 (न्यूरल नेटवर्क एपीआई)
    • libOpenMAXAL.so (OpenMAX AL 1.0.1 सहायता)
    • libOpenSLES.so (OpenSL ES 1.0.1 ऑडियो सहायता)
    • libRS.so
    • libstdc++ (C++ के लिए कम से कम काम)
    • libvulkan.so (Vulkan)
    • libz (Zlib कंप्रेशन)
    • जेएनआई इंटरफ़ेस
  • [C-0-8] ऊपर दी गई नेटिव लाइब्रेरी के लिए सार्वजनिक फ़ंक्शन को जोड़ना या हटाना ज़रूरी नहीं है.

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

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

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

  • [C-0-12] मुख्य Vulkan 1.0 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 ओपन सोर्स प्रोजेक्ट में उपलब्ध सोर्स कोड और हेडर फ़ाइलों का इस्तेमाल करके बनाया जाना चाहिए.

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

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

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

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

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

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

    • Features:, इसके बाद, इस डिवाइस पर काम करने वाली किसी भी ARMv7 सीपीयू सुविधाओं की सूची देनी होगी.
    • CPU architecture: को शामिल करने के बाद एक पूर्णांक जोड़ा जाता है. यह इंटीजर, डिवाइस के साथ काम करने वाले सबसे बेहतर ARM आर्किटेक्चर की जानकारी देता है (उदाहरण के लिए, ARMv8 डिवाइसों के लिए, "8").
  • [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 14 ब्रांच पर मौजूद अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट से Chromium प्रोजेक्ट बिल्ड का इस्तेमाल करना ज़रूरी है.
  • [C-1-3] वेबव्यू से रिपोर्ट की गई उपयोगकर्ता एजेंट स्ट्रिंग इस फ़ॉर्मैट में होनी चाहिए:

    Mozilla/5.0 (Linux; Android $(VERSION); [$(MODEL)] [बिल्ड/$(BUILD)]; wv) AppleWebKit/537.36 (KHTML, जैसे Gecko) Version/4.0 $(CHROMIUM_VER) मोबाइल Safari/537.36

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

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

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

3.4.2. इन ब्राउज़र पर काम करता है

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

  • [C-1-1] HTML5 से जुड़े हर एपीआई के साथ काम करना चाहिए:
  • [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 ओपन सोर्स प्रोजेक्ट को लागू करने के पसंदीदा तरीके के हिसाब से होना चाहिए. साथ काम करने से जुड़ी कुछ बातों के बारे में नीचे बताया गया है:

  • [C-0-1] डिवाइस को किसी स्टैंडर्ड इंटेंट के व्यवहार या सिमेंटिक्स में बदलाव नहीं करना चाहिए.
  • [C-0-2] डिवाइसों को किसी खास तरह के सिस्टम कॉम्पोनेंट (जैसे कि सेवा, Activity, 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] अगर ऐप्लिकेशन ने insertProviderAt() या removeProvider() की मदद से सूची में बदलाव नहीं किया है, तो डिवाइसों को Security.getProviders() तरीके से, दिए गए क्रम और दिए गए नामों (जो Provider.getName() ने दिखाया है) और क्लास के साथ, इन सुरक्षा देने वालों को पहले सात वैल्यू के तौर पर दिखाना होगा. इन कंपनियों की नीचे दी गई सूची के बाद, डिवाइस दूसरी कंपनियां भी दिखा सकते हैं.
    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

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

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

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

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

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

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

  • [C-1-6] किसी ऐप्लिकेशन से किए जाने वाले एपीआई कॉल के लिए, ActivityManager.is background सीमित() तरीके का इस्तेमाल करने पर, यह वैल्यू 'सही' दिखनी चाहिए.

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

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

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

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

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

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

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

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

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

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

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

3.6. एपीआई नाम स्थान

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

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

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

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

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

  • [C-0-3] सार्वजनिक तौर पर सार्वजनिक किए गए किसी भी एपीआई के बताए गए व्यवहार और Java की भाषा में हस्ताक्षर पर असर नहीं डालना चाहिए.
  • [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] यह ज़रूरी है कि फ़ील्ड में, Delvik लिजेक्यूटेबल (DEX) फ़ॉर्मैट और Dalvik बाइट कोड स्पेसिफ़िकेशन और सिमैंटिक के हिसाब से काम किया गया हो.

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

  • आपको Android रनटाइम (ART) का इस्तेमाल करना चाहिए, जो डलास के एक्ज़िक्यूटेबल फ़ॉर्मैट को लागू करने के लिए रेफ़रंस अपस्ट्रीम का इस्तेमाल किया गया है और रेफ़रंस लागू करने के पैकेज मैनेजमेंट सिस्टम का इस्तेमाल किया गया है.

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

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

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

3.8. यूज़र इंटरफ़ेस के साथ काम करने की सुविधा

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

Android में लॉन्चर ऐप्लिकेशन (होम स्क्रीन) और डिवाइस लॉन्चर (होम स्क्रीन) को बदलने के लिए तृतीय-पक्ष ऐप्लिकेशन के लिए समर्थन शामिल है.

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

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

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

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

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

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

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

  • लॉक स्क्रीन पर ऐप्लिकेशन विजेट काम कर सकते हैं.

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

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

3.8.3. सूचनाएं

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

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

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

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

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

  • [C-SR-2] का बहुत ज़्यादा सुझाव दिया जाता है. इससे उपयोगकर्ता यह तय कर सकते हैं कि वे सूचना सुनने वाले किसी खास व्यक्ति को सूचना न देने वाले ऐप्लिकेशन न चुनें.

  • [C-SR-3] इस बात का खास तौर पर सुझाव दिया जाता है कि जब उपयोगकर्ता उस सूचना को कई बार खारिज कर दे, तो वह हर चैनल और ऐप्लिकेशन पैकेज लेवल के हिसाब से, किसी तीसरे पक्ष के ऐप्लिकेशन की सूचना को ब्लॉक करने के लिए, अपने-आप उपयोगकर्ता को उपलब्ध कराए.

  • इसमें रिच नोटिफ़िकेशन की सुविधा भी होनी चाहिए.

  • कुछ उच्च प्राथमिकता वाले नोटिफ़िकेशन को हेड-अप नोटिफ़िकेशन के रूप में दिखाया जाना चाहिए.

  • उपयोगकर्ता के पास, सूचनाएं स्नूज़ करने की सुविधा होनी चाहिए.

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

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

डिवाइस पर यह सुविधा लागू करना:

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

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

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

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

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

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

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

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

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

3.8.4. Assist API से

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

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

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

3.8.5. अलर्ट और टोस्ट

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

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

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

  • [C-1-2] Toast API का इस्तेमाल करते हुए असली उपयोगकर्ताओं को ऐप्लिकेशन के टोस्ट दिखाएं.

3.8.6. थीम

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

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

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

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

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

  • [C-1-5] Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES वाले दस्तावेज़ (android.theme.customization.theme_styles देखें) में बताए गए कलर थीम स्टाइल का इस्तेमाल करके, डाइनैमिक कलर टोनल पैलेट जनरेट करना ज़रूरी है (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_wallP.

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.software.input_methods और Android SDK के दस्तावेज़ में दी गई जानकारी के मुताबिक, IME API के साथ काम करना.

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

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

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

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

3.8.12. जगह

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

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

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

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

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

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

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

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

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

  • [C-2-1] टेक्स्ट को यूनिकोड का पालन करने वाले फ़ॉन्ट को डिफ़ॉल्ट के तौर पर रेंडर करना ज़रूरी है; बिना यूनिकोड का पालन करने वाले फ़ॉन्ट को तब तक डिफ़ॉल्ट फ़ॉन्ट के तौर पर सेट नहीं किया जाना चाहिए, जब तक उपयोगकर्ता उसे लैंग्वेज पिकर में नहीं चुनता.
  • [C-2-2] अगर डिवाइस पर, बिना यूनिकोड का पालन करने वाला फ़ॉन्ट काम करता है, तो यूनिकोड फ़ॉन्ट और यूनिकोड का पालन न करने वाले फ़ॉन्ट के साथ काम करना ज़रूरी है. यूनिकोड का पालन न करने वाले फ़ॉन्ट को यूनिकोड फ़ॉन्ट को हटाना या ओवरराइट नहीं करना चाहिए.
  • [C-2-3] सिर्फ़ यूनिकोड का पालन करने वाले फ़ॉन्ट वाले टेक्स्ट को रेंडर करना ज़रूरी है, बशर्ते स्क्रिप्ट कोड Qaag वाली भाषा का कोड दिया गया हो (जैसे कि my-Qaag). म्यांमार के लिए किसी भी दूसरे ISO भाषा या क्षेत्र कोड (चाहे असाइन किए गए, असाइन नहीं किए गए या रिज़र्व किए गए) का इस्तेमाल नहीं करने वाले फ़ॉन्ट का उल्लेख करने के लिए नहीं किया जा सकता. ऐप्लिकेशन डेवलपर और वेब पेज के लेखक my-Qag को भाषा कोड के तौर पर तय कर सकते हैं, जैसा कि वे किसी दूसरी भाषा में करते हैं.

3.8.14. मल्टी-विंडो

अगर लागू किए गए डिवाइस में एक साथ कई गतिविधियां दिखाने की सुविधा है, तो:

  • [C-1-1] Android SDK के मल्टी-विंडो मोड से जुड़े सहायता दस्तावेज़ में बताए गए ऐप्लिकेशन के व्यवहार और एपीआई के हिसाब से, इस तरह के मल्टी-विंडो मोड को लागू करना ज़रूरी है. साथ ही, इन मोड को इन ज़रूरी शर्तों को पूरा करना होगा:
  • [C-1-2] android:resizeableActivity के मुताबिक होना चाहिए, जो AndroidManifest.xml फ़ाइल में किसी ऐप्लिकेशन ने इस SDK टूल में बताए गए तरीके के मुताबिक सेट किया है.
  • [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] अपने SystemUI में उन कार्रवाइयों को दिखाना ज़रूरी है जो setActions() एपीआई की मदद से, मौजूदा पीआईपी गतिविधि में बताई गई हैं.
  • [C-3-3] setAspectRatio() एपीआई की मदद से, पीआईपी गतिविधि के मुताबिक, आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) 1:2.39 और 2.39:1 के बराबर या इससे कम या इसके बराबर होना चाहिए.
  • [C-3-4] पीआईपी विंडो को कंट्रोल करने के लिए, KeyEvent.KEYCODE_WINDOW का इस्तेमाल करना ज़रूरी है. अगर पीआईपी मोड लागू नहीं है, तो फ़ोरग्राउंड में होने वाली गतिविधि के लिए पासकोड उपलब्ध होना चाहिए.
  • [C-3-5] उपयोगकर्ता को यह सुविधा देनी होगी कि वह किसी ऐप्लिकेशन को पीआईपी मोड में दिखने से ब्लॉक कर सके. एओएसपी को लागू करने की प्रोसेस, नोटिफ़िकेशन शेड में कंट्रोल के ज़रिए इस ज़रूरी शर्त को पूरा करती है.
  • [C-3-6] जब कोई ऐप्लिकेशन AndroidManifestLayout_minWidth और AndroidManifestLayout_minHeight के लिए कोई वैल्यू नहीं बताता है, तो पीआईपी विंडो में कम से कम चौड़ाई और ऊंचाई तय करना ज़रूरी है:

    • कॉन्फ़िगरेशन.uiMode वाले डिवाइस, जिन्हें UI_MODE_TYPE_TELEVISION के अलावा किसी दूसरे तरीके से सेट किया गया है उनमें कम से कम चौड़ाई और ऊंचाई 108 dp होनी चाहिए.
    • कॉन्फ़िगरेशन.uiMode वाले डिवाइस, जिन्हें UI_MODE_TYPE_TELEVISION पर सेट किया गया है उनके लिए यह ज़रूरी है कि उनकी चौड़ाई कम से कम 240 dp और ऊंचाई कम से कम 135 dp हो.

3.8.15. डिसप्ले कटआउट

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

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

  • [C-1-5] अगर डिवाइस का आसपेक्ट रेशियो(लंबाई-चौड़ाई का अनुपात) 1.0(1:1) है, तो कटआउट नहीं होने चाहिए.
  • [C-1-2] हर किनारे के लिए एक से ज़्यादा कटआउट नहीं होने चाहिए.
  • [C-1-3] WindowManager.LayoutParams एपीआई की मदद से ऐप्लिकेशन के सेट किए गए डिसप्ले कटआउट फ़्लैग के मुताबिक काम करना ज़रूरी है, जैसा कि SDK टूल में बताया गया है.
  • [C-1-4] DisplayCutout एपीआई में बताए गए सभी कटआउट मेट्रिक के लिए, सही वैल्यू की जानकारी देना ज़रूरी है.

3.8.16. डिवाइस कंट्रोल

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

डिवाइस से जुड़ी खास ज़रूरतों के बारे में जानने के लिए, सेक्शन 2_2_3 देखें.

3.8.17. क्लिपबोर्ड

डिवाइस पर यह सुविधा लागू करना:

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

अगर किसी डिवाइस पर लागू होने वाले किसी भी ClipData आइटम के कॉन्टेंट को क्लिपबोर्ड पर कॉपी किया जाता है और उस पर लागू होने वाले किसी डिवाइस की झलक, उपयोगकर्ता को दिखने लगती है, तो वे:ClipData.getDescription().getExtras()android.content.extra.IS_SENSITIVE

  • [C-1-1] लोगों को दिखने वाली झलक को छिपाने के लिए उसमें बदलाव करना ज़रूरी है

एओएसपी रेफ़रंस को लागू करने के लिए, क्लिपबोर्ड की इन ज़रूरी शर्तों को पूरा किया जाता है.

3.9. डिवाइस प्रबंधन

Android में ऐसी सुविधाएं शामिल हैं जो सुरक्षा की जानकारी देने वाले ऐप्लिकेशन को सिस्टम लेवल पर डिवाइस के एडमिन फ़ंक्शन करने देती हैं. जैसे, Android Device Administration API की मदद से पासवर्ड नीतियां लागू करना या रिमोट वाइप करना.

अगर डिवाइस लागू करने की सुविधा, 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] DPC ऐप्लिकेशन को डिवाइस के मालिक के ऐप्लिकेशन के रूप में रजिस्टर करना ज़रूरी है. अगर डिवाइस, फ़ीचर फ़्लैग android.hardware.nfc के ज़रिए नियर-फ़ील्ड कम्यूनिकेशन (एनएफ़सी) की सुविधा देता है और आपको MIME टाइप MIME_TYPE_PROVISIONING_NFC वाला एनएफ़सी मैसेज मिलता है, तो उसे डिवाइस का मालिक बनाया जाना है या प्रोफ़ाइल का मालिक बनाना है.
      • [C-1-8] डिवाइस के मालिक के प्रावधान के ट्रिगर होने के बाद, ACTION_GET_PROVISIONING_Mode इंटेंट भेजना ज़रूरी है. इससे DPC ऐप्लिकेशन यह तय कर सकेगा कि डिवाइस का मालिक बनना है या प्रोफ़ाइल का मालिक, जो android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES की वैल्यू के आधार पर तय किया जा सकता है. ऐसा तब तक किया जा सकता है, जब तक कि यह पता न चल पाए कि सिर्फ़ एक मान्य विकल्प मौजूद है.
      • [C-1-9] अगर डिवाइस का मालिक, प्रावधान करने के दौरान बनाया गया है, तो डिवाइस के मालिक ऐप्लिकेशन को ACTION_Admin_POLICY_COMPLIANCE इंटेंट भेजना ज़रूरी है. भले ही, प्रावधान करने के लिए किसी भी तरीके का इस्तेमाल किया गया हो. उपयोगकर्ता, सेटअप विज़र्ड में तब तक आगे नहीं बढ़ सकता, जब तक डिवाइस के मालिक का ऐप्लिकेशन काम नहीं करता.
    • जब लागू किए गए डिवाइस में उपयोगकर्ता या उपयोगकर्ता का डेटा होता है, तो:
      • [C-1-7] अब किसी भी DPC ऐप्लिकेशन को डिवाइस के मालिक के ऐप्लिकेशन के तौर पर रजिस्टर नहीं करना होगा.
  • [C-1-2] ऐप्लिकेशन को डिवाइस के मालिक के तौर पर सेट करने से पहले, असली उपयोगकर्ता से ज़रूरी सूचना ज़ाहिर करनी होगी. ऐसा एओएसपी में बताया गया है. साथ ही, असली उपयोगकर्ता के इंटरैक्शन से पहले, डिवाइस को रीटेल डेमो मोड के लिए प्रोग्राम के हिसाब से कॉन्फ़िगर करना होगा. हालांकि, ऐसा करने से पहले, असली उपयोगकर्ता से उसकी सहमति लेनी होगी. अगर डिवाइस को लागू करने के तरीके के बारे में android.software.device_admin बताया जाता है, लेकिन उसमें मालिकाना हक वाला डिवाइस मैनेजमेंट समाधान भी शामिल है और उनके समाधान में कॉन्फ़िगर किए गए ऐप्लिकेशन को प्रमोट करने का तरीका भी है, तो वे:

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

  • [C-2-2] डीपीसी ऐप्लिकेशन को "डिवाइस के मालिक" के तौर पर रजिस्टर करने से पहले, android.app.action.PROVISION_MANAGED_DEVICE ने जिस फ़्लो को शुरू किया था, एओएसपी डिवाइस के मालिक की सहमति की जानकारी दिखाना ज़रूरी है.

  • [C-2-3] सहमति को हार्ड कोड नहीं करना चाहिए या डिवाइस के मालिक के अन्य ऐप्लिकेशन के इस्तेमाल पर रोक नहीं लगानी चाहिए.

3.9.1.2 मैनेज की जा रही प्रोफ़ाइल का प्रावधान

अगर लागू किए गए डिवाइस पर android.software.managed_users का एलान किया जाता है, तो:

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

  • [C-1-2] मैनेज की जा रही प्रोफ़ाइल को उपलब्ध कराने की प्रोसेस (डीपीसी ने android.app.action.PROVISION_MANAGED_PROFILE का इस्तेमाल करके या प्लैटफ़ॉर्म से शुरू किया गया फ़्लो), सहमति स्क्रीन और उपयोगकर्ता अनुभव को एओएसपी लागू करने के तरीके के हिसाब से शुरू किया जाना चाहिए.

  • [C-1-3] डिवाइस पॉलिसी कंट्रोलर (DPC) की ओर से किसी खास सिस्टम फ़ंक्शन को बंद किए जाने पर, उपयोगकर्ता को उसके बारे में बताने के लिए, सेटिंग में नीचे दिए गए उपयोगकर्ता अधिकार देने होंगे:

    • जब डिवाइस एडमिन ने किसी खास सेटिंग पर पाबंदी लगाई होती है, तब एक जैसा आइकॉन या उपयोगकर्ता की अनुमतियों (जैसे, अपस्ट्रीम एओएसपी की जानकारी वाला आइकॉन) को दिखाया जाता है.
    • एक छोटा सा मैसेज, जो डिवाइस एडमिन ने setShortSupportMessage में दिया है.
    • DPC ऐप्लिकेशन का आइकॉन.
  • [C-1-4] अगर android.app.action.PROVISION_MANAGED_PROFILE के मकसद से प्रावधान शुरू किए जाते समय प्रोफ़ाइल का मालिक तय किया जाता है और DPC ने हैंडलर को लागू किया है, तो वर्क प्रोफ़ाइल में ACTION_PROVISIONING_ टिके रहने के लिए हैंडलर लॉन्च करना ज़रूरी है.

  • [C-1-5] android.app.action.PROVISION_MANAGED_PROFILE के इंटेंट से प्रावधान शुरू किए जाने पर, ACTION_PROFILE_PROVISIONING_complete ब्रॉडकास्ट करना ज़रूरी है.

  • [C-1-6] प्रोफ़ाइल मालिक के प्रावधान के ट्रिगर होने के बाद, DPC ऐप्लिकेशन को ACTION_GET_PROVISIONING_mode इंटेंट भेजना ज़रूरी है. इससे DPC ऐप्लिकेशन यह चुन सकता है कि डिवाइस का मालिक बनना है या प्रोफ़ाइल का मालिक. हालांकि, android.app.action.PROVISION_MANAGED_PROFILE इंटेंट के ज़रिए प्रावधान शुरू किए जाने पर ऐसा नहीं होगा.

  • [C-1-7] प्रावधान के दौरान प्रोफ़ाइल का मालिक बनाए जाने पर, उस प्रोफ़ाइल पर ACTION_Admin_POLICY_COMPLIANCE का इंटेंट भेजना ज़रूरी है. इससे कोई फ़र्क़ नहीं पड़ता कि प्रावधान करने के किस तरीके का इस्तेमाल किया गया है. हालांकि, android.app.action.PROVISION_MANAGED_PROFILE इंटेंट से प्रावधान शुरू होने पर ऐसा किया जा सकता है. जब तक प्रोफ़ाइल के मालिक का ऐप्लिकेशन पूरा नहीं हो जाता, तब तक उपयोगकर्ता को सेटअप विज़र्ड में आगे की कार्रवाई नहीं करनी चाहिए.

  • [C-1-8] प्रोफ़ाइल के मालिक के तौर पर काम करने के दौरान, निजी प्रोफ़ाइल DPC पर ACTION_MANAGED_PROFILE_PROVISIONED ब्रॉडकास्ट भेजना ज़रूरी है. भले ही, प्रावधान करने के लिए किसी भी तरीके का इस्तेमाल किया गया हो.

3.9.2 मैनेज की जा रही प्रोफ़ाइल के लिए सहायता

अगर लागू किए गए डिवाइस पर android.software.managed_users का एलान किया जाता है, तो:

  • [C-1-1] android.app.admin.DevicePolicyManager एपीआई का इस्तेमाल करके, मैनेज की जा रही प्रोफ़ाइलों के साथ काम करना ज़रूरी है.
  • [C-1-2] सिर्फ़ एक या सिर्फ़ मैनेज की जा रही एक प्रोफ़ाइल बनाने की अनुमति होनी चाहिए.
  • [C-1-3] मैनेज किए गए ऐप्लिकेशन और विजेट के साथ-साथ हाल ही के और सूचनाएं जैसे बैज वाले अन्य यूज़र इंटरफ़ेस (यूआई) एलिमेंट दिखाने के लिए, आइकॉन बैज (एओएसपी अपस्ट्रीम वर्क बैज की तरह) का इस्तेमाल करना ज़रूरी है.
  • [C-1-4] उपयोगकर्ता को, मैनेज किए जा रहे प्रोफ़ाइल ऐप्लिकेशन का इस्तेमाल करने का समय बताने के लिए, सूचना का आइकॉन (एओएसपी अपस्ट्रीम वर्क बैज की तरह) दिखाना ज़रूरी है.
  • [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 ओपन सोर्स प्रोजेक्ट साइट पर किया गया है.
    • डीपीसी पासवर्ड की नीतियां, सिर्फ़ मैनेज की जा रही प्रोफ़ाइल की लॉक स्क्रीन पर लागू होने वाले क्रेडेंशियल पर लागू होनी चाहिए. ऐसा तब तक होना चाहिए, जब तक getParentProfileInstance की ओर से दिए गए DevicePolicyManager इंस्टेंस को शामिल न किया जाए.
  • जब मैनेज की जा रही प्रोफ़ाइल के संपर्क, पहले से इंस्टॉल किए गए कॉल लॉग, कॉल के दौरान यूज़र इंटरफ़ेस (यूआई), जारी है और मिस्ड कॉल की सूचनाओं, संपर्क, और मैसेजिंग ऐप्लिकेशन में दिखते हैं, तो उन्हें उसी बैज वाले बैज के साथ दिखाया जाना चाहिए जो मैनेज किए जा रहे प्रोफ़ाइल ऐप्लिकेशन के लिए इस्तेमाल होता है.

3.9.3 प्रबंधित उपयोगकर्ता सहायता

अगर लागू किए गए डिवाइस पर android.software.managed_users का एलान किया जाता है, तो:

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

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

  • [सी-एसआर-1] का सुझाव दिया जाता है कि नए सेकंडरी उपयोगकर्ता में खातों को जोड़ने की अनुमति देने से पहले, एओएसपी डिवाइस के मालिक की सहमति की जानकारी दिखाएं. यह जानकारी 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 की रिपोर्ट करते हैं, तो वे:

नई ज़रूरी शर्तें खत्म करना

3.10. सुलभता

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

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

  • [C-1-1] सुलभता एपीआई SDK टूल के दस्तावेज़ में बताए गए Android के सुलभता फ़्रेमवर्क को लागू करना ज़रूरी है.
  • [C-1-2] सुलभता इवेंट जनरेट करना और SDK टूल में दर्ज सभी AccessibilityService लागू करने के सही तरीकों के हिसाब से AccessibilityEvent डिलीवर करना ज़रूरी है.
  • [C-1-4] लोगों को उन सुलभता सेवाओं को कंट्रोल करने का अधिकार देना ज़रूरी है जो AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON का एलान करती हैं. ध्यान दें कि सिस्टम नेविगेशन बार की मदद से डिवाइस लागू करने पर, उपयोगकर्ताओं को इन सेवाओं को कंट्रोल करने के लिए सिस्टम के नेविगेशन बार में दिए गए बटन का विकल्प देना चाहिए.

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

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

3.11. लिखे गए शब्दों को सुनने की सुविधा

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

अगर डिवाइस लागू करने की प्रोसेस में android.hardware.audio.आउट सुविधा की रिपोर्ट की जाती है, तो वे:

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

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

3.12. टीवी इनपुट फ़्रेमवर्क

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

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

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

3.13. फटाफट सेटिंग

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

अगर डिवाइस लागू करने के तरीके में क्विक सेटिंग यूज़र इंटरफ़ेस (यूआई) कॉम्पोनेंट शामिल है और तीसरे पक्ष की क्विक सेटिंग काम करती है, तो ये:

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

3.14. मीडिया यूज़र इंटरफ़ेस (यूआई)

अगर डिवाइस पर, आवाज़ से चालू किए गए ऐसे ऐप्लिकेशन (ऐप्लिकेशन) शामिल हैं जो MediaBrowser या MediaSession के ज़रिए, तीसरे पक्ष के ऐप्लिकेशन के साथ इंटरैक्ट करते हैं, तो:

  • [C-1-2] आपको getIconBitmap() या getIconUri() से मिले आइकॉन और getTitle() से मिले टाइटल को साफ़ तौर पर दिखाना ज़रूरी है. इसके बारे में MediaDescription में बताया गया है. सुरक्षा के कानूनों का पालन करने के लिए, टाइटल को छोटा कर सकता है. जैसे, ड्राइवर का ध्यान भटकाना.

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

    • [C-1-5] लोगों को हर ऐप्लिकेशन पैकेज के लिए लोकल कैश मेमोरी में सेव किए गए 'इंस्टैंट ऐप्लिकेशन' देखने और उन्हें मिटाने का विकल्प देना ज़रूरी है.
    • [C-1-6] उपयोगकर्ता को एक स्थायी सूचना देनी ज़रूरी है, जिस समय फ़ोरग्राउंड में कोई इंस्टैंट ऐप्लिकेशन चल रहा हो, उसे छोटा किया जा सकता हो. उपयोगकर्ता की इस सूचना में यह जानकारी शामिल होनी चाहिए कि इंस्टैंट ऐप्लिकेशन के लिए इंस्टॉल करने की ज़रूरत नहीं होती है. साथ ही, उसे इस्तेमाल करने का वह अधिकार भी देना चाहिए जो उपयोगकर्ता को सेटिंग में ऐप्लिकेशन की जानकारी वाली स्क्रीन पर ले जाता हो. Intent.ACTION_VIEW पर सेट की गई कार्रवाई वाले इंटेंट का इस्तेमाल करके और "http" या "https" स्कीम के साथ, तय किए गए इंस्टैंट ऐप्लिकेशन के लिए, उपयोगकर्ता को इंस्टैंट ऐप्लिकेशन लॉन्च नहीं करना चाहिए और अगर डिवाइस पर ब्राउज़र उपलब्ध है, तो कॉन्फ़िगर किए गए वेब ब्राउज़र से लिंक को लॉन्च नहीं करना चाहिए.
    • [C-1-7] अगर डिवाइस में 'हाल ही के' फ़ंक्शन उपलब्ध है, तो 'हाल ही के' फ़ंक्शन से 'इंस्टैंट ऐप्लिकेशन' को ऐक्सेस करने की अनुमति देना ज़रूरी है.
  • [C-1-8] यहां SDK टूल में लिस्ट किए गए इंटेंट के लिए, इंटेंट हैंडलर के साथ एक या उससे ज़्यादा ऐप्लिकेशन या सेवा कॉम्पोनेंट को पहले से लोड करना होगा और इंटेंट को इंस्टैंट ऐप्लिकेशन के लिए दिखाना होगा.

3.16. कंपैनियन डिवाइस को दूसरे डिवाइस से जोड़ना

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

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

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

3.17. हैवीवेट ऐप्लिकेशन

अगर लागू किए गए डिवाइस पर FEATURE_CANT_SAVE_STATE सुविधा का एलान किया गया है, तो:

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

अगर लागू किए गए डिवाइस पर इस सुविधा FEATURE_CANT_SAVE_STATE का एलान नहीं किया जाता है, तो:

  • [C-1-1] ऐप्लिकेशन के सेट किए गए cantSaveState एट्रिब्यूट को अनदेखा करना चाहिए और उस एट्रिब्यूट के आधार पर, ऐप्लिकेशन के काम करने के तरीके में बदलाव नहीं करना चाहिए.

3.18. संपर्क

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

RawContacts, खाते से "जुड़े" या "में स्टोर" होते हैं. ऐसा तब होता है, जब ACCOUNT_NAME और ACCOUNT_TYPE रॉ संपर्कों के कॉलम, खाते के Account.name और Account.type फ़ील्ड से मेल खाते हैं.

डिफ़ॉल्ट लोकल खाता: ऐसे रॉ संपर्कों का खाता जो सिर्फ़ डिवाइस पर सेव होते हैं और AccountManager में किसी खाते से नहीं जुड़े होते हैं. इन्हें ACCOUNT_NAME और ACCOUNT_TYPE कॉलम के लिए शून्य वैल्यू के साथ बनाया जाता है.

कस्टम लोकल खाता: ऐसे रॉ संपर्कों का खाता जो सिर्फ़ डिवाइस पर सेव होते हैं और खाता मैनेजर के किसी खाते से नहीं जुड़े होते हैं. इन संपर्कों को ACCOUNT_NAME और ACCOUNT_TYPE कॉलम के लिए कम से कम एक ऐसी वैल्यू का इस्तेमाल करके बनाया जाता है जो शून्य न हो.

डिवाइस पर यह सुविधा लागू करना:

  • [C-SR-1] पसंद के मुताबिक स्थानीय खाते न बनाने के लिए, इस बात पर ज़ोर दिया जाता है.

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

  • [C-1-1] पसंद के मुताबिक बनाए गए स्थानीय खाते का ACCOUNT_NAME, ContactsContract.RawContacts.getLocalAccountName से लौटाया जाना चाहिए
  • [C-1-2] पसंद के मुताबिक बनाए गए स्थानीय खाते का ACCOUNT_TYPE, ContactsContract.RawContacts.getLocalAccountType से लौटाया जाना चाहिए
  • [C-1-3] डिफ़ॉल्ट स्थानीय खाते वाले तीसरे पक्ष के ऐप्लिकेशन से डाले गए रॉ संपर्क (उदाहरण के लिए, ACCOUNT_NAME और ACCOUNT_TYPE के लिए शून्य वैल्यू सेट करके) पसंद के मुताबिक स्थानीय खाते में डाले जाने चाहिए.
  • [C-1-4] पसंद के मुताबिक बनाए गए स्थानीय खाते में डाले गए रॉ संपर्क को खाते जोड़ने या हटाने पर, उन्हें हटाया नहीं जाना चाहिए.
  • [C-1-5] पसंद के मुताबिक बनाए गए स्थानीय खाते में की गई कार्रवाइयां मिटाने के बाद, रॉ संपर्क को तुरंत पूरी तरह मिटा दिया जाना चाहिए (जैसे कि CALLER_IS_SYNCADAPTER पैरामीटर को 'सही' पर सेट किया गया हो), भले ही CALLER\_IS\_SYNCADAPTER पैरामीटर को गलत पर सेट किया गया हो या बताया न गया हो.

4. ऐप्लिकेशन पैकेजिंग के साथ काम करती है

डिवाइस लागू करना:

  • [C-0-1] Android ".apk" फ़ाइलों को इंस्टॉल करने और उन्हें चलाने की क्षमता होनी चाहिए. इसे आधिकारिक Android SDK टूल में शामिल "aapt" टूल से जनरेट किया गया है.

    • हालांकि, ऊपर बताई गई ज़रूरी शर्त को पूरा करना मुश्किल हो सकता है. इसलिए, हम एओएसपी रेफ़रंस के लिए लागू किए गए पैकेज मैनेजमेंट सिस्टम का इस्तेमाल करने का सुझाव देते हैं.
  • [C-0-2] APK सिग्नेचर स्कीम v3.1, APK सिग्नेचर स्कीम v3, APK सिग्नेचर स्कीम v2, और JAR साइनिंग का इस्तेमाल करके ".apk" फ़ाइलों की पुष्टि करने की सुविधा होनी चाहिए.

  • [C-0-3] .apk, Android मेनिफ़ेस्ट, Dalvik बाइटकोड या RenderScript बाइटकोड फ़ॉर्मैट में से किसी को भी इस तरह एक्सटेंड नहीं करना चाहिए कि वे फ़ाइलें, अन्य डिवाइसों पर सही तरीके से इंस्टॉल न हो पाएं.

  • [C-0-4] पैकेज के लिए मौजूदा "इंस्टॉलर ऑफ़ रिकॉर्ड" के अलावा, किसी दूसरे ऐप्लिकेशन को उपयोगकर्ता की पुष्टि के बिना, ऐप्लिकेशन को अपने-आप अनइंस्टॉल करने की अनुमति नहीं देनी चाहिए. DELETE_PACKAGE की अनुमति के हिसाब से, SDK टूल में इस बारे में बताया गया है. सिर्फ़ PACKAGE_NEEDS_VERIFICATION इंटेंट और स्टोरेज मैनेजर ऐप्लिकेशन मैनेज करने ACTION_MANAGE_STORAGE इंटेंट के अपवाद हैं.

  • [C-0-5] ज़रूरी है कि आपकी साइट पर कोई ऐसी गतिविधि हुई हो जो android.settings.MANAGE_UNKNOWN_APP_SOURCES के मकसद को पूरा करती हो.

  • [C-0-6] अज्ञात सोर्स से ऐप्लिकेशन के पैकेज तब तक इंस्टॉल नहीं करना चाहिए, जब तक कि इंस्टॉल करने का अनुरोध करने वाला ऐप्लिकेशन नीचे दी गई सभी ज़रूरी शर्तों को पूरा न करता हो:

    • इसके लिए, REQUEST_INSTALL_PACKAGES की अनुमति का एलान करना ज़रूरी है या android:targetSdkVersion को 24 या इससे कम पर सेट किया जाना चाहिए.
    • यह ज़रूरी है कि उपयोगकर्ता ने अनजान सोर्स से ऐप्लिकेशन इंस्टॉल करने की अनुमति दी हो.
  • हर ऐप्लिकेशन के लिए, अज्ञात सोर्स से ऐप्लिकेशन इंस्टॉल करने की अनुमति देने/रद्द करने की अनुमति उपयोगकर्ता को देनी चाहिए. हालांकि, अगर डिवाइस लागू करने के विकल्प में उपयोगकर्ताओं को यह विकल्प न देना हो, तो उन्हें नो-ऑप के रूप में इसे लागू करने और startActivityForResult() के लिए RESULT_CANCELED वापस करने का विकल्प दिया जाना चाहिए. हालांकि, ऐसे मामलों में भी, उन्हें उपयोगकर्ता को यह बताना चाहिए कि ऐसा कोई विकल्प क्यों नहीं दिया गया है.

  • [C-0-7] उपयोगकर्ता को सिस्टम एपीआई PackageManager.setHarmfulAppWarning से मिली चेतावनी वाली स्ट्रिंग के साथ एक चेतावनी वाला डायलॉग दिखाना ज़रूरी है. ऐसा ऐप्लिकेशन में कोई ऐसी गतिविधि लॉन्च करने से पहले करना चाहिए जिसे उसी सिस्टम एपीआई PackageManager.setHarmfulAppWarning ने नुकसान पहुंचा सकने वाले के तौर पर मार्क किया हो.

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

  • [C-0-8] यहां दिए गए तरीके के मुताबिक, इंक्रीमेंटल फ़ाइल सिस्टम के लिए सहायता लागू करना ज़रूरी है.

  • [C-0-9] APK सिग्नेचर स्कीम v4 और APK सिग्नेचर स्कीम v4 .1 का इस्तेमाल करके, .apk फ़ाइलों की पुष्टि करने की सुविधा दी जानी चाहिए.

5. मल्टीमीडिया कॉन्टेंट के साथ काम करने की सुविधा

डिवाइस पर यह सुविधा लागू करना:

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

डिवाइस पर यह सुविधा लागू करना:

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

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

कृपया ध्यान दें कि न तो Google और न ही Open Handset Alliance ऐसा कोई दावा करते हैं कि ये कोडेक तीसरे पक्ष के पेटेंट से मुफ़्त हैं. जो लोग हार्डवेयर या सॉफ़्टवेयर प्रॉडक्ट में इस सोर्स कोड का इस्तेमाल करना चाहते हैं उन्हें सलाह दी जाती है कि ओपन सोर्स सॉफ़्टवेयर या शेयरवेयर के साथ-साथ इस कोड को लागू करने के लिए, उन लोगों से जुड़े पेटेंट के लाइसेंस की ज़रूरत पड़ सकती है.

5.1. मीडिया कोडेक

5.1.1. ऑडियो एन्कोडिंग

ज़्यादा जानकारी 5.1.3. ऑडियो कोडेक की जानकारी.

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

  • [C-1-1] पीसीएम/वेव
  • [C-1-2] एफ़एलएसी
  • [C-1-3] ओपस

सभी ऑडियो एन्कोडर को इनके साथ काम करना चाहिए:

  • [C-3-1] PCM 16-बिट वाले नेटिव बाइट का इस्तेमाल करके android.media.MediaCodec एपीआई की मदद से ऑडियो फ़्रेम को ऑर्डर किया जाता है.

5.1.2. ऑडियो डिकोडिंग

ज़्यादा जानकारी 5.1.3. ऑडियो कोडेक की जानकारी.

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

  • [C-1-1] MPEG-4 एएसी प्रोफ़ाइल (AAC LC)
  • [C-1-2] MPEG-4 HE AAC प्रोफ़ाइल (AAC+)
  • [C-1-3] MPEG-4 HE AACv2 प्रोफ़ाइल (बेहतर AAC+)
  • [C-1-4] AAC ELD (कम देरी वाले AAC)
  • [C-1-11] xHE-AAC (ISO/IEC 23003-3 एक्सटेंडेड HE AAC प्रोफ़ाइल, जिसमें USAC बेसलाइन प्रोफ़ाइल और ISO/IEC 23003-4 डाइनैमिक रेंज कंट्रोल प्रोफ़ाइल) शामिल है
  • [C-1-5] एफ़एलएसी
  • [C-1-6] एमपी3
  • [C-1-7] एमआईडीआई
  • [C-1-8] वोर्बिस
  • [C-1-9] PCM/WAVE, जिसमें 24 बिट तक के हाई-रिज़ॉल्यूशन ऑडियो फ़ॉर्मैट, 192 किलोहर्ट्ज़ का सैंपल रेट, और 8 चैनल शामिल हैं. ध्यान दें कि यह ज़रूरी शर्त सिर्फ़ डिकोड करने के लिए है. साथ ही, वीडियो चलाने के दौरान किसी डिवाइस को डाउनसैंपल और डाउनमिक्स करने की अनुमति है.
  • [C-1-10] ओपस

अगर डिवाइस पर लागू होने वाले डिवाइस, android.media.MediaCodec API में डिफ़ॉल्ट AAC ऑडियो डिकोडर के ज़रिए, कई चैनलों (यानी कि दो से ज़्यादा चैनल) के AAC इनपुट बफ़र को डिकोड करते हैं, तो इनके साथ काम करना ज़रूरी है:

  • [C-2-1] डाउनमिक्सिंग के बिना ही डिकोड करना ज़रूरी है.उदाहरण के लिए, 5. 0 AAC स्ट्रीम को PCM के पांच चैनलों पर डिकोड किया जाना चाहिए.साथ ही, 5.1 AAC स्ट्रीम को PCM के छह चैनलों में डिकोड किया जाना चाहिए.
  • [C-2-2] डाइनैमिक रेंज मेटाडेटा के बारे में आईएसओ/आईईसी 14496-3 के "डाइनैमिक रेंज कंट्रोल (डीआरसी)" में बताया जाना चाहिए. साथ ही, ऑडियो डिकोडर के डाइनैमिक रेंज से जुड़े व्यवहार को कॉन्फ़िगर करने के लिए, android.media.MediaFormat डीआरसी कुंजियां बताई जानी चाहिए. AAC DRC कुंजियां, एपीआई 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] इस बात पर खास तौर पर ध्यान दिया जाता है कि ऊपर दी गई C-2-1 और C-2-2 शर्तें, सभी AAC ऑडियो डिकोडर से पूरी होती हैं.

यूएसएसी ऑडियो को डिकोड करते समय, 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] PCM 16-बिट वाला नेटिव बाइट, android.media.MediaCodec एपीआई की मदद से ऑडियो फ़्रेम को ऑर्डर करता है.

अगर डिवाइस लागू करने की सुविधा, android.media.MediaCodec API में डिफ़ॉल्ट AAC ऑडियो डिकोडर के ज़रिए, कई चैनलों (यानी कि दो से ज़्यादा चैनल) के AAC इनपुट बफ़र को डिकोड करने की सुविधा देती है, तो इनके साथ काम करना ज़रूरी है:

  • [C-7-1] ऐप्लिकेशन के पास इस कुंजी को KEY_MAX_OUTPUT_CHANNEL_COUNT की मदद से डिकोड करने की सुविधा होनी चाहिए. इससे यह कंट्रोल किया जा सकता है कि कॉन्टेंट को स्टीरियो में डाउनग्रेड किया जाए या नहीं (2 की वैल्यू इस्तेमाल करते समय) या आउटपुट के तौर पर चैनलों की नेटिव संख्या का इस्तेमाल किया जाए. उदाहरण के लिए, 6 या उससे ज़्यादा वैल्यू वाली डिकोडर, 5.1 कॉन्टेंट फ़ीड किए जाने पर 6 चैनलों का आउटपुट देने के लिए, डिकोडर को कॉन्फ़िगर करेगा.
  • [C-7-2] डिकोड करते समय, डिकोडर को android.media.AudioFormat कॉन्सटेंट (उदाहरण:CHANNEL_OUT_5POINT1) का इस्तेमाल करके आउटपुट फ़ॉर्मैट पर KEY_CHANNEL_MASK कुंजी के साथ इस्तेमाल किए जा रहे चैनल मास्क का विज्ञापन देना चाहिए.

अगर डिवाइस लागू करने के तरीके, डिफ़ॉल्ट एएसी ऑडियो डिकोडर के अलावा किसी दूसरे ऑडियो डिकोडर के साथ काम करते हैं और कंप्रेस किए गए मल्टी-चैनल कॉन्टेंट के फ़ीड में एक से ज़्यादा चैनल वाला ऑडियो (दो चैनल से ज़्यादा) जनरेट किए जा सकते हैं, तो:

  • [C-SR-2] कुंजी की मदद से डिकोडिंग को ऐप्लिकेशन के ज़रिए कॉन्फ़िगर करने के लिए, डिकोडर को बहुत ज़्यादा सुझाया जाता है. इससे यह कंट्रोल किया जा सकता है कि कॉन्टेंट को स्टीरियो में डाउनग्रेड किया जाए या नहीं (2 की वैल्यू का इस्तेमाल करने पर) या आउटपुट में चैनल की मूल संख्या का इस्तेमाल किया जाए (जब उस संख्या के बराबर या उससे ज़्यादा वैल्यू का इस्तेमाल किया जाए).KEY_MAX_OUTPUT_CHANNEL_COUNT उदाहरण के लिए, 6 या उससे ज़्यादा वैल्यू वाली डिकोडर, 5.1 कॉन्टेंट फ़ीड किए जाने पर 6 चैनलों का आउटपुट देने के लिए, डिकोडर को कॉन्फ़िगर करेगा.
  • [C-SR-3] डिकोड करते समय, डिकोडर का बहुत ज़्यादा सुझाव दिया जाता है कि वह KEY_CHANNEL_MASK कुंजी के साथ आउटपुट फ़ॉर्मैट पर इस्तेमाल किए जा रहे चैनल मास्क का विज्ञापन करे. इसके लिए, android.media.AudioFormat कॉन्सटेंट (उदाहरण:CHANNEL_OUT_5POINT1) का इस्तेमाल किया जाएगा.

5.1.3. ऑडियो कोडेक की जानकारी

फ़ॉर्मैट/कोडेक जानकारी फ़ाइल टाइप/कंटेनर फ़ॉर्मैट का इस्तेमाल करना
MPEG-4 एएसी प्रोफ़ाइल
(AAC एलसी)
मोनो/स्टीरियो/5.0/5.1 कॉन्टेंट के लिए, सैंपलिंग की सामान्य दर 8 से 48 किलोहर्ट्ज़ के बीच होती है.
  • 3GPP (.3gp)
  • MPEG-4 (.mp4, .m4a)
  • ADTS रॉ AAC (.aac, ADIF काम नहीं करता)
  • MPEG-TS (.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 किलोहर्ट्ज़ (kHz) के बीच के स्टैंडर्ड सैंपल रेट का इस्तेमाल किया जा सकता है.
  • 3GPP (.3gp)
  • MPEG-4 (.mp4, .m4a)
यूएसएसी मोनो/स्टीरियो कॉन्टेंट के लिए, स्टैंडर्ड सैंपलिंग रेट 7.35 से 48 किलोहर्ट्ज़ के बीच होता है. MPEG-4 (.mp4, .m4a)
एएमआर-एनबी 4.75 से 12.2 केबीपीएस का सैंपल @ 8 किलोहर्ट्ज़ (kHz) 3GPP (.3gp)
एएमआर-डब्ल्यूबी 6.60 kbit/s से 23.85 kbit/s के सैंपल @ 16 किलोहर्ट्ज़ के हिसाब से ली गई नौ दरें, जिनकी जानकारी AMR-WB, अडैप्टिव मल्टी-रेट - वाइडबैंड स्पीच कोडेक पर दी गई है 3GPP (.3gp)
FLAC एन्कोडर और डिकोडर, दोनों के लिए: कम से कम मोनो और स्टीरियो मोड काम करना चाहिए. 192 किलोहर्ट्ज़ तक के सैंपल रेट काम करते हैं; 16-बिट और 24-बिट रिज़ॉल्यूशन के साथ काम करना ज़रूरी है. FLAC 24-बिट ऑडियो डेटा हैंडलिंग, फ़्लोटिंग पॉइंट ऑडियो कॉन्फ़िगरेशन के साथ उपलब्ध होनी चाहिए.
  • FLAC (.flac)
  • MPEG-4 (.mp4, .m4a, सिर्फ़ डिकोड)
  • Matroska (.mkv, सिर्फ़ डिकोड करना)
MP3 मोनो/स्टीरियो 8-320 केबीपीएस कॉन्स्टेंट (सीबीआर) या वैरिएबल बिटरेट (वीबीआर)
  • एमपी3 (.mp3)
  • MPEG-4 (.mp4, .m4a, सिर्फ़ डिकोड)
  • Matroska (.mkv, सिर्फ़ डिकोड करना)
एमआईडीआई एमआईडीआई टाइप 0 और 1. DLS वर्शन 1 और 2. XMF और Mobile XMF. RTTTL/RTX, OTA, और iMelody रिंगटोन के लिए सहायता
  • टाइप 0 और 1 (.mid, .xmf, .mxmf)
  • आरटीटीटीएल/आरटीएक्स (.rtttl, .rtx)
  • iMelody (.imy)
वोर्बिस
  • ऑग (.ogg)
  • MPEG-4 (.mp4, .m4a, सिर्फ़ डिकोड)
  • मैट्रोस्का (.mkv)
  • वेबम (.webm)
PCM/WAVE PCM कोडेक को 16-बिट लीनियर PCM और 16-बिट फ़्लोट पर काम करना चाहिए. WAVE एक्सट्रैक्टर, 16-बिट, 24-बिट, 32-बिट लीनियर PCM, और 32-बिट फ़्लोट (हार्डवेयर की सीमा तक की दर तक) के साथ काम करना चाहिए. सैंपलिंग रेट 8 किलोहर्ट्ज़ से 192 किलोहर्ट्ज़ तक काम करना ज़रूरी है. WAVE (.wav)
Opus डिकोड करने की सुविधा: मोनो, स्टीरियो, 5.0, और 5.1 कॉन्टेंट के लिए 8,000, 12,000, 16,000, 24,000, और 48,000 हर्ट्ज़ की सैंपलिंग रेट.
एन्कोडिंग: 8,000, 12,000, 16,000, 16,000, 1,6000, 1,6000, 1,600, 0,000, और 1,600,000 हर्ट्ज़ की सैंपलिंग रेट के साथ मोनो और स्टीरियो कॉन्टेंट के लिए सहायता
  • ऑग (.ogg)
  • MPEG-4 (.mp4, .m4a, सिर्फ़ डिकोड)
  • मैट्रोस्का (.mkv)
  • वेबम (.webm)

5.1.4. चित्र एन्कोडिंग

ज़्यादा जानकारी 5.1.6. इमेज कोडेक से जुड़ी जानकारी.

डिवाइस को लागू करने के लिए, नीचे दी गई इमेज को कोड में बदलने का तरीका काम करना चाहिए:

  • [C-0-1] जेपीईजी
  • [C-0-2] PNG
  • [C-0-3] WebP

नई ज़रूरी शर्तें लागू करें

  • [C-0-4] एवीआईएफ़
    • डिवाइसों में BITRATE_MODE_CQ और बेसलाइन प्रोफ़ाइल होनी चाहिए.

नई ज़रूरी शर्तें खत्म करना

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

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

5.1.5. इमेज डिकोड करना

ज़्यादा जानकारी 5.1.6. इमेज कोडेक से जुड़ी जानकारी.

लागू करने के लिए डिवाइस को नीचे दिए गए इमेज एन्कोडिंग को डिकोड करना ज़रूरी है:

  • [C-0-1] जेपीईजी
  • [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), HEIC (.heic)
AVIF (बेसलाइन प्रोफ़ाइल) इमेज, इमेज कलेक्शन, इमेज के क्रम वाली बेसलाइन प्रोफ़ाइल एचईआईएफ़ कंटेनर (.avif)

MediaCodec एपीआई की मदद से दिखाए गए इमेज एन्कोडर और डिकोडर

  • [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] सरफ़ेस आउटपुट का इस्तेमाल करके कॉन्फ़िगर किए जाने पर, हार्डवेयर डिसप्ले के लिए ऑप्टिमाइज़ किए गए कलर फ़ॉर्मैट में डिफ़ॉल्ट रूप से सेट होना चाहिए.
  • [C-4-2] अगर सरफ़ेस आउटपुट का इस्तेमाल न करने के लिए कॉन्फ़िगर किया गया है, तो सीपीयू रीडिंग के लिए ऑप्टिमाइज़ किए गए YUV420 8:8:8 कलर फ़ॉर्मैट पर डिफ़ॉल्ट रूप से सेट होना चाहिए.

5.1.8. वीडियो कोडेक की सूची

फ़ॉर्मैट/कोडेक जानकारी फ़ाइल टाइप/कंटेनर फ़ॉर्मैट का इस्तेमाल करना
एच.263
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
  • Matroska (.mkv, सिर्फ़ डिकोड करना)
एच.264 एवीसी ज़्यादा जानकारी के लिए, सेक्शन 5.2 और 5.3 देखें
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
  • MPEG-2 टीएस (.ts, सीकेबल नहीं)
  • Matroska (.mkv, सिर्फ़ डिकोड करना)
एच.265 एचईवीसी जानकारी के लिए, सेक्शन 5.3 देखें
  • MPEG-4 (.mp4)
  • Matroska (.mkv, सिर्फ़ डिकोड करना)
MPEG-2 मुख्य प्रोफ़ाइल
  • MPEG2-TS (.ts, सीकेबल नहीं)
  • MPEG-4 (.mp4, सिर्फ़ डिकोड करना)
  • Matroska (.mkv, सिर्फ़ डिकोड करना)
एमपीईजी-4 एसपी
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
  • Matroska (.mkv, सिर्फ़ डिकोड करना)
वीपी8 ज़्यादा जानकारी के लिए, सेक्शन 5.2 और 5.3 देखें
वीपी9 जानकारी के लिए, सेक्शन 5.3 देखें
एवी1 ज़्यादा जानकारी के लिए, सेक्शन 5.2 और सेक्शन 5.3 देखें
  • MPEG-4 (.mp4)
  • Matroska (.mkv, सिर्फ़ डिकोड)

5.1.9. मीडिया कोडेक सुरक्षा

डिवाइस को लागू करने के लिए, यह पक्का करना ज़रूरी है कि मीडिया कोडेक की सुरक्षा सुविधाओं का पालन किया जा रहा हो, जैसा कि नीचे बताया गया है.

Android में, क्रॉस-प्लैटफ़ॉर्म मल्टीमीडिया ऐक्सेलरेशन एपीआई के साथ-साथ कोडेक 2.0, एक लो-ओवरहेड मल्टीमीडिया ऐक्सेलरेशन एपीआई के साथ काम करता है.

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

  • [C-1-1] Android ओपन सोर्स प्रोजेक्ट की तरह, ओएमएक्स या कोडेक 2.0 एपीआई (या दोनों) के ज़रिए मीडिया कोडेक के लिए सहायता देना ज़रूरी है. साथ ही, सुरक्षा से जुड़ी सुविधाओं को बंद नहीं करना चाहिए और न ही उन्हें गच्चा देना चाहिए. इसका खास तौर पर यह मतलब नहीं है कि हर कोडेक को OMX या कोडेक 2.0 API का इस्तेमाल करना ज़रूरी है. इनमें से कम से कम एक एपीआई के लिए सिर्फ़ यही सुविधा उपलब्ध होनी चाहिए. साथ ही, उपलब्ध एपीआई में मौजूद सुरक्षा सुविधाएं भी मौजूद होनी चाहिए.
  • [C-SR-1] को कोडेक 2.0 एपीआई के साथ काम करने का सुझाव दिया जाता है.

अगर लागू किए गए डिवाइस पर कोडेक 2.0 एपीआई काम नहीं करता, तो वे:

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

अगर लागू किए गए डिवाइस, कोडेक 2.0 API के साथ काम करते हैं, तो वे:

  • [C-3-1] हर मीडिया फ़ॉर्मैट और डिवाइस पर काम करने वाले टाइप (एन्कोडर या डिकोडर) के लिए, Android ओपन सोर्स प्रोजेक्ट (अगर उपलब्ध हो) से संबंधित कोडेक 2.0 सॉफ़्टवेयर कोडेक को शामिल करना ज़रूरी है.
  • [C-3-2] Android ओपन सोर्स प्रोजेक्ट में दी गई सॉफ़्टवेयर कोडेक प्रोसेस में कोडेक 2.0 सॉफ़्टवेयर कोडेक को रखना ज़रूरी है. इससे सॉफ़्टवेयर कोडेक का ऐक्सेस ज़्यादा बारीकी से दिया जा सकता है.
  • [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" से शुरू होने वाले नाम वाले कोडेक. आपको कोडेक 2.0 API का इस्तेमाल करना होगा और ऐसे नाम होने चाहिए जो Android के लिए, कोडेक 2.0 नाम रखने से जुड़े दिशा-निर्देशों के मुताबिक हों.
  • [C-1-4] ऐसे कोडेक जिनका नाम "OMX.google." या "c2.android" से शुरू होता है. इसे वेंडर या हार्डवेयर से तेज़ी से होने वाली बढ़ोतरी के तौर पर नहीं दिखाया जाना चाहिए.
  • [C-1-5] कोडेक प्रोसेस (वेंडर या सिस्टम) में चलने वाले कोडेक को सिर्फ़ सॉफ़्टवेयर नहीं माना जाना चाहिए. ये ऐसे कोडेक होते हैं जिनके पास मेमोरी ऐलोकेटर और मैपर के अलावा, दूसरे हार्डवेयर ड्राइवर का ऐक्सेस होता है.
  • [C-1-6] ऐसे कोडेक जो Android ओपन सोर्स प्रोजेक्ट में मौजूद नहीं हैं या उस प्रोजेक्ट में मौजूद सोर्स कोड पर आधारित नहीं हैं उन्हें वेंडर के तौर पर माना जाना चाहिए.
  • [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 पिक्सल (HEVC, VP9, AV1)
  • [C-2-2] हार्डवेयर ऐक्सेलरेटेड के तौर पर दिखाए जाने वाले वीडियो कोडेक को परफ़ॉर्मेंस पॉइंट की जानकारी पब्लिश करना ज़रूरी है. इनमें, इस्तेमाल किए जा सकने वाले सभी स्टैंडर्ड परफ़ॉर्मेंस पॉइंट (PerformancePoint एपीआई की सूची) में शामिल होने चाहिए. हालांकि, ऐसा तब ही होना चाहिए, जब तक कि वे इस्तेमाल किए जा सकने वाले किसी अन्य स्टैंडर्ड परफ़ॉर्मेंस पॉइंट में शामिल न हों.
  • इसके अलावा, अगर दी गई सूची में शामिल स्टैंडर्ड वीडियो की परफ़ॉर्मेंस के अलावा, किसी दूसरे वीडियो की परफ़ॉर्मेंस को लगातार बेहतर बनाया जा सकता है, तो उन्हें लंबे समय तक चलने वाले परफ़ॉर्मेंस पॉइंट भी पब्लिश करने चाहिए.

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

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

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

नई ज़रूरी शर्तें लागू करें

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

  • [C-5-1] ज़रूरी है एक स्लाइडिंग विंडो से ज़्यादा, इंट्राफ़्रेम (I-frame) इंटरवल के बीच के बिटरेट पर 15% से ज़्यादा नहीं होना चाहिए.
  • [C-5-2] ज़रूरी है एक सेकंड की स्लाइडिंग विंडो पर, बिटरेट से 100% से ज़्यादा नहीं होना चाहिए.

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

  • [C-6-1] ज़रूरी है [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 एसपी वीडियो एन्कोडर के साथ काम करती है और उसे तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराया जाता है, तो वे:

  • इसके साथ काम करने वाले एन्कोडर के लिए, इसे डाइनैमिक तरीके से कॉन्फ़िगर किए जा सकने वाले बिटरेट के साथ काम करना चाहिए.

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

  • [C-4-1] सभी हार्डवेयर एक्सेलरेटेड वीडियो और इमेज एन्कोडर को हार्डवेयर कैमरे से फ़्रेम एन्कोड करने की सुविधा देनी चाहिए.
  • यह ज़रूरी है कि सभी वीडियो या इमेज एन्कोडर में, हार्डवेयर कैमरे के फ़्रेम को कोड में बदला जा सके.

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

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

5.2.1. एच.263

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

  • [C-1-1] बेसलाइन प्रोफ़ाइल लेवल 45 का इस्तेमाल करके, QCIF रिज़ॉल्यूशन (176 x 144) पर काम करना चाहिए. SQCIF रिज़ॉल्यूशन का इस्तेमाल करना ज़रूरी नहीं है.
  • इस सुविधा के साथ काम करने वाले एन्कोडर के लिए, इसे डाइनैमिक तरीके से कॉन्फ़िगर किए जा सकने वाले बिटरेट पर काम करने चाहिए.

5.2.2. H.264

अगर लागू किए गए डिवाइस, H.264 कोडेक के साथ काम करते हैं, तो वे:

  • [C-1-1] बेसलाइन प्रोफ़ाइल लेवल 3 के साथ काम करना ज़रूरी है. हालांकि, ASO (आर्बिट्ररी स्लाइस ऑर्डरिंग), एफ़एमओ (फ़्लेक्सिबल मैक्रोब्लॉक ऑर्डरिंग) और आरएस (रिडंडंट स्लाइसर) की सुविधा ज़रूरी नहीं है. इसके अलावा, हमारा सुझाव है कि अन्य Android डिवाइसों के साथ काम करने के लिए, एन्कोडर का इस्तेमाल करके बेसलाइन प्रोफ़ाइल के लिए एएसओ, एफ़एमओ, और आरएस का इस्तेमाल न करें.
  • [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. वीपी8

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

  • [C-1-1] एसडी वीडियो एन्कोडिंग प्रोफ़ाइल के साथ काम करना ज़रूरी है.
  • एचडी (हाई डेफ़िनिशन) वीडियो एन्कोडिंग की नीचे दी गई प्रोफ़ाइल पर काम करना चाहिए.
  • [C-1-2] Matroska WebM फ़ाइलों में काम करने की सुविधा ज़रूरी है.
  • एक ऐसा हार्डवेयर VP8 कोडेक देना चाहिए जो WebM प्रोजेक्ट RTC हार्डवेयर कोडिंग की ज़रूरी शर्तों को पूरा करता हो. इससे यह पक्का किया जा सकेगा कि वेब वीडियो स्ट्रीमिंग और वीडियो-कॉन्फ़्रेंस सेवाओं की स्वीकार की जाने वाली क्वालिटी अच्छी हो.

अगर डिवाइस लागू करने की सुविधा, मीडिया एपीआई के ज़रिए 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. वीपी9

अगर लागू किए गए डिवाइस, 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 एमबीपीएस

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

  • 12-बिट फ़ॉर्मैट के साथ काम करना ज़रूरी नहीं है.

5.2.5. एच.265

अगर लागू किए गए डिवाइस, H.265 कोडेक के साथ काम करते हैं, तो वे:

  • [C-1-1] मुख्य प्रोफ़ाइल लेवल 3 पर 512 x 512 रिज़ॉल्यूशन तक काम करना ज़रूरी है.
  • एचडी एन्कोडिंग प्रोफ़ाइल के साथ काम करना चाहिए, जैसा कि नीचे दी गई टेबल में बताया गया है.
  • अगर कोई हार्डवेयर एन्कोडर है, तो 720 x 480 एसडी प्रोफ़ाइल और एचडी एन्कोडिंग प्रोफ़ाइल के साथ काम करने के लिए, [C-SR-1] को बहुत ज़्यादा इस्तेमाल किया जाता है. नीचे दी गई टेबल में इसके बारे में बताया गया है.
एसडी एचडी 720 पिक्सल एचडी 1080 पिक्सल यूएचडी
वीडियो रिज़ॉल्यूशन 720 x 480 पिक्सल 1280 x 720 पिक्सल 1920 x 1080 पिक्सल 3840 x 2160 पिक्सल
वीडियो फ़्रेम रेट 30 एफ़पीएस (फ़्रेम प्रति सेकंड) 30 एफ़पीएस (फ़्रेम प्रति सेकंड) 30 एफ़पीएस (फ़्रेम प्रति सेकंड) 30 एफ़पीएस (फ़्रेम प्रति सेकंड)
वीडियो बिटरेट 1.6 एमबीपीएस 4 एमबीपीएस 5 एमबीपीएस 20 एमबीपीएस

नई ज़रूरी शर्तें लागू करें

5.2.6. AV1

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

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

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

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

  • [C-2-1] यहां दी गई टेबल में, एचडी1080p एन्कोडिंग प्रोफ़ाइल के साथ काम करना ज़रूरी है:
एसडी एचडी 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 एपीआई की मदद से, डाइनैमिक वीडियो रिज़ॉल्यूशन और फ़्रेम रेट को रीयल टाइम में स्विच किया जा सकता है. साथ ही, डिवाइस पर मौजूद हर कोडेक के साथ काम करने वाले ज़्यादा से ज़्यादा रिज़ॉल्यूशन की सुविधा मिल सकती है.

5.3.1. MPEG-2

अगर डिवाइस लागू करने के तरीके, MPEG-2 डिकोडर के साथ काम करते हैं, तो वे:

  • [C-1-1] मुख्य प्रोफ़ाइल के हाई लेवल के साथ काम करना ज़रूरी है.

5.3.2. एच.263

अगर डिवाइस इंप्लिमेंटेशन H.263 डिकोडर के साथ काम करते हैं, तो ये:

  • [C-1-1] बेसलाइन प्रोफ़ाइल लेवल 30 (CIF, QCIF, और SQCIF रिज़ॉल्यूशन @ 30fps 384 केबीपीएस) और लेवल 45 (QCIF और SQCIF रिज़ॉल्यूशन @ 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 और बेसलाइन प्रोफ़ाइल के साथ काम करना ज़रूरी है. एएसओ (आर्बिट्ररी स्लाइस ऑर्डरिंग), एफ़एमओ (फ़्लेक्सिबल मैक्रोब्लॉक ऑर्डरिंग) और आरएस (अनावश्यक स्लाइस) के लिए सहायता ज़रूरी नहीं है.
  • [C-1-2] वीडियो को नीचे दी गई टेबल में दी गई एसडी (स्टैंडर्ड डेफ़िनिशन) प्रोफ़ाइलों का इस्तेमाल करके डिकोड किया जा सकता हो. साथ ही, उन्हें बेसलाइन प्रोफ़ाइल और मुख्य प्रोफ़ाइल के लेवल 3.1 (720p30 समेत) के साथ एन्कोड किया गया हो.
  • वीडियो को एचडी (हाई डेफ़िनिशन) प्रोफ़ाइल से डिकोड किया जा सकता हो, जैसा कि नीचे दी गई टेबल में बताया गया है.

अगर Display.getSupportedModes() तरीके से रिपोर्ट की गई ऊंचाई, वीडियो रिज़ॉल्यूशन के बराबर या उससे ज़्यादा है, तो डिवाइस पर यह तरीका अपनाएं:

  • [C-2-1] नीचे दी गई टेबल में, एचडी 720 पिक्सल वीडियो डिकोड करने वाली प्रोफ़ाइलों का इस्तेमाल करना ज़रूरी है.
  • [C-2-2] नीचे दी गई टेबल में, एचडी 1080 पिक्सल वीडियो डिकोड करने वाली प्रोफ़ाइलों का इस्तेमाल करना ज़रूरी है.
एसडी (हल्की क्वालिटी) एसडी (अच्छी क्वालिटी) एचडी 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] डिवाइस पर एचडीआर क्वालिटी के वीडियो लागू करने के लिए, 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 FPS (60 FPS)H.265 हार्डवेयर डिकोडिंग के साथ टेलीविज़न) 60 एफ़पीएस (फ़्रेम प्रति सेकंड)
वीडियो बिटरेट 600 केबीपीएस 1.6 एमबीपीएस 4 एमबीपीएस 5 एमबीपीएस 20 एमबीपीएस

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

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

5.3.6. वीपी8

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

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

अगर Display.getSupportedModes() तरीके से रिपोर्ट की गई ऊंचाई, वीडियो रिज़ॉल्यूशन के बराबर या उससे ज़्यादा है, तो:

  • [C-2-1] नीचे दी गई टेबल में बताया गया है कि डिवाइस पर 720 पिक्सल वाली प्रोफ़ाइलों का इस्तेमाल किया जा सकता है या नहीं.
  • [C-2-2] नीचे दी गई टेबल में बताया गया है कि डिवाइस पर 1080 पिक्सल वाली प्रोफ़ाइलों का इस्तेमाल किया जा सकता है या नहीं.
एसडी (हल्की क्वालिटी) एसडी (अच्छी क्वालिटी) एचडी 720 पिक्सल एचडी 1080 पिक्सल
वीडियो रिज़ॉल्यूशन 320 x 180 पिक्सल 640 x 360 पिक्सल 1280 x 720 पिक्सल 1920 x 1080 पिक्सल
वीडियो फ़्रेम रेट 30 एफ़पीएस (फ़्रेम प्रति सेकंड) 30 एफ़पीएस (फ़्रेम प्रति सेकंड) 30 FPS (60 FPS)टेलिविज़न) 30 (60 एफ़पीएस (फ़्रेम प्रति सेकंड)टेलीविज़न)
वीडियो बिटरेट 800 केबीपीएस 2 एमबीपीएस 8 एमबीपीएस 20 एमबीपीएस

5.3.7. वीपी9

अगर लागू किए गए डिवाइस, 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 FPS (60 FPS)VP9 हार्डवेयर डिकोडिंग के साथ टेलीविज़न) 60 एफ़पीएस (फ़्रेम प्रति सेकंड)
वीडियो बिटरेट 600 केबीपीएस 1.6 एमबीपीएस 4 एमबीपीएस 5 एमबीपीएस 20 एमबीपीएस

अगर लागू किए जाने वाले डिवाइस, 'CodecProfileLevel' मीडिया एपीआई के ज़रिए VP9Profile2 या VP9Profile3 के साथ काम करने का दावा करते हैं:

  • 12-बिट फ़ॉर्मैट के साथ काम करना ज़रूरी नहीं है.

अगर लागू किए गए डिवाइस, मीडिया एपीआई के ज़रिए एचडीआर प्रोफ़ाइल (VP9Profile2HDR, VP9Profile2HDR10Plus, VP9Profile3HDR, VP9Profile3HDR10Plus) पर काम करने का दावा करते हैं, तो:

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

5.3.8. Dolby Vision

अगर डिवाइस लागू करने की सुविधा, HDR_TYPE_DOLBY_VISION के ज़रिए Dolby Vision डिकोडर के साथ काम करने का एलान करती है, तो ये:

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

5.3.9. AV1

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

  • [C-1-1] प्रोफ़ाइल 0 के साथ काम करना ज़रूरी है, जिसमें 10-बिट कॉन्टेंट भी शामिल हो.

नई ज़रूरी शर्तें लागू करें

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

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

अगर डिवाइस लागू करने की सुविधा, हार्डवेयर ऐक्सेलरेटेड डिकोडर के साथ AV1 कोडेक के लिए सहायता देती है, तो ये:

  • [C-2-1] Display.getSupportedModes() वाले तरीके से रिपोर्ट की गई ऊंचाई 720 पिक्सल या इससे ज़्यादा होने पर, यहां दी गई टेबल से कम से कम एचडी 720 पिक्सल वाले वीडियो डिकोड करने वाली प्रोफ़ाइलों को डिकोड किया जा सकता है.
  • [C-2-2] Display.getSupportedModes() वाले तरीके से रिपोर्ट की गई ऊंचाई 1080 पिक्सल या इससे ज़्यादा होने पर, यहां दी गई टेबल से कम से कम एचडी 1080 पिक्सल वाले वीडियो डिकोड करने वाली प्रोफ़ाइलों को डिकोड करना ज़रूरी है.
एसडी एचडी 720 पिक्सल एचडी 1080 पिक्सल यूएचडी
वीडियो रिज़ॉल्यूशन 720 x 480 पिक्सल 1280 x 720 पिक्सल 1920 x 1080 पिक्सल 3840 x 2160 पिक्सल
वीडियो फ़्रेम रेट 30 एफ़पीएस (फ़्रेम प्रति सेकंड) 30 एफ़पीएस (फ़्रेम प्रति सेकंड) 30 एफ़पीएस (फ़्रेम प्रति सेकंड) 30 एफ़पीएस (फ़्रेम प्रति सेकंड)
वीडियो बिटरेट 5 एमबीपीएस 8 एमबीपीएस 16 एमबीपीएस 50 एमबीपीएस

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

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

नई ज़रूरी शर्तें खत्म करना

5.4. ऑडियो रिकॉर्डिंग

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

5.4.1. ऑडियो कैप्चर और माइक्रोफ़ोन की रॉ जानकारी

अगर लागू किए गए डिवाइस पर android.hardware.microphone का एलान किया जाता है, तो:

  • [C-1-1] चालू होने पर, किसी भी AudioRecord या AAudio इनपुट स्ट्रीम के लिए, रॉ ऑडियो कॉन्टेंट को कैप्चर करना ज़रूरी है. कम से कम, नीचे दी गई विशेषताओं का इस्तेमाल करना ज़रूरी है:

  • इन विशेषताओं वाले रॉ ऑडियो कॉन्टेंट को कैप्चर करने की अनुमति होनी चाहिए:

    • फ़ॉर्मैट: लीनियर PCM, 16-बिट, और 24-बिट
    • सैंपलिंग रेट: 8,000, 11,025, 16,000, 22,050, 24,000, 32,000, 44,100, 48,000 हर्ट्ज़
    • चैनल: डिवाइस में जितने चाहे उतने माइक्रोफ़ोन
  • [C-1-2] सैंपल की दर के बिना, ऊपर बताई गई दर पर कैप्चर करना ज़रूरी है.

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

  • रॉ ऑडियो कॉन्टेंट को AM रेडियो और डीवीडी क्वालिटी में कैप्चर करने की अनुमति देनी चाहिए, जिसका मतलब है:

    • फ़ॉर्मैट: लीनियर PCM, 16-बिट
    • सैंपलिंग रेट: 22050, 48000 हर्ट्ज़
    • चैनल: स्टीरियो
  • [C-1-4] MicrophoneInfo API का पालन करना ज़रूरी है. साथ ही, AudioManager.getMicrophones() API के ज़रिए तीसरे पक्ष के ऐप्लिकेशन पर उपलब्ध माइक्रोफ़ोन की जानकारी ठीक से भरें. इसके लिए, MediaRecorder.AudioSources DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED या VOICE_PERFORMANCE का इस्तेमाल किया जा सकता है. अगर डिवाइस पर यह सुविधा काम करती है, तो वे:

  • [C-2-1] 16000:22050 या 44100:48000 से ज़्यादा के किसी भी अनुपात में अप-सैंपलिंग के बिना कैप्चर करना ज़रूरी है.

  • [C-2-2] किसी भी अप-सैंपलिंग या डाउन-सैंपलिंग के लिए एक सही एंटी-एलियाज़िंग फ़िल्टर शामिल करना ज़रूरी है.

5.4.2. आवाज़ पहचानने के लिए कैप्चर करें

अगर लागू किए गए डिवाइस पर android.hardware.microphone का एलान किया जाता है, तो:

  • [C-1-1] android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION ऑडियो सोर्स को सैंपलिंग रेट 44,100 और 48,000 में से किसी एक पर कैप्चर करना ज़रूरी है.
  • [C-1-2] AudioSource.VOICE_RECOGNITION ऑडियो सोर्स से ऑडियो स्ट्रीम रिकॉर्ड करते समय, शोर कम करने वाले ऑडियो की प्रोसेसिंग को डिफ़ॉल्ट रूप से बंद कर देना चाहिए.
  • [C-1-3] AudioSource.VOICE_RECOGNITION के ऑडियो सोर्स से ऑडियो स्ट्रीम रिकॉर्ड करते समय, अपने-आप गेन कंट्रोल को बंद करना ज़रूरी है.

  • औसत फ़्रीक्वेंसी रेंज में, डाइमेंशन और फ़्रीक्वेंसी की फ़्रीक्वेंसी सामान्य दिखने चाहिए: खास तौर पर, आवाज़ की पहचान करने वाले ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए जाने वाले हर माइक्रोफ़ोन के लिए, 100 हर्ट्ज़ से लेकर 4000 हर्ट्ज़ तक.

  • [C-SR-1] का बहुत ज़्यादा सुझाव दिया जाता है कि आवाज़ की पहचान करने वाले ऑडियो स्रोत को रिकॉर्ड करने के लिए इस्तेमाल किए जाने वाले हर माइक्रोफ़ोन के लिए, कम फ़्रीक्वेंसी की रेंज में आयाम का लेवल दिखाया जाए. खास तौर पर, 30 हर्ट्ज़ से 100 हर्ट्ज़ तक ±20 dB से लेकर 100 हर्ट्ज़ तक.

  • [C-SR-2] का बहुत ज़्यादा सुझाव दिया जाता है, ताकि आवाज़ की पहचान वाले ऑडियो स्रोत को रिकॉर्ड करने के लिए इस्तेमाल किए जाने वाले हर माइक्रोफ़ोन की मिड-फ़्रीक्वेंसी रेंज की तुलना में ±30 dB से लेकर 4000 हर्ट्ज़ से 22 किलोहर्ट्ज़ तक.

  • ऑडियो इनपुट की संवेदनशीलता को इस तरह सेट करना चाहिए कि हर माइक्रोफ़ोन के लिए 1000 हर्ट्ज़ से दोगुने ऑडियो के टोन के सोर्स को 90 dB के साउंड प्रेशर लेवल (एसपीएल) पर चलाया गया. (इसे माइक्रोफ़ोन से 30 सें॰मी॰ की दूरी पर मापा गया.

  • आवाज़ की पहचान करने वाली ऑडियो स्ट्रीम को रिकॉर्ड करना चाहिए, ताकि पीसीएम आयाम के स्तर, माइक्रोफ़ोन पर इनपुट एसपीएल को कम से कम 30 dB से कम से कम 30 dB से +12 dB re 90 dB SPL तक बदल सकते हैं.

  • माइक्रोफ़ोन पर आवाज़ की पहचान करने वाली ऑडियो स्ट्रीम को 90 dB SPL इनपुट लेवल पर, 1 किलोहर्ट्ज़ के लिए 1% से कम हारमोनिक डिस्टॉर्शन (THD) में रिकॉर्ड करना चाहिए.

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

  • [C-2-1] इस ऑडियो इफ़ेक्ट को android.media.audiofx.NoiseSuppressor एपीआई की मदद से कंट्रोल करने की अनुमति देना ज़रूरी है.
  • [C-2-2] ग़ैर-ज़रूरी आवाज़ें कम करने की हर टेक्नोलॉजी को लागू करने के लिए, AudioEffect.Descriptor.uuid फ़ील्ड की मदद से अलग-अलग पहचान करनी ज़रूरी है.

5.4.3. प्लेबैक को फिर से रूट करने के लिए कैप्चर करें

android.media.MediaRecorder.AudioSource क्लास में REMOTE_SUBMIX ऑडियो सोर्स शामिल होता है.

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

  • [C-1-1] REMOTE_SUBMIX ऑडियो सोर्स को सही तरीके से लागू करना ज़रूरी है. इससे, जब कोई ऐप्लिकेशन इस ऑडियो सोर्स से रिकॉर्ड करने के लिए android.media.AudioRecord एपीआई का इस्तेमाल करता है, तो यह इन चीज़ों को छोड़कर बाकी सभी ऑडियो स्ट्रीम को एक साथ कैप्चर करता है:

    • AudioManager.STREAM_RING
    • AudioManager.STREAM_ALARM
    • AudioManager.STREAM_NOTIFICATION

5.4.4. अकूस्टिक इको रद्द करने वाला

अगर लागू किए गए डिवाइस पर android.hardware.microphone का एलान किया जाता है, तो:

  • AudioSource.VOICE_COMMUNICATION का इस्तेमाल करके कैप्चर करते समय, वॉइस कम्यूनिकेशन के लिए ट्यून की गई और कैप्चर पाथ पर लागू की गई Acoustic Echo रद्दर (एईसी) टेक्नोलॉजी का इस्तेमाल करना चाहिए.

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

  • [C-SR-1] को AcousticEchoCanceler एपीआई तरीके AcousticEchoCanceler.isAvailable() के ज़रिए एलान करने के लिए, STRONGLY_सुझाया गया तरीका अपनाएं
  • [C-SR-2] को इस ऑडियो इफ़ेक्ट को AcousticEchoCanceler एपीआई की मदद से कंट्रोल करने की अनुमति दी जाती है. इसलिए, यह पक्का किया जाता है कि इसे STRONGLY_ पक्का किया जा सके.
  • [C-SR-3] को AudioEffect.Descriptor.uuid फ़ील्ड के ज़रिए, हर AEC टेक्नोलॉजी की पहचान करने के लिए STRONGLY_सुझाया गया तरीका इस्तेमाल किया गया है.

5.4.5. समवर्ती कैप्चर

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

  • [C-1-1] सुलभता सेवा को AudioSource.VOICE_RECOGNITION और किसी AudioSource के साथ कैप्चर करने वाले कम से कम एक ऐप्लिकेशन के ज़रिए, माइक्रोफ़ोन को एक साथ ऐक्सेस करने की अनुमति देनी होगी.
  • [C-1-2] पहले से इंस्टॉल किए गए किसी ऐसे ऐप्लिकेशन को एक साथ माइक्रोफ़ोन इस्तेमाल करने की अनुमति देनी होगी जिसमें Assistant की भूमिका हो और कम से कम एक ऐसा ऐप्लिकेशन हो जो AudioSource.VOICE_COMMUNICATION या AudioSource.CAMCORDER को छोड़कर किसी भी AudioSource से कैप्चर कर रहा हो.
  • [C-1-3] सुलभता सेवा को छोड़कर, किसी दूसरे ऐप्लिकेशन के लिए ऑडियो कैप्चर की आवाज़ बंद करना ज़रूरी है. ऐसा तब होना चाहिए, जब कोई ऐप्लिकेशन AudioSource.VOICE_COMMUNICATION या AudioSource.CAMCORDER का इस्तेमाल करके कैप्चर कर रहा हो. हालांकि, जब कोई ऐप्लिकेशन AudioSource.VOICE_COMMUNICATION से कैप्चर करता है, तो कोई दूसरा ऐप्लिकेशन वॉइस कॉल को कैप्चर कर सकता है. हालांकि, इसके लिए ज़रूरी है कि वह ऐप्लिकेशन, पहले से इंस्टॉल किया गया कोई ऐसा ऐप्लिकेशन हो जिसके पास CAPTURE_AUDIO_OUTPUT की अनुमति हो.
  • [C-1-4] अगर दो या दो से ज़्यादा ऐप्लिकेशन एक साथ कैप्चर कर रहे हों और किसी भी ऐप्लिकेशन में सबसे ऊपर यूज़र इंटरफ़ेस (यूआई) न हो, तो सबसे हाल ही में कैप्चर करने वाले ऐप्लिकेशन को ऑडियो मिलता है.

5.5. ऑडियो प्लेबैक

Android में वह सुविधा शामिल है जिससे ऐप्लिकेशन, ऑडियो आउटपुट वाले सहायक डिवाइसों की मदद से ऑडियो चला सकते हैं. इसकी जानकारी सेक्शन 7.8.2 में दी गई है.

5.5.1. ऑडियो को चलाने की सुविधा

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

  • [C-1-1] इन एट्रिब्यूट के साथ रॉ ऑडियो कॉन्टेंट चलाने की अनुमति होनी चाहिए:

    • सोर्स फ़ॉर्मैट: लीनियर PCM, 16-बिट, 8-बिट, फ़्लोट
    • चैनल: मोनो, स्टीरियो, ज़्यादा से ज़्यादा आठ चैनलों के साथ मान्य मल्टीचैनल कॉन्फ़िगरेशन
    • सैंपलिंग रेट (हर्ट्ज़ में):
      • ऊपर सूची में दिए गए चैनल कॉन्फ़िगरेशन पर 8,000, 11,025, 16,000, 22,050, 24,000, 32,000, 44,100, 48,000
      • मोनो और स्टीरियो में 96000

5.5.2. ऑडियो इफ़ेक्ट

Android, डिवाइस पर ऑडियो इफ़ेक्ट के लिए एपीआई उपलब्ध कराता है.

अगर लागू किए गए डिवाइस पर android.hardware.audio.output सुविधा का एलान किया जाता है, तो:

  • [C-1-1] ऑडियो इफ़ेक्ट की सब-क्लास Equalizer और LoudnessEnhancer के ज़रिए, EFFECT_TYPE_EQUALIZER और EFFECT_TYPE_LOUDNESS_ENHANCER को लागू करने के तरीके को कंट्रोल किया जा सकता है.
  • [C-1-2] इसमें विज़ुअलाइज़र एपीआई लागू करने की सुविधा होनी चाहिए. इसे Visualizer क्लास से कंट्रोल किया जा सकता है.
  • [C-1-3] ऑडियो इफ़ेक्ट सब-क्लास DynamicsProcessing की मदद से, EFFECT_TYPE_DYNAMICS_PROCESSING को लागू करने की सुविधा दी जानी चाहिए.

नई ज़रूरी शर्तें लागू करें

  • [C-1-4] फ़्लोटिंग-पॉइंट इनपुट और आउटपुट के साथ ऑडियो इफ़ेक्ट काम करना ज़रूरी है.
  • [C-1-5] यह पक्का करना ज़रूरी है कि ऑडियो इफ़ेक्ट, मिक्सर चैनलों की संख्या के लिए भी एफ़सीसी_LIMIT तक के कई चैनलों के साथ काम करते हों.

नई ज़रूरी शर्तें खत्म करना

  • EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB, और EFFECT_TYPE_VIRTUALIZER को लागू करने के साथ काम करना चाहिए. इसे AudioEffect सब-क्लास BassBoost,EnvironmentalReverb, PresetReverb, और Virtualizer के ज़रिए कंट्रोल किया जा सकता है.
  • [C-SR-1] फ़्लोट करने वाले पॉइंट और मल्टीचैनल में इफ़ेक्ट लागू करने के लिए, इस बात का खास तौर पर सुझाव दिया जाता है.

5.5.3. ऑडियो आउटपुट की आवाज़

वाहन संबंधित डिवाइस पर विज्ञापन लागू करना:

  • आपको हर ऑडियो स्ट्रीम के हिसाब से, ऑडियो की आवाज़ को अलग-अलग अडजस्ट करने की अनुमति देनी चाहिए. ऐसा करने के लिए, ऑडियो एट्रिब्यूट में बताए गए कॉन्टेंट टाइप या इस्तेमाल का इस्तेमाल करना चाहिए. साथ ही, android.car.CarAudioManager में सार्वजनिक तौर पर बताई गई कार के ऑडियो के इस्तेमाल की अनुमति देनी चाहिए.

5.5.4. ऑडियो ऑफ़लोड

अगर लागू किए गए डिवाइस पर ऑडियो ऑफ़लोड प्लेबैक काम करता है, तो ये:

  • [C-SR-1] हमारा सुझाव है कि जब ऑडियो ट्रैक गैपलेस एपीआई और MediaPlayer के लिए मीडिया कंटेनर के बारे में बताया गया हो, तब एक ही फ़ॉर्मैट वाली दो क्लिप के बीच, एक ही फ़ॉर्मैट वाले गैपलेस ऑडियो कॉन्टेंट में काट-छांट करें.

5.6. ऑडियो के लिए इंतज़ार का समय

ऑडियो के सिग्नल के एक सिस्टम से होकर गुज़रने में लगने वाले समय को, ऑडियो के इंतज़ार का समय कहते हैं. ऐप्लिकेशन की कई क्लास में रीयल-टाइम साउंड इफ़ेक्ट पाने के लिए, इंतज़ार का समय कम समय पर पूरा होता है.

इस सेक्शन के लिए, इन परिभाषाओं का इस्तेमाल करें:

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

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

  • OpenSL ES PCM बफ़र क्यू एपीआई. यह Android एनडीके में पीसीएम से जुड़े OpenSL ES एपीआई का सेट है.

  • ऑडियो नेटिव ऑडियो एपीआई. Android एनडीके में AAudio एपीआई का सेट.

  • टाइमस्टैंप. किसी स्ट्रीम में, फ़्रेम के रिलेटिव पोज़िशन और उससे जुड़े एंडपॉइंट पर फ़्रेम के ऑडियो प्रोसेसिंग पाइपलाइन में जाने और उससे निकलने में लगने वाले अनुमानित समय की जानकारी. ऑडियो टाइमस्टैंप भी देखें.

  • glitch. ऑडियो सिग्नल में कुछ समय के लिए आने वाली रुकावट या सैंपल की गलत वैल्यू. आम तौर पर, यह गड़बड़ी आउटपुट के लिए बफ़र अंडररन, इनपुट के लिए बफ़र ओवररन, डिजिटल या ऐनालॉग नॉइज़ के किसी अन्य सोर्स की वजह से होती है.

  • का मतलब है कुल डेविएशन. मानों के सेट के मीन से विचलन के निरपेक्ष मान का औसत.

  • इंतज़ार का समय टैप करें. स्क्रीन को टैप करने और उस टैप की वजह से जनरेट होने वाली टोन के स्पीकर पर सुनाई देने के बीच का समय.

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

  • [C-1-1] AudioTrack.getTimestamp और AAudioStream_getTimestamp से मिला आउटपुट टाइमस्टैंप, +/- 2 मि॰से॰ के हिसाब से सटीक होता है.
  • [C-1-2] 500 मिलीसेकंड या उससे कम की कोल्ड आउटपुट इंतज़ार का समय.

  • [C-1-3] AAudioStreamBuilder_openStream() का इस्तेमाल करके आउटपुट स्ट्रीम खोलने में 1000 मिलीसेकंड से कम समय लगना चाहिए.

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

  • [C-SR-1] स्पीकर के डेटा पाथ पर, कोल्ड आउटपुट के लिए इंतज़ार का समय 100 मिलीसेकंड या उससे कम होना चाहिए.
  • [C-SR-2] टैप-टू-टोन इंतज़ार का समय 80 मिलीसेकंड या इससे कम.

  • [C-SR-4] AudioTrack.getTimestamp और AAudioStream_getTimestamp से मिला आउटपुट टाइमस्टैंप, +/- 1 मि॰से॰ के हिसाब से सटीक होता है.

नई ज़रूरी शर्तें लागू करें

  • [C-SR-4] AAudioStream_getTimestamp से मिले इनपुट और आउटपुट टाइमस्टैंप के आधार पर परिकलित दोतरफ़ा यात्रा के इंतज़ार का समय, AAUDIO_PERFORMANCE_MODE_NONE और स्पीकर, वायर वाले और वायरलेस हेडसेट के लिए AAUDIO_PERFORMANCE_MODE_LOW_LATENCY के लिए मापी गई दोतरफ़ा यात्रा के इंतज़ार के समय से 30 मि॰से॰ के अंदर होना चाहिए.

नई ज़रूरी शर्तें खत्म करना

अगर डिवाइस लागू करने की प्रोसेस ऊपर बताई गई ज़रूरी शर्तों को पूरा करती है, तो AAudio Native Audio API का इस्तेमाल करते समय, कम से कम एक काम करने वाले ऑडियो आउटपुट डिवाइस पर, लगातार आउटपुट इंतज़ार का समय और कोल्ड आउटपुट इंतज़ार का समय दिखने पर ये काम करती हैं:

  • [C-SR-5] android.hardware.audio.low_latency फ़ीचर फ़्लैग का एलान करके, इंतज़ार का समय कम होने पर रिपोर्ट करने का सुझाव दिया जाता है.
  • [C-SR-6] ऑडियो एपीआई की मदद से, वीडियो स्ट्रीम होने और उसके दिखने के समय का अंतर कम होने से जुड़ी शर्तों को पूरा करने का खास तौर पर सुझाव दिया जाता है.
  • [C-SR-7] इस बात का खास तौर पर सुझाव दिया जाता है कि AAUDIO_PERFORMANCE_MODE_LOW_LATENCY AAudioStream_getPerformanceMode() से आने वाली स्ट्रीम के लिए AAudioStream_getFramesPerBurst() से मिलने वाली वैल्यू, प्रॉपर्टी कुंजी AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER के लिए android.media.AudioManager.getProperty(String) से मिलने वाली वैल्यू से कम या उसके बराबर हो.

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

  • [C-2-1] 'वीडियो स्ट्रीम होने और उसके दिखने के समय का अंतर कम होने पर' सुविधा के साथ काम नहीं करना चाहिए.

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

  • [C-3-1] इनपुट के टाइमस्टैंप में गड़बड़ी को सीमित करें, जैसा कि AudioRecord.gettimestamp या AAudioStream_getTimestamp से मिलता है, +/- 2 मि॰से॰ तक. यहां "गड़बड़ी" का मतलब है सही वैल्यू में अंतर.
  • [C-3-2] 500 मिलीसेकंड या उससे कम का कोल्ड इनपुट इंतज़ार का समय.
  • [C-3-3] AAudioStreamBuilder_openStream() का इस्तेमाल करके, किसी इनपुट स्ट्रीम को खोलने में 1,000 मिलीसेकंड से कम समय लगना चाहिए.

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

  • [C-SR-8] माइक्रोफ़ोन के डेटा पाथ पर, 100 मिलीसेकंड या उससे कम कोल्ड इनपुट इंतज़ार का समय.

  • [C-SR-11] इनपुट के टाइमस्टैंप में दिखने वाली गड़बड़ी को AudioRecord.gettimestamp या AAudioStream_getTimestamp से मिलने वाली गड़बड़ी को, +/- 1 मि॰से॰ तक सीमित करें.

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

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

5.7. नेटवर्क प्रोटोकॉल

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

हर उस कोडेक और कंटेनर फ़ॉर्मैट के लिए डिवाइस को लागू करने की प्रोसेस जिसके लिए डिवाइस को लागू करना ज़रूरी है:

  • [C-1-1] उस कोडेक या कंटेनर को एचटीटीपी और एचटीटीपीएस पर चलाया जा सकता हो.

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

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

मीडिया सेगमेंट के फ़ॉर्मैट

सेगमेंट के फ़ॉर्मैट संदर्भ आवश्यक कोडेक समर्थन
MPEG-2 ट्रांसपोर्ट स्ट्रीम आईएसओ 13818 वीडियो कोडेक:
  • H264 एवीसी
  • एमपीईजी-4 एसपी
  • MPEG-2
H264 एवीसी, MPEG2-4 SP,
और MPEG-2 के बारे में ज़्यादा जानकारी के लिए, सेक्शन 5.1.8 देखें.

ऑडियो कोडेक:

  • AAC
AAC और उसके वैरिएंट के बारे में जानकारी के लिए, सेक्शन 5.1.3 देखें.
ADTS फ़्रेमिंग और ID3 टैग के साथ AAC आईएसओ 13818-7 AAC और इसके वैरिएंट की जानकारी के लिए, सेक्शन 5.1.1 देखें
WebVTT WebVTT

आरटीएसपी (आरटीपी, एसडीपी)

प्रोफ़ाइल का नाम संदर्भ आवश्यक कोडेक समर्थन
H264 एवीसी आरएफ़सी 6184 H264 एवीसी से जुड़ी जानकारी के लिए, सेक्शन 5.1.8 देखें
MP4A-एलएटीएम आरएफ़सी 6416 AAC और इसके वैरिएंट की जानकारी के लिए, सेक्शन 5.1.3 देखें
H263-1998 आरएफ़सी 3551
आरएफ़सी 4629
आरएफ़सी 2190
H263 के बारे में जानकारी के लिए, सेक्शन 5.1.8 देखें
H263-2000 की उम्र आरएफ़सी 4629 H263 के बारे में जानकारी के लिए, सेक्शन 5.1.8 देखें
एएमआर आरएफ़सी 4867 AMR-NB के बारे में जानकारी के लिए, सेक्शन 5.1.3 देखें
एएमआर-डब्ल्यूबी आरएफ़सी 4867 AMR-WB के बारे में जानकारी के लिए, सेक्शन 5.1.3 देखें
एमपी4वी-ईएस आरएफ़सी 6416 MPEG-4 एसपी के बारे में जानकारी के लिए, सेक्शन 5.1.8 देखें
mpeg4-जेनरिक आरएफ़सी 3640 AAC और इसके वैरिएंट की जानकारी के लिए, सेक्शन 5.1.3 देखें
एमपी2टी आरएफ़सी 2250 ज़्यादा जानकारी के लिए, एचटीटीपी लाइव स्ट्रीमिंग के नीचे MPEG-2 ट्रांसपोर्ट स्ट्रीम देखें

5.8. सुरक्षित मीडिया

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

  • [C-1-1] Display.FLAG_SECURE के लिए सहायता का एलान करना ज़रूरी है.

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

  • [C-2-1] लिंक को क्रिप्टोग्राफ़िक तरीके से मज़बूत सिस्टम की मदद से सुरक्षित करना ज़रूरी है. जैसे, Miracast जैसे वायरलेस प्रोटोकॉल से कनेक्ट किए गए डिसप्ले के लिए, HDCP 2.x या उसके बाद वाले वर्शन का इस्तेमाल करना.

अगर डिवाइस लागू करने की सुविधा, Display.FLAG_SECURE के साथ काम करती है और तार वाले बाहरी डिसप्ले के साथ काम करती है, तो वे:

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

5.9. म्यूज़िकल इंस्ट्रुमेंट डिजिटल इंटरफ़ेस (एमआईडीआई)

अगर डिवाइस, android.content.pm.PackageManager क्लास के ज़रिए सुविधा android.software.midi के लिए रिपोर्ट पर काम करता है, तो वे:

  • [C-1-1] एमआईडीआई की मदद से काम करने वाले सभी हार्डवेयर ट्रांसपोर्ट के बजाय, एमआईडीआई की मदद से काम करना चाहिए, ताकि इनके लिए सामान्य नॉन-एमआईडीआई कनेक्टिविटी दी जा सके. हालांकि, इस तरह के ट्रांसपोर्ट में ये शामिल होते हैं:

    • यूएसबी होस्ट मोड, सेक्शन 7.7
    • एमआईडीआई ओवर ब्लूटूथ LE में मुख्य भूमिका में काम कर रहा है, सेक्शन 7.4.3
  • [C-1-2] इंटर-ऐप्लिकेशन एमआईडीआई सॉफ़्टवेयर ट्रांसपोर्ट के साथ काम करना ज़रूरी है (वर्चुअल एमआईडीआई डिवाइस)

  • [C-1-3] इसमें libamidi.so (स्थानीय एमआईडीआई की सुविधा) को शामिल करना ज़रूरी है

  • यूएसबी सहायक डिवाइस (जैसे, कीबोर्ड, माउस, मॉनिटर, वेबकैम वगैरह) पर एमआईडीआई मोड के साथ काम करना चाहिए, सेक्शन 7.7

5.10. प्रोफ़ेशनल ऑडियो

अगर डिवाइस लागू करने की प्रोसेस, android.content.pm.PackageManager क्लास के ज़रिए android.hardware.audio.pro सुविधा के लिए सहायता की रिपोर्ट देती है, तो वे:

  • [C-1-1] android.hardware.audio.low_latency सुविधा के लिए सहायता की जानकारी देना ज़रूरी है.
  • [C-1-2] दोतरफ़ा यात्रा के दौरान, ऑडियो के इंतज़ार का समय एक जैसा होना चाहिए, जैसा कि 5.6 ऑडियो के इंतज़ार का समय सेक्शन में बताया गया है. यह इंतज़ार का समय 25 मिलीसेकंड या इससे कम होना चाहिए. इसके लिए, इस्तेमाल किए जा सकने वाले कम से कम एक पाथ का इस्तेमाल किया जाना चाहिए.
  • [C-1-3] यूएसबी होस्ट मोड और सहायक डिवाइस(जैसे, कीबोर्ड, माउस, मॉनिटर, वेबकैम वगैरह) के साथ काम करने वाले यूएसबी पोर्ट शामिल होने चाहिए.
  • [C-1-4] android.software.midi सुविधा के लिए सहायता की जानकारी देना ज़रूरी है.
  • [C-1-5] AAudio नेटिव ऑडियो एपीआई और AAUDIO_PERFORMANCE_MODE_LOW_LATENCY का इस्तेमाल करके, इंतज़ार के समय और यूएसबी ऑडियो की ज़रूरी शर्तों को पूरा करना ज़रूरी है.
  • [C-1-6] कोल्ड आउटपुट के लिए इंतज़ार का समय 200 मिलीसेकंड या इससे कम होना चाहिए.
  • [C-1-7] कोल्ड इनपुट इंतज़ार का समय 200 मिलीसेकंड या इससे कम होना चाहिए.
  • [C-1-8] स्पीकर से माइक्रोफ़ोन डेटा पाथ का इस्तेमाल करने पर, टैप-टू-टोन के इंतज़ार का समय कम से कम पांच मिलीसेकंड या इससे कम होना चाहिए.

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

  • [C-SR-2] का खास तौर पर सुझाव दिया जाता है कि mMAP पाथ पर A Audio नेटिव ऑडियो एपीआई का इस्तेमाल करके, दोतरफ़ा यात्रा के ऑडियो के इंतज़ार का समय, कोल्ड इनपुट इंतज़ार का समय, कोल्ड आउटपुट इंतज़ार का समय, और यूएसबी ऑडियो से जुड़ी ज़रूरतों को पूरा करने के लिए Pro Audio की ज़रूरी शर्तें पूरी की जाएं.

  • [C-SR-3] ऑडियो के चालू रहने और अलग-अलग सीपीयू पर लोड होने पर, सीपीयू की परफ़ॉर्मेंस को एक जैसा बनाए रखने के लिए, इस बात का खास तौर पर सुझाव दिया जाता है. इसकी जांच Android ऐप्लिकेशन SynthMark का इस्तेमाल करके की जानी चाहिए. SynthMark, सिम्युलेटेड ऑडियो फ़्रेमवर्क पर चलने वाले सॉफ़्टवेयर सिंथेसाइज़र का इस्तेमाल करता है. यह सिस्टम की परफ़ॉर्मेंस का आकलन करता है. मानदंडों की जानकारी के लिए, SynthMark दस्तावेज़ देखें. SynthMark ऐप्लिकेशन को “ऑटोमेटेड टेस्ट” विकल्प का इस्तेमाल करके चलाना चाहिए और उससे ये नतीजे मिल सकते हैं:

    • Voicemark.90 >= 32 आवाज़ें
    • Latitudemark.fixed.little <= 15 मि॰से॰
    • लेटेंसीमार्क.डाइनैमिक.लिटल <= 50 मि॰से॰
  • ऑडियो क्लॉक की गलतियों को कम से कम करना चाहिए और स्टैंडर्ड समय के हिसाब से ड्रिफ़्ट होना चाहिए.

  • दोनों के चालू होने पर, CLOCK_MONOTONIC के हिसाब से ऑडियो क्लॉक ड्रिफ़्ट कम होना चाहिए.

  • डिवाइस पर मौजूद ट्रांसड्यूसर से, ऑडियो में देरी को कम किया जाना चाहिए.

  • USB डिजिटल ऑडियो पर ऑडियो प्रतीक्षा अवधि को कम करना चाहिए.

  • सभी पाथ के लिए, आवाज़ के इंतज़ार के समय को रिकॉर्ड करना चाहिए.

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

  • रिपोर्ट की गई इंतज़ार के समय के लिए, सामान्य इस्तेमाल के दौरान ऑडियो में कोई ग्लिच नहीं होनी चाहिए.

  • एक चैनल से दूसरे चैनल पर वीडियो अपलोड होने और उसके दिखने के बीच इंतज़ार के समय के अंतर का कोई अंतर नहीं होना चाहिए.

  • सभी ट्रांसपोर्ट के लिए, एमआईडीआई का मतलब कम से कम होना चाहिए.

  • सभी ट्रांसपोर्ट में, लोड (जीटर) में एमआईडीआई में देरी में होने वाले उतार-चढ़ाव को कम करना चाहिए.

  • सभी ट्रांसपोर्ट के लिए, एमआईडीआई के सटीक टाइमस्टैंप देने चाहिए.

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

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

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

  • इसके एंड-पॉइंट के इनपुट और आउटपुट साइड के लिए, HAL ऑडियो बफ़रिंग के फ़ेज़ के अंतर को कम किया जाना चाहिए.

  • इसलिए, स्क्रीन पर टच होने में लगने वाले समय को कम किया जाना चाहिए.

  • लोड में टच इंतज़ार के समय में उतार-चढ़ाव को कम किया जाना चाहिए (जीटर).

अगर डिवाइस लागू करने की सुविधा ऊपर दी गई सभी ज़रूरी शर्तों को पूरा करती है, तो वे:

  • [C-SR-4] android.content.pm.PackageManager क्लास के ज़रिए, android.hardware.audio.pro सुविधा के बारे में रिपोर्ट करने का सुझाव दिया जाता है.

अगर लागू किए जाने वाले डिवाइसों में 4 कंडक्टर 3.5 मि॰मी॰ का ऑडियो जैक शामिल है, तो वे:

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

  • [C-3-1] यूएसबी ऑडियो क्लास लागू करना ज़रूरी है.
  • [C-3-2] यूएसबी ऑडियो क्लास का इस्तेमाल करके, यूएसबी होस्ट मोड पोर्ट पर पांच मिलीसेकंड से कम का मीन ऐब्सलूट डेविएशन होना चाहिए. साथ ही, 25 मिलीसेकंड या उससे कम के 'लगातार 'राउंड-ट्रिप वाले ऑडियो' के लिए इंतज़ार का औसत समय होना चाहिए. (इसे यूएसबी-3.5 मि॰मी॰ के अडैप्टर और ऑडियो लूपबैक डोंगल का इस्तेमाल करके मापा जा सकता है. इसके अलावा, आउटपुट से इनपुट को कनेक्ट करने वाले पैच केबल वाले यूएसबी ऑडियो इंटरफ़ेस का इस्तेमाल करके भी इसे मापा जा सकता है).
  • [C-SR-6] इन शर्तों को पूरा करने वाले यूएसबी ऑडियो सहायक डिवाइसों के साथ इस्तेमाल किए जाने पर, इस बात की काफ़ी सलाह दी जाती है कि I/O एक साथ आठ चैनल, 96 किलोहर्ट्ज़ का सैंपल रेट, और 24-बिट या 32-बिट की गहराई इस्तेमाल किया जा सकता है.
  • [C-SR-7] ज़रूरी शर्तों के इस ग्रुप को पूरा करने के लिए, इस बात का खास तौर पर सुझाव दिया जाता है कि MMAP पाथ पर AAudio नेटिव ऑडियो एपीआई इस्तेमाल किया जाए.

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

  • स्टीरियो और आठ चैनलों में आउटपुट को 20-बिट या 24-बिट डेप्थ पर और 192 किलोहर्ट्ज़ पर, कम से कम एक कॉन्फ़िगरेशन में बिट-डेप्थ की कमी या रीसैंपलिंग के बिना काम करना चाहिए.

5.11. प्रोसेस नहीं किए गए के लिए कैप्चर करें

Android में android.media.MediaRecorder.AudioSource.UNPROCESSED ऑडियो सोर्स से, प्रोसेस नहीं किए गए ऑडियो को रिकॉर्ड करने की सुविधा शामिल है. OpenSL ES में, इसे रिकॉर्ड प्रीसेट की मदद से ऐक्सेस किया जा सकता है SL_ANDROID_RECORDING_PRESET_UNPROCESSED.

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

  • [C-1-1] android.media.AudioManager प्रॉपर्टी PROPERTY_SUPPORT_AUDIO_SOURCE_UN कारोबार का इस्तेमाल करके, सहायता की रिपोर्ट करना ज़रूरी है.

  • [C-1-2] ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए जाने वाले हर माइक्रोफ़ोन के लिए, फ़्रीक्वेंसी रेंज में करीब सपाट डाइमेंशन और फ़्रीक्वेंसी फ़्रीक्वेंसी दिखाना ज़रूरी है: खास तौर पर, 100 हर्ट्ज़ से लेकर 7,000 हर्ट्ज़ तक.

  • [C-1-3] ऑडियो के कम फ़्रीक्वेंसी वाली रेंज में आयाम के लेवल दिखाए जाने चाहिए: खास तौर पर, प्रोसेस नहीं किए गए ऑडियो सोर्स को रिकॉर्ड करने वाले हर माइक्रोफ़ोन के लिए, औसत फ़्रीक्वेंसी रेंज की तुलना में ±20 dB से लेकर 5 हर्ट्ज़ से लेकर 100 हर्ट्ज़ तक.

  • [C-1-4] ज़्यादा फ़्रीक्वेंसी वाली रेंज में आयाम के लेवल दिखाए जाने चाहिए: खास तौर पर, प्रोसेस नहीं किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए जाने वाले हर माइक्रोफ़ोन की रेंज की तुलना में, खास तौर पर 7,000 हर्ट्ज़ से लेकर 22 किलोहर्ट्ज़ तक, 30 dB से लेकर 22 किलोहर्ट्ज़ तक.

  • [C-1-5] ऑडियो इनपुट संवेदनशीलता को इस तरह सेट करना ज़रूरी है कि 94 dB के साउंड प्रेशर लेवल (SPL) पर चलाए जाने वाले 1000 हर्ट्ज़ वाले साइनोसोइडल टोन सोर्स से हर एक के लिए 16 बिट-सैंपल (या हर माइक्रोफ़ोन/दोगुने सटीक ऑडियो रिकॉर्ड के लिए फ़्लोटिंग पॉइंट/डबल रिकॉर्ड वाले ऑडियो सोर्स के लिए -36 dB फ़ुल स्केल) के लिए 520 के आरएमएस के साथ रिस्पॉन्स मिलता है.

  • [C-1-6] प्रोसेस नहीं किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए जाने वाले हर माइक्रोफ़ोन के लिए, 60 dB या इससे ज़्यादा का सिग्नल-टू-नॉइज़ रेशियो (SNR) होना चाहिए. (वहीं एसएनआर को 94 dB SPL और सेल्फ़ नॉइज़ के बराबर के एसपीएल यानी A-वेट के बीच के अंतर के तौर पर मापा जाता है).

  • [C-1-7] प्रोसेस न किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए जाने वाले हर माइक्रोफ़ोन पर, 90 dB SPL इनपुट लेवल पर 1 किलोहर्ट्ज़ के लिए 1% से कम हारमोनिक डिस्टॉर्शन (टीएचडी) होना चाहिए.

  • [C-1-8] लेवल को अपने हिसाब से रेंज में लाने के लिए, लेवल मल्टीप्लायर के अलावा, किसी दूसरे पाथ में सिग्नल प्रोसेसिंग (जैसे, ऑटोमैटिक गेन कंट्रोल, हाई पास फ़िल्टर या इको रद्द करना) की ज़रूरत नहीं होनी चाहिए. दूसरे शब्दों में:

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

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

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

  • [C-2-1] AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) एपीआई वाले तरीके के लिए null देना ज़रूरी है, ताकि इस गड़बड़ी के बारे में सही तरीके से बताया जा सके.
  • प्रोसेस न किए गए रिकॉर्डिंग सोर्स के सिग्नल पाथ की सभी ज़रूरी शर्तों को पूरा करने