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

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

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

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

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

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

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

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

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

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

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

2.2.1. हार्डवेयर

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

[7.1.1.1/H-0-1] Android के साथ काम करने वाला कम से कम एक ऐसा डिसप्ले होना चाहिए जो इस दस्तावेज़ में दी गई सभी ज़रूरी शर्तें पूरी करता हो.
[7.1.1.3/H-SR-1] लोगों को डिसप्ले साइज़ (स्क्रीन की सघनता) बदलने की सुविधा देने के लिए, इस बात का बहुत ज़्यादा सुझाव दिया जाता है.
[7.1.1.1/H-0-2] कम से कम किसी बिल्ट-इन डिसप्ले के सबसे ज़्यादा रिज़ॉल्यूशन जितने बड़े ग्राफ़िक बफ़र के जीपीयू कंपोज़िशन पर काम करना ज़रूरी है.

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

[7.1.1.1/H-1-1]* तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराई गई लॉजिकल स्क्रीन ज़रूर बनाएं. यह स्क्रीन के लंबे किनारों पर कम से कम 2 इंच और लंबे किनारों पर 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 मेगाहर्ट्ज़ की फ़्रीक्वेंसी

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

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

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

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

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

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

[7.6.1/H-1-1] अगर डिफ़ॉल्ट डिसप्ले, qHD (जैसे FWVGA) तक के फ़्रेमबफ़र रिज़ॉल्यूशन का इस्तेमाल करता है, तो कर्नेल और यूज़रस्पेस के लिए उपलब्ध मेमोरी कम से कम 416 एमबी होनी चाहिए.
[7.6.1/H-2-1] अगर डिफ़ॉल्ट डिसप्ले एचडी+ (जैसे कि 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] सिर्फ़ एक एबीआई के साथ काम करना ज़रूरी है (सिर्फ़ 64-बिट या सिर्फ़ 32-बिट).

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

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

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

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

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

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

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

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

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

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

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

[7.10/H]* एक बहुत ज़्यादा रोटेटिंग मास (ईआरएम) हैप्टिक एक्चुएटर (वाइब्रेटर) का इस्तेमाल नहीं करना चाहिए.
[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]* हैप्टिक एक्चुएटर को पोर्ट्रेट ओरिएंटेशन के X-ऐक्सिस (बाएं दाएं) में ले जाना चाहिए.

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

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

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

[7.10/H]* android.os.Vibrator.areAllimpactsSupported() और android.os.Vibrator.arePrimitives बेझिझक() एपीआई को चलाकर, लागू करने की स्थिति की पुष्टि करनी चाहिए.
[7.10/H]* हैप्टिक कॉन्सटेंट के लिए क्वालिटी की जांच करनी चाहिए.
[7.10/H]* काम न करने वाले प्रिमिटिव के लिए फ़ॉलबैक कॉन्फ़िगरेशन की पुष्टि करना और उसे अपडेट करना ज़रूरी है. इसकी जानकारी, कॉन्सटेंट के लिए लागू करने से जुड़े दिशा-निर्देश में दी गई है.

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

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 की सूचना पोस्ट करता है.

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

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

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

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

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

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

[9.11/H-0-2] कीस्टोर को लागू करने के तरीके का बैक अप लेना ज़रूरी है. इसके लिए, आपको एक अलग एनवायरमेंट का इस्तेमाल करना होगा.
[9.11/H-0-3] आरएसए, एईएस, ईसीडीएसए, और एचएमएसी क्रिप्टोग्राफ़िक एल्गोरिदम और 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 यूनिट के लिए अलग-अलग कुंजी का इस्तेमाल किया जा सकता है.
[9/H-0-1] ‘android.hardware.security.model.supported’ सुविधा के बारे में एलान करना ज़रूरी है.

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

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

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

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

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

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

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

Android, System API की मदद से Voiceइंटरैक्शनService, माइक ऐक्सेस संकेत के बिना, हमेशा चालू रहने वाले हॉटवर्ड का सुरक्षित तरीके से पता लगाने की सुविधा देता है

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

[9.8/H-1-1] यह पक्का करना ज़रूरी है कि हॉटवर्ड का पता लगाने वाली सेवा सिर्फ़ System या Content CaptureService को डेटा भेज सके
[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-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 के अलावा, ऑडियो या हॉटवर्ड से नहीं जुड़े ऑडियो कॉन्टेंट को फिर से बनाने (पूरी तरह या कुछ हद तक) इस्तेमाल करने के लिए इस्तेमाल किया जा सकता है, को ट्रांसमिट नहीं करना चाहिए.

अगर हैंडहेल्ड डिवाइस पर लागू होने वाले 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.S दिखाते हैं, तो ये:

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

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

[5.1/H-1-1] CodecCapabilities.getMaxSupportedInstances() और VideoCapabilities.getSupportedPerformancePoints() तरीकों का इस्तेमाल करके, किसी भी कोडेक कॉम्बिनेशन में एक साथ चलाए जा सकने वाले हार्डवेयर वीडियो डिकोडर सेशन की ज़्यादा से ज़्यादा संख्या का विज्ञापन करना ज़रूरी है.
[5.1/H-1-2] हार्डवेयर वीडियो डिकोडर सेशन के छह इंस्टेंस (एवीसी, एचईवीसी, VP9, AV1 या बाद के वर्शन) एक साथ 1080p रिज़ॉल्यूशन@30 एफ़पीएस (फ़्रेम प्रति सेकंड) पर चलने वाले होने चाहिए.
[5.1/H-1-3] CodecCapabilities.getMaxSupportedInstances() और VideoCapabilities.getSupportedPerformancePoints() तरीकों का इस्तेमाल करके, किसी भी कोडेक कॉम्बिनेशन में एक साथ चलाए जा सकने वाले हार्डवेयर वीडियो एन्कोडर सेशन की ज़्यादा से ज़्यादा संख्या का विज्ञापन करना ज़रूरी है.
[5.1/H-1-4] 1080p रिज़ॉल्यूशन@30fps पर, एक साथ चलने वाले किसी भी कोडेक कॉम्बिनेशन में, हार्डवेयर वीडियो एन्कोडर सेशन के छह इंस्टेंस (एवीसी, एचईवीसी, VP9, AV1 या इसके बाद के वर्शन) पर काम करना ज़रूरी है.
[5.1/H-1-5] हार्डवेयर वीडियो एन्कोडर और डिकोडर सेशन की ज़्यादा से ज़्यादा संख्या का विज्ञापन करना ज़रूरी है जो CodecCapabilities.getMaxSupportedInstances() और VideoCapabilities.getSupportedPerformancePoints() तरीकों का इस्तेमाल करके किसी भी कोडेक कॉम्बिनेशन में एक साथ चलाए जा सकते हैं.
[5.1/H-1-6] 1080p@30fps रिज़ॉल्यूशन पर एक साथ चल रहे किसी भी कोडेक कॉम्बिनेशन में, हार्डवेयर वीडियो डिकोडर और हार्डवेयर वीडियो एन्कोडर सेशन (एवीसी, एचईवीसी, VP9, AV1 या बाद के वर्शन) के 6 इंस्टेंस के साथ काम करना ज़रूरी है.
[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] 1080p रिज़ॉल्यूशन@30 FPS (फ़्रेम प्रति सेकंड) पर चलने वाले किसी भी कोडेक कॉम्बिनेशन में सुरक्षित हार्डवेयर वीडियो डिकोडर के दो इंस्टेंस (एवीसी, एचईवीसी, VP9, AV1 या बाद के वर्शन) पर काम करना ज़रूरी है.
[5.1/H-1-10] 1080p रिज़ॉल्यूशन@30fps पर एक साथ चल रहे किसी भी कोडेक कॉम्बिनेशन में, सुरक्षित हार्डवेयर वीडियो डिकोडर सेशन के एक इंस्टेंस के साथ तीन असुरक्षित हार्डवेयर वीडियो डीकोडर सेशन (कुल चार इंस्टेंस) (कुल चार इंस्टेंस) के साथ काम करना ज़रूरी है.
[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-SR-1] AV1 हार्डवेयर डिकोडर के लिए फ़िल्म ग्रेन का समर्थन करने के लिए विशेष रूप से सुझाया जाता है.
[5.1/H-1-15] 4K60 रिज़ॉल्यूशन के साथ काम करने वाला कम से कम एक हार्डवेयर वीडियो डिकोडर होना चाहिए.
[5.1/H-1-16] इसमें 4K60 के साथ काम करने वाला कम से कम एक हार्डवेयर वीडियो एन्कोडर होना चाहिए.
[5.3/H-1-1] लोड होने वाले 1080p 60 FPS वीडियो सेशन के लिए, 10 सेकंड में एक से ज़्यादा फ़्रेम नहीं छोड़ना चाहिए (यानी कि 0.167 प्रतिशत से कम फ़्रेम में गिरावट). लोड को हार्डवेयर वीडियो कोडेक और 128 केबीपीएस एएसी ऑडियो प्लेबैक का इस्तेमाल करके, सिर्फ़ 1080 पिक्सल से 720 पिक्सल वाले वीडियो ट्रांसकोडिंग सेशन के रूप में दिखाया जाता है.
[5.3/H-1-2] लोड पर चल रहे 60 FPS वीडियो सेशन के रिज़ॉल्यूशन में बदलाव के दौरान, 10 सेकंड में एक फ़्रेम से ज़्यादा नहीं छोड़ा जाना चाहिए. लोड को हार्डवेयर वीडियो कोडेक और 128 केबीपीएस एएसी ऑडियो प्लेबैक का इस्तेमाल करके, सिर्फ़ 1080 पिक्सल से 720 पिक्सल के वीडियो ट्रांसकोडिंग सेशन के रूप में दिखाया जाता है.
[5.6/H-1-1] OboeTester के टैप-टू-टोन टेस्ट या CTS Verifier टैप-टू-टोन टेस्ट का इस्तेमाल करके 80 मिलीसेकंड या इससे कम समय के लिए टैप-टू-टोन इंतज़ार का समय होना चाहिए.
[5.6/H-1-2] कम से कम एक काम करने वाले डेटा पाथ पर, ऑडियो के इंतज़ार का समय 80 मिलीसेकंड या इससे कम होना चाहिए.
[5.6/H-1-3] स्टीरियो आउटपुट के लिए 3.5 मि॰मी॰ से ज़्यादा के ऑडियो जैक के लिए >=24-बिट ऑडियो काम करना चाहिए. अगर ऐसा है, तो इंतज़ार का समय कम करने और स्ट्रीमिंग कॉन्फ़िगरेशन के लिए पूरे डेटा पाथ के साथ काम करने पर, यूएसबी ऑडियो पर काम करता है. इंतज़ार का समय कम करने वाले कॉन्फ़िगरेशन के लिए, ऐप्लिकेशन को लो-लेटेंसी कॉलबैक मोड में ऑडियो का इस्तेमाल करना चाहिए. स्ट्रीमिंग कॉन्फ़िगरेशन के लिए, ऐप्लिकेशन को Java AudioTrack का इस्तेमाल करना चाहिए. इंतज़ार का समय और स्ट्रीमिंग कॉन्फ़िगरेशन, दोनों में एचएएल आउटपुट सिंक को उसके टारगेट आउटपुट फ़ॉर्मैट के लिए AUDIO_FORMAT_PCM_24_BIT, AUDIO_FORMAT_PCM_24_BIT_PACKED, AUDIO_FORMAT_PCM_32_BIT या AUDIO_FORMAT_PCM_FLOAT में से किसी एक को स्वीकार करना चाहिए.
[5.6/H-1-4] >=4 चैनल के यूएसबी ऑडियो डिवाइसों पर भी काम करना ज़रूरी है (इसका इस्तेमाल डीजे कंट्रोलर, गानों की झलक देखने के लिए करता है.)
[5.6/H-1-5] क्लास का पालन करने वाले एमआईडीआई डिवाइसों के साथ काम करना ज़रूरी है. साथ ही, एमआईडीआई की सुविधा के लिए फ़्लैग का एलान करना होगा.
[5.7/H-1-2] MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL के साथ काम करना ज़रूरी है. इसके लिए, कॉन्टेंट को डिक्रिप्ट करने की ये सुविधाएं दी गई हैं.

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

2.2.7.2. कैमरा

कैमरे को Android 12 CDD के सेक्शन 2.2.7.2 में बताई गई ज़रूरी शर्तों को पूरा करना होगा.

[7.5/H-1-1] पीछे वाला मुख्य कैमरा होना चाहिए, जिसमें कम से कम 12 मेगापिक्सल का रिज़ॉल्यूशन हो. इससे 4k@30fps पर वीडियो कैप्चर किया जा सकता है. इनमें मुख्य मुख्य कैमरा, पीछे वाला कैमरा होता है. इसका आईडी सबसे कम होता है.
[7.5/H-1-2] आपके फ़ोन में एक मुख्य कैमरा होना चाहिए, जिसका रिज़ॉल्यूशन कम से कम पांच मेगापिक्सल से हो. साथ ही, इसमें 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] दोनों प्राइमरी कैमरों के लिए, सीटीएस कैमरा परफ़ॉर्मेंसटेस्ट की जांच के मुताबिक, 1080 पिक्सल रिज़ॉल्यूशन के लिए कैमरा2 JPEG कैप्चर लेटेंसी < 1000 मि॰से॰ से कम होनी चाहिए.
[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] पीछे वाला मुख्य कैमरा होना चाहिए, जो 720 पिक्सल या 1080 पिक्सल @ 240 एफ़पीएस (फ़्रेम प्रति सेकंड) पर काम करता हो.
[7.5/H-1-10] अगर अल्ट्रावाइड आरजीबी कैमरा भी उसी दिशा में है, तो मुख्य कैमरों के लिए कम से कम ZOOM_RATIO < 1.0 होना ज़रूरी है.
[7.5/H-1-11] मुख्य कैमरों पर, एक साथ फ़्रंट-बैक वाली स्ट्रीमिंग की सुविधा लागू करनी होगी.
[7.5/H-1-12] मुख्य बैक कैमरे के लिए CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION की सुविधा ज़रूरी है.
[7.5/H-1-13] अगर पीछे एक से ज़्यादा आरजीबी कैमरे हैं, तो मुख्य कैमरे के लिए LOGICAL_MULTI_CAMERA की सुविधा काम करनी चाहिए.
[7.5/H-1-14] प्राइमरी फ़्रंट और प्राइमरी बैक कैमरे, दोनों के लिए STREAM_USE_CASE की सुविधा काम करनी चाहिए.

2.2.7.3. हार्डवेयर

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

इसे Android 12 CDD के सेक्शन 2.2.7.3 में बताई गई हार्डवेयर की ज़रूरी शर्तों को पूरा करना होगा.

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

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

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

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

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

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

Android टेलिविज़न डिवाइस का मतलब 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.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 हर्ट्ज़ पर काम कर सके.
[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-2] डिवाइस को बिना बैटरी वाले डिवाइस के तौर पर रजिस्टर करना ज़रूरी है. इसके बारे में बिना बैटरी वाले डिवाइसों के साथ काम करने वाले डिवाइस में बताया गया है.

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

[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.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 यूनिट के लिए अलग-अलग कुंजी का इस्तेमाल किया जा सकता है.
[9/T-0-1] ‘android.hardware.security.model.रोशनी’ सुविधा के बारे में एलान करना ज़रूरी है.

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

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

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 कॉन्स्टेंट का इस्तेमाल किया जा सकता है जो सिस्टम ऐप्लिकेशन के लिए उपलब्ध होने चाहिए.

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

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

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

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

[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.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.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.9.3/A-1-1] सभी उपयोगकर्ता लाइफ़साइकल प्रॉपर्टी को लागू करना ज़रूरी है
- INITIAL_USER_INFO, SWITCH_USER, CREATE_USER, REMOVE_USER.

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

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

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

[3.14/A-1-1] मीडिया सेवाओं को शामिल करना ज़रूरी है और उन्हें CAR_INTENT_ACTION_MEDIA_TEMPLATE के मकसद से खोलना है.

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

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

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

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

[8.2/A-0-1] हर प्रोसेस के यूआईडी के हिसाब से, डेटा को नॉन-वोलेटाइल स्टोरेज में पढ़े गए और लिखे गए बाइट की संख्या बताना ज़रूरी है. इससे डेवलपर को सिस्टम एपीआई की मदद से आंकड़े उपलब्ध कराए जाते हैं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. सुरक्षा मॉडल

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

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

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

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

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

[9.11/A-0-1] कीस्टोर को लागू करने के तरीके का बैक अप, एक आइसोलेटेड एक्ज़ीक्यूशन एनवायरमेंट से लेना होगा.
[9.11/A-0-2] आरएसए, एईएस, ईसीडीएसए, एचएमएसी क्रिप्टोग्राफ़िक एल्गोरिदम, और MD5, SHA1, और SHA-2 फ़ैमिली हैश फ़ंक्शन लागू करने ज़रूरी हैं, ताकि Android कीस्टोर सिस्टम के काम करने वाले एल्गोरिदम उस जगह पर सही तरीके से काम कर सकें जिसे कर्नेल और उसके बाद वाले कोड पर चलने वाले कोड से सुरक्षित तरीके से अलग किया गया है. सिक्योर आइसोलेशन से उन सभी संभावित मैकेनिज़्म को ब्लॉक कर देना चाहिए जिनकी मदद से कर्नेल या यूज़रस्पेस कोड, डीएमए के साथ-साथ आइसोलेटेड एनवायरमेंट की अंदरूनी स्थिति को ऐक्सेस कर सकते हैं. अपस्ट्रीम 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 यूनिट के लिए अलग-अलग कुंजी का इस्तेमाल किया जा सकता है.
[9/A-0-1] ‘android.hardware.security.model.supported’ सुविधा के बारे में बताना ज़रूरी है.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[C-9-1] SDK टूल से जुड़े दस्तावेज़ में बताए गए तरीके के मुताबिक, Settings#ACTION_ लेन-देन_वाई-फ़ाई _EASY_कनेक्ट_यूआरआई इंटेंट एपीआई को लागू करना ज़रूरी है.

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

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

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

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

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

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

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

[C-13-1] यूज़र इंटरफ़ेस (यूआई) को शुरू करने के इस इंटेंट android.app.action.ADD_DEVICE_ADMIN का पालन ज़रूर करना चाहिए, ताकि डिवाइस एडमिन को सिस्टम में जोड़ा जा सके (या उन्हें अस्वीकार करने की अनुमति दी जा सके).
[C-13-2] आपको android.app.action.PROVISION_MANAGED_PROFILE, android.app.action.SET_NEW_PARENT_PROFILE_Password, android.app.action.SET_NEW_Password और android.app.action.START_ENCRYPTION के मकसद का पालन करना होगा. साथ ही, इन इंटेंट के मुताबिक बताई गई SDK टूल की गतिविधि देनी होगी.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[C-SR-1] अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट से नीचे दी गई लाइब्रेरी लागू करने का सुझाव दिया जाता है.

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 फ़ंक्शन के मुख्य फ़ंक्शन के सिंबल के साथ-साथ VK_KHR_surface, VK_KHR_android_surface,VK_KHR_swapchain, VK_KHR_maintenance1, और VK_KHR_get_physical_device_properties2 एक्सटेंशन को libvulkan.so लाइब्रेरी से एक्सपोर्ट करना ज़रूरी है. ध्यान दें कि सभी सिंबल का मौजूद होना ज़रूरी है. सेक्शन 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 13 ब्रांच पर अपस्ट्रीम 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] लोगों के लिए ऐप्लिकेशन पर पाबंदी सिर्फ़ तब लागू करनी चाहिए, जब इस बात का सबूत हो कि उपयोगकर्ता ने कुछ समय से ऐप्लिकेशन का इस्तेमाल नहीं किया है. हमारा सुझाव है कि इस अवधि को एक महीना या उससे ज़्यादा रखें. इस्तेमाल के बारे में उपयोगकर्ता के साफ़ तौर पर किए गए इंटरैक्शन से तय किया जाना चाहिए. इसे UsageStats#getLastTimeVisible() के ज़रिए या किसी ऐसी वजह से किया जाना चाहिए जिसकी वजह से ऐप्लिकेशन बंद रहने की स्थिति बने रहे. इसमें सर्विस बाइंडिंग, कॉन्टेंट देने वाले बाइंडिंग, साफ़ तौर पर किए गए ब्रॉडकास्ट वगैरह शामिल हैं. इन्हें एक नए एपीआईUseStats#getLastTimeAnycomponentUsed() से ट्रैक किया जाएगा.
[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 डीपीआई)	48 एमबी
	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 डीपीआई)	80 एमबी
	400 डीपीआई (400 डीपीआई)	96 एमबी
	420 डीपीआई (420 डीपीआई)	112 एमबी
	480 डीपीआई (xxhdpi)	128 एमबी
	560 डीपीआई (560 डीपीआई)	192 एमबी
	640 डीपीआई (xxxhdpi)	256 एमबी
बड़ा	120 डीपीआई (ldpi)	32 एमबी
	140 डीपीआई (140 डीपीआई)	48 एमबी
	160 डीपीआई (एमडीपीआई)	48 एमबी
	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 डीपीआई (एमडीपीआई)	80 एमबी
	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] पिन किए गए शॉर्टकट और डाइनैमिक और स्टैटिक शॉर्टकट का इस्तेमाल करना ज़रूरी है, जैसा कि ऐप्लिकेशन शॉर्टकट पेज पर बताया गया है.

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

[C-3-1] ShortcutManager.isRequestPinShortcutSupported() के लिए, false की शिकायत करना ज़रूरी है.

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

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

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

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

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

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

3.8.2. विजेट

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

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

[C-1-1] प्लैटफ़ॉर्म की सुविधा के साथ काम करने का एलान करना ज़रूरी है android.software.app_widgets.
[C-1-2] इसमें 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. डीएनडी (परेशान न करें)/ प्राथमिकता मोड

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

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

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

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

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

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 की घोषणा करते हैं, लेकिन उनके समाधान में एक मालिकाना डिवाइस प्रबंधन समाधान भी शामिल है और मानक Android DevicePolicyManager एपीआई के ज़रिए पहचाने गए मानक "डिवाइस मालिक" के रूप में कॉन्फ़िगर किए गए ऐप्लिकेशन का प्रचार करने का तरीका भी दिया जाता है, तो वे:

[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 देखें), तो भले ही मैनेज की जा रही प्रोफ़ाइल को मुख्य उपयोगकर्ता के अलावा किसी और उपयोगकर्ता के तौर पर न गिना जाए.

अगर डिवाइस पर लागू करने के तरीके के बारे में 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.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-1-1] Android टीटीएस फ़्रेमवर्क एपीआई के साथ काम करना ज़रूरी है.

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

[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)
वोर्बिस	डिकोड करने की सुविधा: मोनो, स्टीरियो, 5.0, और 5.1 कॉन्टेंट के लिए 8,000, 12,000, 16,000, 24,000, और 48,000 हर्ट्ज़ की सैंपलिंग रेट इस्तेमाल की जा सकती है. एन्कोडिंग: 8,000, 12,400, 12,400, 12,400, 12,400, 12,400, और 12,400 हर्ट्ज़ की सैंपलिंग रेट के साथ मोनो और स्टीरियो कॉन्टेंट के लिए सहायता.	ऑग (.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

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

अगर डिवाइस पर 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)

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 देखें	WebM (.webm) मैट्रोस्का (.mkv)
वीपी9	जानकारी के लिए, सेक्शन 5.3 देखें	WebM (.webm) मैट्रोस्का (.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 पिक्सल (अन्य)	1408 x 1152 पिक्सल (H263) 1280 x 720 पिक्सल (अन्य)	1920 x 1080 पिक्सल (MPEG4 के अलावा)	3840 x 2160 पिक्सल (HEVC, VP9)

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

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

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

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

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

[C-1-1] VP8 या H.264 वीडियो एन्कोडर में से कम से कम एक के साथ काम करना ज़रूरी है. साथ ही, इसे तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराना ज़रूरी है.
इसे VP8 और H.264, दोनों तरह के वीडियो एन्कोडर के साथ काम करना चाहिए. साथ ही, इसे तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराना चाहिए.

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

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

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

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

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

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

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

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

5.2.1. एच.263

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

[C-1-1] बेसलाइन प्रोफ़ाइल लेवल 45 के साथ काम करना ज़रूरी है.
इसके साथ काम करने वाले एन्कोडर के लिए, इसे डाइनैमिक तरीके से कॉन्फ़िगर किए जा सकने वाले बिटरेट के साथ काम करना चाहिए.

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

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

5.3. वीडियो डिकोड करना

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

[C-1-1] सभी VP8, VP9, H.264, और H.265 कोडेक के लिए, एक ही स्ट्रीम में स्टैंडर्ड Android एपीआई की मदद से, डाइनैमिक वीडियो रिज़ॉल्यूशन और फ़्रेम रेट को रीयल टाइम में स्विच किया जा सकता है. साथ ही, डिवाइस पर मौजूद हर कोडेक के साथ काम करने वाले ज़्यादा से ज़्यादा रिज़ॉल्यूशन की सुविधा मिल सकती है.

5.3.1. MPEG-2

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

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

5.3.2. एच.263

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

[C-1-1] बेसलाइन प्रोफ़ाइल लेवल 30 और लेवल 45 के साथ काम करना ज़रूरी है.

5.3.3. MPEG-4

अगर डिवाइस को MPEG-4 डिकोडर के साथ लागू करता है, तो वे:

[C-1-1] सिंपल प्रोफ़ाइल लेवल 3 के साथ काम करना ज़रूरी है.

5.3.4. H.264

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

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

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

[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-बिट कॉन्टेंट भी शामिल हो.

5.4. ऑडियो रिकॉर्डिंग

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

5.4.1. ऑडियो कैप्चर और माइक्रोफ़ोन की रॉ जानकारी

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

[C-1-1] चालू होने पर, किसी भी AudioRecord या AAudio इनपुट स्ट्रीम के लिए, रॉ ऑडियो कॉन्टेंट को कैप्चर करना ज़रूरी है. कम से कम, नीचे दी गई विशेषताओं का इस्तेमाल करना ज़रूरी है:
- फ़ॉर्मैट: लीनियर PCM, 16-बिट
- सैंपलिंग रेट: 8,000, 11,025, 16,000, 44,100, 48,000 हर्ट्ज़
- चैनल: मोनो
- ऑडियो सोर्स: DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED या VOICE_PERFORMANCE. यह AAudio में मिलते-जुलते इनपुट प्रीसेट पर भी लागू होता है, उदाहरण के लिए, AAUDIO_INPUT_PRESET_CAMCORDER.
इन विशेषताओं वाले रॉ ऑडियो कॉन्टेंट को कैप्चर करने की अनुमति होनी चाहिए:
- फ़ॉर्मैट: लीनियर 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 किलोहर्ट्ज़ तक.
ऑडियो इनपुट की संवेदनशीलता को इस तरह सेट करना चाहिए कि हर फ़्लोटिंग माइक्रोफ़ोन की पहचान के लिए 90 dB के साउंड प्रेशर लेवल (माइक्रोफ़ोन के बगल में मापा गया) पर चलाया गया 1000 हर्ट्ज़ वाला साइनसोइडल टोन सोर्स (माइक्रोफ़ोन के बगल में मापा गया) RMS 2500 का आदर्श रिस्पॉन्स दे.
आवाज़ की पहचान करने वाली ऑडियो स्ट्रीम को रिकॉर्ड करना चाहिए, ताकि पीसीएम आयाम के स्तर, माइक्रोफ़ोन पर इनपुट एसपीएल को कम से कम 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.4.6. माइक्रोफ़ोन गेन लेवल [5.4.2 पर ले जाया गया]

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 को लागू करने की सुविधा दी जानी चाहिए.
EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB, और EFFECT_TYPE_VIRTUALIZER को लागू करने के साथ काम करना चाहिए. इसे AudioEffect सब-क्लास BassBoost,EnvironmentalReverb, PresetReverb, और Virtualizer के ज़रिए कंट्रोल किया जा सकता है.
[C-SR-1] फ़्लोट करने वाले पॉइंट और मल्टीचैनल में इफ़ेक्ट लागू करने के लिए, इस बात का खास तौर पर सुझाव दिया जाता है.

5.5.3. ऑडियो आउटपुट की आवाज़

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

हर ऑडियो स्ट्रीम के लिए, ऑडियो की आवाज़ को अलग-अलग अडजस्ट करने की अनुमति देनी चाहिए. ऐसा AudioAttributes में बताए गए कॉन्टेंट टाइप या इस्तेमाल के हिसाब से किया जाना चाहिए. साथ ही, android.car.CarAudioManager में बताई गई कार के ऑडियो के इस्तेमाल की अनुमति दी जानी चाहिए.

5.5.4. ऑडियो ऑफ़लोड

अगर लागू किए गए डिवाइस पर ऑडियो ऑफ़लोड प्लेबैक काम करता है, तो ये:

[C-SR-1] हमारा सुझाव है कि जब ऑडियो ट्रैक गैपलेस एपीआई और 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 मि॰से॰ के हिसाब से सटीक होता है.

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

सेगमेंट के फ़ॉर्मैट

संदर्भ

आवश्यक कोडेक समर्थन

MPEG-2 ट्रांसपोर्ट स्ट्रीम

आईएसओ 13818

वीडियो कोडेक:

H264 एवीसी
एमपीईजी-4 एसपी
MPEG-2

H264 एवीसी, MPEG2-4 SP,
और MPEG-2 के बारे में ज़्यादा जानकारी के लिए, सेक्शन 5.1.8 देखें.

ऑडियो कोडेक:

AAC और उसके वैरिएंट के बारे में जानकारी के लिए, सेक्शन 5.1.3 देखें.

ADTS फ़्रेमिंग और ID3 टैग के साथ AAC

आईएसओ 13818-7

AAC और इसके वैरिएंट की जानकारी के लिए, सेक्शन 5.1.1 देखें

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 मि॰मी॰ का ऑडियो जैक शामिल है, तो वे:

[C-2-1] ऑडियो के लिए 20 मिलीसेकंड या उससे कम के मीन ऐब्सलूट डेविएशन के साथ, 20 मिलीसेकंड या उससे कम के मीन ऐब्सलूट डेविएशन का औसत, 20 मिलीसेकंड या उससे कम के सेक्शन में बताया गया है.ऑडियो लूपबैक डोंगल का इस्तेमाल करके, ऑडियो जैक पाथ पर 5 मिलीसेकंड से कम का मीन ऐब्सलूट डेविएशन होना चाहिए.
[C-SR-5] वायर्ड ऑडियो हेडसेट की खास बातें (v1.1) के सेक्शन मोबाइल डिवाइस (जैक) से जुड़ी ज़रूरी शर्तों का पालन करने के लिए, इस बात पर ज़ोर दिया जाता है.

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

5.12. एचडीआर वीडियो

आने वाले दस्तावेज़ में दी गई जानकारी के मुताबिक, Android 13 एचडीआर टेक्नोलॉजी के साथ काम करता है.

पिक्सल फ़ॉर्मैट

अगर कोई वीडियो डिकोडर COLOR_FormatYUVP010 के लिए सहायता का विज्ञापन करता है, तो:

[C-1-1] सीपीयू-रीड के लिए P010 फ़ॉर्मैट पर काम करना ज़रूरी है (ImageReader, MediaImage, ByteBuffer). Android 13 में P010 को आरामदायक बनाया गया है, ताकि Y और यूवी प्लेन के लिए आर्बिट्रेरी मूविंग की अनुमति दी जा सके.
[C-1-2] P010 आउटपुट बफ़र को जीपीयू से सैंपल किया जा सकता है (जब जीपीयू_SAMPLING के इस्तेमाल के साथ असाइन किया जा चुका हो). इससे ऐप्लिकेशन के हिसाब से जीपीयू कंपोज़िशन और कस्टम टोन मैपिंग चालू होती है.

अगर कोई वीडियो डिकोडर COLOR_Format32bitABGR2101010 के लिए सहायता का विज्ञापन करता है, तो यह:

[C-2-1] आउटपुट प्लैटफ़ॉर्म के लिए RGBA_1010102 फ़ॉर्मैट पर काम करना ज़रूरी है. साथ ही, सीपीयू के हिसाब से पढ़ा जा सकने वाला (ByteBuffer आउटपुट) काम करता है.

अगर कोई वीडियो एन्कोडर, COLOR_FormatYUVP010 के साथ काम करता है, तो:

[C-3-1] इनपुट सर्फ़ेस और सीपीयू से लिखे जा सकने वाले इनपुट के लिए, P010 फ़ॉर्मैट पर काम करना ज़रूरी है (ImageWriter, MediaImage, ByteBuffer) इनपुट.

अगर कोई वीडियो एन्कोडर, COLOR_Format32bitABGR2101010 के साथ काम करता है, तो यह:

[C-4-1] इनपुट प्लैटफ़ॉर्म और सीपीयू से लिखे जा सकने वाले इनपुट के लिए, RGBA_1010102 फ़ॉर्मैट पर काम करना ज़रूरी है (ImageWriter, ByteBuffer) इनपुट. ध्यान दें: एन्कोडर के लिए, अलग-अलग ट्रांसफ़र कर्व के बीच स्विच करने की ज़रूरत नहीं है.

एचडीआर कैप्चर करने से जुड़ी ज़रूरी शर्तें

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

[C-5-1] यह नहीं मानना चाहिए कि एचडीआर मेटाडेटा सटीक है. उदाहरण के लिए, एन्कोड किए गए फ़्रेम में सबसे ज़्यादा चमक के स्तर से ज़्यादा पिक्सल हो सकते हैं या हो सकता है कि हिस्टोग्राम फ़्रेम के बारे में न बताता हो.
कोड में बदली गई स्ट्रीम के लिए सही एचडीआर स्टैटिक मेटाडेटा जनरेट करने के लिए एचडीआर डाइनैमिक मेटाडेटा को इकट्ठा करना चाहिए. साथ ही, हर एन्कोडिंग सेशन के आखिर में इसे आउटपुट के तौर पर दिखाया जाना चाहिए.

अगर लागू किए गए डिवाइस पर CamcorderProfile API के साथ एचडीआर क्वालिटी के वीडियो कैप्चर करने की सुविधा काम करती है, तो:

[C-6-1] Camera2 एपीआई से भी एचडीआर क्वालिटी में वीडियो कैप्चर करने की सुविधा होनी चाहिए.
[C-6-2] हर एचडीआर टेक्नोलॉजी के लिए, कम से कम एक हार्डवेयर-एक्सेलरेटेड वीडियो एन्कोडर काम करना चाहिए.
[C-6-3] ज़रूरी है कि एचएलजी कैप्चर करने के लिए, कम से कम उसका इस्तेमाल किया जा सके.
[C-6-4] कैप्चर की गई वीडियो फ़ाइल में एचडीआर मेटाडेटा (अगर यह एचडीआर टेक्नोलॉजी के लिए लागू हो) लिखने की सुविधा होनी चाहिए. AV1, HEVC, और DolbyVision का मतलब है, कोड में बदली गई बिटस्ट्रीम में मेटाडेटा शामिल करना.
[C-6-5] P010 और COLOR_FormatYUVP010 पर काम करना ज़रूरी है.
[C-6-6] कैप्चर की गई प्रोफ़ाइल के लिए, डिफ़ॉल्ट हार्डवेयर-एक्सेलरेटेड डिकोडर में, एचडीआर से एसडीआर टोन मैपिंग की सुविधा काम करनी चाहिए. दूसरे शब्दों में कहें, अगर कोई डिवाइस HDR10+ HEVC को कैप्चर कर सकता है, तो डिफ़ॉल्ट HEVC डिकोडर को SDR में कैप्चर की गई स्ट्रीम को डिकोड करना होगा.

एचडीआर में बदलाव करने की ज़रूरी शर्तें

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

एचडीआर मेटाडेटा मौजूद न होने पर, इसे जनरेट करने में कम से कम इंतज़ार होना चाहिए. साथ ही, ऐसी स्थितियों को सही तरीके से मैनेज करना चाहिए जिनमें कुछ फ़्रेम के लिए मेटाडेटा मौजूद हो और कुछ के लिए नहीं. यह मेटाडेटा सटीक होना चाहिए (उदाहरण के लिए, फ़्रेम की असली पीक ल्यूमिनेंस और हिस्टोग्राम को दिखाना).

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

[C-7-1] कम से कम एक एचडीआर प्रोफ़ाइल के साथ काम करना ज़रूरी है.
[C-7-2] इस कोडेक से जिन सभी एचडीआर प्रोफ़ाइलों का विज्ञापन दिखाया जा रहा है उनके लिए FEATURE_HdrEditing की सुविधा ज़रूरी है. दूसरे शब्दों में कहें, तो एचडीआर मेटाडेटा का इस्तेमाल करने वाली सभी एचडीआर प्रोफ़ाइलों के लिए, एचडीआर मेटाडेटा जनरेट करना ज़रूरी है.
[C-7-3] नीचे दिए गए वीडियो एन्कोडर इनपुट फ़ॉर्मैट पर काम करना ज़रूरी है, जो एचडीआर डिकोड किए गए सिग्नल को पूरी तरह से सुरक्षित रखते हैं:
- इनपुट प्लैटफ़ॉर्म और ByteBuffer, दोनों के लिए RGBA_1010102 (पहले से ही टारगेट ट्रांसफ़र कर्व में) और COLOR_Format32bitABGR2101010 के लिए सहायता का विज्ञापन देना ज़रूरी है.

अगर डिवाइस में ऐसे कोडेक शामिल हैं जो FEATURE_HdrEditing की सुविधा देते हैं, तो डिवाइस:

[C-7-4] EXT_YUV_target OpenGL एक्सटेंशन के लिए विज्ञापन देना ज़रूरी है.

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

6.1. डेवलपर टूल

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

[C-0-1] Android SDK में दिए गए Android डेवलपर टूल पर भी काम करना ज़रूरी है.
Android डीबग ब्रिज (adb)
- [C-0-2] Android SDK में बताए गए adb और एओएसपी में दिए गए शेल कमांड के साथ काम करना ज़रूरी है. इसका इस्तेमाल ऐप्लिकेशन डेवलपर कर सकते हैं. इनमें dumpsys शामिल है cmd stats
- [C-0-11] शेल कमांड cmd testharness काम करना चाहिए. अगर डिवाइस के Android वर्शन को पुराने वर्शन से अपग्रेड करके, लगातार डेटा ब्लॉक नहीं किया जाता, तो आपको C-0-11 से छूट दी जा सकती है.
- [C-0-3] को डंपसिस कमांड के ज़रिए लॉग किए गए डिवाइस के सिस्टम इवेंट (बैटरीस्टेट , डिस्कस्टेट, फ़िंगरप्रिंट, ग्राफ़िक्सस्टैट, नेटस्टेट, सूचना, प्रोस्टेट) के फ़ॉर्मैट या सामग्री में बदलाव नहीं करना चाहिए.
- [C-0-10] ज़रूरी है कि आप इसे रिकॉर्ड करें और इसे चालू करने की अनुमति न दें. साथ ही, इन इवेंट को cmd stats शेल कमांड और StatsManager System API क्लास में ऐक्सेस करने लायक बनाने के साथ-साथ उन्हें उपलब्ध भी कराना चाहिए.
  - ऐक्टिविटी फ़ोरग्राउंडस्टेटस
  - गड़बड़ी की पहचान हुई है
  - ऐप्लिकेशन ब्रेडक्रंब की रिपोर्ट की गई
  - AppCrash हुआ
  - AppStart हुआ
  - बैटरी स्तर में बदलाव
  - बैटरीसेवरमोडस्टेट बदलें
  - BleScanनतीजे मिला
  - BleScanStateChanged
  - ChargeStateChanged
  - DeviceIdleModeStateChanged
  - ForegroundServiceStateChanged
  - GpsScanStateChanged
  - JobStateChanged
  - प्लग की गई स्थिति
  - शेड्यूल किए गए जॉबस्टेट में बदलाव
  - स्क्रीनस्टेट बदला गया
  - SyncStateChanged
  - सिस्टम बीता हुआ रीयलटाइम
  - UidProcessStateChanged
  - वेकलॉक स्टेट चेंज्ड
  - वेकअप अलार्म ट्रिगर हुआ
  - WifiLockStateChanged
  - WifiMulticastLockStateChanged
  - वाई-फ़ाईस्कैनस्टेट बदला गया
- [C-0-4] ज़रूरी है कि डिवाइस-साइड adb डीमन डिफ़ॉल्ट रूप से इनऐक्टिव हो. साथ ही, Android डीबग ब्रिज को चालू करने के लिए, ऐसा तरीका होना चाहिए जिसे उपयोगकर्ता आसानी से ऐक्सेस कर सकें.
- [C-0-5] सुरक्षित adb के साथ काम करना चाहिए. Android में सुरक्षित adb की सुविधा शामिल है. सुरक्षित adb, पुष्टि किए गए जाने-पहचाने होस्ट पर adb चालू करता है.
- [C-0-6] एक ऐसा तरीका उपलब्ध कराना ज़रूरी है जिसकी मदद से adb को होस्ट मशीन से कनेक्ट किया जा सके. खास तौर से:
अगर यूएसबी पोर्ट के बिना डिवाइस, सहायक डिवाइस (जैसे, कीबोर्ड, माउस, मॉनिटर, वेबकैम वगैरह) मोड पर काम करते हैं, तो वे:
- [C-3-1] लोकल एरिया नेटवर्क (जैसे ईथरनेट या वाई-फ़ाई) के ज़रिए adb लागू करना ज़रूरी है.
- [C-3-2] Windows 7, 8, और 10 के लिए ड्राइवर होना ज़रूरी है. इससे डेवलपर, adb प्रोटोकॉल का इस्तेमाल करके डिवाइस से कनेक्ट कर सकते हैं.
अगर लागू किए गए डिवाइस, वाई-फ़ाई या ईथरनेट के ज़रिए किसी होस्ट मशीन से adb कनेक्शन की सुविधा देते हैं, तो वे:
- [C-4-1] वैल्यू के तौर पर AdbManager#isAdbWifiSupported() तरीके से रिटर्न true करना ज़रूरी है.
अगर लागू किए गए डिवाइस, वाई-फ़ाई या ईथरनेट के ज़रिए किसी होस्ट मशीन से adb कनेक्शन की सुविधा देते हैं और उसमें कम से कम एक कैमरा शामिल है, तो वे:
- [C-5-1] AdbManager#isAdbWifiQrSupported() तरीके से, रिटर्न true करना ज़रूरी है.
Dalvik डीबग मॉनिटर सेवा (डीडीएम)
- [C-0-7] Android SDK में बताए गए सभी डीडीएम सुविधाओं के साथ काम करना ज़रूरी है. ddms, adb का इस्तेमाल करता है, इसलिए ddms के लिए सहायता डिफ़ॉल्ट रूप से बंद होनी चाहिए. हालांकि, जैसा कि ऊपर बताया गया है, जब उपयोगकर्ता Android डीबग ब्रिज को चालू कर रहा हो, तब यह काम करना ज़रूरी है.
SysTrace
- [C-0-9] Android SDK में बताए गए तरीके के मुताबिक, सिस्टम ट्रेस करने की सुविधा का इस्तेमाल करना ज़रूरी है. डिफ़ॉल्ट रूप से, Systrace की सुविधा बंद होनी चाहिए. साथ ही, यह ज़रूरी है कि Systrace की सुविधा को चालू करने के लिए, एक ऐसा सिस्टम होना चाहिए जिसे उपयोगकर्ता आसानी से ऐक्सेस कर सके.
परफ़ेटो
- [C-SR-1] शेल उपयोगकर्ता को /system/bin/perfetto बाइनरी दिखाने के लिए इस बात की बहुत ज़्यादा सलाह दी जाती है कि cmdline परफ़ेटो दस्तावेज़ का पालन करता है.
- [C-SR-2] परफ़ेटो बाइनरी को इनपुट के तौर पर ऐसे प्रोटोबफ़ कॉन्फ़िगरेशन के तौर पर स्वीकार करने का बहुत ज़्यादा सुझाव दिया जाता है जो परफ़ेटो दस्तावेज़ में दिए गए स्कीमा का पालन करता है.
- [C-SR-3] परफ़ेटो बाइनरी को आउटपुट के रूप में लिखने का बहुत ज़्यादा सुझाव दिया जाता है. यह एक ऐसे प्रोटोबफ़ ट्रेस है जो परफ़ेटो के दस्तावेज़ में दिए गए स्कीमा का पालन करता है.
- [C-SR-4] का सुझाव दिया जाता है कि कम से कम परफ़ेटो के दस्तावेज़ में बताए गए डेटा सोर्स, परफ़ेटो बाइनरी की मदद से उन्हें उपलब्ध कराया जाए.
लो मेमोरी किलर
- [C-0-12] किसी ऐप्लिकेशन को लो मेमोरी किलर से खत्म करने के बाद, आंकड़ों के लॉग में LMK_KILL_OCCURRED_FIELD_NUMBER ऐटम लिखना ज़रूरी है.
टेस्ट हार्नेस मोड अगर डिवाइस पर शेल कमांड cmd testharness काम करता है और cmd testharness enable को रन किया जाता है, तो ये काम किए जा सकते हैं:
- [C-2-1] ActivityManager.isRunningInUserTestHarness() के लिए true वापस करना होगा
- [C-2-2] टेस्ट हार्नेस मोड के दस्तावेज़ में बताए गए तरीके के मुताबिक, टेस्ट हार्नेस मोड लागू करना ज़रूरी है.
जीपीयू के काम से जुड़ी जानकारी

डिवाइस पर यह सुविधा लागू करना:
- [C-0-13] शेल कमांड dumpsys gpu --gpuwork लागू करना ज़रूरी है. इससे power/gpu_work_period कर्नेल ट्रेस पॉइंट से मिला, जीपीयू का वर्क डेटा दिखाया जा सकता है जो इकट्ठा किया गया है. अगर ट्रेसपॉइंट काम नहीं करता है, तो कोई डेटा नहीं दिखाएं. एओएसपी लागू करने की सुविधा frameworks/native/services/gpuservice/gpuwork/ है.

अगर लागू किए गए डिवाइस, android.hardware.vulkan.version फ़ीचर फ़्लैग के ज़रिए, Vulkan 1.0 या उसके बाद के वर्शन के साथ काम करने की जानकारी देते हैं, तो वे:

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

6.2. डेवलपर के लिए सेटिंग और टूल

Android में डेवलपर के लिए ऐप्लिकेशन डेवलपमेंट-संबंधी सेटिंग कॉन्फ़िगर करने का समर्थन शामिल है.

डिवाइस लागू करने के लिए डेवलपर के लिए उपलब्ध सेटिंग और टूल का एक जैसा अनुभव देना ज़रूरी है.

[C-0-1] ऐप्लिकेशन डेवलपमेंट से जुड़ी सेटिंग दिखाने के लिए android.settings.APPLICATION_DEVELOPMENT_SETTINGS दिखाने के मकसद का पालन करना ज़रूरी है. अपस्ट्रीम Android लागू करने की सुविधा से, 'डेवलपर के लिए सेटिंग और टूल' मेन्यू डिफ़ॉल्ट रूप से छिप जाता है. साथ ही, उपयोगकर्ता सेटिंग > डिवाइस के बारे में जानकारी > बिल्ड नंबर मेन्यू आइटम में सात (7) बार बटन दबाने के बाद, डेवलपर के लिए सेटिंग और टूल को लॉन्च कर सकते हैं.
[C-0-2] डिफ़ॉल्ट रूप से 'डेवलपर के लिए सेटिंग और टूल' को छिपाना ज़रूरी है.
[C-0-3] ऐसा साफ़ तौर पर बताया जाना चाहिए जो डेवलपर के लिए सेटिंग और टूल चालू करने के लिए, किसी तीसरे पक्ष के ऐप्लिकेशन के मुकाबले किसी तीसरे पक्ष के ऐप्लिकेशन को प्राथमिकता न देता हो. 'डेवलपर के लिए सेटिंग और टूल' चालू करने का तरीका बताने वाला दस्तावेज़ या वेबसाइट उपलब्ध करानी होगी. इस दस्तावेज़ या वेबसाइट को Android SDK दस्तावेज़ों से लिंक करना ज़रूरी है.
'डेवलपर के लिए सेटिंग और टूल' के चालू होने और उपयोगकर्ता की सुरक्षा को ध्यान में रखते हुए, उपयोगकर्ता को इसकी विज़ुअल सूचना दी जानी चाहिए.
ऐसा हो सकता है कि इसमें, मेन्यू को देखकर या बंद करके डेवलपर के लिए सेटिंग और टूल के ऐक्सेस को कुछ समय के लिए सीमित किया जा सके. ऐसा करने से, लोगों की सुरक्षा को लेकर किसी तरह की समस्या का सामना नहीं किया जा सकता.

7. हार्डवेयर के साथ काम करने की सुविधा

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

[C-0-1] डिवाइस पर उस एपीआई को लागू करना ज़रूरी है जैसा कि Android SDK के दस्तावेज़ में बताया गया है.

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

[C-0-2] कॉम्पोनेंट एपीआई के लिए, क्लास की पूरी परिभाषाएं (जैसा कि SDK टूल के दस्तावेज़ में बताया गया है) अब भी दिखाई जानी चाहिए.
[C-0-3] एपीआई के व्यवहार को कुछ सही तरीकों में नो-ऑप के रूप में लागू किया जाना चाहिए.
[C-0-4] एपीआई के तरीकों के लिए ज़रूरी है कि वे शून्य वैल्यू दिखाएं. ऐसा उन जगहों पर किया जाना चाहिए जहां SDK टूल से जुड़े दस्तावेज़ के तहत अनुमति मिली हो.
[C-0-5] एपीआई के तरीकों के लिए, उन क्लास का नो-ऑप लागू करना ज़रूरी है जहां शून्य वैल्यू SDK टूल के दस्तावेज़ में अनुमति नहीं है.
[C-0-6] एपीआई के तरीकों में ऐसे अपवाद नहीं डालने चाहिए जिन्हें SDK टूल के दस्तावेज़ में न बताया गया हो.
[C-0-7] यह ज़रूरी है कि डिवाइस लागू करने के लिए, android.content.pm.PackageManager क्लास पर getSystemAvailableFeatures() और hasSystemFeature(String) तरीकों से, एक ही बिल्ड फ़िंगरप्रिंट के लिए, हार्डवेयर कॉन्फ़िगरेशन की सटीक जानकारी लगातार रिपोर्ट करे.

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

7.1. डिसप्ले और ग्राफ़िक

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

इस सेक्शन में बताई गई ज़रूरी शर्तों के बारे में नीचे बताया गया है:

फ़िज़िकल डायगनल साइज़. स्क्रीन पर रोशनी वाले हिस्से के दो आमने-सामने के कोनों के बीच की दूरी, इंच में.
डॉट प्रति इंच (डीपीआई). पिक्सल की संख्या जिसमें 1” के लीनियर हॉरिज़ॉन्टल या वर्टिकल स्पैन में शामिल पिक्सल की संख्या हो. जहां डीपीआई वैल्यू दी गई हो, वहां हॉरिज़ॉन्टल और वर्टिकल, दोनों डीपीआई को रेंज में होना चाहिए.
आसपेक्ट रेशियो. लंबे डाइमेंशन के पिक्सल और स्क्रीन के छोटे डाइमेंशन का अनुपात. उदाहरण के लिए, 480x854 पिक्सल का डिसप्ले 854/480 = 1.779 या करीब-करीब “16:9” होगा.
डेंसिटी-इंडिपेंडेंट पिक्सल (डीपी). वर्चुअल पिक्सल की यूनिट को 160 डीपीआई स्क्रीन के लिए नॉर्मलाइज़ किया जाता है. इसकी गिनती इस तरह से की जाती है: पिक्सल = डीपी * (डेंसिटी/160).

7.1.1. स्क्रीन कॉन्फ़िगरेशन

7.1.1.1. स्क्रीन का आकार और आकार

Android यूज़र इंटरफ़ेस (यूआई) फ़्रेमवर्क, स्क्रीन के अलग-अलग लॉजिकल लेआउट के साथ काम करता है. साथ ही, यह ऐप्लिकेशन को SCREENLAYOUT_SIZE_MASK और Configuration.smallestScreenWidthDp की मदद से, Configuration.screenLayout के ज़रिए मौजूदा कॉन्फ़िगरेशन के स्क्रीन लेआउट साइज़ के लिए क्वेरी करने की अनुमति देता है.

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

[C-0-1] Android SDK के दस्तावेज़ में बताया गया है कि Configuration.screenLayout के लिए, सही लेआउट साइज़ की जानकारी देना ज़रूरी है. खास तौर पर, डिवाइस लागू करने के लिए ज़रूरी है कि वह नीचे दिए गए लॉजिकल डेंसिटी-इंडिपेंडेंट पिक्सल (dp) स्क्रीन डाइमेंशन को सही तरीके से रिपोर्ट करे:
- Configuration.uiMode वाले डिवाइस के लिए, UI_Mode_TYPE_Watch के अलावा किसी भी अन्य वैल्यू को सेट किया जाता है. साथ ही, Configuration.screenLayout के लिए small साइज़ की जानकारी देना ज़रूरी है. इन डिवाइसों में कम से कम 426 dp x 320 dp होना ज़रूरी है.
- Configuration.screenLayout के लिए normal साइज़ की रिपोर्ट देने वाले डिवाइस में, कम से कम 480 dp x 320 dp होना ज़रूरी है.
- Configuration.screenLayout के लिए large साइज़ की रिपोर्ट देने वाले डिवाइस में, कम से कम 640 dp x 480 dp होना ज़रूरी है.
- Configuration.screenLayout के लिए xlarge साइज़ की रिपोर्ट देने वाले डिवाइस में, कम से कम 960 dp x 720 dp होना ज़रूरी है.
[C-0-2] को स्क्रीन साइज़ के लिए बताए गए ऐप्लिकेशन के साथ काम करना चाहिए. इसके लिए, AndroidManifest.xml में <supports-screens> एट्रिब्यूट का इस्तेमाल करें, जैसा कि Android SDK के दस्तावेज़ में बताया गया है.
इसमें Android के साथ काम करने वाले ऐसे डिसप्ले हो सकते हैं जिनके कोने गोल हों.

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

[C-1-1] ज़रूरी है कि इन शर्तों में से कम से कम एक को पूरा किया गया हो:
- गोल किनारों का रेडियस 38 dp से कम या उसके बराबर होता है.
- जब 15 dp x 15 dp बॉक्स को लॉजिकल डिसप्ले के हर कोने में ऐंकर किया जाता है, तो स्क्रीन पर हर बॉक्स का कम से कम एक पिक्सल दिखता है.
इसमें उपयोगकर्ताओं के लिए, आयताकार कोनों पर डिसप्ले मोड पर स्विच करने का खर्च भी शामिल होना चाहिए.

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

[C-2-1] extensions API के नए उपलब्ध और स्टेबल वर्शन को लागू करना ज़रूरी है. इसके अलावा, Window Manager Jetpack लाइब्रेरी में साइडकार एपीआई के स्टेबल वर्शन का इस्तेमाल करना भी ज़रूरी है.

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

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

साइडकार या एक्सटेंशन एपीआई को सही तरीके से लागू करने की जानकारी के लिए, Window Manager Jetpack के सार्वजनिक दस्तावेज़ देखें.

7.1.1.2. स्क्रीन का आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात)

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

[C-0-1] जिन डिवाइसों पर Configuration.uiMode को UI_MODE_TYPE_NORMAL पर सेट किया गया है उनका आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) वैल्यू 1.86 (करीब 16:9) से कम या उसके बराबर होनी चाहिए. ऐसा तब तक होना चाहिए, जब तक कि ऐप्लिकेशन इनमें से किसी एक शर्त को पूरा न करता हो:
- ऐप्लिकेशन ने android.max_aspect मेटाडेटा वैल्यू की मदद से एलान किया है कि वह बड़ी स्क्रीन के आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) के साथ काम करता है.
- ऐप्लिकेशन android:resizeableActivity एट्रिब्यूट के ज़रिए यह एलान करता है कि उसका साइज़ बदला जा सकता है.
- ऐप्लिकेशन, एपीआई लेवल 24 या उसके बाद के लेवल को टारगेट करता है और किसी ऐसे android:maxAspectRatio का एलान नहीं करता है जिससे अनुमति वाले आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) पर पाबंदी लग जाए.
[C-0-3] जिन डिवाइसों पर Configuration.uiMode को UI_MODE_TYPE_WATCH के तौर पर सेट किया गया है उनका आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) वैल्यू 1.0 (1:1) पर सेट होनी चाहिए.

7.1.1.3. स्क्रीन की सघनता

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

[C-0-1] डिफ़ॉल्ट रूप से, डिवाइस लागू करने के लिए DisplayMetrics पर DENSITY_DEVICE_STABLE API के ज़रिए दी गई Android फ़्रेमवर्क की डेंसिटी में से सिर्फ़ एक को रिपोर्ट करना ज़रूरी है. यह वैल्यू किसी भी समय नहीं बदलनी चाहिए. हालांकि, उपयोगकर्ता के डिसप्ले कॉन्फ़िगरेशन में किए गए बदलावों (उदाहरण के लिए, डिसप्ले साइज़) के हिसाब से डिवाइस अलग-अलग डेंसिटी रिपोर्ट कर सकता है.
डिवाइस को लागू करने के लिए, Android फ़्रेमवर्क की स्टैंडर्ड सघनता तय की जानी चाहिए, जो संख्या के हिसाब से स्क्रीन की फ़िज़िकल डेंसिटी के सबसे करीब हो. ऐसा तब तक होना चाहिए, जब तक लॉजिकल सघनता, रिपोर्ट किए गए स्क्रीन साइज़ को स्क्रीन के साइज़ से कम न कर दे. अगर Android फ़्रेमवर्क की स्टैंडर्ड सघनता, संख्या के हिसाब से फ़िज़िकल डेंसिटी के सबसे करीब होती है, तो ऐसे स्क्रीन साइज़ का पता चलता है जो स्क्रीन के सबसे छोटे साइज़ (320 dp चौड़ाई) से कम हो. ऐसे में, डिवाइस को लागू करने के लिए, Android फ़्रेमवर्क की अगली सबसे कम स्टैंडर्ड डेंसिटी रिपोर्ट करनी चाहिए.

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

[C-1-1] डिसप्ले साइज़ को नेटिव डेंसिटी के 1.5 गुना से ज़्यादा स्केल नहीं किया जाना चाहिए या 320dp (रिसॉर्स क्वालीफ़ायर sw320dp के बराबर) से कम कम असरदार स्क्रीन डाइमेंशन बनाना चाहिए, जो भी पहले हो.
[C-1-2] डिसप्ले साइज़ को नेटिव डेंसिटी के 0.85 गुना से कम पर स्केल नहीं किया जाना चाहिए.
हमारा सुझाव है कि नेटिव डिसप्ले के विकल्पों को स्केल करने की नीचे दी गई स्केलिंग के बारे में बताएं (ऊपर बताई गई सीमाओं का पालन करते हुए)
- छोटा: 0.85x
- डिफ़ॉल्ट: 1x (नेटिव डिसप्ले स्केल)
- बड़ा: 1.15x
- बड़ा: 1.3x
- सबसे बड़ा 1.45x

7.1.2. डिसप्ले मेट्रिक

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

[C-1-1] android.util.DisplayMetrics एपीआई में बताए गए Android के साथ काम करने वाले सभी डिसप्ले मेट्रिक के लिए, सही वैल्यू की रिपोर्ट ज़रूर करें.

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

[C-2-1] ज़रूरी है कि आप Android के साथ काम करने वाले डिसप्ले की सही वैल्यू की रिपोर्ट करें, जैसा कि एम्युलेट किए गए डिफ़ॉल्ट view.Display के लिए, android.util.DisplayMetrics एपीआई में बताया गया है.

7.1.3. स्क्रीन अभिविन्यास

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

[C-0-1] यह रिपोर्ट करना ज़रूरी है कि वे कौनसे स्क्रीन ओरिएंटेशन का इस्तेमाल कर सकते हैं (android.hardware.screen.portrait और/या android.hardware.screen.landscape) और कम से कम एक काम करने वाला स्क्रीन ओरिएंटेशन रिपोर्ट करना ज़रूरी है. उदाहरण के लिए, कोई डिवाइस जिसका ओरिएंटेशन लैंडस्केप स्क्रीन तय है, जैसे कि टेलिविज़न या लैपटॉप, तो सिर्फ़ android.hardware.screen.landscape की रिपोर्ट की जानी चाहिए.
[C-0-2] android.content.res.Configuration.orientation, android.view.Display.getOrientation() या अन्य एपीआई का इस्तेमाल करके पूछे जाने पर, डिवाइस के मौजूदा ओरिएंटेशन के लिए सही वैल्यू बताना ज़रूरी है.

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

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

7.1.4. 2D और 3D ग्राफ़िक ऐक्सेलरेशन

7.1.4.1 OpenGL ES

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

[C-0-1] मैनेज किए जा रहे एपीआई (जैसे कि GLES10.getString() तरीके के ज़रिए) और नेटिव एपीआई के ज़रिए, इस्तेमाल किए जा सकने वाले OpenGL ES वर्शन (1.1, 2.0, 3.0, 3.1, 3.2) की सही तरीके से पहचान करनी होगी.
[C-0-2] ज़रूरी है कि इसमें OpenGL ES के हर वर्शन के लिए, उससे जुड़े सभी मैनेज किए गए एपीआई और नेटिव एपीआई के लिए सहायता शामिल की गई हो.

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

[C-1-1] OpenGL ES 1.1 और 2.0, दोनों पर काम करना ज़रूरी है. इसके बारे में Android SDK टूल के दस्तावेज़ में दी गई जानकारी के हिसाब से बताया गया है.
OpenGL ES 3.1 के साथ काम करने के लिए, [C-SR-1] का बहुत ज़्यादा सुझाव दिया जाता है.
OpenGL ES 3.2 पर काम करना चाहिए.

OpenGL ES dEQP टेस्ट को कई टेस्ट सूचियों में बांटा गया है. हर सूची में तारीख/वर्शन नंबर मौजूद है. ये external/deqp/android/cts/main/glesXX-main-YYYY-MM-DD.txt पर Android सोर्स ट्री में हैं. अगर डिवाइस, अपने-आप रिपोर्ट किए गए लेवल पर OpenGL ES के साथ काम करता है, तो इसका मतलब है कि वह इस लेवल और उससे पहले के लेवल की सभी टेस्ट सूचियों में dEQP की जांच को पास कर सकता है.

अगर डिवाइस, OpenGL ES के किसी भी वर्शन के साथ काम करते हैं, तो वे:

[C-2-1] OpenGL ES से मैनेज किए जाने वाले एपीआई और नेटिव एपीआई के ज़रिए, उनके लागू किए गए किसी भी अन्य OpenGL ES एक्सटेंशन की मदद से रिपोर्ट करना ज़रूरी है. इसके साथ ही, उन एक्सटेंशन स्ट्रिंग की रिपोर्ट भी नहीं करनी चाहिए जिनका वे इस्तेमाल नहीं करते.
[C-2-2] ज़रूरी है कि ये EGL_KHR_image, EGL_KHR_image_base, EGL_ANDROID_image_native_buffer, EGL_ANDROID_get_native_client_buffer, EGL_KHR_wait_sync, EGL_KHR_get_all_proc_addresses, EGL_ANDROID_presentation_time, EGL_KHR_swap_buffers_with_damage, EGL_ANDROID_recordable, और EGL_ANDROID_GLES_layers एक्सटेंशन के साथ काम करते हों.
[C-2-3] android.software.opengles.deqp.level फ़ीचर फ़्लैग का इस्तेमाल करके, OpenGL ES dEQP टेस्ट के सबसे सही वर्शन की रिपोर्ट देना ज़रूरी है.
[C-2-4] android.software.opengles.deqp.level फ़ीचर फ़्लैग में बताए गए तरीके के मुताबिक, कम से कम 132383489 (1 मार्च, 2020 से) वर्शन पर काम करना ज़रूरी है.
[C-2-5] वर्शन 132383489 और android.software.opengles.deqp.level फ़ीचर फ़्लैग में बताए गए वर्शन के बीच के वर्शन के बीच के सभी OpenGL ES dEQP टेस्ट को पास करना ज़रूरी है. उन सभी OpenGL ES वर्शन के लिए ऐसा करना ज़रूरी है.
[C-SR-2] EGL_KHR_partial_update और OES_EGL_image_external एक्सटेंशन के साथ काम करने के लिए, इस बात का खास तौर पर सुझाव दिया जाता है.
getString() तरीके का इस्तेमाल करके सही तरीके से रिपोर्ट की जानी चाहिए. यह तरीका, किसी भी टेक्सचर कंप्रेशन फ़ॉर्मैट के साथ काम करता है, जो आम तौर पर वेंडर के लिए होता है.
EGL_IMG_context_priority और EGL_EXT_protected_content एक्सटेंशन के साथ काम करना चाहिए.

अगर डिवाइस, OpenGL ES 3.0, 3.1 या 3.2 के साथ काम करने का एलान करते हैं, तो वे:

[C-3-1] इन वर्शन के लिए, इससे जुड़े फ़ंक्शन सिंबल को libGLESv2.so लाइब्रेरी में OpenGL ES 2.0 फ़ंक्शन सिंबल के साथ एक्सपोर्ट करना ज़रूरी है.
OES_EGL_image_external_essl3 एक्सटेंशन के साथ काम करने के लिए, [C-SR-3] का बहुत ज़्यादा सुझाव दिया जाता है.

अगर डिवाइस, OpenGL ES 3.2 पर काम करते हैं, तो वे:

[C-4-1] OpenGL ES Android एक्सटेंशन पैक के साथ काम करना ज़रूरी है.

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

[C-5-1] android.hardware.opengles.aep फ़ीचर फ़्लैग का इस्तेमाल करके, सहायता की पहचान करना ज़रूरी है.

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

[C-6-1] EGL_ANDROID_front_buffer_auto_refresh एक्सटेंशन के साथ भी काम करना ज़रूरी है.

7.1.4.2 Vulkan

Android में Vulkan की सुविधा भी है. यह क्रॉस-प्लैटफ़ॉर्म एपीआई है, जो अच्छी परफ़ॉर्मेंस वाले 3D ग्राफ़िक के लिए, कम ओवरहेड देता है.

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

[C-SR-1] Vulkan 1.3 के साथ काम करने के लिए इस बात पर ज़ोर दिया जाता है.
[C-4-1] Vulkan वर्शन के साथ काम नहीं करना चाहिए (यानी कि Vulkan के कोर वर्शन के वैरिएंट वाला हिस्सा शून्य होना चाहिए).

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

[C-SR-2] को Vulkan 1.3 के साथ काम करने के लिए इस्तेमाल करने का सुझाव दिया जाता है.

Vulkan dEQP टेस्ट को कई टेस्ट सूचियों में बांटा गया है. हर सूची में इससे जुड़ी तारीख/वर्शन मौजूद है. ये external/deqp/android/cts/main/vk-main-YYYY-MM-DD.txt पर Android सोर्स ट्री में हैं. एक डिवाइस जो खुद से रिपोर्ट किए गए लेवल पर Vulkan के साथ काम करता है, यह बताता है कि वह इस लेवल और उससे पहले के लेवल की सभी टेस्ट सूचियों में dEQP की जांच को पास कर सकता है.

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

[C-1-1] android.hardware.vulkan.level और android.hardware.vulkan.version फ़ीचर फ़्लैग के साथ सही पूर्णांक वैल्यू की रिपोर्ट करना ज़रूरी है.
[C-1-2] Vulkan नेटिव एपीआई vkEnumeratePhysicalDevices() के लिए, कम से कम एक VkPhysicalDevice की गिनती करना ज़रूरी है.
[C-1-3] सूची में शामिल हर VkPhysicalDevice के लिए, Vulkan 1.0 एपीआई को पूरी तरह से लागू करना ज़रूरी है.
[C-1-4] ऐप्लिकेशन पैकेज की नेटिव लाइब्रेरी डायरेक्ट्री में, libVkLayer*.so नाम की नेटिव लाइब्रेरी में मौजूद लेयर की गिनती करना ज़रूरी है. ऐसा Vulkan नेटिव एपीआई vkEnumerateInstanceLayerProperties() और vkEnumerateDeviceLayerProperties() की मदद से किया जाता है.
[C-1-5] ऐप्लिकेशन पैकेज के बाहर की लाइब्रेरी से मिली लेयर की गिनती नहीं करनी चाहिए या Vulkan API को ट्रेस करने या रोकने के दूसरे तरीके नहीं बताना चाहिए. ऐसा तब तक नहीं होना चाहिए, जब तक ऐप्लिकेशन में android:debuggable एट्रिब्यूट को true के तौर पर सेट न किया गया हो.
[C-1-6] उन सभी एक्सटेंशन स्ट्रिंग की रिपोर्ट करना ज़रूरी है जिन्हें वे Vulkan नेटिव एपीआई के ज़रिए इस्तेमाल करते हैं. साथ ही , उन एक्सटेंशन स्ट्रिंग को रिपोर्ट नहीं करना चाहिए जिनके साथ वे सही तरीके से काम नहीं करते हैं.
[C-1-7] VK_KHR_Surface, VK_KHR_android_Surface, VK_KHR_swapchain, और VK_KHR_incremental_present एक्सटेंशन के साथ काम करना ज़रूरी है.
[C-1-8] आपको android.software.vulkan.deqp.level फ़ीचर फ़्लैग का इस्तेमाल करके, Vulkan dEQP टेस्ट के ज़्यादा से ज़्यादा वर्शन की जानकारी देनी होगी.
[C-1-9] यह ज़रूरी है कि कम से कम यह वर्शन 132317953 (1 मार्च, 2019 से) पर काम करता हो, जैसा कि android.software.vulkan.deqp.level फ़ीचर फ़्लैग में बताया गया है.
[C-1-10] वर्शन 132317953 और android.software.vulkan.deqp.level फ़ीचर फ़्लैग में बताए गए वर्शन के बीच की टेस्ट सूचियों में, सभी Vulkan dEQP टेस्ट को पास करना ज़रूरी है.
[C-1-11] VK_KHR_video_queue, VK_KHR_video_decode_queue, या VK_KHR_video_encode_queue एक्सटेंशन के लिए सहायता की गिनती नहीं करनी चाहिए.
[C-SR-3] VK_KHR_driver_properties और VK_GOOGLE_display_timing एक्सटेंशन के साथ काम करने के लिए, इस बात का खास तौर पर सुझाव दिया जाता है.
VkPhysicalDeviceProtectedMemoryFeatures और VK_EXT_global_priority के साथ काम करना चाहिए.
[C-1-12] VK_KHR_performance_query एक्सटेंशन के लिए, सहायता की गिनती नहीं करनी चाहिए.
[C-SR-4] Android बेसलाइन 2021 प्रोफ़ाइल में बताई गई ज़रूरी शर्तों को पूरा करने के लिए, इस बात का खास तौर पर सुझाव दिया जाता है.

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

[C-2-1] Vulkan की किसी भी सुविधा के फ़्लैग के बारे में एलान नहीं करना चाहिए (जैसे, android.hardware.vulkan.level, android.hardware.vulkan.version).
[C-2-2] Vulkan नेटिव एपीआई vkEnumeratePhysicalDevices() के लिए, किसी भी VkPhysicalDevice की गिनती नहीं करनी चाहिए.

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

[C-3-1] SYNC_FD एक्सटर्नल सेमाफ़ोर और हैंडल टाइप और VK_ANDROID_external_memory_android_hardware_buffer एक्सटेंशन के लिए सहायता देना ज़रूरी है.

7.1.4.3 रेंडरस्क्रिप्ट

[C-0-1] Android SDK के दस्तावेज़ में दी गई जानकारी के मुताबिक, डिवाइस पर Android RenderScript काम करना ज़रूरी है.

7.1.4.4 2D ग्राफ़िक ऐक्सेलरेशन

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

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

[C-0-1] हार्डवेयर से तेज़ी लाने की सुविधा को डिफ़ॉल्ट रूप से चालू करना ज़रूरी है. साथ ही, अगर डेवलपर ऐसा करने का अनुरोध करता है, तो हार्डवेयर से तेज़ी लाने की सुविधा को बंद करना ज़रूरी है. इसके लिए, डेवलपर को सीधे Android View API से android:hardwareAccelerated="false" सेट करके या हार्डवेयर से तेज़ी लाने की सुविधा बंद करनी होगी.
[C-0-2] हार्डवेयर से तेज़ी लाने की सुविधा के बारे में, Android SDK के दस्तावेज़ के मुताबिक काम करना चाहिए.

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

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

[C-0-3] TextureView API के साथ काम करना ज़रूरी है. साथ ही, इसे अपस्ट्रीम Android को लागू करने के तरीके का इस्तेमाल करना चाहिए.

7.1.4.5 वाइड-गाम डिसप्ले

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

[C-1-1] रंग के हिसाब से कैलिब्रेट किया गया डिसप्ले होना चाहिए.
[C-1-2] में एक ऐसा डिसप्ले होना चाहिए जिसका गेमट, CIE 1931 xyY स्पेस में पूरी तरह से sRGB के कलर गामट को ढक देता हो.
[C-1-3] ऐसा डिसप्ले होना ज़रूरी है जिसके गैमट का एरिया, CIE 1931 xyY स्पेस में DCI-P3 का कम से कम 90% है.
[C-1-4] OpenGL ES 3.1 या 3.2 के साथ काम करना चाहिए और इसकी सही तरीके से रिपोर्ट करनी चाहिए.
[C-1-5] EGL_KHR_no_config_context, EGL_EXT_pixel_format_float, EGL_KHR_gl_colorspace, EGL_EXT_gl_colorspace_scrgb, EGL_EXT_gl_colorspace_scrgb_linear, EGL_EXT_gl_colorspace_display_p3, EGL_EXT_gl_colorspace_display_p3_linear और EGL_EXT_gl_colorspace_display_p3_passthrough एक्सटेंशन के लिए सहायता का विज्ञापन देना ज़रूरी है.
GL_EXT_sRGB के साथ काम करने के लिए, [C-SR-1] का सुझाव दिया जाता है.

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

[C-2-1] CIE 1931 xyY स्पेस में, 100% या इससे ज़्यादा sRGB में कवर होना चाहिए. हालांकि, स्क्रीन के रंग के लेवल के बारे में नहीं बताया गया है.

7.1.5. ऐप्लिकेशन के साथ काम करने वाला लेगसी मोड

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

7.1.6. स्क्रीन टेक्नोलॉजी

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

डिवाइस लागू करने के दौरान Android के साथ काम करने वाले सभी डिसप्ले:

[C-0-1] 16-बिट कलर ग्राफ़िक रेंडर करने की क्षमता होनी चाहिए.
24-बिट रंग ग्राफ़िक्स वाले डिस्प्ले का समर्थन करना चाहिए.
[C-0-2] ऐनिमेशन रेंडर करने की क्षमता होनी चाहिए.
[C-0-3] पिक्सल का आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) 0.9 से 1.15 के बीच होना चाहिए. इसका मतलब है कि पिक्सल का आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) स्क्वेयर (1.0) के आस-पास होना चाहिए, जिसमें 10 ~ 15% टॉलरेंस हो.

7.1.7. दूसरे डिसप्ले

Android में, सेकंडरी Android साथ काम करने वाले डिसप्ले काम करते हैं. इससे मीडिया शेयर करने की सुविधाएं और बाहरी डिसप्ले ऐक्सेस करने के लिए डेवलपर एपीआई चालू किए जा सकते हैं.

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

[C-1-1] Android SDK के दस्तावेज़ में बताया गया है कि DisplayManager सिस्टम की सेवा और एपीआई को लागू करना ज़रूरी है.

7.2. इनपुट डिवाइस

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

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

7.2.1. कीबोर्ड

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

[C-1-1] android.software.input_methods फ़ीचर फ़्लैग का एलान करना ज़रूरी है.
[C-1-2] Input Management Framework को पूरी तरह से लागू करना ज़रूरी है
[C-1-3] सॉफ़्टवेयर कीबोर्ड पहले से इंस्टॉल होना चाहिए.

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

[C-0-1] ऐसा हार्डवेयर कीबोर्ड शामिल नहीं किया जाना चाहिए जो android.content.res.Configuration.keyboard (QWERTY या 12-key) में बताए गए किसी एक फ़ॉर्मैट से मेल नहीं खाता.
इसमें सॉफ़्ट कीबोर्ड इस्तेमाल करने के अतिरिक्त विकल्प शामिल होने चाहिए.
इसमें हार्डवेयर कीबोर्ड शामिल हो सकता है.

7.2.2. बिना छुए नेविगेशन

Android में डी-पैड, ट्रैकबॉल, और व्हील को नॉन-टच नेविगेशन के लिए इस्तेमाल किया जा सकता है.

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

[C-0-1] android.content.res.Configuration.navigation के लिए सही वैल्यू की रिपोर्ट करना ज़रूरी है.

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

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

7.2.3. नेविगेशन कुंजियां

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

[C-0-1] ऐसे इंस्टॉल किए गए ऐप्लिकेशन लॉन्च करने के लिए उपयोगकर्ता को ज़रूरी सुविधा देनी होगी जिनकी गतिविधि में ACTION=MAIN और CATEGORY=LAUNCHER या टेलीविज़न डिवाइस लागू करने के लिए CATEGORY=LEANBACK_LAUNCHER के साथ <intent-filter> सेट हो. उपयोगकर्ता के लिए इस तरह के खर्च को मैनेज करने के लिए, होम फ़ंक्शन को इस्तेमाल किया जाना चाहिए.
हाल ही के और वापस जाएं फ़ंक्शन के लिए बटन देने चाहिए.

अगर होम, हाल ही के या वापस जाएं फ़ंक्शन दिए गए हों, तो वे:

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

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

[C-SR-1] का सुझाव दिया जाता है, ताकि मेन्यू फ़ंक्शन के लिए इनपुट का तरीका न बताया जाए. ऐसा इसलिए, क्योंकि Android 4.0 के बाद से ऐक्शन बार की सुविधा काम नहीं करती.
[C-SR-2] नेविगेशन के सभी फ़ंक्शन को रद्द करने लायक बनाने के लिए, इस बात का खास तौर पर सुझाव दिया जाता है. 'रद्द किया जा सकने वाला' का मतलब है कि उपयोगकर्ता किसी तय सीमा से आगे स्वाइप न करने पर, नेविगेशन फ़ंक्शन को लागू होने से रोक सकता है. जैसे, घर जाना, वापस जाना वगैरह.

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

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

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

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

[C-4-1] जब अन्य नेविगेशन कुंजियां ऐक्सेस की जा सकें, तब एक कार्रवाई (जैसे कि टैप करना, दो बार क्लिक करना या हाथ के जेस्चर) से, Assist फ़ंक्शन को ऐक्सेस करना ज़रूरी है.
[C-SR-3] इस इंटरैक्शन के लिए Home फ़ंक्शन को दबाकर रखने का सुझाव दिया जाता है.

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

[C-5-1] नेविगेशन कुंजियों को स्क्रीन के एक खास हिस्से का इस्तेमाल करना चाहिए, जो ऐप्लिकेशन के लिए उपलब्ध नहीं है और ऐप्लिकेशन के लिए उपलब्ध स्क्रीन के हिस्से को धुंधला नहीं करना चाहिए या उसमें कोई रुकावट नहीं डालनी चाहिए.
[C-5-2] डिसप्ले का कुछ हिस्सा उन ऐप्लिकेशन के लिए उपलब्ध कराना ज़रूरी है जो सेक्शन 7.1.1 में बताई गई ज़रूरी शर्तों को पूरा करते हों.
[C-5-3] ऐप्लिकेशन के सेट किए गए फ़्लैग को View.setSystemUiVisibility() एपीआई तरीके से सेट करना ज़रूरी है, ताकि स्क्रीन का यह खास हिस्सा (यानी नेविगेशन बार) SDK में बताए गए तरीके से छिपाया गया हो.

[C-6-1] WindowInsets#getMandatorySystemGestureInsets() इसका इस्तेमाल सिर्फ़, होम जेस्चर की पहचान करने वाली जगह की जानकारी देने के लिए किया जाना चाहिए.
[C-6-2] हाथ के ऐसे जेस्चर जो View#setSystemGestureExclusionRects() के ज़रिए फ़ोरग्राउंड ऐप्लिकेशन में बताए गए, बाहर रखे गए रेक्टैंगल से शुरू होते हैं, लेकिन WindowInsets#getMandatorySystemGestureInsets() के बाहर होते हैं. नेविगेशन फ़ंक्शन में तब तक रोके नहीं जाने चाहिए, जब तक View#setSystemGestureExclusionRects() के दस्तावेज़ में बताए गए, सबसे ज़्यादा एक्सक्लूज़न की सीमा के अंदर रेंज को बाहर रखने की अनुमति नहीं है.
[C-6-3] आपको फ़ोरग्राउंड ऐप्लिकेशन को एक MotionEvent.ACTION_CANCEL इवेंट भेजना होगा. ऐसा तब होगा, जब टच करने पर सिस्टम जेस्चर का ऐक्सेस न मिले. ऐसा तब होता है, जब फ़ोरग्राउंड ऐप्लिकेशन को पहले MotionEvent.ACTION_DOWN इवेंट भेजा गया हो.
[C-6-4] लोगों को ऑन-स्क्रीन, बटन-आधारित नेविगेशन (उदाहरण के लिए, सेटिंग में) पर स्विच करने के लिए विकल्प देना ज़रूरी है.
होम फ़ंक्शन को स्क्रीन के मौजूदा ओरिएंटेशन के निचले किनारे से ऊपर की ओर स्वाइप करना चाहिए.
'हाल ही के' फ़ंक्शन में स्क्रीन को दबाकर रखने और छोड़ने से पहले, ऊपर की ओर स्वाइप करने की सुविधा होनी चाहिए.
WindowInsets#getMandatorySystemGestureInsets() के अंदर शुरू होने वाले हाथ के जेस्चर View#setSystemGestureExclusionRects() के ज़रिए फ़ोरग्राउंड ऐप्लिकेशन में दिए गए एक्सक्लूज़न रेक्टैंगल से प्रभावित नहीं होने चाहिए.

अगर स्क्रीन के मौजूदा ओरिएंटेशन के बाएं और दाएं किनारों पर कहीं से भी नेविगेशन फ़ंक्शन दिया गया है, तो:

[C-7-1] नेविगेशन फ़ंक्शन को वापस जाना ज़रूरी है. स्क्रीन की मौजूदा ओरिएंटेशन के बाएं और दाएं, दोनों किनारों से स्वाइप करके एक स्वाइप में दिखाएं.
[C-7-2] अगर स्वाइप किए जा सकने वाले कस्टम सिस्टम पैनल बाएं या दाएं किनारों पर दिए गए हैं, तो उन्हें स्क्रीन के सबसे ऊपर के एक तिहाई हिस्से में रखा जाना चाहिए. साथ ही, साफ़ तौर पर और लगातार दिखने वाला यह संकेत मिलना चाहिए कि खींचकर छोड़ने पर ऊपर दिए गए पैनल शुरू हो जाएंगे, इसलिए उन्हें वापस नहीं जाना चाहिए. सिस्टम पैनल को उपयोगकर्ता इस तरह से कॉन्फ़िगर कर सकता है कि वह स्क्रीन के किनारों के ऊपरी एक / तिहाई हिस्से से नीचे चला जाए, लेकिन सिस्टम पैनल को किनारों के एक तिहाई से ज़्यादा हिस्से का इस्तेमाल नहीं करना चाहिए.
[C-7-3] जब फ़ोरग्राउंड ऐप्लिकेशन में View.system_UI_FLAG_IMMERSIVE, View.सिस्टम_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT या WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE फ़्लैग का इस्तेमाल किया गया हो, तो यह SDK में सेट के रूप में लागू होता है.
[C-7-4] जब फ़ोरग्राउंड ऐप्लिकेशन में View.system_UI_FLAG_IMMERSIVE, View.system_UI_FLAG_IMMERSIVE_STICKY, WindowInsetsController.BEHAVIOR_DEFAULT या WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARSable_BY_BY_BY_सिस्टम बार को फ़्लैग किया गया या कस्टम बार के सेट के रूप में स्वाइप किया गया.

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

[C-8-1] OnBackInvokedCallback.onBackCancelled() पर कॉल करना ज़रूरी है.
[C-8-2] OnBackInvokedCallback.onBackInvoked() पर कॉल नहीं किया जाना चाहिए.
[C-8-3] KEYCODE_BACK इवेंट भेजा नहीं जाना चाहिए.

अगर आपने पिछला नेविगेशन फ़ंक्शन दिया है, लेकिन फ़ोरग्राउंड ऐप्लिकेशन में OnBackInvokedCallback को रजिस्टर नहीं किया गया है, तो:

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

अगर लागू किए गए डिवाइस, सिस्टम एपीआई setNavBarMode पर काम करते हैं, तो android.permission.STATUS_BAR की अनुमति वाले किसी भी सिस्टम ऐप्लिकेशन को नेविगेशन बार मोड सेट करने की अनुमति मिलती है, तो:

[C-9-1] बच्चों के हिसाब से बने आइकॉन या बटन की मदद से नेविगेट करने की सुविधा देना ज़रूरी है, जैसा कि एओएसपी कोड में बताया गया है.

7.2.4. टचस्क्रीन इनपुट

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

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

इसमें किसी तरह का पॉइंटर इनपुट सिस्टम होना चाहिए (माउस की तरह या छूकर).
इसमें पूरी तरह से अलग-अलग ट्रैक किए गए पॉइंटर का इस्तेमाल किया जाना चाहिए.

अगर Android डिवाइसों के साथ काम करने वाले मुख्य डिसप्ले में टचस्क्रीन (सिंगल-टच या बेहतर सुविधा) शामिल है, तो ये काम किए जा सकते हैं:

[C-1-1] Configuration.touchscreen एपीआई फ़ील्ड के लिए, TOUCHSCREEN_FINGER को रिपोर्ट करना ज़रूरी है.
[C-1-2] android.hardware.touchscreen और android.hardware.faketouch फ़ीचर फ़्लैग की रिपोर्ट करना ज़रूरी है.

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

[C-2-1] डिवाइस पर टचस्क्रीन के टाइप के हिसाब से, सही फ़ीचर फ़्लैग android.hardware.touchscreen.multitouch, android.hardware.touchscreen.multitouch.distinct, android.hardware.touchscreen.multitouch.jazzhand की शिकायत करना ज़रूरी है.

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

[C-3-1] android.hardware.touchscreen से शुरू होने वाले किसी भी फ़ीचर फ़्लैग की शिकायत नहीं करनी चाहिए.
[C-3-2] सिर्फ़ android.hardware.faketouch की शिकायत करें.
[C-3-3] Configuration.touchscreen एपीआई फ़ील्ड के लिए, TOUCHSCREEN_NOTOUCH को रिपोर्ट करना ज़रूरी है.

7.2.5. नकली टच इनपुट

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

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

यह एलान करना चाहिए कि यह सुविधा android.hardware.faketouch फ़ीचर फ़्लैग के लिए काम करती है.

अगर डिवाइस लागू करने की सुविधा, android.hardware.faketouch के साथ काम करती है, तो:

[C-1-1] पॉइंटर की X और Y स्क्रीन की पोज़िशन की रिपोर्ट करना ज़रूरी है. साथ ही, स्क्रीन पर एक विज़ुअल पॉइंटर दिखाना ज़रूरी है.
[C-1-2] आपको कार्रवाई कोड के साथ टच इवेंट को रिपोर्ट करना ज़रूरी है. यह कोड, पॉइंटर पर स्क्रीन पर नीचे या ऊपर जाने की स्थिति में होने वाले बदलाव के बारे में बताता है.
[C-1-3] स्क्रीन पर मौजूद किसी ऑब्जेक्ट पर, नीचे और ऊपर की ओर पॉइंटर की सुविधा का इस्तेमाल करना ज़रूरी है. इससे स्क्रीन पर मौजूद किसी ऑब्जेक्ट पर टैप करके, उपयोगकर्ता उसे एम्युलेट कर सकते हैं.
[C-1-4] समय की सीमा के अंदर, स्क्रीन पर किसी ऑब्जेक्ट पर एक ही जगह पर पॉइंटर को नीचे, ऊपर की ओर, नीचे की ओर फिर पॉइंटर को ऊपर की ओर ले जाना चाहिए. इससे उपयोगकर्ता स्क्रीन पर मौजूद किसी ऑब्जेक्ट पर दो बार टैप करने की सुविधा का इस्तेमाल कर सकते हैं.
[C-1-5] स्क्रीन पर किसी भी जगह पर पॉइंटर डाउन करके भी चलाया जा सकता है. इसके बाद, पॉइंटर, स्क्रीन पर मौजूद किसी भी अन्य आर्बिट्रेरी पॉइंट पर चला जाता है. इसके बाद पॉइंटर इस्तेमाल करना, उपयोगकर्ताओं को टच ड्रैग करने की सुविधा देता है.
[C-1-6] पॉइंटर को नीचे की ओर ले जाना ज़रूरी है, फिर उपयोगकर्ताओं को ऑब्जेक्ट को स्क्रीन पर किसी दूसरी जगह पर तुरंत ले जाने और फिर स्क्रीन पर ऊपर की ओर ले जाने की अनुमति दें, ताकि उपयोगकर्ता स्क्रीन पर ऑब्जेक्ट को फेंक सकें.

अगर डिवाइस लागू करने की प्रक्रिया में, android.hardware.faketouch.multitouch.distinct के साथ काम करने का एलान किया जाता है, तो:

[C-2-1] android.hardware.faketouch के लिए सहायता का एलान करना ज़रूरी है.
[C-2-2] दो या उससे ज़्यादा इंडिपेंडेंट पॉइंटर इनपुट की अलग-अलग ट्रैकिंग के साथ काम करना ज़रूरी है.

अगर डिवाइस लागू करने की प्रक्रिया में, android.hardware.faketouch.multitouch.jazzhand के साथ काम करने का एलान किया जाता है, तो:

[C-3-1] android.hardware.faketouch के साथ काम करने का एलान करना ज़रूरी है.
[C-3-2] 5 (उंगलियों के इस्तेमाल को ट्रैक करना) या एक से ज़्यादा पॉइंटर इनपुट को पूरी तरह से अलग-अलग ट्रैक करना ज़रूरी है.

7.2.6. गेम कंट्रोलर के लिए सहायता

7.2.6.1. बटन मैपिंग

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

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

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

[C-2-1] फ़ीचर फ़्लैग android.hardware.gamepad का एलान करना ज़रूरी है

बटन	एचआईडी का इस्तेमाल²	Android बटन
जवाब¹	0x09 0x001	KEYCODE_BUTTON_A (96)
ब¹	0x09 0x0002	KEYCODE_BUTTON_B (97)
X¹	0x09 0x004	KEYCODE_BUTTON_X (99)
साल¹	0x09 0x005	KEYCODE_BUTTON_Y (100)
डी-पैड अप¹ डी-पैड डाउन करें¹	0x01 0x0039³	AXIS_HAT_Y⁴
बाईं ओर मौजूद डी-पैड1 डी-पैड दाईं ओर¹	0x01 0x0039³	AXIS_HAT_X⁴
बाईं ओर का बटन¹	0x09 0x007	KEYCODE_BUTTON_L1 (102)
राइट शोल्डर बटन¹	0x09 0x008	KEYCODE_BUTTON_R1 (103)
लेफ़्ट स्टिक क्लिक¹	0x09 0x000	KEYCODE_BUTTON_THUMBL (106)
राइट स्टिक पर क्लिक करें¹	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
वापस जाएं¹	0x0c 0x0224	KEYCODE_BACK (4)

1 KeyEvent

2 ऊपर दिए गए एचआईडी के इस्तेमाल के बारे में, गेमपैड CA (0x01 0x0005) में जानकारी दी जानी चाहिए.

3 इस इस्तेमाल में कम से कम 0, लॉजिकल ज़्यादा से ज़्यादा 7, फ़िज़िकल तौर पर कम से कम 0, फ़िज़िकल ज़्यादा से ज़्यादा 315, डिग्री वाली यूनिट, और रिपोर्ट का साइज़ 4 होना ज़रूरी है. लॉजिकल वैल्यू को वह होता है जो वर्टिकल ऐक्सिस से घड़ी की दिशा में घूमने की दिशा में नहीं होता. उदाहरण के लिए, 0 का लॉजिकल वैल्यू कोई रोटेशन नहीं दिखाता और ऊपर वाला बटन दबाया जाता है. वहीं, 1 का लॉजिकल वैल्यू 45 डिग्री के रोटेशन और ऊपर और बाईं दोनों कुंजियों को दबाने के बारे में बताती है.

4 MotionEvent

ऐनालॉग कंट्रोल¹	एचआईडी का इस्तेमाल	Android बटन
बायां ट्रिगर	0x02 0x00C5	एएक्सआईएस_एलट्रर
राइट ट्रिगर	0x02 0x00C4	AXIS_Rट्रिगर
बाईं जॉयस्टिक	0x01 0x0030 0x01 0x0031	AXIS_X AXIS_Y
दाईं जॉयस्टिक	0x01 0x0032 0x01 0x0035	AXIS_Z AXIS_RZ

1 MotionEvent

7.2.7. रिमोट कंट्रोल

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

7.3. सेंसर

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

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

[C-0-1] android.content.pm.PackageManager क्लास के हिसाब से, सेंसर के मौजूद या न होने की सटीक जानकारी देना ज़रूरी है.
[C-0-2] SensorManager.getSensorList() और इससे मिलते-जुलते तरीकों का इस्तेमाल करके, इस्तेमाल किए जा सकने वाले सेंसर की सटीक सूची देनी होगी.
[C-0-3] अन्य सभी सेंसर एपीआई के लिए, उचित तरीके से व्यवहार करना चाहिए. उदाहरण के लिए, जब कोई ऐप्लिकेशन लिसनर रजिस्टर करने की कोशिश करता है, तब true या false को लौटाकर, सेंसर लिसनर को कॉल न करना, जब उससे जुड़े सेंसर मौजूद न हों वगैरह.

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

[C-1-1] Android SDK के दस्तावेज़ में बताया गया है कि हर तरह के सेंसर के लिए, इंटरनैशनल सिस्टम ऑफ़ यूनिट (मेट्रिक) की वैल्यू का इस्तेमाल करके सभी सेंसर मेज़रमेंट की रिपोर्ट ज़रूरी है.
[C-1-2] ऐप्लिकेशन प्रोसेसर के चालू होने पर, सेंसर डेटा को ज़्यादा से ज़्यादा 100 मिलीसेकंड + 2 * sample_time की रिपोर्ट करना ज़रूरी है. ऐसा, सेंसर स्ट्रीम के मामले में इंतज़ार के समय के लिए 0 मि॰से॰ की ज़्यादा से ज़्यादा इंतज़ार के समय के साथ होना चाहिए. इस देरी में, फ़िल्टर करने में हुई देरी शामिल नहीं है.
[C-1-3] सेंसर के पहले सेंसर सैंपल को 400 मिलीसेकंड में + 2 * sample_time तब रिपोर्ट करना ज़रूरी है, जब सेंसर चालू किए जा रहे हों. इस सैंपल के लिए, वैल्यू 0 का सटीक वैल्यू होना स्वीकार है.
[C-1-4] Android SDK दस्तावेज़ से बताए गए किसी भी एपीआई को लगातार सेंसर करने के लिए, डिवाइस को लागू करने के लिए समय-समय पर डेटा के ऐसे सैंपल देने ज़रूरी हैं जिनमें 3% से कम का सिग्नल मिला हो. यहां सिग्नल में गड़बड़ी को लगातार इवेंट के बीच रिपोर्ट किए गए टाइमस्टैंप की वैल्यू के अंतर के स्टैंडर्ड अंतर के तौर पर माना जाता है.
[C-1-5] को यह पक्का करना होगा कि सेंसर इवेंट की स्ट्रीम, डिवाइस के सीपीयू को निलंबित होने की स्थिति में जाने या निलंबन की स्थिति से जगाने से न रोके.
[C-1-6] Android SDK के दस्तावेज़ में दिए गए निर्देशों के मुताबिक, नैनोसेकंड में इवेंट के समय की रिपोर्ट करना ज़रूरी है. इससे यह पता चलता है कि इवेंट कब हुआ और SystemClock.eलैप्स रीयलटाइमNano() घड़ी के साथ कैसे सिंक हुआ.
[C-SR-1] का सुझाव दिया जाता है कि टाइमस्टैंप सिंक करने में गड़बड़ी 100 मिलीसेकंड से कम हो. साथ ही, टाइमस्टैंप सिंक करने की गड़बड़ी 1 मिलीसेकंड से कम होनी चाहिए.
कई सेंसर चालू होने पर, ऊर्जा की खपत, अलग-अलग सेंसर से मिली ऊर्जा की कुल खपत से ज़्यादा नहीं होनी चाहिए.

ऊपर दी गई सूची में पूरी जानकारी नहीं दी गई है. सेंसर पर दिए गए Android SDK टूल और Android ओपन सोर्स दस्तावेज़ों के व्यवहार को आधिकारिक माना जाना चाहिए.

[C-1-6] आपको सभी सेंसर के लिए, शून्य के अलावा किसी अन्य रिज़ॉल्यूशन को सेट करना होगा. साथ ही, Sensor.getResolution() एपीआई तरीके का इस्तेमाल करके, वैल्यू की रिपोर्ट देनी होगी.

कुछ सेंसर कंपोज़िट होते हैं, जिसका मतलब है कि उन्हें एक या उससे ज़्यादा अन्य सेंसर से मिले डेटा से लिया जा सकता है. (उदाहरण के लिए, ओरिएंटेशन सेंसर और लीनियर ऐक्सेलरेशन सेंसर.)

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

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

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

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

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

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

अगर डिवाइस पर कोई ऐसा सेंसर टाइप मौजूद है जो SensoradditionalInfo#TYPE_VEC3_CALIBRATION के साथ काम करता है और सेंसर तीसरे पक्ष के डेवलपर के संपर्क में आता है, तो वे:

[C-4-1] डेटा में, पहले से तय किसी भी तरह के कैलिब्रेशन पैरामीटर को शामिल नहीं किया जाना चाहिए.

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

[C-SR-2] यह पक्का करने के लिए बहुत ज़्यादा सुझाव दिया जाता है कि एक्सलरोमीटर, जाइरोस्कोप, और मैग्नेटोमीटर की एक तय मिलती-जुलती पोज़िशन हो. उदाहरण के लिए, डिवाइस के ट्रांसफ़ॉर्मेशन होने पर (जैसे, फ़ोल्ड किया जा सकने वाला डिवाइस), जब डिवाइस ट्रांसफ़ॉर्मेशन की सभी स्थितियों में, सेंसर कोऑर्डिनेट सिस्टम के साथ अलाइन रहता है और उसे एक जैसा रखता है.

7.3.1. एक्सलरोमीटर

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

[C-SR-1] तीन-ऐक्सिस एक्सलरोमीटर शामिल करने का सुझाव दिया जाता है.

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

[C-1-1] कम से कम 50 हर्ट्ज़ की फ़्रीक्वेंसी तक इवेंट की रिपोर्ट उपलब्ध होनी चाहिए.
[C-1-3] Android सेंसर कोऑर्डिनेट सिस्टम का पालन करना ज़रूरी है, जैसा कि Android API में बताया गया है.
[C-1-4] ऐसा ज़रूरी है कि किसी भी ऐक्सिस पर गुरुत्वाकर्षण(4g) या इससे ज़्यादा के फ़्रीफ़ॉल को चार गुना तक मापने की क्षमता हो.
[C-1-5] इसका रिज़ॉल्यूशन कम से कम 12-बिट होना चाहिए.
[C-1-6] स्टैंडर्ड डेविएशन का स्टैंडर्ड डेविएशन 0.05 m/s^ से ज़्यादा न हो, जिसमें स्टैंडर्ड डेविएशन का हिसाब, हर ऐक्सिस के आधार पर और कम से कम तीन सेकंड तक इकट्ठा किए गए सैंपल के आधार पर लगाया जाना चाहिए. इन सैंपल को सैंपलिंग की सबसे तेज़ी से रेट किया जाना चाहिए.
कम से कम 200 हर्ट्ज़ तक इवेंट रिपोर्ट किए जाने चाहिए.
रिज़ॉल्यूशन कम से कम 16-बिट होना चाहिए.
अगर इस्तेमाल करने के दौरान, लाइफ़ साइकल के दौरान विशेषताओं में बदलाव होता है और पेमेंट हो जाता है, तो इसे इस्तेमाल करते समय कैलिब्रेट होना चाहिए. साथ ही, डिवाइस को फिर से चालू करने के बीच में, कंपंसेशन के पैरामीटर को सुरक्षित रखना चाहिए.
हालांकि, तापमान के हिसाब से मुआवज़ा दिया जाना चाहिए.

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

[C-2-1] TYPE_ACCELEROMETER सेंसर को लागू करना और उसकी रिपोर्ट करना ज़रूरी है.
[C-SR-4] TYPE_SIGNIFICANT_MOTION कंपोज़िट सेंसर को लागू करने के लिए, बहुत ज़्यादा सुझाव दिया जाता है.
[C-SR-5] TYPE_ACCELEROMETER_UNCALIBRATED सेंसर को लागू करने और इसकी रिपोर्ट करने के लिए बहुत ज़्यादा सुझाव दिया जाता है. इस ज़रूरी शर्त को पूरा करने के लिए, Android डिवाइसों का बहुत ज़्यादा सुझाव दिया जाता है. इससे उन्हें आने वाले समय में लॉन्च होने वाले प्लैटफ़ॉर्म पर अपग्रेड किया जा सकेगा, जहां ऐसा करना ज़रूरी हो सकता है.
TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER कंपोज़िट सेंसर को लागू करना चाहिए, जैसा कि Android SDK दस्तावेज़ में बताया गया है.

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

[C-3-1] TYPE_ACCELEROMETER_LIMITED_AXES सेंसर को लागू करना और उसकी रिपोर्ट करना ज़रूरी है.
[C-SR-6] TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED सेंसर को लागू करने और उसकी रिपोर्ट करने के लिए, STRONGLY_सुझाया गया तरीका अपनाएं.

अगर डिवाइस पर लागू होने वाले तीन-ऐक्सिस एक्सलरोमीटर और TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER में से कोई भी कंपोज़िट सेंसर इस्तेमाल किया जाता है, तो:

[C-4-1] उनकी कुल ऊर्जा की खपत हमेशा 4 mW से कम होनी चाहिए.
डाइनैमिक या स्टैटिक स्थिति में होने पर, हर एक की ऊर्जा का साइज़ 2 mW और 0.5 mW से कम होना चाहिए.

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

[C-5-1] TYPE_GRAVITY और TYPE_LINEAR_ACCELERATION कंपोज़िट सेंसर को लागू करना ज़रूरी है.
TYPE_GAME_ROTATION_VECTOR कंपोज़िट सेंसर को इस्तेमाल करने के लिए, [C-SR-7] का बहुत ज़्यादा सुझाव दिया जाता है.

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

[C-6-1] TYPE_ROTATION_VECTOR कंपोज़िट सेंसर को लागू करना ज़रूरी है.

7.3.2. मैग्नेटोमीटर

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

[C-SR-1] तीन-ऐक्सिस मैग्नेटोमीटर (कम्पास) शामिल करने के लिए बहुत ज़्यादा सुझाव दिया जाता है.

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

[C-1-1] TYPE_MAGNETIC_FIELD सेंसर को लागू करना ज़रूरी है.
[C-1-2] इवेंट को कम से कम 10 हर्ट्ज़ तक की फ़्रीक्वेंसी रिपोर्ट किया जा सकता है और कम से कम 50 हर्ट्ज़ तक की फ़्रीक्वेंसी रिपोर्ट की जानी चाहिए.
[C-1-3] Android एपीआई में दी गई जानकारी के मुताबिक, Android सेंसर कोऑर्डिनेट सिस्टम का पालन करना ज़रूरी है.
[C-1-4] हर ऐक्सिस पर संतृप्त होने से पहले, -900 μT और +900 μT के बीच की क्षमता होनी चाहिए.
[C-1-5] हार्ड आयरन ऑफ़सेट की वैल्यू 700 μT से कम होनी चाहिए. साथ ही, इसका वैल्यू 200 μT से कम होना चाहिए. इसके लिए, मैग्नेटोमीटर को डाइनैमिक (मौजूदा प्रेरित) और स्टैटिक (चुंबक से प्रेरित) मैग्नेटिक फ़ील्ड से दूर रखना चाहिए.
[C-1-6] रिज़ॉल्यूशन 0.6 μT के बराबर या इससे ज़्यादा होना चाहिए.
[C-1-7] हार्ड आयरन बायस को ऑनलाइन कैलिब्रेशन और मुआवज़ा का समर्थन करना चाहिए और डिवाइस को फिर से चालू करने के बीच मुआवज़े के पैरामीटर को सुरक्षित रखना चाहिए.
[C-1-8] मुलायम आयरन का मुआवज़ा लागू करना ज़रूरी है—यह कैलिब्रेशन इस्तेमाल करते समय या डिवाइस के प्रोडक्शन के दौरान किया जा सकता है.
[C-1-9] स्टैंडर्ड डेविएशन होना चाहिए, जिसका आकलन हर ऐक्सिस के आधार पर, सबसे तेज़ सैंपलिंग रेट में कम से कम तीन सेकंड की अवधि में इकट्ठा किया गया हो. यह 1.5 μT से ज़्यादा नहीं होना चाहिए; इसमें स्टैंडर्ड डीविएशन 0.5 μT से ज़्यादा नहीं होना चाहिए.
[C-1-10] TYPE_MAGNETIC_FIELD_UNCALIBRATED सेंसर को लागू करना ज़रूरी है.

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

[C-2-1] TYPE_ROTATION_VECTOR कंपोज़िट सेंसर को लागू करना ज़रूरी है.

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

TYPE_GEOMAGNETIC_ROTATION_VECTOR सेंसर को लागू किया जा सकता है.

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

[C-3-1] 10 मिलीवाट से कम बिजली का इस्तेमाल करना चाहिए.
अगर सेंसर को बैच मोड के लिए 10 हर्ट्ज़ पर रजिस्टर किया गया हो, तो इसे 3 mW से कम की खपत होनी चाहिए.

7.3.3. जीपीएस

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

[C-SR-1] GPS/GNSS रिसीवर को शामिल करने के लिए बहुत बल दिया जाता है.

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

[C-1-1] LocationManager#requestLocationUpdate से अनुरोध किए जाने पर, जगह की जानकारी के आउटपुट को कम से कम एक हर्ट्ज़ की दर पर इस्तेमाल करना ज़रूरी है.
[C-1-2] 0.5 एमबीपीएस या इससे तेज़ डेटा स्पीड वाले इंटरनेट कनेक्शन से कनेक्ट होने पर, ज़रूरी है कि ओपन-स्काई स्थितियों में जगह की जानकारी हासिल की जा सके (मज़बूत सिग्नल, बहुत कम मल्टीपाथ, एचडीओपी < 2) 10 सेकंड के अंदर (सबसे पहले ठीक करने में लगने वाला समय). आम तौर पर, यह ज़रूरी शर्त, जीपीएस/जीएनएसएस लॉक-ऑन टाइम को कम करने के लिए, असिस्टेड या अनुमानित जीपीएस/जीएनएसएस तकनीक के इस्तेमाल से पूरी की जाती है. सहायक डेटा में रेफ़रंस का समय, रेफ़रंस के लिए जगह की जानकारी, और सैटलाइट एफ़ेमेरीस/क्लॉक शामिल है.
- [C-1-6] जगह की इस तरह का कैलकुलेशन करने के बाद, डिवाइस को खुले आसमान में पांच सेकंड के अंदर, जगह की जानकारी के अनुरोध फिर से शुरू होने पर पांच सेकंड के अंदर, जगह की जानकारी का पता लगाने के एक घंटे के अंदर अपनी जगह की जानकारी तय कर लेनी चाहिए. ऐसा तब भी ज़रूरी है, जब बाद में किया गया अनुरोध बिना डेटा कनेक्शन के किया गया हो और/या पावर साइकल के बाद.
जगह का पता लगाने के बाद खुले आसमान की स्थितियों में, जब कोई स्थिर व्यक्ति हो या एक मीटर प्रति सेकंड वाले त्वरण वाले वर्ग की गति के साथ:
- [C-1-3] ज़रूरी है कि 20 मीटर के दायरे में जगह की जानकारी और कम से कम 95% मामलों में 0.5 मीटर प्रति सेकंड के दायरे में स्पीड का पता चल जाए.
- [C-1-4] GnssStatus.Callback, एक ही तारामंडल से कम से कम आठ उपग्रहों को एक साथ ट्रैक और रिपोर्ट करना ज़रूरी है.
- एक से ज़्यादा तारामंडलों (उदाहरण के लिए, GPS + कम से कम एक Glonass, Beidou, Galileo) से कम से कम 24 उपग्रहों को एक साथ ट्रैक कर पाना चाहिए.
[C-SR-2] आपातकालीन फ़ोन कॉल के दौरान GNSS Location Provider API के ज़रिए, जीपीएस/GNSS लोकेशन का सामान्य आउटपुट देना जारी रखने का सुझाव दिया जाता है.
[C-SR-3] एसबीएएस के अपवाद को छोड़कर, ट्रैक किए गए सभी नक्षत्रों (जैसा कि GnssStatus मैसेज में बताया गया है) से GNSS मापों को रिपोर्ट करने के लिए हमारी सलाह दी जाती है.
एजीसी और जीएनएसएस मेज़रमेंट की फ़्रीक्वेंसी रिपोर्ट करने के लिए, [C-SR-4] का खास तौर पर सुझाव दिया जाता है.
[C-SR-5] हर जीपीएस/जीएनएसएस की जगह की जानकारी के हिस्से के तौर पर, इस बात का खास तौर पर सुझाव दिया जाता है कि सभी सटीक अनुमान (इनमें बियरिंग, स्पीड, और वर्टिकल शामिल हैं) दें.
[C-SR-6] जीएनएसएस मापों के मिलने पर, उन्हें रिपोर्ट करने के लिए इसका बहुत ज़्यादा सुझाव दिया जाता है. भले ही जीपीएस/जीएनएसएस से मिली जगह की जानकारी अभी तक रिपोर्ट न की गई हो.
[C-SR-7] जीएनएसएस स्यूडोरेंज और स्यूडोरेंज रेट के बारे में बताने की बहुत ज़्यादा सलाह दी जाती है. जगह तय करने के बाद खुले आसमान की स्थितियों में, स्थिर या 0.2 मीटर प्रति सेकंड की एक्सीलेशन के साथ मूवमेंट के लिए, 20 मीटर और समय में 0.2 मीटर प्रति सेकंड के अंदर स्पीड का हिसाब लगाने के लिए काफ़ी होते हैं.

7.3.4. जाइरोस्कोप

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

[C-SR-1] जाइरोस्कोप सेंसर को शामिल करने का सुझाव दिया जाता है.

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

[C-1-1] कम से कम 50 हर्ट्ज़ की फ़्रीक्वेंसी तक इवेंट की रिपोर्ट उपलब्ध होनी चाहिए.
[C-1-4] इसका रिज़ॉल्यूशन 12-बिट या इससे ज़्यादा होना चाहिए.
[C-1-5] तापमान के लिए मुआवज़ा देना ज़रूरी है.
[C-1-6] इस्तेमाल करते समय कैलिब्रेट और मुआवज़ा देना ज़रूरी है. साथ ही, डिवाइस को फिर से चालू करने के बीच मुआवज़े के पैरामीटर को बनाए रखें.
[C-1-7] वैरियंस, हर हर हर्ट्ज़ (वैरियंस प्रति हर्ट्ज़ या रेड^2 / s) से ज़्यादा नहीं होना चाहिए. यह फ़र्क़ 1e-7 radi^2 / s^2 से ज़्यादा नहीं होना चाहिए. सैंपल रेट के हिसाब से, वैरियंस अलग-अलग हो सकता है, लेकिन यह वैल्यू इस वैल्यू के हिसाब से सीमित होनी चाहिए. दूसरे शब्दों में, अगर जाइरो के वैरियंस को एक हर्ट्ज़ की सैंपलिंग रेट पर मापा जाता है, तो यह 1e-7 रेड^2/s^2 से ज़्यादा नहीं होना चाहिए.
[C-SR-2] जब डिवाइस सामान्य तापमान पर स्थिर हो, तब कैलिब्रेशन की गड़बड़ी 0.01 रेड/से से कम रखने का बहुत ज़्यादा सुझाव दिया जाता है.
[C-SR-3] का रिज़ॉल्यूशन 16-बिट या उससे ज़्यादा रखने का सुझाव दिया जाता है.
कम से कम 200 हर्ट्ज़ तक इवेंट रिपोर्ट किए जाने चाहिए.

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

[C-2-1] TYPE_GYROSCOPE सेंसर को लागू करना ज़रूरी है.
[C-SR-4] TYPE_GYROSCOPE_UNCALIBRATED सेंसर को इस्तेमाल करने का सुझाव दिया जाता है.

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

[C-3-1] TYPE_GYROSCOPE_LIMITED_AXES सेंसर को लागू करना और उसकी रिपोर्ट करना ज़रूरी है.
[C-SR-5] TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED सेंसर को लागू करने और उसकी रिपोर्ट करने के लिए, बहुत ज़्यादा मेहनत करनी पड़ती है.

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

[C-4-1] TYPE_ROTATION_VECTOR कंपोज़िट सेंसर को लागू करना ज़रूरी है.

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

[C-5-1] TYPE_GRAVITY और TYPE_LINEAR_ACCELERATION कंपोज़िट सेंसर को लागू करना ज़रूरी है.
TYPE_GAME_ROTATION_VECTOR कंपोज़िट सेंसर को इस्तेमाल करने के लिए, [C-SR-6] का बहुत ज़्यादा सुझाव दिया जाता है.

7.3.5. बैरोमीटर

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

[C-SR-1] बैरोमीटर (ऐंबियंट एयर प्रेशर सेंसर) शामिल करने का सुझाव दिया जाता है.

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

[C-1-1] TYPE_PRESSURE सेंसर को लागू करना और उसकी रिपोर्ट करना ज़रूरी है.
[C-1-2] 5 हर्ट्ज़ या इससे ज़्यादा पर इवेंट डिलीवर करने की अनुमति होनी चाहिए.
[C-1-3] तापमान के लिए मुआवज़ा देना ज़रूरी है.
[C-SR-2] 300hPa से 1100hPa तक की रेंज में दबाव के मेज़रमेंट की रिपोर्ट पाने के लिए, इस सुविधा का बहुत ज़्यादा सुझाव दिया जाता है.
1hPa की पूरी तरह सटीक होना चाहिए.
0.12hPa की 20hPa रेंज से ज़्यादा सटीक होना चाहिए (यह समुद्र के स्तर पर ~200 मीटर से ज़्यादा के बदलाव के ~1m सटीक के बराबर है).

7.3.6. Thermometer

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

[C-1-1] आस-पास का तापमान मापने वाले सेंसर के लिए, सेंसर को SENSOR_TYPE_AMBIENT_TEMPERATURE तय करना ज़रूरी है. साथ ही, सेंसर को उस जगह (कमरे/वाहन के केबिन) का तापमान मापना ज़रूरी है जहां से उपयोगकर्ता, डिवाइस से डिग्री सेल्सियस में इंटरैक्ट कर रहा है.

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

[C-2-1] तापमान मापने वाले सेंसर के लिए, SENSOR_TYPE_AMBIENT_TEMPERATURE की जानकारी देना ज़रूरी नहीं है.

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

[C-SR-1] का खास तौर पर सुझाव दिया जाता है कि PowerManager.getThermalheadroom एपीआई के साथ काम किया जा सके.

7.3.7. फ़ोटोमीटर

डिवाइस में फ़ोटोमीटर (ऐंबियंट लाइट सेंसर) लगाया जा सकता है.

7.3.8. निकटता सेंसर

लागू किए जाने वाले डिवाइसों में प्रॉक्सिमिटी सेंसर शामिल हो सकता है.

अगर लागू किए गए डिवाइस में प्रॉक्सिमिटी सेंसर शामिल है और वे सिर्फ़ “आस-पास” या “दूर” रीडिंग की रिपोर्ट करते हैं, तो ये:

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

7.3.9. हाई फ़िडेलिटी सेंसर

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

[C-1-1] android.hardware.sensor.hifi_sensors फ़ीचर फ़्लैग का इस्तेमाल करके, इस क्षमता की पहचान करना ज़रूरी है.

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

[C-2-1] ऐसा TYPE_ACCELEROMETER सेंसर होना चाहिए जो:
- मेज़रमेंट की रेंज कम से कम -8 ग्रा॰ और +8 ग्रा॰ के बीच होनी चाहिए. साथ ही, कम से कम -16 ग्रा॰ और +16 ग्राम के बीच की मेज़रमेंट रेंज रखने का सुझाव दिया जाता है.
- रिज़ॉल्यूशन कम से कम 2048 LSB/g होना चाहिए.
- तापमान मापने की फ़्रीक्वेंसी कम से कम 12.5 हर्ट्ज़ या इससे कम होनी चाहिए.
- तापमान मापने की फ़्रीक्वेंसी ज़्यादा से ज़्यादा 400 हर्ट्ज़ या इससे ज़्यादा होनी चाहिए; यह SensorDirectChannel RATE_VERY_FAST के साथ काम करना चाहिए.
- तापमान मापने के लिए ज़रूरी नॉइज़ 400 μg/installHz से ज़्यादा नहीं होनी चाहिए.
- इस सेंसर को चालू करने का एक ऐसा तरीका लागू करना ज़रूरी है जिसमें कम से कम 3,000 सेंसर इवेंट की बफ़रिंग क्षमता हो.
- बैच में ऊर्जा की खपत 3 मिलीवाट से ज़्यादा नहीं होनी चाहिए.
- [C-SR-1] इस बैंडविथ में कम से कम 80% Nyquist फ़्रीक्वेंसी और व्हाइट नॉइज़ स्पेक्ट्रम की 3dB मेज़रमेंट बैंडविथ रखने की बहुत ज़ोर दिया जाता है.
- कमरे के तापमान पर 30 μg जवाब हर्ट्ज़ से कम रफ़्तार की जांच की जानी चाहिए.
- तापमान में बदलाव होना चाहिए और ≤ +/- 1 mg/°C होना चाहिए.
- सबसे सही लाइन वाली लाइन होनी चाहिए, जो 0.5% या इससे कम हो. साथ ही, तापमान की संवेदनशीलता के मुकाबले 0.03%/C° तापमान का बदलाव होना चाहिए.
- डिवाइस के इस्तेमाल किए जा रहे तापमान की रेंज में, क्रॉस-ऐक्सिस की संवेदनशीलता 2.5 % से कम और क्रॉस-ऐक्सिस की संवेदनशीलता के वैरिएशन में 0.2% से कम का अंतर होना चाहिए.
[C-2-2] ज़रूरी है कि TYPE_ACCELEROMETER_UNCALIBRATED में क्वालिटी से जुड़ी शर्तें TYPE_ACCELEROMETER जैसी हों.
[C-2-3] ऐसा TYPE_GYROSCOPE सेंसर होना चाहिए जो:
- माप की रेंज कम से कम -1000 और +1000 dps के बीच होनी चाहिए.
- रिज़ॉल्यूशन कम से कम 16 LSB/dps होना चाहिए.
- तापमान मापने की फ़्रीक्वेंसी कम से कम 12.5 हर्ट्ज़ या इससे कम होनी चाहिए.
- तापमान मापने की फ़्रीक्वेंसी ज़्यादा से ज़्यादा 400 हर्ट्ज़ या इससे ज़्यादा होनी चाहिए; यह SensorDirectChannel RATE_VERY_FAST के साथ काम करना चाहिए.
- तापमान मापने के लिए ज़रूरी नॉइज़ 0.014°/s/प्रभावित हर्ट्ज़ से ज़्यादा नहीं होनी चाहिए.
- [C-SR-2] इस बैंडविथ में कम से कम 80% Nyquist फ़्रीक्वेंसी और व्हाइट नॉइज़ स्पेक्ट्रम की 3dB मेज़रमेंट बैंडविथ रखने का बहुत ज़्यादा सुझाव दिया जाता है.
- कमरे के तापमान पर, रैंडम वॉक की दर 0.001 °/s ऐडवांस हर्ट्ज़ से कम होनी चाहिए.
- तापमान में बदलाव होना चाहिए और तापमान ≤ +/- 0.05 °/ s / °C होना चाहिए.
- 0.02% / °C के तापमान के मुकाबले संवेदनशीलता में बदलाव होना चाहिए.
- सबसे सही लाइन वाली लाइन होनी चाहिए, जो 0.2% या इससे कम हो.
- शोर की सघनता ≤ 0.007 °/s/होस्ट हर्ट्ज़ होनी चाहिए.
- डिवाइस के स्थिर रहने पर, तापमान की रेंज 10 ~ 40 °C में, कैलिब्रेशन की गड़बड़ी 0.002 रेड/से से कम होनी चाहिए.
- g-सेंसिटिविटी, 0.1°/s/g से कम होनी चाहिए.
- डिवाइस के इस्तेमाल के लिए सेट किए गए तापमान की रेंज में, क्रॉस-ऐक्सिस की संवेदनशीलता < 4.0 % और क्रॉस-ऐक्सिस वैरिएशन < 0.3% होनी चाहिए.
[C-2-4] ज़रूरी है कि TYPE_GYROSCOPE_UNCALIBRATED और क्वालिटी की ज़रूरी शर्तें TYPE_GYROSCOPE जैसी ही हों.
[C-2-5] ऐसा TYPE_GEOMAGNETIC_FIELD सेंसर होना चाहिए जो:
- तापमान मापने की रेंज कम से कम -900 और +900 μT के बीच होनी चाहिए.
- रिज़ॉल्यूशन कम से कम 5 LSB/uT होना चाहिए.
- तापमान मापने की फ़्रीक्वेंसी कम से कम 5 हर्ट्ज़ या इससे कम होनी चाहिए.
- तापमान मापने की फ़्रीक्वेंसी ज़्यादा से ज़्यादा 50 हर्ट्ज़ या इससे ज़्यादा होनी चाहिए.
- तापमान मापने वाला नॉइज़ 0.5 uT से ज़्यादा नहीं होना चाहिए.
[C-2-6] ज़रूरी है कि TYPE_MAGNETIC_FIELD_UNCALIBRATED में क्वालिटी की ज़रूरी शर्तें TYPE_GEOMAGNETIC_FIELD जैसी हों. इसके अलावा:
- इस सेंसर को चालू करने का एक ऐसा तरीका लागू करना ज़रूरी है जिसमें कम से कम 600 सेंसर इवेंट की बफ़रिंग क्षमता हो.
- [C-SR-3] रिपोर्ट की दर 50 हर्ट्ज़ या इससे ज़्यादा होने पर, 1 हर्ट्ज़ से कम से कम 10 हर्ट्ज़ तक व्हाइट नॉइज़ स्पेक्ट्रम रखने की सलाह दी जाती है.
[C-2-7] ऐसा TYPE_PRESSURE सेंसर होना चाहिए जो:
- इसकी मेज़रमेंट रेंज कम से कम 300 से 1100 hPa के बीच होनी चाहिए.
- रिज़ॉल्यूशन कम से कम 80 LSB/hPa होना चाहिए.
- तापमान मापने की फ़्रीक्वेंसी कम से कम 1 हर्ट्ज़ या इससे कम होनी चाहिए.
- तापमान मापने की फ़्रीक्वेंसी ज़्यादा से ज़्यादा 10 हर्ट्ज़ या इससे ज़्यादा होनी चाहिए.
- तापमान मापने के लिए नॉइज़, 2 Pa/withHz से ज़्यादा नहीं होनी चाहिए.
- इस सेंसर को चालू करने का एक ऐसा तरीका लागू करना ज़रूरी है जिसमें कम से कम 300 सेंसर इवेंट की बफ़रिंग क्षमता हो.
- बैच में ऊर्जा की खपत दो मिलीवाट से कम नहीं होनी चाहिए.
[C-2-8] TYPE_GAME_ROTATION_VECTOR सेंसर होना चाहिए.
[C-2-9] ऐसा TYPE_SIGNIFICANT_MOTION सेंसर होना चाहिए जो:
- अगर डिवाइस स्टैटिक हो, तो उसमें ऊर्जा की खपत 0.5 मिलीवाट से ज़्यादा नहीं होनी चाहिए. वहीं, जब डिवाइस हिलता-डुलता हो, तो ऊर्जा की खपत 1.5 मिलीवाट से ज़्यादा नहीं होनी चाहिए.
[C-2-10] ऐसा TYPE_STEP_DETECTOR सेंसर होना चाहिए जो:
- इस सेंसर को चालू करने का एक ऐसा तरीका लागू करना ज़रूरी है जिसमें कम से कम 100 सेंसर इवेंट की बफ़रिंग क्षमता हो.
- अगर डिवाइस स्टैटिक हो, तो उसमें ऊर्जा की खपत 0.5 मिलीवाट से ज़्यादा नहीं होनी चाहिए. वहीं, जब डिवाइस हिलता-डुलता हो, तो ऊर्जा की खपत 1.5 मिलीवाट से ज़्यादा नहीं होनी चाहिए.
- बैच में ऊर्जा की खपत 4 मिलीवाट से कम नहीं होनी चाहिए.
[C-2-11] ऐसा TYPE_STEP_COUNTER सेंसर होना चाहिए जो:
- अगर डिवाइस स्टैटिक हो, तो उसमें ऊर्जा की खपत 0.5 मिलीवाट से ज़्यादा नहीं होनी चाहिए. वहीं, जब डिवाइस हिलता-डुलता हो, तो ऊर्जा की खपत 1.5 मिलीवाट से ज़्यादा नहीं होनी चाहिए.
[C-2-12] ऐसा TILT_DETECTOR सेंसर होना चाहिए जो:
- अगर डिवाइस स्टैटिक हो, तो उसमें ऊर्जा की खपत 0.5 मिलीवाट से ज़्यादा नहीं होनी चाहिए. वहीं, जब डिवाइस हिलता-डुलता हो, तो ऊर्जा की खपत 1.5 मिलीवाट से ज़्यादा नहीं होनी चाहिए.
[C-2-13] एक ही शारीरिक गतिविधि के इवेंट का टाइमस्टैंप, एक्सीलरोमीटर, जाइरोस्कोप, और मैग्नेटोमीटर की मदद से एक-दूसरे से 2.5 मिलीसेकंड के अंदर होना चाहिए. एक्सलरोमीटर और जाइरोस्कोप से रिपोर्ट की गई, एक ही असल इवेंट का इवेंट टाइमस्टैंप एक-दूसरे से 0.25 मिलीसेकंड के अंदर होना चाहिए.
[C-2-14] जाइरोस्कोप सेंसर के इवेंट टाइमस्टैंप, कैमरा सबसिस्टम के टाइम बेस पर और गड़बड़ी होने पर एक मिलीसेकंड के अंदर होने चाहिए.
[C-2-15] ऐप्लिकेशन के लिए ऊपर दिए गए किसी भी फ़िज़िकल सेंसर पर डेटा उपलब्ध होने से 5 मिलीसेकंड के अंदर ऐप्लिकेशन को सैंपल देना ज़रूरी है.
[C-2-16] डिवाइस के स्टैटिक होने पर 0.5 mW से ज़्यादा बिजली की खपत नहीं होनी चाहिए. वहीं, नीचे दिए गए सेंसर का कोई भी कॉम्बिनेशन चालू होने पर 2.0 mW से ज़्यादा बिजली की खपत नहीं होनी चाहिए:
- SENSOR_TYPE_SIGNIFICANT_MOTION
- SENSOR_TYPE_STEP_DETECTOR
- SENSOR_TYPE_STEP_COUNTER
- SENSOR_TILT_DETECTORS
[C-2-17] इसमें TYPE_PROXIMITY सेंसर हो सकता है. हालांकि, अगर मौजूद है, तो कम से कम 100 सेंसर इवेंट की बफ़र क्षमता होना ज़रूरी है.

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

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

[C-3-1] isDirectChannelTypeSupported और getHighestDirectReportRateLevel एपीआई की मदद से, डायरेक्ट चैनल टाइप और डायरेक्ट रिपोर्ट की दरों के साथ काम करने की सही जानकारी देना ज़रूरी है.
[C-3-2] सेंसर डायरेक्ट चैनल के साथ काम करने वाले सभी सेंसर के लिए, दो तरह के सेंसर में से कम से कम एक को काम करना ज़रूरी है.
- TYPE_HARDWARE_BUFFER
- TYPE_MEMORY_FILE
इस तरह के प्राइमरी सेंसर (नॉन-वेकअप वैरिएंट) के लिए, सेंसर डायरेक्ट चैनल से इवेंट की रिपोर्टिंग की सुविधा काम करनी चाहिए:
- TYPE_ACCELEROMETER
- TYPE_ACCELEROMETER_UNCALIBRATED
- TYPE_GYROSCOPE
- TYPE_GYROSCOPE_UNCALIBRATED
- TYPE_MAGNETIC_FIELD
- TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. बायोमेट्रिक सेंसर

बायोमेट्रिक अनलॉक की सुरक्षा को मापने के बारे में ज़्यादा जानने के लिए, कृपया बायोमेट्रिक सुरक्षा को मेज़र करने से जुड़ा दस्तावेज़ देखें.

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

इसमें बायोमेट्रिक सेंसर शामिल होना चाहिए

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

अगर डिवाइस लागू करने की सुविधा से, तीसरे पक्ष के ऐप्लिकेशन में android.hardware.biometric.BiometricManager, android.hardware.biometric.BiometricPrompt, और android.provider.Settings.ACTION_BIOMETRIC_ENROLL की मदद से, इनसे तीसरे पक्ष के ऐप्लिकेशन को बायोमेट्रिक सेंसर उपलब्ध कराया जाता है, तो:

[C-4-1] इस दस्तावेज़ में दी गई क्लास 3 या क्लास 2 बायोमेट्रिक की ज़रूरी शर्तों को पूरा करना ज़रूरी है.
[C-4-2] Authenticator क्लास और उसके किसी भी कॉम्बिनेशन में, एक कंस्टेंट के तौर पर बताए गए हर पैरामीटर के नाम को पहचानना और उसके हिसाब से काम करना ज़रूरी है. इसके उलट, canAuthenticate(int) और setAllowedAuthenticators(int) के अलावा, किसी और तरीके से पास नहीं किए गए पूर्णांक कॉन्सटेंट को मानना या उनकी पहचान करना ज़रूरी नहीं है जिन्हें Authenticator और उनके किसी कॉम्बिनेशन में, पब्लिक कॉन्सटेंट के तौर पर दर्ज किया गया हो.
[C-4-3] उन डिवाइसों पर ACTION_BIOMETRIC_ENROLL कार्रवाई लागू करनी होगी जिनमें क्लास 3 या क्लास 2 बायोमेट्रिक्स शामिल हैं. इस कार्रवाई में सिर्फ़ क्लास 3 या क्लास 2 बायोमेट्रिक्स के लिए, रजिस्ट्रेशन के एंट्री पॉइंट मौजूद होने चाहिए.

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

[C-5-1] पुष्टि करने के लिए डिफ़ॉल्ट रूप से एक और चरण पूरा करना ज़रूरी है (जैसे, बटन दबाना).
[C-SR-1] उपयोगकर्ताओं को ऐसी सेटिंग चुनने का सुझाव दिया जाता है जिससे वे ऐप्लिकेशन की सेटिंग में बदलाव कर सकें. साथ ही, हमेशा पुष्टि करने से जुड़ा चरण पूरा करना ज़रूरी है.
[C-SR-2] की पुष्टि करने की कार्रवाई को सुरक्षित रखने के लिए इस बात का खास तौर पर सुझाव दिया जाता है कि किसी ऑपरेटिंग सिस्टम या कर्नेल से छेड़छाड़ को स्पूफ़ नहीं किया जा सकता. उदाहरण के लिए, इसका मतलब है कि फ़िज़िकल बटन पर आधारित 'पुष्टि करें' कार्रवाई को ऐसे सुरक्षित एलिमेंट (एसई) के सिर्फ़ इनपुट वाले इनपुट/आउटपुट (GPIO) पिन के ज़रिए रूट किया जाता है जिसे बटन दबाने के बजाय, किसी और तरीके से चलाया नहीं जा सकता.
[C-5-2] आपको setConfirmation required(बूलियन) के हिसाब से, इंप्लिसिट ऑथेंटिकेशन फ़्लो को लागू करना होगा(पुष्टि करने वाले चरण के बिना).

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

[C-SR-3] पुष्टि करते समय सिर्फ़ एक बायोमेट्रिक की पुष्टि करनी ज़रूरी है. उदाहरण के लिए, अगर डिवाइस पर फ़िंगरप्रिंट और फ़ेस सेंसर, दोनों उपलब्ध हैं, तो इनमें से किसी भी एक की पुष्टि होने के बाद onAuthenticationSucceed भेजा जाना चाहिए.

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

[C-6-1] क्लास 3 की ज़रूरी शर्तों को पूरा करना ज़रूरी है. इन शर्तों के बारे में नीचे बताया गया है.
[C-6-2] सिर्फ़ क्लास 3 के बायोमेट्रिक्स तब ही दिखाए जाने चाहिए, जब पुष्टि करने के लिए BIOMETRIC_STRONG की ज़रूरत हो या पुष्टि करने की प्रक्रिया किसी क्रिप्टोऑब्जेक्ट की मदद से शुरू की गई हो.

अगर डिवाइस लागू करने के तरीके में बायोमेट्रिक सेंसर को क्लास 1 (पहले इसे सुविधा कहा जाता था) के तौर पर इस्तेमाल करना हो, तो वे:

[C-1-1] गलतफ़हमी की दर 0.002% से कम होनी चाहिए.
[C-1-2] यह बताना ज़रूरी है कि यह मोड, एक मज़बूत पिन, पैटर्न या पासवर्ड के मुकाबले कम सुरक्षित हो सकता है. साथ ही, अगर Android बायोमेट्रिक्स टेस्ट प्रोटोकॉल के मुताबिक, झूठे नाम से मेल भेजने और दिखाने की अनुमति देने की दर 7% से ज़्यादा है, तो इसे चालू करने के जोखिमों के बारे में साफ़ तौर पर बताना ज़रूरी है.
[C-1-9] बायोमेट्रिक वेरिफ़िकेशन के लिए, 20 से ज़्यादा गलत टेस्ट और नब्बे सेकंड बैकऑफ़ समय के बाद, सुझाए गए मुख्य पुष्टि (जैसे कि पिन, पैटर्न, पासवर्ड) के लिए उपयोगकर्ता को चुनौती देनी होगी. यहां गलत ट्रायल का मतलब है अच्छी कैप्चर क्वालिटी (BIOMETRIC_ACQUIRED_GOOD) जो रजिस्टर किए गए बायोमेट्रिक से मेल नहीं खाता.
[C-SR-4] का सुझाव दिया जाता है कि [C-1-9] में बायोमेट्रिक तरीके से पुष्टि करने के लिए, फ़ॉल्स ट्रायल की कुल संख्या को कम किया जाए. ऐसा तब किया जाता है, जब Android बायोमेट्रिक्स टेस्ट प्रोटोकॉल के मुताबिक, स्पूफ़ और इंपोस्टर स्वीकार करने की दर 7% से ज़्यादा हो.
[C-1-3] बायोमेट्रिक वेरिफ़िकेशन के लिए, इस बात की सीमा तय होनी चाहिए कि इस सुविधा का इस्तेमाल तभी किया जा सकता है, जब गलत एक्सपेरिमेंट का मतलब है कि सही क्वालिटी में कैप्चर की गई क्वालिटी (BIOMETRIC_ACQUIRED_GOOD) हो और वह रजिस्टर किए गए बायोमेट्रिक्स से मेल न खाती हो.
[C-SR-5] बायोमेट्रिक वेरिफ़िकेशन के लिए, पांच गलत ट्रायल के बाद, कम से कम 30 सेकंड बाद इस पर रोक लगाने की बहुत ज़्यादा सलाह दी जाती है. इससे हर [C-1-9] के लिए फ़ॉल्स ट्रायल की ज़्यादा से ज़्यादा संख्या को सेट किया जा सकता है - जहां फ़ॉल्स ट्रायल का मतलब है अच्छी कैप्चर क्वालिटी (BIOMETRIC_ACQUIRED_GOOD) की, जो बायोमेट्रिक रजिस्टर की गई किसी संख्या से मेल नहीं खाती.
[C-SR-6] टीईई में रेट को सीमित करने वाले सभी लॉजिक का इस्तेमाल करने के लिए इस बात का खास तौर पर सुझाव दिया जाता है.
[C-1-10] प्राइमरी ऑथेंटिकेशन बैकऑफ़ पहली बार ट्रिगर होने पर, बायोमेट्रिक्स को बंद करना ज़रूरी है. इसके बारे में सेक्शन 9.11 के [C-0-2] में बताया गया है.
[C-1-11] स्पूफ़ और इंपोस्टर के स्वीकार किए जाने की दर 30% से ज़्यादा नहीं होनी चाहिए. इसमें (1) लेवल ए प्रज़ेंटेशन अटैक इंस्ट्रुमेंट (पीएआई) की प्रजातियों के लिए स्पूफ़ और इंपोस्टर स्वीकार रेट 30% से ज़्यादा नहीं होना चाहिए. साथ ही, (2) लेवल B PAI की पहचान की दर 40% से ज़्यादा नहीं होनी चाहिए.
[C-1-4] उपयोगकर्ता से मौजूदा पुष्टि की पुष्टि कराए बिना या टीईई के सुरक्षित किए गए नए डिवाइस क्रेडेंशियल (पिन/पैटर्न/पासवर्ड) को जोड़कर, नए बायोमेट्रिक्स जोड़ने से रोकना ज़रूरी है. Android ओपन सोर्स प्रोजेक्ट को लागू करने से, ऐसा करने के लिए फ़्रेमवर्क में प्रोसेस होती है.
[C-1-5] उपयोगकर्ता का खाता हटाए जाने पर (इसमें फ़ैक्ट्री रीसेट करना भी शामिल है) उस व्यक्ति की पहचान से जुड़े सभी बायोमेट्रिक डेटा को पूरी तरह से हटा देना चाहिए.
[C-1-6] उस बायोमेट्रिक के लिए, हर झंडे का पालन करना ज़रूरी है (जैसे, DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT, DevicePolicymanager.KEYGUARD_DISABLE_FACE या DevicePolicymanager.KEYGUARD_DISABLE_IRIS ).
[C-1-7] हर 24 घंटे में एक बार या इससे कम समय में, सुझाई गई मुख्य पुष्टि (जैसे- पिन, पैटर्न, पासवर्ड) के लिए, उपयोगकर्ता से संपर्क करना ज़रूरी है. ध्यान दें: Android 9 या इससे पहले के वर्शन पर लॉन्च किए गए डिवाइसों को अपग्रेड करने के लिए, उपयोगकर्ता को हर 72 घंटे या उससे कम समय में, एक बार पुष्टि करने के लिए सुझाए गए मुख्य तरीके (जैसे, पिन, पैटर्न, पासवर्ड) का ऐक्सेस देना ज़रूरी है.
[C-1-8] आपको इनमें से किसी एक के बाद, सुझाई गई मुख्य पहचान (जैसे: पिन, पैटर्न, पासवर्ड) या क्लास 3 (स्ट्रॉन्ग) बायोमेट्रिक के लिए उपयोगकर्ता को चैलेंज देना होगा:
- चार घंटे तक इस्तेमाल न होने पर, टाइम आउट की अवधि या
- बायोमेट्रिक तरीके से पुष्टि करने की तीन कोशिशें सफल नहीं रहीं.
- डिवाइस के क्रेडेंशियल की पुष्टि होने के बाद, इस्तेमाल न होने पर टाइम आउट की अवधि और पुष्टि न हो पाने की संख्या को रीसेट कर दिया जाता है. ध्यान दें: Android 9 या इससे पहले के वर्शन पर लॉन्च किए गए डिवाइसों को अपग्रेड करने पर, उन्हें C-1-8 से छूट दी जा सकती है.
[C-SR-7] को नए डिवाइसों के लिए [C-1-7] और [C-1-8] में बताई गई शर्तों को लागू करने के लिए, Android ओपन सोर्स प्रोजेक्ट के फ़्रेमवर्क में दिए गए तर्क का इस्तेमाल करने की सलाह दी जाती है.
[C-SR-8] इस बात का बहुत ज़्यादा सुझाव दिया जाता है कि डिवाइस के आकलन के हिसाब से, अस्वीकार किए जाने की दर 10% से कम हो.
[C-SR-9] हमारा सुझाव है कि पुष्टि होने का समय एक सेकंड से कम रखें. यह काम, बायोमेट्रिक की पहचान होने के बाद स्क्रीन अनलॉक करने तक किया जाता है. ऐसा, रजिस्टर किए गए हर बायोमेट्रिक के लिए किया जाता है.

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

[C-2-1] क्लास 1 के लिए ऊपर दी गई सभी ज़रूरी शर्तों को पूरा करना ज़रूरी है.
[C-2-2] स्पूफ़ और इंपोस्टर के स्वीकार करने की दर 20% से ज़्यादा नहीं होनी चाहिए. इसमें (1) लेवल ए प्रज़ेंटेशन अटैक इंस्ट्रुमेंट (पीएआई) की प्रजातियों के लिए स्पूफ़ और इंपोस्टर स्वीकार रेट 20% से ज़्यादा नहीं होना चाहिए. (2) स्पूफ़ और इंपोस्टर स्वीकार करने की दर 30% से ज़्यादा नहीं होनी चाहिए.
[C-2-3] Android उपयोगकर्ता या कर्नेल स्पेस जैसे कि ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट (टीईई) के बाहर एक आइसोलेटेड एक्ज़ीक्यूशन एनवायरमेंट (टीईई) में बायोमेट्रिक मैचिंग करना ज़रूरी है. इसके अलावा, आइसोलेटेड एक्ज़ीक्यूशन एनवायरमेंट में, सुरक्षित चैनल वाली चिप पर भी बायोमेट्रिक मैचिंग की जा सकती है.
[C-2-4] सभी की पहचान ज़ाहिर करने वाले डेटा को एन्क्रिप्ट (सुरक्षित) और क्रिप्टोग्राफ़िक तरीके से प्रमाणित करना ज़रूरी है ताकि उन्हें अलग-अलग एक्ज़ीक्यूशन एनवायरमेंट के बाहर न तो हासिल किया जा सके और न ही पढ़ा जा सके या उनमें बदलाव न किया जा सके. साथ ही, Android ओपन सोर्स प्रोजेक्ट की साइट पर लागू करने से जुड़े दिशा-निर्देशों के मुताबिक, अलग-अलग एक्ज़ीक्यूशन एनवायरमेंट के लिए एक सुरक्षित चैनल वाला चिप भी होना चाहिए.
[C-2-5] कैमरे के लिए बायोमेट्रिक्स के लिए, जबकि बायोमेट्रिक के आधार पर पुष्टि या रजिस्टर करने की प्रोसेस जारी है:
- कैमरे को ऐसे मोड में ऑपरेट करना चाहिए जिसमें अलग से एक्ज़ीक्यूशन एनवायरमेंट के बाहर, कैमरे के फ़्रेम को पढ़ा न जा सके या उनमें बदलाव न किया जा सके. इसके अलावा, आइसोलेटेड एक्ज़ीक्यूशन एनवायरमेंट में, सुरक्षित चैनल वाली चिप को पढ़ने से रोका जा सकता है.
- आरजीबी सिंगल-कैमरा सलूशन के लिए, अलग-अलग एक्ज़ीक्यूशन एनवायरमेंट के बाहर भी कैमरे के फ़्रेम ऐक्सेस किए जा सकते हैं. इससे रजिस्ट्रेशन करने जैसे काम करने में मदद मिलती है. हालांकि, इनमें बदलाव नहीं किया जा सकता.
[C-2-6] हर बायोमेट्रिक रजिस्ट्रेशन के बीच अंतर करने के लिए, तीसरे पक्ष के ऐप्लिकेशन को चालू नहीं किया जाना चाहिए.
[C-2-7] को पहचान ज़ाहिर करने वाले बायोमेट्रिक डेटा या इससे मिले किसी भी डेटा (जैसे कि एम्बेड करना) को टीईई के संदर्भ से बाहर ऐप्लिकेशन प्रोसेसर में ऐक्सेस करने की अनुमति नहीं देनी चाहिए. Android 9 या इससे पहले के वर्शन पर लॉन्च किए गए डिवाइसों को अपग्रेड करने पर, C-2-7 पर कोई छूट नहीं दी गई है.
[C-2-8] ज़रूरी है कि आपके पास एक सुरक्षित प्रोसेसिंग पाइपलाइन हो, जिससे किसी ऑपरेटिंग सिस्टम या कर्नेल छेड़छाड़ से उपयोगकर्ता के रूप में गलत तरीके से पुष्टि करने के लिए डेटा को सीधे इंजेक्ट न किया जा सके. ध्यान दें: अगर डिवाइस पर लागू किए जाने वाले डिवाइस, Android 9 या इससे पहले के वर्शन पर पहले ही लॉन्च किए गए हैं और सिस्टम सॉफ़्टवेयर अपडेट के ज़रिए, C-2-8 की ज़रूरी शर्तों को पूरा नहीं किया जा सकता है, तो उन्हें इस ज़रूरी शर्त से छूट दी जा सकती है.
[C-SR-10] का सुझाव दिया जाता है कि फ़ेस बायोमेट्रिक्स के लिए, बायोमेट्रिक तरीके से काम करने में होने वाली दिक्कतों और अटेंशन डिटेक्शन को शामिल करना ज़रूरी है.
[C-2-9] तीसरे पक्ष के ऐप्लिकेशन के लिए, बायोमेट्रिक सेंसर उपलब्ध कराना ज़रूरी है.

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

[C-3-1] [C-1-7] और [C-1-8] को छोड़कर, ऊपर दी गई क्लास 2 की सभी ज़रूरी शर्तें पूरी करना ज़रूरी है.
[C-3-2] ज़रूरी है कि इसमें हार्डवेयर-बैक्ड कीस्टोर लागू किया गया हो.
[C-3-3] स्पूफ़ और इंपोस्टर के स्वीकार करने की दर 7% से ज़्यादा नहीं होनी चाहिए. इसमें (1) लेवल ए प्रेज़ेंटेशन अटैक इंस्ट्रुमेंट (पीएआई) की ऐसी प्रजातियों के लिए स्पूफ़ और इंपोस्टर स्वीकार करने की दर होनी चाहिए जो 7% से ज़्यादा न हों. (2) लेवल बी पीएआई की प्रजातियों के स्पूफ़ और इंपोस्टर को स्वीकार करने की दर 20% से ज़्यादा नहीं होनी चाहिए. प्रोटोकॉलAndroid बायोमेट्रिक्स के मुताबिक, यह 20% से ज़्यादा है.
[C-3-4] हर 72 घंटे में एक बार या इससे कम के लिए, सुझाई गई मुख्य पुष्टि के लिए उपयोगकर्ता को चैलेंज देना ज़रूरी है.
[C-3-5] डिवाइस पर काम करने वाले सभी क्लास 3 बायोमेट्रिक्स के लिए, Authenticator आईडी फिर से जनरेट करना होगा. ऐसा तब ही करना होगा, जब डिवाइसों पर इनमें से किसी का नाम फिर से रजिस्टर किया गया हो.
[C-3-6] तीसरे पक्ष के ऐप्लिकेशन के लिए, बायोमेट्रिक-बैक्ड कीस्टोर बटन चालू करना ज़रूरी है.

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

[C-SR-11] का खास तौर पर सुझाव दिया जाता है, ताकि UDFPS की छुई जा सकने वाली जगह को 3 बटन वाले नेविगेशन में रुकावट डालने से रोका जा सके( ऐसा कुछ उपयोगकर्ताओं को सुलभता सुविधाओं के लिए ज़रूरी हो सकता है).

7.3.11. पोज़ सेंसर

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

इसमें 6 डिग्री फ़्रीडम सेंसर हो सकता है.

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

[C-1-1] TYPE_POSE_6DOF सेंसर को लागू करना और इसकी रिपोर्ट करना ज़रूरी है.
[C-1-2] सिर्फ़ रोटेशन वेक्टर की तुलना में ज़्यादा सटीक होना चाहिए.

7.3.12. हिंज ऐंगल सेंसर

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

[C-1-1] TYPE_HINGLE_ANGLE को लागू करना और इसकी रिपोर्ट करना ज़रूरी है.
[C-1-2] ज़रूरी है कि 0 से 360 डिग्री के बीच की कम से कम दो रीडिंग दिखाई जा सकें (इसमें 0 और 360 डिग्री शामिल हैं).
[C-1-3] getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE) के लिए वेकअप सेंसर दिखाना ज़रूरी है.

7.3.13. IEEE 802.1.15.4 [7.4.9 पर ले जाया गया]

7.4. डेटा कनेक्टिविटी

7.4.1. टेलीफ़ोनी

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

Android का इस्तेमाल उन डिवाइसों पर किया जा सकता है जिनमें टेलीफ़ोनी हार्डवेयर शामिल नहीं है. इसका मतलब है कि Android उन डिवाइसों पर काम करता है जो फ़ोन नहीं हैं.

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

[C-1-1] टेक्नोलॉजी के मुताबिक, android.hardware.telephony फ़ीचर फ़्लैग और अन्य सब-फ़ीचर फ़्लैग के बारे में बताना ज़रूरी है.
[C-1-2] इस टेक्नोलॉजी के लिए, एपीआई को पूरी तरह से सपोर्ट करना ज़रूरी है.
आपको आपातकालीन कॉल के दौरान, सभी उपलब्ध सेल्युलर सेवा प्रकारों (2G, 3G, 4G, 5G वगैरह) को अनुमति देनी चाहिए (भले ही, SetAllowedNetworkTypeBitmap() ने कोई भी नेटवर्क सेट किया हो).

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

[C-2-1] सभी एपीआई को नो-ऑपरेशन के तौर पर लागू करना ज़रूरी है.

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

[C-3-1] android.hardware.telephony.euicc फ़ीचर फ़्लैग के बारे में बताना ज़रूरी है.

अगर लागू किए गए डिवाइस पर, सिस्टम प्रॉपर्टी ro.telephony.iwlan\_operation\_mode को 'लेगसी' पर सेट नहीं किया जाता, तो ये:

[C-4-1] जब Networkआपका तय किया गया चैनल

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

[C-5-1] android.hardware.telephony.ims फ़ीचर फ़्लैग के बारे में बताना ज़रूरी है. साथ ही, MMTEL और आरसीएस यूज़र कैपेबिलिटी एक्सचेंज एपीआई, दोनों के लिए ImsService API को पूरी तरह लागू करना होगा.
[C-5-2] आपको android.hardware.telephony.ims.singlereg फ़ीचर फ़्लैग की जानकारी देनी होगी. साथ ही, SipTransport API, GbaService API, IRadio 1.6 एचएएल का इस्तेमाल करके तय किए गए बेयरर संकेतों को पूरी तरह लागू करने की जानकारी देनी होगी. साथ ही, IMS कॉन्फ़िगरेशन API का इस्तेमाल करके, ऑटो कॉन्फ़िगरेशन सर्वर (ACS) या मालिकाना हक वाले अन्य प्रावधान करने के तरीकों की जानकारी देनी होगी.

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

[C-6-1] टेक्स्ट मैसेज की सुविधा देने के लिए, SmsManager#sendTextMessage और SmsManager#sendMultipartTextMessage CarrierMessagingService को कॉल करना ज़रूरी है. SmsManager#sendMultimediaMessage और SmsManager#downloadMultimediaMessage मल्टीमीडिया मैसेज की सुविधा देने के लिए, CarrierMessagingService को कॉल करना ज़रूरी है.
[C-6-2] android.provider.Telephony.Sms#getDefaultSmsPackage की ओर से तय किए गए ऐप्लिकेशन को एसएमएस और मल्टीमीडिया मैसेज (एमएमएस) भेजते और पाते समय SmsManager एपीआई का इस्तेमाल करना होगा. पैकेज/ऐप्लिकेशन/मैसेजिंग में एओएसपी रेफ़रंस लागू करने की सुविधा, इस ज़रूरी शर्त को पूरा करती है.
[C-6-3] Intent#ACTION_DIAL का जवाब देने वाले ऐप्लिकेशन के लिए, *#*#CODE#*#* फ़ॉर्मैट में आर्बिट्रेरी डायलर कोड डालने की सुविधा होनी ज़रूरी है. साथ ही, उससे जुड़े TelephonyManager#ACTION_SECRET_CODE का ब्रॉडकास्ट भी ट्रिगर होना चाहिए.
[C-6-4] Intent#ACTION_DIAL का जवाब देने वाले ऐप्लिकेशन को उपयोगकर्ताओं को विज़ुअल वॉइसमेल ट्रांसक्रिप्शन देने के लिए VoicemailContract.Voicemails#TRANSCRIPTION का इस्तेमाल करना होगा. इसके लिए ज़रूरी है कि ऐप्लिकेशन विज़ुअल वॉइसमेल ट्रांसक्रिप्शन की सुविधा देता हो.
[C-6-5] उपयोगकर्ताओं को दिखने वाली सभी सुविधाओं में, एक ही सदस्यता के तौर पर ग्रुप यूयूआईडी वाली सभी SubscriptionInfo को दिखाना ज़रूरी है. ये सुविधाएं सिम कार्ड की जानकारी दिखाने और कंट्रोल करने में मददगार होती हैं. इस तरह की सुविधाओं के उदाहरणों में, Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS या EuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS से मेल खाने वाले सेटिंग इंटरफ़ेस शामिल हैं.
[C-6-6] सिम कार्ड की सेटिंग को कॉन्फ़िगर या कंट्रोल करने की अनुमति देने वाली सुविधाओं में, सदस्यता की जानकारी को ऐसे ग्रुप यूयूआईडी और ऑपर्च्यूनिस्टिक बिट के साथ दिखाना या कंट्रोल नहीं करना चाहिए.

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

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

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

[C-6-7] यह ज़रूरी है कि वह हर ईटीएसआई टीएस 102 221 के लिए, हर यूआईसीसी के लिए ज़्यादा से ज़्यादा लॉजिकल चैनलों (कुल 20) को खोलने और एक साथ इस्तेमाल करने की सुविधा दे.
[C-6-8] मोबाइल और इंटरनेट सेवा देने वाली चालू कंपनी के ऐप्लिकेशन (जैसा कि TelephonyManager#getCarrierServicePackageName ने तय किया है) पर इनमें से कोई भी व्यवहार अपने-आप या उपयोगकर्ता की पुष्टि के बिना लागू नहीं करना चाहिए:
- नेटवर्क ऐक्सेस रद्द करना या उसे सीमित करना
- अनुमतियां वापस लें
- एओएसपी में शामिल पावर मैनेजमेंट की मौजूदा सुविधाओं के अलावा, बैकग्राउंड या फ़ोरग्राउंड ऐप्लिकेशन को एक्ज़ीक्यूट करने पर पाबंदी लगाएं
- ऐप्लिकेशन को बंद या अनइंस्टॉल करें

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

[C-8-1] एक ही ग्रुप में बची हुई सभी ऑपर्च्यूनिटी सदस्यताओं को अपने-आप बंद करना ज़रूरी है.

अगर लागू किए जाने वाले डिवाइसों में GSM टेलीफ़ोनी शामिल है, लेकिन CDMA टेलीफ़ोनी नहीं, तो वे:

[C-9-1] PackageManager#FEATURE_TELEPHONY_CDMA के बारे में एलान नहीं करना चाहिए.
[C-9-2] किसी भी 3GPP2 नेटवर्क को, पसंदीदा या अनुमति वाले नेटवर्क टाइप बिटमास्क में सेट करने पर, आपको IllegalArgumentException का इस्तेमाल करना होगा.
[C-9-3] TelephonyManager#getMeid से मिली खाली स्ट्रिंग देनी होगी.

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

[C-10-1] android.hardware.telephony.euicc.mep फ़ीचर फ़्लैग के बारे में बताना ज़रूरी है.

7.4.1.1. नंबर ब्लॉक करने की सुविधा के साथ काम करना

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

[C-1-1] नंबर ब्लॉक करने की सुविधा शामिल होनी चाहिए
[C-1-2] BlockedNumberContract और इससे जुड़े एपीआई को पूरी तरह से लागू करना ज़रूरी है. SDK टूल के दस्तावेज़ में बताया गया है.
[C-1-3] आपको 'BlockNumberProvider' पर मौजूद फ़ोन नंबर से आने वाले सभी कॉल और मैसेज को ब्लॉक करना होगा. ऐसा करने के लिए, ऐप्लिकेशन से कोई इंटरैक्शन नहीं करना होगा. इसमें सिर्फ़ तब अपवाद हो सकता है, जब नंबर ब्लॉक करने की सुविधा को कुछ समय के लिए हटा दिया जाए, जैसा कि SDK टूल के दस्तावेज़ में बताया गया है.
[C-1-4] ब्लॉक किए गए कॉल के लिए, प्लैटफ़ॉर्म कॉल लॉग की सेवा देने वाली कंपनी को जवाब देना होगा. साथ ही, पहले से इंस्टॉल किए गए डायलर ऐप्लिकेशन में, डिफ़ॉल्ट कॉल लॉग व्यू में से BLOCKED_TYPE का इस्तेमाल करके, कॉल को फ़िल्टर करना ज़रूरी है.
[C-1-5] ब्लॉक किए गए मैसेज के लिए, Telephony की सेवाएं देने वाली कंपनी को पत्र नहीं लिखना चाहिए.
[C-1-6] ब्लॉक किए गए नंबर मैनेज करने के यूज़र इंटरफ़ेस (यूआई) को लागू करना ज़रूरी है. यह यूज़र इंटरफ़ेस (यूआई) इस यूज़र इंटरफ़ेस (यूआई) से खोला जाता है. इस यूज़र इंटरफ़ेस (यूआई) को, TelecomManager.createManageBlockedNumbersIntent() तरीके से दिखाए गए इंटेंट के साथ खोला जाता है.
[C-1-7] सेकंडरी उपयोगकर्ताओं को डिवाइस पर ब्लॉक किए गए नंबर देखने या उनमें बदलाव करने की अनुमति नहीं देनी चाहिए. ऐसा इसलिए, क्योंकि Android प्लैटफ़ॉर्म यह मानता है कि मुख्य उपयोगकर्ता के पास डिवाइस पर, टेलीफ़ोनी सेवा का पूरा कंट्रोल होगा. सेकंडरी उपयोगकर्ताओं के लिए, ब्लॉक करने से जुड़े सभी यूज़र इंटरफ़ेस (यूआई) छिपाए जाने चाहिए और ब्लॉक की गई सूची को अब भी लागू किया जाना चाहिए.
जब कोई डिवाइस Android 7.0 पर अपडेट होगा, तो ब्लॉक किए गए नंबरों को सेवा देने वाली कंपनी में माइग्रेट कर देना चाहिए.
उपयोगकर्ता को, पहले से इंस्टॉल किए गए डायलर ऐप्लिकेशन में, ब्लॉक किए गए कॉल दिखाने की सुविधा देनी चाहिए.

7.4.1.2. टेलीकॉम एपीआई

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

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

एओएसपी को लागू करने के लिए, आपको चेतावनी दी जाती है. इससे उपयोगकर्ता को पता चलता है कि इनकमिंग कॉल का जवाब देने से दूसरा कॉल हट जाएगा.
[C-SR-2] डिफ़ॉल्ट डायलर ऐप्लिकेशन को पहले से लोड करने का सुझाव दिया जाता है. यह कॉल लॉग एंट्री और तीसरे पक्ष के ऐप्लिकेशन का नाम तब दिखाता है, जब तीसरे पक्ष का ऐप्लिकेशन अपने PhoneAccount पर EXTRA_LOG_SELF_MANAGED_CALLS अतिरिक्त कुंजी को PhoneAccount पर सेट करता है.true
[C-SR-3] हमारा सुझाव है कि आप ऑडियो हेडसेट के KEYCODE_MEDIA_PLAY_PAUSE और KEYCODE_HEADSETHOOK इवेंट को android.telecom एपीआई के लिए, नीचे बताए गए तरीके से मैनेज करें:
- किसी चल रही कॉल के दौरान, मुख्य इवेंट को थोड़ी देर दबाने पर Connection.onDisconnect() को कॉल करें.
- जब किसी इनकमिंग कॉल के दौरान मुख्य इवेंट को थोड़ी देर दबाएं, तब Connection.onAnswer() को कॉल करें.
- जब किसी इनकमिंग कॉल के दौरान मुख्य इवेंट को दबाकर रखने का पता चलता है, तब Connection.onReject() को कॉल करें.
- CallAudioState की म्यूट स्थिति को टॉगल करें.

7.4.1.3. सेल्युलर NAT-T कीपअलाइव ऑफ़लोड

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

इसमें सेल्युलर कीपअलाइव ऑफ़लोड के लिए सहायता शामिल होनी चाहिए.

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

[C-1-1] SocketKeepAlive API के साथ काम करना ज़रूरी है.
[C-1-2] मोबाइल डेटा पर, एक साथ कम से कम एक कीपअलाइव (चालू रखें) स्लॉट का इस्तेमाल करना ज़रूरी है.
[C-1-3] Cellular Radio HAL के साथ काम करने वाले एक साथ कई सेल्युलर कीपअलाइव स्लॉट की सुविधा ज़रूरी है.
[C-SR-1] इस बात का सुझाव दिया जाता है कि हर रेडियो इंस्टेंस पर कम से कम तीन सेल्युलर कीपअलाइव स्लॉट का इस्तेमाल किया जा सके.

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

[C-2-1] ERROR_UNSUPPORTED वापस करना होगा.

7.4.2. आईईईई 802.11 (वाई-फ़ाई)

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

इसमें 802.11 के एक या उससे ज़्यादा फ़ॉर्म के लिए सहायता शामिल होनी चाहिए.

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

[C-1-1] संबंधित Android API को लागू करना ज़रूरी है.
[C-1-2] हार्डवेयर फ़ीचर फ़्लैग android.hardware.wifi की रिपोर्ट करना ज़रूरी है.
[C-1-3] SDK टूल के दस्तावेज़ में बताया गया तरीका अपनाकर, multicast API को लागू करना ज़रूरी है.
[C-1-4] ज़रूरी है कि किसी भी समय मल्टीकास्ट डीएनएस (एमडीएनएस) के साथ काम किया जाए और mडीएनएस पैकेट (224.0.0.251) को फ़िल्टर न किया जाए. इनमें ये शामिल हैं:
- भले ही, स्क्रीन ऐक्टिव न हो.
- स्टैंडबाय पावर की स्थिति में होने पर भी, Android Television डिवाइस पर लागू करने के लिए.
[C-1-5] WifiManager.enableNetwork() एपीआई तरीके से किए गए कॉल को, मौजूदा चालू Network को स्विच करने के लिए ज़रूरी संकेत के तौर पर नहीं मानना चाहिए. इस कॉल को ऐप्लिकेशन ट्रैफ़िक के लिए डिफ़ॉल्ट रूप से इस्तेमाल किया जाता है और इसे ConnectivityManager एपीआई के तरीकों, जैसे कि getActiveNetwork और registerDefaultNetworkCallback से दिखाया जाता है. दूसरे शब्दों में, वे नेटवर्क की सेवा देने वाली किसी दूसरी कंपनी (जैसे कि मोबाइल डेटा) से मिली इंटरनेट ऐक्सेस को सिर्फ़ तब बंद कर सकते हैं, जब वे यह पुष्टि कर लें कि वाई-फ़ाई नेटवर्क, इंटरनेट ऐक्सेस दे रहा है.
[C-1-6] ConnectivityManager.reportNetworkConnectivity() एपीआई तरीके को कॉल करने पर, Network पर इंटरनेट ऐक्सेस का फिर से आकलन करने का सुझाव दिया जाता है.जांच के बाद पता चलता है कि मौजूदा Network अब इंटरनेट ऐक्सेस नहीं देता है. ऐसे में, इंटरनेट ऐक्सेस देने वाले किसी भी अन्य उपलब्ध नेटवर्क (जैसे कि मोबाइल डेटा) का इस्तेमाल करें.
[C-1-7] STA के डिसकनेक्ट होने के बाद, हर बार स्कैन की शुरुआत में एक बार सोर्स MAC पते और जांच अनुरोध फ़्रेम की क्रम संख्या को किसी भी क्रम में लगाना ज़रूरी है.
[C-1-8] एक जैसे MAC पते का इस्तेमाल करना ज़रूरी है (स्कैन के बीच में MAC पते को किसी भी क्रम में नहीं लगाया जाना चाहिए).
[C-1-9] जांच के अनुरोध की संख्या को सामान्य तरीके से (एक के बाद एक) करना ज़रूरी है. यह एक स्कैन में जांच के अनुरोधों के बीच में करना ज़रूरी है.
[C-1-10] स्कैन के आखिरी जांच अनुरोध और अगले स्कैन के पहले जांच अनुरोध के बीच, जांच अनुरोध की क्रम संख्या को किसी भी क्रम में लगाना ज़रूरी है.
[C-SR-1] असोसिएट और कनेक्ट किए जाते समय, किसी ऐक्सेस पॉइंट (एपी) पर सभी एसटीए कम्यूनिकेशन के लिए इस्तेमाल किए जाने वाले सोर्स MAC पते को किसी भी क्रम में बदलने का सुझाव दिया जाता है.
- डिवाइस को हर उस SSID (पासपॉइंट के लिए एफ़क्यूडीएन) के लिए, किसी भी क्रम में लगाए गए एक अलग MAC पते का इस्तेमाल करना होगा जिससे वह डिवाइस से संपर्क करता है.
- इस डिवाइस को उपयोगकर्ता को यह विकल्प देना होगा कि वह हर SSID को किसी भी क्रम में लगाने (पासपॉइंट के लिए एफ़क्यूडीएन) को बिना किसी क्रम के और किसी भी क्रम में लगाने वाले विकल्पों के साथ कंट्रोल कर सके. साथ ही, नए वाई-फ़ाई कॉन्फ़िगरेशन को किसी भी क्रम में लगाने के लिए, डिफ़ॉल्ट मोड को सेट करना ज़रूरी है.
[C-SR-2] बनाए जाने वाले किसी भी AP के लिए रैंडम BSSID का इस्तेमाल करने का सुझाव दिया जाता है.
- AP की ओर से इस्तेमाल किए जाने वाले SSID के हिसाब से, MAC पता किसी भी क्रम में होना चाहिए और उसे लगातार इस्तेमाल करना चाहिए.
- डिवाइस उपयोगकर्ता को इस सुविधा को बंद करने का विकल्प दे सकता है. अगर ऐसा विकल्प दिया जाता है, तो रैंडमाइज़ेशन की सुविधा डिफ़ॉल्ट रूप से चालू होनी चाहिए.

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

जब भी किसी ऐप्लिकेशन को WifiManager.createWifiLock() और WifiManager.WifiLock.acquire() एपीआई और लॉक चालू होने पर WIFI_MODE_FULL_HIGH_PERF लॉक या WIFI_MODE_FULL_LOW_LATENCY लॉक मिलता है, तो वाई-फ़ाई पावर सेव मोड को बंद कर देना चाहिए.
[C-3-2] जब डिवाइस, वाई-फ़ाई लो-लेटेंसी लॉक (WIFI_MODE_FULL_LOW_LATENCY) मोड में है, तो डिवाइस और ऐक्सेस पॉइंट के बीच दोतरफ़ा यात्रा का औसत समय, वाई-फ़ाई हाई परफ़ लॉक (WIFI_MODE_FULL_HIGH_PERF) मोड में इंतज़ार के समय से कम होना चाहिए.
[C-SR-3] हमारा सुझाव है कि जब भी लो-लेटेंसी लॉक (WIFI_MODE_FULL_LOW_LATENCY) चालू हो जाए और वह लागू हो जाए, तब वाई-फ़ाई से दोतरफ़ा यात्रा में लगने वाला समय कम किया जाए.

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

[C-2-1] उपयोगकर्ता के लिए, WifiManager.isScanAlwaysAvailable एपीआई वाले तरीके का इस्तेमाल करके, वैल्यू को चालू/बंद करने का विकल्प देना ज़रूरी है.

7.4.2.1. Wi-Fi Direct

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

वाई-फ़ाई डायरेक्ट (वाई-फ़ाई पीयर-टू-पीयर) के लिए सहायता शामिल होनी चाहिए.

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

[C-1-1] SDK टूल के दस्तावेज़ में बताए गए तरीके के मुताबिक, मिलते-जुलते Android API को लागू करना ज़रूरी है.
[C-1-2] हार्डवेयर की सुविधा android.hardware.wifi.direct की रिपोर्ट करना ज़रूरी है.
[C-1-3] ज़रूरी है कि सामान्य वाई-फ़ाई काम किया जा सके.
[C-1-4] ज़रूरी है कि एक ही समय में वाई-फ़ाई और वाई-फ़ाई डायरेक्ट की सुविधाएं काम करें.
[C-SR-1] सभी नए बने हुए वाई-फ़ाई डायरेक्ट कनेक्शन के लिए, सोर्स MAC पते को किसी भी क्रम में बदलने का सुझाव दिया जाता है.

7.4.2.2. वाई-फ़ाई टनल किया गया डायरेक्ट लिंक सेटअप

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

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

अगर डिवाइसों पर यह सुविधा लागू होती है, तो WiFiManager API की मदद से टीडीएलएस और टीडीएलएस के साथ काम करने की सुविधा चालू होती है. ऐसे में:

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

7.4.2.3. वाई-फ़ाई अवेयर

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

वाई-फ़ाई अवेयर के लिए सहायता शामिल होनी चाहिए.

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

[C-1-1] SDK टूल के दस्तावेज़ में बताया गया तरीका अपनाकर, WifiAwareManager एपीआई को लागू करना ज़रूरी है.
[C-1-2] android.hardware.wifi.aware फ़ीचर फ़्लैग का एलान करना ज़रूरी है.
[C-1-3] ज़रूरी है कि एक ही समय में वाई-फ़ाई और वाई-फ़ाई अवेयर से जुड़ी सुविधाएं काम करें.
[C-1-4] 30 मिनट से ज़्यादा अवधि के अंतराल में और वाई-फ़ाई अवेयर चालू होने पर वाई-फ़ाई अवेयर मैनेजमेंट इंटरफ़ेस पते को रैंडमाइज़ करना ज़रूरी है. ऐसा तब तक करना होगा, जब तक अवेयर रेंज की कार्रवाई चालू न हो या कोई अवेयर डेटा पाथ चालू न हो (डेटा पाथ के चालू रहने तक रैंडम डेटा की उम्मीद नहीं है).

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

[C-2-1] जगह की जानकारी का पता लगाने वाले एपीआई को लागू करना ज़रूरी है: setRangingEnabled, setMin श्रेणीMm, setMax काफ़ीMm, और onServiceDiscoveredAllowedRange.

7.4.2.4. वाई-फ़ाई पासपॉइंट

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

[C-1-1] वाई-फ़ाई पासपॉइंट की सुविधा शामिल होनी चाहिए.
[C-1-2] पासपॉइंट से जुड़े WifiManager एपीआई को लागू करना ज़रूरी है, जैसा कि SDK टूल के दस्तावेज़ में बताया गया है.
[C-1-3] ज़रूरी है कि यह IEEE 802.11u स्टैंडर्ड के साथ काम करता हो. यह स्टैंडर्ड, खास तौर पर नेटवर्क डिस्कवरी और सेलेक्शन से जुड़ा है. जैसे, जेनरिक ऐडवर्टाइज़मेंट सर्विस (जीएएस) और ऐक्सेस नेटवर्क क्वेरी प्रोटोकॉल (एएनक्यूपी).
[C-1-4] android.hardware.wifi.passpoint फ़ीचर फ़्लैग के बारे में बताना ज़रूरी है.
[C-1-5] पासपॉइंट नेटवर्क को खोजने, मैच करने, और उनसे जोड़ने के लिए, एओएसपी को लागू करने की प्रोसेस का पालन करना ज़रूरी है.
[C-1-6] वाई-फ़ाई अलायंस पासपॉइंट R2 में बताए गए, डिवाइस प्रावधान करने वाले प्रोटोकॉल के कम से कम इस सबसेट के साथ काम करना ज़रूरी है: ईएपी-टीटीएलएस की पुष्टि करना और एसओएपी-एक्सएमएल.
[C-1-7] AAA सर्वर सर्टिफ़िकेट को प्रोसेस करना ज़रूरी है, जैसा कि हॉटस्पॉट 2.0 R3 की खास बातों में बताया गया है.
[C-1-8] उपयोगकर्ता को वाई-फ़ाई पिकर की मदद से, प्रावधान करने का कंट्रोल देना ज़रूरी है.
[C-1-9] सभी डिवाइसों को फिर से चालू करने के दौरान, पासपॉइंट कॉन्फ़िगरेशन को एक जैसा बनाए रखना ज़रूरी है.
[C-SR-1] नियम और शर्तों को स्वीकार करने की सुविधा का पालन करने के लिए, इसका सुझाव दिया जाता है.
[C-SR-2] का सुझाव दिया जाता है, ताकि इवेंट वाली जगह की जानकारी देने वाली सुविधा के साथ काम किया जा सके.

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

[C-3-1] पासपॉइंट को डिफ़ॉल्ट रूप से चालू करना ज़रूरी है.

7.4.2.5. वाई-फ़ाई की जगह की जानकारी (वाई-फ़ाई से यात्रा का समय - आरटीटी)

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

इसमें वाई-फ़ाई की जगह की जानकारी के लिए सहायता शामिल होनी चाहिए.

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

[C-1-1] SDK टूल के दस्तावेज़ में बताया गया तरीका अपनाकर, WifiRttManager एपीआई को लागू करना ज़रूरी है.
[C-1-2] android.hardware.wifi.rtt फ़ीचर फ़्लैग का एलान करना ज़रूरी है.
[C-1-3] हर उस आरटीटी बर्स्ट के लिए सोर्स MAC पते को किसी भी क्रम में लगाना ज़रूरी है जिसे तब किया जाता है, जब आरटीटी जिस वाई-फ़ाई इंटरफ़ेस पर चलाया जा रहा होता है वह किसी ऐक्सेस पॉइंट से जुड़ा न हो.
[C-1-4] 68वें पर्सेंटाइल पर 80 मेगाहर्ट्ज़ बैंडविथ पर 2 मीटर के अंदर सटीक होना चाहिए (ऐसा क्यूमुलेटिव डिस्ट्रिब्यूशन फ़ंक्शन की मदद से किया गया है).
[C-SR-1] 68वें पर्सेंटाइल पर 80 मेगाहर्ट्ज़ बैंडविड्थ के हिसाब से, 1.5 मीटर के दायरे में इसे सटीक तरीके से रिपोर्ट करने की सलाह दी जाती है. कुल डिस्ट्रिब्यूशन फ़ंक्शन का इस्तेमाल करके इसका हिसाब लगाया जाता है.

7.4.2.6. वाई-फ़ाई कीपअलाइव ऑफ़लोड

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

वाई-फ़ाई कीपअलाइव ऑफ़लोड के लिए समर्थन शामिल होना चाहिए.

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

[C-1-1] SocketKeepAlive एपीआई के साथ काम करना ज़रूरी है.
[C-1-2] वाई-फ़ाई का इस्तेमाल करने पर, एक साथ कम से कम तीन कीपअलाइव स्लॉट की सुविधा होनी चाहिए.

अगर लागू किए गए डिवाइस में वाई-फ़ाई कीपअलाइव ऑफ़लोड के लिए सहायता शामिल नहीं है, तो वे:

[C-2-1] ERROR_UNSUPPORTED को वापस करना होगा.

7.4.2.7. वाई-फ़ाई ईज़ी कनेक्ट (डिवाइस प्रॉविज़निंग प्रोटोकॉल)

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

इसमें वाई-फ़ाई ईज़ी कनेक्ट (डीपीपी) के लिए सहायता शामिल होनी चाहिए.

[C-1-1] WifiManager#isEasyConnectSupported() तरीके का इस्तेमाल करके, true को रिटर्न करना ज़रूरी है.

7.4.2.8. एंटरप्राइज़ वाई-फ़ाई सर्वर प्रमाणपत्र की पुष्टि

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

[C-SR-1] इस बात का खास तौर पर सुझाव दिया जाता है कि उपयोगकर्ता को Settings ऐप्लिकेशन में, Enterprise वाई-फ़ाई नेटवर्क को मैन्युअल तरीके से जोड़ने का विकल्प न दें.

7.4.2.9. ट्रस्ट ऑन फ़र्स्ट यूज़ (टीओएफ़यू)

अगर डिवाइस लागू करने की सुविधा, पहली बार इस्तेमाल किए जाने पर भरोसा (टीओएफ़यू) के साथ काम करती है और उपयोगकर्ता को WPA/WPA2/WPA3-एंटरप्राइज़ कॉन्फ़िगरेशन तय करने की अनुमति दी गई है, तो:

[C-4-1] उपयोगकर्ता को TOFU इस्तेमाल करने का विकल्प देना ज़रूरी है.

7.4.3. ब्लूटूथ

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

A2DP वाले बेहतर ऑडियो कोडेक और ब्लूटूथ ऑडियो कोडेक (जैसे, LDAC) काम करने चाहिए.

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

कनेक्ट किए गए कम से कम पांच डिवाइसों पर काम करना चाहिए.

अगर लागू किए गए डिवाइस पर android.hardware.vr.high_performance सुविधा का एलान किया जाता है, तो वे:

[C-1-1] ब्लूटूथ 4.2 और ब्लूटूथ LE डेटा लेंट एक्सटेंशन के साथ काम करना ज़रूरी है.

Android में ब्लूटूथ और ब्लूटूथ स्मार्ट की सुविधा शामिल है.

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

[C-2-1] प्लैटफ़ॉर्म के लिए काम की सुविधाओं (android.hardware.bluetooth और android.hardware.bluetooth_le) का एलान करना ज़रूरी है. साथ ही, प्लैटफ़ॉर्म के एपीआई लागू करने होंगे.
डिवाइस के लिए ज़रूरी ब्लूटूथ प्रोफ़ाइल, जैसे कि A2DP, AVRCP, OBEX, HFP वगैरह का इस्तेमाल करना चाहिए.

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

[C-3-1] हार्डवेयर की सुविधा android.hardware.bluetooth_le के बारे में बताना ज़रूरी है.
[C-3-2] SDK टूल के दस्तावेज़ और android.ब्लूटूथ में दी गई जानकारी के हिसाब से, GATT (जेनरिक एट्रिब्यूट प्रोफ़ाइल) आधारित ब्लूटूथ एपीआई चालू करना ज़रूरी है.
[C-3-3] BluetoothAdapter.isOffloadedFilteringSupported() के लिए सही वैल्यू की रिपोर्ट करना ज़रूरी है. इससे यह बताया जा सकता है कि ScanFilter एपीआई क्लास के लिए, फ़िल्टर करने वाला लॉजिक लागू किया गया है या नहीं.
[C-3-4] BluetoothAdapter.isMultipleAdvertisementSupported() के लिए सही वैल्यू की रिपोर्ट करना ज़रूरी है. इससे पता चलेगा कि कम ऊर्जा वाले विज्ञापन दिखाए जा सकते हैं या नहीं.
[C-3-5] रिज़ॉल्व होने वाले प्राइवेट पते (आरपीए) का टाइम आउट 15 मिनट से ज़्यादा नहीं होना चाहिए. साथ ही, जब डिवाइस स्कैनिंग या विज्ञापन के लिए बीएलई का इस्तेमाल कर रहा हो, तब उपयोगकर्ता की निजता की सुरक्षा के लिए, टाइम आउट पर पते को रोटेट करना होगा. टाइमिंग हमलों से बचने के लिए, 5 से 15 मिनट के बीच के टाइम आउट इंटरवल को भी किसी भी क्रम में रखा जाना चाहिए.
ScanFilter API को लागू करते समय, फ़िल्टर करने वाले लॉजिक को ब्लूटूथ चिपसेट पर ऑफ़लोड करने की सुविधा दी जानी चाहिए.
बैच में स्कैन करने की सुविधा को ब्लूटूथ चिपसेट पर ऑफ़लोड करने की सुविधा दी जानी चाहिए.
इसमें कम से कम चार स्लॉट वाले एक से ज़्यादा विज्ञापन दिखाए जा सकते हैं.

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

[C-4-1] सिस्टम एपीआई BluetoothAdapter.isBleScanAlwaysAvailable() की मदद से, उपयोगकर्ता के लिए इस वैल्यू को चालू/बंद करने का विकल्प देना ज़रूरी है.

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

[C-5-1] BluetoothAdapter.getProfileProxy(context, संख्याएं, BluetoothProfile.HEARING_AID) के लिए true लौटानी होगी.

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

[C-6-1] ऐसे किसी भी ब्लूटूथ मेटाडेटा (जैसे कि स्कैन के नतीजे) के ऐक्सेस पर पाबंदी लगा देनी चाहिए जिसका इस्तेमाल डिवाइस की जगह की जानकारी पाने के लिए किया जा सकता है. ऐसा तब तक होना चाहिए, जब तक अनुरोध करने वाला ऐप्लिकेशन, फ़ोरग्राउंड/बैकग्राउंड की मौजूदा स्थिति के हिसाब से android.permission.ACCESS_FINE_LOCATION अनुमति जांच की प्रोसेस में पास न हो जाए.

अगर डिवाइस लागू करने के तरीके में ब्लूटूथ या ब्लूटूथ स्मार्ट

[C-6-2] android.permission.ACCESS_FINE_LOCATION के पीछे ब्लूटूथ का ऐक्सेस देना ज़रूरी है.

अगर लागू किए गए डिवाइस पर BluetoothAdapter.isLeAudioSupported() API के लिए true रिस्पॉन्स मिलता है, तो:

[C-7-1] यूनिकास्ट क्लाइंट के साथ काम करना ज़रूरी है.
[C-7-2] 2M PHY के साथ काम करना ज़रूरी है.
[C-7-3] एलई एक्सटेंडेड विज्ञापन के साथ काम करना ज़रूरी है.
[C-7-4] एक CIG में, कम से कम दो सीआईएस कनेक्शन के साथ काम करना ज़रूरी है.
[C-7-5] BAP यूनिकास्ट क्लाइंट, सीएसआईपी सेट कोऑर्डिनेटर, एमसीपी सर्वर, वीसीपी कंट्रोलर, सीसीपी सर्वर को एक साथ चालू करना ज़रूरी है.
[C-SR-1] HAP यूनिकास्ट क्लाइंट को चालू करने के लिए इस बात का सुझाव दिया जाता है.

अगर लागू किए गए डिवाइस पर BluetoothAdapter.isLeAudioBroadcastSourceSupported() API के लिए true रिस्पॉन्स मिलता है, तो:

[C-8-1] एक BIG लाइव स्ट्रीम में, कम से कम दो BIS लिंक के साथ काम करना ज़रूरी है.
[C-8-2] BAP ब्रॉडकास्ट सोर्स और BAP ब्रॉडकास्ट असिस्टेंट को साथ-साथ चालू करना ज़रूरी है.
[C-8-3] एलई में समय-समय पर विज्ञापन दिखाने की सुविधा होनी चाहिए.

अगर लागू किए गए डिवाइस पर BluetoothAdapter.isLeAudioBroadcastAssistantSupported() API के लिए true रिस्पॉन्स मिलता है, तो:

[C-9-1] PAST (पीरियॉडिक ऐडवर्टाइज़िंग सिंक ट्रांसफ़र) का इस्तेमाल करना ज़रूरी है.
[C-9-2] एलई के लिए पीरियॉडिक विज्ञापन के साथ काम करना ज़रूरी है.

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

[C-10-1] ज़रूरी है कि आरएसएसआई के मेज़रमेंट 95% के अंदर +/-9dB के अंदर हों. ऐसा उन रेफ़रंस डिवाइस से 1 मीटर की दूरी पर होना चाहिए जो आस-पास की जगह पर ADVERTISE_TX_POWER_HIGH से ट्रांसमिट हो रहे हैं.
[C-10-2] हर चैनल पर होने वाले उतार-चढ़ाव को कम करने के लिए, Rx/Tx सुधार शामिल करना ज़रूरी है. इससे हर ऐंटीना पर, हर ऐंटीना पर (अगर एक से ज़्यादा चैनल का इस्तेमाल किया जा रहा है) हर चैनल का मेज़रमेंट 95% के लिए एक-दूसरे के +/-3dB के अंदर हो.
[C-SR-2] Rx ऑफ़सेट को मापने और उसकी भरपाई करने के लिए बहुत ज़्यादा सुझाव दिया जाता है. इससे यह पक्का किया जा सकेगा कि BLE आरएसएसआई का मीडियन -60dBm +/-10 dB है. यह ADVERTISE_TX_POWER_HIGH से ट्रांसमिट होने वाले रेफ़रंस डिवाइस से 1 मिनट की दूरी पर है. यहां डिवाइस इस तरह से डाले गए हैं कि वे 'पैरलल प्लेन' पर हों और उनकी स्क्रीन एक ही दिशा में हो.
[C-SR-3] Tx ऑफ़सेट को मापने और उसकी भरपाई करने की सलाह दी जाती है. इससे यह पक्का किया जा सकता है कि 1 मीटर की दूरी पर मौजूद किसी रेफ़रंस डिवाइस से स्कैन करते समय और ADVERTISE_TX_POWER_HIGH पर ट्रांसमिट करते समय, आरएसएसआई का मीडियन -60dBm +/-10 dB हो. ऐसा तब होता है, जब डिवाइस इस तरह से हों कि वे 'पैरलल प्लेन' पर हों और उनकी स्क्रीन एक ही दिशा में हो.

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

[C-SR-4] के लिए सहायता देने का सुझाव दिया जाता है:
- एल 2एम फ़ी
- एलई कोडेक पीएचवाई
- LE विज्ञापन एक्सटेंशन
- समय-समय पर दिखने वाले विज्ञापन
- विज्ञापन के कम से कम 10 सेट हों
- कम से कम 8 LE एक साथ कई कनेक्शन होने चाहिए. हर कनेक्शन, किसी भी कनेक्शन टोपोलॉजी रोल में हो सकता है.
- एलई लिंक लेयर की निजता
- "समस्या हल करने वाली सूची" में कम से कम आठ एंट्री होनी चाहिए

7.4.4. नियर-फ़ील्ड कम्यूनिकेशंस

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

नियर-फ़ील्ड कम्यूनिकेशंस (एनएफ़सी) के लिए, ट्रांससीवर और उससे जुड़ा हार्डवेयर शामिल होना चाहिए.
[C-0-1] android.nfc.NdefMessage और android.nfc.NdefRecord एपीआई को लागू करना ज़रूरी है, भले ही उनमें एनएफ़सी के साथ काम करने की सुविधा शामिल न हो या android.hardware.nfc की सुविधा का एलान न किया गया हो, क्योंकि क्लास प्रोटोकॉल-स्वतंत्र डेटा दिखाने का फ़ॉर्मैट दिखाती हैं.

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

[C-1-1] android.content.pm.PackageManager.hasSystemFeature() तरीके का इस्तेमाल करके, android.hardware.nfc सुविधा की शिकायत करना ज़रूरी है.
ज़रूरी है कि वह इन एनएफ़सी स्टैंडर्ड का इस्तेमाल करके, एनडीईएफ़ मैसेज पढ़ और लिख सके:
[C-1-2] ज़रूरी है कि वह एनएफ़सी फ़ोरम रीडर/राइटर के तौर पर काम कर सके (जैसा कि एनएफ़सी फ़ोरम की तकनीकी जानकारी के मुताबिक एनएफ़सीफ़ोरम-टीएस-डिजिटलप्रोटोकॉल-1.0 में बताया गया है) इन एनएफ़सी स्टैंडर्ड का इस्तेमाल करके:
- एनएफ़सीए (ISO14443-3A)
- एनएफ़सीबी (आईएसओ14443-3बी)
- एनएफ़सीएफ़ (जेआईएस X 6319-4)
- IsoDep (आईएसओ 14443-4)
- एनएफ़सी फ़ोरम टैग टाइप 1, 2, 3, 4, 5 (एनएफ़सी फ़ोरम की ओर से तय किया गया है)
[C-SR-1] इस बात का बहुत ज़्यादा सुझाव दिया जाता है कि NDEF मैसेज के साथ-साथ रॉ डेटा को आसानी से पढ़ और लिखा जा सके. इसके लिए, नीचे दिए गए एनएफ़सी के स्टैंडर्ड का इस्तेमाल किया जाता है. ध्यान दें कि एनएफ़सी के स्टैंडर्ड को 'सुझाया गया' के तौर पर मार्क किया गया है. हालांकि, आने वाले वर्शन के लिए काम करने से जुड़ी परिभाषा में, इन्हें 'ज़रूरी है' में बदलने की योजना बनाई गई है. इस वर्शन में इन स्टैंडर्ड का इस्तेमाल करना ज़रूरी नहीं है. हालांकि, आने वाले वर्शन में इन स्टैंडर्ड की ज़रूरत होगी. Android के इस वर्शन पर चलने वाले मौजूदा और नए डिवाइसों को भी इन ज़रूरतों को पूरा करने की सलाह दी जाती है, ताकि वे आने वाले प्लैटफ़ॉर्म के रिलीज़ पर अपग्रेड कर पाएं.
[C-1-13] एनएफ़सी के डिस्कवरी मोड में, काम करने वाली सभी टेक्नोलॉजी के लिए पोल करना ज़रूरी है.
जब डिवाइस चालू हो और स्क्रीन चालू हो, और लॉक स्क्रीन अनलॉक हो, तो एनएफ़सी डिस्कवरी मोड का इस्तेमाल करना चाहिए.
Thin रफ़्तार के एनएफ़सी बारकोड प्रॉडक्ट के बारकोड और यूआरएल (अगर कोड में बदले गए हों) को पढ़ लिया जाना चाहिए.

ध्यान दें कि सार्वजनिक रूप से उपलब्ध लिंक, ऊपर बताए गए JIS, ISO, और एनएफ़सी फ़ोरम की खास बातों के लिए उपलब्ध नहीं हैं.

Android में एनएफ़सी होस्ट कार्ड एम्युलेशन (एचसीई) मोड की सुविधा शामिल है.

अगर डिवाइस पर लागू करने के लिए, एचसीई (NFCA और/या NfcB के लिए) पर काम करने वाला एनएफ़सी कंट्रोलर चिपसेट और ऐप्लिकेशन आईडी (एआईडी) रूटिंग की सुविधा काम करती है, तो ये:

[C-2-1] android.hardware.nfc.hce सुविधा के कॉन्स्टेंट की जानकारी देना ज़रूरी है.
[C-2-2] Android SDK में बताए गए एनएफ़सी एचसीई एपीआई के साथ काम करना ज़रूरी है.

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

[C-3-1] android.hardware.nfc.hcef सुविधा के कॉन्स्टेंट की रिपोर्ट करना ज़रूरी है.
[C-3-2] Android SDK में बताए गए तरीके के मुताबिक, NFCF Card Emulation API को लागू करना ज़रूरी है.

अगर इस सेक्शन में बताए गए, डिवाइस इस्तेमाल करने के तरीके में सामान्य एनएफ़सी की सुविधा शामिल है और वह रीडर/राइटर की भूमिका में MIFARE टेक्नोलॉजी (MIFARE क्लासिक, MIFARE Ultralight, MIFARE क्लासिक पर NDEF) की सुविधा देती है, तो वे:

[C-4-1] Android SDK के बताए गए दस्तावेज़ के मुताबिक, उससे जुड़े Android एपीआई को लागू करना ज़रूरी है.
[C-4-2] android.content.pm.PackageManager.hasSystemFeature() तरीके का इस्तेमाल करके, com.nxp.mifare सुविधा की शिकायत करना ज़रूरी है. ध्यान दें कि यह Android का स्टैंडर्ड फ़ीचर नहीं है. इसलिए, यह android.content.pm.PackageManager क्लास में कॉन्सटेंट के तौर पर नहीं दिखता.

7.4.5. नेटवर्किंग प्रोटोकॉल और एपीआई

7.4.5.1. नेटवर्क की कम से कम क्षमता

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

[C-0-1] डेटा नेटवर्किंग के एक या उससे ज़्यादा तरीकों के लिए सहायता शामिल करना ज़रूरी है. खास तौर पर, डिवाइस लागू करने के लिए 200 केबिट/सेकंड या इससे ज़्यादा वाले कम से कम एक डेटा स्टैंडर्ड के साथ काम करना ज़रूरी है. इस ज़रूरी शर्त को पूरा करने वाली टेक्नोलॉजी के उदाहरणों में EDGE, HSPA, EV-DO, 802.11g, ईथरनेट, और ब्लूटूथ पैन शामिल हैं.
जब एक फ़िज़िकल नेटवर्किंग स्टैंडर्ड (जैसे कि ईथरनेट) प्राइमरी डेटा कनेक्शन हो, तो कम से कम एक सामान्य वायरलेस डेटा स्टैंडर्ड, जैसे 802.11 (वाई-फ़ाई) के लिए काम करना भी ज़रूरी है.
इसमें एक से ज़्यादा तरह की डेटा कनेक्टिविटी लागू की जा सकती है.

7.4.5.2. IPv6

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

[C-0-2] ज़रूरी है कि इसमें आईपीवी6 नेटवर्किंग स्टैक शामिल हो और यह मैनेज किए जा रहे एपीआई जैसे java.net.Socket और java.net.URLConnection के साथ-साथ AF_INET6 सॉकेट जैसे नेटिव एपीआई का इस्तेमाल करके आईपीवी6 कम्यूनिकेशन की सुविधा देता हो.
[C-0-3] डिफ़ॉल्ट रूप से IPv6 चालू होना चाहिए.
- यह पक्का करना ज़रूरी है कि आईपीवी6 कम्यूनिकेशन, आईपीवी4 जितना ही भरोसेमंद हो. उदाहरण के लिए:
  - [C-0-4] बैटरी सेवर मोड में भी आईपीवी6 कनेक्टिविटी को बनाए रखना ज़रूरी है.
  - [C-0-5] रेट सीमित करने से, डिवाइस पर आईपीवी6 का पालन करने वाले किसी भी ऐसे नेटवर्क पर आईपीवी6 कनेक्टिविटी नहीं रहेगी जो कम से कम 180 सेकंड के आरए लाइफ़टाइम का इस्तेमाल करती हो.
[C-0-6] आईपीवी6 नेटवर्क से कनेक्ट होने पर, तीसरे पक्ष के ऐप्लिकेशन को नेटवर्क से सीधे आईपीवी6 कनेक्टिविटी की सुविधा देनी होगी. इसके लिए, डिवाइस पर स्थानीय रूप से किसी भी तरह का पता या पोर्ट ट्रांसलेशन नहीं करना होगा. मैनेज किए जा रहे दोनों एपीआई, जैसे कि Socket#getLocalAddress या Socket#getLocalPort) और getsockname() या IPV6_PKTINFO जैसे एनडीके एपीआई को वह आईपी पता और पोर्ट देना होगा जिसका इस्तेमाल असल में नेटवर्क पर पैकेट भेजने और पाने के लिए किया जाता है. साथ ही, यह इंटरनेट (वेब) सर्वर पर सोर्स आईपी और पोर्ट के तौर पर दिखता है.

आईपीवी6 सपोर्ट के लिए ज़रूरी लेवल, नेटवर्क टाइप पर निर्भर करता है, जैसा कि इन ज़रूरतों में दिखाया गया है.

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

[C-1-1] वाई-फ़ाई पर ड्यूअल-स्टैक और IPv6-सिर्फ़ काम करने की सुविधा होनी चाहिए.

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

[C-2-1] ईथरनेट पर ड्यूअल-स्टैक और सिर्फ़ आईपीवी6 के साथ काम किया जा सकता है.

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

[C-3-1] मोबाइल पर IPv6 ऑपरेशन (सिर्फ़ IPv6 और संभावित रूप से ड्यूअल-स्टैक) के साथ काम करना ज़रूरी है.

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

[C-4-1] डिवाइस को एक साथ एक से ज़्यादा नेटवर्क टाइप से कनेक्ट करने पर, हर नेटवर्क पर ऊपर बताई गई ज़रूरी शर्तों को एक साथ पूरा करना ज़रूरी है.

7.4.5.3. कैप्टिव पोर्टल

कैप्टिव पोर्टल ऐसा नेटवर्क होता है जिसे इंटरनेट ऐक्सेस करने के लिए साइन इन करना ज़रूरी होता है.

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

[C-1-1] इंटेंट को हैंडल करने के लिए, कैप्टिव पोर्टल ऐप्लिकेशन उपलब्ध कराना ज़रूरी है ACTION_CAPTIVE_PORTAL_SIGN_IN और कैप्टिव पोर्टल लॉगिन पेज को दिखाने के लिए, उस इंटेंट को सिस्टम एपीआई पर कॉल करके दिखाना ConnectivityManager#startCaptivePortalApp(Network, Bundle).
[C-1-2] डिवाइस को किसी भी तरह के नेटवर्क, जैसे कि सेल्युलर/मोबाइल नेटवर्क, वाई-फ़ाई, ईथरनेट या ब्लूटूथ से कनेक्ट होने पर कैप्टिव पोर्टल ऐप्लिकेशन के ज़रिए, कैप्टिव पोर्टल की पहचान करने और लॉगिन करने की सुविधा ज़रूर देनी चाहिए.
[C-1-3] जब डिवाइस को निजी डीएनएस के सख्त मोड इस्तेमाल करने के लिए कॉन्फ़िगर किया गया हो, तब क्लियरटेक्स्ट डीएनएस का इस्तेमाल करके कैप्टिव पोर्टल में लॉग इन करने की सुविधा देनी होगी.
[C-1-4] android.net.LinkProperties.getPrivateDnsServerName और android.net.LinkProperties.isPrivateDnsActive के लिए SDK टूल से जुड़े दस्तावेज़ के मुताबिक, एन्क्रिप्ट (सुरक्षित) किए गए डीएनएस का इस्तेमाल करना ज़रूरी है. ऐसा उन नेटवर्क ट्रैफ़िक के लिए किया जाना चाहिए जो कैप्टिव पोर्टल के साथ साफ़ तौर पर जानकारी नहीं देते हैं.
[C-1-5] को यह पक्का करना होगा कि जब उपयोगकर्ता किसी कैप्टिव पोर्टल में लॉग इन कर रहा हो, तो ऐप्लिकेशन (ConnectivityManager.getActiveNetwork, ConnectivityManager.registerDefaultNetworkCallback से लौटाया गया डिफ़ॉल्ट नेटवर्क, और Java.net.Socket जैसे नेटिव API (एपीआई) और Connect() जैसे नेटिव एपीआई डिफ़ॉल्ट रूप से इस्तेमाल किए जाने वाले ऐप्लिकेशन) हों, जो उपलब्ध होने पर इंटरनेट ऐक्सेस देते हैं.

7.4.6. समन्वयन सेटिंग

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

[C-0-1] मास्टर ऑटो-सिंक सेटिंग डिफ़ॉल्ट रूप से चालू होनी चाहिए, ताकि getMasterSyncAutomatically() तरीका “सही” दिखे.

7.4.7. डेटा बचाने वाला विकल्प

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

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

[C-1-1] SDK टूल के दस्तावेज़ में बताए गए तरीके के मुताबिक, ConnectivityManager क्लास के सभी एपीआई के साथ काम करना ज़रूरी है

[C-2-1] ConnectivityManager.getRestrictBackgroundStatus() के लिए RESTRICT_BACKGROUND_STATUS_DISABLED वैल्यू देनी होगी
[C-2-2] ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED को ब्रॉडकास्ट नहीं करना चाहिए.

7.4.8. सुरक्षा तत्व

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

[C-1-1] android.se.omapi.SEService.getReaders() एपीआई की मदद से, लोगों के लिए उपलब्ध सुरक्षा एलिमेंट की गिनती करना ज़रूरी है.
[C-1-2] यूआईसीसी-आधारित सुरक्षा एलिमेंट वाले डिवाइस के लिए android.hardware.se.omapi.uicc के ज़रिए सही फ़ीचर फ़्लैग के बारे में बताना ज़रूरी है. android.hardware.se.omapi.ese ईएसई पर आधारित सुरक्षा एलिमेंट वाले डिवाइस के लिए और एसडी वाले सुरक्षित एलिमेंट वाले डिवाइस के लिए android.hardware.se.omapi.sd के बारे में बताना ज़रूरी है.

7.4.9. यूडब्ल्यूबी

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

[C-1-1] इससे जुड़े Android API को android.uwb में लागू करना ज़रूरी है.
[C-1-2] हार्डवेयर फ़ीचर फ़्लैग android.hardware.uwb की शिकायत करना ज़रूरी है.
[C-1-3] Android वर्शन को लागू करने के दौरान, काम की सभी यूडब्ल्यूबी प्रोफ़ाइलों का इस्तेमाल किया जाना ज़रूरी है.
[C-1-4] लोगों को यह सुविधा देनी होगी कि वे यूडब्ल्यूबी रेडियो को चालू/बंद करने की सुविधा को टॉगल कर सकें.
[C-1-5] यह पक्का करना ज़रूरी है कि यूडब्ल्यूबी रेडियो का इस्तेमाल करने वाले ऐप्लिकेशन, UWB_RANGING अनुमति को (NEARBY_devices अनुमति ग्रुप के तहत) में होल्ड करें.
[C-SR-1] का सुझाव दिया जाता है कि स्टैंडर्ड संगठनों के तय किए गए नियमों के पालन और सर्टिफ़िकेशन टेस्ट को पास करें. इनमें FIRA, CCC, और सीएसए शामिल हैं.
- [C-1-6] यह पक्का करना ज़रूरी है कि दूरी की माप, 95% दूरी के लिए +/-15 सें॰मी॰ के अंदर हो. यह दूरी किसी गैर-रिफ़्लेक्टिव चैंबर में 1 मीटर की दूरी पर होती है.
- [C-1-7] ज़रूरी है कि रेफ़रंस डिवाइस से 1 मीटर की दूरी के माप का मीडियन [0.75 मीटर, 1.25 मीटर] के अंदर हो. यहां ज़मीन की सच्चाई का पता, डीयूटी के ऊपरी किनारे से ऊपर और झुकाकर रखा जाता है.
- मौजूदगी का कैलिब्रेशन में बताया गया मेज़रमेंट सेटअप करने का तरीका अपनाने के लिए, [C-SR-2] का सुझाव दिया जाता है.

7.5. कैमरे

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

[C-1-1] android.hardware.camera.any फ़ीचर फ़्लैग का एलान करना ज़रूरी है.
[C-1-2] किसी ऐप्लिकेशन के लिए यह मुमकिन है कि वह एक साथ, डिवाइस के सबसे बड़े रिज़ॉल्यूशन वाले कैमरा सेंसर से तैयार की गई इमेज के साइज़ के बराबर 3 RGBA_8888 बिटमैप बांट सके, जबकि बुनियादी झलक के लिए कैमरा खुला हो और अभी भी कैप्चर किया जा रहा हो.
[C-1-3] यह पक्का करना ज़रूरी है कि पहले से इंस्टॉल किए गए डिफ़ॉल्ट कैमरा ऐप्लिकेशन हैंडलिंग इंटेंट MediaStore.ACTION_IMAGE_CAPTURE, MediaStore.ACTION_IMAGE_CAPTURE_SECURE या MediaStore.ACTION_VIDEO_CAPTURE की ज़िम्मेदारी इमेज के मेटाडेटा से उपयोगकर्ता की जगह की जानकारी हटाने की है. इसके बाद ही, उसे ऐक्सेस करने वाले ऐप्लिकेशन को ACCESS_FINE_LOCATION में भेजा जा सकता है.

अगर डिवाइस में एचडीआर 10-बिट आउटपुट देने की सुविधा काम करती है, तो ये काम करते हैं:

[C-2-1] 10-बिट आउटपुट की सुविधा वाले हर कैमरा डिवाइस के लिए, कम से कम एचएलजी एचडीआर प्रोफ़ाइल काम करनी चाहिए.
[C-2-2] 10-बिट आउटपुट की सुविधा, मुख्य पीछे वाले कैमरे या सामने वाले मुख्य कैमरे के साथ काम कर सकती है.
[C-SR-1] दोनों प्राइमरी कैमरों के लिए 10-बिट आउटपुट का इस्तेमाल करने के लिए, इस बात का खास तौर पर सुझाव दिया जाता है.
[C-2-3] लॉजिकल कैमरे के सभी BACKWARD_COMPATIBLE वाले फ़िज़िकल सब-कैमरा और लॉजिकल कैमरे के लिए, एक जैसी एचडीआर प्रोफ़ाइल इस्तेमाल की जानी चाहिए.

10-बिट एचडीआर के साथ काम करने वाले लॉजिकल कैमरा डिवाइसों के लिए, जो android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO एपीआई को लागू करते हैं वे:

[C-3-1] लॉजिकल कैमरे पर CONTROL_ZOOM_RATIO कंट्रोल की मदद से, पीछे की ओर काम करने वाले सभी फ़िज़िकल कैमरों के बीच स्विच करने की सुविधा होनी चाहिए.

7.5.1. पीछे वाला कैमरा

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

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

इसमें पीछे वाला कैमरा होना चाहिए.

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

[C-1-1] फ़ीचर फ़्लैग android.hardware.camera और android.hardware.camera.any की शिकायत करना ज़रूरी है.
[C-1-2] इसका रिज़ॉल्यूशन कम से कम 2 मेगापिक्सल होना चाहिए.
कैमरा ड्राइवर में या तो हार्डवेयर ऑटो-फ़ोकस लागू होना चाहिए या सॉफ़्टवेयर ऑटो-फ़ोकस होना चाहिए (ऐप्लिकेशन सॉफ़्टवेयर से पारदर्शी).
इसमें फ़िक्स्ड-फ़ोकस या EDOF (फ़ील्ड की बढ़ाई गई डेप्थ) हार्डवेयर हो सकता है.
इसमें फ़्लैश शामिल हो सकता है.

अगर कैमरे में फ़्लैश चालू है, तो:

[C-2-1] कैमरा प्रीव्यू सरफ़ेस पर android.hardware.Camera.PreviewCallback इंस्टेंस रजिस्टर होने के दौरान फ़्लैश लैंप जलाना नहीं चाहिए. जब तक कि ऐप्लिकेशन ने Camera.Parameters ऑब्जेक्ट के FLASH_MODE_AUTO या FLASH_MODE_ON एट्रिब्यूट को चालू करके फ़्लैश को साफ़ तौर पर चालू न किया हो. ध्यान दें कि यह सीमा डिवाइस में पहले से मौजूद सिस्टम कैमरा ऐप्लिकेशन पर लागू नहीं होती, बल्कि Camera.PreviewCallback का इस्तेमाल करने वाले सिर्फ़ तीसरे पक्ष के ऐप्लिकेशन पर लागू होती है.

7.5.2. सामने वाला कैमरा

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

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

इसमें सामने वाला कैमरा हो सकता है.

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

[C-1-1] फ़ीचर फ़्लैग android.hardware.camera.any और android.hardware.camera.front की शिकायत करना ज़रूरी है.
[C-1-2] इसका रिज़ॉल्यूशन कम से कम VGA (640x480 पिक्सल) होना चाहिए.
[C-1-3] Camera API के लिए, सामने वाले कैमरे को डिफ़ॉल्ट के तौर पर इस्तेमाल नहीं करना चाहिए. साथ ही, सामने वाले कैमरे को पीछे वाले डिफ़ॉल्ट कैमरे के तौर पर इस्तेमाल करने के लिए, एपीआई को कॉन्फ़िगर भी नहीं करना चाहिए. भले ही, डिवाइस में सिर्फ़ यही कैमरा इस्तेमाल किया गया हो.
[C-1-4] जब मौजूदा ऐप्लिकेशन ने साफ़ तौर पर अनुरोध किया हो कि कॉल के ज़रिए android.hardware.Camera.setDisplayOrientation() तरीके से कैमरे के डिसप्ले को घुमाया जाए, तब ऐप्लिकेशन के चुने हुए दिशा-निर्देश के मुताबिक कैमरे की झलक हॉरिज़ॉन्टल तौर पर मिरर की जानी चाहिए. इसके उलट, अगर मौजूदा ऐप्लिकेशन साफ़ तौर पर यह अनुरोध नहीं करता है कि कॉल के ज़रिए android.hardware.Camera.setDisplayOrientation() तरीके से कैमरा डिसप्ले को घुमाया जाए, तो झलक को डिवाइस के डिफ़ॉल्ट हॉरिज़ॉन्टल ऐक्सिस पर बनाया जाना चाहिए.
[C-1-5] ऐप्लिकेशन कॉलबैक में दिखाई गई या मीडिया स्टोरेज के लिए सेट की गई आखिरी स्टिल इमेज या वीडियो स्ट्रीम को मिरर नहीं किया जाना चाहिए.
[C-1-6] पोस्टव्यू में दिखाई गई इमेज को उसी तरह शेयर करना ज़रूरी है जिस तरह कैमरा प्रीव्यू वाली इमेज स्ट्रीम में किया जाता है.
इसमें पीछे वाले कैमरों के लिए उपलब्ध सुविधाएं (जैसे कि ऑटो-फ़ोकस, फ़्लैश वगैरह) शामिल हो सकती हैं. इनके बारे में सेक्शन 7.5.1 में बताया गया है.

अगर डिवाइस लागू करने के तरीके को उपयोगकर्ता घुमा सकता है (जैसे कि एक्सलरोमीटर से अपने-आप या उपयोगकर्ता के इनपुट का इस्तेमाल करके, मैन्युअल तरीके से):

[C-2-1] कैमरे की झलक, डिवाइस के मौजूदा ओरिएंटेशन के हिसाब से हॉरिज़ॉन्टल तौर पर मिरर की जानी चाहिए.

7.5.3. बाहरी कैमरा

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

इसमें ऐसा बाहरी कैमरा इस्तेमाल किया जा सकता है जो हमेशा कनेक्ट न हो.

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

[C-1-1] प्लैटफ़ॉर्म के फ़ीचर फ़्लैग के बारे में बताना ज़रूरी है android.hardware.camera.external और android.hardware camera.any.
[C-1-2] अगर बाहरी कैमरा, यूएसबी होस्ट पोर्ट से कनेक्ट किया गया है, तो यूएसबी वीडियो क्लास (यूवीसी 1.0 या उसके बाद के वर्शन) पर काम करना ज़रूरी है.
[C-1-3] कैमरे के सीटीएस टेस्ट को, किसी दूसरे कैमरे से कनेक्ट करके टेस्ट पास करना ज़रूरी है. कैमरे के सीटीएस टेस्टिंग के बारे में जानकारी source.android.com पर उपलब्ध है.
अच्छी क्वालिटी वाली, कोड में बदली नहीं गई स्ट्रीम (जैसे, रॉ या अलग से कंप्रेस की गई पिक्चर स्ट्रीम) को ट्रांसफ़र करने के लिए, MJPEG जैसे वीडियो कंप्रेस करने की सुविधा इस्तेमाल करनी चाहिए.
शायद इसमें कई कैमरे काम कर सकते हैं.
शायद इनमें कैमरा-आधारित वीडियो एन्कोडिंग की सुविधा काम करती है.

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

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

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

कैमरा ऐक्सेस करने के लिए, Android में दो एपीआई पैकेज शामिल हैं: नया android.hardware.camera2 एपीआई, ऐप्लिकेशन में लो-लेवल कैमरा कंट्रोल दिखाता है. इसमें ज़ीरो-कॉपी बर्स्ट/स्ट्रीमिंग फ़्लो और हर फ़्रेम के हिसाब से एक्सपोज़र, गेन, व्हाइट बैलेंस गेन, कलर कन्वर्ज़न, नॉइज़िंग, शार्पिंग, और बहुत कुछ कंट्रोल शामिल हैं.

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

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

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

[C-0-1] अगर किसी ऐप्लिकेशन ने android.hardware.Camera.Parameters.setPreviewFormat(int) को कभी कॉल न किया हो, तो ऐप्लिकेशन कॉलबैक को दिए गए डेटा की झलक देखने के लिए, android.hardware.PixelFormat.YCbCr_420_SP का इस्तेमाल करना ज़रूरी है.
[C-0-2] जब कोई ऐप्लिकेशन किसी android.hardware.Camera.PreviewCallback इंस्टेंस को रजिस्टर करता है और सिस्टम, onPreviewFrame() तरीके को कॉल करता है, तो झलक का फ़ॉर्मैट YCbCr_420_SP NV21 एन्कोडिंग फ़ॉर्मैट में होना चाहिए. यह फ़ॉर्मैट, बाइट[] में मौजूद डेटा को onPreviewFrame() में पास किया जाता है. इसका मतलब है कि NV21 को डिफ़ॉल्ट तौर पर सेट करना ज़रूरी है.
[C-0-3] android.hardware.Camera के आगे और पीछे वाले, दोनों तरह के कैमरों में झलक देखने के लिए, YV12 फ़ॉर्मैट (जैसा कि android.graphics.ImageFormat.YV12 कॉन्सटेंट में बताया गया है) पर काम करना ज़रूरी है. (हार्डवेयर वीडियो एन्कोडर और कैमरा किसी भी नेटिव पिक्सल फ़ॉर्मैट का इस्तेमाल कर सकता है, लेकिन डिवाइस को YV12 में बदलने की सुविधा ज़रूर चालू की जानी चाहिए.)
[C-0-4] android.media.ImageReader एपीआई की मदद से, उन android.hardware.camera2 डिवाइसों के लिए आउटपुट के तौर पर android.hardware.ImageFormat.YUV_420_888 और android.hardware.ImageFormat.JPEG फ़ॉर्मैट के साथ काम करना ज़रूरी है जिनके लिए android.request.availableCapabilities में विज्ञापन दिखाने की सुविधा REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE है.
[C-0-5] Android SDK के दस्तावेज़ में शामिल पूरा कैमरा एपीआई लागू करना ज़रूरी है. भले ही, डिवाइस में हार्डवेयर ऑटोफ़ोकस या अन्य सुविधाएं शामिल हों. उदाहरण के लिए, जिन कैमरों में ऑटोफ़ोकस की सुविधा नहीं है उनमें रजिस्टर किए गए android.hardware.Camera.AutoFocusCallback इंस्टेंस को कॉल करना ज़रूरी है (भले ही, यह उन कैमरे से जुड़ा न हो जो ऑटोफ़ोकस नहीं हैं.) ध्यान दें कि यह, सामने वाले कैमरों पर लागू होता है. उदाहरण के लिए, भले ही सामने वाले ज़्यादातर कैमरे, ऑटोफ़ोकस के साथ काम नहीं करते हैं, लेकिन एपीआई कॉलबैक, बताए गए तरीके से "फ़ेक" होने चाहिए.
[C-0-6] android.hardware.Camera.Parameters क्लास और android.hardware.camera2.CaptureRequest क्लास में कॉन्सटेंट के तौर पर बताए गए हर पैरामीटर के नाम को पहचानना और उसका पालन करना ज़रूरी है. इसके उलट, डिवाइस लागू करने के तरीके को android.hardware.Camera.Parameters पर कॉन्सटेंट के तौर पर बताए गए तरीके के अलावा, android.hardware.Camera.setParameters() तरीके में पास किए गए स्ट्रिंग कॉन्सटेंट के मुताबिक नहीं होना चाहिए और न ही उनकी पहचान करनी चाहिए. इसका मतलब है कि अगर हार्डवेयर अनुमति देता है, तो डिवाइस को लागू करने के लिए सभी स्टैंडर्ड कैमरा पैरामीटर के साथ काम करना ज़रूरी है. साथ ही, कस्टम कैमरा पैरामीटर के साथ भी काम नहीं करना चाहिए. उदाहरण के लिए, कुछ डिवाइसों में हाई डाइनैमिक रेंज (एचडीआर) इमेजिंग तकनीकों का इस्तेमाल करके इमेज कैप्चर करने की सुविधा होना ज़रूरी है. ऐसे डिवाइसों पर, कैमरा पैरामीटर Camera.SCENE_MODE_HDR के साथ काम करना ज़रूरी है.
[C-0-7] android.info.supportedHardwareLevel प्रॉपर्टी की मदद करने के लिए, आपको Android SDK में बताए गए तरीके के हिसाब से सही लेवल की रिपोर्ट करनी होगी. साथ ही, सही फ़्रेमवर्क सुविधाओं के फ़्लैग की शिकायत करनी होगी.
[C-0-8] को android.request.availableCapabilities प्रॉपर्टी की मदद से, android.hardware.camera2 की अलग-अलग कैमरे की क्षमताओं के बारे में भी बताना होगा. साथ ही, सही फ़ीचर फ़्लैग के बारे में भी बताना होगा. अगर अटैच किया गया कोई कैमरा डिवाइस, सुविधा के साथ काम करता है, तो फ़ीचर फ़्लैग के बारे में बताना ज़रूरी है.
[C-0-9] जब भी कैमरा कोई नई तस्वीर खींचता है और मीडिया स्टोर में तस्वीर की एंट्री जोड़ी जाती है, तब Camera.ACTION_NEW_PICTURE को दिए गए मकसद को ब्रॉडकास्ट करना ज़रूरी है.
[C-0-10] जब भी कैमरा कोई नया वीडियो रिकॉर्ड करता है और मीडिया स्टोर में तस्वीर की एंट्री जोड़ी जाती है, तब Camera.ACTION_NEW_VIDEO के इंटेंट को ब्रॉडकास्ट करना ज़रूरी है.
[C-0-11] यह ज़रूरी है कि सभी कैमरे ऐसे हों जिन्हें बंद किए गए ऐप्लिकेशन से ऐक्सेस किया जा सके android.hardware.Camera एपीआई को android.hardware.camera2 एपीआई से भी ऐक्सेस किया जा सकता है.
[C-0-12] ध्यान रखें कि चेहरे के लुक में कोई बदलाव न किया गया हो. इसमें, android.hardware.camera2 या android.hardware.Camera एपीआई का इस्तेमाल करके, चेहरे की ज्यामिति, चेहरे की त्वचा या चेहरे की त्वचा को निखारना शामिल है. हालांकि, इसमें इनके अलावा, और भी चीज़ें शामिल हो सकती हैं.
[C-SR-1] एक ही दिशा में कई आरजीबी कैमरे वाले डिवाइसों के लिए, लॉजिकल कैमरा डिवाइस के साथ काम करने का सुझाव दिया जाता है. इस डिवाइस की क्षमता CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA होती है. इसमें फ़िज़िकल सब-डिवाइसों के तौर पर उस दिशा में लगे सभी आरजीबी कैमरे शामिल होते हैं.

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

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

7.5.5. कैमरा ओरिएंटेशन

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

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

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

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

7.6. डिवाइस की मेमोरी और स्टोरेज

7.6.1. कम से कम मेमोरी और स्टोरेज

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

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

7.6.2. ऐप्लिकेशन का शेयर किया गया स्टोरेज

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

[C-0-1] ऐप्लिकेशन में शेयर किया जाने वाला स्टोरेज ज़रूर ऑफ़र करना चाहिए. इसे अक्सर "शेयर किया गया एक्सटर्नल स्टोरेज", "ऐप्लिकेशन का शेयर किया गया स्टोरेज" या Linux पाथ "/sdcard" से माउंट किया जाता है.
[C-0-2] 'शेयर किए गए स्टोरेज' को इस तरह कॉन्फ़िगर करना ज़रूरी है कि वह डिफ़ॉल्ट रूप से, दूसरे शब्दों में "अलग-अलग" शब्दों में माउंट किया गया हो. भले ही, स्टोरेज को डिवाइस के स्टोरेज कॉम्पोनेंट में इस्तेमाल किया गया हो या हटाए जाने वाले स्टोरेज मीडियम (जैसे, सुरक्षित डिजिटल कार्ड स्लॉट).
[C-0-3] ऐप्लिकेशन के शेयर किए गए स्टोरेज को सीधे Linux पाथ पर माउंट करना ज़रूरी है sdcard या sdcard से लेकर असल माउंट पॉइंट पर Linux का सिंबल वाला लिंक शामिल करें.
[C-0-4] एपीआई लेवल 29 या उसके बाद के वर्शन को टारगेट करने वाले सभी ऐप्लिकेशन के लिए, डिफ़ॉल्ट रूप से स्कोप वाला स्टोरेज चालू करना ज़रूरी है. हालांकि, इन स्थितियों में यह सुविधा काम नहीं करती:
- जब ऐप्लिकेशन ने अपने मेनिफ़ेस्ट में android:requestLegacyExternalStorage="true" का अनुरोध किया हो.
[C-0-5] मीडिया फ़ाइलों को MediaStore के ज़रिए ऐक्सेस किए जाने पर, जीपीएस Exif टैग जैसे जगह के मेटाडेटा को छिपाने के लिए उसमें बदलाव करना ज़रूरी है. ऐसा सिर्फ़ तब करना चाहिए, जब कॉल करने वाले ऐप्लिकेशन के पास ACCESS_MEDIA_LOCATION की अनुमति हो.

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

डिवाइस का हटाया जा सकने वाला स्टोरेज, जैसे कि सिक्योर डिजिटल (एसडी) कार्ड स्लॉट.
इंटरनल (हटाई नहीं जा सकने वाली) स्टोरेज का एक हिस्सा, जैसा कि Android ओपन सोर्स प्रोजेक्ट (एओएसपी) में लागू किया गया है.

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

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

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

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

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

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

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

यह बताए गए Android MTP होस्ट, Android File Transfer के साथ काम करना चाहिए.
0x00 की यूएसबी डिवाइस क्लास की रिपोर्ट करनी चाहिए.
'MTP' के USB इंटरफ़ेस का नाम रिपोर्ट करना चाहिए.

7.6.3. डिवाइस का स्टोरेज

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

[C-SR-1] लंबे समय तक स्थिर जगह में रखने का सुझाव दिया जाता है, क्योंकि इस सुविधा को गलती से डिसकनेक्ट करने से डेटा मिट सकता है या खराब हो सकता है.

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

[C-SR-2] डिवाइस के हिसाब से स्टोरेज को लागू करने का सुझाव दिया जाता है.

7.7. यूएसबी

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

यूएसबी सहायक डिवाइस (जैसे, कीबोर्ड, माउस, मॉनिटर, वेबकैम वगैरह) पर काम करना चाहिए. साथ ही, यूएसबी होस्ट मोड भी काम करना चाहिए.
USB पर डेटा सिग्नलिंग अक्षम करने का समर्थन करना चाहिए.

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

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

[C-1-1] पोर्ट को ऐसे यूएसबी होस्ट से कनेक्ट करना ज़रूरी है जिसमें स्टैंडर्ड टाइप-ए या टाइप-सी यूएसबी पोर्ट हो.
[C-1-2] यूएसबी स्टैंडर्ड डिवाइस डिस्क्रिप्टर में android.os.Build.SERIAL की मदद से, iSerialNumber की सही वैल्यू की रिपोर्ट करना ज़रूरी है.
[C-1-3] टाइप-सी रेज़िस्टर स्टैंडर्ड के हिसाब से, 1.5A और 3.0A चार्जर का पता लगाना ज़रूरी है. साथ ही, अगर विज्ञापन में टाइप-सी यूएसबी का इस्तेमाल किया जा सकता है, तो उन्हें विज्ञापन में होने वाले बदलावों का पता लगाना चाहिए.
[C-SR-1] पोर्ट में माइक्रो-B, माइक्रो-एबी या टाइप-सी यूएसबी के नाप या आकार का इस्तेमाल किया जाना चाहिए. मौजूदा और नए Android डिवाइसों को इन शर्तों को पूरा करने का सुझाव दिया जाता है, ताकि उन्हें आने वाले प्लैटफ़ॉर्म की रिलीज़ पर अपग्रेड किया जा सके.
[C-SR-2] पोर्ट को डिवाइस के नीचे होना चाहिए (नैचुरल ओरिएंटेशन के मुताबिक) या सभी ऐप्लिकेशन (होम स्क्रीन सहित) के लिए सॉफ़्टवेयर स्क्रीन घुमाने की सुविधा चालू करनी चाहिए, ताकि डिवाइस के नीचे मौजूद पोर्ट के हिसाब से डिसप्ले सही तरीके से दिखे. मौजूदा और नए Android डिवाइसों को इन शर्तों को पूरा करने का सुझाव दिया जाता है, ताकि वे आने वाले प्लैटफ़ॉर्म की रिलीज़ पर अपग्रेड कर सकें.
[C-SR-3] एचएस चिरप और यूएसबी बैटरी चार्जिंग स्पेसिफ़िकेशन, बदलाव 1.2 में बताए गए के मुताबिक 1.5 एक करंट को ड्रॉ करने के लिए समर्थन लागू करना चाहिए. मौजूदा और नए Android डिवाइसों को इन शर्तों को पूरा करने का सुझाव दिया जाता है, ताकि उन्हें आने वाले प्लैटफ़ॉर्म की रिलीज़ पर अपग्रेड किया जा सके.
[C-SR-4] इस बात की बहुत ज़्यादा सलाह दी जाती है कि वह मालिकाना हक वाली चार्जिंग के तरीकों का इस्तेमाल न करे जो डिफ़ॉल्ट लेवल से आगे जाकर VBS वोल्टेज में बदलाव करते हैं. इसके अलावा, सिंक/सोर्स भूमिकाओं में बदलाव करने से, उन चार्जर या डिवाइसों के साथ इंटरऑपरेबिलिटी (दूसरे सिस्टम के साथ काम करना) में समस्याएं आ सकती हैं जो यूएसबी पावर डिलीवरी के मानक तरीकों के साथ काम करते हैं. इसे "बहुत ज़्यादा सुझाया गया" कहा जाता है. आने वाले समय में Android के आने वाले वर्शन में, सभी टाइप-सी वाले डिवाइसों की ज़रूरत हो सकती है, ताकि वे स्टैंडर्ड टाइप-सी चार्जर के साथ पूरी तरह से इंटरऑपरेबिलिटी (दूसरे सिस्टम के साथ काम करना) की सुविधा का इस्तेमाल कर सकें.
[C-SR-5] टाइप-सी यूएसबी और यूएसबी होस्ट मोड के साथ काम करने पर डेटा और पावर रोल बदलने के लिए, इस सुविधा का बहुत ज़्यादा सुझाव दिया जाता है.
हाई-वोल्टेज चार्जिंग के लिए, पावर डिलीवरी की सुविधा होनी चाहिए. साथ ही, डिसप्ले आउट जैसे दूसरे मोड के लिए भी सहायता मिल सकती है.
Android SDK के दस्तावेज़ में बताए गए, Android Open Accessory (AOA) एपीआई और उससे जुड़ी खास बातों को लागू करना चाहिए.

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

[C-2-1] यह एलान करना ज़रूरी है कि यह हार्डवेयर सुविधा android.hardware.usb.accessory पर काम करता है.
[C-2-2] यूएसबी मास स्टोरेज क्लास के इंटरफ़ेस में, ब्यौरे के आखिर में "android" स्ट्रिंग शामिल होनी चाहिए. यूएसबी मास स्टोरेज के iInterface स्ट्रिंग में

7.7.2. यूएसबी होस्ट मोड

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

[C-1-1] जैसा कि Android SDK टूल में बताया गया है, Android यूएसबी होस्ट एपीआई को लागू करना ज़रूरी है. साथ ही, यह एलान करना ज़रूरी है कि यह हार्डवेयर सुविधा android.hardware.usb.host पर काम करता है.
[C-1-2] स्टैंडर्ड यूएसबी सहायक डिवाइसों को कनेक्ट करने के लिए, इस सुविधा को लागू करना ज़रूरी है. दूसरे शब्दों में कहें, तो:
- उपयोगकर्ता के डिवाइस पर टाइप सी पोर्ट का इस्तेमाल करें या फिर केबल की मदद से, डिवाइस के मालिकाना हक वाले पोर्ट को स्टैंडर्ड यूएसबी टाइप-सी पोर्ट (यूएसबी टाइप-सी डिवाइस) में बदलें.
- डिवाइस में पहले से टाइप A का इस्तेमाल करें या फिर केबल की मदद से, डिवाइस के मालिकाना हक वाले पोर्ट को स्टैंडर्ड यूएसबी टाइप-ए पोर्ट में बदलें.
- डिवाइस में एक माइक्रो-एबी पोर्ट होना चाहिए, जो स्टैंडर्ड टाइप-ए पोर्ट में बदलने वाली केबल के साथ शिप हो.
[C-1-3] इसे ऐसे अडैप्टर से नहीं भेजा जाना चाहिए जो यूएसबी टाइप A या माइक्रो-एबी पोर्ट से टाइप-सी पोर्ट (रिसेप्टेकल) में बदल रहा हो.
[C-SR-1] Android SDK के दस्तावेज़ के मुताबिक, यूएसबी ऑडियो क्लास को लागू करने का सुझाव दिया जाता है.
होस्ट मोड में, कनेक्ट किए गए यूएसबी सहायक डिवाइस को चार्ज करना होगा. यूएसबी टाइप-सी केबल और कनेक्टर स्पेसिफ़िकेशन रिवीज़न 1.2 में दिए गए, खत्म होने के पैरामीटर सेक्शन में दिए गए, कम से कम 1.5A के सोर्स का विज्ञापन करना होगा. इसके अलावा, यूएसबी बैटरी चार्जिंग से जुड़ी जानकारी में बताए गए, चार्जिंग डाउनस्ट्रीम पोर्ट(सीडीपी) आउटपुट की मौजूदा रेंज का इस्तेमाल करना होगा.
यूएसबी टाइप-सी स्टैंडर्ड लागू करना चाहिए और उनका इस्तेमाल करना चाहिए.

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

[C-2-1] यूएसबी एचआईडी क्लास के साथ काम करना ज़रूरी है.
[C-2-2] यूएसबी एचआईडी के इस्तेमाल की टेबल और वॉइस कमांड के इस्तेमाल से जुड़े अनुरोध में बताए गए इन एचआईडी डेटा फ़ील्ड की पहचान करने और उन्हें मैप करने की सुविधा ज़रूरी है. इनके लिए, KeyEvent को इस्तेमाल करने का तरीका नीचे बताया गया है:
- इस्तेमाल पेज (0xC) इस्तेमाल आईडी (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
- इस्तेमाल पेज (0xC) इस्तेमाल आईडी (0x0E9): KEYCODE_VOLUME_UP
- इस्तेमाल पेज (0xC) इस्तेमाल आईडी (0x0EA): KEYCODE_VOLUME_DOWN
- इस्तेमाल पेज (0xC) इस्तेमाल आईडी (0x0CF): KEYCODE_VOICE_ASSIST

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

[C-3-1] रिमोट तरीके से कनेक्ट किए गए किसी भी MTP (मीडिया ट्रांसफ़र प्रोटोकॉल) डिवाइसों की पहचान करना ज़रूरी है. साथ ही, ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, और ACTION_CREATE_DOCUMENT इंटेंट की मदद से उनके कॉन्टेंट को ऐक्सेस करना ज़रूरी है. .

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

[C-4-1] 'ड्यूअल रोल पोर्ट' फ़ंक्शन को लागू करना ज़रूरी है, जैसा कि यूएसबी टाइप-सी स्पेसिफ़िकेशन (सेक्शन 4.5.1.3.3) में बताया गया है. ड्यूअल रोल पोर्ट के लिए, 3.5 मि॰मी॰ का ऑडियो जैक वाले डिवाइसों पर, यूएसबी सिंक की पहचान करने वाला (होस्ट मोड) डिफ़ॉल्ट रूप से बंद हो सकता है. हालांकि, लोगों के लिए इसे चालू करना मुमकिन होना ज़रूरी है.
[C-SR-2] DisplayPort के साथ काम करने के लिए इसका बहुत ज़्यादा सुझाव दिया जाता है. साथ ही, यूएसबी सुपरस्पीड डेटा रेट के साथ काम करना चाहिए. साथ ही, डेटा और पावर रोल स्वैप करने के लिए, इसके इस्तेमाल का सुझाव दिया जाता है.
[C-SR-3] इस बात का खास तौर पर सुझाव दिया जाता है कि ऑडियो अडैप्टर ऐक्सेसरी मोड के साथ काम न किया जाए, जैसा कि यूएसबी टाइप-सी केबल और कनेक्टर की खास बातों के बदलाव 1.2 में अपेंडिक्स A में बताया गया है.
इसके लिए, ट्राइ.* मॉडल का इस्तेमाल किया जाना चाहिए. यह मॉडल, डिवाइस के नाप या आकार के हिसाब से सबसे सही है. उदाहरण के लिए, हैंडहेल्ड डिवाइस आज़माने के लिए SNK मॉडल लागू करना चाहिए.

7.8. ऑडियो

7.8.1. माइक्रोफ़ोन

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

[C-1-1] android.hardware.microphone सुविधा के कॉन्स्टेंट की जानकारी देना ज़रूरी है.
[C-1-2] सेक्शन 5.4 में दी गई ऑडियो रिकॉर्डिंग की ज़रूरी शर्तों को पूरा करना ज़रूरी है.
[C-1-3] सेक्शन 5.6 में, ऑडियो के इंतज़ार का समय तय करने से जुड़ी ज़रूरी शर्तों को पूरा करना ज़रूरी है.
[C-SR-1] का बहुत ज़्यादा सुझाव दिया जाता है, ताकि सेक्शन 7.8.3 में बताई गई नियर-अल्ट्रासाउंड रिकॉर्डिंग में मदद मिल सके.

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

[C-2-1] android.hardware.microphone सुविधा के कॉन्स्टेंट की रिपोर्ट नहीं देनी चाहिए.
[C-2-2] सेक्शन 7 के मुताबिक, ऑडियो रिकॉर्डिंग एपीआई को कम से कम नो-ऑप के तौर पर लागू करना ज़रूरी है.

7.8.2. ऑडियो आउटपुट

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

[C-1-1] android.hardware.audio.output सुविधा के कॉन्स्टेंट की जानकारी देना ज़रूरी है.
[C-1-2] सेक्शन 5.5 में दी गई ऑडियो प्लेबैक की ज़रूरी शर्तों को पूरा करना ज़रूरी है.
[C-1-3] सेक्शन 5.6 में, ऑडियो के इंतज़ार का समय तय करने से जुड़ी ज़रूरी शर्तों को पूरा करना ज़रूरी है.
[C-SR-1] सेक्शन 7.8.3 में दी गई जानकारी के मुताबिक, नियर-अल्ट्रासाउंड प्लेबैक की सुविधा देने के लिए इसका सुझाव दिया जाता है.

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

[C-2-1] android.hardware.audio.output सुविधा की शिकायत नहीं करनी चाहिए.
[C-2-2] ऑडियो आउटपुट से जुड़े एपीआई को, कम से कम नो-ऑपरेशन के तौर पर लागू करना ज़रूरी है.

इस सेक्शन में, "आउटपुट पोर्ट" एक फ़िज़िकल इंटरफ़ेस है. जैसे, 3.5 मि॰मी॰ का ऑडियो जैक, एचडीएमआई या यूएसबी ऑडियो क्लास वाला यूएसबी होस्ट मोड पोर्ट. ब्लूटूथ, वाई-फ़ाई या मोबाइल नेटवर्क जैसे रेडियो-आधारित प्रोटोकॉल पर ऑडियो आउटपुट के लिए, "आउटपुट पोर्ट" शामिल नहीं किया जा सकता.

7.8.2.1. ऐनालॉग ऑडियो पोर्ट

अगर डिवाइस में एक या एक से ज़्यादा ऐनालॉग ऑडियो पोर्ट शामिल हैं, तो Android नेटवर्क में 3.5 मि॰मी॰ के ऑडियो प्लग का इस्तेमाल करके हेडसेट और दूसरी ऑडियो ऐक्सेसरी के साथ काम करने के लिए:

[C-SR-1] चार कंडक्टर 3.5 मि॰मी॰ का ऑडियो जैक बनाने के लिए, कम से कम एक ऑडियो पोर्ट को शामिल करने का सुझाव दिया जाता है.

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

[C-1-1] माइक्रोफ़ोन वाले स्टीरियो हेडफ़ोन और स्टीरियो हेडसेट पर ऑडियो चलाया जा सकता हो.
[C-1-2] सीटीआईए पिन-आउट ऑर्डर के साथ, टीआरआरएस के ऑडियो प्लग के साथ काम करना ज़रूरी है.
[C-1-3] ऑडियो प्लग पर माइक्रोफ़ोन और ग्राउंड कंडक्टर के बीच, नीचे दी गई तीन रेंज में से एक के बाद एक, कीकोड की पहचान और मैपिंग की जा सकती है:
- 70 ओम या उससे कम: KEYCODE_HEADSETHOOK
- 210-290 ओम: KEYCODE_VOLUME_UP
- 360-680 ओम: KEYCODE_VOLUME_DOWN
[C-1-4] प्लग इन्स डालने पर, ACTION_HEADSET_PLUG को ट्रिगर करना ज़रूरी है. हालांकि, प्लग पर मौजूद सभी संपर्क, जैक पर अपने ज़रूरी सेगमेंट को छू रहे होंगे.
[C-1-5] 32 ओम वाले स्पीकर प्रतिरोध पर कम से कम 150mV ± 10% आउटपुट वोल्टेज तक चलाने में सक्षम होना चाहिए.
[C-1-6] माइक्रोफ़ोन बायस वोल्टेज 1.8V ~ 2.9V के बीच होना चाहिए.
[C-1-7] ऑडियो प्लग पर माइक्रोफ़ोन और ग्राउंड कंडक्टर के बीच नीचे बताई गई सीमा के हिसाब से, कीकोड का पता लगाकर उसे मैप करना ज़रूरी है:
- 110-180 ओम: KEYCODE_VOICE_ASSIST
[C-SR-2] ओएमटीपी को पिन-आउट करने के क्रम में ऑडियो प्लग के साथ काम करने के लिए, इस बात का खास तौर पर सुझाव दिया जाता है.
[C-SR-3] माइक्रोफ़ोन के साथ स्टीरियो हेडसेट से ऑडियो रिकॉर्डिंग का समर्थन करने के लिए विशेष रूप से सुझाया जाता है.

अगर डिवाइस को लागू करने के लिए 4 कंडक्टर 3.5 मि॰मी॰ का ऑडियो जैक है और वह माइक्रोफ़ोन पर काम करता है और android.intent.action.HEADSET_PLUG को माइक्रोफ़ोन की अतिरिक्त वैल्यू के साथ 1 पर सेट करता है, तो वे:

[C-2-1] ज़रूरी है कि प्लग-इन की गई ऑडियो ऐक्सेसरी पर माइक्रोफ़ोन की पहचान की जा सके.

7.8.2.2. डिजिटल ऑडियो पोर्ट

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

7.8.3. नियर-अल्ट्रासाउंड

नियर-अल्ट्रासाउंड ऑडियो का बैंडविथ 18.5 किलोहर्ट्ज़ से 20 किलोहर्ट्ज़ का बैंड होता है.

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

इस तरह से, ऑडियो मैनेजर.गेटप्रॉपर्टी एपीआई के ज़रिए, करीब-करीब अल्ट्रासाउंड ऑडियो क्षमता की रिपोर्ट सही तरीके से रिपोर्ट करनी चाहिए:

अगर PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND की वैल्यू "सही" है, तो VOICE_RECOGNITION और UNPROCESSED ऑडियो सोर्स को इन ज़रूरी शर्तों को पूरा करना होगा:

[C-1-1] 18.5 किलोहर्ट्ज़ से 20 किलोहर्ट्ज़ के बैंड में माइक्रोफ़ोन का औसत पावर रिस्पॉन्स 2 किलोहर्ट्ज़ पर जवाब के रूप में 15 dB से ज़्यादा नहीं होना चाहिए.
[C-1-2] -26 डीबीएफ़एस पर 19 किलोहर्ट्ज़ के टोन के लिए, माइक्रोफ़ोन का नॉइज़ रेशियो 18.5 किलोहर्ट्ज़ से 20 किलोहर्ट्ज़ से ज़्यादा का नहीं होना चाहिए. यह सिग्नल 50 डीबीएफ़एस से कम नहीं होना चाहिए.

अगर PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND "सही है", तो:

[C-2-1] 18.5 किलोहर्ट्ज़ से 20 किलोहर्ट्ज़ में स्पीकर की औसत प्रतिक्रिया, 2 किलोहर्ट्ज़ पर प्रतिक्रिया के समय से 40 dB से कम नहीं होनी चाहिए.

7.8.4. सिग्नल की सुरक्षा

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

हैंडहेल्ड डिवाइसों पर इनपुट और आउटपुट स्ट्रीम, दोनों के लिए कोई ग्लिच-फ़्री ऑडियो सिग्नल पाथ देना चाहिए. इसका मतलब है कि हर पाथ के लिए एक मिनट की जांच के दौरान कोई ग्लिच नहीं मिला. OboeTester “ऑटोमेटेड Glitch टेस्ट” का इस्तेमाल करके टेस्ट करें.

इस जांच के लिए ऑडियो लूपबैक डोंगल की ज़रूरत होती है. इसे सीधे 3.5 मि॰मी॰ जैक में इस्तेमाल किया जाता है और/या इसे यूएसबी-सी से 3.5 मि॰मी॰ अडैप्टर के साथ इस्तेमाल किया जाता है. सभी ऑडियो आउटपुट पोर्ट की जांच की जानी चाहिए.

फ़िलहाल, OboeTester ऑडियो पाथ के साथ काम करता है. इसलिए, AAudio का इस्तेमाल करके, ग्लिच के लिए यहां दिए गए कॉम्बिनेशन की जांच की जानी चाहिए:

परफ़ॉर्मेंस मोड	शेयर करें	आउट सैंपल रेट	इन चांस	आउट चांस
LOW_LATENCY	खास	जानकारी उपलब्ध नहीं है	1	2
LOW_LATENCY	खास	जानकारी उपलब्ध नहीं है	2	1
LOW_LATENCY	शेयर किया गया	जानकारी उपलब्ध नहीं है	1	2
LOW_LATENCY	शेयर किया गया	जानकारी उपलब्ध नहीं है	2	1
कोई नहीं	शेयर किया गया	48000	1	2
कोई नहीं	शेयर किया गया	48000	2	1
कोई नहीं	शेयर किया गया	44100	1	2
कोई नहीं	शेयर किया गया	44100	2	1
कोई नहीं	शेयर किया गया	16000	1	2
कोई नहीं	शेयर किया गया	16000	2	1

एक भरोसेमंद स्ट्रीम को 2,000 हर्ट्ज़ सिन के लिए सिग्नल से शोर का अनुपात (एसएनआर) और टोटल हार्मोनिक डिस्टॉर्शन (टीएचडी) के लिए, इन शर्तों को पूरा करना चाहिए.

ट्रांसड्यूसर	बात	एसएनआर
पहले से मौजूद प्राइमरी स्पीकर, जिसे बाहरी रेफ़रंस माइक्रोफ़ोन की मदद से मापा गया है	3.0% से कम	>= 50 डीबी
प्राइमरी बिल्ट-इन माइक्रोफ़ोन, जिसे बाहरी रेफ़रंस स्पीकर की मदद से मापा जाता है	3.0% से कम	>= 50 डीबी
पहले से मौजूद ऐनालॉग 3.5 मि॰मी॰ जैक, जिन्हें लूपबैक अडैप्टर का इस्तेमाल करके टेस्ट किया गया	< 1%	60 डीबी से ज़्यादा
फ़ोन के साथ दिए गए यूएसबी अडैप्टर, जिन्हें लूपबैक अडैप्टर का इस्तेमाल करके टेस्ट किया गया है	1.0% से कम	60 डीबी से ज़्यादा

7.9. आभासी वास्तविकता

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

7.9.1. वर्चुअल रिएलिटी मोड

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

7.9.2. वर्चुअल रिएलिटी मोड - बेहतर परफ़ॉर्मेंस

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

[C-1-1] कम से कम दो फ़िज़िकल कोर होने चाहिए.
[C-1-2] android.hardware.vr.high_performance सुविधा के बारे में एलान करना ज़रूरी है.
[C-1-3] स्थायी परफ़ॉर्मेंस मोड के साथ काम करना ज़रूरी है.
[C-1-4] OpenGL ES 3.2 के साथ काम करना ज़रूरी है.
[C-1-5] android.hardware.vulkan.level 0 के साथ काम करना ज़रूरी है.
android.hardware.vulkan.level 1 या इसके बाद के वर्शन के साथ काम करना चाहिए.
[C-1-6] EGL_KHR_mutable_render_buffer, EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_get_native_client_buffer, EGL_KHR_fence_sync, EGL_KHR_wait_sync, EGL_IMG_context_priority, EGL_EXT_protected_content, EGL_EXT_image_gl_colorspace को लागू करना होगा और एक्सटेंशन को उपलब्ध एक्सटेंशन की सूची में दिखाना होगा.
[C-1-8] GL_EXT_multisampled_render_to_texture2, GL_OVR_multiview, GL_OVR_multiview2, GL_EXT_protected_textures को लागू करना ज़रूरी है. साथ ही, एक्सटेंशन को उपलब्ध जीएल एक्सटेंशन की सूची में दिखाना ज़रूरी है.
[C-SR-1] GL_EXT_external_buffer, GL_EXT_EGL_image_array, GL_OVR_multiview_multisampled_render_to_texture, और इन एक्सटेंशन को उपलब्ध जीएल एक्सटेंशन की सूची में लागू करने के लिए, इसका बहुत ज़्यादा सुझाव दिया जाता है.
[C-SR-2] Vulkan 1.1 के साथ काम करने के लिए, इस बात का खास तौर पर सुझाव दिया जाता है.
[C-SR-3] VK_ANDROID_external_memory_android_hardware_buffer, VK_GOOGLE_display_timing, VK_KHR_shared_presentable_image, और इसे Vulkan एक्सटेंशन की सूची में शामिल करने का सुझाव दिया जाता है.
[C-SR-4] आपको कम से कम एक Vulkan सूची वाली फ़ैमिली में शामिल करने का सुझाव दिया जाता है. इसमें flags में VK_QUEUE_GRAPHICS_BIT और VK_QUEUE_COMPUTE_BIT, और queueCount, दोनों की जानकारी कम से कम दो होनी चाहिए.
[C-1-7] जीपीयू और डिसप्ले के लिए, शेयर किए गए सामने वाले बफ़र का ऐक्सेस इस तरह सिंक होना चाहिए कि 60fps पर वीआर कॉन्टेंट की बारी-बारी से रेंडर होने की सुविधा के साथ, दो रेंडर किए गए कॉन्टेंट को दिखाया जाए.
[C-1-9] आपको AHardwareBuffer फ़्लैग AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA, और AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT के लिए काम करना होगा, जैसा कि एनडीके में बताया गया है.
[C-1-10] कम से कम इन फ़ॉर्मैट के लिए AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT के किसी भी कॉम्बिनेशन के साथ AHardwareBuffer का इस्तेमाल करना ज़रूरी है: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM,AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM,AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM,AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
[C-SR-5] का सुझाव दिया जाता है, ताकि C-1-10 में एक से ज़्यादा लेयर और फ़्लैग और फ़ॉर्मैट वाली AHardwareBuffer फ़ाइलें असाइन की जा सकें.
[C-1-11] 30fps पर कम से कम 3840 x 2160 H.264 को डिकोड करने की सुविधा होनी चाहिए, जो औसत 40 एमबीपीएस (30 एफ़पीएस-10 एमबीपीएस पर 1920 x1080 के चार इंस्टेंस के बराबर या 1920 x 60 एमबीपीएस 108 एफ़पीएस (फ़्रेम प्रति सेकंड) पर 2 इंस्टेंस के बराबर) हो.
[C-1-12] HEVC और VP9 के साथ काम करना ज़रूरी है. साथ ही, 10 एमबीपीएस के औसत कंप्रेस किए हुए 1920 x 1080 पर 30 FPS (फ़्रेम प्रति सेकंड) पर कम से कम 1920 x 1080 को डिकोड करने की क्षमता होनी चाहिए. साथ ही, 30
[C-1-13] HardwarePropertiesManager.getDeviceTemperatures API के साथ काम करना ज़रूरी है और त्वचा के तापमान की सटीक वैल्यू दिखाना चाहिए.
[C-1-14] इसमें एक स्क्रीन एम्बेड की गई होनी चाहिए और इसका रिज़ॉल्यूशन कम से कम 1920 x 1080 होना चाहिए.
[C-SR-6] का डिसप्ले रिज़ॉल्यूशन कम से कम 2560 x 1440 रखने का सुझाव दिया जाता है.
[C-1-15] VR मोड में होने पर, डिसप्ले को कम से कम 60 हर्ट्ज़ पर अपडेट करना ज़रूरी है.
[C-1-17] डिसप्ले पर लो-परसिस्टेंस मोड यानी 5 मिलीसेकंड तक का काम होना चाहिए. परसिस्टेंस का मतलब है कि एक पिक्सल से कितने समय तक रोशनी निकल रही है.
[C-1-18] ब्लूटूथ 4.2 और ब्लूटूथ LE डेटा की लंबाई वाले एक्सटेंशन के साथ काम करना ज़रूरी है सेक्शन 7.4.3.
[C-1-19] नीचे दिए गए सभी डिफ़ॉल्ट सेंसर टाइप के लिए, डायरेक्ट चैनल टाइप के साथ काम करना चाहिए और उन्हें इसकी सही तरीके से रिपोर्ट करनी चाहिए:
- TYPE_ACCELEROMETER
- TYPE_ACCELEROMETER_UNCALIBRATED
- TYPE_GYROSCOPE
- TYPE_GYROSCOPE_UNCALIBRATED
- TYPE_MAGNETIC_FIELD
- TYPE_MAGNETIC_FIELD_UNCALIBRATED
[C-SR-7] का सुझाव दिया जाता है कि ऊपर दिए गए सभी डायरेक्ट चैनल टाइप के लिए, TYPE_HARDWARE_BUFFER डायरेक्ट चैनल टाइप का इस्तेमाल किया जा सके.
[C-1-21] android.hardware.hifi_sensors के लिए जाइरोस्कोप, एक्सलरोमीटर, और मैग्नेटोमीटर से जुड़ी ज़रूरी शर्तों को पूरा करना ज़रूरी है. इसके बारे में सेक्शन 7.3.9 में बताया गया है.
[C-SR-8] का सुझाव दिया जाता है, ताकि android.hardware.sensor.hifi_sensors सुविधा के साथ काम किया जा सके.
[C-1-22] फ़ोटॉन के इंतज़ार के समय के लिए एंड-टू-एंड मोशन होना ज़रूरी है. यह मोशन 28 मिलीसेकंड से ज़्यादा नहीं होना चाहिए.
[C-SR-9] इस बात पर ज़ोर दिया जाता है कि फ़ोटॉन की इंतज़ार के समय पर एंड-टू-एंड मोशन हो, जो 20 मिलीसेकंड से ज़्यादा न हो.
[C-1-23] पहले फ़्रेम का अनुपात होना ज़रूरी है. यह काले से सफ़ेद रंग में ट्रांज़िशन के बाद, पहले फ़्रेम पर पिक्सल की चमक और स्थिर स्थिति में सफ़ेद पिक्सल की चमक के बीच का अनुपात होता है. यह अनुपात कम से कम 85% होना चाहिए.
[C-SR-10] के लिए, पहले फ़्रेम का अनुपात कम से कम 90% रखने का सुझाव दिया जाता है.
इसमें फ़ोरग्राउंड ऐप्लिकेशन के लिए एक खास कोर उपलब्ध कराया जा सकता है. साथ ही, Process.getExclusiveCores API की मदद से, सिर्फ़ सबसे ऊपर चलने वाले फ़ोरग्राउंड ऐप्लिकेशन के लिए इस्तेमाल होने वाले सीपीयू की संख्या दिखाई जा सकती है.

अगर खास कोर काम करता है, तो कोर:

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

7.10. हैप्टिक

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

7.11. मीडिया परफ़ॉर्मेंस क्लास

डिवाइस लागू करने की मीडिया परफ़ॉर्मेंस क्लास, android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS API से मिल सकती है. मीडिया परफ़ॉर्मेंस क्लास की ज़रूरी शर्तें R (वर्शन 30) से शुरू होने वाले हर Android वर्शन के लिए बताई गई हैं. 0 का खास वैल्यू यह बताता है कि डिवाइस, मीडिया परफ़ॉर्मेंस क्लास का नहीं है.

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

[C-1-1] आपको कम से कम android.os.Build.VERSION_CODES.R की वैल्यू देनी होगी.
[C-1-2] हैंडहेल्ड डिवाइस इस्तेमाल करना ज़रूरी है.
[C-1-3] "मीडिया परफ़ॉर्मेंस क्लास" की सभी ज़रूरी शर्तें पूरी करना ज़रूरी है. इन शर्तों के बारे में सेक्शन 2.2.7 में बताया गया है.

दूसरे शब्दों में कहें, तो Android T में मीडिया परफ़ॉर्मेंस क्लास को सिर्फ़ हैंडहेल्ड डिवाइसों पर T, S या R वर्शन के लिए तय किया जाता है.

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

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

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

8.1. उपयोगकर्ता अनुभव को लगातार बनाए रखना

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

8.2. फ़ाइल I/O ऐक्सेस की परफ़ॉर्मेंस

ऐप्लिकेशन के निजी डेटा स्टोरेज (/data पार्टिशन) पर, फ़ाइल के ऐक्सेस से जुड़े एक जैसे परफ़ॉर्मेंस के लिए एक समान बेसलाइन उपलब्ध कराने पर, ऐप्लिकेशन डेवलपर अपने सॉफ़्टवेयर डिज़ाइन के लिए ऐसी उम्मीद तय कर सकते हैं जिससे उन्हें ज़्यादा मदद मिलेगी. डिवाइस टाइप के आधार पर, डिवाइस लागू करने के लिए कुछ ज़रूरी शर्तें हो सकती हैं. इन ज़रूरी शर्तों के बारे में सेक्शन 2 में बताया गया है. इन शर्तों के बारे में, यहां दिए गए 'रीड ऐंड राइट' ऑपरेशन के बारे में बताया गया है:

क्रम से लिखने के लिए परफ़ॉर्मेंस. इसे 10 एमबी राइट बफ़र का इस्तेमाल करके, 256 एमबी की फ़ाइल लिखकर मापा जाता है.
रैंडम तरीके से लिखने की परफ़ॉर्मेंस. 4 केबी राइट बफ़र का इस्तेमाल करके 256 एमबी की फ़ाइल लिखकर मापा जाता है.
क्रम से पढ़ने की परफ़ॉर्मेंस. इसे 10 एमबी राइट बफ़र का इस्तेमाल करके, 256 एमबी की फ़ाइल को पढ़कर मापा जाता है.
किसी भी क्रम में पढ़ने की परफ़ॉर्मेंस. 4 केबी राइट बफ़र का इस्तेमाल करके, 256 एमबी की फ़ाइल को पढ़कर मापा जाता है.

8.3. पावर सेविंग मोड

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

[C-1-1] ट्रिगर करने, रखरखाव, वेकअप एल्गोरिदम, और ग्लोबल सिस्टम सेटिंग या ऐप्लिकेशन स्टैंडबाय और बैटरी बचाने वाले मोड के DeviceConfig के इस्तेमाल के लिए, एओएसपी लागू करने से अलग नहीं होना चाहिए.
[C-1-2] ऐप्लिकेशन स्टैंडबाय मोड के लिए, हर बकेट में ऐप्लिकेशन के लिए जॉब, अलार्म, और नेटवर्क की थ्रॉटलिंग को मैनेज करने के लिए, ग्लोबल सेटिंग या DeviceConfig का इस्तेमाल करने के लिए, एओएसपी को लागू करने से अलग नहीं होना चाहिए.
[C-1-3] ऐप्लिकेशन स्टैंडबाय के लिए इस्तेमाल किए जाने वाले ऐप्लिकेशन स्टैंडबाय बकेट की संख्या के लिए एओएसपी को लागू करने से अलग नहीं होना चाहिए.
[C-1-4] पावर मैनेजमेंट में बताए गए तरीके के मुताबिक, ऐप्लिकेशन स्टैंडबाय बकेट और डोज़ को लागू करना ज़रूरी है.
[C-1-5] डिवाइस को पावर सेव मोड पर होने पर, PowerManager.isPowerSaveMode() के लिए true दिखाना ज़रूरी है.
[C-1-6] उपयोगकर्ता को वे सभी ऐप्लिकेशन दिखाने की सुविधा देनी होगी जिन्हें ऐप्लिकेशन स्टैंडबाय और बैटरी बचाने वाले मोड या बैटरी ऑप्टिमाइज़ेशन के इस्तेमाल से छूट दी गई है. साथ ही, उपयोगकर्ता को ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS इंटेंट को लागू करना होगा.
[C-SR-1] बैटरी सेवर की सुविधा को चालू और बंद करने के लिए, लोगों को ज़रूरी अधिकार देने का सुझाव दिया जाता है.
[C-SR-2] इस बात का बहुत ज़्यादा सुझाव दिया जाता है कि उपयोगकर्ता को वे सभी ऐप्लिकेशन दिखाने का मौका दिया जाए जिन्हें ऐप्लिकेशन स्टैंडबाय और बैटरी बचाने वाले मोड से छूट दी गई है.

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

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

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

[C-1-1] इस स्थिति में डिवाइस को फिर से चालू करने (उदाहरण के लिए, लिड को खोलने या वाहन या टेलीविज़न को चालू करने) के बाद ही इस स्थिति में जाना चाहिए.

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

[C-2-1] ऊपर दिए गए C-1-1 से मेल खाना ज़रूरी है या S3 स्टेटस सिर्फ़ तब डालना होगा, जब तीसरे पक्ष के ऐप्लिकेशन को सिस्टम रिसॉर्स (जैसे कि स्क्रीन, सीपीयू) की ज़रूरत न हो.

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

उदाहरण के लिए, जब तीसरे पक्ष के ऐप्लिकेशन, FLAG_KEEP_SCREEN_ON से स्क्रीन चालू रखने या सीपीयू को PARTIAL_WAKE_LOCK तक चालू रखने का अनुरोध करते हैं, तो डिवाइस को S3 स्थिति में तब तक नहीं डालना चाहिए, जब तक कि C-1-1 में दी गई जानकारी के मुताबिक, उपयोगकर्ता ने डिवाइस को इनऐक्टिव स्थिति में डालने के लिए साफ़ तौर पर कोई कार्रवाई न की हो. वहीं, जब JobScheduler की मदद से तीसरे पक्ष के ऐप्लिकेशन लागू किया गया कोई टास्क ट्रिगर होता है या Firebase क्लाउड से मैसेज तीसरे पक्ष के ऐप्लिकेशन को डिलीवर किया जाता है, तो डिवाइस को S3 स्थिति से बाहर निकलना होगा. ऐसा तब करना होगा, जब उपयोगकर्ता ने डिवाइस को इनऐक्टिव स्थिति में न रखा हो. ये व्यापक उदाहरण नहीं हैं और एओएसपी, स्क्रीन चालू करने के बड़े सिग्नल लागू करता है, जो इस स्थिति से स्क्रीन को चालू करते हैं.

8.4. पावर कंज़म्पशन अकाउंटिंग

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

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

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

8.5. एक ही तरह की परफ़ॉर्मेंस

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

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

[C-0-1] PowerManager.isSustainedPerformanceModeSupported() एपीआई तरीके का इस्तेमाल करके, लगातार परफ़ॉर्मेंस बनाए रखने वाले मोड के साथ काम करने की सटीक जानकारी देना ज़रूरी है.
इसमें लगातार परफ़ॉर्मेंस को बनाए रखने वाला मोड भी काम करना चाहिए.

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

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

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

कम से कम एक ऐसा खास कोर होना चाहिए जिसे टॉप फ़ोरग्राउंड ऐप्लिकेशन में रिज़र्व किया जा सके.

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

[C-2-1] Process.getExclusiveCores() एपीआई तरीके का इस्तेमाल करके, उन खास कोर के आईडी नंबर को रिपोर्ट करना ज़रूरी है जिन्हें सबसे ऊपर दिखने वाले ऐप्लिकेशन के ज़रिए रिज़र्व किया जा सकता है.
[C-2-2] खास कोर पर चलाने के लिए ऐप्लिकेशन में इस्तेमाल किए गए डिवाइस ड्राइवर के अलावा किसी उपयोगकर्ता स्पेस की प्रोसेस को अनुमति नहीं देनी चाहिए, लेकिन हो सकता है कि कुछ कर्नेल प्रोसेस को ज़रूरत के हिसाब से चलने की अनुमति दी जाए.

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

[C-3-1] Process.getExclusiveCores() एपीआई वाले तरीके का इस्तेमाल करके, आपको एक खाली सूची देनी होगी.

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

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

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

अगर लागू किए गए डिवाइस पर android.hardware.security.model.compatible सुविधा का एलान किया जाता है, तो:

[C-1-1] ज़रूरी है कि वह इन सब-सेक्शन में बताई गई ज़रूरी शर्तों को पूरा करता हो.

9.1. अनुमतियां

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

[C-0-1] Android डेवलपर के दस्तावेज़ में दिए गए Android अनुमतियों के मॉडल और Android Roles मॉडल के साथ काम करना ज़रूरी है. खास तौर पर, उनके लिए SDK टूल के दस्तावेज़ में बताई गई हर अनुमति और भूमिका को लागू करना होगा. किसी अनुमति या भूमिका को छोड़ा, बदला या अनदेखा नहीं किया जा सकता.
अतिरिक्त अनुमतियां जोड़ी जा सकती हैं, बशर्ते अनुमति आईडी की नई स्ट्रिंग android.\* नेमस्पेस में न हों.
[C-0-2] PROTECTION_FLAG_PRIVILEGED के protectionLevel वाली अनुमतियां, सिर्फ़ उन ऐप्लिकेशन को दी जानी चाहिए जो सिस्टम इमेज के खास पाथ (और साथ ही APEX फ़ाइलें) में पहले से इंस्टॉल हैं. साथ ही, उन्हें हर ऐप्लिकेशन के लिए, साफ़ तौर पर अनुमति वाली अनुमतियों के सबसेट में शामिल किया जाना चाहिए. एओएसपी को लागू करने के लिए, यह ज़रूरी शर्त पूरी करनी होगी.etc/permissions/system/priv-app

रनटाइम में उपयोगकर्ताओं को मिलने वाली अनुमतियां वे होती हैं जिनमें सुरक्षा के लेवल खतरनाक के तौर पर मार्क किया गया हो. targetSdkVersion > 22 वाले ऐप्लिकेशन, रनटाइम के दौरान इनका अनुरोध करते हैं.

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

[C-0-3] उपयोगकर्ता को एक खास इंटरफ़ेस दिखाना होगा, ताकि यह तय किया जा सके कि अनुरोध की गई रनटाइम की अनुमतियां देनी हैं या नहीं. साथ ही, उपयोगकर्ता को रनटाइम की अनुमतियां मैनेज करने के लिए इंटरफ़ेस भी देना होगा.
[C-0-4] दोनों यूज़र इंटरफ़ेस को एक ही बार लागू करना ज़रूरी है. अगर डिवाइस को लागू करने के लिए, किसी साथी डिवाइस का इस्तेमाल किया जा सकता है, तो साथी डिवाइस से कोई दूसरा इंटरफ़ेस मिल सकता है.
[C-0-5] ऐप्लिकेशन को रनटाइम की अनुमति तब तक नहीं देनी चाहिए, जब तक:
- डिवाइस शिपमेंट के समय इंस्टॉल किए जाते हैं और
- ऐप्लिकेशन, अनुमति का इस्तेमाल करे, इससे पहले उपयोगकर्ता की सहमति ली जा सकती है,
  
  या
- रनटाइम की अनुमतियां, अनुमति देने की डिफ़ॉल्ट नीति के तहत या प्लैटफ़ॉर्म की भूमिका को होल्ड करने के लिए दी जाती हैं.
[C-0-6] सिर्फ़ उन सिस्टम ऐप्लिकेशन को android.permission.RECOVER_KEYSTORE की अनुमति देनी होगी जिन्होंने ठीक से सुरक्षित रिकवरी एजेंट रजिस्टर किया है. पूरी तरह से सुरक्षित रिकवरी एजेंट को डिवाइस में मौजूद ऐसा सॉफ़्टवेयर एजेंट कहा जाता है जो डिवाइस की ऑफ़-डिवाइस रिमोट स्टोरेज के साथ सिंक होता है. इसमें ऐसे सुरक्षित हार्डवेयर होते हैं जिनकी सुरक्षा, Google Cloud Key Vault सेवा में बताई गई सुरक्षा के बराबर या उससे ज़्यादा होती है. ऐसा इसलिए किया जाता है, ताकि लॉकस्क्रीन के नॉलेज फ़ैक्टर पर ज़बरदस्ती हमले को रोका जा सके.

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

[C-0-7] जब कोई ऐप्लिकेशन स्टैंडर्ड Android API या मालिकाना हक के तरीके से जगह की जानकारी या शारीरिक गतिविधि के डेटा का अनुरोध करता है, तो Android पर जगह की जानकारी की अनुमति वाली प्रॉपर्टी का पालन करना ज़रूरी है. ऐसे डेटा में ये शामिल हैं, लेकिन इनके अलावा और भी चीज़ें शामिल हो सकती हैं:
- डिवाइस की जगह की जानकारी (जैसे कि अक्षांश और देशांतर) जैसा कि सेक्शन 9.8.8 में बताया गया है.
- ऐसी जानकारी जिसका इस्तेमाल डिवाइस की जगह की जानकारी का पता लगाने या उसका अनुमान लगाने के लिए किया जा सकता है. उदाहरण के लिए, SSID, BSSID, सेल आईडी या उस नेटवर्क का पता जिससे डिवाइस कनेक्ट है.
- उपयोगकर्ता की शारीरिक गतिविधि या उसे किस तरह की गतिविधि में शामिल किया गया है.

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

[C-0-8] किसी ऐप्लिकेशन को जगह की जानकारी या शारीरिक गतिविधि से जुड़े डेटा को ऐक्सेस करने के लिए, उपयोगकर्ता की सहमति लेना ज़रूरी है.
[C-0-9] सिर्फ़ उस ऐप्लिकेशन को रनटाइम की अनुमति देनी होगी जिसके पास SDK टूल के बारे में दी गई जानकारी के मुताबिक, ज़रूरी अनुमति है. उदाहरण के लिए, TelephonyManager#getServiceState के लिए android.permission.ACCESS_FINE_LOCATION ज़रूरी है.

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

जब ऐप्लिकेशन के पास RADIO_SCAN_WITHOUT_LOCATION की अनुमति हो.
डिवाइस कॉन्फ़िगरेशन और सेटअप के लिए, जहां सिस्टम ऐप्लिकेशन के पास NETWORK_SETTINGS या NETWORK_SETUP_WIZARD अनुमति होती है.

अनुमतियों को 'प्रतिबंधित' के तौर पर मार्क किया जा सकता है. इससे उनके काम करने के तरीके में बदलाव होता है.

[C-0-10] किसी ऐप्लिकेशन को hardRestricted फ़्लैग के तौर पर मार्क की गई अनुमतियां तब तक नहीं दी जानी चाहिए, जब तक:
- ऐप्लिकेशन की APK फ़ाइल, सिस्टम पार्टिशन में है.
- उपयोगकर्ता ऐसी भूमिका असाइन करता है जो किसी ऐप्लिकेशन को hardRestricted अनुमतियों से जुड़ी होती है.
- इंस्टॉलर किसी ऐप्लिकेशन को hardRestricted देता है.
- ऐप्लिकेशन को Android के पुराने वर्शन पर hardRestricted दिया गया है.
[C-0-11] जिन ऐप्लिकेशन के पास softRestricted की अनुमति है उन्हें सिर्फ़ सीमित ऐक्सेस का ऐक्सेस होना चाहिए. साथ ही, SDK टूल में बताई गई अनुमति के हिसाब से, अनुमति वाली सूची में शामिल होने तक उनका पूरा ऐक्सेस नहीं लेना चाहिए. यहां हर softRestricted अनुमति (उदाहरण के लिए, READ_EXTERNAL_STORAGE) के लिए पूरा और सीमित ऐक्सेस दिया गया है.
[C-0-12] setPermissionPolicy और setPermission GrantsState एपीआई में बताए गए अनुमति पाबंदियों को बायपास करने के लिए, कोई कस्टम फ़ंक्शन या API नहीं देना चाहिए.
[C-0-13] Android गतिविधियों और सेवाओं से मिली खतरनाक अनुमतियों के ज़रिए सुरक्षित किए गए हर प्रोग्रैम्ड तरीके से डेटा के ऐक्सेस को रिकॉर्ड और ट्रैक करने के लिए, AppOpsManager API का इस्तेमाल करना ज़रूरी है.
[C-0-14] सिर्फ़ उन ऐप्लिकेशन को भूमिकाएं असाइन करनी होंगी जिनमें काम करने वाले फ़ंक्शन भूमिका से जुड़ी ज़रूरी शर्तों को पूरा करते हों.
[C-0-15] ऐसी भूमिकाओं को तय नहीं करना चाहिए जो प्लैटफ़ॉर्म की तय की गई भूमिकाओं की डुप्लीकेट हों या सुपरसेट फ़ंक्शन हों.

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

[C-1-1] एडमिन के पास ये अनुमतियां होनी चाहिए:
- जगह (ACCESS_BACKGROUND_LOCATION, ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION).
- कैमरा (CAMERA)
- माइक्रोफ़ोन (RECORD_AUDIO)
- बॉडी सेंसर (BODY_SENSORS)
- शारीरिक गतिविधि (ACTIVITY_RECOGNITION)

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

[C-2-1] यह पक्का करना ज़रूरी है कि ACTION_MANAGE_OVERLAY_PERMISSION इंटेंट के लिए इंटेंट फ़िल्टर वाली सभी गतिविधियों की यूज़र इंटरफ़ेस (यूआई) स्क्रीन एक ही हो. भले ही, शुरुआती ऐप्लिकेशन या उसकी ओर से दी गई कोई भी जानकारी कुछ भी हो.

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

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

अगर लागू किए गए डिवाइस में कोई भी ऐसा पैकेज पहले से इंस्टॉल होता है जिसमें System UI Intelligence, System Ambient Audio Intelligence, System Audio Intelligence, System Notification Intelligence, System Text Intelligence या System Visual Intelligence की भूमिकाएं शामिल हों, तो ये पैकेज:

[C-4-1] "9.8.6 कॉन्टेंट कैप्चर" सेक्शन में, डिवाइसों को लागू करने से जुड़ी सभी ज़रूरी शर्तें पूरी करनी होंगी.
[C-4-2] आपके पास android.permission.INTERnet की अनुमति नहीं होनी चाहिए. यह सेक्शन 9.8.6 में दिए गए 'बहुत ज़्यादा सुझाया गया' सेक्शन से ज़्यादा सख्त है.
[C-4-3] नीचे दिए गए सिस्टम ऐप्लिकेशन के अलावा, अन्य ऐप्लिकेशन को बाइंड नहीं करना चाहिए: ब्लूटूथ, Contacts, Media, Telephony, SystemUI, और इंटरनेट एपीआई उपलब्ध कराने वाले कॉम्पोनेंट.यह सेक्शन 9.8.6 में दिए गए 'बहुत ज़्यादा सुझाया गया' से ज़्यादा सख्त है.

9.2. यूआईडी और प्रोसेस आइसोलेशन

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

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

9.3. फ़ाइल सिस्टम अनुमतियां

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

[C-0-1] Android फ़ाइल को ऐक्सेस करने की अनुमतियों के मॉडल के साथ काम करना ज़रूरी है. इसके बारे में सुरक्षा और अनुमतियां के रेफ़रंस में बताया गया है.

9.4. वैकल्पिक एक्ज़ीक्यूशन एनवायरमेंट

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

[C-0-1] वैकल्पिक रनटाइम खुद ही Android ऐप्लिकेशन होने चाहिए. साथ ही, उन्हें स्टैंडर्ड Android सुरक्षा मॉडल का पालन करना चाहिए, जैसा कि सेक्शन 9 में बताया गया है.
[C-0-2] वैकल्पिक रनटाइम को उन संसाधनों का ऐक्सेस नहीं दिया जाना चाहिए जिनके लिए रनटाइम की AndroidManifest.xml फ़ाइल में <uses-permission> तरीके का इस्तेमाल करके, अनुमतियों का अनुरोध नहीं किया गया है.
[C-0-3] वैकल्पिक रनटाइम में ऐप्लिकेशन को ऐसी सुविधाओं का इस्तेमाल करने की अनुमति नहीं दी जानी चाहिए जिनके लिए सिस्टम ऐप्लिकेशन के लिए प्रतिबंधित Android अनुमतियों की ज़रूरत होती है.
[C-0-4] वैकल्पिक रनटाइम को Android सैंडबॉक्स मॉडल का पालन करना चाहिए. साथ ही, किसी वैकल्पिक रनटाइम का इस्तेमाल करके इंस्टॉल किए गए ऐप्लिकेशन को, डिवाइस पर इंस्टॉल किए गए किसी अन्य ऐप्लिकेशन के सैंडबॉक्स का फिर से इस्तेमाल नहीं करना चाहिए. हालांकि, शेयर किए गए यूज़र आईडी और साइनिंग सर्टिफ़िकेट के Android सिस्टम का इस्तेमाल नहीं किया जाना चाहिए.
[C-0-5] वैकल्पिक रनटाइम को अन्य Android ऐप्लिकेशन के सैंडबॉक्स के साथ लॉन्च नहीं किया जाना चाहिए, न देना चाहिए या न ही उन्हें ऐक्सेस दिया जाना चाहिए.
[C-0-6] वैकल्पिक रनटाइम को किसी सुपर उपयोगकर्ता (रूट) या किसी अन्य यूज़र आईडी के साथ लॉन्च किया जाना, अनुमति देना या अन्य ऐप्लिकेशन को कोई खास अधिकार नहीं देना चाहिए.
[C-0-7] जब वैकल्पिक रनटाइम वाली .apk फ़ाइलों को डिवाइस को लागू करने की प्रोसेस इमेज में शामिल किया जाता है, तो इसे उस कुंजी से अलग करके साइन किया जाना चाहिए. इसका इस्तेमाल डिवाइस से जुड़े दूसरे ऐप्लिकेशन को साइन करने के लिए किया जाता है.
[C-0-8] ऐप्लिकेशन इंस्टॉल करते समय, वैकल्पिक रनटाइम को ऐप्लिकेशन में इस्तेमाल की गई Android अनुमतियों के लिए उपयोगकर्ता की सहमति लेनी ज़रूरी है.
[C-0-9] जब किसी ऐप्लिकेशन को ऐसे डिवाइस संसाधन का इस्तेमाल करना होता है जिसके लिए Android से जुड़ी अनुमति (जैसे कि कैमरा, जीपीएस वगैरह) मौजूद हो, तो वैकल्पिक रनटाइम में उपयोगकर्ता को यह बताना ज़रूरी होता है कि ऐप्लिकेशन उस संसाधन को ऐक्सेस कर सकेगा.
[C-0-10] जब रनटाइम एनवायरमेंट इस तरह से ऐप्लिकेशन की क्षमताओं को रिकॉर्ड नहीं करता है, तो रनटाइम एनवायरमेंट में रनटाइम का इस्तेमाल करके किसी भी ऐप्लिकेशन को इंस्टॉल करते समय, उस रनटाइम की सभी अनुमतियों की सूची होनी चाहिए.
वैकल्पिक रनटाइम को PackageManager के ज़रिए, अलग-अलग Android सैंडबॉक्स (Linux यूज़र आईडी वगैरह) में इंस्टॉल करना चाहिए.
वैकल्पिक रनटाइम एक ही Android सैंडबॉक्स दे सकते हैं, जिसे सभी ऐप्लिकेशन अन्य रनटाइम का इस्तेमाल करके शेयर करते हैं.

9.5. बहु-उपयोगकर्ता सहायता

Android में कई उपयोगकर्ताओं के लिए सहायता शामिल है. साथ ही, यह आंशिक आइसोलेशन(जैसे, android.os.usertype.profile.CLONE टाइप की एक और उपयोगकर्ता प्रोफ़ाइल) की मदद से, सभी उपयोगकर्ताओं को आइसोलेशन और क्लोन करने की सुविधा देता है.

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

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

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

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

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

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

अगर डिवाइस लागू करने की सुविधा की मदद से, ऊपर बताई गई अतिरिक्त उपयोगकर्ता प्रोफ़ाइल बनती है, तो वे:

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

9.6. प्रीमियम एसएमएस से जुड़ी चेतावनी

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

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

[C-1-1] डिवाइस में /data/misc/sms/codes.xml फ़ाइल में बताए गए रेगुलर एक्सप्रेशन से पहचाने गए नंबर पर एसएमएस मैसेज भेजने से पहले, लोगों को चेतावनी देनी चाहिए. अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट ऐसी सुविधा उपलब्ध कराता है जो इस ज़रूरी शर्त को पूरा करता है.

9.7. सुरक्षा से जुड़ी सुविधाएं

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

Android सैंडबॉक्स में ऐसी सुविधाएं हैं जो Linux कर्नेल में सुरक्षा के लिए बेहतर बनाई गई Linux (SELinux) ज़रूरी ऐक्सेस कंट्रोल (MAC) सिस्टम, seccomp सैंडबॉक्सिंग, और अन्य सुरक्षा सुविधाओं का इस्तेमाल करती हैं. डिवाइस पर यह सुविधा लागू करना:

[C-0-1] मौजूदा ऐप्लिकेशन के साथ काम करना जारी रखना ज़रूरी है, भले ही SELinux या कोई अन्य सुरक्षा सुविधा Android फ़्रेमवर्क के नीचे लागू की गई हो.
[C-0-2] Android फ़्रेमवर्क के नीचे लागू की गई सुरक्षा सुविधा की मदद से, सुरक्षा के उल्लंघन का पता चलने और उसे ब्लॉक करने पर, यूज़र इंटरफ़ेस साफ़ तौर पर नहीं दिखना चाहिए. हालांकि, सुरक्षा के किसी उल्लंघन की स्थिति में अनब्लॉक होने पर, इसका यूज़र इंटरफ़ेस दिख सकता है.
[C-0-3] SELinux या Android फ़्रेमवर्क के नीचे लागू की गई किसी भी दूसरी सुरक्षा सुविधा को उपयोगकर्ता या ऐप्लिकेशन डेवलपर के लिए कॉन्फ़िगर नहीं करना चाहिए.
[C-0-4] ऐसे ऐप्लिकेशन को अनुमति नहीं देनी चाहिए जो काम करने से जुड़ी नीति को भंग करने वाली नीति को कॉन्फ़िगर करने के लिए एपीआई (जैसे कि Device Administration API) के ज़रिए दूसरे ऐप्लिकेशन पर असर डाल सकता है.
[C-0-5] मीडिया फ़्रेमवर्क को कई प्रोसेस में बांटना ज़रूरी है, ताकि Android ओपन सोर्स प्रोजेक्ट की साइट पर दिए गए बताए गए तरीके से, हर प्रोसेस को बारीकी से ऐक्सेस दिया जा सके.
[C-0-6] कर्नेल ऐप्लिकेशन सैंडबॉक्सिंग तकनीक लागू करनी ज़रूरी है. इसकी मदद से, मल्टीथ्रेड प्रोग्राम की कॉन्फ़िगर की जा सकने वाली नीति का इस्तेमाल करके, सिस्टम कॉल को फ़िल्टर किया जा सकता है. अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट इस ज़रूरी शर्त को पूरा करता है. इसके लिए, source.android.com के Kernel कॉन्फ़िगरेशन सेक्शन में बताए गए तरीके के मुताबिक, Threadgroup सिंक्रोनाइज़ेशन (TSYNC) के साथ seccomp-BPF को चालू किया जाता है.

कर्नेल इंटिग्रिटी और खुद की सुरक्षा से जुड़ी सुविधाएं, Android सुरक्षा का ज़रूरी हिस्सा हैं. डिवाइस पर यह सुविधा लागू करना:

[C-0-7] कर्नेल स्टैक बफ़र ओवरफ़्लो से सुरक्षा देने के तरीके लागू करना ज़रूरी है. CC_STACKPROTECTOR_REGULAR और CONFIG_CC_STACKPROTECTOR_STRONG ऐसे तरीकों के उदाहरण हैं.
[C-0-8] कर्नेल मेमोरी की सख्त सुरक्षा लागू करना ज़रूरी है, जहां एक्ज़ीक्यूटेबल कोड को सिर्फ़ पढ़ा जा सकता है, रीड-ओनली डेटा होता है और उसे एक्ज़ीक्यूट नहीं किया जा सकता. साथ ही, लिखा जा सकने वाला डेटा, एक्ज़ीक्यूट नहीं किया जा सकता (जैसे, CONFIG_DEBUG_RODATA या CONFIG_STRICT_KERNEL_RWX).
[C-0-9] एपीआई लेवल 28 या उससे बाद के लेवल पर शिपिंग किए जाने वाले डिवाइसों पर, स्टैटिक और डाइनैमिक ऑब्जेक्ट के साइज़ की सीमाओं को लागू करना ज़रूरी है. इससे यूज़र-स्पेस और कर्नेल-स्पेस (जैसे, CONFIG_HARDENED_USERCOPY) के बीच कॉपी की जांच की जा सकती है.
[C-0-10] एपीआई लेवल 28 या उसके बाद के लेवल वाले डिवाइसों पर, कर्नेल मोड (जैसे कि हार्डवेयर PXN) में एक्ज़ीक्यूट करते समय, CONFIG_CPU_SW_DOMAIN_PAN या CONFIG_ARM64_SW_TTBR0_PAN की मदद से एम्युलेट किए गए यूज़र स्पेस मेमोरी को एक्ज़ीक्यूट नहीं करना चाहिए.
[C-0-11] एपीआई लेवल 28 या उसके बाद के वर्शन वाले डिवाइसों पर, सामान्य यूज़रकॉपी ऐक्सेस एपीआई (जैसे, हार्डवेयर पैन या CONFIG_CPU_SW_DOMAIN_PAN या CONFIG_ARM64_SW_TTBR0_PAN की मदद से एम्युलेट किए गए) के बाहर, कर्नेल में यूज़र-स्पेस मेमोरी को पढ़ना या लिखना नहीं चाहिए.
[C-0-12] एपीआई लेवल 28 या उसके बाद के लेवल (जैसे कि CONFIG_PAGE_TABLE_ISOLATION या CONFIG_UNMAP_KERNEL_AT_EL0) की शिपिंग वाले सभी डिवाइसों पर, हार्डवेयर को CVE-2017-5754 से खतरा होने पर कर्नेल पेज टेबल आइसोलेशन को लागू करना ज़रूरी है.
[C-0-13] एपीआई लेवल 28 या उससे बाद के लेवल (जैसे कि CONFIG_HARDEN_BRANCH_PREDICTOR) वाले सभी डिवाइसों पर, जिन डिवाइसों पर हार्डवेयर को CVE-2017-5715 से खतरा हो सकता है उन सभी पर, ब्रांच के अनुमान को सख्ती से लागू करना ज़रूरी है.
[C-SR-1] कर्नेल डेटा को बनाए रखने के लिए इसका बहुत ज़्यादा सुझाव दिया जाता है जिसे सिर्फ़ शुरू करने के बाद रीड-ओनली के तौर पर मार्क किया जाता है (जैसे, __ro_after_init).
[C-SR-2] कर्नेल कोड और मेमोरी के लेआउट को रैंडमाइज़ करने और ऐसे एक्सपोज़र से बचने के लिए खास तौर पर सुझाव दिया जाता है जिनसे रैंडमाइज़ेशन की समस्या पैदा न हो. उदाहरण के लिए, /chosen/kaslr-seed Device Tree node या EFI_RNG_PROTOCOL के ज़रिए बूटलोडर एंट्रॉपी के साथ CONFIG_RANDOMIZE_BASE).
[C-SR-3] का बहुत ज़्यादा सुझाव दिया जाता है, ताकि कर्नेल में कंट्रोल फ़्लो इंटिग्रिटी (सीएफ़आई) को चालू किया जा सके. इससे कोड का दोबारा इस्तेमाल करने के हमलों (जैसे, CONFIG_CFI_CLANG और CONFIG_SHADOW_CALL_STACK) से ज़्यादा सुरक्षा मिलती है.
[C-SR-4] हमारा सुझाव है कि जिन कॉम्पोनेंट पर यह सुविधा चालू है उन पर कंट्रोल-फ़्लो इंटेग्रिटी (सीएफ़आई), शैडो कॉल स्टैक (एससीएस) या Integer ओवरफ़्लो सैनिटाइज़ेशन (IntSan) को बंद न करें.
[C-SR-5] का खास तौर पर सुझाव दिया जाता है कि सीएफ़आई, एससीएस, और IntSan को, सुरक्षा के लिहाज़ से संवेदनशील यूज़रस्पेस कॉम्पोनेंट के लिए चालू किया जाए. इसकी जानकारी सीएफ़आई और IntSan में दी गई है.
[C-SR-6] का सुझाव दिया जाता है कि शुरू नहीं किए गए लोकल वैरिएबल (CONFIG_INIT_STACK_ALL या CONFIG_INIT_STACK_ALL_ZERO) के इस्तेमाल को रोकने के लिए, कर्नेल में स्टैक शुरू करने की सुविधा चालू की जाए. इसके अलावा, डिवाइस को लागू करने के लिए कंपाइलर की ओर से लोकल वैरिएबल को शुरू करने के लिए इस्तेमाल की जाने वाली वैल्यू नहीं माननी चाहिए.
[C-SR-7] का सुझाव दिया जाता है, ताकि शुरू नहीं किए गए हीप ऐलोकेशन (CONFIG_INIT_ON_ALLOC_DEFAULT_ON) के इस्तेमाल को रोका जा सके. इसके लिए, कर्नेल में हीप शुरू करने की सुविधा चालू करनी चाहिए. साथ ही, उन्हें उस वैल्यू को नहीं मानना चाहिए जिसका इस्तेमाल कर्नेल ने ऐलोकेशन को शुरू करने के लिए किया है.

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

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

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

[C-2-1] ज़रूरी है कि ऐक्सेस कंट्रोल सिस्टम का इस्तेमाल किया जाए. यह सिस्टम, SELinux जैसे ही होता है.

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

[C-SR-9] डीएमए की क्षमता वाले हर I/O डिवाइस को अलग करने के लिए ज़रूरी है कि IOMMU (जैसे ARM SMMU) का इस्तेमाल किया जाए.

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

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

[C-SR-10] यूज़रस्पेस मेमोरी गड़बड़ी का पता लगाने वाले टूल जैसे ARMv9 डिवाइसों के लिए MTE, ARMv8+ डिवाइसों के लिए HWASan या अन्य तरह के डिवाइसों के लिए ASan का इस्तेमाल करके टेस्ट करने की बहुत ज़्यादा सलाह दी जाती है.
[C-SR-11] कर्नेल मेमोरी की गड़बड़ी का पता लगाने वाले टूल जैसे कि KASAN (CONFIG_KASAN, ARMv9 डिवाइस के लिए CONFIG_KASAN_HW_TAGS, ARMv8 डिवाइस के लिए CONFIG_KASAN_SW_TAGS या अन्य तरह के डिवाइस के लिए CONFIG_KASAN_GENERIC) का इस्तेमाल करने की बहुत ज़्यादा सलाह दी जाती है.
[C-SR-12] MTE, GWP-ASan, और KFENCE जैसे प्रोडक्शन में, मेमोरी में गड़बड़ी का पता लगाने वाले टूल का इस्तेमाल करने पर ज़ोर दिया जाता है.

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

[C-SR-13] Android और TEE के बीच मेमोरी शेयर करने के लिए, एक स्टैंडर्ड प्रोटोकॉल का इस्तेमाल करने का सुझाव दिया जाता है. जैसे, Armv8-A (FF-A) के लिए आर्म फ़र्मवेयर फ़्रेमवर्क.
[C-SR-14] हमारा सुझाव है कि भरोसेमंद ऐप्लिकेशन को सिर्फ़ उस मेमोरी को ऐक्सेस करने से रोकें जो ऊपर बताए गए प्रोटोकॉल के ज़रिए उनके साथ शेयर की गई हो. अगर डिवाइस में आर्म S-EL2 अपवाद लेवल पर काम करता है, तो इसे सुरक्षित पार्टिशन मैनेजर की मदद से लागू करना चाहिए. अगर ऐसा नहीं है, तो टीईई ओएस यह नियम लागू करेगा.

9.8. निजता

9.8.1. इस्तेमाल का इतिहास

Android, उपयोगकर्ता की पसंद के इतिहास को सेव करता है और UsageStatsManager की मदद से इस तरह के इतिहास को मैनेज करता है.

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

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

Android, StatsLog आइडेंटिफ़ायर का इस्तेमाल करके सिस्टम इवेंट को सेव करता है. साथ ही, इस इतिहास को StatsManager और IncidentManager System API की मदद से मैनेज करता है.

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

[C-0-2] सिर्फ़ उन फ़ील्ड को शामिल करना ज़रूरी है जिन्हें System API क्लास IncidentManager ने, घटना की रिपोर्ट में DEST_AUTOMATIC से मार्क किया है.
[C-0-3] StatsLog SDK टूल के दस्तावेज़ में दी गई जानकारी के अलावा, किसी और इवेंट को लॉग करने के लिए, सिस्टम इवेंट आइडेंटिफ़ायर का इस्तेमाल नहीं करना चाहिए. अगर सिस्टम से जुड़े अन्य इवेंट लॉग किए जाते हैं, तो वे 1,00,000 से 2,00,000 के बीच की रेंज में किसी दूसरे ऐटम आइडेंटिफ़ायर का इस्तेमाल कर सकते हैं.

9.8.2. रिकॉर्ड किया जा रहा है

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

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

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

[C-1-1] इस फ़ंक्शन को चालू करने और कैप्चर/रिकॉर्ड करने पर, लोगों को इसकी सूचना दी जानी चाहिए.

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

[C-2-1] उपयोगकर्ता की सहमति को छोड़कर, इसे डिवाइस के लगातार स्टोरेज में सेव नहीं करना चाहिए और न ही रिकॉर्ड किए गए रॉ ऑडियो या किसी ऐसे फ़ॉर्मैट को डिवाइस से बाहर नहीं रखना चाहिए जिसे वापस ओरिजनल ऑडियो या फ़ैक्स में बदला जा सके. हालांकि, इसके लिए उपयोगकर्ता की सहमति लेना ज़रूरी है.

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

“कैमरा इंंडिकेटर” का मतलब, स्क्रीन पर मौजूद ऐसे व्यू से है, जो लोगों को लगातार दिखता रहता है और जिसे धुंधला नहीं किया जा सकता. यह लोगों को यह समझ आता है कि कैमरे का इस्तेमाल किया जा रहा है (यूनीक टेक्स्ट, रंग, आइकॉन या अलग-अलग तरीकों से).

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

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

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

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

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

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

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

9.8.3. कनेक्टिविटी

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

9.8.4. नेटवर्क ट्रैफ़िक

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

[C-0-1] सिस्टम-ट्रस्टेड सर्टिफ़िकेट अथॉरिटी (CA) स्टोर के लिए, उन्हीं रूट सर्टिफ़िकेट को पहले से इंस्टॉल करना होगा जो अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट में दिए गए हैं.
[C-0-2] उपयोगकर्ता के रूट वाले सीए स्टोर के साथ शिप करना ज़रूरी है.
[C-0-3] उपयोगकर्ता को एक चेतावनी दिखानी ज़रूरी है, ताकि यह बताया जा सके कि उपयोगकर्ता रूट सीए (सर्टिफ़िकेट देने वाली संस्था) को जोड़े जाने पर, नेटवर्क ट्रैफ़िक को मॉनिटर किया जा सकता है.

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

[C-1-1] उपयोगकर्ता को एक चेतावनी दिखानी होगी, जिसमें यह बताया गया हो:
- उस नेटवर्क ट्रैफ़िक की निगरानी की जा सकती है.
- उस नेटवर्क ट्रैफ़िक को, वीपीएन देने वाले खास वीपीएन ऐप्लिकेशन से रूट किया जा रहा है.

अगर डिवाइस पर लागू करने का कोई ऐसा तरीका है जो डिफ़ॉल्ट रूप से आउट-ऑफ़-बॉक्स चालू होता है, तो वह नेटवर्क डेटा ट्रैफ़िक को प्रॉक्सी सर्वर या वीपीएन गेटवे के ज़रिए रूट करता है (उदाहरण के लिए, android.permission.CONTROL_VPN की अनुमति वाली वीपीएन सेवा को पहले से लोड करना), तो:

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

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

[C-3-1] SERVICE_META_DATA_SUPPORTS_ALWAYS_ON एट्रिब्यूट को false पर सेट करके, उन ऐप्लिकेशन के लिए उपयोगकर्ताओं के लिए इस विकल्प को बंद करना ज़रूरी है जो AndroidManifest.xml फ़ाइल में हमेशा चालू रहने वाली वीपीएन सेवा की सुविधा नहीं देते.

9.8.5. डिवाइस आइडेंटिफ़ायर

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

[C-0-1] को डिवाइस के सीरियल नंबर और जहां भी लागू हो वहां IMEI/MEID, सिम का सीरियल नंबर, और इंटरनैशनल मोबाइल सब्सक्राइबर आइडेंटिटी (IMSI) ऐक्सेस करने से रोकना चाहिए. ऐसा तब तक नहीं किया जाना चाहिए, जब तक कि वह इनमें से किसी एक शर्त को पूरा न करता हो:
- मोबाइल और इंटरनेट सेवा देने वाली कंपनी का हस्ताक्षर किया हुआ ऐप्लिकेशन है. इसकी पुष्टि डिवाइस बनाने वाली कंपनियां कर रही हैं.
- को READ_PRIVILEGED_PHONE_STATE की अनुमति दे दी गई है.
- के पास, मोबाइल और इंटरनेट सेवा देने वाली कंपनी के अधिकार हैं, जैसा कि यूआईसीसी के मोबाइल और इंटरनेट सेवा देने वाली कंपनी के खास अधिकार में बताया गया है.
- वह डिवाइस का मालिक या प्रोफ़ाइल का मालिक है जिसे READ_PHONE_STATE की अनुमति दी गई है.
- ऐप्लिकेशन को सदस्य की पहचान में हुए बदलावों के बारे में स्थानीय कानूनों से जुड़ी शर्तें पूरी करनी होंगी. यह शर्त सिर्फ़ सिम के सीरियल नंबर/आईसीसीआईडी के लिए तय की गई है.

9.8.6. कॉन्टेंट कैप्चर करने और ऐप्लिकेशन खोजने की सुविधा

Android, System API ContentCaptureService, AugmentedAutofillService, AppSearchGlobalManager.query या अन्य मालिकाना हक वाले तरीकों से, डिवाइस पर ऐसे तरीके लागू करता है जिससे ऐप्लिकेशन और उपयोगकर्ता के बीच ऐप्लिकेशन के इन डेटा इंटरैक्शन को कैप्चर किया जा सकता है:

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

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

[C-1-1] डिवाइस में सेव किए जाने पर, ऐसे सभी डेटा को एन्क्रिप्ट (सुरक्षित) करना ज़रूरी है. एन्क्रिप्ट (सुरक्षित) करने का यह तरीका, Android फ़ाइल पर आधारित एन्क्रिप्ट (सुरक्षित) करने के तरीके या Cipher SDK टूल में बताए गए, एपीआई वर्शन 26 के बाद के वर्शन पर मौजूद किसी भी साइफ़र का इस्तेमाल करके इस्तेमाल किया जा सकता है.
[C-1-2] Android पर बैक अप के लिए इस्तेमाल किए गए तरीके या बैक अप लेने के किसी दूसरे तरीके का इस्तेमाल करके, रॉ या एन्क्रिप्ट किए गए डेटा का बैक अप नहीं लेना चाहिए.
[C-1-3] सिर्फ़ ऐसा सारा डेटा और डिवाइस के लॉग को भेजने के लिए, निजता बनाए रखने के तरीके का इस्तेमाल करना ज़रूरी है. निजता बनाए रखने वाले तरीके को "ऐसे डेटा" के तौर पर परिभाषित किया गया है जो सिर्फ़ एग्रीगेट डेटा का विश्लेषण करने और लॉग किए गए इवेंट या लॉग किए गए इवेंट के डेटा को अलग-अलग उपयोगकर्ताओं से मैच करने से रोकता है.ऐसा इसलिए किया जाता है, ताकि हर उपयोगकर्ता के डेटा को आत्मविश्वास के साथ अनुभव न किया जा सके. जैसे, RAPPOR जैसी डिफ़रेंशियल प्राइवसी टेक्नोलॉजी का इस्तेमाल करके.
[C-1-4] इस तरह के डेटा को डिवाइस पर किसी उपयोगकर्ता की पहचान (जैसे कि Account) से नहीं जोड़ना चाहिए. ऐसा करने के लिए, हर बार डेटा इकट्ठा करने के दौरान साफ़ तौर पर उपयोगकर्ता की सहमति लेना ज़रूरी है.
[C-1-5] ऐसे डेटा को ओएस के उन दूसरे कॉम्पोनेंट के साथ शेयर नहीं किया जाना चाहिए जो मौजूदा सेक्शन (9.8.6 कॉन्टेंट कैप्चर) में बताई गई ज़रूरी शर्तों का पालन नहीं करते. हालांकि, हर बार डेटा शेयर करने पर, उपयोगकर्ता की सहमति साफ़ तौर पर दी जानी चाहिए.
[C-1-6] लोगों को ऐसा डेटा मिटाने की सुविधा देनी होगी जिसे ContentCaptureService या मालिकाना हक वाले तरीके से इकट्ठा किया जाता हो. ऐसा तब किया जाता है, जब डेटा को डिवाइस पर किसी भी रूप में सेव किया जाता है.
[C-1-7] लोगों को यह विकल्प देना ज़रूरी है कि वे AppSearch या मालिकाना हक के ज़रिए इकट्ठा किए गए डेटा से, ऑप्ट-आउट करने का विकल्प उपलब्ध करा सकें.यह सुविधा, लॉन्चर जैसे Android प्लैटफ़ॉर्म पर दिखाए जाने पर उपयोगकर्ता को देनी होगी.
[C-SR-1] इस बात पर ज़ोर दिया जाता है कि इंटरनेट की अनुमति का अनुरोध न करें.
[C-SR-2] सिर्फ़ स्ट्रक्चर्ड एपीआई के ज़रिए इंटरनेट ऐक्सेस करने का सुझाव दिया जाता है. ये एपीआई सार्वजनिक रूप से उपलब्ध ओपन-सोर्स लागू करने के तरीके का इस्तेमाल करते हैं.

अगर डिवाइस पर लागू करने के तरीके में कोई ऐसी सेवा शामिल है जो System API ContentCaptureService, AppSearchManager.index या मालिकाना हक वाली ऐसी सेवा को लागू करती है जिसमें ऊपर बताए गए तरीके से डेटा कैप्चर किया जाता है, तो वे:

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

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

9.8.7. क्लिपबोर्ड का ऐक्सेस

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

[C-0-1] क्लिपबोर्ड से क्लिप किया गया डेटा नहीं लौटाना चाहिए (उदाहरण के लिए, ClipboardManager एपीआई के ज़रिए) जब तक तीसरे पक्ष का ऐप्लिकेशन डिफ़ॉल्ट IME नहीं है या फ़िलहाल ऐसा ऐप्लिकेशन है जिस पर फ़ोकस है.
[C-0-2] क्लिपबोर्ड डेटा को क्लिपबोर्ड पर रखने या क्लिपबोर्ड से पढ़ने के ज़्यादा से ज़्यादा 60 मिनट बाद, उसे साफ़ करना ज़रूरी है.

9.8.8. जगह

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

नीचे दी गई जगह के टाइप की सूची नीचे दी गई है, जो उपयोगकर्ता की जगह की जानकारी के बारे में सीधे तौर पर बताती है या जिसे उपयोगकर्ता की जगह के तौर पर बदला जा सकता है. यह पूरी सूची नहीं है, लेकिन इसे उदाहरण के तौर पर इस्तेमाल करना चाहिए कि जगह की जानकारी सीधे तौर पर या किसी और तरीके से किस तरह ली जा सकती है:

जीपीएस/जीएनएसएस/डीजीपीएस/पीपीपी
- ग्लोबल पोज़िशनिंग सलूशन या ग्लोबल नेविगेशन सैटलाइट सिस्टम या डिफ़रेंशियल ग्लोबल पोज़िशनिंग सलूशन
- इसमें रॉ जीएनएसएस मेज़रमेंट और जीएनएसएस स्टेटस भी शामिल है
  - जीएनएसएस की रॉ मेज़रमेंट से जगह की सटीक जानकारी का पता लगाया जा सकता है
यूनीक आइडेंटिफ़ायर वाले वायरलेस टेक्नोलॉजी, जैसे:
- वाई-फ़ाई ऐक्सेस पॉइंट (MAC, BSSID, Name या SSID)
- ब्लूटूथ/BLE (MAC, BSSID, नाम या SSID)
- यूडब्ल्यूबी (MAC, BSSID, नाम या SSID)
- सेल टावर आईडी (3G, 4G, 5G...) इसमें सेल्युलर मॉडम से जुड़ी, आने वाले समय की उन सभी टेक्नोलॉजी को शामिल किया गया है जिनमें यूनीक आइडेंटिफ़ायर शामिल हैं)

मुख्य रूप से, वे Android API देखें जिनके लिए ACCESS_FINE_Location या ACCESS_COARSE_Location की अनुमतियां ज़रूरी हैं.

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

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

9.8.9. इंस्टॉल किए गए ऐप्लिकेशन

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

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

[C-0-1] एपीआई लेवल 30 या उससे बाद के लेवल को टारगेट करने वाले किसी भी ऐप्लिकेशन को, इंस्टॉल किए गए किसी अन्य ऐप्लिकेशन की जानकारी नहीं देनी चाहिए. ऐसा तब तक नहीं होना चाहिए, जब तक ऐप्लिकेशन, मैनेज किए जा रहे एपीआई की मदद से, इंस्टॉल किए गए अन्य ऐप्लिकेशन की जानकारी न देख ले. इसमें, डिवाइस लागू करने वाले टूल से जोड़े गए या फ़ाइल सिस्टम से ऐक्सेस किए जा सकने वाले किसी भी कस्टम एपीआई की जानकारी शामिल है. हालांकि, इसमें इनके अलावा और भी चीज़ें शामिल हो सकती हैं.
[C-0-2] किसी ऐप्लिकेशन को बाहरी स्टोरेज में खास तौर पर ऐप्लिकेशन के लिए बनाई गई डायरेक्ट्री में मौजूद फ़ाइलों को पढ़ने या उनमें बदलाव करने का ऐक्सेस नहीं देना चाहिए. इसके अपवाद ये हैं:
- बाहरी स्टोरेज उपलब्ध कराने वाली संस्था या निकाय (उदाहरण के लिए, DocumentsUI जैसे ऐप्लिकेशन).
- डाउनलोड की सुविधा देने वाली कंपनी, जो ऐप्लिकेशन के स्टोरेज में फ़ाइलें डाउनलोड करने के लिए “डाउनलोड” उपलब्ध कराने वाली कंपनी की अनुमति का इस्तेमाल करती है.
- प्लैटफ़ॉर्म से साइन किए गए मीडिया ट्रांसफ़र प्रोटोकॉल (एमटीपी) वाले ऐसे ऐप्लिकेशन जो किसी दूसरे डिवाइस पर फ़ाइलें ट्रांसफ़र करने की सुविधा देने के लिए, खास अनुमति ACCESS_MTP का इस्तेमाल करते हैं.
- ऐसे ऐप्लिकेशन जो अन्य ऐप्लिकेशन इंस्टॉल करते हैं और जिनके पास INSTALL_PACKAGES अनुमति है वे सिर्फ़ APK एक्सपैंशन फ़ाइलों को मैनेज करने के लिए, सिर्फ़ “obb” डायरेक्ट्री ऐक्सेस कर सकते हैं.

9.8.10. कनेक्टिविटी से जुड़ी गड़बड़ी की रिपोर्ट

अगर लागू किए गए डिवाइस ने android.hardware.telephony फ़ीचर फ़्लैग का एलान किया है, तो:

[C-1-1] BugreportManager की मदद से BUGREPORT_MODE_TELEPHONY के ज़रिए कनेक्टिविटी से जुड़ी गड़बड़ी की रिपोर्ट जनरेट की जा सकती हैं.
[C-1-2] जब भी BUGREPORT_MODE_TELEPHONY का इस्तेमाल रिपोर्ट जनरेट करने के लिए किया जाता है, तब हर बार उपयोगकर्ता की सहमति लेनी ज़रूरी है. साथ ही, आने वाले समय में ऐप्लिकेशन से किए जाने वाले सभी अनुरोधों के लिए, उपयोगकर्ता को सहमति नहीं लेनी होगी.
[C-1-3] उपयोगकर्ता की सहमति के बिना, जनरेट की गई रिपोर्ट को अनुरोध करने वाले ऐप्लिकेशन को नहीं भेजना चाहिए.
[C-1-4] BUGREPORT_MODE_TELEPHONY का इस्तेमाल करके जनरेट की गई रिपोर्ट में, कम से कम यह जानकारी होनी चाहिए:
- TelephonyDebugService डंप
- TelephonyRegistry डंप
- WifiService डंप
- ConnectivityService डंप
- कॉलिंग पैकेज के CarrierService इंस्टेंस का डंप (अगर इसकी वैल्यू बाउंड है)
- रेडियो लॉग बफ़र
[C-1-5] जनरेट की गई रिपोर्ट में, यहां दी गई जानकारी शामिल नहीं होनी चाहिए:
- ऐसी कोई भी जानकारी जो कनेक्टिविटी डीबगिंग से सीधे तौर पर जुड़ी न हो.
- उपयोगकर्ता के इंस्टॉल किए गए किसी भी तरह के ऐप्लिकेशन ट्रैफ़िक लॉग या उपयोगकर्ता के इंस्टॉल किए गए ऐप्लिकेशन/पैकेज की ज़्यादा जानकारी वाली प्रोफ़ाइल (यूआईडी ठीक हैं, पैकेज के नाम नहीं.
इसमें ऐसी अन्य जानकारी भी शामिल हो सकती है जो किसी उपयोगकर्ता की पहचान से न जुड़ी हो. (उदाहरण के लिए, वेंडर लॉग).

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

[C-SR-1] डेवलपर की सेटिंग को डिफ़ॉल्ट रूप से 'बंद है' पर सेट करने का सुझाव दिया जाता है. एओएसपी रेफ़रंस को लागू करने के लिए, डेवलपर सेटिंग में Enable verbose vendor logging विकल्प दिया जाता है, ताकि गड़बड़ी की रिपोर्ट में डिवाइस से जुड़े अन्य वेंडर लॉग शामिल किए जा सकें.

9.8.11. डेटा ब्लॉब शेयर करना

BlobStoreManager की मदद से Android, ऐप्लिकेशन को चुनिंदा ऐप्लिकेशन के साथ शेयर करने के लिए, सिस्टम में डेटा ब्लॉब में योगदान देने की अनुमति देता है.

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

[C-1-1] ऐप्लिकेशन से जुड़े ऐसे डेटा ब्लॉब को शेयर नहीं करना चाहिए जिनकी वे अनुमति नहीं देना चाहते थे (जैसे, डिफ़ॉल्ट ऐक्सेस का दायरा और दूसरे ऐक्सेस मोड, जिन्हें BlobStoreManager.session#allowPackageAccess(), BlobStoreManager.session#allowSubmitSameAccess(), या BlobStore.NOTPublicAccess() का इस्तेमाल करके तय किया जा सकता है. एओएसपी रेफ़रंस फ़ाइल को लागू करने के लिए, इन ज़रूरी शर्तों को पूरा किया जाता है.
[C-1-2] डिवाइस को कहीं से भी नहीं भेजना चाहिए या डेटा ब्लॉब के सुरक्षित हैश को दूसरे ऐप्लिकेशन के साथ शेयर नहीं करना चाहिए (इनका इस्तेमाल ऐक्सेस कंट्रोल करने के लिए किया जाता है).

9.8.12. संगीत की पहचान

Android, System API MusicRecognitionManager की मदद से, अलग-अलग डिवाइसों पर संगीत की पहचान करने का अनुरोध करने और ऑडियो रिकॉर्ड देने का अनुरोध करने के तरीके उपलब्ध कराता है. साथ ही, इस सुविधा का इस्तेमाल संगीत की पहचान करने का ऐक्सेस, ऐसे ऐप्लिकेशन को देता है जो MusicRecognitionService API का इस्तेमाल करके, संगीत की पहचान करने का अनुरोध करता है.

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

[C-1-1] यह लागू करना ज़रूरी है कि MusicRecognitionManager के कॉलर के पास MANAGE_MUSIC_RECOGNITION की अनुमति है
[C-1-2] यह लागू करना ज़रूरी है कि पहले से इंस्टॉल किया गया, संगीत की पहचान करने वाला एक ऐप्लिकेशन, MusicRecognitionService को लागू करता है.
[C-1-3] उपयोगकर्ताओं को MusicRecognitionManagerService या MusicRecognitionService को उपयोगकर्ता के इंस्टॉल किए जा सकने वाले ऐप्लिकेशन या सेवा से बदलने की अनुमति नहीं देनी चाहिए.
[C-1-4] आपको यह पक्का करना होगा कि जब MusicRecognitionManagerService, ऑडियो रिकॉर्ड को ऐक्सेस करके, MusicRecognitionService को लागू करने वाले ऐप्लिकेशन पर भेजता, तो ऑडियो ऐक्सेस को AppOpsManager.noteOp / startOp के ज़रिए ट्रैक किया जाए.

अगर MusicRecognitionManagerService या MusicRecognitionService के इस्तेमाल से किसी डिवाइस पर रिकॉर्ड किए गए किसी ऑडियो डेटा को सेव किया जाए, तो वे:

[C-2-1] डिस्क पर कोई भी रॉ ऑडियो या ऑडियो फ़िंगरप्रिंट नहीं सेव करना चाहिए या मेमोरी में 14 दिनों से ज़्यादा समय तक सेव नहीं करना चाहिए.
[C-2-2] इस तरह का डेटा, MusicRecognitionService के अलावा किसी और तरीके से शेयर नहीं किया जाना चाहिए. हालांकि, हर बार इसे शेयर करते समय, साफ़ तौर पर उपयोगकर्ता की सहमति ली जानी चाहिए.

9.8.13. सेंसर निजता मैनेजर

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

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

9.9. डेटा स्टोरेज सुरक्षित करने का तरीका

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

9.9.1. डायरेक्ट बूट

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

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

9.9.2. एन्क्रिप्ट (सुरक्षित) करने के तरीके की ज़रूरी शर्तें

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

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

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

9.9.3. एन्क्रिप्ट (सुरक्षित) करने के तरीके

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

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

9.9.3.1. मेटाडेटा एन्क्रिप्शन के साथ फ़ाइल आधारित एन्क्रिप्शन

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

[C-1-5] AES-256-XTS या Adiantum का इस्तेमाल करके फ़ाइल के कॉन्टेंट और फ़ाइल सिस्टम मेटाडेटा को एन्क्रिप्ट (सुरक्षित) करना ज़रूरी है. AES-256-XTS का मतलब ऐडवांस्ड एन्क्रिप्शन स्टैंडर्ड है. इसमें 256-बिट साइफ़र कुंजी की लंबाई होती है और इसे XTS मोड में ऑपरेट किया जाता है. कुंजी की पूरी लंबाई 512 बिट होती है. Adiantum का मतलब Adiantum-XChaCha12-AES है, जैसा कि https://github.com/google/aiantum पर बताया गया है. फ़ाइल सिस्टम मेटाडेटा में फ़ाइल का साइज़, मालिकाना हक, मोड, और एक्सटेंडेड एट्रिब्यूट (xattrs) जैसा डेटा शामिल होता है.
[C-1-6] AES-256-CBC-CTS या Adiantum का इस्तेमाल करके फ़ाइल नाम एन्क्रिप्ट करना ज़रूरी है.
[C-1-12] अगर डिवाइस में ऐडवांस एन्क्रिप्शन स्टैंडर्ड (AES) निर्देश (जैसे ARM-आधारित डिवाइसों पर ARMv8 क्रिप्टोग्राफ़ी एक्सटेंशन या x86-आधारित डिवाइसों पर AES-NI) के निर्देश हैं, तो फ़ाइल नाम, फ़ाइल कॉन्टेंट, और फ़ाइल सिस्टम मेटाडेटा एन्क्रिप्शन के लिए ऊपर दिए गए AES-आधारित विकल्पों का इस्तेमाल किया जाना चाहिए, Adiantum का नहीं.
[C-1-13] CE और DE कुंजियों से कोई भी ज़रूरी सब-की (जैसे कि हर फ़ाइल कुंजियां) पाने के लिए, क्रिप्टोग्राफ़िक तौर पर मज़बूत और रिवर्स नहीं किए जा सकने वाले कुंजी डेरिवेशन फ़ंक्शन (जैसे, HKDF-SHA512) का इस्तेमाल करना ज़रूरी है. "क्रिप्टोग्राफ़िक रूप से मज़बूत और रिवर्स नहीं किए जा सकने वाले" का मतलब है कि की डेरिवेशन फ़ंक्शन में कम से कम 256 बिट की सुरक्षा क्षमता है और यह अपने इनपुट पर स्यूडोरैंडम फ़ंक्शन फ़ैमिली के तौर पर काम करता है.
[C-1-14] अलग-अलग क्रिप्टोग्राफ़िक कामों के लिए, एक ही फ़ाइल आधारित एन्क्रिप्शन (एफ़बीई) बटन या सबकी का इस्तेमाल नहीं करना चाहिए (जैसे, एन्क्रिप्ट (सुरक्षित) करने और कुंजी की शुरुआत करने, दोनों के लिए या एन्क्रिप्शन के दो अलग-अलग एल्गोरिदम के लिए).
[C-1-15] यह पक्का करना ज़रूरी है कि स्थायी स्टोरेज में एन्क्रिप्ट (सुरक्षित) की गई फ़ाइल के कॉन्टेंट के ऐसे सभी ब्लॉक जिन्हें नहीं मिटाया गया है, उन्हें एन्क्रिप्ट (सुरक्षित) करने की कुंजी और इनिशलाइज़ेशन वेक्टर (IV) के कॉम्बिनेशन का इस्तेमाल करके एन्क्रिप्ट (सुरक्षित) किया गया हो. यह वेक्टर, फ़ाइल और फ़ाइल में मौजूद ऑफ़सेट पर निर्भर करता है. इसके अलावा, ऐसे सभी कॉम्बिनेशन अलग-अलग होने चाहिए. हालांकि, उन जगहों को छोड़कर जहां इनलाइन एन्क्रिप्शन हार्डवेयर का इस्तेमाल करके एन्क्रिप्शन किया जाता है. यह हार्डवेयर सिर्फ़ 32 बिट की आईवी लंबाई के साथ काम करता है.
[C-1-16] यह पक्का करना ज़रूरी है कि अलग-अलग डायरेक्ट्री में स्थायी स्टोरेज में, मिटाए नहीं गए सभी एन्क्रिप्ट किए गए फ़ाइल नामों को एन्क्रिप्ट करने की कुंजी और इनिशलाइज़ेशन वेक्टर (IV) के अलग-अलग कॉम्बिनेशन का इस्तेमाल करके एन्क्रिप्ट किया गया हो.
[C-1-17] यह पक्का करना ज़रूरी है कि परसिस्टेंट स्टोरेज में सेव किए गए फ़ाइल सिस्टम मेटाडेटा ब्लॉक को, एन्क्रिप्ट (सुरक्षित) करने की कुंजी और इनिशलाइज़ेशन वेक्टर (IV) के अलग-अलग कॉम्बिनेशन का इस्तेमाल करके एन्क्रिप्ट (सुरक्षित) किया गया हो.
CE और DE स्टोरेज की जगहों और फ़ाइल सिस्टम के मेटाडेटा की सुरक्षा करने वाली कुंजियां:
- [C-1-7] हार्डवेयर-बैक्ड कीस्टोर से क्रिप्टोग्राफ़िक तौर पर जुड़ा होना ज़रूरी है. यह कीस्टोर वेरिफ़ाइड बूट और डिवाइस के हार्डवेयर के लिए भरोसेमंद होना चाहिए.
- [C-1-8] सीई कुंजियां इस्तेमाल करने वाले व्यक्ति के लॉक स्क्रीन क्रेडेंशियल से जुड़ी होनी चाहिए.
- [C-1-9] अगर उपयोगकर्ता ने लॉक स्क्रीन के क्रेडेंशियल की जानकारी नहीं दी है, तो CE पासकोड डिफ़ॉल्ट तौर पर सेट होना चाहिए.
- [C-1-10] यूनीक और अलग होना चाहिए. दूसरे शब्दों में, किसी भी उपयोगकर्ता की CE या DE कुंजी किसी दूसरे उपयोगकर्ता की CE या DE कुंजियों से मेल नहीं खाती.
- [C-1-11] ज़रूरी शर्तों को पूरा करने वाले साइफ़र, बटन की लंबाई, और मोड का इस्तेमाल करना ज़रूरी है.
- [C-1-12] बूटलोडर को अनलॉक और लॉक करने के दौरान, इसे सुरक्षित तरीके से मिटाना होगा. इसके बारे में यहां बताया गया है.
पहले से इंस्टॉल किए गए ज़रूरी ऐप्लिकेशन (जैसे, अलार्म, फ़ोन, मैसेंजर) बनाना चाहिए डायरेक्ट बूट की जानकारी.

अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट, Linux कर्नेल "fscrypt" एन्क्रिप्शन सुविधा के आधार पर फ़ाइल आधारित एन्क्रिप्शन और Linux कर्नेल "dm-default-key" सुविधा पर आधारित मेटाडेटा एन्क्रिप्शन को लागू करने की सुविधा देता है.

9.9.3.2. हर उपयोगकर्ता के लिए ब्लॉक-लेवल का एन्क्रिप्ट (सुरक्षित) करने का तरीका

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

[C-1-1] सेक्शन 9.5 में बताए गए तरीके के मुताबिक, एक से ज़्यादा उपयोगकर्ताओं के लिए सहायता उपलब्ध कराना ज़रूरी है.
[C-1-2] हर उपयोगकर्ता के लिए, रॉ पार्टीशन या लॉजिकल वॉल्यूम का इस्तेमाल करना ज़रूरी है.
[C-1-3] पहले से मौजूद ब्लॉक डिवाइसों को एन्क्रिप्ट (सुरक्षित) करने के लिए, हर उपयोगकर्ता के लिए खास और अलग एन्क्रिप्शन कुंजियों का इस्तेमाल करना ज़रूरी है.
[C-1-4] उपयोगकर्ता सेगमेंट को ब्लॉक-लेवल पर एन्क्रिप्ट (सुरक्षित) करने के लिए, AES-256-XTS का इस्तेमाल करना ज़रूरी है.
हर उपयोगकर्ता के ब्लॉक-लेवल के एन्क्रिप्ट (सुरक्षित) किए गए डिवाइसों की सुरक्षा करने वाली कुंजियां:
- [C-1-5] हार्डवेयर-बैक्ड कीस्टोर से क्रिप्टोग्राफ़िक तौर पर जुड़ा होना ज़रूरी है. यह कीस्टोर वेरिफ़ाइड बूट और डिवाइस के हार्डवेयर के लिए भरोसेमंद होना चाहिए.
- [C-1-6] ऐप्लिकेशन इस्तेमाल करने वाले व्यक्ति के लॉक स्क्रीन क्रेडेंशियल से जुड़ा होना ज़रूरी है.

हर उपयोगकर्ता के हिसाब से ब्लॉक-लेवल के एन्क्रिप्शन को, Linux कर्नेल की "dm-crypt" सुविधा का इस्तेमाल करके लागू किया जा सकता है. हर उपयोगकर्ता सेगमेंट के लिए ऐसा किया जा सकता है.

9.9.4. फिर से चालू करने के बाद, फिर से शुरू करें

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

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

खास तौर से:

[C-0-1] CE स्टोरेज को उस हमलावर के लिए भी पढ़ने लायक नहीं होना चाहिए जिसके पास डिवाइस मौजूद है और उसके बाद ये काम किए जा सकते हैं और कुछ सीमाएं तय की गई हैं:
- आर्बिट्रेरी मैसेज पर हस्ताक्षर करने के लिए, किसी भी वेंडर या कंपनी की साइनिंग पासकोड का इस्तेमाल कर सकता है.
- इसकी वजह से डिवाइस को ओटीए मिल सकता है.
- नीचे बताए गए विकल्पों को छोड़कर, किसी भी हार्डवेयर (एपी, फ़्लैश वगैरह) के काम करने के तरीके में बदलाव किया जा सकता है. हालांकि, इस तरह के बदलाव में कम से कम एक घंटे की देरी और रैम से जुड़े कॉन्टेंट को खत्म करने वाला पावर साइकल शामिल होता है.
- छेड़छाड़ से बचाने वाले हार्डवेयर (जैसे, Titan M) के काम करने के तरीके में बदलाव नहीं किया जा सकता.
- लाइव डिवाइस की रैम नहीं देखी जा सकती.
- उपयोगकर्ता का क्रेडेंशियल (पिन, पैटर्न, पासवर्ड) नहीं मिल सकता या उसे किसी वजह से डालने के लिए कहा जा सकता है.

उदाहरण के तौर पर, जो डिवाइस यहां दी गई सभी जानकारी लागू करता है और उनका पालन करता है वह [C-0-1] के मुताबिक होगा.

9.10. डिवाइस इंटिग्रिटी

इन ज़रूरी शर्तों से यह पक्का किया जाता है कि डिवाइस इंटिग्रिटी की स्थिति की जानकारी साफ़ तौर पर दी जाए. डिवाइस पर यह सुविधा लागू करना:

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

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

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

[C-1-1] प्लैटफ़ॉर्म के फ़ीचर फ़्लैग के बारे में बताना ज़रूरी है android.software.verified_boot.
[C-1-2] ज़रूरी है कि हर बूट क्रम पर पुष्टि करनी हो.
[C-1-3] ज़रूरी है कि नहीं बदले जा सकने वाले हार्डवेयर कुंजी से, पुष्टि की प्रोसेस शुरू की जाए. यह कुंजी, ट्रस्ट का मूल रूप है और इसे सिस्टम पार्टिशन के लिए इस्तेमाल किया जाता है.
[C-1-4] कोड को अगले चरण में लागू करने से पहले, पुष्टि करने के हर चरण को लागू करना ज़रूरी है. इससे अगले चरण में सभी बाइट के भरोसेमंद और सही होने की जांच की जा सकती है.
[C-1-5] हैशिंग एल्गोरिदम (SHA-256) और सार्वजनिक पासकोड (RSA-2048) के लिए, पुष्टि करने वाले एल्गोरिदम का इस्तेमाल एनआईएसटी के मौजूदा सुझावों जितने ही मज़बूत करना ज़रूरी है.
[C-1-6] सिस्टम की पुष्टि न हो पाने पर, डिवाइस को बूट करने की अनुमति नहीं देनी चाहिए. ऐसा तब तक नहीं होना चाहिए, जब तक उपयोगकर्ता डिवाइस को बूट करने की कोशिश न करे. ऐसे में, ऐसे स्टोरेज ब्लॉक के डेटा का इस्तेमाल नहीं किया जाएगा जिसकी पुष्टि नहीं हुई है.
[C-1-7] जब तक उपयोगकर्ता साफ़ तौर पर बूटलोडर को अनलॉक न कर दे, तब तक डिवाइस के पुष्टि किए गए हिस्सों में बदलाव करने की अनुमति नहीं देनी चाहिए.
[C-SR-1] डिवाइस में कई अलग-अलग चिप (जैसे, रेडियो, किसी खास इमेज प्रोसेसर) होने पर, हर चिप को चालू करने का सुझाव दिया जाता है, ताकि बूट होने के दौरान हर चरण की पुष्टि की जा सके.
[C-1-8] छेड़छाड़ करके साफ़ तौर पर दिखने वाले स्टोरेज का इस्तेमाल करना ज़रूरी है: इससे यह पता लगाया जा सकता है कि बूटलोडर अनलॉक है या नहीं. छेड़छाड़ होने पर पता चलने वाले स्टोरेज का मतलब है कि बूटलोडर यह पता लगा सकता है कि Android के अंदर के स्टोरेज के साथ छेड़छाड़ की गई है या नहीं.
[C-1-9] डिवाइस इस्तेमाल करते समय, लोगों को निर्देश देना ज़रूरी है. साथ ही, उन्हें बूटलोडर के लॉक किए गए मोड से बूटलोडर अनलॉक मोड में जाने से पहले पुष्टि करनी होगी.
[C-1-10] Android में इस्तेमाल किए जाने वाले हिस्सों (जैसे कि बूट, सिस्टम पार्टिशन) के लिए रोलबैक सुरक्षा लागू करना ज़रूरी है. साथ ही, ओएस के सबसे कम वर्शन का पता लगाने के लिए इस्तेमाल किए गए मेटाडेटा को सेव करने के लिए, ऐसे स्टोरेज का इस्तेमाल करें जिससे छेड़छाड़ न की जा सके.
[C-1-11] बूटलोडर को अनलॉक और लॉक करने के दौरान, '9.12' के मुताबिक, उपयोगकर्ता का सारा डेटा सुरक्षित तरीके से हमेशा के लिए मिटाना ज़रूरी है. डेटा मिटाना' (इसमें उपयोगकर्ता के डेटा का बंटवारा और एनवीआरएएम स्पेस शामिल हैं).
[C-SR-2] खास अधिकार वाली सभी ऐप्लिकेशन APK फ़ाइलों की पुष्टि करने के लिए इस बात पर ज़ोर दिया जाता है कि पुष्टि की गई बूट के ज़रिए सुरक्षित किए गए विभाजनों में मौजूद ट्रस्ट की एक चेन के साथ.
[C-SR-3] किसी खास ऐप्लिकेशन की APK फ़ाइल के बाहर से लोड किए गए एक्ज़ीक्यूटेबल आर्टफ़ैक्ट (जैसे, डाइनैमिक तरीके से लोड किया गया कोड या कंपाइल किया गया कोड) की पुष्टि करने के लिए इस बात का बहुत ज़्यादा सुझाव दिया जाता है. इसके अलावा, बहुत ज़्यादा सुझाव दिया जाता है कि उन आर्टफ़ैक्ट को एक्ज़ीक्यूट न किया जाए.
स्थायी फ़र्मवेयर (जैसे मॉडम, कैमरा) वाले किसी भी कॉम्पोनेंट के लिए रोलबैक सुरक्षा लागू करनी चाहिए. साथ ही, कम से कम अनुमति वाले वर्शन का पता लगाने के लिए इस्तेमाल किए गए मेटाडेटा को स्टोर करने के लिए, ऐसे स्टोरेज का इस्तेमाल करना चाहिए जिससे छेड़छाड़ न की गई हो.

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

अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट, external/avb/ डेटा स्टोर करने की जगह में इस सुविधा को बेहतर तरीके से लागू करने की सुविधा देता है. इसे Android लोड करने के लिए इस्तेमाल किए जाने वाले बूटलोडर में इंटिग्रेट किया जा सकता है.

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

[C-0-3] पूरी फ़ाइल पढ़े बिना, भरोसेमंद कुंजी के ज़रिए फ़ाइल के कॉन्टेंट की पुष्टि करने की सुविधा क्रिप्टोग्राफ़िक तरीके से काम करनी चाहिए.
[C-0-4] किसी सुरक्षित फ़ाइल पर पढ़ने के अनुरोधों को तब पूरा होने की अनुमति नहीं देनी चाहिए, जब पढ़े गए कॉन्टेंट की किसी भरोसेमंद कुंजी से पुष्टि न हो जाए.

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

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

[C-SR-4] Android Protected Safety API के साथ काम करने के लिए, इस बात का खास तौर पर सुझाव दिया जाता है.

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

[C-3-1] ConfirmationPrompt.isSupported() एपीआई के लिए, true को रिपोर्ट करना ज़रूरी है.
[C-3-2] यह पक्का करना ज़रूरी है कि Android OS में जो कोड चल रहा है वह उपयोगकर्ता के इंटरैक्शन के बिना पॉज़िटिव रिस्पॉन्स जनरेट न कर सके. भले ही, यह कोड नुकसान पहुंचाने वाला हो या फिर किसी दूसरे तरीके का.
[C-3-3] यह पक्का करना ज़रूरी है कि उपयोगकर्ता, बताए गए मैसेज को पढ़कर उसे स्वीकार कर पाए हों, भले ही Android OS और उसके कर्नेल के साथ छेड़छाड़ की गई हो.

9.11. कुंजियां और क्रेडेंशियल

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

[C-0-1] कम से कम 8,192 कुंजियों को इंपोर्ट या जनरेट करने की अनुमति देनी होगी.
[C-0-2] लॉक स्क्रीन की पुष्टि करने की प्रक्रिया में, सफल न होने वाली कोशिशों के बीच का समय अंतराल लागू करना ज़रूरी है. n होने पर, 9 < n < 30 के लिए, टाइम इंटरवल कम से कम 30 सेकंड का होना चाहिए. इसमें उन जगहों की गिनती नहीं की जा सकी जिन्हें पूरा नहीं किया जा सका. n > 29 के लिए, टाइम इंटरवल की वैल्यू कम से कम 30*2^floor((n-30)/10)) सेकंड होनी चाहिए या कम से कम 24 घंटे (दोनों में से जो भी कम हो) होनी चाहिए.
जनरेट की जा सकने वाली कुंजियों की संख्या को सीमित नहीं किया जाना चाहिए

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

[C-1-1] कीस्टोर को लागू करने के लिए, एक अलग एक्ज़ीक्यूशन एनवायरमेंट का इस्तेमाल करना ज़रूरी है.
[C-1-2] आरएसए, एईएस, ईसीडीएसए, ECDH (अगर IKeyMintDevice काम करता है), 3DES, और HMAC क्रिप्टोग्राफ़िक एल्गोरिदम और MD5, SHA1, और SHA-2 फ़ैमिली हैश फ़ंक्शन लागू करने चाहिए, ताकि Android कीस्टोर सिस्टम के साथ काम करने वाले एल्गोरिदम के काम करने में मदद मिल सके. यह सुविधा, Android कीस्टोर सिस्टम के साथ काम करने वाले एल्गोरिदम के लिए सही तरीके से काम करती है. ऐसा करने से, कर्नेल के ऊपर चल रहे कोड से, सुरक्षित तरीके से अलग किया जाता है. सिक्योर आइसोलेशन से उन सभी संभावित मैकेनिज़्म को ब्लॉक कर देना चाहिए जिनकी मदद से कर्नेल या यूज़रस्पेस कोड, डीएमए के साथ-साथ आइसोलेटेड एनवायरमेंट की अंदरूनी स्थिति को ऐक्सेस कर सकते हैं. अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट (एओएसपी), Trusty लागू करने की सुविधा का इस्तेमाल करके इस ज़रूरी शर्त को पूरा करता है. हालांकि, ARM TrustZone पर आधारित कोई दूसरा समाधान या Hypervisor-आधारित आइसोलेशन के लिए, तीसरे पक्ष की ओर से समीक्षा किए गए सुरक्षित इंप्लिमेंटेशन के विकल्प, विकल्प हैं.
[C-1-3] आपको लॉक स्क्रीन की पुष्टि, अलग-अलग डिवाइसों पर करना ज़रूरी है. पुष्टि करने का काम पूरा होने पर ही, पुष्टि करने वाली कुंजियों का इस्तेमाल करने की अनुमति दें. लॉक स्क्रीन के क्रेडेंशियल को ऐसे तरीके से सेव किया जाना चाहिए जिससे लॉक स्क्रीन की पुष्टि करने के लिए, सिर्फ़ अलग-अलग एनवायरमेंट को ऐक्सेस किया जा सके. अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट, गेटकीपर हार्डवेयर ऐब्स्ट्रैक्शन लेयर (HAL) और ट्रस्टी उपलब्ध कराता है. इनका इस्तेमाल, इस ज़रूरी शर्त को पूरा करने के लिए किया जा सकता है.
[C-1-4] कुंजी को प्रमाणित करने की सुविधा दी जानी चाहिए, जहां पुष्टि करने वाले साइनिंग पासकोड को सुरक्षित हार्डवेयर से सुरक्षित किया गया हो और सुरक्षित हार्डवेयर में हस्ताक्षर किया जाता हो. पुष्टि करने के लिए इस्तेमाल होने वाली कुंजियों को कई डिवाइसों के साथ शेयर करना ज़रूरी है, ताकि इनका इस्तेमाल डिवाइस आइडेंटिफ़ायर के तौर पर न किया जा सके. इस ज़रूरी शर्त को पूरा करने का एक तरीका यह है कि पुष्टि करने वाली एक ही कुंजी शेयर की जाए. ऐसा तब तक किया जा सकता है, जब तक किसी SKU की कम से कम 1,00,000 यूनिट न बनाई गई हों. अगर किसी SKU की 1,00,000 से ज़्यादा इकाइयां बनाई जाती हैं, तो हर 1,00,000 इकाइयों के लिए अलग-अलग कुंजी का इस्तेमाल किया जा सकता है.

[C-1-5] उपयोगकर्ता को यह तय करने की अनुमति देनी होगी कि अनलॉक किए गए से लॉक की स्थिति में स्विच करने के लिए, स्लीप टाइम आउट का समय तय किया जा सकता है. साथ ही, 15 सेकंड तक का टाइम आउट होना चाहिए. ऑटोमोटिव डिवाइस ऐसे होते हैं जो हेड यूनिट के बंद होने या उपयोगकर्ता के स्विच होने पर स्क्रीन लॉक कर देते हैं. इनमें शायद स्लीप टाइम आउट का कॉन्फ़िगरेशन न हो.
[C-1-6] इनमें से किसी एक पर काम करना ज़रूरी है:
- IKeyMasterDevice 3.0,
- IKeyMasterDevice 4.0,
- IKeyMasterDevice 4.1,
- IKeyMintDevice वर्शन 1 या
- IKeyMintDevice वर्शन 2.
[C-SR-1] को IKeyMintडिवाइस वर्शन 1 के साथ काम करने के लिए इस्तेमाल करने का बहुत ज़्यादा सुझाव दिया जाता है.

9.11.1. सुरक्षित लॉक स्क्रीन, पुष्टि, और वर्चुअल डिवाइस

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

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

[C-SR-1] को पुष्टि करने के लिए, इनमें से किसी एक को ही मुख्य तरीके के तौर पर सेट करने का सुझाव दिया जाता है:
- अंकों वाला पिन
- अक्षरों और अंकों से बना पासवर्ड
- 3x3 बिंदुओं के ग्रिड पर स्वाइप पैटर्न

ध्यान दें कि ऊपर दिए गए पुष्टि करने के तरीकों को, इस दस्तावेज़ में पुष्टि के लिए सुझाए गए मुख्य तरीकों के तौर पर जाना जाता है.

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

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

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

[C-3-1] इनपुट की सबसे कम लंबाई की एंट्रॉपी 10 बिट से ज़्यादा होनी चाहिए.
[C-3-2] सभी संभावित इनपुट की ज़्यादा से ज़्यादा एंट्रॉपी 18 बिट से ज़्यादा होनी चाहिए.
[C-3-3] पुष्टि करने के नए तरीके को एओएसपी में लागू और उपलब्ध कराए गए, पुष्टि करने के किसी भी मुख्य तरीके (जैसे, पिन, पैटर्न, पासवर्ड) की जगह इस्तेमाल नहीं करना चाहिए.
[C-3-4] पुष्टि करने के नए तरीके को तब बंद करना ज़रूरी है, जब डिवाइस पॉलिसी कंट्रोलर (DPC) ऐप्लिकेशन ने DevicePolicyManager.setrequiredPasswordComplexity() के ज़रिए पासवर्ड से जुड़ी ज़रूरी नीति सेट की हो. इस तरीके में, ज़्यादा जटिल जटिलता Password_COMPL फ़ंक्शनY_NONE से ज़्यादा पाबंदी वाली होती है या DevicePolicyManager.set QualityPassword() की तुलना में ज़्यादा पाबंदी वाले Password_परफ़ॉर्मेंस.

[C-3-5] पुष्टि करने के नए तरीकों के लिए, हर 72 घंटे या उससे कम समय में एक बार, सुझाए गए मुख्य तरीकों, जैसे कि पिन, पैटर्न, पासवर्ड का इस्तेमाल करना ज़रूरी है. इसके अलावा, उपयोगकर्ता को साफ़ तौर पर यह बताया जाना चाहिए कि उनके डेटा की निजता को बनाए रखने के लिए, कुछ डेटा का बैक अप नहीं लिया जाएगा.

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

[C-4-1] क्लास 1 (पहले इसे सुविधा के नाम से जाना जाता था) के लिए, सेक्शन 7.3.10 में बताई गई सभी ज़रूरी शर्तों को पूरा करना होगा.
[C-4-2] पुष्टि करने के लिए सुझाए गए मुख्य तरीकों में से किसी एक का इस्तेमाल करने के लिए, फ़ॉल-बैक तरीका (फ़ॉल-बैक तरीका) होना चाहिए. यह तरीका, पुष्टि करने के एक ऐसे मुख्य तरीके पर आधारित है जिसके बारे में पहले से जानकारी है.
[C-4-3] आपको बंद करना होगा और स्क्रीन को अनलॉक करने के लिए, सिर्फ़ सुझाए गए मुख्य ऑथेंटिकेशन को अनुमति देनी होगी. ऐसा तब करें, जब डिवाइस पॉलिसी कंट्रोलर (डीपीसी) ऐप्लिकेशन ने किसी भी जुड़े बायोमेट्रिक फ़्लैग (जैसे KEYGUARD_DISABLE_BIOMETRICS, KEYGUARD_DISABLE_FINGERPRINT, KEYGUARD_DISABLE_FACE या KEYGUARD_DISABLE_IRIS) का इस्तेमाल करके, तरीके DevicePolicyManager.setKeyguardDisabledFeatures() को कॉल करके कीगार्ड सुविधा की नीति सेट कर दी हो.

अगर बायोमेट्रिक तरीके से पुष्टि करने के तरीके, क्लास 3 (पहले स्ट्रॉन्ग के नाम से जाना जाता था) की ज़रूरी शर्तें पूरी नहीं करते, जैसा कि सेक्शन 7.3.10 में बताया गया है, तो:

[C-5-1] अगर डिवाइस पॉलिसी कंट्रोलर (डीपीसी) ऐप्लिकेशन ने पासवर्ड से जुड़ी ज़रूरी शर्तों की क्वालिटी की नीति सेट की है, तो इन तरीकों को बंद करना ज़रूरी है. इसके लिए, DevicePolicyManager.setज़रूरीPasswordComplexity() के ज़रिए, PASSWORD_COMPLEXITY_LOW के मुकाबले ज़्यादा मुश्किल वाले कॉम्प्लेक्सिटी बकेट का इस्तेमाल किया जाता है या DevicePolicyManager.setPassword Quality() तरीके का इस्तेमाल किया जाता है.PASSWORD_QUALITY_BIOMETRIC_WEAK
[C-5-2] उपयोगकर्ता से, सुझाए गए मुख्य पुष्टि (जैसे: पिन, पैटर्न, पासवर्ड) के लिए चुनौती दी जानी चाहिए, जैसा कि सेक्शन 7.3.10 में [C-1-7] और [C-1-8] में बताया गया है.
[C-5-3] इन तरीकों को सुरक्षित लॉक स्क्रीन नहीं मानना चाहिए. साथ ही, इस सेक्शन में दी गई जानकारी को C-8 से शुरू होने वाली ज़रूरी शर्तों को पूरा करना होगा.

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

[C-6-1] उनके पास पुष्टि करने के सुझाए गए प्राथमिक तरीकों में से किसी एक का इस्तेमाल करने के लिए, फ़ॉल-बैक तरीका (फ़ॉल-बैक तरीका) होना चाहिए. यह तरीका, जाने-पहचाने सीक्रेट जानकारी पर आधारित होता है. साथ ही, इन्हें सुरक्षित लॉक स्क्रीन मानने से जुड़ी ज़रूरी शर्तें पूरी करनी होती हैं.
[C-6-2] आपको इस नए तरीके को बंद करना होगा. इसके लिए, डिवाइस नीति नियंत्रक (डीपीसी) ऐप्लिकेशन की मदद से नीति सेट करने के बाद, पुष्टि करने के सुझाए गए मुख्य तरीकों में से सिर्फ़ किसी एक को स्क्रीन अनलॉक करने की अनुमति देनी होगी:
- DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) तरीका
- DevicePolicyManager.setPasswordQuality() ऐसा तरीका जिसमें PASSWORD_QUALITY_NONE की तुलना में ज़्यादा पाबंदी वाली क्वालिटी हो.
- DevicePolicyManager.setRequiredPasswordComplexity() वाला ऐसा तरीका जिसमें PASSWORD_COMPLEXITY_NONE की तुलना में ज़्यादा जटिल कॉम्प्लेक्सिटी बकेट होती है.
[C-6-3] उपयोगकर्ता को हर चार घंटे में कम से कम एक बार, पुष्टि करने के सुझाए गए मुख्य तरीकों (जैसे, पिन, पैटर्न, पासवर्ड) में से किसी एक को अपनाना होगा. जब कोई फ़िज़िकल टोकन, C-X में TrustAgent लागू करने की ज़रूरी शर्तों को पूरा करता है, तो C-9-5 में बताई गई टाइम आउट से जुड़ी पाबंदियां लागू होती हैं.
[C-6-4] नए तरीके को सुरक्षित लॉक स्क्रीन नहीं माना जाना चाहिए. साथ ही, यहां C-8 में बताई गई शर्तों का पालन करना ज़रूरी है.

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

[C-7-1] डिवाइस के लॉक में देरी होने या उसे भरोसेमंद एजेंट की मदद से अनलॉक किए जाने पर, सेटिंग मेन्यू और लॉक स्क्रीन पर साफ़ तौर पर इसकी जानकारी दी जानी चाहिए. उदाहरण के लिए, एओएसपी इस ज़रूरी शर्त को पूरा करने के लिए, सेटिंग मेन्यू में "अपने-आप लॉक होने की सेटिंग" और "पावर बटन से तुरंत लॉक हो जाता है" टेक्स्ट की जानकारी दिखाता है. साथ ही, लॉक स्क्रीन पर एक अलग आइकॉन भी दिखता है.
[C-7-2] DevicePolicyManager क्लास में सभी ट्रस्ट एजेंट एपीआई का पालन करना चाहिए और उन्हें पूरी तरह से लागू करना चाहिए. जैसे, KEYGUARD_DISABLE_TRUST_AGENTS कॉन्सटेंट.
[C-7-3] मुख्य निजी डिवाइस (जैसे कि हैंडहेल्ड) के तौर पर इस्तेमाल किए जाने वाले डिवाइस पर, TrustAgentService.addEscrowToken() फ़ंक्शन को पूरी तरह लागू नहीं करना चाहिए. हालांकि, इसे आम तौर पर शेयर किए गए डिवाइस (जैसे, Android Television या Automotive डिवाइस) पर पूरी तरह लागू करना चाहिए.
[C-7-4] TrustAgentService.addEscrowToken() के जोड़े गए सभी स्टोर किए गए टोकन को एन्क्रिप्ट (सुरक्षित) करना ज़रूरी है.
[C-7-5] एन्क्रिप्ट (सुरक्षित) करने वाली कुंजी या एस्क्रो टोकन को उस डिवाइस पर सेव नहीं किया जाना चाहिए जिस पर कुंजी का इस्तेमाल किया गया है. उदाहरण के लिए, फ़ोन पर सेव की गई कुंजी के ज़रिए, टीवी पर उपयोगकर्ता के खाते को अनलॉक किया जा सकता है. वाहन संबंधित डिवाइसों के लिए, वाहन के किसी भी हिस्से पर एस्क्रो टोकन सेव करने की अनुमति नहीं है.
[C-7-6] डेटा स्टोरेज को डिक्रिप्ट करने के लिए, एस्क्रो टोकन चालू करने से पहले उपयोगकर्ता को सुरक्षा से जुड़ी समस्याओं के बारे में बताना ज़रूरी है.
[C-7-7] पुष्टि करने के लिए सुझाए गए मुख्य तरीकों में से किसी एक का इस्तेमाल करने के लिए, फ़ॉल-बैक का तरीका होना ज़रूरी है.
[C-7-8] उपयोगकर्ता को पुष्टि करने के सुझाए गए मुख्य तरीकों (जैसे: पिन, पैटर्न, पासवर्ड) में से किसी एक को अपनाने के लिए, हर 72 घंटे में कम से कम एक बार चुनौती देनी होगी. ऐसा तब तक होना चाहिए, जब तक उपयोगकर्ता की सुरक्षा को लेकर कोई समस्या न हो (जैसे, ड्राइवर का ध्यान भटकना).
[C-7-9] उपयोगकर्ता को पुष्टि करने के लिए सेक्शन 7.3.10 में [C-1-7] और [C-1-8] में बताए गए किसी एक मुख्य तरीके (जैसे कि पिन, पैटर्न, पासवर्ड) के लिए चुनौती दी जानी चाहिए, बशर्ते उसमें उपयोगकर्ता की सुरक्षा को लेकर कोई खतरा न हो (जैसे कि ड्राइवर का ध्यान भटकाना).
[C-7-10] को सुरक्षित लॉक स्क्रीन नहीं माना जाना चाहिए और नीचे C-8 में बताई गई शर्तों का पालन करना चाहिए.
[C-7-11] प्राइमरी निजी डिवाइसों (जैसे कि हैंडहेल्ड) पर TrustAgents को अनलॉक करने की अनुमति नहीं है.वे इनका इस्तेमाल सिर्फ़ पहले से अनलॉक किए गए डिवाइस को ज़्यादा से ज़्यादा चार घंटे तक अनलॉक रखने के लिए कर सकते हैं. एओएसपी में TrustManagerService को डिफ़ॉल्ट रूप से लागू करने की सुविधा इस ज़रूरी शर्त को पूरा करती है.
[C-7-12] स्टोरेज डिवाइस से टारगेट किए गए डिवाइस में एस्क्रो टोकन भेजने के लिए, क्रिप्टोग्राफ़िक तौर पर सुरक्षित कम्यूनिकेशन चैनल (जैसे, UKEY2) का इस्तेमाल करना ज़रूरी है.

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

[C-8-1] जब डिवाइस पॉलिसी कंट्रोलर (डीपीसी) ऐप्लिकेशन ने DevicePolicyManager.setPasswordQuality() तरीके के ज़रिए, पासवर्ड की क्वालिटी की नीति सेट की है, तो इस नए तरीके को बंद करना ज़रूरी है. इसके लिए, PASSWORD_QUALITY_NONE से ज़्यादा सीमित क्वालिटी वाले कॉन्स्टेंट या DevicePolicyManager.setRequiredPasswordComplexity() का इस्तेमाल किया गया है. हालांकि, इस नए तरीके को 'Password_COMPL फ़ंक्शनY_NONE' के मुकाबले ज़्यादा जटिल तरीके से इस्तेमाल किया गया है.
[C-8-2] उन्हें DevicePolicyManager.setPasswordExpirationTimeout() ने जो पासवर्ड खत्म होने की तारीख सेट की है उसे रीसेट नहीं करना होगा.
[C-8-3] लॉक की स्थिति बदलने के लिए, तीसरे पक्ष के ऐप्लिकेशन को एपीआई का इस्तेमाल करने की अनुमति नहीं देनी चाहिए.

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

[C-9-1] डिवाइस का डिफ़ॉल्ट डिसप्ले लॉक होने पर, आपको इन सेकंडरी वर्चुअल डिसप्ले को लॉक करना होगा. साथ ही, डिवाइस का डिफ़ॉल्ट डिसप्ले अनलॉक होने पर, इन सेकंडरी वर्चुअल डिसप्ले को भी अनलॉक करना होगा.

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

[C-10-1] हर वर्चुअल डिवाइस के लिए, अलग-अलग लॉक स्टेटस का इस्तेमाल करना ज़रूरी है
[C-10-2] इस्तेमाल न होने पर टाइम आउट होने पर, सभी वर्चुअल डिवाइसों को डिसकनेक्ट करना ज़रूरी है
[C-10-3] एक टाइम आउट होना ज़रूरी है
[C-10-4] उपयोगकर्ता के लॉकडाउन शुरू करने पर, सभी स्क्रीन को लॉक करना ज़रूरी है. इसमें लॉकडाउन के तहत, हैंडहेल्ड डिवाइस इस्तेमाल करने के लिए ज़रूरी कीमत भी शामिल है (सेक्शन 2.2.5[9.11/H-1-2] देखें)
[C-10-5] हर उपयोगकर्ता के लिए, वर्चुअल डिवाइस का अलग-अलग इंस्टेंस होना ज़रूरी है
[C-10-6] DevicePolicyManager.setNearbyAppStreamingPolicy से संकेत मिलने पर, VirtualDeviceManager के ज़रिए इससे जुड़े इनपुट इवेंट बनाने की सुविधा बंद करनी होगी
[C-10-7] हर वर्चुअल डिवाइस के लिए, सिर्फ़ एक अलग क्लिपबोर्ड का इस्तेमाल करना होगा या वर्चुअल डिवाइसों के लिए क्लिपबोर्ड को बंद करना होगा
[C-10-11] वर्चुअल डिवाइसों पर पुष्टि करने वाले यूज़र इंटरफ़ेस (यूआई) को बंद करना ज़रूरी है. इसमें नॉलेज फ़ैक्टर एंट्री और बायोमेट्रिक प्रॉम्प्ट शामिल हैं
[C-10-12] किसी वर्चुअल डिवाइस से शुरू किए गए इंटेंट को सिर्फ़ उसी वर्चुअल डिवाइस पर दिखाने के लिए प्रतिबंधित करना ज़रूरी है
[C-10-13] Android कीस्टोर सिस्टम से उपयोगकर्ता की पुष्टि करने की अनुमति के तौर पर, वर्चुअल डिवाइस लॉक की स्थिति का इस्तेमाल नहीं करना चाहिए. KeyGenParameterSpec.Builder.setUserAuthentication* देखें.

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

[C-11-1] आपको सोर्स डिवाइस से टारगेट किए गए डिवाइस पर नॉलेज-फ़ैक्टर का इस्तेमाल करते समय, सुरक्षा की गारंटी वाली जानकारी को एन्क्रिप्ट (सुरक्षित) करना चाहिए. यह जानकारी, Google Cloud Key Vault सेवा के सुरक्षा व्हाइट पेपर में दी गई जानकारी से मिलती-जुलती है.
[C-11-2] टारगेट डिवाइस पर नॉलेज-फ़ैक्टर ट्रांसफ़र करने से पहले, उपयोगकर्ता से सोर्स डिवाइस के नॉलेज-फ़ैक्टर की पुष्टि करने के लिए कहें.
[C-11-3] अगर टारगेट किए गए किसी डिवाइस पर, पुष्टि करने का कोई मुख्य तरीका नहीं है, तो उपयोगकर्ता को उस डिवाइस पर ट्रांसफ़र किए गए नॉलेज-फ़ैक्टर की पुष्टि करने के लिए कहें. इसके बाद ही, टारगेट डिवाइस के लिए, नॉलेज-फ़ैक्टर को मुख्य डिवाइस के तौर पर सेट करना होगा. साथ ही, सोर्स डिवाइस से ट्रांसफ़र किया गया कोई भी डेटा उपलब्ध कराना होगा.

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

[C-12-1] फ़्लैग वाले grantTrust() को सिर्फ़ तब कॉल करना ज़रूरी है, जब वह किसी नज़दीकी डिवाइस की लॉकस्क्रीन से कनेक्ट हो. साथ ही, जब उपयोगकर्ता ने लॉकस्क्रीन पर अपनी पहचान की पुष्टि की हो. उपयोगकर्ता की पुष्टि करने से जुड़ी ज़रूरी शर्तों को पूरा करने के लिए, एक बार इस्तेमाल करने वाले व्यक्ति के अनलॉक करने के बाद, आस-पास मौजूद डिवाइस स्मार्टवॉच से या शरीर पर पहनने की पहचान करने के तरीकों का इस्तेमाल कर सकते हैं.
[C-12-2] स्क्रीन बंद होने पर (जैसे, बटन दबाने पर या डिसप्ले का समय खत्म होने पर) डिवाइस को लागू करने की प्रोसेस को TrustState.TRUSTABLE वाले स्टेटस में डालना ज़रूरी है और TrustAgent ने भरोसे को वापस नहीं लिया है. एओएसपी इस ज़रूरी शर्त को पूरा करता है.
[C-12-3] डिवाइस को TrustState.TRUSTABLE से TrustState.TRUSTED वाली स्थिति में सिर्फ़ तब ले जाना चाहिए, जब TrustAgent अब भी C-12-1 में दी गई ज़रूरी शर्तों के हिसाब से भरोसा दे रहा है.
[C-12-4] TrustManagerService.revokeTrust() पर कॉल करना ज़रूरी है
- भरोसा देने के 24 घंटों के बाद या
- 8 घंटे की निष्क्रिय विंडो के बाद या
- अगर लागू करने की प्रोसेस, [C-12-5] में बताई गई रेंज के मुताबिक क्रिप्टोग्राफ़िक तौर पर सुरक्षित और सटीक नहीं है, तो डिवाइस का इस्तेमाल नहीं किया जा सकता.
[C-12-5] ऐसे लागू करने के लिए नीचे दिए गए विकल्पों में से किसी एक का इस्तेमाल करना ज़रूरी है जो [C-12-4] की ज़रूरी शर्तों को पूरा करते हैं और सुरक्षित और सटीक होते हैं:
- यूडब्ल्यूबी टेक्नोलॉजी का इस्तेमाल करके सुविधाएं लागू करना:
  - ज़रूरी है कि यूडब्ल्यूबी के लिए, नियमों के पालन, सर्टिफ़िकेशन, सटीक होने, और कैलिब्रेशन की ज़रूरी शर्तों को पूरा किया जाए. इन शर्तों के बारे में 7.4.9 में बताया गया है.
  - आपको 7.4.9 में बताए गए पी-एसटीएस सुरक्षा मोड में से किसी एक का इस्तेमाल करना होगा.
- वाई-फ़ाई नेबरहुड अवेयरनेस नेटवर्किंग (एनएएन) का इस्तेमाल करके लागू करना:
  - इसे 2.2.1 [7.4.2.5/H-SR-1] में दी गई सटीक जानकारी से जुड़ी ज़रूरी शर्तों को पूरा करना होगा. साथ ही, 160 मेगाहर्ट्ज़ बैंडविथ (या इससे ज़्यादा) का इस्तेमाल करना होगा और मौजूदगी कैलिब्रेशन में दिए गए मेज़रमेंट सेटअप के चरणों को पूरा करना होगा.
  - Secure LTF का इस्तेमाल करना ज़रूरी है, जैसा कि IEEE 802.11az में बताया गया है.

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

[C-13-8] android:canDisplayOnRemoteDevices एट्रिब्यूट वाली गतिविधियों को ब्लॉक करना ज़रूरी है या मेटा-data android.activity.can_display_on_remote_devices को वर्चुअल डिवाइस पर शुरू होने से रोकने के लिए 'गलत' पर सेट करना.
[C-13-9] ऐसी गतिविधियों को ब्लॉक करना ज़रूरी है जो साफ़ तौर पर स्ट्रीमिंग की सुविधा चालू न करती हों. साथ ही, इनसे यह भी पता चलता हो कि वे वर्चुअल डिवाइस पर SurfaceView#setSecure, FLAG_SECURE, या system_FLAG_HIDE_NON_system_OVERLAY_WINDOWS के ज़रिए चालू होती हैं.

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

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

9.11.2. स्ट्रॉन्गबॉक्स

Android कीस्टोर सिस्टम, ऐप्लिकेशन डेवलपर को क्रिप्टोग्राफ़िक कुंजियों को किसी सुरक्षित प्रोसेसर में सेव करने देता है. साथ ही, वे इसे इस्तेमाल करने के लिए ऊपर बताए गए, अलग-अलग एनवायरमेंट में भी सेव कर सकते हैं. ऐसे अच्छे सुरक्षित प्रोसेसर को "StrongBox" कहा जाता है. यहां C-1-3 से लेकर C-1-11 तक की ज़रूरी शर्तों के बारे में बताया गया है. इससे पता चलता है कि StrongBox का ऐक्सेस पाने के लिए, डिवाइस को किन ज़रूरी शर्तों को पूरा करना होगा.

लागू किए गए डिवाइस जिनमें एक खास सुरक्षित प्रोसेसर होता है:

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

अगर डिवाइस लागू करने की सुविधा StrongBox के साथ काम करती है, तो वे:

[C-1-1] FEATURE_STRONGBOX_KEYSTORE का एलान करना ज़रूरी है.
[C-1-2] खास तौर पर सुरक्षित हार्डवेयर देना ज़रूरी है, जिसका इस्तेमाल की-स्टोर के बैक अप और उपयोगकर्ता की पुष्टि करने को सुरक्षित बनाने के लिए किया जाता है. खास तौर पर बने सुरक्षित हार्डवेयर का इस्तेमाल, दूसरे कामों के लिए भी किया जा सकता है.
[C-1-3] ज़रूरी है कि आपके पास एक अलग सीपीयू हो, जो ऐप्लिकेशन प्रोसेसर (एपी) के साथ कैश, डीरैम, को-प्रोसेसर या दूसरे मुख्य रिसोर्स शेयर नहीं करता हो.
[C-1-4] ज़रूरी है कि AP के साथ शेयर किया गया कोई भी सहायक डिवाइस, StrongBox की प्रोसेसिंग में किसी भी तरह से बदलाव न कर पाए या StrongBox से कोई जानकारी हासिल न कर सके. एपी, StrongBox का ऐक्सेस बंद कर सकता है या ब्लॉक कर सकता है.
[C-1-5] ज़रूरी सटीक (+-10%) वाली एक इंटरनल क्लॉक होनी चाहिए जिस पर AP की ओर से हेर-फेर नहीं किया जा सकता.
[C-1-6] ज़रूरी है कि एक रैंडम नंबर जनरेटर हो जो एक ही तरीके से डिस्ट्रिब्यूट किया गया और ऐसा आउटपुट देता हो जिसका अनुमान न लगाया जा सके.
[C-1-7] डिवाइस को छेड़छाड़ से बचाने की झंझट ज़रूरी है. इसमें, किसी चीज़ की
[C-1-8] साइड-चैनल रेज़िस्टेंस ज़रूरी है. इसमें पावर, टाइमिंग, इलेक्ट्रोमैग्नेटिक रेडिएशन, और थर्मल रेडिएशन साइड चैनल से जानकारी लीक होने से रोकने की क्षमता शामिल है.
[C-1-9] कॉन्टेंट को सुरक्षित तरीके से सेव करना ज़रूरी है. इससे कॉन्टेंट की गोपनीयता, पूरी सुरक्षा, भरोसेमंद, एक जैसा होने, और उसे अपडेट करने की जानकारी मिलती है. StrongBox API की अनुमति के अलावा स्टोरेज में बदलाव नहीं किया जाना चाहिए और न ही इसे पढ़ा जाना चाहिए और न ही इसमें बदलाव किया जाना चाहिए.
इस बात की पुष्टि करने के लिए कि [C-1-3] से [C-1-9] तक का पालन किया गया है या नहीं, डिवाइस पर ये सुविधाएं लागू होती हैं:
- [C-1-10] इसमें ऐसा हार्डवेयर शामिल करना ज़रूरी है जो सिक्योर आईसी प्रोटेक्शन प्रोफ़ाइल BSI-CC-PP-0084-2014 से सर्टिफ़ाइड है. इसके अलावा, इसका आकलन राष्ट्रीय स्तर की मान्यता पा चुकी टेस्टिंग लैबोरेट्री से किया गया है. इसमें जोखिम की ज़्यादा संभावना का आकलन करने के लिए, स्मार्टकार्ड पर हमले की संभावना का सामान्य मानदंड का आकलन किया गया है.
- [C-1-11] फ़र्मवेयर को शामिल करना ज़रूरी है. इसका आकलन, राष्ट्रीय स्तर पर मान्यता पा चुकी टेस्टिंग लैबोरेट्री से किया जाता है. इसमें अटैक पोटेंशियल के सामान्य मानदंड के ऐप्लिकेशन टू स्मार्टकार्ड्स के मुताबिक जोखिम की आशंका का आकलन शामिल है.
- [C-SR-2] हमारा सुझाव है कि ऐसे हार्डवेयर को शामिल करने का सुझाव दिया जाता है जिसे AVA_VAN.5 की मदद से, सुरक्षा टारगेट, इवैलुएशन अश्योरेंस लेवल (ईएएल) 5 का इस्तेमाल करके आकलन किया जाता है. आने वाले समय में, EAL 5 सर्टिफ़िकेशन ज़रूरी हो जाएगा.
- [C-SR-3] इनसाइडर अटैक रेज़िस्टेंस (आईएआर) का ऐक्सेस देने के लिए इस बात की बहुत ज़्यादा सलाह दी जाती है. इसका मतलब है कि फ़र्मवेयर साइनिंग कुंजियों का ऐक्सेस रखने वाला इनसाइडर, ऐसा फ़र्मवेयर नहीं बना सकता जिसकी वजह से StrongBox, सीक्रेट काम की शर्तों को बायपास कर सके या उपयोगकर्ता के संवेदनशील डेटा का ऐक्सेस चालू कर सके. आईएआर को लागू करने का सुझाव है कि फ़र्मवेयर अपडेट की अनुमति सिर्फ़ तब दें, जब प्राइमरी यूज़र पासवर्ड IAuthSecret HAL के ज़रिए दिया गया हो.

9.11.3. पहचान क्रेडेंशियल

android.security.identity.* पैकेज में मौजूद सभी एपीआई लागू करके, पहचान क्रेडेंशियल सिस्टम को तय किया जाता है और हासिल किया जाता है. इन एपीआई की मदद से ऐप्लिकेशन डेवलपर, उपयोगकर्ता की पहचान से जुड़े दस्तावेज़ों को सेव और वापस पा सकते हैं. डिवाइस पर यह सुविधा लागू करना:

[C-SR-1] का सुझाव दिया जाता है, ताकि पहचान क्रेडेंशियल सिस्टम को लागू किया जा सके.

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

[C-1-1] Identity क्रेडेंशियलStore#getInstance() वाले तरीके के लिए 'शून्य' मौजूद नहीं होना चाहिए.
[C-1-2] भरोसेमंद ऐप्लिकेशन के साथ कोड का इस्तेमाल करके, पहचान क्रेडेंशियल सिस्टम (जैसे कि android.security.identity.* एपीआई) को लागू करना ज़रूरी है. ऐसा उस इलाके में किया जाना चाहिए जिसे कर्नेल और इसके बाद के कोड पर चल रहे कोड से सुरक्षित तरीके से अलग रखा गया हो. सिक्योर आइसोलेशन से उन सभी संभावित मैकेनिज़्म को ब्लॉक कर देना चाहिए जिनकी मदद से कर्नेल या यूज़रस्पेस कोड, डीएमए के साथ-साथ आइसोलेटेड एनवायरमेंट की अंदरूनी स्थिति को ऐक्सेस कर सकते हैं.
[C-1-3] आइडेंटिटी क्रेडेंशियल सिस्टम (जैसे कि android.security.identity.* एपीआई) को लागू करने के लिए, ज़रूरी क्रिप्टोग्राफ़िक ऑपरेशन को पूरी तरह से भरोसेमंद ऐप्लिकेशन में ही किया जाना चाहिए. साथ ही, निजी पासकोड के मटीरियल को एक ही एनवायरमेंट में रखना चाहिए, जब तक कि हाई-लेवल एपीआई (जैसे कि createEphemeralKeyPair() तरीके के लिए खास तौर पर ज़रूरी न हो).
[C-1-4] भरोसेमंद ऐप्लिकेशन को कुछ इस तरह लागू किया जाना चाहिए कि उसकी सुरक्षा प्रॉपर्टी पर कोई असर न पड़े (उदाहरण के लिए, क्रेडेंशियल डेटा तब तक रिलीज़ नहीं होता है, जब तक ऐक्सेस कंट्रोल से जुड़ी शर्तें पूरी नहीं हो जाती हैं, MAC को आर्बिट्रेरी डेटा के लिए नहीं बनाया जा सकता) भले ही, Android में बुरा व्यवहार हो या उससे छेड़छाड़ की गई हो.

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

9.12. डेटा हटाना

लागू किए गए सभी डिवाइस:

[C-0-1] उपयोगकर्ताओं को "फ़ैक्ट्री डेटा रीसेट" करने का तरीका देना ज़रूरी है.
[C-0-2] "फ़ैक्ट्री डेटा रीसेट" करते समय उपयोगकर्ता डेटा के फ़ाइल सिस्टम में मौजूद सारा डेटा मिटाना ज़रूरी है.
[C-0-3] डेटा को इस तरह मिटाना ज़रूरी है कि "फ़ैक्ट्री डेटा रीसेट" करते समय, एनआईएसटी SP800-88 जैसे इंडस्ट्री स्टैंडर्ड को पूरा किया जा सके.
[C-0-4] ऊपर दी गई "फ़ैक्ट्री डेटा रीसेट" प्रोसेस को तब ट्रिगर करना ज़रूरी है, जब DevicePolicyManager.wipeData() मुख्य उपयोगकर्ता के डिवाइस नीति नियंत्रक ऐप्लिकेशन से एपीआई को कॉल किया जाता है.
इसमें तेज़ी से डेटा वाइप करने का विकल्प दिया जा सकता है, जो सिर्फ़ लॉजिकल डेटा को हमेशा के लिए मिटाने की सुविधा देता है.

9.13. सुरक्षित बूट मोड

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

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

[C-SR-1] सुरक्षित बूट मोड को लागू करने का सुझाव दिया जाता है.

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

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

9.14. ऑटोमोटिव व्हीकल सिस्टम आइसोलेशन

Android Automotive डिवाइस, वाहन के ज़रूरी सबसिस्टम के साथ डेटा शेयर करते हैं. ऐसा करने के लिए, वाहन के एचएएल का इस्तेमाल किया जाता है. ऐसा सीएएन बस जैसे वाहनों के नेटवर्क से मैसेज भेजने और पाने के लिए किया जाता है.

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

9.15. सदस्यता प्लान

"सदस्यता प्लान" का मतलब है, बिलिंग के लिए बनाए गए प्लान की वह जानकारी जो मोबाइल और इंटरनेट सेवा देने वाली कंपनी ने SubscriptionManager.setSubscriptionPlans() के ज़रिए दी है.

लागू किए गए सभी डिवाइस:

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

9.16. ऐप्लिकेशन के डेटा का माइग्रेशन

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

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

9.17. Android वर्चुअलाइज़ेशन फ़्रेमवर्क

अगर डिवाइस, Android वर्चुअलाइज़ेशन फ़्रेमवर्क एपीआई (android.system.virtualmachine.*) के साथ काम करता है, तो Android होस्ट:

[C-1-1] android.system.virtualmachine.* पैकेज में बताए गए सभी एपीआई के साथ काम करना ज़रूरी है.
[C-1-2] Protected Virtual Machines को मैनेज करने के लिए, Android SELinux और अनुमति के मॉडल में बदलाव नहीं करना होगा.
[C-1-3] अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट (एओएसपी) में दिए गए सिस्टम/सेवा नीति में मौजूद नियमों में बदलाव नहीं करना, उन्हें छोड़ना या बदलना नहीं चाहिए और इस नीति को कभी भी लागू न होने वाले सभी नियमों के साथ कंपाइल करना ज़रूरी है.
[C-1-4] सुरक्षित वर्चुअल मशीन बनाने और चलाने के लिए, गैर-भरोसेमंद कोड (जैसे कि 3p ऐप्लिकेशन) को अनुमति नहीं देनी चाहिए. ध्यान दें: यह विकल्प, आने वाले Android रिलीज़ में बदल सकता है.
[C-1-5] सुरक्षित वर्चुअल मशीन को ऐसे कोड चलाने की अनुमति नहीं देनी चाहिए जो फ़ैक्ट्री इमेज या उनके अपडेट का हिस्सा न हो. ऐसी सभी चीज़ें जो Android वेरिफ़ाइड बूट के तहत नहीं आती हैं (जैसे कि इंटरनेट से डाउनलोड की गई फ़ाइलें या अलग से लोड की गई फ़ाइलें), उन्हें Protected Virtual Machine में चलाने की अनुमति नहीं है.

अगर डिवाइस, Android वर्चुअलाइज़ेशन फ़्रेमवर्क एपीआई (android.system.virtualmachine.*) के साथ काम करता है, तो कोई भी Protected Virtual Machine इंस्टेंस:

[C-2-1] यह ज़रूरी है कि यह सुरक्षित वर्चुअल मशीन में वर्चुअलाइज़ेशन APEX में उपलब्ध सभी ऑपरेटिंग सिस्टम चला सके.
[C-2-2] किसी सुरक्षित वर्चुअल मशीन को ऐसा ऑपरेटिंग सिस्टम चलाने की अनुमति नहीं देनी चाहिए जिस पर डिवाइस लागू करने वाले या ओएस वेंडर ने हस्ताक्षर न किया हो.
[C-2-3] Protected Virtual Machine को डेटा के तौर पर डेटा इस्तेमाल करने की अनुमति नहीं देनी चाहिए (उदाहरण के लिए, SELinux कभी भी execmem की अनुमति नहीं देता).
[C-2-4] अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट (एओएसपी) में दिए गए सिस्टम/sepolicy/माइक्रोड्रॉइड में मौजूद नियमों में बदलाव नहीं करना चाहिए, उन्हें छोड़ना या बदलना नहीं चाहिए.
[C-2-5] आपको सुरक्षित वर्चुअल मशीन की सुरक्षा के लिए बेहतर मैकेनिज़्म लागू करना होगा (जैसे, pVM के लिए SELinux) यहां तक कि नॉन-माइक्रोड्रॉइड ऑपरेटिंग सिस्टम के लिए भी.
[C-2-6] यह पक्का करना ज़रूरी है कि अगर pVM फ़र्मवेयर शुरुआती इमेज की पुष्टि नहीं कर पाता है, तो वह बूट नहीं होगा.
[C-2-7] यह पक्का करना ज़रूरी है कि example.img की इंटिग्रिटी के साथ छेड़छाड़ होने पर, pVM फ़र्मवेयर को बूट होने से मना कर दिया जाए.

अगर डिवाइस, Android वर्चुअलाइज़ेशन फ़्रेमवर्क एपीआई (android.system.virtualmachine.*) के साथ काम करता है, तो हाइपरवाइज़र:

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

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

[C-4-1] ऐसी पीवीएम को फ़ंक्शन नहीं देना चाहिए जो Android सिक्योरिटी मॉडल को बायपास करने की अनुमति देता हो.

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

[C-5-1] एआरटी रनटाइम अपडेट के आइसोलेटेड कंपाइलेशन के साथ काम करना ज़रूरी है.

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

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

10. सॉफ़्टवेयर के साथ काम करने से जुड़ी जांच

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

10.1. कंपैटबिलिटी टेस्ट सुइट

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

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

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

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

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

10.2. सीटीएस वेरिफ़ायर

CTS Verifier, कंपैटबिलिटी टेस्ट सुइट के साथ शामिल है. इसे कोई व्यक्ति ऑपरेटर, ऐसे फ़ंक्शन की जांच करने के लिए चलाए जा सकता है जिसकी जांच ऑटोमेटेड सिस्टम (कार्रवाइयों को अपने-आप पूरा करने वाला सिस्टम) से नहीं की जा सकती. जैसे, कैमरे और सेंसर का सही तरीके से काम करना.

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

[C-0-1] सीटीएस की पुष्टि करने वाले टूल में, लागू होने वाले सभी मामलों का सही तरीके से पालन करना ज़रूरी है.

CTS Verifier में कई तरह के हार्डवेयर की जांच की जा सकती है. इनमें कुछ ऐसे हार्डवेयर भी शामिल हैं जो ज़रूरी नहीं हैं.

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

[C-0-2] उनके पास मौजूद हार्डवेयर की सभी जांचों को पास करना ज़रूरी है; उदाहरण के लिए, अगर किसी डिवाइस में एक्सीलरोमीटर है, तो उसे सीटीएस वैरिफ़ायर में एक्सलरोमीटर टेस्ट केस को सही तरीके से एक्ज़ीक्यूट करना होगा.

'कंपैटिबिलिटी डेफ़िनिशन' दस्तावेज़ के मुताबिक, वैकल्पिक के तौर पर बताई गई सुविधाओं के टेस्ट केस हटाए या हटाए जा सकते हैं.

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

11. अपडेट किया जा सकने वाला सॉफ़्टवेयर

[C-0-1] डिवाइस पर लागू किए गए सभी सॉफ़्टवेयर को लागू करने का तरीका शामिल होना चाहिए. सिस्टम को "लाइव" अपग्रेड करने की ज़रूरत नहीं है—यानी, डिवाइस को रीस्टार्ट करने की ज़रूरत हो सकती है. किसी भी तरीके का इस्तेमाल किया जा सकता है. हालांकि, इसके लिए ज़रूरी है कि यह डिवाइस पर पहले से इंस्टॉल किए गए सॉफ़्टवेयर को पूरी तरह से बदल सके. उदाहरण के लिए, इनमें से कोई भी तरीका इस ज़रूरी को पूरा करेगा:
- डिवाइस को फिर से चालू करके, ऑफ़लाइन अपडेट के साथ "ओवर-द-एयर (OTA)" डाउनलोड किया जा सकता है.
- किसी होस्ट पीसी से, यूएसबी पर "Tethered" अपडेट होता है.
- डिवाइस को फिर से चालू करके, "ऑफ़लाइन" अपडेट किया जाता है. साथ ही, हटाए जा सकने वाले स्टोरेज में सेव की गई फ़ाइल को भी अपडेट किया जाता है.
[C-0-2] अपडेट करने के लिए इस्तेमाल किए गए तरीके को, उपयोगकर्ता का डेटा वाइप किए बिना अपडेट काम करना चाहिए. इसका मतलब है कि अपडेट करने के तरीके में ऐप्लिकेशन के निजी डेटा और ऐप्लिकेशन के शेयर किए गए डेटा को सुरक्षित रखना ज़रूरी है. ध्यान दें कि अपस्ट्रीम Android सॉफ़्टवेयर में अपडेट करने का ऐसा तरीका शामिल है जो इस ज़रूरी शर्त को पूरा करता है.
[C-0-3] पूरे अपडेट पर हस्ताक्षर करना ज़रूरी है और डिवाइस पर अपडेट करने के तरीके से डिवाइस पर सेव किए गए सार्वजनिक पासकोड से अपडेट और हस्ताक्षर की पुष्टि करनी होगी.
[C-SR-1] SHA-256 के साथ अपडेट को हैश करने और ECDSA NIST P-256 का इस्तेमाल करके सार्वजनिक कुंजी से हैश की पुष्टि करने के लिए, हस्ताक्षर करने के तरीके का बहुत ज़्यादा सुझाव दिया जाता है.

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

[C-1-1] डिवाइस को फिर से चालू करके, ऑफ़लाइन अपडेट के साथ ओटीए डाउनलोड करने की सुविधा दी जानी चाहिए.

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

इसके अलावा, डिवाइस पर A/B सिस्टम अपडेट लागू होने चाहिए. एओएसपी इस सुविधा को बूट कंट्रोल एचएएल का इस्तेमाल करके लागू करता है.

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

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

Android में ऐसी सुविधाएं शामिल हैं जो डिवाइस के मालिक वाले ऐप्लिकेशन (अगर मौजूद है) को यह कंट्रोल करने की अनुमति देती हैं कि सिस्टम अपडेट इंस्टॉल किए जाएं या नहीं. अगर डिवाइस का सिस्टम अपडेट सबसिस्टम android.software.device_admin की रिपोर्ट करता है, तो वे:

[C-3-1] SystemUpdatePolicy क्लास में बताए गए व्यवहार को लागू करना ज़रूरी है.

12. दस्तावेज़ में बदलावों का लॉग

इस रिलीज़ में 'कंपैटबिलिटी डेफ़िनिशन' में हुए बदलावों के बारे में खास जानकारी नीचे दी गई है:

4 अक्टूबर, 2023

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

2.2.5. सुरक्षा मॉडल:
बदलाव देखें
- [9.8/H-1-14] सेक्शन 9.8.2 में बताए गए तरीके के मुताबिक, माइक्रोफ़ोन इंंडिकेटर दिखाना ज़रूरी है ~~[9.8/C-3-1]~~, जब वॉइस पर कोई सफल हॉटवर्ड नतीजा भेजा जाता है
2.2.7.1 मीडिया:
बदलाव देखें
- [5.1/H-1-7] लोड होने पर, सभी हार्डवेयर वीडियो एन्कोडर के लिए, 1080 पिक्सल या इससे छोटे वीडियो एन्कोडिंग सेशन के लिए, कोडेक शुरू होने का इंतज़ार 40 मि॰से॰ या इससे कम होना चाहिए. यहां लोड को, हार्डवेयर वीडियो कोडेक और 1080 पिक्सल ऑडियो-वीडियो रिकॉर्डिंग शुरू करने के बीच में, एक साथ 1080 पिक्सल से 720 पिक्सल वाले वीडियो के लिए ट्रांसकोडिंग सेशन के तौर पर दिखाया जाता है. Dolby विज़न कोडेक के लिए, कोडेक को शुरू करने में लगने वाला समय 50 मि॰से॰ या इससे कम होना चाहिए.
- [5.1/H-1-12] लोड होने पर, सभी हार्डवेयर वीडियो डिकोडर के लिए, 1080 पिक्सल या इससे छोटे वीडियो डिकोड करने वाले सेशन के लिए, कोडेक शुरू होने का इंतज़ार 40 मि॰से॰ या इससे कम होना चाहिए. यहां लोड को, हार्डवेयर वीडियो कोडेक और 1080 पिक्सल के ऑडियो-वीडियो प्लेबैक शुरू करने के तरीके का इस्तेमाल करके, सिर्फ़ 1080 पिक्सल से 720 पिक्सल वाले वीडियो ट्रांसकोडिंग सेशन के तौर पर दिखाया गया है. Dolby विज़न कोडेक के लिए, कोडेक के शुरू होने में लगने वाला समय 50 मि॰से॰ या इससे कम होना चाहिए.
- [5.1/H-1-13] लोड होने पर, सभी ऑडियो डिकोडर के लिए, 128 केबीपीएस या इससे कम बिटरेट वाले ऑडियो डिकोड करने वाले सेशन के लिए, कोडेक शुरू होने में 30 मि॰से॰ या इससे कम का समय होना चाहिए. यहां लोड को हार्डवेयर वीडियो कोडेक और 1080 पिक्सल ऑडियो-वीडियो प्लेबैक इनिशलाइज़ेशन का इस्तेमाल करके, एक साथ 1080 पिक्सल से 720 पिक्सल वाले वीडियो की ट्रांसकोडिंग करने के तौर पर तय किया जाता है.

7.4. डेटा कनेक्टिविटी

7.4.1.1. नंबर ब्लॉक करने की सुविधा:

बदलाव देखें

अगर लागू किए गए डिवाइस पर android.hardware.telephony.calling सुविधा की रिपोर्ट मिलती है, तो वे:
7.4.1.2. Telecom API:

बदलाव देखें

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

9.11. कुंजियां और क्रेडेंशियल

9.11.2. StrongBox:

बदलाव देखें

को IAuthSecret HAL के ज़रिए उपलब्ध कराया जाता है.

हटाई गई Android 14 में IAR ज़रूरी हो जाएगा.

26 जून, 2023

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

2.2.1. हार्डवेयर
- हटाई गई ज़रूरी शर्तें 7.2.3/H-0-5, 7.2.3/H-0-6, 7.2.3/H-0-7
- अन्य अपडेट:
  
  बदलाव देखें
  
  मौजूदगी कैलिब्रेशन की ~~ज़रूरी शर्तें~~ में बताए गए, मेज़रमेंट सेटअप के तरीकों का पालन करने पर ज़ोर दिया जाता है.
2.5.1. हार्डवेयर
बदलाव देखें
अगर Automotive डिवाइस में 32-बिट लागू होता है:

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

छोटी/सामान्य स्क्रीन पर 280 डीपीआई या उससे कम

ज़्यादा बड़ी स्क्रीन पर ldpi या उससे कम

बड़ी स्क्रीन पर mdpi या कम

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

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

बड़ी स्क्रीन पर hdpi या उससे ज़्यादा

ज़्यादा बड़ी स्क्रीन के लिए mdpi या उससे ज़्यादा

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

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

बड़ी स्क्रीन पर xhdpi या उससे ज़्यादा

ज़्यादा बड़ी स्क्रीन पर tvdpi या उसके बाद का वर्शन

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

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

बड़ी स्क्रीन पर 400 डीपीआई या उससे ज़्यादा

ज़्यादा बड़ी स्क्रीन पर xhdpi या उससे ज़्यादा

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

3.2.3.5. कंडिशनल (शर्त के साथ) ऐप्लिकेशन इंटेंट

बदलाव देखें

अगर लागू किए गए डिवाइस android.hardware.telephony.calling ~~android.hardware.telephony~~ की रिपोर्ट करते हैं, तो:

7. हार्डवेयर के साथ काम करने की सुविधा

7.4. डेटा कनेक्टिविटी

बदलाव देखें

मौजूदगी का कैलिब्रेशन ~~ज़रूरी शर्तें~~.

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

9.1 अनुमतियां
बदलाव देखें

डिवाइस पर यह सुविधा लागू करना:
- [C-0-5] ~~पहले से इंस्टॉल किए गए~~ ऐप्लिकेशन को रनटाइम की अनुमति तब तक नहीं देनी चाहिए, जब तक:
  - इन्हें डिवाइस की शिपिंग के समय इंस्टॉल किया जाता है और
  - ऐप्लिकेशन अनुमति का इस्तेमाल करने से पहले, उपयोगकर्ता की सहमति ले सकता है,
  या
  - रनटाइम की अनुमतियां, अनुमति देने की डिफ़ॉल्ट नीति या प्लैटफ़ॉर्म भूमिका को होल्ड करने के तहत दी जाती हैं.यह इंटेंट पैटर्न से जुड़ा होता है, जिसके लिए पहले से इंस्टॉल किए गए ऐप्लिकेशन को डिफ़ॉल्ट हैंडलर के तौर पर सेट किया जाता है.
9.11. कुंजी और क्रेडेंशियल
- ज़रूरी शर्तें [C-13-10] और 9.11.4 हटाई गईं.

20 मार्च, 2023

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

2.2.3. सॉफ़्टवेयर
बदलाव देखें
अगर हैंडहेल्ड डिवाइस पर लागू सेटिंग ऐप्लिकेशन में, गतिविधि एम्बेड करने की सुविधा का इस्तेमाल करके स्प्लिट फ़ंक्शन को लागू किया जाता है, तो ये काम किए जा सकते हैं:
- [~~C-17-1~~3.2.3.1/ H-1-1] इनमें ऐसी गतिविधि ज़रूर होनी चाहिए जो बांटने की सुविधा चालू होने पर, Settings#ACTION_SETTINGS_VERSION_DEEP_LINK_ACTIVITY के इंटेंट के हिसाब से काम करती हो. गतिविधि को android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK से सुरक्षित करना ज़रूरी है और इसके लिए Settings##additional_SETTINGS_VERSIONDED_DEEP_LINK_INTENT_uri से पार्स किए गए इंटेंट की गतिविधि शुरू करनी होगी.
नई ज़रूरी शर्तें खत्म करना
2.3.2. मल्टीमीडिया
बदलाव देखें

अगर VP9 हार्डवेयर डिकोडर की मदद से, टेलीविज़न डिवाइस को लागू करने पर, VP9 डिकोड करने और यूएचडी को डिकोड करने वाली प्रोफ़ाइल काम करती है, तो ये काम किए जा सकते हैं:
- [5.3.7/T-~~2-1~~SR1] प्रोफ़ाइल 2 (10 बिट कलर डेप्थ) के साथ, 60 फ़्रेम प्रति सेकंड की दर से यूएचडी डिकोडिंग प्रोफ़ाइल बनाने के लिए, इस बात का खास तौर पर सुझाव दिया जाता है.
2.5.1. हार्डवेयर
बदलाव देखें

वाहन संबंधित डिवाइस पर विज्ञापन लागू करना:
- [7.3/A-~~0-1~~SR1] जीपीएस/जीएनएसएस को अतिरिक्त सेंसर के साथ जोड़ने से, जगह की जानकारी का पता लग सकता है. अगर जगह की जानकारी को बंद माना जाता है, तो इससे जुड़े सेंसर के टाइप और/या इस्तेमाल किए गए वाहन के प्रॉपर्टी आईडी को लागू करने और उनकी शिकायत करने का सुझाव दिया जाता है.
- [7.3/A-~~0-2~~0-4] LocationManager#requestLocationUpdated() के ज़रिए अनुरोध किया गया Location मैप से मेल नहीं खाना चाहिए.

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

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

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

[C-2-1] खाता चुनने के लिए यूज़र इंटरफ़ेस (यूआई) लॉन्च करने के लिए, ContactsContract.Settings.ACTION_SET_DEFAULT_ACCOUNT इंटेंट को हैंडल करना ज़रूरी है. साथ ही, कोई खाता चुनने पर, इस सेटिंग को Contacts की सेवा देने वाली कंपनी में सेव करना ज़रूरी है.

[C-2-2] ContactsContracts.Contacts.CONTENT_TYPE और ContactsContract.RawContacts.CONTENT_TYPE के लिए Intent.ACTION_INSERT and Intent.ACTION_INSERT_OR_EDIT को हैंडल करते समय, खाते की डिफ़ॉल्ट सेटिंग का पालन करना ज़रूरी है. इसके लिए, शुरुआत में खाता चुनें.

नई ज़रूरी शर्तें खत्म करना
3.2.3.5. कंडिशनल (शर्त के साथ) ऐप्लिकेशन इंटेंट
बदलाव देखें

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

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

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

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

6.1. डेवलपर टूल
बदलाव देखें
बंदर

[C-0-8] आपको Monkey फ़्रेमवर्क को शामिल करना होगा और ऐप्लिकेशन के लिए इस्तेमाल करने के लिए उपलब्ध कराना होगा.

7. हार्डवेयर के साथ काम करने की सुविधा

7.3.13. आईईईई 802.1.15.4 (यूडब्ल्यूबी)
बदलाव देखें

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

[C-1-1] इससे जुड़े Android API को android.uwb में लागू करना ज़रूरी है.

[C-1-2] हार्डवेयर फ़ीचर फ़्लैग android.hardware.uwb की शिकायत करना ज़रूरी है.

[C-1-3] Android वर्शन को लागू करने के दौरान, काम की सभी यूडब्ल्यूबी प्रोफ़ाइलों का इस्तेमाल किया जाना ज़रूरी है.

[C-1-4] लोगों को यह सुविधा देनी होगी कि वे यूडब्ल्यूबी रेडियो को चालू/बंद करने की सुविधा को टॉगल कर सकें.

[C-1-5] यह पक्का करना ज़रूरी है कि यूडब्ल्यूबी रेडियो का इस्तेमाल करने वाले ऐप्लिकेशन, UWB_RANGING अनुमति को (NEARBY_devices अनुमति ग्रुप के तहत) में होल्ड करें.

[C-1-6] इस बात पर काफ़ी ध्यान दिया जाता है कि FIRA, CCC, और सीएसए जैसे मानक संगठनों की तय की गई शर्तों के पालन और सर्टिफ़िकेट की जांच को पास किया जाए.

नई ज़रूरी शर्तें खत्म करना
7.4.1. टेलीफ़ोनी
बदलाव देखें

अगर किसी डिवाइस पर ~~जीएसएम या सीडीएमए टेलीफ़ोनी शामिल है~~, तो android.hardware.telephony की सुविधा को रिपोर्ट करें, तो:
- [C-6-1] टेक्स्ट मैसेज की सुविधा देने के लिए, SmsManager#sendTextMessage और SmsManager#sendMultipartTextMessage CarrierMessagingService को कॉल करना ज़रूरी है. SmsManager#sendMultimediaMessage और SmsManager#downloadMultimediaMessage मल्टीमीडिया मैसेज की सुविधा देने के लिए, CarrierMessagingService को कॉल करना ज़रूरी है.
- [C-6-2] android.provider.Telephony.Sms#getDefaultSmsPackage की ओर से तय किए गए ऐप्लिकेशन को एसएमएस और मल्टीमीडिया मैसेज (एमएमएस) भेजते और पाते समय SmsManager एपीआई का इस्तेमाल करना होगा. पैकेज/ऐप्लिकेशन/मैसेजिंग में एओएसपी रेफ़रंस लागू करने की सुविधा, इस ज़रूरी शर्त को पूरा करती है.
- [C-6-3] Intent#ACTION_DIAL का जवाब देने वाले ऐप्लिकेशन के लिए, *#*#CODE#*#* फ़ॉर्मैट में आर्बिट्रेरी डायलर कोड डालने की सुविधा होनी ज़रूरी है. साथ ही, उससे जुड़े TelephonyManager#ACTION_SECRET_CODE का ब्रॉडकास्ट भी ट्रिगर होना चाहिए.
- [C-6-4] Intent#ACTION_DIAL का जवाब देने वाले ऐप्लिकेशन को उपयोगकर्ताओं को विज़ुअल वॉइसमेल ट्रांसक्रिप्शन देने के लिए VoicemailContract.Voicemails#TRANSCRIPTION का इस्तेमाल करना होगा. इसके लिए ज़रूरी है कि ऐप्लिकेशन विज़ुअल वॉइसमेल ट्रांसक्रिप्शन की सुविधा देता हो.
- [C-6-5] उपयोगकर्ताओं को दिखने वाली सभी सुविधाओं में, एक ही सदस्यता के तौर पर ग्रुप यूयूआईडी वाली सभी SubscriptionInfo को दिखाना ज़रूरी है. ये सुविधाएं सिम कार्ड की जानकारी दिखाने और कंट्रोल करने में मददगार होती हैं. इस तरह की सुविधाओं के उदाहरणों में, Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS या EuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS से मेल खाने वाले सेटिंग इंटरफ़ेस शामिल हैं.
- [C-6-6] सिम कार्ड की सेटिंग को कॉन्फ़िगर या कंट्रोल करने की अनुमति देने वाली सुविधाओं में, सदस्यता की जानकारी को ऐसे ग्रुप यूयूआईडी और ऑपर्च्यूनिस्टिक बिट के साथ दिखाना या कंट्रोल नहीं करना चाहिए.
अगर लागू किए जाने वाले डिवाइस में ~~GSM या CDMA टेलीफ़ोनी शामिल है~~, तो android.hardware.telephony की सुविधा की शिकायत करें और सिस्टम का स्टेटस बार दें. इसके बाद:
- [C-6-7-1] उपयोगकर्ता को किसी दिए गए ग्रुप यूयूआईडी के लिए, कोई ऐसी ऐक्टिव सदस्यता चुननी होगी जो उसकी सेवा की स्थिति की जानकारी देने वाली किसी भी कीमत पर हो. इस तरह की सुविधाओं के उदाहरणों में, स्टेटस बार पर मोबाइल सिग्नल आइकॉन या क्विक सेटिंग टाइल शामिल हैं.
- [C-SR-1] हमारा सुझाव है कि प्रतिनिधि के तौर पर ली गई सदस्यता को ऐक्टिव डेटा वाली सदस्यता के तौर पर तब तक चुना जाए, जब तक डिवाइस वॉइस कॉल पर न हो. इस दौरान, इस बात पर बहुत ज़्यादा ध्यान दिया जाता है कि प्रतिनिधि वाली सदस्यता, ऐक्टिव वॉइस सदस्यता है.
अगर किसी डिवाइस पर ~~जीएसएम या सीडीएमए टेलीफ़ोनी शामिल है~~, तो android.hardware.telephony की सुविधा को रिपोर्ट करें, तो:
- [C-6-87] यह ज़रूरी है कि वह हर ईटीएसआई टीएस 102 221 के लिए, हर यूआईसीसी के लिए ज़्यादा से ज़्यादा लॉजिकल चैनलों (कुल 20) को खोल सके और एक साथ इस्तेमाल कर सके.
- [C-6-108] मोबाइल और इंटरनेट सेवा देने वाली कंपनी के चालू ऐप्लिकेशन (जैसा कि TelephonyManager#getCarrierServicePackageName ने तय किया है) पर इनमें से कोई भी व्यवहार अपने-आप या उपयोगकर्ता की पुष्टि के बिना लागू नहीं करना चाहिए:
  - नेटवर्क ऐक्सेस रद्द करना या उसे सीमित करना
  - अनुमतियां वापस लें
  - एओएसपी में शामिल पावर मैनेजमेंट की मौजूदा सुविधाओं के अलावा, बैकग्राउंड या फ़ोरग्राउंड ऐप्लिकेशन को एक्ज़ीक्यूट करने पर पाबंदी लगाएं
  - ऐप्लिकेशन को बंद या अनइंस्टॉल करें
अगर डिवाइस पर लागू ~~जीएसएम या सीडीएमए टेलीफ़ोनी शामिल है~~android.hardware.telephony सुविधा की शिकायत की जाती है और किसी ग्रुप यूयूआईडी को शेयर करने वाली सभी चालू, नॉन-ऑपर्च्यूनिटी सदस्यताओं को बंद कर दिया जाता है, तो डिवाइस से हटा दिया जाता है या अवसर के हिसाब से मार्क किया जाता है. इसके बाद, डिवाइस:
- [C-78-1] एक ही ग्रुप में बची हुई सभी ऑपर्च्यूनिटी सदस्यताओं को अपने-आप बंद करना ज़रूरी है.
अगर लागू किए जाने वाले डिवाइसों में GSM टेलीफ़ोनी शामिल है, लेकिन CDMA टेलीफ़ोनी नहीं, तो वे:
- [C-89-1] इस बारे में जानकारी नहीं देनी चाहिए PackageManager#FEATURE_TELEPHONY_CDMA.
- [C-89-2] किसी भी 3GPP2 नेटवर्क टाइप को पसंदीदा या अनुमति वाले नेटवर्क टाइप बिटमास्क में सेट करने पर, IllegalArgumentException देना ज़रूरी है.
- [C-89-3] TelephonyManager#getMeid से एक खाली स्ट्रिंग देनी होगी.
अगर डिवाइस लागू करने के तरीके में एक से ज़्यादा पोर्ट और प्रोफ़ाइल वाले eUICC काम करते हैं, तो ये:
- [C-1110-1] android.hardware.telephony.euicc.mep सुविधा के बारे में बताने वाले फ़्लैग के बारे में बताना ज़रूरी है.
7.4.9. यूडब्ल्यूबी
बदलाव देखें

अगर डिवाइस पर लागू करने की सुविधा, android.content.pm.PackageManager क्लास के ज़रिए सुविधाandroid.hardware.uwb के बारे में रिपोर्ट करती है, अगर डिवाइस पर लागू करने की सुविधा में 802.1.15.4 के लिए सहायता शामिल है और इस सुविधा को तीसरे पक्ष के ऐप्लिकेशन के लिए सार्वजनिक किया जाता है, तो:
- [C-1-1] इससे जुड़े Android API को android.uwb में लागू करना ज़रूरी है.
- [C-1-2] हार्डवेयर फ़ीचर फ़्लैग android.hardware.uwb की शिकायत करना ज़रूरी है.
- [C-1-3] Android वर्शन को लागू करने के दौरान, काम की सभी यूडब्ल्यूबी प्रोफ़ाइलों का इस्तेमाल किया जाना ज़रूरी है.
- [C-1-4] लोगों को यह सुविधा देनी होगी कि वे यूडब्ल्यूबी रेडियो को चालू/बंद करने की सुविधा को टॉगल कर सकें.
- [C-1-5] यह पक्का करना ज़रूरी है कि यूडब्ल्यूबी रेडियो का इस्तेमाल करने वाले ऐप्लिकेशन, UWB_RANGING अनुमति को (NEARBY_devices अनुमति ग्रुप के तहत) में होल्ड करें.
- [C-SR-1] का सुझाव दिया जाता है कि स्टैंडर्ड संगठनों के तय किए गए नियमों के पालन और सर्टिफ़िकेशन टेस्ट को पास करें. इनमें FIRA, CCC, और सीएसए शामिल हैं.
- [C-1-16] यह पक्का करना ज़रूरी है कि दूरी की माप, 95% के दायरे में +/-15 सें॰मी॰ के बीच हो. यह दूरी, नॉन-रिफ़्लेक्टिव चैंबर में 1 मीटर की दूरी पर होती है.
- [C-1-27] यह पक्का करना ज़रूरी है कि रेफ़रंस डिवाइस से 1 मीटर की दूरी के माप का मीडियन [0.75 मीटर, 1.25 मीटर] के अंदर हो. यहां ज़मीन की सच्चाई का पता, डीयूटी के ऊपरी किनारे से ऊपर और झुकाकर रखा जाता है.
- [C-SR-2] का बहुत ज़्यादा सुझाव दिया जाता है, ताकि मौजूदगी कैलिब्रेशन की ज़रूरी शर्तों में बताए गए मेज़रमेंट सेटअप के तरीकों का पालन किया जा सके.
हमारा सुझाव है कि मौजूदगी को कैलिब्रेट करने की ज़रूरी शर्तों में बताए गए, मेज़रमेंट सेटअप के चरणों का पालन करें.

नई ज़रूरी शर्तें खत्म करना
7.8.2.2. डिजिटल ऑडियो पोर्ट

बदलाव देखें

यह सुविधा, यूएसबी-सी कनेक्टर का इस्तेमाल करके हेडसेट और अन्य ऑडियो ऐक्सेसरी के साथ काम कर सकती है. साथ ही, इसे Android यूएसबी हेडसेट की खास बातों में बताए गए Android नेटवर्क में लागू करने (यूएसबी ऑडियो क्लास) की सुविधा भी देती है.

19 अक्टूबर, 2022

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

2.2.3 सॉफ़्टवेयर
बदलाव देखें

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

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

3.2.3.5. कंडिशनल (शर्त के साथ) ऐप्लिकेशन इंटेंट
बदलाव देखें

अगर डिवाइस पर लागू की गई सेटिंग ऐप्लिकेशन में गतिविधि एम्बेड करने की सुविधा का इस्तेमाल करके, स्प्लिट फ़ंक्शन लागू किया गया है, तो ये:
- [C-17-1] ज़रूरी है कि आपने कोई ऐसी गतिविधि की हो जो बांटने की सुविधा चालू होने पर, Settings#ACTION_SETTINGS_googleblog_DEEP_LINK_ACTIVITY इंटेंट को मैनेज करती हो. गतिविधि को android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK से सुरक्षित रखना ज़रूरी है और इसके लिए Settings##additional_SETTINGS_googleblogDED_DEEP_LINK_INTENT_uri से पार्स किए गए इंटेंट की गतिविधि शुरू करनी होगी.
अगर लागू करने के लिए डिवाइस पर VoiceInteractionService काम करता है और उस समय एक से ज़्यादा ऐप्लिकेशन इस एपीआई का इस्तेमाल करते हैं, तो वे:
- [C-18-1] बोलकर फ़ोन को निर्देश देने और असिस्ट क्लिक/इंप्रेशन देने के लिए, डिफ़ॉल्ट ऐप्लिकेशन सेटिंग मेन्यू दिखाने के android.settings.ACTION_VOICE_INPUT_SETTINGS इंटेंट का पालन करना ज़रूरी है.
3.4.1 वेबव्यू के साथ काम करने की सुविधा
बदलाव देखें
- [C-1-4]दिए गए कॉन्टेंट या रिमोट यूआरएल के कॉन्टेंट को ऐसे प्रोसेस में रेंडर करना ज़रूरी है जो वेबव्यू को इंस्टैंशिएट करने वाले ऐप्लिकेशन से अलग हो. खास तौर पर, अलग रेंडरर प्रोसेस में कम अधिकार होना चाहिए, एक अलग यूज़र आईडी के रूप में चलाया जाना, ऐप्लिकेशन की डेटा डायरेक्ट्री का ऐक्सेस नहीं होना, नेटवर्क का सीधा ऐक्सेस नहीं होना चाहिए, और बाइंडर पर सिर्फ़ ज़रूरी सिस्टम सेवाओं का ऐक्सेस होना चाहिए. वेबव्यू का एओएसपी इस ज़रूरी शर्त को पूरा करता है.

7. हार्डवेयर के साथ काम करने की सुविधा

7.4.2 आईईईई 802.11 (वाई-फ़ाई)
बदलाव देखें

अगर आईईईई 802.11 स्टैंडर्ड में बताए गए तरीके के मुताबिक, डिवाइस पर 'वाई-फ़ाई पावर सेव मोड' का इस्तेमाल किया जा सकता है, तो:
- ~~[C-3-1] ज़रूरी है~~ जब भी कोई ऐप्लिकेशन WIFI_MODE_FULL_HIGH_PERF लॉक या WIFI_MODE_FULL_LOW_LATENCY लॉक पाएं, तो WifiManager.createWifiLock() और WifiManager.WifiLock.acquire() के ज़रिए वाई-फ़ाई पावर सेव मोड बंद करना चाहिए
7.4.3 ब्लूटूथ
बदलाव देखें

अगर डिवाइस लागू करने के तरीके में ब्लूटूथ स्मार्ट (BLE) के लिए सहायता शामिल है, तो वे:
- [C-3-5] रिज़ॉल्व होने वाले प्राइवेट पते (आरपीए) का टाइम आउट 15 मिनट से ज़्यादा नहीं होना चाहिए. साथ ही, उपयोगकर्ता की निजता बनाए रखने के लिए, जब डिवाइस सक्रिय रूप से बीएलई का इस्तेमाल स्कैन या विज्ञापन करने के लिए कर रहा हो, तब टाइम आउट पर पते को रोटेट करना होगा. टाइमिंग अटैक से बचने के लिए, टाइम आउट इंटरवल को भी 5 से 15 मिनट के बीच किसी भी क्रम में रखा जाना चाहिए.
7.5.5 कैमरा ओरिएंटेशन
बदलाव देखें

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

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

9.11 कुंजियां और क्रेडेंशियल
बदलाव देखें

जब डिवाइस पर लागू होने वाला सुरक्षित लॉक स्क्रीन काम करती है, तो यह काम करता है:
- [C-1-6] IKeyMasterDevice 4.0, IKeyMasterDevice 4.1, IKeyMintDevice वर्शन 1 या IKeyMintडिवाइस वर्शन 2 पर काम करना चाहिए.
9.17 Android वर्चुअलाइज़ेशन फ़्रेमवर्क
बदलाव देखें

अगर डिवाइस, Android वर्चुअलाइज़ेशन फ़्रेमवर्क के एपीआई (android.system.virtualmachine.*) के साथ काम करता है, तो Android होस्ट:
- [C-1-3] अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट (एओएसपी) में उपलब्ध कराए गए सिस्टम/सेवा नीति में मौजूद नियमों में बदलाव नहीं करना चाहिए, उन्हें छोड़ना या बदलना नहीं चाहिए. साथ ही, इस नीति को सभी नियमों के साथ कंपाइल करना ज़रूरी है.
अगर डिवाइस, Android वर्चुअलाइज़ेशन फ़्रेमवर्क एपीआई (android.system.virtualmachine.*) के साथ काम करता है, तो कोई भी Protected Virtual Machine इंस्टेंस:
- [C-2-4] अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट (एओएसपी) में दिए गए सिस्टम/sepolicy/माइक्रोड्रॉइड में मौजूद नियमों में बदलाव करने, उन्हें मिटाने या बदलने की ज़रूरत नहीं है.
अगर डिवाइस, Android वर्चुअलाइज़ेशन फ़्रेमवर्क एपीआई के साथ काम करता है, तो क्रिप्टोग्राफ़िक कुंजी के मैनेजमेंट के लिए:
- [C-6-2] DICE को सही तरीके से इस्तेमाल करना ज़रूरी है. इसका मतलब है कि प्रॉडक्ट के लिए सही वैल्यू सबमिट करें. ~~हालांकि, ऐसा हो सकता है कि ज़्यादा जानकारी देने की ज़रूरत न पड़े.~~

15 अगस्त, 2022

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

2.2.1 हार्डवेयर: हार्डवेयर की ज़रूरी शर्तों में इस तरह के बदलाव किए गए हैं.
- इनपुट डिवाइस:
  बदलाव देखें
  
  हैंडहेल्ड डिवाइस लागू करना:
  [7.2.3/H-0-5] मौजूदा फ़ोकस वाली विंडो पर OnBackInvokedCallback.onBackStarted() को कॉल करना ज़रूरी है. ऐसा तब करें, जब 'वापस जाएं' जेस्चर चालू हो या 'वापस जाएं' बटन (KEYCODE_BACK) को 'डाउन ऐरो' पर सेट किया गया हो.
  
  [7.2.3/H-0-6] अगर आपने पीछे जाने का जेस्चर इस्तेमाल किया है या 'वापस जाएं' बटन हटा दिया है, तो OnBackInvokedCallback.onBackInvoked() पर कॉल करें.
  
  [7.2.3/H-0-7] अगर पिछले जेस्चर का इस्तेमाल नहीं किया जा रहा है या KEYCODE_BACK इवेंट रद्द कर दिया गया है, तो OnBackInvokedCallback.onBackCancelled() पर कॉल करें.
  
  नई ज़रूरी शर्तें खत्म करना
  अगर डिवाइस, PackageManager.FEATURE_WIFI_RTT का एलान करके PackageManager.FEATURE_WIFI_AWARE और वाई-फ़ाई लोकेशन (वाई-फ़ाई राउंड ट्रिप का समय — आरटीटी) की जानकारी देकर, वाई-फ़ाई नेबर अवेयरनेस नेटवर्किंग (एनएएन) प्रोटोकॉल के साथ काम करते हैं, तो वे:
  
  [7.4.2.5/H-1-1] एपीआई के तौर पर आपको वाई-फ़ाई की तीन मेगाहर्ट्ज़, तीन मेगाहर्ट्ज़, 8 मेगाहर्ट्ज़, और आपको 8 मेगाहर्ट्ज़ के फ़्रीक्वेंसी बैंड,
  
  [7.4.2.5/H-SR] 90वें पर्सेंटाइल पर 160 मेगाहर्ट्ज़ बैंडविड्थ के अंदर +/-1 मीटर के अंदर रेंज की सटीक रिपोर्ट देने का सुझाव दिया जाता है.साथ ही, यह भी ज़रूरी है कि
  
  मौजूदगी को कैलिब्रेट करने की ज़रूरी शर्तों में बताए गए, मेज़रमेंट सेटअप के तरीकों का पालन करने पर ज़ोर दिया जाता है.
  
  नई ज़रूरी शर्तें खत्म करना
- ऑडियो के इंतज़ार का समय:
  बदलाव देखें
  
  अगर हैंडहेल्ड डिवाइस पर लागू होने वाले android.hardware.audio.output और android.hardware.microphone के बारे में जानकारी दी जाती है, तो:
  - [5.6/H-1-1] दोतरफ़ा यात्रा का औसत इंतज़ार 500 ~~800~~ मिलीसेकंड या पांच से कम मापने का औसत समय होना चाहिए. साथ ही, उसका औसत कुल डेविएशन, 50 ~~100~~ मि॰से॰ से कम होना चाहिए. इन डेटा पाथ के लिए: "स्पीकर टू माइक्रोफ़ोन काम करता है", यूएसबी लूप (अगर काम करता हो), यूएसबी लूप (अगर काम करता हो). ~~काम करने वाला कम से कम एक पाथ.~~
  [5.6/H-1-1] टैप-टू-टोन के चलने का औसत समय 500 मिलीसेकंड तक या कम से कम पांच से कम तक का होना चाहिए. इसके लिए, स्पीकर और माइक्रोफ़ोन के डेटा पाथ का इस्तेमाल किया जाना चाहिए.
  
  नई ज़रूरी शर्तें खत्म करना
- हैप्टिक इनपुट:
  बदलाव देखें
  
  अगर हैंडहेल्ड डिवाइस में कम से कम एक हैप्टिक एक्चुएटर शामिल है, तो वे:
  - [7.10/H]* एक बहुत ज़्यादा रोटेटिंग मास (ईआरएम) हैप्टिक एक्चुएटर (वाइब्रेटर) का इस्तेमाल नहीं करना चाहिए.
  - [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.Vibrationimpact में क्लियर हैप्टिक के लिए सभी सार्वजनिक कॉन्सटेंट (जैसे:{/_TICK, RESULTS_Click, म्फ_HEAVY_Click और IN_DOUBLE_ टर्मिनलPRIMITIVE_* इनमें से कुछ प्रिमिटिव, जैसे कि LOW_TICK और Spin सिर्फ़ तब काम करते हैं, जब वाइब्रेटर काफ़ी कम फ़्रीक्वेंसी के साथ काम कर सकता हो.
  [7.10/H]* android.view.HapticFeedbackConstants में दिए गए सार्वजनिक कॉन्सटेंट को मैप करने के दिशा-निर्देशों का पालन, सुझाए गए android.os.Vibrationimpact कॉन्सटेंट के साथ करें और उससे जुड़े आयाम के संबंध भी बताएं.
  
  नई ज़रूरी शर्तें खत्म करना
  ~~[7.10/H]* लिंक किए गए इन हैप्टिक कॉन्सटेंट मैपिंग का इस्तेमाल करना चाहिए.~~
  [7.10/H]* इस बात की पुष्टि करनी चाहिए कि सार्वजनिक android.os.Vibrator.hasAmplitudeControl() एपीआई के नतीजे, उसके वाइब्रेटर की क्षमताओं को सही तरीके से दिखाते हैं.
  
  नई ज़रूरी शर्तें खत्म करना
  [7.10/H]* android.os.Vibrator.hasAmplitudeControl() का इस्तेमाल करके, डाइमेंशन की क्षमता की पुष्टि करनी चाहिए.
  अगर हैंडहेल्ड डिवाइस लागू करने के प्रोसेस में कम से कम एक लीनियर रेज़ोनेंट एक्चुएटर शामिल है, तो वे:
  - [7.10/H]* हैप्टिक एक्चुएटर को पोर्ट्रेट ओरिएंटेशन के (बाएं दाएं) ऐक्सिस में ले जाना चाहिए.
  - [7.10/H]* काम न करने वाले प्रिमिटिव के लिए फ़ॉलबैक कॉन्फ़िगरेशन की पुष्टि करना और उसे अपडेट करना ज़रूरी है. इसकी जानकारी, कॉन्सटेंट के लिए लागू करने से जुड़े दिशा-निर्देशों में दी गई है.
  - [7.10/H]* फ़ेल होने के जोखिम को कम करने के लिए, फ़ॉलबैक सहायता दी जानी चाहिए, जैसा कि यहां बताया गया है.
2.2.3 सॉफ़्टवेयर:
- ट्रिवियाल डिवाइस कॉटनट्रोल की पुष्टि करें:
  बदलाव देखें
  - [3.8.16/H-1-5] उपयोगकर्ता को ControlsProviderService और Control Control.isAuthRequired एपीआई के ज़रिए तीसरे पक्ष के ऐप्लिकेशन की ओर से रजिस्टर किए गए कंट्रोल से, ऐप्लिकेशन के सीमित पुष्टि करने वाले डिवाइस कंट्रोल से ऑप्ट आउट करने की सुविधा देनी होगी.
- MediaStyle नोटिफ़िकेशन:
  बदलाव देखें
  
  अगर हैंडहेल्ड डिवाइस पर MediaStyle नोटिफ़िकेशन काम करते हों, तो वे:
  - [3.8.3.1/H-1-SR] का खास तौर पर सुझाव दिया जाता है कि उपयोगकर्ता को दी जाने वाली सुविधा (जैसे कि “आउटपुट स्विचर”) जिसे सिस्टम यूज़र इंटरफ़ेस (यूआई) से ऐक्सेस किया जा सके. इसकी मदद से उपयोगकर्ता, उपलब्ध मीडिया रूट (उदाहरण के लिए, ब्लूटूथ डिवाइस और MediaRouter2Manager को दिए गए रूट) में से किसी एक पर स्विच कर सकते हैं. ऐसा तब किया जाता है, जब कोई ऐप्लिकेशन MediaRouter2Manager के साथ सूचना पोस्ट करता है.
2.2.4 परफ़ॉर्मेंस और पावर: फ़ोरग्राउंड सेवाएं चलाने वाले ऐप्लिकेशन के लिए नई ज़रूरी शर्तें.
बदलाव देखें
हैंडहेल्ड डिवाइस लागू करना:
- [8.5/H-0-1] सेटिंग मेन्यू में जाकर, फ़ोरग्राउंड सेवा पर चल रहे ऐप्लिकेशन को बंद करने और ऐसे सभी ऐप्लिकेशन को दिखाने की सुविधा होनी चाहिए जिनमें फ़ोरग्राउंड सेवा चालू है और इनमें से हर सेवा की अवधि को दिखाया जा सकता है. यह सुविधा, SDK टूल से जुड़े दस्तावेज़ में दी गई जानकारी के हिसाब से दी जानी चाहिए.
  
  कुछ ऐप्लिकेशन को छूट मिल सकती है. इसके अलावा, उन्हें इस्तेमाल करने के लिए उपलब्ध सुविधाओं में शामिल नहीं किया जा सकता या उनकी सूची में शामिल नहीं किया जा सकता. इस बारे में, एसडीके से जुड़े दस्तावेज़ में बताया गया है.
नई ज़रूरी शर्तें खत्म करना

2.2.7.1 मीडिया: 'हैंडहेल्ड' की ज़रूरी शर्तों के मीडिया सेक्शन में इस तरह के अपडेट:

बदलाव देखें

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

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

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

2.2.7.2 कैमरा: मीडिया परफ़ॉर्मेंस क्लास के कैमरे की ज़रूरी शर्तों से जुड़े अपडेट.
बदलाव देखें
अगर हैंडहेल्ड डिवाइस लागू करने के तरीके android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS के लिए android.os.Build.VERSION_CODES.T दिखाते हैं, तो ये:
- [7.5/H-1-1] पीछे वाला मुख्य कैमरा होना चाहिए, जिसमें कम से कम 12 मेगापिक्सल का रिज़ॉल्यूशन हो. इससे 4k@30fps पर वीडियो कैप्चर किया जा सकता है. इनमें मुख्य मुख्य कैमरा, पीछे वाला कैमरा होता है. इसका आईडी सबसे कम होता है.
- [7.5/H-1-2] आपके फ़ोन में एक मुख्य कैमरा होना चाहिए, जिसका रिज़ॉल्यूशन कम से कम पांच मेगापिक्सल से हो. साथ ही, इसमें 1080p@30fps पर वीडियो कैप्चर किया जा सकता हो. सामने का मुख्य कैमरा, सामने वाला कैमरा होता है, जिसका आईडी सबसे कम होता है.
- [7.5/H-1-3] android.info.supportedHardwareLevel प्रॉपर्टी को दोनों प्राइमरी कैमरों के लिए FULL या इससे बेहतर के तौर पर काम करना चाहिए.
- [7.5/H-1-4] दोनों प्राइमरी कैमरों के लिए CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME पर काम करना ज़रूरी है.
- [7.5/H-1-5] दोनों प्राइमरी कैमरों के लिए, सीटीएस कैमरा परफ़ॉर्मेंसटेस्ट की जांच के मुताबिक, 1080 पिक्सल रिज़ॉल्यूशन के लिए कैमरा2 JPEG कैप्चर लेटेंसी < 1000 मि॰से॰ से कम होनी चाहिए.
- [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] पीछे वाला मुख्य कैमरा होना चाहिए, जो 720 पिक्सल या 1080 पिक्सल @ 240 एफ़पीएस (फ़्रेम प्रति सेकंड) पर काम करता हो.
- [7.5/H-1-10] अगर अल्ट्रावाइड आरजीबी कैमरा भी उसी दिशा में है, तो मुख्य कैमरों के लिए कम से कम ZOOM_RATIO < 1.0 होना ज़रूरी है.
- [7.5/H-1-11] मुख्य कैमरों पर, एक साथ फ़्रंट-बैक वाली स्ट्रीमिंग की सुविधा लागू करनी होगी.
- [7.5/H-1-12] फ़्रंट और प्राइमरी बैक कैमरे, दोनों के लिए CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION का इस्तेमाल किया जा सकता है.
- [7.5/H-1-13] अगर एक ही दिशा में एक से ज़्यादा आरजीबी कैमरे हैं, तो मुख्य कैमरों के लिए LOGICAL_MULTI_CAMERA की सुविधा काम करनी चाहिए.
- [7.5/H-1-14] प्राइमरी फ़्रंट और प्राइमरी बैक कैमरे, दोनों के लिए STREAM_USE_CASE की सुविधा काम करनी चाहिए.
नई ज़रूरी शर्तें खत्म करना
2.2.7.3 हार्डवेयर: हार्डवेयर के लिए, मीडिया परफ़ॉर्मेंस क्लास की ज़रूरी शर्तों से जुड़े अपडेट.
बदलाव देखें
अगर हैंडहेल्ड डिवाइस लागू करने की प्रोसेस के बाद, android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS के लिए android.os.Build.VERSION_CODES.T रिस्पॉन्स मिलता है, तो ये:
- [7.1.1.1/H-2-1] स्क्रीन का रिज़ॉल्यूशन कम से कम 1080 पिक्सल होना चाहिए.
- [7.1.1.3/H-2-1] कम से कम 400 डीपीआई की स्क्रीन डेंसिटी होनी चाहिए.
- [7.6.1/H-2-1] आपके डिवाइस में कम से कम 8 जीबी की फ़िज़िकल मेमोरी होनी चाहिए.
नई ज़रूरी शर्तें खत्म करना
2.2.7.4 परफ़ॉर्मेंस: परफ़ॉर्मेंस के लिए मीडिया परफ़ॉर्मेंस क्लास से जुड़े अपडेट.
बदलाव देखें
अगर हैंडहेल्ड डिवाइस लागू करने की प्रोसेस के बाद, android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS के लिए android.os.Build.VERSION_CODES.T रिस्पॉन्स मिलता है, तो ये:
- [8.2/H-1-1] यह पक्का करना ज़रूरी है कि क्रम में लिखा गया डेटा, कम से कम 125 एमबी/से॰ का हो.
- [8.2/H-1-2] इस बात का ध्यान रखना ज़रूरी है कि इसमें कम से कम 10 एमबी/सेकंड का रैंडम तरीके से डेटा भेजा गया हो.
- [8.2/H-1-3] यह पक्का करना ज़रूरी है कि क्रम में कम से कम 250 एमबी/सेकंडरी रीड परफ़ॉर्मेंस हो.
- [8.2/H-1-4] यह पक्का करना ज़रूरी है कि आपके ऐप्लिकेशन में कम से कम 40 एमबी/सेकंड का रैंडम रीड परफ़ॉर्मेंस मिले.
नई ज़रूरी शर्तें खत्म करना
2.5.1 हार्डवेयर: तीन-ऐक्सिस एक्सलरोमीटर और 3-ऐक्सिस जाइरोस्कोप से जुड़ी ज़रूरी शर्तों के साथ-साथ, बाहरी व्यू वाले कैमरे से जुड़ी शर्तों के बारे में अपडेट.
बदलाव देखें

वाहन संबंधित डिवाइस पर विज्ञापन लागू करना:
- [7.3.1/A-0-4] ज़रूरी है कि वह Android कार सेंसर कोऑर्डिनेट सिस्टम का पालन करे.
- [7.3/A-SR] 3-ऐक्सिस एक्सलरोमीटर और 3-ऐक्सिस जाइरोस्कोप को शामिल करने के लिए बहुत ज़्यादा ध्यान दिया जाता है.
- [7.3/A-SR] TYPE_HEADING सेंसर को लागू करने और रिपोर्ट करने के लिए STRONGLY_सुझाया गया तरीका इस्तेमाल किया गया.
अगर वाहन संबंधित डिवाइस में एक्सलरोमीटर शामिल है, तो:
- [7.3.1/A-1-1] कम से कम 100 हर्ट्ज़ की फ़्रीक्वेंसी तक इवेंट रिपोर्ट करना ज़रूरी है.
अगर डिवाइस लागू करने के तरीके में 3-ऐक्सिस एक्सलरोमीटर शामिल है, तो वे:
- [7.3.1/A-SR] इस्तेमाल करने का सुझाव दिया जाता है, ताकि सीमित एक्सलरोमीटर के लिए कंपोज़िट सेंसर को लागू किया जा सके.
अगर वाहन संबंधित डिवाइस लागू करने के तरीके में तीन से कम ऐक्सिस वाला एक्सलरोमीटर शामिल है, तो वे:
- [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] का खास तौर पर सुझाव दिया जाता है कि जाइरोस्कोप की माप की रेंज को +/-250dps पर कॉन्फ़िगर किया जाए, ताकि रिज़ॉल्यूशन को बढ़ाया जा सके.
नई ज़रूरी शर्तें खत्म करना
अगर वाहन संबंधित डिवाइस में 3-ऐक्सिस जाइरोस्कोप शामिल है, तो वे:
- [7.3.4/A-SR] इस्तेमाल करने का सुझाव दिया जाता है, ताकि सीमित ऐक्सिस जाइरोस्कोप के लिए कंपोज़िट सेंसर का इस्तेमाल किया जा सके.
अगर वाहन संबंधित डिवाइस में तीन से कम ऐक्सिस वाला जाइरोस्कोप शामिल है, तो वे:
- [7.3.4/A-4-1] TYPE_GYROSCOPE_LIMITED_AXES सेंसर को लागू करना और उसकी रिपोर्ट करना ज़रूरी है.
- [7.3.4/A-4-2] TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED सेंसर को लागू करना और उसकी रिपोर्ट करना ज़रूरी है.
अगर वाहन संबंधित डिवाइस में TYPE_HEADING सेंसर शामिल है, तो वे:
- [7.3.4/A-4-3] कम से कम 1 हर्ट्ज़ की फ़्रीक्वेंसी तक इवेंट की रिपोर्ट उपलब्ध होनी चाहिए.
- [7.3.4/A-SR] कम से कम 10 हर्ट्ज़ की फ़्रीक्वेंसी तक इवेंट की रिपोर्ट करने के लिए STRONGLY_सुझाया गया तरीका अपनाएं.
- यह सही उत्तर के हिसाब से होना चाहिए.
- वाहन के स्थिर रहने पर भी उपलब्ध होना चाहिए.
- रिज़ॉल्यूशन कम से कम 1 डिग्री होना चाहिए.
नई ज़रूरी शर्तें खत्म करना
एक्सटीरियर व्यू कैमरा ऐसा कैमरा होता है जिसमें डिवाइस के कैमरे से अलग तस्वीरें ली जाती हैं. जैसे, रीयर व्यू कैमरा ~~डैशकैम~~ .

अगर ऑटोमोटिव डिवाइस में लागू होने वाले बाहरी व्यू कैमरा शामिल है, तो ऐसे कैमरे के लिए:
- [7.5.5/A-SR] को दिशा-निर्देश में रखने का बहुत ज़्यादा सुझाव दिया जाता है, ताकि कैमरे का लंबा डाइमेंशन क्षितिज के साथ अलाइन हो सके.
- ~~Android सिंक्रोनाइज़ेशन फ़्रेमवर्क के साथ काम करना चाहिए.~~
- हो सकता है कि कैमरा ड्राइवर में या तो हार्डवेयर ऑटो-फ़ोकस सुविधा या सॉफ़्टवेयर ऑटो-फ़ोकस लागू किया गया हो.
अगर वाहन संबंधित डिवाइस में एक या ज़्यादा व्यू कैमरे शामिल हैं और एक्सटीरियर व्यू सिस्टम (ईवीएस) सेवा लोड होती है, तो ऐसे कैमरे के लिए:
- [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 में बताया गया है.
नई ज़रूरी शर्तें खत्म करना
2.5.5 सुरक्षा मॉडल: वाहन संबंधित डिवाइसों के लिए, कैमरा से जुड़ी अनुमतियों के लिए नई ज़रूरी शर्तें.
बदलाव देखें
अगर Automotive डिवाइस में लागू किए गए android.hardware.camera.any का एलान किया जाता है, तो:
- [9.8.2/A-2-1] जब कोई ऐप्लिकेशन लाइव कैमरे का डेटा ऐक्सेस कर रहा हो, तब कैमरा इंंडिकेटर दिखाना ज़रूरी है. हालांकि, ऐसा तब नहीं करना चाहिए, जब सीडीडी आइडेंटिफ़ायर [C-3-X] के साथ सेक्शन 9.1 अनुमतियों में बताई गई भूमिकाओं वाले ऐप्लिकेशन ही कैमरे को ऐक्सेस कर रहे हों.
- [9.8.2/A-2-2] ऐसे सिस्टम ऐप्लिकेशन के लिए कैमरा इंडिकेटर को नहीं छिपाया जाना चाहिए जिसमें यूज़र इंटरफ़ेस या डायरेक्ट यूज़र इंटरैक्शन दिखता है.
नई ज़रूरी शर्तें खत्म करना
2.6.1 टैबलेट की ज़रूरी शर्तें — हार्डवेयर: टैबलेट के स्क्रीन साइज़ से जुड़ी ज़रूरी शर्तों के बारे में अपडेट.
बदलाव देखें

Android टैबलेट डिवाइस का मतलब ऐसे Android डिवाइस से है जो आम तौर पर इन सभी शर्तों को पूरा करता है:
- स्क्रीन डिसप्ले का साइज़ 7” और 18" से कम हो, जिसे डायगनल या तिरछा मापा जाता है.
स्क्रीन का साइज़

[7.1.1.1/Tab-0-1] स्क्रीन का साइज़ 7 से 18 इंच के बीच होना चाहिए.

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

3.2.2 बिल्ड पैरामीटर: getSerial() में अपडेट किए गए ASCII वर्ण.

बदलाव देखें

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

पैरामीटर	जानकारी
getSerial()	एक हार्डवेयर सीरियल नंबर होना (होना चाहिए या वापस करना) होना चाहिए, जो एक ही MODEL और MANUFACTURER के साथ सभी डिवाइसों पर उपलब्ध और अलग-अलग होना चाहिए. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर कोड में बदला जा सकता है और यह रेगुलर एक्सप्रेशन “^[a-zA-Z0-9]+$” से मैच होना चाहिए.

पैरामीटर

जानकारी

getSerial()

एक हार्डवेयर सीरियल नंबर होना (होना चाहिए या वापस करना) होना चाहिए, जो एक ही MODEL और MANUFACTURER के साथ सभी डिवाइसों पर उपलब्ध और अलग-अलग होना चाहिए. इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर कोड में बदला जा सकता है और यह रेगुलर एक्सप्रेशन “^[a-zA-Z0-9]+$” से मैच होना चाहिए.

3.2.3.5 कंडिशनल ऐप्लिकेशन इंटेंट: शर्तों के साथ आवेदन करने के इंटेंट के लिए अपडेट.
बदलाव देखें
अगर लागू किए जाने वाले डिवाइस में कोई बड़ा डिसप्ले (आम तौर पर डिसप्ले की चौड़ाई और ऊंचाई 600dp+) हो और वह स्प्लिट फ़ंक्शन के साथ काम करता हो, तो वे:
- [C-17-1] ज़रूरी है कि आपके पास कोई ऐसी गतिविधि होनी चाहिए जो बांटने की सुविधा चालू होने पर, Settings#ACTION_SETTINGS_VERSION_DEEP_LINK_ACTIVITY के इंटेंट को मैनेज करती हो. गतिविधि को android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK से सुरक्षित करना ज़रूरी है और इसके लिए Settings##additional_SETTINGS_VERSIONDED_DEEP_LINK_INTENT_uri से पार्स किए गए इंटेंट की गतिविधि शुरू करनी होगी.
नई ज़रूरी शर्तें खत्म करना
3.5.1 ऐप्लिकेशन पर पाबंदी: ऐप्लिकेशन से जुड़ी पाबंदियों के बारे में अपडेट.
बदलाव देखें

अगर डिवाइस लागू करने की प्रोसेस में ऐप्लिकेशन पर पाबंदी लगाने के लिए मालिकाना हक वाला कोई तरीका लागू किया जाता है (उदाहरण के लिए, SDK टूल में बताए गए एपीआई के काम करना या उसे बदलना और वह तरीका पाबंदी वाले ऐप्लिकेशन स्टैंडबाय बकेट की तुलना में ज़्यादा प्रतिबंधित है, तो वे:
- [C-1-1] उपयोगकर्ता को पाबंदी वाले ऐप्लिकेशन की सूची देखने की अनुमति देनी होगी.
- [C-1-2] ऐप्लिकेशन पर मालिकाना हक से जुड़ी इन सभी पाबंदियों को चालू / बंद करने के लिए, लोगों को सुविधाएं देनी होंगी.
- [C-1-3] सिस्टम की खराब परफ़ॉर्मेंस दिखाए बिना, अपने-आप लागू होने वाली इन पाबंदियों को अपने-आप लागू नहीं करना चाहिए. हालांकि, सिस्टम की खराब परफ़ॉर्मेंस का पता लगाने पर, ऐप्लिकेशन पर पाबंदियां लगाई जा सकती हैं. जैसे, अटके हुए वेकलॉक, लंबे समय तक चलने वाली सेवाएं, और अन्य शर्तें. ये शर्तें, डिवाइस पर ऐप्लिकेशन लागू करने वालों की मदद से तय की जा सकती हैं. हालांकि, इन्हें इस बात से जुड़ा होना चाहिए कि सिस्टम की परफ़ॉर्मेंस पर ऐप्लिकेशन का क्या असर पड़ता है. ऐसी अन्य शर्तें जो पूरी तरह से सिस्टम की परफ़ॉर्मेंस से जुड़ी नहीं हैं. जैसे, बाज़ार में ऐप्लिकेशन की लोकप्रियता का कम होना. इन शर्तों का इस्तेमाल नहीं किया जाना चाहिए.
- [C-1-4] अगर कोई उपयोगकर्ता, ऐप्लिकेशन पर पाबंदियों को मैन्युअल तरीके से बंद कर देता है, तो उस पर अपने-आप लागू होने वाली पाबंदियां अपने-आप लागू नहीं होनी चाहिए. साथ ही, हो सकता है कि उपयोगकर्ता को अपने मालिकाना हक से जुड़ी ये पाबंदियां लागू करने का सुझाव भी दिया जाए.
- [C-1-5] उपयोगकर्ताओं को इस बारे में बताना ज़रूरी है कि क्या ऐप्लिकेशन पर मालिकाना हक से जुड़ी ये पाबंदियां अपने-आप लागू होती हैं. इस तरह की जानकारी, मालिकाना हक पर लगाई गई इन पाबंदियों को लागू करने से पहले 24 घंटे में देनी ज़रूरी है.
- [C-1-6] किसी ऐप्लिकेशन से किए जाने वाले एपीआई कॉल के लिए, ActivityManager.isBackgroundAction() वाले तरीके के लिए सही नतीजे दिखाना ज़रूरी है.
- [C-1-7] उस मुख्य ऐप्लिकेशन पर पाबंदी नहीं लगानी चाहिए जिसका इस्तेमाल उपयोगकर्ता साफ़ तौर पर कर रहा है.
- [C-1-8] जब भी कोई उपयोगकर्ता साफ़ तौर पर उस ऐप्लिकेशन को इस्तेमाल करना शुरू करता है, तो उसे ऐप्लिकेशन पर मालिकाना हक से जुड़ी इन पाबंदियों को निलंबित करना होगा. ऐसा होने पर, यह ऐप्लिकेशन टॉप फ़ोरग्राउंड ऐप्लिकेशन बन जाता है.
- [C-1-9] इस्तेमाल करने के आंकड़ों के ज़रिए, मालिकाना हक से जुड़े इन सभी इवेंट की रिपोर्ट ज़रूर दें.
- [C-1-10] एक सार्वजनिक और साफ़ तौर पर जानकारी देने वाला दस्तावेज़ या वेबसाइट होनी चाहिए, जिसमें मालिकाना हक से जुड़े प्रतिबंध लागू होने के बारे में बताया गया हो. यह दस्तावेज़ या वेबसाइट, Android SDK के दस्तावेज़ों से लिंक होनी चाहिए. साथ ही, इसमें यह जानकारी शामिल होनी चाहिए:
  
  मालिकाना हक से जुड़ी पाबंदियों के लिए शर्तें ट्रिगर करना.
  
  किसी ऐप्लिकेशन पर क्या और कैसे पाबंदी लगाई जा सकती है.
  
  किसी ऐप्लिकेशन को इस तरह की पाबंदियों से किस तरह छूट दी जा सकती है.
  
  कोई ऐप्लिकेशन, मालिकाना हक वाली पाबंदियों से छूट का अनुरोध कैसे कर सकता है. ऐसा तब होगा, जब वह उन ऐप्लिकेशन के लिए छूट का अनुरोध करता हो जिन्हें उपयोगकर्ता इंस्टॉल कर सकता है.
अगर कोई ऐप्लिकेशन डिवाइस पर पहले से इंस्टॉल है और उपयोगकर्ता ने उसे 30 दिनों से ज़्यादा समय से इस्तेमाल नहीं किया है, तो [C-1-3] [C-1-5] को छूट दी जाती है.

नई ज़रूरी शर्तें खत्म करना
3.8.1 लॉन्चर (होम स्क्रीन): monochrome/adaptive-icon पर काम करने के लिए अपडेट.
बदलाव देखें
अगर डिवाइस में मोनोक्रोम आइकॉन काम करते हैं, तो ये आइकॉन:
- [C-6-1] इसका इस्तेमाल सिर्फ़ तब किया जाना चाहिए, जब कोई उपयोगकर्ता साफ़ तौर पर इन्हें चालू करता है (उदाहरण के लिए, सेटिंग या वॉलपेपर पिकर मेन्यू की मदद से).
नई ज़रूरी शर्तें खत्म करना
3.8.2 विजेट: लॉन्चर में तीसरे पक्ष के ऐप्लिकेशन विजेट की मौजूदगी के बारे में अपडेट.
बदलाव देखें

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

बदलाव देखें

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

बदलाव देखें

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

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

अगर लागू किए गए डिवाइस में कोई स्क्रीन या वीडियो आउटपुट शामिल है, तो वे:
- [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.
  
  android.theme.customization.system_palette की मदद से भेजे जाने पर, "सोर्स रंग" का इस्तेमाल डाइनैमिक कलर टोनल पैलेट जनरेट करने के लिए किया जाता है (जैसा कि Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES में बताया गया है).
- [C-1-6] CAM16 क्रोमा वैल्यू 5 या इससे ज़्यादा होनी चाहिए.
  
  इसे com.android.systemui.monet.ColorScheme#getSeedColors की मदद से वॉलपेपर से लिया जाना चाहिए. इससे चुनने के लिए, कई मान्य सोर्स कलर उपलब्ध होते हैं.
  
  अगर दिया गया कोई भी रंग, ऊपर बताई गई सोर्स कलर की ज़रूरी शर्तों को पूरा नहीं करता है, तो वैल्यू 0xFF1B6EF3 का इस्तेमाल करना चाहिए.
नई ज़रूरी शर्तें खत्म करना
3.8.17 क्लिपबोर्ड: क्लिपबोर्ड पर मौजूद कॉन्टेंट के लिए, ज़रूरी शर्तों वाला नया सेक्शन जोड़ा गया.
बदलाव देखें
3.8.17. क्लिपबोर्ड

डिवाइस पर यह सुविधा लागू करना:
- [C-0-1] 9.8.6 कॉन्टेंट कैप्चर और ऐप्लिकेशन सर्च में बताई गई सेवाओं को छोड़कर, उपयोगकर्ता को साफ़ तौर पर कोई कार्रवाई (उदाहरण के लिए, ओवरले पर बटन दबाना) किए बिना, किसी भी कॉम्पोनेंट, गतिविधि, सेवा या किसी भी इंटरनेट कनेक्शन पर क्लिपबोर्ड डेटा नहीं भेजना चाहिए.
अगर किसी डिवाइस पर लागू होने वाले किसी भी ClipData आइटम के कॉन्टेंट को क्लिपबोर्ड पर कॉपी किया जाता है और उस पर लागू होने वाले किसी डिवाइस की झलक, उपयोगकर्ता को दिखने लगती है, तो वे:ClipData.getDescription().getExtras()android.content.extra.IS_SENSITIVE
- [C-1-1] लोगों को दिखने वाली झलक को छिपाने के लिए उसमें बदलाव करना ज़रूरी है
एओएसपी रेफ़रंस को लागू करने के लिए, क्लिपबोर्ड की इन ज़रूरी शर्तों को पूरा किया जाता है.

नई ज़रूरी शर्तें खत्म करना
3.9.1.1 डिवाइस के मालिक के लिए प्रावधान करने से जुड़ी ज़रूरी शर्तें: डिवाइस के मालिक के लिए प्रावधान से जुड़ी ज़रूरी शर्तों के बारे में अपडेट.
बदलाव देखें

अगर लागू किए गए डिवाइस पर android.software.device_admin का एलान किया जाता है, तो:
- [C-1-1] डिवाइस पॉलिसी क्लाइंट (डीपीसी) को डिवाइस के मालिक के ऐप्लिकेशन के तौर पर रजिस्टर करने की सुविधा होनी चाहिए, जैसा कि यहां बताया गया है:
  - अगर लागू किए गए डिवाइस में उपयोगकर्ताओं का और उपयोगकर्ता का डेटा कॉन्फ़िगर नहीं किया गया है, तो वह:
    
    [C-1-5] DPC ऐप्लिकेशन को डिवाइस के मालिक के ऐप्लिकेशन के रूप में रजिस्टर करना ज़रूरी है या डिवाइस का मालिक बनने या प्रोफ़ाइल का मालिक बनने का विकल्प चुनने के लिए 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] ऐप्लिकेशन को डिवाइस के मालिक के तौर पर सेट किए जाने से पहले, असली उपयोगकर्ता की उपयोगकर्ता की कार्रवाई या प्रोग्राम के हिसाब से सहमति देने की सहमति मिल सकती है. हालांकि, डिवाइस के मालिक का प्रावधान शुरू करने से पहले, सही जानकारी देने वाला नोटिस (जैसा कि एओएसपी में बताया गया है) दिखाना ज़रूरी है. साथ ही, डिवाइस के मालिक के प्रावधान के लिए, प्रोग्रामैटिक डिवाइस के मालिक की सहमति लेने के तरीके (एंटरप्राइज़ की ओर से) का इस्तेमाल, नॉन-एंटरप्राइज़ के लिए आउट-ऑफ़-बॉक्स एक्सपीरियंस में रुकावट नहीं डालने चाहिए.
- [C-1-3] सहमति को हार्ड कोड नहीं करना चाहिए या डिवाइस के मालिक के अन्य ऐप्लिकेशन के इस्तेमाल पर रोक नहीं लगानी चाहिए.
अगर डिवाइस को लागू करने के तरीके के बारे में android.software.device_admin बताया जाता है, लेकिन उसमें ~~डिवाइस का मालिक~~ के मालिकाना हक वाला डिवाइस मैनेजमेंट समाधान भी शामिल है और उनके समाधान में कॉन्फ़िगर किए गए ऐप्लिकेशन को प्रमोट करने का एक तरीका दिया गया है, तो वह:
- [C-2-1] ज़रूरी है कि जिस ऐप्लिकेशन का प्रमोशन किया जा रहा है वह किसी वैध एंटरप्राइज़ डिवाइस मैनेजमेंट समाधान से जुड़ा हो. साथ ही, मालिकाना समाधान में इस तरह से कॉन्फ़िगर किया गया हो कि उसके पास "डिवाइस के मालिक" के बराबर अधिकार हों.
- [C-2-2] डीपीसी ऐप्लिकेशन को "डिवाइस के मालिक" के तौर पर रजिस्टर करने से पहले, android.app.action.PROVISION_MANAGED_DEVICE ने जिस फ़्लो को शुरू किया था, एओएसपी डिवाइस के मालिक की सहमति की जानकारी दिखाना ज़रूरी है.
- [C-2-3] सहमति को हार्ड कोड नहीं करना चाहिए या डिवाइस के मालिक के अन्य ऐप्लिकेशन के इस्तेमाल पर रोक नहीं लगानी चाहिए.
- DPC ऐप्लिकेशन को "डिवाइस के मालिक" के तौर पर रजिस्टर करने से पहले, डिवाइस पर उपयोगकर्ता का डेटा हो सकता है.
3.9.4 डिवाइस मैनेजमेंट से जुड़ी भूमिका की ज़रूरी शर्तें: डिवाइस मैनेजमेंट से जुड़ी ज़रूरी शर्तों के लिए एक सेक्शन जोड़ा गया.
बदलाव देखें
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.18 Contacts: नए संपर्कों की जानकारी जोड़ना.
बदलाव देखें
नए संपर्कों के लिए डिफ़ॉल्ट खाता: संपर्क देने वाली कंपनी नया संपर्क बनाते समय, डिफ़ॉल्ट खाते की सेटिंग मैनेज करने के लिए एपीआई उपलब्ध कराती है.

अगर लागू होने वाले डिवाइस में किसी संपर्क ऐप्लिकेशन को पहले से लोड किया जाता है, तो पहले से लोड किए गए संपर्क ऐप्लिकेशन:
- [C-2-1] खाता चुनने के लिए यूज़र इंटरफ़ेस (यूआई) लॉन्च करने के लिए, ContactsContract.Settings.ACTION_SET_DEFAULT_ACCOUNT इंटेंट को हैंडल करना ज़रूरी है. साथ ही, कोई खाता चुनने पर, इस सेटिंग को Contacts की सेवा देने वाली कंपनी में सेव करना ज़रूरी है.
- [C-2-2] ContactsContracts.Contacts.CONTENT_TYPE और ContactsContract.RawContacts.CONTENT_TYPE के लिए Intent.ACTION_INSERT and Intent.ACTION_INSERT_OR_EDIT को हैंडल करते समय, खाते की डिफ़ॉल्ट सेटिंग का पालन करना ज़रूरी है. इसके लिए, शुरुआत में खाता चुनें.
नई ज़रूरी शर्तें खत्म करना

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

4. ऐप्लिकेशन पैकेजिंग के साथ काम करने की सुविधा: APK सिग्नेचर स्कीम वर्शन के अपडेट.
बदलाव देखें

डिवाइस पर यह सुविधा लागू करना:
- [C-0-2] APK सिग्नेचर स्कीम v3.1 , APK सिग्नेचर स्कीम v3, APK सिग्नेचर स्कीम v2, और JAR साइनिंग का इस्तेमाल करके “.apk” फ़ाइलों की पुष्टि करने की सुविधा होनी चाहिए.
- [C-0-9] APK सिग्नेचर स्कीम v4 और APK सिग्नेचर स्कीम v4 .1 का इस्तेमाल करके, .apk फ़ाइलों की पुष्टि करने की सुविधा ज़रूरी है.

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

5.1.2 ऑडियो डिकोड करने की सुविधा: कई चैनलों का ऑडियो जनरेट करने वाले डिकोडर के लिए नई ज़रूरी शर्तें जोड़ी गई हैं.
बदलाव देखें
अगर डिवाइस लागू करने की सुविधा, 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] इस बात की बहुत ज़्यादा सलाह दी जाती है कि ऐप्लिकेशन, कुंजी को KEY_MAX_OUTPUT_CHANNEL_COUNT की मदद से डिकोड करके कॉन्फ़िगर कर सके. इससे यह कंट्रोल किया जा सकता है कि कॉन्टेंट को स्टीरियो में डाउनग्रेड किया जाए या नहीं (2 की वैल्यू इस्तेमाल करने पर) या आउटपुट में चैनल की मूल संख्या का इस्तेमाल किया जाए या नहीं (जब उस संख्या के बराबर या उससे ज़्यादा वैल्यू का इस्तेमाल किया जाए). उदाहरण के लिए, 6 या उससे ज़्यादा वैल्यू वाली डिकोडर, 5.1 कॉन्टेंट फ़ीड किए जाने पर 6 चैनलों का आउटपुट देने के लिए, डिकोडर को कॉन्फ़िगर करेगा.
- [C-SR] डिकोड करते समय, डिकोडर का बहुत ज़्यादा सुझाव दिया जाता है, ताकि android.media.AudioFormat कॉन्सटेंट (उदाहरण:CHANNEL_OUT_5POINT1) का इस्तेमाल करके, आउटपुट फ़ॉर्मैट पर इस्तेमाल किए जा रहे चैनल मास्क का विज्ञापन दिखाने के लिए, KEY_CHANNEL_MASK कुंजी का इस्तेमाल किया जा सके.
नई ज़रूरी शर्तें खत्म करना
5.4.1 ऑडियो कैप्चर करने और माइक्रोफ़ोन की रॉ जानकारी: ऑडियो इनपुट स्ट्रीम के लिए, साथ काम करने वाले ऑडियो सोर्स के अपडेट.
बदलाव देखें

अगर लागू किए गए डिवाइस पर android.hardware.microphone का एलान किया जाता है, तो:
- [C-1-1] किसी भी AudioRecord या AAudio के लिए, खुली हुई इनपुट स्ट्रीम के लिए, यहां दिए गए एट्रिब्यूट के साथ रॉ ऑडियो कॉन्टेंट को कैप्चर करने की अनुमति देनी चाहिए. कम से कम, नीचे दिए गए एट्रिब्यूट का इस्तेमाल करना ज़रूरी है:
  - फ़ॉर्मैट: लीनियर PCM, 16-बिट
  - सैंपलिंग रेट: 8,000, 11,025, 16,000, 44,100, 48,000 हर्ट्ज़
  - चैनल: मोनो
  - ऑडियो सोर्स: DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED, या VOICE_PERFORMANCE. यह AAudio में मिलते-जुलते इनपुट प्रीसेट पर भी लागू होता है, जैसे कि AAUDIO_INPUT_PRESET_CAMCORDER.
  - [C-1-4] MicrophoneInfo API का पालन करना ज़रूरी है. साथ ही, AudioManager.getMicrophones() एपीआई के ज़रिए तीसरे पक्ष के ऐप्लिकेशन पर उपलब्ध माइक्रोफ़ोन की जानकारी ठीक से भरें. इस सुविधा का इस्तेमाल करने के लिए, MediaRecorder.AudioSources DEFAULT, MIC, CAMCORDER, VOICE_RECOGNITION, VOICE_COMMUNICATION, UNPROCESSED या VOICE_PERFORMANCE का इस्तेमाल किया जाता है. साथ ही, चालू माइक्रोफ़ोन जिन्हें तीसरे पक्ष के ऐप्लिकेशन AudioRecord.getActiveMicrophones() और MediaRecorder.getActiveMicrophones() एपीआई से ऐक्सेस कर सकते हैं.
5.4.2 आवाज़ की पहचान करने के लिए कैप्चर करें: आवाज़ की पहचान करने वाली ऑडियो स्ट्रीम के लिए अपडेट की गई ज़रूरी शर्तें और माइक्रोफ़ोन गेन लेवल के लिए जोड़ी गई ज़रूरी शर्तें.
बदलाव देखें

अगर लागू किए गए डिवाइस पर android.hardware.microphone का एलान किया जाता है, तो:
आवाज़ की पहचान करने वाली ऑडियो स्ट्रीम को फ़्रीक्वेंसी में बदलाव से पहले, करीब सपाट आयाम के साथ रिकॉर्ड करना चाहिए: खास तौर पर, ±3 dB, 100 हर्ट्ज़ से लेकर 4000 हर्ट्ज़ तक.

इनपुट सेंसिटिविटी सेट करके, आवाज़ पहचानने वाली ऑडियो स्ट्रीम को रिकॉर्ड किया जाना चाहिए. जैसे, 1,000 हर्ट्ज़ पर 90 dB साउंड पावर लेवल (एसपीएल) सोर्स से, 16-बिट के सैंपल के लिए 2,500 आरएमएस पाएं.
- औसत फ़्रीक्वेंसी रेंज में, डाइमेंशन और फ़्रीक्वेंसी की फ़्रीक्वेंसी सामान्य दिखने चाहिए: खास तौर पर, आवाज़ की पहचान करने वाले ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए जाने वाले हर माइक्रोफ़ोन के लिए, 100 हर्ट्ज़ से लेकर 4000 हर्ट्ज़ तक.
- [C-SR] का सुझाव दिया जाता है कि कम फ़्रीक्वेंसी की रेंज में आयाम स्तर दिखाया जाए: खास तौर पर, आवाज़ की पहचान करने वाले ऑडियो स्रोत को रिकॉर्ड करने वाले हर माइक्रोफ़ोन के लिए, औसत फ़्रीक्वेंसी रेंज की तुलना में ±20 dB से लेकर 30 हर्ट्ज़ तक से लेकर 100 हर्ट्ज़ तक.
- [C-SR] का बहुत ज़्यादा सुझाव दिया जाता है, ताकि आवाज़ की पहचान करने वाले ऑडियो के स्रोत को रिकॉर्ड करने के लिए इस्तेमाल किए जाने वाले हर माइक्रोफ़ोन की मिड-फ़्रीक्वेंसी रेंज की तुलना में, फ़्रीक्वेंसी रेंज में आयाम का लेवल दिखाया जा सके. खास तौर पर ±30 dB से लेकर 4000 हर्ट्ज़ से 22 किलोहर्ट्ज़ तक.
- ऑडियो इनपुट की संवेदनशीलता को इस तरह सेट करना चाहिए कि हर फ़्लोटिंग माइक्रोफ़ोन की पहचान के लिए 90 dB के साउंड प्रेशर लेवल (माइक्रोफ़ोन के बगल में मापा गया) पर चलाया गया 1000 हर्ट्ज़ वाला साइनसोइडल टोन सोर्स (माइक्रोफ़ोन के बगल में मापा गया) RMS 2500 का आदर्श रिस्पॉन्स दे.
नई ज़रूरी शर्तें खत्म करना
5.4.6 माइक्रोफ़ोन गेन लेवल: माइक्रोफ़ोन गेन लेवल की ज़रूरी शर्तों को सेक्शन 5.4.2 में ले जाया गया.
बदलाव देखें

5.4.6. माइक्रोफ़ोन गेन लेवल [5.4.2 पर ले जाया गया]
अगर लागू किए गए डिवाइस पर android.hardware.microphone का एलान किया जाता है, तो:

आवाज़ की पहचान करने वाले ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किए जाने वाले हर माइक्रोफ़ोन के लिए, औसत फ़्रीक्वेंसी रेंज में करीब-करीब सपाट आयाम और फ़्रीक्वेंसी के आंकड़े दिखाए जाने चाहिए: खास तौर पर, 100 हर्ट्ज़ से लेकर 4000 हर्ट्ज़ तक.

[C-SR] का सुझाव दिया जाता है कि कम फ़्रीक्वेंसी रेंज में आयाम स्तर दिखाया जाए: खास तौर पर, आवाज़ की पहचान करने वाले ऑडियो स्रोत को रिकॉर्ड करने वाले हर माइक्रोफ़ोन के लिए, औसत फ़्रीक्वेंसी रेंज की तुलना में ±20 dB से लेकर 100 हर्ट्ज़ तक.

आवाज़ की पहचान करने वाले ऑडियो स्रोत को रिकॉर्ड करने के लिए इस्तेमाल किए जाने वाले हर माइक्रोफ़ोन की मिड-फ़्रीक्वेंसी रेंज की तुलना में, [C-SR] को बहुत ज़्यादा फ़्रीक्वेंसी रेंज में आयाम स्तर दिखाने का सुझाव दिया जाता है: खास तौर पर ±30 dB से लेकर 4000 हर्ट्ज़ से लेकर 22 किलोहर्ट्ज़ तक.

ऑडियो इनपुट की संवेदनशीलता को इस तरह सेट करना चाहिए कि 90 dB के साउंड प्रेशर लेवल (SPL) पर चलाए जाने वाले 1000 हर्ट्ज़ वाले साइनसोइडल टोन सोर्स से हर ऑडियो सोर्स के लिए इस्तेमाल किए गए हर माइक्रोफ़ोन के लिए, 16 बिट-सैंपल (या -22.35 dB फ़ुल स्केल के लिए -22.35 dB फ़ुल स्केल) के RMS के साथ रिस्पॉन्स दिया जाता है.
5.5.4 ऑडियो ऑफ़लोड: ऑडियो ऑफ़लोड प्लेबैक की ज़रूरी शर्तों के बारे में अपडेट.
बदलाव देखें

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

इस सेक्शन के लिए, इन परिभाषाओं का इस्तेमाल करें:
कोल्ड आउटपुट सिग्नल में गड़बड़ी. कोल्ड आउटपुट इंतज़ार के समय की वैल्यू के अलग-अलग मेज़रमेंट में उतार-चढ़ाव.

कोल्ड इनपुट सिग्नल में गड़बड़ी. कोल्ड इनपुट इंतज़ार के समय की वैल्यू के अलग-अलग मेज़रमेंट में होने वाला बदलाव.
अगर डिवाइस पर लागू होने वाले android.hardware.audio.output का एलान किया जाता है, तो उन्हें इन ज़रूरी शर्तों को पूरा करना होगा या इन्हें पार करना होगा:
- [C-1-2] कोल्ड आउटपुट में 500 मिलीसेकंड या इससे कम इंतज़ार का समय.
- [C-1-3] AAudioStreamBuilder_openStream() का इस्तेमाल करके आउटपुट स्ट्रीम खोलने में 1000 मिलीसेकंड से कम समय लगना चाहिए.
अगर डिवाइस पर लागू होने वाले android.hardware.audio.output के बारे में एलान किया जाता है, तो उन्हें नीचे दी गई ज़रूरी शर्तों को पूरा करने या उनसे ज़्यादा करने के लिए इस्तेमाल करने का सुझाव दिया जाता है:
- [C-SR] स्पीकर के डेटा पाथ पर, कोल्ड आउटपुट के लिए इंतज़ार का समय 100 मिलीसेकंड या उससे कम होना चाहिए. हमारा सुझाव है कि Android के इस वर्शन पर काम करने वाले मौजूदा और नए डिवाइस, इन ज़रूरी शर्तों को अभी पूरा करें. आने वाले समय में, प्लैटफ़ॉर्म के लॉन्च होने के बाद, हमें 200 मि॰से॰ या उससे कम के कोल्ड आउटपुट इंतज़ार के समय की ज़रूरत होगी.
- ~~[C-SR] कोल्ड आउटपुट की गड़बड़ी को कम करें.~~
अगर लागू किए जाने वाले डिवाइसों में android.hardware.microphone शामिल है, तो उन्हें इनपुट ऑडियो से जुड़ी इन ज़रूरी शर्तों को पूरा करना होगा:
- [C-3-2] कोल्ड इनपुट का इंतज़ार का समय 500 मिलीसेकंड या इससे कम होना चाहिए.
- [C-3-3] AAudioStreamBuilder_openStream() का इस्तेमाल करके इनपुट स्ट्रीम खोलने में 1,000 मिलीसेकंड से कम समय लगना चाहिए.
अगर लागू करने वाले डिवाइस में android.hardware.microphone शामिल है, तो इनपुट ऑडियो की इन ज़रूरतों को पूरा करने के लिए इनका सुझाव दिया जाता है:
- [C-SR] माइक्रोफ़ोन के डेटा पाथ पर, 100 मिलीसेकंड या उससे कम कोल्ड इनपुट के इंतज़ार का समय. हमारा सुझाव है कि Android के इस वर्शन पर काम करने वाले मौजूदा और नए डिवाइस, इन ज़रूरी शर्तों को अभी पूरा करें. आने वाले समय में, हमें इस प्लैटफ़ॉर्म के रिलीज़ होने में 200 मि॰से॰ या इससे कम का कोल्ड इनपुट इंतज़ार करना होगा, जितना ज़रूरी है.
[C-SR] इनपुट में 30 मिलीसेकंड या उससे कम का लगातार इंतज़ार का समय.

[सी-एसआर] कोल्ड इनपुट सिग्नल की गड़बड़ी को कम करें.
5.10 प्रोफ़ेशनल ऑडियो: पेशेवर ऑडियो की सुविधा के लिए, आवाज़ के इंतज़ार का समय तय करने से जुड़ी ज़रूरी शर्तों के बारे में अपडेट.
बदलाव देखें

अगर डिवाइस लागू करने की प्रोसेस, android.content.pm.PackageManager क्लास के ज़रिए android.hardware.audio.pro सुविधा के लिए सहायता की रिपोर्ट देती है, तो वे:
- [C-1-2] दोतरफ़ा यात्रा के ऑडियो का इंतज़ार का समय, सेक्शन 5.6 ऑडियो के इंतज़ार का समय 25 मिलीसेकंड या उससे कम में बताया जाना चाहिए ~~और 10 मिलीसेकंड या उससे कम का होना चाहिए~~. ऐसा कम से कम एक काम करने वाले पाथ से किया जाना चाहिए.
- [C-1-5] Aऑडियो नेटिव ऑडियो एपीआई और AAUDIO_PERFORMANCE_MODE_LOW_LATENCY का इस्तेमाल करके इंतज़ार के समय और यूएसबी ऑडियो की ज़रूरी शर्तों को पूरा करना ज़रूरी है.
- [C-1-8] टैप-टू-टोन का औसत समय 80 मिलीसेकंड या स्पीकर से माइक्रोफ़ोन डेटा पाथ की तुलना में कम से कम पांच से कम तक होना चाहिए.
- [सी-एसआर] इस बात का बहुत ज़्यादा सुझाव दिया जाता है कि जब ऑडियो चालू हो और सीपीयू पर लोड अलग-अलग हो, तब भी सीपीयू की परफ़ॉर्मेंस एक जैसी रखी जाए. इसकी जांच Android ऐप्लिकेशन SynthMark का इस्तेमाल करके की जानी चाहिए. SynthMark, सिम्युलेटेड ऑडियो फ़्रेमवर्क पर चलने वाले एक सॉफ़्टवेयर सिंथेसाइज़र का इस्तेमाल करता है. यह सिस्टम की परफ़ॉर्मेंस का आकलन करता है. मानदंड की जानकारी के लिए, SynthMark का दस्तावेज़ देखें. SynthMark को “अपने-आप होने वाली जांच” विकल्प का इस्तेमाल करके चलाया जाना चाहिए. इससे ये नतीजे मिल सकते हैं: * Voicemark.90 >= 32 आवाज़ें * थींलेटमार्क.फ़िक्स्ड.little <= 15 मि॰से॰ * lengthmark. Dynamic.little <= 50 msectle <= 50 msec
- टच इनपुट से लेकर ऑडियो आउटपुट तक, इंतज़ार का समय 40 मि॰से॰ या उससे कम होना चाहिए.
अगर लागू किए जाने वाले डिवाइसों में 4 कंडक्टर 3.5 मि॰मी॰ का ऑडियो जैक शामिल है, तो वे:
- [C-2-1] ऑडियो के लिए 20 मिलीसेकंड या उससे कम समय के हिसाब से, लगातार दोतरफ़ा यात्रा का ऑडियो ट्रैक होना चाहिए.इसके लिए, 20 मिलीसेकंड या उससे कम समय के साथ, ऑडियो जैक पाथ का मीन ऐब्सलूट डेविएशन5 से कम होना चाहिए.

5.12 एचडीआर वीडियो: एचडीआर वीडियो की ज़रूरी शर्तों के लिए, एक नया सेक्शन जोड़ा गया.

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

6.1 डेवलपर टूल: कनेक्टिविटी और जीपीयू कर्नेल की ज़रूरी शर्तों के बारे में अपडेट.
बदलाव देखें

अगर लागू किए गए डिवाइस पर वाई-फ़ाई या ईथरनेट के ज़रिए होस्ट मशीन से adb कनेक्शन काम करते हैं, तो वे:
- [C-4-1] वैल्यू के तौर पर AdbManager#isAdbWifiSupported() तरीके से रिटर्न true करना ज़रूरी है.
अगर डिवाइस लागू करने के तरीके में वाई-फ़ाई या ईथरनेट के ज़रिए किसी होस्ट मशीन से adb कनेक्शन काम करते हैं और उसमें कम से कम एक कैमरा शामिल है, तो वे:
- [C-5-1] AdbManager#isAdbWifiQrSupported() तरीके से, रिटर्न true होना चाहिए.
- जीपीयू के काम से जुड़ी जानकारी
  
  डिवाइस पर यह सुविधा लागू करना:
  
  [C-6-1] शेल कमांड dumpsys gpu --gpuwork लागू करना ज़रूरी है. इससे power/gpu_work_period कर्नेल ट्रेस पॉइंट से मिला जीपीयू का वर्क डेटा दिखाया जा सकता है जिसे इकट्ठा किया गया है. अगर ट्रेसपॉइंट काम नहीं करता है, तो कोई डेटा नहीं दिखाएं. एओएसपी लागू करने की सुविधा frameworks/native/services/gpuservice/gpuwork/ है.
नई ज़रूरी शर्तें खत्म करना

7. हार्डवेयर के साथ काम करने की सुविधा

7.1.4.1 OpenGL ES: सुझाए गए एक्सटेंशन के लिए अपडेट करें.
बदलाव देखें

अगर डिवाइस, OpenGL ES के किसी भी वर्शन के साथ काम करते हैं, तो वे:
- EGL_IMG_context_priority और EGL_EXT_protected_content एक्सटेंशन के साथ काम करना चाहिए.
नई ज़रूरी शर्तें खत्म करना
7.1.4.2 Vulkan: Vulkan के साथ काम करने वाले वर्शन में किए गए अपडेट.
बदलाव देखें

अगर डिवाइस, OpenGL ES 3.1 पर काम करते हैं, तो वे:
- Vulkan 1.3 के लिए, [SR] इस्तेमाल करने का सुझाव दिया जाता है. ~~Vulkan 1.1~~
- ज़रूरी नहीं है कि यह Vulkan वैरिएंट के वर्शन के साथ काम करता हो. इसका मतलब है कि Vulkan के कोर वर्शन का वैरिएंट वाला हिस्सा शून्य होना चाहिए.
अगर लागू किए गए डिवाइस में कोई स्क्रीन या वीडियो आउटपुट शामिल है, तो वे:
- Vulkan 1.3 के लिए, [SR] इस्तेमाल करने का सुझाव दिया जाता है. ~~Vulkan 1.1~~
अगर लागू किए गए डिवाइसों में Vulkan 1.0 या उसके बाद के वर्शन के साथ काम करने की सुविधा शामिल है, तो ये काम किए जा सकते हैं:
- VkPhysicalDeviceProtectedMemoryFeatures और VK_EXT_global_priority के साथ काम करना चाहिए.
- [C-1-12] VK_KHR_performance_query एक्सटेंशन के लिए, सहायता की गिनती नहीं करनी चाहिए.
- [C-SR] को Android बेसलाइन 2021 प्रोफ़ाइल में बताई गई ज़रूरी शर्तों को पूरा करने के लिए इस्तेमाल करने का सुझाव दिया जाता है.
7.2.3 नेविगेशन कुंजियां:
बदलाव देखें

डिवाइस पर यह सुविधा लागू करना:
- [C-SR] का सुझाव दिया जाता है, ताकि नेविगेशन के सभी फ़ंक्शन को रद्द किया जा सके. 'रद्द किया जा सकने वाला' का मतलब है कि उपयोगकर्ता किसी तय सीमा से आगे स्वाइप न करने पर, नेविगेशन फ़ंक्शन को लागू होने से रोक सकता है. जैसे, घर जाना, वापस जाना वगैरह.
नई ज़रूरी शर्तें खत्म करना
अगर वापस जाने का नेविगेशन फ़ंक्शन दिया गया है और उपयोगकर्ता, वापस जाएं वाले जेस्चर को रद्द कर देता है, तो:
- [C-8-1] OnBackInvokedCallback.onBackCancelled() पर कॉल करना ज़रूरी है.
- [C-8-2] OnBackInvokedCallback.onBackInvoked() पर कॉल नहीं किया जाना चाहिए.
- [C-8-3] KEYCODE_BACK इवेंट भेजा नहीं जाना चाहिए.
अगर आपने पिछला नेविगेशन फ़ंक्शन दिया है, लेकिन फ़ोरग्राउंड ऐप्लिकेशन में OnBackInvokedCallback को रजिस्टर नहीं किया गया है, तो:
- सिस्टम को फ़ोरग्राउंड ऐप्लिकेशन के लिए एक ऐनिमेशन देना चाहिए, जिससे यह पता चलता हो कि उपयोगकर्ता वापस जा रहा है, जैसा कि एओएसपी में बताया गया है.
अगर लागू किए गए डिवाइस, सिस्टम एपीआई setNavBarMode पर काम करते हैं, तो android.permission.STATUS_BAR की अनुमति वाले किसी भी सिस्टम ऐप्लिकेशन को नेविगेशन बार मोड सेट करने की अनुमति मिलती है, तो:
- [C-9-1] बच्चों के हिसाब से बने आइकॉन या बटन की मदद से नेविगेट करने की सुविधा देना ज़रूरी है, जैसा कि एओएसपी कोड में बताया गया है.
नई ज़रूरी शर्तें खत्म करना
7.3.1 एक्सलरोमीटर: एक्सलरोमीटर के लिए, सेंसर से जुड़ी ज़रूरी शर्तों के बारे में अपडेट.
बदलाव देखें

अगर लागू किए जाने वाले डिवाइस में एक्सेलरोमीटर ~~3-ऐक्सिस एक्सलरोमीटर~~ शामिल है, तो वे:
- ~~[C-1-2] TYPE_ACCELEROMETER सेंसर को लागू करना और इसकी रिपोर्ट करना ज़रूरी है.~~
- TYPE_SIGNIFICANT_MOTION कंपोज़िट सेंसर को लागू करने के लिए, [SR] का बहुत ज़्यादा सुझाव दिया जाता है.
- [SR] को लागू करने और TYPE_ACCELEROMETER_UNCALIBRATED सेंसर की जानकारी देने के लिए, इसका सुझाव दिया जाता है. इस ज़रूरी शर्त को पूरा करने के लिए, Android डिवाइसों का बहुत ज़्यादा सुझाव दिया जाता है. इसलिए, आने वाले समय में लॉन्च होने वाले प्लैटफ़ॉर्म पर, इन्हें अपग्रेड करना ज़रूरी हो सकता है.
- Android SDK दस्तावेज़ में दी गई जानकारी के हिसाब से, TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER कंपोज़िट सेंसर को लागू करना चाहिए.
अगर डिवाइस लागू करने के तरीके में 3-ऐक्सिस एक्सलरोमीटर शामिल है, तो वे:
- [C-2-1] TYPE_ACCELEROMETER सेंसर को लागू करना और उसकी रिपोर्ट करना ज़रूरी है.
- [सी-एसआर] हमारा सुझाव है कि TYPE_SIGNIFICANT_MOTION कंपोज़िट सेंसर को लागू करें.
- TYPE_ACCELEROMETER_UNCALIBRATED सेंसर को लागू करने और उसकी रिपोर्ट करने के लिए, [C-SR] का इस्तेमाल करने का सुझाव दिया जाता है. इस ज़रूरी शर्त को पूरा करने के लिए, Android डिवाइसों का बहुत ज़्यादा सुझाव दिया जाता है. इससे उन्हें आने वाले समय में लॉन्च होने वाले प्लैटफ़ॉर्म पर अपग्रेड किया जा सकेगा, जहां ऐसा करना ज़रूरी हो सकता है.
- TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER कंपोज़िट सेंसर को लागू करना चाहिए, जैसा कि Android SDK दस्तावेज़ में बताया गया है.
अगर लागू किए जाने वाले डिवाइस में तीन से कम ऐक्सिस वाला एक्सलरोमीटर शामिल है, तो वे:
- [C-3-1] TYPE_ACCELEROMETER_LIMITED_AXES सेंसर को लागू करना और उसकी रिपोर्ट करना ज़रूरी है.
- [C-SR] TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED सेंसर को लागू करने और रिपोर्ट करने के लिए STRONGLY_recommended हैं.
नई ज़रूरी शर्तें खत्म करना
अगर डिवाइस पर लागू होने वाले तीन-ऐक्सिस एक्सलरोमीटर और TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER में से कोई भी कंपोज़िट सेंसर इस्तेमाल किया जाता है, तो:
- [C-4-1] उनकी कुल ऊर्जा की खपत हमेशा 4 mW से कम होनी चाहिए.
अगर डिवाइस में 3-ऐक्सिस एक्सलरोमीटर और 3-ऐक्सिस जाइरोस्कोप सेंसर शामिल है, तो वे:
- [C-5-1] TYPE_GRAVITY और TYPE_LINEAR_ACCELERATION कंपोज़िट सेंसर को लागू करना ज़रूरी है.
अगर डिवाइस में 3-ऐक्सिस एक्सलरोमीटर, 3-ऐक्सिस जाइरोस्कोप सेंसर, और मैगनेटोमीटर सेंसर शामिल होते हैं, तो वे:
- [C-6-1] एक TYPE_ROTATION_VECTOR कंपोज़िट सेंसर लागू करना होगा.
7.3.4 जाइरोस्कोप: जाइरोस्कोप के लिए सेंसर से जुड़ी ज़रूरी शर्तों के बारे में अपडेट.
बदलाव देखें
अगर लागू किए जाने वाले डिवाइसों में जाइरोस्कोप शामिल है, तो:
- [C-1-1] कम से कम 50 हर्ट्ज़ की फ़्रीक्वेंसी तक इवेंट की रिपोर्ट उपलब्ध होनी चाहिए.
- [C-1-4] इसका रिज़ॉल्यूशन 12-बिट या इससे ज़्यादा होना चाहिए.
- [C-1-5] तापमान के लिए मुआवज़ा देना ज़रूरी है.
- [C-1-6] इस्तेमाल करते समय कैलिब्रेट और मुआवज़ा देना ज़रूरी है. साथ ही, डिवाइस को फिर से चालू करने के बीच मुआवज़े के पैरामीटर को बनाए रखें.
- [C-1-7] वैरियंस, हर हर हर्ट्ज़ (वैरियंस प्रति हर्ट्ज़ या रेड^2 / s) से ज़्यादा नहीं होना चाहिए. यह फ़र्क़ 1e-7 radi^2 / s^2 से ज़्यादा नहीं होना चाहिए. सैंपल रेट के हिसाब से, वैरियंस अलग-अलग हो सकता है, लेकिन यह वैल्यू इस वैल्यू के हिसाब से सीमित होनी चाहिए. दूसरे शब्दों में, अगर जाइरो के वैरियंस को एक हर्ट्ज़ की सैंपलिंग रेट पर मापा जाता है, तो यह 1e-7 रेड^2/s^2 से ज़्यादा नहीं होना चाहिए.
- [C-SR] जब डिवाइस सामान्य तापमान पर स्थिर रहता है, तो कैलिब्रेशन की गड़बड़ी 0.01 रेड/से से कम रखने का बहुत ज़्यादा सुझाव दिया जाता है.
- [C-SR] का रिज़ॉल्यूशन 16-बिट या उससे ज़्यादा के लिए इस्तेमाल करने का सुझाव दिया जाता है.
- कम से कम 200 हर्ट्ज़ तक इवेंट रिपोर्ट किए जाने चाहिए.
नई ज़रूरी शर्तें खत्म करना
अगर लागू किए जाने वाले डिवाइसों में 3-ऐक्सिस जाइरोस्कोप शामिल है, तो वे:
- [C-2-1] TYPE_GYROSCOPE सेंसर को लागू करना ज़रूरी है.
अगर लागू किए जाने वाले डिवाइस में तीन से कम ऐक्सिस वाला जाइरोस्कोप शामिल है, तो वे:
- [C-3-1] TYPE_GYROSCOPE_LIMITED_AXES सेंसर को लागू करना और उसकी रिपोर्ट करना ज़रूरी है.
- [C-SR] TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED सेंसर को लागू करने और रिपोर्ट करने के लिए STRONGLY_recommended हैं.
नई ज़रूरी शर्तें खत्म करना
अगर डिवाइस में 3-ऐक्सिस जाइरोस्कोप, एक्सीलरोमीटर सेंसर, और मैगनेटोमीटर सेंसर शामिल हैं, तो वे:
- [C-4-1] एक TYPE_ROTATION_VECTOR कंपोज़िट सेंसर लागू करना होगा.
अगर लागू किए जाने वाले डिवाइस में 3-ऐक्सिस एक्सलरोमीटर और 3-ऐक्सिस जाइरोस्कोप सेंसर शामिल है, तो ये:
- [C-5-1] TYPE_GRAVITY और TYPE_LINEAR_ACCELERATION कंपोज़िट सेंसर को लागू करना ज़रूरी है.
7.3.10 बायोमेट्रिक सेंसर: बायोमेट्रिक सेंसर के लिए, सेंसर से जुड़ी ज़रूरी शर्तों के बारे में अपडेट.
बदलाव देखें

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

अगर डिवाइस लागू करने के तरीके में बायोमेट्रिक सेंसर को क्लास 1 (पहले इसे सुविधा कहा जाता था) के तौर पर इस्तेमाल करना हो, तो वे:
- [C-1-11] स्पूफ़ और इंपोस्टर के स्वीकार किए जाने की दर 30% से ज़्यादा नहीं होनी चाहिए. इसमें (1) लेवल ए प्रज़ेंटेशन अटैक इंस्ट्रुमेंट (पीएआई) की प्रजातियों के लिए स्पूफ़ और इंपोस्टर स्वीकार रेट 30% से ज़्यादा नहीं होना चाहिए. साथ ही, (2) लेवल B PAI की पहचान की दर 40% से ज़्यादा नहीं होनी चाहिए.
नई ज़रूरी शर्तें खत्म करना
अगर डिवाइस लागू करने के तरीके में बायोमेट्रिक सेंसर को क्लास 2 (पहले कमज़ोर कहा जाता था) के तौर पर इस्तेमाल करना हो, तो वे:
- [C-2-2] स्पूफ़ और इंपोस्टर को स्वीकार किए जाने की दर 20% से ज़्यादा नहीं होनी चाहिए. (1) लेवल ए प्रज़ेंटेशन अटैक इंस्ट्रुमेंट (पीएआई) की 20% से ज़्यादा प्रजातियों के लिए स्पूफ़ और इंपोस्टर स्वीकार करने की दर और (2) स्पूफ़ और इंपोस्टर्स स्वीकार करने की दर, लेवल B PAI की वजह से 30% के मुकाबले Android प्रोटोकॉल की तुलना में ज़्यादा है.
अगर डिवाइस लागू करने के तरीके में बायोमेट्रिक सेंसर को क्लास 3 (पहले इसे स्ट्रॉन्ग कहा जाता था) के तौर पर ट्रीट करना हो, तो:
- [C-3-3] स्पूफ़ और इंपोस्टर के स्वीकार करने की दर 7% से ज़्यादा नहीं होनी चाहिए. इसमें (1) लेवल ए प्रेज़ेंटेशन अटैक इंस्ट्रुमेंट (पीएआई) की 7% से ज़्यादा प्रजातियों के लिए स्पूफ़ और इंपोस्टर स्वीकार करने की दर और (2) लेवल बी पीएआई की प्रजातियों के स्पूफ़ और इंपोस्टर को स्वीकार करने की दर Android टेस्ट प्रोटोकॉल की जांच के आंकड़ों के हिसाब से है.
7.3.13 आईईईई 802.1.15.4 (यूडब्ल्यूबी): यूडब्ल्यूबी के लिए ज़रूरी शर्तों का एक नया सेक्शन जोड़ा गया.
बदलाव देखें
7.3.13. आईईईई 802.1.15.4 (यूडब्ल्यूबी)

अगर लागू किए गए डिवाइस पर 802.1.15.4 के लिए सहायता शामिल है और उसके काम करने के तरीके को किसी तीसरे पक्ष के ऐप्लिकेशन के बारे में बताता है, तो वे:
- [C-1-1] इससे जुड़े Android API को android.uwb में लागू करना ज़रूरी है.
- [C-1-2] हार्डवेयर फ़ीचर फ़्लैग android.hardware.uwb की शिकायत करना ज़रूरी है.
- [C-1-3] Android वर्शन को लागू करने के दौरान, काम की सभी यूडब्ल्यूबी प्रोफ़ाइलों का इस्तेमाल किया जाना ज़रूरी है.
- [C-1-4] लोगों को यह सुविधा देनी होगी कि वे यूडब्ल्यूबी रेडियो को चालू/बंद करने की सुविधा को टॉगल कर सकें.
- [C-1-5] यह पक्का करना ज़रूरी है कि यूडब्ल्यूबी रेडियो का इस्तेमाल करने वाले ऐप्लिकेशन, UWB_RANGING अनुमति को (NEARBY_devices अनुमति ग्रुप के तहत) में होल्ड करें.
- [C-1-6] इस बात पर काफ़ी ध्यान दिया जाता है कि FIRA, CCC, और सीएसए जैसे मानक संगठनों की तय की गई शर्तों के पालन और सर्टिफ़िकेट की जांच को पास किया जाए.
नई ज़रूरी शर्तें खत्म करना
7.4.1 टेलीफ़ोनी: जीएसएम और सीडीएमए टेलीफ़ोनी, और मोबाइल नेटवर्क के इस्तेमाल की सेटिंग के लिए, टेलीफ़ोनी की ज़रूरी शर्तों से जुड़े अपडेट.
बदलाव देखें

अगर डिवाइस पर ईयूआईसीसी या ई-सिम/एम्बेड किए गए सिम काम करते हैं और उनमें तीसरे पक्ष के डेवलपर को ई-सिम की सुविधा उपलब्ध कराने के लिए, मालिकाना हक का कोई तरीका शामिल है, तो वे:
- [C-3-1] android.hardware.telephony.euicc सुविधा फ़्लैग के बारे में एलान करना ज़रूरी है.~~EuiccManager API को लागू करने के बारे में पूरी जानकारी दें.~~
अगर डिवाइस लागू करने के लिए GSM या CDMA टेलीफ़ोनी शामिल है, तो:
- [C-6-1] टेक्स्ट मैसेज की सुविधा देने के लिए, SmsManager#sendTextMessage और SmsManager#sendMultipartTextMessage CarrierMessagingService को कॉल करना ज़रूरी है. SmsManager#sendMultimediaMessage और SmsManager#downloadMultimediaMessage मल्टीमीडिया मैसेज की सुविधा देने के लिए, CarrierMessagingService को कॉल करना ज़रूरी है.
- [C-6-2] android.provider.Telephony.Sms#getDefaultSmsPackage की ओर से तय किए गए ऐप्लिकेशन को एसएमएस और मल्टीमीडिया मैसेज (एमएमएस) भेजते और पाते समय SmsManager एपीआई का इस्तेमाल करना होगा. पैकेज/ऐप्लिकेशन/मैसेजिंग में एओएसपी रेफ़रंस लागू करने की सुविधा, इस ज़रूरी शर्त को पूरा करती है.
- [C-6-3] Intent#ACTION_DIAL का जवाब देने वाले ऐप्लिकेशन के लिए, *#*#CODE#*#* फ़ॉर्मैट में आर्बिट्रेरी डायलर कोड डालने की सुविधा होनी ज़रूरी है. साथ ही, उससे जुड़े TelephonyManager#ACTION_SECRET_CODE का ब्रॉडकास्ट भी ट्रिगर होना चाहिए.
- [C-6-4] Intent#ACTION_DIAL का जवाब देने वाले ऐप्लिकेशन को उपयोगकर्ताओं को विज़ुअल वॉइसमेल ट्रांसक्रिप्शन देने के लिए VoicemailContract.Voicemails#TRANSCRIPTION का इस्तेमाल करना होगा. इसके लिए ज़रूरी है कि ऐप्लिकेशन विज़ुअल वॉइसमेल ट्रांसक्रिप्शन की सुविधा देता हो.
- [C-6-5] उपयोगकर्ताओं को दिखने वाली सभी सुविधाओं में, एक ही सदस्यता के तौर पर ग्रुप यूयूआईडी वाली सभी SubscriptionInfo को दिखाना ज़रूरी है. ये सुविधाएं सिम कार्ड की जानकारी दिखाने और कंट्रोल करने में मददगार होती हैं. इस तरह की सुविधाओं के उदाहरणों में, Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS या EuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS से मेल खाने वाले सेटिंग इंटरफ़ेस शामिल हैं.
- [C-6-6] सिम कार्ड की सेटिंग को कॉन्फ़िगर या कंट्रोल करने की अनुमति देने वाली सुविधाओं में, सदस्यता की जानकारी को ऐसे ग्रुप यूयूआईडी और ऑपर्च्यूनिस्टिक बिट के साथ दिखाना या कंट्रोल नहीं करना चाहिए.
अगर डिवाइस पर इस्तेमाल किए जाने वाले डिवाइसों में GSM या CDMA टेलीफ़ोनी शामिल है और सिस्टम स्टेटस बार दिया गया है, तो:
- [C-6-7] उपयोगकर्ता को दिए गए ग्रुप यूयूआईडी के लिए, एक ऐसी ऐक्टिव सदस्यता चुननी होगी जो लोगों को सिम के स्टेटस की जानकारी देने वाली किसी भी कीमत पर दिखा सके. इस तरह की सुविधाओं के उदाहरणों में, स्टेटस बार पर मोबाइल सिग्नल आइकॉन या क्विक सेटिंग टाइल शामिल हैं.
- [C-SR] हमारा सुझाव है कि प्रतिनिधि के तौर पर ली गई सदस्यता को ऐक्टिव डेटा वाली सदस्यता के तौर पर तब तक चुना जाए, जब तक डिवाइस वॉइस कॉल पर न हो. इस दौरान, इस बात पर बहुत ज़्यादा ध्यान दिया जाता है कि प्रतिनिधि वाली सदस्यता, ऐक्टिव वॉइस सदस्यता है.
अगर डिवाइस लागू करने के लिए GSM या CDMA टेलीफ़ोनी शामिल है, तो:
- [C-6-8] यह ज़रूरी है कि वह हर ईटीएसआई टीएस 102 221 के लिए, हर यूआईसीसी के लिए, ज़्यादा से ज़्यादा लॉजिकल चैनलों (कुल 20) को खोल सके और एक साथ इस्तेमाल कर सके.
- [C-6-10] मोबाइल और इंटरनेट सेवा देने वाली चालू कंपनी के ऐप्लिकेशन (जैसा कि TelephonyManager#getCarrierServicePackageName ने तय किया है) पर इनमें से कोई भी व्यवहार अपने-आप या उपयोगकर्ता की पुष्टि के बिना लागू नहीं करना चाहिए:
  
  नेटवर्क ऐक्सेस रद्द करना या उसे सीमित करना
  
  अनुमतियां वापस लें
  
  एओएसपी में शामिल पावर मैनेजमेंट की मौजूदा सुविधाओं के अलावा, बैकग्राउंड या फ़ोरग्राउंड ऐप्लिकेशन को एक्ज़ीक्यूट करने पर पाबंदी लगाएं
  
  ऐप्लिकेशन को बंद या अनइंस्टॉल करें
अगर डिवाइस पर इस्तेमाल किए जाने वाले डिवाइसों में GSM या CDMA टेलीफ़ोनी और सभी चालू, गैर-अवसरवादी सदस्यताओं की सुविधा बंद है, जो ग्रुप के UUID शेयर करती हैं, तो उन्हें डिवाइस से हटा दिया जाता है या अवसर के हिसाब से मार्क किया जाता है. अगर ऐसा किया जाता है, तो डिवाइस:
- [C-7-1] एक ही ग्रुप में बची हुई सभी ऑपर्च्यूनिटी सदस्यताओं को अपने-आप बंद करना ज़रूरी है.
अगर लागू किए जाने वाले डिवाइसों में GSM टेलीफ़ोनी शामिल है, लेकिन CDMA टेलीफ़ोनी नहीं, तो वे:
- [C-8-1] PackageManager#FEATURE_TELEPHONY_CDMA के बारे में एलान नहीं करना चाहिए.
- [C-8-2] किसी भी 3GPP2 नेटवर्क को, पसंदीदा या अनुमति वाले नेटवर्क टाइप बिटमास्क में सेट करने पर, आपको IllegalArgumentException का इस्तेमाल करना होगा.
- [C-8-3] TelephonyManager#getMeid से मिली खाली स्ट्रिंग देनी होगी.
अगर डिवाइस लागू करने के तरीके में एक से ज़्यादा पोर्ट और प्रोफ़ाइल वाले eUICC काम करते हैं, तो ये:
- [C-11-1] android.hardware.telephony.euicc.mep फ़ीचर फ़्लैग का एलान करना ज़रूरी है.
नई ज़रूरी शर्तें खत्म करना
7.4.1.1 नंबर ब्लॉक करने की सुविधा के साथ काम करने की सुविधा: नंबर ब्लॉक करने की ज़रूरी शर्तों के बारे में अपडेट.
बदलाव देखें

अगर लागू करने वाले डिवाइस android.hardware.telephony feature की रिपोर्ट करते हैं, तो वे:
[C-1-4] ब्लॉक किए गए कॉल के लिए, प्लैटफ़ॉर्म कॉल लॉग की सेवा देने वाली कंपनी को जवाब नहीं भेजना चाहिए.
- [C-1-4] ब्लॉक किए गए कॉल के लिए, प्लैटफ़ॉर्म कॉल लॉग की सेवा देने वाली कंपनी को जवाब देना होगा. साथ ही, पहले से इंस्टॉल किए गए डायलर ऐप्लिकेशन में, डिफ़ॉल्ट कॉल लॉग व्यू में से BLOCKED_TYPE का इस्तेमाल करके, कॉल को फ़िल्टर करना ज़रूरी है.
- उपयोगकर्ता को, पहले से इंस्टॉल किए गए डायलर ऐप्लिकेशन में, ब्लॉक किए गए कॉल दिखाने की सुविधा उपलब्ध करानी चाहिए.
नई ज़रूरी शर्तें खत्म करना
7.4.1.3 Cellular NAT-T Keepalive Offload: Cellular के लिए नया सेक्शन NAT-T Keepalive ऑफ़लोड.
बदलाव देखें
7.4.1.3. सेल्युलर NAT-T कीपअलाइव ऑफ़लोड

डिवाइस पर यह सुविधा लागू करना:
- इसमें सेल्युलर कीपअलाइव ऑफ़लोड के लिए सहायता शामिल होनी चाहिए.
अगर डिवाइस पर लागू होने वाले डिवाइस में 'सेल्यूलर कीपअलाइव ऑफ़लोड' सुविधा शामिल है और तीसरे पक्ष के ऐप्लिकेशन के लिए यह सुविधा काम करती है, तो ये:
- [C-1-1] SocketKeepAlive API के साथ काम करना ज़रूरी है.
- [C-1-2] मोबाइल डेटा पर, एक साथ कम से कम एक कीपअलाइव (चालू रखें) स्लॉट का इस्तेमाल करना ज़रूरी है.
- [C-1-3] Cellular Radio HAL के साथ काम करने वाले एक साथ कई सेल्युलर कीपअलाइव स्लॉट की सुविधा ज़रूरी है.
- [सी-एसआर] इस बात का सुझाव दिया जाता है कि हर रेडियो इंस्टेंस के लिए, कम से कम तीन सेल्युलर कीपअलाइव (चालू रखें) वाले स्लॉट हों.
अगर डिवाइस पर लागू करने के तरीके में, सेल्युलर कीपअलाइव ऑफ़लोड के लिए सहायता शामिल नहीं है, तो वे:
- [C-2-1] ERROR_UNSUPPORTED वापस करना होगा.
नई ज़रूरी शर्तें खत्म करना
7.4.2.5 वाई-फ़ाई की जगह की जानकारी (वाई-फ़ाई के ज़रिए आने-जाने का समय - आरटीटी): वाई-फ़ाई की जगह की सटीक जानकारी से जुड़े अपडेट.
बदलाव देखें

अगर डिवाइस पर लागू होने वाले डिवाइस में 'वाई-फ़ाई' की जगह की जानकारी की सुविधा शामिल है और वह तीसरे पक्ष के ऐप्लिकेशन को यह सुविधा देती है, तो वे:
- [C-1-4] 68वें पर्सेंटाइल पर 80 मेगाहर्ट्ज़ बैंडविथ पर 2 मीटर के अंदर सटीक होना चाहिए (ऐसा क्यूमुलेटिव डिस्ट्रिब्यूशन फ़ंक्शन की मदद से किया गया है).
- [C-SR] इस बात की बहुत ज़्यादा सलाह दी जाती है कि 68वें पर्सेंटाइल पर 80 मेगाहर्ट्ज़ बैंडविथ पर 1.5 मीटर के अंदर सटीक तरीके से रिपोर्ट की जाए. इसे कुल डिस्ट्रिब्यूशन फ़ंक्शन की मदद से कैलकुलेट किया जाता है.
नई ज़रूरी शर्तें खत्म करना
7.4.2.6 WiFi कीपअलाइव ऑफ़लोड से जुड़ी शर्तें: सेल्यूलर कीपअलाइव ऑफ़लोड से जुड़ी ज़रूरी शर्तें जोड़ने के लिए अपडेट किया गया.
बदलाव देखें

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

अगर डिवाइस लागू करने की सुविधा, पहली बार इस्तेमाल किए जाने पर भरोसा (टीओएफ़यू) के साथ काम करती है और उपयोगकर्ता को WPA/WPA2/WPA3-एंटरप्राइज़ कॉन्फ़िगरेशन तय करने की अनुमति दी गई है, तो वे:
- [C-4-1] उपयोगकर्ता को TOFU इस्तेमाल करने का विकल्प देना ज़रूरी है.
नई ज़रूरी शर्तें खत्म करना
7.4.3 ब्लूटूथ: ब्लूटूथ से जुड़ी ज़रूरी शर्तों के बारे में अपडेट.
बदलाव देखें

अगर डिवाइस एक्सटेंशन, ब्लूटूथ ऑडियो प्रोफ़ाइल की सुविधा देते हैं, तो वे:
- A2DP की मदद से, बेहतर ऑडियो कोडेक और ब्लूटूथ ऑडियो कोडेक (जैसे, LDAC) काम करने चाहिए.
अगर लागू किए गए डिवाइस पर BluetoothAdapter.isLeAudioSupported() API के लिए true रिस्पॉन्स मिलता है, तो:
- [C-7-1] यूनिकास्ट क्लाइंट के साथ काम करना ज़रूरी है.
- [C-7-2] 2M PHY के साथ काम करना ज़रूरी है.
- [C-7-3] एलई एक्सटेंडेड विज्ञापन के साथ काम करना ज़रूरी है.
- [C-7-4] एक CIG में, कम से कम दो सीआईएस कनेक्शन के साथ काम करना ज़रूरी है.
- [C-7-5] BAP यूनिकास्ट क्लाइंट, सीएसआईपी सेट कोऑर्डिनेटर, एमसीपी सर्वर, वीसीपी कंट्रोलर, सीसीपी सर्वर को एक साथ चालू करना ज़रूरी है.
- HAP यूनिकास्ट क्लाइंट चालू करने के लिए, [सी-एसआर] का खास तौर पर सुझाव दिया जाता है.
अगर लागू किए गए डिवाइस पर BluetoothAdapter.isLeAudioBroadcastSourceSupported() API के लिए true रिस्पॉन्स मिलता है, तो:
- [C-8-1] एक BIG लाइव स्ट्रीम में, कम से कम दो BIS लिंक के साथ काम करना ज़रूरी है.
- [C-8-2] BAP ब्रॉडकास्ट सोर्स और BAP ब्रॉडकास्ट असिस्टेंट को साथ-साथ चालू करना ज़रूरी है.
- [C-8-3] एलई में समय-समय पर विज्ञापन दिखाने की सुविधा होनी चाहिए.
अगर लागू किए गए डिवाइस पर BluetoothAdapter.isLeAudioBroadcastAssistantSupported() API के लिए true रिस्पॉन्स मिलता है, तो:
- [C-9-1] PAST (पीरियॉडिक ऐडवर्टाइज़िंग सिंक ट्रांसफ़र) का इस्तेमाल करना ज़रूरी है.
- [C-9-2] एलई के लिए पीरियॉडिक विज्ञापन के साथ काम करना ज़रूरी है.
अगर लागू किए गए डिवाइस पर FEATURE_BLUETOOTH_LE का एलान किया जाता है, तो:
- [C-10-1] ज़रूरी है कि आरएसएसआई के मेज़रमेंट 95% के अंदर +/-9dB के अंदर हों. ऐसा उन रेफ़रंस डिवाइस से 1 मीटर की दूरी पर होना चाहिए जो आस-पास की जगह पर ADVERTISE_TX_POWER_HIGH से ट्रांसमिट हो रहे हैं.
- [C-10-2] हर चैनल पर होने वाले उतार-चढ़ाव को कम करने के लिए, Rx/Tx सुधार शामिल करना ज़रूरी है. इससे हर ऐंटीना पर, हर ऐंटीना पर (अगर एक से ज़्यादा चैनल का इस्तेमाल किया जा रहा है) हर चैनल का मेज़रमेंट 95% के लिए एक-दूसरे के +/-3dB के अंदर हो.
- [C-SR] Rx ऑफ़सेट को मापने और उसकी भरपाई करने के लिए बहुत ज़्यादा सुझाव दिया जाता है. इससे यह पक्का किया जा सकता है कि ADVERTISE_TX_POWER_HIGH से ट्रांसमिट होने वाले रेफ़रंस डिवाइस से 1 मिनट की दूरी पर BLE आरएसएसआई का मीडियन -60dBm +/-10 dB है. यहां डिवाइस इस तरह से डाले गए हैं कि वे 'पैरलल प्लेन' पर हों और उनकी स्क्रीन एक ही दिशा में हो.
- [सी-एसआर] इस बात का काफ़ी सुझाव दिया जाता है कि Tx ऑफ़सेट को मापा और उसकी भरपाई की जाए. इससे यह पक्का किया जा सकेगा कि 1 मीटर की दूरी पर मौजूद रेफ़रंस डिवाइस से स्कैन करते समय और ADVERTISE_TX_POWER_HIGH पर ट्रांसमिट करते समय, आरएसएसआई का मीडियन -60dBm +/-10 dB हो. ऐसा तब होता है, जब डिवाइस इस तरह हों कि वे एक ही दिशा में स्क्रीन की दिशा में हों.
हमारा सुझाव है कि मौजूदगी को कैलिब्रेट करने की ज़रूरी शर्तों में बताए गए, मेज़रमेंट सेटअप के तरीकों का पालन करें.

अगर डिवाइस, ब्लूटूथ वर्शन 5.0 के साथ काम करते हैं, तो वे:
- [C-SR] के लिए सहायता देने का सुझाव दिया जाता है:
  
  एल 2एम फ़ी
  
  एलई कोडेक पीएचवाई
  
  LE विज्ञापन एक्सटेंशन
  
  समय-समय पर दिखने वाले विज्ञापन
  
  विज्ञापन के कम से कम 10 सेट हों
  
  कम से कम 8 LE एक साथ कई कनेक्शन होने चाहिए. हर कनेक्शन, किसी भी कनेक्शन टोपोलॉजी रोल में हो सकता है.
  
  एलई लिंक लेयर की निजता
  
  "समस्या हल करने वाली सूची" में कम से कम आठ एंट्री होनी चाहिए
नई ज़रूरी शर्तें खत्म करना
7.4.9 यूडब्ल्यूबी: यूडब्ल्यूबी हार्डवेयर के लिए ज़रूरी शर्तों वाला सेक्शन जोड़ा गया.
बदलाव देखें
7.4.9. यूडब्ल्यूबी

अगर डिवाइस, android.content.pm.PackageManager क्लास के ज़रिए सुविधा android.hardware.uwb के लिए रिपोर्ट सपोर्ट करता है, तो ये:
- [C-1-1] यह पक्का करना ज़रूरी है कि दूरी की माप, 95% के बीच की दूरी पर +/-15 सें॰मी॰ के बीच हो. यह दूरी, नॉन-रिफ़्लेक्टिव चैंबर में 1 मीटर की दूरी पर होती है.
- [C-1-2] यह पक्का करना ज़रूरी है कि रेफ़रंस डिवाइस से 1 मीटर की दूरी का मीडियन [0.75 मीटर, 1.25 मीटर] के अंदर हो. यहां ज़मीन की सच्चाई का पता, डीयूटी के ऊपरी किनारे से ऊपर और झुकाकर रखा जाता है.
मौजूदगी को कैलिब्रेट करने की ज़रूरी शर्तों में बताए गए, मेज़रमेंट सेटअप के तरीकों का पालन करने पर ज़ोर दिया जाता है.

नई ज़रूरी शर्तें खत्म करना
7.5 कैमरे: एचडीआर 10-बिट आउटपुट की क्षमता से जुड़ी ज़रूरी शर्तों से जुड़े अपडेट.
बदलाव देखें
अगर डिवाइस में एचडीआर 10-बिट आउटपुट देने की सुविधा काम करती है, तो ये काम करते हैं:
- [C-2-1] 10-बिट आउटपुट की सुविधा वाले हर कैमरा डिवाइस के लिए, कम से कम एचएलजी एचडीआर प्रोफ़ाइल काम करनी चाहिए.
- [C-2-2] 10-बिट आउटपुट की सुविधा, मुख्य पीछे वाले कैमरे या सामने वाले मुख्य कैमरे के साथ काम कर सकती है.
- [C-SR] दोनों ही प्राथमिक कैमरों के लिए 10-बिट आउटपुट का समर्थन करने के लिए कड़ाई जाती है.
- [C-2-3] लॉजिकल कैमरे के सभी BACKWARD_COMPATIBLE वाले फ़िज़िकल सब-कैमरा और लॉजिकल कैमरे के लिए, एक जैसी एचडीआर प्रोफ़ाइल इस्तेमाल की जानी चाहिए.
10-बिट एचडीआर के साथ काम करने वाले लॉजिकल कैमरा डिवाइसों के लिए, जो android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO एपीआई को लागू करते हैं वे:
- [C-3-1] लॉजिकल कैमरे पर CONTROL_ZOOM_RATIO कंट्रोल की मदद से, पीछे की ओर काम करने वाले सभी फ़िज़िकल कैमरों के बीच स्विच करने की सुविधा होनी चाहिए.
नई ज़रूरी शर्तें खत्म करना
7.7.2 यूएसबी होस्ट मोड: ड्यूअल रोल पोर्ट के लिए बदलाव.
बदलाव देखें

अगर डिवाइस इंप्लिमेंटेशन में होस्ट मोड और यूएसबी टाइप-सी के साथ काम करने वाला यूएसबी पोर्ट शामिल है, तो वे:
- [C-4-1] 'ड्यूअल रोल पोर्ट' फ़ंक्शन को लागू करना ज़रूरी है, जैसा कि यूएसबी टाइप-सी स्पेसिफ़िकेशन (सेक्शन 4.5.1.3.3) में बताया गया है. ड्यूअल रोल पोर्ट के लिए, 3.5 मि॰मी॰ का ऑडियो जैक वाले डिवाइसों पर, यूएसबी सिंक की पहचान करने वाला (होस्ट मोड) डिफ़ॉल्ट रूप से बंद हो सकता है. हालांकि, लोगों के लिए इसे चालू करना मुमकिन होना ज़रूरी है.
7.11 मीडिया परफ़ॉर्मेंस क्लास: Android T को शामिल करने के लिए अपडेट किया गया.
बदलाव देखें

अगर लागू किए गए डिवाइस पर, android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS के लिए कोई वैल्यू नहीं दिखती है, तो ये:
- [C-1-3] "मीडिया परफ़ॉर्मेंस क्लास" की सभी ज़रूरी शर्तें पूरी करना ज़रूरी है. इन शर्तों के बारे में सेक्शन 2.2.7 में बताया गया है.
दूसरे शब्दों में कहें, तो Android T में मीडिया परफ़ॉर्मेंस क्लास को सिर्फ़ हैंडहेल्ड डिवाइसों पर T, S या R वर्शन के लिए तय किया जाता है.

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

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

9.1 अनुमतियां: पहले से इंस्टॉल किए गए ऐप्लिकेशन के लिए, अनुमतियों की अनुमति वाली सूची के लिए स्वीकार किए गए पाथ को APEX फ़ाइलों तक बढ़ाएं.
बदलाव देखें
- [C-0-2] PROTECTION_FLAG_PRIVILEGED के protectionLevel वाली अनुमतियां सिर्फ़ उन ऐप्लिकेशन को दी जानी चाहिए जो सिस्टम इमेज (साथ ही APEX फ़ाइलें) के खास पाथ(पाथों) में पहले से इंस्टॉल किए गए हों. साथ ही, ये अनुमतियां हर ऐप्लिकेशन के लिए अनुमति वाली अनुमतियों के सबसेट में भी होनी चाहिए. एओएसपी को लागू करने के लिए, इस ज़रूरी शर्त को पूरा करना होता है.etc/permissions/system/priv-app
9.7 सुरक्षा से जुड़ी सुविधाएं: कर्नेल का रखरखाव बनाए रखने के लिए, शुरू करने की ज़रूरी शर्तों में बदलाव किए गए हैं.
बदलाव देखें

Kernel इंटिग्रिटी और खुद की सुरक्षा से जुड़ी सुविधाएं, Android की सुरक्षा का ज़रूरी हिस्सा हैं. डिवाइस पर यह सुविधा लागू करना:
- [C-SR] का सुझाव दिया जाता है कि कर्नेल में स्टैक शुरू करने की सुविधा चालू की जाए, ताकि शुरू नहीं किए गए लोकल वैरिएबल (CONFIG_INIT_STACK_ALL या CONFIG_INIT_STACK_ALL_ZERO) के इस्तेमाल को रोका जा सके. साथ ही, डिवाइस को लागू करने के लिए कंपाइलर की ओर से लोकल वैरिएबल को शुरू करने के लिए इस्तेमाल की गई वैल्यू को नहीं माना जाना चाहिए.
नई ज़रूरी शर्तें खत्म करना
9.8.7 निजता — क्लिपबोर्ड का ऐक्सेस: उपयोगकर्ता की निजता को सुरक्षित रखने के लिए, काटे/कॉपी/पेस्ट करने के 60 मिनट बाद, क्लिपबोर्ड का डेटा अपने-आप मिट जाए.
बदलाव देखें

डिवाइस पर यह सुविधा लागू करना:
- [C-0-1] क्लिपबोर्ड से क्लिप किया गया डेटा नहीं दिखाना चाहिए (जैसे, ClipboardManager एपीआई की मदद से) जब तक कि तीसरे पक्ष का ऐप्लिकेशन, डिफ़ॉल्ट IME न हो या फ़िलहाल ऐसा ऐप्लिकेशन हो जिस पर फ़ोकस मौजूद है.
- [C-0-2] क्लिपबोर्ड पर मौजूद डेटा को क्लिपबोर्ड पर रखने या क्लिपबोर्ड से पढ़ने के ज़्यादा से ज़्यादा 60 मिनट बाद मिटाना ज़रूरी है.
9.11 कुंजियां और क्रेडेंशियल: सुरक्षित लॉक स्क्रीन से जुड़ी ज़रूरी शर्तों के बारे में अपडेट. इनमें क्रिप्टो एल्गोरिदम में ईसीडीएच और 3DES को जोड़ना भी शामिल है.
बदलाव देखें

जब डिवाइस पर लागू होने वाला सुरक्षित लॉक स्क्रीन काम करती है, तो यह काम करता है:
- [C-1-2] आरएसए, एईएस, ईसीडीएसए, ECDH (अगर IKeyMintDevice काम करता है), 3DES, और HMAC क्रिप्टोग्राफ़िक एल्गोरिदम और MD5, SHA1, और SHA-2 फ़ैमिली हैश फ़ंक्शन लागू करने चाहिए, ताकि Android कीस्टोर सिस्टम के साथ काम करने वाले एल्गोरिदम के लिए, उस एरिया में सही तरीके से काम किया जा सके जिसे कर्नेल के ऊपर और ऊपर चल रहे कोड से सुरक्षित तरीके से अलग किया गया है. सिक्योर आइसोलेशन से उन सभी संभावित मैकेनिज़्म को ब्लॉक कर देना चाहिए जिनकी मदद से कर्नेल या यूज़रस्पेस कोड, डीएमए के साथ-साथ आइसोलेटेड एनवायरमेंट की अंदरूनी स्थिति को ऐक्सेस कर सकते हैं. अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट (एओएसपी), Trusty लागू करने की सुविधा का इस्तेमाल करके इस ज़रूरी शर्त को पूरा करता है. हालांकि, ARM TrustZone पर आधारित कोई दूसरा समाधान या Hypervisor-आधारित आइसोलेशन के लिए, तीसरे पक्ष की ओर से समीक्षा किए गए सुरक्षित इंप्लिमेंटेशन के विकल्प, विकल्प हैं.
9.11.1 सुरक्षित लॉक स्क्रीन, पुष्टि, और वर्चुअल डिवाइस: वर्चुअल डिवाइसों और पुष्टि करने की प्रक्रिया को ट्रांसफ़र करने के लिए, ज़रूरी शर्तों वाला सेक्शन जोड़ा गया.
बदलाव देखें

अगर डिवाइस लॉक स्क्रीन को अनलॉक करने के लिए पुष्टि करने के तरीकों को जोड़ते हैं या उनमें बदलाव करते हैं और पुष्टि करने का नया तरीका किसी फ़िज़िकल टोकन या जगह के हिसाब से होता है, तो:
- [C-6-3] उपयोगकर्ता को हर चार घंटे में कम से कम एक बार, पुष्टि करने के सुझाए गए मुख्य तरीकों (जैसे, पिन, पैटर्न, पासवर्ड) में से किसी एक को अपनाना होगा. जब कोई फ़िज़िकल टोकन, C-X में TrustAgent लागू करने की ज़रूरी शर्तों को पूरा करता है, तो C-9-5 में बताई गई टाइम आउट से जुड़ी पाबंदियां लागू होती हैं.
अगर लागू किए गए डिवाइस पर, ऐप्लिकेशन को सेकंडरी वर्चुअल डिसप्ले बनाने की अनुमति मिलती है और उनसे जुड़े इनपुट इवेंट, जैसे कि VirtualDeviceManager के ज़रिए काम नहीं करते, तो वे:
- [C-9-1] डिवाइस का डिफ़ॉल्ट डिसप्ले लॉक होने पर, आपको इन सेकंडरी वर्चुअल डिसप्ले को लॉक करना होगा. साथ ही, डिवाइस का डिफ़ॉल्ट डिसप्ले अनलॉक होने पर, इन सेकंडरी वर्चुअल डिसप्ले को भी अनलॉक करना होगा.
अगर लागू किए गए डिवाइस पर, ऐप्लिकेशन को सेकंडरी वर्चुअल डिसप्ले बनाने और उनसे जुड़े इनपुट इवेंट, जैसे कि वर्चुअलडिवाइस मैनेजर की सुविधा इस्तेमाल करने में मदद मिलती है, तो वे:
- [C-10-1] हर वर्चुअल डिवाइस के लिए, अलग-अलग लॉक स्टेटस का इस्तेमाल करना ज़रूरी है
- [C-10-2] इस्तेमाल न होने पर टाइम आउट होने पर, सभी वर्चुअल डिवाइसों को डिसकनेक्ट करना ज़रूरी है
- [C-10-3] एक टाइम आउट होना ज़रूरी है
- [C-10-4] उपयोगकर्ता के लॉकडाउन शुरू करने पर, सभी स्क्रीन को लॉक करना ज़रूरी है. इसमें लॉकडाउन के तहत, हैंडहेल्ड डिवाइस इस्तेमाल करने के लिए ज़रूरी कीमत भी शामिल है (सेक्शन 2.2.5[9.11/H-1-2] देखें)
- [C-10-5] हर उपयोगकर्ता के लिए, वर्चुअल डिवाइस का अलग-अलग इंस्टेंस होना ज़रूरी है
- [C-10-6] DevicePolicyManager.setNearbyAppStreamingPolicy से संकेत मिलने पर, VirtualDeviceManager के ज़रिए इससे जुड़े इनपुट इवेंट बनाने की सुविधा बंद करनी होगी
- [C-10-7] हर वर्चुअल डिवाइस के लिए, सिर्फ़ एक अलग क्लिपबोर्ड का इस्तेमाल करना होगा या वर्चुअल डिवाइसों के लिए क्लिपबोर्ड को बंद करना होगा
- [C-10-11] वर्चुअल डिवाइसों पर पुष्टि करने वाले यूज़र इंटरफ़ेस (यूआई) को बंद करना ज़रूरी है. इसमें नॉलेज फ़ैक्टर एंट्री और बायोमेट्रिक प्रॉम्प्ट शामिल हैं
- [C-10-12] किसी वर्चुअल डिवाइस से शुरू किए गए इंटेंट को सिर्फ़ उसी वर्चुअल डिवाइस पर दिखाने के लिए प्रतिबंधित करना ज़रूरी है
- [C-10-13] Android कीस्टोर सिस्टम से उपयोगकर्ता की पुष्टि करने की अनुमति के तौर पर, वर्चुअल डिवाइस लॉक की स्थिति का इस्तेमाल नहीं करना चाहिए. KeyGenParameterSpec.Builder.setUserAuthentication* देखें.
जब डिवाइस लागू करने की प्रोसेस से, उपयोगकर्ता को सोर्स डिवाइस से टारगेट किए गए डिवाइस पर पुष्टि करने से जुड़ी मुख्य जानकारी को ट्रांसफ़र किया जाता है, तो वे:
- [C-11-1] आपको सोर्स डिवाइस से टारगेट किए गए डिवाइस पर नॉलेज-फ़ैक्टर का इस्तेमाल करते समय, सुरक्षा की गारंटी वाली जानकारी को एन्क्रिप्ट (सुरक्षित) करना चाहिए. यह जानकारी, Google Cloud Key Vault सेवा के सुरक्षा व्हाइट पेपर में दी गई जानकारी से मिलती-जुलती है.
- [C-11-2] टारगेट डिवाइस पर नॉलेज-फ़ैक्टर ट्रांसफ़र करने से पहले, उपयोगकर्ता से सोर्स डिवाइस के नॉलेज-फ़ैक्टर की पुष्टि करने के लिए कहें.
- [C-11-3] अगर टारगेट किए गए किसी डिवाइस पर, पुष्टि करने का कोई मुख्य तरीका नहीं है, तो उपयोगकर्ता को उस डिवाइस पर ट्रांसफ़र किए गए नॉलेज-फ़ैक्टर की पुष्टि करने के लिए कहें. इसके बाद ही, टारगेट डिवाइस के लिए, नॉलेज-फ़ैक्टर को मुख्य डिवाइस के तौर पर सेट करना होगा. साथ ही, सोर्स डिवाइस से ट्रांसफ़र किया गया कोई भी डेटा उपलब्ध कराना होगा.
अगर लागू किए गए डिवाइस में सुरक्षित लॉक स्क्रीन होती है और उसमें एक या एक से ज़्यादा ट्रस्ट एजेंट शामिल होते हैं, जो TrustAgentService.grantTrust() System API को FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE फ़्लैग के साथ कॉल करते हैं, तो:
- [C-12-1] फ़्लैग वाले grantTrust() को सिर्फ़ तब कॉल करना ज़रूरी है, जब वह किसी नज़दीकी डिवाइस की लॉकस्क्रीन से कनेक्ट हो. साथ ही, जब उपयोगकर्ता ने लॉकस्क्रीन पर अपनी पहचान की पुष्टि की हो. उपयोगकर्ता की पुष्टि करने से जुड़ी ज़रूरी शर्तों को पूरा करने के लिए, एक बार इस्तेमाल करने वाले व्यक्ति के अनलॉक करने के बाद, आस-पास मौजूद डिवाइस स्मार्टवॉच से या शरीर पर पहनने की पहचान करने के तरीकों का इस्तेमाल कर सकते हैं.
- [C-12-2] स्क्रीन बंद होने पर (जैसे, बटन दबाने पर या डिसप्ले का समय खत्म होने पर) डिवाइस को लागू करने की प्रोसेस को TrustState.TRUSTABLE वाले स्टेटस में डालना ज़रूरी है और TrustAgent ने भरोसे को वापस नहीं लिया है. एओएसपी इस ज़रूरी शर्त को पूरा करता है.
- [C-12-3] डिवाइस को TrustState.TRUSTABLE से TrustState.TRUSTED वाली स्थिति में सिर्फ़ तब ले जाना चाहिए, जब TrustAgent अब भी C-12-1 में दी गई ज़रूरी शर्तों के हिसाब से भरोसा दे रहा है.
- [C-12-4] भरोसा देने के ज़्यादा से ज़्यादा 24 घंटों, 8 घंटे तक इस्तेमाल न होने वाली विंडो या आस-पास मौजूद फ़िज़िकल डिवाइस से कनेक्शन टूट जाने पर, TrustManagerService.revokeTrust() को कॉल करना ज़रूरी है.
अगर डिवाइस लागू करने की सुविधा से, ऐप्लिकेशन को सेकंडरी वर्चुअल डिसप्ले बनाने और उनसे जुड़े इनपुट इवेंट, जैसे कि virtualDeviceManager की मदद से काम करने में मदद मिलती है और डिसप्ले VIRTUAL_DISPLAY_FLAG_SECURE से मार्क नहीं किए गए हैं, तो वे:
- [C-13-8] ज़रूरी है कि android:canDisplayOnRemoteDevices या मेटा-data android.activity.can_display_on_remote_devices की मदद से शुरू होने वाली वर्चुअल डिवाइस पर गलत पर सेट होने वाली गतिविधियों को ब्लॉक करें.
- [C-13-9] ऐसी गतिविधियों को ब्लॉक करना ज़रूरी है जो साफ़ तौर पर स्ट्रीमिंग की सुविधा चालू न करती हों. साथ ही, इनसे यह भी पता चलता हो कि वे वर्चुअल डिवाइस पर SurfaceView#setSecure, FLAG_SECURE, या system_FLAG_HIDE_NON_system_OVERLAY_WINDOWS के ज़रिए चालू होती हैं.
- [C-13-10] वर्चुअल डिवाइसों से शुरू किए गए ऐप्लिकेशन को इंस्टॉल करने की सुविधा बंद करनी होगी.
नई ज़रूरी शर्तें खत्म करना
9.11.2 Strongbox: इनसाइडर अटैक रेज़िस्टेंस (IAR) को एक ज़रूरी शर्त बनाना.
बदलाव देखें

इस बात की पुष्टि करने के लिए कि [C-1-3] से [C-1-9] तक का पालन किया गया है या नहीं, डिवाइस पर ये सुविधाएं लागू की जाती हैं:
- [C-SR] का इनसाइडर अटैक रेज़िस्टेंस (आईएआर) देने के लिए बहुत ज़्यादा सुझाव दिया जाता है. इसका मतलब है कि फ़र्मवेयर साइनिंग कुंजियों का ऐक्सेस रखने वाला इनसाइडर, ऐसा फ़र्मवेयर नहीं बना सकता जिसकी वजह से StrongBox, सुरक्षा से जुड़ी ज़रूरी शर्तों को बायपास कर सके या उपयोगकर्ताओं के संवेदनशील डेटा का ऐक्सेस दे सके. आईएआर लागू करने का सुझाया गया तरीका, फ़र्मवेयर अपडेट की अनुमति सिर्फ़ तब देना है, जब मुख्य उपयोगकर्ता पासवर्ड IAuthSecret HAL के ज़रिए दिया गया हो. Android 14 में, आईएआर को जोड़ना ज़रूरी होगा.
9.11.3 पहचान क्रेडेंशियल: पहचान क्रेडेंशियल सिस्टम के रेफ़रंस को लागू करने के बारे में जानकारी जोड़ी गई.

बदलाव देखें

android.security.identity.* पैकेज में मौजूद सभी एपीआई लागू करके, पहचान क्रेडेंशियल सिस्टम को तय किया जाता है और हासिल किया जाता है. इन एपीआई की मदद से ऐप्लिकेशन डेवलपर, उपयोगकर्ता की पहचान से जुड़े दस्तावेज़ों को सेव और वापस पा सकते हैं. डिवाइस पर यह सुविधा लागू करना:

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

नई ज़रूरी शर्तें खत्म करना
9.11.4 आईडी को प्रमाणित करने की सुविधा: आईडी को प्रमाणित करने से जुड़ी ज़रूरी शर्तों के लिए, एक सेक्शन जोड़ा गया.

बदलाव देखें

9.11.4. आईडी को प्रमाणित करना

डिवाइस पर आईडी की पुष्टि करने की सुविधा काम करनी चाहिए.

नई ज़रूरी शर्तें खत्म करना
9.17 Android वर्चुअलाइज़ेशन फ़्रेमवर्क: Android वर्चुअलाइज़ेशन फ़्रेमवर्क के लिए ज़रूरी शर्तों वाला सेक्शन जोड़ा गया.
बदलाव देखें
9.17. Android वर्चुअलाइज़ेशन फ़्रेमवर्क

अगर डिवाइस, Android वर्चुअलाइज़ेशन फ़्रेमवर्क एपीआई (android.system.virtualmachine.*) के साथ काम करता है, तो Android होस्ट:
- [C-1-1] android.system.virtualmachine.* पैकेज में बताए गए सभी एपीआई के साथ काम करना ज़रूरी है.
- [C-1-2] Protected Virtual Machines को मैनेज करने के लिए, Android SELinux और अनुमति के मॉडल में बदलाव नहीं करना होगा.
- [C-1-3] अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट (एओएसपी) में दिए गए सिस्टम/सेवा नीति में मौजूद नियमों में बदलाव नहीं करना, उन्हें छोड़ना या बदलना नहीं चाहिए और इस नीति को कभी भी लागू न होने वाले सभी नियमों के साथ कंपाइल करना ज़रूरी है.
- [C-1-4] सुरक्षित वर्चुअल मशीन बनाने और चलाने के लिए, गैर-भरोसेमंद कोड (जैसे कि 3p ऐप्लिकेशन) को अनुमति नहीं देनी चाहिए. ध्यान दें: यह विकल्प, आने वाले Android रिलीज़ में बदल सकता है.
- [C-1-5] सुरक्षित वर्चुअल मशीन को ऐसे कोड चलाने की अनुमति नहीं देनी चाहिए जो फ़ैक्ट्री इमेज या उनके अपडेट का हिस्सा न हो. ऐसी सभी चीज़ें जो Android वेरिफ़ाइड बूट के तहत नहीं आती हैं (जैसे कि इंटरनेट से डाउनलोड की गई फ़ाइलें या अलग से लोड की गई फ़ाइलें), उन्हें Protected Virtual Machine में चलाने की अनुमति नहीं है.
अगर डिवाइस, Android वर्चुअलाइज़ेशन फ़्रेमवर्क एपीआई (android.system.virtualmachine.*) के साथ काम करता है, तो कोई भी Protected Virtual Machine इंस्टेंस:
- [C-2-1] यह ज़रूरी है कि यह सुरक्षित वर्चुअल मशीन में वर्चुअलाइज़ेशन APEX में उपलब्ध सभी ऑपरेटिंग सिस्टम चला सके.
- [C-2-2] किसी सुरक्षित वर्चुअल मशीन को ऐसा ऑपरेटिंग सिस्टम चलाने की अनुमति नहीं देनी चाहिए जिस पर डिवाइस लागू करने वाले या ओएस वेंडर ने हस्ताक्षर न किया हो.
- [C-2-3] Protected Virtual Machine को डेटा के तौर पर डेटा इस्तेमाल करने की अनुमति नहीं देनी चाहिए (उदाहरण के लिए, SELinux कभी भी execmem की अनुमति नहीं देता).
- [C-2-4] अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट (एओएसपी) में दिए गए सिस्टम/sepolicy/माइक्रोड्रॉइड में मौजूद नियमों में बदलाव नहीं करना चाहिए, उन्हें छोड़ना या बदलना नहीं चाहिए.
- [C-2-5] आपको सुरक्षित वर्चुअल मशीन की सुरक्षा के लिए बेहतर मैकेनिज़्म लागू करना होगा (जैसे, pVM के लिए SELinux) यहां तक कि नॉन-माइक्रोड्रॉइड ऑपरेटिंग सिस्टम के लिए भी.
- [C-2-6] यह पक्का करना ज़रूरी है कि अगर pVM फ़र्मवेयर शुरुआती इमेज की पुष्टि नहीं कर पाता है, तो वह बूट नहीं होगा.
- [C-2-7] यह पक्का करना ज़रूरी है कि example.img की इंटिग्रिटी के साथ छेड़छाड़ होने पर, pVM फ़र्मवेयर को बूट होने से मना कर दिया जाए.
अगर डिवाइस, Android वर्चुअलाइज़ेशन फ़्रेमवर्क एपीआई (android.system.virtualmachine.*) के साथ काम करता है, तो हाइपरवाइज़र:
- [C-3-1] किसी भी पीवीएम को किसी दूसरी इकाई (जैसे, कोई दूसरा पीवीएम या हायपरवाइज़र) पेज का ऐक्सेस तब तक नहीं देना चाहिए, जब तक कि पेज के मालिक ने इसे साफ़ तौर पर शेयर न किया हो. इसमें होस्ट वीएम शामिल है. यह सीपीयू और डीएमए, दोनों ऐक्सेस पर लागू होता है.
- [C-3-2] किसी पेज को वीएम के इस्तेमाल के बाद और होस्ट पर वापस भेजने से पहले, उस पेज को वाइप करना ज़रूरी है. जैसे, पीवीएम को बंद किया जाना.
- [C-3-3] यह पक्का करना ज़रूरी है कि पीवीएम में किसी भी कोड से पहले, पीवीएम फ़र्मवेयर लोड हो गया हो और उसे एक्ज़ीक्यूट किया जा चुका हो.
- [C-3-4] यह पक्का करना ज़रूरी है कि किसी pVM इंस्टेंस को दिए गए गुप्त कॉपी और सीडीआई के बारे में सिर्फ़ उसी इंस्टेंस से लिया गया हो.
अगर डिवाइस, Android वर्चुअलाइज़ेशन फ़्रेमवर्क के एपीआई के साथ काम करता है, तो इन सभी कामों के लिए:
- [C-4-1] ऐसी पीवीएम को फ़ंक्शन नहीं देना चाहिए जो Android सिक्योरिटी मॉडल को बायपास करने की अनुमति देता हो.
अगर डिवाइस, Android वर्चुअलाइज़ेशन फ़्रेमवर्क एपीआई के साथ काम करता है, तो:
- [C-5-1] एआरटी रनटाइम अपडेट के आइसोलेटेड कंपाइलेशन के साथ काम करना ज़रूरी है.
अगर डिवाइस, Android वर्चुअलाइज़ेशन फ़्रेमवर्क एपीआई के साथ काम करता है, तो क्रिप्टोग्राफ़िक कुंजी के मैनेजमेंट के लिए:
- [C-6-1] DICE की चेन को इस तरह रूट करना चाहिए कि लोग उसमें बदलाव न कर सकें. भले ही, डिवाइस अनलॉक न हों. (यह पक्का करने के लिए कि इसका इस्तेमाल नहीं किया जा सकता).
- [C-6-2] DICE को सही तरीके से इस्तेमाल करना ज़रूरी है. इसका मतलब है कि प्रॉडक्ट के लिए सही वैल्यू सबमिट करें. हालांकि, हो सकता है कि ऐसी जानकारी देने की ज़रूरत न हो.
नई ज़रूरी शर्तें खत्म करना

13। हमसे संपर्क करें

android के साथ काम करने वाले फ़ोरम में शामिल होकर, उनके बारे में साफ़ तौर पर जानकारी मांगी जा सकती है. इसके अलावा, अगर आपको लगता है कि इस दस्तावेज़ में कोई समस्या नहीं है, तो उनके बारे में भी बात की जा सकती है.