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

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

1. परिचय

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

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

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

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

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

इसी वजह से, Android Open Source Project 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 टैबलेट को लागू करना
शर्त ID
- जब कोई शर्त पूरी नहीं होती, तब इस आईडी की वैल्यू 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 इंच (या डिवाइस को लागू करने के लिए 2.5 इंच जो एपीआई लेवल 29 पर शिप किया गया हो या 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.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] ज़रूरी वैल्यू की रिपोर्ट करना ज़रूरी है के लिए, डिवाइस के जीपीयू काउंटर के लिए जीपीयू काउंटर ट्रेस पैकेट प्रोटो.
[7.1.4.6/H-1-3] ज़रूरी वैल्यू की रिपोर्ट देना ज़रूरी है के बाद से, रेंडर स्टेज ट्रेस पैकेट प्रोटो.
[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 या ACTION_ASSIST को मैनेज करने वाली कोई गतिविधि है KEYCODE_MEDIA_PLAY_PAUSE को देर तक दबाए रखने पर या KEYCODE_HEADSETHOOK अगर फ़ोरग्राउंड गतिविधि से, उन इवेंट को हैंडल नहीं किया जा सकता जिन्हें दबाकर रखा गया हो.
[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] GNSS मेज़रमेंट को तुरंत रिपोर्ट करना ज़रूरी है मिल जाते हैं, भले ही GPS/GNSS से मिली किसी जगह की जानकारी अभी तक रिपोर्ट न की गई हो.
[7.3.3/H-2-2] जीएनएसएस स्यूडोरेंज और स्यूडोरेंज की रिपोर्ट करना ज़रूरी है स्थान का निर्धारण करने के बाद खुले आसमान की स्थितियों में, जबकि स्थिर या 0.2 मीटर प्रति सेकंड के वर्ग से कम के साथ मूविंग त्वरण, 20 मीटर के अंदर स्थिति की गणना करने के लिए पर्याप्त है और 0.2 मीटर प्रति सेकंड के अंदर, कम से कम 95% समय में.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[7.6.1/H-1-1] कर्नेल के लिए उपलब्ध मेमोरी और अगर डिफ़ॉल्ट डिसप्ले में फ़्रेमबफ़र का इस्तेमाल किया जाता है, तो यूज़रस्पेस कम से कम 416 एमबी होना चाहिए qHD तक के रिज़ॉल्यूशन (जैसे कि FWVGA).
[7.6.1/H-2-1] कर्नेल के लिए उपलब्ध मेमोरी और अगर डिफ़ॉल्ट डिसप्ले में फ़्रेमबफ़र का इस्तेमाल किया जाता है, तो यूज़रस्पेस कम से कम 592 एमबी होना चाहिए HD+ तक के रिज़ॉल्यूशन (जैसे कि HD, WSVGA).
[7.6.1/H-3-1] कर्नेल के लिए उपलब्ध मेमोरी और अगर डिफ़ॉल्ट डिसप्ले में फ़्रेमबफ़र का इस्तेमाल किया जाता है, तो यूज़रस्पेस कम से कम 896 एमबी होना चाहिए एफ़एचडी तक के रिज़ॉल्यूशन (उदाहरण के लिए, WSXGA+).
[7.6.1/H-4-1] कर्नेल के लिए उपलब्ध मेमोरी और अगर डिफ़ॉल्ट डिसप्ले का इस्तेमाल करता है, तो यूज़रस्पेस कम से कम 1344 एमबी होना चाहिए क्वाड हाई डेफ़िनिशन (क्यूएचडी) तक के फ़्रेम बफ़र रिज़ॉल्यूशन (उदाहरण के लिए, QWXGA).

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

[7.6.1/H-5-1] कर्नेल के लिए उपलब्ध मेमोरी और उपयोगकर्ता के पास होना ज़रूरी है अगर डिफ़ॉल्ट डिसप्ले, फ़्रेमबफ़र रिज़ॉल्यूशन का इस्तेमाल करता है, तो यह कम से कम 816 एमबी होना चाहिए से qHD (जैसे, FWVGA) को कनेक्ट करता है.
[7.6.1/H-6-1] कर्नेल के लिए उपलब्ध मेमोरी और उपयोगकर्ता स्थान कम से कम होना चाहिए अगर डिफ़ॉल्ट डिसप्ले, एचडी+ तक के फ़्रेमबफ़र रिज़ॉल्यूशन का इस्तेमाल करता है, तो 944 एमबी (उदाहरण के लिए, HD, WSVGA).
[7.6.1/H-7-1] कर्नेल के लिए उपलब्ध मेमोरी और उपयोगकर्ता स्थान कम से कम होना चाहिए अगर डिफ़ॉल्ट डिसप्ले में एफ़एचडी तक के फ़्रेमबफ़र रिज़ॉल्यूशन का इस्तेमाल किया जाता है, तो 1280 एमबी (उदाहरण के लिए, WSXGA+).
[7.6.1/H-8-1] कर्नेल के लिए उपलब्ध मेमोरी और उपयोगकर्ता स्थान कम से कम होना चाहिए अगर डिफ़ॉल्ट डिसप्ले में क्वाड हाई डेफ़िनिशन (क्यूएचडी) तक के फ़्रेमबफ़र रिज़ॉल्यूशन का इस्तेमाल किया जाता है, तो 1824 एमबी (उदाहरण के लिए, QWXGA).

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

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

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

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

[7.6.1/H-10-1] ज़रूरी है कि आपके पास कम से कम 4 जीबी स्टोरेज हो इनके लिए, नॉन-वोलेटाइल स्टोरेज उपलब्ध है ऐप्लिकेशन निजी डेटा (यानी "/data" पार्टीशन).
फ़ीचर फ़्लैग 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 GiB से कम है.
[7.7.1/H] इसमें ऐसा यूएसबी पोर्ट होना चाहिए जो सहायक डिवाइस (जैसे, कीबोर्ड, माउस, मॉनिटर, वेबकैम वगैरह) मोड के साथ काम करता हो.

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

[7.7.1/H-1-1] Android ओपन ऐक्सेसरी (एओए) को लागू करना ज़रूरी है एपीआई.

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

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

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

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

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

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

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

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

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

जब यूएसबी सहायक डिवाइस को उन्होंने कनेक्ट किया:

[7.8.2.2/H-4-1] AudioDeviceInfo.TYPE_USB_HEADSET टाइप का डिवाइस होना ज़रूरी है और यूएसबी ऑडियो टर्मिनल टाइप फ़ील्ड 0x0302 है, तो भूमिका isSink() होगी.
[7.8.2.2/H-4-2] ज़रूरी है कि अगर यूएसबी ऑडियो टर्मिनल में, AudioDeviceInfo.TYPE_USB_HEADSET और रोल isSink() को ऐक्सेस किया गया है टाइप फ़ील्ड 0x0402 है.
[7.8.2.2/H-4-3] टाइप का एक डिवाइस देना ज़रूरी है अगर यूएसबी ऑडियो टर्मिनल में, AudioDeviceInfo.TYPE_USB_HEADSET और रोल isSource() का इस्तेमाल किया गया है टाइप फ़ील्ड 0x0402 है.
[7.8.2.2/H-4-4] AudioDeviceInfo.TYPE_USB_DEVICE टाइप वाला डिवाइस होना ज़रूरी है और यूएसबी ऑडियो टर्मिनल टाइप फ़ील्ड 0x603 है, तो भूमिका isSink() होगी.
[7.8.2.2/H-4-5] ज़रूरी है कि अगर यूएसबी ऑडियो टर्मिनल में, AudioDeviceInfo.TYPE_USB_DEVICE और रोल isSource() है प्रकार फ़ील्ड 0x604 है.
[7.8.2.2/H-4-6] ज़रूरी है कि अगर यूएसबी ऑडियो टर्मिनल का टाइप है, तो AudioDeviceInfo.TYPE_USB_DEVICE और रोल isSink() फ़ील्ड 0x400 है.
[7.8.2.2/H-4-7] ज़रूरी है कि अगर यूएसबी ऑडियो टर्मिनल में, AudioDeviceInfo.TYPE_USB_DEVICE और रोल isSource() है प्रकार फ़ील्ड 0x400 है.
[7.8.2.2/H-SR-1] का सुझाव दिया जाता है. ऐसा तब किया जाता है, जब यूएसबी-सी ऑडियो पेरिफ़ेरल, यूएसबी डिस्क्रिप्टर की गिनती करने के लिए, टर्मिनल टाइप और ब्रॉडकास्ट इंटेंट ACTION_HEADSET_PLUG से कम में 1000 मिलीसेकंड.

अगर हैंडहेल्ड डिवाइस लागू करने के निर्देश android.hardware.audio.output और android.hardware.microphone, वे:

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

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

[7.10/H]* एक बहुत ज़्यादा रोटेटिंग मास (ईआरएम) का इस्तेमाल नहीं करना चाहिए हैप्टिक एक्चुएटर (वाइब्रेटर).
[7.10/H]* एक्चुएटर के प्लेसमेंट की जगह तय करनी चाहिए उस जगह के पास जहां डिवाइस आम तौर पर हाथ से पकड़ा या छूता है.
[7.10/H]* क्लियर हैप्टिक android.view.HapticFeedbackConstants में जाकर नाम है (CLOCK_TICK, context_Click, KEY एल्बम_PRESS, KEY एल्बम_ रिलीज़, KEYबोर्ड_TAP, LONG_PRESS, TEXT_HANDLE_ंप, VIRTUAL_KEY, VIRTUAL_KEY_ हटाए, पुष्टि करें, अस्वीकार करें, GESTURE_START, और GESTURE_END).
[7.10/H]* क्लियर हैप्टिक android.os.Vibrationimpact में इनके नाम हैं (म्फट_टीआईके, इफ़ेक्ट_क्लिक, इफ़ैक्ट_HEAVY_Click और ACTION_DOUBLE_Click) और सभी संभव सार्वजनिक इसके लिए PRIMITIVE_* कॉन्सटेंट रिच हैप्टिक android.os.Vibrationimpact.रोशनी में नाम है (Click, TICK, LOW_TICK, QUICK_FALL, QUICK_RISE, SLOW_RISE, Sपिन, THUD. इनमें से कुछ प्रिमिटिव, जैसे LOW_TICK और SMIN का इस्तेमाल सिर्फ़ तब किया जा सकता है, जब वाइब्रेटर फ़्रीक्वेंसी कम होती हैं.
[7.10/H]* सार्वजनिक स्थिरांकों को मैप करने के दिशा-निर्देशों का पालन करना चाहिए android.view.HapticFeedback नतीजों में जाकर सुझाए गए 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.arePrimitivesSupported() एपीआई की.
[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] का सुझाव दिया जाता है शॉर्टकट को ऐप्लिकेशन में पिन करने की सुविधा देने वाला डिफ़ॉल्ट लॉन्चर लागू करने के लिए, विजेट और widgetFeatures.
[3.8.1/H-SR-2] बहुत ज़्यादा सुझाव दिए जाते हैं एक डिफ़ॉल्ट लॉन्चर लागू करने के लिए जो अतिरिक्त सेटिंग का क्विक ऐक्सेस देता है ShortcutManager के ज़रिए तीसरे पक्ष के ऐप्लिकेशन से मिलने वाले शॉर्टकट एपीआई.
[3.8.1/H-SR-3] रखने का सुझाव दिया जाता है एक डिफ़ॉल्ट लॉन्चर ऐप्लिकेशन शामिल करने के लिए, जो ऐप्लिकेशन आइकॉन के लिए बैज दिखाता हो.
[3.8.2/H-SR-1] का सुझाव दिया जाता है तीसरे पक्ष के ऐप्लिकेशन विजेट की सुविधा भी मिलेगी.
[3.8.3/H-0-1] तीसरे पक्ष को अनुमति देनी होगी ऐसे ऐप्लिकेशन जो उपयोगकर्ताओं को Notification और NotificationManager एपीआई क्लास.
[3.8.3/H-0-2] रिच सपोर्ट नोटिफ़िकेशन.
[3.8.3/H-0-3] चेतावनी देने की सुविधा का इस्तेमाल करना ज़रूरी है नोटिफ़िकेशन.
[3.8.3/H-0-4] ज़रूरी है कि नोटिफ़िकेशन शेड, जिससे उपयोगकर्ता को सीधे उपयोगकर्ता की सुविधा के हिसाब से, सूचनाओं का जवाब देना, स्नूज़ (थोड़ी देर के लिए बंद करना), खारिज करना, ब्लॉक करना) करना. जैसे, AOSP में लागू किए गए ऐक्शन बटन या कंट्रोल पैनल का इस्तेमाल करें.
[3.8.3/H-0-5] विकल्प दिखाना ज़रूरी है RemoteInput.Builder setChoices() के ज़रिए दिया गया सूचना शेड में दिखाई देगा.
[3.8.3/H-SR-1] का सुझाव दिया जाता है RemoteInput.Builder setChoices() में दिए गए पहले विकल्प को दिखाने के लिए नोटिफ़िकेशन शेड में दिखाई देगा.
[3.8.3/H-SR-2] बहुत ज़्यादा सुझाव दिए जाते हैं RemoteInput.Builder setChoices() के ज़रिए दिए गए सभी विकल्पों को दिखाने के लिए सूचना शेड में, जब उपयोगकर्ता यहां दी गई सभी सूचनाओं को बड़ा करता है नोटिफ़िकेशन शेड पर टैप करें.
[3.8.3.1/H-SR-1] का बहुत ज़्यादा सुझाव दिया जाता है उन कार्रवाइयों को दिखाने के लिए जिनके लिए Notification.Action.Builder.setContextual के रूप में true इन-लाइन के रूप में सेट किया गया है Notification.Remoteinput.Builder.setChoices.
[3.8.4/H-SR-1] का सुझाव दिया जाता है असिस्ट की कार्रवाई को मैनेज करने के लिए, डिवाइस पर Assistant को लागू करना होगा.

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

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

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

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

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

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

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

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

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

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

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

[3.8.16/H-2-1] इसके लिए null को रिपोर्ट करना ज़रूरी है ControlsProviderService और Control एपीआई.
[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] हमारी सलाह है कि डिवाइस पर उपलब्ध भाषाओं के साथ काम करने वाला TTS इंजन.
[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 से सुरक्षित करना ज़रूरी है और इसे इससे पार्स किए गए इंटेंट की गतिविधि शुरू करें सेटिंग#additional_SETTINGS_VERSIONDED_DEEP_LINK_INTENT_uri.

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

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

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

[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 टूल में दी गई जानकारी के हिसाब से दी गई है दस्तावेज़ होना चाहिए.
- कुछ ऐप्लिकेशन को हटाए जाने से छूट दी जा सकती है या उन्हें इस तरह की सूची में शामिल किए जाने से छूट दी जा सकती है उपयोगकर्ता की कीमत का डेटा, जैसा कि 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 ओपन सोर्स प्रोजेक्ट (AOSP) इस ज़रूरी शर्त को पूरा करने के लिए Trusty लागू करने की प्रोसेस का इस्तेमाल करता है. हालांकि, यह अन्य ARM TrustZone पर आधारित समाधान या तीसरे पक्ष की सुरक्षित समीक्षा एक उचित हायपरवाइज़र-आधारित आइसोलेशन लागू करना वैकल्पिक है के विकल्प.
[9.11/H-0-4] लॉक स्क्रीन पर काम करना ज़रूरी है पुष्टि करने की प्रक्रिया को, एक ही जगह पर रन करने के दौरान सफलतापूर्वक, पुष्टि करने वाली कुंजियों का इस्तेमाल करने की अनुमति दें. लॉक स् क्रीन क्रेडेंशियल को इस तरह से सेव किया जाना चाहिए कि सिर्फ़ अलग-अलग तरीके से एक्ज़ीक्यूट किया जा सके लॉक स्क्रीन ऑथेंटिकेशन करने के लिए उपलब्ध वातावरण. अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट गेटकीपर हार्डवेयर ऐब्स्ट्रैक्शन लेयर (एचएएल) और Trusty शामिल है, जिसका इस्तेमाल इस ज़रूरत को पूरा करने के लिए किया जा सकता है.
[9.11/H-0-5] कुंजी को प्रमाणित करने की सुविधा होनी चाहिए, जहां प्रमाणित करने वाली साइनिंग कुंजी को सुरक्षित हार्डवेयर से सुरक्षित किया गया है और साइनिंग कुंजी को सुरक्षित हार्डवेयर में किया जाता है. प्रमाणित करने के लिए इस्तेमाल होने वाली हस्ताक्षर कुंजियां शेयर करनी ज़रूरी हैं का इस्तेमाल करना बंद कर सकें, इसके लिए आपके पास कई तरह के डिवाइसों का ऐक्सेस होना चाहिए के तौर पर रिकॉर्ड करते हैं. इस ज़रूरी शर्त को पूरा करने का एक तरीका यह है कि अगर किसी SKU की कम से कम 1,00,000 यूनिट को बनाया गया. अगर किसी SKU की 1,00,000 से ज़्यादा इकाइयां बनाई जाती हैं, तो कुंजी का उपयोग प्रत्येक 100,000 इकाइयों के लिए किया जा सकता है.
[9/H-0-1] ‘android.hardware.security.model.रोशनी’ का एलान करना ज़रूरी है सुविधा.

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

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

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

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

[9.8.2/H-5-1] कैमरा इंंडिकेटर दिखाना ज़रूरी है, जब ऐप लाइव कैमरे का डेटा ऐक्सेस कर रहा है, लेकिन तब नहीं जब कैमरा सिर्फ़ बताई गई भूमिकाओं को होल्ड करने वाले ऐप्लिकेशन से ऐक्सेस किया जाता है सीडीडी आइडेंटिफ़ायर [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]* परफ़ेटो बाइनरी को एक ऐसा प्रोटोबफ़ कॉन्फ़िगरेशन डालें, जो परफ़ेटो दस्तावेज़ होना चाहिए.
- [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.S मिलता है android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS के लिए आज़माएं, इसके बाद वे:

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

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

[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] हार्डवेयर वीडियो एन्कोडर के छह इंस्टेंस के साथ काम करना ज़रूरी है सेशन (एवीसी, एचईवीसी, VP9, AV1 या इसके बाद के वर्शन) किसी भी कोडेक से चल रहे हों 1080p रिज़ॉल्यूशन@30fps पर.
[5.1/H-1-5] हार्डवेयर वीडियो एन्कोडर की अधिकतम संख्या का विज्ञापन करना ज़रूरी है और डिकोडर सत्र जो इसके ज़रिए किसी भी कोडेक संयोजन में एक साथ चलाए जा सकते हैं CodecCapabilities.getMaxSupportedInstances() और VideoCapabilities.getSupportedPerformancePoints() तरीके इस्तेमाल करते हैं.
[5.1/H-1-6] हार्डवेयर वीडियो डिकोडर और हार्डवेयर के छह इंस्टेंस पर काम करना ज़रूरी है किसी भी कोडेक में वीडियो एन्कोडर सेशन (AVC, HEVC, VP9, AV1 या उसके बाद के वर्शन) 1080p@30fps रिज़ॉल्यूशन पर एक साथ चल रहा है.
[5.1/H-1-7] सभी हार्डवेयर वीडियो एन्कोडर के लिए 1080p या छोटे वीडियो एन्कोडिंग सेशन जब लोड हो रहा हो. यहां लोड करें को एक साथ 1080 से 720 पिक्सल के रूप में दिखाया गया है हार्डवेयर वीडियो कोडेक इस्तेमाल करके, सिर्फ़ वीडियो ट्रांसकोडिंग सेशन 1080 पिक्सल की ऑडियो-वीडियो रिकॉर्डिंग शुरू करना. Dolby विज़न कोडेक के लिए, कोडेक शुरू होने में 50 मि॰से॰ या इससे कम समय लगना चाहिए.
[5.1/H-1-8] सभी ऑडियो एन्कोडर के लिए 128 केबीपीएस या इससे कम बिटरेट वाला ऑडियो एन्कोडिंग सेशन लोड नहीं किया जा सकता. यहां लोड करें को सिर्फ़ 1080 पिक्सल से 720 पिक्सल वाले वीडियो के तौर पर दिखाया गया है 1080p के साथ हार्डवेयर वीडियो कोडेक का इस्तेमाल करके ट्रांसकोडिंग सेशन ऑडियो-वीडियो रिकॉर्डिंग शुरू करना.
[5.1/H-1-9] सिक्योर हार्डवेयर वीडियो डिकोडर के दो इंस्टेंस पर काम करना ज़रूरी है सेशन (एवीसी, एचईवीसी, VP9, AV1 या इसके बाद के वर्शन) किसी भी कोडेक से चल रहे हों 1080p रिज़ॉल्यूशन@30 एफ़पीएस (फ़्रेम प्रति सेकंड) पर समवर्ती रूप से.
[5.1/H-1-10] असुरक्षित हार्डवेयर वीडियो डिकोडर के तीन इंस्टेंस के साथ काम करना ज़रूरी है सिक्योर हार्डवेयर वीडियो डिकोडर सेशन के एक इंस्टेंस के साथ सेशन (कुल चार इंस्टेंस) (एवीसी, एचईवीसी, VP9, AV1 या इसके बाद के वर्शन) किसी भी कोडेक कॉम्बिनेशन में 1080p रिज़ॉल्यूशन@30fps पर एक साथ चल रहा होगा.
[5.1/ H-1-11] हर हार्डवेयर एवीसी, एचईवीसी, डिवाइस पर मौजूद VP9 या AV1 डिकोडर.
[5.1/H-1-12] सभी हार्डवेयर वीडियो डिकोडर के लिए, 1080 पिक्सल या उससे छोटे वीडियो डिकोड करने का सेशन जब लोड हो रहा हो. यहां लोड करें को एक साथ 1080 से 720 पिक्सल के रूप में दिखाया गया है हार्डवेयर वीडियो कोडेक इस्तेमाल करके, सिर्फ़ वीडियो ट्रांसकोडिंग सेशन 1080p ऑडियो-वीडियो प्लेबैक शुरू करना. Dolby विज़न कोडेक के लिए, कोडेक शुरू होने में 50 मि॰से॰ या इससे कम समय लगना चाहिए.
[5.1/H-1-13] सभी ऑडियो डिकोडर के लिए, 128 केबीपीएस या इससे कम बिटरेट वाला ऑडियो डिकोडिंग सेशन लोड नहीं किया जा सकता. यहां लोड करें को सिर्फ़ 1080 पिक्सल से 720 पिक्सल वाले वीडियो के तौर पर दिखाया गया है 1080p के साथ हार्डवेयर वीडियो कोडेक का इस्तेमाल करके ट्रांसकोडिंग सेशन ऑडियो-वीडियो प्लेबैक शुरू करना.
[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] 10 सेकंड में एक फ़्रेम से ज़्यादा नहीं छोड़ा जाना चाहिए 1080p 60 FPS (फ़्रेम प्रति सेकंड) वीडियो सेशन के लिए (यानी कि 0.167 प्रतिशत से कम फ़्रेम में गिरावट) लोड नहीं किया जा सकता. लोड को सिर्फ़ 1080 पिक्सल से 720 पिक्सल वाले वीडियो के तौर पर दिखाया जाता है हार्डवेयर वीडियो कोडेक इस्तेमाल करके ट्रांसकोडिंग सेशन, साथ ही 128 केबीपीएस AAC ऑडियो प्लेबैक.
[5.3/H-1-2] वीडियो के दौरान 10 सेकंड में एक से ज़्यादा फ़्रेम नहीं छोड़ना चाहिए लोड हो रहे 60 एफ़पीएस (फ़्रेम प्रति सेकंड) वाले वीडियो सेशन के रिज़ॉल्यूशन में बदलाव. लोड इस तरह से परिभाषित किया गया है हार्डवेयर का इस्तेमाल करके, एक साथ 1080 पिक्सल से 720 पिक्सल वाले वीडियो को ट्रांसकोड करने की सुविधा और साथ ही, 128 केबीपीएस AAC ऑडियो प्लेबैक.
[5.6/H-1-1] वीडियो में 80 मिलीसेकंड या इससे कम समय के लिए, टैप-टू-टोन कार्रवाई होनी चाहिए का इस्तेमाल करके,
[5.6/H-1-2] 80 मिलीसेकंड या उससे कम की दोतरफ़ा ऑडियो अवधि में, इंतज़ार का समय तय होना चाहिए कम से कम एक काम करने वाले डेटा पाथ से ज़्यादा हो.
[5.6/H-1-3] 3.5 मि॰मी॰ से ज़्यादा के ऑडियो के लिए, स्टीरियो आउटपुट के लिए 24-बिट ऑडियो की सुविधा ज़रूरी है जैक मौजूद होने पर और USB ऑडियो के ऊपर इंतज़ार का समय कम करने और स्ट्रीमिंग कॉन्फ़िगरेशन के लिए पूरा डेटा पाथ. कम कीमत वाले लोगों के लिए इंतज़ार का समय कम करने के लिए कॉन्फ़िगरेशन किया गया है. ऐप्लिकेशन में ऑडियो के लिए इंतज़ार का समय कम रखना चाहिए कॉलबैक मोड. स्ट्रीमिंग के लिए कॉन्फ़िगरेशन के तहत, ऐप्लिकेशन को 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 चैनल के यूएसबी ऑडियो डिवाइस पर काम करना ज़रूरी है (इसका इस्तेमाल DJ करता है कंट्रोलर का इस्तेमाल करके गाने की झलक सुन सकते हैं.)
[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] फ़ोन के पीछे वाला मुख्य कैमरा होना चाहिए, जिसका रिज़ॉल्यूशन 4k@30fps पर वीडियो कैप्चर करने की सुविधा देने वाले कम से कम 12 मेगापिक्सल का वर्शन. मुख्य पीछे वाला कैमरा, पीछे वाला कैमरा होता है, जिसका आईडी सबसे कम होता है.
[7.5/H-1-2] सामने वाला मुख्य कैमरा होना चाहिए, जिसका रिज़ॉल्यूशन यह कम से कम 5 मेगापिक्सल की क्वालिटी में और 1080p@30fps पर वीडियो कैप्चर करने की सुविधा देता है. मुख्य सामने का कैमरा सामने का कैमरा होता है, जिसका आईडी सबसे कम होता है.
[7.5/H-1-3] android.info.supportedHardwareLevel प्रॉपर्टी के साथ काम करना होगा बैक प्राइमरी के लिए FULL या इससे बेहतर और फ़्रंट प्राइमरी के लिए LIMITED या इससे बेहतर कैमरा.
[7.5/H-1-4] ज़रूरी है दोनों प्राइमरी के लिए CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME कैमरे.
[7.5/H-1-5] Camera2 JPEG फ़ॉर्मैट में वीडियो रिकॉर्ड करने में लगने वाला समय होना ज़रूरी है < 1000 मि॰से॰ के लिए 1080 पिक्सल रिज़ॉल्यूशन, जिसे आईटीएस के सीटीएस कैमरा परफ़ॉर्मेंसटेस्ट की मदद से मापा जाता है दोनों प्राइमरी कैमरों के लिए लाइटिंग की स्थिति (3,000K).
[7.5/H-1-6] Camera2 ऐप्लिकेशन के चालू होने में लगने वाला समय होना ज़रूरी है (पहली झलक के लिए कैमरा चालू करें फ़्रेम) < आईटीएस के तहत सीटीएस कैमरा परफ़ॉर्मेंसटेस्ट की मदद से मापा गया 500 मि॰से॰ दोनों प्राइमरी कैमरों के लिए लाइटिंग की स्थिति (3,000K).
[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.S फ़ंक्शन लागू होता है, तो android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, इसके बाद:

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

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

[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 Television डिवाइस का मतलब ऐसे 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] ओरिएंटेशन में हुए बदलावों को मेज़र करने की सुविधा होनी चाहिए 1000 डिग्री प्रति सेकंड तक.

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

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

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

[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 फ़्रेम प्रति सेकंड पर 720p और 1080p रिज़ॉल्यूशन वाले वीडियो की 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 फ़्रेम प्रति सेकंड पर HD 1080i मुख्य प्रोफ़ाइल के हाई लेवल के साथ. उन्हें इंटरलेस किए गए MPEG-2 वीडियो को डिइंटरलेस करना होगा और उसे तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराया जाए.

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

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

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

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

अगर 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] 60 फ़्रेम प्रति सेकंड पर एचडी 1080 पिक्सल प्रोफ़ाइल 0 (8 बिट रंग की गहराई)

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

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

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

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

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

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

अगर टेलीविज़न डिवाइस लागू करने की प्रोसेस के दौरान, android.hardware.audio.output, वे:

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

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

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

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

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

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

[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] आरएसए, एईएस, ECDSA और HMAC क्रिप्टोग्राफ़िक एल्गोरिदम और MD5, SHA1, और SHA-2 फ़ैमिली हैश फ़ंक्शन, Android कीस्टोर सिस्टम के साथ काम करने वाले एल्गोरिदम ऐसे क्षेत्र में मौजूद होते हैं, जिसे इस पर चलने वाले कोड से सुरक्षित रूप से अलग कर दिया जाता है कर्नेल और उसके ऊपर का हिस्सा. सिक्योर आइसोलेशन से सभी संभावित तरीकों को ब्लॉक करना चाहिए जिससे कर्नेल या यूज़रस्पेस कोड, आइसोलेटेड एनवायरमेंट, जिसमें डीएमए भी शामिल हैं. अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट (AOSP) इस ज़रूरी शर्त को पूरा करने के लिए Trusty लागू करने की प्रोसेस का इस्तेमाल करता है. हालांकि, यह अन्य ARM TrustZone पर आधारित समाधान या तीसरे पक्ष की सुरक्षित समीक्षा एक उचित हायपरवाइज़र-आधारित आइसोलेशन लागू करना वैकल्पिक है के विकल्प.
[9.11/T-0-3] लॉक स्क्रीन पर काम करना ज़रूरी है पुष्टि करने की प्रक्रिया को, एक ही जगह पर रन करने के दौरान सफलतापूर्वक, पुष्टि करने वाली कुंजियों का इस्तेमाल करने की अनुमति दें. लॉक स् क्रीन क्रेडेंशियल को इस तरह से सेव किया जाना चाहिए कि सिर्फ़ अलग-अलग तरीके से एक्ज़ीक्यूट किया जा सके लॉक स्क्रीन ऑथेंटिकेशन करने के लिए उपलब्ध वातावरण. अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट गेटकीपर हार्डवेयर ऐब्स्ट्रैक्शन लेयर (एचएएल) और Trusty शामिल है, जिसका इस्तेमाल इस ज़रूरत को पूरा करने के लिए किया जा सकता है.
[9.11/T-0-4] कुंजी को प्रमाणित करने की सुविधा का इस्तेमाल करना ज़रूरी है, जहां प्रमाणित करने वाली साइनिंग कुंजी को सुरक्षित हार्डवेयर से सुरक्षित किया गया है और साइनिंग कुंजी को सुरक्षित हार्डवेयर में किया जाता है. प्रमाणित करने के लिए इस्तेमाल होने वाली हस्ताक्षर कुंजियां शेयर करनी ज़रूरी हैं का इस्तेमाल करना बंद कर सकें, इसके लिए आपके पास कई तरह के डिवाइसों का ऐक्सेस होना चाहिए के तौर पर रिकॉर्ड करते हैं. इस ज़रूरी शर्त को पूरा करने का एक तरीका यह है कि अगर किसी SKU की कम से कम 1,00,000 यूनिट को बनाया गया. अगर किसी SKU की 1,00,000 से ज़्यादा इकाइयां बनाई जाती हैं, तो कुंजी का उपयोग प्रत्येक 100,000 इकाइयों के लिए किया जा सकता है.
[9/T-0-1] आपको ‘android.hardware.security.model.supported’ का एलान करना ज़रूरी है सुविधा.

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

[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_AVERAGE से ऐक्सेस किया जाता है, ContentRecordService या सेक्शन 9.1 में बताई गई भूमिकाओं वाले ऐप्लिकेशन CDD आइडेंटिफ़ायर C-3-X वाली अनुमतियां].
[9.8.2/T-4-2] इसके लिए माइक्रोफ़ोन इंडिकेटर को नहीं छिपाना चाहिए ऐसे सिस्टम ऐप्लिकेशन जिनमें यूज़र इंटरफ़ेस या डायरेक्ट यूज़र इंटरैक्शन दिखता हो.

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

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

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

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

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

2.4. स्मार्टवॉच के लिए ज़रूरी शर्तें

Android Watch डिवाइस का मतलब ऐसे Android डिवाइस से है जिसे इन कामों के लिए इस्तेमाल किया जाता है इसे कलाई पर पहन सकते हैं.

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

स्क्रीन की डायगनल लंबाई 1.1 से 2.5 के बीच रखें इंच.
शरीर पर पहनने के लिए एक तरीका उपलब्ध कराया गया हो.

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

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 उपकरण कार्यान् वयन में GPS/GNSS रिसीवर शामिल होता है और android.hardware.location.gps सुविधा का इस्तेमाल करके, ऐप्लिकेशन इस्तेमाल करने की क्षमता फ़्लैग करते हैं, तो:

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

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

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

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

[7.4.3/W-0-1] ब्लूटूथ के साथ काम करना ज़रूरी है.
[7.6.1/W-0-1] ज़रूरी है कि आपके पास कम से कम 1 जीबी हो ऐप्लिकेशन के निजी डेटा (यानी "/data" पार्टीशन) के लिए, नॉन-वोलाटाइल स्टोरेज उपलब्ध है.
[7.6.1/W-0-2] स्टोरेज 416 एमबी या इससे कम होना चाहिए कर्नेल और यूज़रस्पेस के लिए उपलब्ध होता है.
[7.8.1/W-0-1] माइक्रोफ़ोन होना ज़रूरी है.
[7.8.2/W] में ऑडियो आउटपुट हो सकता है.

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

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

2.4.3. सॉफ़्टवेयर

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

[3/W-0-1] सुविधा के बारे में एलान करना ज़रूरी है android.hardware.type.watch.
[3/W-0-2] uiMode के साथ काम करना ज़रूरी है = UI_Mode_TYPE_देखें.
[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 (पहले से इंस्टॉल किए गए वर्शन के साथ काम करने वाली भाषाओं के लिए) टेक्स्ट-टू-स्पीच इंजन) के लिए उपलब्ध सुलभता सेवाएं TalkBack का ओपन सोर्स प्रोजेक्ट.

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

[3.11/W-SR-1] हमारी सलाह है कि डिवाइस पर उपलब्ध भाषाओं के साथ काम करने वाला TTS इंजन.
[3.11/W-0-1] को तीसरे पक्ष के टीटीएस इंजन.

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

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

[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 का एलान करना ज़रूरी है सुविधा.

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

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

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

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

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

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

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

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

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

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 को सेटअप किया जा सकता है.
[7.3/A-SR1] शायद जगह की जानकारी को खारिज किया गया हो जीपीएस/जीएनएसएस को अतिरिक्त सेंसर के साथ फ़्यूज़ करके. अगर Location को घातक नहीं माना गया है, इसलिए संबंधित सेंसर टाइप और/या वाहन के प्रॉपर्टी आईडी इस्तेमाल किया गया.
[7.3/A-0-4] जगह की जानकारी LocationManager#requestLocationLocation() के ज़रिए अनुरोध किया गया मैप से मेल खाना चाहिए.
[7.3.1/A-0-4] ज़रूरी है कि वह Android का पालन करे कार सेंसर कोऑर्डिनेट सिस्टम.
[7.3/A-SR-1] 3-ऐक्सिस को शामिल करने के लिए, बहुत ज़्यादा ज़रूरी है एक्सलरोमीटर और 3-ऐक्सिस जाइरोस्कोप.
[7.3/A-SR-2] लागू करने और रिपोर्ट करने के लिए STRONGLY_सुझाया गया तरीका इस्तेमाल किया गया TYPE_HEADING सेंसर.

अगर वाहन संबंधित डिवाइस, 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] हमारी सलाह है कि आप सीमित ऐक्सिस एक्सलरोमीटर के लिए कंपोज़िट सेंसर.

अगर Automotive डिवाइस में लागू किए गए एक्सलरोमीटर से कम 3 ऐक्सिस से:

[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] जगह की जानकारी पहली बार में तय करना ज़रूरी है GPS/GNSS रिसीवर 60 सेकंड के अंदर 4+ दिनों में चालू या चालू हो जाता है.
[7.3.3/A-3-2] 'सबसे पहले ठीक करने के समय' की शर्तों को पूरा करना ज़रूरी है, क्योंकि 7.3.3/C-1-2 और 7.3.3/C-1-6 में बताया गया है जगह की जानकारी के अन्य अनुरोधों के लिए (उदाहरण के लिए, ऐसे अनुरोध जो पहली बार नहीं किए गए हैं) या 4 से ज़्यादा दिनों के बाद. 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 हर्ट्ज़ की फ़्रीक्वेंसी होनी चाहिए.
यह सही उत्तर के हिसाब से होना चाहिए.
वाहन के स्थिर रहने पर भी उपलब्ध होना चाहिए.
रिज़ॉल्यूशन कम से कम 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] ज़रूरी है कि आपके पास कम से कम 4 जीबी स्टोरेज हो ऐप्लिकेशन के निजी डेटा के लिए, नॉन-वोलाटाइल स्टोरेज उपलब्ध है (यानी "/data" पार्टीशन).
[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.* नेमस्पेस.

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

[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 में बताए गए तरीके से संसाधनों को रेंडर करना एसडीके से जुड़े दस्तावेज़.
[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] ज़रूरी है कि CONTENT_STYLE_BROWSABLE_HINT और CONTENT_STYLE_PLAYABLE_HINT MediaBrowser दिखाते समय परिभाषाएं हैरारकी है.

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

[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 ओपन सोर्स प्रोजेक्ट, 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] कॉन्टेंट बनाने की सुविधा होनी चाहिए एक मेहमान उपयोगकर्ता भले ही, किसी डिवाइस पर उपयोगकर्ताओं की तय संख्या पूरी हो गई हो.

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

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

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

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

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

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

कम से कम मेमोरी और स्टोरेज (सेक्शन 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 व्याख्या (@TestApi) से चिह्नित है.
[C-0-3] मैनेज किए जा रहे किसी एपीआई को छोड़ने, एपीआई इंटरफ़ेस या हस्ताक्षर में बदलाव करने की ज़रूरत नहीं है, दस्तावेज़ में शामिल व्यवहार से अलग हो या उसमें कोई कार्रवाई न की गई हो, लेकिन की अनुमति है.
[C-0-4] ज़रूरी है कि एपीआई अब भी मौजूद रहे और सही तरीके से काम करे हो सकता है, भले ही Android डिवाइस में मौजूद हार्डवेयर की कुछ सुविधाएं इसमें एपीआई शामिल नहीं किए गए हैं. सेक्शन 7 देखें देखें.
[C-0-5] तीसरे पक्ष के ऐप्लिकेशन को बिना SDK टूल वाले इंटरफ़ेस इस्तेमाल करने की अनुमति नहीं देनी चाहिए, को Java भाषा पैकेज में ऐसी विधियों और फ़ील्ड के रूप में परिभाषित किया जाता है जिन्हें के बूट क्लासपाथ में शामिल नहीं किया जा सकता है और जो लोगों का हिस्सा नहीं है SDK टूल. इसमें ऐसे एपीआई शामिल हैं जिन्हें @hide एनोटेशन से सजाया गया है, लेकिन इससे नहीं @SystemAPI, जैसा कि SDK टूल के दस्तावेज़ों में बताया गया है और निजी और पैकेज-प्राइवेट क्लास के सदस्यों के साथ शेयर करना शामिल है.
[C-0-6] SDK टूल के अलावा, हर उस इंटरफ़ेस के साथ शिप करना ज़रूरी है जो SDK टूल के दायरे में नहीं आता में अस्थायी और ब्लॉकलिस्ट फ़्लैग के ज़रिए दी गई सूचियां prebuilts/runtime/appcompat/hiddenapi-flags.csv एओएसपी में एपीआई लेवल की सही ब्रांच का पाथ.
[C-0-7] साइन किए गए कॉन्फ़िगरेशन के साथ काम करना ज़रूरी है पाबंदी वाली सूची से बिना SDK टूल वाले इंटरफ़ेस को हटाने के लिए, डाइनैमिक अपडेट का तरीका मौजूदा सार्वजनिक कुंजियों का इस्तेमाल करके, किसी भी APK में साइन किए गए कॉन्फ़िगरेशन को एम्बेड करके AOSP में मौजूद है.

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

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] एक्सटेंशन वर्शन की ओर से तय किए गए सभी एपीआई के साथ काम करना चाहिए android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) ने वापस किया मैनेज किए जा रहे अन्य एपीआई की तरह ही काम करता है, जो सेक्शन 3.1 में बताई गई ज़रूरी शर्तें.

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

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

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

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

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

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

3.2.1. अनुमतियां

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

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

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

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

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

ऐप्लिकेशन के ज़रूरी इंटेंट के लिए, कृपया सेक्शन 2 देखें का उपयोग करने की अनुमति देते हैं.

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

[C-0-1] Android एक एक्सटेंसिबल प्लैटफ़ॉर्म है, इसलिए डिवाइस को लागू करने के लिए यह ज़रूरी है सेक्शन 3.2.3.1 में बताए गए हर इंटेंट पैटर्न को अनुमति दें , सेटिंग को छोड़कर, तीसरे पक्ष के ऐप्लिकेशन से ओवरराइड होने के लिए. कॉन्टेंट बनाने अपस्ट्रीम Android ओपन सोर्स को लागू करने की वजह से, डिफ़ॉल्ट रूप से इसकी अनुमति मिलती है.
[C-0-2] डिवाइस लागू करने वाले लोगों को सिस्टम में खास अधिकार नहीं जोड़ने चाहिए ऐप्लिकेशन की इन इंटेंट पैटर्न का इस्तेमाल कर सकते हैं या तीसरे पक्ष के ऐप्लिकेशन को रोक सकते हैं इन पैटर्न को बाइंड करने और कंट्रोल करने से लेकर इन पैटर्न तक को कंट्रोल किया जा सकता है. यह पाबंदी इसमें खास तौर पर, “Chooser” उपयोगकर्ता के खाते को बंद करने की प्रोसेस शामिल है. हालांकि, इसमें और भी चीज़ें शामिल हो सकती हैं ऐसा इंटरफ़ेस जिसकी मदद से उपयोगकर्ता कई ऐप्लिकेशन में से किसी एक को चुन सकता है समान इंटेंट पैटर्न हैंडल करते हैं.
[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 कॉम्पोनेंट शामिल नहीं होना चाहिए जो किसी ACTION, CATEGORY, या android.* या com.android.* नेमस्पेस में मौजूद अन्य कुंजी स्ट्रिंग.
[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 में ऐसी सेटिंग शामिल हैं जिनकी मदद से, लोग आसानी से अपनी पसंद की सेटिंग चुन सकते हैं डिफ़ॉल्ट ऐप्लिकेशन, जैसे कि होम स्क्रीन या एसएमएस.

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

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

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

[C-4-1] इन इंटेंट का पालन करना ज़रूरी है android.nfc.action.NDEF_DISCOVERED, android.nfc.action.TAG_डिस्कवर & 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 का पालन करना ज़रूरी है को सक्षम और अक्षम करने के लिए उपयोगकर्ता के लिए सुलभ प्रणाली उपलब्ध कराने के उद्देश्य से की गई है पहले से लोड की गई सुलभता सेवाओं के साथ-साथ तीसरे पक्ष की सुलभता सेवाएं सेवाओं.

यदि डिवाइस कार्यान्वयन में Wi-Fi Easy Connect का समर्थन शामिल है और की सुविधाओं का इस्तेमाल करते हैं, तो उन्हें:

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

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

[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_पासवर्ड & 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 के साथ काम करते हैं और उनमें ये भी काम करते हैं एक बार में इंस्टॉल किए गए इस API का उपयोग करके एक से ज़्यादा ऐप्लिकेशन इंस्टॉल करते हैं, तो वे:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[C-0-1] एक या इससे ज़्यादा तय किए गए Android NDK ABI के साथ काम करना ज़रूरी है.
[C-0-2] मैनेज किए गए एनवायरमेंट में चल रहे कोड के साथ काम करना ज़रूरी है, ताकि मानक जावा नेटिव इंटरफ़ेस (जेएनआई) का इस्तेमाल करके नेटिव कोड में कॉल करें सिमेंटिक्स.
[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 लाइब्रेरी के ज़रिए NDK में बताया गया है. ध्यान दें कि सभी सिंबल का मौजूद होना ज़रूरी है, लेकिन सेक्शन 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 डिवाइसों के लिए.
[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] Chromium प्रोजेक्ट बिल्ड का इस्तेमाल करना ज़रूरी है Android पर अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट से के लागू होने के लिए 13 ब्रांच android.webkit.WebView एपीआई.
[C-1-3] वेबव्यू से रिपोर्ट की गई उपयोगकर्ता एजेंट स्ट्रिंग इस फ़ॉर्मैट में होनी चाहिए:

Mozilla/5.0 (Linux; Android $(VERSION); [$(MODEL)] [बिल्ड/$(BUILD)]; wv) AppleWebKit/537.36 (KHTML, जैसे Gecko) वर्शन/4.0 $(CHROMIUM_VER) मोबाइल सफ़ारी/537.36
- $(VERSION) स्ट्रिंग का मान android.os.Build.VERSION.रिलीज़.
- $(MODEL) स्ट्रिंग ख़ाली हो सकती है, लेकिन अगर यह खाली नहीं है, तो यह ज़रूरी है इसके मान android.os.Build.MODEL के समान हैं.
- "बिल्ड/$(बिल्ड)" इसे हटाया जा सकता है, लेकिन अगर यह $(BUILD) मौजूद है स्ट्रिंग, android.os.Build.ID की वैल्यू से मेल खानी चाहिए.
- $(CHROMIUM_VER) स्ट्रिंग का मान Chromium का वर्शन होना चाहिए को अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट में देख लिया है.
- डिवाइस पर लागू होने वाली कार्रवाई से, उपयोगकर्ता एजेंट स्ट्रिंग में मोबाइल को हटाया जा सकता है.
वेबव्यू घटक के बराबर HTML5 सुविधाओं के लिए समर्थन शामिल होना चाहिए उपलब्ध हो सकता है और अगर यह सुविधा का इस्तेमाल करती है, तो HTML5 की खास बातें.
[C-1-4] प्रोसेस के दौरान, दिए गए कॉन्टेंट या रिमोट यूआरएल कॉन्टेंट को रेंडर करना ज़रूरी है जो उस ऐप्लिकेशन से अलग हो जो वेबव्यू को इंस्टैंशिएट करता है. खास तौर पर अलग रेंडरर प्रोसेस में कम ऐक्सेस होना चाहिए, आपके पास ऐप्लिकेशन की डेटा डायरेक्ट्री का ऐक्सेस न हो, इनके पास नेटवर्क का सीधा ऐक्सेस नहीं होता है. साथ ही, आपके पास सिर्फ़ ज़रूरी कम से कम बाइंडर पर सिस्टम सेवाएं ऐक्सेस करना. वेबव्यू का एओएसपी लागू होने की प्रक्रिया पूरी होती है इस शर्त को पूरा करना ज़रूरी है.

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

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

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

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

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

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

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

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

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

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

[C-1-1] सेक्शन 3.5.1 में दी गई सभी ज़रूरी शर्तों को पूरा करना ज़रूरी है. इसमें ये शर्तें शामिल नहीं हैं: [C-1-6] और [C-1-3].
[C-1-2] लोगों के लिए ऐप्लिकेशन पर पाबंदी सिर्फ़ तब लागू करनी चाहिए, जब इस बात का सबूत कि उपयोगकर्ता ने कुछ समय से ऐप्लिकेशन का इस्तेमाल नहीं किया है. यह हमारा सुझाव है कि अवधि को एक महीने या उससे ज़्यादा रखें. इस्तेमाल करना ज़रूरी है यह तय करें कि उपयोगकर्ता और उपयोगकर्ता के बीच साफ़ तौर पर किस तरह से इंटरैक्शन किया जा सकता है. इसके लिए, SubscriptionStats#getLastTime दिखाई() एपीआई या ऐसा कोई भी कॉन्टेंट जिसकी वजह से ऐप्लिकेशन बंद रहने की स्थिति को छोड़ सकता है, इनमें सर्विस बाइंडिंग, कॉन्टेंट देने वाले की बाइंडिंग, साफ़ तौर पर किए गए ब्रॉडकास्ट वगैरह शामिल हैं. जिसे नए एपीआई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) की लाइब्रेरी या किसी अन्य कंपनी की लाइब्रेरी में नहीं होना चाहिए बताए गए अनुसार संगठन यहां पढ़ें.

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

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

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

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

[C-0-1] ज़रूरत के हिसाब से, Delvik exeutable (DEX) फ़ॉर्मैट के साथ काम करना चाहिए और Dalvik बाइटकोड स्पेसिफ़िकेशन और सिमैंटिक.
[C-0-2] ऐसा करने के लिए, Delvik रनटाइम को कॉन्फ़िगर करना ज़रूरी है अपस्ट्रीम Android प्लैटफ़ॉर्म के मुताबिक और यहां दी गई टेबल में बताया गया है. (इसके लिए सेक्शन 7.1.1 देखें स्क्रीन का साइज़ और स्क्रीन की सघनता की परिभाषाएं.)
उसे Android रनटाइम (ART) का इस्तेमाल करना चाहिए, जो कि अपस्ट्रीम रेफ़रंस है डाल्विक एक्ज़िक्यूटेबल फ़ॉर्मैट को लागू करना होगा, और पैकेज मैनेजमेंट सिस्टम लागू करें.
एक्ज़ीक्यूशन के अलग-अलग तरीकों के तहत, फ़ज़ टेस्ट चलाना चाहिए और रनटाइम की स्थिरता बनाए रखने के लिए टारगेट आर्किटेक्चर. इससे संदर्भ लें जेफ़ज़ और 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] AdaptiveIconDrawable को लौटाना ज़रूरी है तब ऑब्जेक्ट करें, जब तीसरे पक्ष का ऐप्लिकेशन उपलब्ध कराने के लिए <adaptive-icon> टैग का इस्तेमाल करे उनका आइकॉन और PackageManager आइकॉन वापस पाने के तरीकों को कॉल किया जाता है.

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

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

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

[C-3-1] इसके लिए false की रिपोर्ट करनी होगी ShortcutManager.isRequestPinShortcutSupported().

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

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

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

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

3.8.3. सूचनाएं

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.3.2. सिस्टम से कॉल रिसीव करने वाली सेवा से जुड़ी सूचना

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

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

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

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

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

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

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

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

3.8.4. Assist API से

Android में सहायक एपीआई शामिल हैं इससे ऐप्लिकेशन यह चुन सकेंगे कि मौजूदा संदर्भ में कितनी जानकारी है डिवाइस पर 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 में “Holo” और "Material" शामिल हैं तय स्टाइल के सेट के तौर पर थीम फ़ैमिली ऐप्लिकेशन डेवलपर का उपयोग करने के लिए, ताकि वे होलो थीम का लुक और स्टाइल Android SDK के मुताबिक तय किया गया है.

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

[C-1-1] किसी भी Holo थीम एट्रिब्यूट में बदलाव नहीं करना चाहिए का इस्तेमाल करें.
[C-1-2] “मटीरियल” थीम फ़ैमिली का इस्तेमाल करना ज़रूरी है और इनमें से किसी में भी बदलाव नहीं करना चाहिए मटीरियल थीम एट्रिब्यूट को अनुमति नहीं है.
[C-1-3] "sans-serif" को सेट करना ज़रूरी है फ़ॉन्ट फ़ैमिली से भाषाओं के लिए Roboto वर्शन 2.x जिसका इस्तेमाल Roboto करता हो या वह इस्तेमाल किए जाने वाले फ़ॉन्ट को बदलने के लिए उपयोगकर्ता की सुविधा देता हो "sans-Serif" के लिए फ़ॉन्ट फ़ैमिली को 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 देखें), नाम हैं 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-ser-thin, San-Ser-light, Sans-Serif-medium, Sans-Serif-black, San-Serif-condensed, अगर डिवाइस पर उपलब्ध भाषाओं के लिए, Sans-erif-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-Qag). कोई अन्य ISO भाषा या क्षेत्र कोड नहीं (चाहे असाइन किया गया, असाइन नहीं किया गया या रिज़र्व किया गया) का इस्तेमाल, नॉन-यूनिकोड को रेफ़र करने के लिए किया जा सकता है म्यांमार के लिए फ़ॉन्ट का इस्तेमाल करें. ऐप्लिकेशन डेवलपर और वेब पेज के लेखक ये काम कर सकते हैं मेरे-Qaag को किसी भी भाषा कोड के तौर पर तय करें अन्य भाषा.

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

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

[C-1-1] ऐसे मल्टी-विंडो मोड को लागू करना ज़रूरी है जो Android SDK में बताए गए ऐप्लिकेशन के व्यवहार और एपीआई मल्टी-विंडो मोड से जुड़ी सहायता से जुड़े दस्तावेज़ और Meet ये ज़रूरी शर्तें:
[C-1-2] android:resizeableActivity का पालन करना ज़रूरी है जिसे कोई ऐप्लिकेशन, AndroidManifest.xml फ़ाइल में इस तरह सेट करता है: यह SDK टूल.
[C-1-3] स्प्लिट स्क्रीन या फ़्रीफ़ॉर्म मोड की सुविधा नहीं देनी चाहिए, अगर स्क्रीन की ऊंचाई 440 dp से कम और स्क्रीन की चौड़ाई 440 से कम है डीपी.
[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() के ज़रिए मौजूदा PIP गतिविधि से तय किया गया एपीआई.
[C-3-3] इससे ज़्यादा या इसके बराबर के आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) में काम करना ज़रूरी है 1:2.39 और 2.39:1 से कम या उसके बराबर, जैसा कि पीआईपी गतिविधि के ज़रिए बताया गया है setAspectRatio() एपीआई.
[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 डीपी और ऊंचाई कम से कम 135 डीपी हो.

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

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

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

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

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

[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 ऐप्लिकेशन को डिवाइस के मालिक के ऐप्लिकेशन के तौर पर रजिस्टर करना ज़रूरी है इसके अलावा, DPC ऐप्लिकेशन को यह चुनने का विकल्प दिया जा सकता है कि आप डिवाइस के मालिक या प्रोफ़ाइल के मालिक बन सकते हैं, अगर डिवाइस, नियर-फ़ील्ड कम्यूनिकेशंस (एनएफ़सी) सहायता का एलान करता है फ़ीचर फ़्लैग android.hardware.nfc और एक एनएफ़सी मैसेज मिलता है MIME प्रकार वाला एक रिकॉर्ड शामिल है MIME_TYPE_PROVISIONING_NFC.
  - [C-1-8] ACTION_GET_PROVISIONING_मोड भेजना ज़रूरी है इंटेंट के हिसाब से, डिवाइस के मालिक के प्रावधान के बाद ट्रिगर होता है, ताकि 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 ने फ़्लो शुरू किया DPC ऐप्लिकेशन को "डिवाइस के मालिक" के रूप में रजिस्टर करने से पहले.
[C-2-3] सहमति को हार्ड कोड नहीं करना चाहिए या डिवाइस के मालिक के अन्य ऐप्लिकेशन का इस्तेमाल करने पर.

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

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

[C-1-1] एपीआई को लागू करना ज़रूरी है डिवाइस नीति नियंत्रक (DPC) ऐप्लिकेशन को मैनेज की जा रही नई प्रोफ़ाइल के मालिक.
[C-1-2] मैनेज की जा रही प्रोफ़ाइल को उपलब्ध कराने की प्रोसेस (यह प्रोसेस, DPC की ओर से android.app.action.PROVISION_MANAGED_PROFILE) सहमति लेने से जुड़ी स्क्रीन और उपयोगकर्ता अनुभव, इन तीनों के मुताबिक होना चाहिए AOSP लागू करना.
[C-1-3] ज़रूरी है कि सेटिंग में जाकर, लोगों के लिए ये सुविधाएं उपलब्ध कराई जाएं, ताकि उपयोगकर्ता को तब बताएं, जब किसी सिस्टम फ़ंक्शन को बंद कर दिया गया हो डिवाइस नीति नियंत्रक (DPC):
- एक जैसा आइकॉन या लोगों के लिए अलग-अलग सुविधाएं (जैसे, अपस्ट्रीम) AOSP की जानकारी का आइकॉन) देखें, ताकि यह पता चल सके कि कोई खास सेटिंग कब डिवाइस एडमिन.
- एक छोटा सा मैसेज, जिसे डिवाइस एडमिन ने आपको setShortSupportMessage.
- DPC ऐप्लिकेशन का आइकॉन.
[C-1-4] ACTION_PROVISIONING_ Success के लिए हैंडलर लॉन्च करना ज़रूरी है इंटेंट प्रावधान की प्रोसेस, android.app.action.PROVISION_MANAGED_PROFILE की मदद से शुरू की जाती है इंटेंट और DPC ने हैंडलर लागू कर दिया है.
[C-1-5] ACTION_PROFILE_PROVISIONING_ वास्तविक को भेजना ज़रूरी है जब प्रावधान प्रक्रिया शुरू की जाती है, तब वर्क प्रोफ़ाइल के DPC को ब्रॉडकास्ट किया जाता है android.app.action.PROVISION_MANAGED_PROFILE इंटेंट.
[C-1-6] 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] ACTION_MANAGED_PROFILE_PROVISIONED भेजना ज़रूरी है प्रोफ़ाइल का मालिक तय होने के बाद, निजी प्रोफ़ाइल के DPC को ब्रॉडकास्ट भेजा जाता है, भले ही, प्रॉविज़निंग का कोई भी तरीका इस्तेमाल किया गया हो.

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

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

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

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

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

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

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

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

3.11. लिखाई को बोली में बदलना

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

अगर डिवाइस लागू करने की सुविधा के ज़रिए android.hardware.audio.Output सुविधा की शिकायत की जा रही है, तो वे:

[C-1-1] ज़रूरी है कि Android टीटीएस फ़्रेमवर्क एपीआई.

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

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

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

Android Television इनपुट फ़्रेमवर्क (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] Google Ads की ओर से उपलब्ध कराए गए कॉन्टेंट को दिखाते समय, तीसरे पक्ष का ऐप्लिकेशन आइकॉन दिखाना ज़रूरी है यह तीसरे पक्ष का ऐप्लिकेशन है.
[C-1-4] उपयोगकर्ता को पूरे MediaBrowser से इंटरैक्ट करने की अनुमति देनी चाहिए हैरारकी है. सुरक्षा के कानूनों का पालन करने के लिए, हैरारकी के किसी हिस्से के ऐक्सेस पर पाबंदी लगाई जा सकती है (उदाहरण के लिए, ड्राइवर का ध्यान भटकना), लेकिन कॉन्टेंट या कॉन्टेंट देने वाला.
[C-1-5] दो बार टैप करें KEYCODE_HEADSETHOOK या KEYCODE_MEDIA_PLAY_PAUSE KEYCODE_MEDIA_NEXT के तौर पर MediaSession.Callback#onMediaButtonEvent के लिए.

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

रॉ संपर्क "से संबद्ध" हैं या "यहां सेव है" एक खाता जब ACCOUNT_NAME, और ACCOUNT_TYPE, रॉ संपर्क के कॉलम खाते का नाम और 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” फ़ाइलों को इंस्टॉल करने और चलाने में इसमें शामिल “aapt” टूल से जनरेट किया जाता है Android का आधिकारिक SDK टूल.
- हालांकि, ऊपर बताई गई शर्त मुश्किल हो सकती है. इसलिए, इन डिवाइसों पर ये सुविधाएं लागू करना मुश्किल होता है एओएसपी रेफ़रंस के लिए, पैकेज मैनेजमेंट सिस्टम का इस्तेमाल करने का सुझाव दिया जाता है सिस्टम.
[C-0-2] ज़रूरी शर्तें पूरी करने पर, “.apk” फ़ाइलों की पुष्टि करने की सुविधा APK सिग्नेचर स्कीम v3.1, APK सिग्नेचर स्कीम v3, APK सिग्नेचर स्कीम v2 और JAR साइनिंग की सुविधा मौजूद होनी चाहिए.
[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 या उससे कम पर सेट किया जाना चाहिए.
- यह ज़रूरी है कि उपयोगकर्ता ने Google से ऐप्लिकेशन इंस्टॉल करने की अनुमति दी हो अज्ञात स्रोत.
उपयोगकर्ताओं को हर ऐप्लिकेशन के लिए, अज्ञात सोर्स से ऐप्लिकेशन इंस्टॉल करें. हालांकि, उन्हें लागू किया जा सकता है इसे नो-ऑप के रूप में और startActivityForResult() के लिए RESULT_CANCELED वापस लौटाएं, अगर डिवाइस लागू करने के क्रम में उपयोगकर्ताओं को यह विकल्प नहीं देना हो. हालांकि, ऐसे मामलों में भी, उन्हें उपयोगकर्ता को यह बताना चाहिए कि पेश है.
[C-0-7] चेतावनी स्ट्रिंग के साथ एक चेतावनी डायलॉग दिखाना ज़रूरी है सिस्टम एपीआई PackageManager.setHarmfulAppWarning की मदद से दिया गया उपयोगकर्ता को किसी ऐसे ऐप्लिकेशन में गतिविधि लॉन्च करने से पहले जिसे उसी सिस्टम एपीआई PackageManager.setHarmfulAppWarning से नुकसान पहुंचाने वाला.
ऐप्लिकेशन को अनइंस्टॉल करने या उसे लॉन्च करने का विकल्प, लोगों को मिलना चाहिए ऐप्लिकेशन दिखाई देगा.
[C-0-8] दस्तावेज़ के मुताबिक, इंक्रीमेंटल फ़ाइल सिस्टम के साथ काम करना ज़रूरी है यहां पढ़ें.
[C-0-9] APK सिग्नेचर स्कीम v4 का इस्तेमाल करके, .apk फ़ाइलों की पुष्टि करने की सुविधा होनी चाहिए और APK सिग्नेचर स्कीम v4.1.

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

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

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

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

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

नीचे दिए गए सेक्शन में दिए गए सभी कोडेक सॉफ़्टवेयर के तौर पर दिए गए हैं Android Open से अपनी पसंद के 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 प्रोफ़ाइल, जिसमें यह शामिल है) यूएसएसी बेसलाइन प्रोफ़ाइल, और ISO/IEC 23003-4 डाइनैमिक रेंज कंट्रोल प्रोफ़ाइल)
[C-1-5] एफ़एलएसी
[C-1-6] एमपी3
[C-1-7] एमआईडीआई
[C-1-8] वोर्बिस
[C-1-9] PCM/WAVE, जिसमें हाई-रिज़ॉल्यूशन वाला ऑडियो शामिल है 24 बिट, 192 किलोहर्ट्ज़ का सैंपल रेट, और आठ चैनल तक के फ़ॉर्मैट. ध्यान दें कि यह ज़रूरत सिर्फ़ डिकोड करने के लिए है. साथ ही, यह कि को वीडियो चलाने के चरण के दौरान डाउनसैंपल और डाउनमिक्स की अनुमति है.
[C-1-10] ओपस

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

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

आईएसओ/आईईसी 23003-4 का इस्तेमाल करके, तेज़ आवाज़ और डाइनैमिक रेंज कंट्रोल की सुविधा काम कर सकती है डाइनैमिक रेंज कंट्रोल प्रोफ़ाइल.

अगर ISO/IEC 23003-4 काम करता है और अगर ISO/IEC 23003-4 दोनों और आईएसओ/आईईसी 14496-3 मेटाडेटा, डिकोड किए गए बिटस्ट्रीम में मौजूद होता है. इसके बाद:

ISO/IEC 23003-4 मेटाडेटा को प्राथमिकता दी जानी चाहिए.

सभी ऑडियो डिकोडर को आउटपुट वाली सुविधा का इस्तेमाल करना चाहिए:

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

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

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

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

[C-SR-2] डिकोडर को बहुत ज़्यादा सुझाया जाता है, ताकि उसे कुंजी की मदद से डिकोड करने की सुविधा का इस्तेमाल करने वाला ऐप्लिकेशन KEY_MAX_OUTPUT_CHANNEL_COUNT का इस्तेमाल करके, यह कंट्रोल किया जा सकता है कि कॉन्टेंट को स्टीरियो में डाउनग्रेड किया जाए या नहीं (दो वैल्यू का इस्तेमाल करने पर) या फिर, चैनलों की मूल संख्या का इस्तेमाल करके आउटपुट दिया जा रहा है (जब बराबर वैल्यू का इस्तेमाल किया जा रहा हो या उससे बड़ा होना चाहिए). उदाहरण के लिए, छह या उससे बड़ी वैल्यू कॉन्फ़िगर होगी एक डिकोडर, जो 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 किलोहर्ट्ज़ (kHz) तक होना चाहिए.	3GPP (.3gp) MPEG-4 (.mp4, .m4a) ADTS रॉ AAC (.aac, ADIF काम नहीं करता) MPEG-TS (.ts, सीकेबल नहीं, सिर्फ़ डिकोड) Matroska (.mkv, सिर्फ़ डिकोड करना)
MPEG-4 HE AAC प्रोफ़ाइल (AAC+)	मोनो/स्टीरियो/5.0/5.1 कॉन्टेंट के साथ स्टैंडर्ड कॉन्टेंट उपलब्ध है किलोहर्ट्ज़ (kHz) से लेकर 16 किलोहर्ट्ज़ (KHz) तक के सैंपल की दर.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
MPEG-4 HE AACv2 प्रोफ़ाइल (बेहतर AAC+)	मोनो/स्टीरियो/5.0/5.1 कॉन्टेंट के साथ स्टैंडर्ड कॉन्टेंट उपलब्ध है सैंपल रेट 16 से 48 किलोहर्ट्ज़ (kHz) तक होना चाहिए.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
AAC ELD (बेहतर कम देरी AAC)	16 से लेकर 16 तक की मानक सैंपलिंग रेट के साथ मोनो/स्टीरियो कॉन्टेंट के लिए सहायता 48 किलोहर्ट्ज़.	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
यूएसएसी	मोनो/स्टीरियो कॉन्टेंट के लिए, 7.35 से स्टैंडर्ड सैंपलिंग रेट के साथ काम करता है 48 किलोहर्ट्ज़ तक.	MPEG-4 (.mp4, .m4a)
एएमआर-एनबी	4.75 से 12.2 केबीपीएस का सैंपल @ 8 किलोहर्ट्ज़ (kHz)	3GPP (.3gp)
एएमआर-डब्ल्यूबी	6.60 किलोहर्ट्ज़/सेकंड से 23.85 किलोहर्ट्ज़/सेकंड तक की 9 दरें, 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, सिर्फ़ डिकोड करना)
MIDI	एमआईडीआई टाइप 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,000, 16,000, 24,000, और 48,000 हर्ट्ज़.	ऑग (.ogg) MPEG-4 (.mp4, .m4a, सिर्फ़ डिकोड) मैट्रोस्का (.mkv) वेबम (.webm)
PCM/WAVE	PCM कोडेक को 16-बिट लीनियर PCM और 16-बिट फ़्लोट पर काम करना चाहिए. वेव एक्सट्रैक्टर, 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, 24,000, और 48,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

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

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

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

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

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

[C-0-1] जेपीईजी
[C-0-2] GIF
[C-0-3] PNG
[C-0-4] BMP
[C-0-5] WebP
[C-0-6] रॉ

अगर डिवाइस में एचईवीसी वीडियो डिकोड करने की सुविधा काम करती है, तो ये काम किए जा सकते हैं: * [C-1-1] HEIF (HEIC) इमेज को डिकोड करना ज़रूरी है.

इमेज डिकोडर जो ज़्यादा बिट-डेप्थ फ़ॉर्मैट (हर चैनल के लिए 9+ बिट) के साथ काम करते हैं:

[C-2-1] अनुरोध करने पर, 8-बिट के मिलते-जुलते फ़ॉर्मैट का आउटपुट देना ज़रूरी है ऐप्लिकेशन, उदाहरण के लिए, ARGB_8888 के ज़रिए android.graphics.Bitmap का कॉन्फ़िगरेशन.

5.1.6. इमेज कोडेक की जानकारी

फ़ॉर्मैट/कोडेक	जानकारी	इस्तेमाल किए जा सकने वाले फ़ाइल टाइप/कंटेनर फ़ॉर्मैट
JPEG	बेस+प्रोग्रेसिव	JPEG (.jpg)
GIF		GIF (.gif)
PNG		PNG (.png)
BMP		BMP (.bmp)
WebP फ़ॉर्मैट		WebP (.webp)
Raw		एआरडब्ल्यू (.arw), CR2 (.cr2), डीएनजी (.dng), NEF (.nef), एनआरडब्ल्यू (.nrw), ओआरएफ़ (.orf), पीईएफ़ (.pef), RAF (.raf), RW2 (.rw2), एसआरडब्ल्यू (.srw)
एचईआईएफ़	इमेज, इमेज कलेक्शन, इमेज क्रम	HEIF (.heif), HEIC (.heic)

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

[C-1-1] YUV420 8:8:8 सुविधाजनक रंग पर भी काम करना चाहिए फ़ॉर्मैट (COLOR_FormatYUV420Flexible) से CodecCapabilities तक.
[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] वीडियो एन्कोडर और डिकोडर को YUV420 8:8:8 सुविधाजनक रंग पर काम करना चाहिए फ़ॉर्मैट (COLOR_FormatYUV420Flexible) से CodecCapabilities तक.
[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 में OMX काम करता है. यह क्रॉस-प्लैटफ़ॉर्म मल्टीमीडिया ऐक्सेलरेशन एपीआई है, और साथ ही, कोडेक 2.0, एक लो-ओवरहेड मल्टीमीडिया एक्सेलरेटर एपीआई के साथ काम करते हैं.

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

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

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

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

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

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

5.1.10. मीडिया कोडेक के लिए कैरेक्टर बनाना

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

[C-1-1] को MediaCodecInfo एपीआई.

खास तौर पर:

[C-1-2] "OMX" से शुरू होने वाले नाम वाले कोडेक. OMX API का इस्तेमाल करना ज़रूरी है और ऐसे नाम रखें जो OMX IL नाम देने के दिशा-निर्देशों के मुताबिक हों.
[C-1-3] "c2" से शुरू होने वाले नाम वाले कोडेक. आपको कोडेक 2.0 एपीआई का इस्तेमाल करना होगा और ऐसे नाम हों जो 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. वीडियो एन्कोडिंग

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

दो स्लाइड वाली विंडो से ज़्यादा, बिटरेट से 15% से ज़्यादा नहीं होनी चाहिए के बीच सेट कर सकते हैं.
स्लाइड करने वाली विंडो पर, बिटरेट को 100% से ज़्यादा नहीं होना चाहिए 1 सेकंड का समय.

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

अगर डिवाइस लागू करने की रिपोर्ट, 720p या 1080p के लिए H.264 एन्कोडिंग की सुविधा देती है मीडिया एपीआई के ज़रिए रिज़ॉल्यूशन वीडियो अपलोड करते हैं, तो वे:

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

	एसडी (हल्की क्वालिटी)	एसडी (अच्छी क्वालिटी)	एचडी 720 पिक्सल	एचडी 1080 पिक्सल
वीडियो रिज़ॉल्यूशन	320 x 240 पिक्सल	720 x 480 पिक्सल	1280 x 720 पिक्सल	1920 x 1080 पिक्सल
वीडियो फ़्रेम रेट	20 एफ़पीएस (फ़्रेम प्रति सेकंड)	30 एफ़पीएस (फ़्रेम प्रति सेकंड)	30 एफ़पीएस (फ़्रेम प्रति सेकंड)	30 एफ़पीएस (फ़्रेम प्रति सेकंड)
वीडियो बिटरेट	384 केबीपीएस	2 एमबीपीएस	4 एमबीपीएस	10 एमबीपीएस

5.2.3. वीपी8

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

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

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

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

	एसडी (हल्की क्वालिटी)	एसडी (अच्छी क्वालिटी)	एचडी 720 पिक्सल	एचडी 1080 पिक्सल
वीडियो रिज़ॉल्यूशन	320 x 180 पिक्सल	640 x 360 पिक्सल	1280 x 720 पिक्सल	1920 x 1080 पिक्सल
वीडियो फ़्रेम रेट	30 एफ़पीएस (फ़्रेम प्रति सेकंड)	30 एफ़पीएस (फ़्रेम प्रति सेकंड)	30 एफ़पीएस (फ़्रेम प्रति सेकंड)	30 एफ़पीएस (फ़्रेम प्रति सेकंड)
वीडियो बिटरेट	800 केबीपीएस	2 एमबीपीएस	4 एमबीपीएस	10 एमबीपीएस

5.2.4. वीपी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] वीडियो के डाइनैमिक रिज़ॉल्यूशन और फ़्रेम रेट पर स्विच करने की सुविधा काम करनी चाहिए में स्टैंडर्ड Android API का इस्तेमाल करके, एक ही स्ट्रीम में सभी VP8, VP9, H.264 और H.265 कोडेक रीयल टाइम में और ज़्यादा से ज़्यादा रिज़ॉल्यूशन तक काम कर सकते हैं डिवाइस पर हर कोडेक के हिसाब से फ़िल्टर करें.

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

अगर Display.getSupportedModes() तरीके से रिपोर्ट की गई ऊंचाई बराबर है या वीडियो रिज़ॉल्यूशन से ज़्यादा है, तो:

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

	एसडी (हल्की क्वालिटी)	एसडी (अच्छी क्वालिटी)	एचडी 720 पिक्सल	एचडी 1080 पिक्सल
वीडियो रिज़ॉल्यूशन	320 x 180 पिक्सल	640 x 360 पिक्सल	1280 x 720 पिक्सल	1920 x 1080 पिक्सल
वीडियो फ़्रेम रेट	30 एफ़पीएस (फ़्रेम प्रति सेकंड)	30 एफ़पीएस (फ़्रेम प्रति सेकंड)	30 FPS (60 FPS)^{टेलिविज़न})	30 (60 एफ़पीएस (फ़्रेम प्रति सेकंड)^{टेलीविज़न})
वीडियो बिटरेट	800 केबीपीएस	2 एमबीपीएस	8 एमबीपीएस	20 एमबीपीएस

5.3.7. वीपी9

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

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

अगर लागू करने के लिए डिवाइस, VP9 कोडेक और हार्डवेयर डिकोडर के साथ काम करते हैं, तो:

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

[C-3-1] डिवाइस पर कम से कम एक 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 एमबीपीएस

अगर डिवाइस लागू करने की प्रोसेस, VP9Profile2 या VP9Profile3 के साथ काम करने का दावा करती है 'CodecProfilelevel' के ज़रिए मीडिया एपीआई:

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

अगर डिवाइस लागू करने के तरीके में एचडीआर प्रोफ़ाइल (VP9Profile2HDR, VP9Profile2HDR10Plus, VP9Profile3HDR, VP9Profile3HDR10Plus) से मीडिया एपीआई:

[C-4-1] डिवाइस पर एचडीआर क्वालिटी के वीडियो अपलोड करने के लिए, ज़रूरी मेटाडेटा स्वीकार करना ज़रूरी है (KEY_HDR_STATIC_INFO एचडीआर प्रोफ़ाइलों और 'KEY_HDR10_PLUS_INFO' HDR10Plus प्रोफ़ाइलों के लिए) से हटा दें. उन्हें समाचार रिपोर्ट से जानकारी हासिल करने और बिटस्ट्रीम और/या कंटेनर से ज़रूरी एचडीआर मेटाडेटा चाहिए.
[C-4-2] डिवाइस को लागू करने के लिए, एचडीआर क्वालिटी के वीडियो को डिवाइस की स्क्रीन पर या किसी स्टैंडर्ड वीडियो आउटपुट पोर्ट पर (जैसे, एचडीएमआई).

5.3.8. Dolby Vision

अगर डिवाइस लागू करने की प्रक्रिया में यह एलान किया जाता है कि वह Dolby Vision डिकोडर के साथ काम करेगा HDR_TYPE_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 एपीआई का पालन करना ज़रूरी है साथ ही, डिवाइस पर उपलब्ध माइक्रोफ़ोन के लिए जानकारी ठीक से भरें के द्वारा तृतीय-पक्ष ऐप्लिकेशन के लिए पहुंच AudioManager.getMicrophones() API, जिसका उपयोग कर सक्रिय AudioRecord के लिए किया जा सकता है 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 ऑडियो सोर्स से एक ऑडियो स्ट्रीम.
डाइमेंशन और फ़्रीक्वेंसी की तुलना में, करीब-करीब सपाट होना चाहिए मिड-फ़्रीक्वेंसी रेंज में: खास तौर पर ±3dB, हर एक के लिए 100 हर्ट्ज़ से लेकर 4000 हर्ट्ज़ तक और आवाज़ की पहचान करने वाले ऑडियो स्रोत को रिकॉर्ड करने के लिए इस्तेमाल किया जाने वाला हर माइक्रोफ़ोन.
[C-SR-1] का बहुत ज़्यादा सुझाव दिया जाता है, ताकि आयाम के लेवल को सबसे कम स्तर पर दिखाया जा सके फ़्रीक्वेंसी रेंज: खास तौर पर, फ़्रीक्वेंसी रेंज: 30 हर्ट्ज़ से 100 हर्ट्ज़ तक ±20 dB आवाज़ रिकॉर्ड करने के लिए इस्तेमाल किए जाने वाले हर माइक्रोफ़ोन के लिए, औसत फ़्रीक्वेंसी रेंज की पहचान करने वाला ऑडियो सोर्स.
[C-SR-2] का बहुत ज़्यादा सुझाव दिया जाता है, ताकि ऊंचाई में आयाम के स्तर को दिखाया जा सके फ़्रीक्वेंसी रेंज: खास तौर पर ±30 dB से लेकर 4000 हर्ट्ज़ से लेकर 22 किलोहर्ट्ज़ तक की आवाज़ रिकॉर्ड करने के लिए इस्तेमाल किए जाने वाले हर माइक्रोफ़ोन के लिए, औसत फ़्रीक्वेंसी रेंज की पहचान करने वाला ऑडियो सोर्स.
ऑडियो इनपुट की संवेदनशीलता को इस तरह सेट करना चाहिए कि 1000 हर्ट्ज़ का साइनसॉइडल टोन सोर्स हो 90 dB साउंड प्रेशर लेवल (एसपीएल) पर चलाया गया (माइक्रोफ़ोन के बगल में मापा जाता है) 16 के लिए 1770 और 3530 की रेंज में RMS 2500 का आदर्श रिस्पॉन्स मिलता है बिट-सैंपल (या -22.35 db ±3dB फ़्लोटिंग पॉइंट/डबल प्रिसिज़न के लिए फ़ुल स्केल नमूने) के रूप में) ऑडियो सोर्स.
आवाज़ की पहचान करने वाली ऑडियो स्ट्रीम को रिकॉर्ड करना चाहिए, ताकि पीसीएम का आयाम बढ़ सके लेवल, इनपुट एसपीएल में -18 से कम से कम 30 dB रेंज में रैखिक रूप से बदलाव करते हैं माइक्रोफ़ोन पर, dB से +12 dB re 90 dB SPL.
आवाज़ की पहचान करने वाली ऑडियो स्ट्रीम को टोटल हारमोनिक के साथ रिकॉर्ड करना चाहिए डिस्टॉर्शन (टीएचडी), 90 dB SPL इनपुट स्तर पर 1 किलोहर्ट्ज़ के लिए 1% से कम माइक्रोफ़ोन.

अगर डिवाइस पर लागू होने वाले 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 API का इस्तेमाल करता है ऑडियो सोर्स अपलोड करता है, यह इन छोड़कर अन्य सभी ऑडियो स्ट्रीम का मिक्स कैप्चर करता है:
- AudioManager.STREAM_RING
- AudioManager.STREAM_ALARM
- AudioManager.STREAM_NOTIFICATION

5.4.4. अकूस्टिक इको रद्द करने वाला

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

अकूस्टिक इको रद्द करने वाला टूल लागू करना चाहिए (AEC) टेक्नोलॉजी को वॉइस कम्यूनिकेशन के लिए इस्तेमाल किया गया है और यह कैप्चर पाथ पर लागू की गई है AudioSource.VOICE_COMMUNICATION का इस्तेमाल करके कैप्चर करते समय.

अगर डिवाइस लागू करने के तरीके से अकूस्टिक इको रद्द करने की सुविधा मिलती है, AudioSource.VOICE_COMMUNICATION के दौरान कैप्चर ऑडियो पाथ में डाला गया चुना जाता है, तो वे:

इसकी जानकारी AcousticEchoCanceler के ज़रिए देने के लिए, [C-SR-1] का STRONGLY_ रोका गया होता है एपीआई का तरीका AcousticEchoCanceler.isAvailable()
[C-SR-2] इस ऑडियो असर को AcousticEchoCanceler की मदद से कंट्रोल किया जा सकता है एपीआई.
[C-SR-3] हर AEC टेक्नोलॉजी की खास तौर से पहचान करने के लिए STRONGLY_ एल्बम को इस्तेमाल किया जाता है ऑडियो इफ़ेक्ट.Descriptor.uuid का इस्तेमाल करके लागू करना फ़ील्ड में डालें.

5.4.5. समवर्ती कैप्चर

अगर डिवाइस लागू करने के तरीके के बारे में android.hardware.microphone का एलान किया गया है,तो उन्हें ज़रूरी है 'एक साथ कैप्चर करें' सुविधा लागू करने के लिए इस दस्तावेज़ में बताया गया है. खास तौर से:

[C-1-1] सुलभता सुविधाओं का इस्तेमाल करके, माइक्रोफ़ोन को एक साथ ऐक्सेस करने की अनुमति दी जानी चाहिए AudioSource.VOICE_RECOGNITION और कम से कम एक के साथ सर्विस कैप्चर कर रहा है किसी भी AudioSource के साथ ऐप्लिकेशन कैप्चर करने की सुविधा मिलती है.
[C-1-2] पहले से इंस्टॉल किए गए किसी डिवाइस से, माइक्रोफ़ोन को एक साथ ऐक्सेस करने की अनुमति दी जानी चाहिए ऐसा ऐप्लिकेशन जिसमें Assistant की भूमिका हो और कम से कम एक ऐप्लिकेशन हो इसे छोड़कर किसी भी AudioSource के साथ कैप्चर कर रहा है AudioSource.VOICE_COMMUNICATION या AudioSource.CAMCORDER.
[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-बिट, फ़्लोट
- चैनल: मोनो, स्टीरियो, मान्य मल्टीचैनल कॉन्फ़िगरेशन ज़्यादा से ज़्यादा आठ चैनलों की सुविधा
- सैंपलिंग रेट (हर्ट्ज़ में):
  - चैनल पर 8000, 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] EFFECT_TYPE_EQUALIZER और EFFECT_TYPE_LOUDNESS_ENHANCER लागू करने की सुविधा को इनके ज़रिए कंट्रोल किया जा सकता है ऑडियो इफ़ेक्ट की सब-क्लास, Equalizer और LoudnessEnhancer हैं.
[C-1-2] विज़ुअलाइज़र टूल का इस्तेमाल करने के लिए, एपीआई को इसके ज़रिए कंट्रोल किया जा सकता है Visualizer क्लास.
[C-1-3] EFFECT_TYPE_DYNAMICS_PROCESSING को लागू करने में मदद करनी चाहिए ऑडियो इफ़ेक्ट सब-क्लास DynamicsProcessing के ज़रिए कंट्रोल किया जा सकता है.
EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB और EFFECT_TYPE_VIRTUALIZER लागू करने का तरीका AudioEffect सब-क्लास की मदद से कंट्रोल किया जा सकता हैBassBoost, EnvironmentalReverb, PresetReverb, और Virtualizer.
[C-SR-1] फ़्लोटिंग-पॉइंट में इफ़ेक्ट इस्तेमाल करने के लिए, इस बात का खास तौर पर सुझाव दिया जाता है कि मल्टीचैनल.

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

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

ऑडियो वॉल्यूम अडजस्ट करने की अनुमति देनी चाहिए कॉन्टेंट के टाइप या इस्तेमाल के हिसाब से, हर ऑडियो स्ट्रीम के हिसाब से अलग-अलग किया जा सकता है AudioAttributes की ओर से और कार ऑडियो का इस्तेमाल, जैसा कि android.car.CarAudioManager में सार्वजनिक तौर पर बताया गया है.

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

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

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

5.6. ऑडियो के लिए इंतज़ार का समय

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

इस सेक्शन के लिए, इन परिभाषाओं का इस्तेमाल करें:

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

[C-SR-5] इंतज़ार का समय कम होने पर, इसकी शिकायत करने का सुझाव दिया जाता है. इसके लिए: android.hardware.audio.low_latency फ़ीचर फ़्लैग.
[C-SR-6] इंतज़ार का समय कम करने की ज़रूरी शर्तों को पूरा करने के लिए, इसका बहुत ज़्यादा सुझाव दिया जाता है AAudio API से ऑडियो ऐक्सेस किया जा सकता है.
[C-SR-7] का सुझाव इसलिए दिया जाता है, ताकि उन स्ट्रीम के लिए भी यह पक्का किया जा सके जो पहले AAUDIO_PERFORMANCE_MODE_LOW_LATENCY AAudioStream_getPerformanceMode() से, AAudioStream_getFramesPerBurst() से मिला मान android.media.AudioManager.getProperty(String) से मिलने वाले मान से कम या उसके बराबर है प्रॉपर्टी कुंजी AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER के लिए.

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

[C-2-1] 'वीडियो स्ट्रीम होने और उसके दिखने के समय का अंतर कम होने पर' सुविधा के साथ काम नहीं करना चाहिए.

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

[C-3-1] इनपुट के टाइमस्टैंप में गड़बड़ी को सीमित करें, जैसा कि ऑडियो रिकॉर्ड.गेटटाइमस्टैंप या AAudioStream_getTimestamp से +/- 2 मि॰से॰ तक. "गड़बड़ी" यहां सही वैल्यू से विचलन का मतलब है.
[C-3-2] 500 मिलीसेकंड की कोल्ड इनपुट इंतज़ार का समय या कम.
[C-3-3] AAudioStreamBuilder_openStream() का इस्तेमाल करके इनपुट स्ट्रीम खोलना ज़रूरी है 1000 मिलीसेकंड से कम समय लेता है.

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

[C-SR-8] माइक्रोफ़ोन पर 100 मिलीसेकंड या उससे कम कोल्ड इनपुट इंतज़ार का समय डेटा पाथ.
[C-SR-11] इनपुट के टाइमस्टैंप में गड़बड़ी को सीमित करें, जैसा कि ऑडियो रिकॉर्ड.गेटटाइमस्टैंप या AAudioStream_getTimestamp, से +/- 1 मि॰से॰ तक.

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

[C-SR-12] का खास तौर पर सुझाव दिया जाता है कि दोतरफ़ा यात्रा का औसत समय लेने के लिए 50 मिलीसेकंड या 5 से कम मापों का, मीन ऐब्सॉल्यूट डेविएशन के साथ 10 मि॰से॰ से कम, कम से कम एक मान्य पाथ से ज़्यादा.

5.7. नेटवर्क प्रोटोकॉल

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

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

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

मीडिया सेगमेंट के फ़ॉर्मैट

सेगमेंट के फ़ॉर्मैट	संदर्भ	आवश्यक कोडेक समर्थन
MPEG-2 ट्रांसपोर्ट स्ट्रीम	आईएसओ 13818	वीडियो कोडेक: H264 एवीसी एमपीईजी-4 एसपी MPEG-2 H264 एवीसी, MPEG2-4 SP, के बारे में ज़्यादा जानकारी के लिए सेक्शन 5.1.8 देखें और MPEG-2. ऑडियो कोडेक: AAC AAC और उसके वैरिएंट के बारे में जानकारी के लिए, सेक्शन 5.1.3 देखें.
ADTS फ़्रेमिंग और ID3 टैग के साथ AAC	आईएसओ 13818-7	सेक्शन 5.1.1 देखें AAC और इसके प्रकारों की जानकारी के लिए
WebVTT	WebVTT

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

संदर्भ

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

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

आईएसओ 13818

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

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

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

ऑडियो कोडेक:

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

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

आईएसओ 13818-7

सेक्शन 5.1.1 देखें AAC और इसके प्रकारों की जानकारी के लिए

WebVTT

आरटीएसपी (आरटीपी, एसडीपी)

प्रोफ़ाइल का नाम	संदर्भ	आवश्यक कोडेक समर्थन
H264 एवीसी	आरएफ़सी 6184	सेक्शन 5.1.8 देखें H264 एवीसी के बारे में जानकारी
MP4A-एलएटीएम	आरएफ़सी 6416	सेक्शन 5.1.3 देखें AAC और इसके प्रकारों की जानकारी के लिए
H263-1998	आरएफ़सी 3551 आरएफ़सी 4629 आरएफ़सी 2190	सेक्शन 5.1.8 देखें H263 पर जानकारी के लिए
H263-2000 की उम्र	आरएफ़सी 4629	सेक्शन 5.1.8 देखें H263 पर जानकारी के लिए
एएमआर	आरएफ़सी 4867	सेक्शन 5.1.3 देखें एएमआर-एनबी पर जानकारी के लिए
एएमआर-डब्ल्यूबी	आरएफ़सी 4867	सेक्शन 5.1.3 देखें एएमआर-डब्ल्यूबी पर जानकारी के लिए
एमपी4वी-ईएस	आरएफ़सी 6416	सेक्शन 5.1.8 देखें MPEG-4 SP के बारे में जानकारी के लिए
mpeg4-जेनरिक	आरएफ़सी 3640	सेक्शन 5.1.3 देखें AAC और इसके प्रकारों की जानकारी के लिए
एमपी2टी	आरएफ़सी 2250	ज़्यादा जानकारी के लिए, एचटीटीपी लाइव स्ट्रीमिंग के नीचे MPEG-2 ट्रांसपोर्ट स्ट्रीम देखें

5.8. सुरक्षित मीडिया

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

[C-1-1] Display.FLAG_SECURE के लिए सहायता का एलान करना ज़रूरी है.

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

[C-2-1] लिंक को क्रिप्टोग्राफ़िक तरीके से मज़बूत बनाने के लिए, वायरलेस प्रोटोकॉल से कनेक्ट किए गए डिसप्ले के लिए, HDCP 2.x या उसके बाद के वर्शन के तौर पर जैसे कि Miracast.

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

[C-3-1] कनेक्ट किए गए सभी बाहरी डिसप्ले के लिए, एचडीसीपी 1.2 या उसके बाद के वर्शन पर काम करना ज़रूरी है वायर वाले पोर्ट के ज़रिए ऐक्सेस करें.

5.9. म्यूज़िकल इंस्ट्रुमेंट डिजिटल इंटरफ़ेस (एमआईडीआई)

अगर डिवाइस लागू करने की प्रोसेस, सुविधा android.software.midi के लिए सहायता को रिपोर्ट करती है के ज़रिए android.content.pm.PackageManager क्लास में शामिल करते हैं, वे:

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

5.10. प्रोफ़ेशनल ऑडियो

अगर डिवाइस, किसी सुविधा को लागू करने के लिए रिपोर्ट पर काम करता है, तो android.hardware.audio.pro को android.content.pm.PackageManager क्लास में शामिल करते हैं, वे:

[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_PERFORMANCE_MODE_LOW_LATENCY.
[C-1-6] कोल्ड आउटपुट के लिए इंतज़ार का समय 200 मिलीसेकंड या इससे कम होना चाहिए.
[C-1-7] कोल्ड इनपुट इंतज़ार का समय 200 मिलीसेकंड या इससे कम होना चाहिए.
[C-1-8] टैप-टू-टोन के इंतज़ार का औसत समय 80 मिलीसेकंड या इससे कम होना चाहिए स्पीकर से माइक्रोफ़ोन डेटा पाथ के लिए, कम से कम पांच से ज़्यादा मापे गए हों.
[C-SR-1] सेक्शन में बताई गई इंतज़ार के समय को पूरा करने के लिए, इस बात का खास तौर पर सुझाव दिया जाता है 5.6 ऑडियो के लिए इंतज़ार का समय, 20 मिलीसेकंड या कम, 5 से कम मीन ऐब्सलूट डेविएशन के साथ 5 से ज़्यादा मेज़रमेंट मिलीसेकंड पर, स्पीकर से माइक्रोफ़ोन पाथ पर.
[C-SR-2] का सुझाव दिया जाता है, ताकि Pro Audio की ज़रूरी शर्तों को पूरा किया जा सके लगातार दोतरफ़ा यात्रा के ऑडियो के इंतज़ार का समय, कोल्ड इनपुट इंतज़ार का समय, और कोल्ड आउटपुट Aऑडियो नेटिव ऑडियो एपीआई का इस्तेमाल करने के दौरान इंतज़ार का समय और यूएसबी ऑडियो से जुड़ी ज़रूरतें पर क्लिक करें.
[C-SR-3] सीपीयू का एक जैसा लेवल देने के लिए, इसका बहुत ज़्यादा सुझाव दिया जाता है की परफ़ॉर्मेंस, जब ऑडियो चालू हो और सीपीयू के लोड में बदलाव हो रहा हो. इसकी जांच की जानी चाहिए Android ऐप्लिकेशन SynthMark का इस्तेमाल करके ऐसा किया जा सकता है. SynthMark, सिम्युलेटेड ऑडियो फ़्रेमवर्क पर चलने वाले सॉफ़्टवेयर सिंथेसाइज़र का इस्तेमाल करता है जो सिस्टम की परफ़ॉर्मेंस का आकलन करता है. ज़्यादा जानकारी के लिए, SynthMark दस्तावेज़ ताकि बेंचमार्क की जानकारी मिल सके. द सिंथमार्क ऐप्लिकेशन को चलाने के लिए “ऑटोमेटेड टेस्ट” विकल्प का इस्तेमाल करके और ये नतीजे पाएं:
- Voicemark.90 >= 32 आवाज़ें
- Latitudemark.fixed.little <= 15 मि॰से॰
- लेटेंसीमार्क.डाइनैमिक.लिटल <= 50 मि॰से॰
ऑडियो क्लॉक की गलतियों को कम से कम करना चाहिए और स्टैंडर्ड समय के हिसाब से ड्रिफ़्ट होना चाहिए.
CLOCK_MONOTONIC सीपीयू के मुकाबले ऑडियो क्लॉक ड्रिफ़्ट कम होनी चाहिए जब दोनों चालू हों.
डिवाइस पर मौजूद ट्रांसड्यूसर से, ऑडियो में देरी को कम किया जाना चाहिए.
USB डिजिटल ऑडियो पर ऑडियो प्रतीक्षा अवधि को कम करना चाहिए.
सभी पाथ के लिए, आवाज़ के इंतज़ार के समय को रिकॉर्ड करना चाहिए.
ऑडियो बफ़र को पूरा करने के लिए, कॉलबैक एंट्री के समय में सिग्नल में गड़बड़ी कम होनी चाहिए, क्योंकि यह कॉलबैक से, पूरे सीपीयू बैंडविथ के इस्तेमाल किए जा सकने वाले प्रतिशत पर असर पड़ता है.
रिपोर्ट की गई इंतज़ार के समय के लिए, सामान्य इस्तेमाल के दौरान ऑडियो में कोई ग्लिच नहीं होनी चाहिए.
एक चैनल से दूसरे चैनल पर वीडियो अपलोड होने और उसके दिखने के बीच इंतज़ार के समय के अंतर का कोई अंतर नहीं होना चाहिए.
सभी ट्रांसपोर्ट के लिए, एमआईडीआई का मतलब कम से कम होना चाहिए.
सभी ट्रांसपोर्ट में, लोड (जीटर) में एमआईडीआई में देरी में होने वाले उतार-चढ़ाव को कम करना चाहिए.
सभी ट्रांसपोर्ट के लिए, एमआईडीआई के सटीक टाइमस्टैंप देने चाहिए.
डिवाइस पर मौजूद ट्रांसड्यूसर पर ऑडियो सिग्नल के शोर को कम करना चाहिए. इसमें ये भी शामिल हैं कोल्ड स्टार्ट के तुरंत बाद की अवधि.
इसके इनपुट और आउटपुट हिस्से में ऑडियो क्लॉक का कोई अंतर नहीं होना चाहिए जब दोनों चालू हों, तब संबंधित एंड-पॉइंट. संगत के उदाहरण एंड-पॉइंट में, डिवाइस में मौजूद माइक्रोफ़ोन और स्पीकर या ऑडियो जैक इनपुट शामिल होते हैं और आउटपुट.
इनपुट और आउटपुट साइड के लिए, ऑडियो बफ़र को पूरा करने वाले कॉलबैक को हैंडल करना चाहिए जब दोनों सक्रिय हों, तो एक ही थ्रेड पर संबंधित समाप्ति-बिंदुओं के और फिर इनपुट कॉलबैक से वापस आने के तुरंत बाद, आउटपुट कॉलबैक करें. या अगर एक ही थ्रेड पर कॉलबैक मैनेज करना संभव नहीं है, तो इनपुट कॉलबैक डालने के तुरंत बाद, आउटपुट कॉलबैक ताकि इनपुट और आउटपुट साइड का एक ही समय सेट किया जा सके.
इनपुट के लिए HAL ऑडियो बफ़रिंग के बीच के फ़ेज़ के अंतर को कम करना चाहिए और संबंधित एंड-पॉइंट के आउटपुट पक्ष भी शामिल होते हैं.
इसलिए, स्क्रीन पर टच होने में लगने वाले समय को कम किया जाना चाहिए.
लोड में टच इंतज़ार के समय में उतार-चढ़ाव को कम किया जाना चाहिए (जीटर).

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

[C-SR-4] सुविधा के साथ काम करने की जानकारी देने का सुझाव दिया जाता है android.hardware.audio.pro, android.content.pm.PackageManager से होकर क्लास.

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

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

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

[C-3-1] यूएसबी ऑडियो क्लास लागू करना ज़रूरी है.
[C-3-2] यह ज़रूरी है कि लगातार दोतरफ़ा यात्रा के दौरान ऑडियो के लिए इंतज़ार का समय 25 मिलीसेकंड या उससे कम, मीन ऐब्सॉल्यूट डेविएशन के साथ पांच से ज़्यादा मेज़रमेंट यूएसबी ऑडियो क्लास का इस्तेमाल करके, यूएसबी होस्ट मोड पोर्ट पर 5 मिलीसेकंड से कम. (इसे यूएसबी-3.5 मि॰मी॰ के अडैप्टर और ऑडियो लूपबैक का इस्तेमाल करके मापा जा सकता है डोंगल या पैच केबल के साथ यूएसबी ऑडियो इंटरफ़ेस का इस्तेमाल करके आउटपुट के लिए इनपुट).
[C-SR-6] इस बात का सुझाव दिया जाता है कि एक साथ आठ चैनल इस्तेमाल किए जा सकें हर दिशा में, 96 किलोहर्ट्ज़ (kHz) सैंपल रेट, और 24-बिट या 32-बिट की गहराई, इस्तेमाल करने पर साथ ही, ऐसे यूएसबी ऑडियो सहायक डिवाइस (जैसे, कीबोर्ड, माउस, मॉनिटर, वेबकैम वगैरह) हैं जो इन ज़रूरी शर्तों को भी पूरा करते हैं.
[C-SR-7] का इस्तेमाल करने की सलाह दी जाती है, ताकि वे इस ग्रुप की ज़रूरी शर्तों को पूरा कर सकें. MMAP पाथ पर Aऑडियो नेटिव ऑडियो एपीआई.

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

स्टीरियो और आठ चैनलों में 20-बिट पर आउटपुट का काम करना चाहिए या 24-बिट की गहराई और 192 किलोहर्ट्ज़ (KHz) के लिए, बिट-डेप्थ के नुकसान या रीसैंपलिंग के बिना, कम से कम एक कॉन्फ़िगरेशन में.

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_UNYYYY.
[C-1-2] में, डाइमेंशन और फ़्रीक्वेंसी के सपाट होने का डेटा दिखाया जाना चाहिए औसत फ़्रीक्वेंसी रेंज में शामिल विशेषताएं: खास तौर पर, ±10 dB प्रोसेस न किए गए हर माइक्रोफ़ोन को रिकॉर्ड करने के लिए, इस्तेमाल किए जाने वाले हर माइक्रोफ़ोन के लिए 100 हर्ट्ज़ से 7,000 हर्ट्ज़ तक ऑडियो सोर्स.
[C-1-3] यह ज़रूरी है कि आयाम के लेवल कम फ़्रीक्वेंसी में दिखाए जाएं रेंज: खास तौर पर, 5 z से 100 हर्ट्ज़ तक की रेंज में को रिकॉर्ड करने के लिए इस्तेमाल किए जाने वाले हर माइक्रोफ़ोन के लिए मिड-फ़्रीक्वेंसी रेंज प्रोसेस नहीं किया गया ऑडियो सोर्स.
[C-1-4] ऐसा होना चाहिए कि बहुत ज़्यादा फ़्रीक्वेंसी पर, ऐम्प्लीट्यूड लेवल दिखाए रेंज: खास तौर पर 7000 हर्ट्ज़ से 22 किलोहर्ट्ज़ तक की रेंज को रिकॉर्ड करने के लिए इस्तेमाल किए जाने वाले हर माइक्रोफ़ोन के लिए मिड-फ़्रीक्वेंसी रेंज प्रोसेस नहीं किया गया ऑडियो सोर्स.
[C-1-5] ऑडियो इनपुट की संवेदनशीलता को 1000 हर्ट्ज़ पर सेट करें 94 dB साउंड प्रेशर लेवल (SPL) पर चलाए जाने वाले टोन के सोर्स के साथ, 16 बिट-सैंपल या फ़्लोटिंग पॉइंट/डबल के लिए -36 dB फ़ुल स्केल के लिए 520 का आरएमएस प्रोसेस न किए गए हर माइक्रोफ़ोन को रिकॉर्ड करने के लिए इस्तेमाल किए जाने वाले हर माइक्रोफ़ोन के लिए सटीक सैंपल) ऑडियो सोर्स.
[C-1-6] यह ज़रूरी है कि सिग्नल-टू-नॉइज़ रेशियो (एसएनआर) 60 dB या इससे ज़्यादा हो प्रोसेस नहीं किए गए ऑडियो सोर्स को रिकॉर्ड करने के लिए इस्तेमाल किया जाने वाला हर माइक्रोफ़ोन. (वहीं एसएनआर को 94 dB SPL और इसके बराबर के अंतर के तौर पर मापा जाता है सेल्फ़ नॉइज़, A-वेटेड) का एसपीएल.
[C-1-7] टोटल हारमोनिक डिस्टॉर्शन (टीएचडी), इससे कम होना चाहिए इस्तेमाल किए जाने वाले हर माइक्रोफ़ोन पर 90 dB SPL इनपुट लेवल पर 1 kHZ के लिए 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, बाइटबफ़र). Android 13 में, P010 को आराम से कंट्रोल किया गया है, ताकि Y के लिए आर्बिट्रेरी तरीके से आगे-पीछे किया जा सके और यूवी प्लेन.
[C-1-2] P010 आउटपुट बफ़र को जीपीयू से सैंपल किया जा सके (जब यह भी तय किया गया है कि जीपीयू_SAMPLING का इस्तेमाल कैसे किया जाता है. इससे जीपीयू कंपोज़िशन और कस्टम सेटिंग चालू हो जाती है ऐप्लिकेशन की टोन मैपिंग के हिसाब से.

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

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

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

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

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

[C-4-1] इनपुट प्लैटफ़ॉर्म और सीपीयू (CPU) के लिखे जाने लायक फ़ॉर्मैट के लिए 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 डिकोडर को कैप्चर की गई स्ट्रीम को एसडीआर में डिकोड करने के लिए.

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

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

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

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

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

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

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

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

6.1. डेवलपर टूल

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

[C-0-1] Android डिवाइस में मौजूद Android डेवलपर टूल पर काम करना चाहिए SDK टूल.
Android डीबग ब्रिज (adb)
- [C-0-2] Android SDK और शेल में बताए गए दस्तावेज़ के मुताबिक adb पर काम करना चाहिए AOSP में दिए गए कमांड का इस्तेमाल करें. इनका इस्तेमाल ऐप्लिकेशन डेवलपर कर सकते हैं, dumpsys सहित cmd stats
- [C-0-11] शेल कमांड cmd testharness काम करना चाहिए. अपग्रेड किया जा रहा है Android के पुराने वर्शन से इस तरह के डिवाइसों को लागू करना: परसिस्टेंट डेटा ब्लॉक को C-0-11 से छूट दी जा सकती है.
- [C-0-3] डिवाइस के सिस्टम के फ़ॉर्मैट या कॉन्टेंट में बदलाव नहीं करना चाहिए इवेंट (बैटरीस्टेट , डिस्कस्टेट, फ़िंगरप्रिंट, ग्राफ़िक्सस्टैट, नेटस्टेट, सूचना, Procstats) को dumpsys आदेश के ज़रिए लॉग किया गया.
- [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 चालू करता है.
- [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 डिफ़ॉल्ट रूप से बंद होना चाहिए और यह ज़रूरी है कि उपयोगकर्ता उसे ऐक्सेस कर सके सिस्टम को चालू करने का तरीका बताएंगे.
परफ़ेटो
- [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] इसके लिए true वापस करना होगा: ActivityManager.isRunningInUserTestHarness()
- [C-2-2] टेस्ट हार्नेस मोड को इस तरह लागू करना ज़रूरी है टेस्ट के हार्नेस मोड के दस्तावेज़.
जीपीयू के काम से जुड़ी जानकारी

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

अगर डिवाइस, android.hardware.vulkan.version फ़ीचर फ़्लैग हैं, वे:

[C-1-1] ऐप्लिकेशन डेवलपर को यह सुविधा देनी होगी कि वे इस सुविधा को चालू या बंद कर सकें जीपीयू डीबग लेयर.
[C-1-2] ज़रूरी है कि जीपीयू डीबग लेयर चालू होने पर, लेयर की गिनती बाहरी टूल से उपलब्ध कराई गई लाइब्रेरी (जो प्लैटफ़ॉर्म का हिस्सा नहीं हैं या ऐप्लिकेशन पैकेज) डीबग करने योग्य ऐप्लिकेशन में मिला बेस डायरेक्ट्री इसके साथ काम करता है vkEnomerateInstancelayerProperties() का इस्तेमाल किया जा सकता है और 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] डिवाइस लागू करने के लिए लगातार सटीक हार्डवेयर की रिपोर्ट ज़रूरी है कॉन्फ़िगरेशन की जानकारी को getSystemAvailableFeatures() और hasSystemFeature(String) तरीके से android.content.pm.PackageManager क्लास का इस्तेमाल करें.

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

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.screenLayout से लेआउट का साइज़ और Configuration.smallestScreenWidthDp.

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

[C-0-1] आपको Configuration.screenLayout के बारे में जानकारी, Android SDK के दस्तावेज़ में दी गई है. खास तौर पर, लागू करने के लिए डिवाइस को सही तरीके से रिपोर्ट करना ज़रूरी है डेंसिटी-इंडिपेंडेंट पिक्सल (डीपी) स्क्रीन डाइमेंशन की जानकारी नीचे दी गई है:
- Configuration.uiMode वाले डिवाइस, इनके अलावा किसी भी दूसरी वैल्यू पर सेट किए गए हैं और इसके लिए small आकार की रिपोर्ट कर रहा है: Configuration.screenLayout, कम से कम 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] ऐप्लिकेशन का सही तरीके से पालन करना ज़रूरी है' बताया गया <supports-screens> तक स्क्रीन के साइज़ के हिसाब से विशेषता को AndroidManifest.xml में, जैसा बताया गया है, देखें.
इसमें Android के साथ काम करने वाले ऐसे डिसप्ले हो सकते हैं जिनके कोने गोल हों.

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

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

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

[C-2-1] एक्सटेंशन एपीआई या साइडकार एपीआई का स्टेबल वर्शन इसका इस्तेमाल Window Manager Jetpack लाइब्रेरी में किया जा सकता है.

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

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

साइडकार या एक्सटेंशन API को सही ढंग से लागू करने के विवरण के लिए यहां जाएं 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] डिफ़ॉल्ट रूप से, डिवाइस को लागू करने के लिए Android फ़्रेमवर्क की सघनता DisplayMetrics DENSITY_DEVICE_STABLE API के ज़रिए और यह वैल्यू कभी भी नहीं बदलनी चाहिए; हालांकि, डिवाइस डिसप्ले कॉन्फ़िगरेशन के हिसाब से अलग-अलग आर्बिट्रेरी डेंसिटी नाम के पहले अक्षर के बाद सेट किए गए, उपयोगकर्ता के किए गए बदलाव (उदाहरण के लिए, डिसप्ले साइज़) बूट करें.
डिवाइस को लागू करने के लिए, 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 पर काम करने वाले सभी डिसप्ले के लिए सही वैल्यू की रिपोर्ट देनी ज़रूरी है मेट्रिक में android.util.DisplayMetrics एपीआई.

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

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

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] इस्तेमाल किए जा सकने वाले OpenGL ES वर्शन (1.1, 2.0, 3.0, 3.1, 3.2) को मैनेज करने वाले एपीआई के ज़रिए (जैसे, GLES10.getString() तरीका) और नेटिव एपीआई शामिल हैं.
[C-0-2] ज़रूरी है कि मैनेज किए जा रहे सभी एपीआई का इस्तेमाल किया जा सके और नेटिव एपीआई के साथ काम करता है.

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

[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 टेस्ट को कई टेस्ट सूचियों में बांटा गया है. हर टेस्ट में, कोई संबद्ध तारीख/वर्शन नंबर. ये Android सोर्स ट्री में external/deqp/android/cts/main/glesXX-main-YYYY-MM-DD.txt. ऐसा डिवाइस जो अपने-आप रिपोर्ट किए गए लेवल पर 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] OpenGL ES dEQP टेस्ट के ज़्यादा से ज़्यादा वर्शन की रिपोर्ट देना ज़रूरी है android.software.opengles.deqp.level फ़ीचर फ़्लैग के ज़रिए काम करता है.
[C-2-4] कम से कम, 132383489 (1 मार्च, 2020 से) वर्शन पर इस तरह से काम करना चाहिए: को android.software.opengles.deqp.level फ़ीचर फ़्लैग में रिपोर्ट किया गया है.
[C-2-5] वर्शन के बीच की टेस्ट सूचियों में से सभी OpenGL ES dEQP टेस्ट पास करने होंगे 132383489 और वह वर्शन जिसकी जानकारी हर काम करने वाली सुविधा के लिए, android.software.opengles.deqp.level फ़ीचर फ़्लैग OpenGL ES वर्शन.
[C-SR-2] EGL_KHR_partial_update और इनके साथ काम करने के लिए, इस बात का सुझाव दिया जाता है OES_EGL_image_external एक्सटेंशन.
getString() तरीके से, किसी भी टेक्सचर का इस्तेमाल करके, सटीक तरीके से रिपोर्ट की जानी चाहिए कंप्रेशन फ़ॉर्मैट है, जो काम करता है. यह आम तौर पर वेंडर के लिए होता है.
EGL_IMG_context_priority और EGL_EXT_protected_content एक्सटेंशन.

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

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

अगर डिवाइस, 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 टेस्ट को कई टेस्ट लिस्ट में बांटा गया है. हर टेस्ट में संबंधित तारीख/वर्शन. ये Android सोर्स ट्री में external/deqp/android/cts/main/vk-main-YYYY-MM-DD.txt. ऐसा डिवाइस जो सेल्फ़-रिपोर्ट लेवल पर Vulkan के साथ काम करते हैं. इससे पता चलता है कि यह dEQP पास कर सकता है इस लेवल और इससे पहले की सभी टेस्ट सूचियों में, टेस्ट के तौर पर जोड़ा जा सकता है.

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

[C-1-1] आपको वैल्यू के तौर पर सही पूर्णांक वैल्यू की रिपोर्ट करनी होगी. android.hardware.vulkan.level और android.hardware.vulkan.version फ़ीचर फ़्लैग.
[C-1-2] Vulkan के लिए कम से कम एक VkPhysicalDevice की गिनती करना ज़रूरी है नेटिव एपीआई vkEnumeratePhysicalDevices() को अपनाएं.
[C-1-3] बताए गए हर एपीआई के लिए, Vulkan 1.0 एपीआई को पूरी तरह से लागू करना ज़रूरी है VkPhysicalDevice.
[C-1-4] नेटिव लाइब्रेरी में मौजूद लेयर की गिनती करना ज़रूरी है libVkLayer*.so को ऐप्लिकेशन पैकेज की मूल लाइब्रेरी निर्देशिका में डालें, Vulkan नेटिव एपीआई vkEnumerateInstanceLayerProperties() के ज़रिए और vkEnumerateDeviceLayerProperties() को अपनाएं.
[C-1-5] ऐसी लेयर की गणना नहीं की जानी चाहिए जो या उसे एन्क्रिप्ट करने के अन्य तरीके उपलब्ध कराकर Vulkan एपीआई, जब तक कि ऐप्लिकेशन में 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] Vulkan dEQP टेस्ट के ज़्यादा से ज़्यादा वर्शन की रिपोर्ट देना ज़रूरी है android.software.vulkan.deqp.level फ़ीचर फ़्लैग के ज़रिए काम करता है.
[C-1-9] कम से कम, 1 मार्च, 2019 से 132317953 वर्शन पर इस तरह से काम करना चाहिए: को android.software.vulkan.deqp.level फ़ीचर फ़्लैग में रिपोर्ट किया गया है.
[C-1-10] इनके बीच की टेस्ट लिस्ट में से, सभी Vulkan dEQP टेस्ट को पास करना ज़रूरी है वर्शन 132317953 और android.software.vulkan.deqp.level फ़ीचर फ़्लैग.
[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 नेटिव एपीआई के लिए, किसी भी VkPhysicalDevice की गिनती नहीं की जानी चाहिए vkEnumeratePhysicalDevices().

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

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

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

[C-0-1] डिवाइस को लागू करने के लिए Android RenderScript के साथ काम करना ज़रूरी है. इसके बारे में पूरी जानकारी दी गई है देखें.

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

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

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

[C-0-1] डिफ़ॉल्ट रूप से, हार्डवेयर से तेज़ी लाने की सुविधा चालू करनी होगी और ज़रूरी है हार्डवेयर से तेज़ी लाने की सुविधा तब बंद करें, जब डेवलपर सेटिंग 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] फ़ोन में ऐसा डिसप्ले होना चाहिए जिसका गैमट, sRGB के कलर गैमट को ढक देता हो पूरी तरह से CIE 1931 xyY स्पेस में.
[C-1-3] में ऐसा डिसप्ले होना चाहिए जिसके गैमट का क्षेत्रफल कम से कम 90% हो CIE 1931 xyY स्पेस में DCI-P3.
[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 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] 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] इंस्टॉल किए गए ऐप्लिकेशन को लॉन्च करने के लिए, लोगों को अनुमति देनी होगी जिसमें <intent-filter> के साथ कोई गतिविधि हुई हो और ACTION=MAIN और टेलीविज़न डिवाइस के लिए CATEGORY=LAUNCHER या CATEGORY=LEANBACK_LAUNCHER लागू करना. उपयोगकर्ता के लिए इस तरह के खर्च को मैनेज करने के लिए, होम फ़ंक्शन को इस्तेमाल किया जाना चाहिए.
हाल ही के और वापस जाएं फ़ंक्शन के लिए बटन देने चाहिए.

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

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

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

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

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

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

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

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

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

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

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

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

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] इस ईमेल के लिए, TOUCHSCREEN_NOTOUCH को रिपोर्ट करना ज़रूरी है Configuration.touchscreen एपीआई फ़ील्ड.

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

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

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

यह एलान करना चाहिए कि यह सुविधा 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] 'पांच' की अलग-अलग ट्रैकिंग (उंगली का हाथ ट्रैक करना) के साथ काम करना ज़रूरी है का इस्तेमाल कर सकते हैं.

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, a लॉजिकल ज़्यादा से ज़्यादा 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 एक्सिस_आरज़ेड

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

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

[C-4-1] इसमें फ़ैक्ट्री के हिसाब से तय किया गया कोई कैलिब्रेशन शामिल नहीं होना चाहिए पैरामीटर दिए गए हैं.

अगर डिवाइस लागू करने के तरीके में 3-ऐक्सिस एक्सलरोमीटर का कॉम्बिनेशन शामिल है, तो 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] लागू करने और रिपोर्ट करने के लिए STRONGLY_recommended हैं TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED सेंसर.

अगर डिवाइस में 3-ऐक्सिस एक्सलरोमीटर और इनमें से कोई भी 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 कंपोज़िट सेंसर.
[C-SR-7] को सीएनजीएस TYPE_GAME_ROTATION_VECTOR कंपोज़िट सेंसर.

अगर डिवाइस में 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 API.
[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 मिलीवाट से कम बिजली का इस्तेमाल करना चाहिए.
बैच मोड के लिए सेंसर रजिस्टर होने पर, इसे 3 mW से कम की खपत होनी चाहिए 10 हर्ट्ज़ पर.

7.3.3. जीपीएस

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

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

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

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

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

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

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

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

[C-1-1] कम से कम 50 हर्ट्ज़ की फ़्रीक्वेंसी तक इवेंट की रिपोर्ट उपलब्ध होनी चाहिए.
[C-1-4] इसका रिज़ॉल्यूशन 12-बिट या इससे ज़्यादा होना चाहिए.
[C-1-5] तापमान के लिए मुआवज़ा देना ज़रूरी है.
[C-1-6] इस्तेमाल करते समय कैलिब्रेट और मुआवज़ा दिया जाना चाहिए. साथ ही, डिवाइस को फिर से चालू करने के बीच के समय में, नुकसान पहुंचाने वाले पैरामीटर के बारे में जानकारी देनी होगी.
[C-1-7] वैरियंस का अंतर, हर हर हर्ट्ज़ के हिसाब से 1e-7 red^2 / s^2 से ज़्यादा नहीं होना चाहिए (वैरियंस प्रति हर्ट्ज़ या रेड^2 / s). वैरिएंस को सैंपलिंग रेट, लेकिन इस वैल्यू के लिए सीमित होना चाहिए. दूसरे शब्दों में, अगर आप जाइरो के वैरियंस को 1 हर्ट्ज़ की सैंपलिंग दर से मापें. यह इससे ज़्यादा नहीं होना चाहिए 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] लागू करने और रिपोर्ट करने के लिए STRONGLY_ राजकीय हैं TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED सेंसर.

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

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

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

[C-5-1] TYPE_GRAVITY और TYPE_LINEAR_ACCELERATION को लागू करना ज़रूरी है कंपोज़िट सेंसर.
[C-SR-6] को सीएनजीएस TYPE_GAME_ROTATION_VECTOR कंपोज़िट सेंसर.

7.3.5. बैरोमीटर

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

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

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

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

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 सेंटीमीटर और दूर तक पढ़ने की सुविधा मिलती है.
[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] का 3dB मेज़रमेंट बैंडविथ रखने का सुझाव दिया जाता है इस रेंज में, Nyquist फ़्रीक्वेंसी का कम से कम 80% और व्हाइट नॉइज़ स्पेक्ट्रम है बैंडविथ.
- त्वरण रैंडम वॉकिंग 30 μg 7Hz से कम होनी चाहिए कमरे का तापमान.
- तापमान में बदलाव होना चाहिए और ≤ +/- 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 सेंसर होना चाहिए जो:
- माप की रेंज कम से कम -1,000 और +1000 dps के बीच होनी चाहिए.
- रिज़ॉल्यूशन कम से कम 16 LSB/dps होना चाहिए.
- तापमान मापने की फ़्रीक्वेंसी कम से कम 12.5 हर्ट्ज़ या इससे कम होनी चाहिए.
- तापमान मापने की फ़्रीक्वेंसी ज़्यादा से ज़्यादा 400 हर्ट्ज़ या इससे ज़्यादा होनी चाहिए; होना चाहिए वह SensorDirectChannel RATE_VERY_FAST के साथ काम करता हो.
- तापमान मापने के लिए ज़रूरी नॉइज़ 0.014°/s/प्रभावित हर्ट्ज़ से ज़्यादा नहीं होनी चाहिए.
- [C-SR-2] का 3dB मेज़रमेंट बैंडविथ रखने का सुझाव दिया जाता है इस रेंज में, Nyquist फ़्रीक्वेंसी का कम से कम 80% और व्हाइट नॉइज़ स्पेक्ट्रम है बैंडविथ.
- कमरे में रैंडम तरीके से पैदल चलने की दर 0.001 °/s 7Hz से कम होनी चाहिए तापमान.
- तापमान में बदलाव होना चाहिए और तापमान ≤ +/- 0.05 °/ s / °C होना चाहिए.
- 0.02% / °C के तापमान के मुकाबले संवेदनशीलता में बदलाव होना चाहिए.
- सबसे सही लाइन वाली लाइन होनी चाहिए, जो 0.2% या इससे कम हो.
- शोर की सघनता ≤ 0.007 °/s/होस्ट हर्ट्ज़ होनी चाहिए.
- कैलिब्रेशन की गड़बड़ी 0.002 रेड/सेकंड से कम होनी चाहिए फ़ोन के स्थिर होने पर, उसका तापमान 10 ~ 40 °C होता है.
- 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] 1 हर्ट्ज़ से लेकर व्हाइट नॉइस स्पेक्ट्रम तक रखने का सुझाव दिया जाता है कम से कम 10 हर्ट्ज़, जब रिपोर्ट की दर 50 हर्ट्ज़ या उससे ज़्यादा हो.
[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 mW जब डिवाइस हिल रहा हो.
[C-2-10] ऐसा TYPE_STEP_DETECTOR सेंसर होना चाहिए जो:
- बफ़रिंग की सुविधा चालू होने पर भी इस सेंसर को चालू करने की ज़रूरत है कम से कम 100 सेंसर इवेंट की क्षमता का होना चाहिए.
- अगर डिवाइस में ऊर्जा की खपत 0.5 मिलीवाट से ज़्यादा न हो, तो स्टैटिक और 1.5 mW जब डिवाइस हिल रहा हो.
- बैच में ऊर्जा की खपत 4 मिलीवाट से ज़्यादा नहीं होनी चाहिए.
[C-2-11] ऐसा TYPE_STEP_COUNTER सेंसर होना चाहिए जो:
- अगर डिवाइस में ऊर्जा की खपत 0.5 मिलीवाट से ज़्यादा न हो, तो स्टैटिक और 1.5 mW जब डिवाइस हिल रहा हो.
[C-2-12] ऐसा TILT_DETECTOR सेंसर होना चाहिए जो:
- अगर डिवाइस में ऊर्जा की खपत 0.5 मिलीवाट से ज़्यादा न हो, तो स्टैटिक और 1.5 mW जब डिवाइस हिल रहा हो.
[C-2-13] एक ही फ़िज़िकल इवेंट के लिए, इवेंट का टाइमस्टैंप एक्सलरोमीटर, जाइरोस्कोप, और मैग्नेटोमीटर के बीच का समय 2.5 मिलीसेकंड से कम होना चाहिए एक-दूसरे के बारे में जानते हैं. उसी असली इवेंट के इवेंट का टाइमस्टैंप जिसके ज़रिए रिपोर्ट की गई एक्सलरोमीटर और जाइरोस्कोप, दोनों में से हर एक के लिए 0.25 मिलीसेकंड के अंदर होना चाहिए अन्य.
[C-2-14] जाइरोस्कोप सेंसर इवेंट के टाइमस्टैंप एक ही समय पर होने चाहिए बेस को कैमरा सबसिस्टम के तौर पर सेट करता है और गड़बड़ी होने के 1 मिलीसेकंड के अंदर होता है.
[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 में क्लास और उसके किसी भी कॉम्बिनेशन में किया जा सकता है. इसके ठीक उलट, 'value' पैरामीटर में दिए गए canAuthenticate(int) और setAllowedAuthenticator(int) और इसमें सार्वजनिक स्थिरांक के तौर पर दर्ज किए गए दस्तावेज़ों के अलावा, अन्य तरीके भी शामिल हैं पुष्टि करने वाले और उनके किसी भी संयोजन को लागू किया जा सकता है.
[C-4-3] ACTION_BIOMETRIC_ENROLL को लागू करना ज़रूरी है उन डिवाइसों पर कार्रवाई करना जिन पर क्लास 3 या क्लास 2 बायोमेट्रिक्स हो. इस कार्रवाई के लिए, क्लास 3 के लिए रजिस्ट्रेशन के एंट्री पॉइंट ही दिखाने चाहिए या क्लास 2 बायोमेट्रिक्स.

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

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

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

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

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

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

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

[C-1-1] गलतफ़हमी की दर 0.002% से कम होनी चाहिए.
[C-1-2] यह बताना ज़रूरी है कि यह मोड एक मज़बूत पिन के मुकाबले कम सुरक्षित हो सकता है, पैटर्न या पासवर्ड शामिल कर सकते हैं और इसे सक्षम करने से जुड़े जोखिमों की स्पष्ट रूप से गणना कर सकते हैं, अगर स्पूफ़ और इम्पॉस्टर स्वीकार करने की दर 7% से ज़्यादा है, जो कि Android बायोमेट्रिक्स टेस्ट प्रोटोकॉल.
[C-1-9] उपयोगकर्ता को, मुख्य रूप से पुष्टि करने के लिए सुझाए गए तरीके के लिए चुनौती देनी होगी (उदा. पिन, पैटर्न, पासवर्ड) 20 से अधिक गलत परीक्षणों के बाद और नहीं बायोमेट्रिक वेरिफ़िकेशन के लिए, बैकऑफ़ समय 90 सेकंड से कम होना चाहिए फ़ॉल्स ट्रायल उसे कहते हैं जिसमें कैप्चर की गई क्वालिटी अच्छी हो (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) स्पूफ़ और इंपोस्टर के स्वीकार किए जाने की दर अटैक इंस्ट्रुमेंट (PAI) की ऐसी प्रजातियां जो 30% से ज़्यादा न हों, और (2) एक स्पूफ़ और लेवल B PAI की प्रजातियों की इंपोस्टर स्वीकार करने की दर 40% से ज़्यादा नहीं है, क्योंकि को Android बायोमेट्रिक्स टेस्ट प्रोटोकॉल से मेज़र किया जाता है.
[C-1-4] ज़रूरी है कि बायोमेट्रिक्स जोड़ने के लिए, पहले यह पुष्टि न की गई हो कि उपयोगकर्ता से मौजूदा डिवाइस की पुष्टि करवाना या कोई नया डिवाइस जोड़ना, ताकि उसकी सेवाओं का इस्तेमाल किया जा सके टीईई की मदद से सुरक्षित किया गया क्रेडेंशियल (पिन/पैटर्न/पासवर्ड) Android Open सोर्स प्रोजेक्ट को लागू करने की प्रोसेस से, फ़्रेमवर्क में ऐसा करने की सुविधा मिलती है तो.
[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] दिए गए फ़्रेमवर्क में लॉजिक का इस्तेमाल करने के लिए, इस बात का सुझाव दिया जाता है में बताए गए प्रतिबंध लागू करने के लिए Android ओपन सोर्स प्रोजेक्ट के ज़रिए नए डिवाइसों के लिए [C-1-7] और [C-1-8].
[C-SR-8] इस बात का बहुत ज़्यादा सुझाव दिया जाता है कि अस्वीकार किए जाने की दर, इससे कम हो 10%, जैसा डिवाइस पर मापा गया है.
[C-SR-9] के लिए, इंतज़ार के समय को एक सेकंड से कम रखने का सुझाव दिया जाता है. इसे मापा जाता है हर डिवाइस के लिए, बायोमेट्रिक की पहचान होने से लेकर स्क्रीन अनलॉक होने तक बायोमेट्रिक रजिस्टर किया गया है.

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

[C-2-1] क्लास 1 के लिए ऊपर दी गई सभी ज़रूरी शर्तों को पूरा करना ज़रूरी है.
[C-2-2] स्पूफ़ और इंपोस्टर के ज़रिए पेमेंट स्वीकार करने की दर 20% से ज़्यादा नहीं होनी चाहिए, लेवल ए के प्रज़ेंटेशन के लिए, (1) स्पूफ़ और इंपोस्टर के स्वीकार किए जाने की दर अटैक इंस्ट्रुमेंट (PAI) की ऐसी प्रजातियां जो 20% से ज़्यादा न हों, और (2) एक स्पूफ़ और लेवल B PAI की प्रजातियों की इंपोस्टर स्वीकार करने की दर 30% से ज़्यादा नहीं है, क्योंकि इससे पता चलता है कि Android बायोमेट्रिक्स टेस्ट प्रोटोकॉल.
[C-2-3] ज़रूरी है कि Android के बाहर, एक अलग एनवायरमेंट में बायोमेट्रिक मैचिंग की सुविधा इस्तेमाल की जाती है उपयोगकर्ता या कर्नेल स्पेस, जैसे कि ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट (टीईई) या एक चिप पर मौजूद है, जो एक सुरक्षित चैनल पर भी काम करता है.
[C-2-4] ज़रूरी है कि पहचान से जुड़ा सारा डेटा एन्क्रिप्ट (सुरक्षित) किया गया हो और उसे क्रिप्टोग्राफ़िक तौर पर इस्तेमाल किया गया हो को इस तरह से प्रमाणित किया गया हो कि उन्हें न तो उनके बाहर से पाया जा सकता है, न पढ़ा जा सकता है, और न ही उनमें बदलाव किया जा सकता है एक-दूसरे से अलग एक्ज़ीक्यूशन एनवायरमेंट या चिप के साथ सुरक्षित चैनल एक्ज़ीक्यूशन एनवायरमेंट, जैसा कि लागू करने की प्रोसेस में बताया गया है दिशा-निर्देश पर अपडेट कर सकते हैं.
[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 के तौर पर ट्रीट करना हो (पहले Strong) था, तो वे:

[C-3-1] क्लास 2 की ऊपर बताई गई सभी ज़रूरी शर्तों को पूरा करना ज़रूरी है. हालांकि, इसमें कुछ भी शामिल नहीं हैं [C-1-7] और [C-1-8].
[C-3-2] ज़रूरी है कि इसमें हार्डवेयर-बैक्ड कीस्टोर लागू किया गया हो.
[C-3-3] स्पूफ़ और इंपोस्टर के ज़रिए पेमेंट स्वीकार करने की दर 7% से ज़्यादा नहीं होनी चाहिए, इसके साथ (1) स्पूफ़ और इंपोस्टर स्वीकार करने की दर लेवल ए प्रज़ेंटेशन अटैक इंस्ट्रुमेंट (पीएआई) वाली ऐसी प्रजातियां जो 7% से ज़्यादा नहीं हैं, और (2) लेवल B वाली पीएआई की प्रजातियों के स्पूफ़ और इंपोस्टर को स्वीकार किए जाने की दर ज़्यादा नहीं है 20% से कम है, जैसा कि Android बायोमेट्रिक्स टेस्ट प्रोटोकॉल.
[C-3-4] उपयोगकर्ता को सुझाए गए प्राइमरी हर 72 घंटे में एक बार पुष्टि करने की सुविधा, जैसे कि पिन, पैटर्न, पासवर्ड या कम.
[C-3-5] Authenticator आईडी को फिर से जनरेट करना ज़रूरी है डिवाइस पर इस्तेमाल किए जा सकने वाले सभी क्लास 3 बायोमेट्रिक्स के लिए, अगर इनमें से कोई भी फिर से रजिस्टर किया गया.
[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_TYPE_IWLAN’ की शिकायत नहीं करनी चाहिए Networkरजिस्ट्रेशनInfo#getAccessNetworkTechnोलॉजी() के ज़रिए जब Networkरजिस्ट्रेशनInfo#getTransportType() की रिपोर्ट, उसी Networkरजिस्ट्रेशनInfo इंस्टेंस के लिए ‘TRANSPORT_TYPE_WWAN’ के तौर पर की जाती है.

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

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

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

[C-6-1] SmsManager#sendTextMessage और SmsManager#sendMultipartTextMessage इस पर कॉल करना ज़रूरी है CarrierMessagingService टेक्स्ट मैसेज की सुविधा उपलब्ध कराने के लिए. SmsManager#sendMultimediaMessage और SmsManager#downloadMultimediaMessage इस पर कॉल करना ज़रूरी है CarrierMessagingService मल्टीमीडिया मैसेज की सुविधा उपलब्ध कराने के लिए.
[C-6-2] जिस ऐप्लिकेशन के लिए android.provider.Telephony.Sms#getDefaultSmsPackage इस्तेमाल करना ज़रूरी है एसएमएस मैनेजर मैसेज (एसएमएस) और मल्टीमीडिया मैसेज (एमएमएस) भेजने और पाने के दौरान एपीआई की सुविधा. एओएसपी का रेफ़रंस पैकेज/ऐप्लिकेशन/मैसेज में लागू करने की प्रक्रिया इस ज़रूरी शर्त को पूरा करती है.
[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] इस नीति के तहत किसी भी SubscriptionInfo को दिखाने या उसे कंट्रोल करने की अनुमति नहीं देनी चाहिए शून्य के अलावा ग्रुप UUID और ऑपर्च्यूनिस्टिक बिट दिखाने में आसान है जो सिम कार्ड की सेटिंग को कॉन्फ़िगर करने या कंट्रोल करने की अनुमति देता है.

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

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

अगर लागू किए गए डिवाइस पर 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] किसी भी टाइम ज़ोन पर,IllegalArgumentException पसंदीदा या अनुमति वाले नेटवर्क टाइप के बिटमास्क में 3GPP2 नेटवर्क टाइप.
[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] का सुझाव दिया जाता है कि डिफ़ॉल्ट डायलर ऐप्लिकेशन को पहले से लोड किया जाए अपने कॉल लॉग में, कॉल लॉग की एंट्री और तीसरे पक्ष के किसी ऐप्लिकेशन का नाम दिखाता है जब तीसरे पक्ष का ऐप्लिकेशन EXTRA_LOG_SELF_MANAGED_CALLS अतिरिक्त कुंजी को उसके PhoneAccount से true पर.
[C-SR-3] ऑडियो हेडसेट को संभालने के लिए कड़ाई जाती है इसके लिए KEYCODE_MEDIA_PLAY_PAUSE और KEYCODE_HEADSETHOOK इवेंट android.telecom नीचे बताए गए API:
- 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] multicast API को लागू करना ज़रूरी है जैसा कि SDK टूल के दस्तावेज़ में बताया गया है.
[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] सोर्स MAC पते और जांच के क्रम की संख्या को किसी भी क्रम में लगाना ज़रूरी है फ़्रेम का अनुरोध करें, हर स्कैन की शुरुआत में एक बार, जबकि STA डिसकनेक्ट किया गया.
[C-1-8] एक जैसे MAC पते का इस्तेमाल करना ज़रूरी है (एमएसी को किसी भी क्रम में नहीं बदला जाना चाहिए पता होता है.
[C-1-9] जांच के अनुरोध के क्रम की संख्या को सामान्य तरीके से दोहराना ज़रूरी है स्कैन में जांच के अनुरोधों के बीच में अंतर करता है.
[C-1-10] आखिरी जांच के बीच, जांच अनुरोध की क्रम संख्या को किसी भी क्रम में लगाना ज़रूरी है एक स्कैन का अनुरोध और अगले स्कैन के लिए पहला जांच अनुरोध.
[C-SR-1] के लिए इस्तेमाल किए जाने वाले स्रोत MAC पते को किसी भी क्रम में लगाने के लिए, इस बात पर ज़ोर दिया जाता है किसी ऐक्सेस पॉइंट (एपी) पर सभी एसटीए कम्यूनिकेशन संबंधित.
- डिवाइस को हर SSID के लिए किसी भी रैंडम मैक पते का इस्तेमाल करना चाहिए (पासपॉइंट के लिए एफ़क्यूडीएन) इससे संपर्क करता है.
- डिवाइस में उपयोगकर्ता को यह कंट्रोल करने का विकल्प देना होगा: हर SSID को रैंडमाइज़ेशन (पासपॉइंट के लिए एफ़क्यूडीएन) और वह भी बिना किसी क्रम के और विकल्प, किसी भी क्रम में दिए जा सकते हैं और नए वाई-फ़ाई के लिए डिफ़ॉल्ट मोड सेट करना ज़रूरी है कॉन्फ़िगरेशन को किसी भी क्रम में लगाना होगा.
[C-SR-2] का सुझाव दिया जाता है कि किसी भी AP के लिए रैंडम BSSID का इस्तेमाल किया जाए बनाएं.
- MAC पता किसी भी क्रम में होना चाहिए और उसे हर उस SSID के हिसाब से बनाए रखना चाहिए जिसका इस्तेमाल एपी॰
- डिवाइस उपयोगकर्ता को इस सुविधा को बंद करने का विकल्प दे सकता है. अगर ऐसा विकल्प दिया जाता है, तो रैंडमाइज़ेशन की सुविधा डिफ़ॉल्ट रूप से चालू होनी चाहिए.

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

किसी ऐप का प्राप्ति होने पर वाई-फ़ाई पावर सेव मोड बंद कर देना चाहिए WIFI_MODE_FULL_HIGH_PERF लॉक या WIFI_MODE_FULL_LOW_LATENCY लॉक WifiManager.createWifiLock() से होकर और WifiManager.WifiLock.acquire() एपीआई और लॉक चालू हैं.
[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] इससे जुड़े Android API को लागू करना ज़रूरी है जैसा कि SDK टूल के दस्तावेज़ में बताया गया है.
[C-1-2] हार्डवेयर की सुविधा android.hardware.wifi.direct की रिपोर्ट करना ज़रूरी है.
[C-1-3] ज़रूरी है कि सामान्य वाई-फ़ाई काम किया जा सके.
[C-1-4] ज़रूरी है कि एक ही समय में वाई-फ़ाई और वाई-फ़ाई डायरेक्ट की सुविधाएं काम करें.
[C-SR-1] सभी के लिए सोर्स MAC पते को किसी भी क्रम में लगाने के लिए, इस बात का खास तौर पर सुझाव दिया जाता है नए बने हुए Wi-Fi Direct कनेक्शन.

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

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

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

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

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

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

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

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

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

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

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

[C-2-1] लोकेशन-अवेयर डिस्कवरी एपीआई को लागू करना ज़रूरी है: setRangingEnabled, setMinMinutesMm, setMaxडिस्टेंसएमएम , और onServiceFindedWithRange.

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

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

[C-1-1] वाई-फ़ाई पासपॉइंट की सुविधा शामिल होनी चाहिए.
[C-1-2] पासपॉइंट से जुड़े WifiManager एपीआई को इस तरह लागू करना ज़रूरी है SDK टूल से जुड़े दस्तावेज़ में बताया गया है.
[C-1-3] ज़रूरी है कि यह IEEE 802.11u स्टैंडर्ड के साथ काम करता हो. को नेटवर्क खोजने और चुनने की सुविधा देता है, जैसे कि सामान्य विज्ञापन सेवा (GAS) और ऐक्सेस नेटवर्क क्वेरी प्रोटोकॉल (ANQP).
[C-1-4] android.hardware.wifi.passpoint फ़ीचर फ़्लैग के बारे में बताना ज़रूरी है.
[C-1-5] खोज करने, मैच करने, और असोसिएट करने के लिए, एओएसपी को लागू करने का तरीका फ़ॉलो करना ज़रूरी है पासपॉइंट नेटवर्क पर स्विच करता है.
[C-1-6] डिवाइस प्रावधान के कम से कम नीचे दिए गए सबसेट पर काम करना ज़रूरी है वाई-फ़ाई अलायंस पासपॉइंट R2 में बताए गए प्रोटोकॉल: EAN-टीटीएलएस पुष्टि करने और एसओएपी-एक्सएमएल.
[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] WifiRttManager एपीआई को इस हिसाब से लागू करना ज़रूरी है SDK टूल से जुड़े दस्तावेज़.
[C-1-2] android.hardware.wifi.rtt फ़ीचर फ़्लैग का एलान करना ज़रूरी है.
[C-1-3] हर आरटीटी के लिए, सोर्स MAC पते को किसी भी क्रम में लगाना ज़रूरी है जिसे उस वाई-फ़ाई इंटरफ़ेस के दौरान चलाया जाता है जिस पर RTT है एक्ज़ीक्यूट किया जाना किसी ऐक्सेस पॉइंट से जुड़ा हुआ नहीं है.
[C-1-4] 68वें दिन पर 80 मेगाहर्ट्ज़ बैंडविथ पर दो मीटर के अंदर सटीक होना चाहिए शतमक (क्यूमुलेटिव डिस्ट्रिब्यूशन फ़ंक्शन की मदद से कैलकुलेट किया गया).
[C-SR-1] 1.5 मीटर के अंदर सटीक तरीके से रिपोर्ट करने का सुझाव दिया जाता है 68वें पर्सेंटाइल पर 80 मेगाहर्ट्ज़ बैंडविथ पर (जैसा कि क्यूमुलेटिव डिस्ट्रिब्यूशन फ़ंक्शन).

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

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

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

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

7.4.3. ब्लूटूथ

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

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

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

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

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

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

[C-5-1] इसके लिए true वापस करना होगा: ब्लूटूथ अडैप्टर.getProfileProxy(context, पहचानकर्ता, BluetoothProfile.HEARING_AID).

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

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

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

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

अगर लागू किए गए डिवाइस,true BluetoothAdapter.isLeAudioSupported() एपीआई का इस्तेमाल करने के बाद:

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

अगर लागू किए गए डिवाइस,true BluetoothAdapter.isLeAudioBroadcastSourceSupported() एपीआई का इस्तेमाल करने के बाद:

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

अगर लागू किए गए डिवाइस,true BluetoothAdapter.isLeAudioBroadcastAssistantSupported() एपीआई का इस्तेमाल करने के बाद:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[C-2-1] ड्यूअल-स्टैक और IPv6-ओनली पर काम करना ज़रूरी है ईथरनेट.

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

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

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

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

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

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

अगर लागू किए गए डिवाइस पर, android.webkit.Webview API वे:

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

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

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

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

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

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

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

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

[C-2-1] इसके लिए RESTRICT_BACKGROUND_STATUS_DISABLED वैल्यू देनी होगी ConnectivityManager.getRestrictBackgroundStatus()
[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] ज़रूरी शर्तों को पूरा करने के लिए इस बात पर ज़ोर दिया जाता है कि मानक संगठनों की ओर से तय किए जाने वाले सर्टिफ़िकेशन टेस्ट. इनमें ये शामिल हैं एफ़आईआरए, सीसीसी और सीएसए.
- [C-1-6] यह पक्का करना ज़रूरी है कि दूरी की माप 95% के लिए +/-15 cm के अंदर हो में 1 मीटर की दूरी पर, लाइन ऑफ़ विज़ुअल एनवायरमेंट में माप के पैमाना नॉन-रिफ़्लेक्टिव चैंबर.
- [C-1-7] यह पक्का करना ज़रूरी है कि दूरी की माप का मीडियन 1 मीटर पर हो रेफ़रंस डिवाइस से [0.75m, 1.25m] के अंदर है, जहां ज़मीनी हकीकत है दूरी को DUT के ऊपरी किनारे से मापा जाता है. इसे ऊपर की ओर और झुकाकर रखा जाता है 45 डिग्री.
- [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 इंस्टेंस रजिस्टर किया गया पर, जब तक कि ऐप्लिकेशन साफ़ तौर पर चालू न हो FLASH_MODE_AUTO या FLASH_MODE_ON एट्रिब्यूट को चालू करके फ़्लैश Camera.Parameters ऑब्जेक्ट में से. ध्यान दें कि यह प्रतिबंध डिवाइस में पहले से मौजूद सिस्टम कैमरा ऐप्लिकेशन, लेकिन सिर्फ़ तीसरे पक्ष के लिए 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] कैमरे की झलक, ऐप्लिकेशन के ज़रिए तय किया गया ओरिएंटेशन, जब मौजूदा ऐप्लिकेशन में हो ने साफ़ तौर पर अनुरोध किया है कि Camera डिसप्ले को घुमाया जा सकता है. इसके लिए, 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 या उसके बाद के वर्शन) पर काम करना ज़रूरी है, अगर बाहरी कैमरा, USB होस्ट पोर्ट से कनेक्ट हो जाता है.
[C-1-3] फ़िज़िकल बाहरी कैमरा डिवाइस से, कैमरे के सीटीएस टेस्ट को पास करना ज़रूरी है कनेक्ट किया गया. कैमरे के सीटीएस टेस्टिंग के बारे में जानकारी source.android.com पर उपलब्ध है.
डेटा ट्रांसफ़र करने के लिए, MJPEG जैसे वीडियो कंप्रेस करें अच्छी क्वालिटी वाली, बिना कोड में बदली गई स्ट्रीम (यानी रॉ या अलग से कंप्रेस की गई इमेज स्ट्रीम).
शायद इसमें कई कैमरे काम कर सकते हैं.
शायद इनमें कैमरा-आधारित वीडियो एन्कोडिंग की सुविधा काम करती है.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7.7. यूएसबी

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

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

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

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

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

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

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

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

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

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

यदि डिवाइस कार्यान्वयन में होस्ट मोड का समर्थन करने वाला USB पोर्ट और USB शामिल है, तो ऑडियो क्लास, वे:

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

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

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

[C-1-1] android.hardware.audio.output सुविधा के कॉन्स्टेंट की जानकारी देना ज़रूरी है.
[C-1-2] Google Play पर सेक्शन 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. ऐनालॉग ऑडियो पोर्ट

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

[C-SR-1] का कम से कम एक उदाहरण शामिल करने का सुझाव दिया जाता है 4 कंडक्टर 3.5mm ऑडियो जैक के लिए ऑडियो पोर्ट.

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

[C-1-1] स्टीरियो हेडफ़ोन और स्टीरियो हेडसेट पर ऑडियो चलाया जा सकता हो माइक्रोफ़ोन को ऐक्सेस करने की अनुमति दें.
[C-1-2] सीटीआईए पिन-आउट ऑर्डर के साथ, टीआरआरएस के ऑडियो प्लग के साथ काम करना ज़रूरी है.
[C-1-3] ज़रूरी है कि माइक्रोफ़ोन और ग्राउंड के बीच, इक्विपमेंट रेट के बराबर की 3 रेंज के बाद ऑडियो प्लग पर कंडक्टर:
- 70 ओम या उससे कम: KEYCODE_HEADSETHOOK
- 210-290 ओम: KEYCODE_VOLUME_UP
- 360-680 ओम: KEYCODE_VOLUME_DOWN
[C-1-4] प्लग डालने पर ACTION_HEADSET_PLUG को ट्रिगर करना ज़रूरी है, लेकिन सिर्फ़ तब, जब प्लग पर मौजूद सभी संपर्क अपने काम के सेगमेंट को छुएं जैक पर.
[C-1-5] कम से कम 150mV ± 10% आउटपुट वोल्टेज तक चलाने की क्षमता होनी चाहिए 32 ओम का स्पीकर प्रतिरोध.
[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] 18.5 किलोहर्ट्ज़ से 20 किलोहर्ट्ज़ से ज़्यादा के शोर के अनुपात में माइक्रोफ़ोन का अनवेटेड सिग्नल -26 डीबीएफ़एस पर 19 किलोहर्ट्ज़ की टोन 50 डीबी से कम नहीं होनी चाहिए.

अगर PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND "सही" है:

[C-2-1] 18.5 किलोहर्ट्ज़ से 20 किलोहर्ट्ज़ में स्पीकर की औसत प्रतिक्रिया, 2 किलोहर्ट्ज़ पर प्रतिक्रिया के समय से 40 dB से कम नहीं होनी चाहिए.

7.8.4. सिग्नल की सुरक्षा

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

दोनों इनपुट के लिए ग्लिच-फ़्री ऑडियो सिग्नल पाथ देना चाहिए साथ ही, हैंडहेल्ड डिवाइसों पर आउटपुट स्ट्रीम देखी जा सकती हैं. इनके बारे में किसी भी समस्या को नहीं बताया गया है को टेस्ट के दौरान, एक मिनट प्रति पाथ के दौरान मापा गया. OboeTester का इस्तेमाल करके टेस्ट करें “ऑटोमेटेड ग्लिच टेस्ट”.

इस जांच के लिए ऑडियो लूपबैक डोंगल की ज़रूरत होती है, इसे सीधे 3.5 मि॰मी॰ जैक में और/या यूएसबी-सी से 3.5 मि॰मी॰ अडैप्टर के साथ इस्तेमाल किया जाता है. सभी ऑडियो आउटपुट पोर्ट की जांच की जानी चाहिए.

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

परफ़ॉर्मेंस मोड	शेयर करें	आउट सैंपल रेट	इन चांस	आउट चांस
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

एक भरोसेमंद स्ट्रीम को, सिग्नल से शोर के लिए इन शर्तों को पूरा करना चाहिए 2000 हर्ट्ज़ साइन के लिए रेशियो (एसएनआर) और टोटल हार्मोनिक डिस्टॉर्शन (टीएचडी).

ट्रांसड्यूसर	बात	एसएनआर
पहले से मौजूद प्राइमरी स्पीकर, जिसे बाहरी रेफ़रंस माइक्रोफ़ोन की मदद से मापा गया है	< 3%	>= 50 डीबी
प्राइमरी बिल्ट-इन माइक्रोफ़ोन, जिसे बाहरी रेफ़रंस स्पीकर की मदद से मापा जाता है	< 3%	>= 50 डीबी
पहले से मौजूद ऐनालॉग 3.5 मि॰मी॰ जैक, जिन्हें लूपबैक अडैप्टर का इस्तेमाल करके टेस्ट किया गया	< 1%	60 डीबी से ज़्यादा
फ़ोन के साथ दिए गए यूएसबी अडैप्टर, जिन्हें लूपबैक अडैप्टर का इस्तेमाल करके टेस्ट किया गया है	< 1%	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, और एक्सटेंशन को उपलब्ध EGL एक्सटेंशन की सूची में प्रदर्शित करें.
[C-1-8] ज़रूरी है GL_EXT_multisampled_render_to_texture2 GL_OVR_multiview, GL_OVR_multiview2, GL_EXT_protected_textures, और एक्सटेंशन को उपलब्ध GL एक्सटेंशन की सूची में दिखाएं.
[C-SR-1] को लागू करने का सुझाव दिया जाता है GL_EXT_external_buffer GL_EXT_EGL_image_array, GL_OVR_multiview_multisampled_render_to_texture, और एक्सटेंशन को उपलब्ध GL एक्सटेंशन की सूची में दिखाएं.
[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 कम से कम 2 है.
[C-1-7] जीपीयू और डिसप्ले के लिए, शेयर किए गए डेटा का ऐक्सेस सिंक करना ज़रूरी है फ़्रंट बफ़र इस तरह की है कि दो के साथ 60fps पर VR सामग्री को बारी-बारी से रेंडर किया जाता है रेंडर करने से जुड़े विज़ुअल, चीर-फाड़ वाले आर्टफ़ैक्ट के बिना दिखेंगे.
[C-1-9] AHardwareBuffer के लिए सहायता लागू करना ज़रूरी है AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER के फ़्लैग किए गए हैं, AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA और AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT जैसा कि एनडीके में बताया गया है.
[C-1-10] AHardwareBuffer के लिए, इस तरह की सहायता उपलब्ध करानी होगी: इस्तेमाल के फ़्लैग का कॉम्बिनेशन AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT, AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE, AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT कम-से-कम निम्न प्रारूप के लिए: AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM, AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM, AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM, AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT.
[C-SR-5] AHardwareBuffer की वैल्यू असाइन करने के लिए, इसका सुझाव दिया जाता है जिसमें एक से ज़्यादा लेयर और फ़्लैग और फ़ॉर्मैट हों.
[C-1-11] 30fps पर कम से कम 3840 x 2160 H.264 डीकोडिंग की सुविधा होनी चाहिए, औसत 40 एमबीपीएस (हर मिनट के 40 एमबीपीएस) तक कंप्रेस किया जाता है. 30 FPS-10 एमबीपीएस पर 1920 x1080 या 60 FPS-20 एमबीपीएस पर 1920 x 1080 के 2 इंस्टेंस).
[C-1-12] यह ज़रूरी है कि ये HEVC और VP9 के साथ काम करते हों. साथ ही, उन्हें कम से कम डिकोड किया जा सकता हो 30 FPS (फ़्रेम प्रति सेकंड) पर 1920 x 1080 रिज़ॉल्यूशन को 10 एमबीपीएस के औसत तक कंप्रेस किया गया होना चाहिए. 30 एफ़पीएस-20 एमबीपीएस पर 3840 x 2160 को डिकोड करने में सक्षम (इसके बराबर 30 FPS-5 एमबीपीएस पर 1920 x 1080 के 4 इंस्टेंस).
[C-1-13] HardwarePropertiesManager.getDeviceTemperatures एपीआई के साथ काम करना ज़रूरी है और त्वचा के तापमान की सटीक वैल्यू दिखाता है.
[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 एपीआई. ज़रूरी शर्तें के लिए मीडिया परफ़ॉर्मेंस क्लास की वैल्यू तय की गई है. R (वर्शन 30). 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 में बताया गया है और संक्रियाएं लिखें:

क्रम से लिखने के लिए परफ़ॉर्मेंस. इसका आकलन करने के लिए, 256 एमबी की फ़ाइल लिखें लिखने के लिए 10 एमबी का बफ़र.
रैंडम तरीके से लिखने की परफ़ॉर्मेंस. 4 केबी का इस्तेमाल करके 256 एमबी की फ़ाइल लिखकर मापा जाता है बफ़र लिखें.
क्रम से पढ़ने की परफ़ॉर्मेंस. इसका पता लगाने के लिए, 256 एमबी की फ़ाइल को पढ़ें लिखने के लिए 10 एमबी का बफ़र.
किसी भी क्रम में पढ़ने की परफ़ॉर्मेंस. 4 केबी का इस्तेमाल करके 256 एमबी की फ़ाइल को पढ़कर मापा जाता है बफ़र लिखें.

8.3. पावर सेविंग मोड

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

[C-1-1] ट्रिगर करने के लिए एओएसपी को लागू करने से अलग नहीं होना चाहिए, के रखरखाव, वेकअप एल्गोरिदम, और ग्लोबल सिस्टम सेटिंग का इस्तेमाल करके या DeviceConfig बैटरी सेव करने वाले ऐप स्टैंडबाय और डोज़ करें (डोज़) मोड में हैं.
[C-1-2] दुनिया भर में इस्तेमाल किए जाने के लिए, एओएसपी को लागू करने से अलग नहीं होना चाहिए सेटिंग या DeviceConfig, जॉब, अलार्म और ऐप्लिकेशन स्टैंडबाय के लिए, हर बकेट में ऐप्लिकेशन के लिए नेटवर्क.
[C-1-3] एओएसपी को लागू करते समय, ऐप्लिकेशन के लिए इस्तेमाल किए जाने वाले ऐप्लिकेशन स्टैंडबाय बकेट स्टैंडबाय.
[C-1-4] ऐप्लिकेशन स्टैंडबाय बकेट और Doze को जानकारी देने के लिए, पावर मैनेजमेंट में बताया गया है.
[C-1-5] PowerManager.isPowerSaveMode() के लिए true वापस करना होगा जब डिवाइस पावर सेव मोड पर हो.
[C-1-6] लोगों के लिए, उन सभी ऐप्लिकेशन को दिखाने की सुविधा देना ज़रूरी है जिन्हें छूट मिली है ऐप स्टैंडबाय और बैटरी कम खर्च करने वाले मोड या बैटरी ऑप्टिमाइज़ेशन से और ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS लागू करना होगा यह उपयोगकर्ता से किसी ऐप्लिकेशन को बैटरी नज़रअंदाज़ करने की अनुमति देने के लिए कहता है ऑप्टिमाइज़ेशन.
[C-SR-1] को इस बात का बहुत ज़्यादा सुझाव दिया जाता है कि हम उपयोगकर्ता को चालू करने के लिए सुविधाएं उपलब्ध कराएं और बैटरी सेवर सुविधा को बंद करना.
[C-SR-2] लोगों को सभी डिसप्ले करने का अधिकार देने के लिए इस बात का बहुत ज़्यादा सुझाव दिया जाता है ऐसे ऐप्लिकेशन जिन्हें ऐप्लिकेशन स्टैंडबाय और बैटरी बचाने वाले मोड के इस्तेमाल से छूट मिली हुई है.

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

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

अगर डिवाइस, लागू होने वाले S4 पावर स्टेटस को एसीपीआई, वे:

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

अगर डिवाइस, लागू होने वाले S3 पावर स्टेटस को एसीपीआई, वे:

[C-2-1] ऊपर दिए गए C-1-1 के मुताबिक होना ज़रूरी है या तीसरे पक्ष के होने पर ही S3 राज्य डालना ज़रूरी है ऐप्लिकेशन को सिस्टम संसाधनों (जैसे स्क्रीन, सीपीयू) की ज़रूरत नहीं होती.

इसके उलट, तीसरे पक्ष के ऐप्लिकेशन को S3 स्टेटस से बाहर निकलना चाहिए दिए गए हैं.

उदाहरण के लिए, जब तीसरे पक्ष के ऐप्लिकेशन, स्क्रीन को सुरक्षित रखने का अनुरोध करते हैं, 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() का पालन करना ज़रूरी है API और अन्य संबंधित API.

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

कम से कम एक ऐसा खास कोर होना चाहिए जिसे सबसे ऊपर रिज़र्व किया जा सके फ़ोरग्राउंड ऐप्लिकेशन में साइन इन करने की सुविधा मिलती है.

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

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

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

[C-3-1] आपको इस वाक्य के ज़रिए एक खाली सूची Process.getExclusiveCores() एपीआई मेथड.

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

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

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

अगर लागू किए गए डिवाइस ने android.hardware.security.model.compatible का एलान किया है सुविधा के तहत, वे:

[C-1-1] ज़रूरी है कि वह इन सब-सेक्शन में बताई गई ज़रूरी शर्तों को पूरा करता हो.

9.1. अनुमतियां

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

[C-0-1] Android अनुमतियों के मॉडल के साथ काम करना चाहिए और Android Roles मॉडल जैसा कि Android डेवलपर दस्तावेज़ में बताया गया है. खास तौर पर, वे हर उस अनुमति और भूमिका को लागू करना ज़रूरी है जो एसडीके से जुड़े दस्तावेज़; कोई अनुमति नहीं और किसी भूमिका को छोड़ा, बदला नहीं जा सकता, या अनदेखा किया गया.
नए अनुमति आईडी की स्ट्रिंग के साथ, दूसरी अनुमतियां जोड़ी जा सकती हैं 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 कुंजी Vault सेवा ताकि लॉकस्क्रीन नॉलेज फ़ैक्टर पर क्रूरता के हमलों को रोका जा सके.

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

[C-0-7] किसी ऐप्लिकेशन के लिए, Android पर जगह की जानकारी की अनुमति वाली प्रॉपर्टी का पालन करना ज़रूरी है स्टैंडर्ड Android एपीआई की मदद से, आपकी जगह की जानकारी या शारीरिक गतिविधि के डेटा का अनुरोध करता है करने के लिए प्रोत्साहित किया जाता है. ऐसे डेटा में ये शामिल हैं, लेकिन इनके अलावा और भी चीज़ें शामिल हो सकती हैं:
- डिवाइस की जगह (जैसे कि अक्षांश और देशांतर) सेक्शन 9.8.8 में बताया गया है.
- ऐसी जानकारी जिसका इस्तेमाल डिवाइस की जगह की जानकारी (उदाहरण के लिए, SSID, BSSID, सेल आईडी या उस नेटवर्क का लोकेशन डिवाइस से कनेक्ट है).
- उपयोगकर्ता की शारीरिक गतिविधि या उसे किस तरह की गतिविधि में शामिल किया गया है.

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

[C-0-8] ऐप्लिकेशन को जगह या शारीरिक गतिविधि का डेटा हो सकता है.
[C-0-9] सिर्फ़ उस ऐप्लिकेशन को रनटाइम की अनुमति देनी होगी जिसमें के लिए ज़रूरी अनुमति होनी चाहिए. उदाहरण के लिए, 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 में बताई गई अनुमति से जुड़ी पाबंदियां और setPermissiongrantState एपीआई.
[C-0-13] हर ऐप्लिकेशन को रिकॉर्ड और ट्रैक करने के लिए, AppOpsManager API का इस्तेमाल करना ज़रूरी है प्रोग्राम के हिसाब से, अपने-आप होने वाली प्रोसेस के ज़रिए डेटा का ऐक्सेस Android की गतिविधियां और सेवाएं.
[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 की सुरक्षा सुविधाएं लागू होनी चाहिए और अनुमति का मॉडल चुनें. भले ही, उनमें ऐसे रनटाइम एनवायरमेंट शामिल हों जो एक्ज़ीक्यूट होते हैं ऐसे ऐप्लिकेशन जो Delvik exeutable की तुलना में किसी अन्य सॉफ़्टवेयर या टेक्नोलॉजी का इस्तेमाल करते हैं फ़ॉर्मैट या नेटिव कोड. दूसरे शब्दों में:

[C-0-1] वैकल्पिक रनटाइम खुद ही Android ऐप्लिकेशन होने चाहिए, साथ ही, 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] ऐप्लिकेशन के लिए अलग-अलग और अलग-अलग ऐप्लिकेशन के लिए स्टोरेज होना चाहिए (a.k.a. /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 का इस्तेमाल करती हैं (SELinux) ज़रूरी ऐक्सेस कंट्रोल (MAC) सिस्टम, seccomp सैंडबॉक्सिंग, और अन्य सुरक्षा सुविधाओं को लागू करना ज़रूरी है. डिवाइस पर यह सुविधा लागू करना:

[C-0-1] मौजूदा ऐप्लिकेशन के साथ काम करना ज़रूरी है. भले ही, SELinux या कोई भी अन्य सुरक्षा सुविधा Android के नीचे लागू की जाती हैं फ़्रेमवर्क शामिल है.
[C-0-2] सिक्योरिटी सुरक्षा से जुड़ी सुविधा ने उल्लंघन का पता लगाया है और उसे ब्लॉक कर दिया है को Android फ़्रेमवर्क के नीचे लागू किया गया है, लेकिन हो सकता है कि उसका यूज़र इंटरफ़ेस साफ़ तौर पर दिखे जब अनब्लॉक किए गए सुरक्षा उल्लंघन का कोई फ़ायदा होता है.
[C-0-3] SELinux या किसी अन्य सुरक्षा सुविधा को लागू नहीं किया जाना चाहिए जो उपयोगकर्ता या ऐप्लिकेशन डेवलपर के लिए कॉन्फ़िगर किए जा सकते हैं.
[C-0-4] ऐसे ऐप्लिकेशन को अनुमति नहीं देनी चाहिए जो दूसरे ऐप्लिकेशन पर असर डाल सकता है एपीआई (जैसे कि डिवाइस एडमिन एपीआई) के ज़रिए, नीति को कॉन्फ़िगर करना होता है इससे कॉन्टेंट के साथ काम करने में रुकावट आती है.
[C-0-5] मीडिया फ़्रेमवर्क को एक से ज़्यादा प्रोसेस में बांटना ज़रूरी है, ताकि यह प्रत्येक प्रक्रिया को और सटीक रूप से ऐक्सेस दिया जा सकता है क्योंकि ब्यौरे वाला पर जाकर देखें.
[C-0-6] कर्नेल ऐप्लिकेशन सैंडबॉक्सिंग मैकेनिज़्म लागू करना ज़रूरी है इसकी मदद से, कॉन्फ़िगर की जा सकने वाली नीति का इस्तेमाल करके, सिस्टम कॉल को फ़िल्टर किया जा सकता है बहुत से थ्रेड वाले प्रोग्राम हैं. अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट ने इसे पूरा किया Threadgroup के साथ seccomp-BPF को सक्षम करके आवश्यकता सिंक्रोनाइज़ेशन (Tसिंक) जैसा बताया गया है source.android.com के Kernel कॉन्फ़िगरेशन सेक्शन में.

Kernel इंटिग्रिटी और खुद की सुरक्षा से जुड़ी सुविधाएं, Android का अहम हिस्सा हैं सुरक्षा. डिवाइस पर यह सुविधा लागू करना:

[C-0-7] कर्नेल स्टैक बफ़र ओवरफ़्लो से सुरक्षा देने के तरीके लागू करना ज़रूरी है. ऐसे तरीकों के कुछ उदाहरण हैं: CC_STACKPROTECTOR_REGULAR और CONFIG_CC_STACKPROTECTOR_STRONG.
[C-0-8] एक्ज़ीक्यूटेबल के लिए कर्नेल मेमोरी सुरक्षा को सख्ती से लागू करना ज़रूरी है कोड रीड-ओनली होता है, रीड-ओनली डेटा होता है, जिसे एक्ज़ीक्यूट नहीं किया जा सकता और न ही लिखा जा सकता है, और लिखने लायक डेटा, एक्ज़ीक्यूट नहीं किया जा सकता (जैसे, CONFIG_DEBUG_RODATA या CONFIG_STRICT_KERNEL_RWX).
[C-0-9] स्टैटिक और डाइनैमिक ऑब्जेक्ट साइज़ को लागू करना ज़रूरी है यूज़र-स्पेस और कर्नेल-स्पेस के बीच कॉपी की जांच को बाउंड करता है (उदाहरण के लिए, CONFIG_HARDENED_USERCOPY) उन डिवाइस पर जो मूल रूप से एपीआई लेवल की मदद से शिपिंग करते हैं 28 या उससे ज़्यादा.
[C-0-10] इस्तेमाल करते समय यूज़र-स्पेस मेमोरी इस्तेमाल नहीं करनी चाहिए कर्नेल मोड में (जैसे कि हार्डवेयर PXN) या फिर CONFIG_CPU_SW_DOMAIN_PAN या CONFIG_ARM64_SW_TTBR0_PAN) डिवाइसों पर मूल रूप से एपीआई लेवल 28 या उसके बाद के लेवल के साथ शिपिंग की जाती है.
[C-0-11] इस तरह की मेमोरी को पढ़ना या लिखना नहीं चाहिए सामान्य usercopy पहुंच API के बाहर कर्नेल (जैसे कि हार्डवेयर पैन, या CONFIG_CPU_SW_DOMAIN_PAN या CONFIG_ARM64_SW_TTBR0_PAN की मदद से एम्युलेट किया गया) एपीआई लेवल 28 या उसके बाद के लेवल के साथ शिपिंग करने वाले डिवाइसों पर.
[C-0-12] कर्नेल पेज टेबल आइसोलेशन को लागू करना ज़रूरी है, अगर हार्डवेयर एपीआई लेवल की मदद से भेजे जाने वाले सभी डिवाइसों पर, CVE-2017-5754 का जोखिम हो सकता है 28 या उससे ज़्यादा (उदाहरण के लिए, CONFIG_PAGE_TABLE_ISOLATION या CONFIG_UNMAP_KERNEL_AT_EL0).
[C-0-13] अगर हार्डवेयर एपीआई लेवल की मदद से भेजे जाने वाले सभी डिवाइसों पर, CVE-2017-5715 के जोखिम की आशंका है 28 या उससे ज़्यादा (उदाहरण के लिए, CONFIG_HARDEN_BRANCH_PREDICTOR).
[C-SR-1] कर्नेल डेटा को बनाए रखने के लिए इसका बहुत ज़्यादा सुझाव दिया जाता है जिसे सिर्फ़ शुरुआत करने के दौरान लिखा जाता है. इसके बाद रीड-ओनली के तौर पर निशान लगाया जाता है शुरू करना (उदाहरण के लिए, __ro_after_init).
[C-SR-2] कर्नेल कोड का लेआउट रैंडमाइज़ करने के लिए और इसका ज़बरदस्त सुझाव दिया जाता है और जोखिम से बचने के लिए, ताकि (उदाहरण के लिए, बूटलोडर एंट्रॉपी के साथ CONFIG_RANDOMIZE_BASE /chosen/kaslr-seed Device Tree node या EFI_RNG_PROTOCOL).
[C-SR-3] का इस्तेमाल करने का सुझाव दिया जाता है, ताकि कंट्रोल फ़्लो इंटिग्रिटी (सीएफ़आई) को चालू किया जा सके कर्नेल का इस्तेमाल करके, कोड का दोबारा इस्तेमाल करने से जुड़े हमलों के ख़िलाफ़ अतिरिक्त सुरक्षा दी जाती है (उदाहरण के लिए, CONFIG_CFI_CLANG और CONFIG_SHADOW_CALL_STACK).
[C-SR-4] हमारा सुझाव है कि कंट्रोल-फ़्लो इंटेग्रिटी (सीएफ़आई) को बंद न करने के लिए, इस बात पर काफ़ी ज़ोर दिया जाता है, शैडो कॉल स्टैक (SCS) या 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 ओपन सोर्स में दिए गए सिस्टम/sepolicy फ़ोल्डर के अंदर प्रोजेक्ट (AOSP) और नीति को 'कभी न अनुमति दें' वाले सभी नियमों के साथ कंपाइल करना ज़रूरी है, डिवाइस/वेंडर के खास डोमेन के साथ-साथ, AOSP SELinux डोमेन के लिए भी उपलब्ध है.
[C-1-5] एपीआई लेवल 28 या उसके बाद के लेवल को टारगेट करने वाले तीसरे पक्ष के ऐप्लिकेशन चलाना ज़रूरी है प्रति-ऐप्लिकेशन SELinux सैंडबॉक्स में प्रत्येक पर प्रति-ऐप्लिकेशन SELinux प्रतिबंधों के साथ ऐप्लिकेशन की निजी डेटा निर्देशिका का उपयोग करता है.
सिस्टम/सेवा नीति में दी गई डिफ़ॉल्ट 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, CONFIG_KASAN_HW_TAGS) ARMv9 डिवाइस, 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] भरोसेमंद ऐप्लिकेशन को सिर्फ़ उस मेमोरी को ऐक्सेस करना जिसे ऊपर दिए गए तरीके का इस्तेमाल करके, उनके साथ साफ़ तौर पर शेयर किया गया है प्रोटोकॉल का इस्तेमाल करना चाहिए. अगर डिवाइस पर Arm S-EL2 अपवाद लेवल काम करता है, तो यह को सुरक्षित पार्टिशन मैनेजर के ज़रिए लागू किया जाना चाहिए. अगर ऐसा नहीं है, तो यह TEE OS के ज़रिए लागू किया जाता है.

9.8. निजता

9.8.1. इस्तेमाल का इतिहास

Android, उपयोगकर्ता की पसंद के इतिहास को सेव करता है और इस तरह के इतिहास को मैनेज करता है: UseStatsManager.

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

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

Android, StatsLog का इस्तेमाल करके सिस्टम इवेंट सेव करता है आइडेंटिफ़ायर हैं और StatsManager और IncidentManager सिस्टम एपीआई.

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

[C-0-2] इसमें सिर्फ़ वे फ़ील्ड शामिल होने चाहिए जिनके बारे में, DEST_AUTOMATIC से मार्क किया गया है सिस्टम एपीआई क्लास IncidentManager ने घटना की रिपोर्ट बनाई.
[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] सिस्टम के भरोसेमंद उपयोगकर्ताओं के लिए, उन्हीं रूट सर्टिफ़िकेट को पहले से इंस्टॉल करना होगा सर्टिफ़िकेट देने वाली संस्था (सीए) का स्टोर, जैसा कि बताया गया है को अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट में देख लिया है.
[C-0-2] उपयोगकर्ता के रूट वाले सीए स्टोर के साथ शिप करना ज़रूरी है.
[C-0-3] उपयोगकर्ता को एक चेतावनी दिखानी होगी जो नेटवर्क ट्रैफ़िक के बारे में बताती है उपयोगकर्ता रूट सीए (सर्टिफ़िकेट देने वाली संस्था) के जोड़े जाने पर, निगरानी की जा सकती है.

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

[C-1-1] उपयोगकर्ता को एक चेतावनी दिखानी होगी, जो यह बताती है कि:
- उस नेटवर्क ट्रैफ़िक की निगरानी की जा सकती है.
- उस नेटवर्क ट्रैफ़िक को किसी खास वीपीएन के ज़रिए रूट किया जा रहा है वीपीएन उपलब्ध कराने वाला ऐप्लिकेशन.

अगर डिवाइस को लागू करने का कोई तरीका मौजूद है, तो वह डिफ़ॉल्ट रूप से आउट-ऑफ़-बॉक्स चालू होता है. प्रॉक्सी सर्वर या वीपीएन गेटवे के ज़रिए, नेटवर्क डेटा ट्रैफ़िक को रूट करता है (उदाहरण के लिए, android.permission.CONTROL_VPN की मदद से, वीपीएन सेवा को पहले से लोड करके, उन्हें:

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

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

[C-3-1] ज़रूरी शर्तें पूरी न करने वाले ऐप्लिकेशन के लिए, इस सुविधा को बंद करना ज़रूरी है सेटिंग के ज़रिए AndroidManifest.xml फ़ाइल में हमेशा-चालू VPN सेवा SERVICE_META_DATA_SUPPORTS_ALWAYS_ON एट्रिब्यूट की वैल्यू false को दें.

9.8.5. डिवाइस पहचानकर्ता

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

[C-0-1] डिवाइस के सीरियल नंबर का ऐक्सेस रोकना ज़रूरी है. साथ ही, जहां लागू होने वाले, IMEI/MEID, सिम का सीरियल नंबर, और अंतरराष्ट्रीय मोबाइल किसी ऐप्लिकेशन की सदस्यता की पहचान (IMSI) की जानकारी, जब तक कि यह इनमें से किसी एक शर्त को पूरा न करता हो ज़रूरतें:
- मोबाइल और इंटरनेट सेवा देने वाली कंपनी का हस्ताक्षर किया हुआ ऐप्लिकेशन है. इसकी पुष्टि डिवाइस बनाने वाली कंपनियां कर रही हैं.
- को READ_PRIVILEGED_PHONE_STATE की अनुमति दे दी गई है.
- के पास, मोबाइल और इंटरनेट सेवा देने वाली कंपनी के अधिकार हैं, जैसा कि यूआईसीसी के मोबाइल और इंटरनेट सेवा देने वाली कंपनी के खास अधिकार में बताया गया है.
- डिवाइस का मालिक या प्रोफ़ाइल का मालिक है जिसे READ_PHONE_STATE की अनुमति.
- (सिर्फ़ सिम के सीरियल नंबर/आईसीसीआईडी के लिए) स्थानीय कानूनों के मुताबिक होना ज़रूरी है सदस्य की पहचान में हुए बदलावों के बारे में ऐप्लिकेशन को पता चलता है.

9.8.6. कॉन्टेंट कैप्चर करने और ऐप्लिकेशन खोजने की सुविधा

सिस्टम एपीआई ContentCaptureService का इस्तेमाल करके, Android, AugmentedAutofillService, AppSearchGlobalManager.query या अन्य का मतलब है, और यह कैप्चर करने के लिए डिवाइस लागू करने के तरीके का इस्तेमाल करता है ऐप्लिकेशन और उपयोगकर्ता:

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

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

[C-1-1] डिवाइस में सेव किए जाने पर, ऐसे सभी डेटा को एन्क्रिप्ट (सुरक्षित) करना ज़रूरी है. यह फ़ाइल को एन्क्रिप्ट (सुरक्षित) करने के लिए, Android फ़ाइल पर आधारित एन्क्रिप्ट (सुरक्षित) करने का तरीका या किसी और तरीके का इस्तेमाल किया जा सकता है को एपीआई वर्शन 26 या इसके बाद के वर्शन के तौर पर लिस्ट किया गया है. इसकी जानकारी Cipher SDK में दी गई है.
[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 की अनुमतियों को मैनेज करने के लिए, लोगों के खर्चे का ध्यान रखना ज़रूरी है सेवाओं के पास हों और Android की अनुमतियों का पालन करते हों सेक्शन 9.1. अनुमति.
[C-SR-3] सेवाओं को दूसरी सेवाओं से अलग रखने के लिए, इस बात का बहुत ज़्यादा सुझाव दिया जाता है सिस्टम के कॉम्पोनेंट(जैसे, जो सेवा या शेयरिंग प्रोसेस आईडी को बाइंड नहीं करता) इन्हें छोड़कर:
- Telephony, संपर्क, सिस्टम यूज़र इंटरफ़ेस (यूआई), और मीडिया

SpeechRecognizer#onDeviceSpeechRecognizer() के ज़रिए Android, सुविधा देता है नेटवर्क को शामिल किए बिना, डिवाइस पर बोली पहचान करने के लिए. उपयोगकर्ता के डिवाइस पर मौजूद SpeechRecognitionr को लागू करने के लिए, नीतियों का पालन करना ज़रूरी है इस सेक्शन में बताया गया है.

9.8.7. क्लिपबोर्ड का ऐक्सेस

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

[C-0-1] क्लिपबोर्ड से क्लिप किया गया डेटा नहीं लौटाना चाहिए (उदाहरण के लिए, ClipboardManager API) से अलग से कोई मैसेज नहीं देना होगा. ऐसा तब तक होगा, जब तक तीसरे पक्ष का ऐप्लिकेशन डिफ़ॉल्ट IME न हो या ऐसा ऐप्लिकेशन हो जो फ़िलहाल, फ़ोकस मौजूद है.
[C-0-2] क्लिपबोर्ड डेटा खत्म होने के बाद, उसे कम से कम 60 मिनट में मिटा देना चाहिए जिन्हें क्लिपबोर्ड पर रखा जाता है या क्लिपबोर्ड से पढ़ा जाता है.

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

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

नीचे दी गई सूची में अलग-अलग तरह की जगहों की जानकारी दी गई है. सूची में यह जानकारी शामिल है: या उसे उपयोगकर्ता की जगह की जानकारी में बदला जा सकता है. यह पूरी जानकारी नहीं है सूची, लेकिन इसका इस्तेमाल उदाहरण के तौर पर यह बताया जाना चाहिए कि जगह की जानकारी सीधे तौर पर क्या हो सकती है या यह सीधे तौर पर नहीं मिलता:

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

9.8.9. इंस्टॉल किए गए ऐप्लिकेशन

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

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

[C-0-1] एपीआई लेवल 30 या उससे बाद के लेवल को टारगेट करने वाले किसी भी ऐप्लिकेशन के बारे में जानकारी नहीं देनी चाहिए इंस्टॉल किए गए किसी भी अन्य ऐप्लिकेशन के लिए, जब तक कि ऐप्लिकेशन पहले से ही जानकारी देखने मैनेज किए जा रहे एपीआई की मदद से, इंस्टॉल किए गए अन्य ऐप्लिकेशन के बारे में जानकारी. इसमें ये शामिल हैं, लेकिन डिवाइस से जोड़े गए किसी भी कस्टम एपीआई के ज़रिए बिना अनुमति के सार्वजनिक की गई जानकारी तक सीमित नहीं है इसके अलावा, फ़ाइल सिस्टम से ऐक्सेस किया जा सकता है.
[C-0-2] किसी ऐप्लिकेशन को नहीं देना चाहिए, किसी भी दूसरे ऐप्लिकेशन में मौजूद फ़ाइलों को पढ़ने या उनमें बदलाव करने का ऐक्सेस नहीं देना चाहिए ऐप्लिकेशन की खास तौर पर ऐप्लिकेशन के लिए बनी डायरेक्ट्री खोलें. इसके अपवाद ये हैं:
- बाहरी स्टोरेज उपलब्ध कराने वाली संस्था या निकाय (उदाहरण के लिए, DocumentsUI जैसे ऐप्लिकेशन).
- डाउनलोड की सेवा देने वाली कंपनी, जो इसके लिए “डाउनलोड” करने वाली कंपनी के अधिकार का इस्तेमाल करती है ऐप्लिकेशन के स्टोरेज पर फ़ाइलें डाउनलोड करने में मदद करता है.
- प्लैटफ़ॉर्म-साइन किए गए मीडिया ट्रांसफ़र प्रोटोकॉल (MTP) ऐप्लिकेशन जो फ़ाइलों को ट्रांसफ़र करने की सुविधा चालू करने के लिए, ACCESS_MTP खास अनुमति किसी अन्य डिवाइस पर.
- ऐसे ऐप्लिकेशन जो दूसरे ऐप्लिकेशन इंस्टॉल करते हैं और जिनके पास अनुमति है INSTALL_PACKAGES आपके पास सिर्फ़ “obb” डायरेक्ट्री ऐक्सेस करने की अनुमति है APK एक्सपैंशन फ़ाइलें.

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#allowSameSignatureAccess(), या BlobStoreManager.session#allowPublicAccess() बदलाव नहीं किया जाना चाहिए). एओएसपी रेफ़रंस को लागू करने की प्रोसेस, इन शर्तों को पूरा करती है ज़रूरतें.
[C-1-2] डिवाइस से बाहर सुरक्षित हैश नहीं भेजने चाहिए या दूसरे ऐप्लिकेशन के साथ सुरक्षित हैश शेयर नहीं करने चाहिए डेटा ब्लॉब (जिसका इस्तेमाल ऐक्सेस कंट्रोल करने के लिए किया जाता है) का है.

9.8.12. संगीत की पहचान

Android, System API MusicRecognitionManager की मदद से, संगीत की पहचान का अनुरोध करने के लिए, ऑडियो रिकॉर्ड लागू करने के लिए और संगीत की पहचान करने की सुविधा, खास अधिकार वाले ऐप्लिकेशन को देंगे. इसके अलावा, MusicRecognitionService एपीआई.

अगर डिवाइस लागू करने के तरीके में कोई ऐसी सेवा शामिल है जो System API को लागू करती है MusicRecognitionManager या मालिकाना हक वाली कोई सेवा, जो ऑडियो डेटा को जैसा कि ऊपर बताया गया है, वे:

[C-1-1] यह लागू करना ज़रूरी है कि MusicRecognitionManager के कॉलर के पास, MANAGE_MUSIC_RECOGNITION की अनुमति
[C-1-2] यह पक्का करना ज़रूरी है कि पहले से इंस्टॉल किया गया कोई एक संगीत पहचानने के लिए बनी हो ऐप्लिकेशन, MusicRecognitionService को लागू करता है.
[C-1-3] उपयोगकर्ताओं को MusicRecognitionManagerService को बदलने की अनुमति नहीं देनी चाहिए का इस्तेमाल कर सकते हैं.
[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] CE की मदद से सुरक्षित किए गए स्टोरेज को अनलॉक करने का कोई तरीका नहीं देना चाहिए उपयोगकर्ता के दिए गए क्रेडेंशियल, रजिस्टर की गई एस्क्रो कुंजी या फिर से चालू करने की प्रोसेस शुरू करें, ताकि डिवाइस को फिर से चालू किया जा सके. सेक्शन 9.9.4 में दिया गया है.
[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/adiatum पर जाएं. फ़ाइलसिस्टम मेटाडेटा फ़ाइल जैसा डेटा होता है साइज़, मालिकाना हक, मोड, और एक्सटेंडेड एट्रिब्यूट (xattrs).
[C-1-6] ज़रूरी है कि AES-256-CBC-CTS का इस्तेमाल करके फ़ाइल के नाम एन्क्रिप्ट (सुरक्षित) किए जाएं या एडिएंटम.
[C-1-12] अगर डिवाइस में ऐडवांस्ड एन्क्रिप्शन स्टैंडर्ड (AES) है निर्देश (जैसे, ARM पर आधारित डिवाइसों पर ARMv8 क्रिप्टोग्राफ़ी एक्सटेंशन या x86-आधारित डिवाइसों पर AES-NI), फिर फ़ाइल नाम के लिए ऊपर दिए गए AES-NI विकल्प, फ़ाइल कॉन्टेंट और फ़ाइल सिस्टम मेटाडेटा एन्क्रिप्शन का इस्तेमाल करना ज़रूरी है, न कि Adiantum.
[C-1-13] क्रिप्टोग्राफ़िक तरीके से मज़बूत और बदली न जा सकने वाली कुंजी का इस्तेमाल करना ज़रूरी है डेरिवेशन फ़ंक्शन (जैसे कि HKDF-SHA512), ताकि सभी ज़रूरी सब-की हासिल की जा सकें (जैसे, CE और DE पासकोड से तय करें. "क्रिप्टोग्राफ़िक तौर पर मज़बूत और इन्हें वापस नहीं लाया जा सकता" इसका मतलब है कि की डेरिवेशन फ़ंक्शन में सुरक्षा की क्षमता है कम से कम 256 बिट का हो और स्यूडोरैंडम फ़ंक्शन के तौर पर काम करता हो फ़ैमिली की मदद ली जा सकती है.
[C-1-14] एक जैसी फ़ाइल आधारित एन्क्रिप्शन (एफ़बीई) कुंजियों या सब-की का इस्तेमाल नहीं करना चाहिए का इस्तेमाल, अलग-अलग क्रिप्टोग्राफ़िक मकसद के लिए किया जा सकता है. जैसे, या दो अलग-अलग एन्क्रिप्शन एल्गोरिदम के लिए).
[C-1-15] यह पक्का करना होगा कि एन्क्रिप्ट की गई फ़ाइल के कॉन्टेंट के ऐसे सभी ब्लॉक जिन्हें नहीं मिटाया गया है और लगातार सेव किए जा सकने वाले स्टोरेज को, एन्क्रिप्शन कुंजी के कॉम्बिनेशन का इस्तेमाल करके एन्क्रिप्ट यानी सुरक्षित किया गया था और इनिशलाइज़ेशन वेक्टर (IV), जो फ़ाइल और ऑफ़सेट दोनों पर निर्भर करता है फ़ाइल से लिंक किया गया है. इसके अलावा, ऐसे सभी कॉम्बिनेशन अलग-अलग होने चाहिए, बशर्ते वे एन्क्रिप्शन, इनलाइन एन्क्रिप्शन हार्डवेयर का इस्तेमाल करके किया जाता है. यह हार्डवेयर सिर्फ़ 32 बिट की IV लंबाई.
[C-1-16] यह पक्का करना होगा कि हर बार एन्क्रिप्ट (सुरक्षित) किए गए सभी फ़ाइलों के नाम को किसी स्थायी पेज पर अलग-अलग डायरेक्ट्री में मौजूद स्टोरेज को, इनके अलग-अलग कॉम्बिनेशन का इस्तेमाल करके एन्क्रिप्ट (सुरक्षित) किया गया था एन्क्रिप्शन की और इनिशलाइज़ेशन वेक्टर (IV).
[C-1-17] यह पक्का करना ज़रूरी है कि एन्क्रिप्ट (सुरक्षित) किए गए सभी फ़ाइल सिस्टम मेटाडेटा को ब्लॉक किया गया हो स्थायी स्टोरेज को एन्क्रिप्शन कुंजी के अलग-अलग कॉम्बिनेशन का इस्तेमाल करके एन्क्रिप्ट किया गया था और इनिशलाइज़ेशन वेक्टर (IV).
CE और DE स्टोरेज की जगहों और फ़ाइल सिस्टम के मेटाडेटा की सुरक्षा करने वाली कुंजियां:
- [C-1-7] हार्डवेयर-बैक्ड कीस्टोर से क्रिप्टोग्राफ़िक तौर पर जुड़ा होना ज़रूरी है. यह कीस्टोर वेरिफ़ाइड बूट और डिवाइस के हार्डवेयर के लिए ज़रूरी है भरोसेमंद सोर्स है.
- [C-1-8] सीई कुंजियां इस्तेमाल करने वाले व्यक्ति के लॉक स्क्रीन क्रेडेंशियल से जुड़ी होनी चाहिए.
- [C-1-9] जब उपयोगकर्ता के पास लॉक स्क्रीन क्रेडेंशियल डालें.
- [C-1-10] यूनीक और अलग होना चाहिए. दूसरे शब्दों में कहें, तो किसी उपयोगकर्ता के सीई या डीई कुंजी किसी दूसरे उपयोगकर्ता की 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 कर्नेल का इस्तेमाल करके, हर उपयोगकर्ता के ब्लॉक-लेवल पर एन्क्रिप्ट (सुरक्षित) करने की सुविधा लागू की जा सकती है "डीएम-क्रिप्ट" हर उपयोगकर्ता के हिसाब से सेगमेंट में बदलाव किए जा सकते हैं.

9.9.4. फिर से चालू करने के बाद, फिर से शुरू करें

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

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

खास तौर से:

[C-0-1] CE स्टोरेज को उस हमलावर के लिए भी पढ़ने लायक नहीं होना चाहिए जिसके पास स्टोरेज है हालाँकि, डिवाइस पर ये काम किए जा सकते हैं और इनकी सीमाएं भी तय की गई हैं:
- मनचाहे तरीके से हस्ताक्षर करने के लिए, किसी भी वेंडर या कंपनी की साइनिंग कुंजी का इस्तेमाल कर सकता है मैसेज.
- इसकी वजह से डिवाइस को ओटीए मिल सकता है.
- इनके अलावा किसी भी हार्डवेयर (एपी, फ़्लैश वगैरह) के काम करने के तरीके में बदलाव कर सकता है नीचे दिए गए हैं, लेकिन इस तरह के संशोधन में कम से कम एक और एक पावर साइकल जो रैम के कॉन्टेंट को खत्म कर देता है.
- छेड़छाड़ से बचाने वाले हार्डवेयर (जैसे, Titan M) के काम करने के तरीके में बदलाव नहीं किया जा सकता.
- लाइव डिवाइस की रैम नहीं देखी जा सकती.
- उपयोगकर्ता का क्रेडेंशियल (पिन, पैटर्न, पासवर्ड) नहीं मिल सका या ऐसा नहीं करने पर उसे डाला जा सकता है.

उदाहरण के लिए, एक डिवाइस पर लागू होता है, जो सभी लागू करता है और उन पर लागू होता है यहां दिए गए ब्यौरों का इस्तेमाल करें [C-0-1] के मुताबिक होगा.

9.10. डिवाइस इंटिग्रिटी

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

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

अगर डिवाइस को लागू करने के तरीके को C-1-8 के साथ काम किए बिना पहले ही लॉन्च कर दिया गया है, तो Android के पुराने वर्शन पर 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 की सुरक्षा की पुष्टि के साथ काम करते हैं एपीआई:

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

9.11. कुंजियां और क्रेडेंशियल

Android कीस्टोर सिस्टम इससे ऐप्लिकेशन डेवलपर किसी कंटेनर में क्रिप्टोग्राफ़िक कुंजी सेव करके उनका इस्तेमाल कर सकते हैं KeyChain API की मदद से क्रिप्टोग्राफ़िक ऑपरेशन या कीस्टोर एपीआई का इस्तेमाल करें. डिवाइस पर यह सुविधा लागू करना:

[C-0-1] कम से कम 8,192 कुंजियों को इंपोर्ट या जनरेट करने की अनुमति देनी होगी.
[C-0-2] लॉक स्क्रीन की पुष्टि करने के लिए, एक समय अंतराल लागू करना ज़रूरी है के बीच पुष्टि करनी होगी. n होने पर, असफल कोशिशों की संख्या, समय 9 < के लिए अंतराल कम से कम 30 सेकंड का होना चाहिए नहीं < 30. n के लिए > 29, समय अंतराल का मान कम से कम 30*2^floor((n-30)/10)) सेकंड होना चाहिए या कम से कम 24 घंटे, जो भी कम हो.
जनरेट की जा सकने वाली कुंजियों की संख्या को सीमित नहीं किया जाना चाहिए

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

[C-1-1] कीस्टोर को लागू करने के तरीके का बैक अप अलग से एक्ज़ीक्यूशन एनवायरमेंट.
[C-1-2] आरएसए, एईएस, ईसीडीएसए, ईसीडीएच (अगर IKeyMintDevice काम करता है), 3DES, और एचएमएसी क्रिप्टोग्राफ़िक एल्गोरिदम और MD5, SHA1, और SHA-2 फ़ैमिली हैश की सुविधा, Android कीस्टोर सिस्टम के साथ काम करने वाली एल्गोरिदम ऐसे क्षेत्र में मौजूद होते हैं, जिसे इस पर चलने वाले कोड से सुरक्षित रूप से अलग कर दिया जाता है कर्नेल और उसके ऊपर का हिस्सा. सिक्योर आइसोलेशन से सभी संभावित तरीकों को ब्लॉक करना चाहिए जिससे कर्नेल या यूज़रस्पेस कोड, आइसोलेटेड एनवायरमेंट, जिसमें डीएमए भी शामिल हैं. अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट (एओएसपी) इस ज़रूरी शर्त को पूरा करने के लिए, लागू करने की प्रोसेस भरोसेमंद है, लेकिन ARM TrustZone पर आधारित कोई अन्य टूल या तीसरे पक्ष की सुरक्षित समीक्षा एक उचित हायपरवाइज़र-आधारित आइसोलेशन लागू करना वैकल्पिक है के विकल्प.
[C-1-3] आइसोलेशन के साथ लॉक स्क्रीन की पुष्टि करना ज़रूरी है एक्ज़ीक्यूशन एनवायरमेंट और यह सुविधा सफल होने पर ही, पुष्टि करने की सुविधा वाले का उपयोग किया जा सकता है. लॉक स्क्रीन के क्रेडेंशियल, इस खाते में सेव किए जाने चाहिए इस तरीके से लॉक स्क्रीन करने के लिए, सिर्फ़ आइसोलेटेड एनवायरमेंट को अनुमति मिलती है पुष्टि करने के लिए. अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट गेटकीपर हार्डवेयर ऐब्स्ट्रैक्शन लेयर (एचएएल) और Trusty शामिल है, जिसका इस्तेमाल इस ज़रूरत को पूरा करने के लिए किया जा सकता है.
[C-1-4] पुष्टि करने के लिए इस्तेमाल होने वाली कुंजी को प्रमाणित करना ज़रूरी है, जहां पुष्टि करने वाली साइनिंग कुंजी मौजूद हो सुरक्षित हार्डवेयर से सुरक्षित किया जाता है और सुरक्षित हार्डवेयर में साइन किया जाता है. प्रमाणित करने के लिए इस्तेमाल होने वाली साइनिंग कुंजियों को इतनी बड़ी संख्या में लोगों के साथ शेयर किया जाना चाहिए ताकि पासकोड का इस्तेमाल डिवाइस आइडेंटिफ़ायर के तौर पर न किया जा सके. एकतरफ़ा को पूरा करने के लिए, पुष्टि करने वाली उसी कुंजी को शेयर करना होगा. ऐसा तब तक नहीं किया जाना चाहिए, जब तक: किसी SKU की कम से कम 1,00,000 इकाइयां बनाई जाती हैं. अगर 1,00,000 से ज़्यादा यूनिट हों एक SKU बनाई जाती है, तो हर 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] पुष्टि करने के नए तरीके को पुष्टि करने के लिए, हम पिन, पैटर्न, पासवर्ड जैसे मुख्य तरीकों के इस्तेमाल का सुझाव देते हैं AOSP में लागू और उपलब्ध कराया गया.
[C-3-4] पुष्टि करने के नए तरीके को तब बंद करना ज़रूरी है, जब डिवाइस नीति नियंत्रक (DPC) ऐप्लिकेशन ने पासवर्ड सेट किया है ज़रूरी शर्तों को पूरा करने के लिए, DevicePolicyManager.setrequiredPasswordComplexity() और इसकी वैल्यू में, 10% से कम Password_COMPLExitY_NONE या DevicePolicyManager.setPassword Quality() के ज़रिए वाला तरीका जिसमें Password_QUALITY_BIOMETRIC_WEAK.
[C-3-5] पुष्टि करने के नए तरीकों का इस्तेमाल पुष्टि करने के लिए, हम पिन, पैटर्न, जैसे कि पिन, पैटर्न, पासवर्ड) को हर 72 घंटे में एक बार या उससे कम समय में या उपयोगकर्ता को पता है कि कुछ डेटा का बैकअप नहीं लिया जाएगा, ताकि सुरक्षित रखने में मदद मिलती है.

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

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

अगर बायोमेट्रिक तरीके से पुष्टि करने के तरीके ज़रूरी शर्तों को पूरा नहीं करते क्लास 3 (पहले इसे स्ट्रॉन्ग कहा जाता था) के लिए, जैसा कि इसमें बताया गया है सेक्शन 7.3.10:

[C-5-1] अगर डिवाइस पॉलिसी कंट्रोलर (DPC) से ऐप्लिकेशन ने के माध्यम से पासवर्ड आवश्यकताएं गुणवत्ता नीति सेट की है DevicePolicyManager.set requiredPasswordComplexity() PASSWORD_COMPLEXITY_LOW की तुलना में ज़्यादा प्रतिबंधात्मक जटिलता बकेट के साथ या DevicePolicyManager.setPassword Quality() का इस्तेमाल करके वह तरीका जिसमें कॉन्टिडेंटल क्वालिटी कॉन्सटेंट हो PASSWORD_QUALITY_BIOMETRIC_WEAK.
[C-5-2] उपयोगकर्ता को सुझाए गए प्राइमरी जैसा कि [C-1-7] में बताया गया है, पुष्टि करने की प्रक्रिया (उदाहरण: पिन, पैटर्न, पासवर्ड) और सेक्शन 7.3.10 में [C-1-8].
[C-5-3] इन तरीकों को सुरक्षित लॉक स्क्रीन नहीं मानना चाहिए नीचे दिए गए सेक्शन में, C-8 से शुरू होने वाली ज़रूरी शर्तों को पूरा किया जा सकता है.

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

[C-6-1] उनके पास फ़ॉल-बैक तरीका (फ़ॉल-बैक तरीका) होना चाहिए, ताकि वे सुझाए गए किसी एक विकल्प का इस्तेमाल कर सकें पुष्टि करने के मुख्य तरीके, जो एक जाने-पहचाने सीक्रेट और Meet सुरक्षित लॉक स्क्रीन के रूप में मानी जाने वाली ज़रूरतों को पूरा करती है.
[C-6-2] इस नए तरीके को बंद करना ज़रूरी है. ऐसा करने पर, स्क्रीन को अनलॉक करने के लिए पुष्टि करने के मुख्य तरीके सुझाए जाते हैं, जब डिवाइस नीति नियंत्रक (DPC) ऐप्लिकेशन ने इनमें से किसी एक के साथ नीति सेट की है:
- कॉन्टेंट बनाने 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] ज़रूरी है कि डेवलपर, Google Ads की नीतियों DevicePolicyManager क्लास, जैसे कि KEYGUARD_DISABLE_TRUST_AGENTS कॉन्स्टेंट.
[C-7-3] TrustAgentService.addEscrowToken() को पूरी तरह से लागू नहीं करना चाहिए ऐसे डिवाइस पर काम करता हो जिसे मुख्य निजी डिवाइस के तौर पर इस्तेमाल किया गया हो (उदाहरण के लिए, हैंडहेल्ड) लेकिन डिवाइस पर फ़ंक्शन को पूरी तरह से लागू किया जा सकता है जिन्हें आम तौर पर शेयर किया जाता है. उदाहरण के लिए, Android Television या वाहन संबंधित डिवाइस).
[C-7-4] Google ने जिन टोकन को सेव किया है उन्हें एन्क्रिप्ट (सुरक्षित) करना होगा 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 को अनुमति नहीं देनी चाहिए (जैसे: हैंडहेल्ड) और उनका उपयोग केवल पहले से अनलॉक किए गए डिवाइस को ज़्यादा से ज़्यादा चार घंटे. डिफ़ॉल्ट रूप से लागू AOSP में TrustManagerService इस ज़रूरी शर्त को पूरा करता है.
[C-7-12] क्रिप्टोग्राफ़िक तौर पर सुरक्षित (जैसे, UKEY2) का इस्तेमाल करना ज़रूरी है स्टोरेज से एस्क्रो टोकन भेजने के लिए कम्यूनिकेशन चैनल टारगेट डिवाइस में बदलें.

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

[C-8-1] डिवाइस नीति नियंत्रक से जुड़े होने पर, नया तरीका बंद करना ज़रूरी है (DPC) ऐप्लिकेशन ने DevicePolicyManager.setPasswordQuality() वह तरीका जिसमें कॉन्टिडेंटल क्वालिटी कॉन्सटेंट हो PASSWORD_QUALITY_NONE या DevicePolicyManager.setRequiredPasswordComplexity() और इसकी वैल्यू में, 10% से कम 'पासवर्ड_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] इसके ज़रिए, जुड़े हुए इनपुट इवेंट बनाने की सुविधा को बंद करना ज़रूरी है इससे पता चलने पर, VirtualDeviceManager DevicePolicyManager.setNearbyAppStreamingPolicy
[C-10-7] हर वर्चुअल डिवाइस के लिए, सिर्फ़ एक अलग क्लिपबोर्ड का इस्तेमाल करना होगा (या वर्चुअल डिवाइसों के लिए क्लिपबोर्ड को बंद करें)
[C-10-11] वर्चुअल डिवाइसों पर पुष्टि करने वाले यूज़र इंटरफ़ेस (यूआई) को बंद करना होगा. इसमें ये भी शामिल हैं नॉलेज फ़ैक्टर एंट्री और बायोमेट्रिक प्रॉम्प्ट
[C-10-12] वर्चुअल डिवाइस से शुरू किए गए इंटेंट को दिखाने पर पाबंदी लगानी ज़रूरी है सिर्फ़ उसी वर्चुअल डिवाइस पर
[C-10-13] उपयोगकर्ता की पुष्टि करने के लिए, वर्चुअल डिवाइस लॉक स्टेट का इस्तेमाल नहीं करना चाहिए अनुमति देने के लिए, Android कीस्टोर सिस्टम से पुष्टि करना चाहते हैं. यहां जाएं: KeyGenParameterSpec.Builder.setUserAuthentication*.

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

[C-11-1] नॉलेज-फ़ैक्टर को एन्क्रिप्ट (सुरक्षित) करने के लिए, इससे मिलती-जुलती सुरक्षा गारंटी का इस्तेमाल करना ज़रूरी है जिनमें बताया गया है कि Google Cloud कुंजी 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-4] TrustManagerService.revokeTrust() पर कॉल करना ज़रूरी है
- भरोसा देने के 24 घंटों के बाद या
- 8 घंटे की निष्क्रिय विंडो के बाद या
- अगर इन्हें लागू करने के लिए, क्रिप्टोग्राफ़िक तौर पर सुरक्षा का इस्तेमाल नहीं किया जा रहा है और सटीक रेंज, जैसा कि [C-12-5] में बताया गया है. यह रेंज, कनेक्शन के दौरान डिवाइस खो जाता है.
[C-12-5] नियमों का पालन करने के लिए, सुरक्षित और सटीक रेंज का इस्तेमाल करना [C-12-4] की ज़रूरी शर्तों के मुताबिक, इनमें से किसी एक तरीके का इस्तेमाल करना ज़रूरी है:
- यूडब्ल्यूबी टेक्नोलॉजी का इस्तेमाल करके सुविधाएं लागू करना:
  - नियमों के पालन, सर्टिफ़िकेशन, सटीक होने, और कैलिब्रेशन की ज़रूरी शर्तें के लिए, 7.4.9 में बताया गया है.
  - P-STS सुरक्षा मोड में से किसी एक का इस्तेमाल करना होगा 7.4.9.
- वाई-फ़ाई नेबरहुड अवेयरनेस नेटवर्किंग (एनएएन) का इस्तेमाल करके लागू करना:
  - इसे सटीक जानकारी देने की ज़रूरी शर्तों को पूरा करना होगा 2.2.1 [7.4.2.5/H-SR-1], 160 मेगाहर्ट्ज़ बैंडविड्थ का इस्तेमाल करें (या ) और में बताए गए मेज़रमेंट सेटअप चरणों का पालन करें. मौजूदगी का कैलिब्रेशन.
  - सुरक्षित एलटीएफ़ का इस्तेमाल करना ज़रूरी है, जैसा कि इसमें बताया गया है आईईईई 802.11az.

अगर लागू किए गए डिवाइस पर, ऐप्लिकेशन को सेकंडरी वर्चुअल डिसप्ले बनाने और उनसे जुड़े इनपुट इस्तेमाल करने की अनुमति मिलती है इवेंट जैसे कि वर्चुअलडिवाइस मैनेजर की मदद से और डिसप्ले 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] ज़रूरी है कि आपके पास ऐसा अलग सीपीयू हो जो कैश, डीरैम, और को-प्रोसेसर शेयर नहीं करता हो या ऐप्लिकेशन प्रोसेसर (AP) से जुड़े अन्य मुख्य संसाधन देख सकते हैं.
[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] हमारा सुझाव है कि हम इस हार्डवेयर को सुरक्षा टारगेट और इवैलुएशन अश्योरेंस लेवल की मदद से जांच की गई (EAL) 5, AVA_VAN.5 की मदद से बेहतर बनाया गया. EAL 5 सर्टिफ़िकेशन और आने वाली रिलीज़ में ज़रूरी हो जाए.
- [C-SR-3] इनसाइडर अटैक रेज़िस्टेंस देने के लिए इसका बहुत ज़्यादा सुझाव दिया जाता है (आईएआर), इसका मतलब है कि फ़र्मवेयर साइनिंग की ऐक्सेस रखने वाला इनसाइडर कुंजियां, फ़र्मवेयर नहीं बना सकतीं जिसकी वजह से StrongBox लीक हो जाता है सुरक्षा से जुड़ी ज़रूरी शर्तों को बायपास करने या अन्य मामलों में उपयोगकर्ता के संवेदनशील डेटा का ऐक्सेस दिया जाए. लागू करने का सुझाया गया तरीका IAR, फ़र्मवेयर अपडेट की अनुमति सिर्फ़ तब देता है, जब प्राइमरी यूज़र पासवर्ड को IAuthSecret HAL के ज़रिए उपलब्ध कराया जाता है.

9.11.3. पहचान क्रेडेंशियल

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

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

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

[C-1-1] IdentityCredentialStore#getInstance() के लिए गैर-शून्य दिखाना ज़रूरी है तरीका.
[C-1-2] पहचान क्रेडेंशियल सिस्टम को लागू करना ज़रूरी है (उदाहरण के लिए, android.security.identity.* APIs) किसी भरोसेमंद कंपनी के साथ कोड के साथ कम्यूनिकेट करने के लिए ऐसे क्षेत्र में ऐप्लिकेशन है, जो इस पर चल रहे कोड से सुरक्षित रूप से अलग रहता है कर्नेल और उसके ऊपर का हिस्सा. सिक्योर आइसोलेशन से सभी संभावित तरीकों को ब्लॉक करना चाहिए जिससे कर्नेल या यूज़रस्पेस कोड, आइसोलेटेड एनवायरमेंट, जिसमें डीएमए भी शामिल हैं.
[C-1-3] पहचान की पुष्टि करने की प्रक्रिया को लागू करने के लिए ज़रूरी क्रिप्टोग्राफ़िक ऑपरेशन क्रेडेंशियल सिस्टम (जैसे कि android.security.identity.* एपीआई) यह होना चाहिए पूरी तरह से भरोसेमंद ऐप्लिकेशन में किया जाना चाहिए. साथ ही, निजी पासकोड के लिए ज़रूरी है जब तक खास तौर से ज़रूरी न हो, तब तक अलग-अलग काम करने के माहौल को न छोड़ें एपीआई की मदद से (उदाहरण के लिए, createEphemeralKeyPair() तरीका).
[C-1-4] भरोसेमंद ऐप्लिकेशन को इस तरह से लागू किया जाना चाहिए कि सुरक्षा प्रॉपर्टी पर इसका कोई असर नहीं हुआ है (उदाहरण के लिए, क्रेडेंशियल का डेटा रिलीज़ नहीं किया गया है जब तक ऐक्सेस कंट्रोल की शर्तें पूरी नहीं हो जातीं, तब तक MAC नहीं बनाया जा सकता के हिसाब से डेटा उपलब्ध कराता है, भले ही Android दुर्व्यवहार कर रहा हो या उसके साथ छेड़छाड़ की जा रही हो.

अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट एक रेफ़रंस देता है भरोसेमंद ऐप्लिकेशन को लागू करना (गै़र-ज़रूरी) जिसका इस्तेमाल पहचान क्रेडेंशियल सिस्टम को लागू करने के लिए किया जा सकता है.

9.12. डेटा हटाना

लागू किए गए सभी डिवाइस:

[C-0-1] उपयोगकर्ताओं को "फ़ैक्ट्री डेटा रीसेट" करने का तरीका देना ज़रूरी है.
[C-0-2] ज़रूरी कार्रवाई करते समय, userdata फ़ाइल सिस्टम पर मौजूद सारा डेटा मिटाना होगा "फ़ैक्ट्री डेटा रीसेट".
[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] इस सॉफ़्टवेयर के लिए Android SELinux और अनुमति मॉडल को सुरक्षित वर्चुअल मशीन का मैनेजमेंट भी करता है.
[C-1-3] इसमें मौजूद नियमों में बदलाव नहीं करना चाहिए या उन्हें छोड़ना या बदलना नहीं चाहिए अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट में दिया गया सिस्टम/सेवा नीति (AOSP) और नीति को कभी भी अनुमति न देने वाले सभी नियमों के साथ कंपाइल किया जाना चाहिए.
[C-1-4] गैर-भरोसेमंद कोड (जैसे कि 3p ऐप्लिकेशन) को सुरक्षित वर्चुअल मशीन. ध्यान दें: यह विकल्प, आने वाले Android रिलीज़ में बदल सकता है.
[C-1-5] किसी सुरक्षित वर्चुअल मशीन को ऐसा कोड चलाने की अनुमति नहीं देनी चाहिए जो वह फैक्ट्री चित्र या उनके अपडेट का हिस्सा नहीं है. ऐसी कोई भी चीज़ जो कवर नहीं की गई है Android वेरिफ़ाइड बूट की सुविधा का इस्तेमाल करके (उदाहरण के लिए, इंटरनेट से डाउनलोड की गई फ़ाइलें या अलग से लोड की गई हैं) को Protected Virtual Machine में चलाने की अनुमति नहीं दी जानी चाहिए.

अगर डिवाइस, Android वर्चुअलाइज़ेशन फ़्रेमवर्क एपीआई (android.system.virtualmachine.*) के साथ काम करता है, तो कोई भी Protected Virtual Machine इंस्टेंस:

[C-2-1] वह Merchant Center में उपलब्ध सभी ऑपरेटिंग सिस्टम एक सुरक्षित वर्चुअल मशीन में वर्चुअलाइज़ेशन APEX.
[C-2-2] सुरक्षित वर्चुअल मशीन को ऑपरेटिंग सिस्टम चलाने की अनुमति नहीं देनी चाहिए जिस पर डिवाइस लागू करने वाले या ओएस वेंडर ने हस्ताक्षर न किया हो.
[C-2-3] सुरक्षित वर्चुअल मशीन को डेटा को कोड के तौर पर इस्तेमाल करने की अनुमति नहीं देनी चाहिए (उदाहरण के लिए, SELinux कभी भी execmem को अनुमति नहीं देता).
[C-2-4] इसमें मौजूद नियमों में बदलाव नहीं करना चाहिए या उन्हें छोड़ना या बदलना नहीं चाहिए अपस्ट्रीम Android ओपन सोर्स में दिया गया सिस्टम/sepolicy/माइक्रोड्रॉइड प्रोजेक्ट (AOSP).
[C-2-5] डेवलपर को सुरक्षित वर्चुअल मशीन की सुरक्षा के बारे में गहराई से जानकारी देने वाले मैकेनिज़्म को लागू करना ज़रूरी है (जैसे, pVM के लिए SELinux) और नॉन-माइक्रोड्रॉइड ऑपरेटिंग सिस्टम के लिए भी.
[C-2-6] यह पक्का करना ज़रूरी है कि अगर pVM फ़र्मवेयर की पुष्टि नहीं की जा सकती, तो वह चालू न हो में दिखाई गई है.
[C-2-7] यह पक्का करना ज़रूरी है कि pVM फ़र्मवेयर को बूट होने से मना कर दिया जाए, अगर example.img से छेड़छाड़ की गई है.

अगर डिवाइस, Android वर्चुअलाइज़ेशन फ़्रेमवर्क एपीआई (android.system.virtualmachine.*) के साथ काम करता है, तो हाइपरवाइज़र:

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

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

[C-4-1] ऐसे पीवीएम को फ़ंक्शन नहीं देना चाहिए जो Android सुरक्षा मॉडल.

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

[C-5-1] एआरटी रनटाइम अपडेट के आइसोलेटेड कंपाइलेशन के साथ काम करना ज़रूरी है.

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

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

10. सॉफ़्टवेयर के साथ काम करने से जुड़ी जांच

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

10.1. कंपैटबिलिटी टेस्ट सुइट

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

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

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

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

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

10.2. सीटीएस वेरिफ़ायर

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

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

[C-0-1] सीटीएस की पुष्टि करने वाले टूल में, लागू होने वाले सभी मामलों का सही तरीके से पालन करना ज़रूरी है.

CTS Verifier में कई तरह के हार्डवेयर की जांच की जाती है. इनमें कुछ हार्डवेयर भी शामिल हैं होना ज़रूरी नहीं है.

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

[C-0-2] उनके पास मौजूद हार्डवेयर की सभी जांचों को पास करना ज़रूरी है; उदाहरण के लिए, अगर किसी डिवाइस में एक्सलरोमीटर है, तो उसे सही तरीके से CTS Verifier में एक्सलरोमीटर टेस्ट केस.

कंपैटबिलिटी डेफ़िनिशन के तहत वैकल्पिक के तौर पर बताई गई सुविधाओं के टेस्ट केस दस्तावेज़ को छोड़ा या हटाया जा सकता है.

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

11. अपडेट किया जा सकने वाला सॉफ़्टवेयर

[C-0-1] लागू किए गए डिवाइस पर, उस सिस्टम सॉफ़्टवेयर को डाउनलोड करने में मदद मिलती है. मैकेनिज़्म को "लाइव" परफ़ॉर्म करने की ज़रूरत नहीं होती अपग्रेड करना पड़ सकता है—इसका मतलब है कि डिवाइस को रीस्टार्ट करना पड़ सकता है. किसी भी विधि का इस्तेमाल किया जा सकता है, बशर्ते कि वह डिवाइस में पहले से इंस्टॉल किया हुआ सॉफ़्टवेयर है. उदाहरण के लिए, इनमें से कोई भी तरीके इस ज़रूरी शर्त को पूरा करेंगे:
- "ओवर-द-एयर (ओटीए)" जिन्हें फिर से चालू करके, ऑफ़लाइन अपडेट के साथ डाउनलोड किया जाता है.
- "टेदर किया गया" होस्ट पीसी से USB पर अपडेट करता है.
- "ऑफ़लाइन" डिवाइस को फिर से चालू करके और हटाए जा सकने वाले स्टोरेज में मौजूद फ़ाइल से अपडेट किया जाता है.
[C-0-2] इस्तेमाल किए गए अपडेट के तरीके से उपयोगकर्ता को वाइप किए बिना अपडेट काम करना चाहिए डेटा शामिल है. इसका मतलब है कि अपडेट करने के तरीके में ऐप्लिकेशन के निजी डेटा को सुरक्षित रखना ज़रूरी है और ऐप्लिकेशन के साथ शेयर किया गया डेटा शामिल है. ध्यान दें कि अपस्ट्रीम Android सॉफ़्टवेयर में अपडेट करने का तरीका चुनना होगा जो इस ज़रूरी शर्त को पूरा करता हो.
[C-0-3] पूरे अपडेट पर हस्ताक्षर करना और डिवाइस पर अपडेट करने का तरीका जानना ज़रूरी है डिवाइस पर सेव किए गए सार्वजनिक पासकोड से, अपडेट और हस्ताक्षर की पुष्टि करना ज़रूरी है.
[C-SR-1] अपडेट को हैश करने के लिए, हस्ताक्षर करने के तरीके का बहुत ज़्यादा सुझाव दिया जाता है SHA-256 के साथ हैश किया जा सकता है. साथ ही, ECDSA NIST का इस्तेमाल करके सार्वजनिक पासकोड के साथ हैश की पुष्टि की जा सकती है पी-256.

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

[C-1-1] डिवाइस को फिर से चालू करके, ऑफ़लाइन अपडेट के साथ ओटीए डाउनलोड करने की सुविधा दी जानी चाहिए.

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

इसके अलावा, डिवाइस पर A/B सिस्टम अपडेट लागू होने चाहिए. एओएसपी इस सुविधा को बूट कंट्रोल एचएएल का इस्तेमाल करके लागू करता है.

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

[C-2-1] डिवाइस इंप्लॉयर को सॉफ़्टवेयर के ज़रिए गड़बड़ी ठीक करनी होगी जो अभी बताए गए तरीके के हिसाब से लागू किया जा सकता है.

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

[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] सभी हार्डवेयर वीडियो एन्कोडर के लिए 1080p या छोटे वीडियो एन्कोडिंग सेशन जब लोड हो रहा हो. यहां लोड करें को एक साथ 1080 से 720 पिक्सल के रूप में दिखाया गया है हार्डवेयर वीडियो कोडेक इस्तेमाल करके, सिर्फ़ वीडियो ट्रांसकोडिंग सेशन 1080 पिक्सल की ऑडियो-वीडियो रिकॉर्डिंग शुरू करना. Dolby विज़न कोडेक के लिए, कोडेक शुरू होने में 50 मि॰से॰ या इससे कम समय लगना चाहिए.
- [5.1/H-1-12] सभी हार्डवेयर वीडियो डिकोडर के लिए, 1080 पिक्सल या उससे छोटे वीडियो डिकोड करने का सेशन जब लोड हो रहा हो. यहां लोड करें को एक साथ 1080 से 720 पिक्सल के रूप में दिखाया गया है हार्डवेयर वीडियो कोडेक इस्तेमाल करके, सिर्फ़ वीडियो ट्रांसकोडिंग सेशन 1080p ऑडियो-वीडियो प्लेबैक शुरू करना. Dolby विज़न कोडेक के लिए, कोडेक शुरू होने में 50 मि॰से॰ या इससे कम समय लगना चाहिए.
- [5.1/H-1-13] सभी ऑडियो डिकोडर के लिए, 128 केबीपीएस या इससे कम बिटरेट वाला ऑडियो डिकोडिंग सेशन लोड नहीं किया जा सकता. यहां लोड करें को सिर्फ़ 1080 पिक्सल से 720 पिक्सल वाले वीडियो के तौर पर दिखाया गया है 1080p के साथ हार्डवेयर वीडियो कोडेक का इस्तेमाल करके ट्रांसकोडिंग सेशन ऑडियो-वीडियो प्लेबैक शुरू करना.

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] ज़रूरी है कि आपने कोई ऐसी गतिविधि की हो जो सेटिंग#ACTION_SETTINGS_VERSION_DEEP_LINK_ACTIVITY इंटेंट तय करें. गतिविधि को इनसे सुरक्षित किया जाना चाहिए: android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK और यह ज़रूरी है इससे पार्स किए गए इंटेंट की गतिविधि शुरू करें सेटिंग#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] जीपीएस/जीएनएसएस को अतिरिक्त सेंसर के साथ फ़्यूल करके, जगह की जानकारी का पता लगा सकता है. अगर Location को घातक नहीं माना गया है, इसलिए संबंधित सेंसर टाइप और/या वाहन के प्रॉपर्टी आईडी इस्तेमाल किया गया.
- [7.3/A-~~0-2~~0-4] जगह LocationManager#requestLocationLocation() के ज़रिए अनुरोध किया गया मैप से मेल खाना चाहिए.

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

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

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

[C-2-1] इंटेंट को हैंडल करना ज़रूरी है इसके लिए यूज़र इंटरफ़ेस (यूआई) लॉन्च करने के लिए ContactsContract.Settings.ACTION_SET_DEFAULT_ACCOUNT खाता चुनना और जब कोई खाता चुना गया.

[C-2-2] मैसेज को हैंडल करते समय, खाते की डिफ़ॉल्ट सेटिंग का पालन करना ज़रूरी है Intent.ACTION_INSERT and Intent.ACTION_INSERT_OR_EDIT ContactsContracts.Contacts.CONTENT_TYPE और ContactsContract.RawContacts.CONTENT_TYPE को शुरुआत में जोड़ें.

नई ज़रूरी शर्तें खत्म करना
3.2.3.5. कंडिशनल (शर्त के साथ) ऐप्लिकेशन इंटेंट
बदलाव देखें

[2.2.3 में ले जाया गया]
यदि डिवाइस कार्यान्वयन का सेटिंग ऐप्लिकेशन किसी स्प्लिट करने की सुविधा, गतिविधि एम्बेड करने की सुविधा का इस्तेमाल करते हैं.

[C-17-1] ऐसी कोई गतिविधि होनी चाहिए जो बांटने की सुविधा चालू होने पर, Settings#ACTION_SETTINGS_googleblog_DEEP_LINK_ACTIVITY इंटेंट. गतिविधि को android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK से सुरक्षित करना ज़रूरी है और इसे इससे पार्स किए गए इंटेंट की गतिविधि शुरू करें सेटिंग#additional_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] ज़रूरी शर्तों को पूरा करने के लिए इस बात पर ज़ोर दिया जाता है कि मानक संगठनों की ओर से तय किए जाने वाले सर्टिफ़िकेशन टेस्ट. इनमें ये शामिल हैं एफ़आईआरए, सीसीसी और सीएसए.

नई ज़रूरी शर्तें खत्म करना
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 इस्तेमाल करना ज़रूरी है एसएमएस मैनेजर मैसेज (एसएमएस) और मल्टीमीडिया मैसेज (एमएमएस) भेजने और पाने के दौरान एपीआई की सुविधा. एओएसपी का रेफ़रंस पैकेज/ऐप्लिकेशन/मैसेज में लागू करने की प्रक्रिया इस ज़रूरी शर्त को पूरा करती है.
- [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] इस नीति के तहत किसी भी SubscriptionInfo को दिखाने या उसे कंट्रोल करने की अनुमति नहीं देनी चाहिए शून्य के अलावा ग्रुप UUID और ऑपर्च्यूनिस्टिक बिट दिखाने में आसान है जो सिम कार्ड की सेटिंग को कॉन्फ़िगर करने या कंट्रोल करने की अनुमति देता है.
अगर डिवाइस लागू करने के तरीके में ~~जीएसएम या सीडीएमए टेलीफ़ोनी शामिल है~~तो android.hardware.telephony सुविधा जोड़ें और सिस्टम स्टेटस बार दें. इसके बाद:
- [C-6-7-1] ज़रूरी है कि दिए गए समय के लिए, प्रतिनिधि के तौर पर चालू सदस्यता चुनें यूयूआईडी ग्रुप बनाएं उपयोगकर्ता को सिम की स्थिति उपलब्ध कराने वाली किसी भी कीमत पर दिखाया जा सकता है जानकारी. इस तरह की सुविधाओं के उदाहरणों में, स्टेटस बार मोबाइल नेटवर्क भी शामिल है सिग्नल आइकॉन या क्विक सेटिंग टाइल.
- [C-SR-1] इस बात पर काफ़ी ज़ोर दिया जाता है कि प्रतिनिधि सदस्यता CANNOT TRANSLATE ऐक्टिव डेटा की सदस्यता जब तक कि डिवाइस किसी कॉल के दौरान इस बात पर ज़ोर दिया जाता है कि सदस्यता, ऐक्टिव वॉइस सदस्यता है.
अगर किसी डिवाइस पर ~~जीएसएम या सीडीएमए टेलीफ़ोनी शामिल है~~, तो 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] किसी भी वैल्यू को सेट करने पर, IllegalArgumentException डालना ज़रूरी है पसंदीदा या अनुमति वाले नेटवर्क टाइप के बिटमास्क में 3GPP2 नेटवर्क टाइप.
- [C-89-3] आपको TelephonyManager#getMeid.
अगर डिवाइस लागू करने के तरीके में एक से ज़्यादा पोर्ट और प्रोफ़ाइल वाले eUICC काम करते हैं, तो ये:
- [C-1110-1] ज़रूरी है कि android.hardware.telephony.euicc.mep फ़ीचर फ़्लैग.
7.4.9. यूडब्ल्यूबी
बदलाव देखें

अगर डिवाइस इंप्लिमेंटेशन रिपोर्ट पर सुविधा काम करती है android.hardware.uwb android.content.pm.PackageManager क्लास, अगर डिवाइस को लागू करने के तरीके में सहायता शामिल है के लिए 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] ज़रूरी शर्तों को पूरा करने के लिए इस बात पर ज़ोर दिया जाता है कि मानक संगठनों की ओर से तय किए जाने वाले सर्टिफ़िकेशन टेस्ट. इनमें ये शामिल हैं एफ़आईआरए, सीसीसी और सीएसए.
- [C-1-16] यह ज़रूरी है कि दूरी की माप, 95% के लिए +/-15 सें॰मी॰ के अंदर हो में 1 मीटर की दूरी पर, लाइन ऑफ़ विज़ुअल एनवायरमेंट में माप के पैमाना नॉन-रिफ़्लेक्टिव चैंबर.
- [C-1-27] यह पक्का करना ज़रूरी है कि दूरी के माप का मीडियन 1 मीटर पर हो रेफ़रंस डिवाइस से [0.75m, 1.25m] के अंदर है, जहां ज़मीनी हकीकत है दूरी को DUT के ऊपरी किनारे से मापा जाता है. इसे ऊपर की ओर और झुकाकर रखा जाता है 45 डिग्री.
- [C-SR-2] मेज़रमेंट सेटअप करने के चरणों को पूरा करने का सुझाव दिया जाता है इसमें बताया गया है मौजूदगी को कैलिब्रेट करने के लिए ज़रूरी शर्तें.
हमारा सुझाव है कि आप मेज़रमेंट का पालन करें सेटअप करने के तरीके, मौजूदगी कैलिब्रेशन की ज़रूरी शर्तों में बताए गए हैं.

नई ज़रूरी शर्तें खत्म करना
7.8.2.2. डिजिटल ऑडियो पोर्ट

बदलाव देखें

हेडसेट और अन्य यूएसबी-सी कनेक्टर का इस्तेमाल करके और उसे लागू करने वाली ऑडियो ऐक्सेसरी (यूएसबी ऑडियो क्लास) जैसा कि Android यूएसबी हेडसेट की खास बातों में बताया गया है.

19 अक्टूबर, 2022

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

2.2.3 सॉफ़्टवेयर
बदलाव देखें

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

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

3.2.3.5. कंडिशनल (शर्त के साथ) ऐप्लिकेशन इंटेंट
बदलाव देखें

यदि डिवाइस कार्यान्वयन का सेटिंग ऐप्लिकेशन किसी स्प्लिट करने की सुविधा, गतिविधि एम्बेड करने की सुविधा का इस्तेमाल करके, फिर वे:
- [C-17-1] ऐसी कोई गतिविधि होनी चाहिए जो सेटिंग#ACTION_SETTINGS_VERSION_DEEP_LINK_ACTIVITY इंटेंट तय करें. गतिविधि को सुरक्षित रखना ज़रूरी है android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK की पेशकश और यह इससे पार्स किए गए इंटेंट की गतिविधि शुरू करनी होगी सेटिंग#additional_SETTINGS_VERSIONDED_DEEP_LINK_INTENT_uri.
अगर डिवाइस लागू करने के तरीके VoiceInteractionService के साथ काम करते हैं और उनमें ये भी काम करते हैं एक बार में इंस्टॉल किए गए इस API का उपयोग करके एक से ज़्यादा ऐप्लिकेशन इंस्टॉल करते हैं, तो वे:
- [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 मिनट से ज़्यादा काम करते हैं और टाइम आउट होने पर पता बदल देते हैं. ऐसा उपयोगकर्ता की निजता को सुरक्षित रखने के लिए किया जाता है जब डिवाइस, स्कैन करने के लिए BLE का इस्तेमाल कर रहा हो या विज्ञापन. टाइमिंग हमलों से बचने के लिए, टाइम आउट इंटरवल को भी बिना किसी क्रम के रखा जाना चाहिए 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 वर्चुअलाइज़ेशन फ़्रेमवर्क के हिसाब से काम करता है APIs (android.system.virtualmachine.*), फिर कोई Protected Virtual Machine उदाहरण:
- [C-2-4] इसमें मौजूद नियमों में बदलाव नहीं करना चाहिए या उन्हें छोड़ना या बदलना नहीं चाहिए अपस्ट्रीम Android ओपन सोर्स में दिया गया सिस्टम/sepolicy/माइक्रोड्रॉइड प्रोजेक्ट (AOSP).
अगर डिवाइस, 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() जब पीछे जाने का जेस्चर यह होता है चुने गए बटन पर क्लिक करें या 'वापस जाएं' बटन रिलीज़ किया गया हो (UP).
  
  [7.2.3/H-0-7] कॉल करना ज़रूरी है OnBackInvokedCallback.onBackCancelled() जब पीछे जाने का जेस्चर न हो तय नहीं किया गया है या KEYCODE_BACK इवेंट रद्द हो जाता है.
  
  नई ज़रूरी शर्तें खत्म करना
  अगर डिवाइसों पर, वाई-फ़ाई नेबर अवेरनेस नेटवर्किंग (एनएएन) प्रोटोकॉल का इस्तेमाल किया जाता है, तो PackageManager.FEATURE_WIFI_AWARE और वाई-फ़ाई की जगह की जानकारी (वाई-फ़ाई राउंड) का एलान किया जा रहा है यात्रा का समय — आरटीटी) और PackageManager.FEATURE_WIFI_RTT का एलान करने पर, वे:
  
  [7.4.2.5/H-1-1] ज़रूरी है कि रेंज की सटीक जानकारी 68वें पर्सेंटाइल पर 160 मेगाहर्ट्ज़ बैंडविथ पर +/-1 मीटर के अंदर (जैसा कि कैलकुलेट किया गया है) क्यूमुलेटिव डिस्ट्रिब्यूशन फ़ंक्शन के साथ), 80 मेगाहर्ट्ज़ बैंडविड्थ पर +/-2 मीटर 68वें पर्सेंटाइल पर है, 68वें दिन, 40 मेगाहर्ट्ज़ बैंडविड्थ पर +/-4 मीटर और 68वें पर्सेंटाइल पर 20 मेगाहर्ट्ज़ बैंडविड्थ पर +/-8 मीटर 10 सेमी, 1 मीटर, 3 मीटर, और 5 मीटर की दूरी. WifiRttManager#startRanging Android API.
  
  [7.4.2.5/H-SR] 90वें पर्सेंटाइल पर 160 मेगाहर्ट्ज़ बैंडविड्थ के अंदर +/-1 मीटर के अंदर रेंज की सटीक जानकारी देने का सुझाव दिया जाता है. कुल फ़्रीक्वेंसी का डिस्ट्रिब्यूशन फ़ंक्शन के हिसाब से, 80 मेगाहर्ट्ज़ की दूरी पर +/-2 मीटर, 90 मेगाहर्ट्ज़ बैंडविथ पर +/-4 मीटर और 40 मेगाहर्ट्ज़ बैंडविथ पर 90 मेगाहर्ट्ज़ बैंडविथ पर +/-4 मीटर और 40 मेगाहर्ट्ज़ बैंडविथ पर +/-1 मीटर की दूरी सटीक तरीके से होती है WifiRttManager#startRanging Android API.
  
  हमारा सुझाव है कि मेज़रमेंट सेटअप करने के लिए, यहां दिए गए चरणों को अपनाएं मौजूदगी को कैलिब्रेट करने के लिए ज़रूरी शर्तें.
  
  नई ज़रूरी शर्तें खत्म करना
- ऑडियो के इंतज़ार का समय:
  बदलाव देखें
  
  अगर हैंडहेल्ड डिवाइस लागू करने के निर्देश android.hardware.audio.output और android.hardware.microphone, वे:
  - [5.6/H-1-1] के लिए, लगातार दोतरफ़ा यात्रा का औसत होना ज़रूरी है इंतज़ार का समय 500 है ~~800~~ मिलीसेकंड या 5 से कम मापों के साथ, औसत कुल विचलन से कम 50 ~~100~~ मि॰से॰ से ज़्यादा ये डेटा पाथ: "स्पीकर टू माइक्रोफ़ोन", 3.5 मि॰मी॰ का लूपबैक अडैप्टर (अगर काम करता है), यूएसबी लूपबैक (अगर काम करता है). ~~इस्तेमाल की जा सकने वाली कम से कम एक सुविधा पाथ.~~
  [5.6/H-1-1] टैप-टू-टोन के दौरान इंतज़ार का औसत समय होना चाहिए स्पीकर पर 500 मिलीसेकंड या कम से कम पांच से कम दूरी पर से माइक्रोफ़ोन डेटा पाथ में जोड़ा जा सकता है.
  
  नई ज़रूरी शर्तें खत्म करना
- हैप्टिक इनपुट:
  बदलाव देखें
  
  अगर हैंडहेल्ड डिवाइस में कम से कम एक हैप्टिक एक्चुएटर शामिल है, तो वे:
  - [7.10/H]* एक बहुत ज़्यादा रोटेटिंग मास (ईआरएम) का इस्तेमाल नहीं करना चाहिए हैप्टिक एक्चुएटर (वाइब्रेटर).
  - [7.10/H]* एक्चुएटर के प्लेसमेंट की जगह तय करनी चाहिए उस जगह के पास जहां डिवाइस आम तौर पर हाथ से पकड़ा या छूता है.
  - [7.10/H]* क्लियर हैप्टिक android.view.HapticFeedbackConstants में जाकर नाम है (CLOCK_TICK, context_Click, KEY एल्बम_PRESS, KEY एल्बम_ हटाए, KEYबोर्ड_TAP, LONG_PRESS, TEXT_HANDLE_मूव, VIRTUAL_KEY, VIRTUAL_KEY_ रिलीज़, पुष्टि, अस्वीकार करें, GESTURE_START, और GESTURE_END).
  - [7.10/H]* क्लियर हैप्टिक android.os.Vibrationimpact में इनके नाम हैं (म्फट_टीआईके, इफ़ेक्ट_क्लिक, इफ़ैक्ट_HEAVY_Click और ACTION_DOUBLE_Click) और सभी संभव सार्वजनिक PRIMITIVE_* इसके लिए कॉन्सटेंट रिच हैप्टिक android.os.Vibrationimpact.Composition में नाम है ~~(PRIMITIVE_Click और PRIMITIVE_TICK)~~ (Click, TICK, LOW_TICK, QUICK_FALL, QUICK_RISE, SLOW_RISE, Sपिन, THUD. इनमें से कुछ प्रिमिटिव, जैसे LOW_TICK और SMIN का इस्तेमाल सिर्फ़ तब किया जा सकता है, जब वाइब्रेटर फ़्रीक्वेंसी कम होती हैं.
  [7.10/H]* सार्वजनिक स्थिरांकों को मैप करने के दिशा-निर्देशों का पालन करना चाहिए android.view.HapticFeedback नतीजों में जाकर सुझाए गए android.os.Vibrationimpact कॉन्सटेंट के लिए, डाइमेंशन और डाइमेंशन के बारे में ज़्यादा जानकारी मिलती है.
  
  नई ज़रूरी शर्तें खत्म करना
  ~~[7.10/H]* लिंक किए गए इन हैप्टिक कॉन्सटेंट का इस्तेमाल करना चाहिए मैपिंग.~~
  [7.10/H]* इस बात की पुष्टि करनी चाहिए कि android.os.Vibrator.hasAmplitudeControl() का सार्वजनिक नतीजा क्या है एपीआई, अपने वाइब्रेटर की क्षमताओं को सही तरीके से दिखाता है.
  
  नई ज़रूरी शर्तें खत्म करना
  [7.10/H]* आयाम के लिए क्षमताओं की पुष्टि करनी चाहिए चलाकर बढ़ाए जा सकने की क्षमता android.os.Vibrator.hasAmplitudeControl().
  अगर हैंडहेल्ड डिवाइस लागू करने के तरीके में कम से कम एक लीनियर रेज़ोनेंट शामिल होता है इनके साथ काम करते हैं:
  - [7.10/H]* X-ऐक्सिस में हैप्टिक एक्चुएटर को ले जाना चाहिए (बाएं-दाएं) में से पोर्ट्रेट ओरिएंटेशन.
  - [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] का सुझाव दिया जाता है उन्हें उपयोगकर्ता का खर्च देने में मदद मिलती है. उदाहरण के लिए, “आउटपुट स्विचर”) इसे सिस्टम यूज़र इंटरफ़ेस (यूआई) से ऐक्सेस किया गया है. इसकी मदद से, उपयोगकर्ता एक से दूसरी सुविधा पर स्विच कर सकते हैं जब कोई ऐप्लिकेशन Mediaसेशन टोकन के साथ MediaStyle सूचना पोस्ट करता है, तो मीडिया रूट(जैसे कि ब्लूटूथ डिवाइस और MediaRouter2Manager को दिए गए रूट).
2.2.4 परफ़ॉर्मेंस और पावर: चलने वाले ऐप्लिकेशन के लिए नई ज़रूरी शर्तें फ़ोरग्राउंड सेवाएं शामिल हैं.
बदलाव देखें
हैंडहेल्ड डिवाइस लागू करना:
- [8.5/H-0-1] इस देश में लोगों को यह सुविधा देनी होगी सेटिंग मेन्यू की मदद से, फ़ोरग्राउंड में चल रहे ऐप्लिकेशन को रोका जा सकता है उन सभी ऐप्लिकेशन को दिखाएगा जिनमें ऐक्टिव फ़ोरग्राउंड सेवाएं हैं और इनमें से हर सेवा की अवधि के बारे में जानकारी, SDK टूल में दी गई जानकारी के हिसाब से दी गई है दस्तावेज़ होना चाहिए.
  
  कुछ ऐप्लिकेशन को हटाए जाने से छूट दी जा सकती है या उन्हें इस तरह की सूची में शामिल किए जाने से छूट दी जा सकती है उपयोगकर्ता की कीमत का डेटा, जैसा कि 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] हार्डवेयर वीडियो एन्कोडर के छह इंस्टेंस के साथ काम करना ज़रूरी है सेशन (एवीसी, एचईवीसी, VP9, AV1 या इसके बाद के वर्शन) किसी भी कोडेक से चल रहे हों 1080p रिज़ॉल्यूशन@30fps पर.
[5.1/H-1-5] हार्डवेयर वीडियो एन्कोडर की अधिकतम संख्या का विज्ञापन करना ज़रूरी है और डिकोडर सत्र जो इसके ज़रिए किसी भी कोडेक संयोजन में एक साथ चलाए जा सकते हैं CodecCapabilities.getMaxSupportedInstances() और VideoCapabilities.getSupportedPerformancePoints() तरीके इस्तेमाल करते हैं.
[5.1/H-1-6] हार्डवेयर वीडियो डिकोडर और हार्डवेयर के छह इंस्टेंस पर काम करना ज़रूरी है किसी भी कोडेक में वीडियो एन्कोडर सेशन (AVC, HEVC, VP9, AV1 या उसके बाद के वर्शन) 1080p@30fps रिज़ॉल्यूशन पर एक साथ चल रहा है.
[5.1/H-1-7] सभी हार्डवेयर वीडियो एन्कोडर के लिए 1080p या छोटे वीडियो एन्कोडिंग सेशन जब लोड हो रहा हो. यहां लोड करें को एक साथ 1080 से 720 पिक्सल के रूप में दिखाया गया है हार्डवेयर वीडियो कोडेक इस्तेमाल करके, सिर्फ़ वीडियो ट्रांसकोडिंग सेशन 1080 पिक्सल की ऑडियो-वीडियो रिकॉर्डिंग शुरू करना.
[5.1/H-1-8] सभी ऑडियो एन्कोडर के लिए 128 केबीपीएस या इससे कम बिटरेट वाला ऑडियो एन्कोडिंग सेशन लोड नहीं किया जा सकता. यहां लोड करें को सिर्फ़ 1080 पिक्सल से 720 पिक्सल वाले वीडियो के तौर पर दिखाया गया है 1080p के साथ हार्डवेयर वीडियो कोडेक का इस्तेमाल करके ट्रांसकोडिंग सेशन ऑडियो-वीडियो रिकॉर्डिंग शुरू करना.
[5.1/H-1-9] सिक्योर हार्डवेयर वीडियो डिकोडर के दो इंस्टेंस पर काम करना ज़रूरी है सेशन (एवीसी, एचईवीसी, VP9, AV1 या इसके बाद के वर्शन) किसी भी कोडेक से चल रहे हों 1080p रिज़ॉल्यूशन@30 एफ़पीएस (फ़्रेम प्रति सेकंड) पर समवर्ती रूप से.
[5.1/H-1-10] असुरक्षित हार्डवेयर वीडियो डिकोडर के तीन इंस्टेंस के साथ काम करना ज़रूरी है सिक्योर हार्डवेयर वीडियो डिकोडर सेशन के एक इंस्टेंस के साथ सेशन (कुल चार इंस्टेंस) (एवीसी, एचईवीसी, VP9, AV1 या इसके बाद के वर्शन) किसी भी कोडेक कॉम्बिनेशन में 1080p रिज़ॉल्यूशन@30fps पर एक साथ चल रहा होगा.
[5.1/ H-1-11] हर हार्डवेयर एवीसी, एचईवीसी, डिवाइस पर मौजूद VP9 या AV1 डिकोडर.
[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] 10 सेकंड में एक फ़्रेम से ज़्यादा नहीं छोड़ा जाना चाहिए 1080p 60 FPS (फ़्रेम प्रति सेकंड) वीडियो सेशन के लिए (यानी कि 0.167 प्रतिशत से कम फ़्रेम में गिरावट) लोड नहीं किया जा सकता. लोड को सिर्फ़ 1080 पिक्सल से 720 पिक्सल वाले वीडियो के तौर पर दिखाया जाता है हार्डवेयर वीडियो कोडेक इस्तेमाल करके ट्रांसकोडिंग सेशन, साथ ही 128 केबीपीएस AAC ऑडियो प्लेबैक.
[5.3/H-1-2] वीडियो के दौरान 10 सेकंड में एक से ज़्यादा फ़्रेम नहीं छोड़ना चाहिए लोड हो रहे 60 एफ़पीएस (फ़्रेम प्रति सेकंड) वाले वीडियो सेशन के रिज़ॉल्यूशन में बदलाव. लोड इस तरह से परिभाषित किया गया है हार्डवेयर का इस्तेमाल करके, एक साथ 1080 पिक्सल से 720 पिक्सल वाले वीडियो को ट्रांसकोड करने की सुविधा और साथ ही, 128 केबीपीएस AAC ऑडियो प्लेबैक.
[5.6/H-1-1] वीडियो में 80 मिलीसेकंड या इससे कम समय के लिए, टैप-टू-टोन कार्रवाई होनी चाहिए का इस्तेमाल करके,
[5.6/H-1-2] 80 मिलीसेकंड या उससे कम की दोतरफ़ा ऑडियो अवधि में, इंतज़ार का समय तय होना चाहिए कम से कम एक काम करने वाले डेटा पाथ से ज़्यादा हो.
[5.6/H-1-3] 3.5 मि॰मी॰ से ज़्यादा के ऑडियो के लिए, स्टीरियो आउटपुट के लिए 24-बिट ऑडियो की सुविधा ज़रूरी है जैक मौजूद होने पर और USB ऑडियो के ऊपर इंतज़ार का समय कम करने और स्ट्रीमिंग कॉन्फ़िगरेशन के लिए पूरा डेटा पाथ. कम कीमत वाले लोगों के लिए इंतज़ार का समय कम करने के लिए कॉन्फ़िगरेशन किया गया है. ऐप्लिकेशन में ऑडियो के लिए इंतज़ार का समय कम रखना चाहिए कॉलबैक मोड. स्ट्रीमिंग के लिए कॉन्फ़िगरेशन के तहत, ऐप्लिकेशन को 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 चैनल के यूएसबी ऑडियो डिवाइस पर काम करना ज़रूरी है (इसका इस्तेमाल DJ करता है कंट्रोलर का इस्तेमाल करके गाने की झलक सुन सकते हैं.)
[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.T मिलता है android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS के लिए आज़माएं, इसके बाद वे:
- [7.5/H-1-1] फ़ोन के पीछे वाला मुख्य कैमरा होना चाहिए, जिसका रिज़ॉल्यूशन 4k@30fps पर वीडियो कैप्चर करने की सुविधा देने वाले कम से कम 12 मेगापिक्सल का वर्शन. मुख्य पीछे वाला कैमरा, पीछे वाला कैमरा होता है, जिसका आईडी सबसे कम होता है.
- [7.5/H-1-2] सामने वाला मुख्य कैमरा होना चाहिए, जिसका रिज़ॉल्यूशन यह कम से कम 5 मेगापिक्सल की क्वालिटी में और 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] Camera2 JPEG फ़ॉर्मैट में वीडियो रिकॉर्ड करने में लगने वाला समय होना ज़रूरी है < 1000 मि॰से॰ के लिए 1080 पिक्सल रिज़ॉल्यूशन, जिसे आईटीएस के सीटीएस कैमरा परफ़ॉर्मेंसटेस्ट की मदद से मापा जाता है दोनों प्राइमरी कैमरों के लिए लाइटिंग की स्थिति (3,000K).
- [7.5/H-1-6] Camera2 ऐप्लिकेशन के चालू होने में लगने वाला समय होना ज़रूरी है (पहली झलक के लिए कैमरा चालू करें फ़्रेम) < आईटीएस के तहत सीटीएस कैमरा परफ़ॉर्मेंसटेस्ट की मदद से मापा गया 500 मि॰से॰ दोनों प्राइमरी कैमरों के लिए लाइटिंग की स्थिति (3,000K).
- [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.T फ़ंक्शन लागू होता है, तो android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, इसके बाद:
- [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.T फ़ंक्शन लागू होता है, तो android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, इसके बाद:
- [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-ऐक्सिस एक्सलरोमीटर और 3-ऐक्सिस जाइरोस्कोप की शर्तों के साथ-साथ एक्सटीरियर व्यू कैमरे के लिए ज़रूरी शर्तें.
बदलाव देखें

वाहन संबंधित डिवाइस पर विज्ञापन लागू करना:
- [7.3.1/A-0-4] ज़रूरी है कि वह Android का पालन करे कार सेंसर कोऑर्डिनेट सिस्टम.
- [7.3/A-SR] 3-ऐक्सिस को शामिल करने के लिए, काफ़ी हद तक ज़रूरी है एक्सलरोमीटर और 3-ऐक्सिस जाइरोस्कोप.
- [7.3/A-SR] लागू करने और रिपोर्ट करने के लिए STRONGLY_सुझाया गया तरीका इस्तेमाल किया गया TYPE_HEADING सेंसर.
अगर वाहन संबंधित डिवाइस में एक्सलरोमीटर शामिल है, तो:
- [7.3.1/A-1-1] इवेंट की रिपोर्ट, फ़्रीक्वेंसी के हिसाब से दी जा सकती है कम से कम 100 हर्ट्ज़.
अगर डिवाइस लागू करने के तरीके में 3-ऐक्सिस एक्सलरोमीटर शामिल है, तो वे:
- [7.3.1/A-SR] हमारी सलाह है कि सीमित ऐक्सिस एक्सलरोमीटर के लिए कंपोज़िट सेंसर.
अगर Automotive डिवाइस में लागू किए गए एक्सलरोमीटर से कम 3 ऐक्सिस से:
- [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 हर्ट्ज़ की फ़्रीक्वेंसी होनी चाहिए.
- यह सही उत्तर के हिसाब से होना चाहिए.
- वाहन के स्थिर रहने पर भी उपलब्ध होना चाहिए.
- रिज़ॉल्यूशन कम से कम 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 सुरक्षा मॉडल: वाहन संबंधित डिवाइसों के लिए, कैमरा ऐक्सेस करने से जुड़ी अनुमतियों के लिए नई ज़रूरी शर्तें.
बदलाव देखें
अगर वाहन संबंधित डिवाइस पर लागू होने वाले android.hardware.camera.any का एलान किया जाता है, तो वे:
- [9.8.2/A-2-1] कैमरा इंंडिकेटर तब दिखाना ज़रूरी है, जब ऐप लाइव कैमरे का डेटा ऐक्सेस कर रहा है, लेकिन तब नहीं जब कैमरा सिर्फ़ बताई गई भूमिकाओं को होल्ड करने वाले ऐप्लिकेशन से ऐक्सेस किया जाता है सीडीडी आइडेंटिफ़ायर के साथ सेक्शन 9.1 की अनुमतियां [C-3-X].
- [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] ऐसी कोई गतिविधि होनी चाहिए जो सेटिंग#ACTION_SETTINGS_VERSION_DEEP_LINK_ACTIVITY इंटेंट तय करें. गतिविधि को इनसे सुरक्षित किया जाना चाहिए: android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK और यह ज़रूरी है इससे पार्स किए गए इंटेंट की गतिविधि शुरू करें सेटिंग#additional_SETTINGS_VERSIONDED_DEEP_LINK_INTENT_uri.
नई ज़रूरी शर्तें खत्म करना
3.5.1 ऐप्लिकेशन पर पाबंदी: ऐप्लिकेशन से जुड़ी पाबंदियों के बारे में अपडेट.
बदलाव देखें

अगर डिवाइस लागू करने के लिए, ऐप्लिकेशन पर पाबंदी लगाने के लिए मालिकाना हक का कोई तरीका लागू किया जाता है, तो (उदाहरण के लिए, एपीआई के ऐसे व्यवहार को बदलना या प्रतिबंधित करना जो में बताया गया है) और वह तरीका ज़्यादा है. इससे प्रतिबंधित है पाबंदी वाले ऐप्लिकेशन स्टैंडबाय बकेट, वे:
- [C-1-1] उपयोगकर्ता को पाबंदी वाले ऐप्लिकेशन की सूची देखने की अनुमति देनी होगी.
- [C-1-2] लोगों के लिए इन सभी सुविधाओं को चालू / बंद करने का अधिकार देना ज़रूरी है मालिकाना हक से जुड़ी पाबंदियों को लागू करता है.
- [C-1-3] इस नीति को बताए बिना, मालिकाना हक से जुड़ी ये पाबंदियां अपने-आप लागू नहीं होनी चाहिए इससे यह पता चलता है कि सिस्टम की परफ़ॉर्मेंस में सुधार हुआ है. हालांकि, हो सकता है कि इस दौरान ऐप्लिकेशन पर पाबंदियां लागू की जाएं सिस्टम की खराब परफ़ॉर्मेंस का पता लगाने पर, जैसे कि अटके हुए वेकलॉक, लंबे समय तक चलना सेवाओं और अन्य शर्तों को पूरा करना ज़रूरी है. ये शर्तें डिवाइस के हिसाब से तय की जा सकती हैं लागू करने वाले, लेकिन सिस्टम की परफ़ॉर्मेंस पर ऐप्लिकेशन के असर से जुड़ा होना चाहिए. किसी और तरीके से जो पूरी तरह से सिस्टम की परफ़ॉर्मेंस से जुड़े न हों. जैसे, ऐप्लिकेशन का बाज़ार में लोकप्रियता की कमी, इसे मापदंड के रूप में उपयोग नहीं किया जाना चाहिए.
- [C-1-4] ऐप्लिकेशन के लिए, मालिकाना हक से जुड़ी ये पाबंदियां अपने-आप लागू नहीं होनी चाहिए जब किसी उपयोगकर्ता ने मैन्युअल रूप से, ऐप्लिकेशन पर लगी पाबंदियों को बंद किया हो और उपयोगकर्ता को इसका सुझाव दिया जा सकता हो ताकि इन मालिकाना हक से जुड़ी पाबंदियों को लागू किया जा सके.
- [C-1-5] उपयोगकर्ताओं को यह बताना ज़रूरी है कि मालिकाना हक से जुड़ी ये पाबंदियां किसी ऐप को अपडेट करता है. ऐसी जानकारी 24 घंटे में देनी ज़रूरी है को लागू करने से पहले ध्यान दें.
- [C-1-6] इस वाक्य के लिए 'सही' होना चाहिए ActivityManager.is मंज़ूरी ट्रैकर() का तरीका इस्तेमाल करें.
- [C-1-7] उस टॉप फ़ोरग्राउंड ऐप्लिकेशन पर पाबंदी नहीं लगानी चाहिए जिसका इस्तेमाल खास तौर पर उपयोगकर्ता है.
- [C-1-8] ऐसे मामलों में, किसी ऐप्लिकेशन पर मालिकाना हक से जुड़ी इन पाबंदियों को निलंबित करना होगा उपयोगकर्ता, ऐप्लिकेशन को खास तौर पर इस्तेमाल करना शुरू कर देता है. इस वजह से, ऐप्लिकेशन का फ़ोरग्राउंड में सबसे ऊपर का इस्तेमाल करें.
- [C-1-9] मालिकाना हक से जुड़े इन सभी इवेंट की रिपोर्ट, इसके ज़रिए देनी होगी इस्तेमाल के आंकड़े.
- [C-1-10] ऐसा सार्वजनिक और साफ़ दस्तावेज़ या वेबसाइट देना ज़रूरी है जिसमें मालिकाना हक से जुड़ी पाबंदियां किस तरह लागू की जाती हैं. इस दस्तावेज़ या वेबसाइट के लिए यह ज़रूरी है कि लिंक किया जा सकता है. साथ ही, इसमें ये चीज़ें शामिल होनी चाहिए:
  
  मालिकाना हक से जुड़ी पाबंदियों के लिए शर्तें ट्रिगर करना.
  
  किसी ऐप्लिकेशन पर क्या और कैसे पाबंदी लगाई जा सकती है.
  
  किसी ऐप्लिकेशन को इस तरह की पाबंदियों से किस तरह छूट दी जा सकती है.
  
  कोई ऐप्लिकेशन अपने मालिकाना हक वाली पाबंदियों से छूट का अनुरोध कैसे कर सकता है, अगर वह में, उन ऐप्लिकेशन को छूट दी गई हो जिन्हें उपयोगकर्ता इंस्टॉल कर सकता है.
अगर कोई ऐप्लिकेशन डिवाइस पर पहले से इंस्टॉल है और उसे किसी ऐप्लिकेशन ने साफ़ तौर पर कभी इस्तेमाल नहीं किया है उपयोगकर्ता 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 (परेशान न करें) / प्राथमिकता मोड

यदि डिवाइस कार्यान्वयन 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 देखें), नाम हैं 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 Clipboard: जोड़ा गया क्लिपबोर्ड पर कॉन्टेंट के लिए नई ज़रूरी शर्तों वाला सेक्शन.
बदलाव देखें
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_मोड भेजना ज़रूरी है इंटेंट के हिसाब से, डिवाइस के मालिक के प्रावधान के बाद ट्रिगर होता है, ताकि 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 का एलान किया जाता है, लेकिन में मालिकाना हक ~~डिवाइस का मालिक~~ डिवाइस मैनेजमेंट की सुविधाओं के बारे में बताना और मैकेनिज़्म उपलब्ध कराना उनके समाधान में कॉन्फ़िगर किए गए ऐप्लिकेशन को "डिवाइस का मालिक" के तौर पर प्रमोट करने के लिए इसके बराबर" मानक "डिवाइस के मालिक" से बदल जाती है जैसा कि स्टैंडर्ड Android डिवाइस से पहचाना जाता है DevicePolicyManager एपीआई, वे:
- [C-2-1] ज़रूरी है कि एक प्रक्रिया पूरी की गई हो, ताकि इस बात की पुष्टि की जा सके कि जिनका प्रचार किसी वैध एंटरप्राइज़ डिवाइस मैनेजमेंट से किया गया हो समाधान किया गया है और उसे मालिकाना समाधान में कॉन्फ़िगर किया गया है उसके पास "डिवाइस के मालिक" के तौर पर अधिकार होने चाहिए.
- [C-2-2] इसमें एओएसपी डिवाइस के मालिक की सहमति की जानकारी दिखाना ज़रूरी है android.app.action.PROVISION_MANAGED_DEVICE ने फ़्लो शुरू किया DPC ऐप्लिकेशन को "डिवाइस के मालिक" के रूप में रजिस्टर करने से पहले.
- [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 खाता चुनना और जब कोई खाता चुना गया.
- [C-2-2] मैसेज को हैंडल करते समय, खाते की डिफ़ॉल्ट सेटिंग का पालन करना ज़रूरी है Intent.ACTION_INSERT and Intent.ACTION_INSERT_OR_EDIT ContactsContracts.Contacts.CONTENT_TYPE और ContactsContract.RawContacts.CONTENT_TYPE को शुरुआत में जोड़ें.
नई ज़रूरी शर्तें खत्म करना

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

4. ऐप्लिकेशन पैकेजिंग के साथ काम करने की सुविधा: APK सिग्नेचर स्कीम वर्शन के अपडेट.
बदलाव देखें

डिवाइस पर यह सुविधा लागू करना:
- [C-0-2] ज़रूरी शर्तें पूरी करने पर, “.apk” फ़ाइलों की पुष्टि करने में APK सिग्नेचर स्कीम v3.1 , APK सिग्नेचर स्कीम v3, APK सिग्नेचर स्कीम v2 और JAR हस्ताक्षर करने होंगे.
- [C-0-9] डेवलपर को .apk फ़ाइलों की पुष्टि करने की सुविधा देनी होगी. इसके लिए, APK सिग्नेचर स्कीम v4 और APK सिग्नेचर स्कीम v4.1 .

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

5.1.2 ऑडियो डिकोड करने की सुविधा: कई चैनलों का ऑडियो जनरेट करने वाले डिकोडर के लिए नई ज़रूरी शर्तें जोड़ी गई हैं.
बदलाव देखें
यदि डिवाइस कार्यान्वयन AAC इनपुट बफ़र के डिकोडिंग का समर्थन करते हैं डिफ़ॉल्ट रूप से, PCM में मल्टीचैनल स्ट्रीम (दो से ज़्यादा चैनल) बनाई जाती है android.media.MediaCodec एपीआई में AAC ऑडियो डिकोडर, इसके बाद: इस पर काम करता है:
- [C-7-1] यह ज़रूरी है कि ऐप्लिकेशन, डिकोडिंग का इस्तेमाल करके कॉन्फ़िगर कर सके कुंजी के साथ KEY_MAX_OUTPUT_CHANNEL_COUNT का इस्तेमाल करके, यह कंट्रोल किया जा सकता है कि कॉन्टेंट को स्टीरियो में डाउनग्रेड किया जाए या नहीं (दो वैल्यू का इस्तेमाल करने पर) या फिर, चैनलों की मूल संख्या का इस्तेमाल करके आउटपुट दिया जा रहा है (जब बराबर वैल्यू का इस्तेमाल किया जा रहा हो या उससे बड़ा होना चाहिए). उदाहरण के लिए, छह या उससे बड़ी वैल्यू कॉन्फ़िगर होगी एक डिकोडर, जो 5.1 कॉन्टेंट फ़ीड किए जाने पर 6 चैनल दिखाता है.
- [C-7-2] डिकोड करते समय, डिकोडर को इस्तेमाल किए जा रहे चैनल मास्क का विज्ञापन देना ज़रूरी है के साथ आउटपुट प्रारूप में KEY_CHANNEL_MASK कुंजी, android.media.AudioFormat कॉन्सटेंट का इस्तेमाल करके (उदाहरण: CHANNEL_OUT_5POINT1).
अगर डिवाइस लागू करने के तरीके, डिफ़ॉल्ट एएसी के अलावा किसी दूसरे ऑडियो डिकोडर के साथ काम करते हैं ऑडियो डिकोडर की मदद से, कई चैनल पर ऑडियो जनरेट किया जा सकता है. इसका मतलब है कि 2 चैनल) जब कंप्रेस किया गया मल्टी-चैनल कॉन्टेंट फ़ीड किया जाएगा, फिर:
- [C-SR] डिकोडर को इस तरह से कॉन्फ़िगर करने की बहुत ज़्यादा सलाह दी जाती है कि इसे कुंजी की मदद से डिकोड करने की सुविधा का इस्तेमाल करने वाला ऐप्लिकेशन KEY_MAX_OUTPUT_CHANNEL_COUNT का इस्तेमाल करके, यह कंट्रोल किया जा सकता है कि कॉन्टेंट को स्टीरियो में डाउनग्रेड किया जाए या नहीं (दो वैल्यू का इस्तेमाल करने पर) या फिर, चैनलों की मूल संख्या का इस्तेमाल करके आउटपुट दिया जा रहा है (जब बराबर वैल्यू का इस्तेमाल किया जा रहा हो या उससे बड़ा होना चाहिए). उदाहरण के लिए, छह या उससे बड़ी वैल्यू कॉन्फ़िगर होगी एक डिकोडर, जो 5.1 कॉन्टेंट फ़ीड किए जाने पर 6 चैनल दिखाता है.
- [C-SR] डिकोड करते समय, डिकोडर की सख्ती से सलाह दी जाती है. चैनल मास्क का इस्तेमाल, आउटपुट फ़ॉर्मैट में KEY_CHANNEL_MASK कुंजी का इस्तेमाल करें. इसके लिए, android.media.AudioFormat कॉन्सटेंट का इस्तेमाल करें (उदाहरण: CHANNEL_OUT_5POINT1).
नई ज़रूरी शर्तें खत्म करना
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 एपीआई का पालन करना ज़रूरी है साथ ही, डिवाइस पर उपलब्ध माइक्रोफ़ोन के लिए जानकारी ठीक से भरें के द्वारा तृतीय-पक्ष ऐप्लिकेशन के लिए पहुंच AudioManager.getMicrophones() API, इसका उपयोग करके सक्रिय AudioRecord के लिए 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 हर्ट्ज़ तक.

इनपुट की संवेदनशीलता को सेट करके, आवाज़ की पहचान करने वाली ऑडियो स्ट्रीम को रिकॉर्ड किया जाना चाहिए ऐसे कि 1000 हर्ट्ज़ पर 90 dB साउंड पावर लेवल (SPL) का स्रोत, 16-बिट सैंपल के लिए 2500.
- डाइमेंशन और फ़्रीक्वेंसी की तुलना में, करीब-करीब सपाट होना चाहिए मिड-फ़्रीक्वेंसी रेंज में: खास तौर पर ±3dB, हर एक के लिए 100 हर्ट्ज़ से लेकर 4000 हर्ट्ज़ तक और आवाज़ की पहचान करने वाले ऑडियो स्रोत को रिकॉर्ड करने के लिए इस्तेमाल किया जाने वाला हर माइक्रोफ़ोन.
- [C-SR] की बहुत ज़्यादा सलाह दी जाती है, ताकि वह कम से कम आयाम के लेवल दिखा सके फ़्रीक्वेंसी रेंज: खास तौर पर, फ़्रीक्वेंसी रेंज: 30 हर्ट्ज़ से 100 हर्ट्ज़ तक ±20 dB आवाज़ रिकॉर्ड करने के लिए इस्तेमाल किए जाने वाले हर माइक्रोफ़ोन के लिए, औसत फ़्रीक्वेंसी रेंज की पहचान करने वाला ऑडियो सोर्स.
- आयाम के स्तर को ऊंचाई पर दिखाने के लिए, [C-SR] का बहुत ज़्यादा सुझाव दिया जाता है फ़्रीक्वेंसी रेंज: खास तौर पर ±30 dB से लेकर 4000 हर्ट्ज़ से लेकर 22 किलोहर्ट्ज़ तक की आवाज़ रिकॉर्ड करने के लिए इस्तेमाल किए जाने वाले हर माइक्रोफ़ोन के लिए, औसत फ़्रीक्वेंसी रेंज की पहचान करने वाला ऑडियो सोर्स.
- ऑडियो इनपुट की संवेदनशीलता को इस तरह सेट करना चाहिए कि 1000 हर्ट्ज़ का साइनसॉइडल टोन सोर्स हो 90 dB साउंड प्रेशर लेवल (एसपीएल) पर चलाया गया (माइक्रोफ़ोन के बगल में मापा जाता है) 16 के लिए 1770 और 3530 की रेंज में RMS 2500 का आदर्श रिस्पॉन्स मिलता है बिट-सैंपल (या -22.35 db ±3dB फ़्लोटिंग पॉइंट/डबल प्रिसिज़न के लिए फ़ुल स्केल नमूने) के रूप में) ऑडियो सोर्स.
नई ज़रूरी शर्तें खत्म करना
5.4.6 माइक्रोफ़ोन गेन लेवल: माइक्रोफ़ोन गेन लेवल की ज़रूरी शर्तों को सेक्शन 5.4.2 में ले जाया गया.
बदलाव देखें

5.4.6. माइक्रोफ़ोन गेन लेवल [5.4.2 पर ले जाया गया]
अगर लागू किए गए डिवाइस पर android.hardware.microphone का एलान किया जाता है, तो:

डाइमेंशन और फ़्रीक्वेंसी के मुकाबले, करीब-करीब सपाट होना चाहिए मिड फ़्रीक्वेंसी रेंज में शामिल विशेषताएं: खास तौर पर, 100 में से ±3dB आवाज़ रिकॉर्ड करने के लिए इस्तेमाल किए जाने वाले हर माइक्रोफ़ोन के लिए, Hz से 4000 हर्ट्ज़ (हर्ट्ज़) की पहचान करने वाला ऑडियो सोर्स.

[C-SR] की बहुत ज़्यादा सलाह दी जाती है, ताकि वह कम से कम आयाम के लेवल दिखा सके फ़्रीक्वेंसी रेंज: खास तौर पर, 5 हर्ट्ज़ से 100 हर्ट्ज़ तक की तुलना में ±20 dB रिकॉर्ड करने के लिए इस्तेमाल किए जाने वाले हर माइक्रोफ़ोन के लिए, फ़्रीक्वेंसी को मिड-फ़्रीक्वेंसी रेंज तक का होना चाहिए आवाज़ पहचानने का ऑडियो सोर्स.

आयाम के स्तर दिखाने के लिए [C-SR] का बहुत ज़्यादा सुझाव दिया जाता है उच्च फ़्रीक्वेंसी रेंज: खास तौर पर ±30 dB से लेकर 4000 हर्ट्ज़ से लेकर 22 किलोहर्ट्ज़ तक इस्तेमाल किए गए हर माइक्रोफ़ोन की मिड फ़्रीक्वेंसी रेंज से तुलना की गई है आवाज़ पहचानने का ऑडियो सोर्स रिकॉर्ड करने के लिए.

ऑडियो इनपुट की संवेदनशीलता को इस तरह सेट करना चाहिए कि 1000 हर्ट्ज़ का साइनसॉइडल हो 90 dB साउंड प्रेशर लेवल (एसपीएल) पर चलाए गए टोन के स्रोत से जवाब मिलता है 16 बिट-सैंपल के लिए 2500 आरएमएस (या फ़्लोटिंग के लिए -22.35 dB फ़ुल स्केल) के साथ पॉइंट/डबल सटीक सैंपल) आवाज़ की पहचान करने वाला ऑडियो सोर्स रिकॉर्ड कर सकता है.
5.5.4 ऑडियो ऑफ़लोड: ऑडियो ऑफ़लोड प्लेबैक की ज़रूरी शर्तों से जुड़े अपडेट.
बदलाव देखें

अगर लागू किए गए डिवाइस पर ऑडियो ऑफ़लोड प्लेबैक काम करता है, तो ये:
- [सी-एसआर] इस सुविधा का सुझाव दिया जाता है, ताकि बिना इंटरनेट के चलाए गए ऑडियो कॉन्टेंट में काट-छांट की जा सके एक ही फ़ॉर्मैट में दो क्लिप के बीच में जब यह नियम बताए गए हों ऑडियो ट्रैक गैपलेस एपीआई और MediaPlayer के लिए मीडिया कंटेनर.
5.6 ऑडियो के लिए इंतज़ार का समय: ऑडियो के इंतज़ार का समय तय करने की ज़रूरी शर्तों से जुड़े अपडेट.
बदलाव देखें

इस सेक्शन के लिए, इन परिभाषाओं का इस्तेमाल करें:
कोल्ड आउटपुट सिग्नल में गड़बड़ी. ठंड के अलग-अलग मापों में उतार-चढ़ाव आउटपुट इंतज़ार के समय की वैल्यू.

कोल्ड इनपुट सिग्नल में गड़बड़ी. ठंड के अलग-अलग मापों में उतार-चढ़ाव इनपुट इंतज़ार के समय की वैल्यू.
अगर लागू किए गए डिवाइस पर android.hardware.audio.output का एलान किया गया है, तो इन शर्तों को पूरा करना या इनसे ज़्यादा होना ज़रूरी है:
- [C-1-2] कोल्ड आउटपुट 500 मिलीसेकंड की इंतज़ार का समय या कम.
- [C-1-3] इसका इस्तेमाल करके आउटपुट स्ट्रीम खोलना AAudioStreamBuilder_openStream() के लिए यह ज़रूरी है इसे 1,000 मिलीसेकंड से कम समय लगता है.
अगर लागू किए गए डिवाइस ने android.hardware.audio.output का एलान किया है, तो इन ज़रूरतों को पूरा करने या इन्हें पूरा करने का सुझाव दिया जाता है:
- [C-SR] स्पीकर के डेटा पर, कोल्ड आउटपुट में 100 मिलीसेकंड या उससे कम का समय लगता है पाथ. Android के इस वर्शन को चलाने वाले मौजूदा और नए डिवाइस VERY हमारा सुझाव है कि इन शर्तों को अभी पूरा करें. आने वाले प्लैटफ़ॉर्म के लिए रिलीज़ के लिए, हमें 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.hardware.audio.pro को android.content.pm.PackageManager क्लास में शामिल करते हैं, वे:
- [C-1-2] दोतरफ़ा यात्रा के ऑडियो का इंतज़ार का समय लगातार होना चाहिए, जैसा कि सेक्शन 5.6 ऑडियो के लिए इंतज़ार का समय 25 मिलीसेकंड या इससे कम ~~और यह 10 मिलीसेकंड या~~ कम से कम एक काम करने वाले पाथ से ज़्यादा.
- [C-1-5] इंतज़ार के समय और यूएसबी ऑडियो की ज़रूरी शर्तों को पूरा करना ज़रूरी है. ऑडियो नेटिव ऑडियो एपीआई और AAUDIO_PERFORMANCE_MODE_LOW_LATENCY.
- [C-1-8] टैप-टू-टोन के दौरान इंतज़ार का औसत समय होना चाहिए स्पीकर पर 80 मिलीसेकंड या कम से कम पांच से कम दूरी पर को भी माइक्रोफ़ोन डेटा पाथ में सेव किया जा सकता है.
- [C-SR] सीपीयू का एक जैसा लेवल देने के लिए, इसका बहुत ज़्यादा सुझाव दिया जाता है की परफ़ॉर्मेंस, जब ऑडियो चालू हो और सीपीयू के लोड में बदलाव हो रहा हो. इसकी जांच की जानी चाहिए Android ऐप्लिकेशन SynthMark का इस्तेमाल करके ऐसा किया जा सकता है. SynthMark, सिम्युलेटेड ऑडियो फ़्रेमवर्क पर चलने वाले सॉफ़्टवेयर सिंथेसाइज़र का इस्तेमाल करता है जो सिस्टम की परफ़ॉर्मेंस का आकलन करता है. देखें SynthMark दस्तावेज़ और उन मानदंडों को भी समझ सकें. द सिंथमार्क ऐप्लिकेशन को चलाने के लिए “ऑटोमेटेड टेस्ट” विकल्प का इस्तेमाल करके और ये नतीजे पाएं: * Voicemark.90 >= 32 आवाज़ें * Latitudemark.fixed.little <= 15 मि॰से॰ * Latitudemark.Dynamic.little <= 50 मि॰से॰
- टच इनपुट से ऑडियो तक इंतज़ार का समय दिखना चाहिए आउटपुट 40 मि॰से॰ या उसके बराबर हो.
अगर लागू किए जाने वाले डिवाइसों में 4 कंडक्टर 3.5 मि॰मी॰ का ऑडियो जैक शामिल है, तो वे:
- [C-2-1] यह ज़रूरी है कि लगातार दोतरफ़ा यात्रा के ऑडियो के लिए इंतज़ार का समय औसत हो, जैसा कि सेक्शन 5.6 ऑडियो के लिए इंतज़ार का समय, 20 मिलीसेकंड या इससे कम, 5 मिलीसेकंड से कम के औसत कुल विचलन के साथ 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 पर काम करते हैं, तो वे:
- [SR] के लिए सहायता शामिल करने का सुझाव दिया जाता है Vulkan 1.3. ~~Vulkan 1.1~~
- ज़रूरी नहीं है कि यह Vulkan वैरिएंट के वर्शन के साथ काम करे. जैसे, Vulkan का कोर वर्शन शून्य होना चाहिए).
अगर लागू किए गए डिवाइस में कोई स्क्रीन या वीडियो आउटपुट शामिल है, तो वे:
- [SR] के लिए सहायता शामिल करने का सुझाव दिया जाता है Vulkan 1.3. ~~Vulkan 1.1~~
अगर लागू किए गए डिवाइसों में Vulkan 1.0 या उसके बाद के वर्शन के साथ काम करने की सुविधा शामिल है, तो ये काम किए जा सकते हैं:
- को सहायता करनी चाहिए VkPhysicalDeviceProtectedMemoryFeatures और VK_EXT_global_priority.
- [C-1-12] इस तरह के फ़ंक्शन के लिए, सहायता की गणना नहीं करनी चाहिए VK_KHR_performance_query एक्सटेंशन.
- [C-SR] का सुझाव दिया जाता है, ताकि आप Android Baseline 2021 प्रोफ़ाइल में बताई गई ज़रूरी शर्तें.
7.2.3 नेविगेशन कुंजियां:
बदलाव देखें

डिवाइस पर यह सुविधा लागू करना:
- [C-SR] का सुझाव दिया जाता है, ताकि नेविगेशन के सभी फ़ंक्शन दिए जा सकें रद्द किया जा सकता है. 'रद्द किया जा सकता है' को रोकने की उपयोगकर्ता की क्षमता को नेविगेशन फ़ंक्शन का इस्तेमाल करने पर (उदाहरण के लिए, होम पर जाना, वापस जाना वगैरह) जब स्वाइप करने की गतिविधि एक तय सीमा से ज़्यादा हो जाती है.
नई ज़रूरी शर्तें खत्म करना
अगर उपयोगकर्ता ने पिछले पेज पर वापस जाने का नेविगेशन फ़ंक्शन दिया हो और उपयोगकर्ता ने 'वापस जाएं' को रद्द कर दिया हो जेस्चर का उपयोग करें, फिर:
- [C-8-1] OnBackInvokedCallback.onBackCancelled() पर कॉल करना ज़रूरी है.
- [C-8-2] OnBackInvokedCallback.onBackInvoked() पर कॉल नहीं किया जाना चाहिए.
- [C-8-3] KEYCODE_BACK इवेंट भेजा नहीं जाना चाहिए.
अगर बैक नेविगेशन फ़ंक्शन दिया गया है, लेकिन फ़ोरग्राउंड ऐप्लिकेशन से कोई OnBackInvokedCallback रजिस्टर न किया गया हो, इसके बाद:
- फ़ोरग्राउंड ऐप्लिकेशन के लिए सिस्टम को एक ऐनिमेशन देना चाहिए यह सुझाव देता है कि उपयोगकर्ता वापस जा रहा है, जैसा कि AOSP में बताया गया है.
अगर लागू किए गए डिवाइस, सिस्टम एपीआई setNavBarMode की मदद करते हैं, तो जिस सिस्टम ऐप्लिकेशन को android.permission.STATUS_BAR की अनुमति है उसे तो वे:
- [C-9-1] बच्चों के लिए बने आइकॉन या बटन-आधारित सुविधा देना ज़रूरी है का इस्तेमाल करें.
नई ज़रूरी शर्तें खत्म करना
7.3.1 एक्सलरोमीटर: एक्सलरोमीटर के लिए, सेंसर से जुड़ी ज़रूरी शर्तों के बारे में अपडेट.
बदलाव देखें

अगर लागू किए जाने वाले डिवाइसों में एक्सलरोमीटर, ~~3-ऐक्सिस एक्सलरोमीटर,~~ वे:
- ~~[C-1-2] इसे लागू करना और रिपोर्ट करना ज़रूरी है TYPE_ACCELEROMETER सेंसर.~~
- ~~[SR] को लागू करने के लिए काफ़ी सुझाव दिया जाता है: TYPE_SIGNIFICANT_MOTION कंपोज़िट सेंसर.~~
- [SR] को लागू करने और रिपोर्ट TYPE_ACCELEROMETER_UNCALIBRATED सेंसर. हमारा सुझाव है कि इस ज़रूरी शर्त को पूरा करने के लिए, Android डिवाइसों का इस्तेमाल करें. आने वाले समय में लॉन्च होने वाले प्लैटफ़ॉर्म पर अपग्रेड किया जा सकेगा. ज़रूरी हो जाता है.
- TYPE_SIGNIFICANT_MOTION को लागू करना चाहिए, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER कंपोज़िट के बारे में ज़्यादा जानकारी मिलेगी.
अगर डिवाइस लागू करने के तरीके में 3-ऐक्सिस एक्सलरोमीटर शामिल है, तो वे:
- [C-2-1] TYPE_ACCELEROMETER सेंसर को लागू करना और उसकी रिपोर्ट करना ज़रूरी है.
- [सी-एसआर] TYPE_SIGNIFICANT_MOTION को लागू करने का सुझाव दिया जाता है कंपोज़िट सेंसर.
- [सी-एसआर] को लागू करने और इसकी रिपोर्ट बनाने के लिए, इसका सुझाव दिया जाता है 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] लागू करने और रिपोर्ट करने के लिए STRONGLY_recommended हैं TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED सेंसर.
नई ज़रूरी शर्तें खत्म करना
अगर डिवाइस में 3-ऐक्सिस एक्सलरोमीटर और इनमें से कोई भी TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER कंपोज़िट सेंसर लागू किए गए हैं:
- [C-4-1] उनका कुल योग ऊर्जा की खपत हमेशा चार मिलीवाट से कम होनी चाहिए.
अगर डिवाइस में 3-ऐक्सिस एक्सलरोमीटर और 3-ऐक्सिस जाइरोस्कोप सेंसर शामिल हैं, तो वे:
- [C-5-1] ज़रूरी है TYPE_GRAVITY और TYPE_LINEAR_ACCELERATION कंपोज़िट सेंसर.
अगर डिवाइस में 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] वैरियंस का अंतर, हर हर हर्ट्ज़ के हिसाब से 1e-7 red^2 / s^2 से ज़्यादा नहीं होना चाहिए (वैरियंस प्रति हर्ट्ज़ या रेड^2 / s). वैरिएंस को सैंपलिंग रेट, लेकिन इस वैल्यू के लिए सीमित होना चाहिए. दूसरे शब्दों में, अगर आप जाइरो के वैरियंस को 1 हर्ट्ज़ की सैंपलिंग दर से मापें. यह इससे ज़्यादा नहीं होना चाहिए 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] लागू करने और रिपोर्ट करने के लिए STRONGLY_recommended हैं TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED सेंसर.
नई ज़रूरी शर्तें खत्म करना
अगर डिवाइस में 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) स्पूफ़ और इंपोस्टर के स्वीकार किए जाने की दर अटैक इंस्ट्रुमेंट (PAI) की ऐसी प्रजातियां जो 30% से ज़्यादा न हों, और (2) एक स्पूफ़ और लेवल B PAI की प्रजातियों की अनुमति दर 40% से ज़्यादा नहीं है, क्योंकि को Android बायोमेट्रिक्स टेस्ट प्रोटोकॉल से मेज़र किया जाता है.
नई ज़रूरी शर्तें खत्म करना
अगर डिवाइस लागू करने के तरीके में बायोमेट्रिक सेंसर को क्लास 2 के तौर पर ट्रीट करना हो (पहले कमज़ोर कहा जाता था), वे:
- [C-2-2] स्पूफ़ और इंपोस्टर के ज़रिए पेमेंट स्वीकार करने की दर 20% से ज़्यादा नहीं होनी चाहिए, के साथ (1) एक स्पूफ़ और इंपोस्टर स्वीकार दर लेवल ए प्रज़ेंटेशन अटैक इंस्ट्रुमेंट (पीएआई) की ऐसी प्रजातियां जो 20% से ज़्यादा नहीं हैं, और (2) लेवल बी पीएआई की प्रजातियों के लिए स्पूफ़ और इंपोस्टर मंज़ूरी रेट 30% से ज़्यादा है, जैसा कि Android बायोमेट्रिक्स टेस्ट प्रोटोकॉल.
अगर डिवाइस लागू करने के तरीके में बायोमेट्रिक सेंसर को क्लास 3 के तौर पर ट्रीट करना हो (पहले Strong) था, तो वे:
- [C-3-3] स्पूफ़ और इंपोस्टर के ज़रिए पेमेंट स्वीकार करने की दर 7% से ज़्यादा नहीं होनी चाहिए, इसके साथ (1) स्पूफ़ और इंपोस्टर स्वीकार करने की दर लेवल ए प्रज़ेंटेशन अटैक इंस्ट्रुमेंट (पीएआई) वाली ऐसी प्रजातियां जो 7% से ज़्यादा नहीं हैं, और (2) लेवल B वाली पीएआई की प्रजातियों के स्पूफ़ और इंपोस्टर को स्वीकार किए जाने की दर ज़्यादा नहीं है 20% से कम है, जैसा कि 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] ज़रूरी शर्तों को पूरा करने के लिए इस बात पर ज़ोर दिया जाता है कि मानक संगठनों की ओर से तय किए जाने वाले सर्टिफ़िकेशन टेस्ट. इनमें ये शामिल हैं एफ़आईआरए, सीसीसी और सीएसए.
नई ज़रूरी शर्तें खत्म करना
7.4.1 Telephony: अपडेट GSM और CDMA टेलीफ़ोनी, और मोबाइल नेटवर्क के इस्तेमाल के लिए टेलीफ़ोनी की ज़रूरतों के लिए सेटिंग.
बदलाव देखें

अगर डिवाइस लागू करने के लिए, ईयूआईसीसी या ई-सिम/एम्बेड किए गए सिम काम करते हैं और उनमें ये शामिल हैं तीसरे पक्ष के लिए ई-सिम की सुविधा उपलब्ध कराने का मालिकाना हक डेवलपर, वे:
- [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 इस्तेमाल करना ज़रूरी है एसएमएस मैनेजर मैसेज (एसएमएस) और मल्टीमीडिया मैसेज (एमएमएस) भेजने और पाने के दौरान एपीआई की सुविधा. एओएसपी का रेफ़रंस पैकेज/ऐप्लिकेशन/मैसेज में लागू करने की प्रक्रिया इस ज़रूरी शर्त को पूरा करती है.
- [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] इस तरह के मैसेज के साथ किसी भी SubscriptionInfo को दिखाने या उसे कंट्रोल करने की अनुमति नहीं देनी चाहिए शून्य के अलावा ग्रुप UUID और ऑपर्च्यूनिस्टिक बिट दिखाने में आसान है जो सिम कार्ड की सेटिंग को कॉन्फ़िगर करने या कंट्रोल करने की अनुमति देता है.
अगर डिवाइस पर इस्तेमाल किए जाने वाले डिवाइसों में GSM या CDMA टेलीफ़ोनी शामिल है और तो:
- [C-6-7] ज़रूरी है कि दिए गए विकल्प के लिए, कोई ऐसा प्रतिनिधि ऐक्टिव सदस्यता चुनें जो चालू हो यूयूआईडी ग्रुप का नाम उपयोगकर्ता को सिम की स्थिति उपलब्ध कराने वाली किसी भी कीमत पर दिखाया जा सकता है जानकारी. इस तरह की सुविधाओं के उदाहरणों में, स्टेटस बार मोबाइल नेटवर्क भी शामिल है सिग्नल आइकॉन या क्विक सेटिंग टाइल.
- [C-SR] इस बात पर काफ़ी ज़ोर दिया जाता है कि प्रतिनिधि के तौर पर ली जाने वाली सदस्यता CANNOT TRANSLATE ऐक्टिव डेटा की सदस्यता जब तक कि डिवाइस किसी कॉल के दौरान इस बात पर ज़ोर दिया जाता है कि सदस्यता, ऐक्टिव वॉइस सदस्यता है.
अगर डिवाइस लागू करने के लिए GSM या CDMA टेलीफ़ोनी शामिल है, तो:
- [C-6-8] ज़रूरी है कि डेवलपर हर ईटीएसआई टीएस 102 221 के लिए, हर यूआईसीसी के लिए लॉजिकल चैनलों की संख्या (कुल 20).
- [C-6-10] मोबाइल और इंटरनेट सेवा देने वाली चालू कंपनी के ऐप्लिकेशन पर, इनमें से कोई तरीका लागू नहीं करना चाहिए (जैसा कि TelephonyManager#getCarrierServicePackageName ने तय किया है) साफ़ तौर पर उपयोगकर्ता की पुष्टि किए बिना:
  
  नेटवर्क ऐक्सेस रद्द करना या उसे सीमित करना
  
  अनुमतियां वापस लें
  
  एओएसपी में शामिल पावर मैनेजमेंट की मौजूदा सुविधाओं के अलावा, बैकग्राउंड या फ़ोरग्राउंड ऐप्लिकेशन को एक्ज़ीक्यूट करने पर पाबंदी लगाएं
  
  ऐप्लिकेशन को बंद या अनइंस्टॉल करें
अगर डिवाइस पर इस्तेमाल किए जाने वाले डिवाइसों में GSM या CDMA टेलीफ़ोनी और सभी चालू है, गैर-अवसर वाली सदस्यताएं जो ग्रुप यूयूआईडी शेयर करते हैं उन्हें बंद कर दिया जाता है. डिवाइस से किसी फ़िज़िकल तौर पर हटाया गया या ऑपर्च्यूनिटी के तौर पर मार्क किया गया, फिर डिवाइस:
- [C-7-1] बाकी सभी चालू ऐप्लिकेशन को अपने-आप बंद करना होगा ऑपर्च्यूनिटी एक ही समूह में सदस्यताएं.
अगर लागू किए जाने वाले डिवाइसों में GSM टेलीफ़ोनी शामिल है, लेकिन CDMA टेलीफ़ोनी नहीं, तो वे:
- [C-8-1] PackageManager#FEATURE_TELEPHONY_CDMA के बारे में एलान नहीं करना चाहिए.
- [C-8-2] किसी भी टाइम ज़ोन पर,IllegalArgumentException पसंदीदा या अनुमति वाले नेटवर्क टाइप के बिटमास्क में 3GPP2 नेटवर्क टाइप.
- [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 ऑफ़लोड: सेल्युलर के लिए नया सेक्शन NAT-T कीपअलाइव ऑफ़लोड.
बदलाव देखें
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 मेगाहर्ट्ज़ बैंडविथ पर दो मीटर के अंदर सटीक होना चाहिए शतमक (क्यूमुलेटिव डिस्ट्रिब्यूशन फ़ंक्शन की मदद से कैलकुलेट किया गया).
- [सी-एसआर] सुझाव दिया जाता है, ताकि इसे 1.5 मीटर के अंदर सटीक तरीके से रिपोर्ट किया जा सके 68वें पर्सेंटाइल पर 80 मेगाहर्ट्ज़ बैंडविथ पर (जैसा कि क्यूमुलेटिव डिस्ट्रिब्यूशन फ़ंक्शन).
नई ज़रूरी शर्तें खत्म करना
7.4.2.6 वाई-फ़ाई कीपअलाइव ऑफ़लोड: सेल्युलर कीपअलाइव ऑफ़लोड से जुड़ी ज़रूरी शर्तें जोड़ने के लिए, इसे अपडेट किया गया.
बदलाव देखें

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

अगर डिवाइस एक्सटेंशन, ब्लूटूथ ऑडियो प्रोफ़ाइल की सुविधा देते हैं, तो वे:
- बेहतर ऑडियो कोडेक और ब्लूटूथ ऑडियो कोडेक के साथ काम करना चाहिए (जैसे, LDAC) A2DP के साथ.
अगर लागू किए गए डिवाइस,true BluetoothAdapter.isLeAudioSupported() एपीआई का इस्तेमाल करने के बाद:
- [C-7-1] यूनिकास्ट क्लाइंट के साथ काम करना ज़रूरी है.
- [C-7-2] 2M PHY के साथ काम करना ज़रूरी है.
- [C-7-3] एलई एक्सटेंडेड विज्ञापन के साथ काम करना ज़रूरी है.
- [C-7-4] एक CIG में, कम से कम दो सीआईएस कनेक्शन के साथ काम करना ज़रूरी है.
- [C-7-5] BAP यूनिकास्ट क्लाइंट, CSIP सेट कोऑर्डिनेटर, MCP सर्वर, वीसीपी कंट्रोलर और सीसीपी सर्वर एक साथ.
- HAP यूनिकास्ट क्लाइंट चालू करने के लिए, [सी-एसआर] का खास तौर पर सुझाव दिया जाता है.
अगर लागू किए गए डिवाइस,true BluetoothAdapter.isLeAudioBroadcastSourceSupported() एपीआई का इस्तेमाल करने के बाद:
- [C-8-1] एक BIG लाइव स्ट्रीम में, कम से कम दो BIS लिंक के साथ काम करना ज़रूरी है.
- [C-8-2] BAP ब्रॉडकास्ट सोर्स, BAP ब्रॉडकास्ट असिस्टेंट को चालू करना ज़रूरी है साथ-साथ
- [C-8-3] एलई में समय-समय पर विज्ञापन दिखाने की सुविधा होनी चाहिए.
अगर लागू किए गए डिवाइस,true BluetoothAdapter.isLeAudioBroadcastAssistantSupported() एपीआई का इस्तेमाल करने के बाद:
- [C-9-1] PAST (पीरियॉडिक ऐडवर्टाइज़िंग सिंक ट्रांसफ़र) का इस्तेमाल करना ज़रूरी है.
- [C-9-2] एलई के लिए पीरियॉडिक विज्ञापन के साथ काम करना ज़रूरी है.
अगर लागू किए गए डिवाइस पर FEATURE_BLUETOOTH_LE का एलान किया जाता है, तो:
- [C-10-1] आरएसएसआई के मेज़रमेंट की यह वैल्यू, +/-9dB के अंदर होनी चाहिए. जो रेफ़रंस डिवाइस से ट्रांसमिट हो रहा है उससे 1 मीटर की दूरी पर माप ADVERTISE_TX_POWER_HIGH, जो आस-पास मौजूद है.
- [C-10-2] हर चैनल के डेटा में उतार-चढ़ाव को कम करने के लिए, Rx/Tx में किए गए सुधार को शामिल करना ज़रूरी है ताकि हर ऐंटीना पर, 3 चैनलों में से हर एक चैनल का माप लिया जा सके (अगर एक से ज़्यादा का इस्तेमाल किया जा रहा है), तो एक-दूसरे के +/-3dB के अंदर हों. माप.
- [सी-एसआर] इस बात का सुझाव दिया जाता है कि Rx ऑफ़सेट को मेज़र करने और उसकी भरपाई करने के लिए पक्का करें कि BLE आरएसएसआई का मीडियन -60dBm +/-10 dB है. यह ADVERTISE_TX_POWER_HIGH पर ट्रांसमिट करने वाला रेफ़रंस डिवाइस, जहां डिवाइस इस तरह से नेविगेट करें कि वे 'पैरलल प्लेन' पर हों स्क्रीन बिलकुल एक जैसी तरफ़ दिशा-निर्देश.
- [सी-एसआर] इस बात का काफ़ी सुझाव दिया जाता है कि टीएक्स ऑफ़सेट को मापने और इसकी भरपाई करने के लिए, पक्का करें कि रेफ़रंस से स्कैन करते समय, आरएसएसआई का मीडियन -60dBm +/-10 dB है डिवाइस 1 मीटर की दूरी पर रखा गया है और इतनी दूरी पर ट्रांसमिट हो रहा है ADVERTISE_TX_POWER_HIGH, जहां डिवाइस इस तरह से काम करते हों कि वे चालू हों 'पैरलल प्लेन' जिनमें स्क्रीन एक ही दिशा में हों.
हमारा सुझाव है कि मौजूदगी को कैलिब्रेट करने की ज़रूरी शर्तों में बताए गए, मेज़रमेंट सेटअप के तरीकों का पालन करें.

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

अगर डिवाइस लागू करने की प्रोसेस, सुविधा android.hardware.uwb के लिए सहायता को रिपोर्ट करती है के ज़रिए android.content.pm.PackageManager क्लास का इस्तेमाल करते हैं, तो वे:
- [C-1-1] यह पक्का करना ज़रूरी है कि दूरी की माप, 95% के लिए +/-15 cm के अंदर हो में 1 मीटर की दूरी पर, लाइन ऑफ़ विज़ुअल एनवायरमेंट में माप के पैमाना नॉन-रिफ़्लेक्टिव चैंबर.
- [C-1-2] यह पक्का करना ज़रूरी है कि दूरी की माप का मीडियन 1 मीटर पर हो रेफ़रंस डिवाइस से [0.75m, 1.25m] के अंदर है, जहां ज़मीनी हकीकत है दूरी को DUT के ऊपरी किनारे से मापा जाता है. इसे ऊपर की ओर और झुकाकर रखा जाता है 45 डिग्री.
हमारा सुझाव है कि मेज़रमेंट सेटअप करने के लिए, यहां दिए गए चरणों को अपनाएं मौजूदगी को कैलिब्रेट करने के लिए ज़रूरी शर्तें.

नई ज़रूरी शर्तें खत्म करना
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 कुंजियां और क्रेडेंशियल: सुरक्षित लॉक स्क्रीन से जुड़ी ज़रूरी शर्तों से जुड़े अपडेट. इनमें ये भी शामिल हैं इसे क्रिप्टो एल्गोरिदम में ECDH और 3DES से जोड़ा गया हो.
बदलाव देखें

जब डिवाइस पर लागू होने वाला सुरक्षित लॉक स्क्रीन काम करती है, तो यह काम करता है:
- [C-1-2] आरएसए, एईएस, ईसीडीएसए, ईसीडीएच (अगर IKeyMintDevice काम करता है), 3DES, और एचएमएसी क्रिप्टोग्राफ़िक एल्गोरिदम और MD5, SHA1, और SHA-2 फ़ैमिली हैश की सुविधा, Android कीस्टोर सिस्टम के साथ काम करने वाली एल्गोरिदम ऐसे क्षेत्र में मौजूद होते हैं, जिसे इस पर चलने वाले कोड से सुरक्षित रूप से अलग कर दिया जाता है कर्नेल और उसके ऊपर का हिस्सा. सिक्योर आइसोलेशन से सभी संभावित तरीकों को ब्लॉक करना चाहिए जिससे कर्नेल या यूज़रस्पेस कोड, आइसोलेटेड एनवायरमेंट, जिसमें डीएमए भी शामिल हैं. अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट (एओएसपी) इस ज़रूरी शर्त को पूरा करने के लिए, लागू करने की प्रोसेस भरोसेमंद है, लेकिन ARM TrustZone पर आधारित कोई अन्य टूल या तीसरे पक्ष की सुरक्षित समीक्षा एक उचित हायपरवाइज़र-आधारित आइसोलेशन लागू करना वैकल्पिक है के विकल्प.
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] इसके ज़रिए, जुड़े हुए इनपुट इवेंट बनाने की सुविधा को बंद करना ज़रूरी है इससे पता चलने पर, VirtualDeviceManager DevicePolicyManager.setNearbyAppStreamingPolicy
- [C-10-7] हर वर्चुअल डिवाइस के लिए, सिर्फ़ एक अलग क्लिपबोर्ड का इस्तेमाल करना होगा (या वर्चुअल डिवाइसों के लिए क्लिपबोर्ड को बंद करें)
- [C-10-11] वर्चुअल डिवाइसों पर पुष्टि करने वाले यूज़र इंटरफ़ेस (यूआई) को बंद करना होगा. इसमें ये भी शामिल हैं नॉलेज फ़ैक्टर एंट्री और बायोमेट्रिक प्रॉम्प्ट
- [C-10-12] वर्चुअल डिवाइस से शुरू किए गए इंटेंट को दिखाने पर पाबंदी लगानी ज़रूरी है सिर्फ़ उसी वर्चुअल डिवाइस पर
- [C-10-13] उपयोगकर्ता की पुष्टि करने के लिए, वर्चुअल डिवाइस लॉक स्टेट का इस्तेमाल नहीं करना चाहिए अनुमति देने के लिए, Android कीस्टोर सिस्टम से पुष्टि करना चाहते हैं. यहां जाएं: KeyGenParameterSpec.Builder.setUserAuthentication*.
जब डिवाइस लागू करने की सुविधा से उपयोगकर्ता, मुख्य सोर्स डिवाइस से टारगेट डिवाइस तक पुष्टि करने के लिए, नॉलेज-फ़ैक्टर दिया जाता है. जैसे, टारगेट किए गए डिवाइस के शुरुआती सेट अप के दौरान ये सुविधाएं मिलती हैं:
- [C-11-1] नॉलेज-फ़ैक्टर को एन्क्रिप्ट (सुरक्षित) करने के लिए, इससे मिलती-जुलती सुरक्षा गारंटी का इस्तेमाल करना ज़रूरी है जिनमें बताया गया है कि Google Cloud कुंजी 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-4] ज़्यादा से ज़्यादा इतने समय के बाद TrustManagerService.revokeTrust() पर कॉल करना ज़रूरी है भरोसा देने के 24 घंटे, 8 घंटे तक इस्तेमाल में न रहने वाली विंडो या बुनियादी शर्तें डिवाइस का कनेक्शन टूट जाता है.
अगर लागू किए गए डिवाइस पर, ऐप्लिकेशन को सेकंडरी वर्चुअल डिसप्ले बनाने और उनसे जुड़े इनपुट इस्तेमाल करने की अनुमति मिलती है इवेंट जैसे कि वर्चुअलडिवाइस मैनेजर की मदद से और डिसप्ले VIRTUAL_DISPLAY_FLAG_SECURE से मार्क नहीं किए गए हैं, तो वे:
- [C-13-8] गतिविधियों को ब्लॉक करना ज़रूरी है android:canDisplayOnRemoteDevices या मेटा-डेटा विशेषता के साथ 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: बनाना इनसाइडर अटैक रेज़िस्टेंस (आईएआर) एक ज़रूरी शर्त है.
बदलाव देखें

इस बात की पुष्टि करने के लिए कि [C-1-3] से [C-1-9] तक का पालन किया गया है या नहीं, डिवाइस पर ये सुविधाएं लागू की जाती हैं:
- [C-SR] का सुझाव दिया जाता है, ताकि इनसाइडर अटैक रेज़िस्टेंस (आईएआर) की सुविधा देता है. इसका मतलब है कि फ़र्मवेयर साइनिंग पासकोड का ऐक्सेस रखने वाला इनसाइडर, ऐसा फ़र्मवेयर नहीं बना सकता जो इसकी वजह से StrongBox, फ़ंक्शन वाली सुरक्षा को बायपास करता है और रहस्यों को लीक करता है उपयोगकर्ता के संवेदनशील डेटा को ऐक्सेस करने की ज़रूरी शर्तें पूरी न की जाएं. कॉन्टेंट बनाने IAR लागू करने का यह सुझाव सिर्फ़ तब दिया जाता है, जब फ़र्मवेयर अपडेट मुख्य उपयोगकर्ता पासवर्ड, IAuthSecret HAL के ज़रिए दिया जाता है. इन मामलों में, आईएआर एक ज़रूरी शर्त बन जाएगा Android 14.
9.11.3 पहचान क्रेडेंशियल: पहचान क्रेडेंशियल सिस्टम रेफ़रंस को लागू करने के बारे में जानकारी जोड़ी गई.

बदलाव देखें

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

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

नई ज़रूरी शर्तें खत्म करना
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] इस सॉफ़्टवेयर के लिए Android SELinux और अनुमति मॉडल को सुरक्षित वर्चुअल मशीन का मैनेजमेंट भी करता है.
- [C-1-3] इसमें मौजूद नियमों में बदलाव नहीं करना चाहिए या उन्हें छोड़ना या बदलना नहीं चाहिए अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट में दिया गया सिस्टम/सेवा नीति (AOSP) और नीति को कभी भी अनुमति न देने वाले सभी नियमों के साथ कंपाइल किया जाना चाहिए.
- [C-1-4] गैर-भरोसेमंद कोड (जैसे कि 3p ऐप्लिकेशन) को सुरक्षित वर्चुअल मशीन. ध्यान दें: यह विकल्प, आने वाले Android रिलीज़ में बदल सकता है.
- [C-1-5] किसी सुरक्षित वर्चुअल मशीन को ऐसा कोड चलाने की अनुमति नहीं देनी चाहिए जो वह फैक्ट्री चित्र या उनके अपडेट का हिस्सा नहीं है. ऐसी कोई भी चीज़ जो कवर नहीं की गई है Android वेरिफ़ाइड बूट की सुविधा का इस्तेमाल करके (उदाहरण के लिए, इंटरनेट से डाउनलोड की गई फ़ाइलें या अलग से लोड की गई हैं) को Protected Virtual Machine में चलाने की अनुमति नहीं दी जानी चाहिए.
अगर डिवाइस, Android वर्चुअलाइज़ेशन फ़्रेमवर्क एपीआई (android.system.virtualmachine.*) के साथ काम करता है, तो कोई भी Protected Virtual Machine इंस्टेंस:
- [C-2-1] वह Merchant Center में उपलब्ध सभी ऑपरेटिंग सिस्टम एक सुरक्षित वर्चुअल मशीन में वर्चुअलाइज़ेशन APEX.
- [C-2-2] सुरक्षित वर्चुअल मशीन को ऑपरेटिंग सिस्टम चलाने की अनुमति नहीं देनी चाहिए जिस पर डिवाइस लागू करने वाले या ओएस वेंडर ने हस्ताक्षर न किया हो.
- [C-2-3] सुरक्षित वर्चुअल मशीन को डेटा को कोड के तौर पर इस्तेमाल करने की अनुमति नहीं देनी चाहिए (उदाहरण के लिए, SELinux कभी भी execmem को अनुमति नहीं देता).
- [C-2-4] इसमें मौजूद नियमों में बदलाव नहीं करना चाहिए या उन्हें छोड़ना या बदलना नहीं चाहिए अपस्ट्रीम Android ओपन सोर्स में दिया गया सिस्टम/sepolicy/माइक्रोड्रॉइड प्रोजेक्ट (AOSP).
- [C-2-5] डेवलपर को सुरक्षित वर्चुअल मशीन की सुरक्षा के बारे में गहराई से जानकारी देने वाले मैकेनिज़्म को लागू करना ज़रूरी है (जैसे, pVM के लिए SELinux) और नॉन-माइक्रोड्रॉइड ऑपरेटिंग सिस्टम के लिए भी.
- [C-2-6] यह पक्का करना ज़रूरी है कि अगर pVM फ़र्मवेयर की पुष्टि नहीं की जा सकती, तो वह चालू न हो में दिखाई गई है.
- [C-2-7] यह पक्का करना ज़रूरी है कि pVM फ़र्मवेयर को बूट होने से मना कर दिया जाए, अगर example.img से छेड़छाड़ की गई है.
अगर डिवाइस, Android वर्चुअलाइज़ेशन फ़्रेमवर्क एपीआई (android.system.virtualmachine.*) के साथ काम करता है, तो हाइपरवाइज़र:
- [C-3-1] किसी भी पीवीएम को ऐसे पेज का ऐक्सेस नहीं देना चाहिए जो किसी अन्य इकाई (जैसे, अन्य pVM या हायपरवाइज़र), जब तक कि पेज पर इसे साफ़ तौर पर शेयर न किया गया हो मालिक. इसमें होस्ट वीएम शामिल है. यह सीपीयू और डीएमए, दोनों ऐक्सेस पर लागू होता है.
- [C-3-2] किसी पेज को वीएम के इस्तेमाल के बाद और वापस करने से पहले उसे वाइप करना ज़रूरी है को होस्ट करना है (उदाहरण के लिए, pVM खत्म हो गया है).
- [C-3-3] यह पक्का करना ज़रूरी है कि pVM फ़र्मवेयर को pVM में कोई भी कोड डालें.
- [C-3-4] यह पक्का करना ज़रूरी है कि किसी पीवीएम इंस्टेंस को दिए गए गुप्त कॉपी और सीडीआई से मिली हुई है.
अगर डिवाइस, Android वर्चुअलाइज़ेशन फ़्रेमवर्क एपीआई के साथ काम करता है, सभी इलाकों में उपलब्ध कराया जाएगा:
- [C-4-1] ऐसे पीवीएम को फ़ंक्शन नहीं देना चाहिए जो Android सुरक्षा मॉडल.
अगर डिवाइस, Android वर्चुअलाइज़ेशन फ़्रेमवर्क एपीआई के साथ काम करता है, तो:
- [C-5-1] एआरटी रनटाइम अपडेट के आइसोलेटेड कंपाइलेशन के साथ काम करना ज़रूरी है.
अगर डिवाइस, Android वर्चुअलाइज़ेशन फ़्रेमवर्क एपीआई के साथ काम करता है, तो क्रिप्टोग्राफ़िक कुंजी के मैनेजमेंट के लिए:
- [C-6-1] DICE की चेन को इस तरह रूट करना चाहिए कि उपयोगकर्ता बदलाव न कर सके. भले ही, ऐसा सिर्फ़ अनलॉक किए गए डिवाइस. (यह पक्का करने के लिए कि इसका इस्तेमाल नहीं किया जा सकता).
- [C-6-2] DICE को सही तरीके से इस्तेमाल करना ज़रूरी है. इसका मतलब है कि प्रॉडक्ट के लिए सही वैल्यू सबमिट करें. हालांकि, हो सकता है कि ध्यान रखने की ज़रूरत नहीं है.
नई ज़रूरी शर्तें खत्म करना

13. हमसे संपर्क करें

आप Android-कंपैटबिलिटी फ़ोरम और ऐसी समस्याओं के बारे में बताएं जो आपको दस्तावेज़ में सही नहीं लगती हैं कवर.