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

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

1. परिचय

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

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

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

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

जहां यह परिभाषा या इसमें बताया गया सॉफ़्टवेयर टेस्ट सेक्शन 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-3] होम फ़ंक्शन को चालू करना ज़रूरी है Android के साथ काम करने वाले ऐसे सभी डिसप्ले जिनसे होम स्क्रीन मिलती है.
[7.2.3/H-0-4] सभी यूआरएल के लिए वापस जाएं वाला फ़ंक्शन देना ज़रूरी है इनमें से किसी एक डिवाइस पर, Android के साथ काम करने वाले डिसप्ले और हाल ही के काम करने की सुविधा Android के साथ काम करने वाले डिसप्ले.
[7.2.3/H-0-2] आपको सामान्य और देर तक, दोनों बटन दबाने होंगे वापस जाएं फ़ंक्शन का इवेंट (KEYCODE_BACK) ऐप्लिकेशन को फ़ोरग्राउंड ऐप्लिकेशन से लिंक करना. सिस्टम इन इवेंट का इस्तेमाल नहीं कर सकता साथ ही, इसे 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.

अगर हैंडहेल्ड डिवाइस को लागू करने के लिए, एक लॉजिकल कैमरा डिवाइस शामिल है, जिसमें नीचे दी गई सूची ये सुविधाएं मिलती हैं: 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(#56_audio-latency)/H-1-1] ज़रूरी है कि आपके पास लगातार दोतरफ़ा यात्रा का औसत हो मीन के साथ, 800 मिलीसेकंड या 5 से कम माप की इंतज़ार का समय कम से कम एक काम करने वाले पाथ से, 100 मि॰से॰ से कम का कुल डेविएशन.

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

[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) और रिच हैप्टिक के लिए सभी सार्वजनिक स्थिरांक android.os.Vibrationimpact.Composition में, नाम है (PRIMITIVE_Click और PRIMITIVE_TICK).
[7.10/H]* लिंक किए गए इन हैप्टिक कॉन्सटेंट का इस्तेमाल करना चाहिए मैपिंग.
[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.arePrimitvesSupported() एपीआई की.
[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 को लागू करना होगा.

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

[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-2-1] इसके लिए null को रिपोर्ट करना ज़रूरी है ControlsProviderService और Control एपीआई.
[3.8.16/H-2-2] सुविधा के बारे में एलान करना ज़रूरी है फ़्लैग करें android.software.controls और false पर सेट कर दें.

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

[3.10/H-0-1] तीसरे पक्ष की सुलभता सुविधाएं ज़रूरी हैं सेवाओं.
[3.10/H-SR-1] पहले से लोड करने के लिए, बहुत ज़्यादा सुझाव दिया जाता है-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 में बताए गए तरीके से वीडियो मोड में कैमरा लॉन्च करने के लिए भी कहा जाता है.

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 इंटेंट पर क्लिक करें और एक सेटिंग मेन्यू दिखाएं, जो पावर के इस इस्तेमाल को दिखाता है.

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-13] हॉटवर्ड का पता लगाने वाली सेवा को होस्ट करने की प्रोसेस को फिर से शुरू करना होगा हर घंटे में कम से कम एक बार या हर 30 हार्डवेयर-ट्रिगर इवेंट में से, जो भी हो सबसे पहले आता है.
[9.8/H-1-14] सेक्शन में बताए गए तरीके के मुताबिक, माइक्रोफ़ोन इंंडिकेटर दिखाना ज़रूरी है 9.8.2, जब सफल हॉटवर्ड नतीजे को बोलकर भेजा जाता है इंटरैक्शन सेवा या इससे मिलती-जुलती इकाई की समीक्षा कर रहे हैं.
[9.8/H-SR-1] हमारी सलाह है कि आप ऐप्लिकेशन को हॉटवर्ड का पता लगाने वाली सेवा के रूप में इंस्टॉल करता है.
[9.8/H-SR-2] हमारी सलाह है कि हॉटवर्ड का पता लगाने वाली सेवा से बाहर के अव्यवस्थित डेटा को हटा दिया गया है.

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

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

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

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.R फ़ंक्शन लागू होता है, तो android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS, इसके बाद:

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

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

[5.1/H-1-1] हार्डवेयर वीडियो डिकोडर की ज़्यादा से ज़्यादा संख्या का विज्ञापन देना ज़रूरी है ऐसे सत्र जो CodecCapabilities.getMaxSupportedInstances() और VideoCapabilities.getSupportedPerformancePoints() तरीके इस्तेमाल करते हैं.
[5.1/H-1-2] हार्डवेयर वीडियो डिकोडर सेशन के छह इंस्टेंस पर काम करना ज़रूरी है (एवीसी, एचईवीसी, VP9* या इसके बाद के वर्शन) किसी भी कोडेक के कॉम्बिनेशन में हो सकते हैं 720p रिज़ॉल्यूशन@30 एफ़पीएस (फ़्रेम प्रति सेकंड) पर समवर्ती रूप से. *सिर्फ़ दो इंस्टेंस की ज़रूरत है, अगर VP9 कोडेक मौजूद है.
[5.1/H-1-3] हार्डवेयर वीडियो एन्कोडर की ज़्यादा से ज़्यादा संख्या का विज्ञापन देना ज़रूरी है ऐसे सत्र जो CodecCapabilities.getMaxSupportedInstances() और VideoCapabilities.getSupportedPerformancePoints() तरीके इस्तेमाल करते हैं.
[5.1/H-1-4] हार्डवेयर वीडियो एन्कोडर के छह इंस्टेंस के साथ काम करना ज़रूरी है सेशन (एवीसी, एचईवीसी, VP9* या इसके बाद के वर्शन) किसी भी कोडेक के साथ चल सकते हैं 720p रिज़ॉल्यूशन@30fps पर. *सिर्फ़ दो इंस्टेंस की ज़रूरत है अगर VP9 कोडेक मौजूद है.
[5.1/H-1-5] हार्डवेयर वीडियो एन्कोडर की अधिकतम संख्या का विज्ञापन करना ज़रूरी है और डिकोडर सत्र जो इसके ज़रिए किसी भी कोडेक संयोजन में एक साथ चलाए जा सकते हैं CodecCapabilities.getMaxSupportedInstances() और VideoCapabilities.getSupportedPerformancePoints() तरीके इस्तेमाल करते हैं.
[5.1/H-1-6] हार्डवेयर वीडियो डिकोडर और हार्डवेयर के छह इंस्टेंस पर काम करना ज़रूरी है किसी भी कोडेक में वीडियो एन्कोडर सेशन (एवीसी, एचईवीसी, VP9* या इसके बाद के वर्शन) 720p@30fps रिज़ॉल्यूशन पर एक साथ चल रहा है. *अगर VP9 कोडेक मौजूद है, तो सिर्फ़ दो इंस्टेंस की ज़रूरत है.
[5.1/H-1-7] सभी हार्डवेयर वीडियो एन्कोडर के लिए 1080p या छोटे वीडियो एन्कोडिंग सेशन (डॉल्बी विज़न कोडेक के अलावा) का लोड हो सकता है. यहां लोड करें हार्डवेयर वीडियो इस्तेमाल करके, एक ही समय पर 1080 पिक्सल से 720 पिक्सल वाले वीडियो को ट्रांसकोड करने की सुविधा 1080p ऑडियो-वीडियो रिकॉर्डिंग के साथ शुरुआत करने के लिए, कोडेक का इस्तेमाल किया जा सकता है.
[5.1/H-1-8] सभी ऑडियो एन्कोडर के लिए 128 केबीपीएस या इससे कम बिटरेट वाला ऑडियो एन्कोडिंग सेशन लोड नहीं किया जा सकता. यहां लोड करें को सिर्फ़ 1080 पिक्सल से 720 पिक्सल वाले वीडियो के तौर पर दिखाया गया है 1080p के साथ हार्डवेयर वीडियो कोडेक का इस्तेमाल करके ट्रांसकोडिंग सेशन ऑडियो-वीडियो रिकॉर्डिंग शुरू करना.
[5.3/H-1-1] 10 सेकंड में दो फ़्रेम से ज़्यादा नहीं छोड़ना चाहिए 1080p 60 FPS (फ़्रेम प्रति सेकंड) वीडियो सेशन के लिए (यानी कि 0.333 प्रतिशत से कम फ़्रेम में गिरावट) लोड नहीं किया जा सकता. लोड को सिर्फ़ 1080 पिक्सल से 720 पिक्सल वाले वीडियो के तौर पर दिखाया जाता है हार्डवेयर वीडियो कोडेक इस्तेमाल करके ट्रांसकोडिंग सेशन, साथ ही 128 केबीपीएस AAC ऑडियो प्लेबैक.
[5.3/H-1-2] वीडियो के दौरान 10 सेकंड में दो फ़्रेम से ज़्यादा नहीं छोड़ना चाहिए लोड हो रहे 60 एफ़पीएस (फ़्रेम प्रति सेकंड) वाले वीडियो सेशन के रिज़ॉल्यूशन में बदलाव. लोड इस तरह से परिभाषित किया गया है हार्डवेयर का इस्तेमाल करके, एक साथ 1080 पिक्सल से 720 पिक्सल वाले वीडियो को ट्रांसकोड करने की सुविधा और साथ ही, 128 केबीपीएस AAC ऑडियो प्लेबैक.
[5.6/H-1-1] वीडियो में टैप-टू-टोन के लिए इंतज़ार का समय 100 मिलीसेकंड से कम होना चाहिए का इस्तेमाल करके,

2.2.7.2. कैमरा

यह ज़रूरी है कि आपका फ़ोन, Android 11 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 ऐप्लिकेशन के चालू होने में लगने वाला समय होना ज़रूरी है (पहली झलक के लिए कैमरा चालू करें फ़्रेम) < आईटीएस के तहत सीटीएस कैमरा परफ़ॉर्मेंसटेस्ट की मदद से मापा गया 600 मि॰से॰ दोनों प्राइमरी कैमरों के लिए लाइटिंग की स्थिति (3,000K).
[7.5/H-1-8] CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW के साथ काम करना ज़रूरी है और मुख्य बैक कैमरे के लिए android.graphics.ImageFormat.RAW_SENSOR.

2.2.7.3. हार्डवेयर

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

Android 11 CDD में बताए गए हार्डवेयर की ज़रूरी शर्तों को पूरा करना ज़रूरी है सेक्शन 2.2.7.3

अगर हैंडहेल्ड डिवाइस लागू करने की प्रक्रिया के लिए, android.os.Build.VERSION_CODES.S फ़ंक्शन लागू होता है, तो android.os.Build.VERSION.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] आपके डिवाइस में कम से कम 6 जीबी की फ़िज़िकल मेमोरी होनी चाहिए.

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

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

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

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

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

[7.3.1/A-1-1] ज़रूरी है कि कम से कम 100 हर्ट्ज़ की फ़्रीक्वेंसी होनी चाहिए.
[7.3.1/A-1-2] ज़रूरी है कि वह Android का पालन करे कार सेंसर कोऑर्डिनेट सिस्टम.

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

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

अगर 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 या दोनों का कॉम्बिनेशन.

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

[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.5/A-SR-1] को पूरी तरह से तैयार करने का सुझाव दिया जाता है, ताकि कैमरे का लंबा डाइमेंशन हॉराइज़न के हिसाब से हो.
[7.5/A-SR-2] हमारा सुझाव है कि इस तरह की समस्या का समाधान पाने के लिए कम से कम 1.3 मेगापिक्सल का हो.
इसमें फ़िक्स्ड-फ़ोकस या EDOF (फ़ील्ड की बढ़ाई गई डेप्थ) हार्डवेयर होना चाहिए.
Android सिंक्रोनाइज़ेशन फ़्रेमवर्क पर काम करना चाहिए.
हो सकता है कि इनमें हार्डवेयर ऑटो-फ़ोकस या सॉफ़्टवेयर ऑटो-फ़ोकस लागू किया गया हो कैमरा ड्राइवर.

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

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

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

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

अगर 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 या उससे ज़्यादा

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

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

[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 12 के लिए मान्य वर्शन स्ट्रिंग.
वर्शन.SDK	फ़ॉर्मैट में, मौजूदा समय में चल रहे Android सिस्टम का वर्शन तीसरे पक्ष के ऐप्लिकेशन कोड को ऐक्सेस किया जा सकता है. Android 12 के लिए, इस फ़ील्ड में पूर्णांक मान 12_INT होना चाहिए.
वर्शन.SDK_INT	फ़ॉर्मैट में, मौजूदा समय में चल रहे Android सिस्टम का वर्शन तीसरे पक्ष के ऐप्लिकेशन कोड को ऐक्सेस किया जा सकता है. Android 12 के लिए, इस फ़ील्ड में पूर्णांक मान 12_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:12/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 की रिपोर्ट करती है, तो:

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

अगर डिवाइस लागू करने के तरीके 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 ओपन सोर्स प्रोजेक्ट से के लागू होने के लिए 12 ब्रांच 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. ऐप्लिकेशन पर पाबंदी

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

[C-1-1] लोगों के लिए वह अधिकार उपलब्ध कराना ज़रूरी है जहां वे पाबंदी वाले ऐप्लिकेशन.
[C-1-2] लोगों के लिए, पाबंदियों को चालू या बंद करने की सुविधा देना ज़रूरी है ट्रैक करने में मदद मिलती है.
[C-1-3] ऐसे कॉन्टेंट पर पाबंदियां अपने-आप लागू नहीं होनी चाहिए जो खराब न हो सिस्टम की परफ़ॉर्मेंस को बेहतर बनाया जा सकता है. हालांकि, नीति का पता चलने पर, ऐप्लिकेशन पर पाबंदियां लगाई जा सकती हैं सिस्टम की खराब परफ़ॉर्मेंस, जैसे कि अटके हुए वेकलॉक, लंबे समय तक चल रही सेवाएं, और अन्य मानदंड. ये शर्तें, डिवाइस लागू करने वालों के हिसाब से तय की जा सकती हैं. हालांकि, इन्हें इस्तेमाल करना ज़रूरी है सिस्टम की परफ़ॉर्मेंस पर ऐप्लिकेशन के असर से जुड़ी जानकारी हो. अन्य शर्तें, जो पूरी तरह से, सिस्टम की परफ़ॉर्मेंस से जुड़ा होता है. जैसे, ऐप्लिकेशन की लोकप्रियता कम होना का उपयोग मानदंड के रूप में नहीं किया जाना चाहिए.
[C-1-4] ज़रूरी नहीं है कि किसी उपयोगकर्ता की वजह से, ऐप्लिकेशन के लिए पाबंदियां अपने-आप लागू न हों ने ऐप्लिकेशन पर लगी पाबंदियों को मैन्युअल तरीके से बंद कर दिया है. साथ ही, हो सकता है कि वह उपयोगकर्ता को उन्हें लागू करने का सुझाव दे ऐप्लिकेशन के ऐक्सेस पर पाबंदियां लगाएं.
[C-1-5] लोगों को यह बताना ज़रूरी है कि किसी ऐप्लिकेशन पर पाबंदियां लगाई गई हैं स्वचालित रूप से. इस तरह की जानकारी पाबंदियां लागू हैं.
[C-1-6] ActivityManager.isBackgroundRestricted() के लिए true वापस करना होगा जब प्रतिबंधित ऐप्लिकेशन इस एपीआई को कॉल करता है.
[C-1-7] उस ऐप्लिकेशन पर पाबंदी नहीं लगाई जानी चाहिए जिसका इस्तेमाल साफ़ तौर पर किया गया है उपयोगकर्ता से.
[C-1-8] ऐसे ऐप्लिकेशन पर लगी पाबंदियों को निलंबित करना ज़रूरी है जो टॉप फ़ोरग्राउंड में आता है ऐप्लिकेशन, जब उपयोगकर्ता साफ़ तौर पर उस ऐप्लिकेशन का इस्तेमाल करना शुरू करता है जो पहले प्रतिबंधित.
[C-1-10] किसी ऐप्लिकेशन को अपने-आप प्रतिबंधित सूची में रखने की अनुमति नहीं देनी चाहिए उपयोगकर्ता के सबसे हाल ही में इस्तेमाल किए जाने के दो घंटे के अंदर बकेट.

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

[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() एपीआई.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.8.3.3. परेशान न करें (परेशान न करें)

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

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

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

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.
[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 के ज़रिए ऑर्डर करते हैं एपीआई.

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 कॉन्टेंट के साथ स्टैंडर्ड कॉन्टेंट उपलब्ध है किलोहर्ट्ज़ (kHz) से लेकर 16 किलोहर्ट्ज़ (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)
वोर्बिस		ऑग (.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 तक.
[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 के बराबर). हमारा सुझाव है कि ये दोनों सुविधाएं काम करें.
[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] इस तरह के कॉन्टेंट के साथ रॉ ऑडियो कॉन्टेंट को कैप्चर करने की अनुमति होनी चाहिए विशेषताएं:
- फ़ॉर्मैट: लीनियर PCM, 16-बिट
- सैंपलिंग रेट: 8000, 11025, 16,000, 44100, 48000 हर्ट्ज़
- चैनल: मोनो
नीचे दी गई चीज़ों के साथ रॉ ऑडियो कॉन्टेंट कैप्चर करने की अनुमति होनी चाहिए विशेषताएं:
- फ़ॉर्मैट: लीनियर 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() एपीआई और ऐसे चालू माइक्रोफ़ोन जिन्हें तीसरे पक्ष की AudioRecord.getActiveMicrophones() के द्वारा पक्ष के ऐप्लिकेशन और MediaRecorder.getActiveMicrophones() एपीआई. अगर डिवाइस लागू करने की प्रोसेस के दौरान, रॉ ऑडियो को एएम रेडियो और डीवीडी क्वालिटी में कैप्चर किया जाता है कॉन्टेंट न हो, इसलिए:
[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 ऑडियो सोर्स से एक ऑडियो स्ट्रीम.
आवाज़ की पहचान करने वाली ऑडियो स्ट्रीम को करीब-करीब फ़्लैट करके रिकॉर्ड करना चाहिए आयाम बनाम फ़्रीक्वेंसी की विशेषताएं: खास तौर पर, ±3 dB, 100 हर्ट्ज़ से 4000 हर्ट्ज़ तक.
इनपुट की संवेदनशीलता को सेट करके, आवाज़ की पहचान करने वाली ऑडियो स्ट्रीम को रिकॉर्ड किया जाना चाहिए ऐसे कि 1000 हर्ट्ज़ पर 90 dB साउंड पावर लेवल (SPL) का स्रोत, 16-बिट सैंपल के लिए 2500.
आवाज़ की पहचान करने वाली ऑडियो स्ट्रीम को रिकॉर्ड करना चाहिए, ताकि पीसीएम का आयाम बढ़ सके लेवल, इनपुट एसपीएल में -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. माइक्रोफ़ोन गेन लेवल

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

डाइमेंशन और फ़्रीक्वेंसी के मुकाबले, करीब-करीब सपाट होना चाहिए मिड फ़्रीक्वेंसी रेंज में शामिल विशेषताएं: खास तौर पर, 100 में से ±3dB आवाज़ रिकॉर्ड करने के लिए इस्तेमाल किए जाने वाले हर माइक्रोफ़ोन के लिए, Hz से 4000 हर्ट्ज़ (हर्ट्ज़) की पहचान करने वाला ऑडियो सोर्स.
ऑडियो इनपुट की संवेदनशीलता को इस तरह सेट करना चाहिए कि 1000 हर्ट्ज़ का साइनसॉइडल हो 90 dB साउंड प्रेशर लेवल (एसपीएल) पर चलाए गए टोन के स्रोत से जवाब मिलता है 16 बिट-सैंपल के लिए 2500 आरएमएस (या फ़्लोटिंग के लिए -22.35 dB फ़ुल स्केल) के साथ पॉइंट/डबल सटीक सैंपल) आवाज़ की पहचान करने वाला ऑडियो सोर्स रिकॉर्ड कर सकता है.
[C-SR-1] का बहुत ज़्यादा सुझाव दिया जाता है, ताकि आयाम के लेवल को सबसे कम स्तर पर दिखाया जा सके फ़्रीक्वेंसी रेंज: खास तौर पर, 5 हर्ट्ज़ से 100 हर्ट्ज़ तक की तुलना में ±20 dB रिकॉर्ड करने के लिए इस्तेमाल किए जाने वाले हर माइक्रोफ़ोन के लिए, फ़्रीक्वेंसी को मिड-फ़्रीक्वेंसी रेंज तक का होना चाहिए आवाज़ पहचानने का ऑडियो सोर्स.
[C-SR-2] का बहुत ज़्यादा सुझाव दिया जाता है, ताकि उच्च फ़्रीक्वेंसी रेंज: खास तौर पर ±30 dB से लेकर 4000 हर्ट्ज़ से लेकर 22 किलोहर्ट्ज़ तक इस्तेमाल किए गए हर माइक्रोफ़ोन की मिड फ़्रीक्वेंसी रेंज से तुलना की गई है आवाज़ पहचानने का ऑडियो सोर्स रिकॉर्ड करने के लिए.

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. ऑडियो आउटपुट की आवाज़

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

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

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

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

[C-SR-1] चलाए गए गैपलेस ऑडियो कॉन्टेंट में काट-छांट करने का सुझाव दिया जाता है जब AudioTrack गैपलेस एपीआई से तय किया गया हो और 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 मिलीसेकंड या उससे कम की कोल्ड आउटपुट इंतज़ार का समय.

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

[C-SR-1] स्पीकर के डेटा पर 100 मिलीसेकंड या उससे कम का कोल्ड आउटपुट इंतज़ार का समय पाथ. Android के इस वर्शन पर चलने वाले मौजूदा और नए डिवाइस VERY हमारा सुझाव है कि इन शर्तों को अभी पूरा करें. आने वाले प्लैटफ़ॉर्म के लिए रिलीज़ के लिए, हमें 200 मि॰से॰ या उससे कम के कोल्ड आउटपुट इंतज़ार के समय की ज़रूरत होगी.
[C-SR-2] टैप-टू-टोन इंतज़ार का समय 80 मिलीसेकंड या इससे कम.
[C-SR-3] कोल्ड आउटपुट की आवाज़ को कम करें.
[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 मिलीसेकंड या उससे कम कोल्ड इनपुट इंतज़ार का समय.

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

[C-SR-8] माइक्रोफ़ोन पर 100 मिलीसेकंड या उससे कम कोल्ड इनपुट इंतज़ार का समय डेटा पाथ. Android के इस वर्शन पर चलने वाले मौजूदा और नए डिवाइस इन शर्तों को पूरा करने का बहुत ज़्यादा सुझाव दिया जाता है. आने वाले समय में प्लैटफ़ॉर्म रिलीज़ होने के बाद, हमें 200 मि॰से॰ या उससे कम के कोल्ड इनपुट इंतज़ार के समय की ज़रूरत होगी. ज़रूरी है.
[C-SR-9] इनपुट के लिए इंतज़ार का समय 30 मिलीसेकंड या उससे कम होना चाहिए.
[C-SR-10] कोल्ड इनपुट सिग्नल की गड़बड़ी को कम से कम करें.
[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 ऑडियो के लिए इंतज़ार का समय, 20 मिलीसेकंड या उससे कम का होना चाहिए और कम से कम एक काम करने वाले पाथ से 10 मिलीसेकंड या उससे कम का होना चाहिए.
[C-1-3] उसमें यूएसबी होस्ट मोड और यूएसबी के साथ काम करने वाले यूएसबी पोर्ट होने चाहिए सहायक डिवाइस (जैसे, कीबोर्ड, माउस, मॉनिटर, वेबकैम वगैरह) मोड चालू करना.
[C-1-4] android.software.midi सुविधा के लिए सहायता की जानकारी देना ज़रूरी है.
[C-1-5] इंतज़ार के समय और यूएसबी ऑडियो की ज़रूरी शर्तों को पूरा करना ज़रूरी है. ऑडियो नेटिव ऑडियो एपीआई.
[C-1-6] कोल्ड आउटपुट के लिए इंतज़ार का समय 200 मिलीसेकंड या इससे कम होना चाहिए.
[C-1-7] कोल्ड इनपुट इंतज़ार का समय 200 मिलीसेकंड या इससे कम होना चाहिए.
[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 मि॰से॰

SynthMark का दस्तावेज़ देखें ताकि बेंचमार्क की जानकारी मिल सके.

ऑडियो क्लॉक की गलतियों को कम से कम करना चाहिए और स्टैंडर्ड समय के हिसाब से ड्रिफ़्ट होना चाहिए.
CLOCK_MONOTONIC सीपीयू के मुकाबले ऑडियो क्लॉक ड्रिफ़्ट कम होनी चाहिए जब दोनों चालू हों.
डिवाइस पर मौजूद ट्रांसड्यूसर से, ऑडियो में देरी को कम किया जाना चाहिए.
USB डिजिटल ऑडियो पर ऑडियो प्रतीक्षा अवधि को कम करना चाहिए.
सभी पाथ के लिए, आवाज़ के इंतज़ार के समय को रिकॉर्ड करना चाहिए.
ऑडियो बफ़र को पूरा करने के लिए, कॉलबैक एंट्री के समय में सिग्नल में गड़बड़ी कम होनी चाहिए, क्योंकि यह कॉलबैक से, पूरे सीपीयू बैंडविथ के इस्तेमाल किए जा सकने वाले प्रतिशत पर असर पड़ता है.
रिपोर्ट की गई इंतज़ार के समय के लिए, सामान्य इस्तेमाल के दौरान ऑडियो में कोई ग्लिच नहीं होनी चाहिए.
एक चैनल से दूसरे चैनल पर वीडियो अपलोड होने और उसके दिखने के बीच इंतज़ार के समय के अंतर का कोई अंतर नहीं होना चाहिए.
सभी ट्रांसपोर्ट के लिए, एमआईडीआई का मतलब कम से कम होना चाहिए.
सभी ट्रांसपोर्ट में, लोड (जीटर) में एमआईडीआई में देरी में होने वाले उतार-चढ़ाव को कम करना चाहिए.
सभी ट्रांसपोर्ट के लिए, एमआईडीआई के सटीक टाइमस्टैंप देने चाहिए.
डिवाइस पर मौजूद ट्रांसड्यूसर पर ऑडियो सिग्नल के शोर को कम करना चाहिए. इसमें ये भी शामिल हैं कोल्ड स्टार्ट के तुरंत बाद की अवधि.
इसके इनपुट और आउटपुट हिस्से में ऑडियो क्लॉक का कोई अंतर नहीं होना चाहिए जब दोनों चालू हों, तब संबंधित एंड-पॉइंट. संगत के उदाहरण एंड-पॉइंट में, डिवाइस में मौजूद माइक्रोफ़ोन और स्पीकर या ऑडियो जैक इनपुट शामिल होते हैं और आउटपुट.
इनपुट और आउटपुट साइड के लिए, ऑडियो बफ़र को पूरा करने वाले कॉलबैक को हैंडल करना चाहिए जब दोनों सक्रिय हों, तो एक ही थ्रेड पर संबंधित समाप्ति-बिंदुओं के और फिर इनपुट कॉलबैक से वापस आने के तुरंत बाद, आउटपुट कॉलबैक करें. या अगर एक ही थ्रेड पर कॉलबैक मैनेज करना संभव नहीं है, तो इनपुट कॉलबैक डालने के तुरंत बाद, आउटपुट कॉलबैक ताकि इनपुट और आउटपुट साइड का एक ही समय सेट किया जा सके.
इनपुट के लिए HAL ऑडियो बफ़रिंग के बीच के फ़ेज़ के अंतर को कम करना चाहिए और संबंधित एंड-पॉइंट के आउटपुट पक्ष भी शामिल होते हैं.
इसलिए, स्क्रीन टच करने में लगने वाला समय कम होना चाहिए.
लोड में टच इंतज़ार के समय में उतार-चढ़ाव को कम किया जाना चाहिए (जीटर).
टच इनपुट से लेकर ऑडियो आउटपुट तक या उससे कम 40 मि॰से॰ के बराबर.

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

[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 पाथ पर AAudio नेटिव ऑडियो एपीआई.

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

स्टीरियो और आठ चैनलों में 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] का अब भी बहुत ज़्यादा सुझाव दिया जाता है प्रोसेस नहीं किए गए रिकॉर्डिंग सोर्स के सिग्नल पाथ के लिए.

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 डीबग ब्रिज को सक्रिय कर रहा हो, तब समर्थित होना चाहिए, किया गया है.
बंदर
- [C-0-8] ज़रूरी है कि Monkey फ़्रेमवर्क को शामिल किया जाए और इसे उपयोग करने के लिए ऐप्लिकेशन.
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-10] 'ऐटम' को LMK_KILL_OCCURRED_FIELD_NUMBER पर लो मेमोरी किलर की वजह से किसी ऐप्लिकेशन को बंद किए जाने पर आंकड़ों का लॉग.
टेस्ट हार्नेस मोड अगर डिवाइस लागू करने के लिए शेल कमांड cmd testharness और cmd testharness enable चलाने के लिए, वे:
- [C-2-1] इसके लिए true वापस करना होगा: ActivityManager.isRunningInUserTestHarness()
- [C-2-2] टेस्ट हार्नेस मोड को इस तरह लागू करना ज़रूरी है टेस्ट के हार्नेस मोड के दस्तावेज़.

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

अगर डिवाइस, 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.1 के साथ काम करने के लिए इस बात पर ज़ोर दिया जाता है.

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

इसमें Vulkan 1.1 के साथ काम करने की सुविधा शामिल होनी चाहिए.

Vulkan dEQP टेस्ट को कई टेस्ट लिस्ट में बांटा गया है. हर टेस्ट में संबंधित तारीख/वर्शन. ये Android सोर्स ट्री में external/deqp/android/cts/main/vk-master-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-2] को VK_KHR_driver_property पर काम करने के लिए बहुत ज़्यादा सुझाया जाता है और VK_GOOGLE_display_timing एक्सटेंशन.

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

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

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

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

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

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] तीन-ऐक्सिस एक्सलरोमीटर शामिल करने का सुझाव दिया जाता है.

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

[C-1-1] कम से कम 50