Android के साथ काम करने की परिभाषा से जुड़े दस्तावेज़ में बदलाव का लॉग

Android 14

26 जून, 2024

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

  • 2.2.1. हार्डवेयर:

    बदलाव देखें

    • [7.6.1/H-1-1] सिर्फ़ एक एबीआई के साथ काम करना ज़रूरी है (सिर्फ़ 64-बिट या सिर्फ़ 32-बिट).

    बदलाव देखें

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

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

  • 2.4.1. हार्डवेयर:

    बदलाव देखें

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

    अगर Watch डिवाइस पर Vulkan के साथ काम करने की सुविधा उपलब्ध है, तो ये:

  • 2.5.1. हार्डवेयर:

    बदलाव देखें

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

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

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

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

    ODM_SKU पैरामीटर के लिए:

    बदलाव देखें

    इस फ़ील्ड की वैल्यू को 7-बिट ASCII के तौर पर कोड में बदलना चाहिए और रेगुलर एक्सप्रेशन ^([0-9A-Za-z.,_-]+)$ से मेल खाना चाहिए.

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

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

    Vorbis फ़ॉर्मैट/कोडेक के लिए जानकारी जोड़ी गई:

    बदलाव देखें

    डिकोड करने की सुविधा: मोनो, स्टीरियो, 5.0, और 5.1 कॉन्टेंट के लिए 8,000, 12,000, 16,000, 24,000, और 48,000 हर्ट्ज़ की सैंपलिंग रेट है.
    एन्कोडिंग: मोनो और स्टीरियो कॉन्टेंट के लिए सपोर्ट, जिसकी सैंपलिंग रेट 8000, 12,000, 164000, 16,080, 24,080 हो

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

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

  • 9.7. सुरक्षा सुविधा:

    डुप्लीकेट कॉन्टेंट को हटाने के लिए, [C-SR-1] को [C-SR-7] में बदला गया और हटाया गया [C-SR-8]:

    बदलाव देखें

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

    • [C-SR-2] कर्नेल कोड और मेमोरी के लेआउट को किसी भी क्रम में लगाने, और ऐसे एक्सपोज़र से बचने के लिए खास तौर पर सुझाव दिया जाता है जिनसे रैंडमाइज़ेशन की समस्या पैदा हो. उदाहरण के लिए, /chosen/kaslr-seed Device Tree node या EFI_RNG_PROTOCOL के ज़रिए बूटलोडर एंट्रॉपी के साथ CONFIG_RANDOMIZE_BASE).

    • [C-SR-3] का बहुत ज़्यादा सुझाव दिया जाता है, ताकि कर्नेल में कंट्रोल फ़्लो इंटिग्रिटी (सीएफ़आई) को चालू किया जा सके. इससे कोड का दोबारा इस्तेमाल करने के हमलों (जैसे, CONFIG_CFI_CLANG और CONFIG_SHADOW_CALL_STACK) से ज़्यादा सुरक्षा मिलती है.

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

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

    • [C-SR-6] का सुझाव दिया जाता है कि शुरू न किए गए लोकल वैरिएबल (CONFIG_INIT_STACK_ALL या CONFIG_INIT_STACK_ALL_ZERO) के इस्तेमाल को रोकने के लिए, कर्नेल में स्टैक शुरू करने की सुविधा चालू की जाए. साथ ही, डिवाइस को लागू करने की प्रोसेस में उस वैल्यू को नहीं मानना चाहिए जिसका इस्तेमाल कंपाइलर ने लोकल वैरिएबल को शुरू करने के लिए किया है.

    • [C-SR-7] को शुरू करने वाले हीप ऐलोकेशन के इस्तेमाल को रोकने के लिए कर्नेल में हीप शुरू करने की सुविधा (CONFIG_INIT_ON_ALLOC_DEFAULT_ON) को चालू करने का सुझाव दिया जाता है. साथ ही, उन्हें उस वैल्यू को नहीं मानना चाहिए जिसका इस्तेमाल कर्नेल ने उन आवंटन को शुरू करने के लिए किया है.

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

    बदलाव देखें

    • [C-1-6] इनमें से किसी एक पर काम करना ज़रूरी है:
      • IKeyMasterDevice 3.0,
      • IKeyMasterDevice 4.0,
      • IKeyMasterDevice 4.1,
      • IKeyMintDevice वर्शन 1 या
      • IKeyMintDevice वर्शन 2.

  • 9.11.1. सुरक्षित लॉक स्क्रीन, पुष्टि, और वर्चुअल डिवाइस:

    बदलाव देखें

    • [C-8-3] उन्हें तीसरे पक्ष के ऐप्लिकेशन की मदद से लॉक होने की स्थिति बदलने के लिए, एपीआई को सार्वजनिक नहीं करना चाहिए.

    बदलाव देखें

    • [C-12-4] TrustManagerService.revokeTrust() पर कॉल करना ज़रूरी है
      • भरोसा देने के 24 घंटों के बाद या
      • 8 घंटे की निष्क्रिय विंडो के बाद या
      • अगर लागू करने की प्रोसेस, [C-12-5] में बताई गई रेंज के मुताबिक क्रिप्टोग्राफ़िक तौर पर सुरक्षित और सटीक नहीं है, तो डिवाइस का इस्तेमाल नहीं किया जा सकता.
    • [C-12-5] ऐसे लागू करने के लिए नीचे दिए गए विकल्पों में से किसी एक का इस्तेमाल करना ज़रूरी है जो [C-12-4] की ज़रूरी शर्तों को पूरा करते हैं और सुरक्षित और सटीक होते हैं:
      • यूडब्ल्यूबी टेक्नोलॉजी का इस्तेमाल करके सुविधाएं लागू करना:
        • ज़रूरी है कि यूडब्ल्यूबी के लिए, नियमों के पालन, सर्टिफ़िकेशन, सटीक होने, और कैलिब्रेशन की ज़रूरी शर्तों को पूरा किया जाए. इन शर्तों के बारे में 7.4.9 में बताया गया है.
        • आपको 7.4.9 में बताए गए पी-एसटीएस सुरक्षा मोड में से किसी एक का इस्तेमाल करना होगा.
      • वाई-फ़ाई नेबरहुड अवेयरनेस नेटवर्किंग (एनएएन) का इस्तेमाल करके लागू करना:
        • इसे 2.2.1 [7.4.2.5/H-SR-1] में दी गई सटीक जानकारी से जुड़ी ज़रूरी शर्तों को पूरा करना होगा. साथ ही, 160 मेगाहर्ट्ज़ बैंडविथ (या इससे ज़्यादा) का इस्तेमाल करना होगा और मौजूदगी कैलिब्रेशन में दिए गए मेज़रमेंट सेटअप के चरणों को पूरा करना होगा.
        • Secure LTF का इस्तेमाल करना ज़रूरी है, जैसा कि IEEE 802.11az में बताया गया है.

8 अप्रैल, 2024

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

  • 2.2.1. हार्डवेयर:

    बदलाव देखें

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

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

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

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

    बदलाव देखें

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

    • [9.8/H-1-6] हर एक सफल हॉटवर्ड नतीजे पर हॉटवर्ड पहचान सेवा से 100 बाइट से ज़्यादा डेटा ट्रांसमिट करने की अनुमति नहीं दी जानी चाहिए. हॉटवर्ड ऑडियो स्ट्रीम से पास किए गए ऑडियो डेटा को छोड़कर.

    बदलाव देखें

    [9.8/H-1-13] को इससे बदलें:

    • [9.8/H-SR-3] हमारा सुझाव है कि हर घंटे में कम से कम एक बार या हर 30 हार्डवेयर-ट्रिगर इवेंट में से जो भी पहले हो, हॉटवर्ड डिटेक्शन सेवा को होस्ट करने की प्रोसेस को फिर से शुरू करें.

    बदलाव देखें

    हटाई गई ज़रूरी शर्तें [9.8.2/H-4-3], [9.8.2/H-4-4], [9.8.2/H-5-3].

  • 2.2.7.2. कैमरा:

    बदलाव देखें

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

    • [7.5/H-1-3] android.info.supportedHardwareLevel प्रॉपर्टी को FULL या बैक प्राइमरी के लिए और LIMITED या फ़्रंट प्राइमरी कैमरे के लिए बेहतर प्रॉपर्टी के तौर पर काम करना चाहिए.

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

    बदलाव देखें

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

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

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

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

  • 5.3.8. Dolby Vision:

    बदलाव देखें

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

    • [C-1-3] पुराने सिस्टम के साथ काम करने वाली बेस-लेयर (अगर मौजूद है) के ट्रैक आईडी को, Dolby Vision लेयर के कंबाइंड किए गए ट्रैक आईडी के जैसा ही सेट करना ज़रूरी है.

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

  • 7.1.1.1. स्क्रीन का साइज़ और आकार:

    बदलाव देखें

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

    • [C-1-1] इस तरह के हर डिसप्ले के लिए, यहां दी गई शर्तों में से कम से कम एक को पूरा करना ज़रूरी है:
      • जब 15 18 डीपी को 1518 डीपी के हिसाब से लॉजिकल डिसप्ले के हर कोने में दिखाया गया हो, तो स्क्रीन पर हर बॉक्स का कम से कम एक पिक्सल दिखेगा.

  • 7.4.3. ब्लूटूथ:

    बदलाव देखें

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

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

    • [C-SR-2] Rx ऑफ़सेट को मापने और उसकी भरपाई करने के लिए बहुत ज़्यादा सलाह दी जाती है. इससे यह पक्का किया जा सकता है कि ADVERTISE_TX_POWER_HIGH से ट्रांसमिट होने वाले रेफ़रंस डिवाइस से 1 मिनट की दूरी पर BLE आरएसएसआई का मीडियन -60dBm +/-10 dB है. यहां डिवाइस इस तरह बनाए गए हैं कि वे 'पैरलल प्लेन' पर इस तरह से हैं कि उनकी स्क्रीन एक ही दिशा में है.

    • [C-SR-3] Tx ऑफ़सेट को मापने और उसकी भरपाई करने की सलाह दी जाती है. इससे यह पक्का किया जा सकता है कि 1 मीटर की दूरी पर मौजूद रेफ़रंस डिवाइस से स्कैन करते समय और ADVERTISE_TX_POWER_HIGH पर ट्रांसमिट करते समय, आरएसएसआई का मीडियन -60dBm +/-10 dB हो. ऐसा तब होता है, जब डिवाइस एक जैसे हों और वे स्क्रीन की दिशा में एक जैसे हों.

    बदलाव देखें

    ज़रूरी शर्तें [C-10-3] और [C-10-4] को 2.2.1 में ले जाया गया. हार्डवेयर.

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

20 नवंबर, 2023

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

  • 2.2.1. हार्डवेयर:

    बदलाव देखें

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

  • 2.2.7.2. कैमरा:

    बदलाव देखें

    • [7.5/H-1-13] अगर पीछे एक से ज़्यादा आरजीबी कैमरे हैं, तो मुख्य पीछे वाले कैमरे के लिए LOGICAL_MULTI_CAMERA की सुविधा काम करनी चाहिए.

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

    बदलाव देखें

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

      एचएमआई आउटपुट मोड को सेट करना ज़रूरी है, ताकि रीफ़्रेश दर पर 50 हर्ट्ज़ या 60 हर्ट्ज़ पर काम करने वाले रिज़ॉल्यूशन को चुना जा सके.

  • 2.4.5. सुरक्षा मॉडल:

    बदलाव देखें

    • [9/W-0-1] android.hardware.security.model.compatible feature के बारे में बताना ज़रूरी है.

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

  • 6.1. डेवलपर टूल:

    बदलाव देखें

    • [C-0-12] 'ऐटम' को LMK_KILL_OCCURRED_FIELD_NUMBER पर

    बदलाव देखें

    • [C-0-13] दिखाने के लिए शेल कमांड dumpsys gpu --gpuwork लागू करना होगा

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

  • 9.7. सुरक्षा से जुड़ी सुविधाएं:

    बदलाव देखें

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

    बदलाव देखें

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

4 अक्टूबर, 2023

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

  • 2.2. हैंडहेल्ड से जुड़ी ज़रूरी शर्तें:

    बदलाव देखें

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

    • स्क्रीन के डायगनल साइज़ 4 इंच 3.3 इंच या एपीआई लेवल 29 या उससे पहले के वर्शन से 8 इंच के बीच होना चाहिए.

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

    • जिसमें टचस्क्रीन इनपुट इंटरफ़ेस हो.

  • 2.2.1. हार्डवेयर:

    बदलाव देखें

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

    • [7.1.1.1/H-0-1] Android के साथ काम करने वाला कम से कम एक ऐसा डिसप्ले होना चाहिए जो इस दस्तावेज़ में बताई गई सभी ज़रूरी शर्तें पूरी करता हो. ऐसा डिसप्ले जो छोटे किनारे पर कम से कम 2.2” और लंबे किनारे पर 3.4” का हो.

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

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

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

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

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

    • [7.1.1.1/H-0-3]* तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराए गए हर UI_MODE_NORMAL डिसप्ले को बिना रुकावट डिसप्ले वाले डिसप्ले एरिया पर मैप करना ज़रूरी है. डिसप्ले एरिया के छोटे किनारे पर कम से कम 2.2” इंच और लंबे किनारे 3.4” इंच होना चाहिए.

    • [7.1.1.3/H-0-1]* DENSITY_DEVICE_STABLE की वैल्यू को, इससे जुड़े डिसप्ले के असल और फ़िज़िकल डेंसिटी के 92% या उससे ज़्यादा पर सेट करना ज़रूरी है.

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

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

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

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

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

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

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

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

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

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

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

    बदलाव देखें

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

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

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

    • [5.3/H-0-6] AV1

  • 2.2.3. सॉफ़्टवेयर:

    बदलाव देखें

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

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

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

    • [3.8.16/H-1-6] डिवाइस लागू करने के तरीके के मुताबिक उपयोगकर्ता के लिए तय की गई कीमत को इस हिसाब से सही तरीके से रेंडर करना ज़रूरी है:
      • अगर डिवाइस ने config_supportsMultiWindow=true को सेट किया है और ऐप्लिकेशन ControlsProviderService की जानकारी में, मेटाडेटा META_DATA_PANEL_ACTIVITY के बारे में बताता है, तो इसमें किसी मान्य गतिविधि (जैसा कि एपीआई के मुताबिक तय किया गया है) का componentName भी शामिल है, तो ऐप्लिकेशन को इस उपयोगकर्ता के लिए तय की गई गतिविधि को एम्बेड करना होगा.
      • अगर ऐप्लिकेशन, मेटाडेटा META_DATA_PANEL_ACTIVITY के बारे में जानकारी नहीं देता है, तो उसे ControlsProviderService एपीआई से मिले तय फ़ील्ड के साथ-साथ Control API से मिले खास फ़ील्ड को रेंडर करना होगा.
    • [3.8.16/H-1-7] अगर ऐप्लिकेशन META_DATA_PANEL_ACTIVITY, मेटाडेटा की जानकारी देता है, तो एम्बेड की गई गतिविधि को लॉन्च करते समय, उसे [3.8.16/H-1-5] में बताई गई सेटिंग की वैल्यू पास करनी होगी. इसके लिए, उसे एम्बेड की गई गतिविधि को लॉन्च करते समय EXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS का इस्तेमाल करना होगा.

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

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

    बदलाव देखें

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

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

    • [8.5/H-0-2]उपयोगकर्ताओं को ऐसे ऐप्लिकेशन को बंद करने का अधिकार देना ज़रूरी है जिसमें फ़ोरग्राउंड सेवा या उपयोगकर्ता की ओर से शुरू की गई नौकरी चल रही हो.

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

    बदलाव देखें

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

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

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

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

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

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

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

    • [9.8/H-1-1] यह पक्का करना ज़रूरी है कि हॉटवर्ड की पहचान करने वाली सेवा, सिर्फ़ सिस्टम, ContentCaptureService या उपयोगकर्ता के डिवाइस पर मौजूद, बोली पहचानने वाली सेवा को SpeechRecognizer#createOnDeviceSpeechRecognizer() से डेटा ट्रांसमिट करे.
    • [9.8/H-1-6] हर एक सफल हॉटवर्ड नतीजे पर (ऑडियो स्ट्रीम को छोड़कर) हॉटवर्ड की पहचान करने वाली सेवा से बाहर भेजने के लिए 100 बाइट से ज़्यादा डेटा की अनुमति नहीं देनी चाहिए.

    • [9.8/H-1-15] यह पक्का करना ज़रूरी है कि हॉटवर्ड के नतीजों पर दी गई ऑडियो स्ट्रीम, हॉटवर्ड की पहचान करने वाली सेवा से वॉइस इंटरैक्शन सेवा को एकतरफ़ा भेजी जाएं.

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

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

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

    • [9.8/H-3-1] यह पक्का करना ज़रूरी है कि क्वेरी का पता लगाने वाली सेवा सिर्फ़ सिस्टम, ContentCaptureService या डिवाइस पर बोली पहचानने वाली सेवा (SpeechRecognizer#createOnDeviceSpeechRecognizer() की बनाई गई) को डेटा भेज सके.
    • [9.8/H-3-2] ContentCaptureService या उपयोगकर्ता के डिवाइस पर बोली पहचानने वाली सेवा के अलावा, VisualQueryDetectionService से बाहर कोई भी ऑडियो या वीडियो की जानकारी भेजने की अनुमति नहीं होनी चाहिए.
    • [9.8/H-3-3] जब डिवाइस को पता चलता है कि कोई व्यक्ति, डिजिटल असिस्टेंट ऐप्लिकेशन का इस्तेमाल करना चाहता है, तो उसे सिस्टम यूज़र इंटरफ़ेस (यूआई) में उपयोगकर्ता की सूचना ज़रूर दिखानी चाहिए.जैसे, कैमरे से उपयोगकर्ता की मौजूदगी का पता लगाना.
    • [9.8/H-3-4] माइक्रोफ़ोन इंंडिकेटर दिखाना ज़रूरी है. साथ ही, उपयोगकर्ता की क्वेरी का पता चलने के तुरंत बाद, यूज़र इंटरफ़ेस (यूआई) में उपयोगकर्ता की क्वेरी को दिखाना ज़रूरी है.
    • [9.8/H-3-5] उपयोगकर्ता से इंस्टॉल किए जा सकने वाले ऐप्लिकेशन को विज़ुअल क्वेरी की पहचान करने वाली सेवा देने की अनुमति नहीं देनी चाहिए.

  • 2.2.7.1. मीडिया:

    बदलाव देखें

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

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

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

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

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

    • [5.2/H-2-1] आने वाले दस्तावेज़ में दी गई जानकारी के मुताबिक, इसे हार्डवेयर एवीसी और एचईवीसी कोडेक के लिए वीडियो एन्कोडर रेट-डिस्टॉर्शन कर्व के ज़रिए तय किए गए कम से कम क्वालिटी टारगेट को पूरा करना होगा.

  • 2.2.7.2. कैमरा:

    बदलाव देखें

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

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

  • 2.2.7.3. हार्डवेयर:

    बदलाव देखें

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

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

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

    बदलाव देखें

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

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

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

    बदलाव देखें

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

    • [5.2/T-0-3] AV1

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

  • 2.4.5. सुरक्षा मॉडल:

    बदलाव देखें

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

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

  • 2.5.1. हार्डवेयर:

    बदलाव देखें

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

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

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

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

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

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

    • [7.5/A-1-1] यह ज़रूरी है कि बाहरी व्यू वाले कैमरों को Android Camera APIs से ऐक्सेस किया जा सके. हालांकि, कैमरे की मुख्य शर्तों को पूरा करने पर, इन कैमरों को ऐक्सेस किया जा सकता है.
    • [7.5/A-SR-1] इस बात का खास तौर पर सुझाव दिया जाता है कि कैमरे की झलक को न तो घुमाएं और न ही हॉरिज़ॉन्टल तौर पर शेयर करें.
    • [7.5/A-SR-2] का रिज़ॉल्यूशन कम से कम 1.3 मेगापिक्सल के लिए बहुत ज़्यादा रखा जाता है.
    • इसमें फ़िक्स्ड-फ़ोकस या EDOF (फ़ील्ड की बढ़ाई गई डेप्थ) हार्डवेयर होना चाहिए.
    • हो सकता है कि कैमरा ड्राइवर में हार्डवेयर ऑटो-फ़ोकस या सॉफ़्टवेयर ऑटो-फ़ोकस सुविधा लागू की गई हो.

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

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

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

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

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

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

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

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

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

    • [7.5/A-SR-1] हमारा सुझाव है कि एक या एक से ज़्यादा ऐसे कैमरों को शामिल करें जो आपकी स्क्रीन पर साफ़ तौर पर दिखते हों.
    • इनमें एक या उससे ज़्यादा लोगों के सामने वाले कैमरे शामिल हो सकते हैं.
    • [7.5/A-SR-2] इस सुविधा का सुझाव दिया जाता है, ताकि एक साथ कई कैमरों से स्ट्रीमिंग की जा सके.

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

    • [7.5/A-1-1] इस तरह से किया जाना चाहिए कि कैमरे का लंबा डाइमेंशन Android ऑटोमोटिव सेंसर ऐक्सिस के X-Y प्लेन के साथ अलाइन हो.
    • [7.5/A-SR-3] तय फ़ोकस या EDOF (फ़ील्ड की बढ़ाई गई डेप्थ) हार्डवेयर का इस्तेमाल करने का सुझाव दिया जाता है.
    • [7.5/A-1-2] ऐसा मुख्य कैमरा होना चाहिए जो दुनिया के सामने वाले कैमरे के तौर पर इस्तेमाल किया जाता हो और फ़ोन का कैमरा आईडी सबसे कम हो.

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

    • [7.5/A-2-1] लोगों के लिए मुख्य कैमरा वही होना चाहिए जिसका आईडी सबसे कम हो.
    • इसे इस तरह से डिज़ाइन किया जा सकता है कि कैमरे का लंबा डाइमेंशन, Android ऑटोमोटिव सेंसर ऐक्सिस के X-Y प्लेन के साथ अलाइन हो सके.

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

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

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

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

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

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

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

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

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

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

  • 2.5.3. सॉफ़्टवेयर:

    बदलाव देखें

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

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

  • 2.5.5. सुरक्षा मॉडल:

    बदलाव देखें

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

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

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

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

    • [9.8.2/A-2-3] लोगों को Settings ऐप्लिकेशन में कैमरा टॉगल करने की सुविधा देनी होगी.
    • [9.8.2/A-2-4] कैमरे का इस्तेमाल करने वाले हाल ही के और चालू ऐप्लिकेशन, PermissionManager.getIndicatorAppOpUsageData() से लौटाए गए ऐप्लिकेशन के तौर पर दिखाना ज़रूरी है. साथ ही, उनसे जुड़े एट्रिब्यूशन मैसेज भी दिखाने होंगे.

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

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

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

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

    बदलाव देखें

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

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

  • 3.2.3.5. शर्त के साथ ऐप्लिकेशन इंटेंट:

    बदलाव देखें

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

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

    बदलाव देखें

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

    • [C-0-12] मुख्य Vulkan 1.0 Vulkan 1.1 फ़ंक्शन के सिंबल के साथ-साथ, libvulkan.so लाइब्रेरी से VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain, VK_KHR_maintenance1, और VK_KHR_get_physical_device_properties2 एक्सटेंशन के लिए, फ़ंक्शन सिंबल एक्सपोर्ट करने होंगे. ध्यान दें कि सभी सिंबल का मौजूद होना ज़रूरी है. हालांकि, सेक्शन 7.1.4.2 में, ज़रूरी शर्तों के बारे में ज़्यादा जानकारी दी गई है. इससे, यह बताया गया है कि हर फ़ंक्शन को कब पूरी तरह लागू किया जाना चाहिए.

  • 3.8.6. थीम:

    बदलाव देखें

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

    • [C-1-5] Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES वाले दस्तावेज़ (android.theme.customization.theme_styles देखें) में बताए गए कलर थीम स्टाइल का इस्तेमाल करके, डाइनैमिक कलर टोनल पैलेट जनरेट करना ज़रूरी है (android.theme.customization.theme_styles देखें), जैसे कि TONAL_SPOT, VIBRANT, EXPRESSIVE, SPRITZ, RAINBOW, FRUIT_SALAD, औरMONOCHROMATIC.

  • 3.8.8. गतिविधि स्विच करना:

    बदलाव देखें

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

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

    बदलाव देखें

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

    • [C-1-10] यह पक्का करना ज़रूरी है कि स्क्रीनशॉट का डेटा, वर्क प्रोफ़ाइल के स्टोरेज में सेव हो. ऐसा तब होता है, जब स्क्रीनशॉट किसी ऐसी topActivity विंडो का इस्तेमाल करके लिया जाता है जिसमें फ़ोकस हो. साथ ही, वह वर्क प्रोफ़ाइल ऐप्लिकेशन से जुड़ा हो जिसमें फ़ोकस हो.
    • [C-1-11] वर्क प्रोफ़ाइल में स्क्रीनशॉट सेव करते समय (यह पक्का करने के लिए कि निजी प्रोफ़ाइल का डेटा वर्क प्रोफ़ाइल में सेव न हो) को छोड़कर, वर्क प्रोफ़ाइल ऐप्लिकेशन विंडो/विंडो को छोड़कर, स्क्रीन पर मौजूद कोई भी अन्य कॉन्टेंट (सिस्टम बार, सूचनाएं या कोई भी निजी प्रोफ़ाइल कॉन्टेंट) कैप्चर नहीं करना चाहिए.

  • 3.9.5 डिवाइस नीति से जुड़ी समस्या हल करने का फ़्रेमवर्क: नया सेक्शन

    बदलाव देखें

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

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

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

  • 5.1.4. इमेज को कोड में बदलने का तरीका:

    बदलाव देखें

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

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

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

    बदलाव देखें

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

    [C-0-7] AVIF (बेसलाइन प्रोफ़ाइल)

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

    बदलाव देखें

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

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

    बदलाव देखें

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

  • 5.1.10. मीडिया कोडेक की कैटगरी तय करना:

    बदलाव देखें

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

    • [C-2-1] अगर कोडेक के साथ काम करता है, तो सभी वीडियो कोडेक को नीचे दिए गए साइज़ के लिए, हासिल किए जा सकने वाले फ़्रेम रेट का डेटा पब्लिश करना होगा:
    एसडी (खराब क्वालिटी) एसडी (अच्छी क्वालिटी) एचडी 720 पिक्सल एचडी 1080 पिक्सल यूएचडी
    वीडियो रिज़ॉल्यूशन
    • 176 x 144 पिक्सल (H263, MPEG2, MPEG4)
    • 352 x 288 पिक्सल (MPEG4 एन्कोडर, H263, MPEG2)
    • 320 x 180 पिक्सल (VP8, VP8)
    • 320 x 240 पिक्सल (अन्य)
    • 704 x 576 पिक्सल (H263)
    • 640 x 360 पिक्सल (VP8, VP9)
    • 640 x 480 पिक्सल (MPEG4 एन्कोडर)
    • 720 x 480 पिक्सल (अन्य, AV1)
    • 1408 x 1152 पिक्सल (H263)
    • 1280 x 720 पिक्सल (अन्य, AV1)
    		 1920 x 1080 पिक्सल (MPEG4, AV1 के अलावा) 3840 x 2160 पिक्सल (HEVC, VP9, AV1)

  • 5.2. वीडियो को कोड में बदलने का तरीका:

    बदलाव देखें

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

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

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

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

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

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

  • 5.2.1. H.263:

    बदलाव देखें

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

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

  • 5.2.5. H.265:

    बदलाव देखें

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

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

  • 5.2.6. AV1: नया सेक्शन

    बदलाव देखें

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

    • [C-1-1] 8-बिट और 10-बिट कॉन्टेंट समेत मुख्य प्रोफ़ाइल के साथ काम करना ज़रूरी है.

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

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

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

    • [C-2-1] यहां दी गई टेबल में, एचडी1080p एन्कोडिंग प्रोफ़ाइल के साथ काम करना ज़रूरी है:
    एसडी एचडी 720 पिक्सल एचडी 1080 पिक्सल यूएचडी
    वीडियो रिज़ॉल्यूशन 720 x 480 पिक्सल 1280 x 720 पिक्सल 1920 x 1080 पिक्सल 3840 x 2160 पिक्सल
    वीडियो फ़्रेम रेट 30 एफ़पीएस (फ़्रेम प्रति सेकंड) 30 एफ़पीएस (फ़्रेम प्रति सेकंड) 30 एफ़पीएस (फ़्रेम प्रति सेकंड) 30 एफ़पीएस (फ़्रेम प्रति सेकंड)
    वीडियो बिटरेट 5 एमबीपीएस 8 एमबीपीएस 16 एमबीपीएस 50 एमबीपीएस

  • 5.3.2. H.263:

    बदलाव देखें

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

    • [C-1-1] बेसलाइन प्रोफ़ाइल लेवल 30 (CIF, QCIF, और SQCIF रिज़ॉल्यूशन @ 30fps 384 केबीपीएस) और लेवल 45 (QCIF और SQCIF रिज़ॉल्यूशन @ 30fps 128 केबीपीएस) पर भी काम करना ज़रूरी है.

  • 5.3.9. AV1:

    बदलाव देखें

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

    • [C-1-1] प्रोफ़ाइल 0 के साथ काम करना ज़रूरी है, जिसमें 10-बिट कॉन्टेंट भी शामिल हो.

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

    • [C-1-1] 8-बिट और 10-बिट कॉन्टेंट समेत मुख्य प्रोफ़ाइल के साथ काम करना ज़रूरी है.

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

    • [C-2-1] Display.getSupportedModes() वाले तरीके से रिपोर्ट की गई ऊंचाई 720 पिक्सल या इससे ज़्यादा होने पर, यहां दी गई टेबल से कम से कम एचडी 720 पिक्सल वाले वीडियो डिकोड करने वाली प्रोफ़ाइलों को डिकोड किया जा सकता है.
    • [C-2-2] Display.getSupportedModes() वाले तरीके से रिपोर्ट की गई ऊंचाई 1080 पिक्सल या इससे ज़्यादा होने पर, यहां दी गई टेबल से कम से कम एचडी 1080 पिक्सल वाले वीडियो डिकोड करने वाली प्रोफ़ाइलों को डिकोड करना ज़रूरी है.
    एसडी एचडी 720 पिक्सल एचडी 1080 पिक्सल यूएचडी
    वीडियो रिज़ॉल्यूशन 720 x 480 पिक्सल 1280 x 720 पिक्सल 1920 x 1080 पिक्सल 3840 x 2160 पिक्सल
    वीडियो फ़्रेम रेट 30 एफ़पीएस (फ़्रेम प्रति सेकंड) 30 एफ़पीएस (फ़्रेम प्रति सेकंड) 30 एफ़पीएस (फ़्रेम प्रति सेकंड) 30 एफ़पीएस (फ़्रेम प्रति सेकंड)
    वीडियो बिटरेट 5 एमबीपीएस 8 एमबीपीएस 16 एमबीपीएस 50 एमबीपीएस

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

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

  • 5.4.2. आवाज़ पहचानने के लिए कैप्चर करें:

    बदलाव देखें

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

    • ऑडियो इनपुट की संवेदनशीलता को इस तरह सेट करना चाहिए कि हर माइक्रोफ़ोन के लिए 1000 हर्ट्ज़ से दोगुने ऑडियो के टोन के सोर्स को 90 dB के साउंड प्रेशर लेवल (एसपीएल) पर चलाया गया. (इसे माइक्रोफ़ोन से 30 सें॰मी॰ की दूरी पर मापा गया.

  • 5.5.2. ऑडियो इफ़ेक्ट:

    बदलाव देखें

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

    • [C-1-4] फ़्लोटिंग-पॉइंट इनपुट और आउटपुट के साथ ऑडियो इफ़ेक्ट काम करना ज़रूरी है.
    • [C-1-5] यह पक्का करना ज़रूरी है कि ऑडियो इफ़ेक्ट, मिक्सर चैनलों की संख्या के लिए भी एफ़सीसी_LIMIT तक के कई चैनलों के साथ काम करते हों.

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

    बदलाव देखें

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

    • [C-SR-4] AudioTrack.getTimestamp और AAudioStream_getTimestamp से मिला आउटपुट टाइमस्टैंप, +/- 1 मि॰से॰ के हिसाब से सटीक होता है.

    • [C-SR-4] AAudioStream_getTimestamp से मिले इनपुट और आउटपुट टाइमस्टैंप के आधार पर परिकलित दोतरफ़ा यात्रा के इंतज़ार का समय, AAUDIO_PERFORMANCE_MODE_NONE और स्पीकर, वायर वाले और वायरलेस हेडसेट के लिए AAUDIO_PERFORMANCE_MODE_LOW_LATENCY के लिए मापी गई दोतरफ़ा यात्रा के इंतज़ार के समय से 30 मि॰से॰ के अंदर होना चाहिए.

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

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

    बदलाव देखें

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

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

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

    • [C-0-1] डिफ़ॉल्ट रूप से, तीसरे पक्ष के ऐप्लिकेशन को सिर्फ़ Android के साथ काम करने वाले डिसप्ले पर रेंडर करना ज़रूरी है.

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

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

  • 7.1.1.1. स्क्रीन का साइज़ और आकार:

    बदलाव देखें

    अगर लागू किए गए डिवाइस पर इन स्क्रीन को रेंडर करने के लिए UI_MODE_TYPE_NORMAL साइज़ कॉन्फ़िगरेशन वाली स्क्रीन काम करती हों और Android के साथ काम करने वाला हो, तो इन स्क्रीन को रेंडर करने के लिए गोल कोने वाले फ़िज़िकल डिसप्ले इस्तेमाल करें.

    • [C-1-1] यह पक्का करना ज़रूरी है कि ऐसे हर डिसप्ले के लिए यहां दी गई ज़रूरी शर्तों में से कम से कम एक को पूरा किया गया हो:
    • गोल किनारों का रेडियस 38 dp से कम या उसके बराबर होता है.

    • जब 15 dp x 15 dp बॉक्स को लॉजिकल डिसप्ले के हर कोने में ऐंकर किया जाता है, तो स्क्रीन पर हर बॉक्स का कम से कम एक पिक्सल दिखता है.

    • इसमें उपयोगकर्ताओं के लिए, आयताकार कोनों पर डिसप्ले मोड पर स्विच करने का खर्च भी शामिल होना चाहिए.

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

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

    • [C-4-1] डिसप्ले कटआउट को छोड़कर, कम से कम 596 dp x 384 dp या इससे ज़्यादा लेआउट वाला लेआउट होना ज़रूरी है.

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

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

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

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

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

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

  • 7.1.1.2. स्क्रीन का आसपेक्ट रेशियो: हटाया गया

  • 7.1.1.3. स्क्रीन की डेंसिटी:

    बदलाव देखें

    डिवाइस में बदलाव:

    • [C-0-1] डिफ़ॉल्ट रूप से, डिवाइस के इस्तेमाल करने के तरीके DisplayMetrics पर DENSITY_DEVICE_STABLE API के ज़रिए सूची में शामिल Android फ़्रेमवर्क के डेंसिटी में से किसी एक की रिपोर्ट करना ज़रूरी है और यह वैल्यू हर फ़िज़िकल डिसप्ले के लिए एक स्टैटिक वैल्यू होनी चाहिए किसी भी समय डिसप्ले के साइज़ की जानकारी DisplayMetrics.density

    • डिवाइस को लागू करने के लिए, Android फ़्रेमवर्क की स्टैंडर्ड सघनता तय की जानी चाहिए जो संख्या के हिसाब से स्क्रीन की फ़िज़िकल डेंसिटी के सबसे करीब हो. ऐसा तब तक होना चाहिए, जब तक कि लॉजिकल सघनता, रिपोर्ट किए गए स्क्रीन साइज़ को स्क्रीन के साइज़ से कम न कर दे. अगर Android फ़्रेमवर्क की स्टैंडर्ड सघनता, स्क्रीन के फ़िज़िकल सघनता के सबसे करीब होती है, तो स्क्रीन के सबसे छोटे साइज़ (320 dp की चौड़ाई) से कम स्क्रीन साइज़ मिलता है. ऐसे में, डिवाइस को लागू करने के लिए, Android फ़्रेमवर्क की अगली डेंसिटी के बारे में बताना चाहिए.

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

    • Android फ़्रेमवर्क की स्टैंडर्ड सघनता तय करनी चाहिए, जो स्क्रीन की फ़िज़िकल सघनता के सबसे करीब हो. इसके अलावा, ऐसा मान भी तय किया जाना चाहिए जो हैंडहेल्ड डिवाइस के कोण वाले फ़ील्ड ऑफ़ व्यू के बराबर माप को मैप करे.

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

    • [C-1-1] डिसप्ले साइज़ को किसी भी स्केल नहीं करना चाहिए डिसप्ले को 1.5 गुना से ज़्यादा स्केल नहीं करना चाहिए 1.5 गुना DENSITY_DEVICE_STABLE नेटिव डेंसिटी या 320dp (रिसॉर्स क्वालीफ़ायर sw320dp के बराबर) से कम, जो भी पहले हो, एक असरदार कम से कम स्क्रीन डाइमेंशन बनाएं.
    • [C-1-2] डिसप्ले साइज़ को किसी भी स्केल नहीं किया जाना चाहिए डिसप्ले को स्केल नहीं करना चाहिए और उसे DENSITY_DEVICE_STABLE नेटिव डेंसिटी के 0.85 गुना से कम करना चाहिए.

  • 7.1.4.2 Vulkan:

    बदलाव देखें

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

    • [C-1-3] Vulkan 1.0 Vulkan 1.1 के हर एपीआई के लिए VkPhysicalDevice को पूरी तरह से लागू करना ज़रूरी है.

    • [C-1-5] ऐप्लिकेशन पैकेज के बाहर की लाइब्रेरी से मिले लेयर की गिनती नहीं करनी चाहिए या Vulkan API का पता लगाने या उसे रोकने के दूसरे तरीके नहीं बताना चाहिए. ऐसा तब तक नहीं होना चाहिए, जब तक ऐप्लिकेशन में android:debuggable एट्रिब्यूट को true या मेटाडेटा com.android.graphics.injectLayers.enable को true पर सेट न किया गया हो.

    • VkPhysicalDeviceProtectedMemoryFeatures और VK_EXT_global_priority के साथ काम करना चाहिए.

    • [C-SR-5] VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory और VK_EXT_global_priority के साथ काम करने के लिए, इस बात पर काफ़ी ज़ोर दिया जाता है.

    • [C-SR-6] HWUI के साथ SkiaVk का इस्तेमाल करने का सुझाव दिया जाता है.

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

    • [C-SR-7] का खास तौर पर सुझाव दिया जाता है कि VK_KHR_external_fence_fd एक्सटेंशन को तीसरे पक्ष के ऐप्लिकेशन के लिए उपलब्ध कराया जाए. साथ ही, यहां बताए गए तरीके से, POSIX फ़ाइल की जानकारी देने वाले डिवाइसों से फ़ेंस पेलोड एक्सपोर्ट करने और उसे इंपोर्ट करने के लिए, ऐप्लिकेशन को चालू किया जा सके.

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

    बदलाव देखें

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

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

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

    • [C-7-2] मुख्य रूप से पहचान की पुष्टि करने का सुझाव (जैसे: पिन, पैटर्न, पासवर्ड) के लिए, लोगों को चैलेंज देना होगा कि बायोमेट्रिक लॉक होने पर लॉकआउट काउंटर को रीसेट करें. क्लास 3 बायोमेट्रिक्स को एक ही या उससे कम क्लास के लॉक किए गए बायोमेट्रिक के लिए, लॉकआउट काउंटर रीसेट करने की अनुमति दी जा सकती है. क्लास 2 या क्लास 1 बायोमेट्रिक्स को किसी भी बायोमेट्रिक्स के लिए, लॉकआउट कार्रवाई करने की अनुमति नहीं होनी चाहिए.

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

    • [C-1-12] प्रज़ेंटेशन अटैक इंस्ट्रुमेंट (पीएआई) की हर प्रजातियों के लिए स्पूफ़ और इंपोस्टर के स्वीकार करने की दर 40% से ज़्यादा नहीं होनी चाहिए. इसे Android बायोमेट्रिक्स टेस्ट प्रोटोकॉल्स से मापा जाता है.

    • [C-SR-13] स्पूफ़ और इंपोस्टर स्वीकार करने की दर को हर प्रज़ेंटेशन अटैक इंस्ट्रुमेंट (पीएआई) की 30% से ज़्यादा प्रजातियों के लिए इस्तेमाल करने की बहुत ज़्यादा सलाह दी जाती है. इसे Android बायोमेट्रिक्स टेस्ट प्रोटोकॉल से मापा गया है.

    • [C-SR-14] बायोमेट्रिक सेंसर की बायोमेट्रिक क्लास और इसे चालू करने से जुड़े जोखिमों के बारे में बताने का सुझाव दिया जाता है.

    • [C-SR-17] नए एआईडीएल इंटरफ़ेस (जैसे, IFace.aidl और IFingerprint.aidl) को लागू करने के लिए, इस बात पर ज़ोर दिया जाता है.

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

    • [सी-एसआर-15] इस बात की बहुत ज़्यादा सलाह दी जाती है कि स्पूफ़ और इंपोस्टर मंज़ूरी की दर हर प्रज़ेंटेशन अटैक इंस्ट्रुमेंट (पीएआई) की 20% से ज़्यादा न हो. यह दर Android बायोमेट्रिक्स टेस्ट प्रोटोकॉल से मापी जाती है.

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

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

    • [सी-एसआर-16] इस बात की बहुत ज़्यादा सलाह दी जाती है कि स्पूफ़ और इंपोस्टर मंज़ूरी रेट हर प्रज़ेंटेशन अटैक इंस्ट्रुमेंट (पीएआई) की 7% से ज़्यादा प्रजातियों से ज़्यादा न हो. Android बायोमेट्रिक्स टेस्ट प्रोटोकॉल के मुताबिक, यह दर 7% से ज़्यादा नहीं होनी चाहिए.

  • 7.3.13. आईईईई 802.1.15.4 (यूडब्ल्यूबी):

    बदलाव देखें

    अगर डिवाइस पर लागू होने वाले 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: CONFIG_ID_1 की तरह है. हालांकि, पहुंचने का कोण (AoA) डेटा रिपोर्ट नहीं किया जाता.
      • CONFIG_ID_4: CONFIG_ID_1 की तरह ही, P-STS सुरक्षा मोड भी चालू है.
      • CONFIG_ID_5: CONFIG_ID_2 की तरह ही, P-STS सुरक्षा मोड भी चालू है.
      • CONFIG_ID_6: CONFIG_ID_3 की तरह ही, P-STS सुरक्षा मोड भी चालू है.
      • CONFIG_ID_7: CONFIG_ID_2 की तरह ही, P-STS का व्यक्तिगत कंट्रोली कुंजी मोड चालू है.
    • [C-1-4] लोगों को यह सुविधा देनी होगी कि वे यूडब्ल्यूबी रेडियो को चालू/बंद करने की सुविधा को टॉगल कर सकें.
    • [C-1-5] यह ज़रूरी है कि यूडब्ल्यूबी रेडियो का इस्तेमाल करने वाले ऐप्लिकेशन के लिए, NEARBY_DEVICES अनुमति ग्रुप के तहत UWB_RANGING अनुमति होल्ड पर हो.

    FIRA, CCC, और सीएसए जैसे मानक संगठनों के तय किए गए नियमों के पालन और सर्टिफ़िकेशन से जुड़ी जांचों को पास करने से, यह पक्का करने में मदद मिलती है कि 802.1.15.4 सही तरीके से काम कर रहा है.

  • 7.4.1. टेलीफ़ोनी:

    बदलाव देखें

    Android API में इस्तेमाल की जाने वाली “Telephony की सेवाएं” और इस दस्तावेज़ में खास तौर पर, वॉइस कॉल करने और एसएमएस मैसेज भेजने या मोबाइल (जैसे GSM, CDMA, LTE, NR) GSM या CDMA नेटवर्क के ज़रिए मोबाइल डेटा सेट करने वाले हार्डवेयर के बारे में बताया गया है. “Telephony” की सुविधा देने वाला डिवाइस, प्रॉडक्ट के हिसाब से कुछ या सभी कॉल, मैसेज सेवा, और डेटा सेवाएं देने का विकल्प चुन सकता है.

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

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

    बदलाव देखें

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

    • [C-1-4] किसी भी समय मल्टीकास्ट डीएनएस (एमडीएनएस) के साथ काम करना चाहिए और mडीएनएस पैकेट (224.0.0.251 या ff02::fb) को फ़िल्टर नहीं करना चाहिए. ऐसा तब तक करना ज़रूरी है, जब तक कि स्क्रीन चालू न हो, जब तक कि बाज़ार से जुड़े नियमों के मुताबिक, ऊर्जा की खपत की रेंज में बने रहने के लिए इन पैकेट को फ़िल्टर करना ज़रूरी न हो. स्टैंडबाय पावर की स्थिति में भी Android Television डिवाइस को लागू करने के लिए.

  • 7.4.3. ब्लूटूथ:

    बदलाव देखें

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

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

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

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

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

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

    बदलाव देखें

    • [C-1-7] ज़रूरी है कि रेफ़रंस डिवाइस से 1 मीटर की दूरी के माप का मीडियन [0.75 मीटर, 1.25 मीटर] के अंदर हो. यहां डीयूटी के ऊपरी किनारे से ज़मीन की दूरी को मापा जाता है. अपने चेहरे को ऊपर की ओर रखकर 45 डिग्री झुकाया गया हो.

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

    बदलाव देखें

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

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

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

    बदलाव देखें

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

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

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

    बदलाव देखें

    बाहरी कैमरा ऐसा कैमरा होता है जिसे किसी भी समय, डिवाइस से असल में जोड़ा या अलग किया जा सकता है और यह किसी भी दिशा में हो सकता है, जैसे कि यूएसबी कैमरे.

  • 7.5.4. Camera API का व्यवहार:

    बदलाव देखें

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

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

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

    बदलाव देखें

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

    • ऐसे डिवाइस जिन्हें उपयोगकर्ता घुमा नहीं सकते, जैसे कि ऑटोमोटिव डिवाइस.

  • 7.10. हैप्टिक:

    बदलाव देखें

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

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

    • [7.10/C] Vibrator.hasVibrator() के लिए 'गलत' दिखाना चाहिए.

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

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

    • android.os.Vibrator.areAllEffectsSupported() और android.os.Vibrator.arePrimitivesSupported() एपीआई चलाकर, लागू करने की स्थिति की पुष्टि करनी चाहिए.
    • हैप्टिक कॉन्सटेंट के लिए क्वालिटी की जांच करनी चाहिए.
    • अगर कॉन्सटेंट के लिए, लागू करने के दिशा-निर्देश में बताया गया है, तो काम नहीं करने वाले प्रिमिटिव के लिए फ़ॉलबैक कॉन्फ़िगरेशन की ज़रूरत पड़ने पर, उसकी पुष्टि करके उसे अपडेट करना होगा.
    • यहां बताए गए तरीके से, गड़बड़ी के जोखिम को कम करने के लिए, फ़ॉलबैक सहायता दी जानी चाहिए.

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

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

  • 9.1. अनुमतियां:

    बदलाव देखें

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

    • [C-0-4] दोनों यूज़र इंटरफ़ेस को एक ही बार लागू करना ज़रूरी है.

    अगर लागू किए गए डिवाइस में कोई भी ऐसा पैकेज पहले से इंस्टॉल होता है जिसमें System UI Intelligence, System Ambient Audio Intelligence, System Audio Intelligence, System Notification Intelligence, System Text Intelligence या System Visual Intelligence की भूमिकाएं शामिल हों, तो ये पैकेज:

    • [C-4-1] "9.8.6 कॉन्टेंट कैप्चर" "9.8.6 ओएस-लेवल और ऐंबियंट डेटा और 9.8.15 सैंडबॉक्स एपीआई लागू करने से जुड़े सेक्शन में, डिवाइस पर लागू होने वाली सभी ज़रूरी शर्तों को पूरा करना होगा".

    • [C-4-2] आपके पास android.permission.INTERnet की अनुमति नहीं होनी चाहिए. यह सेक्शन 9.8.6 में दिए गए 'बहुत ज़्यादा सुझाया गया' सेक्शन से ज़्यादा सख्त है.
    • [C-4-3] नीचे दिए गए सिस्टम ऐप्लिकेशन के अलावा, अन्य ऐप्लिकेशन को बाइंड नहीं करना चाहिए: ब्लूटूथ, Contacts, मीडिया, Telephony, SystemUI, और इंटरनेट एपीआई उपलब्ध कराने वाले कॉम्पोनेंट. यह सेक्शन 9.8.6 में दिए गए 'सुझाया गया' सेक्शन से ज़्यादा सख्त है.

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

    • [C-5-1] इस ऐप्लिकेशन के लिए, ACCESS_FINE_LOCATION को डिफ़ॉल्ट तौर पर इस्तेमाल नहीं करना चाहिए.

  • 9.5. कई उपयोगकर्ताओं के लिए सहायता:

    बदलाव देखें

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

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

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

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

    • [C-4-3] सिर्फ़ इस अतिरिक्त प्रोफ़ाइल से संपर्क लिखने की अनुमति दें. इसके लिए, आपको यहां दिए गए इंटेंट इस्तेमाल करने होंगे:

    • [C-4-4] इस अतिरिक्त उपयोगकर्ता प्रोफ़ाइल में चल रहे ऐप्लिकेशन के लिए, संपर्क सिंक नहीं होने चाहिए.

    • [C-4-14] इस अतिरिक्त प्रोफ़ाइल में चल रहे ऐप्लिकेशन के लिए, आपके पास अलग से अनुमति और स्टोरेज मैनेजमेंट होना ज़रूरी है

    • [C-4-5] सिर्फ़ उस अतिरिक्त प्रोफ़ाइल वाले ऐप्लिकेशन को अनुमति देनी होगी जिसमें लॉन्चर गतिविधि की गई हो. इससे उन संपर्कों को ऐक्सेस करने में मदद मिलती है जिन्हें पैरंट उपयोगकर्ता प्रोफ़ाइल से ऐक्सेस किया जा सकता है.

  • 9.7. सुरक्षा से जुड़ी सुविधाएं:

    बदलाव देखें

    मेमोरी सुरक्षा तकनीक एक ऐसी टेक्नोलॉजी है जो android:memtagMode मेनिफ़ेस्ट विकल्प का इस्तेमाल करने वाले ऐप्लिकेशन में, कम से कम नीचे दी गई गड़बड़ियों की कैटगरी को कम (> 90%) से कम करती है:

    • हीप बफ़र ओवरफ़्लो
    • मुफ़्त में इस्तेमाल करें
    • डबल फ़्री
    • वाइल्ड फ़्री (नॉन-मलोक पॉइंटर से मुक्त)

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

    • [C-SR-15] को सेट करने के लिए बहुत ज़्यादा सुझाव दिया जाता है ro.arm64.memtag.bootctl_supported.

    अगर लागू किए गए डिवाइस की सेटिंग, सिस्टम प्रॉपर्टी ro.arm64.memtag.bootctl_supported को 'सही है' पर सेट करती है, तो ये:

    • [C-3-1] सिस्टम प्रॉपर्टी arm64.memtag.bootctl को नीचे दी गई वैल्यू की कॉमा लगाकर अलग की गई सूची स्वीकार करने की अनुमति देनी होगी. साथ ही, अगला चरण फिर से चालू करने पर, उस सूची को लागू करना होगा:

      • memtag: मेमोरी की सुरक्षा वाली ऊपर बताई गई टेक्नोलॉजी चालू है
      • memtag-once: मेमोरी की सुरक्षा वाली टेक्नोलॉजी, जैसा कि ऊपर बताया गया है, कुछ समय के लिए चालू होती है. साथ ही, डिवाइस को फिर से चालू करने पर यह अपने-आप बंद हो जाती है
      • memtag-off: ऊपर बताई गई मेमोरी की सुरक्षा टेक्नोलॉजी को बंद किया गया है

    • [C-3-2] शेल उपयोगकर्ता को arm64.memtag.bootctl सेट करने की अनुमति देनी होगी.

    • [C-3-3] arm64.memtag.bootctl को पढ़ने के लिए किसी भी प्रोसेस की अनुमति देना ज़रूरी है.

    • [C-3-4] बूट करने पर, arm64.memtag.bootctl को अभी अनुरोध की गई स्थिति पर सेट करना ज़रूरी है. अगर डिवाइस लागू करने की वजह से सिस्टम की प्रॉपर्टी बदले बिना राज्य में बदलाव करने की अनुमति मिलती है, तो प्रॉपर्टी को भी अपडेट करना होगा.

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

    • [C-SR-17] को सुरक्षा सेटिंग मेन्यू में एक ऐसी सेटिंग दिखाने का सुझाव दिया जाता है जिससे उपयोगकर्ता memtag को चालू कर सकता है.

  • 9.8.2. रिकॉर्डिंग:

    बदलाव देखें

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

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

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

    • [C-0-4] उपयोगकर्ताओं को आने वाले समय में, स्क्रीन कैप्चर करने के लिए उपयोगकर्ता की सहमति लेने के लिए बने प्रॉम्प्ट बंद करने की सुविधा नहीं देनी चाहिए. ऐसा तब तक नहीं किया जा सकता, जब तक सेशन को ऐसे सिस्टम ऐप्लिकेशन से शुरू न किया गया हो जिसे उपयोगकर्ता ने android.app.role.COMPANION_DEVICE_APP_STREAMING या android.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMING डिवाइस प्रोफ़ाइल से associate() करने की अनुमति दी है.

  • 9.8.6. ओएस-लेवल और ऐंबियंट डेटा: इस सेक्शन का नाम बदलकर, कॉन्टेंट कैप्चर और ऐप्लिकेशन सर्च से ओएस-लेवल और ऐंबियंट डेटा कर दिया गया है.

    बदलाव देखें

    Android, System API ContentCaptureService, AugmentedAutofillService, AppSearchGlobalManager.query या अन्य मालिकाना हक वाले तरीकों की मदद से, डिवाइस पर यह सुविधा देता है कि ऐप्लिकेशन और उपयोगकर्ता के बीच ऐप्लिकेशन डेटा के इस इंटरैक्शन संवेदनशील डेटा को कैप्चर किया जा सके:

    • AugmentedAutofillService के ज़रिए सिस्टम को भेजी गई कोई भी स्क्रीन या अन्य डेटा.
    • Content Capture एपीआई की मदद से ऐक्सेस की जा सकने वाली कोई भी स्क्रीन या अन्य डेटा.
    • FieldClassificationService एपीआई से ऐक्सेस की जा सकने वाली कोई भी स्क्रीन या अन्य डेटा
    • कोई भी ऐप्लिकेशन डेटा, जो AppSearchManager API के ज़रिए सिस्टम को भेजा जाता है और AppSearchGlobalManager.query के ज़रिए ऐक्सेस किया जा सकता है.

    • ऐसा कोई भी अन्य इवेंट जिसे कोई ऐप्लिकेशन, Content Capture एपीआई या AppSearchManager एपीआई की मदद से, सिस्टम को उपलब्ध कराता है. यह ऐसे इवेंट होते हैं जो Android और मालिकाना हक वाले एपीआई के ज़रिए काम करते हैं.

    • Speech Recognitionr की मदद से SpeechRecognizer#onDeviceSpeechRecognizer() का इस्तेमाल करने पर मिला ऑडियो डेटा.
    • जो ऑडियो डेटा, AudioRecord, SoundTrigger या अन्य ऑडियो एपीआई के ज़रिए बैकग्राउंड में लगातार (लगातार) मिलता है और जिसकी वजह से लोगों को दिखने वाला इंडिकेटर नहीं मिलता
    • कैमरा डेटा जो CameraManager या अन्य Camera API की मदद से, बैकग्राउंड में लगातार (लगातार) मिलता है. साथ ही, इससे उपयोगकर्ता को दिखने वाला इंडिकेटर नहीं दिखता

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

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

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

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

    • [C-SR-3] इस बात पर ज़ोर दिया जाता है कि इन्हें Android SDK API या इसी तरह के OEM के मालिकाना हक वाले ओपन सोर्स रिपॉज़िटरी के साथ लागू किया जाए; और / या इन्हें सैंडबॉक्स किए गए तरीके से लागू किया जाए (9.8.15 सैंडबॉक्स एपीआई लागू करने का तरीका देखें).

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

  • 9.8.10. कनेक्टिविटी से जुड़ी गड़बड़ी की रिपोर्ट:

    बदलाव देखें

    अगर लागू किए गए डिवाइस ने android.hardware.telephony फ़ीचर फ़्लैग का एलान किया है, तो:

    • [C-1-4] BUGREPORT_MODE_TELEPHONY का इस्तेमाल करके जनरेट की गई रिपोर्ट में, कम से कम यह जानकारी होनी चाहिए:
      • SubscriptionManagerService डंप

  • 9.8.14. क्रेडेंशियल मैनेजर: हटाया गया

  • 9.8.15. सैंडबॉक्स एपीआई को लागू करने की प्रोसेस: नया सेक्शन

    बदलाव देखें

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

    सैंडबॉक्स एपीआई को लागू करना:

    • [C-0-1] इंटरनेट की अनुमति के लिए अनुरोध नहीं करना चाहिए.
    • [C-0-2] सिर्फ़ स्ट्रक्चर्ड एपीआई की मदद से इंटरनेट ऐक्सेस करना ज़रूरी है. निजता बनाए रखने वाले तरीकों का इस्तेमाल करके, सार्वजनिक तौर पर उपलब्ध ओपन सोर्स लागू करना ज़रूरी है. इसके अलावा, Android SDK के एपीआई के ज़रिए भी ऐसा किया जा सकता है. निजता बनाए रखने वाले सिस्टम को "ऐसे डेटा को कहा जाता है जो सिर्फ़ एग्रीगेट डेटा का विश्लेषण करने की अनुमति देते हैं और लॉग किए गए इवेंट या लॉग किए गए इवेंट के नतीजों को अलग-अलग उपयोगकर्ताओं से मैच करने से रोकते हैं." ऐसा इसलिए किया जाता है, ताकि हर उपयोगकर्ता के डेटा को घुलने-मिलने लायक न बनाया जा सके. जैसे, RAPPOR जैसी डिफ़रेंशियल प्राइवसी टेक्नोलॉजी का इस्तेमाल करके लागू किया गया डेटा.
    • [C-0-3] सेवाओं को सिस्टम के दूसरे कॉम्पोनेंट से अलग रखना ज़रूरी है (जैसे, सेवा या शेयर करने की प्रोसेस के आईडी को बाइंड नहीं करना). इसमें ये शामिल नहीं हैं:
      • Telephony, संपर्क, सिस्टम यूज़र इंटरफ़ेस (यूआई), और मीडिया
    • [C-0-4] उपयोगकर्ताओं को सेवाओं के बजाय, इंस्टॉल किए जा सकने वाले ऐप्लिकेशन या सेवा इस्तेमाल करने की अनुमति नहीं देनी चाहिए
    • [C-0-5] सिर्फ़ पहले से इंस्टॉल की गई सेवाओं को इस तरह का डेटा कैप्चर करने की अनुमति देनी चाहिए. जब तक एओएसपी (जैसे, डिजिटल असिस्टेंट ऐप्लिकेशन) में बदलाव करने की क्षमता न हो.
    • [C-0-6] पहले से इंस्टॉल की गई सेवाओं के अलावा, किसी भी ऐप्लिकेशन को ऐसा डेटा कैप्चर करने की अनुमति नहीं देनी चाहिए. जब तक कैप्चर करने की ऐसी क्षमता, Android SDK API की मदद से लागू न की गई हो.
    • [C-0-7] सेवाओं को बंद करने के लिए, लोगों को ज़रूरी अधिकार देना ज़रूरी है.
    • [C-0-8] सेवाओं के तहत दी जाने वाली Android की अनुमतियों को मैनेज करने के लिए, उपयोगकर्ता के खर्च का ध्यान रखना ज़रूरी है. साथ ही, सेक्शन 9.1. अनुमति.

  • 9.8.16. ऑडियो और कैमरे का लगातार डेटा: नया सेक्शन

    बदलाव देखें

    9.8.2 रिकॉर्डिंग, 9.8.6 ओएस-लेवल और ऐंबियंट डेटा, और 9.8.15 सैंडबॉक्स एपीआई को लागू करने की प्रोसेस में बताई गई ज़रूरी शर्तों के अलावा, ऐसे काम करने की सुविधा जिनमें Camera Manager या अन्य कैमरा एपीआई के ज़रिए बैकग्राउंड में ऑडियो डेटा (लगातार) का इस्तेमाल ऑडियो रिकॉर्ड, साउंड ट्रिगर या अन्य ऑडियो एपीआई या बैकग्राउंड में मिलने वाले कैमरा डेटा (लगातार) का इस्तेमाल किया जा सके:

    • [C-0-1] सेक्शन 9.8.2 के तहत, रिकॉर्डिंग से जुड़े इंडिकेटर (कैमरा और/या माइक्रोफ़ोन) को तब तक लागू करना ज़रूरी है, जब तक:
      • यह ऐक्सेस, सैंडबॉक्स किए गए इंप्लिमेंटेशन (9.8.15 सैंडबॉक्स एपीआई को लागू करना) में किया जाता है. इसके लिए, इनमें से एक या ज़्यादा भूमिकाओं वाले पैकेज का इस्तेमाल किया जाता है: System UI Intelligence, System Ambient Audio Intelligence, System Audio Intelligence, System Notification Intelligence, सिस्टम टेक्स्ट इंटेलिजेंस या सिस्टम विज़ुअल इंटेलिजेंस
      • ऐक्सेस, सैंडबॉक्स की मदद से किया जाता है. इसे एओएसपी (HotwordDetectionService, WearableSensingService, VisualQueryDetector) में लागू और लागू करने के तरीके के ज़रिए लागू किया जाता है.
      • Assistant ऐप्लिकेशन, सहायक कामों के लिए ऑडियो ऐक्सेस का इस्तेमाल करता है. यह ऐप्लिकेशन, SOURCE_HOTWORD को ऑडियो सोर्स के तौर पर सप्लाई करता है.
      • सिस्टम इसे ऐक्सेस करता है और ओपन-सोर्स कोड को लागू करता है.
    • [C-SR-1] इस तरह के डेटा का इस्तेमाल करने वाली हर सुविधा के लिए, उपयोगकर्ता की सहमति लेने का सुझाव दिया जाता है. साथ ही, यह सुविधा डिफ़ॉल्ट रूप से बंद रहती है.
    • [C-SR-2] यही विकल्प अपनाने का सुझाव दिया जाता है. जैसे, पहने जाने वाले रिमोट डिवाइस से मिलने वाले कैमरा डेटा पर, 9.8.2 रिकॉर्डिंग, 9.8.6 ओएस-लेवल और ऐंबियंट डेटा, 9.8.15 सैंडबॉक्स एपीआई को लागू करना, और 9.8.16 लगातार ऑडियो और कैमरा डेटा में बताई गई पाबंदियों का पालन करना.

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

    • [C-1-1] आपको रिमोट पर पहने जाने वाले डिवाइस पर एक और इंडिकेटर दिखाना होगा.

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

    • [C-2-1] यह पक्का करना ज़रूरी है कि इस तरह का इस्तेमाल, android.app.role.ASSISTANT भूमिका वाले पैकेज से किया गया हो.
    • [C-2-2] यह पक्का करना ज़रूरी है कि इस तरह लागू करने पर, HotwordDetectionService और/या VisualQueryDetectionService Android एपीआई का इस्तेमाल किया जाता है.

  • 9.8.17. टेलीमेट्री: नया सेक्शन

    बदलाव देखें

    Android, StateLog API का इस्तेमाल करके सिस्टम और ऐप्लिकेशन लॉग को सेव करता है. ये लॉग,StatsManager API की मदद से मैनेज किए जाते हैं. इनका इस्तेमाल खास सिस्टम ऐप्लिकेशन के ज़रिए किया जा सकता है.

    StatsManager, निजता बनाए रखने वाले किसी तरीके का इस्तेमाल करके डेटा इकट्ठा करने का तरीका भी उपलब्ध कराता है. यह डेटा, निजता के लिए संवेदनशील माना जाता है. खास तौर पर, StatsManager::query API, StatsLog में तय की गई मेट्रिक की पाबंदी वाली कैटगरी से क्वेरी करने की सुविधा देता है.

    StatsManager से प्रतिबंधित मेट्रिक को इकट्ठा करने और उन्हें लागू करने के लिए की गई क्वेरी:

    • [C-0-1] डिवाइस पर सिर्फ़ ऐप्लिकेशन/लागू करने का तरीका ही होना चाहिए. साथ ही, READ_RESTRICTED_STATS की अनुमति होनी चाहिए.
    • [C-0-2] निजता बनाए रखने के तरीके का इस्तेमाल करके, सिर्फ़ टेलीमेट्री डेटा और डिवाइस का लॉग भेजना ज़रूरी है. निजता बनाए रखने वाले तरीके को "ऐसे डेटा" के तौर पर परिभाषित किया गया है जो सिर्फ़ एग्रीगेट डेटा का विश्लेषण करने देते हैं और लॉग किए गए इवेंट या अलग-अलग उपयोगकर्ताओं से मिले नतीजों को मैच करने से रोकते हैं.इससे हर उपयोगकर्ता के डेटा को घुलने-मिलने लायक नहीं बनाया जा सकता. उदाहरण के लिए, RAPPOR जैसी डिफ़रेंशियल प्राइवसी टेक्नोलॉजी का इस्तेमाल करके इसे लागू करना.
    • [C-0-3] इस तरह के डेटा को डिवाइस पर मौजूद किसी उपयोगकर्ता की पहचान (जैसे खाता) से नहीं जोड़ना चाहिए.
    • [C-0-4] ऐसे डेटा को ओएस के ऐसे दूसरे कॉम्पोनेंट के साथ शेयर नहीं किया जाना चाहिए जो मौजूदा सेक्शन (9.8.17 निजता बनाए रखने वाली टेलीमेट्री) में बताई गई ज़रूरी शर्तों का पालन नहीं करते.
    • [C-0-5] लोगों के पास निजता बनाए रखने की सुविधा को चालू या बंद करने का विकल्प होना चाहिए. इससे उन्हें टेलीमेट्री डेटा को इकट्ठा करने, उसे इस्तेमाल करने, और उसे शेयर करने की सुविधा मिलती है.
    • [C-0-6] अगर डेटा को डिवाइस पर किसी भी रूप में सेव किया जाता है, तो डेटा को इकट्ठा करने की सुविधा की मदद से, उपयोगकर्ता को ऐसा डेटा मिटाने की सुविधा देनी होगी. अगर उपयोगकर्ता ने डेटा को मिटाने का विकल्प चुना है, तो उसे डिवाइस पर सेव किया गया मौजूदा सारा डेटा हटाना होगा.
    • [C-0-7] निजता बनाए रखने वाले प्रोटोकॉल को लागू करने के बारे में, ओपन सोर्स रिपॉज़िटरी में जानकारी देना ज़रूरी है.
    • [C-0-8 ]इस सेक्शन में, डेटा इग्रेस डेटा ट्रैफ़िक की नीतियां लागू करना ज़रूरी है. इससे, StatsLog में तय की गई प्रतिबंधित मेट्रिक कैटगरी में डेटा इकट्ठा करने पर रोक लगाई जाएगी.

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

    बदलाव देखें

    डिवाइस पर ऐप्लिकेशन को लागू करना

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

    • [C-0-3 C-2-1] पूरी फ़ाइल को पढ़े बिना, भरोसेमंद कुंजी के ख़िलाफ़ फ़ाइल के कॉन्टेंट की क्रिप्टोग्राफ़िक तरीके से पुष्टि की जा सकती है.

    • [C-0-4 C-2-2] अगर पढ़े गए कॉन्टेंट की किसी भरोसेमंद कुंजी से पुष्टि नहीं की गई है ऊपर दिए गए [C-2-1] के हिसाब से नहीं, तो सुरक्षित फ़ाइल पर किए गए पढ़ने के अनुरोधों को सफल बनाने की अनुमति नहीं देनी चाहिए.

    • [C-2-4] चालू की गई फ़ाइलों के लिए, O(1) में फ़ाइल चेकसम लौटाना ज़रूरी है.

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

    बदलाव देखें

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

    • [C-0-3] पुष्टि करने के लिए, फ़ेल होने वाले मुख्य तरीकों की संख्या को सीमित करना ज़रूरी है.
    • [C-SR-2] पुष्टि करने की 20 असफल कोशिशों की ऊपरी सीमा को लागू करने का सुझाव दिया जाता है. अगर उपयोगकर्ता सहमति देते हैं और सुविधा को ऑप्ट-इन करते हैं, तो पुष्टि करने की मुख्य कोशिशों की सीमा पार करने के बाद, "फ़ैक्ट्री डेटा रीसेट" करें.

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

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

  • 9.11.1. सुरक्षित लॉक स्क्रीन, पुष्टि, और वर्चुअल डिवाइस:

    बदलाव देखें

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

    • [C-0-1] पुष्टि करने के लिए, फ़ेल होने वाले मुख्य तरीकों की संख्या को सीमित करना ज़रूरी है.
    • [C-SR-5] पुष्टि करने की 20 असफल कोशिशों की ऊपरी सीमा को लागू करने का सुझाव दिया जाता है. अगर उपयोगकर्ता इस सुविधा को सहमति देते हैं और उसे ऑप्ट-इन करते हैं, तो पुष्टि करने की नाकाम कोशिशों की सीमा पार करने के बाद, "फ़ैक्ट्री डेटा रीसेट" करें.

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

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

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

    [C-7-8] उपयोगकर्ता को पुष्टि करने के सुझाए गए मुख्य तरीकों (जैसे: पिन, पैटर्न, पासवर्ड) में से किसी एक को पूरा करने के लिए, हर 72 घंटे में कम से कम एक बार चुनौती देनी होगी. ऐसा सिर्फ़ तब करना होगा, जब उपयोगकर्ता की सुरक्षा को लेकर कोई समस्या (जैसे कि ड्राइवर का ध्यान भटकना) न हो.

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

    [C-13-10] वर्चुअल डिवाइसों से शुरू किए गए ऐप्लिकेशन को इंस्टॉल करने की सुविधा बंद करनी होगी.

  • 9.17. Android वर्चुअलाइज़ेशन फ़्रेमवर्क:

    बदलाव देखें

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

    • [C-1-1] android.system.virtualmachine पैकेज में बताए गए सभी एपीआई के साथ काम करना ज़रूरी है.
    • [C-1-2] Protected Virtual Machines (pVM) को मैनेज करने के लिए, Android SELinux में बदलाव करना ज़रूरी नहीं है.

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

    • [C-1-4] सिर्फ़ प्लैटफ़ॉर्म साइन कोड और खास सुविधा वाले ऐप्लिकेशन कोभरोसेमंद कोड (जैसे, 3p वाले ऐप्लिकेशन) को Protected Virtual Machine pVM बनाने और चलाने की अनुमति नहीं देनी चाहिए. ध्यान दें: यह विकल्प, आने वाले Android रिलीज़ में बदल सकता है.

    • [C-1-5] Protected Virtual Machine pVM को ऐसा कोड चलाने की अनुमति नहीं देनी चाहिए जो फ़ैक्ट्री इमेज या उसके अपडेट का हिस्सा न हो. ऐसी कोई भी चीज़ जिसे Android वेरिफ़ाइड बूट की सुविधा के तहत इस्तेमाल नहीं किया जा सकता (जैसे, इंटरनेट से डाउनलोड की गई फ़ाइलें या अलग से लोड की गई फ़ाइलें), उसे सुरक्षित वर्चुअल मशीन में चलाने की अनुमति नहीं देनी चाहिए .

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

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

    • [C-2-1] यह ज़रूरी है कि यह Protected Virtual Machine pVM डिवाइस पर उपलब्ध सभी ऑपरेटिंग सिस्टम चला सके जो वर्चुअलाइज़ेशन APEX में उपलब्ध हैं.
    • [C-2-2] Protected Virtual Machine pVM को ऐसा ऑपरेटिंग सिस्टम चलाने की अनुमति नहीं देनी चाहिए जिस पर डिवाइस लागू करने वाले या ओएस वेंडर ने हस्ताक्षर न किया हो.
    • [C-2-3] Protected Virtual Machine pVM को अनुमति नहीं देनी चाहिए, जो डेटा को कोड के तौर पर एक्ज़ीक्यूट कर सकें (उदाहरण के लिए, SELinux कभी भी execmem की अनुमति नहीं देता).

    • [C-2-4] अपस्ट्रीम Android ओपन सोर्स प्रोजेक्ट (एओएसपी) में दिए गए सिस्टम/sepolicy/माइक्रोड्रॉइड में मौजूद नियमों में बदलाव नहीं करना चाहिए, उन्हें छोड़ना या बदलना नहीं चाहिए.

    • [C-2-5] Protected Virtual Machine pVM फ़ंक्शन को गहराई से लागू करना ज़रूरी है (जैसे, pVMs के लिए SELinux) को नॉन-माइक्रोड्रॉइड ऑपरेटिंग सिस्टम के लिए भी लागू करना.
    • [C-2-6] यह पक्का करना ज़रूरी है कि पीवीएम काम नहीं करता फ़र्मवेयर अस्वीकार हो जाता है. ऐसा तब होता है, जब यह पुष्टि नहीं कर पाता हो कि वीएम के चलने की शुरुआती इमेज की पुष्टि न हो पाए. पुष्टि की प्रक्रिया वीएम में ही पूरी होनी चाहिए.
    • [C-2-7] यह पक्का करना ज़रूरी है कि pVM फ़ेल हो जाता है फ़र्मवेयर अस्वीकार हो जाता है, ताकि example.img की इंटिग्रिटी के साथ छेड़छाड़ की जा सके.

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

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

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

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

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

    • [C-5-1] आइसोलेटेड कंपाइलेशन की सुविधा काम कर सकती हो. हालांकि, किसी आर्ट रनटाइम अपडेट के डिवाइस पर, आइसोलेटेड कंपाइलेशन की सुविधा को बंद किया जा सकता है.

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

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

    • [C-SR-26-2] हर वीएम के सीक्रेट डेरिवेशन तरीके के तौर पर DICE का इस्तेमाल करने का सुझाव दिया जाता है. DICE की मदद से वीडियो बनाएं. जैसे, सही वैल्यू डालें.

पेज पर सबसे ऊपर जाएं