एंड्रॉइड 14
8 अप्रैल 2024
2. डिवाइस के प्रकार
संशोधन देखें
नई आवश्यकताएँ प्रारंभ करें
यदि हैंडहेल्ड डिवाइस कार्यान्वयन
FEATURE_BLUETOOTH_LEघोषित करते हैं, तो वे:- [ 7.4 .3/एच-1-3] यह सुनिश्चित करने के लिए आरएक्स ऑफसेट को मापना और क्षतिपूर्ति करना आवश्यक है कि
ADVERTISE_TX_POWER_HIGHपर संचारित करने वाले संदर्भ उपकरण से 1 मीटर की दूरी पर माध्य BLE RSSI -50dBm +/-15 dB है। - [ 7.4 .3/एच-1-4] यह सुनिश्चित करने के लिए टीएक्स ऑफसेट को मापना और क्षतिपूर्ति करना आवश्यक है कि 1 मीटर की दूरी पर स्थित संदर्भ डिवाइस से स्कैन करते समय और
ADVERTISE_TX_POWER_HIGHपर संचारित करते समय माध्य BLE RSSI -50dBm +/-15 dB है।
- [ 7.4 .3/एच-1-3] यह सुनिश्चित करने के लिए आरएक्स ऑफसेट को मापना और क्षतिपूर्ति करना आवश्यक है कि
संशोधन देखें
यदि हैंडहेल्ड डिवाइस कार्यान्वयन सिस्टम एपीआई
HotwordDetectionServiceया माइक एक्सेस इंडिकेशन के बिना हॉटवर्ड डिटेक्शन के लिए किसी अन्य तंत्र का समर्थन करता है, तो वे:- [9.8/एच-1-6] हॉटवर्डऑडियोस्ट्रीम के माध्यम से पारित ऑडियो डेटा को छोड़कर प्रत्येक सफल हॉटवर्ड परिणाम पर हॉटवर्ड डिटेक्शन सेवा से 100 बाइट्स से अधिक डेटा प्रसारित करने की अनुमति नहीं दी जानी चाहिए।
संशोधन देखें
[9.8/एच-1-13] को इसमें बदलें:
- [9.8/एच-एसआर-3] हॉटवर्ड डिटेक्शन सेवा को होस्ट करने वाली प्रक्रिया को हर घंटे या हर 30 हार्डवेयर-ट्रिगर इवेंट में कम से कम एक बार, जो भी पहले हो, फिर से शुरू करने की दृढ़ता से अनुशंसा की जाती है।
संशोधन देखें
हटाई गई आवश्यकताएँ [9.8.2/एच-4-3], [9.8.2/एच-4-4], [9.8.2/एच-5-3]।
संशोधन देखें
यदि हैंडहेल्ड डिवाइस कार्यान्वयन
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASSके लिएandroid.os.Build.VERSION_CODES.Uलौटाता है, तो वे:- [ 7.5 /एच-1-3] बैक प्राइमरी कैमरे के लिए
android.info.supportedHardwareLevelप्रॉपर्टी कोFULLया बेहतर और फ्रंट प्राइमरी कैमरे के लिएLIMITEDया बेहतर सपोर्ट करना चाहिए।
- [ 7.5 /एच-1-3] बैक प्राइमरी कैमरे के लिए
संशोधन देखें
यदि टेलीविज़न डिवाइस कार्यान्वयन में अंतर्निहित डिस्प्ले नहीं है, बल्कि एचडीएमआई के माध्यम से जुड़े बाहरी डिस्प्ले का समर्थन करता है, तो वे:
- [ 5.8 /टी-0-1] एचडीएमआई आउटपुट मोड को चुने गए पिक्सेल प्रारूप के लिए उच्चतम रिज़ॉल्यूशन पर सेट करना होगा जो बाहरी डिस्प्ले के लिए 50 हर्ट्ज या 60 हर्ट्ज ताज़ा दर के साथ काम करता है, यह उस क्षेत्र के लिए वीडियो ताज़ा दर पर निर्भर करता है जहां डिवाइस बेचा जाता है।
अधिकतम रिज़ॉल्यूशन का चयन करने के लिए एचडीएमआई आउटपुट मोड को सेट करना होगा जिसे 50 हर्ट्ज या 60 हर्ट्ज ताज़ा दर के साथ समर्थित किया जा सकता है।
- [ 5.8 /टी-0-1] एचडीएमआई आउटपुट मोड को चुने गए पिक्सेल प्रारूप के लिए उच्चतम रिज़ॉल्यूशन पर सेट करना होगा जो बाहरी डिस्प्ले के लिए 50 हर्ट्ज या 60 हर्ट्ज ताज़ा दर के साथ काम करता है, यह उस क्षेत्र के लिए वीडियो ताज़ा दर पर निर्भर करता है जहां डिवाइस बेचा जाता है।
3. सॉफ्टवेयर
संशोधन देखें
- हटाई गई आवश्यकता [सी-1-9]
5. मल्टीमीडिया संगतता
संशोधन देखें
यदि डिवाइस कार्यान्वयन
HDR_TYPE_DOLBY_VISIONके माध्यम से डॉल्बी विजन डिकोडर के लिए समर्थन की घोषणा करता है, तो वे:- [सी-1-3] बैकवर्ड-संगत बेस-लेयर (यदि मौजूद है) की ट्रैक आईडी को संयुक्त डॉल्बी विजन लेयर की ट्रैक आईडी के समान सेट करना होगा।
7. हार्डवेयर अनुकूलता
7.1.1.1. स्क्रीन का आकार और आकार :
संशोधन देखें
यदि डिवाइस कार्यान्वयन
UI_MODE_TYPE_NORMALआकार कॉन्फ़िगरेशन में सक्षम स्क्रीन का समर्थन करता है और इन स्क्रीन को प्रस्तुत करने के लिए गोलाकार कोनों के साथ भौतिक डिस्प्ले का उपयोग करता है, तो वे:- [सी-1-1] यह सुनिश्चित करना होगा कि ऐसे प्रत्येक प्रदर्शन के लिए निम्नलिखित में से कम से कम एक आवश्यकता पूरी हो:
- जब
15ए 18 डीपी गुणा1518 डीपी बॉक्स को लॉजिकल डिस्प्ले के प्रत्येक कोने पर लगाया जाता है, तो प्रत्येक बॉक्स का कम से कम एक पिक्सेल स्क्रीन पर दिखाई देता है।
- जब
- [सी-1-1] यह सुनिश्चित करना होगा कि ऐसे प्रत्येक प्रदर्शन के लिए निम्नलिखित में से कम से कम एक आवश्यकता पूरी हो:
संशोधन देखें
निम्नलिखित आवश्यकताओं को बहाल किया गया:
यदि डिवाइस कार्यान्वयन
FEATURE_BLUETOOTH_LEघोषित करता है, तो वे:[सी-एसआर-2] यह सुनिश्चित करने के लिए आरएक्स ऑफसेट को मापने और क्षतिपूर्ति करने की दृढ़ता से अनुशंसा की जाती है कि औसत बीएलई आरएसएसआई
ADVERTISE_TX_POWER_HIGHपर संचारित एक संदर्भ डिवाइस से 1 मीटर की दूरी पर -60 डीबीएम +/-10 डीबी है, जहां डिवाइस इस तरह उन्मुख होते हैं कि वे हैं 'समानांतर तल' पर, स्क्रीन एक ही दिशा की ओर हों।[सी-एसआर-3] यह सुनिश्चित करने के लिए टीएक्स ऑफसेट को मापने और क्षतिपूर्ति करने की दृढ़ता से अनुशंसा की जाती है कि 1 मीटर की दूरी पर स्थित एक संदर्भ डिवाइस से स्कैन करते समय और
ADVERTISE_TX_POWER_HIGHपर संचारित करते समय माध्य BLE RSSI -60dBm +/-10 dB है, जहां डिवाइस उन्मुख होते हैं जैसे कि वे 'समानांतर तल' पर हों और स्क्रीन एक ही दिशा की ओर हों।
संशोधन देखें
आवश्यकताओं को [सी-10-3] और [सी-10-4] को 2.2.1 पर ले जाया गया। हार्डवेयर ।
- [सी-10-3] यह सुनिश्चित करने के लिए कि
ADVERTISE_TX_POWER_HIGHपर संचारित होने वाले संदर्भ उपकरण से 1 मीटर की दूरी पर माध्य BLE RSSI -55dBm +/-10 dB है, Rx ऑफसेट को मापना और क्षतिपूर्ति करना आवश्यक है। - [सी-10-4] 1 मीटर की दूरी पर स्थित एक संदर्भ डिवाइस से स्कैन करते समय और
ADVERTISE_TX_POWER_HIGHपर संचारित करते समय माध्य BLE RSSI -55dBm +/-10 dB सुनिश्चित करने के लिए Tx ऑफसेट को मापना और क्षतिपूर्ति करना आवश्यक है।
20 नवंबर 2023
2. डिवाइस के प्रकार
संशोधन देखें
यदि हैंडहेल्ड डिवाइस कार्यान्वयन किसी 64-बिट एबीआई (32-बिट एबीआई के साथ या उसके बिना) के समर्थन की घोषणा करता है:
संशोधन देखें
- [ 7.5 /एच-1-13] यदि 1 से अधिक आरजीबी रियर-फेसिंग कैमरे हैं तो प्राथमिक रियर-फेसिंग कैमरे के लिए
LOGICAL_MULTI_CAMERAक्षमता का समर्थन करना चाहिए।
- [ 7.5 /एच-1-13] यदि 1 से अधिक आरजीबी रियर-फेसिंग कैमरे हैं तो प्राथमिक रियर-फेसिंग कैमरे के लिए
संशोधन देखें
[ 5.8 /टी-0-1] एचडीएमआई आउटपुट मोड को चुने हुए एसडीआर या एचडीआर प्रारूप के लिए उच्चतम रिज़ॉल्यूशन पर सेट करना होगा जो बाहरी डिस्प्ले के लिए 50 हर्ट्ज या 60 हर्ट्ज ताज़ा दर के साथ काम करता है।
अधिकतम रिज़ॉल्यूशन का चयन करने के लिए एचडीएमआई आउटपुट मोड को सेट करना होगा जिसे 50 हर्ट्ज या 60 हर्ट्ज ताज़ा दर के साथ समर्थित किया जा सकता है।
संशोधन देखें
- [9/डब्ल्यू-0-1]
android.hardware.security.model.compatible featureघोषित करनी होगी।
- [9/डब्ल्यू-0-1]
6. डेवलपर उपकरण और विकल्प संगतता
संशोधन देखें
- [सी-0-12] को एक
LMK_KILL_OCCURRED_FIELD_NUMBERएटम लिखना होगा
संशोधन देखें
- [सी-0-13] प्रदर्शित करने के लिए शेल कमांड
dumpsys gpu --gpuworkलागू करना होगा
- [सी-0-12] को एक
9. सुरक्षा मॉडल संगतता
संशोधन देखें
यदि डिवाइस कार्यान्वयन लिनक्स कर्नेल का उपयोग करता है जो SELinux का समर्थन करने में सक्षम है, तो वे:
संशोधन देखें
यदि डिवाइस कार्यान्वयन लिनक्स के अलावा कर्नेल का उपयोग करता है या SELinux के बिना लिनक्स का उपयोग करता है, तो वे:
4 अक्टूबर 2023
2. डिवाइस के प्रकार
संशोधन देखें
यदि एंड्रॉइड डिवाइस कार्यान्वयन निम्नलिखित सभी मानदंडों को पूरा करते हैं तो उन्हें हैंडहेल्ड के रूप में वर्गीकृत किया जाता है:
- भौतिक विकर्ण स्क्रीन का आकार 4 इंच
3.3 इंच (या एपीआई स्तर 29 या इससे पहले पर भेजे गए डिवाइस कार्यान्वयन के लिए 2.5 इंच)से 8 इंच की सीमा में रखें।
नई आवश्यकताएँ प्रारंभ करें
- एक टचस्क्रीन इनपुट इंटरफ़ेस रखें।
- भौतिक विकर्ण स्क्रीन का आकार 4 इंच
संशोधन देखें
हैंडहेल्ड डिवाइस कार्यान्वयन:
- [ 7.1 .1.1/एच-0-1] कम से कम एक
एंड्रॉइड-संगत डिस्प्ले होना चाहिए जो इस दस्तावेज़ में वर्णित सभी आवश्यकताओं को पूरा करता हो।ऐसा डिस्प्ले जिसका माप छोटे किनारे पर कम से कम 2.2" और लंबे किनारे पर 3.4" हो।
यदि हैंडहेल्ड डिवाइस कार्यान्वयन सॉफ़्टवेयर स्क्रीन रोटेशन का समर्थन करता है, तो वे:
- [ 7.1 .1.1/एच-1-1]* तीसरे पक्ष के अनुप्रयोगों के लिए उपलब्ध कराई जाने वाली तार्किक स्क्रीन को छोटे किनारों पर कम से कम 2 इंच और लंबे किनारों पर 2.7 इंच का होना चाहिए। एंड्रॉइड एपीआई लेवल 29 या इससे पहले वाले डिवाइस को इस आवश्यकता से छूट दी जा सकती है।
यदि हैंडहेल्ड डिवाइस कार्यान्वयन सॉफ़्टवेयर स्क्रीन रोटेशन का समर्थन नहीं करता है, तो वे:
- [ 7.1 .1.1/एच-2-1]* तीसरे पक्ष के अनुप्रयोगों के लिए उपलब्ध कराई जाने वाली तार्किक स्क्रीन को छोटे किनारे पर कम से कम 2.7 इंच का होना चाहिए। एंड्रॉइड एपीआई लेवल 29 या इससे पहले वाले डिवाइस को इस आवश्यकता से छूट दी जा सकती है।
नई आवश्यकताएँ प्रारंभ करें
[ 7.1 .1.1/एच-0-3]* तीसरे पक्ष के अनुप्रयोगों के लिए उपलब्ध कराए गए प्रत्येक
UI_MODE_NORMALडिस्प्ले को एक अबाधित भौतिक डिस्प्ले क्षेत्र पर मैप करना होगा जो छोटे किनारे पर कम से कम 2.2" इंच और लंबे किनारे पर 3.4" इंच हो।[ 7.1 .1.3/एच-0-1]*
DENSITY_DEVICE_STABLEका मान संबंधित डिस्प्ले के वास्तविक, भौतिक घनत्व से 92% या अधिक होना चाहिए।
यदि हैंडहेल्ड डिवाइस कार्यान्वयन
android.hardware.audio.outputऔरandroid.hardware.microphoneघोषित करते हैं, तो वे:[ 5.6 /एच-1-1] निम्नलिखित डेटा पथों पर 300 मिलीसेकंड या 5 मापों से कम की औसत निरंतर राउंड-ट्रिप विलंबता होनी चाहिए, 30 एमएस से कम औसत पूर्ण विचलन के साथ: "स्पीकर से माइक्रोफ़ोन", 3.5 मिमी लूपबैक एडाप्टर (यदि समर्थित हो), यूएसबी लूपबैक (यदि समर्थित हो)।
[ 5.6 /एच-1-2] स्पीकर से माइक्रोफोन डेटा पथ पर कम से कम 5 मापों में औसत टैप-टू-टोन विलंबता 300 मिलीसेकंड या उससे कम होनी चाहिए।
यदि हैंडहेल्ड डिवाइस कार्यान्वयन में कम से कम एक हैप्टिक एक्चुएटर शामिल है, तो वे:
- [ 7.10 /एच]* एक विलक्षण घूर्णन द्रव्यमान (ईआरएम) हैप्टिक एक्चुएटर (वाइब्रेटर) का उपयोग नहीं करना चाहिए।
- [ 7.10 /एच]* android.view.HapticFeedbackConstents में स्पष्ट हैप्टिक्स के लिए सभी सार्वजनिक स्थिरांक लागू करना चाहिए, अर्थात् (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY_RELEA SE, पुष्टि करें, अस्वीकार करें, GESTURE_START और GESTURE_END)।
- [ 7.10 /एच]* को android.os.VibrationEffect में स्पष्ट हैप्टिक्स के लिए सभी सार्वजनिक स्थिरांक अर्थात् (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK और EFFECT_DOUBLE_CLICK) और android.os.VibrationEffect.Composition में रिच हैप्टिक्स के लिए सभी संभावित सार्वजनिक
PRIMITIVE_*स्थिरांक लागू करने चाहिए। क्लिक करें, टिक करें, LOW_TICK, QUICK_FALL, QUICK_RISE, SLOW_RISE, SPIN, THUD)। इनमें से कुछ आदिम, जैसे LOW_TICK और SPIN केवल तभी संभव हो सकते हैं जब वाइब्रेटर अपेक्षाकृत कम आवृत्तियों का समर्थन कर सकता है। - [7.10/एच]* संबंधित आयाम संबंधों के साथ android.view.HapticFeedbackConstents में अनुशंसित android.os.VibrationEffect स्थिरांक में सार्वजनिक स्थिरांक को मैप करने के लिए मार्गदर्शन का पालन करना चाहिए।
- [ 7.10 /एच]* createOneShot() और createWaveform() API के लिए गुणवत्ता मूल्यांकन का पालन करना चाहिए।
- [ 7.10 /एच]* को सत्यापित करना चाहिए कि सार्वजनिक android.os.Vibrator.hasAmplitudeControl() एपीआई का परिणाम उनके वाइब्रेटर की क्षमताओं को सही ढंग से दर्शाता है।
- [ 7.10 /एच]* एक्चुएटर का स्थान उस स्थान के पास होना चाहिए जहां उपकरण आमतौर पर पकड़ा जाता है या हाथों से छुआ जाता है।
यदि हैंडहेल्ड डिवाइस कार्यान्वयन में कम से कम एक सामान्य प्रयोजन 7.10 रैखिक अनुनाद एक्चुएटर शामिल है, तो वे:
- [ 7.10 /एच] एक्चुएटर का स्थान उस स्थान के पास होना चाहिए जहां डिवाइस को आमतौर पर हाथों से पकड़ा या छुआ जाता है।
- [ 7.10 /एच] हैप्टिक एक्चुएटर को डिवाइस के प्राकृतिक
पोर्ट्रेटओरिएंटेशन के एक्स-अक्ष (बाएं-दाएं) में ले जाना चाहिए।
यदि हैंडहेल्ड डिवाइस कार्यान्वयन में एक सामान्य प्रयोजन हैप्टिक एक्चुएटर है जो एक्स-अक्ष रैखिक अनुनाद एक्चुएटर (एलआरए) है, तो वे:
- [ 7.10 /एच] एक्स-अक्ष एलआरए की गुंजयमान आवृत्ति 200 हर्ट्ज से कम होनी चाहिए।
- [ 7.1 .1.1/एच-0-1] कम से कम एक
संशोधन देखें
हैंडहेल्ड डिवाइस कार्यान्वयन को निम्नलिखित वीडियो एन्कोडिंग प्रारूपों का समर्थन करना चाहिए और उन्हें तीसरे पक्ष के अनुप्रयोगों के लिए उपलब्ध कराना चाहिए:
- [ 5.2 /एच-0-3] एवी1
हैंडहेल्ड डिवाइस कार्यान्वयन को निम्नलिखित वीडियो डिकोडिंग प्रारूपों का समर्थन करना चाहिए और उन्हें तीसरे पक्ष के अनुप्रयोगों के लिए उपलब्ध कराना चाहिए:
- [ 5.3 /एच-0-6] एवी1
संशोधन देखें
यदि अनुभाग 7.2.3 में वर्णित हालिया फ़ंक्शन नेविगेशन कुंजी सहित डिवाइस कार्यान्वयन इंटरफ़ेस को बदलता है, तो वे:
- [ 3.8 .3/एच-1-1] स्क्रीन पिनिंग व्यवहार को अवश्य लागू करें और उपयोगकर्ता को सुविधा को टॉगल करने के लिए एक सेटिंग मेनू प्रदान करें।
यदि हैंडहेल्ड डिवाइस कार्यान्वयन में
ControlsProviderServiceऔरControlएपीआई के लिए समर्थन शामिल है और तीसरे पक्ष के एप्लिकेशन को डिवाइस नियंत्रण प्रकाशित करने की अनुमति है, तो वे:- [ 3.8 .16/एच-1-6] डिवाइस कार्यान्वयन को उपयोगकर्ता की क्षमता को निम्नानुसार सटीक रूप से प्रस्तुत करना होगा:
- यदि डिवाइस ने
config_supportsMultiWindow=trueसेट किया है और ऐपControlsProviderServiceघोषणा में मेटाडेटाMETA_DATA_PANEL_ACTIVITYघोषित करता है, जिसमें एक वैध गतिविधि का घटक नाम (एपीआई द्वारा परिभाषित) शामिल है, तो ऐप को इस उपयोगकर्ता क्षमता में उक्त गतिविधि को एम्बेड करना होगा। - यदि ऐप मेटाडेटा
META_DATA_PANEL_ACTIVITYघोषित नहीं करता है, तो उसेControlsProviderServiceएपीआई द्वारा प्रदान किए गए निर्दिष्ट फ़ील्ड के साथ-साथ कंट्रोल एपीआई द्वारा प्रदान किए गए किसी भी निर्दिष्ट फ़ील्ड को प्रस्तुत करना होगा।
- यदि डिवाइस ने
- [ 3.8 .16/एच-1-7] यदि ऐप मेटाडेटा
META_DATA_PANEL_ACTIVITYघोषित करता है, तो उसे एम्बेडेड गतिविधि लॉन्च करते समयEXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLSका उपयोग करके [3.8.16/H-1-5] में परिभाषित सेटिंग का मान पास करना होगा।
यदि डिवाइस कार्यान्वयन उपयोगकर्ताओं को किसी भी प्रकार की कॉल करने की अनुमति देता है, तो वे
- [ 7.4.1.2 /एच-0-1] फीचर फ़्लैग
android.software.telecomघोषित करना होगा। - [ 7.4.1.2 /एच-0-2] दूरसंचार ढांचे को अवश्य लागू करें।
संशोधन देखें
हैंडहेल्ड डिवाइस कार्यान्वयन:
- [ 8.5 /एच-0-1] सक्रिय फोरग्राउंड सेवाओं या उपयोगकर्ता द्वारा शुरू की गई नौकरियों वाले सभी ऐप्स को देखने के लिए
सेटिंग्स मेनू मेंएक उपयोगकर्ता क्षमता प्रदान करनी होगी , जिसमें एसडीके दस्तावेज़ में वर्णित अनुसार इनमें से प्रत्येक सेवा की शुरुआत के बाद से अवधि भी शामिल है। .और किसी ऐसे ऐप को रोकने की क्षमता जो अग्रभूमि सेवा या उपयोगकर्ता द्वारा शुरू किया गया कार्य चला रहा हो।एक ऐप को रोकने की क्षमता के साथ जो एक फ़ोरग्राउंड सेवा चला रहा है और उन सभी ऐप को प्रदर्शित करता है जिनमें सक्रिय फ़ोरग्राउंड सेवाएँ हैं और इनमें से प्रत्येक सेवा की अवधि तब से प्रदर्शित होती है जब से यह एसडीके दस्तावेज़ में वर्णित है।- एसडीके दस्तावेज़ में वर्णित अनुसार कुछ ऐप्स को ऐसे उपयोगकर्ता सामर्थ्य में बंद किए जाने या सूचीबद्ध होने से छूट दी जा सकती है।
- [ 8.5 /एच-0-1] सक्रिय फोरग्राउंड सेवाओं या उपयोगकर्ता द्वारा शुरू की गई नौकरियों वाले सभी ऐप्स को देखने के लिए
- [ 8.5 /एच-0-2] किसी ऐसे ऐप को रोकने के लिए उपयोगकर्ता को सहायता प्रदान करनी चाहिए जो फ़ोरग्राउंड सेवा या उपयोगकर्ता द्वारा शुरू किया गया कार्य चला रहा हो।
संशोधन देखें
यदि डिवाइस कार्यान्वयन android.hardware.telephony के लिए समर्थन की घोषणा करता है, तो वे:
- [ 9.5 /H-1-1]
UserManager.isHeadlessSystemUserModetrueपर सेट नहीं करना चाहिए।
यदि डिवाइस कार्यान्वयन में एक सुरक्षित लॉक स्क्रीन है और इसमें एक या अधिक ट्रस्ट एजेंट शामिल हैं, जो TrustAgentService सिस्टम एपीआई लागू करता है, तो वे:
- [ 9.11.1 /एच-1-1] अनुशंसित प्राथमिक प्रमाणीकरण विधियों (जैसे: पिन, पैटर्न, पासवर्ड) में से एक के लिए उपयोगकर्ता को हर 72 घंटे में एक से अधिक बार चुनौती देनी चाहिए।
यदि हैंडहेल्ड डिवाइस कार्यान्वयन UserManager.isHeadlessSystemUserMode true पर सेट करते हैं, तो वे
यदि हैंडहेल्ड डिवाइस कार्यान्वयन सिस्टम एपीआई HotwordDetectionService या माइक एक्सेस इंडिकेशन के बिना हॉटवर्ड डिटेक्शन के लिए किसी अन्य तंत्र का समर्थन करता है, तो वे:
- [9.8/एच-1-1] यह सुनिश्चित करना होगा कि हॉटवर्ड डिटेक्शन सेवा केवल सिस्टम,
ContentCaptureService, याSpeechRecognizer#createOnDeviceSpeechRecognizer()द्वारा बनाई गई ऑन-डिवाइस स्पीच रिकग्निशन सेवा पर डेटा संचारित कर सकती है। - [9.8/एच-1-6] प्रत्येक सफल हॉटवर्ड परिणाम पर 100 बाइट्स से अधिक डेटा (ऑडियो स्ट्रीम को छोड़कर) को हॉटवर्ड डिटेक्शन सेवा से प्रसारित करने की अनुमति नहीं दी जानी चाहिए।
- [9.8/एच-1-15] यह सुनिश्चित करना चाहिए कि सफल हॉटवर्ड परिणामों पर प्रदान की गई ऑडियो स्ट्रीम हॉटवर्ड डिटेक्शन सेवा से वॉयस इंटरेक्शन सेवा तक एक तरफा प्रसारित की जाती हैं।
यदि डिवाइस कार्यान्वयन में एक एप्लिकेशन शामिल है जो सिस्टम एपीआई HotwordDetectionService का उपयोग करता है, या माइक उपयोग संकेत के बिना हॉटवर्ड डिटेक्शन के लिए समान तंत्र का उपयोग करता है, तो एप्लिकेशन:
- [9.8/एच-2-3] हॉटवर्ड डिटेक्शन सेवा से ऑडियो डेटा, डेटा प्रसारित नहीं किया जाना चाहिए जिसका उपयोग ऑडियो, या ऑडियो सामग्री को फिर से बनाने के लिए किया जा सकता है जो हॉटवर्ड से संबंधित नहीं है,
ContentCaptureServiceको छोड़कर या ऑन-डिवाइस वाक् पहचान सेवा।
यदि हैंडहेल्ड डिवाइस कार्यान्वयन सिस्टम एपीआई VisualQueryDetectionService या माइक और/या कैमरा एक्सेस इंडिकेशन के बिना क्वेरी डिटेक्शन के लिए किसी अन्य तंत्र का समर्थन करता है, तो वे:
- [9.8/एच-3-1] यह सुनिश्चित करना होगा कि क्वेरी डिटेक्शन सेवा केवल सिस्टम, या
ContentCaptureService, या ऑन-डिवाइस वाक् पहचान सेवा (SpeechRecognizer#createOnDeviceSpeechRecognizer()द्वारा निर्मित) पर डेटा संचारित कर सकती है। - [9.8/एच-3-2]
ContentCaptureServiceया ऑन-डिवाइस वाक् पहचान सेवा को छोड़कर, किसी भी ऑडियो या वीडियो जानकारी कोVisualQueryDetectionServiceसे प्रसारित करने की अनुमति नहीं देनी चाहिए। - [9.8/एच-3-3] जब डिवाइस डिजिटल सहायक एप्लिकेशन के साथ जुड़ने के उपयोगकर्ता के इरादे का पता लगाता है (उदाहरण के लिए कैमरे के माध्यम से उपयोगकर्ता की उपस्थिति का पता लगाता है) तो सिस्टम यूआई में एक उपयोगकर्ता सूचना प्रदर्शित करनी चाहिए।
- [9.8/एच-3-4] एक माइक्रोफोन संकेतक प्रदर्शित करना होगा और उपयोगकर्ता क्वेरी का पता चलने के ठीक बाद यूआई में पता लगाई गई उपयोगकर्ता क्वेरी को प्रदर्शित करना होगा।
- [9.8/एच-3-5] उपयोगकर्ता-इंस्टॉल करने योग्य एप्लिकेशन को विज़ुअल क्वेरी डिटेक्शन सेवा प्रदान करने की अनुमति नहीं देनी चाहिए।
संशोधन देखें
यदि हैंडहेल्ड डिवाइस कार्यान्वयन android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS के लिए android.os.Build.VERSION_CODES.T लौटाता है, तो वे:
- Android 13 CDD अनुभाग 2.2.7.1 में सूचीबद्ध मीडिया आवश्यकताओं को पूरा करना होगा।
नई आवश्यकताएँ प्रारंभ करें
यदि हैंडहेल्ड डिवाइस कार्यान्वयनandroid.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS के लिए android.os.Build.VERSION_CODES.U लौटाता है, तो वे:- [5.1/एच-1-1] हार्डवेयर वीडियो डिकोडर सत्रों की अधिकतम संख्या का विज्ञापन अवश्य करें जिन्हें
CodecCapabilities.getMaxSupportedInstances()औरVideoCapabilities.getSupportedPerformancePoints()विधियों के माध्यम से किसी भी कोडेक संयोजन में समवर्ती रूप से चलाया जा सकता है। - [5.1/एच-1-2] किसी भी कोडेक संयोजन में 8-बिट (एसडीआर) हार्डवेयर वीडियो डिकोडर सत्र (एवीसी, एचईवीसी, वीपी9, एवी1 या बाद के संस्करण) के 6 उदाहरणों का समर्थन करना चाहिए, साथ ही 1080पी रिज़ॉल्यूशन@30 एफपीएस पर 3 सत्र भी चलने चाहिए। और 4k रिज़ॉल्यूशन@30fps पर 3 सत्र, जब तक कि AV1 न हो। AV1 कोडेक्स को केवल 1080p रिज़ॉल्यूशन का समर्थन करना आवश्यक है, लेकिन फिर भी 1080p30fps पर 6 इंस्टेंसेस का समर्थन करना आवश्यक है।
- [5.1/एच-1-3] हार्डवेयर वीडियो एनकोडर सत्रों की अधिकतम संख्या का विज्ञापन अवश्य करें जिन्हें
CodecCapabilities.getMaxSupportedInstances()औरVideoCapabilities.getSupportedPerformancePoints()विधियों के माध्यम से किसी भी कोडेक संयोजन में एक साथ चलाया जा सकता है। - [5.1/एच-1-4] किसी भी कोडेक संयोजन में 8-बिट (एसडीआर) हार्डवेयर वीडियो एनकोडर सत्र (एवीसी, एचईवीसी, वीपी9, एवी1 या बाद के संस्करण) के 6 उदाहरणों का समर्थन करना चाहिए, 1080पी रिज़ॉल्यूशन@30 एफपीएस पर 4 सत्रों के साथ समवर्ती रूप से चलना चाहिए। और 4k रिज़ॉल्यूशन@30fps पर 2 सत्र, जब तक कि AV1 न हो। AV1 कोडेक्स को केवल 1080p रिज़ॉल्यूशन का समर्थन करना आवश्यक है, लेकिन फिर भी 1080p30fps पर 6 इंस्टेंसेस का समर्थन करना आवश्यक है।
- [5.1/एच-1-5] हार्डवेयर वीडियो एनकोडर और डिकोडर सत्रों की अधिकतम संख्या का विज्ञापन अवश्य करें जिन्हें
CodecCapabilities.getMaxSupportedInstances()औरVideoCapabilities.getSupportedPerformancePoints()विधियों के माध्यम से किसी भी कोडेक संयोजन में समवर्ती रूप से चलाया जा सकता है। - [5.1/एच-1-6] 4के पर 3 सत्रों के साथ समवर्ती चलने वाले किसी भी कोडेक संयोजन में 8-बिट (एसडीआर) हार्डवेयर वीडियो डिकोडर और हार्डवेयर वीडियो एनकोडर सत्र (एवीसी, एचईवीसी, वीपी9, एवी1 या बाद के) के 6 उदाहरणों का समर्थन करना चाहिए। @30एफपीएस रिज़ॉल्यूशन (एवी1 को छोड़कर), जिनमें से अधिकतम 2 एनकोडर सत्र और 3 सत्र 1080पी रिज़ॉल्यूशन पर हैं। AV1 कोडेक्स को केवल 1080p रिज़ॉल्यूशन का समर्थन करना आवश्यक है, लेकिन फिर भी 1080p30fps पर 6 इंस्टेंसेस का समर्थन करना आवश्यक है।
- [5.1/एच-1-19] 4K@30एफपीएस रिज़ॉल्यूशन पर एक साथ चलने वाले किसी भी कोडेक संयोजन में 10-बिट (एचडीआर) हार्डवेयर वीडियो डिकोडर और हार्डवेयर वीडियो एनकोडर सत्र (एवीसी, एचईवीसी, वीपी9, एवी1 या बाद में) के 3 उदाहरणों का समर्थन करना चाहिए। (AV1 को छोड़कर) जिनमें से अधिकतम 1 एक एनकोडर सत्र है, जिसे GL सतह के माध्यम से RGBA_1010102 इनपुट प्रारूप में कॉन्फ़िगर किया जा सकता है। यदि जीएल सतह से एन्कोडिंग की जाती है तो एन्कोडर द्वारा एचडीआर मेटाडेटा उत्पादन की आवश्यकता नहीं होती है। AV1 कोडेक सत्रों को केवल 1080p रिज़ॉल्यूशन का समर्थन करने की आवश्यकता होती है, भले ही इसके लिए 4K की आवश्यकता हो।
- [5.1/एच-1-7] लोड होने पर सभी हार्डवेयर वीडियो एन्कोडर्स के लिए 1080पी या छोटे वीडियो एन्कोडिंग सत्र के लिए 40 एमएस या उससे कम की कोडेक आरंभीकरण विलंबता होनी चाहिए। यहां लोड को 1080p ऑडियो-वीडियो रिकॉर्डिंग आरंभीकरण के साथ हार्डवेयर वीडियो कोडेक्स का उपयोग करके समवर्ती 1080p से 720p वीडियो-केवल ट्रांसकोडिंग सत्र के रूप में परिभाषित किया गया है। डॉल्बी विज़न कोडेक के लिए, कोडेक आरंभीकरण विलंबता 50 एमएस या उससे कम होनी चाहिए।
- [5.1/एच-1-8] लोड होने पर सभी ऑडियो एन्कोडर्स के लिए 128 केबीपीएस या कम बिटरेट ऑडियो एन्कोडिंग सत्र के लिए 30 एमएस या उससे कम की कोडेक आरंभीकरण विलंबता होनी चाहिए। यहां लोड को 1080p ऑडियो-वीडियो रिकॉर्डिंग आरंभीकरण के साथ हार्डवेयर वीडियो कोडेक्स का उपयोग करके समवर्ती 1080p से 720p वीडियो-केवल ट्रांसकोडिंग सत्र के रूप में परिभाषित किया गया है।
- [5.1/एच-1-9] किसी भी कोडेक संयोजन में सुरक्षित हार्डवेयर वीडियो डिकोडर सत्र (एवीसी, एचईवीसी, वीपी9, एवी1 या बाद के संस्करण) के 2 उदाहरणों का समर्थन करना चाहिए जो दोनों 8- के लिए 4k रिज़ॉल्यूशन@30 एफपीएस (एवी1 को छोड़कर) पर समवर्ती रूप से चल रहे हों। बिट (एसडीआर) और 10-बिट एचडीआर सामग्री। AV1 कोडेक सत्रों को केवल 1080p रिज़ॉल्यूशन का समर्थन करने की आवश्यकता होती है, भले ही इसके लिए 4K की आवश्यकता हो।
- [5.1/एच-1-10] किसी भी कोडेक में सुरक्षित हार्डवेयर वीडियो डिकोडर सत्र के 1 उदाहरण (कुल 4 उदाहरण) (एवीसी, एचईवीसी, वीपी9, एवी1 या बाद में) के साथ गैर-सुरक्षित हार्डवेयर वीडियो डिकोडर सत्र के 3 उदाहरणों का समर्थन करना चाहिए। संयोजन 4के रेजोल्यूशन@30 एफपीएस (एवी1 को छोड़कर) पर 3 सत्रों के साथ समवर्ती रूप से चल रहा है जिसमें एक सुरक्षित डिकोडर सत्र और 1080पी रेजोल्यूशन@30एफपीएस पर 1 एनएन-सुरक्षित सत्र शामिल है जहां अधिकतम 2 सत्र 10-बिट एचडीआर में हो सकते हैं। AV1 कोडेक सत्रों को केवल 1080p रिज़ॉल्यूशन का समर्थन करने की आवश्यकता होती है, भले ही इसके लिए 4K की आवश्यकता हो।
- [5.1/एच-1-11] डिवाइस पर प्रत्येक हार्डवेयर एवीसी, एचईवीसी, वीपी9 या एवी1 डिकोडर के लिए एक सुरक्षित डिकोडर का समर्थन करना चाहिए।
- [5.1/एच-1-12] लोड होने पर सभी हार्डवेयर वीडियो डिकोडर्स के लिए 1080पी या छोटे वीडियो डिकोडिंग सत्र के लिए 40 एमएस या उससे कम की कोडेक आरंभीकरण विलंबता होनी चाहिए। यहां लोड को 1080p ऑडियो-वीडियो प्लेबैक इनिशियलाइज़ेशन के साथ हार्डवेयर वीडियो कोडेक्स का उपयोग करके समवर्ती 1080p से 720p वीडियो-केवल ट्रांसकोडिंग सत्र के रूप में परिभाषित किया गया है। डॉल्बी विज़न कोडेक के लिए, कोडेक आरंभीकरण विलंबता 50 एमएस या उससे कम होनी चाहिए।
- [5.1/एच-1-13] लोड होने पर सभी ऑडियो डिकोडर्स के लिए 128 केबीपीएस या कम बिटरेट ऑडियो डिकोडिंग सत्र के लिए 30 एमएस या उससे कम की कोडेक आरंभीकरण विलंबता होनी चाहिए। यहां लोड को 1080p ऑडियो-वीडियो प्लेबैक इनिशियलाइज़ेशन के साथ हार्डवेयर वीडियो कोडेक्स का उपयोग करके समवर्ती 1080p से 720p वीडियो-केवल ट्रांसकोडिंग सत्र के रूप में परिभाषित किया गया है।
- [5.1/एच-1-14] एवी1 हार्डवेयर डिकोडर मेन 10, लेवल 4.1 और फिल्म ग्रेन का समर्थन करना चाहिए।
- [5.1/एच-1-15] 4K60 को सपोर्ट करने वाला कम से कम 1 हार्डवेयर वीडियो डिकोडर होना चाहिए।
- [5.1/एच-1-16] 4K60 को सपोर्ट करने वाला कम से कम 1 हार्डवेयर वीडियो एनकोडर होना चाहिए।
- [5.3/एच-1-1] लोड के तहत 4के 60 एफपीएस वीडियो सत्र के लिए 10 सेकंड में 1 से अधिक फ्रेम नहीं गिरना चाहिए (यानी 0.167 प्रतिशत से कम फ्रेम ड्रॉप)।
- [5.3/एच-1-2] 4के सत्र के लिए लोड के तहत 60 एफपीएस वीडियो सत्र में वीडियो रिज़ॉल्यूशन परिवर्तन के दौरान 10 सेकंड में 1 फ्रेम से अधिक नहीं गिरना चाहिए।
- [5.6/एच-1-1] सीटीएस सत्यापनकर्ता टैप-टू-टोन परीक्षण का उपयोग करते हुए टैप-टू-टोन विलंबता 80 मिलीसेकंड या उससे कम होनी चाहिए।
- [5.6/एच-1-2] कम से कम एक समर्थित डेटा पथ पर 80 मिलीसेकंड या उससे कम की राउंड-ट्रिप ऑडियो विलंबता होनी चाहिए।
- [5.6/एच-1-3] यदि मौजूद है तो 3.5 मिमी ऑडियो जैक पर स्टीरियो आउटपुट के लिए >=24-बिट ऑडियो का समर्थन करना चाहिए और यदि कम विलंबता और स्ट्रीमिंग कॉन्फ़िगरेशन के लिए संपूर्ण डेटा पथ के माध्यम से समर्थित है तो यूएसबी ऑडियो पर समर्थन होना चाहिए। कम विलंबता कॉन्फ़िगरेशन के लिए, ऐप द्वारा कम विलंबता कॉलबैक मोड में AAudio का उपयोग किया जाना चाहिए। स्ट्रीमिंग कॉन्फ़िगरेशन के लिए, ऐप द्वारा जावा ऑडियोट्रैक का उपयोग किया जाना चाहिए। कम विलंबता और स्ट्रीमिंग कॉन्फ़िगरेशन दोनों में, HAL आउटपुट सिंक को अपने लक्ष्य आउटपुट प्रारूप के लिए
AUDIO_FORMAT_PCM_24_BIT,AUDIO_FORMAT_PCM_24_BIT_PACKED,AUDIO_FORMAT_PCM_32_BITयाAUDIO_FORMAT_PCM_FLOATस्वीकार करना चाहिए। - [5.6/एच-1-4] को >=4 चैनल यूएसबी ऑडियो डिवाइस का समर्थन करना चाहिए (इसका उपयोग गानों के पूर्वावलोकन के लिए डीजे नियंत्रकों द्वारा किया जाता है।)
- [5.6/एच-1-5] वर्ग अनुरूप MIDI उपकरणों का समर्थन करना चाहिए और MIDI सुविधा ध्वज घोषित करना चाहिए।
- [5.6/एच-1-9] कम से कम 12 चैनल मिश्रण का समर्थन करना चाहिए। इसका तात्पर्य 7.1.4 चैनल मास्क के साथ एक ऑडियोट्रैक खोलने और सभी चैनलों को स्टीरियो में उचित रूप से स्थानिक या डाउनमिक्स करने की क्षमता है।
- [5.6/एच-एसआर] 9.1.6 और 22.2 चैनल मास्क के लिए कम से कम समर्थन के साथ 24 चैनल मिश्रण का समर्थन करने की दृढ़ता से अनुशंसा की जाती है।
- [5.7/एच-1-2] को नीचे दी गई सामग्री डिक्रिप्शन क्षमताओं के साथ
MediaDrm.SECURITY_LEVEL_HW_SECURE_ALLका समर्थन करना चाहिए।
| न्यूनतम नमूना आकार | 4 एमआईबी |
| उपनमूनों की न्यूनतम संख्या - H264 या HEVC | 32 |
| उपनमूनों की न्यूनतम संख्या - VP9 | 9 |
| उपनमूनों की न्यूनतम संख्या - AV1 | 288 |
| न्यूनतम उपनमूना बफ़र आकार | 1 एमआईबी |
| न्यूनतम जेनेरिक क्रिप्टो बफ़र आकार | 500 कि.बी |
| समवर्ती सत्रों की न्यूनतम संख्या | 30 |
| प्रति सत्र कुंजियों की न्यूनतम संख्या | 20 |
| कुंजियों की न्यूनतम कुल संख्या (सभी सत्र) | 80 |
| डीआरएम कुंजियों की न्यूनतम कुल संख्या (सभी सत्र) | 6 |
| संदेश का आकार | 16 किबी |
| प्रति सेकंड डिक्रिप्टेड फ़्रेम | 60 एफपीएस |
- [5.1/एच-1-17] एवीआईएफ बेसलाइन प्रोफाइल का समर्थन करने वाला कम से कम 1 हार्डवेयर इमेज डिकोडर होना चाहिए।
- [5.1/एच-1-18] एवी1 एनकोडर का समर्थन करना चाहिए जो 30 एफपीएस और 1 एमबीपीएस पर 480पी रिज़ॉल्यूशन तक एनकोड कर सकता है।
-
[5.12/एच-1-1] आवश्यक है[5.12/एच-एसआर] डिवाइस पर मौजूद सभी हार्डवेयर एवी1 और एचईवीसी एनकोडर के लिएFeature_HdrEditingसुविधा का समर्थन करने के लिए दृढ़ता से अनुशंसित है। - [5.12/एच-1-2] डिवाइस पर मौजूद सभी हार्डवेयर AV1 और HEVC एनकोडर के लिए RGBA_1010102 रंग प्रारूप का समर्थन करना चाहिए।
- [5.12/एच-1-3] 8 और 10-बिट्स दोनों में YUV बनावट से नमूना लेने के लिए EXT_YUV_target एक्सटेंशन के लिए समर्थन का विज्ञापन करना चाहिए।
- [7.1.4/एच-1-1] डेटा प्रोसेसिंग यूनिट (डीपीयू) हार्डवेयर कंपोजर (एचडब्ल्यूसी) में कम से कम 6 हार्डवेयर ओवरले होने चाहिए, जिनमें से कम से कम 2 10-बिट वीडियो सामग्री प्रदर्शित करने में सक्षम हों।
यदि हैंडहेल्ड डिवाइस कार्यान्वयन android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS के लिए android.os.Build.VERSION_CODES.U लौटाता है और उनमें हार्डवेयर AVC या HEVC एनकोडर के लिए समर्थन शामिल है, तो वे:
- [5.2/एच-2-1] हार्डवेयर एवीसी और एचईवीसी कोडेक्स के लिए वीडियो एनकोडर दर-विरूपण वक्र द्वारा परिभाषित न्यूनतम गुणवत्ता लक्ष्य को पूरा करना होगा, जैसा कि आगामी दस्तावेज़ में परिभाषित किया गया है।
संशोधन देखें
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS के लिए android.os.Build.VERSION_CODES.U लौटाता है, तो वे:- [ 7.5 /एच-1-1] कम से कम 12 मेगापिक्सेल रिज़ॉल्यूशन वाला एक प्राथमिक रियर फेसिंग कैमरा होना चाहिए जो 4k@30एफपीएस पर वीडियो कैप्चर का समर्थन करता हो। प्राथमिक रियर-फेसिंग कैमरा सबसे कम कैमरा आईडी वाला रियर-फेसिंग कैमरा है।
- [ 7.5 /एच-1-2] कम से कम 6 मेगापिक्सेल के रिज़ॉल्यूशन वाला एक प्राथमिक फ्रंट फेसिंग कैमरा होना चाहिए और 1080p@30एफपीएस पर वीडियो कैप्चर का समर्थन करना चाहिए। प्राथमिक फ्रंट-फेसिंग कैमरा सबसे कम कैमरा आईडी वाला फ्रंट-फेसिंग कैमरा है।
- [ 7.5 /एच-1-3] दोनों प्राथमिक कैमरों के लिए
android.info.supportedHardwareLevelप्रॉपर्टी को पूर्ण या बेहतर के रूप में समर्थन करना चाहिए। - [ 7.5 /एच-1-4] दोनों प्राथमिक कैमरों के लिए
CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME का समर्थन करना चाहिए। - [ 7.5 /एच-1-5] दोनों प्राथमिक कैमरों के लिए आईटीएस प्रकाश स्थितियों (3000K) के तहत सीटीएस कैमरा परफॉर्मेंसटेस्ट द्वारा मापी गई 1080पी रिज़ॉल्यूशन के लिए कैमरा 2 जेपीईजी कैप्चर विलंबता <1000
900एमएस होनी चाहिए। - [ 7.5 /एच-1-6] दोनों प्राथमिक कैमरों के लिए आईटीएस प्रकाश स्थितियों (3000K) के तहत सीटीएस कैमरा प्रदर्शन परीक्षण द्वारा मापी गई कैमरा2 स्टार्टअप विलंबता (पहले पूर्वावलोकन फ्रेम के लिए खुला कैमरा) <500 एमएस होना चाहिए।
- [ 7.5 /एच-1-8] प्राथमिक बैक कैमरे के लिए
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAWREQUEST_AVAILABLE_CAPABILITIES_RAW औरandroid.graphics.ImageFormat.RAW_SENSORका समर्थन करना चाहिए। - [ 7.5 /एच-1-9] एक रियर-फेसिंग प्राइमरी कैमरा होना चाहिए जो 720पी या 1080पी @ 240एफपीएस सपोर्ट करता हो।
- [ 7.5 /एच-1-10] यदि समान दिशा में अल्ट्रावाइड आरजीबी कैमरा है तो प्राथमिक कैमरों के लिए न्यूनतम ज़ूम_RATIO <1.0 होना चाहिए।
- [ 7.5 /एच-1-11] प्राथमिक कैमरों पर समवर्ती फ्रंट-बैक स्ट्रीमिंग अवश्य लागू करें।
- [ 7.5 /एच-1-12] प्राइमरी फ्रंट और प्राइमरी बैक कैमरे दोनों के लिए
CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATIONसमर्थन करना चाहिए। - [ 7.5 /एच-1-13] यदि एक ही दिशा में 1 से अधिक आरजीबी कैमरे हैं तो प्राथमिक कैमरों के लिए
LOGICAL_MULTI_CAMERAक्षमता का समर्थन करना चाहिए। - [ 7.5 /एच-1-14] प्राथमिक फ्रंट और प्राथमिक बैक कैमरे दोनों के लिए
STREAM_USE_CASEक्षमता का समर्थन करना चाहिए। - [ 7.5 /एच-1-15] प्राथमिक कैमरों के लिए कैमराएक्स और कैमरा2 दोनों एक्सटेंशन के माध्यम से
बोकेह औरनाइट मोड एक्सटेंशन का समर्थन करना चाहिए। - [ 7.5 /H-1-16] प्राथमिक कैमरों के लिए DYNAMIC_RANGE_TEN_BIT क्षमता का समर्थन करना चाहिए।
- [ 7.5 /एच-1-17] प्राथमिक कैमरों के लिए CONTROL_SCENE_MODE_FACE_PRIORITY और फेस डिटेक्शन ( STATISTICS_FACE_DETECT_MODE_SIMPLE या STATISTICS_FACE_DETECT_MODE_FULL ) का समर्थन करना चाहिए।
संशोधन देखें
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS के लिए android.os.Build.VERSION_CODES.U लौटाता है, तो वे:- [7.1.1.1/एच-2-1] स्क्रीन रिज़ॉल्यूशन कम से कम 1080p होना चाहिए।
- [7.1.1.3/एच-2-1] स्क्रीन घनत्व कम से कम 400 डीपीआई होना चाहिए।
- [7.1.1.3/एच-3-1] कम से कम 1000 निट्स औसत का समर्थन करने वाला एचडीआर डिस्प्ले होना चाहिए।
- [7.6.1/एच-2-1] कम से कम 8 जीबी की भौतिक मेमोरी होनी चाहिए।
संशोधन देखें
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS के लिए android.os.Build.VERSION_CODES.U लौटाता है, तो वे:- [8.2/एच-1-1] कम से कम 150 एमबी/सेकेंड का क्रमिक लेखन प्रदर्शन सुनिश्चित करना होगा।
- [8.2/एच-1-2] कम से कम 10 एमबी/सेकेंड का यादृच्छिक लेखन प्रदर्शन सुनिश्चित करना होगा।
- [8.2/एच-1-3] कम से कम 250 एमबी/सेकेंड का क्रमिक पढ़ने का प्रदर्शन सुनिश्चित करना होगा।
- [8.2/एच-1-4] कम से कम 100 एमबी/सेकेंड का यादृच्छिक पढ़ने का प्रदर्शन सुनिश्चित करना चाहिए।
- [8.2/एच-1-5] कम से कम 50 एमबी/सेकेंड के 2x पढ़ने और 1x लिखने के प्रदर्शन के साथ समानांतर अनुक्रमिक पढ़ने और लिखने का प्रदर्शन सुनिश्चित करना चाहिए।
संशोधन देखें
टेलीविज़न डिवाइस कार्यान्वयन को निम्नलिखित वीडियो एन्कोडिंग प्रारूपों का समर्थन करना चाहिए और उन्हें तृतीय-पक्ष अनुप्रयोगों के लिए उपलब्ध कराना चाहिए:
- [ 5.2 /टी-0-3] एवी1
टेलीविज़न डिवाइस कार्यान्वयन को निम्नलिखित वीडियो डिकोडिंग प्रारूपों का समर्थन करना चाहिए और उन्हें तृतीय-पक्ष अनुप्रयोगों के लिए उपलब्ध कराना चाहिए:
- [ 5.3.2 /टी-0-7] एवी1
संशोधन देखें
यदि डिवाइस कार्यान्वयन में एक सुरक्षित लॉक स्क्रीन है और इसमें एक या अधिक ट्रस्ट एजेंट शामिल हैं, जो TrustAgentService सिस्टम एपीआई लागू करता है, तो वे:
- [ 9.11.1 /डब्ल्यू-1-1] अनुशंसित प्राथमिक प्रमाणीकरण विधियों (जैसे: पिन, पैटर्न, पासवर्ड) में से एक के लिए उपयोगकर्ता को हर 72 घंटे में एक से अधिक बार चुनौती देनी चाहिए।
संशोधन देखें
यदि डिवाइस कार्यान्वयन में एएम/एफएम प्रसारण रेडियो के लिए समर्थन शामिल है और किसी भी एप्लिकेशन के लिए कार्यक्षमता को उजागर किया गया है, तो वे:
- [ 7.4
.10/ए-0-1]FEATURE_BROADCAST_RADIOके लिए समर्थन की घोषणा अवश्य करें।
बाहरी दृश्य कैमरा एक ऐसा कैमरा है जो डिवाइस कार्यान्वयन के बाहर के दृश्यों को चित्रित करता है, जैसे कि रियरव्यू कैमरा।
ऑटोमोटिव डिवाइस कार्यान्वयन:
- इसमें एक या अधिक बाहरी दृश्य कैमरे शामिल होने चाहिए।
यदि ऑटोमोटिव डिवाइस कार्यान्वयन में बाहरी दृश्य कैमरा शामिल है, तो ऐसे कैमरे के लिए, वे:
- [ 7.5 /ए-1-1] एंड्रॉइड कैमरा एपीआई के माध्यम से पहुंच योग्य बाहरी दृश्य कैमरे नहीं होने चाहिए, जब तक कि वे कैमरा मुख्य आवश्यकताओं का अनुपालन न करें।
- [ 7.5 /ए-एसआर-1] कैमरे के पूर्वावलोकन को घुमाने या क्षैतिज रूप से प्रतिबिंबित न करने की दृढ़ता से अनुशंसा की जाती है।
- [ 7.5 /ए-एसआर-2] कम से कम 1.3 मेगापिक्सेल का रिज़ॉल्यूशन रखने की दृढ़ता से अनुशंसा की जाती है।
- इसमें या तो फिक्स्ड-फोकस या ईडीओएफ (फील्ड की विस्तारित गहराई) हार्डवेयर होना चाहिए।
- कैमरा ड्राइवर में या तो हार्डवेयर ऑटो-फ़ोकस या सॉफ़्टवेयर ऑटो-फ़ोकस लागू हो सकता है।
यदि ऑटोमोटिव डिवाइस कार्यान्वयन में एक या अधिक बाहरी दृश्य कैमरे शामिल हैं, और बाहरी दृश्य प्रणाली (ईवीएस) सेवा लोड करते हैं, तो ऐसे कैमरे के लिए, वे:
- [ 7.5 /ए-2-1] कैमरा पूर्वावलोकन को घुमाना या क्षैतिज रूप से प्रतिबिंबित नहीं करना चाहिए।
ऑटोमोटिव डिवाइस कार्यान्वयन:
- MAY में एक या अधिक कैमरे शामिल हो सकते हैं जो तीसरे पक्ष के अनुप्रयोगों के लिए उपलब्ध हैं।
यदि ऑटोमोटिव डिवाइस कार्यान्वयन में कम से कम एक कैमरा शामिल है और इसे तीसरे पक्ष के अनुप्रयोगों के लिए उपलब्ध कराया जाता है, तो वे:
- [ 7.5 /ए-3-1] फीचर फ़्लैग
android.hardware.camera.anyकी रिपोर्ट अवश्य करें। - [ 7.5 /ए-3-2] कैमरे को सिस्टम कैमरा घोषित नहीं किया जाना चाहिए।
- अनुभाग 7.5.3 में वर्णित बाहरी कैमरों का समर्थन किया जा सकता है।
- अनुभाग 7.5.1 में वर्णित अनुसार रियर-फेसिंग कैमरों के लिए उपलब्ध सुविधाएँ (जैसे ऑटो-फ़ोकस, आदि) शामिल हो सकती हैं।
रियर-फेसिंग कैमरा का मतलब एक विश्व-फेसिंग कैमरा है जो वाहन पर किसी भी स्थान पर स्थित हो सकता है और वाहन केबिन के बाहर की ओर होता है; यानी, यह रियर-व्यू कैमरे की तरह, वाहन के शरीर के दूर के दृश्यों को चित्रित करता है।
फ्रंट-फेसिंग कैमरा का अर्थ उपयोगकर्ता-फेसिंग कैमरा है जो वाहन पर किसी भी स्थान पर स्थित हो सकता है और वाहन केबिन के अंदर की ओर होता है; यानी यह उपयोगकर्ता की छवियाँ बनाता है, जैसे कि वीडियो कॉन्फ्रेंसिंग और इसी तरह के अनुप्रयोगों के लिए।
ऑटोमोटिव डिवाइस कार्यान्वयन:
- [7.5/ए-एसआर-1] एक या अधिक विश्व-मुखी कैमरे शामिल करने की दृढ़ता से अनुशंसा की जाती है।
- MAY में एक या अधिक उपयोगकर्ता-सामना वाले कैमरे शामिल हो सकते हैं।
- [7.5/ए-एसआर-2] कई कैमरों की समवर्ती स्ट्रीमिंग का समर्थन करने की दृढ़ता से अनुशंसा की जाती है।
यदि ऑटोमोटिव डिवाइस कार्यान्वयन में कम से कम एक कैमरा शामिल है जो विश्व-मुखी है, तो ऐसे कैमरे के लिए, वे:
- [7.5/ए-1-1] उन्मुख होना चाहिए ताकि कैमरे का लंबा आयाम एंड्रॉइड ऑटोमोटिव सेंसर अक्षों के एक्सवाई विमान के साथ संरेखित हो।
- [7.5/ए-एसआर-3] फिक्स्ड-फोकस या ईडीओएफ (फील्ड की विस्तारित गहराई) हार्डवेयर की दृढ़ता से अनुशंसा की जाती है।
- [7.5/ए-1-2] सबसे कम कैमरा आईडी वाला विश्व-सामना करने वाला प्राथमिक कैमरा होना चाहिए।
यदि ऑटोमोटिव डिवाइस कार्यान्वयन में कम से कम एक कैमरा शामिल है जो उपयोगकर्ता-सामना कर रहा है, तो ऐसे कैमरे के लिए:
- [7.5/ए-2-1] प्राथमिक उपयोगकर्ता-सामना वाला कैमरा सबसे कम कैमरा आईडी वाला उपयोगकर्ता-सामना वाला कैमरा होना चाहिए।
- MAY को उन्मुख किया जा सकता है ताकि कैमरे का लंबा आयाम एंड्रॉइड ऑटोमोटिव सेंसर अक्षों के XY विमान के साथ संरेखित हो।
यदि ऑटोमोटिव डिवाइस कार्यान्वयन में एक कैमरा शामिल है जो android.hardware.Camera या android.hardware.camera2 API के माध्यम से पहुंच योग्य है, तो वे:
- [7.5/ए-3-1] अनुभाग 7.5 में मुख्य कैमरा आवश्यकताओं का अनुपालन करना होगा।
यदि ऑटोमोटिव डिवाइस कार्यान्वयन में एक कैमरा शामिल है जो android.hardware.Camera या android.hardware.camera2 API के माध्यम से पहुंच योग्य नहीं है, तो वे:
- [7.5/ए-4-1] एक्सटेंडेड व्यू सिस्टम सेवा के माध्यम से पहुंच योग्य होना चाहिए।
यदि ऑटोमोटिव डिवाइस कार्यान्वयन में विस्तारित व्यू सिस्टम सेवा के माध्यम से पहुंच योग्य एक या अधिक कैमरे शामिल हैं, तो ऐसे कैमरे के लिए, वे:
- [7.5/ए-5-1] कैमरा पूर्वावलोकन को घुमाना या क्षैतिज रूप से प्रतिबिंबित नहीं करना चाहिए।
- [7.5/ए-एसआर-4] कम से कम 1.3 मेगापिक्सेल का रिज़ॉल्यूशन रखने की दृढ़ता से अनुशंसा की जाती है।
यदि ऑटोमोटिव डिवाइस कार्यान्वयन में एक या अधिक कैमरे शामिल हैं जो विस्तारित व्यू सिस्टम सेवा और android.hardware.Camera या android.hardware.Camera2 API दोनों के माध्यम से पहुंच योग्य हैं, तो ऐसे कैमरे के लिए, वे:
- [7.5/ए-6-1] एक ही कैमरा आईडी की रिपोर्ट करनी होगी।
यदि ऑटोमोटिव डिवाइस कार्यान्वयन एक मालिकाना कैमरा एपीआई प्रदान करता है, तो वे:
- [7.5/ए-7-1]
android.hardware.camera2एपीआई या एक्सटेंडेड व्यू सिस्टम एपीआई का उपयोग करके ऐसे कैमरा एपीआई को लागू करना होगा।
संशोधन देखें
ऑटोमोटिव डिवाइस कार्यान्वयन:
- [ 3.8 /ए-0-1] पूर्ण माध्यमिक उपयोगकर्ताओं को, जो वर्तमान अग्रभूमि उपयोगकर्ता नहीं हैं, गतिविधियों को लॉन्च करने और किसी भी डिस्प्ले पर यूआई तक पहुंच की अनुमति नहीं देनी चाहिए।
संशोधन देखें
यदि ऑटोमोटिव डिवाइस कार्यान्वयन android.hardware.microphone घोषित करते हैं, तो वे:
- [ 9.8.2 /ए-1-1] जब कोई ऐप माइक्रोफ़ोन से ऑडियो डेटा एक्सेस कर रहा हो तो माइक्रोफ़ोन संकेतक अवश्य प्रदर्शित करें, लेकिन तब नहीं जब माइक्रोफ़ोन केवल
HotwordDetectionService,SOURCE_HOTWORD,ContentCaptureServiceया अनुभाग में बताई गई भूमिका निभाने वाले ऐप्स द्वारा एक्सेस किया जाता है। 9.1 सीडीडी पहचानकर्ता के साथ [सी-4-एक्स]। - [ 9.8.2 /ए-1-2] उन सिस्टम ऐप्स के लिए माइक्रोफ़ोन संकेतक को छिपाना नहीं चाहिए जिनमें दृश्य उपयोगकर्ता इंटरफ़ेस या प्रत्यक्ष उपयोगकर्ता इंटरैक्शन है।
- [ 9.8.2 /ए-1-3] सेटिंग्स ऐप में माइक्रोफ़ोन को टॉगल करने के लिए उपयोगकर्ता को सुविधा प्रदान करनी होगी।
यदि ऑटोमोटिव डिवाइस कार्यान्वयन android.hardware.camera.any घोषित करते हैं, तो वे:
- [ 9.8.2 /ए-2-1] जब कोई ऐप लाइव कैमरा डेटा तक पहुंच रहा हो तो कैमरा संकेतक प्रदर्शित करना चाहिए, लेकिन तब नहीं जब कैमरे को केवल ऐप द्वारा एक्सेस किया जा रहा हो, जो धारा 9.1 अनुमतियों में
बताईगई भूमिका निभाते हैं। सीडीडी पहचानकर्ता के साथ [सी-4-एक्स][सी-3-एक्स]।
यदि डिवाइस कार्यान्वयन में एक सुरक्षित लॉक स्क्रीन है और इसमें एक या अधिक ट्रस्ट एजेंट शामिल हैं, जो TrustAgentService सिस्टम एपीआई लागू करता है, तो वे:
- [ 9.11.1 /ए-1-1] अनुशंसित प्राथमिक प्रमाणीकरण विधियों (जैसे: पिन, पैटर्न, पासवर्ड) में से एक के लिए उपयोगकर्ता को हर 336 घंटे में एक से अधिक बार चुनौती देनी चाहिए।
3. सॉफ्टवेयर
संशोधन देखें
डिवाइस कार्यान्वयन:
- [सी-0-8] 23 से कम एपीआई स्तर को लक्षित करने वाले एप्लिकेशन इंस्टॉल करने का समर्थन नहीं करना चाहिए।
3.2.3.5. सशर्त अनुप्रयोग आशय :
संशोधन देखें
यदि डिवाइस कार्यान्वयन
android.hardware.nfc.uiccयाandroid.hardware.nfc.eseरिपोर्ट करते हैं, तो वे:- [C-19-1] NfcAdapter.ACTION_TRANSACTION_DETECTED इंटेंट API ( GSM एसोसिएशन तकनीकी विनिर्देश TS.26 - NFC हैंडसेट आवश्यकताएँ द्वारा परिभाषित "EVT_TRANSACTION" के रूप में) को लागू करना होगा।
3.3.1. अनुप्रयोग बाइनरी इंटरफ़ेस :
संशोधन देखें
डिवाइस कार्यान्वयन:
- [सी-0-12] कोर
वल्कन 1.0वल्कन 1.1 फ़ंक्शन प्रतीकों के साथ-साथVK_KHR_surface,VK_KHR_android_surface,VK_KHR_swapchain,VK_KHR_maintenance1, औरVK_KHR_get_physical_device_properties22 एक्सटेंशन के लिए फ़ंक्शन प्रतीकों कोlibvulkan.soलाइब्रेरी के माध्यम से निर्यात करना होगा। ध्यान दें कि जबकि सभी प्रतीक मौजूद होने चाहिए, खंड 7.1.4.2 उन आवश्यकताओं का अधिक विस्तार से वर्णन करता है जब प्रत्येक संबंधित फ़ंक्शन का पूर्ण कार्यान्वयन अपेक्षित होता है।
- [सी-0-12] कोर
संशोधन देखें
यदि डिवाइस कार्यान्वयन में स्क्रीन या वीडियो आउटपुट शामिल है, तो वे:
- [सी-1-5]
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGESTHEME_CUSTOMIZATION_OVERLAY_PACKAGES दस्तावेज़ (android.theme.customization.theme_stylesदेखें) में उल्लिखित रंग थीम शैलियों का उपयोग करके गतिशील रंग टोनल पैलेट उत्पन्न करना होगा, अर्थात्TONAL_SPOT,VIBRANT,EXPRESSIVE,SPRITZ,RAINBOW,FRUIT_SALAD, औरMONOCHROMATIC.
- [सी-1-5]
संशोधन देखें
यदि अनुभाग 7.2.3 में वर्णित हालिया फ़ंक्शन नेविगेशन कुंजी सहित डिवाइस कार्यान्वयन इंटरफ़ेस को बदलता है, तो वे:
- [सी-1-2] स्क्रीन पिनिंग व्यवहार को लागू करना होगा और उपयोगकर्ता को सुविधा को टॉगल करने के लिए एक सेटिंग मेनू प्रदान करना होगा।
3.9.2 प्रबंधित प्रोफ़ाइल समर्थन :
संशोधन देखें
यदि डिवाइस कार्यान्वयन
android.software.managed_usersघोषित करते हैं, तो वे:- [सी-1-10] यह सुनिश्चित करना होगा कि स्क्रीनशॉट डेटा कार्य प्रोफ़ाइल स्टोरेज में सहेजा गया है जब स्क्रीनशॉट को
topActivityविंडो के साथ कैप्चर किया जाता है जिसमें फोकस होता है (उपयोगकर्ता ने सभी गतिविधियों के बीच आखिरी बार इंटरैक्ट किया था) और वर्क प्रोफ़ाइल से संबंधित होता है अनुप्रयोग । - [सी-1-11] कार्य प्रोफ़ाइल में स्क्रीनशॉट सहेजते समय कार्य प्रोफ़ाइल एप्लिकेशन विंडो/विंडोज़ को छोड़कर किसी भी अन्य स्क्रीन सामग्री (सिस्टम बार, नोटिफिकेशन या किसी व्यक्तिगत प्रोफ़ाइल सामग्री) को कैप्चर नहीं करना चाहिए (यह सुनिश्चित करने के लिए कि व्यक्तिगत प्रोफ़ाइल डेटा है) कार्य प्रोफ़ाइल में सहेजा नहीं गया)।
- [सी-1-10] यह सुनिश्चित करना होगा कि स्क्रीनशॉट डेटा कार्य प्रोफ़ाइल स्टोरेज में सहेजा गया है जब स्क्रीनशॉट को
3.9.5 डिवाइस नीति रिज़ॉल्यूशन फ़्रेमवर्क : नया अनुभाग
संशोधन देखें
यदि डिवाइस कार्यान्वयन
android.software.device_adminयाandroid.software.managed_usersरिपोर्ट करते हैं, तो वे:- [सी-1-1] एओएसपी दस्तावेज़ में दर्ज डिवाइस नीति विवादों को अवश्य हल करें।
5. मल्टीमीडिया संगतता
संशोधन देखें
डिवाइस कार्यान्वयन को निम्नलिखित छवि एन्कोडिंग को एन्कोडिंग का समर्थन करना चाहिए:
- [सी-0-4] एवीआईएफ
- डिवाइस को
BITRATE_MODE_CQऔर बेसलाइन प्रोफ़ाइल का समर्थन करना चाहिए।
- डिवाइस को
- [सी-0-4] एवीआईएफ
संशोधन देखें
डिवाइस कार्यान्वयन को निम्नलिखित छवि एन्कोडिंग को डिकोड करने का समर्थन करना चाहिए:
[सी-0-7] एवीआईएफ (बेसलाइन प्रोफाइल)
संशोधन देखें
प्रारूप/कोडेक विवरण समर्थित फ़ाइल प्रकार/कंटेनर प्रारूप जेपीईजी आधार+प्रगतिशील जेपीईजी (.jpg) GIF जीआईएफ (.gif) पीएनजी पीएनजी (.png) बीएमपी बीएमपी (.बीएमपी) वेबपी वेबपी (.वेबपी) कच्चा ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 ( .rw2), एसआरडब्ल्यू (.srw) HEIF छवि, छवि संग्रह, छवि अनुक्रम HEIF (.heif), HEIC (.heic) एवीआईएफ (बेसलाइन प्रोफ़ाइल) छवि, छवि संग्रह, छवि अनुक्रम बेसलाइन प्रोफ़ाइल HEIF कंटेनर (.avif) संशोधन देखें
प्रारूप/कोडेक विवरण समर्थित फ़ाइल प्रकार/कंटेनर प्रारूप एच .263 - 3जीपीपी (.3जीपी)
- एमपीईजी-4 (.mp4)
- मैट्रोस्का (.mkv, केवल डिकोड)
एच.264 एवीसी विवरण के लिए अनुभाग 5.2 और 5.3 देखें - 3जीपीपी (.3जीपी)
- एमपीईजी-4 (.mp4)
- एमपीईजी-2 टीएस (.ts, खोजने योग्य नहीं)
- मैट्रोस्का (.mkv, केवल डिकोड)
एच.265 एचईवीसी विवरण के लिए अनुभाग 5.3 देखें - एमपीईजी-4 (.mp4)
- मैट्रोस्का (.mkv, केवल डिकोड)
एमपीईजी -2 मुख्य प्रोफ़ाइल - MPEG2-TS (.ts, खोजने योग्य नहीं)
- एमपीईजी-4 (.mp4, केवल डिकोड)
- मैट्रोस्का (.mkv, केवल डिकोड)
एमपीईजी-4 एसपी - 3जीपीपी (.3जीपी)
- एमपीईजी-4 (.mp4)
- मैट्रोस्का (.mkv, केवल डिकोड)
वीपी8 विवरण के लिए अनुभाग 5.2 और 5.3 देखें - वेबएम (.वेबएम)
- मैट्रोस्का (.mkv)
वीपी9 विवरण के लिए अनुभाग 5.3 देखें - वेबएम (.वेबएम)
- मैट्रोस्का (.mkv)
AV1 विवरण के लिए अनुभाग 5.2 और अनुभाग 5.3 देखें - एमपीईजी-4 (.mp4)
- मैट्रोस्का (.mkv, केवल डिकोड)
5.1.10. मीडिया कोडेक विशेषता :
संशोधन देखें
यदि डिवाइस कार्यान्वयन वीडियो कोडेक्स का समर्थन करता है:
- [सी-2-1] सभी वीडियो कोडेक्स को कोडेक द्वारा समर्थित होने पर निम्नलिखित आकारों के लिए प्राप्त फ्रेम दर डेटा प्रकाशित करना होगा:
एसडी (निम्न गुणवत्ता) एसडी (उच्च गुणवत्ता) एचडी 720पी एचडी 1080पी यूएचडी वीडियो संकल्प - 176 x 144 पिक्सल (एच263, एमपीईजी2, एमपीईजी4)
- 352 x 288 पीएक्स (एमपीईजी4 एनकोडर, एच263, एमपीईजी2)
- 320 x 180 पिक्सल (वीपी8, वीपी8)
- 320 x 240 पिक्सल (अन्य)
- 704 x 576 पिक्सल (एच263)
- 640 x 360 पिक्सल (वीपी8, वीपी9)
- 640 x 480 पीएक्स (एमपीईजी4 एनकोडर)
- 720 x 480 पिक्सेल (अन्य, AV1 )
- 1408 x 1152 पीएक्स (एच263)
- 1280 x 720 पिक्सेल (अन्य, AV1 )
1920 x 1080 px (MPEG4, AV1 के अलावा) 3840 x 2160 पिक्सल (एचईवीसी, वीपी9, एवी1 ) संशोधन देखें
यदि डिवाइस कार्यान्वयन किसी वीडियो एनकोडर का समर्थन करता है और इसे तृतीय-पक्ष ऐप्स के लिए उपलब्ध कराता है, तो वे:- दो स्लाइडिंग विंडो पर, इंट्राफ्रेम (आई-फ्रेम) अंतराल के बीच बिटरेट 15% से अधिक नहीं होना चाहिए।
- 1 सेकंड की स्लाइडिंग विंडो पर बिटरेट 100% से अधिक नहीं होनी चाहिए।
यदि डिवाइस कार्यान्वयन किसी भी वीडियो एनकोडर का समर्थन करता है और इसे तृतीय-पक्ष ऐप्स के लिए उपलब्ध कराता है, और सेट करता है
MediaFormat.KEY_BITRATE_MODEसेBITRATE_MODE_VBRताकि एनकोडर वैरिएबल बिटरेट मोड में काम करे, तब तक, जब तक यह न्यूनतम गुणवत्ता स्तर को प्रभावित नहीं करता, एन्कोडेड बिटरेट:-
[सी-5-1] एक स्लाइडिंग विंडो पर, इंट्राफ्रेम (आई-फ्रेम) अंतराल के बीच बिटरेट 15% से अधिक नहीं होना चाहिए। -
[सी-5-2] 1 सेकंड की स्लाइडिंग विंडो पर बिटरेट 100% से अधिक नहीं होना चाहिए।
यदि डिवाइस कार्यान्वयन किसी भी वीडियो एनकोडर का समर्थन करता है और इसे तृतीय-पक्ष ऐप्स के लिए उपलब्ध कराता है और
MediaFormat.KEY_BITRATE_MODEकोBITRATE_MODE_CBRपर सेट करता है ताकि एनकोडर निरंतर बिटरेट मोड में काम करे, तो एन्कोडेड बिटरेट:-
[सी-6-1] अवश्य होना चाहिए[सी-एसआर-2] 1 सेकंड की स्लाइडिंग विंडो पर लक्ष्य बिटरेट से 15% से अधिक नहीं होना चाहिए।
संशोधन देखें
यदि डिवाइस कार्यान्वयन H.263 एनकोडर का समर्थन करता है और इसे तृतीय-पक्ष ऐप्स के लिए उपलब्ध कराता है, तो वे:
- [सी-1-1] बेसलाइन प्रोफ़ाइल स्तर 45 का उपयोग करके क्यूसीआईएफ रिज़ॉल्यूशन (176 x 144) का समर्थन करना चाहिए । एसक्यूसीआईएफ रिज़ॉल्यूशन वैकल्पिक है।
-
समर्थित एनकोडर के लिए गतिशील रूप से कॉन्फ़िगर करने योग्य बिटरेट का समर्थन करना चाहिए।
संशोधन देखें
यदि डिवाइस कार्यान्वयन H.265 कोडेक का समर्थन करता है, तो वे:
- [सी-1-1] 512 x 512 रिज़ॉल्यूशन तक मुख्य प्रोफ़ाइल स्तर 3 का समर्थन करना चाहिए।
-
निम्न तालिका में दर्शाए अनुसार एचडी एन्कोडिंग प्रोफाइल का समर्थन करना चाहिए। - [सी-एसआर-1] को 720 x 480 एसडी प्रोफ़ाइल और एचडी एन्कोडिंग प्रोफाइल का समर्थन करने की दृढ़ता से अनुशंसा की जाती है जैसा कि हार्डवेयर एनकोडर होने पर निम्न तालिका में दर्शाया गया है।
5.2.6. AV1 : नया अनुभाग
संशोधन देखें
यदि डिवाइस कार्यान्वयन AV1 कोडेक का समर्थन करता है, तो वे:
- [सी-1-1] 8-बिट और 10-बिट सामग्री सहित मुख्य प्रोफ़ाइल का समर्थन करना चाहिए।
[सी-1-2] प्रदर्शन डेटा अवश्य प्रकाशित करें अर्थात नीचे दी गई तालिका में समर्थित रिज़ॉल्यूशन के लिए
getSupportedFrameRatesFor()याgetSupportedPerformancePoints()API के माध्यम से प्रदर्शन डेटा रिपोर्ट करें।[सी-1-3] एचडीआर मेटाडेटा को स्वीकार करना होगा और इसे बिटस्ट्रीम पर आउटपुट करना होगा
यदि AV1 एनकोडर हार्डवेयर त्वरित है, तो यह:
- [सी-2-1] को नीचे दी गई तालिका से एचडी1080पी एन्कोडिंग प्रोफ़ाइल का समर्थन करना चाहिए:
एसडी एचडी 720पी एचडी 1080पी यूएचडी वीडियो संकल्प 720 x 480 पिक्सल 1280 x 720 पिक्सेल 1920 x 1080 पिक्सल 3840 x 2160 पिक्सल वीडियो फ्रेम दर 30 एफपीएस 30 एफपीएस 30 एफपीएस 30 एफपीएस वीडियो बिटरेट 5 एमबीपीएस 8 एमबीपीएस 16 एमबीपीएस 50 एमबीपीएस संशोधन देखें
यदि डिवाइस कार्यान्वयन H.263 डिकोडर का समर्थन करता है, तो वे:
- [सी-1-1] को बेसलाइन प्रोफाइल लेवल 30 (सीआईएफ, क्यूसीआईएफ और एसक्यूसीआईएफ रेजोल्यूशन @ 30एफपीएस 384 केबीपीएस) और लेवल 45 (क्यूसीआईएफ और एसक्यूसीआईएफ रेजोल्यूशन @ 30एफपीएस 128 केबीपीएस) का समर्थन करना चाहिए।
संशोधन देखें
यदि डिवाइस कार्यान्वयन AV1 कोडेक का समर्थन करता है, तो वे:- [सी-1-1] 10-बिट सामग्री सहित प्रोफाइल 0 का समर्थन करना चाहिए।
यदि डिवाइस कार्यान्वयन AV1 कोडेक का समर्थन करता है और इसे तृतीय-पक्ष अनुप्रयोगों के लिए उपलब्ध कराता है, तो वे:
- [सी-1-1] 8-बिट और 10-बिट सामग्री सहित मुख्य प्रोफ़ाइल का समर्थन करना चाहिए।
यदि डिवाइस कार्यान्वयन हार्डवेयर त्वरित डिकोडर के साथ AV1 कोडेक के लिए समर्थन प्रदान करता है तो वे:
- [सी-2-1]
Display.getSupportedModes()विधि द्वारा रिपोर्ट की गई ऊंचाई 720पी के बराबर या उससे अधिक होने पर नीचे दी गई तालिका से कम से कम एचडी 720पी वीडियो डिकोडिंग प्रोफाइल को डिकोड करने में सक्षम होना चाहिए। - [सी-2-2]
Display.getSupportedModes()विधि द्वारा रिपोर्ट की गई ऊंचाई 1080पी के बराबर या उससे अधिक होने पर नीचे दी गई तालिका से कम से कम एचडी 1080पी वीडियो डिकोडिंग प्रोफाइल को डीकोड करने में सक्षम होना चाहिए।
एसडी एचडी 720पी एचडी 1080पी यूएचडी वीडियो संकल्प 720 x 480 पिक्सल 1280 x 720 पिक्सेल 1920 x 1080 पिक्सल 3840 x 2160 पिक्सल वीडियो फ्रेम दर 30 एफपीएस 30 एफपीएस 30 एफपीएस 30 एफपीएस वीडियो बिटरेट 5 एमबीपीएस 8 एमबीपीएस 16 एमबीपीएस 50 एमबीपीएस यदि डिवाइस कार्यान्वयन मीडिया एपीआई के माध्यम से एचडीआर प्रोफाइल का समर्थन करता है, तो वे:
- [सी-3-1] बिटस्ट्रीम और/या कंटेनर से एचडीआर मेटाडेटा निकालने और आउटपुट करने का समर्थन करना चाहिए।
- [सी-3-2] डिवाइस स्क्रीन पर या मानक वीडियो आउटपुट पोर्ट (उदाहरण के लिए, एचडीएमआई) पर एचडीआर सामग्री को ठीक से प्रदर्शित करना चाहिए।
5.4.2. आवाज पहचान के लिए कैप्चर :
संशोधन देखें
यदि डिवाइस कार्यान्वयन
android.hardware.microphoneघोषित करते हैं, तो वे:- ऑडियो इनपुट संवेदनशीलता को ऐसे सेट करना चाहिए कि 90 डीबी ध्वनि दबाव स्तर (एसपीएल) (माइक्रोफोन के बगल
से 30 सेमी की दूरी परमापा गया) पर बजाया गया 1000 हर्ट्ज साइनसोइडल टोन स्रोत 1770 की सीमा के भीतर आरएमएस 2500 की एक आदर्श प्रतिक्रिया उत्पन्न करता है। ध्वनि पहचान ऑडियो स्रोत को रिकॉर्ड करने के लिए उपयोग किए जाने वाले प्रत्येक माइक्रोफ़ोन के लिए 16 बिट-नमूनों के लिए 3530 (या -22.35 डीबी ±3 डीबी पूर्ण स्केल फ्लोटिंग पॉइंट/डबल सटीक नमूनों के लिए)।
- ऑडियो इनपुट संवेदनशीलता को ऐसे सेट करना चाहिए कि 90 डीबी ध्वनि दबाव स्तर (एसपीएल) (माइक्रोफोन के बगल
संशोधन देखें
यदि डिवाइस कार्यान्वयन सुविधा
android.hardware.audio.outputघोषित करता है, तो वे:- [सी-1-4] को फ़्लोटिंग-पॉइंट इनपुट और आउटपुट के साथ ऑडियो प्रभावों का समर्थन करना चाहिए।
- [सी-1-5] यह अवश्य सुनिश्चित करें कि ऑडियो प्रभाव मिक्सर चैनल गिनती तक कई चैनलों का समर्थन करते हैं जिन्हें FCC_LIMIT भी कहा जाता है।
संशोधन देखें
यदि डिवाइस कार्यान्वयन
android.hardware.audio.outputघोषित करता है, तो उन्हें निम्नलिखित आवश्यकताओं को पूरा करने या उससे अधिक करने की दृढ़ता से अनुशंसा की जाती है:- [सी-एसआर-4] AudioTrack.getTimestamp और
AAudioStream_getTimestampद्वारा लौटाया गया आउटपुट टाइमस्टैम्प +/- 1 एमएस तक सटीक है।
- [सी-एसआर-4]
AAudioStream_getTimestampद्वारा लौटाए गए इनपुट और आउटपुट टाइमस्टैम्प के आधार पर गणना की गई राउंड-ट्रिप विलंबता, स्पीकर, वायर्ड और वायरलेस हेडसेट के लिएAAUDIO_PERFORMANCE_MODE_NONEऔरAAUDIO_PERFORMANCE_MODE_LOW_LATENCYके लिए मापी गई राउंड ट्रिप विलंबता के 30 मिसे के भीतर होने की दृढ़ता से अनुशंसा की जाती है।
- [सी-एसआर-4] AudioTrack.getTimestamp और
7. हार्डवेयर अनुकूलता
संशोधन देखें
एंड्रॉइड में ऐसी सुविधाएं शामिल हैं जो डिवाइस के लिए एप्लिकेशन संपत्तियों और यूआई लेआउट को स्वचालित रूप से समायोजित करती हैं ताकि यह सुनिश्चित किया जा सके कि तृतीय-पक्ष एप्लिकेशन
विभिन्न हार्डवेयर कॉन्फ़िगरेशन पर अच्छी तरह से चलते हैं।हार्डवेयर डिस्प्ले और कॉन्फ़िगरेशन की विविधता। एंड्रॉइड-संगत डिस्प्ले एक डिस्प्ले स्क्रीन है जो एंड्रॉइड डेवलपर्स में वर्णित सभी व्यवहारों और एपीआई को लागू करती है - स्क्रीन संगतता अवलोकन , यह खंड (7.1) और इसके उपखंड, साथ ही अनुभाग 2 में प्रलेखित कोई भी अतिरिक्त डिवाइस-प्रकार विशिष्ट व्यवहार यह सी.डी.डी.एंड्रॉइड-संगत डिस्प्ले पर जहां सभी तृतीय-पक्ष एंड्रॉइड-संगत एप्लिकेशन चल सकते हैं, डिवाइस कार्यान्वयन को इन एपीआई और व्यवहारों को ठीक से लागू करना होगा, जैसा कि इस अनुभाग में बताया गया है।नई आवश्यकताएँ प्रारंभ करें
डिवाइस कार्यान्वयन:
- [सी-0-1] डिफ़ॉल्ट रूप से, तृतीय पक्ष एप्लिकेशन को केवल एंड्रॉइड-संगत डिस्प्ले पर प्रस्तुत करना होगा।
इस अनुभाग में आवश्यकताओं द्वारा संदर्भित इकाइयों को निम्नानुसार परिभाषित किया गया है:
- भौतिक विकर्ण आकार . प्रदर्शन के प्रबुद्ध भाग के दो विरोधी कोनों के बीच इंच में दूरी।
-
डॉट्स प्रति इंच (DPI)घनत्व । एक रैखिक क्षैतिज या 1 के ऊर्ध्वाधर अवधि द्वारा शामिल पिक्सल की संख्या , प्रति इंच (पीपीआई या डीपीआई) के रूप में व्यक्त की गई । जहांDPIPPI और DPI मान सूचीबद्ध हैं, दोनों क्षैतिज और ऊर्ध्वाधर DPI सूचीबद्ध सीमा के भीतर गिरना चाहिए। - आस्पेक्ट अनुपात । स्क्रीन के छोटे आयाम के लिए लंबे आयाम के पिक्सेल का अनुपात। उदाहरण के लिए, 480x854 पिक्सल का प्रदर्शन 854/480 = 1.779, या मोटे तौर पर "16: 9" होगा।
- घनत्व-स्वतंत्र पिक्सेल (डीपी) ।
एकवर्चुअल पिक्सेल यूनिट 160 के160 डीपीआई स्क्रीनस्क्रीन घनत्व के लिए सामान्यीकृत है । कुछ घनत्व डी के लिए, और कई पिक्सेल पी के लिए, घनत्व-स्वतंत्र पिक्सेल डीपी की संख्या, के रूप में गणना की जाती है :पिक्सेल = डीपीएस * (घनत्व/160)डीपी = (160 / डी) * पी ।
7.1.1.1. स्क्रीन का आकार और आकार :
संशोधन देखें
यदि डिवाइस कार्यान्वयन
UI_MODE_TYPE_NORMALSIZE कॉन्फ़िगरेशन में सक्षम स्क्रीन का समर्थन करता है और इन स्क्रीन को प्रस्तुत करने के लिए गोल कोनों के साथएंड्रॉइड-संगतउपयोग भौतिक प्रदर्शन (ओं) को शामिल करता है, तो वे:- ]
- गोल कोनों की त्रिज्या 38 डीपी से कम या बराबर है।
जब 15 डीपी द्वारा 15 डीपी बॉक्स को तार्किक डिस्प्ले के प्रत्येक कोने पर लंगर डाला जाता है, तो प्रत्येक बॉक्स का कम से कम एक पिक्सेल स्क्रीन पर दिखाई देता है।
आयताकार कोनों के साथ डिस्प्ले मोड पर स्विच करने के लिए उपयोगकर्ता खर्च को शामिल करना चाहिए।
नई आवश्यकताएं शुरू करें
यदि डिवाइस कार्यान्वयन केवल
NO_KEYSकीबोर्ड कॉन्फ़िगरेशन के लिए सक्षम हैं, औरUI_MODE_TYPE_NORMALUI मोड कॉन्फ़िगरेशन के लिए समर्थन की रिपोर्ट करने का इरादा रखते हैं, तो वे:- ]
यदि डिवाइस कार्यान्वयन में एक एंड्रॉइड-संगत डिस्प्ले (एस) शामिल है, जो कि फोल्डेबल है, या कई डिस्प्ले पैनल के बीच एक फोल्डिंग काज शामिल है और इस तरह के डिस्प्ले (एस) को थर्ड-पार्टी ऐप्स को रेंडर करने के लिए उपलब्ध है, तो वे: वे:
यदि डिवाइस कार्यान्वयन में एक एंड्रॉइड-संगत डिस्प्ले (एस) शामिल है जो कि फोल्डेबल है, या कई डिस्प्ले पैनल के बीच एक फोल्डिंग काज शामिल है और यदि काज या फोल्ड फुलस्क्रीन एप्लिकेशन विंडो को पार करता है, तो वे:
- ]
यदि डिवाइस कार्यान्वयन में एक या एक से अधिक एंड्रॉइड-संगत प्रदर्शन क्षेत्र शामिल हैं जो फोल्डेबल हैं, या कई एंड्रॉइड-संगत डिस्प्ले पैनल क्षेत्रों के बीच एक तह काज शामिल हैं और ऐसे प्रदर्शन क्षेत्रों को अनुप्रयोगों के लिए उपलब्ध कराते हैं, तो वे: वे:
- [C-४-१] को आगामी प्रलेखन में वर्णित विंडो मैनेजर एक्सटेंशन एपीआई स्तर के सही संस्करण को लागू करना होगा।
7.1.1.2. स्क्रीन पहलू अनुपात : हटा दिया गया
संशोधन देखें
डिवाइस कार्यान्वयन:
-
]DisplayMetricsDENSITY_DEVICE_STABLEहालांकि,हालांकि , डिवाइस प्रारंभिक बूट के बाद सेट (उदाहरण के लिए, प्रदर्शन आकार) द्वारा किए गए डिस्प्ले कॉन्फ़िगरेशन परिवर्तनों के अनुसार एक अलगमनमाना घनत्वDisplayMetrics.densityकी रिपोर्ट कर सकता है।
- डिवाइस कार्यान्वयन को मानक एंड्रॉइड फ्रेमवर्क घनत्व को परिभाषित करना चाहिए जो स्क्रीन के भौतिक घनत्व के संख्यात्मक रूप से सबसे करीब है, जब तक कि तार्किक घनत्व न्यूनतम समर्थित स्क्रीन के नीचे रिपोर्ट किए गए स्क्रीन आकार को धक्का नहीं देता है। यदि मानक एंड्रॉइड फ्रेमवर्क घनत्व जो कि एक स्क्रीन आकार में भौतिक घनत्व के परिणामस्वरूप संख्यात्मक रूप से निकटतम है, जो कि सबसे छोटे समर्थित संगत स्क्रीन आकार (320 डीपी चौड़ाई) से छोटा है, तो डिवाइस कार्यान्वयन को अगले सबसे कम मानक एंड्रॉइड फ्रेमवर्क घनत्व की रिपोर्ट करनी चाहिए।
नई आवश्यकताएं शुरू करें
- मानक एंड्रॉइड फ्रेमवर्क घनत्व को परिभाषित करना चाहिए जो स्क्रीन के भौतिक घनत्व के संख्यात्मक रूप से निकटतम है, या एक मान जो एक हाथ में डिवाइस के समान समकक्ष कोणीय फ़ील्ड-ऑफ-व्यू माप के लिए मैप करेगा।
यदि डिवाइस कार्यान्वयन प्रदान करते हैं
तो डिवाइस के प्रदर्शन आकार को बदलने के लिए एक खर्च होता है, वे :- [C-1-1]
डिस्प्ले साइज़ को स्केल नहीं किया जाना चाहिए, किसी भीडिस्प्ले को 1.5 गुनाघनत्वसे बड़ा नहीं होना चाहिएDENSITY_DEVICE_STABLE -
]DENSITY_DEVICE_STABLE
-
संशोधन देखें
यदि डिवाइस कार्यान्वयन में वल्कन
1.0 या उच्चतरके लिए समर्थन शामिल है, तो वे:]VkPhysicalDeviceandroid:debuggabletruecom.android.graphics.injectLayers.enableसेटtrueके लिए सेट ।
-
VkPhysicalDeviceProtectedMemoryFeaturesऔरVK_EXT_global_priorityसमर्थन करना चाहिए।
- [C-1-13] Android बेसलाइन 2021 प्रोफाइल द्वारा निर्दिष्ट आवश्यकताओं को पूरा करना चाहिए।
VkPhysicalDeviceProtectedMemoryFeatures.protectedMemoryVK_EXT_global_priority[C-SR-6] को HWUI के साथ
SkiaVkउपयोग करने के लिए दृढ़ता से अनुशंसित किया जाता है।
यदि डिवाइस कार्यान्वयन में वल्कन 1.1 के लिए समर्थन शामिल है और यहां वर्णित किसी भी वल्कन फीचर झंडे की घोषणा करते हैं, तो वे:
-
VK_KHR_external_fence_fd
संशोधन देखें
यदि डिवाइस कार्यान्वयन में कई बायोमेट्रिक सेंसर होते हैं, तो वे:
] बहुत सारे असफल प्रयासों के कारण, एक कम बायोमेट्रिक वर्ग के अन्य सभी बायोमेट्रिक्स को भी लॉक करें। टाइम-बाउंड लॉकआउट के मामले में, बायोमेट्रिक सत्यापन के लिए बैकऑफ़ समय समय-बाउंड लॉकआउट में सभी बायोमेट्रिक्स का अधिकतम बैकऑफ़ समय होना चाहिए।
] अंतराल) बहुत सारे असफल प्रयासों के कारण, एक ही बायोमेट्रिक वर्ग के अन्य सभी बायोमेट्रिक्स को भी बंद करने के लिए। टाइम-बाउंड लॉकआउट के मामले में, बायोमेट्रिक सत्यापन के लिए बैकऑफ़ समय को समय-सीमा के लॉकआउट में सभी बायोमेट्रिक्स का अधिकतम बैकऑफ़ समय होने की दृढ़ता से सिफारिश की जाती है।
] कक्षा 3 बायोमेट्रिक्स को समान या निम्न वर्ग के लॉक बायोमेट्रिक के लिए लॉकआउट काउंटर को रीसेट करने की अनुमति दी जा सकती है। कक्षा 2 या कक्षा 1 बायोमेट्रिक्स को किसी भी बायोमेट्रिक्स के लिए रीसेट लॉकआउट ऑपरेशन को पूरा करने की अनुमति नहीं दी जानी चाहिए।
यदि डिवाइस कार्यान्वयन एक बायोमेट्रिक सेंसर को कक्षा 1 (पूर्व में सुविधा ) के रूप में व्यवहार करना चाहते हैं, तो वे:
]
[सी-एसआर -13] को दृढ़ता से एक स्पूफ और इम्पोस्टर स्वीकृति दर 30% से अधिक नहीं प्रेजेंटेशन अटैक इंस्ट्रूमेंट (पीएआई) प्रजातियों से अधिक नहीं है, जैसा कि एंड्रॉइड बायोमेट्रिक्स टेस्ट प्रोटोकॉल द्वारा मापा जाता है।
]
IFace.aidlIFingerprint.aidl
यदि डिवाइस कार्यान्वयन एक बायोमेट्रिक सेंसर को कक्षा 2 (पूर्व में कमजोर ) के रूप में व्यवहार करना चाहते हैं, तो वे:
- [सी-एसआर -15] को दृढ़ता से सिफारिश की जाती है कि वह एक स्पूफ और इम्पोस्टर स्वीकृति दर 20% प्रति प्रस्तुति हमला उपकरण (पीएआई) प्रजातियों से अधिक नहीं है, जैसा कि एंड्रॉइड बायोमेट्रिक्स परीक्षण प्रोटोकॉल द्वारा मापा जाता है।
-
]वर्चुअल मशीन जो धारा 9.17 में आवश्यकताओं को पूरा करती है । - [C-2-4] में सभी पहचान योग्य डेटा एन्क्रिप्टेड और क्रिप्टोग्राफिक रूप से प्रमाणित होना चाहिए, जैसे कि उन्हें अलग-अलग निष्पादन वातावरण के बाहर हासिल नहीं किया जा सकता है, पढ़ा या बदल दिया जा सकता है या कार्यान्वयन दिशानिर्देशों में प्रलेखित के रूप में अलग-थलग निष्पादन वातावरण के लिए एक सुरक्षित चैनल के साथ एक चिप एंड्रॉइड ओपन सोर्स प्रोजेक्ट साइट या हाइपरविजर द्वारा नियंत्रित एक संरक्षित वर्चुअल मशीन पर जो धारा 9.17 में आवश्यकताओं को पूरा करता है ।
- [C-2-5] कैमरा आधारित बायोमेट्रिक्स के लिए, जबकि बायोमेट्रिक आधारित प्रमाणीकरण या नामांकन हो रहा है:
- कैमरे को एक ऐसे मोड में संचालित करना चाहिए जो कैमरा फ्रेम को अलग -थलग निष्पादन वातावरण के बाहर पढ़ने या बदलने से रोकता है या एक सुरक्षित चैनल के साथ अलग -अलग निष्पादन वातावरण या हाइपरविजर द्वारा नियंत्रित एक संरक्षित वर्चुअल मशीन के साथ एक चिप जो धारा 9.17 में आवश्यकताओं को पूरा करता है।
- RGB सिंगल-कैमरा सॉल्यूशंस के लिए, कैमरा फ्रेम को नामांकन के लिए पूर्वावलोकन जैसे संचालन का समर्थन करने के लिए पृथक निष्पादन वातावरण के बाहर पठनीय हो सकता है, लेकिन अभी भी परिवर्तनशील नहीं होना चाहिए।
- ] 9.17 . Android संस्करण 9 या उससे पहले लॉन्च किए गए अपग्रेड डिवाइस को C-2-7 से छूट नहीं दी गई है।
यदि डिवाइस कार्यान्वयन एक बायोमेट्रिक सेंसर को कक्षा 3 (पूर्व में मजबूत ) के रूप में व्यवहार करना चाहते हैं, तो वे:
- [सी-एसआर -16] को एंड्रॉइड बायोमेट्रिक्स टेस्ट प्रोटोकॉल द्वारा मापा गया एक स्पूफ और इम्पोस्टर स्वीकृति दर 7% प्रति प्रस्तुति हमला उपकरण (पीएआई) प्रजातियों से अधिक नहीं है।
7.3.13। IEEE 802.1.15.4 (UWB) :
संशोधन देखें
यदि डिवाइस कार्यान्वयन में 802.1.15.4 के लिए समर्थन शामिल है और कार्यक्षमता को तीसरे पक्ष के आवेदन के लिए उजागर करना है, तो वे:
- [C-1-2] हार्डवेयर फीचर फ्लैग
android.hardware.uwbकी रिपोर्ट करनी चाहिए। - [C-1-3] AOSP कार्यान्वयन में परिभाषित सभी निम्नलिखित कॉन्फ़िगरेशन सेट ( Fira UCI मापदंडों के पूर्व-परिभाषित संयोजनों) का समर्थन करना चाहिए।
-
CONFIG_ID_1: FIRA-परिभाषित यूनिकास्टSTATIC STS DS-TWRरेंजिंग, टाल्डेड मोड, अंतराल 240 एमएस। -
CONFIG_ID_2: FIRA-परिभाषित एक-से-कईSTATIC STS DS-TWRरेंजिंग, आस्थगित मोड, अंतराल 200 एमएस। विशिष्ट उपयोग का मामला: स्मार्ट फोन कई स्मार्ट उपकरणों के साथ बातचीत करता है। -
CONFIG_ID_3: कोण-ऑफ-आगमन (AOA) डेटा को छोड़करCONFIG_ID_1के समान नहीं है। -
CONFIG_ID_4: p-sts सुरक्षा मोड को छोड़करCONFIG_ID_1के समान ही सक्षम है। -
CONFIG_ID_5: P-STS सुरक्षा मोड को छोड़करCONFIG_ID_2के समान ही सक्षम है। -
CONFIG_ID_6: p-sts सुरक्षा मोड को छोड़करCONFIG_ID_3के समान ही सक्षम है। -
CONFIG_ID_7: P-STS व्यक्तिगत कंट्रोल की कुंजी मोड को छोड़करCONFIG_ID_2के समान ही सक्षम है।
-
- [C-1-4] उपयोगकर्ता को UWB रेडियो को/बंद राज्य को टॉगल करने की अनुमति देने के लिए एक उपयोगकर्ता खर्च प्रदान करना चाहिए।
-
UWB_RANGINGNEARBY_DEVICES
FIRA , CCC और CSA सहित मानक संगठनों द्वारा परिभाषित प्रासंगिक अनुरूपता और प्रमाणन परीक्षणों को पारित करना 802.1.15.4 कार्यों को सही ढंग से सुनिश्चित करने में मदद करता है।
- [C-1-2] हार्डवेयर फीचर फ्लैग
संशोधन देखें
एंड्रॉइड एपीआई द्वारा उपयोग किए जाने वाले "टेलीफोनी" और यह दस्तावेज़ विशेष रूप से वॉयस कॉल रखने और एसएमएस संदेश भेजने , या मोबाइल (जैसे जीएसएम, सीडीएमए, एलटीई, एनआर) जीएसएम या सीडीएमए नेटवर्क के माध्यम से मोबाइल डेटा स्थापित करने से संबंधित हार्डवेयर को संदर्भित करता है। "टेलीफोनी" का समर्थन करने वाला एक डिवाइस उत्पाद को फिट करने के रूप में कुछ या सभी कॉल, मैसेजिंग और डेटा सेवाओं की पेशकश करने के लिए चुन सकता है।
एक GSM या CDMA नेटवर्क के माध्यम से। हालांकि इन वॉयस कॉल को पैकेट-स्विच किया जा सकता है या नहीं, वे किसी भी डेटा कनेक्टिविटी से स्वतंत्र माना जाने वाले एंड्रॉइड के प्रयोजनों के लिए हैं जिसे उसी नेटवर्क का उपयोग करके लागू किया जा सकता है। दूसरे शब्दों में, एंड्रॉइड "टेलीफोनी" कार्यक्षमता और एपीआई विशेष रूप से वॉयस कॉल और एसएमएस को संदर्भित करते हैं। उदाहरण के लिए, डिवाइस कार्यान्वयन जो कॉल नहीं कर सकते हैं या एसएमएस संदेश भेज सकते हैं, उन्हें टेलीफोनी डिवाइस नहीं माना जाता है, भले ही वे डेटा कनेक्टिविटी के लिए सेलुलर नेटवर्क का उपयोग करें।7.4.2. IEEE 802.11 (वाई-फाई) :
संशोधन देखें
यदि डिवाइस कार्यान्वयन में 802.11 के लिए समर्थन शामिल है और कार्यक्षमता को तीसरे पक्ष के एप्लिकेशन के लिए उजागर करना है, तो वे:
- ] इन पैकेटों को फ़िल्टर करना लक्ष्य बाजार पर लागू नियामक आवश्यकताओं द्वारा आवश्यक बिजली की खपत सीमाओं के भीतर रहने के लिए आवश्यक है।
एंड्रॉइड टेलीविजन डिवाइस कार्यान्वयन के लिए, जब स्टैंडबाय पावर राज्यों में भी।
- ] इन पैकेटों को फ़िल्टर करना लक्ष्य बाजार पर लागू नियामक आवश्यकताओं द्वारा आवश्यक बिजली की खपत सीमाओं के भीतर रहने के लिए आवश्यक है।
संशोधन देखें
यदि डिवाइस कार्यान्वयन feather_bluetooth_le की घोषणा करते हैं, तो वे:
-
ADVERTISE_TX_POWER_HIGHएक ही दिशा का सामना करने वाली स्क्रीन के साथ 'समानांतर विमानों' पर। - [C-SR-3] को TX ऑफसेट के लिए मापने और क्षतिपूर्ति करने के लिए दृढ़ता से सिफारिश की जाती है ताकि यह सुनिश्चित हो सके कि 1 मीटर की दूरी पर तैनात एक संदर्भ उपकरण से स्कैनिंग और
ADVERTISE_TX_POWER_HIGHपर प्रेषित करने वाले संदर्भ उपकरण से स्कैनिंग करते समय -60dbm +/- 10 db है, जहां डिवाइस उन्मुख होते हैं। जैसे कि वे एक ही दिशा का सामना करने वाली स्क्रीन के साथ 'समानांतर विमानों' पर हैं।
-
ADVERTISE_TX_POWER_HIGH -
ADVERTISE_TX_POWER_HIGH
यदि डिवाइस कार्यान्वयन ब्लूटूथ संस्करण 5.0 का समर्थन करते हैं, तो वे:
- [C-SR-4] के लिए समर्थन प्रदान करने के लिए दृढ़ता से अनुशंसित हैं:
- ले 2एम पीएचवाई
- ले कोडेक फाई
- ले विज्ञापन विस्तार
- आवधिक विज्ञापन
- कम से कम 10 विज्ञापन सेट
- कम से कम 8 ले समवर्ती कनेक्शन। प्रत्येक कनेक्शन या तो कनेक्शन टोपोलॉजी भूमिकाओं में हो सकता है।
- ले लिंक लेयर गोपनीयता
- कम से कम 8 प्रविष्टियों का एक "संकल्प सूची" आकार
-
संशोधन देखें
- [C-1-7] यह सुनिश्चित करना चाहिए कि संदर्भ उपकरण से 1 मीटर पर दूरी माप का माध्य [0.75m, 1.25m] के भीतर है, जहां DUT के शीर्ष किनारे से जमीनी सत्य दूरी को मापा जाता है।
आयोजित चेहरा और 45 डिग्री झुका।
- [C-1-7] यह सुनिश्चित करना चाहिए कि संदर्भ उपकरण से 1 मीटर पर दूरी माप का माध्य [0.75m, 1.25m] के भीतर है, जहां DUT के शीर्ष किनारे से जमीनी सत्य दूरी को मापा जाता है।
संशोधन देखें
एक रियर-फेसिंग कैमरा डिस्प्ले के सामने डिवाइस के किनारे स्थित एक कैमरा है; यही है, यह एक पारंपरिक कैमरे की तरह, डिवाइस के दूर की तरफ दृश्य छवियां है।
एक रियर-फेसिंग कैमरा एक विश्व-सामना करने वाला कैमरा है जो एक पारंपरिक कैमरे की तरह डिवाइस के दूर की तरफ दृश्य दृश्य देता है; हैंडहेल्ड डिवाइस पर, यह डिस्प्ले के सामने डिवाइस के किनारे स्थित एक कैमरा है।
7.5.2. सामने की ओर मुख किया हुआ कैमरा :
संशोधन देखें
एक फ्रंट-फेसिंग कैमरा डिवाइस के एक ही तरफ स्थित एक कैमरा है जो डिस्प्ले के रूप में है; यही है, एक कैमरा आमतौर पर उपयोगकर्ता को छवि बनाने के लिए उपयोग किया जाता है, जैसे कि वीडियो कॉन्फ्रेंसिंग और इसी तरह के अनुप्रयोगों के लिए।
एक फ्रंट-फेसिंग कैमरा एक उपयोगकर्ता-सामना करने वाला कैमरा है जो आमतौर पर उपयोगकर्ता को छवि के लिए उपयोग किया जाता है, जैसे कि वीडियो कॉन्फ्रेंसिंग और इसी तरह के अनुप्रयोगों के लिए; हैंडहेल्ड डिवाइस पर, यह एक कैमरा है जो डिवाइस के एक ही तरफ डिस्प्ले के रूप में स्थित है।
संशोधन देखें
एक बाहरी कैमरा एक कैमरा है जिसे किसी भी समय डिवाइस कार्यान्वयन से शारीरिक रूप से संलग्न या अलग किया जा सकता है और किसी भी दिशा का सामना कर सकता है; जैसे कि USB कैमरा।
संशोधन देखें
डिवाइस कार्यान्वयन को सभी उपलब्ध कैमरों के लिए कैमरा से संबंधित एपीआई के लिए निम्नलिखित व्यवहारों को लागू करना होगा। डिवाइस कार्यान्वयन:
- ]
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERAभौतिक उप-डिवाइस के रूप में।
- ]
संशोधन देखें
निम्नलिखित सभी मानदंडों को पूरा करने वाले उपकरण ऊपर की आवश्यकता से मुक्त हैं:
- डिवाइस कार्यान्वयन जो उपयोगकर्ता द्वारा मोटर वाहन उपकरणों जैसे घुमाए जाने में सक्षम नहीं हैं।
संशोधन देखें
हाथ से पकड़े जाने या पहने जाने वाले उपकरणों में एक सामान्य उद्देश्य हैप्टिक एक्ट्यूएटर शामिल हो सकता है, जो रिंगटोन, अलार्म, सूचनाओं के साथ-साथ सामान्य टच फीडबैक के माध्यम से ध्यान आकर्षित करने सहित प्रयोजनों के लिए अनुप्रयोगों के लिए उपलब्ध है।
यदि डिवाइस कार्यान्वयन में इस तरह के एक सामान्य उद्देश्य हैप्टिक एक्ट्यूएटर शामिल नहीं है, तो वे:
- [7.10/c]
Vibrator.hasVibrator()के लिए गलत लौटना चाहिए।
यदि डिवाइस कार्यान्वयन में कम से कम एक सामान्य उद्देश्य हैप्टिक एक्ट्यूएटर शामिल है, तो वे:
- [C-1-1]
Vibrator.hasVibrator()के लिए सही लौटना चाहिए। - एक सनकी घूर्णन द्रव्यमान (ERM) हैप्टिक एक्ट्यूएटर (वाइब्रेटर) का उपयोग नहीं करना चाहिए।
-
android.view.HapticFeedbackConstantsमें स्पष्ट हैप्टिक्स के लिए सभी सार्वजनिक स्थिरांक को लागू करना चाहिए (CLOCK_TICK,CONTEXT_CLICK,KEYBOARD_PRESS,KEYBOARD_RELEASE,KEYBOARD_TAP,LONG_PRESS,TEXT_HANDLE_MOVE,VIRTUAL_KEY, virtuary_key,VIRTUAL_KEY_RELEASE,CONFIRM,REJECT,GESTURE_START)GESTURE_END -
android.os.VibrationEffectमें स्पष्ट हैप्टिक्स के लिए सभी सार्वजनिक स्थिरांक को लागू करना चाहिए (EFFECT_TICK,EFFECT_CLICK,EFFECT_HEAVY_CLICKऔरEFFECT_DOUBLE_CLICK) और सभी व्यवहार्य सार्वजनिकPRIMITIVE_*android.os.VibrationEffect.Compositionमें समृद्ध haptics के लिए स्थिरांक (CLICK,TICK, टिक,LOW_TICK, कम करें।QUICK_FALL,QUICK_RISE,SLOW_RISE,SPIN,THUD)। इनमें से कुछ आदिम, जैसे किLOW_TICKऔरSPINकेवल तभी संभव हो सकते हैं जब वाइब्रेटर अपेक्षाकृत कम आवृत्तियों का समर्थन कर सकता है। -
android.view.HapticFeedbackConstantsमें सार्वजनिक स्थिरांक की मैपिंग के लिए मार्गदर्शन का पालन करना चाहिए, जो कि अनुशंसितandroid.os.VibrationEffectस्थिरांक के लिए, इसी आयाम संबंधों के साथ है। - इन लिंक्ड हैप्टिक कॉन्स्टेंट मैपिंग का उपयोग करना चाहिए।
-
createOneShot()औरcreateWaveform()API के लिए गुणवत्ता मूल्यांकन का पालन करना चाहिए। - यह सत्यापित करना चाहिए कि सार्वजनिक
android.os.Vibrator.hasAmplitudeControl()एपीआई का परिणाम सही ढंग से उनकी वाइब्रेटर की क्षमताओं को दर्शाता है। -
android.os.Vibrator.hasAmplitudeControl()चलाकर आयाम स्केलेबिलिटी के लिए क्षमताओं को सत्यापित करना चाहिए।
यदि डिवाइस कार्यान्वयन हैप्टिक कॉन्स्टेंट मैपिंग का पालन करते हैं, तो वे:
-
android.os.Vibrator.areAllEffectsSupported()औरandroid.os.Vibrator.arePrimitivesSupported()APIs को चलाकर कार्यान्वयन की स्थिति को सत्यापित करना चाहिए। - हैप्टिक स्थिरांक के लिए एक गुणवत्ता मूल्यांकन करना चाहिए।
- यदि स्थिरांक के लिए कार्यान्वयन मार्गदर्शन में वर्णित के रूप में असमर्थित आदिमों के लिए फ़ॉलबैक कॉन्फ़िगरेशन की आवश्यकता हो तो सत्यापित और अद्यतन करना चाहिए।
- यहाँ वर्णित विफलता के जोखिम को कम करने के लिए गिरावट का समर्थन प्रदान करना चाहिए।
डिवाइस-विशिष्ट आवश्यकताओं के लिए धारा 2.2.1 देखें।
- [7.10/c]
9. सुरक्षा मॉडल संगतता
संशोधन देखें
डिवाइस कार्यान्वयन:
- [C-0-4] दोनों उपयोगकर्ता इंटरफेस का केवल एक और एक कार्यान्वयन होना चाहिए।
यदि डिवाइस कार्यान्वयन किसी भी पैकेज को स्थापित करें जो सिस्टम यूआई इंटेलिजेंस , सिस्टम एम्बिएंट ऑडियो इंटेलिजेंस , सिस्टम ऑडियो इंटेलिजेंस , सिस्टम नोटिफिकेशन इंटेलिजेंस , सिस्टम टेक्स्ट इंटेलिजेंस , या सिस्टम विजुअल इंटेलिजेंस रोल्स, द पैकेज में से किसी को भी रखता है:
-
]
- [C-4-2] में Android.permission.internet की अनुमति नहीं होनी चाहिए। यह धारा 9.8.6 में सूचीबद्ध दृढ़ता से अनुशंसित की तुलना में सख्त है।
- ] यह धारा 9.8.6 में सूचीबद्ध दृढ़ता से अनुशंसित की तुलना में सख्त है।
यदि डिवाइस कार्यान्वयन में वे
VoiceInteractionServiceका समर्थन करने के लिए एक डिफ़ॉल्ट एप्लिकेशन शामिल करते हैं:- [C-5-1] उस एप्लिकेशन के लिए डिफ़ॉल्ट के रूप में
ACCESS_FINE_LOCATIONअनुदान नहीं देना चाहिए।
संशोधन देखें
यदि डिवाइस कार्यान्वयन ऊपर चर्चा की गई अतिरिक्त उपयोगकर्ता प्रोफ़ाइल बनाते हैं, तो वे:
- [C-4-5] जब उपयोगकर्ताओं को आइकन प्रस्तुत किए जाते हैं तो दोहरी उदाहरण एप्लिकेशन आइकन को नेत्रहीन रूप से अलग करना चाहिए।
- [C-4-6] पूरे क्लोन प्रोफाइल डेटा को हटाने के लिए एक उपयोगकर्ता-व्यय प्रदान करना चाहिए।
- ]
- अंतिम क्लोन ऐप को हटाए जाने पर उपयोगकर्ता को संपूर्ण क्लोन प्रोफ़ाइल डेटा को हटाने के लिए प्रेरित करना चाहिए।
- ]
- [C-४- ९] को निजी ऐप डेटा निर्देशिकाओं और उनकी सामग्री को हटा देना चाहिए, जब उपयोगकर्ता अनइंस्टॉल के दौरान डेटा को हटाने का विकल्प चुनता है।
]
-
Intent.ACTION_VIEW -
Intent.ACTION_SENDTO -
Intent.ACTION_SEND -
Intent.ACTION_EDIT -
Intent.ACTION_INSERT -
Intent.ACTION_INSERT_OR_EDIT -
Intent.ACTION_SEND_MULTIPLE -
Intent.ACTION_PICK -
Intent.ACTION_GET_CONTENT -
MediaStore.ACTION_IMAGE_CAPTURE -
MediaStore.ACTION_VIDEO_CAPTURE
-
]
[C-4-3] केवल निम्न इरादों के माध्यम से इस अतिरिक्त प्रोफ़ाइल से संपर्क लिखने की अनुमति देनी चाहिए:
[C-4-4] इस अतिरिक्त उपयोगकर्ता प्रोफ़ाइल में चलने वाले अनुप्रयोगों के लिए चलने वाले संपर्क सिंक नहीं होना चाहिए।
- [C-४-१४] इस अतिरिक्त प्रोफ़ाइल में चलने वाले अनुप्रयोगों के लिए अलग-अलग अनुमति और भंडारण प्रबंधन होना चाहिए
- ]
संशोधन देखें
एक मेमोरी सेफ्टी तकनीक एक ऐसी तकनीक है जो कम से कम एक उच्च (> 90%) के साथ बग्स के निम्नलिखित वर्गों को कम करती है, जो कि
android:memtagModeमैनिफेस्ट विकल्प:- ढेर बफ़र अतिप्रवाह
- मुफ़्त के बाद उपयोग करें
- डबल फ्री
- वाइल्ड फ्री (एक गैर-मैलोक पॉइंटर से मुक्त)
डिवाइस कार्यान्वयन:
-
ro.arm64.memtag.bootctl_supported
यदि डिवाइस कार्यान्वयन सिस्टम प्रॉपर्टी
ro.arm64.memtag.bootctl_supportedको सही सेट करते हैं, तो वे: वे:arm64.memtag.bootctl-
memtag: एक मेमोरी सुरक्षा तकनीक जैसा कि ऊपर परिभाषित किया गया है वह सक्षम है -
memtag-once: ऊपर परिभाषित एक मेमोरी सुरक्षा तकनीक क्षणिक रूप से सक्षम है, और स्वचालित रूप से अक्षम है, अगला रिबूट -
memtag-off: ऊपर परिभाषित एक मेमोरी सुरक्षा तकनीक अक्षम है
-
[C-3-2] शेल उपयोगकर्ता को
arm64.memtag.bootctlसेट करने की अनुमति देनी चाहिए।arm64.memtag.bootctlarm64.memtag.bootctl] एक संगत बूटलोडर के साथ, एंड्रॉइड ओपन सोर्स प्रोजेक्ट एमटीई बूटलोडर प्रोटोकॉल के माध्यम से उपरोक्त आवश्यकताओं को पूरा करता है।
- [सी-एसआर -17] को सुरक्षा सेटिंग्स मेनू में एक सेटिंग दिखाने के लिए दृढ़ता से अनुशंसित किया जाता है जो उपयोगकर्ता को
memtagसक्षम करने की अनुमति देता है।
संशोधन देखें
डिवाइस कार्यान्वयन:
- [C-०-२] एक उपयोगकर्ता चेतावनी प्रदर्शित करनी चाहिए और स्पष्ट उपयोगकर्ता सहमति प्राप्त करनी चाहिए , जिससे उपयोगकर्ता की स्क्रीन पर प्रदर्शित होने वाली किसी भी संवेदनशील जानकारी को कैप्चर किया जा सकता है,
जिसमें बिल्कुल वैसा ही संदेश शामिल हैजब भीप्रत्येक और हर बार एक सत्र को कैप्चर करने के लिए एक सत्र शामिल होता है। स्क्रीनकास्टिंग या स्क्रीन रिकॉर्डिंग कोMediaProjection.createVirtualDisplay(),VirtualDeviceManager.createVirtualDisplay(), या मालिकाना API के माध्यम से शुरू किया गयाहै।उपयोगकर्ता सहमति के भविष्य के प्रदर्शन को अक्षम करने के लिए उपयोगकर्ताओं को एक खर्च प्रदान नहीं करना चाहिए।
[C-SR-1] को एक उपयोगकर्ता चेतावनी प्रदर्शित करने के लिए दृढ़ता से अनुशंसित किया जाता है जो कि AOSP में लागू होने वाला एक ही संदेश है, लेकिन जब तक संदेश स्पष्ट रूप से उपयोगकर्ता को चेतावनी देता है कि उपयोगकर्ता की स्क्रीन पर कोई भी संवेदनशील जानकारी कैप्चर की जाती है, तब तक इसे बदल दिया जा सकता है।
associate()android.app.role.COMPANION_DEVICE_APP_STREAMINGयाandroid.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMINGडिवाइस प्रोफ़ाइल।
- [C-०-२] एक उपयोगकर्ता चेतावनी प्रदर्शित करनी चाहिए और स्पष्ट उपयोगकर्ता सहमति प्राप्त करनी चाहिए , जिससे उपयोगकर्ता की स्क्रीन पर प्रदर्शित होने वाली किसी भी संवेदनशील जानकारी को कैप्चर किया जा सकता है,
9.8.6. ओएस-स्तर और परिवेश डेटा : इस खंड का नाम बदलकर कंटेंट कैप्चर और ऐप सर्च से ओएस-लेवल और एंबिएंट डेटा तक रखा गया था।
संशोधन देखें
Android, सिस्टम APIS
ContentCaptureService,AugmentedAutofillService,AppSearchGlobalManager.query, या अन्य मालिकाना साधनों के माध्यम सेअनुप्रयोगों और उपयोगकर्तासंवेदनशील डेटा के बीच निम्नलिखित एप्लिकेशन डेटा इंटरैक्शन को कैप्चर करने के लिए डिवाइस कार्यान्वयन के लिए एक तंत्र का समर्थन करता है:- किसी भी स्क्रीन या अन्य डेटा को सिस्टम के लिए
AugmentedAutofillServiceके माध्यम से भेजा जाता है। -
Content Captureएपीआई के माध्यम से कोई भी स्क्रीन या अन्य डेटा सुलभ। - कोई भी स्क्रीन या अन्य डेटा
FieldClassificationServiceएपीआई के माध्यम से सुलभ - कोई भी एप्लिकेशन डेटा
AppSearchManagerAPI के माध्यम से सिस्टम को पारित करता है औरAppSearchGlobalManager.queryके माध्यम से सुलभ है।
- कोई भी अन्य घटना जो एक एप्लिकेशन
Content CaptureAPI याAppSearchManagerAPI के माध्यम से सिस्टम को प्रदान करती है, एक समान रूप से सक्षम Android और मालिकाना API।
- भाषण पहचानने वाले कार्यान्वयन द्वारा
SpeechRecognizer#onDeviceSpeechRecognizer()का उपयोग करने के परिणामस्वरूप ऑडियो डेटा प्राप्त किया गया। -
AudioRecord,SoundTriggerया अन्य ऑडियो एपीआई के माध्यम से पृष्ठभूमि (लगातार) में प्राप्त ऑडियो डेटा, और उपयोगकर्ता-दृश्यमान संकेतक के परिणामस्वरूप नहीं - कैमरामैनर या अन्य कैमरा एपीआई के माध्यम से पृष्ठभूमि (लगातार) में प्राप्त कैमरा डेटा, और उपयोगकर्ता-दृश्य संकेतक के परिणामस्वरूप नहीं
यदि डिवाइस कार्यान्वयन ऊपर दिए गए किसी भी डेटा को कैप्चर करते हैं, तो वे:
[C-1-3] को केवल इस तरह के सभी डेटा
और लॉगऑफ डिवाइस को एक गोपनीयता-संरक्षण तंत्र का उपयोग करके भेजना होगा , जिसमें डेटा साझा होने पर हर बार स्पष्ट उपयोगकर्ता सहमति को छोड़कर । गोपनीयता-संरक्षण तंत्र को "उन लोगों के रूप में परिभाषित किया गया है जो केवल एकत्रीकरण में विश्लेषण की अनुमति देते हैं और लॉग इवेंट्स या व्यक्तिगत उपयोगकर्ताओं के लिए व्युत्पन्न परिणामों के मिलान को रोकते हैं", किसी भी प्रति-उपयोगकर्ता डेटा को आत्मनिरीक्षण योग्य होने से रोकने के लिए (उदाहरण के लिए, एक अंतर गोपनीयता तकनीक का उपयोग करके कार्यान्वित किया जाता है जैसे किRAPPOR)।[C-1-5] को ऐसे डेटा को अन्य OS घटकों के साथ साझा नहीं करना चाहिए जो वर्तमान खंड (9.8.6
सामग्री कैप्चरOS- स्तर और परिवेश डेटा ) में उल्लिखित आवश्यकताओं का पालन नहीं करते हैं, स्पष्ट उपयोगकर्ता सहमति को छोड़कर हर बार यह हर बार होता है साझा किया गया. जब तक इस तरह की कार्यक्षमता Android SDK API (AmbientContext,HotwordDetectionService) के रूप में नहीं बनाई जाती है।ContentCaptureService यदि उपयोगकर्ता डेटा को मिटाने का विकल्प चुनता है, तो सभी एकत्र किए गए ऐतिहासिक डेटा को हटाना होगा।
- ] और / या एक सैंडबॉक्स कार्यान्वयन में प्रदर्शन किया जाए (9.8.15 सैंडबॉक्स्ड एपीआई कार्यान्वयन देखें)।
Android,
SpeechRecognizer#onDeviceSpeechRecognizer()नेटवर्क को शामिल किए बिना, डिवाइस पर भाषण मान्यता करने की क्षमता प्रदान करता है। ऑन-डिवाइस स्पीचरेकॉन्ज़र के किसी भी कार्यान्वयन को इस खंड में उल्लिखित नीतियों का पालन करना चाहिए।- किसी भी स्क्रीन या अन्य डेटा को सिस्टम के लिए
9.8.10. कनेक्टिविटी बग रिपोर्ट :
संशोधन देखें
यदि डिवाइस कार्यान्वयन
android.hardware.telephonyफ़ीचर ध्वज की घोषणा करते हैं, तो वे:-
BUGREPORT_MODE_TELEPHONY-
SubscriptionManagerService
-
-
9.8.14. क्रेडेंशियल मैनेजर : हटा दिया गया
9.8.15. सैंडबॉक्स एपीआई कार्यान्वयन : नया खंड
संशोधन देखें
एंड्रॉइड, प्रतिनिधि एपीआई के एक सेट के माध्यम से सुरक्षित ओएस-स्तर और परिवेश डेटा को संसाधित करने के लिए एक तंत्र प्रदान करता है। इस तरह के प्रसंस्करण को विशेषाधिकार प्राप्त पहुंच और कम संचार क्षमताओं के साथ एक प्रीइंस्टॉल्ड एपीके को सौंप दिया जा सकता है, जिसे सैंडबॉक्स एपीआई कार्यान्वयन के रूप में जाना जाता है।
कोई भी सैंडबॉक्स एपीआई कार्यान्वयन:
- [C-0-1] इंटरनेट की अनुमति का अनुरोध नहीं करना चाहिए।
- ] गोपनीयता-संरक्षण तंत्र को "उन लोगों के रूप में परिभाषित किया गया है जो केवल एकत्रीकरण में विश्लेषण की अनुमति देते हैं और लॉग इवेंट्स या व्यक्तिगत उपयोगकर्ताओं के लिए व्युत्पन्न परिणामों के मिलान को रोकते हैं", किसी भी प्रति-उपयोगकर्ता डेटा को आत्मनिरीक्षण योग्य होने से रोकने के लिए (जैसे, एक अंतर गोपनीयता तकनीक का उपयोग करके कार्यान्वित किया जाता है जैसे कि रैपोर )।
- ]
- टेलीफोनी, संपर्क, सिस्टम यूआई और मीडिया
- [C-0-4] उपयोगकर्ताओं को उपयोगकर्ता-इंस्टालेबल एप्लिकेशन या सेवा के साथ सेवाओं को बदलने की अनुमति नहीं देनी चाहिए
- ] जब तक प्रतिस्थापन क्षमता AOSP (जैसे डिजिटल सहायक ऐप्स के लिए) में नहीं बनाई जाती है।
- ] जब तक कि ऐसी कैप्चर क्षमता Android SDK API के साथ लागू नहीं की जाती है।
- [C-0-7] सेवाओं को अक्षम करने के लिए उपयोगकर्ता खर्च प्रदान करना चाहिए।
- ] अनुमति ।
9.8.16. निरंतर ऑडियो और कैमरा डेटा : नया खंड
संशोधन देखें
9.8.2 रिकॉर्डिंग, 9.8.6 ओएस-लेवल और एंबिएंट डेटा, और 9.8.15 सैंडबॉक्स्ड एपीआई कार्यान्वयन में उल्लिखित आवश्यकताओं के अलावा, कार्यान्वयन जो ऑडियरकॉर्ड, साउंडट्रिगर या अन्य ऑडियो एपीआई के माध्यम से पृष्ठभूमि (लगातार) में प्राप्त ऑडियो डेटा का उपयोग करते हैं या कैमरामैनर या अन्य कैमरा एपीआई के माध्यम से पृष्ठभूमि (लगातार) में प्राप्त कैमरा डेटा:
- ]
- यह एक्सेस एक सैंडबॉक्स कार्यान्वयन में किया जाता है (देखें 9.8.15 सैंडबॉक्स्ड एपीआई कार्यान्वयन), एक पैकेज के माध्यम से निम्नलिखित भूमिकाओं में से एक या अधिक होल्ड , या सिस्टम विजुअल इंटेलिजेंस ।
- The access is performed through a sandbox, implemented and enforced via mechanisms in AOSP (
HotwordDetectionService,WearableSensingService,VisualQueryDetector). - Audio access is performed for assistive purposes by the Digital Assistant application, supplying
SOURCE_HOTWORDas an audio source. - The access is performed by the system and implemented with open-source code.
- [C-SR-1] Is STRONGLY RECOMMENDED to require user consent for every functionality utilizing such data, and be disabled by default.
- [C-SR-2] STRONGLY RECOMMENDED to apply the same treatment (ie follow the restrictions outlined in 9.8.2 Recording, 9.8.6 OS-level and ambient data, 9.8.15 Sandboxed API implementations, and 9.8.16 Continuous Audio and Camera data) to Camera data coming from a remote wearable device.
If the Camera data is supplied from a remote wearable device and accessed in an unencrypted form outside Android OS, sandboxed implementation or a sandboxed functionality built by
WearableSensingManager, then they:- [C-1-1] MUST indicate to the remote wearable device to display an additional indicator there.
If devices provide capability to engage with a Digital Assistant Application without the assigned keyword (either handling generic user queries, or analyzing user presence through camera):
- [C-2-1] MUST ensure such implementation is provided by a package holding the
android.app.role.ASSISTANTrole. - [C-2-2] MUST ensure such implementation utilizes
HotwordDetectionServiceand/orVisualQueryDetectionServiceAndroid APIs.
- ]
9.8.17. Telemetry : New section
See revision
Android stores system and app logs using StatsLog APIs. These logs are managed via StatsManager APIs which can be used by privileged system applications.
StatsManager also provides a way to collect data categorized as privacy sensitive from devices with a privacy preserving mechanism. In particular,
StatsManager::queryAPI provides the ability to query restricted metric categories defined in StatsLog .Any implementation querying and collecting restricted metrics from StatsManager:
- [C-0-1] MUST be the sole application/implementation on the device and hold the
READ_RESTRICTED_STATSpermission. - [C-0-2] MUST only send telemetry data and the log of the device using a privacy-preserving mechanism. The privacy-preserving mechanism is defined as "those which allow only analysis in aggregate and prevent matching of logged events or derived outcomes to individual users", to prevent any per-user data being introspectable (eg, implemented using a differential privacy technology such as RAPPOR ).
- [C-0-3] MUST NOT associate such data with any user identity (such as Account ) on the device.
- [C-0-4] MUST NOT share such data with other OS components that don't follow requirements outlined in the current section (9.8.17 Privacy-preserving Telemetry).
- [C-0-5] MUST provide a user affordance to enable/disable privacy-preserving telemetry collection, use, and sharing.
- [C-0-6] MUST provide user affordance to erase such data that the implementation collects if the data is stored in any form on the device. If the user chose to erase the data, MUST remove all data currently stored on the device.
- [C-0-7] MUST disclose underlying privacy-preserving protocol implementation in an open source repository.
- [C-0-8 ]MUST enforce data egress policies in this section to gate collection of data in restricted metric categories defined in StatsLog .
- [C-0-1] MUST be the sole application/implementation on the device and hold the
See revision
Device implementationsIf device implementations have the ability to verify file content on the per-page basis, then they :
[
C-0-3C-2-1 ] support cryptographically verifying file contentagainst a trusted keywithout reading the whole file.[
C-0-4C-2-2 ] MUST NOT allow the read requests on a protected file to succeed when the read contentdo not verify against a trusted keyis not verified per [C-2-1] above .
- [C-2-4] MUST return file checksum in O(1) for enabled files.
See revision
The Android Keystore System allows app developers to store cryptographic keys in a container and use them in cryptographic operations through the KeyChain API or the Keystore API . डिवाइस कार्यान्वयन:
- [C-0-3] MUST limit the number of failed primary authentication attempts.
- [C-SR-2] Are STRONGLY RECOMMENDED to implement an upper bound of 20 failed primary authentication attempts and if users consent and opt-in the feature, perform a "Factory Data Reset" after exceeding the limit of failed primary authentication attempts.
If device implementations add or modify the authentication methods to unlock the lock screen if based on a known secret and use a new authentication method to be treated as a secure way to lock the screen, then:
- [C-SR-3] A PIN is STRONGLY RECOMMENDED to have at least 6 digits, or equivalently a 20-bit entropy.
- [C-2-1] A PIN of a length less than 6 digits MUST NOT allow automatic entry without user interaction to avoid revealing the PIN length.
9.11.1. Secure Lock Screen, Authentication and Virtual Devices :
See revision
डिवाइस कार्यान्वयन:
- [C-0-1] MUST limit the number of failed primary authentication attempts.
- [C-SR-5] Are STRONGLY RECOMMENDED to implement an upper bound of 20 failed primary authentication attempts and if users consent and opt-in the feature, perform a "Factory Data Reset" after exceeding the limit of failed primary authentication attempts.
If device implementations set a numerical PIN as the recommended primary authentication method, then:
- [C-SR-6] A PIN is STRONGLY RECOMMENDED to have at least 6 digits, or equivalently a 20-bit entropy.
- [C-SR-7] A PIN of a length less than 6 digits is STRONGLY RECOMMENDED NOT to allow automatic entry without user interaction to avoid revealing the PIN length.
यदि डिवाइस कार्यान्वयन में एक सुरक्षित लॉक स्क्रीन है और इसमें एक या अधिक ट्रस्ट एजेंट शामिल हैं, जो
TrustAgentServiceसिस्टम एपीआई लागू करता है, तो वे:[C-7-8] The user MUST be challenged for one of the recommended primary authentication (eg: PIN, pattern, password) methods at least once every 72 hours or less unless the safety of the user (eg driver distraction) is of चिंता।If device implementations allow applications to create secondary virtual displays and support associated input events such as via VirtualDeviceManager and the displays are not marked with VIRTUAL_DISPLAY_FLAG_SECURE, they:
[C-13-10] MUST disable installation of apps initiated from virtual devices.9.17. Android Virtualization Framework :
See revision
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*), the Android host:- [C-1-1] MUST support all the APIs defined by the
android.system.virtualmachinepackage. - [C-1-2] MUST NOT modify the Android SELinux and permission model for the management of Protected Virtual Machines (pVM) .
- [C-1-3] MUST NOT modify, omit, or replace the neverallow rules present within the system/sepolicy provided in the upstream Android Open Source Project (AOSP) and the policy MUST compile with all neverallow rules present.
- [C-1-4] MUST only allow platform signed code & privileged apps
MUST NOT allow untrusted code (eg 3p apps)to create and run aProtected Virtual MachinepVM . Note: This might change in future Android releases.
- [C-1-5] MUST NOT allow a
Protected Virtual MachinepVM to execute code that is not part of the factory image or their updates.Anything that is not covered by Android Verified Boot (eg files downloaded from the Internet or sideloaded) MUST NOT be allowed to be run in a Protected Virtual Machine.
- [C-1-5] MUST only allow a non-debuggable pVM to execute code from the factory image or their platform updates which also includes any updates to privileged apps.
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*), then anyProtected Virtual MachinepVM instance:- [C-2-1] MUST be able to run all operating systems available in the virtualization APEX in a
Protected Virtual MachinepVM . - [C-2-2] MUST NOT allow a
Protected Virtual MachinepVM to run an operating system that is not signed by the device implementor or OS vendor. - [C-2-3] MUST NOT allow a
Protected Virtual MachinepVM to execute data as code (eg SELinux neverallow execmem).
- [C-2-4] MUST NOT modify, omit, or replace the neverallow rules present within the system/sepolicy/microdroid provided in the upstream Android Open Source Project (AOSP).
- [C-2-5] MUST implement
Protected Virtual MachinepVM defense-in-depth mechanisms (eg SELinux for pVMs) even for non-Microdroid operating systems. - [C-2-6] MUST ensure that the pVM fails
firmware refusesto boot ifit cannot verify the initialimages that the VM will run cannot be verified. The verification MUST be done inside the VM. - [C-2-7] MUST ensure that the pVM fails
firmware refusesto boot if the integrity of the instance.img is compromised.
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*), then the hypervisor:- [C-3-1] MUST ensure that memory pages exclusively owned by a VM (either pVM or host VM) are accessible only to the virtual machine itself or the hypervisor, not by other virtual machines - either protected or non-protected.
MUST NOT allow any pVM to have access to a page belonging to another entity (ie other pVM or hypervisor), unless explicitly shared by the page owner. This includes the host VM. This applies to both CPU and DMA accesses. - [C-3-2] MUST wipe a page after it is used by a pVM and before it is returned to the host (eg the pVM is destroyed).
- [C-
3-3SR-1 ] Is STRONGLY RECOMMENDED to ensureMUST ensurethat that the pVM firmware is loaded and executed prior to any code in a pVM. - [C-3-4] MUST ensure that each VM derives a per-VM secret which
{Boot Certificate Chain (BCC) and Compound Device Identifier (CDIs) provided to a pVM instancecan only be derived by that particular VM instance and changes upon factory reset and OTA.
If the device implements support for the Android Virtualization Framework APIs, then across all areas:
- [C-4-1] MUST NOT provide functionality to a pVM that allows bypassing the Android Security Model.
If the device implements support for the Android Virtualization Framework APIs, then:
- [C-5-1] MUST be capable to support Isolated Compilation but may disable Isolated Compilation feature on the device shipment
of an ART runtime update.
If the device implements support for the Android Virtualization Framework APIs, then for Key Management:
- [C-6-1] MUST root DICE chain at a point that the user cannot modify, even on unlocked devices. (To ensure it cannot be spoofed).
- [C- SR-2
6-2] Is STRONGLY RECOMMENDED to use DICE as the per-VM secret derivation mechanism.MUST do DICE properly ie provide the correct values.
- [C-1-1] MUST support all the APIs defined by the